2° Edicion UML y Patrones Craig LarmanCapitulo 10 MobELo DEL Dominio: VISUALIZACION DE CONCEPTOS Todo esté muy bien en la préctica, pero nunca funcionaré en la teorta. Maxima an6nima sobre la gestion Objetivos Identificar las clases conceptuales relacionadas con los requisitos de la itera actual. Crear un modelo de! dominio inicial Distinguir entre atributos correctos ¢ incorrectos. * Ailadir las clases conceptuales de especificacién, cuando sea oportuno. Comparar y contrastar las vistas conceptual y de implementacién. Introduccion Un modelo del dominio se utiliza con frecuencia como fuente de inspiraci6n para el di- sefio de los objetos software, y serd una entrada necesaria para varios de los siguientes artefactos que se presentan en este libro. Por tanto, es importante leer este capitulo si el lector no esta familiarizado con el tema del modelado del dominio. Un modelo del dominio muestra (a los modeladores) clases conceptuales significa- tivas en un dominio del problema; es el artefacto mas importante que se crea durante el anilisis orientado a objetos'. Este capitulo estudia técnicas introductorias a la creacién de modelos del dominio. Los siguientes dos capftulos tratardn mds extensamente las téc- nicas de modelado del dominio —aftadiendo atributos y asociaciones— "Los casos de uso son un importante artefacto del andisis de requisitos, pero no son orientados a objetas. Po: nen de relieve una vista de procesos del dominio.122 10.1. UML Y PATRONES La identificacién de un conjunto rico de objetos o clases conceptuales es una parte esencial del andlisis orientado a objetos, y bien merece la pena el esfuerzo en relacién con los beneficios durante el trabajo de disefio e implementacién. La identificacién de las clases conceptuales forma parte del estudio del dominio del problema. UML contiene notacién, en forma de diagramas de clases, para representar los modelos del dominio. Idea clave Un modelo del dominio es una representacién de las clases conceptuales del mundo real, ‘no de components software. No se trata de un conjunto de diagramas que describen cla- ses software, u objetos software con responsabilidades. Modelos del dominio La etapa orientada a objetos esencial del andlisis o investigacién es la descomposiciGn de tun dominio de interés en clases conceptuales individuales u objetos —Ias cosas de las que somos conscientes—. Un modelo del dominio es una representacién visual de las clases conceptuales u objetos del mundo real en un dominio de interés [MO95, Fowler96]. Tam- bién se les denomina modelos conceptuales (término utilizado en la primera ediciGn de este libro), modelo de objetos del dominio y modelos de objetos de anailisis El UP define un Modelo de Dominio’ como uno de los artefactos que podrian crearse en la disciplina del Modelado del Negocio. Utilizando la notacién UML, un modelo del dominio se representa con un conjunto de diagramas de clases en los que no se define ninguna operacién, Pueden mostrar: + Objetos del dominio o clases conceptuales. + Asociaciones entre las clases conceptuales. + Atributos de las clases conceptuales. Por ejemplo, la Figura 10.1 muestra un modelo del dominio parcial, Hustra que las cla ses conceptuales Pago y Venta son significativas en este dominio, que un Pago esté rela: cionado 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 notaci6n no son importantes en este momento. Idea clave: Modelo del dominio—un diccionario visual de abstracciones Por favor, reflexione un momento sobre la Figura 10.1. La figura visualiza y relaciona al- gunas palabras o clases conceptuales del dominio. También describe una abstraccién de 2 También estin relacionados con los modelos conceptuales entidad-relacién, que son eapaces de mostra vis {as de los dominios puramente conceptual, pero que han sido ampliamente re-interpretados como modelos ded {os para el disefio de bases de datos. Los modelos del dominio no son modelos de datos. ® Se utiliza Modelo del Dominio en mayésculas cuando deseo resaltar que es un modelo oficial definido ene UP, frente al concepto bien conocido de “modelos de dominio",MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS — 123 cconcepto [ tneabeventa | concept | LineaDeventa Registraventa-de antes, del dominio | cantidad 0.1 1 ri —T ‘Almacenado-en asociacion -© Contenida-en 1 1 Venta Tienda atributos » 0] fecha direccion hora 4 nombre 1 7 latberga Pagado-mediante 4" 1 Cayiurada-en Registro Pago Fi ccantidad Figura 10.1, Modelo de! dominio parcial —un diccionario visual—. El niimero de ead extremo de la Vnea indica la multiplicidad, que se describiré en un capitulo posterior. las clases conceptuales, porque hay muchas cosas que uno podrfa comunicar sobre los registros, las ventas, etcétera. El modelo muestra una vista parcial, o abstraccién, e ig- nora detalles sin interés (para el modelador). La informacién que presenta (utilizando la notacién UML) podria, de manera alter- nativa, haberse expresado en prosa, mediante sentencias en el Glosario o en algén otro sitio. Pero es fécil entender los distintos elementos y sus relaciones mediante este len- guaje visual, puesto que un porcentaje significativo del cerebro toma parte en el proce- samiento visual —es una cualidad de los humanos—. Por tanto, el modelo del dominio podria considerarse como un diccionario visual de las abstracciones relevantes, vocabulario del dominio e informacién del dominio. Los modelos del dominio no son modelos de componentes software Un modelo del dominio, como se muestra en la Figura 10.2, es una representacién de las cosas del mundo real del dominio de interés, no de componentes sofiware, como una clase Java o C++ (ver Figura 10,3), u objetos software con responsabilidades, Por tan- 10, los siguientes elementos no son adecuados en un modelo del dominio:124 UML Y PATRONES: vigualizacion de ‘conceptos del mundo real del dominio Venta de interés fecha’ noes una hora representacién de una clase software Figura 10.2, Un modelo del dominio muestra clases conceptuales del mundo real, no clases software. Base Delieice Vents ‘artefacto software; no forma May eaaoarerer ° parte del modelo del dominio Venta lawn ok ee 6 clase software; no forma b fecha parte del modelo del dominio] hora imprimir) Figura 10.3. Un modelo de! dominio no muestra artefactos software o clases. * Artefactos software, como una ventana o una base de datos, a menos que el do- minio que se esté modelando sea de conceptos software, como un modelo de in- terfaces de usuario graficas. * Responsabilidades o métodos' Clases conceptuales El modelo del dominio muestra las clases conceptuales 0 Vocabulario del dominio, In formalmente, una clase conceptual es una idea, cosa u objeto. Mas formalmente, una cle se conceptual podrfa considerarse en términos de su simbolo, intensién, y extensiéa [MO95] (ver Figura 10.4). + Simbolo: palabras o imagenes que representan una clase conceptual. + Intensién: la definici6n de una clase conceptual. + Extensién: el conjunto de ejemplos a los que se aplica la clase conceptual Por ejemplo, considere la clase conceptual para el evento de una transaccién de com! pra. Podria elegir nombrarla con el simbolo Venta. La intensién de una Venta podriaes * Bn el modelado de objetos, normalmente hablamos de responsabilidades relacionadas con los componeai software. Y los métodos son puramente conceptos software. Pero el modelo de dominio describe conceptos del ma do real, no componentes software. Es importante considera las responsabilidades de los objetos durante lt de disefio; s6lo que no forma parte de este modelo. Un caso valido en el que se podrfan mostrar las respons ‘dades en un modelo de dominio es si incluye roles de trabajadores humanos (como el Cajero),y el modelador d recoger las responsabilidades de estos trabajadores humanos.MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 125 mt aeons My "Una venta representa i el hecho de una transicién | © intensién del concepto x de compra. Sucede un dia a yauna hora ° extension del concepto x Figura 10.4, Una clase conceptual tiene un simbolo, una intensién y una extensisn. tablecer que “representa el hecho de una transaccién de una compra, y tiene una fecha y una hora”. La extensién de una Venta la forman todos los ejemplos de ventas; en otras palabras, el conjunto de todas las ventas, ‘Cuando creamos un modelo del dominio, normalmente, el simbolo y la vista inten- sional de la clase conceptual son los que tienen un mayor interés practico. Modelos y descomposicion del dominio Los problemas del software pueden ser complejos; la descomposicién —divide y ven- cerés— es una estrategia comin para tratar esta complejidad mediante la divisién del es- pacio del problema en unidades faciles de comprender. En el andlisis estructurado, la dimensién de la descomposicidn es por procesos o por funciones. Sin embargo, en el andlisis orientado a objetos, la dimensi6n de la descomposicién es fundamentalmente por cosas 0 entidades del dominio. Una diferencia esencial entre el analisis orientado a objetos y el estructurado es: la division por clases conceptuales (objetos) en lugar de la division por funciones. Por tanto, la principal tarea del andlisis es identificar diferentes conceptos en el do- minio del problema y documentar el resultado en un modelo del dominio.126 UML Y PATRONES 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, mos. trado en la Figura 10.5, podria incluir Tienda, Registro y Venta. Tienda Registro Venta Figura 10.5. Modelo del dominio parcial en el dominio de la tienda, 10.2. Identificacion de las clases conceptuales Nuestro objetivo es crear un modelo de! dominio de clases conceptuales interesantes 0 significativas del dominio de interés (ventas). En este caso, eso significa conceptos re- lacionados 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 elaboracién. En cada una, el modelo de do. inio se limita a los escenarios anteriores y actual en estudio, en lugar de un modelo de “gran explosién”, que en las primeras etapas intenta capturar todas las posibles clases conceptuales y las relaciones. Por ejemplo, esta iteracién esta limitada al escenario de ago en efectivo de Procesar Venta; por tanto, se crear un modelo de dominio parcial tinicamente para reflejar eso —no mas—. La tarea central es, por tanto, identificar las clases conceptuales relacionadas con el escenario que se esté disefiando. A continuacién presentamos una guia «til para la identificacién de las clases con- ceptuales: Es mejor especificar en exceso un modelo del dominio con muchas clases conceptuales de grano fino que especificar por defecto. 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 idemtificaci6n inicial, y des- cubrirlas més tarde al considerar los atributos y asociaciones, o durante el trabajo de di sefio. Cuando se encuentren, se pueden afiadir al modelo del dominio. No excluya una clase conceptual simplemente porque los requisitos no indican nin- guna necesidad obvia para registrar informacién sobre ella (un criterio comtin en el mo- delado de datos para el disefio de bases de datos relacionales, pero no relevante en el mo. delado de! dominio), 0 porque la clase conceptual no tiene atributos, Es vilido tener clases conceptuales sin atributos, 0 clases conceptuales con un rol pu: Tamente de comportamiento en el dominio, en lugar de un rol de informacién.MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 127 Estrategias para identificar clases conceptuales En las siguientes secciones se presentan dos técnicas: 1. Utilizaci6n de una lista de categorfas de clases conceptuales. 2. Identificacién de frases nominales. ‘tra excelente técnica para el modelado del dominio es el uso de patrones de ani- Iisis, que son modelos de dominios parciales existentes ereados por expertos, utilizando libros publicados como Analysis Patterns [Fowler96] y Data Model Patterns [Hay96]. Utilizacién de una lista de categorias de clases conceptuales Comience la ereacién de un modelo del dominio haciendo una lista de clases concep- tuales candidatas, La Tabla 10.1 contiene muchas categorias habituales que, normal: nent, merece [a pena tener en cuenta, aunque no en ningsin orden particular de impor- Tncia’ Los ejemplos se han extraido del dominio de las tiendas y las reservas de vuelos Tabla 10.1. Lista de categorias de clases conceptuales. Categoria de clase conceptual Ejemplos objetos tangibles 0 fisicos Registro Avion eepecificaciones, disefios o descripciones | EspecificacionDelProducto de la cosas DescripcionDelVuelo lugares Tienda transacciones Venta, Pago Reserva lineas de la transaccion LineaDeVenta roles de la gente Cajero Piloto contenedores de otras cosas Tienda, Lata Avion ‘cosas en un contenedor Articulo Pasajero otros sistemas informaticos SistemaAutorizacionPagoCredito S electromecdnicos externos al sistema __| ControiDeTraficoAereo ‘conceptos abstractos Ansia ‘Acrofobia ‘organizaciones DepartamentoDeVentas CompaniaAerea hechos Venta, Pago, Reunion Vuelo, Colision, Aterrizaje ccontinia128 UML Y PATRONES Tabla 10.1. Lista de categorias de clases conceptuales. (Continuacién) Categoria de clase conceptual Ejemplos Procesos (normalmente no se representan | VentaDeUnProducto Como conceptos, pero podria ocurir) ReservaUnAsiento reglas y politicas PoliticaDeReintegro PolticaDeCancelacion catalogos CatalogoDeProductos CatalogoDePiezas registros de finanzas, trabajo, contratos, | Recibo, LibroMayor, ContratoEmpleo cuestiones legales RegistroMantenimiento instrumentos y servicios financieros LineaDeCreaito Stock manuales, documentos, ListaDeCambiosDePreciosDiarios articulos de referencia, libros ManualReparaciones Descubrimiento de clases conceptuales mediante la identificacién de frases nominales Otra técnica titil (debido a su simplicidad) recomendada en [Abbot83] es el andlisis lin gilistico: identificar los nombres y frases nominales en las descripciones textuales de un dominio, y considerarlos como clases conceptuales o attibutos candidatos, Se debe tener cuidado con este método; no es posible realizar una correspondencia mecénica de nombres a clases, y las palabras en lenguaje natural son ambiguas. En cualquier caso, es otra fuente de inspiraci6n. Los casos de uso en formato com pleto constituyen una descripcién excelente a partir de la cual extraer este anilisis, Por ejemplo, se puede utilizar el escenario actual del caso de uso Procesar Venta Escenario principal de éxito (0 Flujo Basico): El Cliente llega a un terminal PDV con mercancias y/o servicios que comprar. EI Cajero comienza una nueva venta. El Cajero introduce el identificador del articulo. El Sistema registra la linea de la venta y presenta la descripcién del articulo, precio y,suma parcial. El precio se calcula a partir de un conjunto de reglas de precios. El Cajero repite los pasos 3-4 hasta que se indique. EI Sistema presenta el total con los impuestos calculados, El Cajero le dice al Cliente el total y solicita el pago. El Cliente paga y el Sistema gestiona el pago. EI Sistema registra la venta completa y envia la informacion de la venta y el pago a sistema de Contabilidad externo (para la contabilidad y las eomisiones) y al sistema de Inventario (para actualizar el inventario). 9. El Sistema presenta el recibo, 10. El Cliente se va con el recibo y las mercancias (si es el caso) Bone 2NogMODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 129 Extensiones (o Flujos Alternativos): 7a, Pago en efectivo: 1. El Cajero introduce la cantidad de dinero entregada en efectivo. 2. El Sistema muestra la cantidad de dinero a devolver y abre el cajén de caja 3. El Cajero deposita el dinero entregado y devuelve el cambio al Cliente. 4. El Sistema registra el pago en efectivo. El modelo del dominio es una visualizacién de los conceptos del dominio y voca- bulario relevantes, ;Dénde se encuentran estos términos? En los casos de uso. Por tan- to, constituyen una fuente rica a explorar mediante la identificaci6n de fras nales. ‘s nomi- Algunas de las frases nominales son clases conceptuales candidatas, algunas po- drian hacer referencia a clases conceptuales que se ignoran en esta iteracién (por ejemplo, “Contabi conceptuales. Por favor, dirfjase a la siguiente seccién y al capitulo sobre los atributo: para obtener los consejos que permiten diferenciar entre los dos. jad” y “comisiones”), y algunas podrian ser atributos de las clases Un punto débil de este enfoque es la imprecisién del lenguaje natural; frases no- minales diferentes podrfan representar la misma clase conceptual 0 atributo, entre otras ambigiiedades. Sin embargo, se recomienda que se combine con la técnica la Lis- ta de Categorias de Clases Conceptuales. 10.3. Clases conceptuales candidatas para el dominio de ventas A partir del andlisis de la Lista de Categorias de Clases Conceptuales y las frases no- minales, se genera una lista de clases conceptuales candidatas del dominio. La lista esté restringida a los requisitos y simplificaciones que se estan estudiando actualmente —el escenario simplificado de Procesar Venta— Registro EspecificacionDelProducto Articulo LineaDeVenta Tienda Cajero Venta Cliente Pago Encargado CatalogoDeProductos* No existe una lista “correcta”. Es una coleccién algo arbitraria de abstracciones y vo- cabulario del dominio que el modelador considera relevantes. En cualquier caso, si- guiendo la estrategia de identificaci6n, diferentes modeladores producirén listas similares. 5 IN, del T: Aunque siguiendo las convenciones para nombrar las clases no se utilizar la preposicin, en este caso al igual que en EspecificacionDelProducto y LineaDeVenta, se han uilizado para mejorar la legibilidad del texto.130 UML Y PATRONES. el recibo en el modelo? Objetos de informes: zincl Un recibo es un informe de una venta y del pago, y una clase conceptual relativamente destacable del dominio, por tanto, ,deberfa mostrarse en el modelo? A continuacién presentamos algunos factores a tener en cuenta: * Un recibo es un informe de una venta. En general, no es til mostrar un informe de otra informacién en un modelo de! dominio puesto que toda esta informacién se deriva de otras fuentes; duplica informacién que se encuentra en otras partes. Esta es una raz6n para excluirlo. + Un recibo tiene un rol especial en término de las reglas del negocio: normalmente, confiere al portador del recibo, el derecho a devolver los articulos comprados. Esta s una raz6n para mostrarlo en el modelo. Puesto que la devolucién de articulos no esta siendo considerada en esta iteracién, el Recibo sera excluido. Durante la iteracién que aborda el caso de uso Gestionar Devo- luciones, estarfa justificada su inclusién. 10.4. Guias para el modelado del negocio Como hacer un modelo del dominio Aplique los siguientes pasos para crear un modelo del dominio: 1. Liste las clases conceptuales candidatas, utiizando las técnicas de la Lista de Cate- gorias de Clases Conceptuales y la identificacién de frases nominales, relacionadas on los requisitos actuales en estudio. 2. Represéntelos en un modelo del dominio. 3. Afiada las asociaciones necesarias para registrar las relaciones que hay que mante- nner en memoria (se discutiré en un capitulo siguiente). 4. Afiada los atributos necesarios para satisfacer los requisitos de informacién (se dis- cutiré en un capitulo siguiente). Un método itil auxiliar es aprender y copiar patrones de andlis un capitulo posterior. , que se discutiran en Nombrar y modelar cosas: el cartégrafo La estrategia del cart6grafo se ay -a tanto a los mapas como a los modelos del dominio. Haga un modelo del dominio con el espiritu del modo de trabajo de los cartégratos: * Utiiice los nombres existentes en el territorio + Excluya las caracteristicas irrelevantes, + No afiada cosas que no estan ahiMODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 131 Un modelo del dominio es un tipo de mapa de conceptos 0 cosas de un dominio. Este espiritu destaca el rol analitico de un modelo del dominio, y sugiere lo siguiente: + Un cartégrafo utiliza los nombres del territorio —no cambia los nombres de las ciudades en un mapa—. Para un modelo del dominio, significa que utilice el vo- cabulario del dominio al nombrar los nombres de las clases conceptuales y los atributos, Por ejemplo, si estamos desarrollando un modelo para una biblioteca, nombre al cliente como “Prestatario” 0 “Socio” —Ios términos utilizados por el personal de la biblioteca. + Un cart6grafo elimina las cosas de un mapa si no se consideran relevantes para el propésito del mapa; por ejemplo, la topografia o la poblacién no es necesario que se muestren. Andlogamente, un modelo de dominio podria excluir clases concep- tuales del dominio del problema que no son pertinentes para los requisitos. Por ejemplo, podriamos excluir Boligrafo y BolsaPapel de nuestro modelo del dominio (para el conjunto de requisitos actual) puesto que no tienen un rol relevante obvio. + Un cartégrafo no muestra cosas que no estén ahf, como montafias que no existen. Tgualmente, el modelo del dominio deberia excluir cosas que no se encuentran en el dominio del problema que se esté estudiando, El principio también se conoce como la estrategia Utilice el Vocabulario del Domi- nio [Coad95] Error tipico en la identificacién de las clases conceptuales Quizés el error més tipico al crear un modelo del dominio es representar algo como un atributo cuando deberfa haber sido un concepto. Una regla empirica para ayudar a pre- venir este error es: Si no consideramos alguna clase conceptual X que sea un niimero 0 texto en el mundo real, X es probablemente una clase conceptual, no un atributo. Como ejemplo, ;deberia ser la tienda un atributo de Venta, 0 una clase conceptual se- parada Tienda? Venta > Venta Tienda tienda ie ‘numeroTelefono Enel mundo real, una tienda no se considera un ntimero o un texto —el término su- sgiere una entidad legal, una organizacién, y algo que ocupa espacio—. Por tanto, Tien- da debe ser un concepto. Vuelo Vuelo ‘Aeropuerto | destino nombre132 UML YY PATRONES Otro ejemplo, considere el dominio de las reservas de vuelos. ,Deberfa ser el dest no un atributo de Vuelo, o una clase conceptual aparte, Aeropuerto? En el mundo real, un aeropuerto de destino no se considera un ntimero 0 un texto—e tuna cosa grande que ocupa espacio—. Por tanto, Aeropuerto deberfa ser un concepto. En caso de duda, considérelo un concepto separado. Los atributos deberian ser bastante raros en un modelo del dominio. 10.5. Resolucién de clases conceptuales similares: Registro vs. “TPDV” TPDV son las siglas de terminal de punto de venta, En el lenguaje informatico, un ter minal es cualquier dispositivo de un sistema, como un PC cliente, un PDA en red int limbrico, etcétera. En los primeros tiempos, mucho antes a los TPDVs, una tienda mantenfa un registro —un libro en el que se apuntaban las ventas y pagos—. Con e tiempo, esto se automatiz6 en “cajas registradoras” mecénicas. Hoy en dia, un TPDV de sempefia el rol del registro (ver Figura 10.6). Tepv 7 Rogistro 1 1 Registra ~ Registra > Venta Venta Figura 10.6. TPDV y Registro son clases conceptuales similares Un registro es una cosa que recoge las ventas y pagos, pero esto es un TPDV. Sit embargo, el término registro parece algo mas abstracto y menos orientado a la imple mentaci6n que un TPDV. Por tanto, en el modelo del dominio, ;deberfa utilizarse el sine bolo Registro en lugar de TPDV? Primero, como regla empirica, un modelo del dominio no es absolutamente correcto 0 equivocad, sino mas o menos util; es una herramienta de comunicacién. Por el principio del cartégrafo, “TPDV” es un término familiar en el tervitorio, de me nera que es un simbolo titi desde el punto de vista de la familiaridad y la comunicacié. Por el objetivo de la creacién de modelos que representan abstracciones y son indeper: