RACCIS, 3(2), 19-37, 2013

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software
ISSN: 2248-7441

www.fundacioniai.org/raccis
raccis@fundacioniai.org

From Business Model to System Architecture Considering Goals, Aspects and

Quality Standards
Del Modelo de Negocio a la Arquitectura del Sistema Considerando Metas,
Aspectos y Estándares de Calidad
Jean Carlos Guzmán1, Francisca Losavio2, Alfredo Matteo3
1 Vice-Chancellorship for Virtual Studies. Caribbean International University. Willemstad, Curaçao. Jeancguzman(AT)outlook.com.
2-3 Laboratorio de Modelos, Software y Tecnología (MoST). Escuela de Computación, Facultad de Ciencias, Universidad Central de
Venezuela. Caracas, Venezuela. 2francislosavio(AT)gmail.com, 3alfredojose.matteo(AT)gmail.com.

INFORMACIÓN DEL ARTÍCULO ABSTRACT

Tipo de artículo: Investigación
Historia del artículo:
Recibido: 13-08-2013
Correcciones: 12-10-2013
Aceptado: 21-11-2013
Categories and Subject Descriptors:
D.2.4 [Software Engineering]:
Management – Software process
models.
General Terms:
Business Process Management,
Engineering, Requirements
Engineering, Software Architectures.
Keywords:
Architecture Design; Business
Model; Goals; Aspects; Quality
Standards
Palabras clave:
Diseño Arquitectónico; Modelo de
Negocio; Orientación a Metas;
Orientación a Aspectos; Estándares
de Calidad
At present business models have been converted into strategic assets for enterprise
organizations. They facilitate information management for decisions making, transactions
between parties and optimized services. The goal of this work is to present an Architectural
Design Process (DAOMAC) integrating Goals, Aspects and Quality Standards techniques and
practices, to obtain an Initial Architecture for the software system from the business model.
The main contribution of this work is to consider explicitly non-functional requirements in
the different abstraction levels involved in the process to obtain the initial architecture
model, and guaranteeing their traceability: tasks originating non-functional goals in the
business model where they are not explicitly considered, non-functional crosscutting goals
in the goal model, crosscutting concerns treated as softgoals and operationalizations in the
SIG (Softgoal Interdependency Graph) model. The main artifact obtained is the initial
architecture and its logical view can be appreciated in the DAOMAC application to the case
study, an administrative service process of the Citizen Identification and Registration
System. Another important contribution is the specification of non-functional requirements
by the ISO/IEC 25010 standard to facilitate their traceability and the communication among
work groups.
RESUMEN
Actualmente los modelos de negocio se han convertido en activos estratégicos para las
organizaciones empresariales. Ellos facilitan el manejo de información para toma de
decisiones, transacciones entre las partes y optimización en prestación de servicios. El
objetivo de este trabajo es presentar un proceso de Diseño Arquitectónico Orientado a
Metas, Aspectos y Calidad (DAOMAC) para obtener una Arquitectura Inicial del sistema de
software a partir del modelo de negocio. La contribución principal de este trabajo es haber
considerado explícitamente en el proceso los requisitos no funcionales en varios niveles de
abstracción desde el modelo de negocio, en el cual no están contemplados explícitamente,
hasta llegar al modelo de la arquitectura inicial, garantizando así la trazabilidad entre los
modelos utilizados por las diferentes técnicas: tareas que originan metas no funcionales a
nivel de modelo de negocio, metas no funcionales transversales en el modelo de metas,
incumbencias transversales, softgoals y operacionalizaciones en el modelo SIG (Softgoal
Interdependency Graph). El principal artefacto obtenido es la arquitectura inicial, cuya vista
lógica se aprecia en la aplicación de DAOMAC al caso de estudio, el proceso de Gestión de
Trámites de Identificación del Servicio Administrativo de Identificación, Migración y
Extranjería (SAIME). Otro aporte significativo es la especificación de todos los requisitos no
funcionales por el estándar ISO/IEC 25010, para facilitar su trazabilidad y la comunicación
entre los grupos de trabajo.

© 2013 IAI. All rights reserved.

