Metodologia Iconix 1-2-3

1

Casos de Uso GuiadosPor Modelado de ObjetosCon UML.

Doug Rosenberg yMatt Stephens

2

Use Case Driven Object Modeling with UML: Theory and PracticeCopyright © 2007 by Doug Rosenberg and Matt StephensAll rights reserved. No part of this work may be reproduced or transmitted in any form or by any means,electronic or mechanical, including photocopying, recording, or by any information storage or retrievalsystem, without the prior written permission of the copyright owner and the publisher.ISBN-13 (pbk): 978-1-59059-774-3ISBN-10 (pbk): 1-59059-774-5Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrenceof a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademarkowner, with no intention of infringement of the trademark.Lead Editor: Jonathan GennickTechnical Reviewer: Dr. Charles SuscheckEditorial Board: Steve Anglin, Ewan Buckingham, Gary Cornell, Jason Gilmore, Jonathan Gennick,Jonathan Hassell, James Huddleston, Chris Mills, Matthew Moodie, Dominic Shakeshaft, Jim Sumser,Matt WadeSenior Project Manager: Tracy Brown CollinsCopy Edit Manager: Nicole FloresAssistant Production Director: Kari Brooks-CoponySenior Production Editor: Laura CheuCompositor: Linda Weidemann, Wolf Creek PressProofreader: Nancy RiddioughIndexer: Toma MulliganArtist: Kinetic Publishing Services, LLCCover Designer: Kurt KramesManufacturing Director: Tom DebolskiDistributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor,New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail [email protected],or visit http://www.springeronline.com.For information on translations, please contact Apress directly at 2560 Ninth Street, Suite 219, Berkeley,CA 94710. Phone 510-549-5930, fax 510-549-5939, e-mail [email protected], or visit http://www.apress.com.The information in this book is distributed on an “as is” basis, without warranty. Although every precautionhas been taken in the preparation of this work, neither the author(s) nor Apress shall have anyliability to any person or entity with respect to any loss or damage caused or alleged to be caused directlyor indirectly by the information contained in this work.

3

The UML model and source code for the example use cases in this book are available to readers athttp://www.apress.com and http://www.iconixprocess.com/InternetBookstore.

4

Para Rob, quien tiene el futuro mas brillante lo sé.Mantén el balón donde se hacen os puntos,

Y buenas cosas seguirán pasando.—Doug Rosenberg

Para Michelle, por su inacabable paciencia y apoyo.—Matt

5

Acerca de los autores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XV

Sobre el revisor técnico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

Agradecimientos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX

Prefacio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XXI

Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXVII

CAPITULO I Introducción al Proceso ICONIX. . . . . . . . . . . . . . . . . . . . . . . . .1

PARTE 1 Definición de los

RequisitosCAPITULO 2 Modelo de

Dominio. . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

CAPITULO 3 Modelo de Casos de Uso.. . . . . . . . . . . . . . . . . . . . . . .

.49

CAPITULO 4 Revisión de

Requisitos. . . . . . . .. . . . . . . . . . . . . . . . . . . .83

PARTE 2 Análisis, Diseño

Conceptual y

Arquitectura TécnicaCAPITULO 5 Análisis de

Robustez. . . . . . . . . . . . . . . . . . . . . . . . . . . .101

CAPITULO 6 Revisión Preliminar del Diseño. . . . . . . . . . . . . . . . . . .

143

CAPITULO 7 Arquitectura Técnica. ... . . . . . . . . . . . . . . . . . . . . . . .

159

6

CONTENIDO

PARTE 3 Diseño y CodificaciónCAPITULO 8 Diagramas de

Secuencia. . . . . . . . . . . . . . . . . . . . . . .185

CAPITULO 9 Revisión Crítica del Diseño. . . . . . . . . . . . . . . . . . . . . .

233

CAPITULO 10 Implementación: Paso del Diseño detallado

al Código. . . . . . . ... . . . . . . . ... . . . . . . . ... . . . . . . . . . 257

CAPITULO 11 Revisión del código y

Actualización del modelo. . . . . . . . . . . . . . . . . . . . . . 297

PARTE 4 Pruebas y Trazabilidad de

RequisitosCAPITULO 12 Diseño guiado por pruebas. . . . . . . . . . . . . . . . . . . . .

329

CAPITULO 13 Atendiendo Requisitos. . . . . . . . . . . . . . . . . . . . . . . .

373

PARTE 5 ApéndicesCAPITULO 14 Que hay de nuevo en UML 2.0. . . . . . . ... . . . . . . . . .

395

CAPITULO 15 Spring Bin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .

. . 409

INDICE. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .

425

7

Un proceso es mucho más grande Y el otro demasiado pequeño Y el completo UML que OMG te da Es incomprensible para todos. . .

(Canta a la melodía de "Go Ask Alice" de Jefferson Airplane)

En teoría, todos y cada uno de los aspectos de UML es potencialmente útil, pero en la práctica, nunca parece haber suficiente tiempo para hacer el modelado, análisis y diseño. Siempre hay presión por parte de la administración para saltar al código e iniciar la codificación de forma prematura, porque los avances en proyectos de software tienden a medirse por la cantidad de código existente. El proceso ICONIX, tal y como se muestra en la figura de apertura de este capítulo, es minimalista, tiene un enfoque racionalizado que se centra en esa zona que se encuentra entre los casos de uso y el código. Su énfasis está en lo que tiene que pasar en ese momento del ciclo de vida que se está comenzando: donde ya se tiene un inicio en algunos casos de uso, y es momento de hacer un buen análisis y diseño.

CUANDO USAR UN LIBRO DE COCINA (RECETARIO)

8

C A P I T U L O 1

Introducción al Proceso ICONIX

s

Hay una creciente idea equivocada en el desarrollo de software y es que los libros de de desarrollo de software con enfoques tipo recetario no funcionan. Estamos de acuerdo con esto hasta cierto punto porque el análisis y la programación son enormes, campos muy complejos, y el número de diferentes tipos de proyectos de software es aproximadamente igual al número de proyectos de software. Sin embargo, creemos firmemente que el análisis y el diseño pueden-y de hecho deberían ser una secuencia de pasos repetible como los de un recetario. Estos pasos no deben ser grabados sobre una piedra (es decir pueden y deben ser adaptados), pero ayuda siempre tenerlos ahí. En un mundo lleno de dudas e incertidumbre, es bueno tener una clara y definida secuencia de pasos y respuestas al “¿Cómo hacer?” para poder empezar.Mucho antes, en los días del pre-UML cuando Doug empezaba a enseñar un modelo de enfoque unificado de Booch / Rumbaugh / Jacobson (alrededor de 1992-1993), uno de sus primeros clientes de formación le animó a “escribir un libro de cocina porque a mi gente le gusta seguir los enfoques de los libros tipo recetario”. Aunque muchos han afirmado que es imposible codificar prácticas de análisis y diseño orientado a objetos (OOAD) en un simple y repetible conjunto de pasos (y probablemente no es posible en su totalidad), ICONIX posiblemente se aproxime lo más cerca a un libro tipo recetario para OOAD.Si bien es cierto aún hay margen significante para la flexibilidad con el enfoque (por ejemplo, agregando diagramas de estado o actividad), ICONIX establece un procedimiento sencillo y un conjunto mínimo de pasos que suelen dar lugar a muy buenos resultados. Estos resultados han demostrado ser coherentes y repetibles en los últimos 12 años.

El proceso ICONIX en teoría.En esta sección proporcionamos una visión general del proceso de ICONIX, mostrando cómo todas las actividades funcionan juntas. Empezaremos con una revisión de muy alto nivel de opinión (una especie de un panorama general de otro panorama general) y luego examinaremos cada una de las actividades con más detalle. Mientras avance a través de la visión general, que le proporcionaremos remítase al diagrama del proceso que se halla al inicio de este capítulo, para ver cómo encaja cada parte en el proceso general.

Descripción: De los casos de uso al código fuente.El diagrama al inicio de este capítulo le ofrece una visión general del proceso ICONIX. (Vamos a repetir este diagrama al inicio de cada capítulo, con la sección correspondiente del diagrama de color rojo.) Como se puede ver en el diagrama, ICONIX se divide en flujos de trabajo estáticos y dinámicos que son altamente iterativo: puede ir a través de una iteración de toda el proceso para un pequeño lote de casos de uso (tal vez un par de paquetes válidos que no es gran cantidad teniendo en cuenta que cada caso de uso es tan solo un par de párrafos), todo el camino desde el código fuente hasta las pruebas unitarias. Por esta razón, ICONIX se adecua perfectamente a los proyectos ágiles, donde se necesita una rápida retroalimentación en factores tales como los requisitos, el diseño, y las estimaciones.

Vayamos a través de los pasos que cubriremos en el transcurso de este libro. Los elementos en rojo corresponden a los subtítulos en esta.

Al igual que con cualquier otro proyecto, en algún momento a principios de comenzar a explorar y definir los requisitos. Tenga en cuenta que dentro de cada fase hay un grado de paralelismo, de modo que todas las actividades en la fase de definición de requisitos se entrelazan y se superponen hasta que estén listas.

9

■ Nota Hay diferentes tipos de requisitos (por ejemplo, los requisitos no funcionales, tales como la escalabilidad). Sin embargo, en un proceso de nivel, los distinguimos en requisitos funcionales y requisitos de comportamiento.

1. REQUISITOS

a. Requisitos funcionales: Definir lo que el sistema debe ser capaz de hacer. Dependiendo de la forma en que su proyecto está organizado, ya sea que usted participe en la creación de los requisitos funcionales o que los requisitos serán "dictados desde lo alto" de un cliente o un equipo de analistas de negocios.

b. Modelo de Dominio: Entender el espacio del problema en términos inequívocos (sin ambigüedad).

c. Requisitos de comportamiento: Define la forma en que el usuario y el sistema interactúan (es decir, escribir el primer proyecto de casos de uso). Le recomendamos que empezar con un prototipo GUI (lo que llamamos “guión” GUI) e identificar todos los casos de uso que vamos a poner en práctica, o, al menos, llegar a una primera lista de casos de uso, que espera razonablemente cambiar a medida que se explora los requisitos con mayor profundidad.

d. Etapa 1: Revisión de Requisitos: Asegúrese de que la descripción de los caso de uso coincidan con las expectativas de sus clientes. Tenga en cuenta que se deben revisar los casos de uso en pequeños lotes, justo antes de diseñarlos.

Luego, en cada iteración (es decir, por un pequeño lote de casos de uso), haga lo siguiente.

2. ANALISIS/DISEÑO PRELIMINAR

a. Análisis de robustez: Dibuje un diagrama de robustez (una "imagen del objeto" de los pasos en un caso de uso), reescribiendo los casos de uso a medida que avanza.

b. Actualice el modelo de dominio mientras escribe los casos de uso y dibuje el diagrama de robustez. Aquí descubrirá algunas clases “perdidas”, corregirá las ambigüedades, y añadirá atributos a los objetos de dominio (por ejemplo: identificar que un libro tiene un Título, autor, sinopsis, etc.).

c. Nombre todas las funciones lógicas del software (controladores) necesitadas para hacer que los casos de uso funcionen.

d. Reescriba el primer borrador de casos de uso.

3. Etapa 2: Revisión del Diseño Preliminar (RDP)4. DISEÑO DETALLADO

10

a. Diagrama de Secuencia: Dibuje un diagrama de secuencia (un diagrama de secuencia por cada caso de uso) para mostrar en detalle cómo va a implementar el caso de uso caso. La función fundamental de los diagramas de secuencia es asignar comportamiento para sus clases.

b. Actualice el modelo de dominio mientras se dibujan los diagramas de secuencia, y añada operaciones1 a los objetos de dominio. En esta fase, los objetos de dominio son realmente clases de dominio, o entidades, el modelo de dominio debe convertirse rápidamente en un modelo estático, o diagrama de clases-una parte crucial de su diseño detallado.

c. Limpiar el modelo estático.

5. Piedra miliaria 3: Revisión del diseño crítico (RDC)

6. IMPLEMENTACIÓN

a. Código/pruebas unitarias: Escriba el código y las pruebas unitarias. (o, dependencia de sus preferencias, escriba las pruebas unitarias y luego el código2)b. Integración y pruebas de escenario: Base las pruebas de integración en los casos de uso, de modo que así probara ambos cursos, el básico y el alterno.c. Ejecute una revisión de código y actualice el modelo para prepararse para la próxima ronda de trabajo.

Para la mayor parte del resto de este capítulo, describimos estos pasos en un más detalle.

A lo largo del resto del libro, describimos estos pasos en mucho mayor detalle, y proporcionamos una gran cantidad de ejemplos y ejercicios para ayudarle a comprender la mejor manera para aplicarlos en su propio proyecto.

Requisitos

Figura 1-1 muestra los pasos envueltos en la definición de los requisitos de comportamiento -es decir, el dibujar el modelo de dominio inicial y escribir los el primer borrador de casos de uso.

Los pasos mostrados en la figura 1-1 son cubiertos en los capítulos 2, 3, y 4.

1 También llamados métodos, funciones o mensajes, dependiendo del lenguaje de programación que se use.2 Para los fanáticos de TDD, en el capítulo 12 mostramos un método para incorporar el enfoque de la primera prueba en el Proceso ICONIX. El resultado es esencialmente el “Diseño guiado por pruebas”

11

Análisis de Requisitos

12

Identifique los objetos del mundo real


Reunir información sobre el contexto del

sistema al que hace re-ingeniería



Tablas de la Base de datos

Hacer aun prototipo rápido

del nuevo sistema

propuesto

Hacer aun prototipo rápido

del nuevo sistema

propuesto

Dibuje el Modelo de Dominio


Ponga los objetos de dominio aquí

Organice los casos de uso lógicamente en grupos.

Capture esta información en un diagrama de paquete



Asigne requisitos funcionales a los casos

de uso y objetos de dominio.



Escriba el primer borrador de casos de

uso.


uso.

Etapa 1: Revisión de Requisitos

Figura 1-1. Análisis de Requisitos

Identifique casos de uso y ubíquelos en el diagrama de casos de

uso.


uso.

Pantallas

¿Requisitos funcionales (¿Que es capaz de hacer el sistema?)

Justo al inicio del proyecto, alguien (posiblemente un equipo de analizadores de negocio) hablará con el cliente, usuarios finales, y varios stakeholders, y esa persona (o el equipo) probablemente creen un paquete grande de documentos de Microsoft Word con los requisitos funcionales. Éste es un documento importante, pero es difícil crear un diseño de (o para crear una estimación exacta de,), mientras tiende a ser bastante inestructurado. (Aún si cada requisito es numerado en una lista de un documento grande, ese no hace todavía que cuente como estructurado.)

■Nota las fases iniciales del proceso ICONIX suponen crear un conjunto de requisitos de comportamiento inequívocas -sin ambigüedad-(casos de uso) que son más "cercanos al metal" que la especificación de los requisitos funcionales, y que puedan ser fácilmente diseñados.

Crear necesidades funcionales cae ligeramente fuera del alcance del proceso ICONIX, pero ofrecemos algunos consejos al respecto3. Probablemente el mejor modo para describir nuestro enfoque para recoger los requisito es listar nuestros 10 mejores consejos de Recolección de Requisitos. Describimos estos pasos con más detalle en el capítulo 13.

10.Use una herramienta modeladora que soporta enlace y trazabilidad entre requisitos y casos de uso.

9. Vincule los requisitos a los casos de uso arrastrando y soltando.8. Evite requisitos disfuncionales separando detalles funcionales de su

especificación de comportamiento.7. Escribir al menos un caso de prueba para cada requisito.6. Trate los requisitos como a ciudadanos de primera clase en el modelo.5. Distinga entre tipos diferentes de requisitos.4. Evite el síndrome de "gran documento monolítico”.3. Cree estimaciones de los escenarios de casos de uso, no de los

requisitos funcionales.2. No tenga miedo de ejemplos al escribir requisitos funcionales.1. No haga de sus requisitos una declaración técnica de moda.

Con los requisitos funcionales escritos (ya sea por su equipo o por alguien más), usted realmente querrá hacer algún análisis adicional, para crear un conjunto de requisitos de comportamiento (casos de uso) de los que puede crear un diseño preliminar de alto nivel.

3 En el capítulo 13 mostramos como enlazar sus casos de uso de regreso a los requisitos profesionales,

13

Modelando el Dominio

El modelamiento del dominio es la tarea de construir un glosario del proyecto, o un diccionario de términos usados en su proyecto (por ejemplo: un proyecto de una librería de on line incluiría objetos de dominio tales como Libro, Cliente, Orden e Id de Orden). Su propósito es asegurarse que todos en el proyecto comprendan el espacio del problema en términos inequívocos. El Modelo de Dominio para un proyecto defina el alcance y las formas y la base en la que se construye los casos de uso. El Modelo de Dominio proporciona también un vocabulario común para habilitar una comunicación clara entre los miembros de un proyecto. Es natural que las primeras versiones de su Modelo de Dominio sean erróneas; a medida que explore cada caso de uso, usted “re fortalecerá” el Modelo de Dominio.

Aquí están nuestros 10 mejores consejos para Modelar el Dominio. Los describiremos con más detalle en el Capítulo 2.

10. Enfóquese en los objetos del mundo real (Dominio del problema).9. Use las relaciones de generalización (es-un) y agregación (tiene-un) para

mostrar cómo los objetos se relacionan entre sí. 8. Limite sus esfuerzos para el modelado del dominio inicial a un par de horas. 7. Organice sus clases alrededor de abstracciones claves en el dominio del

problema. 6. No confundir el Modelo de Dominio con un Modelo de Datos. 5. No confunda un objeto (que represente una instancia en particular) con

una tabla de la base de datos (que contiene una colección de cosas). 4. Use el Modelo de Dominio como un glosario del proyecto. 3. Haga su Modelo de Dominio inicial antes de escribir sus casos de uso,

para evitar ambigüedad de nombres.2. No espere que su diagrama de clases final coincida con su Modelo de

Dominio, pero recuerde que debe existir cierto parecido entre ellos.1. No ponga pantallas y otras clases específicas del GUI en su Modelo de

Dominio.

Una vez que tenga el primer paso de su Modelo de dominio, puede usarlo para escribir los casos de uso-esto es, para crear sus requisitos de comportamiento, que introduciremos en la siguiente sección.

¿Requisitos de comportamiento (¿Cómo interactúan el usuario y el sistema?)ICONIX es un enfoque basado en escenarios; el mecanismo primario para descomponer y modelar el sistema es escenario-por-escenario. Cuando se usa ICONIX, la meta es producir un diseño orientado a objeto del que se pueda codificar. Por lo tanto, necesita vincular los escenarios a los objetos. Hace esto escribiendo los casos de uso utilizando el Modelo de Dominio que creó en el paso anterior.

Historial del GUILos requisitos de comportamiento detallan las acciones del usuario y las respuestas del sistema a esas acciones. Para la mayoría de los software, esa

14

interacción entre usuario y sistema toma lugar mediante pantallas, ventanas, o páginas. Cuando esté explorando los requisitos de comportamiento, capture los escenarios usados en forma de una narración de los casos de uso, y esta narración viene de una conversación detallada con los clientes y usuarios finales.

