Fundamentos del Modelado UML: De Conceptos a Casos de Uso en Desarrollo de Software

Introducción: Claves en el Desarrollo de Sistemas de Información

Elementos fundamentales en el desarrollo de sistemas de información incluyen:

• Proceso
• Notación
• Herramientas

¿Qué es UML?

UML son las siglas de Unified Modeling Language (Lenguaje Unificado de Modelado).

Es un lenguaje de propósito general para el modelado orientado a objetos, impulsado por el OMG (Object Management Group).

UML combina notaciones provenientes desde diversas fuentes:

• Modelado Orientado a Objetos
• Modelado de Datos
• Modelado de Componentes
• Modelado de Flujos de Trabajo

Enfoques Orientados a Objetos Aglutinados por UML

UML integra y sintetiza diversos enfoques de modelado orientado a objetos, incluyendo las contribuciones de:

• Booch
• Odell
• Shlaer-Mellor
• Gamma et al. (Patrones de Diseño)
• Embley
• Fusion
• Harel (Statecharts)
• Jacobson (Casos de Uso)
• Meyer (Diseño por Contrato)
• Y otros.

Inconvenientes de UML

A pesar de su amplia adopción, UML presenta ciertos inconvenientes:

• Definición del proceso de desarrollo: UML en sí mismo no es una metodología de desarrollo; es un lenguaje de modelado. Requiere ser complementado con un proceso.
• Cobertura de especificación: No cubre todas las necesidades de especificación de un proyecto de software. Por ejemplo, no define la estructura o contenido de los documentos textuales (como manuales de usuario o especificaciones detalladas).
• Ejemplos aislados: A veces, los ejemplos proporcionados pueden ser demasiado específicos o no cubrir escenarios complejos de manera integral.
• Concentración de mercado: Existe una notable concentración de conceptos, técnicas y métodos en torno a UML y el OMG, lo que podría limitar la exploración de alternativas.

Diagramas UML

UML proporciona un conjunto de diagramas para visualizar, especificar, construir y documentar los artefactos de un sistema de software. Todos estos diagramas son, en esencia, modelos que representan diferentes perspectivas del sistema.

Tipos Principales de Diagramas UML:

• Diagrama de Casos de Uso: Muestra la funcionalidad del sistema desde la perspectiva del usuario.
• Diagrama de Clases: Describe la estructura del sistema mostrando sus clases, atributos, operaciones y las relaciones entre ellos.
• Diagrama de Objetos: Representa instancias de clases (objetos) y sus relaciones en un momento específico.

Diagramas de Comportamiento:

• Diagrama de Estados (o Máquina de Estados): Modela el comportamiento de un objeto a lo largo de su vida, mostrando los estados por los que pasa y las transiciones entre ellos.
• Diagrama de Actividad: Representa los flujos de trabajo o procesos del sistema, mostrando la secuencia de actividades.

Diagramas de Interacción (subconjunto de diagramas de comportamiento):

• Diagrama de Secuencia: Enfatiza el orden temporal de los mensajes intercambiados entre objetos.
• Diagrama de Colaboración (o Comunicación): Muestra las interacciones entre objetos organizadas alrededor de los objetos y sus enlaces.

Diagramas de Implementación:

• Diagrama de Componentes: Visualiza la organización y dependencias entre los componentes de software.
• Diagrama de Despliegue: Describe la configuración física del hardware y software del sistema.

(Todos estos diagramas son modelos que ayudan a comprender y diseñar el sistema)

Profundizando en los Diagramas de Casos de Uso

Los Diagramas de Casos de Uso son una técnica fundamental en UML para:

• Capturar información detallada sobre los servicios que un sistema debe proporcionar a su entorno (usuarios u otros sistemas).
• Aunque se utilizan ampliamente en el modelado orientado a objetos, su origen no es estrictamente OO. Son, primordialmente, una técnica para la captura y especificación de requisitos funcionales del sistema.

