Construcción del modelo de análisis

El objetivo del modelo de análisis es describir los dominios requeridos de información, funcionamiento y comportamiento para un sistema basado en computadoras.

El modelo cambia en forma dinámica conforme los ingenieros de software aprenden más acerca del sistema que se va a construir y los interesados entienden mejor lo necesitan. Por esta razón el modelo de análisis es una representación de los requisitos en un momento determinado , por lo que se espera que este cambie.

Conforme el modelo de análisis evoluciona, ciertos elementos se volverán relativamente estables, por lo que lo que proporcionaran una base sólida para las tareas de diseño que siguen, sin embargo, otros elementos del modelo pueden ser más volátiles, lo que indicara que el cliente aun no entiende por completo los requisitos para el sistema.

El modelo de análisis y los métodos utilizados para construirlo se describen con detalle en el capítulo 8. En las secciones siguientes se presenta una breve visión general.

Elementos del modelo de análisis

Existen muchas maneras de buscar los requisitos para un sistema basado en computadora. Algunas personas involucradas con el software dicen que lo mejor es seleccionar un modo de representación (por ejemplo, el caso de uso) y aplicarlo sin tomar en cuenta todos los modos restantes. Otros profesionales creen que resulta valioso utilizar varios modos de representación para mostrar el modelo de análisis. Las diferentes formas de representación obligan al equipo de software a considerar los requisitos desde distintos puntos de vista, un enfoque que tiene mayores probabilidades de descubrir omisiones, inconsistencias y ambigüedades.

Los elementos específicos del modelo de análisis los determina el método de modelado que se utilice. Sin embargo, existe un conjunto de elementos genéricos común a la mayoría de los modelos de análisis:

Elementos basados en escenarios. El sistema se describe, desde el punto de vista del usuario, por medio de un enfoque basado en escenarios. Por ejemplo, los casos de usos básicos y sus correspondientes diagramas de caso de uso evolucionan para convertirse en casos de uso más elaborados basados en plantillas.

Los elementos del modelo de análisis basados en escenarios con frecuencia Son los primeros que se desarrollan durante la elaboración del modelo. Por tal motivo sirven como una entrada para la creación de otros elementos de modelado.

Un enfoque algo diferente dentro del modelado basado en escenarios muestra las actividades o funciones que han sido definidas como parte de la tarea de obtención de requisitos. Estas funciones existen dentro de un contexto de procesamiento. Esto es, la secuencia de actividades (también se pueden utilizar los términos funciones u operaciones) que describe el procesamiento dentro de un contexto limitado se define como parte del modelo de análisis. Como la mayoría de los elementos del modelo de análisis (y otros modelos de la ingeniería de software), las actividades (funciones) se pueden representar en muchos grados diferentes de abstracciones. Los modelos en esta categoría pueden definirse de manera iterativa. Cada iteración proporciona detales adicionales del procesamiento.  Como un ejemplo. Se presenta un diagrama de actividad UML para la obtención de requisitos. Se muestran tres niveles de elaboración.

El diagrama de actividad es bastante parecido al diagrama de flujo: un diagrama grafico para representar las secuencias y lógica del flujo de control.

Elementos basados en clases. Cada escenario de uso implica un conjunto de “objetos” que se manipulan mientras un actor interactúa con el sistema. Estos objetos se clasifican en clases: una colección de clases con atributos similares y comportamientos en común. Por ejemplo, se puede usar un diagrama de clase para mostrar una clase de Sensor para la función de seguridad de Hogar Seguro. Obsérvese que el diagrama lista los atributos de los sensores (por ejemplo, nombre/id, tipo) y las operaciones [ por ejemplo, identificar (), habilitar ()] que pueden aplicarse para modificar dichos atributos. Además de los diagramas de clase, otros elementos del modelado de análisis muestran la forma en que las clases colaboran con un uno y otro y las relaciones e interacciones entre las clases. Lo anterior se examina con mayor detalle en el capítulo 8.

Elementos de comportamiento. El comportamiento de un sistema basado en computadora puede tener un profundo efecto sobre el diseño que se elija, así como en el enfoque de implementación que se aplique. Por lo tanto, el modelo de análisis debe proporcionar elementos de modelado que muestren el comportamiento.

