1 / 71

A MDA-Compliant Environment for Developing User Interfaces of Information Systems

A MDA-Compliant Environment for Developing User Interfaces of Information Systems. Jean Vanderdonckt vanderdonckt@isys.ucl.ac.be Head of BCHI Lab, http://www.isys.ucl.ac.be/bchi. « Everything you can imagine is real » (Picasso). « Everything you model can be turned into a real interface ».

amiel
Télécharger la présentation

A MDA-Compliant Environment for Developing User Interfaces of Information Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A MDA-Compliant Environment for Developing User Interfaces of Information Systems Jean Vanderdonckt vanderdonckt@isys.ucl.ac.be Head of BCHI Lab, http://www.isys.ucl.ac.be/bchi CAiSE'2005 Keynote address - Porto, June 16, 2005

  2. « Everything you can imagine is real » (Picasso) « Everything you model can be turned into a real interface » CAiSE'2005 Keynote address - Porto, June 16, 2005

  3. Outline • Conceptual modeling of user interfaces • Forward engineering • Reverse engineering • Lateral engineering • Conclusion CAiSE'2005 Keynote address - Porto, June 16, 2005

  4. 1.1 Why is conceptual modeling of user interfaces desirable? • “The presentation layer outside the scope of CSCD” (Antoni Olivé) • A domain model is certainly not a presentation model, but there could be a mapping between • UIs remained for many years the poor parent of conceptual modeling and software engineering • It emerged during late 80’s • Still growing • The complexity and the variety of user interfaces (UI) is dramatically increasing • The paradigm of « one system fits all » is no longer valid CAiSE'2005 Keynote address - Porto, June 16, 2005

  5. 1.1 Diversity of users • Traditional users • People with disabilities • Visual, motor, cognitive CAiSE'2005 Keynote address - Porto, June 16, 2005

  6. 1.1 Variety of tasks [Forrester Research, Inc., 2003] • Users want to determine their path on each platform CAiSE'2005 Keynote address - Porto, June 16, 2005

  7. 1.1 Heterogeneousness of platforms CAiSE'2005 Keynote address - Porto, June 16, 2005

  8. 1.1 Multiplicity of contexts of use CAiSE'2005 Keynote address - Porto, June 16, 2005

  9. Platform #1 Platform #2 Platform #3 Platform #4 Application 1 UI #1 UI #2 UI #3 UI #4 Application 2 UI #5 UI #6 UI #7 UI #8 Application 3 UI #9 UI #10 UI #11 UI #12 Platform model #1 Platform #1 UI model #1 Application 1 Platform model #2 Platform #2 UI model #2 Application 2 Platform model #3 Platform #3 UI model #3 Application 3 Platform model #4 Platform #4 1.1 Consequence • Proliferation of developments CAiSE'2005 Keynote address - Porto, June 16, 2005

  10. 1.1 Consequence • Why is it difficult? • For the designer: • Multiplicity of contexts of use • No systematic design method • For the user: • Poor usability of resulting UI • UI not adapted to the genuine context of use • For the developer: • Increase of development and maintenance costs • Increasing development complexity • Little of no factoring out of common elements Fold & Drop technique: P. Dragicevic CAiSE'2005 Keynote address - Porto, June 16, 2005

  11. 1.2 What does it cover? • Conceptual modeling should cover • Presentation: external manifestation of the UI that is perceivable to the user (static) • Dialog: ordering in time and space of operations performed by the user/system (dynamic) • Modalities of interaction • Graphical • Vocal • Haptic, tactile CAiSE'2005 Keynote address - Porto, June 16, 2005

  12. Platform Environment User Domain Task 1.2 What does it cover? CAiSE'2005 Keynote address - Porto, June 16, 2005

  13. 1.3 Abstraction #1: the concrete UI • Starting point: FUI = Final User Interface • Mark-up languages: HTML, WML, cHTML • Programming languages: Visual Basic, Java • Many manifestations of the same object • Abstraction with respect to the toolkit • Presentation aspects • Events: generating, passing, controlling • Attributes: external (e.g., font) vs internal (e.g. state) • Primitives: life cycle CAiSE'2005 Keynote address - Porto, June 16, 2005

  14. IO created IO displayed IO activated IO deactivated IO undisplayed IO destroyed PR_IO_Deactivate PR_IO_Create PR_IO_Display PR_IO_Activate PR_OI_Erase PR_OI_Destroy PR_IO_Activate PR_IO_ChangeAttribute 1.3 Abstraction #1: the concrete UI [Vanderdonckt & Bodart, 1993] • Definitions • Original: Abstract Interaction Object = abstraction of the same Concrete Interaction Objects independently of their underlying presentation and dialog • We have introduced this abstraction in 1993! • Current: Concrete Interaction Object = abstraction of interaction objects with respect to the underlying toolkit CAiSE'2005 Keynote address - Porto, June 16, 2005

  15. Each graphicalCIO has specific properties such as isVisible, isEnabled, fgColor, and bgColor. Each graphicalCIO is sub-typed into one of the two possible categories: graphicalContainer, and graphicalIndividualComponent CUI Model CIO graphicalCIO graphicalContainer graphicalContainer graphicalIndividualComponent graphicalIndividualComponent 1.3 Abstraction #1: the concrete UI [Limbourg, 2004] CUI Model CUI Model CIO CIO graphicalCIO graphicalCIO graphicalContainer graphicalContainer graphicalIndividualComponent graphicalIndividualComponent GrafiXML CAiSE'2005 Keynote address - Porto, June 16, 2005

  16. 1.3 Abstraction #2: the abstract UI • Different CIOs can be used for the same purpose, but with different interaction modalities • Definition • Abstract Container = set of Abstract Individual Component • AIC = abstraction of CIOs of the same type, but independently of any interaction modality • Abstract User Interface (AUI) = decomposition into AC+AIC CAiSE'2005 Keynote address - Porto, June 16, 2005

  17. 1.3 Abstraction #2: the abstract UI [Limbourg, 2004] CAiSE'2005 Keynote address - Porto, June 16, 2005

  18. Abs.container A. component input output navigation control select 1.3 Abstraction #2: the abstract UI [Montero et al., 2005] • Notation: based on canonical abstract prototypes: Larry Constantine, Helmut Windl, James Noble, & Lucy Lockwood: http://www.forUse.com IdealXML CAiSE'2005 Keynote address - Porto, June 16, 2005

  19. 1.3 Abstraction #3: the task [Paternò et al., 1997] • Task = set of actions carried out by a user in a given context to reach a goal • Logical decomposition of task into sub-tasks • Temporal ordering: LOTOS operators • T1 >> T2 Enabling • T1 [ ]>> T2 Enabling + information passing • T1 |> T2 Suspend/resume • T1 [ ] T2 Choice • T1 [> T2 Disabling (e.g. Form submit) • T1 |=| T2 Independence (any order, but finished) • T1* Iteration • T1{n} Finite iteration • T1 ||| T2 Concurrency • T1 |[x]| T2 Concurrency + information passing • [T] Optional • T Recursion CTTE Editor CAiSE'2005 Keynote address - Porto, June 16, 2005

  20. 1.3 Abstraction #3: the task • Task definition = action + object • Action types • Acquire, render, modify, publish, compute, derive,… • Object types: • Element, list, table, collection, compound,… CAiSE'2005 Keynote address - Porto, June 16, 2005

  21. 1.3 Abstraction #3: the task [Limbourg, 2004] CAiSE'2005 Keynote address - Porto, June 16, 2005

  22. 1.3 Abstraction #4: the context of use [Cameleon project, 2004] • Context of use= triple (U,P,E) where • U is a user model: from cognitive psychology • P is a platform model: subset of UAProf (W3C) • E is an environment model: from ubiquitous computing Pick & Drop technique: J. Rekimoto CAiSE'2005 Keynote address - Porto, June 16, 2005

  23. 1.3 Abstraction #4: the context of use [Limbourg, 2004] CAiSE'2005 Keynote address - Porto, June 16, 2005

  24. triggers (tg): { , } x updates (up): x observes (ob): x isExecutedIn (ex): x manipulates (ma): { , } x These mappings can be established: 1.3 Mapping the models [Montero et al., 2005] CAiSE'2005 Keynote address - Porto, June 16, 2005

  25. 1.3 Mapping the models [Limbourg, 2004] • Mapping the models with a mapping model (!!) CAiSE'2005 Keynote address - Porto, June 16, 2005

  26. 1.4 What do we have so far? Method triggered: download a file Object: computer file Task Task & & Task Task Classes Classes Domain Modality-independent Control AIC Abstract Individual Component Abstract User Abstract User Interface ( Interface ( AUI AUI ) ) Digital control AIC Physical control AIC Toolkit-independent Concrete Interaction Object Graphical 2D push button Graphical 3D push button Physical push button Concrete Concrete User User Interface (CUI) Interface (CUI) HTML push button Windows push button OSF/Motif XmButton VRML97/X3D button Software key Function key Code Code <input type=submit value=“Download" name= Final User Final User Interface (FUI) Interface (FUI) Rendering Rendering Down Down Down Download Download Download Load Load Load CAiSE'2005 Keynote address - Porto, June 16, 2005

  27. Platform S Environment S Reification 1.4 What do we have so far? S=Source context of use User S Task and Domain S UsiXML supported model Abstract user Interface S UsiXML unsupported model Concrete user Interface S Final user Interface S CAiSE'2005 Keynote address - Porto, June 16, 2005

  28. 2. Forward engineering [Limbourg, 2004] • 2.1 Task and domain models • 2.2 From T&D to AUI • Model-to-model transformation • 2.3 From AUI to CUI • Model-to-model transformation • 2.4 From CUI to FUI CAiSE'2005 Keynote address - Porto, June 16, 2005

  29. 2.1 Task and domain models CAiSE'2005 Keynote address - Porto, June 16, 2005

  30. 2.1 Task and domain models [Limbourg, 2004] CAiSE'2005 Keynote address - Porto, June 16, 2005

  31. 2.1 Task and domain models CAiSE'2005 Keynote address - Porto, June 16, 2005

  32. 2.2 From T&D to AUI [Limbourg, 2004] • Definition of AUI structure • Which objects should be logically grouped? • Definition of AIC types • Which « functionnality » should assume AICs and what data do they manipulate ? • Definition of spatio-temporal arrangement • How should AIC be arranged in space and/or in time ? • Definition of dialog control • What is the valid flow of action on AIOs ? CAiSE'2005 Keynote address - Porto, June 16, 2005

  33. 2.2 From T&D to AUI [Limbourg, 2004] • Definition of AUI structure CAiSE'2005 Keynote address - Porto, June 16, 2005

  34. 2.2 From T&D to AUI [Limbourg, 2004] • Definition of AIC types AC = Abstract Component AIC = Abstract Individual Component CIC = Concrete Interaction Component CAiSE'2005 Keynote address - Porto, June 16, 2005

  35. 2.2 From T&D to AUI [Limbourg, 2004] • Definition of spatio-temporal arrangement CAiSE'2005 Keynote address - Porto, June 16, 2005

  36. 2.2 From T&D to AUI • All transformations are in UsiXML • Each model = instance of meta-model • Each model = graph as instance of graph type • Each model-to-model transformation = • graph transformation • Set of productions CAiSE'2005 Keynote address - Porto, June 16, 2005

  37. 2.2 From T&D to AUI [Limbourg, 2004] • Typed model-to-model transformation Meta-Meta-Model Graph Structure is instance of Meta-Model Our Meta-Model Meta-Model Subset 1 Meta-Model Subset 2 e.g., Task+Domain Model e.g., Concrete UI Model Uses language is instance of is instance of Initial UI Model Transformation Rule Resultant UI Model e.g., MyTaskAndDomainModel Our transformation catalog e.g., MyConcreteUIModel CAiSE'2005 Keynote address - Porto, June 16, 2005

  38. 2.2 From T&D to AUI • TransformiXML CAiSE'2005 Keynote address - Porto, June 16, 2005

  39. 2.3 From AUI to CUI [Limbourg, 2004] • Definition of CUI structure • Which AIC is a window? • Definition of CIO type • Which « widget » should represent which AIO ? • Definition of placement • What layout can be specified between CIOs • Definition of navigation • Which container can be started or closed from which container? • Definition of dialog control • What is the dialog local to each CIO? • What is the valid flow of action on CIOs? CAiSE'2005 Keynote address - Porto, June 16, 2005

  40. NAC NAC LHS LHS RHS RHS ::= ::= 2.3 From AUI to CUI [Limbourg, 2004] • Definition of CIO structure CAiSE'2005 Keynote address - Porto, June 16, 2005

  41. 2.3 From AUI to CUI [Limbourg, 2004] • Definition of placement CAiSE'2005 Keynote address - Porto, June 16, 2005

  42. 2.4 From CUI to FUI • Model-to-code transformation • By rendering (interpretation) • Java (InterpiXML) • Tcl/tk (QtkiXML) • Flash (FlashiXML) • By code generation • HTML • Visual Basic CAiSE'2005 Keynote address - Porto, June 16, 2005

  43. Platform S Environment S Reification Abstraction 2.4 What do we have so far? S=Source context of use User S Task and Domain S UsiXML supported model Abstract user Interface S UsiXML unsupported model Concrete user Interface S Final user Interface S CAiSE'2005 Keynote address - Porto, June 16, 2005

  44. 3. Reverse engineering • 3.1 From FUI to CUI • 3.2 From CUI to AUI, task & domain CAiSE'2005 Keynote address - Porto, June 16, 2005

  45. 3.1 From FUI to CUI [Bouillon & Vanderdonckt, 2004] • Do you have the source code? • Markup languages (e.g., HTML): static code analysis (ReversiXML) • Do you have the compiled code? • Programming languages (e.g., compiled C): resource file extraction and static code analysis • Do you have the running application? • Video analysis: computer vision • Do you have only the documentation? • Image analysis: image processing CAiSE'2005 Keynote address - Porto, June 16, 2005

  46. 3.1 From FUI to CUI [Bouillon & Vanderdonckt, 2004] • ReversiXML CAiSE'2005 Keynote address - Porto, June 16, 2005

  47. 3.2 From CUI to AUI, task & domain [Limbourg, 2004] • Code-to-model and model-to-model • CUI to AUI CAiSE'2005 Keynote address - Porto, June 16, 2005

  48. 3.2 From CUI to AUI, task & domain • Re-engineering = reverse + forward • Possible re-interpretation by QtkiXML [Bouillon & Vanderdonckt, 2004] CAiSE'2005 Keynote address - Porto, June 16, 2005

  49. Platform S Environment S Reification Abstraction 3.2 What do we have so far? S=Source context of use User S Task and Domain S UsiXML supported model Abstract user Interface S UsiXML unsupported model Concrete user Interface S Final user Interface S CAiSE'2005 Keynote address - Porto, June 16, 2005

  50. Platform S Environment S Platform T Environment T Reflexion Reification Abstraction Translation 3.2 What do we want to get? [Cameleon project, 2004] S=Source context of use T=Target context of use User S User T http://www.plasticity.org Task and Domain S Task and Domain T UsiXML supported model Abstract user Interface S Abstract user Interface T UsiXML unsupported model Concrete user Interface S Concrete user Interface T Final user Interface S Final user Interface T CAiSE'2005 Keynote address - Porto, June 16, 2005

More Related