unopar

1. Cuiabá
2014
WILLIAM NÉFI NEVES GAERTNER
SISTEMA DE ENSINO PRESENCIAL CONECTADO
TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS
PROJETO DE SOFTWARE DE LOCADORA DE VEÍCULOS.

2. Cuiabá
2014
PROJETO DE SOFTWARE DE LOCADORA DE VEÍCULOS.
Trabalho de Tecnologia em Analise e Desenvolvimento
de Sistemas apresentado à Universidade Norte do
Paraná - UNOPAR, como requisito parcial para a
obtenção de média semestral na disciplina de
Programação Web 1, Projetos de Sistemas e Interface
Homem-Computador.
WILLIAM NEFI NEVES GAERTNER

4. SUMÁRIO
1 INTRODUÇÃO...........................................................................................................5
2 OBJETIVO..................................................................................................................6
3 DESENVOLVIMENTO...............................................................................................7
4 CONCLUSÃO...........................................................................................................76
REFERÊNCIAS..........................................................................................................77

5. 1 INTRODUÇÃO
A realização desta pesquisa com base no estudo de caso "Projeto
de Implementação do ERP na China Telecom” integrando as disciplinas do
semestre, com conceitos conexos ao contento do semestre consistindo em:
Na disciplina “Engenharia e Projeto de Software”, buscou-se abordar
os conceitos relacionados as áreas de competência de acordo com o PMBoK quanto
a: risco, escopo, fornecedores e partes interessadas.
5

6. 2 OBJETIVO
A presente produção textual tem por objetivo compreender o
contento do eixo temático impulsionando a interatividade e a regionalidade e
auxiliando no bom emprego dos conceitos aprendidos.
O intento desta pesquisa é compreender a viabilidade de se
desenvolver o sistema de informação considerado, desenvolvendo a informação em
engenharia de software, em gestão de projetos, e em programação para a web.
6

7. 3 DESENVOLVIMENTO
A China Telecom, a maior operadora de comunicações de telefonia
fixa do mundo, surgiu de uma remodelação da estatal China Telecommunications
corporation. Hoje, emprega em todo o território chinês 350 mil trabalhadores que
atuam em suas operações de redes de telefonia fixa domésticas e internacionais;
serviços de informação, voz e dados por telefonia fixa; e na compensação de contas
internacionais. Apesar da forte concorrência representada pelos serviços de
telefonia
móvel, a empresa vem mantendo um crescimento vigoroso.
Em 2002, a China Telecom tornou-se uma empresa de capital aberto
com ações negociadas na Bolsa de Valores de Nova York. Nesse mesmo ano, os
Estados Unidos concederam à empresa licença para fornecer serviços de internet e
telefonia internacional entre os dois países. Esses passos fazem parte da transição
de uma empresaestatal, à moda antiga, para uma empresa moderna, fundamentada
em lucros maiores e base de clientes mais ampla. No entanto, para se firmar como
um peso pesado das telecomunicações internacionais, a China Telecom teve de
resolver vários problemas. Em primeiro lugar, a empresa precisava de uma
infraestrutura de TI de última geração. Em segundo lugar, precisava atender às
exigências internacionais de prestação de contas que recaem sobre as empresas de
capital aberto. Em terceiro lugar, precisava integrar todas as suas funções
empresariais e permitir o gerenciamento em tempo real. Juntas, essas iniciativas
aumentariam a eficiência organizacional, o controle das operações internas e a
colaboração entre os diferentes departamentos.
3.1 ENGENHARIA E PROJETO DE SOFTWARE
3.1.1 Risco
O risco é um evento ou uma condição de algo que poderá ocorrer ou
não, é incerto, entretanto, se ocorrer, causará efeitos significantes, estes podem ser
negativos ou positivos, em objetos ou projetos.
Os riscos podem ser separados em categorias e avaliados quanto a
sua estrutura analítica.
Dentro do PMbok se tratando de riscos, pode se entender que
7

8. existem fatores positivos e negativos onde se ocorrer um evento incerto pode
influenciar em um ou mais objetivos do projeto.
Alguns fatores podem ser citados, um deles é a troca de funcionários
por fator de desligamento da empresa, podendo ocorrer mudanças no quadro de
desenvolvedores envolvidos, com isso atrasando a entrega do projeto ou a
qualidade inadequada no planejamento do projeto.
Há ainda o chamado risco residual, este é aquele que permanece
mesmo após as respostas quanto a este terem sido implementadas.
No caso dos riscos secundários, são aqueles surgidos após o
resultado direto daimplementação de uma resposta a riscos previamente
observados.
3.1.2 Escopo
O escopo pode ser conceituado como a soma dos produtos, serviços
e resultados a serem fornecidos na forma de projeto.
O Escopo do produto são as características e funções que
conceituam um determinado produto, serviço ou resultado.
Escopo do projeto, o trabalho que deve ser feito para que se
entregue um produto serviço ou resultado, de acordo com características e funções
previamente especificadas.
O escopo de um projeto deve ser elaborado cuidadosamente
especialmente devido aos riscos, não é viável sair do foco do projeto já estabelecido,
este deve seguir integro aos seus pré-requisitos funcionais.
É composto dos processos para garantir que o projeto inclua todo o
trabalho exigido, e somente o trabalho exigido, para completar o projeto com
sucesso.
O escopo é a soma dos produtos, serviços e resultados a serem
fornecidos na forma de projeto. O trabalho que deve ser realizado para entregar um
produto, serviço ou resultado com as funcionalidades e funções especificadas.
O escopo deve ser analisado junto ao seu projeto de modo que não
haja falhas, devendo avaliar o que será feito, como vai ser sua funcionalidade, qual
usuário irá atender, verificando sua documentação cuidadosamente para não
acrescentar nada além do projetado para não haver um Transbordamento de
Escopo, introduzindo maiores requerimentos, do que os que deveriam integrar o
planejamento inicial.
8

9. 3.1.3 Fornecedores
O fornecedor é o indivíduo responsável por proporcionar os produtos
necessários, bem como prover serviços ou resultados para uma organização, a
responsabilidade do fornecedor é de suma importância, já que sem o correto e
preciso fornecimento o projeto ficará prejudicado, e nãoalcançará os devidos
resultados.
É o processo de gerenciamento de aquisições que obtém respostas,
como cotações e propostas, de possíveis fornecedores sobre como os requisitos do
projeto devem ser alcançados. Os possíveis fornecedores, normalmente sem custos
diretos para o projeto ou comprador, gastam a maior parte do esforço real nesse
processo.
Os processos desta área de conhecimento, tem como objetivo
determinar o que se quer adquirir e de quem se quer adquirir, recebendo as
respostas do fornecedor e selecionando o fornecedor escolhido, como se dará o
gerenciamento dos contratos, pagamentos, verificar se as entregas estão sendo
realizadas de acordo com o que foi estabelecido, pagar o fornecedor e formalizar e
finalizar o contrato. O projeto dessa área são: planejar as aquisições, realizar as
aquisições e administrá-las, por último encerrar as aquisições.
3.1.4 Partes Interessadas
As
denominadas
“Partes
interessadas”,
“intervenientes”
ou
“stakeholders” (termo em inglês) são todos os envolvidos no projeto, sejam pessoas
9

10. ou entidades, que possam compartilhar de interesses que possam ser satisfeitos
positiva ou negativamente com a realização ou pelos resultados do projeto. Em geral
as partes interessadas possuem ainda a capacidade de influenciar sobre o projeto e
sobre os indivíduos componentes equipe do projeto. (PMI 2008)
É a décima área de conhecimento inclusa no PMBok, essa mudança
afetou principalmente os processos de comunicação, embora vista por alguns
especialistas como parte interessadas de Recursos Humanos, sua criação tem total
fundamento, uma vez que o gerenciamento por parte dos Gerentes vai muito além
da comunicação.
Com isso o gerenciamento de questões e problemas também recebe
uma maior atenção,incentivando um maior envolvimento das partes interessadas
nas decisões e atividades do projeto. Seus principais processos são: Identificar as
partes interessadas, planejar o gerenciamento das partes interessadas, gerenciar o
envolvimento das partes interessadas e monitorar e controlar o envolvimento das
partes interessadas.
Suponha que a empresa optasse pelo desenvolvimento próprio, faça
uma resenha dos seguintes capítulos:
Desde o momento que se instaura um projeto, a equipe de gerencia
deve identificar as partes interessadas, tanto internas quanto externas. Que, no
decorrer do planejamento e da implementação do projeto, o gestor do projeto e a
equipe devem ser responsáveis pelo gerenciamento das diferentes necessidades,
apreensões e perspectivas das partes interessadas, assim como a influência no
projeto, em busca de um resultado bem-sucedido.
Alguns exemplos de partes interessadas são citadas por Ávila (2013,
p. 1):
•
•
•
•
Clientes e usuários;
Presidente, donos e executivos;
10

11. Acionistas e investidores;
Gerentes funcionais;
11

12. 12
•
Escritório de projetos (Project Management Office PMO), gerentes e comitês de
portfólios e de programas;
•
Fornecedores e parceiros comerciais;
•
Concorrentes;
•
Governo, em suas diversas esferas e poderes;
•
Organismos de regulação e fiscalização internos e
externos, incluindo auditorias, agências, conselhos, sindicatos
e associações institucionais, profissionais e oficiais;
•
Organizações não governamentais (ONG);
•
Comunidades, vizinhança e população abrangida pelas
ações e resultados do projeto.
•
Patrocinador (Sponsor);
•
A equipe do projeto.
12

13. 13
3.1.5 Projeto de Arquitetura
O processo de projeto de arquitetura é o primeiro estágio para a
construção de um projeto e conta com umaligação critica entre processos de
engenharia de projeto e de requisitos. O processo de arquitetura estabelece o
framework básico para a identificação dos principais componentes de um sistema e
a comunicação entre eles.
Entre as vantagens deste, cita-se:
•
Comunicação de stakeholders;
•
Analise de sistema;
•
Reuso em larga escala.
Neste capitulo, tem como objetivo apresentar os conceitos de
arquitetura de software e projeto de arquitetura, nele compreenderá o porquê da
importância do projeto de arquitetura de software, saberá quais as decisões devem
ser tomadas sobre a arquitetura de sistema durante o processo de projeto de
arquitetura, será apresentado a três estilos complementares de arquitetura que
abrangerá a organização geral, decomposição modular e controle de sistema e
compreenderá como as arquiteturas de referência são usadas para comunicar
conceitos de arquitetura e para avaliar arquiteturas de sistema.
Sistemas grandes são sempre decompostos em subsistemas que
fornecem conjunto de serviços relacionados. O Processo inicial de projeto, que
consiste em identificar esses subsistemas e estabelecer um framework para o
controle e a comunicação de subsistemas, é denominado projeto de arquitetura.
13

