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

Apresentação em tema: "O.O.H.D.M. Modelagem Conceitual"— Transcrição da apresentação:

1 O.O.H.D.M. Modelagem Conceitual
Professor Andre Moura

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
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
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 Fontes Bibliográficas
SCHWABE, Daniel. Modelagem Conceitual. PUC-RJ, 1998.