7.modelado de los requerimientos escenarios y clases

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

Transcript of 7.modelado de los requerimientos escenarios y clases

Page 1: 7.modelado de los requerimientos  escenarios y clases

7.Modelado de Requerimientos:escenarios, información y clases.

Ramiro Estigarribia Canese

Page 2: 7.modelado de los requerimientos  escenarios y clases

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

Page 3: 7.modelado de los requerimientos  escenarios y clases

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.

Page 4: 7.modelado de los requerimientos  escenarios y clases

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.

Page 5: 7.modelado de los requerimientos  escenarios y clases

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.

Page 6: 7.modelado de los requerimientos  escenarios y clases

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.

Page 7: 7.modelado de los requerimientos  escenarios y clases

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

Page 8: 7.modelado de los requerimientos  escenarios y clases

Ejemplos de Diagramas.

Page 9: 7.modelado de los requerimientos  escenarios y clases
Page 10: 7.modelado de los requerimientos  escenarios y clases

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.

Page 11: 7.modelado de los requerimientos  escenarios y clases

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

Page 12: 7.modelado de los requerimientos  escenarios y clases

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.

Page 13: 7.modelado de los requerimientos  escenarios y clases

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

Page 14: 7.modelado de los requerimientos  escenarios y clases

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.

Page 15: 7.modelado de los requerimientos  escenarios y clases

Diagrama de Actividades.

Page 16: 7.modelado de los requerimientos  escenarios y clases

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.

Page 17: 7.modelado de los requerimientos  escenarios y clases
Page 18: 7.modelado de los requerimientos  escenarios y clases

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.

Page 19: 7.modelado de los requerimientos  escenarios y clases

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.

Page 20: 7.modelado de los requerimientos  escenarios y clases

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.

Page 21: 7.modelado de los requerimientos  escenarios y clases

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.

Page 22: 7.modelado de los requerimientos  escenarios y clases

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.

Page 23: 7.modelado de los requerimientos  escenarios y clases

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.

Page 24: 7.modelado de los requerimientos  escenarios y clases

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.