Arquiteturas de Software
Francilene Garcia
Projeto I
2008.2
Conceitos Básicos
Um sistema computacional
Um sistema computacional
isolado…
?
No espaço, ninguém escuta o seu
Stakeholders…
Operador
QA
Consumidor
Arquiteto
Técnico
CEO Cliente
Desenvolvedor
CEO Fornecedor
AdminSys
BillGates
Outros sistemas…
Ativos
Gerador de
Relatórios
Contabilidade
Infra Rede
Cadastros
Labs Estudantes
Oportunidades e riscos…
Venda fraca de sistemas
Impostos
Mercado imaturo
Venda acelerada
de sistemas
Construção de imagem
Entrada na Bolsa
BillGates
Desempenho fraco
Chega tarde ao mercado
Restrições e aspectos críticos…
Falta desenv.
de BD
Sistema
Operacional
Alta oferta de desenv.
Java
Processador + rápido
Legislação
Sistemas Legados
Padrões
Políticas
Ética e meio ambiente
É complicado.
Qual o papel da arquitetura?
?
Leaning tower image from Gary Feuerstein.
Other images from The Big Ball of Mud, by Yoder and Foote.
Ciclo de vida do desenvolvimento
Software
concept
Preliminary
requirements
analysis
Arquitetura define a estrutura do sistema
Design of
architecture and
system core
Primeira release libera o core do sistema
Develop
a version
Deliver a
version
Incorporate
customer
feedback
“The evolutionary delivery lifecycle model”
(Rapid Development, Steve McConnell)
Elicit
customer
feedback
A arquitetura desempenha um papel vital na definição da
estrutura do sistema, desde cedo no ciclo de vida do
desenvolvimento
Vida útil do sistema
Vision
Inception
Development
Deployment
Operation
A arquitetura antecipa decisões que afetam
toda vida útil do sistema
Maintenance
Alteration
Legacy
operation
Death
Definições…
…e formam um
todo que atendem
a expectativas
Um sistema é
um conjunto
de partes
As partes se
relacionam
entre si…
Alguns exemplos…
Antes: Na engenharia, trabalha-se com muitos modelos. Um
modelo é uma representação que abstrai detalhes menos
essenciais, e pode ser manuseada de uma forma que o
“objeto real” não permite.
Boletim Web (Blog)
Presentation
Administration
Forums and
posts
Disponibilidade
Navigation
Segurança
Logic
Posting and
navigation
Administration
Data
Forums and posts
Users and sessions
Uma arquitetura em
3-camadas – muito
utilizada em sistemas
client-server e web
Processamento de imagem
Desempenho
Algorithm
control
Capture
Compression
Recognition
Scaling
Image
storage
Module
scheduler
O processamento tipo
“pipeline” é muito utilizado
em sistemas de tempo real
e embarcados
Portabilidade
Isto é tudo!
• Questões?
Referências e Leituras
Recomendadas
• "An Introduction to Architecture." Chapter 1 of A Software
Architecture Primer, by John Reekie and Rohan
McAdam.
• "Architectural Analysis." Chapter 2 of A Software
Architecture Primer, by John Reekie and Rohan
McAdam.
• Jan Bosch, ``Design of Software Architectures,'' Chapter
2 of Design and Use of Software Architectures: Adopting
and Evolving a Product-line Approach, pp 23--40.
Addison-Wesley, 2000.
• Alistair Cockburn, ``Introduction,'' Chapter 1 of Writing
Effective Use Cases, pp 1--19. Addison-Wesley, 2000.
Análise e Projeto Arquitetural
Arquitetura é arte?
Fatores
contextuais
Arquitetura
desejável
Necessidades
do Cliente
Os clientes devem auxiliar no
projeto da arquitetura
desejável, sem esquecer os
fatores contextuais
Fatores contextuais – para casas
•
•
•
•
•
Clima
Materiais disponíveis
Portabilidade
Riscos
Atividades
“Fatores contextuais”?
isks
“OS-Z não é compatível”
onstraints
nablers
“OS-Z melhora a segurança”
“OS-Z não tem tal facilidade”
São exemplos
de fatores.
Tipos de fatores contextuais
• São buscados em vários lugares:
– Mercado/concorrência
– Empresas
– Tecnologia
– Políticas
“A legislação restringe
falhas …”
“Uma versão
atualizada
de …”
“A forte capacidade de
desenvolvimento Java…”
“O time de
desenvolvimento da
India…”
“Padrão 3576
requer…”
“Esta janela de
oportunidade…”
Decisivos
• Mudança…!
• Estrutura organizacional
• Desempenho do time
Uso de narrativas
• Um caminho
Preciso de um editor que “escute”
informal mas útil
minhas palavras e gere um histórico
com meus discursos…
para descrever
funcionalidades do
sistema através de
cenários
• Cria “personagens”
e conta a “estória”
• Algumas vezes
pode parecer levar à
escrita de casos de
uso
Um exemplo de narrativa
“Pedro está interessado em comparar
paisagens do litoral nordestino com
praias da costa espanhola usando
padrões de fotografia. Ele tem
acumulado e classificado dados nos
últimos cinco anos, exportando-os de
forma que os dados possam ser
manuseados por um pacote estatístico.”
“Pedro” é um pesquisador do INPE.
Requisitos funcionais
• Surgem das necessidades dos stakeholders
• Explicitam quais funcionalidades o sistema deve
prover
• Abordagens variam:
–
–
–
–
Linguagem estruturada (análise de requisitos)
Casos de uso
Modelos formais
Estórias de Uso (XP1)
Requisitos não-funcionais
• Expressados na forma de atributos de
qualidade
• A arquitetura deve identificar, analisar e
suportar a implementação de atributos de
qualidade
Atributos runtime
• Atributos runtime
afetam a execução do
sistema em produção
• Cenários devem ser
descritos com foco
em instâncias
específicas da
execução
Um acrônimo bem utilizado…
erformance
sability
eliability
ecurity
Velocidade do process., utilização de
recursos, tempo de resposta
Impacto de fatores humanos
Taxa de falhas, modos,
severidade, e recuperação
Integridade dos dados,
confidencialidade,
resistência a ataques
São atributos usados para definir
o “guarda-chuva” das qualidades.
Qualidades não ligadas à
execução
• São mais ligadas à
vida útil do sistema
• Cenários são
expressados em
termos de incidentes
que ocorrem durante o
desenvolvimento,
deployment, ou
operação do sistema
Outros acrônimos…
aintainability
volvability
estability
eusability
ntegrity
onfigurability
calability
Algum outro atributo de qualidade?
availability auditability modifiability feasibility
compatibility backwards-compatibility standardscompliance continuity-of-view friendliness
customizability learnability memorability enjoyability
responsiveness schedulability verifiability
analyzability reparability adaptability integrability
interoperability predictability extensibility
dependability safety portability survivability
expendability expandability extensibility
distributability flexibility
Performance
• Pode se manifestar de
diferentes formas:
– Latência
– Rendimento
– Eficiência de memória
• Diferentes métricas de
desempenho devem ser
aplicadas a diferentes
partes do sistema
Usability
• Usabilidade apresenta
vários aspectos:
– Aprendizagem
– Atratividade
– Tempo para completar a
tarefa
– Taxa de erros
• Para um bom resultado,
deve ser analisado por um
perito em usabilidade
Reliability
• Um campo complexo:
Availability =
– Falhas de hardware/software
– Mean time to failure (MTTF)
– Mean time to repair (MTTR)
• Demandas por Reliability
dependem de sua
criticalidade:
– Indesejável
– Perda de receita
– Perda de vida
MTTF
MTTF+MTTR
Reliability
• Conceito varia para sistemas
diferentes:
– Sistemas financeiros podem se
tornar indisponíveis, MAS nenhum
dado pode ser perdido
– Sistemas de Telecom podem
perder dados MAS devem se
recuperar agilmente
– Sistemas de controle devem
manter o controle, em qualquer
situação
• Capacidade de recuperação
Criticality
• Consequência do sistema de falha
– Não-crítica
• Perturba a atividade
– Baixa
• Perda de negóco, mas não séria
– Média
• Perda de longo prazo para o negócio
– Alta
• Prejuízo, perda de vida, etc.
Security
• Todo sistema trata de
alguma maneira:
– Ataque externo (network)
– Fragilidade da política
– Integridade dos dados
• Segurança é onerosa
• Técnicos especializados
podem ajudar
Endereçando atributos de
qualidade
• Narrativas (ou
cenários)
• Comportamento
• Patterns (padrões)
• Estilos
• Táticas
Narrativas
• Uma narrativa ou Preciso de um editor que “escute” minhas
palavras e gere um histórico com meus
cenário que
discursos… a cada 15 minutos de fala
reforça o atributo deve ser gerado um documento
de qualidade
buscado
– Contexto
– Ação
– Resposta
Deve ser mensurável!
Performance
“A consulta no caixa eletrônico
deve gerar um retorno em menos
de 2 segundos.”
Referências e Leituras
Recomendadas
• "Architectural Design." Chapter 3 of A Software
Architecture Primer, by John Reekie and Rohan
McAdam.
• Michael Hirsch, ``Making RUP agile,'' OOPSLA
2002 Practitioners Reports, 2002.
• William J. Brown, Hays W. McCormick III, and
Scott W. Thomas. ``One Size Fits All,'' in
AntiPatterns in Project Management, pp
319--366. John Wiley and Sons, 2000.
• Frederick P. Brooks Jr. The Design of Design.
Turing Award Lecture, 2001.
Visões contempladas na
arquitetura de software
Um elefante…
Um arpão!
É como um
leque!
Uma
parede!
Uma
árvore!
Uma
corda?
Uma cobra!
Baseado numa fábula indiana.
Um sistema de software…
Como vai funcionar a
funcionalidade de
mineração de dados?
Quais as vantagens
estratégicas ?
E as
atividades
de tempo
real?
Vamos ver o
deployment
Visões da arquitetura
Uma visão expressa um aspecto
particular da arquitetura
Visão conceitual
Implementação
Domain-level responsibilities
Execução
Estrutura Build-time
Estrutura Run-time
Alguns autores recomendam a
construção de várias visões… outros
não…
Componentes e conectores
Um componente relaciona
um conjunto de
responsabilidades
Exemplos de responsabilidades:
•PlayBackClipSequence
•SynchronizeWithVideo
•PrefetchClips
Um conector indica a
comunicação entre
componentes
A arquitetura conceitual estrutura o sistema em
termos de responsabilidades no nível do domínio
Interfaces externas
Interfaces
externas
(incluindo
sistemas legados)
Interfaces essenciais
com hardware
Algumas
restrições físicas
do sistema
conhecidas
Nota: Um stakeholder não é um sistema externo!
Projetando uma arquitetura?
Atributos de
qualidade
Requisitos do
negócio
Requisitos
funcionais
Não desista…
Design é um
processo iterativo.
A cada passo,
descobre-se mais
sobre o problema, e
mais ainda sobre a
solução.
Vamos iniciar com
um procedimento
simples…
1. Busque uma narrativa do
sistema
A Sapataria Gomes pretende ter um plano de propaganda utilizando
os mecanismos tradicionais, mas que necessita de um site web para
ser o local central no qual os clientes podem conhecer os modelos e
ordenar calçados com medidas e estilos customizados. Eles também
querem usar o site web como interface de entrada para o sistema
financeiro.
O gerente da Sapataria Gomes explicou:
“O que nós queremos é desenvolver um kit com informações básicas
para envio aos nossos clientes e receber de volta o seu pedido.
Nos últimos anos, nós aprendemos muito sobre como ofertar calçados
customizados e montamos o kit. Assim que recebemos as medidas e
preferências dos clientes, nós podemos fabricar qualquer sapato –
todos customizados – aplicando padrões de material, cores e
acabamentos!”
2. Identifique conceitos chaves
A Sapataria Gomes quer fazer publicidade utilizando meios
convencionais, mas requerem um website como local central no qual
os clientes podem obter informações sobre o kit base, entender os
padrões existentes, e solicitar seu sapato customizado. Eles também
querem usar o website como interface para o sistema financeiro.
O Gerente da Sapataria Gomes disse:
“Queremos dissmeinar o kit base para nossos clientes e receber um
retorno deles. … Nós podemos produzir qualquer sapato aplicando
uma grande variedade de padrões …!”
3. Refine os componentes
Propaganda
- conceito abstrato  X
Website- implementação  ?
Clientes
- stakeholder  Cliente do sistema contábil +
Página personalizada
Faixa de cliente  Diversidade de produto
Kit base  Medidas históricas de clientes
Sapato customizado 
Pedido do sapato

