Este documento fornece um resumo da história e conceito de arquitetura de software, além de abordar os processos de documentação e projeto de arquitetura. O texto discute a evolução da arquitetura de software ao longo do tempo, desde suas primeiras menções na década de 1960 até os dias atuais. Também define arquitetura de software como a decomposição de um sistema em componentes e a especificação de suas interações, e explica que a documentação de arquitetura envolve o uso de múltiplas visões para representar diferentes
4. Desejo
(idéia)
Requisitos
(idéia em papel)
Análise e Projeto
(como tornar real?)
Implementação
Tempo
PROCESSO
Produto
Visão de desenvolvimento de software
Arquitetura de Software desempenha
papel relevante neste processo
6. Fontes
The Golden Age of Software Architecture, Mary Shaw e Paul
Clements, IEEE Software, 2006, p. 31-39
The Past, Present, and Future of Software Architecture,
Philippe Kruchten et al, IEEE Software, 2006, p. 22-30
8. Evolução
• 1969: primeira referência a Arquitetura de Software (AS)
• Praticamente todos os trabalhos que citam “arquitetura de
software” são de 1990 ou mais recentes (CiteSeer)
• 20 referências mais citadas
• Publicadas de 1991 a 2000
• 5 livros, 4 artigos (surveys), ...
9. 1985-1993
• Documentação de uma AS usando
box-and-line e explanações informais
• Estruturas específicas de software foram definidas para domínios específicos
(controle de mísseis, ...)
10. 1992-1996
• ADLs (Architectural Description Languages)
Alguns não consideram UML uma ADL
• Formalização (análise formal de um modelo de arquitetura)
• Workshops e congressos pelo mundo
• Padrões arquiteturais são catalogados
Pattern-Oriented Software Architecture---A System of
Patterns, John Wiley & Sons, 1996
(POSA 1)
11. 1995-2000
• IEEE Transactions on Software Engineering dedica toda uma edição a AS em
1995.
• IEEE/IFIP Conference on Software Architecture (www.wicsa.net)
• Grupo de trabalho (IFIP)
http://www.softwarearchitectureportal.org/
12. 1996-2003
• Análise e avaliação de arquiteturas de software “crescem”
• Livros acerca de avaliação e documentação de ASs são publicados
• A importância de atributos qualitativos é ressaltada junto com o
papel da AS para satisfazê-los
• ArchE (auxiliar de arquiteto)
13. 1998-até hoje
• UML torna-se a ADL padrão da indústria
• Arquiteturas n-tier client/server
• Arquiteturas orientadas a serviço (SOA)
• OMG inicia Model Driven Architecture (MDA): “separar negócio e lógica
da aplicação da plataforma tecnológica”
• Currículo ACM/IEEE: 20% de projeto de software é dedicado a AS
14. 1998-até hoje (continuação)
• Surge o papel “arquiteto de software”
• Worldwide Institute of Software Architects (http://www.wwisa.org/)
• International Association of Software Architects
(http://www.iasahome.org/)
• Grady Booch
Handbook on Software Architecture
(catalogados 1929 padrões)
(http://www.booch.com/architecture)
15. Algumas referências úteis
• SEI
http://www.sei.cmu.edu/architecture
• Gaudí System Architecting
http://www.gaudisite.nl/
• Software Architecture (Bredemeyer)
http://www.bredemeyer.com/
• Software Product Lines
http://softwareproductlines.com/
• Software Architectures
http://www.softwarearchitectures.com/
• Grady Booch (Handbook of SA)
http://www.booch.com/architecture
• Pesquisas e ensino
http://sunset.usc.edu/research/software_architecture/
21. Na presença do “complexo”
• Decompomos porque
• A parte é gerenciável, tratável, ...
• Consegue-se lidar com o todo pelas partes
• “Ninguém consegue gerenciar um projeto, mas os pacotes de trabalho deste”
(Rita Mulcahy)
• Efeito colateral
• O todo é mais do que a união das partes
• Quando se parte, surgem conexões, interações...
22. Qual a relação com AS?
Arquitetura de Software
faz uso de
Decomposição
de software
23. Software Engineering, 8th edition, Ian
Sommerville, Addison-Wesley, 2007
• Sistemas são decompostos em subsistemas
• A identificação dos subsistemas e da estrutura empregada para
controle e comunicação destes subsistemas é chamado de projeto
arquitetural
• A saída produzida deste processo de projeto é uma descrição da AS
Estrutura que identifica os principais componentes de
um sistema e as comunicações entre eles.
Interações
Partes
24. Software Architecture in Practice, 2nd Edition,
Bass, Clements, Kazman, Addison-Wesley, 2003
“A arquitetura de software de um programa é a estrutura do sistema
que compreende elementos de software, as propriedades visíveis
externamente destes elementos e os relacionamentos entre eles.”
Propriedades: serviços oferecidos, desempenho,...
25. Outras definições
• “AS é o conjunto de decisões de projeto que, se realizadas incorretamente,
podem acarretar o cancelamento do projeto.”
Eoin Woods, Software Systems Architecture: Working With Stakeholders
Using Viewpoints and Perspectives, Addison-Wesley, 2005.
• Outras dezenas de definições
http://www.sei.cmu.edu/architecture/definitions.html
26. Qual a diferença de AS e projeto?
• Arquitetura é projeto
• Nem tudo que é projeto é arquitetura
• Projeto de granulosidade mais fina e código devem ser produzidos
em conformidade com a AS
Se a propriedade de um elemento da arquitetura não é visível a outros,
então este não é um elemento da arquitetura.
Requisitos Projeto Codificação
A
S
27. Diretriz
As questões estruturais são o foco.
São questões de projeto mais abstratas que
algoritmos e estruturas de dados.
Software Architecture: An Executive Overview
Clements & Northrop, CMU/SEI-96-TR-003
28. Perspectivas de uma AS
• Uma arquitetura de software
• define a estrutura
• estabelece a comunicação entre componentes
• está voltada para requisitos não funcionais
• é uma abstração
(não é preciso consultar código)
Essential Software Architecture, Ian Gorton, Springer-Verlag, 2006
29. Importante
“Arquitetura de software é parte da qualidade do produto e não está
ligada a um processo, tecnologia, cultura ou ferramenta particular.”
Software Architecture-Centric Methods and Agile Development,
Nord & Tomayko, IEEE Software, april/2006
31. Software Engineering, 8th edition, Ian Sommerville,
Addison-Wesley, 2007
(página 240, segundo parágrafo)
“Projeto é um processo criativo. Não há meio
certo ou errado. Ninguém pode fornecer uma 'receita' para projeto de
software. Aprende-se
observando exemplos e discutindo seu
projeto com outros.”
Não há método amplamente aceito acerca de
“como” decompor um software
32. Software Architecture Review and Assessment (SARA) Report
Philippe Kruchten et al, 2001
http://philippe.kruchten.com/architecture/SARAv1.pdf
Modelo do contexto de projeto de arquitetura
(universo de discurso)
33. Modelo do contexto de projeto de arquitetura
(universo de discurso)
Exemplo
Disponibilidade
(PDV)
Para 100 reqs,
1 poderá não ser
concluída
34. Exemplo de interesse nacional
• Sistemas de controle de tráfego aéreo
• Qualidade (concern)
• Alta disponibilidade
• Requisito (versão mais objetiva)
• Indisponibilidade (downtime) inferior a cinco (5) minutos por ano
35. The Visual Architecting ProcessTM
The Visual Architecting Process (VAP)
http://www.bredemeyer.com
Subconjunto dos requisitos de um
sistema (requisitos não funcionais ou
arquiteturalmente relevantes)
Quando parar? Exige avaliação!
36. Architecture Expert (ArchE) Tool
• Criar especificação mensurável de requisitos não funcionais
• Avaliar se a arquitetura corrente satisfaz os requisitos
• Não: fazer mudanças e repetir o passo acima.
• Sim: processo é terminado.
PROBLEMA: o número de possíveis soluções é “grande”,
mesmo para um simples problema.
38. Problema
• Uma arquitetura de software precisa ser:
• comunicada
• compreendida
• analisada
• Ou seja, precisa ser registrada
39. Noção comum
• Arquitetura de Software é composição de:
• Diagramas contendo caixas e linhas
• Juntamente com explanações informais
Componentes operam
sob o controle do
Frontend, responsável
pela interface gráfica ...
Legenda: seta tracejada
significa ...
40. Arquiteto de Software
baixo custo, equiparação
com concorrentes, facilidade
de mudança, usabilidade,
confiabilidade, desempenho, ...
Perspectiva de documentação
Insumos de stakeholders
Arquitetura de Software
Decisões
41. Software Architecture Review and Assessment (SARA) Report
Philippe Kruchten et al, 2001
http://philippe.kruchten.com/architecture/SARAv1.pdf
Modelo do contexto de projeto de arquitetura
(universo de discurso)
Como registrar?
Insumos de stakeholders
42. Alguns atributos qualitativos
• Desempenho
• Escalabilidade (requisições, conexões...)
• Quão fácil é alterar o software?
• Segurança
• Disponibilidade
• Quão fácil é a integração?
• Portabilidade, testabilidade, ...
Essential Software Architecture, Ian Gorton, Springer-Verlag, 2006
43. Disponibilidade
• Nenhum sistema será executado sem interrupções para sempre
• Situações inesperadas e indesejáveis ocorrem
• O sistema será paralisado
• Manutenção será realizada
• Disponibilidade
Quanto do tempo o sistema estará disponível?
44. Desempenho
• Quando se requisita um serviço, o usuário espera por resposta rápida
• Desempenho
Habilidade de produzir a resposta no tempo apropriado
45. Escalabilidade
• Desempenho para um usuário: ótimo
• Desempenho para 1K usuários: OK
• EXEMPLO
QuickSort recursivo (pode causar stack overflow)
• Escalabilidade
Desempenho não cai de forma significativa à medida que o número de
requisições aumenta
46. Segurança
• Nenhum sistema é 100% seguro
• Nenhum sistema é totalmente aberto
• Segurança
Criar “barreiras” para assegurar privacidade e acesso controlado à
funcionalidade
47. Gerenciabilidade
• É preciso monitorar para verificar se está tudo ok
• É preciso alterar em tempo de execução para corrigir rota
• Gerenciabilidade
Capacidade de monitorar e alterar o funcionamento do sistema em tempo
de execução
48. Manutenibilidade
• Todo sistema precisa de atualização
• Todo sistema será corrigido
• Manutenibilidade
Quão fácil é corrigir/atualizar um sistema?
50. Portabilidade
• Todo sistema é executado em um ambiente
• Ambientes alteram-se com o tempo
• Portabilidade
Quão fácil é migrar para um outro ambiente?
51. Como registrá-los?
• Cenário de atributo de qualidade
• Fonte de estímulo
• Estímulo
• Ambiente
• Artefato
• Resposta
• Medida da resposta
• Exemplo
Desenvolvedor deve alterar a interface para contemplar novo
atributo de entidade. Deverá consumir menos de 3 horas para
produzir e testar sem efeitos colaterais.
Software Architecture in Practice, 2nd Edition,
Bass, Clements, Kazman, Addison-Wesley, 2003
52. Software Architecture Review and Assessment (SARA) Report
Philippe Kruchten et al, 2001
http://philippe.kruchten.com/architecture/SARAv1.pdf
Modelo do contexto de projeto de arquitetura
(universo de discurso)
Atributos
qualitativos
O que registrar?
Como registrar?
Arquitetura de Software
54. Como registrar uma AS?
• Box-and line (registro informal)
• IEEE Recommended Practice for Architectural Description of
Software-Intensive Systems
IEEE Std 1471-2000
• The 4+1 View Model of Software Architecture,
Phillip Kruchten, IEEE Software, vol. 12, no. 6, 1995
• Templates, apresentação, ...
How to Represent the Architecture of Your Enterprise
Application Usin UML 2.0 and More
Paulo Merson
http://www.sei.cmu.edu/architecture/arch_doc.html
Arquitetura de Software
61. Qual o problema com box-and-line?
• Em geral não seguem com “legenda” daí
• Não se sabe o que significa uma caixa
• Processo, thread, ...
• Código fonte, compilado, DLL, Jar file, ...
• Contêiner, biblioteca, ...
• Não se sabe a semântica de uma linha
• Fluxo de controle (em que sentido?)
• Fluxo de dados, dependência (temporal, ...)
62. Cenário atual
• Software compreende várias estruturas
• Código, decomposição deste, dependências,...
• Processos e como estes interagem
• A implantação (distribuição) em hardware
• E outras...
• Visão: representação de uma estrutura
• Ou seja, precisamos de várias visões
63. The 4+1 View Model of Software Architecture,
Phillip Kruchten, IEEE Software, vol. 12, no. 6, 1995
• Lógica
• Objetos relevantes (quando se usa OO)
• Processo
• Aspectos de concorrência e sincronização
• Física
• Mapeamento de software em hardware
• Desenvolvimento
• Identifica módulos, subsistemas, camadas
• Cenários (integra as visões)
64. Exemplos de Documentos de
Arquiteturas de Software
(múltiplas visões)
• Toy Air Traffic System (TATS)
Philippe Kruchten
http://philippe.kruchten.com/architecture/SADexample.doc
• Exemplo (documentação de uma AS)
http://la.sei.cmu.edu/sad-wiki/index.php/The_Java_Pet_Store_SAD
65. IEEE Recommended Practice for Architectural Description of Software-Intensive
Systems, IEEE Std 1471-2000
• Sugere o emprego de visões
• Não informa, contudo, quais as visões?
66. “Aquela que melhora a
compreensão do
sistema
e seus atributos”
Software Architecture in Practice, 2nd Edition,
Bass, Clements, Kazman, Addison-Wesley, 2003
Que visão é relevante?
70. Uma perspectiva adicional...
• Arquitetura é o conjunto de decisões de projeto que devem
ser feitas no começo de um projeto.
• Arquitetura faz referência ao que é importante. O que quer
que seja este importante.
• A compreensão comum do projeto de um sistema é a
arquitetura deste sistema.
• Decisões de arquitetura são difíceis de serem alteradas.
Who needs na Architect?
Martin Fowler, IEEE Software, sept/oct, 2003, 11-13.
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
71. Arquiteto de Software (papel)
O arquiteto ideal deveria ser uma pessoa de artes, um
matemático familiar com estudos históricos, um estudante
diligente de filosofia, conhecedor da música, não ignorante em
medicina, capaz de compreender juristas, familiar com a
astronomia e cálculos astronômicos.
Vitruvius, 25 AC
A “visão” do arquiteto de software deve ser
HORIZONTAL, AMPLA,
em vez daquela vertical,
necessária em projetistas de software.
72. Projeto de arquitetura
é um processo criativo
Grady Booch
Handbook on Software Architecture
(catalogados 1929 padrões)
(http://www.booch.com/architecture)
O que influi neste processo?
• A experiência do arquiteto
73. Organização de um sistema
• Modelo cliente/servidor
• Clientes usufruem de serviços oferecidos por servidores
• Modelo repositório
• Sub-sistemas compartilham dados em repositório
compartilhado
• Modelo em camadas
• Camadas oferecem serviços definidos em termos de
serviços oferecidos pelas camadas inferiores
74.
75.
76.
77. Outras questões
• Arquiteturas para sistemas distribuídos
• Arquiteturas cliente/servidor
• Objetos distribuídos (CORBA, ...)
• Service-Oriented Architecture (SOA)
• Mensagens + Interface pública
• Model-Driven Architecture (MDA)
• Separa aplicação de plataformas e tecnologias