Modelo de Dominio PDF

Modelo de Dominio -
Autor: Juan Pablo Beltramone

Versin: 1.0
UTN FRR

Modelo de Dominio - Ing. Juan Pablo Beltramone Pgina 1

MODELO DE DOMINIO

Introduccin al UML

El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica, es un lenguaje de
modelado y no un mtodo o un proceso. El UML utiliza una notacin especfica y reglas
semnticas relacionadas con la construccin de sistemas de software.
El UML en s mismo no prescribe ni aconseja cmo usar esta notacin en el proceso de desarrollo o
como parte de una metodologa de diseo orientada a objetos.
El UML soporta un conjunto rico de elementos grficos para la generacin de diversos diagramas,
como los utilizados para simbolizar clases, componentes, nodos, actividades, flujos de trabajo, casos
de uso, objetos, estados y las relaciones entre todos ellos.
El UML provee beneficios significativos para los desarrolladores de software y las organizaciones
ayudndolos a construir modelos rigurosos, trazables y mantenibles, que soporten el ciclo de vida
completo de desarrollo de software.
Para ms informacin vase el apunte de Introduccin al UML.

El Modelo Lgico o Esttico
Un modelo lgico es una vista esttica de los objetos y las clases que cubren el espacio de anlisis y
diseo.
El modelo lgico abarca tanto el Modelo de Dominio como el Modelo de Clases.
Por lo general, el modelo de dominio es una vista ms general, de los conceptos del negocio de ms
alto nivel, desde un enfoque prioritariamente de Anlisis, mientras que el modelo de clases es un
modelo ms riguroso y enfocado al diseo, en el cual se incluyen clases (ya no conceptuales)
especficamente introducidas como solucin para la implementacin del Software.
Por todo ello, como el MD es el punto de partida para el Modelo de Clases, el primero tendr una
consecuencia directa sobre el segundo, propagando en este los errores, omisiones o incorrectas
representaciones.

Modelo de Dominio
Nota: Los trminos Modelo de Dominio, Diagrama o Medelo de Clases Conceptuales son
equivalentes, pero no as los trminos Diagrama de Clases Conceptuales y Diagrama de Clases.
El MD es usado como una fuente de documentacin y compresin para el diseo de objetos de
Software y ser un artefacto indispensable para la confeccin de subsecuentes artefactos a crearse
conforme avance el proceso de desarrollo.
Es uno de los Artefactos ms importantes dentro del Anlisis orientado a Objetos. Si bien los Casos
de uso son la herramienta indicada para la captura y especificacin de Requerimientos, estos lo
hacen enfatizando el anlisis de los procesos incluidos en el Dominio.
1

El MD tiene como intencin principal explicar cuales son los conceptos principales en el Dominio
del Negocio que se est Analizando.
Defincin Clave (Larman)

1
Craig Larman UML y Patrones - 2da Edicin

Modelo de Dominio -
Versin: 1.0
UTN FRR


Un Modelo de Dominio es una representacin de las clases conceptuales del mundo real, NO de componentes
de Software.

Metfora de la Foto:
Como ya se expres ms arriba, el MD es parte de la Vista Esttica del UML.
Consecuentemente, el MD brinda una visin esttica del Negocio, es como si un momento
determinado le sacramos una foto a la empresa u organizacin en estudio y en ella pudiramos ver
todos los conceptos significativos y la relacin entre los mismos.
Todas las organizaciones son intrnsecamente dinmicas, por lo cual, el anlisis de los procesos
llevados a cabo en la misma nos permitirn encontrar cuales son los conceptos significativos en cada
uno, pero sin perder de vista que el cometido del MD no es el modelado de los procesos, (existen
otras herramientas para tal fin) sino el de los Conceptos intervinientes en cada uno de ellos, su
estructura interna y la relacin entre ellos.

