19

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 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

ABSTRACT 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

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

20

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.

21

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

22

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

23

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.

24

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.

25

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

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.

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);

Construcción Orientada a Aspectos (OA) de la Arquitectura Inicial.

Figura 2. Paquete del Modelo de Proceso DAOMAC

26

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).

27

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.

28

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]

Regla Lenguaje BPMN Lenguaje GRL Regla para la

Correspondencia Termino Definición Notación Gráfica Termino Definición Notación Gráfica

1 Process o Proceso

Actividad realizada dentro o a través de empresas u organizaciones [48].

Texto

Hardgoal o Meta Funcional

Condición o estado de un asunto que a los stakeholders les gustaría lograr [30].

Un Proceso de BPMN representa una Meta Funcional en GRL.

2 Subprocess o Subproceso

Agregación de actividades que son incluidas dentro de un Proceso [48].

Un Subproceso de BPMN representa una Meta Funcional que ha sido descompuesta en GRL en otras metas de nivel inferior

3 Pool

Participantes (entidades o roles de negocio) [48].

Actor

Entidades activas que llevan a cabo ciertas acciones para lograr metas [30].

Un Pool de BPMN representa un Actor en GRL.

4 Lane o Carril Organizan y categorizan actividades de un Pool [48].

Role o Papel Caracterización abstracta del comportamiento de un actor [1].

Un Carril de BPMN es descrito como el Papel de un Actor concreto en GRL.

5 Task o Tarea Es una actividad atómica [48].

Task o Tarea Es una manera particular de hacer algo [30].

Una Tarea de BPMN representa una Tarea particular en GRL.

6

Labeled Association o Asociación Etiquetada

Muestra la asociación entre una tarea o subproceso funcional y una Meta No funcional, «MNF»

Softgoal o Meta No Funcional

Es una condición o estado de un asunto del mundo que a los stakeholders les gustaría lograr (ITU-T, 2012).

Una Asociación Etiquetada de BPMN relaciona una tarea funcional o subproceso de BPMN con un Softgoal en GRL.

7 Data Object u Objeto de Datos

Artefacto que suministra información a las actividades a ser realizadas [48].

Resource o Recurso

Entidad física o informacional que expresa necesidades [30].

Un Objeto de Datos en BPMN representa un Recurso de GRL.

8 Gateway o Compuerta

Controlan la interacción, convergencia o divergencia dentro de un proceso [48].

Task descomposition link o Vínculo de descomposición de tarea

Tipo de vínculo que descompone una tarea en un hardgoal, subtask, resource o softgoal [30].

Una Compuerta en BPMN representa un Vínculo de descomposición de tareas (And/Xor/Ior) de GRL.

9 Sequence Flow o Flujo de Secuencia

Muestra la secuencia de actividades que son realizadas en un proceso [48].

Means-Ends link o Vínculos Medio-Fin

Relación binaria entre un fin y el medio para lograrlos. El “medio” representa una tarea y el “fin” una meta [30].

Un Flujo de Secuencia en BPMN representa un Vínculo Medio-Fin en GRL.

10 Message Flow o Flujo de Mensaje

Muestra el flujo de mensaje entre dos entidades [48].

Dependency link o Vinculo de dependencia

Relación intencional entre dos actores [30].

Un Flujo de Mensaje en BPMN representa un Vínculo de Dependencia entre dos actores en GRL.

29

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: ; Tareas: ; Recursos: ;

Dependencia: ; Contribución: ; Correlación: ; Descomposició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

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.

30

Tabla 2. Especificación de la Meta Funcional Control de Acceso Nombre Control de Acceso Fuente Modelo de Metas Stakeholders Usuario-Ciudadano, Usuario-Analista Descripción Controlar el acceso de los usuarios Clasificación Funcional Contribución Ninguna Prioridad Muy Importante Concern Requerido Seguridad

Respecto a la Meta No Funcional Seguridad (Tabla 3) se observa que no hay ninguna otra Meta No Funcional requerida y a ella la requiere la Meta Funcional Control de Acceso. Es importante señalar aquí el análisis de las contribuciones que se registran respecto a las otras Metas No Funcionales: negativas respecto a la eficiencia y positiva respecto a usabilidad y precisión.

Tabla 3. Especificación de la Meta No Funcional Seguridad

Nombre Seguridad Fuente Modelo de Metas Stakeholders Usuario-Ciudadano, Usuario-Analista Descripción Gestionar Tramites de Identificación por

medio de redes seguras Clasificación No Funcional Contribución (-) Usabilidad, (-) Eficiencia Prioridad Muy Importante Concern Requerido Ninguno

3. Analizar las posibles Metas Transversales. Se construye

la Tabla de Composición de Metas (Tabla 4). Tabla 4. Composición de Metas

