Tesis doctoral. Interfaz de usuario: de la especificación a la ...

Tesis Doctoral

Departamento de SistemasInformticos y Computacin

[email protected]

Especificacin de interfaz de usuario:de los requisitos a la generacin automtica.

Pedro Juan Molina [email protected]

Departamento de Sistemas Informticos y ComputacinUNIVERSIDAD POLITCNICA DE VALENCIA

Director: Dr. scar Pastor Lpez

Valencia, 18 de diciembre de 2002

II TESIS DOCTORAL: ESPECIFICACIN DE INTERFAZ DE USUARIO.

Tesis doctoral.c Pedro J. Molina Moreno, Chinchilla de Montearagn, Albacete, Espaa.

MCMXCVIII - MMIII.Reservados todos los derechos.Porciones de este trabajo estn protegidas bajo Patente US/PTO 10/356.250.

Diseo de cubierta: Pedro J. MolinaIlustracin de cubierta: Vista del ro Pasig (Filipinas) con el Puente Grande depiedra, antes del terremoto de 1863. Fernando Brambila. Coleccin de dibujosy grabados de la Expedicin Malaspina. 1789-1794. Museo Naval, Madrid.

Autoedicin y maquetado en LATEX / MiKTEX y pdfTEX.

III

Abstract

Developing user interfaces is a high resources consuming task. On theother hand, Conceptual Modeling techniques have been proven to be valu-able in order to increase the abstraction level to build systems. However, tra-ditionally, these approaches have forgotten the modeling of the user interface.This PhD thesis provides an extension for the specification of user interfaceson object-oriented conceptual models. The proposed model explores the con-ceptual pattern languages as tools for requirement elicitation, specification andcode generation. As supporting tools, models editors, specification, prototypesand code generators have been developed. All of them have been refined,fine-tuned and validated in an empiric way in an industrial environment afterseveral iterative development cycles. The user interface development processproposed reduces drastically design times and resources needed due to codegeneration and rapid prototyping techniques introduced. Analysis based onConceptual Modeling and supported by code generation techniques narrowsthe gap to the Automatic Programming Paradigm utopia as stated by Balzer.Moreover, in this way, the developing of software systems change from an ar-tisan process to a software production method where the quality of the processfollowed can be guaranteed in the final product.

IV TESIS DOCTORAL: ESPECIFICACIN DE INTERFAZ DE USUARIO.

Resumen

El desarrollo de interfaces de usuario es una tarea que consume grandescantidades de recursos. Por otro lado, las tcnicas de modelado conceptual handemostrado ser muy valiosas para incrementar el nivel de abstraccin a la horade construir sistemas, sin embargo, histricamente dejaban de lado el modela-do de la interfaz de usuario. La presente tesis proporciona una extensin parala especificacin de interfaces de usuario sobre modelos conceptuales orien-tados a objetos. El modelo propuesto explora los lenguajes de patrones con-ceptuales como herramientas para la elicitacin de requisitos, especificacin ygeneracin de cdigo. Como herramientas de soporte, se han construido edi-tores de modelos, especificaciones, prototipos y generadores de cdigo. Todoello, ha sido refinado y validado empricamente en un entorno industrial trasvarios ciclos de desarrollo iterativo. El proceso de desarrollo de interfaces deusuario propuesto reduce drsticamente los tiempos de desarrollo as comolos recursos necesarios gracias a las tcnicas de generacin de cdigo y prototi-pacin rpida introducidas. El anlisis basado en Modelizacin Conceptual yapoyado sobre tcnicas de generacin de cdigo acerca un poco ms la utopadel Paradigma de la Programacin Automtica enunciada por Balzer. Ms an,la construccin de sistemas pierde caractersticas de artesana para convertirseen un mtodo de ingeniera de produccin de software que asegura la calidaddel producto software.

V

Resum

El desenvolupament dinterfcies dusuari s una tasca que consumeixgrans quantitats de recursos. Daltra banda, les tcniques de modelatge concep-tual han demostrat ser molt valuoses per a incrementar el nivell dabstraccia lhora de construir sistemes, no obstant, histricament deixaven de costat elmodelatge de la interfcie dusuari. La present tesi proporciona una extensiper a lespecificaci dinterfcies dusuari sobre models conceptuals orientatsa objectes. El model proposat explora els llenguatges de patrons conceptualscom a ferramentes per a lelicitaci de requisits, especificaci i generaci de co-di. Com a ferramentes de suport, shan construt editors de models, especifica-cions, prototips i generadors de codi. Tot aix, ha sigut refinat i validat empri-cament en un entorn industrial desprs de diversos cicles de desenvolupamentiteratiu. El procs de desenvolupament dinterfcies dusuari proposat redueixdrsticament els temps de desenvolupament aix com els recursos necessarisgrcies a les tcniques de generaci de codi i prototipat rpida introdudes.Lanlisi basada en Modelizaci Conceptual i recolzat sobre tcniques de ge-neraci de codi acosta un poc ms la utopia del Paradigma de la ProgramaciAutomtica enunciada per Balzer. Ms encara, la construcci de sistemes perdcaracterstiques dartesania per a convertir-se en un mtode denginyeria deproducci de programari que assegura la qualitat del producte programari.

Palabras clave

Keywords:

User interface, specification model, conceptual modeling, code generation, object ori-ented methods, patterns.

Palabras clave:

Interfaz de usuario, modelo de especificacin, modelado conceptual, generacin de c-digo, mtodos orientacin a objetos, patrones.

Paraules clau:

Interfcie dusuari, model despecificaci, modelatge conceptual, generaci de codi, m-todes dorientaci a objectes, patrons.

VI

Datos de la tesis

Ttulo de la tesis: Especificacin de interfaz de usuario:de los requisitos a la generacin automtica.

Presentada por: Ingeniero Pedro Juan Molina Moreno,[email protected]

Dirigida por: Catedrtico Oscar Pastor Lpez,[email protected]

Universidad: Universidad Politcnica de Valencia.

Departamento: Sistemas Informticos y Computacin.Programa de doctorado: Programacin Declarativa e Ingeniera de la

Programacin.

Memoria para optar al grado de Doctor en Informtica.

Depsito: Valencia, a 18 de Febrero de 2003.Defensa: Valencia, a 14 de Marzo de 2003.

VII

VIII TESIS DOCTORAL: ESPECIFICACIN DE INTERFAZ DE USUARIO.

Dedicado

a mi amada Silvia:por sacrificar tantos fines de semana sin mi compaa,

a mis queridos padres, Pedro y Manoli:por apoyarme sin descanso en el largo camino para llegar hasta aqu,

y a mi siempre despierto hermano Pablo:por la ayuda logstica prestada ;-)

Agradecimientos

Enrolarme en el desarrollo de unatesis, como lo sera un viaje en galenal Nuevo Mundo all por el siglo XVI, hasido para mi un excitante desafo. Talaventura conlleva aos de preparaciny esfuerzo continuado, que sin lugar adudas, sera difcilmente abordable e im-posible de llevar a buen puerto sin la co-laboracin y el aliento de muchas per-sonas.

A todos aquellos que me han prestado su ayuda de un modo u otro a lolargo de la travesa quiero agradecerles su colaboracin y dedicarles un peda-cito de est tesis que sin duda merecen.

Gracias en primer lugar al Catedrtico s-car Pastor, capitn experimentado de la Ru-ta de las Especias y mentor de este grumetecon el que aprend a esquivar los embitesde corsarios y piratas. Gracias tambin a losintegrantes del Grupo de Investigacin deOO-Method y dems tripulacin del DSICdonde, con centro de operaciones en el in-signe D3, comenc a navegar all por elao 1998 d.C. Gracias al visionario y mece-nas Jos Iborra por la financiacin de aque-llas primeras velas con las que abandona-mos la tierra firme para echarnos a la mar.

Puedo asegurar sin temor a equivocarmeque CARE Technologies S.A. ha sido la naveideal que nos ha permitido surcar las aguaspara alcanzar el ansiado objetivo. Quiero ex-

IX

X TESIS DOCTORAL: ESPECIFICACIN DE INTERFAZ DE USUARIO.

presar mi agradecimiento a su presidente Siegfried Borho, a su director EmilioIborra por facilitar los medios para tal empresa, a todos los integrantes de losdepartamentos de I+D, especialmente a los veteranos marinos con los he com-batido mano a mano en mil batallas, y Factora de Aplicaciones por presentarlas condiciones ideales para investigar y probar nuevos materiales para las ve-las, disear y preparar la nave para soportar cualquier contingencia, bien seatormenta o huracn tropical.

Gracias tambin a los crticos y sobre todo pacientescolaboradores: Silvia Estbanez, Javier Hernndez, JosRomero, ngel Martnez, Pedro J. Jimnez, J. IgnacioSnchez, Ramn Moll y Javier Jaen por hacerme rectificarel rumbo cuando me desviaba de la ruta trazada con el sex-tante respecto a la Osa Mayor.

Mencin especial merece el capitn belga Prof. Jean Van-derdonckt que me ha prestado su ayuda y orientacin desinteresada durantela navegacin en alta mar.

Por ltimo, gracias a los amigos de verdad que han animado a continuarcon tesn cuando el azar nos era adverso y las fuerzas podan flaquear.

Hoy hemos avistado un pedazo de tierra.Parece que el viaje llega a su fin: Sern estslas clidas playas del Nuevo Mundo? Pronto losabremos.

Gracias a cada uno de vosotros amigos.

Denia, a 18 de diciembre de 2002 d.C.

Pedro J. Molina

Las figuras empleadas pertenecen a la exposicin: Manila 1571-1898. Occidente en

Oriente del Centro de Estudios Histricos de Obras Pblicas y Urbanismo. Fuente:

http://www.cedex.es/cehopu/expomanila/ .1234

1Mapamundi. Toms Lpez. 1792. Museo Naval, Madrid.2Corte transversal de un navo y dibujo de un dique seco. lbum marino de Cesreo Fernndez

Duro. Museo Naval.3Astrolabio astronmico del siglo XVI. Museo Naval.4Vista de una torre y parte del pueblo de Samboangan. Fernando Brambila. Coleccin de dibu-

jos y grabados de la Expedicin Malaspina. 1789-1794. Museo Naval.

http://www.cedex.es/cehopu/expomanila/

ndice general

1. Introduccin 1

1.1. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . 2

1.3. Metodologa de trabajo . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Resumen de aportaciones . . . . . . . . . . . . . . . . . . . . . . 5

1.5. Estructura de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1. Organizacin . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.2. Convenciones tipogrficas empleadas . . . . . . . . . . . 7

2. Situacin actual: Construccin de IU 9