Definición y Características del Caso de Uso

Un Caso de Uso, popularizado por Ivar Jacobson, posee las siguientes características y propósitos:

• Describen, mediante secuencias de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario.
• Permiten definir claramente los límites del sistema y las interacciones (relaciones) entre el sistema y su entorno.
• Son descripciones de la funcionalidad del sistema que se mantienen independientes de la implementación tecnológica específica.
• Ofrecen una perspectiva diferente y complementaria a los Diagramas de Flujo de Datos (DFD) del Enfoque Estructurado.
• Cubren una carencia importante en métodos orientados a objetos previos (como OMT o Booch) en lo referente a la determinación y especificación de requisitos.
• Particionan el conjunto total de necesidades del sistema atendiendo a la categoría de usuarios (actores) que participan en cada uno.
• Deben ser redactados de forma que el usuario final pueda entenderlos fácilmente para facilitar su validación y asegurar que el sistema cumplirá con sus expectativas.

Actores en los Casos de Uso

Los actores representan roles que interactúan con el sistema. Se pueden clasificar en:

• Actores Principales: Personas que usan directamente el sistema para realizar sus tareas.
• Actores Secundarios: Personas que mantienen o administran el sistema (ej. administradores de sistemas, personal de soporte).
• Material Externo: Dispositivos o hardware imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados por el sistema (ej. sensores, impresoras especiales).
• Otros Sistemas: Sistemas externos con los que el sistema bajo desarrollo debe interactuar (ej. APIs de terceros, bases de datos externas).

Consideraciones importantes sobre los actores:

• Una misma persona física puede interpretar varios papeles, representados como actores distintos.
• El nombre del actor debe describir el rol desempeñado, no el nombre de una persona o departamento específico.

Determinación e Importancia de los Casos de Uso

La identificación y definición de los Casos de Uso se realiza mediante la observación y precisión, actor por actor, de las secuencias de interacción (escenarios) desde la perspectiva del usuario.

• Un escenario es una instancia particular de un caso de uso; representa una ruta específica a través del caso de uso.
• Los Casos de Uso son cruciales y intervienen durante todo el ciclo de vida del desarrollo de software.
• El proceso de desarrollo, idealmente, estará dirigido por los Casos de Uso (Use Case Driven Development), asegurando que el sistema construido satisfaga las necesidades funcionales identificadas.

Construcción de un Caso de Uso

Al construir un Caso de Uso, se deben seguir ciertas pautas:

• Debe ser simple, inteligible, claro y conciso.
• Generalmente, hay pocos actores asociados directamente a cada Caso de Uso.
• Preguntas clave para ayudar a definirlo:
  • ¿Cuáles son las tareas del actor?
  • ¿Qué información crea, guarda, modifica, destruye o lee el actor?
  • ¿Debe el actor notificar al sistema sobre cambios externos?
  • ¿Debe el sistema informar al actor sobre cambios internos relevantes?

La descripción detallada de un Caso de Uso típicamente comprende:

• Inicio: ¿Cuándo se inicia el caso de uso y qué actor lo desencadena?
• Fin: ¿Cuándo se considera que el caso de uso ha concluido y qué valor o resultado devuelve (si aplica)?
• Interacción Actor-Caso de Uso: ¿Qué mensajes o datos se intercambian entre el actor y el sistema durante la ejecución del caso de uso?
• Objetivo del Caso de Uso: ¿Qué meta específica busca alcanzar el actor al ejecutar este caso de uso?
• Cronología y Origen de las Interacciones: Secuencia temporal de los pasos y quién origina cada interacción.
• Repeticiones de Comportamiento: ¿Qué operaciones o secuencias de pasos pueden ser iteradas?
• Situaciones Opcionales o Alternativas: ¿Qué flujos de ejecución alternativos o variaciones pueden presentarse dentro del caso de uso (ej. manejo de errores, condiciones especiales)?