Meta No Funcional / Meta Funcional

Realizar Solicitudes

Control de Acceso

Revisar Solicitudes

Adecuación funcional X Usabilidad X X Eficiencia X X Seguridad X X X

Nótese que las Metas Funcionales candidatas a la composición de metas son aquellas Metas Funcionales que requieren de las Metas No Funcionales Adecuación funcional (precisión), Usabilidad, Eficiencia y Seguridad. En tanto que la Meta Funcional Control de Acceso es requerida por las Metas Funcionales Realizar Solicitudes y Revisar Solicitudes; en tanto que la Meta Funcional Control de Acceso solo depende de la Meta No Funcional Seguridad: existe una transitividad entre ambas. Por ende, las Metas Funcionales Realizar Solicitudes y Revisar Solicitudes requieren de la Meta No Funcional Seguridad. Así mismo, se construye la Tabla de Metas No Funcionales Transversales (Tabla 5).

Tabla 5. Especificación de Meta No Funcional Transversal

Meta No Funcional Transversal

Incumbencia (Meta Funcional) que Entrecruza

Usabilidad (U) Realizar Solicitudes, Revisar Solicitudes Eficiencia (E) Realizar Solicitudes, Revisar Solicitudes Seguridad (S) Realizar y Revisar Solicitud, Control de Acceso

Nótese que Adecuación funcional (Precisión) no es una Meta No Funcional Transversal porque solo entrecruza a la Meta Funcional Realizar Solicitudes (Tabla 4).

4. Determinar Ambigüedades, Conflictos y Contribuciones.

Se elabora la Tabla 6 de Contribuciones de Metas No Funcionales.

Tabla 6. Contribuciones de las Metas No Funcionales

Meta No Funcional Usabilidad Seguridad Eficiencia Usabilidad Ayuda AlgoPositivo Seguridad Ayuda Rompe Eficiencia AlgoPositivo Rompe

Nótese que la Meta No Funcional Eficiencia rompe a la Meta No Funcional Seguridad, dado que esta incide en el tiempo de respuesta. En cambio la Meta No Funcional Usabilidad ayuda a la seguridad en vista que aporta la interfaz usuario que soporta el mecanismo de autorización para que el usuario acceda al sistema de software. Además, que gráficamente en el Softgoal Interdependency Graph (Figura 10), “Ayuda” corresponde a , “AlgoPositivo” corresponde a y “Rompe” corresponde a . Así mismo, se elabora la Tabla 7 de resolución de conflictos, la cual se presenta a continuación.

Tabla 7. Resolución de Conflictos

Meta Funcional Meta No Funcional Transversal en Conflictos Decisión

Realizar Solicitudes (Ayuda) Usabilidad, (Rompe) Eficiencia, (Realiza) Seguridad, Por tratarse de un

sistema de Gestión de Trámites de Identificación sobre Internet, que involucra recursos financieros, la Seguridad prevalece.

Revisar Solicitudes (Ayuda) Usabilidad, (Rompe) Eficiencia, (Realiza) Seguridad

Asignar Estatus a la Solicitud

(Ayuda) Usabilidad, (Rompe) Eficiencia, (Realiza) Seguridad

Consultar Cadena de Aprobación

(Ayuda) Usabilidad, (Rompe) Eficiencia, (Realiza) Seguridad

Debe observarse qué Control de acceso no aparece porque no presenta conflictos ya que solo requiere Seguridad. Un ejemplo de como ayuda la Usabilidad en la Seguridad es en la incorporación de mecanismos arquitectónicos de Autorización de Acceso. Así mismo al incorporar mecanismos de Seguridad como la Encriptación y Desencriptación de Datos para las transacciones financieras, esto incide en el tiempo de respuesta del sistema (Eficiencia), y en la insatisfacción del usuario (Usabilidad).

5. Asignar prioridades a las Metas No Funcionales

Transversales e Identificar la Meta No Funcional Transversales Principal. En principio, se determinan prioridades entre las Metas No Funcionales Transversales (Tabla 8).

31

Tabla 8. Prioridades

Meta /Prioridad

Importancia Alta

Importancia Media

Importancia Baja

Usabilidad X Seguridad X Eficiencia X

La meta transversal Seguridad tiene alta importancia para la Gestión de Trámites de Identificación, dado que toda operación debe ser autenticada por Internet. Por lo tanto, primero refinamos tanto en el Softgoal Interdependency Graph (Figura 10) como en la tabla de Refinamiento, importancia, operacionalizaciones y mecanismos/soluciones arquitectónicas (Tabla 9, primera columna), la meta transversal Seguridad.

Luego, se procederá a construir los Softgoal Interdependency Graph para las demás metas no funcionales transversales, todas expresadas como características de calidad. Es necesario señalar que en este trabajo, solo refinamos la meta Seguridad por razones de espacio.

