Análise e Projeto Orientados a Objeto com UML e Padrões

Apresentação em tema: "Análise e Projeto Orientados a Objeto com UML e Padrões"— Transcrição da apresentação:

1 Análise e Projeto Orientados a Objeto com UML e Padrões
Parte IV Projeto (1B) Prof. Msc. Emerson Silas Dória

2 Projetando uma solução com Objetos e Padrões
Operação:EntrarItem Pós-Condições: 1. Se tSe for uma nova venda, uma Venda foi criada (criação de instância); Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) EntrarItem(UPC,quantidade) :Sistema Operador DSS Operações do Contratos Operação: TerminarVenda 1. Venda.Completada recebe o valor... Diagrama de Colaboração ou Seqüência :POST EntrarItem(UPC, quantidade) A partir dos Casos de Usos levanta-se os Eventos de Sistema para o DSS Prof. Msc. Emerson Silas Dória

3 Projetando uma solução com Objetos e Padrões
1º Passo: Criar os DI: Crie um DI separado para operação do sistema: Para cada evento do sistema, crie um DI com o evento como a mensagem inicial. :POST EntrarItem 1:???( ) TerminarVenda RegistrarPagamento Inicializar A classe POST servirá de controladora do eventos Prof. Msc. Emerson Silas Dória

4 Projetando uma solução com Objetos e Padrões
2º Passo: Utilizar os Contratos Caso os contratos não tenham sido construídos, deve-se voltar aos casos de uso e pensar sobre o que deve ser conseguido. Contrato: RegistrarPagamento(quantia:numero) Responsabilidade: Registrar o pagamento, calcular o troco e imprimir recibo. Tipo: Sistema Referência Cruzada: Funções: R2.1 Caso de Uso: Comprar Itens Notas: Exceções: Se a venda não está completa, indicar um erro Se a quantia for menor que o total da venda, indicar um erro Saída: Pré-condições: Pós-condições: Um Pagamento foi criado (criação de instância); Pagamento.quantiaFornecida recebeu o valor da quantia (modificação de atributos); O Pagamento foi associado à Venda (relacionamento foi formado); A Venda foi associada à Loja, para acrescentá-la ao histórico de vendas completadas (relacionamento foi formado). Prof. Msc. Emerson Silas Dória

5 Projetando uma solução com Objetos e Padrões
POST Item Loja Venda Pagamento Item Venda Operador Cliente Gerente Catálogo de Produtos Especificação de Produto estoca * possui 1..* usado-por contém descreve capturada-por contido-em descrito-por registra-venda-de 0..1 iniciado-por paga-por iniciada-por log-vendas realizadas 6 3 registra-venda-no 1 3º Passo: Considerar o Modelo Conceitual Prof. Msc. Emerson Silas Dória

6 Iniciando a Construção
Criando uma nova Venda Pelo Criador, POST cria Venda, e Venda cria uma coleção (vazia) para registrar objetos ItemVenda Observações: A exibição da descrição e do preço serão tratados posteriormente; Considere os contratos e modelo conceitual; Prof. Msc. Emerson Silas Dória

7 Iniciando a Construção
Criando um novo ItemVenda Pelo Criador, Venda cria objetos ItemVenda POST passa o parâmetro quantidade para Venda, que o repassa para ItemVenda como parâmetro da mensagem criar_iv Pelo Criador, POST envia mensagem criar_iv para Venda, que então cria um novo ItemVenda e o adiciona à sua coleção de objetos ItemVenda Encontrando uma Especificação de Produto Pelo Especialista, CatalogoDeProdutos faz a busca pela EspecificaçãoDeProduto baseado em uma correspondência de UPCs. Prof. Msc. Emerson Silas Dória

8 Iniciando a Construção
Visibilidade para CatalogoDeProdutos CatalogoDeProdutos é visível para POST pois ambos instâncias são criadas e associadas durante o caso de uso Inicialização Assim, é POST quem envia mensagem de busca de especificação para CatalogoDeProdutos Buscando EspecificaçãoDeProduto no Banco de Dados Persistência será tratada posteriormente (pressupõe todos em memória) Mostrando Descrição e Preço Interação com IU ignorada nesse estágio; objetos de negócio não devem se comunicar com objetos da IU (Padrão MVC(MVS)) Prof. Msc. Emerson Silas Dória

