TE 260

Arquitectura de Software

•

SIN SIGLA

Diego Reyes

18/3/2024

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Arquitectura de Software

1836 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

CENTRO DE INVESTIGACION EN MATEMÁTICAS, A.C.

Modelo para el Desarrollo de
Arquitecturas de Software

Reporte Técnico de Investigación
que para obtener el grado de

Maestro en Ingeniería de Software

presenta

José de Jesús Hernández Suárez

Director:

Dr. Carlos Montes de Oca Vázquez

Guanajuato, Gto. a 22 de julio de 2005.

Resumen

El desarrollar sistemas de software cada vez más grandes y complejos para cubrir las necesidades y
objetivos de las organizaciones actuales, exige prestar atención y especial cuidado al diseño de la arquitectura
de dichos sistemas. Se sabe que el proceso para elaborar una arquitectura de software es muy crítico e
importante para el desarrollo de un sistema de software de gran escala; requiere de conocimientos,
experiencia y creatividad por parte del arquitecto. Son pocas las propuestas de proceso para elaborar una
arquitectura de software que existen en la literatura, en su mayoría dejan en un alto nivel los pasos que se
deben seguir, y en otros casos sólo atacan una parte del proceso. Por otra parte, las organizaciones y
arquitectos de software requieren un proceso que les muestre a detalle las actividades que tienen que seguir,
así como los recursos en los que se pueden apoyar para elaborar una arquitectura de software. El presente
trabajo se encuentra orientado a la atención de estos problemas, proponiendo un modelo de proceso para el
desarrollo de arquitecturas de software, el cual contempla la definición de pasos a cubrir, el flujo de
actividades a detalle que se deben seguir, la especificación entradas y salidas para cada una de dichas
actividades, la descripción de las herramientas susceptibles de utilizar para apoyar las mismas, la descripción
de los roles que intervienen, y la definición de las métricas que se deben registrar para controlar y mejorar el
proceso.

Agradecimientos

El presente trabajo representa el fruto del apoyo, aliento, confianza, guía, enseñanzas y aportaciones que recibí
de muchas personas. Deseo expresar mi más reconocida gratitud a todas ellas.

Al Dr. Carlos Montes de Oca, mi director de investigación, por sus excelentes y puntuales observaciones,
recomendaciones, enseñanzas y guía que orientaron mi camino para llevar a cabo este esfuerzo, así como a lo largo
de la maestría.

Al Dr. Cuauhtémoc Lemus Olalde, por todos los conocimientos transmitidos a través de sus enseñanzas,
ejemplos, y observaciones como experto en arquitecturas de software, así como todo su apoyo.

Al Dr. Miguél Ángel Serrano, por sus diversas aportaciones que reforzaron mi enseñanza en diferentes
temáticas a lo largo de la maestría.

Al Consejo de Ciencia y Tecnología del Estado de Guanajuato (CONCYTEG), por su parcial financiamiento a
través del proyecto GTO-2002-C01-5333 titulado "Promoviendo calidad en la industria de software: recursos
humanos, investigación, servicios" como programa de beca, lo cual me permitió estudiar una maestría de alta calidad
académica.

A mis amigos y compañeros de generación de la maestría, Karen Cortés, Omar Gómez, Gustavo Herrera, Juan
Antonio López y Nayhely Trujillo, por su valiosísimas experiencias transmitidas, por su incondicional y sincero apoyo
en todo momento, y por su grandísima paciencia que siempre me tuvieron para avanzar en nuestro camino.

A mi alma mater, la Universidad Nacional Autónoma de México, y especialmente a la Dirección General de
Servicios de Cómputo Académico (DGSCA), por forjar mi carrera, conocimiento, habilidades y experiencia, que me
han ayudado a lo largo de mi vida académica y profesional, y que sin duda alguna me ayudaron a concluir mi
maestría por todo lo que siempre me transmitió.

Al Dr. Juan Voutssás Márquez, a la Mtra. Marcela Peñaloza Báez, al Mtro. Hugo Alonso Reyes Herrera, al Lic.
José Luis Medina Flores, y a todos mi excelentes amigos y compañeros de la Dirección de Sistemas de la DGSCA que
me dieron su invaluable apoyo, inspiración y aliento para estudiar esta maestría, así como sus excelentes
experiencias, enseñanzas y ejemplos transmitidos que han ayudado a mi formación.

Y especialmente a mi gran familia, mis padres José de Jesús y Sofía, mis hermanos, Olivia, Sofía, Verónica, Luis
Adrián y Alejandra, por su incondicional apoyo, cariño, impulso, aliento y confianza que siempre he recibido de ellos y
me ha ayudado a ser quien soy.

Atentamente, José de J.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Estudio de Investigación

Tabla de Contenido

1. INTRODUCCIÓN..........................................................................................................................................3
2. DESCRIPCIÓN DEL PROBLEMA.....................................................................................................................5
3. TRABAJO PREVIO........................................................................................................................................6
3.1. CONCEPTOS BÁSICOS ...............................................................................................................................6
3.2. PROCESOS DE ARQUITECTURA DE SOFTWARE...................................................................................................7
3.3. DISEÑO DE ARQUITECTURAS.......................................................................................................................9
3.4. ESTÁNDARES .......................................................................................................................................13
3.5. HERRAMIENTAS ....................................................................................................................................15
4. PROPUESTA DE SOLUCIÓN........................................................................................................................17
5. MODELO PARA EL DESARROLLO DE ARQUITECTURAS DE SOFTWARE .........................................................19
5.1. IDENTIFICAR REQUERIMIENTOS ARQUITECTÓNICOS .........................................................................................22
5.2. DISEÑAR LA ARQUITECTURA .....................................................................................................................27
5.3. VERIFICAR LA ARQUITECTURA ...................................................................................................................32
5.4. ADECUAR LA ARQUITECTURA ....................................................................................................................34
5.5. DOCUMENTAR LA ARQUITECTURA...............................................................................................................37
5.6. EVALUAR LA ARQUITECTURA.....................................................................................................................40
5.7. VALIDAR LA ARQUITECTURA .....................................................................................................................41
6. DISCUSIÓN DEL MODELO PARA EL DESARROLLO DE ARQUITECTURAS DE SOFTWARE ................................44
6.1. DESVENTAJAS QUE PRESENTA EL MODELO.....................................................................................................44
6.2. LIMITACIONES QUE PRESENTA EL MODELO ....................................................................................................44
6.3. VENTAJAS QUE PRESENTA EL MODELO .........................................................................................................45
6.4. RECOMENDACIONES DE UTILIZACIÓN DEL MODELO ..........................................................................................45
6.5. ALCANCEY MEJORAS..............................................................................................................................46
7. CONCLUSIONES Y TRABAJO FUTURO.........................................................................................................47
8. BIBLIOGRAFÍA ..........................................................................................................................................49
9. GLOSARIO ................................................................................................................................................51
10. APÉNDICE A. BIBLIOGRAFÍA ADICIONAL ...............................................................................................53

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Estudio de Investigación

Lista de Figuras

Figura 3.2.1, Desarrollo basado en arquitecturas…………………………..……………………………………………………………. 8
Figura 3.2.2, Esquema de un método de diseño de arquitectura…………………………………………………………………… 9
Figura 3.3.1, Descomposición del sistema en elementos de diseño,
Método de Diseño Basado en Arquitectura………………………………………………………………………………………….......... 10
Figura 3.3.2, Matriz de obtención de escenarios genérica…………………………………………………………………………….. 11
Figura 3.4.1, Tabla de comparación de arquitecturas de acuerdo a atributos de calidad………………………………….. 13
Figura 3.4.2, Framework para la medición arquitectónica…………………………………………………………………….………. 14
Figura 3.5.1, Casa de calidad de QFD………………………………………………………………………………………………………… 15
Figura 4.1, Modelo pare el desarrollo de arquitecturas de software – MODAS – Proceso General…………………….. 17
Figura 5.1, Architecture-Based Development en relación con el
Modelo para el Desarrollo de Arquitecturas de Software………………………………………………………………………………. 19
Figura 5.2, Vista detallada del Modelo para el Desarrollo de Arquitecturas de Software…………………………………… 21
Figura 5.1.1, Paso: Identificar requerimientos arquitectónicos del
Modelo para el Desarrollo de Arquitecturas de Software………………………………………………………………………………. 23
Figura 5.1.2, Casa de calidad de SQFD………………………………………………………………………………………………………. 25
Figura 5.1.3, Matriz de relación de escenarios…………………………………………………………………………………………….. 26
Figura 5.2.1, Paso: Diseñar la arquitectura del Modelo para el Desarrollo de Arquitecturas de Software…………… 27
Figura 5.2.2, Descomposición del sistema…………………………………………………………………………………………………… 29
Figura 5.2.3, Selección de estilo arquitectónico…………………………………………………………………………………………… 30
Figura 5.3.1, Paso: Verificar la arquitectura del Modelo para el Desarrollo de Arquitecturas de Software…………… 32
Figura 5.4.1, Paso: Adecuar la arquitectura del Modelo para el Desarrollo de Arquitecturas de Software…………… 34
Figura 5.5.1, Paso: Documentar la arquitectura de software del
Modelo para el Desarrollo de Arquitecturas de Software………………………………………………………………………………. 37
Figura 5.7.1, Paso: Validar la arquitectura del Modelo para el Desarrollo de Arquitecturas de Software……………. 41

