arquitetura de software 1 - facom.ufu.brbacala/es/10-arquitetura de software.pdf · introdução...
TRANSCRIPT
ARQUITETURA DE SOFTWARE 1
Introdução • O que é arquitetura?
• Disposição das partes ou elementos de um edifício ou espaço urbano. [Aurélio]
• A estrutura e organização lógica de funcionamento de um sistema computacional. [Aurélio]
• Considerando essas definições, como desenvolver sistemas mais complexos, sem pensar em sua arquitetura??
• Como fica a qualidade desses sistemas sem “cuidar” da arquitetura??
2
Introdução • À medida que a complexidade e o tamanho dos
sistemas de software têm aumentado, engenheiros de software têm lançado mão de princípios de projeto, tais como a modularização e o ocultamento da informação, de modo a obter sistemas com maior qualidade e a um baixo custo.
• Para isso, o projeto da estrutura global do software (arquitetura de software) é uma questão que vem sendo considerada.
3
Motivação
• Projetos simples podem ser realizados por uma única pessoa • Pouca modelagem
• Ferramentas simples
• Processo simples
• Pouco projeto
• Pouca especialização para construir 4
Motivação
• Projetos complexos/Maiores exigem arquitetura • Mais modelagem
• Ferramentas mais poderosas
• Processos mais bem definidos
• Mais projeto
• Alta especialização para construção 5
Visões Arquiteturais • Para um edifício, são usados tipos diferentes de plantas para
representar diversos aspectos da arquitetura.
6
Visão 4+1 da Arquitetura - RUP
7
Visão Lógica
8
Visão de Implementação
9
Visão de Processo
• Focaliza assuntos como concorrência e paralelismo, tolerância a falhas e objetos distribuídos.
• Interoperabilidade
• Escalabilidade
• Disponibilidade
10
Visão de Implantação
11
Visão de Casos de uso
• Contém alguns cenários-chave usados para dirigir a descoberta e projeto da arquitetura e posteriormente, para validar as diferentes visões.
12
Arquitetura é o elemento central do desenvolvimento de sw
13
Introdução • A arquitetura de software é dita como tendo
principal papel na determinação da qualidade e da manutenibilidade do software.[Wasserman, 1996]
• Os atributos de qualidade dos sistemas de software são estreitamente relacionados às suas arquiteturas. [SEI, 2005]
• Atributos de qualidade:
• performance/desempenho, confiabilidade, manutenibilidade, portabilidade,...
14
O que é arquitetura de software?
• “Uma arquitetura de software deve conter: a definição dos elementos de projeto que compõe o software; a descrição das interações entre estes elementos; os padrões de composição dos elementos; e um conjunto de restrições sobre estes padrões.”
[Shaw 96]
15
O que é arquitetura de software?
• “A descrição da arquitetura de software é um passo intermediário entre a análise de requisitos e o projeto. Esta descrição consiste de elementos arquiteturais, as interações entre estes elementos, e as restrições sobre estes elementos e sobre as suas interações.”
[Perry 92]
16
Definições
• Instância arquitetural:
• Refere-se à arquitetura de um determinado sistema de software.
• Estilo arquitetural:
• Definem as restrições sobre a forma e a estrutura de uma família de instâncias arquiteturais. Exemplos: • Camadas (duas, três ou quatro camadas)
• Pipes and Filters
• Centrada na base de dados
• Cliente-Servidor
• Estilos resultantes da combinação de estilos arquiteturais.
17
Estilo arquitetural • Permite que um profissional (projetista, arquiteto ou
engenheiro) determine a classe a qual pertence a organização de um sistema.
• O que ajudam a identificar o estilo que retrata a arquitetura de software do sistema? • Características dos componentes (subsistemas) e conectores do
sistema
• Topologia da arquitetura
• Restrições semânticas
• Mecanismos de interação entre os componentes.
• O uso de estilos arquiteturais no desenvolvimento de software facilita:
• a comunicação entre as pessoas envolvidas no desenvolvimento
• o entendimento do projeto em desenvolvimento
18
Vantagens de uma arquitetura explícita • Comunicação entre stakeholders
• A arquitetura pode ser utilizada como o foco de discussão entre os interessados
• Reutilização em larga escala
• A arquitetura pode ser reutilizada em uma variedade de sistemas
• Análise do sistema
• A arquitetura pode ser utilizada para análise preliminar sobre a possibilidade do sistema atender seus requisitos não-funcionais
19
Atributos de arquitetura • Performance
• Localizar operações de modo a minimizar a comunicação entre subsistemas
• Segurança
• Utilizar uma arquitetura em camadas com recursos críticos localizados em camadas internas
• Disponibilidade
• Incluir componentes redundantes na arquitetura
• Manutenção
• Utilizar componentes especializados e auto-contidos
20
Arquitetura de referência • Alguns autores utilizam os termos estilos arquiteturais e
arquitetura de referência como sinônimos.
• Contudo, arquitetura de referência é: • Uma estrutura que provê uma caracterização das funcionalidades dos
sistemas de software de um dado domínio de aplicação.
• Exemplos:
• ADAGE um arquitetura de referência para o apoio ao desenvolvimento de sistemas de software no domínio de controle de aviões (Batory et al., 1995),.
• Arquitetura de referência para sistemas de comércio eletrônico (Bass et al., 2003).
• Arquitetura de referência para servidores WWW.
• Arquitetura de referência para sistemas baseados em componentes
• Arquitetura de referência para sistemas orientados a serviços 21
Arquitetura de referência
• Constituem um elemento fundamental para o desenvolvimento de linhas de produto (do inglês, product lines)
• Podem também ser consideradas como o primeiro e essencial passo para o desenvolvimento de frameworks de aplicação.
• Propor arquiteturas de referência para sistemas de um dado domínio de aplicação não é uma tarefa trivial.
22
Arquitetura de software de domínio específico • Base estrutural para a interoperabilidade de
componentes dentro de um domínio.
• Pode dar apoio a uma abordagem de desenvolvimento de domínio específico que possibilite a configuração de componentes reutilizáveis.
• Compreende um modelo de domínio, requisitos de referência, uma arquitetura de referência, infraestrutura ou ambiente de apoio e um processo de desenvolvimento.
23
Projeto arquitetural
• processo de construção de uma arquitetura de software explícita
• ligação entre os processos de especificação e de projeto detalhado de software
24
Projeto arquitetural
• Principais atividades
• Decomposição do sistema de software em subsistemas e componentes
• Identificação das interações e comunicação entre eles
• Modelagem arquitetural
25
Projeto arquitetural
• Problemas
• O projeto de arquiteturas de software específicas (ainda) é baseado em intuição e experiência
• Métodos pouco ajudam!
• Documentação (arquitetura e decisões)
• Modelagem arquitetural
26
Arquitetura de Software
• Elementos [Shaw 96]
• componentes
• conectores
• configurações
• estilos
27
Componente • Unidade de computação ou de armazenamento de
dados
• clientes, servidores
• databases
• filtros
• camadas
• ADTs
• Simples ou composto
28
Conector
• Elemento que modela
• interações entre componentes
• regras que governam tais interações
29
Conector
• interações simples
• chamadas de procedimentos
• acesso a variáveis compartilhadas
• interações complexas
• protocolos cliente-servidor
• protocolos de acesso a base de dados
• broadcast de eventos
• piped data streams
30
Configuração • Uma configuração arquitetural ou topologia é um grafo
de componentes e conectores que descrevem a estrutura arquitetural • aderência a regras de estilo
• Componentes compostos são configurações
31
Componentes e conectores
32
Arquitetura de uma ferramenta CASE
33
Tradutor de
projeto
Editor de
projeto
Gerador de
código
Analisador
de projeto
Gerador de
relatório
Editor de
programa
Repositório
de projeto
Sistema de controle robotizado de embalagem
34
Sistema
de Visão
Sistema de
identificação de
objetos
Controlador de
braço
Controlador
de garra
Sistema de
seleção de
embalagem
Sistema de
embalagem Controlador de
transportadora
Cliente-servidor
35
Rede de banda larga
Cliente 2 Cliente 4
Servidor de
catálogo
catálogo
Servidor de
vídeo
Arquivos de
clipes de filmes
Servidor de
fotografias
Fotografias
digitalizadas
Servidor de
hipertexto
Web de
hipertexto
Cliente 3 Cliente 2 Cliente 3 Cliente 4 Cliente 1
Arquitetura baseada em eventos
36
Subsistema
1
Subsistema
2
Subsistema
3
Subsistema
4
Manipulador de eventos e mensagens
Questões
• Como escolher subsistemas e componentes?
• Quais as suas propriedades? E responsabilidades?
• Como componentes interagem?
• Como incorporar e explicitar propriedades não-funcionais?
• Como descrever uma arquitetura?
37
Estilos Arquiteturais
Estilo Arquitetural
• Padrões ou idiomas de projeto que guiam a organização de módulos e sub-sistemas em sistemas completos. (Shaw & Garlan)
• Abstração de características de composição e interação recorrentes de um conjunto de arquiteturas. (Taylor)
• Idiomas de projeto “chave” que permitem a exploração de padrões estruturais e evolutivos adequados e que facilitam a reutilização de componentes, conectores e processo. (Medvidovic)
39
Estilo arquitetural
• Um estilo arquitetural define uma família de sistemas em termos de um padrão de organização estrutural.
• Um estilo arquitetural define • Um vocabulário de tipos de componentes e
conectores
• Um conjunto de restrições sobre como podem ser combinados
• Um ou mais modelos semânticos que especificam como as propriedades sistêmicas podem ser determinadas a partir das propriedades de suas partes
40
Estilos arquiteturais
• O modelo de arquitetura de um sistema pode estar em conformidade com um modelo ou estilo genérico
• Um conhecimento destes modelos pode simplificar o problema de definição de arquiteturas de sistemas
• Sistemas de grande porte, no entanto, são heterogêneos e não seguem um único estilo
41
Estilos Arquiteturais Shaw and Garlan, Software Architecture, 1996
• Independent Components
• Communicating Processes
• Event-Driven
• Data Flow
• Batch
• Pipes & Filters
• Data –Centric
• Repository
• Blackboard
• Call & Return
• Layered
• Object Oriented
• Main Program & Subroutine
• Virtual Machine
• Interpretter
• Rule-Based
42
Estilos
43
Layered systems [Shaw&Garlan94]
44
Padrões Arquiteturais POSA
Padrões
• Projetistas e arquitetos experientes…
• procuram aderir a princípios e promover boas práticas de design.
• usam padrões para documentar e reutilizar experiência comprovadamente boa em novos projetos (de software)
• Abordagem orientada a problemas
46
O que é um padrão?
• Um padrão é uma regra envolvendo 3 partes, que expressa uma relação entre um certo contexto, um problema e uma solução.
• Contexto
• uma situação que dá margem a um problema
• Problema
• o problema recorrente que surge em tal contexto
• Solução
• uma solução comprovada para o problema.
47
Contexto Exemplos
• "your environment is a distributed and possibly heterogeneous system with independent cooperating components".
• "interactive applications with a flexible human-computer interface".
• "building systems that support their own modification a priori".
48
Problema Exemplos
• “... From a developer"s viewpoint, there should essentially be no difference between developing software for centralized systems and developing for distributed ones”...
• “User interfaces are especially prone to change requests. When you extend the functionality of an application, you must modify menus to access these new functions”...
• “Software systems evolve over time. They must be open to modifications in response to changing technology and requirements”... 49
Solução Exemplos • “Introduce a broker component to achieve better
decoupling of clients and servers”...
• “Use the Model-View-Controller (MVC). MVC was first introduced in the Smalltalk-80 programming environment. MVC divides an interactive application into the three areas: processing, output, and input”...
• “Make the software self-aware, and make selected
aspects of its structure and behavior accessible for adaptation and change. This leads to an architecture that is split into two major parts: a meta level and a base level”...
50
Forças
• “As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves”.
• Forças?
• O termo força denota qualquer aspecto do problema que deve ser considerado ao propor a solução.
51
Forças Exemplos
• Requisitos que a solução deve atender
• “peer-to-peer inter-process communication must be efficient”
• Restrições a serem consideradas
• “inter-process communication must follow protocol XPTO”
• Propriedades desejáveis
• “changing software should be easy”
52
Forças MVC
• O padrão Model-View-Controller especifica duas forças:
• Deve ser fácil modificar a interface do usuário, mas...
• O núcleo funcional do software não deve ser afetada por essa modificação.
53
Forças
• Forças discutem o problema a partir de diversos pontos-de-vista e ajudam a compreensão de detalhes
• Forças podem complementar ou contradizer umas às outras.
• Extensibilidade de um sistema versus minimização de seu código
54
Padrões arquiteturais Buschman, 1996 • Padrões arquiteturais expressam esquemas fundamentais
para a organização estrutural de sistemas de software
• Padrões arquiteturais oferecem um conjunto pré-definido de subsistemas, especificam suas responsabilidades e incluem regras e orientações (guidelines) para organizar os relacionamentos entre eles.
55
Padrões arquiteturais Buschman, 1996
• Distributed Systems • Broker
• Interactive Systems • MVC
• PAC
• Adaptable Systems • Microkernel
• Reflection
• From Mud to Structure • Layers
• Pipes & Filters
• Blackborad
56
Categorias
Categorias de Padrões do livro POSA • Justificativa
• Organizar padrões em função da principal propriedade sistêmica global que incorporam
• Categorias • From Mud to Structure
• padrões que ajudam a evitar um ‘mar' de componentes.
• Distributed systems • suporte à estruturação de sistemas com componentes distribuídos
• Interactive systems • facilidade de adaptação de interface do usuário
• Adaptable systems • suporte à extensão de aplicações e sua adaptação à tecnologia em
evolução e à mudança em requisitos não funcionais 57
Client-server
58
Client-server Multi-tier
59
Broker
60
Publish-Subscribe
61
Peer-to-peer
62
Exemplos
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
Referências
• Resources for Software Architects
• http://www.bredemeyer.com/index.html
93