Professional Documents
Culture Documents
Chinandega
Pbro. y Dr. Toms Ruiz Romero
UACH
Ingeniera de
Software II
Modelo del
Dominio
Ingenieri
a de
Sistemas
Introduccin.
Un modelo del dominio muestra (a los modeladores) clases conceptuales
significativas en un dominio del problema; es el artefacto ms importante que
se crea durante el anlisis orientado a objetos. Este captulo estudia tcnicas
introductorias a la creacin de modelos del dominio. Los siguientes dos
captulos tratarn ms extensamente las tcnicas de modelado del dominio
aadiendo atributos y asociaciones.
La identificacin de un conjunto rico de objetos o clases conceptuales es una
parte esencial del anlisis orientado a objetos, y bien merece la pena el
esfuerzo en relacin con los beneficios durante el trabajo de diseo e
implementacin.
La identificacin de las clases conceptuales forma parte del estudio del dominio
del problema. UML contiene notacin, en forma de diagramas de clases, para
representar los modelos del dominio.
Idea clave
Un modelo del dominio es una representacin de las clases conceptuales del
mundo real, no de componentes software. No se trata de un conjunto de
diagramas que describen ciases software, u objetos software con
responsabilidades.
Modelos del dominio
La etapa orientada a objetos esencial del anlisis o investigacin es la
descomposicin de un dominio de inters en clases conceptuales individuales u
objetos las cosas de las que somos conscientes. Un modelo del dominio es
una representacin visual de las clases conceptuales u objetos del mundo real
en un dominio de inters. Tambin se les denomina modelos conceptuales,
modelo de objetos del dominio y modelos de objetos de anlisis.
Utilizando la notacin UML, un modelo del dominio se representa con un
conjunto de diagramas de clases en los que no se define ninguna operacin.
Pueden mostrar:
Objetos del dominio o clases conceptuales.
Asociaciones entre las clases conceptuales.
Atributos de las clases conceptuales.
Por ejemplo, la figura siguiente muestra un modelo del dominio parcial. Ilustra
que las clases conceptuales Pago y Venta son significativas en este dominio,
que un Pago est relacionado con una Venta de un modo que es significativo
hacer notar, y que una Venta tiene una fecha y una hora. Los detalles de la
notacin no son importantes en este momento.
Evitar
Artefactos software, como una ventana o una base de datos, a menos
que el dominio que se est modelando sea de conceptos software, como
un modelo de interfaces de usuario grficas.
Responsabilidades o mtodos.
Registro
Venta
Ejemplos
Registro
EspecificacionDelProducto
Tienda
Venta
LineaDeVenta
Cajero
Tienda
Articulo
SistemaAutorizacionPagoCr
edito
DepartamentoDeVentas
Venta, Pago
Ejemplos
VentaDeUnProducto
PoliticaDereintegro
CatalogoDeProductos
Recibo, LibroMayor
LineaDeCredito
Stock
ListaDeCambiosDePreciosDi
arios
EspecificacionDelProducto
LineaDeVenta
Cajero
Cliente
Encargado
O?
Venta
Tienda
numeroTelefono
Articulo
Tienda
Venta
Linea
DeVenta
Cajero
Cliente
Encargado
Pago
Catalogo
DeProductos
Especificacin
DelProducto
Aadir Asociaciones
Criterio para asociaciones tiles
Las asociaciones que merece la pena registrar, normalmente, implican
conocimiento de una relacin que es necesario conservar durante algn tiempo
podra ser milisegundos o aos, dependiendo del contexto. En otras
palabras, entre qu objetos necesitamos mantener en memoria una relacin?
Por ejemplo, necesitamos recordar qu instancias de LineaDeVenta estn
asociadas con una instancia de Venta? Sin ninguna duda, de otra manera no
sera posible reconstruir una venta, imprimir un recibo o calcular el total de la
venta.
Considere la inclusin de las siguientes asociaciones en un modelo del
dominio:
Asociaciones de las que es necesario conservar el conocimiento de la
relacin durante algn tiempo (asociaciones necesito-conocer).
Asociaciones derivadas de la Lista de Asociaciones Comunes.
Por el contrario, necesitamos recordar una relacin entre la Venta actual y un
Encargado? No, los requisitos no dan a entender que se necesite ninguna
relacin de este tipo. No es incorrecto mostrar una relacin entre una Venta y
un Encargado, pero no es convincente o til en el contexto de nuestros
requisitos.
Este es un punto importante. En un modelo del dominio con n clases del
dominio diferentes, pueden existir n (n-l) asociaciones entre diferentes clases
conceptuales un nmero potencialmente grande. Muchas lneas en un
diagrama aadirn ruido visual y lo har menos comprensible. Por tanto, sea
cuidadoso al aadir lneas de asociacin. Utilice como criterio las guas que se
sugieren en este captulo.
Localizacin de las asociacioneslista de asociaciones comunes
Comience la inclusin de asociaciones utilizando la lista de la Tabla siguiente.
Contiene categoras comunes que, normalmente, merece la pena tener en
cuenta. Los ejemplos se han extrado de los dominios de ventas
Categora
Ejemplos
LneaDeVenta-Venta
registo-Tienda, Articulo-Estantera
DescrpcionDelArticulo-Catalogo
A es una descripcin de B
A es un lnea de una transaccin o informe de B
DescripcionDelArticulo-Articulo
A se conoce/registra/recoge/informa/cap- tura en B
Venta-Registro
A es miembro de B
Cajero-Tienda
Departamento- Tienda
A utiliza o gestiona B
Cajero-Registro
A se comunica con B
Cliente-Cajero
Cliente-Pago
A es propiedad de B
Registro-Tienda
Venta-Cliente, Venta-Tienda
Pago-Venta
LineaDeVenta-LineaDeVenta
Roles
Cada extremo de una asociacin se denomina rol. Los roles pueden tener
opcionalmente:
Nombre.
Expresin de multiplicidad.
Navegabilidad.
La multiplicidad se presenta a continuacin.
Multiplicidad
La multiplicidad define cuntas instancias de una clase A pueden asociarse
con una instancia de una clase B
Por ejemplo, una instancia individual de una Tienda puede asociarse con
muchas (cero o ms, indicado por el *) instancias de Articulo.
10
11
Los nombres de las asociaciones deben comenzar con una letra mayscula,
puesto que una asociacin representa un clasificador de enlace entre las
instancias; en UML, los clasificadores deben comenzar con una letra
mayscula. Dos formatos tpicos e igualmente vlidos para un nombre de
asociacin compuesta son:
Pagado-mediante.
PagadoMedante.
En la Figura siguiente, la direccin por defecto para la lectura de los nombres
de las asociaciones es de izquierda a derecha o de arriba abajo. No se
corresponde con la direccin por defecto en UML, sino que se trata de una
convencin comn.
Asociaciones e implementacin
Durante el modelado del dominio, una asociacin no es una declaracin sobre
el flujo de datos, variables de instancia o conexiones entre objetos en una
solucin software; es una manifestacin de que una relacin es significativa en
un sentido puramente conceptual en el mundo real.
Desde un punto de vista prctico, muchas de estas relaciones se
implementarn generalmente en software como caminos de navegacin y visibilidad (tanto en el Modelo de Diseo como en el Modelo de Datos), pero su
presencia en una vista conceptual (o esencial) de un modelo de dominio no
requiere su implementacin.
Al crear un modelo de dominio, podramos definir asociaciones que no son
necesarias durante la implementacin. A la inversa, podramos descubrir
asociaciones que necesitan implementarse pero que se obviaron durante el
modelado del dominio. En estos casos, el modelo del dominio puede
actualizarse para reflejar estos descubrimientos.
Sugerencia
Deberan actualizarse los anteriores modelos estudiados, como el modelo del
dominio, con las apreciaciones descubiertas durante el trabajo de
implementacin? No se moleste a menos que haya algn uso prctico del
modelo en el futuro. Si es nicamente (como es el caso algunas veces) un
12
CatalogoDeProductos Registra
EspecificacionDelProducto
13
de B
A utiliza o gestiona B
CajeroRegistro
EncargadoRegistro
EncargadoCajero, aunque probablemente no
es aplicable
ClienteCajero
ClientePago
CajeroPago
PagoVenta
A se comunica con B
A est relacionado con una
transaccin B
A es una transaccin
relacionada con otra transaccin
B
A est al lado de B
LineaDeVentaLineaDeVenta
A es propiedad de B o informe
RegistroTienda
de B
14
Comentario
Los requisitos no indican que necesitoconocer o registrar al cajero actual.
Adems, puede derivarse si est presente
la asociacin Registro Usado-por Cajero.
Registro Usado-por
Los requisitos no indican que necesitoCajero
conocer o registrar al cajero actual.
Registro Iniciado-por
Los requisitos no indican que necesitoEncargado
conocer o registrar al encargado que pone
en marcha un Registro.
Venta Iniciada-por Cliente Los requisitos no indican que necesitoconocer o registrar al cliente que inicia una
venta.
Tienda Almacena Articulo Los requisitos no indican que necesitoconocer o mantener informacin del
inventario.
LineaDeVenta Registra- Los requisitos no indican que necesitoventa-de Articulo
conocer o mantener informacin del
inventario.
Ntese que la capacidad de justificar una asociacin en funcin de necesitoconocer depende de los requisitos; obviamente, un cambio en stos como
que se necesite mostrar en el recibo el ID del cajero cambia la necesidad de
recordar una relacin.
Basado en el anlisis anterior, podra justificarse la eliminacin de las
asociaciones en cuestin.
Bibliografia:
UML y Patrones 2da Edicin Craig Larman.
15