PDF de programación - Captura del razonamiento y evolución de arquitecturas de software mediante la aplicación de operaciones arquitectónicas orientadas a objetivos

Captura del razonamiento y evolución de arquitecturas

de software mediante la aplicación de operaciones

arquitectónicas orientadas a objetivos

María Luciana Roldán, Silvio Gonnet, y Horacio Leone

INGAR (UTN-CONICET), Facultad Regional Santa Fe, UTN, Santa Fe, Argentina

{lroldan, sgonnet, hleone}@santafe-conicet.gov.ar

Resumen. Durante el proceso de diseño de una arquitectura de software, los ac-
tores que participan del mismo toman numerosas decisiones de diseño. Para com-
prender cómo surgió una determinada arquitectura de software, es importante
conservar esas decisiones de diseño junto con el razonamiento que las explican.
Sin embargo, este conocimiento generalmente se pierde, ya que su representación
o documentación es una carga extra de trabajo para quienes lo producen. Para
superar este problema, se propone un modelo de operaciones que permite por un
lado la definición de operaciones que codifican decisiones de diseño recurrentes,
y por otro lado, su aplicación para materializar las decisiones de diseño durante
el proceso de construcción de la arquitectura de software. El modelo posibilita
definir operaciones orientadas a objetivos, de manera que su ejecución refleje no
sólo la decisión sino también el por qué de la misma, permitiendo registrar en
forma casi transparente y natural la intención del diseñador, y mantener la traza-
bilidad entre las decisiones, los elementos arquitectónicos afectados y los objeti-
vos perseguidos o alcanzados.

Keywords: architecture documentation,design rationale, design decisions, goal-
oriented operations

1 Introducción

Las arquitecturas de software permiten describir un sistema complejo con alto nivel de
abstracción y hace posible a arquitectos y diseñadores razonar sobre las propiedades
del sistema [1]. Éstas son los artefactos resultantes de un proceso de diseño, en el cual
diferentes actores toman numerosas decisiones que tienen algún impacto en la arqui-
tectura final. Para comprender porqué una arquitectura de software es como es, es im-
portante conservar esas decisiones de diseño [2, 3, 4, 5, 6] junto con el razonamiento
en las que se basan. El proceso de diseño de arquitecturas de software (SADP) com-
prende las primeras decisiones sobre un sistema complejo que contemplan sus requeri-
mientos de calidad, funcionales y sus restricciones. Diseñadores, arquitectos y otros
“stakeholders” han reconocido la importancia de documentar decisiones de diseño junto
con su razonamiento, y no sólo capturar el artefacto arquitectónico final generado [7].
Sin embargo se reconoce que existen dificultades que inhiben la práctica de documentar
las decisiones y el razonamiento de diseño, como la sobrecarga de trabajo que implica



ASSE 2015, 16º Simposio Argentino de Ingeniería de Software. 44 JAIIO - ASSE 2015 - ISSN: 2451-7593299 para el diseñador. En la práctica, representar el razonamiento arquitectónico se consi-
dera una tarea intensiva en tiempo y esfuerzo, la cual no tiene grandes beneficios en el
corto plazo, desde la perspectiva de los productores de este conocimiento. Por esta ra-
zón frecuentemente es evitada o realizada inadecuadamente [8, 9]. El razonamiento de
diseño, sin embargo, en la práctica es pobremente documentado y frecuentemente se
encuentra poco estructurado, lo que significa que reside sólo en la mente de los arqui-
tectos, y finalmente se pierde.

Partiendo de la idea de que cada decisión tomada por el arquitecto siempre persigue
la satisfacción de cierto objetivo, en este trabajo se propone un modelo que posibilita
la definición y ejecución de operaciones arquitectónicas orientadas a estos objetivos.
De esta manera, cada operación define la semántica de una decisión. Esta semántica
está dada por: i) el posible contexto al que puede aplicarse la operación, es decir, las
precondiciones que deberían cumplirse y los tipos de objetivos que se podrían alcanzar
con su aplicación, ii) el impacto esperado sobre la arquitectura de software, lo cual está
dado por el efecto de las acciones que forman el cuerpo de la operación sobre el diseño
arquitectónico. El uso del modelo de operaciones propuesto facilita la documentación
de la evolución de la arquitectura en una forma natural al proceso de diseño, y permite
mantener la trazabilidad entre los elementos arquitectónicos afectados y los objetivos
perseguidos o alcanzados. En trabajos anteriores [10, 11], hemos propuesto un modelo
que captura cada decisión realizada en un SADP junto con los productos resultantes,
haciendo posible la trazabilidad entre ellos y la reconstrucción de la historia del proceso
de diseño. En el presente trabajo, dicho modelo es redefinido para posibilitar la defini-
ción y ejecución de operaciones orientadas a objetivos.

