02 Modelagem de Domínio

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
Modelagem de domínio
 Capítulo 3
Universidade Federal de Juiz de Fora
DCC-134 – Modelagem de Sistemas de Informação
Prof. André Luiz de Oliveira 
*
*
Apresentação 
Modelagem de domínio
Derivação do modelo de domínio de um sistema
Diagrama de classes
*
Modelagem de domínio 
O termo domínio é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais que exibam funcionalidades similares. 
Exemplos de domínio incluem:
Domínio de Telecomunicações 
Domínio Logístico Atacadista 
Domínio Bancário 
Domínio de Seguros de Saúde 
Domínio Acadêmico Escolar 
*
Modelo de domínio – características gerais 
Um modelo de domínio é um artefato comum em várias metodologias
RUP ou métodos ágeis
Usado para expressar um determinado domínio, normalmente em linguagem UML. 
*
Modelo de domínio – características específicas 
Um modelo de domínio é um produto da modelagem de negócios
Representa, em certa escala, o negócio sendo modelado e compreendido. 
Deve ser realizado inicialmente pelos analistas de negócios e usuários do projeto, e revisado e complementado pelo máximo de participantes de um projeto. 
O modelo de domínio deve ser um artefato colaborativo, compartilhado por todo o time do projeto. 
*
Modelo de domínio – características específicas 
Um modelo de domínio captura o vocabulário do sistema ou negócio sob modelagem. 
Exemplo: um modelo de domínio de um sistema acadêmico de uma faculdade irá possuir os elementos Aluno, Professor, Curso, Disciplina ou Matrícula, entre diversos outros. 
Um modelo de domínio é uma representação lógica e estrutural de elementos do domínio e seus relacionamentos. 
Um diagrama de classes UML possui os elementos necessários para esta estruturação. 
Os conceitos de classes, associações e generalizações são suficientes para estruturar um modelo de domínio. 
*
Modelo de domínio – características específicas 
Um modelo de domínio expressa uma visão conceitual preliminar acerca de um sistema 
Um modelo de domínio deve ser feito no começo do projeto. 
O objetivo do modelo de domínio é capturar o negócio e servir de insumo para a geração de modelos mais formais como o diagrama de classes ou o DER e depois o código executável. 
*
*
Modelo de classes de um domínio
Representar classes de domínio do negócio significa:
Descrever cada problema representado pelos casos de uso, do sistema a ser desenvolvido, sem considerar características da solução, tais como:
Tecnologia a ser utilizada;
Linguagem de programação;
Ferramentas de desenho de telas e relatórios.
*
Identificação de classes
Classes
Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica
Classes bem-estruturadas formam uma parte de uma distribuição equilibrada de responsabilidades em um sistema
*
Identificação de classes
Representação de classes
Uma classe é representada graficamente como um retângulo
Características das classes: atributos, operações e responsabilidades
Notação
*
Identificação de classes
Representação de Classes
Podem ser exibidos somente os compartimentos desejados segundo o nível de abstração requerido no momento
Os nomes das classes são substantivos ou expressões breves, definidos a partir do vocabulário do sistema cuja modelagem está sendo feita.
*
Identificação de classes
Passos para facilitar a identificação de classes do sistema
Estude o domínio da aplicação
Faça uma observação geral no ambiente real onde existe o problema
Procure ouvir atentamente os especialistas do domínio do problema
Observe outros sistemas no mesmo domínio ou em domínios semelhantes
*
Identificação de classes
Heurísticas para descobrir potenciais candidatos a classes
Entidades que são parte do domínio de informação do problema
Ocorrências ou eventos que precisam ser registrados e lembrados pelo sistema
Papéis desempenhados pelas diferentes pessoas que interagem direta ou indiretamente com o sistema
Unidades organizacionais que possam ser relevantes para o sistema
Locais físicos e geográficos importantes no sistema
*
Exemplo: locadora de vídeo [Falbo, 2003]
Controle de Acervo
Título
Fita
Classe
Categoria
Distribuidor
Funcionário
Papéis desempenhados pelas pessoas
*
Exemplo: locadora de vídeo [Falbo, 2003]
Atendimento a Clientes
Cliente
Locação
Reserva
Pagamento
Cheque
*
Identificação de classes
Uma boa classe capta uma, e apenas uma, abstração. Ela deve ter um tema principal.
Ex: Uma classe que mantem as informações do aluno e mais as disciplinas que ele cursou não é uma boa classe. => crie duas classes :
Aluno + DisciplinaCursada
*
Exercício
Identifique Classes nos Problemas:
Sistema acadêmico
Pet shop
*
Especificação de atributos
Atributos
A estrutura de uma classe é representada por seus atributos
Atributos podem ser encontrados pelo exame das definições de classes, requisitos de problemas e pela aplicação do conhecimento do domínio
*
Especificação de atributos
Uma classe pode ter qualquer numero de atributos ou mesmo nenhum atributo.
Os atributos podem ser representados exibindo apenas o seu nome.
O nome de um atributo pode ser um texto, como os nomes das classes, o nome de um atributo é um substantivo ou expressão que, breve, representa alguma propriedade da classe correspondente.
*
Operações
Operações
Uma operação é uma abstração de algo que pode ser feito com um objeto e que é compartilhado por todos os objetos dessa classe
É a implementação de um serviço que pode ser solicitado por algum objeto.
Uma classe pode ter qualquer número de operações ou até nenhuma operação
*
Exemplo
Classe ContaBancária 
*
Identificação de relacionamentos
Relacionamentos entre classes
Classes colaboram umas com as outras através de relacionamentos
Um relacionamento é uma conexão entre itens
Relacionamentos apresentam caminhos para a comunicação entre os objetos
Há três tipos de relacionamentos:
Associação (incluindo Agregação)
Generalização
Dependência
*
Identificação de relacionamentos
Associações:
Uma associação é um relacionamento estrutural que especifica objetos de um item conectados a objetos de outro item
São válidas associações entre objetos de uma mesma classe
Uma associação é representada graficamente como uma linha sólida conectando a mesma classe ou classes diferentes
*
Identificação de relacionamentos
Associações e multiplicidades:
Associações são conexões normalmente bidirecionais entre as classes (binárias)
É possível ter associações conectando mais que duas classes (n-árias)
Multiplicidade indica quantos objetos podem participar de um dado relacionamento, ou seja, ela indica as fronteiras inferior e superior para os objetos participantes
*
Identificação de relacionamentos
Notações para associações e multiplicidades
Um A está associado a um e somente um B:
Um A está associado a um ou mais Bs:
*
Identificação de relacionamentos
Notações para associações e multiplicidades
Um A está associado a zero ou um B:
Um A está associado a zero ou mais Bs:
*
Multiplicidades
*
Identificação de relacionamentos
Associação
A multiplicidade (ou cardinalidade) indica quantos objetos podem participar de uma associação
*
Identificação de relacionamentos
Associações
Nomeação das associações pode ser feita rotulando-se um ou mais papéis
Nomear associações apenas quando necessário
*
Identificação de relacionamentos
Casos especiais de associações
Relacionamentos muito-para-muitos
Relacionamentos recursivos
Múltiplos relacionamentos entre objetos das mesmas classes
Exige nomeação de pelo menos uma das associações
Agregações
*
Identificação de relacionamentos
Casos especiais de associações
Relacionamentos muito-para-muitos
Relacionamentos
recursivos
*
Identificação de relacionamentos
Casos especiais de associações
Múltiplos relacionamentos entre objetos das mesmas classes
Nomeação de pelo menos 1 relacionamento
*
Identificação de relacionamentos
Agregações
Agregações são um tipo mais forte de conexão, onde a relação é entre o todo e suas partes
Relacionamento “parte-de” ou “é-composto-por”
Uma agregação é mostrada como uma linha conectando as classes relacionadas com um losango perto da classe que representa o todo
*
Identificação de relacionamentos
Tipos de Agregações
Agregação Composta ou Composição
A instância da “parte” pertence a uma única instância do “todo”
Representado por um losango preenchido
*
Identificação de relacionamentos
Tipos de Agregações
Agregação Compartilhada
A instância da “parte” pode compor várias instâncias do “todo”
Representado por um losango não preenchido
*
Identificação de relacionamentos
Outros exemplos para agregação compartilhada e composição: 
*
Identificação de relacionamentos
Classes de associação:
Em uma associação entre duas classes, a própria associação poderá ter propriedades
Uma classe de associação é um elemento da modelagem com propriedades de associação e de classe
As classes de associação são representadas com um símbolo de classe anexado a uma associação por uma linha tracejada
*
Identificação de relacionamentos
Exemplo de classes de associação:
*
Identificação de relacionamentos
Outros exemplos de classes de associação:
*
Identificação de relacionamentos
Associações n-árias
São utilizadas para representar a associação existente entre objetos de n classes
Uma associação ternária é um caso mais comum (menos raro) de associação n-ária (n = 3)
Na notação da UML, as linhas de associação se interceptam em um losango
*
Identificação de relacionamentos
Exemplo de associações n-árias
�
�
�
�
�
�
�
�
�
�
�
�
�
�
Uso�
�
�
�
�
�
�
�
�
Static Structure�
�
�
�
�
�
�
nome�
T�cnico�
�
�
�
�
�
�
�
modelo�
Computador�
�
�
�
�
�
�
�
nome
verba�
Projeto�
�
1�
1�
*�
*
Identificação de relacionamentos
Relações de dependência
Uma relação de dependência é uma forma mais fraca de relacionamento, mostrando uma relação entre um ‘cliente’ e um ‘fornecedor’
O ‘fornecedor’ não tem conhecimento semântico do ‘cliente’
Uma dependência é mostrada como uma linha pontilhada entre o 'cliente’ e o ‘fornecedor’, apontando sempre para o ‘fornecedor’
*
Identificação de relacionamentos
Dependência
As relações de dependência são relacionamentos de utilização
Exemplo:
Agenda de Cursos é dependente em relação a Curso:
Curso é empregado nas operações adiciona e remove de Agenda de Cursos
*
Identificação de relacionamentos
Exemplo Dependência:
*
Identificação de relacionamentos
Generalização
Uma generalização é um relacionamento entre itens gerais e tipos mais específicos destes itens
Os tipos gerais são chamados de super-classes
Os tipos mais específicos são chamados de subclasses ou classes-filha
*
Identificação de relacionamentos
Herança
Herança é uma relação entre super-classe e suas sub-classes
Descobre-se a herança analisando-se a hierarquia de classes
Uma classe que tem mais de uma classe mãe é identificada como usando heranças múltiplas
*
Identificação de relacionamentos
Especificação de Hierarquia de Classes
Estrutura para generalização e especialização
Trata-se de um mapeamento entre classes e não entre objetos!
Notação:
*
Identificação de relacionamentos
Diretrizes para analisar a hierarquia modelada:
Uma hierarquia de classes deve modelar relações “é um tipo de”
Toda subclasse deve ser um tipo específico das suas superclasses
Uma subclasse deve suportar toda a funcionalidade definida por suas superclasses
*
Identificação de relacionamentos
Critérios para classes geradas através de hierarquias:
As possíveis especializações e/ou generalizações devem estar no domínio do problema e devem fazer parte das responsabilidades do sistema
Se uma classe é dita subclasse de outra, todas as instâncias da subclasses têm de ser também instâncias da super classe
*
Identificação de relacionamentos
Exemplo de generalização/especialização:
*
Identificação de relacionamentos
Exemplo de generalização/especialização:
As subclasses herdam atributos, operações e associações da superclasse e agregam atributos e operações particulares ao elemento de especialização a que se referem.
*
Identificação de relacionamentos
Exemplo de generalização/especialização:
Todas as associações de classes feitas com a super-classe (Pessoa), no caso Pedido, são extendidas as sub-classes (PessoaFisica e PessoaJuridica).
*
Identificação de relacionamentos
Exemplo de generalização/especialização:
Todas as associações de classe feitas com as sub-classes, no caso Profissão com PessoaFisica, não é extendida a outra subclasses (PessoaJuridica).
*
Criando um modelo de domínio
Começando com as abstrações chaves, você pode criar um modelo do Domínio usando os seguintes passos:
Desenhe uma classe para cada abstração chave e:
Liste os atributos conhecidos
Liste as operações conhecidas
Desenhe associações entre classes colaboradoras.
Identifique e documente relacionamentos e nomes de papéis.
Identifique e documente a multiplicidade da associação.
Identifique e documente a navegabilidade da associação.
Identifique e documente classes de associação.
*
Passo 1: desenhe as classes
*
Passo 2: desenhe as associações
*
Passo 3: rotule as associações e nomes dos papéis
*
Passo 4: rotule a multiplicidade da associação
*
Passo 5: desenhe as setas de navegação
*
Passo 6: desenhe as classes de associação
*
Regra R1: Todo identificador gerado durante o processamento de um UC determina uma classe de objetos da aplicação, representando os objetos identificados pelo identificador.
Identificador gerado: identificador em um fluxo de saída que faz referência a um objeto criado durante o processamento do UC. 
identificador gerado
Regra R1
CLASSES DE OBJETOS
id_pedido, identificador gerado no UC 1, determina a classe Pedido;
id_pedido e id_cliente presentes no UC 3 não são identificadores gerados;
As demais classes determinadas por essa regra são: Cliente (id_cliente), Item (id_item) e Mesa (id_mesa).
Classe Pedido
ATOR: Cliente
 
 
UC 1: Abrir pedido
 