Es notoriamente difícil para nosotros los humanos representar un sistema propuesto en nuestra mente.A menudo es fácil para los clientes y usuarios finales relacionarlo con una ayuda visual, que muy menudo toma la forma de una secuencia de pantallas. Éstas pueden ser simples dibujos lineales en papel, una diapostiva que muestre las sucesiones por la pantalla, un prototipo de HTML, la forma exacta no importa mucho. Lo que es importante es que presentan la sucesión de pantallas a medida que aparecen los usuarios dentro del contexto de los escenarios usados que serán modelados.

Es también importante que las pantallas incluyan detalles sobre varios botones, menús, y otras regiones orientadas a la Interfaz de Usuario (UI). Es asombroso con qué frecuencia un case de uso hecho sin este tipo de acompañamiento de ayuda visual omitirá comportamiento del curso alterno para eventos como "El usuario hace sobre el botón Cancelar ", y cuan mejor los casos de uso llegan a ser cuando vienen acompañados Historial de UI.

Modelado de Casos de Uso

Los casos de uso describen el modo en el que el usuario interactúa con el sistema y cómo el sistema responde a esto. Aquí está nuestra Guía de los 10 mejores consejos para Modelar Casos de Uso. Los describimos con más detalle en el Capítulo 3.

10. Siga la regla de “dos párrafos”. 9. Organice sus casos de uso con actores y diagramas de casos de uso. 8. Escriba sus casos de uso en voz activa. 7. Escriba su uso embala usando un flujo de evento/respuesta,

describiendo ambos lados del diálogo del usuario/sistema. 6. Use Historiales de GUI, prototipos, pantallas, etc. 5. Recuerde que su caso de uso es realmente una especificación de

comportamiento en tiempo de ejecución (runtime). 4. Escriba los casos de uso en el contexto del Modelo de Objeto. 3. Escriba sus casos de uso usando una estructura de pronombre-verbo-

pronombre. 2. Referencie las clases de dominio por nombre. 1. Referencie las clases Interfaz (por ejemplo: pantallas) por nombre.

Etapa 1: Revisión de los Requisitos

Justo final de la figura 1-1, verá la etapa de Revisión de Requisitos. Este paso vital garantiza que los requisitos son sobrentendidos por ambos: el equipo de desarrollo y los clientes/usuarios/stakeholders.

Aquí están nuestros 10 mejores consejos para la Revisión de Requisitos. Los describimos con mayor detalle en el Capítulo 4.

15

10. Asegúrese de que su Modelo de Dominio describe al menos 80% de las abstracciones más importantes ( es decir: objetos del mundo real) del Dominio del problema, en un lenguaje no-técnico que sus usuarios finales pueden comprender.

9. Asegúrese de que su Modelo de Dominio muestra las relaciones “es-un” (generalización) y “tiene-un” (agregación) entre los objetos del dominio.

8. Asegúrese de que sus casos de uso describen ambos cursos, el básico y alterno, en voz activa.

7. Si tiene listas de los requisitos funcionales (es decir: declaraciones "deberá"), asegúrese de que éstos no absorben en el "intermangled" con la voz activa de las descripciones de los casos de uso4.

6. Asegúrese de tener organizado sus casos de uso en paquetes y que cada paquete tenga al menos un diagrama de casos de uso.

5. Asegúrese que sus casos de uso están escritos en el contexto del Modelo de Objetos.

4. Ponga sus casos de uso en el contexto de la interfaz de usuario. 3. Complementa la descripción de sus casos de uso con una especie de

historial, dibujos lineales, pantallas o prototipos GUI.2. Revise los casos de uso, Modelo de Dominio, pantallas/ prototipos GUI

con los usuarios finales, stakeholders, gente de marketing, además de miembros técnicos de su personal.

1. Estructure esta revisión guiado por nuestros "Ocho fáciles pasos para un caso de uso mejor" (vea el Capítulo 4).

Una vez que la Revisión de los Requisitos está completa, puede dirigirse a la fase de Diseño Preliminar.

Análisis/Diseño Preliminar

El análisis se enfoca en construir un sistema correcto. El diseño se enfoca en construir correctamente un sistema.El Diseño Preliminar es un paso intermedio entre el análisis y el diseño.

El Diseño Preliminar reconoce explícitamente algo que mucha gente reconoce implícitamente:

Usualmente no se pueden comprender del todo los requisitos con los que está lidiando a menos que se haga cierto diseño exploratorio.

Figura 1-2 (que sigue de la figura 1-1) muestra los pasos del Diseño Preliminar.

4 En el capítulo 13, introducimos el término “intermangled” para describir el texto de los casos de uso que tienen requisitos funcionales en sí mismos.

16


17

Realizar un Análisis de Robustez

Realizar un Análisis de Robustez

Desambiguar el primer borrador de casos de usoDesambiguar el primer

borrador de casos de uso

Identifique un primer corte de objetos que

realicen cada escenario.

Identifique un primer corte de objetos que

realicen cada escenario.

Actualice su Modelo de Dominio a medida que

descubre nuevos objetos y atributos

Actualice su Modelo de Dominio a medida que

descubre nuevos objetos y atributos

Termine de actualizar el Modelo de Dominio

a nivel de Análisis.

Termine de actualizar el Modelo de Dominio

a nivel de Análisis.

Para cada Caso de Uso…

Etapa 2: Revisión del Diseño Preliminar

Figura 1-2. Análisis/Diseño Preliminar

El paso del Diseño Preliminar (también conocido con el nombre de Análisis de Robustez) involucra hacer un diseño exploratorio que se necesita para comprender las requisitos del sistema, refinando y removiendo la ambigüedad de (también conocida con el nombre de desambigüación) esos requisitos como resultado del diseño exploratorio, y enlazando los requisitos de comportamiento (escenarios de casos de uso) a los objetos (Modelo de Dominio).

Los pasos mostrados en la figura 1-2 son cubiertos en los capítulos 5, 6 , y 7.

Análisis de Robustez

Para llegar de los casos de uso al diseño detallado (y luego al código), se necesita vincular los casos de uso a los objetos. El análisis de robustez le ayuda a unir la brecha entre análisis y el diseño haciendo exactamente eso. Es un modo de analizar la descripción de los casos de uso e identificar un supuesto primer conjunto de objetos para cada caso de uso.

Aquí están nuestros 10 mejores consejos para hacer un análisis de robustez. Los describimos con más detalle en el Capítulo 5.

10. Pegue el texto del caso de uso directamente en su diagrama de robustez.9. Tome sus clases entidad del Modelo de Dominio, y añada lo que falte.8. Se espere reescribir (desambiguar) los casos de uso al dibujar el

diagrama de robustez.7. Haga un objeto Interfaz para cada pantalla, y nombre sus pantallas

inequívocamente.6. Recuerde que los controladores son solo ocasionalmente Objetos de

control reales; son típicamente funciones de software lógicas. 5. No se preocupe por la dirección de las flechas en un diagrama de robustez. 4. Está bien arrastrar un caso de uso en un diagrama de robustez si se

invoca desde un caso de uso familiar.3. El diagrama de robustez representa un diseño conceptual preliminar de

un caso de uso, no un diseño detallado literal.2. Las clases Interfaz y Entidad en un diagrama de robustez generalmente

se convertirán instancias de objetos en un diagrama de secuencia, mientras que los controladores se convertirán en mensajes.

1. Recuerda que un diagrama de robustez es una "imagen de un objeto" de un caso de uso, cuyo propósito es forzar la refinación de ambos, el caso de uso y el Modelo de Objetos.

Con el Diseño Preliminar completo, sus casos de uso deben estar ahora completamente desambiguados y así escritos en el contexto del Modelo de Dominio. El Modelo de Dominio en sí debe haber ayudado a eliminar problemas comunes tales como nombres duplicados para el mismo item, y las clases en el Modelo de Dominio deben tener también los atributos asignados para sí mismas (pero no las operaciones, aún).

18

En teoría usted en este momento debe estar listo para iniciar el diseño detallado, pero en la práctica, lo que realmente ayuda es ejecutar una rápida Revisión del Diseño Preliminar (RDP) primero.

19


La sesión denominada Revisión del Diseño Preliminar (RDP) le ayuda a asegurarse de que los diagramas de Robustez, el Modelo de Dominio, y los casos de uso concuerden mutuamente. Esta revisión es el "paso" entre las fases del Diseño Preliminar y el Diseño Detallado, para cada paquete de casos de uso.

Aquí están nuestros 10 mejores consejos para la RDP. Describimos éstos consejos con más detalle en el Capítulo 6.

10. Para cada caso de uso, asegúrese de que el nombre del caso de uso coincida con el diagrama de robustez, usando la prueba de highlighter.

9. Asegure de que todas las entidades en todos los diagramas de robustez aparezca dentro del Modelo de Dominio actualizado.

8. Asegúrese de poder trazar flujos de datos entre las clases entidad y las pantallas.

7. No olvide curso alterno, y no olvide describir el comportamiento para cada uno de ellos cuando los encuentre.

6. Asegúrese de que cada caso de uso cubre ambos lados del diálogo entre usuario y sistema.

5. Asegúrese de no haber violado las reglas de sintaxis para análisis de robustez.

4. Asegúrese de que esta revisión incluye a ambos participantes: no-técnicos (cliente, equipo de marketing, etc.) y técnicos (programadores).

3. Asegúrese de que los casos de uso están en el contexto del Modelo de Objetos y en el contexto de la GUI.

2. Asegúrese de que los diagramas de robustez (y su correspondiente caso de uso) no intenta mostrar el mismo nivel de detalle que los diagramas de secuencia (es decir: no trate de hacer el Diseño Detallado aún).

1. Siga nuestros " seis fáciles pasos " para un mejor Diseño Preliminar (vea el Capítulo 6).

Con esta sesión de revisión completa, puede estar seguro de que los diagramas y casos de uso concuerdan entre sí, y que ambos están completos y representan correctamente el deseado comportamiento del sistema. Debería ser ahora un asunto relativamente sencillo crear el Diseño Detallado.

Diseño Detallado

El Diseño detallado se enfoca en construir el sistema correctamente. Esperamos que para el momento en el que llegue a este punto, tenga un buen entendimiento de lo que el "sistema correcto" es, porque tendrá que trabajar duro para desarrollar este razonamiento. Ahora se está preocupando por la eficiencia en términos de tiempo de ejecución, carga de red, y huellas de memoria, y está preocupado también por la reusabilidad del código.

La Figura 1-3 muestra los pasos envueltos en el Diseño Detallado.Los pasos mostrados en la figura 1-3 son cubiertos en los capítulos 8 y 9.


20

Divida el Modelo de Dominio en todos los Diagramas de Clases que sean necesarios

Divida el Modelo de Dominio en todos los Diagramas de Clases que sean necesarios

Asigne comportamiento

dibujando diagramas de Secuencia

Asigne comportamiento

dibujando diagramas de Secuencia

«automagic»Genere un diagrama de secuencia esqueleto de los objetos Entidad e

Interfaz en los Diagramas de Robustez

«automagic»Genere un diagrama de secuencia esqueleto de los objetos Entidad e

Interfaz en los Diagramas de Robustez

Dibuje flechas de mensajes entre objetos

Dibuje flechas de mensajes entre objetos«automagic»

Actualice el Diagrama de Clases con los

nuevos atributos y operaciones

«automagic»Actualice el Diagrama

de Clases con los nuevos atributos y

operaciones

«automagic»Genere pruebas unitarias

para todas las clases Control en el Diagrama de

Robustez

«automagic»Genere pruebas unitarias

para todas las clases Control en el Diagrama de

Robustez

Limpie el Modelo Estático

Limpie el Modelo EstáticoRevise el Diseño y asegúrese

que cumple con todos los requisitos

Revise el Diseño y asegúrese que cumple con todos los

requisitos

Para cada Caso de Uso…Etapa 3: Revisión del Diseño Crítico Figura 1-3. Diseño Detallado

Asigne operaciones a las clases

Un diagrama de secuencia por caso de uso

Diagramas de Secuencia (Asigne comportamiento a las clases)

El proceso ICONIX usa el diagrama de secuencia como el vehículo principal para explorar el Diseño Detallado de un sistema con base de escenario-por-escenario.

En el diseño orientado a objetos, una gran parte de la correcta construcción del sistema depende de hacer una asignación óptima de funciones a las clases (tcc: asignación de comportamiento). La esencia de ésta es dibujar flechas con mensajes en los diagramas de secuencia y hallar una herramienta modeladora para asignar de forma automática operaciones a las clases del objeto meta que recibe el mensaje en tiempo de ejecución.

A continuación nuestros 10 mejores consejos para hacer los Diagramas de Secuencia. Los describimos con más detalle en el Capítulo 8.

10. Comprenda porque está dibujando un diagrama de secuencia.9. Haga un diagrama de secuencia para cada caso de uso, con ambos

cursos, el básico y alterno en el mismo diagrama.8. Inicie su diagrama de secuencia con las clases Interfaz, clases entidad,

actores, nombres de los casos de uso que resultan del análisis de robustez.

7. Use el diagrama de secuencia para mostrar el comportamiento del caso de uso (es decir: todos los controladores del diagrama de robustez) realizado por los objetos.

6. Asegúrese su uso embalan mapas de texto a los mensajes ser pasando en la sucesión diagrama. Intente alinear el texto y las flechas de mensaje.

5. No gaste mucho tiempo preocupándose por el foco del control.4. Asigne operaciones a las clases mientras dibuja mensajes. La mayoría de

las herramientas de modelado visuales soportan esta capacidad.3. Revise sus diagramas de clases constantemente mientras asigna

operaciones a las clases, para asegurarse de que todas las operaciones corresponden a las clases apropiadas.

2. Prefactorizar su diseño en los diagramas de secuencia antes de codificar. 1. Deje limpio el Modelo Estático antes de proceder a la RDC.

Ahora, está casi listo para comenzar a codificar. Necesitará ejecutar una Revisión del Diseño Crítico (RDC) primero; pero antes de eso, se pagan dividendos para volver a revisar el Modelo Estático y limpiarlo.

Limpiar el Modelo Estático

Échele un largo vistazo a su Modelo Estático, con el deseo de ordenar su diseño, resolver problemas del diseño del mundo real, identificar patrones de diseño útiles que puedan ser factores para mejorar el diseño, y así en adelante. Esto se debe hacer al menos como un paso final antes de proceder a la RDC, pero puede estar pensando en este nivel en el diseño antes de dibujar los diagramas de secuencia.

En esta fase, debe tener un diseño muy bien hecho que trabaje dentro de las limitaciones del mundo real de de los requisitos de su proyecto, un

21

diseño de marco de aplicación, una topología de despliegue, etc. Existe una última parada antes de comenzar con el código: la RDC.

Etapa 3: Revisión del Diseño CríticoLa RDC le ayuda a lograr tres metas importantes, antes de comenzar con la codificación para el actual lote de casos de uso:

Asegurar que el " cómo " del Diseño Detallado concuerde con el "que " especificado en sus requisitos.

Revise la calidad de su diseño. Verifique la continuidad de mensajes en sus diagramas de secuencia

(allanan "saltos de la lógica" en el diseño).

A continuación los 10 consejos para una buena RDC. Los describimos con más detalle en el Capítulo 9.

10. Asegúrese que el diagrama de secuencia coincida con el caso de uso.9. Asegúrese (sí, de nuevo) que cada diagrama de secuencia explique

ambos cursos de acción, el básico y el alterno.8. Asegúrese que las operaciones han sido asignadas a las clases

apropiadas.7. Revise las clases en sus diagramas de clases para asegurar que tienen el

conjunto apropiado de operaciones y atributos.6. Si su diseño refleja el uso de patrones u otro tipo de modelo de

construcción, verifique que estos detalles son reflejados en los diagramas de secuencia.

5. Trace sus requisitos funcionales (y no funcionales) a sus casos de uso y clases para asegurar que ha cubierto todo.

4. Asegúrese de que sus programadores "verifiquen la sensatez" del diseño y que estén seguros de poder construirlo y de trabajar con toda la intención.

3. Asegúrese que todos sus atributos fueron escritos correctamente, y que retornan valores y que los parámetros de sus operaciones son correctas.

2. Genere las cabeceras para sus clases, e inspecciónelas cuidadosamente. 1. Revise su plan de prueba para su lanzamiento.

Si hizo el diseño detallado para cada caso de uso y ejecutó un RDC (como se describe en el Capítulo 9), entonces su diseño debe ir ajustándose, y listo para codificar.

Implementación

La Figura 1-4 muestra los pasos involucrados en el Código y Pruebas (es decir, la Implementación).

Una vez que se ha hecho el esfuerzo de llevar un modelo desde los casos de uso a través del Diseño Detallado, puede pensar en desatender el modelo e iniciar con un código totalmente independiente del modelo que se ha producido.

Similarmente, su modelado debe proporcionar una base para saber con exactitud que funciones del software necesitan ser probadas, así que puede

22

manejar las pruebas unitarias del modelo en una manera similar para generar código de los diagramas de clases detallados.

23

Etapa 3: Revisión del Diseño Crítico

24

Generar las clases de dominio

Generar las clases de dominio

Código y PruebasCódigo y Pruebas

Implementar las pruebas

unitarias

Implementar las pruebas

unitarias

Escribir el código fuente

Escribir el código fuente

Corra las pruebasCorra las pruebas

Terminar el sistema y las pruebas de aceptación de

usuario

Terminar el sistema y las pruebas de aceptación de

usuario

Revisión del código y

actualización del modelo

Revisión del código y

actualización del modelo

Para cada Controlador en su diagrama de robustez…

Figura 1-4. Implementación

Generar las pruebas unitarias de los controladores en los diagramas de robustez.

Adicionalmente puede generar cualquier código obtenido de su IDE o generador de código.

No

Si

Se aprobaron las pruebas?

Sincronizar el diseño con el código para prepararse para la siguiente fase o iteración.

Etapa 4. Entrega

La tecnología disponible en las herramientas de modelado actuales (al menos las que nosotros usamos) también proporcionan un enlace fácil y conveniente entre el modelo UML y el entorno de codificación. Hemos extendido el proceso ICONIX para manipular con eficiencia esta nueva tecnología.

Los pasos mostrados en la figura 1-4 son cubiertos en los capítulos 10, 11, y 12.

Implementación (Codificación)

A continuación mostramos nuestros 10 primeros consejos para realizar la Implementación. Los describimos con mayor detalle en el Capítulo 10.

10. Asegúrese de conducir el código directamente desde el diseño.9. Si al codificar se revela que el diseño de alguna forma está errado,

modifíquelo. Pero también repase el proceso. 8. Haga inspecciones regulares al código. 7. Cuestione siempre las elecciones del framework de diseño. 6. No deje que los problemas del framework asuman el control de los

asuntos del negocio. 5. Si el código empieza a salirse de control, frénelo y vuelva a revisar el

diseño. 4. Mantenga el diseño y el código sincronizados. 3. Enfóquese en las pruebas unitarias mientras pone en práctica el código. 2. No sobrecomente su código (hace de su código menos mantenible y más

difícil de leer). 1. Recuerde poner en práctica los cursos alternos así como los cursos básicos.

Las pruebas unitarias son un importante (e íntegra) parte de la Implementación.

Pruebas Unitarias

Mientras codifique, debe escribir también pruebas unitarias que estén atadas a los casos de uso. Estas pruebas le permiten probar, de una manera automática y repetible que el comportamiento del sistema (descrito en cada caso de uso) ha sido implementado correctamente. Esencialmente, está probando todas las funciones del software que se identificaron durante el análisis de robustez.

Describimos a continuación los 10 mejores consejos para hacer las Pruebas Unitarias, que explicamos con más detalle en el Capítulo 12.

