Projetar Arquitetura



Documentos relacionados
Engenharia de Software

Sistemas Distribuídos

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Diagrama de Estrutura Composta

Programação Orientada a Objetos (DPADF 0063)

Aula 03-04: Modelos de Sistemas Distribuídos

TechProf Documento de Arquitetura

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

Programação com Acesso a Banco de Dados

Java & Bancos de Dados Adaptado de Slides da Universidade Salgado de Oliveira Goiânia

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

Figura 5 - Workflow para a Fase de Projeto

Franklin Ramalho Universidade Federal de Campina Grande - UFCG

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO

Integrando Java com Banco de Dados

2 Engenharia de Software

Unified Modeling Language. Diagramas de Implementação

Documento de Projeto de Sistema

Laboratório de Banco de Dados Aula 1 Acesso a Banco de Dados. Prof. Josenildo Silva jcsilva@ifma.edu.br

Análise e Projeto Orientados por Objetos

Gestão de projectos na Web

Manipulação de Banco de Dados com Java. Ms. Bruno Crestani Calegaro Maio/ 2015

UFG - Instituto de Informática

Linguagem de Programação Orientada a Objeto. Introdução a Orientação a Objetos Professora Sheila Cáceres

BACHARELADO EM SISTEMAS DE INFORMAÇÃO EaD UAB/UFSCar Sistemas de Informação - prof. Dr. Hélio Crestana Guardia

04/07/2015 UML. Prof. Esp. Fabiano Taguchi DEFINIÇÃO DE REQUSIITOS

Introdução a Web Services

Computador Digital Circuitos de um computador (Hardware)

Eduardo Bezerra. Editora Campus/Elsevier

Motivos para você ter um servidor

Programação Orientada a Objetos JDBC Java Database Connectivity

Gerenciamento de Requisitos Gerenciamento de Requisitos

Aula 1 Acesso a Banco de Dados

Introdução à Computação: Sistemas de Computação

Sistemas Distribuídos: Conceitos e Projeto Java RMI

Capítulo 3 Projeto de Arquitetura

Unidade 8: Padrão MVC e DAO Prof. Daniel Caetano

Introdução a Banco de Dados Aula 03. Prof. Silvestri

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira

3. Fase de Planejamento dos Ciclos de Construção do Software

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Tópicos em Engenharia de Computação

Introdução ao Paradigma Orientado a Objetos. Principais conceitos

Capítulo 2. Processos de Software Pearson Prentice Hall. Todos os direitos reservados. slide 1

sendo bastante acessível e compreendido pelos usuários que o utilizarem.

Sistemas Distribuídos Processos I. Prof. MSc. Hugo Souza

Sistema de Bancos de Dados. Conceitos Gerais Sistema Gerenciador de Bancos de Dados

DESENVOLVENDO O SISTEMA

Desenvolvimento Cliente-Servidor 1

Ano IV - Número 19. Versões e 5.1

Padrão Arquitetura em Camadas

Banco de Dados Orientado a Objetos

Simulador de IEDs utilizando arquivos ICD/SCD

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS -ARQUITETURAS DE APLICAÇÃO MÓVEL. Prof. Angelo Augusto Frozza, M.Sc.

Java Beans e Servlets

Itens estruturais/caso de uso. Itens estruturais/classe ativa. Itens estruturais/componente. Itens estruturais/artefatos. Itens comportamentais

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados.

3.1 Definições Uma classe é a descrição de um tipo de objeto.

Sistemas Distribuídos (DCC/UFRJ)

Requisitos de Sistemas

DSS 09/10. DSS 09/10 Que métodos é que fazem parte de cada camada? Aplicações Multi-camada JDBC. Aula 3 DSS 09/10

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Análise e Projeto Orientado a Objetos

Tarciane Andrade.

O que é o Android? O que é o Android

Padrões de Interação com o Usuário

Linguagem de Modelagem Unificada

DSS 08/09. Camada de Dados - JDBC. Aula 1. António Nestor Ribeiro /António Ramires Fernandes/ José Creissac Campos {anr,arf,jfc}@di.uminho.

1

Banco de Dados Conceito de Arquitetura

Análise e Projeto Orientados por Objetos

BPM e SOA. Grinaldo Lopes de Oliveira (grinaldo@gmail.com) Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PRÓ-REITORIA DE ENSINO DE GRADUAÇÃO (PROENG) ASSESSORIA DE DESENVOLVIMENTO ASSESSORIA JURÍDICA

MANUAL DE PROCEDIMENTOS MPR/SGP-500-R00 ARQUIVAMENTO DE PROCESSOS NA SGP

Laboratório de Computação VI JAVA IDL. Fabricio Aparecido Breve

Introdução ao Processo Unificado (PU)

SISTEMA GERENCIADOR DE BANCO DE DADOS

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl

Prof. Fábio Lúcio Meira

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr

CURSO DESENVOLVEDOR JAVA Edição 2010

Banco de Dados. Banco de Dados. Alcides Pamplona Alcides Pamplona Linguagem de Programação CESBD 2010

Projeto. Gerenciamento de Projeto de Software. Tópicos abordados. Características básicas de um projeto. Definição

No projeto das primeiras redes de computadores, o hardware foi a principal preocupação e o software ficou em segundo plano.

Disciplina de Redes de Computadores Estudo Dirigido para a Prova II Professor Dr Windson Viana de Carvalho

4.1. UML Diagramas de casos de uso

Nível do Sistema Operacional

Micro Mídia Informática Fevereiro/2009

Orientação a Objeto e UML Questões 2014 Prof. Felipe Leite

Curso de Aprendizado Industrial Desenvolvedor WEB

UML: Diagrama de Casos de Uso, Diagrama de Classes

Uma Abordagem usando PU

2 a Lista de Exercícios

SISTEMAS DE INFORMAÇÃO GERENCIAIS

Transcrição:

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

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

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

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

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

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

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

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

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

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 Classes de Análise Elementos de Projeto <<boundary>> <<control>> <<entity>> <<boundary>> Mapeamento m : n Fonte: Rational 16

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

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

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 Classe A Y() Z() Classe complexa <<interface>> Interface A Y() Z() <<subsystem>> Subsistema X 22

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

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

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

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

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 Evite dependências cíclicas 30

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

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

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

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

38

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

Cliente gordo Apresentação Negócio Dados 40

41

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

43

44

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

46

47

48

49

50

51

52

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

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

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 PC Colaborador PC Colaborador Rede Interna Rede Interna Servidor TimeSheet Rede Interna Cadastro de Colaboradores 56

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