CUARTA UNIDAD

EL MODELADO DE DOMINIO

¿Qué es el modelado de dominio?

¿Qué es un diagrama de clases?
¿Cuáles son sus elementos? y
¿Cómo se construye?

1
Lección 8

Conceptos asociados al modelo de dominio

En el contexto de desarrollo de sistemas de información, es frecuente, en las primeras
etapas del proceso, construir un modelo del dominio del problema para representar las
propiedades más importantes del ámbito del negocio relacionado con el problema.
Una técnica muy utilizada para representar este modelo de domino es el diagrama de clases
de UML; precisamente, en esta lección se describen las bases conceptuales para construir
adecuadamente un diagrama de clases.

8.1 Clase y Objeto

Un objeto se define como un concepto, abstracción o cosa con límites bien definidos y
con significado para el problema que se tenga entre manos. Una clase describe un conjunto
de objetos con propiedades similares, relaciones comunes con otros y una semántica
común (Rumbaugh, 1996).
Por ejemplo, “Análisis de sistemas”, “Base de datos I”, “Estadística II”, “Matemática
Básica I” son objetos de la clase ASIGNATURA, en otras palabras, ASIGNATURA representa
al conjunto de todas las asignaturas en el dominio de la gestión académica de una
institución educativa.

8.2 Atributo
Una clase tiene una serie de características o propiedades, por ejemplo ASIGNATURA
tiene código, nombre, créditos, horas de teoría, horas de practica; a estas propiedades se
le conoce como atributos de la clases. Un atributo es una propiedad de una clase que
describe un rango de valores que la propiedad podrá contener en los objetos de la clase
(Rumbaugh, 1996)..
Podemos decir que una clase representa un conjunto de objetos con las mismos atributos
y un objeto es una instancia de una clase, es decir es una entidad que tiene valores
específicos para cada uno de los atributos de la clase.
Por ejemplo, la clase AUTOMOVIL, tiene como atributos: número de placa, color, modelo,
número de puertas, año, entre otros. Un objeto, de la clase AUTOMOVIL, es el auto de
placa SGD345, color azul, modelo Station Wagon, con cuatro puertas, del año 2000. Otro
objeto es el auto de placa ERG237, negro, deportivo, 4 puertas, año 2009.

8.3 Operación
Una clase tiene un comportamiento que es definido por las operaciones o
responsabilidades que la clase puede realizar. Una operación es algo que la clase puede
realizar o que otra clase puede hacer a una clase. Es una función o transformación que se
puede aplicar o que puede ser aplicada por los objetos de una clase (Rumbaugh, 1996)..
Por ejemplo, algunas operaciones de la clase automóvil pueden ser: Encender, Apagar,
Acelerar, Frenar.

2
8.4 Asociación y Enlace
Las entidades o cosas del mundo real se relacionan con otras entidades; a las relaciones
entre objetos se les llama enlaces y a las relaciones entre clases se les llama asociaciones
(Rumbaugh, 1996).
Mediante la abstracción de asociación se vincula dos o más clases, creándose un
elemento de tipo distinto (Vinculo).
Por ejemplo, “Docente dicta Asignatura”, es una asociación entre la clase docente y la
clase asignatura. “Francisco Ramírez dicta Análisis de sistemas” es un enlace entre los
objetos Francisco Ramírez y Análisis de sistemas.

8.5 Generalización y Agregación

La generalización y agregación son dos tipos especiales de relaciones entre clases
(Rumbaugh, 1996)..
La Generalización representa la relación entre clases, donde algunas de ellas son tipos de
otra. Por ejemplo, las clases SECRETARIA, TÉCNICO, INGENIERO son tipos de la clase
EMPLEADO; en otras palabras, EMPLEADO es una generalización de las clases
SECRETARIA, TECNICO, INGENIERO (ver figura 8.1).
Mediante la generalización se abstrae las características comunes a varias clases
(subclases) para construir una clase más general (superclase), la generalización define una
relación de subconjunto entre elementos de dos o más clases.

Figura 8.1 Ejemplo de generalización

GENERALIZACIÓN
SECRETARIA TECNICO EMPLEADO

INGENIERO
Una Clase ES UN TIPO DE otra

