A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV Projeto (1B)"— Transcrição da apresentação:

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

2 Prof. Msc. Emerson Silas Dória2 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 TerminarVenda() RegistrarPagamento(quantia) DSSOperações do Sistema Contratos Operação: TerminarVenda Pós-Condições: 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

3 Prof. Msc. Emerson Silas Dória3 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:???( ) :POST TerminarVenda 1:???( ) :POST RegistrarPagamento 1:???( ) :POST Inicializar 1:???( ) A classe POST servirá de controladora do eventos

4 Prof. Msc. Emerson Silas Dória4 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: n Um Pagamento foi criado (criação de instância); n Pagamento.quantiaFornecida recebeu o valor da quantia (modificação de atributos); n O Pagamento foi associado à Venda (relacionamento foi formado); n A Venda foi associada à Loja, para acrescentá-la ao histórico de vendas completadas (relacionamento foi formado).

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

6 Prof. Msc. Emerson Silas Dória6 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; Iniciando a Construção

7 Prof. Msc. Emerson Silas Dória7 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. Iniciando a Construção

8 Prof. Msc. Emerson Silas Dória8 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)) Iniciando a Construção

9 Prof. Msc. Emerson Silas Dória9 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)

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

11 Prof. Msc. Emerson Silas Dória11 Calculando o Total da Venda 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. Um DI pode não ser iniciado por um evento de sistema. 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

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

13 Prof. Msc. Emerson Silas Dória13 DI [Colaboração] Inicializar Objeto inicial, mas não responsável por assumir o controle da aplicação. É criado pela camada de apresentação. :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) Visibilidade permanente de Loja para POST.

14 Prof. Msc. Emerson Silas Dória14 Aplicações Multicamadas Conectando as camadas de apresentação e lógica da aplicação store :Store 1: create() 2: p := getPOST() : POST :POSTApplet create()

15 Prof. Msc. Emerson Silas Dória15 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

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

17 Prof. Msc. Emerson Silas Dória17 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

18 Prof. Msc. Emerson Silas Dória18 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

19 Prof. Msc. Emerson Silas Dória19 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)

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

21 Prof. Msc. Emerson Silas Dória21 Definindo Diagramas de Classe Sinc. Artefatos AnáliseProjetoTeste 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

22 Prof. Msc. Emerson Silas Dória22 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)

23 Prof. Msc. Emerson Silas Dória23 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 1

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

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

26 Prof. Msc. Emerson Silas Dória26 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 Venda data, hora status:boolean POST captura 1 1 Venda data, hora status:boolean obter_total( ) POST captura 1 1 entrarItem( ) Diagrama de Classe Modelo Conceitual

27 Prof. Msc. Emerson Silas Dória27 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 quantidade Pagamento quantia

28 Prof. Msc. Emerson Silas Dória28 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 quantidade Obter_Subtotal() Pagamento quantia

29 Prof. Msc. Emerson Silas Dória29 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()

30 Prof. Msc. Emerson Silas Dória30 Criando Diagramas de Classe para o Sistema POST Adicionando associações e navegabilidade Investigar os DI As conexões envolvidas nos DI estarão representadas como associações no Diagrama de Classes Navegabilidade implica visibilidade, geralmente visibilidade de atributo. 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 quantidade Obter_Subtotal() Pagamento quantia * * usa busca_em captura pago_por contém possui descreve

31 Prof. Msc. Emerson Silas Dória31 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 Características dos Elementos de Classe Class Name attribute attribute : type attribute : type = initial value classAttribute /derivedAttribute... method1() method2(parameter list) : return type abstractMethod() +publicMethod() -privateMethod() #protectedMethod() classMethod()...

32 Prof. Msc. Emerson Silas Dória32 Arquitetura do Sistema Sinc. Artefatos AnáliseProjetoTeste 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

33 Prof. Msc. Emerson Silas Dória33 Arquitetura Multicamadas Apresentação Lógica da Aplicação Armazenamento SGBD Object Store Enter ItemEnd Sale UPC Make Payment Total Quantity TenderedBalance VendaPagamento BDSegurança -> objetos de domínio -> objetos de serviço GartnerGroup, 95

34 Prof. Msc. Emerson Silas Dória34 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

35 Prof. Msc. Emerson Silas Dória35 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

36 Prof. Msc. Emerson Silas Dória36 Pacotes Arquitetura de um Sistema de Informação

37 Prof. Msc. Emerson Silas Dória37 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.

38 Prof. Msc. Emerson Silas Dória38 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.

39 Prof. Msc. Emerson Silas Dória39 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

40 Prof. Msc. Emerson Silas Dória40 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

41 Prof. Msc. Emerson Silas Dória41 :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. :POST 1: enterItem(upc, qty) 1: displayMessage(msg) Object Store Enter ItemEnd Sale UPC Make Payment Total Quantity TenderedBalance Sem Visibilidade para Janelas Patterns: Separação Modelo-Visão

42 Prof. Msc. Emerson Silas Dória42 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.

43 Prof. Msc. Emerson Silas Dória43 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

44 Prof. Msc. Emerson Silas Dória44 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

45 Prof. Msc. Emerson Silas Dória45 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 Database


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

Apresentações semelhantes


Anúncios Google