Arquitetura lógica e padrões

P R O F. A N TO N I O PA S S O S

Apresentação
Esta apresentação integra os materiais didáticos do curso online Desenvolvimento de aplicativos desktop utilizando padrões. Para saber mais sobre este curso, acesse http://ead.antoniopassos.net. Atenciosamente, Prof. Antonio Passos

Agenda
y Definição de arquitetura y Visões de arquitetura y GRASP Padrões de Princípios Gerais para Atribuição de

Responsabilidades 
   

Especialista na informação; Criador; Coesão alta; Acoplamento fraco; Controlador Padrão camada

y Padrões arquiteturais y Padrões microarquiteturais 
   

Modelo de domínio; Roteiro de transação; Gateway de tabela de dados; Factory method

Definição de arquitetura
y A arquitetura lógica de um software resume a organização e a funcionalidade

dos principais elementos de software. y A arquitetura lógica descreve o sistema em termos de sua organização conceitual em camadas, pacotes, principais frameworks, classes, interfaces e subsistemas. y A arquitetura lógica fornece... 
 

A organização e a estrutura dos principais elementos do sistema; As responsabilidades de larga escala dos sistemas e subsistemas, e suas colaborações; As motivações ou o raciocínio que mostra porque o sistema é projetado de determinada maneira.

Visões de arquitetura
1.
a)

Lógica
Descreve a organização conceitual do software em termos das camadas, dos subsistemas, dos pacotes, dos frameworks, das classes e das interfaces mais importantes. Mostra cenários de realização de casos de uso destacados (como diagrama de interação) que ilustram aspectos importantes do sistema

b)

2. 3. 4. 5. 6.

Processo Implantação Dados Caso de uso Implementação

GRASP
y GRASP é a sigla de General Responsibility Assignment Software Patterns

(Padrões de Princípios Gerais para Atribuição de Responsabilidades) y São nove os padrões GRASP:
1. 2. 3. 4. 5. 6. 7. 8. 9.

Especialista na Informação (Information Expert) Criador (Creator) Coesão Alta (High Cohesion) Acoplamento Fraco (Low Coupling) Controlador (Controller) Polimorfismo () Invenção Pura Indireção Variações Protegidas

GRASP

Especialista na informação
y Problema

Qual é o princípio básico de atribuição de responsabilidades a objetos?
y Solução

Atribuir uma responsabilidade ao especialista na informação, ou seja, àquele que tem a informação necessária para satisfazer a responsabilidade.
y Benefícios:

O encapsulamento de informações é mantido, uma vez que os objetos usam sua própria informação para executar tarefas. Isso favorece o acoplamento fraco, que conduz a sistemas mais robustos e fáceis de manter. O comportamento está distribuído entre as classes que têm as informações necessárias; assim são estimuladas definições de classes leves , de maior coesão, mais fáceis de compreender e manter. Deste modo, obtém-se uma coesão alta.
y Também conhecido como...

Colocar as responsabilidades com os dados , quem sabe faz , fazê-lo eu mesmo , colocar serviços com os atributos com os quais eles trabalham

GRASP

Criador
y Problema

Quem deve ser responsável pela criação de uma nova instância de uma classe?
y Solução

Atribua à classe B a responsabilidade de criar uma instância da classe A se uma das seguintes condições for verdadeira:  B agrega objetos de A;  B contém objetos de A;  B registra instâncias de objetos de A;  B usa de maneira muito próxima objetos de A;  B tem os dados de iniciação que serão passados para A quando ele for criado .
y Benefícios 

Favorece o acoplamento fraco, o que implica em menor dependência para a manutenção e maiores oportunidades de reutilização.

GRASP

Acoplamento fraco
y Problema 

Como favorecer a dependência baixa, o pequeno impacto à mudança e aumentar a reutilização? Atribuir uma responsabilidade de maneira que o acoplamento permaneça fraco. Não é afetado por mudanças em outros componentes; É simples de entender isoladamente; É conveniente para reutilização

