Contexto

Isabella y Anna son parte del equipo de desarrollo del sistema. Isabella es responsable de la ingeniería de requerimientos, mientras que Anna es encargada del diseño del sistema.

Isabella ha terminado el documento de requerimientos y considera que los diagramas de clases, secuencia, casos de uso y diagramas de flujo de datos son suficientes como parte del diseño para pasar a la etapa de construcción y así lograr acortar un mes de diseño que puede ser utilizado para generar más casos de prueba y revisar que el sistema no tenga errores o defectos que podrían aparecer cuando el cliente se encuentre operando el sistema.

Anna considera que el trabajo generado en la etapa de requerimientos se toma en cuenta para realizar el diseño, pero no llega a ser suficiente para determinar la arquitectura que tendrá el software y sobre la cual deben basarse la programación del sistema. Anna insiste que pasar por alto el diseño arquitectónico del software mejorará la estructura del sistema, y responderá mejor a los requerimientos funcionales y no funcionales del sistema.

Isabella tiene las siguientes dudas:


  • ¿Qué pasos se pueden llevar a cabo para lograr un diseño adecuado?
  • ¿Cómo puedes pasar del diagrama de flujo de datos a un diseño arquitectónico?
  • ¿Es posible utilizar los diagramas que se elaboraron en el análisis del sistema para el diseño?

Explicación

5.1 Diseño arquitectónico basado en la funcionalidad

Otra forma en la que es posible definir una arquitectura de software es a través del “diseño arquitectónico basado en la funcionalidad” (Functionality-based architectural design) propuesto por Jan Bosch. Este método se basa principalmente en los requerimientos funcionales documentados en la ingeniería de requerimientos, de allí su nombre, el cual se describe a continuación:

Haz clic en cada concepto para conocer más detalle.

Haz clic aquí para conocer un ejemplo de los tres pasos para elaborar un diseño arquitectónico basado en la funcionalidad de un sistema que será utilizado para monitorear detectores de fuego en un edificio.

5.2. Diseño estructurado

El diseño estructurado es un método que transforma el análisis elaborado en un Diagrama de Flujo de Datos (DFD) a la arquitectura de software. Parte fundamental de este método es el mapeo de la arquitectura. Para comprenderlo se describe a continuación un ejemplo práctico propuesto por Pressman (2010), que seguramente te ayudará a conocer cómo se transforma un flujo de datos a una estructura arquitectónica.

El sistema objetivo de este ejemplo es un software destinado a gestionar un sistema de seguridad para una casa habitación.

Haz clic en cada concepto para conocer más detalle.

Paso 1. Revisión del modelo del sistema fundamental

El primer paso consiste en revisar al diagrama de contexto o diagrama de flujo de datos de nivel 0 y el nivel 1. Este nivel muestra la interacción que tiene el sistema con las entidades (personas, dispositivos y otros sistemas).

Diagrama de contexto. Imagen adaptada de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.

Diagrama del Nivel 1. Imagen adaptada de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.

Paso 2. Revisar y mejorar los diagramas de flujos de datos para el software

Observa que los procesos 1 al 5 del diagrama de flujo son autodescriptivos, por lo que no requieren mayor detalle. Sin embargo, el proceso 6.0 Vigilar sensores, puede requerir mayor información ya que es el fundamento de todo el sistema. Para ello, es posible agregar mayor detalle en un nivel 2 del diagrama de flujo, como se muestra a continuación.

Diagrama del Nivel 2. Imagen adaptada de Pressman, R. (2010).Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.

Paso 3. Determina si el DFD tiene características de transformación o de transacción.

Un diagrama de flujo de datos puede tener dos características, la primera está relacionada con la transformación, es decir, la información entra al sistema, llega a un centro de transformación y después sale por caminos específicos. La segunda se le llama transacción, en el que los datos entran a un elemento que concentra la mayor cantidad de flujos de información, dependiendo de la información de llegada se convierten en flujos que toman diferentes caminos.

Si es transformación

  1. Aislar el centro de transformación de los procesos de entrada y salida
  2. Establecer la siguiente estructura:

  3. Ejecutar un segundo nivel de rediseño.
  4. Refinar la estructura.

Si es transacción

  1. Identificar el centro de la transacción.
  2. Establecer la siguiente estructura de software:

  3. Desarrollar cada una de las transacciones, incorporándola a la estructura anterior.
  4. Refinar la estructura.

En el ejemplo, observa que existe una transformación de la información a través de los procesos hasta llegar a generar una alarma.

Paso 4. Aísla el centro de transformación, especificando las fronteras de entradas y salidas del flujo.

