Arquitetura, Projeto e Implementação de Sistemas de

SoftwareGA-031

Professor: Antônio Tadeu Azevedo Gomes

Email: atagomes@gmail.com 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

Introdução

7

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

Aspectos de qualidade orientados ao usuário final e ao

desenvolvedor!9

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, PApfm@sei.cmu.eduwww.sei.cmu.edu/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

Um exemplo pessoal... 20

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

Principais conceitos

Visões Notações Padrões de software

23

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

A Web…25

A Web…26

A Web!27

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

Exemplo de modelo UML

Visão estática de um cadastro de RH

33

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

Exemplos de design patterns

Composite

Decorator

Adapter

Strategy

Observer

39

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!!!