GuiaparaelaboraodoModelodeDomnio

MetodologiaCelepar

Agosto2009
 SumriodeInformaesdoDocumento

Documento:guiaModelagemClassesDominio.odt Nmerodepginas:20

Verso Data Mudanas Autor

1.0 15/10/08 criao DanielleMayer

1.0 21/07/08 RevisoeAlterao Ariel,Danielle

1.0 28/07/08 RevisoeAlterao Marcos,Danielle

1.0 12/06/09 Alterao MarcosChiarello

1.0 18/09/09 Reviso Marcos,Danielle

 Sumrio
1Introduo.........................................................................................................................................4
1.1VisoGeral..............................................................................................................................4
2DIRETRIZESPARAMODELAGEMDEDOMINIO...................................................................5
2.1IdentificarClassesConceituaiseAtributos..............................................................................5
2.1.1AnalisarEspecificaesdeCasosdeUso........................................................................5
2.1.2Identificarclasseseatributos............................................................................................6
2.1.2.1Exemplo.....................................................................................................................7
2.1.3Relatrios........................................................................................................................10
2.2IdentificarAssociaes...........................................................................................................10
2.2.1ListadeCategoriasdeAssociaes.....................................................................................11
2.2.2Exemplo..........................................................................................................................12
2.3RefinamentodoModelodeDomnio.....................................................................................14
2.3.1Generalizao......................................................................................................................14
2.3.1.1IdentificarSuperclasses....................................................................................................15
2.3.1.2IdentificarSubclasses.......................................................................................................15
2.3.1.3IdentificarClassesconceituaisabstratas...........................................................................16
2.3.1.4Exemplo............................................................................................................................16
2.3.2ClassesAssociativas............................................................................................................17
2.3.2.1Exemplo............................................................................................................................18
2.3.3AgregaoeComposio...................................................................................................18
2.3.3.1Exemplo............................................................................................................................19
2.4OrganizaodoModelodeDomnio......................................................................................19
2.5ConsideraesFinais..............................................................................................................19
 4

1 INTRODUO

A tarefa bsica da anlise orientada a objetos identificar conceitos no domnio do

problemaedocumentarosresultadosemumModelodeDomnio.Oobjetivodesteguiaorientar
aatuaodoAnalistadeSistemasduranteestetrabalho.

1.1 VisoGeral

O Modelo de Domnio a representao visual das classes conceituais ou objetos do