14. De acordo com as informações prestadas no capitulo, nos é
informado que a arquitetura é o primeiro estágio no processo de projeto e representa
uma ligação crítica entre os processos de engenharia de projeto e requisitos. O
processo de projeto de arquitetura envolve o estabelecimento de um framework
básico que identifica os principais componentes de um sistema e as comunicações
entre eles.
Três vantagens de projetar e documentar explicitamente uma
arquitetura de software é, inicialmente a comunicação entre os
Stakeholders,gerentes do projeto, onde a arquitetura é apresentada em alto nível do
sistema que
poderá ser utilizada para enfoque e discussões entre os diferentes gerentes. Em
segundo uma análise do sistema tornando a arquitetura do sistema explícita onde o
14

15. 14
desenvolvimento requer alguma mudança e a análise é fundamental no projeto onde
tem profundo efeito sobre se o sistema atende aos requisitos críticos como
desempenho, confiabilidade e facilidade de manutenção. Em terceiro o reuso em
larga escala, onde um modelo de arquitetura pelo sistema é uma descrição
compacta e administrável de como um sistema está organizado e de como os
componentes operam entre si. A arquitetura de sistema é muitas vezes a mesma
para sistemas com requisitos similares, podendo apoiar o reuso de software em
larga escala.
Hofmeister explica como o estágio de projeto de arquitetura força os
projetistas de software a considerar aspectos principais do projeto logo no início,
eles sugerem que a arquitetura de software possa servir como um plano de projeto
usado para negociar requisitos de sistema e com um meio de estruturação de
discussões com os clientes, desenvolvedores e gerentes. Eles também sugerem que
é uma ferramenta essencial para o gerenciamento de complexidade. Ela oculta
detalhes e permite que os projetistas enfoquem as abstrações principais do sistema.
A arquitetura de sistema afeta o desempenho, facilidade de
distribuição e de manutenção de um sistema. O estilo e estrutura específicos
escolhidos para uma aplicação podem, portando, depender dos requisitos não
funcionais do sistema.
Desempenho: Sendo requisito crítico, a arquitetura deverá ser
projetada para localizar operações críticas dentro de alguns subsistemas. Podendo
significar o uso de componentesde alta granularidade em detrimento dos de baixa
granularidade para reduzir as comunicações entre os componentes.
Proteção: Sendo um requisito crítico, uma estrutura em camadas
para a arquitetura deve ser usada com os itens mais críticos protegidos por camadas
mais internas e com um alto nível de validação de proteção aplicado a essas
camadas.
Segurança: Sendo um requisito crítico, a arquitetura deve estar
projetada em um único subsistema ou em pequenos subsistemas, se tratando de
segurança isso reduz custos e o risco com problemas de validação de segurança,
tornando possível fornecer esse serviço a sistemas de proteção relacionados.
Disponibilidade: Sendo um requisito crítico, deve ser projetada para
15

16. incluir componentes redundantes, com isso substituir e atualizar componentes sem
para o sistema.
16

17. 15
Facilidade de manutenção: Sendo um requisito crítico, a arquitetura
de sistemas deve ser projetada usando componentes de baixa granularidade e
autocontidos que possam ser prontamente mudados, os criadores de dados devem
ser separados dos clientes e estruturas de dados compartilhadas devem ser
evitadas.
Obviamente
há
conflitos
potenciais
entre
algumas
dessas
arquiteturas, por exemplo aprimorando o desempenho e o uso de componentes de
baixa granularidade e aprimora a facilidade de manutenção.
Existe uma sobreposição significativa entre os processos de
engenharia de requisitos e projeto de arquitetura. Idealmente uma especificação de
sistema não deve incluir quaisquer informações de projeto. Na prática isto é irreal
exceto para sistemas pequenos.
Um projeto de subsistema é uma decomposição abstrata de um
sistema em componentes de alta granularidade, cada um dos quais podem ser um
sistema substancial e independente. Osdiagramas de blocos são frequentemente
usados para descrever projetos de subsistemas em que cada caixa no diagrama
representa um subsistema.
Figura 01 – Modelo abstrato de arquitetura
17

18. Na figura mostra um modelo abstrato de arquitetura para um sistema
robotizado de empacotamento que mostra os subsistemas que precisam ser
desenvolvidos, no mesmo pode empacotar diferentes tipos de objetos.
Dizem que diagramas simples de caixas e linhas são representações
úteis de arquitetura, pois eles não mostram a natureza dos relacionamentos entre os
componentes. Da perspectiva do projeto isto é correto, porém este tipo de modelo é
18

19. 16
eficiente para aproximação dos gerentes de sistema e para o planejamento de
projeto, pois não estão abarrotados de detalhes. Os gerentes por fazer parte do
projeto, podem ter uma visão abstrata do sistema.
Quanto ao problema que pode ocorrer na decisão como decompor
um sistema em subsistemas, deve se tentar criar um projeto em que corresponda a
escrita entre os requisitos e os subsistemas. Significando que se os requisitos
mudam as mudanças serão localizadas e não distribuídas entre os vários
subsistemas.
3.1.5.1 Decisões do Projeto de Arquitetura
Durante o processo de projeto de arquitetura, uma série de decisões
precisa ser tomada por seus arquitetos de sistema, essas serão fundamentais para o
processo de projeto de arquitetura, essas decisões são acerca de: estilos de
arquitetura; distribuição do sistema; modelos de sistema; abordagens para estruturar
o sistema, unidades estruturais do sistema e seus módulos; estratégias de controle,
avaliação e documentação do projeto.
Projeto de decisões de arquitetura, se trata de um processo criativo,
onde a organização de sistema satisfaça os requisitosfuncionais e não funcionais do
mesmo. Se tratando de um processo criativo, pode ter uma alteração radical de
acordo com o sistema que será desenvolvido, a origem e a experiência do arquiteto
do sistema e os requisitos específicos do sistema. Acaba-se pensando em projeto
de
arquitetura sobre perspectiva de decisões ao invés de perspectiva de atividade.
Durante o processo de projeto de arquitetura, precisa-se tomar uma série de
decisões fundamentais que afetam profundamente o sistema e seu processo de
desenvolvimento. Baseados em seus conhecimentos e experiências, precisam se
questionar com as seguintes questões:
1. Existe uma arquitetura genérica de aplicação que possa funcionar
como um modelo para o sistema que está sendo projetado?
2.
19

20. Como
o
sistema
será
distribuído
ao
longo
de
vários
processadores?
3. Qual ou quais estilos de arquitetura são apropriados para o
20

21. 17
sistema?
4. Qual será a abordagem fundamental usada para estruturar o
sistema?
5. Como as unidades estruturais de um sistema serão decompostas
em módulos?
6. Qual estratégia será usada para controlar a operação das
unidades no sistema?
7. Como o projeto de arquitetura será avaliado?
8. Como a arquitetura do projeto deve ser documentada?
Mesmo hoje em dia sendo diferentes projetos para cada um dos
softwares, um modelo de desenvolvimento é utilizado como base para criação de
novos softwares, se utilizando de conceitos fundamentais de domínio. As
arquiteturas de aplicações podem sem bastante genéricas como a arquitetura de
sistemas de gerenciamento de informações ou muito mais específicas. Por exemplo,
linhas de produtos de aplicações são criadas com base em um núcleode arquitetura
com variações que satisfazem os requisitos específicos do cliente.
Sistemasembutidos, normalmente projetados para computadores
pessoais, se utilizam de somente um processador e você precisará projetar uma
arquitetura distribuída para o sistema. No entanto em grandes sistemas, são
distribuídos por um número grande de computadores diferentes, a escolha da
arquitetura de distribuição é uma decisão importante que afeta o desempenho e a
confiabilidade do sistema.
A arquitetura de um sistema de software pode ser baseada em um
modelo ou estilo de arquitetura específico, porém nem sempre esta completamente
sendo criada em um padrão de arquitetura, em alguns desenvolvimentos, pode ser
utilizado diferentes tipos de desenvolvimento, nem sempre os grandes sistemas
desenvolvidos estão de acordo com um único estilo. Em alguns casos, a arquitetura
do sistema pode estar composta e criada por combinações e estilos diferentes.
Avaliação do projeto de arquitetura pode ser difícil, pois o verdadeiro
teste de arquitetura recai sobre quão bem ela atende os requisitos funcionais e não
funcionais depois de implantadas. Porém em alguns casos, pode de pesquisar
comparando seu projeto a modelos genéricos de arquitetura ou de referências.
21

22. Alguns pesquisadores propuseram o uso de linguagens de descrição
de arquiteturas para descrever arquiteturas de sistemas, utilizando linguagens
22

23. 18
especializadas ADLs, porém as informações descritas na arquitetura muitas vezes
eram somente decifradas pelos próprios pesquisadores sendo inacessíveis para
especialistas em domínios e aplicações. Isso faz com que elas sejam difíceis de
analisar com base em uma perspectiva prática, somente sendo utilizadas em uma
pequena parte das aplicações.
3.1.5.2 Organização de Sistema
A organização de um sistema reflete a estratégia básica usada paraestruturá-lo, o
modelo organizacional geral deve ser escolhido com antecedência, no
processo de projeto de arquitetura. A organização impacta diretamente na estrutura
do subsistema.
Reflete a estratégia básica usada para estruturá-lo. Necessita da
tomada de decisões sobre o modelo geral organizacional de um sistema com
antecedência no processo de projeto de arquitetura.
Existem três estilos organizacionais amplamente usados, são:
O MODELO DE REPOSITÓRIO:
Os Subsistemas que constituem um sistema devem trocar
informações de modo que possam trabalhar juntos eficientemente, duas maneiras
fundamentais pelo qual isso pode ser feito:
1. Todos os dados compartilhados, são mantidos em um banco de
dados que pode ser acessado por Subsistemas, denominado como modelo
repositório.
2. Cada subsistema mantém seu próprio banco de dados, os dados
são trocados pelos subsistemas que conversam entre eles.
A maioria dos sistemas que usam grandes quantidades de dados é
organizada por um banco de dados ou repositório compartilhado, esse modelo é
adequado para aplicações em que os dados são gerados por um subsistema e
usados em outro. Exemplos deste tipo de sistema incluem sistemas de comando de
23

24. 24

