ARQUITECTURA
DE SOFTWARE
Gustavo Enrique Tabares Parra
EJE 1
Conceptualicemos
Fuente: Adobe/Stock 585614130
Rol del arquitecto de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
¿Por qué es tan importante la arquitectura? . . . . . . . . . . . . . . . . . . . . . . . 7
Diseño arquitectónico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Decisiones arquitectónicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Estilos de arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Arquitectura de flujo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Arquitectura de llamar y regresar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Arquitectura orientada a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Arquitectura en capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Rol del arquitecto de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Normas y marcos IEEE Estándar 1471 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Vistas arquitectónicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Pipeline (tuberías y filtros) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Zachman Enterprise framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ÍNDICE
Actualmente, no existe una definición concreta para el concepto
de arquitectura de software, pues el concepto ha sido abordado por
varios autores, teniendo claro la definición más clara la expuesta por
la IEEE Std 1471-2000: “La arquitectura de software es la organización
fundamental de un sistema enmarcada en sus componentes, las rela-
ciones entre ellos, y el ambiente, y los principios que orientan su diseño
y evolución” (ISO/IEC/IEEE, 2013).
Cuando se diseña una arquitectura de software, se definen y se
INTRODUCCIÓN
crean representaciones de componentes que interactúan entre sí,
con funciones específicas y organizadas dando cumplimiento a los
requerimientos establecidos. Aplicando patrones de solución que son
conocidos como estilos arquitectónicos y patrones de diseño.
A continuación, se abordan las generalidades y características de
la arquitectura de software.
Rol del arquitecto
de software
Arquitectura de software
De acuerdo con Pressman (2010) “la arquitectura del software de un programa o
sistema de cómputo consiste en la estructura o estructuras del sistema, integrando los
componentes del software, sus propiedades externas visibles y las relaciones entre ellos”
(p. 207).
La arquitectura no consiste en el software funcional, es una
estructura que permite:
Pertinente:
Del lat. pertînens, -entis, part.
• Analizar la pertinencia del diseño para satisfacer los reque- pres. act. de pertinere 'pertene-
cer', 'concernir'.
rimientos definidos.
1. adj. Perteneciente o correspon-
• Evaluar alternativas arquitectónicas en una etapa del diente a algo. Un teatro con su
pertinente escenario.
proyecto en la que hacer cambios al diseño del proyecto
todavía es relativamente fácil.
2. adj. Que viene a propósito. Ese
argumento sobra y no es aquí
• Reducir los riesgos relacionados con la construcción del pertinente (RAE).
software.
Este concepto representa la función de los componentes del software en un esquema
arquitectónico. En el contexto del diseño de la arquitectura, un elemento o componente
de software puede representar un módulo o una clase abstracta del programa, un objeto,
también puede integrar bases de datos, la configuración o representación de una red de
cliente y servidores.
Los componentes se relacionan e interactúan entre sí, a través de sus propiedades y
características. En la definición del nivel arquitectónico no se detallan las propiedades
internas como especificaciones del algoritmo a utilizar. La relación entre componentes
puede ser algo simple, derivado de una invocación de un procedimiento o un módulo a
otro, como también más complejos al igual que un protocolo para acceder a una base
de datos (Pressman, 2010, p. 207).
Según Pressman (2010):
”
Hay una diferencia entre los términos arquitectura y diseño.
Un diseño es una instancia de una arquitectura, similar a un
objeto que es una instancia de una clase. Por ejemplo, con-
sidere la arquitectura de cliente-servidor. Con esta arquitec-
tura es posible diseñar de muchos modos un sistema de sof-
tware basado en red, con el uso de una plataforma Java (Java
Arquitectura de software - eje 1 conceptualicemos 5
EE) o Microsoft (estructura .NET). Entonces, hay una arqui-
tectura, pero con base en ella pueden crearse muchos dise-
ños. Así, no es válido mezclar arquitectura y diseño. (p. 208)
La fase del diseño de software es una instancia derivada de una arquitectura espe-
cífica definida del software, cada elemento, cada estructura que se defina, derivan el
origen del diseño que evoluciona a partir de ellos. El diseño parte de la consideración de
la arquitectura (Pressman, 2010, p. 208).
Instrucción
Para profundizar más en el concepto de programación
orientada, los invitamos a visualizar el recurso de apren-
dizaje “Animación”.
¿Por qué es tan importante la arquitectura?
Se identifican tres aspectos clave por los que es importante la arquitectura de sof-
tware, como lo menciona Pressman (2010):
• La definición de la arquitectura del software establece la comunicación entre
todos los componentes interesados para la construcción de un sistema de software
basado en computadora.
• La arquitectura enmarca las primeras decisiones que tendrán como resultado un
efecto profundo y significativo en todo el ciclo de vida del software y, también
importante, en el éxito final del sistema como entidad operacional.
• La arquitectura la conforma un modelo relativamente pequeño y asequible, mos-
trando como está definido y estructurado el sistema y la interacción de los com-
ponentes que la integran (p. 208).
Arquitectura de software - eje 1 conceptualicemos 6
La definición de un modelo de arquitectura, patrones arquitectónicos son transferibles
entre capas. Como son los estilos, los géneros, patrones y componentes como pueden
aplicarse al diseño de otros sistemas, representando una variedad de abstracciones que
le ayudan y facilitan a los arquitectos de software describir la arquitectura en formas
predecibles.
Video
Para mayor comprensión del rol de arquitectura de sof-
tware, invitamos a ver la siguiente videocápsula.
IngSoft – Arquitectura
[Link]
Diseño arquitectónico
El diseño arquitectónico como lo menciona Sommerville (2011), se interesa por com-
prender cómo se debe organizar adecuadamente un sistema, como debe definirse el
diseño estructural general de ese sistema.
El diseño arquitectónico es la fase inicial de una metodología de diseño de software,
establece un vínculo crucial entre la fase de diseño y la ingeniería de requerimientos y
así define la relación entre la estructura de los componentes principales del sistema y
la interacción entre estos. La respuesta que genera el proceso de diseño arquitectónico
está basada en un modelo arquitectónico que demuestra la forma en la que estructura
el sistema con un conjunto de componentes relacionados y en comunicación (p. 148).
Según Sommerville (2011), en los procesos con metodologías ágiles, no es recomen-
dable el desarrollo incremental de arquitecturas, mientras que la redefinición de com-
ponentes frente a los cambios es relativamente fácil, tal vez en las primeras etapas de la
fase del desarrollo debe ser la definición de una arquitectura del
sistema de forma global. (p. 148).
Abstracto, ta:
La figura 1 despliega la arquitectura de un sistema de un Del lat. tardío abstractus; pro-
modelo muy abstracto de la arquitectura para un sistema auto- piamente 'apartado, separado'.1.
adj. Que significa alguna cuali-
matizado a través de un robot de empaquetado, desplegando dad con exclusión del sujeto.2.
los componentes a desarrollarse. adj. Dicho de una obra de arte
o de un artista: que sigue el arte
abstracto (RAE).
Arquitectura de software - eje 1 conceptualicemos 7
El sistema integra diferentes clases de objetos de una banda transportadora, selecciona
y aplica el tipo de empaque de acuerdo con la clase de objeto identificado, posterior-
mente el sistema traslada los objetos que se van a guardar de la banda transportadora
de entrega y los ubica en otro transportador, la definición del modelo arquitectónico a
construir debe integrar dichos componentes y las relaciones entre ellos.
Figura 1.
Arquitectura de un sistema de control para un robot empacador
Fuente: tomado de Sommerville (2011).
Sommerville (2011) menciona que la arquitectura de software juega un papel impor-
tante porque de esta depende el rendimiento y la potencia del sistema, como también
su facilidad de distribución y el mantenimiento del sistema. Los componentes implemen-
tados representan la implementación de los requerimientos funcionales (RF) analizados
del sistema, mientras que los requerimientos no funcionales (RNF) dependen estricta-
mente de la estructura de arquitectura definida del sistema, la forma en que se definen,
organizan y relacionan. En una gran parte de los sistemas (RNF) los requerimientos no
Arquitectura de software - eje 1 conceptualicemos 8
funcionales se relacionan por componentes individuales, sin perder la influencia domi-
nante de la arquitectura del software (p. 149).
Siguiendo a Sommerville (2011), él describe algunas ventajas de definir un diseño y
documentarlo de forma detallada definida en la arquitectura de software.
• Comunicación con los participantes: la arquitectura es una exposición de alto
nivel del sistema, la cual es usada en diferentes enfoques para analizar y discutir
con un amplio número de participantes.
• Análisis del sistema: en una fase inicial del desarrollo del sistema, definir de forma
detallada la arquitectura del sistema es importante realizar un buen análisis. Las
decisiones que se concluyan para definir el diseño arquitectónico tienen una impor-
tancia muy profunda sobre si el sistema puede o no cumplir con especificaciones
críticas como el rendimiento, la fiabilidad y la mantenibilidad del sistema.
• Reutilización a gran escala: un modelo de una arquitectura de sistema es una
definición corta, detallada y de fácil operabilidad para organizar un sistema y cómo
se relacionan e interactúan sus componentes. Cuando los requerimientos de un
sistema son muy similares a otros sistemas, la arquitectura del sistema es la misma
generalmente y, por lo que es importante la reutilización de diseños de componen-
tes, de código de software. Es factible desarrollar arquitecturas cuando hay una
relación similar entre productos, reutilizando la misma arquitectura mediante una
variedad de sistemas relacionados (p. 149).
Instrucción
Para profundizar más en el concepto de programación
orientada, los invitamos a visualizar el recurso de apren-
dizaje “Línea de tiempo”.
Decisiones arquitectónicas
Cada aspecto desarrollado como elemento de una descripción arquitectónica se aboca
a una preocupación de un participante específico. Para desarrollar cada aspecto, el
arquitecto evalúa varias posibilidades y toma la decisión en última instancia de las carac-
terísticas arquitectónicas identificadas que cumplan de mejor forma la especificación.
Arquitectura de software - eje 1 conceptualicemos 9
Estilos de arquitectura
Un estilo arquitectónico está conformado por un conjunto totalmente coordinado de
restricciones arquitectónicas que controla las funciones / características de los elemen-
tos arquitectónicos y las relaciones establecidas entre sus elementos de la arquitectura
establecida.
A la fecha se han desarrollado un gran número de sistemas basados en computado-
ras, gran parte de estos se clasifican en grupos relativamente pequeños de estilos de
arquitectura.
Pressman (2010) clasifica la arquitectura en los siguientes grupos:
• Arquitecturas centradas en los datos.
• Arquitectura de flujo de datos.
• Arquitectura de llamar y regresar.
• Arquitectura orientada a objetos.
• Arquitectura en capas.
Arquitecturas centradas en los datos: está enfocada en el
repositorio de almacenamiento de datos de archivos, bases de Repositorio:
Del lat. repositorium 'armario,
datos que pueden acceder con frecuencia otros componentes alacena'.1. m. Lugar donde se
que realizan operaciones como agregar, eliminar o modificar los guarda algo (RAE).
datos de su repositorio.
La figura 2 muestra un esquema centrado en datos, donde la aplicación cliente accede
a un repositorio central. En muchos casos este estilo es pasivo, la aplicación cliente accede
a la información de forma independiente a los cambios que estos sufran o las acciones
realizadas por software de otros clientes.
Este tipo de arquitecturas promueven la integridad de los datos, o sea, los componen-
tes de software pueden ser modificados y adicionar nuevos componentes del cliente a la
arquitectura sin que afecte a otros clientes, ya que estos operan de forma independiente,
facilitando el paso de datos entre clientes de la arquitectura a través de un tablero que
envía notificaciones a la aplicación cliente cuando se presente un cambio considerable
del cliente (Pressman, 2010, p. 213).
Arquitectura de software - eje 1 conceptualicemos 10
Figura 2.
Estilo de arquitectura centra en datos
Software Software Software
cliente cliente cliente
Software Software
Almacenamiento de
cliente cliente
datos (repositorio)
Software Software Software
cliente cliente cliente
Fuente: Pressman (2010).
Instrucción
Para profundizar más en este concepto, los invitamos a
desarrollar la actividad de aprendizaje “Práctica”.
Arquitectura de flujo de datos
De acuerdo con Pressman (2010), esta arquitectura se aplica
cuando los datos de entrada sufren una transformación que
generan datos de salida, mediante componentes computacio- Patrón, na:
Modelo que sirve de muestra
nales o manipuladores. Un patrón de flujo y filtro está formado para sacar otra cosa igual (RAE).
por un conjunto de componentes llamados filtros, conectados
por flujos que transmiten datos de un componente a otro.
Arquitectura de software - eje 1 conceptualicemos 11
Cada filtro de la arquitectura se ejecuta de forma independiente de los componentes
que lo integran, son diseñadas para recibir una entrada de datos y generar una salida
al siguiente filtro de alguna forma específica. Un filtro no requiere de la información
generada por filtros vecinos (p. 213).
Si el flujo de datos degenera en una sola línea de transformaciones, se deno-
mina lote secuencial. Esta estructura acepta un lote de datos y luego aplica una
serie de componentes secuenciales (filtros) para transformarlos. (Pressman,
2010, p. 213)
Figura 3.
Estilo de arquitectura de flujo de datos
Flujos de salida Filtro Filtro Flujos de
salida
Filtro Filtro Filtro Filtro
Flujos de Filtro Filtro Filtro
salida
Filtro
Fuente: Pressman (2010).
Arquitectura de llamar y regresar
Según Pressman (2010), esta arquitectura muestra una estructura de programa fácil
de modificar y escalar, bajo esta arquitectura existen varios tipos.
Arquitectura de software - eje 1 conceptualicemos 12
• Arquitectura de programa principal/subprograma. Esta arquitectura tradicional
de programa descompone una función en una estructura jerárquica de control de
un programa principal, integra varias componentes de programa y estos a la vez
invoca a otros componentes como muestra la figura 4 una arquitectura de llamar
y regresar.
• Arquitectura de llamada de procedimiento remoto. Los Remoto, ta:
componentes que integran esta arquitectura de programa el lat. remõtus, part. pas. de re-
principal-subprograma están en múltiples redes de com- movēre 'retirar, apartar'.1. adj.
Muy lejano. Una aldea remota.
putadores (p. 214). Tiempos remotos (RAE).
Figura 4.
Estilo de arquitectura de programa principal-subprograma
Programa principal
Subprograma Subprograma Subprograma
controlador controlador controlador
Subprograma Subprograma Subprograma Subprograma Subprograma
de aplicación de aplicación de aplicación de aplicación de aplicación
Subprograma
de aplicación
Subprograma
de aplicación
Fuente: Pressman (2010).
Arquitectura de software - eje 1 conceptualicemos 13
Lectura recomendada
Con el fin de profundizar en el tema arquitectura de software, invitamos a
revisar la lectura complementaria dispuesta en la plataforma de estudio.
Ingeniería de software. Un enfoque práctico (Cap. 9)
Roger Pressman
[Link]
[Link]
Arquitectura orientada a objetos
Los componentes que integran un sistema contienen datos y operaciones que deben
programarse. Los objetos se comunican a través del intercambio de mensajes.
Arquitectura en capas
La arquitectura en capas está conformada por un número de capas diferentes, cada
una ejecuta funciones y operaciones que se aproximan progresivamente a instrucciones
de máquina. Los componentes de la capa externa se encargan de la interfaz de usuario,
la capa interna consume servicios y funciones de software de la aplicación.
Estos estilos arquitectónicos son solo un pequeño grupo de los que están disponibles.
Una vez la fase de análisis de requerimientos define las características y las restricciones
del sistema que se va a construir, se selecciona el estilo arquitectónico o los patrones que
apliquen mejor a esas características y restricciones.
En muchos casos, se aplica más de un patrón y es recomendable diseñar y evaluar
algunos estilos arquitectónicos alternativos. Por ejemplo, en aplicaciones con bases de
datos se combina un estilo en capas (apropiado para la mayoría de los sistemas) con
una arquitectura específica centrada en datos (Pressman, 2010, p. 215).
Instrucción
Para profundizar más en el concepto de programación
en Python, los invitamos a desarrollar la actividad de
aprendizaje “Simulación”.
Arquitectura de software - eje 1 conceptualicemos 14
Rol del arquitecto de software
Según Sommerville (2011), el contar un arquitecto que esté enfocado la visión y que
garantice su cumplimiento logra un proyecto de software éxito y de calidad (p. 17).
El arquitecto del sistema evalúa un estilo arquitectónico adecuado partiendo de los
requerimientos definidos durante la fase de análisis de los datos y sigue con la definición
de una o más vistas de la estructura arquitectónica del sistema.
Se realiza un análisis de opciones de estilos y patrones arquitectónicos para así defi-
nir la estructura más apropiada que cumpla con las especificaciones del usuario y los
atributos de calidad. Ya definida la arquitectura se construye a través de un método de
diseño (Somerville 2011, p. 209).
Con base en Sommerville (2011), el arquitecto del sistema evalúa varias opciones y
aplica en última instancia las características arquitectónicas específicas que cumplan de
la mejor forma la preocupación. Entonces, las decisiones arquitectónicas en sí mismas
se consideran una perspectiva de la arquitectura. Los criterios por las que se tomaron
las acciones dan una visión de un sistema y su concordancia con las especificaciones del
participante (p. 209).
Las tareas del ciclo de desarrollo de software son responsabilidad del arquitecto de
software, y esta acción puede ser desarrollada por un individuo o un equipo de arquitectos
del proyecto. El arquitecto de software debe ser una persona líder técnica con la función
principal de tomar las decisiones necesarias de diseño pertinentes, para satisfacer los
drivers arquitectónicos y poder cumplir con las funcionalidades específicas del sistema,
este debe conocer a profundidad el problema.
Adicionalmente, el arquitecto debe expresar sus decisiones, verificar que durante la
evolución del proyecto estas se lleven a cabo y sean cumplidas por parte de los miembros
del equipo de desarrollo.
Humberto, et al. (2016) exponen los aspectos relacionados con la especificación de
requerimientos, comunicación del diseño y guía al equipo de desarrollo, se requiere de
una variedad de habilidades “suaves”, no técnicas incluyendo liderazgo, capacidad de
negociación, y una excelente habilidad de comunicación verbal y escrita.
Actualmente, muchas compañías de desarrollo de software tienen arquitectos para
el desarrollo de proyectos, aunque no forzosamente se tiene tanta claridad respecto de
las funciones que deben realizar. Aun con esto, es importante mencionar que, en el año
2015, el sitio de CNN Money tenía la labor de los arquitectos de software como el primero
de los cien mejores trabajos en Estados Unidos.
Arquitectura de software - eje 1 conceptualicemos 15
Actualmente, los arquitectos que están al frente en la industria del desarrollo de sof-
tware han recibido una formación teórica y poca práctica en el tema. Esto se debe a
que no es, sino hasta en épocas recientes que se han establecido de manera formal los
conceptos relacionados con la arquitectura de software y que muy pocas instituciones
ofrecen cursos orientados en el tema. Con frecuencia, el desconocimiento y la falta de
experiencia en los principios relativos de la arquitectura se refleja de manera negativa
en los proyectos de desarrollo (p. 25).
Video
En este punto de estudio y para mayor comprensión
del tema de objetos, los invitamos a ver la siguiente
videocápsula.
El rol de arquitecto en la arquitectura de software
[Link]
Normas y marcos IEEE Estándar 1471
La Norma 1471 de IEEE Computer Society surgió en el 2000 como un estándar que
organiza el desarrollo de sistemas de software basados en descripciones arquitectónicas
DA y define el guion o framework de trabajo conceptual de la descripción arquitectónica,
también establece el contenido y las características de estas.
Navasa (2008) menciona que la AS tiene una gran importancia en el desarrollo de
sistemas. Aunque la arquitectura no se ha aplicado apropiadamente hasta que surgió
la norma como pensamiento arquitectónico que permitiera la aplicación y evolución de
las prácticas arquitectónicas.
Actualmente, debe aplicarse conceptos arquitectónicos a la construcción de sistemas
con la intención de reducir costos y lograr la calidad de los sistemas. Partiendo el objetivo
del Estándar 1471 que facilita la comunicación de las arquitecturas, estableciendo las
bases para el desarrollo de calidad y reducción de costos, por medio de la estandariza-
ción y aplicación de elementos de la estructura arquitectónica, basadas en la norma que
contiene recomendaciones de cómo implementar las descripciones arquitectónicas en
la construcción de un sistema. No se basa en definir una propuesta de una arquitectura
estándar, sino en definir un proceso arquitectónico o definir un método, sino en definir
un conjunto de recomendaciones prácticas para la definición de arquitecturas.
Arquitectura de software - eje 1 conceptualicemos 16
La norma está integrada por una variedad de descripciones arquitectónicas que son
necesarias para la implementación en el desarrollo de sistemas y su evolución, la comu-
nicación permanente entre usuarios y desarrolladores, la revisión y comparación de la
arquitectura, la planeación ordenada, la gestión del proyecto, la especificación de carac-
terísticas persistentes, el control y supervisión de los cambios.
La norma de IEEE describe tendencias que son tenidas en cuenta por los equipos de
trabajo para la definición arquitectónica a través de la implementación de framework
que estructuran el desarrollo del sistema. El framework presenta conceptos y términos de
referencia. Enfocados en los parámetros en los que hay consenso, para el uso de múltiples
vistas, funcionalidades reutilizables en modelos de vistas y la relación de la arquitectura
establecida con el contexto del sistema (Navasa, 2008, p. 75).
A continuación, se hace una descripción de algunas definiciones del Estándar 1471,
entre las que se destacan, según Navasa (2008):
• Descripción arquitectónica (architectural description) DA: consiste en un con-
junto de productos, elementos y conceptos totalmente integrados que permiten
documentar la arquitectura sin especificar su formato, sino que describe algunos
contenidos mínimos que la describen.
• Arquitectura: es la organización de los elementos que forman el sistema com-
puesto por una variedad de componentes, las relaciones y el entorno en el que se
desarrolló el sistema, así como los principios que establecen su diseño y evolución.
• Vista (view): representación de un sistema desde la perspectiva de un conjunto
de aspectos relacionados. Un despliegue arquitectónico puede estar conformado
por una o más vistas; y una vista puede contener uno o más modelos arquitectó-
nicos, facilitando así la utilización de múltiples notaciones para representarla. Las
descripciones arquitectónicas ayudan a detectar inconsistencias que se presentan
entre las vistas y el sistema.
• Punto de vista (viewpoint): es una especificación que permite construir y usar
una vista. Haciendo uso de un patrón para construir vistas, que definen puntos de
vista defiendo reglas sobre las vistas (p. 76).
Este marco de desarrollo se genera para definir los términos y conceptos relativos al
contenido y aplicación de las descripciones arquitectónicas como muestra la figura 5
según Navasa (2008):
• Sistema: son todas las aplicaciones, subsistemas, líneas de producto, categorías
u otro elemento de interés relacionados del sistema. Todo sistema se desempeña
en un ambiente y este influye en él.
Arquitectura de software - eje 1 conceptualicemos 17
• Entorno o contexto: establece un ambiente de elementos de varios tipos que inte-
ractúan con el sistema. El entorno también puede ser otro sistema que interactúa
estableciendo límites.
• Concerns (competencia): son aspectos o temas de interés acordes al sistema en
desarrollo, sus operaciones u otro aspecto importante para un actor del sistema.
Los concerns incluyen características del sistema como ejecutabilidad, la fiabilidad,
la seguridad, la distribución o evolución del sistema, cada concern está represen-
tado por una vista arquitectónica.
• Stakeholders (actor): los sistemas pueden tener uno o más stakeholders que
interactúan con el entorno del sistema, cada stakeholder tiene una función en el
sistema desde algún punto de vista.
• Misión: es una función u operación de un actor sobre el sistema para lograr un
objetivo, la esencia de un sistema es realizar una o varias misiones en su entorno.
• Arquitectura: todo sistema debe tener una arquitectura gestionada por una des-
cripción arquitectónica. La norma IEEE 1471 diferencia la arquitectura del sistema
conceptual y las descripciones particulares de la arquitectura como son los pro-
ductos o artefactos de software concretos.
• Stakeholder: es una persona que interactúa con el sistema en desarrollo o que se
va a desarrollar, por lo general son usuarios en diferentes categorías como clientes,
propietarios, usuario del sistema, integrantes del equipo de desarrollo durante todas
las fases del ciclo de vida del proyecto como ingeniero de sistemas, arquitectos,
diseñadores, proveedores, etc., por lo que se representa en el diseño con el nombre
de “actor”.
• Descripción arquitectónica: está compuesta por una o varias vistas, cada vista
representa uno o más concerns. Cada vista muestra la expresión de una arquitec-
tura de un sistema con relación a un punto en particular.
• Punto de vista: define los aspectos que conforman o se crea una vista, una vista
puede estar conformada por varios puntos de vista. El punto de vista determina
el lenguaje que se usa para describir la vista, así como cualquier otro método de
modelado o técnica de análisis que se use para representarla. Una representación
arquitectónica está conformada por una o varios puntos de vista. Un punto de
vista se construye basado en las consideraciones de los actores o stakeholders que
definen las descripciones arquitectónicas y en sus concerns.
• Una vista la puede conformar uno o varios modelos arquitectónicos, cada modelo
se construye usando los métodos establecidos por sus puntos de vista relacionados
(p. 77).
Arquitectura de software - eje 1 conceptualicemos 18
Figura 5.
Marco conceptual de la norma IEEE
Misión
cumple 1...*
influencia posee una
Entorno Sistema Arquitectura
se ubica
tiene 1...* descrito por
identifica 1...* Descripción de
Actor Base lógica
la Arquitectura provee
está dirigido a 1...* participa en
tiene 1...* organizado en
identifica 1...* selecciona 1...* 1...*
conforme a
Competencia Punto de vista Vista agrega 1...*
usado consiste en
para 1...*
cubrir 1...*
tiene como
fuente 0..1 Modelo
Librería de establece métodos
punto de vista para 1...*
Fuente: Navasa (2008).
Vistas arquitectónicas
Los modelos arquitectónicos derivados del sistema representan el análisis de los reque-
rimientos o el diseño de software. De forma alternativa, se puede documentar un diseño
usándolo como base en el diseño y la implementación más específica, y en la evolución
del sistema, hay dos temas muy relevantes como lo menciona Sommerville (2011).
Arquitectura de software - eje 1 conceptualicemos 19
• ¿Qué vistas o perspectivas son útiles al diseñar y documentar una arquitectura del
sistema?
• ¿Qué notaciones deben usarse para describir modelos arquitectónicos? (p. 153)
No se puede representar toda información derivada de un escenario sobre la arqui-
tectura de un sistema en un solo modelo arquitectónico, ya que cada modelo representa
una perspectiva de una vista del sistema, desplegando el sistema en diferentes módulos
o vistas, la iteración que tienen los procesos, cómo se desempeña y distribuye un sistema
con sus componentes a través de una red.
Todas las vistas son importantes y útiles para el diseño y la documentación en diferen-
tes momentos o vistas de la arquitectura de software. El modelo 4+1 de la arquitectura de
software propuesto por Krutchen, manifiesta que deben diseñarse 4 vistas fundamentales
para la definición arquitectónica de un sistema, haciendo uso de casos de uso o escenarios
como lo describe Sommerville (2011) y son:
1. Vista lógica: está relacionada con la abstracción de objetos, clases esta vista
relaciona los requerimientos del sistema con entidades.
2. Vista de proceso: despliega los procesos que conforman el sistema en tiempo de
operación y sus iteraciones entre estos. Esta vista es importante para analizar carac-
terísticas no funcionales del sistema, como es el rendimiento y la disponibilidad.
3. Vista de desarrollo: muestra la descomposición del software en elementos para
su proceso de desarrollo a través de un desarrollador o equipo de desarrollo, esta
vista es importante para los administradores y programadores de software.
4. Vista física: despliega el hardware del sistema y los componentes del software
que se distribuyen a través de los procesadores en el sistema. Esta vista es útil para
los ingenieros de sistemas que planean una implementación de sistema (p. 154).
Pipeline (tuberías y filtros)
Una tubería (pipeline) consiste en un conjunto de nodos de procesamiento de datos
relacionados en serie, donde la salida de un elemento es la entrada del siguiente. Cada
fase del procesamiento se encapsula en un filtro, los datos se comparten a través de
flujos entre filtros adyacentes, la figura 6 muestra un esquema de tuberías y filtros, la
aplicación de este estilo permite la reutilización, el bajo acoplamiento, la concurrencia y
facilidad del estilo (Rodríguez y Silva, 2016).
Arquitectura de software - eje 1 conceptualicemos 20
Figura 6.
Proceso de visualización de tuberías y filtros
Adquisición Preprocesado Segmentación
Reconstrucción Clasificación Visualización
Fuente: Rodríguez y Silva (2016)
Zachman Enterprise framework
Figura 7.
Inventario de artefactos base definidos en el framework Zachman
Fuente: MinTIC (2019).
Arquitectura de software - eje 1 conceptualicemos 21
El framework fue desarrollado por John A. Zachman en el año 1984, y fue publicado
por IBM Systems Journal en 1987.
De acuerdo con Sanchis (2020) es un marco de mayor difusión y con mayor antigüe-
dad y es tomado como marco de referencia, se trata de una taxonomía arquitectónica,
que permite organizar y categorizar artefactos arquitectónicos como documentos de
diseño, especificaciones y modelos, que tengan presente su objetivo como el problema
particular a abordar.
El framework es utilizado por muchas empresas desarrolladoras de software, resul-
tando ser muy interesante y satisfactoria su implementación, ya que permiten agilizar
en el desarrollo y permiten la aplicación de buenas prácticas, cumpliendo estándares de
desarrollo para la construcción de aplicaciones que integren componentes basados en
estilos arquitectónicos y patrones de diseño.
Contiene una variedad de beneficios que ayudan al manejo de la información en la
empresa, entre los cuales se destacan la facilidad de alineación de TI y el negocio, permite
la integración de la información a través de los diferentes procesos de las organizaciones
(p. 30).
Conclusiones
En el campo del software es común el término de arquitectura de software, es impor-
tante comprender que la arquitectura de software hace referencia a la estructura del
sistema, que es construida en etapas tempranas del desarrollo. Esta estructuración está
definida en un diseño de alto nivel del sistema, satisfaciendo los atributos de calidad y
sirviendo como guía en el desarrollo.
Los atributos de calidad son parte de los requerimientos no funcionales del sistema y
son características que deben expresarse de forma cuantitativa.
La arquitectura de software tiene un papel importante en la guía del desarrollo de
software, facilitando dividir el sistema en componentes que serán desarrollados por indi-
viduos o equipos de trabajo. La identificación de esta estructura de trabajo es importante
para la realización de tareas de planeación del proyecto.
Los diseños arquitectónicos que se definen en una organización pueden reutilizarse
para crear sistemas distintos. Esto facilita la reducción de costos y aumentar la calidad
cuando dichos diseños han terminado siendo sistemas exitosos.
Arquitectura de software - eje 1 conceptualicemos 22
ISO/IEC/IEEE 42010. (s. f.). Defining architecture. [Link]
[Link]/ieee-1471/[Link]
Humberto, C. M., Perla, V. E. y Castro, C. L. (2016). Arquitectura de sof-
tware conceptos y ciclo de desarrollo. Cengage Learning.
MinTIC. (2019). Guía de arquitectura de soluciones tecnológicas. MinTIC.
[Link]
curso_pdf.pdf
Navasa, M. A. (15 de 07 de 2008). Marco de trabajo para el desa-
rrollo de arquitecturas software orientado a aspectos. https://
[Link] /dt02pdf/ 123dok_es /003/933/[Link].
BIBLIOGRAFÍA
pdf?X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Al-
gorithm=AWS4-HMAC-SHA256&X-Amz-Credential=7PKKQ3DU-
V8RG19BL%2F20220727%2F%2Fs3%2Faws4_request&X-Amz-Da-
te=20220727T094417Z&X-Amz-SignedHeaders=h
Presman, S. R. (2010). Ingeniería del software. Un enfoque práctico. Mc
Graw-Hill. [Link]
[Link]
Rodríguez, P. A. y Silva, R. L. (2016). Arquitectura de software para el
sistema de visualización médica Vismedic. Revista Cubana de Infor-
mática Médica, 4.
Sanchis, V. M. (2020). Análisis comparativo de herramientas de arqui-
tectura. Universidad Politécnica de Valencia. [Link]
es /bitstream/handle/10251/150193/Sanchis%20-%20An%C3%A1li-
sis%20comparativo%20de%20herramientas%20de%20arquitectu-
ra%[Link]?sequence=1&isAllowed=y
Sommerville, I. (2011). Ingeniería de software. Pearson. [Link]
[Link]/panel/uploads/biblioteca/2018-06-11_03-[Link]