1. INTRODUCCIÓN
Los cambios del entorno exigen hoy día a las empresas,
desarrollar capacidades y competencias que le posibiliten
ofrecer productos y servicios con alto valor agregado,
para enfrentar las demandas actuales y futuras a las que
están siendo sometidas como resultado de profundas
transformaciones culturales, económicas, políticas,
sociales y tecnológicas. Las empresas bajo este contexto,
son sistemas organizacionales diseñados para alcanzar
objetivos y metas, están compuestos por subsistemas
interrelacionados que cumplen funciones especializadas,
supeditadas al consenso sistemático entre personas para
19
lograr algún propósito específico. De allí la necesidad de
establecer y utilizar modelos de negocio. Un Modelo de
Negocio, es un punto inicial para la elaboración del
sistema de software; es útil para que el equipo de
desarrollo entienda mejor la especificación de los
requisitos globales, que el futuro sistema debe satisfacer
[43]. Sin embargo, cómo pasar del modelo de negocio al
modelo del sistema tomando en cuenta propiedades no
funcionales (no directamente percibidas por el usuario)
en las etapas tempranas del ciclo de vida del software, es
aún un problema por resolver. Actualmente existe un
consenso en considerar estas propiedades como
elementos clave para construir la arquitectura inicial de
un sistema de software. En [34], se considera una
Arquitectura Inicial, como la estructura computacional
que posee los componentes principales del sistema de
software, a partir de la cual se articulará el resto del
sistema.
Existen en la literatura muchos trabajos que comparan
diferentes enfoques de diseño arquitectónico; en el
presente trabajo consideramos el estudio reciente
realizado en [23], en el cual se comparan nueve métodos
de diseño arquitectónico que consideran diferentes
enfoques de análisis de requisitos, todos centrados en la
captura de requisitos no funcionales para el diseño
arquitectónico, desde siete criterios seleccionados
después de aplicar la técnica de análisis de características
propuesta en [32]: orientación a metas, metas de negocio,
orientación a aspectos, evaluación arquitectónica,
especificación de requisitos de calidad, notación
arquitectónica y herramientas de soporte. Se destacan los
siguientes resultados: - ninguno de los métodos
estudiados considera estándares para la especificación de
los requisitos de calidad; - seis métodos admiten la
orientación a metas, de los cuales tres consideran el
modelado del negocio como nivel de abstracción inicial; -
dos métodos enfatizan la orientación a aspectos; - solo
uno combina las orientaciones a metas y a aspectos.
Finalmente, se precisa un conjunto de directrices
(incluyendo técnicas y artefactos) que son consideradas
en nuestro trabajo para la definición de un proceso de
diseño arquitectónico que incorpora las técnicas
mencionadas de metas, aspectos y estándares de calidad
las cuales serán descritas en secciones posteriores.
En función de lo observado, el objetivo principal de este
trabajo es presentar un proceso de Diseño Arquitectónico
Orientado a Metas, Aspectos y Calidad (DAOMAC) para
obtener una Arquitectura Inicial, a partir de un modelo de
negocio. El proceso inicia con la descripción textual de un
modelo de negocio; la calidad exigida es especificada bajo
el estándar de calidad ISO/IEC 25010 [31] para facilitar la
trazabilidad y comunicación durante el proceso de
desarrollo. A nivel de la organización empresarial, el
modelo de negocio es expresado en la notación BPMN
(Business Process Model and Notation) [3, 48]. Uno de
nuestros aportes en este nivel, ha sido detectar aquellas
tareas o actividades funcionales que originan una meta no
funcional y que en general, no son contempladas en los
modelos de negocio [43]. Una “Tarea No Funcional” en
nuestro contexto de modelado del negocio, corresponde a
una actividad que culmina con la consecución de una
meta, que el usuario no percibe directamente y esto se
pone de manifiesto en los niveles de abstracción
subsiguientes de orientación a metas y aspectos. En vista
que BPMN [48] no permite expresar metas sino tareas y
asociaciones entre estas tareas, las asociaciones entre
tareas y metas no funcionales se han denotado en BPMN
por la “etiqueta” estereotipada de UML (Unified Modelling
Language) [46], «MNF». En general, hablaremos entonces
de metas no funcionales a nivel de BPMN que indican
objetivos de calidad asociados a una tarea, como por
ejemplo consideraciones de seguridad para el acceso al
sistema o grado de precisión de un cómputo.
Actualmente, la consideración de metas no funcionales a
nivel de modelado de negocio cobra mayor importancia
con la automatización directa de los procesos de negocio
mediante Servicios Web [59, 64]. A nivel de la Ingeniería
de Requisitos, estas tareas no funcionales o <<MNF>>,
corresponden a Metas No Funcionales en el modelo de
metas, el cual se expresa en el Lenguaje de Requisitos
Orientado a Metas o GRL (Goal-oriented Requirements
Language) [30]. Se tomarán también en cuenta aquellas
metas no funcionales que afectan o entrecruzan a otras
metas, o Metas No Funcionales Transversales, las cuales
fueron definidas y tratadas en [22], para así garantizar su
consideración temprana en el contexto de la Orientación a
Aspectos o AOSD (Aspect-Oriented Software Development).
La meta no funcional transversal principal es el requisito
no funcional transversal considerado de mayor prioridad;
a todas la metas no funcionales se asignan prioridades y
son refinadas hasta llegar a operacionalizaciones
concretas, que corresponden a mecanismos o soluciones
arquitectónicas; en [23] estos mecanismos o soluciones
fueron evaluados para seleccionar una opción adecuada
entre varias alternativas arquitectónicas disponibles; la
solución seleccionada es candidata a ser tratada como
componente aspecto en la conformación de la arquitectura
inicial.
Utilizamos como caso de estudio para la aplicación y
primera validación del proceso propuesto, la descripción
textual del proceso de Gestión de Trámites de
Identificación tomado del área gubernamental, en el
dominio de gobierno electrónico, y adelantado por la
Dirección Nacional de Identificación, que involucra a las
Unidades Medulares del Servicio Administrativo de
Identificación, Migración y Extranjería (SAIME), en
Caracas, Venezuela.
Este artículo, además de la introducción, la conclusión y el
agradecimiento, consta de cuatro secciones: la segunda
sección presenta el contexto del trabajo, que contempla el
modelado del negocio en BPMN, el modelado de metas en
GRL, el diseño arquitectónico y modelo de calidad, la
orientación a aspectos. La tercera sección discute los
principales trabajos relacionados con el tema. En la cuarta
sección se presenta el proceso de diseño arquitectónico
DAOMAC propuesto. Finalmente, en la quinta sección, se
aplica el proceso DAOMAC al caso de estudio de Gestión
de Trámites de Identificación del SAIME.
20
2. CONTEXTO DEL TRABAJO
La empresa como sistema organizacional ve actualmente
la necesidad de cumplir con expectativas de calidad de
sus productos y servicios, tales como flexibilidad a
cambios, la seguridad e interoperabilidad de datos y
programas. Para representar estas características de
calidad proponemos el uso de estándares, como la norma
ISO/IEC 25010 [31], dentro de las buenas prácticas de la
Ingeniería del Software, para facilitar así la comunicación
entre los grupos de trabajo y la mejor trazabilidad de los
requisitos no funcionales. Satisfacer las necesidades de
calidad del producto requiere de un fuerte impulso de la
propia industria, que se ha visto motivada por las
exigencias de las comunidades, particularmente en el
ámbito de instituciones gubernamentales, donde el papel
de la tecnología es un elemento fundamental, para el
manejo de la información de estos sistemas, desde la
perspectiva del negocio.
Bajo esta premisa, los modelos de negocio se han
convertido en un activo estratégico necesario que facilita
el manejo de la información para la toma de decisiones,
transacciones entre las partes y optimización de la
prestación de servicios, como elementos transcendentes
en la adecuación de la empresa al entorno. En un sentido
amplio, un servicio es un conjunto de actividades que
busca responder a las necesidades del cliente. En tanto
que, prestar un servicio de calidad implica satisfacer a
cabalidad los requisitos y las necesidades del cliente [28].
Un servicio de gran importancia para las sociedades
mundiales, especialmente para la sociedad venezolana, es
el servicio de Identificación y Registro de Ciudadanos, el
cual constituye un modelo de negocio para la tramitación
de cédulas de identidad y pasaportes de los venezolanos,
así como solicitudes de identificación formuladas por
ciudadanos extranjeros. Es necesario señalar que este
servicio subyace a nivel gerencial al proceso de Gestión de
Trámites de Identificación, objeto de este estudio, el cual
está a cargo de la Dirección Nacional de Identificación,
que involucra a las Direcciones Medulares del Servicio
Administrativo de Identificación, Migración y Extranjería
(SAIME), organismo dependiente del Estado Venezolano.
La alta gerencia de esta institución exige su
automatización, dado el aumento del volumen de
demandas de solicitudes, tanto de cédula de identidad
como de pasaporte.
2.1 Modelos de negocio en BPMN y de metas en GRL
En vista que las operaciones son repetitivas y se
desarrollan cotidianamente en una organización, es
pertinente su automatización; esto conlleva a considerar
necesariamente la definición del negocio como soporte al
proceso de ingeniería del sistema de software. Por lo
tanto, la fase de modelado del negocio se hace necesaria
como etapa previa al diseño arquitectónico de un sistema
de software.
Un Modelo de Negocio, ofrece una vista abstracta y
simplificada de la realidad compleja en la que se expresan
conceptos sobre el funcionamiento del negocio de una
entidad, en términos de metas y factores de importancia
que reflejan su lógica. A nivel conceptual y notacional, el
modelo conceptual está conformado por un diagrama
constituido de elementos que contextualizan el negocio,
como son actores, actividades, entidades, procesos y
vínculos, entre otros [5]. Por ejemplo, un modelo de
negocio en el dominio de la banca electrónica o e-banking,
está integrado por actores sociales, infraestructura
tecnológica y plataforma computacional de soporte a las
diferentes operaciones y procesos que subyacen al
negocio.
En [37] se plantean las características principales del
modelado de negocio: - permite una mejor comprensión de
los mecanismos clave de un negocio existente; - actúa como
base para crear sistemas de información; - facilita la
identificación de ideas para mejorar la estructura actual
del negocio y su operación; - permite experimentar un
nuevo concepto de negocio; - admite la identificación de
oportunidades de Outsourcing; y - representa la estructura
de un negocio bajo la noción de proceso.
En [25] se define un proceso como una colección de
actividades, que toma una o varias clases de entradas y
genera una salida de valor para el cliente. Un Proceso de
Negocio (PN) se concibe como un conjunto vinculado y
natural de actividades basadas en habilidades y
competencias de trabajo, que incluyen interacciones entre
actores, recursos utilizados y vínculos de dependencias
entre estos [27]. Es más que una mera conexión de
actividades, ya que incluye elementos tales como
propósitos o intenciones, recursos utilizados, eventos,
acciones, actividades, desencadenamiento de tareas y
vínculos [25]. Las actividades de un proceso de negocio,
son ejecutadas de acuerdo a reglas preestablecidas para
satisfacer ciertas metas, las cuales son logradas a través
de una o más tareas interrelacionadas, permitiendo
obtener uno o más artefactos para una entidad concreta.
Son coordinadas por actores, quienes tienen la intención
de satisfacer ciertas metas [16]. La especificación de
procesos en el contexto del negocio permite al equipo de
desarrollo de software entender mejor y de un modo más
apropiado, las necesidades y los requisitos que el futuro
sistema debe satisfacer.
Un Modelo del Proceso de Negocio, se define en [58], como
una red de objetos gráficos que incluyen actividades y
controles de flujos, que describen el funcionamiento de
una organización. El modelo de proceso de negocio está
centrado principalmente en la representación gráfica de
esos procesos, usando lenguajes de modelado específicos,
tales como la notación BPMN [48] y el lenguaje GRL [30,
55]. En este trabajo utilizamos estos lenguajes como
entrada al proceso de construcción de una arquitectura
inicial, para establecer el enlace entre el modelo de
negocio y el modelo arquitectónico del software.
El lenguaje BPMN consiste tanto en una notación gráfica
como en una semántica subyacente. Su objetivo principal,
es ofrecer una notación entendible a todos los
participantes del proceso de negocio, porque se basa en el
lenguaje de modelado estándar UML [46]. BPMN utiliza
técnicas de flowcharting o diagrama de flujo y considera
21
cuatro categorías: Objetos de Flujo, Objetos de Conexión,
Carriles o “Swimlanes”, los cuales se especializan en
“pools” para identificar los actores y “lanes” para
identificar los roles de los actores, artefactos y dos
elementos para la modularidad: procesos y diagramas del
proceso de negocio o Business Process Diagrams (DPN),
los cuales manejan la complejidad inherente a un proceso
en particular. Soporta solo conceptos de modelado
aplicables al negocio desde un nivel de abstracción
organizacional intermedio, permitiendo definir,
documentar, organizar y rediseñar procesos desde una
perspectiva particular. Sin embargo una limitación
importante es que no trata aspectos no funcionales a nivel
de tareas que pueden ser derivados de reglas del negocio:
por ejemplo, declarar el acceso restringido a cierta
información para algunos usuarios, es una tarea con
objetivo de seguridad, que debe ser necesariamente
considerado [43].
Por otra parte, el lenguaje GRL, iniciado por la
International Telecommunication Union (ITU) como
subconjunto del estándar z.151, denominado Definición
del Lenguaje de la Notación de Requisitos de Usuarios o
User Requirements Notation (URN) Language Definition
[30], admite elicitación, análisis, especificación y
validación de requisitos, permitiéndoles a los ingenieros
descubrirlos y especificarlos en un sistema software. Es
un lenguaje orientado a metas, centrado en el
razonamiento sobre metas y los relativos atributos de
calidad, que se utilizan para medir metas no funcionales.
Es necesario señalar, que en el contexto de la Ingeniería
de Requisitos Orientada a Metas o GORE (Goal-Oriented
Requirement Engineering) [55], se plantean dos clases de
metas: las Metas Funcionales u objetivos duros,
“hardgoals”, que representan las intenciones deseadas
por un actor, los detalles específicos de cómo la meta va a
ser satisfecha no son descritos en la especificación de la
meta. Las Metas No Funcionales u objetivos blandos,
“Softgoals”, se pueden especificar como criterios o
restricciones que no dependen explícitamente del punto
de vista del actor; pueden ser globales, es decir válidas
para todo sistema. Están directamente relacionadas con
los requisitos de calidad, tales como adecuación funcional,
eficiencia en rendimiento, usabilidad, confiabilidad y
seguridad.
En este trabajo, GRL y su modelo de metas se utiliza como
enlace entre el modelo de negocio expresado en BPMN y
el modelo de arquitectura inicial del sistema de software,
que se representa en UML. GRL proporciona
construcciones para expresar diferentes conceptos, que
surgen durante el proceso de ingeniería de requisitos y
está fundamentado en dos lenguajes de modelado
orientado a metas, i* [60] y el NFR Framework [8]; por lo
tanto sigue el enfoque GORE.
El lenguaje i* [60], es un enfoque centrado en procesos de
negocio, el cual admite la gestión sistemática e intencional
de metas funcionales y no funcionales, partiendo del
modelado de procesos de negocio, hasta llegar a los
componentes arquitectónicos [10, 11]. Está soportado por
un lenguaje con una notación y semántica dinámica,
fundamentada en la noción de intención de los actores,
quienes actúan de manera autónoma, en cumplir metas
[61, 62]. Este enfoque tiene como propósito la
identificación, representación, organización, análisis y
justificación de metas tanto funcionales como no
funcionales, bajo la noción de relaciones intencionales
entre actores de un sistema, quienes tienen propiedades
tales como creencias, habilidades y compromisos [63].
También facilita el análisis del dominio y el modelado del
ambiente, representado por los actores y sus relaciones
[35].
El Framework NFR para requisitos no funcionales [8], es
un enfoque orientado a metas que trata los requisitos no
funcionales como “softgoals”, en contraposición con los
requisitos funcionales, “hardgoals”, que corresponden a
metas funcionales. Los softgoals se identifican como
objetivos de alto nivel a ser logrados por el sistema; son
refinados hasta llegar operacionalizaciones concretas, que
permiten derivar componentes arquitectónicos [10]. Se
representan por un diagrama jerárquico de
interdependencias, el cual se denomina Softgoals
Interdependency Graph (SIG). Una operacionalización se
corresponde a un mecanismo arquitectónico, que
satisface o es una solución para el cumplimiento del
softgoal. El enfoque NFR tiene como finalidad
representar, organizar y analizar los requisitos no
funcionales de un sistema de software [9, 12].
GRL es el lenguaje de modelado de metas seleccionado en
este trabajo, por una parte porque integra elementos de i*
y del NFR framework, admite tanto la detección de
aquellos requisitos que se originan en el contexto del
software como la resolución de conflictos a través de
opciones alternativas de metas en competencia; facilita
una solución de diseño que satisfaga las metas u objetivos
de calidad; por otra parte, es de fácil comprensión y
utilización. En GRL existen tres categorías principales de
conceptos: a) actores (stakeholders u otros sistemas), b)
elementos intencionales (metas, softgoals, tareas, recursos
y creencias) y c) vínculos (incluye descomposiciones,
contribuciones y dependencias). Así mismo, soporta
análisis de estrategias que ayudan a resolver de manera
adecuada posibles conflictos (tradeoffs) subyacentes
entre las metas de los stakeholders. Una estrategia
consiste en un conjunto de elementos intencionales que
son de valor para la satisfacción inicial de metas no
funcionales. Estos valores de satisfacción capturan
situaciones contextuales o futuras: permiten elegir entre
medios alternativos para alcanzar las referidas metas.
Asimismo, BPMN es un lenguaje muy utilizado en la
práctica para expresar procesos de negocio, desde un
enfoque de Ingeniería de Procesos. Sin embargo,
recalcamos que los modelos derivados de BPMN solo
enfatizan los procesos, las tareas funcionales respecto al
negocio y no hay relación explícita con los sistemas de
software que pueden soportar esos procesos. En cambio,
el lenguaje GRL permite expresar metas de alto nivel
organizacional, del software y de los stakeholders, hacer
explícitas las dependencias entre actores, distinguir entre
22
agentes, posiciones y roles [1], y así razonar sobre cada
actor con respecto a sus relaciones con otros actores. A
continuación se describen elementos conceptuales acerca
del diseño arquitectónico y del modelo de calidad, que
será utilizado para especificar las propiedades no
funcionales en el modelo de negocio, los softgoals del SIG
y el tratamiento de aspectos.
2.2 Diseño arquitectónico y modelo de calidad
La Arquitectura de Software proporciona abstracciones de
alto nivel para la representación de la estructura, el
comportamiento y las propiedades esenciales de un
sistema de software. Es definida en [20], como un
conjunto de componentes, conectores y sus relaciones;
esta estructura posee un comportamiento global.
Describe la organización del sistema de software, las
relaciones con otros componentes, el ambiente y los
principios que gobiernan su diseño y evolución [29]. En
este contexto, la tarea del arquitecto es determinar cuáles
son los componentes arquitecturales más convenientes
en función de los requisitos iníciales (funcionales y no
funcionales) del sistema [34]. En [41], se define el Diseño
Arquitectónico como una disciplina que concibe a los
sistemas de software desde un alto nivel de abstracción,
los cuales están compuestos por componentes y
conectores, así como por partes y puertos que al ser
ensamblados, constituyen la arquitectura del sistema. En
este contexto, los componentes se refieren a los elementos
donde se llevan a cabo los cómputos, las partes
representan los roles, los puertos describen los puntos de
interacción entre el entorno y las partes internas; y los
conectores constituyen los medios por los cuales
interactúan los componentes y sus partes; en conjunto
éstos elementos conforman la estructura estática o lógica
de un sistema de software.
Lo trascendental en todo proceso de diseño
arquitectónico, es escoger en etapas tempranas del
proceso de desarrollo del software con base a la
dimensión del problema, una alternativa arquitectónica
adecuada y particularmente centrada en la dimensión de
la solución. Debido a este hecho, se plantea que la
arquitectura de software tiene un fuerte y determinante
efecto en la satisfacción de los requisitos de calidad de un
sistema, en virtud que la mayoría de las decisiones
tomadas durante el proceso de diseño arquitectónico se
alinean a los objetivos de calidad que persigue el sistema
final [15]. Tales requisitos pueden ser satisfechos por
diferentes soluciones arquitecturales, a través de estilos
arquitectónicos, patrones de diseño o patrones
arquitectónicos y, de esta manera, es necesario evaluar
entre varias alternativas con el propósito de elegir la más
adecuada. La selección de un patrón o solución
arquitectónica, es una decisión de diseño fundamental
para el desarrollo del sistema de software. Los estilos
arquitectónicos y patrones de diseño siguen una relación
de composición [6].
Un estilo arquitectónico, define una familia de sistemas en
términos de patrones que especifican un vocabulario de
los componentes y conectores usados como instancia de
ese estilo, adyacente a un conjunto de restricciones de
una solución en particular. En cambio, un patrón de
diseño es definido como una solución exitosa a un
problema general. De lo antedicho se desprende que un
patrón describe un problema que ocurre una y otra vez en
un ambiente particular, y describe el núcleo o core de la
solución a ese problema, mejorando y agilizando el
proceso de desarrollo a través del principio de
reutilización, que es natural en la disciplina de Ingeniería
del Software [14].
Por otra parte, la norma ISO/IEC 25010 [31] es un
estándar internacional utilizado por la comunidad
científica para especificar las propiedades o
características de calidad de un producto de software, que
deben ser refinadas hasta alcanzar los atributos de
calidad, que indican lo que debe ser medido en el
producto de software, a lo largo de todo su proceso de
desarrollo; esta especificación se denomina modelo de
calidad. En particular, en la etapa de diseño
arquitectónico el modelo de calidad facilita el proceso de
evaluación para la selección de mecanismos o soluciones
arquitectónicas entre varias soluciones candidatas a ser
evaluadas.
El modelo de calidad del producto de software, propuesto
en el estándar ISO/IEC 25010 [31], será utilizado en este
trabajo como herramienta principal para especificar
metas no funcionales en los diferentes niveles de
abstracción considerados en DAOMAC, que se detallan en
la Figura 1: «MNF» de BPMN, Metas No Funcionales de
GRL, Incumbencias Transversales, Softgoals y
Operacionalizaciones del Softgoals Interdependency Graph
y Componentes Aspectos en el modelo arquitectural. Es el
nuevo estándar internacional que actualiza el anterior
ISO/IEC 9126-1 del 2001. Se define la calidad del software
como la capacidad del software para satisfacer
necesidades establecidas o implícitas y es representada
mediante dos modelos: el Modelo de Calidad del
Producto, o vista de calidad del producto de software,
incluye la calidad de los subproductos o artefactos
construidos durante todo el proceso de desarrollo, y el
Modelo de Calidad en Uso o vista del usuario. El modelo
de calidad de producto que se utilizará en este trabajo, a
nivel de modelo de negocio, corresponderá inicialmente
al modelo de calidad del dominio, que representa las
características de calidad de una familia de productos
(sistemas) del dominio. ISO/IEC 25010 considera una
estructura jerárquica y propone ocho (8) características
de calidad de alto nivel [31]: adecuación funcional,
eficiencia en rendimiento, compatibilidad, usabilidad,
confiabilidad, seguridad, mantenibilidad y portabilidad.
Estas son refinadas en sub-características y definidas en
su último nivel por un conjunto de atributos (o elementos
medibles) de un producto de software definitivo o
intermedio en el proceso de desarrollo, para el cual la
calidad es descrita y evaluada. Entre estas sub-
características, se tiene [31]:
 Adecuación funcional: Completitud, Correctitud o
