6.Modelado de Requerimientos:Escenarios y Clases.

Ramiro Estigarribia Canese

El Modelo de Requerimientos.➔ La I.S. comienza con una serie de tareas conducen

a la especificación de los requerimientos. ➔ El modelo de requerimientos es la primera

representación técnica de un sistema.➔ Utiliza una combinación de texto y diagramas para

ilustrarlos, a fin de que sea fácil de entender, revisar, corregir, completar y hacer congruente.

Análisis de los Requerimientos➔ El análisis de los requerimientos da como resultado

la especificación de las características operativas del software, indica la interfaz y establece las restricciones que limitan al software.

➔ El análisis de los requerimientos permite al profesional construir sobre los requerimientos básicos establecidos durante las tareas de concepción, indagación y negociación, que son parte de la ingeniería de los requerimientos (véase el capítulo 5)

Tipos de Modelosde Requerimientos.1. Modelos basados en el escenario desde el punto

de vista de distintos “actores” del sistema.2. Modelos de datos, que ilustran el dominio de

información del problema.3. Modelos orientados a clases, que representan

clases orientadas a objetos y sus colaboraciones.4. Modelos orientados al flujo, que representa cómo

se transforman los datos.5. Modelos de comportamiento, a consecuencia de

“eventos” externos.

Modelado de Requerimientos. Filosofía.Durante el modelado de requerimientos la atención “se centra en Qué, y no en Cómo”:1. ¿Qué interacción del usuario ocurre?2. ¿Qué objetos manipula el sistema?3. ¿Qué funciones debe realizar el sistema?4. ¿Qué comportamientos tiene el sistema? 5. ¿Qué interfaces se definen? 6. ¿Qué restricciones son aplicables?El experto debe modelar “lo que se sabe” y usar el modelo como base para un diseño que tendrá incrementos futuros.

Modelo de Requerimientos.Objetivos.1. Describir lo que requiere el cliente.2. Establecer una base el diseño del software.3. Definir un conjunto de requerimientos que puedan

validarse una vez terminado el software.

El modelo de análisis es un puente entre la descripción en el nivel del sistema que se centra en la funcionalidad del negocio que se logra con la aplicación de software, hardware, datos, personas y un diseño de software.

Reglas prácticas del análisisArlow y Neustadt sugieren estas reglas prácticas:1. Debe centrarse en los requerimientos que sean

visibles dentro del problema. 2. El nivel de abstracción debe ser elevado:

“No se empantane en los detalles”.3. Hay que retrasar las consideraciones de la

infraestructura y otros modelos no funcionales hasta llegar a la etapa del diseño.

4. Mantener el modelo tan sencillo como se pueda. No genere diagramas adicionales si no agregan nueva información.

Análisis del Dominio de SW➔ Es frecuente que existan patrones que se repiten

en muchas aplicaciones dentro de un dominio de negocio específico.

➔ Si éstos se definen y clasifican en forma tal que puedan reconocerse y aplicarse para resolver problemas comunes: la creación del modelo del análisis será más eficiente.

➔ Esto mejora el tiempo para llegar al mercado y reduce los costos de desarrollo.

¿Qué es el Análisis del Dominio de SW?➔ Es la identificación, análisis y especificación de los

requerimientos comunes, a partir de un dominio de aplicación específica, normalmente para usarlo varias veces en múltiples proyectos.

➔ La meta del análisis del dominio es clara: encontrar o crear aquellas clases o patrones de análisis que sean aplicables en lo general, de modo que puedan volverse a usar.

Modelado Basado en Escenarios.➔ Aunque el éxito de un sistema se mide de muchas

maneras, la satisfacción del usuario ocupa el primer lugar de la lista.

➔ Si se entiende cómo desean interactuar los usuarios finales con un sistema, el equipo del software estará mejor preparado para caracterizar adecuadamente los requerimientos.

➔ Entonces, el modelado de los requerimientos con UML comienza con la creación de escenarios en forma de casos de uso, diagramas de actividades y diagramas de canales.

Creación de un caso preliminar de usoEn el capítulo-5 se dijo que un caso de uso describe en lenguaje claro un escenario específico desde el punto de vista de un actor definido. Pero: ¿Cómo se sabe sobre qué escribir, cuántoescribir sobre ello, cuán detallada hacer la descripción y cómo organizarla? Son preguntas que deben responderse si los casos de uso han de tener algún valor como herramienta para modelar los requerimientos.

Casos de Uso.¿Sobre qué escribir?➔ Para comenzar se listan las funciones o actividades

realizadas por un actor específico. ➔ Éstas se obtienen de una lista de las funciones

requeridas del sistema, por medio de conversaciones con los participantes o con la evaluación de los diagramas de actividades desarrollados como parte del modelado de los requerimientos.

