Skip to content

Tema 6: Modelado de Requisitos y Análisis

📝 Resumen Ejecutivo

Esta sesión establece el puente entre la toma de requisitos (el "¿QUÉ?") y el diseño/implementación (el "¿CÓMO?"). Se centra en el Modelado Basado en Escenarios para formalizar las necesidades del usuario en Casos de Uso y, posteriormente, transformarlos en un Modelo de Análisis. Este último introduce las Clases de Análisis (Entidad, Control e Interfaz) como una abstracción técnica previa a la codificación para minimizar errores arquitectónicos.

🔑 Conceptos Clave

  • Dominio del Problema vs. Solución: La transición de entender la necesidad del usuario (Requisitos/Análisis) a definir cómo se construirá (Diseño/Implementación).
  • Escenario: Una instancia específica o camino (flujo) dentro de una funcionalidad, incluyendo situaciones de éxito y error.
  • Caso de Uso (CU): Unidad funcional básica que agrupa todos los escenarios de una funcionalidad específica.
  • Modelo de Análisis: Representación técnica pero abstracta del sistema. Evita detalles de implementación (como el lenguaje de código) pero define la estructura lógica.
  • Clases de Análisis (ECB):
    • Entidad: Información persistente (datos).
    • Interfaz (Boundary): Interacción con actores (pantallas, APIs).
    • Control: Lógica de negocio y orquestación del proceso.

📖 Desarrollo del Temario

1. El Proceso de Ingeniería del Software

El desarrollo no es un salto directo de la idea al código java. Sigue un flujo lógico, aunque iterativo:

  1. Requisitos (El QUÉ): Enfocado en el Dominio del Problema. Se habla el idioma del cliente.
  2. Análisis: Refinamiento técnico de los requisitos. Se estructura la solución lógica.
  3. Diseño (El CÓMO): Enfocado en el Dominio de la Solución. Se deciden tecnologías y arquitecturas específicas.
  4. Implementación: Codificación (ej. Java).

¡OJO AL DATO!: Aunque el diagrama parezca una cascada, el proceso recomendado es Iterativo e Incremental. No necesitas terminar todos los requisitos para empezar el análisis. Se trabaja por "piezas" o funcionalidades pequeñas que atraviesan todas las fases.

2. Modelado Basado en Escenarios (Conducido por Casos de Uso)

El objetivo es formalizar las historias de usuario en algo estructurado.

A. Identificar Actores

Un actor no es solo una persona; es cualquier entidad externa que interactúa con el sistema. * Tipos: Usuarios humanos, otros sistemas (ej. pasarela de pago), dispositivos. * Preguntas clave para identificarlos: * ¿Quién usa el sistema? * ¿Quién lo administra? * ¿Con qué otros sistemas interactúa?

B. Identificar Escenarios

Un escenario es una "historia" específica sobre cómo se usa el sistema. * Tipos: Escenarios actuales (As-is), Futuros (Visionary), de Evaluación y de Entrenamiento. * Importancia: Ayudan a descubrir excepciones y flujos alternativos.

Ejemplo Verbal del Profesor (Sistema de Matriculación): Imaginemos el caso de uso "Matricular Alumno". Los escenarios serían: * Escenario 1: Alumno nuevo se registra y matricula (Éxito). * Escenario 2: Alumno antiguo añade asignatura (Éxito). * Escenario 3: Alumno intenta matricularse pero tiene pagos pendientes (Excepción/Error). * Escenario 4: Pago con tarjeta fallido.

Nota: El cliente suele pensar solo en el "camino feliz". Es labor del analista desglosar los escenarios de error (excepciones).

C. Refinar Casos de Uso

Un Caso de Uso agrupa todos los escenarios de una funcionalidad. * Relaciones: Se deben identificar si un CU incluye a otro (Inclusión) o lo extiende (Extensión). * Ejemplo: "Matricularse" puede incluir "Realizar Pago". * Requisitos No Funcionales: En esta fase se detectan restricciones (ej. "Solo se aceptan pagos con tarjeta, no PayPal").

