Análise Orientada a Objeto com a metodologia (R)UP + UML - ppt carregar
PublicouLuana Navarra Alterado mais de 4 anos atrás
Apresentação em tema: "Análise Orientada a Objeto com a metodologia (R)UP + UML"— Transcrição da apresentação:
1 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 © Nabor C. Mendonça 2001
4 Modelo Conceitual para o Sistema TV
Não representam componentes de software! Loja TV Venda data hora BDdeVendas Artefato de software; não faz parte do modelo conceitual evitar Venda Classe de software; não faz parte do modelo conceitual evitar data hora imprimir()
6 Caso de Uso e Modelo de Domínio
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 Conceitos Típicos Categoria Exemplos Objeto físico ou tangível
9 Conceitos Típicos Categoria Exemplos Coisas em um container Item
10 Conceitos Típicos Categoria Exemplos Catálogos Catálogo de produtos
11 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 Conceitos Candidatos para o Sistema TV
Conceitos restritos ao caso de uso Processar Venda - Versão 1
13 Conceitos de Relatório
Não incluir no modelo conceitual quando Toda informação contida no relatório é derivada de outras fontes 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 Incluir Recibo no modelo conceitual para o sistema TV? Sim, mas apenas no ciclo de desenvolvimento que trata do caso de uso Devolver Itens
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 Conceito e Atributo de Conceito
parte_de Vôo Vôo 1..* Aeroporto ou... ? destino nome 1..* chega_a 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?
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 Muito comum no domínio de produtos e vendas Ex.: 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
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" Os termos "tipo" e "interface" são usados para denotar especificações de classes de implementação 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 Relacionamentos e Associações
Relacionamento entre conceitos indica uma conexão significativa e interessante entre os conceitos 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" Um relacionamento precisa ser preservado durante algum tempo Duração de mili-segundos ou anos, dependendo do contexto
19 Relacionamentos 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 Relacionamentos Típicos
Categoria Exemplos A é uma parte física de B Gaveta - TV Asa - Avião A é uma parte lógica de B Item de Venda - Venda Escala - Vôo A está fisicamente contido em B TV - Loja Passageiro - Avião A está logicamente contido em B Descrição-Item - Catálogo Vôo - Roteiro de Viagem A é uma descrição de B Descrição-Item - Item Descrição-Vôo - Vôo 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 A é conhecido/registrado/repor-tado/captado em B Venda - TV Reserva - Terminal de Reserva
21 Relacionamentos Típicos
Categoria Exemplos A é um membro de B Operador - Loja Piloto - Companhia Aérea A é uma sub-unidade organizacional de B Departamento - Loja Manutenção - Companhia Aérea A usa ou gerencia B Operador - TV Piloto - Avião A se comunica com B Cliente - Operador Agente de Reserva - Passageiro A está relacionado com uma transação B Cliente - Pagamento Passageiro - Bilhete A é uma transação relacionada com outra transação B Pagamento - Venda Reserva - Cancelamento A é propriedade de B TV - Loja Avião - Companhia Aérea
22 Identificando Relacionamentos nos Casos de Uso
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 Multiplicidade de Relacionamentos
25 Adicionando Relacionamentos ao Modelo Conceitual do Sistema TV
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 Aplicando a Lista de Relacionamentos Típicos
Categoria Exemplos A é uma parte física de B Não Aplicável (N.A.) A é uma parte lógica de B Item de Venda - Venda A está fisicamente contido em B TV - Loja Item - Loja A está logicamente contido em B Especificação-Produto - Catálogo Catálogo - Loja A é uma descrição de B Especificação-Produto - Item A é um item de uma transação ou relatório B Item de Venda - Venda A é conhecido/registrado/repor-tado/capturado em B Venda (corrente) - TV Venda (completada) - Loja
Categoria Exemplos A é um membro de B Operador - Loja A é uma sub-unidade organizacional de B N.A. A usa ou gerencia B Operador - TV Gerente - TV A se comunica com B Cliente - Operador A está relacionado com uma transação B Cliente - Pagamento Operador - Pagamento A é uma transação relacionada com outra transação B Pagamento - Venda A é propriedade de B TV - Loja
28 Conceitos e Relacionamentos Candidatos para o Sistema TV
29 Eliminando Relacionamentos Redundantes ou Desnecessários
Relacionamentos cujo conhecimento não precisam ser preservados podem ser removidos do modelo Relacionamento Comentários Venda Iniciada-por Operador Conhecimento não exigido nos requisitos; derivável da associação Operador Registra-vendas-em TV Operador Registra-vendas-em TV Conhecimento não exigido nos requisitos. TV Inicializado-por Gerente Conhecimento não exigido nos requisitos. Venda Iniciada-por Cliente Conhecimento não exigido nos requisitos. Loja Armazena Item Conhecimento não exigido nos requisitos. Item de Venda Registra-venda-de Item Conhecimento não exigido nos requisitos.
30 Preservando Relacionamentos de Compreensão
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 Modelo conceitual é um artefato de comunicação! Regra geral: Enfatizar relacionamentos de conhecimento, mas preservar relacionamementos que enriquecem o entendimento do domínio
31 Atributos Atributos descrevem conceitos do domínio
32 Adicionando Atributos aos Conceitos Candidatos do Sistema TV
33 Atributo Derivado Um atributo "derivado" é um atributo cujo valor pode ser deduzido a partir de outras informações Ex.: quantidade em Item de Venda—pode ser deduzido a partir da multiplicidade da associação entre Item de Venda e Item Na UML, indicado com o símbolo "/" SalesLineItem /quantity Item Records-sale-of 0..1 1..* derived attribute from the multiplicity value
34 Modelo Conceitual Inicial do Sistema TV
POST Item Store address name Sale date time Payment amount Sales LineItem /quantity Cashier Customer Manager Product Catalog Specification description price UPC Stocks * Houses 1.. Used-by Contains Describes Captured-on Contained-in Described-by Records-sale-of 0..1 Started-by Paid-by Initiated-by Logs- completed 6 3 Records-sales-on 1
35 Registrando Termos no Glossário
36 Glossário Parcial para o Sistema TV
37 Definindo Diagramas de Seqüência
39 Eventos e Operações Um evento de sistema é um evento externo de entrada gerado por um ator do sistema Inicia uma operação de resposta de mesmo nome Uma operação de sistema é uma operação do sistema que executa em resposta a um evento de sistema
41 Definindo Diagramas de Seqüência
42 Definindo Diagramas de Seqüência
45 Contratos 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) 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 Contratos 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(). Pós-condições: Um :Item-de-Venda foi criado e associado com :Venda, segundo Venda Contém Item-de-Venda :Item-de-Venda .quantidade := quant O Item-de-Venda foi associado a :Especificação-Produto e :Item, segundo os relacionamentos Descrito-por e Registra-venda-de, respectivamente.
47 Contratos e Outros Artefatos
48 Contratos para o Sistema TV
Exercício: faça os contratos das demais operações do sistema TV
49 Utilidade dos Contratos
A principal finalidade dos contratos é validar o modelo conceitual Faltando entidade? Faltando atributo? Atributo inútil? Faltando relacionamento? Entidade inútil? Em conseqüência, o modelo conceitual pode ser modificado / refinado Exemplo: somente ao fazer o contrato TerminarVenda(), descobriu-se a necessidade de um novo atributo booleano Terminou, para o sistema TV