En la segunda columna de la Tabla 9, se muestra la descomposición de la meta Seguridad; se expresa mediante el refinamiento del ISO/IEC 25010 (Figura 10) en sub-características, el cual es directamente reflejado en el refinamiento del Softgoal Interdependency Graph y ayuda también al establecimiento de las prioridades, así como a la 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

Meta No Funcional Transversal

Refinamiento de la Meta No Funcional

Transversal Importancia Operacionalizaciones Mecanismos/soluciones arquitectónicas

Seguridad

Integridad Media Acceso Limitado Limited Access Pattern

Firewall Firewall Pattern Proxy Pattern

Confidencialidad Alta

Encriptación de Data Synmetric Encryption Pattern Asymmetric Encryption Pattern

Autorización de Acceso Discretionary Access Control (DAC) Mandatory Access Control (MAC) Role-Based Access Control (RBAC)

Back-up de Data Homogeneous Redundancy Pattern No Repudio Baja Certificado Digital Certificate Authority

Auditable Media Bitácora de Transacciones Logger-Auditor pattern Bitácora de Eventos Event logger pattern

Autenticidad Baja Identificación Biométrica Authenticator pattern Firma Electrónica Digital Signature Pattern

32

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

Seguridad-Eficiencia La Seguridad es adversa a la Eficiencia del sistema.

Seguridad-Usabilidad

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, 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

/Operacionalización Encriptación de

Data Autorización de

Acceso Back-up 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

Operacionaliza-ciones Metas Transversales refinadas

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

33

2. Describir los mecanismos/soluciones arquitectónicas asociados a la operacionalización seleccionada. La 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.

Patrón Discretionary Access Control (DAC) [26]: Representa el control de acceso basado en identidades de usuarios y la propiedad de objetos. El patrón permite que un propietario de un objeto pueda conceder permiso a otro usuario para acceder al objeto, y el usuario que tenga permiso lo puede delegar una tercera persona, como se observa en la Figura 11.

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

de forma centralizada, lo que se representa en la Figura 12.

Figura 12. Estructura del patrón arquitectónico MAC expresada

en componentes UML

Patrón Role-Based Access Control RBAC [18]: Describe cómo asignar derechos a usuarios sobre la base de sus funciones o tareas, en un ambiente en el que se exige el control de acceso a los recursos informáticos y donde existe una gran cantidad de usuarios, información y gran variedad de recursos, como se observa en la Figura 13.

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

expresada en componentes UML

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]

Características Sub- características

Mecanismos o soluciones arquitectónicas Comentarios Discretionary Access

Control (DAC) Mandatory Access Control

(MAC) Role-Based Access

Control (RBAC) Adecuación funcional Completitud No aplica Aplica Aplica MAC y RBAC controlan el acceso a

través de Internet

Eficiencia

Tiempo de Respuesta

Tiempo (User)+ Tiempo (Subject)+ Tiempo (ReferenceMonitor)+ Tiempo (Permission)+ Tiempo(Operation)+ Tiempo (Object)

Tiempo (User)+ Tiempo (Subject)+ Tiempo (ReferenceMonitor)+ Tiempo (SecurityLevel)+ Tiempo (Operation)+ Tiempo (Object)

Tiempo (Subject)+ Tiempo (Role)+ Tiempo (Right)+ Tiempo (ProtectionObject)

El RBAC es mejor, menor tiempo de respuesta, por tener menos componentes

Utilización de recursos Baja Media Alta

El DAC utiliza menos recursos; RBAC utiliza más recursos, pero soporta mayor volumen de usuarios

Usabilidad No aplica No aplica No aplica No aplica Ninguno de los patrones estudiados influye en la usabilidad

Seguridad

Confidencialidad Baja (Los usuarios auto-administran los permisos)

Media (Existe un intermediario, se requiere de la clasificación y categorización de permisos)

Alta (Existe un intermediario, se requiere de la asignación de funciones o tareas)

La confidencialidad en RBAC es alta y en MAC es media. Se requiere de mecanismos adicionales para la encriptación del Password.

Integridad Baja (Los usuario delegan los permisos)

Media (Existe un intermediario en la concesión de permisos)

Alta (Existe un intermediario en la concesión de permisos)

El RBAC es mejor que MAC en integridad.

34

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 funcional

El MAC y RBAC son iguales respecto a facilitar el acceso a internet.

Eficiencia

El RBAC es mejor en tiempo de respuesta y en uso de recursos porque si bien utiliza más recursos, soporta mayor volumen de usuarios; si la escalabilidad es importante, RBAC es mejor.

Seguridad El RBAC es mejor que MAC con respecto a la 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

“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.

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]

35

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 -

36

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/WebHome.

[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.

37

[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.