Lista de Tablas

Tabla 5.3, Notación para describir el Modelo para el Desarrollo de Arquitecturas de Software………………………… 22

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 3
MODAS
Modelo para el desarrollo de arquitecturas de software

1. Introducción

Las necesidades actuales que tiene toda organización para el logro de sus objetivos, demandan la construcción
de grandes y complejos sistemas de software, mismos que requieren de la combinación de diferentes tecnologías y
plataformas de hardware para alcanzar un buen funcionamiento acorde a dichas necesidades. Esto les sugiere a los
ingenieros en software poner especial atención y cuidado en su proceso de diseño de la arquitectura de software
bajo la cual está soportado el funcionamiento de dichos sistemas de software. Si una arquitectura de software se
encuentra deficiente en su concepto o diseño, o en el peor de lo casos, no contamos con la arquitectura del sistema
que nos encontremos desarrollando, tendremos grandes posibilidades de estar construyendo un sistema incorrecto
que no alcanzará el total de los objetivos planteados. Esto indudablemente nos podrá llevar a un re-trabajo de mayor
inversión tiempo que el planeado, o peor aun, nos podrá llevar al fracaso del sistema de software cuando se
encuentre en operación.

En el diseño de un sistema, existen dos fases generales que se pueden distinguir: 1) diseño arquitectónico y 2)
diseño detallado. El diseño arquitectónico ocurre inmediatamente después de la especificación de requerimientos de
software y antes del diseño detallado. Un diseño arquitectónico se encuentra enfocado a los elementos estructurales,
funcionales y de comportamiento de un sistema, tratando de modelar el problema y la propuesta de solución. Los
elementos estructurales que influencian las decisiones de diseño incluye: estructura de organización y control;
comunicación, sincronización, y protocolos de acceso a datos; distribución física de funciones de elementos de
diseño; desarrollo futuro, etc. Por su parte, el diseño detallado describe el control jerárquico, estructura de datos,
lógica y empaquetado de elementos establecidos en el diseño estructural (traducido y modificado de) [1].

Bass, Clements y Kazman definen a la arquitectura de software de un programa o sistema de cómputo, como la
estructura o estructura del sistema, la cual consta de componentes de software, propiedades visibles externamente
de esos componentes y la relación a través de ellos (traducido de) [2].

De acuerdo al concepto de arquitectura de software, podemos decir que el proceso de elaboración de una
arquitectura de software se refiere al conjunto de pasos que tenemos que seguir para conceptualizar, diseñar,
definir, verificar, documentar y evaluar los diferentes componentes de software y sus propiedades bajo los cuales
estará soportado un sistema de cómputo, así como la relación que existirá entre los mismos.

El proceso de elaboración de arquitecturas de software representa uno de las procesos más importantes y a la
vez más críticos del ciclo de vida del desarrollo de sistemas, debido a que en esta etapa es dónde se define y
especifica el diseño de alto nivel del sistema, el cual fundamenta los componentes, estructura, organización y
relaciones entre dichos componentes, mismos que permitirán llevar a cabo las funciones del sistema de acuerdo a los
requerimientos e intereses de los usuarios. Para los ingenieros de software, un proceso definido para la elaboración
de arquitecturas de software representa contar con una comunicación mutua con los diferentes stakeholders, realizar
decisiones tempranas de diseño, evaluación e identificación temprana de restricciones de diseño, identificar atributos
de calidad en conflicto o tradeoffs y reutilizar componentes de software, además de evitar errores, encontrar fallas y
reducir costos a consecuencia de re-trabajo.

Actualmente, importantes autores y expertos en la materia de arquitecturas de software, como Bass, Clements,
Kazman, Nord, Kruchten, Garlan y Bachmann, entre otros, han realizado muy buenas aportaciones y
recomendaciones en la materia, lo cual ha permitido adoptar y adaptar modelos para llevar a cabo un proceso de
elaboración de arquitecturas de software, o bien un parte de ella.

El problema radica en que existe la ausencia de la definición concreta de un proceso para la elaboración de una
arquitectura de software que permita identificar claramente, las actividades a llevar a cabo en cada uno de los pasos
propuestos, la secuencia concreta de las mismas, las entradas y salidas del proceso, así como de cada una de las
actividades que presentan los pasos del mismo, y las herramientassusceptibles de utilizar para apoyar dichas
actividades.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 4

Por otra parte, sabemos que existe una empresa mexicana dedicada a la consultoría de software cuyo negocio
base es el desarrollo de software a la medida, que preocupada por una constante mejora de procesos y control
estadístico de sus operaciones, busca perfeccionar su proceso de elaboración de arquitecturas de software.
Actualmente esta empresa cuenta con un proceso definido para esta fase del ciclo de vida de un sistema, sin
embargo, se puntualiza que dicho proceso sirve como una guía, es decir, es opcional para los ingenieros de software
al llevar a cabo la labor del diseño de una arquitectura, ya que no restringe el proceso utilizado en el diseño de la
misma, debido a que es la parte más creativa del proceso de desarrollo. De esta manera, la empresa en ningún
momento restringe las técnicas o metodologías utilizadas para representar o definir aspectos de diseño de la
arquitectura, ni restringe las secciones a cubrir en su documentación, sin embargo, para arquitectos novatos o con
poca experiencia, esta actividad puede ser complicada y muy laboriosa sino se cuenta con un proceso que detalle de
manera clara las actividades que puede seguir, las entradas y salidas de las mismas, así como la descripción de los
recursos o herramientas en los que se puede apoyar para llevar a cabo dichas actividades .

Considerando que: 1) el proceso de elaboración de una arquitectura de software es de suma importancia y
crítico para el desarrollo de un sistema de software de gran escala; 2) no existe en la literatura un modelo que
permita identificar de manera clara y rápida las actividades a detalle que se deben seguir para la construcción de una
arquitectura de software con la secuencia de las mismas, y la descripción de recursos o herramientas que apoyen
cada una de dichas actividades; y que 3) el proceso definido por la empresa que hemos mencionado como ejemplo,
aun con la correcta definición y control estadístico de otros procesos para el ciclo de vida de un sistema, el que se
relaciona con el desarrollo de una arquitectura de software no es muy detallado y se encuentra débil en algunos
aspectos; proponemos como solución diseñar un modelo de proceso para el desarrollo de arquitecturas de software
que permita: a) identificar claramente las actividades a llevar a cabo en cada uno de los pasos propuestos, b)
conocer detalladamente las entradas y salidas del proceso, así como de cada una de las actividades que presentan
los pasos del mismo, c) conocer las herramientas o recursos que son posibles utilizar para apoyar dichas actividades,
d) identificar los roles que deben de intervenir, y e) registrar métricas dentro de las actividades a llevar a cabo que
permitan controlar y mejorar el proceso. De esta manera, el presente reporte de investigación presenta una
propuesta de proceso para elaboración de arquitecturas de software definido, que trata de contemplar todos los
elementos expuestos hasta el momento. La propuesta se encuentra basada principalmente en varios de los pasos y
elementos que toman en cuenta el modelo de Desarrollo Basado en Arquitecturas de Len Bass y Rick Kazman [3].

El presente documento de reporte técnico se encuentra dividido en diez secciones. La primera sección esta
representada por la presente introducción; la segunda sección describe la problemática a la que nos enfrentamos; la
tercera sección muestra el trabajo previo realizado en la materia (estado del arte); la cuarta sección describe el
nuestra propuesta de solución; la quinta sección describe el modelo para el desarrollo de arquitecturas de software
propuesto; la sexta sección discute las desventajas, limitaciones, ventajas, recomendaciones, alcance y mejoras que
hemos identificado para el modelo para el desarrollo de arquitecturas de software propuesto; la séptima sección da
las conclusiones de la propuesta; la octava sección muestra las referencias analizadas para la elaboración del
presente reporte; la novena sección presenta un glosario de términos utilizados a lo largo del presente documento, y
finalmente, la décima sección presenta bibliografía adicional que apoyó la investigación.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 5

