O que foi feito até agora

(1)

3 – Atividade

Projetar Arquitetura

Objetivos deste módulo

• Apresentar os passos necessários para

realizar a atividade projetar arquitetura e

discutir seus artefatos

• Apresentar o padrão de arquitetura em

camadas

(2)

Projeto Orientado a Objetos 3

Projetar Arquitetura

O que foi feito até agora

• Análise de caso de uso - para cada caso de uso: – Identificação das classes de análise (fronteira, entidade e

controle)

– Identificação das classes persistentes

– Distribuição do comportamento do caso de uso entre as classes

• Elaboração do diagrama de seqüência • Geração do diagrama de colaboração

(3)

Objetivos desta atividade

• Avaliar o

conjunto

das classes de análise

• Definir elementos de projeto (classes de

projeto e subsistemas) e organizá-los em

pacotes

• Definir a estrutura da aplicação

Modelo de análise e projeto

(4)

Passos para Projetar

Arquitetura

1. Mapear classes de análise em elementos (classes e subsistemas) de projeto

2. Definir a estrutura da aplicação 3. Descrever distribuição

O que temos ao iniciar esta

atividade

! !

(5)

O que teremos no final da

atividade

! !

!

Passo 1: Mapear classes de análise em

elementos (classes e subsistemas) de

projeto

• Identificar classes de projeto

• Identificar subsistemas

(6)

Projeto Orientado a ObjetosMapeamento m : n 11 <<boundary>>

<<boundary>> <<control>>

<<entity>>

Classes de Análise Elementos de Projeto

Identificando elementos de

projeto

Identificando classes de projeto

• Uma classe de análise simples, que representa uma única abstração, é mapeada para uma única classe de projeto

– Exemplo: classes de entidade

• Classes de análise muito simples podem até ser combinadas em uma única classe de projeto • Em geral, classes de análise complexas podem

ser divididas em várias classes ou

(7)

Por que usar subsistemas?

• Subsistemas permitem dividir o sistema em partes independentes (que se tornarão componentes)

– Cada subsistema pode ser desenvolvido, testado e possivelmente implantado independentemente dos demais

– Um subsistema pode representar uma abstração (no projeto) de produtos ou sistemas externos que serão incorporados na implementação

Identificando subsistemas

• Classes de análise

– Classes de fronteira (interfaces com sistemas externos e com usuários)

– Classes que fornecem serviços complexos

• Componentes reusáveis

– Software de comunicação – Suporte ao acesso a BD – Estruturas de dados – Bibliotecas de utilitários

(8)

BVF – Biblioteca Virtual Fucapi

<<boundary>> ComunicacaoImpressora enviar()

<<subsystem>> SubsistemaComunicacaoI

mpressora

ISubsistemaComunicacaoIm pressora

enviar()

Mapeamento das Classes de Análise

em Elementos de Projeto:

BVF

ComunicacaoImpressora

Locatario

Todas as outras classes mapeiam diretamente para elementos de projetos

Classe de Análise Elemento de projeto

SubsistemaComunicacaoImpressora

ISubSistemaComunicacaoImpressora

Locatario

Endereco

(9)

Exercício

• Dado:

– O documento de requisitos

– As classes de análise e seus relacionamentos

• Identificar:

– subsistemas e suas interfaces – classes de projeto

• Produzir:

– Tabela mapeando as classes de análise nos elementos de projeto

– Diagrama de contexto dos subsistemas (opcional)

(10)

Classes de análise

Passo 2. Definir a estrutura da

aplicação

• Definir as camadas da aplicação

• Determinar o meio de armazenamento

que será utilizado

(11)

Definir as camadas da

aplicação

• O arquiteto pode seguir um padrão já existente para estruturar a aplicação

• Se o arquiteto adotar uma estrutura diferente do

padrão, deve descrevê-la no Documento da

Arquitetura

• O arquiteto também pode definir novos padrões ou atualizar orientações já existentes

Estruturação em camadas

• Separação do código:

– interface com o usuário (GUI) – comunicação

– regras de negócio

– acesso a dados _"

#$%"& !

(12)

Benefícios

• Modularidade:

– Dividir para conquistar – Separação de conceitos – Reusabilidade

– Extensibilidade

• Mudanças em uma camada não afetam as outras, desde que as interfaces sejam preservadas

– plug-and-play

Benefícios

• Uma mesma versão de uma camada

trabalhando com diferentes versões de outra camada

– várias GUIs para a mesma aplicação

– vários mecanismos de persistência suportados pela mesma aplicação

(13)

Camada de negócios

• Responsável por implementar a lógica do

negócio

• Classes inerentes ao domínio da aplicação:

