Projetar Arquitetura

Objetivos

• Apresentar os passos necessários para realizar a atividade projetar arquitetura e discutir seus artefatos

• Apresentar o padrão de arquitetura em camadas• Apresentar e exercitar o uso de padrões de

projeto• Apresentar o Padrão MVC• Considerações sobre concorrência e distribuição

Análise e Projeto OO com UML e Padrões| 2

Arquiteto de Informação

Análise e Projeto OO com UML e Padrões| 3

Analisar Casos de Uso

Revisar Projeto

Projetar Arquitetura

Projetista deBanco de Dados

Arquiteto de Software

Revisor de projeto

Projetar Casos de Uso

Projetar Subsistemas

Projetar Base de Dados

Analista deSistemas

CheckList bla bla bla blabla

Projetar classes

Prototipar Interface gráfica

Analisar Serviços

ProjetarServiços

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

– Identificação das responsabilidades das classes– Identificação dos atributos e relacionamentos

Análise e Projeto OO com UML e Padrões| 4

Objetivos desta atividade

• Avaliar o conjunto das classes de análise • Definir elementos de projeto (classes de

projeto, cápsulas e subsistemas) e organizá-los em pacotes

• Definir a estrutura da aplicação

Análise e Projeto OO com UML e Padrões| 5

No final do projeto da arquitetura tudo deve estar pronto para que os projetistas possam detalhar as realizações dos casos de uso de maneira uniforme!

Visão geral dos artefatos

Análise e Projeto OO com UML e Padrões| 6

Arquiteto Projetar Arquitetura

Documento da

Arquitetura

Documento de Requisitos

Mapeamento das Classes de Análise em

Elementos de Projeto

Modelo de Análise e Projeto (classes de projeto, cápsulas e

subsistemas)

Modelo de Análise e Projeto

(classes de análise)

Modelo de Casos de Uso

Passos para Projetar Arquitetura1. Mapear classes de análise em elementos (classes, cápsulas e

subsistemas) de projeto2. Identificar oportunidades de reuso3. Definir a estrutura da aplicação

Análise e Projeto OO com UML e Padrões| 7

Passo 1: Mapear classes de análise em elementos (classes, cápsulas e subsistemas) de projeto

• Identificar classes de projeto• Identificar subsistemas• Especificar a interface dos subsistemas• Fazer o mapeamento

1 classe de análise pode dar origem a 0 ou mais elementos de projeto

Análise e Projeto OO com UML e Padrões| 8

Mapeamento m : n

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 transformadas em um pacote ou subsistema

Análise e Projeto OO com UML e Padrões| 9

QIB – Identificando classes de projeto

• Classe Conta– Tem duas responsabilidades distintas: controle de acesso e conta

bancária– Na realidade, modelam duas entidades diferentes

• A separação favorece o reuso– Por exemplo, ContaCorrente é utilizado para clientes que não têm

acesso à internet.

Análise e Projeto OO com UML e Padrões| 10

1

1

Identificando subsistemas

• Antes, vamos revisar alguns conceitos...

– Qual a diferença entre subsistemas e pacotes?– Como se descreve o comportamento de um

subsistema?– Qual a grande vantagem associada aos

subsistemas?

Análise e Projeto OO com UML e Padrões| 11

Subsistemas e interfaces: notação

Análise e Projeto OO com UML e Padrões| 12

<<subsystem>>Nome subsistema

<<subsystem>>Nome subsistema

Atributos

Realização

Nome da interface

Métodos

<<interface>>Nome da interfaceAtributosMétodos

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

Análise e Projeto OO com UML e Padrões| 13

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– Produtos específicos da aplicação

Análise e Projeto OO com UML e Padrões| 14

Identificando subsistemas

Análise e Projeto OO com UML e Padrões| 15

<<subsystem>>Subsistema X

Classe A

Y()Z() Y()

Z()

<<interface>>

Interface A

Classe complexa

A classe fachada

Análise e Projeto OO com UML e Padrões| 16

Interface <<subsystem>>nomeSubsistema

FachadaSubsistemaISubSistema

Além da interface, é destacada uma classe fachada de cada subsistema

QIB – Efetuar Pagamento do Qualiti Card

Análise e Projeto OO com UML e Padrões| 17

Análise

Projeto

Identificando subsistemas

<<boundary>>ComunicacaoOperadoraCartao

enviar()

<<subsystem>>SubsistemaComunicacao

OperadoraCartaoISubsistemaComunicacaoOperadoraCartao