La Agregación representa la relación entre clases, donde algunas de ellas son componentes
de otra. Por ejemplo, las clases CPU, TECLADO, MOUSE, MONITOR son componentes de la
clase COMPUTADORA; en otras palabras, la clase COMPUTADORA está formada por las
clases CPU, TECLADO, MOUSE Y MONITOR (figura 8.2).
Mediante la agregación se construye una nueva clase o tipo o categoría de objetos a
partir de un conjunto de otras clases denominadas componentes o partes. La agregación
define una nueva clase de objetos a partir de un conjunto de clases (otras, no
necesariamente distintas) que representan sus partes componente.
Figura 8.2 Ejemplo de Agregación

CPU AGREGACIÓN
MOUSE
COMPUTADOR
MONITOR
TECLADO

Una Clase ES PARTE DE otra clase

3
8.6 ¿Qué es el modelo de domino?
El Modelo de dominio es un modelo conceptual que muestra clases conceptuales de
objetos significativos en un dominio de problema. Las clases conceptuales no muestran
componentes software, ni clases software, ni responsabilidades (Larman, 1999).
Por ejemplo, algunas clases conceptuales del dominio de la Gestión Académica son:
ALUMNO, DOCENTE, ASIGNATURA y HORARIO.
El modelo de dominio se puede documentar con un Diagrama de Clases.

8.7 ¿Qué es el diagrama de clases?

Un diagrama de clases es un tipo de diagrama estático del UML, que describe la
estructura de un sistema mostrando sus clases y sus relaciones. En la figura 8.1 se observa
un ejemplo de diagrama de clase simplificado para una Tienda de ventas. Se muestra clases
conceptuales y relaciones entre ellas; cada clase tiene un nombre y una serie de atributos.
Las relaciones se conocen como asociaciones, cada una de ellas tiene un nombre y su
multiplicidad.
La interpretación o lectura de un diagrama de clases permite a desarrolladores y usuarios
disponer de un lenguaje uniforme para mostrar características del negocio en el dominio
del problema. Por ejemplo, en la figura 8.3, podemos leer la siguiente restricción
semántica: “una línea de venta está contenida en una venta y esta puede contener
muchas líneas de venta, nunca ninguna línea de venta”. Además, “cada línea de venta
registra la venta de un artículo y un artículo puede o no estar en una línea de venta”.
Figura 8.3 Ejemplo de diagrama de Clases
c onc epto u LineaDeV enta Regis tra-venta-de
objeto del A rtíc ulo
c antidad
dominio 0..1 1
*
1..n

as oc iación Conteni da-en A l ma cenado- en

1
1 Tienda
atributos V enta direc c ión
tienda
fec ha
hora

1 1
1 Capturada-en
A lb erga
P agada-m edian te 1
1.. *
1 Registro
P ago
cantidad

Fuente: (Larman, 1999)

8.8 Notación UML para modelo de domino

Clase
Para efectos del modelo de dominio, una clase puede considerarse en términos de:
Símbolo, palabras o imágenes que representan a la clase;
Definición del concepto, descripción textual del significado de la clase y
Extensión: conjunto de objetos que pertenecen a la clase.
Por ejemplo, considere la clase Venta del diagrama de clases de la figura 8.4.

4
El símbolo del concepto es un rectángulo dividió en tres partes, la primera es el nombre
de la clase, la segunda los atributos y la tercera las operaciones.
Figura 8.4 Clase

Venta
fecha
hora

La definición del concepto es: Una venta representa el hecho de una transacción de
compra, sucede un día y en una hora.
La extensión es el conjunto de todas las ventas realizadas en la tienda.

Atributo
Para efectos del modelo de dominio se incluyen aquellos atributos para los que los
requisitos indican la necesidad de registrar su información.
Por ejemplo, un recibo recoge la información de una venta, incluyendo fecha y hora. La
Gerencia de la Tienda quiere conocer fecha y hora de las ventas, la clase Venta necesita
los atributos fecha y hora.
Según la notación UML, los atributos se muestran en el segundo compartimento del
rectángulo de la clase.
Figura 8.5 Atributos

Venta
fecha
hora

Asociación
La asociación se representa con una línea que une las clases relacionadas. En el siguiente
ejemplo, se muestra la relación entre las clases ALUMNO y FACULTAD; la semántica
señala que un alumno pertenece a una única facultad y una facultad tiene muchos
alumnos.
Figura 8.6 Asociación

En una asociación se incluye, opcionalmente, el nombre de la asociación, la

navegabilidad, y obligatoriamente, la multiplicidad. La navegabilidad se representa con
una flecha que indica la dirección de envío de mensajes de un objeto a otro. La
multiplicidad es la cantidad de objetos de una clase que está vinculado con un objeto de
la clase asociada.
Por ejemplo, en la figura 8.6, el nombre de la asociación es: Pertenece a. La multiplicidad
de la asociación es de “uno a muchos”; significa “Un objeto de alumno está vinculado con