10. Adopte un " conjunto de pruebas pensado " donde cada bug encontrado es una victoria y no una derrota. Si encuentra (y arregla) el bug en las pruebas, los usuarios no lo encontrarán en el producto final.

9. Comprenda los diferentes tipos de pruebas, y cuando y porque usted debe usarlos.

8. Cuando hacer unidades de prueba, crea una o más pruebas unitarias para cada controlador en cada diagrama de robustez.

25

7. Para sistemas en tiempo real, use los elementos en los diagramas de estado como la base para las pruebas por casos.

6. Haga una verificación a nivel de requisitos (es decir: verifique que cada requisito que haya identificado sea explicable).

5. Use una matriz de trazabilidad como ayuda en la verificación de requisitos.

4. Haga pruebas de aceptación a nivel de escenario para cada caso de uso. 3. Expanda hilos en sus pruebas de escenario para cubrir un camino

completo a través de la parte apropiada del curso básico más cada curso alterno en sus pruebas de escenario.

2. Use marcos de pruebas como JUnit para almacenar y organizar sus pruebas unitarias.

1. Mantenga sus pruebas unitarias bien refinadas.

Como discutimos en el capítulo 12, otros tipos de pruebas ejecutadas en diferentes artefactos del proyecto y diferentes escenarios en el proyecto-en particular, Integración/Pruebas de Escenario.

Expanda hilos para la Integración y las Pruebas de escenario

Esta actividad supone expandir los hilos de día soleado/día lluvioso de los casos de uso. Las pruebas de integración vienen de los casos de uso, para probar siguiente:

1. Todo el escenario del día soleado (el curso básico).2. Parte del escenario del día soleado más cada escenario del día lluvioso

individual (los cursos alternos).

Por ejemplo, un caso de uso con tres cursos alternos necesitará (como mínimo) cuatro pruebas de integración/escenario: uno para el curso básico y uno para cada curso alterno (incluyendo cualquier parte del curso básico).

Con el código y las pruebas escritas para un caso de uso en particular (y con las pruebas pasando!), es importante ejecutar una Revisión del Código y una Actualización del Modelo.

Revisión del Código y Actualización del Modelo

El propósito principal de la etapa de la Revisión del Código y la Actualización del Modelo es sincronizar el Código y el Modelo antes de que la próxima iteración inicie. Este esfuerzo mantiene el diseño justo impidiendo la entropía, o código rot, mientras más y más funcionalidades son sumadas a un sistema complejo. Una vez que se ha concluido esta etapa, el diseño y el código deben estar en buen estado, listos para empezar con el próximo caso de uso (o lote de casos de uso).

A continuación mostramos los 10 consejos para la Revisión del Código y la Actualización del Modelo. Los describimos con más el detalle en el Capítulo 11.

10. Prepárese para la revisión, y asegúrese de que todos los participantes han leído el material de revisión pertinente antes de la reunión.

26

9. Cree una lista de ítems de alto nivel para repasar, basada en casos de uso.

8. Si es necesario, rompa cada ítem de la lista en uno más pequeño. 7. Revise el código en varios niveles diferentes. 6. Reúna datos durante la revisión, y úselo para acumular listas de

verificación para revisiones futuras.5. Siga la revisión con una lista de puntos de acción y envíela por correo

electrónico a todas las personas involucradas en el proyecto.4. Enfóquese en la detección de errores durante la revisión, no en la

corrección.3. Use un explorador integrado de código/modelo que vincule su

herramienta modeladora a su editor de código.2. Mantenga " la formalidad suficiente " con checklists y haga seguimiento

a las listas de acción, pero no se exceda con burocracia.1. Recuerde que es también una sesión de Actualización del Modelo, no

sólo una Revisión del Código.

Esto encierra nuestra visión general del proceso ICONIX. Pareciera que hay mucha información por absorber, pero el proceso en sí, es muy directo una vez que se entiende el porqué de cada paso.

Extensiones para el Proceso ICONIXAunque ha sido usado en cientos de proyectos de TI, ICONIX se ha mantenido similar los últimos 10 o 15 años. En nuestro libro Desarrollo ágil con ICONIX (Apress, 2005), publicamos ciertas extensiones para el proceso. Estas extensiones incluyen:

Realizar el Análisis del Personaje. Complementar el proceso con TDD. Conducir casos de prueba desde el modelo de análisis

Análisis del PersonajeEl Análisis de Personaje como una interacción técnica del diseño hace a los actores y casos de uso más concretos y tangibles para los stakeholders del proyecto. Mucha gente encuentra a los actores y casos de uso demasiado abstractos, así que éste enfoque es quien lo aborda.Un personaje es una descripción de una persona ficticia: un prototipo del usuario objetivo. La persona da un nombre y una descripción breve de su trabajo, metas y aspiraciones, el nivel de habilidad-cualquier cosa que pueda ser pertinente para entender cómo esa persona usa y percibe el producto que se está diseñando. Escriba después los escenarios de interacción (una forma de caso de uso que describe en más detalle las motivaciones del usuario detrás de su interacción con el sistema), basado en el personaje que ha definido. Usando ICONIX, escribirá algunos escenarios de interacción detallados para asegurarse que el sistema se enfoca correctamente en el usuario objetivo, y procederá a escribir en lo más mínimo los casos de uso, para el sistema en conjunto, al estilo ICONIX.

Desarrollo guiado por pruebas (TDD)

27

TDD es un método cada vez más popular para diseñar software escribiendo pruebas unitarias. El diseño efectivamente " evoluciona " a medida que escribe el código. Los equipos han notado que TDD por sí solo puede ser un proceso de diseño escaso (por decirlo menos) y sería muy beneficiado por algún modelado de diseño up-front. ICONIX es un primer candidato para esto, porque su técnica de Análisis de Robustez funciona bien en talleres de diseño con equipos modelando en un pizarrín (o en una herramienta CASE conectada a un proyector).

Manejar casos de pruebas desde el modelo de análisisTiene sentido vincular su Modelo a las pruebas tan estrechamente como sea posible, y de hecho llevar las pruebas a sus casos de uso conducidos por el modelo. Esta extensión de ICONIX lleva la identificación de los casos de prueba directamente del diagrama de robustez, en una manera paralela al modo en el que manejamos la creación de un esqueleto del diagrama de secuencia desde un diagrama de robustez. Es decir, los nombres (objetos entidad e Interfaz) del diagrama de robustez se convierten en instancias de objetos en el diagrama de secuencia, y los verbos (objeto Control) consiguen los casos de prueba creadas para sí. Discutimos este proceso a fondo en el capítulo 12.

ICONIX en la práctica:Ejemplo la Librería de Internet.Iniciando en el capítulo próximo, iremos siguiendo un ejemplo, que llamamos la Librería de Internet, esbozamos cada fase del proceso para usted.

Cuando lleguemos a la fase de los diagramas de secuencia (diseño detallado) en el Capítulo 8, empezaremos a poner en práctica la Librería de Internet usando el Framework Spring, un popular Framework de Java. Este libro no se trata de Spring, así que no ahondaremos en los detalles técnicos de Spring (aunque sugerimos recursos adicionales, impresos y en línea). En su lugar nos enfocaremos en las vías en las que el proceso ICONIX es usado para crear código fuente bien diseñado para una aplicación Web real.

Las técnicas que describimos en este libro deben ser aún más oportunas para usuarios de otros Framework y otros lenguajes de programación OO.

Los casos de uso en los que trabajamos y las clases que descubriremos existen para satisfacer ciertos requisitos que nuestro cliente (el dueño ficticio de la librería que estamos construyendo) ha especificado. Cubriremos estos requisitos en el Capítulo 2, donde mostramos como derivar nuestra versión de primer paso del Modelo de Dominio de los requisitos.

Resumen

En este capítulo introducimos el proceso ICONIX y describimos su información básica y principios. También describimos las características clave y vamos a través del proceso, desde los casos de uso hasta el código.

En el próximo capítulo, describimos en detalle la primera fase del proceso ICONIX: Modelado de Dominio.

28

29

P A R T E 1

Definición de Requisitos

C A P I T U L O 2

Modelo de Dominio

Imagine si todos en su equipo hablaran idiomas diferentes. Digamos que usted habla alemán, su compañero de equipo habla francés, y alguna otra persona está hablando a Swahili. Cada vez que alguien hable, las personas harán esfuerzos sobrehumanos para entender lo que puedan, y cuando se les pregunte, inclinarán la cabeza como si ente entendiesen perfectamente. Se irán entonces con una interpretación completamente mala de lo que realmente se trató de decir.

En todos los proyectos de TI, el problema de incomunicación es imperioso, pero es raramente notado porque todos piensan estar hablando el mismo idioma, y no es así. Una persona dice "reseña de libro", algunas personas interpreta esto como el significado le "revisión editorial" (una revisión escrita por un equipo editorial), mientras que otros podrían interpretarlo como el significado de "revisión del cliente" (una revisión escrita por un cliente y posteado en el sitio web). Los resultados pueden ser-y a menudo lo son - catastróficos, ya que el sistema es desarrollado con los requisitos y el diseño que resultan de la interpretación de diferente de cada miembro.

El Modelo de Dominio es un artefacto colaborativo vivo. Es refinado y actualizado en cada parte el proyecto, de modo que refleja siempre la comprensión actual del espacio del problema.

30

En este capítulo echamos un vistazo al Modelo de Dominio, que aspira a resolver el problema de incomunicación en el proyecto estableciendo un vocabulario común que planee el espacio del problema.

La vista de 10,000 piesEl modelado del dominio es la tarea de construir un glosario del proyecto, o un diccionario de términos usados en su proyecto. El Modelo de Dominio de un proyecto define el alcance y la base en la que se construirán sus casos de uso. Un Modelo de Dominio también proporciona un vocabulario común para habilitar una comunicación clara entre los miembros de un equipo de proyecto. Así aunque este libro es acerca del desarrollo conducido por casos de uso, tenemos que comenzar a partir del modelado de dominio.

¿Qué es un Modelo de Dominio?Como mencionamos, un Modelo de Dominio es, esencialmente, un glosario de proyecto: un diccionario "vivo" de todos los términos usados en su proyecto. Pero un Modelo de Dominio es mejor que un glosario de proyecto, porque muestra gráficamente cómo todos estos términos diferentes se relacionan entre sí. En la práctica es un diagrama de clases simplificado, con líneas dibujadas entre las diferentes clases (objetos de Dominio) para mostrar cómo se relacionan entre sí. El Modelo de Dominio muestra las relaciones de Generalización y Agregación (relaciones: tiene un y es-un) entre las clases de Dominio.

La Figura 2-1 muestra un extracto de un Modelo de Dominio. No se preocupe de los detalles por ahora-nuestro propósito al presentar esta figura es ni más ni menos que visualizar de lo que estaremos hablando el resto del capítulo.

31

Figura 2-1. Diagrama de un ejemplo de Modelo de Dominio

¿Por qué iniciar con el Modelo de Dominio en lugar de los Casos de Uso?Notará que realmente ayuda si se hace un estudio rápido al Modelo de Dominio justo al iniciar un proyecto. Cuando escribe casos de uso, está tentando a hacerlos de alto nivel, vagos y ambiguos. En realidad, algunos gurus recomiendan que escriba sus casos de uso de esta manera (sólo ellos lo llaman " abstracto, "fundamental, " libre de la tecnología, " etc.)-pero más de esto más tarde.Nuestro consejo es bastante opuesto: el texto del caso de uso debe ser fundado en la realidad, y debe ser muy ligado al sistema que se está diseñando. En otros términos, los casos de uso deben escribirse en el contexto del Modelo de Objetos (es decir, el texto del caso de uso necesita referenciar a los objetos de dominio por nombre). Haciendo esto, será capaz de anudar la parte estática y dinámica del modelo, que son cruciales si quiere que el esfuerzo del análisis y diseño sea orientado hacia adelante por sus casos de uso.

Así antes de escribir sus casos de uso, necesita hacer un intento de un primer paso en un Modelo de Dominio. El modelo de dominio es la base de la parte estática de su modelo, mientras que los casos de uso son la base de la parte dinámica. La parte estática describe la estructura; la parte dinámica describe el comportamiento.

■NOTA Todo el nivel de análisis, los términos "objeto" y "clase" son a veces usados de modo intercambiable (un objeto es una instancia en tiempo de

32

ejecución de una clase). Sin embargo, cuando lleguemos a un mayor nivel de diseño, la distinción entre objetos y clases se vuelve más importante.

Modelado de Dominio en teoría

A medida que lea este libro, verá que cada capítulo sigue un patrón familiar. Iniciamos describiendo un aspecto del modelado " en teoría, " usando nuestro ejemplo de la Librería de Internet para ilustrar los puntos que desarrollemos. Luego lo cubrimos " en la práctica, " mostrando errores de modelado típicos y cómo corregirlos, y presentamos algunos ejercicios. Finalmente, terminamos cada capítulo con " más práctica."

10 Consejos para el Modelo de DominioLos principios discutidos en este capítulo pueden ser sumados a ésta guía.

10. Enfóquese en los objetos del mundo real (Dominio del problema).9. Use las relaciones de generalización (es-un) y agregación (tiene-un) para

mostrar cómo los objetos se relacionan entre sí. 8. Limite sus esfuerzos para el modelado de dominio inicial a un par de horas. 7. Organice sus clases alrededor de abstracciones claves en el dominio del

problema. 6. No confundir el Modelo de Dominio con un Modelo de Datos. 5. No confunda un objeto (que represente una instancia en particular) con

una tabla de la base de datos (que contiene una colección de cosas). 4. Use el Modelo de Dominio como un glosario del proyecto. 3. Haga su Modelo de Dominio inicial antes de escribir sus casos de uso,

para evitar ambigüedad de nombres.2. No espere que su diagrama de clases final coincida con su Modelo de

Dominio, pero recuerde que debe existir cierto parecido entre ellos.1. No ponga pantallas y otras clases específicas del GUI en su Modelo de

Dominio.

Echemos un vistazo a cada uno de estos con más detalle.

10. Enfóquese en los objetos del mundo real.Al crear un Modelo de Dominio, debemos enfocarnos en objetos del mundo real dentro del Dominio del problema. Trate de organizar su arquitectura de software de acuerdo a como se ve el mundo real. El mundo real tiende a cambiar menos frecuentemente que los requisitos del software.

33

NOTACIÓN DE CLASE

La Figura 2-2 muestra dos tipos diferentes de notación para una clase. En un diagrama de clase detallado y completo se tiene que usar la notación de la izquierda, con atributos y operaciones. Sin embargo, durante el Modelado inicial, es temprano asignar estas regiones a la clase. Es mejor usar la notación más simple mostrada a la derecha. Esta versión sólo muestra el nombre de la clase de dominio.

Figura 2-2. Notaciones de clases.

9. Use las relaciones de generalización (es-un) y agregación (tiene-un)Con el transcurso del tiempo, fortalecerá su Modelo de Dominio con nuevas clases de dominio, a medida que las identifique. Notará también las relaciones (o asociaciones) entre ellos-por ejemplo, una Reseña de libro pertenece a un Libro, y una Orden de Compra y una Tarjeta de Crédito son ambas de un tipo que es Tipo de Pago. La primera relación (Reseña pertenece a un Libro) es llamada Agregación (tiene un, porque un Libro tiene una Reseña). La segunda relación (Orden de Compra y Tarjeta de crédito son ambas Tipos de Pago) es llamada generalización (es-un, porque una Orden de compra es un Tipo de Pago). La Figura 2-3 muestra una ilustración de estos conceptos.

34

Figura 2-3. Relaciones de agregación y generalización.Éstas y las asociaciones regulares son las relaciones más importantes en

su Modelo de Dominio. El 95% de las relaciones de su Modelo de clase pueden ser modelados usando relaciones de agregación y generalización.

■ SUGERENCIA Mientras sea posible, ponga sus asociaciones de modo que se lean de izquierda a derecha, como cualquier texto. Esto mejorará la lectura de sus diagramas.

8. Limite sus esfuerzos para el modelado de dominio inicial a un par de horasRecomendamos que establezca un presupuesto de tiempo para construir su Modelo de Dominio inicial. Un par de horas es todo lo que debe necesitar. No lo hará perfecto de cualquier modo, así que hágalo rápidamente y espere arreglarlo a medida que proceda. Debe vigilar el hacer ajustes necesarios a su Modelo de Clases del nivel de análisis en respuesta a los descubrimientos hechos durante el análisis de robustez y a lo largo del proyecto.

Descubrirá objetos desaparecidos mientras trabaja en los casos de uso y los diagramas de robustez. El proceso guiado por casos de uso asume que el Modelo de Dominio es incompleto y proporciona un mecanismo para descubrir lo que falta.

El Modelado de Dominio inicial será probablemente las dos horas más importantes que puede gastar en el proyecto!. Es probable que descubra el 80% de sus clases de dominio durante estas dos horas de lluvia de ideas. Si puede conseguir 80% de su vocabulario de dominio sin ambigüedad, entonces serán dos horas bien gastados.

7. Organice sus clases alrededor de abstracciones claves en el dominio del problema.Generalmente es una buena práctica organizar sus clases alrededor de abstracciones claves en el dominio del problema. Recuerde que el Modelo de Dominio es un primer corte del diagrama de clases que se convertirá en la base de la arquitectura de su software. Esto hace al modelo más resistente al cambio. Organizar la arquitectura alrededor de abstracciones del mundo real hace al modelo más resistente cuando los requisitos cambian, ya que los requisitos usualmente cambian más frecuentemente que el mundo real.

6. No confundir el Modelo de Dominio con un Modelo de Datos.Aunque los diagramas pueden parecer similares, recuerde que lo que es una buena práctica en un Modelo de datos no necesariamente es una buena práctica en un diagrama de clases (y viceversa). Las clases son pequeñas y las tablas son grandes. Una tabla en una base de datos relacional a menudo relaciona un número de cosas. Las clases son mejor diseñadas si están en paquetes relativamente pequeños de datos y comportamiento.

En un diagrama de clases, es probable que tenga una clase que maneje una tabla de una base de datos, y deba mostrar cierta clase TableManager. El propósito de las clases tipo TableManager es ocultar los detalles del Sistema de Manejo de Bases de Datos (DBMS) del resto de código base.

35

5. No confunda un objeto con una tabla de la base de datos.Un objeto representa una instancia particular de algo. Una tabla de base de datos representa una colección de cosas. No tiene que ser tan literal como en el mundo Enterprise JavaBeans (EJB), donde una entidad bean representa generalmente una fila sencilla en una tabla. Las clases de dominio son similares, sin embargo. Si llama Libro a una clase de dominio, entonces no se refiere a una tabla Libro – se refiere a un libro sencillo.

Las columnas en una tabla generalmente corresponden a los atributos de una clase. Sin embargo, las tablas de una base de datos contienen muchas más columnas que atributos las clases (las tablas a menudo tienen llaves foráneas), así no puede existir un mapeo directo de 1:1 entre filas de tablas y objetos.

4. Use el Modelo de Dominio como un glosario del proyecto.Si los requisitos ambiguos son el enemigo, el Modelo de Dominio es la primera línea de defensa. El uso ambiguo de nombres por los "expertos de la materia" es muy común y muy dañino. El modelo de dominio debe servir como un glosario del proyecto que ayude a asegurar el uso consistente de términos al describir el espacio del problema.