enviar()

QIB – Efetuar Pagamento do Qualiti Card

Análise e Projeto OO com UML e Padrões| 18

ISubsistemaComunicacaoOperadoraCartao

enviar()

FachadaComunicacaoOperadoraCartao

PagamentoCartao

Contexto do subsistema

ControladorPagamentoQualitiCard

Passo 2. Identificar oportunidades de reuso

• Internas ao sistema– Similaridades entre pacotes e subsistemas

• Externas ao sistema– Componentes disponíveis no mercado– Componentes de aplicações já desenvolvidas– Componentes que podem se tornar reusáveis para

outros projetos

Análise e Projeto OO com UML e Padrões| 19

Identificando oportunidades de reuso• A partir das interfaces de subsistemas ou componentes

existentes analisar onde estes podem ser reutilizados • Para um candidato a subsistema

– Procure interfaces similares (podendo requerer engenharia reversa de subsistemas existentes)

– Tente adaptar a interface nova às existentes, ou tornar as existentes mais gerais

– Substitua a interface nova por existentes

Análise e Projeto OO com UML e Padrões| 20

Passo 3. Definir a estrutura da aplicação

• Definir as camadas da aplicação• Determinar o meio de armazenamento que

será utilizado• Agrupar as classes, cápsulas e protocolos em

pacotes e especificar a fachada da aplicação

Análise e Projeto OO com UML e Padrões| 21

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

Análise e Projeto OO com UML e Padrões| 22

Estruturação em camadas• Separação do código:

– interface com o usuário (GUI)– comunicação– regras de negócio– acesso a dados

Análise e Projeto OO com UML e Padrões| 23

Interface com o usuário(GUI)

Comunicação

Negócio

Dados

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

Análise e Projeto OO com UML e Padrões| 24

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– várias plataformas de distribuição para acesso a

uma mesma aplicação

Análise e Projeto OO com UML e Padrões| 25

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 (entidades)– coleções de negócio– fachada do sistema

Análise e Projeto OO com UML e Padrões| 26

Classes básicas do negócio• Representam conceitos básicos do domínio da

aplicação

Análise e Projeto OO com UML e Padrões| 27

Coleções de negócio• Representam conjuntos de objetos das classes básicas• Responsáveis pela inclusão, remoção, atualização e consultas a

instâncias das classes básicas• Encapsulam as verificações e validações inerentes ao negócio

Análise e Projeto OO com UML e Padrões| 28

Fachada do sistema• Segue o padrão de projeto Facade• Representa os serviços oferecidos pelo sistema• Centraliza as instâncias das coleções de negócio e/ou

controladores• Gerencia as transações do sistema

Análise e Projeto OO com UML e Padrões| 29

CadastroContas CadastroPagamentosCartao

CadastroContas

Fachada

CadastroPagamentosCartao

ControladorPagamentoQualitiCard

Fachada

efetuarPagamentoQualitiCard()

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 (repositórios)

Análise e Projeto OO com UML e Padrões| 30

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

Análise e Projeto OO com UML e Padrões| 31

RepositorioContasBDR

Coleções de dados• Dependem do meio de armazenamento!

Análise e Projeto OO com UML e Padrões| 32

RepositorioContasBDR

RepositorioContasBDOO

RepositorioContasArquivo

Independência do meio de armazenamento

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

Análise e Projeto OO com UML e Padrões| 33

RepositorioContasBDR RepositorioContasArquivo

CadastroContas

<<interface>>RepositorioContas

Interface negócio-dados

• Sugestão de serviços

Análise e Projeto OO com UML e Padrões| 34

<<interface>>RepositorioContas

inserir(conta: Conta): voidatualizar(conta: Conta): voidremover(conta: Conta): voidconsultarConta(login: String): Conta

Juntando tudo - Visão geral da arquitetura

Análise e Projeto OO com UML e Padrões| 35

GUI / Comunicação

NEGÓCIO

Interfaces negócio-

dados

DADOS

Fachada

TelaLogin TelaPagamentoQualitiCard

ControladorLogin ControladorPagamentoQualitiCard

CadastroPagamentosCartao...

ContaInternet PagamentoCartao

IRepositorioContasInternet IRepositorioPagamentosCartao

RepositorioPagamentosCartaoBDR

RepositorioPagamentosCartaoBDOO

RepositorioContasInternetBDR

RepositorioContasInternetArquivo

CadastroContasInternet

QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card