precisión y Ser apropiado.
 Eficiencia en rendimiento: Comportamiento en tiempo,
Utilización de recursos y Capacidad.
23
 Compatibilidad: Co-exigencia e Interoperabilidad.
 Usabilidad: Capacidad de ser aprendido, Ser
reconocido como apropiado, Capacidad de ser
operado, Protección de errores del usuario, Estética de
la interfaz usuario o apariencia y Capacidad de ser de
fácil acceso.
 Confiabilidad: Madurez, Disponibilidad, Tolerancia a
fallas y Capacidad de recuperarse o recuperabilidad.
 Seguridad: Confidencialidad, Integridad, No repudio,
Auditable y Autenticidad.
 Mantenibilidad: Modularidad, Reutilización, Capacidad
de ser analizado, Capacidad de ser modificado y
Capacidad de ser probado.
 Portabilidad: Adaptabilidad, Capacidad de ser
instalado y Capacidad de ser reemplazado.
2.3 Orientación a Aspectos
En particular, este trabajo considera el enfoque de
Desarrollo de Software Orientado a Aspectos, conocido en
la literatura como AOSD (Aspect-Oriented Software
Development) [33], para el tratamiento temprano de
requisitos o aspectos de interés, incumbencias o
“concerns” de un sistema de software [21]. Las
incumbencias que entrecruzan diferentes módulos de un
sistema, se denominan incumbencias transversales o
“crosscutting concerns” y son candidatas a ser tratadas
como aspectos en la etapa de implementación y/o
construcción del software. Un aspecto, es la estructura
que encapsula una incumbencia transversal [33] y su
origen es a nivel de implementación; sin embargo, de
acuerdo a AOSD, debe ser considerado también en las
etapas tempranas del desarrollo de software, para
facilitar así la evolución del sistema, especialmente en las
etapas de modelado del negocio, ingeniería de requisitos
y diseño arquitectónico.
Esta investigación pretende generar aportes hacia la
solución de los problemas planteados, particularmente en
cuanto a la correspondencia o trazabilidad entre el
modelo de negocio y el modelo de la arquitectura del
software, conforme a los requisitos no funcionales que
intervienen y que dirigen la construcción de la
arquitectura. Un elemento esencial que caracteriza
nuestra proposición, consiste en considerar los aspectos
no funcionales desde el modelo de negocio; se inspira en
uno de los principales trabajos de Axel Van Lamswerdee
[56], el cual solo aborda el nivel más abstracto del sistema
de software, pero no el modelo de negocio. Se considera la
trazabilidad entre los modelos involucrados y estándares
actuales, en cuanto a lenguajes de modelado y
especificación de requisitos de calidad. Se define para ello
un proceso completo para el diseño de una arquitectura
inicial, el cual hemos denominado DAOMAC, inspirado en
las directrices plantadas en [23], centrado en la
especificación de los requisitos de calidad por el modelo
de calidad de producto de software del estándar ISO/IEC
25010 [31] y en las técnicas señaladas de modelado del
negocio, GORE y AOSD.
3. TRABAJOS RELACIONADOS
Numerosos son los trabajos que tratan el tema de la
integración de la orientación a metas y aspectos, en el
diseño de la arquitectura del software. Mencionaremos
aquí los más conocidos y utilizados en la práctica o
directamente involucrados con el presente trabajo. En [4]
se presenta un enfoque de requisitos orientado a metas
de alto nivel de abstracción, y también expresados en
KAOS, el cual facilita la reutilización y diseños más
creativos. Utiliza también configuraciones arquitectónicas
para efectuar el paso de los requisitos a la arquitectura de
software. Las configuraciones proporcionan los detalles
arquitectónicos a los diseñadores, permitiendo la
correspondencia de los requisitos de mayor
transcendencia; así como la mejor comprensión de la
arquitectura del sistema de software candidata.
En [13] se presenta un marco conceptual, que sigue la
orientación a metas y que tiene por objetivo, apoyar el
diseño de arquitecturas de software adaptables,
utilizando patrones de diseño. Está centrado en el
Framework NFR, el cual trata los requisitos no
funcionales, como “Softgoal” a ser satisfechos. En [38] se
presenta un enfoque de diseño arquitectónico
fundamentado en el enfoque GORE, para la derivación de
arquitecturas de software a partir de un modelo de metas
expresado en GRL, que incorpora metas tanto del negocio
como del sistema utilizando escenarios expresados en
mapas de casos de uso o Use Case Maps, usados para
describir procesos de negocios definidos en GRL. Los
requisitos funcionales y no funcionales se especifican
como metas (funcionales o no) primero en una notación
gráfica no estándar de árbol; luego, son transformados a
escenarios orientados al diseño, que se ocupan del
refinamiento de los requisitos del sistema.
En [53] se presenta el enfoque ASAAM para la evaluación
de aspectos a nivel de diseño arquitectónico, que admite
la identificación y especificación explícita de
incumbencias transversales, en las etapas tempranas del
ciclo de vida de desarrollo de software. Así mismo, en [54]
se presenta un enfoque formal basado en el enfoque de
orientación a metas, para la derivación de arquitecturas
de software por medio de reglas de transformación,
aplicadas al modelo de requisitos. Los lenguajes de origen
y destino, son el lenguaje de alto nivel de requisitos KAOS
y el ADL (Architecture Description Language) Wright,
respectivamente. En [52] se plantea un enfoque iterativo
de evaluación y transformación de arquitecturas de
software, el cual utiliza y extiende de diversos enfoques
existentes, para crear un método para transformar
sistemáticamente arquitecturas de software, a través de
reglas.
En [50] se aborda el tema del diseño de Arquitecturas de
Líneas de Productos de Software o Software Product Line
Architecture (PLA) basado en incumbencias. Es un
“toolkit” de técnicas y explota la sinergia entre la
orientación a aspectos y MDE (Model Driven Engineering),
hacia un tratamiento sistemático de la variabilidad de los
productos en la línea de productos. Utiliza la herramienta
DiVA (Dynamic Variability in Adaptive System), tanto para
el manejo de la variabilidad dinámica como para
especificar requisitos; utiliza la orientación a metas para
identificar la intencionalidad de los requisitos en general.
24
Finalmente, los requisitos de calidad se especifican como
softgoals. Recientemente, en [7] se plantea un enfoque
sistemático de diseño arquitectónico orientado a metas,
basado en el enfoque de MDE y por ende, en
transformación de modelos para la generación de
arquitecturas de software, a partir de los modelos de i*:
incluye reglas de transformación para derivar
especificaciones arquitectónicas a partir de metas del
negocio y del sistema. Los lenguajes de origen y destino
son, respectivamente, el lenguaje de modelado i* y el ADL
Acme. Los requisitos de calidad se especifican como
softgoals y no se utilizan estándares para esta
especificación.
Finalmente, en [17] se presenta un enfoque de diseño
arquitectónico orientado a metas, basado en
transformaciones (refinamientos), denominado STREAM-
ADD, que extiende la versión clásica STREAM. Este
enfoque refina metas no funcionales del Modelo de
Razonamiento Estratégico de i* en mecanismos o
soluciones arquitectónicas, utilizando reglas de
transformación. Estos dos últimos enfoques, que son los
más similares al nuestro, en cuanto a la transformación de
metas en componentes arquitectónicos, refinan metas no
funcionales del Modelo de Metas de i* en mecanismos o
soluciones arquitecturales, utilizando reglas de
transformación; sin embargo, no tratan metas no
funcionales transversales, ni el paso del modelo del
Figura 1. Niveles de Abstracción considerados en la construcción del proceso DAOMAC
4.2 Proceso DAOMAC
DAOMAC es presentado en la Figura 2 utilizando la
notación estándar SPEM (Software Process Engineering
Metamodel) [47], también basada en UML [46], utilizando
la herramienta StarUML [36], como un modelo de proceso
y está conformado por un “paquete” con cuatro
disciplinas; cada disciplina es después descrita en otro
paquete:
 Construcción del Modelo de Negocio (MN) en BPMN;
 Obtención del Modelo de Metas (MM) en GRL a partir
