Gabriela Quiroga Heredia

ARQUITECTURA DE SOFTWARE

La arquitectura puede definirse como el arte o ciencia de la construcción de edificios para

uso humano. Es ese sentido cabe distinguir entre la acción o proceso de construir, el
“estilo” en los detalles de la estructura y la ornamentación.

Aplicada esta idea a la informática, habría, por tanto, una estructura conceptual y una
organización lógica dentro de una computadora o de un sistema basado en
computadoras, desde el punto de vista de su uso o diseño. Pero también, una realización
particular o física de todo esto.

Las arquitecturas de sistemas están gobernadas por leyes físicas y dichos, sistemas
físicos maduros tienen, a su vez, arquitecturas estables: Aviones, autos y barcos, puentes
y edificios, etc.

Además, dichas arquitecturas surgen de procesos en los que hay experiencia detrás,
conocimientos obtenidos por ensayo y error, reutilización y refinamiento de soluciones
probadas y resultados predecibles.

En el caso del software hay diferencias significativas con las consideraciones que
acabamos de realizar. Así, no hay reglas equivalentes a las de la física. Sino que es
necesario que nosotros las definamos. Esto es así porque el software no es una realidad
tangible por sí misma, como la arquitectura física. Aquí tenemos que hacer modelos,
contemplar muchos estados o situaciones posibles, manejar complejidad, atender a los
cambios en los requerimientos y la tecnología, generar sistemas adaptables, evolutivos y
todo ello procurando un bajo costos de replicación y distribución.

Así, podemos definir la arquitectura del Software como la organización fundamental del
sistema que incluye a sus componentes, sus relaciones entre ellos y el ambiente y los
principios que dictan su diseño y evolución. Involucra un conjunto de decisiones
significativas acerca de la organización del sistema. Selecciona sus elementos
estructurales y sus interfaces. Establece un comportamiento, especificado en función de
la colaboración de los elementos y compone sub-sistemas más grandes a partir de
elementos estructurales y elementos con comportamiento.

¿Cómo establecemos la arquitectura para un sistema informático? Se obtiene mediante

un proceso de partición que relaciona los elementos de una solución de software con
partes de un problema del mundo real definido implícitamente durante el análisis de los
requisitos. La solución aparece cuando cada parte del problema está resuelta mediante
uno o más elementos de software.
Gabriela Quiroga Heredia

El diseño y la especificación completa de la estructura de los sistemas de software se está

transformando en un aspecto de más importancia que la selección de los algoritmos y las
estructuras de datos, en virtud del tamaño y la complejidad de estos es la actualidad.

Características generales de una arquitectura

Diseñar la arquitectura del software es definir los aspectos estructurales como una
composición de componentes, las estructuras globales de control, los protocolos de
comunicación, la sincronización y acceso a los datos, la asignación de la funcionalidad a
los elementos del diseño, la composición de estos elementos, su distribución física, su
escalabilidad y su desempeño. Define al sistema en términos de elementos
computacionales y de las interacciones entre ellos. La arquitectura muestra la
correspondencia entre los requerimientos de sistemas y los elementos del sistema
construido, proveyendo así una exposición racional para las decisiones de diseño.

Elementos Computacionales. Son entidades tales como clientes, servidores, bases de

datos, filtros y capas de un sistema jerárquico. Son además, una parte encapsulada del
sistema de software, donde cada uno tiene una interfaz.

Interacciones. Ocurren entre los elementos a nivel de diseño, pudiendo ser tan simples
como las llamadas a procedimientos o variables de acceso, o tan complejas y
semánticamente ricas como los protocolos del modelo cliente/servidor, los protocolos de
acceso a las bases de datos, la difusión de los eventos asincrónicos y las ráfagas o
stream.

Una relación, además denota una conexión entre los componentes. Una relación puede
ser estática o dinámica.

– Relaciones estáticas. Se muestran en el código fuente, ellas reflejan la colocación de

los componentes dentro de la arquitectura.

– Relaciones dinámicas. Tratan con las conexiones temporales y las interacciones

dinámicas entre los componentes. Ellas no son fácilmente visibles a partir del código
fuente.

Propiedad Funcional. Tiene que ver con un aspecto de la funcionalidad del sistema,
como su nombre lo indica. Está usualmente relacionada con un requerimiento.

Propiedad No Funcional. Trata de una característica del sistema que no está cubierta en
la descripción funcional del mismo. Típicamente se refiere a aspectos tales como
confiabilidad, compatibilidad, costo, facilidad de uso, etc.
Gabriela Quiroga Heredia

