1 / 40

O.O.H.D.M . Modelagem Conceitual

O.O.H.D.M . Modelagem Conceitual. Professor Andre Moura moura.professor@gmail.com. Modelagem Conceitual. Etapa do método OOHDM onde faz-se uma análise do domínio da aplicação .

trapper
Download Presentation

O.O.H.D.M . Modelagem Conceitual

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. O.O.H.D.M.ModelagemConceitual Professor Andre Moura moura.professor@gmail.com

  2. Modelagem Conceitual • Etapa do método OOHDM onde faz-se uma análise do domínio da aplicação. • Constrói-se um Esquema de Classes Conceituais que represente os objetos e relacionamentos existentes no domínio da aplicação. • Aqui preocupa-se com a estrutura conceitual da informação, deixando de lado a aparência e as formas de uso. • A construção de um esquema Conceitual bem elaborado poderá implicar em seu reuso, quando dentro do mesmo domínio.

  3. Modelagem Conceitual • As primitivas tratadas nesta etapa são: • Objetos • atributos; tipos e perspectivas • Classes • Agregação • Generalização/ Especialização • Relações • Subsistemas • Esquemas de Classes e de Instâncias

  4. Revisão de Orientação a Objetos • Sistemas convencionais baseiam-se no entendimento de um conjunto de programas que executam processos sobre dados. A modelagem por objetos vê isso como um conjunto de objetos que interagem entre si.

  5. Revisão de Orientação a Objetos • Objeto: • Algo do mundo real abstraído, que é identificável e que ocupa espaço físico e lógico. • Algo com limites nítidos em relação ao domínio. • Possuí três características: • identidade: seu nome para distinguí-lo • estado: seus atributos internos. Só podem ser modificados / acessados por seus métodos • métodos: suas ações e reações • É a instanciação de uma classe.

  6. Revisão de Orientação a Objetos • Representação do objeto José. • José pertence a classe Pessoa.

  7. Revisão de Orientação a Objetos • Classe: • Conjunto de objetos com atributos semelhantes, mesmos comportamentos e relacionamentos e mesma semântica (mesma representação).

  8. Revisão de Orientação a Objetos • Atributo: • É um valor de dado armazenado por um objeto • Possui um Nome, um valor e um tipo • Método: • Processos que manipulam os dados contidos nos objetos de uma classe. • Definem o comportamento dinâmico do objeto. • São os serviços que podem ser solicitados a um objeto.

  9. Revisão de Orientação a Objetos • Associação: Expressa o relacionamento entre as classes.

  10. Revisão de Orientação a Objetos • Cardinalidade / Multiplicidade:

  11. Revisão de Orientação a Objetos • Agregação: • Denota um relacionamento do tipo “é-parte-de” ou “todo-parte”.

  12. Revisão de Orientação a Objetos • Herança: • Mecanismo de reuso da OO o qual nos permite herdar propriedades de classes já existente.

  13. Revisão de Orientação a Objetos • Generalização / Especialização: • Denota relacionamento do tipo “é um tipo de”, onde uma superclasse é especializada por subclasses.

  14. Modelagem Conceitual

  15. Classes • Nome da classe descrito em Negrito, centralizado e a primeira letra em maiúsculo. Obrigatório. • Forma mais simples de se representar uma classe é um retângulo com seu nome centralizado. • A especificação dos métodos é opcional, pois pode não haver métodos na classe.

  16. Classes • Atributos: • Notação: visibilidade nome: tipo = valor-default {propriedade} • Visibilidade: indica se o atributo é público ou privado. Se for público não descreve-se a visibilidade. Se for privado descreve o sinal de menos “-” em frente ao atributo privado. Visível ou não-visível ao usuário. • Nome: é o identificador do atributo. Sempre descrito com a primeira letra em minúsculo. • Tipo: identifica a aparência do atributo, por isso denota-se o tipo como perspectiva do atributo. • A perspectiva de um atributo pode ser: texto, imagem, som, inteiro, real, etc. • Um atributo pode ter múltiplas perspectivas. Neste caso esboça-se elas entre colchetes “[...]”. A indicação da perspectiva default é obrigatória através do sinal “+”. Somente a perspectiva default é obrigatória de instanciação nos objetos, as demais são opcionais. • Valor-default: seu uso é opcional e serve para expressar o valor de um atributo quando esse é instanciado por um objeto. • Propriedades: serve para relatar informações extras a cerca de um atributo. É opcional. Quando usado, as informações ficam entre chaves “{...}”. • Exemplos: • descrição: [texto+, imagem, som] descrição: [texto+, foto:imagem, som] nome: string código: inteiro • -salário: real=0

  17. Classes • Operações / métodos: • Em websites estáticos a especificação das operações / métodos são desnecessárias. Já para websites dinâmicos é necessário. • Notação: visibilidade nome (lista-parâmetro): expressão-resultado {propriedade} • Visibilidade: indica se o atributo é público ou privado, visível ou não-visível. • Nome: é o identificador do método. Sempre descrito com a primeira letra em minúsculo. • Lista de parâmetros: são os parâmetros formais que devem ser passados a operação. Sua notação é a seguinte: nome: tipo=valor-default • Nome: nome do parâmetro Tipo: é o tipo de dado do parâmetro. Valor-default: é opcional, neste caso exclui-se o sinal d “=“. Quando usado é obrigatório o “=“. • Expressão resultado: Determina o valor de retorno de uma operação. Quando não há, omite-se a expressão. • Propriedades: idem a atributo. • Exemplos: • exibirInformações() • -calcularSalário() • -calcularAbono (abono:real=(15,50)) • verificarCPF (cpfAluno): boolean {Se voltar verdadeiro cpf validou, senão erro no cpf}

  18. Classes • Construindo uma Classe

  19. Classes • Construindo uma Classe

  20. Relacionamentos • Conhecido também como associações. • Usado para expressar o relacionamento entre classes. • As associações podem ser: • Unária: (relação de uma classe consigo mesma) • Binária: (relação entre duas classes) • N-ária ou Ternária: (relação entre três ou mais classes) • A identificação do relacionamento é feita junto a linha do relacionamento e um triângulo preenchido em preto, ao lado do nome do relacionamento, indica a direção da leitura do relacionamento.

  21. Relacionamentos

  22. Cardinalidade • 0..N Cardinalidade de 0 ou 1 (opcional) • 1 Exatamente 1 • 7 Exatamente 7 • 0..* Cardinalidade de 0 a infinito • * Cardinalidade de 0 a infinito • 1..* No mínimo 1, máximo infinito • 1..6 No mínimo 1, máximo 6

  23. Classe de relacionamento • Ocorre quando um relacionamento apresentar a necessidade de ter atributos ou comportamentos próprios.

  24. Mecanismos de Abstração • Agregação • É um relacionamento do tipo “é-parte-de”. Representado por um losango vazio ao lado da classe que agrega. • A cardinalidade da classe que agrega é sempre 1, do outro lado segue as normas.

  25. Mecanismos de Abstração • Composição • É um relacionamento do tipo “é-parte-de” só que neste caso os objetos da classe agregada só existem se a superclasse existir. Representado por um losango cheio ao lado da classe que agrega. • A cardinalidade é idêntica a Agregação.

  26. Mecanismos de Abstração • Generalização / Especialização • É um relacionamento do tipo “é-um-tipo-de”. Classes especializadas (subclasses) herdam todas as características de uma classe generalizada (superclasse).

  27. Mecanismos de Abstração • Generalização / Especialização • Herança • Atributos e métodos são herdados de uma superclasse. • Se uma subclasse possuir um atributo com o mesmo nome da superclasse, as novas perspectivas de atributos serão adicionadas às herdadas. • Se atributos tiverem o mesmo nome e perspectivas default na superclasse e na subclasse, as perspectivas herdadas passam a ser opcionais.

  28. Objeto • É a instância de uma classe. • Possui as mesmas características básicas da classe • Representado de forma semelhante a classe. Nome é sublinhado, em minúsculo e opcional. É composto do: nome-do-objeto:nome-da-classe • Os atributos e métodos são representados com suas instanciações.

  29. Diagrama de Objeto • É a representação no diagrama de classes, de um objeto excepcional, ou seja, um objeto diferente de todos os outros, que não se enquadra em nenhuma das classes e que ocorre apenas uma vez, tornando desnecessário a criação de uma classe para apenas um objeto.

  30. Esquema Conceitual de Classes • É o resultado dessa etapa do OOHDM.

  31. Esquema Conceitual a partir dos UIDs • Definir classes de objetos • Para cada UID, definir uma classe para cada estrutura

  32. Esquema Conceitual a partir dos UIDs • Definir Atributos • Para cada item de dado, retornado pela aplicação ou inserido pelo usuário, definir um atributo de acordo com as seguintes regras: • Se o valor de um atributo A só é possível de ser obtido a partir da instanciação de apenas uma classe X, então esse item de dado é atributo desta classe. • Um item de dado será atributo de uma associação de classes, se for possível obter seu valor a partir de uma classe X e Y. • Um item de dado será atributo de uma nova classe, que deverá ser criada, se o seu atributo não depender de nenhuma classe existente ou da combinação das mesmas.

  33. Esquema Conceitual a partir dos UIDs • Definir Atributos

  34. Esquema Conceitual a partir dos UIDs • Definir Relacionamentos • Para cada atributo A, cujo seu item de dado apareça em uma estrutura que não corresponde a da sua classe verificar: • Se existe outro atributo B, cujo seu item de dado está na mesma estrutura do atributo A, porém pertença a outra classe diferente do atributo A; • É possível obter as informações da uma única instância da classe do atributo A a partir de uma instância da classe do atributo B. • Caso isso ocorra, criar um relacionamento entre as classes do atributo A e B.

  35. Esquema Conceitual a partir dos UIDs • Definir Relacionamentos • Cardinalidade • Se a classe do atributo B for a classe de sua estrutura , então: • Se o item de dado do atributo A é um item de dado simples, então a cardinalidade máx da classe que contém o atributo A é 1. • Se o item de dado do atributo A for um conjunto, então a cardinalidade máx da classe que contém o atributo A é N. • Se o item de dado do atributo A for opcional, então a cardinalidade mín da classe que contém o atributo A é 0.

  36. Esquema Conceitual a partir dos UIDs • Definir Relacionamentos

  37. Esquema Conceitual a partir dos UIDs • Definir Operações / Métodos • Em cada UID, para cada opção que aparece junto a uma transição de estado, verificar se uma operação / método deva ser criado para uma das classes correspondentes ao estado de interação.

  38. Esquema Conceitual a partir dos UIDs

  39. Esquema Conceitual a partir dos UIDs • Ajustes Finais e Validação • Identificar Generalizações e Agregações • Definir cardinalidades ainda não definidas • Eliminar ciclos redundantes de relacionamentos • Validar as operações / métodos • Verificar se faltou atributos para as classes • Verificar se uma classe fora modelada como atributo de outra classe. Neste caso a classe deverá ser excluída.

  40. FontesBibliográficas • SCHWABE, Daniel. Modelagem Conceitual. PUC-RJ, 1998.

More Related