+
O.O.H.D.M.Modelagem ConceitualProfessor Andre [email protected]
+Modelagem Conceitual
Etapa do metodo OOHDM onde faz-se uma analise do dominio da aplicacao.
Constroi-se um Esquema de Classes Conceituais que represente os objetos e relacionamentos existentes no dominio da aplicacao.
Aqui preocupa-se com a estrutura conceitual da informacao, deixando de lado a aparencia e as formas de uso.
A construcao de um esquema Conceitual bem elaborado podera implicar em seu reuso, quando dentro do mesmo dominio.
+Modelagem Conceitual
As primitivas tratadas nesta etapa sao: Objetos
atributos; tipos e perspectivas Classes
Agregacao Generalizacao / Especializacao
Relacoes
Subsistemas
Esquemas de Classes e de Instancias
+Revisao de Orientacao a Objetos
Sistemas convencionais baseiam-se no entendimento de um conjunto de programas que executam processos sobre dados. A modelagem por objetos ve isso como um conjunto de objetos que interagem entre si.
+Revisao de Orientacao a Objetos
Objeto: Algo do mundo real abstraido, que e identificavel e que
ocupa espaco fisico e logico. Algo com limites nitidos em relacao ao dominio. Possui tres caracteristicas:
identidade: seu nome para distingui-lo estado: seus atributos internos. So podem ser
modificados / acessados por seus metodos metodos: suas acoes e reacoes
É a instanciacao de uma classe.
+Revisao de Orientacao a Objetos
Representacao do objeto Jose.
Jose pertence a classe Pessoa.
+Revisao de Orientacao a Objetos
Classe: Conjunto de objetos com atributos semelhantes, mesmos
comportamentos e relacionamentos e mesma semantica (mesma representacao).
+Revisao de Orientacao a Objetos
Atributo: É um valor de dado armazenado por um objeto Possui um Nome, um valor e um tipo
Metodo: Processos que manipulam os dados contidos nos objetos de
uma classe. Definem o comportamento dinamico do objeto. Sao os servicos que podem ser solicitados a um objeto.
+Revisao de Orientacao a Objetos
Associacao: Expressa o relacionamento entre as classes.
+Revisao de Orientacao a Objetos
Cardinalidade / Multiplicidade:
+Revisao de Orientacao a Objetos
Agregacao: Denota um relacionamento do tipo “e-parte-de” ou “todo-
parte”.
+Revisao de Orientacao a Objetos
Heranca: Mecanismo de reuso da OO o qual nos permite herdar
propriedades de classes ja existente.
+Revisao de Orientacao a Objetos
Generalizacao / Especializacao: Denota relacionamento do tipo “e um tipo de”, onde uma
superclasse e especializada por subclasses.
+Modelagem Conceitual
+Classes
Nome da classe descrito em Negrito, centralizado e a primeira letra em maiúsculo. Obrigatorio.
Forma mais simples de se representar uma classe e um retangulo com seu nome centralizado.
A especificacao dos metodos e opcional, pois pode nao haver metodos na classe.
+Classes
Atributos: Notacao:
visibilidade nome: tipo = valor-default {propriedade} Visibilidade: indica se o atributo e público ou privado. Se for público nao descreve-se a
visibilidade. Se for privado descreve o sinal de menos “-” em frente ao atributo privado. Visivel ou nao-visivel ao usuario.
Nome: e o identificador do atributo. Sempre descrito com a primeira letra em minúsculo. Tipo: identifica a aparencia 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 esboca-se elas entre colchetes
“[...]”. A indicacao da perspectiva default e obrigatoria atraves do sinal “+”. Somente a perspectiva default e obrigatoria de instanciacao nos objetos, as demais sao opcionais.
Valor-default: seu uso e opcional e serve para expressar o valor de um atributo quando esse e instanciado por um objeto. Propriedades: serve para relatar informacoes extras a cerca de um atributo. É opcional.
Quando usado, as informacoes ficam entre chaves “{...}”. Exemplos:
descricao: [texto+, imagem, som] descricao: [texto+, foto:imagem, som] nome: string codigo: inteiro
-salario: real=0
+Classes
Operacoes / metodos: Em websites estaticos a especificacao das operacoes / metodos sao desnecessarias. Ja para
websites dinamicos e necessario. Notacao:
visibilidade nome (lista-parâmetro): expressão-resultado {propriedade} Visibilidade: indica se o atributo e público ou privado, visivel ou nao-visivel. Nome: e o identificador do metodo. Sempre descrito com a primeira letra em minúsculo. Lista de parametros: sao os parametros formais que devem ser passados a operacao. Sua
notacao e a seguinte: nome: tipo=valor-default Nome: nome do parametro Tipo: e o tipo de dado do parametro. Valor-default: e opcional,
neste caso exclui-se o sinal d “=“. Quando usado e obrigatorio o “=“. Expressao resultado: Determina o valor de retorno de uma operacao. Quando nao ha,
omite-se a expressao. Propriedades: idem a atributo. Exemplos:
exibirInformacoes() -calcularSalario() -calcularAbono (abono:real=(15,50)) verificarCPF (cpfAluno): boolean {Se voltar verdadeiro cpf validou, senao erro no cpf}
+Classes
Construindo uma Classe
+Classes
Construindo uma Classe
+Relacionamentos
Conhecido tambem como associacoes.
Usado para expressar o relacionamento entre classes.
As associacoes podem ser: Unaria: (relacao de uma classe consigo mesma) Binaria: (relacao entre duas classes) N-aria ou Ternaria: (relacao entre tres ou mais classes)
A identificacao do relacionamento e feita junto a linha do relacionamento e um triangulo preenchido em preto, ao lado do nome do relacionamento, indica a direcao da leitura do relacionamento.
+Relacionamentos
+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 minimo 1, maximo infinito
1..6 No minimo 1, maximo 6
+Classe de relacionamento
Ocorre quando um relacionamento apresentar a necessidade de ter atributos ou comportamentos proprios.
+Mecanismos de Abstracao
Agregacao É um relacionamento do tipo “e-parte-de”. Representado
por um losango vazio ao lado da classe que agrega. A cardinalidade da classe que agrega e sempre 1, do outro
lado segue as normas.
+Mecanismos de Abstracao
Composicao
É um relacionamento do tipo “e-parte-de” so que neste caso os objetos da classe agregada so existem se a superclasse existir. Representado por um losango cheio ao lado da classe que agrega.
A cardinalidade e identica a Agregacao.
+Mecanismos de Abstracao
Generalizacao / Especializacao É um relacionamento do tipo “e-um-tipo-de”. Classes
especializadas (subclasses) herdam todas as caracteristicas de uma classe generalizada (superclasse).
+Mecanismos de Abstracao
Generalizacao / Especializacao Heranca
Atributos e metodos sao herdados de uma superclasse. Se uma subclasse possuir um atributo com o mesmo
nome da superclasse, as novas perspectivas de atributos serao adicionadas às herdadas.
Se atributos tiverem o mesmo nome e perspectivas default na superclasse e na subclasse, as perspectivas herdadas passam a ser opcionais.
+Objeto
É a instancia de uma classe.
Possui as mesmas caracteristicas basicas da classe
Representado de forma semelhante a classe. Nome e sublinhado, em minúsculo e opcional. É composto do:
nome-do-objeto:nome-da-classe
Os atributos e metodos sao representados com suas instanciacoes.
+Diagrama de Objeto
É a representacao no diagrama de classes, de um objeto excepcional, ou seja, um objeto diferente de todos os outros, que nao se enquadra em nenhuma das classes e que ocorre apenas uma vez, tornando desnecessario a criacao de uma classe para apenas um objeto.
+Esquema Conceitual de Classes
É o resultado dessa etapa do OOHDM.
+Esquema Conceitual a partir dos UIDs
Definir classes de objetos Para cada UID, definir uma classe para cada estrutura
+Esquema Conceitual a partir dos UIDs
Definir Atributos Para cada item de dado, retornado pela aplicacao ou
inserido pelo usuario, definir um atributo de acordo com as seguintes regras: Se o valor de um atributo A so e possivel de ser obtido a
partir da instanciacao de apenas uma classe X, entao esse item de dado e atributo desta classe.
Um item de dado sera atributo de uma associacao de classes, se for possivel obter seu valor a partir de uma classe X e Y.
Um item de dado sera atributo de uma nova classe, que devera ser criada, se o seu atributo nao depender de nenhuma classe existente ou da combinacao das mesmas.
+Esquema Conceitual a partir dos UIDs
Definir Atributos
+Esquema Conceitual a partir dos UIDs
Definir Relacionamentos Para cada atributo A, cujo seu item de dado apareca em
uma estrutura que nao corresponde a da sua classe verificar: Se existe outro atributo B, cujo seu item de dado esta na
mesma estrutura do atributo A, porem pertenca a outra classe diferente do atributo A;
É possivel obter as informacoes da uma única instancia da classe do atributo A a partir de uma instancia da classe do atributo B.
Caso isso ocorra, criar um relacionamento entre as classes do atributo A e B.
+Esquema Conceitual a partir dos UIDs
Definir Relacionamentos Cardinalidade
Se a classe do atributo B for a classe de sua estrutura , entao: Se o item de dado do atributo A e um item de dado
simples, entao a cardinalidade max da classe que contem o atributo A e 1.
Se o item de dado do atributo A for um conjunto, entao a cardinalidade max da classe que contem o atributo A e N.
Se o item de dado do atributo A for opcional, entao a cardinalidade min da classe que contem o atributo A e 0.
+Esquema Conceitual a partir dos UIDs
Definir Relacionamentos
+Esquema Conceitual a partir dos UIDs
Definir Operacoes / Metodos Em cada UID, para cada opcao que aparece junto a uma
transicao de estado, verificar se uma operacao / metodo deva ser criado para uma das classes correspondentes ao estado de interacao.
+Esquema Conceitual a partir dos UIDs
+Esquema Conceitual a partir dos UIDs
Ajustes Finais e Validacao Identificar Generalizacoes e Agregacoes Definir cardinalidades ainda nao definidas Eliminar ciclos redundantes de relacionamentos Validar as operacoes / metodos Verificar se faltou atributos para as classes Verificar se uma classe fora modelada como atributo de
outra classe. Neste caso a classe devera ser excluida.
+Fontes Bibliograficas
SCHWABE, Daniel. Modelagem Conceitual. PUC-RJ, 1998.