del Modelo de Negocio (MN) en BPMN;
 Determinación de las Metas No Funcionales
Transversales (MNFT);
negocio al modelo de metas, ni la especificación de
requisitos de calidad por estándares.
4. EL PROCESO DE DISEÑO ARQUITECTÓNICO
ORIENTADO A METAS, ASPECTOS Y CALIDAD
A continuación se describe el proceso DAOMAC, a través
de sus disciplinas y los modelos involucrados.
4.1 Modelos que intervienen el proceso DAOMAC
En referencia a los modelos involucrados (Figura 1), el
proceso DAOMAC propuesto (Figura 2) considera los
siguientes: el modelo de negocio expresado en BPMN, con
la identificación de vínculos entre tareas funcionales y no
funcionales o «MNF» [43]; el modelo de metas expresado
en GRL para hacer la transición entre <<MNF>> del
modelo de negocio y los requisitos no funcionales o
softgoals del sistema de software de GORE y así
identificar las metas no funcionales transversales y su
refinamiento en el SIG como operacionalizaciones
concretas [22]; éstas son asociadas a
mecanismos/soluciones arquitectónicas, las cuales son
descritas y evaluadas de acuerdo a sus atributos o
propiedades de calidad, para la selección de una opción
adecuada entre varias alternativas. Se obtiene finalmente
el modelo de una arquitectura inicial del sistema [23],
expresada como vista lógica en UML 2.0 [46], en la cual se
identifican los componentes orientados a aspectos
(estereotipados en UML como «Aspect») y los
componentes funcionales.
 Construcción Orientada a Aspectos (OA) de la
Arquitectura Inicial.
Figura 2. Paquete del Modelo de Proceso DAOMAC
25
Disciplina I. Construcción de MN en BPMN.
Figura 3. Paquete de la Disciplina Construcción del Modelo de
Negocio (MN) en BPMN
Disciplina II. Obtención de MM en GRL a partir de MN en
BPMN.
Figura 4. Paquete de la Disciplina Obtención de MM en GRL a
partir de MN en BPMN
Disciplina III. Determinación de las MNFT.
Figura 5. Paquete de la Disciplina Determinación de las MNFT
Disciplina IV. Construcción OA de la Arquitectura Inicial.
Figura 6. Paquete de la Disciplina Construcción OA de la
Arquitectura Inicial
5. APLICACIÓN DEL PROCESO PROPUESTO A UN CASO
DE ESTUDIO
Como caso de estudio se considera la descripción textual
del proceso del servicio Gestión de Trámites de
Identificación del SAIME dada en la introducción, el cual
permite el establecimiento de flujos de trabajo o
workflows, en base a la estructura organizativa en sus
diferentes niveles gerenciales (estratégico, funcional y
operativo) con el propósito de automatizar los procesos
de solicitudes de cedulación (servicio gratuito) y
pasaporte (implica pago de impuestos y por consiguiente
la Meta No Funcional Adecuación Funcional, sub-
característica corrección o precisión). La meta funcional
principal o prioritaria, de más alto nivel organizacional,
está centrada en Gestionar Trámites de Identificación por
medio de redes seguras (implica la Meta No Funcional
seguridad) con el propósito de garantizar una interfaz de
usuario atractiva dirigida a la satisfacción del usuario
final (implica la Meta No Funcional usabilidad) y
disminuir los tiempos de respuestas de las solicitudes a lo
sumo tres días (implica la Meta No Funcional eficiencia). A
continuación se aplican al caso de estudio las disciplinas
del proceso DAOMAC descrito en la sección 4 (Figuras 2,
3, 4, 5 y 6).
Disciplina I. Construcción del MN en BPMN. En la Figura
7 se presenta el Modelo de Calidad ISO/IEC 25010 [31]
adaptado al contexto del proceso Gestión de Trámites de
Identificación como entrada al proceso DAOMAC, que se
utiliza para la especificación de las tareas no funcionales.
Puede verse que se ha incorporado al modelo de calidad
el conocimiento sobre los requisitos no funcionales
extraído de la descripción del dominio.
1. Crear los Pools y Lanes del Modelo de Negocio en BPMN.
A efectos de simplificar el caso de estudio, solo
mostramos aquí los Pools (o participantes del Modelo
de Negocio) Usuario así como los Lanes (o roles del
participante) Analista y Ciudadano en el Modelo de
Negocio de BPMN (Figura 8).
26

Figura 7. Modelo de Calidad para Gestión de Trámites de
Identificación
2. Definir las Tareas Funcionales y Subprocesos en los
Pools y Lanes. Se incorporaron al Modelo de Negocio el
evento de inicio, así como las tareas funcionales y
subprocesos que se describen a continuación (Figura
8): en el Lane Usuario-Analista, se definieron las
Tareas Funcionales: Pasaporte, Cédula y Enviar
Solicitud; Subprocesos: Realizar Solicitud, Control de
Acceso, Agendar Cita y Asignar Estatus a la Solicitud. Y
en Lane Usuario-Ciudadano, se definieron las Tareas
Funcionales: Aprobar Solicitud, Rechazar Solicitud,
Enviar Aprobación de Solicitud, Enviar Rechazo de
Solicitud; Subprocesos: Revisar Solicitudes, Control de
Acceso, Asignar Estatus a la Solicitud y Consultar
Cadena de Aprobación.
3. Incorporar Compuertas Exclusivas entre las diferentes
Tareas Funcionales y Subprocesos que subyacen en los
Pools y Lanes. Se agregaron las siguientes compuertas
exclusivas (Figura 8): En el Lane Usuario-Ciudadano:
entre el Subproceso Control de Acceso y las Tareas
Funcionales Pasaporte y Cédula, así como también
entre las citadas tareas y el Subproceso Agendar Cita.
Y en el Lane Usuario-Analista: entre el Subproceso
Control de Acceso y las Tareas Funcionales Aprobar
Solicitud y Rechazar Solicitud así como también entre
las citadas tareas y el Subproceso Asignar Estatus a la
Solicitud. Entre el Subproceso Asignar Estatus a la
Solicitud y las Tareas Funcionales Enviar Aprobación
de Solicitud y Enviar Rechazo de Solicitud así como
entre la Tarea Funcional Enviar Rechazo de Solicitud y
el Subproceso Consultar Cadena de Aprobación y el
Evento de fin.
4. Identificar Tareas No Funcionales y asociarlas a Tareas
Funcionales y subprocesos mediante el estereotipo
<<MNF>>. Se incorporan las siguientes «MNF» como
metas que deben satisfacer las Tareas Funcionales y
Subprocesos (Figura 8): Usabilidad: Subproceso:
Realizar Solicitud y Revisar Solicitudes; Seguridad:
Subproceso: Control de Acceso; Eficiencia: Subproceso:
Realizar Solicitud y Revisar Solicitudes; y Adecuación
Funcional: Tareas Funcionales: Pasaporte.
5. Establecer los Flujos de Secuencia y de Mensajes en
BPMN. Se estableció el Evento de fin así como los Flujos
de Secuencia y de Mensaje en el Modelo de Negocio de
BPMN (Figura 8).
Disciplina II. Obtención del Modelo de Metas en GRL a
partir del Modelo de Negocio en BPMN. En la Tabla 1 se
presentan las reglas de correspondencia semántica entre
los lenguajes BPMN y GRL [39].
1. En base al Modelo de Negocio, definir la Meta Funcional
Medular o Principal asignando prioridades y vínculos de
dependencias del Modelo de Metas. Basándonos en la
regla 1, definimos la meta medular o principal del
Modelo de Negocio de Gestión de Trámites de
Identificación y el nombre del modelo de metas en
GRL, denominado Modelo de Metas de Gestión de
Trámites de Identificación (Figura 9).
2. En base a los Pools y Lanes del Modelo de Negocio,
definir los Actores y Roles en el Modelo de Metas. El
Actor derivado de la regla 3 es: Usuario. De la
aplicación de la regla 4 definimos dos Roles en el Actor
Usuario, ya que este juega el papel de Ciudadano y de
Analista (Figura 9).
3. Identificar Pools, Lanes, Subprocesos, Tareas y
Asociaciones, Objetos de datos y Compuertas en BPMN y
hacerlas corresponder con Metas Funcionales, Metas No
Funcionales y Tareas en GRL. Primero, se detectan las
Metas No Funcionales que estén asociadas a aspectos
no funcionales del negocio en BPMN y se asocian con
las Metas No Funcionales o softgoals de GRL, mediante
la aplicación de la regla 6 (Figura 9): se asoció la tarea
funcional Pasaporte a la «MNF» Precisión en el Role
Usuario-Ciudadano.
Posteriormente, asociamos Tareas, Objetos de datos y
Compuertas de BPMN con Tareas, Recursos y Vínculos
de Descomposición de Tareas en GRL con la aplicación
de las reglas 5, 7 y 8 (Figura 9), como: en el Role
Usuario-Ciudadano: Se obtuvieron las Tareas:
Pasaporte, Cédula y Enviar solicitud. Y dentro de los
Vínculos de descomposición de tareas, se tiene: entre el
subproceso Control de Acceso y las tareas Pasaporte,
Cédula y Enviar solicitud; así como entre estas tareas y
el subproceso Agendar Cita y este con el subproceso
Asignar Estatus a la Solicitud. Y en el Role Usuario-
Analista: se generaron las Tareas: Aprobar Solicitud,
Rechazar Solicitud, Notificar Aprobación de Solicitud,
Notificar Rechazo de Solicitud y Enviar Aprobación de
Solicitud.
Así mismo dentro de los Vínculos de descomposición de
tareas, se tienen: entre el subproceso Control de Acceso
y las tareas Aprobar Solicitud y Rechazar Solicitud así
como también entre estas y el subproceso Asignar
Estatus a la Solicitud. Entre el subproceso Asignar
Estatus a la Solicitud y las tareas Enviar Rechazo de
Solicitud y Enviar Aprobación de Solicitud así como
entre la tarea Enviar Aprobación de Solicitud y el
subproceso Consultar Cadena de Aprobación.
27
 Figura 8. Modelo de Negocio de Gestión de Trámites de Identificación expresado en BPMN [48], utilizando BPM BizAgi [2]

