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

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.