Modelado de los requerimientos: escenarios, informacion y clases de analisis
mapa
1. Tipos de modelo
1.1. •Modelos basados en el escenario de los requerimientos 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 (atributos y operaciones) y la manera en la que las clases colaboran para cumplir con los requerimientos del sistema. •Modelos orientados al flujo, que representan los elementos funcionales del sistema y la manera como transforman los datos a medida que se avanza a través del sistema. •Modelos de comportamiento, que ilustran el modo en el que se comparte el software como consecuencia de “eventos” externos. •El modelo de requerimientos (y la especificación de requerimientos de software) brinda al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software.
1.1.1. Objetivos y Filosofia General
1.1.1.1. Estas realidades hablan a favor de un enfoque iterativo para el análisis y el modelado de los requerimientos. El analista debe modelar lo que se sabe y usar el modelo como base para el diseño del incremento del software y debe lograr tres objetivos principales: 1) Describir lo que requiere el cliente. 2) Establecer una base para la creación de un diseño de software. 3) Definir un conjunto de requerimientos que puedan validarse una vez construido el software.
2. Reglas Prácticas del Análisis
2.1. EL MODELO DEL ANÁLISIS • El modelo debe centrarse en los requerimientos que sean visibles dentro del problema o dentro del dominio del negocio. El nivel de abstracción debe ser relativamente elevado. • Cada elemento del modelo de requerimientos debe agregarse al entendimiento general de los requerimientos del software y dar una visión del dominio de la información, de la función y del comportamiento del sistema. • Debe minimizarse el acoplamiento a través del sistema. Es importante representar las relaciones entre las clases y funciones. • Cada actor tiene su propio uso para el modelo. Por ejemplo, los participantes de negocios deben usar el modelo para validar los requerimientos; los diseñadores deben usarlo como pase para el diseño; el personal de aseguramiento de la calidad lo debe emplear como ayuda para planear las pruebas de aceptación. • Mantener el modelo tan sencillo como se pueda. No genere diagramas adicionales si no agregan nueva información. No utilice notación compleja si basta una sencilla lista.
2.1.1. Análisis de Dominio
2.1.1.1. Más importante aún es que la probabilidad de aplicar patrones de diseño y componentes de software ejecutable se incrementa mucho, esto mejora el tiempo para llegar al mercado y reduce los costos de desarrollo. El análisis del dominio del software 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 dentro del dominio de la aplicación, la identificación, análisis y especificación de capacidades comunes y reutilizables dentro de un dominio de aplicación específica en términos de objetos y clases. Ejemplo. el papel del analista del dominio es similar al de un maestro herrero en un ambiente de manufactura pesada. El trabajo del herrero es diseñar y fabricar herramientas que utilicen muchas personas que hacen trabajos similares pero no necesariamente iguales.
3. Enfoques del modelado de requerimientos
3.1. Se considera que los datos y los procesos que los transforman son entidades separadas los objetos de datos se modelan de modo que se definan sus atributos y relaciones, los procesos que manipulan a los objetos de datos se modelan en forma que se muestre cómo transforman a los datos a medida que los objetos que se corresponden con ellos fluyen por el sistema.
3.1.1. El modelado del análisis lleva a la obtención de cada uno de estos elementos de modelado. Sin embargo, el contenido específico de cada elemento (por ejemplo, los diagramas que se emplean para construir el elemento y el modelo) tal vez difiera de un proyecto a otro.
4. Introducción
4.1. Este modelado de requerimientos utiliza una combinación de texto y diagramas para ilustrarlos en forma que sea relativamente fácil de entender y, más importante, de revisar para corregir, completar y que a la vez tenga coherencia.
5. ¿Quién lo hace?
5.1. Un ingeniero de software (a veces llamado “analista”) construye el modelo con el uso de los requerimientos recabados del cliente.
6. Modelado basado en Escenarios
6.1. La satisfacción del usuario ocupa el primer lugar de la lista. Si se entiende cómo desean interactuar los usuarios finales (y otros actores) con un sistema, el modelado de los requerimientos con Lenguaje unificado modelado comienza con la creación de escenarios en forma de casos de uso, diagramas de actividades y diagramas tipo carril de natación.
7. Escritura de un caso de uso formal
7.1. El objetivo en contexto indica el alcance general del caso de uso.
7.1.1. La pre-condición describe lo que se sabe que es verdadero antes de que inicie el caso de uso. El disparador (o trigger) identifica el evento o condición que “hace que comience el caso de uso”. El escenario en lista las acciones específicas que requiere el actor, y las respuestas apropiadas del sistema. Las excepciones identifican las situaciones detectadas cuando se mejora el caso de uso preliminar. Pueden incluirse o no encabezados adicionales y se explican por sí mismos en forma razonable. En muchos casos, no hay necesidad de crear una representación gráfica de un escenario de uso.