Mejora de un caso de uso.Para entender por completo un caso de uso, es esencial describir interacciones alternativas. Después se evalúa, planteando las preguntas:1. ¿El actor puede emprender otra acción?2. ¿Es posible que el actor encuentre algún de error? 3. ¿Es posible que el actor encuentre otro

comportamiento? En ese caso, ¿cuál sería?Las respuestas dan como resultado la creación de un conjunto de escenarios secundarios que forman parte del caso de uso original, pero que representan comportamientos alternativos.

¿Cuándo Graficar?➔ En muchos casos, no hay necesidad de crear

una representación gráfica de un escenario. ➔ La representación facilita la comprensión,

en particular cuando el escenario es complejo.

➔ En tales casos, es posible elegir de entre una amplia variedad de modelos UML.

Diagrama de actividades➔ El diagrama de actividad UML enriquece el caso de

uso al proporcionar una representación gráfica del flujo de interacción dentro de un escenario específico.

➔ Un diagrama de actividades es similar a uno de flujo, y utiliza rectángulos redondeados para denotar una función específica del sistema, flechas para representar flujo a través de éste, rombos de decisión para ilustrar una ramificación de las decisiones y líneas continuas para indicar que están ocurriendo actividades en paralelo.

Diagrama de Actividades.

Diagramas de canales (swimlane)➔ El diagrama de canal de UML es una variación útil

del diagrama de actividades y permite representar el flujo de actividades descritas por el caso de uso; al mismo tiempo, indica qué actor es responsable de la acción descrita por un rectángulo de actividad.

➔ Las responsabilidades se representan con segmentos paralelos que dividen el diagrama en forma vertical, como los canales o carriles de una piscina.

Atributos de los datosLos atributos de los datos definen las propiedades de un objeto y tienen una de tres diferentescaracterísticas. Se usan para: 1. Nombrar una instancia del objeto de datos2. Describir la instancia 3. Hacer referencia a otra instancia en otra tabla.

Además, debe definirse como identificador uno o más de los atributos. Los valores para los identificadores son únicos.

Relaciones➔ Los objetos de datos están conectados entre sí de

diferentes maneras. ➔ Considere dos objetos de datos, persona y auto. ➔ Se establece una conexión entre persona y auto

porque ambos objetos están relacionados.

Modelado Basado en Clases➔ El modelado basado en clases representa los objetos

que manipulará el sistema, las operaciones (también llamadas métodos o servicios), las relaciones (algunas de ellas jerárquicas) y las colaboraciones.

➔ Los elementos incluyen las clases, atributos, operaciones, clase-responsabilidad-colaborador (CRC), diagramas de colaboración y paquetes.

Identificación de las clases ➔ Al mirar una habitación, se observa un conjunto de

objetos físicos que se identifican, clasifican y definen fácilmente.

➔ Pero cuando se “ve” el espacio del problema de una aplicación de software, es más difícil.

➔ Se comienza por identificar las clases mediante el análisis de los escenarios y la ejecución de un “análisis gramatical”.

➔ Las clases se determinan subrayando cada sustantivo. Si la clase (sustantivo) se requiere para implementar una solución, entonces forma parte del espacio de solución.

Especificación de atributos➔ Los atributos describen una clase que ha sido

seleccionada para incluirse en el modelo de requerimientos (en el contexto del problema).

➔ Por ejemplo, si se fuera a construir un sistema que analiza estadísticas de jugadores de fútbol, los atributos de la clase Jugador serían muy distintos de los que tendría la misma clase cuando se usará en el contexto del sistema de ventas de entradas.

➔ En la primera, atributos tales como Goles y Pases son importantes.

Definición de las OperacionesPor lo general se dividen en cuatro categorías principales: 1. Operaciones que manipulan datos:

agregan, eliminan, seleccionan, etc.2. Operaciones que realizan un cálculo.3. Operaciones que preguntan sobre el estado.4. Operaciones que vigilan un objeto en cuanto a la

ocurrencia de un evento de control.Una operación debe tener “conocimiento” de la naturaleza de los atributos.

Modelado (CRC)➔ El modelado clase-responsabilidad-colaborador

(CRC) proporciona una manera sencilla de y organizar las clases que son relevantes.

➔ En la parte superior de la tarjeta se escribe el nombre de la clase, en la parte izquierda del cuerpo se enlistan las responsabilidades de la clase y en la derecha, los colaboradores.

➔ En realidad, el modelo CRC hace uso de tarjetas índice reales o virtuales. El objetivo es desarrollar una representación organizada de las clases.

Modelado (CRC)

Resumen y Conclusiones➔ El objetivo del modelado de requerimientos es

crear varias representaciones que describan lo que necesita el cliente, y definir un conjunto de requerimientos que puedan ser validados.

➔ Los modelos basados en el escenario ilustran los requerimientos del software desde el punto de vista del usuario.

➔ El caso de uso es el principal elemento del modelado y se obtiene durante la indagación de los requerimientos.