atividade projetar arquitetura - facombacala/es/11- projetando arquitetura.pdfpassos para projetar...
TRANSCRIPT
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>>
CadastroClientePersistente
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
CadastroClientePersistente
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( )
getCanalComunicacao( )
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( )
getCanalComunicacao( )
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
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