Projetar Arquitetura

Transcrição

1 Projetar Arquitetura

2 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

3 Visão geral dos artefatos Especificações suplementares Glossário Documento da arquitetura Orientações de projeto Projetar Arquitetura Classes de análise Modelo de projeto Fonte: Rational Modelo de projeto (classes e subsistemas) 3

4 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

5 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

6 Passo 1. Identificar e documentar mecanismos de projeto e de implementação Mecanismos arquiteturais devem ser documentados usandose 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 Aspecto estrutural Comportamento Orientações de projeto 6

7 Mecanismos de Arquitetura Mecanismos de análise (conceitual) Mecanismos de projeto (concreto) Mecanismos de implementação (produto real) Persistência RDBMS JDBC Persistência OODBMS ObjectStore Distribuição Remote Method Invocation (RMI) Java 1.2 (Sun) ANÁLISE PROJETO IMPLEMENTAÇÃO 7 Fonte: Rational

8 Exemplo: Persistência (RDBMS- JDBC) Fachada CadastroClientePersistente ClientePersistente <<Interface>> RepositorioClientePersistente <<Interface>> RepositorioIteravelClientePersistente <<Interface>> Transacao <<Interface>> GerenciadorTransacoes RepositorioClientePersistenteException 8 TransacaoException

9 Exemplo: Persistência (RDBMS-JDBC) Assinaturas das coleções de dados (repositórios) Fachada CadastroClientePersistente <<Interface>> 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 ClientePersistente <<Interface>> RepositorioIteravelClientePersistente proximo() : ClientePersistente anterior() : ClientePersistente temproximo() : boolean temanterior() : boolean tamanho() : int primeiro() : ClientePersistente ultimo() : ClientePersistente 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. RepositorioClientePersistenteException As 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". 9

10 Exemplo: Persistência (RDBMS-JDBC) Gerenciamento de transações <<Interface>> Transacao iniciar() : void confirmar() : void cancelar() : void finalizar() : void getestado() : int transacaoiniciada() : boolean getid() : int setid(id : int) : void getcanalcomunicacao() : Object TransacaoException <<Interface>> GerenciadorTransacoes novatransacao() : Transacao gettransacao() : Transacao gettransacao(id : int) : Transacao finalizartransacao() : void finalizartransacao(id : int) : void Os métodos gettransacao() e finalizartransacao() não recebem parâmetros porque operam sobre a transação registrada ao thread atual (operam sob contexto) 10

11 Exemplo: Persistência (RDBMS-JDBC) Implementação dos repositórios Fachada CadastroClientePersistente <<Interface>> RepositorioClientePersistente <<Interface>> RepositorioIteravelClientePersistente RepositorioIteravelClientePersistenteArray RepositorioClientePersistenteBD <<Interface>> GerenciadorTransacoes novatransacao() gettransacao() gettransacao() finalizartransacao() finalizartransacao() <<Interface>> Transacao iniciar() confirmar() cancelar() finalizar() getestado() transacaoiniciada() getid() setid() getcanalcomunicacao() GerenciadorTransacoesBD TransacaoBD 11 GerenciadorPoolConexoes

12 Exemplo: Persistência (RDBMS-JDBC) Realizando uma transação com o BD Fachada CadastroClientePersistente RepositorioClientePersistenteBD GerenciadorTransacoesBD TransacaoBD GerenciadorPoolConexoes novatransacao( ) alocarconexao(java.lang.string) new TransacaoBD(jav a.sql.connection) iniciar( ) inserir(clientepersistente) inserir(clientepersistente) Após obter a conexão, o repositório utiliza a API de JDBC para excutar o(s) comando(s) SQL. gettransacao( ) getcanalcomunicacao( ) 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. confirmar( ) cancelar( ) finalizartransacao( ) 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. getcanalcomunicacao( ) liberarconexao(jav a.lang.string, jav a.sql.connection) finalizar( ) 12