Usar el Modelo de Dominio como un glosario del proyecto es el primer paso hacia la desambiguación de su modelo. En cada taller en el que Doug ha enseñado, encontró al menos dos o tres clases de dominio donde los estudiantes usan nombres ambiguos (por ejemplo, "el carro de compras, "cesta de compras," o " trenecito de compras ").

3. Haga su Modelo de Dominio inicial antes de escribir los casos de usoDesde que usó el Modelo de Dominio para desambiguar las abstracciones del dominio del problema, sería tonto haber escrito sus casos de uso usando términos ambiguos para describir clases de dominio. Así que gaste esas dos horas de trabajo en el modelo de dominio antes de escribir sus casos de uso. Escribir los casos de uso sin un modelo de dominio para atar todo acumula gran cantidad de problemas para más tarde.

2. No espere que su diagrama de clases final coincida con su Modelo de DominioLos diagramas de clase se harán mucho más detallados que el Modelo de Dominio mientras el diseño progrese; el modelo de dominio es bastante simple. A medida que diseñe (usando diagramas de secuencia), el diseño detallado se construye como ayudas del GUI, clases de fábrica, y clases de infraestructura que son añadidas al diagrama de clases, y el diagrama del modelo de dominio puede desde luego ser dividido en varios diagramas detallados de clase. Sin embargo, todavía debe ser posible trazar la mayor parte de clases con su equivalente clase de dominio.

1. No ponga pantallas y otras clases específicas del GUI en su Modelo de Dominio.Como si a la caja de Pandora y deje un modelo de dominio atestado de gran cantidad de detalles específicos de la Implementación. Haga una optimización

36

de clases, clases de ayuda, y así se mantendrán fuera del modelo de dominio. El modelo de dominio debe enfocarse meramente en el dominio del problema.

Librería de Internet: Extraer el primer Modelo de Dominio de los requisitos de alto nivel

Cuando está creando su Modelo de Dominio, una buena fuente de las clases de dominio incluye los requisitos de alto nivel -los que normalmente son (aunque no siempre) escritos en la forma " el sistema debe hacer esto; el sistema no debe hacer eso." es útil explorar estos requisitos, extrayendo los nombres y frases de nombre. Puede entonces refinarlos para crear el modelo de dominio inicial.Con eso en mente, examinemos cuidadosamente los requisitos de alto nivel para la Librería de Internet y extraiga algunas clases de dominio de ellos.

1. La librería estará basada inicialmente en la web, pero debe tener una arquitectura suficientemente flexible que de otras alternativas para su desarrollo (Swing/applets, servicios Web, etc.).2. La librería debe ser capaz de vender libros, con órdenes aceptadas desde la Internet.3. El usuario debe ser capaz de añadir libros en un carrito de compras en línea, previa verificación.

a. Similarmente, el usuario debe ser capaz de quitar ítems del carrito de compras.4. El usuario debe ser capaz de mantener listas de interés de libros que él o ella desee comprar en adelante.5. El usuario debe ser capaz de cancelar órdenes antes que se hayan embarcado.6. El usuario debe ser capaz de pagar con tarjeta de crédito u orden de compra.7. Debe ser posible para el usuario la devolución de libros.8. La librería debe ser vista en sitios Web de los asociados usando mini catálogos, que son derivados de un catalogo maestro almacenado en una base de datos central.

a. Los mini catálogos deben ser definidos en XML, ya que se transferirán entre éste y (en adelante será definido) otros sistemas externos.b. El sistema de realización de envíos se llevará a cabo vía los servicios Web de Amazon.

9. El usuario debe ser capaz de crear una cuenta de cliente, de modo que el sistema recuerde los detalles del usuario (nombre, dirección, detalles de su tarjeta de crédito) cuando se loguee al sistema.

a. El sistema mantendrá una lista de cuentas en su base de datos central.

b. Cuando un usuario se loguea, su contraseña debe concordar siempre con la contraseñas en la lista de cuenta maestra.

10. El usuario debe ser capaz de buscar libros por varios métodos de búsqueda -título, autor, palabra clave, o categoría -y luego revisar el detalle del libro.11. Debe ser posible para el usuario postear críticas de sus libros favoritos; los comentarios de revisión deben aparecer en la pantalla de detalles del libro.

37

La crítica debe incluir una clasificación del cliente (1-5), que se muestra conjuntamente con el título de libro en las listas de libro.

38

a. Las reseñas deben ser moderadas-es decir, comprobadas y "Aprobadas" por un miembro del personal antes de que se publique en el sitio Web.b. Las revisiones más largas deben ser truncadas en la pantalla de detalles del libro; el cliente puede hacer clic para ver la revisión completa en una página independiente.

12. Debe ser posible para el personal publicar revisiones editoriales de libros. Éstos deben aparecer también en la pantalla de detalles del libro.13. La librería permitirá terceros vendedores (por ejemplo, librerías de segunda mano) añadir sus propios catálogos de libro. Éstos son añadidos en el catálogo maestro para que los vendedores sean incluidos en los resultados de la búsqueda.14. La librería debe ser escalable, con los siguientes requisitos específicos:

a. La librería debe ser capaz de mantener cuentas de usuario para mas de 100 000 clientes en sus primeros seis meses, y luego 1 000 000 cuentas más.b. La librería debe ser capaz de servir hasta 1 000 usuarios simultáneos (y después de seis meses a 10 000).c. La librería debe ser capaz de acomodar hasta 100 solicitudes de búsqueda por minuto (1 000/minuto después de seis meses).d. La librería debe ser capaz de acomodar hasta 100 compras por hora(1 000/hora después de seis meses).

Estas necesidades son una fuente rica de clases de campo. Permítanos poner todo el realzado nombres y frases de nombre en una lista ( en el proceso, volveremos todos los plurales en singulares, y pon les exhausto orden alfabética ):

Socio asociadoAutorLibroCatálogo de libroDetalles de libroLista de libroReseña de libros recién publicadosLibreríaCategoríaComprobaciónTarjeta de créditoClienteCuenta de cliente

Clasificación de clienteBase de datosRevisión editorialInternetArtículoPalabra claveLa lista de cuentaLista de cuenta maestraCatálogo de libro maestroCatálogo maestroCatálogo miniOrden

ContraseñaOrden de compraComentario de revisiónMétodo de búsquedaResultados de la búsquedaVendedorRealización de envíoSistemaCarro de comprasTítuloCuenta de usuarioLista de deseo

39

Hay un poco de duplicación en esta lista; términos similares se utilizan básicamente para la misma cosa. Pero eso es realmente el principal beneficio del enfoque de modelado de dominio: llegar a identificar y eliminar la duplicación de estos términos al iniciar el proyecto.

■ EJERCICIO Desambiguación con inspección gramatical: Nos dirigimos a través de la lista, para examinar la forma y eliminar los términos duplicados. En primer lugar, trataremos de identificar 6 pares duplicados. (Tenga cuidado: un par parece ser duplicado, pero realmente no lo es.)

Algunos de los temas en la lista son simplemente innecesarios porque quedan fuera del ámbito del modelo de dominio, o son acciones engañosamente disfrazadas de nombres.

Vamos a través de la lista y ahora afinémosla un poco:

• ¡Te parece que los términos "Cliente" y "Cuenta de cliente" son duplicados, pero de hecho representan sutilmente diferentes cosas: "Cuenta de Cliente" es una entidad almacenada en la base de datos, mientras que "Cliente" es un actor (véase el siguiente punto en esta lista). • "El Cliente" y el "Vendedor" son actores, por tanto, deben ser puestos en diagramas de casos de uso. (Véase el capítulo 3.) • Los términos "Cuenta de Usuario" y "Cuenta de Cliente" son duplicados. La elección de cual se mantiene es arbitraria. Así que nos quedaremos con "Cuenta de cliente." • Los términos "Lista de Cuentas" y "Lista Maestra de Cuentas" son duplicados, por lo que uno debe eliminarse. También tenemos un "Catálogo Maestro de libros" lo coherente sería mantener el término "Lista Maestra de Cuentas".• Los términos "Reseña" y "Comentario" son duplicados, por lo que mantendremos "Reseña".• Tenemos varios términos diferentes para un catálogo o lista de libros: "Catálogo de libros", "Lista de libros", "Mini-Catalogo" y "Catálogo Maestro." Los Catálogos y listas son probablemente conceptos diferentes. De hecho, parece que los requisitos están tratando de decirnos algo, que puede estar implícito en el texto. En caso de duda, hable con el cliente. Haga preguntas hasta que obtenga una clara e inequívoca respuesta."Catálogo de libros" y " Catalogo Maestro " son en realidad los duplicados aquí, así que mantendremos "Catalogo Maestro" ya que proporciona un buen contraste con el "Mini-Catálogo". "Lista de libros", es probablemente un término general para los diferentes tipos de listas, lo mantendremos por ahora y veremos cómo encaja cuando dibujemos el diagrama de modelo de dominio. • Hay otro duplicado en ésta área: "Catalogo Maestro" y " Catálogo Maestro de libros." Vamos a suprimir las palabras " Catalogo Maestro" ya que "Catálogo Maestro de libros" es el término más descriptivo.• La palabra "Internet" es muy genérica y no añade nada en este punto.• La palabra "Contraseña" es demasiado pequeña para ser un objeto y mostrar como un elemento de la interfaz de usuario, por lo que deberíamos sacarlo del modelo de dominio. Si empezamos a incluir todos los elementos de la interfaz de usuario en el modelo de dominio, estamos abriendo una lata de gusanos y podríamos estar aquí toda la noche arrinconados en una esquina, luchando contra ellos lejos.

40

• Igual ocurre con "Título" y "Palabra clave".• Otro duplicado es "Libro" y "Detalle de Libro" Sólo mantendremos "Libro", ya que es más conciso que " Detalle de Libro ", sin perder significado.• La palabra "artículo" es vaga y difusa, pero sí representa un concepto válido: un artículo que se ha añadido al carrito de compras del usuario. Así que le cambiaremos de nombre a "Línea de Articulo" y lo mantendremos en la lista.• La palabra "Librería" es demasiado amplia y es poco probable que sea a lo que se refiere explícitamente, por lo que nos desharemos de ella.

Lo que sigue es la lista actualizada de candidatos a clases de dominio. La Figura 2-4 muestra las clases establecidos en el diagrama clases.

AsociadoAutorLibroLista de librosReseñaCategoría Verificación Tarjeta de Crédito Cuenta de Cliente Valoración del cliente

Base de datos Reseña de Editorial Línea de Artículo Lista Maestra de CuentasCatálogo Maestro de librosMini-Catalogo Orden Orden de Compra.

Método de búsqueda Resultados de búsqueda Sistema de Cumplimiento de EnvíosCarrito de ComprasLista de Interés

Como mencionamos anteriormente, aunque las técnicas de inspección gramaticales son útiles para tener un inicio rápido, no debe pasar semanas o incluso días para realizar esto. (Como se verá en el capítulo 4, el resto de los objetos de la Librería de Internet se identificarán durante el análisis de robustez.) Un par de horas es la cantidad de tiempo necesario para usar en el modelo de dominio antes de empezar a escribir los casos de uso.

■ PRECAUCIÓN No se atasque en la Inspección Gramatical.

La Figura 2-4 muestra un tipo de relación, agregación (también conocido como tiene un), que describimos anteriormente. Como este es un intento de un primer paso, no todas las relaciones mostradas son correctas.

Una técnica útil es leer en voz alta el diagrama e incluir el término "tiene-un." Por ejemplo, un carrito de compras "tiene una" Línea de Articulo. Pero, ¿”Tiene” una Orden una Verificación? Tal vez no. Tenga en cuenta que algunos de los objetos de dominio actualmente no concuerdan con ninguna otra cosa más (por ejemplo, Asociado, Sistema de Cumplimiento de Envíos, Base de datos, y Método de búsqueda). Las hemos agrupado a la derecha por ahora; durante el análisis de robustez, pueden ser vinculados a otros objetos, deformados en algo diferente, o eliminados por completo.

41

Figura 2-4. Primer paso del Modelo de Dominio para el Proyecto de la Librería de Internet.

Hay todavía algunos trabajos que hay que hacer en este Modelo de Dominio antes de que esté listo para pasar a la siguiente fase, por lo que vamos a hacer un poco de reorganización del trabajo a continuación.

42

Esperemos que esto ayude a ilustrar un elemento importante del enfoque ICONIX: mejoramiento continuo a través de la iteración y el refinamiento.

Librería de Internet: Segundo intento de Modelo de Dominio

Al elaborar el diagrama del modelo de dominio, hay una lluvia de ideas como un equipo. A menudo el equipo identificará objetos de dominio que no estaban en los requisitos, pero en su lugar han ahondado en la comprensión particular de alguien sobre el dominio del problema. Para ilustrar esto, digamos que hemos descubierto otros dos objetos de dominio: Historial de Orden y Orden de Despacho. Estas no se mencionan explícitamente en los requisitos, pero todavía podrían clasificar como requisitos mínimos para una librería de Internet.

El diagrama actualizado se muestra en la Figura 2-5, con las nuevas clases de dominio mostradas en rojo.

En la Figura 2-5, hemos explorado el concepto de cumplimiento de orden “pedidos” y despacho. Sistema de Cumplimiento de Envíos permanece en el diagrama, pero tendremos que decidir si está en el ámbito del modelo actual o es un sistema externo con el que tenemos que interactuar. Los Sistemas externos son siempre modelados como actores.

También hemos eliminado la Verificación, éste era en realidad un verbo sustantivo. Y hemos eliminado Autor, ya que este es solamente un campo en el libro (es decir, es demasiado pequeño para ser un objeto de clase primaria en el Modelo de Dominio5). Autores. . . quien los necesita?.

Hay cierta ambigüedad en torno a Catálogo Maestro de libros que intentamos resolver. Hemos eliminado el vínculo entre libro y del Catálogo Maestro de libros, y en su lugar añadimos una clase llamada Catálogo de libros y la enlazamos a la clase Libro. Por lo tanto, acabar con una maraña de relaciones: efectivamente estamos diciendo que un Libro pertenece a un Catálogo de libros, y un Catálogo de libros pertenece a un Catálogo Maestro de libros (es decir, un Catálogo Maestro de libros es en realidad un catálogo de catálogos). Idealmente, un Mini-Catálogo también debe pertenecer al Catálogo Maestro de libros. Éste enredo es cada vez más complicado. Lo que realmente necesitamos es una manera simple de decir que un Libro puede pertenecen a un Catálogo de libros, y puede haber diversos tipos de Catálogo de libros. Por suerte, una luz rociada de generalización puede hacer maravillas en una maraña de relaciones de este, como verás en la siguiente sección.

5 Recuerde que no estamos creando un modelo de datos aquí. Si esto fuese un diseño de una base de datos, es casi seguro que crearíamos una tabla para el Autor.

43

Figura 2-5. Segunda instantánea de la evolución del modelo de dominio del Proyecto de la Librería de Internet.Librería de Internet: Construyendo relaciones de generalización

44

Una generalización es una relación en la que una clase es una "especie de" alguna otra clase - por ejemplo, un Gato es una especie de Animal. Esta es la razón por la que la generalización a menudo se denomina relación es-a.Un Gato es más específico que un Animal (un Gato es un "refinamiento" de la clase general Animal), de ahí el término "generalización". La clase más específica se llama subclase, y la más general superclase. Crear de subclases de clases más general se conoce como subtyping.

Dentro de Librería de Internet, Catálogo de libros es un buen candidato para subtyping, porque ayudará a "depurar" la relación entre Mini-Catálogo de libros y Catalogo Maestro de Libros. Lista de libros también es un buen candidato para subtyping, si hay diferentes tipos de cuentas hay diferentes tipos de listas de Libros.

A medida que ahondemos en las necesidades del usuario del sistema “Librería de Internet”, identificaremos los diferentes tipos de listas de libros: listas de interés, listas de recomendación, libros relacionados, resultados de búsqueda, etc. Es cada vez más evidente que todas son listas de Libros, por lo que podrían (conceptualmente, al menos) tener una clase padre en común. Hemos descubierto que hay aspectos de las Listas de Interés, Libros relacionados, etc. que son lo suficientemente diferentes como para justificar un tratamiento separado, aunque tienen mucho en común son en realidad tipos de Lista de Libros. La Figura 2-6 muestra la notación para ésta estructura de generalización.

Figura 2-6. Detalle de Listas de libros del Modelo de Dominio de la Librería de Internet.

Las nuevas clases (Libros relacionados, Lista recomendación, Lista de Interés y Resultados de búsqueda) heredan los atributos y operaciones que definimos para la Lista de

libros. Leamos el diagrama en voz alta: Una lista de libros tiene libros. Libros relacionados es una lista de libros. Una Lista Recomendada es una lista de libros. Una Lista de Interés es una lista de libros. Los Resultados de una búsqueda son una lista de libros. Todos las declaraciones reales describen el espacio del problema? Genial, avanecemos.

■ SUGERENCIA Adicionalmente puede añadir atributos y operaciones especiales para cada una de las nuevas clases. Es decir, si se añade una operación a Libros relacionados, sólo estará disponible para Libros Relacionados. Sin embargo, si lo añade a Lista de libros, la nueva operación estará disponible para todas sus subclases.

45

La Figura 2-7 muestra la versión actualizada del Modelo de Dominio de la Librería de Internet, que hace un buen uso de la generalización para aclarar las relaciones entre clases de dominio. Las nuevas clases se muestran en rojo.

Figura 2-7. Tercera instantánea de la evolución del modelo de dominio para el proyecto de la Librería de Internet.También hemos cambiado la definición de Reseña, por lo que ahora es la clase padre para Reseña de Editorial y la nueva clase, Reseña del Lector. Y, por último, hemos

46

Vendedor

desenredado las relaciones Orden en torno a sus tipos de pago (Tarjeta de crédito y Orden de Compra), añadiendo una nueva superclase, Tipo de pago.

■ SUGERENCIA Si es necesario, se puede generalizar a más de un nivel de subclases. Recuerde buscar declaraciones es un que son verdaderas en el mundo real.

Modelo de Dominio en la prácticaLos siguientes ejercicios, tomados del modelo de dominio de la “Librería de Internet” se han diseñado para poner a prueba su capacidad de detectar los errores más comunes que se hacen durante el modelado del dominio. Después de los ejercicios, puede encontrar los diagramas con los errores resaltados, seguido por los diagramas corregidos.

EjerciciosLos diagramas en las figuras 2-8 a 2-11 contienen uno o más errores típicos de modelado. Para cada una de ellos, trate de averiguar los errores y, dibuje el diagrama corregido. Las respuestas están en la siguiente sección.

EJERCICIO 2-1

La Figura 2-8 muestra un diagrama de clases producidas durante el modelado de dominio. La sintaxis UML es correcta, sin embargo, el diagrama no señalar un error relacionado al proceso ¿Por qué es eso? (Sugerencia: El diagrama muestra demasiado detalle.)

Figura 2-8. Diagrama de Clases del Modelo de Dominio inicial.

EJERCICIO 2-2

La Figura 2-9 muestra el diagrama del modelo de dominio con atributos

47

para la clase Orden. ¿Qué problema relacionado a la base de datos sugiere el diagrama?

Figura 2-9. Diagrama de Clases mostrando atributos.

EJERCICIO 2-3

La Figura 2-10 muestra un diagrama del modelo de dominio en el que el equipo de modelado pudo haberse adelanto muy pronto.

Figura 2-10. Diagrama de Modelo de Dominio con detalles agregados tempranamente.

EJERCICIO 2-4

La Figura 2-11 muestra un diagrama de modelo de dominio en el que el equipo de modelado comenzó a pensar en ciertos detalles demasiado pronto. ¿Qué ha ido mal en este diagrama?

48

Figura 2-11. Otro diagrama de Modelo de Dominio con detalles agregados tempranamente.

Solución

A continuación se presentan las soluciones a los ejercicios propuestos.

EJERCICIO 2-1 Solución: MULTIPLICIDAD

La Figura 2-12 resalta los errores en la Figura 2-9. Es muy pronto para pensar en detalles como la multiplicidad en el modelo de dominio. En esta fase inicial, su principal preocupación debe ser la identificación de objetos de dominio y razonar sobre cómo se relacionan entre sí. La Figura 2-13 muestra el diagrama corregido.

Figura 2-11. Error en la Figura 2-9.

49

Asignar multiplicidad muy pronto

Figura 2-13. Versión corregida de la Figura 2-8.

EJERCICIO 2-2 Solución: MAPEAR TABLAS DE LA BD A LAS CLASES DE DOMINIO

La clase de dominio Orden incluye atributos que no parecen pertenecer a la clase Orden (véase la figura 2-14). La causa más probable es que el modelador haya mapeado estas clases de dominio directamente de un esquema de base de datos relacional. La Figura 2-15 muestra el diagrama corregido. Los atributos extras han sido separados en sus propias clases de dominio (Cuenta de cliente y de Despacho). Tenga en cuenta que por lo general no

mostramos los atributos durante el modelado de dominio.

Figura 2-14. Atributos de la clase de dominio Orden influenciados por error desde el esquema de la Base de Datos.

50

No solo atributos de Orden

Figura 2-15. Atributos de dominio de la Figura 2-14, pero en clases más apropiadas.

EJERCICIO 2-3 Solución. OPERACIONES Y CLASES ABSTRACTAS

El diagrama del modelo de dominio que se muestra en la Figura 2-16 tiene un par de problemas. El primero es que Reseña es una clase abstracta. Si bien esto no es especialmente destructivo, y probablemente el mundo no se acabe como resultado directo de esto el modelado de dominio es una etapa algo temprana en el proceso de desarrollo para estar pensando en este tipo de detalles de diseño.

Quedémonos con Reseña, el otro problema es que un par de operaciones se han asignado: verificarTamaño() y aprobarPublicacion(). Identificar y asignar operaciones a las clases es como diseñar algo- de nuevo- es demasiado pronto para estar pensando en este tipo de detalles.

La Figura 2-17 muestra el diagrama corregido.

51

Figura 2-16. Solución de detalle de espacio (diseño) añadidos en el espacio del problema (modelo de dominio).

Figura 2-17. Versión corregida de la Figura 2-16.

EJERCICIO 2-4 Solución: PATRONES PREMATUROS

En la Figura 2-18, se puede ver un indicio de patrones de diseño. El uso de este particular patrón de diseño, la clase Fábrica de Sesión (SessionFactory) creará nuevas instancias de Sesión de Cliente. Una SessionFactory es claramente parte del espacio de solución, no del espacio del problema, como la mayoría de patrones de diseño. Esto suena mucho a diseño y los casos de uso ni siquiera han sido escritos, por lo que una vez más es demasiado pronto para estar pensando en los detalles de la implementación.

Los patrones de diseño emergen durante el análisis de robustez (Diseño Preliminar), pero el modelado de dominio no es la etapa correcta para

52

Demasiado pronto para estar pensando acerca de si la clase es abstracta.

Asignación de operaciones en el espacio del problema

pensar en ellos.

La Figura 2-19 muestra el diagrama corregido.

Figura 2-11. Detalles de diseño añadidos muy pronto en el proyecto.

Figura 2-19. Diagrama del modelo de dominio con los detalles de diseño removidos.

Más Práctica

Esta sección proporciona una lista de preguntas de modelado que puede utilizar para poner a prueba sus conocimientos de modelado de dominio. Las preguntas se harán cada vez más dificiles, pero las respuestas se pueden encontrar leyendo (y pensado!) las técnicas de modelado de dominio descritas en este capítulo.

1. ¿Cuál de las siguientes no es uno de los cuatro tipos de asociación en un modelo de dominio?

a) Tiene un b) Creac) Es und) Conoce de