– classes básicas do negócio – controladores de negócio – fachada do sistema

Classes básicas do negócio

(14)

Controladores de negócio

• Representam classes de controle das classes básicas

• Responsáveis pela lógica de controle e regras de negócio de instâncias das classes básicas

• Encapsulam as verificações e validações inerentes ao negócio

)* ! )*

Fachada do sistema

• Segue o padrão de projeto Facade

• Representa os serviços oferecidos pelo sistema • Centraliza as instâncias dos controladores de

negócio

• Gerencia as transações do sistema

+ ,-+

(15)

Camada de dados

• Responsável pela manipulação da

estrutura física de armazenamento dos

dados

• Isolam o resto do sistema do meio físico

usado

• Classes coleções de dados oriundas das

classes de análise

entity collection

( !

(( !! ,

Coleções de dados

• Executam inclusões, remoções, atualizações e

consultas a instâncias das classes básicas no

meio de armazenamento usado

• Implementadas de acordo com o meio físico usado

! )*

)*

! )* ,

(16)

Coleções de dados

• Dependem do meio de armazenamento!

( !

! )*

! )* ,

! )* , ))

! )*

)*

Independência do meio de

armazenamento

• Como isolar os controladores de negócio de mudanças na coleção de dados correspondente?

CadastroObras

<<Interface>>

ControladorObras

(17)

Interface negócio-dados

• Sugestão de serviços • Cadastro Obras

– Inserir(obra : Obra) – Consultar (codObra : int) – Remover (codObra : int) – Alterar(obra : Obra)

Locatario Obra

ControladorObras

CadastroObras

ControladorLocatarios

CadastroLocatarios GUI

FachadaBVF $%"

/$0!")

" '( 1

)2

Juntando tudo...

Visão geral da arquitetura

(18)

Classes de análise - a origem

de tudo

• Classes de entidade

– Classes básicas + coleções de dados

• Classes de fronteira

– com usuários classes de GUI – com legados subsistemas

• Classes de controle

– Controladores de negócio – Fachada do sistema

Determinar o meio de

armazenamento que será utilizado

• Qual deve ser a implementação específica

das coleções de dados?

– Determinar o meio físico que deve ser usado para armazenar os dados

• Documentar com uma nota anexada a

visão lógica

(19)

Agrupar as classes em pacotes e

especificar a

fachada

da aplicação

• À medida que os elementos de projeto

são identificados, a complexidade do

modelo vai aumentando

• Para organizá-lo, os elementos devem ser

agrupados em pacotes

• As camadas guiam essa organização

Critérios para definição dos

pacotes

(20)

Pacote Global

• Pode ser usado por todos os outros

pacotes

– classes utilitárias

• Não é necessário explicitar as

dependências

$

(21)

Exemplo: organização em pacotes

do BVF

! )*

%

% !

Exercício

• Dado:

– Os elementos de projeto

– A estrutura definida para a aplicação

• Definir os pacotes da aplicação e os elementos que devem estar presentes em cada pacote • Elaborar um diagrama mostrando as

(22)

Passo 3. Descrever distribuição

• Descrever como o sistema está

organizado nos seus nós físicos (sistemas

distribuídos)

– Definir a configuração da rede – Alocar processos aos nós

• Trabalhar na Visão de Implantação

(Deployment)

<<Node>>

<<Processor>> Processador A

<<Device>> Dispositivo B

Diagrama de implantação:

Elementos

• Nó

– recurso computacional físico – pode ser de dois tipos

(23)

<<Device>> Dispositivo B <<Processor>> Processador A

Conexão

Diagrama de implantação:

Elementos

• Conexão entre nós

– identificar

• mecanismo de comunicação (tecnologia utilizada)

• meio físico utilizado • protocolo de software

Tipos de processadores

• Máquinas dos usuários finais

• Máquinas servidoras

• Processadores especializados

• Máquinas com configuração especial

(24)

Alocar processos a nós

• De acordo com a configuração da rede, os processos do sistema são alocados aos nós levando em consideração:

– Capacidade do nó

– Largura de banda do meio de comunicação

– Disponibilidade de hardware e links de comunicação – Requisitos de redundância e tolerância a falhas – Requisitos de tempo de resposta

(25)

Revisando: Passos realizados nesta

atividade

1. Mapear classes de análise em elementos (classes e subsistemas) de projeto

2. Definir a estrutura da aplicação – Definir as camadas da aplicação

– Determinar o meio de armazenamento que será utilizado

– Agrupar as classes em pacotes e especificar a fachada da aplicação

3. Descrever distribuição

Exercício

• Dado:

– artefatos de requisitos

– modelo de análise e projeto

• Produzir:

– Diagrama de distribuição do BVF,