25. 19
controle, sistemas de informações gerenciais, sistemas CAD e os conjuntos de
ferramentas CASE.
Exemplo de uma arquitetura em ferramenta CASE:
Figura 02 – Modelo de repositório
As Vantagens e Desvantagens de se utilizar um repositório
compartilhado são:
1. Maneira eficiente de compartilhar grandes quantidades de dados.
2. Os subsistemas devem estar de acordo com o modelo de dados
do repositório, inevitavelmente, esse é um compromisso entre as necessidades
específicas de cada ferramenta.
3. Os Subsistemas que produzem dados não precisam saber comoesses dados são
usados por outros subsistemas.
4. A evolução pode ser difícil quando um grande volume de
informações é gerado de acordo com o modelo de dados estabelecidos.
5. As atividades como back-up, proteção, contro de acesso e
recuperação de erros são centralizados, sendo de responsabilidade do gerenciador
de repositório.
6. Subsistemas diferentes podem ter requisitos diferentes para
políticas de proteção, recuperação e back-up.
7. O modelo de compartilhamento fica visível por meio do esquema
de repositório.
8. Pode ser difícil se compartilhar o repositório por uma série de
máquinas, porém sendo possível distribuir um repositório logicamente centralizado,
podendo haver problemas com redundância e inconsistência de dados.
25

26. 20
O MODELO CLIENTE-SERVIDOR:
É um modelo em que o sistema é organizado como um conjunto de
serviços, servidores e clientes associados que acessam e usam estes serviços. Os
principais componentes desse modelo são:
Um conjunto de servidores que oferecem serviços para outros
sistemas, tais como servidores de impressão, servidores de arquivos, servidor de
compiladores.
Um conjunto de clientes que solicita os serviços oferecidos pelos
servidores.
Uma rede que permita aos clientes acessarem esses serviços. Na
prática, a maioria dos sistemas cliente-servidor é implementada como sistemas
distribuídos.
Os clientes talvez necessitem saber os nomes dos servidores
disponíveis e os serviços que eles fornecem. No entanto, os servidores não
precisam saber o nome dos clientes ou quantos deles existem. Essencialmente um
cliente faz um pedido a um servidor e espera até ter uma resposta.
A vantagem mais importante deste modelo é que ele é uma
arquitetura distribuída. O uso efetivo em rede pode ser feito com
muitosprocessadores distribuídos.
É fácil adicionar um novo servidor e fazer a integração do mesmo
com o restante do sistema ou atualizar servidores de forma transparente sem afetar
outras partes do sistema.
Figura 03 – Modelo Cliente-Servidor
26

27. 21
MODELO EM CAMADAS
O modelo em camadas, também chamado de modelo de máquina
abstrata, organiza um sistema em camadas, cada uma das quais fornecendo um
conjunto de serviços, onde cada camada pode ser imaginada como uma máquina
abstrata cuja linguagem de máquina é definida pelos serviços fornecidos pela
camada. Um exemplo de modelo em camadas é o modelo OSI.
A abordagem em camadas dá suporte ao desenvolvimento
incremental de sistemas. À medida que uma camada é desenvolvida, alguns
serviços fornecidos por essa camada podem ser disponibilizados para os usuários.
Uma desvantagem desta abordagem em camadas é que a
estruturação de sistemas dessa maneira pode ser difícil de realizar. O desempenho
também pode ser um problema devido aos vários níveis de interpretação dos
comandos algumas vezes exigidos. Caso tenha várias camadas, um pedido de
serviço de uma camada superior precisa ser interpretado várias vezes em camadas
diferentes antes de ser processado.
Figura 04 – Modelo em camadas
3.1.5.3 Estilos de Decomposição Modular
Após a escolha da organização geral do sistema é necessário tomar
decisões quanto a melhor abordagem a ser utilizada para a decomposição de
subsistemas em módulos. Esta decomposição pode ser orientada a objetos e
27

28. 22
pipelining orientado a funções.
É um outro nível de estrutura onde os subsistemas são decompostos
em módulos.
Dois modelos de decomposição modular podem ser usados um
modelo de objeto onde o sistema é decomposto em objetos que se comunicam.
Um modelo depipeline ou fluxo de dados onde o sistema é
decomposto em módulos funcionais que transformam entradas em saídas. Se
possível, decisões sobre concorrência devem ser postergadas até que os módulos
estejam implementados. Estruturar o sistema em um conjunto de objetos fracamente
acoplados com interfaces bem definidas.
A decomposição orientada a objetos está relacionada à identificação
de classes de objetos, aos seus atributos e às suas operações. Quando
implementados, os objetos são criados a partir dessas classes e um tipo de controle
é usado para coordenar as operações de objetos.
Decomposição orientada a objetos
A decomposição orientada a objetos é a técnica de escolha para a
construção de sistemas que devem ser extensíveis com novos tipos de dados. Mas
há também um outro possível modo para estender a expressão exemplo. Podemos
querer adicionar novas operações sobre expressões. Por exemplo, podemos querer
adicionar uma operação que imprime uma árvore-expressão para a saída padrão.
Se
definimos todos os métodos de classificação e acesso, tal operação pode ser
facilmente escrita como uma função externa.
Decomposição orientada a objetos clássica requer modificação de
todas as classes existentes quando um sistema for estendido com novas operações.
Figura 05 – Decomposição Orientada a Objetos
28

29. 23
Pipelining orientado a funções
Pipelining orientado a funções: um sistema é decomposto em
módulos funcionais que aceitam dados de entrada e transforma-os em dados de
saída.
Neste tipo de decomposição, também chamado de modelo de fluxo
de dados, as transformações funcionais processam suas entradas e produzem
saídas. Os dados fluem de uma para outra função e são transformados ao
moveremse sequencialmente. Cada etapa do processamento éimplementada como
uma
transformação. Os dados de entrada fluem através dessas transformações até
serem convertidos em saída. As vantagens dessa arquitetura são:
1. Ela é intuitiva, no sentido de que muitas pessoas pensam em seu
trabalho em termos de processamento de entrada e saída.
2. A evolução do sistema pela adição de novas transformações é
geralmente direta.
3. Ela é simples de ser implementada tanto quanto um sistema
concorrente ou sequencial.
Figura 05 – Decomposição Pipelining orientado a funções
3.1.5.4 Modelo de Controle
Os modelos de estruturação estão relacionados a um sistema
decomposto em subsistemas, já que para funcionar como sistemas os subsistemas
devem ser controlados de maneira que seus serviços possam ser entregues no
tempo e lugar corretos.
29

30. 24
Modelos estruturais não devem incluir informações de controle, o
arquiteto deve organizar os subsistemas seguindo o modelo de controle que
suplementa o modelo de estrutura utilizado.
Quanto aos modelos de controle genéricos há:
•
Controle centralizado;
•
Controle baseado em eventos.
Estes devem ser utilizados em conjunto com estilos de estrutura.
Os modelos de estruturação, estão relacionados a como um sistema
é decomposto em subsistemas. Para funcionar como um sistema, os subsistemas
devem ser controlados de maneira que seus serviços sejam entregues no lugar certo
e no tempo certo, os mesmos não incluem nem devem incluir informações de
controle.
Dois estilos genéricos de controles usados em sistemas de software
são:
Controle centralizado, que se responsabiliza no geral pelo controle e
inicia para outros sistemas.
Controle baseado em eventos, ao invés dos controles de
informações serem incorporados a um subsistema, cada subsistema pode responder
aeventos gerados externamente
Controle Centralizado:
Estilos arquiteturais relacionados com o fluxo de controle entre os
componentes
30

31. arquiteturais.
Controle
centralizado.
Um
subsistema
tem
responsabilidade global pelo controle e inicia e para outros sistemas. Um
componente
é
responsável
pelo
gerenciamento
da
execução
de
outros
componentes.
O estilo Chamada-Retorno:
31

32. Controle se inicia no topo de uma hierarquia de sub-rotinas e movese para baixo na
hierarquia, pode ser sequencial ou concorrente.
O estilo de gerenciador: Aplicável a sistemas concorrentes e de
tempo real. Um componente controla a parada, o início e a coordenação de outros
32

33. 25
processos de sistema.
Sistemas orientados a eventos:
É
um paradigma
de
programação.
Diferente
de
programas
tradicionais que seguem um fluxo de controle padronizado, o controle de fluxo de
programas
orientados
a
eventos,
são
guiados
por
33

34. indicações
externas,
chamadas eventos. Sua aplicação é grande no desenvolvimento de sistemas
de interface com o usuário.
Diferente de aguardar por um comando completo que processa a
informação, o sistema em tal paradigma é programado em sua base em um laço de
repetição de eventos, que recebem repetidamente informação para processar e
disparam uma função de resposta de acordo com o evento.
O método pelo qual a informação é adquirida por camadas mais
baixas
do
sistema
é
irrelevante.
As
entradas
podem
ser enfileiradas ou
uma interrupção pode ser registrada para reagir, ou ainda ambos.
Programas orientados a evento geralmente consistem em vários
pequenos tratadores, programas que processam os eventos para produzir
respostas,
34

35. e um disparador, que invoca os pequenos tratadores. Uma alternativa consiste em
disparar ostratadores por eles próprios, criando um efeito de evento em cascata.
Esse método é bastante flexível e permite um sistema assíncrono.
Programas com interface com o usuário geralmente utilizam tal paradigma. Sistemas
operacionais também são outro exemplo de programas que utilizam programação
orientada a eventos, este em dois níveis. No nível mais baixo encontram-se o
tratamento de interrupções como tratadores de eventos de hardware, com
a CPU realizando o papel de disparador. No nível mais alto encontram-se os
processos sendo disparados novamente pelo sistema operacional.
35

36. 26
Figura 06 – Modelo de controle chamada-retorno
Um interpretador de comandos pode ser visto como um caso
especial, de modelo orientado a eventos, no qual o sistema, até então inativo,
espera um comando para ser disparado através das instruções do usuário.
Figura 07 – Modelo de controle centralizado
Modelos de Broadcast: Nesses modelos, um evento é transmitido a
todos os subsistemas. Qualquer subsistema programado para manipular esse
evento pode responder a ele.
Modelos orientados a interrupções: Estes modelos são usados
exclusivamente em sistemas de tempo real nos quais interrupções externas são
detectadas por um tratador de interrupções. Estas são, então, passadas para alguns
outros componentes para processamento.
36

37. 27
Figura 08 – Modelo de controle baseado em broadcast seletivo
Figura 09 – Modelo de controle orientado a informações
3.1.5.5 Modelos de Referência
As arquiteturas de referência, não são utilizadas como um modelo
para implementação.
Esse modelo em geral é utilizado como um meio de discussão de
arquiteturas de domínio especifico e de comparação de sistemas diferentes em um
domínio.
Um modelo de referência pode, por exemplo, fornecer,um
vocabulário de comparação.
Em geral este modelo atua como uma base em relação a qual dos
sistemas podem ser avaliados.
3.1.6 Arquitetura de Sistemas Distribuídos
Em
geral
todos
os
sistemas
são
baseados
em
grandes
37

38. computadores, atualmente são baseados em sistemas distribuídos. O sistema
distribuído é aquele no qual as informações em fase de processamento podem ser
distribuídas para vários computadores, ao invés de estar confinado apenas a uma
38

39. 28
máquina.
Entre as vantagens do uso deste sistema pode-se destacar:
•
Compartilhamento de recursos;
•
Abertura;
•
Concorrência;
•
Escalabilidade;
•
Tolerância a defeitos.
Quanto às desvantagens:
•
Complexidade;
•
Proteção;
39