53

Presencia prematura de patrones

2. Al crear una lista de clases de dominio ¿cómo diría que tiene un atributo?

a) Un atributo tiene cardinalidad en todos los casos.b) Un atributo sólo puede ser contenido en instancias sin comportamiento.c) Un atributo tiene un valor que es típicamente no compuesto.d) Un atributo tiene un valor que se compone de muchos otros valores.

3. ¿Qué técnica(s) puede utilizar para averiguar clases de dominio en un sistema?

a) Análisis de Sustantivo frase.b) Ingeniería inversa.c) Categorías de clases de verbo.d) Extreme Programming.

4. ¿Qué término es usado para describir cuando una clase hija es una extensión de una clase padre?

a) Agregación.b) Herencia.c) Composición.d) Encapsulamiento.

5. Dibuje un modelo de dominio para una tienda de música en línea, primero trata de imaginar cómo funciona en abstracto, sin tener en cuenta cualquier pantalla y luego, después de ver un ejemplo de sitios web como iTunes o Napster. ¿Cuál de los modelos de dominio es mejor? Explica tu respuesta.

6. Suponga que puede utilizar técnicas de ingeniería inversa en el esquema de base de datos de Amazon.com e importarlas en una herramienta de modelado visual. ¿Es éste un buen punto de partida para una modelo de dominio? ¿Qué cambios deben hacerse a un esquema de base de datos en el que se uso ingeniería inversa para que sea éste un buen modelo de dominio?

7. Supongamos que alguien le da la mano con algunos códigos Java de un prototipo GUI de una nueva Librería en Internet y usted utiliza técnicas de ingeniería inversa con UML. ¿Sería este un buen punto de partida para un modelo de dominio? ¿Qué cambios tendría que hacerse al prototipo GUI (en el que se uso ingeniería inversa) para que sea un buen modelo de dominio?

8. Supongamos que usted está trabajando en la etapa 3 del proyecto, y tiene un conjunto detallado de diagramas de clases que muestran la completa implementación de la etapa 2 en la que se uso ingeniería inversa desde cierto código C #. La etapa 3 trata de migrar el sistema a un nuevo framework GUI y otra DMBS. ¿Qué cambios tendrían que hacerse en sus diagramas de clase detallados desde la etapa anterior para que sea un buen modelo de dominio para la etapa actual?

54

Resumen

En este capítulo se describe en detalle la primera etapa del proceso ICONIX. El modelado de Dominio constituye la base de toda la actividad del Modelado de objetos. Como se verá en el próximo capítulo, los casos de uso están escritos en el contexto del modelo de dominio, y (como se verá en el capítulo 5) el análisis de robustez contribuye a reforzar tanto el modelo de dominio y los caso de uso, con lo que cada vez están más unidos.

El diagrama de actividad de la Figura 2-20 muestra cómo el modelo de dominio encaja en el esfuerzo del análisis de requisitos. Las actividades que cubrimos en éste capítulo se muestran en rojo.

55


56








Hacer un prototipo rápido

del nuevo sistema

propuesto


del nuevo sistema

propuesto













uso.


uso.


Figura 2-20. Análisis de Requisitos. Punto de control 1


uso.


uso.

Pantallas

C A P I T U L O 3

Modelando Casos de Uso

Con un primer modelo de dominio inicial en su lugar, es hora de comenzar a escribir los casos de uso. Los casos de uso dan un modo estructurado de capturar los requisitos de comportamiento de un sistema, de modo que puede razonablemente crear un diseño desde ellos. Le ayudan a responder ciertas preguntas fundamentales: ¿Qué están tratando de hacer los usuarios del sistema? ¿Cuál es la experiencia del usuario?. Una cantidad sorprendente de lo que su software debe hacer se dicta por el modo en que los usuarios deben interactuar con el.

La vista de los 10,000 piesLos casos de uso le dan algo a partir del cual se puede diseñar, y desde el cual puede con seguridad estimar el tiempo y el esfuerzo. Mientras que ciertos libros de casos de uso tratan a los casos de uso como un resumen técnico de la especificación de los, este libro le enseña a escribir los casos de uso como el primer paso para obtener un buen diseño orientado a objetos y es un medio para ayudarle a obtener código de alta calidad.

57

■ NOTA Vea nuevamente el diagrama de proceso ubicado al inicio de éste capitulo. Como notará, debe crear su modelo de casos de uso cerca del punto de inicio del proceso de desarrollo, poco después de crear un intento inicial del modelo de dominio.

¿Porque necesito casos de uso además de requisitos funcionales?Los requisitos funcionales tienden a ser una mezcla de requisitos de alto y bajo nivel, técnicamente una corriente del pensamiento de los administradores, clientes, y el equipo de marketing capturado en forma serial y colocado en un documento de Word. No hay nada de malo en esto, es sólo el primer paso en el camino por conseguir un conjunto final de requisitos de comportamiento, claro y sin ambigüedad del que se puede crear una forma realista de diseño.

Por supuesto que las especificaciones funcionales son importantes. Pero diseñar, codificar o la estimar directamente de una especificación funcional es como jugar un fascinante juego de "elegir un número al azar." Se necesita hacer algún trabajo exploratorio para equilibrar el campo de juego. Modelar casos de uso -y hacer un diseño preliminar- lo trae hasta aquí.

■ NOTA Los requisitos funcionales no son la única fuente de casos de uso. Las conversaciones con los clientes y usuarios finales son también una fuente muy importante. Crear historiales y prototipos (maquetas IU, demos funcionales-ese tipo de cosas) son de gran ayuda a la hora de definir los casos de uso.

No olvide los escenarios de “Días Lluviosos”.Cuando está escribiendo sus casos de uso, escríbalos de manera que su esfuerzo este enfocado en capturar las acciones de los usuarios y las respuestas del sistema asociadas a dichas acciones. Como ce, el modelado de casos de uso involucra analizar ambos aspectos, tan el curso básico (el "día soleado" típico de un usuario del sistema; a menudo pensados como el 90% del comportamiento) y los cursos alternos (el otro 90% de la funcionalidad de sistema, consistente en los escenarios del "día lluvioso" del modo en que el usuario interactúa con el sistema; en otros términos, lo que suceda cuando las cosas salen mal, o cuando el usuario prueba cierto característica infrecuente del programa). Si captura todo esto en sus casos de uso, tiene la mayor parte de su sistema.

Haga un Modelo de Dominio Inicial antes de escribir sus casos de uso.El caso de uso es escrito en el contexto del Modelo de Dominio -es decir, todos los términos (nombres y frases) que estuvieron en su modelo de dominio también deben ser usados directamente en sus descripciones de casos de uso.

58

El enfoque de ICONIX asume que el modelo de dominio inicial es incorrecto y proporciona un mejoramiento incremental a medida que se analizan los casos de uso. Ése es el por qué se deben gastar sólo un par de horas en el modelado del dominio antes de empezar el modelado de casos de uso.A medida que escriba sus casos de uso, querrá alimentar información y hacer cambios en el modelo de dominio. Hágalos! Mantenga actualizado el modelo de dominio, corrigiéndolo, y fortaleciéndolo con detalles. Así es cómo evoluciona del primer corte del modelo de dominio en un modelo estático a nivel de diseño detallado.

Durante el diseño preliminar, el modelo de dominio se convierte en un modelo de dominio actualizado, que a su vez (durante el diseño detallado) se convertirá en un modelo de clases (es decir, el modelo estático que define las clases del software). Debe actualizar el modelo de dominio no sólo cuando modela casos de uso, sino también al dibujar los diagramas de robustez y secuencia.

Guíe su diseño (y sus pruebas) desde los casos de usoEn algunos de los siguientes capítulos mostraremos cómo escribir casos de uso directamente ligados a las clases diseñadas. Esto le da la trazabilidad de su código y pruebas unitarias todo de modo que mantiene a sus requisitos de comportamiento.

Notamos en la práctica que si escribe sus casos de uso de la manera que describimos en este capítulo y hace el análisis de robustez (ver el capítulo 5), será bastante sencillo identificar un conjunto de pruebas unitarias que verifiquen sus requisitos de comportamiento. Es decir, escribirá pruebas que comprueben que los casos de uso han sido implementados.

Modelado de Casos de Uso en teoría.En esta sección, describimos la teoría detrás del modelado de casos de uso, intercalándola con ejemplos del proyecto de la Librería de Internet. Su principal preocupación es escribir casos de uso que puedan guiar un diseño de. En términos prácticos, esto significa que existe una relación muy cercana entre sus casos de uso y sus clases. A continuación nuestra lista de las 10 cosas más importantes que debe hacer al escribir los casos de uso.

Top 10: Consejos para el Modelado de Casos de usoLos principios discutidos en este capítulo se pueden resumir como una lista de guías. Éstas a su vez, pueden resumirse en una sola frase sencilla:

DESCRIBIR EL USO DEL SISTEMA EN EL CONTEXTO DEL MODELO DE OBJETOS

Los ítems del 10 al 5 describen el uso del sistema, y los ítems del 4 al 1 se refieren a poner la descripción del uso en el contexto del modelo de objetos.

10. Siga la regla de los dos-párrafos. 9. Organice sus casos de uso con actores y diagramas de caso de uso. 8. Escriba sus casos de uso en voz activa.

59

7. Escriba sus casos de uso utilizando un flujo de evento/respuesta, describiendo ambos lados del dialogo usuario/sistema.

6. Use prototipos GUI y modelos de pantallas. 5. Recuerde que sus casos de uso son realmente una especificación del

comportamiento en tiempo de ejecución. 4. Escriba los casos de uso en el contexto del modelo de objetos. 3. Escriba sus casos de uso utilizando una estructura tipo: sustantivo-

verbo-sustantivo. 2. Haga referencia a las de dominio por nombre. 1. Haga referencia a las clases Interfaz (por ejemplo, pantallas) por

nombre.

Estudiemos cada uno de estos temas con más detalle.

10. Siga la regla de los dos párrafosCada caso de uso debe caber cómodamente en dos párrafos, incluyendo el curso básico y los cursos alternos. Cualquier cosa más allá de los dos párrafos resulta en diagramas de secuencia incomprensibles. Si su caso de uso sobrepasa los dos párrafos, probablemente necesita ser dividido en dos o más casos de uso.

Si alguien le da una plantilla grande de un caso de uso, puede apostar que ésa persona no espera que usted guíe el diseño del software desde esos casos de uso (al menos no muy pronto). Las plantillas grandes de casos de uso lo retrasan! Es también una apuesta segura que la plantilla está llena de información de nombres de caso de uso tales como requisitos funcionales. (Vea la barra lateral titulada "Desenredando requisitos disfunciones del escenario del texto " en el capítulo 13).

■ SUGERENCIA el escritor de casos de uso no debe incluir largas listas de requisitos funcionales en la descripción de su escenario. En su lugar, debe escribir sólo acerca de cómo los usuarios van a utilizar el sistema y lo que el sistema hará en respuesta.

COMO ESCRIBIR UN CASO DE USO: LAS TRES PREGUNTAS MAGICAS

Bueno, todo este capítulo describe cómo escribir un caso de uso. Pero al escribir casos de uso necesita preguntarse continuamente las siguientes tres preguntas fundamentales:6

