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

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

© Nabor C. Mendonça 2001 1 Análise Orientada a Objeto com a metodologia (R)UP + UML Modelo Conceitual (ou de Domínio), Diagrama de Seqüência, Contrato.

Apresentações semelhantes


Apresentação em tema: "© Nabor C. Mendonça 2001 1 Análise Orientada a Objeto com a metodologia (R)UP + UML Modelo Conceitual (ou de Domínio), Diagrama de Seqüência, Contrato."— Transcrição da apresentação:

1 © Nabor C. Mendonça Análise Orientada a Objeto com a metodologia (R)UP + UML Modelo Conceitual (ou de Domínio), Diagrama de Seqüência, Contrato de Operação

2 © Nabor C. Mendonça Construindo um Modelo Conceitual a. se ainda não feito b. contínuo c. opcional 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 4. Refinar Glossário b 6. Definir Contrat. de Operação 1. Definir Casos de Uso Essenciais a 5. Definir Diag. Seq. 7. Definir Diag. Estado c Notas Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Um Ciclo de Desenvolvimento

3 © Nabor C. Mendonça Modelo Conceitual n Artefato mais importante da AOO n Representa conceitos relevantes (do ponto de vista do modelador) do domínio do problema n Na UML, ilustrado com diagramas de estruturas estáticas contendo: – Conceitos – Associações entre conceitos – Atributos de conceitos

4 © Nabor C. Mendonça Modelo Conceitual para o Sistema TV n Diagrama parcial

5 © Nabor C. Mendonça n Idéias, coisas, ou objetos do mundo real n Não representam componentes de software! Conceitos LojaTV Venda data hora BDdeVendas evitar Venda data hora imprimir() evitar Artefato de software; não faz parte do modelo conceitual Classe de software; não faz parte do modelo conceitual

6 © Nabor C. Mendonça Caso de Uso e Modelo de Domínio

7 © Nabor C. Mendonça Identificando Conceitos n Regras úteis: – É melhor pecar por excesso do que por parcimônia – Não exclua conceitos simplesmente porque os requisitos não indicam a necessidade de guardar informações sobre eles (comum em projeto de BD) – Comece fazendo uma lista de conceitos candidatos a partir dos casos de uso Considere os substantivos e frases nominais nas descrições textuais do domínio do problema como possíveis candidatos a conceitos ou atributos

8 © Nabor C. Mendonça Conceitos Típicos Categoria Especificação, projeto, ou descrição de coisas Especificação de produto Descrição de vôo Objeto físico ou tangívelTerminal de ponto-de-venda Avião LugaresLoja Aeroporto TransaçõesVenda, Pagamento Reserva Exemplos Itens de transaçãoItens de venda Parcelas de pagamento Container de coisasLoja Avião Papéis de pessoasOperador Piloto

9 © Nabor C. Mendonça Conceitos Típicos Coisas em um containerItem Passageiro Sistemas externosServiço de crédito Controle de tráfego aéreo Nomes abstratosFome Aracnofobia EventosVenda, Assalto, Reunião Vôo, Decolagem OrganizaçõesDepartamento de vendas Companhia aérea Regras e políticasPolítica de devolução Política de cancelamento CategoriaExemplos

10 © Nabor C. Mendonça Conceitos Típicos CatálogosCatálogo de produtos Catálogo de peças Registros de finança, trabalho, contrato, questões legais Recibo, Contrato de trabalho Registro de manutenção Manuais, livrosManual do empregado Manual de reparos Instrumentos e serviços financeirosLinha de crédito Ações CategoriaExemplos

11 © Nabor C. Mendonça Identificando Conceitos e Atributos em Casos de Uso Ação do Ator Resposta do Sistema 1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar. 2. O Operador registra o identi- ficador de cada item. Se há mais de um do mesmo item, o Operador também pode informar a quantidade. 3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda- mento. Mostra a descrição e o preço do item corrente.

12 © Nabor C. Mendonça Conceitos Candidatos para o Sistema TV n Conceitos restritos ao caso de uso Processar Venda - Versão 1

13 © Nabor C. Mendonça Conceitos de Relatório n Não incluir no modelo conceitual quando – Toda informação contida no relatório é derivada de outras fontes n Incluir no modelo conceitual quando – Relatório tem um papel especial em termos das regras de negócio Ex.: Recibo de venda dá direito à devolução dos itens comprados n Incluir Recibo no modelo conceitual para o sistema TV? – Sim, mas apenas no ciclo de desenvolvimento que trata do caso de uso Devolver Itens

14 © Nabor C. Mendonça Criando um Modelo Conceitual n Passos sugeridos 1. Liste os conceitos candidatos encontrados nos casos de usos 2. Represente-os em um modelo conceitual Retângulos 3. Adicione os relacionamentos entre os conceitos Linhas e multiplicidade 4. Adicione os atributos dos conceitos Diferença entre Conceito e Atributo?