40. •
Gerenciamento;
•
Imprevisibilidade.
3.1.6.1 Arquitetura de Multiprocessadores
O modelo mais simples para um sistema distribuído é um
multiprocessador no qual o sistema de software consiste de uma série de processos
que podem ser executados em processadores separados, sendo este modelo mais
comum em sistemas de tempo real e grande porte.
3.1.6.2 Arquitetura de Cliente Servidor
Uma arquitetura cliente-servidor é modelada como um conjunto de
serviços fornecidos pelos servidores e um conjunto de clientes que usam esses
serviços, estes precisam ser informados quanto aos servidores disponíveis, porém
em geral, não sabem da existência de outros clientes.
3.1.6.3 Arquitetura de Objeto Distribuído
Uma arquitetura de objetos distribuídos pode ser utilizada como um
40

41. 29
modelo lógico para a estruturação e a organização de um sistema, onde os objetos
projetados são objetos de grande utilidade (ou objetos de negócios) que fornecem
serviços de domínio específico.
3.1.6.4 Computação interorganizacional Distribuída
Por conta da necessidadeproteção e da interoperabilidade a
computação distribuída foi implementada inicialmente em nível organizacional,
entretanto, atualmente modelos novos de computação distribuída foram criados
permitindo a computação interorganizacional distribuída ao invés da convencional
intra-organizacional.
3.1.7 Arquitetura de Aplicações
As
arquiteturas
de
aplicação
são
criadas
para
suprir
as
necessidades de negócio ou organizacionais, os sistemas de aplicações, embora
utilizados por organizações e objetivos diferentes tem muito em comum
3.1.7.1 Sistema de Processamento de Dados
Os sistemas de processamento de dados são sistemas de
41

42. processamento em lotes nos quais os dados são entrada e saída em lotes de
arquivo ou banco de dados ao invés de entrada e saída para um terminal de usuário.
Os dados são selecionados, dependendo do valor nos campos de registro para
tomada de ações especificas.
3.1.7.2 Sistema de Processamento de transações
Os sistemas de processamento de transações em geral são
utilizados para processar solicitações de informações por usuários em um banco de
dados ou solicitações para atualizar o banco de dados.
42

43. 30
3.1.7.3 Sistema de Processamento de Eventos
Os sistemas de processamento de eventos correspondem aos
eventos do ambiente ou da interface com o usuário do sistema. A principal
característica dos sistemas de processamento de eventos é que a sequência de
eventos é imprevisível e o sistema deve ser capaz de trabalhar com estes quando
ocorrerem.
3.1.7.4 Sistema de Processamento de Linguagem
Os sistemas de processamento de linguagem caracterizam-se por
aceitar linguagens naturais e artificiais como entrada e gerarem uma representação
diferente quanto à linguagem de saída.
3.1.8 Gerenciamento de Configurações
Osgerenciamentos
de
configuração
(CM
–
Configuration
Management) trata-se do desenvolvimento e do uso de padrões e procedimentos
para o gerenciamento de sistemas de software em fase de desenvolvimento.
3.1.8.1 Planejamento e Gerenciamento de Configurações
O planejamento e gerenciamento de configurações é responsável
por descrever os procedimentos e os padrões que deverão ser utilizados para o
gerenciamento, tendo como base para sua elaboração, um conjunto de padrões e
configurações que devem ser adaptados para atender aos requisitos de cada projeto
específico.
3.1.8.2 Gerenciamento de Mudanças
43

44. Procedimentos de gerenciamento de mudanças são voltados para a
análise de custo benefício das mudanças propostas à aprovação das mudanças
viáveis e da rastreabilidade dos componentes do sistema que sofrerem alterações.
44

45. 31
3.1.8.3 Gerenciamento de Versões e releases
Os processos envolvidos no gerenciamento de versões e releases
são realizados com o intuito de identificar e realizar a manutenção da rastreabilidade
das versões de um sistema.
3.1.8.4 Construção de Sistemas
A construção de um sistema trata-se de um processo de compilação
e ligação de componentes de software num programa que executa tais
configurações definidas.
3.1.8.5 Ferramentas CASE para gerenciamento de configurações
Quando um sistema é construído com base em versões de
componentes, um único erro de gerenciamento de configurações poderá indicar que
o software não poderá operar corretamente. A ferramenta CASE é essencial para o
gerenciamento de configurações, tendo sido utilizada desde 1970 para o
desenvolvimento de softwares que abranjam diferentes áreas de gerenciamento de
configurações.
45

46. 32
3.2 PROGRAMAÇÃO PARA WEB II
3.2.1 Comparação de Framework paradesenvolvimento Web (Java)
Quanto aos frameworks utilizados para o desenvolvimento WEB
sabe-se que:
Frameworks são projetados com a intenção de facilitar o desenvolvimento
de software, habilitando designers e programadores a gastarem mais tempo
determinando nas exigências do software do que com detalhes tediosos de
baixo nível do sistema. Especificamente em orientação a objeto (que é o
paradigma da Java), Framework é um conjunto de classes com objetivo de
reutilização de um design, provendo um guia para uma solução de
arquitetura em um domínio específico de software.(RAMOS, 2007, p. 3)
Alguns dos principais Frameworks
Java
para desenvolvimento
WEB são: JSF (Java Server Faces), Spring MVC, Struts 2 e Tapestry, e a
comparação dos mesmos pode ser observada na tabela a seguir.
46

47. 33
3.2.2 Custos/Benefícios dos Frameworks
Quanto ao uso de um framework pronto observa-se os seguintes
fatores:
Vantagens
Desvantagens
- Redução de custos
- Construir um framework é complexo
- Redução de time-to-market
- Re-uso não vem sozinho: deve ser planejado
- Motivos: Maximização de re-uso (análise,
- É mais complexo e demora mais fazer uma
design, código, testes)
aplicação tendo que construir um framework em
- Desenvolvedores se concentram em adicionar
vez de fazer a aplicação do zero
valor em vez de reinventar a roda
- Benefícios são realizados em longo prazo
- Menos manutenção
47

48. - Quem pode pensar em longo prazo quando se
- Fatoração de aspectos comuns a várias
está competindo "On Internet time"?
aplicações
- Poucas empresas
- Uso de herança permite corrigir todas as
- Uma empresa aeroespacial demorou anos para
aplicações com a troca de uma classe-mãe
fazer frameworks e começou a ter retorno na
- Mas cuidado com o"Fragile Base Class -
quarta missão
Problem" onde a troca da classe-mãe quebra as
-
filhas
desenvolvimento e criar novos incentivos
-
Estabilização
48

49. melhor
do
código
(menos
Precisa
modificar
o
processo
de
Vencer o "Not Made Here Syndrome"
defeitos) devido ao uso em várias aplicações
- Melhor consistência e compatibilidade entre
"The most profoundly elegant framework will
aplicações
never be reused unless the cost of understanding
-
Alavancagem
49

50. do
conhecimento
de
it and using its abstractions is lower than the
especialistas
programmer's perceived cost of writing them from
- Framework oferece uma forma de empacotar o
scratch" (Booch, Dr Dobb's Journal, 1994)
conhecimento de especialistas sobre domínios
de problemas
- Assim, não se perde o conhecimento com a
saída de especialistas e o conhecimento pode
ser
usado/estudado
sem
a
presença
do
especialista
- Resultado: criação de patrimônio estratégico da
50

51. empresa (Strategic Asset Building)
Fonte: Jacques, 2014, p. 1.
51

52. 34
3.2.3 Programação Java Web
Para executar um programa projetado para plataforma Java é
necessário a existência de dois componentes:
•
Máquina virtual Java;
•
Conjunto de bibliotecas de classe que disponibilizam um série de
serviços para esse programa.
“O pacote de software que contém a máquina virtual e esta biblioteca
de classes é conhecido como JRE (Java Runtime Environment).” (WIKIPÉDIA, 2015)
A figura a seguir demonstra a Plataforma Java:
Fonte: Wikipédia, 2015, p. 1.
52

53. 35
3.3 PROJETO
Modelo de Arquitetura: Modelo dinâmico.
Framework: Java
Funcionalidades e Aplicações: Sistema de processamento de dados
Padrão: Cliente servidor
Justificativa do projeto: A escolha quanto ao modelo de arquitetura
se deu pelo fato de o mesmomostrar a organização do sistema em processos em
tempo de execução, o framework as funcionalidades e o padrão foram observados
de acordo com as necessidade apresentadas pela China Town.
Ferramentas para a elaboração da fase de projeto:
•
Sistema central SAP;
•
Módulo SAP business Intellingence;
•
Hewllet-Packard;
•
Servidores: HP 9000 e HP Storage XP 128.
53

54. 36
4 CONCLUSÃO
A realização desta pesquisa foi de suma importância pois
possibilitou a integração dos conhecimentos quanto as disciplinas do semestre com
base no estudo de caso "Projeto de Implementação do ERP na China Telecom”,
possibilitando o conhecimento dos conceitos conexos ao contento do semestre
quanto a:
Disciplina “Engenharia e Projeto de Software”, apresentou-se os
conceitos relacionados as áreas de competência de acordo com o PMBoK quanto a:
risco, escopo, fornecedores e partes interessadas.
A atividade ainda realizou breves resenhas de capítulos do livro do
autor Sommerville (2009), com o intuito de possibilitar o entendimento de um trecho
do estudo de caso que afirma que para o desenvolvimento de software interno,
“levaria muito tempo e sairia muito caro” para a China Telecom, os capítulos
utilizados foram:
•
Projeto de Arquitetura;
•
Arquitetura de Sistemas Distribuídos;
•
Arquitetura de Aplicações;
•
Gerenciamento de Configurações; .
Na disciplina “Programação para Web II”, buscou-se realizar uma
54

55. comparação quanto ao uso de Framework para desenvolvimento Web Java.
Neste ainda foram relacionados os Custos/Benefícios quanto ao uso
de frameworks no desenvolvimento de aplicações Web.
Em “Projeto Orientado a Objetos”, demonstrou-se o modelo de
arquitetura apropriado para o suprimento dos pré-requisitos do sistema e quais os
Frameworks deveriamser adotados, bem como o padrão de criação e suas
funcionalidades.
55

56. 37
REFERÊNCIAS
JACQUES,
Phillipe
Sauvè.
Comparativo
Frameworks.
Disponível
em:<
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/porque.htm> . Acesso
em 5 de Maio de 2015.
RAMOS, José Yoshiriro Ajisaka. Comparação entre os principais Frameworks Java
para o desenvolvimento de aplicações WEB. Instituto de Estudos Superiores da
Amazônia (IESAM), Belém, 2007.
SOMMERVILE, Ian. Engenharia de Software. São Paulo: Pearson Education do
Brasil. 2010.
WIKIPÉDIA.
Plataforma
Java.
Disponível
56

