atividade projetar arquitetura - facombacala/es/11- projetando arquitetura.pdfpassos para projetar...

Projetar Arquitetura

Objetivos desta atividade

• Definir mecanismos de projeto e de implementação

• Definir elementos (classes e subsistemas) de projeto e organizá-los em pacotes

• Identificar oportunidades de reuso

• Descrever distribuição

• Revisar a arquitetura do sistema

2

Visão geral dos artefatos

3 Modelo de projeto Modelo de projeto

(classes e subsistemas)

Projetar

Arquitetura

Classes de análise

Orientações

de projeto

Documento da

arquitetura

Glossário

Especificações

suplementares

Fonte: Rational

Passos para Projetar Arquitetura • 1. Identificar e documentar mecanismos de projeto e de

implementação

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

• 3. Identificar oportunidades de reuso

• 4. Definir organização do sistema

• 5. Descrever distribuição

4

Algumas considerações

• Como na análise da arquitetura, a ênfase é no sistema como um todo (e não em um caso de uso)

• O resultado da análise da arquitetura é refinado, servindo como ponto de partida para o projeto

• mecanismos de análise mecanismos de projeto

5

Passo 1. Identificar e documentar mecanismos de projeto e de implementação

• Mecanismos arquiteturais devem ser documentados usando-se diagramas de classe e interação

• A documentação produzida pelo arquiteto servirá como um padrão para o projetista instanciar para uso específico

6 Aspecto estrutural Comportamento Orientações

de projeto

Mecanismos de Arquitetura

7

Mecanismos

de análise

(conceitual)

Persistência

Persistência

Distribuição

ANÁLISE

Mecanismos

de projeto

(concreto)

RDBMS

OODBMS

Remote Method

Invocation (RMI)

PROJETO

Mecanismos

de implementação

(produto real)

JDBC

ObjectStore

Java 1.2 (Sun)

IMPLEMENTAÇÃO

Fonte: Rational

8

ClientePersistente

TransacaoException

RepositorioIteravelClientePersistente<<Interface>>

RepositorioClientePersistenteException

RepositorioClientePersistente<<Interface>>

CadastroClientePersistente

Fachada

Transacao<<Interface>>

GerenciadorTransacoes<<Interface>>

Exemplo: Persistência (RDBMS-JDBC)

9

ClientePersistente

RepositorioIteravelClientePersistente

proximo() : ClientePersistente

anterior() : ClientePersistente

temProximo() : boolean

temAnterior() : boolean

tamanho() : int

primeiro() : ClientePersistente

ultimo() : ClientePersistente

<<Interface>>

RepositorioClientePersistenteExceptionAs consultas podem variar de acordo com os objetivos. Por

exemplo, podemos ter um método

consultarAlunosPorCidade(identificadorCidade : String) que retorna

um RepositorioAlunos ou mesmo um RepositorioIteravelAlunos. A

idéia é que podemos ter vários métodos consultar com diferentes

assinaturas e retornos para atender a diferentes "filtros".

Nem todos os métodos da interface

RepositorioIteravel precisam ser

implementados. Percorrer uma

sequência do início ao fim é trivial de

implementar utilizando-se uma das

estruturas da API Collection, mas

percorrer de trás para frente pode não

ser trivial de implementar.

RepositorioClientePersistente

inserir(cliente : ClientePersistente) : void

inserir(clientes : RepositorioClientePersistente) : void

consultar(identificador : String) : ClientePersistente

consultarXXX(criterio : String) : RepositorioClientePersistente

consultarYYY(criterio : String) : RepositorioIteravelClientePersistente

atualizar(cliente : ClientePersistente) : void

atualizar(clientes : RepositorioClientePersistente) : void

remover(identificador : String) : void

remover(clientes : RepositorioClientePersistente) : void

contem(cliente : ClientePersistente) : boolean

contemTodos(clientes : RepositorioClientePersistente) : boolean

estaVazio() : boolean

tamanho() : int

getRepositorioIteravel() : RepositorioIteravelClientePersistente

<<Interface>>


Fachada

Exemplo: Persistência (RDBMS-JDBC) Assinaturas das coleções de dados (repositórios)

Exemplo: Persistência (RDBMS-JDBC) Gerenciamento de transações

10

TransacaoException

Os métodos getTransacao() e

finalizarTransacao() não

recebem parâmetros porque

operam sobre a transação

registrada ao thread atual

(operam sob contexto)

Transacao

iniciar() : void

confirmar() : void

cancelar() : void

finalizar() : void

getEstado() : int

transacaoIniciada() : boolean

getId() : int

setId(id : int) : void

getCanalComunicacao() : Object

<<Interface>>

GerenciadorTransacoes

novaTransacao() : Transacao

getTransacao() : Transacao

getTransacao(id : int) : Transacao

finalizarTransacao() : void

finalizarTransacao(id : int) : void

<<Interface>>

