+

Anlise e Projeto Orientado a Objetos

Modelagem de Domnio
 2

Introduo

n A modelagem do domnio est relacionada descoberta das

informaes que so gerenciadas pelo sistema. O resultado
dessa investigao expressa no modelo de domnio.
n Um modelo pode ser visto como uma representao idealizada
de um sistema a ser construdo (e.g, maquetes, plantas de
circuitos, plantas arquitetnicas).
n Diagramas UML integram os modelos utilizados em
desenvolvimento de software.
n Benefcios do uso de modelos: melhor gerenciamento da
complexidade (abstrao), melhor comunicao, reduo dos
custos, predio do comportamento do sistema.
 3

Introduo

n Denomina-se domnio do negcio, ou apenas domnio, a rea de

conhecimento especfica na qual um determinado sistema de
software ser desenvolvido.

n Modelo de domnio uma representao visual de conceitos

do mundo real. um dos artefatos mais importantes e mais
utilizados em desenvolvimento de software.
n Diagramas de classes da UML so amplamente utilizados para
expressar os conceitos do domnio. No entanto, diagramas do tipo
entidade-relacionamento tambm possuem essa mesma
aplicabilidade.
 4

Introduo
 5

Benefcios

n Melhor compreenso do domnio

n Estabelecimento de uma comunicao menos ambgua

n Desenvolvedores e pessoas do negcio passam a falar a mesma
lngua (menor hiato representacional)

n Abstrao: foco nos dados e conceitos que devem ser

manipulados pelo sistema e no na soluo tecnolgica
n Modelos de domnio so utilizados principalmente na
identificao dos dados persistentes, mas podem ser aplicados
em outras camadas ou mdulos do sistema
 6

Perspectiva conceitual

n Um modelo de domnio uma descrio de coisas em uma

situao real do domnio de interesse, e no de objetos de
software

n O modelo de domnio faz parte da anlise, ou seja da

investigao do problema
n Modelo de domnio no projeto

n As classes em um diagrama de domnio representam conceitos

e no classes de software a serem implementadas em um
linguagem de programao

n Um modelo de domnio tambm no um modelo de dados.

Portanto, no exclua classes que no sero persistidas mas que
possuem significado comportamental no domnio
 7

Perspectiva conceitual

n O modelo de domnio descreve a informao que sistema

deve gerenciar
n Mas no indica como o sistema a deve gerenciar

n O modelo de domnio esttico. Ento, no devem existir

referncias a operaes ou aspectos dinmicos dos sistemas
n Embora o modelo conceitual seja representando pelo diagrama
de classes da UML, o analista no deve ainda adicionar mtodos a
essas classes.
 8

Perspectiva conceitual

n Anlise:

n Projeto:
 Elementos do modelo de domnio
n Atributos: informaes alfanumricas simples, como nmeros,
textos, datas, etc.

n Classes ou conceitos: que so a representao da informao

complexa que agrega atributos e que no pode ser descrita
meramente por tipos alfanumricos.

n Associaes: que consistem em um tipo de informao que liga

diferentes conceitos entre si.
 10

Encontrando classes conceituais

n Algumas tcnicas:
n Revisar modelos existentes.
n Lista de categorias. Larman apresenta um exemplo de lista com
16 categorias que so teis na identificao inicial.
n Modelagem CRC (classes, responsabilidades e colaboradores).
Identifica as classes candidatas a partir de sesses envolvendo
especialistas do negcio e desenvolvedores. As classes so
registras em cartes. Bezerra apresenta informaes detalhadas
sobre este mtodo.
n Anlise lingustica. Tcnica simples e muito difundida. Realizada a
partir de descries textuais do domnio.
 11

Anlise lingustica

n A partir do texto dos casos de uso:

n Passo 1: isole os substantivos e frases nominais
n Tambm inclua os verbos relacionados a eventos que possuem
informaes importantes que devem ser guardadas pelo
sistema
n Passo 2: mantenha aqueles que so importantes para o sistema
n Passo 3: agrupe os sinnimos
n Passo 4: diferencie conceitos e atributos
Atributos

n So os tipos escalares

n NO so estruturas de dados como listas, tabelas e arrays

n So sempre representados no contexto de uma classe:

 Tipagem
n Atributos podem ter tipos clssicos como string, inteiro, data, etc.,
ou tipos primitivos definidos pelo analista:
Valores Iniciais

Atributos podem ser definidos com

valores iniciais.
Valores iniciais so produzidos no
atributo no momento que as instncias
da classe correspondente forem criadas
 Atributos Derivados
n No so definidos diretamente, mas calculados
 Enumeraes
n So um meio termo entre o conceito e o atributo.
n So basicamente strings e se comportam como tal, mas h um
conjunto predefinido de strings vlidas que constitui a
enumerao.
 Caractersticas de Enumeraes
n NO podem ter associaes com outros elementos.

n NO podem ter atributos.

n Se isso acontecer, ento no se trata mais de uma enumerao, mas

de um conceito complexo.
 Tipos Primitivos
nO
analista pode e deve definir tipos primitivos
sempre que se deparar com atributos que
tenham regras de formao, como no caso do
Quantidade em que sua formao composta
de valor e unidade..
nTipos
primitivos podem ser classes
estereotipadas com <<primitive>>.