Tabla 1. Reglas de correspondencia semántica entre GRL y BPMN [39]

Lenguaje BPMN Lenguaje GRL
Regla para la
Regla Notación
Termino Definición Notación Gráfica Termino Definición Correspondencia
Gráfica
Actividad realizada
Process o dentro o a través de Un Proceso de BPMN representa
1 Texto
Proceso empresas u una Meta Funcional en GRL.
Condición o estado de un
organizaciones [48]. Hardgoal o
asunto que a los
Meta Funcional Un Subproceso de BPMN
Agregación de stakeholders les gustaría
representa una Meta Funcional
Subprocess o actividades que son lograr [30].
2 que ha sido descompuesta en
Subproceso incluidas dentro de un
GRL en otras metas de nivel
Proceso [48].
inferior

Entidades activas que llevan

Pool Participantes (entidades Un Pool de BPMN representa un
3 Actor a cabo ciertas acciones para
o roles de negocio) [48]. Actor en GRL.
lograr metas [30].

Organizan y categorizan Caracterización abstracta Un Carril de BPMN es descrito

4 Lane o Carril actividades de un Pool Role o Papel del comportamiento de un como el Papel de un Actor
[48]. actor [1]. concreto en GRL.

Es una actividad atómica Es una manera particular de Una Tarea de BPMN representa
5 Task o Tarea Task o Tarea
[48]. hacer algo [30]. una Tarea particular en GRL.

Labeled Muestra la asociación Es una condición o estado

Una Asociación Etiquetada de
Association entre una tarea o de un asunto del mundo que
Softgoal o Meta BPMN relaciona una tarea
6 o subproceso funcional y a los stakeholders les
No Funcional funcional o subproceso de BPMN
Asociación una Meta No funcional, gustaría lograr (ITU-T,
con un Softgoal en GRL.
Etiquetada «MNF» 2012).
Artefacto que suministra
Data Object u Resource o Entidad física o
información a las Un Objeto de Datos en BPMN
7 Objeto de Recurso informacional que expresa
actividades a ser representa un Recurso de GRL.
Datos necesidades [30].
realizadas [48].
Task
Controlan la interacción, descomposition Tipo de vínculo que Una Compuerta en BPMN
Gateway o convergencia o link o Vínculo descompone una tarea en representa un Vínculo de
8
Compuerta divergencia dentro de un de un hardgoal, subtask, descomposición de tareas
proceso [48]. descomposición resource o softgoal [30]. (And/Xor/Ior) de GRL.
de tarea
Muestra la secuencia de Relación binaria entre un fin
Sequence Flow actividades que son Means-Ends link y el medio para lograrlos. El Un Flujo de Secuencia en BPMN
9 o Flujo de realizadas en un proceso o Vínculos “medio” representa una representa un Vínculo Medio-Fin
Secuencia [48]. Medio-Fin tarea y el “fin” una meta en GRL.
[30].
Un Flujo de Mensaje en BPMN
Message Flow Muestra el flujo de Dependency
Relación intencional entre representa un Vínculo de
10 o Flujo de mensaje entre dos link o Vinculo
dos actores [30]. Dependencia entre dos actores
Mensaje entidades [48]. de dependencia
en GRL.

28
 Figura 9. Modelo de Metas de Gestión de Trámites de Identificación expresado en GRL [30], utilizando jUCMNav [45]
Donde: Meta No Funcional o Softgoal: ; Meta Funcional o Hardgoal:
Dependencia: ; Contribución:
Luego, los subprocesos expresados de BPMN se
definen como una descomposición de una Meta
Funcional en GRL y los elementos subyacentes son
representados de acuerdo a las reglas y pasos que
tengan lugar, con la aplicación de la regla 6 (Figura 9),
se tiene: En el Role Usuario-Ciudadano: El subproceso
Realizar Solicitud tiene asociado las «MNF». Usabilidad
y Eficiencia. El subproceso Control de Acceso tiene
asociado las «MNF»: Seguridad. Y en el Role Usuario-
Analista: El subproceso Revisar Solicitud tiene
asociado las tareas no funcionales: Usabilidad y
Eficiencia. El subproceso Control de Acceso tiene
asociado las tareas no funcionales: Seguridad.
Finalmente, se describen las Metas Funcionales en GRL
resultantes de la aplicación de la regla 2 al Modelo de
Negocio de Gestión de Trámites de Identificación,
presentado en la Figura 8 (Figura 9): En el Role
Usuario-Ciudadano: Realizar Solicitud, Control de
Acceso, Agendar Cita y Asignar Estatus a la Solicitud. Y
en el Role Usuario-Analista: Revisar Solicitudes, Control
de Acceso, Asignar Estatus a la Solicitud y Consultar
Cadena de Aprobación.
4. En base a los elementos de los Pools y Lanes en BPMN,
establecer vínculos en GRL. En principio, se definieron
los Vínculos de Dependencia implícitos entre los
diferentes elementos de GRL, tales como tareas,
recursos, metas funcionales y no funcionales en base a
la regla 10 (Figura 9). Después, se generaron los
vínculos medio-fin en GRL a partir de flujos de
secuencias explicitados en BPMN, con la aplicación de
la regla 9. Posteriormente, se identificaron los Vínculos
de Correlación entre Metas No Funcionales Usabilidad,
Eficiencia, Precisión y Seguridad. Finalmente, se
establecieron las Contribuciones entre las Metas
; Tareas: ; Recursos: ;
; Correlación: ; Descomposición:
Funcionales o No Funcionales en GRL, especificadas en
las actividades anteriores; en la Figura 9 se muestra el
impacto cualitativo (Realizar o “Make”, Ayuda o
“Help”, AlgoPositivo o “SomePositive”, Desconocido
“Unknown”, AlgoNegativo “SomeNegative”, Ruptura o
“Break” y Afecta o “Hurt”) o cuantitativo (valores entre
-100% y 100%) conforme a [30].
Disciplina III. Determinación de las Metas No
Funcionales Transversales (MNFT).
1. Identificar las Metas Funcionales y No Funcionales en el
Modelo de Metas. Dentro de las Metas Funcionales, se
tiene: en el Role Usuario-Ciudadano: Realizar Solicitud,
Control de Acceso, Agendar Cita y Asignar Estatus a la
Solicitud. Y en el Role Usuario-Analista: Revisar
Solicitudes, Control de Acceso, Asignar Estatus a la
Solicitud y Consultar Cadena de Aprobación. Y dentro
de las Metas No Funcionales, se tiene: en el Role
Usuario-Ciudadano: Usabilidad, Eficiencia
(comportamiento en tiempo), Seguridad y Adecuación
funcional (Precisión); y en el Role Usuario-Analista:
Usabilidad, Eficiencia y Seguridad.
2. Especificar las Metas Funcionales y No Funcionales.
Para cada Meta Funcional, se especifican las metas
requeridas y las metas que la requieren, además de
información general sobre la meta. En este caso la
Meta Funcional Control de Acceso (Tabla 2) requiere
las Metas Funcionales Realizar y Revisar Solicitud y
depende de la Meta No Funcional Seguridad. Es
importante señalar aquí la “transitividad” entre las
metas: Control de Acceso es requerida por Revisar
Solicitud y Realizar Solicitud, por lo tanto estas tres
Metas Funcionales también dependen de la Meta No
Funcional Seguridad.
29
Tabla 2. Especificación de la Meta Funcional Control de Acceso Nótese que Adecuación funcional (Precisión) no es una
Nombre Control de Acceso Meta No Funcional Transversal porque solo
Fuente Modelo de Metas entrecruza a la Meta Funcional Realizar Solicitudes
Stakeholders Usuario-Ciudadano, Usuario-Analista (Tabla 4).
Descripción Controlar el acceso de los usuarios
Clasificación Funcional
Contribución Ninguna 4. Determinar Ambigüedades, Conflictos y Contribuciones.
Prioridad Muy Importante Se elabora la Tabla 6 de Contribuciones de Metas No
Concern Requerido Seguridad Funcionales.

Respecto a la Meta No Funcional Seguridad (Tabla 3) Tabla 6. Contribuciones de las Metas No Funcionales
se observa que no hay ninguna otra Meta No Funcional Meta No Funcional Usabilidad Seguridad Eficiencia
requerida y a ella la requiere la Meta Funcional Control Usabilidad Ayuda AlgoPositivo
de Acceso. Es importante señalar aquí el análisis de las Seguridad Ayuda Rompe
contribuciones que se registran respecto a las otras
Eficiencia AlgoPositivo Rompe
Metas No Funcionales: negativas respecto a la
eficiencia y positiva respecto a usabilidad y precisión.
Nótese que la Meta No Funcional Eficiencia rompe a la
Tabla 3. Especificación de la Meta No Funcional Seguridad Meta No Funcional Seguridad, dado que esta incide en
el tiempo de respuesta. En cambio la Meta No
Nombre Seguridad
Funcional Usabilidad ayuda a la seguridad en vista que
Fuente Modelo de Metas
Stakeholders Usuario-Ciudadano, Usuario-Analista
aporta la interfaz usuario que soporta el mecanismo
Descripción Gestionar Tramites de Identificación por de autorización para que el usuario acceda al sistema
medio de redes seguras de software. Además, que gráficamente en el Softgoal
Clasificación No Funcional Interdependency Graph (Figura 10), “Ayuda”
Contribución (-) Usabilidad, (-) Eficiencia
Prioridad Muy Importante corresponde a , “AlgoPositivo” corresponde a y
Concern Requerido Ninguno “Rompe” corresponde a . Así mismo, se elabora la
Tabla 7 de resolución de conflictos, la cual se presenta
3. Analizar las posibles Metas Transversales. Se construye a continuación.
la Tabla de Composición de Metas (Tabla 4).
Tabla 7. Resolución de Conflictos
Tabla 4. Composición de Metas
Meta No Funcional
Meta Funcional Decisión
Meta No Funcional / Meta Realizar Control de Revisar Transversal en Conflictos
Funcional Solicitudes Acceso Solicitudes (Ayuda) Usabilidad,
Adecuación funcional X Realizar Solicitudes (Rompe) Eficiencia,
(Realiza) Seguridad,
Usabilidad X X Por tratarse de un
(Ayuda) Usabilidad, sistema de Gestión
Eficiencia X X
Revisar Solicitudes (Rompe) Eficiencia, de Trámites de
Seguridad X X X (Realiza) Seguridad Identificación sobre
(Ayuda) Usabilidad, Internet, que
Asignar Estatus a involucra recursos
Nótese que las Metas Funcionales candidatas a la la Solicitud
(Rompe) Eficiencia,
(Realiza) Seguridad financieros, la
composición de metas son aquellas Metas Funcionales Seguridad prevalece.
que requieren de las Metas No Funcionales Adecuación Consultar Cadena
(Ayuda) Usabilidad,
(Rompe) Eficiencia,
funcional (precisión), Usabilidad, Eficiencia y de Aprobación
(Realiza) Seguridad
Seguridad. En tanto que la Meta Funcional Control de
Acceso es requerida por las Metas Funcionales Realizar
Debe observarse qué Control de acceso no aparece
Solicitudes y Revisar Solicitudes; en tanto que la Meta
porque no presenta conflictos ya que solo requiere
Funcional Control de Acceso solo depende de la Meta
Seguridad. Un ejemplo de como ayuda la Usabilidad en
No Funcional Seguridad: existe una transitividad entre
la Seguridad es en la incorporación de mecanismos
ambas. Por ende, las Metas Funcionales Realizar
arquitectónicos de Autorización de Acceso. Así mismo
Solicitudes y Revisar Solicitudes requieren de la Meta
al incorporar mecanismos de Seguridad como la
No Funcional Seguridad. Así mismo, se construye la
Encriptación y Desencriptación de Datos para las
Tabla de Metas No Funcionales Transversales (Tabla
transacciones financieras, esto incide en el tiempo de
5).
respuesta del sistema (Eficiencia), y en la
Tabla 5. Especificación de Meta No Funcional Transversal
insatisfacción del usuario (Usabilidad).

