You are on page 1of 15

Universidad Autnoma de

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.

Los modelos del dominio no son modelos de componentes software


Un modelo del dominio, como se muestra en la Figura 10.2, es una
representacin de las cosas del mundo real del dominio de inters, no de
componentes software, como una clase Java o C+ +, u objetos software con
responsabilidades. Por tanto, los siguientes elementos no son adecuados en un
modelo del dominio:

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.

Modelos y descomposicin del dominio


Los problemas del software pueden ser complejos; la descomposicin divide
y vencers es una estrategia comn para tratar esta complejidad mediante la
divisin del espacio del problema en unidades fciles de comprender. En el
anlisis estructurado, la dimensin de la descomposicin es por procesos o por
funciones. Sin embargo, en el anlisis orientado a objetos, la dimensin de la
descomposicin es fundamentalmente por cosas o entidades del dominio.
Por tanto, la principal tarea del anlisis es identificar diferentes conceptos en el
dominio del problema y documentar el resultado en un modelo del dominio.
Clases conceptuales en el dominio de ventas
Por ejemplo, en el dominio de ventas en una tienda del mundo real, existen las
clases conceptuales de Tienda, Registro y Venta. Por tanto, nuestro modelo del
dominio, mostrado en la Figura anterior, podra incluir Tienda, Registro y Venta.
Tienda

Registro

Venta

Identificacin de las ciases conceptuales


Nuestro objetivo es crear un modelo del dominio de clases conceptuales
interesantes o significativas del dominio de inters (ventas). En este caso, eso
significa conceptos relacionados con el caso de uso Procesar Venta.
En el desarrollo iterativo, uno incrementalmente construye un modelo del
dominio a lo largo de varias iteraciones en la fase de elaboracin. En cada una,
el modelo de dominio se limita a los escenarios anteriores y actuales en
estudio, en lugar de un modelo de gran explosin, que en las primeras
etapas intenta capturar todas las posibles clases conceptuales y las relaciones.
Por ejemplo, esta iteracin est limitada al escenario de pago en efectivo de
Procesar Venta; por tanto, se crear un modelo de dominio parcial nicamente
para reflejar eso no ms.
La tarea central es, por tanto, identificar las clases conceptuales relacionadas
con el escenario que se est diseando.
A continuacin presentamos una gua til para la identificacin de las clases
conceptuales:

No piense que un modelo de dominio es mejor si contiene pocas clases


conceptuales; suele ser verdad justamente lo contrario.
Es normal obviar clases conceptuales durante la etapa de identificacin
inicial, y descubrirlas ms tarde al considerar los atributos y
asociaciones, o durante el trabajo de diseo. Cuando se encuentren, se
pueden aadir al modelo del dominio.
No excluya una clase conceptual simplemente porque los requisitos no
indican ninguna necesidad obvia para registrar informacin sobre ella
(un criterio comn en el modelado de datos para el diseo de bases de
datos relacinales, pero no relevante en el modelado del dominio), o
porque la clase conceptual no tiene atributos.

Es vlido tener clases conceptuales sin atributos, o clases conceptuales


con un rol puramente de comportamiento en el dominio, en lugar de un
rol de informacin.

Estrategias para identificar clases conceptuales


En las siguientes secciones se presentan dos tcnicas:
1. Utilizacin de una lista de categoras de clases conceptuales.
2. Identificacin de frases nominales.

Utilizacin de una lista de categoras de clases conceptuales


Comience la creacin de un modelo del dominio haciendo una lista de clases
conceptuales candidatas. La Tabla siguiente contiene muchas categoras
habituales que, normalmente, merece la pena tener en cuenta, aunque no en
ningn orden particular de importancia. Los ejemplos se han extrado del
dominio de las tiendas
Categora de clase conceptual
objetos tangibles o fsicos
especificaciones, diseos o descripciones de la
cosas
lugares
transacciones
lneas de la transaccin
roles de la gente
contenedores de otras cosas
cosas en un contenedor
otros sistemas Informticos o electromecnicos
externos al sistema
organizaciones
hechos
Categora de clase conceptual
procesos (normalmente no se representan como
conceptos, pero podra ocurrir)
reglas y polticas
catlogos
registros de finanzas, trabajo, contratos,
cuestiones legales
instrumentos y servicios financieros
manuales, documentos, artculos de referencia,
libros

