ArquiteturaSoftware

Arquitetura de Software
Uma Introdução
Copyright © 2017
Fábio Nogueira de Lucena
fabio@inf.ufg.br

Conteúdo
• Contexto, História
• Definição
• Processo
• Documentação (registro)
• Considerações finais

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

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

Outras fontes
• Podcasts
https://www.computer.org/portal/web/computingnow/onarchitecture
• Handbook of Software Architecture
http://handbookofsoftwarearchitecture.com/
• Documenting software architecture (system contexto diagram)
http://www.ibm.com/developerworks/library/ar-archdoc2/
• Documenting software architecture
http://www.sei.cmu.edu/architecture/tools/document/viewsandbeyond.cfm

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), ...

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, ...)

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)

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/

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)

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

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)

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/

O que é complexo, partimos...

A parte é gerenciável, tratável, ...

Então surgem conexões, interações,...

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

Qual a relação com AS?
faz uso de
Decomposição
de software

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

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,...

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

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

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

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

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

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

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)

Exemplo
Disponibilidade
(PDV)
Para 100 reqs,
1 poderá não ser
concluída

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

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!

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.

Problema
• Uma arquitetura de software precisa ser:
• comunicada
• compreendida
• analisada
• Ou seja, precisa ser registrada

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

Arquiteto de Software
baixo custo, equiparação
com concorrentes, facilidade
de mudança, usabilidade,
confiabilidade, desempenho, ...
Perspectiva de documentação
Insumos de stakeholders
Decisões

Como registrar?
Insumos de stakeholders

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, ...

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?

Desempenho
• Quando se requisita um serviço, o usuário espera por resposta rápida
• Desempenho
Habilidade de produzir a resposta no tempo apropriado

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

Segurança
• Nenhum sistema é 100% seguro
• Nenhum sistema é totalmente aberto
• Segurança
Criar “barreiras” para assegurar privacidade e acesso controlado à
funcionalidade

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

Manutenibilidade
• Todo sistema precisa de atualização
• Todo sistema será corrigido
• Manutenibilidade
Quão fácil é corrigir/atualizar um sistema?

Flexibilidade
• Sistemas passarão por mudanças ao longo do tempo
• Flexibilidade
Quão fácil é produzir novas versões?

Portabilidade
• Todo sistema é executado em um ambiente
• Ambientes alteram-se com o tempo
• Portabilidade
Quão fácil é migrar para um outro ambiente?

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.

Atributos
qualitativos
O que registrar?
Como registrar?

O que registrar?
Ontologia para
arquitetura de software

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

Informal
Box-and-line
(representação)
Mecanismo mais
comum
acompanhado
de explicações

Representação
usando
box-and-line
Arquitetura
de software
cliente/servidor
(three-tier)
http://en.wikipedia.org/wiki/Multitier_architecture

Mobile and Wireless Design Essentials, Martyn
Mallick, Wiley, 2003

Arquitetura Web usando Ajax (MSDN)
http://msdn.microsoft.com/msdnmag/issues/07/09/CuttingEdge/default.aspx?loc=pt

The Java EE 5 Tutorial
http://java.sun.com/javaee/5/docs/tutorial/doc/p1.html

Mais um exemplo...

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, ...)

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

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)

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

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?

“Aquela que melhora a
compreensão do
sistema
e seus atributos”
Que visão é relevante?

The Visual Architecting ProcessTM
The Visual Architecting Process (VAP)
http://www.bredemeyer.com

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

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.

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

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

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

Sucesso a todos!
fabio@inf.ufg.br

ArquiteturaSoftware

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a ArquiteturaSoftware

Mais de Fábio Nogueira de Lucena

ArquiteturaSoftware