Dentro de los niveles en los que podemos descomponer un diseño de software podríamos
hablar de tres: arquitectura, código y el ejecutable.

Arquitectura. Los aspectos de diseño involucran la asociación de la capacidad de todo el

sistema con componentes. Los componentes son módulos y la interconexión entre los
módulos se maneja de maneras diferentes. La composición está orientada hacia
subsistemas.

Código. El diseño involucra algoritmos y estructuras de datos. Los componentes son las
partes primitivas de lenguajes de programación, tales como números, caracteres, etc. Los
mecanismos de composición son arreglos, registros, procedimientos, etc.

Ejecutable. El diseño involucra mapas de memoria, arreglos de datos, asignaciones de

registros, etc. Los componentes son patrones de bits soportados por el hardware y las
composiciones se escriben en lenguaje de máquina.

Centrándonos en la arquitectura, esta debería presentar varias cualidades:

Conformidad Funcional. Una arquitectura de calidad debe implementar todos los

requisitos explícitos contenidos en el modelo de análisis y debe acomodar todos los
requisitos implícitos que desea el cliente. Además, debe proporcionar una idea completa
de que es el software, enfocando los dominios de los datos, las funciones y los
comportamientos. La arquitectura del software le dice a los usuarios exactamente lo que
el sistema de software hará.

Adaptabilidad. Esta característica mide cuan fácil es hacer cambios en una arquitectura;
de seguro, esto implica componentes poco acoplados. Un sistema de software adaptable
tiene una alta trazabilidad; esto quiere decir, que hay una relación clara entre los
diferentes niveles de abstracción.

Modularidad. Sin considerar el enfoque de diseño utilizado (estilo arquitectural), el

proceso de descomposición separa el diseño en partes que lo componen,
llamadas módulos o componentes. Se dice que un sistema es modular cuando cada
actividad del sistema de software es ejecutada exactamente por un componente y cuando
las entradas y las salidas de los componentes están bien definidas. Los módulos se
organizan jerárquicamente como resultado de la descomposición. Estos módulos se
integrarán para satisfacer los requisitos del sistema. Para este autor modularidad es el
atributo del software que permite a un sistema ser manejable intelectualmente. Los
módulos encapsulan información; la ventaja de esta característica es que el diseño interno
de cada componente está oculto para el resto de los otros componentes.
Gabriela Quiroga Heredia

Niveles De Abstracción. Estos módulos se estructuran según niveles de abstracción.

Estos niveles de abstracción ayudan a entender el problema a ser resuelto por el sistema
y la solución propuesta. Cuando se plantea una solución modular se pueden presentar
muchos niveles de abstracción. Cada fase del proceso de diseño es un refinamiento en el
nivel de abstracción. Habría tres niveles de abstracción:

– Abstracción procedimental. Es una secuencia dada de instrucciones que tiene una

función específica y limitada.

– Abstracción de datos. Es una colección determinada de datos que describen un objeto

de datos.

– Abstracción de control. Implica un mecanismo de control del programa sin especificar

detalles internos.

Entendible. Un sistema antes de hacerle un cambio debe ser entendido. Este

entendimiento estará afectado por: La cohesión, el acoplamiento, la nominación, la
documentación y la complejidad; inclusive, la complejidad tiene una relación directa con
su fácil entendimiento.

Cohesión. Es una consecuencia del ocultamiento de la información. Un módulo con

cohesión realiza solamente una tarea, requiriendo poca interacción con el resto de los
procedimientos que se realizan en el resto del sistema de software. La cohesión es
deseable debido a que una unidad (componente) representa una parte simple de solución.
Si es necesario cambiar el sistema, la parte correspondiente está en un solo lugar y lo que
se desee hacer con él estará encapsulado en él. La meta es hacer que los componentes
sean lo más cohesivos posible.

Acoplamiento. Está relacionado con la cohesión. Es un indicador de la fuerza de

interconexión entre los componentes o elementos de la arquitectura. Sistemas altamente
acoplados tienen una fuerte interconexión, lo que se refleja en una gran dependencia
entre los componentes. Los sistemas poco acoplados, por otro lado, tienen poca relación
entre sus componentes o elementos. La meta es mantener el acoplamiento en el nivel
más bajo posible; la conectividad sencilla entre módulos da como resultado un software
que es más fácil de comprender y menos propenso al “efecto onda” producido cuando los
errores aparecen en una posición y se propagan a lo largo del sistema. El acoplamiento
depende de la complejidad de las interfaces entre los módulos, del punto en el que se
hace una entrada o referencia a un módulo y de los datos pasan a través de esa interfaz.