13 Exemplo: Persistência (RDBMS- JDBC) Executando uma query RepositorioCliente PersistenteBD GerenciadorTransacoesBD TransacoesBD : Connection : ResultSet : Statement ClientePersistente gettransacao( ) getcanalcomunicacao( ) createstatement( ) O parâmetro String corresponde ao comando SQL a ser executado. executequery(string) getlong(string) getstring(string) new ClientePersistente(long, String) O parâmetro String corresponde ao nome da coluna no banco de dados. Os parâmetros passados para o construtor correspondem aos recuperados na base 13

14 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

15 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

16 Mapeando Classes de Análise em Classes e Subsistemas de Projeto Classes de Análise Elementos de Projeto <<boundary>> <<control>> <<entity>> <<boundary>> Mapeamento m : n Fonte: Rational 16

17 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

18 Pacotes e Subsistemas 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 (interface) Package B Class B1 <<subsystem>> A Class B2 18 Fonte: Rational

19 Subsistemas e Interfaces: Notação <<interface>> interface <<subsystem>> Nome subsistema Realização Interface Realização <<subsystem>> Nome subsistema 19

20 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

21 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

22 Como identificar Subsistemas Classe A Y() Z() Classe complexa <<interface>> Interface A Y() Z() <<subsystem>> Subsistema X 22

23 A classe fachada Além da interface, será destacada uma classe fachada de cada subsistema <<subsystem>> package Interface ISubSistemaMétricas <<subsystem>> SubSistemaMétricas Fachada SubSistemaMétricas 23

24 Identificando Subsistemas Análise <<boundary>> SistemaMétricas enviarreportagensprojeto(reportagens) Projeto <<subsystem>> SubSistemaMétricas ISubSistemaMétricas enviarreportagensprojeto (reportagens: ConjuntoReportagens) 24

25 Mapeando Classes de Análise em Elementos de Projeto Classe de Análise SistemaMétricas Elemento de projeto SubSistemaMétricas As outras classes de análise mapeiam diretamente em classes de projeto 25

26 Contexto do subsistema Exemplo ControladorReportagemProjeto enviar resumo reportagem() <<Interface>> ISubSistemaMetricas enviarreportagensprojeto(reportagens : ConjuntoReportagens) ConjuntoReportagens FachadaSubSistemaMetricas enviarreportagensprojeto(reportagens : ConjuntoReportagens) 26

27 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

28 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

29 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

30 Critérios para organização do sistema em pacotes Acoplamento e Coesão Usuário Distribuição Segurança Evite dependências cíclicas 30

31 Exemplo: organização em pacotes do Timesheet timesheet FachadaTS colaboradores atividades... gui util 31

32 Exemplo: organização em pacotes do Timesheet atividades CadastroAtividades RepositorioAtividadesBD Repositorio Atividades Atividade 32

33 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

34 A Visão de Implantação Logical View Implementation View Analysts/ Designers Structure End-user Functionality Use-Case View Programmers Software management System integrators Performance Scalability Throughput Process View Deployment View System Engineering System topology Delivery,installation Communication 34

35 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

36 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

37 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

38 38

39 Ponto a ponto Apresentação Negócio Dados Apresentação Negócio Dados 39

40 Cliente gordo Apresentação Negócio Dados 40

41 41

42 Cliente-servidor 3 camadas Apresentação Negócio Dados 42

43 43

44 44

45 Arquitetura Web Tradicional Navegador Web Apresentação Negócio Dados 45

46 46

47 47

48 48

49 49

50 50

51 51

52 52

53 Diagrama de implantação: Elementos Nó recurso computacional físico pode ser de dois tipos processador dispositivo <<Node>> Node # 1 <<Processor>> Processor # 1 <<Device>> Device # 1 53

54 Diagrama de implantação: Elementos Conexão entre nós identificar mecanismo de comunicação (tecnologia utilizada) meio físico utilizado protocolo de software <<Processor>> Processor # 1 Connection <<Device>> Device # 1 54

55 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

56 Exemplo: configuração de rede do Timesheet PC Colaborador PC Colaborador Rede Interna Rede Interna Servidor TimeSheet Rede Interna Cadastro de Colaboradores 56

57 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

58 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

59 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

60 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

61 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

62 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