1. ¿Qué pasa?(Esto le da el comienzo de su " escenario del día soleado ".2. Y luego ¿qué más pasa?(Mantenga esta pregunta hasta que su "escenario del día soleado " se haya completado.)3. ¿Qué más podría pasar?

6 Para obtener más información sobre estas "tres preguntas mágicas", véase la Pág.48 de Use Case Driven Object Modeling with UML: A Practical Approach de Doug Rosenberg y Kendall Scott (Addison-Wesley, 1999).

60

(Mantenga esta pregunta hasta que haya identificado todos los "escenarios de días lluviosos " que se pueda imaginar, y describa el comportamiento relacionado).

Las preguntas 1 y 2 están relacionas al curso básico (también conocido como el escenario del día soleado, o lo que sucede cuando todo va bien). La pregunta 3 está relacionada a los cursos alternos (también conocidos como los escenarios de días lluviosos, o lo que ocurre cuando el usuario hace algo mal o sale del curso básico de alguna manera). Vamos a volver a estas tres preguntas más adelante en el capítulo, pero vale la pena afirmarlos desde el principio porque resumir su esencia, es de lo que realmente se trata escribir casos de uso.

9. Organice sus casos de uso con actores y diagramas de caso de uso.Este parece ser el momento adecuado para poner detenerse y hablar sobre diagramas de caso de uso y la forma en que se relacionan a los casos de uso y actores.Un diagrama de casos de uso muestra múltiples casos de uso en un diagrama. Es una visión general de un grupo de casos de uso relacionados. El texto en el óvalo es el título del caso de uso. La figura 3-1 muestra un ejemplo de un diagrama de casos de uso.

Figure 3-1. Ejemplo de un diagrama de casos de uso.

Un actor es representado en el diagrama como una figura de palo y es análogo a un "rol" que los usuarios pueden interpretar. A veces los actores son llamados “usuario" pero a menudo se les da un nombre de rol específico. Por ejemplo, nuestro sistema de la Librería de Internet tendrá actores llamados Webmaster, Ordenador de Stock, Empleado de envío y Cliente. El usuario (actor) es externo al sistema –él o ella está en el "exterior", mientras que el sistema está en el "interior". Los actores pueden representar sistemas externos

61

no-humanos así como personas. A veces las personas se confunden por esta noción; hemos detectado que dibujando una "figura de robot de palos" parece aclararlo.

Una asociación de un actor a un caso de uso significa que el actor es el que lleva a cabo ese caso de uso. La asociación también puede significar responsabilidades. Por ejemplo, un Administrador que apunta a un caso de uso Moderar Mensajes del Foro significa que "El administrador es responsable de moderar los mensajes del foro".

Puede tener más de un actor apuntando a un caso de uso, lo que significa simplemente que el caso de uso es asociado a más de un rol. Del mismo modo, un usuario puede servir como más de un tipo de actor, el mismo usuario podría ser tanto el Ordenador de stock y el Empleado de envío.

8. Escriba sus casos de uso en voz activaSi no presto atención en la clase de Español en el colegio (y no tiene un excelente editor como el nuestro) puede que no este familiarizado con el término “voz activa” y “voz pasiva”. Los términos tienen que ver con la perspectiva de la oración que se escribe. Cuando escribe en voz pasiva, describe lo que se ha hecho sin ningún énfasis en -de hecho, a menudo sin mencionar- que o quien está realizando la acción. Por ejemplo:

La capacidad es proporcionada a los usuarios para acceder a ella, usando una esquema de autorización protegido con contraseña.

¿No es grandioso? La capacidad aparentemente ya está proporcionada, por lo que no tendrá que preocuparse. Por desgracia, puede no ser el caso (tendría que construir esa capacidad). El problema con las oraciones pasivos es que ocultan al actor(es) y, más importante aún, a las funciones del software. La oración del ejemplo también suena notablemente como un requisito funcional- la clase de cosa que se tiende a ver en las grandes y pasivas especificaciones de requisitos (también conocido como tormenta de polvo), y que es su trabajo descifrar para todos volviendo a especificar los requisitos en los casos de uso (es decir, usando la voz activa en las descripciones del comportamiento del sistema).

Para identificar las frases pasivas, busque las formas del verbo "ser" ("es" en el ejemplo anterior) delante de otro verbo ("proporcionada" en el ejemplo). El segundo verbo es a menudo en tiempo pasado. Una forma del verbo “ser/estar" seguida de un verbo n tiempo pasado es una señal clara de una oración pasiva que deberá reescribir en voz activa.

Las oraciones pasivas son a menudo poco claras y carecen de energía; sus lectores se dormirán. Las oraciones activas dejan en claro quién hace que, y mantienen despiertos a los lectores. Utilice oraciones activas y escriba desde la perspectiva del usuario, y sus casos de uso serán mejores y con menos posibilidad de ser malinterpretados.

He aquí una voz activa de reescritura de este caso de uso:

El usuario introduce su nombre de usuario y contraseña, luego cliquea en el botón Ingresar. El sistema busca el perfil de usuario con el nombre de usuario y verifica la contraseña. En seguida el sistema inicia una sesión en el usuario7.

7 Recuerde que este es el curso básico de los días soleados escenario asume que todo va bien. También habría supuesto un suplente que describe lo que ocurre si el nombre de usuario o contraseña no fueron encontrados.

62

7. Escriba sus casos de uso utilizando un flujo de evento/respuesta.Un caso de uso es a menudo desencadenado por un evento, iniciado por algún usuario, que el sistema tiene que responder. Sin embargo, también puede ser activado por un evento iniciado por el sistema para que el usuario responda. Pero en cualquier caso, el caso de uso sigue el flujo de evento/respuesta (ver Figura 3-2).

Figure 3-2. Anatomía de un escenario de un caso de uso.

■ NOTA Muy a menudo, el usuario reacciona a una acción del sistema, por lo que el caso de uso comienza con "El sistema muestra la pantalla XYZ (que muestra la información ZZZ)", y luego el usuario hace algo al respecto. El principal beneficio de iniciar un caso de uso con "El sistema muestra..." es que el sistema muestra algo en la pantalla inicializando el comportamiento (obteniendo la información ZZZ de algún lugar) que a menudo se olvida.

Podemos refinar nuestro caso de uso asunto un poco más comenzando con la acción del sistema, que tiene el efecto beneficioso de causar la asignación de un nombre no ambiguo a la pantalla, de la siguiente manera (con la nueva frase en rojo):

El sistema muestra la pantalla de inicio de sesión. El usuario introduce su nombre de usuario y contraseña, luego cliquea en el botón Ingresar. El

63

sistema busca el perfil de usuario con el nombre de usuario y verifica la contraseña. En seguida el sistema inicia una sesión en el usuario.Tenga en cuenta que en esta versión, hemos identificado más detalles

que el contenido de la voz pasiva-en los requisitos. Ahora sabemos que para hacer Log in, el usuario debe hacer clic en un botón de Inicio de sesión y que el sistema debe hallar el perfil de usuario usando el nombre de usuario. De esto se tratan los casos de uso: mostrar, no decir. En lugar de decir, "El sistema permite a los usuarios acceder a través de un régimen de autorización de contraseñas protegidas" lo que en realidad debería hacer es describir los pasos involucrados en el inicio de sesión: el usuario introduce su nombre de usuario y contraseña, el usuario hace clic en el botón de inicio de sesión, y, a continuación, el sistema verifica los detalles y responde a ellos. Escribir los casos de uso en este formato le alienta a pensar en los finos detalles del comportamiento del sistema.

También es importante recordar escribir ambos lados del dialogo usuario/sistema en sus casos de uso. El modelado de casos de uso puede ser pensado como un enfoque exterior. Cuando se escriben escenarios de casos de uso, se describe la interacción del usuario con el sistema. Pero una interacción es una situación de dos sentidos, por lo que también es necesario describir el comportamiento del sistema, además del comportamiento del usuario. Un caso de uso suele constar de varios pasos. Cada paso supone un evento y una respuesta: la acción del usuario y la reacción del sistema, o viceversa (véa la Figura 3-2).

Un caso de uso describe un diálogo entre un usuario y el sistema. Es necesario escribir el diálogo del lado del usuario para mantener sus requisitos de comportamiento enfocados en el usuario, no basta con escribir sólo lo que el usuario hace, porque en última instancia, está tratando de especificar el software, y el software consiste en el comportamiento del sistema. Es de vital importancia describir ambas partes del diálogo (usuario/sistema) en cada caso de uso.

6. Use prototipos GUI y modelos de pantallas

Storyboards, GUI prototipos, y modelos de pantallas son a menudo ayudas visuales muy útiles cuando escribe un caso de uso. Por ejemplo, si basa el caso de uso en un prototipo GUI, es importante incluir todos los botones y menús que el usuario puede tocar para generar eventos dentro del caso de uso.

Recientemente hemos utilizado el término "storyboard" en lugar de "prototipo", ya que siempre hay el peligro de que el prototipo GUI pueda derivar en un diseño GUI muy amplio. Luego, pequeñas funcionalidades pueden ser añadidas en un supuesto prototipo IU "no-funcional" de, y de repente se ha implementado el sistema "completo", todos los bloques se unen con cuerdas y cinta adhesiva, antes de que haya incluso comenzado a analizar los cursos alternos (ese otro 90% de la funcionalidad del sistema).

Si este escenario le preocupa, hay algunas posibles soluciones:

• Use algo así el Napkin Look & Feel8 de Java para darle a su prototipo GUI la apariencia de "esbozado en el reverso de una servilleta". Éste look fija expectativas adecuados a los clientes, para que

8 Vea http://napkinlaf.sourceforge.net.

64

no crean que su equipo ha llegado milagrosamente de alguna manera la etapa de ejecución.• Use dibujos como el de la Figura 3-3. Esto mantiene a todos enfocados en los conceptos operacionales, en lugar de desviarse con minucias GUI ("Ese botón debe estar 3 píxeles a la derecha! Utilice botones spin-no, un scrollbar pop-up!"). Habrá un montón de tiempo (aunque esperemos que no demasiado tiempo) después para esa tortuosa experiencia.

• Use su herramienta CASE para hacer storyboard a sus pantallas y adjuntarlas a sus casos de uso. Por ejemplo, en Enterprise Architect (EA), puede crear un diagrama personalizado (clase extendida) como un sub diagrama debajo de sus casos de uso y, colocar elementos de IU en el diagrama.

Figura 3-3. Ejemplo de un storyboard de IU (Interfaz de usuario).

He aquí un ejemplo de en caso de uso derivado de la storyboard en la Figura 3-3:

El usuario hace clic en Modificar el carrito de compra, y el sistema muestra la página Editar el carrito de compra con una lista de libros en el carrito de compras del usuario. El usuario selecciona uno de los libros, cambia la cantidad, y hace clic en el botón Actualizar. El sistema muestra la página con las cantidades y el precio total actualizado.

El caso de uso evita hacer cualquier referencia a determinados tipos de elementos. Los hipervínculos para cada título del libro podrían convertirse en botones junto a los títulos de libros, por ejemplo, si usted cambia de un HTML a-un Flash. Pero la descripción del caso de uso no se enfoca en estos detalles, y en su lugar se centra en el comportamiento de evento/respuesta.

Si crea sus archivos de interfaz de usuario fuera de su herramienta CASE o tiene capturas de pantalla del legado del sistema, entonces, use Rational Rose o Enterprise Architect para poder enlazar los archivos de la interfaz de usuario a sus casos de uso. (Véase Figura 3-4).

65

Figura 3-4. Vinculando los archivos a los casos de uso con Enterprise Architect.

4. Recuerde que sus casos de uso son realmente una especificación del comportamiento en tiempo de ejecución.

Con ICONIX, usted conduce el diseño desde los casos de uso. En términos prácticos, esto significa que usted dibuja un diagrama de secuencia para todas y cada caso de uso en la fase actual. El diagrama de secuencia muestra con gran detalle cómo las instancias objeto colaboran conjuntamente en tiempo de ejecución para lograr el comportamiento del caso de uso. Por lo tanto, la descripción del caso de uso servirá como una especificación del comportamiento en tiempo de ejecución que se muestra en los diagramas de secuencia.

Pregunta y Respuesta: CASO DE USO= DOCUMENTACION DE USUARIO ?

Siempre se puede pensar en la descripción de los casos de uso como una descripción de las aventuras del usuario cuando interactúa con el sistema. Por lo tanto, iría así, "En primer lugar el usuario hace esto, luego el usuario hace eso." P: Pero no tengo también que describir la respuesta del sistema?R: Sí. Por lo tanto, el texto sería, "Primero el usuario hace esto, entonces el sistema responde con eso. Luego el usuario hace algo, y el sistema responde con…". Y así sucesivamente.

66

P: ¿No es similar a escribir una guía de usuario?R: Exacto. De hecho, estar "impulsado por casos de uso" puede resumirse de este modo: Primero escribir la guía del usuario y, a continuación, escribir el código.P: Se supone que este principio abarca todo el camino hasta el diseño? R: Sí, el objetivo es construir algo que implemente el comportamiento de los requisitos, por lo que el sistema que va a diseñar será fuerte correlacionado con el punto de vista de los usuarios finales. En otras palabras, primero describe el uso del sistema desde la perspectiva del usuario y, luego diseña y hace las pruebas unitarias desde la perspectiva del usuario, también.P: ¿Qué pasa si estamos actualizando un sistema de legado? R: Se aplica el mismo principio. Simplemente trabajo desde la guía del usuario. Analizar la funcionalidad existente y realizar cambios basados en la forma en que esas funciones se llevarán a cabo en el nuevo sistema. Se encontrará rompiendo el legado de la guía del usuario en sus componentes fundamentales, a partir del cual puede obtener sus escenarios de casos de uso.

4. Escribe los casos de uso en el contexto del modelo de objetos. Repita este mantra por lo menos un centenar de veces antes del desayuno:

No se puede conducir diseños orientado a objetos desde los casos de uso a menos que una los casos de uso a los objetos.

En términos prácticos, esto significa que usted necesita hacer referencia a las clases de dominio que participan en los casos de uso, y es necesario que nombre sus pantallas y demás objetos Interfaz explícitamente en la descripción de los casos de uso. De lo contrario, sus requisitos de comportamiento estarán completamente desconectados de su modelo de objetos, y (¡sorpresa!) no será capaz de conducir el diseño desde los casos de uso.

3. Escriba sus casos de uso utilizando una estructura tipo: sustantivo-verbo-sustantivo.Le sorprenderá cuán fácil es crear un diseño orientado a objetos, si la descripción de sus casos de uso siguen el estilo sustantivo-verbo-sustantivo. La descripción del caso de uso residirá en el margen de su diagrama de secuencia (véase el capítulo 8). Y los diagramas de secuencia se orientan fundamentalmente en torno a nombres y verbos:

• Los nombres son las instancias de los objeto. Estos por lo general vienen del modelo de dominio (Entidades) o son objetos Interfaz/GUI.• Los verbos son los mensajes entre objetos. Estas representan las funciones del software (Controladores) que necesitan ser construidos.

Así que escribiendo sus casos de uso en el formato sustantivo-verbo-sustantivo, establece la tarea de hacer diagramas de secuencia considerablemente más fácil de lo que podría ser de otra manera.

67

2. Referencie las clases de dominio por su nombre.Recuerde del capítulo 2 que el modelo de dominio sirve como un glosario del proyecto que ayuda a garantizar la coherencia en el uso de términos cuando describe el espacio del problema. Como mencionamos en el punto 4, cuando se intenta conducir un diseño orientado a objetos desde los casos de uso, es críticamente importante que los casos de uso estén enlazados a los objetos. Si bien esto puede parecer obvio después de haberse establecido, es un hecho, eso es ignorado en muchos libros sobre casos de uso. Pero piense: ¿cómo puede conducir un modelo de objetos desde los casos de uso, si los casos de uso no están vinculados a los objetos? La respuesta corta es que no se puede. Al mismo tiempo, usted no tiene pleno conocimiento del eventual modelo de objetos cuando empieza a escribir casos de uso. De lo que sí tiene conocimiento en ese momento es que es una versión preliminar del modelo de objetos que describe el dominio del problema en términos inequívocos, es decir, el modelo de dominio. Por lo tanto, vincule los casos de uso a los objetos de dominio. En la práctica, esto significa referenciar las clases de dominio por su nombre en la descripción de los casos de uso.

Digamos que tiene un modelo de dominio que contiene clases de dominio, como Lista de Interés, Libro, Lista de libros, y carrito de compra. La siguiente descripción del caso de uso es una "especie de" uso de estas clases de dominio, pero no les hace referencia por su nombre (el texto erróneo se muestra en rojo):

El usuario selecciona un título y lo añade a su lista de libros que se guardará después. El sistema muestra una página con la lista actualizada y también muestra una lista de títulos en el carrito del usuario, listos para comprar.

Aunque este texto parece claro, es un foco de ambigüedad. "Lista de libros se guardarán después" podría, en los siguientes escenarios de casos de uso, reducida a "lista de libros" o "guardar libros," ambos podrían ser interpretados como algo completamente diferente.

Este es el texto corregido (las partes corregidas se muestran en negrita):

El usuario selecciona un Libro y lo añade a su Lista de Interés. El sistema muestra una página con la lista actualizada y también muestra el carrito de compras del usuario.

Se ha ido de un problema a construir un modelo de dominio de modo que puede comunicarse sin ambigüedades sobre los detalles del sistema que está desarrollando. Mantener fuera la ambigüedad de sus casos de uso es uno de sus objetivos principales, sería tonto no utilizar la terminología que su equipo colectivamente acordó en el modelo de dominio.

■ EJERCICIO Hay otro término en esta descripción del caso de uso que es potencialmente ambiguo. Lo cubrimos en la siguiente sección ("Referenciar las

68

clases Interfaz por nombre"), vea si puede resolverlo antes de continuar. Piense con que lo sustituiría.

1. Haga referencia a las clases Interfaz (por ejemplo, pantallas) por nombre.

Desde que está en la misión de escribir requisitos de comportamiento sin ambigüedades y desde que los requisitos de comportamiento casi siempre implican la interfaz del usuario, es una buena idea no escribir frases vagas y ambiguas en sus casos de uso tales como "El sistema muestra una página web". Más bien, nombre sus pantallas explícitamente-por ejemplo, "El sistema muestra la página de compra."

En muchos casos, el comportamiento de importantes soewftware está relacionado con la inicialización de una página antes de mostrarla, y necesita escribir acerca de este comportamiento como: "El sistema muestra la página de compra que mostrando la facturación y las direcciones de envío." Note cómo la descripción del caso de uso es cada vez menos ambigua!.

Volviendo al ejemplo de la Lista de Interés, así es como el texto debería aparecer una vez que la clase Interfaz es referenciada por su nombre (el texto corregido se muestra en negrita):

El usuario selecciona un Libro y lo añade a su Lista de Interés. El sistema muestra la página lista de interés (que muestra también el carrito de compras actualizado).

Observe que hemos sacado la ambigüedad progresivamente de los casos de uso poniéndolos en el contexto del modelo de objetos y el GUI.

Organice los casos de uso en paquetes: Librería en InternetMuy pronto empezaremos a escribir algunos de los casos de uso de la Librería en Internet. Pero antes de hacerlo, necesitamos alguna forma de organizar todos estos casos de uso. En un buen sistema, puede tener en cualquier lugar los 100 casos de uso.

Afortunadamente, UML nos ofrece el mecanismo de paquetes, que es una manera de agrupar elementos relacionados (por ejemplo, clases, diagramas, o casos de uso). Los paquetes son básicamente contenedores jerárquicos que pueden contener casi cualquier construcción UML, incluyendo otros paquetes. Si eres un programador de Java, los paquetes UML no son totalmente disímiles a los paquetes de Java, en la medida en que le permiten dividir su trabajo en diferentes áreas.

Para la Librería del Internet, la Figura 3-5 muestra un diagrama de paquete que contiene cuatro paquetes. Cada paquete contiene una gran cantidad de casos de uso. Además, el paquete Compras contiene un actor

69

(Cliente), y el paquete Administrador contiene cuatro actores (Servicio de Atención al Cliente, Vendedor, Empleado de Envío y Webmaster).

70

Figura 3-5. Diagrama de paquetes para el ejemplo de la Librería en Internet.

Las Figuras 3-6 a la 3-9 muestran los distintos diagramas de caso de uso para cada uno de los cuatro paquetes. Se dará cuenta de que no hemos molestado a los diagramas ni conectado todas las burbujas de casos de uso con flechas. Esto porque la parte más importante del trabajo es escribir la descripción del caso de uso.

Ofrecemos una breve discusión de las relaciones que hemos dibujado, pero como encontrará al final del debate, valoramos lo que sucede en la descripción del caso de uso mucho más que las relaciones entre los casos de uso.

71

Figure 3-6. Diagrama del caso de uso Use para el paquete “general”.

DESCOMPONER EN FACTORES EL COMPORTAMIENTO FUERA COMÚN

La última cosa que quiere hacer al escribir casos de uso es repetir el mismo comportamiento varias veces. Ésta es una horrible pérdida de esfuerzo, para la que no tiene tiempo y una de las principales causas de parálisis de análisis. Por lo tanto, necesita un mecanismo para factorizar el comportamiento común en su propio caso de uso. Nuestra preferencia para ello es una asociación llamada <<invokes>> y su socio en el crimen <<precedes>>.La Figura 3-7 tiene una flecha etiquetada "invokes" que apunta a Orden de Despacho. Debe leer esto en la dirección de la flecha-en otras palabras, "Checkout “ <<invokes>> Orden de Despacho. Simplemente quiere decir que en el curso del caso de uso Checkout , el caso de uso Orden de Despacho puede ser invocado. Debe mencionar el caso de uso invocado en la descripción del caso de uso, de lo contrario, la relación <<invokes>> no tiene mucho sentido. Por lo tanto, la descripción del caso de uso sería, "El usuario hace clic en el botón Confirmar Orden; que invoca a Orden de Despachola orden." <<y>> es la notación UML para los estereotipos. El estereotipo es un mecanismo de extensión UML, por lo que se puede ampliar el centro de notación UML con su propia semántica asignando un estereotipo a un elemento UML.

72

Donde están mis cosas

Figura 3-7. Diagrama de caso de uso para el paquete "admin".

¿QUÉ HAY DE LOS <<INCLUDES>> Y <<EXTENDS>>?

UML define algunos estereotipos estándar para moverse entre los casos de uso (en particular, <<includes>> y <<extends>>; más información acerca de la sutil distinción entre estos en breve). Se leen asociaciones <<includes>> en la dirección de la flecha, mientras que las asociaciones <<extends>> en la dirección opuesta.Es una buena práctica tener sus casos de uso examinados por "no-expertos-UML" como usuarios finales y gente de marketing (porque ellos son los que entienden lo que el comportamiento debería ser). Hemos notado que estas personas a veces se confunden tratando de leer los diagramas de caso de uso con algunas de las asociaciones que apunta hacia delante y otras hacia atrás. Y, después de trabajar con casos de uso durante 15 años, más o menos, estamos convencidos de que los detalles dentro de los casos de uso son muy importantes, no las asociaciones en los diagramas. Puede pensar en <<invokes>> como un súper conjunto de <<includes>> y <<extends>>. Si A invoca a B, puede llegar a B desde A, y los sutiles detalles de la inclusión y la extensión por lo general no son tan importantes para hacer el trabajo

73

(véase la barra lateral titulada "Casos de uso y Aspectos" más adelante en este capítulo para una caso donde esos detalles son importantes).Recuerde en la Figura 3-7 que existe algún tipo de conexión entre Checkout y los casos de uso que la rodean. En la Figura 3-8 (la versión completa de este diagrama de caso de uso) hemos dibujado las relaciones usando flechas <<invokes>>.

Figura 3-8. Diagrama de caso de uso para el paquete” shopping" También hay un par de estereotipos<<precedes>> en la Figura 3-8. Una relación <<precedes>> significa que un caso de uso debe ser completado antes de que el siguiente comience. Así que en el diagrama, el caso de uso

74

Login debe ser completado antes de Checkout inicie, y también Login debe completarse antes de que Escribir reseña del lector se inicie.

Figura 3-9. Diagrama de casos de uso para el paquete "búsqueda"

La Figura 3-9 muestra la relación de "generalización", denotada por una flecha con una punta de flecha triangular. Esta relación es similar a la generalización de las clases (que usamos en el modelo de dominio para la Librería en Internet en el capítulo 2). Por ejemplo, en el diagrama, Buscar por autor "es un" tipo del caso de uso Buscar de Libros.

Note que además de la generalización, UML también define una relación "extends" modelado como un estereotipo. Los desarrolladores de Java pueden encontrarlo confuso al principio, porque en Java "extends" es el mecanismo utilizado para la implementación de una relación de generalización entre clases. Sin embargo, con casos de uso, la generalización y el extends son dos conceptos distintos.

Un caso de uso concreto puede hacer "extends" a un caso de uso abstracto. Se denota en un diagrama de casos de uso mediante el estereotipo <<extends>>. Las diferencias entre la generalización y el “extends” son sutiles pero importantes:

• Extends define un conjunto de puntos de extensión en el caso de uso padre, la generalización no.• Con extends, el padre debe saber que será extendido (con el fin de definir los puntos de extensión); no es así con la generalización.

75

• Extends se añade a la funcionalidad del padre; la generalización hace un overrides (es decir, lo reemplaza totalmente, aunque sea con algo similar).

Sin embargo, nuestra experiencia con la generalización ha sido casi siempre de ningún valor alguno en el modelado de casos de uso. Por ejemplo, en la Figura 3-9, ¿qué ganamos con modelar diferentes casos de uso de búsqueda como tipos del caso de uso abstracto Buscar Libros? Absolutamente nada! La razón por la que no ganamos nada modelando esto se debe a que para nuestros propósitos, los casos de uso no son clases, son fragmentos de la guía del usuario.

■ SUGERENCIA Si piensa que necesita mostrar generalización de casos de uso en su diagrama, piense en lo que quiere hacer como una "generalización de la guía del usuario", y seguramente pensará ¿Qué cosa? (como nosotros)".

Con el diseño de clases, la generalización es útil, porque puede usarla como un factor común y eliminar la duplicación de código. Sin embargo, con los casos de uso, la generalización no le otorga este beneficio. Hay otras relaciones que pueden utilizarse para el factor común, a fin de evitar escribir descripciones de casos de uso duplicadas. (Véase la Tabla 3-1 en la siguiente sección.)

Nuestro consejo es no detenerse en estos diferentes tipos de relaciones por mucho tiempo. Imagine que esta haciendo algún modelado crítico de casos de uso con un aula de costosos consultores de empresas, y su principal objetivo es obtener todos los requisitos de comportamiento de ellos. Pero el reloj suena y todos salen como una estampida para el break del almuerzo. Qué es más importante: obtener la notación exacta, o extraer todos los detalles que se puedan de los consultores, mientras aún los tiene en la habitación?.

■ SUGERENCIA Recuerde, que lo que está dentro de los casos de uso es lo

que cuenta, no la forma en que han sido dibujados en el diagrama.

Relaciones de Casos de UsoDel mismo modo que la cubierta de sillas en el Titanic podría ser dispuesta de diferentes formas, los casos de uso pueden relacionarse de muchas maneras diferentes, las más comunes se enumeran en la Tabla 3-1. Es perfectamente aceptable hacer ruidos con el cuadro siguiente y retroceder con cuidado gritando, "Retrocede, estereotipo maligno". Las relaciones entre casos de uso han sido causa de la pérdida de muchas horas valiosas de modelado de casos de uso, mientras los analistas sostienen que más de uno serían las más indicadas para poner en su próximo diagrama. Nuestro consejo es simplemente escoger uno y quedarse con él, y no preocuparse demasiado sobre cuáles usar.

76

■ SUGERENCIA Encontramos que el 97,3% del tiempo las relaciones<<invokes>> y <<precedes>> funcionan muy bien para vincular casos de uso; las demás relaciones se muestran en la Tabla 3-1, en su mayoría son innecesarios.

Para un regular (no orientado a aspectos) ADOO, lo importante es que demuestre que los casos de uso están, lógicamente, relacionados de alguna manera, y lo más importante es lo que hay dentro de la descripción del caso de uso porque eso es lo que se está diseñando, probando y estimando. Usted conduce el OOAD de los diagramas de clases y los diagramas de secuencia, los casos de uso conducen los diagramas de secuencia. Por lo tanto, los includes y extends son una distracción. No le da nada, lo hace más lento, y confunde a los lectores del modelo de casos de uso.

■ NOTA Hay una gran excepción a nuestro punto sobre que includes/extends son una distracción. Si va a estructurar su código a lo largo de casos de uso vía aspectos, de repente la distinción entre los includes y extends se hace importante. Ver la barra lateral "Casos de uso y aspectos" más adelante en este capítulo.

Tabla 3-1. Relaciones comunes de casos de uso.

Relación Descripción SoluciónGeneralización (denotada con una flecha apuntando de B a A, con una punta triangular blanca)

El caso de uso B es un tipo del caso de uso A (Piénselo como una relación “overrides”, el caso de uso hijo hereda ninguno de los pasos del caso de uso padre).

Ajo colocado alrededor del cuello mientras duerme.

A <<incluyes>> B A medio camino del caso de uso A, se llama al caso de uso B. Cuando B termina, A se lleva a cabo desde que B se detiene. Es muy similar a la llamada de una función o un GOSUB en BASIC. Es como decir "A tiene-un B”.

Bala de plata

A <<extendí>> B Todos los pasos del caso de uso A se realizan durante la ejecución del caso de uso B, en el punto de extensión que se especifica en B. En la mayoría de los casos <<extends>> es <<includes>> con una flecha hacia atrás. (Ambos son los subtipos de <<invokes>>).

Estaca en el corazón

A <<precedes>> B El caso de uso A debe llevarse a cabo en su totalidad antes de empezar el caso de uso B.

Agua bendita

A <<invokes>> B El caso de uso B sucede durante la vida útil del caso de uso A.

Una buena taza de té y un huevo de Pascua de chocolate.

Puede notar en la Tabla 3-1 que todos estos tipos de relación son notablemente similares, hay una diferencia sutil suficiente para hacer de ellos un verdadero dolor cuando la gente esté en desacuerdo acerca de cual utilizar. De hecho, esperamos que la descripción en la barra lateral "Estereotipos de diagramas de casos de uso como un tratamiento para el insomnio" le ayude a convencerse de que el 99% del tiempo, la distinción entre estas relaciones no es importante.

77

ESTEREOTIPOS DE DIAGRAMAS DE CASOS DE USO COMO UN TRATAMIENTO PARA EL INSOMNIO

Si está preocupado por utilizar <<extends>>,<<includes>>,<<precedes>>, <<invokes>>, o generalizaciones en sus diagramas de casos de su uso, o ha tenido dificultades para dormir recientemente, esta práctica barra lateral le ayudará a decidir y/o dormir. Siéntase libre de imprimirla en una tarjeta postal y colocarla por encima de su monitor: La ampliación de un caso de uso debe definir puntos de extensión en los que podrá ser extendido, pero los casos de uso extendidos deben permanecer independiente del casos de uso original, mientras que los casos de uso incluidos no definen puntos de extensión, aunque su comportamiento se ha extendido por el caso de uso incluido, que es similar a usar generalización, que de hecho no define puntos de extensión, pero su comportamiento no es extendido por los caso de uso incluidos per se-es anulado, a diferencia de anteriores casos de uso, que debe llevarse a cabo en su totalidad antes de el caso de uso hijo comience. La flecha <<extends>> DEBERÁ dibujarse a partir del caso de uso extendido hasta la extensión del caso de uso en una forma análoga a una flecha de generalización que se dibuja a partir de la subclase a su clase padre, mientras que una flecha <<includes>>es SIEMPRE dibujada desde el caso de uso incluido hasta la inclusión del caso de uso en un forma análogo a una flecha de agregación se dibuja desde la clase agregada hasta la clase contendedora. Puede considerar <<includes>>y<<extends>> como subtipos de <<invokes>> (es decir, invokes incluye extends e invokes incluye también includes, pero includes no incluye invokes, ni extends incluye includes), con la distinción acerca de los puntos de extensión y si el caso uso extendido sabe sobre su extensión uso que del caso la ampliación o no. Si piensa en un caso de uso como un fragmento de una guía de usuario, en lugar de pensar en él como un clasificador, que es, por supuesto, cómo se define formalmente dentro de UML, es posible descubrir que la diferencia entre tener puntos de extensión o, simplemente, inclusiones dentro del caso de uso, le ramificación no es especialmente significativa, en ese caso un simple invokes puede ser suficiente y no tendrá que preocuparse en la forma en la que debe dibujar las flechas en el diagrama desde que la flecha extends apunta en dirección opuesta a la flecha includes, de manera similar a cómo una flecha de generalización y de agregación son dibujadas en direcciones opuestas. La flecha hacia abajo convención para el extends que es análoga a la generalización puede causar confusión entre la generalización y el extends, especialmente entre los programadores de Java, para quienes extends ya significa generalización. (Extends es un subtipo de invokes, por lo que se puede decir que extendí extiende a invokes; pero aquí usamos extends en el sentido de generalización, no en el sentido extends de UML, por lo que es una extensión de la extendida terminología OO, pero a decir que extends extiende a extends [pero no al extends de UML] sería la extensión de la verdad). Además, cuando el personal no técnico pide examinar los casos de uso, ocasionalmente sufren consternación al intentar seguir las flechas en los diagramas de caso de uso, ya que algunas flechas apuntan del caso de uso invocado al caso de uso invocador, mientras que otros desde el caso de uso invocador hacia el caso de uso invocado. Este problema es generalmente un indicio de una falta de formación UML entre el personal no técnico y es fácilmente resuelto obligando a todos los usuarios y al personal de marketing

78

a asistir a un taller de tres días de "UML para personal no técnico ", que los educará sobre estas sutiles pero importantes características de UML. <<Precedes>>, por otro lado, es un estereotipo algo diferente a includes, invokes, o extends, en el sentido de que simplemente indica una precedencia temporal, es decir, es ocasionalmente útil usarlo en un diagrama de caso de uso, donde un caso de uso A tiene que pasar ANTES del caso de uso B (es decir, hay precedencia temporal en la que A DEBE ocurrir antes que B). Ninguno de los estereotipos estándar UML de casos de uso (es decir, ni includes ni extends) proporciona un mecanismo conveniente para expresar este concepto de precedencia temporal (a pesar del hecho de que mostrar precedencia temporal es a menudo más útil que mostrar si el caso de uso invocado tiene conocimiento de la invocación o no), por lo que en estos casos PUEDE resultar útil etiquetar la flecha con el estereotipo precedes. Se recomienda encarecidamente que en estos casos la flecha precedes debe originarse desde A (es decir, el caso de uso que precede) y finalizar con la punta de la flecha apuntando a B (es decir, el caso de uso que se ha precedido), resta confusión entre los lectores del diagrama de casos de uso. <<Precedes>> no implica necesariamente que el caso de uso precedido tiene profundo conocimiento del anterior caso de uso, aunque en la práctica éste es a menudo el caso, pero el estereotipo precedes simplemente indica una precedencia temporal. El caso se ha hecho para que sea posible dibujar diagramas de casos de uso válidos al invertir la dirección de la flecha y cambiar el estereotipo de precedes a invokes, pero EN REALIDAD el significado cambia sutilmente por esta acción, en la que la flecha invokes por lo general indica que el caso de uso invocador invoca al caso de uso invocado mientras que la flecha precedes indica que el anterior caso de uso precede temporalmente (es decir, que ocurre antes de tiempo) a los precedentes caso de uso.

Librería en Internet: Perfeccionamiento de casos de usoEs hora de escribir la descripción del caso de uso para nuestro primer caso de uso de la Librería en Internet. Empezaremos con Escribir Reseña de Lector, para el que en el transcurso del libro estudiaremos el camino hasta el código fuente. (También daremos seguimiento al caso de uso Mostrar detalles de Libro, comenzando en el capítulo 4).

Comprobando la última versión del modelo de dominio (vea la Figura 2-7), tenemos dos tipos de reseñas de libros: La Reseña del Lector (comentarios de los Clientes) y la Reseña de la Editorial (comentarios escritos por el personal).

Este es el primer corte de nuestro caso de uso:

El usuario escribe una reseña para el ítem seleccionado, le da un puntaje, y lo envía. La reseña es enviada a un moderador.

79

■ EJERCICIO El caso de uso Escribir Reseña de Lector captura los puntos básicos de la interacción del usuario con el sistema, pero el texto es más bien breve. Cuando se trata de escribir casos de uso, una descripción detallada es preferible a una lacónica. Mejoraremos nuestra versión actual en tan sólo un momento, pero en primer lugar, eche un vistazo al proceso de reseñas de lectores en librerías existentes en Internet (por ejemplo, Amazon.com o SpringerOnline.com), y pruebe escribir una versión más detallada.

La descripción de su caso de uso es lo suficientemente importante como para tomar algún tipo de atención. En particular, asegúrese de que está en voz activa (tiempo presente, describiendo las acciones del usuario y las respuestas del sistema, o viceversa) y que usted mismo nombro los objetos de dominio que participan. Sus objetivos son describir el comportamiento del sistema sin ambigüedad e identificar qué objetos de dominio ejecutarán ése comportamiento.

■ SUGERENCIA Cualquier ambigüedad que deje en un caso de uso acabará dando lugar a más trabajo de desambiguación, por lo que trataré de ser tan preciso como pueda en su descripción.

Vamos a ampliar ahora la descripción del caso de uso y poner la carne en sus huesos:

El cliente selecciona el libro. El sistema muestra una página de detalles del libro. El Cliente hace clic en el botón Escribir Reseña, y el sistema muestra la pantalla de Escribir Reseña. El usuario tipea una reseña, le da una calificación de hasta cinco estrellas, y hace clic en el botón "Enviar". El sistema se asegura que la reseña no es demasiado larga ni muy corta, y que la calificación se encuentra dentro de uno a cinco estrellas. A continuación, el sistema muestra una pantalla de confirmación, y la reseña es enviada a un moderador, lista para ser añadida.

Con esta nueva versión, la narración ha comenzado demasiado pronto. Al describir los acontecimientos previos a la página Escribir Reseña, estamos en realidad describiendo parte de un caso de uso diferente. Así que vamos a eliminar la duplicación del texto:

El Cliente hace clic en el botón Escribir Reseña para el libro que esta viendo actualmente, y el sistema muestra la pantalla de Escribir Reseña. El Cliente tipea una reseña, le da una valoración de hasta cinco estrellas, y hace clic en el botón "Enviar". El sistema se asegura que la reseña no es demasiado larga ni muy corta, y que la calificación se encuentra dentro de uno a cinco estrellas. A continuación, el sistema muestra una pantalla de confirmación, y la reseña es enviada a un Moderador, lista para ser añadida.

80

Leyendo a través del caso de uso, puede ver cómo se relaciona al modelo de dominio. Objetos como Reseña y Valoración, que aparecen en el modelo de dominio, son referenciados explícitamente por su nombre en el caso de uso. Hay un actor humano llamado Cliente, y hemos identificó un nuevo actor llamado Moderador (alguien encargado del control de las reseñas antes de su incorporación). Y también habrá algún tipo Pantalla Escribir Reseña.

El caso de uso actualizado describe también la validación que el sistema realiza en los datos enviados (por ejemplo, comprobando que la valoración del libro sea un valor permitido, dentro de uno a cinco estrellas). Como verá cuando avancemos al análisis de robustez en el capítulo 5, describir las validaciones en la descripción del caso de uso es un método importante de identificación de los controladores.

Una última cosa: El nombre actual del caso de uso necesita también algo de trabajo. Se llama Escribir Reseña de Lector, pero en el modelo de dominio el nombre que tenemos para el lector es Cliente. Así que para mantener el caso de uso de acuerdo al modelo de dominio, hay que cambiar el título a Escribir Reseña del Cliente.

■ EJERCICIO Una pregunta que nuestro caso de uso aún no ha respondido es, ¿Qué ocurre si el cliente hace algo mal? Esta importante pregunta es cubierta explorando los cursos alternos, que cubrimos en la siguiente sección. Pero antes de eso, tiene que darle otro vistazo a la descripción del caso de uso y tratar de pensar en las diferentes formas en que el cliente puede extraviarse por los caminos trillados.

ESCENARIOS TIPO DIA SOLEADO/DIA LLUVIOSO

Un caso de uso describe una secuencia de acontecimientos-el "flujo" de la interacción del usuario con el sistema. Pero los usuarios a menudo no usan un sistema como si estuvieran sobre rieles. Hacen diferentes e inesperadas

81

cosas, o el sistema puede ir mal de alguna manera (por ejemplo, error de red). Tiene que preguntarse, "¿Qué ocurre si algo va mal, o si el usuario hace algo fuera de la típica ruta?". Por lo tanto, un caso de uso consiste en un escenario "sobre ríeles" y varios escenarios "sin carriles". Hay un curso básico (a veces llamado el escenario del día soleado) y uno o más cursos alternos (escenario del día lluvioso) Los alternos representan los menos típicos caminos, así como errores. En su afán de crear un "caso de uso gurú" de mercado, han hecho que la substancial tarea de modelado de casos de uso sea incompresiblemente compleja, algunos autores (usted saben quienes son) han propuesto largas y complicadas plantillas de casos de uso para describir la interacción de los usuarios y varios escenarios de un sistema. Plantillas de casos de uso demasiado complicadas por lo general sólo crean trabajo innecesario; acabará tratando de soñar con los detalles (es decir, suponer) para ir en una matriz de subpartidas que probablemente no son apropiados para su caso de uso. (Vea la sección "Un par de reflexiones sobre las plantillas en los caso de uso" más adelante en este capítulo.) Por lo tanto, nuestra “plantilla” de casos de uso es muy sencilla. Simplemente consiste en un "CURSO BÁSICO" y "CURSOS ALTERNOS". Confíe en nosotros, es todo lo que necesita!. Lo importante (bueno, uno de ellas) es no omitir alguno de los escenarios de días lluviosos. Recuerda las "Tres preguntas mágicas" de este capítulo?. Debe seguir preguntándose la tercera "¿Qué más podría pasar?". Cada vez que se pregunte esto, la respuesta le dará un nuevo curso alterno para su caso de uso. Anótelo en el marco de los "CURSOS ALTERNOS".

Librería en Internet: Cursos Básico y AlternosEn el caso de uso Escribir reseña de lector, todo el texto que tenemos en este momento es el curso básico, "El cliente escribe una reseña de un libro, le da una valoración de hasta cinco estrellas, y hace clic en el botón Enviar". Hay una suposición implícita de que el Cliente ha introducido todos los datos para dar una reseña correctamente-la reseña no es tan grande como El Señor de los Anillos y La guerra y la Paz combinadas, la clasificación está en el rango 1-5 (debería haber una validación JavaScript en el navegador, ya que el usuario puede violar fácilmente su página HTML local para que puedan darse 100 estrellas, por ejemplo), y así sucesivamente. Hemos identificado algunos cursos alternos. Recuerde, seguir preguntándose "¿Qué más puede ocurrir?". Algo como esto:

Tenemos nuestro curso básico. Pero, ¿qué otra cosa sucede?

Uh. . . el usuario podría no haber iniciado sesión?OK. Y ¿qué otra cosa podría suceder?

El usuario puede dar una reseña que es demasiado larga.

Bien. Qué más?

La reseña podría ser demasiado corta.

82

Demasiado corta?

No sé, dejarla en blanco, o que tenga menos de diez caracteres, por ejemplo.

. . . y así sucesivamente.

Con estos escenarios de días lluviosos escríbalos, como cursos alternos, nuestro caso de uso Escribir Reseña de Lector debería ahora tener este aspecto:

CURSO BASICO:

El Cliente hace clic en el botón Escribir Reseña para el libro que actualmente está viendo, y el sistema muestra la pantalla de Escribir Reseña. El Cliente ingresa la reseña, le da al Libro una Calificación de hasta cinco estrellas, y hace clic en el botón "Enviar". El sistema se asegura de que la Reseña no sea demasiado larga o corta, y que la valoración del libro se encuentra dentro de una a cinco estrellas. El sistema muestra entonces una pantalla de confirmación, y la reseña es enviada a un moderador, lista para ser añadida.

CURSOS ALTERNOS:

El Usuario no ha iniciado sesión: el usuario es llevado a la pantalla de inicio de sesión y, a continuación, a la pantalla de Escribir Reseña una vez que haya iniciado sesión.

El usuario introduce un comentario que es demasiado largo (texto> 1 MB): El sistema rechaza la reseña y responde con un mensaje explicando por qué el fue rechazada.

83

La reseña es demasiado corta (<10 caracteres): El sistema rechaza la reseña.

■ EJERCICIO Vea si puede descubrir más cursos alternos para este caso de uso (hay muchos más para se hallados!). Si está atascado, lee cada línea del curso básico y pregúntese, "¿Cómo podría ir esto mal?" y "Que podría hacer diferente el usuario aquí?".

CASOS DE USO Y ASPECTOS

La sinergia entre el modelado de casos de uso y la programación orientada a aspectos (POA) es el tema del libro de Ivar Jacobson, Aspect Oriented-Software Development with Use Cases (Addison-Wesley, 2004). Recomendamos encarecidamente que le dé una cuidadosa lectura a este libro, pero nos gustaría presentar la siguiente breve introducción al material. Como resultado, si está haciendo AOP, la diferencia entre <<includes>>y <<extends>> pueden ser importante.

Los casos de uso nos ayudan a organizar requisitos en torno a las necesidades del usuario, mientras que los aspectos nos ayudan a organizar el código en torno a las preocupaciones del usuario.

Un problema generalizado en el desarrollo de software es el llamado cross-cuttings concerns, que generalmente afectan a varias clases y componentes. Ejemplos de cross-cuttings concerns serían cosas como la seguridad, la gestión de transacciones, persistencia, etc.

Hay dos tipos principales de cross-cuttings concerns, que pueden ser modeladas como casos de uso: los pares de casos de uso (separados, casos de uso independientes) y los casos de uso extendidos. Los casos de uso extendido se pueden extender un solo caso de uso (por ejemplo, mejoras) o múltiples casos de uso (por ejemplo, seguridad, gestión de transacciones, persistencia). Estos últimos se denominan los casos el uso de infraestructura.

En lenguajes tradicionales (no de aspecto), implementar pares puede ser enredoso y/o disperso entre componentes, y es difícil mantener el comportamiento de extensión separado del comportamiento de base.

Los aspectos ayudan a organizar el código de pares sin dispersión o enredos, y las extensiones pueden mantenerse separados utilizando pointcuts y advices.

En resumen, si parte su software en casos de uso y optar por un lenguaje de programación orientado a aspectos, básicamente puede organizar su código en torno a casos de uso de las Interfaces, algo que no puede hacer fácilmente en lenguajes de programación OO tradicionales. La organización del código a lo largo de casos de uso de Interfaces tiene el potencial de ahorro de costes durante la vida útil de un programa.

84

Un Par de Reflexiones sobre las Plantillas de Casos de UsoLos equipos que adoptan casos de uso suelen hacerlo porque están tratando de "hacer lo correcto". Así que la natural suposición sería que por la necesidad de enterrar el proyecto en rumas de documentación, especialmente largas y complejas plantillas de casos de uso. Aunque bien intencionado, este enfoque está-nos atrevemos a decir-horriblemente equivocado.

■ ADVERTENCIA No pierda el tiempo con largas plantillas de casos de uso.

He aquí un ejemplo de una larga y particularmente horrible (en nuestra opinión) plantilla de casos del libro “Writing Effective Use Cases” 9 del famoso gurú Alistair Cockburn:

CASO DE USO 24: PLANTILLA DE CASO <NOMBRE>

<El nombre debe ser el objetivo como una frase corta de verbo activo >

Contexto de uso: <una largo declaración de la meta, si fuera necesario, sus condiciones de ocurrencia normal>

Ámbito: <diseño del alcance, qué sistema es considerado la caja negra >

Nivel: <uno de: resumen, objetivos del usuario, sub-funciones>

Actor principal: <el nombre del rol para el actor principal, o la descripción>

Stakeholders e intereses: <lista de stakeholders y los principales intereses en el caso de uso >

Condición previa: <cual es el estado del mundo que esperamos este cumplido>

Garantías mínimas: <Cómo son protegidos los intereses en todas las salidas>

Garantías de éxito: <el estado del mundo si se logra el objetivo >

Trigger: <que hace comenzar el uso case, puede ser un evento en el tiempo>

Escenario principal de éxito:

9 Alistair Cockburn, “Writing Effective Use Cases” (Nueva York: Addison-Wesley, 2000), Pág.119.

85

<poner aquí los pasos del escenario para activar la entrega de la meta y cualquier limpieza que se haga>

<step #> <descripción de la acción>

Extensiones:

<poner aquí las extensiones [sic], una a la vez, cada una refiriéndose al paso del escenario principal correspondiente>

< paso alterado> <condición>: <acción o sub caso de uso> < paso alterado> <condición>: <acción o sub caso de uso>

Tecnología y Datos Variaciones Lista:

<Ponga aquí las variaciones que causarán una eventual bifurcación en el escenario>

<paso o variación #> <lista de variaciones> <paso o variación #> < lista de variaciones >

Información relacionada:

<Cualquiera información adicional que su proyecto necesite >

Consideramos a esta plantilla horrible porque, si bien teóricamente es elegante en el sentido de que cubre ampliamente todo lo que posiblemente quiere discutir en relación con un caso de uso, en la práctica, si necesita a su equipo para "llenar éste formulario largo" de caso de uso rápidamente descubrirán que:

1. Están perdiendo el tiempo. 2. La pérdida de tiempo los retirará del todo del proceso de modelado.3. Pueden rellenar el formulario sin centrarse en las partes importantes (curso básico y alterno) del caso de uso, y nadie notará la diferencia.

Hemos visto que esto ocurre en el mundo real en muchas ocasiones.Considere las aclaraciones que hicimos como advertencias acerca de las

formas que pueden crear resistencia al hacer casos de uso, que ofrecen una excusa para zanjar el modelado por completo-y todos sabemos lo que sucede entonces. (Pista: "El código escrito, así que de repente terminamos!")

Casos de Uso o algoritmos?Muchas personas confunden la diferencia entre casos de uso y algoritmos, ya que ambas tienden a ser descritas con frases de verbos y, en general, pueden ser pensados como una secuencia de pasos. Así que aquí hay algunas pautas para l diferenciarlos.

Una de las principales diferencias entre un caso de uso y un algoritmo es que mientras un algoritmo puede contener una secuencia de pasos, no representan el diálogo entre un usuario y el sistema. Desde la

86

perspectiva de los casos de uso, incluso un muy complicado algoritmo es considerado como un solo paso en diálogo entre el usuario y el sistema. Si corre el riesgo de tener que describir un algoritmo complejo cuando escribe un caso de uso (por ejemplo, generar una lista de libros recomendados, u ordenar la lista alfabéticamente), debe especificar el algoritmo en otro lugar, pero darle al algoritmo un nombre (por ejemplo, "generar recomendaciones", "Ordenar lista") a fin de que pueda ser referenciado en la descripción del caso de uso.

El Cuadro 3-2 resume las diferencias entre un caso de uso y un algoritmo.

87

Tabla 3-2. Casos de uso vs. Algoritmos.

Casos de Uso Algoritmo

Diálogo entre usuario y sistema Computación "Atómica".Secuencia de Evento / respuesta. Serie de pasos.Cursos Básico/ Alterno Un paso de un caso de usoMúltiples objetos participantes Operación en una claseEl usuario y del sistema Todo el sistema

Modelado de Casos de Uso en la práctica En esta sección, ilustramos la teoría presentada en la primera parte de este capítulo yendo a través de una serie de ejercicios que muestran los errores de modelado de casos de uso más comunes.

Ejercicios Para cada uno de los siguientes casos de uso, y vea la cantidad de errores que puede reconocer, y trate de reescribir la descripción del caso de uso. Luego, compare su versión reescrita con la versión "corregida" al final de este capítulo. Buena suerte!

EJERCICIO 3-1: BUSCAR POR AUTOR

CURSO BASICO: El sistema muestra la página con el formulario de búsqueda, el usuario hace clic en el campo Autor y escribe el nombre de un autor (por ejemplo, Fred Smith). El usuario hace clic en el botón Buscar, el sistema lee el formulario de búsqueda, localiza los libros que coinciden con el nombre del autor, y los muestra en una lista.

CURSOS ALTERNOS: No hay libros encontrados: Una página se muestra informando al usuario que no se han encontrado libros que concuerden con la búsqueda.

EJERCICIO 3-2: MODIFICAR CARRITO DE COMPRAS

PRE CONDICIONES: El usuario ha iniciado sesión.El usuario ha navegado en la página de Edición del Carrito de compras.

CURSO BASICO: El usuario añade o elimina cualquier artículo que quiera cambiar y, a continuación, hace clic en el botón Actualizar. El sistema añade o elimina los artículos y, muestra la página con la actualización del carrito de la compra.

CURSOS ALTERNOS: El carrito de compras está vacío: Ningún elemento puede ser eliminado.

EJERCICIO 3-3: ABRIR UNA CUENTA

88

CURSO BASICO: El sistema muestra la página Crear una cuenta nueva y entra los siguientes campos: Nombre de usuario (debe ser único), contraseña, confirmar contraseña, nombre, apellido, dirección (primera línea), dirección (segunda línea), ciudad, estado, país, código postal, número de teléfono y dirección de correo electrónico. Luego el usuario hace clic en el botón Enviar, el sistema verifica que el nombre de usuario es único, crea la nueva cuenta de usuario, y muestra la página principal, junto con un mensaje que indica que la cuenta de usuario se ha creado y se ha iniciado sesión.

CURSOS ALTERNOS: Contraseña y Confirmar contraseña no coinciden: La página vuelve con un mensaje de validación. Nombre de usuario no es único: La página vuelve al usuario y le pide que elija un nombre de usuario distinto.

SolucionesA continuación las soluciones a los ejercicios propuestos.

EJERCICIO 3-1 SOLUCION: NOMBRES DE OBJETOS BOUNDARY EXPLICITOS

El mismo problema se puede encontrar en varias ocasiones en este caso de uso: los objetos Interfaz no tienen nombres explícitos.

A continuación la versión corregida.

CURSO BASICO:El sistema muestra la página de búsqueda, el usuario hace clic en el campo Autor e ingresa un nombre de autor (por ejemplo, Fred Smith). El usuario hace clic en el botón Buscar, el sistema lee el formulario de búsqueda, localiza los libros que concuerden con el nombre del autor, y muestra la página de resultados de búsqueda que muestra la lista de libros resultantes.

CURSOS ALTERNOS: No hay libros encontrados: La Búsqueda no se ha encontrado la página se visualiza.

EJERCICIO 3-2 SOLUCION: VAGA Y AMBIGUAHay por lo menos tres problemas con este caso de uso.

Problema 1: El caso de uso incluye una cláusula de "condiciones previas". Aunque en muy raras ocasiones, podría encontrar que es útil incluir esta cláusula, la mayor parte del tiempo no tiene un efecto apreciable. En este ejemplo, en realidad se arroja la descripción del caso de uso fuera del curso, ya que la primera "pantalla" de acción se pierde. Esto a su vez se pierda en el diagrama de robustez, lo que significa que probablemente se omita en el diseño, no se estime, y no sea probado.

Problema 2: La descripción del curso básico es un poco rara. No describir una situación específica, sino que intenta cubrir todas las bases ("El usuario agrega o elimina cualquier ítem..."). Como resultado, un importante aspecto del comportamiento se pierde: el usuario no necesariamente quiere añadir ítems en

89

esta página, sólo eliminarlos (o cambiar la cantidad).

Problema 3: El curso alterno no encaja en una acción en particular en la descripción del caso de uso. También hay varios relativamente obvios cursos alternos que faltan.

A continuación, la versión corregida.

CURSO BASICO: El sistema muestra la página del carrito de compras. El usuario hace clic en el botón "Eliminar" al lado de Artículo de Línea. El sistema elimina el ítem del carrito de compras del usuario y, a continuación, vuelve a mostrar la página. El usuario hace clic en el campo de texto Cantidad para otro Artículo, cambia su valor de 1 a 2, y hace clic en el botón Actualizar. El sistema actualiza el carrito de compras, recalcula el importe total, y vuelve a mostrar la página.

CURSOS ALTERNOS: Articulo no encontrado: El item que el usuario escogió para eliminar no se ha encontrado en el carrito de compras (esto podría suceder si el usuario tiene dos pestañas del navegador abiertas y está viendo una versión antigua de la página). El sistema actualiza la página del carrito de compras, con un mensaje de advertencia de fallo porque la página estaba fuera de fecha. Cantidad cambiado a cero: Esto cuenta como eliminar el ítem, por lo que el ítem se elimina del carrito de compras.Valor negativo o no numérico: La página vuelve a aparecer con la cantidad original, y un mensaje informando al usuario que ha entrado un valor no válido.

EJERCICIO 3-3 SOLUCION: MUCHOS DETALLES DE PRESENTACION

Este caso de uso se encuentra en los detalles de presentación, gasta demasiado en enumerar los campos que se encuentran en la página Crear cuenta nueva. En su lugar estos campos deben añadirse como atributos a la clase correspondiente en su modelo de dominio (muy probablemente en la clase Cliente). Cuando los necesite en adelante, estarán justo ahí.

A continuación, la versión corregida.

CURSO BASICO: El sistema muestra la página Crear cuenta nueva y entra los campos para definir una nueva cuenta de cliente (nombre de usuario, contraseña, dirección, etc.) Luego el usuario hace clic en el botón Enviar, el sistema comprueba que el nombre de usuario es único, crea la nueva cuenta de usuario, y muestra la página principal, con un mensaje indicando que la cuenta de usuario ha sido creada y se ha iniciado sesión.

CURSOS ALTERNOS: Contraseña y Confirmar contraseña no coinciden: La página vuelve a mostrarse con un mensaje de validación. Nombre de usuario no único: La página vuelve a mostrarse al usuario y se le pide que elija un nombre de usuario distinto.

90

Más Práctica

Esta sección proporciona una lista de preguntas que puede usar para probar su conocimiento acerca del modelado de casos de uso.

1. Un caso de uso captura a) Objetos, clases, y sus asociaciones.b) El flujo de operaciones dentro de un sistema.c) Una discreta, visible función usuario.d) Colaboraciones entre los objetos organizadas por el tiempo.