57. em:http://pt.wikipedia.org/wiki/Plataforma_Java Acesso em 7 de Maio de 2015.
http://www.wthreex.com/rup/portugues/process/workflow/environm/co_iproj.htm
http://repositorio.roca.utfpr.edu.br/jspui/handle/1/492
http://www.mhavila.com.br/topicos/gestao/pmbok.html
http://www.beware.com.br/arquivos/Como_Elaborar_a_Estrutura_Analitica_de_um_
P
rojeto_Carlos_Magno_Xavier_2013.pdf
http://insecure.org/tools/tools-pt.html
http://www.activeinfo.com.br/tutos/tutorial_instalacao_java_windows.pdf
http://www.mhavila.com.br/topicos/java/tomcat.html
http://ges.dc.ufscar.br/graduacao/tutorial_criacao_projeto_web_eclipse.pdf
http://www.java.marcric.com/cursos/java-01/pages/004-instalandoeclipse.html
http://javasemcafe.blogspot.com.br/2011/05/jsf-20-componentes-primefaces-
221parte.html
http://www.activeinfo.com.br/tutos/tutorial_instalacao_java_windows.pdf
http://www.caelum.com.br/apostila-java-testes-jsf-web-
servicesdesignpatterns/introducao-ao-jsf-e-primefaces/#7-5-especificacao-e-
implementacaodojsf
57

58. 38
http://primefaces.org/documentation.html
http://repositorio.roca.utfpr.edu.br/jspui/handle/1/492
http://www.universidadejava.com.br/docs/introducaoaojavaserverfaces20
CAPITULO 11 – Projeto de Arquitetura
O projeto de arquitetura é primeiro estagio no processo de projetos. Diz o livro que ele idêntica
subsistemas e estabelece um framework para controlar a comunicação dos subsistemas,
subsistemas são sistemas grandes decompostos em subsistemas e que fornece algum conjunto de
serviços relacionados. Ele também representa uma ligação critica entre processos de engenharia de
projeto e requisitos.
três vantagens de projetar e documentar explicitamente uma arquitetura de software:
Comunicação de stakeholders: é uma apresentação em alto nível do sistema que enfoca a discussão
entre diferentes stakeholders.
Analise de sistemas: Tem profundo efeito sobre o sistema, mostra se o sistema pode atender aos
requisitos críticos como, confiabilidade, desempenho e facilidade de manutenção.
Reuso em larga escala:
Apoia o reuso em larga escala de sistemas que possuem arquiteturas de sistemas familiares.
A arquitetura de software serve para negociar requisitos de sistema e estruturar discussões com os
clientes, desenvolvedores e gerentes. É uma ferramenta essencial parra gerenciamento de
complexidade, ocultando detalhes e focando as abstrações principais do sistema. O estilo e estrutura
da aplicação dependem dos requisitos não funcionais do sistema, por exemplo:
Se o desempenho for um requisito crítico a aplicação deve localizar operações criticas dentro de
subsistemas e usar componentes de alta granularidade em detrimento dos de baixa granularidade
para reduzir a comunicação entre eles.
Se a facilidade de manutenção for um requisto crítico, a arquitetura de sistemas deve ser projetada
usando componentes de baixa granularidade e autocontidos que possam ser prontamente mudados.
Há conflitos potenciais entre algumas dessas arquiteturas, por exemplo se o desempenho que
necessita de alta granularidade e a facilidade de manutenção que necessita de baixa granularidade
forem ambos requisitos críticos terá que ser encontrada alguma solução eficaz.
Um projeto de subsistemas é decomposição abstrata de um sistema de componentes em alta
granularidade. Os diagramas de blocos são usados para representar um projeto de subsistemas.
Esses diagramas de blocos são bons para comunição entre stakeholders e para o planejamento do
projeto pois não estão abarrotados de detalhes, já para a arquitetura não são tão bons, pois não
mostram relacionamento entre os componentes do sistema.
O projeto de arquitetura tenta estabelecer uma organização de sistemas que satisfação os requisitos
funcionais e os não funcionais do sistema. Durante o processo de projeto de arquitetura os arquitetos
58

59. de sistemas devem responder a algumas perguntas:
Existe uma arquitetura genérica de aplicação que possa funcionar como um modelo para o sistema
que está sendo projetado?
Como o sistema será distribuído ao longo de vários processadores?
Qual ou quais estilos de arquitetura são apropriados para o sistema?
Qual será a abordagem fundamental usada para estruturar o sistema?
Como as unidades estruturais de um sistema serão decompostas em módulos?
Qual estratégia será utilizada para controlar a operação das unidades do sistema?
Como o projeto de arquitetura será avaliado?
Como a arquitetura do sistema deve ser documentada?
Ao Projetar uma arquitetura de sistemas, você precisa decidir o que seu sistema e classes mais
amplas de aplicação tem em comum, e decidir quanto conhecimento dessas arquiteturas de aplicação
você pode reusar. A arquitetura de um sistema de software pode ser baseada em um modelo ou
estilo de arquitetura especifico, Em alguns casos a arquitetura geral de um sistema pode ser uma
arquitetura composta.
Os modelos de arquitetura que podem ser desenvolvidos podem incluir:
Um modelo estático de estrutura que mostra os subsistemas ou componentes desenvolvidos como
unidades separadas.
Um modelo dinâmico de processo que mostra como o sistema esta organizado em processos em
tempo de execução.
A organização de um sistema refete a estratégia básica usada para estrutura-lo. Você precisa tomar
decisões sobre o modelo geral organizacional de um sistema com antecedência no processo de
projeto de arquitetura. A organização pode refletir diretamente na estrutura subsistema.
possuem três estilos de organizacionais amplamente usados:
Modelo de repositório
Os subsistemas que constituem um sistema devem trocar informações de mofo que possam trabalhar
juntos eficientemente.
Esse modelo é, portanto, adequado para aplicações em que os dados são gerados por um
subsistema e usados por outro.
O repositório é passivo e o controle é de responsabilidade dos subsistemas que o usam.
3 Modelo Cliente – Servidor
O modelo de arquitetura cliente – servidor é um modelo em que o sistem é organizado como um
conjunto de serviços e servidores e clientes associados que acessam e usam os serviços. Os clientes
talvez precisem saber os nomes dos servidores disponíveis e os serviços que eles fornecem. No
59

60. entanto os servidores não precisam saber a identidade do cliente ou quantos são. São acessados os
serviços por meio de chamadas remotas de procedimento usando um protocolo request–eply, o
cliente faz um pedido a um servidor e espera ate receber uma resposta.
A vantagem de um modelo cliente servidor é que ele é uma arquitetura distribuída. O uso efetivo de
sistemas em rede pode ser feito com muitos processadores distribuídos. É fácil adicionar um novo
servidor e integra-lo ao restante do sistema
4 O Modelo em Camadas
O modelo em camadas organiza um sistema em camadas, cada uma das quais fornecendo um
conjunto de serviços.
A abordagem em camadas apoia o desenvolvimento incremental de sistemas. A medida que uma
camada é desenvolvida alguns serviços fornecidos por essa camada podem ser disponibilizados para
os usuários. Essa arquitetura também é modificável e portável. Desde que sua interface permaneça
inalterada, uma camada poderá ser substituída por outra equivalente. Uma desvantagem da
abordagem em camadas é que a estruturação de sistemas dessa maneira pode ser difícil. As
camadas mais internas podem fornecer recursos básicos, como gerenciamento de arquivos,
necessários em todos os níveis.
O desempenho também pode ser um problema devido aos vários níveis de interpretação de
comandos algumas vezes exigidos.
5 Estilos de decomposição modular
Depois que a organização geral do sistema foi escolhida, precisa-se tomar uma decisão sobre a
abordagem a ser usada na decomposição de subsistemas em módulos.
Um modulo é normalmente um componente de sistema que fornece um ou mais serviços para outros
módulos. Ele faz uso de serviços fornecidos por outros módulos.existem duas estratégias principais
que você pode usar ao decompor um subsistema em módulos.
Decomposição orientada a objetos e pipelining orientado a funções.
Você deve evitar tomar decisões prematuras sobre a simultaneidade de um sistema.
6 DECOMPOSIÇÃO ORIENTADA A OBJETOS.
60

61. Um modelo de arquitetura orientado a objetos estrutura o sistema em um conjunto de objetos não
firmemente acoplados com interfaces bem definidas. Os objetos chamam serviços oferecidos por
outros objetos.
Uma decomposição orientada a objetos esta relacionada a classes de objetos, seus atributos e suas
operações. Quando implementados, os objetos são criados a partir dessas classes e algum modelo
de controle é usado para coordenar as operações de objetos. A vantagem é que implementação de
objetos pode ser modificada sem afetar outros objetos.
A desvantagem é que para usar serviços os objetos devem fazer referencia explicita ao nome e a
interface de outros objetos.
7 Pipelining orientado a funções
No pipelining orientado a funções ou modelo de fluxo de dados, as transformações processam suas
entradas e produzem saídas. Os dados fluem de uma para outra função e são transformados ao
moverem – se sequencialmente. Cada etapa é implementada como uma transformação.Os dados de
entrada fluem através dessas transações ate serem convertidos em dados se saída.
As vantagens dessa arquitetura são:
Apoiar o reuso de transformações.
Ele é intuitiva, muitas pessoas pensam em seu trabalho em termos de processamento de entrada e
saída.
A evolução do sistema pela adição de novas transformações é geralmente direta.
Ela é simples de ser implementada tanto quanto um sistema concorrente ou sequencial.
O principal problema é que ele necessita ser um formato comum para transferir dados que possa ser
reconhecido por todas as transformações.
Sistemas interativos são difíceis de escrever usando esse modelo por causa da necessidade de uma
sequencia de dados ser processada.
8 Modelos de controle
Os modelos de controle tem como objetivo controlar subsistemas de maneira que seus serviços
sejam entregues no lugar certo e no tempo certo.
61