Un Modelo Una Abstraccin Otra vez la metfora de la foto.
Al definir el MD, lo que estamos haciendo es plasmar de un modo grfico, una abstraccin o
simplificacin de la realidad, una realidad que siempre ser, inevitablemente, en todo su
alcance, mucho ms compleja e infinita.
Si nos sentamos frente a una computadora conectada a Internet y visualizamos cualquier
ciudad del mundo con el Google Map, ser sencillo apreciar que el nivel de detalle de lo que
alcancemos a ver en la foto, va a depender de la altura desde la cual la mires.
Ese mayor o menor nivel de detalle es el punto correcto a encontrar para nuestro modelo y
va a depender del inters necesario resultante para la comprensin del Negocio y los
requerimientos a cumplir.

Nada es gratis, y generalmente todo aporta.
El mayor y menor detalle compiten en los siguientes resultados:

Menor Detalle Mayor Detalle
Mas Simple
Mas Barato
Menor adaptabilidad y crecimiento

Mas Complejo
Mas Costoso
Mayor Adaptabilidad y crecimiento

Lo bueno si breve, dos veces bueno.

Un punto muy importante que debe tenerse en cuenta y que muchas veces los autores no
aclaran, probablemente por parecer demasiado obvio, es que el Modelo de Dominio debe
realizarse con una mirada prctica e Ingenieril, abordando aquellos conceptos que son
claramente o con algn grado de probabilidad, pasibles de ser virtualizados e includos en un

Modelo de Dominio -
Versin: 1.0
UTN FRR


sistema Informtico, generando con ello un valor agregado de consideracin, sin complicar
por el contrario, un modelo que se pretende, sea lo ms simple posible.

Elementos de UML utilizados en la representacin del Modelo de Dominio
Utilizando el UML como herramienta de modelado, los conceptos principales que bsicamente
vamos a plasmar en el MD son:
Clases Conceptuales
Asociaciones
Atributos

QUE ES UNA CLASE CONCEPTUAL ?

Sin duda que de todos los elementos intervinientes en un MD, el mas representativo y el punto de
partida para la construccin del mismo es el de Clase Conceptual.

Analicemos un poco el trmino Clase Conceptual
Clase: Lo tomamos por su signicado de clasificacin, tipificacin, patrn.
Conceptual: Por su sentido de Concepto, idea, definicin

Antes que nada vamos a aclarar e insistir en la idea de que las clases conceptuales pueden
representar tanto objetos fsicos y tangibles como una Persona o Producto como asi tambin
objetos abstractos como un Servicio, Contrato o Comprobante y muchas veces ser necesario
utilizar mas de una Clase para representar un Concepto.

En cualquier negocio u organizacin o sistema vamos a encontrar infinidad de objetos, tanto fsicos-
tangibles o abstractos que responden a una estructura o patrn comun, con las mismas o muy
similares caractersticas.
En esta linea, por ejemplo, si analizamos los personas que forman parte de la facultad vamos a
encontrar que algunas de ellas, sern Docentes, otras Alumnos y otras podrn ser ambas cosas,
como asi tambin todas ellas son Personas y todas son objetos fsicos.
De igual manera si analizamos las carreras que se cursan en ella encontraremos conceptos como
Plan de Estudios, Materia, Correlatividades, todos ellos objetos abstractos.

La clasificacin de estos objetos en diferentes Clases, segn sus caractersticas comunes es lo que
hacemos cuando escribimos las Clases Conceptuales de un Modelo de Dominio.

Tan simple como cuando un nio que juega con sus pieza de encastre, las separa u ordena de acuerdo
a su forma, tamao y/o diferentes caractersticas, concluyendo luego en que algunas son prismas,
otras son cubos y otras son chatos. (aunque todas ellas sean a su vez piezas de Encastre).

Representacin grfica de una Clase Conceptual:
Las clases conceptuales se respresentan mediante un Rectngulo con dos compartimientos, el
superior contiene el Nombre de la Clase y el inferior los atributos de esta.

Modelo de Dominio -
Versin: 1.0
UTN FRR