Sistema contábil – sistema externo  Acct I/F
Sapato produzido – sistema externo  Shoe production
Padrões e acabamentos – parte do Kit base
4. Projete e conecte
HTTP
Cliente solicita
Página person.
Medidas dos
clientes
Templates
Acct I/F
Pedido
Página pública
Kit base
Variedade Produtos
Produção calçados
Este é o ponto de partida
Phase 1
Extract
domain
elements
Phase “N”
Restructure
for qualities
Elaborate
functionality
Outras iterações deverão melhorar a arquitetura de
forma a melhor mapear as funcionalidades e os
atributos de qualidade
Refine a arquitetura
• Acrescente ou
quebre
componentes
• Explicite melhor as
responsabilidades
• Identifique os
estereótipos
• Crie os modelos
de dados
• Explore os
comportamentos
Um componente é
um conjunto de
responsabilidades
relacionadas.
Quebre o
componente se as
responsabilidades
não se relacionam
entre si …
MuitoPesada
Devem ser contempladas
as demandas de
desempenho e
disponibilidade
Estereótipos conceituais
• Um componente
tem algum tipo de
responsabilidade
especial?
– Interface
– Armazenamento
persistente
– Tempo de
resposta
Um estereótipo indica que o componente (uma
classe) possui algumas propriedades ou atributos.
Um exemplo de estereótipo
User
Consoles
Audio In
Recording and
Clip Processing
Disk
Recorders
Track and Scene
Construction
Clip and Track
Libraries
Track
Playback
Audio Out
Um diagrama que sintetiza aspectos da
arquitetura. É útil para auxiliar na
compreensão de aspectos mais complexos.
Video Sync
Arquitetura da Sapataria Gomes
com estereótipos
HTTP
Personal
Page
Order
shoes
Public
Page
Customise
shoes
Shoe
production
Acct I/F
Customer
accounts
Browse
products
Templates
Customer
meas.
Product
range
Modelos de dados
• Um modelo de
dados captura a
estrutura
essencial do
dado
– Dados e
conectores
– Dados
persistentes
Student
enrolled-in
0..*
ID : integer
Course
name : String
0..*
currently-taking
0..*
Subject
ID : integer
points : integer
O que é um comportamento
Um sistema
envolve
funcionalidades,
uma estrutura
e comportamentos
• Comportamento reúne um conjunto de ações
que o sistema executa
• Podem ser explorados da seguinte forma:
– Papel a ser desempenhado
– Casos de Uso
– Diagramas de sequência
Como podemos explorar mais?
Viz configuration
Web UI
Viz UI
Update throttle
Webviz data
Update manager
Requested data
Data query
Analyzed data
Analyzer
Discovered data
What to search for
Agent
Database
Visualization data
Visualizer
Viz structuring
Visualization
toolkit
Viz rendering
O sistema deve ter um
comportamento em
resposta a uma atividade
definida nas narrativas
Explore eventos das narrativas
Pedro trabalha na UFCG. Ele prefere
escolher o estilo de calçados. Ele ouviu falar
da Sapataria Gomes e quer experimentar.
Ele navega no site e escolhe alguns
padrões. Ele prefere algo em tons claros de
um couro liso num solado confortável. Ele
preenche dados com suas preferências. Ele
não quer fazer o pedido final ainda, ele
deixa o pedido numa lista de produtos
desejados.
browseWebsite
customiseShoe
saveToWishList
Eventos definem mapas de casos
de uso
• Casos de uso ajudam a
visualizar o fluxo
– Mostra a sequência de
atividades
– Atividade responde a um
evento
– Cada vez que um evento
se dá, exercita-se uma
responsabilidade
EventName
RespA1
RespB3
CompA
CompB
RespC2
CompC
Data
Mapas de caso de uso auxiliam a compreender o comportamento macro
Notação casos de uso
Continuation
SEQ-fork
AND-fork
OR-fork
Sapataria Gomes (1)
BrowseRange
HTTP
Personal
Page
Order
shoes
Public
Page
Customise
shoes
Shoe
production
Acct I/F
Customer
accounts
Browse
products
Templates
Customer
meas.
Product
range
Sapataria Gomes (2)
customiseShoe
HTTP
Personal
Page
Order
shoes
Public
Page
Customise
shoes
Shoe
production
Acct I/F
Customer
accounts
Browse
Uma conexão
é
necessáriaproducts
aqui?
Templates
Customer
meas.
Product
range
O que não fazer…
Um AntiPadrão que ocorre
frequentemente
nas arquiteturas de software…
Um anti-padrão descreve uma solução indesejável para um
conjunto de fatores contextuais recorrentes. Também ajuda a
descrever como refatorar tal situação e obter uma solução
desejável.
Versão object-oriented
• Uma classe
controller rodeada
por classes
simples
• Um procedimento
comum no mundo
OO
• Obtida de
requisitos que
ditam soluções
procedurais
• Um resultado
pobre em termos
de evolução
Simple
Class B
Simple
Class A
Everything Else
Simple
Class C
Simple
Class D
Simple
Class E
Versão arquitetural
• Um aplicação complexa
ou componente lógico
rodeado por componentes
de interface ou dados
• Levam nomes como
“controller” ou “manager”
• Indicam a incapacidade
de decompor o sistema
em função das
responsabilidades
retiradas do domínio
Courses
Personal
page
System
controller
Course
data
User
data
Refatoramento
• Re-design object-oriented
– Rever comportamentos
– Identificar “lumps”
– Agregar classes simples relacionadas
entre si
• Re-design arquitetural
– Identificar todas as responsabilidades
– Obter múltiplos componentes baseados
nas responsabilidades
• Ou ainda:
– Jogar fora e reiniciar
AntiPatterns compilam experiências
do mundo real na forma de
problemas recorrentes & indicam
soluções
Referências e Leituras
Recomendadas
• "Conceptual Architecture." Chapter 4 of A
Software Architecture Primer, by John Reekie
and Rohan McAdam.
• Phillippe Kruchten, " Architectural Blueprints—
The “4+1” View Model of Software Architecture",
in IEEE Software 12 (6) November 1995, pp. 4250.
• R. J. A. Buhr, A. Hubbard,"Use Case Maps for
Engineering Real Time and Distributed
Computer Systems: A Case Study of an ACEFramework Application", in IEEE 1996.