2.1. Herramientas para la construccin de Interfaces de Usuario . . 9

2.1.1. RAD: Entornos de desarrollo rpido . . . . . . . . . . . . 10

2.1.2. Herramientas basadas en modelos . . . . . . . . . . . . . 11

2.1.3. Conclusiones sobre las herramientas comerciales . . . . 16

2.2. Modelos para la especificacin de Interfaces de Usuario . . . . . 17

2.2.1. UIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.2. JANUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.3. TRIDENT . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.4. OVID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.2.5. UMLi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2.6. CTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.7. MOBI-D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.2.8. Wisdom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.2.9. Otras aproximaciones . . . . . . . . . . . . . . . . . . . . 50

2.3. Conclusiones del captulo . . . . . . . . . . . . . . . . . . . . . . 51

XI

XII TESIS DOCTORAL: ESPECIFICACIN DE INTERFAZ DE USUARIO.

3. Fundamentos 53

3.1. Modelado Conceptual . . . . . . . . . . . . . . . . . . . . . . . . 53

3.1.1. UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.1.2. OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.1.3. OO-Method . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2. Interfaces de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2.1. Definicin . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2.2. Evolucin de las interfaces de usuario . . . . . . . . . . . 64

3.2.3. Problemas de las interfaces inadecuadas . . . . . . . . . 69

3.2.4. Ventajas de las interfaces correctas . . . . . . . . . . . . . 70

3.2.5. Principios bsicos . . . . . . . . . . . . . . . . . . . . . . . 71

3.3. Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.3.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.3.2. Definicin . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.3.3. Formatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.3.4. Cualidades de un patrn . . . . . . . . . . . . . . . . . . . 83

3.3.5. Lenguajes de patrones . . . . . . . . . . . . . . . . . . . . 85

3.3.6. Uso de los patrones en esta tesis . . . . . . . . . . . . . . 87

3.3.7. Patrones: Panormica general . . . . . . . . . . . . . . . . 87

3.3.8. Reificacin y el Efecto (Delta) . . . . . . . . . . . . . . 90

3.4. Tecnologas de Generacin de Cdigo . . . . . . . . . . . . . . . 91

3.4.1. Ventajas de la generacin de cdigo . . . . . . . . . . . . 91

3.4.2. El mtodo FAST . . . . . . . . . . . . . . . . . . . . . . . . 93

3.4.3. Generacin de cdigo basada en modelos orientados aobjetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102


4. Especificacin de interfaz de usuario 113

4.1. Conceptos del Modelo de Presentacin . . . . . . . . . . . . . . . 113

4.1.1. Requisitos de construccin . . . . . . . . . . . . . . . . . 114

4.1.2. Camino explorado . . . . . . . . . . . . . . . . . . . . . . 115

4.2. Lenguaje de patrones propuesto . . . . . . . . . . . . . . . . . . 115

4.2.1. Plantilla de descripcin de los patrones . . . . . . . . . . 117

NDICE GENERAL. XIII

4.2.2. Nivel 1: Acceso a la aplicacin . . . . . . . . . . . . . . . 119

4.2.3. Nivel 2: Unidades de interaccin . . . . . . . . . . . . . . 125

4.2.4. Nivel 3: Patrones elementales . . . . . . . . . . . . . . . . 145

4.3. Notacin grfica del Modelo de Presentacin . . . . . . . . . . . 194


5. Formalizacin del modelo 199

5.1. Meta-modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

5.2. Semntica del diagrama navegacional . . . . . . . . . . . . . . . 202

5.3. Semntica basada en tareas . . . . . . . . . . . . . . . . . . . . . 203

5.3.1. Especificacin de los patrones usando notacin CTT . . . 204

5.3.2. Especificacin como composicin de subrboles . . . . . 209

5.3.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 211

5.4. Semntica de visibilidad por agente . . . . . . . . . . . . . . . . 211

5.4.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

5.4.2. Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

5.4.3. Definiciones de visibilidad . . . . . . . . . . . . . . . . . 215

5.4.4. Visibilidad de un agente en una vista . . . . . . . . . . . 221


6. Inferencia 225

6.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

6.2. Inferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

6.2.1. Inferencia de vistas . . . . . . . . . . . . . . . . . . . . . . 226

6.2.2. Inferencia del rbol de jerarqua de acciones . . . . . . . 227

6.2.3. Inferencia de unidades de interaccin . . . . . . . . . . . 227

6.2.4. Inferencia de patrones auxiliares . . . . . . . . . . . . . . 230

6.3. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

6.4. Aplicacin a un proceso industrial . . . . . . . . . . . . . . . . . 233


XIV TESIS DOCTORAL: ESPECIFICACIN DE INTERFAZ DE USUARIO.

7. Generacin automtica 235

7.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

7.1.1. Generacin automtica . . . . . . . . . . . . . . . . . . . . 236

7.1.2. Interfaces de alta calidad . . . . . . . . . . . . . . . . . . 237

7.1.3. Prototipado rpido . . . . . . . . . . . . . . . . . . . . . . 237

7.1.4. Mayor productividad . . . . . . . . . . . . . . . . . . . . 238

7.2. Ventajas y retos de la generacin automtica de cdigo . . . . . 238

7.3. Fundamentos de generacin . . . . . . . . . . . . . . . . . . . . . 239

7.3.1. Separacin de responsabilidades . . . . . . . . . . . . . . 240

7.3.2. Tiempos de decisin . . . . . . . . . . . . . . . . . . . . . 240

7.3.3. Arquitecturas para generadores . . . . . . . . . . . . . . 241

7.4. Tcnicas de generacin . . . . . . . . . . . . . . . . . . . . . . . . 243

7.4.1. Tcnicas generales . . . . . . . . . . . . . . . . . . . . . . 244

7.4.2. Tcnicas para interfaces de usuario . . . . . . . . . . . . . 252

7.5. Lenguajes intermedios para interfaz de usuario . . . . . . . . . . 256

7.5.1. AUIML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

7.5.2. UIML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

7.5.3. XUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

7.5.4. XFORMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

7.5.5. XIML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

7.6. Entornos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

7.6.1. Entornos de ventanas . . . . . . . . . . . . . . . . . . . . 258

7.6.2. Entornos hipermediales . . . . . . . . . . . . . . . . . . . 258

7.6.3. Entornos embebidos . . . . . . . . . . . . . . . . . . . . . 259

7.7. Requisitos de construccin . . . . . . . . . . . . . . . . . . . . . . 260

7.7.1. Entorno de las aplicaciones producidas . . . . . . . . . . 260

7.7.2. Funcionalidad requerida . . . . . . . . . . . . . . . . . . . 261

7.7.3. Integracin con el resto de la aplicacin . . . . . . . . . . 262

7.7.4. Integracin con cambios manuales . . . . . . . . . . . . . 265

7.8. Traductores implementados . . . . . . . . . . . . . . . . . . . . . 266

7.8.1. Estructura general . . . . . . . . . . . . . . . . . . . . . . 266

7.9. Estrategias de traduccin de los patrones . . . . . . . . . . . . . 268

NDICE GENERAL. XV

7.10. Ejemplos de aplicaciones producidas . . . . . . . . . . . . . . . . 271

7.10.1. Aplicaciones de escritorio . . . . . . . . . . . . . . . . . . 271

7.10.2. Aplicaciones Web . . . . . . . . . . . . . . . . . . . . . . . 272

7.10.3. Aplicaciones mviles para PDA . . . . . . . . . . . . . . 273


8. Impacto sobre el Proceso Software 277

8.1. Productos software . . . . . . . . . . . . . . . . . . . . . . . . . . 277

8.2. Mtodo de ingeniera de dominio . . . . . . . . . . . . . . . . . . 278

8.3. Coste del software . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

8.4. Estudio comparativo . . . . . . . . . . . . . . . . . . . . . . . . . 280

8.4.1. Tiempo de entrega . . . . . . . . . . . . . . . . . . . . . . 281

8.4.2. Productividad . . . . . . . . . . . . . . . . . . . . . . . . . 282

8.4.3. Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

8.4.4. Impacto sobre el ciclo de desarrollo . . . . . . . . . . . . 288

8.5. Impacto sobre la Interfaz de Usuario . . . . . . . . . . . . . . . . 289


9. Conclusiones 293

9.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

9.2. Resumen de aportaciones . . . . . . . . . . . . . . . . . . . . . . 293

9.2.1. Publicaciones relacionadas . . . . . . . . . . . . . . . . . 294

9.2.2. Patentes industriales . . . . . . . . . . . . . . . . . . . . . 296

9.2.3. Productos software comerciales . . . . . . . . . . . . . . . 297

9.3. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

A. Extensin de OASIS 3.0 301

A.1. Sintaxis propuesta para OASIS 3.0 . . . . . . . . . . . . . . . . 301

A.1.1. Notacin empleada . . . . . . . . . . . . . . . . . . . . . . 301

A.1.2. Extensin sintctica . . . . . . . . . . . . . . . . . . . . . . 301

B. Representacin en XML 307

B.1. Representacin del modelo Just-UI en XML . . . . . . . . . . . . 307

XVI TESIS DOCTORAL: ESPECIFICACIN DE INTERFAZ DE USUARIO.

C. Formalizacin de las frmulas de filtros 319

C.1. Sintaxis de las frmulas . . . . . . . . . . . . . . . . . . . . . . . 319

C.2. Semntica asociada . . . . . . . . . . . . . . . . . . . . . . . . . . 321

C.2.1. Semntica de filtro aplicado a un objeto . . . . . . . . . . 321

C.2.2. Semntica de un filtro aplicado a un conjunto de objetos 321

C.3. Composicin de filtros . . . . . . . . . . . . . . . . . . . . . . . . 322

C.4. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

C.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

D. Formacin de reglas de dependencia 325

D.1. Aplicacin del concepto de AIO . . . . . . . . . . . . . . . . . . . 325

D.1.1. Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

D.1.2. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

D.2. Patrn de dependencia . . . . . . . . . . . . . . . . . . . . . . . . 326

D.2.1. Sintaxis empleada . . . . . . . . . . . . . . . . . . . . . . 326

D.2.2. Orden de ejecucin de las reglas . . . . . . . . . . . . . . 328

D.2.3. Ciclos en reglas . . . . . . . . . . . . . . . . . . . . . . . . 328

E. Gua de estilo para aplicaciones Windows 331

E.1. Reglas de estilo para Windows . . . . . . . . . . . . . . . . . . . 331

F. Abreviaturas 347

G. Glosario de trminos 351

Bibliografa 374

ndice de figuras 381

ndice de tablas 384

Captulo 1

Introduccin