Ejemplo de representacin de una Clase Conceptual Persona:

Instancias

Entonces, cual es la diferencia entre una Clase y un Objeto.??

La clase es la definicin conceptual del Objeto con sus atributos o caractersticas, los objetos son la
realizacin o ejemplos concretos de la misma.
Ejemplo: Lengua, Geografa y Matemtica son Objetos (instancias) de la Clase Materia.
A los objetos de una clase los llamamos Instancias.
En algunos casos puede resultar til representar algn objeto particular de una Clase:

QUE ES UNA ASOCIACION?

Cuando describimos una clase conceptual, lo hacemos a traves de sus Atributos.
Por Ejemplo, Cuando describimos la clase Persona, decimos que tiene los siguientes Atributos:

Si analizamos cada uno de sus Atributos, vamos a encontrar que stos (los atributos) pueden a su vez
tener caractersticas propias, por ejemplo la ciudad de Nacimiento de la persona, tiene a su vez un
Cdigo Postal y una Provincia a la que pertenece, si resulta de inters tener conocimiento de ese
detalle y por lo tanto modelar en nuestro MD, entonces este atributo puede (y debe en este caso)
claramente ser subido de jerarqua o ascendido a la jeraqua de Clase Conceptual en si mismo,
con lo que tendramos la clase:

Modelo de Dominio -
Versin: 1.0
UTN FRR


Ahora bien, tenemos la Clase Conceptual localidad, y seguimso teniendo a la localidad de
Nacimiento de las personas como atributo de estas. AQU APARECEN LAS ASOCIACIONES.!

La localidad de Nacimiento de las personas sigue siendo un atributo de estas, o dicho de otra manera,
las personas siguen teniendo una ciudad en la que nacieron, pero el modo de representarlo vara
desde el momento en el que decidimos incluir la Clase Conceptual Localidad en nuestro MD, la
nueva manera de representarlo es a utilizando las asociaciones, por lo cual ahora tenemos:

Ntese que el atributo ciudadNacimiento fue eliminado de la clase Persona, al
agregarse la asociacin.

Antes de entrar a estudiar en profundiad las asociaciones, realicemos un ejercicio mas acerca de lo
que significa ascender de jerarqua un atributo, transformndole en Clase Conceptual.
Supongamos por un momento que analizamos que la Provincia pertenece a un Pais, el Pais a un
Continente, el Contiente a un Planeta y el Planeta a un Sistema Solar, y como estamos pensando
desarrollar un Software adaptable a la futuras colonizaciones espaciales decidimos modelar e incluir
en nuestro MD todos esos conceptos. En tal caso nuestro MD para a ser algo similar a lo siguiente:

Obviamente que esta es una exageracin llevada hasta ese punto, con un simple objetivo didctico,
donde ademas de los ejemplos de la asociaciones, tambin puede verse que el el nivel de detalle de
nuestro modelo va a depender del nivel de detalle de lo que nos interese y necesitemos modelar.

Modelo de Dominio -
Versin: 1.0
UTN FRR


En definitiva, cas cualquier atributo es potencialmente una clase, incluso el atributo Apellido
podramos jerarquizarlo como clase si por ejemplo, necesitramos o quisiramos conocer el origen
del mismo,
En tal caso, dejando los planetas de lado, podramos tener:

Caractersticias de las Asociaciones:

Hay varias caractersticas de las asociaciones que debemos indicar:

Nombre: Texto que aclara el porqu de la vinculacin entre las clases.

Persona y Localidad pueden tener muchas asociaciones entre si.
Una persona puede haber nacido en una localidad, pero actualmente estar viviendo en otra.
Por lo cual, es claramente distinto indicar:

Que indicar:

Ahora bien, es totalmente aceptable que dos clases tengan ms de una asociacion entre si, por lo cual
ambos modelos anteriores pueden ser representados como:

Modelo de Dominio -
Versin: 1.0
UTN FRR