2. Descripción del problema

Dentro del campo de las arquitecturas de software existen diferentes e importantes aportaciones que han
realizado diversos expertos en la materia, como son: Bass, Clements, Kazman, Nord, Kruchten, Garlan y Bachmann,
entre otros. Estos autores han propuesto distintos conceptos, modelos, técnicas y herramientas para llevar a cabo
una arquitectura de software, o bien una parte de la misma, sin embargo son muy pocos los que consideran el
proceso de manera completa, y aun un número mucho menor los que especifican el detalle de actividades a seguir
en el proceso. Las organizaciones preocupadas por esta importante fase del ciclo de vida de desarrollo de sistemas,
han tomando estas propuestas disponibles para esta fase del ciclo de vida de desarrollo de sistemas, y en el mejor
de los casos las han adaptado para contar con un proceso mucho más definido para la creación de arquitecturas de
software de acuerdo a las exigencias de sus clientes, sin embargo, en muchos de los casos continúa siendo
deficiente.

Actualmente existe una compañía mexicana de consultaría y desarrollo de software a la medida, quién
preocupada por una constante mejora de procesos, y control y calidad de sus operaciones, cuenta con procesos bien
definidos para todas las etapas del ciclo de vida de un sistema de software, incluyendo la elaboración de la
arquitectura de software, sin embargo, este último proceso no cuenta con un nivel de detalle que muestre
explícitamente a un ingeniero en software las actividades y herramientas que debe hacer uso para llegar al diseño de
la arquitectura de una manera sencilla. Esta importante fase no restringe a los ingenieros en software el proceso
utilizado, les proporciona una guía debido a que es la parte más creativa del proceso de desarrollo, y por tal
situación, se ha detectado que existen debilidades que impiden cubrir varios de los aspectos y recomendaciones que
hacen los expertos para la creación de una arquitectura de software.

Sabemos que es muy importante y crítico el proceso de desarrollo de una arquitectura de software, debido a
que el resultado de su ejecución nos conducirá al correcto, o bien, débil diseño de un sistema de software, lo cual
puede traer como consecuencia re-trabajo en la fase de codificación del sistema, o peor aún en la fase de pruebas.
Tomando esto en consideración, comprobando que los procesos o modelos actualmente propuestos por los expertos
en arquitecturas de software se encuentran a un alto nivel, y que la industria de software no cuenta con una
definición detallada de este proceso, podemos decir que la problemática común a la que se enfrentan los ingenieros
de software en la fase de diseño de sistemas es que no cuentan con un recurso accesible que les muestre de manera
clara las actividades a detalle de un proceso para elaboración de arquitecturas de software, el flujo que deben de
seguir para llevar a cabo dichas actividades, definición clara de entradas y salidas respectivas, los roles quiénes
desempeñan dichas actividades, y los recursos o herramientas que apoyen las actividades, además de métricas que
permitan controlar y mejorar dicho proceso. Los modelos y propuestas de proceso actuales que recomiendan los
expertos, no consideran en conjunto todos estos elementos que son de suma importancia para el diseño que llevan a
cabolos ingenieros en software. Esto nos representa la posibilidad de proponer un proceso definido para elaboración
de arquitecturas de software.

El contar con un proceso definido de elaboración de arquitecturas de software trae como consecuencia varios
beneficios para los ingenieros de software, tales como mejorar la comunicación mutua entre los diferentes
stakeholders, realizar decisiones tempranas de diseño, evaluar e identificar tempranamente restricciones de diseño,
identificar atributos de calidad en conflicto o tradeoffs y reutilizar componentes de software, además de evitar
errores, encontrar fallas y reducir costos a consecuencia de re-trabajo.

Por el contrario, si no atendemos la relevancia que tiene un proceso para elaboración de arquitecturas de
software, nos encontramos en el riesgo de desarrollar software deficiente en su concepto o diseño, y por ende
estaremos construyendo un sistema incorrecto que no alcanzara el total de los objetivos planteados. Esto nos llevará
a un re-trabajo con mayor inversión de tiempo, esfuerzo y dinero del planeado, o peor aun, nos podrá llevar al
fracaso del sistema de software cuando se encuentre en operación.

Este trabajo se encuentre dirigido a la atención de los problemas descritos anteriormente, para lo cual
definimos un modelo para la elaboración de arquitectura de software que busca satisfacer la carencia de un proceso
que contemple el flujo de actividades, entradas, salidas, roles, herramientas y métricas que permitan desarrollarla.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 6

3. Trabajo previo

Dentro del campo de la arquitectura de software, existen aportaciones importantes para los diferentes aspectos
que deben ser considerados en su desarrollo. Distintos autores han realizado propuestas muy interesantes en
relación a métodos o procesos para llevar a cabo una arquitectura de software, o bien alguna parte de ella. En la
presente sección describimos brevemente algunos conceptos básicos y algunas de estas aportaciones, mismas que
hemos estudiado y analizado como parte de la investigación del tema y en las cuales se basa nuestra propuesta de
solución.

La presente sección se encuentra dividida en cinco puntos principales. El primer punto describe algunos
conceptos básicos de arquitecturas de software; el segundo punto menciona algunas propuestas de proceso para
arquitecturas de software; el tercer punto describe técnicas para el diseño de arquitecturas de software; el cuarto
punto menciona algunos estándares relacionados con arquitecturas de software, y finalmente el quinto punto hace
mención de algunas herramientas adicionales que serán de utilidad para el proceso de desarrollo de arquitectura de
software.

3.1. Conceptos básicos

Para comprender con mayor facilidad los elementos que son considerados en una arquitectura de software,
mencionaremos a continuación algunos conceptos importantes, los cuales son: estilo arquitectónico, patrón
arquitectónico, patrón de diseño, vistas y estructuras arquitectónicas, view point, escenarios y atributos de calidad.

Un estilo arquitectónico se define como un vocabulario de componentes y tipos de componentes, así como un
conjunto de restricciones sobre cómo estos componentes pueden ser combinados. Algunos de estos estilos
arquitectónicos son: procesamiento secuencial, tuberías y filtros, sistemas orientados a objetos, sistemas en capas,
sistemas basados en eventos, bases de datos, entre otros (traducido de) [4].

Un patrón arquitectónico generalmente impone una regla (Perry and Wolf, 1992) en la arquitectura, la cual
especifica cómo manejará el sistema un aspecto de su funcionalidad. Un patrón arquitectónico trata con algún
aspecto del comportamiento del sistema que no está en el dominio de la funcionalidad del mismo, pero el cual
maneja alguno de sus dominios de soporte, por ejemplo, la manera en cómo el sistema maneja la concurrencia, la
persistencia, la tolerancia a fallas o la distribución (traducido de) [5]. Un patrón arquitectónico es diferente a un
estilo arquitectónico en el sentido que no es predominante y puede ser combinado con un estilo arquitectónico sin
problemas. También es diferente a un patrón de diseño, toda vez que afecta completamente la arquitectura, o al
menos un parte importante de ella (traducido de) [5].

Un patrón de diseño describe una estructura comúnmente recurrente de comunicación entre componentes que
resuelve un problema de diseño general dentro de un contexto en particular (traducido de) [6].

Un estilo arquitectónico está compuesto de patrones arquitectónicos y un patrón arquitectónico está compuesto
por patrones de diseño. Un mecanismo arquitectónico es una estructura en la cual los objetos colaboran para
obtener cierto conocimiento que ayuda a lograr metas de calidad específicas (traducido de) [7].

Una vista es una representación de un conjunto coherente de elementos arquitectónicos. Las vistas consisten
de una representación de un conjunto de elementos y relaciones entre ellos; muestran una perspectiva de la
arquitectura de software. Bass Clements y Kazman proponen tres grupos de vistas, los cuales son: estructuras de
módulos, estructuras de conectores y componentes, estructuras de asignación [2].

Un viewpoint es una especificación de las convenciones para construir y utilizar una vista; representa un patrón
o plantilla a partir del cual se desarrollan las vistas individuales de la arquitectura mediante el establecimiento de los
intereses de los diferentes stakeholders para dicha vista y las técnicas para su creación y análisis (traducido y
modificado de) [8]. Identifica el conjunto de intereses a cubrir e identifica las técnicas de modelado, de evaluación o
de verificación de consistencia empleadas por cualquier vista que corresponda.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 7