Jams se descubrira nada si nos considerse-mos satisfechos con las cosas descubiertas.

Lucio A. Sneca, filsofo y pensadorcordobs, 4 a.C. 65.

En su esencia, la investigacin es la bsquedade la verdad.

Eduardo Primo Yfera, investigadorespaol, [Primo94, 1er captulo, pgina 17].

1.1. Motivacin

Las aplicaciones basadas en sistemas de informacin cuidan, cada vez ms,sus interfaces de usuario. Atrs quedaron los tiempos donde los ordenadoreseran mquinas para una lite: bastaba con que el sistema hiciese bien el trabajono importando cuan crptica1 fuese la interfaz de usuario.

Mas all de su finalidad esencial de interaccin entre hombre y mquina,las interfaces de usuario conforman tambin la cara visible o escaparate de lasaplicaciones tal y como las percibe el cliente final que las usa.

Como consecuencia directa, las interfaces de usuario entregadas en pro-ductos finales estn cada vez ms y ms cuidadas [Constantine99] para ofreceral usuario sensaciones de seguridad, fiabilidad, ergonoma, sencillez de uso yprecisin en la aplicacin suministrada. Todas estas cualidades se transmitensubliminalmente a travs de la interfaz de usuario.

1En los albores de la informtica, donde el ENIAC, las vlvulas y las tarjetas perforadas eran lohabitual.

1

2 TESIS DOCTORAL: ESPECIFICACIN DE INTERFAZ DE USUARIO.

Desde el punto de vista del marketing podramos considerar a las aplica-ciones informticas, como cualquier otro producto, entran por la vista. En estesentido, una cuidada presentacin es esencial para promover su venta. No esde extraar que, ante tal panorama, en la produccin de software comercial ca-da vez es ms frecuente la inversin de mayores esfuerzos en el desarrollo deinterfaces de usuario de alta calidad.

La creciente popularidad de los ordenadores y su uso cotidiano han cam-biado la relacin de los usuarios frente a la mquina y, por ende, lo que losusuarios esperan de ella. Nuevas formas de ordenadores como asistentes paradatos personales (PDA), telfonos mviles, sistemas empotrados o nuevas ge-neraciones de electrodomsticos comienzan a popularizarse, obligndonos ainteractuar con sus interfaces que no siempre son todo lo naturales ni intuiti-vas que uno hubiera deseado.

Los usuarios exigen cualidades al software destinadas a facilitar su trabajo,ahorrar tiempo de uso y de aprendizaje, evitar y corregir los errores. Losprocesos de desarrollo de aplicaciones dedican cada vez mayores esfuerzos adisear y mantener las interfaces de usuario de sus aplicaciones. Gran partede este trabajo se realiza a mano por diseadores y programadores que creany dotan de funcionalidad a las interfaces construidas. Este proceso consumemuchos recursos: personal, herramientas, tiempo y dinero.

Por otro lado, la emergente Sociedad de la Informacin de este nuevo milenioincrementa da a da el volumen de datos producidos. Las aplicaciones nece-sarias para extraer informacin valiosa del ocano de datos se convierten en unanecesidad imperiosa. Los consumidores de aplicaciones demandan cada vezmejor y ms aplicaciones en menos tiempo.

El panorama descrito se beneficiara de cualquier nuevo avance que permi-ta incrementar la productividad en el desarrollo de interfaces de usuario.

1.2. Planteamiento del problema

La Ingeniera del Software promueve tcnicas y mtodos de trabajo para lo-grar que el proceso de produccin de Software no sea una tarea artesanal, sinouna verdadera tarea de ingeniera. Los lenguajes de modelizacin conceptualayudan en este sentido, reduciendo el gap semntico (distancia semntica) exis-tente entre el espacio del problema donde reside el usuario y los lenguajes debajo nivel, pertenecientes al espacio de la solucin, entendibles por la mquina.

El Paradigma de Programacin Automtica [Balzer83], sus aproximacionesdesde el modelado conceptual (OBLOG [Sernadas87], Troll [Hartmann94],OASIS [Pastor92b, Pastor95]) y la generacin automtica de cdigo (OBLOG

INTRODUCCIN. 3

[ESDI93], OO-Method [Pastor96, Pastor97]) logran incrementar la velocidad dedesarrollo de aplicaciones de un modo espectacular provocando una revolu-cin comparable al paso del cdigo ensamblador a lenguajes de programacinde tercera generacin. Sin embargo, los modelos conceptuales suelen centrar laatencin sobre el problema en s: su estructura dinmica asociada, reglas de ne-gocio, es decir, los llamados requisitos funcionales. Las aplicaciones obtenidasde este modo son producidas en tiempos de desarrollo muy bajos y satisfacenlas reglas de negocio especificadas, pero carecen de o tienen una muy pobreinterfaz de usuario que ha de ser construida a mano por completo o al menosrefinada por diseadores especializados.

Sin embargo, existen otro tipo de requisitos denominados clsicamente co-mo requisitos no funcionales que agrupan otro tipo de requisitos importantes delproblema tratado, y que son ms escurridizos a la hora de capturarlos medi-ante tcnicas de Modelado Conceptual. En particular, entre estos requisitos nofuncionales, hallamos los requisitos relativos a la interfaz de usuario, la comu-nicacin entre el hombre y la mquina para llevar a cabo una tarea.

Si tales requisitos de interfaz de usuario logran ser capturados de una ma-nera precisa y se establece una semntica clara para su aplicacin, se abre lapuerta de nuevo al Paradigma de Programacin Automtica aplicada al mbitode las interfaces de usuario. Es decir, la produccin de modo automtico deinterfaces de usuario que cumplen con los requisitos expresados.

Esta tesis pretende proporcionar un marco basado en un lenguaje de pa-trones conceptuales para la especificacin y posterior generacin de cdigocompleta de interfaces de usuario para sistemas de informacin. Los sistemasde informacin engloban a las aplicaciones de gestin, sistemas de negocio,logstica, control de stocks, distribucin, facturacin, contabilidad, etc. consti-tuyendo un gran parte del mercado del software comercial. Esos sistemas in-formacin suelen estar soportados por interfaces WIMP2 basadas en formu-larios que pueden ser generadas de modo automtico. Por contra, controleso mecanismos de interaccin como grficos altamente interactivos o grficosanimados caen claramente fuera del alcance de esta tesis.

La especificacin abstracta de interfaces de usuario junto con tcnicas degeneracin automtica pueden reducir en gran medida el esfuerzo necesariopara obtener las interfaces de tales aplicaciones.

A cambio de invertir un poco ms de esfuerzo en la fase de anlisis (medi-ante la especificacin del correspondiente esquema conceptual y sus caracters-ticas de interfaz de usuario), las fases de codificacin, pruebas e integracin sereducen en gran medida gracias a tcnicas de generacin automtica de cdigo

2Trmino acuado para referenciar interfaces para entornos grficos de usuario IGU, tradi-cionalmente basadas en ventanas, iconos, mens y punteros (Window, Icon, Menu, Pointer).


que permiten derivar las aplicaciones desde las especificaciones.

Los programas derivados de este modo pueden ser empleados como pro-totipos de la aplicacin. Ms an, un prototipo puede convertirse en versinfinal, lista para ser usado con pocas o ninguna intervencin por parte de losdiseadores y programadores.

La presente tesis proporciona una extensin a los modelos conceptuales ori-entados a objetos clsicos para lograr capturar los anteriormente referidos re-quisitos de interfaz de usuario. Para tal fin, se explorar una aproximacinbasada en patrones en la que los esfuerzos se concentran en identificar patronesde comportamiento, estructura o funcionalidad (todo ello a nivel de anlisis)para capturar su semntica, y al mismo tiempo, dotar desde el anlisis de meca-nismos para proporcionar homogeneidad y reuso a las interfaces producidas.

El modelo planteado, denominado Just-UI, permite la especificacin de re-quisitos de interfaz de usuario a nivel conceptual basndose en un lenguajede patrones conceptuales de interfaz de usuario. Se soporta la generacin au-tomtica a diferentes dispositivos a partir de este modelo. Completado con unmtodo orientado a objetos (p.e. OO-Method), es posible abordar el desarrollode aplicaciones completas.

El problema planteado cae dentro de lo que se ha denominado Ingeniera deDominio [Cleaveland01], donde el dominio a tratar lo constituyen las Interfacesde Usuario para aplicaciones de gestin.

1.3. Metodologa de trabajo

La presente tesis est enmarcada dentro de un trabajo de investigacin di-latado en el tiempo que ha compaginado desde su orgenes teora y practica.Los inicios de este trabajo de investigacin se remontan al ao 1998, dondeen un marco acadmico como es el grupo de investigacin de OO-Method enel Dpto. de Sistemas Informticos de Computacin, se presento un ProyectoFinal de Carrera [Molina98] que abri las puertas a un amplio campo de inves-tigacin. Una beca financiada por Consoft S.A. y posteriormente otra beca FPI(Fomento del Personal Investigador) concedida por el Ministerio de Cienciay Tecnologa lo hicieron posible. Posteriormente, la segunda parte ha transcu-rrido en CARE Technologies S.A., empresa de Investigacin y Desarrollo enIngeniera de Software surgida a raz del grupo de investigacin inicial.

Durante este tiempo, se ha llevado a cabo una investigacin activa de ex-perimentacin. Se han construido modelos, editores de modelos, prototipos ygeneradores de cdigo en un ciclo de vida en espiral con refinamientos suce-sivos.

INTRODUCCIN. 5

A medida que se ha ido desarrollando la base terica para nuevos con-ceptos y patrones que enriquecan la expresividad del modelo conceptual, losgeneradores han sido extendidos de modo incremental para adaptarse a losnuevos requisitos emergentes, implementado los nuevos patrones y redisean-do y reimplementando los patrones previos cuando estos se han visto afecta-dos.

La evaluacin de aplicaciones y el estudio terico ha permitido extraernuevos patrones tiles. Al poner en prctica los nuevos patrones en el modeloy en los generadores de cdigo se ha podido producir aplicaciones con menosesfuerzo que en la iteracin previa.

De este modo, por medio de sucesivas iteraciones se ha conseguido validarlos patrones empricamente sobre casos reales en un contexto industrial para irdestilando en cada iteracin el lenguaje de patrones propuesto.

1.4. Resumen de aportaciones

Las principales aportaciones de esta tesis son las siguientes:

1. Describe el estado de la cuestin en la especificacin de interfaces basadasen modelos (vase captulo 2).

2. Describe los pilares base en los que se fundamenta esta tesis (vase captulo3).