62. Modelos de controle são usados em conjunto com estilos de estrutura. Todos os estilos de estrutura
que foi explicado podem ser implementados por meio de controle centralizado ou baseado em
eventos.
9 Controle centralizado.
Em modelo de controle centralizado, um subsistema é designado como controlado de sistema e tem a
responsabilidade pelo gerenciamento da execução de outros subsistemas. Modelos de controle
centralizados Dividem – se em duas classes, dependendo se forem executados sequencialmente ou
paralelamente.
O modelo chamado – retorno. O controle começa no topo da hierarquia de sub – rotina e , através de
chamadas de sub-rotinas, passa para os níveis mais baixos na arvore, são aplicados em modelos
sequenciais.
O modelo gerenciados. Aplicados em modelos concorrentes. Um sistema concorrente é projetado
como um gerenciador de sistema e controla o inicio, a parada e a coordenação de outros processos
do sistema.
Sistemas orientados a eventos.
As decisões dos modelos orientados a eventos são regidos pelos eventos gerados externamente. O
termo evento pode ser um sinal que pode assumir uma gama de valores ou uma entrada de comando
baseados em um menu.
Possuem dois modelos de controle orientados a eventos.
Modelos de broadcast. Nesse modelo, um evento é transmitido a todos os subsistemas. Qualquer
subsistema programado para manipular o evento pode responder a ele. A vantagem dessa
abordagem é que a evolução é relativamente simples, um novo subsistema para tratar classes
especificas de eventos pode ser integrado por meio do registro de seus eventos no tratador de
eventos. A desvantagem é que os sbsistemas não sabem se ou quando os eventos serão
manipulados.
Modelos orientados a interrupções. São usados em sistemas de tempo real como requisitos rigorosos
de tempo, nos quais as interrupções externas são detectadas por um trator de interrupções.A
vantagem dessa abordagem é que ela permite respostas muito rápidas aos eventos a serem
implementados. Sua desvantagem é a complexidade da programação e a dificuldade de validação.
10 Arquitetura de referencia
62

63. As arquiteturas de referencia não são geralmente consideradas um roteiro de implementações. Em
vez disso, sua principal função é ser um meio de discussão de arquiteturas de domínio especifico e
de comparação de sistemas diferentes em um domínio. Um modelo de referencia forenece um
vocabulário para comparação. Ele atua como uma base, em relação a qual os sistemas podem ser
avaliados.
Uma proposta de modelo de referencia é um modelo para ambientes CASE que identifica cinco
conjuntos de serviços que um ambiente CASE deve fornecer. Ele deve também fornecer recursos de
plug in para ferramentas CASE individuais que usam esses serviços. Os cincos níveis de referencias
são:
Serviços de repositório de dados. Estes serviços fornecem recursos para o armazenamento e o
gerenciamento de itens de dados e seus relacionamentos.
Serviços de integração de dados. Estes serviços fornecem recursos para o gerenciamento de grupos
ou para definição de relacionamentos entre eles.
Serviços de gerenciamento de tarefas, estes serviços fornecem recusros para a definição e
aprovação de modelos de processo.
Serviços de mensagem. Comunica ferramenta – Ferramenta, ambiente-ferramenta e ambiente –
ambiente.
Serviços de interface com o usuário. Este serviço fornecem recursos para o desenvolvimento de
interface com o usurio.
A finalidade dessa arquitetura de referencia é ser um meio de classificação e comparação de
ferramentas e ambientes CASE integrados.
CAPITULO 12 – Arquitetura de sistemas distribuídos
Um sistema distribuído é aquele em que as informações em fase de processamento são distribuídas
a vários computadores.
Vantagens de usar uma abordagem distribuída para desenvolvimento de sistemas.
1. Compartilhamento de recursos – Um sistema distribuído permite o compartilhamento de recursos
de hardware e software, como discos, impressoras, arquivos e computadores que estão associados
aos diferentes computadores de uma rede.
2. Abertura - permitem a equipamentos e software de diferentes fabricantes serem combinados, pois
são projetados com base em protocolos padrões.
3. Concorrência – vários processos podem operar ao mesmo tempo em diferentes computadores, e
podem (mais não precisam) conversar uns com os outros.
4. Escalabilidade – são escalonáveis a maneira que a capacidade de um sistema pode ser ampliada
pela adição de novos recursos para atender as demandas dos sistemas.
5. Tolerância a defeitos – pela disponibilidade de vários computadores e o potencial de duplicação de
informação significa que os sistemas distribuídos possam ser tolerantes a algumas falhas de
hardware e software.
63

64. Esses sistemas de distribuição comparados aos sistemas que operam com um processador ou com
um cluster de processadores podem ter algumas desvantagens como:
1. Complexidade - os sistemas distribuídos são mais complexos que os sistemas centralizados.
2. Proteção – o sistema pode ser acessado de vários computadores diferentes, e o trafego na rede
pode estar sujeita a interceptações.
3. Gerenciamento – os computadores do sistema podem ser de tipos diferentes e podem operar em
versões diferentes de sistemas operacionais. Defeitos em uma maquina podem se propagar a outra
maquinas com consequências inesperadas.
4. Imprevisibilidade – Como todos os usuários da web sabem, os sistemas distribuídos são
imprevisíveis em suas respostas. A resposta depende da carga total do sistema, sua organização e a
carga da rede. Como tudo isso pode mudar em um curto período de tempo, o tempo de resposta para
uma solicitação do usuário pode variar drasticamente de uma solicitação para outra.
Possuem dois tipos diferentes de arquiteturas de sistemas distribuídos:
1. Arquitetura cliente-servidor. É o sistema como um conjunto de serviços fornecidos aos
clientes que fazem uso desses serviços. Os servidores e clientes são tratados de maneiras diferentes
nesses sistemas.
2. Arquiteturas de objetos distribuídos. Podemos pensar no sistema como um conjunto de objetos que
interagem e cuja a localização é irrelevante. Não há distinção entre cliente e servidor.
Tanto a arquitetura cliente-servidor e a arquitetura de objetos distribuídos são amplamente usadas no
setor, mais a aplicação ocorre geralmente dentro de uma única organização. A organização é,
portanto, intra-organizacional.
1 Arquitetura de multiprocessadores
O multiprocessador São processos que podem ser executados separados. Esse modelo tomam
decisões usando essas informações e enviam sinais aos atuadores, que modificam o ambiente do
sistema. O uso de vários processadores aprimora o desempenho e a capacidade de recuperação do
sistema
2 Arquitetura cliente-servidor
Em um arquitetura cliente-servidor, uma aplicação é modelada como um conjunto de clientes que
usam esses serviços. Os clientes precisam estar informados sobre os serviços disponíveis, mas
geralmente não sabem da existência de outros clientes. Vários processos de serviços podem ser
executados em um único processador de serviço portanto não há mapeamento entre processos e
processadores de um sistema
O projeto de sistemas cliente-servidor deve refletir a estrutura lógica da aplicação que esta sendo
desenvolvida. Um exemplo é uma aplicação q esta dividida em 3 camadas: a camada de
64

65. apresentação, que se encarrega da apresentação de informações para o usuário e toda a interação
com o usuário. A camada de processos de aplicações se encarrega da
implementação da lógica da aplicação e a camada de gerenciamento de dados se encarrega de todas
as operações de banco de dados.
A arquitetura cliente-servidor mais simples denomina-se arquitetura cliente-servidor de duas
camadas, podem ter duas formas:
Modelo cliente-magro. O processamento e o gerenciamento de dados são realizados no servidor. O
cliente apenas executa o software de apresentação.
Modelo cliente-gordo. O servidor é responsável somente pelo gerenciamento de dados. O software do
cliente implementa a lógica da aplicação e as interações com o usuário do sistema.
Uma desvantagem do modelo cliente-magro é que ele impõe uma grande carga de processamento
sobre o servidor e a rede.
O modelo cliente-gordo faz uso dessa capacidade de processamento disponível e distribui o
processamento lógico de aplicação e a apresentação do cliente. O servidor é essencialmente um
servidor de transações que gerencia todas as transações do banco de dados.
Enquanto o modelo cliente-gordo distribui o processamento mais eficientemente do que um modelo
cliente-magro, o gerenciamento do sistema é mais complexo. A funcionalidade da aplicação é dividida
entre vários computadores. Quando o software precisa ser alterado, isso envolve reinstalação em
cada computador cliente, o que pode resultar em um custo significativo se houver centenas de
clientes no sistema.
O Problema com a abordagem cliente-servidor de duas camadas é que as três camadas lógicas,
devem ser mapeadas sobre dois sistemas de computador – o cliente e o servidor. Pode haver
problemas de escalabilidade e desempenho, se o modelo cliente-magro for
escolhido, ou problemas de gerenciamento de sistemas, se o modelo cliente-gordo for usado. Para
evitar esses problemas uma alternativa é usar o modelo cliente-servidor de três camadas.
Em alguns casos é melhor estender o modelo cliente-servidor de três camadas para uma variante
com varias camadas, na qual servidores adicionais são incorporados ao sistema.
3 Arquiteturas de objetos distribuídos
Nesse modelo os objetos podem ser distribuídos entre uma serie de computadores na rede e se
comunicam através de um middleware, que é chamado de requisitor de objetos. O Middleware
fornece uma inteface transparente continua entre os objetos. Ele fornece um conjunto de serviços que
permitem que os objetos se comuniquem e sejam adicionados e removidos do sistema. As vantagens
são:
Permite que o projetista do sistema postergue decisões sobre onde e como os serviços devem ser
fornecidos.
È uma arquitetura de sistema aberto que permite que novos recursos sejam adicionados.
65

66. Uma arquitetura de objetos distribuídos pode ser usada como um modelo lógico, que permite
estruturar e organizar o sistema.
Uma arquitetura de objetos distribuídos em lugar de uma arquitetura cliente-servidor é adequada para
esse tipo de aplicação por três razões:
O modelo lógico do sistema não é um dos fornecimentos de serviços em que existem serviços
distintos de gerenciamento de dados.
Pode adicionar bancos de dados ao sistema sem grande interrupções.
A maior Desvantagem é que elas são mais complexas do que sistemas cliente-servidor.
4 CORBA
Existem quatro elementos principais desse padrão:
1. um modelo de objeto para objetos de aplicações em que um objeto corba é um encapsulamento de
estado com uma interface bem definida em linguagem neutra descrita em um linguagem de definição
de interface.
2. Um requisitor de objetos que gerencia solicitações para serviços de objetos.
3. Um conjunto de serviços de objetos que são serviços gerais com probabilidade de serem
solicitados por muitas aplicações distribuídas.
4. Um conjunto de componentes comuns construídos sobre esses serviços básicos que podem ser
solicitados pelas aplicações.
O Corba considera um objeto como se fosse um encapsulamento de atributos e serviços, como é
normal em objetos.o Corba deve ter uma definição de interface separada que define atributos e
operações publicas do objeto. as interfaces são definidas por uma linguagem de definição de
interface padronizada independe de linguagem.
Os objetos corba tem um único identificador chamado de referencia de objeto interoperavel. Esse IOR
é usado quando um objeto solicita serviços de um outro objeto.
O requisitor de objetos conhece os objetos que estão solicitando serviços e suas interfaces. O ORB
cuida da comunicação entre os objetos.os objetos que se comunicam não precisam conhecer a
localização de outros objetos nem sobre sua implementação.
O objeto que fornece o serviço tem um esqueleto de IDL associado que liga a interface a
implementação dos serviços.
O corba foi desenvolvido desde 1980 e as versões recentes de corba foram simplesmente dedicadas
ao apoio aos objetos distribuídos.
Os padrões Corba incluem definições de interface
para uma grande variedade de componentes horizontais e verticais. Os componentes verticais são
66

