Ingeniería de Software

Modelado de Requerimientos
(Escenarios, Información y Clase de Análisis)
¿Que 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.

2
 Análisis de Requerimiento
 El análisis de los requerimientos da como
resultado la especificación de las
características operativas del software

 Permite al profesional construir sobre los

requerimientos establecidos durante las
tareas de indagación y negociación. 

 Se generan diversos Modelos de

Requerimientos.
3
 Tipos de Modelos de Requerimientos
  Modelos basados en el escenario desde el punto
de vista de distintos “actores” del sistema

 Modelos de datos, que ilustran el dominio de

información del problema. 

 Modelos orientados a clases, que representan

clases orientadas a objetos y sus
colaboraciones. 

4
 Tipos de Modelos de Requerimientos
   Modelos orientados al flujo, que
representa cómo se transforman los
datos.

 Modelos de comportamiento, a
consecuencia de “eventos” externos.

5
 Filosofía Modelo de Requerimientos

La atención “se centra en Qué no en Como”

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?

6
Filosofía Modelo de Requerimientos
 El experto debe modelar “lo que se
sabe” y usar el modelo como base para
un diseño que tendrá incrementos
futuros.

7
 Reglas prácticas del análisis
 Centrarse en los requerimientos que sean
visibles dentro del problema
 El nivel de abstracción debe ser elevado
 Retrasar las consideraciones de la
infraestructura y otros, hasta llegar a la
etapa del diseño
 Mantener el modelo tan sencillo como se
pueda.

8
 ¿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.

9
 Creación de 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.

10
 ¿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.

UNPSJB - 2005 Ingeniería de Software - Clase 3 11

 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?

UNPSJB - 2005 Ingeniería de Software - Clase 3 12

 Entender un Caso de Uso
 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.

UNPSJB - 2005 Ingeniería de Software - Clase 3 13

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

UNPSJB - 2005 Ingeniería de Software - Clase 3 14

 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.

UNPSJB - 2005 15
Diagrama de actividades

16
Diagramas de canales (swimlane)
 El diagrama de canal de UML es una
variación útil del diagrama de
actividades

  Las responsabilidades se representan

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

17
Diagramas de canales

Ingeniería de Software - Clase 3 18

 Atributos de los Datos
 Definen las propiedades de un objeto
 Se usan para:
 Nombrar una instancia del objeto de datos

 Describir la instancia

 3. Hacer referencia a otra instancia en otra

tabla. 

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
  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). 

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

24
 Resumen y conclusión
 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.

25