Ejemplos
Registro
EspecificacionDelProducto
Tienda
Venta
LineaDeVenta
Cajero
Tienda
Articulo
SistemaAutorizacionPagoCr
edito
DepartamentoDeVentas
Venta, Pago
Ejemplos
VentaDeUnProducto
PoliticaDereintegro
CatalogoDeProductos
Recibo, LibroMayor
LineaDeCredito
Stock
ListaDeCambiosDePreciosDi
arios

Descubrimiento de ciases conceptuales mediante la identificacin de


frases nominales
Otra tcnica til (debido a su simplicidad) recomendada es el anlisis lingstico: identificar los nombres y frases nominales en las descripciones

textuales de un dominio, y considerarlos como clases conceptuales o atributos


candidatos.
Se debe tener cuidado con este mtodo; no es posible realizar una
correspondencia mecnica de nombres a clases, y las palabras en lenguaje
natural son ambiguas.
En cualquier caso, es otra fuente de inspiracin. Los casos de uso en formato
completo constituyen una descripcin excelente a partir de la cual extraer este
anlisis. Por ejemplo, se puede utilizar el escenario actual del caso de uso
Procesar Venta.

Escenario principal de xito (o Flujo Bsico):


1. El Cliente llega a un terminal PDV con mercancas y/o servicios que
comprar.
2. El Cajero comienza una nueva venta.
3. El Cajero introduce el identificador del artculo.
4. El Sistema registra la lnea de la venta y presenta la descripcin del
artculo, precio y suma parcial. El precio se calcula a partir de un
conjunto de reglas de precios.
5. El Cajero repite los pasos 3-4 hasta que se indique.
6. El Sistema presenta el total con los impuestos calculados.
7. El Cajero le dice al Cliente el total y solicita el pago.
8. El Cliente paga y el Sistema gestiona el pago.
9. El Sistema registra la venta completa y enva la informacin de la venta
y el pago al sistema de Contabilidad externo (para la contabilidad y
las comisiones) y al sistema de Inventario (para actualizar el
inventario).
10.El Sistema presenta el recibo.
11.El Cliente se va con el recibo y las mercancas (si es el caso).
Clases conceptuales candidatas para el dominio de ventas
A partir del anlisis de la Lista de Categoras de Clases Conceptuales y las
frases nominales, se genera una lista de clases conceptuales candidatas del
dominio. La lista est restringida a los requisitos y simplificaciones que se
estn estudiando actualmente el escenario simplificado de Procesar Venta.
Registro
Articulo
Tienda
Venta
Pago
CatalogoDeProductos

EspecificacionDelProducto
LineaDeVenta
Cajero
Cliente
Encargado

No existe una lista correcta. Es una coleccin algo arbitraria de abstracciones


y vocabulario del dominio que el modelador considera relevantes. En cualquier
caso, siguiendo estrategia de identificacin, diferentes modeladores
producirn listas similares.
Guas para el modelado del negocio Cmo hacer un modelo del
dominio
Aplique los siguientes pasos para crear un modelo del dominio:
1. Liste las clases conceptuales candidatas, utilizando las tcnicas de la
Lista de Categoras de Clases Conceptuales y la identificacin de frases
nominales, relacionadas con los requisitos actuales en estudio.
2. Represntelos en un modelo del dominio.
3. Aada las asociaciones necesarias para registrar las relaciones que hay
que mantener en memoria.
4. Aada los atributos necesarios para satisfacer los requisitos de
informacin.

Error tpico en la identificacin de las clases conceptuales


Quizs el error ms tpico al crear un modelo del dominio es representar algo
como atributo cuando debera haber sido un concepto. Una regla emprica para
ayudar a venir este error es:
Si no consideramos alguna clase conceptual X que sea un nmero o texto en el
mundo real, X es probablemente una clase conceptual, no un atributo.
Como ejemplo, debera ser la tienda un atributo de Venta, o una clase
conceptual separada Tienda?
Venta
tienda

O?

Venta

Tienda
numeroTelefono

En el mundo real, una tienda no


