Modelado de Requerimientos: Flujo, Comportamiento y WebApps.

Ramiro Estigarribia Canese

Representaciones Gráficas de un Sistema.➔ Después de estudiar en el capítulo 6: casos de uso,

modelado de datos y modelos basados en clase, es razonable preguntar: ¿No son suficientes representaciones gráficas?La respuesta razonable es: “depende del sistema”.

➔ Para ciertos tipos de software, el caso de uso puede ser la única representación necesaria.

➔ En cambio en otras situaciones, la complejidad demanda mayor investigación.

Objetivo del Diseño.➔ El objetivo es crear una representación que tenga

claridad, funcionalidad y belleza.➔ Belady afirma que “la diversificación es la

adquisición de recursos del diseño: componentes, soluciones y conocimiento”.

➔ Deben escogerse aquellos elementos que representen mejor al sistema.

➔ A medida que esto ocurre, se evalúan las alternativas, algunas se rechazan, y se converge hacia la creación del producto final”.

Modelado orientado al Flujo.➔ Aunque algunos ingenieros perciben el modelado

orientado al flujo como una técnica obsoleta.➔ No obstante sigue siendo una de las notaciones

más utilizadas para hacer el análisis de los requerimientos.

➔ Para ciertos tipos de aplicaciones, el modelo de datos y el diagrama de flujo de datos es todo lo que se necesita para obtener una visión significativa de los requerimientos del software.

Diagrama de flujo de datos.➔ Es una representación gráfica del flujo de datos a

través de un sistema de información. ➔ Es una práctica común para un diseñador dibujar

un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas.

Niveles:Nivel 0: Diagrama de contexto. Nivel 1: Diagrama de nivel superior. Nivel 2: Diagrama de detalle o expansión.

Diagrama de Contexto.➔ Es un caso especial del diagrama de flujo de datos,

en donde una sola burbuja representa todo el sistema.

➔ Muestra a través de flujos de datos las interacciones entre los agentes externos y el sistema, sin describir en ningún momento la estructura del sistema.

➔ En este tipo de diagrama, el sistema de información debe representarse como un único proceso de muy alto nivel con entradas y salidas hacia los agentes externos que lo limitan, de forma equivalente a una caja negra.

Diagrama de Contexto.Este diagrama debe de ser fácilmente comprensible: No es posible representar todos los flujos de datos del sistema en él, sino más bien debe representarse en él una visión general del sistema.➔ Las personas, organizaciones y sistemas con los

que se comunica el sistema. Son conocidos como terminadores.

➔ Los datos que el sistema recibe del mundo exterior y que deben procesarse de alguna forma.

➔ Los datos producidos por el sistema y que se enviarán al exterior.

Diagrama de Contexto.

Diagrama de Contexto.

Especificación de Control.➔ Contiene un diagrama de estado que es una

especificación secuencial del comportamiento.➔ También puede contener una tabla de activación

del programa, especificación combinatoria del comportamiento.

Diagrama de Estado.

Especificación del Proceso.➔ Se utiliza para describir todos los procesos del

modelo del flujo que aparecen en el nivel final de la mejora.

➔ El contenido de la especificación del proceso incluye el texto narrativo, una descripción del lenguaje de diseño del algoritmo del proceso, ecuaciones matemáticas, tablas o diagramas de actividad UML, etc.

Análisis estructurado.➔ Las herramientas de análisis estructurado permiten

que un ingeniero de software cree modelos de datos, de flujo y de comportamiento en una forma que permite la consistencia y continuidad con facilidad para hacer la revisión, edición y ampliación.

➔ Los modelos creados con estas herramientas dan al ingeniero la perspectiva de la representación del análisis y lo ayudan a eliminar errores antes de que éstos se propaguen al diseño o, lo que sería peor, a la implementación.

Modelo de ComportamientoIndica la forma en la que responderá el software a eventos o estímulos externos. Deben seguirse los pasos siguientes:1. Evaluar todos los casos de uso para entender la secuencia de interacción.2. Identificar los eventos que conducen la secuencia de interacción con objetos específicos.3. Crear una secuencia para cada caso de uso.4. Construir un diagrama de estado para el sistema.5. Revisar el modelo de comportamiento para verificar la exactitud y consistencia

WebApps - Análisis de Requerimientos ➔ Es frecuente que los desarrolladores web expresen

dudas cuando se plantea la idea del análisis de requerimientos.

➔ Acostumbran decir: “El proceso de desarrollo en web debe ser ágil y el análisis toma tiempo. Nos hará ser lentos justo cuando necesitemos diseñar y construir la webapp”.

➔ El análisis de los requerimientos lleva tiempo, pero resolver el problema equivocado toma aún más tiempo.

Requerimientos para WebApps.La pregunta que debe responder todo desarrollador en web es: ¿Estás seguro de que entiendes los requerimientos del problema? ➔ Si la respuesta es un “sí” inequívoco, entonces tal

vez sea posible omitir el modelado de los requerimientos.

➔ Pero si la respuesta es “no”, entonces ésta debe llevarse a cabo.

¿Cuánto Análisis es Suficiente en una WebApp?Depende de los factores siguientes:1. Tamaño y complejidad del incremento de la

webapp.2. Número de participantes.3. Tamaño del equipo de la webapp.4. Grado en el que los miembros del equipo han

trabajado juntos antes.5. El éxito de la organización depende directamente

del éxito de la webapp.

Modelos para WebApps1. Modelo de contenido: identifica el espectro

completo de contenido que dará la webapp. El contenido incluye texto, imágenes, video, etc.

2. Modelo de interacción: describe la manera en que los usuarios interactúan con la webapp.

3. Modelo funcional: define las operaciones que se aplicarán al contenido de la webapp.

4. Modelo de navegación: define la estrategia general de navegación para la webapp.

5. Modelo de configuración: describe el ambiente e infraestructura en la que reside la webapp.

Resumen y Conclusiones.➔ Los modelos orientados al flujo se centran en el

flujo de objetos de datos a medida que son transformados por las funciones de procesamiento.

➔ Derivados del análisis estructurado, los modelos orientados al flujo usan el diagrama de flujo de datos, notación de modelación que ilustra la manera en la que se transforma la entrada en salida cuando los objetos de datos se mueven a través del sistema.

➔ Cada función del software que transforme datos es descrita por la narrativa de un proceso.

Resumen y Conclusiones.➔ Los patrones de análisis permiten utilizar el

conocimiento del dominio existente para facilitar la creación de un modelo de requerimientos.

➔ El modelado de los requerimientos para las webapps los mismos elementos de modelado. Sin embargo, dichos elementos se aplican dentro de un conjunto de modelos especializados que se abocan al contenido, interacción, función, navegación y configuración cliente-servidor en la que reside la webapp.