Projeto de Arquitetura (Estilos Arquiteturais & Princípios e Padrões)

Arquitetura
de So-ware Parte II
Centro de Inform-ca - Universidade Federal de Pernambuco Sistemas de Informao Vinicius Cardoso Garcia vcg@cin.ufpe.br Slides originais elaborados por Ian Sommerville
O autor permite o uso e a modicao dos slides para ns did-cos
Es-los, Princpios e Padres
PROJETO DE ARQUITETURA DE SOFTWARE

[if977] Engenharia de SoOware - SI - CIn - UFPE 2
Es=los Arquiteturais
A arquitetura de um sistema pode aderir a um ou mais es=los arquiteturais
Um es-lo dene os -pos de elementos que podem aparecer em uma arquitetura e as regras que regem a sua interconexo
Esses es-los pode simplicar o problema de denio de arquiteturas de sistema. A maioria dos sistemas de grande porte adere a vrios es-los Es-los arquiteturais = modelos arquiteturais
Exemplos de Es=los Arquiteturais

Cliente-Servidor Em camadas Filtros e dutos (pipes and lters) Baseado em repositrio Orientado a eventos (publisher/subscriber) Transferncia Representacional de Estado (REST) Objetos distribudos C2
Es=los Arquiteturais e Escolhas de Projeto

Um es-lo arquitetural representa um conjunto de decises (escolhas) de projeto
Conjunto de caracters-cas comuns a diversos sistemas nos quais as mesmas escolhas foram feitas
Padres arquiteturais
Um sistema aderente a determinado es-lo ganha" as caracters-cas inerentes a ele
Es-los podem ser usados para descrever uma determinada arquitetura

Foco nas solues de projeto e no em sua documentao
Organizao de sistema
Reete a estratgia bsica que usada para estruturar um sistema Exemplos:
O es-lo de repositrio de dados compar-lhados; Es-lo de servios e servidores compar-lhados; Es-lo de mquina abstrata ou em camadas Orientado a objetos (ou Objetos Distribudos) Pipes and Filters ou Pipelining
Classicao para ns de estudo

Es=lo de repositrio
Sistemas cujas partes precisam trocar dados com frequncia:
Dados compar-lhados podem ser man-dos em um banco de dados central e acessados por todos os subsistemas Cada subsistema mantm seu prprio banco de dados e passa dados para outros subsistemas
Podem usar uma abstrao de repositrio centralizado Implementao distribuda
[if977] Engenharia de SoOware - SI - CIn - UFPE
Arquitetura de conjunto de ferramentas CASE
Ian Sommerville, Engenharia de SoOware, 8. edio. Captulo 11 [if977] Engenharia de SoOware - SI - CIn - UFPE 8
Caracters=cas do Es=lo Arquitetural de Repositrio

Vantagens
uma maneira eciente de compar-lhar grandes quan-dades de dados Dados aderem a uma representao comum Simplica a projeto de aplicaes fortemente baseadas em dados
Tanto para troca de info. quanto para armazenamento
Desvantagens
Os subsistemas devem estar de acordo com um modelo de dados padronizado A evoluo de dados dipcil e dispendiosa; Diculdade para distribuir de forma eciente.
Es=lo Cliente-Servidor
Mostra como dados e processamento so distribudos por uma variedade de componentes. Servidores independentes que fornecem servios tais como impresso, transferncia de arquivos, gerenciamento de dados, etc. Clientes u-lizam esses servios. Clientes e servidores normalmente se comunicam atravs de uma rede
Diversas tecnologias de comunicao so possveis
Biblioteca de lmes e fotograas
Caracters=cas do Es=lo Cliente- Servidor

Vantagens
Separao de interesses Inerentemente distribudo
Balanceamento de carga, tolerncia a falhas
Desvantagens
fcil adicionar novos servidores ou atualizar servidores existentes. Gerenciamento redundante em cada servidor; Nenhum registro central de nomes e servios pode ser dipcil descobrir quais servidores e servios esto disponveis Requisies e respostas casadas
Modelo de Mquina Abstrata (Em Camadas)

Organiza o sistema em um conjunto de camadas (ou mquinas abstratas)
Cada uma fornece um conjunto de servios Cada camada cliente da camada subjacente
Generalizao do es-lo Cliente-Servidor

No precisa ser distribudo
Apia o desenvolvimento incremental dos subsistemas em camadas diferentes.

