Ingeniería del Software

1. 6.Modelado de Requerimientos:
Escenarios y Clases.
Ramiro Estigarribia Canese

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

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

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

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

7. Reglas prácticas del análisis
Arlow 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.

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

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

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

12. Creación de un caso
preliminar de uso
En 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ánto
escribir 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.

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

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

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

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

18. Diagrama de Actividades.

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

21. Atributos de los datos
Los atributos de los datos definen las propiedades de
un objeto y tienen una de tres diferentes
características. 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.

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

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

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

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

26. Definición de las
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.

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

28. Modelado (CRC)

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