APOO-4b

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Click to Edit Master Title Style
Click to edit Master subtitle style
*
*
Análise e Projeto Orientados a Objeto
com UML e Padrões
Parte IV
Projeto (1B)
© Nabor C. Mendonça 2001
*
*
Diagramas de Interação para o Sistema POST
Eventos de interesse :
Caso de uso Comprar Itens: entrarItem, encerrarVenda, fazerPagamento
Caso de uso Inicializar: inicializar
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — entrarItem
Criando uma nova Venda
Pelo Criador, POST cria Venda, e Venda cria uma coleção (vazia) para registrar objetos Item-de-Venda
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — entrarItem
Criando um novo Item-de-Venda
Pelo Criador, Venda cria objetos Item-de-Venda
POST passa parâmetro quantidade para Venda, que o repassa para Item-de-Venda como parâmetro da mensagem create 
Pelo criador, POST envia mensagem fazerItem-de-Venda para Venda, que então cria um novo Item-de-Venda e o adiciona à sua coleção de objetos Item-de-Venda
Encontrando uma Especificação-Produto
Pelo Especialista, Catálogo-Produto faz a busca pela Especificação-Produto baseado em casamento de UPCs
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — entrarItem
Visibilidade para Catálogo-Produto
Catálogo-Produto é visível para POST pois ambas 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 Catálogo-Produto
Buscando Especificação-Produto no BD
Persistência ignorada nesse estágio (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 Separação Modelo-Visão)
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — entrarItem
Diagrama de colaboração parcial
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — encerrarVenda
Definindo atributo Venda.completada
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — encerrarVenda
Calculando total da venda
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — fazerPagamento
Criando Pagamento
Pelo Especialista, POST e Venda podem criar um Pagamento
Considerando também Alta Coesão e Baixo Acoplamento, Venda é a melhor escolha 
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — fazerPagamento
Registrando a Venda
Pelo Especialista, Loja adiciona a Venda à coleção (log) de vendas completadas
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — fazerPagamento
Calculando troco
Pelo Especialista, Venda e Pagamento podem calcular troco
Considerando Baixo Acoplamento, Venda é a melhor escolha
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — inicializar
Criar por último, após todas as outras operações terem sido consideradas
Instancia objeto de domínio inicial, enviando-lhe uma mensagem create 
Objeto inicial pode ou não tomar conta da execução
Em aplicações interativas, controle da execução normalmente fica com a camada de Apresentação
Se objeto inicial toma conta da execução, uma mensagem run (ou equivalente) pode ser enviada num segundo diagrama de colaboração 
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — inicializar
Candidatos para objeto de domínio inicial:
Uma classe representando o sistema como um todo
Ex.: POST
Uma classe representado o negócio ou organização como um todo
Ex.: Loja (melhor — uma Loja pode conter vários POSTs)
Instâncias de objetos persistentes
Se poucas, criar de uma vez, durante inicialização
Se muitas, criar sob demanda, conforme são requisitadas
© Nabor C. Mendonça 2001
*
*
Diagrama de Interação — inicializar
Diagrama de colaboração parcial
© Nabor C. Mendonça 2001
*
*
Conectando as Camadas de Apresentação e Lógica da Aplicação
© Nabor C. Mendonça 2001
*
*
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 para 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 objeto local de um método de A
Visibilidade global — B é de algum modo visível globalmente
© Nabor C. Mendonça 2001
*
*
Visibilidade de Atributo
Existe de A para B quando B é um atributo de A
Permanente — persiste enquanto A e B existirem 
© Nabor C. Mendonça 2001
*
*
Visibilidade de 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 de A (permanente se B é atribuído a um atributo de A)
© Nabor C. Mendonça 2001
*
*
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 de A (permanente se B é atribuído a um atributo de A)
Duas maneiras comuns de alcançar:
1. Criar nova instância e atribuir para variável local
2. Atribuir objeto de retorno de um método para variável local
© Nabor C. Mendonça 2001
*
*
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 não recomendada) de atingir é atribuir nova instância a uma variável global
Alternativa recomenda:
Padrão Singleton (GoF)
© Nabor C. Mendonça 2001
*
*
Notação de Visibilidade na UML
Uso opcional de “estereótipos” específicos
© Nabor C. Mendonça 2001
*
*
Definindo Diagramas de Classe
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
 diag. interação