Un escenario es una breve descripción de una interacción simple de un stakeholder con el sistema. Los casos de
uso se enfocan al comportamiento del sistema en tiempo de ejecución, dónde el stakeholder es el usuario, sin
embargo, los escenarios abarcan otras interacciones con el sistema, tales como el mantenimiento que se le debe dar
a un sistema al emerger una modificación. De esta manera, los escenarios tienen otros usos más allá de la obtención
y validación de requerimientos de software, como ayudar a comprender y aceptar lo que requiere el stakeholder, y
obtener diferentes vistas arquitectónicas (traducido y modificado de) [9].

Un atributo de calidad es un requerimiento no funcional de un sistema de software por ejemplo: confiabilidad,
facilidad de modificación, rendimiento, facilidad de uso, entre otros. De acuerdo al estándar IEEE Standard 1061-
1992 [38], un atributo de calidad representa el grado en el cual un software posee una combinación deseable de
estos atributos. Jan Bosch [10] define dos categorías para agruparlos, las cuales son: atributos de desarrollo y
atributos de operación. Los atributos de desarrollo son relevantes desde una perspectiva de ingeniería de software,
estos atributos pueden ser: facilidad de mantenimiento, reutilizable, flexibilidad, facilidad de modificación. Los
atributos operacionales son características del sistema en operación por ejemplo: el rendimiento del sistema, la
confiabilidad, robustez, tolerancia a fallas, seguridad. Cualquier arquitectura de software definida de manera
apropiada promueve que se satisfagan atributos de calidad.

3.2. Procesos de arquitectura de software

En la presente sección describiremos brevemente algunos procesos de arquitecturas de software que fueron
analizados para generar nuestrapropuesta de solución. Estos procesos son: Desarrollo Basado en Arquitecturas y
Diseño de Arquitectura de Software: Evaluación y Transformación.

Desarrollo Basado en Arquitecturas

Partiendo de la idea que el desarrollo de una arquitectura de software es un paso crítico en el desarrollo de
sistemas de software de gran escala, Len Bass y Rick Kazman en 1999 propusieron un proceso para desarrollar
arquitecturas de software, conocido como “Desarrollo Basado en Arquitecturas” (Architecture-Based Development)
[3], el cual facilita la identificación de tareas que son necesarias para generar una arquitectura de software, así como
el seguimiento de un método para su construcción. El proceso incluye los siguientes pasos:

a) Obtener los requerimientos arquitectónicos, el cual genera un listado de requerimientos funcionales, un
listado de requerimientos arquitectónicos específicos y un listado de escenarios de calidad.

b) Diseñar la arquitectura, el cual estructura las vistas: funcional, de código, de concurrencia, física y de
desarrollo; desarrolla subsistemas candidatos y selecciona subsistemas.

c) Documentar la arquitectura, en la cual muestra recomendaciones para realizar la documentación de
dicha arquitectura.

d) Analizar la arquitectura, en dónde evalúa la arquitectura mediante el método ATAM (Architecture
Tradeoff Analysis Method) [11].

e) Generar la arquitectura, en dónde muestra recomendaciones para comenzar a codificar la arquitectura
de software.

f) Mantener la arquitectura, el cual propone volver a ejecutar el método para incorporar nuevos
requerimientos a la arquitectura de software.

De manera gráfica, el proceso es representado como se muestra en la figura 3.2.1. Cada uno de estos pasos
considera los siguientes elementos:

Entradas, incluyendo la recolección de la información principal
Actividades constructivas

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 8

Actividades de validación
Salidas

Figura 3.2.1, Desarrollo basado en arquitecturas.

Diseño de Arquitectura de Software: Evaluación y Transformación

Bosh y Molin presentan en su artículo “Software Architecture Desing: Evaluation and Transformation” [10] un
método de diseño de arquitecturas que provee la base para un proceso de diseño balanceado y optimizado,
especialmente para los requerimientos no funcionales. El método evalúa de manera iterativa el grado en el cual la
arquitectura soporta cada uno de los requerimientos no funcionales y mejora la arquitectura utilizando la
transformación hasta que todos los requerimientos no funcionales están cubiertos.

Para este método, la especificación de requerimientos es considerada como entrada y el diseño de la
arquitectura generada es la salida. El proceso se puede resumir de la siguiente manera y es ilustrado con la figura
3.2.2:

1. Se realiza un primer diseño arquitectónico basado en la especificación de los requerimientos
funcionales.
2. Este diseño es evaluado con respecto a los requerimientos no funcionales.
3. A cada requerimiento no funcional le es asignada una estimación utilizando una técnica de evaluación
cualitativa o cuantitativa.
4. Los valores estimados de los requerimientos no funcionales son comparados con los valores en la
especificación del requerimiento.
5. Si todas las estimaciones están cubiertas o mejoradas, el proceso de diseño de la arquitectura es
finalizado. De otra manera la segunda fase se ejecutada: transformación de la arquitectura.
6. Durante esta etapa, la arquitectura es mejorada seleccionando el requerimiento no funcional apropiado
optimizando su transformación.
7. Cada uno de los conjuntos de resultados de la transformación es una nueva versión del diseño
arquitectónico.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 9

8. El diseño es nuevamente evaluado y el mismo proceso es repetido de ser necesario, hasta que todos
los requerimientos no funcionales son completados o hasta que el ingeniero en software decida que no
es factible la solución existente.

Figura 3.2.2, Esquema de un método de diseño de arquitectura.

3.3. Diseño de arquitecturas

En esta sección describiremos brevemente algunos modelos y técnicas que son utilizadas para diseñar y
documentar una arquitectura de software. Dichos modelos son: Diseño Basado en Arquitecturas, Arquitectura Basada
en Escenarios, vistas arquitectónicas, Diseño de arquitectura de software efectivo con UML.

Diseño Basado en Arquitecturas

Bachmann, Bass, Chastek, Donohoe y Peruzzi en el año 2000 propusieron un proceso para llevar a cabo el
diseño de una arquitectura de software, el cual es conocido como “Método de Diseño Basado en Arquitectura” (The
Architecture Based Design Method) [12]. El método proporciona una serie de pasos para el diseño conceptual de la
arquitectura de software. Satisface los requerimientos funcionales, de negocio y de calidad al nivel de abstracciones
que permiten realizar variaciones en la arquitectura cuando se produce una arquitectura en específico. Se basa en la
determinación de los elementos que guía o conducen a la arquitectura (architectural drivers), lo cual es la
combinación de dichos requerimientos funcionales, de negocio y de calidad que moldea la arquitectura.

El método tiene tres fundamentos: descomposición de función (acoplamiento y cohesión), compresión de los
requerimientos de calidad y de negocio, a través de la selección de estilos arquitectónicos y el uso de patrones de
software. La descomposición es examinada desde la perspectiva de tres vistas: lógica, concurrencia y deployment. Se
utiliza la vista lógica para registrar las responsabilidades e interfases conceptuales (salida y entrada de datos) para el
diseño de elementos; la vista de concurrencia para examinar el sistema desde la perspectiva de múltiples usuarios,
recursos, puesta en marcha y otras actividades paralelas, y la vista de deployment para representar nodos en una
red de computadoras, esto es, la estructura física del sistema.

La entrada del método de diseño basado en arquitectura consiste de:

Requerimientos funcionales abstractos
Casos de uso

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 10
Requerimientos de negocio y de calidad abstractos
Escenarios de calidad
Opciones de arquitectura
Reglas

El proceso se fundamenta en la descomposición del sistema en subsistemas conceptuales, éstos a su vez en
componentes conceptuales y finalmente éstos últimos en componentes concretos. Este proceso se esquematiza con
la figura 3.3.1.

Figura 3.3.1, Descomposición del sistema en elementos de diseño,
Método de Diseño Basado en Arquitectura.

Los pasos que considera el método se pueden resumir en los siguientes:

1. Descomposición del sistema en elementos de diseño.
2. Definición de grupos de funcionalidad.
3. Selección del estilo arquitectónico.
4. Refinar plantillas.
5. Verificación de la funcionalidad.
6. Generación de vistas arquitectónicas.
7. Verificación de escenarios y reglas.

Arquitectura Basada en Escenarios