9 DI [Colaboração] EntrarItem
:POST EntrarItem(UPC,QTD) 3:criar_iv(ESPEC, QTD) :Venda iv:ItemVenda 3.1:criar_iv(ESPEC, QTD ) 1:[novavenda] criar( ) :ItemVenda 1.1:criar( ) 3.2:adicionar(iv) :CatalogoDe Produtos :Especificação DeProduto 2:ESPEC:=especificação(UPC) 2.1:ESPEC:=encontrar(UPC) Prof. Msc. Emerson Silas Dória

10 DI [Colaboração] TerminarVenda
Definindo atributo Venda.completada :POST TerminarVenda( ) 1:completar( ) v:Venda completar() { completada:=true } Prof. Msc. Emerson Silas Dória

11 DI [Colaboração] TerminarVenda
Durante a criação dos DI’s não se preocupe com a exibição de informações, exceto quando a informação requerida não é conhecida no momento. Calculando o Total da Venda 2.1:pr:=obter_preço( ) :Venda iv:ItemVenda :ItemVenda pd:Especificação DeProduto 1:[para cada] iv:next( ) obter_total( ) { total:=0 para cada itemvenda, iv tot:=tot+iv.obter_subtotal( ) return( ) } classe Venda 2:st:=obter_subtotal( ) tot:obter_total( ) obter_subtotal( ) quantidade*pd.preço } classe ItemVenda Um DI pode não ser iniciado por um evento de sistema. Prof. Msc. Emerson Silas Dória

12 DI [Colaboração] RegistrarPagamento
Criando Pagamento Pelo Especialista, POST e Venda podem criar um Pagamento Considerando também Alta Coesão e Baixo Acoplamento, Venda é a melhor escolha. :POST :Venda Pagamento 1:registrarPagamento(df) registrarPagamento(df) 1.1:criar(df) Prof. Msc. Emerson Silas Dória

13 DI [Colaboração] Inicializar
Visibilidade permanente de Loja para POST. :Loja :POST cp:CatalogoDe Produtos 2:criar(cp) criar( ) :ItemVenda :EspecificaçãoDe Produto ep:Especificação DeProduto 1:criar( ) 1.2:carregaEspeProd( ) 1.1:criar( ) 1.2.2*:adicionar(ep) 1.2.1*:criar(UPC,PRECO,DESCRICAO) Objeto inicial, mas não responsável por assumir o controle da aplicação. É criado pela camada de apresentação. Prof. Msc. Emerson Silas Dória

14 Aplicações Multicamadas
Conectando as camadas de apresentação e lógica da aplicação post : POST Cashier :POSTApplet onEnterItem() 1: enterItem(upc, qty) 2: [no sale] sale := getSale() : Sale Object Store Enter Item End Sale UPC Make Payment Total Quantity Tendered Balance presses button Presentation Layer Domain sale : Sale 3: t := total() : Float store :Store 1: create() 2: p := getPOST() : POST :POSTApplet create() Prof. Msc. Emerson Silas Dória

15 Visibilidade entre Objetos
Capacidade de um objeto “ver” ou ter uma referência para outro objeto. Necessária para comunicação (envio de mensagens) entre objetos. Quatro maneiras de B ser visível por A: Visibilidade de atributo: B é um atributo de A Visibilidade de parâmetro: B é um parâmetro de um método de A Visibilidade declarada localmente: B é declarado como um objeto local em um método de A Visibilidade global : B é de algum modo visível globalmente Prof. Msc. Emerson Silas Dória

16 Visibilidade Atributo
Existe de A para B quando B é um atributo de A Permanente, persiste enquanto A e B existirem EntrarItem(UPC,QTD) Class POST { private CatalagoDeProdutos cp; } :POST 2:ESPEC:=especificação(UPC) cp:CatalogoDe Produtos EntraItem(UPC, QTD) { ESPEC = cp.especificacao(UPC) } classe POST Prof. Msc. Emerson Silas Dória

