Projetar Arquitetura. Objetivos Apresentar os passos necessários para realizar a atividade projetar arquitetura e discutir seus artefatos Apresentar o

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


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


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


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


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


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


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


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.


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?


Subsistemas e interfaces: notação


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


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




<<subsystem>>Subsistema X

Classe A

Y()Z() Y()

Z()

<<interface>>

Interface A

Classe complexa

A classe fachada


Interface <<subsystem>>nomeSubsistema

FachadaSubsistemaISubSistema

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

QIB – Efetuar Pagamento do Qualiti Card


Análise

Projeto


<<boundary>>ComunicacaoOperadoraCartao

enviar()

<<subsystem>>SubsistemaComunicacao

OperadoraCartaoISubsistemaComunicacaoOperadoraCartao

enviar()

QIB – Efetuar Pagamento do Qualiti Card


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


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


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


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


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


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


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


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

aplicação


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


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


CadastroContas CadastroPagamentosCartao

CadastroContas

Fachada

CadastroPagamentosCartao


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)


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


RepositorioContasBDR

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


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?


RepositorioContasBDR RepositorioContasArquivo

CadastroContas

<<interface>>RepositorioContas

Interface negócio-dados

• Sugestão de serviços


<<interface>>RepositorioContas

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

Juntando tudo - Visão geral da arquitetura


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


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

FachadaTelaMenuDataHora

Conta ContaInternetContaCorrente

CadastroContas

CadastroPagamentosCartao CadastroTransacoesIRepositorioTransacoesRepositorioTransacoesBDR

ComunicacaoOperadoraCartao SubsistemaComunicacaoOperadoraCartaoISubsistemaComunicacaoOperadoraCartaoFachadaComunicacaoOperadoraCartao

CadastroContasInternetIRepositorioContasInternetRepositorioContasInternetBDRCadastroContasCorrenteIRepositorioContasCorrenteRepositorioContasCorrenteBDR



Projeto da arquitetura

Comprovante

FachadaComunicacaoOperadoraCartao

Hora

Data

PagamentoCartaonumeroFaturacontaBancariavalor

RepositorioContasCorrenteBDR


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


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


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


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.


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



• Organização de pacotes


subsistemaComunicacaoOperadoraCartao

controladores

GUIconta transacaoutil

<<global>>

protocolos

QIB – Pacote conta


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


QIB – Pacotes

• Dependência entre pacotes


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


Documents

Projetar Arquitetura. Objetivos Apresentar os passos necessários para realizar a atividade projetar arquitetura e discutir seus artefatos Apresentar o