+ O.O.H.D.M. Modelagem Conceitual Professor Andre Moura [email protected]

+

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.


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.


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.


Representacao do objeto Jose.

Jose pertence a classe Pessoa.


Classe: Conjunto de objetos com atributos semelhantes, mesmos

comportamentos e relacionamentos e mesma semantica (mesma representacao).


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.


Associacao: Expressa o relacionamento entre as classes.


Cardinalidade / Multiplicidade:


Agregacao: Denota um relacionamento do tipo “e-parte-de” ou “todo-

parte”.


Heranca: Mecanismo de reuso da OO o qual nos permite herdar

propriedades de classes ja existente.


Generalizacao / Especializacao: Denota relacionamento do tipo “e um tipo de”, onde uma

superclasse e especializada por subclasses.


+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.


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.


Generalizacao / Especializacao É um relacionamento do tipo “e-um-tipo-de”. Classes

especializadas (subclasses) herdam todas as caracteristicas de uma classe generalizada (superclasse).


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


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.


Definir Atributos


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.


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.


Definir Relacionamentos


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.



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.

Documents

+ O.O.H.D.M. Modelagem Conceitual Professor Andre Moura [email protected]