Aula15Projeto Arquitetural

Projeto e Implementação:
Projeto Arquitetural (I)

Prof. Lucinéia H. Thom
INF01127 ‐ Engenharia de Software N
Relembrando
• Atividades genéricas em todos os processos de
desenvolvimento de software
– Especificação
• O que o sistema deve fazer e suas restrições de desenvolvimento
– Requisitos
– Identificação, expressão, verificação
– Desenvolvimento
• Produção do sistema de software que atenda aos requisitos
identificados
– Análise
– Projeto
– Implementação
– Validação & Verificação
• Certificação de que o software está correto e é o que o cliente
deseja
13/06/2016 lucineia@inf.ufrgs.br 2
Projeto e Implementação
PROJETO DE SOFTWARE
Projeto
• Especificação de requisitos dizem O QUÊ o
sistema deve fazer
• Projeto trata de COMO o sistema fará isto
– Decomposição do sistema
– Determina como
• requisitos funcionais serão atingidos
• dentro das restrições dos requisitos não funcionais
– Define plataformas e tecnologias
– Permite dividir o trabalho entre uma equipe de
desenvolvedores
Projeto
1. O caso de uso inicia quando o
cliente informa um termo de busca
2. O sistema exibe todos os produtos
cujo nome ou descrição contenham
aquele tema (exibir foto, preço,
etc.) ...
Projeto
1. O caso de uso inicia quando o
cliente informa um termo de busca
2. O sistema exibe todos os produtos
cujo nome ou descrição contenham
aquele tema (exibir foto, preço,
etc.) ...
Produto
codigo
*
CTRLPesquisa nome
IUPesquisa
descricao
preco
estoque
...
1. O caso de uso inicia quando o cliente informa um
termo de busca
Projeto 2. O sistema exibe todos os produtos cujo nome ou