15 © Nabor C. Mendonça Conceito e Atributo de Conceito Vôo Aeroporto nome Vôo destino ou... ? Note que, em um sistema de vôos, aeroporto é um conceito relevante, logo deve ser modelado como tal, e não como um atributo (destino). Outras razões: - que vôos partem (chegam) de (a) um aeroporto? - quais os aeroportos de origem e destino de um vôo? parte_de chega_a 1..*

16 © Nabor C. Mendonça n A especificação ou descrição de um objeto deve ser representada como um conceito em separado – evita perda de informação quando o objeto é removido – reduz informações redundantes ou duplicadas n Muito comum no domínio de produtos e vendas Ex.: Conceitos de Especificação ou Descrição Item descrição preço número serial UPC Especificação-Produto Item Número serial Descreve 1 * descrição preço UPC pior melhor

17 © Nabor C. Mendonça Conceitos e a Terminologia da UML n UML usa o termo genérico classe para denotar tanto entidades (conceitos) do domínio da aplicação quanto classes na POO – Uma classe na POO é chamada mais especificamente de classe de implementação n Os termos tipo e interface são usados para denotar especificações de classes de implementação n No âmbito do curso, o termo conceito denota entidades do mundo real (análise), e classe denota componentes de software e suas especificações (design)

18 © Nabor C. Mendonça Relacionamentos e Associações n Relacionamento entre conceitos indica uma conexão significativa e interessante entre os conceitos n No nível de instância de conceito, diz-se associação entre instâncias – Descritos na UML como associações estruturais entre objetos de tipos diferentes n Um relacionamento precisa ser preservado durante algum tempo – Duração de mili-segundos ou anos, dependendo do contexto

19 © Nabor C. Mendonça Relacionamentos n Notação na UML – Uma linha entre dois conceitos mais um nome – Inerentemente bidirecional – Pode conter um seta de direção de leitura – Pontas podem conter expressões de multiplicidade

20 © Nabor C. Mendonça Relacionamentos Típicos Categoria A é uma parte lógica de BItem de Venda - Venda Escala - Vôo A é uma parte física de BGaveta - TV Asa - Avião A está fisicamente contido em BTV - Loja Passageiro - Avião A está logicamente contido em BDescrição-Item - Catálogo Vôo - Roteiro de Viagem Exemplos A é uma descrição de BDescrição-Item - Item Descrição-Vôo - Vôo A é conhecido/registrado/repor- tado/captado em B Venda - TV Reserva - Terminal de Reserva A é um item de uma transação B ou um ítem de um relatório B Item de Venda - Venda Opção de Reserva - Reserva

21 © Nabor C. Mendonça Relacionamentos Típicos Categoria A é uma sub-unidade organizacional de B Departamento - Loja Manutenção - Companhia Aérea A é um membro de BOperador - Loja Piloto - Companhia Aérea A usa ou gerencia BOperador - TV Piloto - Avião A se comunica com BCliente - Operador Agente de Reserva - Passageiro Exemplos A está relacionado com uma transação B Cliente - Pagamento Passageiro - Bilhete A é propriedade de B TV - Loja Avião - Companhia Aérea A é uma transação relacionada com outra transação B Pagamento - Venda Reserva - Cancelamento

22 © Nabor C. Mendonça Identificando Relacionamentos nos Casos de Uso n Regras úteis: – Focar nos relacionamentos cujo conhecimento deve ser preservado – Extrair expressões verbais dos casos de uso – Relacionamentos demais tendem a confundir um modelo conceitual ao invés de iluminá-lo

23 © Nabor C. Mendonça Multiplicidade de Relacionamentos

24 © Nabor C. Mendonça n O valor da multiplicidade depende do contexto – Ex.: Pessoa Trabalha-para Empresa Expressões de Multiplicidade

25 © Nabor C. Mendonça Adicionando Relacionamentos ao Modelo Conceitual do Sistema TV n Relacionamentos fundamentais – Venda Processada-em TV Para conhecer a venda corrente, calcular total e imprimir recibo – Venda Paga-por Cliente Para saber se a venda foi paga, calcular troco, e imprimir recibo – Catálogo-Produto Contém Especificação-Item Para obter a especificação de um item, dado um UPC

26 © Nabor C. Mendonça Aplicando a Lista de Relacionamentos Típicos Categoria A é uma parte lógica de BItem de Venda - Venda A é uma parte física de BNão Aplicável (N.A.) A está fisicamente contido em BTV - Loja Item - Loja A está logicamente contido em BEspecificação-Produto - Catálogo Catálogo - Loja Exemplos A é uma descrição de BEspecificação-Produto - Item A é conhecido/registrado/repor- tado/capturado em B Venda (corrente) - TV Venda (completada) - Loja A é um item de uma transação ou relatório B Item de Venda - Venda