y Solução 

y Benefícios 
 

GRASP

Coesão alta
y Problema 

Como manter a complexidade sob controle? Atribuir uma responsabilidade de maneira que a coesão permaneça alta. Mais clareza e facilidade de compreensão no projeto; Simplificação da manutenção e do acréscimo de melhorias; Favorecimento do acoplamento fraco; A granularidade fina de funcionalidades altamente relacionadas aumenta o potencial de reutilização, porque uma classe altamente coesa pode ser usada para uma finalidade muito específica.

y Solução 

y Benefícios 
  

GRASP

Acoplamento fraco X Coesão alta
y Má coesão geralmente traz mau acoplamento, e vice-versa. A coesão e o

y

y y y

acoplamento são o yin e yang da engenharia de software, por causa da sua influência interdependente; Acoplamento fraco e coesão alta são princípios fundamentais no projeto de software, e como tal devem ser apreciados e aplicados por todos os desenvolvedores. São princípios que devemos ter em mente durante todas as decisões de projeto; São objetivos subjacente a serem continuamente considerados; São padrões de avaliação que o projetista aplica quando avalia todas as decisões de projeto.

GRASP

Controlador
y Problema 

Quem deve ser responsável por tratar um evento de sistema? Atribuir a responsabilidade de receber ou tratar uma mensagem de um evento do sistema a uma classe que represente uma das seguintes escolhas: Ù Represente todo o sistema, o dispositivo ou subsistema; Ù Represente um cenário de um caso de uso dentro do qual ocorra o evento do sistema, frequentemente chamado TratadorDe<NomeDoCasoDeUso>, CoordenadorDe<NomeDoCasoDeUso> ou SessãoDe<NomeDoCasoDeUso> Aumento das possibilidades de reutilização e de interfaces plugáveis . Garante que a lógica da aplicação não seja tratada na camada de interface. Conhecer o estado do caso de uso. Algumas vezes, é necessário garantir que as operações do sistema ocorram em uma sequência válida ou ser capaz de reconhecer o estado da atividade e das operações dentro do caso de uso em processamento.

y Solução: 

y Benefícios  

Padrões arquiteturais: Padrão camadas
y Problemas 
   

As alterações no código-fonte são propagadas por todo o sistema; A lógica da aplicação é entrelaçada com a interface com o usuário e, assim, não pode ser reutilizada com uma interface diferente e nem distribuída para outro nó de processamento; Potencialmente, os serviços técnicos em geral ou a lógica do negócio é entrelaçada com a lógica mais específica da aplicação e, portanto, não pode ser reutilizada, não pode ser distribuída para outro nó nem facilmente substituída por uma implementação diferente; Existe forte acoplamento entre diferentes áreas de interesse. Assim, é difícil dividir o trabalho em limites claros para diferentes desenvolvedores; Devido ao forte acoplamento e à mistura de interesses, é difícil expandir a funcionalidade, aumentar a escala do sistema ou atualizá-lo para usar novas tecnologias.

Padrões arquiteturais: Padrão camadas
y Solução  

Organizar a estrutura lógica de larga escala de um sistema em camadas distintas de responsabilidades precisas e relacionadas, com uma separação clara e coesa dos interesses, de modo que as camadas inferiores sejam serviços de baixo nível e gerais e as camadas mais altas sejam mais específicas da aplicação. A colaboração e o acoplamento se dão das camadas superiores para as inferiores, o acoplamento de uma camada mais baixa para uma mais alta é evitado.

Padrões arquiteturais: As três principais camadas
y Lógica da apresentação 