Kazman, Carrière y Woods proponen un proceso que permite relacionar escenarios con los atributos de calidad
que se consideran en una arquitectura de software, así como con los stakeholders interesados en los mismos [9]. El
proceso propone obtener escenarios, corresponder escenarios a las vistas arquitectónicas, y construir modelos
analíticos, los cuales ayudan a comprender y documentar las decisiones estructurales que se han hechosobre la
arquitectura. Los escenarios que se manejan en el proceso pueden ser:

Directos, los cuales representan los usos del sistema construido de la arquitectura de software
(estímulo-respuesta), o bien

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 11

Indirectos, quienes representan cambios a la arquitectura existente, y por ende al sistema;
incluyen nuevas plataformas de hardware o software, agregar una nueva característica, integrarse
con una nueva pieza de software, reemplazar alguna funcionalidad existente, escalar el sistema,
etc.

Los autores determinan que cada uno de los intereses de los stakeholders debe ser reflejado en los escenarios.
Múltiples stakeholders pueden estar contemplados en múltiples escenarios de acuerdo a su interés. Para manejar
esto, proponen una matriz de escenarios que ayuda a considerar a cada escenario desde cada una de las
perspectivas de los stakeholders y desde la perspectiva de cada atributo de calidad o interés. Esta matriz se
esquematiza por medio de la figura 3.3.2.

Figura 3.3.2, Matriz de obtención de escenarios genérica.

Los escenarios obtenidos deben corresponder a la representación de la arquitectura de software. Para realizar
dicha correspondencia, se debe obtener:

1. Atributos de calidad
2. Escenarios abstractos
3. Escenarios derivados / específicos
4. Mecanismo genérico para responder al escenario
5. Mecanismo específico
6. Modelo analítico, los cuales representan el principio de la ingeniería arquitectónica, pues representan
de manera formal cómo serán medidos los atributos de calidad.

Vistas arquitectónicas

Cuando un arquitectura de software se encuentra representada por uno o más estilos arquitectónicos, patrones
arquitectónico o por patrones de diseño, es necesario conocer la manera en cómo interactúan los componentes
definidos unos con otros, cómo están interconectados dichos componentes entre sí, el tipo de plataforma de software
y de hardware dónde se ejecutarán los componentes, entre otros aspectos. En 1995, Kruchten y por su parte Nord,
[13] [14] dieron a conocer dos propuestas de vistas arquitectónicas para representar diferentes aspectos de una
arquitectura de software.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 12

Kruchten [13] propone cinco vistas:

Vista lógica. Describe el diseño de los objetos que son modelados cuando es utilizado un método de diseño
orientado a objetos. En esta vista también se puede modelar diagramas de entidad relación.

Vista de proceso. Describe el diseño de los aspectos de concurrencia y sincronización del sistema.

Vista física. Describe la relación de los componentes de software que serán ejecutados en el hardware y
refleja aspectos de distribución.

Vista de desarrollo. Describe la organización estática de los componentes de software en un ambiente de
desarrollo.

Escenarios. Muestran cómo los componentes de las cuatro vistas anteriores trabajan en conjunto de manera
transparente.

Por su parte, Nord [14] propone cuatro vistas, mismas que definiremos en la siguiente técnica.

En la actualidad no existe un estándar que defina las vistas que debe tener una arquitectura de software, cada
arquitecto de software puede utilizar y/o crear sus propias vistas, las cuales sin lugar a dudas considerarán estos
elementos, sin embargo es posible tomar como referencia las vistas antes mencionadas.

Diseño de Arquitectura de Software Efectivo con UML

Nord, Paulish, Soni y Hofmeister mencionan en su artículo “Effective Software Architecture Design: From Global
Analysis to Uml Descriptions” [15] que hoy en día es generalmente aceptado que el separar la arquitectura de
software en múltiples vistas puede ayudar a reducir la complejidad y la toma de decisiones sobre diseño de trade-
offs. Proponen la realización de vistas arquitectónicas por medio de UML1 para analizar los factores que influencian la
arquitectura y desarrollar estrategias para adaptar esos factores en el diseño de la arquitectura. En el artículo, los
autores presentan los diagramas UML que pueden ser elaborados para representar cada una de las vistas
arquitectónicas. Las vistas que consideran para la representación de la arquitectura son [16]:

Vista conceptual. Describe la arquitectura en términos de elementos del dominio. El arquitecto diseño las
características funcionales del sistema.

Vista de módulo. Describe la descomposición del software y su organización en capas. Una consideración
importante aquí es limitar el impacto de un cambio en software y hardware.

Vista de ejecución. Es la vista de tiempo de ejecución del sistema: es el mapeo de los módulos a entidades en
tiempo de ejecución, definiendo la comunicación entre ellos y asignándoles los recursos físicos. El uso de
recursos y desempeño son los principales intereses (concerns) en la vista de ejecución. Decisiones como el
uso de una librería ligada o compartida, o el uso de hilos o procesos, se hacen aquí, aunque esas decisiones
pueden retroalimentar a la vista de módulos y requerir cambios.

Vista de código. Captura cómo los módulos e interfases en la vista de módulos son correspondidas hacia los
archivos fuente, y cómo las entidades en tiempo de ejecución en la vista de ejecución son correspondidas a
los archivos ejecutables. La partición de esos archivos y cómo están organizados en los directorios afecta la
construcción del sistema.

1 Unified Modeling Language, lenguaje para especificar, visualizar, modelar, construir y documentar artefactos de sistemas de
software.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 13
3.4. Estándares

A continuación describiremos brevemente dos importantes estándares, el modelo ISO 9126-1 y el estándar
IEEE Std 1471-2000 que son importantes considerar para el diseño y documentación de una arquitectura de
software.

Modelo ISO 9126-1

Existe un modelo de la ISO (International Organization for Standardization) que permite identificar las atributos
de calidad que pueden caracterizar a una arquitectura de software [7]. El modelo es conocido como modelo de
calidad ISO 9126-1. Indica que la calidad está definida por el conjunto de características del producto que reflejan su
capacidad para satisfacer su objetivo o cubrir necesidades. Clasifica y define los diferentes atributos de calidad que
pueden ser considerados en un sistema de software. Menciona que diferentes atributos de calidad pueden ser
considerados por diferentes stakeholders, y propone un flujo de actividades para la selección de una arquitectura de
software candidata de acuerdo a los atributos de calidad que contempla. Dicho flujo de actividades es el siguiente:

1. Obtener requerimientos funcionales por medio de casos de uso.
2. Obtener requerimientos no funcionales.
Especificación de los requerimientos de calidad de acuerdo al dominio del problema.
Especificación de las restricciones tecnológicas.
Especificación de las características de calidad para cada caso de uso.
3. Priorizar casos de uso.
4. Detallar casos de uso.
5. Identificar la arquitectura candidata, de acuerdo a:
Experiencia (arquitectura previamente utilizada y/o patrones existentes)
Información clave obtenida de los casos de uso.
Conjunto de patrones o estilos arquitectónicos.
Acorde a los atributos de calidad.
Puede ser especificada gráficamente por medio de un estándar, diagrama de componentes y
conectores, o formalmenteutilizando lenguajes de descripción de arquitectura o lenguajes
formales.
Las sub-características y atributos relevantes del dominio del problema, deben ser organizados en
una tabla como la que se muestra en la figura 3.4.1.

Figura 3.4.1, Tabla de comparación de arquitecturas de acuerdo a atributos de calidad.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 14

La tabla muestra una relación entre los atributos de calidad con las arquitecturas candidatas, así como
observaciones o comentarios de dicha relación que ayudan a tomar la decisión de la arquitectura de software en la
que se basará un sistema de información.

Como se puede observar, las columnas muestran la arquitectura candidata a ser seleccionada. Las
medidas son calculadas para cada uno de los atributos de acuerdo a las métricas propuestas por el
framework mostrado en la figura 3.4.2.
Cada atributo es priorizado de acuerdo a los requerimientos expresados en el modelo de calidad
para el dominio del problema.

6. Aplicar el framework de medición arquitectónica basado en el ISO 9126-1 para seleccionar la
arquitectura candidata, mostrado en la figura 3.4.2.

Figura 3.4.2, Framework para la medición arquitectónica.

7. Analizar la tabla de evaluación. Los valores de los atributos de calidad relevantes son analizados de
acuerdo a los escenarios (posible trade-offs).

IEEE Std 1471-2000

El estándar IEEE 1471-2000 [17] recomienda prácticas enfocadas a las actividades de creación, análisis y
sustento de una arquitectura de software de un sistema de gran escala, así como la documentación de la misma por
medio de descripciones arquitectónicas. Además, el estándar establece un marco conceptual para descripciones
arquitectónicas, así como el contenido del mismo.