5
un solo objeto de Facultad, y un objeto de Facultad está vinculado con varios objetos de
ALUMNO”.
La multiplicidad permite representar, en el diagrama de clases, las reglas del negocio
definidas en el dominio del problema. Las categorías típicas de multiplicidad son: “Uno a
Uno”, “Uno a Muchos” y “Muchos a Muchos”. En la figura 8.7 se aprecia algunos tipos de
multiplicidad.
Figura 8.7 Tipos de multiplicidad

Clase-Asociación
En algunas ocasiones es necesario representar propiedades propias de la asociación; para
tal efecto, se crea una clase especial llamada Clase-Asociación. Por ejemplo,
consideremos la asociación ALUMNO matriculado en ASIGNATURA, la multiplicidad de
esta asociación es de “muchos a muchos”, en efecto, un alumno puede llevar varias
asignaturas y una asignatura es llevada por varios alumnos. Entonces, la nota promedio
de un alumno en una asignatura corresponde a la asociación; pues si se coloca como
atributo de alumno, no se sabría de qué asignatura es; si se coloca como atributo de
asignatura, no se sabría de qué alumno es, entonces, se crea una clase especial llamada
clase asociación MATRICULA en el que se coloca el atributo nota promedio.
La representación de una clase asociación se hace con una línea discontinua que une la
asociación con la clase generada. (figura 8.8).
Figura 8.8 Ejemplo de Clase-Asociación

Generalización

6
La generalización se representa a través de una línea recta entre las clases subtipos
terminados en un triángulo blanco en el extremo cercano a la clase generalizada. Por
ejemplo, en la figura 8.9, ANFIBIO, MAMÍFERO y REPTIL son tipos de ANIMAL. A su vez,
CABALLO es un tipo de MAMÍFERO.
La Generalización puede encontrarse en aquellas clases que tienen ciertos atributos y
operaciones en común. En ese caso se crea una clase nueva que asume dicho
comportamiento común.
Figura 8.9 Ejemplo de Generalización

Agregación
La agregación se representa a través de una línea recta entre las clases “partes” terminados
en un rombo en el extremo cercano a la clase “todo”. Por ejemplo, en la figura 8.10,
MONITOR, CASES, TECLADO y MOUSE son partes o componentes de COMPUTADORA. A su
vez, CASES está formado por CPU, RAM,VENTILADOR.
Figura 8.10 Ejemplo de Agregación

7
Lección 9

Proceso de construcción del modelo de dominio

Muchos de las clases del dominio pueden obtenerse de una especificación de requisitos o
mediante la entrevista con los expertos del dominio. Las clases del dominio aparecen en
tres formas distintas (Jacobson, 2000):
Objetos del negocio que representan cosas que se manipulan en el negocio, como
pedidos, cuentas, contratos, y facturas.
Objetos del mundo real y conceptos de los que el sistema debe hacer un
seguimiento, como la aviación enemiga, misiles y trayectorias.
Sucesos que ocurrirán o han ocurrido, como la llegada de un avión, sus salidas y la
hora de la comida.
Para construir el modelo de dominio se puede seguir las siguientes actividades: Identificar
las Clases conceptuales o del dominio, Identificar las asociaciones, Identificar atributos,
Identifica relación de generalización y refinar el modelo.
Consideremos la siguiente descripción para realizar el modelo de dominio.

Una empresa recién formada se dedica a integrar partes para formar productos con la intención
de vender el valor agregado de la integración. Con el objetivo de apoyar sus actividades,
mediante una aplicación informática, se ha obtenido las siguientes reglas semánticas:
Un producto tiene un nombre y un precio base. Un producto se forma con muchas partes y
cada parte puede formar muchos productos. La definición de cada producto especifica qué
cantidad de cada parte forma a un producto dado.
Un vendedor tiene un apellido, nombre y un porcentual de comisión. Tanto un cliente como un
proveedor tienen los datos de todo agente comercial; éstos son: cuit, razón social, e-mail,
teléfono y dirección. Además, un proveedor tiene un plazo de pago y un cliente un porcentual
de descuento.
Un parte puede ser comprado a muchos proveedores y un proveedor puede proveer muchas
partes. Cada compra de un parte tiene una fecha y una cantidad. Una venta se realiza entre
cualquier vendedor y cualquier cliente, y éste puede comprar cualquier producto. De una
venta se quiere saber su fecha.
No se pueden vender productos que estén formados por una única parte, esto es, no se
permite vender productos sin elaborar.