Análise e Projeto OO com UML e Padrões| 36

Mapeamento entre análise e projetoClasses de Análise Elementos de Projeto

FachadaTelaMenuDataHora

Conta ContaInternetContaCorrente

CadastroContas

CadastroPagamentosCartao CadastroTransacoesIRepositorioTransacoesRepositorioTransacoesBDR

ComunicacaoOperadoraCartao SubsistemaComunicacaoOperadoraCartaoISubsistemaComunicacaoOperadoraCartaoFachadaComunicacaoOperadoraCartao

CadastroContasInternetIRepositorioContasInternetRepositorioContasInternetBDRCadastroContasCorrenteIRepositorioContasCorrenteRepositorioContasCorrenteBDR

QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card

Análise e Projeto OO com UML e Padrões| 37

Projeto da arquitetura

Comprovante

FachadaComunicacaoOperadoraCartao

Hora

Data

PagamentoCartaonumeroFaturacontaBancariavalor

RepositorioContasCorrenteBDR

RepositorioContasInternetBDR

RepositorioPagamentosCartaoBDR

ContaCorrente

ContaInternet

1

1

1

1

IRepositorioContasCorrente

TelaLogin TelaMenu TelaPagamentoQualitiCard

IRepositorioPagamentosCartaoIRepositorio

ContasInternet

ControladorLogin

CadastroContasCorrente

1

1

1

1

Fachada 1

0..n

1

0..n

1

0..n

1

0..n 0..n

1

0..n

1

1

1

1

ISubsistemaComunicacaoOperadoraCartao

CadastroPagamentosCartao

1

1

1

1

CadastroContasInternet

1

1

1

1

1

1

1

1

ControladorPagamentoQualitiCard

1

1

1

1

1

1

1

11

1

1

1

1

1

1

1

1

1

1

1

Exercício – Qualiti Internet Banking• Dado:

– As classes de análise do caso de uso Realizar Doc– A tabela de mapeamento e o projeto de arquitetura de Efetuar Login e

Efetuar Pagamento do Qualiti Card • Identificar para o Realizar Doc:

– subsistemas e suas interfaces– elementos de projeto (classes e subsistemas)

• Produzir:– Tabela mapeando as classes de análise nos elementos de projeto– Diagrama de contexto dos subsistemas (opcional)– Projeto da arquitetura incluindo Realizar DOC

Análise e Projeto OO com UML e Padrões| 38

Agrupar as classes em pacotes

• À 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

Análise e Projeto OO com UML e Padrões| 39

Critérios para definição dos pacotes• Acoplamento e Coesão

– Agrupa as classes em bibliotecas– Exemplo: cliente, conta, banco, util, etc.

• Distribuição – usuário– Agrupa as classes por locais de implantação– Exemplo: clienteRecife, clienteSaoPaulo, etc.

• Segurança– Agrupa as classes por permissão de acesso– Exemplo: gerência, programadores, etc.

Análise e Projeto OO com UML e Padrões| 40

Evite dependências cíclicas

Pacote Global

• Pode ser usado por todos os outros pacotes– classes utilitárias

• Não é necessário explicitar as dependências

Análise e Projeto OO com UML e Padrões| 41

QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card

• Organização de pacotes

Análise e Projeto OO com UML e Padrões| 42

subsistemaComunicacaoOperadoraCartao

controladores

GUIconta transacaoutil

<<global>>

protocolos

QIB – Pacote conta

Análise e Projeto OO com UML e Padrões| 43

IRepositorioContasCorrente

<<Interface>>

CadastroContasCorrente<<entity collection>>

1

1

1

1

RepositorioContasCorrenteBDR

ContaCorrentenumerosaldo

getSaldo()debitar()

<<entity>>

ContaInternetloginsenha

<<entity>>11 11 IRepositorioContasInternet

<<Interface>>

CadastroContasInternet<<entity collection>>

1

1

1

1

RepositorioContasInternetBDR

QIB – Pacotes

• Dependência entre pacotes

Análise e Projeto OO com UML e Padrões| 44

<<global>>util

controladores

GUI

conta

<<subsystem>>subsistemaComunicaca

oOperadoraCartao

transacao

ISubsistemaComunicacao OperadoraCartao

protocolos

Exercício – Qualiti Internet Banking

• 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 (incluir os elementos do caso de uso Realizar DOC)

• Elaborar um diagrama mostrando as dependências entre pacotes (opcional

Análise e Projeto OO com UML e Padrões| 45