Arquitetura de Software
Introdução
Por quê? O que? Como? Onde? e Quem?
Francilene Garcia
Projeto em Computação I
2009.2
Síntese
• Arquitetura de software é o caminho para:
–
–
–
–
conectar as metas de negócios ao que iremos construir
obter alinhamento
organizar a atividade de produção de código
envolver as diferentes competências de um time
• Arquitetura está muito ligada à vantagem competitiva
• Arquitetura não se obtém facilmente:
– é um trabalho de design não trivial
– cada um tem um papel a desempenhar na sua criação
– é melhor construída por um time pequeno de “arquitetos”
dedicados que dirigem o processo e tomas as decisões
Arquitetura funciona como o “plano de vôo” do desenvolvimento. Ela deve
facilitar o alcance da estratégia de negócio – torna-se a implementação
técnica da estratégia de negócio.
Nós iremos construir um shopping?
Aqui um exemplo de uma arquitetura
base e seus requisitos. É só
construir ela!
Time 1
Lado Leste
Time 2
Link A
Requisitos:
• estilo típico
• praça da alimentação central
• ...
Time 3
Link B
Suponha o seguinte
• O Boulevard Shopping pretende construir uma
nova área. Vários aspectos do novo negócio
foram levantados pelos executivos. É chegado o
momento de traçar os planos e prazos da nova
construção. Eles pretendem uma construção
rápida, pois vários lojistas estão à espera. Os
construtores foram divididos em times. Ao time
mais experiente foi entregue a tarefa de traçar a
arquitetura do novo shopping. Cada parte da
arquitetura foi entregue a um dos time para
construção.
• O que foi obtido ao final?
Certo. Mas nós não entregamos
modelos...
• No negócio software, nós entregamos
código, e temos um certo desconforto em
trabalhar com modelos.
• Porém, se olhamos para o negócio da
construção civil, eles entregam “prédios” e
não plantas e, não iniciam um novo
projeto complexo sem começar por
desenhos de tais estruturas físicas.
Nós construímos o shopping!
Construir uma arquitetura de
software é similar...
• Na construção civil é lugar comum – sente-se a
necessidade de plantas antes de se iniciar uma nova
construção.
• Existem vários aspectos que se relacionam com
integridade, integração entre equipes, consistência nos
detalhes.
• Um plano de atividades é gerado, definindo uma
sequência clara, incluindo aspectos de sua estrutura:
entradas de luz, tolerância a ventos fortes, (em alguns
casos) suportar movimentação de equipamentos
pesados. Ou seja, existem condições típicas e atípicas a
serem consideradas.
• O que resulta de uma arquitetura incompleta?
Adaptações na arquitetura...
É muito fácil obter um “sistema espaguete”!
...as adaptações podem levar ao
caos!
• Tudo começa com as primeiras decisões
de cortes ou extensões na arquitetura,
com a justificativa de melhor atender aos
requisitos. Aumenta o número de ajustes e
o acoplamento cresce a ponto de não se
poder mais isolar os componentes.
• É assim que um sistema deve evoluir?
É a desintegração do sistema, não
sua evolução!
Seria um problema do negócio
Software?
• Um sistema típico de software é perecível,
resultado de:
• incertezas
– no comportamento do
sistema
– nas próximas release
• baixa qualidade
– difícil rastrear falhas
– difícil consertar bugs
• difícil alterar
– duro atender às mudanças
– custa mais, leva mais
tempo
• Baixo reuso
– difícil isolar blocos para
reuso
– blocos são muito
específicos (orientados)
• problemas éticos
• perda de market share
– o concorrente é melhor
– não há retorno
A Arquitetura faz a diferença!
• Uma arquitetura é algo mais que um
“rascunho desenhado” do sistema
• A arquitetura é alinhada a...
Conceitos chaves
• Decomposição do sistema
– Como eu quebro o sistema em partes?
– Tenho todas as partes necessárias?
– As partes se encaixam?
• Trade-offs de interesse
– Aspectos de qualidade mais abrangentes ou
propriedades específicas do sistema (RNF e SLA)
– Relação entre os atributos de qualidade
• Integridade do sistema
Decomposição da arquitetura: as
partes se encaixam?
• Ao atribuir essa tarefa para
o melhor “engenheiro” do
time, que entende de:
– Motor
– Transmissão
– Suspensão
– Etc
• Podemos construir o melhor
carro?
Arquitetura deve ter foco nas
“propriedades mais críticas primeiro”
• Ideia chave: a integridade do sistema não
pode ser alcançada de forma bottom-up
• Você irá precisar de uma visão mais
abrangente do sistema
– Analise os trade-offs existentes para
assegurar que as propriedades críticas do
sistema continuam sendo atendidas quando
você o decompõe em partes
– Projete os mecanismos da arquitetura que
endereçam as propriedades do sistema
Decisões Arquiteturais: Uma
questão de escopo
Quanto mais abrangente a decisão, menos erros podem ser inseridos!
Diferencie decisões de design de decisões de implementação.
Ou seja...
• Se temos em mãos uma dada aplicação, todas as
decisões que podem ser tomadas por projetistas de
componentes ou desenvolvedores devem ser atribuídas
a eles e não surgir como parte da arquitetura. Se o
escopo da arquitetura é uma linha de produtos, então
toda decisão referente a um dado produto deve constar,
pelo menos, na arquitetura do produto se não for
possível constar na arquitetura da linha de produtos.
• Qualquer decisão deve focar no impacto sobre o
sistema – decisões arquiteturais devem focar nas
propriedades de alto impacto nas áreas que estão
altamente alinhadas com a estratégia do negócio.
Escopo das decisões arquiteturais:
Exemplo do Reuso
Escopo das decisões arquiteturais:
Exemplo do Reuso
• Quando focamos num dado produto, todas as
decisões são orientadas para atender às
demandas do respectivo cliente – o que torna
tais componentes menos adequados para
outros produtos.
• Ao construir arquiteturas devemos analisar os
trade-offs de forma mais ampla, adequando-os
aos sistemas globalmente. Decisões sobre
propriedades individuais devem ser
consideradas como parte da arquitetura do
sistema como um todo.
Escopo das decisões arquiteturais:
Impacto
Baixo Impacto
Alto Impacto
Sistêmicas
Não arquitetural Foco da
decisão
(escopo amplo)
arquitetural
Local
Não arquitetural Em geral, não
arquitetural
Prioridades do sistema
• A atenção deve estar voltada para as áreas de
alta prioridade e para os trade-offs entre elas:
–
–
–
–
o negócio (estratégias, competências e recursos)
o mercado (clientes, concorrentes e parceiros)
tecnologia (desafios e oportunidades)
riscos (investimentos em tecnologias e sistemas
legados)
– desafios ao sucesso do sistema (desenvolvimento
em si e do negócio)
Arquitetura de Software: Conceitos
chaves
• Decomposição do
sistema
• Trade-offs entre
propriedades
• Integridade do sistema
• Alinhamento com o
negócio
– Com a estratégia do
negócio
– Com o ambiente do
negócio
• Legado
• Cultura
• Evolução do sistema
– Vida longa!
– Esquema para a estratégia
de implementação
– Lidar com as mudanças,
inevitáveis!
Não esqueça!
• Decisão bottom-up  Estratégia bottom-up
– Pode ser um caminho muito arriscado! Nesse caso a
estratégia real do negócio irá ser resultante das
decisões dos desenvolvedores...
• Estratégia top-down: Estratégia do
negócioEstratégia da arquiteturaEstratégia
da implementação
– A estratégia do negócio é quem dirige a arquitetura,
que é traduzida tecnicamente para suportar toda a
evolução do desenvolvimento.
Por quê isto é tão importante?
• Permite que sejamos
– Mais produtivos
– Mais criativos
– Mais orientados por nossa estratégia
• De forma que podemos ser
– Mais flexíveis, dando retorno ágil
• aos ajustes necessários (mudanças)
• fazendo mais
– Ser um player dominante no mercado
– Estar no negócio, mesmo 5 anos mais tarde
O que é uma arquitetura?
(definição formal)
• “arquitetura é a estrutura do sistema, que
compreende:
– componentes ou partes da implementação
– as propriedades visíveis externamente
desses componentes, e
– as relações entre eles.”
Arquitetura: componentes e
relações
• Componentes
– Blocos (alto nível) do sistema
– Suporta
• Modularidade
• Separação de papéis
– Colaboração entre componentes
• Prover serviços (funcionalidades)
• Num dado nível de serviço (qualidades)
– Interface entre componentes
• Provê encapsulação, com pontos de acesso restritos
– Especificação dos componentes
• Define propriedades visíveis externamente
• Provê guias de utilização
Propriedades visíveis externamente: o
propósito das interfaces
• Interfaces
– Define os pontos de acesso aos componentes
– Facilita o plug-and-play entre componentes
• ameniza restrições entre clientes e provedores
• Serve como um contrato entre provedores de componentes
e clientes
– Define externamente propriedades visíveis
• Uma interface bem definida
– Facilita o entendimento e compreensão do
comportamento do componente e como ele é usado
– Aumenta a produtividade do desenvolvedor
• Foca na montagem e ligação entre componentes através de
suas interfaces
Modelos de arquiteturas
• Ferramentas para apoiar a “criação”
– Explora alternativas e ideias (mais barato que
prototipar ou tentar uma versão teste do
sistema)
– Por exemplo, explorar as colaborações entre
componentes para definir as operações da
interface
• Documentam a arquitetura
– Descritiva ou explícita
– Auxilia na visualização do sistema
Visões da arquitetura
• Clientes diferentes apresentam diferentes
informações sobre suas necessidades
Stakeholders da arquitetura
•
•
•
•
•
•
•
•
•
Gerentes
Arquitetos
Desenvolvedores
QA
Suporte
Marketing
Usuários
Tomadores de decisão (mercado)
Administradores de sistemas
Visões da arquitetura
Visão global
do sistema
Esquema
para os
desenvolv:
•preciso
•Sem
ambiguidade
Arquitetura Conceitual
• Diagramas arquiteturais, especificação informal de
componentes
• Foco: identificação e alocação de responsabilidades entre
componentes
Arquitetura Lógica
• Atualiza os diagramas arquiteturais (apresentando as
interfaces), especificação interface, especificação de
componentes e guias de utilização
• Foco: design da interação, mecanismos e protocolos de
conexão; provimento de info contextual para os usuários dos
componentes
Arquitetura Execução
• Visão do Processo (via Diagramas de Colaboração)
• Foco: informa como se dará o comportamento do componente
em tempo de execução, threads; como eles se comunicam; como
os recursos físicos são alocados.
Endereçando trade-offs
• (re)Lembrando: arquitetura aborda
– a decomposição do sistema em componentes
– foco nas propriedades críticas do sistema e seus
trade-offs
• Trade-offs devem ser endereçados
– Através de padrões arquiteturais
– Estrutura: componentes e interfaces
– Mecanismos: papéis dos componentes e padrões de
interação
• Responsabilidades (atribuídas aos componentes)
• Comportamento expresso nas interações
• fluxo das interações
Visões da arquitetura
Qualidades do
sistema:
encapsulação e
separação de
papéis
Arquitetura Conceitual
• Diagramas arquiteturais, especificação informal de
componentes
• Foco: identificação e alocação de responsabilidades entre
componentes
Mecanismos e
interações entre
componentes
Arquitetura Lógica
• Atualiza os diagramas arquiteturais (apresentando as
interfaces), especificação interface, especificação de
componentes e guias de utilização
• Foco: design da interação, mecanismos e protocolos de
conexão; provimento de info contextual para os usuários dos
componentes
Topologia do
sistema/recursos
e concorrência
Arquitetura Execução
• Visão do Processo (via Diagramas de Colaboração)
• Foco: informa como se dará o comportamento do componente
em tempo de execução, threads; como eles se comunicam; como
os recursos físicos são alocados.
Processo de construção de uma
arquitetura: Objetivos
• Criar uma arquitetura:
– BOA, tecnicamente válida e bem
documentada
– CORRETA, satisfaz aos requisitos dos
stakeholders
– De SUCESSO, como as utilizadas na
construção civil
Processo de construção da
arquitetura
Conclusão
• Uma arquitetura Boa, Correta e de
Sucesso:
– Não aparece “do nada”
– É necessário:
• Planejar (tempo!)
• Documentar e seguir avaliando (não é algo
estático)
• As vezes, joga-se fora e recomeça do zero
• Existe uma contribuição a ser dada por
cada um de nós
Referências
• http://www.bredemeyer.com
• http://www.ewita.com
• http://www.extra.research.philips.com/natl
ab/sysarch/index.html