9.1 Identificando Clases

Se seleccionan los nombres o sustantivos de la descripción del problema como posibles
clases candidatas. Se construye una lista de clases candidatas. Se eliminan, de esa lista, las
clases redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o
construcciones de implementación.
En nuestro ejemplo las clases conceptuales identificadas son:
producto parte vendedor cliente proveedor agenteComercial

8
9.2 Identificando Asociaciones
Se establecen las asociaciones según las reglas del negocio en el dominio del problema, se
puede considerar como estrategia para identificar asociaciones la selección de verbos en
la descripción del problema. Se le agrega la multiplicidad correcta. También se puede
representar la relación " es parte de" o agregación.
En nuestro caso, las asociaciones identificadas son:
producto 1..n se forma 1..n parte
vendedor

1..n 1..n

se vende
agenteComercial Se compra

1..n
1..n
cliente
proveedor

9.3 Identificar Atributos

Por cada clase se indican los atributos necesarios que respondan a los requerimientos del
dominio del problema. Si los atributos corresponden a una asociación, crear una clase
asociación.
En nuestro ejemplo, se señalan los atributos por cada clase y adicionalmente, se
identifican atributos para las algunas asociaciones, creándose las clases asociación
Definición, compra y venta.

vendedor producto parte

nombre 1..n se forma 1..n numParte
apellido
nombre precioBase descripción
porcComis
1..n definición 1..n
1 cantidad
participa
se vende
0..n compra
Se compra fecha
venta agenteComercial
cantidad
fecha cuit
razSocial
email
telf
direcc

1..n 1..n
cliente proveedor
porcDesc plazoPago

9
9.4 Identificar relaciones de generalización
Se organiza y simplifica el modelo usando el principio de herencia; es decir, se puede
generalizar los aspectos comunes de las clases existentes construyendo una superclase, o
se puede especializar una clase en varias subclases.
Para nuestro ejemplo se establece relación de generalización entre agente comercia con
cliente y proveedor:

vendedor producto parte

nombre 1..n se forma 1..n numParte
apellido
nombre precioBase descripción
porcComis
1..n definición
1 1..n
cantidad
participa
0..n se vende compra
venta fecha
agenteComercial Se compra
cantidad
fecha cuit
razSocial
email
telf
direcc

1..n
1..n
cliente proveedor
porcDesc plazoPago

9.5 Refinar el modelo

Se valida que el diagrama responda a los requerimientos. Se itera y refina el modelo hasta
que esté completo; es decir, hasta que cumpla todos los requerimientos señalados en la
descripción del problema.

10
Resumen

Conceptos asociados al modelo de dominio

Un objeto se define como un concepto, abstracción o cosa con límites bien definidos y con
significado para el problema que se tenga entre manos.
Una clase describe un conjunto de objetos con propiedades similares, relaciones comunes con
otros y una semántica común
Un atributo es una propiedad de una clase que describe un rango de valores que la propiedad
podrá contener en los objetos de la clase
Un enlace es una relación entre objetos
Una asociación es la relación entre clases
La multiplicidad es la cantidad de objetos de una clase que están vinculados con un objeto de la
clase asociada.
La Generalización representa la relación entre clases, donde algunas de ellas son tipos de otra
La Agregación representa la relación entre clases, donde algunas de ellas son componentes de otra
El Modelo de dominio es un modelo conceptual que muestra clases conceptuales de objetos
significativos en un dominio de problema
Un diagrama de clases es un tipo de diagrama estático del UML, que describe la estructura de un
sistema mostrando sus clases y sus relaciones
En algunas ocasiones es necesario representar propiedades propias de la asociación; para tal
efecto, se crea una clase especial llamada Clase-Asociación

Proceso de construcción de modelo de dominio

Identificar clases
Identificar asociaciones
Identificar atributos
Identificar relaciones de generalización
Refinar el modelo