3. Explora la aplicacin de patrones conceptuales a la especificacin de in-terfaces de usuario. Y se emplean los patrones para construir un nuevomodelo de especificacin de interfaces de usuario como medio de cap-tura de propiedades abstractas de las interfaces de usuario (vase captulo4).

4. Propone un nuevo mtodo para la especificacin de interfaces de usua-rio basado en la extensin de un modelo conceptual orientado a obje-tos usando patrones conceptuales de interfaz de usuario, manteniendo almismo tiempo, una nica especificacin (vase captulo 4).

5. Demuestra como la especificacin obtenida es independiente de conside-raciones de diseo o implementaciones particulares (vase captulo 4).

6. Se formaliza el modelo presentado usando meta-modelos y especifica-ciones de tareas (vase captulo 5).

7. Presenta una serie de tcnicas de inferencia para facilitar la prototipacinrpida de interfaces de usuario a partir de especificaciones incompletas(vase captulo 6).


8. Revisa y propone tcnicas para construir generadores de cdigo que de-riven automticamente implementaciones a partir de la especificacinpara distintas plataformas (vase captulo 7).

9. Propone mecanismos de integracin del componente de interfaz de usua-rio con otros componentes de la aplicacin (componentes de lgica denegocio) para disponer de una aplicacin totalmente funcional generadade modo totalmente automtico (vase captulo 7).

10. A travs de la utilizacin real del mtodo propuesto sobre casos indus-triales, se demuestra de un modo emprico cmo el mtodo ha incididopositivamente en la productividad, los tiempos de entrega y la calidad delos productos desarrollados (vase captulo 8).

1.5. Estructura de la tesis

Los siguientes apartados describen someramente el contenido de cada ca-ptulo y las convenciones tipogrficas empleadas.

1.5.1. Organizacin

El presente captulo 1 introduce la motivacin, describe el problema aresolver y declara las convenciones tipogrficas empleadas en esta tesis.

El captulo 2 describe el estado de la cuestin en los campos industri-ales y de investigacin. Trabajos previos relevantes a la especificacin yconstruccin de interfaces de usuario son descritos en este captulo.

Antes de describir con detalle las aportaciones de esta tesis, el captulo3 introduce los fundamentos en los que se basa este trabajo. Los concep-tos y la terminologa descrita se tornan imprescindibles para la correctacomprensin de captulos posteriores.

Por fin, el captulo 4 constituye el captulo central de la tesis. Describe lospatrones conceptuales para describir interfaces de usuario y se describeel modelo de especificacin asociado.

La semntica desde diversos puntos de vista es descrita en el captulo 5.

Un mecanismo adicional para favorecer el prototipado rpido es descritoen el captulo 6.

Las tcnicas de generacin automtica de cdigo a partir del modelo deespecificacin son descritas en el captulo 7.

INTRODUCCIN. 7

La justificacin de la utilidad de las ideas presentadas se recoge en elcaptulo 8 donde se muestran los resultados empricos obtenidos tras laaplicacin en un entorno industrial con software comercial.

Finalmente, el captulo 9 resume las conclusiones y aportaciones del tra-bajo presentado.

Los apndices proporcionan informacin complementaria: el apndice Apresenta una extensin sintctica a OASIS para dar cuenta de los pa-trones conceptuales descritos en esta tesis, el apndice B presenta un DTDpara describir en XML especificaciones Just-UI, el apndice C describe endetalle las frmulas de filtro, el apndice D hace lo propio para las reglasde dependencia, mientras que el apndice E muestra un ejemplo de guade estilo para una plataforma particular. Por ltimo, los apndices F y Gcontienen una lista de abreviaturas y un glosario de trminos respectiva-mente.

La bibliografa junto con los ndices de figuras y tablas cierran este traba-jo.

1.5.2. Convenciones tipogrficas empleadas

Para facilitar en la medida de lo posible la lectura de la tesis se han adopta-do una serie de convenciones tipogrficas encaminadas a dotar de homogenei-dad a los distintos tipos de conceptos empleados. Las convenciones son lashabituales en los textos impresos. A continuacin, se enumeran cada una delas convenciones junto a un ejemplo.

Los trminos o vocablos forneos comnmente aceptados en la jerga in-formtica y que, sin embargo, no son propios del espaol, aparecen re-saltados en cursiva para indicar que se trata de trminos procedentes deotra lengua, por ejemplo, el sort de inters.

Las citas o definiciones procedentes de terceras fuentes aparecen en cur-siva y convenientemente identadas. Ejemplo de cita:

Alea iacta est.

Gaius Julius Caesar, emperador romano, 100 a.C. 44 a.C.

El cdigo fuente proveniente de un lenguaje de especificacin formal o unlenguaje de programacin aparece en bloques distinguidos con tipografano proporcional.


[User]trabaja.SetValue(a) : a = "No" :

sueldo.SetActive(false) .

sueldo.SetValue(0)

Las referencias a funciones dentro de una interfaz de usuario particularse denotar empleando fuente Sans Serif. Como por ejemplo:

Combinaciones de teclado: Presione Ctrl + Alt + Del para . . .

Entradas de men: OpcionesPreferenciasFuentes

Botones de accin: Pulse Aceptar para confirmar la tarea.

Las referencias o bibliografa aparecen entre corchetes siguiendo elconvenio estndar indicando un acrnimo y ao de publicacin[Alexander64]. La informacin completa a las referencias se encuentraclasificada alfabticamente en la seccin de Bibliografa.

Las existencia de notas al pie3 aparecen etiquetadas con un subndicenumrico (nico para cada captulo) que corresponde con la nota etique-tada con el mismo nmero que figura al pie de la pgina.

Para facilitar la lectura no-lineal y la navegacin por el documento, laversin digital (no impresa) de esta tesis contiene hiper-enlaces para lascitas bibliogrficas, referencias a captulos o secciones, notas al pie, ndicegeneral, ndices de figuras y tablas, direcciones de internet (en formato deURL), etc.

En la seccin de Bibliografa aparecen (a modo de referencias cruzadas)las pginas de aparicin para cada referencia. Del mismo modo, en laversin digital de este documento dichas referencias cruzadas son hiper-enlaces.

3Ejemplo de nota al pie.

Captulo 2

Situacin actual: Construccinde Interfaces de Usuario

Aquel que duda y no investiga,se torna no slo infeliz,sino tambin injusto.

Blaise Pascal, matemtico y pensadorfrancs, 1623 1662.

El presente captulo realiza un recorrido por los trabajos ms relevantesen el campo de la especificacin y construccin de interfaces de usuario tantodesde el punto de vista de trabajos prcticos implementados en herramientascomerciales y de uso actual en la industria como trabajos tericos desarrolla-dos en mbitos acadmicos. Una vez descrito el cuadro general, ser ms fcilencuadrar las aportaciones al campo proporcionadas por esta tesis.

2.1. Herramientas para la construccin de Interfacesde Usuario

En el mundo de las aplicaciones comerciales podemos diferencias dos tiposde aproximaciones para la construccin de interfaces de usuario:

1. RAD y herramientas de autor. Son herramientas de diseo para construirdirectamente la interfaz de usuario.

2. Herramientas basadas en modelos. Son herramientas basadas en mode-los para intentar aumentar el nivel de abstraccin. Se apoyan en genera-dores de cdigo parciales o totales.

9


Figura 2.1: Entorno de Desarrollo Integrado de Visual Basic 6.0.

A continuacin se describirn las ms significativas.

2.1.1. RAD: Entornos de desarrollo rpido

La primera categora tiene un menor nivel de abstraccin. Aqu se encua-dran las llamadas herramientas RAD (Rapid Application Development). VisualBasic (Microsoft Corp.), Power Builder (Sybase), Delphi o C++ Builder (InpriseCorp.) son brillantes ejemplos de este tipo de herramientas donde la construc-cin de interfaces de usuario es muy rpida en comparacin con las herra-mientas y lenguajes de 3a generacin previos. En ellas, el programador y/odiseador de la interfaz de usuario ayudados por un IDE1 (como pueden serEclipse o Visual Studio .NET) van construyendo la interfaz de usuario medianteel paradigma WYSIWYG: eligiendo los componentes de la interfaz, ajustandosus propiedades y programando el enlace con la lgica de la aplicacin propia-mente dicha.

Es precisamente, el paradigma WYSIWYG, tambin conocido como progra-macin visual, el que ha hecho ms productiva la fase de produccin de inter-

1IDE: Entorno integrado de desarrollo. Vase como ejemplo la Figura 2.1

SITUACIN ACTUAL: CONSTRUCCIN DE INTERFACES DE USUARIO. 11

faces de usuario tal y como se vena haciendo antes de la aparicin de este tipode herramientas. Todo ello a pesar de que dichas herramientas estn limitadas:

Dan soporte a los aspectos de presentacin, pero no cubren adecuada-mente aspectos de dilogo que ha de ser codificado completamente amano.

Solo aptas para interfaces WIMP. Por ejemplo, los grficos dinmicos ogrficos interactivos deben ser programados de modo manual.

Herramientas de autor como Macromedia Director, Macromedia Flash oMacromedia Dreamweaver [Inc.02] son un claro exponente de editores parala construccin de interfaces. Sin embargo, construir buenas interfaces con es-tas herramientas es complejo. De este modo, la calidad y correccin de la in-terfaz as construida queda en manos del saber hacer del diseador que laconstruye. Para garantizar que dicha interfaz sigue estndares de calidad y seajusta a los requisitos se necesitarn realizar, como mnimo, diversas tandas depruebas y evaluaciones.

2.1.2. Herramientas basadas en modelos

Para completar este recorrido sobre el estado actual de las herramientas,comentaremos aquellas herramientas comerciales que estn siendo usadas enla industria para la produccin de software. En particular, se comentarn Ra-tional Rose, TogetherSoft, Argo UML, System Architect, Cool:Plex, ezWay yGenova.

Rational Rose

Rational Rose 2000 [Rat02] (Rational Corp.) es la herramienta CASE de re-ferencia para la especificacin grfica con la notacin UML. Las herramientasde Rational Corp. intentan abarcar todo el ciclo de vida para dar soporte a sumetodologa RUP (Ration Unified Process). Sin embargo, Rational no disponede herramientas para el soporte directo al desarrollo de interfaces de usuario.Ni en la notacin UML, ni en las herramientas de soporte a RUP, se da unarespuesta al modelado o diseo de interfaces de usuario.

Together

Together [Tog02] es otra herramienta de modelado de cdigo (modelado ydocumentacin de diseo orientado a lenguajes de 3a generacin) de la com-paa TogetherSoft. Similar a Rational Rose, da soporte al modelado de cdigo,