b. ordem variada
Sinc.
Artefatos
Análise
Projeto
Teste
Refin.
Plano
Impl.
Um Ciclo de Desenvolvimento 
© Nabor C. Mendonça 2001
*
*
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)
© Nabor C. Mendonça 2001
*
*
Diagramas de Classe
Diagrama parcial para as classes POST e Venda no sistema POST:
© Nabor C. Mendonça 2001
*
*
Como Fazer um Diagrama de Classe
Regras úteis:
1. Identificar todas as classes participando na solução proposta pelos diagramas de interação.
2. Desenhe as classes num diagrama de classe.
3. Inclua os atributos identificados no modelo conceitual.
4. Adicione métodos tal como identificados nos diagramas de interação.
5. Adicione informação sobre o tipo dos atributos e métodos.
6. Adicione as associações necessária para permitir a visibilidade de atributos requisitada.
© Nabor C. Mendonça 2001
*
*
Como Fazer um Diagrama de Classe
Regras úteis (cont.):
7. Adicione setas de navegabilidade para indicar a direção da visibilidade de atributos.
8. Adicione relacionamentos de dependência para indicar outros tipos de visibilidade.
© Nabor C. Mendonça 2001
*
*
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
© Nabor C. Mendonça 2001
*
*
Criando Diagramas de Classe para o Sistema POST
Identificando classes e atributos
© Nabor C. Mendonça 2001
*
*
Criando Diagramas de Classe para o Sistema POST
Adicionando nomes de métodos
© Nabor C. Mendonça 2001
*
*
Criando Diagramas de Classe para o Sistema POST
Métodos create
Métodos de instanciação (construtores) específicos
para cada linguagem de programação
Normalmente omitidos no diagrama de classe
Métodos de acesso
get e set de atributos
Omitidos no diagrama para reduzir ruído (2N métodos desinteressantes para cada N atributos)
Métodos de coleção (multiobjects)
Parte da definição da coleção (classes de biblioteca do tipo container: Vetor, Hashtable, etc.)
Omitidos no diagrama para reduzir ruído
© Nabor C. Mendonça 2001
*
*
Criando Diagramas de Classe para o Sistema POST
Adicionando informação sobre o tipo dos atributos
Opcional
Grau de detalhe dependente da audiência
© Nabor C. Mendonça 2001
*
*
Criando Diagramas de Classe para o Sistema POST
Adicionando associações, navegabilidade e dependências
© Nabor C. Mendonça 2001
*
*
Especificação Detalhada de Membros
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
© Nabor C. Mendonça 2001
*
*
Projetando a Arquitetura do Sistema
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
 diag. interação
b. ordem variada
Sinc.
Artefatos
Análise
Projeto
Teste
Refin.
Plano
Impl.
Um Ciclo de Desenvolvimento 
© Nabor C. Mendonça 2001
*
*
Arquitetura Clássica em Três Camadas
© Nabor C. Mendonça 2001
*
*
Arquitetura Multi-camadas
Decomposição da camada de Lógica da Aplicação:
Objetos de domínio (conceitos)
Objetos de serviço (persistência, comunicação, segurança, etc.)
© Nabor C. Mendonça 2001
*
*
Vantagens da Arquitetura Multi-camadas
Implantação em várias configurações
Isolamento da lógica da aplicação em componentes separados
Distribuição através de diferentes computadores e/ou processos 
Alocação de desenvolvedores para camadas específicas
© Nabor C. Mendonça 2001
*
*
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:
© Nabor C. Mendonça 2001
*
*
Pacotes na Arquitetura de um Sistema de Informação
© Nabor C. Mendonça 2001
*
*
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.
© Nabor C. Mendonça 2001
*
*
Camadas e Partições
Uma arquitetura multi-camadas pode ser composta por divisões verticais (“camadas”) e horizontais (“partições”)
Partições decompõem uma camada em subsistemas relativamente independentes
© Nabor C. Mendonça 2001
*
*
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 das classes representando um serviço particular.
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.
© Nabor C. Mendonça 2001
*
*
Interface para Pacotes de Serviço — O Padrão 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
© Nabor C. Mendonça 2001
*
*
Sem Visibilidade para Janelas — O Padrão Separação Modelo-Visão
Objetos do modelo (domínio) não devem ter conhecimento sobre ou estar diretamente acoplados a objetos da visão (apresentação)
Classes de domínio encapsulam qualquer informação e comportamento relacionados à lógica da aplicação
Classes de apresentação responsáveis apenas por operações de entrada/saída
© Nabor C. Mendonça 2001
*
*
Sem Visibilidade para Janelas — O Padrão Separação Modelo-Visão
© Nabor C. Mendonça 2001
*
*
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
© Nabor C. Mendonça 2001
*
*
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
© Nabor C. Mendonça 2001
*
*
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
© Nabor C. Mendonça 2001
*
*
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
© Nabor C. Mendonça 2001