Ex. Se mudarmos a camada de negcios, s as camadas acima precisam ser modicadas
Sistema de gerenciamento de verses
Caracters=cas do Es=lo em Camadas

Vantagens
Facilidade de compreenso Facilidade de manuteno Desenvolvimento independente
Desvantagens
Duplicao de funcionalidade s vezes dipcil estruturar um sistema atravs de camadas
comum que a estruturao seja violada
Overhead de implementao e desempenho

Es=lo Arquitetural de Objetos

Sistema como um conjunto de objetos fracamente acoplados e com interfaces bem denidas
Cada objeto oferece um conjunto de servios
No nvel arquitetural, frequentemente empregado na construo de sistemas distribudos

Objetos distribudos
Uma implementao OO no implica em uma arquitetura OO

Sistema de processamento de faturas
Caracters=cas do Es=lo Arquitetural de Objetos

Vantagens
Objetos so fracamente acoplados devido ao uso de interfaces Linguagens de implementao orientada a objeto so amplamente usadas.
Desvantagens
Mudanas de interface tm alto impacto No envolve restries topolgicas, o que pode dicultar a manuteno
Dependncias entre objetos no so limitadas
Es=lo Dutos e Filtros (Pipelining)

Originrio de sistemas operacionais UNIX e do projeto de compiladores Transformaes funcionais processam entradas para produzir sadas.
Componentes so chamados de ltros Conectores so dutos (pipes)
-l para aplicaes de processamento de informao que interagem pouco com usurios Variao distribuda: processamento de streams
Sistema de processamento de faturas
Caracters=cas do Es=lo Dutos e Filtros

Vantagens
Apia reuso de transformaes. fcil adicionar novas transformaes. rela-vamente simples implementar como sistema concorrente ou seqencial.
Desvantagens
Requer um formato comum para a transferncia de dados ao longo do pipeline No apropriado para aplicaes intera-vas
Mais especicamente: s apropriado para realizar processamento sequencial
Fluxo de Controle
Es-los arquiteturais relacionados com o uxo de controle entre os componentes arquiteturais Controle centralizado
Um subsistema tem responsabilidade global pelo controle e inicia e pra outros sistemas
Controle baseado em eventos

Cada componente responde a eventos gerados por outros subsistemas
Controle centralizado
Um componente responsvel pelo gerenciamento da execuo de outros componente. O es-lo Chamada-Retorno
Controle se inicia no topo de uma hierarquia de subro-nas e move-se para baixo na hierarquia. Pode ser sequencial ou concorrente
O es-lo de Gerenciador
Aplicvel a sistemas concorrentes e de tempo real Um componente controla a parada, o incio e a coordenao de outros processos de sistema
Chamada-Retorno
Gerenciador para um Sistema Tempo Real
Comunicao entre o Controlador e os outros componentes pode ser baseada em eventos, chamadas de procedimentos, etc.
Sistemas orientados a eventos

Dirigidos por eventos gerados externamente
O 'ming dos eventos est fora do controle dos componentes que os processam
Es-lo Publisher/Subscriber
Eventos so transmi-dos a todos os componentes. Qualquer componente interessado pode respond-los
Es-lo Orientado a Interrupes

Usado em sistemas de tempo real Interrupes so detectadas por tratadores e passadas por outro componente para processamento.
Modelo Publisher/Subscriber
efe-vo na integrao de componentes em computadores diferentes em uma rede
Desacoplamento espacial e temporal Componentes no sabem se um evento ser tratado e nem quando ser.
Alguns componentes (publishers) publicam eventos Componentes (subscribers) registram interesse em eventos especcos e podem trat-los A pol-ca de controle no embu-da no tratador de eventos e mensagens
Publisher/Subscriber
Es=lo Orientado a Interrupes

Usado em sistemas de tempo real onde a resposta rpida para um evento essencial Existem -pos de interrupes conhecidos
Um tratador denido para cada -po
Cada -po associado a uma localizao da memria

Uma chave de hardware causa a transferncia de controle para um tratador.
Permite respostas rpidas, mas complexo para programar e dipcil de validar.

