La acción de modelar los requerimientos da como resultado diferentes tipos de modelo.
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.
Reglas Prácticas del Análisis para Crear el Modelo
- El modelo debe centrarse en los requerimientos que sean visibles dentro del problema o dentro del dominio del negocio.
- Cada elemento del modelo de requerimientos debe agregarse al entendimiento general de los requerimientos de software y dar una visión del dominio de la información, de la función y del comportamiento del sistema.
- Hay que retrasar las consideraciones de la infraestructura y otros modelos no funcionales hasta llegar a la etapa del diseño. Es decir, quizá se requiera una base de datos, pero las clases para implementar las funciones requeridas deben considerarse después de terminar el análisis del dominio del problema.
- Debe minimizarse el acoplamiento a través del sistema. Es importante representar las relaciones entre las clases y funciones.
- Es seguro que el modelo de requerimientos agrega valor para todos los participantes. Cada actor tiene su propio uso para el modelo.
- Mantener el modelo tan sencillo como se pueda. No genere diagramas adicionales si no agregan nueva información; evite notación compleja.
Elementos del Modelo de Análisis
- Modelos basados en el escenario: por ejemplo, casos de uso, historias de usuario.
- Modelos de clase: por ejemplo, diagramas de clase, diagramas de colaboración.
- Modelos de comportamiento: por ejemplo, diagramas de estado, diagramas de secuencia.
- Modelos de flujo: por ejemplo, DFD, modelos de datos.
Definiciones Clave
MBE: El sistema se describe desde el punto de vista del usuario con el empleo de un enfoque basado en los escenarios. Son la primera parte del modelo en desarrollo. Sirven como entrada para la creación de otros elementos de modelado, como diagramas de actividad y UML.
MBC: Cada escenario de uso implica un conjunto de objetos que se manipulan cuando un actor interactúa con el sistema. Este conjunto de objetos tiene atributos similares y comportamientos comunes.
DC: Indica la forma en la que responderá el software a eventos o estímulos externos. El comportamiento de un sistema basado en computadora tiene un efecto profundo en el diseño que se elija y en el enfoque de implementación que se aplique. Por tanto, el modelo de requerimientos debe proveer elementos de modelado que ilustren el comportamiento.
MF: El diagrama de flujo de datos permite desarrollar modelos del dominio de la información y del dominio funcional. La información se transforma cuando fluye a través de un sistema basado en computadora. El sistema acepta entradas en varias formas, aplica funciones para transformarla y produce salidas en distintos modos.
Ejemplos de Modelos
- Caso de uso: describe en lenguaje claro un escenario específico desde el punto de vista de un actor definido.
- Historias de usuario: describen la salida necesaria, características y funcionalidad del software que se va a elaborar.
- Diagramas de clase: representan las clases orientadas a objetos, mostrando un conjunto de clases, interfaces y colaboraciones, así como sus relaciones.
- Diagramas de colaboración: diagrama que muestra interacciones entre colaboradores, entre objetos y subsistemas que pueden no ser visibles de manera externa.
- Diagramas de estado: es un método de representación del comportamiento de un sistema que ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado. Un estado es cualquier modo de comportamiento observable desde el exterior.
- Diagramas de secuencia: indican la forma en la que los eventos provocan transiciones de un objeto a otro. Una vez identificados los objetos, el modelador crea un diagrama de secuencia que representa el modo en el que los eventos causan el flujo de uno a otro como función del tiempo.
- Diagrama de flujo de datos (DFD): adopta un punto de vista del tipo entrada-proceso-salida para el sistema. Los objetos de datos entran al sistema, son transformados por elementos de procesamiento y los objetos de datos que resultan de ello salen del software.
- Modelos de datos: objetos y relaciones.
Modelado Clase-Responsabilidad-Colaborador (CRC)
Un modelo CRC en realidad es un conjunto de tarjetas índice estándar que representan clases. Las tarjetas se dividen en tres secciones. 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. Clases, Responsabilidad, Colaboraciones.
El objetivo es desarrollar una representación organizada de las clases. Las responsabilidades son los atributos y operaciones relevantes para la clase. En pocas palabras, una responsabilidad es “cualquier cosa que la clase sepa o haga”. Los colaboradores son aquellas clases que se requieren para dar a una clase la información necesaria a fin de completar una responsabilidad. En general, una colaboración implica una solicitud de información o de cierta acción.
Pasos para Generar un Modelo de Comportamiento
- Evaluar todos los casos de uso para entender por completo la secuencia de interacción dentro del sistema. Un caso de uso se estudia para efectos del intercambio de información.
- Identificar los eventos que conducen la secuencia de interacción y que entienden el modo en el que estos se relacionan con objetos específicos.
- Crear una secuencia para cada caso de uso.
- Construir un diagrama de estado para el sistema.
- Revisar el modelo de comportamiento para verificar la exactitud y consistencia.