17 Visibilidade Parâmetro
Existe de A para B quando B é passado como um parâmetro para um método de A Temporária, persiste apenas dentro do escopo do método :POST EntrarItem(UPC,QTD) 3:criar_iv(ESPEC, QTD) :Venda iv:ItemVenda 3.1:criar_iv(ESPEC, QTD ) 1:[novavenda] criar( ) :CatalogoDe Produtos 2:ESPEC:=especificação(UPC) criar_iv(EspecificacaoDeProduto ESPEC, int QTD) { ... } classe Venda Prof. Msc. Emerson Silas Dória

18 Visibilidade Declarada Localmente
Existe de A para B quando B é declarado como um objeto local dentro de um método de A Temporária, persiste apenas dentro do escopo do método Duas maneiras comuns de alcançar: 1. Criar uma nova instância local e atribuir a uma variável local 2. Atribuir objeto de retorno de um método para uma variável local :POST EntrarItem(UPC,QTD) 3:criar_iv(ESPEC, QTD) :Venda 1:[novavenda] criar( ) :CatalogoDe Produtos 2:ESPEC:=especificação(UPC) EntrarItem(UPC, QTD) { EspecificacaoDeProduto ESPEC = cp.especializacao (UPC); } classe POST Prof. Msc. Emerson Silas Dória

19 Prof. Msc. Emerson Silas Dória
Visibilidade Global Existe de A para B quando B é global para A Permanente, persiste enquanto A e B existirem Forma menos comum de visibilidade em sistemas desenvolvidos utilizando OO Maneira mais comum (mas menos desejável) de atingir é atribuir nova instância a uma variável global Alternativa recomenda: Padrão Singleton (GoF) Prof. Msc. Emerson Silas Dória

20 Notação de Visibilidade na UML
Uso opcional de “estereótipos” específicos :A 1:msg( ) :B <<atributo>> 2:msg( ) :C <<parâmetro>> 3:msg( ) :D <<local>> 4:msg( ) :E <<global>> Prof. Msc. Emerson Silas Dória

21 Definindo Diagramas de Classe
Sinc. Artefatos Análise Projeto Teste Refin. Plano Impl. 2. Definir Rel. & IU 4. Definir Diag. Interação 5. Definir Diag. Classe a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diagrama de interação b. ordem variada Prof. Msc. Emerson Silas Dória

22 Prof. Msc. Emerson Silas Dória
Diagramas de Classe Um diagrama de classe ilustra as especificações de software para as classes e interfaces do sistema Inclui: Classes, associações e atributos Interfaces (com operações e constantes) Métodos Informação sobre o tipo dos atributos Navegabilidade Dependências UML não diferencia modelo conceitual de diagrama de classe (o termo “classe de implementação” é usado para distinguir o segundo do primeiro) Prof. Msc. Emerson Silas Dória

23 Diagramas de Classe Diagrama parcial para as classes POST e Venda no sistema POST: Venda data, hora status:boolean obter_total( ) métodos POST entrarItem( ) navegabilidade informações sobre tipos captura 1 Prof. Msc. Emerson Silas Dória

24 Como Fazer um Diagrama de Classe
Regras úteis: Identificar todas as classes participantes da solução, proposta pelos diagramas de interação; Desenhar as classes num diagrama de classe; Incluir os atributos identificados no modelo conceitual; Adicionar métodos tal como identificados nos diagramas de interação; Adicionar informação sobre tipos aos atributos e métodos; Adicionar as associações necessária para permitir a visibilidade de atributos. Prof. Msc. Emerson Silas Dória

25 Como Fazer um Diagrama de Classe
Regras úteis (continuação): Adicionar setas de navegabilidade para indicar a direção da visibilidade de atributos; Adicionar relacionamentos de dependência para indicar outros tipos de visibilidade. Prof. Msc. Emerson Silas Dória

26 Modelo de Conceitual X Diagrama de Classe
Modelo Conceitual: abstração de conceitos do mundo real Diagrama de Classe: especificação de componentes de software POST Venda Modelo Conceitual captura data, hora status:boolean 1 1 POST Venda Diagrama de Classe data, hora status:boolean 1 captura 1 entrarItem( ) obter_total( ) Prof. Msc. Emerson Silas Dória

