Arquitetura de Software Introdução. Por quê? O que? Como? Onde? e Quem?

Arquitetura de Software

Introdução

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

Iremos construir um shopping?

Aqui um exemplo de uma arquitetura base e seus requisitos. É só construir ela!

Requisitos: • estilo típico

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.

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

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.

Adaptações na arquitetura...

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

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

A Arquitetura faz a diferença!



Uma arquitetura é algo mais que um

“rascunho desenhado” do sistema

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

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

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

Decisões Arquiteturais: Uma

questão de escopo

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

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

Escopo das decisões arquiteturais:

Impacto

Baixo Impacto

Alto Impacto

Sistêmicas

(escopo amplo)

Não arquitetural Foco da

decisão

arquitetural

Local

Não arquitetural Em geral, não

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

Arquitetura de Software:

Conceitos chaves

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

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 é

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

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

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

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

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

Visões da arquitetura

Stakeholders da arquitetura



Gerentes



Arquitetos



Desenvolvedores



QA



Suporte



Marketing



Usuários



Tomadores de decisão (mercado)

Visões da arquitetura

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

Visões da arquitetura

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.

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

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

Motivação



Orientação a Objetos enfatiza a notação dos

diagramas

 Ótimo para especificação e documentação



Mas O.O. envolve mais que diagramas

 Bons desenhistas nem sempre são bons projetistas



Bons projetistas se apóiam na experiência



O mais poderoso reuso é a reutilização de padrões

 Combina o problema com os padrões de projeto já

Motivação



O.O. explora estruturas de design que

promovem:



Abstração



Flexibilidade



Modularidade



Elegância

Padrões de Desenvolvimento



Abstrai uma solução de projeto reutilizável



Organiza classes e objetos em termos de:

 Dependências  Estrutura

 Interações  Convenções



Nomeia e especifica a solução explicitamente

Padrões de Desenvolvimento



Divide-se em quatro partes:

 Nome

 Descrição do Problema  Solução

 Conseqüências e considerações acerca de sua utilização



Independente de linguagem ou implementação

Adapter

 Converte a interface de uma classe naquela esperada pelos clientes  operacaoAlvo() deve executar metodoNegocios()

Facade

 Oferece uma interface única para um conjunto de interfaces  Simplifica a utilização dos subsistemas

Singleton

 Garantir que uma classe só tenha uma única instância, e prover

um ponto de acesso global a ela

 Precisa de um construtor privado e um método para obter a

instância global (estática)

Proxy

 Método para que um objeto possa controlar o acesso a outro  Normalmente utilizado em objetos distribuídos

Flyweight

 Usar compartilhamento para suportar grandes quantidades de

objetos refinados eficientemente

 Constituem pools, onde a quantidade de objetos pode ser

significativamente inferior ao seu nível de utilização

Abstract Factory

 Prover uma interface para criar famílias de objetos relacionados

ou dependentes sem especificar suas classes concretas

 Exemplo de utilização é o J2EE

Strategy

 Promover diferentes estratégias para resolver um determinado

problema em diferentes condições

 Na prática permite a implementação de diferentes algoritmos

através de diferentes classes

cd Strategy «interface» Strategy + operacao() : void Estrategia1 + operacao() : void Estrategia2 + operacao() : void Estrategia3 + operacao() : void Contexto - strategy: Strategy + requisicao() : void

Mais alguns...

 State: implementa diferentes reações às mudanças

de estado de um objeto

 Decorator: acrescenta responsabilidades

dinamicamente aos objetos

 Iterator: acessa os elementos de uma coleção

sequencialmente

 MVC: divide o aplicativo em três camadas

Padrões J2EE

 Value Object Assembler  Value List Handler

Front Controller

 Centraliza o controle das requisições do cliente, permitindo um

único ponto de manipulação na entrada

 Aumenta a segurança no acesso

 Define a saída visual correta (Front Controller / View Controller)

Composite View

 Cria uma interface visual complexa a partir de interfaces

menores

 Tipicamente utilizado em portais

cd Composite View

CompositeView View 1 _{View 2}

Business Delegate

 Desacopla camadas de apresentação e serviços

 É utilizado um como fachada para cada SessionBean

 Normalmente precisa de um localizador de serviços (JNDI)  Este processo retira o código de localização do cliente

cd Business Delegate

Cliente BusinessDelegate BusinessServ ice

LookupServ ice

uses

Session Facade

 Desacopla camadas de apresentação e modelo (EntityBean)  Reduz as chamadas remotas do cliente, concentrando no

SessionBean

 Transações implementadas no SessionBean ou no Container

Mais alguns...

 Value Object: concentra as propriedades referentes

às entidades, permitindo o envio de um objeto com informações completas e, conseqüentemente,

reduzindo o número de chamadas

 Data Access Object: concentra as operações de

persistência, desacoplando as camadas de

modelo(Entity), e permitindo um meio comum e genérico de acesso aos dados armazenados

 Service Activator: utilizado na execução assíncrona