Tema 7: Modelado de Requisitos y Análisis

1. Resumen Ejecutivo

Esta sesión marca la transición entre la toma de requisitos (el "Qué") y el análisis del sistema (profundizar en el "Qué" estructurándolo para la solución). Se aborda primero una técnica "obsoleta" pero examinable (DFD) y luego se profundiza en el Proceso Unificado mediante las Clases de Análisis (Interfaz, Control, Entidad) y los Diagramas de Interacción (Secuencia y Comunicación), cuyo objetivo es validar con el cliente que hemos entendido la lógica del problema antes de diseñar la solución técnica.

2. Conceptos Clave

Dominio del Problema vs. Solución: División entre entender qué pasa (Requisitos/Análisis) y definir cómo se arregla técnicamente (Diseño/Implementación).
DFD (Diagrama de Flujo de Datos): Herramienta estructurada (NO UML) que modela el flujo de información a través de procesos.
Realización de Casos de Uso (Análisis): Descripción detallada de cómo interactúan los objetos para cumplir un caso de uso.
Clases de Análisis:
- Interfaz (Boundary): Interacción actor-sistema.
- Control: Lógica y orquestación.
- Entidad: Información/Datos persistentes.
Diagrama de Secuencia: Modela la interacción temporal de objetos mediante mensajes.

3. Desarrollo del Temario

3.1. Contexto Global: El Proceso de Ingeniería

El profesor utiliza un esquema mental recurrente para situar cada fase del proyecto.

Niveles de Abstracción:
- Requisitos y Análisis (El "¿QUÉ?"): Pertenecen al Dominio del Problema. Todo lo que se hace aquí mira "hacia arriba", hacia el cliente, para validar si hemos entendido su necesidad.
- Diseño e Implementación (El "¿CÓMO?"): Pertenecen al Dominio de la Solución. Miran "hacia abajo", hacia el equipo de desarrollo y la tecnología (Java, servidores, etc.).

Analogía del Profesor: "El primer día te tomas un café con el cliente y te cuenta su problema (nivel alto). Al final del viaje, le entregas código Java (nivel bajo). El Análisis es hacer 'zoom' en el problema sin llegar aún a la solución técnica pura."

3.2. Modelado Orientado al Flujo: DFD (Diagramas de Flujo de Datos)

Aunque es una técnica de las metodologías estructuradas (antiguas), sigue apareciendo en el temario y en la bibliografía de Pressman.

¡OJO AL DATO! - Pregunta de Examen: * ¿Es el DFD una herramienta de UML? NO. El DFD pertenece al paradigma estructurado, NO es UML.

Características del DFD: * Enfoque: Entrada Proceso Salida. * Sintaxis Básica: * Rectángulos: Entidades externas / Objetos de datos. * Círculos (Burbujas): Procesos o transformaciones. * Líneas paralelas: Almacenamiento de datos (Capa de persistencia/BD). * Flechas: Flujo de datos.

Niveles de Detalle (Abstracción): El DFD permite "explotar" burbujas para ver más detalle: 1. Nivel 0 (Diagrama de Contexto): Todo el sistema es una sola burbuja. Muestra las interacciones con el exterior. 2. Nivel 1: Esa burbuja se rompe en las funcionalidades principales. 3. Nivel 2: Se detalla una funcionalidad específica (ej. "Vigilar Sensores").

3.3. Análisis en el Proceso Unificado (Orientación a Objetos)

Aquí entramos en la metodología estándar actual. El objetivo es transformar los Casos de Uso (que son descripciones funcionales) en una estructura de objetos preliminar.

Las Clases del Análisis (Estereotipos)

A diferencia del diseño final, en el análisis usamos tres tipos de clases conceptuales para que el cliente entienda la estructura sin tecnicismos:

Interfaz (Boundary) |-O:
- Interacciones entre el actor y el sistema (Ventanas, APIs, Pantallas).
- Representa la capa de presentación.
Control O with arrow:
- Lógica del negocio. Procesa la información. Es el "cerebro" del caso de uso.
- Representa el comportamiento.
Entidad _O_:
- Información manejada por el sistema (Datos). Suelen ser persistentes (Base de Datos).
- Representa la información.

Ejemplo: En un "Alta de Usuario", la clase Interfaz es el formulario web, la clase Control valida que el DNI sea correcto y no esté duplicado, y la clase Entidad es el registro del usuario guardado en la base de datos.

3.4. Realización de Casos de Uso - Análisis

Una "realización" explica cómo se ejecuta un caso de uso utilizando las clases de análisis identificadas. Para ello usamos diagramas de interacción.

A. Diagramas de Secuencia (Nivel Análisis)

Muestran la interacción entre objetos a lo largo del tiempo. * Eje vertical: El tiempo avanza hacia abajo. * Mensajes: * Síncrono (punta llena): Espera respuesta. * Asíncrono (punta abierta): No espera respuesta (ej. "lanza y olvida"). * Retorno (punteada): Devuelve un valor.

Fragmentos Combinados (Estructuras de control visuales): * alt: Alternativa (If/Else). Ocurre una cosa U otra. * opt: Opcional (If sin else). Ocurre o no ocurre. * loop: Bucle (For/While). Repetición. * ref: Referencia a otro diagrama (como una llamada a subrutina o un include en casos de uso).

B. Diagramas de Comunicación

Muestran la misma información que los de secuencia, pero centrados en quién habla con quién (los enlaces) en lugar del tiempo. * Son útiles para ver el acoplamiento entre objetos, aunque es más difícil seguir el orden de los mensajes (hay que leer los números: 1, 1.1, 2...).

3.5. Paquetes de Análisis

Organizan los artefactos (clases) basándose en los requisitos funcionales. * Se busca Alta Cohesión (clases relacionadas juntas) y Bajo Acoplamiento (pocas dependencias entre paquetes). * Permiten verificar si la arquitectura inicial planteada es correcta o si un paquete ha quedado demasiado grande y necesita dividirse.

4. Preguntas de Autoevaluación

¿Pertenece el Diagrama de Flujo de Datos (DFD) al estándar UML?
- Respuesta: No, es una herramienta de las metodologías estructuradas, aunque se sigue estudiando por su uso legado.
En el esquema de "Big Picture" del profesor, ¿hacia quién está orientado el trabajo realizado en la fase de Análisis?
- Respuesta: Hacia el cliente (hacia arriba), para validar que se ha entendido el problema (Dominio del Problema).
¿Cuáles son los tres estereotipos de clases de análisis y qué representa cada uno?
- Respuesta: Interfaz (Presentación/Interacción), Control (Lógica/Comportamiento) y Entidad (Datos/Información).
En un diagrama de secuencia, ¿cuál es la diferencia entre un fragmento alt y un fragmento opt?
- Respuesta: alt implica caminos alternativos excluyentes (como un if/else), mientras que opt implica un comportamiento que puede ejecutarse o no (como un if sin else).
¿Qué vista arquitectónica agrupa las clases basándose en la funcionalidad del sistema?
- Respuesta: Los Paquetes de Análisis (o paquetes de servicio).