67. componentes específicos de um domínio de aplicação. Os componentes horizontais são
componentes de propósito geral, como componentes de interface com o usuário.
5 COMPUTAÇÃO INTERORGANIZACIONL DISTRIBUIDA
Por motivo de segurança e interoperabilidade, a computação distribuída foi implementada inicialmente
em nível organizacional. Uma organização tem uma serie de servidores e distribui sua carga
computacional entre eles. Devido ao fato de eles estarem todos localizados dentro da mesma
organização, podem ser aplicados padrões e processos operacionais locais.
6 ARQUITETURAS PONTO A PONTO
São sistemas descentralizados em que as computações podem ser realizadas por qualquer nó da
rede, nenhuma distinção é feita entre clientes e servidores. O sistema global é projetado para
beneficiar-se da capacidade computacional e armazenamento disponíveis em uma rede de
computadores potencialmente grande.
Em principio, em sistemas ponto a ponto, todo nó de rede pode estar ciente a respeito de qualquer
outro nó, pode fazer conexões com ele e pode trocar dados com ele.
Em uma arquitetura descentralizada, os nos de rede não são simplesmente elementos funcionais,
mais também chaves de comunicação que podem guiar os sinais de dados e de controle de um nó
para o outro.
No entanto quando se recupera um documento, o nó que esta recuperando se torna visível para
outros.
7 ARQUITETURA DE SISTEMA ORIENTADO A SERVIÇOS
A essência de um serviço, é que o fornecimento dos serviços é independente da aplicação que usa o
serviço. Os
provedores de serviços podem desenvolver serviços especializados e oferecê-los a uma gama de
usuários de serviços de organizações diferentes.
A proposto WEB Service foi lançada pois o acesso de servidores web, era somente por meio de
navegar web, e o acesso direto aos repositórios de informações por outros programas não era
pratico.
Os três padrões fundamentais que possibilitam comunicação entre WEB SERVICES são:
SOP. Define uma organização para troca estruturada de dados entre WEB SERVICES.
WSDL. Define como as interfaces dos WEB services podem ser representadas.
UDDI. Este é um padrão de descobrimento que define como as informações de descrição do serviço
usadas pelos solicitantes do serviços para descobrir serviços, pode ser organizada.
Todos esses padrões são baseados em XML
67

68. CAPITULO 13 – Arquitetura de aplicações
1 sISTEMAS DE PROCESSAMENTO DE DADOS
Aplicações de processamento de dados.
São Aplicações voltados a dados. Elas Processam dados em lotes sem intervenções explicitas do
usuário durante o processamento. As Ações explicitas tomadas pela aplicação dependem dos dados
que são processados. Os sistemas de processamento em lotes são normalmente usados em
aplicações de negócios nas quais as operações similares são realizadas sobre uma grande
quantidade de dados. Eles tratam de uma grande variedade de funções administrativas, como folha
de pagamento, cobrança, contabilidade e publicidade. Essas aplicações enfocam os dados. Os
bancos de dados são geralmente maiores que os sistemas de informações (SI).
Os sistemas de processamento de dados
selecionam os dados de registros de entrada e, dependendo do valor dos campos nos registros,
tomam algumas ações especificadas no programa. Eles podem, então, enviar o resultado novamente
do processamento ao banco de dados e formatar a entrada e a saída processada para impressão.
Os sistemas de processamento de dados possuem 3 componentes principais:
1 Entrada. A entrada coleta as entradas de uma ou mais fontes.
2 processamento. O processamento realiza a computação usando essas entradas.
3 saída. A saída gera Saídas a serem escritas novamente no banco de dados e ou impressas.
Os componentes de entrada , processamento e de saída podem ser decompostos ainda em uma
estrutura entrada-processamento-saída. Exemplo:
Um componente de entrada pode ler algum dado de um arquivo ou banco de dados(entrada) e
corrigir alguns erros (processo) e, depois enfileirar os dados validos para processamento (saída)
São sistemas orientados a funções, pois os registros e as transações são processados em serie, sem
necessidade de manter o estado entre as transações.
2 sistemas de processamente de transações
Os sistemas de transações são projetados para processar solicitações de informações por usuários
de um banco de dados. Tecnicamente uma sequencia de operações é tratada como uma unidade
simples (uma unidade atômica). Todas as operações tem que ser realizadas antes que as mudanças
tornem-se permanentes no banco de dados.
Os sistemas de processamento de transações são geralmente sistemas interativos nos quais os
usuários enviam solicitações assíncronas de serviço. Primeiro um usuário faz
68

69. uma solicitação para o sistema através de um componente de processamento de entrada/saída. A
solicitação é processada por alguma lógica especifica da aplicação. Uma transação é criada e
passada para um gerenciador de transações, que é em geral incorporado ao sistema de
gerenciamento de banco de dados. Depois que o gerenciador de transações assegurar que a
transação foi concluída adequadamente, ele sinalizara para a aplicação que o processamento foi
finalizado.
A estrutura entrada-processo-saída se aplica aos muitos sistemas de processamento de transações.
Alguns desses sistemas são versões interativas de sistemas de processamento de lotes.
Um exemplo de sistema de processamento de transações é um sistema bancário que permite aos
clientes consultarem suas contas e retirarem dinheiro de um caixa eletrônico. O sistema é composto
de dois subsistemas de software que cooperam entre si – o software de caixa eletrônico e o software
de processamento de contas localizadas no servidor de banco de dados. Os subsistemas de entrada
e de saída são implementados como softwares no caixa eletrônico, uma vez que o subsistema de
processamento está no servidor de banco de dadso.
Em sistemas como os de contabilidade de clientes de um banco, pode haver diferentes maneiras de
interagir com o sistema. Muitos clientes interagirão por meio de caixas eletrônicos, mas uma equipe
do banco usara terminais de mesa para acessar o sistema. Pode haver vários tipos de caixas
eletrônicos e terminais de mesa, e alguns clientes e a equipe do banco podem acessar os dados de
contas por meio de navegadores WEB.
Para simplificar o gerenciamento de diferentes protocolos de comunicação entre terminais, sistemas
de processamento de transações de larga escala podem incluir middleware para comunicação com
todos os tipos de terminal, organização e ordenação em serie dos dados dos terminais e envio dos
dados para processamento.
3 Sistemas de gerenciamento de informações e recursos
Um sistema de informações permite acesso controlado de uma grande base de informações, tais
como catalogo de bibliotecas, tabela de horários de voos ou registros de pacientes em um hospital. O
desenvolvimento da WEB fez com que um grande numero de sistemas de informações migrasse de
sistemas organizacionais especializados para sistemas de propósito geral acessíveis universalmente.
O sistema de informação é modelado com o uso de uma abordagem de camadas ou de maquina
abstrata na qual a camada superior apoia a interface com o usuário e a camada inferior, o banco de
dados de sistema. A camada de comunicações inclui uma lógica especifica de aplicação para acesso
e atualização do banco de dados.
Sistemas de alocação de recursos são uma classe de aplicação amplamente usada. Sua arquitetura
esta alinhada com o modelo de sistema de informações. Os componentes de um sistema de alocação
de recursos inclui:
1- um banco de dados de recursos que mantém detalhes de recursos que são alocados. Os recursos
podem ser adicionados ou removidos do banco de dados.
2- Um conjunto de regras que descreve as regras de alocação de recursos.
69

70. 3- um componente de gerenciamento de recursos que permite que o provedor de recursos adicione,
edite ou elimine recursos do sistema.
4- um componente de alocação de recursos que atualiza o banco de dados de recursos quando eles
são designados e que associa esse recursos a detalhes do solicitante do recurso.
5- um modulo de autenticação de usuários que permite ao sistema verificar se os recursos estão
sendo alocados para um usuário reconhecido.
6- um modulo de gerenciamento de consultas que permite ao usuário descobrir quais recursos estão
disponíveis.
7- um componente de entrega de recursos que prepara os recursos a serem entregues ao solicitante.
Em um sistema de emissão de ingressos, isso pode envolver a preparação de uma confirmação por
e-mail, o envio de uma solicitação para uma impressora que imprime os ingressos e os detalhes de
para onde os ingressos devem ser enviados.
8- um componente de interface com o usuário que esta fora do sistema e permite ao solicitante do
recurso enviar consultas e solicitações para o recurso a ser alocado.
4 Sistemas de processamento de eventos
O sistemas de processamento de eventos respondem aos eventos do ambiente ou da interface com o
usuário do sistema. A principal característica dos sistemas de processamento de eventos é que a
sequencia de eventos é imprevisível e o sistema deve ser capaz de trabalhar com esses eventos
quando eles ocorrerem.
Sistemas de tempo real, são também sistemas de processamento baseados em eventos, porem ao
invés de ter eventos de interface com o usuário, tem eventos associados a sensores e atuadores do
sistema.
5 Sistemas de processamento de linguagens
Os sistemas de processamento de linguagens aceitam uma linguagem natural ou artificial como
entrada e geram alguma outra representação
dessa linguagem como saída. Em engenharia de software, os sistemas de processamento de
linguagens mais amplamente usados são os compiladores que traduzem uma linguagem artificial de
programação de alto nível em código de maquina. Mais outros sistemas de processamento de
linguagens traduzem uma descrição de dados XML em comandos para consultar um banco de dados
e sistemas de processamento de linguagem natural que tentam traduzir uma linguagem em outra.
Os tradutores em um sistema de processamento de linguagens tem uma arquitetura genérica que
inclui os seguintes componentes:
1. Um analisador léxico, que obtém elementos da linguagem de entrada e os converte em um formato
interno.
2. uma tabela de símbolos que mantém informações sobre os nomes de entidades (variáveis, nomes
de classes.) usadas no texto que esta sendo traduzido.
70

