Introducción

En la actual industria del software los sistemas cada vez son más grandes, lo cual trae complicaciones al tratar de entender todo el sistema, para este caso es necesario descomponerlo en partes (subsistemas), establecer quién tendrá el control y la forma en la que estos se comunicarán. Todo esto se conoce como Diseño Arquitectónico.

Este proceso se encuentra dentro de la etapa de Diseño de cualquiera de los modelos de desarrollo de software, vistos en Ingeniería de Software I. Recordando esta etapa es la más crítica del proceso, ya que en esta se genera el diseño del sistema tomando como base los requerimientos extraídos de la necesidad del cliente.

Propósitos de aprendizaje

Propósito general

Identificar el concepto de diseño arquitectónico y su aplicación en el diseño de software.

Propósitos específicos

  • Comprender la importancia del diseño arquitectónico.
  • Tomar decisión de cuál modelo arquitectónico es viable aplicar para la construcción de software.
  • Establecer los principales componentes de un sistema.
  • Descomponer un sistema en subsistemas para su dominio.

Importancia del Diseño Arquitectónico

El proceso de diseño de arquitectura se compone de cinco procesos, tal como se presenta en el gráfico principal de esta pantalla. La entrada del proceso es el problema conocido como SRS (Especificación de Requisitos de Software) y la salida es SAD (Documento de Arquitectura de Software).

En el SAD (Documento de Arquitectura de Software), su contenido depende del diseño inicial y de las necesidades definidas por el equipo de desarrollo. Cuando el sistema es pequeño su documentación es sencilla y muy poca; caso contrario sucede en sistemas grandes donde se requiere bastante documentación muy detallada y con modelos incluidos.

En la actualidad, las tecnologías de información exigen la creación de sistemas robustos, eficaces, eficientes y útiles para el cliente, la decisión del diseño no puede ser una tarea espontánea sino que debe contar con una buena argumentación del porqué de su selección.

Decisiones de Diseño Arquitectónico

Antes de abordar qué es el diseño arquitectónico, se revisarán algunas definiciones respecto a: qué es arquitectura, la importancia de la arquitectura y qué es una descripción arquitectónica.

El Diseño Arquitectónico es una actividad que se encuentra dentro de la etapa de Diseño del ciclo de vida del software. En ella se realiza la identificación de los componentes que harán parte del sistema y la forma en la que estos se deben comunicar. No solo hay que diseñar, sino que también se hace necesario el documentar todo el proceso desarrollado. (Sommerville, 2010).

El Diseño Arquitectónico se centra en la representación de la estructura de los componentes del software, sus propiedades e interacciones (Pressman, 2009). En la siguiente tabla se observan los géneros arquitectónicos que son las categorías específicas que hacen parte del dominio del software. Lo que se busca con esto es establecer qué tipo de sistema se va a construir.

Decisiones de Diseño Arquitectónico

Requerimientos no funcionales

Los requerimientos no funcionales dentro de la definición de la arquitectura se conocen como los atributos de calidad, ya que con el cumplimiento de estos se da respuesta a las necesidades y deseos del cliente. Se clasifican en dos categorías (Fox, 2006):

  1. Atributos de desarrollo:
    • Mantenimiento
    • Reusabilidad

  2. Atributos de operación:
    • Rendimiento
    • Disponibilidad
    • Fiabilidad
    • Seguridad

Decisiones de Diseño Arquitectónico

Importancia Diseño Arquitectónico

El arquitecto del sistema debe hacerse las siguientes preguntas para definir cuál es el diseño arquitectónico adecuado. Las anteriores cuestiones permitirán que el arquitecto piense en: sistemas distribuidos, estilos de control, las pruebas apropiadas y abordar la aplicación por medio de subsistemas.

A continuación, en la imagen se visualiza los diagramas de UML, que facilitan el diseño de software al arquitecto junto con una tabla de las notificaciones, útiles para la especificación de la arquitectura de software.

Actividad de aprendizaje

Actividad de Aprendizaje

Lee atentamente el cuestionamiento sobre conflictos entre requerimientos no funcionales y justifica tu respuesta.

Organización del sistema