2. Un caso de uso que se utiliza para conducir un diseño de software debe ser a) Abstracta, esencial, neutralidad tecnológica, e implementación independiente b) Vago, incompleta y ambigua.c) Específica e inequívoca, y deberá indicarlo expresamente para todas las acciones del usuario y respuestas del sistema.d) "Completamente vestida"-en particular, especificar las condiciones previas, las post condiciones, y requisitos funcionales.

3. Al escribir un caso de uso, un escenario tipo día lluvioso es referido como a) Un punto de extensión b) Un caso de uso generalización c) Un curso alterno de acción d) Una condición previa

4. Hacer el diagrama de robustez para un caso de uso sirve para cual de los siguientes propósitos: a) Asegurarse de que se entiende de que los objetos participan en el caso de uso b) Asegurarse de que se entiende cómo los usuarios interactúan con la GUI c) Verificar doblemente que se ha cubierto todos los posibles cursos de acción d) Desambiguar la descripción de los casos de uso y colocarla en la forma nombre--verbo-nombree) Todas las anteriores

5. Liste tres cosas que son comunes entre un caso de uso y una sección de un manual del usuario para un sistema. Lista tres cosas que son diferentes. (Sugerencia: ¿Cuáles son las cosas que faltan en un manual de usuario que se necesitan para desarrollar un diseño de software OO?)