71. 3. um analisador sintático, que verifica a sintaxe da linguagem que está sendo traduzida. Ele usa uma
gramática definida de linguagem e constrói uma arvore de sintaxe.
4. ume árvore de sintaxe, que é uma estrutura interna que representa o programa que esta sendo
compilado.
5. um analisador semântico, que usa informações da árvore de sintaxe e da tabela de símbolos para
verificar a correção sintática do texto da linguagem de entrada.
6. um gerador de código que ‘caminha’ pela árvore de sintaxe e gera o código de maquina abstrata.
capitulo 29 – gerenciamento de configurações
Gerenciamento de configurações é o desenvolvimento e o uso de padrões e procedimentos para o
gerenciamento de sistemas de software em desenvolvimento.Ha muitas razões Por que os sistemas
existem em diferentes configurações. Configurações podem ser produzidas para diferentes
computadores, para diferentes sistemas operacionais, incorporando funções especificas de clientes.
Os gerentes de configurações são responsáveis por manter a rastreabilidade das diferenças entre
versões de software, para assegurar que as novas versões sejam derivadas de maneira controlada e
liberar novas versões para clientes certos no momento certo.
1 Planejamento de gerenciamento de configurações
O plano de gerenciamento de configurações descreve os padrões e procedimentos que devem ser
usados para o gerenciamento. O ponto de partida para o desenvolvimento do plano deve ser um
conjunto de padrões de configuração, que devem ser adaptados para se atender aos requisitos e as
restrições de cada projeto específico.
1 IDENTIFICAÇÃO DE ITEM DE CONFIGURAÇÃO
Em um grande sistema de software, pode haver módulos de milhares de códigos fonte, scripts de
testes, documentos de projeto etc. Eles são produzidos por pessoas diferentes e, quando criados,
podem ser denominados com nomes similares ou idênticos. Para manter a rastreabilidade de todas
essas informações de maneira que o arquivo certo possa ser encontrado quando for necessário você
necessita de um esquema de identificação consistente para todos os itens no sistema de
gerenciamento de configurações.
Durante o processo de planejamento de gerenciamento de configuração, você decide exatamente
quais itens serão controlados. Planos de projetos, especificações, projetos, programas, e massa de
dados de teste são normalmente mantidos como itens de configuração. Todos os documentos que
podem seruteis para a evolução futura do sistema devem ser controlados pelo sistema de
gerenciamento de configuração.
O esquema de identificação de itens de configuração deve atribuir um único nome para todos os
documentos sob controle de configuração. Esse nome pode refletir o tipo do item, uma parte do
71

72. sistema ao qual ele se aplica, o criador do item. No esquema de atribuição de nomes, você pode
desejar evidenciar a relação entre os itens para garantir que os documentos relacionados possuam
uma mesma raiz em seus nomes. Portanto, você pode definir um esquema de hierarquia com nome.
Esquemas de nomes hierarquizados são simples e de fácil compreensão: algumas vezes, podem
mapear uma estrutura de diretórios usada para armazenar arquivos de projeto. No entanto, refletem a
estrutura de projeto na qual o software foi desenvolvido. Os nomes de itens de configuração associam
componentes com um projeto especifico e, dessa maneira, reduzem as oportunidades para o reuso.
Pode ser muito difícil encontrar componentes relacionados.
2 BANCO DE DADOS DE CONFIGURAÇÃO
O banco de dados de configuração é utilizado para registrar todas as informações relevantes sobre as
configurações de sistema e os itens de configuração. Você usa o banco de dados CM para auxiliar a
avaliação do impacto das mudanças de sistema e para gerar relatórios para a gerencia sobre o
processo de CM. Como parte do processo de CM, deve-se definir o esquema do banco de dados de
CM, os formulários para coletar informações para serem registradas no banco de dados e
procedimentos para registro e recuperação de informações de projeto.
Um banco de dados de configuração pode registrar informações sobre usuários de componentes,
clientes de sistemas, plataformas de execução, mudanças propostas e etc.
De preferência, um banco de dados de configuração deve ser integrado com a versão do sistema de
gerenciamento usada para armazenar e gerenciar os documentos formais do projeto.
Um banco de dados de configuração armazena informações sobre itens de configuração e referencia
seus nomes num sistema de gerenciamento de versão ou depósito de arquivos.
2 Gerenciamento de mudanças
As necessidades e requisitos organizacionais alteram-se durante a vida útil de um sistema. Isso
significa que você precisa fazer as mudanças correspondentes no sistema de software. Para garantir
que essas mudanças serão aplicadas ao sistema de maneira controlada, você precisa de um conjunto
de procedimentos de gerenciamento de mudanças apoiado por ferramentas.
Procedimentos de gerenciamento de mudança dizem respeito a analise de custo e beneficio das
mudanças propostas, a aprovação das mudanças viáveis e a rastreabilidade de quais componentes
do sistema foram alterados. O processo de gerenciamento de mudança deve surtir efeito quando o
software ou a documentação associada são colocados em baseline pela equipe de gerenciamento de
configurações.
O primeiro estágio no processo de gerenciamento de configurações é completar um formulário de
solicitação de mudança (CRF – change request form) que descreve a mudança necessária para o
sistema. Uma vez que o formulário de solicitação de mudança é enviado, ele deve ser registrado no
banco de dados de configuração. A solicitação de mudança é então analisada para verificar se a
mudança solicitada é necessária.
72

73. Para mudanças validas, o estagio seguinte é a avaliação da mudança e o custo. O impacto da
mudança no restante do sistema deve ser verificado. Isso envolve todos os componentes afetados
pela mudança. Se realizar a mudança significa que mudanças adicionais em alguma parte do sistema
são necessárias, isso aumenta claramente o custo de sua implementação. Em seguida as mudanças
necessárias para os módulos do sistema são avaliadas. Finalmente, o custo para realizar a mudança
é estimado, considerando os custos de mudança nos componentes relacionados.
3 gerenciamento de versões e releases
Os processos envolvidos no gerenciamento de versões e relases preocupam-se com a identificação e
a manutenção da rastreabilidade das versões de um sistema. Gerentes de versões idealizam
procedimentos para assegurar que as versões de um sistema possam ser recuperadas quando
solicitadas e não sejam alteradas acidentalmente pela equipe de desenvolvimento. Para produtos, os
gerentes trabalham com a equipe de marketing, e , para sistemas feitos sob encomenda, com os
clientes, para planejar quando novos releases de um sistema devem ser criados e distribuídos para
implantação.
Um release do sistema é uma versão distribuída aos clientes. Cada release deve incorporar novas
funcionalidades ou ser planejado para uma plataforma diferente de hardware.
1 IDENTIFICAÇÃO DE VERSÕES
Para criar uma versão especifica de um sistema, você precisa especificar as versões dos
componentes de sistema que devem ser incluídas nele. Você não pode usar o nome do item de
configuração para identificar a versão, porque ele pode ter muitas versões para cada item
de configuração identificado.
A três técnicas básicas para identificação da versão de componentes.
1. Numeração de versões. O componente recebe um numero explicito e único de versão. Isso é o
mais comumente usado no esquema de identificação.
2. identificação baseada em atributos. Cada componente tem um nome (como o nome do item de
configuração, que não é único para diferentes versões) e um grupo de atributos associados para cada
versão, componentes são portanto, identificados pela especificação de seus nomes e valores de
atributos.
3. identificação orientada a mudanças. Cada componente é denominado como na identificação
baseada em atributos, mas é também associado com uma ou mais solicitações de mudanças. Ou
seja, considera –se que cada versão de componente foi criada em resposta a uma ou mais
solicitações de mudanças. A versão de componente é identificada pelo conjunto de solicitações de
mudanças que se aplicam ao componente.
2 GERENCIAMENTO DE RELEASES
73

74. Um release de sistema é uma versão do sistema distribuído para os clientes. Os gerentes de release
de sistemas são responsáveis por decidir quando um sistema pode ser liberado para os clientes,
gerenciar o processo de criação do release e de meios de distribuição e documentar o release para
assegurar que ele pode ser recriado exatamente como foi distribuído, se for necessário.
A criação de um release é um processo de criação de arquivos e documentos que inclui todos os
componentes do release do sistema. O código executável de programas e todos os arquivos de
dados associados devem ser coletados e identificados. Se os manuais a serem lidos em
computadores são distribuídos, copias eletrônicas devem ser armazenadas com o software.
Finalmente, quando todas as informações estiverem disponiveis, o diretório do release é manipulado
para a distribuição.
Quando um release de sistema é produzido, ele deve ser documentado para assegurar que possa ser
recriado ipsis literis no futuro. Isso é importante para sistemas embutidos de ciclo de vida longo e
feitos para os clientes, como aqueles que controlam maquinas complexas.
Para documentar um release você deve registrar as versões especificas dos componentes de código
fonte usados para criar o código executável. Você deve manter compias dos códigos fonte e código
executável, e de todos os arquivos de dados e de configuração. Você deve também registrar as
versões do sistema operacional, as bibliotecas, os compiladores e outras ferramentas usadas para
construir o software. Elas podem ser necessárias para construir exatamente o mesmo sistema em
alguma data posterior.
4 construção de sistemas
A construção de sistemas é um processo de compilação e ligação de componentes de software num
programa que executa determinada configuração definida. Quando você esta construindo um sistema
com base em seus componentes, você deve pensar nas seguintes questões:
1. Todos os componentes que compõem um sistema foram incluídos nas instruções de construção?
2. A versão apropriada de cada componente necessário foi incluída nas instruções de construção ?
3. todos os arquivos de dados necessários estão disponíveis?
4. Se os arquivos de dados estão referenciados dentro de um componente, o nome usado é o mesmo
que o do arquivo de dados na maquina – alvo?
5. A versão apropriada do compilador e de outras ferramentas requeridas esta disponível? As versões
atuais das ferramentas de software podem ser incompatíveis com as versões antigas usadas para
desenvolver o sistema.
5 ferramentas case para gerenciamento de configurações
Processos de gerenciamento de configurações são normalmente padronizados e envolvem
aplicações de procedimentos predefinidos. Eles requerem o gerenciamento cuidadoso de grande
quantidade de dados e é essencial a atenção aos detalhes. Quando um sistema está sendo
construído com base em versões de componentes, um único erro de gerenciamento de configuração
74

75. pode significar que o software não irá operar adequadamente. Consequentemente, o apoio de um
ferramenta CASE é essencial para o gerenciamento de configuração. Essas ferramentas podem ser
combinadas para criar uma área de trabalho para apoiar todas as atividades de CM.
REFERÊNCIAS
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edição. São Paulo: Pearson Addison Wesley,
2007.
Gilmar Machado
Nivel 0
Mensagens: 9
Data de inscrição: 04/03/2014
Idade: 42
Localização: Rondônia
75

76. 4 CONCLUSÃO
Conclui-se que, durante esse trabalho foi possível entender ainda
mais sobre a elaboração de projetos de software, a necessidade de escolha de um
ciclo de vida mais apropriado, o desenvolvimento de cronogramas e WBS. Também,
como a necessidade dos clientes fica cada vez mais complexa, o projeto deve ser
bem desenvolvido, evitando retrabalhos e a segurança deve ser sempre considerada
como aspecto muito importante.
76

77. REFERÊNCIAS
TIESPECIALISTAS. WBS, uma ferramenta importante para o Gerente de
projetos. Disponível em: http://www.tiespecialistas.com.br/2010/11/wbs-
%E2%80%93-uma-ferramenta-importante-para-o-gerente-de-projetos/. Acesso em
02 de abril de 2014.
WIKIPEDIA. Estrutura analítica de projeto. Disponível em:
http://pt.wikipedia.org/wiki/Estrutura_anal%C3%ADtica_do_projeto Acesso em: 01 de
abril de 2014.
77