Meta No Funcional Incumbencia (Meta Funcional) que 5. Asignar prioridades a las Metas No Funcionales
Transversal Entrecruza
Transversales e Identificar la Meta No Funcional
Usabilidad (U) Realizar Solicitudes, Revisar Solicitudes
Transversales Principal. En principio, se determinan
Eficiencia (E) Realizar Solicitudes, Revisar Solicitudes prioridades entre las Metas No Funcionales
Seguridad (S) Realizar y Revisar Solicitud, Control de Acceso Transversales (Tabla 8).

30
Tabla 8. Prioridades Luego, se procederá a construir los Softgoal
Meta Importancia Importancia Importancia Interdependency Graph para las demás metas no
/Prioridad Alta Media Baja funcionales transversales, todas expresadas como
Usabilidad X características de calidad. Es necesario señalar que en
Seguridad X este trabajo, solo refinamos la meta Seguridad por
Eficiencia X razones de espacio.

La meta transversal Seguridad tiene alta importancia En la segunda columna de la Tabla 9, se muestra la
para la Gestión de Trámites de Identificación, dado descomposición de la meta Seguridad; se expresa
que toda operación debe ser autenticada por Internet. mediante el refinamiento del ISO/IEC 25010 (Figura
Por lo tanto, primero refinamos tanto en el Softgoal 10) en sub-características, el cual es directamente
Interdependency Graph (Figura 10) como en la tabla de reflejado en el refinamiento del Softgoal
Refinamiento, importancia, operacionalizaciones y Interdependency Graph y ayuda también al
mecanismos/soluciones arquitectónicas (Tabla 9, establecimiento de las prioridades, así como a la
primera columna), la meta transversal Seguridad. selección de las operacionalizaciones
correspondientes. Para simplificar la lectura solo
colocamos aquí la meta no funcional transversal
principal Seguridad.

Figura 10. Softgoal Interdependency Graph (SIG) para la Meta No Funcional Transversal Principal Seguridad expresado en GRL [30],
utilizando jUCMNav [45]

Tabla 9. Refinamiento, importancia, operacionalizaciones y mecanismos/soluciones arquitectónicas para la Meta No Funcional

Transversal seguridad
Refinamiento de la
Meta No Funcional
Meta No Funcional Importancia Operacionalizaciones Mecanismos/soluciones arquitectónicas
Transversal
Transversal
Acceso Limitado Limited Access Pattern
Integridad Media Firewall Pattern
Firewall
Proxy Pattern
Synmetric Encryption Pattern
Encriptación de Data
Asymmetric Encryption Pattern
Discretionary Access Control (DAC)
Confidencialidad Alta
Autorización de Acceso Mandatory Access Control (MAC)
Seguridad
Role-Based Access Control (RBAC)
Back-up de Data Homogeneous Redundancy Pattern
No Repudio Baja Certificado Digital Certificate Authority
Bitácora de Transacciones Logger-Auditor pattern
Auditable Media
Bitácora de Eventos Event logger pattern
Identificación Biométrica Authenticator pattern
Autenticidad Baja
Firma Electrónica Digital Signature Pattern

31
 Se incorporan seguidamente las posibles
Operacionalizaciones al Softgoal Interdependency
Graph, las cuales se muestran en la tercera columna de
la Tabla 9. Posteriormente, se soportan las decisiones
de diseño con argumentaciones (Figura 10, Tabla 10).
Tabla 10. Argumentaciones
Metas en Conflictos Argumentación
La Seguridad es adversa a la Eficiencia del
Seguridad-Eficiencia
sistema.
La Seguridad depende de la Usabilidad del
sistema; la componente Interfaz Usuario que
requiere alta usabilidad, es la responsable de la
incorporación de mecanismos arquitectónicos,
Seguridad-Usabilidad por ejemplo para la encriptación y la
desencriptación de datos en transacciones
financieras; esto incide en el tiempo de
respuesta del sistema (Eficiencia), y en la mayor
o menos satisfacción del usuario (Usabilidad).
Subsiguientemente, se establece el impacto de las
contribuciones entre Metas No Funcionales y
operacionalizaciones (Figura 10, Tabla 11). Las
contribuciones pueden ser establecidas
cuantitativamente por el Ingeniero de Metas o
Arquitecto, asignando un porcentaje que corresponde
al peso de la contribución entre Metas No Funcionales
o hacia una Operacionalización.
Así mismo, se pueden expresar cualitativamente como
tipos de contribuciones, por ejemplo de ruptura
(“Break”), como en el caso de la Eficiencia, que impide
el cumplimiento de la Meta No Funcional Seguridad o
de la Operacionalización Autentificación que ayuda
positivamente (“Ayuda”) al cumplimiento de la Meta
No Funcional Integridad. Los impactos cualitativos de
las contribuciones se muestran en la Tabla 11 y en el
SIG de la Figura 10. Finalmente, se incorporan los
mecanismos y/o soluciones arquitectónicas a las
operacionalizaciones (Tabla 9).
Para cada operacionalización, en la cuarta columna de
la Tabla 9, se incorporan aquellas soluciones
arquitectónicas que puedan resolver cada
operacionalización. Como puede verse, se tienen
varias alternativas de solución para cada Meta No
Funcional Transversal. Por ejemplo para la
Confidencialidad, en la Encriptación de Datos hay que
decidir entre una Encriptación Asimétrica o una
Simétrica. Varios factores pueden influir en este caso,
por ejemplo la Encriptación Simétrica es más eficiente
en tiempo de respuesta. Para determinar una solución
“aceptable” se pueden utilizar técnicas de evaluación
arquitectónicas, como por ejemplo las propuestas en
[39, 40].
Obsérvese en la Figura 10, que la correlación entre las
Operacionalizaciones Identificación Biométrica y
Autentificación son transitivas respecto a la Meta No
Funcional Autorización de Acceso, por tanto se dice que
la Identificación Biométrica es “AlgoPositivo” respecto
a la Confidencialidad.
Disciplina IV. Construcción Orientada a Aspectos (OA) de
la Arquitectura Inicial.
1. Elegir la Operacionalización de mayor relevancia desde
el punto de vista arquitectónico, para cada Meta No
Funcional Transversal, en orden de prioridad. En vista
que la Confidencialidad de las transacciones implica
que toda operación en la Gestión de Trámites de
Identificación debe pasar por un proceso de
Autorización, la operacionalización de mayor
relevancia según el caso de estudio es la Autorización
de Acceso. Nótese en la Figura 10 las contribuciones de
las operacionalizaciones Encriptación de Data es
AlgoPositivo ( ), Back-up de Data es Ayuda ( ) y
Autorización de Acceso es Realiza ( ) respecto a la
Meta No Funcional Transversal Confidencialidad
(Tabla 12).
Tabla 12. Valoración de las operacionalizaciones
Meta No Funcional Transversal Encriptación de Autorización de Back-up
/Operacionalización Data Acceso de Data
Confidencialidad
Es notorio señalar además que las
Operacionalizaciones Autentificación y Limitación de
Tiempo de Conexión se derivan de Autorización de
Acceso. Finalmente, la operacionalización SSL (Secure
Sockets Layer) es AlgoPositivo ( ) para la
operacionalización Encriptación de Data.

Tabla 11. Contribuciones y Correlaciones de las operacionalizaciones para la Meta No Funcional Transversal principal Seguridad
Metas Transversales refinadas
Operacionaliza-ciones
Integridad Confidencialidad No Repudio Auditable Autenticidad
Acceso Limitado AlgoPositivo
Firewall Ayuda
Encriptación de Data AlgoPositivo AlgoPositivo
Autorización de Acceso AlgoPositivo Ayuda
Back-up de Data AlgoPositivo AlgoPositivo
Certificado Digital Ayuda
Bitácora de Transacciones Ayuda AlgoPositivo
Bitácora de Eventos Ayuda
Identificación Biométrica AlgoPositivo AlgoPositivo
Firma Electrónica Ayuda

32
2. Describir los mecanismos/soluciones arquitectónicas de forma centralizada, lo que se representa en la
asociados a la operacionalización seleccionada. La Figura 12.
operacionalización Autorización de Acceso, que
proviene del refinamiento de la meta no funcional
transversal prioritaria Seguridad, según la Tabla 11
puede ser “implementada” por cualquiera de los tres
patrones de diseño que se describen a continuación; el
proceso de evaluación consiste en decidir cuál de estos
patrones es el más adecuado, en respuesta a los
requisitos de calidad exigidos por Gestión de Trámites
de Identificación.
Figura 12. Estructura del patrón arquitectónico MAC expresada
en componentes UML
Patrón Discretionary Access Control (DAC) [26]:
Representa el control de acceso basado en identidades
Patrón Role-Based Access Control RBAC [18]: Describe
de usuarios y la propiedad de objetos. El patrón
cómo asignar derechos a usuarios sobre la base de sus
permite que un propietario de un objeto pueda
funciones o tareas, en un ambiente en el que se exige
conceder permiso a otro usuario para acceder al
el control de acceso a los recursos informáticos y
objeto, y el usuario que tenga permiso lo puede
donde existe una gran cantidad de usuarios,
delegar una tercera persona, como se observa en la
información y gran variedad de recursos, como se
Figura 11.
observa en la Figura 13.

Figura 13. Estructura del patrón arquitectónico RBAC

expresada en componentes UML

