Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
www.fundacioniai.org/raccis
raccis@fundacioniai.org
Un estilo arquitectónico, define una familia de sistemas en Adecuación funcional: Completitud, Correctitud o
términos de patrones que especifican un vocabulario de precisión y Ser apropiado.
los componentes y conectores usados como instancia de Eficiencia en rendimiento: Comportamiento en tiempo,
ese estilo, adyacente a un conjunto de restricciones de Utilización de recursos y Capacidad.
23
Compatibilidad: Co-exigencia e Interoperabilidad. diseño de la arquitectura del software. Mencionaremos
Usabilidad: Capacidad de ser aprendido, Ser aquí los más conocidos y utilizados en la práctica o
reconocido como apropiado, Capacidad de ser directamente involucrados con el presente trabajo. En [4]
operado, Protección de errores del usuario, Estética de se presenta un enfoque de requisitos orientado a metas
la interfaz usuario o apariencia y Capacidad de ser de de alto nivel de abstracción, y también expresados en
fácil acceso. KAOS, el cual facilita la reutilización y diseños más
Confiabilidad: Madurez, Disponibilidad, Tolerancia a creativos. Utiliza también configuraciones arquitectónicas
fallas y Capacidad de recuperarse o recuperabilidad. para efectuar el paso de los requisitos a la arquitectura de
Seguridad: Confidencialidad, Integridad, No repudio, software. Las configuraciones proporcionan los detalles
Auditable y Autenticidad. arquitectónicos a los diseñadores, permitiendo la
Mantenibilidad: Modularidad, Reutilización, Capacidad correspondencia de los requisitos de mayor
de ser analizado, Capacidad de ser modificado y transcendencia; así como la mejor comprensión de la
Capacidad de ser probado. arquitectura del sistema de software candidata.
Portabilidad: Adaptabilidad, Capacidad de ser
instalado y Capacidad de ser reemplazado. En [13] se presenta un marco conceptual, que sigue la
orientación a metas y que tiene por objetivo, apoyar el
2.3 Orientación a Aspectos diseño de arquitecturas de software adaptables,
En particular, este trabajo considera el enfoque de utilizando patrones de diseño. Está centrado en el
Desarrollo de Software Orientado a Aspectos, conocido en Framework NFR, el cual trata los requisitos no
la literatura como AOSD (Aspect-Oriented Software funcionales, como “Softgoal” a ser satisfechos. En [38] se
Development) [33], para el tratamiento temprano de presenta un enfoque de diseño arquitectónico
requisitos o aspectos de interés, incumbencias o fundamentado en el enfoque GORE, para la derivación de
“concerns” de un sistema de software [21]. Las arquitecturas de software a partir de un modelo de metas
incumbencias que entrecruzan diferentes módulos de un expresado en GRL, que incorpora metas tanto del negocio
sistema, se denominan incumbencias transversales o como del sistema utilizando escenarios expresados en
“crosscutting concerns” y son candidatas a ser tratadas mapas de casos de uso o Use Case Maps, usados para
como aspectos en la etapa de implementación y/o describir procesos de negocios definidos en GRL. Los
construcción del software. Un aspecto, es la estructura requisitos funcionales y no funcionales se especifican
que encapsula una incumbencia transversal [33] y su como metas (funcionales o no) primero en una notación
origen es a nivel de implementación; sin embargo, de gráfica no estándar de árbol; luego, son transformados a
acuerdo a AOSD, debe ser considerado también en las escenarios orientados al diseño, que se ocupan del
etapas tempranas del desarrollo de software, para refinamiento de los requisitos del sistema.
facilitar así la evolución del sistema, especialmente en las
etapas de modelado del negocio, ingeniería de requisitos En [53] se presenta el enfoque ASAAM para la evaluación
y diseño arquitectónico. de aspectos a nivel de diseño arquitectónico, que admite
la identificación y especificación explícita de
Esta investigación pretende generar aportes hacia la incumbencias transversales, en las etapas tempranas del
solución de los problemas planteados, particularmente en ciclo de vida de desarrollo de software. Así mismo, en [54]
cuanto a la correspondencia o trazabilidad entre el se presenta un enfoque formal basado en el enfoque de
modelo de negocio y el modelo de la arquitectura del orientación a metas, para la derivación de arquitecturas
software, conforme a los requisitos no funcionales que de software por medio de reglas de transformación,
intervienen y que dirigen la construcción de la aplicadas al modelo de requisitos. Los lenguajes de origen
arquitectura. Un elemento esencial que caracteriza y destino, son el lenguaje de alto nivel de requisitos KAOS
nuestra proposición, consiste en considerar los aspectos y el ADL (Architecture Description Language) Wright,
no funcionales desde el modelo de negocio; se inspira en respectivamente. En [52] se plantea un enfoque iterativo
uno de los principales trabajos de Axel Van Lamswerdee de evaluación y transformación de arquitecturas de
[56], el cual solo aborda el nivel más abstracto del sistema software, el cual utiliza y extiende de diversos enfoques
de software, pero no el modelo de negocio. Se considera la existentes, para crear un método para transformar
trazabilidad entre los modelos involucrados y estándares sistemáticamente arquitecturas de software, a través de
actuales, en cuanto a lenguajes de modelado y reglas.
especificación de requisitos de calidad. Se define para ello
un proceso completo para el diseño de una arquitectura En [50] se aborda el tema del diseño de Arquitecturas de
inicial, el cual hemos denominado DAOMAC, inspirado en Líneas de Productos de Software o Software Product Line
las directrices plantadas en [23], centrado en la Architecture (PLA) basado en incumbencias. Es un
especificación de los requisitos de calidad por el modelo “toolkit” de técnicas y explota la sinergia entre la
de calidad de producto de software del estándar ISO/IEC orientación a aspectos y MDE (Model Driven Engineering),
25010 [31] y en las técnicas señaladas de modelado del hacia un tratamiento sistemático de la variabilidad de los
negocio, GORE y AOSD. productos en la línea de productos. Utiliza la herramienta
DiVA (Dynamic Variability in Adaptive System), tanto para
3. TRABAJOS RELACIONADOS el manejo de la variabilidad dinámica como para
Numerosos son los trabajos que tratan el tema de la especificar requisitos; utiliza la orientación a metas para
integración de la orientación a metas y aspectos, en el identificar la intencionalidad de los requisitos en general.
24
Finalmente, los requisitos de calidad se especifican como negocio al modelo de metas, ni la especificación de
softgoals. Recientemente, en [7] se plantea un enfoque requisitos de calidad por estándares.
sistemático de diseño arquitectónico orientado a metas,
basado en el enfoque de MDE y por ende, en 4. EL PROCESO DE DISEÑO ARQUITECTÓNICO
transformación de modelos para la generación de ORIENTADO A METAS, ASPECTOS Y CALIDAD
arquitecturas de software, a partir de los modelos de i*: A continuación se describe el proceso DAOMAC, a través
incluye reglas de transformación para derivar de sus disciplinas y los modelos involucrados.
especificaciones arquitectónicas a partir de metas del
negocio y del sistema. Los lenguajes de origen y destino 4.1 Modelos que intervienen el proceso DAOMAC
son, respectivamente, el lenguaje de modelado i* y el ADL En referencia a los modelos involucrados (Figura 1), el
Acme. Los requisitos de calidad se especifican como proceso DAOMAC propuesto (Figura 2) considera los
softgoals y no se utilizan estándares para esta siguientes: el modelo de negocio expresado en BPMN, con
especificación. la identificación de vínculos entre tareas funcionales y no
funcionales o «MNF» [43]; el modelo de metas expresado
Finalmente, en [17] se presenta un enfoque de diseño en GRL para hacer la transición entre <<MNF>> del
arquitectónico orientado a metas, basado en modelo de negocio y los requisitos no funcionales o
transformaciones (refinamientos), denominado STREAM- softgoals del sistema de software de GORE y así
ADD, que extiende la versión clásica STREAM. Este identificar las metas no funcionales transversales y su
enfoque refina metas no funcionales del Modelo de refinamiento en el SIG como operacionalizaciones
Razonamiento Estratégico de i* en mecanismos o concretas [22]; éstas son asociadas a
soluciones arquitectónicas, utilizando reglas de mecanismos/soluciones arquitectónicas, las cuales son
transformación. Estos dos últimos enfoques, que son los descritas y evaluadas de acuerdo a sus atributos o
más similares al nuestro, en cuanto a la transformación de propiedades de calidad, para la selección de una opción
metas en componentes arquitectónicos, refinan metas no adecuada entre varias alternativas. Se obtiene finalmente
funcionales del Modelo de Metas de i* en mecanismos o el modelo de una arquitectura inicial del sistema [23],
soluciones arquitecturales, utilizando reglas de expresada como vista lógica en UML 2.0 [46], en la cual se
transformación; sin embargo, no tratan metas no identifican los componentes orientados a aspectos
funcionales transversales, ni el paso del modelo del (estereotipados en UML como «Aspect») y los
componentes funcionales.
25
Disciplina I. Construcción de MN en BPMN. Disciplina IV. Construcción OA de la Arquitectura Inicial.
26
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].
27
Figura 8. Modelo de Negocio de Gestión de Trámites de Identificación expresado en BPMN [48], utilizando BPM BizAgi [2]
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.
28
Figura 9. Modelo de Metas de Gestión de Trámites de Identificación expresado en GRL [30], utilizando jUCMNav [45]
4. En base a los elementos de los Pools y Lanes en BPMN, 2. Especificar las Metas Funcionales y No Funcionales.
establecer vínculos en GRL. En principio, se definieron Para cada Meta Funcional, se especifican las metas
los Vínculos de Dependencia implícitos entre los requeridas y las metas que la requieren, además de
diferentes elementos de GRL, tales como tareas, información general sobre la meta. En este caso la
recursos, metas funcionales y no funcionales en base a Meta Funcional Control de Acceso (Tabla 2) requiere
la regla 10 (Figura 9). Después, se generaron los las Metas Funcionales Realizar y Revisar Solicitud y
vínculos medio-fin en GRL a partir de flujos de depende de la Meta No Funcional Seguridad. Es
secuencias explicitados en BPMN, con la aplicación de importante señalar aquí la “transitividad” entre las
la regla 9. Posteriormente, se identificaron los Vínculos metas: Control de Acceso es requerida por Revisar
de Correlación entre Metas No Funcionales Usabilidad, Solicitud y Realizar Solicitud, por lo tanto estas tres
Eficiencia, Precisión y Seguridad. Finalmente, se Metas Funcionales también dependen de la Meta No
establecieron las Contribuciones entre las Metas 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]
31
Se incorporan seguidamente las posibles decidir entre una Encriptación Asimétrica o una
Operacionalizaciones al Softgoal Interdependency Simétrica. Varios factores pueden influir en este caso,
Graph, las cuales se muestran en la tercera columna de por ejemplo la Encriptación Simétrica es más eficiente
la Tabla 9. Posteriormente, se soportan las decisiones en tiempo de respuesta. Para determinar una solución
de diseño con argumentaciones (Figura 10, Tabla 10). “aceptable” se pueden utilizar técnicas de evaluación
arquitectónicas, como por ejemplo las propuestas en
Tabla 10. Argumentaciones [39, 40].
Metas en Conflictos Argumentación
Obsérvese en la Figura 10, que la correlación entre las
La Seguridad es adversa a la Eficiencia del
Seguridad-Eficiencia
sistema.
Operacionalizaciones Identificación Biométrica y
Autentificación son transitivas respecto a la Meta No
La Seguridad depende de la Usabilidad del
sistema; la componente Interfaz Usuario que Funcional Autorización de Acceso, por tanto se dice que
requiere alta usabilidad, es la responsable de la la Identificación Biométrica es “AlgoPositivo” respecto
incorporación de mecanismos arquitectónicos, a la Confidencialidad.
Seguridad-Usabilidad por ejemplo para la encriptación y la
desencriptación de datos en transacciones
financieras; esto incide en el tiempo de Disciplina IV. Construcción Orientada a Aspectos (OA) de
respuesta del sistema (Eficiencia), y en la mayor la Arquitectura Inicial.
o menos satisfacción del usuario (Usabilidad).
1. Elegir la Operacionalización de mayor relevancia desde
Subsiguientemente, se establece el impacto de las el punto de vista arquitectónico, para cada Meta No
contribuciones entre Metas No Funcionales y Funcional Transversal, en orden de prioridad. En vista
operacionalizaciones (Figura 10, Tabla 11). Las que la Confidencialidad de las transacciones implica
contribuciones pueden ser establecidas que toda operación en la Gestión de Trámites de
cuantitativamente por el Ingeniero de Metas o Identificación debe pasar por un proceso de
Arquitecto, asignando un porcentaje que corresponde Autorización, la operacionalización de mayor
al peso de la contribución entre Metas No Funcionales relevancia según el caso de estudio es la Autorización
o hacia una Operacionalización. de Acceso. Nótese en la Figura 10 las contribuciones de
las operacionalizaciones Encriptación de Data es
Así mismo, se pueden expresar cualitativamente como AlgoPositivo ( ), Back-up de Data es Ayuda ( ) y
tipos de contribuciones, por ejemplo de ruptura
(“Break”), como en el caso de la Eficiencia, que impide Autorización de Acceso es Realiza ( ) respecto a la
el cumplimiento de la Meta No Funcional Seguridad o Meta No Funcional Transversal Confidencialidad
de la Operacionalización Autentificación que ayuda (Tabla 12).
positivamente (“Ayuda”) al cumplimiento de la Meta
Tabla 12. Valoración de las operacionalizaciones
No Funcional Integridad. Los impactos cualitativos de
Meta No Funcional Transversal Encriptación de Autorización de Back-up
las contribuciones se muestran en la Tabla 11 y en el /Operacionalización Data Acceso de Data
SIG de la Figura 10. Finalmente, se incorporan los Confidencialidad
mecanismos y/o soluciones arquitectónicas a las
operacionalizaciones (Tabla 9).
Es notorio señalar además que las
Operacionalizaciones Autentificación y Limitación de
Para cada operacionalización, en la cuarta columna de
Tiempo de Conexión se derivan de Autorización de
la Tabla 9, se incorporan aquellas soluciones
Acceso. Finalmente, la operacionalización SSL (Secure
arquitectónicas que puedan resolver cada
operacionalización. Como puede verse, se tienen Sockets Layer) es AlgoPositivo ( ) para la
varias alternativas de solución para cada Meta No operacionalización Encriptación de Data.
Funcional Transversal. Por ejemplo para la
Confidencialidad, en la Encriptación de Datos hay que
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 11. Estructura del patrón arquitectónico DAC 3. Comparar los mecanismos/soluciones arquitectónicas
descritas. Se utiliza el modelo de calidad ISO/IEC
Patrón Mandatory Access Control (MAC) [51]: 25010 [31] como una técnica, como siguiente:
Gobierna el acceso en función del nivel de seguridad Primero, se describen los atributos o propiedades de
de los sujetos (usuarios) y objetos (datos). El acceso a calidad que caracterizan el mecanismo/solución
un objeto sólo se concede si los niveles de seguridad arquitectónica y realizar un análisis comparativo.
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
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 “aspecto” a la Confidencialidad, sub-característica de la
prioridades y una escala definida en correspondencia Meta No Funcional Transversal Seguridad.
a las propiedades de calidad de cada mecanismo. De
acuerdo a los resultados se realiza un análisis En la Figura 14 se muestra los detalles del patrón de
argumentativo (Tabla 14), considerando “métricas diseño RBAC, como un componente «Aspect» que
arquitecturales” de alto nivel de abstracción, a veces encapsula a la Confidencialidad; el cual después de un
cualitativas ya que estamos en proceso de diseño de la proceso de evaluación, fue seleccionado para
arquitectura y el sistema no puede ejecutarse para satisfacer la Meta No Funcional Transversal Seguridad
evaluar aspectos cuantitativos, como por ejemplo: y así asegurar la Meta Funcional Control de Acceso: El
“¿Considera la presencia o no del Mecanismo?” o en proceso completo de evaluación no se detalla aquí por
caso de la eficiencia, “Se hace el cálculo de la suma de razones de espacio.
los tiempos de respuestas de cada componente y
conector directamente sobre la configuración del
patrón” [39].
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]
34
El uso del modelo de calidad para la especificación de Interdependency Graph y en consecuencia, la selección de
requisitos no funcionales ha sido tema central de interés la arquitectura inicial; así como también, la trazabilidad
de nuestro grupo de investigación, desde hace unos diez entre elementos no funcionales.
años. En particular, nuestro proceso integra las técnicas
de evaluación de arquitecturas presentadas en [39, 40], Nuestro aporte principal es haber integrado técnicas
que comparan arquitecturas de software, definiendo un actuales del modelado de negocio, orientación a metas,
marco conceptual de referencia con métricas generales de aspectos y especificación de la calidad de producto, en
alto nivel, utilizando el modelo de calidad ISO/IEC 9126-1 base a las directrices estipuladas en [23]. DAOMAC puede
(ahora ISO/IEC 25010) para la caracterización del ser integrado a las disciplinas de Ingeniería de Requisitos
dominio y así seleccionar una arquitectura inicial del o Ingeniería del Dominio, en contextos de Ingeniería de
sistema de software. Así mismo, consideran la selección Modelos o Líneas de Productos de Software. Así mismo,
de una arquitectura base a partir de tablas de está prevista la construcción de una herramienta de
especificación de atributos de calidad para cada soporte al proceso propuesto.
mecanismo arquitectónico y sus medidas respectivas,
utilizando también el mencionado modelo de calidad. 7. AGRADECIMIENTO
Los proyectos PEII-Fonacit DISofT No 2011001343,
Por otra parte, en [42], se presenta un núcleo notacional Venezuela, DesCCaP No PG-03-8014-2011 del Consejo de
para AOSD en UML para el tratamiento temprano de Desarrollo Científico y Humanístico (CDCH) y el
aspectos (en las disciplinas de requisitos, análisis y Postgrado en Ciencias de la Computación, Facultad de
diseño), construido mediante diferentes elementos de Ciencias, Universidad Central de Venezuela, han prestado
modelado que se encuentran en la literatura y diferentes ayuda financiera parcial a este trabajo. Así mismo,
extensiones de UML. En [43], se muestran pasos y reglas queremos agradecer muy especialmente a los árbitros por
para la correspondencia semántica entre los lenguajes la cuidadosa revisión del documento y los valiosos
BPMN y GRL, definiendo tareas no funcionales en el aportes realizados para mejorar el trabajo.
Modelo de Negocio en BPMN, haciéndolas corresponder
con metas no funcionales en el Modelo de Metas en GRL. 8. REFERENCIAS
Luego, los mismos autores en [22], proponen un proceso
que integra la orientación a metas y la orientación a [1] Amyot, D. et al. (2009). A Lightweight GRL Profile for i*
aspectos, para el tratamiento temprano de las metas no Modeling. ER Workshops 2009, pp. 254-264. Gramado,
Brazil.
funcionales transversales. Un punto relevante de este
[2] BizAgi (2012). BPM BizAgi v2.4. Available in:
enfoque, es por una parte, la especificación de los http://www.bizagi.com/.
requisitos de calidad asociados a las metas a través de un [3] Crusson, T. (2006). Business Process Modeling Language.
modelo de calidad [31]; por otra parte, la asociación de GLiNTECH.
mecanismos/soluciones arquitectónicas o patrones [6] a [4] Brandozzi, M. (2001). From goal oriented requirements
las operacionalizaciones derivadas del proceso, con los specifications to architectural prescriptions. University of
requisitos de calidad exigidos; esto facilitó en [24] la Texas at Austin.
resolución de conflictos y la toma de decisiones en la [5] Burlton, R. (2001). Effective Business Change through
evaluación de diferentes alternativas de solución a nivel Process Management: Strategies and Architectures for
Integrated Change. Process Renewal Group.
de mecanismos arquitectónicos, con bases a la
[6] Buschmann, F. et al. (2001). Pattern-Oriented Software
satisfacción de las metas no funcionales transversales, en Architecture: A System of Pattern. Addison-Wesley.
orden de importancia. [7] Castro, J. et al. (2011). Changing attitudes towards the
generation of architectural models. Journal of Systems and
El presente trabajo integra estos resultados y propone el Software, 85(3), pp. 463-479.
proceso DAOMAC, qué inicia con la descripción del [8] Chung, L. (1991). Representation and Utilization of Non-
proceso de negocio expresado como modelo de negocio Functional Requirements for Information System Design. In
en BPMN, hasta llegar al diseño de una arquitectura Proc. 3rd Int. Conf. Advanced Information Systems Eng.
inicial expresada en componentes UML con aspectos. (CAiSE), pp. 5-30. Trondheim, Norway.
[9] Chung, L.; Nixon, B. & Yu, E. (1995). Using Non-Functional
Requirements to Systematically Select Among Alternatives
En la actualidad se investiga en el uso del modelo de in Architectural Design. Proc. of 1st Int. Workshop on
negocio para la automatización directa de los procesos de architectures for Software System, pp. 31-32. Washington.
negocio, mediante servicios; utilizando la arquitectura [10] Chung, L. & Yu, E. (1998). Achieving System-Wide
basada en servicios SOA (Service Oriented Architecture) Architectural Qualities. Proc. of OMG-DARPA: MCC
[59, 64], enfoque en el cual la especificación temprana de Workshop on Compositional Software Architectures.
los requisitos de calidad, cobra mucha importancia. El Monterey, California.
modelo de calidad ISO/IEC 25010 [31], es una [11] Chung, L.; Gross, D. & Yu, E. (1999). Architectural design to
herramienta útil que puede ser utilizada también, en el meet stakeholder requirements. In Donohue, P. (Ed.),
Software architecture. Kluwer Academic Publishers.
contexto de la automatización de procesos de negocio,
[12] Chung, L. et al. (1999). Non-Functional Requirements in
para facilitar la selección de servicios basada en Metas No Software Engineering. International Series in Software
Funcionales. Es necesario resaltar como el modelo de Engineering, 5. Hardcover.
calidad ISO/IEC 25010 ha permitido la caracterización del [13] Chung, L.; Cooper, K. & Yi, A. (2002). Developing Adaptable
dominio, en cuanto a la especificación de los requisitos de Software Architectures Using Design Patterns: a NFR
calidad, ha facilitado el refinamiento del Softgoal Approach. Journal Computer Standards & Interfaces -
35
Special issue: Adaptable software architectures, 25(3), pp. [37] León, O. & Asato, J. (2009). La Importancia del Modelado de
253-260. Procesos de Negocio como Herramienta para la Mejora e
[14] Christopher, A. et al. (1977). A Pattern Language: Towns, Innovación. Revista Panorama Administrativo, 7(4), pp. 6-7.
Buildings, Construction. Oxford University Press. [38] Liu, L. & Yu, E. (2004). Designing information systems in
[15] Clements, P.; Kazman, R. & Klein, M. (2002). Evaluating social context: a goal and scenario modeling approach.
Software Architectures: Methods and Case Studies. Information Systems, 29(2), pp. 187-203.
Addison-Wesley. [39] Losavio, F. et al. (2003). Quality Characteristics for Software
[16] Bluter, A. (2009). Business Process Management Essentials. Architecture. Journal of Object Technology, 2(2), pp. 133-
Glintech. 150.
[17] Dermeval, D. et al. (2012). STREAM-ADD – Supporting the [40] Losavio, F. et al. (2004). ISO quality standards for
Documentation of Architectural Design Decisions in an measuring architectures. Journal of Systems and Software,
Architecture Derivation Process. Proc. 36th International 72(2), pp. 209-223.
Conference on Computer Software and Applications, pp. 16- [41] Losavio, F. & Guillén, Ch. (2006). Marco conceptual para un
20. diseño arquitectónico basado en aspectos de calidad.
[18] Ferraiolo, D. et al. (2001) Proposed NIST Standard for Role- Revista Universitaria Sapiens, 7(2), pp. 119-138.
Based Access Control. ACM Transactions on Information [42] Losavio, F.; Matteo, A. & Morantes, P. (2009). UML
and Systems Security, 4(3), pp. 224-274. Extensions for Aspect Oriented Software Development.
[19] Filman, R. et al. (2005). Aspect-Oriented Software Journal of Object Technology, 8(5), pp. 85-104.
Development. Addison Wesley. [43] Losavio, F.; Guzmán, J.C. & Matteo, A. (2011).
[20] Garlan, D. & Shaw, M. (1996). Software Architecture: Correspondencia Semántica entre los lenguajes BPMN y
Perspectives on an Emerging Discipline. Prentice Hall. GRL. Revista Venezolana de Información, Tecnología y
[21] Ghezzi, C.; Jazayeri, M. & Mandrioli, D. (2002). Conocimiento Enl@ace, 8(1), pp. 11-29.
Fundamentals of Software Engineering. Prentice Hall. [44] Moreira, A. & Brito, I. (2004). Integrating the NFR
[22] Guzmán, J.C.; Losavio, F. & Matteo A. (2012). Metas No framework in a RE model. Proc. Early Aspects 2004: AORE
Funcionales Transversales en GRL considerando and Architecture Design. Workshop, March 22, Lancaster,
Estándares de Calidad del Software. 1er. Congreso UK.
Venezolano de Tecnología e Innovación (ONCTI). Caracas, [45] Mussbacher, G. (2012). jUCMNav v5.2. http://jucmnav.
Venezuela. softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHo
[23] Guzmán, J.C.; Losavio, F. & Matteo, A. (2013). Comparación me.
de métodos para el diseño arquitectónico del software que [46] OMG. (2005). Unified Modeling Language™ (UML®) 2.0.
consideran metas, aspectos y estándares de calidad. http://www.omg.org/spec/UML/.
Enl@ce: Revista Venezolana de Información, Tecnología y [47] OMG. (2008). Software Process Engineering Metamodel
Conocimiento, 10(2), pp. 11-27. (SPEM) 2.0. http://www.omg.org/spec/SPEM/2.0/PDF/.
[24] Guzmán, J.C.; Losavio, F. & Matteo, A. (2013). Evaluación [48] OMG. (2011). Business Process Model and Notation (BPMN)
arquitectónica con estándares de calidad de una 2.0. http://www.omg.org/spec/BPMN/2.0/.
arquitectura inicial obtenida a partir de metas y aspectos. [49] Rashid, A.; Moreira, A. & Araujo, J. (2003). Modularization y
2do. Congreso Venezolano de Tecnología e Innovación Composition of Aspectual Requirements. Proc. AOSD '03
(ONCTI), Caracas, Venezuela. Proceedings of the 2nd international conference on Aspect-
[25] Hammer, M. & Champy, J. (1993). Reengineering the oriented software development.
Corporation: A Manifesto for Business Revolution. Harper [50] Rashid, A.; Royer, J.C. & Rummler, A. (2011). Aspect-
Collins. Oriented, Model-Driven Software Product Lines: The
[26] Harrison, M.; Ruzzo, W. & Ullman, J. (1976). Protection in AMPLE Way. Cambridge University Press.
Operating Systems. Communications of the ACM, 19(8), pp. [51] Sandhu, R. & Samarati, P. (1994). Access Control: Principles
461-471. and Practice. IEEE Communications, 32(9), pp. 40-48.
[27] Hepp, M. & Roman, D. (2007). An Ontology Framework for [52] Scholten, F. (2007). The concern-oriented software
Semantic Business Process Management. Proc. of the 8th architecture analysis method. Computer Science, Electrical
international conference Wirtschafts informatik, pp. 1-18. Engineering, Mathematics and Computer Science.
February 28 - March 2, 2007, Karlsruhe, Germany. University of Twente.
[28] Horovitz, J. & Jurigus, M. (1994). La satisfacción total del [53] Tekinerdogan, B. (2004). ASAAM: Aspectual Software
cliente interno. McGraw Hill. Architecture Analysis Method. WICSA '04 Proceedings of
[29] IEEE. (2000). IEEE Std 1471-2000: Practice for the Fourth Working IEEE/IFIP Conference on Software
Architectural Description of Software-Intensive Systems. Architecture, p. 1-10.
[30] ITU-T. (2012). ITU-T Z.151: User Requirements Notation [54] Vanderveken, D. et al. (2005). Deriving Architectural
(URN)-Language Definition, Recommendation. Descriptions from Goal-Oriented Requirements Models.
[31] Mlitat, M. & Dai, Z. (2011). ISO/IEC 25010: Software Proc. ICSE 2006, May 20-28, Shanghai, China.
engineering-Software product Quality Requirements and [55] Lamsweerde, A. (2001). Goal-Oriented Requirements
Evaluation (SQuaRE), Quality models. Engineering: A Guided Tour. Proc. RE’01: 5th Intl. Symp.
[32] Kitchenham, B. (1997). DESMET: A Method for Evaluating Req. Eng., Aug., pp. 249-263, Toronto, August 2001.
Software Engineering Methods and Tools. Computing & [56] Lamsweerde, A. (2003). From system goals to software
Control Engineering Journal, 8(3), pp. 120-126. architecture. School on Formal Methods (SFM 2003), pp.
[33] Kiczales, G. et al. (1997). Aspect-oriented programming. 25-43, Bartinoro, Italy.
Proceedings of the ECOOP, pp. 1-25. [57] VPI. (2012). Visual Paradigm for UML v.10.1.
[34] Krutchen, P. (2000). The Rational Unified Process: An http://www.visual-paradigm.com/download/vpuml.jsp.
Introduction. Addison Wesley. [58] White, S. (2004). Business Process Modeling Notation
[35] Lapouchnian, A. (2005). Goal-Oriented Requirements (BPMN) 1.0. Business Process Management Initiative.
Engineering: An Overview of the Current Research. [59] World Wide Web Consortium. Web Services Architecture
University of Toronto. Requirements. W3C Working Group Note 11 February
[36] Lee, M. (2005). StarUML - The Open Source UML/MDA (2004). Copyright © 2004 W3C® (MIT, ERCIM, Keio).
Platform. http://staruml.sourceforge.net/en/. http://www.w3.org/TR/wsa-reqs.
36
[60] Yu, E. & Mylopoulos, J. (1993). An Actor Dependency Model Engineering: Foundations of Software Quality REFSQ’97,
of Organization Work-With Application to Business Process pp. 171-183. Barcelona, Spain.
Reengineering. Proc. Conf. on Organizational Computing [63] Yu, E., Strohmaier, M., & Deng, X. (2006). Exploring
Systems (COOCS ‘93), pp. 258-268. Nov. 1-4, Milpitas, Intentional Modeling and Analysis for Enterprise
California. Architecture. Proc. of the EDOC 2006 Conference Workshop
[61] Yu, E. (1997). Towards Modelling and Reasoning Support on Trends in Enterprise Architecture Research. Hong Kong.
for Early-Phase Requirements Engineering. Proc. of the 3rd [64] Yu, E. & Lo, A. (2007). From Business Models to Service-
IEEE Int. Symp. on Requirements Engineering, pp. 226-235. Oriented Design: A Reference Catalog Approach. Proc. 26th
[62] Yu, E. (1997). Why Agent-Oriented Requirements International Conference on Conceptual Modeling, pp. 87-
Engineering. Proc. 3rd Int. Workshop on Requirements 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.