Diz respeito a como tratar a interação entre o usuário e o software. As responsabilidades primárias da camada de apresentação são exibir informações para o usuário e traduzir comandos do usuário em ações sobre o domínio e a camada de dados. Diz respeito à comunicação com outros sistemas que executam tarefas no interesse da aplicação. Para a maioria das aplicações, a maior parte da lógica de dados é um banco de dados responsável , antes de mais nada, pelo armazenamento de dados persistentes. Diz respeito ao trabalho que esta aplicação tem de fazer para o domínio com o qual você está trabalhando. Envolve cálculos baseados nas entradas e em dados armazenados, validação de quaisquer dados provenientes da camada de apresentação e a compreensão exata de qual lógica de dados executar, dependendo dos comandos recebidos da apresentação.

y Lógica da camada de dados 

y Lógica de domínio (de negócio) 

Padrões microarquiteturais

Modelo de domínio
y Padrão de lógica de domínio y Trata-se de um modelo de objetos do domínio que incorpora tanto o

comportamento quanto os dados. y Um modelo de domínio cria uma rede de objetos interconectados em que cada um representa algum conceito significativo. y Colocar um modelo de domínio em uma aplicação envolve a inserção de uma camada inteira de objetos que modelam a área de negócios com a qual você está trabalhando. Nela você encontrará objetos que representam os dados do negócio e objetos que capturam as regras usadas pelo negócio. y Um modelo de domínio frequentemente se parece com um modelo de banco de dados, embora muitas diferenças persistam: um modelo de domínio mistura dados e processos, tem atributos multivalorados, uma complexa rede de associações e usa herança.

Padrões microarquiteturais

Roteiro de transação
y Padrão de lógica de domínio y Organiza a lógica de negócios em procedimentos onde cada y

y

y y

procedimento lida com uma única solicitação da apresentação. Com o Roteiro de transação, a lógica do domínio é organizada primariamente pelas transações que você executa usando os sistema. Sua tarefa é ler a entrada de dados, inquirir o banco de dados, trabalhar sobre os dados e gravar seus resultados no banco de dados. Organize os Roteiros de transação em classes distintas daquelas que lidam com a apresentação e a fonte de dados. Organize os Roteiros de transação em diversas classes, onde cada uma define um assunto comum para Roteiros de transação relacionados.

Padrões microarquiteturais

Gateway de tabela de dados
y Padrão arquitetural de fonte de dados y Refere-se a um objeto que atua como um Gateway para uma tabela

do banco de dados. Uma instância lida com todas as linhas na tabela. y Um Gateway de tabela de dados armazena todo o SQL utilizado para acessar uma única tabela ou visão: seleções, inserções, atualizações e exclusões. Os outros códigos chamam os métodos do Gateway para toda a interação necessária com o banco de dados. y Um Gateway de Tabela de dados tem um interface simples, consistindo normalmente de diversos métodos de busca para obter dados do banco de dados e métodos para atualizar, inserir e excluir dados. Cada método mapeia os parâmetros de entrada em uma chamada SQL e executa o SQL sobre a conexão com o banco de dados.

Padrões microarquiteturais

Factory Method
y Padrão de criação y Factory refere-se a uma classe que implementa um ou mais

métodos de criação. y Em uma Factory, os métodos de criação podem ser estáticos ou não-estáticos; o tipo de retorno dos métodos de criação pode ser uma interface, classe abstrata ou classe concreta. y Uma Factory pode implementar responsabilidades não-relacionadas com a criação de objetos. y Um Factory Method é um método não-estático que retorna uma classe base ou um tipo de interface e que é implementado em uma hierarquia para permitir criação polimórfica. Um Facoty Method deve ser definido/implementado por uma classe e por uma ou mais subclasses desta classe. A classe e as subclasses agem, cada uma delas, como ou ma Factory.

Referência bibliográfica
FOWLER, Martin. Padrões de arquitetura de aplicações corporativas. Porto Alegre: Bookman, 2006. KERIEVSKY, Joshua. Refatoração para padrões. Porto Alegre: Bookman, 2008. LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado. 2ª ed. Porto Alegre: Bookman, 2004.

Sign up to vote on this title
UsefulNot useful