3.1 Fundamentos de la arquitectura
La arquitectura es parte de nuestra historia como seres humanos, en nuestro afán por embellecer y hacer funcionales los espacios que compartimos. En muchos casos han logrado tal efecto en la cultura que algunas ciudades se caracterizan por la arquitectura de sus edificaciones.
En ese sentido, la ingeniería de software ha tomado prestado el término de arquitectura para ejemplificar el trabajo que se realiza al diseñar componentes de software que se van construyendo y acoplando en un solo sistema de cómputo y lograr resolver una necesidad del usuario.
La arquitectura de software es el proceso de lograr generar un diseño funcional, a través de una estructura de componentes llamada modelo de arquitectura, que da solución a uno o a un grupo de requerimientos propuestos por el cliente.
Tsui, Karam y Bernal (2014) ejemplifican la relación que existe entre los requerimientos del análisis del sistema, la arquitectura y el diseño detallado a través del siguiente diagrama. Observa que existe un nivel de abstracción alto al genera la arquitectura.
La mayor influencia que existe entre el documento de especificaciones y la arquitectura está relacionada con los requerimientos no funcionales como el rendimiento y la mantenibilidad. Mientras que el diseño detallado es generado a partir de la arquitectura. Lo importante es que cada módulo del diseño detallado de respuesta a uno o más requerimientos.
En metodologías ágiles de desarrollo, no se genera un documento formal de arquitectura, sino que se pasa directamente al diseño detallado, ya que el proceso iterativo solo incluye un grupo pequeño de requerimientos.
Relación entre requerimientos, arquitectura y diseño detallado. Imagen recuperada de Tsui, F., Karam, O., Bernal, B. (2014). Essentials of Software Engineering (3ª ed.). EE. UU: Jones & Bartlett Learning.
La idea de modularidad es esencial en la arquitectura del software, ya que ofrece mantener una flexibilidad en la construcción de componentes, son más sencillos de realizar cambios y volver a acoplarlos al resto de los módulos del software, facilitan el proceso de pruebas y es posible hacer correcciones minimizando el riesgo de daños colaterales a otros componentes.
Cada componente debe estar relacionado con algún otro componente, ya sea haciendo uso de métodos o procedimientos de otros componentes, o bien a través de un gestor de información central como son las bases de datos.
Para ejemplificar un modelo de arquitectura, Sommerville (2011) nos ofrece el siguiente diagrama en el que representa un sistema del robótico para empacar objetos de diferentes tamaños, que se encuentran avanzando en una cinta transportadora. El sistema detecta el tipo de objeto, selecciona el tipo de paquete, lo empaqueta con un brazo y mano robóticos, y finalmente lo deposita en otra cinta transportadora.
Arquitectura de un sistema de control de empaquetamiento robótico. Imagen tomada del libro de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson Educación. Sólo para fines educativos.
Como puedes observar es sencillo identificar los componentes de sistema que se han diseñado como parte de la arquitectura del software. Cada componente puede ser desarrollado de forma independiente dado que se enfocan a diferentes funciones. Las flechas en el diagrama indican la relación que existe entre los componentes o la información que debe fluir a través de cada componente.
Este diagrama esconde los detalles de cómo se implementa cada componente, pero tiene la ventaja que cualquier persona puede interpretar en cómo se divide el sistema y fácilmente podrían detectar omisiones, por ejemplo, no incluye el etiquetado del paquete, que sería otro componente.
En opinión de Sommerville (2011), existen dos niveles de abstracción en la arquitectura de software:
Haz clic en cada concepto para conocer más detalle.
En el que cada programa se descompone en componentes con funciones específicas.
Que consideran grupos de programas, otros sistemas y otros componentes de programas. Este tipo de arquitectura es utilizada en sistemas genéricos que pueden ser adoptados por diferentes empresas.
Establecer la arquitectura del software no solo es un paso obligatorio en el diseño, también trae algunos beneficios como los siguientes:
Haz clic en cada concepto para conocer más detalle.
Permite realizar un análisis de las posibles alternativas de solución a los requerimientos, en un nivel de abstracción que es fácil manipular y cambiar.
Definir una adecuada arquitectura del software cobra importancia debido a que responderá a los requerimientos no funcionales del sistema como son: velocidad, capacidad, rendimiento, seguridad, portabilidad, operatividad, escalabilidad, mantenibilidad y usabildad.
La arquitectura es un mecanismo de comunicación con los stakeholders del proyecto. El equipo de desarrollo puede hacer uso de la arquitectura del software para explicar cómo responderá a los requerimientos del cliente en un nivel de abstracción alto, sin la necesidad de confundirse con el detalle.
La arquitectura resalta características que impactarán al resto de las etapas del ciclo de vida del desarrollo del software, por lo que es posible poder negociar o discutir aquellos requerimientos que podrían entrar en conflicto con la arquitectura propuesta.
Un modelo arquitectónico puede ser reutilizado en sistemas con requerimientos similares, piensa por ejemplo en un sistema de facturación electrónica, en el que una solución que haya sido elaborada para una ferretería puede ser aplicada también para otros negocios como una refaccionaria.
3.2 Descripciones arquitectónicas
En cualquier proyecto de software participan personas de diferentes áreas que tienen diferentes intereses. Para que la comunicación fluya de forma adecuada, el administrador del proyecto debe ofrecer la información que necesita para tomar decisiones adecuadas.
Si se trata de un software que administra la relación con los clientes, al vendedor le interesará que el software le facilite el ingreso de órdenes y mantenga siempre actualizado los servicios del cliente. Un contador buscará que los pagos que realizan los clientes sean correctamente registrados y muestre aquellos clientes que presentan un retraso en el pago. Un gerente de mercadotecnia buscará que el sistema le provea de información sobre los productos con mayores ventas y las promociones que han tenido más éxito en el pasado. Como ves, cada persona buscará un beneficio específico en el sistema y su participación en el proyecto estará en función del cumplimiento con sus expectativas.
Según Pressman (2010), una descripción arquitectónica es un conjunto de productos de trabajo que reflejan puntos de vista distintos del sistema, para ello se requiere que el diseño del software genere vistas arquitectónicas que abarquen cada área de interés de los participantes del proyecto.
Vistas arquitectónicas: en palabras de Bass, Clemens y Kazman (2010), las vistas representan un aspecto parcial de una arquitectura de software que muestra propiedades específicas de un sistema. Estas vistas permiten mostrar diferentes facetas de alto nivel del diseño del software o comportamiento.
Modelo de Kruchten (4+1 vistas)
En 1995, Kruchten propuso el siguiente modelo que explica las diferentes vistas que aparecen en la arquitectura del software. El modelo incluye 4 vistas que son consideradas “ortogonales” (lógica, física, de procesos y de desarrollo) y una extra que vincula a las demás (vista de escenarios).
Haz clic en cada concepto para conocer más detalle.
Modelo 4+1 Vistas. Imagen recuperada de Kruchten, P. (1995). Planos arquitectónicos: El modelo “4+1” vistas de la arquitectura del software. IEEE Software, 12(6).
El éxito de las vistas arquitectónicas radica en que cada vista puede ser asignada a grupos diferentes, por ejemplo, el equipo de ingenieros en sistemas pueden enfocarse a realizar la vista física y después la vista de procesos. Los stakeholders pueden validar la vista lógica y los administradores de configuración de software pueden generar la vista de desarrollo.
3.3 Decisiones arquitectónicas
Decidir el diseño arquitectónico del software es un proceso que debe llevarse a cabo con sumo cuidado, ya que de ello dependerá la respuesta que dará el sistema a los requerimientos funcionales y no funcionales documentados en el archivo de especificaciones.
El arquitecto de software debe ofrecer un diseño basado en tipo de sistema a desarrollar, en su experiencia y en su creatividad, por lo que debe tomar decisiones importantes. Recuerda que el arquitecto no está solo en esta labor, es parte de un equipo técnico que, al igual que la etapa de análisis, el diseño arquitectónico se debe ser verificado y validado por todos los involucrados en el proyecto, con el fin de asegurarse que la arquitectura de software es la adecuada para el sistema por desarrollarse.
Somerville (2011) propone algunas preguntas que el arquitecto de software debe responder para realizar un diseño adecuado:
- ¿Existe una arquitectura de aplicación genérica que pueda actuar como una plantilla para el sistema que se está diseñando?
- ¿Cómo se distribuirá el sistema entre varios procesadores?
- ¿Qué estilo o patrones arquitectónicos son apropiados para el sistema?
- ¿Cuál será la aproximación fundamental utilizada para estructurar el sistema?
- ¿Cómo se descompondrán en módulos las unidades estructurales del sistema?
- ¿Qué estrategia se usará para controlar el funcionamiento de las unidades del sistema?
- ¿Qué arquitectura organizacional es mejor para dar solución a los requerimientos no funcionales del sistema?
- ¿Cómo se evaluará el diseño arquitectónico?
- ¿Cómo debería documentarse la arquitectura del sistema?
Al resolver estas preguntas el arquitecto del software o diseñador puede ofrecer un diseño en el que cada decisión tomada está fundamentada en un criterio. Es recomendable que la justificación de estas decisiones sea documentada pues servirá de información contextual a la hora de revisar el diseño arquitectónico del software.
Algunos requerimientos no funcionales que son importantes tomar en cuenta en las decisiones arquitectónicas son las siguientes :
Haz clic en cada concepto para conocer más detalle.
Observa que algunos requerimientos no funcionales pueden entrar en conflicto. Supón que estás en un proyecto de desarrollo de software para un banco. El requerimiento de seguridad es uno de los más importantes, incluso si eso provoca una afectación en el rendimiento. En estos casos es necesario que el usuario tenga claras sus prioridades y puede llegar a una negociación en la que los involucrados estén de acuerdo.
Principios del diseño arquitectónico
En la guía para desarrolladores y arquitectos propuesta por Microsoft (2009) aparecen las siguientes recomendaciones al decidir la estructura arquitectónica del software:
Haz clic en cada concepto para conocer más detalle.
Es importante considerar que cualquier software requiere mantenerse en constante cambio, ya sea para adecuarse a nuevas necesidades internas o para resolver un cambio forzado por alguna entidad externa.
Al modelar la arquitectura del software utilizando diagramas UML es posible realizar un análisis de análisis de riesgos en etapas tempanas del desarrollo del software.
Al modelar la arquitectura del software utilizando diagramas UML es posible realizar un análisis de análisis de riesgos en etapas tempanas del desarrollo del software.
Es recomendable empezar por un diseño que ofrezca una visión panorámica de la arquitectura y seguir con un proceso de evolución en el que se va mejorando el diseño, en lugar de tratar de establecer un diseño que esté completo desde el principio, ya que podría tomar decisiones incorrectas basadas en suposiciones incorrectas.
