Arquitetura de Software Introdução

Por quê? O que? Como? Onde? e

Quem?

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.

Iremos construir um shopping?

Time 1

Lado Leste

Time 2

Link A

Time 3

Link B

Aqui um exemplo de uma

arquitetura base e seus

requisitos. É só construir

ela!

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

– 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

(escopo amplo)

Não arquitetural Foco da

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 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ócioEstratégia da arquiteturaEstraté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

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

Visão global

do sistema

Esquema

para os

desenvolv:

•preciso

•Sem

ambigui-

dade

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

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.

Qualidades do

sistema:

encapsulação e

separação de

papéis

Mecanismos e

interações entre

componentes

Topologia do

sistema/recursos

e concorrência

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

Padrões de Desenvolvimento

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á existentes

Motivação

O.O. explora estruturas de design que promovem:

Abstração

Flexibilidade

Modularidade

Elegância

O problema seria a captura, comunicação e aplicação deste conhecimento

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

Traduz experiência em desenvolvimento

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

Utiliza a simbologia da UML

Padrões GoF

Adapter

Facade

Composite

Bridge

Singleton

Observer

Mediator

Proxy

Chain of Responsibility

Flyweight

Builder

Factory Method

Abstract Factory

Prototype

Memento

Template Method

State

Strategy

Command

Interpreter

Decorator

Iterator

Visitor

Model-View-Controller

Adapter

Converte a interface de uma classe naquela esperada pelos clientes

operacaoAlvo() deve executar metodoNegocios()

cd Adapter

Cliente«interface»

Alvo

+ operacaoAlvo() : void

Adapter

+ operacaoAlvo() : void

ClasseNegocios

+ metodoNegocios() : void

«realize»

Facade

Oferece uma interface única para um conjunto de interfaces

Simplifica a utilização dos subsistemas

cd Facade

Aplicação Facade

+ comprar() : void

+ cadastrar() : void

Carrinho

+ acrescentar() : void

+ remover() : void

+ totalizar() : void

Usuario

+ adicionar() : void

+ autorizar() : void

Produto

+ cadastrar() : void

+ atualizarEstoque() : void

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)

cd Singleton

Singleton

- instancia: Singleton

- Singleton() : void

+ getInstancia() : Singleton

+ operacao1() : void

+ operacao2() : void

Proxy

Método para que um objeto possa controlar o acesso a outro

Normalmente utilizado em objetos distribuídos

cd Proxy

Cliente Proxy

+ operacao() : void

ClienteRemoto Stub

+ operacao() : void

Skeleton

+ serviço() : void

RemoteInterface

ObjetoNegocios

+ operacao() : void

ObjetoRemoto

+ operacao() : void

«realize»«realize»

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

cd Flyweight

FlyweightFactory

- flyweightPool: Collection

+ getFlyweight(Key) : Flyweight

«interface»

Flyweight

+ operacao(Estado) : void

FConcreto

- estadoImutavel: Estado

+ operacao(Estado) : void

FConcretoNaoCompartilhado

- estadoMutavel: Estado

+ operacao(Estado) : void

«realize» «realize»

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

cd Abstract Factory

Abstract

Implementation

AbstractFactory

+ criarClasse1() : ClasseAbstrata1

+ criarClasse2() : ClasseAbstrata2

«interface»

ClasseAbstrata1

+ operacao1() : void

«interface»

ClasseAbstrata2

+ operacao2() : void

FabricaConcreta

+ criarClasse1() : ClasseAbstrata1

+ criarClasse2() : ClasseAbstrata2

ClasseConcreta1

+ operacao1() : void

ClasseConcreta2

+ operacao2() : void

«realize» «realize»

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

«realize» «realize» «realize»

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

independentes, relacionadas à persistência,

interface visual e regras de negócios

Padrões J2EE

Front Controller

View Helper

Composite View

Service to Worker

Dispatcher View

Intercepting Filter

Value Object

Session Facade

Composite View

Value Object Assembler

Value List Handler

Service Locator

Business Delegate

Data Access Object

Service Activator

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)

cd Front Controller

Cliente

Serv let

+ requisicao() : void

«interface»

FrontController

+ requisicao() : void

Composite View

Cria uma interface visual complexa a partir de interfaces

menores

Tipicamente utilizado em portais

cd Composite View

CompositeViewView1 View2

BasicView

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

lookup / create

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

(CMT)

cd SessionFacade

SessionFacade

Entity1

Entity2

Cliente

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 de serviços, sendo apoiado por uma fila de mensagens