Lectura Fundamental 12
Casos de Uso: de Extensiones y de Inclusiones
“El hombre vive fascinado por la inmensidad de la eternidad y nos preguntamos: ¿Nuestras acciones perdurarán a través de los siglos? ¿Gente que no conocemos oirá nuestros nombres mucho después de nuestra muerte? ¿Y se preguntarán quiénes éramos, cuán valientemente peleábamos, cuán ferozmente amábamos?”
Wolfgang Petersen (Troya, 2004)
Introducción
De vuelta en el tiempo, hace unas siete Lecturas Fundamentales, prometí hablar de las relaciones entre los casos de uso. Pues bien, he querido extender el tema hacía el no menos complejo asunto de modelar sistemas de información mediante casos de uso. Trataré de mantener una posición minimalista: abordaré sólo la cuestión relacionada con el diagrama de casos de uso.
Básicamente, un diagrama de casos de casos de uso está compuesto de Actores y Casos de Uso, y las relaciones entre los unos, entre los otros y entre los unos y los otros.
Para recordar qué es un Actor podemos leer la Definición 5 en [3]. Para recapitular sobre Casos de Uso, podemos leer esencialmente [4] y luego repasar [5], [6], [7] y [3]. Ya sabemos además que podemos usar UML [8] para especificar, visualizar, construir y documentar los artefactos de sistemas de software.
Generalización de Actores
Dos o más Actores se relacionan entre ellos mediante la Generalización (de actores). Esta relación significa que uno o más actores pueden heredar las características, pero mejor aún, las responsabilidades de otro actor del sistema. Un Vendedor de Licencias de Software y un Vendedor de Servicios de Ingeniería tienen al menos una responsabilidad en común, una actividad: Registrar Cliente. Si los roles se interceptan en dos o más actividades en el sistema, es posible entonces, por razones de organización del modelo, de abstracción y de simplicidad, crear un nuevo actor: Vendedor de Productos y Servicios. Este parentesco se diagrama como muestro en la figura 1.
Además, muchas veces enfrentamos el dilema en el que un caso de uso (del sistema) es ejecutado por dos o más actores. Como en un sistema de Administración de Proyectos, donde el Gerente de Proyectos puede Matricular un Proyecto, pero también lo puede hacer el Gerente de la Oficina de Proyectos. Una mala idea es expresar esta situación como lo hago aparecer en la figura 2.
Figura 1: Diagrama parcial de Actores de un Sistema CRM
En cambio, usamos la generalización, creando un actor que desde el punto de vista del negocio y del usuario es Abstracto: el Administrador de Proyectos. Entonces, el diagrama se convierte en algo como lo que sugiero en la figura 3.
Figura 2: Diagrama Incorrecto de Casos de Uso de un Sistema de Administración de Proyectos
Figura 3: Diagrama Correcto de Casos de Uso de un Sistema de Administración de Proyectos
Quizás lo que sucede en estos casos es que confundimos Actores del Negocio [3] con Actores del Sistema o, simplemente, cargos o roles de la organización para la cual se construye la aplicación con roles o responsabilidades en el sistema de las personas que ejercen esas funciones. Ese no es el camino.
Por último, tengamos en cuenta el sentido de la generalización de actores: los casos de uso ejecutados por el actor padre son en la práctica ejecutados por los hijos.
Relaciones Entre Actores y Casos de Uso
Un Actor se comunica con casos de uso, componentes y clases [9]. Esta comunicación se representa mediante la relación de Asociación (binaria). En Particular, nos interesa la relación entre el actor y el caso de uso. Esta relación muestra el actor que inicia o ejecuta el caso de uso, normalmente una persona o un grupo de personas, pero también cualquier entidad externa al sistema, como otra aplicación o maquinaria especial.
Las figuras 3, 4, 5 y 6 son muestras de relaciones de asociación típicas entre actores y casos de uso.
En estos diagramas, la constante es que la relación es en ambos sentidos, es decir, es una relación de toma y dame, el actor hace-el sistema hace. Pero también se presentan casos donde la asociación es en un solo sentido, o hacia el caso de uso o hacia el actor. Estas situaciones son comunes cuando el actor no es una persona, sino un software externo o una máquina. Como en la figura 4, donde al ejecutarse la funcionalidad de registrar un cliente que es persona natural, el sistema CRM le comunica al sistema contable que matricule un tercero.
En este diagrama, la funcionalidad que va al sistema externo se representa como un caso de uso “incluido”, una relación de la que hablaré en breve. Pero en la práctica, la comunicación puede ir directamente del caso de uso principal al sistema externo.
Figura 4: Diagrama Parcial de Casos de Uso donde interviene un sistema externo
Casos en los que un actor se relaciona con una clase o un componente se presentan cuando el actor es un sistema externo que envía o recibe datos del sistema principal o, cuando siendo persona, el actor se comunica con el sistema vía una página Web, por ejemplo, que se representa como una clase en la aplicación. Este último caso se presenta en los diagramas de Interacción, como los de Secuencia [10] o de Comunicación.
Relaciones Entre Casos de Uso
Este es la materia que genera más polémica y la que es menos entendida en la comunidad de la IT, así es que trataré de ir más despacio.
Dos o más casos de uso se pueden relacionar entre ellos para distintos propósitos: distribuir mejor el modelo, establecer condiciones de reusabilidad (de funcionalidad), de incrementos del software, y para planear las iteraciones, entre otros. Las relaciones son de tres tipos: Inclusión, Extensión y Generalización. Enfatizaré en las dos primeras.
Relación de Inclusión
Una relación de inclusión define que un caso de uso contiene el comportamiento definido en otro caso de uso [11].
Una relación de inclusión es una relación de un caso de uso base a un caso de uso incluido en la que se especifica como el comportamiento definido en el caso de uso incluido es explícitamente insertado en el comportamiento del caso de uso base [1]. Decimos entonces que el caso de uso incluido es abstracto, es decir, no es ejecutado directamente por un actor.
Esta relación se usa cuando queremos:
-
Factorizar o descomponer (en sentido matemático) el comportamiento del caso de uso base que no es necesario para entender el objetivo principal del mismo y donde solamente el resultado del caso de uso incluido es importante.
-
Distribuir en uno o más casos de uso, funcionalidad del caso de uso base que es común para dos o más casos de uso (reusabilidad).
La primera opción se usa especialmente en casos de uso largos o complejos donde algunas partes del mismo no son relevantes para el sentido primordial del caso de uso y no son necesarias, en primera instancia, para entenderlo y aprobarlo. Por ejemplo, un caso de uso para Ingresar un Cliente de Naturaleza Jurídica puede solicitar docenas o cientos de datos que se pueden agrupar de acuerdo a algunos criterios como Datos Generales, Datos del Tipo de Entidad y Naturaleza Jurídica, Datos del Gerente o Representante Legal, Datos de los Contactos, Referencias Comerciales, entre otros. Algunos de estos grupos de datos pueden incluirse en casos de uso complementarios que son ejecutados desde el caso de uso principal que podría lucir así:
Caso de Uso: Registrar Cliente Jurídico
Actor: Vendedor de Productos y Servicios
Descripción: este caso de uso permite registrar los datos de una persona de naturaleza jurídica…
Secuencia Básica:
1. El caso de uso inicia cuando el Actor decide registrar los datos de una persona jurídica
2. El sistema pide seleccionar la ciudad y oficina de vinculación
3. El actor selecciona la ciudad y oficina de vinculación
4. …
…
12. Se ejecuta el caso de uso Registrar Datos del Tipo de Entidad y Naturaleza Jurídica
13. Se ejecuta el caso de uso Registrar Datos del Gerente o Representante Legal
14. Se ejecuta el caso de uso Registrar Datos de las Referencias Comerciales
15….
…
25. El caso de uso termina
Poscondiciones: N/A
Requisitos Especiales: N/A
En este ejemplo, en los pasos 12 a 14 se ejecutan distintos casos de uso de los que, en principio, interesa el resultado. La palabra clave es “en principio”. En este diagrama también muestro la segunda posibilidad de inclusión, el reuso, con el caso de uso Verificar Centrales de Riesgo, que se ejecuta desde varios casos de uso del modelo.
Algunos aspectos de los casos de uso incluidos que debemos tener en cuenta:
-
Un caso de uso incluido no contiene una funcionalidad significante para la arquitectura del sistema, especialmente para la vista funcional o de casos de uso.
-
Un caso de uso incluido se puede “prototipar” en las primeras de cambio, es decir, durante el análisis y el diseño del mismo, el diseñador se puede concentrar en el caso de uso base y omitir los detalles particulares del caso de uso incluido.
Figura 5: Diagrama parcial del caso de uso Registrar Cliente Jurídico
-
Un caso de uso incluido no debe usarse como excusa para hacer descomposición funcional [4], es decir, tener uno o más casos de uso incluidos que especifiquen aspectos CLAB (creación, lectura, actualización o borrado –CRUD en inglés) o que estén vinculados a usuarios concretos específicos, o completamente ligados a un componente del sistema o a un componente arquitectónico específico, o vinculados a una pantalla o función de usuario determinada, o en algún paso de su secuencia ejecutan otros casos de uso incluidos (asunto este que debería evitarse tanto como se pueda). Para saber más de casos de uso funcionalmente descompuestos ver Definición 3 en [4].
-
Un caso de uso incluido está incompleto por naturaleza, es decir, por sí solo no arroja un resultado observable para el actor, o es un resultado parcial, o sus escenarios dependen de lo que ha pasado antes en el caso de uso principal.
-
Un caso de uso incluido no es ejecutado por un actor distinto al actor del caso de uso base. Sin embargo, un caso de uso incluido puede tener asociado un actor pasivo o secundario, normalmente cuando este actor recibe o entrega información al caso de uso incluido, como anotaba en la figura 4.
-
Un caso de uso incluido no se usa para especificar procesos automáticos o semi-automáticos que el sistema realiza en su totalidad sin interacción con el usuario.
-
Un caso de uso incluido siempre se implementa con el caso de uso base o antes, si se trata de un caso de uso que expone funcionalidad común. En otras palabras, el caso de uso incluido se implementa durante la misma iteración en que se implementa el primero caso de uso principal que lo incluya.
-
Un caso de uso incluido no es condicional, es decir, si el ejecutar el caso de uso base se alcanza el paso donde se ejecuta el caso de uso incluido, éste se ejecuta. Por supuesto, la ejecución de la funcionalidad incluida puede depender de si se cumple una condición o no en el caso de uso base, pero esta condición debe especificarse explícitamente en el caso de uso principal, como apunto en el paso 12 del ejemplo siguiente:
Caso de Uso: Registrar Cliente Natural
Actor: Vendedor de Productos y Servicios
Descripción: este caso de uso permite registrar los datos de una persona natural.
Secuencia Básica:
5. El caso de uso inicia cuando el Actor decide registrar los datos de una persona natural
6. El sistema pide seleccionar la ciudad y oficina de vinculación
7. El actor selecciona la ciudad y oficina de vinculación
8. El sistema solicita el nombre de la persona
9. El actor ingresa el nombre de la persona
10. El sistema pide seleccionar la profesión de la persona
11. El actor selecciona la profesión de la persona
12. Si la profesión es “Congresista” se ejecuta el caso de uso Verificar Lista Clinton.
13. …
14. Se ejecuta el caso de uso Registrar Datos de las Referencias Comerciales
15….
…
25. El caso de uso termina
Poscondiciones: N/A
Requisitos Especiales: N/A
-
Un caso de uso incluido debería incluir, en su documentación, una sección que describa explícitamente los casos de uso base desde los cuales es incluido. Este simple ejercicio hace al documento tan auto-suficiente o auto-contenido como sea posible, es decir, los interesados en el artefacto no tendrán que navegar por ningún otro lado para conocer todo el detalle del caso de uso.
-
En un caso de uso incluido, las precondiciones siempre se han cumplido en el caso de uso base que lo incluye. Entre tanto, las poscondiciones del caso de uso incluido afectan el comportamiento del resto del caso de uso base.
-
Finalmente, un caso de uso incluido no debería tener relaciones de extensión con otros casos de uso. Simplemente no tiene sentido.
Pasemos precisamente a la trama de las extensiones.
Relación de Extensión
La Extensión es una relación de un caso de uso de extensión a un caso de uso extendido que especifica como y cuando el comportamiento definido en el caso de uso de extensión puede ser insertado en el comportamiento definido en el caso de uso extendido [12].
Esta relación se usa:
-
Para establecer que un fragmento de la funcionalidad del caso de uso es opcional, o potencialmente opcional. A diferencia de lo que ocurre con la inclusión que es una relación que implica obligatoriedad en la ejecución, por decirlo de cierta manera.
-
Para señalar una parte del comportamiento que es ejecutado sólo bajo ciertas circunstancias, a veces excepcionales, tales como el envío de un mensaje a un usuario cuando se produce un hecho determinado. Por ejemplo, cuando un cliente VIP solicita el aumento de un cupo de crédito y la cantidad solicitada sobrepasa la política de crédito que puede soportar al Analista de Crédito, entonces el proceso pasa a una instancia mayor, como un Gerente de Oficina o algo así. Decimos entonces que ha ocurrido una interrupción en el caso de uso. A este dilema nos enfrentamos continuamente y la primera intención de un Ingeniero de Requisitos inexperto es crear un único caso de uso con dos actores. Ahora ya sabemos que realmente son dos parejas actor-caso de uso.
-
Para mostrar que puede haber un conjunto de segmentos de comportamiento de los cuales uno o varios de estos pueden ser insertados en un punto de extensión en un caso de uso base o extendido. Estas secciones insertadas (y el orden en el cual son insertadas) dependerán de la interacción con los actores durante la ejecución del caso de uso base.
La extensión es condicional, lo que significa que su ejecución depende de lo que ha pasado mientras se ejecuta el caso de uso base. Éste no controla las condiciones para la ejecución de la extensión –las condiciones son descritas dentro la relación de extensión. El caso de uso de extensión puede acceder y modificar los atributos del caso de uso base. Éste, sin embargo, no puede ver las extensiones y no puede acceder a sus atributos.
Una diferencia fundamental con la inclusión es que, en la extensión, el caso de uso base está completo por sí mismo, es decir, que debería entenderse y tener significado completo sin ninguna referencia a sus extensiones. Sin embargo, el caso de uso base no es independiente de las extensiones, puesto que no puede ser ejecutado sin la posibilidad de seguir las extensiones [2]. También pasa que el caso de uso de extensión puede acceder y modificar los atributos del caso de uso base, pero éste no puede ver las extensiones y no puede acceder a sus atributos. Y más, el caso de uso base se modifica implícitamente por las extensiones. En otras palabras, el caso de uso extendido (base) es ciego a sus extensiones específicas, pero no al contrario.
Un poco truculento, pero así es. La figura 6 es una muestra típica de extensión de casos de uso.
Otra gran diferencia entre la inclusión y la extensión es que el caso de uso de extensión puede ser ejecutado por un actor distinto al caso de uso base, como observamos en el diagrama. Observamos también la condición que activa la extensión en cada caso: en una de ellas se trata de un crédito de mayor cuantía, donde la mayor cuantía es un atributo que puede y debería ser configurable; mientras que en el segundo caso se trata de un cliente del sector gubernamental o bien podría ser algún otro tipo de cliente con tratamiento especial.
Figura 6: Diagrama parcial del caso de uso Aprobar Solicitud de Crédito
Y más de la cuestión semántica, las extensiones de un caso de uso son suplementarias, lo que quiere decir, que el caso de uso extendido está completo, es un todo. En el ejemplo de la figura 6, Aprobar Solicitud de Crédito es un caso de uso terminado por sí mismo y bien podría ser implementado en una iteración distinta (previa) y hasta en un proyecto diferente a la iteración o proyecto donde se implementan los otros casos de uso. Esta es otra de las razones por las que se usa la extensión.
Y estos son algunos aspectos de los casos de uso extendidos y de extensión que debemos tener en cuenta a la hora de modelar sistemas de información:
-
Un caso de uso extendido y sus casos de uso de extensión sí entregan un resultado de valor observable para el actor que los ejecuta, ya sea a través de ellos mismos o transfiriéndolo de la extensión al extendido y de allí al actor.
-
Un caso de uso de extensión no es una especialización del caso de uso extendido, es decir, la extensión no es una relación de herencia o de generalización, dependiendo desde el ángulo del cual miremos. Hago énfasis en este aspecto porque tengo la ligera impresión de que, no sólo los analistas noveles, sino también los diseñadores y los programadores estamos entrenamos para ver la extensión como una especialización, cuando en realidad no es así.
-
Quizás es por eso que la OMG tomó la decisión de cambiar la definición formal de la extensión para que sea una relación de dependencia. Aunque quiero aprovechar este punto para decir también que esta situación se desprende de la estructura formal de UML, la así llamada Especificación de Infraestructura de UML [13], algo que nos ha complicado la vida de muchas formas, sin embargo, esta definición formal muchas veces es irrelevante en la vida real, quiero decir, no es práctica en la mayoría de los modelos que construimos.
-
Un caso de uso se puede usar para documentar nuevas versiones del caso de uso original. Este es un gran beneficio de la extensión, porque deja intacto el caso de uso original que posiblemente ya está implementado y hasta en producción y permite que el analista de requisitos se concentre con los usuarios en las nuevas características del caso de uso extendido.
Aquí nos enfrentamos a la disyuntiva de extender o no extender un caso de uso. Me refiero a que si el cambio es pequeño, posiblemente sea más útil y práctico especificar una secuencia alterna en el caso de uso base; si la modificación es substancial, a juicio del analista, éste tomará la sabia decisión de crear un nuevo caso de uso.
Ahora bien, un caso de uso extendido luce más o menos así:
Caso de Uso: Aprobar Solicitud de Crédito
Actor: Analista de Crédito
Descripción: este caso de uso permite aprobar una solicitud de crédito realizada por un cliente…
Secuencia Básica:
1. El caso de uso inicia cuando el Actor decide aprobar una solicitud de crédito
2. El sistema solicita el radicado y la fecha de de la solicitud
3. El actor ingresa el radicado y la fecha de de la solicitud
4. El sistema valida que el radicado exista para la fecha establecida y muestra los datos de la solicitud: nombre o razón social del cliente, número de identificación y tipo de la misma, dirección, ciudad, …, sector del cliente, cantidad solicitada, …
5. El sistema pide seleccionar el tipo de desembolso (Cheque, Consignación, Efectivo)
6. El actor selecciona el tipo de desembolso
7. El sistema solicita el número de aprobación de la solicitud
8. …
…
25. El caso de uso termina
Poscondiciones: N/A
Puntos de Extensión
5A. La cantidad solicitada es de Mayor Cuantía
7A. El cliente es del sector Gobierno
Requisitos Especiales: N/A
Lo único distinto son los puntos de extensión. Observen que la secuencia básica del caso de uso, ni ninguna otra secuencia, hace alusión a uno o más casos de uso de extensión. Es lo que había dicho: el caso de uso base no conoce los atributos ni las características del caso de uso de extensión.
Por su parte un caso de uso de extensión, se diferencia de un caso de uso normal en que debe tener especificado el evento que lo activa (llamado comúnmente trigger). Por ejemplo, en la figura 7, Asignar Revisión de Arquitectura es considerada una actividad especial por el sistema de Administración de Proyectos:
Figura 7: Diagrama parcial de casos de usos de un Sistema de Administración de Proyectos
Este caso de uso, que extiende a Asignar Actividad, podría lucir más o menos así:
Caso de Uso: Asignar Revisión de Arquitectura
Actor: Gerente de Oficina de Proyectos
Descripción: este caso de uso permite al PMO asignar la revisión de una arquitectura de software…
Evento de Activación: la actividad es una actividad especial: Revisión de Arquitectura
Secuencia Básica:
1. El caso de uso inicia cuando el Actor decide asignar una revisión de arquitectura
2. El sistema pide seleccionar el revisor técnico
3. El actor selecciona el revisor técnico
4. El sistema verifica que el revisor técnico tenga el perfil requerido para la actividad
5. El actor …
6. …
…
12. El caso de uso termina
Poscondiciones: N/A
Requisitos Especiales: N/A
La figura 7 también dilucida sobre otro aspecto de las relaciones entre casos de uso: un caso de uso base puede estar asociado con uno o más casos de uso incluidos y con uno o más casos de uso extendidos.
Otro aspecto importante de las relaciones de extensión es que el diagrama es bastante explicativo. En la figura 8, por ejemplo, está claro que un vuelo cualquiera puede ser reservado por un pasajero cualquiera, pero que si el pasajero está registrado como frecuente, la reserva tiene algunas características especiales (estas particularidades no se pueden observar en un diagrama de casos de uso como este).
El diagrama 8 también muestra otro aspecto de las relaciones de extensión y es que un caso de uso de extensión puede ser a su vez extendido por uno o más casos de uso de extensión. Y este hecho profundiza más en el proceso del negocio que resuelve este modelo: si el vuelo es internacional, y el pasajero frecuente además está registrado como pasajero VIP, tiene la opción de establecer o seleccionar el menú que consumirá durante el vuelo.
Figura 8: Diagrama parcial de casos de usos de un Sistema de Reservación de Vuelos
Del diagrama no se pude extraer información sobre las distintas clases de vuelo que proporciona la aerolínea. Sin embargo, este es precisamente el objeto del siguiente apartado: la clasificación de casos de uso, en el sentido de generalización, llamada también herencia de casos de uso.
Generalización Entre Casos de Uso
Una generalización es una relación taxonómica entre un clasificador más general y un clasificador más específico. Cada instancia del clasificador específico también es una instancia indirecta del clasificador general. Así, el clasificador específico hereda las características del clasificador más general [14].
Esta relación es ampliamente usada en el modelado orientado a objetos, sin embargo, no solo se da entre clases y objetos, sino entre cualquier elemento de UML que actúe como clasificador, como los casos de uso.
La generalización de casos de uso se usa cuando dos o más casos de uso comparten comportamiento, estructura y propósito. Es decir, si dos casos de uso ejecutan un conjunto amplio de actividades similares y sólo algunas diferentes, es posible tomar todas las tareas comunes y especificarlas en un nuevo caso de uso que generaliza a los dos anteriores y en estos dos sólo se especifican las tareas disímiles. Esa es la primera premisa para usar la relación de generalización entre casos de uso, como en la figura 9, donde es posible que Reservar Vuelo Doméstico y Reservar Vuelo Internacional sólo difieran en que para este último caso el actor pueda seleccionar la ruta y especificar algunas condiciones especiales de vuelo.
Figura 9: Diagrama parcial de casos de usos de un Sistema de Reservación de Vuelos
El caso de uso Reservar Vuelo Doméstico puede especificarse de la siguiente manera:
Caso de Uso: Reservar Vuelo Doméstico
Actor: Pasajero
Descripción: este caso de uso permite a un pasajero reservar un vuelo entre dos ciudades nacionales…
Secuencia Básica:
1. El caso de uso inicia cuando el Actor decide reservar un vuelo doméstico
2. El sistema pide seleccionar las ciudades origen y destino del vuelo
3. El actor selecciona las ciudades origen y destino del vuelo
4. El sistema solicita las fechas de ida y de regreso del vuelo
5. El sistema valida la existencia de vuelos con las condiciones establecidas y pide seleccionar la tarifa
6. El actor selecciona la tarifa
7. El sistema genera y muestra un código de reserva y el caso de uso termina
Entre tanto, el caso de uso Reservar Vuelo Internacional puede ir así:
Caso de Uso: Reservar Vuelo Internacional
Actor: Pasajero
Descripción: este caso de uso permite a un pasajero reservar un vuelo cuya ciudad destino es de otro país…
Secuencia Básica:
1. El caso de uso inicia cuando el Actor decide reservar un vuelo internacional
2. El sistema pide seleccionar las ciudades origen y destino del vuelo
3. El actor selecciona las ciudades origen y destino del vuelo
4. El sistema solicita las fechas de ida y de regreso del vuelo
5. El sistema valida la existencia de vuelos con las condiciones establecidas, muestra las rutas disponibles (escalas intermedias) y pide seleccionar la ruta y tarifa de preferencia
6. El actor selecciona la ruta y la tarifa de su preferencia
7. El sistema pide seleccionar las condiciones especiales del vuelo
8. El sistema genera y muestra un código de reserva y el caso de uso termina
Poscondiciones: N/A
Requisitos Especiales: N/A
La diferencia entre uno y otro se nota en los pasos 5, 6 y 7. En este caso, el caso de uso padre, Reservar Vuelo puede contener exactamente la misma funcionalidad que Reservar Vuelo Doméstico y dejar sólo los pasos distintos en Reservar Vuelo Internacional. De esta manera se simplifica la especificación y el modelado del sistema.
También puede ocurrir que sea necesario agrupar dos o más casos de uso cuya funcionalidad, estructura y objetivo sean compartidos en un caso de uso puramente abstracto, también para efectos de simplificación del modelo. Como en la figura 10.
Figura 10: Diagrama parcial de casos de usos de un Sistema de Administración de Proyectos
Aquí, el caso de uso abstracto no contiene ninguna especificación funcional y se usa como “comodín”, quizás para relacionar los casos de uso hijos con uno o más casos de uso incluidos o de extensión. También para hacer el análisis y diseño de todos ellos al mismo tiempo (hacer una única realización de casos de uso, por ejemplo).
Aunque no está especificado, los casos de uso hijos pueden ser ejecutados por actores diferentes. También, si el caso de uso padre es abstracto, podría no tener actor relacionado. En esta última instancia, los hijos deberían tener asociado el actor que los ejecuta, necesariamente.
Mi recomendación final es que usemos la generalización de casos de uso como detallo en esta última alternativa. Para la primera forma, siempre podemos usar inclusión y hasta extensión.
Conclusiones
Un modelo es una abstracción de la realidad, una representación simplificada de algunos fenómenos del mundo real. En materia de sistemas de software, esos fenómenos se refieren a requisitos del software y la representación de los mismos se hace mediante actores, casos de uso y las relaciones entre aquellos y estos y entre cada uno de ellos.
La asociación, la generalización, la inclusión y la extensión son los cuatro tipos de relaciones entre estos elementos de los sistemas de información. Algunas de ellas se quedan en un plano estrictamente teórico o conceptual, en el sentido de que no tienen aplicación práctica, al menos, no una de valor para el modelador. Me refiero a la generalización que en lo que a casos de uso se refiere no tiene el sentido de provecho que tiene, por ejemplo, en un diagrama de clases o uno de objetos.
La asociación, por su parte, es la relación natural entre actores y casos de uso, su significado es directo y simple: este actor ejecuta o inicia este caso de uso. También, este actor entrega o recibe información de (interactúa con) este caso de uso. Más allá, la inclusión y la extensión constituyen un par de relaciones que despiertan emociones encontradas en la comunidad de analistas, ya sea porque tendemos a confundir su uso o porque nuestros paradigmas mentales (específicamente los de la orientación a objetos) no nos permiten verlas y usarlas con claridad expedita.
Estos son los temas que he tratado de dilucidar en este artículo. Son aspectos en los que todos debemos mejorar en aras de incrementar la calidad de los productos que desarrollamos.
¿Quiere Saber Más?
Para conocer más sobre especificación de casos de uso, podemos consultar [15] que sigue siendo, sino el mejor, uno de los muy buenos libros sobre el espinoso asunto de escribir casos de uso.
Para conocer más de modelado de casos de uso, relaciones de inclusión, extensión y generalización, podemos consultar [16], [17] y [18] cuyos autores concentran sus esfuerzos en explicar los distintos patrones que podemos encontrar al momento de modelar requisitos de software con casos de uso.
Como siempre, está el que considero el mejor libro sobre UML, patrones, análisis y diseño orientado a objetos y el proceso de desarrollo de software, todo en uno. Se trata del libro de Larman [19].
También está el libro origen de todo, el de los three amigos [20].
Fin.
[1] IBM. The Rational Unified Process V7.1.
[2] IBM. The Rational Unified Process version V7.1.
[15] Alistair Cockburn, “Writing Effective Use Cases”, Addison-Wesley, 21 feb. 2000.
[16] Mike O’Docherty, Object-Oriented Analysis & design, Understanding System Development With UML.” John Wiley & Sons. 2005.
[18] Kim Hamilton, Russell Miles. Learning UML 2.0. O'Reilly. April 2006.
[19] Graig Larman. applying-uml-and-patterns-an-introduction-to-object-oriented-analysis-and-design-and-the-unified-process-2nd-edition. 13 jul. 2001.
[20] Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide. 2nd-edition. May 29, 2005.
Lectura Fundamental Siguiente: Casos de Abuso