Direccin de lectura: Direccin sugerida en la que debe leerse la asociacin entre las clases.
En el ltimo ejemplo, es claro leer, que:
Una Persona est domiciliada en una Localidad

Pero sera absolutamente incoherente leer
Una Localidad esta domiciliada en Persona

Si podramos decir en cambio que
Una Localidad est habitada por Personas

Las asociaciones son intrnsecamente bidireccionales, esto quiere decir que por lo general cobran
algn sentido semntico prctico en ambas direcciones, pero como el nombre que exprese ese
significado puede ser distinto segn el sentido de lectura, el calificador de direccin de lectura, nos
indica en que orden debe leerse la asociacin de acuerdo al nombre establecido para la misma.

Multiplicidad: La Multiciplidad tambin es Bidireccional, por lo cual debe calificarse en
ambos sentidos.

Definicin de Multiplicidad:
Dadas una Clase Conceptual A y una Clase Conceptual B vinculadas por la asociacin S:
Si tomo una (solo una) instancia de la Clase Acuantas instancias de la Clase B puedo llegar a
encontrar vinculadas por la asociacin S?

Y luego:

Si tomo una (solo una) instancia de la Clase B, cuantas instancias de la Clase A puedo llegar a
encontrar vinculadas por la asociacin S?

Volviendo al ejemplo de las personas y las localidades

Debemos leer: Una persona est domiciliada en una localidad.
Y
Una Localidad est habitada por ninguna o muchas personas

Roles: Hay situaciones en las cuales una clase puede tomar un papel (rol) particular en una
asociacin.

Modelo de Dominio -
Versin: 1.0
UTN FRR


Supongamos por ejemplo que queremos reflejar el hecho de que una localidad est habitada por
personas y que en el caso de que la localidad sea un Municipio, este estar ademas, conducido
por un Intendente.
Hay un par de maneras correctas de modelar esta situacin, una de ellas es la Herencia o
Generalizacin que veremos mas adelante y otra es el empleo de Roles en las Asociaciones.

Veamos como quedara esta situacin empleando Roles en las asociaciones:

Lo que estamos indicando es que existen Personas que tienen una caracterstica especial
que es la ser Intendentes de Localidades que a su vez, algunas de ellas (las Localidades)
tienen la particularidad poltica de ser consideradas Municipios.

Tipos Particulares de Asociaciones:

Existen algunos tipos particulares de asociaciones:

Binarias Simples: las que hemos visto hasta ahora.
Recursivas: Asociacin entre Instancias de una misma clase.
Herencia o Generalizacin
Agregacin: asociaciones que responden al patrn de: es parte de y ..esta compuesta
por ..
Composicin: Agregacin Fuerte

Asociacin binaria simple:
Son el tipo de asociaciones que vimos hasta ahora, donde dos Clases independientes una de otra
comparten un vnculo.

Asociacin Recursiva:
Es muy comn el caso en que una Clase Conceptual est relacionada con si misma.
Ejemplo:

Modelo de Dominio -
Versin: 1.0
UTN FRR


En las relaciones recursivas suele tornarse fundamental la utilizacin de roles. (Ver polticas
de la Ctedra)

Herencia o Generalizacin: (Tipos y Supertipos)

La Herencia o Generalizacin es uno de los Conceptos mas fuertes y tiles de la Teoria de Anlisis y
Programacin orientada a objetos.
La Herencia me permite establecer asociacines del tipo: ..es un/una , mediante las cuales,
establecer una jerarqua de clases de manera tal de poder reflejar mas fielmente la realidad a la vez
que consigo un modelo mas simple y mantenible.

Volviendo al ejemplo de la Localidad, los Municipios, los Intendentes y los Habitantes, podemos
modelar eso mismo utilizando Herencia de la siguiente manera:

Nota: las asociaciones de herencia del ejemplo deben leerse como:
Intendente es una persona
Municipio es una localidad