Figura 11. Estructura del patrón arquitectónico DAC
Patrón Mandatory Access Control (MAC) [51]:
Gobierna el acceso en función del nivel de seguridad
de los sujetos (usuarios) y objetos (datos). El acceso a
un objeto sólo se concede si los niveles de seguridad
del sujeto y el objeto satisfacen ciertas restricciones.
Se utiliza cuando el ambiente es de varias capas y
cuando las políticas de seguridad deben ser definidas
3. Comparar los mecanismos/soluciones arquitectónicas
descritas. Se utiliza el modelo de calidad ISO/IEC
25010 [31] como una técnica, como siguiente:
Primero, se describen los atributos o propiedades de
calidad que caracterizan el mecanismo/solución
arquitectónica y realizar un análisis comparativo.

Tabla 13. Comparación de atributos y medidas para cada mecanismo arquitectónico [39]
Mecanismos o soluciones arquitectónicas
Sub-
Características Discretionary Access Mandatory Access Control Role-Based Access Comentarios
características
Control (DAC) (MAC) Control (RBAC)
Adecuación MAC y RBAC controlan el acceso a
Completitud No aplica Aplica Aplica
funcional través de Internet
Tiempo (User)+
Tiempo (User)+
Tiempo (Subject)+ Tiempo (Subject)+
Tiempo (Subject)+
Tiempo Tiempo (Role)+ El RBAC es mejor, menor tiempo de
Tiempo de Tiempo (ReferenceMonitor)+
(ReferenceMonitor)+ Tiempo (Right)+ respuesta, por tener menos
Respuesta Tiempo (SecurityLevel)+
Tiempo (Permission)+ Tiempo componentes
Eficiencia Tiempo (Operation)+
Tiempo(Operation)+ (ProtectionObject)
Tiempo (Object)
Tiempo (Object)
El DAC utiliza menos recursos; RBAC
Utilización de
Baja Media Alta utiliza más recursos, pero soporta
recursos
mayor volumen de usuarios
Ninguno de los patrones estudiados
Usabilidad No aplica No aplica No aplica No aplica
influye en la usabilidad
Alta (Existe un
Media (Existe un La confidencialidad en RBAC es alta
Baja (Los usuarios intermediario, se
intermediario, se requiere de y en MAC es media. Se requiere de
Confidencialidad auto-administran los requiere de la
la clasificación y mecanismos adicionales para la
permisos) asignación de funciones
Seguridad categorización de permisos) encriptación del Password.
o tareas)
Media (Existe un Alta (Existe un
Baja (Los usuario El RBAC es mejor que MAC en
Integridad intermediario en la concesiónintermediario en la
delegan los permisos) integridad.
de permisos) concesión de permisos)

33
 En la Tabla 13 se asignan valores de acuerdo a las
prioridades y una escala definida en correspondencia
a las propiedades de calidad de cada mecanismo. De
acuerdo a los resultados se realiza un análisis
argumentativo (Tabla 14), considerando “métricas
arquitecturales” de alto nivel de abstracción, a veces
cualitativas ya que estamos en proceso de diseño de la
arquitectura y el sistema no puede ejecutarse para
evaluar aspectos cuantitativos, como por ejemplo:
“¿Considera la presencia o no del Mecanismo?” o en
caso de la eficiencia, “Se hace el cálculo de la suma de
los tiempos de respuestas de cada componente y
conector directamente sobre la configuración del
patrón” [39].
Tabla 14. Análisis argumentativo de mecanismos/soluciones
arquitectónicas
Característica Argumentaciones
Adecuación El MAC y RBAC son iguales respecto a facilitar el
funcional acceso a internet.
El RBAC es mejor en tiempo de respuesta y en
uso de recursos porque si bien utiliza más
Eficiencia
recursos, soporta mayor volumen de usuarios; si
la escalabilidad es importante, RBAC es mejor.
El RBAC es mejor que MAC con respecto a la
Seguridad
confidencialidad e integridad.
Luego, se selecciona un mecanismo/solución
arquitectónica, entre los candidatos evaluados: De la
evaluación presentada en la Tabla 13 y del análisis de
las argumentaciones en la Tabla 14, se desprende que
RBAC y MAC compiten en cuanto a la Adecuación
Funcional. El RBAC es mejor que MAC con respecto a la
Seguridad (confidencialidad e integridad), Meta No
Funcional Transversal de máxima prioridad para el
sistema de Gestión de Tramites de Identificación la cual
está asociada y por ende, satisface a la Meta Funcional
Control de acceso.
Por otra parte, en vista que se requiere además como
política general disminuir el tiempo de respuesta de
una solicitud, es decir, mejorar la eficiencia global de
Gestión de Tramites de Identificación, RBAC resulta
ganador en cuanto a Eficiencia; por lo tanto, se decide
seleccionar a RBAC como solución arquitectónica para
“implementar” la operacionalización Autorización de
Acceso y así encapsular como un componente
Figura 15. Arquitectura Inicial de Gestión de Trámites de Identificación con aspectos expresada en componentes UML [46],
utilizando Visual Paradigm for UML [57]
“aspecto” a la Confidencialidad, sub-característica de la
Meta No Funcional Transversal Seguridad.
En la Figura 14 se muestra los detalles del patrón de
diseño RBAC, como un componente «Aspect» que
encapsula a la Confidencialidad; el cual después de un
proceso de evaluación, fue seleccionado para
satisfacer la Meta No Funcional Transversal Seguridad
y así asegurar la Meta Funcional Control de Acceso: El
proceso completo de evaluación no se detalla aquí por
razones de espacio.
Figura 14. Patrón RBAC como mecanismo que encapsula el
Aspecto Seguridad expresado en componentes UML [46],
utilizando Visual Paradigm for UML [57]
En la Figura 15, se presenta la arquitectura inicial de
Gestión de Trámites de Identificación con aspectos.
Las Metas Funcionales y las Metas No Funcionales
Transversales del Modelo de Metas corresponden a
Compontes Funcionales y Componentes Aspectos,
consecutivamente.
6. CONCLUSIONES
Se ha definido un proceso de diseño de una arquitectura
inicial para el tratamiento temprano de metas no
funcionales que entrecruzan varias metas, a partir de un
Modelo de Negocio. Considerando este primer nivel de
abstracción, el Modelo de Negocio en BPMN, es traducido
a un Modelo de Metas en GRL [43], como segundo nivel de
abstracción; el tratamiento de las Metas No Funcionales
Transversales, son refinadas en operacionalizaciones,
modeladas por el Softgoal Interdependency Graph y se
hacen corresponder con mecanismos/soluciones
arquitectónicas [22], en un modelo arquitectónico
expresado en UML 2.0. Entre estas soluciones se
selecciona una opción adecuada entre varias alternativas,
para la obtención de una arquitectura inicial que
considera aspectos [24], en su último nivel de abstracción.
34
El uso del modelo de calidad para la especificación de
requisitos no funcionales ha sido tema central de interés
de nuestro grupo de investigación, desde hace unos diez
años. En particular, nuestro proceso integra las técnicas
de evaluación de arquitecturas presentadas en [39, 40],
que comparan arquitecturas de software, definiendo un
marco conceptual de referencia con métricas generales de
alto nivel, utilizando el modelo de calidad ISO/IEC 9126-1
(ahora ISO/IEC 25010) para la caracterización del
dominio y así seleccionar una arquitectura inicial del
sistema de software. Así mismo, consideran la selección
de una arquitectura base a partir de tablas de
especificación de atributos de calidad para cada
mecanismo arquitectónico y sus medidas respectivas,
utilizando también el mencionado modelo de calidad.
Por otra parte, en [42], se presenta un núcleo notacional
para AOSD en UML para el tratamiento temprano de
aspectos (en las disciplinas de requisitos, análisis y
diseño), construido mediante diferentes elementos de
modelado que se encuentran en la literatura y diferentes
extensiones de UML. En [43], se muestran pasos y reglas
para la correspondencia semántica entre los lenguajes
BPMN y GRL, definiendo tareas no funcionales en el
Modelo de Negocio en BPMN, haciéndolas corresponder
con metas no funcionales en el Modelo de Metas en GRL.
Luego, los mismos autores en [22], proponen un proceso
que integra la orientación a metas y la orientación a
aspectos, para el tratamiento temprano de las metas no
funcionales transversales. Un punto relevante de este
enfoque, es por una parte, la especificación de los
requisitos de calidad asociados a las metas a través de un
modelo de calidad [31]; por otra parte, la asociación de
mecanismos/soluciones arquitectónicas o patrones [6] a
las operacionalizaciones derivadas del proceso, con los
requisitos de calidad exigidos; esto facilitó en [24] la
resolución de conflictos y la toma de decisiones en la
evaluación de diferentes alternativas de solución a nivel
de mecanismos arquitectónicos, con bases a la
satisfacción de las metas no funcionales transversales, en
orden de importancia.
El presente trabajo integra estos resultados y propone el
proceso DAOMAC, qué inicia con la descripción del
proceso de negocio expresado como modelo de negocio
en BPMN, hasta llegar al diseño de una arquitectura
inicial expresada en componentes UML con aspectos.
En la actualidad se investiga en el uso del modelo de
negocio para la automatización directa de los procesos de
negocio, mediante servicios; utilizando la arquitectura
basada en servicios SOA (Service Oriented Architecture)
[59, 64], enfoque en el cual la especificación temprana de
los requisitos de calidad, cobra mucha importancia. El
modelo de calidad ISO/IEC 25010 [31], es una
herramienta útil que puede ser utilizada también, en el
contexto de la automatización de procesos de negocio,
para facilitar la selección de servicios basada en Metas No
Funcionales. Es necesario resaltar como el modelo de
calidad ISO/IEC 25010 ha permitido la caracterización del
dominio, en cuanto a la especificación de los requisitos de
calidad, ha facilitado el refinamiento del Softgoal
Interdependency Graph y en consecuencia, la selección de
la arquitectura inicial; así como también, la trazabilidad
entre elementos no funcionales.
Nuestro aporte principal es haber integrado técnicas
actuales del modelado de negocio, orientación a metas,
aspectos y especificación de la calidad de producto, en
base a las directrices estipuladas en [23]. DAOMAC puede
ser integrado a las disciplinas de Ingeniería de Requisitos
o Ingeniería del Dominio, en contextos de Ingeniería de
Modelos o Líneas de Productos de Software. Así mismo,
está prevista la construcción de una herramienta de
soporte al proceso propuesto.
7. AGRADECIMIENTO
Los proyectos PEII-Fonacit DISofT No 2011001343,
Venezuela, DesCCaP No PG-03-8014-2011 del Consejo de
Desarrollo Científico y Humanístico (CDCH) y el
Postgrado en Ciencias de la Computación, Facultad de
Ciencias, Universidad Central de Venezuela, han prestado
ayuda financiera parcial a este trabajo. Así mismo,
queremos agradecer muy especialmente a los árbitros por
la cuidadosa revisión del documento y los valiosos
aportes realizados para mejorar el trabajo.
8. REFERENCIAS
[1] Amyot, D. et al. (2009). A Lightweight GRL Profile for i*
Modeling. ER Workshops 2009, pp. 254-264. Gramado,
Brazil.
[2] BizAgi (2012). BPM BizAgi v2.4. Available in:
http://www.bizagi.com/.
[3] Crusson, T. (2006). Business Process Modeling Language.
GLiNTECH.
[4] Brandozzi, M. (2001). From goal oriented requirements
specifications to architectural prescriptions. University of
Texas at Austin.
[5] Burlton, R. (2001). Effective Business Change through
Process Management: Strategies and Architectures for
Integrated Change. Process Renewal Group.
[6] Buschmann, F. et al. (2001). Pattern-Oriented Software
Architecture: A System of Pattern. Addison-Wesley.
[7] Castro, J. et al. (2011). Changing attitudes towards the
generation of architectural models. Journal of Systems and
Software, 85(3), pp. 463-479.
[8] Chung, L. (1991). Representation and Utilization of Non-
Functional Requirements for Information System Design. In
Proc. 3rd Int. Conf. Advanced Information Systems Eng.
(CAiSE), pp. 5-30. Trondheim, Norway.
[9] Chung, L.; Nixon, B. & Yu, E. (1995). Using Non-Functional
Requirements to Systematically Select Among Alternatives
in Architectural Design. Proc. of 1st Int. Workshop on
architectures for Software System, pp. 31-32. Washington.
[10] Chung, L. & Yu, E. (1998). Achieving System-Wide
Architectural Qualities. Proc. of OMG-DARPA: MCC
Workshop on Compositional Software Architectures.
Monterey, California.
[11] Chung, L.; Gross, D. & Yu, E. (1999). Architectural design to
meet stakeholder requirements. In Donohue, P. (Ed.),
Software architecture. Kluwer Academic Publishers.
[12] Chung, L. et al. (1999). Non-Functional Requirements in
Software Engineering. International Series in Software
Engineering, 5. Hardcover.
[13] Chung, L.; Cooper, K. & Yi, A. (2002). Developing Adaptable
Software Architectures Using Design Patterns: a NFR
Approach. Journal Computer Standards & Interfaces -
35
 Special issue: Adaptable software architectures, 25(3), pp.