descrição contenham aquele tema (exibir foto,
preço, bla, bla …
RNF
- Plataforma web
- Browser IE, Forefox, Safari
- Desk/Laptop e tablet
- 90% das pesquisas com tempo de resposta inferior
a 1 s.
- MTF de 5 minutos
- 10.000 usuários simultâneos
- Interface intuitiva, sem treinamento prévio
- etc ….
Projeto – Níveis
• Arquitetural (high level design)
– Estrutura principal
• Sistemas e subsistemas
• Interfaces e dependências
– Cobre a essência dos principais casos de uso
– Atende os requisitos não funcionais
– Uma vez definido, tende a ser mais estável
• Projeto detalhado (low level design)
– Estrutura interna em termos de componentes
– Leva em conta características/idiossincrasias de linguagens
de programação
– Detalhado o suficiente para guiar/facilitar a
implementação
Projeto
Sommerville
Projeto: Por que é tão difícil?
• Análise
– Foca no domínio da aplicação
• Projeto
– Foca no domínio da solução
– Dependente de conhecimento e experiência
– Plataformas tecnológicas têm vida curta
• 3‐5 anos
• Novas linguagens, novos frameworks, novos serviços, novos paradigmas
• Considerações que justificaram uma escolha mudam com a evolução tecnológica
– e.g. Desempenho, produtividade, testabilidade
– Janela de tempo
• Tempo disponível para decisões
• Levam em conta o que se sabe (até o momento) e o que se prevê
– Conhecimento das características do projeto e suas consequências evolui
• Evolução
• Projetar para acomodar mudanças
Projeto – Objetivos
• Reliability • Good documentation
• Modifiability (confiabilidade) • Well‐defined interfaces
• Maintainability • User‐friendliness
• Adaptability • Reuse of components
• Reusability • Rapid development
• Efficiency • Minimum # of errors
• Portability • Readability
• Traceability of requirements • Ease of learning
• Fault Tolerance • Ease of remembering
• Backward‐compatibility • Ease of use
• Cost‐effectiveness • Increased productivity
• Robustness • Low‐cost
• High‐performance • Flexibility
Fonte: Kostas Kontogiannis
Projeto – Objetivos: Relações
Fonte: Kostas Kontogiannis
Projeto – Objetivos
• Eficiência vs. Portabilidade (a facilidade de
transferir software entre ambientes operacionais)
• Custo vs. Robustês (habilidade de um software
funcionar mesmo em condições anormais)
• Funcionalidade vs. Usabilidade
• Desenvolvimento rápido vs. Funcionalidade
• Custo vs. Reusabilidade
• Reuso
• Etc.
Eficiência vs. Portabilidade
Eficiência Interoperabilidade
• Uso dos recursos em tempo de • Um software frequentemente
execução, e seus impactos em deve interagir com outros
termos de tempo de resposta sistemas que formam seu
e consumo de memória ambiente
• Mais do que algoritmos • Arquiteturas que lidem com as
sofisticados, eficiência tem a dificuldades técnicas de
ver com a equilibrada componentes desenvolvidos para
distribuição de diferentes
responsabilidades, e o linguagens/plataformas
acoplamento entre • Oferecer acessos bem definidos a
componentes funcionalidades que devem ser
• Eficiência é frequentemente observáveis externamente
contraditória com outras • Exemplo
propriedades
– Computador/celular/embarcado
Projeto e Implementação
PROJETO ARQUITETURAL
Arquitetura de Software
• Sem definição consensual
– http://www.sei.cmu.edu/architecture/definitions.html
• Duas definições modernas
– "The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
elements, the externally visible properties of those elements, and the
relationships among them.”
[Bass et al., 2003]
– “The fundamental organization of a system, embodied in its
components, their relationships to each other and the environment,
and the principles governing its design and evolution.”
[IEEE, 2000]
• E ainda
– 9 definições “clássicas”, 18 definições nos livros, 100+ definições
adotadas pela comunidade…
13/06/2016 lucineia@inf.ufrgs.br 16 16
• Dois níveis de abstração
– Architecture in the small
• Lida com a arquitetura de programas individuais
• Programa decomposto em componentes
– Architecture in the large
• Lida com a arquitetura de sistemas complexos
(enterprise systems)
– Incluem outros sistemas, programas componentes
• Sistemas
– Distribuídos em diferentes computadores
– Pertencem e são gerenciados por diferentes empresas
• Todo sistema TEM uma arquitetura
– Mesmo que não documentada ou não conhecida
• Vantagens de um projeto e documentação
explícita
– Comunicação com stakeholders
– Análise do sistema
– Reuso em larga escala
• Tópico de pesquisa
– Architecture Recovery and Discovery
Decisões de Arquitetura
• Existe uma arquitetura genérica de aplicação que pode atuar como
um template para sistema sendo projetado?
• Como o sistema vai ser distribuído em uma série de núcleos ou
processadores?
• Que padrões ou estilos arquiteturais serão usados?
• Qual será a abordagem fundamental usada para estruturar o
sistema?
• Como componentes estruturais do sistema serão decompostos em
subcomponentes?
• Que estratégia será usada para controlar a operação de
componentes no sistema?
• Que organização arquitetural é melhor para estar de acordo com os
requisitos não funcionais?
• Como o projeto arquitetural será avaliado?
• Como a arquitetura do sistema deve ser documentada?
Projeto Arquitetural: Atividades Genéricas
• Decisões estratégicas de alto nível
– Estruturação de sistema
• Sistema decomposto em vários subsistemas principais
• Comunicação entre esses subsistemas é identificada
– Modelagem de controle
• Estabelecimento de um modelo geral dos relacionamentos de
controle entre as partes do sistema
– Decomposição modular
• Subsistemas identificados são decompostos em módulos
• Projetista deve decidir sobre o tipo de módulo e suas interconexões
• Arquitetura de software precisa ser mantida consistente no
desenvolvimento de software
– Capacidade de evoluir com o software e seu desenvolvimento
– Compreensível pela equipe
Decomposição de Sistemas
• Subsistemas
– UML: Subsistema, Pacote, Componentes
– Organiza componentes de software
– Fonte
• Coleção interrelacionadas de classes, associações, operações, eventos e restrições
• Serviço de um subsistema
– Responsabilidades genéricas
– Grupos de operações fornecidas
– Fonte
• Casos de uso
• Interface de Subsistema
– UML: Interface, dependência
– Define fluxo de interação e controle entre subsistemas
– Bem definidos e pequenos
– Às vezes chamado de API
• Termo deve ser reservado para a etapa de implementação
Suporte da UML: Diagrama de Pacotes
Decompor o sistema em pacotes

(contendo qualquer outro elemento da UML,
inclusive pacotes)
Suporte da UML: Diagrama de Deployment
Disposição física dos componentes em execução em nodos de hardware.
Princípios Básicos para Arquiteturas
• Modularização
– Decomposições de um sistema em grupos de
subsistemas e componentes
– Empacotamento físico das entidades que constituem
a lógica
• Separação de Preocupações
– Separation of Concerns
– Isolamento de responsabilidades diferentes ou sem
relacionamento entre elas
– Se um componente desempenha diferentes papéis em
distintos contextos, então estes devem ser isolados
Princípios Básicos para Decomposição
• Abstração
– Características essenciais de um componente que permite
distingui‐lo dos demais, e que portanto permite definir de
forma detalhada suas fronteiras conceituais
– Melhor tipo de abstração é a de dados
• Ocultamento de Informações
– Esconder a complexidade e detalhes internos de um
componente de seus clientes, minimizando o acoplamento
• Encapsulamento
– Agrupamento de elementos em uma abstração que
constitui sua estrutura e comportamento
– Unidade fisicamente distinguível
Princípios Básicos para Decomposição
• Alta coesão
– Interface dirigida a um único objetivo global
– Pequenas interfaces
– Melhor forma de coesão é a funcional
• Baixo acoplamento
– Poucas interdependências
• Dependência de poucas interfaces
– Acoplamento alto prejudica a compreensão e manutenção
de um sistema
• Dependências explícitas
• Suficiência, completude
– Em relação à abstração que captura
Fonte:
csis.pace.edu/~marchese/CS
616/Lec11/se_l11.htm
Exemplo de
Arquitetura em
Camadas
Fonte:
csis.pace.edu/~marchese/CS
616/Lec11/se_l11.htm
Testabilidade
• Arquitetura deve facilitar a avaliação do bom
funcionamento
– Melhor detecção, isolamento e correção de
problemas
– Planejar e organizar testes ao longo do tempo
– Integração contínua
– Facilitar integração de componentes
Capacidade de Mudança
• “Manutenção”: erros
– Capacidade de localizar as mudanças
– Minimizar o impacto da mudança nos demais componentes
• Extensibilidade: novas propriedades, versões melhoradas
– Componentes com fraco acoplamento
– Troca de componentes sem afetar seus cliente
• Reestruturação: reorganização dos componentes e de seus
relacionamentos
– Flexibilidade na configuração
• Portabilidade
– Adaptação do sistema a novas interfaces, plataformas,
– Poucas dependências de software/hardware
• Dá melhor apoio à construção de variantes de configuração de
software conforme usuário
• Cuidado com excessos
– Aumenta a complexidade (desenvolver, manter)
– Deteriora o desempenho
– Consome mais recursos
– Decidir as partes prioritárias a serem projetadas para acomodar
mudanças, e quais partes permanecem relativamente mais estáticas
– Se estas decisões não se revelarem acertadas com o tempo,
reestruturar o software para flexibilizar os
componentes/relacionamentos críticos
– É mais barato que projetar total flexibilidade desde o início
• Métodos ágeis costumam não planejar extensivamente para
acomodação de mudanças
Escolhendo Subsistemas
• Subsistema
– Possui bastante autonomia e pouca dependência de outros
componentes
– Pouca interação para cumprir seu objetivo
– Alta coesão, baixo acoplamento
– Análise de Dependências
• Subsistema depende de outros?
• Depende de quais?
• Quais dependem dele?
• Pergunta principal
– Qual é o serviço (papel) do subsistema?
– O que a sua interface deve oferecer a outros subsistemas?
• Questão complementar
– Existe alguma ordem/hierarquia entre os subsistemas?
– Qual o melhor modelo para representar esta ordem/hierarquia?
Referências
• Sommervile, Ian. Engenharia de software. 9ª
edição. Pearson Education. São Paulo, 2011.
– Capítulo 6 – Projeto de Arquitetura
– Capítulo 7 – Projeto Detalhado
• Literatura Opcional
– F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad,
and M. Stal. Pattern‐Oriented Software Architecture.
A System of Patterns. John Wiley & Sons Ltd.,
Chichester, UK, 1996
– M. Shaw and D. Garlan. Software Architecture:
Perspectives on a Emerging Discipline. Prentice Hall,
Englewood Cliffs, NJ, 1996
Perguntas?
• Este material tem
contribuições de
– Ingrid Nunes
– Karin Becker
– Lucinéia Thom
– Marcelo Pimenta

Aula15Projeto Arquitetural

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula15Projeto Arquitetural

Enviado por

Direitos autorais:

Formatos disponíveis

Projeto e Implementação:

Projeto Arquitetural (I)

Projeto 2. O sistema exibe todos os produtos cujo nome ou

Decompor o sistema em pacotes

Disposição física dos componentes em execução em nodos de hardware.

Você também pode gostar