27 POST Criando Diagramas de Classe
Identificando classes e atributos Observar os DI e Modelo Conceitual POST CataladoDeProdutos quantidade EspecificacaoDeProduto descricao preco UPC Loja nome endereco Venda data hora status ItemVenda Pagamento quantia Prof. Msc. Emerson Silas Dória

28 Criando Diagramas de Classe para o Sistema POST
Adicionando nomes aos métodos Observe as mensagens dos DI POST TerminarVenda() EntrarItem() RegistrarPagamento() CataladoDeProdutos quantidade Especificação() EspecificacaoDeProduto descricao preco UPC Loja nome endereco Venda data hora status Completar() Criar_iv() RealizarPagamento() Obter_Total() ItemVenda Obter_Subtotal() Pagamento quantia Prof. Msc. Emerson Silas Dória

29 Criando Diagramas de Classe para o Sistema POST
Adicionando informação sobre o tipo dos atributos Opcional Grau de detalhe dependente do público-alvo. Venda data hora status Completar() Criar_iv(ESPEC: EspecificacaoDeProduto; QTD:integer) RealizarPagamento() Obter_Total() Prof. Msc. Emerson Silas Dória

30 Criando Diagramas de Classe para o Sistema POST
Navegabilidade implica visibilidade, geralmente visibilidade de atributo. Adicionando associações e navegabilidade Investigar os DI POST TerminarVenda() EntrarItem() RegistrarPagamento() CataladoDeProdutos quantidade Especificação() EspecificacaoDeProduto descricao preco UPC Loja nome endereco Venda data hora status Completar() Criar_iv() RealizarPagamento() Obter_Total() ItemVenda Obter_Subtotal() Pagamento quantia 1 1..* * usa busca_em captura pago_por contém possui descreve As conexões envolvidas nos DI estarão representadas como associações no Diagrama de Classes Prof. Msc. Emerson Silas Dória

31 Características dos Elementos de Classe
UML oferece notação rica para descrever características como visibilidade, valores iniciais, etc. No sistema POST: todos os atributos são privados e todos os métodos são públicos Class Name attribute attribute : type attribute : type = initial value classAttribute /derivedAttribute ... method1() method2(parameter list) : return type abstractMethod() +publicMethod() -privateMethod() #protectedMethod() classMethod() Prof. Msc. Emerson Silas Dória

32 Arquitetura do Sistema
Sinc. Artefatos Análise Projeto Teste Refin. Plano Impl. 2. Definir Rel. & IU 4. Definir Diag. Interação 5. Definir Diag. Classe a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diagrama de interação b. ordem variada Prof. Msc. Emerson Silas Dória

33 Arquitetura Multicamadas
Object Store Enter Item End Sale UPC Make Payment Total Quantity Tendered Balance GartnerGroup, 95 Apresentação Lógica da Aplicação -> objetos de domínio Venda Pagamento BD Segurança -> objetos de serviço Armazenamento SGBD Prof. Msc. Emerson Silas Dória

34 Vantagens da Arquitetura Multicamadas
Implantação em várias configurações Isolamento da lógica da aplicação em componentes separados, possibilitando reutilização Distribuição através de diferentes computadores e/ou processos Alocação de desenvolvedores para construção de camadas específicas Prof. Msc. Emerson Silas Dória

35 Representando Arquiteturas com Pacotes
Um pacote é um conjunto de elementos de modelo de qualquer tipo (casos de uso, classes, diagramas de interação), incluindo outros pacotes; O sistema inteiro pode ser considerado dentro do escopo de um único pacote, o pacote Sistema Notação para pacotes na UML: Conceitos do Dominio Elementos Centrais Venda Prof. Msc. Emerson Silas Dória

36 Pacotes Arquitetura de um Sistema de Informação
Presentation 1 Domain Relational Database Interface Communication Reporting Application Frameworks & Support Libraries 2 Low-level Services Layer (object and non-object oriented) Object Database High-level Object- oriented Examples: 1. Java Applets, MFC Documents and Views, VisualAge Visual Parts 2. JDK, MFC, STL Relational Database Object Prof. Msc. Emerson Silas Dória

