Arquitetura Lógica e Diagrama de Pacotes UML

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Arquitetura Lógica e Diagrama de Pacotes UML
1
Prof. Clayton Vieira Fraga Filho
site: www.claytonfraga.pro.br
e-mail: claytonfraga@gmail.com
ENG10508 – Projeto de Sistemas de Software
1
2
Arquitetura lógica e camadas
A arquitetura lógica é a organização em larga escala das classes de software em pacotes, subsistemas e camadas. É chamada de arquitetura lógica porque não há decisão sobre como esses elementos são implantados, essas decisões são parte da arquitetura de implantação (emergente).
2
3
Arquitetura lógica e camadas
Uma camada é um agrupamento de granularidade muito grossa de classes, pacotes ou subsistemas que tem responsabilidade coesiva sobre um tópico importante do sistema.
As camadas são organizadas de modo que as "mais altas“ solicitem serviços das "mais baixas" mas normalmente não vice-versa.
3
Arquitetura lógica
Exemplo arquitetura lógica em camadas parcial:
4
5
Camadas
Camadas em um sistema OO incluem:
Interface com o Usuário.
Lógica da Aplicação e Objetos do Domínio - objetos de software representando conceitos do domínio (por exemplo, uma classe de software Venda) que satisfazem requisitos da aplicação, como calcular um total de vendas.
Serviços Técnicos - objetos de propósito geral e subsistemas que fornecem serviços técnicos de apoio, como interfaceamento com um banco de dados ou registro de erros. Esses serviços geralmente são independentes da aplicação e reusáveis entre diversos sistemas.
5
6
Camadas
Em uma arquitetura em camadas estrita, uma camada apenas solicita serviços da camada diretamente inferior a ela. Esse projeto é comum em pilhas de protocolo de rede, mas não em sistemas de informação.
Sistemas de informação costumam ter uma arquitetura em camadas relaxada, na qual uma camada mais alta solicita informações de várias camadas mais baixas.
Uma arquitetura lógica não precisa ser organizada em camadas, mas isso é muito comum.
6
7
Camadas
As lições de projeto OO aprendidas no contexto da camada de lógica da aplicação (domínio) são aplicáveis a todas as outras camadas ou componentes.
As outras camadas tendem a ser muito dependentes da tecnologia.
7
8
Diagramas de Pacotes
Diagramas de pacotes UML frequentemente são usados para ilustrar a arquitetura lógica de um sistema - as camadas, subsistemas, pacotes, etc. Uma camada pode ser modelada como um pacote UML.
É comum desejar mostrar dependência (acoplamento) entre pacotes, de modo que os desenvolvedores possam ver o acoplamento em larga escala do sistema. A linha de dependência UML é usada para isso.
Um pacote UML representa um espaço de nomes de modo que, por exemplo, uma classe pode ser definida em dois pacotes. Se você precisa fornecer nomes plenamente qualificados, para o caso em que há um pacote externo com um pacote aninhado contendo uma classe.
8
9
Diagramas de Pacotes
Abordagens alternativas UML para mostrar aninhamento de pacotes usando pacotes embutidos, nomes UML plenamente qualificados e o símbolo círculo-cruz.
9
10
Projeto em camadas
As idéias essenciais de usar camadas são :
Organizar a estrutura lógica de larga escala de um sistema em camadas discretas de responsabilidades distintas relacionadas, com uma separação clara e coesa de interesses, de modo que as camadas "inferiores" sejam de baixo nível e serviços gerais e camadas superiores sejam mais específicas da aplicação.
Colaboração e acoplamento ocorrem das camadas superiores para as inferiores; um acoplamento das camadas inferiores para as superiores é evitado.
10
11
Projeto em camadas
Problemas tratados ao usar camadas:
Modificações do código fonte se espalham por todo o sistema.
A lógica da aplicação está entrelaçada com a interface com o usuário, de modo que não pode ser reusada com uma interface diferente ou distribuída para outro nó de processamento.
Serviços técnicos potencialmente gerais ou lógica de negócios estão entrelaçados com lógica mais específica da aplicação, de modo que não podem ser reusados ou facilmente substituídos por uma implementação diferente.
Existe alto acoplamento entre diferentes áreas de interesse.
11
12
TCC - Também conhecida como
12
13
Projeto em camadas
Benefícios do uso de camadas:
Reduz o acoplamento e as dependências, melhora a coesão, aumenta o potencial de reuso e aumenta a clareza.
A complexidade relacionada é encapsulada e decomponível.
Algumas camadas podem ser substituídas por nova implementação.
As camadas inferiores contêm funções reusáveis.
Algumas camadas podem ser distribuídas.
O desenvolvimento em equipes é facilitado.
13
14
Projeto em camadas
As responsabilidades dos objetos em uma camada devem estar fortemente relacionadas umas com as outras e não devem ser misturadas com responsabilidades de outras camadas.
Podemos fazer o mapeamento das camadas e pacotes UML através de pacotes da linguagem, onde o nome da camada é usado como uma separação do nome de pacote da linguagem.
14
15
Projeto em camadas
Para apoiar o reuso, não é interessante utilizar nomes específicos da aplicação no nome do pacote.
15
16
Projeto em Camadas
Qual é o relacionamento entre a camada de domínio e o modelo de domínio?
Olhamos para o modelo de domínio para ter inspiração quanto aos nomes das classes na camada de domínio. A camada de domínio é parte do software e o modelo de domínio é parte da analise da perspectiva conceitual. Eles não são a mesma coisa. Mas criamos um hiato representacional.
As camadas de uma arquitetura são usadas para representar as fatias verticais, enquanto que partições representam uma divisão horizontal de subsistemas relativamente paralelos de uma camada.
Camada do Domínio X Camada da Lógica da aplicação; Objetos do domínio
16
17
Projeto em Camadas
17
18
Projeto em Camadas
18
19
Projeto em Camadas
A maior parte dos sistemas depende de recursos ou serviços, tais como de um banco de dados de estoque em MySQL;
Esses são componentes físicos de implementação não uma camada da arquitetura lógica.
Mostrar recursos externos em uma camada “abaixo” da camada de Fundação(por exemplo) mistura visão lógica e a visão de implantação da arquitetura. O melhor seria, os serviços gerais serem vistos como uma partição do Serviço Técnico.
Diretriz: não mostre recursos externos como a camada inferior
19
20
Projeto em Camadas
20
21
Princípio da separação modelo-visão
O princípio tem no mínimo duas partes:
Não conecte ou acople objetos que não são IU diretamente a objetos de IU.
Não coloque a lógica da aplicação em métodos de objetos IU.
O princípio estabelece que o modelo(objetos da camada de domínio) de objetos não deveria ter conhecimento direto dos objetos de visão(IU).
Padrão Observador É UM RELAXAMENTO DESSE PRINCÍPIO, estabelece uma interface implementada pelo objeto de IU, em que os objetos de domínio enviam mensagens aos objetos de IU.
21
22
Princípio da separação modelo-visão
Motivação:
Apoiar definições coesivas de modelo que enfocam processos do domínio em vez de interfaces do usuário.
Permitir o desenvolvimento separado das camadas de modelo e interface do usuário.
Minimizar o impacto das modificações de requisitos da interface sobre a camada de domínio.
Permitir que novas visões sejam facilmente conectadas a uma camada de domínio existente sem afetar a camada de domínio.
Permitir visões simultâneas e múltiplas do mesmo modelo de objeto.
Permitir a execução da camada de modelo independente da camada de interface com o usuário.
Permitir fácil portabilidade da camada de modelo para outro framework de interface com o usuário.
22
23
DSS, operações e camadas
Nos DSSs identificamos eventos de entrada de atores externos ao sistema, chamado operação do sistema.
Os DSSs ilustram essas operações do sistema, mas escondemos objetos específicos de IU.
Em uma arquitetura em camadas bem projetada que apóia alta coesão e separação de interesses, os objetos da camada IU vão encaminhar a solicitação da camada de IU para a camada de domínio fazer o tratamento.
23