se considera un
nmero o un texto el trmino sugiere una entidad legal, una organizacin, y
algo que ocupa espacio. Por tanto, Tienda debe ser un concepto.
Notacin UML, modelos y mtodos: perspectivas mltiples
El UP (Proceso Unificado-metodologa) define algo denominado Modelo del
Dominio, que se representa con la notacin UML. Sin embargo, no existe un
trmino Modelo del Dominio en la documentacin oficial de UML. Esto nos
revela algo importante:
UML simplemente describe tipos de diagramas, como los diagramas de clases y
los diagramas de secuencia. No superpone un mtodo o perspectiva de
modelado sobre ellos. Ms bien, un proceso (como el UP) aplica la notacin de
la especificacin de UML en el contexto de modelos definidos en el mbito de
una metodologa.
Por ejemplo, la notacin de los diagramas de clases de UML se puede utilizar
para crear representaciones de las clases conceptuales del dominio (un modelo
del dominio), clases software, tablas de una base de datos relacional, etctera.
Por tanto, no debemos confundir la notacin bsica de los diagramas UML, con
su aplicacin para visualizar distintos tipos de modelos definidos por los
metodologistas. Este punto es aplicable no slo a los diagramas de clases UML,
sino a la mayora de la notacin UML.
Ejemplo: el Modelo del Dominio del PDV NuevaEra
La lista de clases conceptuales generadas para el dominio del PDV NuevaEra
se podra representar grficamente para mostrar el comienzo del Modelo del
Dominio.
Registro

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

A es una parte fsica de B

Cajon-registro (o ms concretamente, TPDV)

A es una parte lgica de B

LneaDeVenta-Venta

A est contenido fsicamente en B

registo-Tienda, Articulo-Estantera

A est contenido lgicamente en B

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

A es una subunidad organizativa de B

Departamento- Tienda

A utiliza o gestiona B

Cajero-Registro

LineaDe Venta- Venta

A se comunica con B

Cliente-Cajero

A est relacionado con una transaccin B


A es una transaccin relacionada con otra
transaccin B
A est al lado de B

Cliente-Pago

A es propiedad de B

Registro-Tienda

A es un evento relacionado con B

Venta-Cliente, Venta-Tienda

Pago-Venta
LineaDeVenta-LineaDeVenta

Asociaciones de prioridad alta


A continuacin, presentamos algunas de las categoras de asociaciones de
prioridad alta que son, invariablemente, tiles incluirlas en un modelo del
dominio:
A es una parte lgica o fsica de B.
A est contenida fsica o lgicamente en B.
A se registra en B.
Guas para las asociaciones

Cntrese en aquellas asociaciones para las que se necesita conservar el


conocimiento de la relacin durante algn tiempo (asociaciones
necesito-conocer).
Es ms importante identificar clases conceptuales que identificar
asociaciones.
Demasiadas asociaciones tienden a confundir un modelo del dominio en
lugar de aclararlo. Su descubrimiento puede llevar tiempo, con beneficio
marginal.
Evite mostrar asociaciones redundantes o derivadas.

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

El valor de la multiplicidad indica cuntas instancias se puede asociar


legalmente con otra, en un momento concreto, en lugar de a lo largo de un
periodo de tiempo. Por ejemplo, es posible que un coche usado pudiera a lo
largo del tiempo ser vendido repetidamente a comerciantes de coches usados.
Pero en un momento concreto, el coche slo es Abastecido-por un comerciante.
El coche no es Abastecido-por muchos comerciantes en un momento concreto.
Anlogamente, en pases con leyes mongamas, una persona puede estar
Casado-con slo una persona en un momento dado, aunque a lo largo del
tiempo, puedan casarse con muchas personas.
El valor de la multiplicidad depende de nuestros intereses como modeladores y
desarrolladores de software, porque pone de manifiesto una restriccin de
diseo que ser (o podr ser) reflejada en el software.
La multiplicidad debera ser 1 o 0..1?
La respuesta depende de nuestro inters al utilizar el modelo. Tpica y prcticamente,
la multiplicidad denota una restriccin del dominio que nos preocupamos de ser
capaces de comprobar en el software, si esta relacin se implementase o reflejase en
los objetos software o en la base de datos. Por ejemplo, un concreto artculo podra
llegar a venderse o desecharse, y por tanto, no se almacenara en la tienda por ms
tiempo. Desde este punto de vista, 0..1 es lgico, pero...
Nos preocupa este punto de vista? Si se implementa esta relacin en el software,
probablemente querramos asegurar que una instancia software de Artculo siempre se
relacionara con una instancia concreta de Tienda, de otra manera, indica un error o
corrupcin en los elementos software o datos.
Este modelo de dominio parcial no representa objetos software, sino que las
multiplicidades registran restricciones cuyo valor prctico est, normalmente,
relacionado con nuestro inters en la construccin del software o bases de datos (que
reflejan nuestro dominio del mundo real) con comprobaciones de validez. Desde este
punto de vista, el valor deseable podra ser 1.