11 TransacaoBD

GerenciadorPoolConexoes

GerenciadorTransacoesBD

RepositorioIteravelClientePersistente

<<Interface>>

Fachada


RepositorioClientePersistente

<<Interface>>RepositorioClientePersistenteBD

GerenciadorTransacoes

novaTransacao()

getTransacao()

getTransacao()

finalizarTransacao()

finalizarTransacao()

<<Interface>>

Transacao

iniciar()

confirmar()

cancelar()

finalizar()

getEstado()

transacaoIniciada()

getId()

setId()

getCanalComunicacao()

<<Interface>>

RepositorioIteravelClientePersistenteArray

Exemplo: Persistência (RDBMS-JDBC) Implementação dos repositórios

Ao f inal das operações

do repositório a f achada

dev e concluir ou

cancelar a transação em

f unção das oerações

terem sido bem

sucedidas ou não.

Fachada RepositorioClientePersistenteBDCadastroClientePersistente GerenciadorPoolConexoesTransacaoBDGerenciadorTransacoesBD

novaTransacao( )alocarConexao(java.lang.String)

new TransacaoBD(jav a.sql.Connection)

iniciar( )

inserir(ClientePersistente)

inserir(ClientePersistente)

getTransacao( )

getCanalComunicacao( )

confirmar( )

cancelar( )

finalizarTransacao( )


liberarConexao(jav a.lang.String, jav a.sql.Connection)

final izar( )

O parâmetro String

corresponde ao nome

do pool de conexões a

ser utilizado,

lembrando que o

gerenciador do pool

pode trabalhar com

mais de um pool.

Após obter a conexão, o

repositório utiliza a API

de JDBC para excutar

o(s) comando(s) SQL.

Exemplo: Persistência (RDBMS-JDBC) Realizando uma transação com o BD

12

Exemplo: Persistência (RDBMS-

JDBC) Executando uma query

13

RepositorioCliente

PersistenteBD

GerenciadorTransacoesBD TransacoesBD

: Connection : ResultSet : Statement

ClientePersistente

getTransacao( )


createStatement( )

executeQuery(String)

getString(String)

new ClientePersistente(long, String)

getLong(String)

O parâmetro String

corresponde ao

nome da coluna no

banco de dados.

O parâmetro String

corresponde ao

comando SQL a

ser executado.

Os parâmetros

passados para o

construtor

correspondem aos

recuperados na base

Passos para incorporar persistência

• Identificação das classes necessárias • Uma coleção de dados (repositório) para cada classe persistente

• Incorporar classes ao projeto • Alocação ao pacote respectivo

• Inclusão de relacionamentos com outras classes

• Criação/atualização dos diagramas de interação • Inicialização de conexão

• Acesso: leitura, atualização, remoção, consulta

• Acesso a bibliotecas de classes necessárias à implementação JDBC • Exemplo: java.sql

14

Passo 2. Mapear classes de análise em elementos de projeto • Identificar classes de projeto

• Identificar subsistemas

• Definir interfaces dos subsistemas

• Fazer o mapeamento

15

Mapeando Classes de Análise em Classes e Subsistemas de Projeto

16

Mapeamento m : n

<<boundary>>

<<boundary>>

<<control>>

<<entity>>

Classes de Análise Elementos de Projeto

Fonte: Rational

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 classe de projeto

• Em geral, classes de análise complexas podem ser divididas em várias classes ou transformadas em um pacote ou subsistema

17

Pacotes e Subsistemas

18

• Subsistemas possuem comportamento, enquanto pacotes

são apenas containers de elementos

• Subsistemas encapsulam seus elementos, através de

interfaces (podendo ser substituídos por outros que

preservem a interface)

Client Class

<<subsystem>>

A

Class B1

Class B2

Package B

(interface)

Fonte: Rational

Subsistemas e Interfaces: Notação

19

<<interface>>

interface <<subsystem>>

Nome subsistema

<<subsystem>>

Nome subsistema Interface

Realização

Realização

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

20

Como identificar Subsistemas

• Classes de análise

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

• Classes que fornecem serviços complexos

• Elementos de projeto (por exemplo, componentes)

• Software de comunicação

• Suporte ao acesso a BD

• Estruturas de dados

• Bibliotecas de utilitários

• Produtos específicos à aplicação

21

Como identificar Subsistemas

22

Classe A

Y()

Z()

<<interface>>

Interface A

Y()

Z()

Classe complexa

<<subsystem>>

Subsistema X

A classe fachada

23

<<subsystem>> package

Interface <<subsystem>>

SubSistemaMétricas

Fachada

SubSistemaMétricas

ISubSistemaMétricas

• Além da interface, será destacada uma

classe fachada de cada subsistema

Identificando Subsistemas

24

Análise

<<boundary>>

SistemaMétricas

enviarReportagensProjeto(reportagens)

<<subsystem>>

SubSistemaMétricas

Projeto

