2011 2012
WETENSCHAPPEN master in de informatica: Human-Computer-Interaction
Masterproef Tool support for abstract user interfaces
Promotor : dr. Jan VAN DEN BERGH
De transnationale Universiteit Limburg is een uniek samenwerkingsverband van twee universiteiten in twee landen: de Universiteit Hasselt en Maastricht University
Yves Bottelbergs
Masterproef voorgedragen tot het bekomen van de graad van master in de informatica , afstudeerrichting Human-Computer-Interaction
Universiteit Hasselt | Campus Diepenbeek | Agoralaan Gebouw D | BE-3590 Diepenbeek Universiteit Hasselt | Campus Hasselt | Martelarenlaan 42 | BE-3500 Hasselt
2011 2012
WETENSCHAPPEN master in de informatica: Human-Computer-Interaction
Masterproef Tool support for abstract user interfaces
Promotor : dr. Jan VAN DEN BERGH
Yves Bottelbergs
Masterproef voorgedragen tot het bekomen van de graad van master in de informatica , afstudeerrichting Human-Computer-Interaction
i
Abstract De abstracte user interface (AUI) vormt in model-based user interface design (MB-UID) een belangrijk overgangsmodel tussen taak modellen en concrete prototypes. Een AUI beschrijft de inhoud (en soms ook het gedrag) van een user interface op een implementatie- en platform-onafhankelijke wijze. In deze masterproef wordt er een vergelijkende studie gemaakt tussen de CAP, UMLi, UsiXML, DIANE+, MARIA en CAP3 AUI descriptions en hun software tool support. Er wordt een gefundeerde keuze gemaakt om de tool van CAP3 verder uit te breiden met semantische constraints, alsook met een methode om uit CAP3 modellen constraints te genereren voor diverse toepassingen.
ii
Inhoudsopgave 1 Inleiding 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Inhoud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 5
I
7
Literatuurstudie
2 Model-based user interface design 2.1 Inleiding . . . . . . . . . . . . . . . . 2.2 Deelmodellen . . . . . . . . . . . . . 2.2.1 Task model . . . . . . . . . . 2.2.2 Domain model . . . . . . . . . 2.2.3 Abstract user interface model 2.2.4 Concrete user interface model 2.2.5 Finale user interface . . . . . 2.3 Modelstructuren en abstractieniveaus 2.4 Cameleon Reference Framework . . . 2.5 Multi-path UI development . . . . . 2.6 User-centered design . . . . . . . . . 2.6.1 Inleiding . . . . . . . . . . . . 2.6.2 Prototyping . . . . . . . . . . 2.6.3 Usage-centered design . . . . 2.6.4 MuiCSer . . . . . . . . . . . . 2.7 Conclusie . . . . . . . . . . . . . . . 3 Abstract user interface descriptions 3.1 Inleiding . . . . . . . . . . . . . . . 3.2 Overzicht . . . . . . . . . . . . . . 3.3 CAP . . . . . . . . . . . . . . . . . 3.4 UMLi . . . . . . . . . . . . . . . . 3.4.1 Abstract presentation model 3.4.2 Diagramnotatie . . . . . . . 3.4.3 Task modeling . . . . . . . . 3.5 UsiXML . . . . . . . . . . . . . . . iii
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . . . .
9 9 10 10 12 12 14 14 14 15 18 19 19 19 20 21 23
. . . . . . . .
25 25 26 27 29 29 29 30 33
iv
INHOUDSOPGAVE
3.6
3.7
3.8
3.9
3.5.1 Abstract user interface model 3.5.2 Diagramnotatie . . . . . . . . DIANE+ . . . . . . . . . . . . . . . . 3.6.1 Data model . . . . . . . . . . 3.6.2 Procedures . . . . . . . . . . . MARIA . . . . . . . . . . . . . . . . 3.7.1 Data model . . . . . . . . . . 3.7.2 Presentations . . . . . . . . . 3.7.3 Dialog model . . . . . . . . . CAP3 . . . . . . . . . . . . . . . . . 3.8.1 Structurele specificatie . . . . 3.8.2 Behaviour specificatie . . . . . Evaluatie . . . . . . . . . . . . . . . 3.9.1 Presentation . . . . . . . . . . 3.9.2 Behaviour . . . . . . . . . . . 3.9.3 Diagramnotatie . . . . . . . . 3.9.4 Vergelijking met richtlijnen . .
4 Tool support 4.1 Inleiding . . . . . . . . . . . . . 4.2 CAP . . . . . . . . . . . . . . . 4.2.1 CanonSketch . . . . . . 4.2.2 DialogSketch . . . . . . 4.3 UMLi . . . . . . . . . . . . . . 4.4 UsiXML . . . . . . . . . . . . . 4.4.1 GrafiXML . . . . . . . . 4.4.2 IdealXML . . . . . . . . 4.4.3 AGG en TransformiXML 4.4.4 Andere . . . . . . . . . . 4.5 DIANE+ . . . . . . . . . . . . . 4.6 MARIA . . . . . . . . . . . . . 4.7 CAP3 . . . . . . . . . . . . . . 4.8 Evaluatie . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
34 35 35 36 37 40 40 40 41 42 42 42 45 45 46 48 48
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
51 51 52 52 53 54 55 56 56 57 57 58 58 60 60
5 Conclusie literatuurstudie
65
II
67
Toepassing
6 Concept 6.1 Keuze en motivatie . . . . . . . . 6.2 Tool concept . . . . . . . . . . . . 6.2.1 Constraint checking . . . . 6.2.2 Genereren van constraints
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
69 69 70 70 71
INHOUDSOPGAVE 7 Platform 7.1 Inleiding . . . . . . . . . . . . . . . . 7.2 Eclipse . . . . . . . . . . . . . . . . . 7.3 EMF . . . . . . . . . . . . . . . . . . 7.4 GMF . . . . . . . . . . . . . . . . . . 7.5 Epsilon . . . . . . . . . . . . . . . . . 7.5.1 Epsilon Object Language . . . 7.5.2 Epsilon Validation Language . 7.5.3 Epsilon Generation Language 7.5.4 EuGENia . . . . . . . . . . .
1
. . . . . . . . .
8 Implementatie 8.1 Meta model . . . . . . . . . . . . . . . 8.2 Constraint checking . . . . . . . . . . . 8.3 Genereren van constraints . . . . . . . 8.3.1 Component constraints . . . . . 8.3.2 Design patterns . . . . . . . . . 8.3.3 Multi-platform UI development 8.4 Evaluatie . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
. . . . . . . . .
. . . . . . .
9 Conclusie
. . . . . . . . .
73 73 73 74 75 76 77 78 79 79
. . . . . . .
81 81 83 88 90 91 92 94 99
A Epsilon syntax en features A.1 Epsilon Object Language . . . . . . . . . . . . . . . . . . . . . A.2 Epsilon Validation Language . . . . . . . . . . . . . . . . . . . A.3 Epsilon Generation Language . . . . . . . . . . . . . . . . . .
101 . 101 . 103 . 104
B Generator output B.1 Notification component EVL constraint B.2 Wizard pattern EVL constraint . . . . B.2.1 Strict constraint . . . . . . . . . B.2.2 Flexible constraint . . . . . . .
107 . 107 . 109 . 109 . 114
Bibliografie
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
120
2
INHOUDSOPGAVE
Hoofdstuk 1 Inleiding 1.1
Context
De interactie eigenschappen van diverse software platformen (e.g. PCs, smartphones, tablets) zijn vaak vrij heterogeen, met soms grote verschillen in schermgrootte, schermresolutie of interactiemodaliteit. De ontwikkeling van software die ingezet dient te worden op meerdere dergelijke platformen brengt een moeilijkheid met zich mee; de contrasterende manieren van interactie en de verschillen in platform eigenschappen zorgen ervoor dat voor elk platform een nieuwe, verschillende user interface ontwikkeld dient te worden die toch vaak dezelfde functionaliteit moet bevatten. Naast deze vaststelling zijn er ook software toepassingen die vaak onderhevig zijn aan wijzingen in gebruikscontext, zoals de herdefinitie van taken, de herverdeling van taken onder gebruikers, ondersteuning van nieuwe platformen, wijziging in taal, etc [21]. Deze user interfaces moeten snel en frequent aangepast kunnen worden om tegemoet te komen aan dergelijke veranderingen. In beide situaties stelt zich het probleem dat de ontwikkeling van een nieuwe user interface, door een gebrek aan structuur in het ontwikkelingsproces, steeds een operatie is die van vooraf aan begint bij het identificeren van de benodige functionaliteit, het selecteren van de UI componenten en het ruimtelijk indelen van de UI, rekeninghoudend met de eigenschappen van de context en het platform. Hierdoor gaat steeds opnieuw veel tijd en arbeid verloren. Als oplossing voor dit probleem wordt model-based user interface design (MB-UID) naar voor geschoven. MB-UID is een model-driven software engineering techniek die structuur brengt in het ontwikkelingsproces van user interfaces door een aantal deelmodellen te introduceren. De verschillende deelmodellen (sectie 2.3 voor meer detail) hebben een niveau of graad van abstractie. De meest abstracte modellen in de structuur zijn taak- en domeinmodellen. Op deze modellen wordt vervolgens 3
4
HOOFDSTUK 1. INLEIDING
het abstracte user interface (AUI) model gebaseerd. Dit model dient als basis voor het concrete user interface (CUI) model dat op haar beurt de basis vormt voor de Final UI (FUI). Een user interface design kan op deze manier incrementeel verfijnd worden over de verschillende abstractieniveaus [8, 34]. Een design hoeft overigens niet altijd te beginnen op het laagste abstractieniveau, in sommige MB-UID frameworks kan eender welk model als beginpunt gekozen worden voor de verdere invulling van de modelstructuur [4, 19]. Vooral abstracte user interfaces zijn vaak een centraal model in deze structuren aangezien ze een belangrijk overgangsmodel vormen tussen taak- en domeinmodellen en de concrete user interface (vergelijkbaar met een traditioneel UI prototype, zie sectie 2.6.2), een overgang die zonder deze constructie niet vanzelfsprekend is [8]. Abstracte user interfaces beschrijven een user interface dus als een abstractie van UI functionaliteit die de inhoud (en soms ook de functionaliteit) van de user interface representeert op een platform- en implementatie-onafhankelijke wijze. De abstracte UI maakt gebruik van abstracte interactie objecten (AIO) om UI elementen te modelleren. Belangrijk is dat deze interactieobjecten geen informatie bevatten over hun presentatie of interactiemethode, maar enkel een functie of actie beschrijven op een abstract niveau. In de literatuur worden diverse benaderingen besproken voor de specificatie van abstracte user interfaces. Deze benaderingen kunnen op verschillende manieren ingedeeld worden. Ruwweg zijn er specificaties die een volledig nieuwe syntax defini¨eren en specificaties die bestaande, algemenere specificaties uitbreiden met symbolen en constructies voor de representatie van AUIs. Verschillende AUIs beschrijven een grafische notatie, anderen voorzien enkel een tekstuele representatie. Sommige AUI specificaties bieden ook de mogelijkheid om regels en constraints te defini¨eren op de UI om gedrag (dynamic behaviour) te modelleren. In meer uitgebreide modelleertalen (user interface description languages, UIDL) wordt ook ondersteuning voor (automatische) modeltransformaties tussen verschillende deelmodellen voorzien, hoewel hier tool support ook een belangrijke factor in is. De aanwezigheid van tool support heeft een sterke impact op de effectieve bruikbaarheid van de AUI of de UIDL. Verschillende soorten tool support kunnen ge¨ıdentificeerd worden. Model transformation tools kunnen het aanpassen van abstracte user interfaces aan meerdere gebruikscontexten sterk vereenvoudigen. Met generating of rendering tools kunnen onder meer zeer vlug interactieve prototypes gegenereerd worden. Een specifieke editing tool maakt het opmaken van een AUI makkelijker, etc. Sommige tools bieden een combinatie van deze verschillende vormen. Het opzet van deze masterproef is een inventarisering en kwalitatieve evaluatie te maken van de beschikbare AUI descriptions en hun tool support, en vervolgens in het kader van deze evaluatie een contributie te doen die AUIs
1.2. INHOUD
5
bruikbaarder en breder toepasbaar tracht te maken, in het bijzonder voor minder technische gebruikers.
1.2
Inhoud
De tekst wordt opgesplitst in 2 delen; Deel I bevat een bespreking van modelbased user interface design en een vergelijkende studie van een aantal AUI descriptions en hun tool support. Op basis van de conclusie uit Deel I bespreekt Deel II de implementatie van semantische constraints en een constraint generating tool voor CAP3. In de rest van deze sectie wordt een beknopt overzicht gegeven van de inhoud van de verschillende hoofdstukken. Deel I In Hoofdstuk 2 wordt model-based user interface design uitgebreid besproken. Na een korte definitie worden de vaakst gebruikte modellen doorgenomen – waaronder abstracte user interfaces – aan de hand van hun definities en kenmerken. Vervolgens worden de modelstructuren en hun abstractieniveaus besproken. In de rest van het hoofdstuk worden een aantal belangrijke MB-UID methodes/frameworks behandeld. Vervolgens (Hoofdstuk 3) worden enkele abstracte user interface descriptions besproken. Voor elke description wordt het model in detail behandeld, alsook (indien aanwezig) de grafische presentatie en de structuren voor behaviour modeling. Op het einde van dit hoofdstuk worden deze methoden vergeleken en ge¨evalueerd. Hoofdstuk 4 bespreekt de tool ondersteuning voor de verschillende AUI descriptions die behandeld werden in Hoofdstuk 3. Voor elke AUI description worden ´e´en of meerdere tools besproken. In een evaluatie wordt bepaald welke vormen van tool support aanwezig zijn voor elke AUI description. Er wordt ook getracht de tool support op een kwalitatieve manier te beoordelen op basis van een aantal criteria uit de literatuur. De literatuurstudie wordt geconcludeerd (Hoofdstuk 5) met een bespreking van de behandelde onderwerpen en hun evaluaties. Deel II In Hoofdstuk 6 wordt de keuze voor CAP3 als basis voor de toepassing gemotiveerd en wordt het concept voor de tool besproken en toegelicht. Dit gebeurt o.a. op basis van de conclusie uit Deel I. Hoofdstuk 7 bespreekt beknopt de technologie die gebruikt werd om de functionaliteit te implementeren. Een meer diepgaande bespreking wordt gegeven in de Appendix.
6
HOOFDSTUK 1. INLEIDING
In Hoofdstuk 8 worden de details van de implementatie besproken, alsook de mogelijke toepassingen voor de nieuwe tool functionaliteit. De bespreking van de toepassingen gebeurt aan de hand van uitgewerkte voorbeelden voor de toepassing in kwestie. Afrondend wordt er in dit hoofdstuk een kwalitatieve evaluatie gemaakt van de tool. De finale conclusie (Hoofdstuk 9) bevat een samenvatting van de belangrijkste punten die aangehaald werden in de evaluatie en een finale commentaar op de toepassing. Er worden tenslotte ook mogelijke toekomstige uitbreidingen voor de tool voorgesteld.
Deel I Literatuurstudie
7
Hoofdstuk 2 Model-based user interface design 2.1
Inleiding
Model-driven engineering [37] is een software ontwikkelingsmethodologie die steunt op beschrijvende modellen en model checking (het toetsen van modellen aan een modelspecificatie). Software modellen brengen meer structuur in het ontwikkelingsproces, kunnen communicatie tussen teamleden verbeteren en zorgen ervoor dat fouten vroeger in de ontwikkeling ontdekt kunnen worden. Abstractere modellen kunnen bovendien als basis dienen voor de ontwikkeling van een applicatie voor verschillende doelplatformen, wat tijd en moeite kan sparen. Model-based user interface design/development (MB-UID) is een software engineering aanpak voor user interface ontwikkeling, gebaseerd op model-driven engineering, die een set van abstracties, ontwikkelingsprocessen en tools biedt [19]. In MB-UID wordt een user interface voorgesteld met verschillende modellen op verschillende niveaus van abstractie. Er wordt voor een bepaalde UI een gelaagde modelstructuur van deelmodellen [34] gecre¨eerd die deployment op verschillende eindplatformen en in verschillende gebruikscontexten eenvoudiger maakt. De resulterende finale user interface voor het doelplatform vormt een concretisering van de bestaande modelstructuur. Middels deze aanpak kan een software ontwikkelaar zich concentreren op het ontwikkelen van de UI functionaliteit, zonder aandacht te spenderen aan de details van de verschillende gebruikscontexten, programmeertalen, platformen of modaliteiten [33]. Ook het onderhouden van verschillende versies van eenzelfde applicatie voor meerdere doelplatformen wordt makkelijker en overzichtelijker [4]. Het toepassen van een MB-UID strategie kan bovendien leiden naar meer effici¨ente en bruikbare user interfaces [8], onder meer door het vroegtijdig inzetten op een bepaalde look & feel te voorkomen [10]. 9
10
2.2
HOOFDSTUK 2. MODEL-BASED USER INTERFACE DESIGN
Deelmodellen
Een user interface deelmodel beschrijft bepaalde eigenschappen van de user interface op een bepaald abstractieniveau. Hogere abstractieniveaus zijn minder concreet en beschrijven de user interface op een systeem- en implementatieonafhankelijke wijze. Lagere niveaus gaan dieper in detail en worden specifieker qua implementatie en meer getrouw aan de werkelijkheid. In deze sectie worden een aantal courante UI modellen besproken; in de volgende sectie worden de indeling en de betekenis van de verschillende abstractieniveaus behandeld. Niet alle modellen bespreken noodzakelijkerwijze dezelfde eigenschappen van de user interface. Ruwweg bestaat een user interface uit twee elementen [19]:
De presentation beschrijft de fysieke weergave van de user interface en presenteert de functionaliteit van de user interface a.d.h.v. interactors.
De dialog beschrijft het dynamische gedrag van de interactors en de informatieflow tussen de gebruiker en de applicatie.
De verschillende modellen beschrijven meestal slechts ´e´en van deze eigenschappen, met enkele uitzonderingen. Verschillende modellen kunnen dan weer wel dezelfde eigenschap beschrijven in meer of minder abstracte termen.
2.2.1
Task model
Taak modellen zijn abstracte representaties van de verschillende taken die door de gebruiker uitgevoerd kunnen worden in de user interface [4]. De highlevel taken in het model kunnen meestal verder worden ingedeeld in minder abstracte taken die op hun beurt ook weer ingedeeld kunnen worden, waaruit een hi¨erarchisch model (een taakboom) ontstaat [10]. De hogere niveaus van de taakboom corresponderen met high level gebruiker acties (zoals “Open een file” en “Edit een file”), door deze taken verder op te splitsen worden lagere niveaus gevormd die de taak in meer detail beschrijven. De verschillende soorten taak modellen zijn divers [19]. Meer gedetailleerde modellen zoals ConcurTaskTrees (CTT) [26], een grafische, hi¨erarchische notatie voor taak model specificaties, laten toe dat op de structuur van taken en subtaken constraints (ook wel temporele operatoren genoemd) gedefinieerd kunnen worden die de taakflow bepalen. De set van operatoren gedefinieerd door CTT is gebaseerd op de LOTOS [1] notatie voor concurrente processen, en kan de meeste temporele verhoudingen tussen taken modelleren. Tabel 2.1 geeft een oplijsting van de operatoren die gedefinieerd worden in CTT. Het voorbeeld in figuur 2.1 demonstreert het gebruik van de operatoren in een simpel ConcurTaskTrees taakmodel. Wanneer twee taken verbonden zijn door een lijn gemarkeerd met ´e´en van de in tabel 2.1 vermeldde operatoren bestaat
2.2. DEELMODELLEN
Independent concurrency (T1 ||| T2)
Choice (T1 rs T2)
Concurrency with information exchange (T1 |rs| T2)
Order independence (T1 | | T2)
Deactivation (T1 r¡ T2)
Enabling (T1 ¡¡ T2)
Enabling with information passing (T1 rs ¡¡ T2) Suspend-resume (T1 | ¡ T2)
Iteration (T)
Finite iteration (T1(n)) Optional tasks ([T]) Recursion
11
De twee taken kunnen in eender welke volgorde (of simultaan) uitgevoerd worden. De gebruiker maakt een keuze tussen ´e´en van de twee taken. Tijdens de uitvoering van de gekozen taak zijn de andere taken niet beschikbaar. Twee taken kunnen onafhankelijk van elkaar uitgevoerd worden maar moeten informatie uitwisselen om te synchroniseren. Beiden taken moeten uitgevoerd worden, maar wanneer een taak start moet deze eindigen vooraleer de tweede gestart kan worden. De tweede taak wordt permanent onbruikbaar gemaakt wanneer de eerste taak gekozen wordt. De tweede taak wordt pas beschikbaar wanneer de eerste taak ge¨eindigd is. Gelijk aan Enabling, maar de tweede taak krijgt ook informatie van de eerste taak. De tweede taak kan de eerste taak onderbreken en later opnieuw hervatten met dezelfde status. Deze taak wordt herhaald uitgevoerd tot deze gestopt wordt door een andere taak. Taak wordt een bepaald aantal keer uitgevoerd. Optionele taken hoeven niet uitgevoerd te worden. In de subtree van de taak in kwestie bestaat een andere instantie van de taak. Modelleert recursie.
Tabel 2.1: De ConcurTaskTrees operatoren [26].
12
HOOFDSTUK 2. MODEL-BASED USER INTERFACE DESIGN
er een relatie tussen de twee taken die correspondeert met het gedrag dat de operator modelleert.
Figuur 2.1: Voorbeeld van een CTT taakmodel. [26]
2.2.2
Domain model
Domein modellen vinden hun oorsprong in software engineering en object oriented design (OO). Een domain model beschrijft de klassen, attributen, objecten, methoden en domein relaties van een systeem [4], of m.a.w. de semantiek van de onderliggende applicatie waartoe de user interface toegang verschaft [19]. Vaak worden entity-relationship models of object models als domein model gebruikt [10]. Een belangrijk voorbeeld zijn klasse diagrammen, die een applicatie indelen en structureren in de verschillende OO-klassen en hun attributen, objecten en methoden. Tussen deze entiteiten kunnen vervolgens verschillende soorten relaties gelegd worden. Een belangrijke notatie voor klasse diagrammen is Unified Modeling Language (UML)1 .
2.2.3
Abstract user interface model
Abstracte user interfaces (AUI) representeren de inhoud en de organisatie van de UI(-elementen) op een systeem- en implementatie-onafhankelijke manier. 1
http://www.uml.org/
2.2. DEELMODELLEN
13
Volgens Calvary et al. [4] is een abstracte user interface een “canonieke uitdrukking van de rendering van domeinconcepten en functies op een manier die onafhankelijk is van de interactors beschikbaar op de targets”. Canoniek slaat hier op de reductie tot de meest simpele vorm. Interactors zijn abstracties van widgets of containers en het target is het doel-platform. Deze abstracties van widgets zijn elementen die een functionaliteit, maar geen informatie over de implementatie van deze functionaliteit, defini¨eren. Op het niveau van de AUI spreekt men dus niet van “widgets” (klassieke UI elementen), maar van abstracte interactors of abstract interaction objects (AIO) [21, 19, 10]. Belangrijk is dat een AIO niet enkel platform-onafhankelijk is, maar ook ongebonden is aan een bepaalde interactie- of presentatievorm. Wanneer men de gebruiker bijvoorbeeld een element wil laten selecteren uit een verzameling van elementen heeft men de keuze uit o.a. een combo box en een drop-down menu om de informatie te presenteren. Beiden zijn concrete implementaties van eenzelfde abstract interactie object (een abstract chooser object). Door een user interface te specifi¨eren aan de hand van abstracte interactors i.p.v. widgets kan uitgeklaard worden welke elementen een UI moet bevatten en hoe de inhoud ingedeeld moet worden v´o´or de layout in detail uitgewerkt wordt [8]. Hiermee kan men problemen in de navigatie en organisatie van de UI oplossen vooraleer er keuzes genomen worden omtrent het uiterlijk of gedrag van de UI [8]. Verder laten sommige AUI specificaties een beschrijving van de UI dialog toe in de vorm van temporele operatoren tussen componenten, status overgangen in het systeem of een combinatie van beide. In meer recente AUI specificaties [21, 33, 46] wordt de dialog beschrijving rechtstreeks opgenomen in de syntax van het AUI model. Andere specificaties voorzien een aparte dialog beschrijving die vervolgens verbonden wordt aan het presentatie model [10]. Tenslotte is er een alternatieve, lossere definitie voor het abstracte user interface model in de vorm van Abstract prototypes (syn. content models) [8]. Ook abstract prototypes kunnen de inhoud en elementen van user interfaces representeren onafhankelijk van hun layout of gedrag. Belangrijk is hier dat deze prototypes voorgesteld kunnen worden op een continu¨ um van abstractieniveaus [8]. Een Content inventory is een simpele oplijsting van de informatie en controls die in een gegeven context (e.g. window, dialog) verzameld zijn. Een Visual content inventory modelleert ook positie en ruimtelijke relatie tussen interface elementen. Wire frame schematics lijnen de ingenomen ruimte van UI componenten uit. In deze definitie zijn low- en high-fidelity prototypes (zie ook sectie 2.6.2) de minst abstracte vorm van prototypes, ze stemmen echter eerder overeen met het concrete user interface model, beschreven in de volgende sectie.
14
HOOFDSTUK 2. MODEL-BASED USER INTERFACE DESIGN
2.2.4
Concrete user interface model
Een concrete user interface model (CUI) [19] is een specificatie van de layout, de interactors en het gedrag van de UI onafhankelijk van enige programmeertaal of toolkit [4]. Een concrete user interface is een concretisering van een abstracte user interface. Een concrete user interface wordt gedefinieerd in termen van concrete interaction objects (CIO) die de functionaliteit van de actie definieert ´en een specifieke keuze maakt betreffende interactie- en presentatievorm, zonder te kiezen voor een implementatie in een bepaalde programmeertaal of op een bepaald platform. Wanneer men bijvoorbeeld het selecteren van een object uit een verzameling wil modelleren in een CUI kan men reeds een bewuste keuze maken voor een specifieke interactiemethode en vormgeving, vb. een combo box. Net als in het abstract user interface model kan ook in het concrete user interface model een dialog beschrijving opgenomen worden [21, 33]. De concrete user interface komt overigens qua abstractieniveau ruwweg overeen met de meer traditionele user interface prototypes, meer in detail beschreven in sectie 2.6.2.
2.2.5
Finale user interface
Een final user interface (FUI) is een volledig functionele user interface, operationeel op een welbepaald systeem en ge¨ımplementeerd met een welbepaalde programmeertaal of toolkit [4]. De finale user interface is een concretisering van de concrete user interface. In de FUI wordt de functionaliteit gerepresenteerd a.d.h.v. widgets in een specifieke programmeertaal. Een combo box kan in een finale UI in de programmeertaal Java2 gerepresenteerd worden door een JComboBox object. In C++, gebruikmakende van de Qt Toolkit3 , wordt de combobox gerepresenteerd door een QComboBox object.
2.3
Modelstructuren en abstractieniveaus
Elk model (buiten de Final UI) is steeds per definitie een abstractie [19], doch niet elk model is daarom even abstract. Men kan de verschillende modellen indelen in verschillende abstractieniveaus, waarbij bepaalde niveaus abstracter zijn dan andere. De meeste modelstructuren voor model-based user interface design gaan uit van een indeling in vier discrete abstractieniveaus. Een modelstructuur die als startpunt kan dienen is die van Calvary et al., beschreven 2 3
http://www.java.com/ http://qt.nokia.com/
2.4. CAMELEON REFERENCE FRAMEWORK
15
in de context van het Cameleon reference framework (zie ook sectie 2.4) [4]. De indeling gaat als volgt: 1. Task en Domain model (T&D) 2. Abstract UI (AUI) 3. Concrete UI (CUI) 4. Final UI (FUI) De modellen worden gerangschikt van meest naar minst abstract, en taak en domein model worden in hetzelfde abstractieniveau ingedeeld. Da Silva [34] gebruikt een gelijkaardige indeling om een aantal MB-UIDs te vergelijken. Het Application model (AM) stemt overeen met het domein model. Het Task-Dialogue model (TDM) stemt overeen met het task model. Abstract presentation model (APM) en Concrete presentation model (CPM) stemmen overeen met respectievelijk de abstract en concrete user interface. De Final UI wordt hier niet als “model” gezien. Ook usage-centered design (zie sectie 2.6.3), een model-driven engineering aanpak voor de ontwikkeling van user interfaces, hanteert een gelijkaardige gelaagde modelstructuur waarin abstracte user interfaces een centrale rol bekleden. Task en role models beschrijven taken en gebruikersrollen. Het UI content model stemt overeen met de abstracte user interface en de Finale presentatie en interactie designs komen overeen met traditionele prototypes en dus de concrete user interface. Tabel 2.2 geeft een vergelijking tussen de verschillende modelstructuren en hun abstractieniveaus. Calvary T&D AUI CUI FUI
Da Silva AM en TDM APM CPM /
Usage-centered design Task model en role model UI content model Finale presentatie en interactie designs /
Tabel 2.2: Een vergelijking van abstractieniveaus. De indeling van Calvary dient als referentiepunt. Een “/” duidt op het ontbreken van een equivalent model.
2.4
Cameleon Reference Framework
Het Cameleon reference framework is een framework voor de ontwikkeling van contextgevoelige (context-sensitive) user interfaces. Het framework gebruikt een gelaagde modelstructuur met verschillende abstracte representaties voor de user interface.
16
HOOFDSTUK 2. MODEL-BASED USER INTERFACE DESIGN
Contextgevoelige user interfaces zijn UIs die hun gebruikscontext (context of use) kunnen identificeren en kunnen reageren op veranderingen in deze context. Gebruikscontext wordt hier gedefinieerd als een combinatie van [3, 4]:
De eigenschappen van de gebruiker (vb. voorkeuren of beperkingen).
De eigenschappen van de fysieke- en softwareplatformen die gebruikt worden voor interactie met het systeem (vb. schermgrootte of netwerk bandbreedte).
De eigenschappen die de fysieke omgeving (environment) van de interactie beschrijven, zoals objecten, personen en gebeurtenissen die niet direct verbonden zijn aan de huidige taak, maar die een invloed kunnen hebben op het systeem en/of het gedrag van de gebruiker (vb. hoeveelheid licht of geluid in de omgeving, een bepaalde fysieke locatie leent zich tot andere taken).
Wanneer er at run time een wijziging in de context plaatsvindt kan een contextgevoelige user interface een passende wijziging in de presentatie en/of functionaliteit van de user interface doorvoeren (indien dit nodig blijkt op basis van tijdens het ontwikkelingsproces gedefinieerde criteria). In het kader hiervan worden er verder twee soorten context ge¨ıdentificeerd: predictive contexts en effective contexts [4]. Predictive contexts zijn mogelijke situaties die tijdens het ontwikkelingsproces voorzien worden (vb. het platform is een tablet PC). Effective contexts zijn de situaties die effectief voorkomen at run time. Predictive contexts dienen in het framework als basis voor modeloplossingen voor bepaalde situaties en scenarios. De structuur van het Cameleon framework wordt weergegeven in afbeelding 2.2. Het framework bestaat uit 3 delen: Ontological models, Archetypal models en Observed models. Ontological models zijn platformonafhankelijke metamodellen die modeloplossingen defini¨eren voor problemen die zich kunnen voordoen in verschillende gebruikscontexten. Om de oplossingen in deze modellen toe te passen op concrete situaties worden ze ge¨ınstantieerd in archetypal models. Archetypal models zijn “klassen” voor mogelijke effective models (modellen die at run time actief zullen zijn) en zijn m.a.w. platformafhankelijk. Observed models zijn de effective models die at run time geobserveerd worden. Het framework dient ter ondersteuning van het eigenlijke ontwikkelingsproces van de contextgevoelige user interface. Archetypal models vormen de input voor dit ontwikkelingsproces. De relevante archetypal models worden getransformeerd naar overgangsmodellen (transient model ). Deze modellen delen het ontwikkelingsproces in in de vier bekende lagen van abstractie: task and concepts (T&C), abstract user interface (AUI), concrete user interface (CUI) en final user interface (FUI) [4], in orde van dalende abstractheid zoals beschreven in sectie 2.3. In deze overgangsmodellen worden referenties opgenomen (grijze pijlen in afbeelding 2.2) naar de archetypal models om het gebruik van informatie uit de ontological models te signifi¨eren. De overgang van de transient models naar de Final UI gebeurt a.d.h.v. trans-
2.4. CAMELEON REFERENCE FRAMEWORK
17
Figuur 2.2: Het Cameleon reference framework in schematische voorstelling [4]. De plaats van en relaties tussen de ontological, archetypal en observed models worden ge¨ıllustreerd. formaties. Deze transformaties kunnen automatisch (op basis van de specificaties) plaatsvinden, of manueel gestuurd worden door de ontwikkelaar. Twee soorten transformaties worden gedefinieerd [4]:
Vertical transformation: Verticale transformaties maken de overgang naar een ander abstractieniveau mogelijk. Zowel abstraction (overgang van concrete naar abstracte modellen) als reification (concretisering, overgang van abstracte naar concrete modellen) tussen modellen wordt ondersteunt. De ontwikkeling van de user interface kan beginnen op eender welk abstractieniveau en door middel van de transformaties kunnen de andere abstractieniveaus ingevuld worden.
Horizontal transformation: Horizontale transformaties betreffen de translatie van modellen van eenzelfde abstractieniveau. Translaties kunnen plaatsvinden om een model bestemd voor een bepaald platform te transformeren naar een model bestemd voor een ander platform.
Naast het design proces van het framework wordt er ook een run-time proces voorzien dat bestaat uit het herkennen van een contextwijziging en het bepalen en uitvoeren van de reactie van de user interface [4].
18
2.5
HOOFDSTUK 2. MODEL-BASED USER INTERFACE DESIGN
Multi-path UI development
Multi-path UI development [19, 21] is een modelgebaseerde software ontwikkelingsstrategie, gebaseerd op de modelstructuur uit het Cameleon reference framework. De modellen (T&C, AUI, CUI, FUI) uit de structuur worden verzameld in een model repository en uitgedrukt in eenzelfde UI Description Language (UIDL), namelijk UsiXML (zie sectie 3.5 voor meer). Afhankelijk van de gebruikscontext wordt de UI uitgedrukt gebruikmakend van de modellen in de repository en een ondersteunende software die de modellen kan analyseren, aanpassen en manipuleren [21]. Modeltransformaties uit bestaande modellen maken de creatie van nieuwe modellen mogelijk die aangepast zijn aan de nieuwe gebruikscontext. Het is interessant om op te merken vanuit een software engineering standpunt dat het multi-path UI development framework MDA-compliant is [47]. MDA (Model-Driven Architecture) [23] is een software engineering architectuur die model-driven engineering ondersteunt. MDA hanteert een gelaagde modelstructuur waarin abstracte modellen a.d.h.v. transformatieregels automatisch omgezet kunnen worden in meer concrete modellen [23]. Multi-path UI development implementeert deze principes; dit wordt ge¨ıllustreerd in tabel 2.3. De meest abstracte modellen binnen MDA zijn Computation Independent Models (CIM) die de software modelleren op een manier die onafhankelijk is van de gebruikte technologie. CIM kunnen worden getransformeerd in Platform Independent Models (PIM) die een view tonen van de software onafhankelijk van plaftorm details. PIM kunnen op hun beurt getransformeerd worden in Platform Specific Models (PSM) die de software modelleren voor een specifiek platform. Deze PSMs kunnen uiteindelijk worden omgezet in programmacode (Implementation of Code model). Tabel 2.3 toont een mapping van deze abstractieniveaus op de modelstructuur van Calvary et al., waarop multi-path UI development gebaseerd is [19]. Model Driven Architecture Computing Independent Model Platform Independent Model Platform Specific Model Implementation Platform Model
Calvary Task en Domain Abstract UI Concrete UI Final UI Context Model
Tabel 2.3: Vergelijking van MDA modellen met UI abstractieniveaus van Calvary.
2.6. USER-CENTERED DESIGN
2.6 2.6.1
19
User-centered design Inleiding
In een user-centered design (UCD) [29] proces wordt informatie over en feedback van de gebruiker verzameld en ge¨ıntegreerd in het software ontwikkelingsproces met het oog op het verbeteren van de algemene user experience. De gebruiker helpt het project team met het defini¨eren van het product en het ontwikkelen van de user interface (participatory design). Dit gebeurt in een iteratief proces waarin gebruikersfeedback een belangrijk onderdeel is van de informatie die gebruikt wordt voor het plannen van de volgende iteratie. Er wordt vertrokken vanuit de idee dat de gebruiker, en niet de ontwikkelaar, het meest geschikt is om te bepalen welke producten nuttig en bruikbaar zijn. Als gevolg hiervan wordt het product ontworpen rond de noden van de gebruiker, dit i.t.t. traditionele design filosofie¨en waarin de gebruiker zijn gedrag aanpast aan het product.
2.6.2
Prototyping
De sterke nadruk die binnen de UCD methodologie gelegd wordt op communicatie en collaboratie met de gebruiker wordt uitgebuit a.d.h.v. prototypes (experimentele ontwerpen die zeer snel en goedkoop ontwikkeld kunnen worden) die toelaten om reeds in vroege stadia van de ontwikkeling gebruikersfeedback te verzamelen. De impact van gemaakte designkeuzes op usability kan hiermee worden afgetoetst d.m.v. testing en discussie, en de feedback kan vervolgens in het iteratieve ontwikkelingsproces verwerkt worden. Low-, medium- en high-fidelity prototypes worden onderscheiden; de graad van fidelity vertegenwoordigt de getrouwheid van het prototype ten opzichte van het werkelijke product. Low-fidelity prototypes worden geconstrueerd om zeer vlug concepten, design alternatieven en de algemene layout te modelleren. Ze modelleren echter geen interactie en bieden bijgevolg geen (gesimuleerde) functionaliteit. Medium-fidelity prototypes simuleren gedeeltelijk interactie met de gebruiker terwijl high-fidelity prototypes volledig interactief zijn en veel of alle functionaliteit van het eindproduct simuleren. Belangrijk om op te merken is dat deze prototypes qua abstractieniveau overeen komen met de concrete user interfaces beschreven in sectie 2.3. Realistische prototypes (low- en high fidelity) zijn nodig om tot een succesvolle implementatie van een user interface te komen, terwijl taakmodellen nodig zijn om een doeltreffend design mogelijk te maken [8]. De significante kloof tussen beide wordt overbrugd door abstracte user interfaces.
20
HOOFDSTUK 2. MODEL-BASED USER INTERFACE DESIGN
2.6.3
Usage-centered design
Usage-centered design verschilt van user-centered design in de zin dat de focus niet ligt op de gebruiker, maar op de taken die gebruikers uitvoeren4 . De doelstelling van het proces is gebruikmakende van abstracte modellen het kleinste en meest eenvoudige UI design te ontwikkelen dat de taken die de gebruiker moet uitvoeren ondersteunt, met als doel het verbeteren van de usability van het product [9]. Vooral bij toepassingen waarbij de effici¨entie en betrouwbaarheid van de user interface belangrijk is (zoals medische of industri¨ele applicaties), is usage-centered design aangewezen [8]. UI designs komen voort uit een opeenvolging van op elkaar steunende modellen [8, 9] (samengevat in figuur 2.3):
Role model : Het role model modelleert de rollen (user roles) die gebruikers hebben in relatie tot het systeem. Een user role definieert een relatie van een gebruiker met het systeem (met aspecten als doel en frequentie van interactie, volume en richting van informatie-uitwisseling, houding van het systeem t.o.v. gebruikers in de rol, etc. [9]).
Task model : Het task model representeert de structuur van taken (task cases) die gebruikers uitvoeren. Task cases zijn een vorm van abstracte, vereenvoudigde use cases en zijn ingedeeld in subtaken die een narrative vormen. Het task model modelleert de relaties tussen deze task cases.
Content model : Het content model of abstract prototype representeert de inhoud en de organisatie van de user interface zonder de details van layout en interactie te specifi¨eren. In het usage-centered design proces van Constantine worden de abstracte prototypes uitgedrukt met Canonical Abstract Prototypes (CAP, zie ook sectie 3.3).
Verder onderscheidt men de presentatie- en interactieprototypes (zijnde low tot high-fidelity zoals in sectie 2.6.2) en de finale user interface. Om het abstracte prototype (of content model) te construeren worden gerelateerde taken uit het taakmodel gegroepeerd en wordt voor deze taken een interaction context gedefinieerd [8]. Voor elke taak in deze groep worden de subtaken doorlopen en worden de nodige abstracte componenten toegevoegd aan de interaction context. Pas wanneer alle benodigde elementen aanwezig zijn wordt de layout en de organisatie van de interaction context ingedeeld en het resulterende prototype getoetst aan het taakmodel. De presentatie- en interactieprototypes worden gecre¨eerd door uit het abstracte prototype de individuele abstracte componenten te vervangen door een relevante platform-specifieke widget, rekening houdend met de beschikbare schermruimte, de effici¨entie van de interactie en de presentatie, etc [8]. 4
http://www.foruse.com/questions/index.htm
2.6. USER-CENTERED DESIGN
21
In dit proces verbindt het abstracte prototype dus het task model met de presentatie- en interactieprototypes [9], die op hun beurt de basis vormen voor de finale user interface.
Figuur 2.3: Het usage-centered design proces, de brug die abstracte prototypes maken tussen taak analyses en concrete prototypes wordt hier ge¨ıllustreerd. Actors defini¨eren user roles waaruit beschrijvingen van user taken voortkomen. Deze taken worden verzameld en gemodelleerd in abstracte prototypes. Deze abstracte prototypes worden vervolgens omgezet (concretiseren van de abstracte componenten) in concrete prototypes [9].
2.6.4
MuiCSer
MuiCSer is een proces framework voor multi-disciplinaire user-centered software engineering [14]. Het ontwikkelen van software producten (en dus ook user interfaces) is een proces waarbij ontwikkelaars van vaak verschillende disciplines (user interface designers, software engineers, ...) betrokken zijn. MuiCSer combineert model-driven engineering met model-based user interface development technieken (waaronder ook UCD) om een iteratief software ontwikkelingsproces te cre¨eren dat een multidisciplinair team kan ondersteunen. Het MuiCSer proces kan toegepast worden op een bestaand systeem (redesign) of ingezet worden voor de ontwikkeling van een nieuw systeem. Het framework gebruikt een Agile Software Engineering [18] benadering om het proces te structureren. Figuur 2.4 geeft het framework visueel weer. Het MuiCSer proces bestaat uit 4 fasen die de verschillende stadia beschrijven in de ontwikkeling van een software systeem. Voor elke fase wordt bepaald welke design artefacten er belangrijk zijn. In de analyse fase worden de taken en doelen van de gebruiker gespecifieerd, alsook de resources die nodig zijn om deze taken en doelen te realiseren. De belangrijkste resulterende artefacten uit
22
HOOFDSTUK 2. MODEL-BASED USER INTERFACE DESIGN
Figuur 2.4: Het MuiCSer framework. De donkere pijl duidt op de richting van design en ontwikkeling. De lichte pijl duidt op de richting van user feedback. [14] deze fase zijn taak modellen, personas, use cases en behaviour diagrams. In de structured interaction analysis fase worden interactie- en presentatiemodellen, waaronder abstracte user interfaces [46], gecre¨eerd op basis van de artefacten uit de analyse fase. In de low-fidelity prototyping fase worden mockups van de user interface gemaakt op basis van de voorgaande modellen, design guidelines en de ervaring van de ontwikkelaars. Deze low fidelity prototypes evolueren naar high-fidelity prototypes en uiteindelijk naar de final user interface. Het proces deelt slechts de artefacten in in fasen, maar schrijft geen te volgen methodes voor om overgangen tussen modellen (en fasen) te maken. Net als in andere UCD benaderingen maakt de feedback van de gebruiker of de klant ook in MuiCSer in belangrijke mate deel uit van het ontwikkelingsproces. Gebruikersfeedback wordt na elke fase teruggekoppeld en resulteert in (aanpassingen aan de) modellen en artefacten. In situaties waar gebruikersfeedback niet gegeven kan worden (e.g. wanneer de resultaten van een fase te complex of niet concreet genoeg zijn) moet de fase ge¨evalueerd worden door een expert.
2.7. CONCLUSIE
2.7
23
Conclusie
Er werd een definitie gegeven van model-based user interface design en de context van abstractieniveaus en deelmodellen werd besproken. Vier modelbased user interface design frameworks werden in meer detail behandeld: het Cameleon reference framework, multi-path UI development, usage-centered design en het MuiCSer framework. Cameleon, multi-path UI development en usage-centered design gaan elk uit van de vier abstractieniveaus voor het modelleren van user interfaces, corresponderend met de deelmodellen: taak model (onder andere), abstracte user interface, concrete user interface en final user interface. MuiCSer neemt de modellen op in haar framework en deelt de abstracte user interface in bij dezelfde ontwikkelingsstap als de taak analyse, om net als in usage-centered design als overgangsmodel te dienen tussen taakmodellen en de concrete prototypes. De modelstructuur met de 4 bekende deelmodellen lijkt dan ook algemeen aanvaard te zijn. Cameleon en multi-path UI development besteden veel aandacht aan modeltransformaties tussen de verschillende deelmodellen om het ontwikkelingsproces voor multi-target user interfaces te vereenvoudigen. In multi-path UI development is een gemeenschappelijke UIDL voor de verschillende modellen een belangrijke factor. Usage-centered design en MuiCSer implementeren beide principes van usercentered design, een software ontwikkelingsfilosofie die de user betrekt in het ontwikkelingsproces. Deze frameworks blijken eerder een sturende rol te willen opnemen en zijn minder formeel dan Cameleon en multi-path UI development.
24
HOOFDSTUK 2. MODEL-BASED USER INTERFACE DESIGN
Hoofdstuk 3 Abstract user interface descriptions 3.1
Inleiding
Abstracte user interface descriptions beschrijven de inhoud van een abstract user interface model in een tekstuele of visuele modeling taal. Zoals gekend beschrijven de UI componenten (AIOs, zie sectie 2.2.3) abstracties van widgets of UI taken. Het aantal beschikbare AIOs verschilt sterk tussen de specificaties. Sommige specificaties verkiezen een beperkt aantal abstracte interactors die meer algemene UI functionaliteit modelleren [10, 21], anderen voorzien specifiekere interactors [8, 46, 33]. Soms wordt een grafische diagramnotatie voorzien die op zijn minst de hi¨erarchische indeling (containment relaties) van de abstracte interactors in de AUI weergeeft [21, 10]. In sommige descriptions wordt ook de structurele en ruimtelijke indeling van de componenten gemodelleerd [8, 46]. UI gedrag kan gemodelleerd worden aan de hand van (temporele) relaties tussen componenten of status overgangen in het systeem. Sommige specificaties integreren dialog en presentatie in ´e´en model [46, 21], terwijl anderen een apart dialog model voorzien [10, 33]. Ook de expressiviteit van de dialog specificaties verschilt sterk tussen de verschillende descriptions. In de rest van dit hoofdstuk wordt eerst een overzicht en verder een gedetailleerde beschrijving gegeven van een aantal abstracte user interface descriptions. Vervolgens worden de specificaties besproken op basis van hun modellen, hun grafische notatie, en de mogelijkheden tot behaviour modeling in een vergelijkende evaluatie. Er wordt ook getracht om een vergelijking te maken op basis van een aantal richtlijnen voor notaties uit de literatuur. Pas in Hoofdstuk 4 worden de vormen van beschikbare tool support en de mogelijkheden betreffende modeltransformatie (waar gepast) besproken. 25
26
3.2
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
Overzicht
Canonical Abstract Prototypes (CAP) [8] zijn een relatief expressieve [46] diagramnotatie voor AUIs. CAP voorziet 21 verschillende abstracte componenten, ingedeeld in containers, tools en active materials (die een input/output functie ´en een interactieve functie voorstellen). CAP modelleert echter enkel presentatie aspecten van de UI en heeft geen constructies voor behaviour modeling. CAP3 [46] is een AUI description die verderbouwt op de CAP diagramnotatie en behaviour modeling voorziet. CAP3 introduceert constructies voor temporele relaties en informatieuitwisseling tussen interactors. MARIA [33] en UsiXML [21] zijn XML-gebaseerde UI description languages (UIDL) die de UI kunnen beschrijven op meerdere abstractieniveaus, waaronder ook de AUI. Beiden modelleren UI gedrag met CTT temporele relaties tussen interactors. Bij UsiXML worden de relaties in het AUI model zelf gelegd, in MARIA wordt een apart dialog model verbonden aan het presentation model. UMLi [10] breidt UML uit met een syntax voor het modelleren van user interfaces. UMLi introduceert een nieuwe diagramnotatie en een standaard set van abstracte interactor klassen. UMLi bouwt verder op UML activity diagrams om behaviour modeling in de UI description te voorzien. De activity diagram constructies voor een aantal vaak voorkomende temporele relaties worden vereenvoudigd in UMLi door macros te introduceren voor deze constructies. Object flows worden in de activities opgenomen om relaties te leggen tussen objecten uit de applicatie en de UI. DIANE+ [41] is een taakspecificatie voor user interfaces. Het model is een schematische voorstelling die verschillende abstractieniveaus modelleert. UI gedrag kan beschreven worden door een combinatie van relaties tussen UI taken (operations) en constraints op deze taken. De specificatie heeft echter geen grafische diagramnotatie. CUP 2.0 [11] is een UML 2 profile voor het modelleren van contextgevoelige user interfaces. Het profile definieert UML stereotypes die gebruikt worden om modellen uit model-based user interface design te modelleren. Naast o.a. beschrijvingen voor de interne data en functionaliteit van de applicatie wordt er ook een abstract user interface model voorzien. Het model onderscheidt slechts vier abstracte componenten (input, output, action, group). Er kunnen relaties gelegd worden tussen de verschillende abstracte interactors om precedence (ordening in tijd en ruimte), update en activate relaties te modelleren. CUP 2.0 beschrijft ook een system interaction model dat de interactie taken kan beschrijven; net als in UMLi worden ook hier UML activities gebruikt om de taken te modelleren. CAP, UMLi, DIANE+, MARIA, UsiXML en CAP3 hebben allen een vorm van dedicated tool ondersteuning. Gezien de focus van deze masterproef worden
3.3. CAP
27
daarom deze specificaties verder in detail besproken.
3.3
CAP
Canonical Abstract Prototypes (CAP) zijn een diagramnotatie voor abstracte user interface prototypes. CAP definieert enkel een formele woordenschat en een grafische presentatie, maar is op zich geen volledige modeling taal [8]. CAP werd ontwikkeld als onderdeel van het usage-centered design proces van Constantine [9, 8] (zie sectie 2.6.3), maar kan ook los van het proces gebruikt worden en was bovendien een basis voor verdere verfijningen (zie sectie 3.8). UI elementen worden in CAP weergegeven aan de hand van een standaard verzameling van Canonical Abstract Components (CAC), elk met een specifieke functie (e.g. modify, select, move) en een eigen visueel symbol. CACs komen overeen met de meer algemene AIOs besproken in sectie 2.2.3. Ze zijn ingedeeld in abstract tools, abstract materials en abstract active materials. In de laatste versie van CAP zijn er 21 componenten gedefinieerd: 3 generische componenten (eerder vermeld), 11 abstract tools, 3 abstract containers en 7 abstract active materials [8]. Tools zijn de acties, operatoren, mechanismen of controls die gebruikt kunnen worden om materials te cre¨eren, manipuleren of transformeren [8]. Symbolisch worden tools weergegeven door verschillende soorten cursors. Materials zijn de containers, de inhoud, de informatie, data of andere user interface objecten die worden gemanipuleerd [8]. Materials worden symbolisch weergegeven door vierkantjes. Verder zijn active materials samenstellingen van abstract tools en abstract materials, ook de notatie reflecteert dit (het tool symbool wordt gecombineerd met het material symbool). Ze defini¨eren een interactieve material waarop acties uitgevoerd kunnen worden. Tabel 3.1 geeft een overzicht van de verschillende gedefinieerde tools, materials en active materials. De functionaliteit van de interactor kan meestal afgeleid worden uit de naam. Figuur 3.1 geeft een voorbeeld van de diagramnotatie voor een film viewer UI. Elke component wordt weergeven door een rechthoek (die ook een aanzet geeft tot een modellering van de ruimtelijke indeling van de AUI) met in de linkerbovenhoek het relevante symbool en een beschrijvende naam. De presentatie eenheid die het geheel bevat wordt weergegeven door een rechthoek met een omgeplooide hoek. Naast de notaties voor de Canonical Abstract Components zijn er ook notaties voor annotaties (accolades), groeperingen (kader in stippellijn rond de gegroepeerde elementen) en herhalingen van UI elementen (met 3 gestapelde pijlpunten). CAP zelf bevat geen specifieke constructies voor behaviour modeling, noch wordt door CAP bepaald hoe links tussen het taakmodel of het concrete model
28
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
Tools Action/operation Start/go/to Stop/end/complete Select Create Delete/erase Modify Move Duplicate Perform (& return) Toggle View
Materials Container Element Collection Notification
Active Materials Active material Input Editable element Editable collection Selectable collection Selectable action set Selectable view set
Tabel 3.1: De abstracte interactors (CACs) in CAP.
Figuur 3.1: Voorbeeld van een Canonical Abstract Prototype voor een filmviewer UI [8].
3.4. UMLI
29
gelegd dienen te worden. Het idee is dat tool support deze ondersteuning moet bieden [7].
3.4
UMLi
UML (Unified Modeling Language) [36] is de vaakst gebruikte notatie voor het modelleren van complete software systemen, inclusief de interne applicatielogica [34]. De mogelijkheden van standaard UML voor het modelleren van user interfaces worden vaak beschouwd als ontoereikend, noch bestaat er een universele consensus over hoe men best user interfaces modelleert met UML [34]. Vele modelgebaseerde methodologie¨en voor het ontwerpen van user interfaces hebben daarintegen vaak een slechte ondersteuning voor het modelleren van interne applicatielogica [10]. UMLi breidt UML uit met specifieke notaties voor het modelleren van user interfaces; door een krachtige modelleertaal voor objectgeori¨enteerde software (UML) te combineren met een modeling constructie voor user interfaces tracht men beide problemen op te lossen. UMLi introduceert UI diagrammen, een grafische weergave voor de indeling van de UI. Verder wordt een combinatie van class en activity diagrams gebruikt om de opbouw en functionaliteit van de UI te modelleren. Een aantal nieuwe notaties worden toegevoegd aan activity diagrams om het modelleren van vaak voorkomende UI functionaliteit te vereenvoudigen. Er worden ook een aantal standaard klassen gedefinieerd die abstracte UI interactors (AIOs) kunnen modelleren in de klasse- en UI-diagrammen.
3.4.1
Abstract presentation model
In UMLi worden een aantal gespecialiseerde klassen gedefinieerd waaruit de abstracte specificatie van de UI opgebouwd dient te worden. Een AUI wordt vervolgens voorgesteld met een gewoon UML klassediagram (figuur 3.2(a)) dat deze voorgedefinieerde klassen aanwendt. De generische InteractionClass klasse dient als basis voor de verschillende abstracte interactors. Elke abstracte interactor (AIO) wordt rechtstreeks of onrechtstreeks afgeleid van deze klasse: FreeContainers modelleren de top-level interactie klasse, Containers worden gebruikt om interactie klassen te groeperen, Inputters ontvangen informatie van de gebruiker, Editors maken informatieuitwisseling in twee richtingen mogelijk, Displayers tonen informatie aan de gebruiker en ActionInvokers ontvangen instructies van de gebruiker [10, 34]. Al deze elementen moeten, direct of indirect in een FreeContainer element geplaatst worden.
3.4.2
Diagramnotatie
UMLi definieert naast een UI beschrijving a.d.h.v. klasse diagrammen ook een alternatieve, grafische diagramnotatie om de abstracte UI te beschrijven
30
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
Figuur 3.2: Voorbeeld van een UMLi klassediagram (a) en user interface diagram (b) voor een zoekinterface. Displayers worden gebruikt om zoekresultaten en labels te modelleren; Inputters worden gebruikt voor de zoekparameters [38]. (zie figuur 3.2(b)). De notatie vervult de nood aan een meer intu¨ıtieve en overzichtelijke representatie voor het abstracte UI model. De diagramnotatie modelleert geen ruimtelijke layout maar geeft enkel een opsomming en groepering van de verschillende UI componenten in de abstracte presentatie. Elke AIO krijgt voor deze notatie overigens een grafisch symbool: FreeContainer ), Container ( ), Inputter ( ), Editor ( ), Displayer ( ) en Action( Invoker ( ).
3.4.3
Task modeling
In UMLi worden taken beschreven door een combinatie van UML use cases en activity models waaraan een aantal nieuwe constructies toegevoegd worden. Use cases worden gemapped op top-level activities om user interface functionaliteit te beschrijven [10]. UMLi use cases zijn identiek aan de standaard UML use cases; er wordt niets toegevoegd of uitgebreid. Vanuit een weergave van de gebruiker (“actor”), gerepresenteerd door een stick figure, vertrekken lijnen naar use cases die gerepresenteerd worden door een horizontale ellips. Dit geheel beschrijft een serie van acties die iets van waarde verschaffen aan de actor1 . UML use cases kunnen verder ook interaction activities beschrijven [38] door associaties te leggen tussen use cases en actors of use cases onderling. Een communicates ¡¡ associatie tussen een actor en een use case geeft aan dat de actor interageert met de gebruiker [38]. Een uses ¡¡ associatie tussen twee use cases geeft aan dat de ene use case de andere aanroept of gebruikt. Aan de hand van deze soort use cases worden de taken duidelijk gemaakt die nodig zijn om de doelen van de gebruiker te verwezelijken. Activity diagrams in standaard UML modelleren de stappen die nodig zijn 1
http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
3.4. UMLI
31
om de functionaliteit beschreven in de use cases te structureren. In UMLi worden activities gebruikt om temporele relaties te modelleren tussen de verschillende UI taken, naar analogie met taak modellen [10]. Omdat standaard UML geen notatie heeft om de entry point van een applicatie te modelleren voegt UMLi een expliciete notatie toe, de initial interaction state, weergegeven door een zwart vierkant. De standaard UML activities worden in UMLi bovendien verder uitgebreid met een aantal macros, selection states genoemd, die vaak voorkomend UI gedrag modelleren.
Â
Á
À
De nieuwe macros zijn optional ( ), order-independent ( ) en repeatable ( ) states [10]. Optional duidt op een optionele taak. Activities verbonden aan een optional symbool mogen meerdere malen (of ook niet) uitgevoerd worden. Order-independent verbindt activities die door de gebruiker willekeurig uitvoerbaar zijn. Alle activities verbonden aan het order-independent behavior moeten ´e´en keer uitgevoerd worden. Het repeatable behavior heeft slechts ´e´en verbonden activity die een bepaald aantal keer (moet gespecifieerd worden) uitgevoerd moet worden. Naast de temporele relaties gedefinieerd door de nieuwe macros worden er ook 3 andere constructies ondersteund in de UMLi tool support (zie ook sectie 4.3): sequential (Ñ), concurrent (||) en choice ( ) [39]. De sequential relatie modelleert de opvolging van ´e´en activity op een andere. Concurrent activities worden tegelijk uitgevoerd en choice duidt op een keuze tussen activities. Figuur 3.3 toont de activity diagram constructies voor de nieuwe symbolen en hun geassocieerde events. Om de activities te verbinden met applicatieobjecten worden in UMLi object flows opgenomen in activity diagrams. Object flows leggen relaties tussen objecten uit de applicatie en de UI activiteiten. Vijf verschillende object flow relaties worden gedefinieerd [10, 38]:
interacts ¡¡ duidt op een relatie tussen een abstracte interactor en een action state (een primitieve activity). De relatie duidt op een uitwisseling van informatie tussen een object en de UI interactor, of andersom van de UI interactor naar het object.
presents ¡¡ verbindt een FreeContainer met een activity. Dit geeft aan dat de FreeContainer in kwestie zichtbaar is wanneer de activity actief is.
confirms ¡¡ verbindt een ActionInvoker interactor met een selection state. Dit geeft aan dat de selection state normaal be¨eindigt werd.
cancels ¡¡ relateert een activity of een selection state aan een ActionInvoker. Deze relatie geeft aan dat de activity of selection state niet normaal be¨eindigt werd.
activates ¡¡ verbindt een activity met een ActionInvoker. De verbonden activity wacht op input van de ActionInvoker om te beginnen.
32
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
Figuur 3.3: UMLi constructies voor: (a) sequential (b) concurrent (c) choice (d) order independence (e) optional en (f) repeatable. Een lijn met een pijl associeert de activities met de selection state. De dubbele pijl in (d), (e) en (f) wordt gebruikt om te verduidelijken dat de activity deel uitmaakt van de selection state, en geen gewone verbonden activity is [38].
3.5. USIXML
33
Figuur 3.4 toont een volledige UMLi activity beschrijving voor een zoekinterface. De figuur toont o.a. de notaties voor het nesten van activities, het gebruik van de verschillende object flows, action states, selection states, etc.
Figuur 3.4: Een volledige activity beschrijving voor een interactive zoekinterface in UMLi. [38]
3.5
UsiXML
USer Interface eXtensible Markup Language (UsiXML) [21, 20] is een User Interface Description Language (UIDL) die een ontwikkelaar toelaat een user interface te specifi¨eren op verschillende abstractieniveaus terwijl de mappings tussen deze niveaus bewaard blijven [21]. Een user interface kan gedefinieerd worden beginnende op een bepaald abstractieniveau, om zo tot meerdere final user interfaces te komen of andere abstracte modellen voor verschillende gebruikscontexten [21], gebruikmakende van modeltransformaties. De UsiXML methode past multi-path UI development toe (zie sectie 2.5). UsiXML heeft in de originele specificatie enkel een op XML2 gebaseerde textuele voorstelling. Tools als IdealXML breiden UsiXML uit met een grafische presentatie. 2
http://www.w3.org/XML/
34
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
De user interface wordt in UsiXML beschreven door een UI Model dat 8 verschillende deelmodellen kan bevatten: het mapping model, domain model, AUI model, CUI model, task model, context model, transformation model en resource model. Het UI model is tegelijk ook een superklasse voor deze modellen en bevat gemeenschappelijke features die de andere modellen delen [21]. Het AUI en CUI model beschrijven de abstractieniveaus zoals gedefinieerd in hoofdstuk 2. Het task model wordt uitgedrukt in overeenstemming met de ConcurTaskTrees notatie (sectie 2.2.1). Het domain model modelleert de klassen van de objecten van het systeem. Het mapping model legt relaties tussen de verschillende modellen en hun elementen. Het context model beschrijft de context van de interactie zoals beschreven in het Cameleon framework (sectie 2.4) en bestaat uit een user model, platform model en environment model. Het transformation model beschrijft de transformatieregels voor het transformeren tussen verschillende modellen in de modelstructuur. Niet alle modellen in de structuur zijn verplicht voor elke UI beschrijving; enkel de modellen die nodig zijn om een bepaalde UI te representeren worden opgenomen in het UI model van die user interface [20]. In de verdere bespreking wordt er toegespitst op het AUI model en de diagramnotatie.
3.5.1
Abstract user interface model
In de UsiXML specificatie [19, 21] bevat een AUI een representatie van de UI in termen van Abstract Interaction Objects (AIO) en Abstract User Interface Relationships. AIOs worden verder opgesplitst in Abstract Individual Components (AIC) en Abstract Containers (AC). Abstract Individual Components beschrijven interactieobjecten onafhankelijk van de interactiemodaliteit waarin ze gerepresenteerd zullen worden in de Final UI. AICs zijn de enige abstracte interactors in UsiXML, doch elke AIC kan ´e´en of meerdere facets aannemen om de functie van de AIC verder te verfijnen [19]. Een input facet beschrijft een input actie ondersteund door een AIC. Een output facet beschrijft welke data gepresenteerd kan worden aan de gebruiker door een AIC. Een navigation facet beschrijft de container overgang die een AIC kan toelaten. Een control facet beschrijft de mapping tussen een AIC en de functies beschreven in het domain model. Abstract Container elementen groeperen andere abstract containers of abstract individual components. Ze zijn de abstracte weergave van windows, dialog boxes, layout boxes, etc. van de Concrete en Final UI. Tussen AIOs kunnen Abstract User Interface Relationships gedefinieerd worden. Deze relaties modelleren tegelijk de hi¨erarchische en spatiale indeling van de UI ´en specifi¨eren tegelijk een vorm van behaviour modeling. Vijf relaties worden gedefinieerd [19]:
Decomposition: Modelleert een hi¨erarchische structuur van ACs en AICs.
3.6. DIANE+
35
AbstractAdjacency: Geeft aan dat de twee componenten in tijd of ruimte mekaar opvolgen of aan mekaar grenzen.
Spatio-temporal : Deze relaties kunnen de volgorde van twee elementen modelleren in de ruimte of tijd (afhankelijk van de interactiemethode). Elementen kunnen sequentieel of simultaan voorkomen.
Dialog control : Specifieert een CTT operator tussen twee abstracte componenten en definieert dus een temporele relatie.
Mutual emphasis: Geeft aan dat de componenten later op het concrete niveau expliciet onderscheiden moeten worden van elkaar.
3.5.2
Diagramnotatie
Het UsiXML AUI model heeft geen standaard diagramnotatie, doch er wordt een grafische notatie gebruikt in de IdealXML tool (zie ook sectie 4.4.2) [24]. De abstracte containers ( ) en abstract individual components ( ) hebben beide een grafisch symbool, alsook de verschillende mogelijke facetten van de AIC: output ( ), input ( ), navigation ( ) en control ( ). Zowel ACs als AICs worden in het diagram gerepresenteerd door een afgeronde rechthoek met linksonder het respectievelijke symbool. AICs bevatten op hun beurt ook de verschillende facetten in afgeronde rechthoeken met stippellijnen. Het nesten van de verschillende rechthoeken modelleert de insluiting van componenten in containers en facetten in componenten. De notatie modelleert enkel structurele aspecten van het AUI model, AUI relations worden niet gemodelleerd. Afbeelding 3.5 geeft een voorbeeld van een UsiXML abstract user interface model gerepresenteerd in de IdealXML grafische notatie.
3.6
DIANE+
DIANE+ is een taakspecificatie die de dialoog tussen de gebruiker en het systeem modelleert. DIANE+ gaat uit van 3 viewpoints (representaties) die een interactieve applicatie kunnen modelleren. De Conceptual Representation is het viewpoint van de analyst en beschrijft de algemene logica van het systeem en de communicatie van de UI met de applicatielogica. De External Representation beschrijft de presentatie naar de gebruiker toe (UI). De elementen van de Conceptual Representation worden met de elementen van de External Representation (presentatie objecten) ge¨ıntegreerd in het laatste viewpoint (van de programmeur), de Internal Representation [41]. De DIANE+ specificatie dekt de conceptual representation van de UI en definieert hiervoor een schematische voorstelling en formalisme.
36
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
Figuur 3.5: Voorbeeld van een UsiXML AUI model voor een internet radio player in IdealXML [47]. Het DIANE+ model maakt het modelleren van de UI mogelijk a.d.h.v. een onbepaald aantal abstractieniveaus, waarbij het hoogste niveau de meest algemene beschrijving geeft van de doelen van de applicatie. Deze doelen worden vervolgens opgesplitst in sub-doelen die op hun beurt opgesplitst worden in sub-sub-doelen, etc., die corresponderen met de lagere abstractieniveaus. Deze lagere abstractieniveaus worden progressief concreter in hun beschrijving van de interactie van de gebruiker met het systeem, door het defini¨eren van de opeenvolging van de processen, constraints, etc. Het laagste abstractieniveau bevat de elementaire processen (wanneer verdere opsplitsing onnodig of ongewenst is), die de functionaliteit volledig beschrijven.
3.6.1
Data model
Het DIANE+ data model (OPAC genoemd, naar Object, Presentation, Abstraction, Control) modelleert de data die gebruikt wordt in de applicatie en modelleert tegelijk ook de representatie van die data. Het data model bestaat uit 3 delen [41]:
Abstraction: De eigenlijke data die in het object opgeslagen wordt, zoals een lijst van personen, de naam van een boek, etc.
Presentation: De externe representaties van de abstraction (welke data wordt weergegeven) en de relaties tussen de objecten en de DIANE+ operations (zie volgende sectie).
Control : Een set van methoden om de objecten te beheren/manipuleren
3.6. DIANE+
37
(zoals het cre¨eren of weergeven). Elk data object wordt afzonderlijk voorgesteld door een combinatie van deze 3 elementen. Belangrijk is dat de data hiermee haar eigen externe en interne representatie voorziet. Hierdoor moet geen data management opgenomen worden in het DIANE+ schema, dat enkel de data modelleert in de context van de applicatie (’wat gebeurt er met de data’) [41].
3.6.2
Procedures
Een DIANE+ procedure modelleert de dialoog tussen de gebruiker en het systeem op een schematische wijze. Een procedure wordt in DIANE+ gedefinieerd als een verzameling van operations verbonden door precedences. Een operation is een proces (e.g. print de pagina) of een boom van processen en sub-processen die een process in zijn geheel beschrijven [41]. Een precedence correspondeert met de CTT Enabling (¡¡) operator en defineert een sequenti¨ele link tussen operaties. Om de procedures schematisch voor te stellen definieert DIANE+ een formalisme voor de verschillende soorten precedences en operations. Afbeelding 3.6 geeft een overzicht. Drie soorten operations worden gedefinieerd: automatic, interactive en manual. Automatic operations worden automatisch door het systeem uitgevoerd. Interactive operations vergen input van de gebruiker en manual operations moeten door de gebruiker worden uitgevoerd. Operations verbonden aan een user-triggered symbool ( ) worden door de gebruiker ge¨ınitialiseerd, operations zonder dit symbool worden door het systeem per default uitgevoerd.
Figuur 3.6: De verschillende DIANE+ constructors [41]. Het formalisme definieert ook constraints op operations. Afbeelding 3.7 toont
38
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
een voorbeeld: “Book number” modelleert een required operation (aangegeven door een “r” in de rechter onderhoek) die het nummer van een boek opvraagt. Required operations moeten uitgevoerd worden om het programma succesvol te be¨eindigen. De gebruiker krijgt de keuze tussen het invoeren van het nummer met een toetsenbord of het inscannen van de barcode van het boek. De {1,1} notatie in het model signifieert dat ten tenminste ´e´en en ten hoogste ´e´en constrained operatie (aangegeven door een “c” in de rechter onderhoek) in de sub-operation uitgevoerd moet worden om de operation te voltooien. De twee optional operations (aangegeven door een “o” in de rechter onderhoek) kunnen vrij uitgevoerd worden. De {1,3} notatie geeft aan dat de “Book number” operation zelf minimum ´e´en en maximum drie keer uitgevoerd moet worden.
Figuur 3.7: Het “Book number” voorbeeld van operaties met constraints [41]. Met constraints op operations, in combinatie met precedences, kan UI gedrag beschreven worden. Precedences modelleren de opeenvolging van operations; een operation waarvan de voorgaande operation nog niet uitgevoerd is kan dus zelf nog niet uitgevoerd worden. Een operation zonder precedence kan uitgevoerd worden wanneer de gebruiker het verkiest. Een operation zonder constraints kan herhaaldelijk uitgevoerd worden. Verplichte keuzes worden gemodelleerd door operations met {1,1} constraints op hun subtaken, etc [41]. De vergelijkende tabel 3.3 in sectie 3.9 geeft een meer compleet overzicht. De DIANE+ data objecten, schematisch voorgesteld door 3 mekaar overlappende ellipsen, worden in het model verbonden met operations d.m.v. grijze pijlen om informatieuitwisseling tussen de UI actie en het data object te beschrijven. De richting van de informatieuitwisseling (input, output, input/output) wordt aangegeven door de richting van de pijl, waarbij input/output gemodelleerd wordt met een dubbele pijl. Een rechthoek, verbonden aan een operation door een lijn, introduceert een nieuw niveau van verfijning (sub-operation) in de specificatie. Sub-operations beschrijven de verbonden operation in meer detail. De operations binnen dit nieuwe niveau kunnen ook op hun beurt verder verfijnd worden, wat resulteert in het nesten van operations. Hierdoor worden abstractieniveaus gecre¨eerd die de taak steeds gedetailleerder beschrijven. Afbeelding 3.8 toont een voorbeeld van een email client in DIANE+ dat dit illustreert.
3.6. DIANE+
39
Figuur 3.8: Een representatie van een email client in DIANE+ [41]. De donkere rechthoeken corresponderen met verdere verfijningen van operations.
40
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
3.7
MARIA
MARIA (Model- based lAnguage foR Interactive Applications) is een modelbased user interface description language (UIDL). MARIA ondersteunt de beschrijving van de UI op twee niveaus: een abstracte UI beschrijving en een concrete UI beschrijving. De abstracte UI beschrijving kan worden ’verfijnd’ naar verschillende eindplatformen met een platform-specifieke concrete beschrijving. MARIA is een tekstuele (XML) beschrijving van de user interface, er wordt geen grafische notatie voorzien om de abstracte user interface te representeren. De abstracte beschrijving van de user interface bestaat uit een data model en ´e´en of meerdere presentations met elk een dialog model. Elk wordt afzonderlijk besproken.
3.7.1
Data model
Elke UI description in MARIA wordt ondersteunt door een data model dat de data die gebruikt wordt door de user interface modelleert. Het data model wordt uitgedrukt in de XSD type definition language3 . De interactors in het abstracte en concrete UI model worden verbonden aan de types gedefinieerd in het data model. Ook voor het data model worden twee abstracties beschreven: een concrete en een abstract model, waarbij het concrete model een verfijning is van het abstracte model.
3.7.2
Presentations
Elke interface kan ´e´en of meer presentations bevatten. Een presentation bevat connections, elementaire interactors en interactor compositions [33]. Connections geven de opeenvolging van presentations aan die getriggerd worden door interacties met de UI. Drie soorten connections worden voorzien: elementaire, complexe en conditionele connections. Complexe connections bevatten Boolean operatoren; conditionele connections worden geassocieerd met een bepaalde voorwaarde [33]. Interactors komen overeen met de AIOs die besproken werden in sectie 2.2.3. Twee soorten interactors zijn beschikbaar: interaction objects, die een in/output functie verzorgen, en only output objects, die zoals de naam al doet vermoeden enkel output verzorgen. Beide interactors worden verder ingedeeld in meer specifieke interactie objecten (zie tabel 3.2). Elke interactor wordt geassocieerd met een event; het type van dit event hangt af van het soort interactor (events worden verder besproken in sectie 3.7.3). Interactor compositions tenslotte groeperen of modelleren relaties tussen interactors onderling of tussen interactors en interactor compositions. 3
http://www.w3.org/XML/Schema
3.7. MARIA
41 selection
edit interaction object control
only output object
single choice multiple choice text edit object edit numerical edit position edit navigator activator
interactive description object description feedback alarm text
Tabel 3.2: Tabel van de verschillende interactors in MARIA. Een kolom bevat verfijningen van elementen in de voorgaande kolom (op dezelfde rij).
3.7.3
Dialog model
Aan elke presentation is een dialog model verbonden dat modelleert welke events, acties uitgevoerd door de gebruiker, beschikbaar zijn op een bepaald tijdstip [33]. Het gedrag van de events en hun handlers wordt gespecifieerd met CTT operatoren (zie sectie 2.2.1). Events kunnen twee vormen aannemen [33]:
Property Change Events: Worden getriggerd wanneer de status van een UI interactor wijzigt.
Activation Events: Worden getriggerd door activators, een speciaal soort UI interactor die het starten van een bepaalde applicatie actie modelleren.
Het uitvoeren van een bepaald event kan de set van de voor de gebruiker beschikbare events wijzigen [33].
42
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
3.8
CAP3
CAP3 [46] is een abstract user interface modeling taal die behaviour modeling integreert in de bestaande Canonical Abstract Prototypes specificatie (zie sectie 3.3). CAP3 tracht m.a.w. CAP om te vormen van een zuivere diagramnotatie naar een modeling taal [46]. De specificatie wordt opgesplitst in een structureel en een behavioural gedeelte.
3.8.1
Structurele specificatie
Voor de structurele specificatie wordt de CAP notatie uitgebreid met een aantal nieuwe of gewijzigde constructies. Attributes worden toegevoegd aan de abstracte componenten om een aantal ambigu¨ıteiten op te lossen of ontbrekende constructies toe te voegen (zoals vb. een isSecret attribuut dat toegevoegd wordt aan input om een paswoord veld te modelleren of een maxSelectedElements attribuut dat toegevoegd wordt aan selectable collection om een onderscheid te maken tussen single selection en multiple selection [46]). De bestaande notatie voor een herhaling van UI elementen (3 gestapelde pijlpunten) kan onduidelijkheden cre¨eren wanneer het onzeker is op welke elementen de notatie slaat. In figuur 3.1 is het niet zeker of enkel de Title component herhaald moet worden of ook de Length component. CAP3 introduceert daarom een nieuwe groepering, RepeatedConceptualGroup (weergegeven door een rechthoek met stippellijn), die deze ambigu¨ıteit oplost. Er wordt ook een gewone ConceptualGroup ge¨ıntroduceerd die bepaalde behaviour constructies kan vereenvoudigen (zie sectie 3.8.2). Beide conceptual groups zijn denkbeeldige groeperingen van elementen, geen werkelijke containers of interactors. In tegenstelling tot in CAP waar de top-level container (presentation unit) een aparte constructie is, weergegeven door een rechthoek met geplooide hoek, kan in CAP3 elk element een top-level presentation unit zijn, gegeven dat het niet vervat is in een andere component. Bovendien is het, net als in CAP, mogelijk om de notatie te gebruiken met enkel de generische tool, material en activematerial componenten; de andere specifieke componenten worden als optioneel beschouwd. Figuur 3.9 toont de abstracte UI van afbeelding 3.1 uitgedrukt met CAP3.
3.8.2
Behaviour specificatie
Om UI gedrag te specifi¨eren wordt de notatie uitgebreid met temporele relaties tussen UI componenten. De behaviour specificatie van CAP3 is ook een grafische notatie; relaties worden visueel aangegeven in het UI diagram met constructies van elementen en interconnecties. De CAP3 relaties zijn rechtstreeks gebaseerd op enkele temporele operatoren van CTT (sectie 2.2.1):
3.8. CAP3
43
Figuur 3.9: Voorbeeld van een CAP3 diagram [46]. Vergelijk met het CAP diagram uit figuur 3.1.
Choice: Een keuze tussen twee componenten wordt weergegeven door een rode stippellijn tussen de componenten. Wanneer de keuze een overgang naar een andere taak (presentation unit) inhoudt dan wordt de rode lijn weggelaten en worden enkel de taakovergangen gemodelleerd.
Enabling: Er vertrekt vanuit een component een volle zwarte lijn met open pijlpunt naar de component die wordt ingeschakeld door die component. Dit wordt in CAP3 een Activate relatie genoemd.
Parallel : Hier is geen speciale notatie voorzien; meerdere tools worden gewoon in ´e´en container geplaatst, dit geeft impliciet aan dat zij parallel uitvoerbaar zijn.
Disabling: De CAP Stop/end/complete tool wordt gebruikt om de CTT disabling relatie te modelleren. Deze tool schakelt de container waarin ze vervat is uit.
Suspend-resume: Hier wordt de CAP Perform (& return) gebruikt in een gelijkaardige constructie als Disabling.
Afbeelding 3.10 illustreert de constructies visueel. Andere operatoren zoals Iteration en Optional worden gemodelleerd met gewone tools, dus zonder nieuwe notatie. Alle taken in CAP kunnen meermaals uitgevoerd worden (tenzij temporele constructies dit verhinderen) en zijn in principe optioneel. Voor informatieuitwisseling tussen componenten worden andere connectoren gebruikt. De twee soorten informatieuitwisseling zijn:
44
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
Figuur 3.10: De CAP3 relaties: (a) Choice met taakovergang (b) Choice (c) Disabling (d) Enabling (e) Parallel (c) Suspend-resume [46].
3.9. EVALUATIE
45
Use: component A gebruikt informatie uit component B
Update: component A updatet de informatie in component B
Een grijze stippellijn met een volle pijlpunt signifieert een Update relatie. De Use relaties kunnen impliciet aangegeven worden door het inbedden van een tool in een container (wat aangeeft dat de tool de informatie uit de container gebruikt) of door een zwarte stippellijn met open pijlpunt tussen twee componenten. Afbeelding 3.9 toont het gebruik van de relaties. De Find tool updatet de informatie in de Film Clips container en gebruikt informatie uit de Film Clip ID / Title container. De ConceptualGroup linksonder toont het verbinden van een Update relatie aan alle tools in de groep, dit vereenvoudigd de notatie ´en maakt ze leesbaarder. CAP3 bevat ook de mogelijkheid om context-informatie te modelleren (bv. de fysieke lokatie van de gebruiker). Dit gebeurt a.d.h.v. “domain objects” die een referentie bevatten naar een element van een ander model [46]. Net als bij andere componenten kunnen Update en Use relaties gelegd worden tussen deze objecten en andere componenten om de relevante relaties te modelleren.
3.9
Evaluatie
Om de verschillende descriptions te evalueren wordt er een vergelijking gemaakt tussen de constructies en elementen van de presentation, dialog en grafische diagramnotatie van de verschillende descriptions. Nadien worden de notaties vergeleken op basis van een aantal criteria/richtlijnen uit de literatuur.
3.9.1
Presentation
De presentation van de AUI bepaalt op welke manier de user interface gemodelleerd wordt en welke abstracte interactors beschikbaar zijn in de notatie. Meer verschillende interactors kunnen leiden tot een meer expressieve notatie. Deze sectie zal zich vooral richten op de abstracte interactors van de descriptions. Sectie 3.9.3 bespreekt de grafische notatie(s) van de descriptions. CAP/CAP3 en MARIA hebben de meeste AIOs, waardoor veel user interface functionaliteit gemodelleerd kan worden met specifieke interactors, zonder te moeten teruggrijpen naar generische, en dus minder expressieve interactors. CAP en CAP3 (tabel 3.1) hebben vooral veel soorten action componenten (tools), terwijl MARIA veel diverse input/output componenten (edit en only output) heeft (tabel 3.2). Het is moeilijk om definitief te bepalen welke set van AIOs leidt tot een meer expressieve notatie. Het is bijvoorbeeld niet duidelijk hoeveel de vele opsplitsingen van “edit” (zie tabel 3.2) bijdragen tot de expressiviteit van de MARIA notatie. De vele tools in CAP en CAP3 voor
46
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
vaak voorkomende UI functionaliteit als delete of stop zijn wel veelzeggender dan de eerder generische action componenten in MARIA. CAP maakt geen onderscheid tussen single selection of multiple selection, CAP3 en MARIA doen dit wel. CAP en MARIA hebben geen notatie voor paswoord velden, een toevoeging die CAP3 wel heeft. Notification componenten (zoals notification in CAP/CAP3 en alarm of feedback in MARIA) zijn bovendien ook afwezig in de andere descriptions. UsiXML en UMLi hebben beide een gelijkaardig aantal interactors. UsiXML maakt een onderscheid tussen navigator en control facetten van acties, in UMLi gemodelleerd met een enkele ActionInvoker. Een enkele action component is misschien t´e generisch, een opsplitsing zoals in UsiXML kan op zijn minst nuttig zijn in het licht van het genereren van navigeerbare prototypes. UMLi heeft twee soorten containers: FreeContainers (voor de top-level presentation unit) en Containers. Dit is misschien een ietwat overbodige opsplitsing, een top-level Container kan immers ge¨ınterpreteerd worden als een FreeContainer. Een gelijkaardig onderscheid wordt gemaakt in CAP waar de top-level presentation unit een aparte component is, in CAP3 wordt deze top-level interactor verwijderd en vervangen door een Container component. In DIANE+ blijft het modelleren van de user interactie beperkt tot het combineren van het user-triggering symbool (een primitieve methode om een action of input interactor te specifi¨eren) met de verschillende soorten operations, waaronder ook de interactieve operation die user input modelleert. Er zijn verder geen andere constructies voor UI componenten (UI output wordt impliciet gemodelleerd in een operation: vb. “Read the message”).
3.9.2
Behaviour
Om de kwaliteit van de behaviour modeling van de verschillende descriptions te beoordelen wordt er een vergelijking gemaakt met de ConcurTaskTrees (sectie 2.2.1) operatoren. Tabel 3.3 geeft een overzicht van de verschillende abstracte user interface specificaties die behandeld werden en hun ondersteuning voor de verschillende operatoren die onderscheiden worden in ConcurTaskTrees. CAP is louter een diagramnotatie en heeft bijgevolg geen expliciete constructies voor behaviour modeling. Impliciet zijn componenten vervat in eenzelfde Container echter wel concurrent uitvoerbaar [46]. CAP3 breidt CAP uit met behavioural informatie voor een aantal temporele relaties. De Iteration (T) constructie is enkel ondersteund wanneer ze gebruikt wordt om herhalingen van een interactor in de UI te modelleren (met RepeatedConceptualGroup). Concurrency with information exchange (T1 |rs| T2) wordt uitgedrukt met een Update relatie.
3.9. EVALUATIE
47
In de MARIA specificatie worden CTT operatoren expliciet opgenomen in het dialog model om het temporele gedrag van events te modelleren. Hierdoor zijn per definitie alle operatoren ondersteund. Ook het task model in UsiXML neemt alle CTT operatoren op; het UsiXML task model is namelijk een CTT taak model. Verder worden ook dialog control relaties opgenomen tussen componenten in het AUI model, ook gemodelleerd met een CTT operator. De DIANE+ specificatie kan UI gedrag modelleren door het combineren van precedences en constraints (optional, required, constrained) op haar operations. Deze aanpak is vrij eenvoudig en het beperkte aantal constructors zorgt voor een overzichtelijke behaviour specificatie. Het is onduidelijk of de concurrency (T1 ||| T2) relatie ondersteund is in DIANE+. Het is zeker mogelijk om taken te modelleren die impliciet concurrent zijn, maar er is geen notatie om dit expliciet aan te geven. Het aantal temporele operatoren in UMLi is beperkt, sommigen kunnen echter wel gezien worden als een combinatie van operatoren, zie tabel 3.3. In principe zijn alle temporele operatoren ondersteund zolang ze modelleerbaar zijn met UML activity diagrammen. Enkel de door UMLi expliciet voorziene operatoren werden echter opgenomen in de vergelijking. Het doel van UMLi, de vereenvoudiging van UML specificaties voor het modelleren van user interfaces [10, 38], wordt gemist wanneer voor deze gevallen (meer) complexe activity constructies gemaakt moeten worden in afwezigheid van een toegewijd symbool. Operator T1 ||| T2 T1 rs T2 T1 |rs| T2 T1 | | T2 T1 r¡ T2 T1 ¡¡ T2 T1 rs ¡¡ T2 T1 | ¡ T2 T T1(n) [T]
CAP X
UMLi X X X X
X X X
CAP3 X X X X X X X X
MARIA X X X X X X X X X X X
UsiXML X X X X X X X X X X X
DIANE+ X X X X
X
Tabel 3.3: Ondersteunde temporele operatoren (CTT) of equivalenten in de verschillende abstracte UI beschrijvingen.
48
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
3.9.3
Diagramnotatie
Een diagramnotatie geeft de abstracte user interface grafisch weer in termen van zijn AIOs, hun eventuele groeperingen, onderlinge connecties of andere constructies specifiek aan de notatie (zie tabel 3.4 voor een overzicht). MARIA heeft geen grafische notatie voor haar abstract user interface model en zal in deze sectie dan ook niet verder aan bod komen. Ook DIANE+ heeft geen diagramnotatie. De grafische notatie van CAP is expressief, overzichtelijk, gestroomlijnd en makkelijk interpreteerbaar zonder grondige voorkennis [8]. CAP3 heeft qua grafische notatie grotendeels dezelfde voordelen als CAP. CAP3 werkt met dezelfde set van componenten en is ook structureel vrijwel identiek. De toevoeging van relaties tussen componenten introduceert wel visuele overhead. Een notatie die zowel structurele als behavioral informatie modelleert in ´e´en slag is misschien ook minder gericht, doch de constructies voor de temporele relaties zijn niet overheersend of storend in de zin dat de structurele specificatie aan overzichtelijkheid verliest. De grafische notatie van UMLi (user interface diagram) is vrij beperkt; enkel de elementen en hun groeperingen worden weergegeven. De fysieke locatie van de AIOs in het UI diagram heeft geen enkel bepalend effect op de ruimtelijke indeling van de concrete en final UI. Hierdoor is het UMLi UI diagram niet meer dan een visuele “inventaris” van de UI elementen, en veel minder expressief dan de diagrammen in CAP en CAP3. De AIOs van UMLi zijn ook vrij generisch en beperkt. Het kleine aantal AIOs in UMLi reduceert echter wel de complexiteit van de abstracte presentatie, wat een voordeel kan zijn voor de leesbaarheid [38]. De grafische notatie voor UsiXML AUI modellen (in de IdealXML tool) geeft geen UsiXML relationships weer [24], en dus ook geen temporele of ruimtelijke relaties tussen componenten. De notatie is dus net als de notatie van UMLi meer een visuele inventaris van de AOIs en hun containment relaties. Relaties Containment Ruimtelijk Behaviour
CAP X X
UMLi X
CAP3 X X X
UsiXML X
Tabel 3.4: Mogelijke relaties tussen componenten in de verschillende diagramnotaties.
3.9.4
Vergelijking met richtlijnen
Cognitive dimensions [12, 13] zijn een set van design principes/criteria voor notaties. De dimensions zijn een manier om te bepalen hoe goed een notatie
3.9. EVALUATIE
49
de vooropgestelde activiteit ondersteunt. Een aantal passende of relevante cognitive dimensions worden in deze sectie besproken voor de verschillende AUIs. In [25] worden richtlijnen voorgesteld die gebruikt kunnen worden om de kwaliteit van visuele notaties in software engineering te beoordelen. Ook deze richtlijnen worden opgenomen in de bespreking; let op dat deze criteria enkel op de visuele componenten (de diagramnotaties of schematische notaties) van de descriptions slaan. De abstractions dimensie bepaalt of er meerdere weergaves van eenzelfde model of constructie zijn met als doel het verbergen of tonen van details. Er zijn notaties met generische AIOs die gebruikt kunnen worden in plaats van meer specifieke AIOs (CAP en CAP3). Ook MARIA heeft generische AIOs (edit, control, only output etc), maar het is onduidelijk of deze gebruikt mogen worden in een specificatie [46]. Een ConceptualGroup in CAP3 is mogelijk ook een abstraction (update of use relaties laten vertrekken uit elke component is minder abstract in deze context). In een diffuse notatie zijn er veel symbolen of constructies nodig om een betekenisvol model te krijgen, het tegenovergestelde is waar voor een terse model. Vanwege de verschillende doelstellingen van de descriptions is dit moeilijk te vergelijken. Een UMLi of DIANE+ model is dichter bevolkt maar modelleert ook meer (of andere) informatie. Een diagramnotatie die ook de ruimtelijke indeling van componenten kan modelleren (zoals CAP of CAP3) kan wel meer ruimte in beslag nemen dan een diagramnotatie die dit niet doet (UsiXML of UMLi). Complexere notaties (UMLi, DIANE+) of XML-gebaseerde notaties (UsiXML, MARIA) zijn meer error-prone (het is makkelijker om fouten te maken). Tool support heeft hier echter ook een belangrijke ondersteunende rol (zie sectie 4.8). De UMLi use cases, activity diagrams, class diagrams en UI diagrams zijn intergerelateerd zonder dat dit expliciet wordt aangegeven, een vorm van hidden dependencies. In UsiXML hangt het mapping model af van alle andere modellen. CAP en CAP3 scoren het beste voor role expressiveness, een criterium dat bepaalt hoe duidelijk de rol van de verschillende componenten op te maken is uit hun notaties. De CAP en CAP3 component symbolen zijn logische samenstellingen van verschillende deelsymbolen. Een Editable collection ( ) is een conceptuele samenstelling van een Modify ( ) tool en een Collection ( ), ook de symbolen reflecteren dit. Alle descriptions houden zich aan de semiotic clarity regel die bepaalt hoe duidelijk de symbolen en constructies zijn in hun gebruik - er moet een mapping zijn van ´e´en interactor op maximum ´e´en symbool of constructie. Gerelateerd hieraan is de perceptual discriminability die aangeeft hoe makkelijk belangrijke
50
HOOFDSTUK 3. ABSTRACT USER INTERFACE DESCRIPTIONS
of unieke elementen te onderscheiden zijn van de rest. CAP3 geeft relaties voor informatieuitwisseling tussen componenten weer a.d.h.v. pijlen die beter in het oog springen (een grijze pijl voor Update en een gestippelde pijl voor Use). Complexity management slaat op constructies die de complexiteit van de notatie proberen te beperken door de notatie te modularizeren of hi¨erarchisch te structureren [25]. De ConceptualGroups in CAP3 zijn een manier om het aantal update relaties te beperken en dus de visual clutter van de notatie te minimaliseren. DIANE+ reduceert de complexiteit van haar notatie door abstractieniveaus visueel aan te geven met donkere rechthoeken. Een andere vorm van complexity management is de diagramnotatie in UMLi. Hoewel de notatie ook een andere rol vervult (het aangeven van containment relaties tussen componenten), is het ook een vereenvoudigde weergave van het abstract presentation model (UML diagram). Enkel CAP3 integreert behaviour en presentatie in ´e´en diagram (een bevordering van de cognitive integration van de notatie). De visual expressiveness van de notatie geeft aan hoe divers en visueel onderscheidbaar de diagram notaties zijn (gemeten in dimensies of variabelen als kleur, vorm, etc). Voor CAP en UMLi wordt er een redelijk onderscheid gemaakt tussen containers en interactors, doch de notaties van beide verschillen in principe enkel in vorm, een ´e´en-dimensionele factor. In de UsiXML notatie hebben de verschillende interactor symbolen kleuren, een tweede dimensie. CAP3 gebruikt een rode lijn om keuze relaties tussen componenten te modelleren en een grijze pijl om Update relaties te modelleren. Dual coding slaat op het simultaan weergeven van visuele en textuele feedback, een effici¨entere manier om informatie over te maken. Alle notaties combineren in hun modellen symbolen met een omschrijvende text voor de interactors en scoren hier dus goed. Descriptions met eenvoudigere grafische notaties, zoals UsiXML en UMLi, scoren beter voor de graphic economy richtlijn. Modellen met minder symbolen zijn minder complex en leesbaarder. CAP en CAP3 hebben meer symbolen dan er in een oogopslag onderscheidbaar zijn (tot zes verschillende perceptuele alternatieven zijn makkelijk te onderscheiden [25]). Wanneer een CAP of CAP3 diagram te ingewikkeld dreigt te worden kan men echter generische componenten gebruiken om het diagram te vereenvoudigen. De cognitive fit van de notaties geeft aan op welk doelpubliek de notatie toegespitst is (e.g. experten, beginners). De CAP, UMLi en UsiXML diagramnotaties zijn makkelijk bruikbaar aangezien ze enkel containers en interactors modelleren. CAP3 vergt een iets diepere kennis wegens de integratie van behaviour modeling relaties in de notatie. DIANE+ is complexer en is duidelijk een notatie voor meer geavanceerde gebruikers.
Hoofdstuk 4 Tool support 4.1
Inleiding
Verschillende soorten tool support voor UIDLs en AUIs kunnen onderscheiden worden; ruwweg vindt men volgende soorten tools terug in de literatuur:
Editing tools zijn de meest courante vorm van tool-support en bieden specifieke ondersteuning voor het opbouwen van een bepaald UI model. Het gebruik van een aangepaste tool maakt het opbouwen van een AUI eenvoudiger.
Transformation tools maken (semi-)automatische overgang van een bepaald model in de relevante modelstructuur naar een ander model mogelijk. Dergelijke tools zijn belangrijk indien men aan model-based user interface design wil doen in de context van een framework met deelmodellen.
Generating of rendering tools zijn een specifieke vorm van transformation tools. Ze genereren programmacode uit de UI description. Het genereren van een definitieve, functionele final UI uit de syntax en semantics van bepaalde abstracte user interface specificaties is echter niet per definitie gewenst [8]. Om echt bruikbare en krachtige user interfaces te ontwikkelen is vooralsnog menselijke creativiteit en probleem-oplossend denken nodig [8, 43]. Dit wil niet zeggen dat automatisch gegenereerde UIs geen plaats hebben in model-based user interface design; ze kunnen bijvoorbeeld dienen als snelle interactieprototypes om de flow van de UI te evalueren [5].
Niet alle tool ondersteuning hoeft even krachtig of verfijnd te zijn. Constantine [7] beschrijft een visie op CAP tool support waarin de mate van “verfijndheid” als vergelijkend kenmerk dient om een indeling te maken in verschillende niveaus van tool support. De meest simpele vorm van “tools” in deze indeling zijn low-tech middelen als sticky notes en whiteboards. Deze methode is snel en flexibel en de vluchtige aard van deze prototypes bevordert experimentering 51
52
HOOFDSTUK 4. TOOL SUPPORT
[7]. Een eerste vorm van software tool support zou een eenvoudige teken applicatie zijn (een editing tool) waarbij abstracte interactie objecten geplaatst kunnen worden in een diagram. Een verdere verfijning van de tool support kan ondersteuning bieden voor het verbinden van de abstracte interactie objecten met hun corresponderende taken in het taakmodel. Op een nog hoger niveau kan het abstracte prototype verbonden worden met een concrete prototype. Op het hoogste niveau kunnen de abstracte componenten gelinkt worden aan de werkelijke widgets in de final user interface. Eerst worden ´e´en of meerdere tools besproken voor elke AUI description die behandeld werd in Hoofdstuk 3. Op het einde van dit hoofdstuk zal een vergelijking en evaluatie gemaakt worden van de tools. Ook hier worden waar gepast richtlijnen uit de literatuur besproken.
4.2 4.2.1
CAP CanonSketch
CanonSketch [5] is een user interface modeling tool die het aanmaken van Canonical Abstract Prototypes en Wisdom Presentation Models [30], een uitbreiding van UML voor het modelleren van presentatie-aspecten van een UI, ondersteunt. De gebruiker krijgt een paneel met Canonical Abstract Components die geplaatst, gegroepeerd, geresized en gelabeld kunnen worden in een diagram op een wijze sterk gelijkend op die van traditionele tekenprogramma’s. De nadruk ligt niet op formalismen en semantiek maar op het bereiken van een zo makkelijk mogelijk te gebruiken applicatie [5]. CanonSketch biedt de mogelijkheid om automatisch een HTML prototype te genereren van een Canonical Abstract Prototype met als doel het snel en effici¨ent testen van navigatiepaden in de UI [5]. Het prototype wordt gerendered in een in de tool ingebouwde web browser. De Wisdom methode breidt UML uit met stereotypes voor het modelleren van de UI presentation [30]. In de CanonSketch tool wordt er een mapping gelegd tussen deze stereotypes en een aantal CAP3 componenten. De tool beoogt een automatische synchronisatie tussen het Wisdom UML presentatiemodel, het Canonical Abstract Prototype en een functioneel HTML prototype dat gegenereerd kan worden [6]. De doelstelling is het introduceren van een formalisme (Wisdom) in UI design dat gecombineerd wordt met een expressieve en leesbare notatie (CAP).
4.2. CAP
53
Figuur 4.1: De CanonSketch tool: (a) CAP editor (b) Wisdom editor [5].
4.2.2
DialogSketch
DialogSketch [27] is een tool die ConcurTaskTrees taak specificaties verbindt met Canonical Abstract Prototypes via een gemeenschappelijk UML model. Het doel van de applicatie is het simuleren van de dynamische aspecten van de user interface door de CTT taakboom uit te voeren (“execute”) en de in de taakboom actieve taken terug te koppelen naar het Canonical Abstract Prototype. De tool biedt een grafische editor voor zowel CAP als CTT modellen, afbeelding 4.2 toont een voorbeeld. De tool bouwt verder op een eerdere mapping van de ConcurTaskTrees specificatie op UML 2.0 klassen (tasks model ) [28]. Deze mapping wordt verder uitgebreid om ook Canonical Abstract Prototypes te ondersteunen (presentation model ). De mapping tussen de taken van het task model en de abstract components van het presentation model wordt gelegd met UML dependency relaties [27]. Om de interactie met het systeem te simuleren wordt de taakboom omgezet in een task execution tree die de originele CTT taakboom organiseert rekening houdend met de prioriteitsregels tussen operatoren [27]. De mappings tussen het task en presentation model zorgen ervoor dat user interactie interactie (klikken op een taak in het CAP model) teruggekoppeld kan worden naar het CTT model (de taak wordt voltooid), waardoor nieuwe taken enabled of disabled worden (afhankelijk van de semantiek gedefinieerd door de verbonden operator). Op deze manier kan de ontwikkelaar de navigatie van de UI testen op het niveau van het abstracte prototype.
54
HOOFDSTUK 4. TOOL SUPPORT
Figuur 4.2: DialogSketch UI: (a) CAP editor (b) CTT editor [27].
4.3
UMLi
ARGOi1 [39] is een uitbreiding van de ArgoUML2 tool voor het opbouwen van UML modellen. De plugin ondersteunt de ontwikkeling van UMLi modellen binnen de ArgoUML omgeving. Met ArgoUML kunnen UML modellen grafisch opgemaakt worden op een intu¨ıtieve point-and-click wijze. Componenten worden geselecteerd en “getekend” op het diagram. De ArgoUML UI bestaat uit 4 panelen: het editing panel, waarin componenten geselecteerd kunnen worden en toegevoegd kunnen worden aan de werkruimte; het navigation panel, waarmee de gebruiker kan selecteren welk model actief is in het editing panel; het detail panel dat o.a. de properties van de componenten weergeeft; en het to do panel waarin nog te voltooien werk opgesomd kan worden en gesorteerd per prioriteit. In de ARGOi tool worden ook UMLi componenten ge¨ıntegreerd in deze panelen. Afbeelding 4.3 toont alle componenten in een voorbeeld. ARGOi voorziet ondersteuning voor het opmaken van UMLi UI diagrammen. Om het modelleren van UMLi activity diagrammen mogelijk te maken wordt er ook ondersteuning voor selection states en object flows in activity diagrams voorzien. Er werden ook een aantal wizards toegevoegd die de gebruiker helpen bij het modelleren van de UMLi temporele relaties en object-flows [39]. Om een temporele relatie toe te voegen aan het diagram volstaat het een activity in het diagram te selecteren. Vervolgens krijgt de gebruiker een popup waarin hij de gewenste temporele relatie kan selecteren. Indien de gebruiker een keuze maakt wordt de relevante constructie gegenereerd zoals weergeven in afbeelding 3.3. ARGOi controleert ook tijdens het editen of de integriteit van het model bewaard blijft. Wanneer een klasse of een interactie object met geassocieerde 1 2
http://trust.utep.edu/umli/download2.html http://argouml.tigris.org/
4.4. USIXML
55
Figuur 4.3: De ARGOi tool voor UMLi [10]. Boven rechts het editing panel; boven links het navigation panel; onder rechts het detail panel; onder links het to do panel. relaties in andere modellen gedeleted wordt wordt de gebruiker gewaarschuwd over de associatie en gevraagd om het deleten te bevestigen (middels de zogenaamde integration wizard ) [34]. ARGOi tracht hier de gebruiker te sturen en te behoeden voor fouten. Een voordeel van UMLi is dat het een extensie is van UML die conformeert met de UML standaard; elk model dat conformeert met het UML meta model conformeert ook met het UMLi meta model [39]. UML modellen die opgemaakt werden in een andere UML omgeving zijn dus automatisch compatibel met UMLi-gebaseerde tools (doch andersom niet).
4.4
UsiXML
UsiXML heeft een vrij uitgebreide tool ondersteuning; de website3 van de taal heeft een lijst van meer dan 30 verschillende tools die compatibel zijn met UsiXML. Het is wel belangrijk om op te merken dat de meeste tools gebruik maken van de volledige UsiXML UIDL, en dus niet enkel de abstracte beschrijving. De uitvoerigheid van de UsiXML tool support t.o.v. die van de andere AUI descriptions moet dan ook gezien worden in deze context. 3
http://www.usixml.org
56
4.4.1
HOOFDSTUK 4. TOOL SUPPORT
GrafiXML
GrafiXML [22] is een UsiXML editor waarmee ontwikkelaars en designers simultaan meerdere user interfaces kunnen opmaken voor meerdere gebruikscontexten. De GrafiXML tool heeft enkel een grafische editor voor het CUI model, het AUI model heeft slechts een tekstuele XML-editor. GrafiXML biedt drie representaties van de user interface; een internal representation die de specificatie in de UsiXML taal weergeeft, een external representation die een preview van de user interface weergeeft en een conceptual representation die de CUI grafisch weergeeft. De representaties blijven gesynchroniseerd: wanneer de ontwikkelaar in de CUI editor concrete interaction objects (CIO) plaatst en hun eigenschappen bewerkt wordt dit gereflecteerd in de UsiXML specificatie, en andersom. Ook consistentie met het AUI model wordt op deze manier behouden. Afbeelding 4.4 toont een voorbeeld van de grafische CUI editor en de equivalente tekstuele UsiXML editor. GrafiXML is uitbreidbaar met plugins en kan een final UI genereren in verschillende formaten zoals Java, HTML, XHTML en XUL.
Figuur 4.4: De GrafiXML editor voor de UsiXML CUI: (a) grafisch (b) equivalente UsiXML [21].
4.4.2
IdealXML
IdealXML [24] is de enige UsiXML tool die een grafische editor heeft voor het abstracte user interface model (figuur 4.5). Verder heeft de tool ook editors voor het taak en domein model en kunnen er mapping models tussen de modellen gecre¨eerd worden. De tool is een environment waarin patterns (oplossingen voor vaak voorkomende problemen in software engineering) opgeslagen en bewerkt kunnen worden.
4.4. USIXML
57
Figuur 4.5: De IdealXML editor voor het UsiXML abstracte user interface model [24].
4.4.3
AGG en TransformiXML
UsiXML voorziet een transformation model waarmee transformatieregels, en meer bepaald abstractions, reifications en translations (zoals gedefinieerd in het Cameleon framework, sectie 2.4), uitgedrukt kunnen worden. Het transformation model wordt uitgedrukt in XML en legt een mapping tussen componenten uit een source model en componenten uit een target model. Attributed Graph Grammar (AGG)4 is een software omgeving voor het defini¨eren en uitvoeren van graaftransformaties. De tool kan gebruikt worden [21] om UsiXML model transformaties door te voeren aan de hand van een grafische notatie. Een alternatieve model-transformation tool is TransformiXML [47]. De tool ondersteunt het editen van de tekstuele XML transformation bestanden.
4.4.4
Andere
UsiXML heeft ook diverse andere vormen van tool ondersteuning. ReversiXML [21, 2] is een tool die bestaande HTML pagina’s automatisch kan omzetten in een AUI of CUI model. De gebruiker kan een aantal opties selecteren die o.a. aangeven welke objecten en attributen van het HTML document geanalyseerd moeten worden [2]. FlashiXML, QtkiXML en UsiXML2OpenLaszlo zijn rendering tools die code kunnen genereren voor de Flash5 , Tcl-Tk6 en OpenLaszlo7 programmeertalen respectievelijk. RenderXML [44] is een rendering tool die een finale UI kan genereren voor meerdere platformen en applicatielogica kan verbinden aan de 4
http://user.cs.tu-berlin.de/ gragra/agg/ http://help.adobe.com/en US/FlashPlatform/reference/actionscript/3/index.html 6 http://www.tcl.tk/ 7 http://www.openlaszlo.org/
5
58
HOOFDSTUK 4. TOOL SUPPORT
gerenderde UI. Al deze tools werken echter uitsluitend met de concrete user interface van UsiXML en worden daarom niet verder toegelicht.
4.5
DIANE+
DIANE+ is een vrij oude specificatie en haar tool support reflecteert dit, ge¨ımplementeerd zijnde op het Windows 3.1 platform [41]. De DIANE+ tool bevat een editor en een dialogue manager. De editor is een tekstuele tool waarmee de DIANE+ procedures en operations opgemaakt en aangepast kunnen worden. Aanpassingen in de editor (wijzigingen in de precedences, constraints, etc.) hebben onmiddellijk effect op de UI at runtime. De DIANE+ dialogue manager leidt het gedrag van de applicatie zoals gedefinieerd in de editor. Het automatisch genereren van de UI is niet mogelijk in de DIANE+ tool, ondanks het feit dat dit een ambitie was voor de specificatie [41]. De tool is over het algemeen vrij beperkt en verouderd. Het ontbreken van een grafische editing omgeving voor een schematische specificatie als DIANE+ is een duidelijke beperking.
4.6
MARIA
De MARIA authoring tool8 [33] is een editing en model transformation tool voor de MARIA specificatie. Het editing aspect van de tool omvat het ontwerpen van de UI modellen en het defini¨eren van regels voor de modeltransformaties. De editor biedt twee gesynchroniseerde views op de AUI specificatie: een grafische tree view en een XML editor. De gebruiker kan elementen toevoegen en bewerken in de tree view om de XML specificatie aan te passen, ook andersom worden wijzigingen in de XML specificatie weergegeven in de tree view. De tool ondersteunt model transformaties in beide richtingen; van abstracte modellen naar concrete modellen naar de implementatie en andersom. De volgorde waarin de opbouw van de user interface dient te gebeuren wordt niet vastgelegd. Een user kan dus een UI beschrijving beginnen op eender welk abstractieniveau en vervolgens m.b.v. modeltransformaties de rest van de modellen automatisch laten invullen. Twee soorten transformaties worden ondersteunt door de tool, general transformations en document instance transformations. General transformations associ¨eren de elementen van een source document met de elementen van een target document [33]. Met document instance transformations kunnen spe8
http://giove.isti.cnr.it/tools/MARIAE/home
4.6. MARIA
59
cifieke transformatieregels toegepast worden op een bepaald element in het document. Om een transformatie mogelijk te maken moet de gebruiker een UI beschrijving opstellen in een bepaald source model en vervolgens een set van regels defini¨eren voor de gewenste modeltransformatie naar het target model. Na het kiezen van een target model wordt de XSD structuur (zie sectie 3.7) van beide modellen ingelezen. Daarna worden de componenten van beide modellen naast mekaar in de tool opgelijst in een boomstructuur [33]. Vervolgens dient de gebruiker de UI elementen uit het ene model te associ¨eren met UI elementen uit het andere model. Om bijvoorbeeld een abstract source model om te zetten naar een concreet target model, wordt een abstracte navigator component verbonden aan een concreet button element. De verbinding wordt tot stand gebracht wanneer de gebruiker een pijl trekt tussen de abstracte component en de gewenste concrete component in de tool. Afbeelding 4.6 toont de tool, de oplijsting van de elementen uit een source- en targetmodel, en een aantal verbindingen.
Figuur 4.6: De MARIA Authoring Environment [33]. Elementen uit een abstract model worden geassocieerd met elementen uit een concreet model d.m.v pijlen.
Nadat alle noodzakelijke associaties gemaakt zijn kan de transformatie plaatsvinden. Bij het uitvoeren van de transformatie worden de abstracte elementen
60
HOOFDSTUK 4. TOOL SUPPORT
vervangen door de geassocieerde concrete elementen en wordt de inhoud van het source element ingevuld in het target element [33].
4.7
CAP3
CAP3 heeft voorlopig enkel een editing tool die gebruikt kan worden om een CAP3 model op te stellen en relaties te leggen tussen componenten. De tool is ge¨ımplementeerd als een Eclipse9 plugin en maakt gebruik van het Eclipse Modeling Framework (EMF)10 en het Ecore meta model om de CAP3 notatie te beschrijven. Net als in de andere grafische editing tools wordt ook in de CAP3 editor een paneel voorzien met een lijst van de verschillende CACs die vervolgens gesleept kunnen worden naar het diagram.
Figuur 4.7: De CAP3 Eclipse plugin [46].
4.8
Evaluatie
De kwaliteit van de tool support voor de verschillende abstracte user interface specificaties kan op enkele manieren ge¨evalueerd worden. De meest voor 9 10
http://www.eclipse.org http://www.eclipse.org/modeling/emf/
4.8. EVALUATIE
61
de hand liggende maatstaf is de aanwezigheid van functionaliteit als editing, model transformaties en code generation (of rendering). Tabel 4.1 geeft een overzicht. Alle AUI descriptions hebben tools die het editen van hun modellen ondersteunen. Alle grafische descriptions (behalve DIANE+) hebben ook een grafische editor voor het AUI model. MARIA is beperkt tot een XML editor en een grafische boomweergave van het XML bestand. CAP, DIANE+ en UMLi hebben geen ingebouwde ondersteuning voor model transformaties. De CAP3 tool is gebouwd op het EMF, een framework dat een sterke ondersteuning heeft voor modeltransformaties [46], waardoor de tool impliciet model transformation ondersteunt (als de gebruiker bereid is zelf de transformatie uit te voeren). Ondersteuning voor model transformation is expliciet terug te vinden bij MARIA en UsiXML. Beiden ondersteunen reification, abstraction en translation tussen modellen van hun eigen specificatie. De MARIA Environment heeft een grafische editor voor het aanmaken van transformatieregels, in UsiXML heeft men de keuze tussen een grafische tool (AGG) of een tekstuele tool (TransformiXML). Echte generating tools blijken alleen voor te komen bij meer volledige UIDLs, ze steunen ook eerder op het CUI model dan het AUI model. De generating tool van CAP (CanonSketch) maakt wel een zeer beperkt HTML prototype aan. DialogSketch ondersteunt wel het navigeren doorheen een CAP prototype, maar er wordt hiervoor geen finale UI gegenereerd of gerendered, het CAP model zelf wordt navigeerbaar. CAP3 heeft dankzij het gebruik van het EMF framework ook hier impliciete ondersteuning voor code generation. Tool support Editing Transformation Generating
CAP X X
UMLi X
CAP3 X X X
MARIA X X X
UsiXML X X X
DIANE+ X
Tabel 4.1: Vormen van tool ondersteuning voor de verschillende AUI descriptions. Het is vervolgens ook zinvol om de tools te beoordelen op basis van een aantal richtlijnen uit de literatuur. Niet alle tools zijn vrij beschikbaar; daarom is deze beoordeling hoofdzakelijk gebaseerd op informatie uit de literatuur, en dus noodzakelijkerwijs vrij bondig. Net als bij de descriptions (sectie 3.9.4) kunnen een aantal cognitive dimensions besproken worden. Bijkomend worden de meest relevante richtlijnen besproken die voorgesteld worden in [32], een verzameling van criteria om de effici¨entie van tools of user interfaces te beoordelen. Een opvallend gebrek in CanonSketch is de afwezigheid van dual coding in het paneel met de CACs. Gezien het grote aantal CAP symbolen is het niet eenvoudig om via het icoon op een betrouwbare manier de juiste component te selecteren (zonder de symbolen van alle 21 componenten uit het hoofd te
62
HOOFDSTUK 4. TOOL SUPPORT
leren), dit verhoogt de error-proneness van de tool. Bij andere tools waarbij dit ontbreekt (GrafiXML en UMLi bijvoorbeeld) zijn er een beperkter aantal componenten en is de impact hiervan minder ernstig. De progressive evaluation richtlijn bepaalt in welke mate de tool feedback verschaft tijdens het gebruik (bijvoorbeeld bij onvolledige specificaties). ARGOi waarschuwt de gebruiker wanneer hij klassen wil deleten die ook geassocieerd zijn met andere modellen (dit is ook een verlagen van de error-proneness). Ook tools die verschillende abstractieniveaus automatisch synchroniseren (CanonSketch en GrafiXML) voldoen hieraan. De viscosity bepaalt hoe moeilijk het is om verschillende mogelijke oplossingen te proberen in de tool. Het ontbreken van een visuele editor in DIANE+ bemoeilijkt deze factor, vooral omdat DIANE+ een schematische specificatie is. Sommige tools ondernemen stappen om de viscosity te verlagen (reduce solution viscosity). Het gebruik van wizards om vaak voorkomende constructies (selection states) vlug te genereren in de ARGOi tool speelt een actieve rol in het vereenvoudigen van het ontwerpen van de UMLi diagrammen. Tools met gesynchroniseerde views tussen verschillende abstractieniveaus (zoals CanonSketch en GrafiXML) verminderen het aantal acties die de gebruiker moet uitvoeren om het resultaat van een wijziging te beoordelen (een voorbeeld van flexibility). Het probleem dat de tool oplost moet belang hebben voor een grote groep gebruikers en een tool die het probleem oplost moet ook een duidelijk verschil maken (importance). De editing tools van de verschillende descriptions voldoen hieraan in de mate dat een AUI specificatie best een editing tool heeft. Het probleem kan ook best nog niet eerder opgelost zijn (problem not previously solved ). CanonSketch en DialogSketch zijn beide editors voor CAP, maar er is ook andere functionaliteit aan deze tools verbonden. De meerdere transformatietools voor UsiXML lossen ook hetzelfde probleem op, maar op een andere manier (grafische vs. tekstuele transformatieregels). Sommige tools lossen ook een volledig nieuw probleem op (addressing a new problem). De CanonSketch tool integreert bijvoorbeeld een taakspecificatie in CAP. De editing tools van UMLi, CAP3, MARIA en DIANE+ zijn de enige editing tools voor hun specificatie en lossen dus noodzakelijkerwijze een nieuw probleem voor die specificatie (namelijk de afwezigheid van een editing tool), maar niet noodzakelijk een nieuw probleem in de algemene zin. Het veelvoud aan rendering tools voor UsiXML is ook een voorbeeld van tools die nieuwe problemen oplossen voor een specifieke doel-taal, maar niet een strikt nieuw probleem oplossen (rendering van een final UI). Gebruikers met een minder technische achtergrond hebben baat bij een tool die aangepast is aan hun noden en rekening houdt met hun voorkeuren of beperkingen (empowering new design participants). Complexere tools vernauwen het mogelijke doelpubliek van een tool. Editing tools zijn de meest eenvoudige
4.8. EVALUATIE
63
tools en de grafische AUI descriptions hebben allen een tool die het editing aspect op een gebruiksvriendelijke manier oplost (i.e. grafisch en point & click). Tools voor notaties zonder grafische component, zoals de MARIA Environment en de DIANE+ tool, hebben hoe dan ook een hogere drempel voor niet-technische gebruikers. MARIA voorziet echter wel een optionele editeerbare boomweergave van het XML bestand.
64
HOOFDSTUK 4. TOOL SUPPORT
Hoofdstuk 5 Conclusie literatuurstudie Model-based user interface design (MB-UID) werd besproken en er werd een overzicht gegeven van een aantal relevante model-based user interface design frameworks. Verder werd de plaats van abstracte user interfaces (AUI) binnen MB-UID geschetst en werd er een vergelijkende studie gemaakt tussen een aantal belangrijke abstracte user interface specificaties en de kwaliteit en range van hun tool support. In de context van model-based user interface design werd het Cameleon reference framework, multi-path UI development, usage-centered design en het MuiCSer framework besproken. De frameworks steunen op of verwijzen naar een gemeenschappelijke modelstructuur gedefinieerd door vier abstractieniveaus, corresponderend met het taak- en domeinmodel, de abstracte user interface, de concrete user interface en de final user interface (in orde van dalende abstractie). Vervolgens kwam de focus te liggen op het AUI model, een belangrijk overgangsmodel tussen de taakspecificatie en de concrete prototypes. De CAP, UMLi, DIANE+, MARIA, UsiXML en CAP3 abstracte UI descriptions en hun tool support werden in detail besproken en vergeleken. Een AUI description moet makkelijk bruikbaar, leesbaar en overzichtelijk zijn voor software ontwikkelaars en eventueel ook voor designers (indien dit een doelstelling is van de AUI description). De description moet bovendien ondersteund worden door een krachtige en gebruiksvriendelijke tool ondersteuning wil ze werkelijk toepasbaar zijn. Om deze factoren te evalueren werden zowel de descriptions als hun tool support vergeleken met een aantal criteria en richtlijnen uit de literatuur. CAP is beperkt tot een diagramnotatie voor de AUI en heeft geen constructies voor behaviour modeling. CAP bleek wel een van de meest expressieve notaties te zijn voor het AUI model; de notatie heeft veel specifieke componenten voor vaak voorkomende UI taken en ook ruimtelijke informatie wordt in 65
66
HOOFDSTUK 5. CONCLUSIE LITERATUURSTUDIE
de diagramrepresentatie opgenomen. CAP heeft twee grafische editing tools, CanonSketch en DialogSketch; DialogSketch integreert bovendien een taakspecificatie in de CAP notatie en kan de UI simuleren. UMLi introduceert nieuwe constructies in UML voor het AUI model; een nieuwe, doch weinig expressieve, diagramnotatie en een extensie van UML activities voor behaviour modeling. UMLi heeft een dedicated editing tool die relaties tussen het presentation model en het activity model onderhoudt en waarschuwt bij het deleten van elementen die gerelateerd zijn aan andere modellen. DIANE+ is een taakspecificatie die de UI interactie modelleert op verschillende abstractieniveaus. DIANE+ is een schematische specificatie, maar heeft geen grafische editing tool voor deze specificatie, een belangrijke beperking. De bestaande tool is bovendien vrij beperkt in haar functionaliteit en niet langer bruikbaar op moderne operating systemen. MARIA is een XML-gebaseerde UIDL die een abstract en concrete description van de UI ondersteunt. De taal heeft geen grafische representatie voor het AUI model, een tekortkoming. MARIA heeft ´e´en tool, de MARIA Environment, die een editor integreert met een model transformation tool. UsiXML is een uitgebreide XML-gebaseerde UIDL die de vier Cameleon abstractieniveaus kan modelleren. Het is om deze reden waarschijnlijk de meest omvattende taal die besproken werd. Ook de tool ondersteuning voor UsiXML is ruim en breed. Het ontbreken van een standaard notatie voor het AUI model is een echter een significante beperking, en de notatie die gebruikt wordt in de IdealXML tool is weinig expressief (relaties worden niet gemodelleerd). CAP3 is een van de meest recente en moderne descriptions; behaviour en presentatie worden ge¨ıntegreerd in ´e´en grafisch model dat verder bouwt op de CAP notatie (en dus ook de voordelen van CAP overerft). De CAP3 tool ondersteuning is momenteel beperkt tot het editen van modellen, maar is ge¨ımplementeerd op een model-driven engineering platform met veel mogelijkheden die onbenut blijven.
Deel II Toepassing
67
Hoofdstuk 6 Concept 6.1
Keuze en motivatie
Om AUIs bruikbaarder en breder toepasbaar te maken voor minder technische gebruikers moet eerst een AUI description gekozen worden die in dit kader geschikt is. CAP3 werd gekozen omdat het de reeds expressieve CAP notatie (met 21 verschillende AIOs) uitbreidt met nieuwe presentatie constructies (attributes voor de AIOs en ConceptualGroups), en behaviour constructies integreert in ´e´en enkele uitvoerige en overzichtelijke diagramnotatie. In een CAP3 diagram kan bovendien ook ruimtelijke informatie over de componenten gemodelleerd worden, wat de notatie nog expressiever maakt. De huidige CAP3 tool ondersteuning laat bovendien enkel het editen van CAP3 modellen toe; er is ruimte voor uitbreiding. De keuze voor CAP3 werd ook deels gemaakt uit praktische overwegingen. De CAP3 tool is ge¨ımplementeerd op het EMF platform, een Model Driven Engineering platform dat via het Epsilon framework reeds ondersteuning biedt voor code generation (EGL, zie sectie 7.5.3) en model validation (EVL, zie sectie 7.5.2) en andere model beheer taken als model-to-model transformation, comparison, migration, merging en refactoring (zie hoofdstuk 7 voor meer informatie over EMF en Epsilon). Bovendien heeft EMF een goede integratie in Eclipse waardoor tools ge¨ımplementeerd kunnen worden als Eclipse plugins, en gebruik kunnen maken van de Eclipse API. Een eerste doelstelling voor de toepassing is het opleggen en afchecken van semantische constraints op CAP3 modellen. Sommige (eenvoudige) syntactische constraints worden reeds opgelegd door het CAP3 Ecore model, zo is het bijvoorbeeld onmogelijk om in de tool een option tag toe te voegen aan een ConceptualGroup (herinner: dit is namelijk een denkbeeldige groepering van componenten, geen component op zich). Het is echter belangrijk dat een model naast syntactisch ook semantisch correct (betekenisvol) is. Het meta model van CAP3 laat echter nog teveel vrijheden toe die ervoor zorgen dat een gebruiker 69
70
HOOFDSTUK 6. CONCEPT
makkelijk constructies kan maken die semantisch incorrect zijn. Traditioneel staat de designer zelf in voor de controle van deze correctheid. Dit vereist uiteraard dat de designer voldoende kennis heeft van het meta model om te weten welke constructies semantisch steek houden. Deze vereiste verhoogt de drempel tot het gebruik van CAP3, vooral voor onervaren gebruikers. Het afchecken van semantische constraints kan een belangrijk hulpmiddel zijn om deze drempel te verlagen voor nieuwe gebruikers of gebruikers met een minder technische achtergrond (e.g. UI designers). Een voorbeeld van een specifieke situatie waar dit van belang is is een samenwerking tussen interaction designers en software engineers, waarbij een AUI kan dienen als gedeeld design artefact. Ook voor gebruikers die wel een technische achtergrond hebben (e.g. programmeurs, software engineers) hebben deze constraints voordelen; bijvoorbeeld bij het defini¨eren van complexe diagrammen waar het moeilijk is om het overzicht te bewaren. Constraints worden in de toepassing gedefinieerd aan de hand van de EVL constraint language (zie sectie 7.5.2), een programmeertaal waarmee constraints afgecheckt kunnen worden op EMF modellen zoals het CAP3 meta model. Naast het afchecken van constraints op het meta model kan het soms ook zinvol zijn om constraints te defini¨eren en afchecken op een bepaald soort model (en niet op alle mogelijke modellen), bijvoorbeeld in het kader van een bepaald project, of voor een bepaalde toepassing. Complexere constraints kunnen dienen als een template waaraan een bepaald design moet voldoen. Dit kan meerdere toepassingen hebben, constraints kunnen zo dienen als een raamwerk voor het gebruik van bepaalde componenten of om een kader op te leggen voor een UI design binnen een bepaalde context (zie sectie 8.3 voor meer detail). Een probleem hier is echter dat het schrijven van constraints in EVL een taak is die weggelegd is voor gebruikers die kennis hebben van de EVL programmeertaal (en programmeren in het algemeen), terwijl het vooral designers zijn (i.e. niet-technische gebruikers) die baat hebben bij het opleggen van deze design constraints. Als oplossing hiervoor wordt de mogelijkheid om constraints te genereren uit een CAP3 diagram voorgesteld. Niet-technische gebruikers kunnen hiermee op een grafische/visuele manier constraints specifi¨eren.
6.2 6.2.1
Tool concept Constraint checking
In de eerste plaats moet de tool de correctheid van een CAP3 model bepalen door constraints af te checken op de componenten en connecties van het model. In het resultaat van deze model-checking operatie moet er een onderscheid gemaakt worden tussen warnings en errors om de ernst van de schending van de constraint aan te geven. Een gefaalde constraint kan soms met een geautomatiseerde fix verbeterd worden door de tool. Deze vorm van tool ondersteuning
6.2. TOOL CONCEPT
71
kan in belangrijke mate de error-proneness dimension (zie sectie 4.8 voor de cognitive dimensions van tool support) van een editing tool verlagen door feedback te geven wanneer de gebruiker een identificeerbare fout maakt. Bovendien kan het een voorbeeld zijn van progressive evaluation (indien model-checking ge¨ıntegreerd wordt in de editing tool). Het kan ook de drempel voor niettechnische gebruikers verlagen (empowering new design participants) en het is een voor CAP3 onopgelost probleem (problem not previously solved ). Voor de verschillende componenten van een model zullen volgende constraints afgecheckt worden:
Abstract Components: Er zal voor de verschillende Tools, Materials en Active Materials (zie tabel 3.1) bepaald worden of de attributen consistent zijn met de functie van de component (e.g. het editing attribuut van een EditableElement moet de waarde true hebben).
Relationships: Enkel relaties die logisch mogelijk zijn zijn toegelaten in het model. Onder relaties worden naast Update, Use en Activate relaties ook containment relaties verstaan.
Een aantal voorbeelden van beperkingen op relaties zijn:
Een Update of Use relatie moet steeds een source en target component hebben.
Een Element kan geen RepeatedConceptualGroup bevatten.
Indien er een Update relatie vertrekt uit een ConceptualGroup, dienen alle Tools een operation te specifici¨eren.
Een Select tool kan geen navigatie veroorzaken; de doelcomponent van een Activate relatie die vertrekt van de Select tool moet dus deel uit maken van dezelfde top-level component.
Er kan geen Update relatie vertrekken van een Tool die geen data kan manipuleren (zoals View ) naar een Container component.
Voor de uitwerking zal gebruik gemaakt worden van de Eclipse software development omgeving en het Epsilon framework. Het Epsilon framework kan gebruikt worden om te interageren met de EMF modellen van het CAP3 model en zo de nodige constraint checking taken uit te voeren.
6.2.2
Genereren van constraints
De tweede doelstelling van de tool is het genereren van constraints uit CAP3 diagrammen. Wanneer dergelijke constraints gegenereerd worden uit een model is het de bedoeling dat ook deze constraints semantische beperkingen leggen op modellen. Het verschil met de constraints uit de vorige sectie is dat er een grafische/visuele manier ge¨ıntroduceerd wordt om constraints te defini¨eren.
72
HOOFDSTUK 6. CONCEPT
Het genereren van deze constraints kan verschillende concrete toepassingen hebben, zoals het defini¨eren van een raamwerk voor een bepaalde component, het afdwingen van het correct gebruik van een design pattern, of binnen multiplatform UI development als een template voor een UI design dat op verschillende platformen ingezet dient te worden (zie sectie 8.3 voor meer detail). Concreet ontwerpt een gebruiker eerst een AUI diagram en kan hij hieruit vervolgens een of meerdere constraints genereren met de generating tool. Deze gegenereerde constraints zullen checks bevatten op de componenten en relaties die aanwezig waren in het AUI diagram waaruit de constraint gegenereerd werd. Afhankelijk van opties die aan de generator meegegeven worden kan de interpretatie van dit diagram wijzigen. In verschillende toepassingen kan vereist zijn dat een constraint meer of minder strict ge¨ınterpreteerd wordt. Het moet ook mogelijk zijn om bij het ontwerpen van het diagram aan te geven welke componenten eventueel optioneel zijn in een gegenereerde constraint. Ook voor de implementatie van deze tool functionaliteit zal gebruik gemaakt worden van het Epsilon framework, meer bepaald de EGL programmeertaal voor model-to-text transformation (zie sectie 7.5.3).
Hoofdstuk 7 Platform 7.1
Inleiding
In dit hoofdstuk wordt de software besproken die gebruikt werd om de tool functionaliteit te realiseren. De bedoeling is een kort inzicht te geven in de werking van de frameworks en de keuze ervoor te verantwoorden door features te belichten die de implementatie zullen ondersteunen. De EMF en GMF frameworks en het Epsilon platform worden besproken. EMF is het modeling framework waarin het meta-model van CAP3 gedefinieerd wordt, het biedt bovendien ondersteuning voor het genereren van editors voor meta-modellen. GMF is een framework dat het genereren van editors voor EMF modellen vereenvoudigd. Epsilon is een verzameling van programmeertalen die interactie met EMF modellen mogelijk maken en ondersteuning bieden voor specifieke model-management taken als validation, code generation, etc. Deze frameworks hebben tools die ge¨ıntegreerd zijn in het Eclipse platform, dat ook kort toegelicht wordt.
7.2
Eclipse
Eclipse1 is een open-source platform dat uitbreidbare frameworks en tools voorziet voor software development. Eclipse is ge¨ımplementeerd in Java – doch er wordt ook een C++ IDE voorzien – en de meeste Eclipse functionaliteit wordt aangeboden voor de Java variant. Het Eclipse Project omvat verschillende top-level projecten zoals het Modeling Project, Tools Project en Technology Project. Het Eclipse Modeling Project spitst zich toe op de ontwikkeling van model-based technologie voor Eclipse. De kern van het Modeling Project is het EMF framework. 1
http://www.eclipse.org/
73
74
HOOFDSTUK 7. PLATFORM
7.3
EMF
EMF (Eclipse Modeling Framework)2 [40] is een framework dat gebruikt kan worden om tools en andere applicaties te bouwen rond een bepaald data model. De centrale feature van EMF is het Ecore meta model, dat gebruikt wordt om modellen te defini¨eren. Het Ecore model laat toe verschillende elementen te specifi¨eren (zie figuur 7.1) [40]:
EClass: Representeert een klasse met een naam en nul of meer EAttributes en EReferences.
EAttribute: Geeft een attribuut weer met een naam en een type.
EReference: Representeert een referentie naar een andere EClass met een parameter die aangeeft of het om een containment relatie gaat.
EDataType: Geeft het type van een attribuut weer.
Figuur 7.1: Het Ecore meta model [40]. Instanties van deze klassen kunnen gebruikt worden om een Ecore model te specifi¨eren. Het Ecore model heeft een boomstructuur met een root object dat het hele model representeert. Dit model heeft children die packages representeren en deze packages representeren classes. Ecore modellen kunnen opgebouwd worden met een XML file, de EMF tree-based editor of een UML diagram [40]. De Emfatic 3 editor plugin maakt het mogelijk om Ecore modellen uit te drukken in een tekstuele (human-readable) syntax, gelijkaardig aan Java (zie sectie 7.5.1 voor een codevoorbeeld). Uit een Emfatic bestand kan een Ecore model bestand gegenereerd worden en vice versa. Een concreet voorbeeld van een Ecore model kan gevonden worden in sectie 8.1, waar het CAP3 Ecore model besproken wordt. De bijhorende afbeelding 8.1 illustreert a.d.h.v. een klassediagram hoe het Ecore model opgebouwd is.
2 3
http://www.eclipse.org/emf/ http://eclipse.org/gmt/epsilon/doc/articles/emfatic/
7.4. GMF
7.4
75
GMF
GMF (Graphical Modeling Framework)4 is een verzameling van plug-ins waarmee grafische editors gegenereerd kunnen worden voor een EMF meta model (in de vorm van een Eclipse plugin). GMF biedt herbruikbare componenten voor grafische editors zoals een tool palette, properties view, geometrische figuren, etc. en ook een standaard model om grafische elementen van diagrammen te beschrijven. GMF maakt gebruik van een aantal modellen die elk verschillende aspecten van de editor beschrijven. Het Tooling model (.gmftool ) definieert de tekst die weergegeven wordt in het tool palette, de property sheet en het context menu van de editor. Het Graph model (.gmfgraph) beschrijft de grafische aspecten van de editor en definieert figuren die gebruikt zullen worden in de diagram editor om nodes (klassen) en links (relaties) te illustreren. Het Mapping model (.gmfmap) integreert het Graph model met het Tooling model en het Ecore meta model. Het Mapping model bepaalt welke actie ondernomen wordt wanneer een tool geselecteerd wordt, welke klassen aangemaakt moeten worden en welke figuren gebruikt moeten worden om klassen te representeren die aan het diagram worden toegevoegd.
Figuur 7.2: Genereren van Java code voor de GMF runtime uit een EMF Ecore meta model. Uit het Mapping model wordt een Generator model (.gmfgen) gegenereerd waaruit uiteindelijk programmacode gegenereerd kan worden voor de grafische editor (zie figuur 7.2 voor een overzicht van het hele proces). Deze programmacode kan tenslotte binnen de GMF runtime component uitgevoerd worden.
4
http://www.eclipse.org/gmf/
76
HOOFDSTUK 7. PLATFORM
7.5
Epsilon
Epsilon (Extensible Platform of Integrated Languages for mOdel maNagement)5 is een model-management platform dat gebruikt kan worden om te interageren met EMF, MOF 1.4, pure XML of CZT [35] modellen. Epsilon omvat een aantal ge¨ıntegreerde programmeertalen voor model management (i.e. het automatiseren van bepaalde MDE-taken als validering, model transformatie, vergelijking, etc.), steunend op een gemeenschappelijke architectuur (zie figuur 7.3). De Epsilon Model Connectivity Layer (EMC) biedt een interface die gebruikt kan worden om op een uniforme wijze een model te navigeren en te wijzigen (i.e. toevoegen, updaten en verwijderen van elementen) binnen het hele Epsilon platform [15]. Epsilon Object Language (EOL) is binnen Epsilon de algemene programmeertaal waarmee interactie met modellen bewerkstelligd kan worden (zie sectie 7.5.1 voor meer detail). Verder worden er een aantal andere programmeertalen voorzien voor specifieke MDE-taken. Deze talen bouwen verder op de EOL basistaal en breiden EOL zowel syntactisch als semantisch uit met nieuwe functionaliteit [15]:
Epsilon Validation Language (EVL): Maakt het mogelijk om complexe tekstuele constraints te defini¨eren waartegen modellen gevalideerd kunnen worden om hun correctheid te bepalen (zie sectie 7.5.2).
Epsilon Generation Language (EGL): Kan gebruikt worden om model-totext transformatieregels te defini¨eren in een template dat – wanneer uitgevoerd – ´e´en of meerdere tekst documenten kan genereren uit een bepaald model (zie sectie 7.5.3).
Epsilon Transformation Language (ETL): Kan gebruikt worden om modelto-model transformatieregels te specifi¨eren en uit te voeren. Deze transformatieregels beschrijven hoe modellen van een bepaald meta model uitgedrukt kunnen worden in modellen van een tweede (niet noodzakelijk ander) meta model van eenzelfde of een andere modelleertaal [16].
Epsilon Wizard Language (EWL): Maakt het mogelijk om modellen te updaten door informatie in het model te wijzigen, te verwijderen of toe te voegen op een effici¨ente manier.
Epsilon Comparison Language (ECL): Kan gebruikt worden om regels te defini¨eren die overeenkomstige/gelijkaardige elementen bepalen tussen twee modellen op een geautomatiseerde manier.
Epsilon Merging Language (EML): Kan gebruikt worden om verschillende 5
http://eclipse.org/gmt/epsilon/
7.5. EPSILON
77
modellen (van mogelijk andere metamodellen) samen te voegen tot ´e´en model.
Figuur 7.3: De Epsilon architectuur [35]. De sterke integratie tussen deze talen (via de gemeenschappelijke EOL taal) is een groot voordeel van Epsilon. Verschillende model management taken hebben vaak bepaalde gemeenschappelijke requirements, zoals de nood aan constructies die het navigeren van modellen mogelijk maken [35]. Door deze kern logica te verzamelen in ´e´en basistaal zorgt men ervoor dat de gebruiker slechts ´e´en nieuwe syntax moet leren die vervolgens gebruikt kan worden binnen het hele platform. Dit staat in contrast met andere model management tools die vaak stand-alone zijn en waarbij dus voor verschillende model management taken andere programmeertalen gebruikt worden [35]. Epsilon tool support wordt voorzien in de vorm van Eclipse plugins als editors, perspectives, wizards, en launch configuraties. De editors die voorzien worden voor de verschillende talen bieden syntax highlighting, een hi¨erarchisch overzicht van files en een makkelijke manier om de scripts uit te voeren (met een ingebouwde Apache Ant definities). Voor de toepassing worden EOL, EVL en EGL gebruikt, daarom worden enkel deze talen in meer detail beschreven in de volgende secties.
7.5.1
Epsilon Object Language
De Epsilon Object Language (EOL)6 [15, 16] is een programmeertaal voor model interactie met verschillende soorten modellen, waaronder ook EMF modellen (EOL is dus meta model onafhankelijk). De taal maakt het mogelijk 6
http://eclipse.org/gmt/epsilon/doc/eol/
78
HOOFDSTUK 7. PLATFORM
om modellen effici¨ent te navigeren en te wijzigen. Alle taak-specifieke talen van het Epsilon platform gebruiken EOL als basis, en hoeven dus enkel bijkomende features te implementeren die nog niet reeds bestaan binnen EOL. Toekomstige uitbreidingen op EOL vormen dus ook automatisch uitbreidingen op de andere programmeertalen van het platform. EOL combineert traditionele programmeerconstructies (e.g. variabelen, for en while loops, if statements, etc.) met elementen van OCL [31] als collection querying functies. EOL is dynamically typed en ondersteunt operations (functies). De taal is zelf niet object-geori¨enteerd maar kan wel interageren met objecten van modellen. Het is ook mogelijk om meerdere modellen tegelijk aan te spreken binnen eenzelfde blok EOL code. Appendix A.1 bevat een gedetailleerd overzicht van de relevante syntax en features van EOL.
7.5.2
Epsilon Validation Language
De Epsilon Validation Language7 [15] is een programmeertaal voor model validatie die verder bouwt op EOL. Met EVL kunnen constraints gedefinieerd worden op een model die zullen falen of slagen afhankelijk van de informatie in het model dat tegen de constraint wordt gecheckt. Eenvoudige voorbeelden van constraints zijn de vereiste dat een bepaald attribuut gedefinieerd is of dat een bepaald String attribuut begint met een hoofdletter. Deze soort eenvoudige constraints kunnen meestal uigedrukt worden in een EOL expressie van ´e´en regel. Meer complexe constraints kunnen uitgedrukt worden door gebruik te maken van code blokken met sequenti¨ele EOL code. Het is zowel mogelijk om intra-model (binnen ´e´enzelfde model) als inter-model (tussen twee of meerdere modellen) model checking te doen. EVL maakt ook dependencies tussen constraints mogelijk, waarmee binnen een bepaalde constraint een andere constraint aangeroepen kan worden en het resultaat van deze aanroep verkregen kan worden. Dit resultaat is een boolean waarde die aangeeft of het model succesvol gecheckt is tegen de constraint. Er wordt een onderscheid gemaakt tussen de ernst van de schending van een constraint door twee soorten constraints te voorzien: constraint types, die een “harde” constraint defini¨eren die nooit mag falen, en critique types, die eerder een “suggestie” defini¨eren. Er kunnen aanpasbare error messages opgesteld worden die aan de gebruiker getoond worden wanneer een constraint faalt. Het is ook mogelijk om geautomatiseerde fixes te defini¨eren die door het modifi¨eren van modellen het probleem kunnen trachten op te lossen. Er bestaat ook een ingebouwde ondersteuning voor EVL constraint checking in het GMF framework, zodat model validatie eenvoudig kan toegevoegd worden 7
http://eclipse.org/gmt/epsilon/doc/evl/
7.5. EPSILON
79
aan GMF editors, een belangrijke feature voor ons. Appendix A.2 bevat een gedetailleerd overzicht van de relevante syntax en features van EVL.
7.5.3
Epsilon Generation Language
De Epsilon Generation Language (EGL)8 [15, 35] maakt model-to-text transformation (M2T) mogelijk binnen het Epsilon platform. Met EGL kunnen tekst bestanden (zoals documentatie, code, e.d.) gegenereerd worden gebruikmakend van informatie uit EMF modellen. EGL is een template-gebaseerde taal (e.g. PHP) waarbij statische secties tekst verweven worden met dynamische EOL code om ´e´en geheel te vormen. EGL is ge¨ımplementeerd als een preprocessor; de statische secties van een template worden omgezet in EOL print statements, terwijl de EOL code van de dynamische secties gewoon wordt behouden. Het geheel wordt vervolgens uitgevoerd als EOL code [35]. In een EGL template kunnen protected regions gedefinieerd worden die behouden worden wanneer een EGL template op een later moment opnieuw tekst schrijft naar dezelfde locatie [35]. EGL biedt ook een aantal tekst postprocessors die gebruikt kunnen worden om gegenereerde code te formatteren (“beautification”) voor Java en XML. Appendix A.3 bevat een gedetailleerd overzicht van de relevante syntax en features van EGL.
7.5.4
EuGENia
EuGENia9 [17] is een Epsilon tool waarmee men automatisch GMF modellen (graphing model, tooling model en mapping model) kan genereren uit een geannoteerd Ecore meta model. Hieruit kan men m.b.v. GMF vervolgens automatisch Java code genereren voor een editor voor het meta model. Deze editor kan vervolgens door de gebruiker aangepast worden met een EOL script dat na het genereren uitgevoerd wordt op de gegenereerde GMF modellen, of door de gegenereerde Java code van de editor zelf te wijzigen. EuGENia wordt gebruikt om de basis editor van CAP3 te genereren uit het CAP3 Ecore model.
8 9
http://eclipse.org/gmt/epsilon/doc/egl/ http://eclipse.org/gmt/epsilon/doc/eugenia/
80
HOOFDSTUK 7. PLATFORM
Hoofdstuk 8 Implementatie 8.1
Meta model
Het CAP3 meta model waarmee gewerkt wordt is een aangepaste versie van het model dat (oppervlakkig) besproken werd in sectie 3.8. De belangrijkste wijzigingen worden hier kort aangehaald, alsook de relevante eigenschappen van het nieuwe meta model. Figuur 8.1 toont het klassediagram van het huidige Ecore model voor CAP3. Het top-level Specification element modelleert ´e´en abstract user interface diagram. Dit element kan verschillende Tool, Container en AbstractMaterial elementen bevatten, alsook AbstractComponent elementen (die nu gebruikt worden om de ConceptualGroups besproken in sectie 3.8 te modelleren). De Activate relatie uit het meta model in sectie 3.8 blijft behouden, maar de Update en Use relaties worden nu gemodelleerd met eenzelfde DataFlow relatie. De DataFlow relatie modelleert de uitwisseling van informatie tussen twee componenten, de richting van deze relatie geeft aan welke component informatie ontvangt. De bidirectional property kan gebruikt worden om informatieuitwisseling in beide richtingen te modelleren. Tools hebben een aantal attributen die eigenschappen van de tool modelleren. Het ending attribuut geeft bijvoorbeeld aan dat een tool een bepaalde operatie stopzet; een gelijkaardige situatie geldt voor starting, suspending en exiting. Het maxSelectionCount attribuut wordt gebruikt bij Select en SelectableCollection componenten om het maximum aantal gelijktijdig selecteerbare items te modelleren. De nieuwe Option tag kan op eender welk element geplaatst worden en wordt gebruikt om componenten aan te geven die optioneel zijn in het design. Repetitie van elementen (zoals in de RepeatedConceptualGroup notatie van sectie 3.8) wordt nu gemodelleerd met een Repetition tag die op eender welk 81
82
HOOFDSTUK 8. IMPLEMENTATIE
Figuur 8.1: Grafische weergave van het CAP3 meta model.
8.2. CONSTRAINT CHECKING
83
element geplaatst kan worden (en dus niet enkel op groeperingen). Voor deze tag kunnen een minimum en een maximum aantal repeats gemodelleerd worden met respectievelijk de minRepeats en maxRepeats properties. Belangrijk is dat in de CAP3 tool enkel Tools, AbstractMaterials en Containers rechtstreeks in een diagram geplaatst kunnen worden. Meer specifieke CAP componenten kunnen echter gespecificeerd worden door het type name attribuut van dergelijke componenten in te vullen. Een Tool kan zo bijvoorbeeld een “Select” type name hebben, waardoor het een Select Tool wordt.
8.2
Constraint checking
Om de vereiste constraint checking te realiseren moet ervoor gezorgd worden dat semantische constraints gedefinieerd kunnen worden en vervolgens afgecheckt kunnen worden op CAP3 diagrammen. Omdat de huidige CAP3 tool support ge¨ımplementeerd is binnen EMF/GMF kan gebruik gemaakt worden van het Epsilon framework, en meer specifiek van EVL (herinner sectie 7.5.2) om dit te doen. De (eind-)doelstelling van dit concept is het afdwingen van een volledig semantisch correct CAP3 model, doch de scope van deze masterproef was enkel het aantonen van een methode om dit mogelijk te maken. In het kader hiervan werden een aantal EVL constraints en critiques ge¨ımplementeerd (zie tabel 8.1). Voor sommige constraints wordt er een geautomatiseerde fix voorzien die – indien de constraint faalt – het model kan wijzigen om de constraint te doen slagen. Dit is echter niet mogelijk voor alle constraints; het is voor sommige constraints niet duidelijk welke fix algemeen wenselijk is. Er wordt dus een afweging gemaakt tussen de voordelen van het automatisch oplossen van de error of warning en de algemene toepasselijkheid van de oplossing. Een interessante constraint om bij wijze van illustratie nader te bekijken is de volgende: Een Select tool mag geen navigatie veroorzaken; de doelcomponent van een Activate relatie die vertrekt van de Select tool moet dus deel uit maken van dezelfde top-level component. Een Select tool mag uitsluitend gebruikt worden om selecties van componenten te modelleren binnen een bepaalde top-level container (conceptueel een concrete Window ). Een Select tool die niet aan deze constraint voldoet schendt bijgevolg de semantische integriteit van de CAP3 notatie. Figuur 8.2 toont een voorbeeld van een situatie die dergelijke constraint zou doen falen. De Select component in deze figuur bevat een Activate relatie naar een SelectableCollection component die tot een andere top-level container behoort.
84
HOOFDSTUK 8. IMPLEMENTATIE
Figuur 8.2: De Activate relatie in dit diagram (zwarte pijl) is verboden volgens de constraint.
Meestal is een goed verwoorde constraint in natuurlijke taal op een vrij intu¨ıtieve manier uit te drukken in een EVL constraint. Soms zijn er echter beperkingen in het meta model die een voor de hand liggende oplossing verhinderen, en waar omheen gewerkt moet worden. Om de constraint in kwestie effici¨ent te implementeren moet geverifieerd worden dat de target component van een Activate relatie die als source component een Select tool heeft tot dezelfde top-level parent-container behoort als de source component. De AbstractComponents in het CAP3 meta model hebben echter geen attribuut dat verwijst naar de parent container van de component. Dit is een ideaal moment om gebruik te maken van EOL extended properties (besproken in Appendix A.1) om dit attribuut zelf te defini¨eren. Dit kan a.d.h.v. volgende operations: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
-- Bepaal de parent property (extended property: ˜) Ðâ voor elke AC in de Specification operation setParentsForSpecification ( ) { -- Bepaal Specification; er is normaal precies 1 Ðâ Specification object in een CAP3 model var aui := Specification . allInstances ( ) [ 0 ] ; -- Bepaal parent van elke AbstractComponent in de Specification for ( c in aui . presentations ) { c . ˜ parent = null ; c . setParents ( ) ; } }
Ð
â
8.2. CONSTRAINT CHECKING
85
15 -- Aanroepen op elke top-level container in de AUI,
Ð
â
bepaalt een parent property voor elke child 16 operation AbstractComponent setParents ( ) 17 { 18 for ( i in self . components ) 19 { 20 i . ˜ parent = self ; 21 i . setParents ( ) ; 22 } 23 }
Om de top-level container van een bepaalde component te bepalen kan nu een operation gebruikt worden die iteratief de parent componenten van een component doorloopt tot de top-level container bereikt wordt: 1 2 3 4 5 6 7 8 9 10 11 12 13
-- Geef de top-level container terug waarin de AC Ðâ vervat zit @cached operation AbstractComponent getTopLevelContainer ( ) : Container { var temp = self ;
Ð
â
while ( temp . ˜ parent <> null ) { temp = temp . ˜ parent ; } return temp ; }
De eigenlijke constraint kan dan tenslotte gedefinieerd worden als volgt (zie Appendix A.2 voor een verklaring van de syntax): 1 2 3 4 5 6 7 8 9 10 11 12
context Tool { constraint SelectToolCanNotNavigate { guard : self . typeName = 'Select' check { -- Bepaal parents van elke component in de Specification setParentsForSpecification ( ) ;
Ð
â
-- Alle activation relaties waarvan de huidige
Ð
â
86
HOOFDSTUK 8. IMPLEMENTATIE tool de source is var rels := Activation . allInstances ( )>select ( ar | ar . source = self ) ;
13 14 15 16 17
â
-- Vergelijk parents for ( rl in rels ) if ( rl . target . getTopLevelContainer ( ) <> self . Ðâ getTopLevelContainer ( ) ) return false ;
18 19 20 21 22 23
24 25 26 27 28 29 30 31 32 33 34 35
Ð
return true ; } message : '\'Select\' tools should not cause Ðâ navigation (\'Activation\' relationships Ðâ originating from \'Select\' tools must arrive atÐâ components belonging to the same top-level Ðâ container)' fix { title : 'Change component type to \'View\'' do { self . typeName := 'View' ; } } } }
De constraint is enkel van toepassing op Tool componenten die de type name “Select” hebben (gedefinieerd in de guard conditie). In de constraint wordt eerst de setParentsForSpecification() functie aangeroepen die de parent component bepaalt voor alle componenten in het model. Vervolgens worden alle Activation relaties uit het model geselecteerd die de huidige Tool component als source hebben. Tenslotte worden de top-level containers van de source en target componenten van de relatie vergeleken. Wanneer deze niet gelijk zijn faalt de constraint. Een geautomatiseerde fix wordt gedefinieerd die de type name van de Tool component verandert in View, een type dat wel navigatie mag veroorzaken.
8.2. CONSTRAINT CHECKING
Constraint AbstractComponent namen moeten bestaan en uniek zijn De editable property van een EditableElement of EditableCollection dient de waarde true te hebben De collection property van een (Selectable)Collection moet true zijn Een Element mag geen RepeatedConceptual Group bevatten Een (Selectable)Collection moet tenminste ´e´en Element bevatten Er kan geen DataFlow relatie vertrekken van een tool die geen data kan manipuleren (zoals View ) naar een Container component Een Select tool kan geen navigatie veroorzaken; de doelcomponent van een Activate relatie die vertrekt van de Select tool moet dus deel uit maken van dezelfde top-level component Tools specifi¨eren best een DataFlow of Activate relatie Alle componenten in een Specification defini¨eren best een TypeName Indien er een DataFlow relatie vertrekt vanuit een ConceptualGroup dienen alle tools een operation te specifi¨eren
87
Type Constraint
Autofix
Constraint
X
Constraint
X
Constraint
X
Constraint
X
Constraint
Constraint
X
Critique Critique Critique
Tabel 8.1: Constraints voor het CAP3 model die ondersteund worden door de tool. De Type kolom geeft aan of het falen van de constraint een warning (critique) of error (constraint) genereert. De aanwezigheid van een Autofix duidt op een ingebouwde fix die de error of warning op een geautomatiseerde manier kan oplossen.
88
8.3
HOOFDSTUK 8. IMPLEMENTATIE
Genereren van constraints
Het is de bedoeling dat soortgelijke EVL constraints die besproken werden in de vorige sectie nu ook op een geautomatiseerde wijze gegenereerd kunnen worden uit CAP3 diagrammen. Het diagram waaruit de constraints gegenereerd worden wordt vanaf nu het constraint diagram genoemd. De componenten, relaties en attributen van het constraint diagram worden constraint componenten, constraint relaties en constraint attributen genoemd. De diagrammen die een gebruiker achteraf aan de gegenereerde constraints wenst te onderwerpen worden implementatie diagrammen genoemd. De gegenereerde constraint is eigenlijk een “controle” op de aanwezigheid van de componenten, relaties en attributen die in het constraint diagram gedefinieerd werden. Het doel van de constraint is dan eigenlijk het afdwingen van het correct gebruik van de constraint componenten, relaties en attributen in implementatie diagrammen. De generator geeft de gebruiker een keuze tussen een flexibility type. Het flexibility type bepaalt hoe nauw een diagram moet aansluiten bij de structuur die in het constraint diagram werd opgelegd om de constraint te doen slagen. Concreet worden er momenteel twee flexibility types gedefinieerd: flexible en strict. In flexible constraints is de exacte locatie van de componenten binnen het implementatie diagram is niet van belang, zolang ze maar aanwezig zijn in het diagram. Alle ConceptualGroups zijn automatisch optioneel en relaties die aankomen in of vertrekken vanuit een ConceptualGroup mogen vervangen worden door relaties naar de componenten binnen de ConceptualGroup. In strict constraints worden de exacte containment relaties van de componenten in het constraint diagram ook verwacht in het implementatie diagram. Ook ConceptualGroups zijn verplicht. In beide gevallen mogen de implementatie diagrammen uiteraard elementen toevoegen die niet in het constraint diagram aanwezig zijn. Bovendien mag de ruimtelijke indeling van de componenten volledig gewijzigd worden (in strict constraints moet wel de hi¨erarchische indeling bewaard blijven). Wanneer een type name niet gedefinieerd wordt in het constraint diagram zorgt dit voor een flexibiliteit op component niveau, waarbij een gewone Tool in het constraint diagram bijvoorbeeld een Select tool mag worden in een implementatie diagram. Bij het genereren van constraints wordt er ook rekening gehouden met optionele elementen in diagrammen. Herinner: het Option element in het CAP3 meta model (zie figuur 8.1) laat toe om optionele componenten te defini¨eren in een model. Wanneer dit element gebruikt wordt in een diagram zal er voor deze component een critique gegenereerd worden. Bij afwezigheid van een op-
8.3. GENEREREN VAN CONSTRAINTS
89
tional element in een diagram wordt er door een strict constraint een warning gegenereerd, een flexible constraint zal geen warning geven. De generator tool is ge¨ımplementeerd als een EGL (zie sectie 7.5.3) template, dat als input een CAP3 diagram neemt. In een strict constraint wordt er voor elke component in het constraint diagram een stukje EVL code geprint in het output document dat checkt op de aanwezigheid van de component. Indien deze component aanwezig is worden indien nodig de children van de component gecheckt. Voor elke relatie in het constraint diagram wordt EVL code geprint die controleert of de source en target componenten van het implementatie diagram overeenkomen met die in het constraint diagram. Indien er een optionele component tegengekomen wordt wordt het printen uitgesteld tot de sectie van het template waar de critique gedefinieerd wordt. Het principe is gelijkaardig voor flexible constraints (met het verschil dat de children van een component niet hoeven gecontroleerd te worden). In flexible constraints moet er echter ook rekening gehouden worden met het feit dat ConceptualGroups optioneel zijn, waarbij de gebruiker bij een implementatie er wel of niet kan voor opteren om de ConceptualGroup te gebruiken. In pseudo-code kan het genereren van de EVL code voor deze constraints voorgesteld worden als volgt: 1 2 3 4 5 6 7 8 9 10
11 12
For alle relationships in de specificatie Als source component een ConceptualGroup is Voeg child elementen toe aan een source lijst Als target component een ConceptualGroup is Voeg child elementen toe aan een target lijst Controleer of er een relatie bestaat tussen alle elementen van beide lijsten OF Controleer of er een relatie bestaat tussen alle elementen van de source lijst en de target Ðâ ConceptualGroup OF Controleer of er een relatie bestaat tussen alle elementen van de target lijst en de source Ðâ ConceptualGroup
Ð
â
Ð
â
Ð
â
Met de laatste drie checks worden alle mogelijke configuraties van componenten en ConceptualGroups afgecheckt. Als alle drie checks falen dan bestaat er geen correcte relatie zoals gedefinieerd in het constraint diagram. De generator functie van de tool gaat ervan uit dat de semantische constraints uit de vorige sectie slagen, m.a.w het is niet gegarandeerd dat uit een model dat niet valide is t.o.v. de semantische constraints een semantisch correcte constraint gegenereerd kan worden.
90
HOOFDSTUK 8. IMPLEMENTATIE
Bij wijze van illustratie werden er drie directe toepassingen uitgewerkt voor het genereren van constraints: het defini¨eren van constraints op componenten, het afdwingen van correct UI design d.m.v. design patterns en als hulpmiddel bij multi-platform UI development.
8.3.1
Component constraints
De eerste en meest eenvoudige toepassing is het genereren van semantische constraints voor het CAP3 meta-model. Een designer kan met een EVL constraint semantische regels opleggen voor componenten zoals beschreven in sectie 8.2. Een probleem is echter dat designers vaak in het algemeen geen kennis hebben van gestructureerde programmeertalen, noch is het wenselijk dat men van een designer verwacht dat hij de syntax van een constraint language als EVL leert. Als oplossing wordt het genereren van constraints uit een grafisch CAP3 diagram naar voor geschoven. Stel dat een designer een constraint wil leggen op het gebruik van de Notification component in een bepaald project. Alle Notifications in het project moeten minimaal bestaan uit een “Information” Element en optioneel een “OK” End tool. Het diagram in figuur 8.3 modelleert een Notification component die een “Information” Element bevat en een optionele (gemarkeerd met een cirkel) “OK” End tool. Indien dit diagram ge¨ınterpreteerd wordt als een constraint kan er intu¨ıtief uit opgemaakt worden dat een Notification steeds een Element moet bevatten met de naam “Message”. Een “OK” Tool is optioneel (een Notification hoeft namelijk niet per se een interatieve window te zijn). Appendix B.1 bevat de EVL code die uit dit diagram gegenereerd werd. Figuur 8.4 toont een voorbeeld van een Notification die valideert t.o.v. deze constraint (zowel een strict als een flexible constraint). Let op dat niets de gebruiker belet om elementen toe te voegen aan de constructie, zolang de integriteit van de componenten bewaard blijft (het juiste type, de juiste naam, en indien de constraint strict is, de juiste locatie). De “OK” Tool werd in het constraint diagram gemarkeerd als optioneel, en omdat de Tool in het diagram van figuur 8.4 afwezig is wordt hiervoor een warning gegenereerd. Deze warning heeft enkel tot doel de gebruiker te waarschuwen dat er elementen gedefinieerd werden in het pattern die niet opgenomen werden in het diagram, het diagram is daarom niet minder valide t.o.v. de constraint. In de praktijk kan deze functionaliteit dienen als communicatie tussen designers, waarbij een lead designer dezelfde design principes kan opleggen aan een team van designers, zonder dat hierover per se een expliciete communicatie hoeft te gebeuren. Een design kan namelijk niet gevalideerd worden zonder dat de constraints slagen. Voor verschillende projecten kunnen eventueel verschillende constraints gegenereerd worden voor dezelfde types, afhankelijk van de conventies die gehanteerd worden in het project.
8.3. GENEREREN VAN CONSTRAINTS
91
Figuur 8.3: Een constraint diagram dat bepaalt dat een Notification type steeds een Element moet bevatten. De aanwezigheid van een End tool wordt aangeraden. Momenteel is het enkel de bedoeling dat deze functionaliteit gebruikt wordt om constraints te genereren voor ´e´en bepaalde component, in een constraint diagram kan er dus momenteel niet meer dan ´e´en top-level component geplaatst worden.
Figuur 8.4: Een Notification in de praktijk, gevalideerd met de constraint die gegenereerd werd uit figuur 8.3. De afwezigheid van een “OK” End tool zorgt voor een warning.
8.3.2
Design patterns
User interface design patterns [42] beschrijven “best practices” en herbruikbare oplossingen voor UI design problemen. Patterns beschrijven een template met een fysieke UI structuur die de nodige UI functionaliteit modelleert. UI patterns kunnen uitgedrukt worden in CAP3 diagrammen [45]. Het idee voor deze toepassing is dat we op basis van een CAP3 pattern diagram een set van constraints genereren die het correct gebruik van het pattern zullen
92
HOOFDSTUK 8. IMPLEMENTATIE
afchecken. Design patterns zijn design oplossingen die hun effici¨entie bewezen hebben in de praktijk. Door deze design patterns te implementeren als CAP3 constraints krijgt men het bijkomende voordeel dat een implementatie van het pattern ook onmiddellijk ge¨evalueerd kan worden om de correctheid (of volledigheid) ervan te bepalen. Om dit te illustreren wordt het “Wizard” pattern besproken uit [42]. Dit patroon bespreekt een UI functionaliteit die de gebruiker stapsgewijs een bepaalde taak laat uitvoeren. Wizards worden gebruikt in UIs om lange taken te structureren in een overzichtelijk aantal stappen, of om complexe taken eenvoudiger te maken voor nieuwe gebruikers. Het Wizard pattern bevat de onderdelen die een dergelijke UI moet/kan bevatten. Een aanpassing van het CAP3 Wizard patroon uit [45] (op zijn beurt gebaseerd op het Wizard pattern uit [42]) wordt gegeven in figuur 8.5. De “Step setup” Container bevat een aantal “User input” (aangegeven met een Repetition tag) velden. De verschillende stappen van de Wizard kunnen genavigeerd worden met de “Previous” en “Next” tools. Een optionele “List of steps” SelectableCollection geeft een overzicht van de verschillende stappen (en ook hiermee kan genavigeerd worden tussen stappen). Het genereren van een strict constraint uit dit patroon heeft als resultaat dat de constraint eist dat de exacte containment relaties gerespecteerd worden. Het diagram in figuur 8.6 zou niet succesvol valideren voor een strict constraint, maar voor een flexible constraint is de afwezigheid van de ConceptualGroup rond de “Previous” en “Next” tools geen probleem (de relaties moeten wel bestaan vanuit beide tools uit de ConceptualGroup!). De “Step setup” component (en haar inhoud) moet ook aanwezig zijn in een implementatie van een Wizard. De “List of steps” component is optioneel in het pattern en hoeft dus niet aanwezig te zijn. Appendix B.2.1 en B.2.2 tonen het verschil tussen een respectievelijk strict en flexible constraint gegenereerd uit het diagram in figuur 8.5.
8.3.3
Multi-platform UI development
Als derde toepassing voor het genereren van constraints wordt multi-platform UI development voorgesteld. In deze toepassing wordt een constraint diagram gebruikt in het kader van UI design voor applicaties die op meerdere platformen uitgevoerd dienen te worden. Een constraint diagram wordt hier gebruikt om een specificatie uit te werken die de basis requirements van de UI voor de applicatie bevat. Implementatie diagrammen kunnen dan verschillende cases uitwerken voor verschillende doelplatformen. Concreet kan een lead designer een dergelijke “master” specificatie defini¨eren (een constraint diagram) die de gemeenschappelijke requirements van de UI op de verschillende platformen bevat. Deze requirements bestaan uit compo-
8.3. GENEREREN VAN CONSTRAINTS
93
Figuur 8.5: CAP3 Wizard pattern gebaseerd op het wizard diagram uit [45].
Figuur 8.6: Implementatie van het Wizard pattern, afgechecked door een flexible constraint. Rechtstreekse DataFlow relaties op de “Previous” en “Next” tools worden toegelaten.
94
HOOFDSTUK 8. IMPLEMENTATIE
nenten en relaties. Optionele componenten kunnen gebruikt worden om requirements te defini¨eren die niet in alle implementaties aanwezig moeten zijn, maar wanneer wel ge¨ımplementeerd toch aan een bepaalde constraints moeten voldoen. Bij wijze van illustratie wordt een case voor een multi-platform MP3 player UI uitgewerkt. Een MP3 Player (zie figuur 8.7 voor de “master” specificatie) bestaat minimum uit een aantal controle-knoppen en een volume knop. Bijkomend kunnen er componenten zijn voor het liedje dat afgespeeld wordt, een seek control en een exit tool. Figuur 8.8 toont een case waarbij een MP3 Player UI design gemaakt werd voor een desktop platform. Figuur 8.9 toont een case voor een smartphone of PDA. Beiden valideren voor zowel een strict als flexible constraint, gegenereerd uit het diagram in figuur 8.7. Belangrijk om op te merken is dat er zonder problemen componenten toegevoegd mogen worden aan de implementaties, zolang de componenten gedefinieerd in de constraint maar aanwezig zijn (en in de juiste hi¨erarchische indeling, indien het een strict constraint aangaat). Concreet kan dit bijvoorbeeld toegepast worden in situaties waarbij verschillende designers de UIs ontwerpen voor de verschillende platformen. Een master CAP3 specificatie kan op voorhand gedefinieerd worden door een lead designer, of door het team te samen, en de individuele designs kunnen getoetst worden aan de master specificatie. Hierdoor kunnen vroegtijdig in het ontwikkelingsproces eventuele problemen voorkomen/opgelost worden. Een design dat aan de master specificatie voldoet voldoet ook aan de requirements voor de UI (indien de specificatie goed ontworpen is) . Er is echter ook een nadeel verbonden aan deze methode. Door een specifieke case uit te werken voor bepaalde platformen wordt indruk gewekt dat de “platform-specifieke” CAP3 AUIs concreter zijn. In de realiteit is dit niet het geval, alle cases zijn nog steeds implementatie ´en platform onafhankelijk (zelfs de platform specifieke cases), maar het is wel een afwijking van de filosofie achter de AUI om cases uit te werken voor verschillende platformen.
8.4
Evaluatie
In deze bespreking wordt de aandacht gelegd op het evalueren van a) het gebruik van EVL om semantische constraints te leggen op CAP3 modellen en b) het genereren van EVL constraints uit CAP3 modellen en de waarde hiervan voor de gebruiker. De cognitive dimensions [12, 13] en de richtlijnen in [32] zullen onderdeel uitmaken van deze bespreking. De EVL constraints voor CAP3 (zowel de manueel geschreven als de gegenereerde) dragen bij tot het verlagen van de error-proneness van het ontwerpen van CAP3 modellen. Goed gedefinieerde semantische constraints kunnen er-
8.4. EVALUATIE
95
Figuur 8.7: “Master” CAP3 specificatie voor een MP3-speler die de elementen bevat die platform-specifieke implementaties van een “MP3 Player” moeten bevatten.
Figuur 8.8: MP3-speler voor een desktop platform.
96
HOOFDSTUK 8. IMPLEMENTATIE
Figuur 8.9: MP3-speler voor een smartphone/PDA platform. voor zorgen dat een gebruiker feedback krijgt over de inhoud van zijn model, en hij kan op basis van deze feedback zijn model bijsturen. Dit kan om evidente redenen vooral waardevol zijn wanneer de auteur van de constraints een andere persoon is dan de gebruiker ervan. Semantische constraints zorgen er ook voor dat een nieuwe gebruiker minder diepgaande kennis moet hebben van het gebruikte meta-model bij het ontwerpen van diagrammen. De tool zal de gebruiker bijsturen indien hij fouten maakt, hierdoor kunnen nieuwe gebruikers makkelijker instappen in het gebruik van CAP3 (empowering new design participants). Een door de tool gegenereerde constraint is steeds per definitie syntactisch correct. Dit elimineert volledig de kans dat een gebruiker een syntactische fout maakt bij het defini¨eren van constraints. De error proneness van het defini¨eren van constraints wordt hierdoor aanzienlijk verlaagd. Uiteraard kunnen er nog steeds semantische fouten gemaakt worden zolang deze niet door andere constraints verboden worden. Het defini¨eren van constraints wordt vereenvoudigd voor niet-technische gebruikers (verlaging van hard mental operations) doordat zij geen kennis moeten hebben van programmeren. Gebruikers hoeven bovendien niet langer kennis te hebben van de specifieke constraint language. Ook diepgaande kennis van het gebruikte meta model is minder belangrijk. De drempel tot het gebruik van de tool (en bij uitbreiding de AUI) wordt hierdoor verlaagd en hierdoor kunnen meer diverse gebruikers de tool en AUI gebruiken
8.4. EVALUATIE
97
(empowering new design participants). Het genereren van constraints is een manier om de viscosity van het schrijven van constraints (of het proberen van verschillende constraints) te verlagen. Een gebruiker kan makkelijker en vlugger ingrijpende aanpassingen doen (componenten, relaties en attributen wijzigen) in de grafische tool en vervolgens de EVL code opnieuw genereren. Het is mogelijk om de tool automatisch de constraints te laten checken iedere keer dat het model wordt opgeslagen, een voorbeeld van progressive evaluation. Het gebruik van constraints voor het valideren van UI design patterns en multiplatform design diagrams is een manier om design regels op te leggen aan meerdere designers in een project. Bij het ontwerpen van de onderdelen van de UI kunnen zij beroep doen op de constraints die gelegd werden op componenten of bepaalde patronen. Het falen of slagen van deze constraints zorgt ervoor dat de designer onmiddelijk semantische feedback krijgt op zijn design. Een nadeel bij de voorgestelde toepassing rond multi-platform design diagrams is dat cases uitwerken voor verschillende platformen niet strict in lijn is met de filosofie achter AUIs (doch er is principieel geen schending van de definitie van de AUI, een case blijft steeds implementatie en platform onafhankelijk). Een beperking van de huidige tool is dat een constraint diagram momenteel verwacht wordt te bestaan uit ´e´en top-level component. Bij diagrammen met meerdere top-level componenten zal slechts uit ´e´en van de top-level componenten van het diagram een constraint gegenereerd worden. De gegenereerde constraints bestaan ook altijd uit een controle op het bestaan van componenten en relaties (en sommige attributen), andere vormen van constraints kunnen momenteel niet gegenereerd worden (zoals bv. “AbstractComponent namen moeten bestaan en uniek zijn” uit tabel 8.1). Een technische beperking van de tool is het feit dat het genereren van de constraints nog niet ge¨ıntegreerd is in de GMF editor. De gebruiker kan momenteel de constraints genereren via een Eclipse Run Configuration script, maar het zou de bruikbaarheid van de tool ten goede komen moest er een “Generate” optie beschikbaar zijn in de GMF editor.
98
HOOFDSTUK 8. IMPLEMENTATIE
Hoofdstuk 9 Conclusie Op basis van een vergelijkende studie tussen AUI descriptions die dedicated tool support hebben werd CAP3 gekozen als basis voor een nieuwe AUI tool. De doelstelling van deze tool was het bruikbaarder en breder toepasbaar maken van AUIs. Er werd concreet een manier gedemonstreerd om semantische constraints te defini¨eren op het CAP3 meta model, alsook een tool om semantische constraints te genereren uit CAP3 diagrammen. Deze semantische constraints verifi¨eren of een CAP3 diagram betekenisvol is t.o.v. het meta model. De semantische constraints werden ge¨ımplementeerd m.b.v. de EVL constraint language. Deze constraints bleken waardevol omdat ze het defini¨eren van betekenisvolle CAP3 modellen vereenvoudigen voor zowel ervaren als nieuwe gebruikers door feedback te geven op de inhoud van hun modellen. Gebruikers moeten bovendien minder kennis hebben van het onderliggende meta model. De tool om constraints te genereren werd ge¨ımplementeerd als een EGL template. Deze tool maakt het voor niet-technische gebruikers eenvoudiger om bepaalde constraints aan te maken op CAP3 modellen. Er werd aangetoond dat het grafisch defini¨eren van constraints op deze manier de toepasbaarheid van AUIs voor een breder publiek mogelijk maakt. Drie verschillende mogelijke toepassingen werden uitgewerkt: het defini¨eren van constraints op CAP3 componenten, het afchecken van de correcte implementatie van design patterns, en als ondersteuning bij multi-platform UI development. Een wenselijke toekomstige uitbreiding voor de tool is een integratie van het genereren van constraints in de diagram editor, dit kan de tool eenvoudiger maken in gebruik. In de gegenereerde EVL constraints kunnen er eventueel ook fixes gegenereerd worden voor errors die op een betrouwbare manier opgelost kunnen worden. Een laatste mogelijke uitbreiding is het genereren van EWL (Epsilon Wizard Language) code uit diagrammen. Hiermee kunnen patronen gedefinieerd worden die een gebruiker m.b.v. een wizard in de tool kan toevoegen aan zijn diagram.
99
100
HOOFDSTUK 9. CONCLUSIE
Bijlage A Epsilon syntax en features A.1
Epsilon Object Language
Het is weinig zinvol om de volledige syntax en features van EOL toe te lichten, daarom worden enkel een aantal belangrijke features die voor de toepassing relevant zijn besproken. Om deze features te demonstreren wordt een eenvoudig EMF meta model ge¨ıntroduceerd waarin een Person klasse gedefinieerd wordt die een persoon modelleert. Deze klasse heeft een aantal attributen met persoonlijke informatie en mogelijk een lijst van children, die aangeeft of de persoon kinderen heeft (en welke). In de tekstuele Emfatic representatie ziet dit meta model er als volgt uit: 1 package personModel ; 2 3 class Person { 4 attr String name ; 5 attr String email ; 6 attr String address ; 7 attr String telephoneNr ; 8 attr int age ; 9 val Person [ * ] children ; 10 }
Een belangrijke feature van EOL is de ondersteuning van collection querying operaties (zoals select()) waarmee complexe queries op modellen eenvoudig uitgevoerd kunnen worden. Onderstaand codevoorbeeld selecteert alle Person klassen die children hebben en waarvan het name attribuut gelijk is aan “Foo”: 1
Person . allInstances ( ) . select ( w | w . name = 'Foo' and children . isDefined ( ) ) ;
101
Ð
â
102
BIJLAGE A. EPSILON SYNTAX EN FEATURES
Andere interessante features van EOL zijn o.a. extended properties. Het is mogelijk om attributen toe te voegen aan klassen in een EMF model die niet aanwezig zijn in het meta model. Dit kan bijvoorbeeld gebruikt worden om informatie toe te voegen aan een model die handig is om bepaalde model management taken effici¨ent(er) uit te voeren. Extended properties worden voorafgegaan door een ˜ symbool. Volgend voorbeeld toont het toevoegen van een numChildren element aan alle Person klassen in een model: 1 2 3 4 5
var people := Person . allInstances ( ) ; for ( c in people ) { if ( c . children . isDefined ( ) ) c . ˜ numChildren := c . children . size ( ) ; }
Zoals eerder vermeld is het binnen EOL mogelijk om operations te defini¨eren. Een bijkomende feature van EOL is dat operations gedefinieerd kunnen worden o´p bepaalde componenten (i.e. als member van een component). De component waarop de operation uiteindelijk uitgevoerd wordt kan dan vervolgens aangesproken worden met het self keyword. Een voorbeeld: -- Geef alle personen waarvan alle kinderen ouder zijn Ðâ dan 18 2 Person . allInstances ( ) . select ( p | p . getYoungestChildAgeÐâ ( ) > 17) ; 1
3 4 @cached 5 operation Person getYoungestChildAge ( ) : int 6 { 7 int age ; 8 for ( c in self . children ) 9 { 10 if ( ! age . isDefined ( ) ) 11 age := c . age ; 12 else if ( c . age < age ) 13 age := c . age ; 14 } 15 16 return age ; 17 }
De @cached annotation bij deze operation zorgt ervoor dat de operation slechts ´e´enmaal ge¨evalueerd wordt voor een bepaalde Person. Wanneer de functie een tweede maal aangeroepen wordt wordt de waarde van de vorige functie-aanroep teruggegeven, een effici¨entiewinst. Het is ook mogelijk om Java klassen aan te roepen en Java objecten te instanti¨eren (m.b.v. de Native() constructor), waarmee functionaliteit die
A.2. EPSILON VALIDATION LANGUAGE
103
niet (of onvoldoende) ondersteund wordt door EOL benut kan worden. Onderstaand voorbeeld toont het gebruik van een Java Vector object in EOL: 1 2
var names = new Native ( "java.util.Vector" ) ; names . push ( "Foo" ) ;
A.2
Epsilon Validation Language
Een EVL constraint bestaat uit een aantal keywords met daarop volgend EOL uitdrukkingen die betekenisvol zijn voor het keyword in kwestie. Deze uitdrukkingen kunnen bestaan uit een enkele regel of meerdere regels sequenti¨ele EOL code voor complexere constraints. Het context keyword geeft aan op welke klassen van het meta model de constraints die binnen het context blok gedefinieerd worden van toepassing zijn. Hiermee kan een constraint gedefinieerd worden die enkel ge¨evalueerd wordt voor de component waarvoor deze constraint relevant is. Een constraint waarvan de context de top-level klasse van het meta-model is zal zo ook slechts ´e´en maal uitgevoerd worden voor het gehele metamodel. Een context blok kan meerdere constraint en critique blokken bevatten. Qua syntax zijn beide blokken analoog, maar conceptueel zijn constraints strenger dan critiques; het falen van een constraint tijdens validatie zal een error teweeg brengen, terwijl het falen van een critique slechts een warning teweeg brengt. Binnen een constraint of critique blok kan de klasse die momenteel ge¨evalueerd wordt aangesproken worden met het self keyword. Binnen een constraint of critique blok kan een optionele guard uitdrukking geplaatst worden die bepaalt of de constraint (of critique) van toepassing is op de specifieke klasse die op dit moment ge¨evalueerd wordt. Dit kan op basis van e.g. de waarde van de attributen in deze klasse. De check uitdrukking bevat de eigenlijke voorwaarden waaraan de klasse moet voldoen om de constraint te doen slagen. Het check blok geeft een boolean waarde terug; true wanneer de klasse slaagt voor de constraint, en false wanneer de klasse faalt. Het message keyword definieert de boodschap die getoond zal worden aan de gebruiker indien de constraint (of critique) faalt. In het optionele fix blok kan men tenslotte een automatische fix defini¨eren waarmee de fout automatisch gecorrigeerd kan worden. De title uitdrukking beschrijft wat de fix zal doen (deze wordt getoond aan de gebruiker). Het is de bedoeling dat het do blok het model zo wijzigt dat de constraint zal slagen bij een volgende evaluatie.
104
BIJLAGE A. EPSILON SYNTAX EN FEATURES
Volgend code-voorbeeld toont het gebruik van deze elementen aan voor het Person meta-model uit de vorige sectie, met een constraint die ervoor zorgt dat de email attributen van Person klassen geen spaties bevatten: 1 2 3 4 5 6 7 8 9
context Person { critique EmailCannotHaveSpaces { guard : self . email . isDefined ( ) check : self . email . split ( " " ) . size ( ) < 2 message : "The email address of Person '" + self . Ðâ name + "' cannot have spaces"
10 11 12
13 14 15 16 17 18 19
fix { title : "Rename email address '" + self . email + "Ðâ ' to '" + self . email . replaceAll ( " " , "" ) + "'"Ðâ ; do { self . email := self . email . replaceAll ( " " , "" ) ; } } } }
Het context blok in bovenstaand voorbeeld bepaalt dat de constraints die erbinnen gedefinieerd worden enkel zullen ge¨evalueerd worden voor de Person elementen in het model, andere klassen worden door deze constraints niet ge¨evalueerd. Vervolgens wordt een critique (warning) gedefinieerd met de naam EmailCannotHaveSpaces (deze kan eventueel later gebruikt worden om naar de critique te refereren). De guard uitdrukking zorgt ervoor dat de critique enkel zal ge¨evalueerd worden wanneer het email attribuut van de Person die momenteel ge¨evalueerd wordt een waarde heeft. De check uitdrukking controleert of het email adres van de klasse geen spaties bevat. Wanneer de check uitdrukking false teruggeeft faalt de constraint en wordt de message ingevuld en teruggegeven. Het fix blok (en meer specifiek het do blok) verwijdert de spaties uit het email adres van de Person en corrigeert zo de fout.
A.3
Epsilon Generation Language
Een EGL programma bestaat uit een aantal sections. In statische secties wordt plain-text geschreven; deze tekst verschijnt verbatim in de ouput. In
A.3. EPSILON GENERATION LANGUAGE
105
dynamische secties wordt uitvoerbare EOL code geplaatst waarmee alle functionaliteit van EOL hergebruikt kan worden en aangepaste uitvoer gedefinieerd kan worden. De [% en %] scheidingstekens worden gebruikt om dynamische secties met EOL code te plaatsen binnen statische tekst, terwijl [%= gebruikt wordt om output van dynamische secties te defini¨eren, bijvoorbeeld [35]: 1 2 3
[% for ( i in Sequence { 1 . . 5 } ) { %] i is [%= i %] [%} %]
Dit template print een lijst van nummers af, voorafgegaan door de “i is” statische tekst (geplaatst buiten alle [% en %] scheidingstekens). Na uitvoering van dit template krijgt men het volgende resultaat: 1 2 3 4 5
i i i i i
is is is is is
1 2 3 4 5
EGL is een uitbreiding op EOL, het is daarom ook binnen EGL mogelijk om operations te defini¨eren. Belangrijk is dat operations met een @template annotation ook output kunnen genereren voor het EGL template. Onderstaand codevoorbeeld toont het gebruik van een operation om een lijst van personen te genereren in HTML: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
People [% for ( w in Person>allInstances ( ) ) { %][%=w . showName ( ) ;%][% } %] [% @template operation Person showName ( ) { %]
106
BIJLAGE A. EPSILON SYNTAX EN FEATURES
20
[%=self . name%] 21 [% 22 } 23 %]
Gegeven dat er 3 Person klassen zijn met de namen “Foo”, “Bar” en “Baz”, zal dit bij uitvoering het volgende resultaat geven: 1 2 3
People 4 5 6
11 12
Bijlage B Generator output B.1
Notification component EVL constraint
1 -- Flexibility type: STRICT 2 3 context Container 4 { 5 constraint defaultconstraint 6 { 7 check 8 { 9 10 if ( self . typeName <> 'Notification' ) 11 { 12 return true ; -- skip 13 } 14 15 -- The output message 16 var msg ; 17 18 ---------------19 -- Components -20 ---------------21 22 -- Check if the 'Information' Container exists as 23
24 25 26
Ð
â
a child of self var information := self . components>select ( w | w . Ðâ eClass ( ) . name = 'Container' and w . name = 'Ðâ Information' and w . typeName = 'Element' ) ; if ( information . size ( ) = 0 ) {
107
108
BIJLAGE B. GENERATOR OUTPUT msg := "The 'Information' Container should Ðâ exist as a child of '' and have the 'ElementÐâ ' type name" ; return false ;
27
28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61
62 63 64 65
} else { -- Check component attributes/properties }
-- Success return true ; } message : self . eClass ( ) . name + " '" + self . name + "Ðâ '" + " does not match 'defaultconstraint' Ðâ pattern (" + msg + ")" } critique defaultconstraintOptional { check { if ( self . typeName <> 'Notification' ) { return true ; -- skip } -- The output message var msg ; -------------------------- Optional components --------------------------- Check if the 'OK' Tool exists as a child of Ðâ self var ok := self . components>select ( w | w . eClass ( ) . Ðâ name = 'Tool' and w . name = 'OK' and w . typeNameÐâ = 'End' ) ; if ( ok . size ( ) = 0 ) { msg := "The 'OK' Tool should exist as a child of 'OK' and have the 'End' type name" ;
Ð
â
B.2. WIZARD PATTERN EVL CONSTRAINT return false ;
66 67 68 69 70 71 72 73 74 75 76
77 78
} else { -- Check component attributes/properties } --success return true ; } message : self . eClass ( ) . name + " '" + self . name + "Ðâ '" + " does not fully match 'defaultconstraint' Ðâ pattern (" + msg + ")" } }
B.2 B.2.1
Wizard pattern EVL constraint Strict constraint
1 -- Flexibility type: STRICT 2 3 context Container 4 { 5 constraint wizard 6 { 7 check 8 { 9 if ( self . name <> 'Wizard' ) 10 { 11 return true ; -- skip 12 } 13 14 15 -- The output message 16 var msg ; 17 18 ---------------19 -- Components -20 ---------------21 22 -- Check if the 'Step setup' Container exists as 23
109
Ð
â
a child of self var stepsetup := self . components>select ( w | w . Ðâ eClass ( ) . name = 'Container' and w . name = 'StepÐâ setup' ) ;
110 24 25 26 27 28 29 30 31 32 33 34 35 36
37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
57 58 59 60
BIJLAGE B. GENERATOR OUTPUT
if ( stepsetup . size ( ) = 0 ) { msg := "The 'Step setup' Container should existÐâ as a child of 'Wizard'" ; return false ; } else { -- Check component attributes/properties } -- Check if the 'User input' ActiveMaterial Ðâ exists as a child of stepsetup[0] var userinput := stepsetup [ 0 ] . components>Ðâ select ( w | w . eClass ( ) . name = 'ActiveMaterialÐâ ' and w . name = 'User input' ) ; if ( userinput . size ( ) = 0 ) { msg := "The 'User input' ActiveMaterial Ðâ should exist as a child of 'Step setup'" ; return false ; } else { -- Check component attributes/properties -- Component must define repetition if ( not userinput [ 0 ] . repetition . isDefined ( ) ) { msg := "The 'User input' component should Ðâ define Repetition" ; return false ; } } -- Check if the 'Navigation' AbstractComponent Ðâ exists as a child of self var navigation := self . components>select ( w | w . Ðâ eClass ( ) . name = 'AbstractComponent' and w . nameÐâ = 'Navigation' ) ; if ( navigation . size ( ) = 0 ) { msg := "The 'Navigation' AbstractComponent should exist as a child of 'Wizard'" ;
Ð
â
B.2. WIZARD PATTERN EVL CONSTRAINT 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79 80 81 82
83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98
111
return false ; } else { -- Check component attributes/properties } -- Check if the 'Previous' Tool exists as a Ðâ child of navigation[0] var previous := navigation [ 0 ] . components>Ðâ select ( w | w . eClass ( ) . name = 'Tool' and w . Ðâ name = 'Previous' ) ; if ( previous . size ( ) = 0 ) { msg := "The 'Previous' Tool should exist as aÐâ child of 'Navigation'" ; return false ; } else { -- Check component attributes/properties } -- Check if the 'Next' Tool exists as a child Ðâ of navigation[0] var next := navigation [ 0 ] . components>select ( w Ðâ | w . eClass ( ) . name = 'Tool' and w . name = 'Ðâ Next' ) ; if ( next . size ( ) = 0 ) { msg := "The 'Next' Tool should exist as a child of 'Navigation'" ; return false ; } else { -- Check component attributes/properties }
Ð
â
-------------------- Relationships -------------------if ( relationshipExists ( 'DataFlow' , 'Navigation' , 'Step setup' ) <> true )
Ð
â
112
BIJLAGE B. GENERATOR OUTPUT {
99 100
msg := "A 'DataFlow' relationship must exist between 'Navigation' and 'Step setup'" ; return false ;
101 102 103 104 105 106 107 108
109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129
130 131 132 133
134 135 136
Ð
â
} -- Success return true ; } message : self . eClass ( ) . name + " '" + self . name + "Ðâ '" + " does not match 'wizard' pattern (" + msg Ðâ + ")" } critique wizardOptional { check { if ( self . name <> 'Wizard' ) { return true ; -- skip }
-- The output message var msg ; -------------------------- Optional components --------------------------- Check if the 'List of steps' ActiveMaterial Ðâ exists as a child of self var listofsteps := self . components>select ( w | w . Ðâ eClass ( ) . name = 'ActiveMaterial' and w . name = Ðâ 'List of steps' and w . typeName = 'Ðâ SelectableViewSet' ) ; if ( listofsteps . size ( ) = 0 ) { msg := "The 'List of steps' ActiveMaterial Ðâ should exist as a child of 'List of steps' Ðâ and have the 'SelectableViewSet' type name" ; return false ; } else
B.2. WIZARD PATTERN EVL CONSTRAINT 137 138 139 140 141 142
143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162
163 164 165 166 167 168 169 170 171 172 173 174
113
{ -- Check component attributes/properties } -- Check if the 'Step' Container exists as a Ðâ child of listofsteps[0] var step := listofsteps [ 0 ] . components>select ( wÐâ | w . eClass ( ) . name = 'Container' and w . name Ðâ = 'Step' ) ; if ( step . size ( ) = 0 ) { msg := "The 'Step' Container should exist as a child of 'List of steps'" ; return false ; } else { -- Check component attributes/properties -- Component must define repetition if ( not step [ 0 ] . repetition . isDefined ( ) ) { msg := "The 'Step' component should define Repetition" ; return false ; }
Ð
â
Ð
â
} -- Check if the 'End' Tool exists as a child of Ðâ self var end := self . components>select ( w | w . eClass ( ) Ðâ . name = 'Tool' and w . name = 'End' and w . Ðâ typeName = 'End' ) ; if ( end . size ( ) = 0 ) { msg := "The 'End' Tool should exist as a child of 'End' and have the 'End' type name" ; return false ; } else { -- Check component attributes/properties } --success
Ð
â
114
BIJLAGE B. GENERATOR OUTPUT return true ;
175 176 177
178 179 180 181 182 183 184 185 186 187 188 189 190
191 192 193 194 195 196
} message : self . eClass ( ) . name + " '" + self . name + "Ðâ '" + " does not fully match 'wizard' pattern (" Ðâ + msg + ")" } }
----------------- Operations ------------------ Check if a relationship exists operation relationshipExists ( className : String , Ðâ sourceName : String , targetName : String ) : Boolean { var relationships := Flow . allInstances ( ) ; var rel := relationships>select ( w | w . eClass ( ) . name Ðâ = className and w . source . name = sourceName and w . Ðâ target . name = targetName ) ; if ( rel . size ( ) = 0 ) { return false ; } return true ; }
B.2.2
Flexible constraint
1 -- Flexibility type: FLEXIBLE 2 3 context Container 4 { 5 constraint wizard 6 { 7 check 8 { 9 if ( self . name <> 'Wizard' ) 10 { 11 return true ; -- skip 12 } 13 14 15 -- The output message 16 var msg ; 17
B.2. WIZARD PATTERN EVL CONSTRAINT 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
115
----------------- Components ------------------ Check if the 'Step setup' Container exists var stepsetup := Container . allInstances ( )>selectÐâ ( w | w . name = 'Step setup' ) ; if ( stepsetup . size ( ) = 0 ) { msg := "The 'Step setup' Container should existÐâ "; return false ; } else { -- Check component attributes/properties } -- Check if the 'User input' ActiveMaterial Ðâ exists var userinput := ActiveMaterial . allInstances ( )>Ðâ select ( w | w . name = 'User input' ) ; if ( userinput . size ( ) = 0 ) { msg := "The 'User input' ActiveMaterial should exist" ; return false ; } else { -- Check component attributes/properties
Ð
â
-- Component must define repetition if ( not userinput [ 0 ] . repetition . isDefined ( ) ) { msg := "The 'User input' component should Ðâ define Repetition" ; return false ; } } -- Check if the 'Previous' Tool exists var previous := Tool . allInstances ( )>select ( w | wÐâ . name = 'Previous' ) ;
116 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98
99
BIJLAGE B. GENERATOR OUTPUT
if ( previous . size ( ) = 0 ) { msg := "The 'Previous' Tool should exist" ; return false ; } else { -- Check component attributes/properties } -- Check if the 'Next' Tool exists var next := Tool . allInstances ( )>select ( w | w . Ðâ name = 'Next' ) ; if ( next . size ( ) = 0 ) { msg := "The 'Next' Tool should exist" ; return false ; } else { -- Check component attributes/properties } -------------------- Relationships -------------------var relExists ; var sourceComponents = Sequence { 'Navigation' } ; var targetComponents = Sequence { 'Step setup' } ; sourceComponents . add ( 'Previous' ) ; sourceComponents . add ( 'Next' ) ; if ( flexibleRelationshipExists ( 'DataFlow' , Ðâ sourceComponents , targetComponents ) <> true ) { sourceComponents . removeAt ( 0 ) ; targetComponents . removeAt ( 0 ) ; msg := "A 'DataFlow' relationship must exist Ðâ between 'Navigation' or " + sourceComponentsÐâ + " and 'Step setup' or " + Ðâ targetComponents ; return false ;
B.2. WIZARD PATTERN EVL CONSTRAINT }
100 101 102 103 104 105 106
107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
128 129 130 131
132 133 134 135 136 137 138 139
117
-- Success return true ; } message : self . eClass ( ) . name + " '" + self . name + "Ðâ '" + " does not match 'wizard' pattern (" + msg Ðâ + ")" } critique wizardOptional { check { if ( self . name <> 'Wizard' ) { return true ; -- skip }
-- The output message var msg ; -------------------------- Optional components --------------------------- Check if the 'List of steps' ActiveMaterial Ðâ exists var listofsteps := ActiveMaterial . allInstances ( ) Ðâ >select ( w | w . name = 'List of steps' and w . Ðâ typeName = 'SelectableViewSet' ) ; if ( listofsteps . size ( ) = 0 ) { msg := "The 'List of steps' ActiveMaterial Ðâ should exist and have the 'SelectableViewSetÐâ ' type name" ; return false ; } else { -- Check component attributes/properties }
118
BIJLAGE B. GENERATOR OUTPUT
140 141
-- Check if the 'Step' Container exists var step := Container . allInstances ( )>select ( w | w . name = 'Step' ) ;
142 143 144 145 146 147 148 149 150 151 152 153 154 155
â
if ( step . size ( ) = 0 ) { msg := "The 'Step' Container should exist" ; return false ; } else { -- Check component attributes/properties -- Component must define repetition if ( not step [ 0 ] . repetition . isDefined ( ) ) { msg := "The 'Step' component should define Repetition" ; return false ; }
156 157 158 159 160 161
Ð
â
} -- Check if the 'End' Tool exists var end := Tool . allInstances ( )>select ( w | w . nameÐâ = 'End' and w . typeName = 'End' ) ;
162 163 164 165
if ( end . size ( ) = 0 ) { msg := "The 'End' Tool should exist and have the 'End' type name" ; return false ; } else { -- Check component attributes/properties }
166 167 168 169 170 171 172 173 174 175 176
177 178 179 180
Ð
Ð
â
--success return true ; } message : self . eClass ( ) . name + " '" + self . name + "Ðâ '" + " does not fully match 'wizard' pattern (" Ðâ + msg + ")" } }
B.2. WIZARD PATTERN EVL CONSTRAINT 181 182 183 184 185 186 187 188 189
119
----------------- Operations ------------------ Check if a relationship exists operation relationshipExists ( className : String , Ðâ sourceName : String , targetName : String ) : Boolean { var relationships := Flow . allInstances ( ) ; var rel := relationships>select ( w | w . eClass ( ) . name Ðâ = className and w . source . name = sourceName and w . Ðâ target . name = targetName ) ; if ( rel . size ( ) = 0 ) { return false ; } return true ; }
190 191 192 193 194 195 196 197 -- Check if a relationship exists between the
Ð
â
components of two ConceptualGroups 198 operation flexibleRelationshipExists ( className : StringÐâ , sourceComponents : Sequence , targetComponents : Ðâ Sequence ) : Boolean 199 { 200 var relationships := Flow . allInstances ( ) ; 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218
var sourceTopLevel := sourceComponents [ 0 ] ; var targetTopLevel := targetComponents [ 0 ] ; -- check if a relationship exists between the Ðâ conceptualgroup(s) first if ( relationshipExists ( className , sourceTopLevel , targetTopLevel ) = true ) { return true ; } -- check if relationships exist between internal components if ( sourceComponents . size ( ) > 1 ) { sourceComponents . removeAt ( 0 ) ; } if ( targetComponents . size ( ) > 1 ) { targetComponents . removeAt ( 0 ) ;
Ð
â
Ð
â
120 219 220 221
222 223 224 225 226 227 228 229 230 231
BIJLAGE B. GENERATOR OUTPUT } if ( checkAllRelationshipsExist ( className , Ðâ sourceComponents , Sequence { targetTopLevel } ) = true ) { return true ; } if ( checkAllRelationshipsExist ( className , Sequence { sourceTopLevel } , targetComponents ) = true ) { return true ; }
241 242 243 244 245 246 247 248 249 250 251 252 253 254
â
Ð
â
if ( checkAllRelationshipsExist ( className , Ðâ sourceComponents , targetComponents ) = true ) { return true ; }
232 233 234 235 236 return false ; 237 } 238 239 -- Check if there's a relationship between every 240
Ð
Ð
â
component of sourceComponents and targetComponents operation checkAllRelationshipsExist ( className : StringÐâ , sourceComponents : Sequence , targetComponents : Ðâ Sequence ) : Boolean { var exists := true ; for ( s in sourceComponents ) { for ( t in targetComponents ) { if ( relationshipExists ( className , s , t ) <> true ) { exists := false ; } } } return exists ; }
Bibliografie [1] T. Bolognesi and E. Brinksma, “Introduction to the iso specification language lotos,” Comput. Netw. ISDN Syst., vol. 14, pp. 25–59, March 1987. [Online]. Available: http://portal.acm.org/citation.cfm?id=44211. 44214 [2] L. Bouillon, J. Vanderdonckt, and K. C. Chow, “Flexible re-engineering of web sites,” in Proceedings of the 9th international conference on Intelligent user interfaces, ser. IUI ’04. New York, NY, USA: ACM, 2004, pp. 132–139. [Online]. Available: http://doi.acm.org/10.1145/964442.964468 [3] G. Calvary, J. Coutaz, D. Thevenin, Q. Limbourg, N. Souchon, L. Bouillon, M. Florins, J. Vanderdonckt, and J. V, “Plasticity of user interfaces: A revised reference framework,” in In Task Models and Diagrams for User Interface Design. Publishing House, 2002, pp. 127–134. [4] G. Calvary, J. Coutaz, D. Thevenin, Q. Limbourg, L. Bouillon, and J. Vanderdonckt, “A unifying reference framework for multi-target user interfaces,” INTERACTING WITH COMPUTERS, vol. 15, pp. 289–308, 2003. [5] P. F. Campos and N. J. Nunes, “Canonsketch: a user-centered tool for canonical abstract prototyping,” in In Proceedings of DSV-IS’2004, 11th International Workshop on Design, Specification and Verification of Interactive Systems. Springer-Verlag, 2004. [6] L. Constantine and P. Campos, “Canonsketch and tasksketch: Innovative modeling tools for usage-centered design.” [7] L. Constantine, H. Windl, J. Noble, and L. Lockwood, “From abstraction to realization: Canonical abstract prototypes for user interface design revised,” 2003. [8] L. L. Constantine, “Canonical abstract prototypes for abstract visual and interaction design,” in Interactive Systems. Design, Specification, and Verification, ser. Lecture Notes in Computer Science. Berlin / Heidelberg: Springer, 2003, vol. 2844, pp. 1–15. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-39929-2 1 121
122
BIBLIOGRAFIE
[9] L. L. Constantine and L. A. D. Lockwood, “Usage-centered engineering for web applications,” IEEE Softw., vol. 19, pp. 42–50, March 2002. [Online]. Available: http://portal.acm.org/citation.cfm?id=624648.626381 [10] P. P. da Silva and N. W. Paton, “User interface modeling in umli,” IEEE Software, vol. 20, pp. 62–69, 2003. [11] J. V. den Bergh and K. Coninx, “Cup 2.0: High-level modeling of contextsensitive interactive applications,” in MoDELS, 2006, pp. 140–154. [12] T. R. G. Green, “Cognitive dimensions of notations,” in People and Computers V. University Press, 1989, pp. 443–460. [13] T. Green, “Instructions and descriptions: some cognitive aspects of programming and similar activities,” 2000. [14] M. Haesen, K. Coninx, J. V. D. Bergh, and K. Luyten, “Muicser: A process framework for multi-disciplinary user-centered software engineering processes,” in In Proceedings of Human-Centred Software Engineering, 2008, pp. 150–165. [15] D. Kolovos, L. Rose, and R. Paige, “The epsilon book,” 2011. [16] D. S. Kolovos, R. F. Paige, and F. A. C. Polack, “The epsilon object language (eol,” in In: Proceedings European Conference in Model Driven Architecture (EC-MDA) 2006. Springer, 2006, pp. 128–142. [17] D. S. Kolovos, L. M. Rose, S. B. Abid, R. F. Paige, F. A. C. Polack, and G. Botterweck, “Taming emf and gmf using model transformation,” in Proceedings of the 13th international conference on Model driven engineering languages and systems: Part I, ser. MODELS’10. Berlin, Heidelberg: Springer-Verlag, 2010, pp. 211–225. [Online]. Available: http://dl.acm.org/citation.cfm?id=1926458.1926479 [18] C. Larman, Agile and Iterative Development: A Manager’s Guide. arson Education, 2003.
Pe-
[19] Q. Limbourg, “Multi-Path Development of User Interfaces,” Ph.D. dissertation, Universite catholique de Louvain, 2004. [20] ——, “Usixml, user interface extensible markup language, reference manual,” 2007. [21] Q. Limbourg, J. Vanderdonckt, B. Michotte, L. Bouillon, and V. LopezJaquero, “Usixml: a language supporting multi-path development of user interfaces.” Springer-Verlag, 2004, pp. 11–13. [22] B. Michotte and J. Vanderdonckt, “Grafixml, a multi-target user interface builder based on usixml,” in Proceedings of the Fourth International Conference on Autonomic and Autonomous Systems. Washington, DC,
BIBLIOGRAFIE
123
USA: IEEE Computer Society, 2008, pp. 15–22. [Online]. Available: http://dl.acm.org/citation.cfm?id=1395980.1396094 [23] J. Miller and J. Mukerji, “Mda guide version 1.0.1,” Object Management Group (OMG), Tech. Rep., 2003. [24] F. Montero, M. Lozano, and P. Gonzalez, “Idealxml: an experience-based environment for user interface design and pattern manipulation,” Tech. Rep., 2005. [25] D. Moody, “The physics of notations: Toward a scientific basis for constructing visual notations in software engineering,” IEEE Trans. Softw. Eng., vol. 35, pp. 756–779, November 2009. [Online]. Available: http://dx.doi.org/10.1109/TSE.2009.67 [26] G. Mori, F. Paterno;, and C. Santoro, “Ctte: Support for developing and analyzing task models for interactive system design,” IEEE Transactions on Software Engineering, vol. 28, pp. 797–813, 2002. [27] L. N´obrega, N. J. Nunes, and H. Coelho, “Dialogsketch: dynamics of the canonical prototypes,” in Proceedings of the 4th international workshop on Task models and diagrams, ser. TAMODIA ’05. New York, NY, USA: ACM, 2005, pp. 19–25. [Online]. Available: http://doi.acm.org/10.1145/1122935.1122940 [28] L. Nobrega, N. J. Nunes, and H. Coelho, “H.: Mapping concurtasktrees into uml 2.0,” in In Proceedings of DSV-IS 05. Springer, 2005, pp. 237– 248. [29] D. A. Norman and S. W. Draper, User Centered System Design; New Perspectives on Human-Computer Interaction. Hillsdale, NJ, USA: L. Erlbaum Associates Inc., 1986. [30] N. J. Nunes and J. F. e Cunha, “Wisdom - a uml based architecture for interactive systems,” 2000. [31] Object Management Group, “Omg object constraint language (ocl), v 2.3.1,” 2012. [32] D. R. Olsen, Jr., “Evaluating user interface systems research,” in Proceedings of the 20th annual ACM symposium on User interface software and technology, ser. UIST ’07. New York, NY, USA: ACM, 2007, pp. 251– 258. [Online]. Available: http://doi.acm.org/10.1145/1294211.1294256 [33] F. Paterno, C. Santoro, and L. D. Spano, “Maria: A universal, declarative, multiple abstraction-level language for service-oriented applications in ubiquitous environments,” ACM Trans. Comput.-Hum. Interact., vol. 16, pp. 19:1–19:30, November 2009. [Online]. Available: http://doi.acm.org/10.1145/1614390.1614394
124
BIBLIOGRAFIE
[34] P. Pinheiro da Silva, “Object modelling of interactive systems: The umli approach,” Ph.D. dissertation, Manchester University, Manchester, United Kingdom, 2002. [35] L. M. Rose, R. F. Paige, D. S. Kolovos, and F. Polack, “The epsilon generation language,” in Model Driven Architecture - Foundations and Applications, 4th European Conference, ECMDA-FA 2008, Berlin, Germany, June 9-13, 2008. Proceedings, ser. Lecture Notes in Computer Science, I. Schieferdecker and A. Hartman, Eds., vol. 5095. Springer, 2008, pp. 1–16. [36] J. Rumbaugh, I. Jacobson, and G. Booch, Unified Modeling Language Reference Manual, The (2nd Edition). Pearson Higher Education, 2004. [37] D. C. Schmidt, “Model-driven engineering,” IEEE Computer, vol. 39, no. 2, February 2006. [Online]. Available: http://www.truststc.org/ pubs/30.html [38] P. P. D. Silva and N. W. Paton, “Umli: The unified modeling language for interactive applications,” in In Proceedings of UML2000, volume 1939 of LNCS. Springer, 2000, pp. 117–132. [39] ——, “A uml-based design environment for interactive applications,” in In Proceedings of UIDIS’01. IEEE Computer Society, 2001, pp. 60–71. [40] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, EMF: Eclipse Modeling Framework. Boston, Massachusetts: Addison-Wesley Professional, 2008. [41] J.-C. Tarby and M.-F. Barthet, “The diane+ method,” Computer-aided design of user interfaces, pp. 95–120, 1996. [42] J. Tidwell, Designing Interfaces. Beijing: O’Reilly, 2006. [43] H. Traetteberg, “Model-based user interface design,” Tech. Rep., 2002. [44] F. M. Trindade and M. S. Pimenta, “Renderxml - a multi-platform software development tool,” in Proceedings of the 6th international conference on Task models and diagrams for user interface design, ser. TAMODIA’07. Berlin, Heidelberg: Springer-Verlag, 2007, pp. 293–298. [Online]. Available: http://dl.acm.org/citation.cfm?id=1782434.1782468 [45] J. Van den Bergh and K. Coninx, “Cap3 for interaction design pattern diagrams?” in Proceedings of the 2nd International Workshop on Pattern-Driven Engineering of Interactive Computing Systems, ser. PEICS ’11. New York, NY, USA: ACM, 2011, pp. 4–7. [Online]. Available: http://doi.acm.org/10.1145/2018431.2018433 [46] J. Van den Bergh, K. Luyten, and K. Coninx, “Cap3: context-sensitive abstract user interface specification,” in Proceedings of the 3rd ACM
BIBLIOGRAFIE
125
SIGCHI symposium on Engineering interactive computing systems, ser. EICS ’11. New York, NY, USA: ACM, 2011, pp. 31–40. [Online]. Available: http://doi.acm.org/10.1145/1996461.1996491 [47] J. Vanderdonckt, “A mda-compliant environment for developing user interfaces of information systems,” in Proc. of 17 th Conf. on Advanced Information Systems Engineering CAiSE’05. Springer-Verlag, 2005, pp. 13–17.
Auteursrechtelijke overeenkomst Ik/wij verlenen het wereldwijde auteursrecht voor de ingediende eindverhandeling: Tool support for abstract user interfaces Richting: master in de informatica-Human-Computer-Interaction Jaar: 2012 in alle mogelijke mediaformaten, Universiteit Hasselt.
-
bestaande
en
in
de
toekomst
te
ontwikkelen
-
,
aan
de
Niet tegenstaand deze toekenning van het auteursrecht aan de Universiteit Hasselt behoud ik als auteur het recht om de eindverhandeling, - in zijn geheel of gedeeltelijk -, vrij te reproduceren, (her)publiceren of distribueren zonder de toelating te moeten verkrijgen van de Universiteit Hasselt. Ik bevestig dat de eindverhandeling mijn origineel werk is, en dat ik het recht heb om de rechten te verlenen die in deze overeenkomst worden beschreven. Ik verklaar tevens dat de eindverhandeling, naar mijn weten, het auteursrecht van anderen niet overtreedt. Ik verklaar tevens dat ik voor het materiaal in de eindverhandeling dat beschermd wordt door het auteursrecht, de nodige toelatingen heb verkregen zodat ik deze ook aan de Universiteit Hasselt kan overdragen en dat dit duidelijk in de tekst en inhoud van de eindverhandeling werd genotificeerd. Universiteit Hasselt zal wijzigingen aanbrengen overeenkomst.
Voor akkoord,
Bottelbergs, Yves Datum: 3/02/2012
mij als auteur(s) van de aan de eindverhandeling,
eindverhandeling identificeren en zal uitgezonderd deze toegelaten door
geen deze
