Arquitetura lógica e padrões

PROF. ANTONIO PASSOS

 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

 Definição de arquitetura
 Visões de arquitetura
 GRASP – Padrões de Princípios Gerais para Atribuição de Responsabilidades
 Especialista na informação;
 Criador;
 Coesão alta;
 Acoplamento fraco;
 Controlador
 Padrões arquiteturais
 Padrão camada
 Padrões microarquiteturais
 Modelo de domínio;

 Roteiro de transação;

 Gateway de tabela de dados;

 Factory method
 Definição de arquitetura

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

dos principais elementos de software.
 A arquitetura lógica descreve o sistema em termos de sua organização
conceitual em camadas, pacotes, principais frameworks, classes, interfaces e
subsistemas.
 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. Lógica
a) Descreve a organização conceitual do software em termos das camadas, dos
subsistemas, dos pacotes, dos frameworks, das classes e das interfaces mais
importantes.
b) Mostra cenários de realização de casos de uso destacados (como diagrama de
interação) que ilustram aspectos importantes do sistema
2. Processo
3. Implantação
4. Dados
5. Caso de uso
6. Implementação
 GRASP

 GRASP é a sigla de General Responsibility Assignment Software Patterns

(Padrões de Princípios Gerais para Atribuição de Responsabilidades)
 São nove os padrões GRASP:
1. Especialista na Informação (Information Expert)
2. Criador (Creator)
3. Coesão Alta (High Cohesion)
4. Acoplamento Fraco (Low Coupling)
5. Controlador (Controller)
6. Polimorfismo ()
7. Invenção Pura
8. Indireção
9. Variações Protegidas
 GRASP
Especialista na informação
 Problema
Qual é o princípio básico de atribuição de responsabilidades a objetos?
 Solução
Atribuir uma responsabilidade ao especialista na informação, ou seja, àquele que tem a
informação necessária para satisfazer a responsabilidade.
 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.
 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
 Problema
Quem deve ser responsável pela criação de uma nova instância de uma classe?
 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 .

 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
 Problema
 Como favorecer a dependência baixa, o pequeno impacto à mudança e aumentar a
reutilização?
 Solução
 Atribuir uma responsabilidade de maneira que o acoplamento permaneça fraco.
 Benefícios
 Não é afetado por mudanças em outros componentes;
 É simples de entender isoladamente;

 É conveniente para reutilização

 GRASP
Coesão alta
 Problema
 Como manter a complexidade sob controle?

 Solução
 Atribuir uma responsabilidade de maneira que a coesão permaneça alta.
 Benefícios
 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.
 GRASP
Acoplamento fraco X Coesão alta

 Má coesão geralmente traz mau acoplamento, e vice-versa. A coesão e o

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
 Problema
 Quem deve ser responsável por tratar um evento de sistema?

 Solução:
 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>
 Benefícios
 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.
 Padrões arquiteturais: Padrão camadas

 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

 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

 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.
 Lógica da 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.
 Lógica de domínio (de negócio)
 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.
 Padrões microarquiteturais
Modelo de domínio

 Padrão de lógica de domínio

 Trata-se de um modelo de objetos do domínio que incorpora tanto o
comportamento quanto os dados.
 Um modelo de domínio cria uma rede de objetos interconectados em que cada
um representa algum conceito significativo.
 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.
 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

 Padrão de lógica de domínio

 Organiza a lógica de negócios em procedimentos onde cada
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

 Padrão arquitetural de fonte de dados

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

 Padrão de criação
 Factory refere-se a uma classe que implementa um ou mais métodos
de criação.
 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.
 Uma Factory pode implementar responsabilidades não-relacionadas
com a criação de objetos.
 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.