Arquitetura, Projeto e Implementação de Sistemas de
SoftwareGA-031
Professor: Antônio Tadeu Azevedo Gomes
Email: [email protected] Site: http://wiki.martin.lncc.br/atagomes-cursos-lncc-ga031
1
ObjetivosDar ao aluno a base necessária para que o mesmo possa aplicar conceitos e paradigmas nas áreas de arquitetura, projeto e implementação de sistemas de software
Enfoque no desenvolvimento de sistemas de software com alta complexidade técnica
2
Ementa (não necessariamente linear!)
Introdução histórico; definições básicas; relação entre arquitetura, projeto e implementação Arquitetura notações; visões; estilos Projeto notações; padrões Implementaçãoorientação a xxx; refatoração de código; testes de software
3
BibliografiaShaw, M.; Garlan, D. Software Architecture – Perspectives on an Emerging Discipline. Prentice-Hall, 1996. Hofmeister, C.; Nord, R .; Soni, D. Applied Software Architecture. Addison-Wesley, 2000. Bass, L.; Clements, P.; Kazman, R. Software Architecture in Practice, second edition. Addison-Wesley, 2003. Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; Ivers, J.; Little, R .; Nord, R .; Stafford, J. Documenting Software Architecture – Views and Beyond. Addison-Wesley, 2002. Taylor, R .N.; Medvidovic, N.; Dashofy, E.M. Software Architecture: Foundations, Theory, and Practice. Wiley, 2010.
4
BibliografiaBuschmann, F.; Meunier, R .; Rohnert, H.; Sommerlad, P. Pattern-Oriented Software Architecture, volume 1 – A System of Patterns. Willey, 1996. Schmidt, D.; Stal, M.; Rohnert, H.; Buschmann, F. Pattern-Oriented Software Architecture, volume 2 – Patterns for Concurrent and Networked Objects. Willey, 2000. Kircher, M.; Jain P. Pattern-Oriented Software Architecture, volume 3 – Patterns for Resource Management. Willey, 2004. Jacobson, I.; Booch, G.; Rumbaugh, J. The Unified Software Development Process. Addison-Wesley, 1999. Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. Heineman, G.; Councill, W. Component-Based Software Engineering – Putting the Pieces Together. Addison-Wesley, 2001. Szyperski, C. Component Software – Beyond Object-Oriented Programming. Addison-Wesley, 2002.
Artigos recentes na área.5
Avaliação
Trabalho 1Modelagem arquitetural de sistemas de software Trabalho 2Projeto detalhado de sistemas de software
6
Desenvolvimento de software: dimensões de complexidade
Maior complexidade técnica - Embarcado, tempo real, tolerante a falhas - “Customizado”, inédito, re-arquitetado - Alto desempenho
Menor complexidade técnica - Linguagens de 4a. geração/ baseadas em componentes - Re-codificado - Interativo (desempenho relativo)
Maiorcomplexidadegerencial - Larga escala - Contratual - Vários atores - Dirigido a “projetos”
Menorcomplexidadegerencial - Pequena escala - Informal - Poucos atores - Dirigido a “produtos”
Sistema deinformaçãode defesa
(MIS)
Sistema de defesa anti-mísseis
Comutador
Ferramenta case
Sistema de controlede tráfego aéreo
Sistema deinformaçãoempresarial
(EIS) (família deaplicações)
Compiladorcomercial
Planilhaempresarial
Sistema deinformaçãodistribuído
(ex.: estoque)
Pequenas simulaçõescientíficas
Simulação em larga escala(p.ex. modelos econômicos)
Projeto de software médio: - 5-10 pessoas - 10-15 meses - 3-5 interfaces c/ ambiente - Alguns riscos Software
embarcadoem carros
Sistema deinformação
básico (ex.: estoque)
Simulações científicas
8
Por que arquitetura de software?
O surgimento do conceito de arquitetura de software está ligado ao desenvolvimento de sistemas de defesa norte-americanos
Financiamento de pesquisas na área pela DARPA Com o crescimento (em tamanho e complexidade) dos sistemas de software, a estruturação global dos mesmos passa a ser tão ou mais significativa quanto a escolha de algoritmos e estruturas de dados
Provisão de abstrações que ajudem a lidar com a complexidade de um sistema
Necessidade de ponte entre requisitos do sistema e sua implementação Definição de uma “planta” (blueprint) para o sistema
10
Exemplo de arquitetura de software: a Web!Impossível entendê-la pela imensa base de código que a implementa
Nenhum pedaço de código "implementa" a arquitetura da Web Múltiplos pedaços de código distintos implementam estruturas e comportamentos semelhantes na Web As regras de formação da Web não estão necessariamente no código, mas as consequências dessas regras, sim!
11
Relação entre arquitetura e outras atividades de desenvolvimento
Análise de domínio Análise de requisitos
Análise de risco
Projeto da arquitetura
de h/w
Projeto detalhado, codificação,integração e
teste
Arquitetura de s/w
Atributos de qualidade
Modificação nos requisitos
Especificação do h/w
Modificaçãona especificação
Arquiteturado s/w
Restrições de implementação
12
Arquitetura X ImplementaçãoArquitetos devem codificar?
Sim!!!! Mas quando? Algumas atividades de codificação têm impacto direto na arquitetura:
APIs Prototipação de cenários de uso críticos no sistema
Há algumas práticas de codificação onde o envolvimento do arquiteto é particularmente interessante:
Pair programming Test-driven development
13
Architecture doesn’t stop when it comes to programming. Designs
must be codified appropriately to avoid
architecture drift.
Frank Buschmann & Jörg Bartholdt
Questões arquiteturaisOrganização do sistema como uma composição de elementos Protocolos para comunicação, sincronização e acesso a dados Associação de funcionalidades a elementos da composição Distribuição física dos elementos Atributos de qualidade como escalabilidade e desempenho Seleção entre alternativas arquiteturais
14
Questões “não-arquiteturais”
Seleção de estruturas de dados e algoritmos específicos
Projeto de interface de usuário
Detalhes da linguagem/plataforma de programação
“Technology shapes an architecture, but a
resilient architecture should never be bound to
all of the technologies that form it”
Grady Booch
15
“... plans are useless but planning is indispensable” (Dwight Eisenhower)
16
Detailed, long-term plans can quickly become swamped by complexity as the tree of options branches out. Making assumptions about expected outcomes can prune the number of branches, but each assumption becomes a risk that an unexpected event invalidates the plan. The key is to find a middle ground between operating completely ad hoc on the one hand and having to be Nostradamus on the other. Planning at the proper scope is one tool to help avoid problems. Plans with deep detail and long durations are brittle due to complexity and/or the difficulty in making predictions. Like any other view, plans should be more detailed in the foreground and fuzzier in the distance. (...) Fitness for purpose should be the metric rather than pure quantity of detail.
(http://genehughson.wordpress.com/2014/02/09/plans-planning-and-pivots/)
Definição para arquitetura de software (1a. tentativa)
Descrição dos elementos que compõem o sistema, das interações entre esses elementos e da estrutura de composição (possivelmente aninhada) do sistema
17
Browser
Browser
Browser
Servidor Web
View
Logic
Data
O que define uma “boa” arquitetura?
Resiliência Suporte à evolução Simplicidade Exeqüibilidade Separação clara de aspectos Distribuição balanceada de responsabilidades Equilíbrio entre restrições econômicas e tecnológicas
18
3
© 2006 Carnegie Mellon University
How to Represent the Architecture of Your Application Using UML 2.0 and More
Paulo MersonSoftware Engineering InstitutePittsburgh, [email protected]/architecture
6Paulo Merson, December 2006© 2006 Carnegie Mellon University
We Can Do Better Than This!
I created this diagram8 years ago
The design may be OK
But the design description is bad and in two hours I:ll have told you why!
Prática atual de arquitetura de software
Descrição textual informal, por meio de expressões idiomáticas
“O sistema é baseado no modelo cliente-servidor e usa chamadas remotas de procedimento na comunicação entre clientes e servidores...”
Descrição gráfica abstrata por meio de diagramas “livres”
19
Problemas com a prática atual
Descrição informal e abstrata carrega um vocabulário semanticamente rico, mas potencialmente ambíguo
“Servidor é concorrente ou iterativo?” “Quantos clientes podem se associar simultaneamente a um servidor?” “Chamadas remotas são síncronas ou assíncronas?”
Prática atual sugere que arquitetos de software ainda não são bem servidos de notações e ferramentas adequadas
Mais sobre isso adiante!21
A disciplina “arquitetura de software”
Tema só recentemente considerado como disciplina à parte em engenharia de software
[Shaw & Garlan, 1996] Entretanto, a necessidade de notações formais para descrição arquitetural é algo identificado há muito mais tempo
Programming-in-the-large X Programming-in-the-small [DeRemer & Kron, 1976]
22
Visões arquiteturaisSistemas de software são compostos por várias “estruturas”
Unidades de código, sua decomposição e dependências Processos e suas interações Distribuição e interconexão física no hardware Etc.
Uma visão é uma representação de um conjunto de integrantes de uma dessas “estruturas” (não todas!) e as relações associadas a esses integrantes
Uma visão restringe que tipos de integrantes e relações podem ser expressos em uma estrutura específica
24
Visões arquiteturaisReduzem a quantidade de informação que o arquiteto de software trata em um dado momento Facilitam a ponte entre especificação arquitetural e implementação do sistema Há na literatura 3 modelos principais de visões:
Modelo 4+1 [Jacobson et al., 1999] Modelo Siemens [Hofmeister et al., 2000] Modelo de Clements et al [2002]
28
Exemplos de visões arquiteturais
Modelo de Clements et al [2002] Visão de módulos Visão de execução Visão de implantação (Visão de dados) (Visão de xxx)
29
NotaçõesImportante na comunicação entre diferentes fases do processo de desenvolvimento Esforço de padronização: UML (Unified Modeling Language)
Notação unificada com suporte à modelagem de múltiplas visões arquiteturais de software
30
Por que UML?Padrão aberto (OMG – Object Management Group) Dá suporte a todo o ciclo de vida de desenvolvimento Dá suporte a diversas áreas de aplicação Recebe suporte de inúmeras ferramentas Baseada na experiência e necessidades da comunidade de usuários
31
Surgimento de UML
32
OOSE(Jacobson)
Outros métodos Método de Booch
Método unificado
OMT(Rumbaugh)
Engano comum: UML não define processo de desenvolvimento, só notação
Padrões de softwareEnfocam problemas recorrentes em desenvolvimento de software e apresentam soluções para os mesmos Permitem o desenvolvimento de software com propriedades conhecidas de antemão
Definição de tipos de elementos básicos e restrições na composição desses elementos
Ajudam a gerenciar a complexidade do processo de desenvolvimento
Definição de um vocabulário uniforme Categorias: padrões (ou estilos) arquiteturais, padrões de projeto (ou design patterns), padrões idiomáticos (ou idiomas)
34
Estilos arquiteturaisRef.: [Buschmann et al., 1996]
Expressam aspectos estruturais do sistema de software como um todo
Contudo, sistemas raramente são construídos a partir de um único estilo!
Fase de especificação arquitetural
35
Exemplos de estilosPipes e filtros
Camadas
Cliente-servidor
Peer-to-peer
Objetos (!)
36
ls more“|”
(pipe)
Rede de Comunicação
IP
TCP
Aplicação
Browser
Servidor Web
Browser
Browser
Definição para arquitetura de software (2a. tentativa)
Descrição dos elementos que compõem o sistema, das interações entre esses elementos, da estrutura de composição (possivelmente aninhada) do sistema e de restrições sobre essas composições Restrições topológicas
37
Browser
Browser
Browser
Servidor Web
View
Logic
Data
Design patterns
Ref.: [Gamma et al., 1995] Expressam aspectos estruturais ou comportamentais de partes do sistema de software Fase de projeto
38
Idiomas
Ref.: depende! Expressam aspectos de implementação em uma linguagem de programação específica Fase de implementação
40
Exemplos de idiomas
Smart pointers em C++
Cópia de strings em C e Pascal
Recursive tail calls em Erlang
41
template <class T> class SmartPtr { public: explicit SmartPtr(T* pointee) : pointee_(pointee); SmartPtr& operator=(const SmartPtr& other); ~SmartPtr(); T& operator*() const { ... return *pointee_; } T* operator->() const { ... return pointee_; } private: T* pointee_; ... };
...
Class Widget { public: void Fun(); };
...
SmartPtr<Widget> sp(new Widget); sp->Fun(); (*sp).Fun();
... //não precisa desalocar sp com delete!!!
Top Related