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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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