6. Ataque o defienda la siguiente declaración:

Plantillas largas de casos de uso que incluyen temas como condiciones previas, post condiciones, y requisitos funcionales son una causa de la parálisis del análisis, y, por tanto, largas plantillas deben evitarse.

Cite los pros y los contras de este argumento, y explique su conclusión.

91

7. Lista tres grandes diferencias entre los casos de uso y las historias de usuarios de Extreme Programming (XP). ¿Cuáles son las ventajas de cada uno?

8. Explicar la diferencia entre <<includes>> y <<extends>> de acuerdo a la especificación UML. En particular, atacar o defender la siguiente declaración:

La diferencia entre los estereotipos <<includes>> y <<extends>> sobre las asociaciones en los diagramas de casos de uso no son generalmente importantes a menos que el software sea implementado utilizando un lenguaje de programación orientado a aspectos que apoye directamente la organización del código en torno a las extensiones.

¿Cómo el estereotipo <<invokes>> se relaciona a <<includes>> y <<extends>>? ¿Cuál es el objetivo principal de estos tres estereotipos? ¿Cuál crees que es el más útil conjunto de estereotipos: <<invokes>> y <<precedes>>, o <<includes>> y <<extends>>?

Resumen

En este capítulo, hemos cubierto en detalle cómo escribir los tipos de casos de uso que pueden utilizarse para conducir un diseño de software. El diagrama de actividad de la Figura 3-10 muestra cómo el modelado de casos de uso encaja en el esfuerzo global del Análisis de requisitos; las tareas que hemos discutido en este capítulo se muestran en rojo.

En la Meta 1, habrá escrito el primer la primera versión del proyecto de casos de uso, habiendo hecho preguntas al cliente, usuarios finales, y otros para extraer toda la información posible acerca de cómo el nuevo sistema debe comportarse. Pero el rol del cliente no acaba ahí. En el siguiente capítulo, vamos a cubrir la etapa de la Revisión de los requisitos, en la que se garantiza que el modelo de dominio y los casos de uso trabajan juntos para hacer frente a los requisitos del cliente.

92


93









del nuevo sistema

propuesto


del nuevo sistema

propuesto













uso.


uso.


Figura 3-10. Análisis de Requisitos. Punto de control 2.


uso.


uso.

Pantallas

Documents

Metodologia Iconix 1-2-3