mundorealemumdomniodeproblema,deverepresentaracompreensodainformaoqueo
sistemavaigerenciar.
O Modelo de Domnio identifica os conceitos relacionados a requisitos do sistema e
analisa o problema sob a perspectiva conceitual. um artefato que representa o domnio do
problema,portanto,noutilizadoparamodelaraarquiteturadesoftware(diagramadeclassesde
projeto), poisesta,emborainicialmentederivadadomodeloconceitualpertenceaodomnioda
soluo.
Assim, o Modelo de Domnio deve ser independente da soluo fsica que vir a ser
adotadaedeveconterapenaselementosreferentesaodomniodoproblemaemquesto,ficando
para a fase de projeto os elementos da soluo, isto , todos os conceitos que se referem a
computadorescomo:interfaces,formasdearmazenamento(bancodedados),seguranadeacesso,
comunicao,etc.
UsandoanotaoUML((UnifiedModelingLanguage),umModelodeDomnioilustrado
comdiagramasdeclasse,ondedefiniesdeoperaesouresponsabilidadessodispensadas.
BasicamenteumModelodeDomniosercompostopor:
Conceitos(classesconceituais);
Atributos;
Relacionamentoentreclassesconceituais.

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 5

2 DIRETRIZESPARAMODELAGEMDEDOMINIO

2.1 IdentificarClassesConceituaiseAtributos

Estaatividadeconsisteemlocalizarclassesconceituaiseatributosrelacionadascomos
requisitos que esto sendo considerados, neste caso, os Casos de Uso envolvidos na iterao
correntedeveroseranalisados.
Oprocessodeidentificaodeclassesconceituaiseatributosbasicamentenorteadopelas
atividades:
AnalisarEspecificaesdeCasosdeUso;
IdentificarClasseseAtributos.

2.1.1 AnalisarEspecificaesdeCasosdeUso

AnalisarasEspecificaesdeCasosdeUsoidentificandoossubstantivosouexpresses
que denotam substantivos(conhecidas em lingstica como sintagmas nominais, ex: item de
locao,autorizaodepagamento,etc.)queseroconsideradoscandidatosaclassesconceituais
ouatributos.
Cadasubstantivoidentificadodeveserrelacionado,agrupandopalavrasouexpressesque
sosinnimos(comoporexemploemprstimoelocao).

ParaauxiliarnestaanliseobserveaTabela1abaixolistada.

Categoria Significado
Entidadesexternas (outrossistemas,dispositivosepessoas)queproduzemouconsomeminformaoa
serusadapelosistema.

Coisas (relatrios,figuras,cartas,sinais)quesopartedodomniodeinformaodo
problema.

Ocorrnciasdeeventos (efetuapagamento,emiterecibo)queocorremdentrodocontextodaoperaodo
sistema.

Papis (gerente,engenheiro,vendedor)desempenhadosporpessoasqueinteragemcomo
sistema.

Unidadesorganizacionais (diviso,grupo,equipe,setor)quesorelevantesparaosistema.

Lugares (recepo,estoque)queestabelecemcontextodoproblemaouafunoglobaldo

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 6

Categoria Significado
sistema.

Estruturas (sensores,impressora,computadores,leitoradecdigodebarra)quedefinemuma
classedeobjetosouclassesrelacionadasdeobjetos.

Tabela1:CategorizaodeConceitos
Observao:
Acorrespondnciadosubstantivoemumadascategoriasumindciodequeele
candidatoaclasseconceitual.

2.1.2 Identificarclasseseatributos

Classesconceituaisnormalmentesoidentificadasapartirdeconceitoscomplexos, que
possuemumcomportamentobemdefinidoenopodemserdescritasportiposalfanumricos.
Atributosnormalmentesoidentificadosapartirdeconceitossimples,quenotemcomportamento
definidoecomumnicotipodedadoassociado.IdentifiqueatributosnoModelodeDomnio,
quandoestessatisfazemanecessidadedememorizarinformaesreferenteaosrequisitos(Casosde
Uso)daiteraocorrente.

Dentre os itens identificados, alguns sero classificados como classes conceituais

(conceitoscomplexos),algunsseroclassificadoscomoatributosdeclassesealgunspoderoser
descartadoscomoclasseseatributosporseremirrelevantesparaosistema.
Paracadaitemverifiqueosseguintesquestionamentos:

Oitemfarpartedoescopodosistema?(ouapenasumainformaodosagentes
externosaosistema)
O item possuir um comportamento identificado no sistema? (Possuir
responsabilidades/mtodos)
Oitempossuirumaestruturaidentificadanosistema?(estarassociadoaatributos)
Oitemserelacionaraoutroitem?

Searespostaparatodososquestionamentosforsim,possivelmenteoitemidentificado
representaumaclasse.
Duranteaidentificaodeclasseseatributosdevesetomaratenoaositensquepossuem
omesmosignificado.Seissoocorrer,possivelmenteelesrepresentamomesmoitem.

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 7

2.1.2.1 Exemplo

CenrioprincipaldoCasodeUsoProcessarVendadeumsistemadeVendas

1. OClientechegaaopontodepagamentocombensouserviosparaadquirir.
2. OCaixainiciaumanovavenda.
3. OCaixadigitaoIdentificadordoitem.
4. OSistemaregistraalinhadeitemdevendaeapresentaumadescriodoItem,opreodomesmo
eototalparcialdavenda.Opreocalculadosegundoumconjuntoderegrasdepreos.
OCaixarepeteospassos3e4atqueindiqueterterminado.
5. OSistemaapresentaototal.
6. OCaixainformaaoClienteototalesolicitaopagamento
7. OClientepagaeoSistemaprocessaopagamento.
8. OSistemaregistraavendacompletadaeenviaasinformaesdevendaepagamentoparaoSistema
externodeContabilidade(paracontabilizaoecomisses)edeEstoque(paraatualizaroestoque).
9. OSistemaapresentaorecibo.
10. OClientesaicomoreciboeosbens(seforocaso)
FluxosAlternativos
...
7a.Pagamentocomdinheiro:
1. OCaixadigitaaquantiadedinheirofornecida.
2. OSistemaapresentaovalordotrocoeliberaagavetadedinheiro
3. OCaixadepositaodinheirofornecidoeentregaotrocoparaoCliente.
4. OSistemaregistraopagamentoemdinheiro.

ApartirdaanlisedaEspecificaodoCasodeUsoProcessarVendaforamrelacionados
itens candidatos aclasses conceituais eatributos. Naseqncia osmesmosforamclassificados
comoapresentadonaTabela2:

ItemCandidato NomedaClasseouNomedo Classificao

Atributo
Cliente Cliente Classe
bens DescartadocomoclasseeAtributo
Estedescartepossvelporquebense
servios, neste contexto, so
sinnimosparaitem
servios DescartadocomoclasseeAtributo
Estedescartepossvelporquebense
servios, neste contexto, so
sinnimosparaitem
identificadordoitem Item Classe

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 8

ItemCandidato NomedaClasseouNomedo Classificao

Atributo
Caixa Caixa DescartadacomoclasseeAtributo.
Este descarte possvel porque no
est definido nos requisitos a
necessidade de ser conhecido ou de
registrodoCaixaatual.Claroque,se
os requisitos mudarem, e surgir a
necessidade de exibir no recibo a
identificao do caixa este item
candidatotornaraseumaClase.
Venda Venda Classe
linhadeitemdevenda LinhaDeItemVenda Classe
descriodoItem descricao Atributo
Paramostraradescriodoitemem
telaourecibo
preo preco Atributo
Para calcular o total da venda e
mostraropreodalinhadeitem
total DescartadocomoclasseeAtributo
Descartado porque no necessrio
memorizar esta
informao(informaocalculada)
pagamento Pagamento Classe
Contabilidade DescartadocomoclasseeAtributo
Descartado porquenofazparteda
iteraocorrente.
comisses DescartadocomoclasseeAtributo
Descartado porquenofazparteda
iteraocorrente.
Estoque DescartadocomoclasseeAtributo
Descartado porquenofazparteda
iteraocorrente.
recibo DescartadocomoclasseeAtributo
Descartado porque apenas representa
umrelatriodavenda.
dinheirofornecida(quantia) quantia Atributo
Para determinar se houve um
pagamentosuficiente eparacalcular
otroco.
valordotroco DescartadocomoclasseeAtributo
Descartado porque no necessrio
memorizar esta
informao(informaocalculada)
gavetadedinheiro DescartadocomoclasseeAtributo
Descartado porque no relevante
paraositemacomputacional.

Tabela2:ExemplodeItensCandidatos

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 9

Alm dos candidatos extrados do texto foram identificados outros conceitos no explcitos,
conformedemonstradonaTabela3.
ItemCandidato NomedaClasseouNomedo Classificao
Atributo
Loja Loja Classe
EstabelecimentodeVendanecessrio
para guardar dados necessrios
emissoderecibos.
EspecificaodeProduto EspecificacaoDeProduto Classe
Classe conceitual de especificao
cujo objetivo manter a descrio
sobre o item, independente da
existnciafsicadesteitem.

quantidade quantidade Atributo

Para registrar a quantidade de um
determinadoitemnavenda
endereo endereco AtributoouClasse
Para o caso do recibo requerer Obs:Nesteexemploconsideraremos
endereo enomedoestabelecimento comoatributo,
davenda
nome nome Atributo
Para o caso do recibo requerer
endereo enomedoestabelecimento
davenda
data data Atributo
Umreciboumrelatriodeuma
vendaquenormalmentedevemostrar
dataeohorriodavenda
horrio Atributo
Umreciboumrelatriodeuma
vendaquenormalmentedevemostrar
dataeohorriodavenda

Tabela3:ExemplodeItensCandidatos

SegueabaixoaFigura1querepresentaoprimeiroesboodoModelodeDomniodoexemplo:

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 10

Figura1:Classes
2.1.3 Relatrios

Relatrios identificados devero ser considerados candidatos a classes conceituais

medianteaseguinteanlise:

Emgeral,acrescentarumrelatrioemummodelodedomnionotilporquetodaasua
informaoderivadadeoutrasfontes,duplicandoassimainformaoquepodeserobtida
deoutraforma.Estaumarazoparanoconsiderlo;
Porexemplo:Umreciboumrelatriodevenda.
Agoraseorelatriodesempenhaumpapelespecialemtermosderegradenegcio.Esta
umarazoparaconsiderlo.
Porexemplo:
Umreciboconfereaoportadorodireitodedevolverositenscompradospelo
mesmo.

2.2 IdentificarAssociaes

Uma associao um relacionamento entre classes que indica uma conexo(relao

esttica)comsignificadoeinteresse.
Para encontrar as associaes entre classes conceituais devese observar cada classe e
verificarseainformaorepresentadaestcompleta.Senoestiver,devesecriarumaassociao
entre uma classe e outra a fim de complementar a informao necessria para que a classe

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 11

(conceito)faasentido.
Porexemplo:
AclasseCliente,identificadanoexemploanterior,umainformaoaparentemente
completa,quenonecessitadeassociaesparasecomplementar.
Jaclasse Vendaporsisnofazsentido, casonosesaiba qualcliente est
relacionado ou qual(ais) itens de Venda (LinhaDeItemVenda) esto contidos na
venda(oqueestsendovendido/comprado).
Outramaneiraverificaranecessidadedeassociaesparaasquaisoconhecimentodo
relacionamentoprecisaserpreservadoporalgumtempo(associaesqueprecisamserconhecidas),
quepermitiroalgumtipodenavegaonoprojetoenaimplementaoepodemserteispara
facilitaroentendimentodomodeloconceitual.
Porexemplo:
UmitemdeumavendatemumaassociaocomaclasseVendaparapossibilitaro
clculodototaldevendaseaemissoderecibo.
TambmpossvelencontrarassociaespelousodatcnicadeListadeCategoriasde
Associao.

Observao:
1. Paranomearassociaesuseumafrasecomverboquefacilitealeituraquandojuntadacom
osconceitos(classes)emcadaextremidade.
Exemplo:Venda(classe)PagaporPagamento(classe)
2. Direo:Umaconvenotilconsideraraleituradeassociaesdaesquerdaparaadireita
oudecimaparabaixo,emboraaUMLnofaadissoumaregra.

2.2.1 ListadeCategoriasdeAssociaes

Tcnica utilizada para encontrar associaes tendo por base a lista de categorias de
associaes,conformeTabela4quesegue:

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 12

CategoriadeAssociaes
AumapartefsicadaB
AumapartelgicadeB
AfisicamentecontidoemB
Alogicamentecontidoem/sobreB
AumadescriodeB
AumalinhadeitemdeumatransaoourelatrioB
Aconhecido/registrado/relatado/captadoporB
AummembrodeB
AumasubunidadeorganizacionaldeB
AusaougerenciaB
AsecomunicacomB
AestrelacionadocomumatransaoB
AumatransaorelacionadacomumaoutratransaoB
AadjacentedeB
ApossudoporB
AumeventorelacionadocomB
Tabela4:CategoriasdeAssociao

DentreasassociaescomunsasmaisteisemumModelodeDomnioso:
AumapartefsicaoulgicadeB
AestfisicamenteoulogicamentecontidoemB
AregistradoporB

2.2.2 Exemplo
ContinuandooexemplodoCasodeUsoProcessarVendadeumsistemadeVendas,as
seguintesassociaessoidentificadas,conformeTabela5:

Associao Significado
VendaPagaporPagamento Parasaberseavendafoipaga,relacionara
quantiafornecidacomototaldavendae
imprimirorecibo
Aumatransaorelacionadacomumaoutra
transaoB(categoriadeassociao)
LinhaDeItemDeVendaContidoemVenda AumapartelgicadeB(categoriade
associao)
Aumalinhadeitemdeumatransaoou

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 13

Associao Significado
relatrioB(categoriadeassociao)
EspecificaoDeProdutoDescreveItem AumadescriodeB(categoriadeassociao)
LojaRegistradadosdaVenda Aconhecido/registrado/relatado/captadoporB
NestecasoArepresentaaVendaeBrepresenta
aLoja

VendaIniciadaporCliente AumeventorelacionadocomB(categoriade
associao)

LinhaDeItemDeVendaDescritopor Parasaberqualprodutoreferenteacadalinha
EspecificacaoDeProduto devenda.

LojaEstocaItem AestfisicamentecontidoemB
NestecasoArepresentaaVendaeBrepresenta
aLoja
Tabela5:Associaesidentificadas

Observaes:
Evitarassociaesredundantesouderivveis.
Evitar associaes que no indiquem necessidade de ser conhecidas de acordo com os
requisitos,comodemonstradonaTabela6:
Associao Justificativaparadescarte
VendaIniciadaporCliente Osrequisitosnoindicamanecessidadedeser
conhecidoouderegistraroclientequedincio
aumavenda.
LojaEstocaItem Osrequisitosnoindicamanecessidadedeser
conhecido ou de manter informaes sobre o
estoque. Os requisitos indicam que Estoque
umsistemaexterno.
Tabela6:Associaesdescartadas

TendoemvistaoquadroacimaaassociaoVendainiciadaporClientenoserianecessria,
entretanto, ela importante para a compreenso do domnio. Sendo assim, enfatize as
associaes que devem ser conhecidas, mas acrescente, conforme necessidade, associaes
destinadassomenteaenriqueceracompreensocrticadodomnio.

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 14

Figura2:ModelodeDomniocomAtributoseAssociaesidentificadas

2.3 RefinamentodoModelodeDomnio

Aps a criao doModelo de Domnio bsico importante oseu refino conforme as

notaesdeGeneralizao,ClassesassociativaeAgregao/Composio.

2.3.1 Generalizao

Generalizaoaatividadedeidentificaroquehdecomumentreosconceitosedefinir
relacionamentosentresuperclasses(conceitogeral)esubclasses(conceitosespecializados).Tratase
deumaformadeconstruirclassificaestaxonmicasentreconceitoseilustrlasemhierarquiade
classes.
Estaidentificaoimportante,poispermiteoentendimentodosconceitosemtermosmais
gerais,refinadoseabstratos.Conduzaumacompreensoaprimoradaeareduodeinformaes
repetidas,ouseja,aumaeconomiadeexpresso.
Passospararealizarageneralizaodamodelagem:

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 15

1. IdentificarSuperclasses;
2. IdentificarSubclasses;
3. IdentificarClassesConceituaisAbstratas.

2.3.1.1 IdentificarSuperclasses

A generalizao em uma superclasse aconselhada quando so identificados aspectos

comunsentresubclassesempontencial.
Crieumasuperclasseconceitualemumrelacionamentodegeneralizaocomsubclasses
quando:
As subclasses conceituais em potencial representarem variaes de um conceito
semelhante;
AssubclassesobedecemRegrados100%eRegradoum;
Todas as subclasses tiverem o mesmo atributo, o qual possa ser decomposto e
expressonasuperclasse;
Todasassubclassestiveramamesmaassociao,aqualpossaserdecompostae
relacionadacomasuperclasse.
Regrados100%>100%dadefiniodasuperclasseconceitualdeveseraplicvelsubclasse.A
subclassedeveestar100%deacordocomosatributoseassociaesdasuperclasse.
Regra um > Todos os membros do conjunto de uma subclasse devem ser membros do
conjuntodeumasuperclasse,ouseja,aSubclasseumaSuperclasse.

2.3.1.2 IdentificarSubclasses

Afatoraodeclassesconceituaisasuadivisoemsubclassesdisjuntas.Sendotil,este
particionamento,quando:

Asubclassetiveratributosadicionaisdeinteresse;

Asubclassetiverassociaesadicionaisdeinteresse;

Oconceitodasubclasseforoperado,tratado,reagidooumanipulado demaneira

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 16

diferentedasuperclasseoudeoutrassubclasses,deformaquesejaminteressantesa
seconsiderar;

Oconceitodasubclasserepresentaalgoanimado(porexemplo,umanimal,umrob)
quesecomportademaneiradiferentedasuperclasseoudeoutrassubclasses.

Resumidamente,oprincipalmotivoparaextrairumasubclasseapercepodequeuma
classetemcomportamentousadoporalgumasinstnciasdamesma(objetos)enoporoutras.

2.3.1.3 IdentificarClassesconceituaisabstratas

Aclasseabstratasempreumaclassepaiquenopossuiinstncias.Eladefineummodelo
para uma funcionalidade e fornece uma implementao incompleta a parte genrica dessa
funcionalidadequecompartilhadaporumgrupodeclassesderivadas.tilidentificarclasses
abstratas, pois elas restringem as classes para as quais possvel ter instncias concretas,
esclarecendoassimasregrasdodomniodoproblema.[Umaclasseabstrataestdestinadaapenasa
servir como base para a criao de outras classes servindo como guia para a definio do
comportamentodosherdeiros,dassubclasses.]

Secadamembrodeumasuperclassetambmdevesermembrodeumasubclasse,entoa
superclassechamadaclasseconceitualabstrata.

AnotaoUMLpararepresentaoindicarseunomeemitlico.

2.3.1.4 Exemplo

EsteexemplorepresentaquetodainstnciadePagamentodeveser,maisespecificamente,
uma instncia das subclasses PagamentoEmDinheiro, PagamentoComCartaoDeCredito,
PagamentoComCheque.

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 17

Figura3:Generalizaocomclasseconceitualabstrata

2.3.2 ClassesAssociativas

umaclassequeestligadaaumaassociao,aoinvsdeestarligadaaoutrasclasses.
normalmente necessria quando duas ou mais classes esto associadas, e necessrio manter
informaes sobre esta associao, podendo estar ligada a associaes de qualquer tipo de
conectividade.
A Classe de Associao pode ser vista como uma associao com propriedades de
associaoedeclasseedevemserutilizadas,quandonecessrio,paramanterinformaessobre
umaassociaoespecficaentreobjetosdeduasclassesrelacionadas.
ClasseAssociativapodesertilemumModelodeDomnioquando:
Umatributoestrelacionadoaumaassociao;
Asinstnciasdaclasseassociativatmumtempodevidadependentedaassociao;
H uma associao de muitosparamuitos entre dois conceitos, bem como
informaesrelacionadasassociaopropriamentedita.

2.3.2.1 Exemplo

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 18

Figura4:ClasseAssociativa

2.3.3 AgregaoeComposio

AgregaoumtipoespecialdeAssociaoquedemonstraqueasinformaesdeum
objeto (objetotodo)precisam sercomplementadas pelas informaes contidas emumou mais
objetosdeoutraClasse(objetoparte).
Composioumtipodeagregaoondeotempodevidadapartecoincidentecomo
tempodevidadotodo.Nestecaso,aspartesspodempertenceraotodoesodestrudascomele.

IdentificareilustraragregaesemumModelodeDomnio nomuitoimportante, a
menosqueelaesclarearestriesexistentesnodomniocomrelaoexistnciaaceitveldaparte
independente do todo oua parte pode no existir fora do tempo de vida dotodo, no caso da
composio.Sendoassim,autilizaodeumrelacionamentodeagregaosubjetivaenodeve
serutilizadaindiscriminadamente,utilizeasomenteseosignificado(semntica)efetivamenteseja
deespecificaredocumentaraindicaodotodo/parte(nocasoagregao)e,ainda,quetempo
devidadapartecoincidentecomotempodevidadotodo(nocasocomposio).

Durante a modelagem da soluo, classes de software, este tipo de associao

(agregao/composio)sermaisconsideradodevidoaoimpactosobreasdependnciascriao
destruioexistentesentreasclassesdesoftware,esobreasclassespersistentesquerepresentamo
todoeaspartes(emtermosdeintegridadereferencialecaminhosdeexclusoemcascata).

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 19

2.3.3.1 Exemplo

Figura5:ClassescomrelacionamentodeComposio

2.4 OrganizaodoModelodeDomnio

Asclassesdomodelodedomniodeveroestarorganizadasemumpacote,conforme
notaodaUML,denominadoDOMNIO.Dentrodestepacote,seomodelodedomniocrescer
muito,interessantecriarnovospacotes.
Paraparticionaromodelodedomnioempacotes,agrupeelementosque:
estejam ligados aomesmoassunto intimamente relacionados porconceitos ou
finalidades;
estejamjuntosemumahierarquiadeclasses;
participemdosmesmoscasosdeuso;
estejamfortementeassociados.

2.5 ConsideraesFinais

NoexisteModelodeDomniocorretoouerrado,todososmodelossoaproximaesdo
domnioqueestamostentandocompreender. UmbomModelodeDomniocaptaasabstraes
essenciaiseasinformaesnecessriasparacompreenderodomnionocontextodosrequisitos
considerados,auxiliandoaspessoasnacompreensododomnioseusconceitos,terminologiae
relacionamentos.
AodesenvolverumModelodeDomnio,procurelembrardasseguintesdiretrizes:
maisimportanteidentificarclassesconceituasdoqueassociaes;
O excesso de associaes tende a tornar o modelo de domnio confuso, em vez de
esclareclo;

METODOLOGIADEDESENVOLVIMENTOCELEPAR
 20

Evitemostrarassociaesredundantesouderivveis.

METODOLOGIADEDESENVOLVIMENTOCELEPAR