El diagrama de estado es un método para representar el comportamiento de un sistema al mostrar sus estados y los eventos que ocasionan que dicho sistema cambie de estado. Un estado es cualquier forma de comportamiento observable. Además, el diagrama de estado indica las acciones (por ejemplo, la activación del proceso) que se toman como consecuencia de un evento particular. Para ilustrar un diagrama de estado, considérese el estado de la lectura de comandos de una fotocopiadora de oficina. En la figura se representa el diagrama de estado correspondiente en UML. Un rectángulo redondeado representa un estado. El rectángulo se divide en tres áreas: 1) el nombre del estado (por ejemplo, Lectura de comandos) 2) las variables de estado que indican la manera en que el estado se manifiesta a sí mismo en el mundo exterior. y 3) las actividades de estado que indican la forma en que se ingresa al estado (entrada/) y las acciones (do:) invocadas mientras se permanece en el mismo.

Elementos orientados al flujo. Cuando la información fluye a través de un sistema basado en computadora, esta se transforma. El sistema acepta la entrada en una variedad de formas, aplica funciones para transformarla y produce una salida también en formas diferentes. La entrada puede ser una señal de centro que transmite un transductor, una serie de números de teclea un operador humano, un paquete de información transmitido a través de liga de red, o un voluminoso archivo de datos obtenido de un almacenamiento secundario. La transformación puede incluir una sola comparación lógica, un algoritmo numérico complejo o un enfoque de interferencia de reglas pertenecientes a un sistema experto. La salida puede encender una sola luz de Led o producir un reporte de 200 páginas. En efecto, es posible crear un modelo de flujo para cualquier sistema basado en computadora, sin importar su tamaño o complejidad. En el capítulo 8 se presenta una exposición más detallada del modelado flujo.

Patrones de análisis

Cualquiera que lleve a cabo ingeniería de requisitos en más de unos cuantos proyectos de software comienza a darse cuenta que ciertas cosas suceden de manera recurrente en todos los proyectos dentro de un dominio de aplicación especifico. Esto puede denominarse patrones de análisis y representan algo (por ejemplo, una clase una función o un comportamiento) dentro del dominio de aplicación que puede reutilizarse al modelar muchas aplicaciones.

Geyer-Shultz y Hahsler sugieren dos beneficios que pueden asociarse con el uso de patrones de análisis: 

Primero, los patrones de análisis aceleran el desarrollo de modelos de análisis abstractos que capturan los requisitos principales del problema concreto al proporcionar modelos reutilizables del análisis, los cuales incluyen ejemplos. Así como una descripción de las ventajas limitaciones. Segundo, los patrones de análisis facilitan la transformación del modelo de análisis en un modelo de diseño al sugerir patrones de diseño y soluciones confiables para problemas comunes.

Los patrones de análisis se integran al modelo respectivo mediante una referencia al nombre del patrón. Estos también se encuentran almacenados en un depósito para que lo ingenieros de requisitos puedan utilizar los servicios de búsqueda y así encontrarlos y reutilizarlos.

La información acerca de un patrón de análisis se presenta en una plantilla estándar que tiene la siguiente forma

• Nombre del patrón: un descriptor que captura la esencia del patrón. El descriptor se utiliza dentro del modelo de análisis cuando se hace alguna referencia al patrón.
• Intención: describe aquello que el patrón pretende lograr o representar o el problema que ataca dentro del contacto de un dominio de aplicación.
• Motivación: un escenario que ilustra la forma en que el patrón se puede utilizar para atacar el problema.
• Fuerzas y contexto: una descripción de los aspectos externos (fuerzas externas) capaces de afectar la manera en que se utiliza el patrón, así como de los asuntos externos que serán resueltos cuando se aplique el patrón. Los aspectos externos pueden incluir cuestiones relacionadas con los negocios, restricciones técnicas externas y asuntos relacionados con las personas.
• Solución: una descripción de la forma en que se aplica el patrón para resolver el problema, poniendo especial atención en los aspectos estructurales y de comportamiento.
• Consecuencias: se enfoca en lo que sucede cuando se aplica el patrón y en los cambios que se producen durante su aplicación.
• Diseño: Examina la manera en que el patrón de análisis se puede lograr por medio de patrones de diseño conocidos.
• Usos conocidos: ejemplos de usos en sistemas reales.
• Patrones relacionados: uno o más patrones de análisis que se están relacionados con el patrón en cuestión. Porque el patrón el análisis 1) por lo general se utiliza junto con el patrón en estudio, 2) es similar en el sentido estructural a dicho patrón, 3) es una variación del mismo.