27 © Nabor C. Mendonça Aplicando a Lista de Associações Típicas Categoria A é uma sub-unidade organizacional de B N.A. A é um membro de BOperador - Loja A usa ou gerencia BOperador - TV Gerente - TV A se comunica com BCliente - Operador Exemplos A está relacionado com uma transação B Cliente - Pagamento Operador - Pagamento A é propriedade de B TV - Loja A é uma transação relacionada com outra transação B Pagamento - Venda

28 © Nabor C. Mendonça Conceitos e Relacionamentos Candidatos para o Sistema TV

29 © Nabor C. Mendonça Eliminando Relacionamentos Redundantes ou Desnecessários n Relacionamentos cujo conhecimento não precisam ser preservados podem ser removidos do modelo Relacionamento Operador Registra-vendas-em TVConhecimento não exigido nos requisitos. Venda Iniciada-por OperadorConhecimento não exigido nos requisitos; derivável da associação Operador Registra-vendas-em TV TV Inicializado-por GerenteConhecimento não exigido nos requisitos. Venda Iniciada-por ClienteConhecimento não exigido nos requisitos. Comentários Loja Armazena ItemConhecimento não exigido nos requisitos. Item de Venda Registra-venda-de ItemConhecimento não exigido nos requisitos.

30 © Nabor C. Mendonça Preservando Relacionamentos de Compreensão n Preservar apenas relacionamentos de conhecimento pode resultar num modelo que não transmite um completo entendimento do domínio – Ex.: Venda Iniciada-por Cliente Remoção deixa de fora um aspecto importante do domínio o fato de que um cliente gera uma venda n Modelo conceitual é um artefato de comunicação! n Regra geral: – Enfatizar relacionamentos de conhecimento, mas preservar relacionamementos que enriquecem o entendimento do domínio

31 © Nabor C. Mendonça Atributos n Atributos descrevem conceitos do domínio n Definidos para conceitos cujos requisitos (casos de uso) sugerem a necessidade de preservar algum tipo de informação – Ex.: atributos data e hora para o conceito Venda n Notação na UML

32 © Nabor C. Mendonça Adicionando Atributos aos Conceitos Candidatos do Sistema TV Conceito Especificação-ProdutodescriçãoPara mostrar na tela e imprimir no recibo. UCPPara localizar especificação do item. preçoPara calcular o total da venda. PagamentoquantiaPara determinar se pagamento é suficiente e calcular troco. Vendadata, horaPara imprimir no recibo e registrar no log de vendas. Item de VendaquantidadePara registrar a quantidade digitada quando há mais de um do mesmo item. Atributos e justificativa Lojanome, endereçoPara imprimir no recibo.

33 © Nabor C. Mendonça Atributo Derivado n Um atributo derivado é um atributo cujo valor pode ser deduzido a partir de outras informações – Ex.: quantidade em Item de Vendapode ser deduzido a partir da multiplicidade da associação entre Item de Venda e Item n Na UML, indicado com o símbolo / SalesLineItem /quantity Item Records-sale-of * derived attribute from the multiplicity value

34 © Nabor C. Mendonça Modelo Conceitual Inicial do Sistema TV

35 © Nabor C. Mendonça Registrando Termos no Glossário n Um glossário ou dicionário de modelo é um documento que define os termos (ou vocabulário) do domínio – Similar a um dicionário de dados usado na modelagem de BD n Fundamental para garantir uma comunicação consistente e um entendimento compartilhado entre usuários e desenvolvedores n Também pode ser usado para registrar restrições de domínio e regras de negócio (não explorado no curso)

36 © Nabor C. Mendonça Glossário Parcial para o Sistema TV Categoria atributoUma descrição sucinta de um item de venda. caso de usoDescrição do processo de um cliente comprando itens numa loja. tipoUm item à venda numa loja. tipoUm pagamento em dinheiro. Comentário atributoO preço de um item de venda. Termo Especificação-Produto.descrição :Texto Comprar Itens Item Pagamento Especificação-Produto.preço :Quantidade atributoA quantidade de um tipo particular de item comprado. tipoUma transação de venda. tipoUm item particular comprado como parte de uma venda. Item de Venda.quantidade :Inteiro Venda Item de Venda

37 © Nabor C. Mendonça Definindo Diagramas de Seqüência a. se ainda não feito b. contínuo c. opcional 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 4. Refinar Glossário b 6. Definir Contrat. de Operação 1. Definir Casos de Uso Essenciais a 5. Definir Diag. Seq. 7. Definir Diag. Estado c Notas Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Um Ciclo de Desenvolvimento