El estándar considera y describe los siguientes elementos:

Contexto de las descripciones arquitectónicas.
Los stakeholders y sus roles.
Las actividades de la arquitectura en el ciclo de vida.
Los usos de una descripción arquitectónica.
La documentación arquitectónica.
La identificación de los stakeholders y sus intereses en la arquitectura.
La selección de viewpoint arquitectónicos.
Consistencia a través de las vistas arquitectónicas.
El razonamiento arquitectónico.

El arquitecto de software puede utilizar este estándar como referencia para la documentación de una
arquitectura de software.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 15
3.5. Herramientas

Quality Function Deployment

Quality Function Deployment (QFD) es un método estructurado para planear y desarrollar un producto, de tal
manera que se especifiquen claramente los deseos y necesidades del cliente, para después evaluar la capacidad del
mismo en términos de su impacto o conocimiento de dichas necesidades (traducido de) [18]. En términos prácticos,
QFD es una metodología para identificar y traducir necesidades y deseos del cliente a: requerimientos técnicos,
características que se puedan medir y características de ingeniería para el desarrollo de un producto.

QFD hace uso de una tabla, llamada casa de calidad, en dónde registra las necesidades del cliente y las traduce
a requerimientos técnicos, lo cual se va refinando a través de diferentes niveles, de tal manera que se cubran todos
los requerimientos o características del producto. Una tabla QFD consiste de seis secciones (ver figura 3.5.1)
(traducido de) [19] en donde se especifica textualmente:
• Necesidades y beneficios del cliente.
• Matriz de planeación, la cual registra:
Importancia para el cliente
Representación de la satisfacción del cliente
Representación de la satisfacción de la competitividad
Metas
Razón de mejora
Punto de ventas
Valor normalizado
• Respuesta técnica, necesidades del cliente traducidas a un lenguaje técnico.
• Relaciones entre la respuesta técnica y las necesidades del cliente, lo cual se puede medir con: no ligado
(0), posiblemente ligado (1), moderadamente ligado (3), fuertemente ligado (9).
• Matriz técnica. Las respuestas técnicas son priorizadas sumando el valor de cada una de las columnas de la
respuesta técnica.
• Correlación técnica. Representa la relación entre las respuestas técnicas (grado de impacto).

Technical
Correlation

Technical Response
Cu
st
om
er
n
ee
ds
a
nd
b
en
ef
its

Relationships
Im
po
rt
an
t
to
c
us
to
m
er

Cu
st
om
er
s
at
is
fa
ct
io
n
pe
rf
or
m
an
ce

Co
m
pe
tit
iv
e
sa
tis
fa
ct
io
n
pe
rf
or
m
an
ce
s
G
oa
l
Im
pr
ov
em
en
t
ra
di
o
Sa
le
s
Po
in
t
N
or
m
al
iz
ad
r
aw
w
ei
gh
t
Priorities
Competitive Benchmarks
Own performance
Te
ch
ni
ca
l
m
at
riz

Target
Figura 3.5.1, Casa de calidad de QFD.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 16

Los requerimientos arquitectónicos de una arquitectura de software pueden ser identificados y traducidos a
requerimientos técnicos mediante el uso de QFD, partiendo de la idea de que dicha arquitectura será utilizada para
obtener un producto de software. De esta manera, existe una adaptación de QFD para el desarrollo de software, la
cual es denominada Software Quality Function Deployment (SQFD). SQFD es una técnica de solicitud de
requerimientos, adaptable a cualquier metodología de ingeniería de software, que cuantificablemente, solicita y
define requerimientos críticos del cliente (traducido y modificado de) [20]. Los factores que toma en cuenta QFD son
los mismos considerados por SQFD, pero con el enfoque de software.

Con lo anterior, hemos descrito brevemente: 1) algunos conceptos básicos de arquitecturas de software; 2)
algunas propuestas de proceso para arquitecturas de software, en dónde explicamos el modelo de Desarrollo Basado
en Arquitecturas, que contempla los pasos fundamentales para construir una arquitectura de software, y el modelo
Diseño de Arquitectura de Software: Evaluación y Transformación, que propone un método de diseño de
arquitecturas de software mediante la evaluación y transformación iterativa hasta obtener los resultados esperados
de dicha arquitectura; 3) técnicas para el diseño de arquitecturas de software, en dónde expusimos el Diseño Basado
en Arquitecturas, que propone la manera en cómo se puede descomponer el concepto de un sistema de software
para llegar a elementos de diseño, el método de Arquitectura Basada en Escenarios, el cual propone el uso de un
matriz de obtención de escenarios para relacionarlos con los diferentes atributos de calidad esperados en el sistema y
con los diferentes stakeholders interesados en el mismo, las vistas arquitectónicas de Kruchten y Nord, y el método
de Diseño de Arquitectura de Software Efectivo con UML, dónde se presentan las vistas que recomienda Nord para
describir una arquitectura de software, así como los diagrama UML que se proponen para describir cada vista; 4)
algunos estándares relacionados con arquitecturas de software, en dónde mencionamos el modelo ISO 9126-1, que
especifica los atributos de calidad que pueden tener un sistema de software y un flujo de actividades para
seleccionar arquitecturas candidatas de acuerdo a dichos atributos de calidad, y el estándar IEEE 1471-2000, que
recomienda prácticas enfocadas a las actividades de creación, análisis y sustento de una arquitectura de software; y
finalmente 5) herramientas adicionales, en dónde expusimos la metodología que sigue QFD para identificar
necesidades de los clientesy convertirlos en requerimientos técnicos de arquitecturas de software.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 17

4. Propuesta de Solución

La propuesta de solución para nuestro problema se encuentra basada en las diferentes aportaciones de
importantes autores que fueron descritas en la sección de trabajo previo del presente documento. La esencia de
nuestra propuesta consiste en abstraer los elementos relevantes de cada uno de los trabajos previos, con el objetivo
de definir un modelo de proceso para elaboración de arquitecturas de software con la consideración de varias de las
aportaciones que hacen los expertos en esta materia.

De acuerdo a la problemática expuesta en la sección de la descripción del problema del presente documento, y
después de analizar los diferentes conceptos, modelos, técnicas y herramientas que se proponen en la literatura en el
campo de arquitecturas de software, presentamos a continuación el Modelo para el Desarrollo de Arquitecturas de
Software – MODAS, el cual representa un proceso definido para la elaboración de arquitecturas de software, mismo
que permite elaborar una arquitectura nueva, reutilizar una arquitectura existente o dar mantenimiento a una
arquitectura en operación. El modelo parte del documento de especificación de requerimientos de software en el
caso de una arquitectura nueva, y del documento de arquitecturas de software para la definición de una arquitectura
reutilizada o en mantenimiento. Nuestro modelo contempla los siguientes pasos, mismos que se representan la figura
4.1 de acuerdo a sus entradas, salidas y flujos correspondientes:

1. Identificación de los requerimientos arquitectónicos
2. Diseño de la arquitectura
3. Verificación de la arquitectura
4. Adecuación de la arquitectura
5. Documentación de la arquitectura
6. Evaluación de la arquitectura
7. Validación de la arquitectura

Figura 4.1, Modelo pare el desarrollo de arquitecturas de software – MODAS – Proceso General.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 18

La figura 4.1 representa el panorama general de la solución que muestra nuestro modelo. Como se puede
observar, el proceso puede recibir como objetivo la definición de una nueva arquitectura de acuerdo a los
requerimientos de software, la reutilización de una arquitectura existente observando que cumple con los
requerimientos de software establecidos, o bien, el mantenimiento a una arquitectura de software para incorporación
de nuevos requerimientos. La salida del proceso puede ser una arquitectura liberada, o una arquitectura no
aprobada, la cual debe ser adecuada en el caso de que existan cambios menores, o volver a generar el proceso de
manera completa en el caso de contar con cambios mayores.

El modelo de proceso permite diseñar una arquitectura después de identificar los requerimientos
arquitectónicos, o bien, verificar directamente que la arquitectura cumpla con los requerimientos arquitectónicos
establecidos si se trata de una arquitectura reutilizada o en mantenimiento. En cualquiera de los dos casos, este
último paso verificará la completes y el correcto diseño de la arquitectura, con el objetivo de adecuarla si se observan
inconsistencias, o bien documentar el diseño realizado. Es importante señalar que tanto en el momento de realizar el
diseño de la arquitectura, como en su adecuación, pueden documentarse ciertas elementos, mismos que se
formalizarán en el paso de documentación de la arquitectura.