Controle dirigido a interrupes
Arquiteturas de Referncia
Derivadas de um estudo de domnio de aplicao, ao invs de sistemas existentes. Podem ser usadas como base para a implementao de sistemas (no o uso principal) ou comparao de sistemas diferentes.
Atua como um padro com relao ao qual os sistemas podem ser avaliados.
Exs.
Modelo OSI para sistemas de comunicao Organizao tradicional de compiladores em vanguarda e retaguarda (e seus elementos internos)
Modelo de referncia OSI
Arquitetura de um Compilador
33
PRINCPIOS ARQUITETURAIS E PADRES DE PROJETO

Slides originalmente preparados pelo prof. Fernando Castor Filho
Princpios
Quais princpios arquiteturais voc j viu aplicados a projetos de soOware?
35
Princpios
Arquitetura em camadas, sem regras de negcio nas vises (apresentao), interfaces, injeo de dependncia, alta coeso, baixo acoplamento, ACID (Atomicidade, Consistncia, Isolamento e Durabilidade), componentes stateless, modelo de domnio limpo, sempre use stored procedures, nunca use stored procedures, no reinvente a roda,
Princpios
ATENO!

Princpios so muito bons, mas tenha certeza deles serem realistas e no tenham um impacto nega-vo na arquitetura
37
Princpios da Orientao a Objetos

Coeso alta e Acoplamento baixo
Classes devem ter um conjunto pequeno e bem- denido de responsabilidades Alm disso, devem depender umas das outras o mnimo possvel Implicam em facilidade de manuteno e compreenso
38

Desenvolva para uma interface e no para uma implementao
39

Prera composio de objetos a herana
Reuso caixa branca vs. reuso caixa preta
Herana quebra o encapsulamento
Maior exibilidade
Estrutura do sistema pode mudar em tempo de execuo
Maior coeso
Classes mais focadas em um nico obje-vo
Composio implica em mais classes
40

Um mdulo deve ser aberto para extenso e fechado para modicao
Subclasses devem ser capazes de subs=tuir suas superclasses

Elipses vs. Crculos Listas ligadas vs. Pilhas e Filas

Dependncias entre pacotes no devem formar ciclos
42

Dependa na direo da estabilidade
MELHOR!
PIOR!

Crie classes apenas quando necessrio
Pessoa
Funcionrio Funcionrio
Gerente
Vendedor
44

Crie classes apenas quando necessrio
Pessoa
Funcionrio Funcionrio
Gerente
Vendedor
Classes devem encapsular informao que manipulada em conjunto e que evolui em conjunto
45
Padres de Projeto
Escritores de livros, histrias em quadrinhos e roteiros raramente inventam novas histrias Idias frequentemente so reusadas
Heri Trgico => Hamlet, Macbeth An--Heri => Aquiles, Sawyer, Lobo
Proje-stas tambm reu-lizam solues, de preferncia as boas

Experincia o que torna uma pessoa um expert
Problemas so tratados de modo a evitar a reinveno de solues

O que um Padro de Projeto?

Abstrao de uma soluo de projeto recorrente Envolve dependncias, estruturas, interaes e convenes rela-vos a classes e objetos Documentam experincia no projeto de sistemas de soOware Tornam projetos OO mais exveis, elegantes e reusveis
47
Denio de Alexander
... describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice
Alexander, Christopher, Sara Ishikawa and Murray Silverstein A Pattern Language: Towns. Buildings, Construction. Oxford University Press, USA, 1977.
Existem Muitos Tipos de Padro!

Padres de gerenciamento
Ex. Mtodos geis como SCRUM e XP
Padres organizacionais Padres de anlise Padres arquiteturais => Es=los Arquiteturais Padres de implementao => Idioms
Classicao dos padres GoF