Cuando se definie una asociacin de Herencia hay una Clase mas General (Padre o Supertipo) y una
o mas clases (hijas o Subtipos) que especializan esa clase. Los atributos de la Clase Padre son
heredados (los poseen sin necesidad de redefinirlos) automticamente por las clases hijas, luego
estas pueden tener nuevos atributos (por eso se dice que especializan) que no perteneceran a la
clase padre.

Modelo de Dominio -
Versin: 1.0
UTN FRR


Cuando conviene Generalizar y/o Especificar Clases:

Vease Larman UML y Patrones Cap. 28. Generalizacin.

Clases Asociativas :

Cuando estudiamos las clases y sus atributos vimos que potencialmente, casi cualquier atributo
puede ser jerarquizado y tomado como Clase.
Algo similar sucede con las asociaciones.
En ciertas circunstancias muy comunes, surge la necesidad o el inters de conocer caractersticas o
atributos que son propios de la asociacin.
Como no tenemos la posibilidad de definirle atributos a las asociaciones, es que surge un tipo
especial de Clase Conceptual que es la Clase Asociativa, que como su nombre lo indica es una
combinacin de Clase y Asociacin.

Volvamos al Ejemplo:

Esta asociacin nos est indicando que un Municipio es conducido por un Intendente, ahora bien,
es probable que sea de inters, conocer por ejemplo, el perodo de Mandato del Intendente, la
clase asociativa nos permite modelarlo de la siguiente manera:

Nota: la clase asociativa se identifica visualmente con una lnea entrecortada que se une a la
asociacin original.

Una caracterstica identificatoria de las Clases Asociativas es que la Tupla de las Instancias que
asocia debe si o si existir previo a la instancias de la Clase Asociativa, es decir, en el ejemplo
anterior, previo a poder crear una instancia de la clase Mandato, las respectivas instancias de las
Clases Conceptuales Intendente y Municipio deben existir, o dicho por la negacin, no se puede
crear un objeto Mandanto sin saber de que Intendente y Localidad estamos hablando.

Debe tenerse en claro que la multiplicidad representada en la Clase Asociativa es la multiplicidad
pre-existente entre las Clases Conceptuales originales, no entre las Clase asociativa y cada una de las
Clases asociadas.

Modelo de Dominio -
Versin: 1.0
UTN FRR


Por definicin de la Clase Asociativa, no puede existir ms de una instancia en la Clase Asociativa
que asocie a la misma tupla de instancias de las Clases que asocia.
En el ejemplo anterior, un intendente no podra tener ms de un mandato en un mismo municipio.
Para resolver esta situacin, el UML 2.0 agreg la posibilidad de incluir el calificador {bag} (bolsa),
a ambos extremos de la asociacin, para indicar que puede haber mas de una instancia de la clase
asociativa que asocie a la misma tupla de instancias.

Clase Asociativas n-arias
Las Clases Asociativas pueden asociar mas de dos clases.

Agregacin y Composicin :

Hay un tipo de Asociacin muy comn que es la de Parte-Todo.

A es una parte de B o B est Compuesto por A

El todo es el Compuesto, formado por las partes.

Esta relacin de Composicin puede darse tanto en ensambles fsicos como de relacin.
Por lo General ls ensambles fsicos son Composiciones.
De los ensambles de relacin podemos encontrar tanto agregaciones como tambin composiciones.

Un ejemplo muy clsico de Composicin es el del Cbte y las lineas del Detalle del Cbte.

Si quisiramos modelar las ciudades que componen el itinerario de un circuito turstico podramos
modelar utilizando una relacin de Agregacin como:

Modelo de Dominio -
Versin: 1.0
UTN FRR


En la Composicin (diamante lleno), la multiplicidad del lado del Compuesto es siempre 1, una linea
de Comprobante solo puede pertenecer a un comprobante, en la Agregacin en cambio, la
multiplicidad del lado del Cbte puede ser de 0 a muchos, una ciudad podr estar incluida en ninguno
o mucho itinerarios, esta una diferencia distintiva entre ambos tipos de relaciones.