253-260.
[14] Christopher, A. et al. (1977). A Pattern Language: Towns,
Buildings, Construction. Oxford University Press.
[15] Clements, P.; Kazman, R. & Klein, M. (2002). Evaluating
Software Architectures: Methods and Case Studies.
Addison-Wesley.
[16] Bluter, A. (2009). Business Process Management Essentials.
Glintech.
[17] Dermeval, D. et al. (2012). STREAM-ADD – Supporting the
Documentation of Architectural Design Decisions in an
Architecture Derivation Process. Proc. 36th International
Conference on Computer Software and Applications, pp. 16-
20.
[18] Ferraiolo, D. et al. (2001) Proposed NIST Standard for Role-
Based Access Control. ACM Transactions on Information
and Systems Security, 4(3), pp. 224-274.
[19] Filman, R. et al. (2005). Aspect-Oriented Software
Development. Addison Wesley.
[20] Garlan, D. & Shaw, M. (1996). Software Architecture:
Perspectives on an Emerging Discipline. Prentice Hall.
[21] Ghezzi, C.; Jazayeri, M. & Mandrioli, D. (2002).
Fundamentals of Software Engineering. Prentice Hall.
[22] Guzmán, J.C.; Losavio, F. & Matteo A. (2012). Metas No
Funcionales Transversales en GRL considerando
Estándares de Calidad del Software. 1er. Congreso
Venezolano de Tecnología e Innovación (ONCTI). Caracas,
Venezuela.
[23] Guzmán, J.C.; Losavio, F. & Matteo, A. (2013). Comparación
de métodos para el diseño arquitectónico del software que
consideran metas, aspectos y estándares de calidad.
Enl@ce: Revista Venezolana de Información, Tecnología y
Conocimiento, 10(2), pp. 11-27.
[24] Guzmán, J.C.; Losavio, F. & Matteo, A. (2013). Evaluación
arquitectónica con estándares de calidad de una
arquitectura inicial obtenida a partir de metas y aspectos.
2do. Congreso Venezolano de Tecnología e Innovación
(ONCTI), Caracas, Venezuela.
[25] Hammer, M. & Champy, J. (1993). Reengineering the
Corporation: A Manifesto for Business Revolution. Harper
Collins.
[26] Harrison, M.; Ruzzo, W. & Ullman, J. (1976). Protection in
Operating Systems. Communications of the ACM, 19(8), pp.
461-471.
[27] Hepp, M. & Roman, D. (2007). An Ontology Framework for
Semantic Business Process Management. Proc. of the 8th
international conference Wirtschafts informatik, pp. 1-18.
February 28 - March 2, 2007, Karlsruhe, Germany.
[28] Horovitz, J. & Jurigus, M. (1994). La satisfacción total del
cliente interno. McGraw Hill.
[29] IEEE. (2000). IEEE Std 1471-2000: Practice for
Architectural Description of Software-Intensive Systems.
[30] ITU-T. (2012). ITU-T Z.151: User Requirements Notation
(URN)-Language Definition, Recommendation.
[31] Mlitat, M. & Dai, Z. (2011). ISO/IEC 25010: Software
engineering-Software product Quality Requirements and
Evaluation (SQuaRE), Quality models.
[32] Kitchenham, B. (1997). DESMET: A Method for Evaluating
Software Engineering Methods and Tools. Computing &
Control Engineering Journal, 8(3), pp. 120-126.
[33] Kiczales, G. et al. (1997). Aspect-oriented programming.
Proceedings of the ECOOP, pp. 1-25.
[34] Krutchen, P. (2000). The Rational Unified Process: An
Introduction. Addison Wesley.
[35] Lapouchnian, A. (2005). Goal-Oriented Requirements
Engineering: An Overview of the Current Research.
University of Toronto.
[36] Lee, M. (2005). StarUML - The Open Source UML/MDA
Platform. http://staruml.sourceforge.net/en/.
[37] León, O. & Asato, J. (2009). La Importancia del Modelado de
Procesos de Negocio como Herramienta para la Mejora e
Innovación. Revista Panorama Administrativo, 7(4), pp. 6-7.
[38] Liu, L. & Yu, E. (2004). Designing information systems in
social context: a goal and scenario modeling approach.
Information Systems, 29(2), pp. 187-203.
[39] Losavio, F. et al. (2003). Quality Characteristics for Software
Architecture. Journal of Object Technology, 2(2), pp. 133-
150.
[40] Losavio, F. et al. (2004). ISO quality standards for
measuring architectures. Journal of Systems and Software,
72(2), pp. 209-223.
[41] Losavio, F. & Guillén, Ch. (2006). Marco conceptual para un
diseño arquitectónico basado en aspectos de calidad.
Revista Universitaria Sapiens, 7(2), pp. 119-138.
[42] Losavio, F.; Matteo, A. & Morantes, P. (2009). UML
Extensions for Aspect Oriented Software Development.
Journal of Object Technology, 8(5), pp. 85-104.
[43] Losavio, F.; Guzmán, J.C. & Matteo, A. (2011).
Correspondencia Semántica entre los lenguajes BPMN y
GRL. Revista Venezolana de Información, Tecnología y
Conocimiento Enl@ace, 8(1), pp. 11-29.
[44] Moreira, A. & Brito, I. (2004). Integrating the NFR
framework in a RE model. Proc. Early Aspects 2004: AORE
and Architecture Design. Workshop, March 22, Lancaster,
UK.
[45] Mussbacher, G. (2012). jUCMNav v5.2. http://jucmnav.
softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHo
me.
[46] OMG. (2005). Unified Modeling Language™ (UML®) 2.0.
http://www.omg.org/spec/UML/.
[47] OMG. (2008). Software Process Engineering Metamodel
(SPEM) 2.0. http://www.omg.org/spec/SPEM/2.0/PDF/.
[48] OMG. (2011). Business Process Model and Notation (BPMN)
2.0. http://www.omg.org/spec/BPMN/2.0/.
[49] Rashid, A.; Moreira, A. & Araujo, J. (2003). Modularization y
Composition of Aspectual Requirements. Proc. AOSD '03
Proceedings of the 2nd international conference on Aspect-
oriented software development.
[50] Rashid, A.; Royer, J.C. & Rummler, A. (2011). Aspect-
Oriented, Model-Driven Software Product Lines: The
AMPLE Way. Cambridge University Press.
[51] Sandhu, R. & Samarati, P. (1994). Access Control: Principles
and Practice. IEEE Communications, 32(9), pp. 40-48.
[52] Scholten, F. (2007). The concern-oriented software
architecture analysis method. Computer Science, Electrical
Engineering, Mathematics and Computer Science.
University of Twente.
[53] Tekinerdogan, B. (2004). ASAAM: Aspectual Software
Architecture Analysis Method. WICSA '04 Proceedings of
the Fourth Working IEEE/IFIP Conference on Software
Architecture, p. 1-10.
[54] Vanderveken, D. et al. (2005). Deriving Architectural
Descriptions from Goal-Oriented Requirements Models.
Proc. ICSE 2006, May 20-28, Shanghai, China.
[55] Lamsweerde, A. (2001). Goal-Oriented Requirements
Engineering: A Guided Tour. Proc. RE’01: 5th Intl. Symp.
Req. Eng., Aug., pp. 249-263, Toronto, August 2001.
[56] Lamsweerde, A. (2003). From system goals to software
architecture. School on Formal Methods (SFM 2003), pp.
25-43, Bartinoro, Italy.
[57] VPI. (2012). Visual Paradigm for UML v.10.1.
http://www.visual-paradigm.com/download/vpuml.jsp.
[58] White, S. (2004). Business Process Modeling Notation
(BPMN) 1.0. Business Process Management Initiative.
[59] World Wide Web Consortium. Web Services Architecture
Requirements. W3C Working Group Note 11 February
(2004). Copyright © 2004 W3C® (MIT, ERCIM, Keio).
http://www.w3.org/TR/wsa-reqs.
36
[60] Yu, E. & Mylopoulos, J. (1993). An Actor Dependency Model
of Organization Work-With Application to Business Process
Reengineering. Proc. Conf. on Organizational Computing
Systems (COOCS ‘93), pp. 258-268. Nov. 1-4, Milpitas,
California.
[61] Yu, E. (1997). Towards Modelling and Reasoning Support
for Early-Phase Requirements Engineering. Proc. of the 3rd
IEEE Int. Symp. on Requirements Engineering, pp. 226-235.
[62] Yu, E. (1997). Why Agent-Oriented Requirements
Engineering. Proc. 3rd Int. Workshop on Requirements
Engineering: Foundations of Software Quality REFSQ’97,
pp. 171-183. Barcelona, Spain.
[63] Yu, E., Strohmaier, M., & Deng, X. (2006). Exploring
Intentional Modeling and Analysis for Enterprise
Architecture. Proc. of the EDOC 2006 Conference Workshop
on Trends in Enterprise Architecture Research. Hong Kong.
[64] Yu, E. & Lo, A. (2007). From Business Models to Service-
Oriented Design: A Reference Catalog Approach. Proc. 26th
International Conference on Conceptual Modeling, pp. 87-
101. Auckland, New Zealand, November 5-9.
37
Copyright of Revista Antioqueña de las Ciencias Computacionales is the property of Instituto
Antioqueno de Investigacion and its content may not be copied or emailed to multiple sites or
posted to a listserv without the copyright holder's express written permission. However, users
may print, download, or email articles for individual use.