A continuación, en la sección 2, se mencionan trabajos relacionados. En la sección
3, se introduce el enfoque del modelo de representación del proceso de diseño que es
la base del presente trabajo. En la sección 4, se aborda el modelo conceptual para defi-
nición y ejecución/captura de operaciones orientadas a objetivos. Además, se presenta
un dominio para SADP que no sólo incluye tipos de objeto de diseño para representar
los principales bloques de construcción de una arquitectura de software, sino también
permite definir tipos para representar elementos relativos a razonamiento arquitectó-
nico. Para ilustrar las capacidades de definición de operaciones se presentan algunos
ejemplos de operaciones orientadas a objetivos. En la sección 5 se presenta un escenario
en el cual se empleó el modelo propuesto para capturar la evolución de una arquitectura
de software de un sistema que fue migrado a la cloud. Por último, en la sección 6 se
presentan las conclusiones del trabajo.

2 Trabajos relacionados
Aportes recientes consideran a la trazabilidad como un método para seguir el proceso
de desarrollo de software [12, 13, 14]. Por otro lado, varios autores se han concentrado
en el modelado y captura del razonamiento para poder representar y seguir la evolución
de los productos del proceso de desarrollo [15, 16]. A pesar de su importancia, existen
escasas propuestas que aborden el proceso de desarrollo de forma integrada, y las
existentes en su mayoría no permiten la representación del mismo junto al conocimiento
empleado. Este problema ha sido reconocido por diversos autores en diferentes
dominios de la ingeniería de software [2-6, 8, 9], quienes concuerdan en que las

ASSE 2015, 16º Simposio Argentino de Ingeniería de Software. 44 JAIIO - ASSE 2015 - ISSN: 2451-7593300 decisiones tomadas constituyen conocimiento tácito, el cual a pesar de ser esencial para
la solución alcanzada, no es explícitamente documentado, ni forma parte del artefacto
resultante. Esto conduce a que en futuras revisiones o modificaciones del artefacto a
construir (durante su evolución), sea difícil y costoso establecer correspondencias entre
las decisiones de diseño y las razones que las respaldaron.

Otra línea vinculada con la temática es la de administración de los productos de
los procesos de diseño, entendiendo aquí como productos a los modelos, datos,
diagramas, programas, etc. Existen desde hace tiempo, sistemas de administración de
productos y de sus versiones [17], los cuales son ampliamente utilizados en la práctica.
Estos responden a la necesidad básica que los productos de un proceso de desarrollo
deben ser almacenados y organizados. Los sistemas de administración de productos, así
como los sistemas de administración de configuraciones de software [18], están
enfocados en productos, principalmente en código fuente y software ensamblado, y no
contemplan el seguimiento del proceso de diseño. Estos sistemas presentan dificultades
para la posterior recuperación de información sobre qué requerimientos fueron
contemplados, qué restricciones fueron adoptadas/relajadas, qué decisiones de diseño
fueron realizadas, qué alternativas fueron consideradas, y cuál fue la seleccionada,
durante el proceso de desarrollo.

3 Un modelo para la representación del proceso de diseño y

evolución de arquitecturas de software

El modelo propuesto para definición de operaciones orientadas a objetivos (OpOOs)
está basado en nuestro trabajo previo, que consiste en un modelo para la captura de
procesos de diseño ingenieriles y una herramienta que lo implementa parcialmente [10,
11]. Dicho modelo posee un enfoque operacional, en donde las decisiones de diseño
son materializadas en la ejecución de operaciones de diseño aplicables a los tipos de
productos manejados en el dominio.
A partir de la representación del proceso de evolución mediante las operaciones ejecu-
tadas y los productos generados, se espera poder responder a diferentes preguntas acerca
de cómo se llevó a cabo dicho proceso. Por ejemplo:

i) ¿Cuáles fueron los elementos arquitectónicos afectados por la ejecución de una

operación o secuencia de operaciones (decisión)?

ii) ¿Qué operaciones se ejecutaron? ¿Qué objetivos perseguían? ¿Qué requerimien-

tos intentaban satisfacer?

iii) ¿Qué productos surgieron como consecuencia de la ejecución de una determinada

operación (decisión)?

iv) ¿Qué operaciones se ejecutaron para alcanzar un cierto objetivo?
v) ¿Qué operación dio lugar a la aparición de determinado producto?
vi) ¿Qué objetivos no fueron considerados en el proceso de diseño de la arquitectura?

Para poder responder a tales cuestiones, el modelo se sustenta en un esquema de
administración de versiones que permite capturar y representar la evolución de los dis-
tintos productos del diseño en forma conjunta con las operaciones aplicadas a los mis-
mos. El modelo considera el proceso de diseño como una secuencia de actividades que
operan sobre los productos del proceso de diseño, denominados objetos de diseño. Los

ASSE 2015