x workshop iberoamericano de ingeniería de requisitos y...

MEMORIAS

X Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software

Editores Francisca Losavio

Guilherme Horta Travassos Vicente Pelechano

Isabel Díaz Alfredo Matteo

Isla de Margarita, Venezuela Del 7 al 11 de Mayo de 2007

http://kuainasi.ciens.ucv.ve/ideas07

Ficha Técnica Memorias del X Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software (IDEAS'07) Editores: F. Losavio, G. H. Travassos, V. Pelechano, I. Díaz, A. Matteo Mayo, 2007 – Caracas, Venezuela ISBN XXXXX ISSN XXXXX Copyright © 2007 by IDEAS'07 All rights reserved Prohibida la reproducción total o parcial de esta obra, por cualquier medio, sin la autorización de sus editores

Agradecimiento

La publicación de estas memorias fue posible gracias al apoyo de las siguientes instituciones venezolanas:

Fondo Nacional de Ciencia Tecnología e Innovación (Fonacit) del Ministerio del Poder Popular para Ciencia y Tecnología

Consejo de Desarrollo Científico y Humanístico (CDCH) de la Universidad Central de Venezuela

Presidencia IDEAS'07

Francisca Losavio Universidad Central de Venezuela Facultad de Ciencias Escuela de Computación

Comité Directivo de IDEAS

Ernesto Pimentel Universidad de Málaga España

Jaelson Brelaz de Castro Universidad Federal do Pernambuco Brasil

Luca Cernuzzi Universidad Católica Nuestra Señora de la Asunción Paraguay

Luis Olsina Universidad Nacional de La Pampa Argentina

Miguel Katrib Universidad de La Habana Cuba

Oscar Pastor Universidad Politécnica de Valencia España

Silvia Gordillo Universidad Nacional de La Plata Argentina

Comité Organizador IDEAS'07

Alfredo Matteo Co-Presidente Universidad Central de Venezuela Facultad de Ciencias Escuela de Computación

Isabel Díaz Co-Presidente Universidad Central de Venezuela Facultad de Ciencias Económicas y Sociales Escuela de Economía

Comité de Programa

Guilherme Horta Travassos Co-Presidente Universidade Federal do Río de Janeiro Brasil

Vicente Pelechano Co-Presidente Universidad Politécnica de Valencia España

Miembros del Comité de Programa

(1) Alessandro Garcia, Lancaster University – United Kingdom (2) Alfredo Matteo, Universidad Central de Venezuela – Venezuela (3) Altigran Soares da Silva, Universidade Federal do Amazonas – Brasil (4) Álvaro Arenas, CCLRC Rutherford Appleton Laboratory – Reino Unido (5) Amador Durán, Universidad de Sevilla – España (6) Antonio Brogi, Universidad de Pisa – Italia (7) Antonio Ruiz, Universidad de Sevilla – España (8) Antonio Vallecillo, Universidad de Málaga – España (9) Carme Quer, Universitat Politècnica de Catalunya – España

(10) Claudia Maria Lima Werner, COPPE/Universidade Federal do Rio de Janeiro (11) Emília Mendes, University of Auckland – Nueva Zelanda (12) Ernesto Pimentel, Universidad de Málaga – España (13) Ernest Teniente, Universitat Politècnica de Catalunya – España (14) Esperanza Marcos, Universidad Rey Juan Carlos – España (15) Fernanda Alentar, Universidade de Pernambuco – Brasil (16) Francisco Ruiz, Universidad de Castilla-La Mancha – España (17) Gustavo Rossi, Universidad Nacional de La Plata – Argentina (18) Itana Gimenes, Universidade Estadual de Maringá – Brasil (19) Jaelson Castro, Universidad Federal do Pernambuco – Brasil (20) João Araújo, Universidade Nova de Lisboa – Portugal (21) Joao Falcão e Cunha, Universidade do Porto – Portugal (22) Jonás Montilva, Universidad de Los Andes – Venezuela (23) José Carlos Maldonado, Universidade de São Paulo – Brasil (24) Juan Hernández, Universidad de Extremadura – España (25) Judith Barrios, Universidad de Los Andes – Venezuela (26) Júlio Leite, Pontificia Universidade Católica do Río de Janeiro – Brasil (27) Káthia Marçal de Oliveira, Universidade Católica de Brasilia – Brasil (28) Luca Cernuzzi, Universidad Católica Nuestra Señora de la Asunción – Paraguay (29) Luis Olsina, Universidad Nacional de La Pampa – Argentina (30) María Lencastre, Universidade de Pernambuco – Brasil (31) Manoel Mendonça, Universidade Salvador UNIFACS – Brasil (32) Marcello Visconti, Universidad Técnica Federico Santa María – Chile (33) Márcio Delamaro, Centro Universitário Eurípides de Marília – Brasil (34) Márcio de Oliveira Barro, Universidade Federal do Estado do Rio de Janeiro – Brasil (35) María Angélica Ovalles, Universidad Simón Bolívar – Venezuela (36) Mario Piattini, Universidad de Castilla-La Mancha – España (37) Miguel Katrib, Universidad de La Habana – Cuba (38) Nancy Zambrano, Universidad Central de Venezuela – Venezuela (39) Natalia Juristo, Universidad Politécnica de Madrid – España (40) Oscar Pastor, Universidad Politécnica de Valencia – España (41) Pere Botella, Universitat Politècnica de Catalunya – España (42) Regina María Maciel Braga, Universidade Federal de Juiz de Fora – Brasil (43) Ricardo de A. Falbo, Universidade Federal do Espíritu Santo – Brasil (44) Sandra Fabbri, Universidade Federal de Sao Carlos – Brasil (45) Silvia Gordillo, Universidad Nacional de La Plata – Argentina

Revisores Colaboradores

(1) Alberto Abelló, Universidad Politècnica de Catalunya – España (2) Alicia Díaz, Universidad Nacional de La Pampa – Argentina (3) Antonia Reina Quintero, Universidad de Sevilla – España (4) Arilo Claudio Dias Neto, COPPE/Universidade Federal do Río de Janeiro – Brasil (5) Hernan Melgratti, Universidad de Pisa – Italia (6) Isabel Díaz, Universidad Central de Venezuela – Venezuela (7) Isi Castillo, Universidad Central de Venezuela – Venezuela (8) Ismael Navas, Universidad de Pisa – Italia (9) Javier Bazzocco, Universidad Nacional de La Pampa – Argentina

(10) Joaquín Peña Siles, Universidad de Sevilla – España (11) Jobson Luiz Massolar da Silva, COPPE/Universidade Federal do Río de Janeiro – Brasil (12) José María Conejero, Universidad de Extremadura – España (13) Juan Manuel Murillo, Universidad de Extremadura – España (14) Maria Istela Cagnin, Centro Universitário Eurípides de Marília – Brasil (15) María José Escalona, Universidad de Sevilla – España (16) Pedro J. Clemente, Universidad de Extremadura – España (17) Pedro Valderas, Universidad Politécnica de Valencia – España (18) Razvan Popescu, Universidad de Pisa – Italia (19) Rodrigo de Oliveira Spinola, COPPE/Universidade Federal do Río de Janeiro – Brasil (20) Thaizel Fuentes, Universidad de Pisa – Italia (21) Valter Vieira de Camargo, Centro Universitário Eurípides de Marília – Brasil (22) Victoria Torres, Universidad Politécnica de Valencia – España

PRÓLOGO Este volumen contiene los trabajos aceptados y presentados en el X Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software: IDEAS'07 celebrado en la Isla de Margarita, Venezuela, del 7 al 11 de mayo de 2007.

Muy brevemente mencionaremos los números y los pasos que dimos durante el proceso de evaluación. Inicialmente se enviaron 104 resúmenes que finalmente se concretaron en el envío de 82 artículos. Cada artículo se asignó a 3 revisores. En la difícil decisión de aceptar o rechazar los trabajos se discutieron las discrepancias con respecto a un mismo artículo para alcanzar, donde fuera posible, un consenso. Además de esto adoptamos el criterio de aceptar como artículos todos y sólo aquellos que obtuvieron un promedio igual o superior a 4 sobre 6. Así, el resultado final ha sido que de los 82 artículos enviados, 29 han sido aceptados para su presentación.

La cantidad de trabajos enviados se ha mantenido, lo que constituye un síntoma claro del interés que existe por IDEAS. Esto nos hace pensar que, pasados 10 años, IDEAS ha lograrse consolidarse como un foro de primer nivel en Ingeniería del Software para Iberoamérica. Al mismo tiempo, el porcentaje de aceptación indica un nivel de exigencia interesante para la realidad Iberoamericana que puede ayudar a situar a IDEAS a una altura que permita obtener un mayor reconocimiento de las calificaciones de los autores en sus respectivos países.

Evidentemente, todo esto no hubiera sido posible sin la valiosa colaboración de distintos actores a quienes se dirigen nuestros más sinceros agradecimientos. Entre ellos cabe mencionar a los autores, por su esfuerzo en investigación, los revisores, miembros del Comité de Programa y sus colaboradores, quienes han realizado un esfuerzo particularmente intenso por la cantidad de trabajados recibidos y el proceso adoptado, los miembros del Comité Organizador, los ponentes de los tutoriales y conferencias invitadas, el Comité Directivo de IDEAS y todas las demás personas e instituciones patrocinantes que de distintas formas han contribuido para que este evento se constituya en una ocasión importante y beneficiosa para la comunidad científica en nuestra región.

Esperamos disfruten de IDEAS'07 así como de la cálida acogida y exuberante belleza de la Isla de Margarita.

Francisca Losavio Presidenta IDEAS'07

Guilherme Horta Travassos Co-Presidente Comité de Programa

Vicente Pelechano Co- Presidente Comité de Programa

ÍNDICE DE CONTENIDOS SESIÓN 1: LENGUAJES, MÉTODOS, PROCESOS Y HERRAMIENTAS (Parte 1) ……...…….. 1 Extracting the Best Features of Two Tropos Approaches for the Efficient Design of MAS ……………………………………………………………..

3

Maria Jocelia Silva, Paulo Roberto Maciel, Rosa C. Pinto, Fernanda Alencar, Patrícia Tedesco, Jaelson Castro Universidade Federal de Pernambuco, Brasil

Soporte Automatizado a la Ingeniería de Requisitos de Seguridad ………………… 17 Daniel Mellado1, Moisés Rodríguez2, Eduardo Fernández-Medina2, Mario Piattini2 1Ministerio de Trabajo y Asuntos Sociales, España 2Universidad de Castilla-La Mancha, España

SESIÓN 2: MODELADO ORGANIZACIONAL ………………………………….…………….. 31 Construcción de Modelos de Requisitos a partir de Modelos de Procesos y de Metas …………………………………………………………

33

José De la Vara, David Anes, Juan Sánchez Universidad Politécnica de Valencia, España

Modelagem de Requisitos Organizacionais, Não-Funcionais e Funcionais em Software Legado com Ênfase na Técnica i* ...................................

47 Victor F. Araya S.1-2, André A. Vicente2, Fabio G. Köerich2, Jaelson Brelaz de Castro3 1Universidad de Talca, Chile 2Universidade Estadual do Oeste do Paraná, Brasil 3Universidade Federal de Pernambuco, Brasil

SESIÓN 3: MEDICIÓN Y EXPERIMENTACIÓN ……………………………….………………. 61 Validando la Usabilidad y Mantenibilidad de los Modelos de Procesos de Negocio: un Experimento y su Réplica ……………………

63

Elvira Rolón1, Félix García2, Francisco Ruiz2, Mario Piattini2 1Universidad Autónoma de Tamaulipas, México 2Universidad de Castilla-La Mancha, España

Soporte de Información Contextual en un Marco de Medición y Evaluación ……. 77 Hernán Molina, Luis Olsina Universidad Nacional de La Pampa, Argentina

Propuesta de Marco para la Selección de Técnicas de Educción de Requisitos ... 91 Dante Carrizo1, Oscar Dieste2 1Universidad Complutense de Madrid, España 2Universidad Politécnica de Madrid, España

SESIÓN 4: INGENIERÍA DE REQUISITOS ……………………………………….…………….. 105 Discovering Group Communication Requirements ………………………………….… 107 Igor Miranda1, Renata Araujo2, Marcos Borges1 1Universidade Federal do Rio de Janeiro, Brasil 2Universidade Federal do Estado do Rio de Janeiro, Brasil

Comparação do Impacto do Uso de um Processo de Engenharia de Requisitos entre Grupos de Desenvolvimento de Software - Um Estudo de Caso ....................

121 Elias Canhadas Genvigir1-2, Nilson Sant´Anna1 1Universidade Tecnológica Federal do Paraná, Brasil 2Instituto Nacional de Pesquisas Espaciais, Brasil

Extensión al Modelo de Separación Multi-Dimensional de Concerns en Ingeniería de Requisitos …………………………………………….….

135 Carlos A. Ospina, Carlos A. Parra, Luis F. Londoño, Raquel Anaya Universidad EAFIT, Colombia

SESIÓN 5: PROCESOS DEL NEGOCIO …………………….………………….…………….. 149 Una Propuesta Basada en Modelos para la Construcción de Sistemas Ubicuos que den Soporte a Procesos de Negocio …….

151

Pau Giner, Victoria Torres Universidad Politécnica de Valencia, España

Experiencia en Transformación de Modelos de Procesos de Negocios desde BPMN a XPDL ……………………………………………..

165 Beatriz Mora, Francisco Ruiz, Félix García, Mario Piattini Universidad de Castilla-La Mancha, España

Verification of Models in a MDA Approach for Collaborative Business Processes … 179 Pablo Villarreal1, Jorge Roa1, Enrique Salomone1-2, Omar Chiotti1-2 1Universidad Tecnológica Nacional, Argentina 2INGAR-CONICET, Argentina

SESIÓN 6: LENGUAJES, MÉTODOS, PROCESOS Y HERRAMIENTAS (Parte 2) …………..... 193 Towards a Standardized Description and a Systematic Use of Social Patterns ……. 195 Carla Silva1, João Araújo2, Ana Moreira2, Jaelson Castro1 1Universidade Federal de Pernambuco, Brasil 2Universidade Nova de Lisboa, Portugal

Aplicación de QVT al Desarrollo de Almacenes de Datos Seguros: Un caso de Estudio …………………………………………………………………………..

209 Emilio Soler1, Juan Trujillo2, Eduardo Fernández-Medina3, Mario Piattini3 1Universidad de Matanzas, Cuba 2Universidad de Alicante, España 3Universidad de Castilla-La Mancha, España

SESIÓN 7: MDA Y TRANSFORMACIÓN DE MODELOS …………………………….……….. 223 Marco de Referencia para la Evaluación de Herramientas basadas en MDA ……. 225 Juan Bernardo Quintero, Raquel Anaya de Paez Universidad EAFIT, Colombia

Composición de Transformaciones de Modelos en MDD basada en el Álgebra Relacional …………………………………………………………

239 Roxana Giandini1, Gabriela Pérez1, Claudia Pons1-2 1Universidad Nacional de La Plata, Argentina 2Universidad Abierta Interamericana, Argentina

OOWS Suite: Un Entorno de Desarrollo para Aplicaciones Web basado en MDA … 253 Francisco Valverde, Pedro Valderas, Joan Fons Universidad Politécnica de Valencia, España

SESIÓN 8: LENGUAJES, MÉTODOS, PROCESOS Y HERRAMIENTAS (Parte 3) …………..... 267 Utilizando a Tecnica I* para Modelar a Concepção de Vigotski Visando Auxiliar o Processo de Desenvolvimento de Software Educacional para Pessoas com Deficiência Visual ......................................................................

269

Victor F. Araya S.1-2, Dorisvaldo Rodrigues da Silva2, André Abe Vicente2, Jaelson de Castro3 1Universidad de Talca, Chile 2Universidade Estadual do Oeste do Paraná, Brasil 3Universidad Federal de Pernambuco, Brasil

Intercambio de Modelos UML y OO-Method …………………………………………… 283 Beatriz Marín, Giovanni Giachetti, Oscar Pastor Universidad Politécnica de Valencia, España

Apoio Automatizado à Gerência de Riscos Cooperativa ........................................ 297 Victorio Carvalho, Alexandre Coelho, Ricardo Falbo Universidade Federal do Espírito Santo, Brasil

SESIÓN 9: LENGUAJES, MÉTODOS, PROCESOS Y HERRAMIENTAS (Parte 4) …………..... 311 Um Modelo Integrado de Requisitos com Casos de Uso ........................................ 313 Michel Fortuna1-2, Claudia Werner1, Marcos Borges1 1Universidade Federal do Rio de Janeiro, Brasil 2Universidade Federal do Juiz de Fora, Brasil

Planejamento Integrado das Atividades de Codificação e Testes em Orientação a Objetos no Nível de Granularidade dos Métodos.................................................

327 Tatiane Lopes, Clovis Fernandes Instituto Tecnológico de Aeronáutica, Brasil

Desenvolvimento de Interface com Usuário Dirigida por Modelos com Geração Automática de Código ....................................................................

341 Lucas Issa1, Clarindo Pádua1, Rodolfo Resende1, Stenio Viveiros1, Pedro Neto2 1Universidade Federal de Minas Gerais, Brasil 2Universidade Federal do Piauí, Brasil

SESIÓN 10: REQUISITOS Y COLABORACIÓN …………..………………………….……….. 355 OO-Sketch: Una Herramienta para la Captura de Requisitos de Interacción …….. 357 José Ignacio Panach, Sergio España, Inés Pederiva, Oscar Pastor Universidad Politécnica de Valencia, España

Colaboração e Negociação na Elicitação de Requisitos ...................................... 371 Danilo Freitas, Marcos Borges, Renata Araujo Universidade Federal do Rio de Janeiro, Brasil

SESIÓN 11: SERVICIOS WEB Y COMPONENTES …………..………………………….…….. 385 Automated Generation of BPEL Adapters ………………………………………………... 387 Antonio Brogi, Razvan Popescu Universidad de Pisa, Italia

Un Enfoque Dirigido por Modelos para el Desarrollo de Servicios Web Semánticos 401 César J. Acuña, Esperanza Marcos, Mariano Minoli Universidad Rey Juan Carlos, España

Un Perfil UML para la definición de Componentes Inteligentes ……………………… 415 José Luis Pastrana1, Ernesto Pimentel1, Miguel Katrib2 1Universidad de Málaga, España 2Universidad de La Habana, Cuba

EVETIS'07: PRIMER ENCUENTRO VENEZOLANO SOBRE TECNOLOGÍAS DE LA INFORMACIÓN E INGENIERÍA DE SOFTWARE ……..………………

427

Sesión 1 Lenguajes, Métodos, Procesos

y Herramientas (Parte 1)

1

Extracting the Best Features of Two Tropos

Approaches for the Efficient Design of MAS

Maria Jocelia Silva1, Paulo Roberto Maciel1, Rosa Cândida Pinto1,

Fernanda Alencar2, Patrícia Tedesco1, Jaelson Castro1

1 Centro de Informática, Universidade Federal de Pernambuco, Caixa Postal

7851, Recife, PE, Brazil

{mjs2, prm, rccp, pcart, jbc}@cin.ufpe.br

2

Departamento de Eletrônica e Sistemas, Universidade Federal de

Pernambuco (UFPE), Caixa Postal 7146, Recife, PE, Brazil

[email protected]

Abstract. Nowadays, there is an increasing demand for agent-oriented software

development methodologies. Tropos is one of the most complete. However, re-

searchers currently use two Tropos approaches. Some potential users feel diffi-

culties in applying the methodology due to the differences in the sequence of

activities and output artifacts generated by those two approaches. In this work

we analyze both approaches of Tropos to identify the similarities and differ-

ences between them. As result, we select a sequence of activities and common

output artifacts and extract the better points of each approach. The selected ac-

tivities are then applied to the xaADB (a multiagent system that monitors

DBMS) modeling to capture the fundamental concepts of the agents oriented

development paradigm: agents, organization, communication, negotiation and

coordination.

Keywords: agent oriented; methodology; multiagent systems; Tropos.

1 Introduction

The construction of a software product involves a series of often highly complex

activities, which is developed from the point of view of some people that have the

expertise on some part of the system. Such people can deeply know the product to be

generated or can have only a partial comprehension of its general context, but they

contribute with information and knowledge to attain the desired result. The use of

methods and standards allow a correct documentation in all phases of the software life

cycle. They ensure that all the information collected during the software development

process can be identified, analyzed correctly and justified by its contributors.

A methodology is a collection of methods covering and connecting different stages

in a process. Tropos [5, 6] is a software development methodology used for modeling

of multiagent systems. It borrows the abstractions and concepts from organizational

and social disciplines to understand, model, reason, analyze and design Multi-Agent

IDEAS'07: X Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software

3

System (MAS) [19]. In fact these approaches provide a more flexible, higher-level set

of constructs to deal with a world operating more on social principles than on mecha-

nistic rules [20]. Currently, there are two versions of Tropos [5, 6]. There are differ-

ences in the sequence of activities and output artifacts generated.

The aim of this paper is analyses the main versions of Tropos methodologies [5,6].

At first, our goal is to develop the case study of multiagent software, the xaADB

multiagent system. So we have to choice one of the versions. Thus we decided to

identify the similarities and differences between them; to propose a hybrid sequence

of activities and commons output artifacts of these approaches; and finally, to apply

the selected sequence to the case study.

This paper is structured as follows. Section 2 presents the related works. Section 3

presents the two Tropos’ approaches. Section 4 introduces the selection of the com-

mons activities. The case study used to evaluate the use of the methodology is showed

in section 5. Section 6 presents the results of the application of the selected activities

in the case study. Finally section 7 presents the conclusions and the future works.

2 Related work

Sturn proposes in [17] an evaluation method for agent-oriented methodologies using a

feature-based analysis, a survey, and a structured analysis. He compares Gaia MaSe,

Tropos and OPM/MAs methodologies. Dam [10] introduces an evaluation framework

for performing a systematic and comprehensive evaluation of several agent-oriented

methodologies. Cernuzzi and Rossi in [8] propose a framework evaluate of the agent-

oriented analysis and design methodologies considering qualitative evaluation criteria

employing quantitative methods. They claim that their framework may be used by

agent-based systems designer as well as for authors of agent-oriented methodologies.

All of these works compare different methodologies. Our work presents a study of

different versions of the same methodology.

Multiple studies have been proposed for increase the modeling agent-oriented sys-

tems. Cernuzzi and Zambonelli [9] introduce AUML [1] as notation into Gaia Meth-

odology [21] for capture a very rich and expressive way the agent’s interaction proto-

cols. Bernon [2] tries joining the ADELFE, Gaia and PASSI methodology for unified

their meta-models showing the interoperability between agent-oriented methodolo-

gies. Juan [14] introduces a conceptual framework for creating and reusing modular

methodologies, their framework can modularize agent-oriented methodologies. None

of these works presents a clear process to development agent-oriented software.

Our proposal outlines a guideline to help the software engineer to development

agent-oriented systems. In our work we join the two versions selecting what have

better in each one for apply in a case study of multiagent software.

3 The Two Tropos Approaches

Tropos was proposed in 2001 [7] to develop a framework for building agent software

systems. This project group authors from various universities in Brazil, Canada, Bel-


4

gium, Germany and Italy. Tropos adopts the concepts offered by i* [20], a modeling

framework based on concepts such as actor (actors can be agents, positions or roles),

and social dependencies among actors (goal, softgoal, task and resource). Tropos

spans four phases:

• Early requirements, concerned with the understanding of a problem by studying an

organizational setting.

• Late requirements, where the system-to-be is described within its operational envi-

ronment, along with relevant functions and qualities.

• Architectural design, where the system’s global architecture is defined in terms of

subsystems, interconnected through data, control and other dependencies.

• Detailed design, where behavior of each architectural component is defined in

further detail.

The initial ideas of Tropos [7] were evolved in what we call Tropos'01 [6], and

later in what we call Tropos'04, whose first studies were presented in [4], and soon

afterwards in [5]. In this paper we considerer the approaches presented in [6] (the

Toronto’s version) and [5] (the Italy’s version).

Based in [18], which propose a generic formalization of a spiral software develop-

ment process for MAS, we analyzed the two Tropos versions. We show the differ-

ences between Tropos’01 and Tropos’04 identifying the activities and output artifacts.

By the analyses of the Tropos’01, we identify that the activities are textually ex-

pressed. This makes hard the comprehension and increases the analyst’s work. There-

fore, we organize, In the Table 1, the Tropos’01 activities with its occurrence se-

quence and output artifacts. We organize the activities as four phases of the method-

ology, labeled as follow: the two first letters relate the phases of the methodology

(e.g., ER-Early Requirements, LR-Late Requirements, AD-Architectural design, DD-

Detailed Design); the two next letters relate to versions of Tropos (e.g. 01-Toronto);

and, finally the sequential number of the activity. Thus, ER.01.1 means the early

requirements phase (ER) of the Tropos’01 (01) and the activity one (1). The artifacts

are codified sequentially (A1..An). The activity ER.01.1 has A1 (Stakeholder List) as

its output artifact.

By the same way, we analyzed the Tropos’04 [5], and proposed the Table 2. Note

that this table has three columns instead two as in Table 1. The activities of the all

phases are grouped in modeling stages (actor modeling, dependency modeling, goal

modeling, plan modeling and capability modeling). We group the two first modeling

stages (Actor Modeling and Dependency Modeling), in the Requirements phases

(Early and Late), because the identification of actors and its dependencies are done

simultaneous in this phases. We join these modeling stages in only one called Actor

and Dependency Modeling. Besides this, the activities labels are changed in the field

related with the Tropos’ version (e.g. ER.04.01, means the early requirements phase

(ER) of the Tropos’04 (04) and the activity one (1) and belong to the Actor and De-

pendency Modeling stage).

Altogether, the activities of both versions are similar in early requirements and late

requirements. The architectural design and detailed design have some differences; in

general, the sequence of activities is different to attain similar artifacts and some dif-

ferent artifacts (e.g., capability diagrams in the Tropos’04 and the UML class diagram

in the Tropos’01.) are found. The next section discusses this similarities and differ-


5

ences and proposes a hybrid sequence of activity that will be applied in the case

study.

Table 1. Tropos’01 Activities and output artifacts.

Phase / Activities Output Artifacts

Early Requirements

ER.01.1. Identify the stakeholders who will be represented as (social) actors who

depend on each other for goals to be achieved, task to be performed and resource to be

furnished.

A1 - Stakeholder

List

ER.01.2. Produce a strategic dependency model (SD) for describing the network of

relationships among actors. A strategic dependency model is a graph involving actors

who have strategic dependencies among each other.

A2 - Strategic

Dependency

Model ER.01.3. Once the relevant stakeholders and their goals have been identified, a strate-

gic rationale model determines through a means-ends analysis how these goals (includ-

ing softgoals) can actually be fulfilled through the contributions of other actors.

A3 - Strategic

Rationale Model

Late Requirements

LR.01.1. Identify the system ‘to-be’ who will be represented as one or more actors

who contribute to the fulfillment of stakeholder goals.

A4 - Strategic De-

pendency Model LR.01.2. Integrate the actors representing the system’s environment and the system’s

functional and non-functional requirements in the Strategic Dependency Model.

A5 - Strategic

Rationale Model

LR.01.3. The system is decomposed into several sub-actors which take on some of these responsibilities. This decomposition and responsibility assignment is realized

using the same kind of means-ends analysis along with the strategic rationale analysis.

A6 - Strategic Rationale Model

Architectural Design

AD.01.1. The first task during architectural design is to select among alternative

architectural styles (e.g. hierarchical contracting, pyramid, joint-venture etc) [15][11]

using as criteria the desired qualities identified earlier.

A7 - Selected

Architectural

Style

AD.01.2. Include new actors in current models and assign system responsibilities to

included actors, based on the selected architectural style.

A8 - Strategic

Dependency

Model

AD.01.3. A further step in the architectural design consists in defining how the goals assigned to each actor are fulfilled by agents with respect to social patterns [12] (e.g.

matchmaker, broker, mediator, wrapper, etc). For this end, designers can be guided by

a catalogue of agent patterns in which a set of pre-defined solutions are available in Tropos, social patterns are used for solving a specific goal defined at the architectural

level through the identification of organizational styles and relevant quality attributes

(softgoals) as discussed previously.

A9 - Social patterns, Strate-

gic Dependency

Model

AD.01.4. A detailed analysis of each social pattern allows defining a set of capabilities

associated with the agents involved. A capability states that an actor is able to act in order to achieve a given goal. In particular, for each capability the actor has a set of

plans that may apply in different situations. A plan describes the sequence of actions to

perform and the conditions under which the plan is applicable.

A10 - Social

Pattern Capabili-ties List

AD.01.5. Capabilities are collected in a catalogue and associated to the pattern. This

allows defining the actors’ role and capabilities suitable for a particular domain.

A11 - Social

Pattern Capabili-

ties List

AD.01.6. The goal is decomposed into different sub goals and solved with a combina-

tion of patterns

A12 - Strategic

Rationale Model.

Detailed Design

DD.01.1. Model a UML class diagram [3] focusing on that actor that will be imple-mented. The target implementation model is the BDI model [16], an agent model

whose main concepts are Beliefs, Desires and Intentions.

A13 - UML class diagram.

DD.01.2. Model events exchanged in the system, using extended AUML [1] sequence diagrams and collaborations diagrams.

A14 - AUML sequence dia-

gram.

DD.01.3. At the lowest level, use plan diagrams, to specify the internal processing of atomic actors. Each identified plan is specified as a plan diagram. The plan graph is a

UML state transition diagram.

A15 - Plan Diagram


6

Table 2. Tropos’04 activities and output artifacts.

Phases/

Modeling Activities

Output Arti-

facts

Early Requirements

Actor and

Dependency

Modeling

ER.04.1. Identify and analyze the stakeholders and their intentions.

Stakeholders are modeled as social actors who depend on one another

for goals to be achieved, plans to be performed, and resources to be

furnished. Intentions are modeled as goals.

A1 - Stakeholder

List

ER.04.2. Through a goal-oriented analysis, goals are decomposed into

finer goals, which eventually can support evaluation of alternatives.

A2 - Actor

Diagram

ER.04.3. The rationale of each goal relative to the stakeholder who is

responsible for its fulfillment has to be analyzed. Goal decomposition

can be closed through a means-end analysis aimed at identifying plans, resources and softgoals that provide means for achieving the goal.

Goal Model-

ing

ER.04.4. Inside the actor diagram, softgoal analysis is performed

identifying the goals that contribute positively or negatively to the softgoal.

A3 - Goal Dia-

gram

Late Requirements

Actor and

Dependency Modeling

LR.04.1. The system-to-be is represented as one actor which has a

number of dependencies with the other actors of the organization. These dependencies define the system’s functional and non-functional

requirements.

A4 - Actor

Diagram for system actor

LR.04.2. These goals are then analyzed from the point of view of the

actor.

Goal Model-

ing

LR.04.3. Softgoal contributions can be identified applying the same

kind of analysis described by the goal diagram.

Plan Model-

ing

LR.04.4. Decompose the plans to complement the goal modeling.

A5 - Goal Dia-

gram for system

actors

Dependency

Modeling

LR.04.5. Some dependencies in the actor diagram must be revised

upon the introduction of the system actor.

A4 - Actor

Diagram


Actor Mod-

eling

AD.04.1. Inclusion of new actors and delegation of sub-goals to sub-

actors upon goal analysis of system’s goals.

A6 - Actor

Diagram for

Architecture

AD.04.2. Inclusion of new actors according to the choice of a specific

architectural style [11].

Dependency

Modeling AD.04.3. Inclusion of actors contributing positively to the fulfillment

of some specific functional and non-functional requirement.

A7 - Extended

Actor Diagram

AD.04.4. This step consists in the identification of the capabilities needed by the actors to fulfill their goals and plans. Capabilities are not

derived automatically but they can be easily identified by analyzing the

extended actor diagram.

A8 - Actor Capabilities List

Capability Modeling

AD.04.5. The last step consists of defining a set of agent types and

assigning each of them one or more different capabilities (agent as-

signment). Tropos suggests a set of pre-defined patterns recurrent in

multi-agent literature that can help the designer [12].

A9 - Agent

Types Capabili-

ties List

Detailed Design

DD.04.1. The UML activity diagram [3] allows us to model a capabil-

ity (or a set of correlated capabilities) from the point of view of a

specific agent.

A10 - Capability

Diagrams

DD.04.2. Each plan node of a capability diagram can be further speci-fied by UML activity diagrams.

A11 - Plan Diagrams

Capability

Modeling

DD.04.3. Here AUML sequence diagrams [1] can be exploited. In

AUML sequence diagrams, agents correspond to objects, whose life-

line is independent from the specific interaction to be modeled com-munication acts between agents correspond to asynchronous message

arcs.

A12 - Agent

Interaction

Diagrams.


7

4 The Selected Sequence of Activities

The two Tropos versions [5, 6] were used to select the better sequence of activities

that allow the methodology users apply the best features of each approach. In this

section, these versions are analyzed and for each methodology phase a sequence of

activities are selected and presented in Table 3. Below, these analyses are split in

phase.

Early and Late requirements: Tropos’01 and Tropos’04 generate similar output

artifacts: Stakeholders List, Actor Diagram with Strategic Dependency Model and

Goal Diagram with Strategic Rationale Model. The difference between the two lies in

the proposed sequence of activities. In Tropos’01 the goals are fulfilled following the

original proposal of the i* [20]. Tropos’04 besides the means-end analysis offers more

types of decompositions (e.g., AND-decomposition and OR-decomposition). Thus,

Tropos’04 is a clearer method for creating the Actor diagram and Goal diagram. Fur-

thermore, models are constructed by analyzing each intentional element and applying

the follow modeling stages: actor modeling, dependency modeling, goal modeling

and plan modeling. This allows create diagrams easier to understand. Therefore, we

selected the Tropos’04 sequence of activities to the both phases (Table 3).

Table 3. Selected sequence of activities of Tropos

Selected Activities Artifacts

Early Requirements

ER.04.1 - Identify the stakeholders and their intentions.

ER.04.2 – Decompose goals through a goal-oriented analysis.

ER.04.3 - Analyze the rationale of each goal.

ER.04.4 - Identify goals that contribute positively or negatively to

softgoal.

A1 - Stakeholder List

A2 - Actor Diagram

A3 - Goal Diagram

Late Requirements

LR.04.1 - Identify the system ‘to-be’. LR.04.2 – Analyze the goals from the point of view of the actor.

LR.04.3 – Identify softgoal contributions.

LR.04.4 – Decompose the plans. LR.04.5 – Revise dependencies in the actor diagram.

A4 - Actor Diagram A5 - Goal Diagram


AD.04.1 - Include new actors and delegation of sub-goals to them.

AD.01.1 - Select among alternative architectural styles. AD.01.2 - Include new actors based on the selected architectural style.

AD.01.3 - Define agents with respect to social patterns.

AD.01.4 - Define a set of capabilities associated with the agents involved in the pattern.

AD.04.5 - Define a set of agent types (social patterns).

A6 - Actor Diagram for

System Architecture A7 - Selected Architectural

Styles

A8 - Actor Diagram A9 - Goal Diagram

A10 - Actor Capabilities List

A11 - Selected social pat-

terns

Detailed Design

DD.01.1 - Model a UML class diagram.

DD.04.1 - Model a capability.

DD.04.2 – Specify each plan node of a capability diagram by UML activity diagrams.

DD.01.2 - Model events using extended AUML sequence diagrams

and collaborations diagrams.

A12 - UML class diagram

A13 - Capability Diagram

A14 - Plan Diagrams A15 - Agent Interaction

Diagrams


8

Architectural design: the global architecture of the system is defined in term of

subsystems represented by new actors. Tropos’01 first defines the architectural styles.

From the selected style, new actors are inserted and its system goals are attributed.

The goals are filled with respect to the social patterns by analyzing their capacities.

The Tropos’04 defines the actors from the analysis of the goals, selects the style

architectural and includes new actors who contribute to fill the functional and non-

functional requirements. It identifies the capacities of for each actor and classifies the

types of agents who fulfill the goals using the social patterns. The results of both

approaches are the same, but we choose a sequence that emphasizes system goals

instead of the architectural styles and social patterns. The selected activities (Table 3)

are: AD.04.1 from Tropos’04; AD.01.1, AD.01.2, AD.01.3, AD.01.4 from Tropos’01,

and AD.04.5, again from the Tropos’04). These activities improve the using of the

methodology in our study case.

Detailed design: following the same process logic of the later phase, the activities

chosen for this phase also come from both Tropos’01 and Tropos’04. The first

activity is to implement a class diagram of each agent (DD.01.1). After this, the

diagram of capacities (DD.04.1) and each plan (DD.04.2) that composes this diagram

are further detailed. Finally, the protocols of communication of the agents are

specified through the sequence diagram from AUML (DD.01.2). It is observed that

the sequence of activities is the same, with addition of class model, that has the

advantage to express a more complete agents modeling.

The summary of the sequence of activities selected for our case study is showed in

Table 3. As explained, these activities are collected from Tropos’01 (see Table 1) and

Tropos’04 (see Table 2). The codification of the labels is the same described above.

Table 3 shows that all activities in the Early and Late Requirements were selected

from Tropos’04. In architectural design some activities was selected from Tropos’01

(AD.01.1, AD.01.2, AD.01.3, AD.01.4) and Tropos’04 (AD.04.1, AD.04.5). In De-

tailed design also was selected activities from Tropos’01 (DD.01.2, DD.01.1) and

Tropos’04 (DD.04.1, DD.04.2).

The next section presents concepts of the system xaADB, which is the case study

of this work.

5 Case Study

To get a deeper understanding of the Tropos methodology, a system architectural

specification was developed. In order to make the case study as complete as possible,

we have modeled the XAADB (eXternal Architecture for Autonomous Database

administration), a multi-agent system that aims at providing autonomy to Database

Management Systems (DBMS). This system is presented as an architectural frame-

work, for autonomous fault resolution components development for traditional

DBMS. The XAADB is being developed as part of a Master’s research at the Infor-

matics Center, Federal University of Pernambuco, Brazil.

Acting as an electronic Database Administrator, the xaADB involves catalogued

fault resolution, fail alerts, bad settings alerts and performance trouble resolution.


9

Some implementation requirements also should be followed (e.g. using of intelligent

agents, software developed as an external layer from DBMS software, using of ma-

chine learning techniques as well as closely following the autonomic computing prin-

ciples [13]). This case study has a special characteristic of being predominantly a

computational system (not only an information system) which brings the specification

of non-functional requirements to the forefront. Database administration is a well

known activity in informatics, thus making it easier to evaluate the case study with

respect to the concepts described in this paper.

6 Applying the Selected Sequence

We apply the Tropos sequence suggested in section 3 on the system xaADB. The

models were drawn to represent xaADB system components.

5.1 Early Requirements: in this phase, stakeholders and their intentions are

modeled. The xaADB is a “computational” system that aims at helping a data base

administrator to solve specific problems in DBMS. This phase justify the need of this

system to the DBA and the organization where the DBA is working for. The artifacts

produced by the activities below represent who are the stakeholders and their needs.

ER.04.1 - Identify the stakeholders and their intentions: There are two main

stakeholders in the system xaADB. The actor Client is the organization that decides

on about the software acquisition. The actor DBA is the database administrator that

works in the organization. The stakeholders and the list of their needs are showed in

table 4.

Table 4. Stakeholder List

Stakeholder Objectives

1 DBA 1. To liberate him/herself of routine tasks;

2. To have resources allow him/her to improve the work quality;

3. To use more time for strategical tasks.

2 Client /

Company

1. More efficient administration of data to a lesser cost;

2. To improve the allocation of human resources in the company.

3. To guarantee the continuity of services.

Figure 1 show the stakeholders needs, in a graphical notation using i* model [20].

Actor Client has two main goals, which are obtain the “Data management improved”

and the “Cost reduced”. It depends on actor DBA to fulfill the goal “Database man-

agement performed”. The Client expects “Efficiency in data management provided”

and the “Service continuity insured”. The DBA expects the Client to achieve better

work conditions. To do his/her job, the DBA uses the services provided by the Op-

erational System (OS) and Database management system (DBMS). They are repre-

sented as system actors.


10

Fig. 1. Artifact actor diagram or Strategic dependency model

ER.04.2 – Decompose goals through a goal-oriented analysis: The Client has as

main goals the “Data management improved” and “Betters work condition achieved”.

DBA has a one goal which is “Data management performed”. In this case, there are

no goal decompositions.

ER.04.3 - Analyze the rationale of each goal: Client can acquire a new solution that

contributes positively to obtain his goal. To acquire a new solution, the Client

performs the plan “Evaluate Solutions”. S/He has three ways to evaluate. S/He can

“Develop a tool” or “Buy a tool” or “Use a free tool”. The actor DBA has the goal

“Database management performed”. S/He can perform two plans to obtain this goal.

S/He either continues the “Use of traditional administration” or “Automate task using

a SMA”. The multiagent system which realizes this task is the xaADB system. Figure

2 shows the goal diagram to DBA and Client actor.

Fig. 2. Artifact goal diagram or Strategic rationale model (SR) for the actor Client.


11

ER.04.4 - Identify the goals that contribute positively or negatively to the softgoal: Among the Client evaluated alternatives to acquire a new solution the plan

“Use a free tool” contributes positively to obtain “cost reduced”. The other options

contribute negatively. Use a tool with requirements of a SMA contributes positively

to achieve the Client soft goal “Efficiency in Data management provided”.

Traditional administration also contributes to obtain this soft goal, but with a minor

pound of efficiency. Plan “Use automated task using a SMA” contributes positively to

softgoal “Service continuity insured”. The figure 2 shows this analysis.

5.2 Late Requirements: This phase focus on actor’s dependencies on system and

analyze the goals to identify non-functional and functional requirements. The main

goal that generates the software is analyzed and decomposed in sub-goals and plans.

These represent the software functionality. The following activities compose the Late

Requirement phase in xaADB software.

LR.04.1 - Identify the ‘system-to-be’: in this activity, the xaADB system is

introduced in the model and its dependencies on others actors are identified. The actor

DBA depends on xaADB system to fulfill the goal “Autonomous fault resolution

performed”. The expected quality attributes from xaADB are represented as softgoals.

These are “High performance”, “Usable system”, “Trustful system”, “Supportable

system” and “Secure system”. xaADB uses the services provided by Operational

system and the DBMS. Figure 3 shows the Actor diagram with xaADB system.

LR.04.2 – Analyze the goals from the actor’s point of view: The system main goal

is “Autonomous fault resolution performed”. It is decomposed in sub-goals that

represent different classes of problems that will be solved by the system. The system

monitors the DBMS and operational system status. When a fault is detected, a

resolution method must be applied to solve the detected problem. Figure 4 shows the

decomposed sub-goals in the area marked with label LR.04.2.

Fig. 3. Artifact Actor diagram or Strategic dependence model (SR).


12

LR.04.3 – Identify softgoal contributions: To satisfy the DBA quality expectation,

new goals are included in the model. “Users authenticated” contribute to achieve the

softgoal “Secure System provided”. “Information and knowledge managed” and

“Events notified” are included to fulfill the softgoal “Usable system provided” and

“Trustful system provided”. Figure 4 shows the softgoal contribution delimited by the

area labeled LR.04.3.

LR.04.4 – Decompose the plans: The analysis of xaADB system is finished by the

identification of plans that will be executed to achieve the goals. To demonstrate this

activity, a means-end analysis of the goal “Database logical objects faults monitored

and solved” was made. The system monitors the DBMS status. If a failure is detected,

it chooses between correcting the failure or suggesting a solution to the DBA. The

failure resolution can be decomposed in many sub-plans to solve the detected

different problems. The area marked with the label LR.04.4 in the figure 4, shows the

plan decomposition. Each goal is analyzed during the late requirements. The final

result is the complete goal diagram shown in figure 4.

LR.04.5 – Revise dependencies in the actor diagram: when the analysis of goals

and plans is complete, new dependencies between the xaADB and others actors can

be identified. For the sake of space, this analysis will not be shown here.

Fig. 4. Artifact goal diagram or Strategic rationale model (SR) for the actor xaADB


13

5.3 Architectural design: In this phase, the actor xaADB is analyzed and new actors

are identified. The goals are delegated to new actors. First, roles assumed by the actor

are analyzed; next roles are broken in agents with special capabilities.

AD.04.1 - Include new actors and delegation of sub-goals to them: The system

goals were grouped in “Monitor and solve faults”, “Manage information and

knowledge” and “Register and notify events”. Actors “Fault solver”, “Information

and knowledge manager” and “Report Manager” were created to achieve these goals,

respectively. “Fault Solver” is a role which can be played by others actors, depending

on the fault to be solved. Actors “Connectivity Manager” and “O.S. Manager” are

agents who monitor and solve connectivity and O.S. failures. Figure 5 shows the actor

diagram for system architecture.

Fig. 5. Artifact Actor Diagram for System Architecture

AD.01.1 - Select among alternative architectural styles: Tropos uses the

organizational styles proposed in [11][15]:pyramid, joint venture, structure in 5 and

more. An architectural organization is defined coming from the system quality

attributes, presented as softgoals. Using these criterions to select organizational

structure, two possibilities were found: Joint Venture and Pyramid. Joint-venture

organization style is more decentralized, which permits greater autonomy to local

actors. So Joint Venture style was chosen for xaADB system.

AD.01.2 - Include new actors based on the selected architectural style: Following

the Joint venture style, the actor Coordinator was inserted into model. Actor “Fault

Solver” delegate global plans execution control to actor Coordinator. Actor

“Information and knowledge manager” provide information to other actors. Both

“Coordinator” and “Fault Solver” can send information to system user about

performed actions to “Report manager” actor. Figure 6 shows the new actors in

selected architectural style.

AD.01.3 - Define agents with respect to social patterns: After select the

architectural style, the plans and objectives are analyzed and new actors are inserted

from agents’ social patterns mappings [12]. Due to space limitation, we will end the

xaADB analysis at this point. In future work, the analysis of social patterns’ use and

detailed design phase will be presented.


14

Fig. 6. Selected Architectural Styles

7 Conclusions and future work

This paper focuses on the identification of activities that capture the best points of two

approaches of the Tropos development methodology. To achieve this, the four Tro-

pos’ phases were analyzed for the both approaches. As a result, a common sequence

of activities and output artifacts was generated. The selected activities were applied to

a multiagent system that monitors distributed DBMS: the xaADB system. In this

work, some activities of the phases Early Requirements, Late Requirements and Ar-

chitectural Design were modeled. The objective was to present how the selected ac-

tivities’ sequence could help us to use the Tropos methodology.

For future work, we plan to analyze deeply the detailed design phase and model the

xaADB system. For this, we will compare Tropos with GAIA [21]. The goal will be

to evaluate which methodology is more adequate to detailed design. Tropos is more

complete for Early Requirements and Late Requirements. We also plan to develop a

process to guide the use of Tropos to Multi-agent system’s modeling and allow trace-

ability in the methodology phases.

References

1. Bauer, B., Muller, J. and Odell, J.: Agent UML: A formalism for specifying multiagent

interaction. In Proc. of the 1st Int. Workshop on Agent-Oriented Software Engineering,

AOSE’00, pages 91–104, Limerick, Ireland (2001).

2. Bernon, C., Cossentino, M., Gleizes, M., Turci, P., and Zambonelli, F. “A Study of Some

Multi-Agent Meta-Models”, in Odell, J., Giorgini, P., and Muller, J., editors, Agent-

oriented Software Engineering V, AOSE 2004, volume 3382 of LNCS, pages 62–77.

Springer-Verlag, Berlin, Heidelberg. (2004).

3. Booch, G., Rumbaugh, J. and Jacobson, I.: The Unified Modeling Language: User Guide.

Addison-Wesley (1999).


15

4. Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopoulos, J., Perini, A.: Towards an Agent

Oriented approach to Software Engineering. In the Workshop Dagli oggetti agli agenti:

tendenze evolutive dei sistemi software (2001).

5. Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopoulos, J. and Perini, A.: Tropos: An

Agent-Oriented Software Development Methodology. Autonomous Agents and Multi-

Agent Systems, 8(3):203–236, (2004).

6. Castro, J., Kolp, M. and Mylopoulos, J.: Towards Requirements-Driven Information Sys-

tems Engineering: The Tropos Project. Information Systems Journal, Elsevier, Vol 27: 365-

89 (2002).

7. Castro, J., Kolp ,M., Mylopoulos, J.: UML for Agent-Oriented Software Development: the

Tropos Proposal. In International Conference on the Unified Modeling Language (2001).

8. Cernuzzi, L. and Rossi, G. “On the Evaluation of Agent Oriented Methodologies”, Proceed-

ings of the Workshop on Agent Oriented Methodology (OOPSLA’02). Pages: 21-32.

COTAR, (2002).

9. Cernuzzi , L. and Zambonelli, F. “Experiencing AUML in the Gaia Methodology “, in 5th

International Conference on Enterprise Information Systems. Angers - France April 2003.

10. Dam, K. H. and Winikoff, M. “Comparing Agent-oriented Methodologies”, in Giorgini, P.,

Henderson-Sellers, B., and Winikoff, M., editors, Agent-Oriented Information Systems: 5th

International Bi-Conference Workshop, volume 3030 of LNAI, pages 78–93. Springer-

Verlag, Berlin, Germany. (2003).

11. Fuxman, A., Giorgini, P., Kolp, M. and Mylopoulos, J.: Information systems as social

structures. In Proc. of the 2nd Int. Conf. on Formal Ontologies for Information Systems,

FOIS’01, Ogunquit, USA (2001).

12. Hayden, S., Carrick, C. and Yang, Q.: Architectural design patterns for multiagent coordi-

nation. In Proc. of the 3rd Int. Conf. on Autonomous Agents, Agents’99, Seattle (1999).

13. Horn, P.: Autonomic Computing: IBM's Perspective on The State of Information Technol-

ogy - IBM Corporation. <http://www.research.ibm.com/autonomic>, last access Jan 2007.

14. Juan, T., Sterling, L., Martelli, M., and Mascardi, V. “Customizing AOSE Methodologies

by Reusing AOSE Features”, in Proceedings of the 2nd Iinternational Joint Conference on

Autonomous Agents and Multiagent Systems (AAMAS’03), pages 113–120, New York,

USA. ACM Press. (2003).

15. Kolp, M., Castro, J. and Mylopoulos, J.: A social organization perspective on software

architectures. In Proc. of the 1st Int. Workshop From Software Requirements to Architec-

tures, STRAW’01, pages 5–12, Toronto, Canada (2001).

16. Rao, A., and Georgeff, M.: Decision procedures for BDIlogics. Journal of Logic and Com-

putation 8(3):293–344 (1998).

17. Sturm A., Dori, D. & Shehory O.: Comparative Evaluation of Agent-Oriented Methodolo-

gies, in Methodologies and Software Engineering for Agent Systems, Kluwer, pp. 127-149

(2004).

18. Wautelet Y., Kolp M. and Achbany Y.: S-Tropos, An Iterative SPEM-Centric Software

Project Management Process, Working Paper IAG (2005).

19. Wooldridge, M.: An Introduction to MultiAgent Systems. John Wiley and sons, LTD,

Chichester, England (2002).

20. Yu, E.: Modelling Strategic Relationships for Process Reengineering. PhD thesis, Univer-

sity of Toronto, Department of Computer Science (1995).

21. Zambonelli, F., Jennings, N. R., Wooldridge, M.: Developing Multiagent Systems: The

Gaia Methodology. ACM Transactions on Software Engineering Methodology, v. 12, n. 3,

p. 317-370 (2003).


16

Soporte Automatizado a la Ingeniería de Requisitos de

Seguridad

Daniel Mellado1, Moisés Rodríguez2, Eduardo Fernández-Medina2, Mario Piattini2

1 Ministerio de Trabajo y Asuntos Sociales; Gerencia de Informática de la Seguridad Social; Centro Informático del Instituto Nacional de la Seguridad Social; Madrid, España.

[email protected] 2 Grupo ALARCOS, Dpto. de Tecnologías y Sistemas de Información, Centro Mixto de Inves-tigación y Desarrollo de Software UCLM-Soluziona; Universidad de Castilla-La Mancha.

Paseo de la Universidad 4, 13071 Ciudad Real, España. (Eduardo.Fdez-Medina, Mario.Piattini, Moises.Rodriguez)@uclm.es

Resumen. La Ingeniería de Requisitos de Seguridad es una disciplina que se está erigiendo como una importante rama de la Ingeniería del Software, debido a que se está comprendiendo cada vez más que la seguridad debe abordarse desde el inicio de la fase de requisitos. Pero sin una herramienta CARE (Com-puter-Aided Requirements Engineering), la aplicación de cualquier metodolo-gía o proceso de ingeniería de requisitos suele fracasar por tener que realizarse manualmente. Por tanto, en este artículo presentamos el prototipo de la herra-mienta CARE denominada SREPTOOL, que da soporte automatizado al proce-so de ingeniería de requisitos de seguridad SREP (Security Requirements Engi-neering Process) para facilitar su aplicación. SREPTOOL simplifica la gestión de requisitos de seguridad proporcionando una forma guiada, sistemática e in-tuitiva de tratarlos desde las primeras fases del desarrollo software, simpli-ficando la gestión del repositorio de recursos de seguridad y la integración de los Criterios Comunes en el proceso de desarrollo software tal y como propone SREP.

Palabras clave: Ingeniería de Requisitos; Requisitos de Seguridad; CARE; Herramienta de Gestión de Requisitos; Criterios Comunes; ISO 15408.

1 Introducción

Hoy en día es ampliamente aceptado el principio que establece que la construcción de la seguridad en las etapas tempranas del proceso de desarrollo es más eficaz respecto a los costes y tiene como resultado diseños más robustos [14]. Por tanto, la seguridad en el software está generando cada vez mayor interés entre los ingenieros del softwa-re [26] lo cual ha ocasionado que la disciplina de la Ingeniería de Requisitos de Segu-ridad sea altamente considerada como parte de la Ingeniería de la Seguridad aplicada a los procesos de desarrollo de sistemas software, lo cual hasta la fecha, ha carecido de la atención necesaria [16]. La denominada Ingeniería de Requisitos de Seguridad, proporciona técnicas, métodos y normas aplicables en el ciclo de desarrollo de los SI


17

y que implica el uso de procedimientos repetibles y sistemáticos para asegurar que el conjunto de requisitos obtenidos es completo, consistente y fácilmente comprensible y analizable por parte de los diferentes actores implicados en el desarrollo del sistema a fin de desarrollar Sistemas de Información seguros [15]. A pesar de todas estas consideraciones, todavía existen muchas organizaciones en

la actualidad que tienden a prestar poca atención a los requisitos de seguridad. Uno de los motivos es la carencia de herramientas CARE (Computer-Aided Requirements Engineering) que soporten la aplicación de los métodos o metodologías o procesos de ingeniería de requisitos de seguridad, lo que suele implicar que, tal y como se descri-be en [2], la implantación de este tipo de procesos suela fracasar por tener que reali-zarse manualmente. Después de haber realizado un análisis comparativo de las propuestas existentes

sobre requisitos de seguridad y herramientas CARE que los soporten en [20], con-cluimos que aunque en los últimos años se ha planteado una gran cantidad de pro-puestas, ninguna de las identificadas alcanzaba un nivel deseado de integración en el ciclo de desarrollo software, ni facilitaban soporte metodológico intuitivo y sistemáti-co para la gestión de requisitos de seguridad a fin de desarrollar sistemas de informa-ción seguros y conformes a los estándares de seguridad actualmente más relevantes (como ISO/IEC 15408 [9] principalmente así como ISO/IEC 27001 [11], ISO/IEC 17799 [10] o ISO/IEC 21827 [8]) en lo relativo a la gestión de requisitos de seguri-dad. Con este fin y partiendo del anteriormente definido concepto de Ingeniería de Requisitos de Seguridad, propusimos el proceso SREP (Security Requirements Engi-neering Process) [21]. En este artículo describimos el prototipo de una herramienta de gestión de requisi-

tos de seguridad denominada SREPTOOL, que hemos desarrollado para dar soporte automatizado a la aplicación de SREP. SREPTOOL proporcionará una forma guiada, sistemática e intuitiva para la aplicación del proceso de ingeniería de requisitos de seguridad SREP, asimismo posibilita una sencilla integración con los demás requisi-tos y con las distintas fases del ciclo de desarrollo, así como facilita el cumplimiento del estándar IEEE 830:1998 [6], ayudándose para ello de las funcionalidades que ofrece ‘IBM Rational RequisitePro’ (herramienta CARE que extiende SREPTOOL). Además, este prototipo ayuda en que los sistemas de información desarrollados sean conformes a los estándares de seguridad anteriormente mencionados en lo relativo a la gestión de requisitos de seguridad, sin la necesidad de dominar dichos estándares y reduciendo la participación de expertos de seguridad para conseguirlo, es decir, mejo-ra la eficiencia de SREP. Y adicionalmente, gracias al Repositorio de Recursos de Seguridad que integra SREPTOOL, se facilita la reutilización de artefactos, mejorán-dose por ende la calidad sucesivamente. El resto del artículo esta organizado de la siguiente forma: en la sección 2, resu-

mimos algunas características básicas de SREP con el fin de comprender la exposi-ción posterior de la herramienta. A continuación, en la sección 3, ofrecemos una comparación de las herramientas CARE y mostraremos el marco comparativo que hemos usado para realizar el análisis de cada una de estas propuestas, y las conse-cuentes decisiones adoptadas. Posteriormente, en la sección 4, se establecen las nece-sidades concretas relativas a la ingeniería de requisitos de seguridad que una herra-mienta CARE tendría que soportar, además describimos la funcionalidad de


18

SREPTOOL y cómo ha sido implementada. Finalmente en la sección 5 expondremos nuestras conclusiones, junto con las aportaciones de SREPTOOL y el trabajo futuro.

2 El Proceso de Ingeniería de Requisitos de Seguridad SREP

SREP [21] es un proceso basado en activos y dirigido por el riesgo para el es-tablecimiento de requisitos de seguridad en el desarrollo de SI seguros. Básica-mente este proceso describe cómo integrar los Criterios Comunes (CC) [9] en el ciclo de desarrollo junto con el uso de un repositorio de recursos de seguridad para facilitar la reutilización de requisitos, activos, amenazas, test y contramedi-das. Asimismo, facilita los distintos tipos de trazabilidad (según los conceptos de trazabilidad en [22] que se basan en [4, 15]): pre-trazabilidad y post-trazabilidad; la trazabilidad hacia atrás y hacia delante; las relaciones de trazabilidad entre requisitos y las relaciones de los requisitos con otros artefactos. Este proceso está centrado en la construcción de conceptos de seguridad en las

primeras fases del desarrollo. De manera genérica se puede describir como un ‘add-in’ de actividades (que se descomponen en tareas, donde se generan artefac-tos de entrada y salida, y con la participación de distintos roles) que se integran sobre el modelo actual de cualquier Organización dándole un enfoque en ingenie-ría de requisitos de seguridad. Como se describe en [21], nosotros hemos descrito más detalladamente cómo SREP se integra en el ciclo de vida del Proceso Unifi-cado [12], que como sabemos está divido en una secuencia de fases y cada fase puede implicar varias iteraciones. De esta manera, el modelo elegido por SREP es un modelo de proceso en espiral y los requisitos de seguridad y sus artefactos asociados (amenazas, etc.) evolucionan a lo largo del ciclo de vida y se tratan a la vez que los otros requisitos funcionales y no funcionales y demás artefactos del pro-ceso de desarrollo software. Al mismo tiempo, los Componentes de los CC se in-troducen en el ciclo de vida de desarrollo software, de manera que SREP usa los diferentes componentes según la fase del ciclo de vida en que se esté y la activi-dad de SREP correspondiente, aunque las tareas de aseguramiento de la calidad se realizan durante todas las fases y son en estas tareas donde la mayoría de los re-quisitos de aseguramiento de los CC se incorporan. El Repositorio de Recursos de Seguridad (RRS) facilita el desarrollo con reuti-

lización de requisitos, lo cual incrementa su calidad, ya que las inconsistencias, errores, ambigüedades y otros problemas se pueden detectar y corregir en proyec-tos sucesivos [25]. Un meta-modelo de repositorio, describiendo la organización del RRS se muestra en la Fig. 1. Se trata de un meta-modelo dirigido por activos así como por amenazas y objetivos, porque los requisitos pueden obtenerse a través de los objetivos de seguridad o de las amenazas partiendo de los activos.


19

Fig. 1 Meta-modelo del Repositorio de Recursos de Seguridad

3. Comparativa de Herramientas CARE

En primer lugar, hubo que tomar la decisión inicial de desarrollar una herramienta nueva o extender una existente, y dadas las características del proceso SREP y los objetivos que pretende su aplicación, se consideró más adecuado extender una herra-mienta existente y centrarse en el campo de las herramientas CARE, descartándose herramientas de gestión documental o de contenidos (CMS, Content Management Systems), así como otro tipo de herramientas CASE (Computer-Aided Software En-gineering) centradas en otras fases del ciclo de vida. Por tanto, en esta sección, con el objetivo de obtener una visión general de las

herramientas CARE, se expone un resumen del estado del arte de estas herramientas. Para lo cual, primeramente, se identifican las herramientas CARE existentes y se seleccionan las que se estudiarán en profundidad; a continuación se realizará una comparación de las seleccionadas anteriormente, para lo cual, se establece un marco de análisis. Para la definición del marco de análisis que nos facilitara la adecuada


20

selección de una herramienta CARE se tuvo en cuenta tanto las necesidades concretas que la herramienta CARE tendría que soportar para la correcta aplicación del proceso SREP, como los requisitos generales de una buena herramienta CARE. Para lo cual nos basamos en [5], al que consideramos como uno de los catálogos de requisitos de herramientas CARE más completos y concretos; así como en la encuesta de INCOSE (International Council on Systems Engineering) [7], considerada como uno de los análisis más importantes y completos de requisitos de herramientas CARE; y en [17], donde se realiza un análisis de herramientas CARE desde la perspectiva de los requi-sitos de seguridad. Basándonos en la encuesta de INCOSE, realizamos una primera selección de

herramientas que cumplían con la mayoría de las funciones y que han demostrado con su grado de penetración en el mercado que proporcionan soluciones efectivas, tal y como se recoge en diversos estudios al respecto, como [1, 7, 24]. Nuestra lista selec-cionada fue: RequisitePro, IRqA, DOORS y Caliber-RM. En la Tabla 1 se resume el análisis comparativo realizado sobre las anteriores

herramientas, utilizando como criterios de comparación aquellas características con-sideradas necesarias para la satisfactoria aplicación del proceso SREP.

Tabla 1 Resumen de la comparativa de herramientas CARE

RequisitePro IRqA DOORS Caliber-RM

Extensibilidad de la

funcionalidad

Si, API basado en COM

Si, API basado en COM y JAVA

Si, API lenguaje DXL

Si, API basado en COM y JAVA

Trazabilidad Si, entre los tipos de requisitos.

Si, entre tipos de requisitos, con-ceptos, UML, código, test.

Si, entre cualquier elemento del repositorio

Si, entre los tipos de requisitos y otros elementos.

Integración con otras

herramientas del ciclo

de vida

Si, con IBM Rational tools (Rational Rose, Rational TestMan-ager, and Rational ClearQuest,

MSProject, etc)

Si, con Office, IRqA-Rational Rose, Mercury TestDirector,

CVS.

Si, mediante el lenguaje DXL.

Si, con Office, Project, Model-ling, Testing e IDE tools.(Ej. Mercury TestDi-

rector)

Soporte reutilización No No No No

Repositorio del

proyecto

MS-Access, MS-SQL Server, Oracle

MS-SQL Server, Oracle, Informix,

MySQL Propietario

MS-Access y MS-SQL Server

Validación de la

especificación

Si, con matriz de trazabilidad


Si, con matriz de trazabili-

dad


Estándares de especi-

ficación

Si, la salida puede adaptarse a las plantillas que se

definan

Si, la salida puede adaptarse a dife-rentes forma-tos/plantillas

Si, la salida puede adap-tarse a dife-rentes forma-

tos

Si, la salida puede adaptarse a dife-rentes formatos

Experiencia previa.

Facilidad uso e Inter-

faz de usuario

Si. Requisitos, vistas y documen-tos en una sola vista. Acceso web colaborativo

No. Organizada en vistas.

No. Difícil de seguir. Módu-los y objetos

No. Práctica y amigable, orienta-da al entorno web

Importación de requi-

sitos Si, Word y CSV

Si, Word, CSV, Excel, XML

Si, Word y ficheros delimitados

Si, Word y fiche-ros delimitados


21

Control de versiones

y líneas base

Si pero no comparables

Si y comparables Si y compa-rables

Si y comparables

Control acceso por

roles y usuarios Si Si Si Si

Requisitos parametri-

zados No No No No

Estas herramientas proporcionaban casi todas las necesidades exigibles para una herramienta CARE. Sin embargo observamos con el análisis realizado que ninguna de ellas cubría todas las necesidades para dar soporte automatizado a SREP. De hecho, alguna de las limitaciones eran críticas para una satisfactoria aplicación de SREP, por lo que la capacidad de extensibilidad de las herramientas se consideró un factor clave de éxito. Destacan entre otras debilidades encontradas, el hecho de que ninguna de las herramientas posibilitaba la parametrización. Al igual, que tampoco facilitaban técni-cas adecuadas para la especificación de requisitos de seguridad (como UMLSec [13] o casos de uso de seguridad [3]), ni de las amenazas (casos de mal uso [23]); ni facili-taban soporte metodológico automatizado para la gestión de requisitos de seguridad, careciendo de soporte para actividades fundamentales, como la valoración del riesgo; ni facilitando la conformidad de los estándares de seguridad actualmente más relevan-tes relativos a requisitos de seguridad (como ISO/IEC 15408, ISO/IEC 27001, ISO/IEC 17799 o ISO/IEC 21827).

En definitiva, se decidió elegir extender RequisitePro como soporte para nuestro prototipo, debido fundamentalmente a los siguientes factores:

• Extensibilidad. RequisitePro facilita un API basada en COM que permite ac-ceder a los datos almacenados en éste (proyectos, requisitos, atributos, etc.) tanto para consultarlos como para modificarlos. Así como controlar la inter-faz de usuario de RequisitePro y también los documentos de Microsoft Word. Lo cual, a pesar de ser algo más limitada que en las otras herramien-tas, nos resultaba más claro y sencillo de adaptar a las necesidades de SREPTOOL.

• Integración automatizada con el resto de actividades del ciclo de vida. Re-quisitePro al estar integrada en el paquete “Rational Suite AnalystStudio” fa-cilitaba un aspecto clave para SREP, la integración no solo con los otros re-quisitos, sino con otros artefactos del ciclo de vida (como su integración con elementos de modelado de Rational Rose).

• Experiencia previa. La herramienta RequisitePro ha sido ampliamente utili-zada como herramienta de soporte en proyectos previos al desarrollo de SREPTOOL (utilizándose por ejemplo en [19]), al ser la herramienta corpo-rativa de la Gerencia de Informática de la Seguridad Social (organismo al que pertenece el primer autor), lo que puede resultar muy interesante para la realización de futuros casos de estudio reales de SREPTOOL.

• Facilidad de uso y Multiusuario. Una de sus características más destacadas es su integración con el procesador de textos Microsoft Word, así como ver todas sus funciones en una sola vista. Además proporciona la posibilidad de acceso multiusuario al proyecto y una interfaz web colaborativa.


22

• Trazabilidad. RequisitePro permite la creación de relaciones de trazabilidad entre distintos tipos de requisitos, y se visualiza a través de una matriz de tra-zabilidad.

• Otros factores destacables. RequisitePro permite cierta reutilización utilizan-do plantillas de documentos. Asimismo, su repositorio está basado en una base de datos relacional comercial (MS-Access, Oracle, MS-SQLServer) y ofrece control de versiones de los requisitos.

4. La Herramienta SREPTOOL

El prototipo que se presenta es una primera aproximación que servirá para obte-ner experiencia del problema mediante su aplicación en escenarios de uso y casos de estudio, para así refinarlo y obtener una versión definitiva de SREPTOOL.

4.1. Tecnología utilizada

Para la creación del prototipo se ha utilizado el lenguaje de programación Visual Basic 6, produciendo como artefacto de salida una biblioteca dll ActiveX, que será enlazada con RequisitePro. De esta manera, los objetos de RequisitePro serán visibles desde SREPTOOL y por otro lado, los artefactos generados por el prototipo serán visibles desde RequisitePro. Así, la funcionalidad del prototipo estaría accesible des-de la ventana principal de Rational RequisitePro, a través del menú Tools�SREPTOOL. Para la integración con RequisitePro, SREPTOOL se ha des-arrollado como un add-in de dicha herramienta CARE, para lo cual se ha utilizado la interfaz de extensibilidad de RequisitePro, en concreto el RequisitePro Extensibility Server (RPX) que permite acceder a los datos almacenados en RequisitePro y el RqGUIApp library que controla la interfaz de usuario del RequisitePro y permite también controlar los documentos de Microsoft Word. Además, utilizará dos bases de datos (para este prototipo son MS-Access). La primera contendrá la información de los usuarios y estará cifrada. La segunda será el repositorio y su acceso estará contro-lado mediante contraseña.

4.2. Funcionalidad del prototipo

El prototipo de SREPTOOL permite la aplicación del proceso SREP en el desa-rrollo de un proyecto dando soporte automatizado a sus nueve actividades. A conti-nuación se explica el funcionamiento del prototipo y cómo SREPTOOL facilita la realización de cada una de estas actividades, ya que va guiando la actuación de los distintos roles y responsables, así como ayuda en la generación de la documentación necesaria. Para lo cual nos ayudaremos de escenarios de uso sencillos para ilustrarlas (extraídos de [19]), aunque debido a las restricciones de espacio no se explicarán en profundidad, ni se mostrarán todas las interfaces del prototipo.


23

Una vez arrancado RequisitePro, si se pulsa en el menú Tools, se puede observar la opción SREPTOOL. Seguidamente, y ya también arrancado el gestor de base de datos, el usuario deberá autentificarse y seleccionar un rol para poder arrancar el prototipo. Dependiendo del rol con el que el usuario se identifique ante el sistema, dicho usuario podrá realizar unas determinadas actividades tal y como se determina en los roles que se determinan en SREP [21], por ejemplo el responsable de la activi-dad (el ingeniero de requisitos, normalmente) junto con el asegurador de calidad validarán los artefactos en cada actividad y permitirán o no pasar a la siguiente activi-dad o volver a alguna anterior. Una vez autorizado, el usuario, y según sus permisos, podrá elegir entre crear un nuevo proyecto o abrir un proyecto ya existente. Esta segunda opción representará la situación en la que ya exista otra iteración de SREP guardada y el usuario desee realizar un refinamiento.

En la Fig. 2, se observa la interfaz principal de SREPTOOL. A través del menú Ver, se permite ver los distintos documentos generados. Hay una pestaña por cada actividad de SREP y tres botones en la parte inferior comunes para todas las pestañas, que permiten validar la actividad, generar el informe de la actividad o salir.

Actividad 1: Acuerdo de las definiciones

Tal y como se observa en Fig. 2, el usuario puede seleccionar los conceptos y de-finiciones de seguridad que desea tener en cuenta para su proyecto. Para ello tan solo tiene que seleccionar el estándar y dentro de él los conceptos que le resulten necesa-rios. Por otro lado, en esta actividad se seleccionan los stakeholders (partes interesa-das o participantes) de entre el personal disponible, asignándole a cada uno de ellos el rol que va a desempeñar. Además en esta primera actividad el usuario puede definir el nivel de aseguramiento que desea aplicar al proyecto en desarrollo, así como recoger los artefactos de entrada de SREP en la Visión de Seguridad, como la Política de Seguridad Organizacional. Finalmente, al pulsar el botón “Generar Informe”, se crea el “Documento de Visión de Seguridad” de manera automática con los datos que el usuario ha introducido en esta actividad.

Actividad 2: Identificación de activos

En esta actividad el usuario podrá seleccionar el Dominio de seguridad al cuál per-tenece el proyecto en desarrollo. En función de dicho dominio, podrá seleccionar aquellos activos que considere relevantes para su proyecto. Por otro lado, el usuario podrá crear un nuevo Dominio y agregarle nuevos activos creados o activos pertene-cientes a otros dominios relacionados.

Actividad 3: Identificación de objetivos de seguridad

En esta actividad el usuario puede elegir para cada uno de los activos selecciona-dos en la actividad anterior, uno/s de los objetivos de seguridad de los que ese activo tenga registrados en el repositorio. Además para cada uno de los objetivos de seguri-dad introducidos en el proyecto, el usuario puede establecer una valoración de dichos objetivos. Por otro lado, esta actividad facilita la creación de nuevos objetivos de seguridad por parte del usuario, así como la creación de dependencias entre dichos objetivos. El usuario puede crear un nuevo objetivo de seguridad y asociárselo tanto a alguno de los activos como al dominio de la aplicación. Finalmente, si se pulsa el


24

botón “Generar Informe”, se plasmarán todos los datos en el “Documento de Objeti-vos de Seguridad”.

Fig. 2 Interfaz de la Actividad 1 de SREPTOOL

Actividad 4: Identificación de amenazas

En esta actividad el usuario podrá ver las amenazas que tienen asociadas los acti-vos de su proyecto y/o las amenazas que tienen asociadas los objetivos de seguridad. De esta manera, podrá seleccionar para su proyecto aquellas amenazas que considere de mayor relevancia. Como se observa en la Fig. 3, el usuario habría seleccionado para el activo “Información personal de nivel alto” la amenaza “Alteración no autori-zada de información”. Sin embargo, pudiera ser que las amenazas que el usuario quiera asociar a los acti-

vos u objetivos de su proyecto no se encontrasen en el Repositorio de Recursos de Seguridad. En este caso, el usuario podrá introducir una nueva amenaza mediante la instanciación de un “nuevo Caso de Mal Uso” o de un “nuevo Árbol de Ataque”, al pinchar sobre dichos botones. De manera que rellenando una plantilla, podrá especi-ficar: Nombre e Id del Caso de mal Uso; Casos de Uso Relacionados; Probabilidad de que se produzca la amenaza; Resumen, Precondiciones y Postcondiciones; Interac-ciones que se producen en el Caso de mal Uso; Tipo de amenaza (Genérica o Específica). Finalmente, si el usuario pulsa en esta actividad el botón de generación de informe, se creará el documento de “Definición del Problema de Seguridad”.

Actividad 5: Valoración del riesgo

Una vez que se han identificado las amenazas en la actividad anterior, ahora el usuario puede estimar el impacto que produce la materialización de cada una de ellas. Una vez calculado el impacto que produce la amenaza, se puede estimar el riesgo aproximado de dicha amenaza teniendo en cuenta la frecuencia con que dicha amena-za se manifiesta. Para realizar el cálculo del impacto y el riesgo, el prototipo utiliza


25

una de las técnicas propuestas por MAGERIT v.2 [18] basada en el análisis mediante tablas. Por ejemplo, si el usuario ha calculado el impacto que tiene la amenaza “Alte-ración no autorizada de información”. Dado que la degradación que produce la ame-naza es “Alta” y la valoración del objetivo de seguridad también es “Alto”, el resulta-do es un impacto “Muy Alto”. A continuación si el usuario ha seleccionado una fre-cuencia para la amenaza de valor “Poco Frecuente”. El resultado será un riesgo de valor “Alto”. Por último, en esta actividad se genera el “Documento de Valoración del Riesgo” al pulsarse el botón “Generar Informe”.

Fig. 3 Interfaz de la Actividad 4

Actividad 6: Elicitación de Requisitos de Seguridad

Esta actividad es una de las principales de SREPTOOL. Una vez se han seleccio-nado las amenazas relevantes para el proyecto, el usuario puede seleccionar aquellos requisitos de seguridad que quiere implantar. Para ello el usuario tiene tres opciones como se observa en la Fig. 4:

• Teniendo seleccionada una amenaza, el prototipo mostrará los requisitos que hay en el RRS para esa amenaza. El usuario solo tendrá que seleccionar aque-llos requisitos que considere relevantes.

• Seleccionando una clase y una de sus familias, el prototipo mostrará los requi-sitos de seguridad asociados a dicha familia. El usuario podrá seleccionar y añadir a su proyecto los requisitos deseados.

• Seleccionando uno de los paquetes de requisitos y dentro del paquete aquellos requisitos deseados.

Por otro lado, el usuario puede introducir nuevos requisitos de seguridad que no se encuentren en el repositorio mediante una plantilla. En la que podrá introducir: El Nombre e Id del Caso de Uso Seguro; Aquellas amenazas y objetivos con las que está relacionado el requisito que instancia el caso de uso seguro; Los requisitos de seguri-dad que son excluyentes respecto al requisito de seguridad que se está instanciando;


26

El tipo de requisito de seguridad (genérico o específico) y en caso de que sea especí-fico, a que requisito genérico pertenece; La clase, familia y paquete de requisitos a los que se quiere asociar el nuevo requisito de seguridad; Precondiciones, Postcondicio-nes e Interacciones del caso. Además, el usuario puede seleccionar o crear Contramedidas o Test de Seguridad.

Finalmente, con el botón “Generar Informe” se crea el “Documento de Especificación de Requisitos de Seguridad”.

Fig. 4 Interfaz Actividad 6

Actividad 7: Priorización

Esta actividad tiene por objetivo automatizar la priorización de requisitos de se-guridad en función del riesgo de las amenazas que mitigan. Para cada uno de los requisitos de seguridad establecidos en el proyecto, el usuario podrá seleccionar el valor de prioridad que desea asignarle (Critico, Estándar, Óptimo). Una vez seleccio-nadas las prioridades de todos los requisitos, al pulsar el botón priorizar se ordenarán los requisitos de mayor a menor prioridad.

Actividad 8: Inspección de requisitos

En esta actividad, el prototipo facilita al usuario la verificación y validación de los requisitos de seguridad, mediante, la comprobación de aquellas amenazas para las cuales no se han especificado requisitos de seguridad en el proyecto, así como, los requisitos de aseguramiento que no han sido añadidos al proyecto de acuerdo con el nivel de aseguramiento que se definió en la actividad 1. En la Fig. 5 se aprecia cómo el prototipo nos indica que para la amenaza “Revelación no autorizada de informa-ción”, el usuario no ha especificado ningún requisito de seguridad. Por otro lado, SREPTOOL muestra cuatro requisitos de aseguramiento pendientes, que de acuerdo


27

al nivel EAL1, el usuario no había añadido a su proyecto. Por último, el prototipo permite la generación automática del “Informe de Validación” y el “Documento de Fundamentación de los Requisitos de Seguridad”.

Actividad 9: Mejora del repositorio.

En esta última actividad, el prototipo permite añadir al repositorio (RRS) todos aquellos recursos de seguridad que el usuario haya creado durante la iteración. SREPTOOL presenta en la parte superior y clasificados por categorías, todos aquellos recursos de seguridad que han sido creados nuevos. El usuario (en este caso el equipo de inspección o el asegurador de la calidad) ha de seleccionar aquellos que considere interesantes de ser introducidos en el RRS y pulsar el botón “Añadir al Repositorio”. De esta manera, en la parte inferior se mostrará el número de elementos de cada cate-goría que se han creado en la iteración, y cuantos de ellos han sido introducidos en el repositorio. Por último, el prototipo generará el “Documento de Declaración de Segu-ridad” conforme a los Criterios Comunes (ISO/IEC 15408), que contendrá toda la información de los artefactos generados por SREPTOOL en anteriores actividades.

Fig. 5 Interfaz Actividad 8

5. Conclusiones y Trabajo Futuro

En nuestros días, la seguridad en el software está generando cada vez mayor inte-rés Existen diversas herramientas CARE interesantes, algunas de ellas han sido des-critas y comparadas en este trabajo, aunque presentan algunas limitaciones en lo rela-tivo a la gestión de requisitos de seguridad expuestas anteriormente. Por ello, el prototipo que se presenta (SREPTOOL) proporciona una forma guia-

da, sistemática e intuitiva para la aplicación del proceso de ingeniería de requisitos de seguridad SREP, asimismo posibilita una sencilla integración con los demás requisi-


28

tos y con las distintas fases del ciclo de desarrollo, así como facilita el cumplimiento del estándar IEEE 830:1998, ayudándose para ello de las funcionalidades que ofrece ‘IBM Rational RequisitePro’. Además, este prototipo facilita que los sistemas de información desarrollados sean conformes a los estándares de seguridad actualmente más relevantes relativos a la gestión de requisitos de seguridad (como ISO/IEC 15408, ISO/IEC 27001, ISO/IEC 17799 o ISO/IEC 21827), sin la necesidad de domi-nar dichos estándares y reduciendo la participación de expertos de seguridad para conseguirlo. Asimismo, gracias al Repositorio de Recursos de Seguridad que integra, se facilita la reutilización de artefactos, mejorándose por ende la calidad sucesiva-mente. Además, existe un conjunto de aspectos proyectados para el futuro del prototipo

que permitirán aumentar el nivel de automatización de la aplicación de SREP y por tanto una mejor eficacia en el proceso de ingeniería de requisitos, entre los cuales destacamos los siguientes: extender el tipo de especificaciones de requisitos soporta-das, para que soporte UMLSec [13]; extender la herramienta para que pueda ser so-portada en otras herramientas CARE; automatizar la creación de los casos de uso de seguridad utilizando los casos de mal uso creados en la actividad 4 de SREP.

Agradecimientos

Este artículo es parte del proyecto ESFINGE (TIN2006-15175-C05-05) del Ministe-rio de Educación y Ciencia, y de los proyectos MISTICO (PBC-06-0082) y DIMENSIONS (PBC-05-012-2) de la Consejería de Ciencia y Tecnología de la Junta de Comunidades de Castilla- La Mancha y el FEDER.

Referencias Bibliográficas

1. Atlantic_Systems, Requirements tools (http://www.volere.co.uk/tools.htm). 2006.

2. Davis, A., Tracing: A Simple Necessity Neglected. IEEE Software, 12(5) (1995). 3. Firesmith, D.G., Security Use Cases. Journal of Object Technology, 2003: p.

53-64. 4. Gotel, O.C.Z. and Finkelstein, A.C.W. An analysis of the requirements trace-

ability problem. in First International Conference on Requirements Engineering (ICRE'94). 1994: IEEE CS Press.

5. Hoffmann, M., Kühn, N., and Bittner, M. Requirements for Requirements Mangement Tools. in 12th IEEE International Requirements Engineering Con-ference (RE'04). 2004. Kyoto, Japan.

6. IEEE, IEEE 830: 1998 Recommended Practice for Software Requirements Specifications. 1998.

7. INCOSE, The International Council on Systems Engineering Requirements Management Tools Survey (http://www.incose.org). 2006.

8. ISO/IEC, ISO/IEC 21827:2002 Information technology -- Systems Security Engineering -- Capability Maturity Model (SSE-CMM). 2002.

9. ISO/IEC, ISO/IEC 15408:2005 Information technology - Security techniques - Evaluation criteria for IT security, (Common Criteria v3.0). 2005.


29

10. ISO/IEC, ISO/IEC 17799 Information technology - Security techniques - Code of practice for information security management. 2005.

11. ISO/IEC, ISO/IEC 27001:2005 Information technology -- Security techniques -- Information security management systems -- Requirements. 2005.

12. Jacobson, I., Booch, G., and Rumbaugh, J., The Unified Software Development Process. 1999, Boston: Addison-Wesley Longman Publishing Co.

13. Jürjens, J., UMLsec: extending UML for secure systems development. UML 2002 - The Unified Modeling Language. Model Engineering, Lan-guages,Concepts, and Tools. 5th International Conference., 2002. LNCS 2460: p. 412-425.

14. Kim., H.-K., Automatic Translation Form Requirements Model into Use Cases Modeling on UML. ICCSA 2005, LNCS, 2005: p. 769-777.

15. Kotonya, G. and Sommerville, I., Requirements Engineering Process and Tech-niques. Hardcover ed. 1998, UK: John Willey & Sons. 294.

16. Lamsweerde, A.v. Elaborating Security Requirements by Construction of Inten-tional Anti-Models. in 26th International Conference on Software Engineering. 2004. Edinburgh: ACM-IEEE.

17. Lasheras, J., Toval, J.A., Nicolas, J., and Moros, B., Soporte Automatizado a la reutilización de requisitos. Jornadas de Ingeniería del Software y Bases de Da-tos (JISBD 2003), 2003: p. 335-346.

18. López, F., Amutio, M.A., Candau, J., and Mañas, J.A., Methodology for Infor-mation Systems Risk Analysis and Management. 2005: Ministry of Public Ad-ministration.

19. Mellado, D., Fernández-Medina, E., and Piattini, M., Applying a Security Re-quirements Engineering Process. 11th European Symposium on Research in Computer Security (ESORICS 2006), 2006. Springer LNCS 4189: p. 192-206.

20. Mellado, D., Fernández-Medina, E., and Piattini, M., A Comparative Study of Proposals for Establishing Security Requirements for the Development of Se-cure Information Systems. The 2006 International Conference on Computational Science and its Applications (ICCSA 2006), Springer LNCS 3982, 2006. 3: p. 1044-1053.

21. Mellado, D., Fernández-Medina, E., and Piattini, M., A Common Criteria Based Security Requirements Engineering Process for the Development of Secure In-formation Systems. Computer Standards and Interfaces, 2007. 29(2): p. 244 - 253.

22. Pinheiro, F.A., Requirements Traceability, in Perspectives on software require-ments, Sampaio, J.C. and Horacio, J., Editors. 2004.

23. Sindre, G. and Opdahl, A.L., Eliciting security requirements with misuse cases. Requirements Engineering 10, 2005. 1: p. 34-44.

24. TCP, Comparative Study Between Requirements Management and Engineering Tools (http://www.irqaonline.com/downloadarea/documents.htm). 2004.

25. Toval, A., Nicolás, J., Moros, B., and García, F., Requirements Reuse for Im-proving Information Systems Security: A Practitioner's Approach. Requirements Engineering, 6(4) (2002). p. 205-219.

26. Viega, J. and McGraw, G., Building Secure Software: How to Avoid Security Problems the Right Way. 2002, Boston: Addison-Wesley.


30

Sesión 2 Modelado Organizacional

31

Construcción de modelos de requisitos a partir de modelos de procesos y de metas1

Jose Luis De la Vara González, David Anes Alcolea, Juan Sánchez Díaz

Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia

Camino de Vera s/n, Valencia, España {jdelavara, danes, jsanchez}@dsic.upv.es

Abstract. Los Sistemas de Información (SI) utilizados dentro de una organización no son algo separado de la organización empresarial a la que le dan soporte, y por tanto la Ingeniería de Requisitos (IR) debe considerar las necesidades de negocio de una organización. Aunque se reconoce que la IR es el puente natural que conecta el mundo empresarial y el mundo de los SI, la mayor parte de la investigación en IR continúa estando orientada a la solución, evitando considerar los problemas reales del mundo empresarial. Las necesidades de negocio pueden ser descritas mediante el alineamiento de los SI con la estrategia del negocio, los procesos de negocio, las infraestructuras organizacionales y las metas organizacionales. Una de las consecuencias del alineamiento entre negocio y los SI es el “mapeado” de las metas organizacionales y los procesos a la especificación del sistema En este trabajo se presenta una aproximación que utiliza una especificación en la forma de modelo de metas, construida mediante heurísticas en base a modelos de procesos en la forma de BPMN. A partir del modelo de metas, mediante un proceso de refinamiento y de etiquetado de metas, se obtiene un modelo de requisitos en la forma de casos de uso. La especificación así obtenida permite reflejar de manera más cercana las necesidades del negocio y asegura el alineamiento de las mismas con el futuro SI.

Keywords: modelado organizacional, proceso de negocio, modelo de metas, requisitos

1 Introducción

El desarrollo de un sistema de información para una organización es un proceso complejo que no sólo conlleva la resolución de los problemas tecnológicos asociados con su arquitectura y componentes, sino que también debe tener en cuenta los problemas organizacionales y sociales relacionados con su dominio de aplicación. En el contexto organizacional, el dominio de aplicación del sistema lo constituye la organización en la cual se ha de acoplar el futuro sistema. Así, un buen conocimiento del dominio de aplicación es un factor crítico para garantizar el éxito de la actividad de elicitación de requisitos – la primera actividad dentro del proceso de desarrollo de software.

1 Este trabajo ha sido desarrollado con el soporte del MEC bajo el proyecto DESTINO

TIN2004-03534 y cofinanciado por FEDER


33

En los últimos años diversos autores [1][2][7][8][15] han reconocido la importancia de modelar la organización antes de elicitar los requisitos de su sistema de información. Un modelo organizacional es una representación que captura la estructura y el comportamiento de la organización en la cual estará inmerso el sistema. Este modelado puede ser muy útil para que los desarrolladores entiendan de un modo apropiado las necesidades de información y los requisitos que el sistema debe satisfacer.

En este trabajo se presenta una propuesta que permite derivar a partir de un modelo organizacional un modelo de requisitos utilizando como pasos intermedios un modelo de procesos y un árbol de metas. La propuesta permite la participación en el proceso de derivación a analistas organizacionales y analistas informáticos o del sistema. Los nexos de unión lo constituyen el lenguaje de modelado de procesos BPMN (Business Process Modelling Notation) [11], que contiene una notación comprensible por los diversos actores interesados en los procesos de negocio, y un árbol de metas derivado de los modelos definidos con esta notación. El árbol de metas se construye a partir de un conjunto de patrones de los procesos de negocio, posteriormente se etiqueta para describir qué metas se automatizan y finalmente se deriva un modelo de casos de uso. El proceso de construcción garantiza el alineamiento entre los modelos organizacionales y los modelos software resultantes.

En nuestra aproximación (descrita en la sección 2) se utilizan diferentes vistas para los diferentes “stakeholders” que participan en el proceso, conteniendo cada una de ellas la información necesaria y de interés para ellos en su ámbito de trabajo. Nosotros distinguimos los siguientes “stakeholoders”:

• Gestores del negocio que toman, entre otras, la decisión de desarrollar o modificar

el sistema de información de la organización. Para ellos es relevante la vista de metas estratégicas de la organización (metas organizacionales en lo que sigue) que describen las metas que quiere conseguir la organización a largo plazo.

• Analistas organizacionales que modelan la organización y dentro de ésta los procesos de negocio. Además, participan junto a los analistas informáticos en la tarea de decidir qué metas del árbol interesan a la organización que sean automatizadas.

• Analistas de sistemas de información que se encargan de desarrollar el sistema informático. La vista de procesos es relevante para ellos ya que derivan mediante un conjunto de heurísticas un árbol de metas asociado a cada proceso. También son relevantes el árbol de metas etiquetado y el modelo de requisitos. El trabajo se encuentra estructurado de la siguiente forma: en la sección 2 se

describe la propuesta con las fases que posee; la sección 3 presenta el caso de estudio que será utilizado para ilustrar la aplicabilidad de la aproximación; las secciones 4, 5 y 6 describen los flujos de trabajo que gobiernan el método; finalmente las secciones 7 y 8 presentan respectivamente los trabajos relacionados y las conclusiones.


34

2 Descripción de la propuesta

La figura 1 muestra las tres fases de la propuesta que hemos llamado respectivamente: modelado organizacional, de metas y de requisitos. Cada fase contiene un conjunto de actividades y trabajadores que participan en las mismas.

Fig. 1. Fases de la propuesta

En la primera fase se analiza y modela la organización en la cual estará inmerso el sistema informático que se pretende construir. El propósito de esta fase es capturar y justificar la actividad de la organización, para posteriormente utilizarla como inicio del proceso de derivación del árbol de metas del sistema de información. En esta fase se construye un diagrama de contexto, un modelo de roles, un modelo de procesos (junto a los recursos que utilizan), un modelo de metas organizacionales o estratégicas y la asignación de las metas de la organización a los procesos que les dan soporte.

En la segunda fase, denominada modelado de metas, los procesos de negocio se analizan. De este análisis se extraen las metas actuales que componen los procesos. A continuación se establecen las metas que se desean automatizar (etiquetado del árbol de metas) y que deben estar presentes en el sistema de información, generando distintas alternativas si procediera. Estas alternativas se evalúan y se selecciona la que se considere como mejor opción para la organización. Como resultado se obtiene un conjunto de metas del sistema a desarrollar.

Una vez seleccionada la opción que mejor encaje con las necesidades del sistema, el análisis de las metas del sistema de información finaliza y éstas se traducen en un modelo de requisitos (casos de uso), en la fase 3 de la propuesta. En las siguientes secciones detallaremos cada una de las mismas.

3 Caso de estudio

Como caso de estudio hemos seleccionado una empresa de confección que subcontrata los procesos de manipulación necesarios para confeccionar sus productos. La empresa únicamente compra el hilo o la materia prima a proveedores. En sus


35

instalaciones dispone de maquinaría para cortar los patrones, el resto de los procesos de transformación (tejeduría, tintado, estampado, etc.) son subcontratados a otras empresas. La organización trabaja bajo pedidos de grandes clientes, de manera que al principio de cada temporada los clientes pactan los modelos y las cantidades de prendas que van a solicitar. Los pedidos de grandes clientes deben ser enviados directamente a las tiendas, con la particularidad de que tanto los pedidos iniciales como los de reposición tienen un plazo de entrega estipulado, por lo que las prendas contenidas en un pedido deben estar fabricadas o en proceso inminente de fabricación. La empresa cuenta con un pequeño ordenador para anotar los pedidos, los envíos y la facturación a clientes. La empresa no dispone de un sistema informático propiamente dicho, de forma que los pedidos de los clientes llegan por correo ordinario y mediante una hoja de cálculo se crean los albaranes que componen las expediciones. Las secretarias de la empresa se encargan de formar los albaranes de envío que pasan a la sección de almacén. El jefe de almacén, de acuerdo al stock disponible de artículos, organiza la expedición o el envío que recoge una empresa de transporte. Los albaranes pueden ser modificados en el almacén, si existe menos cantidad de la pedida, y son entregados de vuelta a las secretarias para que procedan a su facturación. Debido al volumen creciente de pedidos la empresa está interesada en informatizar tanto la gestión de pedidos como de albaranes y facturas. De los diversos procesos de la compañía se utilizará el proceso “selección de pedidos y envío de género a clientes” (“tratar pedido” en lo que sigue) para ilustrar la aproximación.

4 Modelado de la organización

Para modelar una organización en primer lugar se deben mantener entrevistas con empleados de las distintas unidades organizacionales de la empresa o con empleados que desempeñen actividades asociadas a distintos roles dentro de la organización. Por otro lado, también es conveniente estudiar toda la documentación disponible relacionada tanto con la actividad de la empresa como con sus políticas de negocio.

Los modelos generados en esta fase son: diagrama de contexto, modelo de roles, metas estratégicas u organizacionales, modelos de procesos (con recursos), y asignación de metas a procesos. Por cuestiones de espacio haremos hincapié en el modelo de procesos/recursos, comentando brevemente el resto de los modelos. El diagrama de contexto del negocio muestra las distintas unidades organizacionales y la relación de éstas (provisión de datos/servicios) con unidades externas (clientes, proveedores, competidores, etc.). El modelo de roles es un modelo estándar que refleja los actores, las unidades organizacionales y los roles que juegan dentro de cada actividad contenida en los proceso que componen la empresa. Las metas estratégicas están asociadas con los tipos de proceso (i.e. gestionar eficientemente el envío de prendas, mantener la satisfacción de los clientes, diversificar los clientes, minimizar el tiempo de fabricación, aumentar las ventas un 20%), justifican la existencia de los procesos dentro de la organización y explican cómo se llevan a cabo. Habitualmente no pueden medirse directamente y al criterio de medida le llamaremos meta operacional. Por ejemplo, la meta estratégica “mantener la satisfacción de los clientes”, con respecto al proceso “Ventas a Clientes”, puede medirse con la siguiente meta operacional: los clientes están satisfechos si un 80% de los mismos aumenta un


36

5% su volumen anual de pedidos. Es la organización la que tiene que definir las metas operacionales o el procedimiento de medida que se aplica a sus procesos. La asignación de metas a procesos y su operacionalización se realiza como ultima actividad.

Con respecto al modelo de procesos, en él se representan los procesos de negocio de la organización tal y como se desarrollan en la actualidad, que se pueden definir como el conjunto completo y dinámicamente coordinado de actividades colaborativas y transaccionales que proporcionan valor a sus clientes [14]. De entre los distintos lenguajes y notaciones aparecidos para la definición de procesos de negocio destaca BPMN, desarrollada por BPMI e integrada actualmente dentro de OMG. Debido al amplio apoyo que está recibiendo en la industria, BPMN se ha posicionado como el futuro estándar de facto para el modelado de procesos de negocio. La principal meta de BPMN es suministrar una notación que sea fácil de entender por todos los usuarios de procesos de negocio. Esto incluye a los analistas de procesos organizacionales que crean las versiones iniciales de los modelos de negocio, a los desarrolladores encargados de la implementación que dará cabida a dichos modelos en forma de sistema de información, o a los encargados de dirigir y gestionar los procesos. Por tanto, BPMN crea un estándar que intenta llenar el hueco entre el modelado de negocio y su implementación. La notación consiste básicamente en un diagrama, llamado BPD (Business Process Diagram), que está basado en técnicas de diagramas de flujo para crear modelos gráficos de operaciones de procesos de negocios. Un BPD se crea a partir de un conjunto de elementos gráficos que hacen posible un desarrollo de diagramas que resulten fáciles de comprender tanto a los analistas de negocio como a los de sistema. Este conjunto se divide en objetos de flujo, conexiones, elementos de piscina, y artefactos [11].

Fig. 2. Proceso de selección de pedidos y envío de género a clientes

La figura 2 muestra el modelo BPMN para el proceso “tratar pedidos” del caso de estudio, cuya descripción informal es la siguiente: la secretaria selecciona los pedidos que deben servirse de forma inminente. Cada pedido contiene habitualmente un


37

conjunto de patrones (prendas) y un conjunto de centros de envío (direcciones físicas de entrega), mientras que el “packing list” muestra el desglose por centro de envío de las prendas que tienen que servirse. Las prendas se envían a cada centro junto con un albarán de envío por cada caja. El jefe de almacén selecciona aquellos centros que deben servirse primero (priorización de albaranes), ya que los centros pueden servirse en diferentes días. El albarán se entrega a los operarios que realizan la distribución en cajas y, de acuerdo al stock existente, puede que se introduzca menos cantidad de la solicitada. Así, el jefe de almacén decide si las cajas se envían con el contenido actual o bien se espera a que lleguen nuevos productos terminados. A continuación, y manualmente, modifica el “packing list” que recibió de las secretarias y éstas generan el “packing list” definitivo que se sitúa en cada una de las cajas. Con el conjunto de cajas se forma una expedición, la cual recoge una empresa de transporte externa. Por último las secretarias anotan el material que ha sido entregado, para posteriormente generar la factura. Hay que indicar que toda la información se intercambia en papel.

A la vez que se modela el proceso se modelan también los recursos (objetos de datos en la terminología BPMN, que pueden ser tanto lógicos como físicos y sirven de entrada y salida de las actividades del proceso) y las relaciones existentes entre ellos, en la forma de un diagrama de clases. Esta información se utiliza (como se explica después) para derivar el árbol de metas del proceso (fase 2 de la propuesta). Así, el modelo de recursos del caso de estudio es el representado en la figura 3.

Fig. 3. Modelo de recursos para el caso de estudio

5 Modelado de metas

Se puede definir una meta como un objetivo o estado que se debe alcanzar. Su definición hace referencia a una serie de propiedades cuyo cumplimiento se quiere garantizar [9]. El modelado de metas se ha empleado ampliamente en dos contextos. Por una parte, dentro del modelado organizacional las metas guían a la empresa y justifican su comportamiento. Por otra parte, dentro de la ingeniería de requisitos las metas establecen el porqué se necesita y cómo se puede cumplir un requisito (frente a la clásica cuestión de qué es necesario), justifican la presencia de un requisito en una especificación, permiten la generación de alternativas, y aseguran un alineamiento entre la estrategia de negocio de una organización y su sistema de información [9].

La definición de un proceso tiene asociadas una serie de metas que deben satisfacerse durante o tras el desarrollo del mismo. Así, en el camino a alcanzar la meta “final” de un proceso pueden participar sub-metas que denotan hitos relevantes dentro de él, de manera que las acciones que los participantes llevan a cabo como parte del proceso contribuyen al cumplimiento de dichas metas [13]. Al usar BPMN para modelar los procesos de negocio muchas de estas metas están declaradas


38

explícitamente en la estructura del proceso, pero pueden existir otras que sean implícitas al proceso y para cuya detección haga falta el uso del modelo de los recursos que intervienen en el proceso.

La aproximación presentada propone como mecanismo para la definición de metas de un proceso de negocio la construcción de un árbol de metas en el que se usan los conceptos de meta y tarea de la metodología i*[15], donde nosotros únicamente utilizamos una relación de descomposición o refinamiento dentro del árbol. Las metas se pueden descomponer (con relaciones and y or) en nuevas metas o en tareas, las tareas son los nodos hojas del árbol resultante. El árbol será generando en base a una serie de patrones estructurales identificados en BPMN y mediante un conjunto de guías de transformación (véase siguiente sección). El árbol se usa como estructura de análisis de la organización, para justificar las decisiones tomadas y para justificar también la presencia de los requisitos en el sistema de información.

5.1 Guías para derivar el árbol de metas de un proceso de negocio

Las guías utilizadas en nuestra aproximación son heurísticas basadas en el análisis de los elementos de un BPD y en el modelo de recursos asociado. Para ello, se ha definido la correspondencia entre primitivas o patrones estructurales que componen un BPD junto a su modelo de recursos asociado y la estructura de un árbol de metas.

A continuación se detallan los patrones básicos o más comunes que aparecen en BPMN y que tienen una aplicación directa en el caso de estudio. El conjunto completo de guías puede consultarse en [5].

Guía 1 (BPD completo): un BPD representa una meta que se corresponde con la raíz del árbol de metas del proceso. El nombre de la meta coincide con el del BPD que representa. Para el proceso del caso de estudio, la raíz del árbol de metas es “Tratar pedido”.

Guía 2 (Objetos de flujo): según su clase, cada objeto de flujo puede representar una tarea o una meta. Las tareas y eventos con un disparador asociado de BPMN representan tareas, mientras que los subprocesos y pasarelas que representen una decisión en un proceso representan una meta. Respecto al nombre de las metas derivadas de objetos de flujos, éste varía según el tipo del objeto de flujo que se trate. En este sentido, el nombre de una meta o tarea derivada de una actividad coincide con el de ésta, el nombre de una tarea que denote un evento con disparador hará referencia a la clase de disparador que contenga (mensaje, temporizador, excepción,…) y al tipo de evento que se trate (inicial, intermedio o final), y el de una meta que represente una pasarela dependerá del tipo de flujo que origine (bifurcación, bucle, etc.).

Se considera que sólo representan tareas los eventos que tengan asociados un disparador específico ya que si no fuera así sería porque son eventos cuya ejecución es implícita al propio proceso, como suele ocurrir con los eventos iniciales y finales. Por otra parte, la justificación de que un evento representa una tarea es que los eventos con disparadores podrían representarse en el proceso como tareas en cuyo nombre estuviera explícito el tipo de disparador, como por ejemplo la tarea “Generar una excepción por saldo negativo” para un proceso de negocio referente al uso de un


39

cajero. No obstante, el uso de eventos dentro en un BPD le proporciona mayor expresividad respecto a las tareas que podrían representarlos. A su vez, sólo las pasarelas que denotan decisiones representan metas ya que la finalidad de las no lo coincide con la meta que se deriva del proceso.

Por ejemplo, para el proceso de realización de las actividades del tratamiento de pedidos de la empresa de confección, la actividad “Seleccionar pedido” se corresponde con una tarea de mismo nombre y el evento “Suficiente producto disponible” lo hace con una tarea cuyo nombre es “Esperar suficiente producto disponible”.

Guía 3 (Bucles): los bucles (como iteración de un flujo de secuencia) de un proceso representan una meta cuyo objetivo es el cumplimiento de la condición de finalización del mismo. A esta meta contribuyen las metas y tareas que se deriven de los elementos que integren el bucle (contribución AND). Además, la meta del bucle se corresponde con la de la pasarela en la que se comprueba que la condición de finalización se satisface, por lo que su nombre, asignado por el analista, debe hacer referencia a este hecho.

Este patrón se define como consecuencia de que los elementos que componen el bucle podrían integrarse dentro de un subproceso que fuera una actividad que iterase. Además, dentro de él se puede existen refinamientos. Así, se puede dar el caso de que en un bucle existan elementos que no se ejecutan en todas las posibles trazas del proceso y otros elementos que sí. En este caso la meta del bucle se descompone en dos metas (descomposición OR) que distinguen ambos casos, de forma que las metas o tareas derivadas de los elementos que componen el bucle contribuyen (contribución AND) a las dos o sólo una de las nuevas metas introducidas.

Como ejemplo, y coincidiendo con el refinamiento, a partir del proceso de ejemplo se deriva la meta “Tener cantidad de producto suficiente” como resultado del bucle presente, que se descompone en “Comprobarlo cuando se cumple” y “Comprobarlo cuando no se cumple”. Al cumplimiento de la primera de ellas contribuyen las tareas “Situar prendas” y “Validar caja”, y al de la segunda estas dos tareas y “Esperar suficiente producto disponible”.

Guía 4 (Elementos de datos): las metas y tareas derivadas de actividades de un proceso que modifican el estado de un mismo elemento de datos contribuyen (descomposición AND) al cumplimiento de una meta que tiene como objetivo que dicho elemento alcance el último de los estados representados (generar, obtener, establecer,… el elemento en ese estado). Si el estado sólo es modificado por una actividad, se considera que dicha modificación está implícita en la meta o tarea correspondiente a la actividad. Sin embargo, se puede dar el caso de que sólo una actividad modifique el estado de un objeto de datos pero que exista otra meta que contribuya a esta modificación (como es explica la siguiente guía), en cuyo caso sí se define la meta que persigue que el elemento logre un estado determinado.

Adicionalmente, en conjunción con la guía anterior, si todas las actividades que componen un bucle modifican el estado de un mismo elemento de datos, entonces las metas o tareas derivadas de ellas no contribuyen a la meta que hace referencia al estado final de dicho elemento de datos, sino que lo hace la meta correspondiente al bucle.


40

Por tanto, en el caso de estudio se puede derivar la meta “Colocar albarán”, a la que contribuyen “Priorizar albarán” y “Colocar albarán en caja”, y “Tener cantidad de producto suficiente contribuye a “Completar las cajas”.

Guía 5 (Relaciones de agregación inclusiva): si existe una relación de agregación inclusiva entre dos objetos (del modelo de recursos), en el caso de que existan metas cuyo fin sea que estos objetos alcancen un determinado estado, entonces la meta correspondiente al elemento componente contribuye al cumplimiento de la del elemento compuesto. Es decir, las metas relacionadas con los componentes de un elemento también son metas de dicho elemento.

Para el caso de ejemplo, dado que existe este tipo de relación entre envío y cajas, la meta “Completar cajas” contribuye a “Formar envío”.

Guía 6 (Finalización del árbol de metas): una vez derivadas las metas y tareas de un proceso de negocio modelado con BPMN y las contribuciones entre ellas, el árbol resultante debe ser finalizado. Así, todas las metas y tareas que tras el seguimiento de las heurísticas anteriores no contribuyan al cumplimiento de al menos una meta, entonces lo hacen a la meta raíz del árbol.

Fig. 4. Árbol de metas para el proceso del caso de estudio

Para el proceso de tratamiento de pedidos de una empresa de confección, a partir de los patrones estructurales descritos se obtiene el árbol de metas de la figura 4.


41

5.2 Etiquetado del árbol de metas

Una vez formado el árbol de metas de un proceso de negocio, el siguiente paso es establecer las metas que la organización desea automatizar. A cada una de los elementos hoja del árbol se le asigna una etiqueta, representado el efecto que se quiere que la introducción del nuevo sistema tenga sobre ella. Dicha etiqueta puede ser para automatizar (“A”) si se desea que el sistema de información dé soporte a una meta o tarea, cesar (“C”) si se desea que el sistema de información realice autónomamente una meta o tarea que antes requería intervención humana, o mantener (“M”) si se desea que la meta o tarea se satisfaga como hasta ese momento. En el caso de un elemento etiquetado como a cesar, se deben definir las tareas que contribuyen a dicho cese (etiquetadas con “SI”) y que realizará el sistema de información por sí solo.

A continuación se propagan las etiquetas desde los elementos descendientes a las metas de los niveles superiores según la siguiente lógica. Si algún elemento descendiente tiene la etiqueta de automatizar, entonces la meta padre también la tiene. Si todos los descendientes tienen la misma etiqueta de cesar o de mantener, entonces la meta padre tiene la misma etiqueta que su descendencia. Por último, si las etiquetas de los elementos descendientes son combinación de cesar y mantener, entonces la meta padre se etiqueta como a automatizar, puesto que se satisfará gracias a la contribución de metas o tareas que se mantienen y otras cuyo cumplimiento se debe a la intervención autónoma del sistema de información (las tareas descendientes de las etiquetadas como a cesar).

Durante este proceso de etiquetado pueden surgir distintas alternativas respecto a la selección de cada etiqueta, dependiendo de lo que se quiera de cada una de las metas y tareas, y respecto a las tareas a introducir para cesar otra. Implícitamente, todos los elementos tienen las tres alternativas establecidas (mantener, automatizar, cesar), pero sólo será necesario representar en el árbol las alternativas de las metas o tareas que realmente lo necesiten, por su importancia o efecto en el sistema. En este caso, el elemento del árbol se descompone (descomposición OR) en las etiquetas alternativas que se estimen oportunas. Se escogerá aquella opción que mejor encaje con los deseos y necesidades de la organización, de forma que se elimina del árbol la descomposición en alternativas y se le asigna al elemento la etiqueta correspondiente.

Además, se puede producir una reingeniería en los procesos. Por una parte, las tareas que se etiquetan para automatizarlas pueden conllevar la introducción de nuevas actividades en el proceso. Este hecho es debido que, al trabajar con un sistema software, pueden aparecer nuevas acciones en el proceso que son necesarias para su uso o que antes no se realizaban porque carecían de significado o no eran posibles. Por ejemplo, en una organización puede aparecer alguna actividad relacionada con el mantenimiento o uso del sistema de información (arranque, finalización, alguna comprobación física, etc.) o alguna actividad que se lleva a cabo porque el sistema de información posibilita su realización (consulta de estadísticas, monitorización de algún elemento, etc.). Por otra parte, los elementos que hayan originado tareas etiquetadas como a cesar desaparecerán del proceso. Como resultado se genera un nuevo árbol de metas del proceso negocio, del que desaparecen las metas y tareas etiquetadas como a cesar y se reestructura el proceso.


42

Para el caso de estudio, se obtiene el árbol de metas etiquetado de la figura 5, en el que se ha introducido la tarea “Imprimir albarán”, ya que es necesaria una copia impresa del albarán correspondiente para cumplir la meta “Colocar albarán”.

Una vez determinadas las metas y tareas del proceso de negocio a las que debe dar soporte el sistema de información, se obtiene el árbol de metas de éste (correspondientes a las metas con las etiquetas “A” o “SI”). El árbol de estas metas es el resultado de “podar” las metas y tareas que se mantienen como antes y las que se desean cesar. Las tareas introducidas por el cese de otra y etiquetadas con “SI” pasan a contribuir a la meta antecesora más cercana etiquetada como a automatizar, y se mantienen las etiquetas de las metas que no se eliminan.

Fig. 5. Árbol de metas etiquetado para el caso de estudio

6 Modelado de requisitos

El modelo de casos de uso [12] se deriva a partir del árbol de metas obtenido anteriormente. Cada caso de uso denotará un requisito establecido en el árbol de metas del sistema. En primer lugar, los casos de uso se agrupan en paquetes, de manera que cada paquete se corresponde con un BPD y en él estarán aquellos casos de uso que se deriven de su árbol de metas. En segundo lugar, los requisitos se corresponden con las tareas del árbol, las cuales representan servicios que debe


43

ofrecer el sistema. El conjunto de casos de usos que se obtiene en este momento del proceso puede ser modificado si el analista así lo estimase, cambiándoles el nombre para mejorar su expresividad o refinando o abstrayendo los requisitos según el nivel de detalle que considere conveniente. Además, se pueden introducir relaciones de generalización, inclusión o extensión entre los casos de usos.

Por otra parte, el analista tiene que consultar el modelo de recursos en esta fase. Este hecho se debe a que puede considerar necesario la introducción de algún caso de uso relativo a la gestión (alta, baja, modificación o consulta) de los recursos que manipula el sistema. La razón para ello es que sean requisitos necesarios en el sistema, y no estén definidos implícita o explícitamente en ninguno de los casos de uso derivados hasta ahora. El analista también puede definir casos de uso para la gestión del sistema por parte de un administrador o para la distinción entre tipos de usuarios.

Una vez identificados los requisitos, el siguiente paso es asignarlos a un actor (o varios, dependiendo del caso) responsable de él. En el caso de que la tarea correspondiente a un requisito posea la etiqueta “SI”, la realización de éste puede caer bajo la responsabilidad de un actor “Reloj”, si el requisito se ejecuta periódica y autónomamente por el sistema cuando se cumple una condición, o que el requisito se incluya dentro de otro (relación “<<include>>” entre casos de uso) que provoca su activación en el sistema. Si la etiqueta es “A”, el actor responsable será el participante en el proceso que represente la calle en la cual se encuentra el elemento que origina la tarea. También se deben establecer los actores responsables de los posibles casos de uso definidos para la gestión de los recursos, y el analista puede definir nuevos actores y relaciones entre ellos, en este caso de generalización.

Fig. 6. Modelo de casos de uso asociado al proceso del caso de estudio

Como resultado de estos pasos, se obtiene el diagrama de casos de uso de la figura 6 como modelo de requisitos para el caso de estudio planteado, correspondiente al paquete “Tratamiento de pedidos”. Respecto a los participantes en el proceso, se han introducido los actores “Reloj”, “Administrador”, “Usuario” y “Empleado de almacén”, para realizar funcionalidad automática y periódica en el sistema, de gestión de los usuarios del sistema, de identificación, y común al jefe de almacén y operario, respectivamente. En este último caso, el caso de uso “Consultar albarán” se ha introducido en sustitución de “Validar caja” y “Distribuir las cajas”, tareas que aparecen en el árbol, puesto que ésa es la funcionalidad que realmente se necesita. Además, se han establecido diferentes relaciones de herencia entre actores (tienen


44

funcionalidad común) y de inclusión entre casos de uso (uno provoca la ejecución de otro).

7 Trabajos relacionados

Dentro del área de desarrollo de software existen propuestas que consideran el modelado de negocio como fase inicial del proceso de desarrollo. Algunos de estos métodos que pueden encontrarse en la literatura son: I* [15], KAOS [4], y las propuestas de Ericsson [6] y Marshall [10] basadas en el lenguaje unificado de modelado (UML) [12]. Las características principales de las dos últimas es que elaboran modelos de negocio con constructores cercanos al mundo del desarrollo de software y que algunos aspectos de la organización (como la tecnología que implementará los procesos de negocio o la relación entre las distintas vistas de la misma) no quedan claramente especificados.

El framework i* permite especificar modelos de negocios centrándose en las dependencias que existen entre los actores de la organización. Los modelos de i* son considerados estratégicos en el sentido de que cada actor no sólo está interesado en lograr sus metas inmediatas, sino que se interesa también en las relaciones que tiene con otros actores ya que puede depender de que otros actores le proporcionen servicios o recursos. Pensamos que los modelos de i* son complejos y no escalables cuando se aplican a casos reales de cierta entidad.

KAOS permite construir modelos de requisitos a partir de las metas organizacionales. Esta aproximación está soportada por un marco formal que define cada término de forma rigurosa. La principal contribución de KAOS es la demostración de que los requisitos se corresponden con las metas del futuro sistema. El principal inconveniente es que no proporciona ningún mecanismo para representar la estructura de la organización y como consecuencia de ello no permite efectuar, por ejemplo, un análisis de reingeniería de procesos.

8 Conclusiones y trabajos futuros

El artículo presenta una aproximación que enriquece las aproximaciones de desarrollo basadas en metas con un modelo de procesos, proponiendo un conjunto de guías o heurísticas que permiten derivar un modelo de requisitos a partir de un modelo de procesos mediante la utilización de un árbol de metas intermedio. La propuesta permite que los desarrolladores identifiquen de un modo sistemático y participativo (ya que intervienen diversos agentes como los gestores de negocio, analistas organizacionales y analistas de sistemas de información) los requisitos del sistema que dará soporte a la organización.

Además, la propuesta asegura el alineamiento entre la estrategia de negocio de la organización y su sistema de información, gracias a la trazabilidad entre los distintos modelos. Los requisitos de éste son definidos a partir de las metas de los procesos de negocio, los cuales a su vez se basan en las metas estratégicas de la organización.

En la actualidad el trabajo está siendo aplicado a otros casos de estudio para evaluar el alcance del método y de las heurísticas propuestas. La investigación aquí


45

presentada forma parte de un convenio con la empresa Care Technologies [3] cuyo objetivo principal es la construcción de una herramienta y de un método asociado que permita transformar modelos organizacionales en modelos requisitos utilizables en un entorno de generación automática de código.

Referencias

1. Bleistein, S., Cox, K., Verner, J.: Strategic Alignment in Requirements Analysis for Organizational IT: An Integrated Approach. 20º ACM Symposium on Applied Computing, 2005, Santa Fe, USA

2. Bubenko, J.A.: Experiences from Testing Enterprise Modelling- A Requirements Acquisition Method,, 1994

3. Care Technologies. http://www.care-t.com 4. Dardenne, R., Fickas, S., Lamsweerde, A. van: Goal-directed Requirements Engineering.

Proc. 4º ACM Symposium on the foundation of Software Engineering, 1996, San Francisco, USA

5. De la Vara, J. L.: Derivación de modelos de requisitos a partir de modelos organizacionales. Proyecto Fin de Carrera, Facultad de Informática, Universidad Politécnica de Valencia, 2006

6. Eriksson, H., Penker, M.: Business Modeling with UML: Business Patterns at Work. OMG John Wiley and Sons, 2000.

7. Jackson, M.: The Role of Software Architecture in Requirements Engineering- Position Statement. RE’1994. IEEE Computer Society Press . pp 241.

8. Kavakli, E., Loucopoulos, P.: Goal Modeling in Requirements Engineering: Analysis and Critique of Current Methods. En Information Modeling Methods and Methodologies, 102-124, 2005

9. Lamsweerde, A. van: Goal-Oriented Requirements Engineering: A Guided Tour. Proc. 5º IEEE International Symposium on Requirements Engineering, 2001, Toronto, Canadá

10. Marshall, C.: Enterprise Modeling with UML. Addison-Wesley, 2000. 11. OMG: Business Process Modeling Notation (BPMN) Specification (online), febrero 2006,

http://www.omg.org 12. OMG: Unified Modelling Language: Superstructure Version 2.0 (online), julio 2005,

http://www.omg.org 13. Ould, M. A.: Business Processes: Modelling and Analysis for Re-engineering and

Improvement. John Wiley & Sons, 1995 14. Smith, H., Fingar, P.: Business Process Management: The Third Wave. Meghan-Kiffer

Press, 2003 15. Yu, E.: Modeling Strategic Relationships for Process Reengineering, PhD Thesis,

University of Toronto, 1995


46

Modelagem de Requisitos Organizacionais, Não-Funcionais e Funcionais em Software Legado com Ênfase

na Técnica i*

Victor Francisco Araya Santander1,2, André Abe Vicente2, Fabio Gausmann Köerich2,

Jaelson Freire Brelaz de Castro3

1Universidad de Talca, Facultad de Ingeniería, Curicó Chile

[email protected] 2 Universidade Estadual do Oeste do Paraná, Cascavel - Paraná Brasil

[email protected] , [email protected] 3 Universidade Federal de Pernambuco, Recife - Pernambuco Brasil

[email protected]

RESUMO: Diversos sistemas computacionais desenvolvidos utilizando metodologias tradicionais como análise estruturada e essencial encontram-se em processo de evolução devido à necessidade de atender novos requisitos, do uso de novas tecnologias, de mudanças na metodologia de desenvolvimento, entre outras motivações. Neste processo, pouca ou nenhuma atenção tem-se dado ao aproveitamento de informações existentes na documentação destes sistemas tais como os Diagramas de Fluxos de Dados (DFD). Acredita-se que estes diagramas podem ser uma importante fonte de informação na reconstrução de sistemas de software. Para tanto, propõe-se neste artigo, um conjunto de diretrizes que permite derivar modelos organizacionais em i* a partir dos DFDs existentes. Defende-se a idéia de que construir modelos organizacionais como primeiro artefato do processo de evolução de um sistema legado trás inúmeras vantagens, tais como: a possibilidade de visualizar e conhecer adequadamente todos os relacionamentos intencionais estratégicos do ambiente organizacional no qual o software será utilizado, explorar o modelo organizacional criado com os novos requisitos, entre outros. Palavras Chaves: Engenharia de Requisitos, Sistemas Legados, Modelagem Organizacional.

1 Introdução Com base em inúmeros relatos na literatura da área de engenharia de software podemos afirmar que sistemas de software evoluem [4][15][16]. Esta evolução está associada em grande parte à necessidade de atender novos requisitos organizacionais, funcionais e não-funcionais [22] expressos por usuários e clientes. Softwares também precisam evoluir em virtude dos diversos problemas decorrentes do uso inadequado de técnicas de desenvolvimento, bem como falta de uma adequada compreensão do problema a ser solucionado. Estes sistemas de software normalmente vêm acompanhados de uma documentação incompleta, código fonte não documentado e ausência de uso de uma política de rastreamento de requisitos efetiva [26].

Neste sentido, pesquisas recentes [11] destacam que o uso da documentação na evolução de sistemas de software, mesmo que incompleta, pode se tornar uma


47

importante ferramenta de comunicação e melhoria no processo de evolução de sistemas de software. Atualmente, existem diversas empresas trabalhando com sistemas de software denominados de sistemas legados, os quais foram implementados em linguagens de programação em desuso, cuja manutenção e evolução é árdua e custosa. Desta forma, consideramos que tratar a evolução de sistemas de software, desconsiderando completamente a documentação existente pode não ser o caminho mais adequado, pois muitas informações importantes poderiam ser perdidas. Comumente tem se realizado engenharia reversa e/ou reengenharia para recuperar e melhorar sistemas legados visando atender novas solicitações e necessidades de clientes. Contudo, este trabalho não é simples. Normalmente, neste processo não se tem uma clara dimensão do impacto do sistema de software em relação à organização por não se compreender aspectos básicos do ambiente organizacional, bem como quais tarefas e objetivos deste ambiente serão suportados pelo sistema de software. Além desta percepção, raramente explora-se novos requisitos organizacionais que impulsionam a necessidade de novos requisitos funcionais em relação ao sistema de software sob evolução. Visando propor um tratamento mais sistemático neste sentido, neste artigo propomos o uso da técnica de modelagem organizacional i* como forma de explorar as intencionalidades sob a forma de metas, tarefas, recursos e softgoals no processo de evolução de sistemas legados. Consideramos que em um processo de engenharia reversa ou reengenharia, o primeiro passo a ser dado é a correta compreensão do ambiente organizacional, bem como as relações entre o sistema sob evolução e os atores que fazem parte do ambiente organizacional.

O presente artigo está estruturado da seguinte forma: na seção 2, descrevemos os principais métodos orientados a objetivos destacando o uso da técnica i* como ferramenta para representar de forma mais adequada os relacionamentos associados com o sistema legado sob evolução e seu ambiente organizacional. Na seção 3, são apresentadas as diretrizes para apoiar o processo de evolução de sistemas legados utilizando-se a técnica i*. Na seção 4, as diretrizes propostas são aplicadas a um estudo de caso e na seção 5 são apresentadas as considerações finais, bem como os trabalhos relacionados e futuros.

2 Técnicas Orientadas a objetivos utilizadas na Engenharia de Requisitos

Requisitos são freqüentemente difíceis de serem entendidos pelos stakeholders,

mas podem ser justificados e explicados por uma discussão através de objetivos. Abordagens orientadas a objetivos priorizam os “porquês” do sistema a ser construído. Estes “porquês” expressam as razões que justificam a existência dos requisitos do sistema a ser desenvolvido. Podemos classificar estes objetivos em três categorias: objetivos organizacionais, objetivos não-funcionais e objetivos funcionais. Os objetivos organizacionais expressam metas de alto nível da organização relacionadas a políticas internas e externas da organização, planejamento organizacional e necessidades percebidas no ambiente organizacional. Os objetivos funcionais estão relacionados com a obtenção dos requisitos funcionais expressando as funcionalidades que o sistema pretendido deverá satisfazer. Os requisitos não-funcionais (NFRs) [6] são os requisitos que impõem condições aos requisitos


48

funcionais, expressando quais condições e restrições devem prevalecer visando a satisfação dos usuários.

A Engenharia de Requisitos Orientada a Objetivos (EROO) visa propiciar que as metas necessárias a satisfação de usuários e clientes sejam adequadamente representadas, validadas e documentadas. Os principais métodos orientados a objetivos incluem: GBRAM (Goal Based Requirements Analysis Method)[2] [3], CREWS (Cooperative Requirements Engineering With Scenarios) [9][19][20][21] e TROPOS [17][18]. O método GBRAM (Goal-Based Requirements Analysis Method) aponta cenários como sendo uma fonte bastante efetiva para a descoberta de novos objetivos, bem como para a construção de novos cenários. O método GBRAM propõe diversas heurísticas para identificação, classificação, refinamento e elaboração dos objetivos para facilitar a elicitação dos requisitos do sistema. O método CREWS - L'Escritoire é uma técnica baseada em cenários e utiliza o acoplamento bidirecional objetivo-cenário para a elicitação dos requisitos permitindo o relacionamento objetivo-cenário e cenário-objetivo. Pode-se, na descoberta de um objetivo associado a um cenário, descobrir novos objetivos com base em um cenário já elaborado. Portanto, o processo de elicitação de requisitos nesta abordagem ocorre interativamente entre a descoberta de objetivo e cenário. A abordagem CREWS – L’Escritoire tem como núcleo o Chunk de Requisitos (CR) composto pelo par <objetivo, cenário>. Considera-se um objetivo algo intencional e um cenário uma descrição operacional para obtenção do objetivo associado.

Entre os métodos orientados a objetivos utilizados na engenharia de requisitos, podemos destacar a metodologia TROPOS que utiliza a técnica i*. Esta metodologia e mais especificamente a técnica i* são a base da nossa proposta de sistematização do processo de evolução de sistemas legados. A escolha fundamenta-se nos recursos que a técnica disponibiliza para representar aspectos de intencionalidade no ambiente organizacional com a particularidade da possibilidade de inclusão do sistema computacional pretendido ou em evolução na representação deste ambiente. Isto possibilita que aspectos relacionados ao sistema computacional pretendido ou em evolução possam ser explorados já na fase inicial conhecida como “early requirements” e que novas metas em relação a este sistema possam ser expressas e entendidas por todos os stakeholders. Outra vantagem desta abordagem é a facilidade de entendimento da técnica devido a sua simplicidade gráfica e conceitualização. Além destas vantagens, já existem propostas na literatura que permitem a evolução de modelos organizacionais em i* para modelos integrantes da UML (Linguagem de Modelagem Unificada) tais como casos de uso [23][24][25] e diagrama de classes [28]. Isto facilitaria a evolução de sistemas legados, considerando que esta evolução normalmente está associada a mudanças de uma metodologia estruturada de desenvolvimento de sistemas utilizada na construção do sistema legado, para uma metodologia orientada a objetos cujas vantagens são bem conhecidas na literatura da área [1][13][29].

A seguir apresentamos uma descrição mais aprofundada da técnica de modelagem organizacional i*. Em seguida apresentamos nossa proposta. 2.1 A Técnica i* A técnica i* objetiva possibilitar a representação/modelagem de aspectos organizacionais envolvidos com processos [27]. Basicamente permite descrever aspectos de intencionalidade e motivações envolvendo atores em um ambiente


49

organizacional. Para descrever estes aspectos são propostos dois modelos: O Modelo de Dependências Estratégicas (SD) e o Modelo de Razões Estratégicas (SR). O Modelo de Dependências Estratégicas é composto por nós e ligações. Os nós representam os atores no ambiente e as ligações são as dependências entre os atores. Por ator entende-se uma entidade que realiza ações para obter objetivos no contexto do ambiente organizacional. Atores dependem uns dos outros para atingir objetivos, realizar tarefas, e obter recursos no ambiente organizacional. O ator que depende de alguma forma de outro ator é chamado de Depender e o ator que atende e satisfaz o Depender é denominado de Dependee. O objeto ou elemento de dependência entre Depender e Dependee é denominado de Dependum. Portanto, haverá relacionamentos do tipo Depender -> Dependum -> Dependee. O modelo de Razões Estratégicas é um modelo complementar ao modelo de dependências estratégicas. Este modelo permite compreender e modelar de forma mais detalhada as razões associadas com cada ator e suas dependências. Enquanto o modelo de Dependências Estratégicas prove um nível de abstração, no qual modela-se somente os relacionamentos externos entre atores, o modelo de Razões Estratégicas permite uma maior compreensão a respeito das razões estratégicas de atores em relação a processos da organização e como os mesmos são expressos. O modelo de Razões Estratégicas auxilia no processo de Engenharia de Requisitos, permitindo que elementos de processos e as razões por detrás dos mesmos sejam expressas. Na Engenharia de Requisitos, o modelo de Razões Estratégicas pode ser utilizado para compreender como sistemas estão relacionados/envolvidos em rotinas de atores da organização para gerar alternativas, bem como para modelar e suportar o raciocínio de atores organizacionais a respeito destas alternativas.

A seguir apresentamos um exemplo de modelagem de um ambiente de Comércio Eletrônico que mostra o uso da técnica i*. São apresentados os modelos de Dependências Estratégicas e de Razões Estratégicas, figuras 1 e 2 respectivamente. Estes modelos são extraídos de [5] e representam as dependências externas entre os atores organizacionais, bem como as razões estratégicas internas destes atores, em relação a processos da organização Media Shop que utilizará um sistema de comercio eletrônico (Medi@) para realizar vendas pela Internet.

A Media Shop é uma loja que vende e entrega vários tipos diferentes de itens de mídia, tais como: livros, jornais, revistas, CDs de áudio, fitas VHS, DVDs e outros. Os clientes (remotos ou locais) da Media Shop podem usar um catálogo atualizado regularmente que descreve os itens de mídia disponíveis para especificar o seu pedido. A Media Shop é abastecida com os últimos lançamentos, pelos produtores de mídia, e itens já cadastrados, pelos fornecedores de mídia. Para aumentar as vendas, a Media Shop decidiu implementar um serviço de vendas pela internet. Com a nova configuração o cliente pode pedir itens da Media Shop pessoalmente, por telefone, ou através da internet. Este novo sistema foi chamado de Medi@ e está disponível na Web através das facilidades fornecidas pela Telecom. Ele também usa os serviços financeiros fornecidos pelo Banco, que é especializado em transações financeiras on-line. O objetivo básico do novo sistema é permitir que um cliente on-line examine itens no catálogo da internet através do sistema Medi@ e possa também fazer pedidos de compra através da internet.

O Medi@ está disponível para qualquer cliente potencial que possua acesso à internet e um navegador web. Não há restrições de registro ou procedimentos de identificação para a navegação no catálogo ou consulta de um item do banco de dados. Mesmo sem efetivar nenhuma compra, um visitante anônimo é considerado um cliente on-line do Medi@. Clientes potenciais podem pesquisar a loja on-line


50

tanto através do catálogo on-line ou consultando um item do banco de dados. O catálogo agrupa itens da mídia do mesmo tipo em (sub)hierarquias e gêneros (ex.: CDs de áudio classificados em pop, rock, jazz, ópera, música clássica, trilha sonora, ...) de forma que o cliente possa consultar apenas as (sub)categorias que interessa a ele. Um engenho de pesquisa on-line permite aos clientes, com itens particulares em mente, pesquisarem por título, autor/artista/diretor e campos de descrição através de palavras chaves ou de um texto completo. Se o item não estiver disponível no catálogo, o cliente tem a opção de solicitar a Media Shop para fazer um pedido do item desejado ao Fornecedor de Mídia.

Figura 1. Modelo de dependências Estratégicas (SD) para o Media Shop

Figura 2. Modelo de Razões de Estratégicas (SR) para o Media Shop.


51

3 Melhorando a Evolução de Sistemas Legados A evolução de um sistema legado é motivada principalmente pela necessidade de atender a novos requisitos organizacionais, funcionais e não-funcionais. Neste sentido verifica-se também que normalmente esta evolução implica e inclui a necessidade de mudança de metodologia de desenvolvimento de software. Organizações tipicamente desejam que seus sistemas legados desenvolvidos utilizando metodologias tradicionais tais como análise estruturada ou essencial, sejam desenvolvidos utilizando-se metodologias orientadas a objetos como o Processo Unificado [29] ou orientadas a componentes como Catalysis [30]. Esta mudança visa beneficiar os sistemas de software existentes nestas organizações das vantagens principalmente oriundas do uso do paradigma orientado a objetos tais como reusabilidade, coesão, desempenho, entre outras [13]. A análise estruturada ou essencial, na qual a maioria dos softwares legados foi desenvolvido, faz uso da técnica já bastante conhecida denominada de Diagrama de Fluxo de Dados (DFD). Tem se observado que além do código fonte, modelos de representação construídos utilizando-se DFDs tem sido a única documentação existente e disponível de sistemas legados sendo utilizados. Basicamente, um DFD é uma ferramenta de modelagem que representa um sistema de informações como uma rede de processos, interligados entre si por fluxos e depósitos de dados.

Neste contexto, defendemos a idéia de que a partir dos Diagramas de Fluxo de Dados já existentes, os quais em muitos casos, juntamente com o código fonte, representam a única fonte disponível de documentação de sistemas legados, podemos evoluir para modelos organizacionais construídos usando a técnica i*. A vantagem principal deste mapeamento advém do fato de iniciar um processo de engenharia reversa e/ou reengenharia [10][14] coletando todos os aspectos essenciais necessários sobre o ambiente organizacional, bem como sobre as expectativas dos atores da organização em relação ao sistema de software em evolução. Para tanto, propomos na próxima seção algumas diretrizes que viabilizam este processo de mapeamento. Cabe ressaltar que construídos os modelos organizacionais na técnica i* a partir dos DFDs existentes como documentação do sistema legado em evolução, pode-se também evoluir destes modelos organizacionais para diagramas de caso de uso ou diagramas de classe em UML, conforme propostas e ferramentas apresentadas em [23] e [28] respectivamente. Na próxima seção, apresentamos o DFD do Software Casa Segura [32], o qual será utilizado nas seções subseqüentes como estudo de caso. 3.1 Diagrama de fluxo de dados adotado como estudo de caso Segundo Gane & Sarson [31] um diagrama de fluxo de dados é um esquema que permite a visualização dos fluxos de dados através de qualquer sistema mostrando as entidades externas que são as fontes ou os destinos dos dados, os processos que transformam os dados, bem como pelos depósitos de dados os quais representam o armazenamento das informações necessárias no sistema. Desta forma, um DFD é composto por entidades externas, processos, fluxos de dados e depósito de dados. As entidades externas são basicamente uma fonte ou destino para transações. Os processos são conjuntos de operações que transformam dados lógica ou fisicamente, de acordo com uma lógica de processo. Cada fluxo de dados pode ser considerado como um tubo por onde passam pacotes de dados que identificam os processos, entidades ou depósitos de dados. O deposito de dados é utilizado para representar um local no qual os dados do sistema serão armazenados.


52

Visando entender os elementos que compõem um DFD e também para efeitos de exemplificação do uso da aplicação das diretrizes descritas na próxima seção, segue abaixo um exemplo de DFD de um sistema legado passível de evolução.

Figura 3. DFD Software Casa Segura em nível de Contexto [32].

Figura 4. Diagrama de Fluxo de Dados do Processo Monitorar Sensores [32]. A figura 3 representa uma visão em nível de contexto do Diagrama de Fluxo de

Dados do Software Casa Segura [32] e a figura 4 representa o DFD nível 2 em relação ao processo monitorar sensores. Utilizam-se esses dois níveis no processo de mapeamento porque os mesmos contém os elementos que devem ser observados na derivação de modelos organizacionais em i*. O nível de contexto expressa uma visão de alto nível do sistema a ser desenvolvido. Deste nível podemos derivar, por exemplo, os atores da organização envolvidos de alguma forma com o sistema. Adota-se também, para o mapeamento, as informações contidas no último nível do DFD. No estudo de caso adotado sobre o Software Casa Segura, o ultimo nível corresponde ao nível 2. Este nível do DFD expresso na figura 4 contém todas as funcionalidades que devem ser implementadas visando satisfazer os requisitos dos usuários. Assim estas informações podem derivar objetivos, tarefas e recursos a serem considerados no modelo de dependências estratégicas em i*. Desta forma, estes dois níveis serão explorados visando extrair os requisitos organizacionais, funcionais e não-funcionais do ambiente organizacional e sistema de software em evolução.


53

Na figura 3, podemos observar que O Software Casa Segura recebe os fluxos de dados “Comandos e Dados do Usuário” e “Estado do Sensor” das entidades externas “Painel de Controle” e “Sensores”, respectivamente. Nesta figura também podemos observar que o software fornece os fluxos de dados “Informação para ser Mostrada”, “Tipo do Alarme” e “Tons do Número de Telefone”, os quais são enviados para as entidades externas “Mostrador de Painel de Controle”, “Alarme” e “Linha Telefônica” ,respectivamente.

A figura 4 representa uma parte do DFD de último nível do Software Casa Segura expresso em [32]. Apresentando todos os elementos que detalham o processo de mais alto nível “Monitorar Sensores”. Os outros processos no mesmo nível de “Monitorar Sensores” não são explorados devido a limitação de espaço neste artigo. Observando mais atentamente a figura 4, podemos verificar todas as funções do “Software Casa Segura” necessárias ao detalhamento necessário à obtenção do monitoramento dos sensores. Estes processos são “Ler Sensores”, “Avaliar com base na Configuração”, “Discar o Telefone”, “Gerar Sinal de Alarme”, “Formatar Para Exibir” e “Mostrar Mensagens e Estados”, além dos fluxos de dados “Estado do Sensor”, “Número do Telefone”, “Identificação e Tipo do Sensor”, “Dados de Configuração”, “Identificação Tipo e Localização do Sensor”, “Dados de Alarme”, “Tons do Número de Telefone”, “Tipo de Alarme” e “Informação do Sensor”, bem como o Depósito de Dados “Informação de Configuração”. Na próxima seção são apresentadas as diretrizes que serão utilizadas na evolução do DFD para o modelo organizacional através da técnica i*. 3.2 Diretrizes para apoiar o processo de evolução de sistemas legados Tendo em vista a necessidade de apoiar o processo de evolução de sistemas legados e considerando as vantagens advindas da derivação de modelos organizacionais em i* a partir dos DFDs disponíveis de um sistema legado e em evolução, propõe-se abaixo o conjunto de diretrizes que podem ser seguidas para este mapeamento. Cabe ressaltar que estas diretrizes não fazem parte da técnica i* e as mesmas representam a principal contribuição do presente artigo. Para efeitos de exemplificação, as figuras 3 e 4 são consideradas na descrição das diretrizes. As diretrizes 1 e 2 consideram o DFD de nível de contexto apresentado na figura 3. As demais diretrizes consideram o nível 2 do DFD (figura 4) pois deste nível podemos extrair importantes tarefas, objetivos e recursos que devem ser considerados pelo sistema em evolução. Cabe ressaltar que como resultado da utilização destas diretrizes podemos obter o Diagrama de Dependências Estratégicas (SD), bem como o diagrama de Razões Estratégicas (SR) em i*.

Diretriz 1 – Análise da entidade externa – Toda entidade externa representada no DFD será modelada como ator na técnica i*. Na figura 3, por exemplo, a entidade externa “Sensores” deve ser modelada como ator em i*.

Diretriz 2. – Analise do Sistema Computacional – Deve-se criar um ator em i* que represente o sistema computacional sendo tratado no processo de evolução. Na figura 3, por exemplo, o “Software Casa Segura” deve ser modelado como ator em i*.

Diretriz 3 – Análise do depósito de dados – No DFD, o depósito de dados tem a finalidade de armazenar dados. Todo depósito de dados no DFD será modelado como dependência do tipo recurso na técnica i*. O depósito de Dados “Informação de Configuração”, por exemplo, será modelado como dependência do tipo recurso em i*.

Diretriz 4 - Análise do processo – Um processo no DFD representa uma função ou transformação da informação que está inserida dentro dos limites do sistema a ser


54

modelado. Portanto, o processo tem o objetivo de transformar uma entrada em uma saída. Em virtude disso, esta função ou transformação pode ser entendida como um objetivo ou uma tarefa a ser realizada pelo sistema.

Diretriz 4.1 – Transformando processo em dependência do tipo objetivo – Quando a obtenção da meta representada por determinado processo do DFD pode ser satisfeita de formas distintas pelo dependee, este processo é modelado na técnica i* através da dependência do tipo objetivo. Isto ocorre porque na técnica i* os objetivos são alcançados sem necessariamente o depender conhecer a forma como a meta será satisfeita pelo dependee. Na figura 4, por exemplo, temos o processo “Gerar Sinal de Alarme”, que gera a dependência do tipo objetivo em i* de mesmo nome. Diretriz 4.2 – Transformando processo em dependência de tarefa – Quando a obtenção da meta representada por um processo é satisfeita de forma particular, modela-se o processo na técnica i* através da dependência do tipo tarefa. Isso ocorre porque na técnica i*, a tarefa é realizada de uma forma conhecida e pré-determinada. O processo “Discar o Telefone” da Figura 4, por exemplo, deve ser modelado como dependência do tipo tarefa em i*.

Diretriz 5 – Analisando a descrição do fluxo de dados – a descrição do fluxo de dados no DFD deve ser analisada conforme segue:

Diretriz 5.1 – Transformando a descrição de fluxo de dados em dependência do tipo recurso – Quando a descrição do fluxo de dados estiver relacionada com a disponibilidade da informação, é necessário criar uma dependência do tipo recurso na técnica i*. Isto ocorre porque na técnica i* a dependência do tipo recurso está associada a disponibilidade de informação. Na figura 4, temos como exemplo, o fluxo de dados “Estado do Sensor”, que será transformado em uma dependência do tipo recurso em i*. Diretriz 5.2 - Transformando a descrição de fluxo de dados em dependência do tipo tarefa – Quando a descrição do fluxo de dados estiver relacionada com a realização de alguma tarefa e a obtenção da mesma é satisfeita de forma particular, este fluxo de dados pode ser mapeado para uma dependência do tipo tarefa na técnica i*. Na figura 4, o fluxo de Dados “Tons do numero do Telefone” deve ser mapeado para a dependência do tipo tarefa em i* de mesmo nome. Diretriz 5.3 - Transformando a descrição de fluxo de dados em dependência do tipo objetivo – Quando a descrição do fluxo de dados estiver relacionada com a realização de algum objetivo e a obtenção do mesmo pode ser levada a cabo de várias formas, este fluxo gera uma dependência do tipo objetivo na técnica i*. Na figura 4, por exemplo, temos que o fluxo de dados “Identificação tipo e Localização do Sensor” será mapeado para a dependência do tipo objetivo em i*.

Diretriz 6 – Investigar e Enriquecer o Modelo SD – A fim de investigar e enriquecer com novas dependências o modelo SD gerado podemos realizar alguns questionamentos tais como:

• Quais são as pré-condições para a obtenção deste objetivo/tarefa/recurso? • Quais são as pós-condições deste objetivo/tarefa/recurso? • As respostas para estas perguntas podem gerar dependências a serem

adicionadas ao modelo organizacional. Diretriz 7 – Investigar o Pseudo-Código para Decomposição de Tarefas no

Modelo SR – Como no último nível de um DFD podemos encontrar o pseudo-código de cada processo, essa informação pode ser usada na construção do modelo de Razões Estratégicas em i*. Cada descrição de pseudo-código dos processos no último nível de um DFD contém os passos necessários e que devem ser realizados na obtenção do


55

processo. Estes passos podem gerar a decomposição das dependências no modelo de Razões Estratégicas. Esta diretriz está em evolução e neste trabalho não será aplicada.

4 Aplicando a Proposta a um Estudo de Caso Para o estudo de caso aplicaremos as diretrizes propostas ao DFD do Software Casa Segura apresentado na seção anterior. Cabe salientar, que devido a questões de espaço, neste artigo aplicaremos as diretrizes apresentadas na seção anterior ao DFD de contexto expresso na figura 3 e ao DFD nível 2 associado apenas ao processo “Monitorar Sensores”. Segue abaixo a aplicação das diretrizes, bem como o modelo SD gerado.

Diretriz 1: Observando a figura 3 podemos verificar a existência das entidades externas, “Painel de Controle”, ”Sensores”, “Mostrador do Painel de Controle”, “Alarme”, “Linha Telefônica”. Cada uma destas entidades é mapeada para um ator de mesmo nome na técnica i*.

Diretriz 2: Na figura 3 verificamos que a entidade externa “Software Casa Segura” representa o sistema computacional que está sendo evoluído. Assim, este ator mapeado para o ator “Software Casa Segura” em i* que representa o sistema computacional em evolução.

Diretriz 3: Observando a figura 4, verificamos o Depósito de Dados “Informação de Configuração”, o qual deve ser modelado como dependência do tipo recurso em i*. Isto ocorre porque este Depósito de Dados está relacionado com a disponibilidade da informação e na técnica i* isto é expresso através de uma dependência do tipo recurso.

Diretriz 4.1: Verificamos na figura 4 que temos dois processos que são satisfeitos de forma distinta: “Gerar Sinal de Alarme” e “Avaliar com base na Configuração”. Em i*, as dependências do tipo objetivo podem ser satisfeitas de várias formas. Como esses processos podem ser obtidos de formas distintas, cada um dos mesmos será modelado como uma dependência do tipo objetivo em i*.

Diretriz 4.2: Na figura 4 podemos observar quatro processos que são obtidos de uma forma bastante específica: “Ler Sensores”, “Discar o Telefone”, “Formatar Para Exibir” e “Mostrar Mensagens e Estados”. Estes processos são mapeados para dependências do tipo tarefa de mesmo nome em i*.

Diretriz 5.1: Podemos também observar na figura 4 três fluxos de dados: “Estado do Sensor”, “Dados de Configuração”, e “Informação do Sensor”, que estão associados a disponibilidade de informações. Na modelagem em i*, as dependências do tipo recurso representam a necessidade de obtenção de informação e por isso os fluxos observados são mapeados para dependências do tipo recurso e mesmo nome em i*.

Diretriz 5.2: Na figura 4 verificamos também que os fluxos de dados “Identificação Tipo e Localização do Sensor”, “Numero de Telefone”, “Tons do número de Telefone” representam a obtenção de tarefas de uma forma já determinada. Como em i* uma tarefa é obtida de uma maneira particular, estes fluxos de dados são mapeados para dependências do tipo tarefa em i* com a mesma nomenclatura.

Diretriz 5.3: Na figura 4 também podemos observar os fluxos de dados: “Identificação e Tipo do Sensor”, “Dados de Alarme” e “Tipo de Alarme”, os quais representam a necessidade de obtenção de metas de formas distintas. Como em i* dependências de objetivo são obtidas de formas distintas, temos que esses fluxos de dados devem ser mapeados para dependências do tipo objetivo em i*.

É importante ressaltar que como descrito na figura 5, os atores que participam nas dependências mapeadas a partir dos DFDs explorados são os atores já descobertos via diretriz 1 e 2. Os atores participantes nos relacionamentos foram associados com base no DFD de nível 2 descrito na figura 5, considerando a origem da dependência e quem será


56

responsável pela satisfação da mesma. Por exemplo, observando a dependência do tipo recurso “Informação de Configuração” mapeada a partir do depósito de dados de mesmo nome descrito na figura 4 (ver diretriz 3), podemos observar que quem tem interesse direto na obtenção deste recurso é o ator “Sensores” e quem disponibilizará esta informação é o ator “Software Casa Segura” que representa o sistema computacional em evolução. Assim, o ator “Sensores” depende do ator “Software Casa Segura” para a obtenção do recurso “Informação de Configuração”, conforme expresso na figura 5. Os demais relacionamentos foram modelados utilizando o mesmo raciocínio.

A tabela 1 apresenta um resumo dos elementos em i* gerados a partir da aplicação das diretrizes. O número entre parênteses representa a diretriz que gerou o componente.

Atores

Painel de Controle, Sensores, Mostrador do Painel de Controle, Alarme, Linha Telefônica (1), Software Casa Segura (2) Dependências do tipo Recurso Dependências do Tipo

Tarefa Dependências do Tipo

Objetivo Informação de Configuração(3)

Estado do Sensor(5.1) Dados de Configuração(5.1) Informações do Sensor(5.1)

Dados do Alarme(5.1) Identificação e Tipo do

Sensor(5.3)

Ler Sensores(4.2) Discar o Telefone(4.2)

Formatar Para Exibir(4.2) Identificação tipo e Local do

Sensor(5.2) Número de Telefone(5.2)

Tons do número de Telefone(5.2)

Gerar Sinal de Alarme(4.1)

Avaliar com Base na Configuração(4.1)

Tipo de Alarme(5.3)

Tabela 1. Elementos gerados a partir das diretrizes propostas

Figura 5. Diagrama SD gerado no Estudo de Caso

A figura 5 descreve o modelo SD gerado através da aplicação das diretrizes propostas

na seção 3.1. No modelo SD gerado estão descritos os atores e as dependências entre os


57

mesmos. Estes elementos foram todos derivados a partir da utilização das diretrizes propostas (ver tabela 1). Observando a figura 5, verificamos que o ator “Alarme” depende do ator “Software Casa Segura” pra realizar o objetivo “Gerar Sinal de Alarme”. Verificamos também que o ator “Software Casa Segura” depende do ator “Sensores” para realizar a tarefa “Ler Sensores” e para obter os recursos “Estado do Sensor” e “Identificação e Tipo do Sensor” e do ator “Painel de Controle” para realizar o objetivo “Avaliar Com Base na Configuração” e obter o recurso “Dados de Configuração”. O ator “Sensores” depende do ator “Software Casa Segura” para obter o recurso “Informação de Configuração”, e do ator “Painel de Controle” para realizar a tarefa “Identificação Tipo e Local do Sensor”. O ator “Alarme” depende do ator “Sensores” para alcançar o objetivo “Tipo de Alarme” e para obter o recurso “Dados de Alarme”, e do ator “Software Casa Segura” para alcançar o objetivo “Gerar Sinal de Alarme”. O ator “Mostrador de Painel de Controle” depende do ator “Sensores” para obter o recurso “Informação do Sensor”, e do ator “Painel de Controle” para realizar a tarefa “Formatar para Exibir”. O ator “Linha Telefônica” depende do ator “Software Casa Segura” para realizar as tarefas “Discar o Telefone”, “Numero de Telefone” e “Tons de Numero de Telefone”.

Cabe ressaltar que a partir deste modelo em i*, podemos derivar casos de uso em UML ou diagramas de classes em UML, auxiliando desta forma na construção do software orientado a objetos.

5 Considerações Finais Apresentamos neste artigo inicialmente um breve relato sobre técnicas orientadas a objetivos utilizadas para apoiar o processo de evolução de software em sistemas legados. Dentre estas técnicas, foi dada ênfase ao estudo da técnica i* como forma de modelar os aspectos estratégicos do ambiente organizacional, bem como o impacto que a evolução de um sistema ocasionará no ambiente organizacional e nos atores deste ambiente. Visando apoiar o processo de evolução de sistemas legados, apresentamos um conjunto de diretrizes que permitem derivar o modelo de Dependências Estratégicas em i* a partir de Diagramas de Fluxos de Dados disponíveis como documentação do sistema legado em evolução. Defendemos que o fato de construir um modelo organizacional como primeira tarefa no processo de evolução de sistemas legados traz inúmeras vantagens entre as quais destacamos: a possibilidade de visualizar e conhecer adequadamente todos os relacionamentos intencionais estratégicos do ambiente organizacional no qual o software sendo reconstruído será utilizado, explorar o modelo organizacional criado com os novos requisitos organizacionais, não-funcionais e funcionais a serem satisfeitos; apresentar um modelo que possa servir de base para a modelagem orientada a objetos; utilizar de forma adequada e não única a documentação existente do software legado, evitando perda de informações importantes existentes em modelos tais como Diagramas de Fluxos de Dados; instigar nos stakeholders envolvidos a necessidade de compreender adequadamente o ambiente organizacional antes de proceder a implementação do sistema alvo. Entre os trabalhos relacionados podemos destacar a proposta apresentada em [18] que apresenta o processo de derivação de Diagramas de Casos de Uso a partir de Diagramas de Fluxos de Dados como um meio de apoio à evolução de sistemas legados. É importante salientar que esta proposta não fornece mecanismos que permitam explorar adequadamente novos requisitos organizacionais e aspectos intencionais que devem ser tratados na evolução de sistemas legados. Podemos também citar como trabalhos relacionados as propostas apresentadas em [22] e [28], que apresentam um processo de derivação de Casos de Uso e Diagramas de Classe em UML a partir de i*,


58

respectivamente, apontando meios de apoiar o processo de construção de software orientados a objetos. Cabe ressaltar que a temática associada a evolução de sistemas legados é bastante discutida na literatura da área. Contudo, poucos trabalhos apresentam meios efetivos de reaproveitamento de informações e possibilidade de evolução sistemática utilizando processos de desenvolvimento orientados a objetos. É um fato que muitos sistemas legados devem evoluir para não entrarem em desuso e que esta evolução deve ser tratada de forma sistemática, principalmente se observarmos que muitas informações necessitam e podem ser aproveitadas neste processo de evolução. Um maior cuidado também deve ser observado se atentarmos para o fato de que a evolução destes sistemas está associada, em grande parte, a mudanças na adoção do processo de desenvolvimento, na qual tipicamente passa-se de metodologias estruturadas para metodologias orientadas a objetos como o RUP [29] e baseadas em componentes como Catalysis [30]. Poder evoluir tratando adequadamente os requisitos organizacionais, não-funcionais e funcionais é um desafio que pode ser melhor tratado com a presente proposta. Como trabalhos futuros podemos destacar:

1. Estudar mecanismos para derivar além do modelo SD, também o modelo SR em i*. Estudos em andamento apontam para a viabilidade de explorar o pseudocódigo de Processos em Diagramas de Fluxos de Dados visando derivar o modelo SR.

2. Prover suporte computacional para a proposta apresentada; 3. Integrar esta proposta aos trabalhos [22] e [28] que propõe a derivação da

modelagem orientada a objetos (diagrama de classes ou casos de uso) através da técnica i* e Realizar mais estudos de caso utilizando as diretrizes que foram elaboradas;

6 Referências Bibliográficas 1. ALMEIDA, E. S., LUCRÉDIO, D., ALVARO, A., PRADO, A, F. e TREVELIN, L, C. An

Experimental Study about Distributed Component-Based Software Development. In: SBES’2002, 16th Brazilian Symposium on Software Engineering, Tools Session. (2002).

2. ANTON, A., Goal identification and refinement in the specification of software-based information systems. Phd Thesis, Georgia Institute of Technology, Atlanta, GA, June, (1997).

3. ANTON, A., CARTER, R.A., DAGNINO, A., DEMPSTER, J.H., SIEGE, D.F., “Deriving Goals from a Use Case Based Requirements Specification”, Requirements Engineering Journal, Springer-Verlag, Volume 6, May (2001), pp. 63-73.

4. BENNETT, K. H. e WARD, M. P. Formal Methods for Legacy Systems. Journal of Software Maintenance: Research and Practice, v. 7, n. 3, (1995), p. 203-219.

5. CASTRO, J., KOLP, M. e MYLOPOULOS, J. Towards Requirements-Driven Information Systems Engineering: The Tropos Project, 35 pages, In: Information Systems, Elsevier, Amsterdam, The Netherlands, (2002).

6. CHUNG, L., NIXON, B.A.,YU, E. e MYLOPOULOS, J., Non-Functional Requirements in Software Engineering (Monograph), Kluwer Academic Publishers, 472 pp, (2000).

7. COCKBURN, A., Writing Effective Use Cases, Humans and Technology, Addison-Wesley, (2000).

8. DARDENNE, A., VAN LAMSWEERDE, A. e FICKAS, S., Goal-Directed Requirements Acquisition, Science of Computer Programming, 20, pp. 3-50, (1993).

9. DUBOIS, E. e P. HEYMANS Scenario Based Techniques for supporting the elaboration and the validation of Formal Requirements”, RE Journal (1998).

10. FONTANETE, V. et al., Reengenharia de Sistemas Legados Baseada em Componentes usando Transformações. São Carlos/SP, (2003). Artigo. Universidade Federal de São Carlos.

11. FORWARD, A. e LETHBRIDGE, T. C., The Relevance of Software Documentation, Tools and Technologies: A Survey, DocEng2002, ACM Press, p. 26-33, (2002).


59

12. HAUMER, P., POHL, K. e WEIDENHAU’PT, K. Requirements Elicitation and Validation with Real World Scenes. IEEE Transactions on Software Engineering, Vol. 24, No 12, Special Issue on Scenario Management, December, (1998).

13. JACOBSON, I. Object Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley (1995).

14. JESUS, E. S. Engenharia Reversa de Sistemas Legados Usando Transformações. São Carlos/SP, (2002), Dissertação de Mestrado, Universidade Federal de São Carlos.

15. LEITE, J. C. S. P., SANT’ANNA, M. e GOUVEIA, F., Draco-PUC: A Technology Assembly For Domain Oriented Software Development. Proceedings of ICSR94 (International Conference on Software Reuse), IEEE Press, (1994).

16. LEITE, J.C.S.P., ROSSI, G., BALAGUER, F. e MAIORANA, V., “Enhancing a requirements baseline with scenarios”. In Proceedings of the Third IEEE International Symposium on Requirements Engineering – RE’97, IEEE Computer Society Press, January, (1997), pp. 44-53

17. MYLOPOULOS, J., CHUNG, L. e YU, E. Requirements analysis: from object oriented to goal oriented. Communications of the ACM, 42(1):31–37, (1999).

18. MYLOPOULOS, J. e CASTRO, J., Tropos: A Framework for Requirements-Driven Software Development, In: Brinkkemper, J. and Solvberh, A. (eds), Information Systems Engineering: State of Art and Research Themes, Lectures Notes in Computer Science, Springer-Verlag, June (2000).

19. PAIVA, L., Quebrando Paradigmas na Transição de Metodologias em Sistemas Legados, Cascavel-PR, Brasil, Curso de Especialização, UNIOESTE – Cascavel, (2004).

20. RALYTÉ, J., ROLLAND, C. e PLIHON, V., Method Enhancement With Scenario Based Techniques, In Proceedings of CAISE 99, 11th Conference on Advanced Information Systems Engineering, Heidelberg, Germany, June 14-18, (1999), (CREWS Report Series 99-10).

21. ROLLAND, C., SOUVEYET, C. e ACHOUR, C. B. Guiding Goal Modeling Using Scenarios. IEEE Transactions on Software Engineering, Vol 24, No 12, Special Issue on Scenario Management, December, (1998).

22. SANTANDER, V. F., Integrando Modelagem Organizacional com Modelagem Funcional, Tese de Doutorado, Centro de Informática, Universidade Federal de Pernambuco, Recife, Dezembro, (2002).

23. SANTANDER, V. F., CASTRO, J. F. B., Deriving Use Cases from Organizational Modeling In: IEEE Joint International Requirements Engineering Conference - RE’02, (2002), Essen, Germany.

24. SANTANDER, V. F. A., CASTRO, J. F. B., Developing Use Cases from Organizational Modeling In: IV Workshop de Engenharia de Requisitos, (2001), Buenos Aires, Argentina.

25. SANTANDER, V. F. A., CASTRO, J. F. B. Desenvolvendo Use Cases a partir de Modelagem Organizacional In: III Workshop de Engenharia de Requisitos, (2000), Rio de Janeiro, RJ.

26. TORANZO, M., Uma Proposta para Melhorar o Rastreamento de Requisitos de Software, Tese de Doutorado, Centro de Informática, Universidade Federal de Pernambuco, Recife, Dezembro, (2002).

27. YU, E., Modelling Strategic Relationships for Process Reengineering, Phd Thesis, University of Toronto, (1995).

28. PEDROZA, F. P. ; ALENCAR, F. M. R. ; SANTANDER, V. F. A. ; CASTRO, J. F. B. ; SILVA, F. R. C. Ferramentas de Suporte ao Mapeamento da Modelagem i* para a UML: eXtended GOOD e GOOSE. In: VII Workshop on Requirements Engineering, December, 9-10, 2004, Tandil, Argentina. Proceedings of the VII Workshop on Requirements Engineering. Buenos Aires : Grupo Editor Tercer Milenio S.A, 2004. v. 1. p. 167-175.

29. JACOBSON, I., BOOCH, G., RUMBAUGH, J., The Unified Software Development Process, Addison-Wesley (1999).

30. D'SOUZA , DESMOND, F., A.C. Wills, Objects, Components and Frameworks with UML: The Catalysis Approach, Addison-Wesley, November, (1998).

31. GANE, C.; SARSON, Trish. Análise Estruturada de Sistemas. LTC, Rio de Janeiro, 1983. 32. PRESMANN, R. Engenharia de Software . McGraw-Hill , 6a ed, São Paulo, 2006.


60

Sesión 3 Medición y Experimentación

61

Validando la Usabilidad y Mantenibilidad de los Modelos de Procesos de Negocio: un Experimento y su

Réplica

Elvira Rolón1, Félix García2, Francisco Ruiz2, Mario Piattini2

1 Facultad de Ingeniería Arturo Narro Siller, Universidad Autónoma de Tamaulipas Centro Universitario Tampico-Madero, 89336 Tamaulipas, México

[email protected]

2 Departamento de Tecnologías y Sistemas de Información Centro Mixto de Investigación y Desarrollo de Software UCLM-Soluziona

Universidad de Castilla-La Mancha, Paseo de la Universidad 4, 13071, Ciudad Real, España.

{Felix.Garcia, Franscisco.RuizG, Mario.Piattini}@uclm.es

Resumen. De cara a promover la mejora continua de los modelos de procesos de negocio así como de facilitar la evaluación temprana de ciertas propiedades de calidad del modelo, se ha definido un conjunto de medidas para evaluar la complejidad estructural de dichos modelos. En este artículo se presenta la validación de las medidas propuestas mediante dos experimentos realizados con alumnos de la Universidad de Castilla-La Mancha en España, y de la Universidad Autónoma de Tamaulipas en México. Con la realización del primer estudio empírico fue posible conocer el conjunto de medidas útiles para evaluar la usabilidad y la mantenibilidad de modelos conceptuales de procesos de negocio. El segundo experimento fue una réplica del primero y nos permitió corroborar y validar los resultados del primer estudio.

Palabras clave: Procesos de Negocio, Modelado, Medición, Validación

1 Introducción

El modelado de procesos de negocio ha ganado una amplia aceptación en la última década como una valiosa técnica de diseño y gestión para una variedad de propósitos. Así mismo, con el surgimiento de nuevas y diferentes propuestas para la gestión de los procesos de negocio (PN), se han propiciado dos importantes aspectos relacionados a los requisitos de los modelos de procesos [1]: 1. Que se haya incrementado considerablemente la cantidad y variedad de usuarios y diseñadores de modelos y, 2. que se haya incrementado la cantidad y variedad de los propósitos para los cuales son usados los modelos de procesos.

Uno de los primeros pasos en el logro de las metas de las organizaciones es el modelado de PN, que desde el punto de vista empresarial pretende los siguientes


63

objetivos [2]: a) Mejorar el entendimiento de una situación y comunicarla entre los diversos stakeholders y, b) Utilizarlos como una herramienta para alcanzar las metas de un proyecto de proceso de desarrollo.

Esta importancia de los procesos de negocio y su modelado, también ha generado interés en la comunidad científica en lo referente a su estudio, análisis y medición. Sin embargo, hasta ahora en la literatura existen pocos estudios relacionados con la medición y evaluación de los PN, al menos en un nivel conceptual como es nuestro tema de estudio. Uno de los trabajos relacionados al tema de medidas de complejidad para modelos de PN, es el presentado por Gruhn y Laue [3], en donde discuten cómo las ideas conocidas en la investigación acerca de la complejidad del software, pueden ser usadas para analizar la complejidad de los modelos de procesos de negocio. En base a la idea de que al medir el peso cognitivo del modelo de proceso de negocio (MPNs), se puede obtener información acerca de la facilidad o dificultad de comprenderlo, asignan un peso cognitivo a los elementos del MPN, para posteriormente definir el peso cognitivo del modelo en su totalidad.

Otro trabajo es el presentado por Cardoso [4] en donde describe una medición para analizar la complejidad de los flujos de control de procesos Web y flujos de trabajo (Workflows). Sin embargo, esta medición es empleada en el tiempo de diseño para evaluar la complejidad del diseño de un proceso antes de su implementación.

En cambio, nuestro interés se centra en la fase de diseño del proceso, mediante la cual se facilita la visualización de las tareas que se llevan a cabo dentro de una organización. Al hablar de la fase de diseño, nos referimos al modelado, manipulación y rediseño de los procesos, en donde incluso llega a ser necesario el efectuar tareas de mantenimiento lo que puede convertir esta fase en una de las más complicadas dentro del ciclo de vida del proceso, al requerir inversión de tiempo y recursos de dos ámbitos diferentes: los desarrolladores técnicos y los analistas de negocio.

Teniendo en cuenta lo anterior, este trabajo se enfoca en la evaluación de la complejidad estructural de los MPNs en un nivel conceptual. Con esto se pretende dar soporte a la gestión de los PN facilitando la evaluación temprana de ciertas propiedades de calidad de los modelos. Además, esto facilitaría la evolución de los MPNs al proporcionar información subjetiva acerca de su mantenibilidad.

El punto de partida para este estudio ha sido la definición de medidas para modelos de procesos de negocio expresados con la notación estándar BPMN (Business Pro-cess Modeling Notation) [5]. Para validar las medidas propuestas, actualmente se esta llevando a cabo una familia de experimentos con una población integrada por exper-tos en análisis de negocios y en ingeniería del software. Esto nos permitirá comparar los resultados de ambos tipos de perfiles.

El artículo contiene los siguientes apartados: en la sección 2 se presenta una reseña de las medidas que hemos definido. En la sección 3 se describe el diseño experimental bajo el cual fueron llevados a cabo los dos primeros experimentos. En la sección 4 se muestra el análisis de los resultados obtenidos a partir de los datos recopilados en ambos experimentos. En la sección 5 se describen cuales fueron las amenazas a la validez en la realización de los estudios empíricos, y finalmente en la sección 6 se plantean las conclusiones y el trabajo por realizar a futuro.


64

2 Medidas para Procesos de Negocio

Con el objetivo de evaluar la complejidad estructural y conocer de forma objetiva cual es la mantenibilidad de los modelos de procesos de negocio (MPNs), se ha definido un conjunto de medidas siguiendo la terminología de la notación BPMN 2.0 [5]. Los términos utilizados en este trabajo en cuanto a la medición de modelos de procesos de negocio, se basa en la Ontología de la Medición del Software definida por García et al. [6]. De este modo, el conjunto de medidas definidas han sido agrupadas en dos categorías: • Medidas base, que consisten principalmente en contar los elementos significativos

del modelo de proceso de negocio, y de las cuales se ha definido un total 46 medidas base en función de los principales elementos que componen en metamodelo BPMN.

• Medidas Derivadas, que han sido definidas a partir de las medidas base, permiten conocer las proporciones existentes entre los diferentes elementos del modelo. Este grupo esta compuesto por un total de 14 medidas. En primera instancia, la definición de las medidas nos permitió investigar la

relación entre la complejidad estructural y la mantenibilidad como atributo externo de dichos modelos. Al efectuar la validación teórica de las medidas definidas bajo el marco de Briand et al. [7], fue posible agruparlas de acuerdo a diferentes propiedades de la complejidad estructural (Figura 1).

Fig. 1. Relación entre la complejidad estructural y los atributos de calidad

En [8] se puede obtener una descripción más detallada de las medidas propuestas así como un ejemplo que ilustra su cálculo.


65

3 Diseño Experimental

Con el objetivo de establecer qué medidas son útiles para evaluar la entendibilidad y mantenibilidad de los MPNs, se ha iniciado el desarrollo de una familia de experimentos, que además nos permitirá evaluar aspectos de calidad de modelos conceptuales de procesos de negocio expresados con BPMN. En el contexto de la familia se han llevado a cabo los dos primeros experimentos que nos han permitido obtener las primeras conclusiones sobre la validez empírica de las medidas, habiéndose seleccionado un conjunto representativo del total de las medidas definidas para MPNs.

El diseño experimental utilizado fue el mismo para ambos estudios, ya que una vez realizado un primer experimento, se realizó una replica del mismo con la finalidad de corroborar los resultados obtenidos

Inicialmente a los sujetos se les dio una sesión de introducción sobre el modelado de procesos de negocio y del metamodelo BPMN, además de una sesión de entrenamiento para proporcionarles a los participantes el conocimiento necesario para llevar a cabo las tareas requeridas en el experimento.

En ambos experimentos se realizó un diseño intra-sujetos, en el que todos los sujetos tenían que contestar a todos los test. A cada sujeto le fue entregada una selección de diez MPNs los cuales les fueron dados en diferente orden. Al repartir el material ya descrito a los sujetos, se hizo una breve explicación de cómo rellenar los test, indicándoles que no había límite de tiempo para la realización de los mismos y que en caso de duda podían preguntar al responsable de la organización del experimento.

Una visión general del diseño de los experimentos se puede observar en la Fig. 2.

Fig. 2. Diseño Experimental


66

Una descripción más detallada tanto de las medidas definidas como del diseño experimental se puede consultar en [8], donde además se presentan algunos ejemplos del material experimental utilizado. A continuación se resumen los aspectos más significativos.

3.1 Objetivo

Siguiendo la plantilla GQM [9], el objetivo del primer experimento y su réplica fue: - Analizar medidas de complejidad estructural para modelos

de procesos de negocio - Con el propósito de evaluarlas - En relación a la capacidad de ser usadas como indicadores de la

entendibilidad y la modificabilidad de dichos modelos,

- Desde el punto de vista de los investigadores - En el contexto de estudiantes, becarios de investigación y profesores

de ingeniería en informática (primer experimento) y estudiantes de un master en informática (réplica).

3.2 Material

El material estaba compuesto por diez MPNs expresados con BPMN. Cada modelo tenía un diferente grado de complejidad, obtenidos variando el valor de las medidas tal como se puede apreciar en la Tablas 1 y 2. La intención al elegir modelos de dimensiones distintas, fue la de determinar la influencia de la complejidad del modelo para diferentes usuarios como pueden ser los analistas de negocios y los ingenieros de software, en quienes particularmente esta enfocado el objetivo de nuestro estudio. Para cada modelo se elaboraron dos cuestionarios: en el primero de ellos se pidió responder a una serie de cinco preguntas relacionas a la entendibilidad del modelo, y en el segundo se propuso una serie de modificaciones a realizar en el modelo. Además, al final de cada cuestionario se incluyó una pregunta para que los sujetos evaluaran de acuerdo a su opinión la complejidad de los modelos presentados. El material también incluía un ejemplo resuelto en el cual se indicaba la forma en que debían realizarse los ejercicios.

Tabla 1. Valores de las medidas base


67

Tabla 2. Valores de las medidas derivadas

3.3 Sujetos

En los dos experimentos realizados los sujetos seleccionados tenían una experiencia similar en el modelado de procesos. A pesar de ello, les fue impartida la sesión de entrenamiento, sin que con ello fueran conscientes de los aspectos que intentábamos analizar. El grupo de participantes en el primer experimento estuvo formado por 27 sujetos entre estudiantes de doctorado, becarios de investigación y profesores de la Escuela Superior de Informática de la Universidad de Castilla-La Mancha de Ciudad Real, España.

El grupo de participantes en el segundo experimento estuvo formado por 31 sujetos estudiantes del Master en Sistemas de Información que se imparte en la División de Estudios de Posgrado e Investigación de la Facultad de Ingeniería Arturo Narro Siller, en la Universidad Autónoma de Tamaulipas en México. El perfil de los participantes corresponde a diferentes áreas entre las que destacan principalmente: Ingeniería en Informática, Licenciatura en Informática Administrativa e Ingeniería Industrial.

Cada sujeto recibió un material compuesto por diez MPNs, cinco de ellos con cuestionarios de preguntas sobre el modelo y los otros cinco con ejercicios de modificaciones. En el caso de los cuestionarios relativos a la entendibilidad del modelo los sujetos debían responder “si” ó “no” a las seis cuestiones listadas, y en el caso del cuestionario de modificabilidad debían llevar a cabo cinco modificaciones consistentes en adicionar y/o eliminar tareas, objetos de datos, roles o dependencias entre elementos. Antes de iniciar las tareas solicitadas en cada cuestionario, se pidió a los sujetos que escribieran la hora de inicio, y al término de la realización de las tareas solicitadas también se les pidió escribieran la hora de finalización. Al final de cada cuestionario los sujetos evaluaron subjetivamente la complejidad en una escala de 5 valores.

3.4 Variables e Hipótesis

Las variables independientes son las distintas medidas base y derivadas definidas que evalúan la complejidad estructural de los MPNs. Las variables dependientes son las relativas a las dos subcaracterísticas de calidad: la entendibilidad y la modificabilidad de los MPNs, las cuales fueron medidas a través de los tiempos de respuesta empleados por los sujetos para llevar a cabo las tareas requeridas, así como de los


68

aciertos a las cuestiones relacionadas a las tareas de entendimiento y de los aciertos en las tareas de modificación.

Las hipótesis planteadas acorde al objetivo de nuestra investigación son las siguientes:

• Hipótesis nula, H0u: No hay una correlación significativa entre las medidas de complejidad estructural y el tiempo de entendibilidad.

• Hipótesis alternativa, H1u: Hay una correlación significativa entre las medidas de complejidad estructural y el tiempo de entendibilidad.

• Hipótesis nula H0m: No hay una correlación significativa entre las medidas de complejidad estructural y el tiempo de modificabilidad.

• Hipótesis alternativa, H1m: Hay una correlación significativa entre las medidas de complejidad estructural y el tiempo de modificabilidad.

4 Resultados

Para realizar el análisis de los datos obtenidos de los dos experimentos, una vez que éstos fueron recogidos de las hojas de respuestas, se controló que estuvieran completas y se revisaron los aciertos en las respuestas así como los tiempos empleados para la realización de cada ejercicio. En el caso del primer experimento los cuestionarios de los 27 sujetos participantes estuvieron completos en cuanto a la realización de las tareas solicitadas. En cambio, en el segundo experimento se contó con la participación de un total de 35 sujetos, pero al revisar los aciertos en las respuestas se encontraron 4 de ellos incompletos, ya que solo habían respondido los cuestionarios de entendibilidad, sin dar respuesta a las tareas de modificabilidad. Considerando que esto podría afectar en el análisis de los resultados, se decidió descartarlos del experimento, por lo que solo se analizaron los datos de 31 sujetos.

4.1 Análisis Descriptivo

Al efectuar el análisis e interpretación de los datos recogidos, intentamos comprobar las hipótesis formuladas en el apartado 3.4, para lo cual inicialmente se realizó un resumen con las estadísticas descriptivas de tales datos (Tabla 3). Este resumen está compuesto por los valores de las medidas para cada modelo de proceso de negocio (Tablas 1 y 2), por las medianas de las puntuaciones dadas por los sujetos a las dos subcaracterísticas analizadas, así como por la media de los tiempos de entendibilidad y modificabilidad en cada modelo.

En cuanto a los resultados del primer experimento, se puede ver en la Tabla 3 que en relación a los tiempos de entendibilidad los modelos 5, 6 y 10 fueron los mas difíciles de entender por los sujetos, mientras que los modelos 2, 7 y 9 resultaron con mayor complejidad a la hora de llevar a cabo tareas de mantenimiento, en este caso al efectuar las modificaciones solicitadas. Al analizar los valores de las desviaciones estándar, se puede ver que hay una variación, ya que los modelos 6, 8 y 10 presentan una desviación estándar más alta para el caso de la entendibilidad, mientras que los


69

modelos 1, 2 y 5 son los que presentan mayor desviación estándar para las tareas de modificabilidad.

Tabla 3. Promedios y Desviación Estándar para tiempos de entendibilidad y modificabilidad

De los resultados obtenidos a partir del segundo experimento, en la tabla 3 se observa que han sido los modelos 5, 9 y 10 los más difíciles de entender por los sujetos, y que los modelos 4, 7 y 10 fueron los de mayor complejidad a la hora de llevar a cabo las modificaciones solicitadas. Respecto al resultado de la desviación estándar existe una gran variación para el caso de la entendibilidad, al ser los modelos 1, 6 y 7 los que presentan la desviación más alta, mientras que en el caso de las tareas de mantenimiento son los modelos 4, 6 y 10 los que presentan mayor desviación estándar.

Al analizar estos resultados y considerando también los valores de las medidas presentadas en las Tablas 2 y 3, los modelos 7, 9 y 10 parecen ser los modelos con mas alta complejidad estructural lo cual proporciona alguna evidencia acerca de la influencia de la complejidad estructural de los modelos de procesos de negocio en su mantenibilidad.

En cuanto al resultado de la valoración subjetiva (Tabla 4) acerca de la complejidad de los modelos presentados y de acuerdo a la escala utilizada, los sujetos del primer experimento consideraron que en el caso de la entendibilidad casi todos los modelos son de complejidad normal, excepto los modelos 2, 3 y 4 que fueron calificados como de complejidad “algo simple”. En lo relativo a la valoración subjetiva de los modelos en los que debieron hacer tareas de modificación, los modelos 7 y 10 fueron puntuados con una complejidad mayor, siendo considerados como “algo complejos”. El resto de los modelos fueron valorados de complejidad “algo simple” y “normal”.

A diferencia, en los resultados de la valoración subjetiva obtenidos en el segundo experimento, los sujetos consideraron que son cinco los modelos que tienen complejidad “algo simple” siendo estos los modelos 1, 2, 7, 8 y 10, mientras que el resto de modelos fueron valorados de complejidad “normal”. Referente a la valoración subjetiva de los modelos para las tareas de modificación los sujetos consideraron que los modelos 5, 7 y 10 son “algo complejos” y el resto de complejidad “normal”. En esta última valoración existe una similitud en los resultados del primer experimento en cuanto a la complejidad de los modelos 7 y 10.


70

Tabla 4. Resultados de la valoración subjetiva de los modelos

De igual forma, al comparar estos resultados con los tiempos relacionados a las tareas de entendibilidad y modificabilidad, existe una coincidencia en los modelos 7 y 10, los cuales aparecen como algunos de los modelos que presentan mayor complejidad.

4.2 Análisis Estadístico

A partir del resumen de los promedios en los tiempos de entendibilidad y de modificabilidad, así como el resumen de los valores de las medidas fue posible realizar un análisis estadístico. Inicialmente se efectuó un análisis de correlación de los valores de las medidas con respecto a los tiempos de respuesta y al número de aciertos de los resultados obtenidos en ambos experimentos, el cual se llevó a cabo siguiendo las sugerencias de Perry et al. [9], Wholin et al. [10], Juristo y Moreno [11], Ciolkowski et al. [12] y Briand et al. [13].

Para comprobar si la distribución de los datos obtenidos era normal, se aplicó el test de Kolmogorov-Smirnov. Como resultado de ello se obtuvo que la distribución era no normal, por lo que se decidió utilizar un test estadístico no paramétrico como el coeficiente de correlación de Spearman con un nivel de significación α = 0.05 lo cual indica la probabilidad de rechazar la hipótesis nula cuando es cierta (error de tipo I), es decir, el nivel de confianza es del 95%.

Usando el coeficiente de correlación de Spearman cada una de las medidas fue correlacionada separadamente con los tiempos de entendibilidad y modificabilidad. En la Tabla 5 se muestran los resultados del análisis de correlación del primer experimento para los tiempos de entendibilidad, tiempos de modificabilidad, los aciertos en las tareas de entendibilidad y modificabilidad, así como de la valoración subjetiva de los modelos en ambos ejercicios.

En los resultados del análisis estadístico a partir de los datos obtenidos en el primer experimento que se muestran en la Tabla 5, se puede ver que existe una correlación (rechazando la hipótesis H0u) entre los tiempos de entendibilidad y las medidas NEDDB, NSFE, TNE, NIMsE, NEMsE, y TNIE. Sin embargo respecto al tiempo empleado por los sujetos en la modificabilidad de los diagramas, el análisis de correlación no arrojó ningún resultado (aceptando la hipótesis H0m), por lo que ninguna medida tiene correlación con dicha variable. Considerando que no existe


71

ninguna correlación de las medidas definidas con respecto a los tiempos de modificabilidad, en futuros experimentos este aspecto será tomado en cuenta a la hora de refinar el material experimental.

Tabla 5. Resultados del análisis de correlación de Spearman (primer experimento)

En relación a los aciertos en las tareas de entendibilidad y modificabilidad, existe una correlación entre los aciertos de entendibilidad y las medidas NT, TNSE, TNT, NSFA, y PDOTOut. Así mismo, existe una correlación entre los aciertos en los ejercicios de modificación de los modelos y las medidas TNSE, NDOIn, NDOOut, y TNDO.

Finalmente, en cuanto a las valoraciones subjetivas que los sujetos hicieron de los modelos, existe una correlación entre la entendibilidad y las medidas NSFE, TNE, TNA y CLA, y una correlación entre la modificabilidad y las medidas NT, NSFE, NSFL, TNEE, TNE, TNT, TNA y NENE. De este análisis se puede resumir que las medidas que presentan dos o mas correlaciones con las variables analizadas son las medidas: NT, NSFE, TNSE, TNE, TNT y TNA.

De igual forma en el segundo experimento se aplicó el test de Kolmogorov-Smirnov el cual reveló que los datos recogidos tenían una distribución no-normal, por lo que también se utilizó el test estadístico no paramétrico de coeficiente de correlación de Spearman con un nivel de significancia de α=0.05. Los resultados obtenidos se muestran en la Tabla 6.

De acuerdo a los resultados mostrados en la Tabla 6, existe una correlación (rechazando la hipótesis H0u) entre los tiempos de entendibilidad y las medidas NT, NSFE, TNSE, TNEE, TNE, TNT y TNA. Con respecto al tiempo empleado por los sujetos en la modificabilidad de los diagramas, el análisis de correlación indica a diferencia de los resultados obtenidos en el primer experimento que las medidas CLA, NCS, NEDEB, NSFG, TNCS, y TNG tienen correlación con dicha variable (rechazando la hipótesis H0m).


72

Tabla 6. Resultados del análisis de correlación de Spearman (segundo experimento)

En relación a los aciertos en las tareas de entendibilidad y modificabilidad, existe una correlación entre los aciertos de entendibilidad y las medidas NSNE, TNSE, y CLA. Así mismo, existe una correlación entre los aciertos en los ejercicios de modificación de los modelos y las medidas TNEE y TNE.

Finalmente, en cuanto a las valoraciones subjetivas que los sujetos hicieron de los modelos, en el caso de la entendibilidad no existe correlación con ninguna de las medidas. Este resultado varió en relación a los resultados obtenidos en el primer experimento en donde 4 de las medidas presentan una correlación con dicha variable. Por último, se observa que existe una correlación entre la modificabilidad y las medidas NEDDB, NSFL, TNEE, TNE, NSFG, y TNG.

Al comparar los resultados obtenidos en ambos experimentos, se observa que en ambos casos hay un total de 10 medidas que mantienen correlación con las variables analizadas siendo estas: NT, NEDDB, NSFE, NSFL, TNSE, TNEE, TNE, TNT, TNA y CLA.

5 Amenazas de la Validez

Los principales problemas que amenazaron la validez de los estudios empíricos realizados fueron: • Validez Interna. Como parte del experimento, se controlaron las siguientes

variables: • Características de los participantes. El uso de un diseño intra-sujetos minimizó

el posible riesgo de diferencias entre los sujetos. • Complejidad de las tareas. Las tareas experimentales fueron equivalentes en

complejidad para cada grupo de modelos experimentales (entendibilidad y mantenibilidad).


73

• Instrumentación. Se usaron las mismas técnicas de medición para las variables dependientes e independientes para todos los participantes. El riesgo de error en la medición fue reducido por el cálculo automático de todos los valores.

• Capacitación. A todos los participantes les fue impartida una sesión de preparación previa y recibieron los conocimientos necesarios para llevar a cabo adecuadamente el experimento. En ambos experimentos, esta sesión introductoria fue impartida por la misma persona y utilizando el mismo material, por lo que la formación recibida previa al experimento fue la misma para los dos grupos de sujetos participantes.

• Efectos de aprendizaje. Los modelos experimentales fueron entregados a los sujetos en un orden aleatorio y solo un tipo de tarea (entendibilidad ó modificabilidad) fue requerida en cada modelo para minimizar los efectos de aprendizaje y secuencia.

• Control del entorno. Este hecho no afectó la validez interna ya que el experimento se llevó a cabo bajo condiciones controladas en el que los participantes fueron supervisados por los encargados del experimento.

• Efectos de fatiga. El tiempo promedio de la duración del experimento fue de 40 minutos por lo que se evitaron los efectos de fatiga.

• Error en la medición. Otra amenaza a la validez interna es el hecho de que los sujetos eran responsables de registrar los tiempos empleados en la realización de las tareas. Esto incrementa el riesgo de error en la medición para la variable dependiente, ya que los sujetos podían quizás haber registrado los tiempos de forma incorrecta. El diseño intra-sujetos ayudó a minimizar esta amenaza porque el posible error de medición podría distribuirse aleatoriamente a través de los niveles de la variable independiente. Además, un reloj digital fue proyectado en la pizarra durante la ejecución de los experimentos para facilitar a los participantes anotar tiempos exactos.

• Validez externa. Se identificaron tres posibles amenazas a la validez externa del estudio empírico: • Los modelos experimentales. En ambos experimentos se utilizaron algunos

modelos de procesos de negocio encontrados en la literatura y otros representativos de casos reales, pero para futuros estudios empíricos se deben utilizar modelos de procesos de negocio reales.

• Las tareas experimentales. Los tipos de tareas a realizar en los modelos fueron diseñados para lograr los objetivos de la investigación, pero estas deberían ser adaptadas a situaciones reales en la práctica.

• Población muestral. Una clara amenaza a la generalidad de los resultados de este estudio fue el tipo de sujetos experimentales y el background de cada grupo participante considerando que estos fueron de distintos países. Sin embargo, la población seleccionada para los experimentos fueron estudiantes de maestría, estudiantes de doctorado y profesores, lo cual reduce la posibilidad de generalizar los resultados en la práctica. De cualquier forma, esta amenaza se espera reducir en un futuro, al realizar nuevos estudios empíricos con una población formada por gente del ámbito empresarial.


74

6. Conclusiones y Trabajo Futuro

En este trabajo, se han presentado los resultados de dos experimentos realizados con estudiantes de doctorado, becarios y profesores de la Escuela de Informática de la Universidad de Castilla-La Mancha y con estudiantes de la Master en Sistemas de Información de la Universidad Autónoma de Tamaulipas en México. El objetivo en la realización de estos experimentos fue el de analizar y evaluar la complejidad estructural de los modelos de proceso de negocio en un nivel conceptual a partir de un conjunto de medidas que han sido definidas en base a la notación estándar BPMN.

Así mismo, con la realización de la familia de experimentos se pretende analizar atributos de la calidad del modelo tales como la usabilidad y la mantenibilidad, con lo cual se estaría proporcionando el soporte necesario a la hora de llevar a cabo las tareas de mantenimiento de los modelos de proceso de negocio.

Como resultado de estudios empíricos realizados fue posible saber que, del total de medidas definidas, diez de ellas tienen correlación con las variables analizadas que fueron los tiempos de entendibilidad, tiempos de modificabilidad, aciertos de entendibilidad y modificabilidad, así como en la valoración subjetiva acerca de la complejidad de los modelos.

En cuanto al trabajo por realizar se tienen contemplados los siguientes aspectos: • En la realización de nuevos experimentos, se pretende analizar dos

subcaracterísticas más de la calidad del modelo como son la analizabilidad y la facilidad de aprendizaje, las cuales están relacionadas a la usabilidad y a la mantenibilidad del modelo, respectivamente.

• En el contexto de la familia de experimentos se tiene previsto realizar un nuevo diseño experimental con el fin de confirmar si las medidas no validadas en estos primeros experimentos pueden ser útiles para evaluar la usabilidad y mantenibiblidad de los MPNs, o son candidatas a ser descartadas. Para ello se llevará a cabo un nuevo experimento con estudiantes del Master Universitario en Tecnología del Software, en la Universidad del Sannio (Benevento, Italia).

• Adicionalmente, se iniciará el desarrollo de los modelos de procesos de negocio de una empresa del sector salud, lo que nos permitirá en estudios futuros, utilizar modelos experimentales de casos reales. De igual forma se tiene programada la realización de un nuevo experimento en el que participarán empleados de esta empresa, con lo cual podremos comparar los resultados hasta ahora obtenidos con la gente del área de ingeniería del software.

Agradecimientos. Este trabajo ha sido parcialmente financiado por los proyectos ENIGMAS (Junta de Comunidades de Castilla-La Mancha, Consejería de Educación y Ciencia, referencia PBI-05-058), ESFINGE subvencionado por el Ministerio de Educación y Ciencia (Dirección General de Investigación)/Fondos Europeos de Desarrollo Regional (FEDER), referencia TIN2006-15175-C05-05 y COMPETISOFT (Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo, referencia 506AC0287).


75

Referencias

1. Becker, J., Rosemann M., and von Uthmann, C. Guidelines of Business Process Modeling. Business Process Management, Models, Techniques and Empirical Studies. (2000) Springer-Verlag.

2. Multamäki, M., Objective-Driven Planning of Business Process Modeling. Department of Industrial Engineering and Management. Helsinki University of Technology. (2002),

3. Gruhn, V. and Laue, R. Complexity Metrics for Business Process Models. Proceedings of 9th International Conference on Business Information Systems (BIS´06). Klagenfurt, Austria. (2006)

4. Cardoso, J., How to Measure the Control-flow Complexity of Web Processes and Workflows, Workflow Handbook, WfMC, Editor. Lighthouse Point, FL, USA. (2005) 199-212.

5. OMG, Business Process Modeling Notation. Object Management Group. (2006) 6. Garcia, F., Bertoa, M. F., Calero, C., et al., Towards a Consistent Terminology for

Software Measurement. Information and Software Technology, (2006). 48(8) 631-644. 7. Briand, L., Morasca, S., and Basili, V. Property-Based Software Engineering Measurement.

IEEE Transactions on Software Engineering, (1996). 22(1) 68-86. 8. Rolón, E., Ruiz, F., García, F., Piattini, M. Métricas para la Evaluación de Modelos de

Procesos de Negocio. 9º Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software (IDEAS´06). La Plata, Buenos Aires, Argentina. (2006) 419-432

9. Perry, D., Porte, A. and Votta, L. Empirical Studies of Software Engineering: A Roadmap. Future of Software Engineering, (2000) 345-355.

10. Wohlin, C., Runeson, P., Höst, M., et al., Experimentation in Software Engineering: An Introduction. Kluwer Academic Publishers. (2000)

11. Juristo, N. and Moreno, A. Basics of Software Engineering Experimentation. Kluwer Academic Publishers. (2001)

12. Ciolkowski, M., Shull, F. and Biffl, S. A Family of Experiments to Investigate the Influence of Context on the Effect of Inspection Techniques. Proceedings of the 6th International Conference on Empirical Assessment in Software Engineering (EASE´02). Keele (UK). (2002).

13. Briand, L., El Emam, K. and Morasca, S. Theorical and Empirical Validation of Software Product Measures. International Software Engineering Research Network, Technical Report ISERN-95-03. (1995).


76

Soporte de Información Contextual en un Marco de Medición y Evaluación

Hernán Molina, Luis Olsina

GIDISWeb, Facultad de Ingeniería, UNLPam, Calle 9 y 110 (6360) General Pico, La Pampa, Argentina

[hmolina,olsinal]@ing.unlpam.edu.ar

Resumen. El uso de un marco que defina de forma precisa la información utilizada en actividades de medición y evaluación en los proyectos de software de una organización, puede ofrecer soluciones más consistentes y comparables. Sin embargo, las diferencias del contexto, determinado por cada proyecto, pueden afectar la coherencia y consistencia entre los resultados de los distintos proyectos. En este trabajo se discute la importancia del uso de información de contexto para dicho propósito. Además, se propone un modelo y una estrategia para la representación y el uso de información de contexto en el marco de medición y evaluación denominado INCAMI, para asistir en la recomendación de soluciones de diseño y en la interpretación de los resultados obtenidos. Se ilustra el modelo con un caso de estudio.

Palabras Clave: Aseguramiento de calidad, medición, evaluación, contexto.

1 Introducción

En cualquier campo de la ciencia, el conocimiento nunca puede interpretarse de forma aislada debido a la riqueza y ambigüedad del lenguaje natural utilizado para expresarlo, y a que existen siempre factores externos (de su contexto), incluyendo puntos de vista, factores temporales, espaciales, funcionales y estructurales [20], que determinan la interpretación de la información disponible. Esto no es diferente en la ingeniería de software e ingeniería web, en las cuales se utilizan diversas definiciones de conceptos en todas las actividades que involucran, y cuya aplicación e interpretación sólo es válida bajo ciertas condiciones del contexto en las que son utilizadas. En particular, el aseguramiento de calidad es uno de los procesos clave, ya que ofrece mecanismos para la mejora, tanto de los procesos como de los productos que de ellos surjan. En este área, se han publicado importantes resultados de investigaciones entre los cuales destacamos a [13, 15, 16], donde se define un marco de medición y evaluación, orientado a propósitos y centrado en la organización, llamado INCAMI que define de forma explícita los conceptos involucrados en la definición, medición y evaluación de requerimientos no funcionales mediante el uso de una ontología [12] para ser aplicados en proyectos de software y web de una organización. Sin embargo, considerando que la organización puede llevar a cabo diversos proyectos, estas actividades deben estar respaldadas por la información relevante del contexto, relativo a la entidad bajo análisis, que permita validar la


77

aplicabilidad de las definiciones utilizadas así como la interpretación de los resultados obtenidos.

El objetivo del presente trabajo es robustecer el marco INCAMI, desde la perspectiva de la especificación del contexto de la entidad bajo análisis, de forma que sea posible utilizar esta información para efectuar recomendaciones de diseño en proyectos de medición y evaluación (especificación de requerimientos, diseño de la medición y diseño de la evaluación), aumentar la consistencia y coherencia en la interpretación y comparación de resultados de diferentes proyectos y, posteriormente, utilizar la información histórica de las soluciones aplicadas y resultados correspondientes para recomendar nuevas soluciones en base a las lecciones aprendidas.

El artículo se encuentra organizado de la siguiente forma: en la siguiente sección se describe brevemente el marco INCAMI, destacando la necesidad de utilizar información contextual para obtener resultados más coherentes y consistentes en actividades de medición y evaluación orientadas a objetivos y centradas en la organización. En la sección 3 se describe la propuesta para incorporar información de contexto en el marco INCAMI, denominada C-INCAMI. En la sección 4 se presenta un ejemplo sobre un caso de estudio realizado utilizando el marco INCAMI, como prueba de los conceptos propuestos. En la sección 5 se presenta una discusión referente al enfoque utilizado en esta propuesta respecto del utilizado en otros trabajos y por último, se enuncian las conclusiones y trabajos futuros.

2 El Marco de Medición y Evaluación INCAMI

2.1 Panorama del Marco

INCAMI [13, 15, 16] define aquellos conceptos involucrados en la medición y evaluación de requerimientos no funcionales en proyectos de software y web, como parte de las actividades de aseguramiento de calidad de una organización. INCAMI está basado en una ontología [12], que define de forma explícita los conceptos, atributos y relaciones principales que se utilizan en las actividades de medición y evaluación, y en la metodología WebQEM (Web Quality Evaluation Method) [17]. Los conceptos principales del marco INCAMI (del cual toma su nombre) son Necesidad de Información, Modelo de Concepto, Atributo, Métrica e Indicador (Information Need, Concept Model, Attribute, Metric and Indicator).

El marco sigue un enfoque orientado a propósitos u objetivos, ya que todas las actividades (selección de métricas y ejecución de la medición, y la definición de indicadores y ejecución de la evaluación) se enfocan en satisfacer una necesidad de información especificada inicialmente. Además, el marco está centrado en la organización, en el sentido de que la definición de los conceptos involucrados se encuentra enmarcada en el ámbito de una organización que lleva a cabo actividades de medición y evaluación como parte de sus programas de aseguramiento de calidad, contemplando aspectos de reusabilidad y consistencia de dichas actividades. Adicionalmente, INCAMI es soportado por un catálogo organizacional [14] que define las instancias de los conceptos, definidos en el marco, para ser utilizados en las


78

actividades de medición y evaluación, ofreciendo mecanismos de reuso que facilitan la consistencia y coherencia entre los resultados de evaluaciones para los diferentes proyectos de la organización.

Los conceptos del marco INCAMI están organizados en cuatro componentes principales (para más detalles consultar [13, 15, 16, 17]): • el módulo de definición y especificación de requerimientos no funcionales, que

trata con la definición de la necesidad de información (InformationNeed) y el diseño de los requerimientos, mediante uno o más modelos de concepto (ConceptModel), para instanciar, por ej., en modelos de calidad interna, calidad en uso, entre otros, utilizados para guiar las actividades posteriores de medición y evaluación (ver Fig. 1);

Fig. 1. Modelo conceptual para el componente de Definición y Especificación de Requerimientos no funcionales.

• el módulo de diseño y ejecución de la medición, que trata con la especificación de las entidades (Entity) concretas a ser medidas, la selección de las métricas (Metric) (del catálogo INCAMI) para cuantificar los atributos de los modelos de concepto seleccionados, y el registro de las mediciones obtenidas;

• el módulo de diseño y ejecución de la evaluación, que trata con la definición de los indicadores que interpretarán los modelos de concepto seleccionados, el diseño de los criterios de decisión, y del modelo de agregación para el cálculo global que proveerá una interpretación al concepto foco de la evaluación para cada una de las entidades medidas; y

• el módulo de conclusiones y recomendaciones, para el soporte a la toma de decisiones.

2.2 La Necesidad de Información de Contexto

Las actividades de medición y evaluación en la ingeniería de software y web se enfocan en obtener un entendimiento sobre algún aspecto de interés (por ej.


79

usabilidad, eficiencia), propio de una entidad en particular, desde un determinado punto de vista y con un propósito claramente establecido. En este sentido, la entidad bajo análisis no puede ser considerada de forma aislada ya que existen factores o propiedades que influyen en las conclusiones e interpretaciones que se obtengan a partir de su evaluación. Estos factores o propiedades corresponden al entorno o contexto en el que se encuentra dicha entidad, particularmente, un proyecto de software o web que es llevado adelante por alguna organización. Por lo tanto, estas propiedades deben ser contempladas al llevar a cabo la medición y evaluación de tales entidades.

Como se mencionó previamente, el marco INCAMI permite a una organización llevar a cabo diversos proyectos que hagan uso de facilidades de medición y evaluación. En este sentido, el marco, junto con el soporte tecnológico disponible [2, 15], ofrece un punto de referencia común a todos los proyectos para obtener resultados consistentes y comparables mediante los mecanismos de reuso de las instancias de los diferentes conceptos del marco. No obstante, esta consistencia puede ser robustecida, ya que no existían mecanismos definidos que permitieran utilizar la información de contexto disponible para asegurar esta consistencia, ya que, previo a la presente propuesta [13, 15, 16], el marco INCAMI permitía definir el contexto en el que se lleva a cabo la evaluación sólo en un campo con formato de texto libre (ver InformationNeed, Fig. 1). Suponiendo que la información disponible al respecto se encuentre especificada y sea clara, no es posible utilizarla de forma objetiva y consistente para recomendar soluciones de diseño ni comparar resultados provenientes de actividades de medición y evaluación, ya que la información de contexto disponible sólo puede ser contemplada de forma subjetiva por un evaluador. Por esta razón es necesario definir de forma clara y concisa, al igual que para los conceptos del marco INCAMI, aquellos elementos que permitan especificar formalmente el contexto relevante de una entidad bajo análisis, así como los mecanismos que permitan utilizar esta información de forma consistente y coherente para mejorar el diseño, la interpretación, comparación y reuso de resultados de la medición y evaluación de cualquier entidad.

3 Soporte de Información Contextual en Medición y Evaluación

Tal como fue expuesto al comienzo, el propósito de este trabajo es incorporar la capacidad de medición y evaluación respaldada por información de contexto al marco INCAMI. Cabe aclarar que se entiende sensible al contexto a aquella aplicación que dependa de o utilice información de contexto para ofrecer un servicio al usuario [5, 19]. En nuestra propuesta al igual que en [9], el contexto es considerado desde el punto de vista de la gestión de la información con el objetivo de mejorar su interpretación y reuso en una organización, particularmente, una organización de software. En este enfoque, la entidad, foco del contexto, es cualquier elemento de información del dominio de la ingeniería de software relevante respecto las tareas que se llevan a cabo como parte de sus procesos. Este trabajo se enfoca en procesos de medición y evaluación, en el cual los aspectos del contexto corresponden a un entorno


80

específico, tal como descripciones de procesos, recursos, documentos o productos de software.

A continuación se describe el enfoque propuesto, denominado C-INCAMI (Contextual INCAMI), respecto de la definición y modelización de la información de contexto, así como de los mecanismos para especificar y utilizar dicha información para efectuar recomendaciones de diseño en las actividades de medición y evaluación dentro del marco INCAMI.

3.1 Definición y Modelado de Contexto

3.1.1 Una visión de contexto. Aún no existe en la literatura una definición consensuada acerca de este concepto, sin embargo, no es ese el objetivo del presente trabajo, sino analizar los elementos que lo caracterizan para construir un enfoque apropiado a nuestra propuesta. Con este objetivo en mente, presentamos algunas de las definiciones y visiones de contexto de algunos autores.

En [5], Dey define al contexto como cualquier información que pueda ser utilizada para caracterizar la situación de una entidad (persona, lugar u objeto) considerada relevante en la interacción entre un usuario y una aplicación, incluyendo a éstos últimos. Esta definición, aunque genérica, proporciona un primer acercamiento al entendimiento del concepto. Gong presenta en [7] dos interpretaciones de contexto desde un punto de vista computacional; la primera ve al contexto como un espacio donde todos sus elementos se encuentran agrupados o contenidos por una entidad X de interés; la segunda, ve al contexto como el espacio de aquellas cosas relacionadas externamente con y referenciadas por X. De estas visiones, Gong propone una definición cuantificable de contexto al definirlo como “la colección formada por un objeto y sus relaciones con otros objetos, incluyendo estos últimos”. Strang et al definen en [19] el término información de contexto como cualquier información que puede ser utilizada para caracterizar el estado de una entidad (persona, lugar u objeto) concerniente a un aspecto específico (una clasificación), cuyos estados (o instancias) se expresan en una determinada escala. Además define a una entidad y un aspecto relevante en función de una tarea y un estado de dicho aspecto. Kaltz et al consideran en [11] que el contexto está determinado por un conjunto de factores de contexto estructurados según un modelo de contexto, una ontología del dominio de la aplicación y una perspectiva actual de tales factores (la información de contexto propiamente dicha).

Luego de analizar las definiciones y algunos enfoques existentes, extraemos un conjunto de elementos que permiten caracterizar al término contexto: • La información de contexto es relativa o referente a un objeto o entidad específico; • La entidad a la cual se refiere la información de contexto debe ser aquella relevante

respecto de la tarea para la cual es considerada; • La información de contexto corresponde a propiedades o aspectos internos y

externos de la entidad y las relaciones que los unen bajo una situación específica; • La información de contexto a considerar es aquella relevante respecto de:

1. la tarea específica relacionada a esa entidad; 2. el propósito específico para dicha tarea; 3. los aspectos o características relevantes de la entidad (aquellos involucrados


81

en la tarea para la cual se considera la entidad); 4. la situación de la entidad respecto de la tarea y su interacción con otros

elementos del contexto; • La información de contexto corresponde a un conjunto estructurado de aspectos o

propiedades de contexto, incluyendo el conjunto de relaciones entre ellas, y un léxico o descripción asociada que hace explícita su interpretación. El marco INCAMI se utiliza en la medición y evaluación de entidades (ver Entity y

EntityCategory en Fig. 1). Entonces, la entidad relevante para la cual se describirá el contexto son la entidades objeto de las actividades de medición y evaluación (por ej., procesos, productos, etc.). Estas entidades se encuentran enmarcadas en proyectos de software o web, que son llevados a cabo por una organización, posiblemente ejecutando los procesos definidos por ella. Por lo tanto, la información de contexto relevante será aquella relativa al proyecto al cual está relacionada la entidad, él o los procesos utilizados que influyan en ella, la organización que lleve a cabo el proyecto y, posiblemente, al ambiente externo a la misma.

A continuación se describe el modelo construido a partir de los elementos identificados como parte del contexto.

3.1.2 Un Modelo de Contexto para el Marco INCAMI. Un modelo de contexto es un elemento clave en la construcción de sistemas que utilicen información contextual [19]. La representación elegida para el mismo debe concordar con el propósito para el cual se utilizará dicha información, balanceando entre complejidad aceptable y capacidad de expresividad deseada. En este sentido se han considerado diferentes enfoques de representación, presentados en [18], que son analizados a la luz de un conjunto de requerimientos de interés para nuestra propuesta, algunos de los cuales son comunes a los identificados, en dicho trabajo, para el campo de sistemas ubicuos: • El conocimiento contextual debe poder ser validado tanto a nivel de estructura

como a nivel de instancia contra un modelo de contexto; • La información contextual debe ser precisa (una única interpretación) permitiendo

el reuso coherente y consistente de la misma; • El modelo de contexto debe poder ser aplicable a sistemas existentes; en este caso,

al ambiente existente que soporte al marco INCAMI [2, 15]; • El modelo debe ser simple de especificar y procesar: con el fin de mantener la

relación costo/beneficio desde el punto de vista del desempeño del sistema; • El modelo debe ser específico para el dominio de la ingeniería de software y web:

ya que debe estar enfocado en los aspectos relevantes a la organización respecto de las actividades de medición y evaluación en proyectos de software y web;

• El modelo debe ser lo suficientemente flexible para permitir su adaptación basada en necesidades específicas de la organización. Se ha optado por utilizar una combinación de diferentes enfoques de modelado de

contexto, aprovechando las ventajas de unos para cubrir las deficiencias de otros. La integración de la información de contexto al marco INCAMI se realizará manteniendo dos espacios de información diferentes: el espacio de elementos del dominio (los componentes del marco INCAMI -ver sección 2.1) y el espacio de elementos de contexto; la contextualización de los elementos del dominio se efectuará estableciendo relaciones con elementos del espacio de contexto [11].


82

En el modelo propuesto (ver Fig. 2), el contexto es representado como una colección de propiedades de contexto (representadas mediante pares nombre-valor). Cada propiedad pertenece a una clase de una taxonomía de propiedades de contexto que define y clasifica1, los conceptos claves de la ingeniería de software y web [1, 3] (siguiendo el enfoque presentado en [11]) pudiendo ser modificada por la organización según sus necesidades. Para muchas de estas clases existen subclases relacionadas a aspectos más específicos que no han sido incluidas aquí por razones de espacio. Adicionalmente, se ha definido la semántica de dichas propiedades (mediante un conjunto de metadatos) así como los tipos de valores de las mismas (por medio de una métrica) de forma que no haya lugar a ambigüedades respecto de su interpretación y comparación.

Se deben distinguir dos situaciones en las cuales se utilizará información de contexto (ambas situaciones son mostradas en la Fig. 3): • Para describir el contexto relevante de la entidad, objeto de las actividades de

medición y evaluación en un proyecto particular, para una necesidad de información específica; y

• Para describir el contexto relevante al cual son aplicables determinados elementos del espacio de información del marco INCAMI, denominados elementos contextuales. Estos son elementos cuya definición puede determinar que sean más o menos aplicables a un determinado contexto, observando aspectos de coherencia y consistencia. Los elementos contextuales identificados en el marco INCAMI son: modelo de concepto, métrica e indicador (elemental y global). Finalmente, se utilizará un catálogo de contexto común (de forma similar al

catálogo INCAMI [14]) en el que, tanto las clases de la taxonomía, como definiciones de instancias de las mismas, útiles a la organización, serán almacenadas, mediante un sistema colaborativo de revisión [2]. De esta forma cada proyecto particular hará uso de aquellas propiedades que sean relevantes al contexto correspondiente, manteniendo la consistencia con el resto de los proyectos que la organización lleve a cabo.

En resumen, el enfoque propuesto presenta las siguientes características: • Simple: una propiedad es un par nombre-valor que puede ser importado del

catálogo de contexto y fácilmente especificado y comparado utilizando la especificación de la métrica asociada;

• Específico: los aspectos o propiedades utilizados para describir el contexto son específicos para el dominio de la ingeniería de software y web;

• Flexible: mediante el uso del catálogo de contexto y el sistema de revisión, la información de contexto puede ser modificada según las necesidades;

• Semánticamente definido y validable: el significado de cada uno de los tipos de propiedades se encuentra explícitamente definido, así como el de las instancias correspondientes y sus posibles valores;

• Orientado a la organización: el catálogo de contexto, permite que toda la información especificada sea aquella útil a los objetivos globales de la organización, permitiendo la integración o comparación consistente y coherente de resultados entre diferentes proyectos que la misma lleve a cabo;

1 La taxonomía fue definida en OWL (Ontology Web Language) con la herramienta Protégé.


83

• Débilmente acoplada al marco INCAMI: el modelo de contexto se encuentra separado del resto de los elementos del dominio INCAMI permitiendo la contextualización de elementos del marco.

A continuación se describen los mecanismos por los cuales se especifica y utiliza la información de contexto en el marco C-INCAMI.

Fig. 2. Modelo de contexto para el dominio de la Ingeniería de Software y Web

Fig. 3. Modelo correspondiente a la integración de información de contexto al marco INCAMI.


84

3.2 Especificación y Uso de Información de Contexto

Tomando como referencia los pasos del método WebQEM [17], el contexto en el cual se considera la entidad bajo análisis será especificado como parte de la Necesidad de Información (InformationNeed), en la etapa de especificación de requerimientos. El evaluador seleccionará del catálogo de contexto de la organización las propiedades que considere relevantes, luego se asignarán los valores correspondientes, que describan el contexto mencionado, utilizando la especificación de la métrica asignada a cada propiedad, de forma similar a como son cuantificados los atributos de un modelo de concepto durante la implementación de la medición.

En segundo lugar, la información de contexto para los elementos contextuales almacenados en el catálogo INCAMI [14] será especificada mediante un mecanismo de revisión colaborativo (tal como fue implementado en [2]) utilizando las propiedades de contexto definidas en dicho catálogo.

Para mejorar el diseño de la medición y evaluación de las entidades bajo análisis, se utilizará la información de contexto asociada a los elementos contextuales para determinar su compatibilidad con el contexto actual (especificado en la necesidad de información). De esta forma, cada vez que se solicite un determinado elemento contextual del catálogo INCAMI, se mostrará al usuario evaluador una lista de los elementos aplicables en orden descendiente de aplicabilidad al contexto actual (una de las categorías de funcionalidades que una aplicación sensible al contexto puede ofrecer [5]). Esta compatibilidad se basa en determinar la existencia de las propiedades especificadas por el elemento contextual en el contexto actual con los mismos valores (el detalle de este procedimiento será presentado en trabajos futuros). La comparación de valores es consistente gracias a la disponibilidad de la escala definida por la métrica.

Adicionalmente, el contexto especificado será almacenado junto con el proyecto de medición y evaluación para ser utilizado, posteriormente, con fines de procesamiento de información histórica (ver Sección 6).

Finalmente, la información de contexto permitirá efectuar interpretaciones y comparaciones más coherentes ya que, las conclusiones que pudieran obtenerse de una evaluación estarán acotadas al contexto en el cual se encontraba la entidad evaluada. Este tipo de comparaciones pueden ser automatizadas ya que la información de contexto disponible puede ser procesada gracias al modelo diseñado.

4 Prueba de Conceptos sobre un Caso de Estudio

En esta sección se presenta un ejemplo a modo de prueba de conceptos para ilustrar el modelo descripto en la sección 3.1. El ejemplo se ha desarrollado sobre un caso de estudio de evaluación de calidad en uso sobre una aplicación de e-learning [4] en el cual se utilizó el marco INCAMI. En este tipo de evaluaciones, el contexto es altamente relevante, ya que los conceptos involucrados (según la norma ISO 9126-4) se definen en consideración del contexto de uso. Como se indicó en la sección 3.2, se comienza por definir la necesidad de información como parte de la especificación de requerimientos (ver Tabla 1).


85

Tabla 1. Ejemplo de especificación de la Necesidad de Información para el caso de estudio.

Propósito Foco Punto de vista

Comprender Calidad en uso Estudiante ingresante

CategoríaEntidad Entidad Contexto

Producto/Aplicación Web/WbIS2 QPlus Campus Virtual (ver Tabla 2)

Como parte de la especificación del contexto, se seleccionan del Catálogo de

Contexto de la organización aquellas propiedades de contexto relevantes. La definición de una propiedad de contexto, tal como es recuperada del catálogo, dispone de un nombre, una descripción, el tipo de propiedad al que pertenecen (ver Fig. 2), el peso o importancia relativa y la métrica asociada, que especifica cómo obtener un valor para dicha propiedad. Luego, se asigna el valor correspondiente a cada propiedad para describir el contexto de la entidad bajo análisis. Además se debe especificar, para cada una, la fuente del dato y el momento en el cual fue obtenido. En la Tabla 2 se muestran ejemplos de algunas propiedades de contexto instanciadas (se obviará la especificación de las métricas asociadas, indicando sólo el tipo de valor a continuación del mismo).

Tabla 2. Ejemplos de propiedades de contexto para las cuales se han asignado valores que describen el contexto del proyecto de medición y evaluación actual (extraído de [4]).

Nombre Descripción Tipo Valor

User profile type The general profile the user presents

StakeholderProperty Undergraduate student (Escala Categórica)

Focus Concern The main feature or aspect of interest.

MeasurementAnd AnalysisProperty

Quality in Use (Escala Categórica)

Entity Category The category to which the entity belongs.

SoftwareProduct Property

WbIS (Escala Categórica)

Point of view The position or perspective (ie. a given role) from which an entity is considered.

StakeholderProperty User, Manager, etc. (Escala Categórica)

Una vez definida la necesidad de información, las actividades siguientes, que

involucran tanto la especificación de los requerimientos, el diseño de la medición y de la evaluación, requieren de la selección de ciertos elementos contextuales del catálogo INCAMI, los cuales fueron mencionados en la sección anterior. A continuación se presenta un ejemplo para la selección de un modelo de concepto.

Como parte del diseño de los requerimientos, se debe seleccionar del catálogo correspondiente un Modelo de Concepto (clase ConceptModel en Fig. 1) para describir el concepto foco de la evaluación, en este caso, el de Calidad en Uso. En la Tabla 3 se muestran los dos modelos de calidad en uso recuperados del catálogo, junto con la especificación del contexto al cual son aplicables.

2 Web-based instructional system


86

Tabla 3: Ejemplo de dos modelos de calidad en uso con sus propiedades de contexto respectivas.

Modelo de Calidad en Uso 1: 1. Quality in Use Model 1.1. Effectiveness 1.1.1. Task Completion 1.1.2. Task Effectiveness

1.2. Productivity 1.2.1. Efficiency regarding Task Completion 1.2.2. Efficiency regarding effectiveness

1.3. Satisfaction

Aplicable al contexto (ContID): @C1; caracterizado por: PropID Name Value Type

$FC1@C1 $EC1@C1 $EC2@C1 $POV1@C1 $UPT1@C1 $UPT2@C1

Focus Concern Entity Category Entity Category Point of view User profile type User profile type

Quality in Use WbIS e-Commerce Web App.User Customer Undergraduate student

MeasurementAndAnalysisProperty SoftwareProductProperty SoftwareProductProperty MeasurementAndAnalysisProperty StakeholderProperty StakeholderProperty

Modelo de Calidad en Uso 2: 1. Quality in Use Model 1.1. Effectiveness 1.1.1. Task Completion 1.1.2. Task Effectiveness

1.2. Productivity 1.2.1. Efficiency regarding Task Completion 1.2.2. Efficiency regarding effectiveness

1.3. Satisfaction 1.4. Safety 1.4.1. User Health 1.4.2. Software Damage

Aplicable al Contexto (ContID): @C2; caracterizado por: PropID Name Value Type

$FC1@C2 $EC1@C2 $POV1@C2 $UPT1@C2

Focus Concern Entity Category Point of view User profile type

Quality in Use Aircraft Navigation System User Novice Aircraft Pilot

MeasurementAndAnalysisProperty SoftwareProductProperty MeasurementAndAnalysisProperty StakeholderProperty

Realizando una comparación de las propiedades del contexto asociado a ambos

modelos con aquellas especificadas para el contexto actual (definido en la necesidad de información -ver Tablas 1 y 2) surge que el modelo más apropiado es el “Modelo de Calidad en Uso 1”, ya que el valor de la propiedad Entity category del modelo 2 (Aircraft Navigation System) difiere del especificado para la misma en el contexto actual (WbIS), mientras que en el modelo 1 es el mismo (ver Tabla 4), al igual que con User profile type.

5 Trabajos Relacionados y Discusión

El término sensible al contexto (en inglés context-aware) comenzó a ganar importancia con la aparición de dispositivos móviles, como una solución para ofrecer


87

mejores servicios, campo cubierto por la computación ubicua. Sin embargo, observando diferentes definiciones del enfoque en [5, 7, 9, 11] y considerando la definición del término aware3, "tener conocimiento o percepción de una situación o hecho", el enfoque context-aware puede ser aplicado a todo campo en el cual la información del contexto relevante sea necesaria y útil para ofrecer un servicio al usuario. Dependiendo del dominio de la aplicación, de los aspectos de contexto relevantes (por ej. posición, tiempo u otros más específicos) y de los requerimientos específicos, será el tipo de aplicación resultante. Por ejemplo, en el campo de las aplicaciones ubicuas sensibles al contexto [6, 8, 10, 18, 19] (como aplicaciones de guías de turismo o de museos para usuarios móviles), en las cuales el usuario móvil es la entidad principal, los aspectos de contexto más relevantes son el de posición, tiempo y preferencias del usuario (entre otros), a diferencia de otros enfoques, como en [9], donde el enfoque es aplicado en la gestión de conocimiento sensible al contexto en ambientes de negocios, para facilitar y mejorar el uso de información empresarial. Otro ejemplo es el uso de información de contexto para la resolución de problemas en sistemas inteligentes [8]. Siempre que exista información de contexto que influya en la forma en que los servicios son ofrecidos, la aplicación de un enfoque sensible al contexto es factible y, por lo tanto, deseable, para mejorar dicho servicio. Así, en este trabajo se ha utilizado el enfoque sensible al contexto para mejorar los procesos de medición y evaluación en proyectos de software y web, utilizando la información de contexto relativa a las entidades involucradas en tales actividades.

Tabla 4. Comparación de los contextos de ambos modelos con el contexto actual. En el encabezado se muestra, para cada modelo, la cantidad de propiedades cuyos valores son iguales a aquellas especificadas en el contexto actual.

Propiedad Proyecto actual Modelo 1 4 Modelo 2 2

Focus Concern Quality in Use Quality in Use Quality in Use

Entity Category WbIS WbIS Aircraft Navigation System

Point of view User User User

User profile type Undergraduate student

Undergraduate student

Novice Aircraft Pilot

Respecto del enfoque de modelado utilizado para representar la información de

contexto, cabe destacar que el modelo de contexto presentado en este trabajo difiere en gran medida con aquellos vistos en el campo de la computación ubicua ya que en estos últimos se debe manipular un amplio rango de información de diferente naturaleza, mientras que en nuestra propuesta, el dominio de aplicación es muy específico. Sin embargo los requerimientos de simplicidad y capacidad de expresión son los mismos. En esta propuesta se ha logrado un modelo que es simple y específico a la vez, alcanzando un nivel de expresividad flexible que puede ser ajustado según las necesidades.

3 Según Ask Oxford (http://www.askoxford.com/concise_oed/aware?view=uk)


88

6 Conclusiones y Trabajos Futuros

En este trabajo se ha presentado una propuesta, denominada C-INCAMI, para incluir en el marco INCAMI tanto la información del contexto relevante como así también los mecanismos para utilizar dicha información en la recomendación de decisiones de diseño en los procesos de medición y evaluación en los proyectos de software y web de una organización. Esto es posible ya que no sólo se guardan los datos y metadatos de la medición y evaluación sino también de la información del contexto asociado.

El enfoque planteado ofrece un mecanismo simple, flexible, consistente (semánticamente validable), orientado a la organización y a los objetivos, para la representación del conocimiento de contexto que dé soporte a las actividades involucradas en el diseño de actividades de medición y evaluación de las entidades en un proyecto de software y web, así como en la interpretación de los resultados del análisis correspondiente. Se espera de esta forma mejorar la calidad de las entidades claves de la organización (procesos, productos y servicios), al incluir, en el proceso de toma de decisiones para la mejora, información relevante que influya en la interpretación de resultados de la evaluación de las mismas.

Además se ha presentado un ejemplo a modo de prueba de conceptos sobre un caso de estudio de evaluación de Calidad en Uso para el cual la definición del contexto de evaluación es un elemento crítico para el éxito de la misma.

Los trabajos futuros se enfocarán, por un lado, en definir de forma más detallada el mecanismo de selección y presentación de los elementos contextuales, de forma que sea posible recomendar de un modo automático el más apropiado al contexto actual, y por otro lado, se trabajará en el diseño de una arquitectura que dé soporte tecnológico a la propuesta presentada, integrándolo al prototipo existente que da soporte al marco INCAMI [2, 15]. Otra línea de investigación en avance es la utilización de la información histórica de los resultados de la medición y evaluación de los proyectos de una organización, incluyendo la información relativa al contexto, para efectuar recomendaciones de diseño en base a la experiencia pasada.

Reconocimientos. Este trabajo y línea de investigación están soportados por los proyectos UNLPam 09/F037, PAV 127-05 y PICTO 11-30300, de la Agencia de CyT, Argentina.

Referencias

1. Abran, A., Moore, J., Bourque, P., Dupuis, R., Tripp, L.: Guide to the Software Engineering Body of Knowledge -SWEBOK, Iron Man Version 1.0, IEEE Computer Society Press, 2004, URL: http://www.swebok.org

2. Baffini, M., Rivera, B., Olsina, L.: Sistema Colaborativo de Revisión de Métricas. III Workshop de Ingeniería de Software y Bases de Datos, XII CACIC, San Luis, Arg., 2006.

3. CMMI Product Team, Capability Maturity Model® Integration (CMMISM), Version 1.1 - CMMISM for Software Engineering (CMMI-SW, V1.1), Staged Representation, CMU/SEI-2002-TR-029, ESC-TR-2002-029, 2002.

4. Covella, G. Olsina, L; Assessing Quality in Use in a Consistent Way, In proc. of ACM, Int'l Congress on Web Engineering, (ICWE05), SF, USA, pp.1-8, 2006, ISBN 1-59593-352-2.


89

5. Dey, A.K.: Understanding and Using Context. Personal and Ubiquitous Computing Journal, Vol. 5 (1), 2001, pp. 4-7. ISSN: 1617-4917 (Online), Springer London.

6. Freitas Bulcao Neto, R. de, Graça Campos Pimentel, M. da: Toward a Domain-Independent Semantic Model for Context-Aware Computing: In Proc. of the Third Latin American Web Congress (LA-Web05), pp. 61-70, ISBN:0-7695-2471-0, IEEE Computer Society, 2005.

7. Gong, L.: Contextual Modeling and Applications, IEEE Int’l Conference on Systems, Man and Cybernetics. pp. 381-386 Vol. 1, 2005, ISBN: 0-7803-9298-1.

8. Gu, T., Wang, X. H., Pung, H. K., Zhang, D. Q.: An Ontology-based Context Model in Intelligent Environments: In Proc. of Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS’04), pp. 270-275. San Diego, CA, USA, 2004.

9. Huang, W., Tao, T.: Adding Context-awareness to Knowledge Management in Modern Enterprises. 2nd IEEE Int’l Conference on Intelligent Systems, 2004, ISBN: 0-7803-8278-1.

10. Kaenampornpan, M., E. O'Neill, E.: An Integrated Context Model: Bringing Activity to Context: In Workshop on Advanced Context Modelling, Reasoning and Management, UbiComp 2004, Nottingham, UK, 2004.

11. Kaltz, J.W., Ziegler, J., Lohmann, S.: Context-aware Web Engineering: Modeling and Applications. In: RIA - Revue d'Intelligence Artificielle, Special Issue on Applying Context-Management, Vol. 19 (3): pp. 439-458, Lavoisier, Paris, France, 2005, ISSN 0992-499X.

12. Martín M., Olsina, L.: Towards an Ontology for Software Metrics and Indicators as the Foundation for a Cataloging Web System, In Proc. of IEEE Computer Press, 1st Latin American Web Congress (LA-Web), Santiago de Chile, Nov 10-12, 2003.

13. Molina, H. Papa, F. Olsina, L.: Marco Conceptual para el Soporte de Proyectos de Medición y Evaluación en Aseguramiento de Calidad, 8° Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software (IDEAS05), Valparaíso, Chile, 2005.

14. Molina H., Papa F., Martín M., Olsina L.: Semantic Capabilities for the Metrics and Indicators Cataloging Web System. In: Engineering Advanced Web Applications, Matera M. and Comai S. Eds., Rinton Press Inc., US, pp. 97-109, 2004, ISBN 1-58949-046-0.

15. Olsina, L; Papa, F.; Molina, H.: How to Measure and Evaluate Web Applications in a Consistent Way, Chapter Book to appear in a Springer Book titled Web Engineering: Modelling and Implementing Web Applications; Rossi, Pastor, Schwabe, and Olsina Eds., 2007.

16. Olsina, L; Molina, H; Papa, F.: Organization-Oriented Measurement and Evaluation Framework for Software and Web Engineering Projects, In Lecture Notes in Computer Science of Springer, LNCS 3579, Int'l Congress on Web Engineering, (ICWE05), Sydney, Australia, pp. 42-52, 2005.

17. Olsina L., Rossi G.: Measuring Web Application Quality with WebQEM, IEEE Multimedia, Vol. 9(4), pp. 20-29, 2002.

18. Strang, T., Linnhoff-Popien, C.: A Context Modeling Survey. In: Workshop on Advanced Context Modelling, Reasoning and Management, UbiComp 2004 - The Sixth Int’l Conference on Ubiquitous Computing, Nottingham, UK, pp. 34-41, 2004, http://citeseer.ist.psu.edu/strang04context.html

19. Strang, T., Linnhoff-Popien, C., Frank, K.: CoOL: A Context Ontology Language to enable Contextual Interoperability. DAIS 2003, LNCS 2893, pp. 236–247, 2003. ISSN: 0302-9743, Springer Berlin / Heidelberg.

20. Theodorakis, M.: Contextualization: An abstraction Mechanism for Information Modeling. Doctoral thesis in Computer Science, University of Crete, 2001, http://citeseer.ist.psu.edu/theodorakis01contextualization.html.


90

Propuesta de Marco para la Selección de Técnicas de Educción de Requisitos

Dante Carrizo1 y Oscar Dieste2

1 Departamento Sistemas Informáticos y Computación

Facultad de Informática Universidad Complutense de Madrid

C/ Prof. José García Santesmases s/n, 28040, Madrid, España [email protected]

2 Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software

Facultad de Informática Universidad Politécnica de Madrid

Avda. Montepríncipe s/n, 28040, Boadilla del Monte, 28660, España [email protected]

Resumen. La Ingeniería de Requisitos puede hacer uso de una gran cantidad de técnicas para educir las necesidades de los usuarios. No obstante, actualmente apenas existen guías y criterios prácticos para realizar la selección de técnicas más adecuadas en un proyecto de desarrollo particular. En este artículo se presenta un marco que ayude a ingenieros de requisitos a enfrentarse al proceso de educción en un determinado Contexto Situacional. Este marco requiere de la determinación de: los Atributos Contextuales (atributos que influyen en la decisión), la Adecuación de las Técnicas, y el Procedimiento de Selección.

Palabras claves: Ingeniería de Requisitos, Técnicas de Educción, Educción de Requisitos.

1 Introducción

La ingeniería de requisitos es el proceso sistemático de desarrollar requisitos a través de un proceso iterativo y cooperativo de adquisición de información acerca del dominio del problema, documentando las observaciones resultantes en una variedad de formatos de representación, y chequeando la precisión del entendimiento ganado [1]. La correcta realización de la actividad de requisitos es vital para la calidad del producto final [2] [3]. No obstante, una somera revisión de las investigaciones en Ingeniería de Requisitos permite entrever que la mayoría de los trabajos realizados hacen referencia a métodos o técnicas de modelado y especificación de requisitos [4], descuidando en consecuencia todo lo referido al modo en que se deben obtener esos requisitos. Para la obtención de requisitos, se han definido un buen número de técnicas de educción [5], pero en contrapartida, no existen criterios claros acerca de cuándo


91

aplicar dichas técnicas en la práctica [6] [7]. Más específicamente, la dificultad reside no en cómo utilizar las técnicas de educción, sino cuándo o en qué circunstancias dichas técnicas son aplicables y potencialmente efectivas para obtener los requisitos [8]. Todo ello supone una carencia importantísima para la actividad de requisitos, ya que la efectividad de la educción es un factor que influye poderosamente sobre la calidad de los requisitos y, por lo tanto, del producto final [9]. Por esto, es incuestionable la necesidad de contar con guías claras para la selección de la(s) técnica(s) que mejor funcione(n) en un contexto particular, tal y como han sugerido un amplio número de investigadores [9][10][11][12][13] [14][15]. Por consiguiente, el presente trabajo tiene como objetivo definir una guía metodológica que permita identificar las técnicas de educción más efectivas en un caso particular. Para ello, el artículo se estructurará en cuatro secciones. La sección 2 describirá el modo ideal en que se debe llevar a cabo la selección de técnicas de educción, así como los trabajos realizados al respecto. La sección 3 describirá la propuesta realizada, desglosando ésta en sus diversos componentes: aspectos situacionales, adecuación de las técnicas de educción y procedimiento de selección. Finalmente, la sección 4 discutirá las ventajas de la aproximación propuesta frente a los trabajos realizados hasta la fecha.

2 Antecedentes y Trabajos Relacionados

Debido a la gran cantidad de técnicas disponibles para educir requisitos, los analistas o ingenieros de software se enfrentan continuamente a la decisión sobre la(s) técnica(s) a utilizar en cada proyecto de desarrollo. Éstos, normalmente, eligen la técnica a aplicar por alguna de las siguientes razones [9]:

� Es la única técnica que conoce. � Es la técnica favorita para todas las situaciones. � Es una técnica particular prescrita por una metodología. � Es una técnica que se entiende intuitivamente efectiva bajo las circunstancias

actuales del proyecto de desarrollo. Muy al contrario, un ideal experto en requisitos, conocedor de todas las técnicas de educción y con vasta experiencia, se enfrentaría de un modo muy distinto al problema de la selección de técnicas de educción:

1. Determinaría qué atributos, o características del proyecto de desarrollo actual, influyen en la efectividad de las técnicas de educción, identificando los valores de cada uno de estos atributos.

2. De acuerdo con su conocimiento acerca de las técnicas de educción, evaluaría la adecuación de cada técnica al proyecto de desarrollo actual, utilizando para ello los atributos identificados anteriormente.

3. Finalmente, seleccionaría una o varias técnicas, las priorizaría y prepararía el plan de educción de requisitos.

La citada estrategia es, en líneas generales, la utilizada en los pocos trabajos que han afrontado esta problemática. Maiden y Rugg [16] proponen un esquema denominado ACRE (Acquisition of Requirements). ACRE considera que existen cinco facetas o atributos que influyen en la efectividad de las técnicas de educción: Propósito de los


92

Requisitos, Tipos de conocimientos, Filtro interno de conocimiento, Fenómenos Observables y Contexto de Adquisición. Para cada uno de los citados atributos, se identifican sus posibles valores y se evalúa la adecuación, para cada valor, de un conjunto de doce técnicas de educción distintas. No obstante, y aunque no cabe duda de la importancia de la propuesta realizada, este trabajo posee ciertas carencias debido, principalmente, al escaso número de atributos considerado y a la falta de una validación empírica del esquema propuesto. En la misma línea, Davis y Hickey [9] definen cinco categorías de atributos que afectan a la efectividad de las técnicas de educción: Características del dominio del problema (tales como complejidad, borrosidad, madurez, importancia de requisitos no funcionales); Características del dominio de solución (tipo de solución a desarrollar); Características de los interesados; Características de los desarrolladores (tales como el conocimiento, destrezas comunicacionales, experiencia); y Características de los ingenieros de requisitos (conocimiento del dominio del problema o solución por ejemplo). Se trata sin duda de un trabajo muy completo en cuanto a los atributos considerados pero, no obstante, no llega a relacionar técnicas de educción y atributos, por lo que su aplicación práctica es imposible. Ya de menor importancia que los dos trabajos antes citados, Byrd y otros [17] proponen un esquema de categorización basado en tres dimensiones: obstáculos de comunicación (de los participantes), entendimiento del dominio del problema (información, proceso, comportamiento, marco del problema), y control del proceso (conducido por el Usuario/Experto, conducido por el Analista/Ingeniero de Conocimiento, conducido por la Máquina/Sistema de apoyo). Claramente este trabajo constituye un serio intento para identificar la efectividad de un número importante de técnicas, aunque es también evidente que la cantidad de atributos manejada es muy reducida. En una línea parecida Dhaliwal y Benbazat [10] proponen diversos atributos relevantes para la selección, los cuales son: Características del experto, Características del ingeniero, grado de incertidumbre, Tipo de Tarea, Métodos de resolución de problemas, Metodología de desarrollo, y Entorno organizacional. Al igual que en el caso anterior, es claro que el número de atributos considerados es reducido y, adicionalmente, esta propuesta es meramente descriptiva, proponiendo los atributos sin mayor detalle en su definición y sin llegar a definir la relación entre atributos y técnicas de educción. También de modo similar, Kim y Courtney [18] proponen un marco conceptual, muy limitado, compuesto únicamente por dos factores: Dominio del Problema y Categorías de Conocimiento. Finalmente, debe mencionarse la existencia de un buen número de trabajos que estudian una gran diversidad de técnicas y atributos contextuales, los que fueron presentados en [19]. No obstante, dichos estudios son de muy limitada utilidad debido, por una parte, a la deficiente metodología utilizada en muchos de ellos así como, por otra parte, al hecho de que la dispersión en técnicas y atributos considerados hacen difícil sumarizar toda la información proporcionada de modo confiable [21].


93

3 Propuesta de Solución

La solución propuesta en esta investigación consiste en un marco que consta de los componentes mostrados en la figura 1. Al igual que los estudios realizados hasta el momento, tales como [9] y [16], la solución propuesta parte de la identificación de un conjunto de factores contextuales, los cuales a su vez se desglosan en atributos y valores, que afectan a la efectividad de las técnicas de educción. Para cada atributo de influencia y valor, se ha determinado cuán adecuada es cada técnica de educción de un subconjunto escogido de técnicas básicas que han sido elegidas para el estudio. No obstante, y en esto reside la novedad e importancia del presente trabajo, la adecuación individual de cada técnica respecto a cada valor de cada atributo no es el último paso del procedimiento de selección propuesto. Al contrario, se ha definido una función de selección que permite combinar sistemáticamente las adecuaciones parciales de cada técnica, utilizando el contexto situacional concreto del proyecto de desarrollo actual, con la finalidad de obtener un plan de educción propuesto. Las secciones siguientes describen los componentes indicados.

Plan de Educción

Procedimiento

de Selección de

Técnicas de

Educción

Contexto Situacional

Función de Selección

Adecuación

Atributos

de

Influencia

Técnicas

de

Educción

Valores

de

Adecuación

Figura 1. Modelo de proceso de selección de técnicas de educción.

3.1 Atributos Contextuales

La “bondad” de uso de cualquier técnica de educción está asociada a un conjunto de atributos que se obtienen del contexto en que dicha técnica es utilizada. Por ejemplo, la técnica de entrevista abierta tiene mayor efectividad que una estructurada al inicio del desarrollo, por lo que el momento del proceso parece ser un atributo diferenciador entre el uso de las técnicas.


94

Tabla 1. Conjunto de atributos considerados para la descripción del contexto.

Factor Atributos Definición Valor Descripción

Alta Formación formal y práctica

Media Formación sin práctica Formación en Técnicas de Educción

Formación y práctica recibidas por el eductor en Técnicas de Educción

Nula No tiene conocimiento respecto de ellas

Alta Más de 5 proyectos educción

Media Entre 2 y 5 proyectos de educción Experiencia en Educción

Actividades de educción previas abordadas por el eductor

Baja Menos de 2 proyectos de educción

Alta Más de 5 aplicaciones de la técnica

Baja Entre 1 y 5 aplicaciones de la técnica

Experiencia en la Técnica de Educción

Cantidad de actividades de educción previas en que eductor ha aplicado la técnica.

Nula Sin aplicación de la técnica

Alta Más de 2 proyectos o conocimiento formal

Baja Entre 1 y 2 proyectos o conocimiento no formal

Eductor

Familiaridad con el Dominio

Proyectos previos en dominio similar o conocimiento de él, por parte del eductor

Nulo Completamente desconocido

Individual 1 individuo

Grupal Entre 2 y 5 individuos Individuos por Sesión

Cantidad de individuos que pueden participar en una sesión de educción simultáneamente

Masivo Más de 5 individuos

Alto Consenso Consenso entre Educentes

Grado de acuerdo inicial entre los educentes Bajo No hay consenso

Alto Muy interesado

Bajo Poco interesado Interés del Educente

Motivación mostrada por el educente en participar en las sesiones

Nulo Sin interés

Experto Más de 5 años en el dominio o función

Entendido Entre 2 y 5 años en el dominio o función Nivel de Pericia Experiencia del educente en el dominio del problema o su trabajo

Novicio Menos de 2 años en el dominio o función

Alta Explica sobresalientemente su conocimiento

Media Puede explicar normalmente su conocimiento Capacidad de Articulación

Facilidad del educente para explicar su conocimiento

Baja No explica claramente su conocimiento

Alta Dispone holgadamente de tiempo

Media Dispone ajustadamente de tiempo Disponibilidad de Tiempo

Tiempo del que dispone el educente para dedicar a las sesiones

Baja Dispone menos tiempo del deseado

Lejano En ciudad distinta del eductor

Educente

Localización/ Accesibilidad

Ubicación física del educente Cercano En la misma ciudad del eductor

Estratégico Se educe estrategias/control

Táctico Se educe procedimientos/heurísticas

Tipo Información a Educir

Tipo de información que la técnica puede educir

Básico Se educe conceptos/atributos

Táctico Se cuenta con procedimientos, heurísticas

Básico Se cuenta con conceptos, atributos

Nivel de Información Disponible

Tipo de información que se dispone previamente a la sesión, antes de aplicar la técnica

Nulo No se cuenta con información

Alto Bien definido

Dominio del Problema

Grado de Definición

Claridad de los objetivos del proyecto Bajo Mal definido

Alta Mal de tiempo

Media Tiempo ajustado Restricción de Tiempo del Proyecto

Disponibilidad suficiente de tiempo para aplicar la técnica

Baja Holgura de tiempo

Inicial Educción de definiciones generales

Intermedia Educción de requisitos principales

Proceso de Educción

Momento del Proceso

Etapa del proceso de educción en que se encuentra antes de la sesión

Avanzada Educción información final


95

Dichos atributos, agrupados en factores, se han obtenido mediante un proceso de dos fases: una primera fase de búsqueda e identificación de un conjunto inicial de atributos, obtenido mediante la revisión de la literatura e investigaciones previas [19], y una segunda de análisis y depuración que permitió eliminar, modificar y agregar atributos relevantes. El resultado final se presenta en la tabla 1 (el análisis no se presenta por razones de espacio pero puede verse en [20]), junto con una descripción de los atributos pertenecientes a cada factor y los posibles valores de dichos atributos. Este conjunto de factores/atributos/valores no es en ningún modo cerrado, y podrá expandirse en el futuro con nuevas entradas a medida que aumente la información disponible acerca de la efectividad de las técnicas de educción.

3.2 Adecuación de las Técnicas

Una vez determinados los atributos contextuales, es crucial determinar la adecuación de cada técnica de educción, esto es, en qué situaciones una técnica de educción es efectiva, y por lo tanto puede o debe utilizarse, y en qué situaciones ello no es posible. La determinación de la adecuación de las técnicas de educción se realizó en base al conocimiento extraído de varias y diversas fuentes, tales como: la literatura científica, casos de estudio, los marcos previos propuestos y, especialmente, los trabajos empíricos acerca de la adecuación de técnicas de educción [21]. Los valores de adecuación se han asignado para cada posible combinación de técnica de educción y valor de los atributos de los factores contextuales (esto es, los valores mostrados en la tabla 1). Los valores definidos para la adecuación, los cuales están inspirados en parte en el trabajo de Maiden y Rugg [16], son: “√” (la técnica se recomienda para ese caso), “×” (la técnica no se recomienda para ese caso), y “–” (en este caso el uso de la técnica es indiferente). El valor de adecuación prescribe el uso de una determinada técnica de educción en el caso de que los atributos contextuales tomen determinados valores. Una técnica puede ser adecuada para uno o más valores de un atributo contextual, o puede ser adecuada para uno y desaconsejada para otro. El valor de indiferencia significa que, en dicha situación, la técnica no es especialmente efectividad o inefectiva, lo que a efectos prácticos implica que puede o no ser utilizada. Por ejemplo, es recomendable utilizar la técnica de análisis de protocolos cuando el eductor tiene una amplia experiencia en educción, mientras que su uso no es recomendado cuando su experiencia es baja. En el caso de una experiencia media, dicha técnica proporcionará resultados razonables, aunque no magníficos. En la tabla 2 se muestran los valores de adecuación de un conjunto inicial de técnicas frecuentemente utilizadas para la educción de requisitos. Nótese que este conjunto inicial podrá ampliarse en el futuro incorporando nuevas técnicas de educción.


96

Tabla 2. Adecuación del conjunto de técnicas de educción consideradas.

Atributos Valores

Ent

. Abi

erta

E.E

stru

ct.u

rada

O.T

.H.

Inci

dtes

.Crit

icos

Cla

s. C

once

ptos

Cue

stio

nario

s

Ana

l. P

roto

colo

s

Em

parr

illad

o

Tor

men

ta I

deas

T.N

om. G

rupo

Mét

odo

Del

phi

Ladd

erin

g

Obs

erv

Par

ticip

.

Pro

totip

ado

Foc

us G

roup

JAD

Esc

en./C

aso

uso

Alto √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

Bajo √ √ √ √ – √ – – √ √ – – √ – – – – Formación en Técnicas de Educción Nulo – – – – × – × × – × × × – – × × ×

Alta √ √ √ √ √ √ √ √ √ √ – √ √ √ √ √ √

Media √ √ √ √ √ √ – – – √ – √ √ √ √ – √ Experiencia en Educción

Baja – – √ – – – – – – – – – √ – – × –

Alta √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

Baja √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ Experiencia en la técnica de Educción Nula – – √ – – – – – – √ – – – – – × –

Alta √ √ – √ √ √ – √ √ – √ √ – √ √ √ –

Baja √ √ – – √ √ √ √ √ – √ √ √ – √ √ – Familiaridad con el Dominio Nula √ – √ – – – √ – √ – – – √ × × × –

Individual √ √ √ √ √ √ √ √ × × × √ √ √ × × √

Grupal – – √ – – √ × × – √ √ – √ – √ – – Individuos por Sesión

Masivo × × √ × × √ × × √ √ √ – √ – √ √ –

Alto √ √ – √ √ √ – √ – – – √ – √ √ – √ Consenso de Educentes Bajo – – – – – √ – √ – √ √ – – √ √ – –

Alto √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

Bajo – – √ – √ √ – √ – √ √ √ – √ √ – √ Interés del Educente

Nulo × – √ × – √ × √ × √ √ – × √ – × –

Experto √ √ – √ √ √ √ √ √ √ √ √ √ √ √ √ √

Entendido √ √ √ √ √ √ – √ √ √ √ √ √ √ √ √ √ Nivel de Pericia

Novicio – √ √ – √ √ – √ √ √ √ √ √ √ √ √ √

Alta √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

Media – √ √ √ √ √ – √ √ √ √ √ √ √ √ √ √ Capacidad de Articulación

Baja – – √ × √ √ × √ × × √ √ √ √ × × –

Alta √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

Media – √ √ √ √ √ – √ – – √ √ – √ – – √ Disponibilidad de Tiempo

Baja – √ √ – √ √ × √ × × √ √ – √ × × –

Lejano – – – × – √ × √ × × √ – × × × × × Localización/ Accesibilidad Cercano √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

Estratégico √ – – √ × √ √ × √ √ √ × – – √ √ –

Táctico √ √ √ √ × √ √ × √ √ √ × √ √ √ √ √

Tipo Información a Educir

Básico – √ – – √ √ × √ – – – √ √ √ √ × –

Táctico √ √ – √ – √ √ √ – √ √ – – √ √ √ √

Básico √ √ – × √ √ √ √ √ √ √ √ – √ √ √ √

Nivel de Información Disponible Nulo √ × √ × × × × × √ √ × × √ √ √ √ √

Alto – √ √ √ √ √ √ √ – – – √ √ – – – √ Grado Definición Bajo √ – – – – – – – √ √ √ – – √ √ √ –

Alta – √ × √ √ √ √ × × × × √ × × – × √

Media √ √ – √ √ √ – – – – – √ – – – – √ Restricción de Tiempo del Proyecto Baja √ – √ √ √ – – √ √ √ √ – √ √ √ √ √

Inicial √ – √ × √ – × × √ √ – √ √ – √ √ –

Intermedio – √ – √ √ √ √ √ – √ √ √ √ √ √ × √ Momento del Proceso

Avanzado – √ × √ × √ – – × – – × × – – × –


97

3.3 Procedimiento de Selección

La determinación de los valores de los atributos para un proyecto en particular permite obtener la información de entrada necesaria para seleccionar las técnicas candidatas para un plan de educción. Los valores excluyentes de cada atributo conforman el Contexto Situacional representado por una 16-tupla de valores base. El vector de valores, denominado C, sería:

C = (c1,c2,c3,…c16), donde ci es el valor determinado en el proyecto actual para el atributo i. Por ejemplo, C = (Nula, Baja,..., Intermedio), significaría que en el proyecto de desarrollo considerado, el eductor posee Nula (valor) formación en técnicas de educción (atributo), ya que no ha tenido ningún tipo de conocimiento de las técnicas. Respecto a su experiencia en educción (atributo), posee un valor Bajo debido a que ha realizado educción en menos de 2 proyectos de desarrollo, etc. La estrategia general para realizar la selección de las técnicas es una equiparación incremental de los valores de C con el esquema de Adecuación, A, que tiene la estructura de la tabla 3.

Table 3. Esquema de adecuación de técnicas de educción.

Técnicas Atributos Valores

t1 t2 … Tk

V1,1 a a a a

V1,2 a a a a AT1

V1,3 a a a a

V2,1 a a a a AT2

V2,2 a a a a

… a a a a

… a a a a …

… a a a a

V16,1 a a a a

… a a a a AT16

V16,j a a a a

En este esquema, obtenido en esta investigación: tk : es una técnica de educción de requisitos k, con k=1,17.

ATi : es el atributo de influencia i, con i=1,16. V i,j : es el valor j que puede tomar el atributo i, con i=1,16 y j={ 2,3}. a: es uno de los valores de adecuación definidos, con a= { –, √, ×}.

La estrategia a seguir genera un árbol con una serie de listas P sucesivas que representan las técnicas propuestas para la educción. Las listas pi son más fiables a medida que descienden en el árbol y contienen un conjunto de pares con cada técnica


98

y su ponderación de prioridad de elección. A mayor valor de ponderación, la técnica respectiva es más recomendada. Esta estrategia se presenta en la figura 2 y se define como:

Sf(A,C) → { P | P es un árbol de listas pi } pi = { (t1,w1), (t2,w2), …(tk,wk) | wk es ponderación de la técnica k con k=1,17 }

ATx

ATy

ATz ATz ATz

ATy

ATz

… … …

…

Vx,Vx,Vx,

Vy, Vy, Vy, Vy, Vy,

p1

p4

p3

pi

…

p0

Figura 2. Estrategia Procedimiento de Selección de Técnicas. En el árbol, la propuesta ideal es la que se obtiene en el nivel hoja que contempla todos los atributos. No obstante, si los atributos inferiores de la rama no establecen técnicas elegidas, por la configuración de valores del proyecto, será posible considerar alguna de las propuestas superiores, lo cual dará flexibilidad y éxito al procedimiento que siempre dará una solución al problema de selección. En particular, como se muestra en la figura 3, la propuesta ideal es la pi pero de no haber técnicas seleccionadas puede considerarse la p6, la p1, incluso la p0, consecutivamente. Para poder iniciar la función de selección antes descrita se debe establecer la prioridad o grado de influencia de los atributos en la decisión de selección de técnicas de educción. Estos atributos se han agrupado en tres conjuntos de creciente importancia: • Prescindibles: Atributos que aun siendo influyentes en el procedimiento de

selección, son los más probables ha ser desestimados si no se encuentran técnicas idóneas. Están en los niveles inferiores del árbol hasta llegar a las hojas.

• Relevantes: Atributos de gran importancia e influyentes en la decisión de selección que se evitará soslayar para obtener resultados. Se encuentran en los niveles medios del árbol.


99

ATx

ATy

ATz ATz ATz

ATy

ATz

… … …

…

Vx,Vx,Vx,

Vy, Vy, Vy, Vy, Vy,

p1

p4

p3

p8 p6

pi

p0

Figura 3. Propuesta de Educción del Procedimiento de Selección de Técnicas.

• Mandatarios: Atributos que obligan al procedimiento de selección y que

difícilmente podrían ser ignorados para elegir las técnicas. Están en los niveles superiores del árbol comenzando por la raíz.

Dentro de cada grupo, los atributos están ordenados por prioridad tal como se indica en la figura 4. Las propuestas de técnicas pi se obtienen sucesivamente a medida que se va considerando un atributo de influencia, es decir a medida que se desciende de nivel en el árbol. Así, pk+1 se obtiene a partir del pk, obtenido en el nivel anterior, relacionado mediante el operador σ con el pATi correspondiente al atributo agregado. El operador σ será explicado más adelante.

pk+1 = σ ( pk, pATi ) Para obtener el pATi se utiliza el operador π que captura los valores de adecuación de cada técnica para un atributo determinado considerando el valor ci. Estos valores asignan ponderación de preferencia a cada técnica conformando una lista de pares de la forma:

pATi = π (ci, ATi) = { (t1,w1), (t2,w2), …(tk,wk) } Particularmente para el p0 de la figura 3:

p0 = pATx = { (t1,wx1), (t2,wx2), …(t17,wx17) }


100

Figura 4. Relación de Influencia de los Atributos. Los valores tk son las técnicas de educción y los valores wk son pesos que se derivan de los valores de adecuación a como se muestra en la tabla 4:

Experiencia en Educción

Formación en Técnicas de Educción

Familiaridad con el

Dominio

Experiencia en la Técnica de

Educción

Interés del Educente

Localización/ Accesibilidad

Individuos por Sesión

Disponibilidad de Tiempo

Nivel de Pericia

Capacidad de Articulación

Tipo de Información

a Educir

Nivel de Información Disponible

Grado de Definición del

Problema

Restricción de Tiempo

del Proyecto

Momento del Proceso

Consenso entre

Educentes

PRIORIDAD GRUPO

MANDATORIOS

RELEVANTES

PRESCINDIBLES


101

Tabla 4. Asignación de ponderaciones a valores de adecuación.

a √ – ×

w 2 1 0

El operador σ permite derivar un plan de técnicas más idóneas para cada nivel:

pk+1 = σ ( pk, pATi ) , ó pk+1 = σ ( pk, π (ci, ATi)) Particularmente para el p1 y p6 de la figura 3:

p1 = σ ( p0, pATy ) , ó p1 = σ ( p0, π (cy, ATy)) y,

p6 = σ ( p1, pATz ) , ó p6 = σ ( p1, π (cz, ATz)) El operador σ genera una propuesta de educción p siguiente, más exacta y fiable, a partir de dos propuestas. Esta operación actúa sobre los valores de las ponderaciones de las propuestas generando para cada técnica un nuevo valor. Básicamente, el operador realiza un producto escalar de los vectores de valores de ponderación, es decir, realiza una multiplicación de los respectivos valores de ponderaciones de cada técnica. Si una técnica contiene una ponderación 0 (cero) en la propuestas del atributo a agregar, lo cual significa que no ha sido recomendada, la prescripción se mantiene. Si el valor es 1 (uno), lo que significa que es indiferente, se mantiene la ponderación acumulada. Si el valor es 2, lo cual significa que se recomienda la técnica, la ponderación se incrementa. Por ejemplo, un pi = {(t1,4), (t2,0), …(t17,12)} significaría que se recomienda principalmente el uso de escenarios/casos de uso y en segunda prioridad la entrevista estructurada, mientras que en ningún caso se debe utilizar la entrevista abierta.

4 Discusión

El marco propuesto mejora los trabajos realizados acerca del problema de selección hasta la fecha. Comparando la presente propuesta con Maiden y Rugg [16], así como con Davis y Hickey [9] (los dos trabajos más completos), pueden apreciarse las siguientes mejoras: � El número de atributos considerados supera a [16] y es comparable a [9]. � El número de técnicas de educción consideradas supera tanto a [9] como a [16]. � Se propone un valor de adecuación para cada combinación de cada valor de un

atributo contextual y una técnica de educción, al igual que [16]. � Se propone explícitamente un procedimiento de selección, a diferencia de [9] y

[16]. Adicionalmente, el trabajo descrito en el presente artículo representa únicamente una fracción de las líneas de trabajo que se están desarrollando en la actualidad, las cuales mejoran ostensiblemente a [9] y [18]. Dichas líneas son las siguientes: � La operación σ puede producir como resultado que ninguna técnica de educción

pueda ser considerada efectiva. No obstante, ello no es en modo alguno admisible, debido a que la educción debe llevarse necesariamente a cabo. Por consiguiente, el procedimiento de selección propuesto debe garantizar como


102

resultado no un conjunto único de técnicas efectivas, sino subconjuntos cada vez más extensos de técnicas de educción de variada efectividad.

� Del mismo modo, el contexto situacional puede ser más complejo que el anteriormente considerado. Concretamente, los factores no tienen por qué ser únicos, sino múltiples, y cambiar con el tiempo. Por ejemplo, en lugar de existir un único analista en el proyecto, pueden existir varios, como también varios pueden ser los clientes y usuarios en distintos momentos del proceso de educción. Por ello, en lugar de existir una única 16-tupla para definir el contexto situacional, pueden existir varias, lo que exige mayores refinamientos en el cálculo de la operación σ.

� Finalmente, y debido a lo antes indicado, la educción se torna como un proceso más complicado que la aplicación de la técnica de educción más efectiva por parte de un analista a un cliente/usuario. Muy al contrario, será necesario confeccionar un plan de educción que considere los distintos factores (analistas, clientes, etc.), las técnicas más efectivas y el orden de aplicación de cada una de ellas.

Los aspectos indicados anteriormente demuestran las interesantes posibilidades que plantea el marco propuesto y justifica la dedicación de mayores esfuerzos investigadores.

5 Conclusiones

El objetivo de esta propuesta es apoyar al proceso de educción en el uso de técnicas para la captura de requisitos. En este sentido, se propone un procedimiento sistemático para identificar las técnicas más adecuadas, ventaja que ninguna de las propuestas actuales posee. Además, el marco considera una importante cantidad de atributos, que podrá incrementarse con posteriores estudios, y define pertinentemente los valores que ellos pueden tomar y que pueden ser fácilmente asignados en un caso particular. El marco puede crecer, también, en el universo de técnicas consideradas en la medida que se estudien sus posibles valores de adecuación. Actualmente, se ha comenzado con la validación empírica del marco propuesto, diseñando la estrategia de validación, y en los próximos meses realizado experimentos que ensayen subconjuntos de atributos y técnicas. Junto con esto, se elaborará una herramienta software que soporte el marco.

Referencias

1. Loucopoulos, P., and V. Karakostas. Systems Requirements Engineering. McGraw-Hill, pp. 1995.

2. Boehm, B. W.; McClean, R. K., and Urfrig, D. B. Some experience with automated aids to the design of large-scale reliable software. IEEE Transactions on Software Engineering. 1975 Mar; 1(1):125-133.

3. Standish Group. The CHAOS Report. 2005 Oct 18.


103

4. Kovitz, B. Practical Software Requirements. Manning Publications Co. 1998.1. Loucopoulos, P., and V. Karakostas. Systems Requirements Engineering. McGraw-Hill, pp. 1995.

5. Jones, S. R. and Miles, J. C. “The Use of a Prototype System for Evaluating Knowledge Elicitation Techniques”. Expert Systems. 1998; 15(2):83-97.

6. Goguen, J., and C. Linde. “Techniques for Requirements Elicitation”. International Symposium on Requirements Engineering, Los Alamitos, California: IEEE Computer Society Press, January 1993, pp. 152-164.

7. Wooten, T. C. and Rowley, T. H. “Using anthropological interview strategies to enhance knowledge acquisition”. Expert Systems With Applications. 1995; 9(4).

8. Holtzblatt, K., and H. Beyer. “Requirements Gathering: The Human Factor”. Communications of the ACM, 38, 5 (May 1995), pp. 31-32.

9. Davis, A., and A. Hickey. "An Ontological Approach to Requirements Elicitation Technique Selection," in Ontologies in the Context of Information Systems, R. Ramesh, et al., eds., Kluwer Academic, 2005.

10. Dhaliwal Jasbir Singh and Izak Benbazat. “A framework for the comparative evaluation of knowledge acquisition tools and techniques”. Knowledge-Acquisition. vol.2, no.2; June; p.145-166. 1990.

11. Lloyd, W.J. “Tools and Methods for effective distributed requirements engineering: an empirical study”. Master Thesis. Virginia Tech, 2001. Available at: http://scholar.lib.vt.edu/theses/available/etd-07262001-110924/ 2001.

12. Agarwal R. and Tanniru M. “Knowledge Acquisition using Structured Interviewing: an Empirical Investigation”. Journal of Management Information Systems, 7, 1. Summer 1990, 123-140. 1990. El Emam, K., and N. Madhavji. “Requirements Engineering Practices in Information Systems Development: A Multiple Case Study”. Second International Symposium on Requirements Engineering, Los Alamitos, California: IEEE Computer Society Press, 1995.

13. Roth Roberta M. and William C. Wood II. “Knowledge Acquisition from single versus multiple experts: a field study comparison using the Delphi technique”. The journal of Knowledge Engineering. Volume 6, Number 3. Fall. 1993.

14. Burton-AM; Shadbolt-NR; Rugg-G; Hedgecock-AP. “The efficacy of knowledge elicitation techniques: a comparison across domains and levels of expertise”. Knowledge-Acquisition. vol.2, no.2; June; p.167-78. 1990.

15. Chao-C-J; Salvendy-G. “Impact of cognitive abilities of experts on the effectiveness of elicited knowledge”. Behaviour and Information Technology. vol.14, no.3; May-June 1995; p.174-82. 1995.

16. Maiden, N., and G. Rugg. “Knowledge Acquisition Techniques in Requirements Engineering”. In Proc. Of the Workshop on Requirements Elicitation for Systems Specification, Keele, UK, July 1994.

17. Byrd, T.A., Cossick, K.L. and Zmud, R.W. “A Synthesis of Research on Requirements Analysis and Knowledge Acquisition Techniques”. MIS Quarterly, 16, 117-138. 1992.

18. Kim J. and J. Courtney. “A survey of knowledge acquisition techniques and their relevance to managerial problem domains”. Decision Support Systems, 4, 1988.

19. Carrizo M. Dante. “Selección de las Técnicas de Educción de Requisitos: Una Visión Conjunta de la Ingeniería de Software y la Ingeniería del Conocimiento”. Proceedings JIISIC ’04. Madrid, España, 2004.

20. Carrizo D. y O. Dieste. “Atributos Contextuales Relevantes para la Selección de Técnicas de Educción Requisitos”. Proceedings JIISIC’06. Veracruz, México, 2006.

21. Dieste, O., Davis, A., Juristo, N., Hickey, A., Moreno, A. “Revision and aggregation of empirical evidences regarding elicitation techniques”. Submitted to the International Journal of Empirical Software Engineering, 2006.


104

Sesión 4 Ingeniería de Requisitos

105

Discovering Group Communication Requirements

Igor da Silva Miranda1, Renata Mendes de Araujo2, Marcos Roberto da Silva Borges1

1 Post-Graduate Program in Informatics, IM&NCE, UFRJ, POBox 2324, Rio de Janeiro, RJ, 20001-970, Brasil

[email protected], [email protected] 2 Department of Applied Informatics, UNIRIO, Av. Pasteur 458, Urca, Rio de Janeiro, RJ,

22290-240, Brasil [email protected]

Abstract. Communication is one of the most important aspects to promote collaboration within organizations. The way communication takes place in a collaborative interaction is intrinsic to the nature of the group, the task to be performed and the environment where it occurs. Nevertheless, we observe that most groupware applications relies on basic communication channels, such as chat and message systems, and do not explore other possible communication requirements for each particular situation. This research work proposes a method to guide the definition of group communication requirements. It presents a conceptual framework for group communication aspects based on human communication and computer mediated communication that will be used in the method as a guide for identifying communication requirements.

Keywords: group communication, system requirements, groupware.

1 Introduction

In recent years, organizations have perceived that group work may improve the productivity and the quality of their business results. They have understood that the exchange of experiences and knowledge among group members increase their ability to produce better results. Thus, many organizations have been trying to promote the establishment of formal and informal work groups.

One way to encourage group work is to support communication, coordination, awareness and group memory through collaborative systems [1][11]. Communication is an important aspect, if not the most important of them, since only through communication the other collaboration aspects may occur.

Nevertheless, the identification of communication requirements in collaborative systems is not a simple task. Often, designers of collaborative systems adopt general and common communication channels such as chat and messaging systems. This decision does not take into consideration the specific communication requirements for certain groups and for particular contexts. This work assumes that it is necessary to understand how communication takes place in a specific context, before defining its supporting requirements.


107

Another important issue discussed in this work is that very often opportunities for improving collaboration within organizations are neglected. Information systems developed to support the organization’s business processes have an embedded and undisclosed collaborative component. The potential collaboration that may exist in a business process is not properly explored by the supporting information system.

The purpose of this paper is to present a method to guide designers of information systems in the identification of group communication requirements. The method is based on a framework, which assembles and organizes aspects of group communication. The framework provides a theoretical basis that can be used by system designers at each method step.

The paper is divided into 5 sections. Section 2 presents the framework, which is the starting point to pursue the method; Section 3 presents the method. We present a case study on the use of the proposed method in Section 4; and Section 5 concludes the paper and points out future work.

2 A conceptual framework for communication aspects

To perform the identification of communication requirements, the system designer must know which communication aspects should be analyzed in a collaborative context. In order to help this analysis, a conceptual framework for communication aspects is proposed based on information gathered from literature. The framework does not aim to cover all the possible communication aspects but it comprises those which are relevant for the requirements definition and, consequently, for the software development.

The aspects are: time-space, flexibility, symmetry, affectivity and formality. Each aspect is described in the framework by means of factors that affect them. Factors can be considered as variables that combined configure the aspect.

Table 1. Conceptual framework for communication aspects

Aspect: Time-Space Aim: This aspect aims at determining when and where messages should be sent and received during an interaction. Interactions occur in a defined time with each participant located in one defined place [11]. However, the boundaries of time and space are not always evident, allowing them to change [7].

Time. A synchronous interaction occurs when participants interact at the same time. Both need to be available and prepared to interact and should have access to the necessary communication resources. In an asynchronous interaction the time is more flexible. It is not possible to know when the messages will be received or sent.

Factors:

Space. Participants can interact sharing the same physical place (face-to-face interactions) or they can be located at different places (remote interactions).


108

Aspect: Flexibility Aim: Flexibility deals with the autonomy that participants have or not to build messages and to structure their interaction.

Message Construction. Messages have a format. In some cases the format is explicit to the participant and in other cases is not. When this format is highly structured, the participant has little freedom to elaborate his messages. For example, most chat and e-mail systems let the users write the content of the message in a free format. Other situations require users to follow a pre-defined format such as a letter or a form. Structure of the Conversation. An interaction is characterized as a sequence of messages being exchanged. The way these messages are organized during the conversation is important for its understanding. According to [12], there are three modes of structuring conversation: sequential, hierarchical and networked. In sequential conversation, the chronological order of the messages is evidenced. However, the relationship among messages can provoke problems as the loss of context [21]. The hierarchical structure allows message organization as a tree, based on the relationship among them. It facilitates the understanding, since messages are organized by their subject. The networked structure enables the construction of complex relationships among messages. Many relations can be created, stimulating conversation. On the other hand this model of interaction can become very complex to follow, specially in anssynchronous interaction.

Factors:

Interaction Protocol. The interaction protocol can be established explicitly or emerge naturally. We suggest four interaction protocol types: sequential, order independent, intercalative and concurrent. In a sequential protocol, people follow a predefined order and they cannot be interrupted during their participation. The order independent protocol is similar, except for not having an order. In intercalative protocol only one person can speak for a time, but another participant can interrupt him. Concurrent protocol allows parallel conversations, as well as interruptions.

Aspect: Symmetry

Aim: This aspect is to establish the similarities and differences of available resources for each participant. These differences can influence the contribution of each participant [15].

Messages direction. Unidirectional communication happens when the messages are originated always from the same source and for the same receivers while the bidirectional communication takes place when any participant can be both sender and receiver. In unidirectional communication, the roles of the sender and the receivers are clearly assigned. That is what happens in formal interactions such as lectures and announcements; and is sometimes an instrument to influence receivers. The bidirectional communication is a more symmetrical interaction where all participants are able to influence and to be influenced. Number. An interaction does not occur only between two individuals. Different means of communication such as telephone, chats, radios, etc, allow one person to communicate with many persons. Each combination (one to one, one to many, many to many) is considered a relation to be explored by supporting mechanisms.

Factors:

Resources Availability. During an interaction, participants may not access the same communication resources [15]. As an example, in some distance education applications, where the interactions occur through an audio channel, the teacher can observe the students through video, while the reverse is not possible. Sometimes, the disparity of resources can cause conflicts to some participants who feel harmed during the interaction [1].


109

Aspect: Affectivity Aim: Affectivity is understood as the emotions that participants are able to send and receive during an interaction, especially through nonverbal elements.

Closeness. The emotional distance can limit the influence that one participant has over others [1]. However, this distance can also make communication more objective since participants can speak freely between them [8]. The level of closeness can be influenced by the possibility of sending non-verbal elements during the communication [17][19].

Factors:

Trust. The concept of trust is related to how participants can be confident on other participants and in respect to their own interaction. Whenever one participant gathers more information about others and about how the interaction occurs, more self-confident he becomes [16][23]. In an interaction where anonymity is allowed, for instance, people tends to fell less exposed and this reflects on the way the interaction goes.

Aspect: Formality

Aim: This aspect is related to the degree of formality that a message must follow. It is highly related to the affectivity and the flexibility of the communication process.

Agenda. Most formal interactions follow an agenda, the simplest it can be. However, depending on the characteristic of the interaction the agenda is elaborated and published so that the participants can prepare themselves for the interaction. In other situations, the agenda is elaborated in the beginning of the interaction in accordance with the subjects and issues brought by the participants. In informal and short duration interactions, the elaboration of an agenda is generally not necessary. Definition of Participants. In some cases it is important to define previously who the participants of the interaction will be. When a person is assigned in advance, he is able to get prepared, and dispose the required resources for the interaction. In other situations, participants´ admission occurs during the interaction; it can be free or through approval of the group or of a mediator. Role Definition. The assignment of tasks to roles is typical in formal interactions. Even if the assignment is made before or during the interaction, the presence of roles reveals some kind of formalism in the interaction. Opportunity. The prior arrangement of the interaction is very important in order to let participants adjust their schedules and be prepared. However, [18] and [28] affirm that the majority of the interactions are opportunistic, or either, they initiate without any planning. This type of interaction starts informally, but allows that the participants to argue different work subjects. Record of the Interaction. Recording an interaction can be very helpful for the organizational memory. This record makes possible to understand how some decisions had been taken, and correct potential problems. Nevertheless, interactions should become very formal, and in some cases, it can inhibit fluency. In informal contexts, interactions are generally not recorded.

Factors:

Interaction Context. The context where an interaction occurs has direct influence on its formality. An interaction that has informal features can assume a formal behavior, when it is into formal context. That can occur in the inverse situation too.


110

3 The method

This work claims that traditional methods for identifying system requirements can be enhanced in order to comprise the issues related to group communication. Therefore, we propose a method – MDRcom – comprising a sequence of phases, which helps to explicitly discuss communication requirements during system elicitation. The proposed framework is used by the method to guide system designers in finding relevant communication supporting needs for the system being developed.

The first step in this method is to define what a communication requirements is. In MDRCom communication requirements are the set of system requirements that define the characteristics that must be addressed by the system in order to support the group communication needs. According to Watzlawick [27], communication is composed by interactions. In this work we define interaction as any message exchange among participants with the intention of establishing communication. A message is defined as a set of structured visual, auditive and audiovisual signals shared by participants. A message has a beginning and an end, so it can be isolated and identified [27].

Next, MDRCom defines what is the basic unit for identifying communication requirements in a given situation. For this purpose, MDRCom defines the concept of way of interaction (WI). A WI is a generalization of communication interactions that have the same characteristics and can be equally analyzed and treated. For example, an attendant in a helpdesk answers to several calls daily. Considering each call as an interaction, and that they usually have the same characteristics, it can be said that they compose the same way of interaction between customers and attendants.

MDRCom assumes that the organization’s business processes are the starting point for identifying system requirements [2]. Business processes models are the input for describing how the organization operates and help to identify what work routines should be automated. As an input to MDRCom, business processes are a basis for contextualizing where communication requirements should be searched.

Another input of MDRCom is the conceptual framework presented in the previous section. The framework will help the designer in discovering and classifying communication requirements by analyzing the interactions that occur within the organization’s portion of the processes being analyzed. Finally, the MDRCom takes into account the system users´ information, expectations and needs. As a result, MDRCom expects that a set of communication requirements can be produced and added to the system’s requirements documentation (Figure 1).

Fig. 1. Method overview


111

The MDRCom is based on the idea that the first step to identify system communication requirements is to understand how it occurs, independently from a computer-supported solution. Due to the fact that communication is composed by interactions (as explained in section 2), it is possible to understand that it is important to identify the ways of interaction (WIs) that compose a specific group or work process context. After identifying the ways of interaction, it is possible to characterize each one based on the aspects organized in the framework, leading to its specific supporting needs. The MDRCom has 3 phases that will be sequentially performed by a system designer to obtain a clear and detailed understanding of communication interactions and their characteristics (Figure 2).

Fig. 2. Phases of the MDRCom

3.1. Identifying Ways of Interaction

While performing an activity, participants communicate by using different ways of interaction among them. Each WI has specific characteristics and contributes to the activity in a special manner. To identify which WIs exist is the first step to understand how the can be supported latter. This phase can be divided into the following steps:

Selecting participants. The designer can choose from the scope of the business process selected for analysis the roles that were defined to perform process activities. Representatives of these roles are candidates for participating in a brainstorm session for identifying ways of interactions. It is important that all roles are represented in the discussion in order to provide different points of view about the communication. A facilitator may also be defined to conduct the method dynamics and discussions. The facilitator can be one any of the participants selected or the designer.

Turning interaction explicit. Participants are invited to expose how they individually see the interaction that occurs during the activity/process. The method suggests the application of a group dynamics to capture this information. This dynamic is based on CRC cards [4], from object-oriented design. The basic use of a CRC cards is that each participant can write on a card what are his responsibilities in that activity and with whom (persons or other roles) he interacts/communicate in order to perform it [6] (Figure 3).

The purpose of this dynamics is to make this step more collaborative. Participants can share their views using the cards and make a sense about the overall communication, learning and criticizing about it.


112

Fig. 3. A CRC card registering how a communication is perceived by one participant

Preliminary Representation. Information captured in the previous step must be formally registered using the Ways of Interaction Model. The interactions identified in the cards must be graphically represented and presented to participants for visualization and validation. Figure 4 presents a simplified representation of a possible way of interaction where a teacher answers to students’ issues and the students report that they make questions to the teacher. Each line represents a view of an interaction reported by each participant.

Fig. 4. Example of a ways of interaction model

Refinement. Inconsistencies can be identified after the translation of the information captured in the cards to the graphical representation in the model. The objective of this step is to eliminate them as also as to stimulate the discussion among participants in order to reach consensus. Figure 5 presents a refined version of the model resulted as presented in Figure 4. If both participants of this interaction – teacher and student – agree that they refer to the same WI, so it can be considered that this WI exists and can be explicitly represented as in Figure 5.

Scope definition. Based on the WIs identified in the model, it is possible to select those that will be considered in the following phases of method. The selected WIs will be those that the designers and participants agree that are candidates for automated support.


113

Fig. 5. A refined view of the WI model

3.2. Characterizing Ways of Interaction

The aim of this phase is to look at each WIs selected on the preceding phase and to try to have a deeper understanding of its nature. Thus, each WI will be separately analyzed. Two steps comprise this phase:

Describing WIs. Each WI must be briefly described so that the designer can document it and enforce his understanding about it. Taking Figure 5 as an example, the WI there represented can be described as: “This WI describes the moment when students can solve doubts with the teacher”

Analyzing WIs. At this step, the designer will try to analyze each WI based on the communication aspects framework presented in Section 2. To analyze the characteristics of an interaction may require the use of observation techniques, such as ethnography [14]. Using or not this kind of technique may be restricted to the project’s schedule and budget and to the designer’s competence in doing it. The communication aspects framework will be used here like a checklist, indicating each aspect that the designer must analyze/observe. The framework does not describe how the designer will find the information but just what to look for in order to describe the WI.

There is no exact order to follow the framework checklist. However, the framework was organized in a sequence that facilitates the analysis. For instance, aspects like flexibility and affectivity appear before formality because the framework considers that the latter can be easier understood if the former are already known. Table 2 presents an example of the results of the execution of this stage, using the example of Figure 5.

3.3. Defining System Requirements

The aim of this phase is to guide the designer into defining system requirements based on the characterization obtained in the previous phase. It is important to notice that the MDRCom does not have the objective of specifying requirements but just to identify them. As mentioned by Sommerville [25], the requirements definition aims at describing requirements in a way that users and designers without the need of using a


114

special notation or formalism can understand them. In the requirements specification activity, on its turn, a formal notation (diagrams) is used and it is necessary special skills or qualification to interpret it.

Table 2. Example of the results of the second phase

WI: To solve doubts with the teacher Description: A student, outside the classroom, can make questions to a teacher. Time-space Time The interaction must be asynchronous to allow the teacher to access

available material. Answers must be given within a defined period of time.

Space students and teachers can be in different places … … Formality Record of the Interaction

All the interactions are registered, comprising a memory that can be further searched by teachers.

… … Therefore, the final result of MDRCom is the collection of information necessary

to define communication requirements. The MDRCom supposes that all its comprising steps can be conducted in parallel with traditional requirements gathering, being communication another aspect to be considered. This phase comprises the following steps:

Identifying needs. In this step, each factor that will be supported must be described as needs that will be treated by the system. To identify needs, it is necessary to understand that the information obtained in the previous step are related to the WIs and not yet to the system. Therefore, it is important to identify from the preceeding analysis, what would be the main system characteristics.

To maintain the system requirements rationale, each identified system need must be registered associated to WI and the framework aspect that originated it.

Considering the factor Time in the example of table 2, the following need can be identified: “The system must manage the answer time of each teacher.”

Identifying functionalities and restrictions. Once the system needs have been identified, the next step is to describe how it will support them, i.e., to identify the system functionalities. For each identified system need, it is necessary to describe through which functionality it will be achieved, as well as eventual restrictions.

In that step, it must be obtained information such as: allow asynchronous interactions and notify the teacher when the deadline for answering the question has arrived.

Defining user access. This step aims at defining users’ system access, i.e., to define which users have access to which functionalities. This information can be found by


115

analyzing the WIs in terms of suitable factors for providing this information, such as: Resource Availabity, Messages Direction, and Message Construction.

Example: “Just teachers can access a database of previous interactions.”

Building a data dictionary. In this step, the analyst must define the information content that will be organized and registered by the system. Thus, a set of data concepts related to communication can be outlined and described and further incorporated to the system’s overall data model and dictionary. Some factors are specially interesting for helping to discover these concepts, such as Message Construction.

Final Review. This step proposes the review of the defined requirements trying to guarantee their conformance with the whole set of requirements identified for the system and if they are addressing users’ expectations. It is important to observe if there is no conflict or redundancy among requirements and if none of the communication requirements violate organization’s business rules or project restrictions.

4. Case Study

A case study was conducted in order to verify the applicability of MDRCom as also as to verify if its outcome would be requirements that represents a set of group communication supporting needs. The case study was conducted in the context of a research project [3][22], which aims at specifying an environment for supporting collaborative social networks for software process improvement – the RCC-Sw. Collaborative networks are a kind of social organization or community that facilitates participants in performing collaborative actions towards a common objective. Through this network it is possible to mobilize people, even remotely located, to perform collaborative projects and actions. Communication among participants is of course a key aspect for the network dynamics. MDRCom was used, then, to identify communication requirements for the supporting environment for the RCC-Sw.

The sample. The team that took part on the case study was composed by the members of the research project – four researchers from IS area, two senior software developers and two undergraduate students. Among the researchers, only three of them were experienced in groupware and groupware development. However, all of them were senior requirements analysts. Among the software developers, both had experience with requirements gathering but only one of them had experience in groupware development. The undergraduate students had naive experience in both areas. Participants were divided into two groups, based on their profiles, to form an experimental group – the group that would use MDRCom – and a control group – the group that would identify requirements using any method they wanted, instead of MDRCom. An observer had been included in each group to analyze the work.


116

Scenario. To start the method execution within the experimental group, one of the RCC-Sw processes were presented. The chosen process was the one who deals with how the network rules should be changed and approved by network members (Fig 6).

Fig. 6. Process description for changing the network rules.

Results. The questions we wanted to answer with this case study were: Question 1: The method can be performed as specified? To answer this issue, we tried to observe the results of each method phase and to evaluate if they represented the expected results. This evaluation was performed through reviewing the documents elaborated during the method execution. It was observed that all the method steps were performed and the results obtained were satisfactory and corresponded to what was expected as a result. Question 2: What were the barriers or difficulties faced by designers while using the method? Through observation, interviews and by analyzing the generated documents and results, we collected the number of doubts, errors and the amount of time necessary to complete the method. Participants reported some doubts on methods concepts that needed to be further explained. Question 3: The obtained requirements represent the group communication needs? As also as the previous question, observations, interviews and document analysis were used to identify the level of requirements detail and description obtained, the clarity of the results and the acceptance level of designers about the method. Participants reported that the results obtained would be hardly obtained if no method were applied. Discussion. From the results obtained by the control group (the one which did not use the method), it was possible to observe that participants were concerned at specifying the communication mechanisms that would be incorporated in the system instead of understanding the characteristics that the software should have in order to support this specific collaboration context. Furthermore, designers did not focus on a specific process and defined requirements in a broader way, focusing all the system. The final definition comprised the identification of all the roles (external users, agents, work groups, secretary and support) that interact with the system as well as the communication mechanisms that will be provided classified as synchronous (chat)


117

and asynchronous (email, discussion form, and whiteboards). Also de cardinality of interactions using each mechanism

The results obtained by the experimental group (using the method) showed a very detailed requirements definition. The group identified 5 FIs for the process under analysis involving its participants (Submit for approval – Author/Agent, Send/receive suggestions for change – Author/Secretary, Notify result/receive notification-Secretary/Agent, Send/receive voting result – Agent/Author, Discuss Proposal – Agent/Agent). The analysis of each interaction resulted in a rich characterization of FIs and consequently, requirements. It was generated more than 50 requirements, both functional and non-functional.

It was possible to identify a small amount of intersections between the set of requirements gathered by the experimental group and the control group, such as having asynchronous ways of interaction through email and discussion forums. However, issues like anonymity, the need for recording interactions and discussions, associating them to the suggestions under approval, voting mechanisms among others, showed that the method helped the identification of a richer detail of requirements. The table bellow shows some examples of identified requirements that were not detailed or identified by the control group.

Table 3. Example of requirements identified by the experimental group

PROCESS: Change Network Rules FI Aspect Factor Requirement Roles Submit for approval

Formality Record of the interaction

The system must register the messages exchanged

Agent, Author

Send/receive suggestions for change

Flexibility Message construction

The system must allow the Author to highlight the changes in the text before sending it to the Secretary

Author, Secretary

Send/receive voting result

Formality Role definition

The system must allow the identification of the coordinator of the voting interaction

Agent, Author

Send/receive voting result

Affectivity Trust The system must allow anonymity Agent, Author

Another benefit of the method was that the rationale of each requirement was

recorded by associating each requirement to a specific way of interaction (WI) and to the business process.

Limitations. Time was the main limitation of the case study. Two weeks were spent for presenting the method and performing it. A longer period of time as well as additional training on the method steps would probably influence the results, since participants would be more able to perform the method activities. Another limitation was that the case study focused on only one business process. Analyzing more processes would have enriched the discussions and the resulting requirements.


118

6. Conclusion

This research has been motivated by the growing need of organizations to support collaborative work. It is argued that it should be profitable to consider collaboration supporting aspects while identifying system requirements to support organizations’ business processes. Communication was the collaborative supporting aspect considered in this work. A framework and a method – MDRCom – were proposed in order to accomplish the task of identifying communication requirements.

The case study points out to evidences that the use of MDRCom helps designers to get a deeper understanding of the communication needs and, further, can define more suitable supporting requirements. However, more case studies must be conducted in order to assess its efficiency. Another possibility of future work is to specify and build a supporting tool to help designers in performing the method steps.

Finally, the contributions of this research – the framework and the method – are a first step for characterizing, respectively: group communication requirements and how to consider and organize them in a requirements elicitation process. Further steps of this research would be to formalize the aspects in the framework as non-functional requirements [9] and to formalize MDRCom with existing requirements elicitation techniques [10][20] and notations [29].

Acknowledgments. The authors would like to thank the members of the RCC-Sw for participating in the case study.

References

1. Araujo, R.M., Borges, M.R.S., Dias, M.S. A Framework for the Classification of Computer Supported Collaborative Design Approaches. In: III CYTED-RITOS International Workshop on Groupware, 1997, Madrid.

2. Araujo, R. M. ; Mknight, D. ; Borges, M. R. S. A Systematic Approach for Identifying System Requirements from the Organization´s Business Model. In: Simpósio Brasileiro de Sistemas de Informação, 2005, Florianópolis, 2005.

3. Araujo, R. M., Dutra, J.R., Cappelli, C. Software Process Improvement through Social Networks. In: 8th International Workshop on Learning Software Organizations, 2006, Rio de Janeiro. v. 1. (2006.) 69-76.

4. Beck, K.: Think Like An Object. UNIX Review, (1991) 39-43. 5. Blois, A. P. T. B., Becker, K.: A Component-Based Architecture to Support Collaborative

Application Design. In Proceedings of 8th International Workshop on Groupware: Design, Implementation and Use. Springer-Verlag, (2002) 134–146.

6. Cain, B. G., Coplien, J.O.: A Role-Based Empirical Process Modeling Environment. In Proceedings of Conference on The Software Process, Berlin, (1993) 125-133.

7. Cockburn, Greenberg, S.: "Making contact: Getting the group communicating with groupware." In Proc. ACM Conf. on Organizational Computing Systems, Milpitas, (1993) 31-41.

8. Condon, J. C.: When people talk with people. Basic Readings in Communication Theory, 10 ed., C. D. Mortensen, Ed. New York: Haper & Row, Publishers, (1973) 45-63

9. Cysneiros, L.M. do Prado Leite, J.C.S. Nonfunctional requirements: from elicitation to conceptual models. IEEE Transactions on Software Engineering, vol. 30, n. 5, 2004, pp.328-350.


119

10. Easterbrook, S. Yu, E. Aranda, J. Yuntian Fan Horkoff, J. Leica, M. Qadir, R.A. Do viewpoints lead to better conceptual models? An exploratory case study. In: 13th IEEE International Conference on Requirements Engineering, Paris, 2005. pp 199-208.

11. Ellis, C. A., Gibbs, S. J., Rein, G. L.: Groupware: Some issues and experiences. Communication of ACM, 34 (1991) 38-58

12. Gerosa, M. A., Pimentel, M., Fuks, H., Lucena, C. J. P.: Analyzing Discourse Structure to Coordinate Educational Forums. In Proceedings of 7th International Conference on Intelligent Tutoring Systems - ITS-2004, Maceió, (2004) 262-272

13. Gibbs, S. J.: LIZA: an extensible groupware toolkit. In Proceedings of the SIGCHI conference on Human factors in computing systems: Wings for the mind, (1989) 29-35

14. Goguen, J.: Techniques for Requirements Elicitation. In Proceedings of Requirements Engineering '93. IEEE Computer Society, New York (1993) 152-164.

15. Greenspan, S., Goldberg, D., Weimer, D., Basso, A.: Interpersonal trust and common ground in electronically mediated communication. In Proceedings of 2000 ACM conference on Computer supported cooperative work. Philadelphia, (2000) 251-260.

16. Jarvenpaa, S. L., Leidner, D. E. Communication and Trust in Global Virtual Teams, Organization Science, Vol. 10, No. 6, Special Issue: Communication Processes for Virtual Organizations (1999) 791-815

17. Kiesler, S., Siegel, J., MCGuire, T. W.: Social psychological aspects of computer-mediated communication. Computer-supported cooperative work: a book of readings, I. Greif, Ed. Morgan Kaufmann Publishers Inc., (1988) 657–682.

18. Kraut, R., Fish, R., Root, R., Chalfonte, B.: Informal Communication in Organizations: Form, Function, and Technology In Proceedings of Human Reactions to Technology: The Claremont Symposium on Applies Social Psychology. Beverly Hills, (1990) 287- 314.

19. Mehrabian, Communication without Words, Basic Readings in Communication Theory, 10 ed., C. D. Mortensen, Ed. New York: Haper & Row, Publishers, (1973) 91-98

20. Moreira, A., Araújo, J. Rashid, A. A Concern-Oriented Requirements Engineering Model, Advanced Information Systems Engineering, Lecture Notes in Computer Science, vol. 3520/2005, pp. 293-308.

21. Pimentel, M.G., Fuks, H., Lucena, C.J.P.: Co-text Loss in Textual Chat Tools. In Proceedings of 4TH International and Interdisciplinary Conference on Modeling and Using Context - CONTEXT 2003. Stanford, (2003) 483-490.

22. RCC-SW: Projeto de Redes de Colaboração e Conhecimento para Melhoria dos Processos de Desenvolvimento de Software. Available: http://www.uniriotec.br/~rcc-sw/ (2005)

23. Rocco, E.: Trust breaks down in electronic contexts but can be repaired by some initial face-to-face contact. In Proceedings of the SIGCHI conference on Human factors in computing systems, Los Angeles, (1998) 496-502

24. Roseman, M. and Greenberg, S.: GroupKit: A groupware toolkit for building real-time conferencing applications. In Proceedings of the ACM CSCW Conference on Computer Supported Cooperative Work, ACM Press, Toronto, (1992) 43-50

25. Sommerville, I., Software Engineering. Boston: Addison-Wesley Longman Publishing Co. (1989)

26. Sommerville, I., Bentley, R., Rodden, T. and Sawyer, P.: Cooperative Systems Design. The Computer Journal, 37, 5, (1994) 357-366.

27. Watzlawick, P. B., Jackson, D.D.: Pragmatics of Human Communication, London: Faber, (1968)

28. Whittaker, S.: Video as a technology for interpersonal communications: a new perspective In Proceedings SPIE, (1995) 294-304

29. Yu, E., Mylopoulos, J., Lespérance, Y., AI Models for Business Process Reengineering. IEEE Expert: Intelligent Systems and Their Applications, vol. 11, n. 4, 1996, pp. 16-23.


120

Comparação do Impacto do Uso de Um Processo de Engenharia de Requisitos Entre Grupos de

Desenvolvimento de Software – Um Estudo de Caso

Elias Canhadas Genvigir1 2, Nilson Sant´Anna1

1Universidade Tecnológica Federal do Paraná (UTFPR) Av. Alberto Carazzai, 1.640 – 86300-000 – Cornélio Procópio – PR – Brasil

2Instituto Nacional de Pesquisas Espaciais (INPE)

Av. dos Astronautas,1.178 – 12227-010 – São José dos Campos – SP – Brasil {elias, nilson}@lac.inpe.br

Resumo. O uso de processos no desenvolvimento de um projeto de software constitui uma das fontes de esforços na pesquisa em Engenharia de Software. Experimentos são realizados usando dados de diferentes projetos, mas poucos trabalhos usam a comparação entre grupos que desenvolvem um mesmo projeto. Este trabalho faz uso da execução de um experimento, realizado sobre um mesmo projeto, para avaliar os requisitos de grupos que utilizam ou não um determinado processo para Engenharia de Requisitos. O quanto um processo de Engenharia de Requisitos impacta nos requisitos levantados é o foco principal deste trabalho. Análises estatísticas foram realizadas e seus resultados foram usados para explorar três perguntas sobre os requisitos além de reportar os resultados mais evidentes sobre o efeito do uso de um processo sobre a qualidade dos requisitos levantados.

Palavras Chaves: Engenharia de Requisitos, Processos de Software, Experimentação de Software.

1 Introdução

É de vital importância para o sucesso do projeto de software a gerência de seus requisitos. Este sucesso, por sua vez, está baseado na expectativa do usuário e na forma pela qual suas necessidades serão atendidas por esse software.

A engenharia de requisitos concentra-se nas necessidades e expectativas sobre o software sendo rica em complexidade e várias são as técnicas que podem ser utilizadas para o gerenciamento de requisitos. Entre essas complexidades pode-se citar o grande volume de requisitos levantados nos projetos modernos de software, a forma de representar um processo e a maneira na qual os requisitos podem ser modelados.

É papel da engenharia de requisitos criar mecanismos para manter o equilíbrio das necessidades dos usuários em relação ao que o software deve realizar, ou seja, ela deve assegurar que o produto de software atenda seus objetivos, tanto do ponto de vista do usuário como do ponto de vista técnico e do negócio em questão. Para tanto


121

uma metodologia de trabalho deve ser adotada para a especificação de requisitos do software, mas qual o impacto que um processo modelado pode causar em grupos de desenvolvimento que aplicam pela primeira vez um determinado processo?

O artigo apresenta os resultados obtidos na execução de um experimento sobre um processo de engenharia de requisitos. Para tanto foi utilizado um estudo de caso para observar questões relacionadas ao uso ou não de um processo modelado e qual o grau de impacto na qualidade dos requisitos levantados durante o experimento. Um processo modelado é compreendido, neste estudo, como a representação de atividades do mundo real para um processo de produção de software sendo desenvolvido e modelado por meio de um meta-processo e representado por uma linguagem de modelagem de processos [1].

O experimento foi realizado através do uso de grupos de trabalho, os quais tiveram que levantar os requisitos de um dado sistema fazendo uso ou não do processo modelado de engenharia de requisitos.

2 Questões Pesquisadas

O estudo reporta as contribuições mais evidentes realizadas no experimento, focando três perguntas que orientaram o trabalho:

1. É significativa a diferença na qualidade dos requisitos levantados entre equipes de desenvolvimento que usam um processo modelado de engenharia de requisitos e equipes que não usam um processo modelado?

2. O uso pela primeira vez de um processo modelado de requisitos por uma equipe de desenvolvimento impacta significativamente a qualidade dos requisitos?

3. A representação de requisitos através de casos de uso facilita a elicitação dos requisitos de um sistema?

A necessidade de obter informações sobre a execução e a qualidade de artefatos gerados por um processo modelado de requisitos orientou a investigação sobre o quanto esse processo pode inferir positivamente ou não no levantamento dos requisitos de um sistema. Mas a avaliação de qual deveria ser o processo de requisitos a ser utilizado deixava lacunas a respeito do conhecimento prévio dos membros dos grupos sobre processos já existentes o que poderia interferir nos resultados. Para solucionar este problema um novo processo de requisitos baseado nos principais processos existentes e modelado em uma linguagem de definição de processos foi definido para o experimento.

3 Modelo Para o Processo de Engenharia de Requisitos

A definição do processo levou a pesquisa sobre os trabalhos desenvolvidos na área Davis [2], Jarke e Pohl [3], Sommerville [4], Macaulay[5], Jalote [6], Sommervile e Sawyer [7], Graham [8], Pohl [9], Kontonya e Sommervile [10]. Foi observado que os autores especificam de forma abrangente o processo de engenharia de requisitos e que é grande a preocupação com sua divisão em grandes atividades e na concentração


122

de esforços pela determinação de seus campos de conhecimento. Por outro lado as normas e os modelos investigados: ISO 15504 [11], ISO/IEC 12207 - Software Life Cycle Processes [12], SW-CMM- The Capability Maturity Model for Software [13], RUP - Rational Unified Process [14], SWEBOK – Guide to the Software Engineering Body of Knowledge [15], MPS.BR - Modelo de Melhoria do Processo de Software Brasileiro [16]; destacam com maior ênfase as tarefas, ou seja, como e o que deve ser feito pelo processo. De modo geral, tanto os modelos e normas quanto os autores não especificam de forma totalmente ampla as atividades que compõem o processo e o campo de conhecimento as quais elas compreendem.

O modelo proposto neste trabalho levou em consideração as observações dos autores e as melhores práticas descritas pelas normas e modelos, abordando de maneira abrangente e ao mesmo tempo precisa o processo de engenharia de requisitos.

3.1 Modelando o Processo Através do Software Process Engineering Metamodel Specification

Após a pesquisa sobre Engenharia de Requisitos, foi necessário modelar o processo para uso durante o experimento. Para tanto foi utilizado, para representar os elementos do processo, a linguagem de modelagem SPEM - Software Process Engineering Metamodel Specification [17]. O SPEM surgiu da necessidade de unificação entre várias linguagens de modelagem de processos, sendo sua publicação inicial chamada de UPM - Unified Process Model [18].

A modelagem consiste em utilizar diagramas da UML (Pacote, Caso de Uso, Classe e de Atividades) associados aos estereótipos propostos pelo SPEM para representar tanto os elementos estáticos quanto os dinâmicos de um processo.

O processo proposto para a Engenharia de Requisitos é composto por quatro elementos do SPEM chamados Disciplines: Elicitação, Análise e Negociação, Validação e Documentação, que são executados de forma iterativa, alocados dentro de um diagrama de pacotes representando o nível mais alto do processo (Fig. 1).

Engenhariade Requisitos

<<Discipline>>Elicitação

<<Discipline>>Validação

<<Discipline>>Análise e Negociação

<<Discipline>>Documentação

Fig. 1. Diagrama de Pacote do Processo de Engenharia de Requisitos

Cada uma das Disciplines é refinada por meio de diagrama de pacotes que permitem visualizar, em um nível alto de abstração, as principais atividades que compõem o processo.

Os diagramas de pacotes são utilizados durante toda a modelagem do processo para apresentar o conjunto de elementos que compõem uma determinada Discipline,


123

como apresentado na Figura 2, esta figura apresenta o refinamento através de diagramas de pacotes da Discipline Elicitação que por sua vez é composta de quatro WorkDefinition sendo que um deles é decomposto em outro diagrama de pacotes o qual contém os elementos em nível atômico.

Elicitação

Compreender asNecessidades dos

Usuários

Compreender oProblema a Ser

Resolvido

CompreenderDomínio daAplicação

Compreender oContexto do

Negócio

Compreender o Problemaa Ser Resolvido

Definir Objetivos da Aplicação ( )

Identificar Complexidades da Aplicação( )

Engenheiro de Requisitos

Descrição dosObjetivos

Descrição dasComplexidades do

Sistema

Template Guideline

Priorizar Metas ( )

Definir Problemas a Serem Resolvidos( )

Descrição dasMetas

Descrição dosProblemas

Fig. 2. Diagrama de Pacotes da Discipline Elicitação e a decomposição em outro diagrama de Pacotes do elemento WorkDefinition Compreender o Problema a ser Resolvido.

A seqüência da execução das Disciplines do Processo é demonstrada através do uso de um diagrama de atividades que permitem a visualização dos WorkProduct gerados pelo WorkDefinition ou por uma Discipline e quais os participantes do processo que são responsáveis por cada um dos artefatos gerados (Fig. 3).



Sistema



Engenheiro deRequisitos

Definir Problemas aSerem Resolvidos( )

da Aplicação( )

Definir o Objetivo daAplicação ( )

Priorizar Metas ( )



Sistema



Guideline 3

Engenheiro deRequisitos

Documentos dosWorkdefinitions

Anteriores

Fig. 3. Diagrama de Atividades e de Classes do WorkDefinition Compreender o Problema a ser Resolvido.

Ao todo o processo modelado é composto por 31 atividades (Tabela 1), representadas no processo através dos diagramas, em diferentes níveis de abstração. A documentação do processo consiste, além dos diagramas, de uma descrição textual detalhada dos objetivos, das tarefas e dos artefatos consumidos e gerados por cada uma das atividades.


124

Tabela 1. Disciplines e Atividades que compõem o processo modelado de engenharia de Requisitos utilizado no experimento.

Discipline Atividades de cada Discipline

Elicitação

WorkDefinition: Compreender o domínio da aplicação

• Identificar o domínio do negócio • Identificar características do negócio • Identificar as atividades do negócio

WorkDefinition: Compreender o contexto do negócio

• Identificar a estrutura organizacional • Identificar sistemas existentes

WorkDefinition: Compreender o problema a ser resolvido

• Definir objetivos da aplicação • Identificar complexidades da aplicação • Definir problemas a serem resolvidos • Priorizar metas

WorkDefinition: Compreender as necessidades dos usuários

• Definir funcionalidades do sistema • Identificar atores e funções • Definir casos de uso • Definir o diagrama de caso de uso de contexto • Descrever casos de uso • Definir os protótipos de interface

Análise e Negociação • Definir e executar checklist • Estabelecer rastreabilidade • Executar matriz de interação • Documentar problemas • Negociar Requisitos

Documentação • Elaborar dicionário de termos • Definir padrões para a documentação • Gerar especificação de requisitos de software

Validação • Definir ações • Definir plano de revisão • Distribuir documentação • Corrigir especificação de requisitos • Listar problemas • Validar artefatos versus casos de uso • Validar Interfaces versus casos de uso • Executar checklists

As quatro Disciplines do processo, listadas na Tabela 1, cobrem tanto as normas quanto os modelos propostos pelos autores analisados, além de estabelecer a rastreabilidade através da execução de um conjunto de atividades definidas internamente nas Disciplines e na execução iterativa do processo.

4 Métodos de Pesquisa

O experimento realizado orienta-se sobre o modelo conceitual e o modelo GQM - Goal Question Metric propostos por Basili [19][20]. Esses modelos dividem o trabalho de experimentação em fases (definição, planejamento, operação e interpretação) e são orientados a metas. Neste trabalho, essas fases são apresentadas como: escopo do trabalho; definição do estudo métodos e práticas; análise e interpretação.


125

4.1 Escopo do Trabalho

O estudo de caso foi desenvolvido no ano de 2005 com alunos de pós-graduação da área de Engenharia de Software do curso de Pós-graduação em Computação Aplicada do Instituto Nacional de Pesquisas Espaciais – INPE e teve duração, de experimentação, de três meses. Seu principal propósito foi verificar as vantagens e desvantagens do uso de um processo modelado em relação à outra ou nenhuma técnica específica de Engenharia de Requisitos, avaliando a qualidade dos requisitos levantados entre os grupos de trabalho.

4.2 Definição do Estudo Métodos e Práticas

O experimento consistiu em formar oito grupos, contendo cada um cinco indivíduos, entre eles um gerente escolhido pelos membros do grupo, que simularam oito empresas distintas.

Todos os grupos, representando empresas, competiram entre si para apresentar, em um mesmo prazo estipulado, um sistema de informação que automatizasse uma fábrica de artefatos metálicos. Com a intenção de estimular a competição entre os grupos, a empresa que apresentasse um produto de software adequado às necessidades estabelecidas pelo cliente teria um contrato de prestação de serviços estabelecido. É interessante ressaltar que o cliente utilizado no experimento consistiu de uma empresa real de produção de artefatos metálicos, na qual um indivíduo externo aos procedimentos metodológicos do experimento (o diretor da empresa) se dispôs a atender, em tempo integral, todos os grupos que participaram do experimento, assim que estes necessitassem de alguma visita, reunião ou informações para o levantamento de requisitos junto ao cliente.

Foram criadas duas categorias de grupos, uma que trabalhou com o processo modelado e outra que não teve acesso ao modelo do processo, ou seja, dos oito grupos formados quatro fizeram uso do processo modelado de Engenharia de Requisitos e quatro trabalharam sem o processo modelado. Tanto a composição dos membros que fariam parte de cada grupo quanto a escolha dos grupos que trabalhariam com e sem o processo foi feita aleatoriamente. Os grupos foram divididos em pares e ímpares, também de forma aleatória, assim como a definição de qual deles utilizaria o processo modelado.

Para todos os grupos foi fornecida uma pequena descrição textual do caso de estudo, com o objetivo de permitir uma visão geral do sistema a ser desenvolvido e os artefatos que deveriam ser entregues após a conclusão do trabalho. Para este experimento deveria ser entregue, 90 dias após a apresentação dos objetivos, os requisitos modelados por meio de casos de uso e um sistema de informação que atendesse a descrição fornecida.

Detalhes sobre a aplicação a ser desenvolvida foram omitidos. Isso foi feito para que os grupos necessitassem elicitar junto ao cliente os requisitos do sistema a ser desenvolvido evitando-se, assim, que a atividade de elicitação fosse descaracterizada, mal utilizada ou diminuísse o grau de realismo do experimento.

Para todos os grupos foram apresentados de forma expositiva, os objetivos que deveriam ser atingidos: "Um sistema computacional deve ser desenvolvido, em 90 dias, com os objetivos de: melhorar os trabalhos dos setores de venda e de compra, melhorar a monitoração das diversas unidades de produção, e manter o diretor informado sobre todos os setores de uma fábrica de artefatos metálicos".


126

Como atividades específicas os grupos deveriam: a) Desenvolver o levantamento dos requisitos modelando-os através de casos de uso; b) Desenvolver o sistema baseado nos requisitos levantados.

Os grupos sem o processo modelado puderam utilizar-se de qualquer outro modelo, metodologia, ciclo de vida ou processo para desenvolver o sistema, se assim o desejassem. Os grupos com processo utilizaram, especificamente, o processo para a engenharia de requisitos, fornecido no momento da apresentação dos objetivos que consistia de um manual contendo a documentação do processo e sua descrição.

Para estabelecer conclusões sobre o experimento três categorias de informações foram coletadas: 1) Informações sobre os grupos e seus membros; 2) Informações sobre a execução do processo, e 3) Informações sobre os requisitos: número de requisitos levantados; incompletos; sobrepostos; redundantes; negociados; e corretos.

Na primeira categoria as informações foram coletadas através da aplicação de um questionário contendo quarenta perguntas dirigidas aos membros e aos gerentes dos grupos. Foram apresentadas questões quanto à experiência dos indivíduos, sobre o esforço despendido e sobre as experiências em relação ao trabalho executado. A segunda categoria também fez uso de questionários. Por fim, a terceira categoria utilizou um avaliador externo ao experimento que fez uso da aplicação das métricas estabelecidas no experimento para avaliar os requisitos.

Sobre métricas que poderiam ser utilizadas para medir um requisito, considerou-se o grau de qualidade, visto que a qualidade dos requisitos está diretamente relacionada à qualidade do produto de software. Tornou-se então necessário estabelecer o que era um requisito com qualidade.

A norma IEEE-830 [21] define que requisitos de alta qualidade são claros, completos, sem ambigüidade, implementáveis, consistentes e testáveis. Ainda, segundo a norma, os requisitos que não apresentem estas qualidades são problemáticos e devem ser revistos e renegociados com os clientes e usuários.

Por falta de padrões para avaliar especificamente casos de uso, foi utilizada a norma IEEE-830, com algumas modificações, para avaliar os casos de uso e suas descrições, como os cenários. Foi estabelecido então, que um caso de uso deveria ser:

• Correto: um caso de uso é correto somente se pode ser identificado no software; • Não ambíguo: um caso de uso é não ambíguo se tem somente uma interpretação; • Completo: um caso de uso é completo se: 1) Sua descrição é significativa e está

relacionada à funcionalidade, desempenho, atributos, restrições de projeto e interfaces externas; 2) Sua descrição define as respostas do software para todas as classes quanto aos dados de entradas, em todas as classes de situações realizáveis (cenários); 3) Todos os termos e referências a atores, a figuras, tabelas e definições estão relacionados; 4) Possui grau de importância e risco: um caso de uso é estável se possui um identificador para indicar a importância do requisito e o grau de risco;

• Consistente: um caso de uso é consistente se não está relacionado a nenhum conflito, ou seja, se é compatível com os objetivos do sistema e se não possui problemas de acordo técnico entre os envolvidos.

• Verificável: um caso de uso é verificável somente se sua declaração e descrição são verificáveis. Um caso de uso é verificável somente se, existir algum processo de custo finito, no qual uma pessoa ou máquina possa verificar se este está sendo atendido pelo produto do software. Em geral, um caso de uso ambíguo é não verificável;


127

• Modificável: um caso de uso é modificável somente se a sua estrutura e estilo permitem que qualquer mudança possa ser feita facilmente, de forma completa e consistente, mantendo a estrutura e o estilo;

• Rastreável: um caso de uso é rastreável se a origem de cada um de seus requisitos está clara e se este é facilmente referenciado e rastreado tanto nos seus desdobramentos (cenários) quanto em relação a sua origem.

Após determinar as métricas foi avaliada a técnica para aplicá-las nos casos de uso. A solução inicial para aplicar as métricas estabelecidas dar-se-ia pelo uso de um

modelo de casos de uso do problema, definido previamente por especialistas independentes, contra o modelo elicitado e elaborado por cada grupo. Mas essa técnica traz implicações sobre o alto grau de abstração existente na definição desse diagrama UML, ou seja, um mesmo problema pode ser modelado de diferentes formas e encontrar uma mesma solução. Devido a esse problema optou-se por uma avaliação sem interferências ou comparações com um modelo de casos de uso pré-definido. Para tanto, um avaliador externo, com experiência comprovada em engenharia de requisitos e técnicas orientadas a objetos, teve acesso às especificações dos requisitos de software e também aos produtos de software desenvolvidos por cada um dos oito grupos. Este avaliador levantou os requisitos, grupo a grupo, e aplicou as métricas definidas para avaliação dos casos de uso, utilizando uma lista de checagem que continha os sete critérios baseados na norma IEEE-830, citados anteriormente.

Ao avaliar o conjunto de casos de uso de um dado grupo o avaliador verificava, por exemplo, se um caso de uso era correto conferindo se o mesmo poderia ser identificado no produto de software. Como o avaliador possuía acesso tanto às especificações de requisitos quanto ao produto de software ele verificava a informação e a reportava para a lista de checagem dos casos de uso do grupo que estava sendo avaliado (Tabela 2). Caso o item avaliado existisse e estivesse completo, o item recebia o valor 1, caso contrário, possuísse problemas, estivesse errado ou parcialmente preenchido, recebia o valor 0.

Tabela 2. Disciplines e Atividades que compõem o processo modelado de engenharia de Requisitos utilizado no experimento.

Casos de Uso Itens

a b c .... .... y z

Correto 0 1 1 0 0 0 0 Não ambíguo 1 1 0 1 1 1 1 Completo 1 0 1 0 1 0 0 Grau de Importância 1 1 1 1 1 1 1 Consistente 1 0 1 0 1 0 0 Verificável 1 0 1 0 1 0 0 Modificável 1 0 1 0 1 0 0 Rastreável 1 0 1 0 1 0 0

A verificação estatística das questões definidas no início do experimento foi feita pela definição das hipóteses e pela constatação ou não da veracidade destas. Para cada um dos itens avaliados foram definidas as seguintes hipóteses:

1) H0 (hipótese nula): Os requisitos levantados pelos grupos, com processo e sem uso do processo, possuem o mesmo grau de qualidade do item avaliado. Assim, considera-se a hipótese nula por H0: δ = 0 (sem diferença significativa).

2) HA (hipótese alternativa): Os requisitos levantados pelos grupos, com processo e sem uso do processo, não possuem o mesmo grau de qualidade do item


128

avaliado. Assim, considera-se a hipótese alternativa por HA: δ ≠ 0 (existência de diferença significativa).

4.3 Análise

Foram determinados os valores das variáveis necessárias para a resposta à hipótese H0 e à hipótese HA. Os valores, tanto os com processo como os que não usaram o processo, foram comparados entre os dois tipos de grupos.

A Tabela 3 apresenta o número de acertos obtidos após a análise dos casos de uso dos grupos e a Tabela 4 apresenta o número de erros.

Tabela 3. Número de acertos obtidos nos casos de uso levantados pelos grupos.

Grupos usando

Processo

Número de Casos de Uso

Corretos Não ambíguos

Comple-tos

Grau de Importân-

cia

Consistente Verificá-vel

Modificá-vel

Rastreável

1 16 15 11 15 16 10 12 16 16 3 14 14 14 14 14 10 14 14 14 5 10 10 10 10 10 9 10 10 10 7 17 17 10 17 17 10 9 17 17

Sem uso Processo

2 14 10 4 0 0 4 0 0 0 4 19 8 8 0 0 8 0 0 0 6 27 9 7 0 0 7 0 0 0 8 103 10 10 0 0 9 0 0 0

Tabela 4. Número de erros obtidos dos casos de uso levantados pelos grupos.

Grupos usando

Processo

Número de Casos de Uso

Não Corretos

Ambí-guos

Incomple-tos

Sem Grau de Impor-

tância

Inconsis-tente

Não Verificá-

vel

Não Modificável

Não Rastreavel

1 16 1 5 1 0 6 4 0 0 3 14 0 0 0 0 4 0 0 0 5 10 0 0 0 0 1 0 0 0 7 17 0 7 0 0 7 8 0 0

Sem Uso Processo

2 14 4 10 14 14 10 14 14 14 4 19 11 11 19 19 11 19 19 19 6 27 18 20 27 27 20 27 27 27 8 103 93 93 103 103 94 103 103 103

Para observar a diferença entre as médias de cada um dos itens dos dois tipos de grupos, utilizou-se o teste estatístico não-paramétrica de Mann-Whitney.

Desde que atingido um grau de mensuração pelo menos ordinal, pode-se aplicar a prova U de Mann-Whitney [22], para comprovar se dois grupos independentes foram ou não extraídos da mesma população. Segundo Siegel [22] trata-se de uma das mais poderosas provas não-paramétricas, e constitui uma alternativa extremamente útil para a prova paramétrica t ou teste t de Student, quando se deseja evitar as suposições exigidas por este último, ou quando a mensuração atingida é inferior a escala de intervalos. Com esse teste, pode-se testar se duas amostras independentes provêm de populações idênticas. Em particular podemos testar a hipótese nula µ1=µ2 sem


129

precisar supor que as populações originárias tenham a forma aproximada de distribuições normais.

A decisão do teste pode se basear em R1 ou R2 que são, respectivamente, a soma dos postos dos valores da primeira amostra e da segunda amostra, não importando qual seja a amostra 1 e qual seja a amostra 2. A decisão do teste de hipótese pode basear-se em R1, ou em R2 ou pela estatística U apresentada pelas fórmulas:

12

)11(12.1 R

nnnnU −++= e 2

2)12(2

2.1 Rnn

nnU −++= (1)

Segundo Mood [23] se aplicado a prova do teste U a dados que possam ser adequadamente analisados pela prova paramétrica t, seu poder-eficiência tende para 3/π = 95,5 por cento quando o número de elementos aumenta, e está próximo de 95 por cento para amostras de tamanho moderado. Trata-se, portanto, de uma excelente alternativa para a prova t, e que dispensa as suposições restritivas e as exigências inerentes à prova t.

Após a tabulação dos dados considerou-se a hipótese de teste ao nível de 95% de confiança (estatisticamente discernível no nível de 5%), observaram-se os resultados, extraídos da análise efetuada pelos softwares SPSS e Excel para o teste U, admitindo-se para todos os testes de hipótese que se seguiram que: H0: δ=0 e HA: δ ≠ 0 com p <= 0,05 para U e n1 e n2 dados.

Segundo os resultados obtidos, foi rejeitada a hipótese nula para todos os itens avaliados, ou seja, estatisticamente não é possível afirmar que os dois grupos possuem um número igual ou aproximado de requisitos com os mesmos padrões de acerto, observando-se que os grupos que fizeram uso do processo obtiveram em todos os itens diferença significativa positivamente sobre a qualidade dos requisitos levantados.

A Tabela 5 apresenta alguns valores estatísticos levantados sobre o número de erros observados sobre os itens avaliados nos casos de uso levantados pelos grupos.

Tabela 5. Resultados da comparação entre grupos.

Elementos Analisados Tipo de grupo N Média Desvio Padrão Erro Médio 1 4 0,25 0,500 0,250 Número de Casos de Uso

não corretos 2 4 31,50 41,396 20,698 1 4 3,00 3,559 1,780 Número de Casos de Uso

Ambíguos 2 4 33,50 39,921 19,960 1 4 0,25 ,500 0,250 Número de Casos de Uso

incompletos 2 4 40,75 41,844 20,922 1 4 0,00 ,000 0,000 Número de Casos de Uso

sem grau de risco 2 4 40,75 41,844 20,922 1 4 4,50 2,646 1,323 Número de Casos de Uso

Inconsistentes 2 4 33,75 40,418 20,209 1 4 3,00 3,830 1,915 Número de Casos de Uso

não Verificáveis 2 4 40,75 41,844 20,922 1 4 0,00 ,000 0,000 Número de Casos de Uso

não Modificáveis 2 4 40,75 41,844 20,922 1 4 0,00 ,000 0,000 Número de Casos de Uso

não Rastreável 2 4 40,75 41,844 20,922

A tabela apresenta valores a respeito do número de casos de uso levantados pelos grupos e analisados. Onde: N = número de grupos, Tipo de grupo = caracteriza-se por 1 = grupos com processo; 2= grupos sem uso do processo


130

A Figura 4 apresenta dois gráficos, o primeiro um Box Plot e o segundo um gráfico de barras que demonstram os valores apresentados pelos grupos nos itens: número de casos de uso inconsistentes.

Fig. 4. Gráficos comparativos entre os grupos: número de casos de uso inconsistentes.

Ao observar os gráficos é possível notar que o agrupamento dos dados dos grupos que usaram o processo é mais conciso enquanto os grupos que não usaram o processo possuem grande discrepância, fator que foi considerado na análise estatística por apontar a relevância de quanto à falta de um processo para o desenvolvimento dos requisitos pode refletir em incoerências notadas no alto número de requisitos inconsistentes e dos erros apresentados nos demais itens avaliados. Ainda sobre a análise dos dados observa-se grande variação do grupo número oito (sem processo). Mesmo retirando este último grupo da análise não é possível aceitar H0 para nenhum dos itens avaliados, considerando p <= 0,05 e n1=3 e n2=4.

Também foi realizada análise estatística sobre os dados do perfil dos membros dos grupos. Através de questionários três categorias de perguntas foram feitas:

1) Sobre experiência, por exemplo: Quanto tempo de experiência na área? Quanto tempo de experiência em desenvolvimento de sistemas? Quanto tempo de conhecimento em metodologias sobre qualidade? Quanto tempo de conhecimento em metodologias sobre engenharia de requisitos? Participação em quantos projetos de pequeno, médio e grande porte?

2) Dedicação e expectativas sobre experimento, por exemplo: Quantas horas de estudos adicionais? Quantas horas de estudo sobre o problema abordado no experimento? Quantas reuniões do grupo participou? Quais as categorias de problemas encontrados?

3) Comportamento do grupo, como exemplo: Quantas reuniões o grupo realizou? Tempo médio das reuniões do grupo? Participação do gerente do grupo? Modelo de comunicação usada pelo gerente do grupo?

O questionário totalizou 40 perguntas e os membros dos grupos gastaram em média 30 minutos para respondê-las.

Para análise dos dados coletados nos questionários foi utilizado o teste exato de Fisher e o teste χ2 (Qui-quadrado), que permitem avaliar se a diferença nas amostras constituem evidências convincentes de associação entre as variáveis analisadas [22].

Todos os teste foram realizados considerando as hipóteses H0: a variável analisada é independente entre as duas categorias de grupo e; HA: a variável analisada não é independente existindo associação entre as duas categorias de grupos. Foi considerado nível de confiança de 95% e significância de 5%.

44N =

Grupo Sem ProcessoGrupo Com Processo

Nú

me

ro d

e C

aso

s d

e U

so

100

90

80

70

60

50

40

30

20

10

0

-10

6 4 17 10 11

20

94

0102030405060708090

100

Com Processo Sem Processonú

mer

o de

cas

os d

e us

o


131

Nas duas primeiras categorias de perguntas aceitou-se a Hipótese H0 para todos os casos, o que permitiu considerar a inexistência de diferença, estatisticamente discernível, entre os itens avaliados sobre experiência, dedicação e expectativas dos membros que compunham as duas categorias independentes de grupos.

Para a terceira categoria de perguntas três itens rejeitaram a hipótese H0: 1) o número de reuniões realizadas entre os membros dos grupos, grupos com processo tiveram em média nove reuniões, enquanto os grupos sem uso do processo tiveram três reuniões; 2) a freqüência de participação nas reuniões, membros dos grupos com uso do processo participaram em média de 89% das reuniões enquanto membros dos grupos sem uso do processo participaram 60%; 3) o número de reuniões com o cliente, grupos usando o processo tiveram em média sete reuniões com o cliente enquanto grupos sem uso do processo tiveram duas reuniões. Para estes três casos foi aceita a hipótese alternativa HA o que permitiu considerar a existência de associação para esses três itens entre as duas categorias de grupos analisados sendo que para os demais casos foi aceita a hipótese H0, ou seja, não houve diferença entre os grupos.

5. Interpretação

No contexto estatístico os resultados da análise, para os dados coletados, foram obtidos ao nível de certeza de 95%. Adotando-se uma metodologia mais precisa sobre o ponto de vista estatístico, o experimento pode ser executado até que se possa extrair um número de amostra que seja significativa estatisticamente para que outros tipos de testes possam ser aplicados, o que poderia apresentar o comportamento populacional.

Com relação ao propósito do experimento, no qual foi aplicado o processo para engenharia de requisitos estabelecido, houve bons resultados. Pode ser verificado o sucesso da aplicação de um processo como também algumas vantagens nítidas na aplicação de um processo modelado contrapondo o uso do empirismo no desenvolvimento dos requisitos de um sistema, visto que nenhum dos grupos, que não utilizaram o processo, fizeram uso de técnicas específicas para a Engenharia de Requisitos em seus projetos.

Sobre os requisitos levantados pelos grupos destaca-se o grupo número oito - sem uso do processo. Este grupo apresentou um alto número de requisitos levantados, cento e três. Esse dado enfatiza que a falta de uma metodologia para conduzir o trabalho da engenharia de requisitos, em um grupo de desenvolvimento, pode interferir negativamente na qualidade dos requisitos, mesmo quando o grupo não difere em experiência, dedicação e comportamento dos demais grupos.

Para este experimento, com a amostra aqui apresentada, sobre os aspectos de aplicabilidade, pode-se verificar a validade e o aumento do grau de qualidade dos requisitos. Vários fatores também devem ser considerados, como a falta da parte experimental de um processo de gerência de projeto que poderia mostrar o tempo gasto na execução de cada atividade o que poderia sugerir outras análises.

Um item que deve ser observado é que a determinação de um processo já estabelece um padrão de qualidade entre os grupos que o utilizam, pois nos testes estatísticos aplicados não foi possível observar diferença entre a experiência dos membros dos dois tipos de grupos.

Para os requisitos que foram representados em forma de casos de uso não é possível afirmar que os mesmos melhoram a interpretação dos requisitos como afirmado por Maiden e Robertson [24], pois a análise é feita por grupos que utilizam a mesma forma de representação.


132

Uma das explicações sobre a qualidade dos requisitos pode ser dada pelo fato de que a as reuniões solicitadas pelos grupos que usaram o processo junto ao cliente para o levantamento dos requisitos foi 72% maior do que os grupos que não utilizam o processo. O que permite sugerir que o formalismo para o desenvolvimento das atividades do processo força o analista a envolver-se com o problema do cliente compreendo de forma ampla o problema a ser resolvido.

Ainda sobre o experimento também foi positivo o grau de aceitação do uso do processo, visto que:

• 52% dos membros dos grupos com processo consideraram o processo de média facilidade de uso;

• 32% dos membros dos grupos com processo consideraram o processo de alta facilidade de uso;

• 16% dos membros dos grupos com processo consideraram o processo de uso altamente recomendado.

Sobre o grau de dificuldade associado à execução do processo no experimento, observou-se que:

• 11% dos membros dos grupos com processo consideraram como maior dificuldade a compreensão da linguagem utilizada para modelar o processo;

• 5% encontrou dificuldades em executar as atividades; • 21% atribuiu as falhas à gerência do grupo; • 47% à falta de conhecimento técnico para executar as atividades; • 16% à falta de tempo para compreender e executar o modelo proposto.

Também é observado que a dificuldade na interpretação e na aplicação de um processo de requisitos não possui grande relevância comparada a outros problemas.

Ainda sobre os requisitos foi observada grande diferença entre os requisitos dos grupos que utilizaram o processo e os dos que não o utilizaram, havendo assim a tendência de validar em todos os casos a hipótese alternativa que supõe diferença entre as médias das duas categorias de grupos no item qualidade dos requisitos. Mas com relação a essa interpretação e ao fato de ser pequena a representatividade da amostra, motiva-se a continuação deste experimento em trabalhos futuros, o que possibilitaria estabelecer conclusões mais precisas, bem como reconsiderar o mecanismo de avaliação dos casos de uso, visto que o uso de avaliadores independentes pode inferir variabilidade nos resultados obtidos.

6. Conclusão

A execução de experimentos em Engenharia de Software, especificamente na Engenharia de Requisitos, compõem uma tarefa complexa, dada as características do software. O controle das diversas variáveis inerentes ao ambiente de desenvolvimento torna quase inviável esse tipo de experimento. Devido a esses problemas muitos trabalhos optam por utilizar dados de diferentes projetos, mas ao lidar com a Engenharia de Requisitos diferentes projetos apresentam diferentes e complexas variações sobre suas variáveis.

Este caso de estudo apresentou como um processo modelado para engenharia de requisitos pode ser aplicado em um caso prático e que o uso de processos apresentam uma alternativa real para a melhoria dos requisitos do software.

Estudos futuros podem fazer uso de outros caminhos para a execução de experimentos como o uso de várias formas para representar requisitos, o aumento da população analisada e o acréscimo de métricas gerenciais sobre os dados levantados.


133

Outro ponto que pode ser considerado é o refinamento dos mecanismos de avaliação de requisitos.

Este artigo apresentou que o uso de um processo modelado aplicado pela primeira vez por grupos de desenvolvimento apresenta resultados positivos sobre a qualidade dos requisitos elicitados.

Referências

1. Derniame, J., Ali Kaba, B., Wastell, D. G.: Software Process: Principles, Methodology, Technology. Lecture Notes in Computer Science 1500 Springer (1999).

2. Davis, A. M. “Software requirements: objects, functions and states”. 1 ed., Prentice-Hall Inc. (1993).

3. Jarke, M., Pohl, K. “Requirements engineering in 2001: managing a changing reality.” IEEE Software Engineering Journal, v. 9, n. 6, p. 257-266, November, (1994).

4. Sommerville. I. “Software engineering”. 5. ed. Harlow, Addison Weley, (1995). 5. Macaulay, L. “Requirements engineering”. 1. ed. Springer, (1996). 6. Jalote, P. “An integrate approach to software engineering”. 2. ed., Springer, (1997). 7. Sommerville, I., Sawyer, P. “Requirements engineering: a good practice guide”. Lancaster

University, John Wiley & Sons LTD, July (1998). 8. Graham, I. “Requirements engineering and rapid development: an object oriented approach”.

1. ed. Harlow, Addison Wesley, (1998). 9. Pohl, K. “The Three dimensions of requirements engineering”. Conference on Advanced

Information Systems Engineering, A Framework and its Applications.Information Systems. Proceedings.v. 19, n. 3, p. 243-258,(1993).

10.Kontonya, G., Sommerville, I. “Requirements engineering : process and techiques”. 1. ed. Chichester England, John Wiley & Sons, April. ISBN 0-471-97208-8 (2000).

11.International Standard Organization (ISO) SPICE – “Software Process Assessment”. Part1: concepts and introductory guide Version 1.00, ISO/IEC (1995).

12.International Standard Organization ISO/IEC 12207, Software Life Cycle Processes. (1997). 13.Ministério da Ciência e Tecnologia (MCT). Tradução não oficial do CMU/SEI-93-TR-24-

CMM V1.1, Modelo de Maturidade de Capabilidade de Software (SW-CMM), Tradução de: José Marcos Gonçalves André Villas Boas, Versão 1.2, 11/10/2001.

14.Rational Software Corporation - Rational Unified Process - RUP, (2000). 15.Institute of Electrical and Electronics Engineers – IEEE - SWEBOK – “Guide to the

software engineering body of knowledge : trial version (version 1.00)”, editors, Bourque, P.; Dupuis, R., Tripp, L. L. IEEE Computer Society Press, May, (2001).

16.Kival, C. W., Eratóstenes, E. R. A., Ana Regina, C. R., Cristina, A. F. M., Danilo, S., Clênio, F. S. “Brazilian Software Process Reference Model and Assesssment Method”, ISCIS 2005, LNCS 3733, pp. 402-411, (2005).

17.Object Management Group. “Software process engineering metamodel specification -SPEM”. Formal Submission, OMG document number formal/02-11-14, November (2002).

18.Genvigir, E. C., Sant’Anna, N., Borrego, L. F. F., Cereja, M. G. J., Casillo, B. H. “Modelando Processos de Software através do UPM - Modelo de Processo Unificado”, XIV Congresso Internacional de Tecnologia de Software Qualidade de Software, CITS, (2003)

19.Basili, V. R., Selby, R. W., Hutchens, D. H. “Experimentation in software engineering” IEEE Transactions on Software Engineering, USA, v. 12, n.7, p. 733-743, (1986).

20.Basili, V. R., Caldiera I. G., Rombach H. D. “Goal Question Metric Paradigm. Encyclopedia of Software Engineering”, v. 1, John Wiley & Sons, (1994).

21.Institute of Electrical and Electronics Engineers – “IEEE Std 830-1998 IEEE Recommended practice for software requirements specifications”. New York, IEEE, (1998).

22.Siegel, S. “Estatística não-paramétrica”. 1. ed. Rio de Janeiro, MacGraw – Hill, (1954). 23.Mood, A. M. “On the asymptotic efficiency of certain non-parametric two-sample tests”. 1.

ed. Ann. Math. Statist., 25, p. 514-522, (1954). 24.Maiden, N., Robertson, S. “Developing use cases and scenarios in the requirements process”

- ICSE - International Conference on Software Engineering. ACM Digital Library, Minneapolis, (2005).


134

Extensión al modelo de Separación Multi-Dimensional de

Concerns en Ingeniería de Requisitos

Carlos Andrés Ospina, Carlos Andrés Parra, Luis Fernando Londoño, Raquel Anaya

Computer Science Department

EAFIT University, Medellín, Colombia {cospinav, cparradu, ranaya}@eafit.edu.co, [email protected]

Resumen. En este trabajo se presenta un análisis del modelo AORE Multi-Dimensional y su viabilidad de aplicación a nivel industrial. Se presenta una propuesta para complementar el modelo AORE Multi-Dimensional, para lo cual se recogen ideas tomadas de la experiencia en empresas de desarrollo de software, algunos conceptos del esquema de clasificación de concerns y relaciones propuestas en COSMOS y en propuestas de clasificación de requisitos existentes. Esta extensión permite la clasificación de los concerns, una caracterización de las relaciones de grano grueso y la definición de vistas que facilitan un acercamiento al modelo desde diferentes perspectivas de interés. La propuesta de extensión se ilustra con un ejemplo usando UML con el apoyo de una herramienta CASE convencional Palabras claves: AORE, AOSD, Aspecto, Interés, Interés de corte transversal, Requisitos, Solución de conflictos, Vistas de concerns.

1. Introducción

El tratamiento temprano de los concerns que componen un sistema se ha convertido en uno de los campos que ha generado mayor interés en los últimos años. Actualmente existe una diversidad de aproximaciones que proponen la introducción de aspectos en la fase de requisitos. Cada aproximación ha sido analizada y es objeto de discusiones en diferentes escenarios del ámbito tecnológico [4]. Existen razones manifiestas por las cuales el tratamiento de los aspectos debe ser llevado a cabo desde las primeras etapas del ciclo de vida del software [3]. La principal motivación de estos esfuerzos de investigación parten de la premisa de que la consideración temprana de los aspectos, como temas de interés transversal a mas de un participante del proyecto, logrará un mejor entendimiento del problema y facilitará su evolución a las fases siguientes.


135

El objetivo de este trabajo es presentar una propuesta de extensión del modelo AORE Multi-Dimensional [1],[2] para facilitar su implementación a nivel industrial. En la sección 2 se hace una presentación del modelo AORE y el esquema de COSMOS y se destacan los elementos que justifican dicha extensión. En la sección 3 se presenta la propuesta de extensión del modelo AORE Multi-Dimensional y la manera como puede ser trabajado este modelo en una herramienta CASE. En la sección 4 se presenta un ejemplo de aplicación del modelo y sus extensiones y finalmente se presentan las conclusiones y trabajos futuros. Este trabajo está enmarcado en el proyecto MMEDUSA1 un esfuerzo conjunto de la Universidad EAFIT y AVANSOFT S.A. con apoyo de COLCIENCIAS, el cual pretende brindar un “Marco Metodológico para Desarrollo de Aplicaciones Utilizando la Aproximación de Aspectos”.

2. Modelos de Requisitos Bajo el Enfoque Orientado a Aspectos

Las iniciativas del tratamiento de aspectos están enfocadas en el manejo de las propiedades de corte transversal en las etapas tempranas de la ingeniería de requisitos y el diseño de la arquitectura [3]. A continuación se realiza una presentación resumida de las dos propuestas que fueron objeto de estudio en este trabajo.

2.1 Aspect Oriented Requirement Engineering – AORE Multi-Dimensional

El modelo AORE Multi-Dimensional es un modelo propuesto por el grupo de aspectos de la Universidad Nova de Lisboa de Portugal. La versión actual del modelo tiene por objetivo realizar una descomposición de los requerimientos de una manera uniforme, sin importar su naturaleza funcional o no funcional. Bajo este modelo, los concerns implican un conjunto coherente de requisitos. Los concerns mantienen encapsulados conjuntos coherentes de requisitos tanto funcionales como no funcionales. La propuesta no restringe la manera como los concerns son definidos; esto significa que el levantamiento de los requisitos se podría realizar utilizando

1 MMEDUSA: Proyecto de investigación para definir un Marco Metodológico para Desarrollo de Aplicaciones Utilizando la Aproximación de Aspectos, Universidad EAFIT, AVANSOFT S.A., COLCIENCIAS. Medellín, Colombia 2006 – 2008. http://mmedusa.avansoft.com/terracota


136

cualquiera de las aproximaciones existentes.

La actividad de identificar y especificar intereses, se consigue utilizando técnicas de separación de requisitos como: puntos de vista, orientación a objetivos y casos de usos mencionados por los autores en [1], [2], que permitan identificar desde el problema los intereses y sus correspondientes requisitos. La especificación es realizada en XML. La actividad de identificar relaciones de grano grueso entre intereses, busca qué posibles influencias (positiva o negativa) sean detectables entre intereses los concerns. Estos intereses son relacionados entre sí en una matriz en cuyas intersecciones se señala (a) la influencia de un interés con respecto a otro. La actividad de especificar las proyecciones de los intereses usando reglas de composición, consiste en especificar cada una de las proyecciones encontradas en la actividad anterior la manera como los requisitos colaboran para el objetivo que persigue el concern. Esto es logrado a través de reglas de composición especificadas a través de una estructura XML que permite relacionar los requisitos junto con la acción u operador que lo cualifica dentro del concern. La actividad de manejo de conflictos entre intereses, permite especificar si un interés determinado puede contribuir positiva o negativamente con otros intereses; el modelo detalla una heurística de doblamiento de la matriz de contribuciones sobre su diagonal, con el propósito de observar si existe un efecto acumulativo para las situaciones donde dos intereses se influencia entre sí. Finalmente la quinta y última actividad del modelo es, identificación de las dimensiones de los intereses, donde un interés puede mapearse en una arquitectura como función, decisión o aspecto.

2.2. Modelo COSMOS

El modelo COSMOS es un modelo propuesto por IBM que busca proveer una aproximación a la separación de concerns avanzada siguiendo un enfoque multidimensional de vistas de concerns. Por tratarse de un esquema de clasificación, esta propuesta resulta apropiada para complementar cualquier aproximación que considere los concerns como elementos de primera clase [7], [8]. COSMOS distingue tres tipos de elementos, concerns, relaciones y predicados. COSMOS divide los concerns básicos en dos categorías, lógicos y físicos.


137

2.3 Oportunidades de extensión al modelo AORE Multi-Dimensional

Existen algunos puntos clave identificados en el modelo AORE Multi-Dimensional los cuales es posible fortalecer basados en conceptos extraídos del esquema de clasificación y relaciones propuestas por COSMOS, otras iniciativas de clasificación en ingeniería de requisitos, experiencia y lecciones aprendidas en empresas de desarrollo de software: - El modelo parte de una especificación de requisitos, la cual puede ser obtenida aplicando cualquier técnica de elicitación existente. Esto significa que los concerns son identificados siguiendo una aproximación botton-up. Podría ser conveniente, en algunas situaciones, seguir un enfoque descendente top-down para descubrir primero los concerns a alto nivel de abstracción y luego identificar los requisitos que conforman dicho concern.

- El modelo no entra a caracterizar los diferentes tipos de concerns. Una caracterización de éstos podría facilitar el análisis de las relaciones de grano grueso y lograr un mejor entendimiento de la semántica de las reglas de composición que se propone (enforce, ensure, provide, applied, exclude, affect).

- Las relaciones de grano grueso definen relaciones de influencia de un interés con respecto a otro. Si se entra a realizar una caracterización de los concerns, se podría a su vez, complementar estas relaciones para que precisen la semántica específica de la influencia que tiene un concern sobre el otro.

3 Propuesta de Ampliación del Modelo AORE Multi-Dimensional

Basado en el análisis y aplicación del modelo AORE Multi-Dimensional en casos de la industria y los hallazgos mencionados en la sección 2.3, se ha identificado la posibilidad de extender el modelo con el fin de proveer un mecanismo de clasificación de concerns y análisis de relaciones entre estos. En la figura 1 se muestra la propuesta del modelo AORE Multi-Dimensional extendido con tres actividades adicionales (identificadas en los recuadros en blanco), las cuales se describen a continuación. La propuesta de ampliación se apoya en iniciativas extraídas del estudio de otros modelos como INFR [5], COSMOS [6], [7], [8], 4+1 Vistas [9], [10], V-Graph [11], propuestas de requisitos de [12], la norma técnica ISO-9126 [14] y la experiencia de ingenieros de requisitos en la industria del software que han trabajado en la aplicación del modelo en casos de la industria.


138

Figura 1. Modelo AORE Multi-Dimensional Extendido.

3.1 Clasificar concerns

Esta actividad está orientada a proveer la clasificación de los concerns identificados y que hacen parte de los elementos de definición del sistema requerido. La clasificación que se propone de los concerns puede ser vista en la tabla 1.

Tabla 1. Clasificaciones propuestas para concerns

Clasificación Descripción

Objetivo Objetivos del sistema, los cuales pueden estar agrupados o ser vistos de manera individual como un concern.

Negocio Es una colección coherente de requisitos, los cuales pueden ser funcionales, de información y reglas de negocio.

Riesgos Son concerns que representan posibles dificultades a las cuales se expone el sistema en desarrollo.

Calidad Generalmente son concerns asociados a características no funcionales del software (“ilities” ISO 9126 [14]) y requisitos no funcionales del sistema que se tenga en cuestión. Estas características pueden afectar todo el sistema o sólo partes de éste.

Físicos Estos concerns comprenden un conjunto amplio de elementos que no son propios del sistema, pero los cuales pueden afectarlo considerablemente en cualquiera de las etapas. Estos concerns comprenden características tales como infraestructura, plataforma (Sistema Operativo), componentes externos, entorno de desarrollo, dispositivos, equipos y frameworks.

Identificar y especificar concerns|

Identificar relaciones de grano grueso entre concerns

Especificar proyecciones de concerns usando reglas de composición

Revisar concerns

Especificar dimensiones de concerns

Manejar Conflictos

Construir tabla de contribución.

Identificar proyecciones reflejadas: “folding”

Asignar pesos a los concerns conflictivos

Resolver conflictos

Clasificar concerns

Complementar relaciones de grano grueso e|ntre concerns

Genera

r vis

tas d

e c

oncern

s


139

Contexto Este tipo de concerns comprende elementos del sistema que no son susceptibles a cambios y el sistema los debe considerar. Ejemplos de elementos que se consideran concerns de contexto son: restricciones de ley, servicios externos, sistemas existentes, modelos de referencia.

Es importante anotar que para las clasificaciones de concerns introducidas al modelo descritas en la tabla 1, y para aquellas que no aplica la definición de concern propuesta por AORE Multi-Dimensional, dado que estas no pueden entenderse como una colección coherente de requisitos (objetivos, riesgos y concerns de contexto), no se realizan proyecciones sobre otros concerns por medio de reglas de composición, ya que no cuentan con granularidad a nivel de requisitos; la influencia de los concerns mencionados sobre los demás, se ve directamente en las relaciones de grano grueso refinadas.

3.2 Complementar relaciones de grano grueso entre concerns

Esta actividad se realiza posterior a la actividad de especificación de relaciones de grano fino, luego de que haya adquirido una visión más clara de la manera como los requisitos contribuyen o afectan un concern. Esto permite replantear y complementar las relaciones de grano grueso definidas anteriormente. La actividad de definición de relaciones de grano fino implica establecer relaciones a nivel de los requisitos que componen los concerns; en este proceso es posible encontrar que no existe una relación entre los requisitos de los concerns, lo cual implica que la relación de grano grueso deba desaparecer. En la tabla 2 se describen las relaciones de grano grueso refinadas que se proponen como elemento de ampliación del modelo; la tabla se tiene el nombre que identifica la relación de grano grueso refinada y una descripción semántica de la relación.

Tabla 2. Relaciones de grano grueso refinadas.

Relación Descripción

Contribución Un concern contribuye a otro cuando los requisitos del concern origen ayudan al cumplimiento de los requisitos del concern destino. Esta relación es vista como la relación recíproca a la afección. La contribución se da cuando el concern origen afecta de manera positiva al concern destino.

Restricción Un concern restringe a otro cuando los requisitos del concern origen restringen los requisitos del concern destino.

Condición Un concern condiciona a otro cuando los requisitos del concern origen condicionan los requisitos del concern destino. Se diferencia de la restricción por que las condiciones solo se aplican bajo ciertas reglas o circunstancias.

Uso Un concern usa a otro concern cuando los requisitos del concern origen usan requisitos del concern destino.

Extensión Un concern extiende a otro concern cuando los requisitos del concern origen extienden los requisitos del concern destino

Afección Un concern afecta a otro concern cuando los requisitos del concern origen afectan los


140

requisitos del concern destino. La afección es considerada como un aporte negativo entre los concerns. Esta relación se considera como la relación recíproca a la contribución.

Admisión Un concern admite a otro concern cuando los requisitos del concern origen admiten la aplicación de los requisitos del concern destino.

Se aplica a Un concern se aplica a otro concern cuando los requisitos del concern origen son aplicados a los requisitos del concern destino sin condicionarlos. Puede entenderse como la relación recíproca a la admisión.

3.3 Generar vistas de concerns

La generación de las vistas de los concerns se propone como una actividad transversal que puede ser realizada en cualquier momento. Esta actividad es opcional y tiene como objetivo permitir a los diferentes stakeholders obtener visiones del sistema desde diferentes perspectivas. Se introduce el concepto de vista propuesto por 4+1 view model [9], [10], el cual permite predefinir las perspectivas de interés de los involucrados. En el modelo AORE Multi-Dimensional extendido se proponen las vistas que se presentan en la tabla 3. Puede observarse que una vista esta asociada con unos tipos particulares de concerns definidos en la tabla 1. Cualquier vista adicional y de interés para el sistema puede ser incluida a criterio de los stakeholders.

Tabla 3. Vistas de concerns.

Vista Concerns Descripción Stakeholders

Negocio Objetivos, negocio, calidad y restricciones de ley

Vista orientada a mostrar los concerns que brinden la globalidad del sistema, reflejando la funcionalidad básica y las características de calidad que éste poseerá.

Analistas. desarrolladores, SQA

Funcional Objetivos, negocio.

Proporciona una visión de las funcionalidades de negocio que el sistema proveerá.

Usuario final.

QoS

Contexto y calidad.

Proporciona una visión de los elementos invariantes del sistema y características de calidad a tener en cuenta para el diseño del sistema.

Arquitectos, desarrolladores, SQA

Plataforma Físicos, sistemas existentes y servicios.

Proporciona una visión de los concerns que determinan el entorno en el cual operará el sistema.

Operadores, integradores sistemas y arquitectos, desarrolladores

Proyecto Objetivos, negocio, riesgos.

Proporciona una vista, de los objetivos del sistema, funcionalidades, riesgos y atributos de calidad que el sistema debe satisfacer.

Gerentes de proyecto, SQA.

3.4 Uso de una herramienta de modelado

En el proceso de aplicar un modelo como AORE Multi-Dimensional en un caso real e


141

incorporarlo como alternativa a un proceso de desarrollo de software, se hace indispensable contar con una herramienta que facilite el proceso de aplicar los elementos del modelo. Enterprise Architect es una herramienta robusta y flexible, que brinda soporte para el desarrollo de software, administración de proyecto, administración de requerimientos y análisis de negocio que ofrece soporte para UML [13]. Se utilizó esta herramienta teniendo en cuenta que es la herramienta adoptada a nivel organizacional por la empresa de desarrollo. La herramienta permite el manejo de una estructura de paquetes para agrupar los requisitos en las categorías de concerns definidas en la extensión del modelo AORE Multi-Dimensional; cada paquete es estereotipado de acuerdo al tipo de concerns que representa. De otra parte, la herramienta ofrece la posibilidad de crear diagramas para representar las vistas de concerns, las cuales sirven para mostrar una visión de los concerns desde la perspectiva de los diferentes stakeholders. Estas vistas, son derivadas a partir de los concerns definidos en sus respectivas categorías y de las relaciones que dichos concerns establecen con otros. Las relaciones de grano grueso son establecidas por medio de diagramas de paquetes. Es posible identificar cada paquete con un color diferente según el tipo de concern al que corresponde; opcionalmente se puede hacer visible en el paquete los requisitos que agrupa.

A partir de este diagrama de paquetes es posible obtener la matriz de Relaciones de Grano Grueso, generada desde la herramienta. Un elemento a tener en cuenta, son las reglas de composición de los concerns las cuales son especificadas por medio de diagramas haciendo uso de los requisitos que componen el concern. Las reglas de composición son representadas por medio de relaciones entre los requisitos estereotipados con las acciones de operación, los operadores de restricción y acciones de resultado identificadas.

A partir de las relaciones de grano fino es posible obtener los diagramas de relaciones de grano grueso refinados y los diagramas de vistas de concerns.

4 Aplicación del Modelo Extendido

El modelo y sus extensiones fue aplicado en un problema real de la empresa de software. El sistema (GESCOM) surge como una necesidad de las empresas para gestionar el talento humano que las componen y a los aspirantes a ingresar, basándose en un modelo por competencias.


142

El sistema debe proveer facilidades para (a) configurar los diferentes cuestionarios de evaluación de las competencias de acuerdo a los requerimientos establecidos por los diversos roles de la empresa; (b) realizar el proceso de evaluación tanto de los aspirantes como de los empleados; (c) generar resultados cuantitativos del proceso de evaluación, cuyo análisis posterior permita a las empresas; (d) definir un plan de desarrollo integral de sus empleados como actores claves para el cumplimiento de los objetivos empresariales. Para aplicar el modelo al caso de estudio se partió de un documento de requisitos presentado en forma de catálogo de requisitos que ha sido utilizado como insumo para la primera actividad del modelo cuyo objetivo es la identificación y especificación de concerns.

4.1 Aplicación del modelo

En esta sección se ilustra la aplicación del modelo AORE Multi-Dimensional extendido en el sistema GESCOM.

4.1.1 Identificación de concerns

Puesto que ya se contaba con una lista inicial de requisitos, los concerns fueron obtenidos siguiendo una aproximación ascendente. Los concerns identificados se describen en la tabla 4.

4.1.2 Clasificar los concerns

La clasificación de los concerns realizada se presenta en la tabla 4. A partir de estas clasificaciones es posible crear las vistas de concerns.

Tabla 4. Clasificación de los concerns identificados

Clasificació

n

Concerns

Calidad Ergonomía Contexto Restricciones técnicas Físico Componentes externos / frameworks; Herramientas de apoyo; Herramientas de desarrollo;

Estaciones de desarrollo; Servidores; Infraestructura / plataforma Negocio Cargos; Competencias; Configuración del sistema; Empresas; Evaluaciones; Experiencia;

Necesidades de formación; Personas; Plan de desarrollo Objetivo Configuración inicial de las empresas; Mostrar indicadores de forma gráfica;

Permitir la configuración de la seguridad por roles; Permitir la evaluación por diferentes evaluadores; Permitir mostrar los resultados de las evaluaciones; Presentar informes imprimibles; Presentar informes técnicos


143

Riesgo Disponibilidad de recursos; Especificación; Imprevistos técnicos; Inexperiencia; Tiempos y costos

4.1.3 Identificación de relaciones de grano grueso

Las relaciones de grano grueso son establecidas de acuerdo a la especificación del sistema y modeladas en Enterprise Architect mediante diagramas de paquetes. Posteriormente se genera la matriz de relaciones de grano grueso.

4.1.4 Identificación de relaciones de grano fino

La identificación de las relaciones de grano fino implica el análisis de las relaciones de los requisitos de un concern contra todos los requisitos de otros concerns. En la tabla 5. se muestran algunas de las relaciones de grano fino identificadas en el caso de estudio para los concerns Ergonomía, Evaluaciones y Competencias. Esta tabla muestra los requisitos del concern origen y la relación existente con los requisitos del concern destino, además se muestran las acciones de operación, los operadores de restricción y acciones de resultado identificadas en cada relación.

Tabla 5. Relaciones de grano fino para los concerns Evaluaciones, Ergonomía y Competencias.

Concern origen Acción de

operación

Operadores

Restricción

Acción de

resultado

Concern destino

Ergonomía: REQ-RNG-0023 Ensure On Fulfilled Cargos: REQ-INF-0006 Ergonomía: REQ-RNG-0022 Provide On Fulfilled Competencias: REQ-FUN-0010 Ergonomía: REQ-RNG-0022 Ensure On Fulfilled Competencias: REQ-INF-0008 Ergonomía: REQ-FUN-0022 Provide For Fulfilled Evaluaciones: REQ-FUN-0021 Ergonomía: REQ-FUN-0022 Ensure On Fulfilled Evaluaciones: REQ-INF-0040 Ergonomía: REQ-RNG-0023 Applied For Fulfilled Conf. del sistema: REQ-FUN-0004 Ergonomía: REQ-FUN-0017 Ensure On Fulfilled Conf. del sistema: REQ-INF-0007 Ergonomía: REQ-FUN-0017 Provide For Fulfilled Conf. del sistema: REQ-FUN-0001 Competencias: REQ-RNG-0001 Enforce For Fulfilled Evaluaciones: REQ-INF-0001 Competencias: REQ-RNG-0011 Applied For Fulfilled Evaluaciones: REQ-FUN-0050 Competencias: REQ-FUN-0010 Applied On Fulfilled Evaluaciones: REQ-INF-0017 Evaluaciones: REQ-FUN-0014 Affect On Fulfilled Personas: REQ-INF-0012 Evaluaciones: REQ-FUN-0050 Affect On Fulfilled Competencias: REQ-INF-0028

4.1.5 Refinamiento de relaciones de grano grueso

Al refinar las relaciones de grano grueso a partir de las relaciones de grano fino, Es importante anotar que para la selección de la relación de grano grueso se deben tener en cuenta las diferentes relaciones de grano fino que se presentan. La tabla 6 muestra las relaciones de grano grueso calificadas de acuerdo a su semántica.


144

Tabla 6. Relaciones de grano grueso refinadas: Evaluaciones, Ergonomía y Competencias.

Concern origen Relación Concern destino

Ergonomía Extiende a Evaluaciones Ergonomía Usa Competencias, Cargos Ergonomía Admite a Conf. Del sistema Competencias Condiciona a Evaluaciones Evaluaciones Contribuye a Permitir mostrar los resultados de las evaluaciones Evaluaciones Contribuye a Permitir la evaluación por diferentes evaluadores Evaluaciones Afecta a Personas Evaluaciones Se aplica a Competencias

4.1.6 Solución de conflictos

Para el sistema no se detectaron conflictos entre los concerns (específicamente para los concerns estudiados: ergonomía, evaluaciones y competencias) y los demás concerns identificados en el sistema. Esto se debe a que se parte de un catálogo de requisitos que ya ha sido sometido a otras estrategias de solución de conflictos.

4.1.7 Vistas de concerns: Se presentan las vistas generadas a partir del caso de aplicación con los respectivos concerns involucrados.

Vista de negocio: En esta vista se encuentran los concerns de negocio (Necesidades de formación, evaluaciones, competencias, personas, cargos, configuración del sistema, empresas experiencia y plan de desarrollo), de calidad (Ergonomía) y los objetivos (Permitir la evaluación por diferentes evaluadores, configuración inicial de las empresas, permitir mostrar los resultados de las evaluaciones, permitir la configuración de la seguridad por roles, mostrar indicadores de forma gráfica). Para el sistema usado como caso de aplicación, GESCOM, en el catálogo de requisitos no se detectaron restricciones de ley. Vista funcional: En la vista funcional esta conformada por los concerns de tipo objetivos y concerns de tipo negocio. Se incluyen los concerns de tipo objetivo (Permitir la evaluación por diferentes evaluadores, configuración inicial de las empresas, permitir mostrar los resultados de las evaluaciones, permitir la configuración de la seguridad por roles, mostrar indicadores de forma grafica) y concerns de tipo negocio (Necesidades de formación, evaluaciones, competencias, personas, cargos, configuración del sistema, empresas experiencia y plan de desarrollo). Vista QoS: En esta vista se tienen los concerns restricciones técnicas y ergonomía, los cuales pertenecen a los concerns de tipo contexto y calidad que conforman esta vista.


145

Vista de plataforma: Está compuesta por los concerns de tipo físicos, sistemas existentes y servicios. En la aplicación del caso para el catálogo de requisitos de GESCOM sólo se detectaron concerns del tipo físico (Estaciones de desarrollo, servidores, herramientas de desarrollo, componentes externos / frameworks, infraestructura / plataforma, herramientas de desarrollo). Vista de proyecto: Compuesta por los concerns de tipo objetivos, negocio y riesgos. Del caso de aplicación se extrajeron los concerns objetivos (Permitir la evaluación por diferentes evaluadores, configuración inicial de las empresas, permitir mostrar los resultados de las evaluaciones, permitir la configuración de la seguridad por roles, mostrar indicadores de forma gráfica), de negocio (Necesidades de formación, evaluaciones, competencias, personas, cargos, configuración del sistema, empresas experiencia y plan de desarrollo) y los riesgos (Especificación, disponibilidad de recursos, tiempos y costos, inexperiencia).

4.1.8 Especificar dimensiones de concerns

Las dimensiones para los concerns Ergonomía, Competencias y Evaluaciones son presentados en la tabla 7.

Tabla7. Especificación de las dimensiones de los concerns.

Concern Influence Mapping

Ergonomía Diseño, evolución Decisión Competencias Especificación, análisis. Clase Evaluaciones Especificación, análisis. Clase

Conclusiones y Trabajos Futuros

Este trabajo ha presentado una propuesta de extensión del modelo AORE multidimensional con el propósito de permitir la clasificación y análisis de las relaciones entre concerns. Con la adopción de un esquema de clasificación se obtienen los siguientes beneficios: - Se abre la posibilidad de que la definición de los concerns pueda seguir una aproximación ascendente, cuando ya se cuenta con una lista de requisitos, o una aproximación descendente, cuando los primeros tipos de concerns que se definen son los objetivos.

- Se puede contar con un catálogo existente de concern debidamente caracterizado (atributos de calidad, reglas de negocio, reglamentaciones externas, etc.) Este hecho facilita su incorporación para ser aplicado en proyectos reales ya que se puede lograr una reutilización de concerns que son transversales a más de un proyecto.


146

- La caracterización de los diversos tipos de concerns facilitará el entendimiento del tipo de relación que se sucede entre ellos con el propósito de resolver situaciones conflictivas que puedan presentarse.

- Se predefinen vistas o perspectivas de interés de modelo que facilitan el análisis desde diferentes perspectivas. La herramienta CASE que soporte el proceso deberá contar con la capacidad de generación automática de dichas vistas y la definición de nuevas vistas. La aplicación del modelo AORE Multi-Dimensional Extendido a nivel industrial, requiere el uso de una herramienta que facilite la ejecución de las tareas propuestas. Enterprise Architect se presenta como una herramienta robusta que permite la adaptación de muchos de sus artefactos para la aplicación del modelo, sin embargo no da un soporte completo para todas las actividades de este. En una segunda fase del proyecto se pretende integrar la funcionalidad de manipulación de concerns en una herramienta CASE que ha sido construida por el grupo, denominada ARCA [16], en la cual se permite la generación automática de las plantillas XML definidas por el modelo. Las relaciones de grano fino propuestas por el modelo AORE Multi-Dimensional se presentaron como una de las mayores dificultades al momento de aplicar el modelo. Esto debido a la cantidad de requisitos que conforman un sistema de nivel industrial a lo cual se suma la complejidad que genera contar con relaciones conformadas por tres elementos: acciones, operadores y acciones de resultado. Estos tres elementos y los múltiples valores que pueden tomar en cada relación hacen que la ejecución de la tarea “Identificación de relaciones de grano fino”, al no contar con heurísticas que guíen el proceso, sea compleja. Trabajos futuros pueden enfocarse al establecimiento de heurísticas que faciliten el desarrollo de esta actividad. Uno de los valores agregados al introducir un esquema de clasificación de concerns, y que actualmente se está explorando, es el aporte que el análisis de las contribuciones negativas pueden dar para resolver los conflictos que suceden entre los concern de acuerdo al tipo de concern involucrado. Dependiendo de la naturaleza del concern, una relación conflictiva podría dar origen a tres actividades básicas: (a) abordar el proceso de negociación de requisitos el cual desechará o redefinirá algunos de ellos; (b) depurar los requisitos e identificación de nuevos objetivos que no habían sido considerados; (c) identificación de riesgos que deben decidirse si se aceptan.

Referencias

1. MOREIRA, Ana, RASHID, Awais, ARAUJO, Joao. “Multi-dimensional Separation of Concerns in Requirements Engineering”. 2005. The 13th International Conference on Requirements Engineering (RE'05), August 29, September 2, 2005, Paris, France. IEEE Computer Society.


147

2. MOREIRA, Ana, RASHID, Awais, ARAUJO, Joao. “A Concern-Oriented Requirements Engineering Model”, in Conference on Automated Information Software Engineering (CAISE), Lecture Notes in Computer Science 3520, Berlin: Springer, 2005, pp. 293-308

3. TEKINERDOGAN, Bedir, MOREIRA, Ana, ARAÚJO, Joao, CLEMENTS, Paul. “Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design” Workshop Proceedings, University of Twente, TR-CTIT-04-44, 119 pp, October 2004..

4. BAKKER, Jethro, TEKINERDOGAN, Bedir, AKSIT, Mehmet. “Characterization of Early Aspects Approaches”. Presented at Workshop on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design, held in conjunction with AOSD Conference, 2005

5. BRITO, Isabel, MOREIRA, Ana. “Integrating the NFR framework in a RE model”. Early Aspects 2004: Aspect-Oriented Requirements Engineering and Architecture Design, Lancaster, UK. 2004.

6. FILMAN, Robert. ELRAD, Tzilla. CLARKE, Siobhán. AKSIT, Mehmet. “Aspect Oriented Software Development”. Addison-Wesley. 2005

7. SUTTON, Stanley. “Concerns in a Requirements Model – A Small Case Study”. Workshop on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design, held in conjunction with AOSD Conference, 2003

8. SUTTON, Stanley. ROUVELLOU, Isabelle. “Modeling of Software Concerns in COSMOS”. 1st Int' Conf. on Aspect-Oriented Software Development (AOSD 2002), Enschede, The Netherlands, 2002, pp. 127-133.

9. KRUTCHEN, Philippe. “The 4+1 View Model of Software Architecture”. 1995. Paper published in IEEE Software 12 (6).November 1995, pp. 42-50

10. KONTIO, Mikko. “Architectural manifesto: Designing software architectures. Introducing the 4+1 view model”. Softera, . February 2005

11. YU, Yijun, SAMPAIO DO PRADO LEITE, Julio Cesar, MYLOPOULOS, John. “From Goals to Aspects: Discovering Aspects from Requirements Goal Models”. Department of Computer Science, University of Toronto. IEEE Joint International Conference on Requirements Engineering, pp.33–42, 2004.

12. DURÁN, Amador. “Metodología para la elicitación de requisitos de sistemas de software”. Informe Técnico LSI-2000-10. Facultad de Informática y Estadística Universidad de Sevilla, October, 2000-

13. SPARX SYSTEMS. “Enterprise Architect - UML Design Tools”. Sparx Systems Pty Ltd. 2006.

14. ISO/IEC 9126-1: 2001 International Standard “Software Engineering” 15. TARR, Peri, OSSHER, Harold, SUTTON, Stanley, HARRISON, William. “N Degrees of

Separation: Multi-Dimensional Separation of Concerns.” Proceedings of the International Conference on Software Engineering (ICSE'99), May, 1999

16. ANAYA, Raquel, et.al. “Documento de Arquitectura de AR2CA Versión 3.0.” Reporte Técnico Proyecto nro. 479-2003-1118/14714901. Dirección de Investigación y Docencia. Universidad EAFIT, 2006.


148

Sesión 5 Procesos del Negocio

149

Una Propuesta Basada en Modelos para la Construcción de Sistemas Ubicuos que den Soporte a

Procesos de Negocio1

Pau Giner y Victoria Torres


Camí de Vera, s/n 46022 Valencia, España

{pginer, vtorres}@dsic.upv.es

Resumen. La aplicación de la computación ubicua para dar soporte a procesos de negocio se ha mostrado efectiva, aportando mejoras cuantificables en el contexto empresarial. Sin embargo, esta aplicación generalmente se ha realizado siguiendo un enfoque centrado en la tecnología. El rediseño continuo de los procesos de negocio, junto a la gran heterogeneidad en la interacción con el sistema que ofrece la computación ubicua dificulta la evolución de estos sistemas. El presente trabajo trata de hacer patente la necesidad de una aproximación metodológica basada en el desarrollo dirigido por modelos para la construcción de sistemas ubicuos que den soporte a procesos de negocio. Para ello se definirán claramente las necesidades y requisitos que este tipo de sistemas exige considerar y cómo estas exigencias pueden ser cubiertas desde un enfoque de desarrollo dirigido por modelos.

Palabras clave: Procesos de Negocio, Computación Ubicua, DDM.

1 Introducción

La Computación Ubicua [1] da nombre a un paradigma de computación novedoso en el que la tecnología aparece integrada en elementos cotidianos de la vida real y en el que la interacción con el sistema se lleva a cabo de forma transparente al usuario. Estas características suponen un cambio tanto en la concepción de los sistemas a desarrollar como en la forma de interactuar con éstos por parte de los usuarios finales.

De entre los diferentes campos de aplicación que tiene la Computación Ubicua [30], este trabajo se centra en los Sistemas Ubicuos que dan soporte a los Procesos de Negocio de una organización (SUPN), presentando las características, beneficios y necesidades que se dan en este tipo de sistemas.

El uso de Computación Ubicua en entornos empresariales se encuentra todavía en un estado prematuro, sin embargo su implantación en algunos contextos [6][7][8]


TIN2004-03534 y cofinanciado por FEDER.


151

pone de relieve las ventajas aportadas. La aplicación de las tecnologías de Computación Ubicua debe realizarse teniendo en cuenta las características dinámicas del contexto en el que “vive” el sistema: cambios constantes en los Procesos de Negocio que gobiernan el sistema, en la tecnología utilizada o incluso en los dispositivos de acceso. Este dinamismo exige mecanismos que permitan de forma sencilla la modificación constante del sistema.

El presente trabajo de posicionamiento pretende dar una visión de las necesidades y requisitos que debe cumplir un método que dé soporte a la construcción de SUPN desde una perspectiva de Desarrollo de Software Dirigido por Modelos. La principal aportación, por tanto, es la identificación de los modelos necesarios para captar todos los requisitos detectados.

El resto del trabajo se estructura de la siguiente manera. En la Sección 2 se introducen conceptos sobre Procesos de Negocio y su gestión así como algunas nociones relevantes sobre la Computación Ubicua. La Sección 3 presenta un estudio sobre la aplicación de la Computación Ubicua para dar soporte a los Procesos de Negocio, poniendo de manifiesto beneficios y requisitos. La Sección 4 presenta los modelos a considerar para ofrecer un enfoque metodológico para el desarrollo de este tipo de sistemas. Finalmente, la Sección 5 expone las conclusiones y trabajos futuros.

2 Contexto de partida

Los SUPN representan la unión de dos áreas de conocimiento distintas. Por un lado el tratamiento de los Procesos de Negocio y por otro los Sistemas Ubicuos. A continuación se introducen brevemente ambos campos, destacando algunos aspectos de interés referenciados en el resto del trabajo.

2.1 Procesos de Negocio

Un proceso de negocio es una colección de actividades estructuradas y relacionadas que producen un valor para la organización, sus inversores o sus clientes. Un proceso de negocio puede incluir otros procesos.

Business Process Management (BPM) da nombre a la disciplina que se encarga de modelar, automatizar, integrar, monitorizar y optimizar la gestión sistemática de los procesos de negocio. Esto lo consigue mediante la integración de disciplinas tales como el Modelado de procesos, Simulación, Workflow, Enterprise Application Integration (EAI) e integración Business-to-Business (B2B).

Además, BPM reconoce el factor cambiante existente en los Procesos de Negocio y por ello propone tanto el modelado de los procesos como su simulación y ejecución en un entorno donde la definición sea explicita pudiendo ser controlado, analizado y rediseñado de forma constante para mejorar su eficiencia. Para hacer posible esta propuesta han surgido tanto lenguajes de descripción de procesos como motores de ejecución.

Existen diferentes notaciones para modelar procesos de negocio (Diagramas de actividad de UML, Procesos de Negocio EDOC, IDEF, ebXML BPSS, BPMN, etc.). En este trabajo, debido a sus características como comentaremos a continuación, se


152

utiliza Business Process Model Notation [25] (BPMN) como notación para la descripción de Procesos de Negocio. BPMN es el estándar para el modelado de Procesos de Negocio propuesto por la Business Process Management Initiative (BPMI) y adoptado por la OMG. BPMN únicamente incluye un tipo de diagrama llamado Business Process Diagram (BPD) para modelar Procesos de Negocio así como los sub-procesos y tareas que lo componen. Pese a tratarse de una notación de alto nivel de abstracción, se han definido reglas de transformación que permiten derivar una definición ejecutable del proceso. En [24] se describe la obtención de una descripción utilizando Business Process Execution Language for Web Services (WS-BPEL). WS-BPEL es un lenguaje para la orquestación de Servicios Web. Existen numerosos motores de ejecución de procesos que permiten utilizar descripciones en WS-BPEL, algunos ejemplos son Oracle BPEL Process Manager, Microsoft BizTalk Server o Active BPEL Engine.

2.2 Sistemas Ubicuos

La Computación Ubicua supone la diseminación del sistema informático de forma que éste pasa a formar parte de productos cotidianos convertidos en objetos inteligentes gracias a las tecnologías ubicuas. Las tecnologías más relevantes para hacer realidad este paradigma son la identificación automática (Auto-ID), la localización y los sensores.[3]

Etiquetas de código de barras, etiquetas RFID, Smart Cards o sistemas biométricos representan los mecanismos más utilizados para la identificación. La tecnología de código de barras está ampliamente extendida, no obstante la detección requiere visión directa entre el receptor y la etiqueta. La identificación por radiofrecuencia (RFID) no tiene esta limitación. Aunque se trata de una solución más sofisticada su uso aumenta a la par que sus costes de producción se reducen.

Existen distintas técnicas para conocer la ubicación de un elemento, normalmente éstas se basan en extensiones de los mecanismos de Auto-ID y permiten desde conocer la posición del receptor que identificó al elemento hasta realizar el cálculo de la posición del propio elemento a partir del análisis del entorno (a partir de la intensidad de señal recibida, por ejemplo). En cualquier caso, la información de posición solo es relevante si se posee un modelo de posicionamiento [23].

La tecnología de sensores permite convertir factores del entorno como la temperatura, presión, iluminación, nivel de ruido o presencia de objetos, en fuentes de información utilizables por el sistema. Es importante destacar que si bien suponen un aporte de información disponible de forma continua, la fiabilidad de estos dispositivos puede variar y esto deberá considerarse.

3 Procesos de Negocio en Entornos Ubicuos: Beneficios y Necesidades

Desde el campo de la investigación se han llevado a cabo estudios sobre la repercusión que puede tener la introducción de la Computación Ubicua en entornos


153

gestionados por Procesos de Negocio. Por un lado se han estudiado los beneficios tanto económicos [2] como de mejora de los propios procesos [3] [4] [5]. Por otro lado, se han desarrollado prototipos que han permitido experimentar dichas mejoras en contextos organizacionales muy diversos como el control de la cadena de suministro de supermercados [6], las operaciones de mantenimiento de la industria aeronáutica [7] o el control de cultivos en el sector vinícola [8]. Sin embargo, estos estudios se centran en el nivel tecnológico, careciendo de un enfoque metodológico que permita su construcción a partir del modelado de Procesos de Negocio.

3.1 Beneficios

La Computación Ubicua, como soporte de los Procesos de Negocio de una organización, supone una aportación doble: por un lado, permite transformar elementos previamente pasivos en objetos inteligentes que participan en el proceso, por otro lado, posibilita una interacción más natural con el sistema. A continuación se describen los beneficios de la aplicar estas tecnologías en un SUPN.

Reducción de la distancia entre el mundo real y su representación El sistema se aproxima al espacio del problema. Añadiendo dispositivos a objetos de interés se vincula éstos con sus representantes del sistema informático. Se establece así una correspondencia directa entre el estado real y su representación. La realización de una tarea y la notificación de ésta pasan a ser un todo. Esto se traduce en una mayor automatización de los procesos.

Aumento de la calidad de la información Reducir la distancia entre los objetos reales y su representación informática, permite automatizar la introducción de datos. Los datos pueden recogerse en el instante y lugar donde son generados o usados. Obtener la información “in situ” aumenta la calidad de ésta, evitando posibles alteraciones. Además, adquirir la información de forma automática posibilita la toma de medidas a un mayor nivel de detalle tratando individualmente cada elemento en poblaciones que por su tamaño hacen inabordable una medición manual.

Heterogeneidad de acceso al sistema Los participantes en el proceso podrán interactuar con el sistema de diversas formas. Dicha interacción podría pasar desde ser transparente al usuario (los usuarios se limitan a realizar sus tareas y es el propio sistema el que las percibe) hasta llevarse a cabo mediante dispositivos móviles. Esta flexibilidad en cuanto al acceso al sistema agiliza también la colaboración entre usuarios, puesto que el sistema deja de ser un ente ajeno al proceso y pasa a formar parte del propio contexto en el que se desarrolla éste.

Adaptación al contexto El cambio del entorno puede disparar eventos del Proceso de Negocio, obligando a que éste se adapte a la nueva situación. Esto aporta un mayor dinamismo en los


154

Procesos de Negocio, permitiendo su adaptación al cambio sin necesidad de un rediseño completo.

Nuevos modelos de negocio La introducción de la Computación Ubicua permite ampliar el rango de modelos de negocio que hasta ahora se diseñaban. El carácter activo de los objetos implicados en el proceso así como la mejora en la calidad de la información y el control del proceso permite tomar en consideración factores que antes no se tenían en cuenta para definir un modelo de negocio. Un SUPN permitiría fijar características como el precio de un producto de forma individualizada en función de factores del contexto o del propio elemento. La viabilidad de los nuevos modelos de negocio deberá, no obstante, ser analizada desde la perspectiva económica [9].

3.2 Requisitos de los SUPN

Los sistemas ubicuos plantean una serie de necesidades ya estudiadas en profundidad desde el punto de vista técnico [13] [14] [15], económico [16] y social [17]. La utilización de estos sistemas como soporte a Procesos de Negocio hace emerger nuevos retos y aspectos a considerar. A continuación se identifican los requisitos que se deben considerar en la construcción de un SUPN.

Identificación de los elementos que participan en el proceso En un Proceso de Negocio sobre sistemas ubicuos, los elementos que trata el sistema podrán estar vinculados con objetos reales o no. Por ejemplo, en el contexto de un supermercado, el elemento factura podrá ser puramente digital mientras que los productos comprados tendrán su correspondencia con objetos reales. Puede ocurrir, además, que pese a existir una vinculación entre elementos virtuales y reales, no se apliquen tecnologías de Auto-ID y deba tratarse de un modo tradicional. Si no se utilizan mecanismos de Auto-ID, se necesitará la intervención humana para introducir el identificador del elemento en el sistema, ya sea tecleando su código o pasándolo por un lector de código de barras según lo sofisticado de la solución.

Evolución del sistema Los SUPN se desarrollan en un contexto muy cambiante, tanto por el dinamismo que introducen los propios Procesos de Negocio (cambio de reglas o procedimientos que rigen el sistema) como por la evolución tecnológica de los dispositivos utilizados. Por lo tanto, el diseño del sistema deberá realizarse de forma que se minimice el impacto de los posibles cambios.

Los procesos pueden cambiar de forma frecuente y por consiguiente el sistema que les da soporte también debe hacerlo. Es deseable que las modificaciones llevadas a cabo en la definición del Proceso de Negocio se reflejen de forma adecuada en el sistema en el menor tiempo posible para cubrir las necesidades de la organización.

Por otro lado, hay que considerar también el cambio a nivel tecnológico. La incorporación de tecnología para mejorar el proceso como sensores o Auto-ID, deberá ser añadida al sistema de forma sencilla.


155

Heterogeneidad de interacción Los sistemas ubicuos deben permitir la intervención sencilla de participantes humanos en los Procesos de Negocio. Tandler en [10] recoge los requisitos arquitectónicos que deben cubrirse para afrontar la construcción de sistemas ubicuos con soporte a la colaboración mediante múltiples dispositivos de naturaleza heterogénea. Se deberán considerar por lo tanto, distintas formas de interacción y de representación de la información. El uso de varios dispositivos para realizar una misma tarea por uno o varios usuarios, o incluso la utilización del mismo dispositivo por varias personas en acciones conjuntas.

Simulación del sistema La simulación del sistema en los SUPN cobra especial importancia. La implantación de un sistema ubicuo tiene asociados unos costes muy dependientes del nivel de detalle al que se desee la información. Por lo tanto será importante saber si una configuración concreta es suficiente para los objetivos de la organización. Además, también son relevantes aspectos como la validación del correcto funcionamiento del proceso y la comprobación de propiedades de interés antes de la implantación del sistema para razonar sobre este y tomar medidas destinadas a su mejora.

Interoperabilidad entre sistemas Los Procesos de Negocio pueden involucrar a varias organizaciones o sistemas distintos dentro de una misma organización. El principal freno a la introducción de nuevas tecnologías es la necesidad de mantener los sistemas legados. Un SUPN deberá ser capaz de integrar sistemas legados así como comunicarse con sistemas externos de forma sencilla.

4 Enfoque metodológico basado en DSDM

El aumento en tamaño y complejidad de los sistemas y las exigencias en cuanto a calidad y productividad han potenciado la búsqueda de mejoras en los métodos de producción de software. El Desarrollo de Software Dirigido por Modelos (DSDM) plantea el uso de modelos como los elementos centrales del desarrollo de software. Esta aproximación supone abstraer los detalles de implementación y utilizar conceptos cercanos al dominio del problema, lo que facilita la especificación del sistema.

El Object Management Group (OMG) introdujo Model Driven Architecture (MDA) junto a un conjunto de especificaciones para reducir la complejidad, bajar los costes y acelerar la introducción de nuevas aplicaciones software. Esta iniciativa propone el DSDM mediante el uso de estándares propuestos por la propia OMG. Entre éstos se incluyen estándares de modelado y metamodelado (especificación del lenguaje a usar para definir los modelos) como UML y MOF, así como un estándar de transformación entre modelos (MOF 2.0 QVT [26]).


156

El soporte del DSDM en lo que a herramientas se refiere crece día a día. Como ejemplo vale la pena comentar el proyecto de Eclipse Modeling2 el cual engloba una variedad de herramientas destinadas a dar soporte a lo largo de todo el proceso de desarrollo. Estas herramientas desarrolladas en el entorno de Eclipse permiten por ejemplo definir metamodelos, crear lenguajes gráficos y textuales de modelado o transformar modelos (tanto para generar nuevos modelos como para obtener código).

Dada la complejidad de los sistemas ubicuos, el DSDM puede resultar un método efectivo para su desarrollo ya que permite definir primitivas cercanas al dominio de aplicación.

La utilización de modelos en cualquier campo de la ingeniería tiene como uno de los objetivos principales verificar el correcto funcionamiento del sistema final antes de su implantación. Las características del DSDM permiten afrontar algunas de las necesidades destacadas en la sección 3.2 como la simulación del sistema [29].

4.1 Modelos a considerar

En base a los requisitos identificados en la sección 3.2, y puesto que apostamos por un enfoque de DSDM, en esta sección se presentan los modelos necesarios para llevar a cabo el desarrollo de SUPN. Estos modelos se han agrupado en tres grupos bien diferenciados los cuales se encargan de (1) modelar el Proceso de Negocio del sistema a desarrollar, (2) modelar la estructura del Sistema de Información Ubicuo y (3) modelar la interacción con los usuarios (ver Figura 1).

Figura 1 Modelos involucrados en la propuesta

Además de la agrupación de los modelos, esta figura muestra las relaciones/dependencias existentes entre ellos. Estas dependencias aparecen expresadas en forma de flechas etiquetadas con dos tipos de etiquetas. Por un lado, la

2 http://www.eclipse.org/modeling/


157

etiqueta «usa» indica que el modelo origen de la relación utiliza elementos incluidos en el modelo destino. Por otro lado, la etiqueta «genera» indica que el modelo destino se derivará total o parcialmente del origen (a través de la aplicación de las correspondientes transformaciones).

A continuación se describe cada uno de estos tres grupos así como los modelos que los forman, justificando su uso y detallando qué requisitos de los indicados en el apartado 3.2 se encargan de satisfacer.

Descripción del Proceso de Negocio La definición de los Procesos de Negocio mediante diagramas BPMN se ha mostrado efectiva en el contexto de aplicaciones Web tradicionales [22]. Sin embargo, para extender su campo de aplicación a los SUPN, esta notación debe ser revisada y extendida para cubrir las nuevas necesidades que introducen este tipo de sistemas.

Modelo de Proceso de Negocio Los distintos Procesos de Negocio se expresan mediante diagramas BPD siguiendo la notación BPMN. Este modelo describe las tareas que realiza cada participante en el proceso, así como su ordenación temporal y el intercambio de mensajes con entidades externas.

La notación BPMN permite clasificar las tareas en ocho tipos diferentes (Service, Receive, Send, User, Script, Manual, Reference y None). En este trabajo se utilizan sólo cinco de estos ocho tipos los cuales se han agrupado en los siguientes cuatro, (1) tareas manuales (sin soporte del sistema), (2) tareas de usuario (un participante humano interactúa con el sistema para llevar a cabo una tarea), (3) tareas de intercambio de mensajes (Send y Receive) y (4) tareas de servicios (tareas automatizadas). Para dotar al modelo de una semántica que permita derivar posteriormente el sistema ubicuo a partir de este modelo se asociarán las tareas de los grupos 2 y 4 (tareas de tipo usuario y servicio) con funcionalidad definida en los modelos Estructural y de Servicios.

El uso de un modelo de Proceso de Negocio como pieza central para el desarrollo del sistema, supone centralizar los cambios en el conocimiento de la organización. Utilizar BPMN como notación facilita la obtención de descripciones ejecutables del proceso. Esto permite trasladar los cambios de la descripción del proceso a su implementación en el motor de ejecución de forma automática, facilitando así la evolución del sistema.

Además, el papel que BPMN juega en una arquitectura SOA como integrador de servicios [28] permite abordar la interoperabilidad entre sistemas mediante la orquestación de diferentes servicios.

Modelo Estructural El Modelo Estructural permite definir la estructura del sistema (sus clases, operaciones y atributos) y relaciones entre clases (especialización, asociación y agregación) mediante el uso de un diagrama de clases.

Modelo Dinámico


158

Este modelo se define mediante un diagrama de transición de estados y permite determinar los cambios de estado que sufren los objetos del sistema definidos en el Modelo Estructural ante el disparo de distintos eventos[27]. El presente modelo trata de plasmar el ciclo de vida de un objeto definiendo que eventos están permitidos en cada uno de los estados y las transiciones entre estados.

Modelo Funcional Este modelo permite capturar la semántica de los cambios de estado que provocan la ejecución de las operaciones definidas en el modelo Estructural. Esta semántica está expresada mediante una especificación formal textual fundamentada en la lógica dinámica [27]. En ésta se podrán definir los cambios en el estado interno de los objetos indicando las precondiciones y postcondiciones ante la ocurrencia de eventos.

Modelo de Servicios El Modelo de servicios permite abstraer a nivel de modelado (y por lo tanto de forma independiente a la tecnología) funcionalidad que es proporcionada por sistemas externos o por dispositivos ubicuos que participan en el sistema. Éste modelo representa los elementos que ofrecen funcionalidad al sistema pero éste no se encarga de mantener su estado interno. Se especificarán dichos elementos y sus operaciones mediante un diagrama de clases. En el caso de los servicios ofrecidos por los dispositivos ubicuos, éstos se presentarán de forma independiente del dispositivo y será en los modelos que forman la parte de Sistema Ubicuo donde se asocien a un dispositivo concreto. De este modo, en el presente modelo podrá aparecer un servicio de “detección de presencia” sin especificar si este será implementado mediante una cámara, un sensor, otro dispositivo o un sistema externo.

Sistema Ubicuo Para permitir la construcción de un sistema basado en la Computación Ubicua a partir de descripciones de Proceso de Negocio se ha introducido un conjunto de modelos que permiten definir aspectos específicos del contexto. El Modelo de Contexto permite enriquecer los modelos Estructural y de Servicios aportando matices relevantes desde el punto de vista de la Computación Ubicua. Además de completar estos modelos, se ha considerado la introducción de algunos de los modelos utilizados en [20] para la construcción de sistemas pervasivos. Estos modelos intentan desacoplar en la mayor medida posible los servicios de los dispositivos que los implementan, facilitando así la evolución del sistema a nivel tecnológico.

Modelo de Contexto El modelo de Contexto permite definir características específicas del contexto a las relaciones/asociaciones existentes en el Modelo Estructural (tanto entre clases como entre una clase y sus atributos). Siguiendo el modelo propuesto por [18], estas asociaciones se clasifican en estáticas (relaciones fijas durante el ciclo de vida de la entidad) y dinámicas. Las asociaciones dinámicas, a su vez, se clasifican en sensoriales (obtenidas por algún tipo de sensor software o hardware), derivadas (se obtienen mediante una formula a partir de una o más asociaciones) y de perfil (obtenidas a partir de información proporcionada por el usuario).


159

Este refinamiento del Modelo Estructural tiene especial importancia ya que permite gestionar adecuadamente el comportamiento de los elementos que participan en el proceso. Por ejemplo este modelo permite indicar a nivel de modelado si los elementos con los que trabaja el sistema tienen un elemento real asociado y si su identificación es activa (el propio elemento se auto-identifica) o pasiva (el elemento posee un identificador que debe ser transmitido al sistema). En particular, referente a los mecanismos de identificación existen frameworks como Savant [11] o Cooltown [12] que permiten gestionar aspectos relativos a la auto-identificación abstrayendo detalles tecnológicos. Estas soluciones permiten dotar al sistema de mecanismos de identificación. La integración de estos frameworks con los elementos del sistema dependerá de la información especificada en el Modelo de Contexto.

Además, este modelo permite expresar restricciones sobre dependencias de las asociaciones (para evitar toma de decisiones incongruentes) y sobre la calidad de la información proporcionada por los distintos dispositivos (en términos por ejemplo de la fiabilidad de dichos dispositivos) para poder definir información contextual.

Modelo Estructural de Servicios Este modelo permite especializar los servicios definidos en el Modelo de Servicios en base al contexto en el que estos servicios se van a desarrollar. Por lo tanto, en este modelo se definirán las instancias (todavía independientes de dispositivo y por lo tanto de tecnología) de cada uno de los servicios que va a ofrecer el sistema. Por ejemplo, el servicio de “detección de presencia” descrito en el Modelo de Servicios, podrá tener varias realizaciones en el modelo actual (detección de un cliente próximo a un producto, detección de un intruso dentro de una zona restringida, etc.) encargadas de ofrecer la misma funcionalidad, pero en contextos distintos. El presente modelo desacopla la funcionalidad de los servicios de sus particularidades facilitando la especialización de servicios del mismo tipo en contextos distintos. Este modelo se representa mediante un diagrama de componentes UML 2.0.

Modelo de Proveedores de Enlace Este modelo define los tipos de dispositivos físicos (cámaras, sensores, etc.) que van a participar en el sistema proporcionando alguno de los servicios definidos en el Modelo de Estructura de Servicios.

Modelo de Estructura de Componentes El modelo de Estructura de Componentes sirve para enlazar el Modelo Estructural de Servicio con el Modelo de Proveedores de Enlace. Permite definir que tipos de dispositivo se usarán para implementar cada realización de los servicios que posee el sistema ubicuo. Las diferentes realizaciones comparten la misma funcionalidad, sin embargo, sus exigencias de calidad o precisión pueden variar y ser implementadas mediante diferentes dispositivos.

Interacción con los usuarios Los modelos utilizados en este grupo permiten dar soporte a las distintas formas de interacción con los usuarios así como a los diversos dispositivos que participan en el sistema. Para llevar a cabo el desarrollo de interfaces multi-modales, multi-dispositivo


160

y adaptables vamos a basarnos en la investigación desarrollada en el campo de la Interacción Hombre Máquina.

En [19] se introduce el concepto de plasticidad como la capacidad de adaptación de las interfaces a cambios físicos y del entorno manteniendo sus propiedades de usabilidad y se propone un framework para permitir mediante un enfoque metodológico la heterogeneidad de interacción de los sistemas ubicuos.

De dicho framework hemos adoptado los modelos de Tareas de Sistema, Interfaz Abstracta, Interactuadores e Interfaz Física para el desarrollo de nuestra metodología. Además de estos cuatro modelos, este framework define tres modelos más, uno de Tareas de Usuario, otro de Entorno y otro de Plataforma. Sin embargo, en nuestra propuesta metodológica estos modelos no se han introducido ya que resultan redundantes respecto a otros ya considerados. Por un lado, la información expresada por el Modelo de Tareas de Usuario queda recogida en el Modelo de Proceso de Negocio. La única diferencia es que el framework utiliza la notación ConcurTaskTrees [21] y en nuestro caso la notación empleada es BPMN. Sin embargo ambas notaciones tienen capacidad expresiva suficiente para representar tareas, su descomposición y tipo así como su relación temporal. El Modelo de Entorno permite representar información referente al contexto, información que nuestra metodología ya incluye en el Modelo de Contexto descrito previamente. Por último, el modelo de Plataforma definido por el framework permite describir las características físicas de la plataforma destino. En nuestra propuesta, esta función ya la realizan los modelos relativos al sistema ubicuo a distintos niveles de abstracción, donde el Modelo de Estructura de Componentes junto a la información relativa a dependencias y calidad de la información que introduce el Modelo de Contexto permite caracterizar la plataforma. El resto de modelos que se adoptan en nuestra propuesta, y que mantienen la semántica original propuesta en el framework, son comentados a continuación.

Modelo de Tareas de Sistema Este modelo describe como son llevadas a cabo las tareas en el sistema. Además de las tareas relativas al dominio de la aplicación incluidas en el Modelo de Proceso de Negocio, el modelo puede incluir tareas articulatorias (tareas que no modifican los valores de los conceptos del dominio) introducidas por los dispositivos físicos y restricciones de representación de los dispositivos del sistema.

Modelo Abstracto de Interfaz El presente modelo introduce la noción de Unidad de Presentación (Presentation Unit), una estructura jerárquica, con presencia de elementos del dominio, comportamiento asociado y enlaces para representar navegación.

Modelo de Interactuadores Los elementos de interacción disponibles por el sistema se representan en este modelo. Entendemos por interactuadores a los agentes de comunicación con estado interno y perceptible capaces de procesar y producir eventos provocados por un usuario o componente del sistema. Son los bloques básicos de construcción de las


161

interfaces, como puedan ser los widgets en interfaces gráficas o frases en interfaces por voz.

Modelo de Interfaz Física de Usuario La Interfaz Física de Usuario se obtiene al asociar un interactuador a cada Unidad de Presentación definida en el Modelo Abstracto de Interfaz siguiendo las restricciones expresadas en el resto de modelos.

4.2 Metodología propuesta

La especificación de un SUPN consistirá en la definición de los modelos presentados previamente donde se deberá respetar las relaciones de generación mostradas en la Figura 1. Inicialmente se definirán los modelos relativos a la especificación del Proceso de Negocio. Para disponer de un Modelo de Proceso de Negocio completo será necesario definir los elementos tanto del Modelo Estructural como de Servicios involucrados en el proceso. Los objetos de negocio definidos en el Modelo Estructural deberán ser completados mediante los modelos Dinámico y Funcional para especificar su ciclo de vida y evolución interna ante eventos.

Los modelos relativos al Proceso de Negocio no deben necesariamente especificarse de forma secuencial completando uno antes de iniciar el siguiente. Teniendo en cuenta que se trata de una fase temprana del desarrollo puede ser conveniente definir el Modelo de Proceso de Negocio y según se detecte la funcionalidad requerida ir añadiendo las clases o servicios que la proporcionen. En el caso de encontrarse en un dominio bien conocido, puede ser adecuado definir inicialmente el Modelo Estructural, para posteriormente especificar el Modelo de Procesos de Negocio como la coordinación de funcionalidad ya definida.

Una vez definidos los modelos que se refieren al Proceso de Negocio, se especificarán los modelos que caracterizan el aspecto ubicuo del sistema. Si bien los anteriores modelos reflejan qué información es utilizada, en los presentes se especificará cómo esta es obtenida y mediante que dispositivos. Por un lado se indicará la relación de los elementos del sistema con su entorno (Modelo de Contexto) y por otro la vinculación con los dispositivos (Modelo Estructural de Servicios, Modelo de Proveedores de Enlace y Modelo de Estructura de Componentes).

La definición de la interacción partirá del Modelo de Proceso de Negocio donde se añadirán tareas articulatorias (Modelo de Tareas de Sistema) y se estructurarán para definir una representación abstracta (Modelo Abstracto de Interfaz) para finalmente vincularlo mediante el Modelo de Interfaz Física de Usuario con los interactuadores disponibles definidos en el Modelo de Interactuadores. Los modelos relativos a la interacción deberán seguir la secuencia descrita anteriormente en su especificación ya que es posible derivar de forma automática un modelo preliminar en cada paso a partir del modelo anterior. De este modo, la agrupación de tareas realizada en el Modelo Abstracto de Interfaz permitirá determinar la elección del interactuador adecuado (un panel con pestañas o una lista desplegable, por ejemplo).

El papel que juegan los modelos de Interactuadores y de Proveedores de Enlace, aunque en contextos distintos, es similar ya que representan los elementos físicos de interacción y su definición puede llevarse a cabo en cualquier fase del proceso. Se


162

aconseja en ambos casos poseer un repositorio que permita la reutilización de estos modelos en diferentes aplicaciones, ya que sistemas diferentes compartirán dispositivos y mecanismos de interacción en su implementación.

5 Conclusiones y trabajo futuro

En este trabajo de posicionamiento se han presentado las ventajas que introduce el uso de la Computación Ubicua para dar soporte a Procesos de Negocio así como la necesidad de afrontar su desarrollo mediante una aproximación de DSDM. Además, se han identificado los requisitos a cubrir desde el punto de vista del modelado para dar soporte a la construcción de estos sistemas. Puesto que se trata de un trabajo de posicionamiento, como trabajos futuros hemos planificado la implantación del método propuesto en el método OO-Methtod [27]. El objetivo es dotar a éste de los modelos necesarios para la generación automática de sistemas ubicuos que den soporte a los procesos de negocio de una organización.

6 Referencias

[1] M. Weiser. The Computer for the 21st Century. Scientific American, 265(3):94–104, Sept. 1991.

[2] M. Langheinrich, V. Coroama, J. Bohn, M. Rohs. As we may live - Real world implications of ubiquitous computing. Technical Report, Institute of Information Systems, Swiss Federal Institute of Technology, Zurich, Switzerland, 2002. http://www.inf.ethz.ch/vs/publ/papers/ucimplications.pdf (13 July 2003).

[3] Strassner, M., Schoch, T. (2002): Today’s Impact of Ubiquitous Computing on Business Processes. In: Mattern, F. Naghshineh, M. (Eds.): Pervasice Computing. First Int. Conf. Pervasive Computing 2002, Zurich, Switzerland.

[4] Fleisch, E. Bussiness Perspectives on Ubiquitous Computing. M-Lab Working Paper No. 4. University of St. Gallen,Switzerland, 2001.

[5] Uwe Sandner, Jan Marco Leimeister, Helmut Krcmar. Business Potentials of Ubiquitous Computing. In: Proceedings of the Falk Symposium No. 146 bGut-Liver Interactions: Basic and Clinical Conceptsb. Innsbruck, Austria, 2005.

[6] Roussos, G., L. Koukara, P. Kourouthanasis, J. Touminen, O. Sappala and J. Frissaer (2002). "A Case Study in Pervasive Retail." ACM: 90-94.

[7] Lampe, M., Strassner, M., Fleisch, E.: A ubiquitous computing environment for aircraft maintenance. In: ACM Symposium on Applied Computing, Nicosia, Cypress (2004).

[8] T. Brooke and J. Burrell, "From ethnography to design in a vineyard", in Proceeedings of the Design User Experiences (DUX) Conference, June 2003, case Study.

[9] Elgar Fleisch and Christian Tellkamp. The challenge of identifying value-creating ubiquituous computing applications. In Workshop on Ubiquitous Commerce, International Conference on Ubiquitous Computing (UBICOMP’03), 2003.

[10] Peter Tandler: Software Infrastructure for Ubiquitous Computing Environments: Supporting Synchronous Collaboration with Heterogeneous Devices. In: Proceedings of UbiComp 2001: Ubiquitous Computing. Heidelberg: Springer LNCS 2201, 2001, pp. 96-115.


163

[11] Oat Systems and MIT Auto-ID Center. The Savant. Technical Report MIT-AUTOID-TM-003, MIT Auto-ID Center, May 2002.

[12] T. Kindberg et al. People, Places, Things: Web Presence for the Real World. In WMCSA 2000, Monterey, USA, Dec. 2000.

[13] G. Abowd, E.Mynatt. Charting Past, Present and Future Research in Ubiquitous Computing. ACM Transactions on Computer-Human Interaction, vol. 1, no. 7, March 2000, pp. 29–58.

[14] M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE Personal Communications, August 2001, pp. 10–17.

[15] K. Lyytinen, Y. Yoo. Issues and Challenges in Ubiquitous Computing. Communications of the ACM, vol.45, no12, December 2002, pp. 63–65.

[16] M. Langheinrich, V. Coroama, J. Bohn, M. Rohs. As we may live - Real world implications of ubiquitous computing. Technical Report, Institute of Information Systems, Swiss Federal Institute of Technology, Zurich, Switzerland, 2002.

[17] A. Stone. The Dark Side of Pervasive Computing. IEEE Pervasive Computing, January-March 2003, pp. 4–8.

[18] Henricksen, K., Indulska, J., and Rakotonirainy, A. Modeling context information in pervasive computing systems. In LNCS 2414: Proceedings of 1st International Conference on Pervasive Computing (Zurich, Switzerland, 2002), F. Mattern and M. Naghshineh, Eds., Lecture Notes in Computer Science (LNCS), Springer, pp. 167–180.

[19] D. Thevenin and J. Coutaz, "Plasticity of User Interfaces: Framework and Research Agenda", Proc. of INTERACT’99 (Edinburgh, August 1999), IOS Press, 1999.

[20] Javier Muñoz and Vicente Pelechano. Building a Software Factory for Pervasive Systems Development. In CAiSE 2005, Porto, Portugal, June 13-17, volume 3520 of LNCS, pages 329–343, May 2005.

[21] Paterno, Mancinii and Meniconi, 1997. "ConcurTaskTress: a Diagrammatic Notation for Specifying Task Models", In Proceedings of INTERACT 97, Chapman & Hall, 362-366

[22] Torres, V, Pelechano, V., Giner, P.: Generación de Aplicaciones Web basadas en Procesos de Negocio mediante Transformación de Modelos. In: Riquelme, J.C., Botella, P. (eds.): Ingeniería del Software y Bases de Datos. JISBD 2006. 443-452

[23] S. Domnitcheva: Location Modeling: State of the Art and Challenges, Location Modeling for Ubiquitous Computing Workshop at Ubicomp 2001, Atlanta

[24] Ouyang, C., van der Aalst,W.M.P., Dumas, M., ter Hofstede, A.H.M.: Translating BPMN to BPEL. BPM Center Report BPM-06-02, BPMcenter.org (2006)

[25] S. A. White. Business Process Modeling Notation (BPMN) Version 1.0. Business Process Management Initiative, BPMI.org, May 2004.

[26] OMG. MOF QVT Final Adopted Specification. ptc/05-11-01, Nov 2005. [27] Pastor, O., Gomez, J., Insfran, E., Pelechano, V. The OO-Method Approach for

Information Systems Modelling: From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems 26, pp 507–534 (2001).

[28] Christian Emig, Christof Momm, Jochen Weisser, Sebastian Abeck: Programming in the Large based on the Business Process Modeling Notation, Jahrestagung der Gesellschaft fur Informatik (GI), Bonn, September 2005.

[29] R. Heckel and M. Lohmann. Towards Model-Driven Testing. Electronic Notes in Theoretical Computer Science 82(6), 2003.

[30] Spinola, Rodrigo, Massolar, Jonson, Travassos, G. H. Towards a Conceptual Framework to Classify Ubiquitous Software Projects. In: SEKE 2006 - International Conference on Software Engineering and Knowledge Engineering, 2006, San Francisco. Proceedings of the SEKE 2006, 2006.


164

Experiencia en transformación de modelos de procesos de negocios desde BPMN a XPDL.

Beatriz Mora, Francisco Ruiz, Félix García, Mario Piattini

Universidad de Castilla-La Mancha, Escuela Superior de Informática, España {Beatriz.Mora | Francisco.RuizG | Felix.Garcia | Mario.Piattini}@uclm.es

Resumen. En este trabajo se presenta una primera experiencia de aplicación de MDA a la transformación de modelos de procesos de negocio, desde BPMN a XPDL. Se trata de transformaciones entre niveles M1 y M1 (en terminología MDA), es decir, entre modelos y modelos; pero con la particularidad de que los modelos BPMN son de naturaleza conceptual mientras que los modelos XPDL son de naturaleza lógica. Esto ha originado problemas a la hora de establecer las equivalencias entre elementos de BPMN y elementos de XPDL y, como consecuencia, se han sufrido complicaciones importantes para definir las transformaciones. Para llevar a cabo la experiencia se ha trabajado con el entorno de desarrollo ADT, funcionando sobre la plataforma ECLIPSE. Con esta herramienta se han utilizado diversos estándares soportados por MDA (MOF, QVT y OCL 2.0) y el lenguaje KM3 (Kernel MetaMetaModel) para describir los metamodelos. En este trabajo se explica la manera en que se ha llevado a cabo la experiencia y se comentan los principales problemas encontrados; entre los cuales caben resaltar dos: ausencia de una correcta impedancia entre ambos metamodelos, y algunas limitaciones de la herramienta. También se presentan las principales lecciones aprendidas.

Palabras Claves: MDA, Transformación de modelos, Procesos de negocio, BPMN, XPDL, ADT.

1 Introducción

La Arquitectura MDA [13], las transformaciones de modelos y los procesos de negocios son conceptos que están cobrando cada vez mas importancia en la ingeniería del software. Estos conceptos son el principal motor de esta experiencia, consistente en la aplicación de la arquitectura MDA en una transformación de modelos de procesos de negocio, representados en BPMN [10], a XPDL [19].

Las transformaciones se han realizado entre niveles M1 a M1, según la terminología MOF [12], pero con la peculiaridad que los dos metamodelos del nivel M2 subyacentes son de distinta naturaleza: BPMN es de naturaleza conceptual mientras que XPDL es de naturaleza lógica. Es una situación con un cierto parecido a los modelos conceptuales entidad/relación frente a los modelos lógicos relacionales, en el campo de las bases de datos.


165

Para llevar a cabo las transformaciones se ha utilizado el lenguaje ATL (Atlas Transformation Language) [7] sobre el entorno de desarrollo ADT (ATL Development Tools) [2], ambos desarrollados por la Universidad de Nantes (Francia).

Son tres los objetivos que han impulsado la realización de la experiencia. En primer lugar, probar la tecnología. En este sentido, interesaba utilizar un entorno de desarrollo intuitivo, amigable, que ayudase a realizar transformaciones aplicando los principios de MDA, y que estuviera basado en la tecnología Eclipse. ADT cumple todos estos requisitos. El segundo objetivo era trabajar con modelos y metamodelos de procesos de negocios. El tercer y último objetivo buscado era enfrentar el reto de una transformación compleja, como es el caso de BPMN vs XPDL.

El resto de este trabajo está organizado en los siguientes apartados: una continuación de la introducción, donde se comenta un aspecto que puede ser clarificador para el lector: estándares empleados para el modelado de procesos de negocio. En segundo lugar se explican las características del entorno tecnológico empleado durante la experiencia. En el tercer apartado se presentan los únicos trabajos relacionados conocidos. A continuación, en el tercer apartado se desarrolla la experiencia, detallando paso a paso lo que se ha realizado, también comentando los problemas encontrados. Y por último, un apartado de conclusiones.

1.1 Modelado de Procesos de Negocios

Mientras que el objetivo de un proceso software es obtener un producto software[1], el objetivo de un proceso de negocio es obtener resultados beneficiosos (generalmente un producto o servicio) para los clientes u otros interesados (stakeholders) [15]. Un modelo de proceso de negocio describe cómo funciona el negocio [6], es decir, describe las actividades involucradas en el negocio y la manera en que se relacionan unas con otras e interactúan con los recursos necesarios para lograr la meta del proceso.

El modelado de procesos de negocios se utiliza para capturar, documentar o rediseñar procesos de negocio. Para llevarlo a cabo se pueden emplear diversos lenguajes, con diferente naturaleza, características y objetivos.

BPMN (Business Process Modeling Notation) es una notación gráfica para el modelado conceptual de procesos de negocio. Proporciona la capacidad de entender y definir procesos de negocio, tanto internos como externos, a través de un diagrama de procesos de negocio. Es un estándar de facto que provee una representación gráfica (mediante diagramas) para expresar procesos de una empresa. Se diseñó con el objetivo de facilitar la comprensión por parte de todos los implicados (expertos TIC, analistas de negocio, directivos, etc.) que participan en el proceso.

XPDL (XML Process Definition Language) es un lenguaje para la definición de flujos de trabajo de procesos. Fue creado por la WfMC en el año 2001 y el 3 de octubre del 2005 se liberó la versión 2.0. XPDL forma parte de la interfaz uno (definición de procesos de negocio). Utiliza un formato de archivo basado en XML [18], que se puede usar para intercambiar modelos de procesos de negocio entre herramientas diferentes. Es un formato de archivo que representa el “dibujo” del grafo que representa la definición del proceso. Por esta razón, incluye elementos tales como el tamaño y las coordenadas X e Y de un nodo o las líneas que indican el camino a seguir. Los nodos y las líneas tienen atributos que pueden especificar información


166

sobre la ejecución del proceso, tales como roles, descripción de actividades, temporizadores, llamadas a servicios (web o de otro tipo), etc. La versión 2.0 incluye extensiones para poder representar todos los elementos de BPMN. Éste último hecho demuestra la importancia real que han cobrado ambos lenguajes. Por ello, puede resultar interesante y útil establecer mecanismos de transformación automatizados entre ambos, razón por la cuál cobra sentido la experiencia aquí presentada.

2 Entorno Tecnológico Empleado

Para este experimento interesaba utilizar un entorno de desarrollo que permita transformaciones siguiendo la filosofía de MDA y que esté basado en la tecnología Eclipse (www.eclipse.org). La arquitectura de plugins de Eclipse permite, además de integrar diversos lenguajes sobre un mismo IDE, introducir otras aplicaciones accesorias que pueden resultar útiles durante el proceso de desarrollo; tales como diseñadores en UML, editores visuales de interfaces, ayuda en línea para librerías, etc. Por todas estas razones, en esta experiencia se optó por emplear un entorno tecnológico que esté soportado por Eclipse. El entorno utilizado en este experimento, y que satisface estos requisitos, es ADT (ATL Development Tools), el cual proporciona herramientas para trabajar con el lenguaje de transformaciones ATL. Los elementos que se pueden encontrar en ADT son los típicos que pueden aparecer en un entorno de desarrollo: asistentes (wizards) para crear proyectos ATL que permiten ejecutar transformaciones, editor de textos, vistas de propiedades, iconos para especificar todos los elementos específicos de ATL, “builder” asociado al tipo de proyecto, distintas perspectivas, informes de errores de compilación, depurador, etc.

ATL es un lenguaje de transformación de modelos basado en los estándares del OMG, MOF, QVT [11] y OCL 2.0 [14]. Es un lenguaje híbrido, ya que se trabaja con construcciones declarativas e imperativas. Las construcciones declarativas son la opción preferida para escribir las transformaciones, puesto que son claras y precisas. Permiten expresar correspondencias, entre los elementos del modelo fuente y del modelo destino, a partir de una serie de composiciones de reglas. Adicionalmente, las construcciones imperativas proporcionan constructores para facilitar la especificación de correspondencias que de forma declarativa serían mucho más complejas de implementar.

El principio que hay que tener en cuenta a la hora de abordar una transformación en ATL, es que una transformación también es un modelo y, por tanto, cumple todas las propiedades de un modelo. Aunque con ATL es posible realizar diversos tipos de transformaciones (M1 a M2, M2 a M1, M3 a M1, M3 a M2, etc.), los objetivos de nuestro experimento han supuesto que sólo se hallan experimentado transformaciones M1 a M1 (de modelo BPMN a modelo XPDL). De todas formas, la filosofía MDA obliga a tener en cuenta y a utilizar los niveles superiores de modelado, ya que cada modelo se define conforme a un metamodelo, y éste a su vez se define respecto de un metametamodelo universal. MOF, ya comentado, y Ecore [4], que se introdujo con “Eclipse Modelling Framework” (EMF) [5], son los metametamodelos más significativos.

La transformación de modelos proporciona las facilidades para generar un modelo Mb (definido a partir de su metamodelo MMb) a partir de otro modelo Ma (definido


167

acorde a su metamodelo MMa). El modelo de la transformación es un tercer modelo que define las reglas necesarias para realizar la transformación. Por supuesto, también se define a partir de su metamodelo que en el caso que nos ocupa es el metamodelo de ATL. Todos estos metamodelos que intervienen en la transformación (el de entrada, el de salida y el de transformación) están a su vez definidos en base a un único metametamodelo, tales como MOF o Ecore.

En nuestro experimento, el modelo de transformación es un archivo ATL (MMa2MMb.atl), que está basado en el metamodelo ATL (ver Fig. 1). Este archivo contiene las reglas necesarias para la transformación de los modelos, incluyendo las correspondencias entre los metamodelos de entrada y de salida.

Fig. 1. Esquema de una transformación de modelos con ADT.

Para facilitar la codificación de los metamodelos se emplea KM3 [8]; un lenguaje creado por el mismo grupo de investigación de ATL. Este lenguaje proporciona una sintaxis textual similar a la notación de Java. La sintaxis abstracta de KM3 está basada en Ecore y eMOF 2.0. El formato de archivo .km3 se puede serializar en los formatos Ecore y MOF 1.4. Una vez escritos los metamodelos en KM3, ADT permite pasarlos a Ecore, traducción que es obligatoria porque las transformaciones ATL requieren que los metamodelos y modelos estén escritos en Ecore.

3 Propuestas relacionadas

Debido a su novedad, casi no existe información ni estudios relacionados con la transformación entre los lenguajes BPMN y XPDL. Se sabe que la última versión de XPDL, la 2.0, define las extensiones necesarias para poder representar BPMN pero, aún así, no existe ningún documento oficial que represente las transformaciones y correspondencias entre ambos lenguajes. El único trabajo conocido al respecto es el llevado a cabo por alguna empresa privada [17], en el cual se presentan algunas correspondencias entre los dos lenguajes que han servido de apoyo para la experiencia. La mayor limitación de esta propuesta es que no entra en detalle en el

MOF

MMa MMb

Ma Mb MMa2MMb.atl

ATL

M3

M2

M1


168

análisis de los elementos del primer lenguaje que corresponden con otro u otros del segundo lenguaje. Por esta razón, dicho trabajo ha tenido que ser realizado durante la realización de nuestro experimento y, de hecho, ha supuesto la mayor parte del esfuerzo realizado.

4 Transformación de BPMN a XPDL

En ATL, y por tanto en nuestro experimento, a la hora de llevar a cabo una transformación, es necesario realizar las siguientes etapas:

1) Creación del proyecto ATL:. Se emplea “ATL Proyect”, un módulo del entorno que ayuda a la creación de los proyectos ATL mediante un asistente.

2) Creación de los metamodelos KM3: en esta experiencia, los metamodelos son los correspondientes a BPMN y XPDL.

3) Creación del archivo ATL de transformación: que almacena las reglas de transformación entre los modelos.

4) Creación del modelo de entrada: para probar la experiencia, es necesaria la elaboración de un modelo de entrada, en este caso, el modelo de entrada corresponde a un modelo de BPMN utilizado de ejemplo.

5) Ejecución de la transformación para obtener el modelo de salida: se emplea el módulo “ATL builder” para obtener, en nuestro caso, el modelo XPDL correspondiente.

En los sub-apartados siguientes se detallan algunos de los aspectos más

significativos durante la realización de estas etapas.

4.1 Metamodelos

Tal como se ha explicado, para la transformación entre BPMN y XPDL se necesitan sendos metamodelos escritos en KM3. En un principio, los metamodelos que sirvieron de base se encontraron en la página oficial de Eclipse (xpdl.km3: última actualización 21/02/2006 y bpmn.km3: última actualización 20/09/2006). Al principio, pareció que encontrar estos metamodelos ya creados pareció solucionar la tarea más costosa de codificación, pero, analizando dichos metamodelos, se comprobó que el de BPMN estaba incompleto porque se refería a la versión 1.0 y sólo incluía algunos elementos (Activity, BpmnDiagram, Message, Pool, Properties, PropertiesType, Subproceso), dejando a muchos otros sin precisar. En cambio, el metamodelo de XPDL, sí coincidía casi por completo con la especificación de su lenguaje.

Para solventar el problema del metamodelo BPMN se pensó en escribir el metamodelo a partir de sus especificación correspondiente [10], pero resultaba un trabajo demasiado laborioso para los objetivos del experimento. Por ello, finalmente se optó por crear dos metamodelos parciales de BPMN y XPDL, que describieran sólo los elementos más representativos. Para alcanzar los objetivos de la experiencia era suficiente con dichos metamodelos parciales ya que, lo que interesaba, era que existiese una transformación entre lenguajes de modelado de procesos de negocio


169

conceptuales y lógicos. Además, en este punto cabe resaltar que se descubrió que no existen correspondencias plenas entre ambos metamodelos, es decir, muchos elementos de uno de los metamodelos no tienen un elemento equivalente (o similar) en el otro metamodelo. Por todo ello, los elementos que se incluyeron en los metamodelos parciales fueron sólo aquellos que tienen correspondencia plena, es decir, con equivalentes en el otro metamodelo y, en consecuencia, son transformables de BPMN a XPDL.

De esta forma, el metamodelo parcial de XPDL, utilizado como entrada en la transformación, incluye sólo los elementos más significativos que tienen equivalente en el lenguaje BPMN. Por otro lado, al estar incompleto el metamodelo de BPMN disponible en la web de Eclipse, se optó por utilizar como punto de partida, para el metamodelo de salida, el metamodelo subyacente de la herramienta de modelado de procesos de negocio “eBPMN Designer” [16]. La principal ventaja de ésta herramienta es que ya trabaja con la nueva versión oficial 2.0. La desventaja que hubo que superar es que hubo que realizar ingeniería inversa para disponer del metamodelo BPMN a partir del código de la herramienta, ya que no figura de forma explícita como un recurso, documento o archivo específico.

En la siguiente figura (Fig. 2) se muestra parte del código de ambos metamodelos, escrito en KM3. La imagen de la izquierda corresponde al metamodelo de XPDL y la imagen de la derecha al metamodelo de BPMN.

Fig. 2. Parte del código del metamodelo de XPDL (izq.) y BPMN (der.) en KM3.

4.2 Correspondencias

Una vez que se tienen los metamodelos, el siguiente paso es la creación del fichero de transformación ATL. Dentro de éste fichero se definieron todas las reglas necesarias para la transformación entre modelos BPMN y XPDL, basados en los previamente referidos metamodelos parciales. Lo primero que hubo que abordar era la lista de correspondencias a implementar. Para ello nos basamos en la propuesta ya comentada en el apartado 2. El resultado fue la lista de correspondencias mostrada en la Tabla 1. Por las razones ya comentadas, los elementos considerados en nuestra experiencia fueron los mostrados en negrita en la citada tabla: Business Process


170

Event

FlowObjectname : String

ProcessObjectattributes : Stringdocumentation : String

Event

Activity

Elementid : Stringname : String

Diagram, Event, Task, SequenceFlow y Pool (este elemento no se encontraba en [17] y fue añadido).

Tabla 1. Correspondencias identificadas entre BPMN y XPDL

BPMN XPDL Business Process Diagram Package Process WorkflowProcess Subprocess SubFlow Activity Activity Gateway Route (Child of Activity) Gate Transition (see below) Event Event InputPropertyMaps OutputPropertyMaps

DataMappings

Task Task (Child of Activity Implementation)

Artifact Artifact (Child of Activity) Graphical Connecting Objects, SequenceFlow, MessageFlow, Association

Transition

Property Field Pool Pool

En la figura 3 se muestra la correspondencia entre elementos Event de BPMN y

XPDL.

Fig. 3. Correspondencia Event (BPMN) - Event (XPDL).

En la siguiente imagen (Fig. 4), se hace lo mismo pero para los elementos de tipo Task (tareas). También, para mejorar la visibilidad, se han omitido las subclases de Task: ManualTask, ServiceTask, UserTask, ScriptTask, ReferenceTask, ReceiveTask y SendTask.


171

Transitionfrom : Activityto : ActivityQuantity : Integer


SequenceFlowfrom : Stringto : StringQuantity : Integer

Connect ingObjectname : String

ProcessObjectattributes : Stringdocumentation : String

TasktriggerKind : Stringimplementation : String

Activity


TasktaskType : String

Activityname : String

Fig. 4. Correspondencia Task (BPMN) - Task (XPDL).

La figura 5 representa la correspondencia entre elementos SequenceFLow (en BPMN) y elementos Transition (en XPDL).

Fig. 5. Correspondencia SequenceFlow (BPMN) – Transition (XPDL).

Por último, en la figura 6, se muestra parte del código que implementa todas estas correspondencias mediante reglas de transformación. Como se observa en dicha figura, el archivo de transformación está compuesto de reglas (rules), de forma que existe al menos una regla por cada elemento. En cada una de estas reglas se indica el elemento origen de BPMN y su correspondencia con el elemento destino de XPDL.


172

Fig. 6. Ejemplo del código del archivo de transformación bpmn2xpdl.atl.

4.3. Ejemplo

Tal como se explicó anteriormente, para ejecutar la transformación es necesario que los metamodelos se traduzcan al formato Ecore, operación que se realiza automáticamente por el entorno ADT. Por tanto, parece que el lenguaje KM3 sólo ha servido para facilitar la codificación en un estilo amigable a “lo Java” en lugar de emplear alguno de los estándares de metamodelado basados en XML (MOF/XMI, Ecore).

Completada la fase de la escritura de los metamodelos, el siguiente paso es la creación del modelo BPMN de entrada (bpmnModel.ecore) que será transformado al correspondiente modelo XPDL de salida (xpdlModel.ecore), ambos escritos en Ecore. Con fines ilustrativos, se ha elegido como modelo BPMN el mostrado en la figura 7. Se puede observar que sólo se incluyen los elementos Pool, StartEven (subtipo de Event), EndEvent (subtipo de Event), UserTask (subtipo de Task) y SequenceFlow. El Pool es un servicio web formado por dos eventos (InicioEvento y FinEvento), dos tareas (RecibiendoPeticion y EnviandoPeticionDisponible) y tres flujos de secuencia que conectan InicioEvento con RecibiendoPetición, RecibiendoPetición con EnviandoPeticionDisponible y EnviandoPeticionDisponible con FinEvent.


173

Fig. 7. Modelo BPMN de ejemplo creado con la herramienta eBPMN y su correspondiente

codificación (parte) en Ecore. Escrito el modelo BPMN, la transformación es automática. Tan sólo hace falta

asociar los metamodelos en Ecore y el archivo de transformación al proyecto, y ejecutar la transformación. Con el ejemplo anterior, se obtuvo el código Ecore de la figura 8, que representa el modelo XPDL correspondiente.

Fig. 8. Codificación en Ecore (parte) del modelo XPDL obtenido.

4.4 Principales Dificultades Encontradas

A pesar de que la experiencia ha resultado satisfactoria al alcanzarse los objetivos buscados, han surgido algunos problemas y dificultades que merecen ser destacados.

La tabla de correspondencias encontrada en [17] sólo es orientativa y, en realidad, no resuelve el problema de la transformación entre BPMN y XPDL, es decir, no precisa la correspondencia atributo por atributo de los elementos. Esta labor ha sido realizada dentro de éste experimento de la forma más completa posible, pero con la limitación de que se han encontrado elementos cuyos atributos no coinciden totalmente entre ambos lenguajes. Por ejemplo, en el caso de “Activity” (actividad), elemento excluido en los metamodelos parciales probados (ver tablas 2 y 3), los atributos de actividad en BPMN no coinciden con los de XPDL, y tampoco se cumple


174

que los de BPMN son un subconjunto de los de XPDL o viceversa. Por tanto, al transformar desde BPMN a XPDL siempre se pierden atributos y también al trasformar en dirección contraria. En cambio, para el elemento “Event” (evento), incluido en los metamodelos parciales, los atributos que tiene en BPMN son los mismos que los que tiene en XPDL, aunque con distintos nombres.

En la siguiente tabla (Tabla 2) se muestran los elementos excluidos del metamodelo BPMN para la transformación.

Tabla 2. Elementos excluidos de la transformación del metamodelo BPMN

BPMN Activity InputPropertyMaps Artifact Lane Assignment LaneElement Association Loop BPMNObject Message BusinessProcessUnit MessageFlow Cancel MultiInstanceLoop Compensation OutputPropertyMaps ComplexGateway ParalellGateway ConnectingObject Participant DataBasedExclusiveGateway Process DataObject ProcessObject EmbeddedSubProcess Property Error ReferenceSubProcess EventBasedExclusiveGateway Rule ExclusiveGateway StandardLoop Expresión Subprocess FlowObject Swimlane Gate TextAnnotation Gateway Timer Group Transaction InclusiveGateway WebService IndependentSubProcess

En la Tabla 3 se listan los elementos excluidos del metamodelo XPDL para la

transformación. Otros problemas encontrados están en relación con el entorno de desarrollo ADT.

Se han encontrado errores y carencias que dificultaron la tarea en el momento de la codificación. En primer lugar, el entorno no compila el archivo de transformación, por lo que aunque se incluyan elementos incorrectos en las reglas de transformación que no existan o estén mal escritos, el compilador no lo detecta. Otro problema es la actualización de los metamodelos, cada vez que se modifican los metamodelos hay que pasarlos de nuevo a Ecore, ya que no se realiza automáticamente por parte del entorno. Otro aspecto a resaltar es la utilización de KM3. Como ya hemos indicado, no parece justificarse el empleo de una nueva notación, si al final la transformación se realiza en Ecore obligatoriamente. En cuanto a la documentación sobre ADT y el


175

lenguaje ATL, se han echado en falta ejemplos de transformaciones que ilustren casos más complejos, a la altura de la transformación aquí abordada.

Tabla 3. Elementos excluidos de la transformación del metamodelo XPDL

XPDL Activity Object ActivitySet ParametrizedApplication Annotation Participant Application ReferencedApplication Artifact ResultCompesation Association ResultError BlockActivity ResultMultiple Category Route DataField SubFlow DataObject Transition Element Trigger Event TriggerIntermediateMultiple ExternalPackage TriggerMultiple ExternalReference TriggerResultLink Field TriggerResultMessage Gateway TriggerRule Group TriggerTimer Lane TypeDeclaration MessageFlow WorkFlowProcess

5 Conclusiones y Trabajo Futuro

La experiencia aquí presentada ha sido satisfactoria en el sentido de que se alcanzaron los objetivos perseguidos: i) se han podido conocer las características, ventajas y limitaciones del lenguaje ATL y la plataforma ADT; y ii) también se han podido conocer y comprobar las dificultades reales que supone la “buena idea” de la transformación automática de modelos para un caso de complejidades realistas. De forma adicional, se ha podido descubrir que todavía no existen metamodelos adecuados para las versiones actuales oficiales de BPMN y de XPDL. Sin la disponibilidad de dichos metamodelos de forma pública y estandarizada, se hace muy difícil e improbable el éxito del nuevo paradigma de desarrollo dirigido por modelos.

De forma más concreta, se ha descubierto que al establecer las correspondencias entre elementos de BPMN y XPDL surge una dificultad bastante grande porque no están nada claras las equivalencias semánticas entre ambos lenguajes. En nuestra opinión, dicha dificultad es debida a la naturaleza conceptual de BPMN frente a la naturaleza lógica de XPDL. Los conceptos empleados en BPMN se refieren al dominio del problema (cómo funciona la empresa) mientras que los de XPDL se refieren al dominio de la solución (cómo es el flujo de trabajo adecuado para que funcione así).


176

Creemos que un trabajo importante de cara al futuro será desarrollar una adecuada metodología que identifique y establezca las adecuadas correspondencias conceptual-lógico, entre BPMN y XPDL, así como la definición de reglas que permitan la generación de las partes de XPDL que no tienen una equivalencia en BPMN El resultado de este esfuerzo puede llegar a tener tanta importancia como tienen, desde hace muchos años, las reglas de transformación entidad/relación (el BPMN de las bases de datos) a esquemas relacionales en SQL (el XPDL de las bases de datos).

Por último, como continuación de la experiencia aquí presentada y buscando superar las limitaciones de ADT ya comentadas, se ha decidido probar con otros entornos tecnológicos diferentes. Por ello, actualmente se acaba de empezar otra experiencia más completa con el entorno MOMENT [3], [9].

Agradecimientos

Este trabajo ha sido parcialmente financiado por los proyectos ENIGMAS (Junta de Comunidades de Castilla-La Mancha, Consejería de Educación y Ciencia, PBI-05-058), ESFINGE (Ministerio de Educación y Ciencia, Dirección General de Investigación, Fondos FEDER, TIN2006-15175-C05-05) y COMPETISOFT (Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo, 506AC0287).

Referencias

1. Acuña, S.T. y Ferré, X., Software Process Modelling. In Proceedings of the 5th. ISAS-SCI 2001. Orlando Florida, USA, 2001: p. pp. 237-242

2. Allilaire, F. y Tarik, I., ADT: Eclipse development tools for ATL. Université de Nantes. Faculté de Sciences et Techniques. LINA, 2005

3. Boronat, A., Oriente, J., Gómez, A., Ramos, I. y Carsí, J.A., An Algebraic Specification of Generic OCL Queries within the Eclipse Modeling Framework. Second European Conf. on Model Driven Architecture (ECMDA). Bilbao (Spain). Springer LNCS. July 10th-13th 2006,

4. Budinsky, F., Steinberg, D., Ellersick, R. y Grose, T.J., Book, Chapter 5 ”Ecore Modeling Concepts". 2004, Addison Wesley Professional

5. Budinsky, F., Steinberg, D., Ellersick, R. y Grose, T.J., Eclipse Modeling Framework. 2004, Addison Wesley Professional

6. Dufresne, T. y Martin, J., Process Modeling for E-Business. George Mason University, Spring 2003, INFS 770 - Methods for Informations Systems Engineering: Knowledge Management and E-Business., 2003

7. ATLAS group LINA & INRIA, ATL: Atlas Transformation Language ATL. User Manual; Versión 9.7. 2006.

8. ATLAS group LINA & INRIA, KM3:Kernel MetaMetaModel Manual; Version 0.3. 2004. 9. Grupo ISSI: MOMENT (A framework for Model ManagemENT), Consultado el 10-enero-

2006. http://moment.dsic.upv.es/ 10. Object Management Group, Business Process Modeling Notation Specification. 2006. Final

Adopted Specification: dtc/06-02-01. 11. Object Management Group, Meta Object Facility (MOF) 2.0 Query/View/Transformation

Specification. 2005. Final Adopted Specification ptc/05-11-01.


177

12. Object Management Group, Meta Object Facility (MOF) Specification; version 1.4. 2002. Document. formal/02-04-03.

13. Object Management Group, Model-Driven Architecture (MDA) Guide Version 1.0.1. 2003. OMG Document, omg/2003-06-01. http://www.omg.org/mda/aspecs.htm

14. Object Management Group, OCL 2.0 - OMG Final Adopted Specification. 2003. ptc/03-10-14.

15. Sharp, A. y McDermott, P., Workflow Modeling: Tools for Process Improvement and Application Development. London: Artech House, 2001

16. Soyatec, eBPMN Designer. http://www.soyatec.com/ebpmn/ 17. CAPE VISIONS. Software to Simplify Complexity, XPDL with BPMN Extensions. 2004.

http://www.omg.org/bpmn/Documents/WfMC/XPDL with BPMN Extensions.doc 18. W3C, Extensible Markup Language (XML) 1.0 (Fourth edition). 2006. A technical

recommendation standard of the W3C. http://www.w3.org/TR/REC-xml 19. The Workflow Management Coalition Specification, Process Definition Interface - XML

Process Definition Language; Version 2.0. 2005. Document Number WFMC-TC-1025. Document Status – Final.


178

Verification of Models in a MDA Approach for

Collaborative Business Processes

Pablo D. Villarreal1, Jorge Roa

1, Enrique Salomone

1,2, Omar Chiotti

1,2

1CIDISI - Universidad Tecnológica Nacional - Facultad Regional Santa Fe, Lavaisse 610,

3000, Santa Fe, Argentina

([email protected]) 2INGAR-CONICET, Avellaneda 3657, 3000, Santa Fe, Argentina

({salomone,chiotti}@ceride.gov.ar)

Abstract. The application of a MDA approach for the automatic generation of

B2B specifications from collaborative business process models enables

enterprises to implement B2B collaborations with their partners, reducing the

costs, time and complexity in the generation of technological solutions. Because

of collaborative processes describe the behavior of the interactions between the

partners, an important issue is the verification of the correctness of these

processes, such as the absence of deadlocks and livelocks. In this work we

describe how collaborative process models can be verified exploiting the

benefits of a MDA approach. We describe the formalization of collaborative

process models defined with the UP-ColBPIP language by using Petri Nets and

the transformations of UP-ColBPIP models into Petri Nets specifications. Thus,

a formal semantics for collaborative process models is provided, which enables

the verification of these models through tools for verification of Petri Nets.

Keywords: MDA, Business-to-Business, Collaborative Business Processes,

Petri Nets, Model Transformations

1 Introduction

The modeling and specification of collaborative business processes is a central issue

in order to enterprises can implement Business-to-Business (B2B) collaborations.

Through these processes, partners undertake to jointly carry out decisions to achieve

common goals, coordinate their actions and exchange information.

Models of collaborative processes are defined in the business level of a B2B

collaboration. They are designed from a business perspective by business analysts and

system designers, who are not acquainted and do not want to deal with the technical

details of the B2B collaboration. Hence, collaborative process models should be

defined independent of any implementation technology [1].

Specifications of collaborative processes are defined in the technological level of a

B2B collaboration, in which enterprises focus on the implementation of the B2B

information systems that support the collaborative processes. In this level enterprises

have to generate the specifications of both collaborative processes and partners’


179

systems interfaces by using a particular B2B standard. There are two main

technologies to define these B2B specifications [3]: standards based on Web Services

Composition, such as BPEL (Business Process Execution Language) [4] and WS-

CDL (Web Services Choreography Description Language) [12]; and standards based

on Business Transactions, such as ebXML [17].

The model-driven development and the Model-Driven Architecture (MDA) [13]

were identified as key enablers to support the modeling and specification of business

processes [2, 21]. We have proposed a MDA approach that enables both the design of

collaborative processes independent of the idiosyncrasies of particular B2B standards,

and the automatic generation of B2B specifications based on a B2B standard from

conceptual collaborative process models [19, 21]. As part of this approach, the UML

Profile for Collaborative Business Processes based on Interaction Protocols (UP-

ColBPIP) has been defined. This language enables business analysts to model

collaborative processes using concepts closer to the B2B collaboration domain than

the implementation technology.

To enhance the benefits of the model-driven development and MDA, the

verification of technology-independent models in an early stage of the development

has been recognized as an important issue [15]. This is because of in an early stage of

the development is when business analysts and system designers make most of the

fundamental decisions. Furthermore, since collaborative process models describe the

behavior of the interactions between the partners in B2B collaborations, the

verification of the correctness of these process models is required.

To achieve this objective, it is necessary the application of a formal language to

verify collaborative process models. UP-ColBPIP is a semi-formal language. Hence,

to verify collaborative processes, it is necessary the formalization of this language.

In this work we propose an extension to the MDA approach for collaborative

processes for supporting the verification of technology-independent collaborative

process models. We use Hierarchical Colored Petri Nets [11] to formalize

collaborative processes defined with the UP-ColBPIP language and define the

transformations of UP-ColBPIP models into Petri Nets models. In this way, a formal

semantics for collaborative process models is provided which enables the verification

of these models by using existing analysis techniques and tools for Petri Nets.

This paper is organized as follows. Section 2 overviews the MDA approach for

collaborative processes and the UP-ColBPIP language. Section 3 presents the

extension to this MDA approach for enabling the verification of collaborative process

models. Section 4 presents the formalization of the primitives of the UP-ColBPIP

language through Colored Petri Nets patterns and describes the transformation of UP-

ColBPIP models into hierarchical Colored Petri Nets. Section 5 describes the meaning

of the Colored Petri Nets properties for the verification of interaction protocols.

Section 6 describes related works and section 7 gives conclusions and future works.

2 MDA Approach for Collaborative Business Process

We have proposed a MDA approach for collaborative processes [21] that enables the

automatic generation of B2B specifications from technology-independent


180

collaborative process models. The XML code to be generated corresponds to the

specifications of: collaborative processes and partners’ systems interfaces both based

on technology-specific languages (or B2B standards). The development process of

this MDA approach consists of two phases: analysis and design of collaborative

processes, and generation of B2B specifications. Following, we describe these phases.

2.1 Analysis and Design of Collaborative Business Processes

The UML Profile for Collaborative Business Processes based on Interaction

Protocols (UP-ColBPIP) that extends the UML2 semantics to model technology-

independent collaborative processes from a business perspective. This language

encourages a top-down approach and supports the modeling of four views:

• B2B Collaboration View, which defines the participants (partners and their roles)

of a B2B collaboration, the collaborative agreement’s parameters and the common

business goals to be fulfilled by the partners.

• Collaborative Processes View, which identifies the collaborative processes

required to achieve the common business goals. UP-ColBPIP extends the

semantics of use cases to identify collaborative processes.

• Interaction Protocols View, which defines the explicit behavior of the collaborative

processes through the use of interaction protocols. UP-ColBPIP extends the

semantics of the UML2 interactions to model interaction protocols.

• Business Interfaces View, which defines the business interfaces of the partners.

These interfaces contain the business services (operations) that support the

exchange of messages of the interaction protocols. To define this view, UP-

ColBPIP extends the semantics of the UML2 composite structures and interfaces.

The first and second views correspond to the analysis stage. The last views

correspond to the design stage. The output of this phase is a UP-ColBPIP model with

the four views, which will contain the description of the collaborative business

processes to be carried out in a B2B collaboration. More details about this language

can be found in [19, 21]. Following, we describe the main view for the purpose of

verifying the behavior of collaborative processes: the Interaction Protocols View.

In the B2B collaborations domain, an interaction protocol describes a high-level

communication pattern through a choreography of business messages between

partners playing different roles. Modeling interaction protocols, the focus is on

representing the global view of the interactions between the partners. The message

choreography describes the global control flow of the peer-to-peer interactions

between the partners, as well as the responsibilities of the roles they fulfill.

UP-ColBPIP allows the association of a speech act to business messages. A speech

act represents the intention that a partner has with regard to the business document

sent in the message. Thus, decisions and commitments done by the partners can be

known from the speech acts. This also enables the definition of complex negotiations.

As an example, we describe the interaction protocol Demand Forecast Request

(Figure 1). In this protocol, partner “A” plays the supplier role and partner “B” plays

the customer role. They are represented by lifelines. The purpose of this protocol is

the supplier and the customer agrees on the type of forecast demand to be defined.

The protocol starts with the supplier, which requests a forecast demand, as it is


181

indicated by the message request(DemandForecast). Then, the customer processes the

received message with its contents and makes a decision. The customer can respond

of two different forms, as it is expressed by the control flow segment with the Xor

operator. This operator indicates that only one of the two paths can occur according to

the condition defined in each path. One alternative is the customer accepts the

supplier’s request and commits to carry out the demand forecast in the future. It is

expressed by the message agree(ResponseToForecastRequest). The business

document of this message contains more information about the customer’s response.

Then, the execution of the protocol continues. Another alternative is the customer

sends a message refuse(ResponseToForecastRequest) to indicate that it rejects the

type of forecast requested by the supplier. The business document of this message

contains the reasons of the rejection. In this case, the protocol finishes with a failure

from the point of view of the business logic (it does not represent a technical failure),

as it is indicated by the explicit termination event failure.

If the customer agrees on carry out the forecast, then the nested protocol

Collaborative Demand Forecast is invoked in order to partners agree on a common

demand forecast. After its execution the protocol finishes, because every protocol has

an implicit termination by default.

Furthermore, the business messages of the Xor control flow segment have defined

time constraints representing deadlines, which indicate these messages have to be sent

before two days, after of the occurrence of the first message.

Xor

Object1 Object2

request(DemandForecast)

Partner A:Supplier

Partner B:Customer

agree(ResponseToForecastRequest)

refuse(ResponseToForecastRequest)

{t..t+2d}

{t..t+2d}

{t=now}

refCollaborative Demand Forecast

sd <<protocol>> Demand Forecast Request

[Failure]

Fig. 1. Sequence Diagram of the Demand Forecast Request Interaction Protocol

2.2 Generation of B2B Specifications

This phase involves the generation of B2B specifications, i.e. the specifications of the

collaborative processes and the partners’ interfaces by using a specific B2B standard.

Figure 2 shows the pattern of transformations applied in this phase, which follows the

principles of MDA. The input is the UP-ColBPIP model that contains the defined


182

collaborative processes based on interaction protocols and the business interfaces of

the partners. Two types of models have to be generated: technology-specific business

process models and technology-specific partners’ interfaces models. These models are

generated through the definition and execution of model-to-model transformations

that are carried out by using a tool for model transformations. Also, it requires the

building of the metamodels corresponding to the technology-specific models to be

generated. These metamodels are derived from the XML schemas of the technology-

specific languages. Model-to-XML code transformations supports the generation of

XML documents corresponding to the B2B specifications based on a B2B standard.

TechniquesComponents

UP-ColBPIP Model (Collaborative Processes based

on Interaction Protocols)

Transformations of

UP-ColBPIP into Technology-

Specific Process Models

Transformations of

UP-ColBPIP into Technology-

Specific Interface Models

Technology-Specific

Business Process Models

Technology-Specific

Partner’s Interface Models

Model to XML Code Transformations

Technology-Specific Business

Process Specifications

Technology-Specific Partner’s

Interface Specifications

Modeling Language

UP-ColBPIP

Technology-Specific

Business Process Metamodel

Technology-Specific Partner’s

Interface Metamodel

Production Rules of

XML Code

B2B Standard

Languages

Tool for Model

Transformations

Fig. 2. Pattern of Transformations to generate B2B Specifications

To support this MDA pattern of transformations, we have developed a tool [14] for

model transformations of collaborative processes. We use AGG [16] to support the

definition of the model-to-model transformations as graph transformations. The tool

takes an XMI file containing a UP-ColBPIP model, converts it to a graph and

executes the corresponding transformation rules using the AGG engine. Also, the tool

supports the generation of the XML specifications from the output graph of the

transformation through the application of production rules of XML code.

In previous works we proposed and described the application of this MDA

approach to generate technological solutions based on the current and more used B2B

standards: ebXML [20], BPEL [22] and WS-CDL [23]. We showed how UP-ColBPIP

models can be used to generate technological solutions based on these B2B standards.


183

3 Adding a Verification Support to the MDA Approach for

Collaborative Business Processes

Due to collaborative processes describe the behavior of the partners in the

collaboration, as well as the form in which the partners’ systems will interact, the

verification of properties of these processes, such as the absence of deadlocks and

livelocks, is required.

The use of technology-independent models to verify system’s properties in an early

stage of the development has been recognized as one of main aspects to be supported

by a model-driven method [15], because in a early stage of the development is when

business analysts and system designers make most of the fundamental decisions.

To achieve the above requirement, we extend the MDA approach and propose the

verification of the collaborative processes should be done after the definition of the

technology-independent collaborative process models. This means the verification

should be applied on these models instead of the B2B specifications. Thus, the

development process of the MDA Approach consists of three phases (Figure 3):

1. Analysis and design of collaborative processes.

2. Verification of collaborative processes.

3. Generation of B2B Specifications.

Verification of Collaborative Processes

Analysis and Design of Collaborative Business Processes

Formal Specifications of Collaborative Processes

B2B SpecificationsTechnology-independent Collaborative Process Models

Generation of B2B Specifications

Fig. 3. Phases of the MDA approach for collaborative business processes

The output artifact of the first phase is the technology-independent collaborative

processes model, which is the input for the next phases. In the second phase, the

output artifacts are the specifications of collaborative processes in a formal language,

in such a way they can be verified. According to the results of the verification, it is

possible to go back to the first phase to correct the processes. Several cycles of

analysis/design and verification can occur. Finally, once the collaborative processes

were agreed, the third phase consists of selecting a B2B standard and generating the

B2B specifications that fulfill the collaborative processes defined in the first phase.

To produce the output artifacts of the second phase, Figure 4 shows the pattern of

transformations to be applied. The input is a UP-ColBPIP model that contains the

defined collaborative processes based on interaction protocols. Model-to-Model

Transformations are applied to generate Petri net models. These models are defined

according to the language PNML (Petri Net Marking Language) [5], which is a XML-

based standard language for Petri nets. This XML-based language is currently used by

most of the tools for Petri Nets. The PNML metamodel can be generated from the

XML schema of PNML to enable the building of PNML models.


184

Finally, from these models, XML documents containing Petri nets specifications

corresponding to the interaction protocols are generated. In this way, Petri Nets tools

can be used to read the generated Petri nets specifications, carry out the verification of

the Petri Nets and determine the correctness of the collaborative processes based on

interaction protocols. Particularly, we have used CPN Tools [7] as the tool to verify

the properties of Petri Nets.

TechniquesComponents

Tool for Model

Transformations

Model to XML Code Transformations

Modeling Language

UP-ColBPIP

PNML Metamodel

Production Rules of XML Code

PNML Language

UP-ColBPIP-to-PNML Transformations

UP-ColBPIP Model (Collaborative

Processes based on Interaction Protocols)

PNML Models

PNML Specifications

Fig. 4. Pattern of Transformations to generate Petri Nets Specifications

4 Formalizing the UP-ColBPIP Language with Petri Nets

To verify the correctness of collaborative processes, we formalize interaction

protocols defined with UP-ColBPIP by using Hierarchical Colored Petri Nets.

4.1 Hierarchical Colored Petri Nets

Colored Petri Nets (CP-Nets) [11] provide a technique for the construction and

analysis of distributed and concurrent systems. A CP-Net model of a system describes

the states of a system and the transitions between those states. CP-Nets have a wide

variety of analysis techniques and moreover they provide primitives to describe

concurrent synchronization processes. CP-Nets are graphically represented by places

(ellipse), transitions (rectangles), directed arcs and tokens. The set of tokens in the

places marks the state of the system. Transitions and places are connected through

arcs. A transition becomes active, i.e. it can be fired, when there is at least one token

on each input place of the transition. The firing of the transition removes the tokens

from each input place and put a token on each output place.

Hierarchical CP-Nets use the idea of substitution transitions. A transition can be

related to another CP-Net, which is called the subnet or CP-Net module. The input

and output places of the substitution transition are related with port places of the

subnet, which constitute the interface with the substitution transition. Through the


185

input port places, the subnet receives the tokens from the input places of the

substitution transition. Analogously, the subnet delivers tokens to the output places of

the substitution transition through its output ports. Hierarchical CP-Nets allow the

building of large CP-Nets from smaller CP-Nets.

4.2 Transformation of Interaction Protocols into Hierarchical CP-Nets

To transform interaction protocols into hierarchical Colored Petri Nets (CP-Nets), we

propose a set of predefined patterns of CP-Nets. Each CP-Net pattern represents and

formalizes a UP-ColBPIP primitive. Then, CP-Net modules are built from these

patterns and are composed into hierarchical CP-Nets for representing the interaction

protocols to be verified. The transformation of interaction protocols into CP-Nets is

carried out applying the following principles:

• An interaction protocol is mapped into a CP-Net model with hierarchical structure.

• There is a CP-Net pattern for each primitive of the UP-ColBPIP language used to

define interaction protocols.

• The hierarchical CP-Net representing an interaction protocol is built by composing

CP-Net patterns according to the primitives used in the interaction protocol.

• The control flow of the messages choreography of the protocol is represented by

one control flow token, which represents an instance of the protocol.

• There is only one end place for the hierarchical CP-Net representing the protocol.

The transformation procedure of interaction protocols into CP-Nets consists of:

1. Take a protocol, generate its hierarchical CP-Net and iterate on its elements,

because of an interaction protocol is defined as an ordered set of interaction

elements. One start place and one end place is added to the generated CP-Net for

representing the start and the implicit finalization of the protocol.

2. Each protocol element is mapped into a CP-Net module according to the primitive

used and its corresponding CP-Net pattern.

3. A CP-Net module corresponding to an element is added to the hierarchical CP-Net

through a substitution transition that makes reference to the module. The input and

output places of the substitutions transitions of a hierarchical CP-Net are related

with the port places defined in the CP-Net modules.

4. In the hierarchical CP-Net, the generated substitution transitions represent the

order of the elements in the protocol and are connected with their respective input

and output places.

Following, we describe the main CP-Net patterns (Table 1) that formalize the UP-

ColBPIP primitives for interaction protocols.

CP-Net Pattern of a Business Message. A business message is mapped into a CP-

Net containing: three places that represent the states of a message, i.e. ready, sent and

received; and two transitions representing the events of sending and receiving of the

message. These places and transitions represent the basic type of business message.

Furthermore, a message can have defined two types of time exceptions: duration and

deadline. This is represented by the places duration and deadline and the transitions

duration_exc_ev and deadline_exc_ev. If the message has defined a deadline


186

exception, there will be an initial marking in the place deadline with an exception

token. In this way, the transition deadline_exc_ev will be enabled when the message

has been sent. If the time exception occurs in the message, the transition

deadline_exc_ev will be fired and it will consume the exception token, the transition

receive_event will be disabled and will not be fired, and the control token will be put

in the place deadline_exc to indicate the time exception has occurred. In a similar

way, the duration exception of the message is represented.

Finally, a message can also have acknowledgements. These acknowledgments are

represented by another CP-Net pattern. It is not shown here because we assume the

delivery of the message’s acknowledgements is guaranteed by the implementation

technology and hence, it does not affect the verification process. If acknowledgments

are defined in a message, a transition is added as output of the place received that

represents the module containing the CP-Net pattern of the acknowledgements, as

well as a place acks_received is added that represents the sender have received the

corresponding acknowledgments from the receiver.

CP-Net Patterns of Control Flow Segments. A Control Flow Segment (CFS)

represents complex message sequences in the interaction protocol’s choreography. It

contains a control flow operator and one or more interaction paths. An interaction

path can contain the following primitives: messages, termination events, interaction

occurrences, and nested control flow segments. The semantics of a CFS depends on

the operator used: Xor, Or, And, If, Loop, Transaction, Exception, Stop and Cancel.

The And operator represents the execution of parallel interaction paths in any order.

The Xor operator represents that only one path, of a set of alternative paths, can be

executed in case its condition is evaluated to true. The Or operator represents the

selection of several paths from several alternatives. Each path is executed in case its

condition is evaluated to true. The Loop operator represents a path that can be

executed while its condition is satisfied. For each operator of a CFS we define a CP-

Net Pattern. Table 1 contains the CP-Net patterns that describe the behavior of the

types of CFSs. In the transformation process, a CFS is transformed into one of these

CP-Net patterns. An interaction path of a CFS is transformed into a CP-Net module.

The substitution transitions, which represent the paths in these CP-Net patterns, will

reference the modules of the paths. A CP-Net module representing a path is built by

using the CP-Net Patterns according to the primitives used in that path.

For example, the CP-Net that represents the CFS with the And operator contains

the places and transitions representing the split and the join of an AND constructor in

CP-Nets. Furthermore, it contains the substitution transitions representing the

execution of the paths. The same occurs with the CFSs with the Or and Xor operators.

Mapping of Terminations and Subprotocols. An interaction protocol can have

implicit or explicit terminations. Explicit termination events are: success and failure.

Success implies the protocol ends in a successful way. Failure implies the protocol

ends in an unexpected way from the point of view of the business logic. Also, an

interaction protocol can have Interaction Occurrences, which represent the invocation

of another interaction protocol referred as the subprotocol or nested protocol. For

these primitives there are not CP-Net patterns. Instead, an interaction occurrence is


187

mapped into a transition referencing the CP-Net module representing the subprotocol.

Termination events are mapped into transitions representing the events and a

termination place. Due to the CP-Net representing a protocol has only one end place,

the termination places are merged with this end place. This implies that they behave

as the end place, i.e., once a token is put in this place, the protocol’s instance finishes.

Table 1. CP-Net patterns representing the UP-ColBPIP primitives.

UP-ColBPIP primitives CP-Net Patterns

Business Message:

Control Flow Segment (AND)

Control Flow Segment (XOR) Xor

path 1

path 2

Control Flow Segment (OR)

Or

path 1

path 2

Control Flow Segment (Loop) Loop (0,n)

path


188

4.3. Example of Transformation of Interaction Protocols into CP-Nets.

We show the transformation of the protocol of Figure 1, which was described in the

section 2.1, into a hierarchical CP-Net (Figure 5.a). It contains a start place indicating

the initiation of the protocol. The substitution transition msg_request_DF references

the CP-Net module representing the first message of the protocol.

The transition msg_request_DF has an input place startDFR and an output place

received that are related with the places ready and received respectively of the CP-Net

module representing a business message. The input place received and output place

Xor_out of the transition Xor are related respectively with the places Xor_split and

Xor_join of the CP-Net module representing the Xor CFS. This CP-net module

(Figure 5.b) was built using the corresponding CP-Net pattern of a CFS with the Xor

operator. Due to the first path of the CFS has only one message, a transition

representing the message is added. The second path is mapped into the CP-Net

module refuse (Figure 5.c). It contains a transition that represents the corresponding

message and another one that represents the failure termination event. Because we

define hierarchical CP-Nets that have only one end place, the place failure is merged

with the end place of the CP-Net representing the protocol. In addition, since the

execution of the second path implies a termination of the protocol instance, the

transition refuse in the CP-Net module that represents this path does not contain an

output place. This means that when the transition is executed, a token is put in the

failure place of the submodule and the execution of the CP-Net finishes.

Finally, the hierarchical CP-Net contains a transition representing the subprotocol

and another one representing the implicit termination event of the protocol.

a)

b) c)

Fig. 5. Hierarchical CP-Net of the Demand Forecast Request protocol

5 Verification of CP-Nets Representing Interaction Protocols

The behavioral properties of CP-Nets can be verified by using the state space

method provided by CPN Tools [7]. The state space method relies on the computation

of all reachable states and state changes to verify the properties of CP-Nets. Table 2

describes the properties of a CP-Net identified as relevant for the verification of

interaction protocols. Furthermore, the table describes how these properties have to be

interpreted for determining the correctness of a CP-Net representing a protocol.


189

For example, dead transitions are used to detect when a path of a CFS does not

have any element, and when the paths of an And CFS have success or failure

terminations and the protocol has more elements then of the CFS. In these cases it is

possible to inform the protocol can have a deadlock. Also, dead transitions will occur

when a message does not have a defined exception time. In this way, it is possible to

inform the message should have defined a deadline or duration exception for the

protocol can be finished and does not have an infinite execution time.

Table 2. Interpretation of CP-Net Properties for the verification of interaction protocols

CP-Net property Meaning in the verification of interaction protocols

Reachability Indicates if it is possible to achieve the states of a protocol, i.e. if the

elements of the protocol can be achieved and executed

Boundness The number of maximum tokens in each place have to be 1

Dead Transitions Indicates if some elements of the protocol will never be executed, which

could produce a deadlock

Dead Marking Must exist at least one dead marking which indicates the final state of

the protocol, else the protocol has an infinite loop

Live Transitions If there are live transitions, this means that there can be an infinite loop

in the protocol

Home Marking Must exist one home marking corresponding to the final state of the

protocol, i.e. the state final can be achieved from any state

Fairness Determines if each path in the protocol has the chance to be selected

6 Related Work

There are different proposals to verify business processes based on technology-

specific languages such as BPEL [9, 18] and WS-CDL [10]. Petri Nets were used to

formalize control flow constructors of BPEL [18]. The main difference with our work

is these approaches can be used to verify processes in a late stage of the development,

i.e. when the technological solution has been already generated. Although a MDA

method can be applied to generate BPEL and WS-CDL specifications [22, 23] and

then the above approaches can be used to verify these specifications, the main issue is

when the results of the verification indicate modifications should be done to fix the

B2B specifications. In this case, a transformation procedure is required to propagate

automatically these modifications to the corresponding collaborative process models;

and the modifications have to be done in the technological level using the selected

B2B standard language, instead of the business level.

Petri Nets were also proposed to model and verify services compositions [8]

representing the global view of the interactions between the partners. In our work, we

use Petri Nets into a MDA approach to formalize and verify models built with a

higher level language, with the purpose of hiding to the business analysts the

complexity and limitations of using a formal language to model business processes.

Finally, there are works that apply MDA approaches or model transformations for

business processes [2, 6]. However, they do not consider a verification phase into

their development process.


190

7 Conclusions and Future Work

In this work we have proposed an extension to a MDA approach for the modeling and

specification of collaborative business processes in order to enterprises can generate

automatically formal specifications of collaborative processes and verify the

correctness of these processes.

We have highlighted the importance of the verification of technology-independent

collaborative process models. This enhances the benefits of the MDA approach for

collaborative processes, because of the verification of these processes can be done in

an early stage of the development, when most of the fundamental decisions of a B2B

collaboration are carried out and previous to the generation of the technological

solutions. In addition, the verification of these processes is essential for partners can

be sure that the behavior of the collaborative processes is well-defined.

In this MDA approach, the behaviour of collaborative processes is modelled

through the definition of interaction protocols by using the UP-ColBPIP language.

Therefore, to enable the verification of interaction protocols, we have proposed their

formalization by using hierarchical CP-Nets and we have described the

transformations of interaction protocol into hierarchical CP-Nets. For each primitive

of the UP-ColBPIP language, a CP-Net pattern was defined that represents its formal

semantics. The CP-Net patterns are used to build hierarchical CP-Nets representing

interaction protocols, where each CP-Net module contained in these CP-Nets is

defined according to the CP-Net pattern of the primitive that it represents.

Furthermore, we have provided the interpretation of the CP-Nets properties to be

verified for determining the correctness of the interaction protocols.

Furthermore, we have described the pattern of transformations to be applied for

generating hierarchical CP-Nets specifications based on the PNML language from

UP-ColBPIP models. This pattern of transformations follows the principles of MDA

and reuses the tools for model transformations we use to generate B2B specifications

based on B2B standards. In addition, PNML-based specifications can be read by most

of the existing Petri Nets Tools to verify properties of the CP-Nets representing the

interaction protocols. Particularly, we have used CPN Tools to do this.

Our ongoing work is about the implementation of the transformations of UP-

ColBPIP models into CP-Nets specifications based on PNML by using the tool for

model transformations of collaborative processes we have developed. Another future

work is to support the automatic interpretation of the verification results generated by

the CPN Tools, in order to people, which are not familiarized with Petri Nets, can

interpret the results of the verification of interaction protocols.

References

1. Baghdadi, Y.: ABBA: An architecture for deploying business-to-business electronic

commerce applications. Electronic Commerce Research and Applications, 3(2004) 190-212

2. Baïna, K, Benatallah, B., Cassati, F., Toumani, F.: Model-Driven Web Service

Development. CaiSE’04, LNCS Springer (2004) 290-306.

3. Bernauer, M., Kappel, G., Kramler, G.: Comparing WSDL-based and ebXML-based

Approaches for B2B Protocol Specification. Proceedings of ISOC’03 (2003).


191

4. BEA, IBM, Microsoft, SAP, Siebel: Business Process Execution Language for Web

Services. http://www-106.ibm.com/developerworks/library/ws-bpel/, 2003.

5. Billington, J., Christensen, S., van Hee, K.E., Kindler, E., Kummer, O., Petrucci, L., Post,

R., Stehno, C.: The Petri Net Markup Language: Concepts, Technology, and Tools. 24th

Int. Conf. on Applications and Theory of Petri Nets, LNCS 2679 (2003) 483-505.

6. Bruno, G. and La Rosa, M.: From Collaboration Models to BPEL processes through service

models. BPM Workshops 2005, WSCOBPM 2005, 75-88, 2005.

7. CPN tools. http://www.daimi.au.dk/CPNtools/

8. Dijkman, R.M, Dumas, M.: Service-oriented Design: a Multi-viewpoint Approach.

International Journal of Cooperative Information Systems (IJCIS) 13(4), pp. 337-368, 2004.

9. Ferrara, A: Web Services: a Process Algebra Approach. The Proceedings of the 2nd

International Conference on Service Oriented Computing (ICSOC 2004). ACM (2004)

10. Foster, H., Uchitel, S., Magee, J., Kramer, J. Model-Based Analysis of Obligations in Web

Service Choreography. IEEE International Conference on Internet & Web Applications and

Services, Guadeloupe, French Caribbean (2006).

11. Girault, C., Valk, R.: Petri Nets for System Engineering: A Guide to Modeling,

Verification, and Applications, Springer-Verlag New York, Inc, 2001.

12. Kavantzas, N., Burdett, D., Ritzinger, G., Fletcher, T., Lafon, Y.: Web Services

Choreography Description Language Version 1.0. W3C Candidate Recommendation(2005)

13. Object Management Group: MDA Guide V1.0.1, 2003. http://www.omg.org/mda.

14. Pochettino, J.P.: Ambiente de Software para Transformaciones de Modelos de Procesos de

Negocio Colaborativos. Undergraduate Thesis. Universidad Tecnológica Nacional, Santa

Fe, Argentina (2006).

15. Selic,B :The Pragmatics of Model-Driven Development. IEEE Software,20(5),19-25(2003)

16. Taentzer. AGG: A Graph Transformation Environment for Modeling and Validation of

Software. Application of Graph Transformations with Industrial Relevance (AGTIVE’03),

Springer, LNCS 3062 (2004) 446 – 456.

17. UN/CEFACT and OASIS: ebXML Business Specification Schema Version 1.10,

http://www.untmg.org/downloads/General/approved/ebBPSS-v1pt10.zip (2001)

18. Verbeek, H.M.W., van der Aalst, W.M.P.: Analyzing BPEL Processes using Petri Nets.

Second International Workshop on Applications of Petri Nets to Coordination, Workflow

and Business Process Management. Florida, USA, (2005) 59-78.

19. Villarreal, P.: Method for the Modeling and Specification of Collaborative Business

Processes. PhD Thesis. Universidad Tecnológica Nacional, Santa Fe, Argentina (2005).

20. Villarreal, P., Salomone, H.E. and Chiotti, O.: Applying Model-Driven Development to

Collaborative Business Processes. Proceedings of the 8th Ibero-American Workshop of

Requirements Engineering and Software Environments (IDEAS 2005), Chile, 2005.

21. Villarreal, P., Salomone, H.E. and Chiotti, O.: Modeling and Specifications of

Collaborative Business Processes using a MDA Approach and a UML Profile. In: Rittgen,

P. (eds): Enterprise Modeling and Computing with UML. Idea Group Inc, 2006.

22. Villarreal, Salomone, Chiotti: MDA Approach for Collaborative Business Processes:

Generating Technological Solutions based on Web Services Composition. 9th Ibero-

American Workshop of Requirements Engineering and Software Environments, (2006).

23. Villarreal, P., Salomone, H.E. and Chiotti, O.: Transforming Collaborative Business

Process Models into Web Services Choreography Specifications. 2dn IEEE International

Workshop on E-Commerce and Services, Springer, LNCS 4055 (2006) 50-65.


192



193

Towards a Standardized Description and

a Systematic Use of Social Patterns

Carla Silva1, João Araújo

2, Ana Moreira

2, Jaelson Castro

1

1 Centro de Informática, Universidade Federal de Pernambuco, 50732-970, Recife, Brazil {ctlls, jbc}@cin.ufpe.br

2 CITI/Dept. Informática, FCT, Universidade Nova de Lisboa, 2829-516 Caparica, Portugal {ja, amm}@di.fct.unl.pt

Abstract. The detailed design of Multi-Agent Systems (MAS) is intended to

introduce additional detail for each architectural component of the system

according to agent-oriented design patterns. In this paper, we propose a process

to perform the detailed design of MAS using UML-based diagrams and social

patterns. This process is described in detail using the SPEM notation and is

illustrated with the e-News example, where the social patterns description

technique is exemplified with the Matchmaker pattern.

1 Introduction

The detailed design phase of the software development lifecycle introduces

additional detail to the structure and behavior of each architectural component of a

system. In Tropos [7], a framework for developing MAS, the detailed design phase

defines how the goals assigned to each actor present in the architectural model are

fulfilled by agents performing roles according to social patterns [11]. However,

Tropos does not provide a systematic way to choose and apply the social patterns in

the detailed design of the MAS under development. To solve this issue, we define a

process to guide the detailed design of MAS using UML-based diagrams and social

patterns. The description of this process is achieved by using the SPEM (Software

Process Engineering Metamodel) notation [14]. To describe the social patterns, we

have used a technique called Agent Pattern Specification (APS) [20], based on the

Unified Modeling Language (UML) standard [13] and the work on Pattern

Specifications (PSs) [5]. We illustrate the proposal using a content management

system, called e-News [18].

This paper is organized as follows: Section 2 reviews some background work on

SPEM, social patterns, agent-oriented modeling notation and APS technique, to

describe social patterns using a standard notation. Section 3 presents the Detailed

Design process and describes it using the SPEM notation. Section 4 illustrates our

approach for performing the detailed design of MAS using social patterns. Section 5

compares our proposal with existing related works. Finally, section 6 summarizes our

work and points out directions for future work.


195

2 Background

The purpose of this work is to propose and specify in SPEM a process to perform the

detailed design of MAS using both an agent oriented modeling notation [19] and

social patterns [11]. The SPEM is a UML metamodel (and UML profile) [13] to

represent a family of software development processes and their components [14]. It

constitutes a sort of “ontology” of software development processes. Some relevant

SPEM concepts used in this work can be found in [14].

The APS technique, to describe social patterns, uses model roles [10] to specialize

the agency metamodel [19]. Thus, this section introduces the social patterns, the agent

oriented notation (based on the agency metamodel) and the APS technique.

2.1 Social Patterns

Social patterns [11] have been defined in the context of Tropos [7], a framework

aimed at building software that operates within a dynamic environment. In this work,

we concentrate on the detailed design phase which consists of defining how the goals

assigned to each agent present in the architectural model are fulfilled by agents

performing roles according to social patterns. The social patterns defined in Tropos

include Booking, Subscription, Call-For-Proposals, Bidding, Matchmaker, Monitor,

Broker, Mediator, Embassy and Wrapper patterns. Here we will use the Matchmaker

pattern to illustrate the APS technique.

2.2 Agent Oriented Modeling

In this section, we present the MAS architectural diagram specified according to the

agency metamodel introduced in [19] and reflecting the client-server pattern [16]

that we have tailored for MAS. We define the MAS architectural diagram (Fig. 1) in

terms of AgentRole, Goal, MacroPlan, ComplexAction, OrganizationalPort,

AgentConnector, Dependum, Dependee and Depender. A Dependum defines an

“agreement” of service offer between two agent roles. The agent role responsible for

providing the service is the dependee. The agent role that requests the service is the

depender. A dependum can be of four types: goals, softgoals, tasks and resources [24].

Agent roles need to exchange signals through an AgentConnector to accomplish the

contractual agreement of service providing between them. An OrganizationalPort

specifies a distinct interaction point between the AgentRole and its environment

(depicted as a white square attached to the «AgentRole» class). A Goal is a condition

or state of affairs in the world that the Agent has committed itself to achieve. How the

goal is to be achieved is not specified, allowing alternatives to be considered [12]. A

Plan encapsulates the recipe for achieving some goal. An AgentAction determines the

steps to perform a plan.

For example, in Fig. 1 we have the Provider agent role which is responsible for

performing the service defined in the Dependum. This agent role aims at achieving the

ServicePerformed goal by executing the PerformPlan plan, which, in turn, consists of


196

performing the service() AgentAction. The Client agent role aims at achieving the

ServiceRequested goal by executing the RequestPlan plan, which, in turn, consists of

performing the request() AgentAction. Thus, the Client agent role is responsible for

requesting the service defined in the Dependum. Both the message for requesting the

service execution and the message for confirming whether the service was successfully

concluded are sent through the AgentConnector.

Fig. 1. MAS Architectural Diagram

2.3 Agent Pattern Specification

To describe social patterns we propose a technique, called APS [20], that specializes

the agency metamodel for MAS architectural diagram [19] by using the concept of

model roles [10]. In fact, the concept of model roles was used in the PS technique [5]

to specialize the UML metamodel for specifying which model elements must

participate in a pattern.

The following sub-sections describe the template used to specify a social pattern

(section 2.3.1) and the respective structural specification (section 2.3.2). The

communication specification complements the pattern description and can be found in

[21]. These are illustrated by the Matchmaker pattern.

2.3.1 Pattern Template

The template used to describe social patterns (with a subset of GoF’s template [6])

was introduced in [20] to illustrate the Matchmaker pattern. Its main attributes are

Name, Intent, Applicability, Motivation example, Problem, Solution and Participants.

2.3.2 Structural Agent Pattern Specification

A structural agent pattern specification (SAPS) defines subtypes of agency

metaclasses describing MAS architectural diagram elements (e.g., agency metaclasses

AgentRole, AgentConnector) and specifies semantic pattern properties using

constraint templates (see Fig. 2). An SAPS consists of a structure of pattern roles [10],

where a role specifies properties that a MAS model element must have if it is to be

part of a pattern solution model. Formally, a role defines a subtype (specialization) of

an agency metaclass. The metaclass is called the base of the role. For example, a role

that has the metaclass AgentConnector as its base specifies a subset of MAS agent


197

connectors. A MAS model element conforms to (or plays) a role if it satisfies the

properties defined in the role, that is, the element is an instance of the subtype defined

by the role. A role in an SAPS can be a classifier or a relationship role. A role that has

the base Classifier or a base that is a subtype of Classifier (e.g., AgentRole,

Dependum) is a classifier role. A relationship role is any role that has the base

Relationship or a base that is a subtype of Relationship (e.g., Association,

AgentConnector).

Fig. 2. Matchmaker Structural Agent Pattern Specification

Fig. 2 shows an SAPS that specifies solutions of the Matchmaker pattern [11]. The

matchmaker involves an intermediary AgentRole (matchmaker) that receives requests

from service Providers to subscribe/unsubscribe its services into the yellow pages

maintained by it. A Client may need a specific service provided by an unknown

Provider. The Matchmaker also receives requests from Clients to locate some

Providers which offer a specific service. If there is some Provider for the requested


198

service, the Matchmaker informs that Provider’s identification to the Client which, in

turn, can directly interact with it [20].

The SAPS of the Matchmaker pattern is described using the client-server

architectural pattern (Fig. 1). The Matchmaker pattern has to provide three services

(i.e. dependums): Locate Provider, Perform Service and Subscribe Yellow Pages. For

example, in the shaded area of the Fig. 2 we have the classes involved in the |Locate

Provider service defined in a Dependum class. When the |Client AgentRole executes

the |Request Provider Identification MacroPlan by performing the requestProviderID

ComplexAction in order to achieve the |Provider Identified Goal, it triggers a request

to the |Matchmaker AgentRole to perform the |Locate Provider Service. The

|Matchmaker AgentRole performs the requested service because it does not conflict

with the achievement of the Yellow Pages Service Provided Goal. A conflict is

detected when the service requested to an agent playing a specific agent role, can

cause the failure of some of its goals. Hence, both the requested service and the goal

achievement are accomplished by means of the Yellow Pages Server MacroPlan. The

description of the Perform Service and Subscribe Yellow Pages services is achieved in

a similar way.

Here we will use the idea proposed in [23] for using model roles only in the

elements of the pattern that will vary from one application to another, since when the

pattern is applied to a specific application, these roles will be instantiated to model

elements of the application. For example, the SAPS in Fig. 2 consists of only seven

model roles: three for AgentRole metaclass (Client, Provider and Matchmaker), one

for Goal metaclass (|Provider Identified), one for MacroPlan metaclass (|Request

Provider Identification) and two for Dependum metaclass (|Locate Provider and

|Perform Service).

3 The Detailed Design Process

The detailed design phase involves two ProcessRoles (Agent Designer and Software

Architect), three Guidances (Agency Metamodel, i* Framework and Mapping

Heuristics) and ten WorkProducts (five UMLModels, two MASModels and three

Documents), presented in Fig. 3.

According to Fig. 3, each ProcessRole performs specific activities that can use

specific Guidance to consume and/or produce different WorkProducts.

The Agent Designer ProcessRole is responsible for choosing the most appropriate

agent model for the internal architecture [3]. The Software Architect ProcessRole is

the person, team, or organization responsible for the systems’ architecture [8].

In Fig. 4, we can find the Activities performed by each ProcessRole, the

WorkProducts consumed and produced by each activity as well as the workflow of the

detailed design activities.

The Detailed Design Process (Fig. 4) is composed of nine activities: Perform

means-end analysis, Map i* to UML, Specify architectural model, Specify

environmental model, Specify communication model, Specify intentional model,

Specify action model, Select social pattern and Apply social pattern.


199

Perform means-end analysis helps identifying the reasons/motivations associated

with each dependency that an agent possesses [24] and produces the SR Architectural

Model WorkProduct. Map i* to UML uses a set of heuristics presented in [19] to

guide the mapping of i* description of MAS architecture to the UML-based notation

for MAS [19] and produces the Mapping Document WorkProduct. Specify

Architectural Model specifies the MAS according to the architectural model (aided by

the Mapping Document WorkProduct) and produces the Architectural Model

WorkProduct. Specify Action Model specifies the MAS according to the action model

[17]. Currently this is made in an ad hoc fashion and produces the Action Model

WorkProduct.

Fig. 3. Detailed Design Package

Specify Environmental Model specifies the MAS according to the environmental

model (aided by the Mapping Document WorkProduct) and produces the

Environmental Model WorkProduct. Specify Communication Model specifies the

MAS according to the communication model (aided by the Mapping Document

WorkProduct) and produces the Communication Model WorkProduct. Specify

Intentional Model specifies the MAS according to the intentional model (aided by the

Mapping Document WorkProduct) and produces the Intentional Model WorkProduct.

In Select Social Pattern, the software architect can, for example, analyze the templates

[20] that describe several features of each social pattern to address a specific

requirement. This activity produces the Design Decisions WorkProduct. Finally, the

Apply Social Pattern applies the chosen social patterns through instantiation of each

model role present in the structure of the pattern (e.g., |Client, |Locate Provider) and

updates the Architectural, Environmental, Intentional, Communication and Action

Models.


200

Fig. 4. Workflow for the Detailed Design Process

The Strategic Dependency (SD) Architectural Model is a WorkProduct consumed

by the Perform means-end analysis activity. This is an i* framework model which

describes a network of dependency relationships among various (architectural) actors,

capturing the motivation and why of activities [24]. The Catalogue of Social Patterns

is a WorkProduct consumed by the Select Social Pattern Activity and includes all the

social patterns [11] described in detail using the approach presented in Section 2.3.

In the following we can find the explanation of each WorkProduct produced in the

Detailed Design Process (Fig. 4). The Strategic Rationale (SR) Architectural Model is

an i* framework model which describes and supports the reasoning that each

(architectural) actor goes through concerning its relationships with other

(architectural) actors by using a means-ends analysis [24]. The Architectural Model is

a UML-based model defined in terms of AgentRoles which possess goals achievable

by plans. Since an AgentRole is not omnipotent, it needs to interact with other

AgentRoles in order accomplish its responsibilities.

An AgentRole possesses OrganizationalPorts which enable the exchange of

messages with other AgentRoles through AgentConnectors in order to accomplish


201

some Dependum (i.e., service contract) [19]. The Communication Model is a UML-

based model defined in terms of Agents playing AgentRoles and the messages

exchanged between them to achieve a service providing [19]. The Environmental

Model is a UML-based model defined in terms of AgentRoles composing an

organization which is situated in an environment. This environment is composed of

resources which are accessed by the AgentRoles according to their rights in order to

accomplish their responsibilities [19]. The Intentional Model is a UML-based model

defined in terms of agents, their beliefs, agent roles, goals, plans, as well as the norms

and the ontology used in the organization [19]. The Action Model is a UML-based

model described in terms of agent plans and actions using UML 2.0 activity diagrams

[17]. The Mapping Document stores textually the mapping between i* concepts and

concepts of the UML-based notation for MAS. The Design Decisions WorkProduct

stores the decisions taken during the selection of social patterns for designing a MAS.

The i* Framework, Agency Metamodel and Mapping Heuristics are used by the Agent

Designer ProcessRole to execute its activities.

The i* Framework includes concepts such as actor and social dependencies among

actors as well as two diagrams: Strategic Dependency (SD) and Strategic Rationale

(SR) [24]. The Agency Metamodel is an extension to the UML metamodel [13] which

defines a UML-based notation for MAS architecture [19]. The Mapping Heuristics is

a set of heuristics to describe MAS using our UML-based notation derived from an

architectural description using i* [19].

4 Case Study

To illustrate the adoption of our process (Fig. 4), we consider the example of e-

News System [18]. The e-News system enables a user to read news by accessing the

newspaper website maintained by a Webmaster agent which is responsible for

updating the published information. The information to be published is provided by

the Chief Editor agent. The Chief Editor agent depends on the Editor agent to have the

news of a specific category. For example, an Editor may be responsible for political

news, while another one may be responsible for sports news. Each Editor contacts one

or many Photographers-Reporters which can find the news of specific categories (e.g.,

about sport news). The Chief Editor then edits the Editor’ news and forwards them to

the Webmaster to publish them. One of the non-functional requirements of the e-News

system is the ability to ensure easier recovery if some agent in the system stops

running, i.e., system availability. This requirement is not shown in the case study

because we could not present the requirements models of the system, due to lack of

space. However, we highlight this requirement since it will be used to choose the

proper social pattern for the e-News system detailed design.

4.1 Agent Detailed Design

The architectural design of the e-News system is initially specified using the i*

technique and presented in [18]. To identify the information related to the agent


202

oriented notation (section 2.2), it is necessary to perform two activities depicted in

Fig. 4: Perform means-end analysis and Map i* to UML.

After concluding the Perform means-end analysis activity, we produce the SR

model expanding all the architectural actors of the system. Then, we can start to

perform the Map i* to UML activity, using the heuristics present in [19] to produce

the architectural, communication, intentional, environmental and action models. The

interested reader can find the use of these activities in [19]. In the next section we

present the architectural model produced for the e-News system.

4.1.1 Architectural model

We start by proposing an architectural solution for the e-News problem by performing

the Specify architectural model activity of the Detailed Design Process (Fig. 4).

Hence, the architectural design of the e-News system (Fig. 5) is performed by using

the MAS architectural pattern depicted in Fig. 1 to assign the system’s responsibilities

to the architectural components.

The e-News system is composed of four AgentRoles: Editor, Webmaster, Chief

Editor and Reporter. For example, in Fig. 5 the shaded area corresponds to the

interaction between the Chief Editor and Editor AgentRoles to achieve the service

Provide News of Specific Category. The Chief Editor AgentRole intends to achieve

the Newspaper Edited and Published Goal by means of the Edit and Publish

Newspaper MacroPlan. However, to edit the newspaper the Chief Editor AgentRole

has to request the Editor AgentRole to perform the Provide News of Specific Category

service. The Editor performs the requested service because it does not conflict with

the achievement of the News of Specific Category Edited Goal. Hence, both the

requested service and the goal achievement are accomplished by means of the Edit

News of Specific Category MacroPlan.

Due to lack of space, we cannot show the communication, intentional,

environmental and action models for the e-News System. The interested reader can

find these models in [21].

4.2 Social Pattern Selection and Application

The last step of the process is to select and apply social patterns to refine the

architectural design of the e-News system (Fig. 5). One of the key challenges is to

choose the proper social pattern to be applied to a system architectural design. One

can for example analyze the templates [20] that describe several features of each

social pattern to address a specific requirement. For example, the e-News System has

the Availability requirement, i.e., the system has to ensure easier recovery of the

system if some agent in the system stops running. This requirement could not be

shown in the case study because we did not present the requirements models of the e-

News System. The interested reader can find these requirements models in [21].

Analyzing the template of several patterns, we have concluded that the most

suitable pattern to address the Availability requirement is the Matchmaker, since it

enables the search for another agent to replace the one that has stopped. However, in

other situations, one can conclude that it would be better to use a combination of


203

patterns to address a requirement. Showing the template of the other social patterns

could help clarifying the justification of choosing the Matchmaker pattern to address

the Availability requirement.

Fig. 5. Architectural Model for e-News

In order to be able to apply a social pattern, we need to instantiate each model role

present in the structure of the pattern (e.g., |Client, |Locate Provider). For example, the

following bindings represent the instantiations of the model roles present in the

Matchmaker SAPS (Fig. 2) for the e-News system (shaded area of Fig. 5):

1. Bind |Client to Editor

2. Bind |Provider to Photographer-Reporter

3. Bind |Matchmaker to Chief Editor

4. Bind |Provider Identified to Photographer-Reporter Identified

5. Bind |Perform Service to Produce News Article of Specific Subject

6. Bind |Locate Provider to Locate Photographer-Reporter


204

7. Bind |Request Provider Identification to Request Photographer-Reporter

Identification

Fig. 6. Detailed Design of e-News Architecture

Instantiating the model roles of the pattern (Fig. 2) for the e-News model elements

(Fig. 5), we find the pattern applied to the problem (Fig. 6). Thus, we applied the

structure of the pattern to the architectural diagram of the e-News System through


205

model roles instantiation (the bindings shown above), which can be easily automated

by a CASE tool.

Observe that the Matchmaker pattern is refining the Editor, Chief Editor and

Photographer-Reporter AgentRoles by adding the pattern-specific concerns (ports,

connectors, dependums, goals and plans).

Thus, the Editor can search for Photographer-Reporter at run time; the

Photographer-Reporter can publish its services in the yellow pages service of the

Chief Editor; the Chief Editor can ensure decoupling among agents and, therefore,

easier system recovering if a Photographer-Reporter contacted by an Editor stops

running. In this case, the Editor may replace that Photographer-Reporter by locating

another one in the yellow pages of the Chief Editor. (Note that some

«ComplexAction» stereotypes have been omitted in Fig. 6 to save space).

In this work, we are not concerned with specifying the interaction between the e-

News system and the News Agency external system, because it will imply the use of

another social pattern called Wrapper [11], which will be illustrated in future work.

5 Related Work

Methodologies such as GAIA [25], Tropos and MaSE [2] have become the focus of

the emerging area of agent-oriented software engineering. In GAIA, the detailed

design phase is responsible for identifying the agent and services models which, in

turn, act as guidelines for the actual implementation of agents and their activities.

The purpose of the design phase in MaSE is to take roles and tasks and to convert

them into a form more amenable to implementation, namely agents and conversations.

The MaSE design phase consists of four steps: designing agent classes, developing

conversation, assembling agents and deploying the agents. Observe that all these

methodologies do not support the application of design patterns for detailing the MAS

architecture. Moreover, both GAIA and MaSE do not use a standard notation to

specify the artifacts produced during the design phase.

The approach presented in [11] proposes a framework to explore five different

complementary dimensions required to describe both social patterns and detailed

design models. These dimensions are social, intentional, structural, communicational

and dynamic. In this framework the UML’s class diagram was extended to support the

design of BDI (belief-desire-intention) agent architecture [15] and JACK [1]

implementation. Therefore, the work also supports generation of code from agent’s

specifications to JACK platform.

When we are talking about design, it is expected that the specification of MAS be

as detailed as possible to serve as a guide to direct implementation in any available

platform (not only JACK). The models produced in the detailed design phase of our

approach can be implemented in any FIPA compliant platform [4] which supports the

BDI agent model [15].

The process described in [22] uses the proposal of [11] both to describe social

patterns and specify MAS design. That process does not provide an explicit and

systematic way for selecting and applying the social patterns during MAS design.


206

Therefore, the patterns are applied in an ad hoc way and their choice is not clearly

justified. On the other hand, our process provides activities to help the selection of

social patterns to a specific MAS application and to systematically guide the

application of the chosen patterns.

6 Conclusion

This paper presents a process to perform detailed design of MAS using social patterns.

The process is described using SPEM and includes activities to map i* models to

UML-based diagrams. These diagrams capture five views of MAS: Architectural,

Communication, Intentional, Environmental and Action. It also includes activities to

select and apply social patterns to the architectural design to introduce additional

detail to the structure and behavior of each architectural component of MAS.

To describe the structure and behavior of social patterns, we have used the APS

(Agent Pattern Specification) technique [20], which has been obtained by specializing

the agency metamodel through model roles. A model role specifies properties that a

MAS model element must have if it is to be part of a pattern solution model. Since the

APS technique and the agent-oriented modeling notation are based on a standard

modeling language (UML), the social patterns could be easily used by several agent-

oriented methodologies, as well as the detailed design process can be supported by

any UML CASE tool.

Future work includes: (1) investigating if the intentional, environmental [19] and

dynamic diagrams [17] can be used to specify social patterns and, therefore,

complement the APS technique; (2) providing a complete catalogue of social patterns

described using this technique; (3) studying how social patterns can be modeled and

implemented using aspect-orientation [9] to handle crosscutting concerns; (4)

developing a tool to support both the process and the code generation; (5) applying

the approach to more case studies; and, finally, (6) handling conflicts which might

occur when different social patterns are applied to the same MAS design.

Acknowledgements

This work was supported by several research grants (CNPq Proc. 142248/2004-5 &

CAPES/GRICES Proc. 129/05).

References

1. AOS (Agent Oriented Software Group): JACK Intelligent Agents. Available:

http://www.agent-software.com/, Last access in March (2005)

2. DeLoach, S.: Engineering Organization-based Multiagent Systems. 4th Software

Engineering for Large-Scale Multi-Agent Systems (SELMAS’05), EUA (2006) 1 – 7


207

3. Ferber, J., Gutknecht, O.: Admission of agents in groups as a normative and organizational

problem. Workshop on Norms and Institutions in MAS, ACM press (2000)

4. FIPA: FIPA (The Foundation for Intelligent Physical Agents), Available:

http://www.fipa.org (2004)

5. France, F., Kim, D., Ghosh, S., Song, E.: A UML-Based Pattern Specification Technique.

IEEE Transactions on Software Engineering, 30, 3 (2004) 193 – 206

6. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable

Object-Oriented Software, Addison-Wesley (1995)

7. Giorgini, P., Kolp, M., Mylopoulos, J., Castro, J.: Tropos: A Requirements-Driven

Methodology for Agent-Oriented Software. Henderson-Sellers, B. et al. (eds.): Agent-

Oriented Methodologies. Idea Group (2005) 20 – 45

8. IEEE Computer Society: IEEE Recommended Practice for Architectural Description of

Software-Intensive Systems: IEEE Std 1471 (2000)

9. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J., Irwin, J.:

Aspect-Oriented Programming. 11th European Conference Object-Oriented Programming

(ECOOP’97). Springer-Verlag, Finland (1997)

10. Kim, D., France, R., Ghosh, S., Song, E.: Using Role-Based Modeling. Language (RBML)

as Precise Characterizations of Model Families. 8th IEEE International Conference on

Engineering of Complex Computer Systems (ICECCS’02), Greenbelt, MD (2002)

11. Kolp, M., Do, T., Faulkner, S., Hoang, H.: Introspecting Agent Oriented Design Patterns.

In: Advances in Software Eng. and Knowledge Eng., Vol. III, World Publishing (2005)

12. Mylopoulos, J., Kolp, M., Castro, J.: UML for agent-oriented software development: The

Tropos proposal. 4th Unified Modeling Language (UML’01), Toronto, Canada (2001)

13. OMG: Unified Modeling Language (UML): Superstructure. Version 2.0, Available:

www.omg.org/docs/formal/05-07-04.pdf (2005)

14. OMG: Software Process Engineering Metamodel (SPEM) Specification. Version 1.1,

Available: www.omg.org/docs/formal/05-01-06.pdf (2006)

15. Rao, A. S. and Georgeff, M. P.: BDI agents: from theory to practice. Technical Note 56,

Australian Artificial Intelligence Institute (1995)

16. Shaw, M. and Garlan, D.: Software Architecture: Perspectives on an Emerging Discipline.

Prentice Hall (1996)

17. Silva, V., Noya, R. , Lucena, C.: Using the UML 2.0 activity diagram to model agent plans

and actions. 4th AAMAS’05, The Netherlands (2005) 594 – 600

18. Silva, C., Castro, J., Alencar, F. and Ramos, R.: Extending UML to Support Both Agency

and Organizational Architectural Features. IX IDEAS, Argentina (2006)

19. Silva, C., Araújo, J., Moreira, A., Castro, J., Tedesco, P., Alencar, F., Ramos, R.: Modeling

Multi-Agent Systems using UML. 20th SBES, Florianópolis, Brazil (2006)

20. Silva, C., Araújo, J., Moreira, A., Castro, J.: Designing Social Patterns using Advanced

Separation of Concerns. In: 19th International Conference Advanced Information Systems

Engineering (CAiSE’07), 11-15 June 2007, Trondheim, Norway (to appear)

21. Silva, C.: Tropos Detailed Design. Technical Report, Available: cin.ufpe.br/~ctlls/TDD.pdf

22. Wautelet, Y., Kolp, M. and Achbany, Y.: S-Tropos - An Iterative SPEM-Centric Software

Project Management Process. Technical Report, Available at

http://www.isys.ucl.ac.be/staff/youssef/Articles/WP_SPEM.pdf (2005)

23. Whittle, J. and Araújo, J.: Scenario Modeling with Aspects. Rashid, A. et al. (eds.): IEE

Proceedings - Software, Special Issue on Early Aspects: Aspect-Oriented Requirements

Engineering and Architecture Design (2004).

24. Yu, E.: Modelling Strategic Relationships for Process Reengineering. Ph.D. thesis.

Department of Computer Science. University of Toronto, Canada (1995)

25. Zambonelli, F., Jennings, N., Wooldridge, M.: Developing Multiagent Systems: the Gaia

Methodology. ACM Transactions on Soft. Eng. and Methodology, 12, 3 (2003) 317 – 370


208

Aplicación de QVT al desarrollo de Almacenes de Datos Seguros: Un caso de estudio

Emilio Soler1, Juan Trujillo2, Eduardo Fernández -Medina3 y Mario Piattini3

(1) Departamento de Informática. Universidad de Matanzas (Cuba) Autopista de Varadero km 3. Matanzas. Cuba.

[email protected] (2) Departamento de Lenguajes y Sistemas Informáticos. Universidad de Alicante

C/ San Vicente S/N 03690 Alicante (España) [email protected]

(3) Grupo ALARCOS, Departamento de Tecnologías y Sistemas de Información Centro Mixto de Investigación y Desarrollo de Software UCLM -Soluziona

Universidad de Castilla-La Mancha Paseo de la Universidad, 4 – 13071 Ciudad Real, España

{eduardo.fdzmedina, mario.piattini}@uclm.es

Resumen . Los almacenes de datos (DWs) con frecuencia almacenan información histórica y agregada, extraída de múltiples, heterogéneas y distribuidas fuentes de información, por ello, la seguridad es un aspecto crucial para su desarrollo. El empleo del estándar Model Driven Architecture (MDA) en el modelado seguro de los DWs permite la obtención del esquema lógico a partir del modelo conceptual multidimensional. En este artículo , aplicamos el lenguaje Query/View/Transformation (QVT) al desarrollo de un DWs seguro mediante un caso de estudio. Primero, introducimos el caso de estudio relacionado con un sistema típico sanitario. Después, con la aplicación de un conjunto de relaciones QVT, transformamos todos los requisitos de seguridad y auditoria representados en el modelo conceptual multidimensional al nivel lógico, para ello nos basamos en la construcción de un esquema copos de nieve. De este esquema, resulta fácil la obtención de código para una plataforma específica que implemente aspectos de seguridad y auditoria.

Keywords: Relaciones QVT, seguridad de datos, MDA, modelado multidimensional seguro.

1 Introducción

El modelado multidimensional (MD) es la base de los Almacenes de Datos (Data Warehouses , DWs), las Bases de Datos MDs, y aplicaciones de Proces amiento Analítico En -Línea (On-Line Analytical Processing, OLAP). Estas aplicaciones de manera conjunta constituyen un mecanismo muy poderoso para descubrir información de negocio crucial en los procesos de toma de decisiones estratégicas.


209

Los DWs con frecuencia almacenan información histórica y agregada, extraída de múltiples, heterogéneas, autónomas y distribuidas fuentes de información, por ello, la supervivencia de las organizaciones depende de la correcta gestión, seguridad y confidencialidad de la información [1]. La información de seguridad es un requisito serio que debe ser considerado, no como un aspecto aislado, sino como algo presente en todas las etapas del ciclo de vida de desarrollo, desde el análisis de los requisitos hasta la implementación y mantenimiento [2]. Lo anterior justifica que es crucial especificar medidas de confidencialidad en el modelado MD y hacerlas cumplir.

El profile de UML presentado en [3] permite especificar los principales aspectos de seguridad en el modelado MD de los DWs. En [4] presentamos una extensión del metamodelo relacional del Common Warehouse Metam odel (CWM) que permite especificar a nivel lógico todas las medidas de seguridad y auditoria consideradas en el modelado conceptual del DW. Estas dos propuestas se integran bajo la arquitectura Model Driven Architecture (MDA) en [5], para establecer un PIM (Platform Independent Model) y un PSM (Platform Specific Model) seguro, así como un conjunto de relaciones Query/View/Transformations (QVT) para el modelado de DWs seguros. De esta manera proponemos una solución al denominado hueco semántico existente entre modelos conceptuales avanzados e implementaciones relacionales o multidimensionales de cubos de datos [6].

En este trabajo aplicamos un conjunto de relaciones QVT al desarrollo de un DW seguro. El caso de estudio presentado está relacionado con un sistema típico sanitario. El modelo conceptual multidimensional considerado es transformado en un esquema lógico relacional y a partir de este explicamos como obtener código para una plataforma destino. Para ello utilizamos un PIM Multidimensional Seguro (Secure Multidimensional PIM, SMD PIM) y un PSM Multidimensional Seguro (Secure Multidimensional PSM, SMD PSM) así como las relaciones definidas en [5].

Fig. 1. Esquema general de la transformación

En la Figura 1 ilustramos la arquitectura MDA Multidimensional Segura propuesta en [5]. A la izquierda aparece el Secure Multidimensional (SMD) esquema conceptual, es decir, el SMD PIM. Mediante la transformación T1 obtenemos el esquema relacional lógico, es decir, el SMD PSM, representado en el centro de la Figura 1. Si elegimos un SGBD que implemente aspectos de seguridad, entonces el SMD PSM se transforma según T2 en código para la plataforma destino. Este código lo llamamos Código Multidimensional Seguro (Secure Multidimensional Code, SMD

SecurityRole SecurityRole

SFact

SDimension1

SBase1

SBase2 SBase3

SDimension2

Table

Table Table

Table

Table T1 T2

SMD PIM SMD PSM SMD CODE

Create Table Add Constraint Apply_Table_Policy


210

Code). Obsérvese cómo la restricción de seguridad, es decir, la securityRule (representada mediante una nota de UML) es transformada del nivel conceptual al nivel lógico mediante T1, y más tarde transformada en código mediante la transformación T2.

El resto de este artículo se estructura como sigue. La sección 2 comienza introduciendo el caso de estudio relacionado con un sistema sanitario. Le sigue una explicación del modelado conceptual multidimensional para introducir el PIM y termina esta sección aplicando las transformaciones QVT para obtener el PSM. Finalmente la sección 3 presenta las principales conclusiones y el trabajo futuro inmediato.

2 Caso de estudio

En esta sección, aplicamos las transformaciones QVT al desarrollo de un DW seguro relacionado con un sistema típico sanitario. Hemos omitido algunos detalles para hacer más comprensible el caso de estudio. El ejemplo es una versión ampliada de [4]. Después de considerar el modelo multidimensional que representa nuestro PIM, definimos relaciones QVT para construir un PSM relacional que constituye un esquema snowflake1 a nivel lógico. Este PSM relacional representa una instancia del metamodelo relacional extendido de CWM que aparece en [5].

Un hospital desea automatizar los ingresos de los pacientes así como guardar millones de registros de complejos tratamientos realizados a pacientes. La información que manipula un sistema sanitario requiere confidencialidad, de ahí que resulta interesante construir un DW que contemple de manera exacta requisitos de seguridad. La clase Admission guarda información acerca de de los pacientes que ingresan a uno o más hospitales. Para almacenar los datos del paciente y de su diagnóstico son necesarias las clases, Diagnosis , Patient , Time, Diagnosis _Group y City. La clase UserProfile contiene información de todos los usuarios que tendrán acceso al sistema (ver Figura 2).

Hemos usado los siguientes niveles de seguridad: confidential, secret y topSecret, así como los roles de usuarios Health (incluyendo los subroles Doctor y Nurse) y nonHealth (incluyendo los subroles Mantenimiento y Administrativo). La raíz de esta jerarquía de roles es EmpleadoHospital. En este ejemplo no hemos considerado categorías de usuario.

2.2 Modelado conceptual multidimensional

La Figura 2 muestra un modelo MD seguro que incluye una clase de hecho (Admission), tres dimens iones (Diagnosis, Patient y Time), cinco clases base (DataD , Diagnosis _Group, DataP, City, y DataT), y una clase (UserProfile). La clase de

1 Para detalles sobre este modelo el lector puede consultar la referencia [9].


211

hecho Admisión – estereotipo SFact- contiene todas las admisiones individuales de pacientes en uno o más hospitales, y puede ser accedido por todos los usuarios que tienen niveles de seguridad secret o topSecret -valor etiquetado SecurityLevels (SL) de las clases-, y desempeñan roles de health o administrative -valor etiquetado SecurityRoles (SR) de las clases-. Obsérvese cómo el atributo cost puede ser sólo accedido por usuarios que desempeñan el rol de administrativo –valor etiquetado SR de los atributos - La clase base DataP contiene la información de los pacientes del hospital y puede ser accedido por todos los usuarios que tienen nivel de seguridad secreto –valor etiquetado SL-, y desempeñan roles de health o administrative –valor etiquetado SR -.

Fig. 2. Ejemplo de modelado multidimensional seguro

El atributo Address puede ser accedido sólo por usuarios que desempeñan el rol de adm inistrativo –valor etiquetado SR de los atributos-. La clase base City contiene la info rmación de las ciudades, y permite agrupar a grupos de pacientes por ciudades. Las ciudades pueden ser accedidas por todos los usuarios que tienen nivel de seguridad confidential –valor etiquetado SL-. La clase base DataD contiene la

DataD {SL= S; RS= Health}SOID codeDiagnosisSD descriptionSDA healthAreaSDA validFromSDA validTo

Diagnosis_Group {SL= C}SOID codeSD description

City {SL= C}SOIDcodeSD nameSDA population

1..*

1

1..*

1

<<Rolls-upTo>>

DataP {SL= S; RS= Health, Admin}

SOID ssnSD nameSDA dateOfBirthSDA address {RS= Admin}

1..*1

1..*1

DiagnosisPatient

Admission {SL= S..TS; RS= Health, Admin}

SFA typeSFA cost {SR= Admin}

1

0..*

1

0..* 0..*1

0..*1

Time

0..*

1

0..*

1

DataT {SL= S; RS= Health, Admin}

SOID, SD dateSDA dayOfYearSDA vacationSDA big_event

<<SecurityRule>> 1 {InvolvedClasses= (Diagnosis, DataD, Diagnosis_group&Patient)} {self.SL= (If self. Diagnosis.DataD.Diagnosis_group.description="cancer" or self.Diagnosis.DataD.Diagnosis_group.description="AIDS" then TS else S)

userProfile

userCodesecurityLevelcitizenshiphospitalworkingAreadateContract

<<AuditRule>> 2 {logType= frustatedAttents} {self.type= 'primary_diagnosis'}

<<AuthorizationRule>> 4 {exceptSign= +} {self.name= userProfile.name}

<<SecurityRule>> 3 { InvolvedClasses= (Patient)} self.SL= (If.self.cost>10000 then TS else S)


212

información de cada diagnóstico, y puede ser accedida por los usuarios que desempeñan un rol de health –valor etiquetado SR-, y tienen nivel de seguridad secreto –valor etiquetado SL-. Finalmente, Diagnosis_Group contiene un conjunto de grupos generales de diagnóstico. Cada grupo puede estar relacionado con varios diagnósticos, pero un diagnóstico siempre estará relacionado a un solo grupo. Los grupos de diagnóstico pueden ser accedidos por todos los usuarios que tienen nivel de seguridad confidential –valor etiquetado SL-. Se han especificado varias restricciones de seguridad utilizando las restricciones, estereotipos y valores etiquetados definidos previamente:

1. El nivel de seguridad de cada instancia de Admission es definido por una restricción de seguridad especificada en el modelo. Si el valor del atributo SDescription de Diagnosis_group a la cual pertenece el diagnóstico que está relacionado a la Admission es cáncer o SIDA, el nivel de seguridad –valor etiquetado SL- de esta adm isión será topSecret , en caso contrario será secret. Esta restricción es sólo aplicada si el usuario hace una consulta cuya información viene de cualquier clase base de la dimensión Diagnosis, unida con la clase base DataP –valor etiquetado involvedClasses -. De esta manera, un usuario que tiene un nivel de seguridad secreto podría obtener el número de pacientes con cáncer por cada ciudad, pero nunca si la información de la base DataP aparece en la consulta.

2. El valor etiquetado logType ha sido definido para la clase Admission, especificando el valor frustratedAttempts . Este valor etiquetado especifica que el sistema tiene que registrar, para una auditoria futura, la situación en la cual un usuario trata de acceder a información cuyo tipo es ‘primary_diagnosis’ de esta clase de hecho, y el sistema lo rechaza debido a la carencia de los permisos necesarios.

3. El nivel de seguridad –valor etiquetado SL- de cada instancia de Admission puede también depender del valor del atributo cost, que indica el precio del servicio de admisión. En este caso, la restricción es sólo aplicable para consultas que contienen información de la clase base DataP –valor etiquetado involvedClasses-.

4. Los pacientes podrían ser usuarios especiales del sistema. En este caso, debería ser posible que los pacientes accedan a su propia información como pacientes (por ejemplo, consultando sus datos personales). Esta restricción es especificada usando el valor etiquetado exceptSign en la clase base DataP.

El privilegio considerado en estas excepciones es read , pero no la hemos especificado en el modelo ya que es el valor por defecto del valor etiquetado exceptPrivilege.

En la Figura 2 hemos representado una instancia del PIM que hemos llamado Secure Multidimensional PIM (SMD PIM) [5] . En este modelo la clas e Admission representa una SFact, mientras que Diagnosis , Patient y Time representan SDimensions. En este ejemplo no consideramos SDegenerateFact. Diagnosis _Group y City representan SBases. La SFact Admission, las SDimensions y las SBases heredan requisitos de seguridad, por ello, permiten modelar mediante notas de UML [7] a las clases AuditRule, AuthorizationRule y SecurityRule, para establecer de este modo reglas de seguridad en el modelo multidimensional. A nivel de atributo la seguridad se establece mediante las clases SFactAttribute, SOID, SDescriptor y SDimensionAttribute. La clase llamada UserProfile contendrá información de todos los usuarios con derecho de acceso al modelo multidimensional.


213

2.3 Relaciones QVT para obtener el PSM

Un modelo específico de plataforma es una vista de un sistema desde el punto de vista de la plataforma. Un PSM combina la especificación del PIM con los detalles que especifican cómo el sistema usa un determinado tipo de plataforma [8]. En el diseño de bases de datos y almacenes de datos, el modelado conceptual da lugar al PIM, y el modelado lógico al PSM. Existen varias propuestas para representar los modelos multidimensionales a nivel lógico, todas ellas dependen de las propiedades del SGBD (Relational Online Analytical Processing, ROLAP, multidimensional online analytical processing , MOLAP o Hybrid Online Analytical Processing, HOLAP). Aunque Kimball [9] asegura que la representación más común es sobre plataformas relacionales, es decir, sobre sistemas ROLAP.

El SMD PSM permite representar a nivel relacional los requisitos de seguridad que fueron representados en el modelado conceptual del DW. En este modelo podemos representar tablas, columnas, claves primarias y ajenas, etc. De este modo podemos establecer seguridad en atributos y tablas. Mediante notas de UML [7] expresamos las restricciones de seguridad que fueron modeladas a nivel conceptual.

Fig. 3. Transformación SMD PIM a SMD PSM

La transformación principal contiene relaciones del tipo top-level. En cada relación mediante las cláusulas when y where se especifican pre y post -condiciones que debe satisfacer la relación. En la Figura 3 hemos representado la transformación principal. La primera relación en ejecutarse es SecureDW2SSchema , con ella, todos niveles de seguridad: confidencial, secret y topsecret, así como toda la jerarquía de roles son transformados en sus equivalentes de SSchema. La relación UserProfile2RUserProfile, transforma la clase UserProfile en una tabla perteneciente a SSchema que tendrá el mismo nombre de UserProfile. La relación que sigue, es decir, SFact2STable es mostrada en su notación gráfica en la Figura 4, mediante esta

Transformation SMD To SREL(SMD: SECDW,) SREL: SECRDW) { key Table{name, Schema}; key Column {name, owner}; key UserProfile{name, Schema}; key PrimaryKey{name, owner}; key ForeingKey{name, owner}; key SecurityProperty{name, owner}; ke y SecurityConstraint(name, owner); top relation SecureDW2S Schema{} top relation UserProfile2RUserProfile{} top relation SFact2Table {} top relation SDegenerateFact2STable{} top relation SDimension2STable{}

//Association SFact with SDimension top relation AssocSF_SD2FKey{} //Association SDegener ateFact with SDimension top relation Assoc SDF_SD2FKey // Association SDegenerateFact with SFact top relation AssocSDF_SF2FKey{} }


214

relación cada SFact conjuntamente con sus propiedades de seguridad es transformada en una tabla que contendrá la misma información de seguridad.

Fig. 4. Transform ando SFacts en STables

La cláusula where invoca a las relaciones que deben ser ejecutadas. En la Figura 5, vamos a mostrar cómo se transforman los atributos de SFact en SColumnas de la tabla que representa a la SFact, de modo que, cada columna contendrá la información de seguridad de su correspondiente atributo en la SFact

Fig. 5. Transform ando SAttributes en SColumns

En la Figura 6 mostramos el resultado de aplicar la relación SFact2STable a nuestro caso de estudio. La SFact Admission es transformada en una tabla del modelo SMD PSM, es decir, en la tabla Admission, que tendrá una clave primaria, así como las propiedades de seguridad secur ityLevel y securityRole .

La Figura 7 muestra el resultado de aplicar la relación SFactAttribute2SColumn, como consecuencia, la tabla Admission contendrá las columnas type y cost de tipo string y float respectivamente. La columna cost tendrá asociado la propiedad de seguridad securityRole. En la propia Figura 7, los requisitos de seguridad asociados a

<<domain>>

C E

SMD SREL <<domain>>

SFact2STable

SL= f_sl Pk: PrimaryKey name=n_pk

SC= f _sc

t: STable

name= n_f

SR= f_sr

sdw: SecureDW

When

Where SecureDW2 SSchema (sdw,ss) ;

SFactAttribute2SColumn (f, t) ;

SFactConstraint2SecurityConstraint (f, t) ; SDegenerateDimension2SColumn (f, t) ;

n_c= 'ID'+'_' + n_f; n_pk= 'pk' + '_' + n_f;

ss: SSchema

f: SFact

name= n_f SL_SF= f_sl SR_SF= f_sr SC_SF=f_sc

c: SColumn name=n_c type= 'INTEGER'

<<domain>>

C E

SMD SREL

<<domain>> SFactAttribute2SColumn

SL= a_sl SC= a_sc SR= a_sr

Where

name= n_sfa type= t_sfa SL_SFA= a_sl SR_SFA= a_sr SC_SFA= a_sc

sfa: SFactAttribute c: SColumn name=n_sfa type= SRelType

SRelType= SMDType2SRelType ( t_sfa);

t: STable f: SFact


215

la tabla Admission son modelados en el encabezamiento de la tabla, tal y como lo garantiza el metamodelo SECRDW [4].

Fig. 6. Aplicando SFact2STable

Fig. 7. Aplicando SFact Attribute2 SColumn

Continuando con las relaciones que aparecen en la cláusula where de SFact2STable, corresponde ahora aplicar la relación SDegenerateDimension2SColumn , en nuestro caso no se presenta pues no tenemos relaciones many-to-many entre la SFact Admission y las SDimensions .

La Figura 8 presenta la definición de la relación SFactCon straint2SecurityConstraint, la cual garantiza que todas los constraints asociados a la SFact se transforman en constraints asociados a la tabla, tal y como puede verse en la Figura 9. El metamodelo SECRDW [4] , garantiza que estos constraints se modelan a nivel lógico mediante notas asociadas a la tabla.

type: SColumn SFA Type: string SFA cost: currency

Admission SL= {S..TS} SR= {Health, Admin}

<<STable>> Admission SL= {S..TS} SR= {Health, Admin}

PK ID_Admission: Number

SFactAttribute2SColumn cost: SColumn

string: SQLDataType

float: SQLDataType

SR= {Admin}

Hospital: SSchema

ID_Admission: SColumn

PK_Admission: PrimaryKey

Hospital

Admission: STable

SR= {Health, Admin} SL= {S..TS}

SFA Type: string SFA cost: currency


Number: SQLSimpleType Column

SFact2STable


216

Fig. 8. SFactConstraint2SecurityConstraint

Fig. 9. Aplicando SFactConstraint2SecurityConstraint

Continuando con la transformación principal que aparece en la Figura 3,

corresponde la aplicación de la relación SDegeneratefact2STable, la cual no se presenta pues todas las relaciones entre la SFact Admission y las SDimensions son del tipo many-to-many. En la Figura 10 presentamos la definición de la relación SDimension2STable.

SFactConstraint2SecurityConstraint

<<domain>>

C E

SMD SREL

<<domain>>

s_OCLar= 'r_OCLar'; s_OCLau= 'r_OCLau'; s_OCLsr= 'r_OCLsr' ;…

auc: AuditConstraint

t: STable

aur : AURConstraint

ar: ARConstraint

name= r_sr involvedTables= s_icsr OCLConstraint= s_OCLsr

ar: AuditRule

au: AuthorizationRule

f: SFact

sr: SecurityRule

name= r_sr involvedClasses= r_icsr OCLConstraint = r_OCLsr

Where

SFA Type: string SFA cost: currency


<<STable>> Admission SL= {S..TS} SR= {Health, Admin}

PK ID_Admission: Number type: string cost: float SR= {Admin}

AudR 2

SecR 3

SecR 1 AudConst 2

ARConst 1

ARConst 3

SFa

ctC

onst

rain

t2S

ecur

ityC

onst

r


217

Fig. 10. Transformando SDimension en STable

En el modelado multidimensional las dimensiones no tienen atributos [10] , por ello, la relación SDimension2STable cuando es ejecutada crea una tabla cuyo nombre es la concatenación del nombre de la dimensión con el nombre de la rootBase, es decir, la única SBase asociada a la SDimension. Toda la información de seguridad que tiene asociada la rootBase se transforma en propiedades de seguridad de la tabla y mediante la ejecución de las relaciones que aparecen en la cláusula where de la relación SDimension2STable, se garantiza que todos los atributos de rootBase van a conformar las columnas de la tabla.

En la Figura 11 se ilustra la aplicación de la relación SDimension2STable, como resultado de aplicar esta relación se crea la tabla Patient_DataP , con todas las propiedades de seguridad que tiene asociada la rootBase, en este caso, el nivel de seguridad será secret y los roles de usuarios health y admin.

Varias de las relaciones que aparecen en la cláusula where de la relación SDimension2STable guardan cierta similitud con las definidas para la relación SFact2STable, por ello, a continuación vamos a definir la relación SBase2STable.

En la Figura 12 mostramos la definición de la relación SBase2STable . Esta relación crea una tabla con clave primaria, así como una clave ajena en la tabla que recibe como parámetro cuando es invocada, lógicamente la clave primaria y la clave ajena estarán asociadas para garantizar que las tablas forman parte de una relación one-to-many entre las SBases. En la cláusula where aparece un llamado a esta relación nuevamente, así como a SpecializedSBase2STable para asegurarnos que recorremos toda la jerarquía de bases que conforman la dimensión.

C

SMD SREL <<domain>>

SDimension2STable

sdw: SecureDW

Wher e SecureDW2 SSchema (sdw,ss) ;

srb: SRootBase

name= n_srb SL_SF= rsb_sl SR_SF= rsb_sr SC_SF= rsb_sc

Pk: name=n_pk

SC=

<<domain>>

t: STable

name= n_st

ss: SSchema

c: SColumn name= n_c type= 'INTEGER'

E

SL= rsb_sl

When

n_c= 'ID'+'_' + n_sd; n_pk= 'pk' + '_' + n_st; n_st= n_sd +'_'+ n_srb

SRootBaseConstraint2SecurityConstraint ( srb, t) ; SBase2STable ( srb, t);

sd: SDimension name= n_sd

SDimensionAttribute2SColumn (srb, t) ;

SOID2SColumn (srb, t) ; SDescriptor2SColumn ( srb, t) ;

SpecializedSBase2Table (srb, t) ;

SR=


218

Fig. 11. Aplicando SDimension2 STable

Fig. 12. Transformando SBase en STable

En la Figura 13 ilustramos la aplicación de la relación SBase2STable a nuestro caso de estudio. Cuando la relación es ejecutada se crea la tabla City con la clave primaria PK_City. Esta clave primaria estará asociada con la clave ajena que también es creada en la STable Patient_Data. La tabla City tendrá asociada la propiedad de

SBase2STable

C

SMD SREL

<<domain>> b1: SBase

SDescriptor2SColumn ( b2, t 2);

b2: SBase

name= n_sb SL_SF= sb_sl SR_SF= sb_sr SC_SF= sb_sc

Pk: PrimaryKey name=n_pk

SC= sb_sc

<<domain>>

t2: STable

name= n_sb c: SColumn name= n_c type= 'INTEGER'

E

SL= sb_sl

SDimensionAttribute2SColumn ( b2, t2); SOID2SColumn (b2, t 2);

n_c= 'ID'+'_' + n_sb; n_pk= 'pk' + '_' + n_sb; fn_c= 'REF_' + n_c

SBase2STable ( b2, t 2) ;

SR= sb_sr

SpecializedSBase2Table ( b2, t2);

SBaseC onstraint2SecurityConstraint ( b2, t 2);

t1: STable c: SColumn name= fn_c type= 'INTEGER' c: FKey

name= n_p k

Wher e

Hospital: SSchema

ID_Patient: SColumn

PK_Patient: PrimaryKey

Patient_DataP: STable

SR= {Health, Admin}

SL= {S}

Num ber: SQLSimpleType

SDimension2STable

SOID ssn: string SD name: string SDA dateOfBirth: date SDA address: string

DataP SL= {S} SR= {Health, Admin}

Patient

Hospital


219

seguridad definida mediante securityLevel con valor confidencial. El resultado final es que las tablas City y Patient_DataP quedan relacionadas.

Fig. 13. Aplicando SBase2STable

Las primeras cuatro relaciones que aparecen en la cláusula where de la relación SBase2STable garantizan la transformación de todos los atributos de la SBase en columnas de la tabla que representa a la SBase, así como la transformación de todos los constraints asociados a la SBase en constraints asociados a la tabla que representa a la SBase. Los llamados a las relaciones SBase2STable y SpecializedBase2STable permiten hacer recursividad para recorrer toda la jerarquía de bases que conforman la dimensión. La relación SpecializedBase2STable tiene cierta similitud con la relación SBase2STable, por esa razón no la vamos a definir.

Fig. 14. Esquema copos de nieve representando una instancia del SMD PSM

Para completar el caso de estudio sólo nos resta aplicar las relaciones AssocSF_SD2FKey, AssocSDF_SD2FKey y AssocSDF_SF2FKey , que permiten

<<STable>> Admission

SL= {S..TS} SR= {Health, Admin}

PK ID_Admission: Number type: string cost: float SR= {Admin}

<<STable>> Time_DataT

SL= {S} SR= {Health, Admin}

<<STable>> Patient_DataP

SL= {S} SR= {Health, Admin}

<<STable>> City SL= {C}

<<STable>> Diagnosis_DataD SL= {S} SR= {Health, Admin}

<<STable>> Diagnosis_group SL= {C}

AudConst 2 ARConst 1

ARConst 3

AURConst 4

PK_City: PrimaryKey

City: STable

Patient_DataP: STable

SBase2STable

SOID code: string SD name: string SDA population: currency

City SL= {C}

Patient

ID_City: SColumn

Number: SQLSimpleType

PK_City: ForeingKey

DataP: STable

SL= {C}

'REF'_'ID_City' : SColumn


220

establecer relaciones entre SFact y las SDimensions, entre las SDegenerateFact y las SDimensions y entre las SFact y las SDegenerateFact. En nuestro caso sólo procede establecer relaciones entre la SFact Admission y las SDimensions, pues no tenemos SDegenerateFact. Como consecuencia de aplicar la relación AssocSF_SD2FKey resulta que en la tabla Admission se crean tres claves ajenas que permiten relacionar a la tabla Admission con las tablas Diagnosis _DataD, Patient_DataP y Time_DataT.

En la Figura 14 hemos omitido los atributos en algunas tablas, así como las claves primarias y ajenas para hacer que el esquema snowflake sea más comprensible. Obsérvese cómo las restricciones de seguridad han sido modeladas a nivel lógico.

El DBMS Oracle 9i permite implementar bases de datos multiniveles y tiene además un componente llamado Oracle Label Security (OLS) [11] , que permite establecer seguridad mediante predicados y funciones etiquetadas. Para ilustrar las posibilidades de OLS vamos a centrarnos únicamente en el ARConstraint etiquetado con el número 3 en la Figura 14. En la T abla 1 (1) muestra cómo mediante la creación de una función y el uso de etiquetas de seguridad podemos definir lo siguiente: Si el valor de la columna Cost es mayor que 10000 entonces la etiqueta de seguridad estará compuesta por el nivel de seguridad topSecret y por los roles usuarios Health y Admin, en caso contrario, la etiqueta de seguridad estará compuesta por el nivel de seguridad Secret y los mismos roles de usuarios. La Tabla 1 (2) muestra có mo enlazar esta función etiquetada con la tabla Admission.

Tabla 1. Ejemplo de implementación de aspectos de seguridad en OSL


En este artículo hemos aplicado un conjunto de relaciones QVT al desarrollo de un DW seguro. El caso de estudio desarrol lado constituye una aplicación de la arquitectura MDA Multidimensional Segura, en la que definimos un PIM y un PSM seguro así como la correspondiente transformación mediante el estándar QVT. El caso de estudio desarrollado pone de manifiesto que la arquitectura MDA puede ser aplicada al modelado seguro de los DWs, ya que esta permite obtener el modelo lógico del DW para una plataforma relacional a partir del modelo conceptual. Si utilizamos un DBMS como Oracle9i, entonces muchas de las propiedades de seguridad y auditoria modeladas en el esquema snowflake a nivel lógico, pueden ser transformadas en código, con ello evidenciamos que es posible automatizar todo el

(1) CREATE FUNCTION Which_Cost (Cost: Integer) Return LBACSYS.LABC_LABEL

As MyLabel varchar2(80) Begin If Cost > 10000 then MyLabel:= ‘ TS::Health, Admin’; else

MyLabel:= ‘ S::Health, Admin’; end if; Return TO_LBAC_DATA_LABEL(‘MyPolicy’, MyLabel); End; (2) APPLY_TABLE_POLICY (‘MyPolicy’, ‘Admission’,

‘Scheme’, , ‘Which_Cost’)


221

proceso de diseño de un DW seguro, lo que resulta un ahorro de tiempo para los desarrolladores .

Nuestro trabajo futuro consiste en estudiar la posibilidad de implementar las relaciones QVT utilizando la capacidad que ofrecen algunas plataformas.

Agradecimientos

Este proyecto ha sido parcialmente financiado por los proyectos METASIGN (TIN2004 -00779) del Ministerio Español de Educación y las Ciencias, DADASMECA (GV05/220) del gobierno regional de Valencia, DIMENSIONS (PBC-05-012-1), DADS (PBC-05-012-2) FEDER y por la Consejería de Ciencia y Tecnología de la Junta de Comunidades de Castilla-La Mancha.

Re ferencias

1. G. Dhillon and J. Backhouse, "Information Systems Security Management in the New Millenium.," Communications of the ACM , vol. 43 (7), 2000.

2. P. Devanbu and S. Stubblebine, "Software Engineering for Security: a Roadmap," presentado en The Future of Software Engineering, Limerick, Ireland, 2000.

3. R. Villarroel, E. Fernández-Medina, and M. Piattini, "A UML 2.0/OCL Extension for Designing Secure Data Warehouses," Journal of Research and Practice in Information Technology, vol. 38, 2006.

4. E. Soler, R. Villarroel, J. Trujillo, E. Fernández-Medina, and M. Piattini, "Representing Security and Audit Rules for Data Warehouses at the Logical Level by using the Common Warehouse Metamodel," ARES'06, Vienna, Austria, 2006.

5. E. Soler, J. Trujillo, E. Fernández-Medina, and M. Piattini, "Un Conjunto de Transformaciones QVT para el Modelado De Almacenes de Datos Seguros," DSDM'06. Desarrollado en el marco de las XI Jornadas de Ingeniería del Software y Bases de Datos, Sitges, España, 2006.

6. J. Hammer, M. Schneider, and T. Sellis, "Data Warehousing at the Crossroads," presentado en The Dagstuhl Perspectives Workshop, Dagsthul. Germany, 2004.

7. G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language: User Guide.: Addison-Wesley, 1999.

8. J. Miller and J. Mukerji, "MDA Guide Version 1.0.1," 2003. 9. R. Kimball and M. Ross, The Data Warehousing Toolkit, 2 edition ed: John Wiley, 2002. 10. S. Luján-Mora, J. Trujillo, and I.-Y. Song, "A UML profile for multidimensional modeling

in data warehouses," Data & Knowledge Engineering (DKE) , vol. 59, pp. 725–769, 2006. 11. J. Levinger, " Oracle Label Security. Administrator's guide. Release 2.0 (9,.2)," 2002.


222

Sesión 7 MDA y Transformación de Modelos

223

Marco de Referencia para la Evaluación de Herramientas Basadas en MDA

Juan Bernardo Quintero1 y Raquel Anaya de Páez1

1 Grupo de Investigación en Ingeniería de Software, Universidad EAFIT. Medellín, Colombia

{jquinte1, ranaya}@eafit.edu.co

Resumen. La Arquitectura Dirigida por Modelos o MDA, es una propuesta reciente de OMG que muestra un proceso de desarrollo basado en la realización y transformación de modelos, en donde las herramientas de apoyo juegan un papel fundamental. En este trabajo se definen los mecanismos, referentes y estrategias para evaluar herramientas basadas en MDA. Este marco de referencia estudia diez herramientas, implementando en cada una el estudio de un caso y clasificándolas en cinco categorías así: OptimalJ y AndroMDA en la categoría de despliegue de aplicaciones, UMT y ATL en la categoría de transformación, Enterprise Architect y Jdeveloper en la categoría de clásicas de modelado y desarrollo, OCLE y Octopus en la categoría de entornos de verificación de modelos, y EMF y Jamda en la categoría de apoyo al desarrollo de herramientas. Este trabajo compila y extiende trabajos anteriores, de tal manera que sirva como referente a la comunidad de desarrolladores.

Palabras claves: Arquitectura Dirigida por Modelos (MDA), Lenguaje de Modelado Unificado (UML), Lenguaje de Restricciones Objetuales (OCL), Transformación, Herramientas de Transformación.

1 Introducción

El desarrollo de software puede verse como un proceso de evolución de conceptos cercanos al espacio del problema para progresivamente definir mecanismos y elementos cercanos al espacio de la solución, pasando por etapas (análisis, diseño, programación, etc.) que permiten gestionar el avance del proceso.

Dada la complejidad del desarrollo de una solución software, se hacen necesarias estrategias para alcanzar beneficios fundamentales como son la productividad, la interoperabilidad, la portabilidad y la facilidad de mantenimiento, es por esto que propuestas como la de MDA se fundamentan en principios básicos como los expuestos en el manifiesto MDA [1] planteado por IBM: (a) representación directa para enfocarse en el dominio del problema mas que en la tecnología, (b) automatización de las tareas mecánicas que no requieren intervención humana y (c) estándares abiertos que posibiliten la interoperabilidad de las herramientas y plataformas. Estos tres elementos evidencian la importancia que tienen las herramientas en el proceso de desarrollo basado en MDA, para posibilitar la


225

construcción de modelos, apoyar su transformación y permitir la interdisciplinariedad de los participantes, a través de la integración de las diversas plataformas y herramientas que estos utilizan.

Los planteamientos dados por el enfoque MDA, han motivado una evolución permanente en los constructores de herramientas CASE (Computer Aided Software Engineering). Aunque existe un buen número de herramientas CASE para el modelado de aplicaciones con UML [2], estas herramientas no dan un amplio soporte al refinamiento de modelos, lo cual dificulta la evolución consistente de una solución software en las diferentes fases del proceso de desarrollo.

El objetivo de este artículo es definir un marco de referencia para la evaluación de herramientas de transformación basadas en MDA, para tal propósito se organizó de la siguiente manera: primero se presenta el proceso de transformación de modelos en el capítulo 2, luego en el capítulo 3 definiremos el marco de referencia como tal, para ponerlo en práctica en el ejercicio de comparación de herramientas del capítulo 4, y finalmente mostrar las conclusiones y trabajos futuros en el capítulo 5.

2 Transformación de Modelos

Los modelos resultantes del trabajo realizado en cada una de las etapas de un proceso de desarrollo de software, son artefactos de suma importancia para MDA.

Espacio del problema

Espacio de la solución

Problema

CIM

PIM

PSM

Código

Solución

Procesos de transformación, en lo posible apoyados con herramientas.

Figura 1. La transformación en el proceso basado en MDA.

Los principales modelos planteados en MDA son: el modelo independiente de la computación (CIM: Computationally-Independent Model), el modelo independiente de la plataforma o (PIM: Platform-Independent Model) y el modelo específico de la plataforma (PSM: Platform-Specific Model). La figura 1 ilustra la forma como MDA propone transformar los modelos para partir de un problema, y llegar a una solución.

El proceso de transformación de modelos es un tema que ha sido ampliamente estudiado [3] y que cobra relevancia bajo el enfoque de MDA [4]. Desde la perspectiva de MDA, la transformación de modelos se sustenta en la definición de las reglas para convertir un modelo de un nivel de abstracción a otro basándose en


226

lenguajes y mecanismos estándares, con el propósito de lograr una solución genérica al anhelado sueño de “programar modelos”.

2.1 Propuestas Existentes en Transformación de Modelos

Debido al apogeo de MDA, en la actualidad nos encontramos con numerosos frameworks, herramientas, lenguajes y estándares alrededor del tema; para la realización de este marco de referencia se exploró un amplio espectro de propuestas en transformación de modelos. A continuación presentaremos las propuestas que por su difusión han alcanzado relevancia, y que no son objeto de estudio directo de esta investigación. • QVT: (Query/View/Transformations) estándar propuesto por la OMG y basado

en MOF (Meta Object Facility) para lenguajes de transformación en MDA [5]. • JMI: (Java Metadata Interface) framework basado en MOF, para permitir la

carga, manipulación y serialización de ficheros XMI (XML Metadata Interchange) y posibilitar el intercambio de modelos UML [6].

• UML Action Semantics: incluye los lenguajes de acción (AL), para la especificación de acciones sobre diagramas de estado y operaciones sobre diagramas de clases [7].

• GMT: (Generative Modeling Tools) proyecto de Eclipse Foundation acerca del desarrollo de software dirigido por modelos (MDSD: Model Driven Software Development). Entre el grupo de subproyectos que incluye, se encuentran ATL, VIATRA2 y UMLX.

• xUML: (eXecutable UML) subconjunto de UML que incorpora un AL, para construir modelos de dominio ejecutables [8], se basa en la formula: xMUL=UML-“Debilidad Semántica”+AL. En este ámbito se encuentra además UMLX, sintaxis gráfica que complementa QVT [9].

• VIATRA: (VIsual Automated model TRAnsformations) ambiente de validación y verificación basado en transformación de modelos soportado por la herramienta VIATRA2 [10].

• GReAT: (Graph Rewriting and Transformations) enfoque de transformación por grafos con un conjunto de herramientas diseñadas para la rápida especificación e implementación de transformaciones de modelo a modelo [11].

• XDE: (IBM Rational Rose XDE Modeler) permite crear modelos UML independientes del lenguaje, se puede integrar con diversos entornos [12].

• Stratego: lenguaje modular para la especificación de transformaciones automáticas y completas de programas, basándose en el paradigma de estrategias de reescritura, tiene una herramienta de implementación llamada Stratego/XT [13].

• BOTL: (The Bidirectional Object oriented Transformation Language) notación gráfica precisa, formal y comprensiva, que pretende fundir los lenguajes formales con la fortaleza expresiva de las representaciones gráficas [14].

• ArcStyler: herramienta para la transformación de modelo a modelo, generación de código, y generación de archivos para pruebas y despliegue [15].

• Codagen Architect: herramienta que soporta la generación a partir de diagramas de clases, actividades, estados y casos de uso, importados vía XMI 1.1 [16].


227

• AToM3: (A Tool for Multi-formalism Meta-Modelling) herramienta para el meta-modelado y la transformación de modelos, utiliza una gramática declarativa gráfica y realiza las transformaciones reescribiendo grafos [17].

• KMTL: (Kent Model Transformation Language) posee un framework llamado KMF (Kent Modelling Framework) y se integra a un ambiente de desarrollo llamado MDD Environment, construido sobre el IDE de Eclipse [18].

2.2 Caracterización de los Enfoques de Transformación

Para aplicar los principios planteados en la ingeniería de modelos, es importante tener clara la taxonomía de un enfoque de transformación de modelos. A continuación presentaremos dos de las caracterizaciones que han cobrado gran popularidad.

La primera caracterización es propuesta por Czarnecki y Helsen en su investigación de “Clasificación de enfoques en transformación de modelos” [3], trabajo bastante exhaustivo en tratar los diferentes elementos de un enfoque en transformación de modelos, la figura 2 sintetiza dicha caracterización.

Figura 2. Caracterización de la transformación según Czarnecki y Helsen.


228

La segunda caracterización es presentada por Jézéquel de la Universidad de

Rennes, en su trabajo “Model Transformation Techniques” [19], el mapa de la figura 3 se basa en los conceptos para especificar esta caracterización.

Figura 3. Caracterización de la transformación según Jézéquel.

Un aspecto interesante de ambas caracterizaciones, radica en la forma de evidenciar la diferencia entre las lógicas declarativas e imperativas. La lógica declarativa indica el qué, usando invariantes y relaciones entre los modelos de origen y destino; y la lógica imperativa indica el cómo, para derivar un modelo destino a partir del modelo origen. Ambas lógicas pueden ser combinadas vía pre y post condiciones de la forma ilustrada en la figura 4.

Proceso de transformación de modelos

Pre-Condición Declarativa

Post-Condición Declarativa Regla Imperativa

Figura 4. Combinación de lógica declarativa e imperativa.

Con la lógica declarativa de lenguajes como OCL, se pueden definir reglas de restricción para las pre y post condiciones de las transformaciones, sin embargo la derivación de los elementos del destino a partir de los del origen, necesita de la capacidad de una lógica imperativa como la de los lenguajes de transformación, que indique como realizar las transformaciones

2.3 Clasificación de los Enfoques de Transformación

Los trabajos usados como referentes para la clasificación de enfoques [3], [19], coinciden en definir las dos principales categorías con base en el origen y destino de la transformación, separando los enfoques en transformaciones de modelo a texto y transformaciones de modelo a modelo.

Para la transformación de un modelo a texto existen dos estrategias básicas de implementación: los enfoques basados en visitantes y los basados en plantillas.


229

En cuanto a las transformaciones de modelo a modelo (M2M), el trabajo de Czarnecki y Helsen [3], propone una clasificación cuyo criterio está definido por la estrategia de implementación del enfoque, como lo ilustra la figura 5.

Figura 5. Mapa de los enfoques de M2M según Czarnecki y Helsen.

2.4 Antecedentes en la Evaluación de Herramientas MDA

Tras el surgimiento de MDA, se han adelantado varias investigaciones de herramientas MDA, el detalle de las fechas y herramientas evaluadas en cada una de las investigaciones usadas como referentes en este trabajo se ilustran en la tabla 1.

Tabla 1. Antecedentes en investigaciones de herramientas MDA.

Ref. Entidad o Evento Fecha Herramientas Evaluada [20] King’s College London / The

University of York Sep-2003 OptimalJ

[21] Universidad de Murcia Jun-2004 OptimalJ y ArcStyler [22] Vienna University of

Technology Jun-2005 UMT, MTL, ATL, GMT, BOTL y

OptimalJ. [23] Royal Institute of Technology /

Karolinska University Hospital Jun-2005 OptimalJ, Arcstyler, Codagen

Architect, Objecteering/UML, Together Architect, XMF Mosaic, Constructor, MDE Studio y Ameos.

[24]

International Workshop on Graph and Model Transformation, GraMoT.

Sep-2005 AGG, Fujaba, GReAT y VIATRA.

Si bien es cierto que nuestro trabajo toma como referentes los estudios antes

mencionados, consideramos que el marco de referencia propuesto representa un aporte importante por las siguientes razones: • Complementa dichos estudios con una categorización de las herramientas MDA,

que apoya a las industrias en perfilar sus verdaderas necesidades con respecto a las herramientas de desarrollo que necesita.

• Amplía el espectro de las herramientas evaluadas, pues vemos que el primer estudio solo evalúa una herramienta, y el segundo dos; con respecto al tercer estudio solo coinciden tres herramientas: UMT, ATL y OptimalJ, con el cuarto, solo coincide OptimalJ; y con el quinto no coincide ninguna.

• La construcción de reportes técnicos para ilustrar la aplicación del estudio de un caso en las diferentes herramientas, es un valor agregado importante del proyecto


230

que facilitará el proceso de adopción del enfoque MDA más allá del ámbito académico.

3 Marco de Referencia Propuesto

Este trabajo investigativo pretende ser una guía práctica para las empresas de software que requieren seleccionar la herramienta MDA más adecuada para apoyar la transformación en su proceso de desarrollo y por ende lo agilice.

Es importante poner de manifiesto la relevancia de la verificación de modelos en el marco de la transformación, pues resultaría muy costoso propagar un error de un modelo al momento de transformarlo en otro con un nivel de abstracción menor. Por tal motivo, también se incluyen entornos de verificación de modelos en la evaluación.

3.1 Propuesta de Clasificación de Herramientas

Al revisar diversos sitos dedicados al estudio de MDA con listas de herramientas: • http://www.omg.org/mda/committed-products.htm • http://planetmde.org/ • http://www.codegeneration.net/generators-by-standard.php?standard=1

Nos encontramos con que no se realiza una clasificación de las herramientas de acuerdo con su propósito. Adicionalmente la clasificación de los enfoques de transformación presentada anteriormente en este trabajo, basa su criterio de clasificación en la estrategia de implementación de las reglas de transformación.

La clasificación de herramientas MDA planteada en este trabajo, se fundamenta en la utilidad para el usuario final de la transformación, y presenta estas categorías: • Categoría 1. Herramientas de despliegue de aplicaciones: apoyan el proceso de

desarrollo de software pero que hacen especial énfasis en el despliegue de aplicaciones.

• Categoría 2. Herramientas de transformación: su frente de trabajo fundamental es la transformación, soportan ampliamente la definición de reglas o mecanismos de transformación.

• Categoría 3. Herramientas clásicas de modelado y desarrollo: herramientas que aunque por lo general no se clasifican en el marco de MDA, pero presentan interesantes alternativas de transformación y generación.

• Categoría 4. Entornos de verificación de modelos: herramientas basadas en OCL, que sirven para definir restricciones sobre modelos. Las particularidades de estas herramientas, hacen necesaria la evaluación independiente de las mismas.

• Categoría 5. Herramientas de apoyo al desarrollo de herramientas: las que se usan para desarrollar otras herramientas que apoyen la construcción y transformación de modelos.

• Categoría 6. Herramientas híbridas y otros enfoques: herramientas y frameworks que para sus implementaciones combinan algunos de los demás enfoques planteados, o utilizan otras técnicas.


231

3.2 Criterios de Evaluación

Para la selección de los criterios o propiedades de evaluación que conforman nuestra propuesta, se realizó un compendio de los criterios utilizados en las investigaciones que sirvieron de antecedentes en este trabajo [20], [21], [22], [23], [24], luego se seleccionaron los más relevantes desde la perspectiva práctica del usuario desarrollador, teniendo en cuenta las siguientes consideraciones: • Criterios MDA: las propiedades entre el 1 y el 18, están directamente relacionadas

con el cuerpo del conocimiento de MDA [25]. • Criterios de calidad: las propiedades entre el 20 y el 25, están estrechamente

relacionadas con los atributos de calidad planteados en las normatividades de calidad, especialmente con la norma ISO-9126.

• Criterios de entorno: las dos propiedades restantes, la 19 y la 26, se refieren a la relación de las herramientas con su entorno.

• Criterios generales: aspectos como la arquitectura de la herramienta, la instalación, el montaje de modelos, las estrategias de transformación, la documentación, la facilidad de uso, el despliegue, la internacionalización, la difusión, la madurez, el costo y el soporte; se plasmaron de manera descriptiva en los reportes técnicos de cada una de las herramientas, pero no se consideraron en la análisis cuantitativo.

La tabla 2 ilustra la lista de criterios de esta propuesta, incluyendo las referencias de las investigaciones antecedentes que trabajaron cada criterio.

Tabla 2. Criterios de evaluación del marco de referencia propuesto.

# Propiedad Descripción 1 Soporte para CIM Posibilita la captura de los procesos de negocio a través de

un modelo independiente de la computación [23] 2 Soporte para PIM Permite que se especifique un sistema mediante un modelo

independiente de una plataforma concreta [20] [21] [23] 3 Soporte para PSM Captura una implementación del middleware de un sistema

como un modelo de la arquitectura [20] [21] [23] 4 Definición de

transformaciones Proporciona un lenguaje de modelado para transformaciones y permite manipular las transformaciones [21] [23]

5 Soporte transformaciones entre modelos

Permite transformaciones de un CIM a varios PIMs o de un PIM a varios PSMs [21] [23]

6 Soporte de transformaciones a código

Permite transformaciones PIM o PSM a varios tipos de código [24]

7 Soporte de tipos de transformación

Posibilita transformaciones basadas en marcado, meta-modelo y/o patrones [23]

8 Mapeo bidireccional Permite reglas de transformación en ambos sentidos [23] 9 Soporte de ingeniería en

reversa Permite la generación de modelos a partir de código fuente o ejecutables para los sistemas heredados [22] [23]

10 Integración de Modelos (Transformaciones M:N)

Proporciona mecanismos para integrar modelos de un nivel que generan un solo modelo en el siguiente nivel [23] [24]

11 Sintaxis abstracta para el lenguaje de transformación

Define una sintaxis por composición de partes declarativas e imperativas, basadas en estándares MOF como OCL y QVT [20] [21] [22] [24]

12 Transformación de modelos en el mismo nivel (refinamiento)

Provee soporte para convertir un PSM en otros PSM, o un PIM a otros PIM [20] [21] [22] [23] [24]


232

13 Soporte de los principales diagramas UML para MDA

Posibilita la construcción o importación de los diagramas: casos de uso, clases, estados, secuencias, comunicaciones y/o actividades [20] [21] [24]

14 Soporte de diagramas UML complementarios

Posibilita la construcción o importación de los diagramas: componentes, objetos, despliegue, tiempos, vista de interacción y/o estructura compuesta [23]

15 Soporte de perfiles UML estándar en la industria

Permite la adopción de perfiles para plataformas estándar como J2EE y .NET [23]

16 Creación/Personalización de perfiles UML

Provee la definición de perfiles propios del usuario [23]

17 Soporte puentes Posibilita el uso de puentes entre PSM y entre código en ambas direcciones [23]

18 Uso de patrones Tiene técnicas para definir y aplicar patrones para la construcción de PIMs, PSMs y transformaciones [23]

19 Consistencia incremental Conserva los cambios realizados “manualmente” tras regenerar los modelos [20] [21]

20 Robustez Posibilita dirigir o refinar las transformaciones entre modelos, y si la ejecución de una transformación continúa en caso de encontrar errores [21]

21 Interoperabilidad Expresa sus modelos en UML, es capaz de importar y exportar modelos en XMI y de guardarlos en un almacén MOF [22]

22 Escalabilidad Soporte para transformación con resultados pequeños o grandes [20] [21] [24]

23 Simplicidad La transformación fácil de entender y escribir. Algún tipo de programación como la de las Action Semantics se asume simple [22]

24 Entendibilidad La documentación y la interfaz gráfica usan una terminología comprensible, posee un completo paquete de ejemplos que facilitan su utilización [22]

25 Trazabilidad Registra las transformaciones para permitir conectar un elemento del PIM con los elementos del PSM en que se ha transformado, o con el código que le corresponde [22]

26 Equipado con herramientas

Está acompañado o se integra con herramientas que permitan maximizar y extender su funcionalidad: editores de código, compiladores, etc. [20] [23]

Tras investigar al respecto de la evaluación comparativa de entornos de

verificación de modelos, solo nos encontramos con un estudio realizado en la universidad Nova de Lisboa [26], con un carácter cualitativo, en el que solo se evalúan 8 características muy generales. Por limitantes de espacio no se presenta la descripción de los criterios de la categoría 4, sin embargo la lista de estos se presenta en la tabla 6, en el análisis comparativo de los entornos de verificación de modelos.

3.3 Escala para la Evaluación

En cuanto a la escala de valores para la evaluación, nos basamos en la planteada en [23], que define la calificación con valores entre -1 y 5, como ilustra la tabla 3.


233

Tabla 3. Escala de valores para la evaluación.

Val. Descripción Definición -1 Hace las cosas peor u

ocasiona confusión La forma en que la característica es implementada dificulta el uso, o alienta el uso incorrecto de la misma

0 No soporta La característica no está soportada ni referida en el manual 1 Poco soporte La característica es soportada indirectamente, por ejemplo a

través del uso de otras características de la herramienta en combinaciones no estándar

2 Algún soporte La característica aparece explícitamente en la lista de características de la herramienta

3 Fuerte soporte La característica aparece explícitamente en la lista de características de la herramienta y en el manual del usuario. Todos los aspectos de la característica son cubiertos, pero el uso de la misma dependen de la experiencia del usuario

4 Muy fuerte soporte La característica aparece explícitamente en la lista de características de la herramienta y el manual del usuario. Todos los aspectos de la característica son cubiertos, y la herramienta provee caja de diálogo adaptadas para asistir al usuario

5 Soporte completo La característica aparece explícitamente en la lista de características de la herramienta y el manual del usuario. Todos los aspectos de la característica son cubiertos, y la herramienta provee escenarios para asistir al usuario como los “Wizard”

4 Comparación de Herramientas Basadas en MDA

El estudio de un caso implementado en cada una de las herramientas MDA para la comparación, se especificó de manera tradicional utilizando la propuesta del uso de modelos UML planteada por Larman [27]. El modelamiento de este estudio de un caso siguiendo una aproximación tradicional, sirve de referencia para analizar la manera como las herramientas de transformación, limitan o posibilitan el manejo de los artefactos involucrados en las diferentes fases del proceso.

El estudio del caso representa un ejercicio de tamaño moderado (cinco casos de uso primarios y cuatro clases en el modelo de domino), lo que posibilita el montaje del modelo en cada una de las herramientas a evaluar. Es importante anotar que el estudio del caso, se llevó hasta la implementación y el despliegue, con el propósito de tener un buen referente para evaluar las herramientas que apoyan inclusive en estas epatas.

4.1 Metodología de Evaluación

El método que se propone para la evaluación consta de las siguientes fases: 1. Clasificar: categorizar las herramientas a evaluar con base en la clasificación de

enfoques de transformación propuesta en este marco de referencia. 2. Montar: montaje del modelo conceptual o del diagrama de clases de diseño, del

estudio de un caso, según lo exija cada herramienta. Para esta fase se intenta


234

cargar el modelo vía XMI, en caso de no ser soportado por la herramienta se realiza el modelo dentro de la misma herramienta.

3. Experimentar: probar procesos de transformación automatizados con el apoyo de cada herramienta MDA.

4. Evaluar: realizar la evaluación del conjunto de criterios definidos en cada una de las herramientas exploradas.

5. Reportar: construir un reporte técnico de la evaluación de cada una de las herramientas.

6. Comparar: realizar un análisis comparativo de las herramientas evaluadas.

4.2 Herramientas Evaluadas

La tabla 4 muestra la clasificación que se realizó de las herramientas evaluadas:

Tabla 4. Herramientas evaluadas en cada categoría.

Id Categoría Herramientas C1 Herramientas de

despliegue de aplicaciones H0- OptimalJ: www.compuware.com/products/optimalj/ H1- AndroMDA: www.andromda.org/

C2 Herramientas de Transformación

H2- UMT/QVT: umt-qvt.sourceforge.net/ H3- ATL: http://www.eclipse.org/gmt/atl/download/

C3 Herramientas clásicas de modelado y desarrollo

H4- Enterprise Architect: www.sparxsystems.com/ H5- JDeveloper: www.oracle.com/technology/products/

C4 Entornos de verificación de modelos

H6- OCLE: lci.cs.ubbcluj.ro/ocle/ H7- Octopus: www.klasse.nl/octopus/index.html

C5 Herramientas de Apoyo al desarrollo de herramientas

H8- EMF: www.eclipse.org/emf/ H9-Jamda: jamda.sourceforge.net/

Como vemos, se evaluaron dos herramientas en cada categoría, con el propósito de que el análisis comparativo sea útil incluso dentro de cada categoría.

4.3 Análisis Comparativo

La tabla 5 ilustra los resultados del análisis comparativo de las herramientas y frameworks de las categorías 1, 2, 3 y 5. En cada uno de los reportes técnicos aparece una amplia descripción de las características de cada herramienta, con la respectiva justificación de la calificación asignada a cada característica.

Tabla 5. Análisis comparativo en herramientas de transformación.

Categoría C1 C2 C3 C5 # Propiedad H0 H1 H2 H3 H4 H5 H8 H9 Prom

1 Soporte para CIM 1 1 1 4 1 1 1 1 1,38 2 Soporte para PIM 5 3 1 4 5 5 4 3 3,75 3 Soporte para PSM 5 3 3 4 5 5 3 3 3,88 4 Definición de transformaciones 2 3 3 4 3 0 0 3 2,25 5 Soporte transformaciones entre modelos 5 3 0 5 4 4 0 3 3,00 6 Soporte de transformaciones a código 5 4 5 3 4 4 5 3 4,13 7 Soporte de tipos de transformación 4 3 3 4 3 0 0 3 2,50


235

8 Mapeo bidireccional 0 0 0 3 0 0 0 0 0,38 9 Soporte de ingeniería en reversa 0 3 3 1 4 5 0 0 2,00 10 Integración de Modelos

(Transformaciones M:N) 4 3 0 1 0 3 1 1 1,63

11 Sintaxis abstracta para el lenguaje de transformación

3 3 2 4 4 0 0 0 2,00

12 Transformación de modelos en el mismo nivel (refinamiento)

3 1 0 4 2 0 3 3 2,00

13 Soporte de los principales diagramas UML para MDA

4 4 5 3 5 5 3 3 4,00

14 Soporte de diagramas UML complementarios

4 0 0 1 5 0 0 0 1,25

15 Soporte de perfiles UML estándar en la industria

5 3 4 2 4 5 2 3 3,50

16 Creación/Personalización de perfiles UML 0 3 5 1 5 0 1 1 2,00 17 Soporte puentes 5 0 0 3 0 3 0 0 1,38 18 Uso de Patrones 5 3 0 1 0 5 3 1 2,25 19 Consistencia incremental 5 5 0 5 3 5 5 0 3,50 20 Robustez 3 2 0 5 4 5 3 3 3,13 21 Interoperabilidad 4 3 5 5 5 0 4 2 3,50 22 Escalabilidad 23 Simplicidad 5 3 3 3 3 3 3 3 3,25 24 Entendibilidad 5 3 5 5 5 5 5 2 4,38 25 Trazabilidad 2 1 0 4 1 3 0 3 1,75 26 Equipado con herramientas 2 3 3 5 5 5 5 2 3,75 Total 86 63 51 84 80 71 51 46 66,5

En cuanto a las herramientas de la categoría 4, “entornos de verificación de modelos”, los resultados de su análisis comparativo se ilustran en la tabla 6.

Tabla 6. Análisis comparativo en entornos de verificación.

# Propiedad H6 OCLE

H7 OCTOPUS Prom.

1 Soporte al modelado 5 0 2,50 2 Asistencia en la edición de código OCL 4 4 4,00 3 Compilación 5 5 5,00 4 Chequeo de modelos 5 0 2,50 5 Restricciones sobre el meta-modelo 3 0 1,50 6 Generación de código 5 5 5,00 7 Sintaxis abstracta para el lenguaje de restricciones 5 5 5,00 8 Soporte de ingeniería en reversa 4 0 2,00 9 Soporte de diagramas UML 5 4 4,50 10 Creación y personalización de perfiles UML 0 0 0,00 11 Uso de Patrones 0 0 0,00 12 Consistencia incremental 0 0 0,00 13 Robustez 5 4 4,50 14 Interoperabilidad 0 5 2,50 15 Escalabilidad 16 Entendibilidad 5 5 5,00 17 Equipado con herramientas 5 5 5,00

Total 56 42 49,00


236


El análisis comparativo nos muestra OptimalJ como la herramienta MDA más evolucionada de las evaluadas; mientras que ATL (Atlas Transformation Language) con su herramienta de apoyo ADT (ATL Development Tools), también obtiene un buen puntaje, pues es la única herramienta evaluada que ataca directamente el problema de transformación de modelo a modelo de forma genérica; igualmente Enterprise Architect obtiene buena calificación, pues las transformaciones a PSM y a código son manipulables y fáciles de realizar. En el frente de los entornos de verificación de modelos, OCLE (OCL Environment) ofrece diversas funcionalidades para la edición y verificación de modelos UML 1.5. En cuanto a la columna de los promedios en las tablas 5 y 6, sus valores más altos nos muestran los criterios con mayor apoyo, ilustrando el camino evolutivo de las herramientas MDA.

Dentro de MDA, la transformación juega un papel fundamental, al punto de haber sido llamado “el corazón y el alma de MDA” o “el eslabón perdido de MDA”. Para cristalizar los propósitos de una transformación, se deben utilizar lenguajes que permitan expresar lo qué se quiere transformar y cómo se quiere transformar. La lógica declarativa para expresar el qué, se ha venido estandarizando a través de la maduración y acogida de OCL, pero la lógica imperativa para expresar el cómo, todavía no se encuentra suficientemente estandarizada. Es en este punto donde propuestas tendientes a la unificación como QVT, las Actions Semantics y xUML entre otras, definen caminos para continuar investigaciones como las presentadas en este trabajo. Los trabajos futuros podrían profundizar en los siguientes aspectos: • Definir mecanismos para que MDA sirva de eje integrador de las diferentes

aproximaciones avanzadas en el desarrollo, como son la orientación por aspectos, las líneas de productos de software y los lenguajes específicos de dominio.

• Plantear estrategias para que las herramientas de transformación amplíen la cobertura del CIM, y de esta forma permitir el reuso desde etapas más tempranas.

• Ampliación del espectro de evaluación de entornos de verificación de modelos, para definir si la lógica declarativa ha alcanzado los niveles de asimilación de los conceptos generales de MDA por parte de las herramientas de transformación.

Los diferentes reportes técnicos y demás material producido en este trabajo investigativo, se encuentran disponibles para la comunidad informática en la dirección: http://docencia.udea.edu.co/ingenieria/ArquitecturaSoftware/MDA

Referencias

1. Booch, G., Brown A., Rumbaugh, J.: An MDA Manifesto. IBM Rational Software (2004) 2. Quintero, J., Anaya, R., Marin, C., Bilbao, A.: Un estudio comparativo de herramientas para

el modelado con UML. En: Revista Universidad EAFIT. Vol. 41, No. 137 (2005) 60-73 3. Czarnecki, K., Helsen S.: Classification of Model Transformation Approaches. University of

Waterloo. Canadá (2003) 4. Object Management Group: Model Driven Architecture (MDA) Guide Version [documento

en línea]. OMG (2003) [citado 8-jun-2006] http://www.omg.org/docs/omg/03-06-01.pdf. 5. Object Management Group: Revised submission for MOF 2.0 QVT rfp [documento en

línea]. OMG (2002) [citado 22-ago-2006] http://www.omg.org/ docs/ad/02-04-10.pdf


237

6. Sun Developer Network: Java Metadata Interface (JMI) [documento en línea]. SUN (2002) [citado 10-may-2006] http://java.sun.com/products/jmi/

7. Object Management Group. UML Specification (Action Semantics) [documento en línea]. OMG (2002) [citado 22-ago-2006] http://www.omg.org/docs/ptc/02-01-09.pdf

8. Object Management Group. Semantics of a Foundational Subset for Executable UML Models [documento en línea]. OMG (2005) [citado 22-ago-2006] http://www.omg.org/ docs/ad/05-04-02.pdf

9. Willink, E.: UMLX - A graphical transformation language for MDA. En: OOPSLA 2003 Conference. Anaheim, California (2003)

10. Generative Model Transformer. VIATRA2 Subproject [documento en línea]. GMT (2005) [citado 22-ago-2006] http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/gmt-home/ index.html

11. Agrawal, A., Kalmar, Z., Karsai, G., Shi, F., Vizhanyo, A.: GReAT User Manual. Nashville: Institute for Software-Integrated Systems, Vanderbilt University (2003)

12. International Business Machines Corp.: Rational Rose XDE Modeler [documento en línea]. IBM (2006) [citado 23-ago-2006] http://www306.ibm.com/software/info/ecatalog/ es_ES/products/W107428N46756Z97.html

13. Program-Transformation.Org. Stratego: Strategies for Program Transformation [documento en línea]. Program-Transformation (2004) [citado 23-ago-2006] http://www.stratego-language.org/Stratego/WebHome

14. Marschall, F., Braun, P.: BOTL - The Bidirectional Object Oriented Transformation Language. Instituto de Informática, Universidad Técnica de Munich. Munich (2003)

15. Interactive Objects: ArcStyler 5.5. Documentation Roadmap [documento en línea]. IO (2006) [citado 23-ago-2006] http://www.interactiveobjects.com/data/downloads/ArcStyler _DOC/doc/ArcStylerRoadmap.html

16. Codagen Technologies Corp.: Codagen Architect 3.0: Reviewer’s Guide [documento en línea]. Codagen (2002) [citado 23-ago-2006] http://www.codagen.com/products/architect/ architect_reviewers_guide.pdf

17. The Modelling, Simulation And Design Lab. ATOM3: A Tool for Multi-formalism Meta-Modelling [documento en línea]. MSDL (2006) [citado 24-ago-2006] http://atom3.cs. mcgill.ca/index_html

18. Akehurst, D.H., Howells, W.G., McDonald-Maier K.D.: Kent Model Transformation Language. En: MoDELS 2005 Conference. Montego Bay, Jamaica (2005)

19. Jézéquel, J.M.: Model Transformation Techniques [documento en línea]. Universidad de Rennes (2005) [citado 15-ago-2006] http://www.irisa.fr/prive/jezequel/enseignement/ ModelTransfo.pdf

20. King’s College London, University Of York: An Evaluation of Compuware OptimalJ Professional Edition as an MDA tool (2003)

21. García, J., Rodríguez, J., Menárguez, M., Ortín, M. J., Sánchez, J.: Un estudio comparativo de dos herramientas MDA: OptimalJ y ArcStyler. Universidad de Murcia. Murcia (2004)

22. Wang, W.: Evaluation of UML Model Transformation Tools. Business Informatics Group, Vienna University of Technology. Viena (2005)

23. Akhter, N., Tariq, N.: Comparison of Model Driven Architecture (MDA) based tools. Institute of Technology y Karolinska University Hospital. Estocolmo (2005)

24. Mens, T., Van Gorp, P., Varró, D., Karsay, G.: Applying a Model Transformation Taxonomy to Graph Transformation Technology. En: Electronic Notes in Theoretical Computer Science (2005)

25. Kleppe, A., Warmer , J., Bast, W.: MDA Explained. Addison-Wesley (2003) 26. Santos, R., Invernizzi, H.: OCL – Estado del Arte. Facultad de Ciencias y Tecnología,

Universidad Nova de Lisboa (2004) 27. Larman, C.: UML y Patrones: Introducción al análisis y diseño orientado a objetos. 2 ed. s.l,

Prentice Hall (2005)


238

Composición de Transformaciones de Modelos en MDD

basada en el Álgebra Relacional

Roxana Giandini (1)

Gabriela Pérez (1)

Claudia Pons (1) (2)

(1) Universidad Nacional de La Plata, Facultad de Informática

LIFIA - Laboratorio de Investigación y Formación en Informática Avanzada

La Plata, Bs As, Argentina, 1900

(2) UAI - Universidad Abierta Interamericana, Argentina

[giandini, gperez, cpons]@lifia.info.unlp.edu.ar

Resumen: En el desarrollo de software dirigido por modelos (MDD), los conceptos claves son los

modelos y las transformaciones entre modelos. Esta metodología puede ser vista en forma genérica como

un proceso de desarrollo de software implementado mediante una red de transformaciones entre modelos

que se combinan o componen en modos diversos.

Este trabajo propone un conjunto de operaciones para composición de transformaciones. La aplicación

de estas operaciones fue justificada mediante ejemplos de uso. Se ha observado que la composición de

transformaciones se basa fuertemente en analizar y definir operaciones de composición entre las

relaciones que componen a las transformaciones, por lo que dichas operaciones están inspiradas en

operaciones binarias del Álgebra Relacional. Finalmente se presenta la definición formal de estas

operaciones, en base a un profile para transformaciones ya desarrollado por nuestro grupo de trabajo.

Palabras Claves: Ingeniería de Software, Desarrollo Dirigido por Modelos, Transformación de

Modelos, Composición de Transformaciones

1. Introducción

El desarrollo de software dirigido por modelos - Model Driven Development (MDD) [1] -

propone un proceso de desarrollo de software en el que los conceptos claves son los modelos

y las transformaciones de modelos. En este proceso, el software se obtiene construyendo uno

o más modelos y transformándolos en otros. La visión general de este proceso es que los

modelos de entrada son independientes de la plataforma y los de salida son específicos de la

plataforma y que, estos últimos pueden ser fácilmente transformados a formato ejecutable. En

otras palabras, el proceso dirigido por modelos es comúnmente visto como un proceso de

generación de código.

Existe también otra visión más genérica sobre este proceso, en la cual la diferencia entre ser

independiente de la plataforma y ser específico no es el punto predominante. La clave para

esta vista más genérica es que el proceso de desarrollo de software es implementado mediante

una red de transformaciones que se combinan o componen en modos diversos. Esto hace al

desarrollo dirigido por modelos mucho más abierto y flexible.

Algunas de las posibles composiciones que se pueden dar entre transformaciones son: -

componer dos o más transformaciones existentes en una nueva transformación con sus nuevas

relaciones. Esto podría definirse bajo operadores tales como la suma o diferencia de

transformaciones.

- encadenar dos o mas transformaciones (encadenamiento secuencial), produciendo una nueva

transformación, cuyo dominio será el dominio de la primer transformación y cuyo codominio

será el codominio de la segunda.


239

- combinar dos transformaciones para lograr codominios de transformación más amplios (join

acotado).

La composición de transformaciones requiere contar con constructores propios y operadores

para composición dentro de un lenguaje simple de transformación entre modelos. Diversos

lenguajes para transformación de modelos como ATL [7], Kent [8], TefKat [9] son conocidos

actualmente por estar en una etapa avanzada de desarrollo y uso. A modo de síntesis,

Czarnecki y Helsen en [15] proponen un framework para la clasificación de propuestas para

transformación de modelos existentes. Algunas de estas propuestas incluyen actividades de

composición entre modelos; por ejemplo el trabajo de Bézivin [16] introduce tres frameworks

para composición de modelos y estudia sus características claves; mientras que Kolovos et al

en [11] presentan operaciones para merging de modelos basadas en el lenguaje EOL [10]. Sin

embargo, pocas de ellas tratan el aspecto de composición de transformaciones. El trabajo de

Kleppe [12] presenta un ambiente para transformación de modelos llamado MCC,

implementado como un plug-in para Eclipse; además describe someramente una clasificación

de operaciones para combinar transformaciones como unidades independientes ejecutables.

En este trabajo presentamos un álgebra para composición de transformaciones. El conjunto de

operadores definidos permitirá al usuario discernir bajo que condiciones aplicar cada uno y

administrar su combinación para obtener los resultados esperados. La definición de estos

operadores está inspirada en las operaciones binarias del álgebra relacional. Describimos

también una formalización para esta propuesta como extensión de trabajos anteriores [14, 19],

donde definimos un metamodelo y construimos un lenguaje minimal para transformación de

modelos.

El artículo se estructura de la siguiente manera: la sección 2 presenta un análisis general del

concepto de composición de transformaciones basado en el estudio de un ejemplo y en el

metamodelo propuesto para transformaciones. La sección 3 justifica el motivo por el que

basamos la definición de composición de transformaciones en el Álgebra Relacional y

presenta informalmente, a través de ejemplos, las operaciones para composición de

transformaciones. La sección 4 presenta la definición formal (en base al profile construido) de

las operaciones de composición introducidas en la sección anterior. Finalmente la sección 5

presenta conclusiones y líneas de trabajo futuro.

2. Un análisis del Concepto de Composición de Transformaciones

En esta sección analizamos mediante un ejemplo de aplicación real la necesidad de contar con

operadores de composición entre transformaciones. Supongamos que queremos definir una

transformación que transforme todos los elementos que forman un diagrama de clases UML

en elementos Java. Para simplificar esta tarea podría dividirse y asignarse subtareas a distintos

grupos de trabajo. Cada uno de estos grupos desarrollará las reglas o relaciones necesarias

para transformar un subconjunto de elementos de UML. En este caso, llamemos T1 y T2 a dos

de estas transformaciones parciales. La cuestión que se plantea ahora es como componer estas

transformaciones para obtener la transformación requerida inicialmente. Surge así la

necesidad de definir operadores para combinar transformaciones. En este caso podemos

llamar suma a la operación que se aplica a dichas transformaciones parciales para obtener una

transformación más completa. Por ejemplo, la Figura 1 muestra dos transformaciones, T1 y

T2. T1 transforma algunos elementos del metamodelo UML en elementos Java.

Análogamente, T2 transforma otros elementos del metamodelo UML en elementos Java.

Llamamos T1+T2 a la transformación resultante de sumar estas dos transformaciones, la cual

deberá contener las relaciones necesarias para transformar los mismos elementos fuente, en

los mismos elementos destino de las transformaciones originales.


240

Supongamos ahora que se requiere definir una transformación UML2Rel que convierta

elementos UML en elementos del Modelo Relacional. Contamos con T1+T2 (definida entre

UML y Java), y tenemos disponible otra transformación T3, que se aplica entre Java y el

Modelo Relacional. Para obtener UML2Rel (llamada T1+T2&T3 en la Figura 1) existen al

menos dos posibilidades: la primera es creando una nueva transformación e inicializándola

definiendo las relaciones necesarias para transformar cada uno de los elementos; la segunda es

realizar el encadenamiento secuencial de las transformaciones ya existentes mediante la

aplicación de una operación. Como en el caso de la suma, esto resultará más beneficioso.

Por último, supongamos que no se tiene decidido en que plataforma se implementará el

modelo UML debido a que, dependiendo de las propiedades del hardware y del software

instalado en los equipos, se puede obtener una mayor performance usando una u otra

plataforma. En consecuencia, es deseable mantener las opciones de transformación

postergando la selección del modelo destino hasta el momento de la concreción. Las

plataformas opcionales para este caso son el Modelo Relacional y un Modelo Orientado a

Objetos. Para esto, contamos con una transformación T4 que convierte elementos UML en

elementos del Modelo Orientado a Objetos. Se requiere por lo tanto, definir una

transformación que permita especificar relaciones que conviertan elementos UML tanto en

elementos del Modelo Relacional como en elementos del Modelo Orientado a Objetos.

Resulta entonces necesaria la definición de un tercer operador, el cual llamaremos Join

Acotado, que produce como resultado la transformación llamada T1+T2&T3#T4 en la Figura

1. Esta operación permitirá ampliar el codominio de la transformación resultante mediante la

combinación de los metamodelos de las transformaciones originales. Por ejemplo, para una

transformación de clases UML a elementos del Modelo Relacional, compuesta con otra

transformación de clases UML a elementos del Modelo Orientado a Objetos, genera una

relación que tenga como dominio a las clases UML y como codominio a las tuplas formadas

por elementos del Modelo Relacional y elementos del Modelo Orientado a Objetos. Para

poder aplicarse, las transformaciones a componer deben tener el mismo metamodelo como

dominio.

Figura 1: Ejemplo de composición de transformaciones

Mediante el desarrollo de este ejemplo se puede ver que la utilización de operadores de

composición entre transformaciones tiene la ventaja de evitar la especificación de una nueva

transformación, mediante la reutilización de elementos ya definidos.

En cuanto a la metodología a seguir para componer transformaciones debemos analizar la

estructura de una transformación. La figura 2 muestra el metamodelo minimal para

transformaciones propuesto en nuestro trabajo previo [19] e inspirado en el lenguaje QVT


241

(Query/View/Transformations) [4]. Siguiendo este metamodelo, una transformación puede

verse como un conjunto de relaciones ya que éstas son sus componentes principales, que

aplicadas a un dominio producen elementos del codominio. El dominio de una relación se

define como el conjunto de elementos a los cuales efectivamente se aplica la relación. Al tipo

de estos elementos lo llamaremos tipo de dominio de la relación. Análogamente se define el

codominio como el conjunto de elementos obtenidos al aplicar la relación. Llamaremos tipo

del codominio al tipo de los elementos pertenecientes al codominio.

Las relaciones pueden ser de distinto nivel: algunas se ejecutan automáticamente (relaciones

topLevel), mientras que otras deben ser invocadas explícitamente. Se ha observado que la

composición de transformaciones se basa fuertemente en analizar y definir operaciones de

composición entre sus relaciones topLevel.

3. La Composición de Transformaciones Basada en el Álgebra

Relacional

El lenguaje QVT, especificación estándar de OMG [2] para transformaciones, y otros

lenguajes basados en él, definen a las transformaciones en términos de relaciones que

transforman elementos particulares de determinados metamodelos en otros elementos

posiblemente expresados en otro metamodelo. Como se describió en la sección 2, al

componer dos transformaciones, componemos sus relaciones. En cada relación se define

dominio y codominio. Dentro de los dominios, se definen variables y expresiones que

especifican la transformación entre el tipo del dominio y el tipo del codominio, y que pueden

estar embebidas en forma de predicados en las cláusulas when y where de la relación (ver

Figura 2). Combinar estos predicados puede provocar que un mismo elemento del dominio se

relacione con más de un elemento en el codominio (como en el caso del join acotado). Esto es

correcto ya que hablamos de relaciones en el sentido matemático y no de funciones. Bajo este

análisis podemos concluir que para combinar o componer relaciones de transformaciones,

resulta válido aplicar las operaciones binarias del Álgebra Relacional.

En el siguiente apartado recordamos la definición de las operaciones del Álgebra Relacional y

luego presentamos la definición e introducimos ejemplos de algunas operaciones para

composición de transformaciones que se basan en ellas.

3.1 El Álgebra Relacional - Operaciones Binarias

Los matemáticos definen una relación como un subconjunto del producto cartesiano de una

lista de dominios. En el área de Bases de Datos Relacionales, esto se corresponde exactamente

con la definición de Tabla, por lo que pasa a usarse el término matemático de relación y tupla,

en vez de los términos tabla y fila [18].

Un lenguaje de consulta es un lenguaje en el cual un usuario solicita información desde la

base de datos. El álgebra relacional es un lenguaje de consulta procedural. Hay cinco

operaciones fundamentales en esta álgebra. Dos unarias: selección y proyección, y tres

binarias: producto cartesiano, unión o suma y diferencia de conjuntos. Todas estas

operaciones producen una nueva relación como resultado. Adicionalmente, otras operaciones

que pueden definirse en términos de las fundamentales son: theta -Joint, joint natural,

intersección y división.

Introducimos a continuación algunas de estas operaciones, que nos dan base para la definición

del álgebra de transformaciones:


242

Figura 2. Metamodelo para Transformación de Modelos

Sean las relaciones R y S definidas de la siguiente manera:

R = {(a1, a2) | a1 D1 y a2 D2 }

S = {(b1,b2)| b1 D3 y b2 D4 } donde

D1 y D2 son dominio y codomino de R respectivamente y D3 y D4 son dominio y codomino

de S respectivamente.

Sobre R y S se definen las operaciones binarias:

• Unión (U): R U S es el conjunto de tuplas formado por los elementos que están en R, en S

o en ambos. RUS = { (c1,c2) | (c1,c2) R ó (c1,c2) S }

• Producto cartesiano (X): R X S es el conjunto de todas las tuplas (k1 + k2) cuyos

primeros k1 elementos forman una tupla en R y los últimos k2 elementos forman una

tupla en S. R X S = { ((a1,a2),(b1, b2)) : (a1,a2) R y (b1, b2) S}

� Join Natural ( # ): es una operación derivada del Producto cartesiano, donde las

tuplas se forman uniendo las tuplas de R y de S que tienen variables del dominio en

común.

• Diferencia de conjuntos ( - ) R – S es el conjunto de tuplas que pertenecen a R y que no

están en S. R – S = { (c1,c2) | (c1,c2) R y (c1, c2) S }

3.2 El Álgebra de Transformaciones - Operaciones Binarias

Abordaremos en detalle en este trabajo las operaciones de suma o unión, encadenamiento

secuencial y join acotado entre transformaciones. La definición del resto de las operaciones es

parte de nuestro trabajo futuro.

En algunos casos al componer dos transformaciones (por ejemplo en la suma), hay que

analizar sus conjuntos de relaciones para determinar cuales predican sobre elementos en

común y cuales no. Las relaciones que no tienen elementos en común van a formar parte de la

transformación resultante en su forma original, mientras que en el caso de las otras relaciones


243

habrá que aplicar el operador correspondiente pero esta vez entre relaciones, para obtener una

nueva relación que forme parte de la transformación resultante.

En otros casos, como en el encadenamiento secuencial, habrá que analizar otras condiciones

que las relaciones deban cumplir para componerse en secuencia.

En conclusión, se puede decir que la composición entre transformaciones puede llevarse al

plano de definir operadores de composición en términos de las relaciones que las componen y

cumplen con las condiciones necesarias para poder componerse.

En general, las operaciones que presentamos consideran a las relaciones definidas de un solo

dominio a un solo codominio, como aparece especificado en el metamodelo de la Figura 2.

Para describir en forma clara cada una de las operaciones, a continuación se definen las

transformaciones introducidas en el ejemplo de la sección 2, sobre las cuales se aplicaran,

paso a paso, las operaciones introducidas también en la misma sección.

Suma de transformaciones

La idea intuitiva de la suma de dos transformaciones T1 y T2, es que la transformación

resultado contenga todas las relaciones definidas en las transformaciones originales. En este

contexto, se debe analizar cada relación de T1 respecto a todas las relaciones de T2 y

viceversa. Para cada relación de T1 si esta definida sobre elementos distintos a los que se

aplican las relaciones de T2, dicha relación aparecerá sin modificaciones en la transformación

resultante. En cambio, por cada relación existente en T2 que se aplica sobre elementos

comunes, se creará una nueva relación resultante de la suma de las dos originales. Las

relaciones de T2 que no fueron combinadas con relaciones de T1 aparecerán también sin

modificaciones en la resultante.

Para comprender mejor la suma de dos transformaciones, introducimos a continuación la

especificación de dos transformaciones T1 y T2 y de la transformación T1+T2, resultante de

aplicar la suma entre ellas. La especificación de las transformaciones se muestra (por

restricciones de espacio) en formato textual. Este formato se genera automáticamente al

imprimir a texto una especificación gráfica construida instanciando nuestro profile para

transformaciones.

Los ejemplos de transformaciones presentados están inspirados en el Catálogo de Lano[17]. Transformation T1 (Uml: UML2.0, Java: JAVA) {

TopLevel Relation PersistentClass2ClassWithKey {

checkonly domain Uml c: Class

checkonly domain Java jc: JavaClass

when {c.isPersistent}

where {c.name =jc.name and jc.ownedFields-> exists (jf: JavaField |

jf.name = “primaryKey” and jf.type = “Integer”) and jc. ownedMethods -> exists

(jm: JavaMethod | jm.name = “getPrimaryKey” and jm.returnType = “Integer”) } }

Transformation T2 (Uml: UML2.0, Java: JAVA) {

TopLevel Relation Class2Class {



when {}

where { c.name = jc.name and

c. ownedAttribute -> forAll (p : Property | ( jc.ownedFields->

exists(jf:JavaField | p.name = jf.name) and jc.ownedMethods -> exists (jm1,

jm2 : JavaMethod | Attr2Getter (p, jm1) and Attr2Setter (p, jm2)) }}

Relation Attr2Getter{

checkonly domain Uml a: Property

checkonly domain Java jm: JavaMethod

when { }


244

where { ‘get’ + p.name.firstUpperCase() = jm.name } }

Relation Attr2Setter{

checkonly domain Uml p: Property

checkonly domain Java jm: JavaMethod

when { ! p.isReadOnly }

where {jm.name = ‘set’ + p.name.firstUpperCase() and jm.ownedParameter-

>first().name = ‘a’ + p.name.firstUpperCase() and jm.ownedParameter-

>first().type = p.type} }

Query firstToUpperCase(string: String) : String {

self.substring(1,1).toUpperCase()+self.substring(2,self.size())}

}

Ambas transformaciones T1 y T2 se aplican entre un modelo UML y un modelo JAVA.

T1 define una única relación topLevel, llamada PersistentClass2ClassWithKey. El tipo del

dominio de esta relación son todas las clases UML. El tipo de codominio de esta relación son

las clases Java. La cláusula when de esta relación determina su dominio, que esta restringido a

todas las clases persistentes. Al aplicar la relación, por cada clase UML, se generará una clase

Java con el mismo nombre, a la cual se introduce un nuevo atributo de identidad, llamado

primaryKey de tipo Integer para cumplir la función de clave primaria. Además, para permitir

la lectura de este atributo se agrega una nueva operación llamada getPrimaryKey.

T2 define una única relación topLevel, Class2Class, cuyo dominio son todas las clases dado

que la cláusula when no tiene condición (se asume true), por lo tanto no restringe los

elementos del tipo del dominio. Las clases Java son el tipo de su codominio.

Class2Class invoca a otras dos relaciones, Attr2Getter y Attr2Setter. Al aplicar la relación

Class2Class, en el modelo Java resultante se agrega un método getter y uno setter por cada

atributo definido en la clase original. Además de estas relaciones, la transformación incluye un

query que, dado un string, retorna el mismo string con el primer carácter en mayúscula.

Como dijimos en la sección 2, al sumar T1 con T2 hay que analizar las relaciones que las

componen. Attr2Getter y Attr2Setter, al no ser topLevel, formarán parte de la suma, tal cual

estaban definidas teniendo en cuenta que no se produzcan conflictos de nombre entre las

relaciones de una y otra transformación. Lo mismo ocurre con el query definido en la

transformación. En cambio, entre las relaciones topLevel PersistentClass2ClassWithKey y

Class2Class, definidas sobre los mismos tipos de elementos, se aplica la operación de suma

para relaciones. Esta operación crea una nueva relación con el mismo tipo de dominio y el

mismo tipo de codominio que las relaciones originales. El dominio de la relación resultado

será la unión de los dominios de las relaciones origen. La cláusula when resultante se define

como una disyunción entre las cláusulas when de las relaciones originales. La cláusula where

se define como una disyunción entre las dos conjunciones formadas por los when y where de

las relaciones originales:

Transformation T1 + T2 (Uml: UML2.0, Java: JAVA) {

TopLevel Relation PersistentClass2ClassWithKey+Class2Class {



when { true or c1.isPersistent }

where {

(true and c.name = jc.name and


exists(jf:JavaField | p.name = jf.name) and jc.ownedMethods -> exists (jm1,

jm2 : JavaMethod | Attr2Getter (p, jm1) and Attr2Setter (p, jm2)) )

OR

(c.isPersistent and c.name =jc.name and jc.ownedFields-> exists (jf: JavaField

| jf.name = “primaryKey” and jf.type = “Integer”) and jc. ownedMethods ->


245

exists (jm: JavaMethod | jm.name = “getPrimaryKey” and jm.returnType =

“Integer”)) } }

Encadenamiento secuencial de transformaciones

La idea intuitiva de componer en secuencia dos transformaciones es generar una

transformación compuesta cuya aplicación sea equivalente a aplicar primero una

transformación T1 y a ese resultado, aplicarle una segunda transformación T2. Solo los

elementos del modelo de entrada de T1 que tengan como salida elementos del modelo de

entrada de T2, pertenecerán a la transformación compuesta. Aquellos que no tengan elementos

que los conecten no pertenecerán al resultado.

Esta operación fue definida debido a que al desarrollar ejemplos de composición resultó

interesante y útil componer transformaciones en secuencia, donde sus relaciones se encadenen

siempre que el tipo de codominio de la primera relación sea igual al tipo de dominio de la

segunda relación. Cada tupla se compone entonces de un elemento del dominio de la primera

y un elemento del codominio de la segunda.

Sea la transformación T3 definida con una única relación topLevel que convierte clases Java

en tablas de Modelo Relacional con igual nombre. Además, los atributos simples de las clases

JAVA pasan a ser columnas, con igual nombre e igual tipo, en la tabla correspondiente:

Transformation T3 (Java: JAVA, Rel: RDBMS) {

TopLevel Relation Class2Table {


checkonly domain Rel t: Table

when { }

where {jc.name = t.name and jc.ownedFields -> forAll (jf:JavaField |

t.column -> exists (co | Attr2Col (jf, co))

Relation Attr2Col {

checkonly domain Java jf: JavaField

checkonly domain Rel co: Column

when {not jf.isMultivalued()}

where { co.type = jf.type and co.name = jf.name } }

Como en otros casos de composición, al encadenar dos transformaciones, hay que analizar las

relaciones que las componen. Siguiendo con el ejemplo, si encadenamos en secuencia la

transformación T1+T2 con T3, por cada relación de la transformación T1+T2 se estudia su

conexión con cada relación de T3. Se aplicará la operación de encadenamiento secuencial

pero ahora entre relaciones; en este ejemplo las relaciones que cumplen con la condición para

ser encadenadas son PersistentClass2ClassWithKey + Class2Class de T1+T2 y Class2Table

de T3. Se genera así una nueva relación topLevel que convierte clases UML en tablas del

Modelo Relacional. En este caso, el encadenamiento secuencial resultará en la siguiente

transformación:

Transformation T1+T2 & T3 (Uml: UML2.0, Rel: RDBMS) {

TopLevel Relation PersistentClass2ClassWithKey+Class2Class & Class2Table {


checkonly domain Rel t: Table

when { true or c1.isPersistent }

where {

LET jc: Class =



exists(jf:JavaField | p.name = jf.name) and jc.ownedMethods -> exists

(jm1, jm2 : JavaMethod | Attr2Getter (p, jm1) and Attr2Setter (p, jm2))

) or


246

(c.isPersistent and c.name =jc.name and jc.ownedFields-> exists (jf:

JavaField | jf.name = “primaryKey” and jf.type = “Integer”) and jc.

ownedMethods -> exists (jm: JavaMethod | jm.name = “getPrimaryKey” and

jm.returnType = “Integer”) )

AND true

IN

jc.name = t.name and jc.ownedFields -> forAll (jf:JavaField |

t.column -> exists (co | Attr2Col (jf, co)) }

Al observar la transformación resultante, podemos enunciar algunas cuestiones sobre las

relaciones que fueron encadenadas:

• En la relación compuesta aunque los elementos intermedios no aparecen ni en el dominio

ni en el codominio, las condiciones entre ellos deben seguir cumpliéndose, por lo que la

cláusula where de la primera relación debe cumplirse. Por esta razón debe formar parte de

la cláusula where de la transformación resultante. Lo mismo ocurre con la cláusula when

de la segunda relación. Estas condiciones intermedias aparecen especificadas mediante

una expresión LET de OCL dentro de la cláusula where de la relación resultante.

• Las relaciones invocadas por las topLevel (por ej. Attr2Setter) que se aplican a elementos

de metamodelos intermedios, deberán también ser parte de la cláusula where de la

relación compuesta, ya que el metamodelo intermedio esta oculto y en caso contrario

quedarían mal definidas. Por lo tanto, deben estar incluidas también como expresiones

LET dentro del where resultante. Por limitaciones de espacio y por legibilidad, en el

ejemplo no se encuentran incluidas en la cláusula where.

Join acotado ( # ) de transformaciones

Esta operación se basa en el Join Natural del Álgebra Relacional. Tiene como precondición

que las transformaciones se apliquen sobre el mismo metamodelo de entrada. La idea intuitiva

al componer dos transformaciones T1 y T2 mediante un join es que la transformación

compuesta mantenga como entrada los elementos de entrada en común de T1 y T2 y como

salida los elementos de salida de ambas transformaciones. Es decir, componer dos

transformaciones para lograr codominios de transformación más amplios, para un mismo

elemento del dominio. Como en los otros casos, debemos analizar como componer las

relaciones. La idea es que se compongan aquellas relaciones de cada transformación que se

apliquen sobre el mismo dominio. El codominio se forma con los codominios de ambas

relaciones, dando así la posibilidad de que a un mismo elemento del dominio, le correspondan

2 elementos en el codominio.

Consideremos la transformación T4 que convierte mediante una relación topLevel, clases

UML a clases del Modelo Orientado a Objetos:

Transformation T4 (Uml: UML2.0,oodbms: OODBMS) {

TopLevel Relation Class2 OODBMSClass {


checkonly domain oodbms c2: Class

when { }

where {c.name = c2.name and c. ownedAttributes -> forAll (p: Property |

if (p.type.oclIsKindOf(Datatype)) then c2.attributes -> exists (a: Attribute |

p.name = a.name and p.type = a.type) and c2.attributes -> exists (a:Attribute |

a.name = “OID” and a.type = String) }

La aplicación de la operación Join acotado entre las transformaciones T1+T2 & T3 y T4

resulta en la siguiente transformación:

Transformation T1+T2&T3 # T4 (Uml:UML2.0,Mm: RDBMSMergeOODBMS){


247

TopLevel Relation PersistentClass2ClassWithKey+Class2Class & Class2Table #

Class2 OODBMSClass {


checkonly domain Mm t: Table, Mm c2: Class

when { true or c1.isPersistent and true }

where {

LET jc: Class =



exists(jf:JavaField | p.name = jf.name) and jc.ownedMethods -> exists

(jm1, jm2 : JavaMethod | Attr2Getter (p, jm1) and Attr2Setter (p,

jm2))) or

(c.isPersistent and c.name =jc.name and jc.ownedFields-> exists (jf:

JavaField | jf.name = “primaryKey” and jf.type = “Integer”) and jc.

ownedMethods -> exists (jm: JavaMethod | jm.name = “getPrimaryKey” and

jm.returnType = “Integer”) )

IN

jc.name = t.name and jc.ownedFields -> forAll (jf:JavaField | t.column

-> exists (co | Attr2Col (jf, co))

AND

c.name = c2.name and c. ownedAttributes -> forAll (p: Property | if

(p.type.oclIsKindOf ( Datatype)) then c2.attributes -> exists (a: Attribute |

p.name = a.name and p.type = a.type) and and c2.attributes -> exists

(a:Attribute | a.name = “OID” and a.type = String) } }

Puede verse que el metamodelo de la transformación resultante coincide con el metamodelo

de las transformaciones originales, mientras que el metamodelo de salida se define como un

metamodelo Mm producto del merge entre los metamodelos de salida de las transformaciones

originales.

Al igual que en los demás casos, al componer transformaciones se componen las relaciones

que las forman. En este caso, se componen las dos únicas relaciones topLevel definidas en las

transformaciones. La relación resultante mantiene el tipo de dominio de las originales. El tipo

del codominio esta compuesto por las variables de los tipos de codominio de las relaciones

originales. La cláusula when de la relación resultado, se define como una conjunción entre las

cláusulas when de las relaciones originales, formando así el dominio con la intersección de

ambos dominios originales. La cláusula where se define como una conjunción de las cláusulas

where de las relaciones originales.

4. Una Formalización para Composición de Transformaciones

Presentamos en esta sección una especificación formal para las operaciones introducidas

intuitivamente en la sección anterior. Esta formalización se basa en el profile que implementa

el metamodelo para Transformaciones inspirado en QVT. Dicho profile utiliza el lenguaje

para restricciones OCL [5] y extiende a la Infrastructure 2.0 [6], instancia de MOF [3]. La

implementación completa del profile puede encontrarse en nuestro trabajo anterior [19].

En este trabajo, las operaciones están especificadas en términos de las metaclases

pertenecientes al metamodelo de la Figura 2, abstrayéndonos de las particularidades de

implementación del profile.

4.1 Definición de las operaciones de Composición

Las operaciones están definidas en OCL especificando sus pre y postcondiciones, en el

contexto de un elemento Relation. Una Relation cumple con ciertas restricciones y se


248

compone de dominio, codominio, cláusulas when y where, helpers y eventualmente un

conjunto de variables globales (relationVars) de tipo de dato primitivo que describen

generalmente nombres de variables comunes a los dominios de la relación.

En general, las operaciones tienen otra Relation como parámetro, con la cual se compone la

receptora, y dan como resultado una nueva Relation. Los prerrequisitos que piden las

operaciones, se expresan en forma de precondiciones, mientras que las definiciones de cada

elemento que conforma a la Relation resultante (dada por la pseudovariable result de OCL), se

expresa en las postcondiciones de la operación.

Suma de Relaciones (+)

Context Relation:: suma (r2: Relation) : Relation

Precondiciones:

Los metamodelos del dominio y del codominio de ambas relaciones coinciden, y los tipos del dominio y

codominio también. Pre: self.domain.typedModel.metamodel = r2.domain.typedModel.

metamodel and self.coDomain.typedModel.metamodel= r2.coDomain.

typedModel.metamodel

Pre: self.domain.variables-> collect(v|v.type) = r2.domain.variables -

> collect(v| v.type) and self.codomain.variables->collect(v|v.type) =

r2.codomain.variables->collect(v| v.type)

Suponemos que los nombres de variables de dominio y codominio de ambas relaciones coinciden. En

caso contrario, se deben renombrar las variables de r2 para que haya coincidencia, modificando también

las ocurrencias de tales variables en el body del when / where donde sea necesario.

Postcondiciones:

El nombre de la relación resultado es la unión de los nombres de ambas relaciones con ‘+’ intercalado. Post: result.name = self.name.concat (‘+’).concat (r2.name)

La cláusula when se forman como la disyunción entre los when de las relaciones originales. Si alguna

relación no tiene definida su cláusula when, se entiende que aplica a todos los elementos del tipo de

dominio, por lo cual se puede interpretar que la cláusula tiene valor true. Post: result.when.bodyExpression = self.when. getBodyExpression or

r2.when. getBodyExpression

La operación getBodyExpression retorna la expresión de la cláusula when en caso que exista, o una

expresión true en caso contrario.

La cláusula where se forma con la disyunción entre las conjunciones formadas por los when / where de

las relaciones originales. Post: result.where.bodyExpression = (self.when.getBodyExpression and

self.where.bodyExpression) or (r2.when.getBodyExpression and

r2.where.bodyExpression)

Los metamodelos de dominio y codominio son los de la relación receptora. Post:result.domain.typedModel.metamodel =

self.domain.typedModel.metamodel

Post:result.coDomain.typedModel.metamodel=

self.coDomain.typedModel.metamodel

Las variables del dominio y codominio coinciden con las variables de la relación receptora. Post:result.domain.variables = self.domain.variables

Post:result.coDomain.variables = self.coDomain.variables


249

Los helpers se forman con la unión de los helpers de las relaciones originales. Post: result.helpers = self.helpers ->union (r2.helpers)

Las variables globales se forman con la unión de las variables globales de las relaciones originales. Post: result. relationVars = self.relationVars -> union (r2.

relationVars)

Encadenamiento secuencial de relaciones (&)

Context Relation:: secuencia (r2: Relation) : Relation

Precondiciones: Los elementos del codominio de la relación receptora coinciden con los elementos del dominio de la

relación parámetro. Pre: self.coDomain.variables-> collect(v|v.type)= r2.domain.variables-

>collect(v| v.type)

Suponemos que los nombres de variables de dominio de la relación r2 coinciden con los de las variables

de codominio de la relación receptora. En caso contrario, se deben renombrar como se especificó en la

suma.

Postcondiciones: El nombre de la relación resultado es la unión de los nombres de ambas relaciones con ‘&’ intercalado. Post: result.name = self.name.concat (‘&’).concat (r2.name)

El metamodelo del dominio de la relación resultado coincide con el metamodelo del dominio de la

relación receptora. Post:result.domain.typedModel.metamodel =


El metamodelo del codominio de la relación resultado coincide con el metamodelo del codominio de la

relación parámetro. Post:result.coDomain.typedModel.metamodel =

r2.coDomain.typedModel.metamodel

Las variables de dominio coinciden con las variables de la relación receptora. Las variables del

codominio coinciden con las variables de la relación parámetro. Post:result.domain.variables = self.domain.variables

Post:result.coDomain.variables = r2.coDomain.variables

La cláusula when es la cláusula when de la relación receptora. Post: result.when.bodyExpression = self.when. bodyExpression

La cláusula where de la relación resultante se forma con el where de la relación parámetro. Como parte

de esta cláusula se define, mediante una expresión LET de OCL, la conjunción de la cláusula where de la

relación receptora con la cláusula when de la relación parámetro. De la misma manera, las relaciones

restantes, no topLevel, deben ser rescritas también en forma de LETs anidados, dentro de la cláusula

where.

Post: result.where. bodyExpression =

LET self.codomain.variables. first.eferredVariable =

self.where.bodyExpression and r2.when. bodyExpression

IN r2.where.bodyExpression

Los helpers y las variables globales se forman de la misma manera que en el caso de la suma.


250

Join acotado de Relaciones (#)

Context Relation:: join# (r2: Relation):Relation

Precondiciones:

Los metamodelos del dominio de ambas relaciones coinciden. Pre: self.domain.typedModel.metamodel= r2.domain.typedModel.metamodel

Los elementos del dominio de ambas relaciones coinciden. Pre: self.domain.variables->collect(v|v.type)= r2.domain.variables->

collect(v| v.type)

Suponemos que los nombres de variables del dominio de ambas relaciones coinciden. En caso contrario,

se deben renombrar como se especificó en la suma.

Postcondiciones:

El nombre de la relación resultado es la unión de los nombres de ambas relaciones con ‘#’ intercalado. Post: result.name = self.name.concat (‘#’).concat(r2.name)

El metamodelo del dominio es el metamodelo del dominio la relación receptora. Post:result.domain.typedModel.metamodel =


El nombre del metamodelo del codominio de la relación resultado es la concatenación de los nombres

con la palabra ‘Merge’ intercalada. Post:result.codomain.typedModel.metamodel.name=

self.codomain.typedModel.metamodel.name.concat(‘Merge’).

concat(r2.codomain.typedModel.metamodel.name)

El metamodelo del codominio de la relación resultado se forma aplicando un merge con el metamodelo

del codominio de la relación receptora y un merge con el codominio de la relación parámetro. Post: result.coDomain.typedModel.metamodel.packageMerge-> exists (pm |

pm.mergedPackage = self.coDomain.typedModel.metamodel) and

result.coDomain.typedModel.metamodel.packageMerge-> exists (pm |

pm.mergedPackage = r2.coDomain.typedModel.metamodel)

Las variables del dominio coinciden con las variables de la relación receptora. Post:result.domain.variables = self.domain.variables

Las variables del codominio se forman con la composición de las variables de los codominios de las

relaciones originales. Post:result.coDomain.variables = self.coDdomain.variables ->

union(r2.coDomain.variables)

Post: result.when.bodyExpression = self.when.bodyExpression and

r2.when.bodyExpression

Post: result.where. bodyExpression = self.where.bodyExpression and

r2.where.bodyExpression

Los helpers y las variables globales se forman de la misma manera que en el caso de la suma.

5. Conclusiones

El desarrollo de software dirigido por modelos puede ser visto en forma genérica como un

proceso de desarrollo de software implementado mediante una red de transformaciones entre


251

modelos que se combinan o componen en modos diversos. Esto hace al desarrollo dirigido por

modelos mucho más abierto y flexible.

La utilización de operadores de composición entre transformaciones tiene la ventaja de evitar

definir nuevas transformaciones, mediante la reutilización de elementos ya definidos.

En este trabajo hemos propuesto un conjunto de operaciones para composición de

transformaciones. La aplicación de estas operaciones fue justificada mediante ejemplos de

uso. Además presentamos la definición formal en OCL de ellas, en base al profile para

transformaciones ya desarrollado por nuestro grupo de trabajo. Se ha observado que la

composición de transformaciones se basa fuertemente en analizar y definir operaciones de

composición entre las relaciones que componen a las transformaciones, por lo que dichas

operaciones están inspiradas en las operaciones binarias del Álgebra Relacional.

En lo inmediato, implementaremos estas operaciones integrándolas a la herramienta Case

[13] que nuestro grupo de investigación está desarrollando. Resta abordar el estudio y

formalización de otras operaciones de composición entre transformaciones que surgen del

Álgebra Relacional, como diferencia, producto Cartesiano, intersección, etc. El análisis

incluirá en que casos el desarrollador puede encontrarle una utilización conveniente a la

aplicación de estas operaciones.

Resulta interesante también extender este profile para soportar mecanismos de Traceability

que permitan recuperar información acerca del origen de los elementos que forman las

diferentes composiciones.

Referencias

1. MDA Guide, v1. 0. 1, omg/03-06-01, June 2003. http://www. omg. org.

2. OMG (Object Management Group) http://www. omg. org

3. Meta Object Facility (MOF) 2. 0. OMG Adopted Specification. 2003. http://www. omg. org.

4. MOF 2. 0 Query/View/Transformations (QVT) - OMG Adopted Specification. March 2005. http://www. omg. org.

5. OMG. The Object Constraint Language Specification – Version 2. 0, for UML 2. 0, April 2004.

6. The Unified Modeling Language Infrastructure version 2. 0, OMG Final Adopted Specification. March 2005. 7.

Jouault F. , Kurtev I. Transforming Models with ATL Workshop in Model Transformation in Practice at the MoDELS

2005 Conference. Montego Bay, Jamaica, Oct 3, 2005

8. Akehurst D , Howells W. , McDonald-Maier K. Model Transformation Language. Workshop in Model

Transformation in Practice - MoDELS 2005 Conference, Jamaica, Oct 3, 2005

9. Lawley M. , Steel J. Practical Declarative Model Transformation with TefKat. Workshop in Model Transformation

in Practice - MoDELS 2005 Conference. Jamaica, Oct 3, 2005

10. Dimitrios Kolovos, Richard Paige and Fiona Polack. The Epsilon Object Language (EOL). In Proc. Model Driven

Architecture Foundations and Applications: 2nd European Conference, ECMDA-FA, vol 4066 of LNCS, pages 128–

142, Spain, June 2006.

11. Dimitrios Kolovos, Richard Paige and Fiona Polack. Merging Models with the Epsilon Merging Language

(EML). In Proceedings of MoDELS 2006 Conference, Session Model Integration. Genova, Italy, October 2006.

12. Anneke Kleppe. MCC: A Model Transformation Environment. A. Rensink and J. Warmer (Eds.): ECMDA-FA

2006, LNCS 4066, pp. 173 – 187, Bilbao, Spain, June 2006.

13. Pons C., Giandini R., Pérez G., et al. Precise Assistant for the Modeling Process in an Environment with

Refinement Orientation. "UML Modeling Languages and Applications: UML 2004 Satellite Activities, Revised

Selected Papers". LNCS #3297. Springer, 2004.

14. Giandini, R. , Pons, C. Un lenguaje para Transformación de Modelos basado en MOF y OCL. Actas de XXXII

CLEI 2006. Santiago, Chile. Agosto, 2006.

15. Czarnecki, Helsen. Feature-based survey of model transformation approaches.IBM System Journal,V45,N3, 2006

16. Bézivin J. et al. A canonical Scheme for Model Composition. A. Rensink and J. Warmer (Eds.) ECMDA-FA

2006, LNCS 4066, pp. 346 – 360, Bilbao, Spain, June 2006.

17. Lano K., Catalogue of Model Transformation. 2006, http://www.dcs.kcl.ac.uk/staff/kcl/tcat.pdf

18. Ullman J. Principles of Database System. Computer Science Press. 1980

19. Giandini, R, Pérez, G, Pons, C. A minimal OCL-based Profile for Model Transformation. VI Jornada

Iberoamericana de Ing. de Soft. e Ing. del Conocimiento JIISIC’07.Lima, Perú. Feb, 2007.


252

OOWS Suite: Un Entorno de desarrollo para

Aplicaciones Web basado en MDA1

Francisco Valverde1, Pedro Valderas

1, Joan Fons

1

1 Departamento de Sistemas Informáticos y Computación, Universidad Politécnica de

Valencia, Camino de Vera S/N, 46022 Valencia, España

{fvalverde, pvalderas, jjfons}@dsic.upv.es

Resumen En este trabajo, se introduce un entorno de desarrollo MDD para

aplicaciones Web: La OOWS Suite. Dicho entorno proporciona herramientas

que dan soporte al proceso de desarrollo del método OOWS permitiendo la ge-

neración automática de aplicaciones Web totalmente funcionales. Estas herra-

mientas son: (1) Un modelador basado en Eclipse que permite la edición visual

de modelos OOWS. (2) Un conjunto de transformaciones modelo-a-texto que

permiten generar de forma automática la interfaz Web de una aplicación a partir

de estos modelos. Para implementar dicha interfaz se ha desarrollado un fra-

mework que, siguiendo la filosofía de las Factorías de Software, reduce el nivel

de abstracción entre los modelos conceptuales y el código a generar facilitando

la definición de las transformaciones. (3) Una estrategia para integrar dichas

herramientas con OlivaNova, una herramienta comercial de generación de apli-

caciones tradicionales (no-Web) en ambientes transaccionales. Esta integración

nos permite delegar la generación de la lógica de negocio de una aplicación

Web en una herramienta altamente contrastada a nivel industrial

1 Introducción

El Desarrollo de Software Dirigido por Modelos (DSDM) comienza a proporcionar

resultados prometedores. Existen distintos indicadores que nos hacen ser optimistas

en cuanto a la evolución e implantación industrial de esta filosofía de desarrollo. Em-

pezando por el gran empuje que constituye MDA del OMG [1] y la reciente aparición

de las Fábricas de Software [2] impulsadas por Microsoft. Quizás uno de los aspectos

más esperanzadores es el desarrollo continuo de tecnologías y herramientas para la

construcción de herramientas CASE que dan soporte al DSDM como son el proyecto

Eclipse Modeling Project [3] y las DSL Tools [4] integradas en MS Visual Studio

2005. También invita al optimismo la proliferación de herramientas con un soporte

explícito al DSDM, como son ArcStyler [5], Together [6] o AndroMDA [7].

El mundo de la ingeniera Web no es ajeno a esta tendencia, y diversas aproximacio-

nes han ido apareciendo con el fin de proporcionar soporte para el desarrollo de apli-

caciones Web dirigido por modelos. Estas aproximaciones introducen modelos con-

ceptuales para capturar de forma abstracta los diferentes aspectos que definen una


TIN2004-03534 y cofinanciado por FEDER


253

aplicación Web. A partir de estos modelos proponen el uso de transformaciones mo-

delo-a-modelo o modelo-a-texto con el fin de obtener el código equivalente a la repre-

sentación abstracta de la aplicación Web que constituye el modelo. En este sentido,

hay que destacar aproximaciones como OOHDM [8], WebML [9], WSDM [10],

OOWS [11], UWE [12] u OOH [13] que son ampliamente aceptadas en el ámbito

científico de la ingeniería Web y que han sido probadas y validadas en el desarrollo

de diferentes aplicaciones. Además, algunas de ellas ya proporcionan herramientas

que dan soporte a su método, como son el caso de WebRatio (herramienta que da

soporte a WebML y que ha sido implantada a nivel industrial), ArgoUWE (UWE) o

VisualWade (OOH). Estas herramientas permiten la definición de modelos que captu-

ran los aspectos estructurales, navegacionales y de presentación de las aplicaciones

Web. Además, proporcionan soporte para la generación de código a partir estos mo-

delos. Sin embargo, aunque estas herramientas se encuentran en constante desarrollo,

los aspectos de comportamiento son actualmente soportados de forma parcial desde

un punto de vista de modelado conceptual. El comportamiento que ofrecen se centra

básicamente en operaciones CRUD2 ligadas a la base de datos y en operaciones arit-

méticas básicas, no permitiendo establecer pre/postcondiciones en las operaciones o

definir cambios complejos en el estado de los objetos.

En este trabajo, se introduce la OOWS Suite, un entorno de desarrollo para aplica-

ciones Web basado en el método de ingeniería Web OOWS. OOWS constituye una

extensión del método OO-Method [14] para dar soporte al modelado conceptual de

aplicaciones Web. En este contexto, el entorno de desarrollo OOWS Suite proporcio-

na herramientas que, basándose en una arquitectura MDA, permiten la creación de los

diferentes modelos OOWS/OO-Method y la generación automática de aplicaciones

Web. Con dicho fin, la OOWS Suite integra la herramienta industrial OlivaNova. Esta

herramienta comercial ha sido desarrollada por la empresa Care Technologies S.A.

[15] y permite generar de forma automática sistemas software completos a partir de

los modelos OO-Method. La OOWS Suite proporciona mecanismos que extienden la

funcionalidad de OlivaNova para soportar correctamente el modelado de aplicaciones

Web y la posterior generación de código. Estas extensiones constituyen la principal

aportación de este trabajo y son las siguientes:

1. Se ha desarrollado una herramienta de modelado basada en Eclipse que da soporte

a la definición de los modelos introducidos por OOWS: el modelo navegacional y

el modelo de presentación.

2. Se ha definido una estrategia basada en transformaciones modelo-a-texto que per-

mite generar código a partir de los modelos OOWS. El código generado está basa-

do en un framework de implementación de aplicaciones Web que reduce el nivel

de abstracción entre los modelos OOWS y el código a generar. Para ello, el fra-

mework proporciona constructores basados en conceptos abstractos del desarrollo

Web (como página, enlace, mecanismo de identificación, etc.).

3. Se han implementado mecanismos para la integración conservativa de las exten-

siones propuestas por OOWS con la herramienta comercial OlivaNova. Esta inte-

gración se realiza a dos niveles: (1) A nivel de modelado, permitiendo que, en

tiempo de modelado, la herramienta que da soporte a los modelos OOWS interac-

túe correctamente con los modelos OlivaNova, y (2) a nivel funcional, permitiendo

2 Create, Relationship, Update, Delete


254

la interoperabilidad, en tiempo de ejecución, entre la interfaz Web generada a partir

de los modelos OOWS y la lógica de negocio generada por OlivaNova.

El resto del trabajo se estructura como sigue: La sección 2 presenta brevemente el

proceso de desarrollo basado en OOWS/OO-Method al cual de soporte la OOWS

Suite. En la sección 3 se introduce la herramienta de modelado desarrollada para crear

modelos OOWS. En la sección 4 se detalla la estrategia seguida para la generación de

código a partir de estos modelos así como el framework de implementación y los

mecanismos para definir y asociar aspectos estéticos al código generado. En la sec-

ción 5 se introduce la integración de las extensiones propuestas por OOWS con la

herramienta comercial Olivanova. Por último, la sección 6 introduce las conclusiones

y líneas de trabajo futuras.

2 Proceso de desarrollo OOWS/OO-Method

La OOWS Suite proporciona soporte para el desarrollo de aplicaciones Web basándo-

se en el método de ingeniería Web OOWS. OOWS surge como una extensión para el

ámbito de las aplicaciones Web del método de producción de software orientado a

objetos OO-Method. OO-Method proporciona mecanismos para la generación de có-

digo a partir de modelos conceptuales. Basándose en una arquitectura MDA, este

método define un PIM en el cual se modelan tanto los aspectos estáticos como diná-

micos del sistema a través de tres vistas complementarias entre sí:

• Un Modelo Estructural, que define la estructura estática del sistema mediante la

definición de sus clases y las relaciones entre éstas. Este modelo se basa en el dia-

grama de clases UML.

• Un Modelo Dinámico, que describe la secuencia válida de estados en la vida de los

objetos pertenecientes a cada clase del sistema. Para ello se utiliza un Diagrama de

Transición de Estados UML. Además, también se describe la interacción entre ob-

jetos de diferentes clases mediante un Diagrama de Secuencia UML.

• Un Modelo Funcional, que especifica la semántica de cada cambio de estado en la

vida de un objeto definiendo el efecto de sus servicios. Para ello, se utiliza una es-

pecificación formal textual.

OO-Method ha sido implantado a nivel industrial mediante la herramienta OlivaNo-

va [16], la cual da soporte al método. OlivaNova proporciona un modelador que per-

mite la edición visual de los modelos OO-Method e implementa un motor de trans-

formación [17] que genera de forma automática y completa código en entornos tran-

saccionales (Java y .NET). Para ello, la herramienta transforma internamente el PIM

de OO-Method en el PSM correspondiente a la tecnología destino. A partir de este

PSM, genera código basado en una arquitectura de tres capas (presentación, lógica de

negocio y persistencia). La figura 1 muestra, en su parte izquierda, el proceso de desa-

rrollo de OO-Method.

OOWS introduce dos nuevos modelos en el proceso de desarrollo OO-Method, con

el fin de soportar correctamente las nuevas características enfatizadas en el desarrollo

de aplicaciones Web (navegación y presentación). Estos modelos son:


255

• El Modelo Navegacional, que define la estructura navegacional del sistema. Dicho

modelo se define a partir de un conjunto de grafos cuyos nodos (contextos navega-

cionales) representan vistas sobre el modelo estructural de OO-Method y cuyos ar-

cos representan enlaces de navegación entre los nodos. Cada una de las vista define

la información y funcionalidad que debe proporcionarse en los contextos navega-

cionales. Básicamente, un contexto navegacional representa a nivel conceptual una

de las páginas que definen la aplicación Web a nivel de implementación.

• El Modelo de Presentación, que especifica las propiedades que deben cumplir la

información mostrada. Para ello, se proponen un conjunto de patrones de presenta-

ción aplicables a las primitivas abstractas definidas en el modelo navegacional. Di-

chos patrones indican aspectos como la organización de la información (modo re-

gistro, tabular, maestro-detalle, etc), ordenación de la información, etc.

PIM

CÓ

DIG

O

OO-Method

PIM

-to-P

SM

-to-C

ode

MODELO DINÁMICO

MODELO FUNCIONAL

OLIVANOVA MODELLER

Clase Relación

Atributos

PSM+

Generador de Código

OLIVANOVA

TRANSFORMATION ENGINE

Aplicación

MODELO NAVEGACIONAL

MODELO DE PRESENTACIÓN

OOWS

Capa de Presentación

Capa de Lógica de Negocio

Capa de PersistenciaArquitectura de 3

capas

Framework

Interfaz Web

PROCESO DE TRADUCCIÓN

Mod

el D

riven

Arc

hite

ctur

e

+Generador de codigo

PIM

CÓ

DIG

OTra

nsf

orm

aci

ón A

uto

mátic

a

Compilador OOWS

Aplicación Web

Integración

MODELO ESTRUCTURAL

Editor Visual OOWS

Desarrollo de aplicaciones Web mediante OOWS Suite

Fig. 1. Proceso de desarrollo MDA

En este contexto, la herramienta que da soporte a OO-Method, OlivaNova, debe ser

extendida para permitir la creación de los nuevos modelos introducidos por OOWS

así como para considerar correctamente, en el proceso de generación de código, la

información definida en ellos. Como se ha comentado en la introducción, debido a

políticas comerciales de la empresa, dicha extensión debe realizarse de una forma

conservativa (sin modificar el producto OlivaNova) con el fin de asegurar que no

existen problemas de compatibilidad con las aplicaciones previamente desarrolladas.

Para lograr esta meta, se ha construido el entorno de desarrollo OOWS Suite. Dicho

entorno introduce una serie de herramientas que, basándose en OOWS, complemen-

tan conservativamente el proceso de desarrollo OO-Method con el fin de dar soporte


256

al desarrollo de aplicaciones Web. El nuevo proceso de desarrollo que define la

OOWS Suite se muestra en la Figura 1. La parte izquierda de esta figura representa el

proceso de desarrollo de OO-Method. La parte derecha representa las extensiones que

complementan este proceso y que dan soporte al desarrollo de aplicaciones Web. Así

pues, el proceso de desarrollo que soporta la OWS Suite se divide en tres etapas:

1. Modelado: Se construye el PIM que define los diferentes aspectos de una aplica-

ción Web. Los modelos OO-Method que capturan los aspectos estáticos y de com-

portamiento son definidos mediante el modelador de OlivaNova [16]. El modelo de

navegación y de presentación son definidos por la herramienta de modelado

OOWS. Dicha herramienta se presenta en la sección 3. La estrategia definida para

la interacción de ambas herramientas se explica con detalle en la sección 5.1

2. Generación de código: En esta etapa se llevan a cabo dos procesos de generación

de código paralelos. Por un lado, el motor de transformación de OlivaNova obtiene

código a partir de los modelos OO-Method mediante una transformación PIM-

PSM-Código. Información sobre esta transformación puede encontrase en [17]. Por

otro lado, un compilador de modelos OOWS genera una interfaz Web mediante

una transformación modelo-a-texto (lo que MDA denomina una transformación

automática). Dicha transformación se introduce en la sección 3.2.

3. Integración OOWS/OO-Method: La integración de la información capturada por

los modelos OO-Method con la información capturada por los modelos OOWS se

lleva a cabo a nivel de implementación. La interfaz Web generada a partir de los

modelos OOWS está basada en un framework que se encarga de interactuar con la

lógica de negocio de OlivaNova (.NET, Java etc.). Las diferentes primitivas que in-

troduce del framework, así como ejemplos de su uso se introducen en las secciones

4.1 y 4.3. La integración del framework con el código OO-Method se introduce en

la sección 5.2.

El proceso de desarrollo propuesto por la OOWS Suite permite implementar (si-

guiendo una arquitectura MDA) aplicaciones Web totalmente funcionales. Además,

extiende de forma conservativa la herramienta OlivaNova, ahorrándole a Care Tech-

nologies problemas de compatibilidad con proyectos ya desarrollados. A continua-

ción, se presentan cada una de las extensiones introducidas por la OOWS Suite.

3 Herramienta de modelado para los modelos OOWS

Para dar soporte a la creación de modelos OOWS, se ha desarrollado una herramienta

basada en la plataforma Eclipse Modelling. Dicha herramienta debe soportar dos

aspectos básicos:

• Creación y Persistencia de Modelos: Se deben proporcionar mecanismos que

faciliten la creación de modelos OOWS, respetando siempre su metamodelo, y la

serialización de los modelos en un lenguaje estándar. Para satisfacer estas necesi-

dades se han utilizado los componentes que proporciona el Eclipse Modelling

Framework (EMF) [18]. A partir de la definición en ECore (subconjunto del están-

dar MOF de la OMG) del metamodelo de OOWS, EMF nos proporciona la funcio-

nalidad necesaria para poder crear y modificar modelos conceptuales. Además,

EMF proporciona mecanismo para almacenar los modelos en el formato XMI, es-


257

tándar de la OMG para el intercambio de modelos conceptuales, abriendo la posi-

bilidad de interacción con otras herramientas de modelado externas.

• Edición visual de Modelos: Para facilitar la construcción de los modelos OOWS

se propone desarrollar una herramienta de edición visual de modelos similar a las

herramientas CASE industriales. Para esta tarea se ha utilizado el Eclipse Grap-

hical Modelling Framework (GMF). Este framework permite la generación auto-

mática de editores gráficos a partir de una especificación que asocie primitivas de

modelos Ecore a su representación gráfica o textual.

Fig. 2. OOWS Case Tool

En la figura 2 puede verse una captura de la herramienta desarrollada con el modelo

navegacional OOWS de la aplicación Web IMDB3 (la cual utilizaremos como caso de

estudio en el resto del articulo). La aplicación Web IMDB constituye la mayor fuente

de información cinematográfica de acceso público. En este sentido, en el modelo

navegacional de dicha aplicación se definen contextos navegacionales que proporcio-

nan información relacionada con el cine. Por ejemplo, el contexto TopMovies muestra

un ranking de las mejores películas valoradas por los usuarios y el contexto MovieIn-

formation proporciona información detallada sobre una película determinada.

4 Generación de código a partir de los modelos OOWS

La estrategia definida para generar código a partir de los modelos OOWS está basada

en un conjunto de transformaciones modelo-a-texto. Con el fin de facilitar la defini-

ción de estas transformaciones, se ha desarrollado un framework que reduce el gap

semántico entre los modelos OOWS y el código generado. Para ello, el framework

proporciona un conjunto de constructores de alto nivel de abstracción. Además, dicho

3 The Internet Movie Database, http://www.imdb.com


258

framework define una serie de mecanismos para incorporar los aspectos estéticos a

través de plantillas de presentación, totalmente independientes del código que imple-

menta la funcionalidad y la recuperación de información.

Así pues, en esta sección se introduce en primer lugar el framework desarrollado

para la implementación de aplicaciones Web. A continuación, se presentan las trans-

formaciones modelo-a-texto. Finalmente, se comentan los mecanismos proporciona-

dos por el framework para integrar aspectos estéticos.

4.1 Framework de implementación

El objetivo del framework de implementación es el de simplificar la definición de las

transformaciones de modelo a código. El lenguaje de implementación utilizado ha

sido PHP 5, al ser un lenguaje habitualmente utilizado para la creación de frameworks

en entornos Web como Zend Framework [19] o CakePHP [20]. El framework propor-

ciona constructores de alto nivel de abstracción para la implementación de páginas

Web. Dichos constructores se definen a partir de un conjunto de clases que represen-

tan conceptos habituales a la hora de construir aplicaciones Web como son página,

enlace, menú de navegación, etc. En este sentido, el framework define una aplicación

Web como un conjunto de objetos que especifican la información y funcionalidad que

la aplicación Web debe proporcionar. Los objetos principales que componen una a-

plicación Web son:

• Application: Este objeto, que es único en cada aplicación, contiene la información

global. Por ejemplo, a través del método Rol permite definir los tipos de usuarios

que pueden acceder a la aplicación o mediante la propiedad AllowAnonymous per-

mite autorizar el acceso anónimo. También es posible seleccionar los estilos de

presentación mediante el método DefaultStyle. Además, proporciona el método

AddPage para definir los objetos Page que compone nuestra aplicación.

• Page: Cada objeto Page permite implementar una página Web. Siguiendo criterios

de usabilidad definidos en [21], este objeto construye cada página Web como la

agregación de un conjunto de zonas de contenido. Las zonas de contenido más im-

portantes que permite definir este objeto son:

− Navegación: proporciona al usuario el conjunto de enlaces de navegación que puede activar dentro de la página en la que se encuentra.

− Información: recupera información del sistema para ser mostrada, generalmen-

te, desde la capa de persistencia.

− Entrada de datos: se encarga de proporcionar al usuario un formulario, en el

cual pueda introducir la información necesaria para la ejecución de un servicio.

− “Custom”: contiene información, generalmente independiente del dominio de

la aplicación, que no puede ser catalogada como por ejemplo banners.

El objeto Page proporciona primitivas para añadir estás zonas de contenido como

por ejemplo AddNavigationZone o AddInformationZone.

• Zone: Este objeto se encarga de especificar cada una de las zonas de contenido citadas anteriormente. Tomando como ejemplo la zona de información, proporcio-

na el método AddField para indicar los atributos van a ser recuperados y AddDetail

para mostrar información relacionada. También es posible definir mecanismos de


259

filtrado e indexación de la información, a través de las primitivas DefineFilter y

DefineIndex respectivamente.

La figura 3 muestra la implementación parcial de una página del caso de estudio.

Por último, comentar que para poder utilizar el framework, éste debe ser previamente

instalado en el servidor donde se encuentren las páginas Web de la aplicación. Cuan-

do el usuario realiza una petición de acceso a una página Web, el framework se en-

carga de crear el conjunto de objetos que forman la página Web solicitada (según la

definición del objeto Page correspondiente). Dichos objetos se encargan de producir

código XHTML que permite visualizar la página en el navegador Web del usuario.

Además, el framework proporciona constructores de alto nivel pero independientes

del método OOWS. Esto permite que el framework pueda ser utilizado como tecnolo-

gía destino por cualquier método de ingeniería Web.

Fig. 3. Ejemplo del código del framework

4.2 Proceso de generación de código

A la hora de abordar el proceso de transformación de un modelo a código existen

distintas alternativas. Desde la transformación basada en grafos como se muestra en

[22], pasando por el uso de lenguajes de plantillas [23] e incluso la aplicación de

transformaciones XSLT [24]. La opción que se ha escogido ha sido la de utilizar

openArchitectureWare (oAW) [25], un framework de herramientas de soporte al

DSDM. La gran ventaja de oAW respecto a otras soluciones se basa en el hecho de

estar basada en la plataforma Eclipse y por lo tanto, es posible integrar perfectamente

las herramientas que proporciona dentro de la OOWS Suite. Entre otras utilidades,

oAW proporciona el lenguaje xPand para la generación código a partir de modelos.

Este lenguaje, permite la definición de reglas que toman como entrada una primitiva


260

conceptual de un modelo. A partir de la información de dicho elemento se completa

una plantilla de código.

Para hacer posible el proceso de generación de código, se han definido las corres-

pondencias entre las primitivas conceptuales de OOWS y las primitivas del frame-

work. Todo elemento del metamodelo de OOWS tiene asociada una regla que esta-

blece el código del framework al cual se traduce. Tomemos como ejemplo, la primiti-

va conceptual “modelo navegacional” (descrita en la sección 2) junto con su regla

asociada, ModelNavigationRule (ver Figura 4). En primer lugar, esta regla añade el

usuario al cual pertenece el modelo navegacional a través de la primitiva Rol del obje-

to Application. A continuación para cada contexto se crea una nueva página Web a

través de la primitiva Page.

Fig. 4. Regla de transformación para el modelo navegacional

4.3 Definiendo los aspectos visuales de presentación

La OOWS Suite proporciona una estrategia para definir los aspectos estéticos basada

en plantillas de presentación., definidas mediante el lenguaje CSS. Se introducen dos

tipos de plantillas:

• Independientes del Dominio: los estilos de estas plantillas se definen a partir de las primitivas conceptuales de OOWS/OO-Method y los términos que introduce el fra-

mework. Estilos de este tipo son por ejemplo: InformationZone, AttributeName,

NavigationLink, etc. Este grupo de etiquetas define un conjunto de estilos genéri-

cos que pueden ser aplicados a cualquier aplicación generada mediante la OOWS

Suite.

• Dependientes del Dominio: a diferencia de las anteriores, sus estilos se definen a partir de conceptos propios del dominio de la aplicación a construir. Estilos de este

tipo son por ejemplo: MovieTitle, Director, Cast, etc. Estos estilos no son reutiliza-

bles.

La Figura 5A muestra la definición de dos estilos dependientes. Dichos estilos se

han definido específicamente para el caso de estudio IMDB. Definen las propiedades

estéticas que deben presentar el título de cada película .MovieInformation.MovieTitle)

así como el reparto de actores (.MovieInformation .Cast). Como vemos, estos estilos

están definidos a partir de conceptos propios de la aplicación IMDB y no pueden ser

utilizados en otras aplicaciones. La Figura 5B muestra la definición de tres estilos

independientes los cuales, definen las propiedades estéticas que deben cumplir la zona

de información de cada página (.InformationZone), el nombre de los atributos defini-

dos en las clases del modelo estructural (.AttributeName) y el valor de dichos atribu-

tos (.AttributeValue). Estos estilos, aunque también han sido utilizados en el caso de


261

estudio, son independientes de dominio y por tanto pueden ser utilizados en el desa-

rrollo de otras aplicaciones Web.

Fig. 5. Estilos dependientes e independientes de domino

El framework es el encargado de asociar los aspectos estéticos definidos en las plan-

tillas de presentación al código que implementa la aplicación Web. Para ello, la estra-

tegia seguida es la siguiente:

1. En primer lugar, los constructores del framework producen código XHTML sin

ningún tipo de formato predefinido. Sin embargo, dicho código esta marcado

mediante un conjunto de estilos independiente y dependientes. Los estilos inde-

pendientes han sido predefinidos e integrados directamente en el framework. Por

otra parte, los estilos dependientes son generados dinámicamente por los cons-

tructores del framework, a partir de la información de nuestros modelos.

2. Por otro lado, el framework proporciona el método DefaultStyle del objeto Ap-

plication, que nos permite introducir las plantillas de presentación que deben

asociarse al código XHTML. Por ejemplo, si asociamos la plantilla de presenta-

ción que define el look and feel de ImDB del siguiente modo:

$Application->DefaultStyle("IMDB");

El framework generará la siguiente línea de código XHTML cada vez que el

usuario acceda a una página de la aplicación Web:

<link rel="stylesheet" type="text/css" href="IMDB.css">

Esta estrategia basada en plantillas dependientes e independientes de dominio pre-

senta las siguientes ventajas:

• Adaptabilidad: Cambiar el “look and feel” de una aplicación resulta tan sencillo

como cambiar la plantilla del método DefaultStyle del objeto Application. La fi-

gura 6 presenta la visualización de una página Web del caso de estudio tras

haberle asociarlo dos plantillas de presentación diferentes.

• Reusabilidad: todas las aplicaciones Web desarrolladas mediante la OOWS Sui-

te están implementadas mediante código XHTML. Dicho código comparte en

cualquier desarrollo el marcado basado en los estilos de presentación indepen-

dientes de domino. En este contexto, las plantillas independientes de domino

pueden ser asociadas al código de cualquier aplicación Web.


262

Fig. 6. Una misma página Web con diferente “Look & Feel”

5 Integración OOWS/OO-Method

A fin de dar soporte a la generación automática de aplicaciones Web a nivel indus-

trial, los nuevos modelos introducidos por OOWS deben integrarse con los modelos

OO-Method proporcionados por la herramienta OlivaNova. Dicha integración debe

realizarse a dos niveles: En primer lugar, a nivel de modelado, permitiendo la correcta

interacción de los modelos OOWS basados en EMF con los modelos OO-Method de

OlivaNova. En segundo lugar, a nivel de generación de código, donde la funcionali-

dad generada por OlivaNova debe comunicarse con la interfaz Web generada a partir

de los modelos OOWS.

5.1 Integración a nivel de modelado

La definición de los modelos OOWS se realiza partiendo del modelo estructural de

OO-Method definido mediante el modelador de OlivaNova. Por ejemplo, para definir

la vista que constituye cada contexto navegacional es necesario conocer las clases

definidas en el modelo estructural. Así pues, la integración entre ambas herramientas

de modelado se llevará a cabo a través del modelo estructural OO-Method. Para ello,

se deben proporcionar dos tipos de mecanismos: (1) Mecanismos que faciliten a la

herramienta OlivaNova la exportación del modelo estructural y (2) mecanismos que

faciliten a la herramienta de modelado OOWS la importación del mismo modelo.

Los mecanismos para la exportación del modelo estructural ya vienen proporciona-

dos por la herramienta OlivaNova, ya que dicha herramienta almacena sus modelos

mediante el lenguaje estándar XML. Los mecanismos para la importación de este

modelo estructural deben ser implementados en la herramienta de modelado OOWS.

La solución adoptada para resolver este problema ha sido la siguiente (ver Figura 7):

• En primer lugar, se ha utilizado Ecore para definir el metamodelo del modelo es-

tructural. Ecore es un lenguaje definido a partir de un subconjunto de MOF para la


263

construcción de metamodelos. Además, es la base de EMF por lo que es fácilmente

integrable en la herramienta de modelado OOWS (la cual ha sido desarrollada tam-

bién mediante EMF, ver sección 3). Así pues, el metamodelo definido en Ecore se

introduce en dicha herramienta extendiendo el metamodelo de OOWS. Esto permi-

te que la herramienta soporte los diferentes conceptos abstractos que definen el

modelo estructural.

• A continuación, se ha definido una transformación de modelo-a-modelo que permi-

te transformar un modelo estructural de OlivaNova en un modelo estructural basa-

do en el metamodelo Ecore (almacenado en un documento XMI basado en XML).

Una vez realizada esta transformación, el modelo estructural Ecore (en el cual se

especifica la lógica de negocio de la aplicación Web) puede ser cargado en la

herramienta de modelado OOWS. Para definir la transformación se ha utilizado

una plantilla XSLT. Se ha optado por esta opción porque el modelo estructural

OlivaNova y el modelo estructural Ecore se almacenan como documentos XML.

XSLT nació con el fin de proporcionar precisamente transformaciones entre este

tipo de documentos.

Modelo Estructural

Olivanova (XML)

OlivaNova Modelador OOWS

Modelo Estructural Ecore (XMI)

TransformaciónM2M Metamodelo

OOWS

Metamodelo del Modelo EstructualBasado en Ecore

<<extiende>>XSLT

Paso 1Paso 2

Basado en

Fig. 7. Integración a nivel conceptual con OlivaNova

5.2 Integración a nivel funcional

A partir de los modelos OOWS se genera una interfaz Web implementada mediante el

framework introducido en la sección 4.1. Sin embargo, la lógica de negocio es gene-

rada por OlivaNova en una tecnología diferente a la que utiliza dicho framework. En

este sentido, es necesario definir un mecanismo para integrar la interfaz con la lógica

de negocio.

Para acotar el problema, nos hemos centrado en el código generado por OlivaNova

para la plataforma .NET, en donde la lógica de negocio se encapsula como un com-

ponente COM+. La comunicación de las interfaces con dicho componente se produce

mediante el envío de un mensaje XML con la consulta/servicio requerido y la recep-

ción de otro mensaje con la respuesta. Así pues, la interfaz Web implementada me-

diante el framework debe comunicarse con la lógica de negocio implementada por

OlivaNova a través de mensajes XML.

Para llevar a cabo este proceso de comunicación, se ha definido una fachada de

negocio denominada OlivaNovaFacade (ver Figura 8). Dicha fachada proporciona un


264

conjunto de métodos que pueden ser utilizados por el framework y que se encargan de

construir los mensajes XML adecuados. Los métodos más importantes son:

• QueryPopulation: devuelve la población relacionada de una clase determinada.

• QueryById: devuelve una única instancia de una clase a partir de su oid. • QueryRelated: a partir del oid de una instancia, devuelve todas las instancias de

una clase relacionadas.

• ExecuteService: a partir del identificador unívoco de un servicio tal y el conjunto de valores de los argumentos, ejecuta dicho servicio.

• GetServiceResponse: recupera el resultado o el error de la ejecución de un servicio.

Fig. 8. Integración con la funcionalidad generada con OlivaNova

6 Conclusiones

En este trabajo, se ha introducido la OOWS Suite, un entorno de desarrollo MDD

para aplicaciones Web. Dicho entorno proporciona herramientas que dan soporte al

proceso de desarrollo OOWS/OO-Method permitiendo la generación automática a

partir de modelos de aplicaciones Web totalmente funcionales. Dicha aplicaciones

Web están basadas en tres capas (presentación, lógica de negocio y persistencia).

Para el desarrollo de la capa de presentación (o interfaz Web), la OOWS Suite

proporciona una herramienta de modelado y un conjunto de transformaciones mode-

lo-a-texto que permiten la edición visual de los modelos introducidos por OOWS y la

posterior generación automática de código. Dicha herramientas han sido construidas a

partir de estándares MDA (XMI, MOF) y herramientas libres (EMF, oAW) de gran

aceptación dentro del ámbito del DSDM y con grandes posibilidades de evolución.

Por otro lado, el código generado por las transformaciones está basado en un fra-

mework de implementación que, siguiendo la filosofía de las Factorías de Software,

reduce el nivel de abstracción entre los modelos conceptuales y el código a generar,

facilitando la definición de las transformaciones. El framework también proporciona

mecanismos que facilitan la adaptación y reutilización de aspectos estéticos a través

de plantillas de presentación.

Para el desarrollo de las capas de lógica de negocio y persistencia, se ha definido

una estrategia para integrar la herramienta comercial que da soporte a OO-Method

(OlivaNova) en la OOWS Suite. Esta integración permite delegar la generación de la


265

lógica de negocio de una aplicación Web en una herramienta altamente contrastada a

nivel industrial. Además, extiende de forma conservativa la herramienta OlivaNova,

evitando que surjan problemas de compatibilidad con proyectos ya desarrollados.

Por ultimo, comentar que el proceso de desarrollo soportado por la OOWS Suite ha

sido validado en el desarrollo de aplicaciones Web reales como el sitio Web del de-

partamento de sistemas informáticos y computación (www.dsic.upv.es).

Referencias

[1] Object Management Group (OMG). www.omg.org.

[2] Greenfield, J., Short, K., Cook, S., Kent S. and Crupi, J., Software Factories: Assembling

Applications with Patterns, Models, Frameworks, and Tools, Wiley.

[3] Eclipse Modelling Project. www.eclipse.org/modeling/

[4] Microsoft DSL Tools. http://msdn2.microsoft.com/en-us/vstudio/aa718368.aspx.

[5] Arcstyler. www.interactive-objects.com/products/arcstyler

[6] Borland Together. www.borland.com/us/products/together/index.html

[7] AndroMDA. www.andromda.org

[8] Schwabe D., Rossi G., and Barbosa. S. Systematic Hypermedia Design with OOHDM. In

ACM Conference on Hypertext, Washington, USA, 1996.

[9] Ceri, S. Fraternali, P., Bongio, A., Brambilla M., Comai S., Matera M. (2003). Designing

Data-Intensive Web Applications.Morgan Kaufman

[10] O. De Troyer and S. Casteleyn. Modelling Complex Processes from web applications

using WSDM. In IWWOST 2003. Oviedo, Spain. 2003 pp 1-12.

[11] Fons J., Pelechano V., Albert M., and Pastor O. Development of Web Applications from

Web Enhanced Conceptual Schemas. In ER 2003, vol. 2813 of LNCS. Springer

[12] N. Koch. Software Engineering for Adaptive Hypermedia Applications. PhD thesis,

Ludwig-Maximilians-University, Munich, Germany, 2000.

[13] J. Gómez, C. Cachero, O. Pastor. Extending an Object-Oriented Conceptual Modelling

Approach to Web Application Design. June 2000. CAiSE'2000, LNCS 1789, Pags 79-93

[14] Pastor, O., Gomez, J., Insfran, E. and Pelechano, V. The OO-Method Approach for Infor-

mation Systems Modelling: From Object-Oriented Conceptual Modeling to Automated

Programming. Information Systems 26, pp 507–534 (2001)

[15] Care Technologies S.A. www.care-t.com

[16] OlivaNova Modeller. http://www.care-t.com/products/modeler.asp

[17] OlivaNova Transformation Engine. http://www.care-t.com/products/transengine.asp

[18] Budinsky, F., Steinberg, D., Merks, E., Ellersick, R. and Grose T.J., Eclipse Modelling

Framework: A developer’s guide, Addison-Wesley, 2004.

[19] Zend Framework. http://framework.zend.com/

[20] CakePHP. www.cakephp.org

[21] Olsina, L. Metodologia Cuantitativa para la Evaluacion y Comparacion de la Calidad de

Sitios Web. PhD thesis, Facultad de Ciencias Exactas de la Universidad Nacional de La

Plata (1999).

[22] Rozenberg G. (ed.).Handbook of Graph Grammars and Computing by Graph Trans-

formation. World Scientific, Singapore (1997)

[23] Muñoz, J. and Pelechano, V., Building a software factory for pervasive systems develop-

ment., in CAiSE, volume 3520 of Lecture Notes in Computer Science, pages 342–356,

Springer, 2005.

[24] Kovse, J. and Härder, T. Generic XMI-Based UML Model Transformations. 8th Interna-

tional Conference on Object-Oriented Information Systems, Montpellier, France, 2002.

[25] OpenArchitectureWare. www.openarchitectureware.org


266



267

Utilizando a Técnica i* para Modelar a Concepção de Vigotski visando auxiliar o Processo de Desenvolvimento

de Software Educacional para Pessoas com Deficiência Visual

Victor F. A. Santander 1,2, Dorisvaldo Rodrigues da Silva2, Andre Abe Vicente2, Jaelson Freire B. Castro3

1Universidad de Talca – Facultad de Ingeniería - Curicó Chile

[email protected] 2Universidade Estadual do Oeste do Paraná, Cascavel - PR Brazil

[email protected], [email protected] 3Universidade Federal de Pernambuco, Recife - PE Brazil

[email protected]

Resumo: Este trabalho trata da importância do estabelecimento de requisitos funcionais (RF), não-funcionais (RNF) e organizacionais no desenvolvimento de software educacional para pessoas com deficiência visual com intuito de apoiar a aprendizagem colaborativa. Visando facilitar a compreensão das necessidades específicas de pessoas com deficiência visual segundo a teoria de Vigotski, utilizamos inicialmente a técnica i* de modelagem organizacional para construir os modelos de dependências estratégicas e de razões estratégicas em um ambiente de aprendizagem colaborativa. A partir destes modelos, definimos um conjunto de requisitos organizacionais, funcionais e não-funcionais para um sistema computacional de apoio a educação de pessoas com deficiência visual. Os requisitos funcionais foram descritos através da técnica de Casos de Uso na UML. Obteve-se como resultado deste trabalho a elicitação, análise e negociação, modelagem e validação de 43 requisitos funcionais, 43 casos de uso e 11 requisitos não-funcionais, além do diagrama de casos de uso resultante.

Palavras chave: Aprendizagem colaborativa, deficiência visual, engenharia de requisitos, software educacional, modelagem organizacional.

1 Introdução

Historicamente, cada sociedade tem-se relacionado com a pessoa com deficiência de acordo com as suas concepções de homem, valores culturais e crenças. Iniciou-se pelo ato de abandono, da exterminação, da expiação com a prática da caridade, da segregação, do assistencialismo para a integração e, finalmente, para uma proposta de inclusão educativa e, conseqüentemente, social. Essas questões demonstram que tem ocorrido uma evolução nas relações entre a sociedade, dita normal, e as pessoas com deficiência.

Para compreender a relação social do deficiente no decorrer da história, é necessário conceber que o homem procura, primeiramente, satisfazer as suas necessidades básicas de sobrevivência, as quais necessariamente determinam o estabelecimento das relações sociais. Para atender esta premissa, incontestavelmente para qualquer sujeito com


269

deficiência ou não, estão postas as seguintes condições: a) as relações humanas estão voltadas para a satisfação de suas necessidades básicas, b) é necessário produz de meios para satisfazê-las e 3) estabelecer relações de exploração com a natureza.

Bianchetti e Freire [2] afirmam que o “organismo humano é capaz de aplicar o equipamento que possui por constituição a uma ampla escala de atividades, que estão em constante variação”. Assim, uma parcela significativa de pessoas necessita de condições especiais para ter acesso ao sistema formal de educação e ao mercado de trabalho. São as pessoas com deficiência.

Neste contexto, Vigotski [28] apresenta uma série de conceitos que auxiliam o entendimento do universo relacionado a pessoa com deficiência e a dependência do mesmo em relação ao processo de aprendizagem colaborativa [9]. Para entender melhor os conceitos apresentados por Vigotski, neste trabalho utilizamos a técnica i* [29]. A modelagem apresentada facilitará o entendimento do relato do processo adotado na obtenção de requisitos a serem considerados no desenvolvimento de software educacional destinado ao usuário em questão. As características e especificidades destes usuários tornam mais crítico o processo de elicitação, análise e documentação de requisitos, estabelecendo-o como ponto fundamental para o sucesso no desenvolvimento deste tipo de software. Estas questões evidenciam a necessidade de estabelecer requisitos que possam contribuir no processo de aprendizagem colaborativa destes usuários.

O presente artigo está estruturado da seguinte forma: Na seção 2, aborda-se os conceitos relacionados a cegueira e a visão reduzida, bem como apresenta-se um breve relato sobre aspectos relacionados a inclusão educacional. Estas especificidades reforçam a necessidade de estabelecer adequadamente um conjunto de requisitos para o desenvolvimento de software educacional para estes tipos de usuários. A seção 3 trata da utilização da técnica i* para compreender a concepção da pessoa com deficiência na perspectiva teórica de Vigotski, a qual permite modelar e demonstrar as dependências existentes entre os diferentes atores envolvidos no processo da aprendizagem colaborativa. Na seção 4 apresenta-se aspectos relacionados a aprendizagem colaborativa promovida por meio de recursos de informática, os quais têm por finalidade dar suporte a prática docente no processo de ensino-aprendizagem de pessoas com deficiência visual. A seção 5 trata de estudos realizados para estabelecer um conjunto de requisitos segundo as necessidades das pessoas cegas e das pessoas com visão reduzida, utilizando principalmente de técnicas relacionadas ao processo de engenharia de requisitos, bem como apresenta-se um conjunto de requisitos elicitados e modelados através das técnicas de Caso de Uso em UML. Na seção 6 apresenta-se o processo de validação dos requisitos e na seção 7 faz-se as considerações finais.

2 Conceituando cegueira e visão reduzida

Segundo Bruno [10], a cegueira caracteriza-se pela ausência total de visão até a perda da projeção de luz, sendo que o processo de aprendizagem, neste caso, ocorrerá por meio da integração dos sentidos tátil – cinestésico – auditivo – olfativo – gustativo. Para a pessoa cega o sistema braile é o principal meio de leitura e escrita. Nos primeiros anos de vida escolar da criança cega o sistema braille é importantíssimo porque facilita a alfabetização e permite a ela escrever de forma correta a ortografia das palavras. Em termos pedagógicos, a pessoa com visão reduzida é identificada como sendo àquela que lê tipos impressos ampliados ou se utiliza de auxílio de potentes recursos ópticos, sendo que o processo educacional ocorrerá por meio de leitura, escrita e as atividades diárias se


270

desenvolverão de acordo com as possibilidades do uso do resíduo visual existente na pessoa, além do auxílio de recursos ópticos específicos. A avaliação da visão subnormal, reduzida ou baixa visão deve ser feita mediante dois procedimentos, sendo um a avaliação clínico-funcional realizada por médico oftalmologista e o outro a avaliação funcional feita por pedagogo, devendo ambos serem especializados em visão subnormal. A avaliação clínica consiste em: diagnóstico e prognóstico, avaliação da acuidade visual para perto e longe, avaliação do campo visual, avaliação da sensibilidade aos contrates e visão de cores, prescrição e orientação de recursos ópticos especiais. Em face disto, é necessário ressaltar que a elaboração de requisitos para o desenvolvimento de software educacional para atender o aluno cego ou com visão reduzida, deve ser realizada considerando tanto os aspectos da avaliação clínica como os da avaliação funcional.

2.1 Aspectos relacionados a inclusão educacional

O discorrer sobre inclusão educacional pressupõe o oposto, a exclusão educacional, a qual perpassa pela exclusão social. Isto demonstra que a inclusão deve ser vista e analisada no contexto e na dimensão social em que ela ocorre. Vê-se que a inclusão educacional é uma das faces da inclusão social [20]. Esta é uma reflexão importante mais não será discutida e nem analisada neste artigo.

Ao analisar a questão da exclusão educacional, no sentido de estar fora do processo, constata-se que isso também passa pela preparação e comprometimento do professor em atender e propiciar condições adequadas para promover a aprendizagem do aluno com deficiência. Dessa forma, as produções de materiais didáticos devem ser somadas a adequação do espaço físico, a preparação do professor e dos alunos para receber o aluno com deficiência para, efetivamente, promover o desenvolvimento de suas potencialidades no ambiente escolar. Compreender que um aluno com deficiência visual não possui atraso de sua capacidade cognitiva em decorrência da cegueira é fundamental para estimular as suas potencialidades em termos de aprendizagem. Os recursos pedagógicos contribuem neste processo. Para o caso específico da deficiência visual é necessário construir processos alternativos que transmitam a informação e o conhecimento por vias que não sejam necessariamente a visão. Um destes recursos é o software educacional. Entretanto, para usá-lo como recurso é preciso que o mesmo possa ser desenvolvido utilizando requisitos básicos capazes de atender as especificidades de usuários com algum tipo de deficiência.

3 Utilizando a Técnica i* para compreender a concepção da pessoa com deficiência na perspectiva teórica de Vigotski

É importante fazer uma breve descrição da técnica i* antes de apresentar o modelo que representa a concepção da pessoa com deficiência na perspectiva teórica de Vigotski [28]. A técnica i* objetiva possibilitar a representação/modelagem de aspectos organizacionais envolvidos com processos [29]. Basicamente, permite descrever aspectos de intencionalidade e motivações envolvendo atores em um ambiente organizacional. Do ponto de vista da Engenharia de Requisitos, i* auxilia na compreensão do ambiente organizacional (incluindo potenciais sistemas de software), bem como permite explorar propostas alternativas de sistemas mostrando como o ambiente de trabalho, envolvendo atores da organização (processos de negócio), seria


271

afetado e modificado para atender e suportar a implantação de alguma proposta alternativa. Assim, i* pode auxiliar na importante tarefa atribuída a engenheiros de requisitos, que é a de avaliar os impactos que a introdução de novos sistemas podem causar nos participantes (atores) da organização, como também nos clientes destas organizações. Basicamente, esta técnica provê uma compreensão das razões (“Porquês”) que estão associadas aos requisitos de software. Para descrever o ambiente organizacional, i* propõe dois modelos: O Modelo de Dependências Estratégicas (SD) e o Modelo de Razões Estratégicas (SR). Neste artigo exploraremos o uso do Modelo de Dependências Estratégicas e o Modelo de Razões Estratégicas. O Modelo de Dependências Estratégicas é composto por nós e ligações. Os nós representam os atores no ambiente e as ligações são as dependências entre os atores. Por ator entende-se uma entidade que realiza ações para obter objetivos no contexto do ambiente organizacional. Atores dependem uns dos outros para obter objetivos. O ator que depende de alguma forma de outro ator é chamado de Depender e o ator que atende e satisfaz o Depender é denominado de Dependee. O objeto ou elemento de dependência entre Depender e Dependee é denominado de Dependum. Portanto, haverá relacionamentos do tipo Depender → Dependum → Dependee. As dependências apresentadas neste modelo podem ser de diferentes tipos, tendo como base o tipo do Dependum. Existem quatro tipos de dependências propostos em i* conforme segue: objetivo, tarefa, recurso e objetivo-soft. Na dependência de objetivo o Depender depende do Dependee para modificar um estado do mundo. O Dependee tem como papel satisfazer/alcançar um objetivo para o Depender. Na dependência de tarefa o Depender depende do Dependee para executar uma atividade, sendo de responsabilidade do Depender mostrar o caminho como isto será feito. No entanto, não é fornecido para o Dependee “o porquê” da realização da tarefa. Na dependência de recurso o Depender depende do Dependee em relação à disponibilidade de um recurso, seja ele físico ou de informação. Isto significa que o Dependee deve fornecer um recurso que o Depender necessita para realizar outras atividades no ambiente organizacional. Na dependência de objetivo-soft define-se objetivo-soft como um objetivo cuja avaliação de realização é bastante subjetiva e o seu significado não é claramente conhecido. Geralmente, o entendimento e avaliação do objetivo-soft acontecem ao longo do processo da realização de tarefas associadas com o objetivo-soft. Estes objetivos-soft são também referenciados como requisitos não-funcionais no contexto da Engenharia de Requisitos.

Na figura 1 apresentamos as notações gráficas utilizadas na técnica i* para representar atores e dependências entre os mesmos. Tendo como base estes elementos definidos para o modelo de dependências estratégicas, tanto as intenções quanto motivações e objetivos organizacionais podem ser modelados e várias alternativas para o desenvolvimento de sistemas computacionais podem ser avaliadas, optando-se por aquela que melhor satisfaça os objetivos de todos os stakeholders.

Fig. 1. Notações gráficas utilizadas na técnica i*


272

Após esta breve descrição da técnica i*, apresentamos na figura 2 o modelo de dependências estratégicas para um ambiente de aprendizagem colaborativa envolvendo as pessoas com deficiência visual.

O diagrama apresentado na figura 2 tem por finalidade permitir a visualização das relações de dependências existentes entre os atores: aluno cego, aluno com visão reduzida, aluno vidente, professor, escola/universidade e o software para deficientes visuais. Cabe ressaltar que os atores “aluno cego” e “aluno com visão reduzida” são visualizados como tipos de “Aluno com Deficiência Visual”. Esta relação é expressa em i* através do relacionamento ISA. Observa-se que as dependências “mudar a cor da fonte” e “mudar a cor da tela”, “imprimir texto no formato adequado”, “Ampliar tamanho da fonte na leitura de texto” são objetivos específicos do ator “aluno com visão reduzida” em relação ao ator “software para deficientes visuais”. Já as dependências “ler textos utilizando o retorno sonoro”, “Obter resposta sonora para todas as ações”, são metas fundamentais que devem ser satisfeitas pelo software para deficientes visuais, objetivando viabilizar o uso do computador pelo ator “aluno com deficiência visual”. Finalmente visualiza-se o objetivo “testar teclado” que é uma meta que deve ser satisfeita pelo software para deficientes visuais, objetivando o teste do teclado por parte do ator “Aluno cego”.

Fig. 2. Modelo de dependências estratégicas elaborado para um ambiente de aprendizado


273

O diagrama apresenta também as relações de dependências do tipo objetivo “interação com o entorno”, “superar a conseqüência social do defeito” e alcançar “desenvolvimento cognitivo e psicológico”, entre “aluno com deficiência visual” e os atores “aluno vidente”, “escola/universidade” e “professor” que expressam, segundo Vigotski, que a pessoa com deficiência necessita de outros atores sociais para alcançar estas metas consideradas essenciais para o seu desenvolvimento. As dependências do tipo objetivo “tratamento igualitário nas atividades escolares” e “acessibilidade ao material e ao espaço da escola” entre o ator “aluno com deficiência visual” e “aluno vidente” e “escola/universidade” expressam dependências existentes do deficiente visual em relação aos procedimentos adotados tanto da escola quanto do professor que possibilitarão um tratamento e acesso igualitário do mesmo na realização das diversas atividades escolares.

Na figura 3, visando obter uma maior aprofundamento no entendimento deste ambiente, realizamos a construção modelo de razões estratégicas no qual expressamos os meios, formas, alternativas que os atores que desempenham um papel de dependee nos relacionamentos consideram na satisfação de suas dependências. Nesta figura podemos observar que a dependência do tipo objetivo Ampliar tamanho da fonte ou figura na leitura de texto entre o aluno com visão reduzida e o software para deficientes visuais é satisfeito internamente pelo ator software através da tarefa Ampliar tamanho da fonte, a qual é decomposta nas sub-tarefas Aluno seleciona o texto ou figura a ser ampliado, Sistema altera a fonte ou figura conforme definido pelo aluno e pelo objetivo Aluno define o tamanho da fonte ou figura. Este último objetivo possui dois meios para ser satisfeito. Esta situação é expressa através do uso do mecanismo meio-fim entre Utilizar tecla de atalho pré-definida, Digitar tamanho da fonte ou figura e o objetivo Aluno define o tamanho da fonte ou figura representando que o aluno pode redefinir o tamanho da fonte ou figura de duas formas: através do uso de teclas de atalho pré-definidas ou digitando o tamanho desejado da fonte ou figura.

Assim, para levar a cabo a obtenção do objetivo Ampliar tamanho da fonte ou figura na leitura de texto é necessário que as três atividades já mencionadas sejam realizadas. Da mesma forma, verificamos que a dependência do tipo objetivo Mudar a cor da fonte entre o aluno com visão reduzida e o software para deficientes visuais é satisfeito internamente pelo ator software através da tarefa Mudar a cor da fonte, a qual é decomposta nas sub-tarefas Aluno seleciona o texto cuja cor será alterada, Aluno escolhe a cor existente na palheta de cores e Sistema realiza alteração da cor da fonte. Estas três sub-tarefas devem ser realizadas para que o objetivo Mudar a cor da fonte seja satisfeito. Podemos também visualizar na figura 6 que a dependência do tipo objetivo Mudar a cor da tela entre o aluno com visão reduzida e o software para deficientes visuais é satisfeito internamente pelo ator software através da tarefa Mudar a cor da tela a qual é decomposta nas sub-tarefas Aluno escolhe a cor existente na palheta de cores e Sistema realiza a alteração da cor da tela. Estas duas sub-tarefas devem ser realizadas para que o objetivo Mudar a cor da tela seja satisfeito. A dependência do tipo objetivo Imprimir textos no formato adequado entre o aluno com visão reduzida e o software para deficientes visuais é satisfeito internamente pelo ator software através da tarefa Imprimir textos no formato adequado, a qual é decomposta nas sub-tarefas Aluno abre arquivo a ser impresso, Aluno define formato adequado, Aluno envia arquivo para impressão e O sistema imprime o texto no formato especificado. Estas quatro sub-tarefas devem ser realizadas para que o objetivo Imprimir textos no formato adequado seja satisfeito.


274

Fig. 3 Modelo de dependências estratégicas elaborado para um ambiente de aprendizado Na figura 3 também podemos observar a dependência do tipo objetivo Ler textos utilizando retorno sonoro entre o ator aluno com deficiência visual e ator software para deficientes visuais. Esta dependência é satisfeita internamente pelo software através da tarefa Ler texto utilizando resposta sonora, a qual é decomposta nas sub-tarefas Aluno abre o arquivo para leitura e O sistema inicia a leitura do texto de forma sonora, bem como pelo objetivo Aluno seleciona o texto a ser lido. O objetivo Aluno seleciona o texto a ser lido pode ser levado a cabo por três meios os quais são Leitura do texto completo, Leitura do texto por parágrafo e Leitura do texto por linha. O mecanismo meio-fim é utilizado para relacionar estas três atividades à obtenção do objetivo Aluno seleciona o texto a ser lido. A outra dependência do tipo objetivo Obter Resposta sonora para todas as ações entre o ator aluno com deficiência visual e o ator o software para deficientes visuais é satisfeita internamente pelo software através da tarefa Emitir resposta sonora, a qual é decomposta nas sub-tarefas Aluno realiza uma ação no teclado, Sistema identifica a ação realizada e O sistema emite a resposta sonora de acordo com a ação. Estas três sub-tarefas devem ser realizadas para que o objetivo Obter Resposta sonora para todas as ações seja satisfeito. Finalmente, a dependência do tipo objetivo Testar teclado entre o ator Aluno Cego e o ator software para deficientes visuais é satisfeita internamente pelo software através da tarefa Testar teclado a qual é decomposta nas sub-tarefas Aluno Aciona qualquer tecla do teclado e Sistema emite


275

mensagem sonora de acordo com a tecla acionada. Estas duas sub-tarefas devem ser realizadas para que o objetivo Testar teclado seja satisfeito.

4 Aprendizagem colaborativa promovida por meio de recursos de informática aplicados a educação de pessoas com deficiência visual.

Há evidências que grupos cooperativos atingem níveis mais avançados de pensamento, retendo a informação por mais tempo que os alunos que trabalham individualmente. Neste aspecto, se houver recursos tecnológicos capazes de propiciar o acesso ao conteúdo sistematizado pela escola ao aluno com deficiência visual, isto possibilitará que este possa estar em igualdade de condições com as demais crianças para participar do próprio processo educacional, inclusive em termos de estar experienciando o processo de aprendizagem colaborativa, no ambiente de sala de aula.

Desta forma, necessariamente os recursos relacionados à informática deverão atender, minimamente, os requisitos que sejam capazes de propiciar interação com a máquina, tanto ao aluno cego quanto ao aluno com visão reduzida. Além disso, deve dar condições a ambos de acessar os conteúdos disponíveis, quer estejam na internet ou em softwares educacionais. O tópico a seguir trata dos estudos realizados para estabelecer um conjunto de requisitos funcionais e não-funcionais para atender as necessidades da pessoa com deficiência.

5. Estudos para estabelecer um conjunto de requisitos segundo as necessidades das pessoas cegas e das pessoas com visão reduzida

Segundo Sommerville [24], as atividades do processo de engenharia de requisitos são essenciais para garantir que o software desenvolvido satisfaça os requisitos dos usuários/clientes. Neste processo é fundamental compreender que erros produzidos no inicio destas atividades e descobertos em estágios posteriores do desenvolvimento causam freqüentemente custos elevados de correção [7] [8].

Para iniciar efetivamente o desenvolvimento de um determinado software é necessário ter estabelecido todos os aspectos que servirão de base para o processo de engenharia de requisitos [15] [18] [24]. Nesta pesquisa especificamente as entradas tomadas como base para o processo de engenharia de requisitos foram os documentos de domínio vinculados as necessidades especiais dos deficientes visuais, as recomendações das Conferências Mundiais de Jontien – Tailândia [27], de Salamanca – Espanha [5], de Tessalônica – Grécia [6], a Constituição Federal do Brasil [4], as teorias de aprendizagem [21] [23] [17], o estudo da defectologia [22] [28] e o estudo da tiflotecnologia [19]. A partir da base teórica realizada a luz da revisão da literatura, fez-se contato com a Associação Cascavelense de Deficientes Visuais 1[1], explicando quais os objetivos da pesquisa. Com os membros da Diretoria dessa entidade foram agendadas quatro reuniões de trabalho com duração de duas horas cada, bem como com um grupo de (10 a 15) pessoas cegas e com visão reduzida para discutir os requisitos para o desenvolvimento de software educacional. Os aspectos relacionados a questão

1 Associação Cascavelense de Deficientes Visuais possui 450 sócios em diferentes níveis de escolaridade, sendo que em torno de 10% utilizam o computador para atividades relacionadas a educação e ao trabalho.


276

pedagógica foram analisadas por pedagogos cegos e pedagogos com visão reduzida que faziam parte do grupo definido pela ACADEVI [1].

Todas as fases do processo de engenharia de requisitos (elicitação, análise e negociação, especificação, modelagem e validação) foram consideradas imprescindíveis para obter um conjunto de requisitos capazes de atender adequadamente as especificidades de aluno cego ou com visão reduzida. Foi utilizada a técnica de casos de uso para modelar os requisitos funcionais do sistema, considerando inicialmente os modelos de dependências estratégicas e de razões estratégicas descritos na figuras 2 e 3. Cabe ressaltar que a técnica de casos de uso na UML tem-se mostrado bastante efetiva no processo de desenvolvimento. Está técnica é a chave na maioria dos processos de desenvolvimento orientados a objetos, tais como Rational Unified Process – RUP [16] e Catalysis [12]. Segundo Booch et.al. [3] os casos de uso na Linguagem de Modelagem Unificada (UML) são utilizados para descrever o uso de um sistema por atores, sendo realizado neste caso a descrição de uma seqüência de passos e operações que um usuário deve executar para interagir com o sistema no intuito de realizar uma tarefa ou alcançar um objetivo. Cabe ressaltar também que em Santander [25] apresenta-se uma proposta para derivar casos de uso a partir de modelos em i*. Este trabalho também auxiliou-nos no processo de descoberta e descrição dos casos de uso para o software educacional para pessoas com deficiência visual.

Assim, observou-se que devido as especificidades desses usuários (ator cego e ator com visão reduzida), foi fundamental definir os casos de uso com a participação e colaboração dos mesmos, evitando assim o re-trabalho no processo de engenharia de requisitos. Esta condição também permitiu ao engenheiro de requisitos maior compreensão das necessidades deste tipo de usuário, o que contribui decisivamente na qualidade do produto a ser desenvolvido. A seguir, apresenta-se na figura 4 uma descrição de um subconjunto de casos de uso, de um total de 43, descobertos após a análise dos modelos descritos nas figuras 2 e 3, bem como através das diversas interações com os stakeholders envolvidos.

Caso de Uso 1: Ampliar tamanho da fonte ou figura na leitura do texto Objetivo: O aluno com visão reduzida deseja ampliar o tamanho da fonte ou figura para melhor leitura Atores: aluno com visão reduzida. Pré-condições: Arquivo a ser manipulado já aberto Condição final de Sucesso: fonte ou figura ampliada Cenário Principal: 1. O caso de uso inicia quando o aluno seleciona o texto ou figura a ser ampliado; 2. O aluno define o tamanho da fonte ou figura através do uso de uma tecla pré-definida; 3. O sistema altera a fonte ou figura conforme definido pelo aluno; Extensões 2a) O aluno define o tamanho da fonte ou figura digitando o tamanho da fonte ou figura desejado. Caso de Uso 2: Mudar a cor da fonte Objetivo: O aluno com visão reduzida deseja modificar a cor da fonte no texto Atores: aluno com visão reduzida. Pré-condições: Arquivo a ser manipulado já aberto Condição final de Sucesso: Cor da fonte alterada Cenário Principal: 1. O caso de uso inicia quando o aluno com visão reduzida seleciona o texto cuja cor será alterada; 2. O aluno com visão reduzida escolhe a cor existente na palheta de cores; 3. O sistema realiza a alteração da cor da fonte no texto


277

Caso de Uso 3: Mudar a cor da tela Objetivo: O aluno com visão reduzida deseja modificar a cor da tela para uma melhor visualização Atores: aluno com visão reduzida. Pré-condições: Condição final de Sucesso: Cor da tela alterada Cenário Principal 1. O caso de uso inicia quando o aluno com visão reduzida escolhe a cor existente na palheta de cores visando mudar a cor da tela atual; 2. O sistema realiza a alteração da cor da tela. Caso de Uso 4: Ler texto utilizando resposta sonora Objetivo: O aluno com visão reduzida ou cego deseja realizar a leitura de um texto através de resposta sonora. Atores: Aluno com visão reduzida e aluno cego. Pré-condições: Condição final de Sucesso: Texto lido com retorno sonoro Cenário Principal: 1. O caso de uso inicia quando o aluno com visão reduzida ou aluno cego abre o arquivo para leitura; 2. O aluno com visão reduzida ou cego seleciona o texto completo a ser lido; 3. O sistema inicia a leitura do texto de forma sonora. Extensões: 2a) o aluno seleciona a leitura do texto por parágrafo; 2b) o aluno seleciona a leitura do texto por linha; 3a) o aluno pode interromper a leitura em qualquer momento apertando uma tecla. Caso de Uso 5: Imprimir textos no formato adequado Objetivo: O aluno com visão reduzida deseja imprimir um texto no tamanho e cor especificados. Atores: Aluno com visão reduzida. Pré-condições: Condição final de Sucesso: Texto impresso no formato adequado Cenário Principal: 1.O aluno com visão reduzida abre o arquivo a ser impresso; 2.O aluno com visão reduzida define o formato de impressão no que tange a cor e tamanho; 3.O aluno com visão reduzida solicita a impressão; 4.O sistema imprime o texto no formato especificado Caso de Uso 6: Obter resposta sonora para todas as ações Objetivo: O aluno com visão reduzida ou cego deseja obter retorno sonoro para qualquer ação no sistema. Atores: Aluno com visão reduzida e aluno cego Pré-condições: Condição final de Sucesso: Retorno sonoro para qualquer ação Cenário Principal: 1.O aluno com visão reduzida ou cego realiza uma ação no teclado; 2.O sistema identifica a ação realizada; 3.O sistema emite resposta sonora de acordo com a ação Caso de Uso 7: Testar o teclado Objetivo: O aluno cego deseja testar o teclado. Atores: Aluno cego. Pré-condições: Software ativado. Condição final de sucesso: Realização de teste do teclado pelo aluno cego. Cenário principal: 1. O caso de uso inicia quando o aluno cego aciona qualquer tecla do teclado. 2. O sistema emite através do sintetizador a mensagem sonora correspondente a tecla acionada.


278

Extensões: Dependendo do domínio do software deverá usar gravação em voz humana.

Fig. 4. Subconjunto dos casos de uso descritos para um sistema computacional que atende aos requisitos de deficientes visuais em um processo de aprendizagem colaborativa.

Na figura 5, apresentamos uma versão reduzida do diagrama de (43) casos de uso para o software educacional para pessoas com deficiência visual. Este diagrama considera os casos de uso descobertos a partir dos modelos organizacionais descritos nas figuras 2 e 3. Cabe ressaltar que os atores aluno cego e aluno com visão reduzida herdam todos os casos de uso associados ao ator aluno com deficiência visual. Estes atores foram relacionados via mecanismo de generalização.

Os diagramas de casos de uso são importantes por representar as funcionalidades do sistema a partir do ponto de vista do aluno cego e do aluno com visão reduzida, mostrando também os tipos de relacionamentos existentes entre os casos de uso. O diagrama de casos de uso completo pode ser obtido em [13].

6. Validação de requisitos com o uso das técnicas de revisão e prototipação.

A atividade de validação foi realizada para verificar se os requisitos apresentados no documento atendiam todas as necessidades e aspectos que os usuários desejariam do software pretendido. Para realizar esta atividade de validação utilizou-se as técnicas de revisão e prototipação. A técnica de revisão consiste em revisar os requisitos, utilizando-se de um grupo de pessoas que analisam, discutem e apontam os melhores caminhos para solucionar os problemas encontrados durante o processo de elicitação, análise e negociação e especificação. Nesta revisão foram ajustados os termos que causavam conflitos e ambigüidade nas descrições dos requisitos e casos de uso , sendo que, ao final desta fase foi gerado um documento contendo um conjunto de 43 requisitos funcionais, 43 casos de uso e 11 requisitos não-funcionais, os quais foram validados pelos usuários cegos e pelos usuários com visão reduzida, membros da Acadevi. Já, a técnica de prototipação consiste no desenvolvimento de um protótipo. Neste trabalho foi desenvolvido um protótipo para validar alguns casos de uso considerados críticos pelos usuários. Foram validados por meio do protótipo desenvolvido os seguintes casos de uso: Caso de Uso 1: Ampliar tamanho da fonte ou figura na leitura do texto, Caso de Uso 2: Mudar a cor da fonte, Caso de Uso 3: Mudar a cor da tela e Caso de Uso 6: Obter resposta sonora para todas as ações. Para avaliar os casos de uso: Caso de uso 1 - Ampliar tamanho da fonte ou figura na leitura do texto, Caso de uso 2 - Mudar a cor da tela e Caso de uso 3 – Mudar a cor da tela desenvolveu-se uma tela com estas condições de uso. Ao ser ativado o software estes requisitos aparecem, e, são os responsáveis pelas possibilidades de criar contrastes adequados entre fonte e tela, ao usuário com visão reduzida. Foram realizados testes com diversos usuários com visão reduzida para identificar as melhores opções de cores para os contrastes (tela/letra). Após realização dos testes, conclui-se que a escolha das cores pelos usuários era algo muito pessoal e subjetiva, pois, usuários com a mesma patologia visual emitiam respostas totalmente diferentes, dificultando assim a definição das cores (fonte/tela). Constatada esta condição, definiu-se que este requisito seria atendido com a disponibilização de uma


279

palheta de 16 cores, já existente no Windows, e que a mesma seria localizada no rodapé da página do software. Estes requisitos foram validados com o uso do protótipo, conforme demonstram as figuras 6 e 7.

Fig. 5. Diagrama de Casos de Uso Parcial do software educacional para pessoas com deficiência visual.

Fig. 6. Telas do protótipo com tamanho de letras, cor das letras e cor de tela padrão

Para o caso específico do Caso de Uso 6: Obter resposta sonora para todas as ações a

ser emitida pelo software, realizou-se, por meio do protótipo, a validação utilizando o “sintetizador de voz” e a gravação em voz humana. Neste caso, as duas opções foram consideradas válidas pelos usuários. Entretanto, ressaltaram que a voz humana é de melhor qualidade, sendo mais agradável para ouvir. Salientaram também que dependendo do usuário e do domínio de aplicação do software, a mensagem sonora deve ser gravada em voz humana, principalmente quando o aplicativo desenvolvido for destinado às crianças.

Fig. 7. Tela do protótipo com tamanho de letras, cor das letras e cor de tela alterados, criando um contraste.


280

7. Considerações Finais

Cabe ressaltar que parte deste trabalho é uma evolução de Santander&Silva [26]. Neste artigo, apresentamos inicialmente através da técnica i*, os principais elementos inerentes ao processo de aprendizagem colaborativa que envolve pessoas com deficiência visual segundo a visão de Vigotski, considerado como um dos maiores pesquisadores da área. A partir dos modelos organizacionais construídos utilizando-se a técnica i*, apresentamos um sub-conjunto, de um total de 43 requisitos funcionais, 43 casos de uso e 11 requisitos não-funcionais que podem ser aplicados no desenvolvimento de software educacional para pessoas com deficiência visual. Neste sentido, alguns requisitos deste estudo já estão sendo utilizados no desenvolvimento do software xLupa – um ampliador de tela inteligente, para pessoas com visão reduzida. Esse projeto xLupa está sendo financiado pelo CNPq2. Entre os trabalhos relacionados com softwares destinados às pessoas com deficiência visual podem ser citados Leitores e Ampliadores de Ecrã, Tradutores de Braille, Ampliadores de Documentos, disponíveis em (http://www.lerparaver.com/links_software.html) e Software educacional falando sobre História do Brasil [14], o qual teve como base o protótipo deste estudo. Os requisitos apresentados nestes sistemas atendem adequadamente as necessidades dos usuários com deficiência visual. Contudo, é importante salientar que não foram encontrados na literatura da área, referências bibliográficas ou artigos publicados que tratam especificamente do processo de engenharia de requisitos voltado para aplicativos educacionais para deficientes visuais. Também não foram encontrados processos de engenharia de requisitos sistematizados e, que atendam as necessidades específicas das pessoas com deficiência visual sob ótica de Vigotski, principalmente em relação ao processo de aprendizagem colaborativa de pessoas com deficiência. Entre os possíveis trabalhos futuros podemos destacar:

1. Desenvolver um sistema computacional de ensino a distância para deficientes visuais que considere os requisitos expressos neste trabalho e posteriormente utilizar este software em estudos de caso buscando avaliar as reais vantagens do uso do mesmo em um ambiente escolar de aprendizagem colaborativa. 2. Incluir na modelagem do sistema o tratamento dos requisitos não-funcionais descobertos utilizando a técnica de NFR – Framework [11]. 3. Ampliar os nossos estudos visando estabelecer os requisitos a serem aplicados no desenvolvimento de softwares para as pessoas com paralisia cerebral.

Referências

1. ACADEVI. Associação Cascavelense de Deficientes Visuais. Cascavel: 2001. 2. BIANCHETTI, L.; FREIRE, I. M. (orgs). Um Olhar sobre a Diferença - Interação,

Trabalho e Cidadania - Campinas – SP: Papirus, 1998. 3. BOOCH, G., I. Jacobson, J. Rumbaugh, The Unified Modeling Language User Guide,

Addison Wesley, 1999. 4. BRASIL. Constituição Federal do Brasil: promulgada em 5 de outubro de 1988. 16 ed. atual.

e ampl. – São Paulo: Saraiva, 1997. 5. BRASIL. Declaração de Salamanca, e linha de ação sobre necessidades educativas especiais/

tradução: Edilson Alkmim da Cunha. 2. ed. – Brasília: CORDE, 1997.

2 Conselho Nacional de Desenvolvimento Científico e Tecnológico – Ministério da Ciência e Tecnologia –

Brasil.


281

6. BRASIL. Conferencia de Tessalonica, Brasília: MMA,1997. 7. BRASIL.Engesoft. Disponível em <http://www.fw.uri.br/~adrovane/engsoft_arquivos/>.

Acesso em 25 de out de 2004. 8. BRASIL.1999. Plataforma Tecnológica em Engenharia de Requisitos – Estratégias para

oAumento da Qualidade no Desenvolvimento de Sistemas (1999). Disponível em: <http://www.cic.unb.br/~facp/per/docs/resumo.htm >. acesso em: 28 de set. 2004.

9. BRUFFEE, K.A. Collaborative learning. higher education, interdependence and the authorithy of knowledge. 2. ed.Baltimore: Johns Hopkins, 1999.

10. BRUNO, M. M. G. Deficiência visual: reflexão sobre a prática pedagógica. São Paulo: Laramara, 1997.

11. CHUNG, L., Nixon, B.A.,Yu, E., Mylopoulos, J., Non-Functional Requirements in Software Engineering (Monograph), Kluwer Academic Publishers, 472 p. 2000.

12. D'SOUZA , DESMOND F., A.C. WILLS, Objects, Components and Frameworks with UML: The Catalysis Approach, Addison-Wesley, November, (1998).

13. SILVA, D.R., A educação de pessoas com deficiência visual: requisitos básicos para o desenvolvimento de um aplicativo educacional, Dissertação de mestrado, UFSC, Florianópolis, SC, 2005

14. FALANDO SOBRE. Software Educacional Falando Sobre História do Brasil, versão DV, desenvolvido no NIT-UNIOESTE: Cascavel, 2002.

15. IEEE – AS STANDARDS BOARDS IEEE std 830-1998: IEEE Recommended Practice For Software – Requirements Specifications, jun. 1998.

16. JACOBSON, I., BOOCH, G., RUMBAUGH, J., The Unified Software Development Process, Addison-Wesley (1999).

17. KELLER, F. S.; SCHOENFELD, N. W. Princípios de psicologia: um texto sistemático na ciência do comportamento. Tradução: Carolina Martuscelli Bori e Rodolfo Azzi. São Paulo: EPU, 1973.

18. KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Processes and Techniques. Viley 1997.

19. MARTÍN, M. B.; LA FUENTES, B. E.; DIAZ, F.R.; BUENO, S.T. Niños y niñas con ceguera: recomendaciones para la familia y la escuela. Málaga: Ediciones Ajibe, 1999

20. MITLER, P. Educação Inclusiva – Contextos sociais. trad. Windy Brazão Ferreira. Porto Alegre: Artmed, 2003.

21. PIAGET, J. – A epistemologia genética / Sabedoria e ilusões da filosofia; problemas de psicologia genética. Trad. Nathanael C. Caixeiro, Zilda Abujamra Daeir, Célia E. A. Di Pietro. 2. ed. - São Paulo: Abril Cultural, 1983.

22. RODNEY, P. El aspecto psicológico de la discapacidad visual como elemento de comprensión central em el desarollo de la inclusión. Entre dos mundos, Revista de traducción sobre discapacidad visual, nº 22, agosto de 2003. ISSN 1136-0720. Madrid. ONCE. 2003.

23. ROGERS, C. Liberdade para aprender. Belo Horizonte: Interlivros, 1977. 24. SOMMERVILLE, I., Engenharia de Software. Trad. Mauricio de Andrade Ribeiro. 6 ed. São

Paulo: Addison Wesley, 2003. 25. SANTANDER, V. F., Castro, J. F.: “Deriving Use Cases from Organizational Modeling”, In:

IEEE Joint International Requirements Engineering Conference, RE’02, University of Essen, Germany, September, 9-13, (2002), pp. 32-39.

26. SANTANDER, Victor Francisco Araya, SILVA, D. R. Requirements Engineering Contributions on the Development of Educational Software for the Blind or People with Impaired Vision – An Experience Account. CLEI Electronic Journal. http://www.clei.cl/cleiej/: , v.9, n.1, 2006.

27. UNICEF. BRASIL.< http://www.unicef.org/brazil/jomtien.htm>, Acesso em 17 jan 2005. 28. VYGOTSKY, L. S. Fundamentos de defectologia. In: Obras completas. V. 5. La Habana:

Editorial Pueblo y Educación, 1995. 29. YU Eric, Modelling Strategic Relationships for Process Reengineering, Phd Thesis,

University of Toronto, (1995).


282

Intercambio de modelos UML y OO-Method1

Beatriz Marín1, Giovanni Giachetti1, Oscar Pastor

1

1 Departamento de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia

Camino de Vera s/n

46022 Valencia, España

{bmarin, ggiachetti, opastor}@dsic.upv.es

Resumen. Los modelos objetuales se han convertido en los actores principales

en el proceso de desarrollo de software, provocando un auge en la aparición de

herramientas CASE que permiten realizar este tipo de modelos, e incorporando

distintas facilidades que diferencian a unas y otras. Este auge conlleva cada vez

más la necesidad de intercambiar modelos entre las distintas herramientas para

poder aprovechar estas facilidades. En particular, se quiere aprovechar las

prestaciones de herramientas avanzadas, que posibilitan la compilación de

modelos objetuales, generando de esta manera la aplicación final descrita en

dichos modelos. En este contexto, este artículo presenta la correspondencia

entre modelos objetuales UML y OO-Method –un método de producción

automática de software a partir de modelos objetuales compatible con MDA- y

una implementación que transforma automáticamente dichos modelos según la

correspondencia establecida, que posibilita el intercambio de modelos,

aprovechando principalmente la generación automática de aplicaciones

mediante OO-Method a partir de modelos UML.

1 Introducción

Hoy en día, las investigaciones enfocadas al análisis y diseño de sistemas se

centran cada vez menos en los objetos vistos como artefactos de programación, y más

en los modelos conceptuales conformados por dichos objetos. No porque los objetos

hayan perdido importancia, sino todo lo contrario. La orientación a objetos es una

tecnología que se encuentra madura, lo que queda demostrado por la unificación de

los lenguajes de modelado orientado a objetos en el estándar UML[7], que está

globalmente aceptado y usado en los procesos de desarrollo de software, y que ha

pasado del ámbito de la programación (espacio de la solución) al ámbito del

modelado (espacio del problema).

Desde hace algunos años, los modelos son los que se encuentran en la cima de las

tecnologías, puesto que además de la gran ventaja de reutilización de código de la

orientación a objetos, permiten obtener ventajas de portabilidad de los sistemas,

interoperabilidad con otros sistemas y facilidad de cambio del sistema. Debido a que


TIN2004-03534 y cofinanciado por FEDER.


283

los modelos son una representación del conocimiento que se tiene de alguna realidad,

desde un punto de vista en particular, se pretende conseguir el sistema de software

final a partir de las transformaciones automáticas de los modelos realizados.

En este sentido, la OMG ha dictado un estándar para el desarrollo de software

llamado MDA [1] (Model Driven Architecture), el cual es un paradigma de desarrollo

basado en separar la lógica de la arquitectura de la aplicación; representando cada

parte con modelos, que mediante transformaciones dirigidas por metamodelos, se

puede obtener el sistema final.

Por esta razón, actualmente en el mercado se tiene una serie de herramientas CASE

que apoyan los procesos de desarrollo que utilizan el paradigma MDA, unas con más

éxito que otras, ya que algunas permiten obtener a partir de los modelos el código de

las clases, con sus atributos y cabeceras de servicios; y por otra parte, existe un

conjunto más reducido de herramientas, que permite obtener el sistema final mediante

transformaciones de los modelos. Dentro de este conjunto se encuentra Olivanova

Modeler, que pertenece a la empresa CARE-Technologies [2] [3] [13], y que

operacionaliza la conversión de un modelo objetual conceptual en el “código” de la

aplicación final descrita en dicho modelo.

Además, dado que existen varias herramientas CASE que permiten realizar

modelos objetuales, la OMG ha dictado un estándar para el intercambio de modelos

entre las diferentes herramientas, repositorios, bases de datos y productos de software

en general. Este estándar es XMI [4], XML Metadata Interchange, con lo cual los

modelos pueden ser exportados desde una herramienta, importados en otra,

almacenados en algún repositorio, traspasados a algún formato, permiten generar

código a partir de ellos, etc.

Cabe destacar que, para poder intercambiar cualquier tipo de modelos mediante

XMI, sus meta-modelos deben tener elementos que se encuentren en la especificación

MOF (Meta Object Facility), estándar dictado también por la OMG [5] [6]. MOF

define los elementos que pueden componer los distintos meta-modelos; por lo que,

una vez que se han identificado los elementos de los modelos en una herramienta

origen y destino, se pueden intercambiar los modelos entre las herramientas según

sean las relaciones de sus elementos.

En este contexto tecnológico, el problema que aborda este trabajo es la elaboración

de un proceso que transforma los modelos UML construidos con herramientas CASE

de propósito general, en los modelos conceptuales concretos requeridos por un

compilador de modelos OO-Method y viceversa. La contribución principal aportada

es demostrar que estas estrategias basadas en estándares tienen una aplicación práctica

concreta y una utilidad evidente cuando las componentes tecnológicas se acoplan

adecuadamente.

Particularmente, se considerará el diagrama de clases como el modelo conductor

del análisis y diseño de un sistema, enfocando la propuesta de este trabajo al

intercambio de modelos de clases entre herramientas que soporten UML [7] y OO-

Method [8][9], por ejemplo, entre Poseidon y Olivanova Modeler.

Este artículo está organizado en 5 secciones. Después de esta introducción, la

sección 2 describe las correspondencias entre los elementos UML y OO-Method, la

sección 3 muestra una la estrategia de implementación para el intercambio de

modelos, la sección 4 describe un ejemplo de aplicación de dicha estrategia, y

finalmente, la sección 5 relata las conclusiones y los trabajos futuros.


284

2 Modelos UML y OO-Method

Antes de identificar la correspondencia entre los elementos de los modelos de

clases UML y OO-Method, primero se debe identificar cada uno de los elementos,

relevantes para el intercambio, que pueden componer dichos modelos.

2.1 Elementos UML

El diagrama de clases UML refleja básicamente clases y relaciones entre clases

[12]. A continuación se lista un conjunto de elementos de modelado relevantes para el

intercambio de modelos, asociados al diagrama de clases: Clases, que contienen

Atributos y Operaciones; Asociaciones de Clases, que pueden ser Asociación,

Agregación, Composición o Generalización; Actores; Interfaces y Paquetes.

2.2 Elementos OO-Method

Al igual que el diagrama de clases UML, el diagrama de clases OO-Method

también refleja clases y relaciones entre clases. Los elementos relevantes para el

intercambio que se pueden utilizar en este diagrama son los siguientes: Clases, que

contienen Atributos, Eventos, Transacciones y Operaciones; Asociaciones de Clases,

que pueden ser Asociación, Agregación, Composición o Generalización; Agentes y

Clusters.

2.3 Correspondencia entre elementos UML y OO-Method

Se debe tener en cuenta que, OO-Method utiliza un subconjunto de los elementos

pertenecientes a UML, los cuales permiten especificar completamente un sistema

organizacional mediante un lenguaje formal de especificación OASIS [10], que no

presenta heterogeneidad de interpretación semántica, a diferencia de lo que ocurre con

las interpretaciones más informales asociadas a la especificación de modelos UML.

Por medio de este lenguaje formal, es posible obtener el sistema final listo para

compilar y ejecutar. Por esta razón, cada elemento de OO-Method se ha analizado

detalladamente para establecer la correspondencia con los elementos del diagrama

UML, reduciendo al máximo la brecha señalada anteriormente, dada por el uso del

lenguaje natural en UML y OASIS en OO-Method.

• Correspondencia de clases:

Una clase describe un conjunto de objetos que comparten las mismas

especificaciones de características, restricciones y semántica. Tanto las

clases UML como las clases OO-Method conciernen a esta descripción,

por lo que la correspondencia entre ellas es directa, es decir, el nombre de

una clase UML corresponderá al nombre de una clase OO-Method y los

comentarios de una clase UML corresponderán a los comentarios de una


285

clase OO-Method. En esta línea, los elementos contenidos en una clase

UML serán también los elementos contenidos en una clase OO-Method,

pero las correspondencias entre estos elementos serán detalladas más

adelante.

Existen algunas clases de OO-Method que se comportan de manera

especial, ya que pueden ejecutar servicios de otras clases. Estas clases

son conocidas como agentes, que además de ser clases del modelo de

clases UML, serán actores del diagrama de casos de uso, conservando el

nombre de la clase e interactuando con los servicios que ejecuta.

En el sentido contrario, los actores de UML que se encuentren en el

modelo de clases, serán clases agentes en OO-Method; y si están

relacionados con clases, entonces podrán ejecutar todos los servicios de

la clase que tiene relacionada.

• Correspondencia de atributos:

Los atributos de una clase, ya sea UML u OO-Method, representan

características de ella, por lo que su correspondencia es directa, es decir,

el nombre de un atributo UML será el nombre del atributo OO-Method y

la documentación del atributo UML será el comentario del atributo OO-

Method.

En cuanto al tipo de dato de los atributos, UML permite definir los tipos

de datos que se utilizarán en un proyecto, pudiendo ser simples,

complejos, objetuales, etc.; en cambio OO-Method tiene un conjunto

predefinido de tipos de datos simples para los atributos y los tipos de

datos objetuales son representados mediante la correspondiente

asociación entre clases. Cada herramienta CASE que permite realizar

modelos UML, tiene un conjunto predefinido de tipos de datos, además

de entregar la posibilidad de crear otros tipos de datos, por lo que,

teniendo en cuenta la herramienta desde la que se quiere transformar un

modelo y su conjunto predefinido de tipos de datos, se realizará la

equivalencia uno a uno por cada tipo de dato; y para el caso en que no

exista equivalencia, el tipo de dato en OO-Method se asumirá como

String. A pesar de que UML y OO-Method acepten tipos de datos

abiertos, las herramientas que los soportan fijan un subconjunto

predefinido de tipos de datos para las diferentes características de los

modelos. A modo de ejemplificar las equivalencias entre los

subconjuntos predefinidos de los tipos de datos de las herramientas que

soportan UML y OO-Method, a continuación se muestra una tabla que

detalla los tipos de datos predefinidos en la herramienta UML Poseidon y

la herramienta OO-Method Olivanova Modeler.


286

Tabla 1. Ejemplo de correspondencia entre tipos de datos UML y OO-Method

UML OO-Method

Boolean Bool

Byte Int

Short Int

Float Real

Decimal Real

Money Real

Char String

Time DateTime

Currency Real

Date Date

Double Real

Integer Int

Otro tipo String

Cada atributo tiene una propiedad que indica si el valor que toma puede

cambiar en el futuro. Esta propiedad de los atributos es conocida como

changeability en UML. Para expresar la misma semántica, en OO-

Method se clasifican los atributos en constantes, variables y derivados.

En este sentido, los atributos que no pueden cambiar su valor en el

tiempo, corresponderán a los atributos constantes y los que sí pueden

cambiar su valor, serán los atributos variables. UML no representa si un

atributo es derivado en la propiedad changeability, sino que tiene una

propiedad booleana para los atributos que indica si son derivados

(isDerived); por lo que los atributos que tengan esta propiedad como

verdadera corresponderán a atributos derivados en OO-Method.

Para el caso de los atributos derivados, OO-Method permite especificar

su fórmula de derivación mediante el lenguaje formal OASIS; en UML

podría usarse OCL [11] para especificar las fórmulas de derivación, pero

en términos reales, la mayoría de los modelos UML no presentan las

especificaciones OCL. Por esta razón, las fórmulas de derivación serán

traspasadas como parte de la documentación de los atributos cuando se

transforme un modelo OO-Method a uno UML.

El valor inicial de un atributo UML corresponde al valor que tomará el

atributo cuando se crea un objeto de una clase. Esto es equivalente al

valor por defecto de un atributo en OO-Method.

Para los atributos que pueden no tener valores asignados en un instante

del tiempo, OO-Method permite asignarles la propiedad de que pueden

ser nulos; en cambio en UML se especifica el número mínimo y máximo

de valores que un atributo puede tener en un instante del tiempo. Esta

especificación es la multiplicidad del atributo, y sólo cuando su mínimo

es 0 significa que el atributo acepta nulos.


287

• Correspondencia de servicios:

Los servicios definen el comportamiento de los objetos de una clase. OO-

Method distingue los eventos, las transacciones y las operaciones. Los

eventos son servicios atómicos, indivisibles, que ocurren en un instante

temporal y que pueden asignar valores a los atributos de las clases. Las

transacciones son servicios que contemplan una secuencia de eventos y

otras transacciones que sólo tienen dos formas de terminar: se ejecuta de

manera completa o se deshace toda la ejecución. Las operaciones son

servicios que detallan una secuencia de eventos, transacciones y otras

operaciones; y que se ejecuta paso a paso desde el inicio al final,

independientemente de si ha fallado en algún paso.

En UML, las operaciones no especifican la forma en que se consumirá el

servicio, por lo que fue necesario decidir la correspondencia más cercana

a los servicios en OO-Method. Para esto, se tiene en cuenta que el

modelo UML que se quiere transformar es correcto y que no tiene

servicios inventados por el diseñador, sino que los servicios especificados

describen fehacientemente el comportamiento de los objetos.

Dado que las operaciones UML generalmente especifican el

comportamiento de los objetos sin detallar qué atributos del objeto serán

afectados por la realización del servicio, las operaciones UML no

corresponderán a eventos de OO-method. Las operaciones modeladas en

UML podrían ser más semejantes a las transacciones u operaciones de

OO-Method; y como la semántica de las transacciones es más común que

la semántica de las operaciones en el comportamiento de un sistema, ya

que asegura que la base de datos del sistema es consistente; entonces las

operaciones UML corresponderán a las transacciones OO-Method. En el

sentido contrario, los eventos, transacciones y operaciones de OO-

Method corresponderán a operaciones del diagrama de clases UML.

Cada servicio, ya sea de UML u OO-Method, conservará el nombre,

documentación, argumentos de entrada y salida cuando sea transformado

en un sentido y en otro.

Para el caso de los servicios OO-Method, se pueden especificar las

fórmulas de evaluación de los atributos y las fórmulas de las

transacciones y las operaciones mediante el lenguaje formal OASIS; sin

embargo, tal como para los atributos derivados, la especificación OCL

para los servicios no es muy utilizada en los modelos UML; por lo que

serán concatenadas con la documentación de cada operación UML, según

sea el caso.

Los servicios tienen una propiedad para indicar si pueden ser vistos desde

los demás elementos del modelo: la visibilidad. En UML, esta propiedad


288

puede tomar los valores public, private, protected y package; y se puede

interpretar como:

• Un elemento public es visible a todos los elementos que tienen

acceso al espacio de nombres que lo posee.

• Un elemento private es sólo visible dentro del espacio de

nombres que lo posee.

• Un elemento protected es visible a los elementos que tienen una

relación de generalización con el espacio de nombres que lo

posee.

• Un elemento package es visible desde los paquetes que se

encuentran en el mismo espacio de nombres que lo posee; y

sólo puede ser otorgado a elementos que no se encuentren

dentro de paquetes.

Los servicios OO-Method permiten indicar de forma precisa su

visibilidad, es decir, las clases que lo pueden ver, o más bien, sus agentes.

Además, OO-Method permite indicar si un servicio no debe ser visto por

ninguna clase agente mediante la propiedad internal use, con lo cual sólo

será visto por la clase que lo contiene y sus relacionadas. Para realizar la

correspondencia entre la visibilidad de los servicios UML y OO-Method,

se ha tenido en cuenta esta propiedad, por lo que los servicios que tengan

visibilidad private o protected en UML corresponderán a servicios con la

propiedad internal use en OO-Method. Para los servicios que tengan

visibilidad public o package en UML, una vez que se tenga el modelo en

OO-Method, será necesario indicar detalladamente qué clase puede ver

cada servicio. Si la transformación se quiere realizar en sentido inverso,

es decir desde OO-Method a UML, todos los servicios OO-Method

tendrán visibilidad public, a excepción de los que tengan la propiedad

internal use que corresponderán a visibilidad private.

Si una operación UML tiene el estereotipo <<constructor>>, significa

que al realizarla se creará una nueva instancia de la clase que contiene la

operación. Esto es equivalente a que la transacción en OO-Method tenga

el flag New. Lo mismo sucede con el estereotipo <<destructor>> en las

operaciones UML, ya que corresponderán a transacciones OO-Method

con el flag Destructor.

• Correspondencia de asociaciones:

Las asociaciones representan relaciones entre dos clasificadores, que

pueden ser clases, actores, interfaces, etc. Las asociaciones entre dos

clases UML corresponderán a asociaciones de clases OO-Method,

conservando el nombre y la documentación.

Cada asociación tiene dos extremos, en cada uno de los cuales se conecta

la asociación con las clases participantes en ella. El nombre de cada

extremo de la asociación UML corresponderá al nombre de cada rol

participante en la asociación OO-Method.


289

Además, OO-Method distingue las clases participantes en la asociación

como componente y compuesta, según la independencia que tenga una

clase de la otra, es decir, una clase será componente si en cualquier

momento del tiempo pueden crearse o destruirse enlaces de las instancias

de esa clase con las instancias de la clase que se encuentra en el otro

extremo de la asociación; y una clase será compuesta cuando una vez

creados los enlaces de las instancias de esa clase con las de la clase que

se encuentra en el otro extremo, no pueden ser destruidos o no se puede

crear un nuevo enlace cuando los objetos del otro extremo de la

asociación ya han sido inicializados. Cada extremo de la asociación UML

tiene una propiedad que indica su cambio en el tiempo, por lo que si la

propiedad indica que no se puede cambiar (frozen), entonces ese extremo

corresponderá a un extremo compuesto; y cuando dicha propiedad

indique que si puede cambiar (changeable), entonces ese extremo de la

asociación será componente en OO-Method.

Siguiendo con las propiedades de los extremos de las asociaciones, UML

permite que ambos extremos sean frozen, lo cual implicaría que los

objetos de las clases participantes en la asociación deberían ser creados

en el mismo instante de tiempo; lo cual podría significar que se trata del

mismo objeto y por lo tanto sería necesario revisar el modelo. Para el

caso en que un extremo de la asociación sea frozen y el otro changeable,

corresponderá a asociaciones estático-dinámicas en OO-Method. Para el

caso en que ambos extremos de la asociación sean changeable,

corresponderá a una asociación dinámica-dinámica de OO-Method.

Cuando se tienen asociaciones del tipo dinámica-dinámica, es necesario

especificar los servicios que crearán y destruirán los enlaces entre las

clases participantes de la asociación. Generalmente, esta especificación

no se realiza en los modelos UML, que luego son codificados para

obtener el sistema final, en cambio en OO-Method es necesario

especificar estos servicios, ya que a partir de las especificaciones se

puede generar el sistema de software por completo.

Tanto en UML como en OO-Method, cada extremo de la asociación

posee una propiedad que indica la multiplicidad, es decir, cuántas

instancias como mínimo y cuántas instancias como máximo pueden ser

asociadas al otro extremo. Por esta razón, la multiplicidad de cada

extremo de una asociación tiene una correspondencia directa entre

asociaciones UML y OO-Method.

Dado que los actores presentes en el diagrama de clases UML

corresponderán a clases agentes en OO-Method, las asociaciones entre

actores o entre actores y clases serán tratadas de la misma manera que se

ha detallado para las asociaciones entre clases.


290

Las asociaciones entre clases UML pueden especializarse en

agregaciones o composiciones, las cuales son relaciones del tipo es-parte-

de que se diferencian en que la composición incorpora dependencia entre

las instancias de las clases relacionadas. En OO-Method esta

especialización se realiza mediante el manejo de cardinalidades y

dependencia de identificación. A modo de ejemplo, para representar una

relación de agregación entre la clase A y la clase B, donde A es agregada

a B, bastaría con definir una relación que posea cardinalidad máxima uno

desde A hacia B. Mientras que una asociación de composición de A en B

se representaría mediante una relación con cardinalidad mínima y

máxima de uno desde A hacia B, incorporando adicionalmente la

dependencia de identificación de la clase A; con lo cual la duración de

cualquier instancia de A quedará determinada por la instancia de B

relacionada. Ya que la semántica de las asociaciones de agregación y

composición es equivalente entre UML y OO-Method, es posible

establecer una correspondencia directa entre ellas para el intercambio de

modelos.

• Correspondencia de generalización:

La generalización corresponde a una asociación entre varios

clasificadores generales (hijos) y un clasificador específico (padre). En

UML, los hijos heredan todo el comportamiento del padre y agregan

información adicional.

Sin embargo, en OO-Method la herencia es semánticamente más precisa,

pues permite especificar tanto la generalización permanente como la

generalización temporal. La generalización permanente ocurre cuando la

clase padre posee una condición de especialización sobre los atributos

constantes de las clases hijas. En cambio, la generalización temporal

ocurre cuando el padre tiene una condición de especialización sobre los

atributos variables de sus hijos; o a través de eventos que asocian y

liberan a padres con hijos (carrier y liberator respectivamente). En la

generalización temporal también se debe indicar la clase donde se

encuentran los eventos carrier y liberator, pues los hijos pueden liberarse

por sí mismos o pueden ser liberados desde el padre.

Dado que en el contexto general, la generalización de UML es similar a

la de OO-Method, éstas serán correspondidas. Se debe tener en cuenta

que, cuando se quiera transformar un modelo UML a uno OO-Method,

será necesario especificar en el modelo OO-Method los eventos carrier y

liberator de la generalización de manera detallada.

• Correspondencia de paquetes:

Los paquetes son utilizados para agrupar elementos y proveer un espacio

de nombres común a los elementos agrupados. Tanto en la especificación


291

OO-Method como en UML los clusters y paquetes son coherentes a esta

descripción, por lo que su correspondencia será directa.

A modo se resumen, a continuación se presenta una tabla de equivalencias entre

elementos de OO-Method con elementos de UML.

Tabla 2. Correspondencia entre elementos OO-Method y UML

OO-Method UML

Proyecto Modelo

Clase Clase

Agente Actor

Atributo Atributo

Evento Operación

Transacción Operación

Operación Operación

Argumento Entrada Parámetro

Argumento Salida Parámetro

Asociación Asociación

Generalización Generalización

Cluster Paquete

3 Estrategia de Implementación

La estrategia de implementación, tiene por objetivo definir los pasos y mecanismos

necesarios para poder llevar a cabo la transformación de elementos desde UML a OO-

Method y viceversa, según las correspondencias presentadas en el punto 2.

3.1 Proceso de transformación desde UML a OO-Method

Para iniciar el proceso de transformación de un modelo UML a uno OO-Method,

es necesario volcar el modelo UML en un archivo XMI, según el estándar establecido

por la OMG. El volcado al archivo XMI se realiza con las utilidades que presente la

propia herramienta UML en donde se ha modelado; por este motivo, es importante

que la herramienta UML utilizada cumpla con el estándar XMI.

A continuación, con el archivo XMI que contiene el modelo UML, se efectúa la

transformación automática del modelo UML a un modelo OO-Method, aplicando las

correspondencias detalladas en el punto 2. Al término del proceso de transformación,

se obtiene como resultado un archivo XML que contiene la definición del modelo

equivalente para OO-Method.

Es importante señalar que las transformaciones aplicadas sobre el archivo XMI

varían según la versión de UML con la cuál se generó el modelo y la versión del


292

estándar XMI utilizada para volcarlo; por lo que será necesario especificar dicha

información al momento de iniciar la transformación.

Finalmente, el archivo XML generado como producto de la transformación del

archivo XMI, es importado en la herramienta OO-Method.

3.2 Proceso de transformación desde OO-Method a UML

Al igual que en la transformación desde UML a OO-Method, el primer paso en el

proceso de transformación es volcar el modelo OO-Method en un archivo XML.

Una vez que se tiene el archivo XML que contiene el modelo OO-Method, se

realiza su transformación automática a un modelo UML, utilizando las

correspondencias descritas en el punto 2. Se obtendrá un archivo XMI como resultado

de la transformación automática, construido según el estándar establecido por la

OMG y que contiene la definición del modelo equivalente para UML.

Cabe destacar que el archivo XMI resultante debe estar en una versión del estándar

XMI soportada por la herramienta UML. Lo mismo ocurre con el modelo UML que

está definido en dicho archivo; razón por la que es necesario especificar la versión del

archivo XMI y de UML soportados por la herramienta, antes de realizar la

transformación del archivo XML que contiene el modelo OO-Method.

En último lugar, el archivo XMI generado es importado en la herramienta UML.

3.3 Consideraciones

Actualmente las herramientas UML no cumplen íntegramente con el estándar XMI

establecido por la OMG, por lo que es necesario especificar además de las versiones

de XMI y UML, la herramienta utilizada para generar el archivo XMI; tanto para el

caso de la transformación UML a OO-Method, como para la transformación de OO-

Method a UML.

Por otro lado, debido a que existen elementos OO-Method que no tienen

representación directa en UML; la exportación de un modelo desde OO-Method a

UML y luego la importación a OO-Method, puede dar como resultado un modelo

OO-Method distinto al modelo original. Esta diferencia radica principalmente en las

definiciones formales que se realizan mediante OASIS en el modelo OO-Method

original y que pierden su formalidad al realizar la exportación a UML, ya que se

convierten en documentación del modelo UML, y al transformar nuevamente el

modelo UML a OO-Method, corresponden a documentación y no a definiciones

formales en OASIS. Por esta razón, no existen garantías para recuperar el modelo

original a partir de un modelo que se ha exportado e importado. Ejemplos de estas

definiciones formales son la especificación de los servicios, de las derivaciones para

los atributos derivados y de las precondiciones.


293

4 Ejemplo de intercambio de modelos

La estrategia de intercambio planteada en el punto 3 será aplicada en un proceso de

intercambio real, que transforma un modelo de ejemplo generado en la herramienta

UML Poseidon v4.1.2 (que se muestra en la Fig. 1) a un modelo de la herramienta

OO-Method OLIVANOVA Modeler v6.9.a (que se muestra en la Fig. 2).

Fig. 1. Ejemplo de modelo realizado en Poseidon.

El primer paso contempla el volcado del modelo UML generado en Poseidon a un

archivo XMI que cumpla con el estándar definido por la OMG. La versión utilizada

de Poseidon cumple con la versión 1.2 del estándar XMI definido por la OMG para

modelos UML versión 2.0. Para realizar el volcado del modelo, se utiliza la función

de exportación a XMI que posee Poseidon.

El segundo paso consiste en ejecutar la aplicación de importación XMI construida

para OLIVANOVA Modeler, que utiliza una plantilla de transformación XSL, donde

son definidos los procedimientos necesarios para la identificación de los elementos

del modelo volcado y su transformación, según lo establecido en el punto 2 de este

documento.

La aplicación de importación solicita el archivo XMI que será importado, la

herramienta utilizada para su generación, versión del estándar XMI utilizada para

generar dicho archivo y versión de UML del modelo descrito. En este punto se debe

especificar la herramienta Poseidon, versión 1.2 de XMI y versión 2.0 de UML.

Una vez que se ha ingresado toda información requerida por la aplicación, se

identifican los elementos y se genera un reporte que muestra al usuario los elementos

que han sido transformados desde el modelo UML.

Finalmente, el resultado del proceso de transformación es un archivo XML, que

describe un modelo OO-Method según la especificación definida en el DTD 3.3 de la

herramienta OLIVANOVA Modeler.

El modelo desplegado en la herramienta es el que se muestra en la Fig. 2, donde se

puede apreciar claramente que los actores Persona, Empleado y Cliente del modelo

original han sido traspasados como clases agentes en el modelo destino, las clases


294

factura y detalle del modelo de origen se conservan como clases en el modelo destino,

todas ellas conservando sus nombres, atributos y operaciones. Además se puede

visualizar la relación de generalización entre Persona, Empleado y Cliente; y la

asociación entre Cliente y Factura; y también la asociación entre Factura y Detalle,

cada una con sus respectivas cardinalidades.

Fig. 2. Ejemplo de modelo traspasado a Olivanova Modeler.

El proceso de exportación funciona de manera inversa al proceso de importación,

con las consideraciones especificadas el punto 3.

En este momento, se encuentran implementadas dos aplicaciones con la estrategia

presentada en este documento: XMIImporter y XMIExporter.

XMIImporter, permite importar los modelos realizados en herramientas UML que

cumplan con el estándar XMI a la herramienta OO-Method OLIVANOVA Modeler.

Las herramientas UML soportadas por XMIImporter son:

• Poseidon, para XMI v1.2 y UML v2.0

• MagicDraw, para XMI v1.2 y UML v1.4

• Rational Rose, para XMI v1.1 y UML v1.3

XMIExporter, permite exportar los modelos realizados en la herramienta

OLIVANOVA Modeler a herramientas UML que cumplan con el estándar XMI.

Actualmente soporta la herramienta Poseidon, para XMI v1.2 y UML v2.0.


Actualmente en el mercado existe un sinfín de herramientas CASE que apoyan el

proceso de desarrollo de software. Algunas tienen más éxito que otras, dadas las

facilidades que presentan para su uso y los productos que se pueden conseguir con

ellas. En este sentido, el intercambio de modelos entre las distintas herramientas juega

un papel principal, ya que permitiría utilizar las facilidades presentadas por las

distintas herramientas y en un plano más global facilitar el intercambio de

conocimiento entre organizaciones que desarrollan software y sus proyectos.


295

Hoy por hoy, la falta de estandarización por parte de las distintas herramientas de

modelado presenta un obstáculo importante para alcanzar las metas señaladas; motivo

por el cual es muy relevante la apertura de las herramientas al intercambio de modelos

y que se adapten cada vez más a los estándares dictados, como lo es XMI. Por esta

razón, se han desarrollado dos herramientas que permiten facilitar el intercambio de

modelos UML y OO-Method que cumplen con el estándar XMI: XMIImporter y

XMIExporter, que como su nombre lo indica, permiten importar modelos a la

herramienta OO-Method y exportar modelos OO-Method respectivamente. Estas

herramientas presentan una contribución real al intercambio de modelos bajo los

estándares dictados por la OMG.

XMIImporter presta especial ayuda cuando se tiene un modelo realizado en UML

y se quiere generar de manera automática el sistema para ese modelo, ya que al

importar el modelo a OLIVANOVA Modeler y especificar en detalle los servicios

nombrados en el diagrama de clases mediante OASIS y las diferentes utilidades

presentadas por la herramienta, se puede generar y probar el sistema final en muy

poco tiempo, permitiendo que los desarrollos de software sean más rápidos y con una

menor probabilidad de fallos producto de la codificación.

Aún queda bastante trabajo por realizar en los procesos de intercambio de modelos,

por lo que el trabajo futuro estará centrado en la definición de nuevas

correspondencias, tanto a nivel de elementos como en la definición formal del

comportamiento de dichos elementos. Ya se ha comenzado con el análisis de

correspondencias entre los elementos de OO-Method y UML para los diagramas de

estados y de colaboración, luego se continuará con los diagramas de secuencia y de

actividades; y posteriormente se trabajará sobre la correspondencia entre definiciones

OASIS y OCL que permitan intercambiar de la manera más completa posible los

modelos entre herramientas UML y OO-Method.

Referencias

1. http://www.omg.org/mda/

2. http://www.care-t.com

3. http://www.care-t.com/technology/mda.asp

4. OMG: XML Metadata Interchange (XMI) Specification, version 1.2, 2002.

5. http://www.omg.org/mof/

6. OMG: MOF, versión 1.3, 2000.

7. http://www.uml.org/

8. http://oomethod.dsic.upv.es 9. Pastor O., Insfrán E.: OO-Method, the methodological support for Oliva Nova Model

Execution System. http://www.care-t.com/_downloads/whitepapers/WP-OOMethod.pdf

10. Pastor O., Ramos I., Cuevas J., Devesa J.: OASIS versión 2.0, An Object

Definition Language for Object Oriented Databases, 1994. 11. OMG: Object Constraint Language, versión 2.0, 2006.

12. OMG: UML Superstructure Specification, versión 2.0, 2005.

13. Molina J., Pastor O.: MDA, OO-Method y la tecnología OLIVANOVA Model

Excecution, DSDM - 2004.


296

Apoio Automatizado à Gerência de Riscos Cooperativa

Victorio Albani de Carvalho, Alexandre G. N. Coelho, Ricardo de Almeida Falbo

Departamento de Informática, Universidade Federal do Espírito Santo, Vitória - ES - Brasil {victorioalbani, alexandrecoelho20}@yahoo.com.br,

[email protected]

Abstract. Software process is inherently cooperative. During its activities, developers work together in order to develop a quality product. Especially, project managers are involved in decision make activities that can drive the project to success or failure. Those activities are better performed by experienced people, when developers work cooperatively, and when knowledge is shared. In this paper, we present a tool that supports cooperative development of Risk Plans.

1 Introdução

As atividades do processo de software são reconhecidamente cooperativas. Durante um projeto de software, diversos profissionais trabalham em conjunto com o objetivo comum de desenvolver um produto de software de qualidade, que atenda às necessidades do cliente, obedecendo a restrições de custos e prazos.

Em especial, gerentes de projetos são responsáveis pela tomada de decisões que podem levar um projeto ao sucesso ou ao fracasso. A experiência é unanimemente apontada como uma das principais características desejáveis de um bom gerente de projetos. Entretanto, cada projeto de software é único. Assim, por mais experientes que sejam os gerentes de projetos, muitos ganhos podem ser obtidos através da troca de experiências durante a realização das atividades de gerência.

Essa troca de experiências pode se dar de várias formas. Outros gerentes podem ser chamados a opinar informalmente ou a relatar suas experiências, profissionais podem realizar atividades efetivamente de modo cooperativo, elaborando conjuntamente certos artefatos, ou podem-se utilizar dados históricos de projetos anteriores similares. Neste último caso, contudo, para tomar uma decisão em um projeto, muitas vezes, é importante conhecer, também, as justificativas e razões existentes por trás de uma decisão tomada, além de conhecer a decisão em si e os produtos dela decorrentes. Assim, é útil registrar, não apenas os artefatos gerados em uma atividade, mas também as razões por trás das decisões tomadas, incluindo justificativas, alternativas consideradas e os argumentos que conduziram à decisão.

Esta situação geral se aplica à gerência de riscos. Todo projeto está sujeito a riscos que podem afetar o seu andamento e os seus custos. Gerentes de projeto devem determinar a probabilidade e o impacto da ocorrência desses eventos indesejáveis e fazer planos para evitar que eles ocorram ou, caso sejam inevitáveis, procurar minimizar as conseqüências negativas dos mesmos [1]. Tipicamente, todas essas


297

informações são registradas em um documento, o Plano de Riscos. Mas além de ter acesso ao Plano de Riscos em si, é bastante útil conhecer as razões que levaram às decisões que eles escondem.

O trabalho apresentado neste artigo tem por objetivo facilitar a troca de experiências na Gerência de Riscos, por meio da elaboração cooperativa de Planos de Risco e da captura do raciocínio seguido durante a realização dessa atividade e posterior disseminação desse conhecimento. Para tal, GeRis [2], a ferramenta de apoio à gerência de riscos do ambiente de desenvolvimento de software ODE [3], foi reformulada e estendida.

Este artigo está organizado da seguinte forma: a seção 2 discute brevemente a Gerência de Riscos e três potenciais instrumentos de apoio a seu complexo processo: automatização do processo, gerência de conhecimento e apoio ao trabalho cooperativo; a seção 3 apresenta sucintamente o ambiente ODE, sua ferramenta de apoio à gerência de riscos (GeRis) e sua infra-estrutura de gerência de conhecimento, procurando destacar recentes melhorias feitas; a seção 4 trata das novas funcionalidades providas no ambiente para a elaboração cooperativa de planos de riscos e como o conhecimento envolvido nessa tarefa é capturado; finalmente a seção 5 apresenta as considerações finais do artigo.

2 Apoio ao Processo da Gerência de Riscos

Segundo o padrão IEEE Std 1540-2001 [4], a Gerência de Riscos visa a identificar potenciais problemas antes que eles ocorram, de forma que ações possam ser tomadas a fim de reduzir ou eliminar a probabilidade e o impacto desses problemas.

De modo simplificado, podemos pensar um risco como uma probabilidade de alguma circunstância adversa ocorrer, ameaçando o projeto, o software que está sendo desenvolvido ou a organização. Os riscos podem surgir como decorrência de requisitos mal definidos, de dificuldades em estimar prazos, custos e recursos, da dependência de habilidades individuais e de mudanças nos requisitos, dentre outros. Um gerente de projeto deve prever riscos, compreender o impacto desses riscos no projeto, no produto e nos negócios e tomar providências para evitá-los. Planos de contingência podem ser traçados para que, se os riscos vierem realmente a ocorrer, seja possível uma ação imediata que vise à recuperação [5].

Os riscos sempre envolvem duas características: incerteza (o evento que caracteriza um risco pode ou não acontecer) e perda (se um risco se tornar realidade, conseqüências indesejáveis vão ocorrer). Quando riscos são analisados, é importante quantificar o nível de incerteza e o grau de perdas associados a cada risco. Além disso, as atividades da gerência de riscos devem ser aplicadas iterativamente durante todo o acompanhamento do projeto de software [6]. Essas atividades incluem:

• Identificação de riscos: visa a identificar possíveis ameaças (riscos) para o projeto, antecipando o que pode dar errado;

• Análise de riscos: trata de analisar os riscos identificados, estimando sua probabilidade e impacto (grau de exposição ao risco);

• Avaliação de riscos: busca priorizar os riscos e estabelecer um ponto de corte, indicando quais riscos serão gerenciados e quais não serão;


298

• Planejamento de ações: trata do planejamento das ações a serem tomadas para evitar que um risco ocorra (ações de mitigação) ou para definir o que fazer quando um risco se tornar realidade (ações de contingência);

• Elaboração do Plano de Riscos: todos os aspectos envolvidos na gerência de riscos devem ser documentados em um plano de riscos, indicando os riscos que compõem o perfil de riscos do projeto, suas avaliações, a definição dos riscos a serem gerenciados e, para esses, as ações de mitigação e contingência;

• Monitoramento de riscos: à medida que o projeto progride, os riscos têm de ser monitorados para se verificar se os mesmos estão se tornando realidade ou não. Novos riscos podem ser identificados, o grau de exposição de um risco pode mudar e ações podem ter de ser tomadas. Essa atividade é realizada durante o acompanhamento do progresso do projeto.

A importância de se gerenciar riscos é atualmente inquestionável. Quase todas as normas e modelos de qualidade e padrões de gerência de projetos advogam que essa prática é essencial. O CMMI [7], por exemplo, possui uma área de processo totalmente dedicada à gerência de requisitos no nível 3 de maturidade (Gerência de Requisitos), além de possuir práticas específicas e sub-práticas nas áreas de processo Planejamento de Projeto e Controle e Monitoração de Projetos, ambas do nível 2.

Contudo, apesar de ter sua importância reconhecida, muitas organizações encontram dificuldades na realização dessa atividade. Segundo resultados da pesquisa em Qualidade e Produtividade no Setor de Software Brasileiro de 2001 [8], apenas 11,8% das organizações de software brasileiras realizavam esta prática. Assim, é muito importante procurar prover meios de apoiar a realização desta atividade. Dentre esses meios podemos citar o apoio automatizado, o compartilhamento de experiências e o apoio ao trabalho cooperativo.

As ferramentas CASE (Computer-Aided Software Engineering) têm sido um meio bastante utilizado para apoiar gerentes e profissionais de Engenharia de Software na realização de atividades do processo de software. Neste conjunto de ferramentas inclui-se também a gerência de riscos. Dentre as diversas ferramentas CASE de apoio à gerência de riscos podem ser citadas RiskRadar1, ProRisk2 e RiskyProject3. Para uma lista mais ampla, veja http://www.rspa.com/spi/project-risk.html.

Quando se trata da automatização do processo de software, uma questão importante é a integração de ferramentas. Ferramentas CASE geralmente atendem a uma, ou a poucas atividades, resolvendo problemas pontuais. Entretanto, na prática, esses problemas não estão dissociados, sobretudo quando se trata da gerência de projetos. Isso implica na utilização de várias ferramentas para que se possa atender às diversas atividades do processo. Assim, quanto mais ferramentas forem utilizadas, mais trabalho é necessário para integrar suas informações, já que resultados produzidos por uma ferramenta devem ser passíveis de processamento por outras. Assim, ao menos algum tipo de integração de dados é necessário [9].

A busca pela integração levou ao desenvolvimento de Ambientes de Desenvolvimento de Software (ADSs). ADSs podem ser descritos como coleções de ferramentas integradas que facilitam as atividades da engenharia de software, durante

1 http://www.iceincusa.com/Products.aspx?p=Products_RiskRadar 2 http://eng-sun3.murdoch.edu.au/~geoff/ProRisk/ProRiskBrowser.html 3 http://www.intaver.com/riskyprojectprof.html


299

todo o ciclo de vida do software ou pelo menos em porções significativas dele [10]. Em escala bem menor que ferramentas CASE de apoio à gerência de riscos, há ADSs que possuem ferramentas dedicadas a essa atividade, tais como os ambientes Odyssey [11] e TABA [12].

No que tange ao compartilhamento de experiências, a gerência de conhecimento (GC) tem sido bastante utilizada no contexto da Engenharia de Software em geral [13] e na Gerência de Riscos mais especificamente [2]. A gerência de riscos é uma atividade complexa e de intenso conhecimento e, portanto, gerenciar o conhecimento organizacional nela envolvido é importante. Apoiados por sistemas de GC, gerentes de projeto podem utilizar conhecimento organizacional sobre riscos, juntamente com suas próprias experiências, para realizar as atividades desse complexo processo [2].

Mas para ser efetivo, um sistema de GC deve estar integrado ao processo de trabalho [14]. No caso do processo de software, quando apoiado de forma automatizada por um ADS, é natural integrar o sistema de GC a esse ADS [15]. Essa preocupação, por exemplo, tem sido foco do ADS TABA, incluindo apoio de GC ao processo da gerência de riscos [12].

Por fim, deve-se considerar que o processo de software é uma atividade essencialmente cooperativa, na qual diferentes profissionais atuam em conjunto para desenvolver um produto de software de qualidade. Equipes tendem a ser mais produtivas quando há cooperação e troca de idéias. Esse é precisamente o caso da gerência de projetos. Por exemplo, Pressman [6], Pfleeger [1] e Jørgesen [16] apontam a combinação de estimativas de diferentes especialistas utilizando diferentes abordagens como uma boa prática para a geração de estimativas confiáveis. Mas isso não se restringe às estimativas. Planos de riscos podem ser melhor desenvolvidos se diversos especialistas trabalharem em conjunto, apontando riscos, debatendo seus graus de exposição e definindo ações, até chegarem a uma proposta consensual.

Ao analisar esses três diferentes potenciais mecanismos de apoio à gerência de riscos – automatização do processo, gerência de conhecimento e apoio ao trabalho cooperativo – identificamos que há uma forte sinergia entre eles e, portanto, maiores benefícios podem advir se eles forem combinados. Este é o foco deste trabalho: explorar a sinergia entre automatização do processo, apoio ao trabalho cooperativo e gerência de conhecimento no apoio à gerência de riscos. Seu desenvolvimento se deu no contexto do ambiente ODE, apresentado a seguir.

3 O Ambiente ODE

O ambiente ODE (Ontology-based Software Development Environment) [3] é um Ambiente de Desenvolvimento de Software (ADS) centrado em processo e baseado em ontologias. A premissa do Projeto ODE é a seguinte: se as ferramentas do ADS são construídas baseadas em ontologias, a integração das mesmas é facilitada, pois os conceitos envolvidos estão bem definidos e compartilhados.

Tal ambiente vem sendo desenvolvido no Laboratório de Engenharia de Software da Universidade Federal do Espírito Santo (LabES-UFES) desde 1999 e a partir do final de 2004 foi implantado em caráter experimental em uma organização de


300

desenvolvimento de software, atualmente CMMI nível 2, visando obter um feedback de sua utilidade em situações reais.

Formando a base ontológica de ODE, há diversas ontologias, dentre elas, ontologias de Processo de Software, de Riscos de Software, de Qualidade de Software e de Organizações de Software. Essas ontologias fornecem uma conceituação sólida para a construção de diversas ferramentas do ambiente, incluindo a sua infra-estrutura de Gerência de Conhecimento [17]. Em especial, merece destaque no contexto deste trabalho a ontologia de requisitos de software [2], usada como base para a construção da ferramenta GeRis [2], de apoio à Gerência de Riscos.

Ontologias são usadas em ODE para derivar as classes que implementam o ambiente ou algumas de suas ferramentas. Essas classes são conceitualmente organizadas em três níveis, como mostra a Figura 1 [18]. O nível ontológico (pacote Ontologia) é responsável pela descrição das ontologias no ambiente e suas classes correspondem à meta-ontologia assumida no ambiente. O nível de conhecimento (pacote Conhecimento) abriga as classes que descrevem o conhecimento em relação a um domínio de aplicação. Suas classes são derivadas das ontologias, sendo que seus objetos atuam no papel de conhecimento sobre os objetos do nível base. Por fim, o nível base (pacote Controle) define as classes que implementam o ambiente e suas ferramentas. As ontologias exercem um papel fundamental em ODE, na medida em que são responsáveis por organizar e estabelecer as conexões entre itens distribuídos pelos três níveis [18].

Fig. 1. Arquitetura Conceitual de ODE.

O ambiente conta atualmente com diversas ferramentas, dentre elas ferramentas de apoio à definição de processos de software, de apoio à engenharia de requisitos, de apoio à realização de estimativas e de apoio à gerência de riscos. Além disso, o ambiente possui uma infra-estrutura de gerência de conhecimento [17] e uma infra-estrutura de caracterização de itens de software [19] que é utilizada pela primeira para apoiar a busca de itens de conhecimento úteis, com base em similaridade de projetos.

3.1 A Infra-estrutura de Gerência de Conhecimento de ODE

A infra-estrutura de Gerência de Conhecimento (GC) de ODE [17] é composta por uma memória organizacional, estruturada em repositórios de conhecimento, e cinco tipos básicos de serviços para permitir a captura e criação, recuperação e acesso, disseminação pró-ativa, uso e manutenção de itens de conhecimento.

Como mostra a Figura 2, os repositórios de conhecimento da memória organizacional de ODE contêm itens de conhecimento. Esses itens podem ser formais ou informais.

Ontologia

Nível Ontológico

Conhecimento

Nível de Conhecimento

Controle

Nível Base


301

Memoria Organizacional

Ontologia ItemConhecimentoFormal

AvaliacaoReusoConhecimento

Item Conhecimento

0..n1

0..n1

KRisco(from Conhecimento)

KAcao(from Conhecimento)

Documento(from Controle)

PlanoRisco(from GeRis)

Conceito

0..n

1..n

0..n

1..n

Repositorio Conhecimento

1..n1

1..n1

1..n0..n

1..n0..n

0..n1 0..n1

Conhecimento(from Conhecimento)

1

0..n

1

0..n

0..n

1

0..n

1

ItemConhecimentoInformal

0..n

0..n

0..n

0..n

Licao Aprendida

Pacote Mensagem

Artefato(from Controle)

KArtefato(from Conhecimento)

0..n

1

0..n

+tipo

1

KCategoriaRisco(from Conhecimento)

Fig. 2. Diagrama de classes parcial da Infra-estrutura de Gerência de Conhecimento de ODE.

Os itens formais são os diversos artefatos produzidos pelas ferramentas do ambiente, dentre eles os planos de riscos. Já os itens informais incluem lições aprendidas e pacotes de mensagens, sendo estes últimos formados por mensagens trocadas nas ferramentas de comunicação de ODE (correio eletrônico e fórum), que são empacotadas usando um serviço de empacotamento de mensagens [17]. Todos os itens são indexados por objetos do nível de Conhecimento, sub-classes da classe Conhecimento (sempre precedidas pelo prefixo K) que descrevem o conhecimento organizacional sobre um domínio descrito por uma ontologia de ODE. Por exemplo, a ontologia de riscos de ODE possui os conceitos categoria de risco, risco e ação, que foram mapeados, respectivamente, nas classes KCategoriaRisco, KRisco e KAcao, cujos objetos, por sua vez, descrevem o conhecimento organizacional sobre categorias de risco consideradas pela organização e potenciais riscos e ações de contingência e mitigação. Já artefatos são anotados com o tipo específico do artefato (KArtefato). Por exemplo, planos de risco dos diversos projetos são sempre associados ao mesmo objeto de conhecimento que representa o tipo de artefato “Plano de Risco”. Assim, as ontologias são utilizadas para estruturar a memória organizacional de ODE, usando


302

um mecanismo de anotação conceitual. Essas anotações são usadas posteriormente por serviços de busca e disseminação.

No que se refere aos serviços, cinco tipos básicos são providos pela infra-estrutura: • captura e criação: artefatos produzidos pelas ferramentas do ambiente são

disponibilizados como itens formais de conhecimento. Assim, planos de risco produzidos na ferramenta GeRis, quando finalizados, passam a ser tratados como itens de conhecimento. Para tratar lições aprendidas, há um serviço específico que permite seu registro, aprovação e publicação [15]. Por fim, conforme citado anteriormente, há um serviço de empacotamento de mensagens trocadas por membros da organização usando as ferramentas de comunicação de ODE [17];

• recuperação e acesso: é o serviço geral de busca de itens de conhecimento, com iniciativa por parte dos usuários do ambiente. Esse serviço se apóia fortemente no esquema de anotação ontológica descrito anteriormente;

• disseminação pró-ativa: serviço análogo ao anterior, mas iniciado pelo sistema, fornecendo itens relevantes para uma determinada atividade que está sendo executada. Esse serviço é provido por agentes especializados, sendo que ele não é geral, precisando ser tratado pelas ferramentas que o implementam. Na ferramenta de gerência de riscos, há um sistema multi-agente que provê esse serviço [20];

• feedback da relevância: durante o uso de um item de conhecimento, o desenvolvedor pode registrar uma avaliação da relevância de um item para o seu trabalho (classe AvaliacaoReusoConhecimento na Figura 2) [15]; e

• manutenção: com base no feedback provido pelos desenvolvedores, o serviço de manutenção permite a exclusão de itens da memória organizacional [15].

3.2 GeRis: A Ferramenta de Apoio à Gerência de Riscos de ODE

GeRis é a ferramenta de apoio à gerência de riscos de ODE. Conforme brevemente comentado anteriormente, o ambiente e algumas de suas ferramentas são estruturados e construídos refletindo as conceituações definidas pelas ontologias de ODE. Dado que ODE é desenvolvido usando a tecnologia de objetos, é realizado um mapeamento de ontologias para modelos de objetos, aplicando-se parcialmente a abordagem sistemática de derivação de infra-estruturas de objetos a partir de ontologias, descrita em [21]. Nessa abordagem conceitos, relações, propriedades e restrições definidas como axiomas de uma ontologia são mapeados para classes, associações, atributos e métodos de um modelo de objetos que é, então, usado como modelo base para uma parte do ambiente ou ferramenta. Além disso, segue-se o esquema de anotação conceitual descrito anteriormente, no qual as classes derivadas das ontologias são anotadas com os conceitos da ontologia.

GeRis segue essa abordagem, tomando por base uma ontologia de riscos [2]. Os conceitos e relações da ontologia são descritos como instâncias das classes do pacote Ontologia. Para a derivação das classes dos outros dois níveis, levaram-se em conta quais conceitos tratam de conhecimento organizacional (derivados como classes do pacote Conhecimento) e quais são elementos específicos de projetos (derivados como


303

classes do nível base) [2]. A Figura 3 mostra um modelo de classes simplificado de GeRis, com atualizações recentes feitas em relação a [2].

Documento(from Controle)

Artefato

dtFinalizacaoversao

(from Controle)

0..1

0..n

0..1

0..n

+versaoAnterior

PlanoRisco

Projeto(from Controle)

10..n 10..n KCategoriaRisco(from Conhecimento)

KRisco(from Conhecimento)

1..n

0..n

1..n

0..n

PerfilRisco

0..n

1

0..n

1

1

0..n

1

0..n10..n 10..n

Consequenciadescricaoobservacao

AvaliacaoRiscodataprobabilidadeimpactograuExposicaoindicadorGerenciamentoindicadorOcorrencia

0..1

1

0..1

1

0..n1

0..n1

KAcao(from Conhecimento)

0..n

1..n

0..n

1..n

0..n

0..n

0..n0..n

+acaoMitigacao0..n

0..n

+acaoContingencia0..n

0..n

Fig. 3. Diagrama de classes parcial da versão atual de GeRis.

Os objetos das classes de conhecimento (KCategoriaRisco, KRisco e KAcao) são criados por meio de uma funcionalidade do ambiente para cadastrar conhecimento, disponibilizada apenas para usuários com papel de Gerente de Conhecimento. Os objetos das demais classes são criados pelo uso da ferramenta GeRis.

Desde sua primeira versão, GeRis oferece as seguintes funcionalidades [2]: (i) na identificação de riscos, o conhecimento organizacional sobre potenciais riscos para um projeto (objetos da classe KRisco) é apresentado para que o gerente de projeto selecione quais riscos compõem o perfil de risco do projeto em questão; (ii) uma vez identificados os riscos, podem-se avaliar a probabilidade e o impacto de cada um deles, definindo o grau de exposição de cada risco no projeto; (iii) os riscos são ordenados, então, pelo grau de exposição e apresentados para que o gerente de projeto selecione quais serão gerenciados; (v) finalmente, para os riscos a serem gerenciados, são definidas ações de contingência e mitigação.


304

Os serviços gerais da gerência de conhecimento de ODE podem ser usados, por exemplo, para buscar e reutilizar um plano de risco de um projeto similar [2]. Além disso, foi desenvolvido um sistema multi-agente para disseminação pró-ativa de potenciais riscos, graus de exposição e ações [20].

A primeira versão de GeRis foi disponibilizada juntamente com o ambiente para uso em caráter experimental por uma organização de software no final de 2004. Desse uso, várias melhorias foram sugeridas, dentre elas a necessidade de aperfeiçoamento na usabilidade da ferramenta e a possibilidade de se ter várias versões concorrentes de um mesmo plano de risco.

No que se refere à melhoria da usabilidade, ainda que as funcionalidades acima citadas claramente sigam uma ordem, dada pelo processo da Gerência de Riscos, a ferramenta, por usar um sistema de menus convencional, não mostrava explicitamente essa ordem, dificultando o seu uso. Para tratar esse problema, que não é específico da ferramenta de gerência de riscos, mas de qualquer ferramenta que tenha de automatizar um processo bem definido com atividades tendo de ser realizadas segundo uma determinada ordem, um novo componente foi desenvolvido. Esse componente permite dar clareza ao processo, provendo as funcionalidades na ordem definida por esse, como ilustra a Figura 4.

Fig. 4. Identificação de Riscos na Nova Versão de GeRis.

Em relação à oportunidade de melhoria que apontava a possibilidade de se ter várias versões diferentes do mesmo plano de risco, possivelmente considerando aspectos diferentes, conduziu ao desenvolvimento de funcionalidades de apoio ao trabalho cooperativo em GeRis e de captura e disseminação do conhecimento envolvido nesta tarefa, discutidas a seguir.


305

4 Apoio ao Trabalho Cooperativo em GeRis

A abordagem para permitir a elaboração cooperativa de planos de risco foi desenvolvida a partir de uma adaptação da técnica Delphi [1], usualmente aplicada na realização de estimativas. Segundo essa técnica, por meio de uma reunião com várias rodadas, mediada por um moderador, as estimativas de diversos especialistas são combinadas visando à geração de uma estimativa consensual. Cada participante é livre para utilizar a abordagem que lhe for mais conveniente para a elaboração de sua proposta e a cada rodada da reunião, os especialistas têm a oportunidade de rever suas estimativas com base na troca de idéias entre os participantes, com argumentações e justificativas.

A adaptação proposta para apoiar a elaboração cooperativa de planos de riscos prevê a realização de uma reunião para construção cooperativa desse artefato, em um fluxo de trabalho iterativo composto de sete etapas, a saber:

1. Identificação da necessidade de realizar a Gerência de Riscos de forma cooperativa: o gerente de projeto identifica que a gerência de riscos deve ser realizada de forma cooperativa e propõe uma reunião para a realização da mesma.

2. Planejamento Inicial da Reunião: o gerente de projeto define o moderador, os participantes e o tipo da reunião, e prepara materiais e recomendações que julga serem importantes para os participantes.

3. Planejamento de Rodada: o moderador estabelece as datas de início e término de uma rodada e notifica os participantes da mesma.

4. Elaboração de Propostas: os participantes elaboram suas propostas de planos de riscos, devendo explicar os motivos que os levaram a tais propostas, e as submetem para o moderador.

5. Elaboração de Proposta de Consenso: o moderador, de posse das propostas dos participantes, procura elaborar uma proposta consensual que contemple as principais considerações de cada participante. Essa proposta é submetida para apreciação de todos. Caso considere as propostas dos participantes divergentes a ponto de não permitirem a elaboração de uma proposta de consenso, o moderador pode apresentar novas informações e recomendações aos participantes e iniciar uma nova rodada de discussões, retomando o processo a partir do passo 3.

6. Discussão sobre a Proposta de Consenso: por meio de um fórum, os participantes emitem opiniões sobre a proposta de consenso, justificando seus pontos de vista.

7. Avaliação da Proposta de Consenso: tomando por base as opiniões dos participantes, o moderador avalia se a proposta de consenso pode ser aprovada, se precisa de pequenas alterações mas pode ser aprovada, ou se uma nova rodada de discussões é necessária, retomando o processo a partir do passo 3. Caso acredite ser inviável chegar a um consenso entre os participantes, o moderador pode, ainda, finalizar a reunião sem que uma proposta de consenso seja aprovada.

Uma reunião pode ser de dois tipos: (i) aberta, na qual, a cada rodada, os participantes têm acesso, de forma anônima, às propostas apresentadas por todos os outros participantes na rodada anterior e a um relatório sumário dessas propostas, ou


306

(ii) fechada, na qual cada participante só tem acesso à sua própria proposta da rodada anterior, ao relatório sumário das propostas e à proposta consensual apresentadas na rodada anterior.

Tomando por base essa abordagem para apoiar a elaboração cooperativa de planos de riscos, novas funcionalidades foram desenvolvidas, algumas delas diretamente no ambiente ODE (por potencialmente se aplicarem a outras situações) e outras estendendo a ferramenta GeRis. A Figura 5 mostra um diagrama de casos de uso provendo uma visão geral dessas funcionalidades. As funcionalidades Agendar Reunião e Controlar Reunião são providas no ambiente, enquanto a elaboração de planos de risco é feita usando GeRis.

Gerente de Projeto Agendar Reunião

Moderador Controlar Reunião

Participante Participar da Reunião de Elaboração de Plano de Risco

Fig. 5. Visão geral das funcionalidades de apoio à Gerência de Riscos Cooperativa.

O caso de uso “Agendar Reunião” permite que o gerente do projeto agende uma reunião para a elaboração cooperativa de planos de riscos, definindo, dentre outras coisas, quem será o moderador da mesma (que pode, inclusive, ser ele próprio). Um fórum para discussão é criado e, a partir de então, o moderador controla a reunião.

O caso de uso “Controlar Reunião” envolve diversas funcionalidades, todas relacionadas ao controle de rodadas da reunião, permitindo, dentre outros, iniciar uma nova rodada, encerrar uma rodada e encerrar a reunião. A funcionalidade relativa a iniciar uma nova rodada é sempre usada no início do processo ou quando o moderador julgar que o consenso não foi atingido e que uma nova rodada deve ser realizada para avançar na realização da atividade. No caso do encerramento da reunião, três são as possibilidades: (i) aceitar a proposta de consenso sem alterações, elegendo-a como proposta consensual da reunião; (ii) com base nas opiniões dos participantes, o moderador pode optar por efetuar pequenas alterações na proposta de consenso e definir a proposta alterada como sendo o resultado final da reunião; ou (iii) encerrar a reunião sem um resultado, dado que não foi possível atingir uma proposta satisfatória.

Durante as rodadas de uma reunião, os participantes devem gerar suas propostas e, ao final da rodada, o moderador pode elaborar uma proposta de consenso. Para que os participantes e o moderador possam elaborar propostas bem fundamentadas, é necessário que tenham acesso ao maior número possível de informações sobre o projeto em questão. Assim, o caso de uso “Participar de Reunião de Elaboração de Plano de Riscos” envolve diversas funcionalidades, dentre elas:


307

• Consultar Recomendações: permite que os participantes tenham acesso às recomendações feitas pelo gerente do projeto e pelo moderador da reunião de modo a apoiá-los na elaboração de suas propostas.

• Consultar Caracterização do Projeto: em ODE, projetos podem ter associadas diversas características, tais como domínio da aplicação, paradigma, tipo de equipe etc. Essas informações são muito importantes para a gerência de riscos e, portanto, têm de estar acessíveis aos participantes da reunião.

• Editar Proposta: permite que os participantes elaborem suas propostas. Corresponde, de fato, ao uso da ferramenta GeRis com todas as suas funcionalidades. Vale destacar que uma proposta anteriormente elaborada pode ser como ser usada como ponto de partida.

• Analisar Impacto das Características do Projeto sobre a Proposta: permite que o participante indique o nível de impacto (um valor de 0 a 10) que cada característica do projeto exerceu sobre sua proposta, justificando.

• Submeter Proposta: permite que os participantes submetam suas propostas ao moderador e que o moderador submeta uma proposta de consenso para avaliação dos participantes.

• Consultar Proposta de Consenso: permite que o moderador e os participantes consultem a proposta de consenso corrente.

• Consultar Propostas Anteriores: permite que o moderador e os participantes consultem propostas submetidas em rodadas anteriores.

• Participar de Discussões: permite que o moderador e os participantes leiam as mensagens já postadas no fórum da reunião, postem novas questões nesse fórum e respondam a questões postadas no mesmo.

A elaboração cooperativa de planos de risco propicia aprendizado, tendo em vista que os participantes argumentam, justificam e discutem as propostas, buscando chegar a um consenso. Deixar esse conhecimento em nível de indivíduo em um ambiente que possui uma infra-estrutura de gerência de conhecimento (GC) seria um contra-senso. Assim, com o objetivo de levar esse aprendizado para o nível organizacional, um novo item de conhecimento informal foi adicionado à infra-estrutura de GC de ODE: as histórias de reunião.

Conforme apontado por Buckingham [22], o processo de software tem sido altamente orientado a artefatos, ou seja, focado em gerar e manter os artefatos durante o ciclo de vida, culminando no sistema final. Apesar desse processo atingir seu objetivo, as razões por trás das decisões que levaram aos artefatos permanecem implícitas e são, conseqüentemente, difíceis de recuperar e reutilizar. Assim, é importante, também, capturar e reusar o conhecimento envolvido na elaboração desses artefatos. Com a abordagem utilizada para a elaboração de planos de riscos de forma cooperativa isso é possível, já que pelo menos parte do raciocínio seguido pelos participantes (incluindo o moderador) foi capturada.

Assim, as histórias de reunião apresentam, em um relatório gerado dinamicamente, informações acerca de uma reunião, que são divididas em duas partes: dados gerais e dados das rodadas. Dentre os dados gerais, constam objetivo da reunião, número e papéis dos participantes, número de rodadas e de propostas geradas e resultado final. De cada rodada, são apresentadas as seguintes informações: propostas, justificativas, características consideradas, mensagens trocadas no fórum, resultado da rodada e dados sumários, tais como riscos mais apontados e probabilidades e impactos médios.


308

O formato do relatório das histórias de reunião foi elaborado com base no formato definido no trabalho de Torres [23], que aplica Histórias de Aprendizagem na captura e disseminação do conhecimento adquirido em projetos de Tecnologia de Informação.

5 Considerações Finais

Este trabalho apresentou a evolução da ferramenta de Gerência de Riscos de ODE (GeRis) para apoiar a elaboração cooperativa de planos de riscos e a captura do conhecimento envolvido.

Conforme citado na seção 2, há diversas ferramentas e ambientes de desenvolvimento de software que apóiam essa atividade, alguns inclusive com apoio de gerência de conhecimento, como é o caso da Estação TABA. Contudo, não encontramos em nenhuma das ferramentas pesquisadas funcionalidades como as propostas neste trabalho para a elaboração cooperativa de planos de riscos, com a captura do conhecimento envolvido nas decisões tomadas.

Como continuação deste trabalho, está-se estendendo a abordagem proposta para outras ferramentas de ODE, tal como a ferramenta de apoio a estimativas [19]. Além disso, está prevista a implantação de uma nova versão do ambiente ODE, contendo a nova versão de GeRis, nas organizações parceiras em abril de 2007, a partir de quando se pretende avaliar na prática a eficácia da abordagem proposta.

Agradecimentos

Este trabalho foi realizado com o apoio do CNPq e da CAPES, entidades do Governo Brasileiro dedicadas ao desenvolvimento científico e tecnológico, da FAPES, Fundação de Apoio à Ciência e Tecnologia do Espírito Santo, e das empresas VixTeam e Projeta, parceiras que têm financiado o projeto e dado feedback de sua aplicação a casos reais.

Referências

1. Pfleeger, S.L. (2001) Software Engineering: Theory and Practice, 2nd Edition, New Jersey: Prentice Hall.

2. Falbo, R.A., Ruy, F.B., Bertollo, G., Togneri, D.F. (2004) “Learning How to Manage Risks Using Organizational Knowledge”. Proceedings of the 6th International Workshop on Advances in Learning Software Organizations, LSO’2004, pp. 7-18, Banff, Canada.

3. Falbo, R.A.; Natali, A.C.C.; Mian, P.G.; Bertollo, G.; Ruy, F.B. (2003) “ODE: Ontology-based software Development Environment”, IX Congreso Argentino de Ciencias de la Computación, p. 1124-1135, La Plata, Argentina.

4. IEEE Std 1540-2001, “IEEE Standard for Software Life Cycle Processes – Risk Management”.

5. Sommerville, I. (2003) Engenharia de Software, São Paulo: Addison-Wesley, 6ª edição. 6. Pressman, R. S. (2002) Engenharia de Software, McGraw-Hill, 5ª edição.


309

7. Chrissis, M.B., Konrad, M., Shrum, S. (2003) CMMI: Guidelines for Process Integration and Product Improvement, Addison Wesley.

8. Subcomitê Setorial da Qualidade e Produtividade em Software, Programa Brasileiro da Qualidade e Produtividade (2002) Qualidade e Produtividade no Setor de Software Brasileiro – Pesquisa 2001.

9. Gruhn, V. (2002) “Process-Centered Software Engineering Environments: A Brief History and Future Challenges”, In: Annals of Software Engineering 14, p. 363-382.

10. Harrison, W., Ossher, H., Tarr, P. (2000) “Software Engineering Tools and Environments: A Roadmap”. Proceedings of The Future of Software Engineering (ICSE’2000). Limerick, Ireland, pp. 263 – 277.

11. Barros, M.O., Werner, C.M.L., Travassos G.H. (1999) “Risk Analysis: a key success factor for complex system development”. Proceedings of the 12th International Conference Software & Systems Engineering and their Applications, Paris, France.

12. Farias, L.L., Travassos, G.H., Rocha, A.R.C. (2003) “Managing Organizational Risk Knowledge”, Journal of Universal Computer Science, vol. 9, no. 7.

13. Rus, I.; Lindvall, M. (2002) “Knowledge Management in Software Engineering”. IEEE Software 19(3) May/Jun. pp 26-38.

14. Fischer, G., Ostwald, J. (2001) “Knowledge Management: Problems, Promises, and Challenges”. IEEE Intelligent Systems, v. 16, n. 1, pp. 60-72.

15. Natali, A.C.C., Falbo, R.A. (2002) “Knowledge Management in Software Engineering Environments”, Proc. of the 16th Brazilian Symposium on Software Engineering, Gramado, Brazil.

16. Jørgesen, M. (2004), “A Review of Studies on Expert Estimation of Software Development Effort”, Journal of Systems and Software, vol. 70, issue 1-2, pp. 37-60.

17. Falbo, R.A., Arantes, D.O., Natali, A.C.C. (2004) “Integrating Knowledge Management and Groupware in a Software Development Environment”. Proceedings of the 5th International Conference on Practical Aspects of Knowledge Management, Karagiannis, D., Reimer, U. (Eds.): LNAI 3336, Springer-Verlag Berlin Heidelberg, Austria, pp. 94-105.

18. Ruy, F.B., Falbo, R.A. (2006) “Tratamento Semântico de Conhecimento Organizacional em um Ambiente de Desenvolvimento de Software”, First Workshop on Ontologies and Metamodels for Software and Data Engineering, Florianópolis, Brazil.

19. Carvalho, V.A., Arantes, L.O., Falbo, R.A. (2006) “EstimaODE: Apoio a Estimativas de Tamanho e Esforço no Ambiente de Desenvolvimento de Software ODE”, Anais do V Simpósio Brasileiro de Qualidade de Software (SBQS´2006), Vila Velha, Brasil.

20. Falbo, R.A., Pezzin, J., Schwambach, M.M. (2005) “A Multi-Agent System for Knowledge Delivery in a Software Engineering Environment”, 17th International Conference on Software Engineering and Knowledge Engineering, Taipei, China, pp. 253 – 258.

21. Falbo, R.A., Guizzardi, G., Duarte, K.C. (2002) “An Ontological Approach to Domain Engineering”. Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering, SEKE'2002, Ischia, Italy, p. 351- 358.

22. Buckingham, S.S. (1996), “Design Argumentation as Design Rationale”, The Encyclopedia of Computer Science and Technology (Marcel Dekker Inc: NY), Vol. 35 Supp. 20, 95-128.

23. Torres, A.H.S. (2006) Captura e Disseminação do Conhecimento em Projetos de Software, Dissertação de Mestrado, Universidade Católica de Brasília, Brasília - DF, Brasil.


310



311

Um Modelo Integrado de Requisitos com Casos de Uso

Michel H. Fortuna1,3, Cláudia M. L. Werner1, Marcos R. S. Borges2

1COPPE/Programa de Engenharia de Sistemas e Computação 2IM-NCE/Programa de Pós-Graduação em Informática

Universidade Federal do Rio de Janeiro (UFRJ) 3Universidade Federal de Juiz de Fora (UFJF)

[email protected], [email protected], [email protected]

Resumo. Durante a fase de definição dos requisitos de um sistema, a utilização, em separado, de um modelo de casos de uso e de um modelo de objetos (de domínio), introduz a necessidade de se garantir a consistência entre eles. Isso pode ser evitado com um modelo integrado que permita a derivação do compor-tamento externo (modelo de casos de uso) e da funcionalidade interna e infor-mações de estado (modelo de objetos), como visões complementares. Este arti-go propõe uma especialização do modelo de casos de uso para fazer dele um modelo integrado de requisitos, a partir do qual, um modelo de objetos possa ser derivado. São apresentadas regras semiformais para essa derivação, assim como resultados de estudos realizados para avaliar o modelo proposto.

Palavras-chave: Modelo integrado de Requisitos; Casos de Uso; Nível Infor-macional de Objetivo; Interface Informacional.

1. Introdução

Vários autores têm mostrado a necessidade de se aplicar mais de uma técnica de mo-delagem para a especificação dos requisitos de um sistema [6] [20]. Em geral, utiliza-se o modelo de casos de uso (Use Cases - UCs) [9] [2] para especificar o comporta-mento externo do sistema, e o modelo de (classes de) objetos [17] para especificar a funcionalidade interna e informações de estado necessárias para uma adequada espe-cificação do comportamento externo.

A utilização de dois modelos introduz o problema da consistência entre eles. Em decorrência, várias propostas têm sido apresentadas para verificar ou promover essa consistência [6] [13] [1] [15]. Outra estratégia para atacar o problema, sugerida por Glinz [6] e bem menos explorada, é utilizar um único modelo integrado, a partir do qual, tanto o comportamento externo (casos de uso) quanto o comportamento interno e as informações de estado (modelo de objetos) possam ser derivados como visões complementares. Embora trabalhar com um modelo integrado possa ser mais comple-xo do que utilizar, separadamente, cada modelo que ele integra, a simples eliminação do problema da consistência entre modelos pode representar uma compensação muito favorável. E, através do mecanismo de visões, o modelador pode ainda trabalhar em um aspecto isolado, por exemplo, do modelo de objetos.

O presente artigo apresenta um modelo integrado para requisitos. Ele resulta da es-pecialização do modelo de casos de uso, pela introdução de uma regra de elicitação de casos de uso e pela exigência de um maior rigor na descrição dos fluxos de informa-ções trocados entre o sistema e as entidades externas que com ele interagem (atores).


313

O restante do artigo está organizado em mais cinco seções. A seção 2 descreve a especialização do modelo de casos de uso para fazer dele um modelo integrado de re-quisitos. A seção 3 apresenta um conjunto de regras para a derivação da visão do mo-delo de objetos, a partir do modelo de casos de uso especializado. A seção 4 descreve alguns estudos realizados para avaliar o modelo proposto. A seção 5 discute trabalhos relacionados e, por fim, a seção 6 resume as principais contribuições do artigo e suge-re desenvolvimentos futuros.

2. Casos de Uso e o Modelo Integrado de Requisitos

A especialização proposta para o modelo de casos de uso, visando torná-lo um modelo integrado de requisitos, envolve duas providências: (1) a fixação de um nível especial de abstração para elicitar os casos de uso (UC’s); e (2) um maior detalhamento e significado formal na especificação das informações que fluem entre o sistema e seus atores, em cada UC. Elas estão descritas nas subseções seguintes.

2.1 O Nível Informacional de Objetivos (NIO)

O NIO é o nível de abstração para objetivos dos atores, induzido pelos eventos autô-nomos gerados por eles. Evento autônomo é uma intervenção no sistema, de iniciativa de um ator, que dispara um processo do sistema responsável pelo alcance de um obje-tivo. Se um evento serve apenas para dar andamento a um processo iniciado anterior-mente, ele não é um evento autônomo. Para ilustrar, considere um sistema de terminal de auto-atendimento bancário. O usuário desse sistema, ao introduzir seu cartão ban-cário no leitor do terminal está gerando um evento autônomo pois, tal evento, de sua exclusiva iniciativa, dispara o processo subjacente ao objetivo de, por exemplo, retirar dinheiro do terminal. Já outros eventos, tais como fornecimento de senha, escolha da quantia a retirar, confirmação da validade do cartão e aprovação da retirada pelo ban-co, não são eventos autônomos, pois são requeridos pelo sistema para concluir a exe-cução do processo subjacente ao objetivo de retirar dinheiro do terminal, iniciada com a introdução do cartão no leitor do terminal. Diz-se que esses eventos são subassumi-dos pelo evento (autônomo) de introdução do cartão. A autonomia de um evento é de-terminada pelo modelador, com base no conhecimento do domínio do sistema que es-tá sendo modelado.

No modelo integrado de requisitos proposto, os UC’s correspondem, de forma biu-nívoca, aos objetivos do NIO; ou seja, são exatamente aqueles ativados pelos eventos autônomos. Esse critério de elicitação de UC’s pode ser considerado uma especializa-ção do critério comumente recomendado na literatura − o do UC possuir valor para algum stakeholder [10] [2] [11] [12] [17]. Isso porque, um UC do NIO sempre terá valor para um ator, pois, por definição, corresponderá a um sentimento de “missão cumprida” (objetivo alcançado) de um ator, ou mais especificamente, ao sentimento de que a sua parte ou responsabilidade no fluxo de trabalho (workflow) está concluída, e que, a partir daí, outros atores (e, eventualmente, ele próprio) podem dar prossegui-mento a esse fluxo. Este é um critério mais objetivo de valor, que os stakeholders po-dem facilmente utilizar para determinar os UC’s, pois exprime algo que faz parte da realidade do seu dia-a-dia, ou seja, a divisão de trabalho entre eles. Além disso, já que um evento autônomo abstrai todos os outros eventos por ele subassumidos, os UC’s


314

assim elicitados realizam toda a funcionalidade do sistema, constituindo um particio-namento funcional completo do mesmo.

No modelo integrado proposto, o NIO tem papel-chave. Em primeiro lugar, como a ativação dos UC's desse nível depende da iniciativa de algum ator, nenhuma suposi-ção geral poderá ser embutida no sistema, sobre a proximidade (coexistência), no tempo, dos processos a eles subjacentes. Isso significa que toda informação a ser co-municada entre os processos deve ser considerada como informação a ser persistida entre estados do sistema (informação de estado). Em segundo lugar, como os UC's do NIO visam alcançar objetivos dos atores, realizando algo de sua responsabilidade no workflow desempenhado com o auxílio do sistema, essa informação de estado partici-pará de estados estáveis1 do sistema, e como tal, deve fazer parte do modelo de obje-tos, como um atributo de classe.

2.2 Interface Informacional de Casos de Uso

A informação que flui entre o sistema e seu ambiente (atores) durante a execução de um UC é aqui denominada de interface informacional (II) do UC. A maior parte das propostas de modelagem com UC’s dá pouca ênfase ao detalhamento dessa interface, conforme atestado por Lauesen [14, pgs. 100, 132, 432] e Hay [8, pgs. 43, 185, 240]. Nessa categoria se incluem propostas como as contidas em [9] [10] [12] [3] [18] e [19]. Uma exceção é a proposta de Bittner & Spence [2], endossada por Jacobson [11]. Segundo esses autores, um UC deve especificar completamente as suas entradas e saídas.

O detalhamento preciso da II de cada UC é, obviamente, um pré-requisito para a determinação das informações de estado (atributos de classe) propiciada pelos UC’s do NIO. Uma proposta de detalhamento que atende essa finalidade é apresentada por Fortuna & Borges [4]. Nela, a especificação da II é constituída de duas partes: a) es-pecificação de fluxos, e b) dicionário de itens elementares, ilustradas na Figura 1 e na Tabela 1, respectivamente, para um sistema simples de gerência de restaurante.

A especificação dos fluxos (Fig.1) utiliza uma linguagem concisa e estruturada com vários símbolos especiais. Os sinais e indicam, respectivamente, fluxo de entrada e fluxo de saída de informações, do ponto de vista do sistema. Uma informa-ção ou item em um fluxo pode ser elementar (indivisível) ou composto (agregado de outras itens elementares ou compostos). Os itens compostos também são chamados de pacotes, e indicados pelo símbolo . A notação utilizada para descrever a composi-ção de um pacote é a seguinte: + significa composição, n{x}m significa de n a m ocor-rências (ou repetições) de x, ( ) é utilizado para agrupar itens, | significa ou e [ ] deli-mita itens condicionais, ou seja, que nem sempre estarão presentes (podem não ser pertinentes, dependendo do contexto). Item calculado é todo item presente em um fluxo de saída (item de saída), cujo valor resulta de um cálculo efetuado pelo sistema. Um tipo especial de item calculado são os itens identificadores. Eles se destacam pelo nome iniciado por id_ (por exemplo, id_cliente), e representam abstrações do domínio da aplicação incluídas na especificação de requisitos. Essa linguagem semiformal possibilita um maior grau de automatização na obtenção da visão de objetos do mode-lo integrado (seção 3). 1 Estado vigente no momento em que um objetivo de ator é alcançado.


315

ATOR: Cliente UC 1: Abrir pedido pedido = dt_pedido + id_mesa + itens_ped

itens_ped = 1{id_item + quant_item} id_pedido

ATOR: Cliente UC 2: Cancelar pedido cancela_ped = id_pedido

ATOR: Cliente UC 3: Pedir a nota solicitacao_nota = id_pedido + [id_cliente] nota = id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente]

itens_nota = 1{id_item + cat_item + nome_item + pç_unit + quant_item + vl_item}

ATOR: Cliente UC 4: Pagar a nota pagamento = id_pedido + vl_entregue + dt_pagto troco

ATOR: Cliente UC 5: Pendurar a nota pendura = id_pedido + id_cliente

ATOR: Gerente UC 6: Cadastrar cliente habitual cliente = nome_cliente + tel_cliente id_cliente

ATOR: Gerente UC 7: Atualizar o cardápio item_consumo = nome_item + pc_unit + cat_item + descr_item id_item

ATOR: Gerente UC 8: Solicitar consumo diário solic_consumo = dt_emissao + dt_consumo consumo_dia = dt_emissao + dt_consumo + consumo_itens

consumo_itens = 0{cat_item + {id_item + nome_item + quant_item} }2

ATOR: Gerente UC 9: Solicitar receita solic_receita = dt_emissao + periodo_apur

periodo_apur = dt_inicio + dt_fim receita = dt_emissao + periodo_apur + vl_consumo + receita_realiz + receita_pend + receta_txServ +

receita_total

ATOR: Gerente UC 10: Cadastrar mesa mesa = nr_mesa id_mesa

ATOR: Gerente UC 11: Solicitar relação de notas penduradas solic_penduras = dt_emissao + periodo_apur

periodo_apur = dt_inicio + dt_fim penduras = dt_emissao + periodo_apur + {id_cliente + nome_cliente + tel_cliente + notas_pend +

vl_pendCli} + vl_pend notas_pend = 1{id_pedido + dt_pedido + nr_mesa + itens_nota + vl_nota} itens_nota = 1{id_item + cat_item + nome_item + pç_item + quant_item + vl_item}

Figura 1. Especificação dos fluxos da aplicação Restaurante


316

Tabela 1. Dicionário de itens elementares do UC 3: Pedir a nota (parcial)

Ator: Cliente UC 3: Pedir a nota Nome Descrição Tipo Domínio

id_pedido Identificador do pedido da nota a emitir. Nr. Natural quant_item Quantidade consumida de um item. Nr. Natural vl_item Valor do consumo de um item. Preço unitário

× quantidade consumida do item. Moeda

cat_item Categoria do item de consumo Texto {prato, bebida}

3. Derivação do Modelo de Objetos de Domínio O objetivo desta seção é apresentar um conjunto de regras para a derivação de um modelo de objetos de domínio (MOD), a partir do modelo especializado de UC’s pro-posto na seção anterior. Elas constituem uma evidência da integração alcançada. São também discutidas heurísticas capazes de apoiar o emprego, ou complementar os re-sultados, das regras (subseção 3.2).

3.1 Regras de Derivação

A apresentação das regras está dividida em 4 seções − uma para cada tipo de elemento do modelo de classes, que elas ajudam a determinar: classes, associações, atributos e operações. A especificação dos fluxos da interface informacional do sistema Restau-rante (Figura 1) é utilizada para exemplificar a aplicação das regras. O modelo de ob-jetos resultante é apresentado na Figura 2 (no final desta seção).

3.1.1 Classes de Objetos As classes são determinadas por uma categoria de (itens elementares) identificadores, formada pelos identificadores gerados nos UC’s. Um identificador é gerado em um UC quando o seu valor é estabelecido durante a execução do UC. Por exemplo, id_cliente é um identificador gerado no UC 6 (Cadastrar cliente habitual - Fig.1), pa-ra servir de referência a um objeto (cliente) criado durante o processamento do UC. Regra 1. Cada identificador gerado dá origem a uma classe de objetos.

As classes obtidas a partir dos identificadores gerados representam abstrações utili-zadas e compartilhadas pelos especialistas de domínio, que participam da definição dos requisitos do sistema. Assim, elas têm boa chance de serem classes úteis, com a-tributos e operações significativas no domínio [16, pg. 733].

No sistema Restaurante (Fig.1): id_pedido, identificador gerado no UC 1 - Abrir pedido, determina a classe Pedido. As demais classes determinadas dessa forma são: Cliente (id_cliente, UC 6), Item (id_item, UC 7) e Mesa (id_mesa, UC 10).

3.1.2 Associações entre Classes Os relacionamentos entre os diversos objetos manipulados pelo sistema estarão repre-sentados na interface informacional (II) dos UC’s, uma vez que eles devem ser, ne-cessariamente, informados pelos atores ao sistema. Por exemplo, no sistema Restau-rante, o relacionamento entre um pedido e a mesa no qual ele é feito, precisa ser informado ao sistema.

Como os objetos são representados por seus identificadores, os relacionamentos entre objetos estarão representados pela ocorrência de dois ou mais identificadores na interface informacional de cada UC.


317

Regra 2a. Todo par <id1, id2>, que possa ser formado com id1 sendo um identificador gerado presente no fluxo de saída do UC, e id2 um identificador presente no fluxo de entrada, determina uma associação entre as classes identificadas por id1 e id2. No caso de mais de um identificador gerado, as associações correspondentes a pares que com-partilham o mesmo id2 tendem a ser redundantes.

No sistema Restaurante (Fig.1): o UC 1 permite formar os pares de identificadores <id_pedido, id_mesa> e <id_pedido, id_item>. Isso determina as associações Pedido-Mesa e Pedido-Item, respectivamente. Regra 2b. Quando os identificadores ocorrerem apenas em um dos fluxos do UC (considerando, para o fluxo de saída, apenas os identificadores gerados2), todo par de identificadores determina uma associação entre as classes por eles identificadas. Em fluxos com mais de dois identificadores, algumas dessas associações tendem a ser re-dundantes.

No sistema Restaurante: o par de identificadores <id_pedido, id_cliente>, presente nos UC’s 3 (Pedir a nota) e 5 (Pendurar a nota), determina a associação Pedido-Cliente.

Existem ainda regras para determinar (parcialmente) a multiplicidade das associa-ções. Elas foram omitidas aqui por falta de espaço, mas podem ser consultadas em [5].

3.1.3 Atributos das Classes Graças à restrição aos UC’s do NIO (seção 2.1), as informações a serem persistidas como atributos no modelo de objetos de domínio (MOD) correspondem aos itens de informação cujo valor entra ou é calculado em um UC, e depois precisa ser recupera-do em outro UC. Regra 3a (persistência). Todo item elementar não-identificador e de entrada, que for necessário em um UC distinto daquele em que o item entrou no sistema, deve ser per-sistido; caso contrário, não deve ser persistido.

No sistema Restaurante (Fig.1): o item elementar dt_pedido entra no UC 1 (fluxo de entrada pedido) e é reutilizado (consultado) nos UC’s 3 e 11. Portanto, deve ser persistido. Por outro lado, vl_entregue e descr_item não precisam ser persistidos; o primeiro porque é utilizado apenas no próprio UC em que entrou (UC 4, para o cálcu-lo do troco), e o segundo por não ser utilizado em UC algum, nem mesmo no UC em que entrou no sistema3 (UC 7). Regra 3b (persistência). Para todo item elementar não-identificador, de saída e cal-culado, cujo valor originalmente calculado for necessário em outro UC, se houver chance desse valor não poder ser reproduzido nesse outro UC, ele deve ser persistido; senão, ele não precisa ser persistido.

No sistema Restaurante (Fig.1): o item elementar (não-identificador) de saída vl_item, calculado4 no UC 3, precisa ser recuperado no UC 11, para fins da emissão da relação de notas a pagar (penduras). Mas não se pode garantir que o valor de vl_item, calculado no momento em que o cliente pede a nota (UC 3), possa ser repro-duzido mais adiante, quando o gerente desejar a relação de notas a pagar (UC 11). Is-so porque, entre um instante e outro, o preço unitário do item pode ser alterado (atra- 2 Para se ter associações inéditas. 3 Uma potencial falha da especificação de requisitos, que esta regra ajuda a detectar. 4 Pela multiplicação do preço do item (prato ou bebida) pelo nr. de unidades consumidas.


318

vés do UC 7 - Atualizar o cardápio). Portanto, o vl_item calculado no UC 3 precisa ser persistido.

Uma vez decidida a persistência de um item (regras 3a e 3b), o próximo passo é a-locar o item como atributo de uma das classes determinadas com a regra 1 (seção 3.1.1). Na modelagem com UC’s do NIO, a única forma de estabelecer a ligação entre um item e o objeto do qual representa uma propriedade (atributo), é incluir a identifi-cação do objeto na mesma interface informacional que contém o item (ou seja, ambos devem participar da II do mesmo UC). É o que acontece, por exemplo, na interface informacional do UC 4, que inclui, além de dt_pagto, id_pedido para identificar o pe-dido que está sendo pago. A regra a seguir traduz isso. Ela utiliza o conceito de clas-ses alcançadas por um identificador, que inclui: a) a classe que ele identifica, e b) as classes de associação5 nas quais ele participa como um dos identificadores (se existir). Regra R3c (alocação). Cada item a persistir, presente na interface informacional de um UC, deve ser alocado como atributo de uma das classes alcançadas pelos identifi-cadores presentes nessa mesma interface.

No sistema Restaurante, por exemplo: dt_pedido e quant_item (UC 1) devem ser alocados, respectivamente, nas classes Pedido (identificada por id_pedido), Pedido-Item (classe de associação, alcançada pelo identificador id_pedido.); vl_item (UC 3) deve ser alocado na classe Pedido-Item (classe de associação, alcançada pelo identifi-cador id_pedido); e dt_pagto (UC 4) na classe Pedido; etc.

A modificação do estado do sistema, isto é, de um objeto ou de uma associação en-tre objetos, ocorre, comumente, nos UC’s cuja interface informacional contém algum item de informação a persistir. Entretanto, mesmo UC’s sem essa característica po-dem produzir mudança de estado. Isso porque, a simples ocorrência do evento dispa-rador do UC pode implicar a mudança. Obviamente, essa mudança também é imple-mentada via um atributo do objeto (ou da associação), que pode ser um atributo criado anteriormente para persistir um item da interface, ou um atributo especialmente criado para refletir a mudança. Esse último tipo de atributo será distinguido dos demais atri-butos (ordinários) pela denominação atributo de estado.

Regra R3d (atributo de estado). Nos UC’s com interface informacional constituída apenas de fluxo de entrada e contendo exclusivamente identificadores, deve ser intro-duzido um atributo de estado em uma das classes alcançadas por esses identificadores.

No MOD do sistema Restaurante (Fig.1), os atributos cancelado? e pendurado? foram introduzidos na classe Pedido, pela utilização dessa regra nos UC’s 2 (Cance-lar pedido) e 5 (Pendurar a nota), respectivamente.

3.1.4 Operações das Classes As operações a serem incluídas no modelo de classes de domínio deverão possibilitar: a) Realizar as mudanças de estado no sistema, pela criação e alteração de objetos (re-

gras 4a e 4d); e b) Realizar as mudanças de estado no ambiente do sistema, pela produção das saídas

previstas na interface informacional, representadas pelos itens calculados não per-sistidos6 e fluxos de saída (regras 4b e 4c).

5 Representam uma associação entre objetos de duas outras classes (não necessariamente dis-

tintas). Exemplo: a classe Pedido-Item (vide Figura 2). 6 Os itens calculados persistidos não geram operações, pois estão disponíveis na interface da

classe como atributos.


319

Regra R4a. Todo identificador gerado produz uma operação construtora na classe i-dentificada por esse identificador.

No sistema Restaurante, essa regra determinou 4 operações construtoras: Pedido( ) (UC 1), Cliente( ) (UC 6), Item( ) (UC 7) e Mesa( ) (UC 10), nas respectivas classes homônimas.

Regra R4b. Todo item calculado não persistido produz uma operação a ser incluída em uma das classes alcançadas pelos identificadores presentes na interface informaci-onal do UC, ou na falta desses, a ser incluída na classe que representa o sistema.

No sistema Restaurante: operações vl_consumo( ), vl_realiz( ), receita_pend( ), re-ceita_txServ( ), receita_total( ), e vl_pend( ) (as 5 primeiras provenientes do UC 9, e a última do UC 11), alocadas na classe Restaurante; vl_nota (UC 3), quant_item( ) (UC 8), e vl_pendCli( ) (UC 11), alocadas nas classes Pedido, Item e Cliente, respectiva-mente; e troco( ) (UC 4), alocada na classe Pedido.

Regra R4c. Todo fluxo de saída, presente em UC cujo processamento não produz mudança de estado no sistema7 (tipicamente, UC’s de consulta) e que não se resuma a apenas um único item não persistido8, dá origem a uma operação para produção do fluxo, a ser incluída em uma das classes alcançadas pelos identificadores presentes na interface informacional do UC, ou na falta desses, a ser incluída na classe que repre-senta o sistema.

No sistema Restaurante: operações consumo_dia( ) (UC 8), receita( ) (UC 9) e penduras( ) (UC 11), alocadas na classe Restaurante.

Regra R4d. Todo UC que não tenha sido contemplado com operações originadas pe-las regras (R4a) e (R4c), dá origem a uma operação para realizar mudança no estado do sistema, a ser incluída em uma das classes alcançadas pelos identificadores presen-tes na interface informacional do UC, ou na falta desses, a ser incluída na classe que representa o sistema.

No sistema Restaurante: operações cancelar( ) (UC 2), pedirNota( ) (UC 3), pa-garNota( ) (UC 4), e pendurarNota( ) (UC 5), alocadas na classe Pedido.

A visibilidade das operações deve ser pública, uma vez que todas elas se originam diretamente do modelo de requisitos do sistema. As operações determinadas pelos i-tens calculados não persistidos (regra R4b) retornam o valor calculado para o item. Os argumentos das operações podem ser obtidos a partir dos itens presentes no fluxo de entrada dos UC’s. A especificação (tipo e valor inicial) dos argumentos das operações é feita com base nas informações de tipo e domínio do item correspondente, constan-tes no dicionário de itens elementares da aplicação. Por exemplo, a partir da interface informacional (Fig.1) e do dicionário do UC 3 (Tabela 1), chega-se às especificações: pedirNota(in cliente: Cliente) e vl_nota( ): Currency.

A Figura 2 (adiante) mostra o resultado da aplicação das regras discutidas nessa seção, à interface informacional do sistema Restaurante, definida na seção 2.2 (Fig.1).

7 Não possui identificador gerado, nem item persistido ou atributo de estado, e não altera o

valor de algum item persistido. 8 Já tratado na regra R4b.


320

+ M e s a ( in n rM e s a : B y te )-n r_ m e s a : B y te

M e s a

+ P e d id o ( in d tP e d id o : D a te , in m e s a : M e s a , in ite n s P e d : O b je c t)+ t ro c o ( in v lE n tre g u e : C u r re n c y ) : C u r re n c y+ v l_ n o ta ( ) : C u r re n c y+ c a n c e la r ( )+ p e d irN o ta ( in c lie n te : C lie n te )+ p e n d u ra rN o ta ( in c lie n te : C lie n te )+ p a g a rN o ta ( in d tP a g to : D a te )

-d t_ p e d id o : D a te-d t_ p a g to : D a te-c a n c e la d o ? : b o o l-p e n d u ra d o ? : b o o l

P e d id o

+ C lie n te ( in n o m e C li : S t r in g , in te lC li : S t r in g )+ v l_ p e n d C li( in d t In ic A p u r : D a te , in d tF im A p u r : D a te ) : C u r re n c y

-n o m e _ c lie n te : S t r in g- te l_ c lie n te : S t r in g

C l ie n te

+ Ite m ( in n o m e Ite m : S t r in g , in p c U n it Ite m : C u r re n c y , in c a t Ite m : S t r in g , in d e s c r Ite m : S t r in g )+ q u a n t_ ite m ( in d tC o n s u m o : D a te ) : u n s ig n e d s h o r t

-n o m e _ ite m : S tr in g-p c _ u n it : C u r re n c y-c a t_ ite m : S tr in g

It e m

1 . .1

0 . . *0 . . *

0 . .1

q u a n t_ ite m : B y tev l_ ite m : C u r re n c y

P e d id o - Ite m

0 . . *

1 . . *

+ R e s ta u ra n te ( )+ v l_ c o n s u m o ( )+ c o n s u m o _ d ia ( )+ re c e ita _ re a liz ( )+ re c e ita _ p e n d ( )+ re c e ita _ txS e rv ( )+ re c e ita _ to ta l( )+ re c e ita ( )+ v l_ p e n d ( )+ p e n d u ra s ( )

-p e d id o s : O b je c t-m e s a s : O b je c t-c lie n te s : O b je c t-c a rd a p io : O b je c t

R e s ta u r a n te

Figura 2. Visão do modelo de classes do sistema Restaurante 9

3.2 Análise das Regras e seus Padrões Sintáticos

A seção anterior (3.1) apresentou 11 regras para a derivação da visão de objetos do modelo integrado de requisitos proposto. Essas regras cobrem todos os principais e-lementos de um modelo de classes de objetos: classes, associações, atributos e opera-ções. Elas podem ser categorizadas segundo o grau de determinismo e automatização na obtenção dos resultados da sua aplicação.

As regras determinísticas são aquelas capazes de determinar (individualizar) o e-lemento ou aspecto por ela tratado, do modelo de objetos. Esse é o caso, por exemplo, da regra R3a (seção 3.1.3), que sempre permite determinar a persistência (ou a não-persistência) dos itens de entrada, presentes na interface informacional dos UCs. Já a regra R4b (seção 3.1.4) é um exemplo de regra não-determinística, pois não é capaz, no caso geral, de determinar uma classe única, à qual alocar o item a persistir. Além de R3a, as seguintes regras são determinísticas: R1, R2a, R2b, R3b, e R4a. As demais são não-determinísticas.

As regras automatizáveis são aquelas cuja aplicação pode ser decidida e realizada de forma automática (sem intervenção do modelador). As regras R3c, R3d, R4a, R4b, R4c e R4d são automatizáveis. As demais são não-automatizáveis. Por exemplo, a 9 Por falta de espaço, omitimos a assinatura das operações da classe Restaurante.


321

aplicação da regra R3a exige decidir sobre se um item é necessário (ou não) em outro UC distinto daquele em que ele entrou no sistema. Para isso é preciso a intervenção do modelador.

Para auxiliar o modelador na aplicação das regras não-determinísticas e/ou não-automatizáveis, foram identificadas algumas heurísticas, aproveitando o formalismo e a estruturação da descrição da interface informacional dos UC’s (seção 2.2). Essas heurísticas se baseiam na ocorrência de padrões sintáticos na interface, capazes de sugerir um resultado específico para a aplicação de uma regra. Por exemplo, na apli-cação da regra R3a acima mencionada, que é não-automatizável, a ocorrência do se-guinte padrão sintático sugere a necessidade de persistir um item elementar de infor-mação: itens elementares homônimos, em UC’s distintos, com pelo menos um deles no fluxo de entrada de um UC, e outro no fluxo de saída de outro UC. Isso é uma heu-rística porque o modelador não está obrigado a utilizar o mesmo nome toda vez que se referir a uma mesma informação em UC’s distintos (apesar disso ser recomendável). A vantagem das heurísticas decorre do fato de que, tanto o reconhecimento dos pa-drões quanto sua própria aplicação, podem ser automatizados. Até o momento foram identificados 14 padrões sintáticos para as regras [5].

4 Estudos Realizados com o Modelo Integrado

Até o momento foram realizados dois estudos para avaliação do modelo integrado proposto, que descrevemos a seguir.

O primeiro estudo foi um experimento que teve por objetivo testar o conceito de eventos autônomos (seção 2.1), como critério para o particionamento de um sistema em UC’s, em comparação ao critério usual baseado no valor do UC para algum stake-holder [2]. Mais especificamente, o estudo visou avaliar, comparativamente, a cober-tura funcional e a granularidade dos particionamentos obtidos com cada um desses critérios. Para fins do experimento, a cobertura funcional de um particionamento foi medida pelo número de funções cobertas pelos UC’s presentes no particionamento, dentre uma lista de funções extraídas de uma especificação preliminar do sistema (texto em linguagem natural), que serviu de ponto de partida para os particionamen-tos. A granularidade de um particionamento foi medida pelo número de UC’s elicita-dos no particionamento. A hipótese testada no experimento é que o critério de eventos autônomos produz particionamentos com maior cobertura funcional, e de grão mais fino (mais UC’s)10. Participaram os alunos da disciplina de modelagem de sistemas, do 2° ano de um curso de graduação em Ciência da Computação, totalizando 35 alu-nos, distribuídos em duas turmas, uma diurna e outra noturna (20 e 15, respectiva-mente). A preparação envolveu a elaboração de um questionário para a caracterização dos participantes, que mostrou a falta de conhecimento e experiência prévias dos mesmos, na modelagem com UC’s e classes de objetos. Foram feitas duas execu-ções (trials), uma em cada turma. A turma diurna utilizou o critério de valor, enquan-to que a noturna utilizou o critério dos eventos autônomos. Os instrumentos utilizados por ambas as turmas foram: (1) uma especificação em texto livre (não estruturado) 10 Uma vez que se utilizou as recomendações de Bittner & Spence [2] para a elicitação dos

UC’s (critério de valor).


322

descrevendo um sistema de biblioteca, e (2) um conjunto de diretrizes para utilização do critério de particionamento atribuído à turma.

O experimento se enquadra como um estudo multi-test within object (1 objeto e mais de 1 participante) [22]. A análise estatística da variável cobertura mostrou que as amostras utilizadas têm uma distribuição normal (Teste T, NS11 = 5%) e são homo-cedásticas (Teste de Levene, NS= 5%), sem outliers (no diagrama boxplot). A análise de comparação das médias das duas amostras permitiu concluir que elas são diferen-tes a um NS= 5% (teste paramétrico T). A Tabela 2 (adiante) apresenta o comple-mento da análise do Teste T. As médias de cobertura foram de 12,93 funções cober-tas no critério de eventos autônomos, contra 10,35 funções cobertas no critério de valor. Conclui-se, portanto, que o critério dos eventos autônomos produz cobertura funcional maior (aproximadamente 25% maior) do que o critério de valor, a um nível de significância de 5%. Além disso, a cobertura variou menos no critério dos eventos autônomos (menor desvio padrão).

Tabela 2. Estatísticas do Estudo 1 - Variável cobertura Critério Nr. de Partic. Média Desv. Padrão Méd. Erro Pad.

Valor 20 10,35 2,961 0,662 Ev. Autônomos 15 12,93 2,314 0,597

A análise estatística da variável granularidade mostrou que as amostras utilizadas

têm distribuição normal e são homocedásticas. Embora a inspeção visual do diagrama boxplot indique uma maior granularidade do critério de eventos autônomos (sem ou-tliers), o resultado do Teste T para comparação das médias não confirmou isso, a um nível de significância de 5%. Como o resultado estatístico sobre granularidade não confirmou a hipótese do estudo, e vai contra a nossa experiência com os critérios, pre-tendemos repetir o estudo, dedicando uma atenção especial à capacitação dos partici-pantes na utilização dos critérios.

O segundo estudo foi informal, realizado com a finalidade de avaliar, preliminar-mente, a compreensibilidade e usabilidade das regras (seção 3.1) (com seus padrões sintáticos − seção 3.2), bem como ter uma primeira avaliação do grau de uniformida-de do modelo de classes resultante da sua aplicação. Participaram do estudo, em mo-mentos diferentes, dois analistas graduados em Ciência da Computação, ambos com 2 anos de experiência no desenvolvimento de sistemas e 1 ano na leitura de especifica-ções informacionais de UC’s (seção 2.2). Primeiramente, um dos analistas aplicou as regras utilizando a especificação informacional de um sistema de biblioteca com 19 UC’s. O modelo de classes obtido foi comparado com o modelo de classes construído previamente pelo experimentador12, também com a aplicação das regras. As discre-pâncias detectadas revelaram dificuldades do analista na compreensão de algumas re-gras, o que motivou a revisão do manual de regras. Posteriormente, e com o manual revisado, o outro analista executou o mesmo estudo. Para avaliar a uniformidade dos resultados, foram contadas as discrepâncias entre o modelo obtido por cada analista e o modelo construído pelo experimentador. Consideramos discrepância, para fins dessa avaliação, os elementos (classes, atributos, associações e operações) a mais ou faltan-

11 Nível de Significância. 12 Primeiro autor deste artigo.


323

do em relação ao modelo produzido pelo experimentador. A Tabela 3 apresenta os resultado dessa avaliação.

Tabela 3. Resultados do Estudo 2 Analista 1 Analista 2 Legenda

Elementos #E #D %S #D %S Classes 5 0 100 0 100

Associações 11 1 91 0 100 Atributos 20 4 80 0 100 Operações 41 4 90 1 97

#E: Nr. de elementos no modelo do ex-perimentador.

#D: Nr. de discrepâncias. %S: Perc. de sucesso em reproduzir o

modelo do experimentador. Com os resultados favoráveis obtidos nessa primeira avaliação, pretendemos reali-

zar um estudo experimental envolvendo mais participantes e comparando a técnica proposta, e seus resultados, com aqueles obtidos empregando outra técnica usual no contexto de UC’s.

5. Trabalhos Relacionados

Existem várias propostas relacionadas à integração do modelo de casos de uso com o modelo de classes de um sistema. Glinz [6], por exemplo, propõe a elaboração dos dois modelos em paralelo, guiada por uma série de diretrizes para mantê-los consis-tentes entre sí. Em [13], os dois modelos também são construídos separadamente, para em seguida serem verificados quanto a consistência, com base em um modelo inter-mediário ("activity graphs") elaborado a partir dos UC's. Ambas as propostas diferem da nossa por trabalharem com dois modelos em separado.

Mais próximas da proposta deste artigo estão aquelas que procuram gerar o modelo de classes a partir do modelo de UC's. Nessa categoria se posicionam, por exemplo, as propostas contidas em [1], [15] e [21]. Entretanto, enquanto a proposta deste artigo utiliza um modelo de UC's incrementado e transformado em um modelo integrado, aquelas propostas utilizam o modelo padrão de UC's. Em [1], o modelo de classes ge-rado é bastante incompleto, conforme evidencia a Tabela 4 a seguir. O mesmo acon-tece em [21]. Mais completo é o modelo de classes gerado em [15], mas a custa de uma dependência excessiva do modelador, que precisa interpretar as respostas à uma série de perguntas formuladas aos atores do sistema. Essas deficiências decorrem, em nossa opinião, da falta de elementos formalmente identificáveis nos UC's, que por fi-carem escondidos nas descrições em linguagem natural, tornam difícil a geração au-tomática do modelo de classes.

Tabela 4. Elementos presentes no modelo de classes das diferentes propostas [6] [13] [1] [15] [21] [A]

Classes x x x x x x Legenda: Atributos x x x x [6]: (Glinz, 2000)

de estado x [13]: (Kösters et al., 2001) Associações x x x x [1]: (Biddle et al., 2002) Multiplicidades x x [15]: (Liang, 2003) Operações x x x x x x [21]: (Subramaniam et al, 2004)

Assinatura x [A]: Proposta do artigo


324

Glinz [7] também adota, como nós, uma abordagem de modelo integrado para re-quisitos, mas a sua proposta difere da nossa em vários outros aspectos. Ela não utiliza o modelo de UC's como base de integração. Além disso, busca uma integração mais abrangente, envolvendo estrutura, dados, comportamento, interação com o usuário, etc., objetivando a geração de diversas visões, em diferentes níveis de abstração.

Uma pergunta pertinente é: que tipo de contribuição o modelo integrado proposto representa para os trabalhos em MDA (Model Driven Architecture) [23]? Segundo Berrisford [24], duas questões (relacionadas a requisitos) precisam ser respondidas para se construir um modelo que possa ser transformado em um sistema de processa-mento de dados: (1) que unidades de trabalho os atores do sistema invocam ou reque-rem?; e (2) que dados precisam ser persistidos em uma estrutura de dados coerente, para que aquelas unidades de trabalho possam ser realizadas? A especialização aqui proposta para os UC's produz respostas para ambas as questões. Em vista disso, acre-ditamos que o modelo integrado resultante dessa especialização está em melhores condições para apoiar transformações CIM → PIM13, do que o modelo de UC's.

6. Conclusão e Trabalhos Futuros Neste artigo propomos um modelo integrado para especificação dos requisitos de um sistema, obtido por especialização do modelo de casos de uso, com a fixação de um nível especial para elicitação dos casos de uso e um maior detalhamento e significado formal na especificação dos fluxos de informação trocados entre o sistema e seus ato-res. Com isso pudemos estabelecer um conjunto de regras e heurísticas (padrões sintá-ticos) para a derivação semi-automática de um modelo de (classes de) objetos a partir do modelo integrado, demonstrando assim, a integração alcançada.

Além de evitar a necessidade de um tratamento independente para o problema da consistência quando se utilizam dois modelos em separado (qualidade inerente a toda solução de integração de modelos), a nossa solução traz ainda como vantagens claras ser uma especialização do modelo de casos de uso e ter a capacidade de derivar, au-tomaticamente14, a maior parte dos principais elementos de um modelo de classes, sem cobrar para isso uma formalização completa. Isso contrasta com várias das solu-ções propostas para tratar o problema da consistência quando se utiliza o modelo de casos de uso e o de objetos em separado, que dependem excessivamente da interven-ção do modelador, ou exigem um nível de formalização incompatível com a finalida-de desses modelos na fase de definição de requisitos.

Para avaliar o modelo integrado proposto, realizamos alguns estudos sobre as im-plicações da especialização introduzida nos casos de uso e sobre a usabilidade das re-gras e heurísticas que guiam o processo de derivação do modelo de objetos. Esses es-tudos mostraram alguns resultados animadores, mas pouco conclusivos. Há necessidade de se empreender outros estudos para validar os resultados preliminares obtidos, bem como avaliar comparativamente o modelo proposto, por exemplo, quan-to ao esforço demandado na sua utilização, o nível de treinamento exigido para se ob-ter um resultado efetivo com ele, a uniformidade na elicitação de UC’s, e a qualidade e uniformidade do modelo de objetos produzido. Além disso, pretendemos também especificar um mecanismo de rastreamento entre as duas visões do modelo integrado. 13 CIM: Computation-Independent Model ; PIM: Platform-Independent Model. 14 Em grau dado pelas regras automatizáveis e pelas heurísticas associadas aos padrões sintáti-

cos (seção 3.2).


325

Agradecimentos. Os autores agradecem a Marco Antônio Pereira Araújo, e a Tarcí-sio de Souza Lima e seus alunos, pela contribuição na realização do experimento. Igualmente agradecem aos revisores anônimos, pelos seus comentários.

Referências 1. Biddle, R., Noble, J., Tempero, E.: From Essential Use Cases to Objects. forUse Proceed-

ings, 2002. 2. Bittner, K., Spence, I.: Use Case Modeling. Addison-Wesley, 2002. 3. Cockburn, Alistair. Escrevendo Casos de Uso Eficazes. 1 ed., Bookman Editora, 2005. 4. Fortuna, M.H., Borges, M.R.S.: Modelagem Informacional de Requisitos. Anais do VIII

Workshop em Engenharia de Requisitos (WER 2005). Porto, Portugal, Junho de 2005. 269-280

5. Fortuna, M. H.: Modelagem Informacional de Requisitos. Monografia de qualificação ao doutorado em Engenharia de Sistema e Computação, COPPE/UFRJ, Outubro de 2006.

6. Glinz, M.: A Lightweight Approach to Consistency of Scenarios and Class Models. Pro-ceedings of the 4th Intl. Conf. on Requirements Engineering (ICRE’00), 2000.

7. Glinz, M.: ADORA Project. htp://www.ifi.unizh.ch/groups/req/projects/ADORA/ADORA-project.html. Acesso em dezembro, 2006.

8. Hay, D.C.: Requirements Analysis. Prentice Hall PTR, 2003. 9. Jacobson, I., Christerson, M., Jonsson, P., Övergaard, G.: Object-Oriented Software Engi-

neering - A Use Case Driven Approach. Addison-Wesley, 1992. 10. Jacobson, I., Ericsson, M., Jacobson, A.: The Object Advantage - Business Process Reen-

gineering with Object Technology. 1 ed. England, Addison-Wesley (ACM Press), 1994. 11. Jacobson, I.: “Use cases - Yesterday, today, and tomorrow”, Software and Systems Model-

ing Journal, v.3, pp. 210-220, 2004. 12. Jacobson, I., Ng, P-W.: Aspect-Oriented Software Development with Use Cases. 1 ed.,

Addison Wesley Professional, 2004. 13. Kösters, G., Six, H-W., Winter, W.: Coupling Use Cases and Class Models as a Means for

Validation and Verification of Requirements Specifications. Requirements Engineering Journal, 6, 2001. 3-17.

14. Lauesen, S.: Software Requirements - Styles and Techniques. Addison-Wesley, 2002. 15. Liang, Y.: From use cases to classes: a way of building object model with UML. Informa-

tion and Software Technology (Elsevier), 45, 2003. 83-93. 16. Meyer, B.: Object-Oriented Software Construction. 2 ed. New Jersey, Prentice Hall PTR,

1997. 17. Object Management Group (OMG): UML 2.0 Specification. http://www.uml.org. Acesso

em dezembro, 2006. 18. Robertson, S., Robertson, J.: Mastering the Requirements Process. Addison-Wesley, 1999. 19. Robertson, S., Robertson, J.: Mastering the Requirements Process. 2 ed. New Jersey, Ad-

dison Wesley Professional, 2006. 20. Siau, K., Lihyunn, L.: Are use case and class diagrams complementary in requirements

analysis? An experimental study on use case and class diagrams in UML. Requirements Engineering Journal, 9:4 (November), 2004. 229-237.

21. Subramaniam, K. et al.: UCDA. Use Case Driven Development Assistant Tool for Class Model Generation. SEKE Conference Proceedings, 2004.

22. Wohlin, C. et al.:, Experimentation in Software Engineering - An Introduction, Kluwer Academic Publishers, London, UK, 2000.

23. Object Management Group (OMG): Model Driven Architecture (MDA). http://www.omg.org/mda/. Acesso em fevereiro, 2007.

24. Berrisford, G.: Why IT veterans are sceptical about MDA. 2nd European Workshop on Model Driven Architecture (MDA), Canterbury, UK. Setembro, 2004.


326

Planejamento Integrado das Atividades de Codificação

e Testes em Orientação a Objetos no Nível de

Granularidade dos Métodos

Tatiane Macedo Prudencio Lopes, Clovis Torres Fernandes

Instituto Tecnológico de Aeronáutica - ITA

Pça Eduardo Gomes, 50

12228-901 São José dos Campos , São Paulo, Brasil

[email protected], [email protected]

Resumo. No desenvolvimento de software orientado a objetos usualmente

realizam-se as atividades de codificação e testes separadamente, sem um

planejamento da ordem em que os métodos das classes serão codificados e

testados. A codificação das classes é feita de maneira informal, e mesmo com

testes planejados no nível de granularidade das classes, não se permite que logo

que se codifique um método da classe seja possível testá-lo em seguida.

Considerando tal contexto, neste trabalho propõe-se um planejamento integrado

das atividades de codificação e testes, com uma ordenação no nível de

granularidade dos métodos das classes, de maneira que um método possa ser

testado logo após a sua implementação. Assim, tal planejamento integrado

permitirá a realização dessas atividades de forma paralela bem como um melhor

reaproveitamento de esforços na construção de stubs e realização de retestes.

Palavras-chave: Orientação a Objetos, Teste de Software, Codificação,

Planejamento, Integração.

1 Introdução

Atividades de codificação e testes correspondem a fases essenciais do processo de

desenvolvimento de software e embora constituam fases distintas, estão intimamente

relacionadas [1]. Em geral, realizam-se codificação e testes de maneira informal em

que tanto programadores quanto testadores não possuem um planejamento quanto à

ordem em que os métodos das classes de um software em desenvolvimento serão

codificados e testados. Na maioria das vezes, programadores da equipe de

desenvolvimento escolhem partes da especificação a serem implementadas que

supõem mais apropriadas num dado momento. Somente após a completa codificação

do software especificado é que testadores iniciam o trabalho de descobrir evidências

de defeitos introduzidos durante qualquer fase do processo de desenvolvimento

submetendo-o a diversas baterias de testes. Alguns testadores realizam testes de

unidade em métodos da classe assim que estes estejam implementados, embora esses

testes não sejam planejados quanto à ordem de realização. Isso, conseqüentemente,

limita os testes somente a métodos que não necessitam da colaboração de outros


327

métodos servidores ou a métodos que utilizem serviços de métodos já implementados

embora ainda não testados. Em ambas as maneiras de realização de testes

mencionadas, os testes não são planejados quanto à ordem de realização no nível de

granularidade dos métodos das classes e nem são subseqüentes à atividade de

codificação, que também não é planejada.

Na Análise e Projeto Estruturados (APE), Weinberg [2] propôs uma estrutura de

um plano de codificação e testes em que se planeja a ordem que os módulos serão

codificados e testados, de maneira que o módulo recém construído seja testado logo

em seguida. Assim, a ordem de codificação dos módulos corresponde exatamente à

ordem de testes. Caso, no momento dos testes, o módulo recém construído necessite

da colaboração de outros módulos ainda não reais, os módulos colaboradores são

implementados como módulos fictícios, denominados stubs, somente para simular o

comportamento requerido pelo módulo recém construído. Na Orientação a Objetos

(OO), anteriormente aos trabalhos de Kung et al. [3, 4, 5] e Tai & Daniels [6], tanto a

atividade de codificação quanto de testes não eram planejadas quanto à ordem de

realização. Classes eram selecionadas para a implementação de maneira informal, de

acordo com a necessidade dos implementadores em um dado momento do projeto.

Testes também eram realizados de maneira informal: classes que necessitavam da

colaboração de outras classes eram testadas mesmo que as classes servidoras ainda

não tivessem sido testadas, construção de stubs que poderiam ser economizados,

realização de retestes em classes não afetadas pelas modificações. Posteriormente a

esses trabalhos, mesmo com a atividade de codificação não planejada e separada da

atividade de testes, os testes podiam ser realizados de acordo com uma dada ordem

das classes o que reduzia a quantidade de stubs e retestes realizados. Embora os

trabalhos de Kung et al. [3, 4, 5] e Tai & Daniels [6] se preocupassem com uma

ordem de testes das classes, eles não previam a ordem que baterias de testes seriam

aplicadas especificamente nos métodos da classe, ou seja, qual seria a ordem de testes

dos métodos da classe.

A proposta deste artigo é uma integração das fases de codificação e testes na OO

assim como Weinberg [2] apresenta para a APE, porém num nível de granularidade

menor correspondente ao nível dos métodos das classes. Dessa forma, a atividade de

codificação pode ser planejada de maneira que se defina uma ordem de

implementação das classes e de seus respectivos métodos, mas essa mesma ordem de

codificação pode corresponder exatamente à ordem de testes de maneira que logo que

um método de uma classe seja codificado planeje-se testá-lo em seguida. Assim,

atividades de codificação e testes podem ser integradas com a conseqüente redução de

esforços na construção de stubs e realização de retestes, bem como uma redução no

tempo de execução dessas atividades.

Este artigo está organizado da seguinte maneira. Na Seção 2 apresentam-se alguns

problemas decorrentes em realizar a codificação de classes da OO separadamente da

atividade de testes. Na Seção 3 apresenta-se uma proposta de integração de

codificação e testes no nível de granularidade dos métodos das classes. Na Seção 4

apresentam-se alguns trabalhos relacionados com o planejamento das atividades de

testes, bem como as contribuições propostas no artigo. Finalmente, na Seção 5

apresentam-se as conclusões e alguns trabalhos futuros.


328

2 Alguns Problemas Decorrentes das Atividades de Codificação e

Testes na OO

Na OO, na maioria das vezes, a escolha das classes a serem codificadas é feita de

maneira informal, sem nenhum planejamento, de acordo com a necessidade do

implementador em um dado instante do projeto. Todas as classes especificadas são

implementadas como um todo, embora algumas vezes, sem nenhum planejamento

definido, realizam-se testes de unidade em determinadas classes logo que são

codificadas. Um plano de testes que defina exatamente a ordem em que as classes

serão testadas, bem como os stubs a serem criados e retestes a serem realizados, pode

ser seguido como forma de planejamento da atividade de testes. No entanto,

codificação e testes são realizados separadamente, não ocorrendo uma integração

dessas atividades de modo que logo que uma classe tenha sido codificada, possa ser

testada em seguida. Além disso, não se pode saber exatamente qual método da classe

será codificado e testado.

Suponha, por exemplo, o diagrama de classes UML da Figura 1, que representa as

relações interclasses de associação, agregação e herança entre as classes C1, C2, C3, C4

e C5. Na fase de codificação dessas classes, realizada de maneira informal, o

implementador selecionaria uma dada classe para codificá-la, por exemplo, a classe

C4. À medida que a codificação sucede, o implementador percebe que algumas

classes como, por exemplo, C5 e C2, são necessárias serem implementadas antes de

C4, pois as relações de herança e associação entre C4 e C5 e, C4 e C2, respectivamente,

indicam uma dependência entre essas classes. Então, inicia-se a codificação de novas

classes, enquanto a codificação de C4 não pode prosseguir. Quando o implementador

supõe que a codificação da classe C4 pode ser reiniciada, então retorna à classe C4 até

que a finalize ou até que uma nova dependência ocorra. E assim, o implementador

segue com um planejamento informal para a codificação das classes até o fim de toda

a implementação.

Fig. 1. Exemplo de diagrama de classes UML das classes C1, C2, C3, C4 e C5.


329

Algumas vezes, testes de unidade são aplicados a algumas classes, mas

novamente, as relações de dependência limitam esses testes, como, por exemplo,

alguns métodos da classe C4 podem invocar métodos de classes como C5 ou C2 e, se

os testes de C5 e C2 ainda não foram realizados, testes de unidade de C4 podem não

ser bem sucedidos por causa dessas dependências. Pode-se perceber então que um

planejamento da codificação teria uma significante contribuição para o programador.

Um planejamento dos testes no nível de granularidade das classes, em que se

define a ordem de efetivação dos testes das classes, após as classes já terem sido

codificadas, pode ser realizado de acordo com os trabalhos de Kung et al. [3, 4, 5] e

Tai & Daniels [6]. Com base nas informações de projetos de classes como diagramas

de classes e relacionamentos de colaboração entre classes na OO, podem-se obter as

relações de dependência entre classes. Essas relações serão os dados de entrada para

os algoritmos de Tai & Daniels [6] que definirão a ordem de testes das classes

codificadas previamente sem o uso de um planejamento. Também serão os dados de

entrada para os algoritmos de Kung et al. [3, 4, 5] que definirão os retestes a serem

realizados de acordo com a quantidade de stubs criados.

Para as classes representadas na Figura 1, após todas as classes terem sido

codificadas sem qualquer planejamento, uma ordem de testes pode ser obtida de

acordo com as relações de dependência entre as classes. Essa ordem de realização dos

testes constitui um plano de testes no nível de granularidade das classes e baterias de

testes são aplicadas a todos os métodos da classe. Quando uma classe totalmente já

implementada, mas ainda não testada, colabora com outra classe e essa outra classe

esteja em fase de testes, não convém que a classe cliente utilize os serviços da classe

servidora ainda não testada; por causa disso há a necessidade da construção de um

stub da classe colaboradora, muito embora esta já esteja implementada, de maneira a

garantir o comportamento requerido pela classe cliente no momento de seus testes.

Assim, em classes independentes, que não necessitam da colaboração de outras

classes, como, por exemplo, a classe C1, pode-se iniciar os testes imediatamente. A

classe C2 seria a próxima classe a ser testada, pois necessita da colaboração de uma

outra classe, a classe C1, mas que já se encontra testada. Percebe-se que as classes C5

e C3 são mutuamente alcançáveis, ou seja, existe uma dependência cíclica entre as

duas classes pela relação de associação bidirecional, e deve-se escolher uma das duas

para ser implementada como stub durante os testes da outra, uma vez que as

implementações das classes C5 e C3 não foram testadas e, portanto, não garantem o

seu comportamento. Por exemplo, constrói-se um stub de C3 que simule o

comportamento requerido por C5 enquanto testa-se C5. Em seguida, substitui-se o stub

de C3 pela classe real, já codificada, e testa-se C3. Necessariamente, a classe C5 deverá

ser retestada devido à modificação realizada em C3, quando ela passa de classe stub

para classe real. Percebe-se que o esforço gasto na construção do stub de C3 é

descartado após os testes, uma vez que a classe C3 já se encontrava previamente

codificada.

No plano de testes apresentado para o diagrama de classes da Figura 1, os

seguintes problemas podem ser observados:

• Embora se tenha uma ordem de testes das classes, não se sabe exatamente

qual a ordem de testes dos métodos, por exemplo, qual método da classe será

primeiramente testado. Assim, no momento de realização dos testes da classe


330

C1, por quais métodos devem-se iniciar os testes? Baterias de testes podem

ser aplicadas a métodos que dependam de outros métodos, tanto dentro da

própria classe, conhecido como intraclasse, quanto em outras classes,

denominado interclasse, que ainda não foram testados.

• Stubs para simular o comportamento de uma dada classe são construídos

mesmo que a classe já tenha sido implementada, pois classes codificadas e

não testadas não garantem o seu comportamento durante os testes de suas

classes clientes, e então se constrói o stub com esse objetivo. Mas o esforço

gasto na construção de stubs é descartado uma vez que as classes estão

previamente codificadas e stubs utilizados na fase de testes não são

reaproveitados na fase de implementação que já fora realizada.

• A codificação das classes não é seguida dos testes e alguns defeitos inseridos

durante a implementação são possivelmente descobertos somente na fase de

testes, quando todas as classes já tiverem sido implementadas e os defeitos

possivelmente propagados.

• A codificação e testes não são integrados de maneira que classes possam ser

codificadas e testadas paralelamente a outras classes, reduzindo o tempo de

realização dessas atividades.

• Quando retestes são necessários, por exemplo, reteste da classe C5 devido a

modificações de classe stub para real, todas as baterias de testes para todos

os métodos da classe são novamente realizados mesmo que alguns métodos

não tenham sido afetados pela modificação.

Como proposta de solução para os problemas citados, pode-se planejar a integração

das atividades de codificação e testes, de forma análoga ao proposto por Weinberg [2]

para a APE, de maneira que a ordem de codificação corresponda exatamente à ordem

de testes das classes na OO no nível de granularidade dos métodos.

3 Integração de Codificação e Testes em OO no Nível de

Granularidade dos Métodos

Weinberg [2] propôs uma estrutura de um plano de codificação e testes para a APE

em que se planeja a ordem que os módulos serão codificados e testados, de maneira

que, logo que um módulo tenha sido implementado, seja testado em seguida. Assim, a

ordem que os módulos são codificados corresponde exatamente à ordem que os

módulos serão testados. Quando um módulo necessita da colaboração de outro

módulo que não esteja implementado e testado, um módulo stub simula o

comportamento requisitado pelo módulo em teste. Esse mesmo módulo stub será

então reaproveitado para a criação do módulo real correspondente, no momento que

este for implementado conforme planejado.

Na Figura 2 ilustra-se um diagrama de estrutura de módulos, considerando a

técnica top-down, com varredura dos módulos em largura, em que módulos de alto

nível são implementados e testados antes de módulos de baixo nível. De acordo com a

proposta de Weinberg [2], o módulo 1 é o primeiro módulo a ser implementado; mas

esse mesmo módulo necessita da colaboração dos módulos 2, 3 e 4, que ainda não


331

estão prontos. Uma maneira de simular o comportamento requerido pelo módulo 1 é a

construção de stub para cada um dos módulos 2, 3 e 4. Assim, o módulo 1 pode ser

testado. O passo seguinte é a implementação real do módulo 2, a partir do

correspondente stub anteriormente construído. O módulo 2 necessita da colaboração

dos módulos 5, 6 e 7 que não estão prontos. Então, stubs são construídos para esses

módulos para a realização dos testes no módulo 2. Testar o módulo 2 significa retestar

todos os módulos já testados, mas agora com a integração do novo módulo real 2. Em

seguida, o stub do módulo 3 é reaproveitado para a implementação de seu módulo

real; stubs para os módulos 8 e 9 também são implementados; então, testes são

executados agora com o módulo 3 já real. E assim, todos os módulos são codificados

e em seguida testados até que o módulo 13, o último módulo, é finalmente

implementado como um módulo real e então testado.

Fig. 2. Chamada de módulos de um programa com a técnica top-down [2].

Na Figura 3 apresenta-se o Plano de Teste Modular (PTM) proposto por

Weinberg [2] aplicado ao diagrama de estrutura de módulos da Figura 2. São

realizadas 13 fases de testes, sendo que a cada fase de teste representada no PTM

indica-se o status de todos os módulos de programa requisitados para cada fase de

testes, quais módulos são requisitados como stubs (S), quais são reais (R) e quais não

são necessários para qualquer estágio no teste. Módulos implementados em uma dada

fase, seja como real ou stub, estão representados em negrito. Como exemplo, na fase

de testes 6, os módulos de 1 a 5 são módulos reais já codificados e testados, o módulo

6 é implementado como real, representado por R, a partir de seu stub construído na

fase de testes 2, os módulos de 7 a 11 são módulos stubs construídos nas fases de

testes anteriores, o módulo 12 é implementado como stub, representado por S, e o

módulo 13 ainda não fora requisitado. Testes realizados na fase 6 testam o módulo 6

recém implementado como real e retestam todos os módulos já testados nas fases

anteriores, incluindo módulos que dependam do módulo recém modificado e que

poderiam ser afetados pelas novas modificações.

Na OO, pode-se planejar a integração das atividades de codificação e testes de

maneira análoga ao que Weinberg [2] propõe, como apresentado por Lopes &

Fernandes [8]. Em [8] apresenta-se um Plano de Codificação e Testes (PCT) no nível


332

de granularidade das classes de maneira que logo que uma classe seja codificada

também seja possível testá-la em seguida.

Fig. 3. Plano de Teste Modular (PTM) para o conjunto de módulos da Figura 2 [2].

Porém, considerando um nível de granularidade menor, um Plano de Codificação

e Testes (PCT) no nível dos métodos das classes descreveria a ordem em que as

classes e seus métodos serão codificados e em seguida testados, com os respectivos

stubs a serem criados bem como retestes a serem realizados. Na Figura 5,

exemplificada mais adiante, representa-se um exemplo de PCT no nível de

granularidade dos métodos das classes, de acordo com as relações intraclasse e

interclasse ilustradas na Figura 4.

Relações entre as classes na OO são muito mais complexas que simples chamadas

de módulos como na APE, pois existem relações de associação, agregação e herança

que tornam as dependências entre classes mais fortes [1, 9]. Uma característica de

grande interesse da OO é o polimorfismo. Embora não faça parte do escopo deste

trabalho, modificações provindas das implementações polimórficas tais como adição

de novas dependências ou remoção de dependências previamente existentes podem

ser realizadas e cobertas pelo PCT baseado no desenvolvimento iterativo, como

apresentado no trabalho de Lopes [7].

Suponha, por exemplo, o diagrama de classes da Figura 1 que representa as

relações de associação, agregação e herança entre as classes C1, C2, C3, C4 e C5 e o

diagrama da Figura 4 que ilustra as dependências intraclasse e interclasse entre os

métodos das classes. A classe C1 é uma classe independente que não necessita da

colaboração de nenhuma outra classe, embora seja uma classe colaboradora para C2;

C1 é composta dos métodos m1 e m2, em que m1 depende de m2 no nível intraclasse. A

classe C2 tem uma relação de agregação com a classe C1, ou seja, C2 contém objetos

da classe C1, e é uma classe colaboradora para C4; C2 é composta pelos métodos m1,

m2, m3 e m4, em que m1 depende de m2 e m3, m2 depende de m4 e m4 depende de m3,

todos no nível intraclasse, e de [C1, m1] no nível interclasse. A classe C3 é tanto

cliente quanto colaboradora da classe C5, por uma relação de associação bidirecional;

C3 é composta dos métodos m1 e m2, em que m1 depende de m2 no nível intraclasse e

de [C5, m3] no nível interclasse. A classe C5, por sua vez, é colaboradora e cliente da

classe C3; C5 é composta dos métodos m1, m2 e m3, em que m1 depende de m2 e m3 no


333

nível intraclasse, e de [C3, m1] no nível interclasse. Finalmente, a classe C4 tem uma

relação de herança com a classe C5 e, portanto, C4 pode herdar alguns métodos de C5;

tem ainda uma relação de associação com C2; C4 é composta do método m1, que

depende de [C2, m1], [C2, m2] e [C5, m2] no nível interclasse. Durante os testes, deve-

se garantir que, por exemplo, métodos herdados de C5 por C4 se comportem

adequadamente; em conseqüência disso, deveriam ser testados antes da classe C4.

Dessa forma, as relações na OO fazem com que codificação e testes economizem

esforços quando escolher primeiramente as classes e métodos independentes, como,

por exemplo, [C1, m2], e só então se segue com os testes dos métodos das classes

dependentes, como por exemplo, C2.

Fig. 4. (a) Diagrama de dependência intraclasse e interclasse para as classes da Figura 1 [10];

(b) Grafo de dependência dos métodos nos níveis interclasse e intraclasse.

Stubs serão construídos somente quando um conjunto de classes se relacionar de

maneira cíclica, ou seja, quando classes forem mutuamente dependentes. No diagrama

de classes da Figura 1, há ocorrência de ciclos entre as classes C3 e C5, pois tanto C5

tem uma relação de associação com C3 quanto C3 com C5. No diagrama de

dependência da Figura 4 percebe-se, num nível de granularidade menor, que [C3, m1]

depende de [C5, m3], e formando um ciclo de dependência interclasse entre C3 e C5,

[C5, m1] depende de [C3, m1]. É nesse caso que um stub deve ser construído para uma

das duas classes com o objetivo de simular o comportamento, até que uma das classes

seja codificada e testada. Supondo, por exemplo, que seja criado um stub da classe C3

para os testes da classe C5, então o stub corresponderia à codificação geral da classe

C3, somente com sua assinatura, e com o mínimo de código necessário para simular o


334

comportamento requerido de [C5, m1] em relação à [C3, m1]. Como no PCT as classes

serão codificadas e logo em seguida testadas, então stubs construídos para os testes

serão reaproveitados no momento em que a classe for implementada como uma classe

real.

O reaproveitamento dos stubs criados para a codificação real das classes e métodos

correspondentes não influencia na fase de manutenção do software quando, por

exemplo, uma modificação é realizada em um dado método da classe. Ou seja,

quando um método é modificado, outros métodos que dependem, direta ou

indiretamente, do método modificado são retestados considerando que o método

modificado já fora alterado e conseqüentemente retestado, com a aplicação de baterias

de testes antigas, utilizadas anteriormente, bem como baterias de testes novas que

cubram as novas modificações.

Retestes ocorrerão somente quando uma classe já construída como stub for

implementada para uma classe real. Nesse caso retestes serão realizados somente nas

classes, mais especificamente nos métodos, possivelmente afetados pela modificação.

Suponha por exemplo que a classe C3, representada no diagrama de dependência da

Figura 4, que antes fora codificada como um stub, seja agora codificada como uma

classe real. Então, quando [C3, m1] é codificado e testado como um método real,

retestes são necessários nos métodos das classes já codificados e testados e que o

utilizaram como stub, ou seja, [C5, m1]. Os demais métodos de C5, m2 e m3, não

necessitam de retestes uma vez que não possuem relações interclasse com [C3, m1].

Na Figura 5 ilustra-se o exemplo de um PCT para as classes representadas na

Figura 1, no nível de granularidade dos métodos representados nas Figuras 4(a) e

4(b). No PCT, a ordem de codificação corresponde exatamente à ordem de testes,

stubs são construídos somente na ocorrência de dependência mútua entre as classes e

retestes seletivos realizados quando classes stubs são modificadas para classes reais.

No nível de granularidade dos métodos da classe, representado na Figura 5, em um

primeiro momento, codifica-se e testa-se os métodos da classe C1, uma classe

independente. O método m2 é o primeiro método a ser codificado e logo em seguida

pode-se testá-lo. O método m1, dependente do método m2 anteriormente codificado e

testado, pode agora ser codificado e então testado. Em seguida os métodos da classe

C2 são codificados, pois C2 depende da classe C1 já pronta. O método m3, um método

independente de relações intraclasse e interclasse, é o primeiro a ser codificado e logo

em seguida testado. No passo seguinte, m4 que depende dos métodos [C1, m1] e [C2,

m3] já prontos, pode então ser codificado e em seguida submetido a uma bateria de

testes. O terceiro método a ser codificado e testado é m2, e por último o método m1. O

próximo passo é a codificação dos métodos da classe C5, mas, antes da realização dos

testes, necessita-se da construção de um stub para C3, e só então é que os testes em C5

são realizados. O primeiro método da classe C5 a ser codificado e em seguida testado

pode ser tanto m2 quanto m3, pois ambos são independentes.

No PCT da Figura 5 escolhe-se m2. Em seguida, codifica-se e testa-se o método

m3. O método m1 é o próximo método a ser codificado, mas para a realização dos

testes sabe-se que, devido a uma dependência interclasse, deve-se construir um stub

do método m1 da classe C3, ou seja [SC3, m1], para que [C5, m1] possa ser testado

adequadamente. Em seguida, a classe C3 é codificada como uma classe real, ou seja, o

stub construído no passo anterior é reaproveitado nesse momento e os métodos reais

de C3 são então codificados. Codifica-se então o método m2, que é independente de


335

outros métodos, e então se aplica uma seqüência de testes, ou bateria de testes, ao

método m2. Em seguida, codifica-se o método m1, com possíveis reaproveitamentos

do stub [SC3, m1] que já fora codificado; e em seguida aplicam-se os testes em m1.

Como [C5, m1] fora testado com o uso de um stub de [C3, m1], nesse momento que

[C3, m1] está codificado e testado como um método real, retestes são necessários em

[C5, m1] devido ao relacionamento interclasse. Os demais métodos da classe C5 não

necessitam ser retestados uma vez que não foram afetados pela modificação de [C3,

m1] de stub para real. Finalmente, codifica-se o método m1 da classe C4 e realizam-se

os testes logo em seguida.

Fig. 5. Um PCT para as classes da Figura 1 no nível de granularidade dos métodos das classes.

No PCT ilustrado na Figura 5 apresenta-se uma possibilidade de ordem de

codificação e testes dos métodos das classes de maneira seqüencial, ou seja, no

momento de codificação ou testes de um dado método nenhum outro método pode

estar sendo codificado ou testado paralelamente. No entanto, esse mesmo PCT pode

organizar as classes e seus métodos de tal maneira que, enquanto determinadas classes

são codificadas, outras classes podem também estar sendo codificadas ou testadas. Na

Figura 6 ilustra-se o exemplo de codificação e testes, realizados conforme o PCT da

Figura 5, mas com a possibilidade de métodos das classes serem codificados e

testados paralelamente.

Supõe-se que a codificação para todos os métodos na Figura 6 gaste o mesmo

tempo t, que é igual também para o teste de todos os métodos. Assim como os tempos

de codificação diferem entre si e os tempos de testes diferem entre si também, os

tempos de codificação diferem dos tempos de testes, mas neste trabalho considera-se

uma simplificação de maneira que os tempos de codificação e testes são os mesmos

para todo método m.

No tempo 1, os métodos [C1, m2], [C5, m2] e [C5, m3] podem ser codificados

paralelamente. No tempo 2, os métodos codificados no tempo anterior já podem ser

testados e os métodos [C1, m1], [SC3, m1], [C2, m3] e [C5, m1] são codificados. No

tempo 3, os métodos codificados no tempo 2 são testados, exceto o stub [SC3, m1], e

os métodos [C2, m4] e [C3, m2] são codificados. No tempo 4 os métodos [C2, m2] e

[C3, m1] são codificados paralelamente aos testes dos métodos [C2, m4] e [C3, m2]. No

tempo 5 é codificado o método [C2, m1] e testados os métodos [C2, m2] e [C3, m1]. No

tempo 6 o método [C4, m1] é codificado e os métodos [C2, m1] e [C5, m1] são testados.


336

Finalmente, no tempo 7 testa-se o método [C4, m1]. Dessa forma, PCT no nível de

métodos com paralelismo, tem-se 7 tempos para a realização das atividades de

codificação, testes e retestes enquanto que o PCT no nível dos métodos sem

paralelismo, conforme Figura 5, tem-se 13 tempos para a realização das mesmas

atividades.

Fig. 6. Paralelismo entre Codificação e Testes para o PCT da Figura 5.

É importante salientar que na codificação e testes em paralelo, a quantidade de

recursos humanos disponíveis deve ser considerada. Por exemplo, no tempo 2 exige-

se a disponibilidade de no mínimo quatro implementadores para os métodos [C1, m1],

[SC3, m1], [C2, m3] e [C5, m1], e três testadores para os métodos [C1, m2], [C5, m2] e

[C5, m3] para que ocorra codificação e testes paralelamente.

No trabalho de Lopes [7] apresenta-se uma validação da proposta de integração de

codificação e testes apresentada neste artigo. Alguns estudos de caso são utilizados

para comprovar as contribuições para o planejamento integrado de codificação e

testes na OO no nível de granularidade dos métodos das classes.

Ainda em Lopes [7] tem-se a apresentação da ferramenta denominada Ford

(Ferramenta de Ordenação) para a automatização da proposta de integração

apresentada neste artigo. Porém, a ferramenta encontra-se em fase de aplicação e

testes.


337

4 Trabalhos Relacionados

Tai & Daniels [6] apresentam um algoritmo que define uma ordem de testes para

classes na OO já codificadas. O objetivo da ordenação é reduzir os esforços na

construção de stubs durante a realização dos testes. Embora as classes sejam todas

previamente implementadas, durante os testes há a necessidade de se criar stubs para

garantir o comportamento requerido por determinadas classes cliente e que não é

garantido por classes codificadas e não testadas. Assim, esses stubs são descartados

posteriormente pelo fato de que a classe real correspondente já fora previamente

implementada. Retestes são previstos somente nas classes diretamente relacionadas

com os stubs criados, quando estes são substituídos pela classe real já codificada e

então testada.

A proposta apresentada neste artigo possui algumas melhorias em relação ao

trabalho de Tai & Daniels [6], quando propõe a integração das atividades de

codificação e testes, de maneira que a ordem em que os métodos das classes serão

testados corresponda exatamente à ordem em que serão codificados. Enquanto Tai &

Daniels [6] descartam os stubs construídos na fase de testes, o trabalho proposto faz

um reaproveitamento de todos eles no momento da implementação da classe real

correspondente ao stub criado. Em relação aos retestes, Tai & Daniels [6] os realizam

somente nas classes diretamente relacionadas com o stub construído. O trabalho

proposto prevê a realização de retestes tanto em classes diretamente relacionadas com

a classe modificada quanto em classes indiretamente relacionadas com a modificação,

conhecido como retestes seletivos conforme apresentado por Binder [11] e Jéron et al.

[12]. Finalmente, como conseqüência da fase de codificação não planejada e

totalmente separada da fase de testes, o trabalho de Tai & Daniels [6] não permite que

logo que se codifique uma classe possa testá-la em seguida, assim como proposto

neste artigo.

Kung et al. [4] apresentam um algoritmo para a identificação das classes

possivelmente afetadas por modificações realizadas, permitindo retestes seletivos.

Assim como no trabalho de Tai & Daniels [6], em Kung et al. [3, 4, 5] stubs são

construídos, mesmo com a classe correspondente já codificada, para que esse stub

garanta um comportamento adequado solicitado pela classe cliente que não é

garantido por uma classe implementada e não testada. Quando o stub é substituído

pela classe real, retestes são realizados de maneira que todas as classes possivelmente

afetadas, direta ou indiretamente, sejam retestadas. Teoricamente, um dos objetivos

do trabalho de Kung et al. [3, 4, 5] consiste na redução da quantidade de stubs criados

e o método de ordenação proposto atinge tal objetivo. No entanto, Tai & Daniels [6]

conseguem mostrar que a técnica utilizada em seus trabalhos reduz ainda mais que a

proposta de Kung et al. [3, 4, 5] e por esse motivo, escolheu-se o método de

ordenação de Tai & Daniels [6] para a ordenação de classes no planejamento

proposto.

Enquanto Kung et. al [4] fazem uma reengenharia reversa para extrair da

implementação das classes suas relações de dependência, o trabalho proposto neste

artigo obtém essas informações a partir de diagramas de classes e colaborações entre

classes em nível de projeto. O reaproveitamento de stubs também não é possível no

trabalho de Kung et al. [3, 4, 5], uma vez que codificação e testes são atividades

realizadas separadamente. E, assim como o trabalho de Tai & Daniels [6], Kung et al.


338

[3, 4, 5] também não planejam a fase de codificação, realizada separadamente da fase

de testes, não permitindo a integração entre codificação e testes.

Lima & Travassos [13], diferentemente de Kung et al. [3, 4, 5] e Tai & Daniels

[6], consideram as classes no nível de abstração de projeto, ou seja, as relações de

dependência entre as classes são extraídas de diagramas UML. A partir dessas

informações, propõem um conjunto de heurísticas que permitem estabelecer uma

ordem de prioridade para o teste de integração das classes que compõem o software

de maneira que o número de stubs necessários para a realização das atividades de

testes seja reduzido. Enquanto neste trabalho proposto os stubs são reaproveitados no

momento de implementação das classes e métodos reais correspondentes, Lima &

Travassos [13] não mencionam a possibilidade de reaproveitamento desses stubs.

Além disso, uma ordem de teste de integração no nível de granularidade dos métodos

das classes, como proposto neste trabalho, poderia reduzir a complexidade dos stubs

criados uma vez que se sabe exatamente quais métodos da classe devem ser simulados

como stubs para o teste de uma dada classe.

5 Conclusões e Trabalho Futuros

Na maioria das vezes, atividades de codificação e testes na OO não são

planejadas. Alguns trabalhos propõem o planejamento das atividades de testes no

nível de granularidade das classes, definindo uma ordem em que as classes serão

testadas, de maneira que as quantidades de stubs criados e retestes realizados sejam

reduzidas. Mesmo com o planejamento dos testes no nível de granularidade das

classes, não se sabe exatamente qual a ordem de testes dos métodos das classes e

ainda, codificação e testes são realizados separadamente, não permitindo que se

codifique um dado método da classe e que logo em seguida seja possível testá-lo.

Neste artigo propõe-se uma integração das atividades de codificação e testes de

maneira que a ordem definida para a codificação dos métodos das classes corresponda

exatamente à mesma ordem definida para os testes. Assim, quando um método da

classe é codificado, o teste desse mesmo método pode ser realizado logo em seguida.

A ordem em que os métodos das classes são codificados e testados é obtida a

partir da análise das relações de dependência entre os métodos das classes, e essa

mesma ordem tenta reduzir ao máximo a quantidade de stubs criados bem como os

retestes realizados. Uma maior integração entre codificação e testes ocorre quando

vários métodos podem ser codificados e testados paralelamente, o que reduz o tempo

de realização dessas atividades.

Alguns trabalhos futuros são apresentados a seguir:

• Melhoria nos algoritmos apresentados por Kung et al. [4] e Tai & Daniels [6]

visando uma maior redução na quantidade de stubs criados e retestes

realizados.

• Adaptação do planejamento integrado de codificação e testes ao

desenvolvimento iterativo e incremental em que o software é desenvolvido

em partes, e a cada iteração novos métodos e classes podem ser adicionados;


339

bem como partes já codificadas e testadas na iteração anterior podem ser

modificadas.

• Algoritmo para paralelizar PCT no nível de granularidade dos métodos de

acordo com a quantidade de recursos humanos disponíveis.

Referências

1. McGregor. J. D., Sykes, D. A.: A Practical Guide To Testing Object-Oriented Software. 1st

edn. Addison-Wesley, Boston MA (2001).

2. Weinberg, V.: Structured Analysis. Prentice Hall, Upper Saddle River NJ (1978).

3. Kung, D., Gao, J., Hsia, P.: 1994. Developing an Object Oriented Testing and Maintenance

Environment. Communications of The ACM, Vol. 38. ACM-Press, New York NY USA

(1995) 75-87.

4. Kung, D., Gao, J., Hsia, P., Lin, J., Toyoshima, Y.: Class Firewall, Test Order, and

Regression Testing of Object-oriented Programs. Journal of Object-Oriented

Programming, Vol. 8. (1995) 51-65.

5. Kung, D., Gao, J., Hsia, P., Toyoshima, Y., CHEN, C., KIM, Y. S., SONG, Y. K.:

Developing an Object-Oriented Software Testing and Maintenance Environment.

Communications of the ACM, Vol.. 38. ACM-Press, New York NY USA (1995) 75-87.

6. Tai, K. C., Daniels, F. J.: Test Order for inter-Class Integration Testing of Object-Oriented

Software. COMPSAC’97 – 21st International Computer Software and Applications

Conference, Washington DC (1997) 602-607.

7. Lopes, T. M. P.: Uma Estrutura Para o Plano de Codificação e Testes no Desenvolvimento

Evolutivo de Software Orientado a Objetos. 174 f. Dissertação (Mestrado em Engenharia

Eletrônica e da Computação) – ITA – Instituto Tecnológico de Aeronáutica, São José dos

Campos SP Brasil (2004).

8. Lopes, T. M. P.: Planejamento Integrado das Atividades de Codificação e Testes na

Orientação a Objetos. In: I Simpósio Brasileiro de Testes de Software – I SBTS.

Pernambuco Recife Brasil (2006).

9. Hanh, V. L., Akif, K., Le Traon, Y., Jézéquel, J. M.: Selecting an Efficient OO Integration

Testing Strategy: An Experimental Comparison of Actual Strategies. ECOOP – 2001

Object Oriented Programming, Budapeste Hungria (2001) 381-401.

10. Harrold, M. J., McGregor, J. D., Fitzpatrick, K.: Incremental Testing of Object-Oriented

Class Structures. In: Proc. 14th IEEE International Conference on Software Engineering.

Melbourne Austrália (1992) 68-80.

11. Binder, R. V.: Testing Object-Oriented Systems: Models, Patterns and Tools. Addison-

Wesley, Boston MA (1999).

12. Jéron, T., Jézéquel, J. M., Traon, Y. L., Morel, P.: Efficient Strategies for Integration and

Regression Testing of OO Systems. In: Proceedings of the 10th International Symposium

on Software Reliability Engineering. IEEE Computer Society, Washington DC USA (1999)

260.

13. Lima, G.M.P.S., Travassos, G.H.: Testes de Integração Aplicados a Software Orientado a

Objetos: Heurísticas para Ordenação de Classes. In: III Simpósio Brasileiro de Qualidade

de Software (SBQS-2004), Brasília DF (2004).


340

Desenvolvimento de

Interface com Usuário Dirigida por Modelos com

Geração Automática de Código

Lucas Issa1, Clarindo Pádua1, Rodolfo Resende1, Stenio Viveiros1, Pedro Neto2

1 Universidade Federal de Minas Gerais, Departamento de Ciência da Computação,

Av. Antônio Carlos 6627 - Prédio do ICEx - sala 4010 - Pampulha 31270-010 Belo Horizonte, MG – Brasil

{issa, clarindo, rodolfo, stenio}@dcc.ufmg.br 2 Universidade Federal do Piauí, Departamento de Informatica e Estatistica.

Campus Universitario da Ininga, S/N - CCN-DIE - Ininga 64045-500 Teresina, PI - Brasil

[email protected]

Resumo. Este trabalho aplica técnicas de MDA (Model Driven Architecture) para gerar código a partir de modelos UML. Foi proposto um método, MDGI (Método de Desenvolvimento e Geração de Interfaces), que permite gerar modelos e código de padrões (patterns) recorrentes em sistemas. Esses padrões são gerados a partir de um modelo de domínio da aplicação. Neste trabalho também foi formalizado, mas não descrito neste documento, um modelo independente de tecnologia para a interface com o usuário. Para validar informalmente o método desenvolvido, foi implementado um caso de uso seguindo o método proposto comparando-se os resultados obtidos com o desenvolvimento feito sem o auxílio do método. Os resultados indicam um possível aumento de produtividade, além de permitir um maior nível de reutilização em função das técnicas de modelagem e codificação implementadas nas transformações.

Palavras-chave: Model Driven Architecture (MDA), Model Driven Development (MDD), geração de código, geração de modelo, transformações, modelo de interface com o usuário, reutilização, produtividade.

1 Introdução

A UML (Unified Modeling Language) [17] [24] tem sido muito utilizada no desenvolvimento de sistemas [8]. Embora seu uso traga muitos benefícios, ainda existem possibilidades de torná-la mais efetiva. Neste trabalho é apresentada uma alternativa nessa direção, utilizando modelos para geração de código. Embora a UML ajude o desenvolvimento de um produto de software, o código

fonte é o principal artefato do desenvolvimento. É comum que modelos se tornem desatualizados à medida que o sistema evolui, principalmente os modelos de alto nível. Complicando ainda mais esse cenário, com o passar do tempo são criadas novas


341

tecnologias, e a migração de sistemas existentes para as novas tecnologias é bastante oneroso. É nesse contexto que a metodologia conhecida como Model Driven

Architecture (MDA) [23] pode contribuir para solucionar alguns problemas. No MDA, o foco é centrado no modelo e não no código-fonte. O modelo passa a

gerar resultados concretos, ou seja, parte da aplicação é gerada automaticamente a partir dele. Assim, é possível focar o desenvolvimento, de forma efetiva, no modelo. No MDA, alterações podem ser feitas diretamente no modelo, que eventualmente serão transformadas em outros modelos, que descrevem a implementação. Utilizando essa abordagem, naturalmente a documentação dos requisitos e da implementação estará atualizada. Além disso, no MDA é possível automatizar padrões de implementação. Dessa forma, o código-fonte gerado a partir do modelo não será apenas estrutural, uma “casca”. As lógicas que são comuns em várias aplicações ou em várias partes de uma mesma aplicação poderão ser geradas ou re-geradas automaticamente, sempre que houver necessidade. O objetivo deste trabalho é produzir um método de transformação e uma

ferramenta de apoio ao desenvolvimento de software baseado no paradigma MDA. Tal ferramenta deve permitir a modelagem e a geração de parte de aplicações, incluindo as interfaces com o usuário. Embora não esteja tradicionalmente no escopo do MDA detalhar como tratar as questões de interface, este é um aspecto que deve ser considerado para permitir o uso efetivo do conceito de MDA. Portanto, o foco do trabalho está em como tratar a modelagem de interface dentro do MDA. Para fazer uma validação informal do resultado deste trabalho, foi feita uma

comparação entre duas abordagens de desenvolvimento da mesma aplicação. A primeira utilizou o método proposto e a ferramenta desenvolvida neste trabalho e a segunda não usou o método e nenhuma ferramenta de automatização seguindo conceitos do MDA. Resultados preliminares indicam que a utilização da primeira abordagem possa trazer benefícios, como redução de erros, melhor documentação do sistema, padronização, melhora na qualidade e aumento de produtividade. O restante deste trabalho está estruturado da seguinte forma. A Seção 2 explica os

modelos independentes de plataforma definidos. A Seção 3 explica e justifica o método proposto, o MDGI. A Seção 4 apresenta e discute os resultados desse trabalho. Na Seção 5 são apresentadas as conclusões.

2 Modelos

No MDA [7] [18] [23], o processo de desenvolvimento se inicia com a modelagem do PIM (Plataform Independent Model). Por isso, o primeiro passo neste trabalho foi definir a linguagem de modelagem que seria utilizada para o PIM. O PIM foi dividido em dois modelos que têm características diferentes e objetivos

distintos. O primeiro, denominado PIM Domain, tem como objetivo modelar o domínio da aplicação ou sistema, ou seja, os conceitos e regras de negócio, sem preocupação com aspectos de interação (interface) com o usuário. O segundo, denominado PIM UI, tem como objetivo de modelar o aspecto que não é tratado no primeiro: a interação com o usuário. O segundo modelo não replica o que já foi


342

definido no PIM Domain, ele simplesmente deverá fazer referência quando necessário. Portanto, ele é depende do PIM Domain. O PIM UI foi baseado nos modelos propostos por Rosenberg [16], Artim [21],

Nunes [10] e Pinheiro da Silva [14] [15], acrescentando-se aspectos que permitem a geração de PSMs (Plataform Specific Model) e código-fonte da aplicação, tanto partindo do PIM Domain quanto do PIM UI. Os modelos propostos pelos autores acima identificados foram projetados para modelar a interação com o usuário, mas não foram projetados para permitir geração automática de código-fonte. A descrição detalhada [9] dos modelos PIM Domain e PIM UI será objeto de um

artigo futuro. Embora o formato dos modelos utilizados neste trabalho seja uma contribuição importante, o principal objetivo aqui é a descrição da transformação de PIM Domain para PIM UI. Os modelos e as transformações PSMs relacionadas também foram definidos e implementados, sendo possível criar uma aplicação a partir dos modelos PIM UI e PIM Domain usando a método descrito a seguir.

3 Método de Desenvolvimento e Geração de Interfaces - MDGI

Nesta seção apresentamos uma visão geral do MDGI. O MDGI prescreve a separação do PIM em dois aspectos ou modelos, um que descreve o domínio do sistema e outro que descreve a interação com o usuário. O modelo requer também a existência de pelo menos uma transformação do primeiro para o segundo modelo. O PIM Domain e o PIM UI são as instanciações desses dois aspectos, assim como a transformação de PIM Domain para PIM UI é a instanciação da transformação definida como necessária pelo MDGI. A separação do PIM nesses dois aspectos permite trabalhar em alto nível e ainda se

ter flexibilidade suficiente para modelar a interação do sistema com o usuário de maneira a conseguir atender aos requisitos do sistema de forma satisfatória. A modelagem da interação com o usuário em alto nível é importante, pois podemos abstrair de detalhes de tecnologia. Esse nível de abstração já foi proposto por Rosenberg [16], Artim [21] e Nunes [10] antes do surgimento do MDA. Nossa abordagem vai além, permitindo que o modelo seja usado para gerar o sistema com código-fonte de qualidade, separando os conceitos de domínio e de interface com o usuário. E, ainda, a modelagem da solução que atende aos requisitos do sistema pode ser reaproveitada para gerar a aplicação para diferentes tecnologias ou plataformas. Isso é possível graças ao mecanismo de transformação de PIM para PSM previsto no MDA. Além da independência de plataforma, o mecanismo de transformação permite que o conhecimento de utilização de determinada tecnologia seja embutido na própria transformação. Com isso, a aplicação desse conhecimento pode ser automatizada pela execução da transformação sobre os modelos PIMs. Durante o desenvolvimento deste trabalho, tomamos conhecimento que depois do

surgimento do MDA os autores Courbis [4], Schattkowsky [19] e Vanderdonckt [22] chegaram a adaptar ou mapear suas ferramentas e métodos que já vinham sendo desenvolvidos para o MDA. Eles de alguma forma já contemplavam a interface com o usuário no PIM. No entanto, percebemos que eles não atendiam a todos os requisitos do MDA à risca e, sendo nossa proposta diferente, cremos que o nosso trabalho seja


343

uma contribuição mais clara e direta em termos da tecnologia MDA, além de demonstrarmos alguns resultados de acordo com a análise que será apresentada mais a frente. Não basta apenas dividir o PIM em dois aspectos. A transformação do PIM

Domain para o PIM UI também tem um papel importante no MDGI. Essa transformação deve utilizar a aplicação de padrões (patterns) para gerar o modelo de interação com o usuário que poderá ser alterado para adaptar-se aos requisitos do sistema. Depois de aplicado o MDGI, os passos seguintes seguem o MDA. Os dois modelos PIM, o de domínio e o de interação, são transformados em modelos PSM, que por sua vez são transformados em código-fonte. Portanto, o MDGI pode ser considerado um método para se usar ou criar o PIM. A Fig. 1 mostra detalhadamente como o MDGI pode ser instanciado; nesta figura estão ilustrados todos os passos, transformações e modelos.

Fig. 1. Transformações, modelos e passos do MDGI.

A separação da modelagem de domínio da modelagem da interação com o usuário é um ponto importante neste trabalho. A separação desses dois aspectos está presente em várias técnicas no processo de desenvolvimento de software. Entre elas destacamos, por exemplo, as de análise, como a apresentada por Rosenberg [16], Nunes [10] e Artim [21], que ressaltam a importância da separação destes dois aspectos. No desenvolvimento de sistemas, também existem abordagens que recomendam a implementação de objetos de negócio sem envolver aspectos de

Passo 1. Criar o PIM Domain. Passo 2. Executar a

transformação.

Passo 3. Se houver necessidade alterar o PIM UI.

Passo 4.

Executar a transformação.

Passo 6. Se houver necessidade alterar o PSM Hibernate.

Passo 7. Se houver necessidade alterar o PSM Struts.

Passo 5.

Executar a transformação.

Passo 8. Executar a transformação.

Passo 10. Se houver necessidade alterar o Código-fonte do Hibernate.

Passo 11. Se houver necessidade alterar o Código-fonte do Struts.

Passo 9. Executar a transformação.

Modelo

Linguagem do modelo Especificação da transformação

Legenda:

Linguagem de origem da transformação

Linguagem de destino da transformação

Linguagem usada no modelo

Transformação

PSM

Hibernate PSM Struts

Código-fonte

do Hibernate

Código-fonte

do Struts

Perfil UML do PSM Hibernate

Perfil do PSM Struts

Java + Struts

Java + Hibernate

PSM Hibernate para Código-fonte

PSM Struts para Código-fonte

PIM Domain

Perfil UML do PIM UI

Perfil UML do PIM Domain

PIM UI

PIM Domain para PIM UI

PIM Domain para PSM Hibernate

PIM UI para PSM Struts


344

interface com o usuário [20]. Esses objetos, em sua maioria, são responsáveis por implementar os dados e regras de negócio do domínio da aplicação. Na modelagem independente de plataforma proposta pelo MDA, os mesmos argumentos se aplicam. Por esse motivo e por outros apresentados ao longo deste trabalho, propomos a separação do PIM nesses dois aspectos. A seguir destacamos alguns benefícios dessa abordagem: − Conceitos e regras do domínio podem ser reutilizados em várias interfaces com o usuário sem replicação de modelagem e, conseqüentemente, de código. Dessa forma, a modelagem de qualquer tela que usa um conceito da aplicação não precisará replicar as informações já modeladas no modelo de domínio da aplicação, basta referenciar. Isso também favorece a manutenção, pois como o conceito está descrito apenas em um lugar, alterações são nele centralizadas.

− Os conceitos do domínio são modelados de forma clara e o relacionamento das interfaces com o usuário com esses conceitos é explícito, facilitando o entendimento das regras de negócio do sistema.

− Facilita a geração automática da interface com o usuário a partir de padrões aplicados no modelo de domínio (PIM Domain). A transformação de PIM Domain para PIM UI implementada e realizada neste

trabalho contempla a aplicação de uma solução aplicando o padrão que pode ser chamado Caso de uso CRUD1. Neste trabalho, o caso de uso CRUD representa uma forma padronizada de modelar e consequentemente de implementar interfaces com o usuário para criar, visualizar, alterar e excluir entidades que representam os conceitos do domínio do sistema. Resumidamente, pode-se dizer que para cada classe de entidade do PIM Domain, envolvidas na transformação, é gerado, no PIM UI, classes que representam as interfaces que permitem o usuário realizar estas operações do CRUD. Depois de aplicada a transformação e, conseqüentemente, o padrão CRUD, pode-se alterar a modelagem da interface para atender aos requisitos, excluindo dela alguma dessas operações e/ou incluindo outras. Essa característica de alterar a aplicação do padrão (pattern) é aderente à idéia de padrões de projeto [5] que estabelece o padrão como um guia para solução de um problema. A aplicação do padrão deve ser adaptada ao contexto onde ele está sendo utilizado. O CRUD foi escolhido porque é um padrão básico presente em grande parte das

aplicações, principalmente nas chamadas aplicações enterprise. Entretanto, nossa transformação pode ser estendida para acrescentar novos aspectos ou variações a esse padrão. Podem ser implementadas também outras transformações com o intuito de automatizar a aplicação de outros padrões, inclusive o intuito é que, em projetos reais, isso seja feito. Conforme já explicado, o MDGI requer a existência de um modelo que represente

o domínio da aplicação e um que represente as interfaces com o usuário. Os dois não precisam ser necessariamente o PIM Domain e o PIM UI que foram definidos neste trabalho, mas recomendamos a utilização deles. No entanto, se os modelos definidos aqui não satisfizerem às necessidades específicas de desenvolvimento, podem ser alterados, estendidos ou redefinidos.

1 O termo CRUD vem do inglês Create (criar), Read (ler), Update (atualizar) e Delete (apagar). Este termo é muito usado no contexto de banco de dados representando as operações básicas. É comum que casos de uso utilizem essas operações.


345

4 Discussão dos Resultados

Nesta seção, comparamos duas abordagens de desenvolvimento de um caso de uso de um sistema denominado Merci. Na primeira abordagem foi usado o processo Praxis [11] [12] padrão, que é um processo de desenvolvimento de software que não utiliza o MDA. Na segunda abordagem, serão usados os modelos e transformações definidos neste trabalho. O Praxis é um processo desenvolvimento de software desenhado para uso na educação, mas usado também em uma versão industrial pelo Synergia2, onde este trabalho vem sendo desenvolvido, e por empresas brasileiras de desenvolvimento de software. O Merci é um sistema definido como exemplo ilustrativo na documentação do Praxis [13]. Nessa documentação são disponibilizados o código-fonte e toda a documentação de implementação da aplicação conforme o Praxis padrão. Para fazer a comparação, foi escolhido o Caso de uso Gestão de usuário, o qual contém funcionalidades básicas de inclusão, alteração, exclusão e pesquisa de usuários. A comparação foi feita utilizando os seguintes aspectos: diferenças dos modelos

UML usados, quantidade de código-fonte gerado automaticamente, quantidade de elementos UML gerados, padronização e reaproveitamento de convenções e soluções de implementação (reuso), quantidade de código-fonte das transformações, qualidade do código-fonte e produtividade.

4.1 Diferenças dos Modelos UML

No Praxis, a modelagem de um sistema é separada em duas partes: o Modelo do Desenho Externo (MDE) e o Modelo do Desenho Interno (MDI). A primeira tem o objetivo de descrever as funções do sistema sob o ponto de vista do usuário, sem detalhes técnicos. A segunda tem o objetivo de descrever internamente como o sistema foi implementado. O MDE é constituído por classes que representam as interfaces com o usuário,

dispostas em dois diagramas de classes, um de estrutura dinâmica, que modela detalhadamente a navegação entre telas, e um diagrama de estrutura estática, que modela relacionamentos entre telas: generalizações, composições e agregações. O MDE contém também diagramas de seqüência que representam os fluxos comuns das interações do usuário com o sistema. O MDI é constituído (dentre outros elementos) por classes que implementam o sistema. Elas são dispostas em diagramas de classes de fronteira, de controle e de entidade. Os conceitos de MDE e MDI do Praxis têm algumas características semelhantes

aos conceitos de PIM e PSM do MDA. Ambos o MDE e o PIM se propõem a modelar o sistema com foco em suas funções e não em detalhes de tecnologia ou plataforma. A diferença entre os dois é que no MDE existe a preocupação em modelar o sistema sob o ponto de vista do usuário, ou seja, só as interfaces com o usuário são modeladas. No PIM, não existe essa restrição e, normalmente, tem-se uma preocupação em modelar os conceitos que o sistema manipula e implementa. O MDI

2 O Synergia é o laboratório de engenharia de software do Departamento de Ciência da Computação da Universidade Federal de Minas Gerais.


346

e o PSM se propõem a modelar detalhes de implementação do sistema como um todo, considerando principalmente os aspectos de tecnologia ou plataforma. É importante destacar que, no MDE, a falta de elementos que modelam os

conceitos do sistema dificulta a execução de transformações sobre o mesmo. O PIM Domain proposto neste trabalho supre justamente essa deficiência. Já o PIM UI o complementa com informações relativas à interação com o usuário. A junção do PIM Domain e do PIM UI permite a automatização do desenvolvimento do software e sem perda da modelagem da interface com o usuário, representada em alto nível, sem detalhes de implementação. Além disso, usando o MDGI, o PIM UI pode ser gerado automaticamente a partir do PIM Domain. Para requisitos específicos, que vão além das operações básicas de consulta, criação, exclusão e alteração de entidades, é necessário alterar ou complementar o PIM UI. Entretanto, no contexto de elaboração do PIM, foi eliminado o trabalho manual que envolve essas operações básicas, que podem ser comuns em sistemas. Existem ainda outras diferenças entre o PIM e o MDE, como, por exemplo, a

existência de protótipos e de Casos de Uso de Desenho no MDE. Mas a diferença mais importante, considerando o contexto deste trabalho, foi a descrita acima. Esses elementos não existentes no PIM poderiam continuar a ser criados manualmente ou talvez não sejam mais necessários, pois as transformações permitem gerar um sistema funcional bem próximo do que se pretende como versão final do sistema. Com isso, ao invés de usar o protótipo, pode-se fazer validações utilizando a versão do sistema gerada automaticamente.

4.2 Quantidade de Código-fonte Gerado

Como estamos comparando a implementação da mesma função e desejamos que o código-fonte gerado tenha pelo menos a mesma qualidade, uma de nossas expectativas é que a quantidade de linhas do código-fonte seja bem parecida entre as implementações das duas abordagens. Conforme apresentado na Tabela 1, a diferença na quantidade de linhas foi muito

pequena entre as duas abordagens, confirmando nossa expectativa.

Tabela 1. Comparação da quantidade de linhas do código-fonte.

Abordagem de desenvolvimento Quantidade de linhas do sistema Não-automatizado (Praxis) 689 Automatizado (MDGI) 697

4.3 Quantidade de Elementos UML Gerados

Com relação aos elementos UML usados na modelagem das duas abordagens existem grandes diferenças, tanto em relação à quantidade quanto ao tipo dos elementos. A comparação entre a Tabela 2 e a Tabela 3 mostra essas diferenças, que são justificadas


347

pelo fato dos modelos serem bem diferentes entre as duas abordagens, conforme discutido na seção 4.1.

Tabela 2. Quantidade de elementos de modelagem da abordagem não automatizada (Praxis).

Modelo Número de elementos dos diagramas de classes

Número de elementos dos diagramas de seqüência

Total

MDE 28 66 94

MDI 111 - 111

Tabela 3. Quantidade de elementos de modelagem da abordagem automatizada (MDGI).

Modelo Número de elementos dos diagramas de classes

Número de elementos dos diagramas de seqüência

Total

PIM Domain 7 - 7 PIM UI 32 - 32 PIM 39 - 39

PSM 104 - 104

A Plataforma Praxis foi incluída na contagem dos elementos na abordagem Praxis

porque é nela que grande parte da função está descrita. Ao comparar o total de elementos do MDE (94) com o total do PIM (39),

percebemos que o MDE tem mais que o dobro de elementos. Isso se deve aos diagramas de seqüência que não estão presentes na abordagem MDGI. Desconsiderando os diagramas de seqüência, o total de elementos de diagramas de classe do MDE (28) já fica mais próximo do total do PIM (39). Essa diferença se deve ao fato de o Praxis não representar, no MDE, os conceitos do sistema, que na abordagem MDGI é representado pelo PIM Domain. Ao comparar o total de elementos do MDI (111) com o total do PSM (104),

percebemos que os valores são bem próximos. Esse fato é justificado pelo mesmo motivo apresentado na seção anterior, pois esses modelos representam de forma bem próxima o código-fonte do sistema. Essas comparações todas são feitas para reforçar dois pontos. Primeiro, os

diagramas de seqüência representam uma quantidade grande em termos de elementos UML e, conseqüentemente, construí-lo ou consultá-lo demandará esforço considerável. A abordagem MDGI não requer os diagramas de seqüência, conforme explicado na seção 4.1. Segundo, a abordagem MDGI não requer muitos elementos a mais do que uma abordagem não-automatizada. Os elementos adicionais necessários são representados pelo PIM Domain. Apesar de serem mais elementos no modelo, são fáceis de ser criados por dois motivos. Primeiro, porque comparado ao PIM UI é necessário uma quantidade bem menor de elementos. Segundo, porque esses elementos podem ser extraídos quase que diretamente do modelo de entidade da análise, o qual é usado como insumo essencial pelo Praxis para gerar o MDE, mas não é considerado parte do MDE.


348

4.4 Padronização e Reutilização

Tanto na implementação do Merci pelo Praxis, quanto na implementação deste trabalho, houve a preocupação de criar elementos reutilizáveis. Entretanto, a nossa abordagem (MDGI) permite uma dimensão de reutilização que não é possível com a utilização do Praxis em versão não automatizada. Essa dimensão é possível graças às regras de transformação, que são reutilizadas na transformação de cada elemento de modelagem transformado. Esse não é simplesmente um reaproveitamento de componente de software, mas pode ser considerado como o reuso do conhecimento de utilização de alguma tecnologia. Neste trabalho foram criadas transformações que permitem a reutilização de conhecimentos relacionados à implementação de vários aspectos das tecnologias usadas na implementação: Hibernate [1] e Struts [26]. Por exemplo, como um relacionamento de composição entre duas classes deve ser

implementada usando o Hibernate? A resposta a essa pergunta está implementada em uma regra de transformação específica. O mesmo ocorre com a classe de enumeração, a navegação de uma página para outra, o salvamento dos dados de uma entidade e vários outros aspectos. Além dessa reutilização, é importante destacar que a execução dessas

transformações gera outro resultado importante. Os modelos e o código-fonte criados pelas transformações são padronizados, pois os elementos de modelagem, com as mesmas características, são gerados pela mesma regra de transformação. Principalmente em sistemas desenvolvidos por equipe, esta padronização é difícil de alcançar, uma vez que o número de soluções possíveis é indefinido. Além disso, a solução de implementação dada por cada desenvolvedor dependerá de sua experiência técnica. Por mais que se tente difundir os padrões de soluções e desenho na equipe, é da natureza humana errar. Portanto, a padronização é difícil de se alcançar e não é totalmente garantida. Em longo prazo, presume-se que essa padronização ajude na manutenção do sistema, pois, supondo que as soluções implementadas pelas transformações sejam conhecidas, essas serão mais claras e centralizadas.

4.5 Quantidade de Código-fonte das Transformações

Este é um dos pontos mais importantes da comparação entre as duas abordagens. Conforme apresentado na Tabela 4, a contagem de linhas das transformações foram divididas em dois módulos.

Tabela 4. Quantidade de linhas de código-fonte das transformações.

Módulo da transformação Quantidade de linhas 1. Regras de transformações 3.915 2. Elementos reutilizáveis entre as regras 1.638

O segundo módulo contém funções que facilitam a manipulação dos elementos

UML e são usadas em várias regras de transformações. Ele foi separado em um módulo à parte porque seu conteúdo não sofrerá muitas modificações caso seja necessário alterar ou acrescentar regras de transformação.


349

O primeiro módulo contém as lógicas das regras de transformação. A quantidade de linhas desse módulo (3.915 linhas) é praticamente seis vezes maior do que a quantidade de linhas de código gerado na aplicação (697 linhas). Em relação a essa diferença, gostaríamos de destacar alguns aspectos: − Essa grande diferença é um indicativo forte de que o esforço necessário para implementar as transformações é bem maior do que para implementar a aplicação manualmente.

− Apesar dessa diferença de tamanho ao comparar com o código-fonte do sistema gerado, deve-se lembrar que, além do código-fonte, essas transformações geram também os modelos PIM UI, PSM Domínio e PSM Struts. Em outras palavras, parte do código do módulo é responsável pela criação desses modelos e não pela geração direta do código da aplicação. Em nossa abordagem, não faz sentido desconsiderar a parte do módulo responsável por gerar os modelos, pois sem eles não é possível gerar o código-fonte. Embora a quantidade de linhas comparada seja em relação apenas ao código gerado, é importante destacar que além do código são gerados também os modelos, o que é uma característica positiva.

− A implementação das transformações tende a ser mais complexa do que a do sistema, pois ela tem que considerar a complexidade dos modelos e código-fonte que ela está gerando mais a complexidade de implementação da própria transformação.

− O esforço de implementação das transformações pode ser amortizado ao longo do desenvolvimento de vários sistemas.

Apresentado esses aspectos, sugerimos que, ao optar por implementar

transformações, primeiro é preciso avaliar o grau de reutilização (considerando nosso experimento, o grau de reutilização deveria ser superior a seis vezes). Quanto maior essa reutilização mais diluído será o custo de implementação das transformações. Caso contrário, o custo/benefício da abordagem MDGI não se justifica. É importante ressaltar que o parâmetro linhas de código usado para chegar a esse

número de seis vezes é controverso. Entretanto, ele já é um indicativo forte e já nos permite ter uma noção mais clara de quando é indicado ou não optar por se criar regras de transformação. A fim de tentarmos confirmar esse valor de seis vezes, usamos um outro

parâmetro: o esforço para implementar as transformações foi de 196,2 horas e o esforço total para implementar o caso de uso sem automatização foi de 36,1 horas, conforme apresentado na Tabela 5. Ao comparar esses dois valores chegamos ao valor 5,4, que é bem próximo de seis. Isso novamente é indicador de que, nas condições aqui descritas, para implementar as transformações é necessário um esforço seis vezes maior do que para implementar a função desejada no sistema.

4.6 Qualidade do código-fonte

De forma geral, a qualidade do código-fonte não é diretamente ligada ao fato de o desenvolvimento ser ou não automatizado. De acordo com o CMMI [25], a qualidade está ligada ao processo (procedimentos e métodos), pessoas (habilidades, treinamentos e motivação) e tecnologia (ferramentas e equipamentos). No processo, o


350

CMMI prevê as áreas de validação e verificação que são diretamente ligadas à qualidade externa e interna do software. Com o intuito de garantir a qualidade tanto no desenvolvimento do software usando a abordagem automatizada, quanto no desenvolvimento das transformações, todos esses aspectos relativos à qualidade podem e devem ser considerados. No entanto, partindo do princípio que no desenvolvimento das transformações

foram tomados os cuidados citados no parágrafo anterior, por construção, um software que utiliza estas transformações já herdam a qualidade das mesmas.

4.7 Produtividade

Observe na Tabela 5 que o esforço para gerar o sistema (8,7 horas) é 4 vezes menor que o esforço para implementar o sistema (36,1 horas). Portanto, se desconsiderarmos a implementação das transformações, existe um ganho de produtividade considerável.

Tabela 5. Esforço para construção de parte do sistema.

Modelo Esforço em horas Abordagem não automatizada (Praxis) 36,1 Abordagem automatizada (MDGI) 8,7

A fim de confirmar se a quantidade de esforço empregada no Merci (abordagem

não-automatizada) é próxima do esforço de desenvolvimento fora de ambientes controlados, comparamos os dados do Merci com os dados do Relatório de métricas de um projeto do Laboratório Synergia. Os dados apresentados nesse relatório são de Casos de uso com complexidade considerada simples que seria a complexidade equivalente ao Caso de uso Gestão de usuário do Merci que foi implementado durante este trabalho. No processo (de desenvovlimento) personalizado do Synergia, o MDI não é considerado um modelo formal. O processo personalizado considera que o Desenho Interno é realizado durante a tarefa de codificação e é documentada pelo próprio código-fonte. Na comparação foi verificado que a diferença do esforço total entre o caso de uso do Merci e a média dos casos de uso do Synergia é pequena (3,5%). Isso mostra que os dados apresentados pelo Merci são dados bem próximos da realidade em um ambiente de desenvolvimento. Como foi discutido na seção 4.5, o esforço de implementação das transformações é

grande e a tendência é que o custo desse esforço se dilua à medida que as transformações sejam reutilizadas em funções diferentes do sistema ou dos sistemas. É importante destacar que na implementação das transformações deve-se ter

cuidado especial, pois transformações com soluções ruins poderão espalhar soluções ruins pelo sistema inteiro. Por isso, as transformações devem implementar soluções maduras e consolidadas. Caso contrário, grandes retrabalhos podem ser necessários, cujas conseqüências não foram exploradas nesta pesquisa.


351

5 Conclusão

A partir de experiências de produção de software usando modelos, este trabalho identificou possíveis aspectos nos quais o desenvolvimento pode ser melhorado. Sobre esse assunto foram estudadas metodologias como o Model-Driven Software

Development (MDSD) [3] e MDA. Com esses estudos, decidiu-se fazer uma aplicação prática da utilização do MDA com o intuito de analisar o resultado final dessa aplicação. Metodologias MDA, em geral, não especificam como devem ser tratados o desenvolvimento e a modelagem da interação com o usuário, o que é aspecto importante na produção de software. Portanto, foram estudados modelos de interação com o usuário antes e depois do surgimento do MDA e nenhum deles se adequava completamente à especificação de MDA. Por isso, baseando-se nesse estudo, decidiu-se criar o PIM UI, que é um modelo independente de plataforma de interação com o usuário. As principais contribuições desta pesquisa foram a criação do MDGI e a definição do PIM UI. Além do PIM UI, foram definidos também três modelos: o PIM Domain e PSM

Hibernate e o PSM Struts. Sob o ponto de vista de contribuição deste trabalho, estes modelos têm importância menor. O PIM Domain porque seus elementos e a forma com que eles são usados já são bem conhecidos em várias experiências usando o MDA. O PSM Hibernate e o PSM Struts por representarem a implementação em tecnologias e plataformas específicas. Esses modelos podem ser substituídos por outros representando a implementação em outras tecnologias. No entanto, eles são fundamentais para aplicação do MDA e, portanto, foram fundamentais para possibilitar a aplicação prática do PIM UI, validando-o informalmente e possibilitando a análise desta aplicação. A aplicação MDGI proposta neste trabalho foi comparada com o desenvolvimento

usando o Praxis, no qual não é previsto nenhum tipo de automatização de geração de modelos e de código-fonte funcional. Ao analisar esta comparação, destacamos três aspectos em que houve grandes diferenças. Primeiro, sob o ponto de vista de padronização e reutilização, foi possível

encapsular, com o uso de regras de transformações, a implementação de um dado modelo, independente de tecnologia, em determinada tecnologia. O Praxis, assim como a maioria dos processos, não se preocupa em padronizar, documentar e repetir esse mapeamento, que fica a cargo do conhecimento específico de cada projetista e de cada implementador e, portanto, esse mapeamento acaba não sendo importante no processo de desenvolvimento de software. Com a abordagem MDGI, atingimos um nível de abstração em que conseguimos fazer modelagem independente de tecnologia e reutilizar conhecimentos implementados sob forma de regras de transformações para gerar implementações específicas de tecnologia. Esse nível de reaproveitamento não é possível sem a adoção de abordagens como o MDA e o MDSD, que naturalmente acabam proporcionando uma padronização na forma com que esse mapeamento é feito. Com o PIM UI foi demonstrado que esse tipo de reutilização é possível também no nível de interface com o usuário. Segundo, conforme mostrado na comparação de produtividade, na apresentação da

quantidade de elementos UML e código-fonte gerados, a abordagem MDGI proporciona ganho de produtividade considerável, desconsiderando o esforço de implementação das transformações. Além dos dados mostrados nesse trabalho Bettin


352

[2] e Herst [6] também mostraram que a utilização do MDA pode propiciar ganho de produtividade. Terceiro, apesar do ganho de produtividade, é importante ressaltar que ele não vem

de graça. Neste trabalho, nossas medições indicam que a implementação das transformações chega a gastar um esforço 6 vezes maior do que o necessário para implementar o que elas se propõem a gerar. Portanto, antes de decidir implementar transformações é altamente recomendado analisar se elas serão suficientemente reutilizadas a ponto de pagar esse custo e ainda se obter ganhos. Além dessa questão, é importante ressaltar que devem ser implementadas

transformações que geram modelos e código-fonte com soluções maduras e consolidadas. Caso contrário, o risco desse custo alto pode ser ainda mais elevado, acarretando grandes retrabalhos para correção das soluções imaturas. Outro ponto que é importante destacar em relação ao código-fonte gerado pelas

transformações é que ele não seja redundante. Trechos de código que seriam idênticos entre as transformações devem ser isolados em componentes fora delas e apenas ser invocados pelo código gerado pela transformação. Estes podem ser componentes de interface com o usuário, de entidade, de controle ou até mesmo utilitários. O importante é que tenham o código-fonte aberto para que a aplicação seja mais facilmente estendida, se necessário. Conforme elucidado nas boas práticas do MDSD, geração de código-fonte que não segue este princípio tende a ser complexa, de difícil manutenção e extensibilidade. Neste trabalho, também foi mostrado que o MDE e o MDI do Praxis têm conceitos

parecidos ao PIM e ao PSM do MDA, respectivamente. Por isso, desde que no PIM sejam contemplados conceitos de interface com o usuário como o PIM UI faz, a inclusão da abordagem MDGI dentro do processo Praxis é praticamente direta, embora os modelos tenham que ser alterados para expressar tudo que é necessário para a geração de modelos e código. Dessa forma, os modelos e transformações propostos neste trabalho podem ser usados diretamente no processo Praxis.

Agradecimentos. Ao programa de iniciativa acadêmica da IBM por oferecer ferramentas e ambiente de desenvolvimento que foram de grande valia para realização deste trabalho.

Referências

1. Bauer, C.; King, G., Hibernate in action, Manning, 2005. 2. Bettin, J., Model-Driven Architecture – Implementation & Metrics. Disponível em: http://www.softmetaware.com/mda-implementationandmetrics.pdf, Agosto, 2003, último acesso em fevereiro de 2005.

3. Bettin, J., Model-Driven Software Development, Versão 0.8. Disponível em: http://www.softmetaware.com/mdsd-and-isad.pdf, Junho, 2004, último acesso em fevereiro de 2005.

4. Courbis, A.; Lahire, P.; Parigot, D., To build open and evolutive applications: an approach based on MDA and Generative Programming, Technical report, INRIA, 2003.

5. Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.


353

6. Herst, D.; Roman, E., Model Driven Development for J2EE Utilizing a Model Driven

Architecture (MDA) - Approach: A Productivity Analysis, TMC Research Report, Junho, 2003.

7. Kleppe, A.; Warner, J.; Bast, W., MDA explained, the Model Driven Architecture:

Practise and Promise, Addison-Wesley, 2003. 8. Kobryn, C., UML 2001: A Standardization Odyssey, Communications of the ACM, Vol. 42, No. 10, páginas 29-37, Outubro 1999.

9. Issa, L., Desenvolvimento de Interface com Usuário Dirigida por Modelos e Geração

Automática de Código, Dissertação de mestrado, UFMG, Belo Horizonte, Brasil, Novembro, 2006.

10. Nunes, N.; Cunha, J., Wisdom: A Software Engineering Method for Small Software Development Companies. IEEE Software, Vol. 17, No. 5, páginas 113-119, Setembro/Outubro, 2000.

11. Paula Filho, W. P., A Model-driven Software Process for Course Projects. Proceedings of Educators' Symposium of the ACM / IEEE 8th International Conference on Model Driven Engineering Languages and Systems. Montego Bay, Jamaica, Outubro, 2005.

12. Paula Filho, W. P., Engenharia de Software: fundamentos, métodos e padrões. LCT, 2a edição, 2002.

13. Paula Filho, W. P., Praxis 2.1. Disponível em http://www.wppf.uaivip.com.br/praxis/2.1/Praxis 2.1.htm, último acesso em janeiro 2007.

14. Pinheiro da Silva, P.; W. Paton, N., User Interface Modeling in UMLi. IEEE Software, Vol. 20, No. 4, Julho/Agosto, 2003, páginas 62-69.

15. Pinheiro da Silva, P., User Interface Declarative Models and Development Environments: A Survey. In Proceedings of DSV-IS 2000, LNCS, Limerick, Ireland, Junho, 2000. Springer-Verlag.

16. Rosenberg, D., Use Case Driven Object Modeling with UML: A practical Approach, 3a edição, Addison-Wesley, 1999.

17. Rumbaugh, J.; Jacobson, I.; Booch, G., The Unified Modeling Language Reference Manual, Addison Wesley, 2 a edição, 2004.

18. Santos, H.; Barros, R., Utilizando o MOF na construção de metamodelos em um ambiente

MDA. SBES, Brasília, 2004. 19. Schattkowsky, T.; Lohmann, M., UML Model Mappings for Platform Independent User

Interface Design, MoDELS Satellite Events 2005, páginas 201-209. 20. Singh, I.; Stearns, B.; Johnson, M., Designing Enterprise Applications with the

J2EETMPlatform, 2 a Edição, Addison-Wesley, 2002. 21. Artim, J. M. ´Entity, Task, and Presenter Classification in User Interface Architecture: An

Approach to Organizing HCI Practice´ in Van Harmelen, M., Object Modeling and User

Interface Design: Designing Interative Systems, Addison-Wesley, 2001. 22. Vanderdonckt, J., A MDA-Compliant Environment for Developing User Interfaces of

Information Systems, CAiSE 2005, páginas 16-31. 23. Object Management Group., OMG Model Driven Architecture. Disponível em:

http://www.omg.org/mda, último acesso em fevereiro de 2005. 24. Object Management Group., UML Superstructure Specification, v2.0, Agosto, 2005.

Disponível em: http://www.omg.org/cgi-bin/doc?formal/05-07-04, último acesso em novembro de 2005.

25. Software Engineering Institute., CMMI® for Development, Version 1.2 - Improving processes for better products, CarnegieMellon, Agosto, 2006. Disponível em: http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html, último acesso em fevereiro de 2007.

26. The Apache Software Foundation., Struts 1.2.x, Novembro, 2005. Disponível em: http://struts.apache.org/struts-doc-1.2.x/index.html, último acesso em novembro de 2005.


354

Sesión 10 Requisitos y Colaboración

355

OO-Sketch: una herramienta para la captura de requisitos de interacción1

José Ignacio Panach, Sergio España, Inés Pederiva, Óscar Pastor


Camino de Vera s/n, 46071 Valencia, España {jpanach, sergio.espana, ipederiva, opastor}@dsic.upv.es

+34 96 387 7000

Resumen. Actualmente no existe un método ampliamente aceptado para la cap-tura de requisitos de interacción. El dibujo de bocetos de la interfaz de usuario va cobrando poco a poco un papel importante dentro de este ámbito. Es necesa-rio el desarrollo de herramientas que permitan dibujar estos bocetos en formato digital. Además, siguiendo el paradigma MDA, el esfuerzo aplicado en la cap-tura de requisitos debería verse reflejado en etapas posteriores de Modelado Conceptual. La herramienta encargada de soportar el dibujo de bocetos también debería ser capaz de realizar esta transformación desde los requisitos al Modelo Conceptual. El objetivo de este trabajo es abordar ambos aspectos. Por un lado, se presentan las primitivas para realizar los bocetos. Por otro lado, se presenta la estrategia abordada para su transformación automática hacia el Modelo Con-ceptual definido por OO-Method, un método de producción de software con-forme con MDA. La herramienta de edición de bocetos, llamada OO-Sketch, alcanzaría su máxima potencia como parte de la tecnología ONME, la cual in-cluye un compilador de modelos que, a partir del Modelo Conceptual, es capaz de generar la correspondiente aplicación software totalmente funcional.

1 Introducción

El campo de la Ingeniería del Software (IS) ha mostrado una preocupación histórica por el modelado de los requisitos funcionales de los sistemas. Sin embargo, así como hay modelos ampliamente conocidos para la captura de requisitos funcionales, no existe un modelado comúnmente aceptado para los requisitos de interacción con el usuario. Para encontrar estudios sobre este tipo de requisitos, es necesario recurrir a la comunidad de Interacción Persona Ordenador (IPO).

Una de las técnicas usadas dentro del ámbito de la comunidad IPO para la captura de requisitos de interfaz de usuario es el uso de bocetos (sketches). Esta técnica se ba-sa en el dibujo a mano alzada de las interfaces a través de las cuales el usuario quiere interactuar con el sistema de información. Esta forma de modelar tiene como principal


TIN2004-03534 y cofinanciado por FEDER. También ha participado el programa de becas FPI de la Generalitat Valenciana.


357

ventaja su simplicidad a la hora de ser entendida por el usuario final ya que, aunque sus conocimientos en informática sean escasos, le será fácil razonar con estos bocetos sobre el aspecto que presentará la aplicación software. Hoy en día son numerosas las aplicaciones que se han construido para soportar el dibujo de estos bocetos en formato digital, diseñándolos con variados dispositivos de interacción (p.e. lápices electróni-cos). De esta manera, el usuario final de la aplicación puede involucrarse en la fase de captura de requisitos de interacción. Este hecho facilita que la aplicación final genera-da sea más usable para el usuario, ya que éste puede validar desde las primeras fases de desarrollo del software si los bocetos cumplen los requisitos de interacción que él mismo plantea. La propuesta del trabajo presentado en este artículo está basada en es-ta línea de soporte digital para los bocetos. La idea es engarzar esta técnica de diseño temprano de interfaz en un marco de desarrollo de software que sigue el paradigma Model Driven Architecture (MDA) [9], con el fin de reaprovechar las especificacio-nes realizadas en la etapa de Captura de Requisitos para derivar parte de los Modelos de Análisis. Como caso particular, se pretende introducir esta técnica dentro de OO-Method [13], un método de producción de software que permite la generación auto-mática de código. Este método se basa en la separación de dos niveles de abstracción diferentes: el espacio del problema y del espacio de la solución. Esto sitúa a OO-Method como una metodología para implementar herramientas siguiendo las directri-ces MDA, ya que separa la especificación conceptual de las aplicaciones de sus posi-bles implementaciones software. OO-Method tiene su implementación industrial en la tecnología OlivaNova Model Execution2 (ONME). En la Figura 1 se presenta el pro-ceso de desarrollo de software OO-Method, desde la captura de requisitos a la cual proponemos incluir una actividad de Captura de Requisitos de Interacción, hasta la generación automática del código final mediante un compilador de modelos.

Fig. 1. Proceso de desarrollo de sistemas software con OO-Method

En este trabajo se presenta la estrategia adoptada para la especificación de los re-quisitos de interacción. Se propone un modelo combinado con dos vistas: bocetos de

2 Care Technologies: http://www.care-t.com


358

interfaz y modelos de tareas en la notación ConcurTaskTrees (CTT) [14]. En este ar-tículo se presentan las primitivas de los bocetos de interfaz; es decir, la manera en que se va a permitir construir los bocetos. Estas primitivas se presentan a nivel conceptual con el fin de implementarlas en la herramienta de construcción de bocetos OO-Sketch en trabajos futuros. Una interesante aportación al campo del modelado de interfaces es que estas primitivas gráficas se hacen corresponder con patrones estructurales de tareas, que son las piezas con las que proponemos componer los modelos de tareas. Así, los modelos de tareas se convierten en la representación estructurada y algebraica de los bocetos, de manera que constituyen un soporte formal para su repositorio. Am-bas vistas se construyen de manera simultánea y el sustrato CTT resulta transparente para el ingeniero de requisitos.

Otra aportación de este trabajo es la posibilidad de encuadrar el diseño de los boce-tos en un marco de producción automática de software. En trabajos anteriores [12] fueron definidos los patrones estructurales de tareas y su correspondencia con patro-nes del Modelo de Presentación OO-Method, a partir del cual es posible la generación del código de la aplicación software. El presente trabajo amplía esta estrategia me-diante la inclusión de bocetos, poniéndola al alcance de los usuarios.

La estructura del documento es la siguiente: en la sección 2 se presenta el método de producción automática de software OO-Method, en la sección 3 se muestran las correspondencias entre los bocetos y los árboles estructurales de tareas, en la sección 4 se exponen las distintas variedades de interacción que debe ofrecer la herramienta presentada, en la sección 5 se aplican todos estos conceptos sobre un caso de estudio, en la sección 6 se realiza un estudio del estado del arte de otras herramientas ya exis-tentes que soportan el dibujo de bocetos, identificando sus bondades y carencias y, fi-nalmente, en la sección 7 se presentan las conclusiones del trabajo.

2 OO-Method: hacia un proceso de desarrollo holístico

OO-Method es un método para la construcción de sistemas software; abarca desde la fase de requisitos hasta la generación automática del código final. En la Figura 1 se muestra gráficamente el proceso de producción y los modelos que lo soportan.

En una primera fase se lleva a cabo la Captura de Requisitos. Consideremos un modelo de requisitos funcionales compuesto por la Misión del Sistema (una descrip-ción del ámbito del sistema), el Árbol de Refinamiento de Funciones (una jerarquía de descomposición de funciones que debe ofrecer el sistema) y un modelo de Casos de Uso (cada hoja del árbol se considera un caso de uso, que es refinado mediante planti-llas de escenario).

Estos artefactos facilitan la fase de Análisis, durante la cual se realiza el modelado conceptual del sistema. El Modelo Conceptual describe de manera prescriptiva los tres ejes de un sistema de información: • El Modelo de Objetos permite especificar la vista estática, la estructura de las cla-

ses identificadas en el dominio del problema, así como las relaciones estructurales y las relaciones de agentes sobre los servicios de las clases.

• El Modelo Dinámico y el Modelo Funcional se centran en el comportamiento del sistema. El Modelo Dinámico determina las posibles secuencias de eventos que


359

pueden ocurrir en la vida de los objetos. El Modelo Funcional especifica el efecto que tienen los eventos sobre el estado de los objetos.

• Por último, el Modelo de Presentación ofrece una descripción abstracta de la inter-faz del sistema. Este modelo está estructurado en tres niveles de patrones de inter-faz [10]:

Nivel 1. Árbol de jerarquía de acciones: siguiendo el principio de aproxima-ción gradual [7] expresa cómo la funcionalidad será presentada al usuario que acceda al sistema. Es una abstracción del menú de la aplicación que da acceso a los patrones del siguiente nivel. Nivel 2. Unidades de interacción (UI): modela las unidades de interfaz abstrac-ta que el usuario deberá emplear para llevar a cabo sus tareas. Cuatro patrones pueden combinarse para conformar la interfaz: la UI de Instancia modela la pre-sentación de los datos de un objeto del dominio, la UI de Población permite mostrar una lista de instancias, la UI de Maestro-Detalle permite hacer combi-naciones de las anteriores para presentaciones más complejas, la UI de Servicio modela un formulario de entrada o modificación de datos. Su estructura y com-portamiento puede especificarse con más detalle mediante patrones de nivel 3. Nivel 3. Patrones elementales: Permiten restringir y precisar el comportamien-to de las diferentes unidades de interacción. Con ellos se definen filtros, ordena-ciones, acciones, navegaciones, etc.

A partir del Modelo Conceptual se aplica la Compilación de Modelos y se obtiene una aplicación software completamente funcional. El código final está organizado en una arquitectura de tres capas: la de interfaz, la de lógica y la de persistencia.

OO-Method define un proceso de desarrollo basado en el modelado conceptual. El Modelo Conceptual definido, artefacto estrella de esta aproximación, tiene en consi-deración tanto los aspectos estáticos del sistema, como su dinámica y la interacción con agentes externos; ofrece mecanismos para la descripción del sistema como un to-do. Sin embargo, el Modelo de Requisitos Funcionales necesita ser complementado con un Modelo de Requisitos de Interacción que permita la captura de las necesidades interactivas de los usuarios. En trabajos anteriores [4] se ha resuelto esta carencia me-diante el uso de modelos de tareas, utilizando la notación CTT. El trabajo que presen-tamos extiende esta propuesta superponiendo al árbol de tareas una capa de bocetos de interfaz. De esta manera es posible implicar al usuario más directamente en la cap-tura de requisitos de interacción. La principal contribución del trabajo es la definición de correspondencias entre la capa de bocetos y la capa de tareas que permiten la cons-trucción simultánea de ambos modelos. Al editar el boceto, es posible construir de manera automática el árbol de tareas subyacente.

3 Construcción sincrónica de bocetos y modelos de tareas

Los bocetos son un modelo temprano de la interfaz gráfica de usuario. Para definir un nuevo modelo, la primera cuestión es determinar su conjunto de constructores ele-mentales. Se trata de definir las primitivas con las que se podrá construir un boceto de interfaz. Por las características eminentemente gráficas de un boceto, la concepción de estas primitivas está muy ligada a su representación visual. Conviene separar varios


360

aspectos: (1) la propia primitiva, el concepto que hay detrás del constructor elemental definido; (2) por otro lado aparece la interacción con la herramienta, la variedad de formas en que se puede añadir (y manipular) la primitiva a un boceto; (3) otro aspecto es la variada representación visual que dicha primitiva tiene en el boceto.

Fig. 2. Aspectos ligados a la definición de primitivas de boceto

A continuación se presentan los aspectos conceptuales, acompañándolos de la re-presentación visual cuando sea conveniente. La estrategia que la herramienta OO-Sketch debe proporcionar para la construcción sincrónica de los bocetos y sus árboles CTT equivalentes, hace aconsejable una correspondencia biunívoca entre las primiti-vas de boceto y los patrones estructurales de tareas. De esta manera, ya queda defini-do el conjunto de conceptos: por cada patrón estructural de tareas debe definirse una primitiva de boceto. Por motivos de espacio, este trabajo está centrado en los patrones estructurales de tareas relacionados con el listado de instancias.

3.1. Población

El objetivo es presentar al usuario un listado con instancias de una clase de objetos de negocio (p.e. un listado con los clientes de la empresa). En [12] se presentaron los pa-trones estructurales de tareas vinculados con esta Unidad de Interacción.

Fig. 3. Primitiva gráfica y patrón estructural de tareas para la Población.

Para dotar de flexibilidad gramatical a los modelos de tareas, se propuso un meca-nismo de composición de patrones: los dobles corchetes << >> denotan puntos donde se enganchan otros patrones estructurales de tareas. Los círculos con números se in-cluyen en las figuras como ayuda para facilitar el entendimiento de los vínculos entre las primitivas.


361

Como se observa en la Figura 3, la primitiva de boceto para la Población de instan-cias consiste en un contenedor marcado con un icono de rejilla en la esquina superior derecha, según la notación propuesta en [10] para este patrón. En el interior del con-tenedor aparecen espacios delimitados para agregar otras primitivas de boceto.

3.2. Visualización

La primitiva de Visualización permite especificar gráficamente los campos que se mostrarán de las instancias de la población. Se trata de un conjunto de columnas a las que se puede asignar nombre. En la fase de análisis, cuando derivemos el Modelo de Objetos, los campos aquí definidos estarán vinculados con atributos de las clases.

Fig. 4. Primitiva gráfica y patrón estructural de tareas para la Visualización.

3.3. Acciones

Las Acciones son operaciones que se pueden realizar sobre la instancia seleccionada entre las listadas por la Población. Algunas acciones son muy habituales (p.e. la crea-ción de nuevas instancias, la modificación y el borrado), otras son más particulares del sistema que estamos bosquejando.

..

.Acción1

AcciónN

2

Fig. 5. Primitiva gráfica y patrón estructural de tareas para las Acciones.

3.4. Navegación

La Navegación permite acceder a otras pantallas de la aplicación. Si bien el menú de una aplicación constituye una navegación taxonómica (organiza el acceso a la funcio-nalidad del sistema), la primitiva de boceto que nos ocupa define una navegación es-tructural, a través de la cual se accede a partes de la aplicación que soportan la edición o consulta de objetos del negocio estructuralmente asociados con el objeto origen. Por ejemplo, desde una población de líneas de factura podríamos navegar a la ficha del cliente o al pedido del cual proceden.


362

Fig. 6. Primitiva gráfica y patrón estructural de tareas para la Navegación.

3.5. Filtro

La primitiva de boceto del Filtro permite especificar un criterio de filtrado para las instancias listadas por la población. Para ello se realizan marcas sobre los campos por los cuales se desea filtrar. Estos campos marcados instancian los argumentos del pa-trón estructural de tareas correspondiente.

Fig. 7. Primitiva gráfica y patrón estructural de tareas para el Filtro.

3.6. Ordenación

La primitiva de Ordenación se define de manera similar a la de Filtro, realizando una serie de marcas sobre los campos por los cuales se desea una ordenación. Junto con la primitiva de Filtro, proporciona al usuario el tratamiento sencillo de poblaciones muy extensas.

Fig. 8. Primitiva gráfica y patrón estructural de tareas para la Ordenación.

4 Consideraciones sobre la usabilidad de la herramienta

Las herramientas de boceto de interfaces se caracterizan por ofrecer una interacción ágil para construir el boceto de las ventanas. Los avances tecnológicos en materia de reconocimiento de formas y escritura, unidos al creciente interés por los desarrollos dirigidos por modelos, han hecho posible la aparición de herramientas que interpretan


363

las interacciones del diseñador para ir construyendo un modelo estructurado de la in-terfaz dibujada. Para que una herramienta de este tipo tenga aceptación entre los usua-rios, es necesario que sea flexible en sus formas de interacción.

La herramienta que planeamos construir debe ofrecer gran variedad en la edición de las primitivas de boceto. A continuación, se desarrolla el vértice superior de la Fi-gura 2 (la interacción con la herramienta), y se elaboran ciertos aspectos de la repre-sentación visual que completan las definiciones de la sección anterior.

Se conciben dos vertientes interactivas principales, que dependerán en gran medida de los dispositivos hardware de interacción utilizados por el diseñador. • Lápiz: Permite trazar los bocetos con rapidez, pero la introducción de texto requie-

re de técnicas de reconocimiento de formas textuales. Especialmente apropiado pa-ra el uso con PDAs y tablet PCs, con portátiles y ordenadores de sobremesa se acompaña de tableta digitalizadora. Es indicado para reuniones con el usuario.

• Ratón y teclado: La flexibilidad a la hora de dibujar formas geométricas es menor; sin embargo la introducción de texto es más precisa. Es indicado para completar, en una segunda iteración, los bocetos realizados con el usuario.

Concebimos una herramienta de edición de bocetos que permita la inclusión de las primitivas de varias maneras, siempre buscando la mínima interacción necesaria para llevar esto a cabo. Por ejemplo, la primitiva de población es una estructura gráfica compleja, pero basta trazar una forma rectangular con un icono de rejilla para que la herramienta pueda interpretar que debe colocar la primitiva (interacción con lápiz, ver Figura 9). Otra opción es arrastrar la primitiva desde una librería hasta el modelo acti-vo (interacción con ratón, ver Figura 10).

Fig. 9. Trazado de la primitiva y reconocimiento (modo de interacción con lápiz).

Fig. 10. Librería de primitivas (modo de interacción con ratón).

Nuestra propuesta para la interacción con lápiz supone, además, una concepción del sketching que mejora la calidad visual de los bocetos diseñados: al reconocer una


364

primitiva, se sustituye el trazo del diseñador por la representación gráfica correspon-diente. De esta manera, el resultado es más homogéneo (véase la Figura 9).

5 Caso de estudio

Como caso de estudio se ha elegido un sistema de gestión de una empresa de suminis-tro de agua. Esta aplicación tiene como finalidad la gestión de clientes, de materiales, registro de las lecturas en los contadores, emisión de facturas y un control sobre las tareas que cada operario realiza. Para simplificar el caso de estudio, se ha elegido la tarea Listar Contadores, que se utiliza para obtener un listado con todos los contado-res del sistema. El boceto que dibujaría el analista para capturar los requisitos de in-terfaz sería similar al de la Figura 11.

Cerrar

Zona #Contad Modelo Abonado Dirección

Abonado Lecturas Calibre

Crear

Modif

Borrar

F FF F F F FO O

Fig. 11. Boceto para Listar Contadores

La Figura 11 muestra un boceto que se convertirá en una Unidad de Interacción de Población una vez aplicada la transformación de modelos. El listado de contadores puede ser filtrado y ordenado, utilizando para ello las primitivas Filtro (F) y Orden (O). En la Figura 11 se aprecian dos filtros, representados por dos filas de F’s. Cada uno de ellos utiliza como filtrado los campos en los cuales aparece la marca F. En el boceto quedan reflejados los campos que se mostrarán de los contadores, las acciones que se puedan ejecutar sobra las instancias y las navegaciones que se pueden realizar.

Mientras el analista va dibujando los bocetos con el usuario, se van creando los ár-boles CTT que representan las interfaces dibujadas. El árbol de la tarea estudiada (ver Figura 12) se ha construido utilizando las transformaciones del apartado 4.


365

Fig. 12. Árbol CTT para la tarea Listar contadores

Tal y como se explica en trabajos anteriores [12], una vez se han construido los ár-boles CTT, el analista puede derivar automáticamente el Modelo de Presentación de OO-Method. Para ello se utilizan las correspondencias definidas entre los patrones es-tructurales de tareas y los patrones del Modelo de Presentación. Construido el Modelo de Presentación, la generación de la interfaz final es también totalmente automática, utilizando para ello el compilador de modelos de ONME.

Fig. 13. Interfaz final para Listar contadores

La Figura 13 muestra la interfaz final para la tarea estudiada. En ella se pueden apreciar las características dibujadas en el boceto, es decir, los filtros, ordenaciones, navegaciones, campos que se visualizan y acciones.

6 Trabajos relacionados

Actualmente existe una cierta variedad de herramientas para realizar el dibujo de bo-cetos de interfaz y, a partir de estos, obtener una interfaz final de manera automática.


366

En esta sección se presentan algunas de las más relevantes. Por un lado están las herramientas específicas para el diseño de un determinado tipo de aplicaciones; así ocurre en el caso de DEMAIS [1], especialmente pensada para diseñar aplicaciones multimedia. Esta herramienta permite a un diseñador plasmar las ideas de interacción y de temporalidad y ver el resultado obtenido con la herramienta. Fue desarrollado pa-ra el uso sobre una pantalla electrónica que permite al diseñador dibujar directamente sobre ésta. Para crear el diseño, DEMAIS proporciona storyboards, scripts de voz y editores multivista.

Otra herramienta similar es DENIM [11], que ayuda a los diseñadores de sitios web durante las primeras fases de diseño a través de bocetos a diferentes niveles de refinamiento: el mapa del sitio, storyboard y páginas individuales. También unifica los niveles a través de vistas. Al igual que la herramienta anterior, los dibujos están pensados para ser realizados sobre la pantalla usando un lápiz electrónico.

Por otro lado se encuentran algunas herramientas utilizadas para diseñar aplicacio-nes de cualquier tipo. Una de estas herramientas es SILK [8], que permite dibujar los bocetos tanto con pantalla gráfica como con ratón. El usuario puede usar cuatro primi-tivas: rectángulo, línea libre (para el texto), línea recta y elipse. Combinando estas primitivas se forman los prototipos de interfaz, que serán transformados mediante la herramienta en ventanas reales en Visual Basic 5.0 o Common Lisp. El diseñador puede elegir el estilo de los componentes de la interfaz una vez la herramienta reco-noce a cada uno de esos componentes (p.e. el tipo de botón). Para ilustrar la navega-ción entre las interfaces se utilizan storyboards.

Otra herramienta similar es JavaSketchIt [2] que, al igual que la anterior, permite el dibujo de bocetos sobre una pantalla usando un lápiz electrónico. Para ello, usa una combinación de figuras simples que representan cada uno de los componentes de in-terfaz posibles (widgets). La identificación de estas figuras se realiza utilizando la li-brería CALI [4]. Cuando no es posible la identificación inequívoca de una figura, el sistema de reconocimiento devuelve una lista de posibles candidatos. La aplicación puede entonces elegir el mejor candidato dependiendo de la información contextual. Identificados todos los componentes gráficos se genera la interfaz en código Java.

Freeform [15] es otra herramienta basada en el dibujo de bocetos sobre una panta-lla electrónica para diseñar formularios de Visual Basic. La herramienta tiene un es-pacio para trazar los bocetos, donde se puede dibujar, escribir sobre ellos y editar. El texto escrito a mano es interpretado posteriormente usando el algoritmo de Rubine [16]. Antes de que se genere el formulario en Visual Basic, el usuario puede modifi-car las decisiones de reconocimiento que ha llevado a cabo la herramienta, eligiendo otro tipo de control a través de una lista. Para la navegación entre bocetos se utilizan también los storyboards. Dispone de un modo de ejecución en el que el usuario puede probar las navegaciones y escribir sobre los componentes dibujados con el editor. Esta herramienta también posee la funcionalidad de alinear los controles creados y deter-minar un tamaño estándar para esos controles.

Por último, existe una herramienta que no genera código específico para un deter-minado lenguaje de programación. SketchiXML [3] genera especificaciones de inter-faces de usuario en UsiXML [17], un lenguaje de descripción de interfaces de usuario independiente de plataforma. A partir de UsiXML se puede generar código en HTML, XHTML y Java, mediante el uso de otras herramientas de su suite. El usuario de SketchiXML traza los dibujos que luego son reconocidos utilizando la librería CALI,


367

al igual que en JavaSketchIt. Esta herramienta es capaz de avisar al usuario sobre po-tenciales problemas de usabilidad en los bocetos dibujados. Una vez se ha completado la fase de diseño, SketchiXML analiza sintácticamente la información de diseño (par-sing) para generar una especificación UsiXML. Existen reglas de transformación para adaptar un modelo UsiXML creado en un contexto concreto a otro distinto (p.e. pasar de un diseño para PDA a uno para ordenador de sobremesa). Además, las representa-ciones de las figuras que se pueden dibujar en el boceto son configurables por el usua-rio.

En cualquier caso, existe una limitación común a todas las herramientas descritas anteriormente: solo generan la interfaz del sistema software, y en algunos casos, la navegación entre interfaces. La propuesta de este trabajo es una aportación notable al área del diseño de bocetos: OO-Sketch está concebida para incorporarse a un proceso de generación automática de código completamente funcional. Como caso particular, describimos su inclusión en la tecnología ONME, donde no solo se genera la interfaz de la aplicación software, sino toda su funcionalidad del sistema de información.

OO-Sketch es, junto con SketchiXML, una de las pocas herramientas de bocetos totalmente independiente del lenguaje de implementación que se generará. La mayo-ría de herramientas están pensadas para lenguajes de implementación específicos, como es el caso de Freeform o JavaSketchIt. Sin embargo, a partir de los bocetos de OO-Sketch se pueden generar aplicaciones en Visual Basic, .NET, Java/Swing, Cold-Fusion, JSP, ASP y PocketPC.

Por último, cabe destacar que la propuesta OO-Sketch está pensada para ser ejecu-tada tanto en ordenadores de sobremesa como en dispositivos móviles. La inserción de texto puede realizarse bien mediante un lápiz electrónico cómo a través de un te-clado y las figuras se pueden dibujar tanto con un lápiz electrónico, como con un ra-tón. La variedad interactiva depende del tipo de dispositivo sobre el que se dibuje el boceto. Las herramientas anteriormente citadas no proporcionan esta flexibilidad a la hora de realizar los bocetos; si bien SILK permite el dibujo de figuras mediante lápiz electrónico o ratón, el texto únicamente puede ser introducido mediante teclado.

7 Conclusiones y trabajos futuros

En este trabajo se ha presentado una técnica de generación automática de interfaces a partir de bocetos. Esta técnica, unida a la compilación de modelos ya existente en la tecnología ONME, permite que se generen sistemas software totalmente ejecutables. Realizando el Modelado Conceptual y los bocetos no es necesario escribir ni una sola línea de código.

Para materializar estas ideas, se ha definido una serie de transformaciones que permite construir sincrónicamente bocetos de interfaz de usuario y árboles estructura-les de tareas (CTT). Una vez construidos estos árboles, se puede generar automática-mente el Modelo de Presentación que utiliza ONME. A partir de este Modelo de Pre-sentación, junto con los otros modelos que habrá definido el analista (Modelo de Objetos, Modelo Dinámico, Modelo Funcional) se genera el sistema software de ma-nera automática.


368

Como trabajo futuro contemplamos la implementación de una herramienta capaz de dibujar bocetos que generen árboles CTT de manera transparente para el analista. Para ello la herramienta debería disponer de un reconocedor de formas para identifi-car los componentes de los bocetos dibujados con lápices electrónicos. Por otro lado, utilizando las correspondencias entre primitivas de boceto y patrones estructurales de tareas descritas en este artículo, se implementaría la creación sincrónica de árboles de tareas a partir de los bocetos. Esta funcionalidad, unida a la transformación del mode-lo de tareas al Modelo de Presentación y del Modelo de Presentación a la interfaz fi-nal, proporcionará una herramienta capaz de generar interfaces de usuario de manera automática con una gran rapidez, lo que permitirá una rápida realimentación del usua-rio

Otra ventaja de usar un lenguaje formal como CTT es la posibilidad de validar los bocetos con los cuales están vinculados. Así pues, se pretende implementar un valida-dor sintáctico de árboles de tareas de manera que solo se permitan árboles CTT (y por lo tanto bocetos) válidos.

Por último, se planea realizar un estudio empírico de la propuesta. Para ello se lle-varán a cabo una serie de experimentos sobre la herramienta OO-Sketch con el objeti-vo de comprobar las mejoras metodológicas que conlleva su uso. Del mismo modo, se llevarán a cabo evaluaciones de la usabilidad tanto en el uso de la herramienta como de las aplicaciones que se generen. Además, se estudiará la posibilidad de incorporar a la herramienta OO-Sketch un evaluador temprano de usabilidad [5] que realice pre-dicciones parciales sobre la usabilidad de la aplicación software que se esté modelan-do.

8 Referencias

[1] Bailey, B. P., Konstan, J.A. (2003). Are Informal Tools Better? Comparing DEMAIS, Pen-cil and Paper, and Authorware for Early Multimedia Design. En Actas del Human Factors in Computing Systems CHI’2003. New York: ACM Press.

[2] Caetano, A., Goulart, N., Fonseca, M., Jorge, J. (2002). JavaSketchIt: Issues in Sketching the Look of User Interfaces. En Actas de AAAI Spring Symposium - Sketch understand-ing.AAAI Press; pp. 9–14.

[3] Coyette, A., Vanderdonckt, J. (2005). A Sketching Tool for Designing Anyuser, Anyplat-form, Anywhere User Interfaces. En Actas de INTERACT 2005, LNCS 3585; pp. 550-564.

[4] España, S., Panach, I., Pederiva, I., Pastor, O. (2006) Towards a Holistic Conceptual Mod-elling-Based Software Development Process. En Actas de 25th International Conference on Conceptual Modeling (ER2006); Tucson, Arizona, USA; pp. 437-450

[5] España, S., Pederiva, I., Panach, J.I., Abrahão, S., Pastor, O. (2006). Evaluación de la Us-abilidad en un Entorno de Arquitecturas Orientadas a Modelos. En Actas del 9° Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software (IDEAS 2006). La Plata, Buenos Aires, Argentina; pp. 331-334.

[6] Hong, J. I., Li, F.C., Lin, J., Landay, J.A. (2001). End-User Perceptions of Formal and In-formal Representations of Web Sites. En Extended Abstracts of CHI’2001; pp. 385–386.

[7] ISO/IEC TR 9126-4 (2004). Software engineering - Product quality - Part 4: Quality in use metrics.

[8] Landay, J., Myers, B.A. (2001). Sketching Interfaces: Toward More Human Interface De-sign. IEEE Computer 34. pp. 56–64.

[9] MDA: http://www.omg.org/mda Última visita junio 2006.


369

[10] Molina, P. J. (2003). Especificación de interfaz de usuario: de los requisitos a la genera-ción automática. PhD. Departamento de Sistemas Informáticos y Computación. Valencia, Universidad Politécnica de Valencia; 382 páginas.

[11] Newman, M. W., Lin, J., Hong, J.I., Landay, J.A. (2003). DENIM: An Informal Web Site Design Tool Inspired by Observations of Practice." Human-Comp. Interaction 18; pp. 259–324.

[12] Panach, I., Pederiva, I., España, S., Pastor, O. (2006). Generación Automática de Interfa-ces a Partir de Patrones Estructurales de Tareas. En Actas de Interacción 2006, Puertollano, España.

[13] Pastor, O., Gómez, J., Insfrán, E. Pelechano, V. (2001) The OO-Method Approach for In-formation Systems Modelling: From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems, 26(7) 507–534.

[14] Paternò, F., C. Mancini, et al. (1997). ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models. En Proceedings of the IFIP TC13 International Conference on Human-Computer Interaction, Chapman & Hall, Ltd. pp. 362-369.

[15] Plimmer, B. E., Apperley, M. (2003). Software for Students to Sketch Interface Designs. En Proc. of IFIP Conf. on Human-Computer Interaction INTERACT’2003, IOS Press; pp. 73–80.

[16] Rubine, D., (1991) Specifying gestures by example. En actas de 18th annual conference on Computer graphics and interactive techniques, ACM Press; pp. 329-337.

[17] Vanderdonckt, J., Q. Limbourg, B. Michotte, et al. (2004) USIXML: a User Interface De-scription Language for Specifying Multimodal User Interfaces. En actas de W3C Workshop on Multimodal Interaction WMI'2004. Sophia Antipolis, Grecia.


370

Colaboração e Negociação na Elicitação de Requisitos

Danilo Pestana de Freitas1, Marcos R. S. Borges1, Renata Mendes de Araújo2

1 Programa de Pós-Graduação em Informática IM&NCE Universidade Federal do Rio de Janeiro, Brasil

2 Departamento de Informática Aplicada Universidade Federal do Estado do Rio de Janeiro, Brasil

[email protected]; [email protected]; [email protected]

Abstract. Em um projeto de desenvolvimento de software, requisitos bem definidos são insumos fundamentais à construção de um sistema. O levantamento de requisitos é uma etapa de grande interação entre usuários e engenheiros de requisitos, tornado-a propícia a uma análise sobre a colaboração em suas atividades. Identificou-se, então, uma oportunidade para o desenvolvimento de um processo que valorize a colaboração e a negociação entre as equipes com o objetivo de reduzir a ambigüidade dos requisitos, aumentar seu entendimento e melhorar o nível das definições. Procura-se assim, aumentar a qualidade do produto e reduzir o volume de re-trabalho, possibilitando a definição de prazos e custos mais reais. Este artigo explora esta abordagem, apresentando um processo e uma ferramenta de apoio à colaboração e à negociação na fase de levantamento e definição dos requisitos do sistema. Uma avaliação baseada em um estudo de caso real é apresentada.

Keywords. Requisitos, Colaboração, Negociação

1. Introdução

Requisitos bem definidos são insumos fundamentais à construção do sistema capaz de atender às reais necessidades dos usuários. Pesquisas indicam que grande parte dos problemas da engenharia de software surge nas primeiras interações entre usuários e analistas. Embora muitos trabalhos tenham sido desenvolvidos com o objetivo de organizar e melhorar esta etapa do ciclo de desenvolvimento de software, requisitos ainda chegam às etapas subseqüentes com baixo nível de entendimento, grau de ambigüidade elevado e com algumas indefinições, provocando re-trabalho, atrasos, aumento de custo e a confecção de um produto com qualidade discutível [9].

O levantamento de requisitos é uma atividade rica em interações, porém seu produto final, os requisitos, nem sempre são apresentados em níveis de detalhes que possam garantir um entendimento de quem deles se utiliza durante a construção do sistema. A proposta deste trabalho está focada na necessidade de organizar essa atividade de forma colaborativa, para que os refinamentos necessários à descrição dos requisitos, sejam percebidos e efetivamente utilizados por toda equipe.

Este artigo descreve uma proposta para uma elicitação de requisitos realizada de forma colaborativa, que apóia a interação e a negociação com argumentos e propostas


371

visando buscar o consenso. A hipótese que norteia o trabalho pode ser então descrita da seguinte forma: “A utilização de um processo de trabalho, apoiado na colaboração e na negociação, durante o levantamento de requisitos, aumenta o grau de entendimento da equipe e possibilita a construção de requisitos menos ambíguos, melhores descritos, mais completos, necessários e providos de consenso”.

O artigo está dividido em 6 seções. Na próxima seção discutem-se vários aspectos relacionados aos requisitos, que possibilitem o entendimento da importância desta atividade no contexto do desenvolvimento adequado do software. A Seção 3 apresenta o processo proposto, abordando uma alternativa de resolução dos problemas selecionados, baseado no suporte à colaboração e a negociação. Uma ferramenta de apoio ao processo descrito é apresentada na Seção 4. A Seção 5 relata a preparação e os resultados de um estudo de caso que foi utilizado para proporcionar uma primeira análise dos resultados gerados pelo enfoque proposto. A Seção 6 apresenta as conclusões, contribuições, limitações e propostas de trabalhos futuros.

2. Problemas da Fase de Levantamento de Requisitos

O levantamento de requisitos é uma fase que compreende o período em que o engenheiro de requisitos procura entender o problema e a necessidade do usuário. Esta é uma atividade multidisciplinar, pois lida com aspectos sociais e humanos de forma tão intensa quanto com os aspectos técnicos. Há diversas metodologias e técnicas para o levantamento de requisitos [9]. Wiegers [14], Togneri, Menezes e Falbo [13], Baez e Brunner [2] propõem uma divisão em quatro etapas principais, considerando as atividades de elicitação, análise, especificação e validação. Uma quinta atividade pode ser destacada para que tenha um grau de relevância diferenciada e se refere à priorização de requisitos.

Na Priorização de Requisitos, o principal objetivo é resolver conflitos entre usuários sem comprometer o interesse de cada um. Devem-se atribuir prioridades aos requisitos de acordo com as necessidades dos usuários objetivando atender primeiro aqueles mais críticos para a organização. Em geral, os modelos de negociação identificam as principais necessidades de cada usuário, atribuindo prioridade às necessidades mais relevantes.

Por outro lado, os requisitos não são estáticos. Eles evoluem durante todo o ciclo de vida de um sistema. A gerência de requisitos é o estabelecimento de um processo com o objetivo de gerenciar e controlar as mudanças nos requisitos e o relacionamento entre eles. Pressman [12] e Wiegers [14] consideram que um requisito é rastreável se for possível identificar quem o solicitou, porque o requisito existe, quais os requisitos relacionados e como os requisitos se relacionam a outras informações do projeto. Boas práticas de gerenciamento de requisitos geram benefícios a médio e longo prazo, como maior satisfação do cliente e custos de desenvolvimento mais baixos.

Um grande contingente de problemas em projetos de desenvolvimento de software está relacionado à obtenção de requisitos. Christel e Kang [4] definem três categorias de problemas desta fase:


372

Problemas de escopo - onde os requisitos podem endereçar pouca ou demasiada informação, pois os limites do sistema nem sempre são definidos de forma precisa. Ocorre muitas vezes do usuário especificar detalhes técnicos desnecessários que podem confundir, ao invés de esclarecer, os objetivos gerais do sistema. Em alguns casos, há também a percepção de que os usuários não possuem uma compreensão plena do domínio do problema. Problemas de compreensão - os usuários não estão completamente certos das suas necessidades. Eles não possuem uma boa compreensão das capacidades e limitações de seu ambiente computacional, além de não possuir uma idéia precisa e explícita do sistema a ser desenvolvido. Há sempre requisitos conflitantes com as necessidades de outros usuários e muitos requisitos são ambíguos ou instáveis. Há também um volume considerável de mudanças dos requisitos. Os pontos de vistas entre o usuário e o analista de sistema são diferentes e colaboram para o desentendimento, principalmente por terem formação distinta. Problemas de volatilidade – os requisitos mudam com freqüência entre o momento inicial do projeto e a sua conclusão. A natureza do mercado provoca constantes mudanças, e se adaptar a elas durante a fase de definição dos requisitos é muito difícil. É preciso identificar corretamente os impactos destas mudanças e os inter-relacionamentos dos requisitos.

A ocorrência destes problemas pode conduzir o projeto a uma situação de difícil gerenciamento. É geralmente aceito que erros produzidos no estágio de requisitos, se não detectados até um estágio avançado do desenvolvimento de software, podem ser muito custosos. Entretanto, engenheiros de software gastam muito pouco tempo executando esta importante tarefa. É difícil motivar clientes para expressar precisamente o que eles necessitam, uma vez que eles nem sempre possuem um conhecimento completo sobre a funcionalidade do sistema pretendido [8].

Um grande número de problemas, relacionados ao levantamento de requisitos, já foi abordado e solucionado por diversas técnicas e ferramentas. Não obstante, alguns problemas ainda necessitam de solução. Martins e Daltrini [11] afirmam que apesar dessas técnicas oferecerem auxílio aos desenvolvedores, os problemas essenciais da elicitação de requisitos - dificuldade do usuário em saber o que ele realmente precisa, dificuldade de comunicação entre usuários e desenvolvedores e, conseqüentemente, dificuldade em organizar os requisitos do software para o desenvolvimento futuro – ainda constituem um desafio a ser superado.

3. Colaboração e Negociação no Levantamento de Requisitos

Apenas a existência de ferramentas apoiadas em colaboração não resolve os principais problemas relacionados ao levantamento de requisitos, porém o estímulo ao seu uso propõe melhorias significativas no levantamento de requisitos, pois groupware se mostra um caminho fértil para ajudar a solucionar alguns problemas [7]. Além da ferramenta, identifica-se a necessidade de que o processo de trabalho em uso pela equipe também seja colaborativo. O uso de um processo que estimule e amplie os aspectos de colaboração, que organize o trabalho, e estruture as atividades, propõe


373

uma equipe trabalhando de forma mais coesa, concentrada em um objetivo comum e com um nível de participação bem distribuído e equilibrado.

Formas como se obtêm requisitos demonstram a existência de algumas situações que vêm se perpetuando no cotidiano. Em geral, analistas reúnem-se com os usuários, realizam entrevistas, obtêm documentação para pesquisa, aplicam questionários e retornam aos seus postos de trabalho, buscando identificar através de todo este arcabouço, os requisitos para o projeto. É um trabalho individualizado e sujeito a interpretações circunstanciais. Formatam, então, um documento contendo os requisitos descobertos, fruto desta análise. O retorno ao usuário para uma validação ocorre poucas vezes e quando ocorre é de pouca eficiência. Em um número reduzido de empresas há processos bem definidos. Entretanto, mesmo para estes, considera-se a forma clássica de trabalho, com a participação de profissionais atuando isoladamente ou interagindo através da passagem de responsabilidade entre um e outro. O nível de contribuição no entendimento do requisito é relativamente baixo.

O isolamento dos grupos de trabalho acaba provocando lacunas no entendimento dos requisitos. Identifica-se uma necessidade real de aproximação maior dos profissionais para uma interação forte e colaborativa. Macaulay [10] fortalece esta idéia quando afirma que há, agora, uma aceitação geral da idéia da participação dos stakeholders nas atividades de requisitos e projeto do sistema. Pressman [12] confirma esta necessidade quando aborda que muito freqüentemente, usuários e engenheiros de requisitos têm inconscientemente um estado de espírito de ‘nós e eles’. Em vez de trabalhar como equipe para identificar e refinar requisitos, cada parte define seu próprio ‘território’ e se comunica por intermédio de uma série de memorandos e sessões de perguntas e respostas. A experiência tem mostrado que essa abordagem não funciona bem. Sobram mal-entendidos, informações importantes são omitidas e nunca é estabelecido um relacionamento de trabalho bem sucedido. Em Togneri, Menezes e Falbo [13] também se encontra pavimentação sólida para o papel colaborativo da engenharia de requisitos, considerada como uma tarefa interativa não trivial e que envolve intensa comunicação e colaboração humana.

Duas constatações sobre requisitos norteiam este trabalho: a) a fase de levantamento de requisitos é fundamental num projeto de software b) apesar de todo avanço nas técnicas, ferramentas e metodologias propostas, existem ainda pontos que precisam de aprimoramento. O que se propõe é oferecer uma alternativa que valorize o compartilhamento da responsabilidade e a colaboração, e que seja um processo que conduza o levantamento de requisitos de forma organizada, estruturada, e ainda que ofereça oportunidades de melhor uso do tempo disponível de todos os stakeholders.

3.1 O Processo Proposto

Embora o fundamento do levantamento de requisitos seja de uma atividade interativa, a necessidade de colaboração nem sempre é visível ou praticada. A falta de colaboração permite que se propaguem interpretações distintas dos requisitos, visto que o trabalho isolado de cada profissional compromete o entendimento correto e adequado das necessidades. A interação existente por si só, não gera o principal produto do trabalho em equipe, que é a co-responsabilidade. É oportuno lembrar que interagir nem sempre resulta em colaborar.


374

Assim, a proposta de solução nasce da necessidade de organizar e direcionar o trabalho de levantamento de requisitos. Busca-se o aumento do nível de colaboração, a melhora na comunicação, a criação de mecanismos que auxiliem o entendimento dos requisitos e ajude a criar um direcionador das atividades, a organização das discussões e apoio para a resolução de conflitos, que sempre surgem nesta atividade. A proposta está fundamentada nos seguintes princípios: Ser inerentemente apoiado em participação colaborativa - A engenharia de software como um todo e o levantamento de requisitos em particular podem ser considerados atividades com forte viés de trabalho em grupo. Togneri, Menezes e Falbo [13] contribuem com esta visão e propõem que o uso de CSCW pode ser útil na solução de alguns problemas característicos da engenharia de requisitos. O desenvolvimento das atividades e artefatos deve ser compartilhado por todos os componentes da equipe, utilizando-se de mecanismos de colaboração e comunicação. Cada produto gerado é definido como entrega do grupo. A manipulação dos artefatos é livre e incentivada - A contribuição que cada um pode fazer deve ser total, sem limites, em qualquer artefato. Deve-se permitir que qualquer artefato seja manipulado e alterado por qualquer participante, independente de sua autoria. Assim como a manipulação, os questionamentos devem ser incentivados e permitidos. Para evitar desvios ou que haja interferência não construtiva no trabalho em função desta liberdade e independência, o coordenador atua buscando o melhor resultado da atividade em grupo. A equipe deve possuir visibilidade sobre a participação de cada um – A equipe deve saber como está o desenvolvimento do trabalho e a contribuição de cada participante. Deve saber quem, quando, onde e como colaborou. O conhecimento generalizado da participação de cada um motiva aos demais e torna as interações mais dinâmicas e positivas. Busca-se a geração de uma importante sinergia proporcionando maiores e melhores contribuições para o projeto. Todas as interações e iterações devem ser registradas - É preciso registrar a vida de cada artefato, desde sua origem até sua aprovação final, quantas e quais foram às alterações que sofreu. Devem estar disponíveis também as interações realizadas a seu respeito tais como: questionamentos recebidos, conflitos criados, pontos fortes e fracos registrados ou mensagens trocadas. Assim, procura-se aumentar a capacidade da equipe de gerar e manter uma parte considerável de sua memória organizacional. Manter uma associação entre os requisitos e os processos de negócio da organização – requisitos originam-se, principalmente, dos objetivos organizacionais, portanto é importante incentivar esta reflexão. A associação entre requisitos e processos de negócio confirma a relevância dos requisitos. É especialmente importante para auxiliar nas atividades de negociação e priorização.

O processo proposto está dividido em fases, organização que facilita seu entendimento bem como oferece uma melhor visibilidade do estado do projeto ao longo do tempo. Considerou-se também que a divisão em fases permite um mecanismo para a revisão dos trabalhos e para a identificação dos pontos de controle do processo, pois a passagem de uma fase para outra deve ser refletida, negociada e decidida. Atribui-se ao coordenador do projeto a atividade de mudança de fase, uma vez que ele funciona como o canalizador dos trabalhos e detém uma percepção clara dos compromissos e da evolução do trabalho como um todo. As fases serão detalhadas a seguir e são representadas em forma de camadas como mostra a Figura 1.


375

Priorização

Requisitoscandidatos

ProblemasCandidatos

Oportunidades Candidatas

Funcionalidades NãoFuncionalidades

Problema Oportunidade

Processos deNegócio Requisitos

Problema

Oportunidade

Requisitos

Interdependência

Essencial

Desejado 1 2 N

Requisitoscandidatos

ProblemasCandidatos

Oportunidades Candidatas

Levantamento de Requisitos

Refinamento e Seleção

Associação

Priorização

Montagem daEquipe

Socialização e Planejamento

Coordenador

Escopo doProjeto

Contexto dosparticipantes

Contexto doprojeto

Plano deTrabalho

Glossário

Glossário

Equipe

Equipe

Equipe

Equipe

Fig. 1. Fases do processo em forma de camada

A primeira fase, denominada de Socialização e Planejamento, possui uma conotação voltada para a socialização da equipe, gerando um conhecimento recíproco entre seus componentes e para a organização do trabalho a ser realizado. Esta fase visa ainda prover a equipe do entendimento geral do processo que será usado e do conhecimento do projeto em que trabalharão. A segunda fase, Levantamento de Requisitos, tem como objetivo primordial a geração do maior volume de requisitos possíveis. Assim aplica-se o princípio da técnica de brainstorming. Segue a fase de


376

Refinamento e Seleção, onde o foco passa a ser o de refinar as descrições e selecionar os requisitos relevantes ao projeto e classificá-los em funcionalidade ou critérios de performance, acesso, qualidade e segurança. Depois de selecionados os requisitos são associados a problemas, oportunidades e processos de negócio na fase de Associação, que propõe uma reflexão sobre os requisitos selecionados quando os contrapõem aos problemas que pretendem resolver. A penúltima fase, chamada de Priorização, corresponde à necessidade de priorizar o desenvolvimento dos requisitos através do enfoque dos critérios de essencialidade e grau de importância, útil quando há escassez de recursos ou quando se pretende fazer entregas parciais do sistema.

Tabela 1 - Encaminhamento para resolução dos problemas

Problema Proposta Apresentada • Requisitos ambíguos • Requisitos incompletos • Dificuldades de entender as

necessidades dos usuários

O requisito será submetido à equipe que discutirá sobre a necessidade do mesmo, identificando conflitos e ambigüidades. O requisito será ainda validado e priorizado pela equipe. A proposta é de um refinamento sucessivo, que levará o requisito a uma redação final com menos ambigüidade e apresentado de forma mais clara.

• Identificação precária dos problemas ou oportunidades que os requisitos endereçam

O requisito será associado aos problemas e oportunidades identificadas pela equipe.

• Inexistência de um vocabulário comum

A equipe atualizará um glossário de termos que será base para o trabalho.

• Falta de registro formal das necessidades do usuário

Todas as interações e versões dos objetos, incluindo discussões e votações, devem ser registradas e acompanhadas pela equipe. O conceito de versão será muito importante para a recuperação do histórico.

• Falta de tempo para reuniões de esclarecimentos.

• Agendas incompatíveis • Distância geográfica.

O processo permite contribuições assíncronas e diminui a necessidade de reuniões síncronas e presenciais. Cada pessoa pode usar o seu tempo disponível para realizar o trabalho que não necessariamente esteja sincronizado com o de outra pessoa da equipe.

• Não há uma distinção clara entre os requisitos essenciais e os requisitos desejados

• Prioridades dos requisitos mal definidas

Os requisitos serão classificados em Essenciais e Desejáveis. Os requisitos desejáveis serão priorizados pela equipe que discutirá os motivos de cada priorização e os benefícios para o projeto.

• Conflitos de interesses O processo implementa mecanismos de resolução de conflito através de votação em propostas ou por escolha do patrocinador ou do coordenador.

A proposta muda o papel dos diversos stakeholders do projeto, principalmente os

usuários, quando oferece a estes uma participação mais ativa e constante em todo o ciclo de levantamento de requisitos, observando e contribuindo para a evolução destes. A proposta move o usuário da posição passiva que até então lhe era designada, com participação limitada a questionários ou entrevistas e posterior recepção de documentos compilados.

Propõe-se também mudar a forma de trabalhar dos engenheiros de requisitos, que freqüentemente é solitária e hermética. Após um conjunto de entrevistas e


377

questionários, eles dependem da sua própria interpretação para produzir um documento que dificilmente será lido e validado pelo usuário com o devido cuidado e tempo necessário. Nesta proposta, a interação pode ser imediata. Tão logo se descreva um requisito ou um problema, podem surgir perguntas ou comentários ou até uma sugestão de melhoria. Evidencia-se assim a participação colaborativa intensa e dinâmica entre engenheiros de requisitos, usuários e outros stakeholders. A Tabela 1 mostra um relacionamento entre estes problemas e as ações embutidas na proposta que pretende resolvê-los ou minimizá-los.

4. RECOLAB – Requisitos por Colaboração

Para implementar o processo desenvolveu-se um groupware que busca facilitar a comunicação e oferece registros eficientes de todas as interações ocorridas durante o trabalho, substituindo ou organizando os documentos gerados, tais como: atas, entrevistas e questionários, gerando um embrião da memória do grupo. A ferramenta oferece facilidades para o entendimento correto das necessidades, para estimular a geração de idéias, fomentar questionamentos e comentários e para a medição do nível de participação de cada pessoa, refinando de acordo com o processo a descrição dos requisitos, depurando seus problemas e indefinições.

Levantamento de

Requisitos

Memória de Grupo (projetos / requisitos)

Requisitos Projetos

Idéias

Idéias

AtasQuestionários

Questões

Questões

Oportunidades

Oportunidades

Problemas

Problemas

Patrocinador

Usuário

Analista de Sistemas

Administrador

Stakeholder

Medições

Pontos Positivos

Pontos Positivos

Medições

Fig. 2. RECOLAB – Requisitos por Colaboração

A Figura 2 representa a essência e concepção da ferramenta, proporcionando uma

interação colaborativa entre usuário, analista, patrocinador, administrador e outros stakeholders, incluídos aí os especialistas de domínio do projeto que se trabalhará. A ferramenta organiza e registra as idéias, problemas, oportunidades, questionamentos,


378

pontos positivos e negativos além de preparar indicadores da participação da equipe, otimizando o trabalho de levantamento de requisitos e pavimento a construção de uma memória da equipe.

O conhecimento que se acumula durante o levantamento de requisitos, congrega toda a história do trabalho e pode ser resgatada em vários momentos. Inicialmente, durante o próprio trabalho, retornando-se a questões anteriormente discutidas para recuperar os motivos e premissas das decisões. Depois, da mesma forma, pode ser vasculhada para ajudar em manutenções futuras, entendendo o passo a passo das definições, mantendo o rastreamento do requisito quando este sofrer qualquer solicitação de mudança.

4.1 Princípios gerais do RECOLAB

O ambiente RECOLAB foi desenvolvido com o objetivo de apoiar o processo de levantamento de requisitos proposto. O que implica em ser um canal facilitador para o trabalho em grupo com um enfoque voltado para a colaboração, organizando as atividades e aproximando os envolvidos, gerenciando sua comunicação, registrando os objetos e eventos ocorridos. A ferramenta reconhece os seguintes perfis: Administrador, responsável pela entrada dos parâmetros da ferramenta, o cadastro de pessoas e de projetos; Usuário, responsável pelo insumo básico das informações geradoras de requisitos; Coordenador da atividade de levantamento de requisitos, a quem cabe selecionar e negociar a participação dos membros da equipe, planejar o trabalho, acompanhar a participação da equipe, e verificar os pontos de controle; Engenheiro de requisito ou analista de sistemas, profissional da área de informática que atua em conjunto com os usuários no levantamento, classificação, especificação, validação e priorização dos requisitos; Patrocinador, responsável geral pelo projeto, é normalmente quem acredita nas possibilidades e nos benefícios que o software pode oferecer e investe no desenvolvimento do mesmo.

Durante as atividades, o RECOLAB oferece ao coordenador alguns elementos de percepção sobre o andamento do trabalho e o nível de participação e de contribuição de cada membro da equipe, ajudando-o a reconhecer e tomar ações pró-ativas no trabalho que está sendo desenvolvido, para, por exemplo, obter mais contribuições.

A equipe como um todo também recebe mecanismos de percepção da ferramenta, permitindo destacar a participação colaborativa de cada participante, identificando quem está ativo durante a sessão, a data e hora da última alteração do objeto, bem como quem realizou esta modificação. Nos casos em que há votação, identifica-se quem já votou em uma proposta, e quem ainda não emitiu o seu voto, influenciando as decisões em prol do conhecimento que a ferramenta registra.

Para manter um acervo acessível e gerenciável o RECOLAB mantém um histórico da evolução de cada objeto, registrando todas as interações que este sofreu. Mantém ainda um registro de tudo que o usuário já conhece do desenvolvimento do trabalho, podendo apresentar todas as modificações ocorridas e que o usuário não conhece. Com este acervo é fácil também identificar quem conhece e quem não conhece as alterações dos objetos.

Construído para ser um canal de comunicação, o RECOLAB promove mecanismos de comunicação entre os participantes, materializadas em envio de mensagens, envio


379

de e-mail e geração de quadro de aviso, bem como a possibilidade de inserir questões, respondê-las, associar pontos positivos e negativos sobre qualquer objeto, expondo sua opinião e ainda a indicação de conflitos.

Para a comunicação indireta o RECOLAB implementou os seguintes elementos: Conflitos, propostas e votos, pontos positivos e pontos negativos, perguntas e respostas. Um ponto positivo é a indicação de satisfação ou aprovação que se deseja registrar, assim como o ponto negativo é a indicação de insatisfação ou desaprovação. Uma pergunta é a expressão de uma dúvida ou questionamentos, e uma resposta é a resolução daquela pergunta. Uma pergunta pode receber mais de uma resposta. Os conflitos podem ser considerados como qualquer situação de desentendimento ou divergência. O RECOLAB implementa três formas de resolução de conflitos: por decisão do patrocinador, por decisão do coordenador ou por votação da equipe. Quando a opção for pela votação, o resultado pode ser apurado através de uma maioria simples ou através de unanimidade. Para a resolução de um conflito é sempre necessária a criação de pelo menos uma proposta, que deve ser registrada.

4.2 A interface padrão

O RECOLAB possui uma interface padrão para as telas. Em geral, a tela é dividida em três frames, como mostra a Figura 3 (para melhor visualização dos frames, foram inseridas as linhas divisórias, que não aparecem quando se utiliza o RECOLAB).

Figura 3 - Interface padrão do RECOLAB

No frame superior pode-se visualizar o login ativo da sessão, a hora da última ação realizada e o menu do sistema. O menu, composto de ícones representando os objetos e as funcionalidades, possui dois níveis hierárquicos. No primeiro apresentam-se os objetos que se pode manipular: projeto, requisito, glossário, oportunidade, etc. No segundo, as ações possíveis sobre o objeto escolhido são disponibilizadas. Os menus são formatados de acordo com a fase do projeto e do perfil do usuário, ou seja, numa


380

fase podem aparecer objetos que não aparecem em outras, e para o coordenador aparecem funções diferentes do analista ou usuário. Ao selecionar o objeto no menu nível 1, o RECOLAB formata o nível 2 com as ações permitidas.

No frame da direita são fornecidas as seguintes informações: nome do projeto escolhido, o mesmo profissional pode trabalhar em mais de um projeto, a fase atual do projeto e os usuários ativos no momento (com uma indicação do seu perfil: C – Coordenador, P – Patrocinador, U – Usuário e A – Analista) e a quantidade de interações que dependem da ação do usuário, tais como: mensagens destinadas a ele, quadro de avisos não lidos, perguntas e conflitos não resolvidos.

O frame da esquerda é onde o usuário atua mais constantemente, é a área de trabalho em objetos. Neste frame há indicação do nome da tela e ao seu lado um espaço reservado para as mensagens que o sistema fornece ao usuário. São mensagens que indicam o sucesso da ação (iniciadas por S), erros encontrados (iniciadas por E) e avisos do sistema (iniciadas por A). É neste frame de trabalho que se registra a alteração em objetos, onde se descreve os requisitos, os problemas e oportunidades, redigem-se as perguntas e mensagens, registram-se conflitos e realizam-se votações. A Figura 4 ilustra a tela de criação e edição de um requisito.

Fig. 4. Tela de criação e edição de um requisito

Ainda no frame principal, para cada objeto o RECOLAB lista as pessoas que leram e as que não leram aquela versão. Quando a tela estiver relacionada à votação de uma proposta, o RECOLAB apresenta as pessoas que votaram na proposta, aquelas que não votaram na proposta e aquelas que ainda não se manifestaram sobre o conflito.

O RECOLAB procura manter uma percepção de autoria das partes das descrições através das cores de cada autor. Assim, sabe-se, ao visualizar a descrição, que pessoas contribuíram e onde contribuíram para melhor descrever o objeto. Esta forma de identificação de usuários através das cores também será utilizada nas seguintes partes do groupware: descrições de uma forma geral, usuários on-line, a lista de pessoas que leram ou não leram determinada versão do objeto, e a lista de votação.


381

5. O Estudo de Caso

O processo e a ferramenta propostos foram submetidos à avaliação através de um estudo de caso que reuniu nove voluntários. Nesta seção é apresentado um resumo. A descrição completa faz parte de uma dissertação de mestrado [6]. Todos são profissionais e possuem diferentes graus de experiência na atividade de levantamento de requisitos. Os principais objetivos do estudo de caso foram: 1. Identificar se o processo e a ferramenta propostos permitem o desenvolvimento da

atividade de levantamento de requisitos; 2. Identificar se o processo e a ferramenta propostos oferecem solução para que a

atividade de levantamento de requisitos produza requisitos menos ambíguos, mais completos, com menos indefinições, providos de consenso e priorizados. O cenário proposto para este estudo de caso foi o desenvolvimento de um projeto

para uma organização, que deseja ter um maior controle sobre sua frota de veículos, composta de 50 unidades. A organização possui um controle manual e tem freqüentes problemas com a falta de manutenção preventiva, custo elevado e atrasos de entrega.

O grupo de trabalho constituiu-se de profissionais que atuam em diferentes áreas, sendo distribuídos da seguinte forma em relação a sua principal ocupação: quatro desenvolvedores, um profissional da área de qualidade, três usuários de sistemas, um gerente de projeto. A cada profissional foi designado um perfil de acordo com sua experiência profissional. O grupo foi apresentado ao processo e a ferramenta em uma reunião, onde puderam também se conhecer um pouco mais.

A avaliação esperada está relacionada à percepção destes profissionais comparando esta experiência com métodos e técnicas usados anteriormente por eles. O resultado do estudo de caso foi analisado sob dois aspectos, a avaliação qualitativa, representada pelos comentários, críticas e sugestões destes profissionais, e a avaliação quantitativa, medida pelo grau de concordância sobre questões propostas no questionário de avaliação, e pelos resultados obtidos na execução do estudo de caso, tais como: número total de requisitos criados, número de requisitos selecionados, quantidade de interações, conflitos, e artefatos gerados.

5.1 Resultados do Estudo de caso

O estudo de caso realizado apresentou respostas satisfatórias aos dois objetivos principais a que se propôs: 1. Identificar se o processo e a ferramenta propostos permitem o desenvolvimento da

atividade de levantamento de requisitos; 2. Identificar se o processo e a ferramenta propostos oferecem solução para que a

atividade de levantamento de requisitos produza requisitos menos ambíguos, mais completos, com menos indefinições, providos de consenso e priorizados. Em relação ao primeiro objetivo, a resposta é positiva e comprovada pela execução

do início ao fim do processo apoiado pelo RECOLAB e que produziu um volume de artefatos considerável. Não há registro de incompatibilidades ou de impossibilidade do uso tanto do processo quanto da ferramenta, seja pelos comentários expostos ou pelas indicações feitas nos formulários de avaliação respondidos.


382

A análise dos resultados mostra uma produção considerável de requisitos e outros objetos, que a ferramenta permitiu manipular. Nota-se também que o processo de refinamento sucessivo funcionou, já que os objetos criados tiveram muitas atualizações. O nível de interação entre as pessoas também foi relevante. Foram gerados muitas mensagens, quadros de aviso, algumas perguntas e conflitos. Não houve envio de e-mails pela ferramenta, o que de certa forma, mostra o grau de confiança das pessoas em utilizar a ferramenta.

Os conflitos gerados também mostrou que através da ferramenta consegue-se registrar, propor alternativas e solucionar conflitos por meio de votação, mecanismo usado para resolução de conflitos neste projeto.

Em relação ao segundo objetivo, lançamos mão das avaliações dos questionários preenchidos pelos participantes do estudo de caso, onde se busca a percepção destes no uso do processo e da ferramenta. Da análise das respostas e dos comentários, há uma avaliação positiva do grupo de que o processo e a ferramenta efetivamente possibilitam a geração de requisitos menos ambíguos, mais completos, com menos indefinições, providos de consenso e priorizados.

Tanto pelas respostas obtidas nos questionários, quanto pelo volume de objetos criados e manipulados, observa-se um grau de satisfação pelo uso da solução, usados de forma integral com todos os pormenores. O resultado obtido confirma a hipótese de que um processo colaborativo, apoiado por um groupware, oferece mecanismos para resolver ou minimizar os problemas selecionados do levantamento de requisitos.

6. Discussão e Conclusões

Este trabalho descreveu o uso de um processo colaborativo, que estrutura as etapas da atividade de levantamento de requisitos, apoiado na colaboração e no trabalho em equipe. O processo proposto une os profissionais que detêm parte do conhecimento necessário à atividade de elicitar os requisitos. Com uma lógica voltada para a participação colaborativa, os requisitos são refinados sucessivamente durante o processo, possibilitando a geração de uma lista final de requisitos provida de consenso dos envolvidos. A construção de um groupware agilizou a atividade e permitiu flexibilizar as iniciativas de comunicação e acompanhamento das atividades, bem como proporcionou mecanismos de percepção eficientes para o trabalho em grupo.

Realizou-se um estudo de caso de avaliação do processo e da aplicação desenvolvida, que reuniu um grupo de profissionais para trabalhar no levantamento de requisitos em um cenário proposto. O resultado desta avaliação foi promissor, indicando um razoável nível de aceitação.

O trabalho apresentou algumas contribuições. A primeira contribuição percebida foi na ratificação do uso de um processo e de groupware para auxiliar a engenharia de software. Muitas etapas da engenharia de software são inerentemente colaborativas, e o uso de soluções de groupware explicita esta característica e promove uma interação mais amigável e gerenciável destas etapas do ciclo de desenvolvimento.

A aproximação proposta entre os diversos stakeholders e os engenheiros de requisitos, bem como a mudança na forma de atuar de cada um deles é outra contribuição, pois conduz a uma visão mais ativa e participativa do trabalho. O


383

trabalho contribuiu ainda para oferecer mecanismos que gerenciam melhor as mudanças futuras no sistema desenvolvido, uma vez que mantém registros sobre as decisões que foram tomadas para desenvolver os requisitos até sua descrição atual.

A principal limitação refere-se à avaliação. Realizou-se apenas um estudo de caso para avaliação da solução. Esta limitação gera uma análise restrita dos benefícios e riscos do processo, focalizando apenas um grupo de trabalho, com características próprias. O ideal seria ter outros casos de teste para avaliação e experimentos mais formais oferecendo um número maior de variáveis para as conclusões.

O processo e a ferramenta não aprofundam questões para resolução de conflitos e tomadas de decisão. Sabe-se que o processo de negociação e resolução de conflitos não se limita a uma votação ou a decisão de um ou outro representante do projeto. O que se propôs nesta versão foi criar mecanismos que auxiliassem na evidência dos conflitos, e uma forma de resolvê-los para que se tenha uma seqüência do projeto.

Referências

1. Araujo, R.M., Borges, M.R.S.: Extending the Software Process Culture – An Approach Based on Groupware and Workflow, 3rd International Conference on Product Focused Software Process Improvement, Kaiserslautern, Germany, LNCS Vol. 2188 (2001) 297–311

2. Baéz, M. G., Brunners, I. B.: Metodología DoRCU para la Ingeniería de Requerimientos, Workshop de Engenharia de Requisitos, Buenos Aires, Argentina (2001) 210–222

3. Brooks, F.: No Silver Bullet: Essence and Accidents to Software Engineering, IEEE Computer Vol 20 No. 4 (1987) 10–19

4. Christel, M. G., Kang, K. C.: Issues in Requirements Elicitation, Technical Report Software Engineering Institute CMU/SEI-92-TR-12.7, Disponível em: http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf. Acesso Mar 2005.

5. Cysneiros, L.M.: Requisitos Não Funcionais: Da elicitação ao Modelo Conceitual” Tese de Doutorado, Dept. de Informática PUC-Rio, 2001.

6. Freitas, D. P.: Ampliando a Colaboração no Levantamento de Requisitos de Sistemas, Dissertação de Mestrado, Programa de Pós-Graduação em Informática UFRJ, 2006.

7. Gottesdiener, E.: Requirements by Collaboration, Addison-Wesley, 2002. 8. Kassel, N. W., Malloy, B. A.: An approach to automate requirements elicitation, Anais da

7th IASTED International Conference, Software Engineering and Applications, Marina Del Rey, CA, USA (2003)

9. Leite, J. C. S. P.: Gerenciando a qualidade de software com base em requisitos, Qualidade de software: Teoria e Prática, cap. 17. A.R.C. Rocha, J.C. Maldonado, K. Weber (orgs), Prentice-Hall (2001)

10. Macaulay, L. A.: Seven-Layer Model of the Role of the Facilitator in Requirements Engineering, Springer Requirements Engineering Journal Vol 4 No. 1 (1999) 38–59

11. Martins, L.E.G., Daltrini, B.M.: An Approach to Software Requirements Elicitation Using Precepts from Activity Theory, 14th IEEE International Conference on Automated Software Engineering (1999) 15–23

12.Pressman, R.S.: Engenharia de Software, 5ª edição, McGraw Hill (2002) 13.Togneri D., Falbo R. A., Menezes C. S.: Supporting Cooperative Requirements Engineering

with an Automated Tool, Workshop de Engenharia de Requisitos (2002) 240–254 13.Toro, A.D., Jiménez, B. B., Cortés, A. R., Bonilla, M. T., A Requirements Elicitation

Approach Based in Templates and Patterns, . Workshop de Engenharia de Requisitos. Buenos Aires, Argentina, 1999.

14.Wiegers, K. E., Software Requirements, Microsoft Press, 1999.


384

Sesión 11 Servicios WEB y Componentes

385

Automated Generation of BPEL Adapters�

Antonio Brogi and Razvan Popescu

Computer Science Department, University of Pisa, Italy{brogi,popescu}@di.unipi.it

Abstract. The heterogeneous, dynamic, distributed, and evolving na-ture of Web services calls for adaptation techniques to overcome vari-ous types of mismatches that may occur among services developed bydifferent parties. In this paper we present a methodology for the auto-mated generation of (service) adapters capable of solving behaviouralmismatches among BPEL processes. The adaptation process, given twocommunicating BPEL processes whose interaction may lock, builds (ifpossible) a BPEL process that allows the two processes to successfully in-teroperate. A key ingredient of the adaptation methodology is the trans-formation of BPEL processes into YAWL workflows.

1 Introduction

BPEL [2] is currently used to (manually) compose WSDL [16] services into com-plex business applications. A main problem to achieve automated service compo-sition is that the composite application may lock due to interaction mismatchesamong the participant services. One possibility to overcome such mismatches isa disciplined use of adapters, as services “in-the-middle” capable of mediatingthe information exchanged by the involved parties.

Service adaptation may be tackled at various levels of the Web services stack[10]. For example, signature-based adaptation [9,12] addresses issues due to syn-tactic differences among the exchanged messages (e.g., different orderings of themessage parts), ontology-based adaptation [8,11] mediates semantic mismatchesamong the exchanged messages (e.g., messages belonging to different ontologyconcepts), and behaviour-based adaptation [1,3] handles the integration of ser-vices into a lock-free aggregate due to mismatches in their communicating pro-tocols (e.g., different orderings of message exchanges). However, Web serviceadaptation is in its early stages and current approaches feature only partialsolutions to the issues of adaptation.

Our long term objective is to develop a general methodology for serviceadaptation capable of suitably overcoming signature, ontology and behaviourmismatches in view of business application integration within and across or-ganisational boundaries. In this paper we present a methodology for the au-tomated generation of (service) adapters capable of solving behavioural mis-matches among BPEL processes. The adaptation process, given two communi-cating BPEL processes whose interaction may lock, builds (if possible) a BPEL� This work has been partially supported by the SMEPP project (EU-FP6-IST

0333563) and by the F.I.R.B. project TOCAI.IT.


387

process that allows the two processes to successfully interoperate. Three strongmotivations for adapting services are the need to develop adapters for servicecomposition, for ensuring backwards compatibility of new service versions, aswell as the need to develop adapters for each class of clients a service may have.A key ingredient of the adaptation methodology is the use of service contracts[6] including WSDL signatures and YAWL behaviour, where YAWL [13] is usedas intermediate (formal) language to provide a (partial) description of the ser-vice behaviour. Immediate advantages of using such an abstract language are thepossibility of adapting services written in different service description languages,multiple deployment of the adapter as a real-world service, as well as developingformal analyses and transformations independently of the different languagesused by providers to describe the behaviour of their services. Moreover, inte-gration with the YAWL-based service customisation [5] and aggregation of Webservices [4,6] becomes straightforward.

The rest of the paper is organised as follows. Section 2 overviews BPEL andYAWL. Following, Section 3 introduces a (simple) motivating example, whichwill be used to informally illustrate the adaptation methodology. In Section 4 wepresent the adaptation methodology. Related work and some concluding remarksare discussed in Section 5.

2 A Brief Introduction to BPEL and YAWL

The next two Subsections give a very high-level view of both languages. Someother details on the two languages will be discussed in the next Section, whiledescribing the adaptation methodology. For a complete description of the twolanguages, please see [2] for BPEL, and [13] for YAWL.

2.1 BPEL: Business Process Execution Language

BPEL is a language for expressing the behaviour of a business process. It en-ables the specification of control and data logic around a set of Web serviceinteractions. A BPEL process exposes a WSDL interface to its clients.

A BPEL process can be either abstract or executable. An abstract processhides implementation details (i.e., private information), while an executable pro-cess provides the full interaction behaviour.

BPEL defines the notion of partner link to model the interaction between abusiness process and its partners. A partner link refers to at most two WSDLport types, one of the interface to the business process (viz., operations offeredby the process to the partner), and the other of the interface of a partner (viz.,operations offered by the partner to the business process).

BPEL is a hybrid language that combines features from both the block-structured language XLANG and from the graph-based language WSFL. Theformer contributed with basic activities (e.g., for sending and receiving messages,for waiting for a period of time, and so on) as well as with structured ones(e.g., sequential or parallel execution of activities, activity scoping, and so on)


388

for combining activities into complex ones. The latter brought the definition oflinks to synchronise activities executed in parallel. Other features of BPEL areinstance management through correlation sets, event and fault handling, as wellas compensation capabilities.

The BPEL basic activities are: receive/reply through which a BPEL processinputs/sends a message from/to a partner service, invoke through which a BPELprocess asynchronously/synchronously invokes an operation of a partner service,wait for delaying the execution of the process, throw for signalling faults, termi-nate for explicitly terminating the execution of the process, a dummy empty fordoing a “no-op”, assign for copying values between variables, and compensatefor invoking a compensation handler.

The structured activities are: sequence, switch, and while for sequential, con-ditional and repeated activity execution, flow for parallel activity execution, pickfor managing the non-deterministic choice of the activity to be executed, andscope for providing an execution context for an activity.

2.2 YAWL: Yet Another Workflow Language

YAWL is a new proposal of a workflow/business processing system, which sup-ports a concise and powerful workflow language and handles complex data trans-formations and Web service integration. YAWL defines twenty most used work-flow patterns divided in six groups – basic control-flow, advanced branching andsynchronisation, structural, multiple instances, state-based, and cancellation. Athorough description of these patterns may be found in [14].

YAWL extends Petri nets (PNs) by introducing some workflow patterns (formultiple instances, complex synchronisations, and cancellation) that are not easyto express using (high-level) PNs. Being built on PNs, YAWL is an easy to un-derstand and to use formalism, which features an intuitive (graphical) represen-tation of services. Moreover, it can benefit from the abundance of PN analysistechniques. With respect to the other workflow languages (mostly proposed byindustry), YAWL relies on a well-defined formal semantics based on transitionsystems. Moreover, not being a commercial language, YAWL supporting tools(editor, engine) are freely available.

From a control-flow perspective, a YAWL file describes a workflow specifica-tion that consists of a tree-like structure of extended workflow nets (or EWF-netsfor short). An EWF-net is a graph where nodes are tasks or conditions, and edgesdefine the control-flow relation. Each EWF-net has a single input condition anda single output condition.

Tasks employ one join and one split construct, which may be one of thefollowing: AND, OR, XOR, or EMPTY. Intuitively, the join of a task T specifies“how many” tasks before T are to be terminated in order to execute T, whilethe split construct specifies “how many” tasks following T are to be executed.

It is worth noting that YAWL tasks may be interpreted as PN transitions,and YAWL conditions can be represented as PN places. The control-flow fortasks with XOR/OR splits is managed through predicates in the form of logicalexpressions. When a task finishes its execution, it places tokens in its output


389

places, depending on its split type. Dually, a task is enabled for execution de-pending on its join and on the tokens available in its input places.

Another feature of YAWL is the use of cancellation sets consisting of condi-tions and tasks. When a task is executed all tokens from its cancellation set (ifany) are removed.

From a data-flow perspective, YAWL uses XMLSchema, XPath and XQueryfor dealing with data. Variables are defined at both EWF-net and task levels,and bindings between them are realised through XQuery expressions.

3 Motivating Example

Consider the following example consisting of two interacting BPEL processes:Command Centre (CC) and Mars Explorer (ME). The former provides a Webservice interface for the assignment of exploration tasks. The latter is a Webservice interface to the robot performing the tasks. Hereafter we present a sim-plification of the BPEL processes (e.g., in order to express the message exchangeswe simply use service names instead of partnerLinks and portTypes). Althoughfairly simple, the example illustrates various interactions among services. Onthe one hand, CC communicates with its client, as well as with the ME service.On the other hand, ME interacts with CC (viz., its client), as well as with theLogger and Explorer services.<process name=“CommandCentre”><sequence>

<receive op=“ExecTask” from Client var=“taskInfo” createInst=“yes”/><invoke op=“Login” of MarsExplorer var=“loginInfo”/><assign><copy> from=“/taskInfo/coords” to=“coords”</copy></assign><invoke op=“SetCoords” of MarsExplorer var=“coords”/><assign><copy> from=“/taskInfo/job” to=“jobDetails”</copy></assign><invoke op=“SetJob” of MarsExplorer var=“jobDetails”/><pick>

<onMsg op=“SubmitRep” from MarsExplorer var=“report”><sequence><receive op=“JobID” from MarsExplorer var=“id”/><invoke op=“Logout” of MarsExplorer/><reply op=“ExecTask” of Client var=“report”/></sequence></onMsg>

<onMsg op=“SubmitErr” from MarsExplorer var=“error”><sequence><invoke op=“Logout” of MarsExplorer/><assign><copy> from=“error” to=“report”</copy></assign><reply op=“ExecTask” of Client var=“report” faultName=“Task Error”/>

</sequence></onMsg></pick></sequence></process>

The CC service1 first receives the task information from its client. It then logsin with the ME, to which it forwards the location and the job details. It waitsnext either a report or an error message from the ME. In the former case, it firstreceives the job id from the ME, then it closes the connection with the ME, andfinally, it forwards the report to the client. In the latter case, it first logs outfrom the ME, and then it replies to the client with the error message.<process name=“MarsExplorer”><sequence>

<receive op=“Login” from CommandCentre var=“loginInfo” createInst=“yes”/><invoke op=“JobID” of CommandCentre var=“id”/><receive op=“SetJob” from CommandCentre var=“jobDetails”/><receive op=“SetCoords” from CommandCentre var=“coords”/><invoke op=“ValidateLocation” of LoggerService inVar=“coords” outVar=“rep1”/><invoke op=“Explore” of ExplorerService inVar=“jobDetails” outVar=“rep2”/><assign><copy> from=“concat(rep1,rep2)” to=“report”</copy></assign><invoke op=“SubmitRep” of CommandCentre var=“report”/>

1 We use “process” and “service” interchangeably to denote BPEL processes.


390

<receive op=“Logout” from CommandCentre/></sequence><faultHandlers>

<catch faultName=“Task Error” faultVar=“error”><sequence><invoke op=“SubmitErr” of CommandCentre var=“error”/><receive op=“Logout” from CommandCentre/>

</sequence></catch></faultHandlers></process>

The ME service starts by waiting for the CC to log in, to which it sends im-mediately the job’s id. It receives next from the CC the job description and thelocation of the exploration site. In order to carry out the task, the ME first vali-dates the coordinates (e.g., by checking previous exploration logs) and moves therobot to the respective location by (synchronously) invoking the Logger Service(LS), and then, it delegates the Explorer Service (ES) for the actual execution ofthe job (again, through a synchronous invocation). If the latter two invocationsreturn successfully, the ME generates the final report, sends it to the CC, andwaits for the CC to log out. Note that, although not represented in the exam-ple, the invocations to the LS and to the ES may return a “Task Error” fault.(This information has to be specified in the WSDL file(s) defining the respectiveoperations). In that case, the ME service catches the fault, forwards to the CCthe error, and finally, it waits for the CC to close the connection.

It is easy to see that the two services, CC and ME, cannot successfullyinteract because of mismatches between their behaviour. Immediately after thelogin information exchange, while the CC sends the location of the explorationsite to the ME, the ME sends the job id to the CC. Furthermore, the CC firstsends the location, and then the details of the job to the ME, which expectsthem in the reversed order. A further mismatch is the fact that, while the CCexpects the job id only when the exploration is successful, the ME always sendsit, and moreover, at a different moment.

The following Section 4 shows how we automatically generate BPEL adaptersto cope with such behabioural mismatches.

4 Adaptation Methodology

The adaptation methodology inputs two communicating BPEL processes, Cand S, whose interaction may lock, and it builds (if possible) a BPEL processadapter A, which allows the two processes to successfully interoperate. The fouradaptation phases are: (1.) Service Translation. This phase is in charge oftranslating the BPEL descriptions of C and S into corresponding YAWL work-flows [7]. (2.) Adapter Generation. This phase builds the YAWL workflow ofA from the workflows of C and S. It first generates the Service Execution Trees(SETs) of C with respect to S (SET (CS)), as well as of S with respect to C(SET (SC)), followed by the generation of the SETs of their duals (SET (CS)and SET (SC)). Informally, when a service X outputs a message m, a dual ofX is a service that inputs m, and vice-versa. Next, SET (A) is obtained bysuitably merging SET (CS) and SET (SC). Finally, the YAWL workflow of Ais derived from SET (A). (3.) Lock Analysis. This phase verifies whether theYAWL-based aggregation [4,6] of C, A, and S locks. If it does, we consider thatthe adaptation has failed. Otherwise, we consider that the adaptation is suc-cessful. (4.) Adapter Deployment. If the adaptation is successful, this phase


391

deploys the YAWL workflow of A as a BPEL process, which can be used as aservice-in-the-middle between C and S.

4.1 Service Translation

In [7] we present a methodology for translating BPEL processes into YAWLworkflows. Its main strengths are that (1) it defines YAWL patterns for allBPEL activities, (2) it provides a compositional approach to construct structuredpatterns from suitably interconnecting other patterns, and (3) it handles events,faults and (explicit) compensation.

On the one hand, the pattern of each BPEL basic activity (with the excep-tion of assign and compensate) is obtained by suitably instantiating the BasicPattern Template (BPT). The BPT is a template of YAWL tasks, which servesboth for identifying the translated activity (through an Activity Specific Task,or AST for short), as well as the control-logic of executing or skipping the activ-ity. On the other hand, the pattern of each BPEL structured activity (togetherwith assign, compensate, and process) is obtained from the Structured PatternTemplate (SPT) template. The SPT consists of a Begin (logically marking theinitiation of the structured activity) and of an End pattern (logically markingthe termination of the structured activity), as well as a pattern template (BPTor SPT) for each child activity. Furthermore, the Scope and Process patterns addSPTs for handling exceptional behaviour. Each pattern inputs and outputs atmost three types of control-flow links, called green, blue, and red lines. The greenlines serve for translating the structural dependencies among BPEL activities.The blue lines are used for translating the BPEL synchronisation links, and thered lines are necessary for implementing the fault handling mechanism. As spacelimitations do not allow us to go into further details, please see [7] for more(in-depth) details on the BPEL2YAWL translator.

The YAWL workflows of the CC and ME services of our example can beseen in Figure 1.2 In the workflow of ME, Begin(Process) and End(Process),logically mark the initiation and the termination, respectively, of the BPEL pro-cess. The process activity, a sequence leads to generating the Begin(Sequence) aswell as the End(Sequence) tasks. The first activity in the sequence is a receive,which gives the Receive task. Furthermore, the rest of the activities are trans-lated correspondingly. (The numbers inside some of the task labels are used fordisambiguation purposes only.) Note however the translation of the BPEL pick.The Begin(Pick) task contains the branch selection logic (basically a deferredchoice construct [13]), and it outputs two tokens3. One leads to executing thechosen branch, while the second leads to skipping the other branch (so as toachieve the dead-path-elimination).

The workflow of CC is built in a similar manner. However, the compos-ite tasks representing the invoke ValidateLocation and invoke Explore activities

2 The two workflows are represented in a slightly simplified form w.r.t. the descriptiongiven in [7] (e.g., the default faultHandlers of the process, as well as redundant greengates are not represented, the assign is represented in a compact form, etc.).

3 The semantics of executing YAWL workflows is quite similar to executing PNs.


392

ME_YAWL

CC_YAWL LEGEND

Begin (Proc.)

Begin (Seq.)

receive ExecTask

invoke Login

assign (coords)

assign (jobDetails)

invoke SetCoords

invoke SetJob

Begin (Pick)

Begin (Seq.)

receive JobId

invoke Logout (1)

reply ExecTask (1)

End (Seq.)

Begin (Seq.)

invoke Logout (2)

assign (report)

reply ExecTask (2)

End (Seq.)

End (Pick)

End (Seq.)

End (Proc.)

InitonMsg SubmitRep

Wait 4 branch decisiononMsg SubmitErr

Begin(Pick)

Empty-join/split

XOR-join / AND-split

AND-join / XOR-split

input cond.output cond.

Atomic Task

OR-join / OR-split

cond.

Tasks and Conditions

Composite Task

Begin (Seq.)

receive Login

invoke JobId

receive SetCoords

receive SetJob

assign (report)

invoke SubmitRep.

receive Logout (1)

End (Seq.)

End (Proc.)

Begin (FaultHandler)

Red Gate 1

Red Gate 2

Begin (Proc.)

Begin (Seq.)

invoke SubmitErr

receive Logout (2)

End (FaultHandler)

Invoke ValidateLoc.

invoke Explore

!fault

!faul

t

fault

green linered line

Control-Flow

Joins and Splitsfault

Fig. 1. YAWL workflows corresponding to the CC and ME BPEL processes.

output either green tokens, if the invocations succeed, or red tokens, if the in-vocations fail (i.e., faults are being raised). In the former case, the execution ofthe workflow continues normally, and the green output of End(Sequence) leadsto skipping the tasks inside the Begin(FaultHandler) → End(FaultHandler) zone(so as to achieve the dead-path-elimination). In the latter case, the execution ofthe faulty invocation is (immediately) followed by the execution of the tasks inthe fault handling zone.

4.2 Adapter Generation

The Adapter Generation phase consists of the four steps discussed hereafter.

Service Execution Trees. This step automatically generates the Service Ex-ecution Trees (SETs) of the two services to be adapted. The SET of a BPELprocess X is a tree describing all the possible scenarios of executing the basic ac-tivities (or activities, for short) of X . Informally, the root of the SET is given bythe activity (or activities) that can be executed first, while the leaves correspondto activities executed last. Each intermediary node represents the execution ofone or more activities. A node consisting of more than one activity denotes aconcurrent execution of the respective activities. Given a node n, child nodesof n contain (distinct sets of) activities that can be executed immediately afterexecuting the activities of n. Hence, one may think of each path in the tree asa service execution trace. We generate the SET of a BPEL process X througha reachability analysis [4] of its corresponding YAWL workflow obtained duringthe Service Translation phase. Note that the BPEL2YAWL translator [7] allowsus to cope – when adapting – both with synchronisation links and with the ex-ceptional behaviour of BPEL. In order to cope with loops in the process, ourreachability analysis uses the modified reachability trees defined in [15]. Further-more, each node of the SET can be labelled with a condition constraining itsexecution. Such conditions are due to guards employed by switch activities andsynchronisation links. In [4,5] we show how to generate the logical expression


393

SET(MECC)SET(ME*CC) SET(CCME)SET(ME)rcv Login

inv JobId

rcv SetJob

rcv SetCoords.

inv ValidateLoc.

inv SubmitErr. inv Explore.

rcv Logout (2) inv SubmitErr.

rcv Logout (2)

assign(report)

inv SubmitRep.

rcv Logout (1)

inv SubmitErr.

rcv Logout

rcv Login

inv JobId

rcv SetJob

rcv SetCoords.

empty

inv SubmitErr. empty

rcv Logout (2) inv SubmitErr.

rcv Logout (2)

empty

inv SubmitRep.

rcv Logout (1)

inv SubmitErr.

rcv Logout

rcv Login

inv JobId

rcv SetJob

rcv SetCoords.

inv SubmitErr.

rcv Logout (2)

inv SubmitRep.

rcv Logout (1)

LEGEND

activity executed

activity skipped

(a) (b)

(c)

inv Login

inv SetCoords.

inv SetJob

rcv SubmitRep. rcv SubmitErr.

rcv JobId

inv Logout (1)

inv Logout (2)

(d)

activity executed

activity skipped

Fig. 2. (a) SET (ME), (b) SET (ME∗CC), (c) SET (MECC), and (d)

SET (CCME).

constraining the fulfilment of a service execution trace. However, in order toease the description of the methodology, and due to space limitations, we do notdetail this issue here. The SET one obtains for a service X contains all messageexchanges of X with other services. We call this the full-form of the SET, andwe denote it by SET (X). SET (ME) is given in Figure 2(a). For example, theexecution of the (synchronous) invoke ValidateLocation can be followed eitherby the invoke Explore, or by the invoke SubmitErr. The former is due to a suc-cessful execution of the invoke ValidateLocation, while the latter is executed inthe case of a fault being received by the invoke ValidateLocation. Furthermore,the successful termination of the sequence activity of the BPEL process leads toemploying the dead-path-elimination inside the pattern implementing the fault-Handler of the BPEL process [7]. This is indicated in SET (ME) by the darkcoloured invoke SubmitErr and rcv Logout nodes.

From (the full-form of) SET (X) we derive next the (compact-form of) SETof X with respect to another service Y , with which X interacts. We denote itby SET (XY ). Informally, from the original SET (X) we keep only message ex-changes between X and Y . First, all message exchanges (viz., receive/reply/invoke)of X with services other than Y , as well as all other basic activities (e.g., as-sign), and all skipped activities are replaced by empty activities. We denote theresulting SET as SET (X∗

Y ). For example, the invoke ValidateLocation and theinvoke Explore, which ME performs on the Logger Service and Explorer Service,respectively, are set to empty when computing SET (ME∗

CC). (SET (ME∗CC) is

given in Figure 2(b).) Second, each empty node in SET (X∗Y ) (with the excep-

tion of the root) is removed from the tree, and its sub-trees (if any) are mergedwith its parent nodes. We denote the resulting tree by SET (XY ). Note that themerge process applied at a node n of SET (X∗

Y ) also removes duplicate subtreesof n. For instance, by removing the three empty nodes of SET (ME∗

CC), we gettwo identical subtrees (invoke SubmitErr → receive Logout) at the receive Set-Coords node. The merge at receive SetCoords will then remove one duplicate.SET (MECC) is represented in Figure 2(c). Due to space limitations, we presentonly the SET (CCME) – which is built analogously – in Figure 2(d).


394

Dual SETs. This step generates for each service X (to be adapted), the SETof a dual of X with respect to another service Y . Basically, when X receivesa message m from Y , a dual of X with respect to Y (denoted by SET (XY ))acts somewhat “as Y should” and sends a message m to X , and vice-versa.One obtains SET (XY ) from SET (XY ) by replacing asynchronous invokes withreceives (and vice-versa), and synchronous invokes with pairs receive → reply(and vice-versa). SET (MECC) and SET (CCME) are depicted in Figure 3(a)and (b), respectively.

Adapter SET. The SET of an adapter A (SET (A)) mediating the interac-tion of two services, C and S, is obtained by suitably merging SET (CS) withSET (SC). This process consists of two steps, as follows.

During the first step, we match the activities of SET (CS) with the activ-ities of SET (SC) with the following two rules: (1) An asynchronous invokeOp of SET (CS) matches a receive Op of SET (SC), and vice-versa, and (2)a synchronous invoke Op of SET (CS) matches a pair receive Op → reply Op ofSET (SC), and vice-versa. Then, we express each match as a data-flow depen-dency (or dependency, for short), which emerges at the receive and targets theinvoke, in the case of asynchronous message exchanges, or as a pair of depen-dencies, one emerging at the receive and targeting the invoke, and another oneemerging at the invoke and targeting the reply, in the case of synchronous mes-sage exchanges. We call an activity that is target of at least one dependency asconstrained. Otherwise, we say that the activity is unconstrained (with respectto the data-flow dependencies between the two SETs). For example, invoke Lo-gin and receive JobId of SET (MECC) match receive Login and invoke JobId,respectively, of SET (CCME). (See Figure 3(a) and (b).) Informally, a depen-dency indicates that the adapter has to wait first a message from one of thetwo services, and then (possibly at a later moment) it forwards it to the otherservice. In other words, a dependency from X to Y says that the adapter has toexecute X before executing Y . Note that the interpretation in the case of multi-ple dependencies emerging from different activities Xk and targeting an activityY , is that for the execution of Y it suffices to execute only one activity Xk. Thisis the case for invoke Logout (1) and invoke Logout (2) of SET (MECC).

As previously mentioned, each path in SET (X) is an execution trace of X .During the second step, we compute the merge of all possible pairs of traces (c, s),where c =< c1, c2, . . . , cn > is a trace of SET (CS), and s =< s1, s2, . . . , sm > isa trace of SET (SC). Such a merge can lead either to a success, or to a failure. Inthe former case, the merge of c and s gives a (successful) trace a of the adapter A(and consequently a path in SET (A)). At each step, the merge process comparesnodes

ci andsj , by starting from the roots of the two traces, and it produces a

node ak. In terms of BPEL activities, one may think of the node ak as a sequencecontaining a flow. The merge algorithm basically adds activities of the two nodes(ci and

sj) either inside the flow, or inside the sequence yet following the flow.For simplicity, we informally describe hereafter the algorithm of merging twonodes containing each one activity only, and each being the target of at mostone dependency. (The general case of merging nodes with multiple activities


395

Merge Example

SET(A)

(a) (b)(1) (2) (3) (4)

(1) + (3) => SUCCESS (5)

(1) + (4) => ERROR

(2) + (3) => ERROR

(2) + (4) => SUCCESS (6)

rcv Logininv Login rcv Login

inv Login

rcv Login

inv Login

(c)

SET(CCME)rcv Login

rcv SetCoords.

rcv SetJob

inv SubmitRep. inv SubmitErr.

inv JobId

rcv Logout (1)

rcv Logout (2)

SET(MECC)inv Login

rcv JobId

inv SetJob

inv SetCoords.

rcv SubmitErr.

inv Logout (2)

rcv SubmitRep.

inv Logout (1)

LEGEND

data-flow dependency

activities executed in parallel

(5)

(d)

(6)

rcv Login

inv Login

andrcv SetCoords. rcv JobId

rcv SetJob

inv SetJob

inv SetCoords.

inv SubmitRep. inv SubmitErr.

rcv SubmitErr.rcv SubmitRep.

inv JobId

rcv Logout (1)

inv Logout (1)

rcv Logout (2)

inv Logout (1)

Fig. 3. (a) SET (MECC), (b) SET (CCME), (c) Generating SET (A) nodes, (d)SET (A).

and multiple constraints is analogous.) If ci is unconstrained, then add ci to theflow inside ak (e.g., merging receive JobId and receive SetCoords). Please notethat in the case of an unconstrained invoke activity, the merge process (of thetwo traces) returns with a failure. We do so in order to avoid the generationof (arbitrary) messages by the adapter. Otherwise, if ci is constrained by sJ

such that J < j (i.e., from the point of view of executing the trace s, activityof sJ has already been executed), then add ci to the flow (e.g., merging invokeSetCoords and invoke SubmitRep). Otherwise, if ci is constrained by sJ such thatJ = j (i.e., activity of sJ is ready to be executed), then add ci to the sequence,following the flow (e.g., merging invoke Login and receive Login). Otherwise, ifci is constrained by sJ such that j < J (i.e., activity of sJ is not executable yet),then we say that the trace c is “stalled” (e.g., assume merging invoke SetJob andreceive SetCoords). Next, the algorithm does the same for sj. For example, onemay see in Figure 3(c) the result of merging the roots of MECC , and CCME .(The elimination of the flow is due to the fact that it contains one activityonly.) If both traces are stalled, then we have a lock between the two traces, andhence a failure in merging the two traces. Otherwise, the algorithm continues bycomparing the node ci (if c is stalled) or ci+1 (if c is not stalled) with the nodesj (if s is stalled) or sj+1 (if s is not stalled). If the merge has added to the tracea all nodes of one of the two traces (c/s), it simply appends at the end of a theremaining sequence of nodes of the other trace (s/c). If all nodes of both c ands have been added to a, then we have a success, and a represents a (successful)trace of the adapter A.

Next, we derive SET (A) by merging all successful traces a of A. If no suchsuccessful traces exist, then the algorithm generating the adapter fails, as themismatches between the two interacting processes cannot be solved. For example,if the root of SET (CS) consists of an invoke Op1 and if the root of SET (SC)consists of another invoke Op2, then we have a deadlock as each service is waitingto receive a message from the other. Consider a set {a1, a2, . . . , ap} of successfuladapter traces. The merge algorithm, in this case, starts by considering SET (A)to be a1. Then, for all nodes ak

i of the other traces ak, it checks whether aki


396

is contained in SET (A) at depth i. If so, it marks the respective position inthe tree, and it choses the next node in the sequence (i.e., ak

i+1). Otherwise, itadds the rest of the trace ak, including the node ak

i , as a branch splitting fromthe last marked node in SET (A). For our example, we get only two successfultraces of the adapter. The first one, denoted by (5) in Figure 3(d) is obtained bymerging the traces denoted by (1) and (3) of SET (MECC) and SET (CCME),respectively, while the second one, denoted by (6) is obtained by merging tracesdenoted by (2) and (4). These two adapter traces are then merged into theadapter given in Figure 3(d).

Adapter Workflow. If the adapter has at least one successful trace, then theadaptation process generates next the YAWL workflow of the adapter A fromSET (A) as described hereafter. Initially, it generates the Begin(Process) and theBegin(Sequence), as well as the End(Sequence) and the End(Process) patterns[7], which logically mark the initiation of the business process and of its activity,as well as their termination, respectively. The former two, as well as the last twoare to be linked in a sequence. (See Figure 4.) Basically, generating the patternof a basic activity simply consists of instantiating the Basic Pattern Templatedefined in [7] (e.g., setting the name, inputs, and outputs of its Activity SpecificTask), while generating the pattern of a structured one reduces to instantiatingits Begin and its End patterns, and the pattern of each child activity (, as well asthe patterns for handling the exceptional behaviour, if any). For each node n inSET (A), starting with its root, the algorithm generates and adds to the workflowthe pattern(s) corresponding to the activity (activities) contained in n. If nconsists of one activity only, then the pattern of its (basic) activity is producedand suitably linked in the workflow as output of the pattern corresponding tothe parent node of n (or to Begin(Sequence) if n is the root). For example,the receive Login root of SET (A) leads to a Receive pattern linked as output ofBegin(Sequence). If n consists of multiple activities, then the pattern given by thenode is a Flow, which includes the patterns of each activity in the node. Next,if n has one child node only, the adaptation process continues with its child.Otherwise, if n has more than one successor, then we have three possibilities: (1)If all child nodes of n contain each one receive only, and if there are no conditionsconstraining their execution4 then the resulting pattern is a Pick having therespective receives as onMessage tasks in Begin(Pick), and for each branch isgenerated a Sequence pattern. The generation process continues then on eachsubtree having as root a child of n (excluding the child of n already considered asonMessage inside the Pick). (2) If all child nodes of n are constrained by (disjoint)conditions, then a Switch pattern is produced with the respective conditions asguards, and for each branch of the Switch, a Sequence pattern is generated. Thealgorithm continues next on each branch of the subtree with the root n. (3) In allother cases, the adaptation process aborts, as the adapter cannot be successfullyconstructed due to a non-deterministic (other than pick) behaviour. For example,

4 We recall that such conditions are due to the guards of switch activities and syn-chronisation links.


397

Adapter for CC and ME

Begin (Proc.)

Begin (Seq.)

invoke Login

receive Login

Begin (Flow)

receive SetCoords

receive JobId

End (Flow)

receive SetJob

invoke SetJob

invoke SetCoords

Begin (Pick)

Begin (Seq.)

Begin (Seq.)

invoke SubmitRep.

invoke SubmitErr

invoke JobId

receive Logout (2)

invoke Logout

receive Logout (1)

invoke LogoutEnd

(Pick)End

(Seq.)End

(Proc.) End (Seq.)

End (Seq.)

InitonMsg SubmitRep

Wait 4 branch decisiononMsg SubmitErr

Begin(Pick)

Fig. 4. YAWL workflow of an adapter for CC and ME.

if n has two unconstrained children, one invoke Op1 and one receive Op2, thenthe adapter cannot “know” whether it should wait for a message, or whetherit should send a message. The YAWL adapter one obtains for our example ispresented in Figure 4.

4.3 Lock Analysis

In [4] we show how reachability graphs (or modified reachability trees) can beemployed to check the lock-freedom of aggregations of YAWL workflows (e.g., anon-final node of the reachability graph/tree without outgoing links correspondsto a deadlock). Hence, through this methodology one may check whether theaggregation [4,6] of the workflows of C, A, and S locks. If all traces of theaggregate are lock-free, then A is a full adapter for C and S. Otherwise, ifsome (yet not all) of the traces of the aggregate are lock-free, then A is a partialadapter, as there are interaction scenarios that cannot be resolved. Finally, if theaggregate does not have lock-free traces, then we consider that the adaptationhas failed. (Although space limitations do not allow us to demonstrate it, notethat the adapter for CC and ME given in Figure 4 is a full adapter.)

4.4 Adapter Deployment

If the Lock Analysis phase has validated A as a full/partial adapter, then theAdapter Deployment phase generates the BPEL process of the adapter A fromits YAWL workflow. The deployment process works by parsing the YAWL work-flow with respect to the patterns defined in our BPEL2YAWL translator [7]. Forexample, the Pick pattern in Figure 4 leads to the generation of a BPEL pickwith two branches guarded by onMessage SubmitRep, and onMessage SubmitErr,where each branch activity is a sequence. Although not explicitly represented inthe figures, the YAWL patterns translating BPEL activities contain all the nec-essary information for the inverse, YAWL2BPEL translator (e.g., partnerLink,portType, operation, and variable attributes in the case of a receive, and so on).The YAWL workflow of the adapter in Figure 4, leads to the following BPEL(adapter) process:<process name=“Adapter for CC and ME”><sequence>

<receive op=“Login” from CommandCentre var=“loginInfo”/><invoke op=“Login” of MarsExplorer var=“loginInfo”/><flow>


398

<receive op=“SetCoords” from CommandCentre var=“coords”/><receive op=“JobID” from MarsExplorer var=“id”/></flow>

<receive op=“SetJob” from CommandCentre var=“jobDetails”/><invoke op=“SetJob” of MarsExplorer var=“jobDetails”/><invoke op=“SetCoords” of MarsExplorer var=“coords”/><pick>

<onMsg op=“SubmitRep” from MarsExplorer var=“report”><sequence><invoke op=“SubmitRep” of CommandCentre var=“report”><invoke op=“JobID” of CommandCentre var=“id”/><receive op=“Logout” from CommandCentre/><invoke op=“Logout” of MarsExplorer/></sequence></onMsg>

<onMsg op=“SubmitErr” from MarsExplorer var=“error”><sequence><invoke op=“SubmitErr” of CommandCentre var=“error”><receive op=“Logout” from CommandCentre/><invoke op=“Logout” of MarsExplorer/>

</sequence></onMsg></pick></sequence></process>

5 Concluding Remarks

In this paper we have outlined a methodology for the automated generationof (service) adapters capable of solving behavioural mismatches between BPELprocesses. Its main features are: (1) It automatically synthesises a full/partialBPEL adapter (if possible) from two input BPEL processes, (2) it generates theYAWL workflow of the adapter, which can be used to check properties (e.g., lock-freedom, reachability, liveness, and so on) of the interaction with the adaptedservices, as well as (3) it can be straightforward integrated with the ontology-enriched service customisation [5] and service aggregation [4,6] approaches, asall use service contracts with YAWL as intermediate language to represent theservice behaviour.

Web service adaptation is in its early stages and current approaches fea-ture only partial solutions to the issues of adaptation. Iyer et al. [9] employXML scripts and XSL to (manually) achieve the signature-level interoperabilityof SOAP services. Syu [12] describes an OWL-S based approach to deal withonly three cases of adaptation of input parameters: permutation, modification,and combination. Hau et al. [8] provide a framework for semantic matchmakingand service adaptation, which deals with signature mismatches, yet not withbehavioural ones. Ponnekanti and Fox [11] propose a framework for coping withstructural, value, encoding, and semantic incompatibilities among services. Yet,their approach – as [8,9,12] – relies on black-box (viz., behaviour-less) viewsof services. A methodology for generating service adapters to solve behaviouralmismatches was presented by Brogi et al. in [3], yet it assumes the availabil-ity of an adapter specification to be manually generated. Benatallah et al. [1]describe an approach for the generation of replaceability adapters based on mis-match patterns. However, their approach cannot capture complex behaviouralmismatches (through pattern compositions), and the generation of the adaptercode relies on the designer (e.g., the provision of the template parameters).

It is worth noting that our adaptation methodology can be successfully em-ployed to generate replaceability adapters, viz., adapters that wrap Web servicesso that they become compliant with other services (e.g., wrapping new serviceversions for backwards compatibility). Given two services, S and S∗, wrappingS∗ so as to behave like S with respect to clients C can be achieved by comput-ing SET (A) as the merge of SET (SC) and SET (S∗

C). Furthermore, behavioural


399

service customisation, viz., the generation of adapters that wrap services S∗ intoexposing to clients C a partial behaviour S, can be achieved again by computingSET (A) as the merge of SET (SC) and SET (S∗

C).Two main lines of future work are the development of adapters capable of

solving behavioural mismatches among several interacting BPEL processes, aswell as enhancing the adaptation methodology to cope with ontology mismatchesalong the lines of [4,5].

References

1. B. Benatallah, F. Casati, D. Grigori, H. R. M. Nezhad, and F. Toumani. DevelopingAdapters for Web Services Integration. In Proc. of CAiSE, LNCS vol. 3520, pages415–429, 2005.

2. BPEL4WS Coalition. Business Process Execution Language for Web Services v1.1.3. A. Brogi, C. Canal, E. Pimentel, and A. Vallecillo. Formalizing Web Service Chore-

ographies. In Proc. of WS-FM’04, ENTCS 105, pages 73–94, 2004.4. A. Brogi and R. Popescu. Contract-based Service Aggregation. Technical Report,

University of Pisa, Sep. 2006. (http://www.di.unipi.it/∼popescu/CoSA.pdf).5. A. Brogi and R. Popescu. Service Adaptation through Trace Inspection. In Proc.

of SOBPI’05, pages 44–58, 2005.6. A. Brogi and R. Popescu. Towards Semi-automated Workflow-Based Aggregation

of Web Services. In Proc. of ICSOC’05, LNCS vol. 3826, pages 214–227, 2005.7. A. Brogi and R. Popescu. From BPEL Processes to YAWL Workflows. In Proc.

of WS-FM’06, LNCS vol. 4184, pages 107–122, 2006.8. J. Hau, W. Lee, and S. Newhouse. The ICENI Semantic Service

Adaptation Framework. In UK e-Science All Hands Meeting, 2003.(http://www.nesc.ac.uk/events/ahm2003/AHMCD/pdf/017.pdf).

9. A. Iyer, G. Smith, P. Roe, and J. Pobar. An Exam-ple of Web Service Adaptation to Support B2B Integration.(http://ausweb.scu.edu.au/aw02/papers/refereed/smith2/paper.html).

10. M. P. Papazoglou and D. Georgakopoulos. Service-Oriented Computing. Commu-nications of the ACM, 46(10):24–28, 2003.

11. S. R. Ponnekanti and A. Fox. Interoperability among independently evolving webservices. In Proc. of the 5th ACM Int. Conf. on Middleware, pages 331–351, 2004.

12. J.-Y. Syu. An Ontology-Based Approach to Automatic Adaptation of Web Ser-vices. Department of Information Management National Taiwan University, 2004.(http://www.im.ntu.edu.tw/IM/Theses/r92/R91725051.pdf).

13. W. M. P. van der Aalst and A. H. M. ter Hofstede. YAWL: Yet Another WorkflowLanguage. Inf. Syst., 30(4):245–275, 2005.

14. W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski, and A. P. Barros.Workflow Patterns. Distrib. Parallel Databases, 14(1):5–51, 2003.

15. F.-Y. Wang, Y. Gao, and M. Zhou. A Modified Reachability Tree Approach toAnalysis of Unbounded Petri Nets. IEEE Transactions on Systems, Man andCybernetics – Part B, 34(1):303–308, 2004.

16. WSDL Coalition. Web Service Description Language (WSDL) v1.1.


400

Un Enfoque Dirigido por Modelos para el Desarrollo

de Servicios Web Semánticos

César J. Acuña1, Esperanza Marcos1 y Mariano Minoli1

1 Grupo de Investigación Kybele

Universidad Rey Juan Carlos

C/Tulipán S/N, 28933, Móstoles, Madrid, España e-mail: {cesar.acuna, esperanza.marcos}@urjc.es, maria-

[email protected] web: http://www.kybele.es

Resumen. La Web ha evolucionado desde su surgimiento, hasta nuestros días y

consecuentemente han evolucionado las aplicaciones Web. Las metodologías

de desarrollo de aplicaciones Web cambiaron para acoplarse a dicha evolución,

cambiando sus técnicas, actividades y procesos; como ocurrió, por ejemplo,

cuando surgieron los servicios Web. La aparición de la Web Semántica y espe-

cialmente el surgimiento de los Servicios Web Semánticos, requieren el desa-

rrollo de nuevos elementos durante el proceso de desarrollo de las aplicaciones

que los utilizan. Las metodologías de desarrollo Web deben adaptarse para so-

portar el desarrollo sistemático de tales elementos. En este trabajo presentamos

una primera aproximación para el modelado de servicios Web semánticos y por

ende de las aplicaciones que los utilizan. Este enfoque se basa en la extensión

de MIDAS, un marco metodológico para el desarrollo de Sistemas de Informa-

ción Web. Esta extensión de MIDAS que llamaremos MIDAS-S agrega a

MIDAS una serie de modelos para abordar el modelado de los elementos reque-

ridos en las aplicaciones Web que utilizan Servicios Web Semánticos siguiendo

un enfoque dirigido por modelos.

1 Introducción

En [1] los autores presentaban una arquitectura de integración basada en Servicios

Web Semánticos (SWS) para la integración de portales Web. El objetivo de dicha

arquitectura es el de facilitar el desarrollo de portales Web de integración, es decir

portales Web que permiten acceder a datos y servicios de otros portales Web subya-

centes. Los SWS incrementan la potencialidad de los Servicios Web (SW) mediante la

asociación de descripciones semánticas, permitiendo que las tareas de búsqueda, des-

cubrimiento, selección, composición e integración de SW sean automatizadas. Exis-

ten, actualmente, varios enfoques para describir semánticamente SW, tales como:

OWL-S [15], WSMO (Web Services Modeling Ontology)[9] y WSDL-S[2] entre

otras. Las propuestas más importantes son OWL-S y WSMO, ambas fueron enviadas

al W3C (Word Wide Web Consortium) para su estandarización.


401

Los SWS son uno de los componentes principales de la arquitectura de integración

mencionada previamente y, para poder desarrollar portales de integración basados en

la arquitectura propuesta, deben desarrollarse múltiples SWS.

Muchas metodologías de desarrollo Web han aparecido desde que surgió la Web

para abordar diferentes aspectos del desarrollo de aplicaciones Web. Estas metodolo-

gías fueron evolucionando conforme evolucionó la Web. Por ejemplo, con el surgi-

miento de los servicios Web (tal como los conocemos hoy), las metodologías existen-

tes fueron modificadas para incluir nuevos modelos para la generación de documentos

WSDL, para modelar la composición de dichos servicios, etc. Sin embargo, hasta

donde sabemos, las metodologías actuales de desarrollo de software no han incluido

aún, técnicas y procesos específicos para el desarrollo de aplicaciones basadas en

SWS.

De manera general, el desarrollo de SWS debería ser incluido dentro de metodolo-

gías de desarrollo por diversas razones, pero fundamentalmente porque de esa manera

se sistematizaría su desarrollo y promovería su adopción por parte de los desarrollado-

res. Se debe tener en cuenta que los lenguajes enriquecidos semánticamente tales

como OWL-S o WSML que fueron creados para escribir las descripciones de los

SWS, suelen tener una curva de aprendizaje que resulta muy empinada para el des-

arrollador medio, resultando en una barrera para la adopción de esta tecnología. Para

ser ampliamente adoptado por los desarrolladores y para tener éxito en el desarrollo

de aplicaciones reales, el desarrollo de SWS debe acoplarse a las tendencias actuales

en Ingeniería del Software.

Precisamente, una de esas tendencias actuales para el desarrollo de software, es el

desarrollo dirigido por modelos basado en la Arquitectura Dirigida por Modelos

(MDA, Model Driven Archictecture) [12] propuesta por el Object Management

Group (OMG). MDA es un enfoque para la creación y refinamiento de modelos y la

generación de código a partir de dichos modelos.

MIDAS [3] es un marco metodológico basado en MDA para el desarrollo de Sis-

temas de Información Web (SIW). En este trabajo presentamos MIDAS-S, una exten-

sión de MIDAS que integra dentro del marco metodológico de MIDAS el modelado

de SWS. La motivación de este trabajo fue la carencia de técnicas específicas y de

enfoques metodológicos para el desarrollo de SWS que se experimentó durante el

desarrollo de las aplicaciones de integración utilizando la arquitectura de integración

que se mencionó anteriormente. Además, en la actualidad existe un elevado número

de proyectos de investigación y desarrollo con alto grado de participación por parte de

la industria, en el área de los SWS, lo que hace pensar que, muy probablemente, los

SWS sean adoptados a corto plazo en el desarrollo de aplicaciones. Para entonces,

será necesario contar con técnicas y modelos específicos como los que se proponen en

este trabajo.

La versión de MIDAS-S incluida en este trabajo define los nuevos modelos reque-

ridos para desarrollar SWS usando WSMO como plataforma específica para imple-

mentar SWS. Sin embargo, otras propuestas (tales como OWL-S) podrían integrarse

también. Proponemos utilizar WSMO principalmente porque se trata de una propuesta

para la descripción de SWS concebida teniendo en cuenta la integración de servicios y

porque incluye, además del lenguaje de descripción de SWS llamado WSML (Web

Services Modeling Language), un entorno de ejecución denominado WSMX (Web


402

Services Execution Environment) que permite la ejecución de SWS descriptos me-

diante WSMO. Otro motivo por el cual utilizamos WSMO es porque es la propuesta

que presenta mayor intensidad en las actividades investigación y desarrollo.

MIDAS-S se centra en la creación de SWS y de las descripciones asociadas en

WSML a través del desarrollo de modelos UML [14] siguiendo un enfoque MDA.

Así, los desarrolladores no necesitan conocer más que UML para poder modelar

SWS.

Para la validación del enfoque presentado en este trabajo, hemos usado como caso

de estudio, el desarrollo de los SWS necesarios para la construcción de un portal Web

de integración, basado en la arquitectura propuesta en [1] que tiene por objetivo inte-

grar los diferentes portales Web de los Ayuntamientos del sur de Madrid. Una des-

cripción detallada de este caso de estudio puede encontrarse en [1].

El resto del trabajo se estructura de la siguiente manera. La sección 2 describe muy

brevemente MIDAS y WSMO como la plataforma elegida para la descripción de

SWS. La sección 3 presenta MIDAS-S incluyendo su nueva arquitectura de modelos.

La sección 4 discute los trabajos relacionados. Finalmente la sección 5 remarca las

principales conclusiones y plantea trabajos futuros de investigación.

2 Conceptos Previos

En esta sección se presentan brevemente algunos conceptos previos para dotar de un

contexto al resto del trabajo. La sección 2.1 describe MIDAS como el marco metodo-

lógico que es extendido para obtener MIDAS-S. La sección 2.2 describe WSMO

como la propuesta adoptada para la descripción de SWS.

2.1 MIDAS: Una Metodología Dirigida por Modelos para el Desarrollo de SIW

MIDAS es un marco metodológico, basado en MDA para el desarrollo ágil de SIW.

MIDAS propone modelar los SIWs de acuerdo a dos dimensiones ortogonales. Por un

lado, el grado de dependencia de la plataforma (según el enfoque MDA), por lo que

define Modelos Independientes de Computación (CIMs – Computation Independent

Models), Modelos Independientes de Plataforma (PIMs – Platform Independent Mo-

dels) y Modelos Específicos de Plataforma (PSMs – Platform Specific Models. Por el

otro lado, modela el sistema teniendo en cuenta los aspectos en los que comúnmente

se estructura un SIW: hipertexto [4], contenido [10],[16] y comportamiento [5]. Ade-

más MIDAS sugiere utilizar UML como notación única para todo el proceso de mode-

lado a nivel PIM y PSM.


403

Fig. 1. Marco Metodológico MIDAS

2.2 WSMO: Web Services Modeling Ontology

WSMO es una iniciativa para la descripción de SWS propuesta por el DERI1. Define

las especificaciones ontológicas para los elementos centrales de SWS. Los elementos

de WSMO están definidos utilizando MOF (Meta Object Facility), los cuatro princi-

pales son:

Ontologías proporcionan la terminología utilizada por otros elementos de WSMO

para describir los aspectos pertinentes de los dominios de discurso.

Servicios Web describen las entidades computacionales que proporcionan el acce-

so a servicios que proporciona algún valor en un dominio. Estas descripciones com-

prenden las capacidades, interfaces y el trabajo interno del servicio Web.

Metas (goals) representan los deseos de los usuarios, que podrían ser satisfechos

mediante un servicio Web.

Mediadores son componentes de WSMO para resolver los problemas de la inter-

operabilidad entre elementos diferentes.

En la propuesta de WSMO también se integra WSML (Web Service Modeling

Language) es un lenguaje de descripción semántica cuyo objetivo es formalizar los

elementos definidos en WSMO; y WSMX (Web Service Execution Enviroment) que

provee un entorno para el descubrimiento, selección, mediación, invocación e inter-

operabilidad de SWS. Una descripción detallada de WSMO puede encontrarse en [9].

3 MIDAS-S: Integrando el Desarrollo de Servicios Web

Semánticos en un Marco Metodológico Dirigido por Modelos

La versión de MIDAS-S que se incluye en este trabajo incluye las extensiones necesa-

rias para el modelado de SWS descritos siguiendo la propuesta de WSMO pero, el

objetivo final de MIDAS-S es integrar el desarrollo de SWS con el desarrollo de los

otros aspectos de un SIW como son el hipertexto, el contenido y el comportamiento.

1 Digital Enterprise Research Institute – www.deri.org


404

La figura 2 muestra la arquitectura de modelos de MIDAS-S que extiende a la de

MIDAS ya presentada en la figura 1. Para modelar las descripciones semánticas de los

SWS y los elementos relacionados ya vistos en la sección 2 (Servicios Web, Ontolo-

gías, Mediadores y Metas), MIDAS-S agrega un nuevo aspecto a la metodología, el

aspecto de semántica. Nótese, que el aspecto de semántica es transversal al resto de

los aspectos anteriormente considerados por MIDAS. Esto se debe a que es posible

incluir consideraciones semánticas en cualquier aspecto según sea necesario.

Este trabajo se centra en el modelado de las descripciones semánticas de los de

SWS, por lo que de ahora en adelante, nos centraremos en los aspectos de semántica y

de comportamiento de MIDAS-S. La Figura 3 describe los modelos definidos en el

aspecto de comportamiento (heredados del aspecto de comportamiento de MIDAS

[5]) y los modelos hasta ahora definidos en el aspecto de semántica.

CIM

PIM

PSM

<<M

appin

gs

PIM

-PIM

>>

<<M

appin

gs

PSM

-PS

M>>

<<M

appin

gs P

IM-P

SM

>>

Fig. 2. Arquitectura de Modelos de MIDAS-S.

Como hemos dicho esta primera versión de MIDAS-S se centra en el modelado de

SWS a nivel específico de plataforma, a este nivel el aspecto de semántica de

MIDAS-S, incluye un modelo por cada elemento de alto nivel definido en WSMO.

Así, se definen modelos para las ontologías, metas, servicios Web y mediadores

CIM

PIM

PS

M

<<M

appin

gs

PIM

-PIM

>>

<<M

appin

gs

PS

M-P

SM

>>

<<M

appin

gs P

IM-P

SM

>>

Fig. 3. Modelos definidos en los aspectos de comportamiento y semántica.

En la figura 4 se muestra la relación de los nuevos modelos definidos para MIDAS-

S y la arquitectura de cuatro niveles definida en MDA. El metamodelo de WSMO se

define a partir de MOF (Meta-Object Facility) [11] y se ubica en el Nivel M2 de me-

tamodelado al igual que los metamodelos definidos para cada uno de los elementos de


405

WSMO, cada uno de estos metamodelos se crean a partir de la redefinición del meta-

modelo de WSMO y abordando las particularidades de cada modelo en concreto.

«Metamodelo»

WSMO

«modelo»

Modelo de

Mediador

«modelo»

Modelo de

SWS

«modelo»

Modelo de

Ontología

«modelo»

Modelo de

Meta

MOF

«Metamodelo»

Mediador

«Metamodelo»

Servicio Web

Semántico

«Metamodelo»

Ontología

«Metamodelo»

Meta

«merge»«merge» «merge»

«merge»

Meta Ontoloía SWS Mediador

Nivel M3

(meta-meta-modelado)

Nivel M2

(meta-modelado)

Nivel M1

(modelado)

Nivel M0

(información)

Fig. 4. Modelos definidos en los aspectos de comportamiento y semántica.

Las instancias de estos metamodelos, ubicadas en el Nivel M1 de la Figura 4, modelan

ontologías, servicios Web y mediadores concretos, que se ubican en el nivel M0.

Para hacer uso de las capacidades de modelado gráfico de UML se han definido

también perfiles UML (UML profiles) para cada modelo, que soportan la notación

UML 2.0 [14] y permiten la edición gráfica de los modelos propuestas a través de

diagramas UML. Por razones de claridad, los perfiles UML de cada modelo no se han

representado en la figura 4, pero pertenecen al Nivel M2 de metamodelado.

Partiendo de los modelos UML del Nivel M1 y generando las descripciones co-

rrespondientes en XMI [19], se podrían generar las descripciones en WSML de cada

elemento requerido por WSMO implementando las reglas de transformación adecua-

das. La definición de dichas reglas de transformación está fuera del alcance de este

trabajo y serán abordadas en trabajos futuros.

A continuación y dadas las restricciones de espacio, a modo de ejemplo, presenta-

remos solo la definición del modelo de ontologías de WSMO. Para este modelo va-

mos a describir su metamodelo, un ejemplo y la generación del código WSML que se

obtendría a partir de dicho modelo.

3.1 Modelo de Ontologías WSMO

Para modelar las ontologías con WSMO hemos optado por definir dos modelos como

se muestra en la Figura 5. El modelo de contexto de ontología y el modelo de conteni-

do de ontología. Esta separación se debe principalmente a que en WSMO se puede

distinguir claramente la información contextual de una ontología de su contenido en

sí.


406

Fig. 5. Modelo Ontología WSMO.

El modelo de contexto de ontología extiende el modelo de paquetes de UML y re-

coge información sobre el contexto de una ontología, esto es: información sobre espa-

cios de nombres (namespaces), ontologías importadas, mediadores utilizados, etc. Su

metamodelo se puede observar en la figura 6.

Fig. 6. Metamodelo de Contexto de Ontología.

En la figura 6 los nuevos elementos son representados con elementos sombreados

(de ahora en adelante todos los nuevos conceptos en cada metamodelo se representa-

ran de esta manera).

La tabla 1 describe los elementos del modelo de contexto de ontología. Para cada

elemento, la tabla 1 enumera: su metaclase, la descripción de dicho elemento, los

valores etiquetados (si hubiera) y la notación utilizada para representar cada uno de

ellos.

Tabla 1. Elementos en el modelo de contexto de ontología.

Elemento del

Modelo Metaclase Descripción Notación

WOntology Package Representa una ontología

WSMO. Puede represen-

tar la que esta siendo

modelada o una ontología

importada.

Un paquete estereotipado con

<<WOntology>>, con el identifica-

dor de la ontología como nombre.

WMediator Package Representa un mediador

WSMO. Normalmente

importado por la ontología

que lo esta usando.

Un paquete estereotipado con

<<WMediator>>, con el identifica-

dor del mediador como nombre.


407

Ontology Package Representa cualquier

ontología importada (dis-

tinta a WSMO).

Un paquete estereotipado con <<On-

tology>>, con el identificador de la

ontología como.

WsmoImport Depende

ncy

Permite el uso de nombres

o identificadores para

referirse a los miembros

de un paquete desde otro

namespace.

Una dependencia estereotipada con

<<WSMOImport>> y con el nombre

del prefijo como un Valor Etiqueta-

do. El prefijo es usado para identifi-

car el namespace. Este prefijo es

agregado al nombre local de los

elementos y atributos para formar el

nombre calificado.

Namespace Package Un conjunto de símbolos

únicos o identificadores,

los cuales pueden ser

utilizados por medio del

prefijo de la relación de

Importación de WSMO.

Un paquete cuyo nombre es el nom-

bre del conjunto de elementos que

representa.

El modelo de contenido de ontología representa los diferentes elementos constituti-

vos de la ontología que se esta modelando: conceptos, atributos, instancias, axiomas,

etc. El modelo de contenido de ontología extiende el modelo de clases de UML y su

metamodelo se presenta en la figura 7.

Fig. 7. Metamodelo de Contenido de Ontología.

La tabla 2 describe los elementos del modelo de contenido de ontología. Para cada

elemento, la tabla 2 enumera: su metaclase, la descripción de dicho elemento, los

valores etiquetados si hubiera y la notación utilizada para representar cada uno de

ellos.


408

Tabla 2. Elementos en el modelo de contenidos de ontología

Elemento

del

Modelo

Meta

clase Descripción Notación

Concept Class Representa el concepto en una

ontología.

Una clase estereotipada con <<Con-

cept>>, y el identificador del concep-

to como nombre.

Att Class Representa los atributos de un

concepto.

Valores Etiquetados: ofType:

representan la restricción de

integridad en los valores del

atributo cuando la definición

no ha sido inferida.

Una clase estereotipada con

<<Att>>, con el atributo identifica-

dor como nombre.

Axiom Class Representa la expresión lógi-

ca expresada como axiomas.

Valores Etiquetados: axiom-

Definition: la expresión lógi-

ca del axioma

Una clase estereotipada con

<<Axiom>>, con el identificador del

axioma como nombre. Se recomienda

representar el valor etiquetado

axiomDefinition como parte de un

comentario unido al elemento del

modelo.

Relation Class Representa interdependencias

entre distintos conceptos.

Valores Etiquetados: Parame-

ter: una lista de los paráme-

tros de la relación.

Una clase estereotipada con <<Rela-

tion>> con el identificador de la

relación como nombre.

Relation-

Instance

Class Representa la instancia de una

relación.

Valores Etiquetados: una lista

de los valores de la instancia

de la relación.

Una clase estereotipada con <<Rela-

tionInstance>> y el identificador de

la relación a la cual pertenece la

instancia en cuestión.

Instance Class Representa la instancia de un

Concept.

Valores Etiquetados: hasVa-

lue: incluye los valores de

atributos para los atributos

simples definidos en el con-

cepto.

Una clase estereotipada con <<Ins-

tance>> y el identificador de la ins-

tancia como nombre.

Impli-

esType

Asso-

ciation

Representa las definiciones

inferidas de un atributo (Att).

Vincula la definición de un

atributo con el concepto del

cual es inferido

Una asociación directa estereotipada

con <<impliesType>> y la caracterís-

tica del atributo como valor etiqueta-

do. La fuente es el atributo y el desti-

no es el concepto del cual sus valores


409

Valores Etiquetados: AttFea-

ture: información adicional

sobre los atributos del con-

cepto. Toma valores de la

enumeración AttFeatureType

Enumeration.

son inferidos.

memberOf Asso-

ciation

Representa la relacion entre:

una instancia (Instance) y los

conceptos a los que pertene-

ce; una instancia de relación

(RelationInstance) y la rela-

ción a la que pertenece.


con <<memberOf>>. La fuente es la

instancia (Instance) y el destino es el

concepto (Concept) al cual la instan-

cia pertenece.

inverseOf Asso-

ciation

Vincula la definición del

atributo con el concepto

(Concept) apropiado cuando

la definición del atributo es

inferida como inverso del

mismo.


con <<inverseOf>>. La fuente es el

atributo y el destino es el concepto

inverso del cual sus valores son infe-

ridos.

SubConce

ptOf

Asso-

ciation

Representa la relación entre

un concepto y sus super-

conceptos.


con <<SubConceptOf>>. El origen

es el subconcepto y el destino es el

superconcepto.

Para el escenario de aplicación mencionado anteriormente, hemos definido varias

ontologías nuevas y hemos adaptado algunas ya existentes. Hemos definido, entre

otras, una ontología para definir los conceptos relacionados con los Tickets de teatro,

puesto que en el portal de integración de portales de ayuntamientos integramos la

información de los eventos culturales de los diferentes ayuntamientos con los servicios

provistos por un portal Web de venta de entradas de teatro. Como un ejemplo de uso

del modelo de ontología, la figura 8.a muestra el modelo de contexto de ontología

para la ontología de Tickets de teatro y la 8.b muestra parcialmente el modelo de

contenido de dicha ontología. En la figura se pueden apreciar los nuevos estereotipos,

restricciones y valores etiquetados definidos para modelar los diferentes elementos de

WSMO.


410

(a)

(b)

Fig. 8. Modelo de Ontología para la Ontología de Tickets de Teatro

A partir de los modelos mostrados en la figura 8.a y 8.b y aplicando las reglas de

transformación apropiadas es posible obtener código WSDL para esta ontología, tal

como se muestra en la figura 9. La figura resalta con un cuadro sombreado el código

WSDL correspondiente al Modelo de Contexto de la Ontología correspondiente a la

figura 8.a.


411

Fig. 9. Código WSDL generado a partir de los modelos UML de Ontología de Tickets de Tea-

tro.

4 Estado del Arte

En la actualidad, existen relativamente pocas propuestas para el desarrollo sistemático

de SWS, esta escasez de propuestas se debe, principalmente, a la inmadurez de esta

tecnología. Las propuestas existentes se puede dividir en dos grupos: (a) Herramientas

para el modelado visual y generación de descripciones de SWS y (b) Enfoques meto-

dológicos para el desarrollo de SWS.

Con respecto al primer grupo, existen varias herramientas para la generación de

descripciones de SWS en OWL-S [13],[6] o WSMO [17],[18]. Estas herramientas

solo soportan el modelado gráfico de los diferentes elementos de los SWS y la gene-

ración del código correspondiente, lamentablemente cada una de ella define su propia

notación y no siguen ningún enfoque metodológico ni integran el desarrollo de SWS

en un proceso de desarrollo de aplicaciones Web.

En el segundo grupo, las propuestas son aún menos. El trabajo presentado en [8]

describe un proceso de tres pasos para la creación de descripciones de SWS con

OWL-S a partir de un conjunto de artefactos de software existentes (por ejemplo mo-

delos de clases, modelos WSDL). El trabajo presentado en [7] describe un método de

software automatizable que utiliza técnicas MDA para generar descripciones OWL-S

a partir de un modelo UML. Desafortunadamente ambos trabajos se centran única-


412

mente en OWL-S y tampoco integran el desarrollo de SWS dentro de un marco meto-

dológico para el desarrollo de aplicaciones. Hasta donde nosotros sabemos, no tene-

mos conocimiento de la existencia de un marco metodológico como el que se presentó

en este trabajo que trata de integrar el desarrollo sistemático de SWS basados en

WSMO dentro de un marco metodológico dirigido por modelos.


Los servicios Web semánticos están cobrando una importancia considerable hoy en

día, ya que se trata de una de las tecnologías relacionadas a la Web semántica con más

posibilidades de ser adoptada a corto plazo. Sin embargo, para fomentar la adopción

extendida de esta tecnología es necesario definir técnicas de ingeniería del software

para permitir el desarrollo sistemático de SWS.

En este trabajo hemos propuesto una extensión a MIDAS, un marco metodológico

dirigido por modelos para el desarrollo de sistemas de información Web, llamada

MIDAS-S. MIDAS-S constituye un paso hacia la integración del desarrollo de SWS,

utilizando WSMO, dentro de un marco metodológico dirigido por modelos.

En este trabajo hemos presentado los nuevos modelos de MIDAS-S para el desa-

rrollo se SWS, y hemos descrito brevemente uno de ellos presentando su metamodelo

y su aplicación al desarrollo de una aplicación real. Nótese que los metamodelos pre-

sentados en este trabajo deben ser aún refinados para mejorar el modelado de axiomas

y restricciones lógicas propias del lenguaje WSML, en este sentido estamos trabajan-

do en el modelado de axiomas WSML a través de OCL (Object Constraint Language)

un lenguaje también familiar para los desarrolladores.

Como trabajos futuros de investigación proponemos la integración de los modelos

definidos en este trabajo dentro de MIDAS-CASE para soportar su transformación

hacia descripciones en WSML. MIDAS-CASE es una herramienta case que actual-

mente esta siendo desarrollada para soportar la metodología MIDAS.

Otro objetivo de MIDAS-S es integrar el desarrollo de SWS con el desarrollo de

otros aspectos del desarrollo de las aplicaciones Web como por ejemplo el hipertexto

y el comportamiento. Como trabajo futuro de investigación también se plantea la

definición de reglas de transformación entre los diferentes modelos de MIDAS y los

nuevos modelos definidos en el aspecto de semántica de MIDAS-S.

Agradecimientos

Este trabajo ha sido financiado parcialmente por el Ministerio de Ciencia y Tecnolo-

gía de España a través del proyecto GOLD (TIN 2005-0010)


413

Referencias

[1] Acuña C., Gómez J.M., Marcos E., Bussler C. A Web Portal Integration Architecture

based on Semantic Web Services. Actas del 7º Internacional Conference on Informa-

tion Integration and Web bases Applications and Services (IIWAS 2005). Pp. 174-

185, Malasia, 2005.

[2] Akkiraju R., Farell J., Miller J.A., Nagarajan M., Sheth A. y Verma K. Web Service

Semantics - WSDL-S. Recuperado de:

http://w3.org/2005/04/FSWS/Submissions/17/WSDL-S.htm, 2005

[3] Cáceres, P., Marcos, E., Vela, B. A MDA-Based Approach for Web Information Sys-

tem Development, Actas del Workshop in Software Model Engineering. 2003

[4] De Castro V., Marcos, E., Cáceres P., A User Service Oriented Method to Model

Web Information Systems. X. Zhou et al. (Eds.): Web Information System Engineer-

ing 2004 (WISE 2004), LNCS 3306, pp. 41–52, 2004.

[5] De Castro, V., Marcos, E., Wieringa, R.,: From Business Modeling to Web Services

Composition: A Web Engineering Approach. 25th International Conference on Con-

ceptual Modeling (ER2006). Enviado.

[6] Elenius D., Denker G., Martin D., Gilham F., Khouri J., Sadaati S., and Senanayake

R.. The owl-s editor - a development tool for semantic web services. En actas del Se-

cond European Semantic Web Conference, Mayo de 2005.

[7] Gannon G. and Timm J. An MDA-based Approach for Facilitating Adoption of Se-

mantic Web Service. En Actas del IEEE EDOC Workshop on Model-Driven Seman-

tic Web (MDSW 04), Septiembre de 2004.

[8] Jaeger M., Engel L, and Geihs K. A methodology for developing owl-s descriptions.

En First International Conference on Interoperability of Enterprise Software and Ap-

plications Workshop on Web Services and Interoperability, Febrero de 2005.

[9] Lausen H, Polleres A. and Roman D. (Eds). Web Service Modeling Ontology Sub-

mission. Recuperado de: http://www.w3.org/Submission/WSMO/, 2005

[10] Marcos, E., Vela, B., Cavero, J.M.: Methodological Approach for Object-Relational

Data-base Design using UML. Journal on Software and Systems Modeling (SoSyM).

Springer-Verlag. France, R., Rumpe, B. (eds.). Volúmen SoSyM 2, pp.59-72, 2003.

[11] The Object Management Group: Meta-Object Facility, version 1.4. Recuperado de:

http://omg.org/technology/documents/formal/mof.htm, 2002

[12] Miller, J., Mukerji, J. (eds.). MDA (2001) ‘OMG Model Driven Architecture’, Docu-

mento Nº ormsc/2001-07-01. Recuperado de: http://www.omg.com/mda.

[13] Scicluna J., Abela C., and Montebello M.. Visual modeling of owl-s services. En ac-

tas del IADIS International Conference WWW/Internet, Octubre 2004.

[14] UML (2003). ‘UML Superstructure 2.0’, .OMG Especificación Adoptada ptc/03-08-

02. Accesible en: http://www.uml.org/

[15] OWL Services Coalition. Owl-s: Semantic markup for web services. Recuperado de

http://www.daml.org/services/owls/1.0/owl-s.html, 2003.

[16] Vela, B., Acuña, C. and Marcos, E. A Model Driven Approach for XML Database

Devel-opment, 23rd. International Conference on Conceptual Modeling (ER2004).

LNCS 3288. Springer Verlag, pp. 780-794. 2004.

[17] WSMO Studio. Recuperado de: http://www.wsmostudio.org, 2005

[18] Web Service Modeling Toolkit. Recuperado de:

http://www.wsmo.org/wsmo_tools.html, 2005

[19] XML Metadata Interchange (XMI). Recuperado de:

http://ww.omg.org/technology/documents/formal/xmi.htm, 2005


414

Un Perfil UML para la definición de Componentes Inteligentes

José L. Pastrana1, Ernesto Pimentel1, Miguel Katrib2

1 ETSI Informática, Universidad de Málaga, Campus de teatinos s/n, 29071 Málaga, España

{pastrana, ernesto}@lcc.uma.es 2 Facultad de Matemática y Computación, Universidad de La Habana, San Lázaro y L, Ve-

dado, Ciudad de la Habana, Cuba [email protected]

Resumen. El desarrollo de sistemas basados en componentes tiene el problema del posible cambio en las interfaces de los mismos al adquirir o usar una nueva versión de un componente o sustituirlo por otro nuevo, ya que dichos compo-nentes se comportan para nosotros como cajas negras que pueden ser remotos o locales (adquiridos por compra, descarga, etc.). El presente trabajo presenta cómo podemos usar los mecanismos de extensión del lenguaje de modelado UML (Unified Modelling Language) [3] y en concreto el uso de perfiles UML para definir un metamodelo de Componentes Inteligentes cuya generación de código produzca unos componentes con una base de conocimiento capaz de adaptarse a los cambios de interfaz de los componentes que usa. Así mismo, y a través de un ejemplo, mostraremos los detalles del código generado.

1 Introducción

La ingeniería del Software basada en componentes (Component-Based Software Engineering o CBSE) centra sus esfuerzos en el desarrollo y construcción de aplica-ciones software gracias a la integración de componentes software que ya existen y que han podido ser desarrollados por nuestro propio equipo o descargados, compra-dos, etc. Así, la técnica clásica de desarrollo de sistemas escribiendo código se ve complementada por el ensamblaje de componentes existentes. Por tanto, uno de los máximos objetivos perseguidos por la CBSE es la flexibilidad y facilidad de mante-nimiento de los sistemas software. Algunos de esos sistemas serán tan críticos que su mantenimiento debe realizarse “al vuelo” lo que no permite parar todo el sistema, modificar y reiniciar todo el sistema. El desarrollo de las metodologías de análisis y diseño orientados a objetos trajo con-sigo la existencia de diversas notaciones y propuestas, entre las que cabe destacar la metodología de Booch [1], la Object Modeling Technique (OMT) de Rumbaugh et al [8] y OOSE de Ivar Jacobson [4] entre otras. Ante el problema de la proliferación de notaciones distintas, los autores más relevantes unieron esfuerzos para producir una notación unificada, y el resultado de esto fue el Lenguaje Unificado de Modelado o Unified Modeling Language, UML [3].


415

En palabras de sus creadores, UML es un lenguaje para especificar, visualizar, cons-truir y documentar los artefactos de los sistemas software, así como para modelado de negocios y otros sistemas no-software. UML representa una colección de prácticas de ingeniería aconsejables que han demostrado ser útiles para modelar sistemas grandes y complejos. Fue desarrollado por Rational Software, la empresa de Grady Booch, y sus socios, y en 1997 fue remitido al Object Management Group en lo que sería la versión 1.1 de UML. Desde su creación, UML ha sido adoptado por muchas empre-sas como estándar en sus procesos de desarrollo, para modelado de negocios, gestión de requisitos, análisis y diseño, programación y pruebas. Actualmente, UML es ges-tionado por el OMG como un estándar más. UML incluye artefactos para modelar clases, máquinas de estados, casos de uso y otros elementos de la orientación a obje-tos El presente trabajo propone el desarrollo de componentes inteligentes que sean capa-ces de adaptarse en tiempo de ejecución a los posibles cambios producidos en las interfaces de los componentes externos (conceptualmente remotos) que dicho compo-nente utiliza. Para el desarrollo de dichos componentes se va a desarrollar un perfil UML que permita la generación automática de código para dichos componentes a partir de su modelado.

2 Perfiles UML

El lenguaje de modelado UML es el estándar más utilizado para especificar y docu-mentar cualquier sistema de forma precisa. Sin embargo, el hecho de que UML sea una notación de propósito muy general obliga a que muchas veces sea deseable poder contar con algún lenguaje más específico para modelar y representar los conceptos de ciertos dominios particulares. Los Perfiles UML [2, 5] constituyen el mecanismo que proporciona el propio UML para extender su sintaxis y su semántica para expresar los conceptos específicos de un determinado dominio de aplicación. Un modelo es una descripción de (parte de) un sistema, descrito en un lenguaje bien definido. Y, un lenguaje bien definido es un lenguaje con una sintaxis y semántica precisa que puede ser interpretado y manipulado por un ordenador. Los modelos proporcionan un mayor nivel de abstracción, permitiendo trabajar con sistemas mayo-res y más complejos, y facilitando el proceso de codificación e implementación del sistema de forma distribuida y en distintas plataformas. UML es un lenguaje de propósito general lo que proporciona una gran flexibilidad y expresividad a la hora de modelar sistemas. Sin embargo, hay numerosas ocasiones en las que es mejor contar con algún lenguaje más específico para modelar y repre-sentar los conceptos de ciertos dominios particulares. Esto sucede, por ejemplo, cuando la sintaxis o la semántica de UML no permiten expresar los conceptos especí-ficos del dominio, o cuando se desea restringir y especializar los constructores pro-pios de UML, que suelen ser demasiado genéricos y numerosos.


416

OMG (Object Management Group) define dos posibilidades a la hora de definir len-guajes específicos de dominio, y que se corresponden con las dos situaciones men-cionadas antes: o bien se define un nuevo lenguaje (alternativa de UML), o bien se extiende el propio UML, especializando algunos de sus conceptos y restringiendo otros, pero respetando la semántica original de los elementos de UML (clases, asociaciones, atributos, operaciones, transiciones, etc.) utilizando una serie de mecanismos recogidos en lo que se denominan Perfiles UML (UML Profiles). Cada una de estas dos alternativas presenta ventajas e inconvenientes. Así, definir un nuevo lenguaje permite mayor grado de expresividad y correspondencia con los con-ceptos del dominio de aplicación particular, al igual que cuando nos hacemos un traje a medida. Sin embargo, el hecho de no respetar el metamodelo estándar de UML va a impedir que las herramientas UML existentes en el mercado puedan manejar sus conceptos de una forma natural. Un Perfil se define en un paquete UML, estereotipado «profile», que extiende a un metamodelo o a otro Perfil. Tres son los mecanismos que se utilizan para definir Perfiles: estereotipos (stereotypes), restricciones (constraints), y valores etiquetados (tagged values). En primer lugar, un estereotipo viene definido por un nombre, y por una serie de elementos del metamodelo sobre los que puede asociarse. Gráficamente, los estereo-tipos se definen dentro de cajas, estereotipadas «stereotype». A los estereotipos es posible asociarles restricciones, que imponen condiciones sobre los elementos del metamodelo que han sido estereotipados. De esta forma pueden describirse, entre otras, las condiciones que ha de verificar un modelo “bien formado” de un sistema en un dominio de aplicación. Finalmente, un valor etiquetado es un meta-atributo adicional que se asocia a una metaclase del metamodelo extendido por un Perfil. Todo valor etiquetado ha de con-tar con un nombre y un tipo, y se asocia un determinado estereotipo. Los valores etiquetados se representan de forma gráfica como atributos de la clase que define el estereotipo.

3 Creación de Perfiles UML

En esta sección describiremos un posible método de elaboración de perfiles UML. La especificación de UML 2.0 sólo se limita a definir el concepto de perfil y sus conte-nidos. Sin embargo que es necesario poder contar con ciertas guías y recomendaciones que sirvan de ayuda a la hora de definir un perfil UML para una plataforma o dominio de aplicación concreto. A la hora de definir un perfil UML proponemos seguir los siguientes pasos:


417

1. Antes de comenzar, es preciso disponer de la correspondiente definición del

metamodelo de la plataforma o dominio de aplicación a modelar con un per-fil. Si no existiese, entonces definiríamos dicho metamodelo utilizando los mecanismos del propio UML (clases, relaciones de herencia, asociaciones, etc.), de la forma usual como lo haríamos si nuestro objetivo no fuese definir un perfil UML. Deberemos incluir la definición de las entidades propias del dominio, las relaciones entre ellas, así como las restricciones que limitan el uso de estas entidades y de sus relaciones.

2. Si ya disponemos del metamodelo del dominio, pasaremos a definir el Perfil. Dentro del paquete «profile» incluiremos un estereotipo por cada uno de los elementos del metamodelo que deseamos incluir en el Perfil. Estos este-reotipos tendrán el mismo nombre que los elementos del metamodelo, esta-bleciéndose de esta forma una relación entre el metamodelo y el Perfil. En principio cualquier elemento que hubiésemos necesitado para definir el me-tamodelo puede ser etiquetado posteriormente con un estereotipo.

3. Es importante tener claro cuáles son los elementos del metamodelo de UML que estamos extendiendo sobre los que es posible aplicar un estereotipo. Ejemplo de tales elementos son las clases, sus asociaciones, sus atributos, las operaciones, las transiciones, los paquetes, etc. De esta forma cada estereoti-po se aplicará a la metaclase de UML que se utilizó en el metamodelo del dominio para definir un concepto o una relación.

4. Definir como valores etiquetados de los elementos del perfil los atributos que aparezcan en el metamodelo. Incluir la definición de sus tipos, y sus po-sibles valores iniciales.

5. Definir las restricciones que forman parte del Perfil, a partir de las restric-ciones del dominio. Por ejemplo, las multiplicidades de las asociaciones que aparecen en el metamodelo del dominio, o las propias reglas de negocio de la aplicación deben traducirse en la definición las correspondientes restric-ciones.

Una vez se ha definido un Perfil UML, la forma de utilizarlo en una aplicación con-creta se representa mediante una relación de dependencia (estereotipada «apply») entre el paquete UML que contiene la aplicación, y los paquetes que definen los Per-files UML que se desean utilizar.

4 SmartComponent Profile

Nuestra propuesta se aplica a sistemas donde uno (o varios) componentes utilizan servicios proporcionados por otros componentes que pueden ser locales o remotos, por lo que partiremos de un esquema de aplicación cliente/servidor conectados a través de otro componente Proxy o intermediario. El metamodelo que describe tal dominio de aplicación puede ser descrito en UML como sigue:


418

MyModel<<metamodel>>

Client<<Component>>

Server<<Component>>

<<requestService>>

<<requestService>>

Proxy<<Component>>

ProxyInterfaceServerInterface

Fig. 1 Metamodelo de la Aplicación

A partir de este metamodelo, el Perfil UML que va a representarlo va a estar descrito como un paquete UML, estereotipado «profile»:

SmartComponent<<profile>>

Class<<MetaClass>> Proxy

sharp : PrologInterface OWL_ontology : String

<<Stereotype>>

Fig. 2 Profile UML

Como puede observarse, dicho Perfil define un estereotipo, correspondiente a la clase Proxy definida en el metamodelo, así como las metaclases de UML sobre las que pueden aplicarse tales estereotipos. Dichas metaclases corresponden al metamodelo a ser extendido, en este caso al metamodelo de UML. Una vez se ha definido el Perfil UML, para utilizarlo en una aplicación concreta lo representamos mediante una rela-ción de dependencia (estereotipada «apply») entre el paquete UML que contiene la aplicación y el paquete que define nuestro Perfiles UML, tal como puede verse en Fig. 3.


419

SmartComponent<<profile>>

MyApplication

<<apply>>

Fig. 3 Diagrama que muestra una aplicación que hace uso del Perfil

5 Adaptación Dinámica de Componentes

Adaptar aplicaciones basadas en componentes se reduce a la posibilidad de adaptar uno (o más) componentes en tiempo de ejecución, o lo que es lo mismo, desconectar un componente y sustituirlo por otro nuevo (una nueva versión) [6]. Una adaptación dinámica puede ser necesaria debido a múltiples razones: correctivas, adaptativas, de extensión, de perfeccionamiento, etc. Una adaptación correctiva elimina fallos de comportamiento del componente que se está ejecutando, reemplazándolo por una nueva versión que tiene la misma funciona-lidad pero que funciona correctamente. Cuando lo que hacemos en una adaptación adaptativa, lo que se realiza es una adaptación de la aplicación en respuesta a cam-bios del entorno (hardware, sistema operativo, etc.). Otra clase de adaptación es la adaptación por extensión en la que se añaden nuevas funcionalidades al sistema me-diante la adicción de nuevos componentes. Por último, las adaptaciones de perfeccio-namiento se realizan para mejorar la aplicación aun cuando esta funciona correcta-mente, reemplazando un componente por otro que ha sido optimizado.

A la hora de realizar una adaptación se deben satisfacer muchos requisitos, pero los más importantes a tener siempre en cuenta son la consistencia, el rendimiento y el grado de automatización. La consistencia concierne a la aplicación usada para adap-tar la aplicación actual en tiempo de ejecución. Dicha aplicación que realice las adap-taciones debe ser altamente prioritaria. Sin embargo, eso no debe suponer que dicha aplicación de adaptación tenga todo tipo de derechos para hacer lo que quiera y cuan-do quiera, ya que la operación de adaptación debe preservar la consistencia de la misma. El tema del rendimiento se refiere a la duración de la adaptación y al número de componentes afectados que deben ser mínimos. Y por ultimo, el grado de automa-tización es un punto importante, ya que representa la capacidad de una aplicación de


420

adaptarse a si misma; esto es posible cuando la aplicación tiene información relevante en tiempo de ejecución y es capaz de procesarla de manera que la propia aplicación se adapte a las circunstancias en tiempo de ejecución. Para poder realizar procesos de adaptación de forma automática e inteligente en tiem-po real, necesitamos contar con cierta información a cerca de qué términos pueden ser equivalentes, reemplazables, etc. Para suministrar dicha información, ya que no hablamos de simples sinónimos sino de información de equivalencias o reemplazos dependientes de un dominio y de un contexto, usaremos una ontología que ya es una herramienta que está siendo usada con éxito para propósitos de comprensión del len-guaje natural en campos como la Web semántica. Como lenguaje de ontologías usa-remos OWL que es el estándar del OMG. Por tanto, se va a usar OWL [9] para sumi-nistrar una información procesable automáticamente para adaptar peticiones de servi-cios en tiempo de ejecución.

Dentro del conjunto características que permite OWL Lite tenemos las relacionadas con equivalencias (Equality y Inequality), que nos van a permitir establecer qué con-ceptos son equivalentes y cuáles no. En nuestra propuesta usaremos las equivalencias de clase, propiedad y la identidad: equivalentClass, equivalentProper-ty y sameAs.

• equivalentClass: esta característica nos permite establecer clases de com-ponentes que son equivalentes. Por ejemplo, la clase coche es equivalente a la clase automóvil.

• equivalentProperty: esta característica nos permite establecer propieda-des equivalentes. Por ejemplo, tiene un jefe podría ser una propiedad equiva-lente a tiene un superior.

• sameAs: esta característica nos permite definir sinónimos de un individuo, Por ejemplo, José es lo mismo que Pepe.

Utilizando estas propiedades, estableceremos que dos servicios son sustituibles para ser adaptados si son el mismo (sameAs) o son una propiedad equivalente (equiva-lentProperty) y dos tipos, dos nombres o dos componentes son sustituibles para ser adaptados si son el mismo (sameAs) o son de una clase equivalente (equiva-lentClass).

6 Detalles de Implementación

El perfil definido debe ser implementado de forma automática de manera que se genere el código correspondiente a los intermediarios que realizan las llamadas y las adaptaciones inteligentes de forma totalmente transparente al usuario. A la hora de realizar una implementación de la propuesta hemos asumido que nuestros com-ponentes son ensamblados (assemblies) bajo la plataforma Microsoft .NET. Por tanto, a la hora de generar el Proxy encargado del manejo del componente, se ge-


421

nerará un método por cada servicio que éste ofrezca y en el que se realizarán las llamadas a través de un objeto “inteligente” o “adaptable”. Supongamos que queremos desarrollar una aplicación de escritorio para el manejo de una calculadora simple y disponemos del siguiente componente que nos ofrece los servicios deseados: namespace Calculadora { public class Calculadora { public int Suma(int x, int y); public int Resta(int x, int y); public int Multiplica(int x, int y) ; public int Divide(int x, int y); } } En la generación de código, se generará el Proxy CalculadoraAdaptable, que realizará el siguiente proceso para la invocación de los servicios: public int Suma(int x, int y) { return (int)Adapta(c,"Suma",new object[] {x,y}); { public int Resta(int x, int y) { return (int)Adapta(c,"Resta",new object[] {x,y}); } public int Multiplica(int x, int y) { return (int)Adapta(c,"Multiplica",new object[]{x,y}); } public int Divide(int x, int y) { return (int)Adapta(c,"Divide",new object[] {x,y}); }

El método Adapta es el encargado de ejecutar la invocación del servicio requerido y en caso de producirse una excepción porque el servicio no esté disponible, este método buscará todos los servicios ofrecidos por el componete usando técnicas de reflexión y para cada uno de ellos intentará comprobar que el servicio solicitado es reemplazable por el nuevo servicio. Esto será posible gracias a la base de conocimiento sobre el dominio que se incorpora via OWL y al motor de inferencia lógica proporcionado por P#. De esta manera, el código resultante para la adpatación es: private object Adapta(object server, string method,

object[]param) { . . .


422

try { MethodInfo m = ServerType.GetMethod(method,

typeParam); return m.Invoke(server,param); } catch (Exception) { SymbolTerm C = SymbolTerm.MakeSymbol(

"calculadora"); SymbolTerm S1 = SymbolTerm.MakeSymbol(

method.ToLower()); ListTerm P1 = lista_param(typeParam); foreach (MethodInfo m in

serverType.GetMethods()) { SymbolTerm S2 = SymbolTerm.MakeSymbol(

m.Name.ToLower()); ListTerm P2; bool ok;

. . . P2 = lista_param(typeParam2); sharp.SetPredicate( new

Can_Be_Replaced_6( C,S1,P1,C,S2, P2,new ReturnCs(sharp)));

ok = sharp.Call(); if (ok) { return m.Invoke(server,param); } } } return null; } El código anteriormente mostrado lo que fundamentalmente realiza es intentar invocar el servicio y en el caso de que se produzca la excepción porque el servicio no está disponible, obtiene via reflexión todos los servicios disponibles en el componente e intenta unificar la llamada realizada con los servicios ofrecidos a travez del motor prolog que nos proporciona P# y la ontología OWL traducida a hechos y ampliada con las reglas de reemplazo como puede verse en las regla y hechos de la suma que se muestran a continuación: owlClass(calculadora). owlClass(int). owlClass(double). sameAs(int,system_int32). owlSubClassOf(double,int). objectProperty(calculadora,suma,[int,int]).


423

equivalentProperty(suma,add). canBeReplaced(C1,S1,P1,C2,S2,P2):- owlClass(C1),

canBeReplacedClass(C1,C2), objectProperty(C1,S1,P1), canBeReplacedProperty(S1,S2), equivalentParam(P1,P2).

Como podemos ver en la regla anterior, podemos reemplazar una llamada a un servicio S1 sobre una clase C1 que actúa como servidor y con una lista de parámetros P1 cuando las clases son reemplazabes, los servicios son reemplazables y los parámetros son equivalentes.

canBeReplacedClass(C,C). canBeReplacedClass(C1,C2):- sameAsReflexiva(C1,C2). canBeReplacedClass(C1,C2):- owlSubClassOf(C2,C1). canBeReplacedClass(C1,C2):- equivalentClassReflexiva

(C1,C2).

Como podemos ver en las reglas anteriores, podemos reemplazar una clase puede ser reemplazada por si misma, por una subclase o por otra que sea equivalente.

canBeReplacedProperty(S,S). canBeReplacedProperty(S1,S2):- sameAsReflexiva(S1,S2). canBeReplacedProperty(S1,S2):equivalentPropertyReflexiva

(S1 ,S2). Como podemos ver en las reglas anteriores, podemos reemplazar un servicio por otro que sea equivalente.

equivalentParam([],[]). equivalentParam([X|R1],[X|R2]) :- owlClass(X),

equivalentParam(R1,R2). equivalentParam([X|R1],[Y|R2]) :- owlClass(X),

owlClass(Y), canBeReplacedClass(X,Y), equivalentParam(R1,R2).

Como podemos ver en las reglas anteriores, podemos reemplazar una clase puede ser reemplazada por si misma, por una subclase o por otra que sea equivalente.

7 Conclusiones y Trabajos futuros

En este trabajo hemos presentado los Perfiles UML como un mecanismo muy ade-cuado para la definición de lenguajes específicos de dominio cuya semántica sea una extensión de la de UML, y en concreto, hemos utilizado dicha técnica para la defini-ción del metamodelo que representa un componente capaz de adaptarse de forma


424

automática a cambios producidos en la interfaz de alguno de los componentes que le proveen servicios. Dicho uso de los perfiles de UML ya se emplean para la generación de implementa-ciones de modelos para plataformas específicas como CORBA o EJB. Como trabajos futuros nos proponemos la incorporación de la herramienta de genera-ción de código a alguna de las herramientas de diseño de arquitecturas. Una posibili-dad muy interesante, ya que todo el desarrollo y los ejemplos realizados hasta el mo-mento sería ver su posible integración con Microsoft® Visual Studio® 2005 Team System. Otra línea de trabajo futuro cara a la optimización y fundamentalmente a la eficiencia de la adaptación y basándonos en la idea que tras producirse una adaptación esta tiende a ser más usada que la versión anterior, una posibilidad que ofrece la tecnolo-gía NET, sería genera, compilar y cargar en memoria una nueva versión del Proxy en la que la llamada “correcta” sea la producida por la adaptación para así evitar la unifi-cación cada vez que se realice la llamada al correspondiente servicio.

Referencias

1. Booch G. Object-Oriented Analysis and Design with Applications, 2nd edition.

Addison-Wesley Object Technology Series, February 1994. ISBN: 0805353402. Edición española: Análisis y diseño orientado a objetos con aplicaciones, segunda edición. Addison-Wesley / Díaz de Santos, 1996. ISBN: 0-201-60122-2

2. Heckel R., Lohmann M., Thöne S. Towards a UML Profile for Service-Oriented Architectures. http://www.hwswworld.com/downloads/9_28_05_e/MDAFA-2003-FinalVersion.pdf

3. ISO/IEC. Unified Modeling Language (UML). Version 1.5. International Standard ISO/IEC 19501.

4. Jacobson I., Booch G ., Rumbaugh J. The Unified Software Development Process. Addison-Wesley, enero de 1999. ISBN: 0201571692.

5. Fuentes L., Vallecillo A. y Troya J.M.. Using UML Profiles for Documenting Web-Based Application Frameworks. Annals of Software Engineering, 13:249–264, 2002.

6. Ketfi A., Noureddine B., Pierre-Yves C. Dynamic updating of component-based applications. SERP'02, Las Vegas, Nevada, USA, 2002.

7. Object Management Group. UML 2.0 Infrastructure Specification, OMG document ptc/03-09-15, 2003.

8. Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorenson W. Object-Oriented Modelling and Design. Prentice Hall, enero de 1991. ISBN: 0136298419.

9. W3C Recommendation, OWL Web Ontology Language. Use Cases and Requirements, http://www.w3.org/TR/2004/REC-webont-req-20040210/.


425

http://kuainasi.ciens.ucv.ve/ideas07/evetis07

Primer Encuentro Venezolano sobre Tecnologías de Información e

Ingeniería de Software

427

Coordinadores EVETIS'07

Luis Eduardo Mendoza Universidad Simón Bolívar Departamento de Procesos y Sistemas Laboratorio de Investigación en Sistemas de Información (LISI)

Isabel Díaz Universidad Central de Venezuela Facultad de Ciencias Económicas y Sociales – Escuela de Economía Facultad de Ciencias – Escuela de Computación – Laboratorio TOOLS

Ledis Chirinos Universidad Central de Venezuela Facultad de Ciencias – Escuela de Computación – Laboratorio TOOLS


428

Comité de Programa

Luis Eduardo Mendoza Universidad Simón Bolívar Departamento de Procesos y Sistemas Laboratorio de Investigación en Sistemas de Información (LISI)

Isabel Díaz Universidad Central de Venezuela Facultad de Ciencias Económicas y Sociales – Escuela de Economía Facultad de Ciencias – Escuela de Computación – Laboratorio TOOLS

Revisores

(1) Ana Mercedes Díaz - Universidad Centroccidental Lisandro Alvarado (2) Anna Grimán - Universidad Simón Bolívar (3) Dinarle Ortega - Universidad de Carabobo (4) Edgar González - Universidad Centroccidental Lisandro Alvarado (5) Edumilis Méndez - Universidad Simón Bolívar (6) Francisca Grimón - Universidad de Carabobo (7) Hyxia Villegas - Universidad de Carabobo (8) Isabel Besembel - Universidad de Los Andes (9) Isabel Díaz - Universidad Central de Venezuela

(10) Jonás Montilva - Universidad de Los Andes (11) José Gregorio Sánchez - Universidad Centroccidental Lisandro Alvarado (12) Kenyer Domínguez - Universidad Simón Bolívar (13) Lourdes Ortiz - Universidad Católica Andrés Bello (14) Luis E. Mendoza - Universidad Simón Bolívar (15) María Gertrudis López - Universidad Central de Venezuela (16) Maryoly Ortega - Universidad Simón Bolívar (17) Pedro Castillejo - Universidad Católica Andrés Bello (18) Ramón Valera - Universidad Centroccidental Lisandro Alvarado (19) Reina Loaiza - Universidad de Carabobo (20) Rodolfo Canelón - Universidad Centroccidental Lisandro Alvarado (21) Teresita Rojas - Universidad Simón Bolívar


429

Acerca de EVETIS En el marco del X Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software se celebra el primer Encuentro Venezolano sobre Tecnologías de Información e Ingeniería de Software: EVETIS'07. Este evento nace con el objetivo de ofrecer a la comunidad científica y empresarial del país un espacio para la comunicación de resultados, intercambio de opiniones, definición de nuevos proyectos y colaboraciones en materia de Ingeniería de Software y Tecnologías de Información. La realización de EVETIS'07 como una actividad de IDEAS'07 se ha constituido en una excelente oportunidad para mostrar a los visitantes iberoamericanos algunas de las actividades de investigación, desarrollo e innovación que se adelantan en Venezuela y estrechar vínculos de cooperación con ellos. En las próximas páginas se presentan 18 trabajos seleccionados después de un proceso de revisión realizado por un equipo de profesores de distintas universidades venezolanas. Los artículos fueron propuestos y revisados in extenso. En este proceso se han valorado altamente aquellas contribuciones que ponen en evidencia el importante rol que cumple la Ingeniería de Software en el desarrollo de las Tecnologías de Información, resaltando la articulación entre estas dos importantes áreas del conocimiento. Para la presentación de los artículos se escogió la modalidad de carteles. Los temas centrales de los artículos seleccionados son diversos, entre otros: telemedicina, software libre, comunidades virtuales, aspectos y calidad de software, herramientas de desarrollo de sistemas, gestión de datos, aplicaciones Web, ontologías, agentes y gestión de recursos, integración de sistemas, simulación, sistemas dinámicos, educación a distancia, gestión de proyectos. Especial reconocimiento debe hacerse tanto a los autores como a los profesores que participaron en el proceso de revisión, sin cuya colaboración no hubiera sido posible lograr esta primera recopilación de trabajos. Esperamos que el esfuerzo realizado contenga el impulso suficiente para que esta iniciativa se mantenga y mejore en el tiempo, constituyéndose en un futuro próximo en un evento de relevancia nacional por su contribución al desarrollo tecnológico como camino al bienestar social de Venezuela.

Isabel Díaz López Luis Eduardo Mendoza

Mayo, 2007


431

Lista de Trabajos La Industria de Software en Venezuela: Una Caracterización de su Recurso Humano ………………………………….………..

435

Dulce Rivero, Jonás Montilva, Gladys Granados, Judith Barrios, Isabel Besembel, Beatriz Sandia Universidad de Los Andes

La Fiabilidad y los Requisitos de Software bajo la Perspectiva de la Orientación a Aspectos …………………………………………….…

444

Isi Castillo1-2, Francisca Losavio2, Alfredo Matteo2, Rafael Caldera2 1 Universidad Nacional Experimental Sur del Lago "Jesús María Semprum" 2 Universidad Central de Venezuela

Chamaéleon. Prototipo que Unifica Patrones de Diseño de Interfaces en Sitios Web ………………………………………..

451 Gladys Benigni, Manuel Pérez, Justo Marcano Universidad de Oriente (Núcleo Nueva Esparta)

Modelo de Integración de Sistemas en Empresas Venezolanas: Estudios de Caso .....................................................................................................

457 Irina Titaeva, Luis E. Mendoza, María Pérez Universidad Simón Bolívar

Hacia un Sistema de Información para Apoyar la Gestión de la Educación a Distancia ………………………..………………

465 Luis Ramos1, Richard Gil2 1Universidad Nacional Abierta 2Universidad Simón Bolívar

Diseño de un Sistema Multiagente para la Gestión de Recursos usando la Metodología MAS CommonKads …………………………………………….

472

Juan F. Serrano, Rina Suros Universidad Central de Venezuela

Estado del Arte sobre el uso del LDAP como Estructura Alternativa para regular Infraestructuras de Clave Pública (PKI) en Ambientes Empresariales …………….....

480

Gabriel Moline, John Delgado Fundación Instituto de Ingeniería, Ministerio del Poder Popular para Ciencia y Tecnología

Un Meta-Proceso para el Desarrollo de Proyectos de Tecnología de Información en Petróleos de Venezuela …………...……………….…

487 Lenis Malavé, Derlys Hernández, Cruz Erlinda Herrera Dirección de Automatización, Informática y Telecomunicaciones, Petróleos de Venezuela S.A.

ULAnux/ULAnix: Software Académico a la Medida .................................................. 495 Jesús Molina, Gilberto Diaz, Joskally Carrero, Jacinto Dávila Universidad de Los Andes


433

Lector de Historias Clínicas Electrónicas codificadas en el Estándar Health Level 7/Clinical Document Architecture para su Aplicación en Servicios de Telemedicina ………………………………….….

502

Edgar Lugo, Hyxia Villegas, Rafael Pacheco, Ángel Villegas Universidad de Carabobo

Una Caracterización de Herramientas MDA de Código Abierto …………………….. 509 Juan Carlos Herrera, Alfredo Matteo, Isabel Díaz Universidad Central de Venezuela

Análisis de Características (Modo Preselección) para Evaluar Plataformas de Componentes …………………………………………………..

517 Merizeh Mijares, Aleksander González, Luis E. Mendoza, María Pérez, Anna Grimán Universidad Simón Bolívar

Fábrica de Software Libre: sirviendo al Bienestar Colectivo …………………………. 524 José Aguilar1, Oswaldo Terán1-2, Johanna Álvarez1, Blanca Abraham1 1Fundación para el Desarrollo de la Ciencia y Tecnología del Estado Mérida 2Universidad de Los Andes

Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología …………...………………………………….

532 Lorner A. Rivas1-2, María Pérez2, Luis E. Mendoza2, Anna Grimán2 1Instituto Nacional de Investigaciones Agrícolas 2Universidad Simón Bolívar

Comunidades Virtuales centradas en Usabilidad y Sociabilidad …………………… 539 Boris Guevara, Jean Carlos Guzmán, Nancy Zambrano Universidad Central de Venezuela

Herramienta para la Evaluación de Proyectos de Outsourcing de TI basada en Factores Críticos de Éxito …………………………………………………….

546 Edumili Méndez, María Pérez, Luis E. Mendoza Universidad Simón Bolívar

Simulando Dinámicas de Integración Regional ……………………………………….. 553 Sary Levy-Carciente1, Tirso Palm1, María de la Fé López 2 1Universidad Central de Venezuela 2Universidad Simón Bolívar

HYPERQBIX: Sistema de Indicadores de Gestión de Calidad para DBAccess STP (Software Technology Park), C.A. …………………………………………

560 Gladys Benigni, María González Universidad de Oriente (Núcleo Nueva Esparta)


434

La Industria de Software en Venezuela: Una Caracterización de su Recurso Humano

Dulce Rivero1, Jonás Montilva1, Gladys Granados2, Judith Barrios1, Isabel Besembel1 y Beatriz Sandia3

Universidad de Los Andes, Facultad de Ingeniería

1 Grupo de Investigación en Ingeniería de Datos y Conocimiento (GIDyC) 2 Centro de Excelencia en Ingeniería de Software (CEISoft)

3 Coordinación de Estudios Interactivos a Distancia (CEIDIS) {milagro, jonas, ijudith, ibc, [email protected]}, [email protected]

Resumen. El presente trabajo muestra un panorama del estado actual de la industria del software en Venezuela (INS), destacando los aspectos de formación y capacitación del personal, como dos de los factores claves para el alcance de los estándares de calidad del software, estándares que son requeridos para competir en los mercados nacional e internacional. En este artículo, se presentan los resultados de un sondeo realizado con la finalidad de apreciar la formación académica que el personal de la INS tiene actualmente, para luego definir las necesidades de capacitación y/o actualización profesional que dicha industria requiere satisfacer en el corto y mediano plazo.

1 Introducción

El término “Industria Nacional del Software - INS” se utiliza, para referirse al conjunto de empresas radicadas en nuestro país que se dedican expresamente al desarrollo, mantenimiento y comercialización de productos de software para terceros. Un porcentaje de estas empresas compite en el mercado nacional e internacional ofreciendo sus servicios de desarrollo y mantenimiento. La decisión de cual es la empresa más capacitada o apropiada para el desarrollo de una aplicación depende de varios factores, entre los más relevantes están: (1) el nivel de formación de sus recursos humanos; (2) el grado de competencia que estos recursos tienen para desarrollar productos de software; y (3) la madurez que tiene la empresa en función de los procesos de desarrollo que ella utiliza. Por ello, si la empresa tiene como visión ser altamente competitiva, es necesario que sus recursos humanos estén muy bien capacitados; pues, ello incide directamente en la mejora de sus procesos internos.


435

Un punto importante de esta investigación consistió en responder la siguiente interrogante: ¿Qué es un recurso humano bien capacitado? De forma resumida, puede decirse que es un profesional competente y que, por lo tanto, conoce los aspectos teórico-conceptuales y utiliza con habilidad las técnicas, modelos, métodos y herramientas necesarias para realizar las tareas de su área de ejercicio profesional. Particularmente, un profesional de la Ingeniería de Software tiene, por un lado, conocimientos de los aspectos teóricos, conceptuales y metodológicos de la Ingeniería de Software y, por el otro, posee habilidades y destrezas en la aplicación de métodos, técnicas, modelos, prácticas y herramientas propias de su área de trabajo. Esta definición es consistente con aquellas expresadas por Ford y Gibbs [1], Parnas [2] y Shaw [3].

A partir de la respuesta anterior, nos preguntamos luego: ¿Están los recursos humanos de la INS en Venezuela bien capacitados? Para responder esta interrogante, buscamos información sobre los niveles de formación de los recursos humanos de la INS, se encontró que no existen ni datos ni estudios que permitan conocer cual es la situación actual. Es decir, no se tiene información acerca del nivel de formación, las debilidades y las carencias del recurso humano empleado por la INS.

Esta información es indispensable, ya que, por un lado, ayuda a tener una apreciación general del estado actual del recurso humano de esta industria y, por el otro, tener una idea clara de hacia donde se orienta dicha industria. El primero de estos dos aspectos permite detectar las condiciones actuales del recurso humano. Mientras que, el segundo facilita la definición de los perfiles profesionales que la INS requiere en el corto o mediano plazo, para elevar su competitividad y la calidad de sus productos. A fin de medir estos aspectos, se hizo necesario plantearse los siguientes objetivos [4]: 1. Identificar los procesos que ejecutan actualmente las empresas de la INS para

desarrollar sus productos de software. 2. Determinar el estado actual de formación del recurso humano empleado en la INS para

desarrollar software. 3. Establecer las necesidades de capacitación o actualización profesional que la INS

estima conveniente para mejorar sus procesos de desarrollo. El Modelo Integrado de Capacidad y Madurez – CMMI establece que la calidad de un

producto va asociada a la calidad del proceso que se sigue para producirlo [5]. Una parte importante de este trabajo de investigación estuvo dirigido a identificar los métodos y/o modelos de procesos que se emplean actualmente para desarrollar productos de software. La otra parte se concentró en el establecimiento del nivel de formación académica que tiene actualmente el personal de la INS. La medición y asociación de estos dos aspectos, nos permitió estimar la capacidad que la INS tiene para desarrollar software de alta calidad, así como, las necesidades de capacitación y/o actualización profesional que esta industria requiere satisfacer en el corto y mediano plazo.

Este trabajo está organizado de la siguiente manera: En la sección dos se presentan los métodos y técnicas empleados para la recolección y análisis de los datos de la investigación; en la sección tres se muestran las estadísticas y resultados obtenidos; y en la sección cuatro, se concluye la situación actual y se establecen las necesidades de formación prioritarias para la INS.


436

2 Métodos y Técnicas Empleadas en el Diagnóstico de la INS

Para diagnosticar la situación actual del recurso humano de la INS, es necesario contar con un conjunto de datos que puedan ser analizados a fin de obtener la información requerida. En general, existen dos maneras de realizar diagnósticos: una de ellas es la recopilación de datos a través de informes existentes y/o publicaciones; la segunda es la recolección de datos por medio de encuestas [6]. Dado que no se encontraron estudios similares al aquí reportado, que muestren la situación actual del recurso humano de la INS, fue necesario realizar una serie de actividades que condujeron a la recolección de estos datos, mediante encuestas realizadas a un grupo de empresas de la INS seleccionado al azar a través de un muestreo.

Como todo sondeo de opinión, es importante seguir un proceso que permita realizar de forma organizada la captura y análisis de datos [7; 6]. Para ello, se diseñó y ejecutó el proceso ilustrado en la Fig. 1, mediante un diagrama de clases en UML. Este proceso está compuesto de un conjunto estructurado de pasos y actividades.

Diagnóstico deNecesidades de

Formación

<<process>>

Definición deObjetivos delDiagnóstico

<<process>>

Diseño de losInstrumentos de

Medición

<<process>>Reprogramaciónde las actividades

de medición

<<process>>

Levantamiento deDatos

<<process>>

Selección deMétodos y Técnicas

del Diagnóstico

<<process>>

Análisis de Datos<<process>>

Organización dedatos

<<process>>

Elaboración delInforme

<<process>>Medición de las

Necesidades

<<process>>Visitas a

empresasselectas

<<process>>Elaboración deDirectorio deEmpresas INS

<<process>>Planificación del

Diagnóstico

<<process>>

Definición deactividades del

Diagnóstico

<<process>>

Fig. 1. Proceso de Diagnóstico de Necesidades.

El orden en que se describe cada uno de los procesos no indica necesariamente el orden es que se realizaron; pues, muchas de ellas se ejecutaron en paralelo o simultáneamente. 1. Planificación del Diagnóstico.- Se definieron, primero, los objetivos específicos del

diagnóstico de necesidades. Luego, se definieron sus actividades detalladas y se elaboró el cronograma de trabajo.

2. Elaboración del Directorio de Empresas INS.- A partir de directorios de empresas TIC, tales como los de EXPORTIC, InVeSoft, Cavedatos y la Cámara Venezolana de Software Libre (AVESOL), se elaboró el Directorio de Empresas INS que se utilizó para el diagnóstico. Este directorio contenía, para el momento en que se hizo el diagnóstico, un total de 150 empresas.

3. Selección de Métodos y Técnicas para el Diagnóstico.- Se seleccionó, en principio, el cuestionario como instrumento principal para realizar el diagnóstico. Sin embargo,


437

debido a que un número muy bajo de empresas (sólo 10 de las 150 contenidas en el directorio) respondieron el cuestionario, se optó por realizar adicionalmente entrevistas bajo dos modalidades: contacto telefónico/e-mail y visitas a empresas.

4. Medición de las Necesidades.- Una vez definidas las técnicas que se emplearían en la elaboración del diagnóstico, se ejecutó el siguiente conjunto de actividades: • Diseño del instrumento de medición.- El instrumento utilizado para la medición

fue un cuestionario elaborado en EXCEL enviado, vía correo electrónico, a gerentes o representantes de empresas INS. El diseño del instrumento se basó en el análisis de diferentes parámetros de evaluación de una empresa. En base a estos parámetros, se definieron diferentes facetas y para cada una de estas se elaboró un conjunto de preguntas. Los parámetros seleccionados fueron los siguientes: Datos básicos de la empresa, Productos y procesos de software, y Recursos humanos.

• Selección de la muestra.- En vista de la baja respuesta obtenida a través de los cuestionarios, se optó por realizar entrevistas y contactos, vía telefónica o por e-mail, a una muestra más reducida de empresas. Se colocó el cuestionario en un sitio web que facilitó su acceso a cada una de las empresas seleccionadas. Para el cálculo del tamaño de esta muestra, se utilizó el método de muestreo descrito por Kendal y Kendal [8] y el estimador en línea disponible en http://www.ksrinc.com/tools/moe.asp. Se estableció un nivel de confianza del 95%, un nivel de error (incertidumbre) del 7.5% y un tamaño poblacional de 150 empresas. Se obtuvo un tamaño de la muestra a encuestar de 76 empresas.

• Levantamiento de datos.- Las 76 empresas seleccionadas fueron contactadas. De este total, se entrevistaron directamente a 12 empresas y se contactaron vía telefónica y correo electrónico a un total de 28 empresas, las cuales junto con los 10 cuestionarios recibidos inicialmente conforman un total de 50 encuestas. Dado que este número es inferior al de la muestra, se recalculó el tamaño del error de muestreo. Se obtuvo que para una muestra de 150 empresas, un nivel de confianza del 95% y un tamaño de muestra de 50, el error que se maneja es del 11.32%.

• Organización de los datos recolectados.- Los datos de las encuestas se almacenaron en un archivo EXCEL a fin de procesarlos electrónicamente.

• Análisis de los datos.- Se analizó cada una de las preguntas del cuestionario. Los resultados de este análisis se presentan en la Sección 3.

5. Visita a empresas selectas.- Se visitaron varias empresas INS ubicadas en las principales ciudades del país. Las razones de estas visitas fueron: (1) recolectar directamente los datos de la encuesta; y (2) observar de cerca el modo en que estas empresas desarrollan sus productos de software.

3 Resultados Obtenidos

La información recabada a través de la encuesta permitió analizar los cuatros aspectos inherentes a la INS que fueron considerados en el diagnóstico. Estos son: Las


438

características generales de las empresas INS, los productos y procesos de software que ellas desarrollan, los recursos humanos que emplean y las necesidades de actualización profesional que ellas consideran necesarias para mejorar sus procesos y productos.

3.1 Características Generales de las Empresas INS

Con el objeto de establecer mejor el contexto productivo y comercial, dentro del cual se desarrolla software en nuestro país, se definieron y analizaron varias de sus características generales, a saber: el tamaño de la empresa (definida como el número de empleados), la antigüedad de la empresa, el alcance de su mercado y el tipo de licencia de sus productos.

3.1.1. El Tamaño de la Empresa INS. Para estimar el tamaño promedio de las empresas, se utilizó una clasificación típica que divide a las empresas, de acuerdo al número total de empleados esta clasificación emplea siete grupos: Individual, Microempresa (2-5 empleados), Empresa Muy Pequeña (6-10) Pequeña (11-50), Mediana (51-100), Grande (1001- 500) y Muy Grandes (>500). De acuerdo con los datos obtenidos, el 83,68% de la INS está compuesto por empresas que tienen menos de 51 empleados y que van desde microempresas hasta empresas pequeñas. El estrato principal está constituido por empresas pequeñas (42,86%), es decir, aquellas que tienen entre 11 y 50 empleados.

3.1.2 Antigüedad de las Empresas. La INS es una industria muy joven, el 74% de las empresas encuestadas tienen en el mercado entre 1 y 12 años, mientras el resto (26%) tienen más de doce años como empresas constituidas. Al combinar el tamaño de la empresa con su antigüedad, se obtuvo que el 42% de las empresas pequeñas (menos de 51 empleados) del país fueron creadas en los últimos 7 años. Las empresas de más de siete años tienden a tener mayor número de empleados (entre 11 y 500 empleados).

3.1.3 Alcance del Mercado que Cubren las Empresas. El 33% de las empresas hacen exportación de productos y servicios de software. Este grupo, también, vende sus productos en el mercado nacional. El 67% restante sólo coloca sus productos a nivel nacional y/o local. Estas cifras constituyen un indicador de la importancia que tiene, para la INS, el seguimiento de estándares internacionales y las certificaciones basadas en modelos tales como el CMMI [5] e ISO 9000 [9].

3.1.4 Modalidad de Licencia de Software de los Productos. En Venezuela, se está trabajando en varias modalidades de licenciamiento de los productos de software, que se corresponden con el cliente a quien está destinado el producto. El 48% de las empresas encuestadas usan licencias de varios tipos, mientras un 40% que trabajan exclusivamente con licencias de software propietario. El 13% restante trabajan sólo con licencias de software libre. Se reconoce, sin embargo, que en los meses posteriores a la realización de


439

la encuesta, la demanda de productos de software libre creció significativamente debido a la implantación del decreto nacional de software libre [10].

3.2 Resultados Relacionados con los Productos y Procesos de Software

Para conocer las características de los productos que elaboran las empresas INS y los procesos que ellas aplican, se elaboraron varias preguntas cuyos resultados se describen a continuación:

3.2.1 Tipos de Productos Elaborados. El 41% de las empresas encuestadas elabora aplicaciones de negocio o administrativas, el otro 59% elabora aplicaciones embebidas, industriales, software del sistema, aplicaciones científicas, software educativo, de entretenimiento y otros.

3.2.2 Asignación de Personal a los Procesos de Software. Dado que este estudio busca, entre otras cosas, identificar las áreas en las cuales la INS requiere mejorar las competencias de su recurso humano, es necesario conocer la distribución del personal. Es importante resaltar, que una persona puede desempeñar roles en una o más de las varias áreas funcionales. En las empresas más pequeñas un alto porcentaje del personal desempeñan roles en distintas áreas de proceso. Este porcentaje de dedicación disminuye en la medida que la empresa se hace más grande. En las empresas que tienen 50 o menos empleados, el número de personas dedicadas al área de codificación y mantenimiento de software oscila entre el 50% y el 80%; mientras que, en las empresas medianas o grandes se encuentra una distribución porcentual menor. En general, para todas las empresas encuestadas, se encontró que el área donde hay mayor porcentaje de personal dedicado es el área de codificación, seguido por el diseño y, luego, el de mantenimiento de software.

3.2.3 Uso de Modelos de Procesos en el Desarrollo de Software. Un indicador importante de la calidad de los productos de software es el uso de modelos de procesos y/o métodos de desarrollo de software maduros. Se preguntó, a las empresas encuestadas, si emplean algún modelo de procesos o método de desarrollo de software específico que oriente a sus grupos de desarrollo de procesos. De acuerdo a los datos obtenidos, el 93% de las empresas dice utilizar algún modelo de procesos o método de desarrollo en particular. El 51% dice emplear un modelo propio, es decir, han desarrollado su propio modelo de procesos o utilizan una mezcla de varios de los modelos conocidos. Sin embargo, se pudo detectar que muchas empresas que usan un modelo propio, por lo general, no tienen el modelo documentado a un nivel de detalle que facilite su uso corporativo. El 68% de la muestra señaló que no es obligatorio el uso de modelos de procesos en los proyectos, En este aspecto, se puede concluir que la mayoría de las empresas INS no están empleando modelos y métodos maduros en su proceso productivo, lo cual limita significativamente la calidad de los productos que estas empresas producen.


440

3.2.3 Uso de Modelos de Mejora de Procesos. La madurez y capacidad de una empresa de software para desarrollar productos de alta calidad se mide a través de modelos de mejoras, tales como los modelos CMMI (Capability Maturity Model Integration), SPICE, BOOTSTRAP, MOPROSOFT, etc. El modelo CMMI-SW del Instituto de Ingeniería de Software es el modelo empleado por la industria mundial del software, como un estándar de facto, en la evaluación de la capacidad y madurez que tienen estas empresas para desarrollar software de alta calidad [5]. De acuerdo a los resultados obtenidos, se concluye que sólo el 7% de las empresas consultadas usan el modelo CMMI. Los otros modelos no son conocidos o no son utilizados nacionalmente.

3.3. Resultados Relacionados con la Formación de los Recursos Humanos

Como parte de la investigación se indagó sobre la distribución del personal en las empresas de acuerdo a su nivel de educación formal. En este sentido, se pudo observar que la mayor parte de los empleados (75%) tienen una formación universitaria en Computación, Sistemas o Informática. Un 9% de todo el personal tiene estudios de maestría o doctorado. Al establecer una relación entre el tamaño de las empresas con el nivel de formación académica del personal que ellas contratan, se pudo observar que las empresas con más de 10 empleados tienden a contratar principalmente profesionales universitarios en el área de Informática o carreras afines; mientras que, en las empresas más pequeñas (≤10 empleados) se nota un equilibrio mayor en el empleo de personal técnico superior y graduado universitario.

3.4 Necesidades de Actualización Profesional. Uno de los objetivos de este diagnóstico fue determinar las necesidades de actualización profesional que las empresas INS tienen actualmente. Para medir estas necesidades, se agruparon las áreas de conocimiento de la Ingeniería de Software, en base a procesos y tecnologías, en tres grandes grupos: • Procesos de gestión y soporte.- Agrupa a las áreas de conocimiento relacionadas con

los procesos de gestión de proyectos y los procesos de soporte. • Procesos técnicos.- Cubre las áreas de conocimiento vinculadas al desarrollo y

mantenimiento de software. • Tecnologías de software.- Incluyen las tecnologías empleadas en el desarrollo de

software, tales como: lenguajes de programación, de modelado, sistemas de gestión de bases de datos y plataformas de desarrollo. De acuerdo a los datos obtenidos, las mayores necesidades de actualización

profesional, que tienen las empresas INS, están en las áreas Gerencia de Proyectos de Software, Gestión de la Calidad (SQA) y Gestión de Procesos de Software.

3.4.1 Necesidades de Actualización Profesional en Procesos Técnicos de Software. Las principales necesidades de actualización profesional que fueron detectadas están en los procesos de Requisitos de Software, seguido por el Diseño de Arquitecturas de Software. Con un porcentaje menor, pero aún por encima del 50%, las áreas de Diseño de


441

Componentes de Software y las Pruebas de Software son áreas en las que las empresas requieren mejorar la formación de su personal.

3.4.2 Necesidades de Actualización Profesional en Tecnologías de Software. En relación a la necesidad de actualización profesional, se tiene que más del 40% de las empresas encuestadas consideran que tienen necesidades de capacitación en lenguajes específicos como PHP y JAVA. En relación a las plataformas de desarrollo de software se observó que J2EE y .NET son las plataformas donde hay mayor necesidad de actualización profesional. Con respecto a otras tecnologías de desarrollo de software, Postgres y MySQL son los sistemas de gestión de bases de datos en los que se requiere una mayor actualización del personal. En lo que respecta a lenguajes de modelado de software, la mayoría de las empresas encuestadas consideran que su personal necesita capacitación en UML (Unified Modeling Language) y BPMN (Business Process Modeling Notation).

4 Conclusiones

Los resultados presentados en este informe constituyen un aporte fundamental para la INS; pues, permite a los diferentes actores de esta industria tener una apreciación general del estado en que ella se encuentra y de la situación actual de sus recursos humanos.

Así mismo, se puede concluir, que la INS es un sector importante de la economía nacional que está en pleno proceso de desarrollo y que, como tal, adolece, en la mayoría de los casos, de la madurez necesaria para producir software con los altos niveles de calidad exigidos internacionalmente y evaluados mediante modelos de mejoras tales como el CMMI y SPICE. Un porcentaje muy pequeño de las empresas encuestadas podría calificar para alcanzar, en este momento, el nivel 2 del modelo CMMI, lo cual es importante y prioritario para alcanzar competitividad internacional.

Aún cuando un alto porcentaje de empresas INS siguen métodos o modelos de procesos especializados y/o estándares, ellos no son usados de manera institucionalizada (obligatoria para todos los grupos) y menos aún son gestionados y medidos con la finalidad de mejorarlos. Además, la gestión de proyectos realizada en la mayoría de empresas INS no es una actividad rutinaria o cotidiana y las técnicas, herramientas y estándares asociados a los procesos de apoyo al desarrollo, tales como el aseguramiento de calidad y la gestión de configuración, son casi desconocidas por un alto porcentaje de empresas de la INS.

Para poder competir en los mercados internacionales, la INS debe subsanar las debilidades detectadas en sus recursos humanos, procesos y productos. La actualización profesional es uno de los caminos que puede contribuir a mejorar las competencias del recurso humano y puede incidir, indirectamente, en la mejora de los procesos y productos de software que produce esta industria. Esta actualización debe estar fundamentada en estándares, lineamientos y cuerpos de conocimientos reconocidos, talos como aquellos


442

descritos en [11], [12] y [3]. Finalmente, es importante mencionar que el error de muestreo obtenido en esta

investigación, es del 11.31%. Este indicador establece que la diferencia máxima entre los resultados obtenidos y los que se obtendrían al entrevistar toda la población es de 11.32%. Aunque este error está por encima del acostumbrado en estudios estadísticos más completos (generalmente, 5 – 8 %), los resultados obtenidos permiten tener una apreciación bastante confiable del estado actual de la INS, por cuanto su margen de error del 5% establece una baja probabilidad de que lo afirmado sea incorrecto.

Agradecimiento. La realización del trabajo fue financiada por el Fondo Nacional de Ciencia, Tecnología e Innovación (FONACIT) bajo el Proyecto de Innovación y Transferencia Número 2001003171 y el Programa ADG del CDCHT de la Universidad de Los Andes asignado al Grupo de Investigación en Ingeniería de Datos y Conocimiento (GIDyC).

Referencias

1. Ford, G. and Gibbs, N.E. A Mature Profession of Software Engineering. Technical Report CMU/SEI-96-TR-004. Software Engineering Institute, USA, January, 1996.

2. Parnas, D. Software Engineering Programs are not Computer Science Programs. IEEE Software, November/December, 1999. pp. 19-30.

3. Shaw, M. Software Engineering Education: A Roadmap. In Finkelstein, A. (Ed.), The Future of Software Engineering". ACM Press, 2000

4. Proyecto: Programa de Formación Profesional para el Desarrollo de la Industria Nacional del Software. Propuesta técnica. Universidad de Los Andes, Facultad de Ingeniería, Escuela de Ingeniería de Sistemas, Departamento de Computación, Grupo de Investigación en Ingeniería de Datos y Conocimiento (GIDyC), Mérida. Junio, 2005.

5. Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Software Engineering. Technical Report # CMU/SEI-2001-TR-029. Carnegie Melon University, Software Engineering Institute. August, 2002.

6. Martinez M., V. Diseño de encuestas de opinión. Paracuellos de Jarama, Madrid, 2003. 7. Frey, J. Survey research by telephone. Sage, Londres. 1989. 8. Kendal, K. y Kendal, J. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Educación,

México, 2005. 9. Schmauch, Ch. ISO 9000 for Software Developers. ASQC Quality Press, Wisconsin, 1995. 10. Decreto No. 3390. Gaceta oficial No. 38.095. República Bolivariana de Venezuela. 28/12/2004. 11. The Joint Task Force on Computing Curricula IEEE/ACM. Software Engineering 2004.

Curriculum Guidelines for Undergraduates Degree Programs in Software Engineering. August, 2004.

12. IEEE. Guide to the Software Engineering Body of Knowledge SWEBOK, 2004 Version. IEEE Computer Society, Professional Practices Committee. June, 2004.


443

La Fiabilidad y los Requisitos de Software bajo la Perspectiva de la Orientación a Aspectos

Isi Castillo1,2, Francisca Losavio2, Alfredo Matteo2, Rafael Caldera2

1 Universidad Nacional Experimental Sur del Lago “Jesús María Semprum”

2 Centro ISYS, Universidad Central de Venezuela {castilloi, flosav, almatteo, rjcaldera}@cantv.net

Resumen. Los sistemas fiables son aquellos sistemas capaces de entregar entre ciertos límites un servicio que ha sido previamente acordado; están basados en la fiabilidad, concepto que involucra a las características de calidad disponibilidad, confiabilidad, seguridad, integridad y flexibilidad a efectuar cambios (“maintainability”). Estas características por lo general se asocian a los requisitos no funcionales y pueden ser tratados bajo el paradigma de la Orientación a Aspectos (OA), debido a que cada una representa una incumbencia o “concern”. El objetivo de este trabajo es modelar conceptualmente los elementos principales utilizados en el dominio de los sistemas fiables y establecer la correspondencia entre el concepto de fiabilidad, el paradigma de la OA, los requisitos del software y sus propiedades de calidad, permitiendo identificar y tratar los aspectos de fiabilidad desde las etapas iniciales del ciclo de vida. El modelo constituye una herramienta útil para iniciar una ontología dentro del área de los sistemas fiables orientada a aspectos, permite dar soporte a la emergente disciplina de la ingeniería de requisitos orientada a aspectos en el dominio de los sistemas fiables.

Palabras Clave: fiabilidad, enfoque orientado a aspectos, requisitos de software, calidad de software, modelación.

1 Introducción

La construcción de sistemas altamente confiables se ha convertido en un gran reto para la industria del software. En la actualidad se hacen necesarias mejores tecnologías y formalismos para especificar y manejar la fiabilidad. Estas deben ser más acordes con las complejidades técnicas propias de este tipo de sistemas, en los cuales debe evitarse al máximo la ocurrencia de fallas, faltas y errores; por otra parte estos sistemas deben responder a cambios en su entorno y en los requisitos de los usuarios. Durante el desarrollo de los sistemas de software, resulta de gran importancia el manejo de un conocimiento claro y preciso sobre los principales elementos conceptuales asociados al dominio del sistema. En diversas ocasiones, los miembros de los equipos de investigación y desarrollo experimentan serias deficiencias en el manejo de los términos relacionados con el producto de software ha obtener; dificultando la adecuada implementación de los requisitos exigidos


444

por el producto. Estas debilidades han despertado el interés en las comunidades de investigadores por buscar herramientas que faciliten la comprensión del dominio de cada tipo de sistema. Dentro del contexto de este trabajo este interés se ha evidenciado en los intentos presentados en 3,4,5,14,16 para definir términos comunes dentro del ámbito de los sistemas fiables y los requisitos de software.

Las prácticas de desarrollo de software actuales solo tienden a consideran los requisitos funcionales desde las primeras etapas del ciclo de vida de los productos de software, relegando los no funcionales a etapas tardías del desarrollo, causando enmarañamiento de código y dificultando el mantenimiento. El objetivo de este trabajo es modelar conceptualmente los elementos principales utilizados en el dominio de los sistemas de alta confiabilidad y establecer la correspondencia entre el concepto de fiabilidad, el paradigma de la OA, los requisitos de software (funcionales y no funcionales) y sus propiedades de calidad, permitiendo identificar y tratar los aspectos de fiabilidad desde las etapas iniciales del ciclo de vida. La identificación, comprensión y la importancia de la correcta y precisa especificación de los requisitos, se incrementa drásticamente con la magnitud y complejidad de los sistemas de software, particularmente si estos tienen que responder a exigencias que van más allá del alcance de sus funcionalidades principales. Estas exigencias deben ser identificadas temprano y consideradas oportunamente por los profesionales del software, en el desarrollo de sus aplicaciones y han enfocado la atención de la comunidad de investigadores hacia la disciplina de la ingeniería de requisitos, en particular hacia una ingeniería de requisitos de calidad, en la cual se destaca explícitamente el tratamiento dado a los requisitos no funcionales.

Este artículo está estructurado en 4 secciones. Luego de la introducción, en la sección 2 se introduce brevemente el contexto dentro del cual se enmarca el trabajo, en particular se presenta y define un sistema fiable y el paradigma de la orientación a aspectos. La sección 3 describe el modelo conceptual propuesto. Para finalizar, en la sección 4 se presentan las conclusiones sobre el trabajo realizado y los trabajos futuros.

2 Contexto del trabajo

2.1 Los Sistemas Fiables

En líneas generales los sistemas fiables (en la literatura conocidos como “dependable systems”), han sido definidos como todos aquellos sistemas capaces de entregar un servicio que ha sido previamente confiado o acordado; estos sistemas se fundamentan en el concepto de fiabilidad o “dependability” como propiedad principal 1,3,13. Según 3,13 la fiabilidad se define como la habilidad de un sistema para evitar frecuentes y severas faltas de un servicio, es un concepto integrado, que incluye las características de calidad: Disponibilidad (“availability”), confiabilidad (“reliability”), resguardo (“safety”), integridad (“integrity”), confidencialidad (“confidentiality”) y capacidad de mantenimiento o “mantenibilidad” (“maintainability”). La asociación entre disponibilidad, confidencialidad e integridad, conlleva a la definición de la propiedad denominada seguridad (“security”), como puede visualizarse en la Fig. 1 3,14. Otra definición más sencilla para la fiabilidad presentada en 16 es “cualidad o característica de ser fiable”, donde el adjetivo “fiable” es atribuido a aquel sistema cuyas faltas son consideradas suficientemente escasas o insignificantes.


445

Fig. 1. Árbol de Fiabilidad [3].

Del árbol de fiabilidad, se define la disponibilidad como la predisposición para obtener y/o proveer un servicio correcto, la confiabilidad como la continuidad de un servicio correcto y la integridad como la ausencia de alteraciones inadecuadas del sistema; estas tres propiedades son agrupadas bajo la propiedad de seguridad, en la Fig. 1. Por otra parte, el resguardo se define como la ausencia de consecuencias catastróficas sobre el(los) usuario(s) y el ambiente, la confidencialidad como la habilidad para mantener en reserva la información, y la mantenibilidad como la habilidad para experimentar modificaciones y reparaciones 3,14. En 1,3,14 se indica además que la fiabilidad en un sistema es afectada por una serie de amenazas denominadas fallas (“faults”), errores (“errors”) y faltas (“failures”). La falta en un sistema es un evento que ocurre cuando el servicio entregado se desvía del servicio esperado o correcto; un error es aquella parte del estado del sistema que pueda causar una falta de servicio y una falla es definida como la causa hipotética de un error.

2.2 El paradigma de la orientación a aspectos

En los últimos años ha surgido un nuevo enfoque denominado Desarrollo de Software Orientado a Aspectos (AOSD, “Aspect-Oriented Software Development”) el cual busca resolver la complejidad de los sistemas de software y aumentar su reutilización y capacidad de mantenimiento. El AOSD o paradigma OA ha surgido del paradigma de la Programación Orientada a Aspectos (AOP, “Aspect-Oriented Programming”), el cual plantea mejorar la gran complejidad presente en los sistemas de software, está fundamentado en un nuevo término denominado aspecto propio de la AOP 1112. El AOSD tiene como objetivo solucionar a lo largo de todo el ciclo de desarrollo el denominado problema del código enmarañado, separando en una nueva entidad llamada aspecto aquellas propiedades o puntos de interés (denominados “concerns”) que no se corresponden con la funcionalidad básica de la aplicación, y que se encuentran “entremezcladas” o replicadas en más de un componente. Estas propiedades que se diseminan son reconocidas como concerns transversales o (“crosscutting concerns”) 7,11,12.

3 El modelo AO-DeSMO

Esta sección presenta el modelo conceptual propuesto para asociar el dominio de los sistemas fiables con el paradigma de la orientación a aspectos, los requisitos de software y la calidad del software, al


446

cual denominamos AO-DeSMO (Aspect-Oriented Dependable Systems MOdel), expresado en UML 10. Este modelo representa el refinamiento de trabajos previos presentados en 4,5. AO-DeSMO refleja la terminología y los conceptos básicos de los sistemas fiables utilizados en consenso por la comunidad internacional, ahora asociados al mundo de la ingeniería de requisitos y a la orientación a aspectos mediante su vinculación con el mundo de la calidad del software, a través de las características de calidad involucradas en el concepto de fiabilidad. Este modelo pretende facilitar el entendimiento de los principales elementos asociados al dominio de estos sistemas y su tratamiento con el paradigma de la orientación a aspectos. El hecho de expresarlo en un lenguaje de modelación estándar facilita su reutilización en otros contextos, por ejemplo bajo el enfoque MDA (“Model Driven Architecture”).

En el modelo de la Fig. 2, un sistema ha sido implícitamente considerado como un todo, una entidad humana o física, de hardware y software que interactúa con otras entidades; es una entidad que cumple con una o más funciones para así entregar uno o más servicios a sus correspondientes usuarios 3,14. El servicio entregado por un sistema se define como el comportamiento percibido por sus usuarios, es una secuencia de estados externos del sistema, un servicio puede ser correcto o incorrecto; un servicio es correcto cuando implementa adecuadamente la función del sistema 2, un servicio es incorrecto cuando el comportamiento del sistema no corresponde con la función esperada por los usuarios. Una función representa una parte de la funcionalidad de un sistema y es descrita mediante los requisitos del sistema de software o requisitos de software (funcionales y no funcionales 17,18), los cuales son derivados de las necesidades o requisitos de la organización en la cual operará el sistema. De acuerdo al modelo, un sistema fiable es un sistema que debe cumplir con una o más funciones y con determinadas propiedades de calidad. La fiabilidad definida en la sección 2.1, ha sido especificada en AO-DeSMO por un modelo de calidad, es decir un subconjunto de características y subcaracterísticas del estándar internacional ISO/IEC 9126-1 8 para especificar la calidad de productos de software, ahora conocido como ISO/IEC 25010-SQuaRE 9; puede verse en la Fig. 2 en el ámbito de Propiedades de Calidad.

Este modelo de calidad tiene dos perspectivas: la primera corresponde al modelo de Calidad en Uso (calidad percibida por el usuario final en el sistema ya concluido) el cual ha sido representado solamente por la característica de calidad Resguardo. La segunda corresponde al modelo de Calidad Interna (calidad percibida durante el proceso de desarrollo) y Externa (calidad percibida por los desarrolladores en un ambiente de prueba) descrito por las características: confiabilidad (refinada con las subcaracterísticas madurez y tolerancia a fallas) y disponibilidad (subcaracterística implícita de confiabilidad que engloba a madurez y tolerancia a fallas), funcionalidad (refinada con la subcaracterística seguridad) y mantenibilidad (refinada con las subcaracterísticas facilidad de cambios, facilidad de pruebas y estabilidad). Por otra parte, un sistema fiable debe evitar presentar servicios incorrectos los cuales se originan por la influencia de ciertas amenazas: las fallas, los errores y las faltas 1,3,14. Un servicio incorrecto es generado por uno o más errores, un error que afecta a un servicio es una indicación que ocurre o ha ocurrido una falta, un error es una desviación del servicio correcto y es causado por una falla. Una falta es una indicación que uno o más estados externos del sistema se desvían del estado de servicio correcto. Las diferentes formas en la que un sistema puede faltar se conocen como modos de falta.

En la Fig. 2, los requisitos no funcionales se asocian a propiedades cuantificables de calidad (propiedad de calidad) tales como: fiabilidad, disponibilidad, respuesta en tiempo entre otros 6,15.


447

Fig. 2. El modelo AO-DeSMO. Nótese que en la figura se han dejado en inglés los términos del dominio para facilitar su reutilización.

Como vimos anteriormente, un modelo de calidad 8,9 es usado para expresar las propiedades de calidad que caracterizan el dominio de aplicación (en nuestro caso el dominio se refiere a los sistemas fiables). Una propiedad de calidad puede originar una funcionalidad implícita impuesta o no por una regla de negocio. La funcionalidad implícita no compete al usuario final y no ha sido

Sistemas Fiables

Aspectos y Requisitos

Policies Process ing Constraints

Technol. Constraints

SAFETY

I N USE Quali ty ModelMATU RITY

FAULT TOLERANCE

RECOVERABILITY

CHANGEABILITY

STABILITY

TESTABILITY

R ELI ABILI TY / AVAILABILITY

MANTANAI BI LITY

INTERNAL/EXTERNAL Quality Model

FUNCTIONALITY

C ON FI DENTIALITY

INTEGRITY

SECURITY

SERVICE

Functional Requirement

Concern

Sy stem Requirement s

FUNCTION Sof t ware Requirement

1

1

+def ines 1

+corresponds to 1

1..*+identif y 1..*

1..*

1..*

+corresponds to1..*

+specif y1..*

Application Domain

SYSTEM

1. .* +has1. .*

1..* +accomplish1..*

1..*+must

accomplish

1..*

CORRECT SERVICE

Aspect

Business Rule 1..*

+def ines

1..*

+depends on

1..* 1..*

+imposes1..*

+are deriv ed f rom

1..*

Functional Concern

(Depend. Sy stems ) Quality Model

1

1

+charact er ized by 1

+depends on 1

DEPENDABLE SYSTEM+corresponds to

1..*

+must deliv ery

1..*

Cross cutt ing Concern

+is implemented

+correspond t o

0..*0..1+can der iv e

f rom

0..* +can be0..1

2..*

+crosscuts

2..*NonFunctional

Concern0..*0..1

+can deriv e f rom

0..*+can be0..1

Implicit Funcionality

0..*+imposes0..*

(DEPENDABILITY) Quality Property1..*

+has associated

1..*

1

1..* +specif ied by1+express

1..*

*+must

accomplish

*

0..1

1

+deriv ed f rom0..1

+associated to1

0..1+can be0..1

1..*

1..*

+associated to 1..*

+deriv es f rom 1..*

1..*+can originate1..*

NonFunctional Requirement 1

+responds to1

1..*

1..*

+associat ed to1..*

+deriv ed f rom1..*

FAULT FAILURE

ERROR

+caused by

+activ ate

+propagate

+ocurrs by

EVENT

11

+represents1

+generates

1

Failures Mode1..* +corresponds to1..*

INCORRECT SERVICE

+generat ed by+generates

+generate

1..*

1..*

+due to

1..*

+originate1..*

Propiedades de Calidad


448

explícitamente indicada, pero debe ser adicionada a fin de garantizar el logro de la funcionalidad global de la aplicación. Una funcionalidad implícita responde a un requisito no funcional y por lo general es identificada por los miembros del equipo de desarrollo 6,15. En general una propiedad de calidad derivada de un requisito funcional, no funcional o de una funcionalidad implícita puede ser un potencial concern transversal, objeto de ser tratado a través del paradigma AO 7,11,12. En el contexto de este paradigma, y según las definiciones introducidas en la sección 2.2, un concern transversal puede ser un concern funcional o no funcional que se entrecruza entre dos o más concerns funcionales afectando a distintas partes de un sistema fiable y que de implementarse, producirían enmarañamiento y dispersión en su especificación; por tanto, un concern funcional o no funcional puede ser un concern transversal (representados a través de la especialización en el modelo). Un concern corresponde a un requisito de software, del cual es necesario ocuparse para resolver un problema inherente al software 7; por tanto, puede asignársele igual estructura, comportamiento y tratamiento dentro de las disciplinas de ingeniería de requisitos y diseño arquitectónico. Algunos concerns, tal como los requisitos se asocian a las funciones o servicios específicos que debe realizar la aplicación o sistema fiable, y se especifican como concerns funcionales. Otros concerns, denominados concerns no funcionales describen las condiciones o restricciones que la aplicación debe satisfacer, pudiendo afectar la puesta en práctica de los concerns funcionales. Los concerns no funcionales al igual que los requisitos no funcionales, se asocian a una o más propiedades de calidad (o propiedades de fiabilidad en este caso) cuantificables y han sido el objeto principal de estudio dentro del AOSD por ser considerados como potenciales concerns transversales. El mecanismo propuesto por el AOSD para resolver los concern transversales son los aspectos. Un aspecto es una unidad modular diseñada para implementar o encapsular un concern transversal 7,11,12. En el desarrollo de los sistemas fiables, las características de fiabilidad (derivadas de los requisitos funcionales y no funcionales) pueden por correspondencia ser tratadas bajo la perspectiva de la OA, debido a que cada una representa un concern que puede estar entremezclado entre otros concerns funcionales y por ende cada una constituye un potencial concern transversal.


Este artículo ha presentado a AO-DeSMO, un modelo conceptual que busca asociar los principales elementos y la terminología básica que ha sido utilizada por la comunidad de investigadores en el dominio de los sistemas fiables, considerando tres ámbitos: los requisitos de software, su calidad y el paradigma de la orientación a aspectos; en particular se presenta la asociación de las propiedades de fiabilidad con el concepto de aspecto a través de los requisitos de software. El modelo constituye una herramienta útil para iniciar una ontología dentro del área de los sistemas fiables o computación fiable orientada a aspectos, permite dar soporte a la emergente disciplina de la ingeniería de requisitos orientada a aspectos en el dominio de los sistemas fiables, favoreciendo la especificación de los requisitos de una aplicación usando la terminología de la OA y una terminología estándar de calidad. Como trabajo futuro, esta investigación se dirige hacia la cuantificación de los atributos de calidad que corresponden a las propiedades de fiabilidad y su correspondiente tratamiento a través del concepto de aspecto. Así mismo se está trabajando en aplicar el modelo a casos concretos en las etapas tempranas del desarrollo.


449

Referencias

1. Avizienis, A., Laprie, J.C. Y Randell, B. Fundamental Concepts of Dependability. Technical report, LAAS CNRS, October 2000.

2. Avizienis, A., Laprie, J.C. y Randell, B. Fundamental Concepts of Dependability. Research report Nº1145, LAAS CNRS, April 2001.

3. Avizienis, A., Laprie, J.C., Randell, B. y Landwehr, C. Basic concepts and taxonomy of dependable and secure computing. IEEE Transaction on dependable and Secure Computing Vol. 1, issue 1, pp 11-33, IEEE 2004.

4. Caldera, R., Castillo, I., Losavio, F. y Matteo, A. Modelación de Requisitos, Aspectos y Calidad de Software. Proceeding XXXII Conferencia Latinoamericana de Informática CLEI’2006, Santiago, Chile. Agosto 2006.

5. Castillo, I., Caldera, R., Losavio, F. y Matteo, A. Caracterización de Sistemas Fiables basada en un modelo estándar de calidad. Proceeding XXXII Conferencia Latinoamericana de Informática CLEI’2006, Santiago, Chile. Agosto 2006.

6. Chirinos, L., Losavio, F y Matteo, A. Identifying Quality-Based Requirements. Information Systems Management. Editorial: Auerbach Publications, 21(1),15-26, 2004.

7. Filman, R., Elrad, T., Clarke, S. y Aksit, M. Aspect-Oriented Software Development. Addison Wesley, Boston. 2005.

8. ISO/IEC: FCD 9126-1. Information Technology - Software Engineering Product Quality. Part 1: Quality Model. 2001.

9. ISO/IEC: FCD 25010. Software Engineering. Software Product Quality Requirements and Evaluation (SQuaRE). Quality Model and guide. Draft 2006.

10. Jacobson, I., Booch, G. y Rumbaugh, J. El Lenguaje Unificado de Modelado. Segunda Edición. Madrid: Addison Wesley. 2000.

11. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.M. e Irwin, J. Aspect-Oriented Programming. ECCOP’97 Object-Oriented Programming, 11th European Conference, M. Aksit y S. Matsouka, Eds. LNCS 1241, 220-242. 1997.

12. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, M. y Griswold, W. G. An Overview of AspectJ. ECOOP’2001 Object-Oriented Programming, 15th European Conference, (Budapest), J. L. Knudsen, Ed. LNCS, vol.2072 Springer-Verlag, Berlin, 327-353. 2001.

13. Laprie, J.C. Dependable computing and fault tolerance: concepts and terminology. In Digest of FTCS-15, 2-11,1985.

14. Laprie, J.C. Dependability: Basic Concepts and terminology. IFIP WG 10.4 - Dependable Computing and Fault Tolerance, August 1994.

15. Losavio, F., Chirinos, L., Levy, N. y Ramdane-Cherif, A. Quality Characteristics for Software Architectures. Journal of Object Technology, 2(2), 133-150. 2003.

16. Randell, B. Facing up to Faults. ICSE’04 Workshop on Architecting Dependable Systems, May 2004. 17. Sommerville, I. y Sawyer, P. Requirements Engineering. A Good Practice Guide. John Wiley and

Sons, New Cork 1997. 18. Wiegers, K. Software Requirements: Practical techniques for gathering and managing requirements

throughout the product development cycle. Microsoft Press, Washington, USA, pp 12-14. 2003.


450

Chamaéleon. Prototipo que Unifica Patrones de Diseño de Interfaces en Sitios Web

Gladys Benigni , Manuel Pérez y Justo Marcano

Coordinación Programa Licenciatura en Informática Universidad de Oriente - Núcleo Nueva Esparta, Venezuela

[email protected]

Resumen. Los sistemas de software han mejorado su funcionalidad y procesamiento de la información, sin dejar de lado el avance en cuanto a las interfaces de usuario y la forma de interacción con las mismas, las cuales, han brindado una mejor usabilidad de las aplicaciones, y en consecuencia, una mayor aceptación por parte de los usuarios. Para contribuir con el desarrollo de herramientas para la creación de interfaces en sitios Web, nace Chamaéleon, la cual tiene como propósito facilitar la creación de este tipo de aplicaciones basándose en patrones de diseño, un código flexible que permite portabilidad y reutilización. Igualmente, cada uno de estos patrones cuenta con información adicional que ayudará al usuario al correcto uso de los mismos según el problema que éste presente, es decir, información detallada que trate aspectos como: ¿cuál es el problema?, ¿cuándo usar el patrón?, ¿qué solución ofrece el patrón?, ¿por qué usar el patrón?.

Palabras clave: Chamaéleon, patrones de diseño, interfaces de usuario, sitios Web, usabilidad, reutilización.

1 Introducción

Las interfaces de usuario (IU) desde sus inicios hasta la actualidad han evolucionado, logrando mejorar cada vez más la interacción entre el usuario y el computador, pues éstas pasaron de ser pantallas estáticas a ser pantallas totalmente dinámicas donde la información fluye hacia el usuario según éste lo desee. El gran salto en la evolución de las IU se dio principalmente cuando se desarrollaron las Interfaces Gráficas de Usuario (GUI, por sus siglas en inglés), las cuales ofrecían mejoras útiles al usuario para manejar la información.

A medida que las IU evolucionaban, los requerimientos de los usuarios también eran mayores, por lo cual, su complejidad en el diseño creció tanto que, en la actualidad se requiere de expertos en distintas áreas ajenas a la informática para desarrollar una IU usable, entre las cuales se destacan: el Diseño Gráfico, Educación, Psicología, entre otras. Todas estas especialidades buscan evaluar la usabilidad de las IU, basándose en principios básicos que involucraban elementos como el uso del color, fuentes, formas, entre otros.


451

Para lograr la estandarización de los diseños de IU, varias compañías desarrolladoras de software realizaron las guías de estilo, las cuales “son documentos que recogen normativas y patrones básicos relacionados con el aspecto de una interfaz para su aplicación en el desarrollo de nuevas pantallas dentro de un entorno concreto”, [5]. Éstas abarcan todos los elementos de la apariencia en la interfaz, (fuentes, colores, formas, íconos, presentación de la información, menues, entre otros), estableciendo los lineamientos que determinan la forma en que se deben realizar los diseños. Sin embargo, las guías de estilo no tuvieron un gran apoyo en la comunidad de programadores, debido a que su difusión fue bastante limitada, [7].

Para solventar los problemas de las guías de estilo, surgieron los patrones de diseño, basándose en los principios básicos de los patrones, los cuales ya se venían utilizando en otras áreas. En este sentido, un patrón no es más que “un modelo a seguir que describe una solución exitosa de un problema particular en un contexto dado” [1]. Este concepto adaptado a la informática, permite afirmar que un patrón es la solución a un problema codificado, que concentra conocimientos de expertos y se presta a ser utilizada por otros desarrolladores. Los patrones poseen ciertas características que van en contraposición a todo lo tratado en las guías de estilo, ya que estos permiten una mayor adaptabilidad, compresión, utilidad por ser un código reutilizable; y confianza, al ser códigos que están en constante mejora, [1].

La utilidad de un patrón no solo se limita, a otorgar soluciones a un problema, éstos también pueden ser utilizados para: describir un problema, facilitar la comunicación en un grupo de trabajo creando estándares de codificación, documentar un trabajo realizado, entre otras cosas. En cambio, las guías de estilo son más limitadas, ya que, solamente están destinadas a explicar los aspectos que deben tener las interfaces de usuario; estas directrices o reglas de diseño, indican cómo asociar estos principios abstractos a entornos de programación concretos. Además, estas guías están sujetas al estilo de la compañía creadora, lo cual la enmarca a un solo enfoque, debido a que cada organización posee sus estatutos y lineamientos para trabajar.

Actualmente, los patrones son ampliamente utilizados para el desarrollo de aplicaciones, permitiendo concentrar toda la atención de los desarrolladores de software en aspectos específicos de la aplicación, al facilitar códigos ya elaborados para problemas triviales, lo cual, beneficia a un gran número de programadores que sólo tienen que disponer de éstos códigos a su conveniencia, según sean las necesidades de su aplicación. En este sentido, el uso de patrones de diseño ayuda enormemente a aquellas personas que no poseen mucho conocimiento en el desarrollo de interfaces de usuarios, o bien no manejan los lineamientos que se deben tomar en cuenta para crear IU usables; ya que son soluciones desarrolladas y probadas por expertos en el área, que además están en constante mejora, por ser un código reutilizado por muchos desarrolladores.

Por esta razón, surge la necesidad de seguir innovando en el desarrollo de herramientas, que permitan a desarrolladores y usuarios noveles la creación de interfaces de usuario y diseño de sitios Web que cumplan con los principios generales de usabilidad, (Anticipación, Autonomía, Colores, Consistencia, Eficiencia del usuario, Reversibilidad, Ley de Fitts, Reducción del tiempo de latencia, Mínimo proceso de aprendizaje, Uso


452

adecuado de metáforas, Protección del trabajo, Legibilidad, Seguimiento e Interfaz visible); y que además provea formas de interacción con los elementos de la misma, garantizando así la resolución a problemas triviales y el cumplimiento de los requerimientos de los usuarios.

A partir de esto, nace la presente investigación, la cual busca facilitar el diseño de interfaces de usuario a través de un prototipo Web de alta fidelidad que proporcione soluciones usables y personalizables, por medio de una diversa gama de patrones de diseño Web, los cuales, el usuario podrá modificar y ajustar a sus necesidades. El propósito de la misma es “desarrollar un prototipo Web de alta fidelidad que unifique patrones de diseño de interfaces de usuario ya existentes, para su reutilización y fácil manipulación en el desarrollo de sitios Web por parte de usuarios noveles, intermedios y avanzados”.

2 Materiales y Métodos

Para la elaboración de Chamaéleon se contó con: Computador procesador Intel Pentium D 2.8 ghz, 1 gb DDR2 RAM, y otros componentes. Las herramientas de software necesarias para la construcción del prototipo se categorizaron de la siguiente manera: a) Plataforma Operativa: Windows XP Professional Server Pack 2; b) Herramientas de Diseño: Macromedia Dreamweaver 8., Macromedia Fireworks 8., Macromedia Flash 8 y Corel Draw 12; c) Lenguaje de Programación: Php y JavaScript; d) Manejar de Base de Datos: MySql; e) Servidor Web: Apache Server; f) Navegador Web: Internet Explorer 6.0.

La metodología de desarrollo que se aplicó para llevar a cabo Chamaèleon, es la Ingeniería de Software Orientada a Objetos (OOSE por sus siglas en inglés de Object Oriented Software Engineering), propuesta por Jacobson [3]. Por considerarse de un prototipo para la Web, se utilizará la extensión de UML, para hipermedia y multimedia en su versión 0.91 de Conallen [2], a través de sus clases estereotipadas.

3 Resultados

3.1 Prototipo de Alta Fidelidad Chamaéleon

Chamaéleon, es un sitio Web que nace con la finalidad de ser una herramienta para el desarrollo de sitios Web, proporcionando una diversa gama de opciones que faciliten la creación de éstos a partir de la reutilización de patrones de diseño de interfaces. Estos patrones pueden ser modificados por el usuario para adaptarlos a sus necesidades o requerimientos de forma rápida y sencilla. Asimismo Chamaéleon proporciona servicios útiles como foros, documentación, enlaces de interés, entre otros, tratando de cubrir todas las necesidades de los usuarios del sitio Web.


453

3.2 Comparando Chamaéleon

Actualmente existen diversos software con los cuales se pueden desarrollar aplicaciones a nivel de interfaz, destacando aspectos como usabilidad, reutilización y simplicidad. En este sentido se presenta, AllWebmenu [4], la cual es una aplicación que tiene como objetivo facilitar la creación de páginas Web, dándole al usuario la posibilidad de introducir menús dinámicos de forma fácil y sencilla. Velneo [6] nace con la concepción de ser una herramienta que facilite soluciones empresariales completas, desde la creación de plantillas, manejadores de base de datos, entre otras. Velneo cuenta con una herramienta para la rápida creación de programas, la cual abarca aspectos generales de la estructura de los datos y la interfaz de usuario a implementar, para el desarrollo de la IU. Welie [8] es un claro ejemplo de lo que es un sitio Web basado en el uso de patrones. La finalidad de Welie es poner a disposición de los desarrolladores, patrones de diseño ubicados en distintas categorías como: tipo de sitio, navegadores, comercio, entre otros. Cada uno de los proyectos mencionados anteriormente se enfocan en brindar a los usuarios programadores herramientas que faciliten su trabajo, reduciendo costo, tiempo y esfuerzo. Sin embargo, a nivel de flexibilidad y manipulación de las interfaces de usuario generadas, dichas aplicaciones son bastante rígidas, restringiendo al programador al uso de plantillas preestablecidas, que a pesar de ser personalizables, enmarcan al usuario en un único esquema (por ejemplo, véase http://welie.com). En contraposición, Chamaéleon, además de contar con todos los beneficios antes mencionados, pretende brindar al usuario un mayor manejo del producto final, a través del uso de patrones ya probados y evaluados por otros programadores, que aportan una solución viable al problema planteado, mediante el manejo independiente de cada componente en la interfaz diseñada, logrando una mayor aproximación con lo que el usuario desea realizar.

3.3 Desarrollo de Chamaéleon

En la fase de análisis del método OOSE [3], se resalta el modelo de requerimientos en el cual se referencia el modelo de caso de uso (compuesto por los actores y los casos de uso), así como el modelo objeto de dominio de Chamaéleon (Fig. 1), identificándose en la misma, los objetos fundamentales que toman parte en el sistema. El modelo de objetos, presenta la funcionalidad de la aplicación y se detalla con la fusión de los objetos entidad, control e interfaz presentes en el modelado de la aplicación (modelo de análisis).

La fase de construcción comprende el modelo de diseño y el modelo de implementación, los cuales completan el desarrollo conceptual del sistema. Este modelo es el que se vincula de forma más estrecha con aspectos de la implementación del sitio Web; se construye para adaptar más a la realidad el modelo conceptual. En base a lo señalado, para desarrollar la aplicación se elaboraron los diagramas de interacción entre los objetos del sistema aunado a los casos de uso definidos en la fase de análisis.


454

Fig. 1. Modelo Objeto de Dominio.

En vista de que Chamaèleon es un sistema que funciona en un ambiente Web, de manera dinámica y con una arquitectura de tres (3) capas, es importante describir su estructura con alguna herramienta metodológica diseñada especialmente para sistemas Web. En la metodología OOSE [3] no está contemplada la diagramación de componentes Web, por esta razón, se ha tomado como complemento la extensión de UML para aplicaciones Web, donde se incluyen las Clases Estereotipadas [2]. Con ésta es posible representar objetos como las páginas de cliente y de servidor, formularios, enlaces, entre otros.

En lo que respecta a la base de datos, la misma es relacional, y se diseñó siguiendo los criterios expresados por Jacobson [3]. Para culminar esta fase, en el modelo de implementación, se definen los aspectos técnicos de la construcción del sistema, así como la especificación de los recursos tecnológicos que se seleccionaron como soporte de la misma los cuales fueron detallados en el aparte materiales y métodos. Seguidamente, como ejemplo, se presenta el código del módulo agregar usuario: function Guardar_Registro($Nomb,$Pass,$Ima) { include ("Conexion.php"); $query_Reg="Select * from Usuarios where Login='$Nomb'"; $Reg = mysql_query($query_Reg, $conexion) or die(mysql_error()); $Row_Reg = mysql_fetch_assoc($Reg);//Busca al usuario if ($Row_Reg["Login"]!="")//Si cuenta existe, error echo ('<script language="javascript"> alert("Error, Usuario Existente"); </script>'); else //Si no agrega el registro dentro de la BD { $query_Reg="INSERT INTO Usuarios (Login,Pass,Imagen) VALUES ('$Nomb','$Pass','$Ima')" ; $Reg = mysql_query($query_Reg, $conexion) or die(mysql_error());


455

echo ('<script language="javascript"> alert("Usuario Agregado"); </script>'); } }

Finalmente, en la fase de pruebas, se desarrollaron las pruebas al prototipo para validar el correcto funcionamiento de la aplicación.

3.4 Ejemplo de creación de Banners en Chamaéleon

Para realizar un Banner dentro de Chamaéleon se debe seguir una secuencia de pasos que se detalla seguidamente: 1. Se debe elegir el tipo de Banner utilizando el menú desplegable ubicado en la opción

Banner de la sección Diseño Web del menú vertical izquierdo de Chamaéleon (ver Fig. 2).

Fig. 2. Pantalla de creación de Banner de Chamaéleon.

2. Al escoger el tipo de Banner aparecerá una pantalla que contendrá información del Banner seleccionado así como las propiedades del mismo que pueden ser modificadas a gusto del usuario (Fig. 3).

Fig. 3. Propiedades del Banner.

3. Una vez llenado todos los datos, se debe hacer click en el botón visualizar el cual mostrará en una ventana nueva el Banner obtenido.


456

4. Si el Banner cumple con las expectativas del usuario y no se desea colocar algún otro componente a la página (texto, imágenes, tablas, entre otros), éste podrá guardar el código generado mediante la opción guardar proyecto ubicada en la parte derecha del Banner superior de Chamaéleon; el proyecto será guardado en una dirección dada por el usuario en un documento html.

5 Conclusiones

Chamaèleon es un sitio Web que nació con el propósito de servir como herramienta que permita desarrollar páginas Web de forma rápida y sencilla, dando la opción a los diferentes usuarios de esta aplicación a modificar el código generado, permitiéndolo caracterizarlo como flexible y adaptable. Además, Chamaéleon proporciona servicios útiles como foros, documentación, enlaces de interés, entre otros, tratando de cubrir las necesidades de los usuarios que acudan al sitio. Asimismo, Chamaéleon dispone de un servicio de mensajería, donde los usuarios registrados podrán dar sugerencias, incluir códigos (reuso), opiniones, entre otras; y además como complemento, presenta contenido teórico acerca de usabilidad y patrones de diseño, que servirán como fuente documental para futuras investigaciones en el área.

Referencias

1. Acosta, A y Zambrano, N. Patrones en Interacción Humano-Computador: Fundamentos Teóricos. Caracas – Venezuela. (2001).

2. Conallen, C. Modeling Web Application Design with UML. Volume 42, number 10. (1999). 3. Jacobson, I. Object-Oriented Software Engineering (Ed. rev.). Inglaterra: Addison-Wesley.

(1992). 4. Likno Software. DHTML menú & Javascript menu creator – Powerful Web menú solutions.

Disponible: http://www.likno.com/. [Consulta: 2006, Octubre 28]. (2006). 5. Martín, C y Vargas, A. Guías de estilo para el diseño de Interfaces de Usuario Web.

Disponible:_http://2tancomeon.easyhost4all.info/files/trabajo.pdf. [Consulta: 2006, Octubre 25]. (2005).

6. Velneo.¿Qué es Velneo? Disponible: http://www.velneo.com/Web/index.pro. [Consulta: 2006, Octubre 28]. (2006)

7. Villa, L. Guías de estilo: diseño, normalización y usabilidad. [Documento en línea]. Disponible: http://www.alzado.org/articulo.php?id_art=327 [Consulta: 2006, Octubre 20]. (2004).

8. Welie, M. …patterns in Interaction Design. Disponible: http://www.welie.com/. [Consulta: 2006, Octubre 28]. (2006).


457

Modelos de Integración de Sistemas en Empresas Venezolanas: Estudios de Caso

Irina Titaeva1, Luis E. Mendoza1, María Pérez1

1 Departamento de Procesos y Sistemas, Edificio de Matemáticas y Sistemas, Laboratorio de

Investigación en Sistemas de Información (LISI), Universidad Simón Bolívar, Apartado 89000, Baruta, Caracas, 1080-A, Venezuela

[email protected], {lmendoza, movalles}@usb.ve

Resumen. Actualmente la integración de sistemas juega un rol importante en el mundo globalizado, ya que permite a las organizaciones enfrentarse mejor al mercado mundial. Los Modelos de Integración (MI) permiten a las organizaciones determinar bajo qué enfoque están llevando a cabo su proceso de integración, dónde el uso de los Sistemas de Información (SI) y la implementación de las Tecnologías de Información (TI) se hace indispensable. Esta investigación tiene por objetivo presentar los resultados de 8 estudios de caso donde se identificaron los MI (Ciclo, Semilla, Web, Flujo, Onda, Anillo, Célula y Árbol) que han sido estudiados en contextos foráneos para determinar cómo éstos modelos están presentes en las organizaciones venezolanas. Como resultado, se pudo demostrar que las organizaciones venezolanas pueden ampliar su conocimiento sobre la integración de sus SI y TI, a través del uso de estos modelos, mejorando de esta manera su integración de sistemas.

Palabras clave: Estudio de caso, Integración de sistemas, Modelos de integración.

1 Introducción

Durante los últimos años las organizaciones han sido expuestas a un fuerte proceso de cambio bajo la influencia del desarrollo de las Tecnologías de Información (TI) donde la integración de la tecnología con los procesos de la organización juega un papel importante. La integración constituye una verdadera herramienta para que las organizaciones combinen todos sus procesos presentes en los diversos sistemas que la conforman.

La idea principal de la integración es hacer que la organización, a través de la coordinación de todos sus procesos y el uso de la tecnología, logre ser más competitiva formando una nueva visión del futuro. Las estrategias gerenciales organizacionales deberían apuntar hacia la conformación de sistemas integrados que aprovechan al máximo los elementos tecnológicos presentes hoy día en cualquier organización.


458

En [5] se propone una de las técnicas para la Integración de las Aplicaciones Empresariales (EAI por la siglas en inglés de Enterprise Application Integration) a través de los MI, ofreciendo a las organizaciones múltiples soluciones de integración. Se puede considerar que los MI desarrollados en [5] son de vital importancia para un desarrollo del país planificado y constante, puesto que las organizaciones permiten a los individuos explotar su potencial en beneficio de la colectividad y, en una mayor escala, de su comunidad y de la sociedad en general. Sin embargo cabe preguntarse si en Venezuela, las organizaciones están siguiendo algunos de los modelos propuestos por Brown.

El presente artículo presenta los resultados de 8 estudios de caso donde se identificaron los MI (Ciclo, Semilla, Web, Flujo, Onda, Anillo, Célula y Árbol), a través de la aplicación de un modelo basado en las características de los MI propuestos por Brown, para determinar cómo éstos modelos están presentes en las organizaciones venezolanas.

Este trabajo, además de la presente introducción y las conclusiones finales, presenta en la sección 2 una breve descripción de los MI en los cuales se fundamenta el modelo de especificación basado en características descrito en la sección 3. En la sección 4 se presentan los 8 estudios de caso objeto del artículo, previo a la presentación en la sección 5 del análisis de resultados de dichos estudios de caso.

2 Modelos de Integración

Existen varios tipos de integración que son necesarios y valiosos pero a veces no satisfacen las necesidades de muchos negocios. Algunas veces las áreas que cubren son demasiado específicas dedicándose a una función o a un departamento en particular. Se necesita la integración no solamente en el nivel físico sino conceptual. Para esto se utiliza el concepto de EAI, el cual se define de la siguiente manera: “… es el proceso mediante el cual hardware, software y procedimientos de negocios combinan sus componentes haciendo posible la fácil utilización de la información y los sistemas en un trabajo conjunto que puede alcanzar la sinergia [5]. EAI está representada a través de los MI [5]. Estos modelos expresan en un lenguaje común las soluciones para la integración, capturan las múltiples posibilidades que se presentan para la organización, muestran cómo se combinan los elementos para lograr la solución deseada. La Tabla 1 contiene la breve descripción de cada modelo.

El uso de cada modelo ofrece unos beneficios específicos que reflejan su esencia. Estos modelos tratan de abarcar todas las posibles combinaciones de integración que pueden usar las organizaciones. En [5] se menciona que es probable que existan otros modelos que no están descritos todavía. Los MI demuestran un amplio panorama de la aplicación de los mismos en diversos procesos organizacionales. Cada proceso está relacionado con el propósito de la organización. Éste, en su lugar, define la razón de ser de la organización y actúa como catalizador para crear una estructura que opera en el marco del contexto definido. Para llevar a cabo los cambios deseados, una organización necesita identificar los procesos actuales, recalcando sus fortalezas y debilidades, comprenderlos, planificar


459

cómo poder mejorarlos o transformarlos y definir los requerimientos tecnológicos, entre otros. Los MI reúnen los requisitos necesarios para soportar y llevar a cabo este proceso de cambio. En base de lo anterior, surge la pregunta ¿Cómo se pueden identificar los MI en las organizaciones venezolanas?

Tabla 1. Modelos de integración. Adaptado de [5].

Modelo Descripción Ciclo Un proceso cíclico que se caracteriza por su repetición, evolución, autoreforzamiento y autocorrección. Semilla Genera o transforma la estructura donde un componente central produce los resultados Web Es una red de nodos y conectores que permite diseñar redes de comunicación, analizar los caminos óptimos.

Flujo Se utiliza para rastrear el curso de la información, género, servicios y comunicaciones; reduce la complejidad y optimiza los pasos.

Onda Describe las capas de sistemas, ambientes o redes, donde cada capa tiene una función.

Anillo No es direccional y jerárquica, ayuda a definir si funciones comerciales son centralizados o no y cuáles recursos se pueden utilizar local y globalmente para el mayor beneficio.

Célula Modela el soporte de clasificación y comportamiento; se utiliza para el análisis de sistemas distribuidos, de división geográfica y de conducta a nivel local versus global.

Árbol Ayuda a modelar sistemas con la bifurcación compleja, diversificación y, también, aplicar varias opciones en caso de la distribución.

3. Modelo de Identificación de los MI

El modelo aplicado a los casos es un modelo de especificación basado en características y contiene elementos de los ocho (8) MI presentados en [5], descritos en la Tabla 2.

Tabla 2. Descripción de las características del modelo.

Modelo Descripción

Proceso Consiste en fases sucesivas que en su conjunto forman una operación estratégica, táctica o comercial de una unidad de negocios [6].

Organización Es un sistema humano “de cooperación y coordinación integradas dentro de límites definidos con el fin de alcanzar metas compartidas” [4].

Tecnología Se refiere “al conocimiento, herramientas, maquinaría, información, habilidades y materiales empleados para completar las tareas organizacionales..." [7].

Cambio Se refiere a una actitud frente al cambio que permite evolucionar de un estado al otro para mejorar la situación presente

Comunicación Manifestar o transmitir alguna información de manera verbal, escrita o a través de otro medio [6]. Producto/servicio Se refiere a un bien o provecho producido o ejecutado al beneficio de otro, en un tiempo dado

Mercadeo Se refiere a una serie de operaciones por las que pasa el bien desde el momento de su producción, hasta llegar al cliente

Las características descritas en la Tabla 2, conforman el nivel 1 del modelo englobando

los principales elementos de todos los modelos, representando su esencia y resaltando lo más importante de cada uno. Cada característica fue descompuesta en subcaracterísticas y para poder medirlas, se formularon 95 métricas, siguiendo el paradigma GQM [3]. Cada métrica está codificada correlativamente a la subcaracterística correspondiente. En Tabla 3 se presenta la codificación de las métricas para la identificación de los modelos.


460

Tabla 3. Codificación para la identificación de modelos.

Modelo Características Subcaracterísticas Métricas

Ciclo Proceso

P1. proceso documentación P1.1 P2. proceso comportamiento P2.1, P2.2, P2.3, P2.4, P2.5, P2.6 P3. proceso estructura P3.1, P3.2, P3.3 P4. proceso tiempo P4.1

Semilla

Proceso

P5. proceso automatización P5.1 P2. proceso comportamiento P2.7, P2.8

P3. proceso estructura P3.4, P3.5, P3.6, P3.7, P3.8, P3.9, P3.10, P3.11, P3.12, P3.13, P3.14

P6. proceso coordinación P6.1, P6.2 P7. proceso finanzas P7.1

Organización O3. organización crecimiento O3.1 O4. organización costos O4.1 O1. organización estructura O1.1

Web Tecnología

T3. tecnología comercialización T3.1, T3.2 T4. tecnología red T4.1

Proceso P3. proceso estructura P3.15, P3.16, P3.17, P3.18, P3.19 Cambio CB1. cambio resistencia CB1.1

Flujo Proceso P3. proceso estructura P3.20, P3.21, P3.22, P3.23, P3.24

Onda

Tecnología T4. tecnología red T4.2, T4.3 T1. tecnología automatización T1.1 T5. tecnología calidad T5.1

Proceso

P3. proceso estructura P3.2, P3.25, P3.26 P4. proceso tiempo P4.2 P8. proceso soporte P8.1 P9. proceso seguridad P9.1

Comunicación CM2. comunicación problemas CM2.1

Anillo

Proceso P3. proceso estructura P3.27, P3.28, P3.29 P5. proceso automatización P5.2

Comunicación CM1. comunicación red CM1.1

Tecnología T4. tecnología red T4.3, T4.4, T4.5 T2. tecnología crecimiento T2.1

Organización O3. organización crecimiento O3.2

Célula

Organización O1. organización estructura O1.2, O1.3, O1.4, O1.5 O2. organización finanzas O2.1

Comunicación CM3. comunicación frecuencia CM3.1 CM4. comunicación forma CM4.1

Tecnología T6. tecnología SI T6.1, T6.2 T7. tecnología procesamiento T7.1 T8. tecnología BD T8.1

Proceso P3. proceso estructura P3.30, P3.31, P3.32 P10. proceso beneficios P10.1 P11.proceso cliente P11.1, P11.2, P11.3, P11.4

Producto/servicio PS1. producto/servicio calidad PS1.1

Mercadeo M1. mercadeo flexibilidad M1.1 M2.mercadeo innovación M2.1

Árbol Proceso P3. proceso estructura

P3.5, P3.16, P3.33, P3.34, P3.35, P3.36, P3.37, P3.38, P3.39

Tecnología T6. tecnología SI T6.3 Organización O3. organización crecimiento O3.3

Para la aplicación del modelo a los estudios de caso, se diseñó un cuestionario, donde

cada una de las preguntas representa a cada métrica y admite una sola respuesta de todas las posibles respuestas, con un valor mínimo igual a 1 (uno) y un valor máximo igual a


461

cinco (5). Este cuestionario fue aplicado a cada uno de las organizaciones participantes en el estudio.

4. Estudios de caso

Los estudios de caso están constituidos por cada una de las organizaciones venezolanas participantes en el estudio y que conforman un total de ocho estudios, los cuales están distribuidas de la siguiente manera: al sector secundario se corresponde a los casos uno (1), dos (2), siete (7) y ocho (8) y con el sector terciario se corresponden casos tres (3), cuatro (4), cinco (5) y seis (6).

Cuando se habla del sector secundario se hace la referencia a las actividades relacionadas con el área manufacturera, tales como: producción de calzados, pieles, cueros, muebles; de agroindustria, tales como producción de lácteos, azúcar y otros productos alimenticios; de industria de extracción minera y de petróleo, entre otros. En su totalidad lo que produce este sector sirve como base para la fabricación de nuevos productos [1, 2, 8].

Cuando se habla del sector terciario, se hace referencia a las actividades relacionadas con el comercio, los servicios que incluyen restaurantes, hoteles, transporte, servicios financieros, comunicaciones y educación, entre otros. En general, este sector incluye actividades que no producen bienes en sí pero son necesarias para el funcionamiento de la economía [1, 2, 8].

Con relación a las organizaciones que participaron en la investigación, se puede decir que por razones de confidencialidad no se revelan sus nombres y todas ellas figuran bajo números según el orden en el cual se aplicó el cuestionario. Sobre las actividades de cada organización se informa lo siguiente: el caso uno (1) corresponde a una organización dedicada a la distribución de electricidad; el caso dos (2) corresponde a una organización dedicada a la extracción del petróleo, los casos siete (7) y ocho (8) corresponden a organizaciones dedicadas a la producción de alimentos; los casos tres (3) y seis (6) corresponden a organizaciones que prestan servicio de telecomunicaciones, el caso cuatro (4) corresponde a una organización dedicada a la prestación de servicios financieros y el caso cinco (5), corresponde a una organización educativa.

Dadas las limitaciones de espacio, en la próxima sección sólo se presentarán los resultados más importantes obtenidos.

5. Análisis de Resultados

Se puede observar en la Tabla 4 que los modelos semilla, anillo y célula fueron identificados en todos casos; los modelos ciclo, onda y árbol se identificaron en seis (6) casos y los modelos web y flujo en cinco (5) casos. En otras palabras, los modelos semilla, anillo y célula, se detectaron en un 100% de los casos estudiados; los modelos


462

ciclo, onda y árbol, en un 75% de los casos estudiados; los modelos web y flujo en un 62,5% de los casos estudiados.

Tabla 4. MI detectados por cada caso.

Sector Caso Cantidad Modelos identificados Modelos no identificados

Secu

n-da

rio

1 7 (87,5%) Ciclo, semilla, web, onda, anillo, célula, árbol Flujo 8 7 (87,5%) Ciclo, semilla, web, onda, anillo, célula, árbol Flujo 7 6 (75%) Ciclo, semilla, onda, anillo, célula, árbol Web, flujo 2 5 (62,5%) Semilla, web, flujo, anillo, célula Ciclo, onda, árbol

Ter

ciar

io

4 8 (100%) Ciclo, semilla, web, flujo, onda, anillo, célula, árbol Ninguno 5 8 (100%) Ciclo, semilla, web, flujo, onda, anillo, célula, árbol Ninguno 3 6 (75%) Ciclo, semilla, flujo, onda, anillo, célula Web, árbol 6 5 (62,5%) Semilla, flujo, anillo, célula, árbol Ciclo, web, onda

Según estos resultados, en los casos estudiados se identificaron los MI propuestos en

[5], por lo cual se puede decir que en el grupo de empresas venezolanas que participaron en el estudio, se da la presencia de éstos.

Cabe señalar que en los casos uno (1) y ocho (8), el único modelo que no estuvo presente fue el modelo flujo. En los casos tres (3) y siete (7) no están presentes los modelos: web, en ambos casos, y, árbol y flujo, respectivamente. Para los casos dos (2) y seis (6) faltaron los modelos ciclo y onda para ambos casos, el modelo web y el modelo onda, respectivamente. Es decir, que los modelos que tienen mayor frecuencia de ausencia son los modelos flujo y web. Dado estos resultados, se pueden reagrupar todos los modelos según la frecuencia de la presencia. De esta manera se forman tres grupos: 1. En el primer grupo se incluyen los modelos que tienen la más alta frecuencia de

identificación (en ocho casos) y son semilla, anillo y célula. Este grupo contiene el modelo semilla que, según [5], está enfocado hacia el crecimiento, el modelo anillo está enfocado hacia el cambio y el modelo célula está enfocado hacia la funcionalidad de cada componente. De este modo, la primera agrupación puede reflejar la tendencia que tienen las organizaciones que están en ese grupo, hacia el cambio en su constante crecimiento es definiendo las funciones de cada unidad organizacional.

2. En el segundo grupo se incluyen los modelos que tienen presencia en seis (6) casos y son ciclo, onda y árbol. Este grupo contiene el modelo ciclo que, según [5], está orientado hacia un cambio evolutivo, el modelo onda que funciona en ciertos períodos y con cierta frecuencia, y el modelo árbol que se caracteriza por crecimiento con una estructura compleja y distribuida. Las causas de esta agrupación podrían ser las siguientes: el proceso de cambio es constante, cíclico y abarca diferentes estructuras.

3. En el tercer grupo se incluyen los modelos que tienen presencia en cinco casos (5) y son web y flujo. Este grupo contiene el modelo web que, según [5], describe redes y el modelo flujo que rastrea el curso de la información. La posible causa de esta agrupación podría ser que las organizaciones tienden hacia la estructura más flexible que les permite el uso de redes en su trabajo diario, optimizando la canalización de la información y recursos, entre otros. Tal como señala el análisis por los casos, estos modelos son los que fueron menos identificados en todos los casos.


463

Los resultados obtenidos indican que en dos (2) casos correspondientes al sector terciario se identificaron todos los modelos, lo que confirma la existencia de los modelos propuestos en [5] y la factibilidad de su implantación en las organizaciones venezolanas. En los casos correspondientes al sector secundario se encuentra mayor ausencia de modelos tales como web y flujo lo que lleva a la conclusión de que este sector está más expuesto a la entropía en sus procesos que el sector terciario y, también, que es menos flexible al respecto de los cambios tecnológicos. Los modelos semilla, anillo y célula, se identificaron en todos casos estudiados, lo que lleva a suponer que estos modelos, por sus características, reflejan mejor la tendencia de las organizaciones hacia el cambio y el crecimiento, a través de la implantación de nuevas tecnologías. Finalmente, por su tamaño, en las organizaciones medianas casi no está presente el modelo web porque está orientado más que todo a las estructuras distribuidas y no jerárquicas, las cuales son más propicias en las organizaciones grandes.

6. Conclusiones

El principal aporte de esta investigación es que los estudios de caso permiten corroborar que el modelo de identificación basado en características de los MI ayuda a identificar los modelos propuestos en [5] en las organizaciones venezolanas. La aplicación del modelo de identificación de MI en las organizaciones venezolanas puede ampliar el conocimiento que éstas tienen sobre la integración de sus SI y TI, mejorando de esta manera los procesos de integración de sistemas que requieren para enfrentar el mercado tan competitivo como el actual.

Agradecimientos. Este trabajo fue financiado por el FONACIT a través del proyecto S1-200100792 y por la USB a través del Grupo de Investigación LISI - GID-043.

Referencias

1. Banco de la República Biblioteca Luís Ángel Arango (Colombia). Sector Real. En http://www.lablaa.org/ayudadetareas/economia/econo52.htm, s/f

2. Banco de la República Biblioteca Luís Ángel Arango (Colombia). ¿Cuáles son los sectores de la economía? En http://www.lablaa.org/blaavirtual/pregfrec/economia.htm

3. Basili, V., Caldiera, G., Rombach, H: Goal Question Metric Paradigm. Encyclopedia of Software Engineering, J. J. Marciniak (ed.), John Wiley & Sons, New York (1994)

4. Brand, S.O.: Diccionario de economía, Vol. 8. Editorial Plaza & Janes, Colombia (1985) 5. Brown, L: Integration Models: Templates for Business Transformation. USA (2000) 6. Diccionario de la Real Academia Española. Vigésima primera edición, Madrid (1992) 7. Hodge B.J., Anthony, W.P., Gales, L.M: Teoría de la Organización. Un Enfoque Estratégico.

5ta edn. Prentice Hall Iberia, S.R.L, Madrid (1998) 8. CIR-UNET, Revista Táchira Exporta 2002/2003, San Cristóbal (2002)


464

Hacia un Sistema de Información para Apoyar la Gestión de la Educación a Distancia

Luis Ramos1 y Richard Gil2

1 Universidad Nacional Abierta, Área de Ingeniería Industrial del Centro Local Aragua,

Venezuela [email protected]

2 Universidad Simón Bolívar, Decanato de Investigación y Desarrollo, Dpto. De Procesos y

Sistemas. Edif. Matemáticas y Sistemas Valle de Sartenejas 89000 Baruta, MI – Venezuela [email protected]

Resumen. El acceso a la Educación Superior y la calidad de la misma son afectadas por un conjunto amplio de variables dinámicas, muchas de ellas han sido estudiadas de manera separada y en conjunto en algunas oportunidades, entre estas variables destacan las socioeconómicas, tecnológicas, cognoscitivas y organizativas. Cuando se evalúan en conjunto aparecen entidades categorizadas con interrelaciones complejas que requieren un lenguaje común para poder comunicarse e intercambiar información. Para representar el conjunto explícito e implícito de estas entidades y sus relaciones, se ha plateado un modelo basado en el paradigma ontológico y se ha representado computacionalmente utilizando una herramienta de la tecnología semántica denominada Protégé, el producto pretende ser la ontología de la dimensión considerada en el dominio del modelo estudiado, que para este caso concreto es de la Educación a Distancia en Latinoamérica. El sistema propuesto será la base tecnológica que permitirá poner en práctica algunas premisas teóricas de una educación económicamente sustentable, que use la tecnología disponible al estudiante, que forme ciudadanos independientes y que sea efectivo en nivel de aprendizaje y número de egresados.

Palabras Claves: Educación a Distancia, ontología, Protégé.

1 Introducción

El uso de sistemas de información basados en computadoras es cada día más amplio en todas las áreas del quehacer humano y la educación como parte de ella, no escapa de esta realidad. En los países desarrollados se encuentran nuevas aplicaciones a diario, pero en los países subdesarrollados existen limitaciones tecnológicas y económicas de parte de los gobiernos de turno como de los potenciales usuarios. Estas limitaciones han dado base a


465

diversos autores para denominar “brecha digital” a este fenómeno [1]. A pesar de estas afirmaciones, la UNESCO ha señalado que las tecnologías de la información y comunicación no son la panacea de la educación para todos, siendo sólo una herramienta más de las que existen y que lo importante es saber qué herramienta utilizar en un contexto determinado [2]. Considerando las afirmaciones anteriores, Ramos & Gil [3] presentaron un modelo teórico de sistema de información para apoyar la gestión de la educación universitaria a distancia que considera cuatro macro variables, a saber: tecnológica, cognoscitiva, económica y administrativa. Estableciendo las relaciones entre cada una de estas variables y las componentes principales de las mismas, el sistema debería indicarle al estudiante o a su asesor qué modelo administrativo debería seguir y qué tecnología educativa debería usar para sus estudios (presencial ó a distancia), a partir de la información del nivel económico del estudiante, su estilo cognitivo y la tecnología que tenga a su disposición.

2 Ontología de Sistemas, Estableciendo un Lenguaje Común

La jerarquía de la informática incluye (desde abajo hacia arriba) los conceptos de los datos, información, conocimiento, experiencia, sabiduría e ingenuidad [4]. Las computadoras han ido escalando progresivamente esta jerarquía, pues los datos, información y cierto conocimiento están almacenados de manera convencional en las computadoras, similarmente a la propuesta de Iraset Páez sobre la pirámide Informacional [5]. A medida que se sube en las escalas se inmiscuye más intelecto humano y menos poder computacional, eso se debe que a estos niveles se requiere más inteligencia (humana o artificial). Desde los años 80 se viene incrementando el nivel informático de las computadoras, al tiempo que estas vienen asumiendo el rol de herramientas de soporte de infraestructura de conocimiento, sobre lo cual se construyen los sistemas expertos y sistemas de soporte de decisiones basados en inteligencia artificial. Ahora bien, cuando se acerca una situación de llevar los sistemas computacionales a los niveles de conocimiento y comprensión, se debe enfrentar con la interrogante planteada por Winograd y Flores de: ¿qué significa aprender? ó ¿qué se puede aprender?, esta última pregunta es uno de los asuntos centrales de la filosofía [6].

Los racionalistas aceptan la existencia de una realidad objetiva, en la que el conocimiento se convierte en un almacén de representaciones, las cuales se pueden usar para razonar y convertir dicho razonamiento en lenguaje. De acuerdo con Kant (1781), una pregunta clave es: ¿qué estructura usa nuestra mente para capturar la realidad?. La respuesta a esta pregunta está en la categorización de Kant, él obtuvo esta categorización partiendo de la categorización lógica del juicio.

Los sistemas de información no actúan exactamente de acuerdo con el proceso de percepción y comprensión propuesto por Kant. Aunque, este nuevo acercamiento se puede aplicar a los sistemas de información corrientes [7]. También Heidegger, argumentó que la comprensión práctica es más fundamental que la comprensión teórica. Se tiene más


466

acceso al mundo real por medio de experiencia práctica con lo que está a mano [8]. El estudio de la categorización de las cosas que pueden existir en algún dominio del mundo o la realidad se le denomina ontología [9]. El producto es un catálogo de tipos de cosas, las cuales se asume que existen en ese dominio de interés desde la perspectiva de una persona o grupo de personas que usa un lenguaje específico, con el propósito de hablar acerca de ese dominio. Uschold y Jasper definen a una ontología como: “Una ontología puede tomar variedad de formas, pero necesariamente incluirá un vocabulario de términos y algunas especificaciones de su significado. Esto incluye definiciones y una indicación de cómo los conceptos están interrelacionados lo cual colectivamente impone una estructura en el dominio y restringe la posible interpretación de términos” [10].

Se puede afirmar que las ontologías buscan capturar conocimiento consensuado en forma genérica, para que pueda ser reusado y compartido a través de aplicaciones de software y por grupos de personas. Lo deseable es que sean construidas de manera cooperativa por diferentes grupos de personas en diferentes localidades. Las ontologías pueden ser de peso ligero (Light Weight), sí incluyen sólo conceptos, taxonomías de los conceptos, relaciones entre conceptos y propiedades que describen conceptos; ó de peso pesado (Heavy Weight), sí se le adicionan axiomas y restricciones a la ontología de peso ligero. Para este caso, se desarrolló una ontología de peso ligero. Hay una gran cantidad de sistemas, tales como plantas industriales, negocios, bases militares y universidades en las cuales las ontologías son relevantes e igualmente importantes. En estos sistemas humanos el desarrollo de ontologías se debe principalmente a que esto permitirá el uso de un lenguaje común que facilitará la comprensión, diseño, desarrollo y gerencia de tales sistemas efectivamente. Consecuentemente, resulta útil adaptar las tradicionales técnicas ontológicas usadas en las ciencias naturales a estos dominios [11].

3 Metodología

Entre las diversas metodologías para desarrollo de ontologías se encuentra la Methontology, la cual permite la construcción de ontologías en el nivel de conocimiento y es la que propone la descripción más ajustada de cada actividad a realizar [7]. La Methontology propone un ciclo de vida de construcción de la ontología (Fig. 1) basado en prototipos evolutivos, porque esto permite agregar, cambiar y remover términos en cada nueva versión (prototipo). Para cada prototipo, la Methontology se inicia con una actividad de planificación, después se inician las actividades de desarrollo (especificación, conceptualización, formalización, implementación, mantenimiento), junto con las actividades gerenciales (control y aseguramiento de la calidad) y las actividades de soporte (adquisición de conocimiento, integración, evaluación, documentación, gerencia de configuración). Todas estas actividades se realizan en paralelo.

El proceso de especificación consistió en responder a algunas preguntas: ¿Cuál es el dominio que la ontología cubrirá? ¿Para qué se usará la ontología? ¿Para qué tipos de preguntas la información en la ontología debería proveer respuestas? ¿Quién usará y


467

mantendrá la ontología? Después de responder a estas preguntas se pasó a desarrollar el modelo conceptual (conceptualización). Se incluyen los términos que se usaran en la ontología, se clasifican a estos términos según sus niveles y/o jerarquías conceptuales, se crean las instancias y atributos de cada concepto y se describen cada uno de los componentes de la ontología. Seguidamente se pasó a la formalización, proceso mediante el cual se convierte el modelo conceptual en un modelo formal o semi computable. La implementación, convierte al modelo formalizado en un modelo computable, a través de un lenguaje para construcción de ontologías. Estas dos últimas etapas se desarrollaron con Protégé, herramienta de software para el soporte de desarrollo de ontologías.

Fig. 1. Proceso de Desarrollo y Ciclo de Vida de la Methontology. Tomado de “Ontological Engineering”. Por Gómez – Pérez, 2005 (p. 127). Traducción de los autores.

4 Software para la representación de la ontología

Entre las diversas herramientas para desarrollo de ontologías se encuentra Protégé. Esta es una herramienta de código abierto y arquitectura expandible que le permite a los expertos construir bases de conocimiento de manera más directa [12]. Permite hacer modelos de conocimientos basados en “frames” (marcos) y otros basados en el Lenguaje Ontológico Web (OWL), que podría ser usado en configuración Lite, Lógica Descriptiva (DL) o Full [13]. Para este caso se usó el modelo de conocimiento basado en lenguaje OWL en la versión Lite por tratar de representar una ontología de peso ligero (Light weight). La interface de usuario se configura fácilmente, contiene una serie de pantallas llamadas Tabs, cada pantalla muestra un aspecto diferente de la ontología en una vista especializada [14]. Algunas de estas Tabs son las Clases, que muestran la jerarquía de las clases de la


468

ontología, las Propiedades, que permiten editar relaciones entre las clases, los Individuos, que permiten editar los valores individuales de cada clase y los Formularios, que permiten editar información acerca de las propiedades y los individuos que le corresponden a cada una de las clases consideradas en la ontología. Se agregaron dos Tabs adicionales, uno denominado jambalaya, que permite ver todos los componentes de la ontología gráficamente y una de preguntas (queries), con la que se estructuran preguntas al sistema, para confirmar la consistencia de la misma.

5 Resultados

En la Fig. 2 se puede observar una pantalla de la ontología desarrollada en Protégé OWL Lite. Del lado izquierdo está la jerarquía de clases y del lado derecho aparece una representación en jambalaya.

Fig. 2 Ontología desarrollada en Protégé OWL Lite versión 3.3 beta.

En la Fig. 3 se muestra la pantalla (Tab) de preguntas donde se verificó la consistencia de la ontología del sistema desarrollado, en donde interesa saber si se da respuestas a las interrogantes planteadas en la etapa especificación de la ontología. Para este caso del lado izquierdo se configuró la pregunta, que consideró a la clase “Administración”, que contiene a las formas de administración de la educación, ya sea presencial o a distancia, estando esta última a su vez constituidas por la administración industrial, de baja escala e interactiva; a la propiedad “tienequeusarlibros” junto con la individualidad


469

“softwareinteractivo” y para este caso el resultado de la búsqueda fue la clase de “Administración” denominada “En línea”, la cual corresponde con el criterio del experto que brindó su conocimiento para el desarrollo del sistema, y puede ser observada en la parte superior derecha de la pantalla. La ontología desarrollada en este trabajo es un primer acercamiento con la intención de desarrollar un sistema completo de apoyo a la gestión de la educación a distancia, que debe pasar por un proceso más amplio de verificación y validación con pruebas de completitud y consistencia. Usando también algunas herramientas tecnológicas de validación como la denominada Racer ® y haciendo evolucionar la ontología a niveles mayores de lenguaje como lo son OWL DL y OWL Full.

Fig. 3 Verificación de la consistencia de la ontología del sistema desarrollado

5 Conclusiones

a. Este desarrollo demuestra que existe la posibilidad de que expertos en áreas distintas a la Ingeniería de Sistemas, puedan desarrollar sistemas expertos de mediana complejidad basándose en el paradigma ontológico. b. Para lograr lo planteado en el punto anterior se requiere que los expertos de un dominio determinado especifiquen los conceptos y las relaciones que existen entre ellos, de una manera no ambigua y precisa para que se pueda representar en un computador. c. En la actualidad existen diversos software para la representación del conocimiento por medio de ontologías, el investigador sólo ha usado Protégé, debido a la facilidad con la


470

que puede ser descargado gratuitamente de la página Web de la Stanford University y, a que este software es recomendado en algunas de las bibliografías especializadas en el tema, existiendo también amplia documentación y ejemplo de su uso en Internet. d. El sistema propuesto, luego de hacerle una validación más amplia, podría usarse como herramienta virtual de asesoría para los estudiantes universitarios, que ayude a seleccionar tecnologías educativas y técnicas de estudios lo más efectivas posibles, debido a que en la educación de un ser humano intervienen un grupo amplio de variables con interrelaciones complejas.

Referencias

1. Casacurbeta, D. E – learning e Inclusión Social en el Marco del Sistema Universitario Español. (2004). Disponible en: http://www.uoc.edu/rusc/dt/esp/casacuberta0704.pdf. [Consulta: 2006, marzo.]

2. UNESCO. Education in and for the Information Society. (2003). Disponible en: http://portal.unesco.org/ci/en/file_download.php/60a203d894a4002ada6bc3e4232d6d5ceducation.pdf. [Consulta: 2006, marzo.]

3. Ramos, L. & Gil, R. Propuesta de Marco de Referencia de Sistema de Información para apoyar la Gestión de la Educación a Distancia. Ponencia presentada en el XIII Congreso Internacional de Tecnología y Educación a Distancia. Costa Rica. (2006)

4. Dori, D. Object – Process Methodology.(1ra Edición) Berlin: Springer. (2002) 5. Páez, I. Gestión De La Inteligencia, Aprendizaje Tecnológico Y Modernización Del Trabajo

Informacional. Retos Y Oportunidades, UNESCO Caracas. (1992) 6. Winograd, T & Flores, F. Understanding Computers and Cognition. MA. Addison – Wesley.

(1978). 7. Gomez – Perez, A, Gomez – Perez, M & Corcho, O. Ontological Engineering. (4ta reimpresión).

Londres: Springer. (2005). 8. Heidegger, M. Being and Time. Nueva York. Harper & Row. (1962). 9. Sowa, J. Principles of Ontology. (2001). Disponible en: http://www.kls.standford.edu/onto-

std/mail-archive/0136.htlm. [Consulta: 2006, marzo]. 10. Uschold, M. & Jasper, R. A Framework for Understanding and Classifying Ontology

Applications. Ponencia presentada en: Benjamins VR (ed) IJCAI’99 Workshop on Ontology and Problem Solving Methods: Lessons Learned and Future Trends. Estocolmo, Suecia. (1999). Disponible en: http://CEUR-WS.org/Vol-18/

11. IDEF Family of Methods. A Structured Approach to Enterprise Modeling and Analisis. (2001). Disponible en: www.idef.com. [Consulta: 2006, marzo].

12. Gennari, J & otros. The evolution of Protégé-2000: An environment for knowledge-based systems development. International Journal of Human- Computer Studies, 58(1) (2003) 89–123.

13. Noy, N, Fergerson, R & M. Musen, M. The knowledge model of Protégé-2000: Combining interoperability and flexibility. In 2nd International Conference on Knowledge Engineering and Knowledge Management (EKAW’2000), Juan-les-Pins, France. (2000).

14. Knublauch, H & Musen, M. (s.f). Editing Description Logic Ontologies with the Protégé Owl Plugin. Disponible en: http://protege.stanford.edu/plugins/owl/publications/DL2004-protege-owl.pdf. [Consulta: 2006, octubre].


471

Diseño de un Sistema Multiagente para la Gestión de Recursos usando la

Metodología MAS CommonKADS

Serrano Juan F. , Suros Rina

Universidad Central de Venezuela, Facultad de Ciencias. Centro de Computación Paralela y Distribuida. Caracas, Venezuela.

[email protected], [email protected]

Resumen. En este artículo se presenta el proceso de modelado de un sistema para la gestión de recursos de redes de alta velocidad, basado en agentes y se desarrolla un caso de estudio. Para el diseño se utiliza una metodología orientada a agentes llamada MAS CommonKADS. Esta metodología es una extensión de la metodología CommonKADS que añade aspectos relevantes para sistemas multiagentes integrando técnicas de orientación a objeto y de diseño de protocolos. El modelo de ciclo de vida para el desarrollo de la metodología contempla las fases de conceptualización análisis y diseño, bajo el modelo en espiral dirigida por riesgo. La aplicación de la metodología consistió en la implementación de cada uno de los modelos que la conforman, facilitando el despliegue e integración de los componentes del sistema de manera natural y el proceso de desarrollo de software. Este sistema multiagentes se adapta a medios complejos, dinámicos y geográficamente distantes.

Palabras clave: Sistemas Multiagentes, MAS CommonKADS, Metodologías Orientadas a Agente, Inteligencia Artificial Distribuida, Gestión de Recursos.

1 Introducción

El diseño de herramientas para la detección, asignación, uso, monitoreo y control de los recursos y de la ejecución de aplicaciones en sistemas distribuidos sobre redes de alto rendimiento es un problema complejo. En la actualidad, sobre una red de alto rendimiento el usuario cuenta con tecnologías middleware para el desarrollo de aplicaciones en entornos de computación ubicua, que presentan grandes limitaciones en cuanto al manejo optimo de las enormes capacidades de computo distribuido y almacenamiento de datos distribuido que nos ofrecen este tipo de redes, cuyas dificultades fundamentales son: la dinámica con la cual varia la disponibilidad de los recursos y la distancia geográfica en la que se encuentra ubicado el recurso optimo para la aplicación que deseamos ejecutar. La idea central de este artículo es el diseño de un sistema multiagentes para la gestión de recursos en un medio complejo, dinámico, geográficamente distante [10].


472

Existen problemas que requieren de muchos recursos para realizar una gran cantidad de cómputos que le permita alcanzar una solución óptima en un tiempo determinado. Resulta poco probable encontrar una forma de distribuir la responsabilidad de la gestión de recursos de un modo que convenga a todas las aplicaciones, sin embargo, la distribución de la gestión de recursos de forma dinámica permitiría que distintos tipos de aplicaciones la implementen según su conveniencia.

En este artículo se presenta una solución al problema planteado utilizando la metodología MAS CommonKADS [1], que permite cubrir las características más relevantes en el modelado de un sistema multiagente para la gestión de recursos computacionales en redes de alta velocidad.

La organización de este artículo es la siguiente. En la Sección 2 se realiza una breve descripción de la metodología MAS CommonKADS. En la sección 3 se aplica la metodología al problema de asignación de recursos computacionales en redes de alta velocidad y finalmente en la Sección 4 se presentan las conclusiones y los trabajos a realizar a futuro.

2 Metodología MAS CommonKADS

MAS CommonKADS es una extensión de la metodología CommonKADS [2] considerada un estándar de facto en el desarrollo de sistemas inteligentes, que añade aspectos relevantes para los SMA e integra técnicas de las metodologías de orientación a objeto para facilitar su aplicación [4]. La metodología MAS CommonKADS define siete modelos para el desarrollo de SMA, implementados pasa a paso como se muestra a través del desarrollo del problema objeto de estudio. Previo al desarrollo de los modelos, presenta una fase de conceptualización en la que se hace una introducción al sistema, utilizando la técnica de casos de usos basados en el usuario [3], con el objeto de determinar los primeros elementos que conforman el sistema, las relaciones entre los procesos y principalmente la interacción del usuario con el sistema. La aplicación de esta metodología se fundamenta en el desarrollo de los diferentes modelos, definiéndose plantillas textuales en cada uno de los modelos, para la descripción de los agentes identificados en el sistema [1].

3 Gestión de recursos en redes de alta velocidad

A continuación presentamos la aplicación de la metodología MAS CommonKADS para desarrollar un gestor de recursos, elemento encargado de decidir cómo ha de llevarse a cabo el despliegue de una aplicación de forma que su rendimiento sea el adecuado de acuerdo a criterios predefinidos, y lograr que las aplicaciones puedan aprovechar el rendimiento potencial de una red de alta velocidad. Se presentan resultados obtenidos producto del desarrollo de la metodología a través de todas sus fases.


473

3.1 Fase de Conceptualización

Durante esta fase se hace una introducción general al sistema. Se utiliza la técnica de casos de usos basados en el usuario, con el objetivo de determinar los elementos que conforman el sistema, las relaciones entre los procesos y la relación del usuario con el sistema [1]. Para identificar los actores relacionados con el sistema, se realiza una breve descripción del problema.

3.1.1 Descripción del problema Un usuario desea tener acceso a la red de alta velocidad y solicitar recursos para la ejecución de una aplicación. El usuario debe acceder al sistema y autenticarse. Posteriormente el sistema lo autoriza, ingresa e introduce información suficiente relacionada con la aplicación y recursos que requiere. El sistema procesa la solicitud: ingresa la aplicación, se leen sus requerimientos y se inicia la búsqueda de los recursos solicitados. El sistema recibe la información necesaria sobre los recursos y se elige el recurso disponible considerando políticas de asignación definidas, bien sea por defecto o por selección según métricas establecidas, y se realiza el envío efectivo de la aplicación al recurso. El servicio de información local monitorea la aplicación y envía notificaciones sobre estado de la misma, que le son entregadas al usuario de ser requeridas por éste. Una vez concluida la ejecución de la aplicación el servicio de información local envía la información al usuario y el gestor local procede a eliminar la información generada por el proceso de ejecución.

3.1.2 Identificación de actores Actores principales: - Usuario: accede al sistema vía portal Web - Scheduler: planificador de aplicaciones de alto nivel - Buscador de Recursos: buscar los recursos según requerimientos

de la aplicación introducidos al sistema por el actor usuario - Monitor Global: monitorea estado de los recursos Actores de apoyo: - Monitor local: supervisa el estado de los recursos locales - Gestor local: planificador local

3.1.3 Casos de usos Los casos de usos identificados en el sistema son los siguientes: solicitar recursos, planificar asignación de recursos, buscar recursos, supervisar recursos, gestión local de recursos, enviar aplicación. Los diagramas de casos de uso no se muestran por limitaciones de espacio.


474

3.2 Modelo de Agente

Considerando la fase previa de conceptualización, resulta conveniente identificar los agentes y analizar sus tareas para mostrar la descomposición funcional del sistema. Se identificaron los agentes del sistema, objetivos y otras características importantes, tal y como se describe durante el desarrollo del modelo. Se identificaron los agentes Interfaz de Usuario, Scheduler, Buscador de Recursos, Monitor Global y Monitor Local. Otras características de interés se señalan en la plantilla textual del modelo de agentes. Presentamos la descripción del Agente Interfaz de Usuario según la plantilla textual MAS CommonKADS, ver Tabla 1.

3.3 Modelo de Tarea

Identificados los agentes, se procede a definir las tareas a realizar por cada uno de ellos para alcanzar los objetivos propuestos. MAS CommonKADS no presenta una estructura grafica para modelar las tareas. A continuación presentamos el diagrama de actividades para el Agente Interfaz de Usuario descrito en la plantilla textual del Modelo de Agente en la sección anterior, ver Fig. 1.

Fig. 1. Diagrama de Actividades del Agente Interfaz de Usuario.


475

3.4 Modelo de Coordinación

Este modelo permite establecer las relaciones dinámicas existentes entre los agentes que conforman el sistema multiagente, es decir, especificar las interacciones de los distintos agentes involucrados en la resolución del problema. Se basa fundamentalmente en la definición de los canales de comunicación y el análisis de las interacciones entre agentes (identificación y descripción de conversaciones e intervenciones). Resume las relaciones dinámicas entre los agentes una vez desarrolladas las interacciones válidas y permitidas entre ellos.

3.5 Modelo de Comunicación

El objetivo de este modelo es modelar las interacciones hombre - máquina. Para modelar esta interacción, se debe descomponer el dialogo entre el usuario y el sistema indicando cuales transacciones se dan. El diagrama de comunicación considera la intervención del usuario a través del Agente Interfaz de Usuario con los demás agentes del sistema. Uno de los aportes más significativos de este modelo, es especificar las distintas interacciones entre los agentes que trabajan para resolver el problema planteado.

Tabla 1. Plantilla textual del Modelo de Agente correspondiente al Agente Interfaz de Usuario.

Agente Interfaz de Usuario Nombre: Interfaz de Usuario Tipo: Agente de gestión Papel: Interfaz de acceso a la red de alta velocidad Posición: Dentro de los agentes del sistema Descripción: El agente interfaz de usuario permite al usuario acceder a su certificado privado para su autenticación. Establece comunicación con el usuario a través de la interfaz definida, recibe comandos de usuario para realizar tareas específicas, procesa peticiones y las pasa a los distintos componentes para ser procesadas. Establece los mecanismos de seguridad a través de los protocolos y mecanismos del Middlewere de la red. Objetivo: Brindar al usuario la posibilidad de acceder a la red y solicitar recursos Parámetros de entrada: Perfil de usuario y requerimientos de la aplicación a ejecutar Parámetros de salida: Resultados generados al ejecutar la aplicación Servicio: Brinda la posibilidad a través de un portal Web de solicitar recursos Experiencia: Ninguna Comunicación: Agente Scheduling Coordinación: Administrador de la cola de aplicaciones, Agente Scheduling

3.6 Modelo de Organización

El modelo de organización de MAS CommonKADS nos permite modelar las relaciones estructurales entre agentes. Este modelo describe tanto la organización humana como la sociedad de agentes. Define las relaciones estáticas existentes entre los diversos agentes


476

software que constituyen el sistema multiagente. La estructura organizativa del sistema de gestión de recursos que se está desarrollando, se fundamenta en un tipo de agente: Agentes Software. Las comunicaciones permitidas se muestran en la descripción de los canales básicos de comunicación. La Fig. 2 ilustra la arquitectura del sistema en desarrollo.

3.7 Modelo de Experiencia

El desarrollo del Modelo de Experiencia del sistema se inicia con la identificación de las tareas genéricas. La identificación de las tareas genéricas consiste en determinar la estructura de inferencia para cada tarea del modelo de tareas, que requieran conocimiento. La Fig. 3 muestra el diagrama de inferencias del proceso validar usuario relacionado con el Agente Interfaz de Usuario.

Fig. 2. Arquitectura del sistema multiagente.

3.8 Modelo de Diseño

El desarrollo de este modelo nos permite determinar y documentar la infraestructura de red para el sistema multiagente, de igual manera, el diseño del agente, su arquitectura y el ambiente de desarrollo del sistema multiagente. El diseño de la arquitectura del agente no se considera en la metodología, es proporcionada por la plataforma del desarrollo del agente.

Fig. 3. Diagrama de Inferencias del proceso validar usuario.


477


En este trabajo se presenta el proceso de modelado de un sistema para la gestión de recursos en redes de alta velocidad. Para el diseño se utiliza la metodología orientada a agentes MAS CommonKADS que cubre el desarrollo de todo el ciclo de vida de un sistema multiagente a través del desarrollo de siete modelos, sin presentar ningún tipo de restricción con respecto al número de agentes presentes en él. Su uso se basa en procedimientos bien conocidos que facilitan el aprendizaje de la metodología y además, define plantillas textuales para cada modelo que permiten la descripción de los agentes, sus características y la estructura del SMA. Como resultado se obtienen los modelos de agentes, tareas, comunicación, coordinación, organización, experiencia y diseño. Para cada modelo de la metodología, hemos demostrado el proceso estándar de desarrollo y la notación gráfica. Nuestro esfuerzo se centró en la implementación de la metodología en el modelado de un sistema basado en agentes distribuidos. Las redes de alto rendimiento son redes de mucha complejidad y el paradigma orientado a agentes contribuye significativamente en el diseño de soluciones adecuadas. En este sentido, la utilización de MAS CommonKADS en el modelado de un SMA como parte de la Inteligencia Artificial Distribuida, demuestra que se pueden obtener soluciones para un problema de alta complejidad, permitiendo el desarrollo de todo el ciclo de vida del software de manera general. MAS CommonKADS es lo suficientemente completa para permitir el desarrollo de sistemas multiagentes robustos y complejos. Sin embargo, a pesar de que la metodología CommonKADS tiene un modelo de agente, no cubre aspectos relevantes de los agentes, es decir, no ofrece facilidad alguna para modelar interacciones entre agentes, lo que dificulta su aplicabilidad en el caso de SMA. Una extensión interesante de esta investigación es el uso de metodologías de diseño para sistemas multiagentes que integren un ambiente que permita generar códigos.

Referencias

1. Iglesias, C.: Definición de una Metodología para el Desarrollo de Sistemas Multi-Agente. Tesis Doctoral. Departamento de Ingeniería de Sistemas Telemáticos, Universidad Politécnica de Madrid. España (1998)

2. Henao, Mónica.: CommonKADS-RT: Una Metodología para el Desarrollo de Sistemas Basados en el Conocimiento de Tiempo Real. Tesis Doctoral. Valencia. España. (2001)

3. J. Rumbaugh, I. Jacobson, G. Booch, The unified modelling language reference manual. Addison Wesley (1999)

4. Mas A.: Agente Software y Sistemas Multiagente. Pearson Prentice Hall S.A., Madrid. España (2005) 5. Ricordel, P.M.: Programmation Orientée Multi-Agents, Développenment et Deploiement de

Systèmes Multi-Agents Volleyes, Institut National Polytechnique de Grenoble (2001) 6. Russell, S. y Norvig, P.: Artificial Intelligence: a Modern Approach. Prentice Hall (1995) 7. Tanenbaum A.S.: Sistemas Operativos Distribuídos. Prentice Hall Hisp., S.A., México (1996) 8. Tansley, D. S. W. y Hayball, C. C.: Knowledge Based Systems Analysis and Design a KADS

Developer's Handbook. Prentice Hall (1993) 9. Wooldridge, M. J. y Jennings, N. R.: Agent Theories, Architectures, and Languages: A Survey. Actas


478

de conferencia. Springer-Verlag (1995) 10. Wooldridge M., N.J., D. Kinny, The Gaia Methodology For Agent-Oriented Analysis and Design.

International Journal Of Autonomous Agents And Multi-Agent Systems, (2000) 11. High-Performance Networks for High-Impact Science. Report of the August 13-15, 2002; Workshop

Conducted by the Office of Science, U.S. Department of Energy High-Impact Science Scenarios. http://www.doecollaboratory.org/meetings/hpnpw/finalreport/high-impact_science.pdf

12. Timothy Callahan and Seth Copen Goldstein ftimothyc, ISCA A Low Overhead, High Throughput Network Interface http://citeseer.ist.psu.edu/callahan95nifdy.html

13. Zambonelli F., J.N.Y.W.M., Developing Multiagent System: The Gaia Methodology.Acm Transactions On Software Engineering And Methodology., (2003) 317-370


479

Estado del Arte sobre el uso del LDAP como Estructura Alternativa para Regular Infraestructuras de

Clave Pública (PKI) en Ambientes Empresariales

Gabriel Moline, John Delgado

Fundación Instituto de Ingeniería, Centro de Ingeniería Eléctrica y Sistemas, Urb. Monte Elena, Parque Tecnológico, Universidad Simón Bolivar, Municipio Baruta, Caracas, Venezuela

{gmoline,jdelgado}@fii.org

Resumen. En este documento se explorarán los posibles usos del LDAP, como estructura adecuada para almacenar atributos, los cuales no son par-te integrante de los certificados, pero son de un gran valor agregado para la gestión de atributos a nivel empresarial; de esta forma se logrará brindar mayor economía dentro de la definición de los atributos del certificado, definiendo variables globales de control sobre cada cliente, los cuales de-seen acceder a la infraestructura, validarse o verificarse dentro de una pla-taforma basada en una Infraestructura de clave pública.

Palabras clave: LDAP, certificación electrónica, PKI, X.509, Atributos de certificados, ambiente empresarial, Infraestructura de Clave Publica.

1 Introducción

Uno de los principales retos, que padecen las organizaciones al momento de implantar una infraestructura de claves públicas, es la diferenciación entre identidad electrónica y atributos electrónicos. Al hablar sobre identidades y certificación electrónica, se debe definir el estándar x509v3, este consiste en un estándar UIT (Unión Internacional de Te-lecomunicaciones) para infraestructuras de claves públicas, en donde se especifica entre otras cosas, el formato de atributos estándares para los certificados de claves públicas, este estancar da un serie de libertades dentro del esquema de definición de los atributos del certificado. Por ende básicamente los elementos dentro de la estructura x.509v3 son atributos en la mayoría de las organizaciones, pero las organizaciones no emiten identida-des sino enriquecen atributos normados por el ente regulador de la infraestructura o en su defecto por el suplidor de la infraestructura. Por ende el cliente pierde su identidad y co-mienza a ser un cúmulo de atributos dentro de la estructura del X509v3 [8].

Consciente de la problemática y tomando en cuenta que el certificado electrónico no es una estructura con capacidades para crecer de forma indefinida, en este articulo propone-mos la idea de usar un repositorio alternativo, para de esta forma vincular los atributos del certificado en contraste con atributos de identidad propios de la persona mas otros atribu-


480

tos (estados) de importancia; los cuales pueden estar vinculados con el estatus del certifi-cado como método alternativo para acceder a su condición.

Dentro del estándar x.500v3 [4] se contemplan 2 proposiciones para la verificación del estatus de los certificados, estos son los Certificate Revocation List (es una lista negra de los certificados revocados por la Autoridad de Certificación(CA)) y el contemplado en el RFC2560 denominado Online Certificate Status Protocol, la contradicción principal res-pecto al funcionamiento de estos dos métodos es: dado que se intenta consultar la CA (CRL O OSCP) para verificar el estatus del certificado, cuál es la ganancia de ingresar atributos al certificado y atributos de identidad a la estructura del certificado? (tomando en cuenta que el crecimiento del certificado no tiene ningún propósito), y dado que se realice algún tipo de operación con el certificado, con cuál regularidad los aplicativos tienen la capacidad de realizar validaciones por los atributos internos de los certificados? [4].

Por ende, es de suma importancia agregar al repositorio alternativo, la funcionalidad de verificar y constatar el estatus de la validación del certificado. Las ideas plasmadas en estos documentos son producto de las discusiones realizadas, enmarcadas dentro de la implantación del primer proveedor de servicios de certificación del estado venezolano. La estructura de este documento se precisan de la siguiente forma: en la sección 2, se mues-tran los problemas de verificación de identidad implementadas en entornos empresariales orientados al uso del estándar x509v3. En la sección 3 se explica como opera el LDAP como una estructura de soporte. En la sección 4 se define la concepción de una infraes-tructura de gestión de privilegios basada en un LDAP. En la sección 5 se plasman las conclusiones obtenidas sobre el trabajo que se esta realizando y la sección 6 establece las referencias del documento.

2 Problemas de Verificación de Identidad Implementada en Entornos Empresariales Orientados al Uso del Estándar x509v3.

Cuando es requerida que la seguridad dentro de los entornos empresariales sea provista mediante el uso de certificados electrónicos, es usual que requieran servicios que en la mayoría de los casos son provistos por consorcios del área de infraestructuras de claves publicas. Estas empresas al momento de realizar una modificación sobre los atributos de los certificados, propician el uso de estructuras personalizadas, lo cual se traduce en tiem-pos de desarrollo y en altos costos de inversión para el cliente. Concluyendo con esto, que la mayoría de los proyectos de PKI son implantados sobre estructuras planas de atributos por tener básicamente un ahorro a nivel económico. Dentro de las problemáticas encon-tradas, en el uso de certificación electrónica, se pueden enunciar las siguientes: [2,3]. a) La mayoría de las herramientas realizan verificación de usuarios mediante el DN (Dis-

tinguished Name) sin verificar la estructura de confianza de la PKI, definida aun antes de la creación del certificado electrónico a analizar. Además de este inconveniente, es necesario aclarar que más del 90% de los atributos dentro de la estructura del certifi-cado no depende del cliente a verificar, por ende, donde esta la verificación de usua-rios?


481

b) Existe una problemática de realizar verificación de estatus sobre certificados electró-nicos en infraestructuras que sean susceptibles a estar offline o en su defecto estructu-rar un protocolo de contingencias para organizaciones que no puedan acceder por cualquier falla técnica al repositorio de CRL y OSCP. [2,3]

c) La complejidad y la curva de aprendizaje que deben afrontar los equipos técnicos, en el manejo, administración y mantenimiento de infraestructuras orientadas a una PKI, en contraste con la poca capacidad que pueda poseer el mantenimiento preventivo pa-ra evolucionar a correctivo.

2.1 Eventualidades del Uso de Dispositivos de Almacenamiento (smart-card, Dispositivo de Almacenamiento Criptográfico y otros) en Usuarios Finales.

El uso de smart-card y tokens son ampliamente conocidas para soluciones a nivel de usua-rios finales, elemento importante para fortalecer el almacenamiento de la clave privada, que es en donde radica el corazón de la infraestructura de claves públicas [1, 7]. Dentro del uso de estos dispositivos de almacenamiento, podemos definir su descripción y sus posibles inconvenientes en su uso: a) Tarjetas de Memorias: Son simples dispositivos que no garantizan ningún nivel de

aseguramiento, lo que de hecho es mal llamado dispositivo de almacenamiento seguro. b) Protección a través de tarjetas inteligentes: El uso de smart-card permite acceder des-

pués de validar un código de seguridad (PIN). El problema fundamental que conlleva esto, es que si el computador donde se esta realizando la acción posee un código mali-cioso, podría capturar el código de seguridad y tener la capacidad de sustraer la clave privada del certificado [2].

c) Protección a través de procesadores criptográficos: La idea de este tipo de dispositivos es almacenar y crear la clave privada y no tenerla en unos repositorios de tarjetas inte-ligentes. Con respecto a su problemática, se podría concebir que el servidor que tenga contacto sobre el dispositivo tenga un código malicioso que firme no solo el documen-to predestinado para esto, sino muchos mas, dado que el usuario quería realizar una transacción de firma digital; con el escenario anterior, cuando este usuario prosiga a realizar una verificación de versión con respecto al antivirus, este debería borrarlo no solo el software malicioso sino los logs y elementos de trazas que pudieron haber de-jado el uso del software sobre el paquete de firma electrónica.

Cuando se ejecuta un proceso de firma orientado hacia documentos, es mandatorio que el usuario deba ingresar un PIN, que no es mas que un código de seguridad que esta pro-tegiendo la clave privada inmersa dentro de la estructura de la tarjeta inteligente, con res-pecto a la situación antes planteada, es necesario para evitar esto, ingresar forzosamente el PIN cada vez que se ejecuta la acción de firma sobre un documento de forma electrónica. Es importante que si al usuario se le es solicitado ingresar el PIN 3 veces cuando solo se procede a firmar electrónicamente un solo documento, esto debe ser reportado ya que puede estar aconteciendo un acto ilícito.


482

3. LDAP Como Estructura de Soporte

El Light Directory Access Protocol es una versión simplificada del X.500 Directory Ac-cess Protocol; es un servicio el cual provee información básica sobre personas o servicios Web, así como teléfonos, direcciones de correo, organización, claves públicas de certifi-cados digitales, hash de claves, jerarquización de grupos, etc. El LDAP es una parte defi-nida por una base de datos y otra por un protocolo, muy similar al DNS (puede llegar a contener muchos mas datos). El LDAP es optimizado para buscar y soportar replicaciones de una misma información pero dividida entre varios servidores. Básicamente la habilidad de utilizar el LDAP, es realizar todas las acciones de acceso dado un usuario especifico, el cual debe y tiene permisos sobre distintas infraestructuras, es por ello que dado que se tiene la clave pública ingresada como parámetro del árbol del LDAP, fácilmente se podría utilizar este para verificar, para distintas infraestructuras la autenticación y autorización sobre recursos o datos [8].

3.1 Uso de Distintos Niveles de Verificación.

Dentro del uso del LDAP, se pueden estructurar varios niveles de jerarquización para la autorización y autenticación para la gestión de datos o el acceso a recursos. Dentro de la definición de los niveles, se puede definir los siguientes: a) Simple Autenticación Usuario /Contraseña: Esta es la estructura sobre el uso del al-

macenamiento de la clave en un algoritmo de hash, que básicamente esta compuesto por una función no biyectiva, la cual hace que este se encuentre publicado mas no esta a la luz de todos para ser usado. El problema sobre su almacenamiento y publicación, es que se debe definir un correcto criterio de uso, con respecto al algoritmo usado ya que debe ser seleccionado uno que no sea deprecado o fácil de atacar. Entre los que se puede encontrar comercialmente, podemos tener por ejemplo: SHA256, SHA385, SHA512, hay que tener cuidado con los algoritmos dependiente de SHA-x ya que han tenido buenos resultados atacándolos en los últimos 2 años. (Recomendamos SHA2-X).

b) Usando certificación electrónica: Aprovechando todas las virtudes del LDAP, es im-portante recalcar, dado que se define la publicación de claves públicas en la estructura, se puede utilizar una infraestructura de claves públicas para tener la autenticación y autorización de usuarios sobre recursos informáticos y datos.

c) Usando filtrado de Seriales sobre certificados: Dado que se toma en cuenta que existe una PKI, un certificado valido y un esquema de validación, la utilización de seriales de los certificados vienen dados para operadores y administradores de las plataformas de administración delegadas para permisos necesarios para tales roles.

Es importante recalcar que cada uno de estos métodos de autenticación y autorización, tienen la opción de ser implementados de forma simultanea, lo que trae como consecuen-cia que se ejecuten 3 tipos de permisos, 2 en el área de autenticación y uno en el área de autorización.


483

Se ha mostrado el poder del LDAP como un protocolo de gran utilidad [6], en caso de ser usado para autenticación y autorización de usuarios o servicios entre infraestructura, a continuación vamos a explicar cuales son los esquemas disponibles de seguridad, dado que tenemos que consultar un LDAP para el acceso a aplicaciones [5]. LDAP posee tres tipos de autenticaciones: Acceso anónimo.(Por ejemplo Ninguno), Acceso simple, a tra-vés de una clave convencional, esta podría ser capturada por un sniffer y Con SASL.

El uso de SASL Simple Authentication and Security Layer es un protocolo para auten-ticación de propósito general, capaz de ejecutarse sobre SSL o TCPIP. En principio, SASL, tiene la capacidad de trabajar con otros protocolos (como puede ser un LDAP), SASL trabaja con los siguientes mecanismos de autenticación: Anónimo. (RFC 2245), CRAM-MD5 (RFC 2195), Digest-MD5 (RFC 2831). Servicio externo. (RFC 2222). Kerberos V4.V5 (RFC 2222), SecurID (RFC 2808) (token), Secure Remote Password ( draft-burdis-cat-srp-sasl-06.txt), S/Key (RFC 2222), X.509 (draft-ietf-ldapext-X.509-sasl-03.txt).

4. Concepción de una Infraestructura de Gestión de Privilegios (IGP) Basada en un LDAP en Contraste con Atributos Dentro del Certificado.

El problema fundamental entre la utilización de una gestor de privilegios basado en un LDAP y el uso de certificados digitales del lado del cliente , es que en la actualidad , a nivel de clientes, no se encuentran dispositivos de almacenamiento criptográficos capaces de acelerar a nivel de SSL o crear peticiones sobre certificados de forma personalizada, por ende, es muy poco probable que cada cliente pueda tener una forma de traducir un certificado con muchos atributos en muchos atributos leídos desde un certificado. Dicho esto, el contenido dentro del certificado es in factible respecto a un proceso de autoriza-ción o autenticación. Los atributos dentro del certificado, están inmersos dentro de una dinámica desde los momentos de su creación, esto tiene que ver con poder entender la persistencia de los atributos y la forma como estos pueden variar en el tiempo, en contras-te con su operatividad respecto a un proceso de autorización o autenticación; estos ele-mentos son: a) Periodicidad: Capacidad que tienes los atributos de ser ampliamente repetidos dentro

de la estructura del certificado, por ejemplo: más de un certificado con la misma in-formación dentro del atributo. El problema fundamental es que un atributo que posee una característica de periodicidad no puede hacer el rol de elemento descriptivo por-que no es inequívoco.

b) Potencialidad: Se define como el criterio de selección que pueda tener cualquier atri-buto que es generado y almacenado dentro del certificado.

c) Capacidad descriptiva: Es la capacidad que posee una etiqueta de describir la informa-ción que va a contener el atributo. Este es altamente sensible porque puede ser mani-pulado y descubrir información que puede estar almacenada dentro del certificado. Por ejemplo: un certificado que posee un atributo denominado passwordsha1, básicamen-te describe que es un password y que posee un algoritmo de cifrado SHA1. Este ele-


484

mento es muy poco encontrado mas no deja fuera este escenario de mal diseño sobre los atributos del certificado.

Un problema que se posee cuando se realizar una lectura de atributos dentro de los cer-tificados, es que no se puede generar trazas de lectura sobre la estructura del certificado sino vagamente se puede ejecutar trazas de lectura sobre la plataforma que lee el certifi-cado. Dadas estas características y problemáticas en función de poder ejecutar un efecti-vo proceso de autorización y autenticación sobre una plataforma empresarial, se procede a definir lo relacionado con la infraestructura de gestión de privilegios.

4.2 Aplicabilidad de la Infraestructura de Gestión de Privilegios (IGP).

Dentro de la explicación que va definir la aplicabilidad de la IGP, se pueden definir pri-meramente los factores que la integran, es decir, un LDAP, un requerimiento basado en los atributos que describen un criterio de asignación de estado y una gama de estados que son definidos mediante la dinámica administrativa de los servicios o recursos dentro del ambiente empresaria:

La estructura del IGP debe poseer internamente los siguientes elementos: • La clave publica de los certificados generados dentro de la Autoridad de Certificación. • Una gama de elementos que consisten en atributos propios del usuario. • Los estados definidos sobre la capacidad de autorizar o autenticar dado que se ha rea-

lizado una confirmación sobre la clave pública y privada del certificado. Para poder acceder a estos datos definidos sobre el LDAP, se debe poseer un motor

SSL para desencriptar estos datos con la clave privada del LDAP la cual esta almacenada en un dispositivo criptográfico, lo que trae como consecuencia que no se pueda leer li-bremente estos datos porque cada registro esta almacenado y encriptado. Es importante aclarar que los estados definidos deben tener en cuenta que, dado que una persona no puede tener acceso hacia ningún recurso o dato y tampoco puede tener autenticación so-bre la plataforma, esta persona esta bloqueada, aun cuando su certificado sea valido y tenga libre acceso hacia la plataforma en cuestión.

5. Conclusiones

• Los tiempos de respuesta de los procesos de denegación de servicio pueden ser más rápidos sobre plataforma de publicación de directorios que sobre los estándares tradi-cionales.

• Los estándares tradicionales no pueden ser monitoreados por herramientas tradiciona-les, en cambio, estas herramientas si monitorean servicios como lo es el LDAP.

• Existen servicios de replicación de LDAP, para mantener el balanceo de cargas y la alta disponibilidad del servicio.

• En el caso que se pueden realizar actividades de forensica sobre el uso del certificado, se puede realizar una estructura de logs que cada uno de ellos sean firmado con el cer-tificado digital del administrador el LDAP e ingresar una apostilla de tiempo que nos


485

indique la hora legal del país en el cual se esta desempeñando la acción, con esto se le da soporte legal a las aplicaciones de logs.

• Se puede definir una política de suspensión del servicio de certificado sin necesidad de anularlo o revocarlo, lo que trae como consecuencia que no se generen cargos ex-tras al servicio de la Autoridad de Certificación para generar un certificado nuevo al usuario, lo que a la larga genera una economía sobre la operatividad de la CA.

6. Referencias 1. Crépeau, C. & Slakmon, A. Simple backdoors for RSA key generation. RSA Confer-

ence 2003. 2. Gutmann, P. PKI Technology Survey and Blueprint.

http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitech.pdf. 3. Gutmann, P. PKI: It's Not Dead, Just Resting. In IEEE Computer, August 2002. 4. ITU-T Recommendation X.509 ISO/IEC 9594-8. The Directory: Public Key and At-

tribute Certificate Frameworks. May 2001. 5. SUN. The JNDI Tutorial.

http://java.sun.com/products/jndi/tutorial/ldap/security/sasl.html. 6. Holguín, A. Autenticación Centralizada Con Tecnología Ldap, Universidad de Los

Andes, Marzo 2002. 7. Data Protection http://www.dataprotectionhq.com/cryptographyanddatasecurity/ 8. van de Graaf, J. Reflecting on X.509 and LDAP, or How Separating Identity and At-

tributes Could Simplify a PKI.


486

Un Meta-Proceso para el Desarrollo de Proyectos de Tecnología de Información en

Petróleos de Venezuela†

Lenis Malavé, Derlys Hernández, Cruz Erlinda Herrera

Petróleos de Venezuela, S.A – Dirección de Automatización, Informática y Telecomunicaciones Gestión de Necesidades y Oportunidades – Consultoría de Requisitos

El Tambor, Los Teques, Venezuela {ernesto_guevaram, derlyshernandez}@cantv.net {herreraeu}@pdvsa.com

Resumen. Este artículo describe un meta-proceso para el desarrollo de Proyectos de Tecnología de Información (TI) en PDVSA. Este meta-proceso muestra el flujo de actividades necesarias para el desarrollo de este tipo de proyectos así como los productos que generan cada una de estas actividades. El meta-proceso se sustenta en el uso de plantillas para documentos tipo siguiendo las especificaciones establecidas por la empresa en lo que a soluciones tecnológicas se refiere. Se detallan con principal relevancia las Fases de Análisis y Diseño de los Proyectos de TI por ser las etapas responsables de trazar la arquitectura y cimientos de una solución. Con este meta-proceso se ha logrado mejorar sustancialmente los procesos de automatización, informática y telecomunicaciones (AIT), garantizando la calidad de las soluciones. Palabras claves: Petróleos de Venezuela Sociedad Anónima (PDVSA), Unified Modeling Language (UML), Rational Unified Process (RUP), meta-proceso, metodología, guía, regla, tecnología de información, fase, especificación, desarrollo, documentación.

1. Introducción

Petróleos de Venezuela, S.A (PDVSA) con el propósito de mejorar los criterios de documentación de sus proyectos de TI se vio en la necesidad de crear un meta-proceso que incluyera las mejores prácticas, técnicas y métodos para el desarrollo de los mismos. Este meta-proceso permite agregar nueva documentación para los proyectos que genere valor a la corporación, corregir errores de documentación anterior, así como también unificar terminologías. La definición del meta-proceso pretende superar las limitaciones detectadas por el uso de la denominada Guía para la Gerencia de Proyectos (GGPIC), entre otras: (i) poca compatibilidad con los proyectos de TI; (ii) documentación con pocos aportes al área de desarrollo de software; (iii) escaso aprovechamiento de las metodologías de Ingeniería de

† PDVSA® Petróleos de Venezuela S.A. Este trabajo ha sido realizado gracias al apoyo de todo el personal de Gestión

de Necesidades y Oportunidades (GNO) en su aplicación y retroalimentación.


487

Software (RUP, UML, XP, etc.); (iv) impactos en los tiempos de desarrollo, debido a la falta de especificaciones técnicas detalladas de la oportunidad o necesidad; (v) retrabajos causados por levantamientos de información incompletos o no enfocados a opciones de solución específicos; (vi) fallas comunicacionales entre los procesos de AIT relacionados con la ejecución de proyectos de TI. En el establecimiento del Meta-Proceso de Desarrollo de Proyectos de Tecnología de Información se consideraron las tendencias actuales sobre procesos de desarrollo pesados y ligeros o ágiles, tales como[7, 8]: RUP (Rational Unified Process) [1], XP (eXtreme Programming) [2], Métrica Versión 3 [3], V-Modell [4], GGPIC Guías de Generación de Proyectos de Inversión de Capital (GGPIC) [5] y Casos de Negocios [6]. Además, facilita la generación de formatos y modelos gráficos basados en UML (Unified Modeling Language) [9, 1]. Además, conllevó la adopción de nuevas tecnologías (como, por ejemplo, la Arquitectura Basada en Servicios – ABS [10]) y estándares para el manejo de configuraciones y el aseguramiento de la calidad. El meta-proceso es iterativo e incremental; establece fases del ciclo de vida de un proyecto a través de las cuales se definen flujos de trabajo manteniendo, al mismo tiempo, su independencia con respecto al ciclo de desarrollo del proyecto propiamente dicho. De forma similar, se caracteriza por ser independiente de la naturaleza del proyecto, auto-adaptándose a sus particularidades. En este trabajo exponemos el Meta-Proceso para el Desarrollo de Proyectos de Tecnología de Información, cuyo objetivo es definir, analizar, diseñar y documentar los requerimientos de un proyecto de TI, sirviendo de guía para su aplicación diaria con miras a obtener resultados de calidad en los productos. Este artículo ha sido organizado en cinco secciones. La Sección 2 describe el Meta-Proceso de Desarrollo de Proyectos de TI, detallando su eje vertical (actores o stakeholders) y su eje horizontal (fases que lo comprenden). La Sección 3 describe las experiencias documentadas en la aplicación del Meta-Proceso, teniendo como enfoque la experimentación. En las dos últimas secciones se exponen los trabajos futuros, las conclusiones y las referencias bibliográficas. 2. El Meta-Proceso de Desarrollo de Proyectos de Tecnología de Información

El meta-proceso describe el flujo de actividades para la ejecución de proyectos de TI en PDVSA, identificar los actores que intervienen y los roles que desempeñan en cada actividad; además, define la estructura de los productos (documentos) a generar en cada fase. El meta-proceso se centra en las fases de análisis y diseño de proyectos de TI y no detalla las fases correspondientes al desarrollo o construcción y transición de la solución.

El metaproceso es representado a través de un diagrama de actividades UML en base a dos coordenadas: el eje vertical y el eje horizontal. En el eje vertical se ubican siete actores o stakeholders, los cuales participan en determinadas actividades de cada fase. Estos actores están identificados según el rol que desempeñan como sigue: Consultor Negocios, Consultor de Tecnología, Consultor de Requisitos, DIS (Desarrollo e Implantación de Soluciones),


488

Cadena y Suministros, Seguridad Lógica, Asuntos Públicos. En el eje horizontal se muestran las fases del meta-proceso y los productos (documentos) a generar en cada una de ellas. 2.1 Fase 1: Inicio (Visualización) Su objetivo principal es establecer los objetivos para el ciclo de vida del proyecto. Sus entradas se basan en las necesidades y/o requerimientos del cliente. En esta fase la participación del cliente es necesaria por lo que es considerado como parte del equipo de proyecto. Durante esta fase se especifica el caso de negocio, generando como salida los siguientes productos (Fig. 1):

Documento de Inicio: incluye el planteamiento del problema, tipos de solución, visualización inicial del proyecto, catálogo de requisitos generales, alcance, equipo y cronograma de trabajo, consideraciones técnicas y limitaciones.

Documento de Factibilidad Técnica: se desarrolla en caso de no existir en el catálogo de servicios. Consiste en el estudio detallado de la factibilidad tecnológica para satisfacer las necesidades del cliente en sintonía con la Arquitectura y Políticas establecidas por la Dirección AIT de la empresa.

Fig. 1. Diagrama de Actividades del Meta-Proceso: Inicio (Fase 1)


489

2.2 Fase 2: Preparación (Conceptualización + Definición) Permite plantear la arquitectura de la solución, que no es más que el conjunto de especificaciones detalladas en los productos que se generan en esta fase. Los insumos de esta fase se obtienen principalmente del levantamiento de información de los requerimientos del cliente. Las salidas corresponden a los siguientes documentos (Fig. 2):

Documento de Especificación para el Cliente (I): captura los requisitos (de información, funcionales, no funcionales) a través de levantamientos de información formales (investigación, entrevistas orales y escritas, mesas de trabajo, etc.). La información obtenida se representa a través de: el Diagrama de Procesos de Negocio, el Diagrama de Actividades, el Catálogo de Requisitos Priorizado, Consideraciones de Tecnología y el Prototipo Interfaz Preliminar.

Documento de Solución: es un estudio técnico-económico detallado de las posibles opciones de solución, considerando la visión estratégica de la plataforma PDVSA (Arquitectura Basada en Servicios, aprovechamiento de la plataforma, cultura del dato, herramientas transversales, actualización tecnológica, entre otros). Por cada opción de solución propuesta, se realiza una descripción (consideraciones preliminares, antecedentes, alcance de la solución, matriz de evaluación, estándares, políticas y lineamientos) que incluye un análisis costo beneficio clase V, cronograma de actividades, arquitectura de hardware y software.

Documento de Especificaciones de Construcción: detalla todas las especificaciones técnicas en materia de arquitectura y plataforma necesarias para la construcción de la solución. En esta sección se muestran aspectos como: lenguajes de programación, manejadores de base de datos, servidores, arquitectura, sistema operativo, etc.

Documento de Especificaciones para el Desarrollador: dirigido a los desarrolladores de la solución. Contiene Diagramas de Clases, de Secuencias y diseño de la Arquitectura.

Documento de Plan de Pruebas de Aceptación: diseño y documentación del Plan de Pruebas que ejecutará el cliente durante la Fase de Transición para la posterior aceptación de la solución.

Documento de Especificaciones Cliente (II): registra el análisis costo-beneficios de clase II y el cronograma de actividades detallado de la solución aceptada, así como también la matriz de riesgos respectiva. Este producto será insumo importante para el proceso de licitación.


490

Fig. 2. Diagrama de Actividades del Meta-Proceso: Preparación (Fase 2)

2.3 Fase 3: Construcción La Fase de Construcción tiene como objetivo principal generar el producto o servicio especificado en las documentaciones generadas en la Fase de Preparación (Análisis y Diseño), a fin de que satisfaga los requerimientos previamente definidos. En caso de haber elementos subcontratados o adquiridos externamente, en esta fase se deben integrar con el producto o servicio principal, así como también realizar los ajustes necesarios en el diseño, a manera de corregir las posibles lagunas, errores o inconsistencias. A continuación, se muestra la Figura 3, que presenta el Diagrama de Actividades del Meta-Proceso de esta Fase.


491

Fig. 3. Diagrama de Actividades del Meta-Proceso: Construcción (Fase 3)

2.4 Fase 4: Transición (Operacionalización)

En esta fase la atención se enfoca en asegurar que el software está disponible para los usuarios finales. Como objetivo principal se tiene la realización de las pruebas beta para validar el nuevo sistema con las expectativas del cliente, así como la operación en paralelo al sistema anterior que se está reemplazando, si fuere el caso. La Fase de Transición incluye el entrena-miento de usuarios y administradores de la solución, instalación y puesta en producción, te-niendo como base la ejecución de los planes de instalación.

Se debe destacar la relevancia dada a las actividades de corrección de errores, mejoras en el funcionamiento y rendimiento y usabilidad, que deben ser ejecutadas en esta fase. De la mis-ma manera formalizar los criterios de aceptación del producto, realizar la entrega formal del mismo, y completar el material de soporte de los usuarios finales (manuales de usuario, de administración y del sistema). Considerando que un proyecto de tecnología, tiene como obje-tivo satisfacer las necesidades de determinado cliente, no se debe pasar por alto, la retroali-mentación con los usuarios finales, y garantizar que la solución desarrollad cumpla con los requerimientos y alcance inicial.


492

Fig. 4. Diagrama de Actividades del Meta-Proceso: Transición (Fase 4)

4. Experiencia

Este meta-proceso está siendo aplicado como prueba piloto desde el mes de Junio 2006 en la Cartera de Proyectos manejada por GNO Servicios Comunes Centro (SCC), para un estimado de cincuenta proyectos de TI. No obstante, en el transcurso de los diez meses de aplicación de este meta-proceso, se han realizado continuas mesas de trabajo, a fin de hacer seguimiento a los resultados obtenidos, y realizar las mejoras necesarias, para evitar cuellos de botellas en las actividades y en las plantillas de documentos diseñadas como complemento del meta-proceso, con el objeto de desarrollar los puntos que realmente generan valor al proceso. En base a estas experiencias y mesas de trabajo, se han logrado recoger impresiones entre los Consultores de Requisitos que han participado en la aplicación del meta-proceso, consiguiendo resultados que nos demuestran la evolución del mismo, y certifican que verdaderamente proporciona aportes en la gestión de proyectos de TI en PDVSA. Dichos resultados se representan en las mejoras en los flujos de comunicación, lo que genera consecuencias positivas, al evitar los retrabajos en los proyectos y generar soluciones de calidad que cuentan con la participación y validación del usuario. Actualmente se encuentra en período de retroalimentación masivo, donde participan todos los actores descritos en el meta-proceso (Consultores de Negocio, Consultores de Requisitos, DIS, Consultores de Tecnología, etc.), para su mejoramiento, estando conformados por capital humano asignado a AIT – PDVSA.

5. Conclusiones y Trabajos Futuros

En este artículo se ha descrito el Meta-Proceso para el Desarrollo de Proyectos de Tecnología de Información en PDVSA. Este meta-proceso muestra cómo se gestionan las fases de análisis y diseño de un proyecto de TI para obtener soluciones que satisfagan las necesidades de los clientes. El meta-proceso se desarrolla a través de cuatro fases: Inicio, Preparación, Construcción, Transición, generando en cada una de ellas los productos necesarios para el ciclo de vida óptimo de un proyecto de TI. Estas fases se relacionan entre sí debido a que las


493

salidas de una de éstas, son las entradas o insumos de la siguiente. Con este meta-proceso se establece el flujo de actividades y los actores que participan en el ciclo de vida de un proyecto, apoyados por plantillas genéricas para cada documento. Como trabajos futuros se ha pensado en la obtención de algunos productos que pueden generar valor al meta-proceso, como lo son: la automatización de las plantillas de los documentos, control y seguimiento de la ejecución de la cartera de proyectos, generación de un catálogo de servicios automatizado con miras a la implantación de una arquitectura basada en servicios. Finalmente, es importante hacer un seguimiento continuo del meta-proceso a fin de introducir las mejoras se requieran; en este sentido, es necesaria la experimentación formal metodológica del mismo, que determine sus fortalezas y debilidades.

6. Referencias

1. Booch G., Rumbaugh J., Jacobson I: El Lenguaje Unificado de Modelado. Edit. Addison-Wesley, 2002. 2. Paulk M.: Extreme Programming from a CMM Perspective. IEEE Software, 2001. 3. De Amescua S. A.: Análisis y Diseño Estructurado y Orientado a Sistemas Informáticos. Editorial

McGraw Hill, 2003. 4. http://en.wikipedia.org/wiki/V_model 5. PDVSA: Guía de Generación de Proyectos de Inversión de Capital (GGPIC), 2004. 6. PDVSA: Paso a Paso en los Casos de Negocio, 2003. 7. Highsmith J.: The Great Methodologies Debate. Part I. Cutter IT Journal, 14(12), 2001. 8. Paulk M.: Agile Methodologies from a CMM Perspective. SEI-CMU, 2002. 9. Jacobson I., Booch G., Rumbaugh J: El Proceso Unificado de Desarrollo de Software. Addison-

Wesley, 2002. 10. Jones S.: Enterprise Soa Adoption Strategies. Editorial Lightning Source Inc., 2006.


494

ULAnux/ULAnix: Software Academico a la Medida

Jesus Molina1, Gilberto Dıaz1, Joskally Carrero1 Jacinto Davila1,2

Universidad de Los AndesMerida, 5101. Venezuela

1 CTI-CPTM. ULA - [email protected] CESIMO. ULA - [email protected]

ABSTRACT El Software Libre permite que cualquier usuario puede disponerdel software que requiere para hacer su trabajo, configurado y listo para funcionaren practicamente cualquier hardware que el usuario pueda encontrar mientras sedesplaza para trabajar. Esta independencia del hardware es, no solamente unaalternativa para facilitar el trabajo del cada usuario, sino un mecanismo para re-ducir los costos de dotacion de hardware y aprovechar al maximo las capacidadescomputacionales, especialmente en ambientes con recursos limitados.En la Universidad de Los Andes, Venezuela, comenzamos a explorar esta posi-bilidad con el proyecto de una LiveDistro ULAnix, la primer distribucion de unsistema operativo creada a partir de la MetaDISTRO, ULAnux. Es importantedestacar que ULAnux no es solamente software en un CD. Es un serie de pro-cesos conflagrados para reunir software, usando diversos medios de distribucion,con la necesidad particular de cada usuario, especialmente quienes compartenhardware o no pueden dedicar tiempo a configuracion de la plataforma. Por estarazon, nos permitimos hablar de Software a la medida.

KEYWORDS

LiveDistro, MetaDistros, ULAnux

1 Introduccion

Hacer a las maquinas mas inteligentes para no depender de las maquinas parece unapromesa sin sentido. Parece mas razonable hacer mas inteligentes a las maquinas paraque no dependan de los humanos.

Lo cierto es que lo que todo usuario de software desea es una maquina que puedaacompanarlo a todas partes, funcionar en cualquier condicion y permitir ası que elusuario se desentienda del trabajo de programacion, instalacion y configuracion. Lapopularidad de las computadoras portatiles es la mejor prueba de ese deseo de los usuar-ios, seguidas por el reciente auge de los asistentes electronicos personales o PDAs.

Con todo, cierta tecnologıa informatica parece atar al usuario a un particular hard-ware que lo limita y condiciona, aun en casos en los que el software podrıa hacer queel dispositivo se comportara mas inteligentemente.


495

El Software Libre, segun las definiciones formales que se obtienen en el ciberespa-cio3, promete cambiar todo eso. Cualquier usuario puede disponer del software querequiere para hacer su trabajo, configurado y listo para funcionar en practicamentecualquier hardware que el usuario pueda encontrar mientras se desplaza para trabajar.

Esta independencia del hardware es, no solamente una alternativa para facilitar eltrabajo del cada usuario, sino un mecanismo para reducir los costos de dotacion dehardware y aprovechar al maximo las capacidades computacionales, especialmente enambientes con recursos limitados[4].

En la Universidad de Los Andes, Venezuela, comenzamos a explorar esta posibil-idad con el proyecto de la LiveDistro4, ULAnix, la primer distribucion de un sistemaoperativo creada a partir de la MetaDISTRO, ULAnux5 6 con la que atenderemos lasnecesidades genericas de los usuarios de la red de datos de la ULA http://www.ula.ve.

2 Como producir un LiveDistro

Cada version de ULAnix (la ultima es la beta 4.0) es una imagen estandar de una porciondel sistema operativo GNU/Linux, Debian en partıcular. Esa imagen de software puedeser almacenado en un CD y con ella, cualquier usuario podra “iniciar” (arrancar o “toboot”) cualquier maquina, para obtener el mismo ambiente de trabajo (incluyendo apli-caciones finales como las herramientas de oficina o de navegacion por Internet) quebien conoce y sabe aprovechar.

Por ahora, ULAnix funciona en CDs. Es una LiveCD. Pero el proyecto incluye eldesarrollo de varias “LiveUSB”, versiones que funcionen desde Memorias Flash conconexion USB con el computador. Y tambien incluye versiones “LiveDVD” para queaquellos usuarios con acceso a maquinas con lectoras DVD puedan disfrutar de unambiente mas completo, con una version enriquecida (mas espacio, mas aplicaciones)de ULAnix.

Pero el aporte fundamental del proyecto ULAnux, no es la imagen ULAnix. Esla metadistro ULAnux: una plataforma y una coleccion de procesos para adaptar unadistribucion GNU/Linux a un entorno de trabajo concreto, a la medida de cada usuarioo grupo de usuarios.

La metadistro funciona como una “cadena de produccion” de software a la medida.En nuestro caso particular, con los paquetes Debian: mkisofs, squashfs-tools,genlive, initramfs-tools, busybox e initramfs-tools-metadistros,se procede como se describe a continuacion. Un proceso adaptado a partir de las her-ramientas y experiencias de Mario Debian[3] y Soleup[1], [2]:

3 http://es.wikipedia.org/wiki/Software libre4 http://en.wikipedia.org/wiki/LiveDistro5 http://nux.ula.ve6 nux nucis f. [a nut; a nut tree]. http://www.nd.edu/˜archives/latgramm.htm

nux, -cis f. i. fructus http://www.rostra.dk/latin/saxo.htmlEn el nombre de ULAnux hay un homenaje respetuoso al Sistema Operativo GNU/Linux

y a sus creadores, que han convertido al Software Libre en una realidad exitosa. Hubiesemosquerido nombrarle ULAnux, como nos sugiriera R.M. Stallman, siempre en defensa del nu.


496

1. Se define el directorio de trabajo a partir del que se creara la imagen ISO (que va alCD o a otro tipo de dispositivo).Tradicionalmente es algo como /media/distro/sources, para los paquetesa instalar en la imagen, /media/distro/master para la imagen propiamentey /media/distro/isos para almacenar la version valida de cada imagen pro-ducida.

2. Se instala la distro base con debootstrap(e.g. debootstrap etch /media/distro/sources)

3. Se crea una configuracion basica estandar de /etc/fstab, /etc/resolv.conf,/etc/network/interface, /etc/adjtime y /etc/apt/sources.listen /media/distro/sources.

4. Se adopta a /media/distro/sources como el ambiente de trabajo (para queel administrador pueda operar sobre la imagen como sı estuviera instalando soft-ware en una maquina en la forma habitual).Eso se hace con chroot /media/distro/sources.Otros comandos como mount sys y mount proc, son luego necesarios paracompletar la configuracion de ambiente para la imagen. Uno muy importante es elcomando que “exporta” los dispositivos de la maquina matriz para la imagen:mount -o bind /dev /media/distro/sources/dev, pues de esos dis-positivos Linux dependera la portabilidad de la imagen sobre hardware diverso.

5. Sobre ese ambiente configurado, el administrador puede proceder a instalar paque-tes en la forma habitual (e.g. aptitude en Debian), incluyendo la imagen basedel sistema operativo:grub, linux-imagen, discover, xwindows-system-core, udev, gdm,gnome-core, entre otros.

6. Una vez finalizada la instalacion de paquetes sobre ese ambiente simulado (conchroot), se desmontan los sistemas de archivos correspondientes.

7. Finalmente, el programa genlive se encarga de producir la imagen como unarchivo con extension .iso en /media/distro/isos o el directorio correspon-diente.

Este proceso sistematico, al que llamamos el proceso rojo (ver fig 1) se sigue cadavez que se desea crear una imagen y, desde luego, puede ser adecuado a cada tipo de im-agen o condiciones de hardware que se anticipen. De hecho, ULAnux ya ha producido,ademas de la DistroLive o LiveCD emblema ULAnix, una imagen para el Plan Na-cional de Alfabetizacion Tecnologica, PNAT, del Ministerio de Ciencias y TecnologıaVenezolano, con el material instrucional requerido para dictar cursos de formacion ensoftware libre, en localidades instalaciones que, inclusive, carezcan de conexion a In-ternet.

3 Los procesos ULAnux

El proceso rojo es apenas el corazon de un arreglo de procesos que nos permitendisponer de la metadistro. La figura 1 muestra el conjunto completo, que incluye losprocesos:


497

Fig. 1. Los procesos ULAnux

Azul.... para la recoleccion o cosechado del software, las pruebas de recompilacion y fun-cionamiento mınimo, el empaquetamiento y el almacenamiento en el repositorio enInternet, de los usuarios que deseen instalar o actualizar ULAnix en sus maquinas.Proyectamos la creacion de una aplicacion WEB que permita presentar solicitudesde versiones especıficas de ULAnix por esa vıa.

Rojo.... o de creacion de la imagen, descrito antes y con el cual se generan las imagenesISO de ULAnix.

Amarillo o proceso de pruebas, probablemente el proceso as importante, consiste de laspruebas y retroalimentacion formal o informal que se recibe de los usuarios de cadaimagen ULAnux y las respuestas correspondientes. Estamos evaluando (el softwarepara) un sistema de registro de tickets para mantener el almacen sistematico defallas, sugerencias y otras contribuciones de los usuarios, ası como las respuestadel plan de Cero Dificultad Hacia el Software Libre que se describe mas adelante.

Verde... o de instalacion, realizado por los usuarios de ULAnux para instalar o actualizarsus maquinas a partir de un repositorio tipo Debian, pero localizado en RedULAla red de la Universidad de Los Andes (Para instalar, el usuarios ejecuta un insta-lador especıfico basado en Soleupix, pero adaptado para el entorno ULAnix. Paraactualizar, cualquier aplicacion tradicional, como Synaptic sirve).

Rosado.. o de certificacion, realiza el seguimiento a las contribuciones y la creacion y man-tenimiento de un sistema de estımulo a los usuarios de software Libre.


498

4 Agregando valor con la instalacion y actualizacion local

Fig. 2. Instalando ULAnix en disco desde el repositorio Debian en la ULA

El proceso Verde es posible gracias a que RedULA dispone de un repositorio conlos estandares de la distribucion madre Debian[], en el servidor ftp.ula.ve. Perono solo hemos copiado la estructura Debian, sino que realizamos el empaquetado local-mente, lo que nos permite incluir software preparado en casa o adecuado a las necesi-dades de nuestra comunidad local.

Desde ese repositorio es posible completar toda la instalacion de ULAnix en eldisco duro de un computador estandar PC base Intel. Si la instalacion se realiza dentrode las instalaciones de la Universidad de Los Andes (dispersa por toda la Ciudad deMerida), el ahorro en tiempo y ancho de banda es considerable. La Figura 2 muestrauna maquina mientras instalaba el software desde el repositorio ULAnux.

5 Cero Dificultad hacia el Software Libre

Una LiveDistro y la posibilidad de instalar software libre localmente tendra una serie deimpactos, algunos de los cuales son difıciles de anticipar. Sin embargo, este proyectoha apuntado, desde su inicio en el ano 2004, a un particular efecto: a concentrar la


499

Fig. 3. Un portal para usuarios de ULAnux

atencion y el esfuerzo de nuestro personal tecnico sobre un conjunto (abierto) perobien seleccionado de aplicaciones, podremos atender mas efectiva y eficientemente anuestros usuarios.

El Plan de Cero Dificultad hacia el Software Libre ha sido disenado justamente conese objetivo. Pretende ofrecer dos niveles de atencion a los (nuevos y viejos) usuariosde Software Libre. En el nivel de atencion inmediata, incluıremos las aplicaciones conlas cuales los usuarios interactuan directamente. Crucialmente se cuentan en este grupotodas las herramientas Ofimaticas como la suite OpenOffice, aMessenger, IceDove oThunderbird y el navegador Mozilla Firefox. Sobre estas aplicaciones, todas incluıdasen ULAnix, el servicio de atencion a usuarios de RedULA ofrecerıa respuestas a con-sultas en menos de 72 horas, tiempo garantizado. Esto gracias a la experticia local enesos programas.

Sin embargo, el Plan tambien contempla admision de cualquier otra consultasobre cualquier otro programa de Software Libre. Estas consultas seran someti-das a los canales habituales de intercambio de informacion de la comunidad de soft-ware y las respuestas, cuando ocurrieren, seran publicadas en el centro de toda la op-eracion de documentacion para usuarios: el Portal de Software Libre de la ULA:http://nux.ula.ve. La Figura 3 muestra la imagen del nuevo portal.

6 Software a la medida

La siguiente etapa del proyecto, sin embargo, es todavıa un paso mas cerca de las necesi-dades de los usuarios de computadoras. El portal ULAnux, http://nux.ula.ve, que ya


500

soporta algunos servicios de consulta, documentacion y discusion sobre software libre,sera condicionado para permitirle a usuarios configurar su propia distribucion. Un for-mulario Web, de seleccion multiple, le permitira a los usuarios hacer una solicitud, tandetallada (o poco detallada) como deseen de los programas que quisieran tener en unaimagen ISO (en CD, USB o DVD).

El objetivo es permitirle al usuario desplazarse con “su ambiente” de trabajo, sinnecesidad de mover un computador particular. De esta manera podremos, entre otrascosas, atender las necesidades cambiantes de los laboratorios y centros de computo dela Universidad que suelen tener casi tantos ambientes requeridos como usuarios reg-istrados.

Esos ambientes academicos, ademas, podran integrar, sin mayor dificultad sus pro-pios desarrollos de software a las imagenes ULAnix, a traves de un repositorio de soft-ware con un sistema de manejo de versiones (como Subversion) soportando el desar-rollo local de software.

7 Conclusiones

ULAnux es una metadistribucion libre de software libre, con la cual producimos ULAnixla distribucion de software de la Universidad de Los Andes. La coleccion de programasen esta distribucion varıa de acuerdo a las necesidades particulares de nuestra comu-nidad, tanto en terminos basicos (como ocurre con todos los programas de ofimatica)como para requisitos especiales (software para laboratorios, cursos y grupos de trabajo).

Sin embargo, es importante destacar que ULAnux no es solamente software en unCD. Es un serie de procesos conflagrados para reunir software, usando diversos mediosde distribucion (que incluyen un repositorio completamente funcional en Internet), conla necesidad particular de cada usuario, especialmente quienes comparten hardware o nopueden dedicar tiempo a configuracion de la plataforma. Por esta razon, nos permitimoshablar de Software a la medida.

Agradecimientos

Los autores expresan su agradecimiento a los usuarios que nos han venido ayudando aprobar y mejorar ULAnix, y a los arbitros anonimos de EVETIS07.

References

1. Escuela Universitaria Politecnica de Valladolid-Espana. Soleupix.http://soleup.eup.uva.es/mediawiki/index.php/Soleupix.

2. HispaLiNUX. Metadistros. http://metadistros.hispalinux.es/.3. Mario Izquierdo. Como hacer una metadistro. http://soleup.eup.uva.es/mario/post/1/265, Di-

ciembre 2005. http://creativecommons.org/licenses/by-nc-sa/2.1/es/.4. UNU-MERIT. Economic impact of open source software on innovation and the competi-

tiveness of the information and communication technologies (ict) sector in the eu. Technicalreport, UNU-MERIT, 2006.


501

Lector de Historias Clínicas Electrónicas Codificadas en el Estándar Health Level 7 / Clinical Document Architecture

para su Aplicación en Servicios de Telemedicina

Edgar Lugo, Hyxia Villegas, Rafael Pacheco, Angel Villegas

Centro de Procesamiento de Imágenes. Facultad de Ingeniería. Universidad de Carabobo. Estado Carabobo. Venezuela.

{ealugo, hyxia, jpacheco, avillegas}@uc.edu.ve

Resumen: El objetivo principal de este trabajo es diseñar e implementar un software libre para leer historias clínicas electrónicas basadas en el estándar Health Level 7 / Clinical Document Architecture (HL7/CDA). La implementación del software fue realizada utilizando la metodología Programación Extrema, PHP, Javascript y XML asíncronos (AJAX) y las herramientas Apache 2 y Eclipse 3.1. El lector recibe un documento XML codificado en HL7/CDA y luego organiza su contenido en la memoria del computador. Las pruebas fueron realizadas en Linux Ubuntu 6.06 LTS y Windows XP SP2, utilizando Apache 2 y PHP 5. Los resultados obtenidos muestran que es posible la recepción de historias clínicas electrónicas que se encuentren en conformidad con el estándar HL7/CDA. Se concluye que el lector facilita la gestión de la información contenida en historias clínicas codificadas en HL7/CDA luego de su recepción, representando así una contribución al intercambio de información clínica para servicios de telemedicina.

Palabras clave: Telemedicina, Historias Clínicas, HL7, Clinical Document Architecture.

1 Introducción

Las historias clínicas electrónicas (HCE) han sido un campo de investigación clave en informática médica. Según [1], una HCE es la información médica de la vida de una persona almacenada digitalmente, con el propósito de soportar la continuidad del cuidado médico, la educación y la investigación, asegurando la confidencialidad de su contenido en todo momento. En la actualidad, la mayor parte de las organizaciones que prestan servicios de salud, almacena las historias clínicas electrónicas en todo tipo de formatos propietario, y son gestionadas en una multitud de sistemas de información médica disponibles en el mercado. Esta situación se convierte en un problema de interoperabilidad serio en el campo de la informática médica.


502

Organizaciones, investigadores e industrias se han dedicado a desarrollar estándares para normar el almacenamiento de la información de un paciente en HCE a nivel mundial, y así permitir la interoperabilidad entre los sistemas de información médica.

Health Level Seven (HL7) es una de estas organizaciones, cuya misión es proveer estándares para el intercambio, gestión e integración de datos que apoyen el cuidado clínico del paciente, específicamente relacionados con la interoperabilidad entre sistemas de información en el ámbito de la salud [2]. HL7 es una de varias organizaciones desarrolladoras de estándares (SDO) acreditada por ANSI en el campo de la salud. Entre sus logros, Health Level Seven, produjo la especificación HL7 versión 2, aprobada por ANSI en el 2004 [3]. En la actualidad, HL7 versión 2 es el estándar de mayor utilización en el campo de la salud a nivel mundial, para el intercambio de datos clínicos y administrativos entre aplicaciones de software [4]. Sin embargo, esta versión produjo inconvenientes debido a su gran flexibilidad y a la carencia de un modelo de información que la soportara. Para remediar esto, surge la especificación HL7 versión 3 [5], basada en el Modelo de Referencia de Información (RIM) [6]. Es en esta especificación que se propone un estándar de documentos basados en marcas para representar las historias clínicas electrónicas (HCE) llamado Clinical Document Architecture.

Clinical Document Architecture (CDA) Release 2.0 [7], surge para dar respuesta a la necesidad de intercambio de historias clínicas electrónicas de manera estandarizada entre sistemas. HL7/CDA es un estándar de marcado de documentos que especifica la estructura y la semántica de los documentos clínicos con la finalidad de su intercambio [7]. Los documentos CDA son codificados en XML [8] y su significado deriva del RIM y utiliza los tipos de datos del estándar HL7 versión 3.

En este trabajo de investigación presentamos un lector de historias clínicas electrónicas basado en el estándar HL7/CDA Release 2.0, seleccionado entre varias otras iniciativas de estandardización [9], en vista de los resultados obtenidos en [10]. El lector viene a satisfacer la carencia de soluciones de software libre que permitan facilitar la gestión de la información contenida en un documento CDA.

2 Metodología

Para el desarrollo del lector de historias clínicas electrónicas codificadas en HL7/CDA, se realizó una revisión del estándar Clinical Document Architecture Release 2.0, la cual permitió determinar las etiquetas que conforman dicho estándar, su significado dentro del documento clínico y el orden que les corresponde dentro del mismo. Luego de conocer las etiquetas que conforman el estándar, fue posible establecer el alcance de los elementos que debía estar en capacidad de procesar y organizar en una estructura de datos el lector de documentos CDA.

Para facilitar la comprensión de cada una de estas etiquetas fue utilizado un archivo XLST [11], provisto por HL7, que permite transformar una historia clínica electrónica codificada en HL7/CDA en HTML [12], para ser visualizada en cualquier navegador de


503

Internet. El uso de este archivo de conversión permitió distinguir con mayor claridad cada uno de los elementos que conforman la historia clínica electrónica y posteriormente serviría para verificar si la información interpretada por el lector era la correcta.

Según [13], un documento clínico que puede ser modificado y accesible a través de la Web, reduce considerablemente las gestiones de papel realizadas en una clínica convencional. Esta razón y adicionalmente nuestro interés de que el lector sea aplicado en servicios de telemedicina a través de Internet, nos llevaron a seleccionar un conjunto de herramientas que sirvieran de plataforma Web para desarrollar y probar dicho lector.

Apache es el servidor Web de mayor popularidad en Internet y es utilizado por más del 60% de los sitios Web a nivel mundial [14], por tal razón es el seleccionado en su versión 1.3.33 para ejecutar el lector. Para realizar la implementación del lector utilizando programación orientada a objetos, fue seleccionado el lenguaje PHP, por representar la tecnología de mayor popularidad para contenido Web dinámico utilizada en servidores Apache [14]. La versión utilizada de PHP fue la 5.0.4. Como entorno de desarrollo integrado (IDE), fue utilizado el editor multipropósito Eclipse 3.1 y su plugin PHPEclipse, que permite codificar en PHP utilizando este IDE.

La arquitectura de software utilizada para el lector de historias clínicas electrónicas codificadas en HL7/CDA, es Cliente/Servidor de 3 capas. Según [15], esta arquitectura de software es utilizada cuando se requiere incrementar el rendimiento, flexibilidad, capacidad de mantenimiento, reusabilidad y escalabilidad del software, mientras se oculta la complejidad del procesamiento realizado al usuario, siendo ideal para aplicaciones para Internet.

Al recibir un documento XML codificado en HL7/CDA, el lector utiliza la clase Generic XML parser [16]. Esta clase permite estructurar todas las etiquetas y elementos de datos de un archivo XML en un vector de datos almacenado en la memoria del computador. Cada posición de este vector almacena una etiqueta del documento XML, la cantidad de etiquetas que conforman la información correspondiente a la etiqueta actual, y los atributos de la misma.

Luego de haber almacenado la información de la historia clínica electrónica codificada en HL7/CDA en la memoria del computador, es necesario organizar dicha información para su posterior uso. Para realizar esta función fue generada la clase HCE (Historia clínica electrónica). Esta clase permite almacenar los datos del médico y del paciente, la fecha de creación de la historia clínica, su identificador único y todas las secciones en las cuales se encuentre clasificada la información dentro de la misma. Para organizar las secciones de la historia clínica electrónica es utilizado un método recursivo llamado RecorrerArbolHL7CDA perteneciente a la clase HCE. Dicho método se encarga de recorrer el vector que contiene almacenada toda la información del documento HL7/CDA previamente generado por la clase Generic XML parser e identificar las secciones del mismo. En función del tipo de información contenida en cada una de las posiciones del vector, llama al método correspondiente para procesar los diferentes tipos de información. Estos métodos se encargan de hacer legibles los títulos de las secciones, fechas, nombres, apellidos, sexo, texto, listas de ítems, tablas y elementos multimedia. Algunos de estos métodos son recursivos, en vista de que un elemento puede estar compuesto por otros


504

adicionales y es necesario reconstruir la información tomando en cuenta todo el contenido de la historia clínica electrónica.

Al punto de haber procesado cada tipo de información, esta es almacenada utilizando la clase Table [17]. Esta clase permite crear tablas dinámicamente en la memoria del computador, que pueden contener filas, columnas e inclusive otras tablas. Cuando se ha concluido el proceso de completar la información de las mismas, es posible generar de manera automática en HTML toda la información para ser visualizada en un navegador de Internet, con la limitante de no poder visualizar el contenido de una tabla almacenada dentro de otra. Por tal motivo fue desarrollado un método recursivo de visualización para la clase Table, que permite generar del código HTML para esta situación en particular no prevista por la clase original.

Cada sección de la historia clínica electrónica esta representada por una instancia de la clase Table creada dinámicamente. Este diseño es ideal, ya que permite ir creando las secciones a medida que van siendo identificadas, sin importar la cantidad de estas bajo la cual este clasificada la información de la historia clínica electrónica. Las secciones son identificadas al encontrar una etiqueta title, que representa el título de una sección. Cuando esto ocurre es llamado el método ProcesarTagTitulo, que se encarga de generar la nueva tabla para la sección actual y de almacenar el título en la primera celda de dicha tabla. Las siguientes celdas sirven para almacenar el contenido de la sección y son creadas a medida que el lector va procesando la información que fue almacenada en el vector generado por la clase Generic XML parser según su tipo. La sección puede tener contenido multimedia o texto.

En el caso de contenido multimedia, el procesamiento de dicha información es llevado a cabo por un método llamado ProcesarTagMultimedia perteneciente a la clase HCE. Este método es invocado al encontrar una etiqueta observationmedia, en donde es extraída la ubicación del contenido multimedia que debe ser desplegado en la historia clínica electrónica. En esta versión del software, los contenidos multimedia se restringen a solo imágenes. Se tiene programado incluir videos y sonidos para la siguiente versión.

El contenido texto resulta un poco más complejo, ya que se deben considerar los diferentes tipos de texto que pueden existir en la sección: tablas, listas de ítems o simplemente texto. Todo este trabajo es realizado por el método recursivo ProcesarTagText de la clase HCE. En el caso de las tablas el método se encarga de insertar una tabla nueva dentro de la celda actual y allí de almacenar todo el contenido correspondiente a la misma. No existe límite con respecto a la cantidad de filas o columnas de estas tablas, ya que estas son generadas dinámicamente por el método ProcesarTagText. Generalmente esta etiqueta se utiliza para registrar tablas con resultados de un conjunto de exámenes médicos o signos vitales del paciente entre otros. En el caso de las listas de ítems, cada uno de sus elementos es almacenado en una celda de la tabla correspondiente a la sección que actualmente esta siendo procesada. Por último, el texto simple es almacenado en solo una celda, eliminando del mismo todas aquellas palabras que en una revisión del documento hayan sido marcadas con el atributo revised="delete".

Después que la información de la historia clínica electrónica ha sido organizada, se procede a desplegar la misma invocando al método Mostrar de la clase HCE. Este método


505

genera toda la historia clínica electrónica que originalmente estaba contenida en el documento HL7/CDA en HTML y es posible visualizarla en un navegador de Internet.

Las pruebas de funcionamiento del lector de historias clínicas electrónicas codificadas en HL7/CDA fueron realizadas utilizando documentos CDA provistos por HL7 y del curso de HL7 del Campus Virtual del Hospital Italiano de Buenos Aires [18], en los sistemas operativos Linux Ubuntu 6.06 LTS y Windows XP Service Pack 2. Los navegadores de Internet utilizados fueron Mozilla Firefox 1.5.0.7 e Internet Explorer 6.

Los documentos HL7/CDA son enviados al lector utilizando Javascript y XML asíncronos (AJAX) [19, 20] desde un navegador de Internet, y la respuesta generada por el lector en HTML es recibida por el navegador de Internet utilizando igualmente AJAX.

La metodología de desarrollo de software utilizada para desarrollar el lector de historias clínicas electrónicas codificadas en HL7/CDA fue Programación Extrema (XP).

3 Resultados

El lector funciona correctamente en los sistemas operativos Linux Ubuntu 6.06 LTS y Windows XP Service Pack 2, con lo cual se hace posible la recepción de historias clínicas electrónicas que se encuentren en conformidad con el estándar HL7/CDA en cualquiera de estas plataformas. La Fig. 1 ilustra parte de una de estas historias clínicas electrónicas en conformidad con HL7/CDA y el resultado luego de ser procesada por el lector es mostrado en la Fig. 2.

Fig. 1. Sección de Historia Clínica codificada en HL7/CDA.

Adicionalmente, las historias clínicas electrónicas utilizadas para verificar el funcionamiento del lector, fueron procesadas de manera correcta por el software, a pesar de estar organizadas de manera totalmente distinta en lo que se refiere a la cantidad de secciones, volumen de contenido y tipo de información que estas incluían.

Henry Levin, the 7<sup>th</sup> </content> is a 67 year old male referred for further asthma management. Onset of asthma in his <content revised="delete">twenties</content> <content revised="insert">teens</content>. He was hospitalized twice last year, and already twice this year. He has not been able to be weaned off steroids for the past several months.

</text>


506

Fig. 2. Utilización del Lector de Historias Clínicas Electrónicas utilizando Internet Explorer 6 y Windows XP Service Pack 2.

4 Conclusiones

De los resultados mostrados, de su análisis y discusión, se obtienen las siguientes conclusiones sobre el lector de historias clínicas electrónicas codificadas en el estándar HL7/CDA: • Facilita la gestión de la información contenida en historias clínicas codificadas en

HL7/CDA luego de su recepción, ya que toda la información es almacenada en la memoria del computador a través de una estructura de datos de simple.

• Reduce la cantidad de errores en la información de las historias clínicas, a través del intercambio de las mismas, evitando generar una por cada sistema, institución o servicio de salud utilizado.

• Hace posible la recepción de historias clínicas electrónicas que se encuentren en conformidad con el estándar HL7/CDA enviadas por cualquier organización a nivel mundial a través de correo electrónico, servicios Web u otros medios, en cualquiera de los sistemas operativos utilizados en este trabajo de investigación, sin importar cantidad de secciones, volumen de contenido, ni tipo de información que incluyan.

• Representa una contribución al intercambio de información clínica para ser utilizada en servicios de telemedicina.

• Permite mejorar la organización de los servicios de salud y aumentar la disponibilidad de la información al ser manejada de manera digital, para médicos y pacientes.

• Sirve de proveedor de información a repositorios de datos clínicos, que permitirán realizar trabajos de investigación en el campo de la salud utilizando un amplio y variado volumen de datos.


507

Referencias

1. Iakovidis, I.: Towards personal health records: Current situation, obstacles and trends in implementation of Electronic Healthcare Records in Europe. International Journal of Medical Informatics, Vol. 52. (1998). 105-117.

2. http://www.hl7.org/. Fecha de Acceso: Oct (2006). 3. Health Level Seven: HL7® Version 2 Standard. http://www.hl7.org.au/HL7-V2-Resrcs.htm.

Fecha de Acceso: Oct (2006). 4. Eichelberg M., Aden T., Riesmeier J., Dogac A. y Laleci G.: A survey and analysis of

Electronic Healthcare Record standards. ACM Computing Surveys Vol. 37, No. 4. (2005). 277-315.

5. Health Level Seven: HL7 Version 3 Standard. http://www.hl7.org.au/HL7-V3-Resrcs.htm. Fecha de Acceso: Oct (2006)

6. Health Level Seven: Reference Information Model 2.14. http://www.hl7.org/library/data-model/RIM/modelpage_mem.htm. Fecha de Acceso: Oct (2006)

7. Health Level Seven: HL7 Clinical Document Architecture, Release 2.0. (2004). http://www.hl7.org/v3ballot/html/foundationdocuments/cda/cda.htm. Fecha de Acceso: Nov (2006).

8. World Wide Web Consortium: Extensible Markup Language (XML) 1.0 (Third Edition). http://www.w3.org/TR/2006/REC-xml-20060816/. Fecha de Acceso: Nov (2006).

9. Treins, M., Curé O., y Salzano G.: On the interest of using HL7 CDA release 2 for the exchange of annotated medical documents. Proceedings of the 19th IEEE Symposium on Computer-Based Medical Systems. (2006) 524-532

10. Lugo, E. y Villegas H.: Evaluation of Electronic Health Records Standards for its use in the Integral Medical Care Unit of the Universidad de Carabobo. LV Convención Anual de ASOVAC. (2005).

11. World Wide Web Consortium: XSL Transformations (XSLT) Version 1.0. http://www.w3.org/TR/1999/REC-xslt-19991116. Fecha de Acceso: Nov (2006).

12. World Wide Web Consortium: HTML 4.01 Specification. http://www.w3.org/TR/html4/. Fecha de Acceso: Nov (2006).

13. Hooda, J., Dogdu E. y Sunderraman R.: Health Level-7 Compliant Clinical Patient Records System. ACM Symposium on Applied Computing. (2004). 259-263.

14. Titchkosky, L., Arlitt M. y Williamson C.: A performance comparison of dynamic Web technologies. ACM SIGMETRICS Performance Evaluation Review, Vol. 31 (2003). 2-11.

15. Sadoski, D. y Comella-Dorda S.: Three Tier Software Architectures. http://www.sei.cmu.edu/str/descriptions/threetier_body.html. Fecha de Acceso: Dic (2006).

16. Lemos, M.: Generic xml parser class. http://www.phpclasses.org/browse/package/4.html. Fecha de Acceso: Dic (2006).

17. Lotito, J.: Table class (Version 1.0). http://www.phpclasses.org/browse/package/318.html. Fecha de Acceso: Dic (2006).

18. Kaminker, D.: Curso de HL7. http://campus.hl7.org.ar. Fecha de Acceso: Nov (2006). 19. Anderson T.: Using Ajax with PHP and Sajax. http://www-

128.ibm.com/developerworks/edu/os-dw-os-phpajax-i.html. Fecha de Acceso: Dic (2006). 20. Asleson R. y Schutta N.: Foundations of Ajax. Apress, United States of America. (2006).


508

Una Caracterización de Herramientas MDA de Código Abierto†

Juan Carlos Herrera1, Alfredo Matteo1 e Isabel Díaz1-2

Universidad Central de Venezuela 1Facultad de Ciencias - Escuela de Computación - Laboratorio TOOLS

2Facultad de Ciencias Económicas y Sociales - Escuela de Economía Los Chaguaramos, Ciudad Universitaria. Caracas, Venezuela

[email protected] ; {amatteo,idiaz}@kuaimare.ciens.ucv.ve

Resumen. En este trabajo se aplican cuatro marcos de evaluación propuestos recientemente por varios autores para lograr una caracterización de 13 herramientas MDA (Model Driven Architecture) de código abierto. Esta caracterización tiene como principal objetivo conocer las principales propiedades y enfoques de transformación que implementan estas herramientas. Los marcos de evaluación utilizados son analizados en este artículo y, además, son también extendidos aportando nuevas características para la evaluación de este tipo de herramientas.

Keyword: Arquitectura Dirigida por Modelos, MDA, código abierto, herramienta, evaluación de herramientas, marco de evaluación.

1. Introducción

La Arquitectura Dirigida por Modelos (MDA) es una iniciativa de la OMG (Object Management Group) que promueve un enfoque de desarrollo de software basado en la transformación sucesiva de modelos [11]. MDA supone la definición de un modelo y su correspondencia a uno o más modelos, los cuales son obtenidos a partir del primero de forma automática [5]. De esta manera, se establece un vínculo controlable entre un modelo origen un modelo destino. El enfoque MDA busca lograr portabilidad, productividad, reusabilidad, mantenibilidad, integración, interoperabilidad y apoyo a la evolución del sistema según cambia la plataforma tecnológica [3].

Este trabajo describe un marco de referencia para la evaluación de herramientas de transformación de código abierto basadas en MDA. Se entiende como herramienta MDA a aquellas que dan soporte al proceso de diseño y construcción de sistemas a través de la transformación automática de modelos [2]. En particular, en este artículo se presentará la evaluación realizada a un conjunto de herramientas MDA de código abierto, según la categorización presentada en Modelbased.net [9]. El trabajo se orientó a este tipo de

† Esta investigación ha sido desarrollado con el soporte de los Proyectos 03.00.6051.2005 y 05.00.5923.2005

del Consejo de Desarrollo Científico y Humanístico de la Universidad Central de Venezuela.


509

herramientas para atender una necesidad venezolana actual derivada de la exigencia legal de utilizar software libre para el desarrollo de sistemas en todas las instituciones y dependencias gubernamentales [6]. De aquí, que se haya planteado la obtención de una caracterización de las herramientas MDA de código abierto más conocidas.

Este trabajo ha sido estructurado en 5 secciones. La Sección 1 se reservó para esta introducción. Las Secciones 2 y 3 explican, respectivamente, el marco para la caracterización de las herramientas y los resultados obtenidos. La Sección 4 está dedicada a las conclusiones. Por último, en la Sección 5 se listan las referencias señaladas en este artículo.

2. Marco para la Caracterización

En los últimos años se han propuesto diversos criterios para la clasificación de herramientas MDA [3, 7, 8, 9, 12]. De especial interés son las propuestas de Stuart Kent [8], Jean-Marc JEZEQUEL [7], Czarnecki y Helsen [3] y Naveed Ahsan Tariq Naeem Akhter [12]. La elección de estos trabajos se debió a que permiten determinar el nivel de apoyo que puede ofrecer la herramienta MDA a la comunidad de desarrolladores e identificar el enfoque de transformación utilizado por las mismas. En su conjunto, los criterios propuestos por estos autores conforman un marco consistente para la caracterización de herramientas MDA de código abierto. Se trata con esto de establecer sus principales características y posibilitar su comparación de tal manera de facilitar la elección de estas herramientas, en términos del uso que se requiera dar a las mismas.

2.1. Clasificación de Stuart Kent

La clasificación propuesta por Kent se muestra en la Tabla 1. El criterio utilizado por este autor está orientado a establecer las funcionalidades que deberían ofrecer estas herramientas, agrupándolas según el tipo de apoyo que ofrecen a los desarrolladores [8]. Sin embargo, esta clasificación tiene como limitante que no considera los diferentes enfoques de transformación que utilizan estas las herramientas.

Tabla 1. Caracterización de Herramientas MDA según Kent [8]

Código Características

1.1 Orientadas a verificar que los modelos están bien formados 1.2 Permiten trabajar con instancias de modelos 1.3 Ofrecen soporte para la transformación entre modelos 1.4 Verificación orientada a modelos 1.5 Dedicadas al control de versiones y el trabajo distribuido 1.6 Apoyan los procesos de desarrollo de software dirigido por modelos


510

2.2. Clasificación de Jean-Marc Jezequel

Jezequel esboza una caracterización según la técnica de transformación de modelos que aplica la herramienta [7]. El autor expresa en cada categoría la forma cómo las transformaciones de modelos son soportadas, dependiendo de la herramienta y el enfoque de transformación utilizado para ello.

Tabla 2. Caracterización de Herramientas MDA según Jean-Marc Jezequel [7]


2.1 Lenguajes de Programación de Propósito General 2.2 Herramienta de Transformación Genérica 2.3 Herramientas CASE de Lenguajes Interpretados 2.4 Dedicadas a la Transformación de Modelos 2.5 De Meta-Meta-modelado

2.3. Clasificación de Czarnecki y Helsen Czarnecki y Helsen establecen una taxonomía para la clasificación de las herramientas MDA según el enfoque de transformación de modelos que utilizan [3]. Establecen dos enfoques de alto nivel: transformación de modelo a código y transformación de modelo a modelo. Como parte de estos enfoques se agrupan otros (ver Tabla 3).

Tabla 3. Caracterización de Herramientas MDA según Czarnecki y Helsen [3]


3.1 Enfoque Modelo a Código 3.1.1 Enfoque basado en el patrón "visitor" 3.1.2 Enfoque basado en plantillas

3.2 Enfoque Modelo a Modelo 3.2.1 Enfoque de manipulación directa 3.2.2 Enfoque relacional 3.2.3 Enfoque basado en transformación de grafos 3.2.4 Enfoque centrado en la estructura

3.2.5 Enfoque híbridos

2.4. Clasificación de Naveed Ahsan Tariq y Naeem Akhter

El aspecto más importante del trabajo de estos autores es la elaboración de un estudio formal de las características esenciales que deben tener las herramientas MDA [12]. Sin embargo, este marco sólo ha sido aplicado a herramientas de código propietario. La Tabla 4 muestra un subconjunto de características propuestas por Tariq y Akhter. Este subconjunto se ha seleccionado considerando aquellas características que expresan los aspectos más relevantes de la transformación entre modelos.


511

Tabla 4. Caracterización de Herramientas MDA según Tariq y Akhter [12]

Código Características Código Características

4.1 Soporte de CIM 4.13 Transformación directa PIM Código 4.2 Soporte de PIM 4.14 Transformación directa PIM Código 4.3 Modelos MOF compatible 4.15 Transformación basada en marcas 4.4 Soporte de Diagrama de Caso de Uso 4.16 Transformación basada en meta-modelos 4.5 Soporte de Diagrama de Clase 4.17 Transformación basada en modelos 4.6 Soporte de Diagrama se Secuencia 4.18 Transformación basada en patrones 4.7 Soporte para AS UML 4.19 Transformación basada en perfiles UML 4.8 Soporte para XMI-XML 4.20 Registro de transformaciones 4.9 Soporte Query-View-Tranformation 4.21 Trazabilidad de transformaciones

4.10 Soporte OCL 4.22 Combina 2 o más CIM en 1 4.11 Transformación PIM PSM Código 4.23 Combina 2 o más PIM en 1 4.12 Transformación PIM PSM Código

PIM: Modelo Independiente de Plataforma CIM: Modelo Independiente del Cómputo PSM: Modelo Especifico de la Plataforma AS: Semántica de Acción

2.5. Otras Características propuestas en este Trabajo Una etapa común en cualquier método de desarrollo de software es la especificación de los requisitos del sistema los cuales son expresados, generalmente, de forma textual. A partir del modelo de especificación se construye el modelo de análisis usando un lenguaje de modelado. Este proceso se hace generalmente de forma manual [13]. No obstante, ya se han propuesto algunas herramientas que pretenden dar soporte automatizado a este proceso [4]. Estas herramientas permiten la transformación de un documento o texto (CIM: Modelo Independiente de Computo) para obtener un Modelo Independiente de Plataforma (PIM) que exprese el resultado del análisis de los requisitos del sistema. La identificación de herramientas que apoyen este tipo de transformaciones y la determinación del alcance de las mismas son entonces necesidades a las que se enfrentan actualmente los desarrolladores. Ninguno de los marcos de evaluación consultados permite establecer si una herramienta MDA satisface estas necesidades. De aquí que se hayan propuesto las características que se enuncian en la Tabla 5.

Tabla 5. Caracterización de Herramientas MDA propuestas en este Trabajo

Código Características 5.1 Transformación CIM PIM 5.2 Transformación CIM PIM 5.3 Transformación CIM PIM PSM 5.4 Transformación CIM PIM PSM 5.5 Transformación Texto MOF 5.6 Transformación Texto MOF 5.7 Transformación de Texto CIM 5.8 Transformación de Texto CIM

MOF: Meta Object Facility [10]


512

2.6. Herramientas MDA de Código Abierto utilizadas

En el enfoque arquitectónico dirigido por modelos es necesario que los metamodelos, modelos y transformaciones puedan ser mantenidos y evolucionar a lo largo del ciclo de vida del desarrollo del software [1]. En consecuencia, se hace necesario el uso de herramientas que apoyen esta difícil tarea, maximizando la productividad en la construcción de los modelos y minimizando el esfuerzo requerido para mantenerlos. Existe un número importante de herramientas MDA de código abierto. No obstante, el análisis que se presenta en este trabajo, fue realizado utilizando sólo 13 de éstas [9]: MOFScript, MTF (Model Transformation FRamework), ADT, ModFact, GMT (Generative Model Transformer), KMF (Kent Modelling Framework), OAW (Open Architecture Ware), OpenMDX, AndroMDA, SmartQVT, Jamda, UMLAUT (unified Modeling Language All Purposes Transformer) y KERMETA.

3. La Caracterización Obtenida

Las Tablas 6, 7, 8 y 9 que se presentan en esta sección, muestran las características de las 13 herramientas MDA de código abierto seleccionadas. La información que se muestra corresponde al resultado de identificar en estas herramientas, las características indicadas en las Tablas 1, 2, 3, 4 y 5. Se ha marcado con " " las características identificadas. 3.1. Caracterización desde la Perspectiva de Kent La Tabla 6 muestra las características identificadas en las herramientas MDA de código abierto seleccionadas para este estudio. Los resultados obtenidos muestran que todas las herramientas evaluadas apoyan los procesos propios del desarrollo de software dirigido por modelos.

Tabla 6. Identificación de las Características propuestas por Kent [8]

Código de las Características (ver Tabla 1)Herramientas 1.1 1.2 1.3 1.4 1.5 1.6 MOFScript MTF ADT Modfact GMT OAW OpenMDX AndroMDA SmartQVT Jamda UMLAUT KERMETA KMF


513

3.2. Caracterización desde la Perspectiva de Jezequel

La Tabla 7 muestra las características identificadas en las herramientas MDA de código abierto seleccionadas para este estudio. Puede observarse que, excepto una, todas las herramientas evaluadas están orientadas a soportar el proceso de transformación de modelos.

Tabla 7. Identificación de las Características propuestas por Jezequel [7]

Código de las Características (ver Tabla 2)Herramientas 2.1 2.2 2.3 2.4 2.5

MOFScript MTF ADT Modfact GMT OAW OpenMDX AndroMDA SmartQVT Jamda UMLAUT KERMETA KMF

3.3. Caracterización desde la Perspectiva de Czarnecki y Helsen La Tabla 8 muestra las características propuestas por Czarnecki y Helsen que fueron identificadas en las herramientas MDA de código abierto seleccionadas para este estudio (ver Tabla 3). El análisis de los resultados indica que el 69% de las herramientas hacen uso de un enfoque híbrido, esto es, la transformación es expresada de forma declarativa e imperativa.

Tabla 8. Identificación de las Características propuestas por Czarnecki y Helsen [3]

Código de las Características (ver Tabla 3) Herramientas 3.1.1 3.1.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 MOFScript MTF ADT Modfact GMT OAW OpenMDX AndroMDA SmartQVT Jamda UMLAUT KERMETA KMF


514

3.4. Caracterización desde la Perspectiva de Tariq y Akhter La Tabla 9 muestra las características propuestas por Tariq y Akhter que fueron identificadas en las herramientas MDA de código abierto seleccionadas para este estudio. El análisis de los resultados indica que ADT cumple con la mayor cantidad de las características que debe tener una herramienta MDA según estos autores. No obstante, ADT sólo satisface el 30,4% de las mismas. SmartQVT y KERMETA le siguen, cumpliendo sólo un 17,3% de las características enunciadas por Tariq y Akhter. El resto de las herramientas satisfacen el 13% o menos de dichas propiedades. Estos números nos indican que las herramientas analizadas sólo están en capacidad de apoyar parcialmente el desarrollo de sistemas bajo el enfoque MDA.

Cabe destacar, además, que sólo el 52,17% de las características propuestas por los autores son satisfechas por las herramientas. Hay características que no son cumplidas por ninguna de éstas. Por otra parte, las características que se evidenciaron más fueron: transformación basada en modelos (46,15% de las herramientas) y soporte QVT/OCL (53% de las herramientas).

Tabla 9. Identificación de las Características propuestas por Tariq y Akhter [12]

Código de las Características (ver Tabla 4) Herramientas 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 MOFScript MTF ADT Modfact GMT OAW OpenMDX AndroMDA SmartQVT Jamda UMLAUT KERMETA KMF

3.5. Caracterización desde la Perspectiva de la Propuesta presentada en este Trabajo

La Tabla 10 muestra las características propuestas en este trabajo, que fueron identificadas en las herramientas MDA de código abierto seleccionadas para este estudio. El análisis revela que cuatro de las herramientas cumplen sólo el 37,5% de las características propuestas. Las restantes cumplen el 12,5% o el 25% de las mismas. Además, el 50% de las características no son satisfechas por ninguna de las herramientas analizadas. Nótese que las características que pueden evidenciarse más en las herramientas corresponden a su capacidad de transformar modelos CIM a PIM o de MOF a Texto (61,5 % de las herramientas). Ninguna de las herramientas estudiadas permite obtener algún modelo a partir de texto.


515

Tabla 10. Identificación de las Características propuestas en este Trabajo Código de las Características (ver Tabla 5)

Herramientas 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 MOFScript MTF ADT Modfact GMT OAW OpenMDX AndroMDA Jamda SmartQVT UMLAUT KERMETA KMF

4. Conclusiones En este artículo se presenta una caracterización de 13 herramientas de código abierto que apoyan el desarrollo dirigido por modelos. El objetivo de esta caracterización es facilitar su elección en términos de las necesidades de un particular desarrollo. El análisis realizado permitió determinar que la mayor parte de las herramientas estudiadas apoyan los procesos de desarrollo dirigido por modelos y, especialmente, aquellos relacionados estrechamente con la transformación de modelos. Más de la mitad de estas herramientas utilizan un enfoque híbrido de transformación (declarativa e imperativa). No obstante, el alcance del apoyo a la transformación que ofrecen las herramientas es bastante limitado, concretándose principalmente en la especificación de los modelos mediante QVT y OCL.

5. Referencias 1. Bennet K. H., Rajlich V. T.. Software Maintenance and Evolution: a Roadmap. Taken From: "The Future of

Software Engineering”, ACM Press, 2000. 2. Beydeda S., Matthias B., Volker G. Model-Driven Software Development. Springer. Berlin, 2005. 3. Czarnecki K., Helsen S. Classification of Model Transformation Approaches. OOPSLA’03: Workshop on

Generative Techniques in the Context of Model-Driven Architecture. University of Waterloo, Canada, 2003. 4. Díaz I., Moreno L., Fuentes I., Pastor O. Integrating Natural Language Techniques in OO-Method.

Proceedings of 6th International Conference on Computational Linguistics and Intelligent Text Procesing. LNCS 3406, V. 560-571. Springer-Verlag. February 2005.

5. Frankel D. Model Driven Architecture. Applying MDA to Enterprise Computing. Wiley Publishing, 2003. 6. Gaceta oficial Nº 38.095 del 28/12/ 2004. Decreto Nº 3.390. Republica Bolivariana de Venezuela.

http://www.gobiernoenlinea.ve/legislacion-view/sharedfiles/Decreto3390.pdf. 7. Jézéquel, J.M. Model Transformation Techniques. [Documento Electrónico]. Universidad de Rennes, 2005.

http://www.irisa.fr/prive/jezequel/enseignement/ModelTransfo.pdf 8. Kent S. Model Driven Engineering. Proceeding of IFM2002. LNCS 2335. Springer, 2002. 9. Modelbased.net. [Documento Electrónico]. http://www.modelbased.net/mda_tools.html 10. MOF: Model to Text Transformation Language. OMG Document, 2004. http://www.omg.org 11. Object Management Group. Model Driven Architecture. Guide Version 1.0.1. [Documento Electrónico].

OMG, 2003. http://www.omg.org/docs/omg/03-06-01.pdf. 12. Tariq N. A., Akhter N. Comparison of Model Driven Architecture (MDA) based Tools. Department of

Computer and Systems Sciences, Royal institute of Technology (KTH), Stockholm, Sweden, 2005. 13. Young R.R. The Requirements Engineering Handbook. Boston. London. Artech House, Inc. 2004.


516

Análisis de Características (Modo Preselección) para Evaluar Plataformas de Componentes

Merizeh Mijares1, Aleksander González1, Luis E. Mendoza2, María Pérez2, Anna Grimán2

1 Dirección de Ingeniería de Información, Edificio de Matemáticas y Sistemas,

Universidad Simón Bolívar, Apartado 89000, Baruta, Caracas, 1080-A, Venezuela {marizeh, gonzaleza}@usb.ve

2 Departamento de Procesos y Sistemas, Edificio de Matemáticas y Sistemas, Laboratorio de

Investigación en Sistemas de Información (LISI), Universidad Simón Bolívar, Apartado 89000, Baruta, Caracas, 1080-A, Venezuela

{lmendoza, movalles, agriman}@usb.ve

Resumen. En trabajos anteriores se propuso el Método de Evaluación de la Calidad de Arquitecturas Basadas en la Integración Componentes (MECABIC), como una solución al problema de la inexistencia de métodos que evalúen la Calidad de las Arquitecturas Basadas en Componentes. Sin embargo, para lograr que MECABIC ayude plenamente al arquitecto de software en el proceso de evaluación, se hace necesario la construcción de una herramienta que lo soporte. Por ello, fue necesario seleccionar la tecnología más adecuada en lo que se refiere a frameworks de componentes para lograr dicho objetivo. Este artículo presenta la aplicación de un análisis de características para evaluar la plataforma de componentes más adecuada para la implementación de MECABIC. El método seguido se conoce como Análisis de Características - Modo Preselección.

Palabras clave: Plataformas de componentes, evaluación, análisis de características.

1 Introducción

La arquitectura de software es de suma importancia para el desarrollo de un sistema, ya que ella es el corazón de éste [9], impactando los niveles de calidad asociados al sistema [2, 3]. Por tal motivo, para garantizar estas características o requerimientos de calidad, los arquitectos y desarrolladores de software necesitan métodos y herramientas que les den soporte durante el proceso de evaluación arquitectónica y que les permita documentar adecuadamente este proceso. Un análisis y revisión de la arquitectura de software puede asegurar que las decisiones tomadas, particularmente aquellas que afectan los requerimientos de Calidad, sean las más satisfactorias para el propósito del sistema [2, 3].


517

Sobre esta base, en trabajos previos se propuso el Método de Evaluación de la Calidad de Arquitecturas Basadas en la Integración Componentes (MECABIC), como una solución al problema de la inexistencia de métodos que evalúen la Calidad de las Arquitecturas Basadas en Componentes [3, 10]. Los arquitectos de software que apliquen este método podrán determinar si la arquitectura sugerida por el conjunto de componentes integrados en un sistema, promueven o no características como confiabilidad, seguridad y mantenibilidad, entre otras.

Ahora bien, para lograr que MECABIC ayude plenamente al arquitecto de software en el proceso de evaluación, se hace necesario la construcción de una herramienta que lo soporte; en concreto, en alguna de las principales corrientes de la industria en lo que se refiere a frameworks de componentes (COM, J2EE, Eclipse y .NET). Por ello, fue necesario seleccionar la tecnología más adecuada. Este artículo presenta la aplicación de un análisis de características para evaluar la plataforma de componentes más adecuada para la implementación de MECABIC. El método seguido se conoce como Análisis de Características - Modo Preselección.

Este artículo, además de la introducción, presenta en la sección 2 una breve descripción de los antecedentes del trabajo. En la sección 3 expone los basamentos del análisis de características, así como la definición de las características aplicadas posteriormente. En la sección 4 presenta la aplicación de las características antes definidas a las principales frameworks de componentes del mercado, así como el correspondiente análisis de resultados. Finalmente, en la sección 5 se exponen las conclusiones.

2 Antecedentes

2.1 Arquitecturas y frameworks de componentes

En [7] explican que en el campo del estudio de la arquitectura de software han existido dos líneas de investigación disjuntas. La primera busca estudiar asuntos de diseño, y fundamentos teóricos que ayuden a formalizar y analizar las arquitecturas, mientras que la segunda, se centra en la implementación arquitecturas. Es importante proporcionar un marco formal que expresar que tipo de configuraciones arquitectónicas basadas en componentes proporcionan características de calidad buscadas, y también, establecer una correspondencia con las arquitecturas implementadas. Para el caso de los componentes, los frameworks son los que proveen el conjunto de dependencias contextuales explicitas que se necesitan para desplegar los componentes [10], por lo tanto es deseable que al momento de hacer la evaluación se pueda determinar que características de calidad propicia o castiga el framework utilizado.

Según [9], los modelos de framework son similares a la vista estructural de un sistema, pero su énfasis primario radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su composición. Los modelos de framework


518

a menudo se refieren a dominios o clases de problemas específicos. Para el caso particular de componentes, los frameworks de componentes tienen la función de permitir la interoperabilidad (conexión) entre distintos componentes estándares o modelos de componentes, así como describir las tecnologías de ensamblaje de componentes que soportan [5, 10].

2.2 MECABIC

MECABIC es un método que se enfoca en evaluar y analizar la calidad exigida por los usuarios de Arquitecturas de Software Basadas en Componentes [5]. El método adapta diferentes elementos de algunos métodos de evaluación arquitectónica (ATAM, Bosch, ABD, ARID, Losavio) y establece un conjunto de pasos para determinar la calidad de los sistemas de software basados en componentes. Incluye orientaciones para generar y discutir escenarios iniciales a evaluar, y un conjunto de preguntas a partir de las cuáles estudiar las decisiones arquitectónicas consideradas.

Este método consta de 4 fases, tal como se puede observar en la Fig. 1.

Fig. 1. Fases de MECABIC [5].

3 Análisis de características – modo preselección

En su forma más simple, el análisis de la característica proporciona una lista de las respuestas de si/no a la existencia de una característica particular en un producto. Un tipo


519

de evaluación por un análisis de características es el hacer un análisis razonado más allá del “me parece bien” ese producto. En el enfoque de modo de preselección, la evaluación es realizada por una persona o un equipo, solamente en base a la documentación [6]. Es el mejor enfoque de investigación para una gran de métodos/herramientas y es a menudo usado como una primera etapa en un ejercicio más complejo de evaluación que implica reducir el número de posibles métodos/herramientas a una corta lista de uno o dos métodos/herramientas candidatos que puedan ser evaluados con más detalle [6]. Ésta es forma más económica, pero menos confiable de un análisis de características, por su alto nivel de subjetividad [6].

3.1 Definición de las características

En la Tabla 1 se presentan las definiciones de las características utilizadas en la comparación y que permiten diferenciar las plataformas de componentes participantes en la comparación.

Tabla 1. Definición de las características para la comparación. Característica Descripción

Interfaces Binarias Se refiere a la disponibilidad de un entorno normalizado que proporcione soporte a los mecanismos de comunicación de las interfaces.

Soporte de portabilidad y compatibilidad a nivel de código fuente

Se refiere a la capacidad de la plataforma de componentes para promover la creación/uso de componentes multiplataforma.

Manejo de memoria, ciclos de vida y recolección de basura

Se refiere al soporte que brinda la plataforma para el manejo de memoria, la creación, eliminación, copiado y movimiento de componentes, así como el servicio de recolección de memoria.

Conceptos de evolución y versiones

Se refiere a cómo la plataforma de componentes maneja los conceptos de evolución del software y manejo de versiones.

Concepto de categorías Se refiere a la incorporación del concepto de categoría de componentes y su manejo por parte de la plataforma.

Ambientes de desarrollo Se refiere a las facilidades y completitud de la plataforma de componentes para el soporte del desarrollo de componentes.

Dominio de mercados Se refiere al mercado (clientes y tipo) abarcado por la plataforma de componentes. Está relacionado directamente con el fabricante de la plataforma de componentes y de cómo este se ha posicionado en el mercado del software.

Servicios Se Refiere a establecer el soporte de servicios como un conjunto de procesos integrados.

Cableado Se refiere a la tecnología utilizada para “cablear” o interconectar a los componentes dentro de la plataforma.

4 Aplicación de las características y análisis de resultados

En la Tabla 2 se presenta el análisis entre los diferentes proveedores de plataformas del mercado COM, J2EE, Eclipse y .NET.


520

Tabla 2. Comparación entre las tecnologías de componentes ofrecidas por Microsoft, Sun, OMG e IBM.

Característica COM Sun IBM-Eclipse .NET

Interfaces Binarias

COM implementa una estandarización binaria para interacción entre componentes

Java implementa la estandarización en bytecodes (evitando la estandarización binaria). Para las interfaces a nivel binario, existe la Java Native Interface.

Eclipse se encuentra escrita en lenguaje Java, por lo que evita la estandarización binaria e implementa la estandarización en bytecodes. Tal como sucede con SUN, Java a nivel binario ofrece la Native Interface.

Al igual que COM., .NET implementa una estandarización binaria para interacción entre componentes. [8].

Soporte de portabilidad y compatibilidad a nivel de código fuente

COM no maneja el concepto de estandarización a nivel de código o compilación del lenguaje.

La especificación del lenguaje Java resuelve el problema de interoperabilidad y compatibilidad, pero no presta soporte para otros lenguajes.

El lenguaje Java promueve la interoperabilidad y compatibilidad, aunque no da soporte a otros lenguajes. Sin embargo, Eclipse se caracteriza entre otras cosas, en ser una comunidad de software abierto que crea tecnología y una plataforma universal y abierta de integración de herramientas. Dichas herramientas basadas en eclipse, dan a los desarrolladores libertad de elección de una ambiente multi-lenguaje. [1].

Uno de los atractivos más importantes de .NET es la muy mejorada disponibilidad de fácilmente utilizar código escrito en diferentes lenguajes. Con el fin de hacerlo, los lenguajes que soportan .NET necesitan compartir un formato común para exponer información que describe un tipo. La metadata es ese formato común. La metadata también es crucial para que .NET interopere con las APIs Win32 y objetos COM actuales. [8].

Manejo de memoria, ciclos de vida y recolección de basura

COM Y DCOM manejan control de referencias (para lo cual los componentes deben respetar el manejo de las referencias), sin embargo deja de funcionar en sistemas de gran magnitud, distribuidos y abiertos.

Java maneja un recolector de basura, que tiene soporte en ambientes distribuidos a partir de Remothe Method Invocation – RMI (JDK 1.1). El modelo de objetos distribuidos de Java maneja “leases” (tiempo de vida limitados para referencias remotas).

La programación requiere grandes habilidades y disciplina. Esto es especialmente cierto cuando se van a administrar recursos tales como archivos, memoria, conexiones de red, recursos de base de datos, etc. Uno de los tipos más comunes de errores ocurre cuando una aplicación se rehúsa a liberar uno de estos recursos, haciendo que ésta aplicación u otra fallen. CLR de .NET monitorea automáticamente el uso de los recursos, garantizando que su aplicación nunca tendrá escasez de recursos. Esto se denomina recolección automática de memoria-basura. No hay manera de liberar explícitamente un recurso de memoria, ya que la memoria-basura se recolecta automáticamente cuando ya no es necesaria. [8].

Conceptos de evolución y versiones

COM implementa la congelación de interfaces y sus especificaciones mediante un ID. Esto resuelve el problema del manejo de las versiones y el de migración, sin embargo, dificulta el manejo de la compatibilidad en ambientes de despliegue particulares.

Java implementa control de versiones únicamente a nivel binario.

Con Java es posible lograr el control de versiones, pero a nivel binario.

Los ensambles también juegan un rol en el sistema de seguridad .NET en que el ensamble es la unidad en la que se solicitan y otorgan los permisos. Para reforzar adecuadamente el versionamiento, implementación y características de seguridad en .NET, el ensamble actúa como el rango de resolución que se utiliza para resolver referencias a los tipos. [4]


521

Java y CORBA no manejan categorías. Concepto

de categorías

COM maneja débilmente las categorías.

En Java es posible simular las categorías mediante interfaces.

A pesar de que Java no maneja categorías, es posible simular éstas mediante interfaces.

Maneja débilmente las categorías

Ambientes de desarrollo

Los ambientes de COM y Java son los más desarrollados,

El ambiente de Eclipse es bastante completo y desarrollado. Eclipse ofrece una diversidad de plug-ins que dan soporte a los sistemas y aplicaciones de software libre. [1].

.NET posee un ambiente bastante desarrollado. Ofrece una gran variedad de herramientas de desarrollo, que permiten a los programadores, desarrollares en la creación aplicaciones. [7]. Microsoft ofrece un ambiente de desarrollo integrado con Visual Studio® .NET, el cual reduce la cantidad de experiencia que requieren los desarrolladores, permitiéndoles aprovechar esa experiencia en una amplia variedad de dispositivos. [7]

J2EE y COM dominan soluciones basadas en PC y servidores.

Dominio de mercados

COM es la más fuerte en implementación de soluciones en computadores clientes.

Los Web Services hacen gran uso de JSP, ASP Y ASP.NET

IBM anunció recientemente una nueva familia de herramientas de desarrollo de aplicaciones habilitadas para servicios web, bajo Windows y Linux, basadas en Eclipse. Además Eclipse da soporte a aplicaciones y sistemas de software libre. [1].

Microsoft ofrece a los desarrolladores un solo modelo de programación, Microsoft .NET Framework, que se extiende desde el escritorio hasta el servidor y hasta dispositivos móviles. El modelo de programación de servicios Web XML nativos de .NET Framework proporciona una manera consistente de crear aplicaciones, ya sea que un desarrollador esté escribiendo una aplicación para un teléfono WAP, Pocket PC, PC de escritorio con Microsoft Windows® XP u otros dispositivos tales como una Palm portátil o localizadores Blackberry. [7].

Servicios

COM+ complementa a COM con un variado conjunto de servicios, incluyendo manejo de transacciones y mensajes.

Java 2 Enterprise Edition también ofrece un gran número de servicios.

Eclipse ofrece una gran cantidad y variedad de servicios, tales como: Entornos gráficos para desarrollos; frameworks para desarrollo de servicios Web; ambiente de desarrollo para J2EE, que elimina la mayor parte del overhead asociado al desarrollo de aplicaciones J2EE, conjunto de plug-ins con el cuál se obtiene el estado del arte para el desarrollo de aplicaciones para Java server-side; etc. [8].

.NET ofrece una gran variedad de servicios, tales como: manejo de transacciones y mensajes; "HailStorm" es un nombre en clave para una colección de Servicios Web XML de Microsoft que, en conjunto, proporcionan una plataforma para crear aplicaciones centradas en el usuario; Mobile Information 2001 Server amplía el alcance de las aplicaciones empresariales, los datos empresariales y el contenido intranet de Microsoft .NET para el usuario móvil; Microsoft .NET Framework es la plataforma para desarrollar, implementar y ejecutar Servicios Web XML; Visual Studio.NET es una herramienta fácil y productiva para desarrollar aplicaciones basadas en Windows, aplicaciones Web y aplicaciones móviles para la Plataforma .NET; entre otros. [7].

Cableado

El protocolo de cableado de DCOM es usado también por COM, y COM+ soporta formatos múltiples de mensajería.

Java tiene su propio protocolo RMI, aunque soporta IIOP y XML.

.NET soporta protocolos de cableado como IIOP y XML. [4].

Se puede observar en la Tabla 2 que Eclipse propicia la interoperabilidad y compatibilidad, además se caracteriza, en ser el resultado de una comunidad de software abierto que crea tecnología y una plataforma universal abierta de integración de herramientas. Dichas herramientas basadas en eclipse, dan a los desarrolladores libertad


522

de elección de un ambiente multi-lenguaje [1]. Cabe señalar que el ambiente de Eclipse es bastante completo y desarrollado. Eclipse ofrece una diversidad de plug-ins que dan soporte a los sistemas y aplicaciones de software libre [1]. En este sentido, la comparación indica que para implementar MECABIC en una plataforma basada en componentes, la tecnología más adecuada sería Eclipse.

5 Conclusiones

En este artículo se establece que Eclipse es la plataforma más apropiada para implementar MECABIC, de acuerdo a la comparación entre los principales proveedores de tecnologías del mercado (COM, .NET de Microsoft; J2EE y Java de Sun Microsystems, e IBM con Eclipse). Por otro lado, se corroboró que la función de un framework de componentes es permitir la interoperabilidad (conexión) entre distintos componentes estándares o modelos de componentes. Además, los modelos de componentes también pueden imponer restricciones sobre la arquitectura y ejercer influencia sobre la calidad del sistema.

Agradecimientos. Esta investigación fue financiada por la USB, Venezuela, a través del proyecto DID S1-IN-CAI-012-06 y del Grupo de Investigación LISI - GID-043.

Referencias

1. Adams, G., Erickson, M.: Working the Eclipse Platform, IBM (2001) 2. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice. Segunda Edición.

Addison-Wesley (2003) 3. Bosch, J.: Design And Use of Software Architecture. Addison Wesley. Harlow, England (2000) 4. Carpe, F., Sevilla, D.: Estudio de la Plataforma .NET, Univ. de Málaga. Diciembre (2001) 5. González, A., Mijares, M., Mendoza, L.E., Pérez, M., Grimán, A.: Método de evaluación de

arquitecturas de software basadas en componentes (MECABIC). VII Jornadas Internacionales de las Ciencias Computacionales, Colima, México (2005)

6. Kitchenham, B.: DESMET: A method for evaluating Software Engineering methods and tools, Technical Report TR96-09. Keele University (1996)

7. Medivovic, N., Roseblum, D., Redmiles, D., Robbinns, J. Modeling Software Architectures in the Unified Modeling Language. ACM Transactions on Software Engineering and Methodology, 11(1) (2002) 2–57.

8. Rubiolo, D., Meier, J., Jezierski, E., Mackman, A.: Microsoft .NET Explained. Microsoft, 2001. 9. Shaw, M., Garlan, D. Software Architecture Perspectives on a Emerging Discipline. Prentice

Hall Inc., New Jersey (1996) 10. Szyperski et al., Component Software — Beyond Object-Oriented Programming, Tercera

edición, Addison-Wesley/ACM Press (2003)


523

Fábrica de Software Libre: Sirviendo al Bienestar Colectivo

Jose Aguilar1,2, Oswaldo Terán1,2,3, Johanna Alvarez1, Blanca Abraham1

1 FUNDACTE-Mérida, Vía La Hechicera, Mérida, Venezuela 2 Centro de Microprocesadores y Sistemas Distribuidos (CEMISID), Universidad de Los Andes,

Mérida-Venezuela. 3 Centro de Simulación y Modelos (CESIMO), Universidad de Los Andes, Mérida-Venezuela.

Tel: +58-0274-2447111. Fax: +58-0274-2440370 {aguilar, oteran}@ula.ve, {jalvarez, blanca}@funmrd.gov.ve

Resumen. En este trabajo se presentan los elementos tanto operativos como filosóficos de una Fábrica de Software Libre con localización concreta, implantada en una institución pública venezolana, el Centro Nacional de Tecnología Libres, el cual está al servicio (prioritariamente) del sector público venezolano. Se presenta una metodología elaborada en y para esta fábrica, donde se han combinado aspectos de modelos y métodos de desarrollo de software, así como elementos de la producción industrial, con los estilos de desarrollo de software libre catedral y bazar, siempre bajo la premisa de atender estratégicamente, y con visión a largo plazo, la problemática del sector público venezolano. A la vez, se complementan elementos tradicionales de la Ingeniería del Software con herramientas como la Planificación Estratégica y la Prospectiva Tecnológica, a fin de enfocarse de manera global en el problema social que se está tratando (e.g., búsqueda de la soberanía tecnológica) y la problemática particular del sector social receptor.

1 Introducción

Bajo la nueva estrategia territorial, en Venezuela se propone la creación de un modelo productivo que articule la acción de comunidades organizadas en unidades productivas para conformar Núcleos de Desarrollo Endógeno (NUDE) [11], adecuadamente ubicados en el territorio. Por otro lado, según el PNUD (Programa de la Naciones Unidas para el Desarrollo), las Tecnologías de Información y Comunicación (TICs) se manifiestan en dos estratos: uno de naturaleza estructural ("Infoestructura") y otro de naturaleza cultural ("Infocultura") [15]. En el primer estrato se incluye el conjunto de dispositivos de computación, almacenamiento, telecomunicación e interfaz (hardware), junto con todo el universo de programas básicos y de aplicación (software), y los registros de contenidos, en las distintas áreas de aplicación. Por otra parte, se le ha dado el nombre de Infocultura a aquella parte de la cultura orientada a comprender y usar de la mejor manera la Infoestructura para resolver los distintos problemas que se presentan en el devenir de la sociedad.


524

Es importante resaltar que en la ciudad de Mérida confluyen en la actualidad una serie de aspectos académicos, tecnológicos, económicos, sociales y políticos que la califican como un potencial núcleo de desarrollo endógeno basado en TICs [2]. Para impulsar el NUDE en TICs se requiere de instituciones públicas dedicadas al tema de Investigación y Desarrollo en TICs, las cuales asuman el reto de generar las políticas públicas y de articular los grandes proyectos del país en el sector. Así nace el Centro Nacional de Desarrollo e Investigación en Tecnologías Libres (CENDITEL), como un centro orientado a promover la reflexión, investigación, desarrollo y apropiación de Tecnologías Libres pertinentes (infoestructura del NUDE). Algunos de los proyectos actuales de dicho centro son: La Fábrica Nacional de Software Libre (FSL) y La Academia Nacional de Software Libre (ASL). Tanto la FSL como la ASL son localidades concretas, la primera de enseñanza de, y la segunda de elaboración de, software libre. En este trabajo hablaremos sobre la FSL.

2 Fábrica de Software Libre

Se define como “software libre” (SL) al software disponible al usuario de manera que éste pueda usarlo, acceder al código, modificarlo, y distribuirlo. Otro aspecto importante, en el desarrollo de SL es que este puede elaborarse de manera colectiva, por comunidades de desarrolladores que aportan soluciones desde lugares distantes, aprovechando los beneficios de la Internet, Intranet o cualquier tipo de comunicación en red que sirva a la comunidad de desarrolladores. Existen dos modalidades o modelos de desarrollo de SL, a saber (para más detalles, véase Raymond [16]): 1. Estilo Bazar: En este caso, el desarrollo de software no es dirigido de manera

centralizada, la construcción de la aplicación se realiza con la participación de una comunidad de interesados que libera frecuentemente cada versión desarrollada, con la finalidad de que otros puedan depurar el código.

2. Estilo Catedral: En el estilo catedral el desarrollo de software está dirigido de manera centralizada y el proceso de desarrollo esta restringido a un grupo de programadores, quienes trabajan fuertemente en la depuración del código con la finalidad de que los usuarios puedan ver menos errores en cada versión liberada. A pesar de que muchos colaboradores de una FSL puedan estar ubicados en diferentes

localidades, como lo sugiere el estilo Bazar, la fábrica, como entidad identificable, debe tener una ubicación específica a fin de facilitar el aprovechamiento de las ventajas de la producción industrial. Por otra parte, generalmente una FSL responde a necesidades o demandas con tiempos específicos, lo que implica que debe haber una planificación explícita y un control del avance de los proyectos específicos, de manera localizada y centralizada, aún cuando se haga uso de componentes re-usables desde la comunidad de SL.

Utilizando estas nociones, tenemos la siguiente definición de FSL: “localidad concreta


525

donde se elabora SL de manera eficiente y eficaz para satisfacer cierta demanda o necesidad especifica; aprovechando los beneficios de los criterios y conceptos útiles en la producción industrial (e.g., de la automatización y del re-uso de componentes); promoviendo el desarrollo colaborativo y solidario, ofrecido por comunidades de individuos o grupos localizados en lugares diversos.”

Una FSL promueve el desarrollo de software y la apropiación de la tecnología localmente, tanto a nivel de la fábrica misma como a nivel de comunidades de desarrolladores, mientras facilita el acceso al producto por parte de las comunidades y PYMES. Así, una FSL apunta hacia la independencia tecnológica, el crecimiento socio-productivo local, además de ofrecer características de seguridad importantes. Además, una FSL debe saber descubrir las necesidades del cliente, muchas de las cuáles irán más allá de la simple implementación de una aplicación de software. Para ello, no son suficientes las nociones tradicionales de gestión de desarrollo de software. Por tanto, se hace necesaria la inclusión de herramientas útiles para descubrir las necesidades y debilidades del sector social receptor del servicio, tales como la planificación estratégica y la prospectiva tecnológica [3, 9, 17]. Esto puede llevar a la creación, incluso, de otras organizaciones que apoyen y complemente a la FSL en su rol social. En este contexto aparece, por ejemplo, una ASL, que promueve la enseñanza en torno al uso del SL, a fin de disminuir la falta de comprensión y conocimiento en torno al SL (una debilidad actual del sector social receptor).

2.1 Aspectos considerados para la creación de la FSL de CENDITEL

La FSL de CENDITEL ha estado desarrollando SL para instituciones públicas venezolanas desde el 2003. Actualmente en la FSL de CENDITEL trabajan más de veinte ingenieros y técnicos especialistas en análisis y desarrollo de software. Así mismo, la FSL se fortalece con el trabajo colaborativo de toda la comunidad de desarrolladores que desee contribuir en el progreso de alguno de los proyectos en particular o iniciar uno nuevo, pues la plataforma colaborativa [10] permite que se descarguen y se incorporen actualizaciones de sistemas existentes.

La FSL de CENDITEL ha sufrido un proceso de mejoras a medida que se desarrollar y aplica una metodología [1, 6], basada en modelos organizacionales de referencia y métodos de desarrollo. Entre a los métodos que han sido tomadas en cuenta para el desarrollo de una metodología para la FSL de CENDITEL (a ser presentaba brevemente en la sección 3) tenemos: Watch [12], la Programación Extrema (XP) [4], y Rational Unified Process [8]. De la misma manera, en relación a modelos de desarrollo de referencia, de donde se han tomado también ideas para la metodología de la FSL, entre otros, se tienen: el Modelo de Procesos para Desarrollo y Mantenimiento de Software (MoProSoft) [7, 13, 14], y CompetiSoft: Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica [5].

La metodología se apoya en el desarrollo colaborativo, y apuntala los siguientes


526

aspectos: 1. Procesos de desarrollo bien definidos (según un marco metodológico) 2. Elevada calidad del producto y capacidad de los procesos. 3. Mecanismos, herramientas y formatos estandarizadas para facilitar el desarrollo

colaborativo. Esto se traduce en facilidades para la liberación del código fuente, junto a la documentación asociada al mismo; la re-utilización de componentes provenientes de la comunidad de SL; así como el uso de herramientas y formatos de documentación que faciliten las diferentes fases del desarrollo.

4. Tomar en consideración las ventajas de los estilos de desarrollo catedral y bazar.

3 Modelo de Procesos de la FSL de CENDITEL

El modelo de procesos que sirve de base a la FSL de CENDITEL se basa en un esquema de desarrollo iterativo e incremental, orientado a la construcción de aplicaciones de software utilizando herramientas libres. La metodología de desarrollo se basa en una estructura organizacional orientada a procesos específicos: Gestión de Proyectos de Software, Administración de Proyectos de Software y Desarrollo de Aplicaciones de Software. La relación entre estos procesos se muestra en la Fig. 1.

Fig. 1. Relación entre los procesos de Gestión, Administración y Desarrollo de Aplicaciones de Software.


527

Tal como se muestra en la figura, los tres procesos se retroalimentan entre sí a través de los principales productos que se generan en cada proceso. Los procesos mostrados en la Fig. 1 se describen brevemente a continuación.

3.1 Proceso de Gestión de Proyectos de Software

En este proceso se realizan una serie de actividades en las cuales se genera un conjunto de documentos relacionados con: a) conceptualización del proyecto, b) estudio de factibilidad de un desarrollo por parte del personal de la organización o por contratación, c) priorización de funcionalidades y riesgos, d) descripción del proyecto, e) plan del proyecto, f) oferta de servicio y g) establecimiento de los acuerdos de liberación y uso del código fuente. De este último documento depende que el código fuente y la documentación asociada al mismo puedan ser publicadas. Es importante mencionar que en el caso del plan del proyecto son considerados tres aspectos fundamentales para la planificación del desarrollo. Estos aspectos tienen que ver con la priorización de funcionalidades, la priorización de riesgos de desarrollo y las dependencias entre funcionalidades. Estos aspectos son utilizados para determinar el orden de desarrollo de las funcionalidades en cada iteración.

3.2 Proceso de Administración de Proyectos de Software

Cada proyecto de software que se lleva a cabo en la organización tiene un administrador o líder del proyecto. Este administrador se encarga de planificar y coordinar, a través de la plataforma de desarrollo colaborativo, las actividades respectivas a cada iteración (i.e., secuencia precisa de actividades basadas en un plan y unos criterios de evaluación establecidos que resultan en una liberación ejecutable de la aplicación). Adicionalmente, el mismo es responsable de publicar las versiones de la aplicación (siempre y cuando los acuerdos de liberación y uso del código fuente lo permitan) y de administrar las listas de correo, los foros y las demás actividades asociadas al proyecto que puedan ser manejadas desde la plataforma. La plataforma de desarrollo colaborativo cuenta a su vez con un administrador. Este administrador realiza actividades como: implementar nuevas funcionalidades al servidor (plataforma), y administrar el sistema de control de versiones, la lista de correo, los foros y las tareas de los proyectos adscritos a la plataforma.

3.3 Proceso de Desarrollo de Aplicaciones de Software

Una vez elaborado el plan del proyecto y la planificación de la iteración correspondiente, se comienza a realizar un conjunto de actividades distribuidas por fases, las cuales conforman el Proceso de Desarrollo de Aplicaciones. En base a estas actividades se planifica cada una de las iteraciones contempladas en el plan del proyecto. Las fases del


528

Proceso de Desarrollo de Software (Libre) [1] y la relación entre las mismas se presentan en la Fig. 2. A diferencia de otras metodologías y métodos orientados al desarrollo de SL donde se han descuidado un poco los sub-procesos Especificación de Requerimientos e Implantación, en esta metodología se da a éstos la misma importancia que al resto de los sub-procesos. Ello ocurre dado que la FSL tiene clientes específicos y debe cumplir con compromisos en ciertos lapsos de tiempo, además de que se requiere tener una relación estrecha con el interesado. Además, la metodología da importancia tanto al desarrollo Bazar como al Catedral.

Fig. 2. Fases del Proceso de Desarrollo de Aplicaciones de Software (Libre).

5 Conclusiones

En este artículo se ha presentado la FSL de CENDITEL, desde su contexto, pasando por una revisión de su sentido para la sociedad y la forma particular de servir a ésta, dado este sentido, hasta elementos particulares de su implementación. Se ha hecho énfasis en el fin social de una fábrica de SL, y en su compromiso estratégico, en este caso particular, con una visión de país donde se promueven el desarrollo endógeno y la soberanía tecnológica. Bajo esta situación, la idealización o diseño de la FSL debe nutrirse de múltiples fuentes, desde aquellas que tienen que ver con el desarrollo tradicional de software (Ingeniería del


529

Software, métodos y modelos de desarrollo de software), con formas de producción industrial, o con los diversos estilos de desarrollo de SL; hasta herramientas conceptuales de análisis y gestión de la problemática social o organizacional, las cuales van más allá de lo tradicionalmente utilizado en los desarrollos de software (e.g., planificación estratégica y prospectiva tecnológica). Con el propósito de cumplir de manera apropiada su rol social, la FSL requiere de otras instituciones que la complementen y faciliten la generación de impacto, dadas las debilidades sector social receptor. Entre estas instituciones está la Academia de Software Libre, cuyo rol es disminuir la falta de conocimiento del SL, tanto en relación a su uso como a la filosofía que le da sentido. Finalmente, la FSL y la ASL aparecen en un momento histórico con un fin enmarcado dentro de un proceso de cambio social que persigue objetivos muy particulares (e.g., promoción del desarrollo endógeno), los cuales exigen una constante revisión de las estrategias y operaciones específicas ejecutadas, a medida que el proceso avanza. A ello no escapa la forma como se implementan la FSL y la ASL, su concepción, sus estrategias y sus acciones específicas.

Referencias

1. Alvarez, J. et al., “Metodología para el Desarrollo de Software Libre: Buscando el Compromiso entre Funcionalidad y Riesgos”, Reporte Técnico 001-2006, Fábrica de Software Libre, Fundacite, Merida, 2006.

2. Aguilar, J., I. Vivas, “El Desarrollo Endógeno y las Tecnologías de Información y Comunicación en Venezuela” en Ochoa, Alejandro (Ed.) (2006) Aprendiendo En torno al Desarrollo Endógeno. CDCHT- CSI- FUNDACITE.

3. Aguilar, J., Terán, O. y Morantes, W., Prospectiva Tecnológica, Fundacite-Mérida (Ed.), Mérida, 2006.

4. Beck, K., “Extreme Programming Explained: Embrace Change”, Second Edition, Addison Wesley Profession, 2004.

5. CompetiSoft. http://alarcos.inf-cr.uclm.es/Competisoft/CompetiSoft. 6. Corredor, Y., Evaluación de MoProSoft como alternativa metodológica de organización de

empresas de desarrollo y mantenimiento de software, Tesis de Pregrado, Escuela de Ingeniería de Sistemas-Universidad de Los Andes, Mérida, Venezuela, 2006.

7. EvalProSoft. http://www.software.net.mx/NR/rdonlyres/ED7B3399-0CA4-412E-9FAC-0EEB94F85C5F/1224/EvalProSoftv11.pdfEvalprosoft

8. Kruchten P., The Rational Unified Process – An Introduction, Second Edition, Addison-Wesley, 2000.

9. Matus, C. y Zambrano, A., Gobierno y Planificación, Guía de Análisis Teórico, IESA Centro Zulia, 1997.

10. GFORGE. http://gforge.org/ 11. Ministerio de Planificación y Desarrollo, Núcleos de Desarrollo Endógeno, Caracas, 2004. 12. Montilva, J., “Desarrollo de Aplicaciones Empresariales: El Método WATCH”, Mérida,

Venezuela, 2004.


530

13. MoProSoft.http://www.software.net.mx/desarrolladores/prosoft/Estudios/precios_moprosoft_nmx.htm

14. Oktaba, H. et al., Modelo de Procesos para la Industria de Software (MoProSoft, Versión 1.3), 2005 (http://www.software.net.mx).

15. Programa de las Naciones Unidas para el Desarrollo, Informe sobre Desarrollo Humano en Venezuela 2002, Caracas, 2002.

16. Raymond, E., The Cathedral and The Bazaar, O’Reily, October, 1999. 17. Zambrano, A. Gerencia Estratégica y Gobierno. Ediciones IESA. 2001.


531

Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología

Lornel A. Rivas1,2, María Pérez2, Luis E. Mendoza2, y Anna Grimán2

1 Gerencia de Investigación, Instituto Nacional de Investigaciones Agrícolas, Avenida Universidad, vía El Limón, Apartado 2103, Maracay, Edo. Aragua, Venezuela

[email protected]

2 Departamento de Procesos y Sistemas, Edificio de Matemáticas y Sistemas, Laboratorio de Investigación en Sistemas de Información (LISI),

Universidad Simón Bolívar, Apartado 89000, Baruta, Caracas, 1080-A, Venezuela {movalles, lmendoza, agriman}@usb.ve

Resumen. Las herramientas para el desarrollo de software (HDS) desempeñan un importante papel en el desarrollo de aplicaciones. Como parte de la ingeniería de software (IS), las HDS han experimentado cambios en los últimos años. Aún ante la existencia de numerosas herramientas, es necesario abordar temas genéricos sobre las HDS, identificar tópicos relevantes y sus relaciones para facilitar su comprensión y análisis. Esta investigación en progreso, establece la construcción de una ontología que describe conceptos y relaciones para la investigación en HDS. Parte de las HDS en el contexto de la IS: las disciplinas, las áreas de conocimiento y las herramientas como una capa de la IS, para dar lugar a una exploración mayor sobre las definiciones de HDS, las características que definen sus beneficios y las taxonomías disponibles. Ello procura establecer conexiones y motivar una visión de conjunto para su análisis.

Palabras clave: herramientas, ingeniería de software, ontología, desarrollo de software.

1. Introducción

Las herramientas de desarrollo de software (HDS) han desempeñado un importante papel en el desarrollo de aplicaciones. Como consecuencia del avance tecnológico éstas han experimentado también continuos cambios. Así como se cuenta en la actualidad con documentación sobre las numerosas HDS disponibles, y con trabajos de investigación que revelan avances en herramientas particulares, existe también en la literatura evidencia de que los escritos técnicos genéricos sobre HDS son relativamente escasos [4], identificándose la pertinencia de canalizar iniciativas para la formulación de modelos conceptuales, que apoyen la compresión (y el uso posterior) de las HDS.


532

En este trabajo en progreso, se formula una ontología que identifica los tópicos relevantes de las HDS y sus relaciones y genera elementos de referencia para futuros trabajos.

Además de esta introducción, el trabajo presenta en la sección 2 una breve descripción de la metodología utilizada. En la sección 3 y 4 se explica la construcción de la ontología a través del análisis del contexto de la ingeniería de software y de las herramientas el desarrollo, respectivamente. Finalmente, en la sección 5 se exponen las conclusiones obtenidas.

2. Metodología

Según [7] una ontología es una descripción explícita y formal de conceptos en un dominio de discurso. A continuación se mencionan las actividades realizadas, en el marco de la metodología propuesta por estos autores [7] para crear ontologías: a) se identificaron conceptos comunes de cada tema, y otros no comunes pero sí relevantes; b) se tomó en cuenta información recientes sobre aspectos asociados a las HDS; c) no se encontraron ontologías sobre este tema; d) los términos importantes son descritos a lo largo de este artículo, destacando jerarquías y relaciones; e) no se especifican las propiedades ni se crean instancias dado que aún no se aplica a ningún caso de estudio.

3. Las Herramientas en el Contexto de la Ingeniería de Software

Desde sus inicios, la IS ha estado relacionada con otras disciplinas de la ingeniería: Ingeniería en computación, Ciencias de la computación, Gestión, Mantenimiento, Matemáticas, Gestión de proyectos, Gestión de la calidad, Ergonomía del software e Ingeniería de sistemas [4]. Así, en el marco de sus propios principios y sin concebirse de manera aislada de otras disciplinas la IS abarca todos los aspectos de la producción del software [12].

3.1 Las Herramientas como Área de Conocimiento de la IS

Las disciplinas conforman una visión de contexto de la IS. Hacia lo interno, existen un conjunto de áreas de conocimiento que facilitan la comprensión del alcance y las limitaciones de diferentes temas en la IS. Estas áreas son: Requerimientos, Diseño, Construcción, Pruebas y Mantenimiento de software, Gestión de la configuración, Gestión de la ingeniería y del proceso de la ingeniería de software, Herramientas y métodos de software, y Calidad de software. De este modo, las herramientas de software y los


533

métodos, integran un área específica de la IS, y contribuyen a la producción de software de alta calidad, con bajo costo y en el menor tiempo posible.

3.2 Herramientas en el Ámbito de la IS como Tecnología Multicapas

Pressman plantea una arquitectura general de la IS como una tecnología multicapas [8], una perspectiva que la representa en un conjunto cuatro grandes capas o niveles -que integran a su vez diferentes conceptos - con ciertas relaciones entre ellas (Fig. 1). Estas capas se describen a continuación: • Enfoque de Calidad. Establece el un apoyo sobre el cual debe sustentarse

necesariamente cualquier enfoque de IS [8] y determina una vinculación directa del desarrollo de software con la satisfacción de los requerimientos de los usuarios.

• El Proceso. Permite un desarrollo racional de la IS [8] y comprende actividades técnicas y de gestión propias asociadas al ciclo de vida del software [4]. Está determinado por un modelo, una representación formal de un sistema [10]. En la IS, un modelo se comporta también como una estrategia de desarrollo [8].

Fig. 1. Herramientas como una capa de la IS.

• El Método. Un método es una guía general para ayudar al desempeño de una actividad [10]. En la IS, los métodos indican cómo construir el software. Los métodos tienen dimensiones de eficiencia y de efectividad, sentido del proceso y del producto, cualidades que se atribuyen directamente a la calidad del software [2].

• Las Herramientas. Todo método tiene uno o varios instrumentos y técnicas asociados a él, con un grado de adecuación que depende generalmente del contexto de aplicación. Instrumento o herramienta, sería aquello que nos permite transportarnos por el método [2]. Así, las HDS proporcionan un enfoque automático o semi automático para el proceso y para los métodos.

4. Herramientas de Desarrollo de Software

Actualmente se considera a las HDS como herramientas basadas en computadoras que asisten el proceso de ciclo de vida de software [4], consolidadas en la literatura en la


534

forma de Ingeniería de software asistida por computadora (CASE, por sus siglas en inglés). Esto es, software que se utiliza para ayudar a las actividades del proceso de software o software que es utilizado para diseñar y para implementar otro software [12].

Permiten automatizar acciones bien definidas, reduciendo también la carga cognitiva del ingeniero de software, quien requiere libertad para concentrarse en los aspectos creativos del proceso. Este soporte se traduce en mejoras a la calidad y la productividad en el diseño y desarrollo [1, 11]. Las HDS automatizan metodologías de software y desarrollo de sistemas y se vinculan con los diferentes conceptos involucrados en el desarrollo (Fig. 2).

Fig. 2. Visión ampliada de las herramientas como una capa de la IS.

4.1 Mejoras que Provee el Uso de HDS

El soporte que brindan las HDS al proceso de desarrollo proporciona importantes ventajas para el equipo de trabajo de IS (Fig. 3). Estas mejoras se sintetizan en: a) Apoyan a las metodologías y métodos [1, 5], integrando actividades y propiciando visión de continuidad entre fases metodológicas; b) Mejoran la comunicación entre los actores involucrados, facilitándoles compartir su trabajo [5] y desempeñarlo de forma dinámica e iterativa; c) Establecen métodos efectivos para almacenar y utilizar los datos [1], lo que permite organizar y correlacionar componentes, para accesarlos a través de un repositorio [5]; d) Agregan eficiencia al mantenimiento, ya que los programas son construidos sobre las mismas estructuras y estándares, facilitando la adherencia a la disciplina de diseño [1, 9] y facilitan también la conversión automática de programas a versiones más recientes de lenguajes de programación [12]; y, e) Automatizan porciones del análisis y diseño tediosas y propensas a error [5], con influencia sobre la generación de código, las pruebas y el control. Resalta la consideración de que los beneficios potenciales sólo pueden ser alcanzados si las HDS son utilizadas de forma correcta [5].


535

Fig. 3. Mejoras que provee el uso de HDS.

4.2 Clasificaciones de las Herramientas

Establecer una clasificación resulta importante para comprender los tipos de herramientas disponibles y su soporte al proceso del software [5]. En adelante se exponen las principales perspectivas, o formas de clasificación de las HDS, disponibles en la literatura. En la práctica, los límites entre estas clasificaciones son difusos [8], lo cual contribuye al argumento de que no es fácil ubicar una herramienta utilizando una clasificación particular. En la Fig. 4 se representan estas tres perspectivas, en una manera bastante general (razón por la cual las HDS funcionales no se describen en detalle).

Fig. 4. Clasificación de HDS desde diferentes perspectivas.

• De acuerdo con las funciones que la herramienta soporta. En esta perspectiva, las HDS se clasifican según su función específica dentro del proceso de desarrollo [8, 12]. En la literatura se identifican hasta 22 tipos de herramientas clasificadas funcionalmente [8]. Estas clasificaciones tienen una intención orientadora, apuntan a mostrar la amplitud de las herramientas y sus aportes a distintas etapas del desarrollo [12], más que a establecer taxonomías rigurosas.

• De acuerdo con el actor que es soportado por la herramienta. Esta perspectiva se basa en el sujeto a quien soporta la herramienta, y las define como: a) De Alto nivel, que ayudan principalmente a los analistas y diseñadores, permitiéndoles crear y modificar el sistema [1]; y, b) De Bajo nivel, utilizadas por programadores y trabajadores quienes deben implementar los sistemas diseñados.


536

• De acuerdo con el proceso. En esta clasificación se definen tres categorías: a) las Herramientas, que ayudan a tareas puntuales y se utilizan a discreción del ingeniero de software; b) los Bancos de trabajo, que agrupan herramientas que mantienen algún grado de integración y soportan a un método que incluye un modelo del proceso [8]; y, c) los Ambientes, que apoyan a los procesos de software, incluyen bancos de trabajo integrados y soportan a los datos, al control y a la integración [3].

• Tópicos de las herramientas, como sub área de conocimiento de la IS. A modo de cierre, resulta pertinente considerar la definición de los tópicos relativos a las HDS [4]. En esta clasificación existe un conjunto de herramientas dentro de cada tópico, cuyo campo de acción se asocia no sólo con las actividades propias de cada uno de estos, sino también se considera el caso de herramientas que prestan soporte con un carácter transversal, como el caso de las herramientas misceláneas (Fig. 5).

Fig. 5. Tópicos de las HDS, como sub área de conocimiento de la IS.

Con la intención de procurar una visión global de estas perspectivas, se presenta en la Fig. 6 una expresión integradora de las mismas. Si bien en la Fig. 6 no expresa con detalle todos los tipos de HDS a los cuales se ha hecho referencia en este trabajo -dado su número- se resalta la oportunidad de establecer relaciones y motivar el análisis, como aporte al proceso de conformación del mapa conceptual.

5. Conclusiones

En este artículo se propone una visión global de las HDS, que facilita la comprensión de los temas que se abordan en esta primera etapa de investigación, y los que sean agregados y debidamente relacionados durante la construcción de la ontología. Esta expone, asimismo, los elementos de referencia para el análisis contextual de características de las HDS, como apoyo al desarrollo de proyectos de IS. La revisión bibliográfica muestra que las HDS, junto con los métodos, constituyen un área de conocimiento específica y relevante de la IS, que es a su vez parte de un conjunto de disciplinas relacionadas de la ingeniería. En este contexto, las HDS contribuyen a la producción de software de alta calidad, a bajo costo y en el menor tiempo posible. Sin embargo, sus beneficios potenciales serán logrados sólo si las HDS se utilizan en forma correcta.


537

Fig. 6. Visión global de las perspectivas de clasificación de las HDS.

Agradecimientos. Esta investigación fue financiada por el FONACIT, Venezuela, a través del proyecto G-2005000165.

Referencias

1. Alter, S. Information systems. The foundation of e-business. (4th. ed.). USA: Prentice Hall (2002). 2. Callaos, N. Metodología sistémica de sistemas. Conceptos y aplicaciones. Trabajo de ascenso a la categoría

de titular. Venezuela: Universidad Simón Bolívar, (1995). 3. Fuggetta, A. A classification of CASE technology. Computer. Publication, 26 (12), (1993), 25-38. 4. IEEE. Guide to the software engineering body of knowledge SWEBOK. A project of the IEEE Computer

Society Professional Practices Committee. USA: IEEE computer Society (2004) 5. Kendall; Kendall. Systems analysis and design (5th ed.) USA: Prentice Hall (2002). 6. Martin, E., Brown, C., De Hayes, D.; Hoffer, J.; Perkins, W.; Managing information technology (5th. ed.)

USA: Prentice Hall (2004). 7. Noy, N. y McGuinness, D. Ontology Development 101: A Guide to Creating Your First Ontology. in Protege

Documentation. Stanford University: Stanford, CA. (2001). 8. Pressman. Ingeniería del software (6ta ed.) . España: McGraw-Hill (2005). 9. Premkumar, G., Potter, M. Adoption of computer aided software engineering (CASE) technology: an

innovation adoption perspective. Data base advances. 26 (2y3), (1995), 105-124. 10. Rumbaugh, J. OMT Insigh. Perspectives on modeling from the Journal of Object-Oriented Programming.

England: Cambridge University Press (1998). 11. Sharma, S.; Rai, A. CASE deployment in IS organizations. Comm. of the ACM, 43(1), (2000), 80-88. 12. Sommerville, I. Ingeniería del Software (7ma. ed.) España: Pearson Educación (2005). 13. Whitten, J., y Bentley, L. Systems Analysis and Design Methods. (6th. ed.) USA: McGraw Hill (2004).


538

Comunidades Virtuales centradas en Usabilidad y Sociabilidad

Boris Guevara, Jean Carlos Guzmán y Nancy Zambrano

Centro de Ingeniería de Software y Sistemas (ISYS.) Escuela de Computación. Facultad de Ciencias. Universidad Central de Venezuela.

Apdo. 47002, 1041-A. Los Chaguaramos 1041-A. Caracas, Venezuela [email protected], [email protected],[email protected]

Resumen. The term community is defined by the sociologists like a type of social group. A social group is a set of people who persecute a common goal, for which establish a network of relations product of its interaction and communication, whose conduct is governed by a set of cultural norms, interests share, beliefs and common values. In this sense, a virtual community is an efficient space for the interchange of knowledge, interests, beliefs and values and simultaneously effective to generate new knowledge of collective form. Similarly, a virtual space that it wants to foment the formation of a community, requires to facilitate the usability of the space by means of a oriented design to maximize the capacities of interaction of the available space. The usability is the specific aspect that not only foments the participation but that makes possible without it represents a complex and intimidate process for the participant. In order to finalize the sociability one talks about those elements that influence the social interaction between the members of a virtual community, aspects such as the collective purposes and the roles that each individual assumes in the virtual community, they are some of the characteristics of its sociability.

Palabras clave: Communities, Communities Virtual, Sociability, Usability.

1 Introducción

La revolución de las Tecnologías de la Información y de las Comunicaciones (TIC) ha provocado cambios en el entorno social, económico, político y cultural. En este trabajo interesa destacar el papel mediador de las TIC en los procesos de comunicación entre personas de las organizaciones y cómo puede ser aprovechada por las comunidades. Este carácter comunicacional de la informática agrega como medio central las aplicaciones interactivas y como parte de estas la interfaz, que constituye la capa de interacción. Sin embargo, es necesaria la diversificación de dichas aplicaciones, en virtud que cada vez más se disponen poderosas innovaciones tecnológicas, las cuales avanzan de una manera vertiginosa permitiendo la evolución de las comunidades sustentadas en las TIC,


539

originando nuevas líneas de investigación entre las cuales se encuentran los temas de sociabilidad y de usabilidad asociados a las comunidades virtuales. Esta investigación se encuentra estructurada de la siguiente manera: en Primer lugar; se presenta el concepto, características, taxonomía y los factores de éxito de una comunidad virtual. En segundo lugar, se muestra el tema de usabilidad en las comunidades virtuales. En tercer lugar, se expone el tópico de sociabilidad en las comunidades virtuales. Y finalmente, se presentan las futuras investigaciones, las conclusiones y la bibliografía.

2 ¿Qué es una comunidad virtual?

Según Rheingold [8], se define como comunidades virtuales a las agregaciones sociales que emergen en la red cuando un número suficiente de personas entablan discusiones públicas durante un tiempo lo suficientemente largo, con suficiente sentimiento humano, para formar redes de relaciones personales en el ciberespacio. En esta definición encontramos tres elementos básicos: la interactividad, el componente afectivo y el tiempo de interactividad, como condiciones para que exista una comunidad virtual y ellas corresponden a algunas de las características de las comunidades en general.

Para Michael Powers [7], una comunidad virtual es un espacio electrónico donde un grupo de personas se reúne para intercambiar ideas de una manera regular, y denota una generalización de la vida habitual donde realizamos un conjunto de actividades extras a las comunes por medio de dispositivos computacionales donde nos reunimos, conversamos, compartimos y colaboramos con otras personas, conformando un entorno de relaciones sociales. Bajo esta percepción, se puede decir que una comunidad virtual está conformada por un componente de usabilidad y otro de sociabilidad [4], como expresa la Fig. 1, donde la sociabilidad es clasificada en tres aspectos: persona, propósito y políticas.

Fig. 1. Componentes Claves de una Comunidad Virtual. Adaptado de Preece (2003).

Personas

Propósito

Políticas Softw

are

Sociabilidad Usabilidad


540

2.1 Características y Taxonomía de las Comunidades Virtuales

Según Figallo [1], una comunidad virtual se distingue por las siguientes características: (1) El miembro se siente parte de una totalidad social amplia: sentido de pertenecía. (2) Existe una red de relaciones entre sus miembros: lazos sociales. (3) Hay una corriente de intercambio de contenidos que tienen valor para sus miembros: colaboración y cooperación. (4) Las relaciones entre los miembros se mantienen en el tiempo, creando un conjunto de historias compartidas: sustentabilidad. Bajo este contexto, Hagel y Armstrong [2] presenta la siguiente taxonomía: • Comunidades orientadas hacia el usuario: los usuarios definen el tema de la

comunidad. Se pueden subdividir en: (a) Comunidades geográficas: agrupan personas que viven en una misma área geográfica o interesadas en intercambiar información sobre un área geográfica. (b) Comunidades demográficas: reúnen usuarios de características demográficas similares, por ejemplo: jóvenes, personas de edad madura, mujeres, personas de una misma profesión. (c) Comunidades temáticas: orientadas hacia la discusión de un tema de interés para los usuarios, de tipo científico, cultural, político, comercial, recreativo, económico o social.

• Comunidades orientadas hacia la organización: el tema es definido según los objetivos y áreas de trabajo de la organización. Se pueden subdividir en: (a) Comunidades verticales: agrupan usuarios de empresas de diferentes ramas de actividad económica (u organizaciones de diferentes áreas institucionales de la sociedad). (b) Comunidades funcionales: se refieren a un área específica del funcionamiento de la organización.

Figallo [1] fija una visión diferente y propone una tipología basada en tres criterios: (1) Grado de interactividad entre los miembros de la comunidad: Comunidades interactivas, (2) Grado de focalización del tema de discusión: Comunidades temáticas y (3) Grado de cohesión social: Comunidades afines o con propósitos específicos.

2.2 Factores de éxito en las Comunidades Virtuales

El éxito de una comunidad virtual puede ser medido en términos de la cantidad de personas participantes, la cantidad e interactividad de las discusiones y la clase de políticas [6]. Según De Souza y Preece [4] toda comunidad consta de tres componentes: (1) un componente de comunidad virtual con cuatro elementos ontológicos: comunidad, personas, propósitos y políticas; (2) un componente interpretativo que proporciona las pruebas de adecuación de los comportamientos comunicacionales en la comunidad aplicando un sistema basado en señales determinado culturalmente (señales que dan un sentido semiótico, tal como señales comunes de conversación coloquial para cualquier hablante de un leguaje particular); y (3) un componente framework de las comunidades virtuales: el componente de usabilidad y sociabilidad que examina tanto atributos individuales (por ej. la reciprocidad) así como los atributos colectivos de sociabilidad (por ej. la cultura de la comunidad). En la Fig. 2, se hace una adaptación de esta propuesta y se


541

describen los componentes fundamentales de una comunidad virtual y las relaciones que existen entre ellos. Se incorporan los tipos de información que conforman una comunidad virtual, así como también las aplicaciones colaborativas que deben estar disponibles para que sea posible la interacción.

Fig. 2. Modelo de una Comunidad Virtual.

En la Fig. 3, se muestra el componente calidad integrado por las cualidades de usabilidad y sociabilidad, es una instanciación del metamodelo calidad y esta vinculado al componente análisis por medio del conector evaluación. El componente de análisis esta constituido por las partes: pruebas, interpretación y mejoras que son realizadas al componente comunidad, así mismo las comunicaciones permiten la realización del componente análisis. No obstante, el componente comunidad es una representación de las partes más relevantes del modelo de comunidad expresado en la Fig. 2.


542

Fig. 3. Componentes de una Comunidades Virtual.

3 Usabilidad en las comunidades virtuales

La usabilidad es percibida como una cualidad que permite el uso productivo de una aplicación interactiva en la realización de una o varias tareas particulares de una manera rápida y efectiva. Preece y otros [5], plantean que un software con buena usabilidad contribuye al rápido aprendizaje, alta habilidad de retención, baja tasa de errores y alta productividad. Este es consistente, controlable y fiable, haciendo agradable y eficaz su uso. La usabilidad es una cualidad del software que está estrechamente ligada a la interfaz de la aplicación. Nielsen [3] establece que la interfaz de una aplicación es usable si posee los siguientes atributos: fácil de aprender, eficiente en cuanto al uso, fácil de memorizar, baja tasa de errores (que minimice los errores que pueda cometer el usuario) y que logre la satisfacción del usuario. Concretando, se puede decir que la usabilidad permite mejorar la iteración entre el usuario y la aplicación aunque esto requiera un mayor esfuerzo por parte del equipo de desarrollo. Shneiderman [9], ha formulado tres (3) principios generales para la usabilidad del software, los cuales son: • Consistencia: un software consistente usa los mismos términos y procedimientos para

realizar la misma funcionabilidad a través del programa. • Control: los usuarios desean tener el control. Ellos desean que el software los ayude

pero que no les quite su sentido del control, de tal manera que puedan hacer lo que desean, cuando lo requieran y no ser obligados por el software.

• Fiabilidad: el software que es consistente y controlable es también fiable. Los usuarios conocen que si un conjunto particular de comando trabajó en una ocasión este trabajaría en otra similar. Su confianza y sus habilidades aumentan con la experiencia. Preece [4], recomienda tres (3) elementos que resultan centrales al éxito de la

usabilidad en una comunidad virtual, a saber: accesibilidad, navegación, diseño de la información.


543

4 Sociabilidad en las comunidades virtuales

La sociabilidad es una cualidad que se encuentra naturalmente asociada al aspecto social de la comunicación e interacción entre personas y a la cohesión colectiva. La sociabilidad es vista como una característica en la calidad de una comunidad virtual y se encuentra íntimamente entrelazada a la usabilidad del software. Para Preece [6], la sociabilidad de un entorno virtual facilita que sus integrantes hagan el mejor uso de las herramientas tecnológicas convirtiendo así la comunidad virtual en un espacio eficiente para el intercambio y a la vez efectivo en la generación de nuevos conocimientos de forma colectiva.

La sociabilidad se refiere a aquellos elementos que influencian la interacción social entre los integrantes de una comunidad virtual, aspectos tales como las metas, los propósitos colectivos y los roles que cada individuo asume en la comunidad virtual son algunas de las características de la sociabilidad. Por esto es importante que los asociados o colaboradores de la comunidad, tengan claras las metas de la comunidad así como lo que esperan de todos sus integrantes. En afinidad, cada integrante tiene un propósito en particular pero que junto a los demás hacen sinergia en un interés común, el de socializar y compartir bien sean experiencias, prácticas o conocimientos con otras personas.

Las comunidades con buena sociabilidad tienen políticas sociales que soportan el propósito de la comunidad siendo entendibles, socialmente aceptables y realizables [6]. El éxito de una comunidad online es confortado por la combinación de software bien diseñado y políticas sociales cuidadosamente concebidas. Bajo esta concepción Preece [6], establece una guía de diseño para sociabilidad agrupada en tres categorías: registro, confianza, seguridad y gobierno.

Según Preece [6], las comunidades con buena sociabilidad tienen políticas sociales que respaldan su propósito y son comprensibles, socialmente aceptables y factibles. Para llevar a cabo este propósito, son necesarias las investigaciones transdisciplinarias que estudian temas que incluyen: comunidad y cultura: para comprender mejor las diferentes culturas, soportar la diversidad online y entender las diferencias entre las comunidades; asuntos éticos: desarrollo de códigos de conducta online; y acceso universal: a todos los individuos que deseen interactuar y participar en las actividades que dan vida en un espacio común.

5. Futuras investigaciones

Dentro de los tópicos que son relevantes para el tema de comunidades asociados a la sociabilidad y usabilidad, se tienen: técnicas para mostrar y soportar interacción social; desarrollo de frameworks de calidad soportados en la sociabilidad y usabilidad para la construcción de comunidades virtuales; desarrollo de métodos, técnicas y medidas para determinar el éxito de la comunidad virtual; escalabilidad, la cual incluye tomar en cuenta la usabilidad y sociabilidad universal en comunidades con numerosos miembros asociados


544

y por consiguiente con gran cantidad de transacciones que afectan el performance; Y crear procesos de desarrollo que tomen en cuenta la sociabilidad y la usabilidad en la etapas tempranas del ciclo de vida del software.

6. Conclusiones

La comunidad virtuales tienen como propósito apoyar la dinámica de interacción y socialización entre sus miembros, para garantizarlo, su diseño debe estar centrado hacia dos componentes esenciales como lo son la usabilidad y la sociabilidad, en esta investigación se establece un framework para el diseño de comunidades virtuales centrada hacia estas cualidades, el mismo esta integrado por los siguientes componentes: metamodelo de calidad, calidad (usabilidad, sociabilidad), análisis (Pruebas, Interpretación, Mejoras) y un componente comunidad, descrito ampliamente a través del modelo de comunidades, con lo cual se proporciona una visión de cómo debe estar conformada una comunidad virtual. Por otro lado se puede establecer que el éxito de una comunidad virtual está muy ligado a la usabilidad, aunque no sea fácil medirla debido a la inexistencia de un método único. Sin embargo, se puede afirmar que un sitio con buena usabilidad, posee lo que se necesita para garantizar la interacción entre sus miembros y por ende la sociabilidad, factor indispensable para considerar a una comunidad exitosa. En cuanto a la sociabilidad es importante investigar nuevos métodos, modelos y pruebas para medirla y evaluar de manera confiable, con lo cual se abre una nueva línea para futuras investigaciones.

Referencias

1. Figallo, C. 1998. Hosting Web Communities. John Wiley & Sons. New York. 2. Hagel, J. y Armstrong, A. 1997. Net.gain: expanding markets through virtual

communities. Harvard Business School Press. Boston, USA. 3. Nielsen, J. 1993. Usability engineering. Boston, AP Professional. Chapter 5. 4. Preece, J. y Sieckenius, C. 2003. A Framework for analizing and understanding online

Communities. University of Maryland Baltimore County. 5. Preece, J. y Diane, M. 2003. Online Communities Focusing on sociability and

usability. University of Maryland Baltimore County. 6. Preece, J. 2001. Online communities: Usability, sociabilty, theory and methods.

University of Maryland Baltimore County. 7. Powers, M. 1997. How to program a virtual community. Ziff-Davis Press. New York. 8. Rheingold, H. 1993. The virtual community. Addison-Wesley. Reading, USA. 9. Shneiderman B (1998) Designing the User Interface, Addison-Wesley.


545

Herramienta para la Evaluación de Proyectos de Outsourcing de TI basada en Factores Críticos de Éxito

Edumilis Mendez1, María Pérez1 , Luis E. Mendoza1

1 Departamento de Procesos y Sistemas, Edificio de Matemáticas y Sistemas, Laboratorio de Investigación en Sistemas de Información (LISI),

Universidad Simón Bolívar, Apartado 89000, Baruta, Caracas, 1080-A, Venezuela {emendez, movalles, lmendoza}@usb.ve

Resumen. Actualmente muchas empresas delegan sus funciones no-crossfuncional a terceros con la finalidad de reducir costos, aumentar la productividad, expandir sus horizontes y aumentar su capacidad competitiva. Debido a los constantes avances tecnológicos, esta realidad ocurre cada vez con mayor frecuencia en el área de las Tecnologías de Información (TI). Sin embargo, la gerencia de este tipo de relación no es una tarea fácil. El éxito de la relación contractual y de los proyectos que esta engloba se ven impactados por una serie de factores críticos que favorecen los beneficios del Outsourcing para las organizaciones. Este artículo tiene por objetivo presentar una herramienta para el procesamiento de los Factores Críticos de Éxito (FCE) para Outsourcing de TI (OTI), identificados a través de un modelo, con la finalidad de soportar la evaluación de los proyectos y brindar orientaciones al cliente y al proveedor del servicio.

Palabras clave: Outsourcing de TI, Herramienta, Factores Críticos de Éxito, Proyecto.

1 Introduction

Según [1, 2, 3, 4, 5, 6] se puede decir que el Outsourcing de Tecnologías de Información (OTI) es la relación contractual entre un cliente y su proveedor de servicios, donde éste toma la responsabilidad total o parcial del área de las TI a la que fue contratado, aprovechando el conocimiento, experticia, experiencia y creatividad con la que cuenta este proveedor, para brindar un servicio de alta calidad a sus clientes y satisfacer sus expectativas. En los últimos años se ha presentado la posibilidad real de que el OTI pueda superar la resistencia y la duda presente en los clientes, y de esta manera pueda convertirse en una forma normal para la gestión de las TI [7]. Sin embargo, el auge que ha tenido el OTI y a la ausencia actual de orientaciones claras y tangibles en proyectos de este tipo a motivado a los autores a identificar una serie de Factores Críticos de Éxito (FCE). En [7] proponen un modelo basado en FCE para OTI, mediante el cual, utilizando


546

la relevancia de los FCE en el alcance de los objetivos, orienta a las empresas para que afiancen sus fortalezas y superen las debilidades.

En este sentido, este artículo tiene por objetivo presentar una herramienta para el procesamiento de los FCE para OTI, identificados en el modelo propuesto por [7], con la finalidad de soportar la evaluación de los proyectos y brindar orientaciones al cliente y al proveedor del servicio.

Con la finalidad de mostrar los aportes de este trabajo se siguió la siguiente estructura: inicialmente se aborda el modelo de FCE para OTI propuesto por [7], el cual ofrece los lineamientos para evaluar a los proyectos de OTI y que se automatiza a través de la Herramienta que se propone en la sección 3. Por último, se muestran las conclusiones.

2 Modelo de Factores Críticos de Éxito para OTI

Como se puede observar en la Tabla 1 el modelo de FCE para OTI propuesto por [7] está constituido por tres categorías: Gestión, Relación Cliente-Proveedor y Técnico/Tecnológico, las cuales se encuentran dividas a su vez en sub-categorías: Contrato, Operacional, Personal y Estratégico para Gestión; y Colaboración, Comunicación, Compromiso y Confianza para Relación Cliente-Proveedor. Esto representa un total de 29 FCE y 69 métricas.

Tabla 1. Modelo de FCE propuesto, Categorías y subcategorías [7].

Categoría: Gestión Subcategoría: Estratégica 1. Enfoque Estratégico 2. Relaciones a largo Plazo 3. Outsourcing como valor intelectual 4. Separar las metas y objetivos a corto y a largo plazo 5. Establecimiento en conjunto de la dirección del negocio

Subcategoría: Personal 6. Concentrarse en el empleado 7. Manejar la resistencia al cambio y promoción de la idea

de Outsourcing 8. Promover el trabajo en equipo

Subcategoría: Operacional 9. Control de la Gerencia 10. Rendimiento en la entrega 11. Gerencia de Costos 12. Creación y uso de mejoras prácticas

Subcategoría: Contrato 13. Control eficiente del contrato 14. Puntos claros entre el cliente y el proveedor 15. Flexibilidad 16. Uso de SLA (Niveles de Acuerdos de Servicio)

Categoría: Relación Cliente - Proveedor Subcategoría: Compromiso 17. Compartir el conocimiento eficientemente 18. Colaboración entre las organizaciones

Subcategoría: Comunicación 19. Entendimiento entre ambas organizaciones 20. Mantener unas líneas activas de comunicación

Subcategoría: Colaboración 21. Relación, más como matrimonio que como contrato 22. Individuos profesionales 23. Formular penas e incentivos 24. Unión de ambas gerencias en el apoyo del proyecto 25. Fuerte inversión de tiempo y esfuerzo 26. Compartir el riesgo

Subcategoría: Confianza 27. Confianza entre ambas partes

Categoría: Técnico-Tecnológico 28. Experticia y conocimientos técnicos

29. Mantener una alta capacidad innovadora en cuanto al servicio y las ventajas tecnológicas


547

Para más detalles del modelo, consultar el artículo "Critical Success Factors as a Strategy for Risk Mitigation in IT Outsourcing Projects" [7]. En la próxima sección se muestra el diseño e implementación de la herramienta propuesta.

3 Herramienta propuesta para la evaluación de proyectos de OTI

A partir del modelo basado en FCE para OTI mencionado en la sección anterior, el cual define un conjunto de métricas y sus criterios de aceptación y conformidad, se procedió a desarrollar una herramienta Web que permite al proveedor de servicio conocer el estado de sus proyectos de Outsourcing de TI de una forma clara, sencilla, eficiente y precisa. La finalidad de la herramienta es el procesamiento de la información y formular las orientaciones a partir de la misma.

3.1. Arquitectura de la herramienta

La herramienta fue desarrollada mediante el paradigma de programación orientada a objetos. El diseño está basado en una arquitectura de 3 capas, las cuales se describen a continuación y se muestran a través de la Fig. 1.

Fig. 1. Arquitectura de la herramienta.

• Capa I: Acceso a la Datos o Persistencia En esta capa se realizan todas las acciones que tienen que ver con el acceso a los

datos y su persistencia. Aquí se manejan todas las conexiones y consultas que permiten procesar la data necesaria. Como fuente se encuentra la Base de datos (SQL Server 2000).


548

• Capa II: Lógica o Reglas del Negocio: En esta capa se tienen objetos que realizan el procesamiento de los datos y es donde

se implementan las validaciones y lógica correspondiente a cada objeto presente en la herramienta. En la Fig. 2 se muestra el Diagrama de clases, el cual soporta la vista lógica de la aplicación o herramienta. En esta se puede observar que un proyecto puede estar asociado a varias evaluaciones, y cada evaluación cuenta con 1 o más evaluadores.

Fig. 2. Diagrama de clases.

• Capa III: Presentación o Interfaz de Usuario (UI): En esta capa se crearon un conjunto de ASP.NET Server Controls, ASP.NET User

Control para reutilizar elementos de UI y garantizar la consistencia de la interfaz a lo largo de la herramienta, brindando así una experiencia amigable al usuario de la herramienta. A su vez, esta capa utiliza los Microsoft Office Web Components para poder brindarle al usuario gráficas que muestren de una manera visual, los resultados y comparaciones de las evaluaciones.

3.2 Especificaciones Técnicas

La herramienta se desarrolló bajo Windows Server 2003, con la plataforma .NET v1.1, utilizando el lenguaje C#, el ambiente ASP.NET para la integración Web, y el manejador de base de datos que se empleó fue SQL Server 2000. Para la generación de las gráficas,


549

se utilizó los Office Web Components v11, para .NET. La herramienta posee capacidad para exportar tablas e información en formatos de Microsoft Word y Microsoft Excel con la finalidad de facilitarle al usuario el transporte de información. A continuación se indican las especificaciones a nivel de interfaz.

3. 3. Especificaciones de Interfaz

En esta sección se describen algunas de las características que posee la herramienta, para esto muestran algunas de las pantallas más importantes para la formulación de Orientaciones en los proyectos de Outsourcing de TI.

3.3.1 Especificaciones Administrativas

La aplicación está orientada a controlar los proyectos en los que se encuentra involucrada una empresa en particular, independientemente si su rol es el de cliente o el de proveedor de servicios, ambos ambientes se previeron en el desarrollo de la herramienta. La herramienta permite la creación y administración de los usuarios de la misma, proporcionando para cada uno, además de los datos básicos, un usuario y clave para el ingreso a la herramienta. Una vez que el usuario ingresa a la aplicación puede acceder a administrar y conocer el estado de los proyectos en los que está involucrada la empresa, por lo que en la siguiente sección se describe como es la administración de los proyectos.

3.3.2 Administración de Proyectos

Los usuarios de la herramienta pueden monitorear el estado de los proyectos de Outsourcing en los que esta involucrados la empresa; en la Fig. 3 se presenta la pantalla en donde el Administrador puede observar el detalle de algún proyecto en específico y las evaluaciones asociadas con el mismo. Como se puede apreciar en la parte inferior y en el diagrama de clases que se diseñó para la misma, un proyecto puede estar asociado a varias evaluaciones, y cada evaluación cuenta con uno o más evaluadores.

3.3.3. Administración de Evaluaciones

Las evaluaciones conforman la base para poder obtener las orientaciones y conocer el estado de un proyecto en las distintas categorías definidas para los FCE. Para cada evaluación se deben ingresar las personas a las cuales se les va a aplicar el instrumento de evaluación. Una vez que el evaluador es asociado con la evaluación, la herramienta le envía un e-mail con el link para el acceso al cuestionario correspondiente según su perfil: cliente o proveedor.


550

Fig. 3. Datos básicos del proyecto.

Cuando los evaluadores finalizan su cuestionario, la aplicación habilita un botón para ver los resultados obtenidos en el proyecto de OTI. Estos resultados estarán representados por una puntuación que se encuentra en porcentaje, por lo que 0% es la mínima puntuación y 100% es la máxima. Con esta puntuación, y de acuerdo con los criterios de aceptación y/o conformidad para los FCE del modelo, se indica en qué nivel se encuentra cada uno de los FCE en el proyecto de Outsourcing que se está realizando el estudio.

Una vez obtenido los resultados de la evaluación del proyecto de OTI, la empresa debe atacar aquellos FCE cuyo nivel de aceptación no fue satisfactorio, mantener el rendimiento en las áreas en las que la evaluación si fue satisfactorio, y poner atención en los factores en los cuales la evaluación los colocó como aceptables.

La herramienta además tiene la funcionalidad de poder comparar evaluaciones realizadas a un proyecto y de esta forma conocer con certeza si en verdad el proyecto está mejorando y cómo ha sido la evolución del mismo. En la Fig. 4 se muestra la comparación entre dos evaluaciones de un proyecto de Outsourcing. Es recomendable realizar evaluaciones periódicas a los proyectos con la finalidad de poder analizar cómo es el desarrollo y evolución del mismo.

Conclusiones

En este artículo se presentó una herramienta para el procesamiento de los FCE para OTI, identificados a través de un modelo, con la finalidad de soportar la evaluación de los proyectos y brindar orientaciones al cliente y al proveedor del servicio. Esta herramienta permite hacer un control y seguimiento de estos facilitando la gestión de los mismos, orientando a los gerentes y líderes de proyectos de la organización cliente y/o proveedor cuáles son los FCE que deben mejorar y cuáles hay que tenerles mayor cuidado dependiendo de los resultados obtenidos.


551

Fig. 4. Comparación entre evaluaciones en un proyecto de OTI.

Agradecimientos. Esta investigación fue financiada por la USB, Venezuela, a través del proyecto DID-CAI-014-05.

Referencias

1. Domberger, S. The Contracting Organization: A Strategic Guide to Outsourcing. Oxford: Oxford University Press (1998)

2. Grover, V., Cheon, M. J. y Teng, J.T.C. (1996) The Effect of Service Quality and Partnership on The Outsourcing of Information Systems Functions, Journal of Management Information System, 12(4) (1996) 89-116.

3. Kraker, F. The Truth About Outsourcing, Brian Roberty and Ian Robertson, Gower, Aldershot and Brookfield, VT. (1995)

4. Ketler K. and Willems J. A study of the Outsourcing Decision: Preliminary Results in Proceeding of SIGCPR 99,New Orleans, USA, ACM (1999), 182-189.

5. Kilby, G. Duesburys, Unisys U3 Conference (1993) 6. Lee, J., Huynh, MW, Chi-wai, KR y Pi, S. The evolution of Outsourcing Research: ¿What is

the next Issue? Proceedings of the 33rd Hawaii International Conference on System Sciences (2000)

7. Méndez, Edumilis; Mendoza, L; Pérez, M. "Critical Success Factors as a Strategy for Risk Mitigation in IT Outsourcing Projects". Twelfth Americas Conference on Information Systems - AMCIS 2006. México. Agosto (2006) 3268 – 3280.


552

Simulando Dinámicas de Integración Regional

Sary Levy-Carciente1,2, Tirso Palm1,3, María de la Fé López4

1Universidad Central de Venezuela (UCV)

2Instituto de Investigaciones Económicas y Sociales “Rodolfo Quintero”, FaCES-UCV 3Centro de Estudios del Desarrollo (CENDES-UCV)

4Universidad Simón Bolívar (USB) [email protected], [email protected], mlopez@usbve

Resumen: Con el afán de apoyar la toma de decisiones de los hacedores de política, el trabajo plantea elementos a considerar en un modelo de simulación a partir de la perspectiva de la dinámica de sistemas, que permita evidenciar los canales económicos, políticos y sociales de relación entre naciones que participan o se aproximan a procesos de integración regional. Nuestra perspectiva se inspira en la reciente adhesión de Venezuela al MERCOSUR

1 Introducción

La relación que una economía establece con terceros puede verse a partir de distintas aristas, como son: el comercio de bienes y servicios, el flujo de capitales, el movimiento de mano de obra y la relación cambiaria; todas ellas claramente imbricadas. De igual manera, esta relación con terceros puede verse afectada o desdibujada (positiva o negativamente) a partir del entorno institucional en el que se desenvuelve, siendo los procesos de globalización e integración los de más evidente impacto en el presente y pasado reciente.

Los sucesos recientes en Sudamérica han evidenciado importantes sismos en los esquemas de vinculación entre las naciones de la región, con impacto en los procesos de integración que se venían adelantando, sumándose a la compleja red de relaciones internacionales de la región, cruzada por intereses económicos, motivaciones político-ideológicas y características socio-culturales.

En este dinámico y multidimensional espacio de relaciones internacionales, los hacedores de política han de dar respuesta a sus nacionales desde diversos ángulos y los inesperados cambios de rumbo de determinadas políticas o estrategias, pero no cuentan con suficiente holgura temporal que les permita con antelación preparase para evaluar los costos y beneficios de las nuevas dinámicas generadas, tanto en el corto como en el largo plazo.

De lo anterior emerge la importancia de revisar el estado de integración alcanzado por la región para evaluar sus logros, dificultades y extraer enseñanzas que guíen a los


553

hacedores de políticas públicas y a los dirigentes de la región en los difíciles avatares que suponen estos acuerdos. Asimismo, el desarrollo de una herramienta que parta de un análisis sistémico resulta relevante para los hacedores de política. La misma, sin pretender proyectar el futuro, les permitiría moverse en diversos escenarios y evaluar las alternativas de políticas ex – ante, una especie de laboratorio controlado, donde se puedan evidenciar los riesgos a los que se someten las naciones y sus distintos sectores a partir de políticas específicas. De igual manera, permitiría identificar aquellas acciones a potenciar o profundizar, dada la posibilidad de beneficio o externalidades positivas capaces de favorecer.

Con el afán de aportar a lo señalado previamente, el trabajo desarrolla un modelo de simulación teórico desarrollado a partir de la perspectiva de dinámica de sistemas, evidenciando los agentes participantes en un acuerdo de integración regional en el que se presenta el intercambio. Dicho modelo pretende tener aplicabilidad especial a los países integrantes del MERCOSUR, mostrando las redes de relación y las dinámicas que de dicho sistema emergen.

2 Dinámica de Sistemas en Ciencias Sociales

La dinámica de sistemas (DS), conforma una metodología de uso generalizado para modelar y estudiar el comportamiento de cualquier clase de sistema y su evolución a lo largo del tiempo. La construcción de modelos por DS parte de la distinción esencial entre dos tipos de variables: de nivel y de flujo; cuyos elementos edifican modelos que describen sistemas internamente conectados por relaciones uni, multi o bi- direccionales. Algo que distingue a la DS de otras aproximaciones al estudio de los mismos problemas, es el uso de bucles de realimentación los cuales muestran el carácter no lineal que suele estar presente en los problemas del mundo real [1].

Dentro de las ventajas de la DS destaca la facilidad que ofrece para la comprensión de situaciones complejas, permitiendo identificar las variables claves y las sensibles. Asimismo, permite analizar múltiples alternativas y comparar resultados, favoreciendo la escogencia de la óptima. De lo anterior deriva que la DS se conforma en una herramienta muy potente que permite observar las causas estructurales que provocan el comportamiento del sistema a partir de modelos de simulación de gestión. Asimismo, favorece el estudio del comportamiento de los escenarios donde interactúan diversos actores a partir de la determinación de ciertas variables, que resultan en aproximaciones de las políticas gubernamentales, decisiones de diferentes entes, cambios en las estructuras, y/o demoras o rezagos en el tiempo y cuya interacción afecta el comportamiento y la estabilidad de los países.

La resolución de un problema a través de un proyecto de DS exige los siguientes pasos [2]: a) adecuada identificación y definición del problema, b) conceptualización del sistema (elementos e influencias) y desarrollo de una hipótesis dinámica que


554

explique la(s) causa(s) del problema, c) construcción de un modelo que pueda ser simulado con computadores, d) prueba del funcionamiento del modelo, e) desarrollo y validación en el modelo de políticas alternativas que alivien o mejoren el problema, y f) implementación de las soluciones

La razón más importante que favorece la utilización de esta herramienta en ciencias sociales es su capacidad para construir modelos simples, focalizados en ámbitos específicos de la realidad y descubrir las consecuencias de la aplicación de determinadas políticas, las cuales se fundamentan en teorías socio-económicas, pero aplicadas a sociedades artificiales. Los procesos de formalización o de creación de modelos formales se basan en técnicas de optimización, métodos estadísticos o en base a modelos causales, basados en la Teoría General de Sistemas, utilizando la DS como herramienta de análisis, y deben referir con precisión el significado de las teorías [3].

3 Un Modelo

Se diseñó un modelo de tres actores, cuatro sectores productivos y dos factores de producción (capital y trabajo), que se desempeñan en economías abiertas en competencia perfecta y donde la participación en un acuerdo de integración regional resulta en una reducción de costos, favoreciendo el intercambio entre las partes. Por su parte, la economía de forma doméstica recoge este aspecto como una señal positiva a la producción, que permite el crecimiento y genera externalidades positivas.

a. Software Se diseñó un modelo de simulación de DS utilizando el programa VENSIM,07® el

cual se caracteriza por ser una herramienta de modelización que permite conceptualizar, documentar, simular, analizar y optimizar estos modelos. VENSIM,07® provee una forma simple y flexible de construir modelos de simulación, por lazos causales y/o diagramas de niveles y flujos. La escogencia de este software se debió a que este programa permite explorar el comportamiento del modelo diseñado, elemento central en nuestro objetivo.

b. Actores El modelo de simulación fue concebido a partir de tres actores claves: • El país que intenta ingresar al acuerdo de integración regional, PAIS • El bloque ya conformado de integración regional, ARI • El resto del mundo, ROW En cada actor existe un proceso de generación productiva que se destina,

eventualmente, al intercambio internacional. c. Sectores productivos El modelo concibe la existencia de cuatro sectores productivos (Si, con i: 1→4):

Sector Energético, S1; Sector Agropecuario, S2; Sector Manufactura, S3; Sector Servicio, S4.


555

d. Dinámicas entre actores Se simula una dinámica de intercambio de N sectores productivos, los cuales

interactúan creando vínculos y relaciones de dependencia que explican la operacionalidad del intercambio comercial en el mercado internacional, evidenciando la red de relaciones entre: ARI-PAIS, PAIS-ROW, ARI-ROW (ver Fig.1, Fig.2)

Fig. 1.Perspectiva del Modelo

e. Relación entre dos actores: e.1 ARI-ROW: Una lectura desde el ARI nos permite explicar el intercambio comercial hacia

ROW de siguiente manera: ARI demanda importaciones de ROW del sector productivo Si (MdSi-ARI-ROW)

a una tasa de importación, tMSi-ARI-ROW, esta tasa de importaciones estará influenciada por la producción de dicho sector, tPsi-ROW.

Fig. 2. Proceso de Negociación entre actores (PAIS-ARI-ROW)

ROW

ARI

PAIS

Negociación entrebloquesExperiencia sobre

costos de producción

Precios y atractivo para laexportación / importación

Factores demercado

PAIS (SectoresEconómicos)

Zona de IntercambioComercial

Resto del Mundo

Acuerdo Regional deIntegración

Perpectiva deadhesión al ARI


556

Por su parte, MdSi-ARI-ROW es equivalente a XoSi-ROW-ARI, que es la oferta de exportaciones que ofrece ROW a ARI del sector productivo en cuestión. Este nivel de exportaciones dependerá de los costos de producción (CSi-ROW), del precio al cual ROW ofrece su producto (pSi-row) y de los impuestos que ARI aplica a las importaciones provenientes de ROW, (ArancelSi-ARI-ROW).

Tales variables serán fundamentales para determinar el atractivo que dichos productos resulten para el bloque (AtractivoSi-ARI-ROW), y en función del atractivo el bloque decidirá si resulta más beneficioso comprar a ROW o adquirir el producto dentro generado por ARI. Se identifican dos factores que inciden sobre el atractivo de dicho producto proveniente del resto del mundo que son: el factor servicio ROW (Servicio-ROW) y la sensibilidad de los operadores (Sensibilidad-ARI-ROW) que mide los cambios del producto y cómo influyen sobre los operadores del mercado. Estos nos permite identificar la proporción de mercado que el ARI representa para ROW (Mket%ARI- ROW).

e.2. ARI-PAIS y ROW-PAIS Las relaciones ARI-PAIS y ROW-PAIS, fueron diseñadas de forma análoga a las

de ARI-ROW, de donde la explicación anterior cabe para ellas. f. Relaciones internas a los actores: f.1. Intra-PAIS Esta relación muestra la dinámica de la generación de la producción (PoSi-PAIS) y

su realización interna en PAIS a partir del consumo privado (CprivSi-PAIS) y el consumo público (CpubSi-PAIS) de los distintos sectores productivos, que definen su consumo total (CtotalSi-ARI) y éste se realiza a una tasa dada, tCdSi-ARI (Ver Fig. 3). El nivel de producción requiere de una inversión IiSi-PAIS para cada sector, la cual se depreciará considerando el promedio de vida útil del capital (KvidaSi). La inversión estará condicionada por el nivel de interés en el mercado aplicable para el sector (rSi). La concreción de la inversión potenciará el nivel de empleo (NSi) y a su vez impactará el salario nominal (w), el cual presionará el consumo. El nivel de empleo depende a su vez de las características de la fuerza laboral (Labor), la cual tiene cierto nivel de crecimiento (CrecLabor) y una estructura de la pirámide poblacional que define el nivel de población económicamente activa.

Consumo

IngresoLabor

ProducciónDeseada

Producción

Tecnología

Inversión Deperesiación

Exportacionesnetas Gasto Publico

(M) (X)

Fig. 3. Modelo PAIS. Sector Económico: Relaciones básicas


557

La producción generada se contrasta con la deseada por la demanda y de ahí se extraen las necesidades de vinculación hacia fuera de la economía de PAIS. Aquella parte de la producción que no se realiza internamente se exporta, sea a ROW o a ARI (siguiendo la explicación del punto e). Por su parte la demanda interna no cubierta por la producción interna será satisfecha a partir de las importaciones que se hagan a ROW o de ARI. La relación de PAIS con ARI tiene como elemento que modifica la dinámica de competencia perfecta el atractivo que el bloque le ofrece ventajas arancelarias incrementando el atractivo del comercio con ARI representado por el (Mket%ARI).

f.2 Intra-ARI e Intra- ROW Para este ejercicio las dinámicas internas en ARI y ROW no se explicitaron, ya que

fueron considerados como actores equivalentes a PAIS sin identificación de sus componentes internos.

g. Factores Técnicos g.1 Madurez tecnológica Con la finalidad de identificar el ciclo de vida de una tecnología dada utilizada en el

proceso productivo de un sector específico, se generó un factor que denominamos MadurezTecnologica que nos permite identificar la eficiencia marginal de la inversión. Esta variable se mueve entre [0,1], identificando la posibilidad de adopción de nuevas tecnologías a partir de 0.5.

G2. Experiencia Acumulada En la medida que los actores participan de una acción generan un proceso de

aprendizaje cuya curva permite una mayor eficiencia en su rendimiento. Para recoger este aspecto se generó un factor que denominamos Experiencia, el cual actúa como un factor que reduce los costos productivos.

4 Algunos Resultados

Al correr el modelo se pudo observar la dinámica de la relación que se genera entre los agentes y entre las variables identificadas para cada uno de ellos: • Se evidenciaron los comportamientos vinculados de los distintos árboles de relación

entre las variables. • El modelo manifestó una alta sensibilidad a las condiciones iniciales, las cuales

modificaban las dinámicas de comportamiento de forma importante. Para la evaluación de los comportamientos se simularon los siguientes escenarios:

• Escenario 1: PAIS sólo ofrecía un producto (S1) a ARI y a ROW, comercio que compensaba incrementando las importaciones de todos los restantes sectores productivos. En dicho escenario S1 es intensivo en capital, S2 intensivo en trabajo y S3 y S4 se simularon como de intensividad compartida en ambos factores. Este escenario manifestaba un comercio compensado a nivel macroeconómico pero


558

desmejoras en las condiciones del mercado laboral en PAIS. Asimismo manifestaba estabilidad en variables como inflación y tasa de interés.

• Escenario 2: PAIS sólo ofrecía un producto (S1) a ARI y a ROW, pero lograba a cambio ventajas políticas a nivel internacional (variable que denominamos Geopolítica). Estas ventajas políticas fueron consideradas como ventajas en órdenes no económicos, pero que se traducían en ventajas en la variable Sensibilidad de PAIS. En este escenario comparado con el Escenario 1 el impacto negativo en el sector laboral era menor, pero dependía del peso que se le diese a la variable Sensibilidad.

• Escenario 3: PAIS sólo ofrecía un producto (S1) a ARI y ROW, pero ARI no deseaba adquirirlo de PAIS. En este caso el deterioro económico se incrementaba en PAIS, mientras que ARI lograba mejoras sustanciales económicas medidas a partir de un incremento de la producción, incremento de exportaciones

• Escenario 4: PAIS sólo ofrecía un producto (S1) a ARI y a ROW y lograba que el todas las importaciones de ARI de dicho producto fuesen de PAIS. En este caso se simuló la necesidad de existencias de S1 para la producción de S2, S3 y S4. En este caso, la producción de ARI dependía de PAIS y la variable Geopolítica impactaba en mayor medida las ventajas logradas por PAIS. De esta manera el comportamiento era similar a los generados en el Escenario 2 pero aún mejores para PAIS.

5 Conclusiones

La importancia que adquieren los procesos de integración regional en el presente y la vertiginosidad con la cual los hacedores han de tomar decisiones para evaluar los costos y beneficios – sociopolíticos y económicos, a corto y a largo plazo – exige generar herramientas que faciliten dichas acciones.

El trabajo muestra las ventajas potenciales de una herramienta de simulación por dinámica de sistema para lo señalado con anterioridad. En este sentido una adecuación de este modelo a casos específicos nos podría identificar dinámicas de distintos procesos de integración. Específicamente, los comportamientos generados en los escenarios simulados bien podrían ser considerados como aproximaciones iniciales a las dinámicas económicas que pudieran generarse ante la adhesión de Venezuela al MERCOSUR Referencias 1. Lagarda, L.E.A., Modelos mentales y formales con dinámica de sistemas (2001) www.itson.mx/dii/elagarda/apagina2001/Dinamica/pdf/caso-b.pdf. 2. Aracil, J., Introducción a la Dinámica de Sistemas. Ed. Alianza Universidad, Madrid. (1979) 3. Gilbert, N. y Troitzsch, K.G., Simulation for the Social Scientist. 2da. edn. Open University

Press, Buckingham Philadelphia (2005)


559

HYPERQBIX: Sistema de Indicadores de Gestión de Calidad para DBAccess STP (Software Technology Park), C.A.

Gladys Benigni1 y María González1

1 Coordinación Programa Licenciatura en Informática.

Universidad de Oriente – Núcleo Nueva Esparta. Venezuela [email protected]

Resumen. La empresa de desarrollo de software DBAccess STP, C.A, trabaja con Indicadores de Gestión de Calidad que están íntimamente relacionados con los objetivos de calidad de la empresa. El propósito de este proyecto es analizar, diseñar, construir e implementar un Sistema de Indicadores de Gestión de Calidad que apoye la toma de decisiones de una manera rápida y eficiente. Para la realización de este sistema se utilizaron teorías de Inteligencia de Negocios (Business Intelligence) que permitieron migrar los datos desde la base de datos corporativa hasta una base de datos multidimensional para permitir a los usuarios finales a través de una interfaz web, visualizar de una manera multidimensional por medio de un Cubo OLAP las diferentes perspectivas del negocio de cada indicador de gestión.

Palabras clave: Sistema de Indicadores de Gestión, Inteligencia de Negocios, Data Warehouse, Data mart, Metodología DBAccess, CMMI, UML.

1 Introducción

DBAccess es una empresa venezolana de consultoría para el desarrollo de software fundada en 1988; “su sede principal está ubicada en Caracas, Venezuela y el centro global de desarrollo de software está localizado en la ciudad de Mérida. Cuenta, además, con oficinas en Chicago, Estados Unidos de América y Lima, Perú” [2]. La compañía DBAccess “optó por un enfoque matricial, contando así con una estructura funcional y una de proyectos” [4]. Dentro de la estructura funcional se encuentra la Dirección de Calidad que entre sus características se destaca la de velar por el mantenimiento de la ruta de calidad de la empresa, a través de procesos de mejora, entre los cuales se encuentra el de Métricas e Indicadores de DBAccess en la categoría de soporte, con el fin de implantar un mecanismo de recogida de datos, almacenamiento y


560

análisis de los mismos de forma que las decisiones que se tomen puedan estar basadas en estos datos [5]. Cada objetivo de calidad está asociado a una Dirección y es medible a través de un indicador de gestión que responde a dos principios básicos: “lo que no es medible no es gerenciable” y “el control se ejerce a partir de hechos y datos” [1]. La recolección de los datos para determinar estos indicadores se realiza usando una hoja de cálculo Excel, que maneja cada Dirección de DBAccess para el control de sus indicadores. Los procesos de recolección para el Indicador de Satisfacción del Cliente se realizan una vez que el cliente posee una cuenta dentro de DBAccess, para que acceda a un cuestionario que mide el grado de satisfacción del servicio. Una vez que el cliente ha contestado la encuesta, envía la misma a través de Internet y llega al buzón de correo corporativo de DBAccess de los Gerentes de Cuenta y del Director de Mercadeo, es éste último el encargado de vaciar los datos en una hoja de cálculo Excel, donde las columnas representan las preguntas y las filas a los clientes, y cada celda indica la puntuación obtenida en esa pregunta por ese cliente. En esta hoja de cálculo también se refleja la puntuación de cada encuesta por cliente y el índice global de satisfacción del cliente. Una vez finalizado cada mes, cada Director procede a enviar por correo electrónico las hojas de cálculo, a la Dirección de Calidad, la cual es la encargada de extraer el dato arrojado para cada indicador y realizar las gráficas comparativas con el valor esperado para ese trimestre y con los trimestres anteriores denominados: Q1, Q2, Q3, Q4 por su nomenclatura en Inglés “Quarter”. La Junta Directiva de DBAccess en pleno se reúne trimestralmente para analizar los valores obtenidos en los indicadores de gestión. Para el cuarto trimestre (Q4) la empresa migró a un nuevo modelo de negocio que se basa en la conformación y consolidación de Centros de Desarrollo de Software (CDS) para los clientes. Además se trata de un innovador modelo de organización que potencia la capacidad emprendedora, la asociatividad y la innovación en la producción y entrega de valor agregado a los clientes, a través de la prestación de servicios especializados en tecnologías de la información [3]. En vista de lo antes expuesto, se desarrolló un sistema para el cálculo y visualización de los indicadores de gestión de calidad para la empresa DBAccess que extrae los datos periódicamente desde la nueva base de datos corporativa hasta la base de datos multidimensional denominada DATAMART, con el fin de permitir visualizar la información de los indicadores multidimensionalmente (usando las bondades del Cubo OLAP) a la Junta Directiva a través de diferentes navegadores que se usan en la plataforma de la empresa, con el propósito de apoyar en el proceso de toma de decisiones gerenciales, estratégicas y administrativas en cuánto al cálculo de la remuneración variable.


561

2 Antecedentes

Actualmente, a nivel empresarial, la inteligencia de negocios representa un factor invaluable en la toma de decisiones oportunas; en tal sentido se destacan las investigaciones que seguidamente se señalan. Introducción al soporte de decisiones [9], tesis en la que se describe en qué consiste el proceso del Datawarehousing y desarrolla como caso de ejemplo una implementación pequeña de un Cubo OLAP a través del Analysis Services. Sistema de Apoyo Gerencial Universitario [7]; sistema de información para el apoyo a la toma de decisiones de la Universidad Politécnica de Madrid (UPM), cuyo objetivo principal es proveer una aplicación del tipo Inteligencia de Negocios que implica la implantación de un datawarehouse que abarque todas las áreas y departamentos de la universidad. Indicadores de gestión para las universidades venezolanas [8].El objetivo básico de la investigación es ofrecer un conjunto de indicadores de gestión que puedan suministrar información relevante en relación con procesos evaluativos a diferentes niveles organizacionales y faciliten el proceso de toma de decisiones que contribuya a una mayor eficiencia de la institución educativa. HyperQbix, a diferencia de los referenciados con anterioridad es un sistema de indicadores de gestión desarrollado bajo herramientas de inteligencia de negocios que apoya la toma de decisiones de los directivos de la empresa DBAccess; permite la carga periódica de los datos desde la base de datos corporativa hasta el data mart pasando por una base de datos intermedia a través de los procesos de extracción, transformación y carga (Extract, Transform, and load (ETL) processes); asimismo, permite mantener la data histórica y una perspectiva multidimensional de los indicadores de gestión, gracias a la creación de una base de datos multidimensional diseñada bajo el esquema estrella y construida con SQL Server 2000, denominada DATAMART, en la que se almacenan las métricas de los Indicadores de Gestión. Permite tomar mejores decisiones en línea, gracias a la futura implementación de un Cubo OLAP desarrollado con la Herramienta Microsoft Analysis Services de SQL Server 2000 para cada indicador conectado al data mart. HyperQbix a diferencia de los antecedentes señalados anteriormente no sólo administra los indicadores de gestión, sino que también implementará una solución para los altos ejecutivos de la empresa.

3 Desarrollo de HyperQBIX

Para el desarrollo de HyperQBIX se utilizó la metodología DBAccess [2], la cual se basa en un desarrollo cíclico, iterativo e incremental, gracias a la división en dos (2) capas: la capa interna y la capa externa, donde se definen un conjunto de fases (Fig. 1); permite además, controlar y dirigir la construcción de la aplicación hasta lograr su completo desarrollo y puesta en funcionamiento cumpliendo con los requerimientos de los clientes definidos en la etapa de análisis.


562

Fig. 1. Marco Metodológico de DBAccess.

3.1 Capa Interna

Está formada por las fases de: análisis de requisitos, análisis y diseño, construcción e implantación.

3.1.1 Fase I. Análisis de Requisitos En esta fase se realizó la ingeniería de requisitos, a través de cuestionarios, obteniéndose la identificación de los usuarios e involucrados, el documento de análisis, el documento de casos de uso y la elaboración del plan de proyecto.

3.1.2 Fase II. Análisis y Diseño En esta fase se efectuó la investigación acerca de las herramientas y tecnologías a utilizar para la arquitectura del sistema (Fig. 2), la elaboración del glosario del sistema y el documento de base de datos y la administración del proyecto. Se acordó utilizar tres (3) bases de datos: la corporativa, la intermedia y la base de datos DATAMART. Seguidamente, se presenta una breve descripción de cada uno de los componentes que forman la arquitectura del sistema. • Base de Datos Corporativa: De donde se extrae la información referente a los

indicadores de gestión de calidad de DBAccess, a través de los procesos de extracción, transformación y carga.

• Base de Datos Intermedia: Actúa como estructura de datos temporal para almacenar los datos provenientes de la base de datos corporativa; está formada por dos tablas que no están relacionadas entre sí; cada tabla almacena los datos provenientes de cada indicador de gestión de calidad


563

• Base de Datos Multidimensional: Llamada DATAMART en la cual se guardan los datos históricos correspondientes a los indicadores de gestión de calidad de DBAccess. Todas las bases de dato se construyeron con SQL Server 2000.

• Procesos de extracción, transformación y carga (ETL): Son los procesos responsables del transporte e integración de datos de uno o más sistemas fuentes a uno o más sistemas de destino [6]. Los procesos se desarrollaron con la herramienta Data Transformation Services de SQL Server 2000.

• Cubo OLAP: Es una estructura de datos multidimensional que representa la intersección de una combinación única de dimensiones. Para cada intersección hay una celda que contiene un valor [6]. Este Cubo OLAP fue construido con la herramienta Analysis Services para SQL Server 2000.

• Hoja de Cálculo Excel: Se utilizó la hoja de cálculo Excel por la afinidad que los usuarios finales tienen con la misma, y además desde esta se puede hacer una conexión hacia el Cubo OLAP.

• Página web HTML: Se construyó la página web (con los componentes de Office WebComponents) con el fin de colocar un enlace dentro de la Intranet Corporativa.

Fig. 2. Arquitectura del Sistema HYPERQBIX.

3.1.2.1 Modelo Estrella de la Base de Datos Multidimensional En la fase de análisis y diseño se realizaron los modelos estrellas, constituidos por las tablas de hecho y tablas de dimensiones para los indicadores de gestión de calidad de DBAccess: Satisfacción del Cliente y Porcentaje de Utilización de Planta (Fig. 3).


564

Fig. 3. Modelo estrella para el Indicador de Porcentaje de Utilización de Planta.

3.1.3 Fase III. Construcción Esta fase está representada por la construcción de los procesos ETL en Data Transformation Services y las bases de datos y el Cubo OLAP de cada indicador de gestión con SQL Server 2000 Analysis Services. Cubo de Satisfacción: Es un cubo OLAP que almacena información acerca del índice de satisfacción de un cliente de acuerdo al servicio prestado por DBAccess. Para este cubo se crea el miembro calculado Índice de Satisfacción bajo la fórmula en lenguaje MDX (Fórmula 1):

[Measures].[Valor Pregunta]/[Measures].[Cantidad].

(1)

Cubo de Utilización: es un cubo OLAP que almacena información acerca del porcentaje de utilización de planta en DBAccess. Para este cubo se crea el miembro calculado %Utilización bajo la fórmula en lenguaje MDX (Fórmula 2):

[Measures].[Hora Facturada]/[Measures].[Hora Capacidad]*100.

(2)

3.1.4 Fase IV. Implantación En esta fase se realizó la configuración, instalación del sistema, las pruebas en el ambiente de pruebas y la actualización del documento de arquitectura.

3.2 Capa Externa

En esta capa se realizaron las áreas claves del proceso enmarcadas por la gestión de requerimientos, planificación de proyectos, seguimiento y control de proyectos, aseguramiento de la calidad y gestión de configuración del software.


565

4. Conclusiones

La observación directa de los Indicadores de Gestión de Calidad de DBAccess, permitió conocer sus fórmulas, términos y la dirección encargada de su automatización. Es importante el cálculo de los Indicadores de Gestión de Calidad para los empleados y directores. La adaptación de la metodología DBAccess garantizó reducir los riesgos en etapas tempranas del proyecto y la construcción de una arquitectura del software entendible por todos los involucrados. La acertada creación de la base de datos intermedia permitió almacenar la granularidad mínima para cada indicador de gestión. La utilización de Microsoft Data Transformation Services como herramienta para la construcción de los procesos ETL entre cada base de datos permitió cargar sólo los datos realmente necesarios a la base de datos del data mart. La construcción de una base de datos multidimensional utilizando Microsoft Analysis Services, resultó beneficiosa para los usuarios finales, debido a la oportunidad de explorar las diferentes medidas y dimensiones del negocio. La creación de una interfaz web como un hipervínculo dentro de la Intranet Corporativa de DBAcces, permite el uso del sistema desde cualquier punto. La implantación del Sistema de Indicadores de Gestión de Calidad de la empresa DBAccess, permite a los usuarios finales consultar los valores de los indicadores de gestión de calidad definidos hasta ahora.

Referencias

1. Caicedo, C., Castañeda, W. y Pacheco, J.: Indicadores Integrales de gestión. Bogotá: Mc Graw Hill. (2002) 41

2. Cardalda, J. y Rodriguez, L.: Manual de Gestión de Operaciones de DBAccess (2004) 1- 8 3. DBAccess: Modelo de negocio. Disponible: http://www.dbaccess.com/modelo_negocio.htm.

[Consulta: 2006, Marzo, 03]. (2006). 4. Espinoza, B.: Conceptualización, Diseño y Desarrollo de Sistema de Control de Tiempo para

DBAccess. (2006) 6 5. INSIDE DBAccess: ISO 9000: DBAccess avanza en su estrategia de aseguramiento de la

Calidad. Disponible: http://www.dbaccess.com/InsideDBAccess/insidedbaccess/insidev3/ spanish/index.html. [Consulta: 2006, Marzo, 03]. (2004).

6. Misner, S., Luckevich, M. y Vitt, E. : BUSINESS INTELLIGENCE: Técnicas de análisis para la toma de decisiones estratégicas. Madrid: Mc Graw Hill. (2003). 174.

7. Nader, J. Sistema de Apoyo Gerencial Universitario. Trabajo de Grado no publicado, Instituto Tecnológico de Buenos Aires, Argentina, Buenos Aires. (2003).

8. Salcedo, H. Indicadores de gestión para las universidades venezolanas: un proyecto de alcance nacional. Agenda Académica 6(1), (1998), 63-91.

9. Zvenger, P. Introducción al soporte de decisiones. Trabajo de Grado no publicado, Universidad del Sur, Bahía Blanca. (2005).


566