PROF. ANTONIO PASSOS

Arquitetura lógica e padrões

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ógicaa) 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. Processo3. Implantação4. Dados5. Caso de uso6. 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 Pura8. Indireção9. Variações Protegidas

GRASP

Especialista na informação

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

SoluçãoAtribuir 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

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