37 Identificando Pacotes
Regras úteis: Agrupar em um pacote elementos que oferecem um serviço comum (ou uma família de serviços relacionados), com acoplamento e colaboração relativamente altos. Em níveis mais altos de abstração, o pacote deve ser visto como um elemento altamente coeso, com responsabilidades fortemente relacionadas. Por outro lado, o acoplamento e colaboração entre elementos agrupados em diferentes pacotes devem ser relativamente baixos. Prof. Msc. Emerson Silas Dória

38 Visibilidade entre Pacotes
Visibilidade típica: Acesso a pacotes de domínio Outros pacotes (normalmente pacotes de apresentação) têm visibilidade para várias das classes que representam conceitos de domínio. Acesso a pacotes de serviço Outros pacotes (normalmente pacotes de domínio e apresentação) têm visibilidade para apenas uma ou poucas classes em cada particular pacote de serviço. Padrão Façade (Fachada) - GoF Acesso a pacotes de apresentação Nenhum outro pacote tem visibilidade direta para as classes da camada de apresentação; comunicação, quando há, é de forma indireta. Prof. Msc. Emerson Silas Dória

39 Interface dos Pacotes de Serviço Patterns: Façade - GoF (Fachada)
Uma Fachada é uma classe que oferece uma interface comum para um grupo de outros componentes ou um conjunto de interfaces originalmente separadas; Usada para oferecer um interface pública comum para um pacote de serviço; Classes de outros pacotes comunicam-se apenas com a fachada, a qual colabora com as outras classes internas (privadas) para oferecer o serviço; Suporta baixo acoplamento Prof. Msc. Emerson Silas Dória

40 Sem Visibilidade para Janelas Patterns: Separação Modelo-Visão
Objetos do modelo (domínio) não deveriam ter conhecimento direto dos objetos devisão (apresentação), ou estar diretamente acoplados a estes. Classes de domínio encapsulam a informação e o comportamento relacionados à lógica da aplicação Classes de apresentação responsáveis apenas por operações de entrada/saída Prof. Msc. Emerson Silas Dória

41 Sem Visibilidade para Janelas Patterns: Separação Modelo-Visão
:POST Presentation (View) Layer (e.g., POSTApplet) Domain (Model) Layer Worse. Messaging or coupling from the Model layer to the View layer is not desirable. Better. Messages from View to Model layer. Supports model-view separation. 1: enterItem(upc, qty) 1: displayMessage(msg) Object Store Enter Item End Sale UPC Make Payment Total Quantity Tendered Balance Prof. Msc. Emerson Silas Dória

42 Vantagens do Padrão Separação Modelo-Visão
Foco em processos do domínio, em vez de em mecanismo de interação e apresentação; Desenvolvimento separado das camadas de lógica da aplicação e apresentação; Redução do impacto de mudanças na camada de apresentação nos objetos de domínio; Capacidade de incluir novos mecanismos de interação, sem afetar a lógica da aplicação; Suporte para múltiplas visões do mesmo objeto de domínio; Execução e teste da lógica da aplicação independentemente da camada de apresentação. Prof. Msc. Emerson Silas Dória

43 Prof. Msc. Emerson Silas Dória
Comunicação Indireta Evita acoplamento entre objetos remetentes (senders) e e seus destinatários (receivers) Suporte para difusão (broadcast) de mensagens Mecanismo mais comuns: Padrão Editor-Assinante (ou Observador) Callbacks Notificação de eventos Prof. Msc. Emerson Silas Dória

44 Coordenadores de Aplicação
Um coordenador de aplicação é uma classe responsável pela mediação entre as camadas de apresentação e lógica da aplicação Responsabilidades básicas: Mapear informação entre objetos de domínio e IU Responder a eventos capturados pela IU Abrir janelas para mostrar informação produzida pelos objetos de domínio Atualizar janelas quando informação à mostra muda na camada de lógica da aplicação- caso haja múltiplas visões para o mesmo objeto de domínio Gerenciar transações Prof. Msc. Emerson Silas Dória

45 Armazenamento e Persistência
Requer um subsistema específico para mapear entre objetos de domínio e objetos do BD Implementado de forma semi-transparente através de frameworks de persistência Domain Relational Database Interface Object Database Interface Relational Database Object Prof. Msc. Emerson Silas Dória