è
 pedido = dt_pedido + id_mesa + itens_ped
 
. . . . . 
 
ç
 
id_pedido
ATOR: Cliente
 
 
UC 3: Pedir a nota
 
è
 solicitacao_nota = 
id_pedido
 + [
id_cliente
]
 
ç
 nota = 
 
id_pedido
 + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_c
liente + 
tel_cliente]
 
. . . . . 
 
 
 
*
Regra R2a: Todo par <id1, id2>, onde id1 é um identificador gerado presente no fluxo de saída do UC e id2 é um identificador presente no fluxo de entrada, determina uma associação entre as classes identificadas por id1 e id2. 
No caso do fluxo de saída possuir mais de um identificador gerado, as associações correspondentes a pares que compartilham o mesmo id2 tendem a ser redundantes.
Regra R2a
ASSOCIAÇÕES ENTRE CLASSES (1)
id1: id_pedido, identificador gerado e de saída, no UC 1 (classe identificada: Pedido);
id2: id_item e id_mesa, de entrada, no UC 1 (classes identificadas: Item e Mesa, respectivamente).
Associação Pedido-Mesa
Associação Pedido-Item
ATOR: Cliente		UC 1: Abrir pedido
( 	pedido = dt_pedido + id_mesa + itens_ped
( itens_ped = 1{id_item + quant_item}
( 	id_pedido
 
*
Regra R2b: Quando os identificadores ocorrerem apenas em um dos fluxos do UC (considerando, para o fluxo de saída, apenas os identificadores gerados), todo par de identificadores
determina uma associação entre as classes por eles identificadas. 
Caso existam mais de dois identificadores, algumas dessas associações tendem a ser redundantes.
Regra R2b
ASSOCIAÇÕES ENTRE CLASSES (2)
Identificador não gerado
Associação Pedido-Cliente
Associação Pedido-Cliente
ATOR: Cliente		UC 3: Pedir a nota
( solicitacao_nota = id_pedido + [id_cliente]
( nota = 	id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente]
. . . . .
ATOR: Cliente		UC 5: Pendurar a nota
 ( pendura = id_pedido + id_cliente
*
*
*
*
*
*
http://blog.marcomendes.com/2008/07/10/modelagem-de-dominio/
*
4 - Os conceitos de classes, associações e generalizações são suficientes para estruturar um modelo de domínio. 
Como consequência, um modelo de domínio não captura interações temporais ou representações físicas de modelagem. 
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*