Un estilo arquitectónico hace referencia a la especialización de elementos, relaciones y el grupo de restricciones sobre cuándo usar un sistema.

El objetivo del estilo arquitectónico radica en establecer la organización de los componentes del sistema,ya que si se llegase a presentar una reingeniería, se puede hacer los cambios de arquitectura sin que se presente ningún tipo de complicación en la estructura de software.

Se revisarán los modelos de organización del sistema que le permite al diseñador visualizar la estructura de los datos dentro de cada subsistema y de esta forma determinar los recursos y las relaciones que tendrán entre sí. Es decir le sirve de plantilla para la construcción.

Antes de abordar los estilos se debe tener en cuenta que el proceso de diseño es útil porque se ve que la arquitectura es una toma de decisiones que implica los siguientes aspectos.

Organización del sistema

Modelo repositorio

También conocida como una arquitectura que se centra en los datos, ya que cuenta con un almacén de datos que puede ser un archivo o la base de datos. Su función es permitir que los componentes tengan acceso, actualicen, agreguen, eliminen o modifiquen los datos.

El cliente es quien accede al repositorio de forma independiente. En ocasiones se suele llamar pizarrón ya que envía notificaciones al cliente en los momentos en que ocurren cambios en los datos y que se tiene la certeza que es de interés para el usuario.

Son promulgadores de la integridad, ya que los componentes se cambian y se agregan otros sin ocasionar problemas. El pizarrón resulta ser útil en el momento en que se usa para coordinar transferencias de información entre los clientes y estos se siguen ejecutando de forma independiente. (Pressman, 2009)

En el modelo de repositorio, los subsistemas tienen la posibilidad de intercambiar información; para esto es necesario que esta se encuentre centralizada y todo aquel que la necesite pueda accesar a ella.

¿Qué otros ejemplos de modelos repositorios conoce?

Organización del sistema

Modelo Cliente Servidor

En este modelo, como su nombre lo indica, existe un servidor, el cual posee una serie de servicios que pone a la disposición de unos clientes, quienes acceden sin ningún inconveniente. Este modelo se compone de tres elementos: servidores, clientes y red.

El funcionamiento del Modelo Cliente Servidor consiste en que el cliente realiza una petición de servicio por medio de una llamada a procedimiento remoto conocida como agente Broker. El flujo de control es independiente tanto para el caso del cliente como para el servidor. Para el caso de las sincronizaciones estas se presentan cuando hay que administrar peticiones o prepararse para el recibo de resultados.

¿Qué otros ejemplos de modelos Cliente Servidor conoce?

Organización del sistema

Modelo Capas

Visualmente se asemeja al ya conocido Modelo OSI, el cual consiste en una serie de escalones que se van acomodando uno sobre otro hasta llegar a un tope; esto quiere decir que para llegar al último escalón debe recorrer todos los anteriores.

Este tipo de modelo ofrece una gran ventaja ya que permite soportar el desarrollo del sistema por medio de capas incrementales, obteniendo al final la totalidad de la funcionalidad. En el momento en que se realice un cambio en alguna capa el resto seguirá soportando el sistema sin ningún problema; ya que hasta no verificar que funcionará correctamente no se hará el ajuste definitivo. Veamos el siguiente ejemplo.

Modelo Vista Controlador

Es aquella que se compone de tres tipos de sistemas diferentes:

  • Subsistema modelo: su función es la de realizar el mantenimiento del conocimiento del dominio.
  • Subsistema vista: se encarga del despliegue del sistema al usuario.
  • Subsistema controlador: maneja las secuencias de interacción para el usuario.

A continuación se presentan algunos ejemplos de la vida real donde se utiliza estos modelos de diseño arquitectónico.

Actividad de aprendizaje

Actividad de Aprendizaje

De acuerdo con lo estudiado hasta este punto, realiza la siguiente actividad donde organizarás un diagrama de capas con base en un caso específico.

Estilos de descomposición modular

En el anterior tema se veía cómo se organiza el sistema a nivel de arquitectura. A continuación, se mostrará que para abordar mejor un sistema hay que realizar descomposición de este. Típicamente se habla de los módulos, pero en algunas ocasiones genera confusión entre lo que es un subsistema y un módulo.

