EL iA LENGUAJE te UNIFICADO ist conse DE MODELADO eslcnges UML 2.0 ® DA EDICION Grady Booch James Rumbaugh __ Ivar Jacobson Aprenda UML directamente de sus creadores120 UML Y PATRONES 9.12. Artefactos del UP Capitulo 10 { La Figura 9.6 presenta ejemplos de relaciones de los DSSs con otros artefactos. M ODELO DEL DomiIN IO: - VISUALIZACION DE CONCEPTOS . iP q F Muestra de artefactos UI { Antefactos parciales, d Modelo (_ tefinados en cada) : Modelado del Dominio iteracion I de! Negocio 7 F A \ 8 Los parametros Todo esté muy bien en la practica, pero nunca funcionaré en la teoria. 0 valores de retorno : 7 : podrian elaborarse 4 Maxima anénima sobre la gestién en el Glosario Modelo de Casos de Uso SEEELEEEE EEE Y Requisitos seat i | Eee ES Glosario i {__ ban : eventos del f | operaciones sistema & i | del sistema textode Gatos eee eee ate contratos de los casos : las operaciones de uso del sistema del sistema _ ' eas Objetivos i t : / Doc. de Arquitec- : * Identificar las clases conceptuales relacionadas con los requisitos de Ia iteracion Modelo de Diseho picts de diseno ‘ura de Software Ae elt Disefio rotoe |e band eoaad oe : * Crear un modelo del dominio inicial. + Distinguir entre atributos correctos e incorrectos. + Afiadir las clases conceptuales de especificacion, cuando sea oportuno. | : * Comparar y contrastar las vistas conceptual y de implementacién. i Plan de Des. | de Software | Gestion del A] Proyecto = = we y = Introducci6n "e : ot 7 . k is | oe Marco de Un modelo del dominio se utiliza con frecuencia como fuente de inspiracién para el di- Desarrollo sefio de los objetos software, y serd una entrada necesaria para varios de los siguientes | Pruebas Entorno 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. \ ‘ sie ee cece Figura 9.6. Muestra de la influencia de los artefactos UP. 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 creacidn de modelos del dominio. Los siguientes dos capitulos trataran mas extensamente las téc- nicas de modelado del dominio —afiadiendo atributos y asociaciones—. | i | Los casos de uso son un importante artefacto del analisis de requisitos, pero no son orientados a objetos. 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 0 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 implementaci6n. 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 componentes 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 descomposicién de un dominio de interés en clases conceptuales individuales u objetos —las cosas de las que somos conscientes—. Un modelo del dominio es una representaci6n 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 edicién de este libro), modelo de objetos del dominio y modelos de objetos de andlisis”. 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 0 clases conceptuales. « Asociaciones entre las clases conceptuales. * Atributos de las clases conceptuales. Por ejemplo, la Figura 10.1 muestra un modelo del dominio parcial. Ilustra que las cla- ses conceptuales Pago y Venta son significativas en este dominio, que un Pago esta 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 notacién 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 0 clases conceptuales del dominio. También describe una abstraccién de 2 ‘También estin relacionados con los modelos conceptuales entidad-relaci6n, que son capaces de mostrar vis- tas de los dominios puramente conceptuales, pero que han sido ampliamente re-interpretados como modelos de da- tos para el disefio de bases de datos. Los modelos del dominio no son modelos de datos. ) Se utiliza Modelo del Dominio en maytisculas cuando deseo resaltar que es un modelo oficial definido en el UP, frente al concepto bien conocido de “modelos de dominio” MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 123 concepto 7 u objeto oO [_ tineadeverta Registra-venta-de Atioulo del dominio | eanided loa ; 1 Het = * 6 Al " [ asociacion By... Gontenida-en Imacenado-en 7 1 Venta Tienda atributos Me 0} fecha ' direecion hora i nombre 1 1 ‘Alberga Pagado-mediante fae : Capturada-en > Registro Pago 4 1 cantidad | Figura 10.1. Modelo de! dominio parcial —un diccionario visual—. El ndmero de cada extremo de la linea indica la multiplicidad, que se describird en un capitulo posterior. las clases conceptuales, porque hay muchas cosas que uno podria 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 0 en algun otro sitio. Pero es facil 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 informaci6n del dominio. Los modelos del dominio no son modelos de componentes software Un modelo del dominio, como se muestra en Ja Figura 10.2, es una representacién de las cosas del mundo real del dominio de interés, no de componentes software, como una clase Java o C+ + (ver Figura 10,3), u objetos software con responsabilidades. Por tan- to, los siguientes elementos no son adecuados en un modelo del dominio:UML Y PATRONES visualizacion de conceptos del mundo real del dominio de interés noes una tepresentacién de una clase software Figura 10.2, Un modelo del dominio muestra clases conceptuales del mundo real, no clases software. ae eee eee artefacto software; no forrma Bi parte del modelo del dominio Venta faerie ee ~ ———| 6 clase software; no forma @ fecha parte del modelo del dominio| hora imprimir() Figura 10.3. Un modelo del dominio no muestra artefactos software 0 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 cla- se conceptual podria considerarse en términos de su simbolo, intensién, y extension {MO95] (ver Figura 10.4). ¢ Simbolo: palabras o imagenes que representan una clase conceptual. + Intensién: la definicién de una clase conceptual. * Extensién: cl 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 podria es- Enel modelado de objetos, normalmente hablamos de responsabilidades relacionadas con los componentes software. Y los métodos son puramente conceptos software. Pero el modelo de dominio describe conceptos del mun- do real, no componentes software. Es importante considerar las responsabilidades de los objetos durante el trabajo de diseito; solo que no forma parte de este modelo. Un caso valido en el que se podrian mostrar las responsabili- dades en un modelo de dominio es si incluye roles de trabajadores humanos (como el Cajero), y el modelador desea recoger las responsabilidades de estos trabajadores humanos MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 125 Venta o- simbolo del concepto & fecha hora | "Una venta representa elhecho de una transicion | o- intensién de! concepto bs de compra, Sucede un dia ya.una hora" LEE EEE eee a ventas | Ne? ° extension del concepto be o Figura 10.4. Una clase conceptual tiene un simbolo, una intensién y una extension. tablecer que “representa el hecho de una transaccién de una compra, y tiene una fecha y una hora”. La extensiGn 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 descomposici6n de! dominio Los problemas del software pueden ser complejos; la descomposicién —divide y ven- cerds— 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 descomposicion es por procesos 0 por funciones. Sin embargo, en el andlisis orientado a objetos, la dimensién 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 10.2. 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 [vena Figura 10.5. Modelo del dominio parcial en el dominio de fa tienda. identificacién de las clases conceptuales Nuestro objetivo es crear un modelo del 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 elaboracidn. En cada una, el modelo de do- minio 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 estd limitada al escenario de pago en efectivo de Procesar Venta; por tanto, se creara un modelo de dominio parcial uinicamente para reflejar eso —no mas—. La tarea central es, por tanto, identificar las clases conceptuales relacionadas con el escenario que se est4 disefiando. A continuacién pre ceptuales: entamos una guia util para la identificacidn de las clases con- Es mejor especificar en exceso un modelo del dominio con muchas clases conceptuales | de grano fino que especificar por detecto. | a j 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 Ja etapa de identificacién inicial, y des- cubrirlas mas 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 del dominio), 0 porque la clase conceptual no tiene atributos. Es valido tener clases conceptuales sin atributos, 0 clases conceptuales con un rol pu- ramente 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. Utilizacidn de una lista de categorfas de clases conceptuales. 2. Identificacién de frases nominales. Otra excelente técnica para el modelado del dominio es el uso de patrones de ana- lisis, que son modelos de dominios parciales existentes creados por expertos, utilizando libros publicados como Analysis Patterns [Fowler96] y Data Model Patterns {Hay96]. Utilizaci6n de una lista de categorias de clases conceptuales Comience la creacién de un modelo del dominio haciendo una lista de clases concep- tuales candidatas. La Tabla 10.1 contiene muchas categorfas habituales que, normal- mente, merece la pena tener en cuenta, aunque no en ningtin orden particular de impor- tancia. Los ejemplos se han extrafdo 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 o fisicos Registro Avion especificaciones, disefios o descripciones | EspecificacionDelProducto de la cosas DescripcionDelVuelo lugares Tienda transacciones | Venta, Pago Reserva lineas de la transaccién LineaDeVenta roles de la gente | Cajero | Piloto contenedores de otras cosas Tienda, Lata Avion cosas en un contenedor Articulo Pasajero otros sistemas informaticos SistemaAutorizacionPagoCredito 0 electromecanicos extemos al sistema ConirolDeTraficoAereo conceptos abstractos Ansia Acrofobia organizaciones DepartamentoDeVentas | CompattiaAerea hechos Venta, Pago, Reunion | Vuelo, Colision, Aterrizaje continéa* 128 UML Y PATRONES i$ Tabla 10.1. Lista de-categorias de clases conceptuales. (Continuacion) Categoria de clase conceptual Ejemplos procesos (normalmente no.se representan | VentaDeUnProducto como conceptos, pero podria ocurrir) ReservaUnAsiento reglas y politicas PoliticaDeReintegro PoliticaDeCancelacion catalogos CatalogoDeProductos CatalogoDePiezas registros de finanzas, trabajo, contratos, Recibo, LibroMayor, ContratoEmpleo cuestiones legales RegistroMantenimiento instrumentos y servicios financieros LineaDeCredito Stock manuales, documentos, ListaDeCambiosDePreciosDiarios articulos de referencia, libros ManualReparaciones Descubrimiento de clases conceptuales mediante la identificacion de frases nominales Otra técnica Util (debido a su simplicidad) recomendada en [Abbot83] es el andlisis lin- giiistico: identificar los nombres y frases nominales en las descripciones textuales de un dominio, y considerarlos como clases conceptuales 0 atributos candidatos. Se debe tener cuidado con este método; no es posible realizar una correspondencia mecanica de nombres a clases, y las palabras en lenguaje natural son ambiguas. En cualquier caso, es otra fuente de inspiracidn. Los casos de uso en formato com- pleto constituyen una descripcién excelente a partir de la cual extraer este andlisis. Por ejemplo, se puede utilizar el escenario actual del caso de uso Procesar Venta. Escenario principal de éxito (o Flujo Basico): . El Cliente llega a un terminal PDV con mercancias y/o servicios que comprar, . El Cajero comienza una nueva venta. . El Cajero introduce el identificador del articulo. . El Sistema registra la linea de ta venta y presenta la descripcidn del articulo, precio y suma parcial. El precio se caicula a partir de un conjunto de reglas de precios. E! Cajero repite los pasos 3-4 hasta que se indique. . El Sistema presenta el total con los impuestos calculados. . El Cajero le dice al Cliente ei total y solicita el pago. . El Cliente paga y el Sistema gestiona el pago. . El Sistema registra la venta completa y envia la informacion 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) 9. El Sistema presenta el recibo. 10. El Cliente se va con el recibo y las mercancias (si es el caso). Sena PNON 10.3. SUALIZACION DE-CONCEPTOS“ yee mA Extensiones (0 Flujos Alternativos): 7a. Pago en efectivo: 1. El Cajero introduce la cantidad de di . 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 identificacién de frases nomi- nales. 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, “Contabilidad” y “comisiones”), y algunas podrfan ser atributos de las clases conceptuales. Por favor, dirfjase a la siguiente seccién y al capitulo sobre los atributos, para obtener los consejos que permiten diferenciar entre los dos. Un punto débil de este enfoque es la imprecisién del lenguaje natural; frases no- minales diferentes podrian representar la misma clase conceptual o atributo, entre otras ambigiiedades. Sin embargo, se recomienda que se combine con la técnica la Lis- ta de Categorias de Clases Conceptuales. 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 esta restringida a los requisitos y simplificaciones que se estén 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 coleccion algo arbitraria de abstracciones y vo- cabulario del dominio que el modelador considera relevantes. En cualquier caso, si- guiendo ® estrategia de identificacin, diferentes modeladores produciran listas similares. *N. del T.: Aunque siguiendo las convenciones para nombrar las clases no se utilizarfa la preposicién, en este caso al igual que en EspecificacionDelProducto y LineaDe Venta, se han utilizado para mejorar la legibilidad del texto.130 UML Y PATRONES Objetos de informes: zincluir el recibo en el modelo? 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 util mostrar un informe de otra informacién en un modelo del 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 de] negocio: normalmente, confiere al portador del recibo, el derecho a devolver los articulos comprados. Esta es una razon para mostrarlo en el modelo. Puesto que la devolucién de articulos no esta siendo considerada en esta iteracién, el Recibo serd 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 dei dominio Aplique los siguientes pasos para crear un modelo del dominio: 1. Liste las clases conceptuales candidatas, utilizando las técnicas de la Lista de Cate- gorias de Clases Conceptuales y la identificacién de frases nominales, relacionadas con los requisitos actuales en estudio. Represéntelos.en un modelo del dominio. 3. Afiada las asociaciones necesarias para registrar las relaciones que hay que mante- ner en memoria (se discutira 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 titil auxiliar es aprender y copiar patrones de andlisis, que se discutiran en un capitulo posterior. Nombrar y modelar cosas: el cartégrafo La estrategia del cartégrafo se aplica tanto a los mapas como a los modelos del dominio. ae | Haga un modelo del dominio con el espiritu del modo de trabajo de los cartégrafos: | © Utilice 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 wtilice 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” —los términos utilizados por el personal de la biblioteca—. Un cart6grafo elimina las cosas de un mapa si no se consideran relevantes para el proposito 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 montaiias que no existen. Igualmente, el modelo del dominio deberfa excluir cosas que no se encuentran en el dominio del problema que se esta 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 Quizas el error mas tipico al crear un modelo del dominio es representar algo como un atributo cuando deberia 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 numero o texto en el mundo real, X es probablemente una clase conceptual, no un atributo. | Como ejemplo, {deberia ser la tienda un atributo de Venta, o una clase conceptual se- parada Tienda? Venta tee Venta Tienda tienda fe numeroTelefono En el mundo real, una tienda no se considera un ntimero o un texto —el término su- giere una entidad legal, una organizacién, y algo que ocupa espacio—. Por tanto, Tien- da debe ser un concepto. Vuelo Vuelo | Aeropuerto destino FH nombreoA bitrariamente, pero el personal involucrado también habria entendido TPDV. 132 UML Y PATRONES MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 133 Otro ejemplo, considere el dominio de las reservas de vuelos. ;Deberia ser el desti- dientes de la implementacién, Registro es atractivo y util’. Se podria considerar Registro ‘ no un atributo de Vuelo, o una clase conceptual aparte, Aeropuerto? : justamente, para representar tanto la clase conceptual de un sitio que registra las ventas, En el mundo real, un aeropuerto de destino no se considera un nimero o un texto —es f ome anal abstecel onl de aries clases de terminales: come ute Dy. |. una cosa grande que ocupa espacio—. Por tanto, Aeropuerto deberia ser un concepto Ambas elecciones tienen valor; en este caso de estudio se ha elegido Registro algo ar- En caso de duda, considérelo un concepto separado. Los atributos deberian ser bastante raros en un modelo del dominio. 10.6. Modelado del mundo irreal Algunos sistemas software son para dominios que encuentran muy poca analogfa con do- | A al 7 minios naturales 0 de negocios; el software para las telecomunicaciones es un ejemplo. | 10.5. Resolucion de clases conceptuales similares: Todavia es posible crear un modelo del dominio en estos dominios, pero requiere un alto Registro vs. “TPDV grado de abstraccién y olvidarse de disefios familiares. Por ejemplo, algunas de las clases conceptuales candidatas relacionadas con con- TPDY son las siglas de terminal de punto de venta. En el lenguaje informatico, un ter- hE : : : & P Bua} ee mutadores de telecomunicaciones son: Mensaje, Conexion, Puerto, Dialogo, Ruta, Pro- f minal es cualquier dispositivo de un sistema, como un PC cliente, un PDA en red ina- ldmbrico, etcétera. En los primeros tiempos, mucho antes a los TPDVs, una tienda tocolo. | mantenia un registro —un libro en el que se apuntaban las ventas y pagos—. Con el tiempo, esto se automatiz6 en “cajas registradoras” mecdnicas. Hoy en dia, un TPDV de- St neae sempeiia el rol del registro (ver Figura 10.6). 10.7. Clases conceptuales de especificacion o descripcion conceptos similares con cee BCE nombres diferentes La siguiente discusién podria, al principio, parecer relacionada con un tema raro y alta- mente especializado. Sin embargo, prueba que la necesidad de las clases conceptuales de especificacién (como se definirén) es habitual en muchos modelos del dominio. Por tan- 1 - to, se destaca. TPDV / 0? Registro J Asuma lo siguiente: : 1 1 Registra ~ Registra ~ | * Una instancia de un Anticulo representa un objeto fisico de una tienda; como tal, | podria incluso tener un ntimero de serie. : see ea te * Un Articulo tiene una descripcién, precio, e identificador del articulo (articu- Venta Mea loID), que no se recogen en ningtin otro sitio. Figura 10.6. TPDV y Registro son clases conceptuales similares. * Todo el mundo que trabaja en la tienda tiene amnesia. * Cada vez que se vende un articulo ffsico real, se elimina una instancia de Articulo Un registro es una cosa que recoge las ventas y pagos, pero esto es un TPDV. Sin it al Piers software correspondiente, del “terreno del software”. 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 sim- bolo Registro en lugar de TPDV? Con estas suposiciones, {qué ocurre en el siguiente escenario? Existe una fuerte demanda de las nuevas hamburguesas vegetales que han tenido mu- Primero, como regla empirica, un modelo del dominio no es absolutamente correcto o cho éxito —-ObjetoHamburguesa—. La tienda las vende todas, lo que implica que se eli- equivocado, sino mas o menos util; es una herramienta de comunicacion. minen de la memoria del ordenador todas las instancias de Articulo de los Objeto- ee 7 Hamburguesa. Por el principio del cartégrafo, “TPDV” es un término familiar en el territorio, de ma- nera que es un simbolo util desde el punto de vista de la familiaridad y la comunicacion. © Notese que en los primeros tiempos, un registro era tinicamente una posible implementacién del modo de re- Por el objetivo de la creacién de modelos que representan abstracciones y son indepen- gistrar las ventas. El término ha adquirido un significado generalizado a lo largo del tiempo.. Ba134 UML Y PATRONES Ahora, aqui estd lo esencial del problema: Si alguien pregunta: “;Cudnto cuestan los ObjetosHamburguesa?”, nadie puede contestar, porque el precio se encontraba en las ins- tancias inventariadas, que se eliminaron cuando se vendieron. Notese también que el modelo actual, si se implementa en el software tal y como se des- cribe, contiene datos duplicados y es ineficiente en cuanto al espacio, puesto que la des- cripci6n, el precio y el ID, se duplican en cada instancia de Articulo del mismo producto. La necesidad de especificaci6n o descripcién de las clases conceptuales El problema anterior ilustra la necesidad de conceptos de objetos que sean especifica- ciones 0 descripciones de otras cosas. Para solucionar el problema del Articulo, lo que se necesita es una clase conceptual EspecificacionDelProducto (0 EspecificacionDelArti- culo, DescripcionDelProducto, ...) que recoge la informacién sobre los articulos. Una EspecificacionDelProducto no representa un Articulo, sino una descripeién de la infor- maci6n sobre los articulos. Nétese que incluso si todos los elementos inventariados se venden, y sus correspondientes instancias software de Articulo se eliminan, permanece todavia la EspecificacionDelProducto. Los objetos de descripcién o especificacién estan fuertemente relacionados con las cosas que describen. En un modelo del dominio, es tipico establecer que una Especifi- cacionDeX Describe un X (ver Figura 10.7). Articulo descripcion | Peor precio numeroSerie articulolD EspecificacionDelProducto Articulo descripcion Describe Mejor precio \1 * | numeroSerie articulolD | Figura 10.7. _ Especificaciones o descripciones sobre otras cosas. El “**” significa una multiplicidad de “muchos”, Indica que una EspecificacionDelProducto podria describir a muchos (*) Articulos. La necesidad de clases conceptuales de especificacién es habitual en los dominios de ventas y productos. También es tipica en la fabricacién, donde se requiere una descrip- cion de la cosa que se fabrica, que es distinto de Ja cosa en si misma. Se ha dedicado tiempo y espacio a motivar las clases conceptuales de especificacién porque son muy frecuentes; no es un concepto de modelado raro. MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 135 ~Cuando se requieren las clases conceptuales de especificacién? Las siguientes guias sugieren cudndo utilizar las especificaciones: Afiada una clase conceptual de especificacion o descripcién (por ejemplo, Especifica- cionDelProducto) cuando: Se necesita la descripcién de un articulo o servicio, independiente de la existencia actual de algun ejemplo de esos articulos o servicios. La eliminacién de instancias de las cosas que describen (por ejemplo, Articulo) dan como resultado una pérdida de informacién que necesita mantenerse, debido a la aso- ciaci6n incorrecta de informacién con la cosa eliminada. Reduce informacion redundante o duplicada. Otro ejemplo de especificacion Como otro ejemplo, considere una compaiifa aérea que sufre un accidente catastréfico de uno de sus aviones. Asuma que se cancelan todos los vuelos durante seis meses, pendiente de que se complete la investigacién. También asuma que, cuando se cance- Jan los vuelos, su correspondiente objeto software Vuelo, se elimina de la memoria del ordenador. Por tanto, después de la colisién, se eliminan todos los objetos software Vuelo. Si el tinico registro de los aeropuertos de destino de los vuelos se encuentra en las instancias software Vuelo, que representa un vuelo especifico en una fecha y hora concreta, ya no habra un registro de las rutas de los vuelos de la compafifa. Para solucionar este problema, se necesita una DescripcionDelVuelo (0 Especifica- cionDelVuelo) que describe un vuelo y su ruta, incluso cuando no se ha planificado nin- gtin vuelo concreto (ver Figura 10.8). Descripcion de servicios No6tese que el ejemplo anterior trata sobre un servicio (un yuelo) en lugar de un articulo (como una hamburguesa vegetal). Es habitual que se necesiten descripciones de servi- cios o planes de servicios. Como otro ejemplo, una compaififa de telefonfa mévil vende paquetes con deno- minaciones como “bronce”, “oro”, etcétera. Es necesario tener el concepto de des- cripci6n del paquete (un tipo de plan de servicio que describe las tarifas por minuto, acceso a Internet sin cable, el coste, etcétera) separado del concepto del paquete real- mente vendido (como el “paquete oro vendido a Craig Larman el | de enero de 2002, a $55 al mes”). El departamento de Marketing necesita definir y registrar este plan de servicios 0 DescripcionDelPaqueteDeComunicacionesMoviles antes de que se venda alguno.136 UML Y PATRONES Vuelo ——— Aeropuerto fecha Vuela-a bea numero * + | nombre hora Vuelo Fopscassienani ae Deserite-por__| DesetpcionDelvuelo | Mejor a * 1 | numero | hora * Describe-vuelos-a 1 Aeropuerto nombre Figura 10.8. Especificaciones sobre otras cosas. 10.8. Notacion UML, modelos y métodos: perspectivas multiples El UP define algo denominado Modelo del Dominio, que se representa con la notacién UML. Sin embargo, no existe un término “Modelo del Dominio” en la documentacién oficial de UML. Esto nos revela algo importante: UML simplemente describe tipos de diagramas, como los diagramas de clases y los dia- gramas de secuencia. No superpone un método 0 perspectiva de modelado sobre ellos. Mas bien, un proceso (como el UP) aplica la notacién de la especificacién de UML en el contexto de modelos definidos en el Ambito de una metodologia. Por ejemplo, la notacién 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, etcétera. Por tanto, no debemos confundir la notacién basica de los diagramas UML, con su aplicacién para visualizar distintos tipos de modelos definidos por los metodologistas (ver Figura 10.9). Este punto es aplicable no sdlo a los diagramas de clases UML, sino ala mayoria de la notacio6n UML. Como otro ejemplo de los diagramas de UML que se interpretan de manera diferente en modelos distintos, los diagramas de secuencia UML se pueden utilizar para repre- sentar el paso de mensajes entre los objetos software (como en el Modelo de Disefio del UP), o la interaccidn entre personas y grupos en el mundo real (como en el Modelo de Objetos del Negocio del UP). MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 137 Venta Modelo del Dominio UP Pago 1 Pago-por_1 Notacién del diagrama fecha de clase UML utilizado hora en un modelo esencial que visualiza los conceptos del mundo real. cantidad Venta Modelo de Disefio UP Pago Notacién del diagrama de 1 Pago-por 1_| fecha: Fecha clase UML utilizado en un p>} horalnicio: Hora modelo de especificacion i : que visualiza los jgetDevolucion(): Dinero) getTotal(): Dinero componentes software. cantidad: Dinero Figura 10.9. La notacién de la especificacién UML se puede aplicar en diferentes perspectivas y modelos definidos por un proceso 0 método. Esta idea se pone de relieve en el método orientado a objetos Syntropy [CD94], y Martin Fowler la reitera en UML Distilled [FS00]. Es decir, la misma notacién basada en diagramas se puede utilizar en tres perspectivas y tipos de modelos: 1. Perspectiva esencial o conceptual: se interpreta que los diagramas describen cosas del mundo real o de un dominio de interés. 2. Perspectiva de especificacién: se interpreta que los diagramas (utilizando la misma notaci6n de los modelos esenciales) describen abstracciones software o componentes con especificaciones e interfaces, pero no comprometidas a nin- guna implementacién en particular (por ejemplo, no especificamente una clase C# o Java). 3. Perspectiva de implementacién: se interpreta que los diagramas (utilizando la misma notacién de los modelos esenciales) describen implementaciones soft- ware con una tecnologia y lenguaje particular (como Java). Superposicion de terminologia: UML vs. métodos En la especificaci6n UML, las cajas rectangulares mostradas en la Figura 10.9 se deno- minan clases, pero nétese que en UML, este término abarca una variedad de fendmenos —cosas fisicas, cosas del software, eventos, etcétera’—. Un proceso 0 método super- pondra una terminologia alternativa sobre UML. Por ejemplo, en el UP, cuando las cajas de UML se dibujan en el Modelo del Dominio, podrfan llamarse conceptos del dominio o clases conceptuales; e] Modelo del Dominio ofrece una perspectiva conceptual. En el UP, cuando las cajas UML se dibujan en el Modelo de Disefio, se denominan oficial- mente clases de disefio: el Modelo de Disefio ofrece una perspectiva de especificacién o implementaci6n, como quiere el modelador. 7 Una clase UML es un caso especial de un elemento de modelado UML muy general el clasificador —algo con caracteristicas estructurales y/o comportamiento, incluyendo clases, actores, interfaces y casos de uso—.UML Y PATRONES Independientemente de 1a definicién, la cuestiGn importante es que es Util distinguir entre la perspectiva de un analista que mira conceptos del mundo real tal como una ven- ta (una perspectiva conceptual), y los disefiadores de software que especifican compo- nentes software como la clase software Venta (una perspectiva de especificacién o im- plementacion). UML se puede utilizar para ilustrar ambas perspectivas con una notacién y pers- pectiva muy similar, asf que es muy importante tener en cuenta qué perspectiva se esta tomando. Para mantener las cosas claras, este libro utilizara los términos relacionados con las clases de la siguiente forma, que es consistente con UML y el UP: * Clase conceptual: concepto o cosa del mundo real. Una perspectiva conceptual o esencial. El Modelo de! Dominio del UP contiene clases conceptuales. Clase software: una clase que representa una perspectiva de especificacin o imple- mentaci6n de un componente software, independientemente del proceso o método. Clase de disefio: un miembro de! Modelo de Disefio del UP. Es un sindénimo de clase software, pero por alguna raz6n deseo resaltar que es una clase del Modelo de Disefio. El UP permite que una clase de disefio tenga perspectiva de especificacién o imple- mentacion, segun desee el modelador. Clase de implementacion: una clase implementada en un lenguaje orientado a objetos como Java. Clase: como en UML, el término general que representa o una cosa del mundo real (una clase conceptual) o del software (una clase software). 10.9. Reduccion del salto en la representacion Por favor, mire atentamente la Figura 10.10. {Por qué los libros y educadores que pre- sentan el disefio de objetos comtin s6lo muestran el uso de clases software cuyos nom- bres reflejan el vocabulario del dominio? {Por qué eligen un nombre de clase software como Venta, y qué hace una Venta? Simplemente, eligiendo nombres que reflejan el vocabulario del dominio (Venta) se favorece la rapida comprensién y proporciona una pista acerca de lo que se espera del trozo de cédigo de la clase software Venta. Tenemos un modelo mental del dominio en cuestion (por ejemplo, una tienda que vende cosas). En el mundo real, sabemos que una venta tiene una fecha. En consecuencia, si creamos una clase Java llamada Venta, y le damos la responsabilidad de conocer sobre una venta real y su fecha, entonces la clase Java Venta se corresponde de alguna manera con nuestro modelo mental del dominio real; es decir, apela a nuestra “intuicién” del dominio. Ei Modelo del Dominio proporciona un diccionario visual del vocabulario y conceptos de! do- minio a partir de los cuales nos inspiramos para nombrar algunas cosas del disefio software. Esto se relaciona con el tema del salto de la representaci6n 0 salto semantico —cl salto entre nuestro modelo mental del dominio y su representacién en el software—. BeSEPEES PEEPS PEEPS PEEPS ERCP P a PES EEE EEE PEE EEE PEE Sree Ere eoP CEES EPPS MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS Modelo del Dominio UP Vista del personal involucrado de los conceptos mas relevantes del dominio 139 Un pago en el Modelo del 1 Venta Dominio es un coneepto, pero Pago __|1 Pago-por 1 un Pago en el Modelo de Disefio cantidad fecha es una clase software. No son hora o mismo, pero el primero inspiré i el nombre y definicion inspira del segundo. —_—_— — objetos — —— —— — y nombres en Esto reduce el salto de la representacion. 7 Venta Pago $$ Esta es una de las grandes ideas FI 5 1 Pago-por 1 fecha: Fecha de la tecnologia de objetos cantidad: Dinero eee horalnicio: Hora getDevolucion(): Dinero getTotal{): Dinero Modelo de Disefio UP EI desarrollador orientado a objetos se ha inspirado en el dominio del mundo real al crear las clases software. Por tanto, el salto de la representacién entre el modo en el que el personal involuerado concibe el dominio, y su representacidn en el software, se ha reducido. Figura 10.18. En el disefio y programacién de objeios, es normal crear clases software cuyos nombres ¢ informacién se inspira en el dominio del mundo real. En un extremo, podriamos programar directamente la aplicacién de PDV NuevaE- ra en cédigo binario para invocar el conjunto de instrucciones del procesador. Enten- demos que el salto en las representaciones es enorme, y existird en el software un cos- te real —aunque dificil de cuantificar— con un salto en la representacién tan grande, porque es dificil de entender y relacionar con el dominio del problema. Cercano al otro extremo del espectro, estan las tecnologias de objetos que nos permiten partir el cédigo en clases cuyos nombres reflejan el tipo de particién que percibimos en el dominio. En el mundo real percibimos una “parte” (o hecho) denominada venta, luego en el terreno del software tenemos una clase software denominada Venta. Esta estrecha correspondencia uno-a-uno entre el vocabulario del dominio y nuestro vocabulario del software y sus par- ticiones reduce el salto de la representacién. Esto acelera la comprensién del cédigo exis- tente (porque funciona de la manera que esperamos, conociendo e] dominio) y sugiere formas “naturales” para extender el cddigo que se corresponden andlogamente con el do- minio, 0 apelan a nuestras intuiciones del dominio. Diciéndolo sencillamente, el modelo software nos recuerda al modelo mental 0 conceptual, y funciona de manera predecible. Los modelos software proporcionan una ventaja practica al reducir el salto de la re- presentacién. La mayoria de los ingenieros del software saben que es verdad, incluso si es dificil de cuantificar. De hecho, una prueba de esto es que algunos de los programa- dores Java, de forma deliberada complican el cédigo fuente para que sea dificil hacer in- genicria inversa a partir de los bytecodes, cambiando los nombres de las clases y los mé- todos Java de manera que sean ininteligibles y, por tanto, ya no evoquen nuestra vision del dominio, aunque las estructuras de control y datos no se cambian.140 UML Y PATRONES Por supuesto, la tecnologia de objetos es valiosa también porque puede favorecer el disefio de sistemas elegantes, débilmente acoplados, que pueden crecer y ampliarse f4- cilmente, como veremos en lo que queda del libro. Una reduccién del salto en la repre- sentacién es titil, pero se puede sostener que es secundario a la ventaja que ofrecen los objetos de facilitar los cambios y extensiones, y el soporte que ofrecen para el manejo y ocultacién de la complejidad. 10.10. Ejemplo: el Modelo del Dominio del PDV NuevaEra 10.11. La lista de clases conceptuales generadas para el dominio del PDV NuevaEra se podria representar gréficamente (ver Figura 10.11) para mostrar el comienzo del Modelo del Dominio. Registro Articulo Tienda Venta Lineal , , Daven Cajero Cliente Encargado at Catalogo Especificacion| 7 DeProductos DelProducto Figura 10.11. Modelo del Dominio inicial Las consideraciones acerca de los atributos y asociaciones del Modelo del Dominio se posponen a capitulos siguientes. Modelos del Dominio en el UP Como se sugiere en el ejemplo de la Tabla 10.2, un Modelo del Dominio, normalmente, se inicia y completa en la elaboracién. Inicio Los modelos del dominio no se incentivan fuertemente en la fase de inicio, puesto que el propésito del inicio no es llevar a cabo un estudio serio, sino decidir si merece la pena un estudio mas profundo en el proyecto, en una fase de elaboracién. Elaboracion El Modelo del Dominio se crea sobre todo durante las iteraciones de la elaboracién, cuando la necesidad més importante es entender los conceptos relevantes y trasladar al- gunos a clases software durante el trabajo de disefio. MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 141 Tabla 10.2. Muestra de los artefactos UP y evolucién temporal. c — comenzar, r - refinar. Disciplina Artefacto Inicio| Elab. | Const. | Trans. lteracion >| 11 | E1...En|C1...Cn|T1...T2 Modelado del Negocio | Modelo del Dominio c Requisitos Modelo de Casos de Uso c t Vision c r Especificacion Complementaria | c t Glosario c r Disefio Modelo de Disefio c r Documento de Arquitectura SW c Modelo de Datos c r implementacién Modelo de Implementacion c r r Gestion del Proyecto | Plan de Desarrollo SW c r r r Pruebas Modelo de Pruebas c r Entorno Marco de Desarrollo c r Aunque, irénicamente, se dedicarén un nimero significativo de paginas a explicar el modelado de los objetos del dominio, en manos experimentadas el desarrollo de un mo- delo del dominio (parcial, desarrollado incrementalmente) en cada iteracién deberfa durar slo unas pocas horas. Esto se acorta mediante el uso de patrones de anilisis predefinidos. El Modelo de Objetos del Negocio del UP vs. el Modelo del Dominio El Modelo del Dominio del UP es una variacién oficial del menos comtin Modelo de Objetos del Negocio del UP (BOM, Business Object Model). E] BOM del UP —no con- fundir con el modo en el que otras personas 0 métodos podrfan definir un BOM, que es un término ampliamente utilizado con significados diferentes— es un tipo de modelo de empresa utilizado para describir el negocio completo. Podria utilizarse al Nevar a cabo la ingenierfa o reingenierfa de procesos del negocio, independiente de cualquier aplicacién software (como el PDV NuevaEra). Citando textualmente: [EI BOM del UP] sirve como abstraccién del modo en el que los trabajadores y las entidades del negocio necesitan relacionarse y c6mo necesitan colaborar para llevar a cabo el negocio. [RUP] El BOM se representa con varios diagramas diferentes (clase, actividad y secuencia) que muestran como funciona (0 deberia funcionar) toda la empresa. Es més Util si se rea- liza ingenieria de procesos de negocio por toda la empresa, pero ésta es una actividad menos comtin que la creacién de una tinica aplicacién software. En consecuencia, el UP define el Modelo del Dominio como un artefacto subcon- junto o una especializacién del BOM, que se crea normalmente. Citando textualmente: Puedes elegir desarrollar un modelo de objetos del negocio “incompleto”, enfo- cado a explicar “cosas” y productos importantes para un dominio. ... A menudo se hace referencia a éste como modelo del dominio. [RUP] BE142 UML Y PATRONES 10.12. Lecturas adicionales Object-Oriented Methods: A Foundation de Odell proporciona una sélida introduccién al modelado del dominio conceptual. También resulta titil Design Object Systems de Cook and Daniel. Analysis Patterns de Fowler ofrece importantes patrones de los modelos del dominio, y se recomienda sin ninguna duda. Otro libro bueno, que describe patrones de los mo- delos del dominio es Data Model Patterns: Conventions of Thought de Hay. Los con- sejos de los expertos en el modelado de datos, que entienden la distincién entre los mo- delos conceptuales puros y los modelos de los esquemas de bases de datos, pueden ser muy ttiles para el modelado de los objetos del dominio. Java Modeling in Color with UML [CDL99] contiene més consejos relevantes sobre el modelado del dominio de lo que sugiere el titulo. El autor identifica patrones comunes en los tipos relacionados y sus asociaciones; el aspecto de color es realmente una vi- sualizacién de las categorias tipicas de estos tipos, como descripcién (azul), roles (ama- rillo), y momento-intervalos (rosa). El color se utiliza para ayudar a ver los patrones. Desde el trabajo original de Abbot, el andlisis lingiifstico ha adquirido técnicas mas sofisticadas para el andlisis orientado a objetos, generalmente denominado modelado del lenguaje natural, o una variante. Véase [Moreno97] como un ejemplo. 10.13. Artefactos del UP La influencia entre los artefactos, destacando el Modelo del Dominio, se muestra en la Figura 10.12. MODELO DEL DOMINIO: VISUALIZACION DE CONCEPTOS 143 Muestra de artefactos UP —~ Artefactos parciales, /” Modelo» refinados en cada Mode aae ifdel Boma iteracion del Negocio 1 I i i Sah Aes ceoeean San a- el estado cambia elaboracién de peer eteete en los objetos del algunos términos : dominio, atributos, en e| modelo asociaciones del dominio Modelo de Casosde Uso 2 2 mee OY Requisitos Es lo {tool} \ Es Glosario I a eal texto de diagramas diagramas los casos de casos de secuencia jasgueecones de uso de uso del sistema Se ore. Doc. de Arquitec- seri ture de Software Jo de D pooner clases software Disefio ros | en la capa det dominio Rey he del disefio se inspiran SEE en los nombres, atributos y asociaciones del modelo del dominio Plan de Des. de Software Gestion del Proyecto BRB ene Marco de Pruebas Desarrollo Pruebas Entorno Figura 10.12. Muestra de la influencia entre los artefactos UP.