Exemplo: CDU Comprar Livros
n Fluxo Principal
1. [IN] Comprador informa sua
identificao.
2. [OUT] Sistema informa os livros
disponveis para venda (ttulo, capa
e preo) e o contedo atual do
carrinho de compras.
3. [IN] Comprador seleciona os livros
que deseja comprar.
4. Comprador decide finalizar a
compra.
5. [OUT] Sistema informa o valor total
dos livros e apresenta as opes de
endereo cadastradas.
6. [IN] Comprador seleciona um
endereo para entrega.
7. [OUT] Sistema informa o valor do
frete e total geral, bem como a lista
de cartes de crdito j
cadastrados para pagamento.
8. [IN] Comprador seleciona um
carto de crdito.
19
9. [OUT] Sistema envia os dados do carto
e valor da venda para a operadora.
10. [IN] Operadora informa o cdigo de
autorizao.
11. [OUT] Sistema informa o prazo de
entrega.
Fluxo alternativo (4): Comprador decide
guardar carrinho
4a.1 [OUT] Sistema informa o prazo em
dias em que o carrinho ser mantido.
Fluxo de exceo 6a: Endereo consta
como invlido
6a.1 [IN] Comprador atualiza o endereo e
caso de uso segue para o passo 6.
Fluxo de exceo 10a: Operadora no
autoriza a venda
10a.1 [OUT] Sistema apresenta outras
opes de carto ao comprador.
10a.2 [IN] Comprador seleciona outro
carto e caso de uso segue para o passo
9.
 20

Exemplo: resultado
 Associaes
n Relacionam dois ou mais conceitos entre si.
 Papeis
n Correspondem funo que um lado da associao representa em
relao aos objetos do lado oposto.

n Mltiplas Associaes Demandam Papeis

Como Encontrar Associaes?

n Procure observar cada conceito complexo e se pergunte se a

informao representada por ele completa

n se no for, deve-se criar uma associao entre este conceito

e outro(s) conceito(s) de forma a complementar a
informao necessria para que o conceito faa sentido
Dependncia entre Conceitos

n Conceitos dependentes (como Compra) precisam

necessariamente estar ligados aos conceitos que os
complementam (como Comprador e Item).

n Informaes associativas s podem ser representadas

atravs de associaes
 Atributos Disfarando Associaes
n No se deve colocar no modelo conceitual os atributos que
representam chaves estrangeiras
n como se fosse uma tabela de banco de dados relacional
Errado Errado
 Multiplicidade de Papel
n Indica quantos objetos podem se associar.
n Sempre h um limite inferior.
n Pode haver um limite superior.
n Consideraes de Multiplicidade

o O papel obrigatrio ou no?

Uma pessoa obrigada a ter pelo menos um automvel?
Um automvel deve obrigatoriamente ter um dono?
o A quantidade de instncias que podem ser
associadas atravs do papel tem um limite
conceitual definido?
Existe
um nmero mximo ou mnimo de automveis que
uma pessoa pode possuir?
 Armadilha da Obrigatoriedade
n A toda venda corresponde um pagamento.

n Mas isso no torna a associao obrigatria, pois a venda pode

existir sem um pagamento.

n Um dia ela possivelmente ser paga, mas ela pode existir sem o
pagamento por algum tempo.

n Ento esse papel no obrigatrio para a venda.

Armadilha do Limite Mximo
nO
nmero mximo de automveis que uma
pessoa pode possuir o nmero de automveis
que existe no planeta. Mas medida que outros
automveis venham a ser construdos, esse
magnata poder possu-los tambm.
nEmboraexista um limite fsico, no h um limite
lgico para a posse.
nEntoo papel deve ser considerado
virtualmente sem limite superior.
 29

Exemplo: CDU Comprar Livros

 30

Exerccio

n As informaes a seguir se referem a uma aplicao de

controle de comanda eletrnica da padaria Doce Sabor de
Seu Joaquim.
n O cliente utiliza uma comanda eletrnica durante suas compras
na padaria. A cada produto consumido, o atendente registra em
sua comanda (que possui uma numerao) o produto e a
quantidade. Ao passar no caixa na sada da padaria, a caixa l os
gastos da comanda, finalizando a compra. Na leitura da comanda,
verifica-se o valor unitrio de cada produto a fim de calcular o
valor total da compra.

n Faa um diagrama de classes conceituais desse cenrio.

 31

Referncias

n LARMAN, Craig. Utilizando UML e padres: uma

introduo anlise e ao projeto orientados a objeto e ao
desenvolvimento iterativo. Porto Alegre: Bookman, 2007, 3
ed.

n WAZLAWICK, Raul Sidnei. Anlise e Projeto de Sistemas de

Informao Orientados a Objetos. Rio de Janeiro: Elsevier,
2011, 2 ed.

n BEZERRA, Eduardo.Princpios de Anlise Projeto de

Sistemas com UML. Rio de Janeiro: Campus, 2002.

n MELO, Ana Cristina. Exercitando modelagem em UML. Rio

de Janeiro: Brasport, 2006.