La descomposición funcional va enmarcada en el contexto de la ingeniería de software orientada a objetos, ya que le permite pensar en componentes que contiene clases que colaboran entre sí.

La clase incluye los atributos y operaciones necesarias para su posterior implementación. A su vez se incluyen las interfaces que son las encargadas de permitir que las clases se comuniquen y hagan parte de un trabajo colaborativo.

¿Cuál es la mejor estrategia para descomponer un sistema?

Estilos de descomposición modular

Orientada a objetos

El sistema se compone de una serie de objetos, los cuales poseen una serie de servicios definidos que pueden ser invocados o utilizados por otros objetos. Los objetos tienen tres características fundamentales:

  • Tiene un nombre, con el cual se puede identificar de otros objetos.
  • Tiene unos atributos, estos son las características propias del objeto que lo hacen diferente a los demás.
  • Tiene métodos que son las operaciones que puede realizar.

La descomposición orientada a objetos es lo que actualmente se conoce como una clase y la representación de varias clases con sus relaciones es lo que se vio en Ingeniería de Software I como “Diagrama de Clases”. En la interactividad anterior se exponen las ventajas y desventajas de este sistema.

La descomposición orientada a objetos hace parte de los métodos de diseño estructurado, que sugiere que el diseño de software debe llevarse a cabo de forma metódica: diseñar con base a un método, corregir al menor detalle el diseño. A finales de los años 90 se unieron los métodos de diseño en lo que hoy se conoce como UML. En el siguiente enlace encontrará más información acerca de métodos estructurados. Específicamente en la utilización de la metodología ágil RUP que contiene las fases y disciplinas necesarias para hacer un buen diseño.

Estilos de descomposición modular

Orientada a flujo de funciones

Este tipo de descomposición también se conoce como Modelo de Flujo de Datos, ya que a partir de una entrada el sistema produce una salida. Los datos que ingresan a medida que van pasando de una función a otra se transforman hasta llegar a un estado final.

El proceso de transformación de los datos puede ocurrir de forma paralela o secuencial, según sea el caso; en ocasiones los datos vienen de a uno solo o agrupados lo que comúnmente se conoce cómo lote.

Actividad de aprendizaje

Actividad de Aprendizaje

Con base en lo estudiado hasta este punto, evalúa qué tanto aprendiste de la arquitectura multiprocesador.

Estilos de control

En el tema anterior se hablaba de los modelos para estructurar el sistema y se encontró que la mejor forma es dividirlo en subsistemas. Esto hace que surja la necesidad de que alguien controle sus servicios para que estos se han accedidos y llegue en el momento indicado.

Todo modelo estructural debe ir acompañado de un estilo de control.

Para tener un buen manejo del sistema, se incurre en la necesidad de control de los componentes y administración de las responsabilidades y el correcto funcionamiento del mismo. En ocasiones se presentan ejecución de componentes en forma secuencial o paralela; para esto el arquitecto debe considerar cuál será la mejor opción.

El arquitecto deberá definir un modelo de control que facilite el acceso a los servicios sin importar si es una descomposición de objetos o de funciones.

Patrones arquitectónicos para control: existen patrones arquitectónicos específicos que reflejan formas usadas comúnmente para organizar el control en un sistema. En ellos se incluyen el control centralizado, basado en un componente que llama otros componentes, y el control con base en un evento, donde el sistema reacciona a eventos externos (Sommerville, 2008).

Estilos de control

Control centralizado

En el momento de su diseño, el arquitecto de software decide cuál de los subsistemas tendrá el control y la responsabilidad de la ejecución del resto de subsistemas. Este se subdivide en dos:

  • Modelo llamada – retorno: el control está dado por una jerarquía de subrutinas, en donde el control pasa a los niveles inferiores del árbol. Es comúnmente utilizado en sistemas secuenciales.
  • Modelo gestor: es usado en sistemas concurrentes. Sus tareas son controlar el inicio, las paradas, y debe coordinar el resto del sistema. Los procesos se pueden ejecutar en paralelo sin que genere algún tipo de inconveniente a todo el sistema en general.

Estilos de control

Basado en Eventos

