El documento describe los diferentes tipos de modelos de requerimientos, incluyendo modelos basados en escenarios, datos e información, y clases. Explica que el modelo de requerimientos es la primera representación técnica de un sistema y permite visualizar el sistema desde diferentes puntos de vista. También cubre temas como la creación de casos de uso, diagramas de actividades, y el modelado basado en clases.

1. 7.Modelado de Requerimientos:
escenarios, información y clases.
Ramiro Estigarribia Canese

2. ¿Qué es el Modelo de Requerimientos?
➔ Es la primera representación técnica de un sistema.
➔ Utiliza una combinación de texto y diagramas para
ilustrar al sistema a construir, a fin de que sea fácil
de entender, revisar y corregir.
➔ Es importante porque permite visualizar al sistema
desde varios puntos de vista diferentes.

3. Resultados: Modelo de Requerimientos
➔ Da como resultado la especificación de las
características operativas y establece las restricciones
que limitan al software.
➔ Permite al profesional construir sobre los
requerimientos establecidos durante las tareas de
indagación y negociación.
➔ Se generan diversos Modelos de Requerimientos.

4. Tipos de Modelos de 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.

5. Filosofía: Modelo de Requerimientos.
La atención “se centra en Qué”:
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.

6. Reglas del Análisis de Requerimientos.
Arlow y Neustadt sugieren estas reglas prácticas:
1. 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. Retrasar las consideraciones de la infraestructura y
otros, 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.

7. ¿Qué es el Análisis del Dominio?
➔ Es la identificación de los requerimientos comunes,
para usarlo varias veces en múltiples proyectos.
➔ Esto mejora el tiempo para llegar al mercado y reduce
los costos de desarrollo.
➔ Estos se definen y clasifican en forma tal que puedan
reconocerse con facilidad.

8. Ejemplos de Diagramas.

10. Creación de un Caso de Uso
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?
Son preguntas que deben responderse si los casos de
uso han de tener algún valor como herramienta para
modelar los requerimientos.

11. ¿Sobre qué temas escribir?
1. Para comenzar se listan las funciones o actividades
realizadas por un actor específico.
2. Se obtienen de una lista de las funciones requeridas
del sistema.
3. Por medio de conversaciones con los participantes.
4. A partir de los diagramas de actividades
desarrollados como parte del modelado de los
requerimientos.

12. Entender un Caso de Uso.
Para entender por completo un caso de uso, es esencial
describir interacciones alternativas.
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?
El resultado la creación de un conjunto de escenarios
secundarios que forman parte del caso de uso original,
pero que representan comportamientos alternativos.

13. ¿Cuándo Graficar?
➔ En muchos casos, no hay necesidad de crear una
representación gráfica de un escenario.
➔ La representación visual facilita la comprensión.
➔ En tales casos, es posible
elegir de entre una amplia
variedad de modelos UML.

14. Diagrama de actividades
➔ El diagrama de actividad proporciona 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.

15. Diagrama de Actividades.

16. 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.

18. Atributos de los Datos
Los atributos de los datos definen las propiedades de un
objeto. Se usan para:
1. Nombrar una instancia del objeto de datos
2. 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.

19. 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.

20. Modelado Basado en Clases
➔ Se representan 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.

21. Identificación de las clases
➔ Al mirar una habitación, se observa un conjunto de
objetos físicos que se identifican fácilmente.
➔ Pero en 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”.
➔ Se determinan subrayando cada sustantivo.
Si la clase (sustantivo) se requiere para implementar
una solución, entonces forma parte del espacio de
solución.

22. 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.

23. Operaciones
Por 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.

24. Resumen y Conclusiones
➔ El objetivo del modelado de requerimientos es crear
varias representaciones que describen 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.