ISubSistemaMétricas

enviarReportagensProjeto (reportagens:

ConjuntoReportagens)

Mapeando Classes de Análise em Elementos de Projeto

25

SistemaMétricas

As outras classes de análise

mapeiam diretamente em

classes de projeto

Classe de Análise Elemento de projeto

SubSistemaMétricas

Contexto do subsistema Exemplo

26

FachadaSubSistemaMetricas

enviarReportagensProjeto(reportagens : ConjuntoReportagens)

ISubSistemaMetricas

enviarReportagensProjeto(reportagens : ConjuntoReportagens)

<<Interface>>

ControladorReportagemProjeto

enviar resumo reportagem()

ConjuntoReportagens

Passo 3. Identificar 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

• Mapeie o candidato a subsistema a componentes existentes

27

Possíveis 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

• Exemplo: para implementação de mecanismos arquiteturais

28

Passo 4: Definir organização do sistema • À 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

29

Critérios para organização do sistema em pacotes • Acoplamento e Coesão

• Usuário

• Distribuição

• Segurança

30

Evite dependências cíclicas

Exemplo: organização em pacotes do Timesheet

31

timesheet

gui

FachadaTS

util

colaboradores atividades ...

Exemplo: organização em pacotes do Timesheet

32

atividades

Repositorio

Atividades

CadastroAtividades

Atividade

RepositorioAtividadesBD

Passo 5. 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 do documento da arquitetura

33

A Visão de Implantação

34

Logical

View

Process

View

Deployment

View

Implementation

View

Programmers

Software management

Analysts/

Designers

Structure

System Engineering

System topology

Delivery,installation

Communication

System integrators

Performance Scalability

Throughput

End-user

Functionality

Use-Case View

Por que distribuir sistema em diferentes processos? (visão de processos)

• Utilizar várias CPU’s e/ou nós

• Aumentar a utilização da CPU

• Prover tempo de resposta mais rápido

• Priorizar atividades

• Melhorar disponibilidade

• Suportar sistemas de grande porte

35

Motivação para distribuir sistema em diferentes máquinas

• Reduzir carga de processador

• Requisitos especiais de processamento

• Escalabilidade

• Economia

• Prover acesso distribuído ao sistema

36

Padrões de Distribuição

• Cliente-servidor

• 3 camadas

• Cliente “gordo” (Fat Client)

• Servidor “gordo” (Fat Server)

• Cliente-servidor Distribuído

• Ponto a ponto

37

Ponto a ponto

39

Apresentação

Negócio

Dados

Apresentação

Negócio

Dados

Cliente “gordo”

40

Apresentação Negócio

Dados

Cliente-servidor 3 camadas

42

Apresentação

Negócio

Dados

Arquitetura Web Tradicional

45

Navegador Web

Apresentação Negócio

Dados

Diagrama de implantação: Elementos • Nó

• recurso computacional físico

• pode ser de dois tipos

• processador

• dispositivo

53

<<Node>>

Node # 1

<<Processor>>

Processor # 1

<<Device>>

Device # 1

Diagrama de implantação: Elementos

• Conexão entre nós

• identificar

• mecanismo de comunicação (tecnologia utilizada)

• meio físico utilizado

• protocolo de software

54

<<Device>>

Device # 1

<<Processor>>

Processor # 1

Connection

Tipos de processadores

• Máquinas dos usuários finais

• Terminais burros

• Máquinas servidoras

• Processadores especializados

• Máquinas com configuração especial

• desenvolvimento

• testes

55

Exemplo: configuração de rede do Timesheet

56

PC

Colaborador

PC

Colaborador

Servidor

TimeSheet

Cadastro de

Colaboradores

Rede Interna Rede Interna

Rede Interna

Alocar processos a nós

• De acordo com a configuração da rede, os processos do sistema devem ser alocados 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

57

Definir mecanismo de distribuição • O mecanismo de implementação para distribuição também

deve ser escolhido

• Exemplo: Para RMI foi escolhido Java 1.2 da Sun

58

Revisão: Passos realizados nesta atividade • 1. Identificar e documentar mecanismos de projeto e de

implementação

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

• 3. Identificar oportunidades de reuso

• 4. Definir organização do sistema

• 5. Descrever distribuição

59

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

• Para cada subsistema

• Diagrama de classes com contexto do subsistema

60

Exercício:

• Dado:

• A tabela de mapeamento das classes de análise nos elementos de projeto

• Os relacionamentos entre as classes e subsistemas

• Definir:

• Os pacotes da aplicação e os elementos que devem estar presentes em cada pacote

61

Exercício:

• Dado:

• documento de requisitos

• modelo de projeto

• Produzir:

• principais processos do sistema

• configuração da rede (nós e suas conexões)

• distribuição dos processos entre os nós

62

atividade projetar arquitetura - facombacala/es/11- projetando arquitetura.pdfpassos para projetar...

Documents