Para llevar a cabo nuestro paso de evaluación de la arquitectura, haremos uso del proceso para evaluación de
arquitecturas de software, propuesto por Omar Gómez [21]. Este proceso recibirá como entrada el documento de
arquitectura de software obtenido, y después de realizar ciertos análisis con herramientas como SNA (Survivability
Network Analysis), ALMA (Architecture-Level Modifiability Analysis), entre otros, reportará si la arquitectura es
adecuada con respecto a los atributos de calidad especificados, si existe algún conflicto entre los mismos, y
recomendaciones para su adecuación. A su vez, este proceso mencionará el impacto y el riesgo que correrá el diseño
de la arquitectura de software sin la incorporación de ciertos elementos, estilos o patrones. En caso de que la
arquitectura no apruebe la evaluación, se llevará a cabo el proceso de adecuación, verificación, documentación y
evaluación nuevamente. Si por el contrario la arquitectura aprueba la evaluación, se ejecutara el paso de validación,
mismo que se encarga de estudiar el diseño de la arquitectura con los diferentes stakeholders para determinar si
cubre sus requerimientos establecidos, o bien debe sufrir adecuaciones menores o mayores. Si se descubren cambios
menores en la validación, entonces se llevará a cabo el proceso de adecuación, verificación, documentación y
validación nuevamente, pero si por el contrario se determinan cambios mayores, como incorporación de nuevos
requerimientos, entonces se ejecutará nuevamente todo el proceso.

En la siguiente sección del presente documento definiremos a detalle las actividades a realizar, las entradas y
salidas internas, las herramientas que apoyarán dicha actividad y las métricas que ayudarán a controlar y mejorar el
proceso para cada uno de los pasos del modelo.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 19

5. Modelo para el desarrollo de arquitecturas de software

El modelo de proceso para el desarrollo de arquitecturas de software que proponemos, consta de siete pasos
básicos: identificar los requerimientos de software, diseñar la arquitectura, verificar la arquitectura, adecuar la
arquitectura, documentar la arquitectura, evaluar la arquitectura, y validar la arquitectura. Cada uno de estos pasos
recibe ciertas entradas, proporciona ciertas salidas, maneja entradas y salidas internas, hace uso de herramientas, y
en ciertos casos define una métrica para el control y mejoramiento del mismo proceso.

Nuestro modelo para el desarrollo de arquitecturas de software, se encuentra fundamentado en el modelo que
describen Bass y Kazman conocido como: “Desarrollo Basado en Arquitecturas” (Architecture-Based Development)
[3]. Este modelo consta de seis pasos, los cuales son: obtener los requerimientos arquitectónicos, diseñar la
arquitectura, documentar la arquitectura, analizar la arquitectura, generar la arquitectura y mantener la arquitectura.
Los autores describen las actividades que se realizarán en cada paso, proponiendo el uso de ciertas herramientas
para algunos de ellos, como por ejemplo: una matriz de obtención de escenarios para obtener los requerimientos y el
método ATAM (Architecture Tradeoff Análisis Method) para realizar el análisis de la arquitectura. Sin embargo, al
analizar este modelo, podemos observar que no se menciona con mucho detalle las tareas específicas a realizar
internamente, no son rápidamente identificadas, no se mencionan entradas y salidas internas, ni métricas para
controlar y mejorar el proceso. En la figura 5.1 podemos observar la relación que guarda nuestro modelo con el
modelo Architecture-Based Development.

Architecture-Based Development Modelo para el Desarrollo de Arquitecturas de Software

Figura 5.1, Architecture-Based Development en relación con el
Modelo para el Desarrollo de Arquitecturas de Software.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software –Reporte Técnico de Investigación 20

Como se puede observar en la figura 5.1, el modelo Architecture-Based Development considera un paso
enfocado a generar la arquitectura de software mediante código, el cual no es considerado por el Modelo de
Desarrollo de Arquitecturas se Software. A su vez, este primer modelo considera el mantener la arquitectura de
software como un paso dentro del proceso, el cual se conecta nueva mente al inicio del mismo. Por su parte, nuestro
segundo modelo considera el mantenimiento de la arquitectura como un objetivo de entrada del proceso, el cual,
después de identificar los requerimientos arquitectónicos, omitirá el paso de diseñar la arquitectura, para
directamente verificarla y adecuarla. Por su parte, el Modelo de Desarrollo de Arquitecturas se Software, considera
tres pasos adicionales: verificar la arquitectura, el cual determinará si la arquitectura se encuentra completa y sin
errores de diseño antes de ser evaluada; adecuar la arquitectura si requiere de cambios después de verificación o
validación, y finalmente validar la arquitectura con los diferentes stakeholders una vez que se haya generado el
documento de arquitectura de software y haya pasado la evaluación correspondiente.

De esta manera, podemos decir que el Modelo de Desarrollo de Arquitecturas se Software se fundamenta en el
modelo Architecture-Based Development, incorporando pasos adicionales que ayudan a su correcto diseño, así como
la incorporación de elementos que facilitan la identificación de actividades a realizar. Los elementos que
adicionalmente considera el modelo de proceso son:

Entradas y salidas del proceso general.
Definición de los pasos internos de cada uno de los pasos generales del proceso.
Detalle de entradas y salidas de las actividades de los pasos del proceso.
Uso de herramientas que apoyan cada pasos del proceso.
Incorporación de métricas que ayudan a controlar y mejorar el proceso.

El modelo de proceso permite desarrollar una nueva arquitectura de software, reutilizar una arquitectura de
software existente para cubrir los requerimientos arquitectónicos de un nuevo sistema, o bien, dar mantenimiento a
una arquitectura que se encuentre en operación.

Las entradas que presenta el modelo de proceso son:
Documento de especificación de requerimientos de software para el caso de la elaboración de una nueva
arquitectuela.
Documento de especificación de requerimientos de software y documento de arquitectura de software para el
caso de la reutilización de una arquitectura previamente definida.
Documento de arquitectura de software y definición de nuevos requerimientos para el caso del mantenimiento
de una arquitectura de software en funcionamiento.

Las salidas que presenta el modelo de proceso son:
Documento de arquitectura de software liberado
Documento de arquitectura de software sin liberar, con observaciones y recomendaciones de adecuación.

Los pasos que considera el Modelo para el Desarrollo de Arquitecturas de Software, son:

1. Identificar requerimientos arquitectónicos, el cual, mediante el documento de especificación de
requerimientos, o definición de nuevos requerimientos de software, permite analizar los requerimientos
funcionales y requerimientos no funcionales para ser convertidos a requerimientos técnicos que darán
las directrices del diseño o adecuación de la arquitectura de software, según se el caso de definir una
nueva arquitectura, reutilizar una arquitectura existente o dar mantenimiento a una arquitectura en
operación.

2. Diseñar la arquitectura, mediante el cual el sistema se descompone en subsistemas, componentes y
elementos de diseño, mismos que al conceptualizarse y asignar funcionalidad representarán nuestro
diseño arquitectónico.

3. Verificar la arquitectura, por medio del cual determinaremos la completes de los requerimientos en el
diseño, así como el correcto diseño de los componentes de software, dando la posibilidad a que la
evaluación se enfoque en la detección de problemáticas profundas y con un mayor grado de
especialización, de los atributos de calidad de la arquitectura.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 21

4. Adecuar la arquitectura, el cual permitirá realizar ajustes o adaptaciones al diseño de la arquitectura de
software una vez que fue verificada, evaluada o validada y se identificó que no cubre los
requerimientos establecidos, o bien se encuentran mal diseñados.

5. Documentar la arquitectura de software, por medio del cual representaremos gráfica y textualmente la
arquitectura de software, además de plasmar los requerimientos que cubre, orientadores
arquitectónicos que dan la directriz de la arquitectura, el uso de estilos arquitectónicos, patrones
arquitectónicos y/o patrones de diseño, decisiones de diseño, intereses de los diferentes stakeholders,
entre otros aspectos.

6. Evaluar la arquitectura de software, mediante el cual determinaremos si la arquitectura de software
cumple con los requerimientos no funcionales o atributos de calidad, si existe algún conflicto entre
dichos atributos de calidad, o bien el impacto y riesgo que puede traer como consecuencia la ausencia
de ciertos estilos, patrones o componentes en la arquitectura de software.

7. Validar la arquitectura de software, por medio del cual, finalmente determinaremos con los diferentes
stakeholders que la arquitectura de software se encuentre acorde a los requerimientos establecidos y
cubra todas las necesidades. Si al validarla se identifican cambios menores, podrá ejecutarse el paso
de adecuación, documentación y validación nuevamente; pero si se identifican cambios mayores,
podrá ejecutarse todo el proceso nuevamente.