generacin de clases y permite mantener sincronizado cdigo y modelo de di-seo. En la ltima versin, incluye caractersticas tipo RAD (UI Builder) con elcual es posible disear interfaces de usuario para el lenguaje Java.

Figura 2.2: Herramienta Argo UML.

Argo UML

Argo UML [Arg02, Robbins97] es la respuesta del mundo del software decdigo abierto a herramientas como Rational Rose. Implementado en Java ycon licencia de cdigo abierto, permite modelar usando notacin UML (vaseFigura 2.2). La apertura de cdigo facilita la creacin de mdulos adicionalespara la generacin de cdigo.2 Al igual que Rational Rose, no dispone de as-pectos especficos para el desarrollo de interfaces de usuario.

2Argo UML es un proyecto GNU de cdigo abierto en Java. Disponible en http://argouml.tigris.org

http://argouml.tigris.orghttp://argouml.tigris.org


System Architect

Por otro lado, System Architect [Sys01] (Popkin Software) es otra herra-mienta CASE que permite construir diagramas segn diversas notaciones talescomo UML, OMT o Coad & Yourdon entre otras. Su finalidad es la de soportarla fase de anlisis de un sistema software y la de proporcionar un marco de tra-bajo inicial en la fase de diseo. Para este ltimo fin, esta herramienta propor-ciona un lenguaje de guiones o de scripts. Sobre dicho lenguaje se construyenprogramas que recorren la informacin obtenida en el anlisis y generan plan-tillas de cdigo que contienen las cabeceras de las funciones a implementar.Lejos de ser scripts de generacin completos, los scripts generan muy poco c-digo y slo los aspectos ms genricos estructurales. El usuario puede adaptarel script para ajustarlo a sus necesidades, pero para ello, deber aprender amanejar este nuevo lenguaje de script y conocer la estructura de la informacindel modelo que se pretende recorrer.

System Architect cuenta con scripts para generar cdigo SQL que producelas tablas e ndices para diversos gestores de base de datos, cdigo de cabecerapara funciones y clases en C++, Java, etc. Sin embargo, la generacin de cdigoen estos entornos para interfaz de usuario es casi inexistente.

Figura 2.3: Herramienta Cool:Plex.


Cool:Plex

Cool:Plex [Coo01] es un producto de Computer Associates. Es una herra-mienta comercial destinada al diseo de aplicaciones cliente-servidor indepen-diente de plataforma. Se basa en diagramas de entidad relacin extendidos(vase Figura 2.3) para especificar la esttica del sistema. Usa componentes ypatrones de diseo [Gamma95] que son traducidos en la fase de generacina un lenguaje destino en particular. La interfaz de usuario se disea al estiloWYSIWYG de modo similar a las herramientas RAD. De la interfaz, lo nicoque se permite disear es la esttica de cada ventana o panel.

eZway

eZway [eZw01] es un producto de Freeway Inc. Es una herramienta de de-sarrollo de aplicaciones ligada a plataformas y tecnologas de Microsoft. El pro-ceso de construccin est soportado por las siguientes caractersticas:

Definicin de funcionalidad.

Diagrama de casos de uso. Dibujados usando la herramienta VISIO[VIS02].

Especificacin de los casos de uso, a travs de una tabla textual.

Definicin de formularios. Diseo usando formularios para Visual Basico pginas ASP.

Componentes de segunda y tercera capa. Permite definir los compo-nentes de segunda y tercera capa para lgica de negocio y persistenciarespectivamente.

Generacin de cdigo. A partir de los objetos definidos en cada capa ge-nera cdigo Visual Basic o ASP.

Gestin del cambio. Se permite almacenar cdigo personalizado VisualBasic para ensamblar con la aplicacin final.

eZway, por tanto, est muy ligado a la plataforma Microsoft. Emplea VisualBasic y objetos ActiveX en el proceso de diseo, lo que dificulta la migracindel proyecto a otras plataformas como pueda ser Java.

Desde el punto de vista de la interfaz de usuario, el diseo es dependientede la tecnologa Microsoft, por lo cual, no puede ser fcilmente migrado a otrosentornos no Windows.


Figura 2.4: Modelo de Dilogo de Genova.

Genova

Genova 7.0 es un mdulo de extensin para Rational Rose desarrolladopor Genera A.S. [Genera00]. A partir de modelos UML construidos con Ra-tional Rose, Genova permite construir Modelos de Dilogo y de Presentacin(vase Figura 2.4) de modo parcial que representan la interfaz de usuario co-mo un rbol de composicin de AIO3 [Bodart96]. Genova incluye el conceptode Selectores de objeto (Object Selectors) para establecer las corresponden-cias entre AIO CIO. Algunos aspectos de diseo pueden ser parametriza-dos (vase Figuras 2.5 y 2.6)lo que permite configurar una gua de estilo con talparametrizacin.

El desarrollador selecciona las clases que desea emplear desde un modelode clases en Rational Rose y selecciona qu gua de estilo emplear. La guade estilo asegura la uniformidad de la presentacin en la interfaz de usuariogenerada.

La generacin de cdigo de Genova soporta las siguientes plataformas des-tino: Java, C++, Visual Basic and HTML.

3AIO. (Abstract Interaction Object) Objeto abstracto de interfaz [Vanderdonckt93] frente a CIO(Concrete Interaction Object) Objeto concreto de interaccin, tambin llamado control o widget. Am-bos se discutirn ms adelante con mayor precisin.


Figura 2.5: Parmetros de diseo en Genova 1/2.

2.1.3. Conclusiones sobre las herramientas comerciales

Las herramientas de tipo RAD para el desarrollo de interfaces de usuariosuelen aparecer integradas dentro de IDE (Delphi, Visual Basic, Eclipse, VisualStudio .Net, etc.) de lenguajes de tercera generacin. En estas herramientas deprogramacin, el desarrollo de la interfaz de usuario se realiza a un nivel dediseo. La experiencia del diseador es crucial para obtener interfaces de altacalidad. Las interfaces diseadas de este modo son dependientes de un lengua-je de programacin o librera de controles dada, dificultando la portabilidad aotros entornos.

Por otro lado, las principales herramientas de modelado que incrementanel nivel de abstraccin como son Rational Rose, Together, Argo UML, SystemArchitect basadas en UML no proporcionan mecanismos para la especificacinde interfaces. Cabe mencionar que, el modelado realizado con estas herramien-tas, es ms cercano al modelado de cdigo que al modelado conceptual ya quemuchas introducen dependencias del lenguaje destino en la especificacin, im-posibilitando de este modo la generacin a otras plataformas.

Un segundo tipo de herramientas hbridas como Cool:Plex y ezWay intro-ducen diseadores de interfaces de usuario. Si bien, el primero slo permiteespecificar la esttica de la interfaz de usuario. Y el segundo es dependiente delos lenguajes destino Visual Basic y ASP.

Por ltimo, Genova introduce un Modelo de Dilogo y de Presentacin si-guiendo las ideas de Vanderdonckt [Vanderdonckt93]. Probablemente, Genova


Figura 2.6: Parmetros de diseo en Genova 2/2.

es la herramienta comercial ms avanzada para la generacin de Interfaz deUsuario a partir de modelos UML.4

Genova proporciona un control razonable sobre los parmetros de gene-racin. Sin embargo, al ser un mdulo de extensin a Rational Rose, los mo-delos de dilogo se almacenan de modo separado al modelo UML raz. Estopuede provocar problemas de sincronizacin y de desfase de versiones cuan-do el modelo UML cambia y los Modelos de Dilogo asociados no lo hacen. Lageneracin producida por Genova est basada en pantallas y est orientada ala invocacin de uno o ms mtodos.

A la vista de la revisin a la tecnologa, podemos concluir que no existenherramientas que complementen el modelado conceptual y el modelado deinterfaz de usuario a nivel conceptual (independiente de plataforma destino)de una manera completamente integrada.

Disponer de un nico modelo capaz de contener la descripcin de estructura, com-portamiento, funcionalidad e interfaz de usuario se convierte en un objetivo de primerorden perseguido por la presente tesis.

2.2. Modelos para la especificacin de Interfaces deUsuario

Las herramientas del mbito acadmico ponen el nfasis en la especi-ficacin de la interfaz de usuario. Dejando de lado los detalles de imple-

4Rational Rose por s solo, no proporciona ningn soporte para la Interfaz de Usuario.


mentacin, se centran en la captura declarativa del comportamiento espera-do del sistema. Una vez completado el anlisis, algunas de las herramientasplantean la posibilidad de generar cdigo para prototipos en uno o ms lengua-jes destino.

Algunos de los trabajos presentados pueden ser denominados como MB-UIDE,5 como evolucin de los UIMS.6

En esta seccin se describirn los trabajos ms relevantes y se compararla informacin que cada uno de ellos recopila. Dicha informacin es vital parala fase de generacin de interfaces de usuario, ya que la idoneidad, completi-tud y no-ambigedad de la informacin condicionan fuertemente qu puedegenerarse automticamente y qu no.

A continuacin, se describirn los trabajos relacionados en el campo de es-pecificacin de interfaz de usuario. En particular, nos detendremos en describirUIDE, JANUS, TRIDENT, OVID, UMLi, CTT, MOBI-D y Wisdom.

2.2.1. UIDE

UIDE es un entorno que permite al analista indicar los requisitos de interfazde un sistema y disear la interfaz de usuario a un nivel de abstraccin elevado.UIDE dispone de herramientas adicionales para evaluar la calidad del diseo,generar prototipos de interfaz, etc.

UIDE (User Interface Design Environment) [Foley91] es un sistema sopor-tado por una base de conocimiento para asistir en el proceso de diseo, eva-luacin e implementacin de la interfaz de usuario. UIDE recoge una repre-sentacin conceptual del diseo de la interfaz de usuario y proporciona unconjunto de herramientas para disear, analizar e implementar interfaces deusuario al mismo nivel que las herramientas CASE soportan tareas de inge-niera del software. Esta aproximacin encuadra a UIDE dentro del campogeneral de los Sistemas Gestores de Interfaz de Usuario UIMS User InterfaceManagement Systems.

Un UIMS tpico permite al diseador:

Especificar la organizacin de las ventanas, iconos y mens.

Crear la ayuda y mensajes de error.

Seleccionar tcnicas de interaccin alternativas, tales como lenguaje decomandos, mens estticos o mens emergentes (pop-up menus).

5Model based-User Interface Development Environment Entornos de desarrollo de interfaces deusuario basados en modelos.

6User Interface Management Systems Sistemas de gestin de interfaces de usuario.


Especificar la secuencia de acciones del usuario.

Especificar los nombres de los procedimientos a invocar por el UIMScuando un comando y sus parmetros han sido introducidos por el usua-rio.

