Autor: Liusba Cañete Núñez / liusba.canete@ltu.jovenclub.cu

Introducción

Ejemplo de una Arquitectura de Software1En la actualidad, el proceso de desarrollo de software ha aumentado progresivamente, teniendo como resultado la construcción de grandes y complejos sistemas que requieren la combinación de diferentes tecnologías y plataformas de software y hardware para alcanzar las funcionalidades requeridas. En consecuencia, el producto resultante debe ser flexible y muy específico para la solución de un problema concreto, por lo que los desarrolladores deben definir el conjunto de requisitos críticos, funcionales, de rendimiento y/o de calidad que permita dar solución al problema, teniendo en consideración cómo el software debe solucionar sus objetivos, es decir, definir el conjunto de estructuras, clases y atributos principales del software y sus interfaces de comunicación. El problema radica en saber priorizar la definición, el diseño, la implementación y la evaluación de la Arquitectura del Software (en lo adelante AS), por lo que el presente artículo tiene como objetivo situar al lector en qué es la AS y cuáles son los beneficios de la definición de la misma en un proyecto de software, aportando conocimientos referentes a este amplio mundo de la AS.

Desarrollo

La Arquitectura de Software permite evaluar la solución de un software desde las primeras fases de su desarrollo, aportando numerosos beneficios a cualquier proyecto de software que se realice. El presente trabajo tiene como objetivo situar al lector en qué es la Arquitectura de Software y cuáles son los beneficios de la definición de la misma en un proyecto de software. Se utilizaron métodos de investigación teóricos como: el analítico, el histórico y el lógico para la construcción y desarrollo de esta investigación, los cuales permitieron profundizar en el conocimiento de las características esenciales de la Arquitectura de Software. Para las fuentes se utilizó investigación bibliográfica, permitiendo realizar la búsqueda, recopilación, revisión, organización y valoración de la bibliografía.

“La AS es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos, el ambiente y los principios que orientan su diseño y evolución”, así lo plantea el estándar IEEE Std 1471-2000.

Definir la AS permite dedicar los mínimos esfuerzos a implementar un prototipo estable de arquitectura que garantice una demostración tangible de la viabilidad del proyecto en fases tempranas. “La AS, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requisitos de desempeño de un sistema, así como requerimientos no funcionales, como: la confiabilidad, escalabilidad, portabilidad y disponibilidad” (Kruchten, 1995).

En otras palabras, la AS es el diseño de más alto nivel de la estructura de un sistema, por lo que debe dar garantías de que la solución diseñada es realizable dentro de las restricciones de tiempo, personal y presupuesto, o sea, que el proyecto es viable.

Una definición reconocida de AS es la aportada por Clements: “La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar el objetivo del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de compresión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones” (Clements, 1996). Por otro lado Kazman plantea: “La AS es importante como disciplina debido a que los sistemas de software crecen de forma tal que resulta muy complicado que sean diseñados, especificados y entendidos por un solo individuo. Uno de los aspectos que motivan el estudio en este campo es el factor humano, en términos de aspectos como inspecciones de diseño, comunicación a alto nivel entre los miembros del equipo de desarrollo, reutilización de componentes y comparación a alto nivel de diseños alternativos” (Kazman, 1996).

En efecto, la definición de la AS trae numerosos beneficios para un proyecto de software ya que permite la evaluación de la solución desde fases muy tempranas de desarrollo; los componentes de una arquitectura pueden ser reutilizados en la creación de otros sistemas de software; propicia la construcción incremental del software y las correspondientes actividades de verificación; posibilita atender y resolver, en etapas tempranas, los riesgos relacionados con la arquitectura que, por lo general, coinciden con aquellos que pueden conducir a mayores daños; aumenta la satisfacción y compromiso de clientes y usuarios y ayuda a mantener alta la moral del equipo de desarrollo.

Conclusiones:

La clave del éxito consiste en definir qué es y qué no es la arquitectura; sus componentes deben ser los suficientes para garantizar la viabilidad del proyecto, debido a que la AS encierra los mayores riesgos de desarrollo y un paso en falso puede traer consigo costosos resultados en cuanto a tiempo, esfuerzo y recursos en general. Al mismo tiempo, la definición de la AS aporta numerosos beneficios, tanto al software como al equipo de desarrollo, al ser la reutilización de sus componentes y poder determinar la viabilidad del proyecto en las fases más tempranas del desarrollo, algunos de los beneficios más importantes.

Referencias Bibliográficas:

Clements, P. (1996). “A Survey of Architecture Description Languages”. Pro-ceedings of the International Workshop on Software Specification and Design. Alemania.

Group, A. W. (14 de nov. de 2000). IEEE 1471. IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems . Institute of Electrical and Electronics (IEEE).

Kazman, R. (1996). Tool Support for Architecture Analysis and Design. Department of Computer Science, University of Waterloo. Recuperado el 10 de mayo de 2002, de ftp://ftp.sei.cmu.edu/pub/sati/Papers_and_Abstracts/ISAW-2.ps.

Kruchten, P. (1995). «Architectural Blueprints–The 4+1 View Model of Software Architecture». IEEE Software, Institute of Electrical and Electronics Engineers.

Group, A. W. (14 de nov. de 2000). IEEE 1471. IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems . Institute of Electrical and Electronics (IEEE).

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *