Y PATRONES Introduccién al andlisis y disefio orientado a objetos CRAIG LARMAN PRENTICE HALLUML Y PATRONES INTRODUCCION AL ANALISIS Y DISENO ORIENTADO A OBJETOS CRAIG LARMAN ‘Versién en espafiol: ‘Luz Maria Hendndez Rodriguez Traductora profesional Con revisién técnica de: Ing. Humberto Cardenas Anaya No. de Entrada x Ditcwor dele Careradengentera en Sistemas Conpuaconaes "5, 3) 95 568 4 Profesor del Departamento de Sistemas de Informacién, = Instinuo Teenolgico y de Estudios Superiores de Monterrey, Campus Estado de México PRENTICE ‘ey HALL ‘Longman MEXICO + ARGENTINA + BOLIVIA « BRASIL.» COLOMBIA + COSTA RICA + CHILE * ECUADOR EL SALVADOR + ESPANA + GUATEMALA + HONDURAS « NICARAGUA + PANAMA PARAGUAY « PERU + PUERTO RICO + REPUBLICA DOMINICANA+ URUGUAY « VENEZUELA [AMSTERDAM - HARLOW + MIAMI e MUNICH + NUEVA DELH+ MENLO PARK = NUEVA JERSEY [NUEVA YORK - ONTARIO PARIS »SINGAPUR SYDNEY -TOKIO TORONTO ZURICH SIBUREjemplo de actividades de desarrollo Patrones generales de software para asignar responsabilidades (GRASP) 1, Detitslan | 2 Croat ope | ~ (Patri Descripcién | = 2Quién asumird la responsabilidad en el caso general? 3. efi 4. Rglsariosminos | Asignar una responsabilidad al experto en informacién: la clase que posee la informacién necesaria para ee | eee camp con a eaponsblidad Pant Snags | aang — Rain rea? ~ | yy elaboracion -@t prototipo. (de alto nivel y esenciaies)| od 2 Asignar a la clase B la responsabilidad de crear una instancia de clase A, si se cumple una de las si- iene omaione: Tiamat | outa wien || ete — contene sistraA pened eared ee sbbnsp-meok 4 Becntine 5. Buti A muy de crea eC aiteraiognr ap F Contador {Rilnaininisra mn ent el stoma? ‘Asignar la eesponsabilidad de administrar un mensaje de eventos del sistema a una clase que represente tuna de las siguientes opciones: 1, EI negocio o a organizacion global (un controlador de fachada) 2. El “sistema” global (un controlador de fachada). 3. Un ser animado del dominio que realice el trabajo (un controlador de papeles). 44. Una clase artificial (Fabricacion Pura) que represente el caso de uso (un controlador de casos de uso). Bajo Acoplamiento | ;Cémo dar soporte a poca dependencia y a una mayor reutlizaciin? (evaluativo) | Asignar las responsabilidades de modo que se mantenga bajo acoplamiento. {Como mantener controlable la complejidad? [Asignar las responsabilidades de modo que se mantenga una alta cohesion? 2Quién, cudndo el comportamiento varia sequin el tipo? Cuando varia el tipo (clase) de alternativas o comportamientos relacionados, asignar la responsabilidad del comportamiento —mediante operaciones polimérficas— a los tipos en que varia el comportamiento Fabricacin Pura | - : Desde el punto de vista del andlisis y del disefio orientados a objetos, esta activi- . ; oe dad se parece al disefio orientado a objetos que pone de relieve la asignacién 15.3 ¢Cudles son los papeles o las funciones en la organizacion? de responsabilidades. La asignacion significa distribuir las funciones y las respon- sabilidades entre varios objetos de software en la aplicacién, del mismo modo que El siguiente paso consiste en identificar los papeles de las personas que intervendran se asignan a los papeles de los empleados. Los objetos de software normalmente en los procesos: cliente, representante de ventas, ingeniero de software, etcétera colaboran o interactian para cumplir con sus responsabilidades, como lo hacen las En la perspectiva del andlisis y del disefio orientados a objetos, este paso nos recuerda emma al andlisis del dominio orientado a objetos que expresamos con un modelo con- La descripcién de la asignacién de las responsabilidades y las interacciones de objetos ceptual, Este modelo presenta las diversas categorias de las cosas en el dominio; no a menudo se expresan grificamente con diagramas de disefio de clase y con dia- solo los papeles de las personas sino también todas las cosas de interés, sey gramas de colaboracién; unos y otros muestran la definicién de clases y el flujo de observa en la figura 1.4. mensajes entre los objetos de software.1 ANALISIS ¥ DISESO ORIENTADOS A ORJETOS 1 - ANALISIS Y DISERO ORIENTADOS A ORJETOS z z a Por ejemplo, en el juego de dados el caso de uso de Juega un Juego, ieee | a | | rie bak d ! Caso de uso: Juega un Juego. : = - | Participantes: Jugador. 2Cuales son los ‘Anilisis de ea ; procesos del negocio? requerimientos Casos de uso Descripeién: Este caso de uso comienza cuando el jugador recoge y hace rodar los dados. {Cuales son los papeles de Silos puntos suman siete, gana y los empleados? Analisis del dominio Modelo conceptual pierde si suman cualquier otro ~ = — — niamero. 2Qué funciones cumplen los | Asignacion de Diagramas de diseno de leados? 2cémo nsabilidades, clases, diagramas d pane imeractan eos? diseho de interacclones | colaboracion .6.2 — Definicién de un modelo conceptual anilisis orientado a objetos tiene por finalidad estipular una especificacién del . . dominio del problema y los requerimientos desde la perspectiva de la clasifics por 1.6 Un ejemplo del andlisis y del disefio orientados a objetos objetos y desde el punto de vista de entender los términos empleados en el dominio, Para descomponer el dominio del problema hay que identificar los conceptos, los atributos y las asociaciones del dominio que se juzgan importantes. El resultado ecesita abundante informacion para explicar cabalmente el puede expresarse en un modelo conceptual, el cual se muestra graficamente en un grupo de diagramas que describen los conceptos (objetos). Un simple ejemplo Se nos permite ver todo anélisis y el diseto orientados a objetos. Para no perdernos en el panorama, muchos detalles, ofrecemos al lector una explicacién sucinta sobre algunos de los pasos y diagramas usando para ello un ‘ejemplo simple: un “juego de dados” en que un jugador lanza dos dados. Si el total es siete, gana y de lo contrario pierde, Las notaciones utilizadas forman parte del lenguaje UML. Observe, por favor, que en el ejemplo no estan representados todos los pasos posibles ni los diagramas; tan s6lo aparecen los mas comunes y esenciales. Por ejemplo, como se aprecia en la figura 1.5, en el dominio del juego de dados, una parte del modelo conceptual muestra los conceptos Jugador, Dados y JuegodeDados, 1.6.1 Definicidn de los casos de uso sus asociaciones y atributos. Para entender los requerimientos se necesita, en parte, conocer los procesos del dominio -—— — yeel ambiente externo, 0 sca los factores externos que participan en los procesos. Dichos [agar ones Dados procesos de dominio pueden expresarse en casos de uso, o sea, en descripciones narta- a ‘valorMostraco tivas de los procesos del dominio en un formato estructurado de prosa, ; L > J sce | 1 Detar ete pamiss| | Defi os casos el modo Jos diag iagremas de JuegodeDados moet 2 | e oe ep os casos de uso no son propiamente un elemento del andlisis orientado a objetos; se Figura 1.5 Modelo conceptual del juego de dados. limitan a describir procesos y pueden ser igualmente eficaces en un proyecto de tec- nologia no orientada a objetos. No obstante, constituyen un paso preliminar muy wil El modelo conceptual no es una descripcién de los componentes del software; repre- porque describen las especificaciones de un sistema, senta los conceptos en e! dominio del problema en el mundo real 10 4 -1.6.3 1 ANALISIS ¥ DISENO ORIENTADOS A OBJETOS Definicién de los diagramas de colaboracién E] disefio orientado a objetos tiene por objeto definir las especificaciones légicas del software que cumplan con los requisitos funcionales, baséndose en la descomposicion por clases de objetos. Un paso esencial de esta fase es la asignacién de responsabi- lidades entre los objetos y mostrar como interactian a través de mensajes, expresados en diagramas de colaboracién. Estos presentan el flujo de mensajes entre las ins- tancias y la invocacién de métodos. 1 ANALISIS ¥ DISENO ORIENTADOS A ORJETOS Por ejemplo, en el juego de dados, al examinar el diagrama de colaboracién, obtene- ‘mos el siguiente diagrama del disefio de clases. Puesto que tn mensaje juego se envia a una instancia Jugador, Jugador requiere un método jugar, mientras que Dado requiere un método lanzar. A diferencia del modelo conceptual, este diagrama no muestra gréficamente concep- tos del mundo real; describe inicamente los componentes del software. Para indicar de qué manera los objetos se conectan entre sia través de atributos, una linea con una flecha en la punta indicara un atributo. Por ejemplo, JuegodeDados posee un atributo que apunta a una instancia de un Jugador. Por ejemplo, supongamos que se desea una simulacién en el software del juego de dados, El diagrama de colaboracién de la figura 1.6 muestra graficamente el paso esencial del juego, enviando mensajes a las instancias de las clases Jugador y Dado. Jugador Dado nombre, i Laren 2] waerMoatrado - | veer ents Jugar() Janzar() poet == pegey | tert it — (pirea / a — 2 og 2aselana) — 1 12:bada ogodedade inte Figura 1.6 Diagrama de colaboracién que muestra los mensajes entre lot obetos ccootwne vaalzar) 1.6.4 Definicién del disefio de clases Figura 1.7 Diagrama del disefio de clases para los componentes de software. El diagrama del disefio de clases de la figura 1.7 no esta completo; representa tinica- mente el inicio de las especificaciones del software que se requieren para definir cabalmente cada clase. Para definir una clase es preciso contestar varias preguntas: = .Cémo se conectan unos objetos a otros? ‘= | expands Be > 83s os Ge gon Presupueso, james da Lae ‘rogram ‘te os tse Se jr? BE 28g PEEEEE EEE EEE EEE aks 1 Wega Qe cee eee — gE BE Dependenciarespecto a aeeSteet OWES fs ‘losario a 8 Figura 3.2 Influencia de los artefactos en l fase de planeacién y de elaboracién, 1 Sise creaun artefacto que no tenga otros dependientes y si no se usa como entrada de otra cosa, habré que poner en tela de jucio su valor yel tiempo que se dedicé a su creacién. ceeparte! FASE DE PLANEACION Y DE ELABORACIONCASO DE ESTUDIO: EL PUNTO DE VENTA Objetivos = Definir el caso de estudio que se emplea en el libro. 1 El sistema del punto de venta ‘Nuestro principal caso de estudio es el sistema de una terminal (POST) de punto de venta.’ Esta terminal es un sistema computarizado con el que se registran las ventas y se realizan Jos pagos; normalmente se utiliza en las tiendas al detalle. Abarca componentes de hard- ‘ware (una computadora yun lector de cédigo de barras)y software para correr el sistema, ‘Suponga que se nos ha pedido crear un programa para una terminal de punto de venta. Con una estrategia de desarrollo de incremento iterativo, vamos a realizar las fases de requerimientos, andlisis y disefio orientados a objetos e implementacién. > Figura 4.1 Terminal de punto de venta, 1 Unproblema también examinado en [Coad95], aunque este trabajo se llevé a cabo de manera independiente y mucho antes que el otro. 35___4 CASO DE ESTUDIO: EL PUNTO DE VENTA ¢Por qué escogimos este problema? Por ser representativo de muchos sistemas de informacién y porque toca problemas comunes que puede encontrar un desarrollador. Ahondaremos lo suficiente en el andlisis y en el disefto, para que el lector vea en forma detallada cémo se abordan estos problemas y pueda aplicar el método a otros proyectos. 4.2 Capas arquitecténicas y el énfasis en el caso de estudio Un sistema tipico de informacion que incluya una intertaz grafica del usuario y acceso ala base de datos suele presentar un diseiio arquitectinico de varios niveles 0 capas (figura 4.2) como las siguient = Presentacién: interfaz gréfica; ventanas. = Légica de aplicacién - Objetos del dominio del problema: objetos que repre- sentan conceptos del dominio (os objetos de ventas, por ejemplo) que cumplen con los requisitos de aplicacién. = Légica de aplicacién - Objetos de servicio: objetos de dominio no relaciona- dos con el problema que prestan servicios de soporte: por ejemplo, interfaz con luna base de datos, = Almacenamiento: un mecanismo persistente de almacenamiento; por ejemplo una base de datos relacional u orientada a objetos. | eranasixy dicho oietados objeto generalente son més les para moda los niveles logicos de la aplicacion. - —__| Estudiaremos en el capitulo 22 el tema de una arquitectura de capas (o niveles). El caso de estudio del punto de venta destaca principalmente los objetos del dominio del problema, asignéndoles responsabilidades para cumplir con los requisitos de la aplicacién. En el capitulo 38 nos serviremos del disefto orientado a objetos para crear un conjunto de objetos del nivel de servicio para conectarnos con una base de datos. En este método de disefio, la capa de presentacién tiene muy poca responsabilidad; se dice que es delgada. Las ventanas no contienen un codigo que se encargue de la légica © procesamiento de la aplicacién. Por el contrario, las solicitudes de tarea se envian al dominio del problema y a las capas de servicio. 43 Nuestra estrategia: aprendizaje y desarrollo iterativos Este libro esté organizado para seguir una estrategia de desarrollo iterativo. El andlisis y el diseno orientados a objetos se aplican al sistema del punto de venta en dos ciclos de desarrollo iterativo en que el primer ciclo se destina a una simple aplicacién de las funciones basicas. El segundo amplia la funcionalidad del sistema (véase la figura 4.3). 36 4 CASO DE ESTUDIO: FI. PUNTO DE VENTA Presentacién punto menor expicar como Mh ‘onectarse a otras capas Ee Logica de aplicacion -objetos del dominio fer | | ‘punto primaio » ‘el prob icceesamen |g etic” ater __alcaso de estusio punto secundario Gelcaso.deestudio | Eniaprinea gran BY Secon dl bro 80 | Se expican mas | hablidades do Figura 4.3 Ruta de aprendizaje que siguen los ciclos de desarrollo. 3.4 CASO DF RSTUDIO: EL PUNTO DE VENTA Ademis del desarrollo iterativo, también se expone de manera iterativa la presentacién de los temas del andlisis y el disefio orientados a objetos, la notacién de UML y los patrones. En el primer ciclo de desarrollo del sistema del punto de venta, se describe un grupo basico de temas de andlisis y de disefio, asi como la notacién. El segundo ciclo se expande y ofrece nuevas ideas, la notacién de UML y los patrones. Esta estrategia tiene por objeto proponer un modelo de aprendizaje “justo a tiempo”, EI modelo procura explicar primero las ideas de mayor uso, lo més cerca posible del ‘momento en que el lector perciba la necesidad de aprenderlos para poder continuar. Al principio, el libro se centra en las ideas y habilidades fundamentales, sin saturarlo ‘con nueva informacién que no pueda aplicar de inmediato. Después se explican las habilidades e ideas que se utilizan més raramente. 1 CONOCIMIENTO DE LOS REQUERIMIENTOS Objetivos = Crear los artefactos de la fase de requerimientos; por ejemplo, las especifica- ciones de funciones, Identificar y clasificar las funciones del sistema Identificar y clasificar los atributos del sistema y relacionarlos con las fun- ciones. Introduccién Un proyecto no puede ser exitoso sin una especificacién correcta y exhaustiva de los, requerimientos. Para ello se necesitan muchas habilidades; un examen riguroso de cllas rebasa el Ambito de este libro, pues nuestro objetivo es que el lector domine el andlisis y el disefio orientados a objetos. Pero se ofrece una introduccidn a los reque- rimientos de la aplicacién punto de venta, porque en Ia practica es un paso decisivo, y se mencionan otros artefactos relacionados con la fase de requerimientos, No duda- mos en recomendar Exploring Requirements: Quality Before Design [GW89], obra que se centra en las habilidades necesarias para dilucidar los requerimientos importantes. Este capitulo se propone lograr que el lector pueda expresar los requerimientos, no en convertirlo en un experto en el dominio de los sistemas de terminales para tiendas y puntos de venta, Por eso, la lista de las funciones y atributos del sistema no es exhaus- tiva, sino representativa.5 - CONOCIMIENTO DE LOS REQUERIMIENTOS notes a. constante opeonat © aplazable onsen Actividades dela fase de planeacién y elaboracién, ~— invorme | Especticacones prliminar do de requerimentos mwestgacion < z (asos de uso: 1. todos de allo nivel ». aigunos esencialos Protaipos expandidos Prosupuesto, ~~ Diagiamas de Programa cease do Us0 Models conceptual — | mS prolminar Dependencia respecte a y Giosario Dependencias de los artefactos respecto a la fase de planeacién y elaboracion. 52 21 ps 5 - CONOCIMIENTO DE LOS REQUERIMIENTOS Ninguno de los artefactos que se describen en la presente seccién son propios del Ienguaje UML; se trata simplemente de documentos comunes de la fase de reque- rimientos. Los requerimientos Los requerimientos son una descripcién de las necesidades o deseos de un pro- ducto, La meta primaria de a fase de requerimientos es identificar y documentar lo que en realidad se necesita, en una forma que claramente se lo comunique al cliente y a los miembros del equipo de desarrollo. El reto consiste en definirlos de manera inequivoca, de modo que se detecten los riesgos y no se presenten sorpresas al momento de entregar el producto, Se recomiendan los siguientes artefactos en la fase de requerimientos: = panorama general = clientes a metas = funciones del sistema = atributos del sistema Otros documentos pertinentes, que por cierto no examinaremos en el libro, se men: cionan al final del capitulo. Integracién de las piezas del rampecabezas En nuestro caso de estudio, la definicién de los requerimientos aparece muy clara ¥ tajante: la realidad dista mucho de serlo. Por lo regular hay que reunir y asimilar muchos estudios y documentos electrénicos, analizar los resultados de las entrevistas, celebrar reuniones para definir los requerimientos en grupo, etcétera Presentacion general Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizaré en las ventas al menudeo. Clientes ObjectStore, Inc., detallista multinacional de objetos. 415.5 5.6 5.6.1 42 5 - CoNOCTATENTO DE LOS REQUERIMIENTOS Metas En términos generales, la meta es una mayor automatizacién del pago en las cajas registradoras, dar soporte a servicios mas répidos, més baratos y mejores y a los pro- esos dle negocios. Mas concretamente, la meta incluye: = Pago répido de los clientes. = Audlisis rapido y exact de las ventas. = Control automatico del inventario. Funciones del sistema Las funciones del sistema son lo que éste habra de hacer, por ejemplo autorizar los pagos a crédito. Hay que identificarlas y listarlas en grupos cohesivos y légicos. Con el objeto de verificar que algin X es de verdad una funcién del sistema, la siguiente oracion deberd tener sentido: El sistema deberd hacer . Por ejemplo: El sistema deberé autorizar los pagos a crédito. En cambio, los atributos del sistema son cualidades no funcionales —entre ellas la facitidad de uso— que a menudo se confunden con las funciones. Notese que “faci lidad de uso” no encaja en la oracién de verificacién: El sistema deberd hacer la facitidad de uso. Los atributos no deben formar parte del documento de las especificaciones funcionales del sistema, sino de un documento independiente que especifica sus atributos, Categorias de las funciones Las funciones, como autorizar pagos a crédito, han de clasificarse a fin de establecer prioridades entre ellas e identificar las que de lo contrario pasarian inadvertidas (pero que consumen tiempo y otros recursos). Las categorias son: 3.6.2 5- CoNOCIIMENTO DE LOS REQUERIMIENTOS Evidente Debe realizarse, y el usuario deberia saber que se ha realizado. Oculta Debe realizarse, aunque no es visible para los usuarios. Esto se aplica a muchos servicios técnicos subyacentes, como guardar informacion en un mecanismo persis- tente de almacenamiento. Las funciones ocultas a menudo se omiten (erréneamente) durante el proceso de obtencién de los requerimientos. onan Superflua COpcionales; su inclusién no repercute significativa- mente en el costo ni en otras funciones, Funciones basicas Las siguientes funciones del sistema en la aplicacién de la terminal del punto de venta son luna muestra representativa; no pretenden en absoluto ser exhaustivas. Nuestro objetivo es entender los detalles del analisis y del disefio, no el funcionamiento de una tienda, | Registra la venta en proceso (actual): los productos | evidente comprados. R12 Calcula el total de la venta actual; se incluyen el evidente impuesto y los calculos de cupén. R13 Captura la informacién sobre el objeto comprado evidente usando su cédigo de barras y un lector 0 usando una | ‘captura manual de un cédigo del producto; por ejemplo, tn cédigo universal de producto (UPC). Ria Reduce las cantidades del inventario cuando se realiza_| oculta una venta R15 | Seregistran las ventas efectuadas. oculta R16 El cajero debe introducir una identificacién y una con- | evidente trasefia para poder utilizar el sistema. RL (Ofrece un mecanismo de almacenamiento persistente. | oculta5.6.3 5.7 '5- CONOCIMIENTO DE LOS REQUERIMIENTOS Ref # Funcién | Categoria | R18 Ofrece mecanismos de comunicacién entre los procesos | oculta yentre los sistemas, [Rig | Muestra la descripcion y el precio del producto | registrado, evidente Funciones de pago Ref # Funcion Categoria R21 ‘Maneja los pagos en efectivo, capturando la cantidad | evidente | ofrecida y calculando el saldo deudor. i R22 ‘Maneja los pagos a crédito, capturando la informacion | evidente | crediticia a partir de una lectora de tarjetas o mediante captura manual, y autorizando los pagos con el servicio de autorizacién (externa) de créditos de la tienda a | través de una conexién por modem. R23 Maneja los pagos con cheque, capturando la licenci de conducir mediante captura manual, y autorizando los pagos con el servicio de autorizacién (externa) de cheques de la tienda a través de la conexion por modem. pt R24 Registra los pagos en el sistema de cuentas por cobrar, oculta pues el servicio de autorizacion de crédito debe a la tienda el monto del pago. evidente Atributos del sistema Los atributos del sistema son sus caracteristicas o dimensiones; no son funciones. Por ejemplo: facilidad de uso tolerancia a las fallas tiempo de respuesta metifora de interfaz —_< costo al detalle plataformas Los atributos del sistema pueden abarcar todas las funciones (por ejemplo, la plataforma del sistema operative) o ser especificos de una funcién o grupo de funciones. 5 - CONOCIMIENTO DE LOS REQUERIMIENTOS. Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden ser valores discretos, confusos o simbélicos; por ejemplo: tiempo de respues Jcolégicamente correcto) metafora de interfaz = (grafico, colorido, basado en formas) Algunos atributos del sistema también pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera, generalmente en un rango numérico de los valores de un atributo; por ejemplo: tiempo de respuesta = (cinco segundos como maximo) He aqui algunos ejemplos mas: Atributo Detalles y restricciones de frontera tiempo de respuesta (restriccion de frontera) Cuando se registre un pro- ducto vendido, la descripcién y el precio apareceran en cinco segundos. | metafora de interfaz (detalle) Ventanas orientadas a la metafora de una forma y cuadros de dislogo. (detalle) maximiza una navegacién facil con teclado y no con apuntadores tolerancia a fallas (restriccién de frontera) debe registrar los pagos a crédito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energia 0 del equipo. plataformas del sistema _| (detalle) Microsoft Windows 95 y NT. operativo Atributos del sistema en las especificaciones de funciones Conviene deseribir todos los atributos del sistema que se relacionen claramente con las funciones dentro de la lista en que se especifican estas iiltimas. Ademés, los detalles de los atributos y las restricciones de frontera pueden catalogarse como obli- gatorios w opcionales.' 1 Una restriccién de frontera suele ser obligatoria, pues de lo contrario significaria que no era sélida,5 CONOCIMIENTO DE LOS REQUERIMTENTOS R19 | Mostrar la descripcién yl pre- | evidente | tiempo de | 5 segundos como obliga- cio del producto registrado. respuesta | maximo torio metafora_ | pantallas basadas en | obliga- de interfaz | formas torio colorido: | opcional R24 | Registrar los pagos a crédito en | oculto | tolerancia | debe registrar en las | obliga- el sistema de cuentas por a fallas cuentas por cobrar en | torio cobrar, pues el servicio de auto- un plazo de 24 horas, rizacién de crédito debe a la aun cuando se produ: tienda el importe del pago. can falas de energia © del equipo tiempo de | 10segundos como | obliga- respuesta | maximo torio 5.8 Otros artefactos en la fase de los requerimientos En este libro se da una introduccién muy sucinta a los requerimientos; es un tema que bien podria abarcar libros enteros. Las funciones y los atributos del sistema son los documentos minimos de los requerimientos, de modo que se necesitan otros artefac- tos importantes para atenuar el riesgo y entender el problema, a saber: = Requerimientos y equipos de enlace: lista de los que deberian participar en la espe- cificacién de las funciones y atributos del sistema, en la realizacién de entrevistas, de pruebas, de negociaciones y de otras actividades. = Grupos afectados: ios que reciben el impacto del desarrollo o aplicacién del sistema. = Suposiciones: las cosas cuya verdad se supone. m= Riesgos: las cosas que pueden ocasionar el fracaso 0 retraso, CASOS DE USO: DESCRIPCION DE PROCESOS Objetivos = Identificar y escribir casos de uso. = Disefiar diagramas de casos de uso. m= Contrastar los casos de uso de alto nivel con los expandidos. m= Contrastar los casos de uso esenciales con los reales. 1 Introduccién Una técnica excelente que permite mejorar la comprensién de los requerimientos es la creacién de casos de uso, es decir, descripciones narrativas de los procesos del dominio. En este capitulo se exponen los conceptos basicos de esta técnica y se dan ejemplos para aplicarlos a la terminal de punto de venta. = Dependencias: otras personas, sistemas y productos de los cuales no puede prescindir el proyecto para su terminacién. = Glosario: definicién de los términos pertinentes; tema que se estudiar en capitu- los subsecuentes. = Casos de uso: descripciones narrativas de los procesos del dominio; tema que se vera en capitulos posteriores. = Modelo conceptual preliminar: modelo de conceptos importantes y de sus rela- ciones; tema que se tratard en capitulos posteriores, En el siguiente capitulo clasificaremos los casos de uso y escogeremos los que utiliza- remos en el primer ciclo de desarrollo. EI UML incluye formalmente el concepto de casos de uso y sus diagramas de uso.{6 CASOS DE USO: DESCRIPCION DE PROCESOS Notas ‘a.consiane MA » epsional © aplazable 4. orden variable Actividades de la fase de planeacion y elaboracién, Intorme | Especicaciones prelimnar do io roquermientos investigacén ——— Casas de uso: Protest 2.10008 de alto nivel algunos esonciales cexpansidos resupuesto, ~ Diegremas de programa cases uso | Mosel cononival relma’ . Dependencia respecto a a Gosario Dependencias de los artefactos respecto a la fase de planeacién y elaboracién. 48 6 - CASOS DE USO: DESCRIPCION DE PROCESOS Actividades y dependencias Los casos de uso requieren tener al menos un conocimiento parcial de los reque- rimientos del sistema, en teoria expresados en el documento donde se especifican, Casos de uso El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso [Jacob- son92]. Los casos de uso son historias 0 casos de utilizacién de un sistema; no son exactamente los requerimientos ni las especificaciones funcionales, sino que ejempli- fican e incluyen tacitamente los requerimientos en las historias que narran ‘Comprar productos Figura 6.1. Icono del lenguaje UML para un caso de uso, Ejemplo de un caso de uso de alto nivel: comprar productos EI siguiente caso de uso de alto nivel describe clara y concisamente el proceso de comprar articulos en una tienda cuando se emplea una terminal en el punto de venta. Caso de uso: Comprar productos Actores: Cliente, Cajero. Tipo: Primario (que se explicard luego). Un Cliente llega a la caja registradora con los articulos que comprara, El Cajero registra los articulos y cobra el importe. Al terminar la operacin, el Cliente se marcha con los pro- ductos. Los encabezados y la estructura de este caso de uso son representativos. Sin em- bargo, el UML no especifica un formato rigido; puede modificarse para atender las necesidades y ajustarse al espiritu de la documentacién: ante todo, una comunicacién clara, Conviene comenzar con los casos de uso de alto nivel para lograr rapidamente entender los principales procesos globales. 49{6- CASS DE. USO: DESCRIPCION DE PROCESOS 6 - CASOS DE US0: DESCRIPCION DE PROCESOS 6.3.2 Ejemplo de un caso expandido de uso: comprar productos con efectivo Curso normal de los eventos Accién del actor Respuesta del sistema Un caso expandido de uso muestra mas detalles que uno de alto nivel; este tipo de casos suelen ser ttiles para alcanzar un conocimiento més profundo de los procesos y de los requerimientos. A menudo se llevan a cabo en un estilo “coloquial” entre los actores y el sistema [Wirfs-Brock93]. Damos en seguida un ejemplo de un caso expan- dido de Comprar productos que ha sido simplificado para manejar tnicamente los agos en efectivo y excluir la administracién del inventario (lo hemos hecho para sim- plificar la explicacién en este primer ejemplo). 7. El Cliente efectia un pago en efec- tivo —el “efectivo ofrecido”— posi- blemente mayor que el total de la venta, 8. El Cajero registra la cantidad de efec- 9, Muestra al cliente la diferencia. tivo recibida. Genera un recibo. 10. El Cajero deposita el efectivo rect 11, Registra la venta concluida. bido y extrae el cambio del pago. Coo Comprar productos en efectivo EI Cajero da al Cliente el cambio y el Actores: Cliente (niciador), Cajero. recibo impreso. Propésito Capturar una venta y su pago en efectivo. 12, El Cliente se marcha con los articu- ‘Resumen: Un Cliente llega a la caja registradora con articulos que desea los comprados. comprar. El Cajero registra los productos y recibe un pago en efectivo. Al terminar Ia operacién, el Cliente se marcha con los productos comprados. Tipo: Primario y esencial. . Funciones: R1.1, R1.2, R13, R17, RL9, R2d. Cursos alternos Linea 2: introduccién de identificador invalido. Indicar error. Referencias cruzadas: mnte no tenfa suficiente dinero. Cancelar la transaccién de venta. = Linea 7: el 3.3 Explicacién del formato expandido Curso normal de los eventos La parte superior de la forma expandida es informacién muy sucinta Accién del actor Respuesta del sistema 1. Este caso de uso comienza cuando un Cliente llega a una caja de TPDV as Nombre del caso de uso (Terminal Punto de Venta) con pro- Actores: Lista de actores (agentes externos), en la cual se indica quién ductos que desea comprar. inicia el caso de uso. 2, El Cajero registra el identificador de 3. Determina el precio del producto & ; ye cada producto, corpora a la transaccién actual la Propésito reece Si hay varios productos de una _ informacion correspondiente. Resumen: Repeticidn del caso de uso de alto nivel o alguna sintesis misma categoria, el Cajero también _—_Se presentan la descripcién y el pre- cine! puede introducir la cantidad, cio del producto actual. a 1 Primario, secundario u opcional (a explicar) 4. Al terminar de introducir el pro- 5. Calcula y presenta el total de la ee ducto, el Cajero indica a TPDV que venta. 2. Esencial o real (a explicar). se concluy6 la captura del producto, Referencias Casos relacionados de uso y funciones también relacionadas 6. El Cajero le indica el total al Cliente. cruzadas: del sistema,6.4 52. 6 CASOS DE USO: DESCRIPCION DE PROCESS La seccién intermedia, curso normal de los eventos, es la parte medular del formato expandido; describe los detalles de la conversidn interactiva entre los actores y el sistema, Un aspecto esencial de la seccion es que explica la secuencia més comin de los eventos: Ia historia normal de las actividades y la terminacién exitosa de un pro- ceso. No incluye situaciones alternas, Curso normal de los eventos Accién del actor Respuesta del sistema Descripciones numeradas de las respuestas del sistema. Acciones numeradas de los actores. opciones 0 excep- ‘son complejas, La tiltima seceién, curso alterno de los eventos, describe important ciones que pueden presentarse en relacién con el curso normal. podemos expandirlas y convertirlas en nuestros casos de uso. Cursos alternos = Alternativas que pueden ocurrir en el ntimero de linea. Descripcién de excepciones. Actores Elactor es una entidad externa del sistema que de alguna manera participa en la histo- ria del caso de uso. Por lo regular estimula el sistema con eventos de entrada 0 recibe algo de él. Los actores estan representados por el papel que desempefian en el caso: Cliente, Cajero u otro. Conviene escribir su nombre con mayuiscula en la narrativa del caso para facilitar la identificacién. Oo Cliente Figura 6.2. Icono del lenguaje UML que representa un actor de casos de uso! 1 Aunque el icono estindar es una figura humana estlizada, hay quienes prefieren utilizar un icono con figura de computadora para designar los actores que son sistemas de computo y no seres humanos, 5 6 - CASOS DE USO: DESCRIPCION DE PROCESOS 0 de uso hay un actor iniciador que produce la estimulacién incial y, posible- wicar quién es el iniciador, Enun mente, otros actores participantes; tal vez convenga Los actores suelen ser los papeles representados por seres humanos, pero pueden ser cualquier tipo de sistema, como un sistema computarizado externo de bancos. He aqui algunos tipos: = papeles que desempefian las personas = sistemas de cémputo = aparatos eléctricos 0 mecénicos Un error comun en los casos de uso Un error comin en la identificacién de los casos de uso consiste en representar los pasos, las operaciones o las transacciones individuales como casos. Por ejemplo, en el dominio de la terminal del punto de venta, podemos definir (incorrectamente) un denominado “Imprimir el recibo”, cuando en realidad esta operacidn no es mas que un paso de un proceso mas amplio del caso Comprar productos. Un caso de uso es una descripcién de un proceso de principio a fin relativamente amplia, descripcién que suele abarcar muchos pasos 0 transacciones; normalmente no @5 un paso ni una actividad individual del proceso, | — Es posible dividir las actividades o parte del caso en subcasos (denominados casos abstractos de uso), incluso en pasos individuales; pero esto no es Jo habitual y lo veremos en el capitulo 26. Identificacion de los casos de uso Los siguientes pasos de la identificacién de los casos de uso requieren una lluvia de ideas y revisar los documentos actuales sobre la especificaci6n de los reque- rimientos,{6- CASOS DE USO: DESCRIPCION DE PROCESOS 6 - CASOS DE US0: DESCRIPCION DE PROCESOS “1 8 Casos de uso, funciones del sistema y rastreabilidad Un método con que se identifican los casos de uso se basa en los actores, 1. Se identifican los actores relacionados con un sistema o empresa, Las funciones del sistema identificadas durante la especificacién previa de requerimien tos deben asignarse a los casos de uso. Ademés, debe ser posible verificar, mediante la seccién Referencias cruzadas, que todas las funciones hayan sido asignadas. Con ello se Jogra un vinculo importante respecto a la rastreabilidad entre los artefactos, En defini- tiva, todas las funciones y casos de uso del sistema deberian poder rastrearse hasta la 2. Encada actor, se identifican los procesos que inician en que participan. Un segundo método de identificacién de los casos de uso se basa en eventos. implementacién y la aplicacién de pruebas. 4. Se identifican los eventos externos a los que un sistema ha de responder. 2. Se relacionan ls eventos con los actores y con los casos de uso. 9 Diagramas de los casos de uso En la aplicacién del punto de venta, algunos actores posiblemente relevantes y los pro- En la figura 6.3 se muestra un diagrama de casos de uso para el sistema del punto de ceesos que inician son: venta, Cajero Registra A TROV Entrega efectivo O Oo Aw | cliente Compra productos Calero Ctente Paga los productos Registra los datos Entega ol caro toe pedacos aa comprades 6.7 Caso de uso y procesos del dominio Figura 6.3: Diagrama parcial de casos de uso. Un caso de uso describe un proceso, un proceso de negocios por ejemplo, Un pro- eso describe, de comienzo a fin, una secuencia de los eventos, de las acciones y las Un diagrama de casos de uso explica gréficamente un conjunto de casos de uso de un transacciones que se requieren para producir u obtener algo de valor para una em- sistema, los actores y la relacién entre éstos y los casos de uso. Estos tiltimos se mues- presa o actor. tran en dvalos y los actores son figuras estilizadas. Hay lineas de comunicaciones \ entre los casos y los actores; las flechas indican el fio de la informacién o el estimulo, A continuacién se mencionan algunos procesos: ° ° unos Pr El diagrama tiene por objeto ofrecer una clase de diagrama contextual que nos per- = Retira efectivo en un cajero automatico mite conocer répidamente los actores externos de un sistema y las formas basicas en ue lo utilizan, = Ordena un producto : m= Registra los cursos que se imparten en una escuela 10 Formatos de los casos de uso = Verifica la ortografia de un documento con un procesador de palabras ea a et tea En la préctica, los casos de uso pueden expresarse con diverso grado de detalle y de aceptacion de las decisiones concernientes al disefto. En otras palabras, un mismo6.10.1 6 - CASOS DE US0: DESCRIPCION DE PROCESOS ‘caso de uso pueden escribirse en diferentes formatos y con diversos niveles de detalle. ‘Mas adelante estudiaremos otras formas de clasificarlos y expresarlos en formatos; pero por ahora nos concentraremos en una divisién fundamental: casos con formato de alto nivel y expandido. Formato de alto nivel Un caso de uso de alto nivel describe un proceso muy brevemente, casi siempre en dos 0 tres enunciados, Conviene servirse de este po de caso durante el examen ini cial de los requerimientos y del proyecto, a fin de entender répidamente el grado de complejidad y de funcionalidad del sistema. Estos casos son muy sucintos y vagos en las dec 6.10.2 Formato expandido 6.11 Un easo de uso expandido describe un proceso mis a fondo que el de alto nivel. La diferencia bisica con el caso de uso de alto nivel consiste en que tiene una seccién destinada al curso normal de los eventos, que los describe paso por paso. Durante la fase de especificacién de requerimientos, conviene escribir en el formato expandido los casos mas importantes y de mayor influencia; en cambio, los menos importantes pueden posponerse hasta el ciclo de desarrollo en el cual van a ser abordados. Los sistemas y sus fronteras Un caso de uso describe la interaccién con un “sistema”. Las fronteras ordinarias del sistema son: = la frontera hardware/software de un dispositivo o sistema de cémputo = eldepartamento de una organizacion = Ia organizacion entera ED} ‘Actor 130 de uso. Figura 6.4. Frontera de un Es importante definir la frontera del sistema para identificar lo que es interno o externo, asi como las responsabilidades del sistema. E] ambiente externo esta repre- sentado tinicamente por actores. 6 - Cass DE USO: DESCRIPCION DE PROCESOS Estudiaremos un ejemplo de la influencia que tiene seleccionar la frontera del sistema: los pagos en la terminal del punto de venta y la tienda. Si elegimos como “el sistema” la tienda entera o el negocio (figura 6.6), el tinico actor es el cliente y no el cajero, porque este ultimo es un recurso del sistema del negocio que realiza las funciones. Pero si escogemos como sistema el hardware y el software de la terminal del punto de venta (figura 6.5), se trata como actores al cliente y al cajero. O [o™ | 1 Geno ots) —| Regaira los precuctos Entroga ol cambid Figura 6.5, Casos de uso y actores cuando el sistema TPDV es la frontera. Compre ross >10 cee Ex aca ies Nests Figura 6.6 Casos de uso y actores cuando tienda es la frontera. En Ia seleccién de una frontera del sistema influyen las necesidades de la investi- gacién, Si estamos desarrollando un software de aplicacién o un dispositivo, sera razonable establecer la frontera del sistema en la del hardware y en la del software; or ejemplo, la terminal del punto de venta y sus programas constituye “el sistema”, y el cliente y el cajero son los actores (agentes) externos, Si estamos efectuando la reingenieria de procesos de la empresa —reorgani- zando los procesos o la empresa para mejorar la competitividad o la calidad, Ia selec- ce 876 - CAS0S DE USO: DESCRIPCION DE PROCESOS cidn de la compafia o de la tienda entera como el sistema es importante. En el sistema ‘TPDY, definiremos “el sistema” como la terminal de punto de venta y su software. 6.12 Casos de uso primarios, secundarios y opcionales Los casos deberian clasificarse en primarios, secundarios u opcionales. Mas adelante, a partir de estas designaciones, clasificaremos nuestro conjunto de casos de uso para establecer prioridades en su desarrollo. Los casos primarios de uso representan los procesos comunes mas importantes, como Comprar productos. Los casos secundarios de uso representan procesos menores 0 raros; por ejemplo, Solicitud de surtir el nuevo producto. Los casos opcionales de uso representan procesos que pueden no abordarse. 6.13 Casos esenciales de uso comparados con los casos reales de uso 6.13.1 Casos 58 Grado dela aceptacién del clseRo en un caso do uso Caso esencial aso real muy abstracto muy conereto Figura 6.7. Los casos esenciales y reales de uso existen a lo argo de un continuo, esenciales de uso Los casos esenciales de uso [Constantine97] son casos expandidos que se expresan ‘en una forma tedrica que contiene poca tecnologia y pocos detalles de implemen- tacién; las decisiones de disefio se posponen y se abstraen de la realidad, especial- ‘mente las concernientes a la interfaz para el ustario. Un caso de este tipo describe el proceso a partir de sus actividades y motivos esenciales. El grado de abstraccidn con que se describe existe en un continuo: la descripcidn puede ser més o menos esencial. Los casos de alto nivel siempre son de caracter esencial, debido a su brevedad y abstraccion. En seguida se incluye un ejemplo de un caso de Retiro de efectivo en un cajero automatico, que se expresa en una forma relativamente esencial. 6 - CASOS DE US0: DESCRIPCION DE PROCESOS Esencial Accién de los actores Respuesta del sistema 1. Ell Cliente se identifica, 2. Presenta opciones. 3. yasi sucesivamente. 4. yasi sucesivamente, La manera en que un cliente se identifica cambia con el tiempo —es una decision de diseio—, pero forma parte del proceso esencial de que la identificacién se realice de alguna manera. Conviene crear casos esenciales de uso al comenzar a investigar los requerimientos, con el propésito de entender mejor el alcance del problema y las funciones necesarias. Este tipo de casos son de gran utilidad porque permiten captar la esencia del proceso y sus motivos fundamentales, sin verse abrumado con detalles de disefio. Suelen tam- bién ser correctos durante largo tiempo, ya que excluye las decisiones de disefio y, por lo mismo, su creacién favorece la comprensién y el registro de los factores que dan vida a los procesos de un negocio. Una empresa puede recuperar y releer los casos esenciales de uso mucho tiempo después, aplicandolos exitosamente a un nuevo proyecto de desarrollo. 13.2 Casos reales de uso En cambio, un caso real de uso describe concretamente el proceso a partir de su disefio concreto actual, sujeto a las tecnologias especificas de entrada y de salida, etc. Cuando se trata de la interfaz para el usuario, a menudo ofrece presentaciones de pan talla y explica la interaccidn con los artefactos. A continuacién se incluye el caso Retiro de efectivo expresado en una forma relativamente real. Real Accién de los actores Respuesta del sistema 1, El Cliente introduce su tarjeta, 2. Pide el niimero de identificacién personal (NIP). 3. Introduce el NIP con un teckado 4, Muestra el mend de opciones. 5. yas{ sucesivamente 6. y asi sucesivamente, Notese que la accién esencial del “Cliente se identifica a si mismo” del caso de uso se realizé ahora concretamente en la serie de acciones comenzando con “El Cliente intro- duce su tarjeta”, 596 - CASOS DE USO: DESCHIPCION DE PROCHSOS En teorfa, los casos reales de uso se crean durante la fase de diseno en un ciclo de desarrollo, por ser un artefacto del disefio. En algunos proyectos se prevén las primeras, decisiones de disefio concernientes a la interfaz para el usuario; de ahi la necesidad de crear casos reales en la fase inicial de elaboracién. Se recomienda hacerlo en la fase de planeacién y elaboracién por la aceptacién prematura de un disefio y la abrumadora complejidad. No obstante, algunas compafias aceptan un contrato de desarrollo, basindose en las especificaciones de la interfaz para el usuario, En el capitulo 19 se examinan los casos reales en la aplicacién al punto de venta. 6.13.3 El caso esencial de uso de la compra de productos El-caso ampliado de uso Comprar productos que ya mencionamos tiende a ser un caso esencial, Obsérvese que la descripcién no es muy especifica respecto a la realizacion ‘técnica. El caso esta escrito de manera que casi podemos imaginar su aplicabilidad después de cien aitos 0 hace cien afios, lo cual manifiesta que es esencial Esencial Accién de los actores Respuesta del sistema 1. EI Cajero registra el identificador en 2. Determina el precio del producto y cada producto. agrega la informacién sobre él a la Sihay mis de un producto igual, e| tual transaccidn de venta. Cajero puede introducir de igual Aparecen Ia descripcién y el precio ‘manera la cantidad. del producto actual. 3. yasi sucesivamente. 4. yasi sucesivamente. 6.13.4 El caso real de uso de la compra de productos ‘A diferencia de una version esencial del caso de uso, una versién real se compromete ccon el disefio; una versin completa de ella se explicara en un capitulo posterior. En el siguiente ejemplo de la versién real, nétese la decisién de utilizar un cédigo universal de producto (CUP) con el identificador del producto! y una interfaz grafica para el usuario. En una fase temprana del andlisis no conviene tomar algunas decisiones, como lade utiliza tun cédigo universal de producto (CUP) en el caso esencial de uso. El anilisis y disefo| csencial y real son terminos a lo largo de un continuo de abstraccién més que extremos. He aqui io mas importante: siempre que se adopta un compromiso durante la fase de andl sis, existe la posibilidad de un error prematuro de diseflo, sobrecarga de informacion y| ‘menor flexibilidad, {6 CASOS DE. USO: DESCRIPCION DE PROCESOS Real Accién de los actores 1. En cada producto, el Cajero teclea el Cédigo Universal de Productos (CUP) en el campo de entrada del CUP de la Ventanal. Después oprime el botén “Introducir producto” con el ratén oprimiendo la tecla . 3. etcétera, 14 Sobre la notacién Respuesta del sistema 2, Muestra el precio del producto y agrega la informacion sobre él a la actual transaccién de venta, La descripcién y el precio del pro- ducto actual se muestran en el cuadro de Texto 2 de la Ventanal. 4, etcétera, 14.1 Asignacién de nombre a los casos de uso ‘Alcaso de uso se le asigna un nombre que comience con un verbo para subrayar que se trata de un proceso. Por ejemplo: = Comprar productos = Introducir un pedido 14.2 Inicio de un caso expandido de uso Comience un caso expandido con el siguiente esquema: 1, Este caso comienza cuando Por ejemplo: 1. Este caso de uso comienza cuando un Cliente llega a un TPDV con productos que desea comprar. De este modo se estimula una identificacin clara del actor y del evento iniciadores. 14.3 Puntos sobre la decision de notacién y sobre la ramificacién Un caso de uso puede contener puntos de decisién. Por ejemplo, en Comprar produc- tos, el cliente puede optar por pagar con efectivo, a crédito o con cheque en el ‘momento del pago. Si una de estas trayectorias de decisién es un caso muy represen- tativo y si las otras alternativas son raras, inusuales 0 excepcionales, el caso tipico.CASOS DE USO: DESCRIPCION DE PROCESOS deberd ser el tinico acerca del cual se escribe en el Curso normal de los eventos y las opciones han de escribirse en la seccién titulada Alternativas. Pero en ocasiones el punto de decision representa opciones cuya probabilidad es rela tivamente igual y normal; esto sucede con los tipos de pago en efectivo, con tarjeta de crédito y con cheque. En este caso se utiliza la siguiente estructura notacional: 1. Ena seccién principal Curso normal de los eventos, indique las ramas de las sub- secciones. Escriba una subseccién en cada rama, utilizando otra vez un Curso normal de los ‘eventos. Inicie el evento numerando en 1 cada seccién. 3. Si las subsecciones tienen opciones, escribalas en una seccién de alternativas de cada subseccién, Seccién: principal Curso normal de los eventos Accién de los actores Respuesta del'sistema 1. Este caso de uso comienza cuando un Cliente Tega a la caja TPDV con los productos que compraré, (Excluidos los pasos intermedios)... El Cliente escoge el tipo de pago: a. Sipaga en efectivo, constiltese la sec- ccién Pago en efectivo. b, Sipaga.a crédito, consiitese la seccién Pago con tarjeta de crédito. c. Sipaga con cheque, consiiltese la sec- ccién Pago con cheque. 4, Registra la venta terminada, 5. Imprime un recibo. 6. El Cajero le entrega el recibo al Cliente. 7. El Cliente se marcha con los productos com- prados. ‘C4808 DE USO: DESCRIPCION DE PROCESOS Seccién: Pago en efectivo Curso normal de los eventos Accién de los actores Respuesta del sistema 1, El Cliente da un pago en efectivo —el “efectivo ofrecido’—, posiblemente mayor que el total de ia venta, 2. El Cajero registra el efectivo ofrecido. 3. Muestra al Cliente la diferencia. 4. El Cajero deposita el efectivo reci- Dido y extrae la diferencia, El Cajero entrega al Cliente el cambio del pago. Cursos alternativos = Linea 4: efectivo insuficiente en la caja para pagar la diferencia. Se pide efectivo al supervisor o se pide al Cliente un pago mas cercano al total de la venta, Seccién: pago con tarjeta de crédito Cursos normales y alternos de la historia de pago con tarjeta de crédito. Seccién: pago con cheque Cursos normales y alternos de la historia de pago con cheque. Casos de uso dentro de un proceso de desarrollo Pasos de la fase de planeacién y elaboracién 1. Después de haber listado las funciones del sistema, defina la frontera de éste y Tuego identifique los actores y los casos de uso.{6- CASOS DE US0: DRSCRIPCION DE PROCESOS 2. Escriba todos los casos de uso en el formato de alto nivel. Clasifiquelos en prima- ros, secundarios u opcionales, 8. Dibuje un diagrama de caso de uso, 4. Relacione los casos de uso y dé ejemplo de las relaciones en el diagrama corres- Pondiente (més adelante se explican las relaciones de los casos). 5. Escriba en el formato esencial expandido los casos de uso més importantes, influ yentes y riesgosos, a fin de entender y estimar mejor la naturaleza y las dimen- ones del problema. Para evitar anilisis complejos posponga la escritura de la forma esencial expandida de los casos de uso menos importantes hasta los ciclos de desarrollo en que seran abordados. 6. in teoria, los casos reales deberian posponerse hasta una fase de disefio en el Ciclo de desarrollo, porque su creacién conlleva decisiones de disefio. Pese a ello, a veces es necesario crear casos reales de uso durante la etapa inicial de los reque- rimientos si: 9 Las descripciones concretas facilitan notablemente la comprensién. 9 Los Clientes exigen especificar sus procesos en esta forma, 7. Clasifique los casos de uso (que se expondrén en el siguiente capitulo) 6.15.2 Pasos de la fase del ciclo de desarrollo iterativo 1. Fase de andlisis: escriba casos esenciales de uso expandidos para los que se han abordado, si todavia no se llevan a cabo. 2, Fase de disefio: escriba casos reales de uso para los que estin siendo abordados, en caso de que todavia no se realicen. 6.16 Pasos del proceso en un sistema del punto de venta Explicaremos algunas de las siguientes actividades en capitulos posteriores, ya que requicren una exposicién amplia o pueden aplazarse para evitar una sobre- carga de informacién. Como nuestra meta es adquirir la habilidad de aplicar los casos y no convertirnos en expertos en tiendas, no escribiremos los detalles de todos los casos. 6.16.1 Identifique los actores y los casos de uso En la aplicacién del punto de venta, defina la frontera del sistema que seré el sistema de hardware/software, el caso habitual. Un ejemplo de lista de los actores y procesos relevantes a que dan inicio —que no pretende en absoluto ser completa— incluye: 6 - CASOS DE US0: DESCRIPCION DE PROCESOS ] Registra los productos Entrega el cambio Cliente | compra productos Paga los productos Gerente Inicia Cierra ‘Administrador Incorpora nuevos del sistema usuarios 6.16.2 Escriba casos de uso en el formato de alto nivel ‘Una muestra de casos de us Caso de uso: Actores: Tipo: Deseripeién: de alto nivel comprende: Comprar productos Cliente (iniciador), Cajero. Primario, Un Cliente llega a una caja con productos que desea comprar. sjero registra los productos y obtiene el pago. Al terminar la transaccidn, el Cliente se marcha con los productos. Inicio de operaciones Gerente, Primario. Un gerente activa una TPDV a fin de preparla para que la usen los Cajeros. El Gerente comprueba que la fecha y la hora sean correctos; hecho esto, el sistema est listo para que lo utilice el Cajero. 656 - CA80S DE USO: DESCRIPCION DE PROCESOS 6 - CASOS DE Us0: DESCRIPCION DE PROCESOS 6.16.3 Dibuje un diagrama de casos de uso Casos de uso: comprar productos Seccién: princips TPov ~ Coma C Caso de uso: Comprar productos oma proaucos a» Actores: Cliente (iniciador), Cajero. Caro " = Ciente Propésito: Capturar una venta y su pago. Resumen: Un Cliente llega a la caja con productos que desea comprar. El Cajero registra los productos y recibe el pago, que puede ser autorizado. Al terminar la transaccién, el Cliente se marcha con los productos. Tipo: Primario y esencial. ——~ Referencias Funciones: R11, R1.2, R13, R17, RL9, R2.1, R2.2, R2.3, R24. Ce = O a Casos de uso: el Cajero debe haber terminado el caso de uso: — Ga fags ations Admiistador delsistoma | Curso normal de los eventos Figura 6.8 Diagrama parcial de un caso de uso, que representa la aplicacién TPDV, Accién de los actores Respuesta del sistema 6.16.4 Relacione los casos de uso 1, Este caso de uso comienza cuando un Cliente lega a la caja TPDV con pro- Este tema lo trataremos en un capitulo posterior. ductos que desea comprar. 2. ElCajero registra los productos. 3. _Determina el precio del producto y eat 4 1a informacién sobre ¢1 a la ic i Si hay més de un producto, también a 5 6.16.5 Escriba algunos casos esenciales expandidos de uso puede introducir la cantidad actual transaccién de venta. Se muestran la descripcién y el pre- cio del producto actual, Entre los casos primarios de uso realmente significativos figuran: 4, Alterminar la captura de los produc- 5. Calculay presenta el total de la venta. = Comprar productos ar la cap tos, el Cajero indica a TPDV que ter- ‘= Pagar los productos comprados miné la captura de los productos. Escribir lo anterior en una forma esencial expandida suministrara una mayor infor- 6. EI Cajero le indica el total al Cliente. ‘macién y esclarecimiento de los requerimientos. A continuacién se presenta el caso de uso Comprar productos en su forma esencial expandida completa:68. {6 - CASO$ DE USO: DESCRIPCION DE PROCESOS Curso normal de los eventos Accién de los actores Respuesta del sistema 7, El Cliente escoge la forma de pago: a. Sipaga en efectivo, véase la sec- cién Pagar en efectivo. b. Sipaga con tarjeta de crédito, véase la seccién Pagar con tarjeta de crédito cc. Sipaga con cheque, véase la seccién Pagar con cheque. 8, Registra la venta terminada, 9. Actualiza los niveles de inventario, 10. Genera un recibo. 11. El Cajero entrega el recibo al cliente. 12. B] Cliente se marcha con los produe- tos comprados, Cursos alternos ‘= Linea 2: se introduce un identificador invalido del producto. Indique el error. = Linea 7: el Cliente no pudo pagar. Cancele la transaccién de venta. Seccién: pagar en efectivo Curso normal de los eventos Accién de los actores Respuesta del sistema 1. El Cliente da un pago en efectivo —el “efectivo ofrecido"—, posiblemente mayor que el total de la venta, 6 - CASOS DE Uso: DESCRIPCION DE PROCESOS Curso normal de los eventos Accién de los actores Respuesta del sistema 2. El Cajero registra el efectivo ofrecido, 3. Presenta la diferencia al Cliente. El Cajero deposita el efectivo reci- bido y extrae la diferencia. El Cajero le entrega el cambio al Cliente. Cursos alternos = Linea 1: el Cliente no tiene suficiente efectivo. Puede cancelar 0 iniciar otro método. de pago, m= Linea 4: la caja no contiene suficiente efectivo para pagar la diferencia. El Cajero pide més efectivo al supervisor o le pide al Cliente otro billete de menor denomi- nacién u otra forma de pago. Secci6n: pago con tarjeta de crédito Curso normal de los eventos Accién de los actores Respuesta del sistema 1. El Cliente comunica su informacion 2. Genera una solicitud de pago con de crédito para pagar con tarjeta. tarjeta de crédito y la envia a un Servir cio externo de autorizacién de crédito, Servicio de autorizacién de cré- 4, Recibe una respuesta aprobatoria de dito autoriza el pago. crédito del Servicio de autorizacién de crédito. 5. Enel sistema de Cuentas por cobrar registra la informacién sobre el pago con tarjeta de crédito y la respuesta de aprobacién. El Servicio de auto- rizacién de crédito debe dinero a la ‘Tienda; por tanto, Cuentas por cobrar debe darle seguimiento. 6. Muestra el mensaje aprobatorio de autorizacién,{6- CASOS DE USO: DESCRIPCION DE PROCESOS Cursos alternos = Linea 3: solicitud de crédi poner otro método de pago. negada por el Servicio de autorizacién de crédito, Pro- Seccién: pago con cheque Curso normal de los eventos Accién de los actores Respuesta del sistema 1. El Cliente extiende un cheque y se identific 2. El Cajero registra la informacién so- 3, Genera una solicitud de pago con bre la identificacién y solicita la auto- cheque y la envia a un Servicio ex- rizacién del pago con cheque. terno de autorizacién de cheques. 4. Verifica que el pago haya sido auto- 5, Recibe una respuesta aprobatoria del rizado por el Servicio de autorizaciin _—_Servicio de autorizacidn de cheques. ce cede 6. Indica la obtencién de la autorizacién, Cursos alternos = Linea 4: verificar solicitud negada por el Servicio de autori poner otra forma de pago. én de cheques. Pro 6.16.6 Si es necesario, escriba algunos casos reales de uso No conviene 0 no es necesario crear casos de uso real en este momento; este trabajo se realizara durante los ciclos de desarrollo. 6.16.7 Clasifique los casos de uso Este tema se estudiard en el siguiente capitulo. _70 {6- CASOS DE US0: DESCRIPCION DE PROCESOS 6.17 Modelos muestra Los casos esenciales de alto nivel y los diagramas de casos de uso son miembros del modelo de casos de uso del andlisis (figura 69). — del ett BS - - roan cnamico Figura 6.9 Modelo de andlisis pocUNeetAkoN YB HBO - URUGUAY aCLASIFICACION Y PROGRAMACION DE LOS CASOS DE USO Objetivos ‘= Clasificar los casos de uso. = Cuando sea necesario, preparar versiones simplificadas de los casos de uso. = Asignar los casos de uso a los ciclos de desarrollo. 71 Introduccién Las especificaciones de los requerimientos y los casos de uso se definen en la Fase de Planeacién y Blaboracién. Ademas, puede crearse un Modelo conceptual preliminar y disefiar una arquitectura también preliminar del sistema, aunque estas actividades se pospondrén en nuestro estudio de casos para ofrecer una introduccién mas gradual a los temas. Suponiendo que todos los artefactos deseados hayan sido generados (por ejemplo, la especificacién de los requerimientos y los casos de uso), el siguiente paso es iniciar la fase de Construccién en el ciclo de desarrollo iterativo y comenzar a implementar el sistema. En un ciclo de vida de desarrollo iterativo, la tarea de llenar los casos de uso se distribuye entre varios ciclos. En el presente capitulo se estudia la clasificacién y la programacién o calendariza. cién de los casos de uso, Una vez concluida esta etapa, estaremos listos para comen- zar el primer ciclo de desarrollo y examinar a fondo el anilisis y disefio orientados a objetos.17 - CLASIPICACION Y PROGRAMACION DE LOS CASOS DE USO 72 Actividades de la fase de planeacién y elaboracién, Informe | proiminer do Investigacion Protatpos Prosupuest programa Dependonciarespecto @ 7.2.1 Notas a.consiante Mh ». opconal ©. plaza 4 orden varable Especticacones e requerimientos casos de uso todos de alto nivel b. algunos esenciales 7.2.2 expandicos Diagramas de casos de uso | Modelo conceptual plminar iosano Dependencias de los artefactos respecto a la fase de planeacion y elaboracion, 1 CLASIFICACION Y PROGRAMACION DE. LOS CASOS DE USO Programacién de los casos de uso en los ciclos de desarrollo Casos de uso y los ciclos de desarrollo Los ciclos de desarrollo se organizan en torno a los requerimientos de los casos de uso. En otras palabras, se asigna un ciclo para implementar uno 0 mas casos de uso 0 sus versiones simplificadas, cuando el caso integro resulta demasiado complejo para abor- darlo en un ciclo (figura 7.1). ow fD de desaroio = Ciclo de desarralio Gases (azo de uso AS version versén smpiticada | integra Figura 7.1. Asignacién de los casos de uso a los cilos de desarrollo, Clasificacion de los casos de uso Es necesario clasificar los casos de uso, y los casos de alto rango han de tratarse al ini- cio de los ciclos de desarrollo. La estrategia general consiste en escoger primero los casos que influyen profundamente en la arquitectura basica. He aqui algunas de las cualidades que aumenta la clasificacién de un caso: a. Tener una fuerte repercusién en el muchas clases a la capa del dominio o requerir servicios de per b. Con relativamente poco esfu el diseno. zo obtener informacién ¢ ideas importantes sobre Incluir funciones riesgosas, urgentes o complejas. Requerir una investigacién a fondo o tecnologia nueva y riesgosa. Representar procesos primarios de la linea de negocios. Apoyar directamente el aumento de ingresos o la reduccién de costos, 7.1 CLASIFICACION Y PROGRAMACION DE L0S CASOS DE USO 1T- CLASIFICACION ¥ PROGRAMACION DE LOS CASOS DE USO El esquema taxondmico puede servirse de una clasificacién simple y poco rigurosa: realiz6 incrementalmente para satisfacer las necesidades de arranque de otros alto-mmediano-bajo ‘casos. No vamos a presentar de manera explicita la programacién de los pasos de El esquema también puede aplicar puntuaciones (posiblemente incrementadas con pon- este caso de uso y supondremos que siempre se desarrolla en forma imph deracién), basdndose en les cualidades que inciden en la clasificacién; por ejemplo ee i wo | al biel a 75 Programacion de los casos de uso en la aplicacién Comprar productos |5 3 |2|0 [5 |3 | 18 del punto de venta Y asi sucesivamente 7 . 7 oe A partir de la clasificacién, el caso Comprar productos deberia incluirse en el primer 7.3 Clasificacion de los casos de uso en la aplicacion ciclo de desarrollo. Como hemos visto, también puede abordarse una versién simple al punto de venta de Inicio para soportar los otros casos de uso. Con base en los criterios anteriores de clasificacién, a continuacién se incluye una 75.1 Creacién de versiones multiples de los casos de uso complejos clasificacién informal y poco rigurosa de los casos de uso de aplicacién al punto de venta, De ninguna manera pretendemos dar una lista exhaustiva. Siempre que se asigne un caso de uso, es necesario estimar si es posible resolverlo {ntegramente en el lapso limitado de un ciclo (cuatro semanas, por ejemplo) o si el tra- bajo ha de ser distribuido en varios ciclos. En este caso, Comprar productos es extre- ‘Caso de uso , x ei & © s as 7 # = gt of madamente complejo y quizd requiere cinco o mas ciclos, suponiendo que cada uno | Alto ‘Comprar Corresponde a los criterios de clasificacion mas ‘tendra una duracién de cuatro semanas exactamente. Se supone una estrategia de pro- productos altos. gramacién de duracién o tiempo fijo, en la cual al ciclo de desarrollo se le establece Mediano | Incorpora ‘Afecta al subdominio de la seguridad 4 tun plazo fi. eeeeenynnssanat En esta situacién el caso se redefine a partir de varias versiones de él, que van abar- Registra los pro- Afecta al subdominio de la seguridad. cando requerimientos cada vez mas exhaustivos. Cada versién se limita a incluir lo ductos comprados que se estima una cantidad razonable de trabajo dentro de los confines de la duracién | Paga los produc- Proceso importante; afecta a la contabilidad. fija del ciclo (digamos cuatro semanas). Por ejemplo: tos comprados wo. ei a : = —___ 2 = Comprar productos: versién 1 (pagos en efectivo, sin actualizaciones de inven- Bajo Pagar Efecto minimo ena arquitectura: trio.) Iniciar La defini in depende de otros casos de uso. iat = Comprar productos: versién 2 (permitir cualquier tipo de pago) Cerrar Efe minimo en la arquitectura. = Comprar productos: versién 3 (versién completa, incluyendo entre otras cosas las, actualizaciones del inventario, ..) 74 El caso de uso de arranque Las versiones anteriores se distribuyen después a lo largo de una serie de ciclos de desarrollo, junto con otros casos de uso. Practicamente todos los sistemas cuentan con un Caso de uso de inicio 0 arranque. Aunque tal vez no ocupe un nivel alto conforme a otros criterios, es preciso estudiar 7.5.2 Asignacién de los casos de uso al menos una version simplificada de él, al principiar el ciclo de desarrollo para pre- sentar la inicializacién supuesta en otros casos. En cada ciclo de desarrollo, éste se Si nos basamos en la clasificacién de los casos y de varias versiones de Comprar pro- ) de secuencia | | “Salsatone . — Diagramas i (cea, sependenciareepet | 08 operacion nat ~ J __ | Piagam ], [Eequema do | | de estado base de datos 4°} Dependencias de los artefactos durante la fase de construccién, 9 - CONSTRUCCIGN DE UN MODELO CONCEPTUAL Identificar muchos objetos 0 conceptos constituye la esencia del andlisis orientado a objetos, y el esfuerzo se compensa con los resultados conseguidos durante la fase de disefio e implementacién, La identificacién de conceptos forma parte de una investigacién del dominio del pro- blema. El lenguaje UML contiene la notacién en diagramas de estructura estatica que explican grificamente los modelos conceptuales, Una cualidad esencial que debe ofrecer un modelo conceptual es que representa | cosas del mundo real, no componentes del software. Actividades y dependencias Una de las primeras actividades centrales de un ciclo de desarrollo consiste en crear un modelo conceptual para los casos de uso del ciclo actual. Esto no puede hacerse si no se cuentan con los casos y con otros documentos que permitan identificar los con- ceptos (objetos). La creacién no siempre es lineal; por ejemplo, el modelo conceptual puede formularse en paralelo con el desarrollo de los casos. Modelos conceptuales EI paso esencial de un analisis o investigacién orientados a objetos es descomponer el problema en conceptos u objetos individuales: las cosas que sabemos. Un modelo conceptual es una representacién de conceptos en un dominio del problema [MO95, Fowler96]. En el UML, lo ilustramos con un grupo de diagramas de estructura estitica donde no se define ninguna operacién, La designacién de modelo conceptual ofrece la ventaja de subrayar fuertemente una concentracién en los conceptos del dominio, no en las entidades del software. Puede mostrarnos: = conceptos m= asociaciones entre conceptos = atributos de conceptos Por ejemplo, en la figura 9.1 vemos un modelo conceptual parcial del dominio de la tienda y las ventas. Explica gréficamente que el concepto de Pago y Venta son impor- tantes en este dominio del problema, que Pago se relaciona con Venta en una forma que conviene sefialar y que Venta tiene fecha y hora. Por ahora no son importantes para nosotros los detalles de la notacién, 87.9.3.1 9.3.2 9 - CONSTRUCCION DE UN MODELO CONCEPTUAL entas LneadePrecuctos | __Registra-venta-de [ Concepto Mo [canioas 0.4 h [Acoucn My © Contenida-en ‘Aributos » Figura 9.1 Modelo conceptual parcial. Los nimeros en los extremos dela linea indica ‘multiplicidad, la cual se describe en un capitulo subsecuente. 9.3.3 Conocimiento de la nomenclatura del dominio Ademés de descomponer el espacio del problema en unidades comprensibles (con- ceptos), la creacidn de un modelo conceptual contribuye a esclarecer la terminologia 0 nomenclatura del dominio. Podemos verlo como un modelo que comunica (a los inte- resados como pueden serlo los desarrolladores) cuales son los términos importantes yy c6mo se relacionan entre si. Los modelos conceptuales no son modelos de disefio de software Un modelo conceptual, como se advierte en la figura 9.2, es una descripcién del dominio de un problema real, no es una descripcién del disefto del software, como una clase de Java o de C++ (figura 9.3). Por ello los siguientes elementos no son adecuados endl = Los artefactos de software, como una ventana o una base de datos, salvo que el dominio a modelar se refiera a conceptos de software; por ejemplo, un modelo de interfaces gréficas para el usuario. 9 - CONSTRUCCION DE UN MODELO CONCEPTUAL = Las responsabilidades 0 métodos+ fe sotware Figura 9.2. Un modelo conceptual muestra conceptos del mundo real, a —S ew — ° ‘no forma parte de un é =| | emecess § aso de sofware so [ ob ° Sieve pmes un i mentees” | [ein Figura 9.3. Un modelo conceptual no muestra los artefactos o clases del software. Conceptos En términos informales el concepto es una idea, cosa u objeto, En un lenguaje mas formal, podemos considerarlo a partir de su simbolo, intensién’ y extensién [MO95] (figura 9.4). = Simbolo: palabras o imagenes que representan un concepto, = Intensién: la definicién del concepto. = Extensién: el conjunto de ejemplos a que se aplica el concepto. Consideremos, por ejemplo, el concepto del evento de una transaccién de compra. Podemos optar por designarlo con el simbolo Venta. La intensién de una Venta puede afirmar que “representa el evento de una transaccién de compra y tiene fecha y hora”. La extension de Venta son todos los ejemplos de venta; en otras palabras, el conjunto de todas las ventas Las responsabilidades normalmente se relacionan con entidades del software y los métodos siempre lo hacen; pero el modelo conceptual describe conceptos reales, no entidades del software. Durante la fase de diseffo es muy importante tener en cuenta las responsabilidades; yya que no sélo forman parte de este modelo. Intensién: en oposicién a extensién, designa el grado de una cualidad.9 - CONSTRUCCION DE UN MODELO CONCEPTUAL na vorta representa | eloverto de una 0 [lensing concep ‘transaccion de compra. | Sane | extenstn det concept My Figura 9.4 El concepto tiene un simbolo, itensién y extension Cuando se crea un modelo conceptual, por lo regular la vista del simbolo y de la inten- sién de un concepto es el aspecto de mayor interés practico. Los modelos conceptuales y la descomposicién Los problemas de software a veces son complejos; la descomposicién —divide y vencerés— es una estrategia que suele utilizarse para resolver la complejidad divi- diendo el espacio del problema en unidades comprensibles. En el andlisis estrue- turado Ia dimensién de la descomposicién se realiza mediante procesos o funciones. En cambio, en el andlisis orientado a objetos, se lleva a cabo fundamentalmente con concepts. Una distincién fundamental entre el andlisis orientado a objetos y el andlisis estructurado: division por conceptos (objetos) y no por funciones. Por tanto, una tarea primordial de Ia fase de andlisis consiste en identificar varios conceptos en el dominio del problema y documentar los resultados en un modelo con: ceptual. 9 - CONSTRUCCION DE UN MODELO CONCEPTUAL, Conceptos en el dominio del punto de venta Por ejemplo, en el dominio del problema real de comprar productos en una tienda en una terminal de punto de venta (TPDV) intervienen los conceptos de Tienda, TPDV y una Venta, Por tanto, nuestro modelo conceptual (figura 9.5) puede incluir una Tienda, TPDV y una Venta, Figura 9.5 Modelo conceptual parcial en el dominio dela tienda, Estrategias para identificar los conceptos Nuestra meta es crear un modelo conceptual de conceptos interesantes o significati- vos del dominio en cuestién. En este caso, ello significa conceptos relacionados con el caso de uso Comprar productos, versién 1. La tarea fundamental sera, pues, identificar los conceptos; se proponen dos estrategias, La siguiente es una directriz de gran utilidad en la identificacién de conceptos: Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refi- nados que no especificarlo cabalmente No piense que un modelo conceptual es mas adecuado si tiene menos conceptos; ‘generalmente suele suceder lo contrario. Es frecuente omitir conceptos durante la fase inicial de identificacién y descubrirlos mas tarde cuando se examinen los atributos 0 asociaciones o durante la fase de disefto. Cuando se detecten, habra que incorporarlos al modelo conceptual. No se excluya un concepto simplemente porque los requerimientos no indiquen una necesidad evidente que permita recordar la informacién acerca de ella (criterio comin de la construccién de modelos de datos para diseftar una base de datos relacional, pero no pertinente a la creacién de modelos conceptuales) o porque el concepto carezca de atributos. Es perfectamente valido tener conceptos sin atributos 0 conceptos con un papel puramente de comportamientos en el dominio en vez de un papel informacional. Obtenci6n de conceptos a partir de una lista de categorias de conceptos Lacreacién de un modelo conceptual se comienza preparando una lista de conceptos idéneos a partir de la siguiente lista. Contiene muchas categorfas comunes que vale la pena tener en cuenta, sin que importe el orden de importancia. Los ejemplos se toma ron de los dominios de la tienda y de las reservaciones de lineas aéreas. ot92 {9 - CONSTRUCCION DE UN MODELO CONCEPTUAL Son my objetos fisicos o tangibles TOV Avion especificaciones, disefio 0 descripciones de cosas EspecificaciondeProducto DescripciondeVuelo lugares Tienda Aeropuerto transacciones Venta, Pago Reservacion linea o renglén de elemento de transacciones papel de las personas VentasLineadeProducto Cajero Piloto contenedores de otras cosas Tienda, Cesto Avion cosas dentro de un contenedor otros sistemas de cémputo 0 Producto Pasajero SistemadeAutorizaciondeTarjetadeCredito electromecénicos externos al sistema ControldeTraficoAereo conceptos de nombres abstractos Hambre Acrofobia organizaciones DepartamentodeVentas ObjetoLineaAerea eventos Venta, Robo, Junta Vuelo, Accidente, Aterrizaje {9 - CONSTRUCCION DE UN MODELO CONCEPTUAL Categoria del concepto Elemplos procesos VentaUnProducto (a menudo no estan representados como | ReservacionAsiento | Conceptos, pero pueden estarlo) PoliticadeReembolso PoliticadeCancelaciones reglas y politicas, catélogos CatalogodeProducto CatalogodePartes registros de finanzas, de trabajo, de contratos de asuntos legales Recibo, Mayor, ContratodeEmpleo BitacoradeMantenimiento LineadeCredito Existencia instrumentos y servicios financieros ‘manuales, libros ManualdePersonal ‘ManualdeReparaciones 9.4.2 Obtencién de conceptos a partir de la identificaci6n de frases nominales Otra técnica muy util (por su simplicidad) propuesta en {Abbot83] consiste en identifi- car las frases nominales en las descripciones textuales del dominio de un problema y considerarlas conceptos 0 atributos idéneos. Este método hay que utilizarlo con mucha prudencia; no es posible encontrar mecanicamente correspondencias entre sustantivo y concepto, y ademas las palabras del lenguaje natural son ambiguas. Pese a ello, esta técnica es fuente de inspiracién, Los casos expandidos de uso son una excelente descripcién que puede conseguirse con este andlisis. Por ejemplo, puede usarse el caso de uso Comprar productos, versién J9 - CONSTRUCCION DE UN MODELO CONCEPTUAL 9 - CONSTRUCCION DE UN MODELO CONCEPTUAL 9.5.1 Objetos del informe: ¢se incluye el recibo en el modelo? Accién de los actores Respuesta del sistema El recibo es un registro de una venta y de un pago, asi como un concepto relativa mente prominente en el dominio de ventas; edebe, pues, mostrarse en el modelo? En seguida se mencionan algunos factores que han de tenerse presentes: 1. Este caso de uso comienza cuando un Cliente lega a una caja de TPDY con productos que desea comprar. = El recibo es un informe de una venta. En general, no conviene incluirlo en un 2. El Cajero registra el eédigo uni- 3. Determina el precio del producto modelo conceptual, ya que toda su informacién proviene de otras fuentes. Este es versal de productos (CUP) enca’ ya la transaccién de ventas le ‘un buen motivo para excluirl. da producto. agrega la informacién sobre el pro- = Elrecibo cumple un papel especial respecto a las reglas de la empresa: al portador ducto. 7 Si hay més de un producto, el Se muestran la deseripeién y el eo el o-res i desslees le proacizs|atiithdosua|om a asia Cajero puede introducir también _precio del producto actual. Cath lacantidad. El recibo se excluiré, porque las devoluciones de productos no se incluyen en este ciclo de desarrollo, Se justificara su inclusién durante el ciclo que aborde el caso Devolver productos. Algunas de las frases nominales anteriores son concepto algunas pueden ser atributos de conceptos. Por favor, consulte el lector la seccién siguiente y el capitulo 5 dedicado a los atributos: en ellos encontrar sugerencias para distinguirlos, 9.5.2 El modelo conceptual del punto de venta (s6/o conceptos) Una debilidad de este enfoque es la imprecision del lenguaje natural; varias frases nominales pueden designar el mismo concepto o atributo, entre otras ambigiiedades que pueden presentarse. Pese a ello, no dudamos en recomendar usarlo en combi- nacién con el método de Lista de categoria de conceptos. La lista anterior de los nombres de conceptos puede representarse grificamente (fi- gura 9.6) en la notacién del diagrama de estructura estatica de UML, a fin de mostrar la génesis del modelo conceptual. 9.5 Conceptos idéneos para el dominio del punto de venta [wv | A partir de la Lista de categoria de conceptos y del andlisis de frases nominales genera- —— mos una lista de conceptos adecuados para incluirlos en la aplicacién del punto de | Vertasinee | | cajro Ctente cues | venta, La lista esté sujeta a la restriccidn de los requerimientos y simplificaciones que Lepotee JL Lt L se consideren en el momento: los casos simplificados de uso de Comprar productos, versién 1. _ _ . [Povo | [ Cssogeds”| —[Espcteacon| TPDV EspecificaciondeProducto (Pao _| | Proautoe deProducta Producto VentasLineadeProductos Tienda Cajero Figura 9.6 Modelo conceptual inicial del dominio del punto de venta, Venta Cliente | mn En capitulos posteriores trataremos de los atributos y asociaciones del modelo con- Pago Gerente ceptual CatélogodeProductos DAD DE % HEPUMLICA DOCUMEN aciN ¥ BTELIOTECA MONTEVIDEO - URUGHAY 959 - CONSTRUCCION DE UN MODELO CONCEPTUAL 9.6 Directrices para construir modelos conceptuales 9.6.1. Cémo construir un modelo conceptual Aplique los siguientes pasos para crear un modelo conceptual: _— Para construir un modelo conceptual: | 41. Liste los conceptos idéneos usando la Lista de categorias de conceptos y la identificacion de la frase nominal relacionadas con los requerimientos en | cuestisn, 2. Dibijelos en un modelo conceptual. 3. Incorpore las asociaciones necesarias para registrar las relaciones para las cuales debe reservar un espacio en la memoria (tema que se expondra en un capitulo posterior). 4. Agregue los atributos necesarios para cumplir con las necesidades de infor- macién (tema que se tratara en un capitulo posterior) 9.6.2 La asignacién de nombres y el modelado de las cosas: el cartégrafo La estrategia del cartégrafo se aplica a los mapas y a los modelos conceptuales, —— Prepare un modelo conceptual inspirandose en la metodologia del cartégrafo: = Utilice los nombres existentes en el territorio, 1 Excluya las caracteristicas irrelevantes. = No agregue cosas que no existan. El modelo conceptual es una especie de mapa de conceptos 0 cosas de un dominio, Este enfoque pone de relieve el papel analitico de un modelo conceptual y sugiere lo siguiente: = Los cartégrafos se sirven de nombres del territorio—no cambian los nombres de ciudades en sus mapas. En el caso de un modelo conceptual, ello significa utilizar el vocabulario del dominio cuando se asignan nombres a los conceptos y a 10s atributos. Por ejemplo, al desarrollar el modelo de una biblioteca, al cliente se le designaré con los nombres que utilice el personal: Visitante, Lector u otro semejante. 9.6.3 9.7 9- CONSTRUCCION DE. UN MODELO CONCEPTUAL = Un cartégrafo elimina cosas en el mapa en caso de que no las juzgue pertinentes para el propésito que persigue; asi, no es necesario que muestre la topografia ni las poblaciones. De modo analogo, un modelo conceptual puede excluir en el dominio del problema los conceptos que no se relacionen con los requerimientos, Por ejemplo, podemos omitir Pluma y BolsadePapel en nuestro modelo conceptual (con el conjunto actual de requerimientos), por no tener una funcién importante que sea obvia, = Un cartégrafo no muestra cosas que no existan; por ejemplo, una montafa inexis- tente. En forma parecida, e! modelo conceptual ha de excluir las cosas que mo se encuentren en el dominio del problema en cuestién, Un error que se comete frecuentemente al identificar los conceptos Tal vez el error mas frecuente cuando se crea un modelo conceptual es el de represen: tar algo como atributo, cuando debié haber sido un concepto. Una regla prictica para no caer en él es: | Si en el mundo real no consideramos algtin concepto X como numero 0 texto, probablemente X sea un concepto y no un atributo, Por ejemplo, pongamos el caso del dominio de las reservaciones en lineas aéreas. eDeberia Destino ser un atributo de Vuelo o un concepto aparte Aeropuerto? Vuelo | Aeropuerto 40.7 -— En el mundo real, un aeropuerto de destino no se considera nimero ni texto: es una ‘cosa masiva que ocupa espacio. Por tanto, Aeropuerto deberia ser un concepto, En caso de duda, convierta el atributo en un concepto independiente. Solucién de los conceptos similares: comparaci6n entre TPDV y Registro Antafio, mucho antes del advenimiento de las terminales instaladas en el punto de venta, una tienda llevaba un registro: un libro donde asentaba las ventas y los pagos. Con el tiempo fue automatizado en un registro mecéinico de efectivo, Hoy esa terminal desempena el papel del registro (figura 9.7). 979.8 CoNSTRUCCION DE UN MODELO CONCEPTUAL conceptos semejantes a con dstnto nombre [Sse a) ee eo I 1 Pita” nese pane ce tL | Veria [vent Figura 9.7 TPDVy registro son conceptos similares. Un registro es una cosa que asienta las ventas y los pagos, pero también lo es la terminal instalada en el punto de ventas. No obstante, el término registro parece tener un signifi- cado mas abstracto y denota una implementacién menos orientada que TPDV. Pues bien, gen el modelo conceptual deberiamos utilizar el simbolo Registro en vez de TPDV? Primero, una regla practica consiste en que un modelo conceptual no es absoluta- | ‘mente correcto ni erréneo, sino de mayor 0 menor utilidad; es una herramienta de la comunicacién. Conforme al principio del cartégrafo, TPDV es un término usual en el tertitorio, por lo cual es un simbolo itil desde el punto de vista del conocimiento y la comunicacién, Registro es atractivo y stil, segrin la meta de crear modelos que representen abstrac- ciones y que no dependan de la implementacién.! Ambas opciones tienen sus bondades. En este caso de estudio hemos escogido TPDV de modo un tanto arbitrario; también pudimos haber escogido Registro, Construccién de un modelo del mundo irreal Algunos sistemas de software estén destinados a dominios que presentan muy poca semejanza con los dominios naturales 0 con los de las empresas; un ejemplo lo consti- tuye el software de las telecomunicaciones, Todavia es posible crear un modelo concep- tual en esos dominios, pero se requiere un alto grado de abstraccién y abandonar los disefios comunes. + Notese que antafio un regisro era simplemente una implementacion posible de la manera de registrar las ventas. Con el tiempo, su significado ha ido generalizandose. 9.9 9.9.1 9 - CONSTRUCCION DE UN MODELO CONCEPTUAL, Enumeramos algunos conceptos adecuados que se relacionan con un intercambio de telecomunicaci fensaje, Conexién, Didlogo, Ruta, Protocolo, Especificaci6n 0 descripcién de conceptos Suponga lo siguiente: = La instancia de Elemento representa una entidad fisica de una tienda; puede ser incluso un mimero serial. = Un Elemento tiene una descripcién, precio y cédigo universal de producto, los cuales no estén registrados en ninguna otra parte. = Todos los que trabajan en la tienda sufren amnesia. = Cada vez que se vende un elemento fisico, en “terreno del software” se elimina una instancia del software correspondiente a Elemento, Con estas suposiciones, preguntamos: ¢qué sucede en el siguiente escenario? Existe gran demanda de una nueva hamburguesa: ObjetoHamburguesa. La tienda vende todas sus existencias, lo cual significa que todas las instancias de Elemento de ObjetoHamburguesa se cancelan en la memoria de la computadora, Ahora bien, ésta es la esencia del problema: si alguien pregunta: “:Cudnto cuesta el ObjetoHamburguesa?”, nadie podra contestarle porque la memoria de su precio se anexé a las instancias inventariadas, que fueron elimindndose conforme se vendfan. Notese asimismo que el modelo actual, si se implementa en el software tal como se describe, posee datos duplicados y maneja ineficientemente el espacio, porque la des- cripeién, el precio y el cédigo universal de producto se duplica en cada instancia de Elemento del mismo producto. Necesidad de las especificaciones El problema anterior demuestra la necesidad de un concepto de objetos que son espe- cificaciones o descripciones de otras cosas. Para resolver el problema del Elemento lo que se necesita es una EspecificaciondeProducto (0 EspecificaciondeElemento, Descrip- ciondeProducto, ..) concepto que registra la informacion sobre los elementos, Una Espe- cificaciondeProducto no representa un Elemento, sino una descripcién acerca de ellos. Notese que, aunque todos los elementos inventariados se vendan y se eliminen sus instancias correspondiente de software, se conserva la EspecificaciondeProducto. La descripcién o especificacién de objetos se relacionan bastante con aquella que des- criben. En un modelo conceptual, se acostumbra estipular que una EspecificacionX describe una X.9.9.2 9.9.3 100 {9- CONSTRUCCION DE UN MODELO CONCEPTUAL Producto | ‘escripcion = prec Foret de sare oor | ee EspecticaciondeProduct eseripcion precio cur | 1 * | pumero de serie Figura 9.8 Especificaciones de otras cosas. El signo **” significa una multiplicidad de “muchos Indica que una EspecificaciondeProducto puede describir muchos (*) Productos. La necesidad de especificar los conceptos es frecuente en los dominios de ventas y productos, También lo es en la manufactura, donde se requiere una descripcién de lo manufacturado que se distingue de la cosa manufacturada. El tiempo y el espacio han sido incluidos al explicar la causa de la especifcacién de conceptos, por ser muy comunes; no se trata de un concepto poco usual de la construccidn de modelos. Cuando se requiere especificar los conceptos? Las siguientes directrices indican cuando emplear las especificaciones. Incorpore una especificacién 0 descripcién de conceptos (por ejemplo, Especifica- ciondeProducte) cuando: | = Laeliminacién de las instancias de las cosas que describen Elemento, por ejem- plo, da por resultado una pérdida de la informacién que ha de conservarse, 13.11 Figura 13.6 Definicién de la frontera del sistema, 3.10 Asignacién de nombre a los eventos y a las operaciones de un sistema Los eventos de un sistema (y sus operaciones asociadas) deberian expresarse en el nivel de propésito y no el medio fisico de entrada o en el nivel de elementos de la interfaz. ‘También mejora la claridad si el nombre de un evento del sistema comienza con un verbo (agregar... introducir.., terminar... efectuar..), como en la figura 13.7, porque recalca que los eventos estin orientados a comandos. x Calero ‘Tembee ms jeone 9 _inroduceProducto(CUP, cantidad) IntroducieTeclaOprimida ° (CUP, cantidad) Figura 13.7 Escoja los nombres de los eventos y de las operaciones en un nivel abstracto, 142 Presentacién del texto del caso de uso En ocasiones conviene mostrar al menos fragmentos del texto del caso de uso dentro. del diagrama de la secuencia, con el fin de describir gréficamente su estrecha relacién con el caso de uso (figura 13.8). ‘Sistema | En todos los productos, el Cajero registra el Codigo universal ‘de producto (CUP) y la caida __IntroductrProducto (CUP, cantidad) [termina de captrar el producto, terminarVerta() 2 Caoroindea dia TOV cue bmn ny, ia vans onc. El Cajero le indica el total al Clento,y éso le da.un pogo 1 Cajoro registra ol importe recibice on elective Figura 13.8 Diagrama de la secuencia de un sistema con texto del caso de uso. 143,118 - COMPORTAMIENTO DE. LOS SISTEMAS: DIAGRAMA DE LA SECUENCIA DEL SISTEMA, 13.12 Modelos muestra Los diagramas de la secuencia de un sistema forman parte del modelo del compor- tamiento del sistema, como se advierte en la figura 13.9, la cual especifica a qué eventos responde un sistema y qué responsabilidades y poscondiciones tiene sus operaciones Creede COMPORTAMIENTO i rn DE LOS SISTEMAS: CONTRATOS | ! \ ee Objetivos Crear contratos para las operaciones de un sistema 14.1 Introduccién ; ‘Figura 13.9 Modelo del anilisis. ‘Los contratos contribuyen a definir el comportamiento de un sistema; describen el efecto que sobre é1 tienen las operaciones. En este capitulo estudiaremos su utili- zacion. El lenguaje UML ofrece un soporte para definir los scontrnens: ya que permite definir las precondiciones y las poscondiciones de las operaciones. 14.2 Actividades y dependencias Los contratos de operacién del sistema se elaboran durante la fase de andlisis en un ciclo de desarrollo. Su preparacién depende del desarrollo previo del modelo conceptual, de los diagramas de la secuencia del sistema y la identificacién de sus operaciones. 1 En la definiciOn formal del UML —o metamodelo—, las operaciones tienen un conjunto de propiedades predefinidas que incluye sus precondiciones y poscondiciones. 14414- CoMPORTAMIENTO DE LOS SISTEMAS: CONTRATOS fas +] Cases 6 use Actividades de la fase de andlisis dentro de un ciclo de desarrollo. ae etna Cas coors |< a « co reas feo] Yrperan rece - 7 Dagaras de aoe — Dagares fe let aioe J Wea ; T reteset [ Glosario {it Diagramas 4 Definiciones | Sageess [| ore, |, ome [TB Daperas »| de secuencia satan | act Diagramas |! ns sora ta ender reap a Conaina (e np i sl Seatbe 14.5 amas “-f Esquema de | Cetane. | rinse, sa. Dependencias de los artefactos durante la fase de construccién. 114 CoMPORTAMIENTO DE LOS SISTEMAS: CONTRATOS Comportamiento de un sistema Antes de emprender el diserio Iogico de cémo funcionaré una aplicacién de software, es, necesario investigar y definir su comportamiento como “caja negra’. El comporta- miento de un sistema es una descripcién de fo que hace, sin explicar ebmo lo hace. Los contratos son documentos muy ttiles que describen el comportamiento de un sistema a partir de cémo cambia el estado de un sistema cuando se llama una operacién suya. Contratos En la figura 14.1, el diagrama de la secuencia de un sistema muestra los eventos gene- rados por tn actor externo, pero no profundiza en los detalles de la funcionalidad aso- ciada con las operaciones invocadas. No contiene los detalles necesarios para entender la respuesta del sistema, 0 sea su comportamiento, En términos generales, un contrato! es un documento que describe lo que una opera- ‘cién se propone lograr. Suele redactarse en un estilo declarativo, enfatizando lo que sucederd y no cémo se conseguird. Los contratos suelen expresarse a partir de los cambios de estado de las precondiciones y de las poscondiciones. Puede elaborarse un contrato ‘para un método de una clase de software o para una operacién més global del sistema. Elcontrato de operacién del sistema describe los cambios del estado del sistema total cuando se llama una de sus operaciones. ‘stoma | teoninaiVonta) ‘reoduorPodicoy ° ecuarP age) | Figura 14.1 Las operaciones del sistema requieren las descripciones del contrato. Repetimos: un contrato puede emplearse con una operacién de alto nivel que se aplica al sistema entero 0 con un método de bajo nivel de una clase particular. Por ahora nos centraremos en su uso en las operaciones del sistema, Ejemplo de contrato: introducirProducto Enel siguiente ejemplo se describe un contrato de la operacién introducirProducto del sistema. 1 Bertrand Meyer fue el primero en difundir el término. 147|M4- COMPORTAMIENTO DE LOS SISTEMAS: CONTRATOS. |4- CoMPORTAMIENTO DE LOS SISTEMAS: CONTRATOS Referencias ‘Niimeros de referencia de las funciones del sistema, casos Contrato ceruzadas: de uso, etcétera. Nombre: introducirProducto Notas: Notas de diseno, algoritmos ¢ informacién afin. (cup: nimero, Excepciones: Casos excepcionales. cantidad: entero). ; i ; : Salida: No salidas de la Interfaz del Usuario; por ejemplo, men- Responsabi- Capturar (registrar) la venta de un producto y agregarla sajes o registros que se envian afuera del sistema. lidades: ala venta. Desplegar la descripcién y el precio del, Precondich ; . . producto. ‘condiciones: _Suposiciones acerca del estado del sistema antes de eject- & tar la operacién. Tipo: sistema, Poscondiciones: Referencias Funciones del sistema: R1.1, R13, R19. cruzadas: Casos de uso: Comprar productos. . = Elestado del sistema después de la operacién. Esto se explica a fondo en la Notas: Utilizar el acceso superrapido a la base de datos. siguiente seccién, Excepcions Si el CUP no es valido, indicar que se cometié un error. Salida: . Precondiciones: __EI sistema conoce el CUP. 14.7 Cémo preparar un contrato Poscondiciones: & Sise trata de una nueva venta, se crea una Venta (creacién de instancia). Aplique la siguiente sugerencia para elaborar contratos. = Sise trata de una nueva venta, la nueva Venta fue asociada a TPDV (asociacién for- = Secreé una instancia VentasLineadeProducto (creacién de instancia). 1. Identifique las operaciones del sistema a partir de los diagramas de su um Seasocié una instancia VentasLineadeProducto ala Venta (asociacién formada). 2. Elabore un contrato en cada operacién del si m= Se asigné cantidad a VentasLineadeProducto.cantidad (modificacién de atributo). 3. Comience redactando la seccién de Responsabilidades; después describa infor- malmente el propésito de la operacién. = Se asocié una instancia VentasLineadeProducto a la instancia EspecificaciondePro- ducto, basado esto en la correspondencia del CUP (asociacién formada). | 4 Complete luego la seccién de Poscondiciones, describiendo en forma declara- tia los cambios de estado de los objetos en el modelo conceptual : 5. Para describ as poscondiciones utile ls sigulentes catego 14.6 Secciones del contrato creanény ehminecén de sina a 2 Mo icacién de los atributos. Una descripcién de las secciones de un contrato se da en el siguiente esquema. No todas las secciones son necesarias; nosotros recomendamos las de Responsabilidades i coelecione: forinauas y caticasuas -y Poscondiciones. ee ee) Contrato ‘Nombre: Nombre de la operacién y parémetros. 14.7.1 Contratos y otros artefactos Responsabi- Descripcién informal de las responsabilidades que lidades: debe cumplir la operacién. Los casos de uso sugieren los diagramas de los eventos y de la secuencia del Tipo: ‘Nombre del tipo (concepto, clase de software, sistema. interfaz). a Después se identifican las operaciones del sistema. 148 149,14.8 150 14 - COMPORTAMIENTO DE LOS SISTEMAS: CONTRATOS = Elefecto de las operaciones del sistema se describe en los contratos, aero Sistema ‘Gperecion CASQDE USO: IrosucProducte COMPRAR PRopucTos ‘nroduciroducto Pscondconas: (exw, Sian tga un cantidd) eva vos, Wo crada Creo noms eaten omen = Sistema va =) = teminarvera)| = 1. cade ‘eure iotucrrstco) 80 comienza etocua?a peracion ae temnarventa sfoctuxPago (onto) Pecendlones me 1 20 de uso Diagrama do Operacione Contratos In secuoncia ‘el sistema del latema 14.8.2 Figura 14.2 Contratos y otros artefactos. Poscondiciones Nétese que las poscondiciones en el ejemplo introducirProducto incluyen una clasifi cacién; por ejemplo, creaciém de instancias 0 asociacién formada, Después de la seccién de Responsabilidades, la parte més importante del contrato son las poscondiciones, 14.9 que estipulan cémo cambis el sistema tras esta operacién. No son acciones que deben efectuarse durante la operacién; mas bien son declaraciones sobre el estado del sistema que se aplican una vez concluida la operacién, es decir, una vez que el humo se hha disipado, ELUML no impone limites a la manera de expresar las poscondiciones; pero las siguien- tes categorias de cambio de estado han resultado de gran utilidad en la practica. Le aconsejamos expresar sus poscondiciones de una manera similar. Categorias utiles referentes a las poscondiciones del contrato: = Greacién y eliminacién de las instancias. m Modificacién de los atributos. = Asociaciones formadas y canceladas. ee Yt 14. COMPORTAMIENTO DE LOS SISTEMAS: CONTRATOS EL UML no define cémo expresar las poscondiciones; as{ que puede usted escoger el formato que més le agrade. Lo importante es que adopte una actitud declarativa, orien tada al cambio de estado y no a la accién, porque las poscondiciones deberian ser declaraciones sobre los estados o resultados, no una descripcién de acciones a realizar. 14.8.1 Las poscondiciones se relacionan con el modelo conceptual Las poscondiciones se expresan dentro del contexto del modelo conceptual. ¢Qué instancias es posible crear? La respuesta es: las provenientes de ese modelo. :Qué aso- ciaciones es posible formar? La respuesta es: las que estan en el modelo conceptual. Y asi pociriamos ir formulando y contestado més preguntas. Cuando se elaboran contratos, generalmente el lector se percatard de la necesidad de registrar en el modelo conceptual nuevos conceptos, atributos 0 asociaciones. No se limite usted a la definicién precedente del modelo conceptual: mejérelo conforme vaya haciendo mas descubrimientos, mientras reflexiona sobre los contratos de las operaciones. La ventaja de las poscondiciones Expresado en una forma declarativa de cambios de estado, el contrato constituye una excelente herramienta de investigacién, pues permite describir los cambios necesarios para que el sistema funcione sin necesidad de describir cémo se logran. En otras pala- bras, podemos posponer el disefo y la solucién del software y concentrarnos analitica- mente en lo que debe suceder, no en la manera de conseguirlo. El espiritu de las poscondiciones: el escenario y el telén Las poscondiciones deberian describir el estado de un sistema, no las acciones a rea- lizar. Expréselas en tiempo pasado para enfatizar que se trata de declaraciones sobre un cambio pretérito de estado. Por ejemplo: ‘= Se creé una instancia Ventas/.ineadeProducto (mejor); en lugar de = Crear una instancia VentasLineadeProducto (peor), Reflexione sobre las poscondiciones sirviéndose de la siguiente imagen: El sistema y sus objetos se presentan en el escenario de un teatro. 1. Tome una fotografia del escenario antes de la operacién. 2. Corra el telén del escenario y aplique la operacién del sistema (ruido de fondo con sonidos metdlicos, gritos, chillidos..). 3. Corra el telén y tome una segunda fotografia. 15114 - COMPORTAMIENTO DE 10S SISTEMAS: CONTRATOS 4. Compare las fotografias de antes y después, y exprese como poscondiciones los cambios del estado del escenario (Se cred la instancia VentasLineadeProducto.. 14.10 Explicacién: poscondiciones de introducirProducto En la siguiente seccién analizaremos por qué se utilizan las poscondiciones de Ia ope- racion del sistema de introducirProducto. 14.10.1 Creacién y eliminacion de instancias Una ver que el cajero capturé el cédigo universal de producto (CUP) y la cantidad de un producto, qué nuevos objetos han de crearse? Si se trata de una nueva venta, habria que crear una instancia para una nueva Venta. Una instancia VentasLineadePro- ducto deberia ser creada de modo incondicional. Por tanto: m= Sise trata de una nueva venta, se creé una Venta (creacién de instancia). = Se cred una instancia VentasLineadeProducto (creacién de instancia). 14.10.2 Modificacién de atributos Una vez, que la cajera capturé el cédigo universal de producto y la cantidad de un pro- ducto, zqué atributos de los objetos nuevos o actuales deberian ser modificados? Habria que establecer la cantidad de VentasLineadeProducto. Por tanto: = Se definié para VentasLineadeProducto.cantidad el valor de cantidad (modificacién del atributo). 14.10.3 Asociaciones formadas y canceladas Una vez que el cajero capturé el cédigo universal de producto y la cantidad de un pro- ducto, zqué asociaciones entre los objetos nuevos y los actuales debieron haber sido formadas 0 canceladas? Habria que haber relacionado la nueva instancia Ventas- LineadeProducto con sus Ventas y con su Producto. Si se trataba de una nueva venta, la Venta debié haber sido relacionada con la’TPDV dentro de la cual es registrada. Por tanto: = Sie trata de una venta nueva, la nueva Venta fue asociada a la TPDV (asociacién formada). = Una instancia VentasLineadeProducto fue asociada a la Venta (asociacién for- mada). = Una instancia VentasLineadeProducto fue asociada a una EspecificaciondeProducto, con base en la correspondencia del CUP (asociacién formada). 152 114 - COMPORTAMIENTO DE 1.08 SISTEMAS: CONTRATOS 14.11 {Cuan completas deben ser las poscondiciones? En la fase de andlisis no es probable —ni siquiera necesario— generar un grupo de poscondiciones completas y exactas de la operacién del sistema. Aconsejamos ver en su elaboracién la conjetura inicial mas acertada, a sabiendas de que los con- tratos estarén incompletos. Esta creacién temprana —aunque incompleta— sin duda es preferible a posponer la investigacién hasta la fase de disefio, cuando los creadores se concentraran en el disefio de una solucién mas que en averiguar lo que debe hacerse. Algunos de los detalles finos —y quiz hasta los mas generales— se descubrirdn durante la fase de disefio. No es algo necesariamente malo; en Ia fase de investi- gacién se debilitan el esfuerzo y la dedicacién si se prolongan demasiado tiempo. En la fase de disefio se logran algunos descubrimientos que después pueden guiar la fase de investigacién de un ciclo iterativo posterior. Una de las ventajas del desa- rrollo iterativo es ésta: los descubrimientos hechos en la fase de disefio de un cicto pueden mejorar la calidad de la investigacién y el trabajo de andlisis en el siguiente ciclo. 14.12 Descripcidn de los detalles y algoritmos del disefio: notas Laseccién del contrato correspondiente a Notas es el lugar donde pueden hacerse las declaraciones del disefio referentes a la operacién. Por ejemplo, si se sabe que se pre- fiere un algoritmo en particular para manejar la operacién, esa seccién es el sitio idé- neo para su documentacién, 14.13 Precondiciones Las precondiciones definen las suposiciones sobre el estado del sistema al iniciarse la operacién, Hay muchas precondiciones que pueden declararse en una operacion, pero la experiencia revela que vale la pena mencionar las siguientes: = Cosas que son importantes probar en el software en algiin momento de la ejecu- cidn de la operacién. = Cosas que no seran sometidas a prueba, pero de las cuales depende el éxito de la operacién, Queremos compartir esta suposicién con los futuros lectores del contrato, a fin de subrayar su importancia y de que los lectores se percaten de ella, 163