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 Time 2 Time 3

Lado Leste Link A Link B

Requisitos:
• estilo típico
• praça da alimentação central
• ...
 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 • Baixo reuso
– no comportamento do – difícil isolar blocos para
sistema reuso
– nas próximas release – blocos são muito
• baixa qualidade específicos (orientados)
– difícil rastrear falhas • problemas éticos
– difícil consertar bugs • perda de market share
• difícil alterar – o concorrente é melhor
– duro atender às mudanças – não há retorno
– custa mais, leva mais
tempo
 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

(escopo amplo) decisão
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 • Alinhamento com o
sistema negócio
• Trade-offs entre – Com a estratégia do
propriedades negócio
– Com o ambiente do
• Integridade do sistema 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
Arquitetura Conceitual
Visão global • Diagramas arquiteturais, especificação informal de
do sistema componentes
• Foco: identificação e alocação de responsabilidades entre
componentes
Arquitetura Lógica
Esquema • Atualiza os diagramas arquiteturais (apresentando as
para os interfaces), especificação interface, especificação de
desenvolv: componentes e guias de utilização
•preciso • Foco: design da interação, mecanismos e protocolos de
conexão; provimento de info contextual para os usuários dos
•Sem
componentes
ambigui-
dade 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 Arquitetura Conceitual
sistema: • Diagramas arquiteturais, especificação informal de
encapsulação e componentes
separação de • Foco: identificação e alocação de responsabilidades entre
papéis componentes
Arquitetura Lógica
• Atualiza os diagramas arquiteturais (apresentando as
Mecanismos e interfaces), especificação interface, especificação de
interações entre componentes e guias de utilização
componentes • Foco: design da interação, mecanismos e protocolos de
conexão; provimento de info contextual para os usuários dos
componentes

Arquitetura Execução
Topologia do • Visão do Processo (via Diagramas de Colaboração)
sistema/recursos • Foco: informa como se dará o comportamento do componente
e concorrência 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