Por lo tanto, la arquitectura debe poseer unos ciertos atributos de calidad. Pero lo más
interesante del caso es que cada decisión incorporada en una arquitectura de software
puede afectar potencialmente dichos atributos de calidad. Lo cierto es que los atributos no
Gabriela Quiroga Heredia

están aislados ni son independientes entre sí. El análisis de atributos no se presta a

estandarizaciones y las técnicas de análisis son específicas para un atributo en particular.

¿Por qué es importante la arquitectura de software?

La arquitectura de software es de especial importancia ya que la manera en que se

estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer
lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de
calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las
peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les
resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que
tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de
calidad son parte de los requerimientos (no funcionales) del sistema y son características
que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el
sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”,
ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos.

La manera en que se estructura un sistema permitirá o impedirá que se satisfagan los

atributos de calidad. Por ejemplo, un sistema estructurado de tal manera que una petición
deba transitar por muchos componentes antes de que se devuelva una respuesta podría
tener un desempeño pobre. Por otro lado, un sistema estructurado de tal manera que los
componentes estén altamente acoplados entre ellos limitará severamente la
modificabilidad. Curiosamente, la estructuración tiene un impacto mucho menor respecto
a los requerimientos funcionales del sistema. Por ejemplo, un sistema difícil de modificar
puede satisfacer plenamente los requerimientos funcionales que se le imponen.

Además de los atributos de calidad, la arquitectura de software juega un papel

fundamental para guiar el desarrollo. Una de las múltiples estructuras que la componen se
enfoca en partir el sistema en componentes que serán desarrollados por individuos o
grupos de individuos. La identificación de esta estructura de asignación de trabajo es
esencial para apoyar las tareas de planeación del proyecto.

Finalmente, los diseños arquitectónicos que se crean en una organización pueden ser
reutilizados para crear sistemas distintos. Esto permite reducir costos y aumentar la
calidad, sobre todo si dichos diseños han resultado previamente en sistemas exitosos.

Los requerimientos del software moderno son cada vez más complejos puesto que los
usuarios esperan más de sus aplicaciones. Las aplicaciones de escritorio independientes
y sencillas ya no son lo suficientemente buenas en la mayoría de los escenarios
comerciales y empresariales. En nuestro mundo conectado, la aplicación debe interactuar
con otras aplicaciones y servicios y ejecutarse en una serie de entornos, como la nube, y
en dispositivos portátiles. Los diseños monolíticos comunes en el pasado se han
reemplazado por software componentizado orientado al servicio, que utiliza marcos,
sistemas operativos, hosts en tiempo de ejecución y redes para implementar
características que eran insólitas hasta hace unos pocos años.
Gabriela Quiroga Heredia

Esta complejidad afecta no sólo al diseño, sino también a la implementación,

mantenimiento y administración del software. El costo total de propiedad (TCO) del
software ahora se compone predominantemente de costos posteriores a la
implementación. Una aplicación con buena arquitectura minimizará el TCO al reducir el
costo y tiempo requeridos para implementar la aplicación, mantenerla en ejecución,
actualizarla para cumplir con los requisitos cambiantes y solucionar problemas. Además
simplificará el soporte técnico y la administración por parte del usuario.

El software también debe cumplir varios criterios fundamentales para tener éxito. Debe
proporcionar seguridad de manera que la aplicación y sus datos estén protegidos contra
ataques malintencionados y errores accidentales. Debe ser robusto y confiable para
minimizar los errores y los costos asociados. Debe ejecutarse dentro de los parámetros
requeridos para satisfacer las necesidades del cliente, como un tiempo de respuesta
máximo o una capacidad de carga de trabajo específica. Debe ser sostenible para poder
minimizar los costos de administración y soporte técnico y suficientemente extensible para
permitir los cambios y actualizaciones inevitables que se requerirán con el tiempo.

Todos estos factores implican algunas desventajas. Por ejemplo, la implementación de los
mecanismos más seguros mediante un cifrado complejo afectará el rendimiento. La
implementación de opciones de configuración y actualización de amplio rango puede
hacer que la implementación y administración sean más complicadas. Además, cuanto
más complejo sea el diseño, más costará implementarlo. Una buena arquitectura tendrá
como objetivo equilibrar estos factores para producir el resultado óptimo en el escenario
específico.