Los UIMS clsicos tienen un nivel de abstraccin muy bajo, tal y comoocurre en la programacin visual, donde se manipulan directamente los ele-mentos de implementacin (controles) de la interfaz final. UIDE intenta incre-mentar el nivel de abstraccin de un modo notable.

La base de conocimiento de UIDE contiene la siguiente informacin:

Jerarqua de clases de objetos que existen en el sistema.

Propiedades de los objetos (meta-data).

Acciones que pueden realizarse sobre los objetos.

Unidades de informacin requeridas por las acciones (argumentos).

Pre- y post-condiciones sobre las acciones.

La informacin recogida en la base de conocimiento (vase la Figura 2.7)puede emplearse para:

Comprobar la consistencia y completitud del diseo.

Transformar la base de conocimiento e incluso la interfaz de usuario querepresenta en otra distinta pero funcionalmente equivalente a travs deun conjunto de algoritmos de transformacin.

Evaluar la bondad (calidad) del diseo.

Disear la disposicin de mens y cajas de dilogo.

Elegir tcnicas de interaccin apropiadas.

Generacin automtica de mecanismos de ayuda inteligente con ani-macin.

Mantener un modelo del conocimiento del usuario acerca de la aplica-cin, para facilitar el trabajo a la ayuda inteligente.

Implementar macros y capacidades deshacer/rehacer (undo/redo).

Proporcionar entrada a SUIMS, un simple UIMS que implementa la in-terfaz de usuario a modo de prototipo.


Base de Conocimientode Diseo

Entorno de Diseo deInterfaz de Usuario

UIDE

Interfaz de UsuarioSUIMS

Diseador delinterfaz de usuario

Usuario de laaplicacin

Funciones de laAplicacin

Comprobacin deConsistencia / Completitud

Algoritmos detransformacin

Tecnicas de interaccin

Algoritmos de Evaluacin

Estructura de Menus /Diseo cajas de dialogos

MacroComandos

Undo / Redo

Modelo de Usuario

Ayuda Inteligente

Figura 2.7: Arquitectura de UIDE (adaptado de [Foley91]).


El mdulo que interacciona con el usuario, SUIMS sigue el siguiente ciclode ejecucin:

Establece y actualiza el contenido de la pantalla.

Comprueba todas la precondiciones y reconoce las acciones que estndisponibles.

Acepta una accin seleccionada por el usuario.

Procesa cada parmetro de acuerdo a su tipo (explcito, implcito, etc.).

Acepta los valores de los parmetros en un orden arbitrario, usando cua-lesquiera de las tcnicas de interaccin disponibles.

Confirma implcitamente la accin (si se suministra toda la informacinnecesaria), confirma explcitamente (si as se requiere) o cancela la accin.

Ejecuta la accin.

Evala las post-condiciones.

SUIMS identifica siete tareas de interaccin:

Seleccin de comando.

Seleccin de clase.

Seleccin de instancia.

Seleccin de atributo.

Seleccin de posicin.

Entrada de texto.

Entrada entera (argumento de tipo entero).

Para llevarlas a cabo, emplea las llamadas tcnicas de interaccin. Por ejem-plo, las tcnicas de interaccin apuntar, introduccin de texto y seleccin de menpueden usarse para llevar a cabo la tarea de interaccin seleccin de instancia.No hay restricciones para indicar qu tcnicas de interaccin pueden ser em-pleadas en cada tarea de interaccin. Si no se selecciona ninguna, es obvio quela tarea no podr llevarse a cabo. Si estn activadas ms de una, el usuariopuede elegir la que le resulte ms cmoda.

UIDE se apoya en un modelo de datos (base de conocimiento) para abor-dar desde un punto de vista formal la especificacin de interfaz. Mediante unaaproximacin cercana a los principios del modelo orientado a objetos, se recoge


la estructura y la semntica del sistema a modelar con un modelo de datos, loque permite disponer de una base de conocimiento o informacin centralizadadel sistema a partir de la cual se pueden extraer conclusiones as como propo-ner implementaciones a la interfaz de usuario.

UIDE constituye una de las primeras herramientas MB-UIDE7 de primerageneracin que ha servido como referencia a muchas otras posteriores. UIDEsolo soporta el modelo de dominio, careciendo de modelos de tareas, presen-tacin, dialogo o de usuarios.

2.2.2. JANUS

JANUS [Balzert96] es un trabajo de la Universidad de Ruhr en Alemania.Partiendo del Anlisis Orientado a Objetos (OOA) [Coad91], genera parte de lainterfaz de usuario asociada. El modelo de configuracin de clases empleadorecoge clases (con mtodos y atributos) y relaciones (agregacin y herencia). Apartir de esta informacin que debe haber sido recopilada con la ayuda de unaherramienta CASE, JANUS es capaz de generar, por ejemplo:

Un formulario por cada clase para representar una instancia de objeto,con controles para cada atributo y botones par cada mtodo de la clase.

Un formulario por cada clase para mostrar conjuntos de objetos de unamisma clase con una rejilla que contiene tantas columnas como atributostiene la clase y botones para lanzar los mtodos de la clase.

El mtodo OOA proporciona un anlisis del sistema pero no captura requi-sitos de interfaz de usuario propiamente dicho, se apoya solo en el modelo dedatos. Esta carencia de informacin acerca de los requisitos de la interfaz deusuario provocan que la interfaz generada por JANUS no sea muy refinada yslo contemple la parte de dilogo (parcialmente) de la interfaz.

2.2.3. TRIDENT

TRIDENT8 [Bodart93, Bodart95d, Bodart95a, Bodart95b, Bodart96] es unproyecto desarrollado en la Universidad de Namur, que propone un modelode arquitectura para el desarrollo de aplicaciones de gestin interactivas.

El principal objetivo de TRIDENT es permitir al diseador de interfaz gene-rar, de modo automtico, tanto como sea posible, a partir de una especificacin

7Model-Based User Interface Design Environment. Entornos de diseo de interfaces de usuariobasados en modelos.

8TRIDENT: (Tools foR an Interactive Development EnvironmeNT)


Figura 2.8: Interfaz de la herramienta SEGUIA.

descrita a travs de diversos modelos (tales como: modelos de tareas o mode-los de entidad-relacin orientados a objetos). Aspectos como la seleccin de loselementos de presentacin, eleccin de objetos de interaccin apropiados, dis-tribucin en pantalla de los objetos de interaccin, secuenciacin de dilogos yconversacin bsica quedan resueltos con esta aproximacin.

TRIDENT emplea anlisis de requisitos funcionales y anlisis de tareas. Apartir del primero se obtiene un modelo entidad-relacin extendido. El anli-sis de tareas se realiza construyendo ACG (Grafos encadenados de actividad,Activity Chain Graphs) que ligan las tareas interactivas del usuario con la fun-cionalidad del sistema.

Una de las principales aportaciones de TRIDENT al campo de la especifi-cacin de interfaces de usuario es la introduccin de del concepto de AIO (Abs-tract Interaction Object) como abstraccin de CIO (Concrete Interaction Object) ocontrol.

SEGUIA (System Export for Generating a User Interface Automatically)[Vanderdonckt99a, Vanderdonckt99b] es un generador de interfaces a partirde modelos construidos por TRIDENT.9 SEGUIA contiene un sistema expertoque selecciona mediante reglas y heursticos la mejor traduccin de AIO a CIOen el proceso de generacin adems de soportar la disposicin y el alineado delos CIO en ventanas y cajas de dilogo (vase Figura 2.8).

Grafos encadenados de actividad

Uno de los resultados derivados del anlisis de tareas es un modelo quedescribe las tareas interactivas que el usuario tiene que realizar. Este modelo

9Vase http://www.inyo.ucl.ac.be/bchi/research/seguia .

http://www.inyo.ucl.ac.be/bchi/research/seguia


Nombre

Apellido

Calle, Nmero,CP, Ciudad

Cdigo_Cliente

Nombre

Apellido

Nuevo_Cliente

Cdigo_Cliente

Cliente_Vlido

Error

Cliente_Vlido



Cliente_Vlido

Error

Cli_por_cdigo

Cli_por_nombre

Modificar_Direccin

Fecha

Modo

Salvar_Cliente

= OR

= AND

= XOR

Figura 2.9: Ejemplo de diagrama ACG (adaptado de [Bodart95d]).

puede representarse grficamente mediante un grafo encadenado de actividado (ACG). Un ACG despieza un flujo de informacin en funciones encadenadaspara definir una lgica de negocio para alcanzar los objetivos asignados a latarea interactiva.

Un ejemplo de ACG para una tarea interactiva10 Salvar_Cliente se muestraen la Figura 2.9. Cada funcin recibe informacin de entrada que representa lainformacin necesaria para la correcta ejecucin de la funcin. Por ejemplo, lainformacin Nombre, Apellido, Direccin debe proporcionarse para permitir laejecucin de Nuevo_Cliente. Cada funcin produce informacin de salida quepuede ir destinada al usuario (por ejemplo: Cdigo_Cliente) o, por el contrario,ser interna e ir destinada como informacin de entrada para otra funcin (porejemplo: Cliente_Vlido). La terminacin de la ejecucin de una funcin per-mite que el encadenamiento de funciones progrese un paso ms en el AGC.La entrada de informacin, la visualizacin de resultados y el encadenamientode funciones es compatible con enlaces OR(representados sin arco), AND(arcossimples) y XOR(dobles arcos). Por ejemplo, el enlace ANDentre Nombre, Apelli-do y Direccin indica que toda la informacin es necesaria; el enlace XORentreError y el conjunto de informaciones Cliente_Valido y Direccin significa queuno de los dos, el mensaje de error o la combinacin de las informaciones sergenerado.

10El ejemplo descrito de ACG es una traduccin libre del ejemplo original descrito en[Bodart95d].


Diseo de la presentacin

La construccin de los componentes de la interfaz de usuario se basa en lossiguientes conceptos:

CIO (Concrete Interaction Object): Es un objeto real, un control pertene-ciente al mundo de la interfaz de usuario que cualquier usuario puedemanipular, como un botn de comando, una lista, una casilla de verifi-cacin. Un CIO es compuesto si se puede descomponer en unidades mspequeas y es simple si no puede ser descompuesto.

AIO (Abstract Interaction Object): Son la abstraccin de todos los CIO des-de el punto de vista de la presentacin y de comportamiento, independi-entemente del entorno final de implementacin.

Ventana (Window): Es la ventana raz que puede considerarse como unaventana lgica para los AIO y como ventana fsica, caja de dilogo o panelpara CIO. Cada ventana es por s misma un CIO compuesto de otros CIOsimples o compuestos a su vez. Todas las ventanas estn geogrficamentedelimitadas en la ventana del usuario.