Classicao feita a par-r do obje-vo principal do padro Padres fundamentais Padres de criao (crea'onal)
Aplicao de princpios bsicos de orientao a objetos Descrevem tcnicas para instanciar objetos Permitem organizar classes e objetos em estruturas maiores Permitem atribuir responsabilidades a objetos
Padres estruturais (structural)
Padres comportamentais (behavioral)
Propriedades dos Padres de Projeto

Padres...
fornecem um vocabulrio comum fornecem uma abreviao para comunicar princpios complexos auxiliam na documentao do projeto do sistema capturam partes essenciais de um projeto de maneira compacta mostram mais de uma soluo fornecem uma soluo exata resolvem todos os problemas de projeto aplicam-se apenas ao projeto orientado a objetos Em computao, surgiram nesse contexto, porm
Padres no
Elementos de um Padro de Projeto

1. Nome do padro
Apelido usado para descrever uma soluo de projeto Facilita discusses de projeto Um padro pode ter vrios nomes dis-ntos
52

2. Problema
Descreve quando o padro pode ser aplicado Pode incluir condies sobre a aplicabilidade do padro (contexto) Sintomas de um projeto inexvel ou inadequado
53

3. Soluo
Descreve elementos do projeto Inclui relacionamentos, responsabilidades e colaboraes No descreve projetos concretos ou implementaes Funciona como um modelo Um es=lo arquitetural nada mais que um padro aplicado no nvel da arquitetura

4. Consequncias
Resultados e compromissos Normalmente classicadas em vantagens e desvantagens Fundamentais para se avaliar a aplicabilidade do padro em determinado contexto Em geral, padres de projeto implicam em maior exibilidade
necessrio avaliar se essa exibilidade necessria
55

5. Usos conhecidos
Padres so solues j testadas em vrios contextos, potencialmente por vrias pessoas Benepcios e desvantagens bem conhecidos! Regra dos trs
Uma ocorrncia um evento isolado Duas podem signicar uma coincidncia Trs fazem um padro
56
Ml=plas Formas de Exibio
Padro Observer
Nome: Observer. Descrio do problema: necessrio representar um mesmo conjunto de dados de diversas maneiras, de modo que mudanas nesses dados se reitam em todos os modos de exibio Descrio da soluo: Mecanismo para que o display seja no'cado de modicaes no estado sem que, para isso, o estado precise conhec-lo Consequncias: Estado e display desacoplados fcil atualizar tanto um display quanto vrios displays Invocaes implcitas podem resultar em erros de programao dipceis de rastrear Exige cdigo extra
O Padro Observer
Usos Conhecidos
AWT do Java Development Kit Diversas partes da implementao da plataforma Eclipse Um grande nmero de arcabouos modernos para a construo de interfaces com o usurio
60
O Padro Strategy
Nome: Strategy Descrio do problema: Dependendo do contexto, necessrio usar algoritmos diferentes para resolver um problema, embora seja desejvel no ter que modicar esse contexto por causa do algoritmo empregado Descrio da soluo: Denir uma interface para todos os algoritmos e fazer com que o contexto conhea apenas essa interface, no suas implementaes Consequncias:
Separa contexto e cliente das implementaes do algoritmo Contexto no est ciente da estratgia usada; o cliente congura o contexto Strategies podem ser subs-tudas em tempo de execuo Normalmente mais efe-vo se usado junto com uma Factory
61
Padro Strategy
62
O Padro Composite
Nome: Composite Descrio do problema: Dados que o programa precisa manipular podem ser tanto elementos atmicos quanto grupos de elementos (podendo conter, inclusive, outros grupos). O programa deveria tratar esses itens de maneira uniforme Descrio da soluo: Denir uma interface compar-lhada tanto por itens atmicos quanto por grupos de elementos e fazer com que o programa lide com ela, sem saber se o objeto subjacente atmico ou um grupo Consequncias:
Trata todos os componentes do mesmo jeito, independentemente da complexidade Novos -pos de componentes podem ser includos com facilidade Pode exigir um nmero grande de objetos
63
Padro Composite
64
O Padro Iterator
Nome: Iterator Descrio do problema: necessrio separar as operaes que sero realizadas sobre uma ou mais estruturas de dados da maneira como essas estruturas de dados sero percorridas Descrio da soluo: Denir uma interface padro para percorrer estruturas de dados em geral e fazer com que seus usurios vejam apenas a interface e no a maneira como a estrutura de dados percorrida Consequncias:
Independncia entre a estrutura de dados e a maneira de percorr-la Ml-plos iteradores => ml-plas maneiras de percorrer uma estrutura de dados Comunicao extra entre o iterador e a estrutura Modicaes estrutura podem criar inconsistncias
65
Padro Iterator
66
O Padro Faade
Nome: Faade Descrio do problema: necessrio disponibilizar uma interface nica simplicada para um conjunto das funcionalidades (interfaces) de uma API ou subsistema, por exemplo. Descrio da soluo: Implementar um Facade demanda denir um conjunto de operaes reduzidas que permita ocultar a complexidade inerente u-lizao de vrias classes de um subsistema (adaptado [SoOware Design Paerns, 2005]). Consequncias:
Esconde do cliente os componentes do subsistema
Reduz o nmero de objetos que os clientes lidam; Torna o subsistema mais fcil de usar;
Fraco acoplamento entre subsistema e seus clientes; No impede que aplicaes usem classes do subsistema, caso elas precisem;
67
O Padro Faade
Faade
68
O Padro Faade
Fonte: hp://www.pg.cefetpr.br/coinf/simone/paerns/facade.php
Mais sobre Padres de Projeto

Dem uma olhada em: hp://en.wikipedia.org/wiki/Design_Paerns O texto sobre padres est legal e tem links para as descries de todos os padres do livro (com cdigo!)
70
Bibliograa
SOMMERVILLE, I. Engenharia de SoOware. 9. Ed. So Paulo: Pearson Educa-on, 2011
Captulos 11 a 14 e 18
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Pakerns: Elements of Reusable Object-Oriented So-ware. 1 ed. Estados Unidos da Amrica: Addison-Wesley, 1995.

Projeto de Arquitetura (Estilos Arquiteturais & Princípios e Padrões)

Enviado por

Dados do documento

Descrição:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Descrição:

Direitos autorais:

Formatos disponíveis

Projeto de Arquitetura (Estilos Arquiteturais & Princípios e Padrões)

Título original:

Enviado por

Descrição:

Direitos autorais:

Formatos disponíveis

Arquitetura

Es-los, Princpios e Padres

PROJETO DE ARQUITETURA DE SOFTWARE

Exemplos de Es=los Arquiteturais

Es=los Arquiteturais e Escolhas de Projeto

Um sistema aderente a determinado es-lo ganha" as caracters-cas inerentes a ele

Es-los podem ser usados para descrever uma determinada arquitetura

Classicao para ns de estudo

[if977] Engenharia de SoOware - SI - CIn - UFPE

Arquitetura de conjunto de ferramentas CASE

Caracters=cas do Es=lo Arquitetural de Repositrio

Biblioteca de lmes e fotograas

Caracters=cas do Es=lo Cliente- Servidor

Modelo de Mquina Abstrata (Em Camadas)

Generalizao do es-lo Cliente-Servidor

Apia o desenvolvimento incremental dos subsistemas em camadas diferentes.

Sistema de gerenciamento de verses

Caracters=cas do Es=lo em Camadas

Overhead de implementao e desempenho

Es=lo Arquitetural de Objetos

No nvel arquitetural, frequentemente empregado na construo de sistemas distribudos

Uma implementao OO no implica em uma arquitetura OO

Sistema de processamento de faturas

Caracters=cas do Es=lo Arquitetural de Objetos

Es=lo Dutos e Filtros (Pipelining)

Sistema de processamento de faturas

Caracters=cas do Es=lo Dutos e Filtros

Controle baseado em eventos

Gerenciador para um Sistema Tempo Real

Sistemas orientados a eventos

Es-lo Orientado a Interrupes

Es=lo Orientado a Interrupes

Cada -po associado a uma localizao da memria

Permite respostas rpidas, mas complexo para programar e dipcil de validar.

Controle dirigido a interrupes

Modelo de referncia OSI

[if977] Engenharia de SoOware - SI - CIn - UFPE

PRINCPIOS ARQUITETURAIS E PADRES DE PROJETO

[if977] Engenharia de SoOware - SI - CIn - UFPE

Princpios da Orientao a Objetos

[if977] Engenharia de SoOware - SI - CIn - UFPE

Princpios da Orientao a Objetos

[if977] Engenharia de SoOware - SI - CIn - UFPE

Princpios da Orientao a Objetos

Composio implica em mais classes

[if977] Engenharia de SoOware - SI - CIn - UFPE

Princpios da Orientao a Objetos

Subclasses devem ser capazes de subs=tuir suas superclasses

Princpios da Orientao a Objetos

[if977] Engenharia de SoOware - SI - CIn - UFPE

Princpios da Orientao a Objetos

Princpios da Orientao a Objetos

[if977] Engenharia de SoOware - SI - CIn - UFPE

Princpios da Orientao a Objetos

[if977] Engenharia de SoOware - SI - CIn - UFPE

Proje-stas tambm reu-lizam solues, de preferncia as boas

Problemas so tratados de modo a evitar a reinveno de solues

O que um Padro de Projeto?

Existem Muitos Tipos de Padro!