View
111
Download
2
Category
Preview:
Citation preview
Arquitetura de SoftwareIntroduçã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 1Lado Leste
Time 2Link A
Time 3Link B Tim
e 4
Circular
Time 5
Lado Sul
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 globaldo 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
Referências
http://www.bredemeyer.com http://www.ewita.com http://www.extra.research.philips.com/
natlab/sysarch/index.html
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:NomeDescrição do ProblemaSoluçãoConseqüê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
Recommended