11
Lectura
Desarrollo de un modelo de dominio (*)
El modelado de dominio se realiza habitualmente en reuniones organizadas por los analistas del
dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. Para
formar un equipo eficaz, estas reuniones deberían incluir tanto a expertos del dominio como a gente
con experiencia en modelado.
El objetivo del modelado del dominio es com prender y describir las clases más importantes
dentro del contexto del sistema. Los dominios de tamaño moderado normalmente requieren
entre 10 y 50 de esas clases. Los dominios más grandes pueden requerir muchas más.
Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se
guardan como definiciones en un glosario de términos, de otra manera, el modelo de dominio se
hará demasiado grande y requeriría más esfuerzo del necesario para esta parte del proceso.
Algunas veces, como en los dominios del negocio muy pequeños, no es necesario desarrollar un
modelo de objetos para el dominios; en su lugar, puede ser suficiente un glosario de términos.
El glosario y el modelo de dominio ayudan a los usuarios, clientes, desarrolladores, y otros
interesados a utilizar un vocabulario común. La terminología común es necesaria para compartir
el conocimiento con los otros. Cuando abunda la confusión, el proceso de ingeniería se hace
difícil, si no imposible. Para construir un sistema software de cualquier tamaño, los ingenieros de
hoy en día deben “fundir” el lenguaje de todos los participantes en uno solo consistente.
Por último, es necesario una llamada de atención sobre el modelo de dominio. Puede ser bastante
fácil el comenzar modelando las partes internas de un sistema y no su contexto. Por ejemplo,
algunos objetos del dominio podrían tener una representación inmediata en el sistema, y algunos
analistas del dominio podrían a su vez caer en la trampa de especificar los detalles relativos a esta
representación. En casos como éstos, es muy importante recordar que el objetivo del modelado
del dominio es contribuir a la comprensión del contexto del sistema, y por lo tanto también
contribuir a la comprensión de los requisitos del sistema que se desprenden de este contexto. En
otras palabras, el modelado del dominio debería contribuir a una compresión del problema que
se supone que el sistema resuelve en relación a su contexto. El modo interno por el cual el
sistema resuelve éste problema se trata en los siguientes flujos de análisis, diseño e
implementación.

(*) Jacobson (2000)

12
Actividades
Desarrollar el modelo de dominio para el siguiente caso

Una Institución Educativa ha decidido brindar unos cursos extracurriculares, tanto

para sus alumnos como para personas externas a la Institución. Las razones para la
inclusión de personas no pertenecientes a la Institución son: obtener fondos para la
modernización de las instalaciones y ayudar al pago de los viáticos de los
profesores invitados.
Se desea desarrollar una aplicación que permita administrar el dictado de los
cursos; una primera aproximación del contexto del negocio es el siguiente:
Se brinda varios cursos. Cada curso tiene un nombre, un cupo máximo y un cupo
mínimo el cual, si no se alcanza, hace que el curso no se dicte. Cada curso es
dictado por un único docente y un docente puede dictar más de un curso. Cada
docente tiene apellidos, nombres, cargo y una dedicación.
A cada alumno se le da un material general, independientemente de la cantidad de
cursos en que se haya inscrito, además de un material particular para cada curso en
el que esta inscrito. Se desea controlar si se le ha entregado, o no, tanto el material
general como los materiales particulares a cada alumno.
Un alumno puede asistir a muchos cursos y cada curso debe tener una cantidad
mínima de inscritos –cupo mínimo- y no sobrepasar el cupo máximo.
De los alumnos internos se debe mantener la información de apellidos, nombres y
número de libreta; de los alumnos externos, apellidos, nombres, número de recibo
–único para todos los cursos-, forma de pago -efectivo, cheque o tarjeta- y monto
pagado.
A cada curso se le asigna una única aula que tiene un nombre, una ubicación y una
capacidad. No puede asignarse un aula a un curso cuyo cupo máximo no entre en la
misma.
También se desea controlar si el alumno va asistir como oyente –no se presenta a
examen ni realiza prácticos- a cada curso en donde se inscribió. Esta información es
útil para que el docente organize el dictado.

13
Autoevaluación
Conteste las siguientes preguntas
1. La diferencia entre clase y objeto es
2. Proporciones una ejemplo de clase con algunos de sus atributos , y tres ejemplos de objetos
de dicha clases
3. Una clase conceptual es
4. La diferencia entre enlace y asociación es
5. La diferencia entre generalización y agregación es
6. El modelo de domino es
7. Un diagrama de clases es
8. La multiplicidad de una asociación representa
9. Una clase-asociación es

Exploración on-line
Portal del producto IBM Rational Modeler
http://www-01.ibm.com/software/awdtools/modeler/

Pagina de Craig larman

http://www.craiglarman.com/wiki/index.php?title=Main_Page

Referencias bibliográficas
Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos.
Mexico D.F. Prentice-Hall Hispanoamericana.
Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT.
Mexico D.F. Prentice Hall Hispanoamericana.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.

14