Figura 5.2, Vista detallada del Modelo para el Desarrollo de Arquitecturas de Software.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 22

La figura 5.2 muestra una vista detallada del Modelo para el Desarrollo de Arquitecturas de Software, en dónde
se especifican las entradas y salidas de cada paso, así como las herramientas que apoyarán la realización de las
actividades de cada uno de ellos. La definición de cada paso con cada uno de sus elementos la describiremos más
adelante. Hacemos uso de uno de los profiles de UML (Unified Modeling Language) para modelar procesos de
negocio, creado por Eriksson y Penker 2. Por medio de este profile de UML describiremos cada paso de nuestro
modelo de procesos. La notación que utilizaremos se describe en la tabla 5.3:

Símbolo Descripción

Representa una entrada o salida del proceso
general, es decir de manera externa.

Representa un paso del proceso, ya sea en el
proceso general, así como los sub-pasos internos.

Indica una entrada o salida interna del proceso, es
decir, en los sub-pasos.

Se refieren a las herramientas que se utilizarán
como recursos dentro de cada uno de los pasos del
modelo

Indica las métricas que se registrarán en ciertos
pasos del proceso para controlarlo y mejorarlo.

Se refiere a la indicación del seguimiento de un
flujo, la entrada la un recurso, o bien el registro de
una métrica.

Se refiere a la indicación de un flujo opcional.

Representa la decisión sobre un camino que puede
seguir el proceso de acuerdo a las salidas
obtenidas en el paso previo.

Tabla 5.3, Notación para describir el Modelo para el Desarrollo de Arquitecturas de Software.

A continuación detallaremos el flujo interno que contiene cada uno de los pasos de nuestro modelo
representado en la figura 5.2, así como la descripción de los elementos que los conforman.

5.1. Identificar requerimientos arquitectónicosEste paso permite identificar los requerimientos arquitectónicos del sistema que será desarrollado. El análisis de
los mismos se realizará a través del documento de especificación de requerimientos de software y de una matriz de
seguimiento a requerimientos, para el caso de una arquitectura nueva o reutilizada, o bien, la definición de los
nuevos requerimientos, para el caso del mantenimiento de una arquitectura existente. El objetivo de este paso es
analizar los requerimientos funcionales y requerimientos no funcionales del sistema para ser convertidos en
requerimientos técnicos, los cuales darán las directrices del diseño o adecuación de la arquitectura de software,
según sea el caso del objetivo inicial de entrada del proceso.

2 Eriksson, Hans-Erik and Penker, Magnus, Business Modeling with UML, Business Patterns at Work, Wiley Computer Publishing,
2000.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 23

La figura 5.1.1 muestra las actividades que sigue este paso, especificando sus entradas, salidas, herramientas a
utilizar y registro de métricas.

Figura 5.1.1, Paso: Identificar requerimientos arquitectónicos del
Modelo para el Desarrollo de Arquitecturas de Software.

Los elementos a considerar para este paso del proceso son:

Elemento Descripción
Entradas
Documento de especificación de requerimientos de software y matriz de seguimiento a
requerimientos, para el caso de una arquitectura nueva o reutilizada, o la definición de los nuevos
requerimientos, para el caso del mantenimiento de una arquitectura existente.
Salidas
Escenarios directos e indirectos que afectan la arquitectura, matriz de relación de escenarios,
orientadores arquitectónicos y la selección del posible método analítico que podrá medir los
requerimientos no funcionales en el diseño arquitectónico.
Recursos
SQFD, el ISO 9126-1, modelo de escenarios directos e indirectos, la matriz de relación de escenarios
de Kazman, Carrière y Woods [9], y métodos analíticos para medir atributos de calidad.
Métricas
Número de requerimientos funcionales y no funcionales entre número de requerimientos técnicos
definidos, así como número de escenarios definidos entre el número de stakeholders y entre número
de atributos de calidad establecidos.
Roles Analista y arquitecto.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 24

Como mencionamos anteriormente, este paso parte con el documento de especificación de requerimientos de
software, matriz de seguimiento a requerimientos, o bien un listado de requerimientos funcionales y requerimientos
no funcionales del sistema, cuya arquitectura está siendo elaborada. Los requerimientos funcionales pueden estar
especificados mediante casos de uso de UML.

Por medio de los requerimientos funcionales y no funcionales del sistema, el arquitecto deberá analizar e
identificar los requerimientos que afectan la arquitectura, así como los atributos de calidad que se espera cumpla la
misma. Los diferentes stakeholders, a través de la especificación de sus diferentes intereses sobre la arquitectura de
software, pueden ayudar a determinar los atributos de calidad considerados para dicha arquitectura. El arquitecto
puede apoyarse de la ayuda del analista o analistas quiénes especificaron los requerimientos del sistema cuya
arquitectura está siendo construida para la identificación de los requerimientos arquitectónicos.

Una vez que contamos con la identificación de requerimientos funcionales y requerimientos no funcionales que
afectan la arquitectura, debemos convertirlos a requerimientos técnicos, mismos que reflejan los requerimientos
arquitectónicos para nuestro diseño. Para la obtención de estos requerimientos arquitectónicos, se propone el uso de
la técnica SQFD, con el objetivo de traducir requerimientos funcionales, no funcionales e intereses del cliente a
requerimientos técnicos que consideren atributos de calidad para la arquitectura de software.

La secuencia de pasos que se debe seguir de acuerdo a (traducido y modificado de) [19] [20] para la
preparación de una casa de calidad SQFD es la siguiente, misma que se ilustra con la figura 5.1.2:

1. Registrar los requerimientos funcionales del sistema en la sección de “requerimientos y beneficios del
cliente” de la casa de calidad representados por casos de uso. Los casos de uso que se encuentren
relacionados deben ser agrupados. Las sentencias de los requerimientos son comúnmente sentencias
cortas registradas específicamente en la terminología del cliente (nombre del caso de uso) y son
acompañadas de una definición detallada (caso de uso).

2. En conjunto con los clientes, los requerimientos son convertidos a un enunciado técnico y medible del
producto de software. Estos enunciados corresponden a los componentes de la arquitectura de software
(elementos), mismos que son colocados en la sección de “respuesta técnica” de la casa de calidad.

3. Los clientes participan completando la correlación técnica de la matriz identificando la solidez de las
relaciones entre los diferentes requerimientos de usuario y la especificación técnica del producto. Es
importante obtener consenso concerniente a las relaciones fuertes.

4. La importancia o prioridad de cada uno de los casos de uso deben ser especificada y registrada en la
sección de “importancia para el cliente”. Esta importancia puede ser identificada con 1, 3 y 9, dónde 1 es el
de menos importante y el 9 es el más importante.

5. Determinar la relación entre componentes de la arquitectura y los casos de uso. Para cada uno de los casos
de uso, la arquitectura de software determina cual responsabilidad de un componente son utilizados por el
caso de uso. Posteriormente, buscar el resultado de las relaciones, el cual es utilizado para el indicador de
prioridad de los componentes, sumando los resultados de la multiplicación de las prioridades de los
requerimientos del cliente por los valores de la correlación entre los requerimientos del cliente y la
especificación técnica del producto. Este valor es convertido a porcentaje. El resultado es registrado en la
sección de relaciones. El resultado final del proceso de SQFD contendrá una especificación técnica del
producto y su prioridad.

Grupo de Ingeniería de Software
CIMAT

Modelo para el Desarrollo de
Arquitecturas de Software

José Hdez. S. – Maestría en Ingeniería de Software – Reporte Técnico de Investigación 25

3
Technical
Correlation

Technical Response
Cu
st
om
er
n
ee
ds
a
nd
b
en
ef
its

Relationships
Im
po
rt
an
t
to
c
us
to
m
er

Cu
st
om
er
s
at
is
fa
ct
io
n
pe
rf
or
m
an
ce

Target
4
2
1 5
Figura 5.1.2, Casa de calidad de SQFD.

Con lo anterior, hemos descrito la manera en cómo obtener los requerimientos arquitectónicos por medio de
una especificación técnica del producto de software. Para obtener información más detallada acerca de esta técnica,
se recomienda consultar las referencias: [19] [20].

Para efectos del control de nuestro proceso, en este paso debemos registrar la métrica de número de
requerimientos funcionales y no funcionales entre el número de requerimientos técnicos establecidos, con el objetivo
de conocer cuántos requerimientos cubrirá la arquitectura de