Cmo de detalladas deben ser las asociaciones?


Las asociaciones son importantes, pero un error tpico al crear los modelos del
dominio, es dedicar demasiado tiempo durante el estudio intentando
descubrirlas.
Es fundamental entender lo siguiente:
Es ms importante encontrar las clases conceptuales que las asociaciones. La
mayora del tiempo dedicado a la creacin del modelo del dominio debera
emplearse en la identificacin de las clases conceptuales, no de las
asociaciones.
Asignacin de nombres a las asociaciones
Nombre una asociacin en base al formato Nombre Tipo-Frase VerbaTNombre
Tipo donde la frase verbal crea una secuencia que es legible y tiene significado
en el contexto del modelo.

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

artefacto temporal que se utiliza para inspirar las etapas siguientes, y no se


utilizar de manera significativa ms adelante, por qu actualizarlo? Evite
hacer o actualizar cualquier modelo o documentacin a menos que exista una
justificacin concreta para su futura utilizacin.
Asociaciones del Modelo del Dominio del PDV NuevaEra
Ahora podemos aadir las asociaciones a nuestro modelo del dominio del PDV.
Deberamos aadir aquellas asociaciones que los requisitos (por ejemplo, los
casos de uso) sugieren o implican una necesidad de recordar, o que, de otra
manera, recomienda fuertemente nuestra percepcin del dominio del
problema. Cuando abordamos un nuevo problema, las categoras comunes de
asociaciones, presentadas anteriormente, deberan revisarse y tenerse en
cuenta, puesto que representan muchas de las asociaciones relevantes que
normalmente necesitan recogerse.
Relaciones evidentes de la Tienda
La siguiente muestra de asociaciones es justificable en trminos de necesitoconocer. Se basa en los casos de uso que se estn considerando actualmente.
Para conocer la venta actual, generar
Registro Registra Venta
el total, imprimir recibo
Venta Pagada-mediante Pago

Para conocer si se ha pagado la


venta, relacionar la cantidad
entregada con el total de la venta, e
imprimir un recibo

CatalogoDeProductos Registra
EspecificacionDelProducto

Para recuperar una Especificacin


DelProducto a partir de un articuloID

Aplicacin de la lista de comprobacin de categoras de asociaciones


Recorreremos la lista de comprobacin, basada en los tipos identificados
previamente, considerando los requisitos del caso de uso actual.
Categora
Sistema
A es una parte fsica de B
RegistroCaja
A es una parte lgica de B
LineaDeVentaVenta
A est contenido fsicamente en RegistoTienda
B
ArticuloTienda
A est contenido lgicamente en EspecificacionDelProducto
B
CatalogoDeProductos
CatalogoDeProductosTienda
A es una descripcin de B
EspecificacionDelProducto-Articulo
A es una lnea de una
LineaDeVentaVenta
transaccin o informe de B
A se conoce/ registra/ recoge/
(completa)VentaTienda
informa/ captura en B
(actual) VentaRegistro
A es miembro de B
CajeroTienda
A es una subunidad organizativa no aplicable

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

Modelo del Dominio del PDV NuevaEra


El modelo del dominio de la Figura siguiente muestra un conjunto de clases
conceptuales y asociaciones que son candidatas para nuestra aplicacin de
PDV. Las asociaciones se derivaron sobre todo a partir de la lista de
comprobacin de asociaciones candidatas.

Conservamos slo las asociaciones necesito-conocer?

14

El conjunto de asociaciones que se muestran en el modelo del dominio de la


Figura se derivaron de forma mecnica, la mayor parte, a partir de la lista de
comprobacin de asociaciones. Sin embargo, sera deseable que furamos ms
cuidadosos con las asociaciones que incluimos en nuestro modelo del dominio.
Vista como una herramienta de comunicacin, no es deseable sobrecargar el
modelo del dominio con asociaciones que no se necesitan forzosamente y que
no favorecen nuestra comprensin. Demasiadas asociaciones no
imprescindibles oscurecen en lugar de aclarar.
Como se sugiri previamente, se recomienda el siguiente criterio para mostrar
las asociaciones:

Cntrese en aquellas asociaciones para las que el conocimiento de la


relacin necesita conservarse durante algn tiempo (asociaciones
necesito-conocer).
Evite mostrar asociaciones redundantes o derivadas.

En base a este consejo, no todas las asociaciones que se acaban de mostrar


son imprescindibles. Considere lo siguiente:
Asociacin
Venta Insertada-por
Cajero

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

You might also like