3. Del Requisito al Modelo de Análisis

Una vez tenemos los Casos de Uso, no codificamos inmediatamente. Creamos el Modelo de Análisis para asegurar que entendemos la arquitectura lógica.

Estructura Jerárquica del Análisis:

  1. Modelo de Análisis: La visión global.
  2. Paquetes de Análisis: Agrupaciones lógicas de funcionalidades.
  3. Realización de Casos de Uso: Cómo colaboran las clases para cumplir un CU.
  4. Clases de Análisis: Los ladrillos básicos.

4. Clases de Análisis (Tipología ECB)

Esta es la parte más crítica de la sesión. Las clases de análisis no son código todavía, son conceptos. Se dividen en tres tipos fundamentales:

1. Interfaz (Boundary / Presentación) ├─○

  • Definición: Maneja la interacción entre los actores y el sistema.
  • Función: Captura datos y muestra resultados.
  • Ejemplo: Formulario web de matriculación, Pantalla de Login, API endpoint para el banco.

2. Control (Comportamiento) ↺

  • Definición: Representa la lógica de negocio, el "cerebro" del caso de uso.
  • Función: Orquesta. No guarda datos permanentemente, sino que procesa, valida y calcula.
  • Ejemplo: GestorMatricula. Verifica si el alumno cumple los requisitos, calcula el precio total, valida que no haya solape de horarios.

3. Entidad (Información) ◯__

  • Definición: Representa la información persistente y de larga duración.
  • Función: Almacena datos del dominio del problema.
  • Características: Suelen tener atributos de alto nivel, pero en esta fase no definimos tipos de datos exactos (int, string) ni métodos complejos, solo conceptos.
  • Ejemplo: Alumno, Matricula, Asignatura.

Ejemplo de Realización de Análisis (Matriculación): Para cumplir el Caso de Uso "Matricular": 1. El Actor (Estudiante) interactúa con la Interfaz (Pantalla de Matriculación). 2. La Interfaz pasa los datos al Control (Gestor de Matrículas). 3. El Control verifica datos consultando la Entidad (Alumno) y crea una nueva Entidad (Matrícula).

5. Modelo de Dominio (Clases Entidad)

Es un diagrama de clases conceptual. * Objetivo: Mostrar cómo se relacionan los datos entre sí. * Cardinalidad (\(0..1\), \(1..*\)): Es vital definir cuántos elementos se relacionan. * Ejemplo: Un Alumno puede tener \(1..*\) (muchas) Matrículas. Una Matrícula pertenece a \(1\) Alumno. * Sin Métodos: En análisis, las clases entidad rara vez muestran métodos (operaciones), solo atributos conceptuales.

🧠 Preguntas de Autoevaluación

  1. ¿Cuál es la diferencia principal entre el modelo de requisitos y el modelo de análisis?

    • Respuesta: El modelo de requisitos habla el lenguaje del cliente (necesidades, "¿Qué?"), mientras que el modelo de análisis estructura esas necesidades en un lenguaje técnico lógico (clases, paquetes) previo al diseño.

  2. En el ejemplo de matriculación, si el sistema valida que el alumno no tenga deudas previas antes de inscribirlo, ¿qué tipo de clase de análisis realiza esta validación?

    • Respuesta: Una clase de Control. Es la encargada de la lógica de negocio y validaciones.

  3. ¿Por qué es importante identificar escenarios de "excepción" o "fracaso" y no solo los de éxito?

    • Respuesta: Porque los desarrolladores necesitan saber cómo debe comportarse el sistema cuando algo sale mal (ej. pago rechazado) para evitar errores no controlados en la implementación.

  4. Verdadero o Falso: En la fase de análisis debemos definir exactamente si un atributo es String, Integer o Boolean.

    • Respuesta: Falso. En el análisis se define el concepto (ej. "nombre", "fecha"). El tipo de dato exacto se suele definir en la fase de Diseño.