PU (Presentation Unit): Constituyen la parte encargada de llevar a cabo laentrada y visualizacin de los datos de cualquier subtarea de una tareainteractiva. Cada unidad de presentacin puede descomponerse en unao ms ventanas que pueden no aparecer en pantalla simultneamente.Cada PU est compuesta por, al menos, una ventana llamada ventanabase, a partir de la cual el resto estn encadenadas.

Siguiendo el ACG descrito en la Figura 2.9, el usuario puede aadir nuevosclientes o modificar clientes previamente existentes. Para localizar clientes exis-tentes, stos pueden ser localizados en una base de datos a partir de un c-digo de identificacin o a partir del nombre y el apellido. Por lo tanto, dosunidades de presentacin deben ser identificadas: una PU1 que cubra las fun-ciones de Nuevo_Cliente, Cliente_por_Cdigo, Cliente_por_Nombre y Modi-ficar_Direccin y otro PU2 que cubra la funcin Salvar_Cliente.

De acuerdo al ACG, PU1 puede ser dividido en siete ventanas:

1. Una caja de dilogo W11 que permita al usuario seleccionar de entre lastres alternativas (nuevo cliente o cliente existente, identificado en esteltimo caso por nombre o por cdigo). Vase Figura 2.10.

2. Una ventana W12 que permita al usuario aadir un nuevo cliente pro-porcionando toda la informacin necesaria. Vase Figura 2.11.


Figura 2.10: Presentacin de la ventana W11 (adaptado de [Bodart95d]).




IO Simple

1-n1-n

Tarea interactiva

Unidad dePresentacin

Ventana

1-n1-n

1-n1-n

1-n1-n

IO Compuesto

IO Simple

1-n 1-n

Figura 2.15: Estructura de la presentacin en TRIDENT (adaptado de[Bodart95d]).

3. Un mensaje de error W13 para alertar al usuario siempre que falte infor-macin en la ventana W12. Vase Figura 2.12.

4. Una ventana W14 que permita al usuario buscar un cliente por su cdigoy modificarlo cuando sea necesario. Vase Figura 2.13.

5. Un mensaje W15 de alerta cuando el cdigo suministrado no correspon-da a un cliente existente en la base de datos. Vase Figura 2.14.

6. Una ventana W16 para realizar bsquedas de clientes por el nombre y elapellido, adems de permitir su modificacin cuando sea necesario (si-milar a W14).

7. Un mensaje W17 que alerte al usuario cuando se proporcione un nombrey apellido que no corresponda a un cliente existente (similar a W15).

Del mismo modo al indicado, la unidad de presentacin PU2 puede com-ponerse de una ventana W21 para permitir la introduccin de Modo y Fechaantes de recoger finalmente el Cliente (vase Figura 2.9). Esta aproximacin de-fine una presentacin por refinamientos iterativos empezando desde los ob-jetos generales hasta acabar en objetos terminales de acuerdo a la estructuramostrada en la Figura 2.15.

Dicha estructura de presentacin consiste en una jerarqua de CIO para ca-da tarea interactiva (IT). La Tabla 2.1 presenta a modo de resumen la estructurade la presentacin del ejemplo descrito con el nombre del CIO empleado entreparntesis.


IT_Salvar_Cliente

PU1_Identificar_un_Cliente

W11_Identificacin_de_Cliente (caja de dilogo)

Tipo_de_Cliente (botn de radio)

Busqueda_de_Cliente_Existente (botn de radio)

Aceptar (botn de comando)

Cancelar (botn de comando)

W12_Nuevo_Cliente (ventana)

Nombre (caja de edicin)

Apellido (caja de edicin)

Direccin (grupo)

Calle (caja de edicin)

...

Salvar, Borrar, Aceptar,

Cancelar (botones de comando)

W13_Campo_Faltante (mensaje de error)

W14_Bsqueda_por_Cdigo (ventana)

...

W15_Cdigo_Inexistente (mensaje de alerta)

W16_Bsqueda_por_nombre (ventana)

...

W17_Nombre_Inexistente (mensaje de alerta)

PU2_Almacenar_Cliente

W21_Entrada_Final (caja de dilogo)

Modo (caja de edicin)

Fecha (caja de edicin)

Tabla 2.1: Representacin textual de la estructura de la presentacin en TRI-DENT (adaptado de [Bodart95d]).


CO

IOAO

= Uses

Figura 2.16: Esquema genrico de la arquitectura de TRIDENT (adaptado de[Bodart95d]).

Modelo de la arquitectura

El modelo de arquitectura propuesto para TRIDENT [Bodart95d] consisteen una jerarqua de los elementos genricos ilustrados en la Figura 2.16.

El modelo de arquitectura se compone de tres clases de objetos cuya des-cripcin es la siguiente:

1. La clase Control Objects (CO) es una clase genrica que se descomponeen diversos CO de diferentes tipos para manejar el dilogo y aseguraruna correspondencia entre las estructuras de datos de la aplicacin y laspertenecientes a la presentacin. Cada CO es responsable de la gestin deuna porcin del dilogo y de realizar la correspondencia en esa porcinentre la aplicacin y la presentacin. El comportamiento del CO tomala forma de un script escrito en un lenguaje de reglas y puede ser par-cialmente representado grficamente con un diagrama de transicin deestados.

2. La clase Application Objects (AO) es una clase que no puede ser descom-puesta puesto que sus elementos representan las funciones de la apli-cacin. Es importante asegurar que las funciones necesarias estn inclui-das en la arquitectura, ya que los requerimientos funcionales desempe-an un papel importante en la asignacin de significado semntico a lastareas interactivas y a sus respectivas subtareas.

3. La clase Interaction Objects (IO) es una clase genrica que contiene dostipos de CIO: CIO encargados de realizar la entrada/salida de informa-cin y CIO que estn estrictamente implicados en el dilogo (por ejemplo,los botones que disparan las funciones).


La arquitectura de TRIDENT se descompone en tres conceptos (como enMVC11 [Goldberg83, Bergin02] y PAC12 [Coutaz87].) La jerarqua de descom-posicin en TRIDENT es jerrquica a tres niveles, la descomposicin de losconceptos esta limitada nivel por nivel. Por en contrario, en PAC, todos losaspectos pueden ser descompuestos jerrquicamente de modo simultaneo.

Las reglas que gobiernan el comportamiento de estas tres clases de objetosson idnticas, del mismo modo que las relaciones permitidas entre cualquierpar de objetos en esta jerarqua. Cada objeto es un agente. Si una flecha uneun objeto padre con un objeto hijo cualesquiera, se establece una relacin entreellos indicando que el objeto padre usa al objeto hijo. Con ms detalle:

Un objeto hijo enva al objeto padre eventos relacionados con el compor-tamiento de los estados significativos.

Un objeto padre invoca las primitivas ofertadas por el objeto hijo paraobtener informacin necesaria para llevar a cabo los pasos del compor-tamiento que tiene programado.

Veamos con ms detalle cada uno de los componentes:

AO. Objetos de aplicacin Representan componentes particulares de apli-cacin en el sentido de que, para cada funcin que aparece en el ACG,existe un correspondiente AO en la jerarqua. Si la aplicacin actual yaexiste y est escrita con un lenguaje no orientado a objetos pero se pre-tende reutilizarla, entonces, cada funcin ser encapsulada en un nuevoobjeto AO donde el cdigo de la funcin ser uno de los mtodos delobjeto. Si por el contrario, la aplicacin es nueva, se escribir en algnlenguaje orientado a objetos y se crear un nuevo AO por cada funcinde aplicacin.

En cualquier caso, el conjunto de todos los objetos de clase AO constituyela mquina funcional. La funcin de disparo perteneciente a esta mquinafuncional determina la lgica funcional de negocio representada por eldiagrama ACG. Cada AO de la jerarqua propuesta es siempre un objetohijo de un y slo un objeto de control (CO), el cual es responsable dellevar a cabo la funcin comn.

CO. Objetos de control Son los responsables de manejar otro componente deinterfaz en el sentido de que para cada paso a dar para llevar a cabo lacomposicin de la presentacin, existe el correspondiente CO en la jerar-qua. La composicin de las presentaciones permite ocultar el concepto

11ModeloVistaControlador, (ModelViewControler).12Presentation, Abstraction & Control.


de ventanas (que son dinmicamente secuenciadas) bajo el concepto deunidades de presentacin. Las distintas unidades de presentacin se ma-terializan en el contexto requerido para llevar a cabo su tarea de interac-cin. La jerarqua de CO puede construirse a partir del mismo esquema,por lo que los siguientes CO son de utilidad:

CO-IT: el nico objeto de control correspondiente a la tarea interac-tiva (interactive task).

CO-PU: los objetos de control correspondientes a las unidades depresentacin (presentation units).

CO-W: el objeto de control correspondiente a la ventana (window).

CO-Fc: los objetos de control correspondientes a las funciones de laaplicacin (application functions).

Cada CO correspondiente a una funcin de aplicacin (CO-Fc) es un ob-jeto hijo de un objeto de control ventana (CO-W) que alberga a todos losCIO necesarios para lanzar la funcin o servicio asociado en la mquinafuncional.

IO. Objetos de interaccin Los IO constituyen la interfaz de usuario propia-mente dicha, de un lado los controles de entrada/salida IO-I/O (in-put/ output interaction objects) y, por otro lado, los elementos de control(botones, iconos, etc.) denominados IO-P (presentation interaction objects).

Estos objetos que son seleccionados por un sistema experto [Bodart94],son equivalentes a los CIO y pertenecen a entornos fsicos como Win-dows, OSF/Motif, OS/2 Presentation Manager, etc.

Cada IO, bien sea IO-I/O o IO-P, es un objeto hijo de un objeto de controlde funcin (CO-F), los cuales envan eventos que representan los cam-bios de estado significativos. Adems, tienen definidas primitivas parapermitir que el objeto padre pueda interrogar su estado. En las imple-mentaciones, la mayor parte de las veces, estas primitivas son mtodosnativos proporcionados por las libreras de controles empleadas.

Semntica de las relaciones en la arquitectura

La semntica de las relaciones involucradas en la arquitectura (vase la Figu-ra 2.17) es la siguiente:

Semntica de la relacin CO-IT CO-PU: El objeto de control correspon-diente a la tarea interactiva (CO-IT) gestiona el cambio dinmico deunidades de presentacin, que carga y descarga (de modo secuencial oconcurrente) cada PUi de acuerdo a los eventos recibidos de un PUj .


IO-Comp

IO-PIO-I/O

1-10-n