La otra diferencia fundamental entre la Composicin (tambin conocida como agregacin fuerte) y
la Agregacion, radica en la interdependencia de las instancias de las clases asociadas.
En la Composicin, la relacin mas fuerte de todas, las instancias del lado de la parte, tienen su
tiempo de vida, atado, al tiempo de vida del compuesto, es decir, si se borrara el Cbte todas las
lineas que lo componen desaparecen junto con el.
En la Agregacin en cambio, la instancias del lado de la parte, son independientes del Todo, pueden
incluso crearse y nunca ser agregadas a ningn compuesto.

Atributos:
Por ltimo vamos a ser mencin directa, (ya los venimos mencionando) a los Atributos.
Los atributos componen la especificidad de cada clase. Sus caractersticas, su estructura, su
conformacin.
Los atributos que inclumos de cada Clase Conceptual, son aquellos de interes y que resultan
necesarios tanto para el entendimiento como para el conocimiento de las instancias (objetos) de la
Clase.

Dos caracterstcas vamos a nombrar respecto de los Atributos:

Multiplicidad:
Al igual que las asociaciones los atributos tienen multiplicidad. Una persona puede tener varios
Nmeros telefnicos y puede ser que no tenga cuenta de correo electrnico.

Por lo general cuando la multiplicidad es 1 no se la grafica, pero si o si, debe modelarse cuando esta
sea mayor a uno o igual a cero.

En este ejemplo estamos indicando que una persona puede tener ms de un
telfono y puede o no tener email.

Atributos Derivables o de Clculo:
Existen atributos cuyo valor puede ser calculado partiendo del valor de otros atributos de la misma
instancia o de otras instancias de la misma u otras clases.
En tal caso puede resultar til para una mejor comprensin incluir estos atributos, al hacerlo, debe
indicarse que son atributos derivados con una barra invertida.

Modelo de Dominio -
Versin: 1.0
UTN FRR


Esta definicin est intimamente relacionada con el concepto de persistencia que escapa a esta
etapa de modelado del dominio, pero que debe ser comprendida para entender el porqu de los
Atributos (o asociaciones) derivados.
La persistencia es el proceso de conservar las instancias (objetos) de la clase, generalmente
guardando la informacin de estos en bases de datos o serializando los mismos en archivos de
diferentes tipos.
Al indicar atributos como derivados estoy previendo que los mismos no deben ser persistidos, sino
calculados en el momento de instanciar los objetos de la clase.
Supongamos para el ejemplo, que necesito conocer la edad de las personas en cualquier momento.
Dado que la edad puede calcularse a partir de la fecha de nacimiento, entonces podemos modelar
de la siguiente manera:

Asociaciones Derivadas
El concepto de Atributos derivados tambin puede ser extensivo a las asociaciones.
Existen asociaciones que pueden ser calculadas a traves del valor de algun atributo.
Si bien no es necesario agregar estas asociaciones al Modelo de Dominio, en ocasiones puede ser
de utilidad para una mejor comprensin del mismo (asociaciones de comprensin)

Modelo de Dominio -
Versin: 1.0
UTN FRR


Resumen:
Elementos de UML utilizados en la representacin del Modelo de Dominio
Utilizando el UML como herramienta de modelado, los elementos grficos que bsicamente vamos a
utilizar en el MD son:
Clases Conceptuales
Asociaciones
Atributos
De cada uno de estos elementos vamos a indicar:
Elemento Caractersticas
Clase Nombre
Atributos
Clase Asociativa

Asociaciones: Nombre
Clases que asocia
Tipo de Asociacin (simple, composicin, agregacin, herencia)
Direccin de Lectura
Multiplicidad
Roles
Asociaciones Derivadas

Atributos Nombre
Multiplicidad
Atributos Derivados

Modelo de Dominio PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Modelo de Dominio PDF

Caricato da

Copyright:

Formati disponibili

Modelo de Dominio -

Autor: Juan Pablo Beltramone

Potrebbero piacerti anche