Tal como lo indica su nombre, el control se rige por eventos que se generan de forma externa. Hay que tener en cuenta que un evento se define como: señal binaria. Señal dentro de un rango de valores desde la selección de un menú. Con los eventos no se sabe en qué momento aparecerán.

Su interacción se hace por medio de invocaciones de procedimientos o funciones. Cada componente deja a disposición los datos que puede compartir para los otros. Se garantiza el cumplimiento de los eventos mediante el manejo de mensajes, que genera la comunicación entre componentes.

Los siguientes elementos, componentes y conexiones, hacen parte de los sistemas basados en eventos; los cuales a su vez se clasifican en dos modelos: Modelos de transmisión (broadcast) y Modelo dirigido por interrupciones.

Actividad de aprendizaje

Actividad de Aprendizaje

De acuerdo con lo estudiado en los estilos de control, agrupe los siguientes conceptos de diseño arquitectónico.

Material
de apoyo

Resumen

En esta unidad se trató la arquitectura de software como la base para la estructuración correcta de un sistema. En ingeniería de software I eran esenciales los requerimientos funcionales (solución a la necesidad del cliente), en ingeniería de software II es de vital importancia los requerimientos no funcionales los cuales permiten garantizar el rendimiento, la disponibilidad, confianza y seguridad de la información que maneja el sistema; conocidos como atributos de calidad.

El diseño arquitectónico le permite al desarrollador comprender todo el sistema a partir de los subsistemas. De esta forma garantiza el cubrimiento de todos los requerimientos ya sean funcionales o no funcionales. Una vez se obtiene este diseño, se genera el modelo de objetos que se verá en una próxima unidad.

Hay modelos arquitectónicos de dominio específico que permiten, que a partir de una arquitectura ya estructurada, reutilizarse cada vez que se desarrollen nuevos sistemas. Estas son las arquitecturas de referencia.

Actividad de aprendizaje

Actividad de Aprendizaje

Para finalizar esta unidad, le invitamos a realizar las siguientes actividades:

  • De acuerdo con dos casos propuestos, seleccionar su modelo estructural y justificar la respuesta.
  • Con base en todo lo estudiado en la unidad, lee el siguiente caso de estudio y evalúa lo aprendido.

Bibliografía ()

  • Amescua, A. (2003). Análisis y diseño estructurado y orientado a objetos de sistemas informáticos. Madrid: Mc Graw-Hill Interamericana.
  • Bourque, P. & Fairley, R.E. (2014). Guide to the Software Engineering Body of Knowledge. Hoes Lane: A Project of the IEEE Computer Society.
  • Bruegge, B. & Dutoit, A. (2004). Object- Oriented Software Engineering Using UML, Patterns, and Java. (3ra ed.) Estados Unidos: Prentice Hall.
  • Fox, C. (2006). Introduction to Software Engineering Design. Boston: Pearson Addison Wesley.
  • George, J., Batra, D., Valacich, J. & Hoffer, J. (2006). Object-oriented systems analysis and design. New Jersey: Prentice Hall.
  • Lawrence Pfleeger, S. (2002). Ingeniería de software. Teoría y práctica. Buenos Aires: Pearson Education.
  • Naveda, J. F.& Seidman, S. B. (2006). IEEE computer society real world software engineering problems a self study guide for today´s software professional. Hoboken N.Y.: Wiley-IEEE Computer Society Pr
  • Piattini, M. (1996). Análisis y diseño detallado de Aplicaciones Informáticas de Gestión. Madrid: RA-MA editorial.
  • Pressman, R. (2009). Ingeniería del Software. Madrid: MC. Graw Hill.
  • Schach, S. R. (2006). Ingeniería de Software Clásica y Orientada a Objetos. México: Mc Graw-Hill.
  • Software Engineering Standards Commitee (2000). IEEE Recommended Practice for Architectural Description of Software Intensive Systems. IEEE Computer Society.
  • Sommerville, I. (2010). Ingeniería de Software. Madrid: Pearson Educación SA.
  • Tyree, J. & Akerman, A. (2005). Architectural Decisions: Demystifying Architecture. IEEE Software, 22(2), pp. 19-27.

Referencias Web