38 © Nabor C. Mendonça Diagramas de Seqüência n Um diagrama de seqüência ilustra a ordem das interações dos atores externos com o sistema (representado como uma caixa-preta) e os eventos que eles geram

39 © Nabor C. Mendonça Eventos e Operações n Um evento de sistema é um evento externo de entrada gerado por um ator do sistema – Inicia uma operação de resposta de mesmo nome n Uma operação de sistema é uma operação do sistema que executa em resposta a um evento de sistema

40 © Nabor C. Mendonça n O conjunto necessário de operações de sistema é determinado através da identificação dos eventos de sistema – Exemplos de operações para o sistema POST: entrarItem(UPC, quantidade) encerrarVenda() fazerPagamento(quantia) n Na UML, representado como operações de um tipo denominado Sistema: Representando Operações

41 © Nabor C. Mendonça Definindo Diagramas de Seqüência n Regras úteis: 1. Desenhar uma linha vertical representando o sistema como uma caixa-preta. 2. Identificar os atores que operam diretamente com o sistema. Desenhar uma linha vertical representando cada um desses atores. 3. A partir da descrição das seqüências típicas de eventos dos casos de uso, identificar os eventos de sistema que cada ator gera. Ilustrar os eventos no diagrama. 4. Opcionalmente, incluir o texto do caso de uso à esquerda do diagrama.

42 © Nabor C. Mendonça Definindo Diagramas de Seqüência n Diagrama de seqüência para o sistema POST com (parte do) texto do caso de uso Compra Itens - Versão 1:

43 © Nabor C. Mendonça Nomeando Eventos e Operações n Regras úteis: – Começar com um verbo – Enfatizar intenção em vez do meio físico de entrada ou componente gráfico da interface com o usuário Ex.: encerrarVenda em vez de pressionarTeclaEnter – Expressar intenção no nível mais alto de abstração Ex.: fazerPagamento em vez de entrarQuantia

44 © Nabor C. Mendonça Definindo Contratos de Operação a. se ainda não feito b. contínuo c. opcional 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 4. Refinar Glossário b 6. Definir Contrat. de Operação 1. Definir Casos de Uso Essenciais a 5. Definir Diag. Seq. 7. Definir Diag. Estado c Notas Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Um Ciclo de Desenvolvimento

45 © Nabor C. Mendonça Contratos n Um contrato é um documento que descreve os compromissos de uma operação – Pré e pós-condições de mudanças de estado – Para operações de sistema – Referências: casos de uso, funções (requisitos) – Assinatura – Descrição da operação (opcional) n Processo de definição de contratos 1. Identificar operações de sistema a partir do(s) diagrama(s) de seqüência 2. Para cada operação do diagrama de seqüência, construir um contrato

46 © Nabor C. Mendonça Contratos n Exemplo para operação entrarItem (Id, quant) Pré-condições: Objeto :Venda existe associado a um :TV, segundo o relacionamento Registrada-por. O objeto foi criado pela operação iniciarVenda(). n Um : Item-de-Venda foi criado e associado com :Venda, segundo Venda Contém Item-de-Venda n :Item-de-Venda.quantidade := quant n O Item-de-Venda foi associado a :Especificação-Produto e :Item, segundo os relacionamentos Descrito-por e Registra-venda-de, respectivamente. Pós-condições:

47 © Nabor C. Mendonça Contratos e Outros Artefatos CashierSystem enterItem (upc, quantity) endSale() makePayment (amount) USE CASE: BUYING ITEMS Typical Course Of Events 1. This use case begins... Use CaseSystem Sequence Diagram Operation: enterItem Postconditions: 1. If a new sale, a new Sale has been created... Operation: endSale Postconditions: Contracts System endSale() enterItem() makePayment() System Operations

48 © Nabor C. Mendonça Contratos para o Sistema TV n Exercício: faça os contratos das demais operações do sistema TV

49 © Nabor C. Mendonça Utilidade dos Contratos n A principal finalidade dos contratos é validar o modelo conceitual – Faltando entidade? Faltando atributo? Atributo inútil? – Faltando relacionamento? – Entidade inútil? n Em conseqüência, o modelo conceitual pode ser modificado / refinado n Exemplo: somente ao fazer o contrato TerminarVenda(), descobriu-se a necessidade de um novo atributo booleano Terminou, para o sistema TV


Carregar ppt "© Nabor C. Mendonça 2001 1 Análise Orientada a Objeto com a metodologia (R)UP + UML Modelo Conceitual (ou de Domínio), Diagrama de Seqüência, Contrato."

Apresentações semelhantes


Anúncios Google