Para conocer el centro de la transformación de datos se requiere detallar a un nivel 3. Observa que el proceso 6.2 contiene la parte fundamental de todo el sistema. De allí puedes identificar las entradas y determinar qué salidas se generan.

Observa que en un nivel 3 del flujo de datos prácticamente se describen tareas que debe realizar el proceso. En este nivel es posible agrupar en componentes las actividades afines que puedan formar parte de la estructura arquitectónica. Por ejemplo, se observa que existen tres bloques principales, que son entradas, condiciones y salidas.

Diagrama del Nivel 3. Imagen adaptada de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.

Observa que a partir del diagrama es posible dividir los procesos en los componentes que darán estructura a la arquitectura del software:

Paso 5. Realiza el “rediseño de primer nivel”.

En este paso ya es posible determinar un primer diseño arquitectónico tomando en cuenta las actividades medulares del sistema, para así transformarlas en componentes:

Controlador de sensor de entradas: coordina todos los datos que llegan.
Controlador de condiciones de alarma: supervisa las operaciones que se generan con la entrada de datos.
Controlador de salidas de alarmas coordina la producción de datos de salida.

Paso 6. Realizar rediseño de segundo nivel.

En este paso se identifican las actividades del flujo de datos que están relacionadas con los componentes del rediseño de primer nivel. Observa que en este ejemplo existe una relación 1 a 1 con respuecto al flujo de datos, sin embargo, Pressman (2010) hace notar que no siempre es así, es posible tener diferentes mapeos entre los componentes.

Estructura para el proceso Vigilar Sensores. Imagen tomada de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.

5.3 Refinamiento

El último paso de este método de estructura del diseño estructurado será el refinamiento, que es un proceso de ajuste y mejora al diseño con el principal objetivo de verificar que cumpla con los requerimientos funcionales y no funcionales del sistema.

Aquí la meta será generar un diseño de arquitectura lo más simple pero a la vez completo posible.

“El refinamiento del diseño debe perseguir el menor número de componentes que sea consistente con la modularidad efectiva y la estructura de datos menos compleja que cumpla de modo adecuado con los requerimientos de información” (Pressman, 2010).


El proceso de refinamiento requiere que tengas en mente lograr que los componentes sean independientes funcionalmente, existe una buena cohesión y un mínimo de de acoplamiento, de esa manera lograrás que la arquitectura sea sencilla de comunicar, implementar y mantener.

En el ejemplo anterior, como parte del refinamiento del diseño arquitectónico, Pressman (2010) sugiere eliminar los siguientes componentes: el controlador de sensor de entradas, el controlador de condiciones de alarmas, seleccionar número telefónico y formatear pantalla. Observa que deja una estructura más simple y elimina tareas que pueden ser incluidas en componentes superiores.

El mayor problema que se tiene en el refinamiento es evitar el paradigma de tratar de generar un diseño parecido a una estructura de un programa, lo que hace difícil evaluarlo o mejorarlo sin tener que pensar en modificar el código del programa.

Estructura refinada del programa para Vigilar Sensores. Imagen recuperada de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill..

Cierre

El diseño de la arquitectura de un software es un proceso iterativo en el que se prueban diferentes estructuras hasta encontrar la que mejor resuelva los requerimientos del usuario. Para llegar a generar esta arquitectura, existen varios caminos o métodos, cada uno de los cuales empieza por un primer diseño que se irá refinando hasta encontrar el más adecuado.

El trabajo elaborado en la ingeniería de requerimientos será el punto de partida. De él se pueden retomar los diagramas contenidos en el documento de especificaciones, que probablemente deban agregarse mayor detalle con el fin de establecer una visión general de lo que debe ser y hacer el sistema, con qué entidades externas debe intercambiar información y cuáles son las relaciones que tendrán sus componentes internos.

El arquitecto de sistemas debe tener en mente la necesidad de establecer una estructura lo más simple posible que pueda posteriormente modificar o adaptase a nuevas necesidades. Lograrlo no es sencillo y es muy útil que este trabajo se valide con el equipo del proyecto de desarrollo en pro de generar un software de calidad.

Checkpoint

Asegúrate de poder:

  • Identificar los pasos para elaborar un diseño arquitectónico basado en la funcionalidad para llegar a generar una estructura de arquitectura que responda a los requisitos del usuario.
  • Practicar el método del diseño estructurado para llegar a generar un primer diseño de arquitectura con el que pueda establecer un proceso de refinamiento hasta llegar a una arquitectura simple ya la vez completa.

Referencias

  • Bosch, J. (2000). Design & use of software architecture. EE. UU: Addison-Wesley.
  • Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.