1-10-n

0-n0-n

1-11-n

CO-IT

CO-PU

CO-W

1-11-n

1-11-1

1-11-1

CO-Fc

AO

1-1 0-n

0-n0-n

Figura 2.17: Relaciones entre los Objetos de Control en TRIDENT (adaptado de[Bodart95d]).


Semntica de la relacin CO-PU CO-W: El objeto de control correspondi-ente a una unidad de presentacin (CO-PU) gestiona el cambio dinmicode las ventanas, que muestra u oculta la ventana Wi de acuerdo a loseventos recibidos desde otra ventana Wj .

Semntica de la relacin CO-W CO-Fc: El objeto de control correspondi-ente a una ventana (CO-W) invoca al objeto de control correspondiente ala funcin de aplicacin cuando todas las condiciones requeridas por estallamada son completadas, sto es, cuando toda la informacin necesariapara realizar la funcin est disponible en los objetos hijos de CO-W. ElCO correspondiente a la funcin de aplicacin (CO-Fc) enva al CO-W unevento alertando de la terminacin del proceso.

Semntica de las relaciones recursivas entre CO-Fc: Los CO asociados a lasfunciones de aplicacin intercambian eventos entre ellos mismos paramantener la dinmica del ACG consistente y se llaman mutuamente asus servicios para intercambiar estas informaciones.

Semntica de las relaciones entre IO . . . y CO-W: Los IO, sean IO-I/O o IO-P, son los objetos que directamente atienden las reacciones del usuario.Los IO generan eventos destinados a su padre cuando el estado cambia.Los objetos padre llaman a los servicios ofertados por los IO para conocerque acciones han sido realizadas por el usuario.

La clave en la arquitectura TRIDENT consiste en ofertar algoritmos paraconvertir adecuadamente el diagrama ACG en una jerarqua compuesta porlos objetos y relaciones de agente anteriormente descritas. La propia arqui-tectura separa claramente la interfaz de la funcionalidad, encapsulando dichafuncionalidad en el conjunto de AIO que forman la denominada mquina fun-cional.

Los conceptos de AIO, CIO y Unidad de Presentacin se han revelado comoabstracciones muy tiles a la hora de abordar el problema de la interfaz deusuario.

Por otro lado, la experiencia con TRIDENT [Bodart95d] evidencia que elmodelo ofrece buenos resultados sobre aplicaciones de gestin de complejidadmoderada sin requerimientos de tiempo real. TRIDENT no es un modelo depropsito general.

El analista tiene ahora la nueva responsabilidad de realizar el anlisis detareas y de generar los correspondientes diagramas ACG. Dependiendo de lacalidad del anlisis realizado, la interfaz se ajustar en mayor o menor grado alo esperado.


Figura 2.18: Diagrama de clases decorado con vistas [Roberts98].

En resumen, TRIDENT es una herramienta de referencia dentro del mundode herramientas para el diseo de interfaces de usuario soportadas en modelos.En este proyecto se asentaron las bases de los conceptos de AIO, CIO y Unidadde Presentacin. Dada la importancia y el uso que de dichos conceptos se haceen esta tesis, se ha considerado conveniente proporcionar una revisin msdetallada de esta herramienta frente a otras tambin consideradas.

2.2.4. OVID

OVID [Roberts98] (Objects, Views, and Interaction Designs, Objetos, vistas ydiseos de interaccin) es una extensin a UML para abordar el modelado deinterfaces de usuario.

Usando el concepto de estereotipo definido en UML, en OVID se define elconcepto de vista View como un estereotipo de clase (vase Figura 2.18). Unavista es una presentacin de un objeto perteneciente a una clase dada. A partirde modelos UML anotados con vistas, los diseadores pueden prototipar demodo manual la vista (vase Figura 2.19).


Figura 2.19: Boceto en papel de la vista correspondiente a una habitacin dehotel [Roberts98].

Figura 2.20: Ejemplo de interfaz a modelar [Silva02].


Figura 2.21: Dominio de aplicacin [Silva02].

OVID es el primer mtodo que se propone extender UML para la especi-ficacin de interfaces orientadas a objetos. Sin embargo, la especificacin espoco formal y la correspondencia entre las vistas y la implementacin se dejatotalmente abierta a criterio del diseador.

2.2.5. UMLi

UMLi [Silva02, Silva01] es el trabajo de investigacin de Paulo Pinheiro daSilva para extender UML con conceptos y diagramas para abordar la especifi-cacin de interfaces de usuario en UML.

La Figura 2.20 muestra un ejemplo de interfaz de usuario a modelar. En lassucesivas figuras se muestran los diagramas asociados a la especificacin deeste ejemplo.

El modelo de dominio (vase Figura 2.21) muestra un anlisis orientado aobjetos clsico de las clases de anlisis participantes en el sistema.

UMLi introduce un nuevo diagrama: El diagrama de presentacin de inter-faz de usuario (vase un ejemplo en la Figura 2.22) Las primitivas de este diagra-ma se denominan Primitive Interaction Objects y son las siguientes:

Inputter. Representa un campo de entrada donde el usuario proporciona


Figura 2.22: Presentacin de interfaz de usuario [Silva02].

informacin al sistema. Se representa grficamente mediante un tringu-lo issceles invertido 5.

Displayer. Representa un campo de salida donde el sistema proporcionainformacin al usuario. Se representa grficamente mediante un tringu-lo issceles 4.

Editor. Es una primitiva compuesta: se comporta como Inputter y Dis-player al mismo tiempo. Se representa mediante un rombo .

Container. Representa un contenedor de objetos de interaccin. Un con-tenedor puede contener a otros contenedores. Se representa mediante uncilindro de trazo discontinuo.

FreeContainer. Representa un contenedor de primer nivel, es decir, nopuede estar contenido dentro de otro contenedor. Se representa medianteun prisma de trazo discontinuo.

Tambin se introducen una serie de estereotipos para extender la interac-cin de flujo entre objetos en los Diagramas de Actividad (vase Figura 2.23):

presents Conecta un FreeContainer con una actividad, indicando quela actividad es activada cuando se presenta la interfaz descrita por elFreeContainer.


Figura 2.23: Modelo de comportamiento [Silva02].

interacts Conecta un Inputer, Displayer o Editor con una tarea. Indicaque la tarea est ligada a la interaccin con estas primitivas.

cancels Relaciona una tarea con un ActionInkover. Representa que laaccin del usuario cancela la tarea en curso.

activatesPara disparar una tarea.

Por ltimo, se introducen estereotipos a los estados, denominados Selection-States, tambin para los Diagramas de Actividad:

OrderIndepenceState Indica independencia de orden. Se representagrficamente mediante el smbolo .

OptionalState Indica opcionalidad. Se representa grficamente medi-ante el smbolo .

RepeatableState Indica posibilidad de repeticin. Se representa grfi-camente mediante el smbolo .

Las Figuras 2.21, 2.22 y 2.23 muestran cmo queda la especificacin delejemplo mostrado en la Figura 2.20.

UMLi constituye el primer intento serio de extender UML para capturar lainterfaz de usuario de un modo formal. Sin embargo, la fina granularidad delos conceptos manejados conlleva problemas graves de escalabilidad. Los pro-blemas de tamao medio se tornan complejos y tediosos de especificar (vase


Figura 2.24: Categoras de tareas en ConcurTaskTrees [Patern00].

Ley de Novak, en la pgina 98), lo cual dificulta en gran medida su adopcin enentornos de desarrollo industriales.

Por otro lado, las primitivas empleadas son tiles para describir los inter-faces WIMP. Para otro tipo de interfaces como las interfaces grficas, las primi-tivas pueden no ser las adecuadas para representarlas.

2.2.6. CTT

ConcurTaskTree [Patern00] es una notacin ampliamente aceptada en elcampo de la especificacin de Modelos de Tareas. La notacin est soportadapor el lenguaje formal LOTOS [ISO88]. Fabio Patern y su equipo en el CNUCECNR de Pisa han desarrollado una herramienta CASE (ConcurTaskTree Environ-ment [Patern02]) que soporta el diagramado con esta notacin.

La notacin define cuatro categoras de tareas:

Tareas de usuario: (User Tasks) Tareas llevadas a cabo por el usuario. Nor-malmente son actividades cognitivas, como pensar una estrategia pararesolver un problema.

Tareas de aplicacin: (Application Tasks) Tareas realizadas por la apli-cacin. E.g., presentar una serie de resultados al usuario.

Tareas de interaccin: (Interaction Tasks) Tareas realizadas por el usuarioal interactuar con el sistema. E.g., pulsar un botn o una tecla.

Tareas abstractas: (Abstract Tasks) Tareas que requieren actividades com-plejas y que pueden ser descompuestas en otras ms sencillas.

ConcurTaskTree usa una representacin grfica para cada categora de ta-reas como muestra la Figura 2.24.

Una tarea puede ser descompuesta en subtareas. Las subtareas estn rela-cionadas entre s por medio de relaciones temporales. La notacin ConcurTask-Trees proporciona un conjunto de operadores temporales basados en la semn-tica del lenguaje LOTOS. Los operadores aparecen descritos en las Tablas 2.2y 2.3.


Operador DescripcinOcurrencia independiente(T1|||T2)

Las tareas pueden acontecer en cualquier orden sinrestriccin. E.g. monitorizar una pantalla y hablarpor un micrfono.

Independencia de orden(T1| = |T2)

Las subtareas pueden acontecer en cualquier ordenpero no al mismo tiempo.

Alternativa(T1[ ]T2)

Eleccin entre un conjunto de tareas. Una vez se haseleccionado una tarea, el resto de tareas no estarndisponibles hasta que la tarea seleccionada haya si-do completada. E.g. al iniciar un procesador de tex-tos, el usuario puede abrir un documento existenteo crear uno nuevo.

Concurrencia con inter-cambio de informacin(T1|[ ]|T2)

Dos tareas pueden ejecutarse concurrentementepero han de sincronizarse para intercambiar infor-macin. E.g. en un procesador de texto el usuariopuede editar y desplazar verticalmente el texto encualquier orden. Sin embargo, slo es posible editarla informacin que es visible en la regin actual.

Desactivacin(T1[> T2)

La tarea T1 es definitivamente desactivada unavez que la primera accin de la segunda tarea T2comienza. Este concepto es usado en las interfacesde usuario cuando el usuario puede deshabilitar unconjunto de tareas y habilitar otro conjunto. E.g. traspulsar un botn.

Habilitar(T1 >&g

Tesis doctoral. Interfaz de usuario: de la especificación a la ...

Documents

Transcript of Tesis doctoral. Interfaz de usuario: de la especificación a la ...