PROJETO DE ARQUITETURA

Transcrição

1 PROJETO DE ARQUITETURA Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... Próximas aulas: Seminários de Padrões de Projeto GoF 1º Dia: 10/11/2017, 08h 10h, Sala 04 2º Dia: 13/11/2017, no local e horário habituais 3º Dia: 17/11/2017, 08h 10h, Sala 04 Mais informações: 1

2 Na aula passada... Padrões de Projeto GoF (Gang of Four) Se o Modelo de Domínio cresce muito: É desejável decompô-lo em pacotes de conceitos fortemente relacionados. Pacotes 2

3 Posse e referência entre pacotes: Um elemento é possuído pelo pacote dentro do qual é definido, mas pode ser referenciado em outros pacotes. O nome do elemento é qualificado pelo nome do pacote, usando o formato NomeDoPacote::NomeDoElemento. Elemento possuído pelo pacote Elemento referenciado em outros pacotes Dependências entre pacotes: Os elementos do pacote dependente tem, de alguma forma, conhecimento (ou estão acoplados) aos elementos do pacote de destino. Exemplo: um pacote faz referência a um elemento pertencente a outro pacote. Relacionamento de dependência 3

4 Como particionar um Modelo de Domínio: Como particionar um Modelo de Domínio: Todos os elementos do modelo estão enraizados em um pacote Domínio. Todos os conceitos amplamente compartilhados, comuns e centrais são definidos um pacote Elementos Centrais ou Conceitos Comuns. em 4

5 Como particionar um Modelo de Domínio: Pacote Elementos Centrais ou Conceitos Comuns : conceitos amplamente compartilhados. Como particionar um Modelo de Domínio: Pacote Pagamentos 5

6 Como particionar um Modelo de Domínio: Pacote Produtos Como particionar um Modelo de Domínio: Pacote Vendas : 6

7 Como particionar um Modelo de Domínio: Pacote Transações de Autorização Como particionar um Modelo de Domínio: 7

8 Arquitetura Lógica Introdução: Um Projeto OO típico é baseado em várias camadas arquiteturais como a camada de Interface com o Usuário, camada de Aplicação Lógica (ou Domínio ) etc. Diagramas UML podem ilustrar a Arquitetura Lógica como parte do modelo de projeto. Ela pode também ser resumida como uma visão no DAS (Documento de Arquitetura do Software). Principal entrada: forças arquiteturais captadas na Especificação Suplementar (artefato de requisitos do PU). Arquitetura Lógica Exemplo de Arquitetura Lógica em camadas parcial feita com a notação de Diagrama de Pacotes da UML. 8

9 Evolução da Arquitetura Lógica: Evoluir a Arquitetura Lógica significa gradualmente adicionar mais pacotes e mais informação às camadas e aos pacotes existentes, à medida que as iterações (do PU) se dão. Um objetivo da 3ª fase da Elaboração é ter a Arquitetura central estabelecida (projetada e implementada). Refinamento da Arquitetura Lógica Evolução da Arquitetura Lógica: Neste ponto, são feitas referências ao uso de padrões de projeto como o Adapter (Adaptador), Fachada (Façade), Fábrica ou Strategy (Estratégia) 9

10 Refinamento da Arquitetura Lógica Acoplamento entre camadas e pacotes: Linhas de dependência Diagrama da Visão Lógica: ilustra acoplamentos importantes entre as camadas e os pacotes. Refinamento da Arquitetura Lógica Acoplamento pacote-pacote: Diagrama de Arquitetura Lógica mais comum: oculta os tipos específicos e foca apenas no acoplamento pacote a pacote (apenas os mais importantes e suas dependências). 10

11 Interação entre camadas e entre pacotes: Diagramas de Pacotes mostram informações estáticas. Para entender a dinâmica na arquitetura lógica é útil incluir um diagrama que mostre como os objetos se conectam e se comunicam entre as camadas Diagrama de Interação. Foca as colaborações conforme elas cruzam os limites das camadas e de pacotes. Fazer apenas para os cenários arquiteturalmente mais significativos: ilustram muitos aspectos das grandes idéias ou aquelas de larga escala. Refinamento da Arquitetura Lógica Objeto Unitário (Singleton) Cenário Processar Vendas : Nome do caminho: <NomeDoPacote>::<NomeDoTipo> Domínio::Vendas::Registradora Subsistema (<<subsistema>>): entidade separada que tem comportamentos e interfaces. Algumas mensagens foram ignoradas para destacar apenas as interações arquiteturalmente significativas 11

12 Colaboração com o padrão Camadas: Duas decisões de projeto a nível arquitetural: Quais são as grandes partes? Como elas estão conectadas? Padrão arquitetural Camadas: Guia a definição das grandes partes Padrões de projeto micro arquiteturais como Fachada, Controlador e Observador são usados para o projeto das conexões entre camadas e pacotes. Colaboração com o padrão Camadas: Pacotes simples x Subsistemas: Alguns pacotes ou camadas não são apenas grupos conceituais de coisas, mas são verdadeiros subsistemas, com comportamentos e interface. 12

13 Colaboração com o padrão Camadas: Pacotes simples x Subsistemas: O pacote EstabelecimentoDePreços não é um subsistema: apenas agrupa a fábrica e as estratégias usadas no estabelecimento de preços. O pacote Persistência, MotorDeRegraPDV e Jess são subsistemas: são mecanismos separados com responsabilidades coesas que funcionam. Estereótipo que identifica um subsistema Colaboração com o padrão Camadas: Fachada: Padrão de acesso mais comum no caso de pacotes que representam subsistemas. Um objeto de fachada público define os serviços do subsistema e os clientes colaboram com a fachada e não com os componentes internos do subsistema. Geralmente mantem um pequeno número de operações de alto nível (serviços de granularidade grossa) 13

14 Colaboração com o padrão Camadas: Fachada: Uma fachada não realiza o seu próprio trabalho, mas sim é a consolidadora ou mediadora dos objetos do subsistema, que são os que realizam o trabalho. Outros pacotes não veem a implementação do subsistema, pois fica oculto atrás da fachada. Colaboração com o padrão Camadas: Fachada: Se a aplicação tem um pequeno número de operações é comum que a camada de Domínio tenha apenas um objeto fachada para a camada superior. Mas se tem muitas operações, com vários subsistemas, é comum pelo menos uma fachada para cada subsistema nas camadas superiores. 14

15 Colaboração com o padrão Camadas: Fachada: Número de interfaces expostas para as camadas superiores. Colaboração com o padrão Camadas: Fachadas de sessão e a camada de aplicação: Fachada de sessão: mantem os estados da sessão para as operações de um caso de uso, em que cada instância de sessão represente uma sessão com um único cliente. Logo, é comum criar uma fachada de sessão para cada caso de uso. 15

16 Colaboração com o padrão Camadas: Fachadas de sessão e a camada de aplicação Colaboração com o padrão Camadas: O padrão GRASP Controlador descreve controladores para chamadas de operação que partem das UIs. 16

17 Bibliografia Esta aula foi retirada dos seguintes livros/artigos: LARMAN, Craig. Utilizando UML e Padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman,