Home

generierung von korrekten und minimalen oberflächenmodellen aus

1. S 2 S 2 Compatible T 1 Incompatible Incompatible T 1 Incompatible Incompatible S 1 S 2 S 1 S 2 Abbildung 4 4 2 Initiale Resolution der merger table Abbildung 4 4 3 Endg ltige Resolution der merger table 41 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Ein kompatibles Zustandstripel ist offensichtlich unm glich die Resolution terminiert mit den beiden maximal kompatiblen Zustandsmengen S 1 S 2 und T 1 Die minimale berdeckung besteht aus genau diesen beiden Mengen die von hier an S und T genannt werden In Abbildung 4 4 4 ist das resultierende Oberfl chenmodell dargestellt Abbildung 4 4 4 Das vom Reduktionsalgorithmus berechnete Oberflachenmodell des Systems aus Abbildung 4 4 1 Ein Blick auf das unterliegende System zeigt nun dass vom Startzustand S 1 keine ausgehende Transition nach T 1 f hrt Aber der zu S 1 geh rende Zustand des Interfaces ist S in dem laut Oberfl chenmodell angeblich ein automatisches Ereignis t einen Wechsel nach T ausl sen kann Das hei t S verk rpert einen angmenting state dem Benutzer wird f lschlicherweise mitgeteilt dass T auftreten kann Solches Verhalten widerspricht direkt den von Heymann und Degani entwickelten Korrektheitskriterien das Oberfl chenmodell aus Abbildung 4 4 4 ist inkorrekt Die Annahme muss also falsch gewesen sein woraus Satz 4 4 1 folgt u Das Problem l sst sich beheben indem eine zus tzliche Bedingung
2. Das Programm erm glicht das Laden und Speichern von Modellen in einem eigenen Dateiformat mod Die Daten von Maschinen und Oberfl chenmodell werden dabei so letzteres vorhanden ist in der gleichen Datei aufgef hrt Weiter lassen sich die Modelle einzeln als Bild des Typs PNG exportieren Diese und andere Dateifunktionen finden sich unter dem Men punkt File F r die Bearbeitung des Maschinenmodells stehen zehn Werkzeuge zur Verf gung die sich sowohl ber das Men Edit als auch ber den Tool Bar alle Schaltfl chen au er der ganz rechts anw hlen lassen Sie reichen von der Erzeugung von Zust nden benutzergesteuerten und automatischen Transitionen ber das Festlegen des Startzustands und das L schen von Objekten bis hin zur Erstellung von Spezifikationsklassen und dem nachtr glichen Anpassen oder L schen selbiger Ein Klick auf einen der Buttons w hlt das entsprechende Werkzeug aus unten rechts werden dazu kontextsensitive Informationen angezeigt Weitere Erl uterungen zur Verwendung dieser Funktionen folgen im n chsten Abschnitt Die Darstellung der Modelle kann ber den Men punkt View individualisiert werden So l sst sich die Gr e der Labels von Zust nden Transitionen und Klassen genauso wie die der Arbeitsfl chen der Modelle ber einen Dialog Abbildung 5 2 2 ndern Auch kann die Anzeige der Modelle unter View einzeln skaliert werden In Abbildung 5 2 1 ist das Maschinenmodell beispielsweise verkleiner
3. Oberfl chenmodells existiert welcher alle aus J resultierenden Folgezust nde T T enth lt m repr sentierenden Zustand user genau dann vernachl ssigt wenn kein Zustand T user 45 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Es ist klar dass eine Transition zwischen S und allen wie T beschaffenen Zust nden sinnvoll user user ist sofern solche Zust nde Teil der minimalen Uberdeckung sind Ansonsten muss aber Abhilfe geleistet werden um dem Verschwinden von entgegenzuwirken Der L sungsansatz der hier verfolgt werden soll und per Option im Software Tool aktivierbar ist besteht darin im Falle des Fehlens eines Zustands T user mit J gelabelte Transitionen von Spe aus zu allen Zust nden zu erstellen die mindestens einen Zustand T T T beinhalten Abbildung 4 4 9 verdeutlicht was f r das System aus Abbildung 4 4 7 beim Erzeugen der Transitionen mit 03 passiert 177a 031 Abbildung 4 4 9 Reduziertes Maschinenmodell des Systems aus Abbildung 4 4 7 nach Erstellung aller Transitionen Durch diese Ma nahme entsteht selbstverst ndlich Nicht Determinismus der im n chsten Schritt eigentlich gleich wieder beseitigt werden w rde Da dies dem Ziel m gliche Wechsel von Zust nden sichtbar zu machen gerade entgegensteht wird ein anderer Weg gew hlt Jede vorerst mit P bezeichnete Transition bekommt einen eindeutigen Namen die zugeh rigen Erei
4. se ES S S Om user model State1 39 Create new state Name for the state to create Stated State3 Abbrechen E Ok State2 eS 1 4 oo Ses Abbildung 5 3 2 Drei Zust nde existieren bereits ein vierter wird gerade erstellt machine model Als n chstes sollen die Zust nde durch Transitionen miteinander verbunden werden Die beiden Schaltfl chen rechts neben der f r neue Zust nde vgl Abbildung 5 3 2 dienen genau dazu Vorher seien die Zust nde aber noch in eine bersichtlichere Anordnung gebracht Dazu wird das Standardwerkzeug ausgew hlt Schaltfl che ganz links die Zust nde lassen sich damit per drag n drop bewegen Nun werden einige benutzergesteuerte Transitionen erzeugt Dies geschieht indem erst der Zustand von dem die Transition ausgeht und anschlie end der zugeh rige 59 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen Zielzustand angeklickt wird Die Vergabe eines Namens erfolgt aquivalent zu der bei Zust nden Abbildung 5 2 4 zeigt den Moment wo der Benutzer den ersten Zustand State4 der letzten zu erstellenden Transition die wie schon eine andere t3 hei en soll angeklickt hat und sich mit der Maus ber dem zweiten State3 befindet Zur Unterst tzung des Ged chtnisses werden in einem solchen Vorgang bereits zugewiesene Zust nde gr n eingef rbt Der Verlauf der Linien der Transitionen wird automatisch festgelegt Hierbei findet
5. Abbildung 2 1 1 seven stages of action NACH NORMAN 1989 47 THE WORLD Im Folgenden sei daher beschrieben welche Arten von Fehlern existieren die ein Mensch bei der Bedienung eines Systems produziert Abgesehen wird dabei von der Beschaftigung mit der Formulierung von Handlungszielen da dieser Bereich eng an die konkrete Aufgabenanforderung gebunden ist und somit nicht in einer generellen Analyse enthalten sein kann Da ein falsches Ziel aber auf eine Fehlinterpretation der zuvor aufgenommenen Information hindeutet h ngt dieses Stadium unterschwellig nat rlich von der Evaluation des aktuellen Zustands ab W hrend eben dieses perzeptuellen und kognitiven Prozesses k nnen Verst ndnis Ged chtnis und Aufmerksamkeitsfehler auftreten Ist dem Benutzer nicht bewusst in welchem Zustand sich das Ger t oder Programm befindet oder was die zuletzt ausgef hrte Aktion f r Auswirkungen 5 Kapitel 2 Grundlegende Probleme und Ziele des User Interface Designs hatte so wird er sicherlich nicht in der Lage sehen das richtige Ziel zu formulieren Wenn also nicht sichtbar gemacht wird welche Daten aktuell g ltig sind und der Benutzer nicht ausreichend Feedback auf Eingaben erh lt wie soll er zu den richtigen Schl ssen gelangen Wie soll er verstehen was das System tut Andersherum kann die angezeigte Menge an Informationen jedoch auch unverh ltnism ig hoch sein f hrt damit zu einer zus tzlichen Belastung des Ged chtniss
6. Beweis von Satz 4 4 3 Zu beweisen sind die folgenden Aussagen 1 Die Anzahl an Zust nden ist minimal und 2 die Anzahl an Vorkommen von Ereignissen ist minimal Bei der zweiten Aussage wird auf die Beachtung aller se f oop Transitionen verzichtet da es vom konkreten Fall abh ngig ist ob sich deren Abbildung im Oberfl chenmodell als notwendig erweist Aus demselben Grund wird nicht dazwischen unterschieden ob eine Transition mit einem oder mehreren Ereignissen beschriftet ist Daher reicht es zu zeigen dass die Anzahl aller zwischen Zust nden bestehenden Transitionen minimal ist Beweis von 1 ber Widerspruch Sei amp die Anzahl der Zust nde des Oberfl chenmodells die der Reduktionsalgorithmus berechnet hat Angenommen es gibt ein Oberfl chenmodell mit h chstens amp 7 Zust nden das korrekt ist Dann gilt zumindest eine der folgenden Aussagen a Die vom Algorithmus ermittelte berdeckung der maximal kompatiblen Zustandsmengen ist nicht minimal b Mindestens zwei Zust nde des Maschinenmodells h tten entgegen der Berechnung des Algorithmus zusammengefasst werden k nnen Der Algorithmus vergleicht alle m glichen berdeckungen also kann Aussage a nicht wahr sein Wenn die Annahme stimmt hat der Algorithmus somit f lschlicherweise ausgeschlossen dass zwei Zust nde und nicht unterschieden werden m ssen Da aus den Korrektheitskriterien unmittelbar zu entnehmen ist dass kompatible Zust nde der gleichen Spezifika
7. DEGANI 2004 S 252 Ein restricting state liegt exemplarisch vor wenn vom ihm aus die Aktivierung des Ruhezustands eines Computers mit dessen Absturz einhergeht ohne dass auf dieses Problem hingewiesen wird Interfaces die solcherlei Situationen hervorrufen verwirren bzw erstaunen einen Benutzer da er mit dem Resultat nicht rechnen kann VGL HEYMANN amp DEGANI 2006 S 9 Augmenting states hingegen lassen den Benutzer an den eigenen F higkeiten respektive den Funktionalit ten des Systems zweifeln denn es herrscht Unverst ndnis gegen ber dem Ausbleiben des gew nschten Resultats etwa wenn das vermeintliche Ausl sen einer halbautomatischen Kamera aufgrund zu geringen Lichteinfalls ohne jegliche Erkl rung wirkungslos bleibt Zusammen bilden die beiden letztgenannten die Menge an Zust nden die falsche Aussagen ber Nachfolgezust nde machen Das Nichtvorhandensein von error states restricting states und augmenting states bedeutet umgekehrt dass dem Benutzer der aktuelle Zustand und die Konsequenzen m glicher Handlungen ersichtlich sind Einzig nicht durch die Korrektheitskriterien abgedeckt ist der Fall dass ein internes Ereignis einen Wechsel des Zustands des User Interfaces ausl st der dem Benutzer nicht als m glich angezeigt wird Kapitel 4 wird sich noch damit besch ftigen inwiefern diese Tatsache Einfluss auf die korrekte Bedienbarkeit nehmen kann Die Einhaltung der Kriterien ist unweigerlich mit dem Ziel verkn pft
8. Die Benutzung des Editors wird im Folgenden anhand eines simplen Beispiels gezeigt das die Erstellung von Zust nden Transitionen und Spezifikationsklassen sowie die Generierung des Oberfl chenmodells und das Speichern beider Modelle erkl rt Der Anschaulichkeit halber werden als bevorzugte Steuerungselemente hier die Schaltfl chen im Tool Bar verwendet Beim Start der Software kann der Benutzer prinzipiell nur zwei m gliche Vorgehensweisen verfolgen entweder l dt er ein bestehendes Modell oder er erstellt den ersten Zustand eines neuen Maschinenmodells Alle anderen Funktionen abgesehen von Optionen machen ohne vorhandenes Modell keinen Sinn und so blendet die Oberfl che sie aus vgl Abbildung 5 3 1 Autom File Edit View Generate Language x O N machine model Abbildung 5 3 1 Zu Beginn ist das einzig verf gbare Werkzeug Neuen Zustand erstellen Ein Klick auf die Arbeitsfl che des Maschinenmodells ffnet nun ein Fenster in dem ein Name f r den zu erstellenden Zustand einzugeben ist Nacheinander seien hier nun die Zust nde State1 State2 State3 und State4 erzeugt Abbildung 5 2 3 stellt die Situation dar in der schon drei der vier Zust nde existieren und ein weiterer gerade hinzugef gt wird Es zeigt sich dass bereits hier weitere Werkzeuge anw hlbar sind Au erdem ist erkennbar dass der erste Zustand automatisch als vorl ufiger Startzustand festgesetzt wurde Puc LUIL VIEW MUCTIAIE Lamnyuaye x ORIEN
9. Dies wird mittels Induktion ber die L nge aller m glichen Ereignissequenzen bewiesen Sei n 7 Der Algorithmus deklariert Zust nde als inkompatibel wenn ein gemeinsames Ereignis in Zust nde verschiedener Spezifikationsklassen f hrt Schalten einer einzigen Transition kann in kompatiblen Zust nden daher nicht in einem error state m nden Es folgt die Induktionsvoraussetzung F r ein beliebiges aber festes ist die Existenz von error states ausgeschlossen Seien also weiter S und T zwei kompatible Zust nde des Maschinenmodells und 8 eine von und T aus definierte Ereignissequenz der L nge T Zu zeigen ist dass P niemals in Zust nden verschiedener Spezifikationsklassen resultiert Die Sequenz schalte in ein Folgezustandspaar T Nach Induktionsvoraussetzung ist der und T repr sentierende Zustand des Oberfl chenmodells kein error state Zu dem Zeitpunkt an dem der Reduktionsalgorithmus die Ereignisfolge f 8 durch Ersetzen der Zustandspaare in der merger table simuliert hat wurde dies f r S und T zumindest auch f r bereits getan Da nun und T kompatibel sind m ssen auch S und T vom Algorithmus als kompatibel berechnet worden sein Das hei t insbesondere dass f von und T aus nicht in Zust nde verschiedener Spezifikationsklassen f hrt Es folgt dass f r keine definierte Ereignissequenz der L nge 7 ein error state erreicht wird Beweis von 2 und 4
10. Ein Unterschied ist jedoch dass das f r den Fu g nger als benutzergesteuert geltende Ereignis Press im Maschinenmodell der Fahrzeug Ampel zu den automatischen Ereignissen z hlt denn ein Autofahrer kann dieses nicht beeinflussen Dar ber hinaus muss zur Konstruktion des User Interfaces f r Pkws vor allem eine andere Zusammensetzung der Klassen gew hlt werden wie sie in Abbildung 3 2 3 zu Pressi _ i C 1 C 2 Walk Gg To Drive C DON T DRIVE 7 Press i sehen ist Abbildung 3 2 3 Maschinenmodell der Fu g ngerampel samt Spezifikationsklassen aus Sicht des Autofabrers Es handelt sich zwar hierbei um eine Maschine die der Benutzer rein beobachtend wahrnimmt doch liegen nat rlich auch solche Systeme im Blickpunkt dieses Kontexts Offensichtlich k nnen die vier Klassen den Farben einer Ampel zugeordnet werden DON T DRIVE zu rot DRIVE zu gr n STOP zu gelb sowie PREPARE zu rot gelb Das resultierende Interface l sst sich folglich leicht erahnen und sei an dieser Stelle vernachl ssigt Wichtiger ist die Schlussfolgerung dass die Zust nde die einem Benutzer anzuzeigen sind damit dieser das zugeh rige System korrekt bedienen im letzten Beispiel lediglich beobachten kann von der Aufgabe f r die das System entwickelt wurde in hohem Ma e abh ngig ist Die Frage welche Zust nde spezifikations quivalent sind ist sicherlich bei umfangreichen Modellen nicht immer leicht zu beantworten Anhand der Fu g ngeramp
11. Formalisierung der Aufgabenspezifikation in einer sehr konkreten Form ben tigt die Einteilung in Spezifikationsklassen impliziert dass die Entwickler grunds tzlich entscheiden k nnen m ssen welche internen Zust nde ein und denselben Modus repr sentieren 50 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Dennoch ist ein nicht unwesentlicher Fortschritt ersichtlich Bezogen auf die anzuzeigende Information stellt die Partition der Zustande den letzten Eingriff des Menschen wahrend des Prozesses des Designs eines Interfaces dar was nach dem eben angestellten Beweis der Korrektheit als offensichtlicher Vorteil zu deklarieren ist Au erdem wird die vorbereitende Modellierung von Abl ufen eines Systems heutzutage mehr und mehr zum Standard Dass diese genau in der hier vorgestellten Weise durchgef hrt wird ist hinzukommend nicht verpflichtend As such the approach methodology and algorithm proposed here can be extended to other discrete event formalisms such as Petri nets and Statecharts as well as to hybrid systems models that have both continuous and discrete behaviors HEYMANN amp DEGANI 2006 S 25 Unabh ngig von den in Kapitel 4 4 besprochenen und nicht v llig behobenen Schwachstellen im Verfahren ist ein Hauptproblem des Reduktionsalgorithmus seine Laufzeit im schlechtesten Fall Angenommen etwa ein Maschinenmodell beinhalte Zust nde welche alle einer einzigen Spezifikationsklasse ang
12. Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Hot B Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible laee Hot C Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Warm AWarm B Hot A Hot B Cool A Cool B Cool C Warm A Warm B Warm C Hot A Hot B Abbildung 4 3 1 Initiale Resolution der merger table des Heiz und Kiiblsystems 32 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Dabei sind Zellen deren zugeh rige Zust nde noch nicht als inkompatibel identifiziert wurden grau hinterlegt Folgezustandspaare sind au erdem zur Abgrenzung gegen ber kompatiblen Zust nden in einer anderen Schriftart dargestellt Beginnend bei der obersten Zelle in Abbildung 4 3 1 die die Zust nde Cool A und Cool B repr sentiert finden sich zwei Folgezustandspaare mit Blick auf das Maschinenmodell zeigt sich dass die Transition heat up zu Warm B bzw Warm C f hrt Daher wird WarmB Warm in die Zelle geschrieben Das automatische Ereignis cool schaltet hingegen nach Cool B bzw Cool C Bei der Zelle darunter also der von Cool A und Cool C f llt auf dass kein gemeinsames internes Ereignis existiert ein manuelles Ausl sen von heat up bewirkt aber einen Wechsel zu Warm B Hot El So wird der Inhalt der Tabelle Zelle f r Zelle ermittelt Bereits hier kann die Kompatibilit t eines gro en Anteils aller Zust nde
13. Incompatible Warm B Warm C Warm B Warm C Cool B Cool C Cool B Cool Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Hot A Hot B Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Warm A Warm B Hot B Hot Cool A Cool B Cool C Warm A Warm B Warm C Hot A Hot B Abbildung 4 3 2 Erste Iteration des Resolutionsprozesses der merger table Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Hot A Hot B Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Tepe ker Cool A Cool B Cool C Warm A Warm B Warm C Hot A Hot B Abbildung 4 3 3 Zweite Iteration des Resolutionsprozesses der merger table In der nachsten Iteration werden drei weitere inkompatible Zustandsmengen entdeckt siehe Abbildung 4 3 3 So erweisen sich beispielsweise Warm A und Warm B beide inkompatibel mit Warm C denn in den zugeh rigen Zellen taucht jeweils Cool B Gool 6 auf das sich ja zuvor schon 34 Kapitel 4 Generierung von korrekten und minimal
14. m lt minClassCover THEN minClassCover FOR j 1 TO m DO userStates create_user_ state m j RETURN userStates m Determine the transitions of the user model by the transitions of the machine model PROCEDURE determine transitions userStates machineStates machineTransitions VAR userTransitions create_all_transitions userStates machineTransitions delete_nondeterministic_innerclass_transitions userStates userTransitions delete _automatic_self_loops userTransitions group_events_that_always_appear together userTransitions Der Reduktionsalgorithmus besteht also wie die Hauptmethode reduction_algorithm zeigt aus drei Schritten Als erstes werden alle maximal kompatiblen Zustandsmengen berechnet compute maximal_compatibles anhand derer dann eine minimale Uberdeckung des Maschinenmodells gefunden wird compute_minimal_cover Das Resultat dieser beiden Abschnitte sind die Zust nde des Oberfl chenmodells Anschlie end werden die Transitionen des Modells ermittelt determine_transitions die sich aus der Zusammenfassung der Zust nde des Systems und den berg ngen zwischen diesen ergeben Die Berechnung der maximal kompatiblen Zustandsmengen beginnt mit der Erzeugung der trivial kompatiblen 1 elementigen Mengen Eine effiziente iterative Methode die dem Finden aller kompatiblen Zustandspaare dient basiert auf der Benutzung so genannter merger tables VGL HEYMANN amp DEGANI 2006 S 13 Eine merg
15. sst Das Vorgehen wird an einem gegen ber der Ampel etwas komplexeren Beispiel illustriert werden das insbesondere sp ter bei der automatischen Generierung mehr Erkenntnisse 14 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces liefern wird aber auch schon hier die Notwendigkeit einer Verifikationsmethode verdeutlicht Um diese Methode anwenden zu k nnen muss jedoch eine M glichkeit bestehen die Spezifikation der Aufgaben die an ein System in Bezug auf die Beobachtbarkeit gestellt werden zu formalisieren Ein Konzept das diesem Anspruch gerecht zu werden versucht wird deshalb zun chst noch anhand des Beispiels der Fu g ngerampel eingef hrt 3 2 SPEZIFIKATIONSKLASSEN ALS FORMALISIERUNG DER AUFGABENANFORDERUNG Michael Heymann und Asaf Degani widmen sich in den genannten Papern der Rolle der Aufgaben des Benutzers nur bedingt VGL HEYMANN amp DEGANI 2006 S 6F SOWIE HEYMANN amp DEGANI 2002 I S 7 aber es sei schon zu Beginn erw hnt dass der von ihnen verfolgte Ansatz eine Einschr nkung der beiden Verfahren darstellt Im Zuge der Beobachtbarkeit eines automatisierten Systems hat ein Benutzer das ndern von Modi zu verfolgen ebenso wie er selbst Eingabesequenzen t tigen und die Konsistenz zwischen dem Weg zum gew nschten Ziel und der aktuellen Situation berwachen muss Ein Modus ist dabei nicht zwangsl ufig ein genauer Zustand des Systems sondern repr sentiert in der Regel viel h ufig
16. 4 Abbildung 5 2 3 Einstellungsm glichkeiten f r die Generierung von Oberfl chenmodellen Der Benutzer kann entscheiden ob alle se f oops automatischer Ereignisse gel scht werden sollen oder nur diejenigen welche wirklich berfl ssig sind weil das zugeh rige Ereignis ausschlie lich in Form solcher se oop Transitionen vorkommt Weiter sind im Programm zwei verschiedene M glichkeiten umgesetzt die Zust nde des Oberfl chenmodells automatisch anzuordnen die Anordnung l sst sich hinterher noch manuell ver ndern entweder es wird einzig die Verteilung der zusammengefassten Zust nde innerhalb einer Klasse als Kriterium zugrunde gelegt oder die Zustandsanordnung wird zus tzlich noch gerastert Es sei angemerkt dass beide Alternativen lediglich Heuristiken darstellen die von der Annahme ausgehen dass der Benutzer die Zust nde des Maschinenmodells sinnvol ausgerichtet hat Es h ngt vom Einzelfall ab welche Methode das bessere Ergebnis liefert Als drittes findet sich noch die Auswahl ob der originale Reduktionsalgorithmus von Heymann und Degani angewendet werden soll der wie in Kapitel 4 4 gezeigt wurde nicht zwangsweise fehlerfrei ist oder ob anstatt dessen die ge nderte Version auszuf hren ist in der restricting states und concealing states vermieden werden Zuletzt ist noch zu sagen dass das Software Tool diverse Fehler verhindert und mittels Dialogen R ckmeldung dar ber gibt So ist es exemplarisch nicht m glich
17. 4 2 berblick ber den Reduktionsalgorithmus sssscsssssssssssssesscessseesseessseccessnssecessssnsseesnunsecesssnnsesessnnseseesnneeseesnnnesess 28 43 Konkrete Anwendung des Algorithmus zur Generierung von Oberfl chenmodellen uueee 31 4 4 Fehlerbehebung und daf r n tige nderungen am Reduktionsalgorithmus een 40 4 5 Korrektheit des Reduktionsalgorithmus 4 6 Grenzen der Anwendbarkeitdes Verfahrens susasnesesesensenseeeninauikn ea laire 50 5 ENTWICKLUNG EINER SOFTWARE ZUR ERZEUGUNG VON OBERFLACHENMODELLEN 53 5 1 Technischer Hintergrund Architektur und interne Abl ufe der Software 5 2 berblick ber die Funktionen des graphischen Editors eesscssssssssssssessesssssessessnnesseessnsescessnsssessnnneseesnnessensnnesess 5 3 Exemplarische Anwendung der Software aesnsensnsnenensensensensensenennennennensensonsonsnnennennensensensonsnnenennennensennensonans 6 ZUSAMMENFASSUNG UND AUSBLICK cuersossnssennssennssensnssensusssssunssssunsssssnssessnsssssnsssssnnsensen 64 ANHANG leeres 66 Eidesstattliche Erkl rung u 2 22 66 Auf der beigef gten CD enthalten u 66 LITER TURVERZEICHNISS ccscvcesscccsceccccevcecectesceSccwaucelcdecuccddcecudebsducvcebeuucscebccdedcebedevecedscess 67 Kapitel 1 Einleitung 1 EINLEITUNG Knowing what to abstract and how to abstract it is the foundation of any user interface design DEGANI 2004 S 31 1 1 MOTIVATION EINF HRUNG IN DAS THEMA Kaum ein Bereich de
18. Arbeit verwendeten Beispielmodelle zur Verf gung gestellt benannt mit Teilkapitelnummer und inhaltlicher Thematik so etwa 4_4_augmenting_state Ebenso befinden sich dort die drei Beispiele aus HEYMANN amp DEGANI 2002 I und HEYMANN amp DEGANI 2006 Der Ordner javadoc beinhaltet die aus dem Quellcode generierten Javadoc HTML Dateien mit der Startseite index html In references finden sich Kopien aller verwendeten Quellen die im Internet zum Download bereit stehen Der Ordner source enth lt schlie lich den Java Quellcode des Programms der entsprechend der Packages in Unterverzeichnisse aufgeteilt ist 66 Literaturverzeichnis LITERATURVERZEICHNIS DEGANI ASAF 2004 Taming HAL Designing Interfaces Beyond 2001 Palgrave Macmillan New York DEGANI ASAF amp HEYMANN MICHAEL 2002 Formal Verification of Human Automation Interaction Human Factors 44 1 S 28 43 http ti arc nasa gov people asaf hai pdf Formal 20Verification 200f 20Human Automatio n 20Olnteraction pdf 09 10 2006 HAREL DAVID 1987 Statecharts A Visual Formalism for Complex Systems Science of Computer Programming 8 S 231 274 HEYMANN MICHAEL amp DEGANI ASAF 2002 I On Abstractions and Simplifications in the Design of Human Automation Interfaces NASA Technical Memorandum 211397 Moffett Field CA NASA Ames Research Center http ti arc nasa gov people asaf interface_design pdf NASA 20Report 20 200n 20Ab stractions
19. B und Hot C zum Beispiel enth lt das Paar Met A Hot Bl Die Originalzelle dieser Zust nde enth lt wiederum Warm A Warm Bl sowie MotB Hot so dass Hot A Hot Bl mit diesen berschrieben wird Dieses Vorgehen liefert die Tabellenbelegung aus Abbildung 4 3 2 auf der folgenden Seite und entspricht dem folgenden Pseudocode die Bedeutung der Variable cellChanged wird weiter unten aufgegriffen Resolve the merger table as long as cells are changing PROCEDURE resolve_merger_ table iteratively mergerTable VAR cellChanged TRUE WHILE cellChanged TRUE cellChanged FALSE FOR i 1 TO states DO FOR j 0 TO i 1 DO IF mergerTable i j Incompatible THEN VAR oldCell mergerTable i j substitute _cell mergerTable i j IF oldCell mergerTable i j THEN cellChanged TRUE VAR newCompatibles create_new_compatibles mergerTable RETURN newCompatibles 33 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Cool B Cool C Warm A Warm B Warm C Hot A Hot B Hot C Cool B Cool C Warm A Warm B Warm C Hot A Hot B Hot C Hot A Hot C Cool A Cool B Warm G Hot Cool A Cool B Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Warm A Warm B Warm A Warm B Incompatible Incompatible
20. Entwicklung einer Software zur Erzeugung von Oberflachenmodellen 5 2 BERBLICK UBER DIE FUNKTIONEN DES GRAPHISCHEN EDITORS Abbildung 5 2 1 zeigt die gesamte Bedienungsoberfl che der erstellten Software unter Mac OS X Das Aussehen der Oberfl che kann je nach Betriebsystem variieren Bereits zu Beginn sei darauf hingewiesen dass hier die englische Version beschrieben wird Das System wird standardm ig mit der eingestellten Sprache des Betriebssystems gestartet ber den Men punkt Language kann aber zu jeder Zeit zwischen Deutsch und Englisch umgeschaltet werden Andere Sprachen sind nicht eingebunden lie en sich aber ohne Schwierigkeiten in die Software integrieren 16 F 7 Automatic Interface Modeling Tool 1 0 heatandcool mod File Edit View Generate Language Ol 7 gt EeN x iel OM machine model user model c00l c00l heat up cool down cool down hot hot heat up cool down selected object standard tool x 50 name Cool A Click on a state or transition to select it Move a state or a line segment of a transition by drag n drop Lal Y 50 class COOL change Abbildung 5 2 1 Die gesamte Oberfl che des Software Tools auf Englisch unter Mac OS X Die Oberfl che besteht nun grunds tzlich aus sechs Bereichen Oben finden sich Men und Tool Bar des Programms die darin enthaltenen Funktionalit ten werden noch bes
21. Ereignisse oT 02 03 04 und 05 k nnen zu Beginn automatisch innerhalb der Spezifikationsklasse S berg nge triggern Ein Auftreten von a p y oder 6 schaltet dann in 38 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen einen der eindeutig zu unterscheidenden Zustande P Q und R in denen der Benutzer Aktionen ausfuhren kann Dieses System sei nun die Eingabe des Reduktionsalgorithmus Im ersten Schritt werden die maximal kompatiblen Zustandsmengen S A S B S C S C S D S E und S A S C S E sowie P Q und R berechnet Offensichtlich finden sich hier anders als beim Heiz und K hlsystem berschneidungen zwischen den kompatiblen Mengen der Klasse S Es zeigt sich dass S A S C S E f r die minimale berdeckung berfl ssig ist alle anderen werden hingegen ben tigt In Abbildung 4 3 8 ist die minimale berdeckung des Maschinenmodells dargestellt Bereits hinzugef gt wurden die vorerst erzeugten Transitionen Da der Startzustand des Systems S C sowohl in S A S B S C als auch S C S D S E enthalten ist kann aus diesen beiden der entsprechende Startzustand des User Interfaces frei gew hlt werden und so findet sich die zugeh rige Markierung in der Abbildung bei S C S D S E 03 02 01 05 03 04 04 05 03 Abbildung 4 3 8 Reduziertes Maschinenmodell des abstrakten Systems nach Erstellung aller Transitionen Bei Betrachtung der berg nge der oberen Zust nde des Interfaces d
22. Fehler im Verfahren zur Generierung von User Interfaces entdeckt wurde Unter der gegebenen Definition von Spezifikationsklassen vgl Definition 3 2 1 vermeidet das berechnete Oberfl chenmodell nicht in allen F llen das Auftreten von augmenting states Ein Gegenbeispiel wird diese Behauptung nun zuerst belegen Anschlie end wird eine m gliche Behebung des Problems durch Einf hren einer zus tzlichen Bedingung vorgestellt die das Verfahren jedoch einschr nkt Desweiteren lassen sich F lle konstruieren in denen der Reduktionsalgorithmus von Heymann und Degani Oberfl chenmodelle erzeugt die restricting states enthalten Auch f r dieses Problem wird ein Ausweg aufgezeigt werden der eine nderung des Festsetzens der im Oberfl chenmodell anzuzeigenden Transitionen vornimmt Dieser Ausweg legt gleichzeitig eine Erweiterung der Korrektheitskriterien um die Vermeidung noch zu definierender concealing states nahe wird leider aber auch in gewisser Hinsicht Probleme offen lassen 40 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Satz 4 4 1 Unter der Definition von Spezifikationsklassen Definition 3 2 1 gew hrleistet der Reduktionsalgorithmus nicht die Vermeidung von augmenting states Beweis von Satz 4 4 1 ber Widerspruch Angenommen der Algorithmus vermeidet augmenting states Dann muss er deren Existenz in allen berechneten Oberfl chenmodellen generell ausschlie en Es werde nun folgendes Beispiel betra
23. NORMAN 1989 von den seven stages of action VGL NORMAN 1989 S 45F Um eine Aktion auszuf hren formt der Mensch zuallererst ein Ziel 1 Als Konsequenz entwickelt er die Absicht zu handeln 2 spezifiziert f r sich die Aktion 3 und f hrt sie aus 4 Anschlie end nimmt er den resultierenden Zustand des Handlungskontextes wahr 5 interpretiert ihn 6 und evaluiert das Ergebnis 7 Diese stetig auftretende Handlungsfolge entspringt dem wie folgt definierten Aktionszyklus Definition 2 1 1 Der Aktionszyklus The Action Cycle VGL NORMAN 19839 S 47 Der Aktionszyklus menschlichen Handelns besteht aus zwei Aspekten der Ausf hrung und der Evaluation Ausf hrung meint das aktive Umsetzen einer Handlung Evaluation bezeichnet den Vergleich zwischen dem Ziel das durch eine Handlung ausgel st werden soll und dem Resultat der Handlung Norman weist darauf hin dass dieses zyklische Vorgehen dargestellt in Abbildung 2 1 1 keine vollst ndige psychologische Theorie widerspiegelt sondern dass es eher als angen hertes Modell anzusehen ist Es wird dennoch daf r hilfreich sein die grundlegenden Ziele des User Interface Designs in Hinsicht auf die vermittelte Information herauszuarbeiten L Goals 2 pri a Intention to act Evaluation of interpretations Sequence of actions Interpreting the perception 2 Execution of the g Perceiving the 3 action sequence g state of the world v
24. Schritt entweder alle automatischen se oops oder nur diejenigen deren zugeh riges Ereignis ausschlie lich als self loop vorkommt Die Benutzeroberfl che der Software hat daf r eine Einstellungsm glichkeit it is up to the design team to decide based on operational and situation awareness consideration whether they want to provide information about these internal gear shifts HEYMANN amp DEGANI 2006 S 19 Hat auch diese Reduktion stattgefunden so k nnen zuletzt noch Ereignisse zusammengefasst werden die stets zusammen an Transitionen erscheinen In diesem Fall n mlich erweist sich eine Unterscheidung zweier solcher Ereignisse f r den Benutzer als irrelevant Aus den berechneten Transitionen und den zuvor konstruierten Zust nden l sst sich im Anschluss das User Interface ableiten Hierf r muss noch entschieden werden welche Informationen direkt darzustellen sind und welche einer Bedienungsanleitung oder anderen externen Quellen entnommen werden sollen Der Reduktionsalgorithmus terminiert also mit dem bisher als korrekt und minimal vermutetem Modell der Oberfl che Er wurde in diesem Abschnitt vollst ndig aber abstrakt beschrieben Zur Veranschaulichung finden sich daher im n chsten Teilkapitel zwei Beispiele die die wesentlichen Eigenschaften des Verfahrens illustrieren Zuerst geht es darum das korrekte und minimale User Interface des Heiz und K hlsystems zu ermitteln Danach werden ausstehende Aspekte des Redu
25. Vergleich mit dem Maschinenmodell in Abbildung 3 3 1 Triggern von cool down hat aus allen Zust nden in WARM einen der Zust nde Cool A und Cool B als Ergebnis und umgekehrt f hrt heat up von dort aus anders als bei Cool C immer in den Modus WARM Daher werden Cool A und Cool B durch COOL 1 Cool C hingegen durch COOL 2 repr sentiert Au erdem gew hrt dieses Oberfl chenmodell einen partiellen Einblick in die Menge automatischer 20 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces Ereignisse bildet namlich ab dass interne Wechsel zwischen COOL 1 und COOL 2 vorkommen k nnen Aber handelt es sich hierbei jetzt um ein korrektes User Interface Diese Frage ist allein durch genaues Hingucken schon hier schwer zu beantworten bei steigender Komplexit t der Systeme wird solch ein Vorgehen zweifelsohne nahezu unm glich Es bedarf einer Methode die die Korrektheit eines Oberfl chenmodells zu einem gegebenen Maschinenmodell und der formalen Aufgabenspezifikation anhand definierter Abl ufe verifiziert Solch eine Methode wird auf den folgenden Seiten auf formalem und graphischem Weg erarbeitet und durchgef hrt In any human machine system two concurrent processes are constantly at play the machine with its internal states and transitions on the one hand and the interface annunciations with the associated user model transitions on the other HEYMANN amp DEGANI 2006 S 10 Diese beiden Prozesse repr
26. Wie gerade gezeigt weisen die generierten Oberfl chenmodelle keine error states auf der aktuelle Zustand des unterliegenden Systems ist dem Benutzer also jederzeit bekannt Dar ber hinaus werden weder benutzergesteuerte noch automatische Transitionen vom ge nderten Reduktionsalgorithmus internalisiert sofern diese einen Zustandswechsel bedingen und keine nicht deterministische Situation hervorrufen Das Entfernen einer se oop Transition kann offensichtlich zu keinem concealing state f hren benutzergesteuerte se oops werden ohnehin nicht entfernt Sei also J eine nicht deterministische ausgehende Transition eines Zustands user des Oberfl chenmodells deren entsprechenden Transitionen im Maschinenmodell zu Zust nden 48 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Sy S f hre P wird vom ge nderten Reduktionsalgorithmus nur dann internalisiert wenn es eine andere ebenfalls mit J gelabelte ausgehende Transition von S gibt die zu einem Zustand des Oberfl chenmodells f hrt der mindestens auch die Zust nde S repr sentiert Daher ist die Existenz von restricting states und concealing states ausgeschlossen Beweis von 3 Die in Definition 4 4 1 eingef hrte Bedingung impliziert dass nur automatische Ereignisse T T Wechsel zwischen kompatiblen Zust nden S einer Spezifikationsklasse von m C ausl sen k nnen Nach Definition der Kompatibilit t kann kein Ereig
27. ausgeschlossen werden vgl Abbildung 4 3 1 so etwa bei Cool A und Warm B Dies l sst sich auf verschiedene Spezifikationsklassen zur ckf hren aber auch dem Vergleich der benutzergesteuerten Transitionen h tte keins der inkompatiblen Zustandspaare standgehalten Die zu Warm A und Warm B geh rige Zelle ist nun nicht leer weil die beiden Zust nde inkompatibel sind Es gibt lediglich kein Ereignis das von ihnen aus in ein anderes Zustandspaar f hrt Die gemeinsamen Transitionen heat up und cool down f hren n mlich jeweils in den gleichen Zustand k nnen somit f r keine fehlerhafte Situation verantwortlich sein Schon jetzt l sst sich konstatieren dass sich diese Zust nde als kompatibel herausstellen werden Nach Berechnung der initialen Resolution wird die Tabelle iterativ resolviert Eine Verwendung des Maschinenmodells ist von hier an nicht mehr notwendig der aktuelle Inhalt der merger table ist vollkommen ausreichend VGL HEYMANN amp DEGANI 2006 S 15 Als inkompatibel markierte Zellen werden nicht weiter ver ndert Jede andere Zelle ist wie folgt zu substituieren Falls sie einen Verweis auf eine als inkompatibel markierte Zelle beinhaltet wird sie ebenfalls als solche gekennzeichnet so etwa befindet sich in der Zelle von Cool B und Cool C das inkompatible Zustandspaar Warm 6 Hot Ansonsten wird jedes Zustandspaar durch alle Paare ersetzt die in der Originalzelle des Zustandspaars notiert sind Die Zelle von Hot
28. daraus hervorgeht dass dort schon in der Definition der Korrektheit die Vermeidung von augmenting states ausgelassen wurde vgl Kapitel 2 2 F r die Einhaltung dieses Korrektheitskriteriums erweist sich genau die zweite Bedingung n mlich als wichtig Wie Definition 4 1 1 erkennen l sst sind zwei Zust nde bei Erf llung der ersten beiden Bedingungen genau dann kompatibel wenn f r eine beliebige Eingabesequenz gilt dass entweder das resultierende Zustandspaar T ebenfalls kompatibel ist oder wenn und T denselben Zustand bezeichnen Daher wird die Berechnung der kompatiblen Zustandspaare komplement r angegangen Instead of trying to find all state pairs that are compatible it is computationally more convenient to first find all state pairs that are incompatible HEYMANN amp DEGANI 2006 S 13 Entsprechend ergibt sich f r Inkompatibilitat folgende formale Definition Definition 4 1 2 Inkompatible Zust nde Incompatible states VGL HEYMANN amp DEGANI 2006 S 13 Zwei Zust nde S und T eines Systems hei en genau dann inkompatibel wenn sie mindestens einer der folgenden drei Bedingungen gen gen 1 S und T geh ren nicht derselben Spezifikationsklasse an 2 S und T haben nicht die gleichen ausgehenden benutzergesteuerten Transitionen 3 Es existiert eine f r und T definierte Eingabesequenz die in inkompatible Folgezust nde S und T f hrt 26 Kapitel 4 Generierung von korrekten und minimalen Obe
29. der Korrektheit des Verfahrens gezeigt Dazu wird die in Kapitel 3 3 vorgestellte Methode auf das Oberfl chenmodell angewendet Die Herleitung des sich ergebenden zusammengesetzten Modells sei hier vernachl ssigt das Modell findet sich in Abbildung 4 3 6 Es weist keine error states restricting states und augmenting states auf und erf llt damit die Korrektheitskriterien aus Definition 2 2 1 37 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Cool A fefele i Warm A ln HOT cool down cool down I I cool coo hi cool down Warm B Aww S cool down cool cool cool down Warm C 712127 Cool C feelo x HOT Abbildung 4 3 6 Zusammengesetztes Modell des Heiz und Kiiblsystems Bei der Generierung des Oberfl chenmodells des Heiz und K hlsystems sind nicht alle Aspekte des Reduktionsalgorithmus zum Tragen gekommen Daher sei hier noch ein weiteres Beispiel kurz betrachtet das insbesondere mehr Aufschluss ber die berlappungen von kompatiblen Zustandsmengen und das Festsetzen von Transitionen geben wird Abbildung 4 3 7 zeigt das Maschinenmodell eines abstrakten Systems dessen inhaltliche Bedeutung hier nicht weiter von Interesse ist Der Benutzer soll auch dieses Mal zu jedem Zeitpunkt ber die aktuelle und folgende Spezifikationsklasse bescheid wissen Abbildung 4 3 7 Maschinenmodell eines abstrakten Systems inklusive Spezifikationsklassen Die
30. die n tig f r paarweise Kompatibilit t sind so stellt U eine neue kompatible Zustandsmenge dar Sie werden schrittweise in VAR set union intersection k erzeugt Es wird also jeweils die Differenz von U und einem Element aus I betrachtet denn gesucht sind genau alle die m glichen Teilmengen M von U f r die M U 7 gilt Im vorliegenden Fall ist das neben den Ausgangspaaren nur Hot A Hot C Da auch Hot A Hot C zu den kompatiblen Mengen der Gr e n T 2 geh rt contains comps set muss Hot A Hot B Hot C folglich ebenfalls eine kompatible Zustandsmenge der Gr e n 3 sein Hot A Hot B Hot A Hot C und Hot B Hot C sind somit im Umkehrschluss nicht maximal Eine kompatible Menge mit Kardinalit t 4 ist beim Heiz und K hlsystem ausgeschlossen da ohnehin keine Spezifikationsklasse mehr als drei Zust nde umfasst Der erste Schritt des Reduktionsalgorithmus liefert also die sechs maximal kompatiblen Zustandsmengen Cool A Cool B Cool C Warm A Warm B Warm C und Hot A Hot B Hot C 36 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Die Reduktion hat eine Menge an maximal kompatiblen Zustandsmengen berechnet in deren Elementen es keine Uberlappungen gibt Die minimale Uberdeckung des Maschinenmodells enth lt deshalb all diese Zustandsmengen Sie bilden die Basis f r die Erstellung der Zust nde des Oberfl chenmodells Zur Unterscheidung werden Cool A Cool B
31. ein Software Tool implementiert das den Reduktionsalgorithmus umsetzt Das Tool erm glicht die manuelle Erstellung von Maschinenmodellen sowie die Einteilung in Spezifikationsklassen komfortabel auf graphischer Ebene Die Generierung des zugeh rigen Oberfl chenmodells verl uft automatisch sowohl was die Berechnung als auch was die Anordnung der Zust nde betrifft Au erdem erlaubt das Programm die in bestimmten F llen auftretenden Fehler des originalen Algorithmus zu vermeiden Kapitel 5 Mehrere Erweiterungen des Software Tools sind denkbar So k nnte etwa das beschriebene Verifikationsverfahren noch eingebettet werden Die grundlegenden Voraussetzungen daf r sind bereits geschaffen denn nur geringe nderungen am Quellcode w rden das ebenfalls manuelle Erzeugen von Oberfl chenmodellen gestatten Darauf aufbauend k nnte ein eigenes Modul f r die Konstruktion des zusammengesetzten Modells implementiert werden Ferner k nnte eine Speicherung der Modelle im XML Format n tzlich sein um eine bessere Interoperabilitat mit anderen Modellierungswerkzeugen zu erreichen Auch hierf r bedarf es keiner wesentlichen Modifikationen des bestehenden Codes findet doch die Behandlung programmexterner Daten in einer einzigen Klasse statt Schlie lich l sst sich die Usability der bestehenden Implementierung zweifelsohne noch steigern Zwar war ein Ziel beim Entwurf der Software ein intuitiv und leicht bedienbares User Interface anzubieten und diese
32. ein sicher bedienbares User Interface zu konstruieren Doch sie allein macht ein Programm bzw eine Maschine nicht 9 Kapitel 2 Grundlegende Probleme und Ziele des User Interface Designs benutzbar Anderenfalls ware zum Beispiel auch ein Interface angemessen das die kompletten systeminternen Ablaufe anzeigt was meist sowohl technisch nicht realisierbar als auch vom Belastungsaspekt aus gesehen unvertretbar ist Das zweite Ziel das beim Interface Design und somit insbesondere in Kapitel 4 im Blickpunkt steht ist folglich die Menge angezeigter Informationen so gering wie m glich zu halten Definition 2 2 2 Korrektes und minimales User Interface correct and succinct user interface VGL HEYMANN amp DEGANI 2002 I S 16 Ein korrektes User Interface inklusive aller zugeh rigen Hilfsmaterialien ist minimal wenn die Anzeige keines Zustands und ebenso keiner weiteren Information entfernt werden kann ohne die Korrektheitseigenschaft zu verletzen Es sei bereits jetzt darauf hingewiesen dass es von der Beschaffenheit des Problems abh ngen kann ob etwa Ereignisse die nur intern von Bedeutung sind unter Umst nden auch f r den Benutzer sichtbar gemacht werden sollten Es wird sich au erdem zeigen dass im Regelfall nicht unbedingt nur eins sondern mehrere korrekte und minimale User Interfaces zu einem gegebenen System und der Aufgabenspezifikation existieren k nnen Auf diese Aussagen wird bei der Beschreibung des Verfahren
33. ergibt sich dass dem Benutzer verschwiegen wird dass sich sowohl A 1 als auch A 2 durch Ausl sen von ud in B erreichen lassen B konstituiert einen restricting state und folglich ist auch das Oberfl chenmodell aus Abbildung 4 4 6 inkorrekt Diese Feststellung steht im Widerspruch zur Annahme woraus Satz 4 4 2 folgt u Bevor die Behebung des soeben gezeigten Fehlers vorgestellt wird seien noch einmal die in Definition 2 2 1 aufgef hrten Korrektheitskriterien untersucht sie gew hrleisten dass der Benutzer immer ausreichend ber den aktuellen Zustand bescheid wei dass er das Resultat einer etwaigen Aktion vorausahnen kann und dass ihm keine falschen Versprechungen ber m gliche Zustandswechsel gemacht werden Wie jedoch schon in Kapitel 2 2 angedeutet wurde ist der Fall nicht abgedeckt in dem ein System einen Zustandswechsel der Oberfl che hervorruft den der Benutzer nicht abzusehen vermag Das folgende Beispiel demonstriert dass solch eine Situation auftreten kann In Abbildung 4 4 7 ist ein abstraktes Maschinenmodell samt der Einteilung in Spezifikationsklassen dargestellt bei dem das Augenmerk auf den Zust nden der Spezifikationsklasse S liegen wird Abbildung 4 4 7 Abstraktes Maschinenmodell eines Systems inklusive Spezifikationsklassen Auf die Beschreibung des Vorgehens des Reduktionsalgorithmus sei auch hier verzichtet er liefert das Oberfl chenmodell aus Abbildung 4 4 8 auf der folgenden Seite S A und S B wurden zu S
34. unterliegende Verhalten des Systems beobachtbar ist Beobachtbarkeit 7 Kapitel 2 Grundlegende Probleme und Ziele des User Interface Designs meint intuitiv gesprochen dem Benutzer jederzeit die fur die Benutzung relevanten Ablaufe offen darzulegen und zwar in einer Weise die es ihm erlaubt das Geschehen so zu verfolgen dass er sich in der Lage sieht seine Ziele zu erreichen Dies beinhaltet neben dem Wissen ber den aktuellen Zustand und m gliche Folgezust nde auch dass die kognitiven Anforderungen den F higkeiten des Benutzers entsprechen Der Begriff Beobachtbarkeit entstammt der Regelungstechnik und bezeichnet das Ma daf r wie gut der interne Zustand eines Systems aus dem Wissen externer Ausgaben abgeleitet werden kann Norman schl gt die von ihm konstatierten Prinzipien guten Designs VGL NORMAN 1989 S 17F UND S 52F f r den Entwurf eines Ger ts als Leitfaden vor Sie spiegeln implizit die grundlegenden Voraussetzungen daf r wider dass ein Ger t beobachtbar ist Der Benutzer kann den Zustand des Ger ts und Alternativen f r die n chste Aktion erkennen visibility ebenso das Verh ltnis zwischen Aktionen und Konsequenzen sowie zwischen Zust nden des Systems und des Interfaces good mappings Au erdem erh lt er stetig R ckmeldung ber die Auswirkungen seiner Aktionen feedback Weiterhin fordert Norman ein gutes konzeptuelles Modell good conceptual model das sich aber st rker auf die optische Pr senta
35. wird noch der Startzustand als State2 neu festgelegt daf r wird das entsprechende Werkzeug im Tool Bar ausgew hlt und der Zustand angeklickt Eine Funktion die am Beispielmodell nicht ausgef hrt werden soll aber exemplarisch einmal gezeigt wird ist das L schen eines Zustands oder einer Transition repr sentiert wird sie durch die Schaltfl che mit dem Kreuz im Tool Bar Ein Klick auf das zu entfernende Objekt gen gt es wird jedoch nachgefragt ob der L schvorgang wirklich durchgef hrt werden soll dargestellt in Abbildung 5 2 5 Diese Frage werde hier verneint Ole IE sar emp Delete state State2 Do you really wish to delete the state E Notice Deleting the state leads automatically to deleting the related transitions and removing the specification class if it only contains this state Cancel Delete state R es ae os el Abbildung 5 2 5 Entfernen eines Objekts hier des rot eingefarbten Zustands erfordert eine Best tigung State2 Sind alle Zust nde und Transitionen vorhanden so ist der n chste logische Schritt die Einteilung in Spezifikationsklassen vorzunehmen Dazu wird die Schaltfl che mit dem gestrichelten gr nen Kasten gedr ckt Davon ausgehend werden die zusammenzufassenden Zust nde per Linksklick ausgew hlt die Eingabe wird dann per Rechtsklick unter Mac ctr Linksklick beendet Ein Fenster erscheint in dem der Name der Klasse einzugeben ist F r das vo
36. zum implementierten Software Tool zu geben findet sich im Folgenden die Umsetzung des Verfahrens als Pseudocode auf abstrakter Ebene Main method of the reduction algorithm PROGRAM reduction algorithm machineStates machineTransitions specClasses VAR maxCompatibles compute_maximal_compatibles machineStates machineTransitions specClasses VAR userStates compute_minimal_cover maxCompatibles specClasses VAR userTransitions determine transitions userStates machineStates machineTransitions Computation of all the maximal compatible state sets PROCEDURE compute maximal compatibles machineStates machineTransitions specClasses VAR compatibles create _initial_compatibles machineStates VAR mergerTable compute initial_resolution compatibles specClasses machineTransitions compatibles resolve merger table iteratively mergerTable compute _ compatible state sets recursively compatibles 3 delete not_maximal_compatibles compatibles RETURN compatibles 28 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Computation of a minimal cover of the machine model by max compatibles PROCEDURE compute minimal _cover maxCompatibles specClasses FOR i 1 TO classes DO compsOfClass get_compatibles_refering_to_class specClasses i maxCompatibles minClassCover compsOfClass FOR every non trivial subset m of compsOfClass DO IF subset_is cover_of class m specClasses i THEN IF
37. 1 zusammengefasst S C und S D zu S 2 Unter anderem wurde au erdem das automatische Ereignis 03 internalisiert und zwar deshalb weil es wie eben keinen Zustand im Oberfl chenmodell gibt der die m glichen Folgezust nde S A und S C eines Auftretens von 03 repr sentiert Dadurch zeigt das Oberfl chenmodell und somit das resultierende User Interface nicht dass ein Wechsel von S 1 nach S 2 m glich ist Schlimmer noch Der Zustand S 2 ist aus Benutzersicht scheinbar unerreichbar Diese Gegebenheit widerspricht zwar nicht den Korrektheitskriterien S 1 verk rpert also keinen error state restricting state oder augmenting state Sie vermindert auch nur bedingt die Bedienbarkeit da der Benutzer einen Wechsel nach S 2 insofern wahrnimmt als ihm der g ltige Zustand jederzeit 44 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen angezeigt wird Doch sie ist trotzdem alles andere als befriedigend denn anderenfalls k nnte jede andere automatische Transition ebenso gut verschwiegen werden Abbildung 4 4 8 Das vom Algorithmus berechnete Oberflachenmodell des Systems ans Abbildung 4 4 7 Es ist anzumerken dass aus Gr nden der Ubersichtlichkeit hier ein Beispiel mit 03 als se f Ioop gew hlt wurde Das Problem kann jedoch auch bei Ereignissen die ausschlie lich Wechsel zwischen Zust nden ausl sen auftreten Es bedarf also einer zus tzlichen Forderung f r das zu generierende Modell die absichert dass eine Tran
38. 20and 20Simplifications 20in 20Design pdf 29 09 2006 HEYMANN MICHAEL amp DEGANI ASAF 2002 II Constructing Human Automation Interfaces A Formal Approach Ninth International Conference on Human Computer Interaction in Aeronautics Boston Massachusetts Institute of Technology http ti arc nasa gov people asaf interface_design pdf Constructing 20Human Automation 20Interfaces pdf 29 09 2006 HEYMANN MICHAEL amp DEGANI ASAF 2002 III On the Construction of Human Automation Interfaces by Formal Abstraction In S Koenig and R Holte Eds Abstraction Reformulation and Approximation S 99 115 London UK Springer Verlag http ti arc nasa gov people asaf interface_design pdf On 20the 20Construction 200f 20 Human Automation 20Interfaces pdf 29 09 2006 HEYMANN MICHAEL amp DEGANI ASAF 2006 Formal Analysis and Automatic Generation of User Interfaces Approach Methodology and an Algorithm Paper accepted for publication Human Factors Journal Expected date of publication Spring 2007 http ti arc nasa gov people asaf interface_design pdf Generation_of_User_Interfaces pdf preprint 29 09 2006 NORMAN DONALD A 1989 The Design of Everyday Things Paperback edition Currency Doubleday New York 67 Literaturverzeichnis PARASURAMAN R SHERIDAN T B amp WICKENS C D 2000 A Model for Types and Levels of Human Interaction with Automation IEEE Transaction on Systems Man and Cybernetics Part A S
39. Ebene sowohl textuell als auch in Form von Pseudocode beschrieben wobei letzterer aus dem im Rahmen dieser Arbeit entwickelten Software Tool hervorgeht Auf die konkrete Umsetzung einzelner Methoden wird anhand der Beispiele genauer eingegangen Anschlie end wird den Fragen nachgegangen ob das Verfahren den Korrektheitskriterien aus Kapitel 2 standh lt inwiefern Verbesserungen des Verfahrens m glich sind und wo die Grenzen des Verfahrens liegen Bereits zu diesem Zeitpunkt l sst sich sagen dass es nicht zwangsl ufig nur en korrektes und minimales Oberfl chenmodell zu einem Maschinenmodell und der Aufgabenspezifikation gibt Es handelt sich bei der Erzeugung des Oberfl chenmodells daher nicht um eine Synthese es wird also nicht versucht das richtige Modell zu formen Vielmehr geht es darum das Maschinenmodell weitestm glich zu reduzieren ohne die Korrektheitskriterien zu verletzen VGL HEYMANN amp DEGANI 2002 I S 16 25 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Sei also angenommen das Maschinenmodell eines Systems und die Spezifikationsklassen sind gegeben Wie gesagt braucht der Benutzer zur Aufgabenerf llung nicht notwendigerweise zwischen einzelnen internen Zust nden unterscheiden zu k nnen er muss hingegen lediglich stets den aktuellen und n chsten Modus repr sentiert durch je eine Spezifikationsklasse kennen F r ihn erweist es sich deshalb als unerheblich ob das System in einem Z
40. Fakult t EIM Institut f r Informatik AG Mensch Computer Interaktion und Softwaretechnologie Universit t Paderborn STUDIENARBEIT GENERIERUNG VON KORREKTEN UND MINIMALEN OBERFLACHENMODELLEN AUS MASCHINENMODELLEN Henning Wachsmuth henningw upb de vorgelegt bei Prof Dr Gerd Szwillus und Prof Dr Franz Josef Rammig Abstract ABSTRACT Bislang beruht der Prozess des User Interface Designs auf intuitivem Vorgehen und dem R ckgriff auf Heuristiken Dieses Vorgehen birgt jedoch Schwachstellen denn es zeigt sich immer wieder dass bei der Interaktion zwischen Mensch und Maschine Situationen auftreten in denen das Interface falsche Aussagen ber die internen Abl ufe des unterliegenden Systems macht was im Ernstfall schwerwiegende Folgen haben kann Die Wissenschaftler Michael Heymann und Asaf Degani haben daher ein Verfahren entworfen das zu dem gegebenen Modell eines Systems und der Aufgabenspezifikation auf formalem Weg ein Modell der Oberfl che generiert aus dem die anzuzeigenden Informationen eines Interfaces direkt ableitbar sind Ziel ist die Beobachtbarkeit des unterliegenden Systems zu gew hrleisten der Benutzer muss jederzeit wissen in welchem Zustand sich das System befindet und welchen es in Abh ngigkeit zur n chsten Aktion erreichen wird Au erdem sollen nur die daf r minimal notwendigen Informationen vermittelt werden Im Rahmen dieser Arbeit geht es darum das Verfahren abstrakt wie auch anschaulich vorzu
41. Funktionalit ten des Programms zu erl utern und die Benutzung anschlie end anhand eines beispielhaften Wegs zu zeigen widmet sich dieses Teilkapitel dem technischen Hintergrund behandelt dabei die wesentlichen Klassen Strukturen und Abl ufe der Software Von genaueren Darstellungen der einzelnen vorbereitenden Schritte des Softwareentwicklungsprozesses wird hingegen abgesehen Sei nun das vereinfachte Klassendiagramm des Programms in Abbildung 5 1 1 auf der folgenden Seite betrachtet Der bersichtlichkeit halber wurden alle Attribute und Methoden ausgeblendet Weiterhin wurden einige bergangsklassen ausgelassen welche einzelne Komponenten der Bedienungsoberfl che sowie Dialoge betreffen ebenso wie mehrere Datenhaltungsklassen deren Bedeutung f r das Verstehen der Strukturen wenig relevant ist Das implementierte System h lt sich an das Prinzip der 3 Schichten Architektur trennt also die drei Bereiche Datenspeicherung entity Benutzerausgabe boundary und die Ausf hrung wesentlicher Systemoperationen control weitestgehend voneinander Dabei wurden die Schnittstellen zwischen diesen Bereichen minimal gehalten der Zugriff auf systeminterne Daten findet ausschlie lich ber die Kontrollklasse DataControl statt Sie fungiert in gewisser Hinsicht als Server bietet also die Verwaltung der Daten als Dienst an ohne von sich aus mit der jeweiligen Kontrollklasse zu kommunizieren Bez glich der Ausgabe kennt keine Kontrollklasse eine
42. Gr n kommt ausgibt Aber resultiert daraus schon ein korrektes Interface Sofern nicht gerade Autos direkt vor der Ampel pl tzlich anhalten wei der Fu g nger nicht wann es zu dem Wechsel von DON T WALK zu WALK kommt An manchen Kreuzungen findet sich eine Anzeige die ein gelb blinkendes laufendes M nnchen zeigt Dies dient jedoch eher der Warnung f r Autofahrer Denn f r ein korrektes Interface ist es nicht ausschlaggebend dass der Benutzer im Vorhinein wei wann es zu einem Ereignis kommen kann sondern nur dass es dazu kommen kann Drei Zust nde gen gen somit der Eigenschaft der Korrektheit und zwar so wie sie im folgenden Oberfl chenmodell zusammengefasst sind Abbildung 3 1 3 das mit dem nun vorhandenen Vorwissen keiner weiteren Erkl rung bedarf Eine Besch ftigung mit phonetischen Signalen die eine Fu g ngerampel sehbehindertengerecht macht soll hier nebenbei nicht stattfinden denn es geht ja nur darum welche Informationen angezeigt werden nicht auf welche Weise diese angezeigt werden NOT PRESSED Press To Walk PRESSED Abbildung 3 1 3 Korrektes Oberflachenmodell einer Druckknopf gesteuerten Fu g ngerampel Die Erarbeitung des Oberfl chenmodells wurde hier noch intuitiv ohne formale berpr fung der Korrektheit der Ergebnisse durchgef hrt In diesem Kapitel wird daher ein Verfahren vorgestellt mit dem sich ein Oberfl chenmodell bez glich des zugeh rigen Maschinenmodells verifizieren l
43. K hlsystems in Abh ngigkeit zur Eingabe zu jedem Zeitpunkt erkennen zu 18 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces k nnen Bei der Ampel wurde argumentativ angenommen dass f r die drei Klassen jeweils genau eine Anzeige vorhanden sein muss Dementsprechend w re auch f r das vorliegende Beispiel ein intuitiver Ansatz das Interface so zu konstruieren dass es dieser Bedingung gerecht wird In Abbildung 3 3 2 ist eine simple und gut berschaubare solche Schnittstelle dargestellt Sie zeigt die aktive Stufe hier hot dunkel hinterlegt an die anderen hell Durch die Tasten cool down und heat up l sst sich die Stufe ndern hot warm cool i down Abbildung 3 3 2 Potentielles User Interface f r das Heiz und K hlsystem Das Oberfl chenmodell dieses User Interfaces beinhaltet offensichtlich drei Zust nde welche Transitionen verlaufen aber zwischen diesen Im Maschinenmodell in Abbildung 3 3 1 ist zu sehen dass fast alle benutzergesteuerten Transitionen jeweils zur daneben befindlichen Klasse f hren Eine Ausnahme bildet lediglich die von Cool C ausgehende Transition heat up durch die das System direkt in den Zustand Hot C gelangt Die Schnittstelle selbst gibt keinen Aufschluss dar ber dass das Bet tigen der Taste heat up in der Stufe cool einen Wechsel nach hot als Konsequenz haben kann Je nach dem ob diese Situation in einer zugreifbaren Bedienun
44. allem auch nicht in dem gew nschten Ziel ein Interface zu entwickeln das sowohl korrekt als auch minimal ist even when a correct interface is found there is no assurance that it is the simplest HEYMANN amp DEGANI 2002 I S 15 Es muss also ein systematisches Verfahren gefunden werden das die korrekte und gleichzeitig minimale Informationsvermittlung garantiert Michael Heymann und Asaf Degani haben einen Algorithmus entworfen der versucht dieser Forderung gerecht zu werden Er wird Thema des folgenden Kapitels und letztlich der Kernaspekt dieser Arbeit sein Auf Beispiele zur methodischen Ermittlung von restricting states und augmenting states witd an dieser Stelle nebenbei verzichtet Die berpr fung der Korrektheit des gleich vorgestellten Verfahrens welche eine erneute Besch ftigung mit dem Konzept der Spezifikationsklassen erfordern wird wird jedoch die Entdeckung eines augmenting states in einem abstrakten Beispiel hervorbringen Ein restricting state wurde ja bereits zu Beginn dieses Teilkapitels beim ersten Oberfl chenmodell ausfindig gemacht doch auch restricting states werden noch im Blickpunkt dieser Arbeit stehen Im zusammengesetzten Modell w rde ein solcher Zustand eine unbeobachtete ausgehende benutzergesteuerte Transition aufweisen 24 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen 4 GENERIERUNG VON KORREKTEN UND MINIMALEN OBERFLACHENMODELLEN as software design is
45. also der gr tm glichen Menge an Zust nden die der Benutzer nicht voneinander zu unterscheiden braucht Trivialerweise sind Zust nde f r sich kompatibel weshalb jeder Zustand mindestens Element einer maximal kompatiblen Menge an Zust nden ist Da andersherum jeder Systemzustand selbstredend durch einen Zustand des User Interfaces abgedeckt zu sein hat muss das zu generierende Oberfl chenmodell folgerichtig eine berdeckung der Zust nde des Maschinenmodells verk rpern Definition 4 1 4 Uberdeckung cover VGL HEYMANN amp DEGANI 2002 I S 17 Eine Menge M an kompatiblen Zustandsmengen hei t Uberdeckung der Zust nde eines Systems wenn jeder Zustand des Systems in mindestens einem Element aus M enthalten ist Abbildung 4 1 1 Uberdeckung eines Maschinenmodells durch maximal kompatible Zustandsmengen Abbildung 4 1 1 veranschaulicht die Uberdeckung eines Maschinenmodells zeigt unter Anderem dass sich zwei maximal kompatible Zustandsmengen berschneiden Unter der Annahme dass dem Benutzer alle relevanten Zustands berg nge offen gelegt werden gew hrleistet das Erf llen des berdeckungskriteriums korrekte Bedienbarkeit Auf die Erarbeitung der Transitionen die 27 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen f r das Oberfl chenmodell wesentlich sind wird weiter unten eingegangen Aufgrund m glicher berlappungen kann unabh ngig davon aber der Fall auftreten dass f r eine ber
46. andere bergangsklasse als MainGUI jede bergangsklasse au er MainGUl lie e sich daher austauschen ohne die anderen Schichten zu beeinflussen Die MainGUI liefert das Grundger st der Oberfl che selbst und gibt ansonsten den Gro teil der Aktualisierungsauftr ge an die einzelnen Klassen der bergangsschicht weiter 53 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen lt lt boundary gt AbstractGraphicsPanel A IN i ER N lt lt boundary i lt lt boundary MachineModelPanel MMGraphicsPanel lt lt boundary UserModelPanel 1 lt lt boundary UMGraphicsPanel lt lt boundary 7 MainGUl Fe a TT lt lt contral gt gt 1 UserModelControl 1 fis 2 lt lt control gt gt AbstractViodelControi a 2 1 1 lt lt control gt gt 7 MainControl 7 1 1 1 Rs 1 WV 1 Nr 1 Nr lt lt control gt gt 1 1 lt lt control gt gt 1 1 lt lt control gt gt f GUIStateControl gt DataControl FileControl x Eee 6 6 J lt lt entity gt gt Ka 0 7 lt lt entity gt gt UserStatelnformation SpecClassinformation M lt sentity gt gt 03 lt lt entity gt gt Stateinformation Transitioninformation lt scontrol gt gt MachineModelControl IA 1 1 lt lt entity gt gt Re 115 lt lt entity gt gt MachineStatelnformation 7 Compatiblelnfor
47. ann gefordert sein die Anzahl der Zustande oder die der Transitionen zu minimieren Ebenso kann aber auch die inhaltliche Bedeutung der sich ergebenden Anzeigen das entscheidende Moment sein Da es hier jedoch darum gehen soll ein automatisches und allgemein anwendbares Verfahren zu entwickeln und rein prinzipiell kein Kriterium st rker wiegt als die anderen wurde f r das Software Tool die bestm gliche Reduktion der Menge an Zust nden als oberste Priorit t definiert da sie sicherlich der Entlastung des Benutzers f rderlich ist Die Berechnung einer minimalen berdeckung ist ein NP schweres Problem Der Beweis dessen soll hier nicht gef hrt werden lie e sich aber durch polynomielle Reduktion auf ein bekanntes solches Problem anstellen Der Code der Methode compute_minimal_cover zeigt dass pro Spezifikationsklasse alle Kombinationen zugeh riger maximal kompatibler Zustandsmengen compsOfClass getestet werden um eine minimale Uberdeckung der Zust nde der Klasse minClassCover zu finden Anschlie end werden aus den ausgew hlten Zustandsmengen direkt Zust nde des Oberfl chenmodells erzeugt create_user_state Selbstredend wird mit diesem brute force Ansatz die Minimierung anzuzeigender Zust nde garantiert Auf Basis der durch die berdeckung gegebenen Zust nde werden schlie lich die Transitionen des Oberfl chenmodells festgesetzt Generell darf verst ndlicherweise kein Ereignis welches in einem Wechsel des Zustands des Ober
48. as hei t f r alle folgenden Betrachtungen kann das konkrete Design einer Schnittstelle bergangen werden die Besch ftigung mit dem Oberfl chenmodell deckt dieses vollkommen ab Au erdem enth lt es implizit Aussagen die etwa eine Bedienungsanleitung auflistet und zwar in Form der Transitionen Eine Transition J zwischen zwei Zust nden und besagt ja schlie lich nichts anderes als Wenn das System in Zustand ist und Ereignis J ausgel st wird so schaltet das System in den Zustand S Aus diesem Grund kann also auch auf die Unterscheidung dazwischen verzichtet werden welche Informationen ein User Interface selbst preisgibt und welche sich in den beigef gten Hilfsmaterialien befinden VGL HEYMANN amp DEGANI 2006 S 8 Das Oberfl chenmodell verbindet all diese Quellen siehe auch Definition 3 1 2 und stellt sie abstrakt dar weshalb es f r die vorliegenden Zwecke berlegen ist u cool cool down heat up Abbildung 3 3 5 Alternatives Oberflachenmodell des Heiz und K hlsystems Das Problem bei den oben abgebildeten Modellen entstand aus den unterschiedlichen internen Folgezustanden von Cool A und Cool B gegen ber Cool C bez glich der Transition heat up Das Modell in Abbildung 3 3 5 versucht diese Schwachstelle nun zu beheben indem es den Modus COOL in zwei Untermodi aufteilt die genau auf die Differenz zwischen den Zust nden in COOL was eingehende und ausgehende Transitionen betrifft abzielen Dies zeigt ein
49. asterize arrangement of states eingestellt danach f hrt Dr cken des Buttons ganz rechts im Tool Bar zur Berechnung und Anzeige des korrekten und minimalen Oberfl chenmodells Es ist in Abbildung 5 2 8 dargestellt die auch die automatische Benennung der Zust nde illustriert Offensichtlich haben sich die Zust nde aus 3 AND 4 entgegen denen aus 1 AND 2 als kompatibel herausgestellt Die genaue Zusammensetzung der Zust nde des Maschinenmodells in denen des Oberflachenmodells kann in der Auswahlliste contains nachvollzogen werden welche f r einen ausgew hlten Zustand des Oberfl chenmodells unten links angezeigt wird Namen und Positionen der Zust nde und Transitionen lie en sich jetzt noch nach gleichem Vorgehen wie beim Maschinenmodell nachtr glich ndern was hier nicht geschehen soll Es sei aber darauf hingewiesen dass die Umbenennung einer der mit t1 gelabelten Transition gleichzeitig die Umbenennung aller so gelabelten Transitionen bewirkt um die Semantik des Modells aufrecht zu erhalten OE R I PA ao Oberflachenmodell 1 AND 2 1 3 AND 4 1 Y 1 AND 2 2 Abbildung 5 2 8 Driicken des Buttons oben in der Mitte fiihrt zur Generierung des Oberflachenmodells 62 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen Die letzte hier noch beschriebene Aktion soll das Speichern der beiden Modelle sein Dazu wird Save model unter dem Men punkt File ausgew hlt Es ffnet sich ein Dialog in dem de
50. che Zust nde zu einer Klasse zusammengefasst werden wird von Design Teams mittels Anwendung von Techniken der Aufgabenanalyse sowie Experteneingaben vorgenommen Dieser Schritt der Erzeugung eines Interfaces erfordert also sehr wohl menschlichen Einfluss l sst sich aber in den generellen Entwicklungsprozess einer Software integrieren wie ihn etwa die Unified Modeling Language UML vorsieht VGL HEYMANN amp DEGANI 2006 S 6F UND S 24F Hinweis Bei der Auseinandersetzung mit den Eigenschaften von Spezifikationsklassen wurde klar dass Definition 3 2 1 die sich auf die Informationen st tzt welche den Quellen DEGANI amp HEYMANN 2002 HEYMANN amp DEGANI 2002 I III sowie HEYMANN amp DEGANI 2006 zu entnehmen sind unzureichend f r das in Kapitel 4 beschriebene Verfahren zur automatischen Generierung von Interfaces ist Im Anschluss daran wird die Definition daher noch einmal untersucht werden und es wird sich zeigen dass eine weitere Bedingung f r die Einteilung in Spezifikationsklassen gefordert werden muss Die Betrachtung wird jedoch erst dann sinnvoll wenn der Generierungsalgorithmus hinreichend bekannt ist F r den Moment reichen au erdem die oben stehenden Angaben aus um das Klassenkonzept zu verstehen Zur Veranschaulichung der Bedeutung von Spezifikationsklassen sei erneut das Maschinenmodell der Fu g ngerampel untersucht Abbildung 3 2 2 zeigt eine Einteilung der sechs Zust nde in drei verschiedene Modi die auf den A
51. chrieben sie lassen sich alternativ auch ber Tastaturk rzel aktivieren Dabei werden die K rzel an das verwendete Betriebssystem angepasst denn w hrend etwa die Standardmaskierung unter Windows oder Linux mittels der Taste ctr geschieht findet diese bei Mac OS X nicht durch ctr sondern durch statt In der Mitte gibt es links einen Bereich f r das Maschinenmodell machine model und rechts einen f r das Oberfl chenmodell user model Diese beiden Arbeitsfl chen sind in ein split panel eingebettet so dass sich ihre Gr e bei Bedarf mittels der Regler zwischen den Modellen anpassen oder eins von beiden vor bergehend v llig ausblenden l sst Der untere Teil der Oberfl che beinhaltet auf der linken Seite eine Anzeige f r Informationen des selektierten Zustands bzw der selektierten Transition selected object welche auch Eingaben 56 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen des Benutzers erlaubt Aktuell ist in der Abbildung der Zustand Cool A des Maschinenmodells selektiert erkennbar an der blauen Einf rbung dessen Koordinaten in der Fl che sowie Name und Klassenzugeh rigkeit in den Textfeldern erscheinen Rechts von diesem Bereich ist ein Ausgabefeld das eine Kurzbeschreibung der Funktionsweise des ausgew hlten Werkzeugs in sich tr gt hier die des standard tools im Tool Bar ebenfalls blau eingef rbt welches dem Selektieren und Bewegen von Objekten dient
52. chtet Abbildung 4 4 1 zeigt das abstrakte Maschinenmodell eines Systems Die Aufgabenspezifikation besage dass der Benutzer jederzeit wei in welcher der Spezifikationsklassen C 1 und C 2 sich das System befindet und welche es als n chstes erreichen wird Das benutzergesteuerte Ereignis J schaltet vom Startzustand S 1 in den Zustand S 2 In S 2 bleibt ein weiteres Auftreten von f ergebnislos Das interne Ereignis t kann jedoch einen Zustandswechsel nach T 1 bewirken Das Beispiel ist keineswegs unrealistisch Wie bereits zu Beginn von Kapitel 3 gesagt geben viele Fu g ngerampeln nach Dr cken des Knopfes kein Feedback Die Gr nphase f r den Fu g nger kommt hingegen einfach scheinbar unbestimmte Zeit sp ter Abbildung 4 4 1 Maschinenmodell eines abstrakten Systems inklusive zwei Spexifikationsklassen Welches Oberfl chenmodell ergibt sich also nach Anwendung des Reduktionsalgorithmus In Abbildung 4 4 2 findet sich die initiale Resolution der merger table T 1 ist inkompatibel mit beiden anderen Zust nden denn er geh rt nicht der gleichen Spezifikationsklasse an Weiter gibt es kein gemeinsames Ereignis von S 1 und S 2 das in einem Zustandspaar resultiert Daher bleibt die Zelle welche diese Zust nde repr sentiert leer Schon nach einer einzigen Iteration des Resolutionsprozesses ver ndert sich die Tabelle nicht mehr Die Zelle von S 1 und S 2 wird folglich als kompatibel markiert vgl Abbildung 4 4 3
53. chzeitige Abbildung aller m glichen Ereignissequenzen eines Maschinenmodells und des zugeh rigen Oberfl chenmodells darstellt Es ist formal definiert durch ein 6 Tupel n PR OS go Ors S auto mit e endlichen Eingabealphabeten 2 fiir benutzergesteuerte Ereignisse und 2 f r ggf maskierte automatische Ereignisse e einer endlichen Menge O SO xQ an Zustandspaaren bestehend aus System und Interface Zustand inklusive eines Startzustands 45 4 q E QS e Ubergangsfunktionen 0 0 x XS gt Of und Sw OF X XS 0 Bevor die Entwicklung eines solchen Modells graphisch veranschaulicht stattfinden soll seien zun chst die Eingabealphabete 2 und amp des Maschinen und des Oberfl chenmodells eingehender untersucht Dies wird auch erkenntlich machen wieso das Eingabealphabet des zusammengesetzten Modells fiir automatische Ereignisse das des Oberflachenmodells ist 21 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces Wie das Konzept der Spezifikationsklassen vorgibt muss der Benutzer nicht exakt wissen in welchem Zustand sich das System befindet sondern nur welcher Modus aktiv ist und welcher der folgende sein wird Deshalb k nnen einige interne Ereignisse beim User Interface vernachl ssigt werden andere lassen sich gruppieren Diese Abstraktion wird durch eine Projektion II ZU gt 2 auto auto erreicht die entscheidet welche Ereignisse im Eingabealphabet des Oberfl chenmode
54. deckung nicht alle maximal kompatiblen Zustandsmengen ben tigt werden Da nun weiter ein in dieser Arbeit formuliertes Ziel des User Interface Designs ist die Anzahl angezeigter Informationen so gering wie m glich halten bedarf es folglich einer minimalen berdeckung des Maschinenmodells durch maximal kompatible Zustandsmengen Definition 4 1 5 Minimale berdeckung minimal cover VGL HEYMANN amp DEGANI 2002 I S 18 Eine berdeckung M der Zust nde eines Systems ist minimal wenn keine echte Teilmenge von M eine berdeckung der Zust nde des Systems darstellt Maximal kompatible Zustandsmengen und eine minimale berdeckung des Maschinenmodells erweisen sich also als Essenz des Algorithmus In Kapitel 4 4 und Kapitel 4 5 wird berpr ft werden ob ein damit gebildetes Oberfl chenmodell die Korrektheitskriterien erf llt und au erdem das Verhalten des unterliegenden Systems weitestm glich abstrahiert wird An dieser Stelle soll es gen gen sich der Konzepte bewusst zu sein da dies erlaubt den generellen Ablauf des Reduktionsalgorithmus im Gesamten zu betrachten 4 2 BERBLICK BER DEN REDUKTIONSALGORITHMUS Ehe die Generierung von Oberfl chenmodellen an Beispielen erl utert werden wird gibt dieses Teilkapitel einen berblick ber das Verfahren Teilweise wird hier noch nicht die genaue Methodik einzelner Schritte beschrieben und zwar dann wenn sich dies ohne Beispiel als unpraktikabel erweisen w rde Um einen Bezug
55. die sich bilden lassen untereinander kompatibel sind Heymann und Degani beschreiben in den gegebenen Quellen nicht wie sich die daf r notwendigen Berechnungen vollziehen vermutlich deshalb weil dies f r eine konkrete Zustandsmenge klar erscheint Anstatt im allgemeinen Fall aber nun alle kompatiblen Mengen paarweise vergleichen zu m ssen wird innerhalb des Programms ein rekursiver Algorithmus verwendet der sich Eigenschaften von Mengen und Operationen auf diesen zu Nutze macht und in Kapitel 4 3 n her charakterisiert werden wird Nach Ausf hrung der entsprechenden Methode compute_compatible_state_sets_recursively sind dann alle kompatiblen Zustandsmengen ermittelt worden W hrend der Pseudocode aus Gr nden der bersichtlichkeit an dieser Stelle besagt dass alle nicht maximalen kompatiblen Mengen jetzt wieder entfernt werden ist das bei der Umsetzung in der Software bereits passiert In dem Moment n mlich in dem etwa wie oben S gefunden wurde kann die Maximalit t der drei zugeh rigen Paare ausgeschlossen werden Der zweite Schritt des Generierungsverfahrens besteht nun darin eine minimale Uberdeckung anhand der vorliegenden maximal kompatiblen Zustandsmengen zu bestimmen The selection among the various candidate user models cannot generally be quantified and is based on engineering and human factors considerations HEYMANN amp DEGANI 2006 S 22 Je nach dem worauf das Design des User Interfaces abzielt k
56. eh ren und dieselben Benutzeraktionen erm glichen ber die Frage des Sinns eines solchen Systems sei hier hinweggesehen Dann sind alle Zust nde in jedem Fall paarweise miteinander kompatibel Folgerichtig w rde der Reduktionsalgorithmus eine maximal kompatible Zustandsmenge der Gr e berechnen Die Methoden zum Finden kompatibler Zustandsmengen haben zwar f r sich nur polynomielle Laufzeit schr niedrigen Grades ebenso brigens die f r das Festsetzen der Transitionen Da der Algorithmus f r das beschriebene Modell aber in jedem rekursiven Schritt jeweils alle Teilmengen einer bestimmten Gr e m lt n miteinander vergleichen muss folgt exponentielle Laufzeit Es ist klar dass sich hnliche F lle auch in realistischeren Modellen ergeben k nnen Auch die Suche nach einer minimalen berdeckung bedeutet wie gesagt f r jede Spezifikationsklasse das Testen jeder m glichen Kombination an maximal kompatiblen Zustandsmengen die aus der Klasse hervorgehen Zweifelsohne k nnen also die notwendigen Berechnungen f r sehr gro e Systeme mit tausenden an Zust nden untragbar werden VGL AUCH HEYMANN amp DEGANI 2006 S 25 Wie dem auch sei es kann behauptet werden dass die Laufzeit im Allgemeinen trotzdem theoretisch nicht schlecht ist was auf den ersten Blick berraschend klingen mag sich aber begr nden l sst Die worst case Laufzeit ist n mlich nicht etwa durch die Anzahl der Zust nde eines Systems nach oben abgegrenzt oder schl
57. eidung selbiger im Allgemeinen wichtig sein 39 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Zuletzt seien noch die Zustande S A S B S C in S 1 und S C S D S E in S 2 umbenannt Es entsteht das in Abbildung 4 3 9 aufgef hrte korrekte und minimale Oberfl chenmodell des Systems Li o b Abbildung 4 3 9 Korrektes und minimales Oberflachenmodell des abstrakten Systems Damit sind alle grundlegenden Vorgehensweisen des Reduktionsalgorithmus besprochen Auf die explizite Angabe der in determine_transitions enthaltenen Methoden wird verzichtet da es sich bei den dort angestellten Berechnungen im Wesentlichen um berpr fungen der im Maschinenmodell bestehenden Transitionen handelt Kapitel 5 wird sich noch den technischen Hintergr nden des Software Tools widmen Ebenso wird die Oberfl che des Programms samt ihren Funktionalit ten dort beschrieben und deren Benutzung exemplarisch durchgef hrt Im Fokus soll jetzt erst einmal die Frage stehen ob der Reduktionsalgorithmus die Korrektheitskriterien einh lt Es wird sich zeigen dass weder restricting states noch augmenting states im allgemeinen Fall ausgeschlossen sind Verbesserungen des Verfahrens werden vorgestellt anhand derer sich danach die Korrektheit des Algorithmus beweisen l sst 4 4 FEHLERBEHEBUNG UND DAF R N TIGE NDERUNGEN AM REDUKTIONSALGORITHMUS Schon in Kapitel 3 2 wurde darauf hingewiesen dass im Rahmen dieser Arbeit ein
58. eine Unterscheidung zwischen 18 verschiedenen F llen der relativen Lage der beiden betroffenen Zust nde statt die regelt ob eine Transition gerade um die Ecke oder in Stufenform verl uft Mithilfe des Standardwerkzeugs lassen sich brigens auch einzelne Segmente der Linien von Transitionen verschieben Auch dies ist mittels drag n drop umzusetzen machine model State2 State4 Abbildung 5 3 3 Der Startzustand einer neuen benutzergestenerten Transition wurde bereits ausgew hlt Es sei nun im Nachhinein entschieden worden dass t3 ein automatisches Ereignis bezeichnen soll Um diese nderung zu bewerkstelligen wird eine der zugeh rigen Transitionen ausgew hlt Im unteren linken Bereich der Oberfl che erscheinen daraufhin ihre Attribute In der Auswahlliste type kann dann der Wert automatic eingestellt werden Bet tigen des Buttons change f hrt die gew nschte Aktion durch Da es jedoch eine zweite Transition mit demselben Namen gibt ffnet sich ein Dialog Abbildung 5 3 4 der hier durch Dr cken von Change all best tigt werde a Name exists more than once t3 Do you wish to change all transitions with this name d e C lected object q Just this one Change all om State4 name t3 k x State3 type automatic change Abbildung 5 3 4 ndern des Typs von Transitionen 60 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen Anschlie end
59. el wurde weiterhin gezeigt dass die Einteilung in Spezifikationsklassen eine wesentliche Vorarbeit bedeutet Die Behandlung der Entstehung der Klassen wird in dieser Arbeit aber nicht von fortw hrendem Interesse sein Vielmehr wird im weiteren Lauf davon ausgegangen werden dass das Maschinenmodell und die Aufgabenspezifikation gegeben sind Damit sind alle Vorkehrungen getroffen um die von Heymann und Degani entwickelte Methode zur Verifikation eines Interfaces an einem Beispiel zu erl utern das immerhin neun Zust nde und 24 Transitionen aufweist einem halbautomatischen Heiz und K hlsystem 17 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces 3 3 VERFAHREN ZUR VERIFIKATION DES USER INTERFACES EINER MASCHINE Nachdem die Modellierung von Systemen durch zustandsbasierte Modelle er rtert und eine M glichkeit die Spezifikation der Aufgaben eines Benutzers zu formalisieren aufgezeigt wurde wird in diesem Teilkapitel die Korrektheit potentieller User Interfaces beschrieben durch ihre assoziierten Oberfl chenmodelle bez glich des Maschinenmodells des unterliegenden Systems berpr ft Die dabei verwendete Methode wurde von Heymann und Degani entwickelt und dient dazu error states restricting states und augmenting states aufzusp ren Sie soll an einem neuen Beispiel das auch f r die Vermittlung des Verfahrens zur Generierung von Interfaces n tzlich sein wird veranschaulicht werden welches im Folgenden vo
60. eliebig gew hlten Startzustand Drive 1 haben Autos Vorrecht Bet tigen des Knopfes der Ampel symbolisiert durch das benutzergesteuerte Ereignis Press bewirkt einen Wechsel zu Drive 2 Von dort aus wird automatisch Ereignis To NOR erst nach NOR 1 dann To Walk nach Walk und anschlie end To NOR nach NOR 2 geschaltet W hrend dieses Ablaufs bleibt ein erneutes Dr cken des Knopfes ergebnislos was die mit Press gelabelten se f Joops ausdr cken Der Folgezustand von NOR 2 ist schlie lich Drive 1 es sei denn Press wurde bereits ausgel st in diesem Fall wird erst NOR 3 erreicht und danach Drive 2 Walk ist der einzige Zustand in dem Fu g nger die Stra e berqueren d rfen in NOR 1 NOR 2 und NOR 3 m ssen sie genauso wie die Autos warten Solch ein Modell ist das Maschinenmodell eines Systems l Press Abbildung 3 1 1 Maschinenmodell einer Druckknopf gestenerten Fu g ngerampel Definition 3 1 1 Maschinenmodell machine model Das Maschinenmodell eines Systems ist ein endlicher Zustandsautomat der das Verhalten des Systems vollst ndig beschreibt Es ist formal definiert durch ein 6 Tupel Air Zaw Q do Oun Can Mit e endlichen Eingabealphabeten 2 f r benutzergesteuerte Ereignisse und 2 f r user auto automatische Ereignisse e einer endlichen Menge QO an Zust nden inklusive eines Startzustands q Q bergangsfunktionen 8 0 x Xi 0 und 6 0 x 3 gt 0 Eins der wesentlichen Ziele dieser Arbei
61. ement erweist sich als obligatorisch Dieses Resultat ist sicherlich nicht w nschenswert denn dadurch geht die Minimierung der Anzahl an Zust nden mit der Erh hung der Anzahl notwendiger Benutzeraktionen einher Es stellt sich jedoch die Frage inwiefern es Alternativen f r die hier angestellte Korrektur gibt Diese Frage f hrt zu dem unterliegenden Problem das Situationen hervorruft in denen concealing states und error states auftreten Wenn der einzige Weg im Schritt der Determinierung der Transitionen solche Zust nde zu vermeiden ist neue Transitionen zu generieren dann liegt der Schluss nahe dass die von einem solchen Zustand repr sentierten Systemzust nde im Grunde nicht kompatibel sind bzw dass die Definition von Kompatibilit t nicht gen gend Bedingungen enth lt Es m ssten demnach Einschr nkungen getroffen werden die verhindern dass resultierende Transitionen des Oberfl chenmodells zu so nicht existenten Zust nden f hren Ein solches Konzept h tte aber die berarbeitung der Berechnung maximal kompatibler Zustandsmengen zur Folge was den Umfang dieser Arbeit bersteigt Abgesehen davon ist der oben angef hrte L sungsansatz keineswegs falsch im Gegenteil Die von dem ge nderten Reduktionsalgorithmus berechneten Oberfl chenmodelle gen gen allen geforderten Korrektheitskriterien Diese Behauptung soll gleich bewiesen werden ebenso wie die Minimalit t der sich ergebenden Modelle Zudem macht die Einf hrung der umbena
62. en Oberflachenmodellen als inkompatibel herausgestellt hatte AuBerdem zeigt sich bereits hier dass die Zellen der Paare aus HOT gleich bleiben Sowohl die Zelle von Hot A und Hot B als auch die von Hot B und Hot C verweisen auf sich selbst Da dar ber hinaus Warm A Warm B leer ist gibt es keine nderung des Inhalts der Zellen Ein weiterer Schritt des Resolutionsprozesses identifiziert keine neuen inkompatiblen Paare Ebenso ist der Inhalt der Tabelle identisch zu dem in Abbildung 4 3 3 Innerhalb der Umsetzung des Algorithmus gilt also cellChanged FALSE was zum Abbruch der Schleife f hrt Die Resolution terminiert aus diesem Grund und die Zellen der Zust nde die nicht Incompatible in sich tragen werden als Compatible markiert wie es in Abbildung 4 3 4 dargestellt ist Cool B Incompatible Cool C Incompatible Incompatible Warm A Incompatible Incompatible Incompatible Warm B Incompatible Incompatible Incompatible Compatible Warm C Incompatible Incompatible Incompatible Incompatible Incompatible Hot A Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Hot B Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Compatible Hot C Incompatible Incompatible Incompatible Incompatible Incompatible Incompatible Compatible Compatible Cool A C
63. er mehrere interne Zust nde Die Anforderung an das User Interface mit der sich an dieser Stelle besch ftigt werden soll ist die Gew hrleistung der Beobachtbarkeit der Modi des unterliegenden Systems a common task specification in an automated control system is that the user be able to determine unambiguously the current and the subsequent mode of the machine HEYMANN amp DEGANI 2002 I S 7 Heymann und Degani formalisieren solche Modi in Form so genannter Spezifikationsklassen die sie wie folgt definieren Definition 3 2 1 Spezifikationsklasse specification class VGL HEYMANN amp DEGANI 2006 S 6 Eine Spezifikationsklasse innerhalb eines Systems ist eine Menge interner Zust nde zwischen denen der Benutzer inhaltlich nicht unterscheiden k nnen muss Jeder Zustand des Systems ist Element genau einer Spezifikationsklasse Sei M die Menge der Zust nde und C die Menge der Spezifikationsklassen eines Systems Dann gilt VSEM AC EC SEC A VGEC i j gt s C Abbildung 3 2 1 Einteilung der Zust nde eines Maschinenmodells in Spezifikationsklassen 15 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces Die Einteilung der Spezifikationsklassen entspricht also einer disjunkten Clusterung der Zust nde eines Systems verbildlicht durch Abbildung 3 2 1 Es handelt sich dabei folgerichtig um eine Partition Zust nde einer Klasse hei en spezifikations quivalent Die Entscheidung wel
64. er table beinhaltet pro Zustandspaar des Maschinenmodells eine Zelle die in compute_initial_resolution mit den Paaren an Folgezust nden sofern vorhanden initialisiert wird die sich durch Ausl sen eines einzelnen Ereignisses erreichen lassen Zust nde die nicht der gleichen Spezifikationsklasse angeh ren oder verschiedene Aktionen des Benutzers erlauben werden schon hier als inkompatibel markiert Danach werden alle weiteren inkompatiblen Zustandspaare mittels iterativen Ersetzens der in den Zellen gespeicherten Paare durch deren m gliche Nachfolgezustandspaare herausgearbeitet indem die Kriterien aus Definition 4 1 2 angewendet werden Dieses Resolutionsverfahren umgesetzt in der Methode resolve_merger_table_iteratively terminiert wenn sich die Tabelle nicht mehr ver ndert wenn also keine neuen Ereignisfolgen mehr abzuhandeln sind Alle Zustandspaare die bis dahin nicht als inkompatibel erkannt worden sind m ssen folgerichtig kompatibel sein denn sie erf llen die Bedingungen aus Definition 4 1 1 Es kann nun aber sein dass sich noch gr ere kompatible Zustandsmengen finden lassen Wie angesprochen folgt f r Zust nde S und etwa aus den kompatiblen Paaren 3 29 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Sp S und S 53 dass S S S ein kompatibles Tripel darstellt Entsprechend sind vier Zustande kompatibel wenn alle sechs 2 Tupel bzw alle vier 3 Tupel
65. es und Geistes Ab einem bestimmten Grad wird der Benutzer die Schnittstelle nicht mehr berschauen k nnen und daher nicht mehr entscheiden k nnen welche Informationen f r ihn wesentlich sind Weiter steht gerade bez glich technischer Ger te die Aufmerksamkeit des Benutzers im Fokus Wie bereits angesprochen stellt ein User Interface im Allgemeinen eine hohe Abstraktion der internen Logik des unterliegenden Systems dar Damit Systeme bersichtlich bleiben laufen zahlreiche Aktivit ten automatisch im Hintergrund ab Insbesondere mit solchen automatisierten Systemen befasst sich diese Arbeit No the transition happens without any direct user involvement this is where it all begins DEGANI 2004 S 59 Wenn Vorg nge ohne Einfluss des Benutzers geschehen weil sie von internen oder externen Bedingungen ausgel st werden und sie Relevanz f r die Bedienung des Systems haben ist angemessene R ckmeldung zwingend erforderlich In dem Paper A Model for Types and Levels of Human Interaction with Automation PARASURAMAN ET AL 2000 betonen Raja Parasuraman Thomas B Sheridan und Christopher D Wickens unter Anderem dass der Benutzer einer Maschine bevorzugt dann aufnahmef hig ist wenn er sie aktuell selbst steuert Im Umkehrschluss Humans tend to be less aware of changes in environmental or system states when those changes are under the control of another agent whether that agent is automation or another human than when the
66. eudocode skizziert Die Methode bricht ab wenn in einem Durchlauf keine neuen kompatiblen Mengen mehr gefunden worden sind foundNewCompatible FALSE Find all compatible state sets with cardinality n gt 2 recursively PROCEDURE compute compatible state_sets_recursively compatibles n VAR foundNewCompatible FALSE VAR comps get_compatibles_ of size n 1 FOR i 1 TO comps 1 DO FOR j 0 TO i 1 DO VAR union get_union comps i comps j IF union n THEN VAR newCompatible TRUE VAR intersection get_intersection comps i comps j FOR k 1 TO intersection DO VAR set union intersection k IF NOT contains comps set THEN newCompatible FALSE IF newCompatible TRUE THEN compatibles create_new_compatible union foundNewCompatible TRUE IF foundNewCompatible TRUE THEN compute_compatible_state_sets_recursively compatibles n 1 Anhand der Zust nde aus HOT sei diese Methode zur Berechnung von Mengen der Gr e n 3 erkl rt Die Vereinigung zweier kompatibler Zustandspaare seien dies etwa Hot A Hot B und Hot B Hot C ist U Hot A Hot B Hot C welche in get_union comps i comps j konstruiert wird U enth lt einen Zustand mehr als die Eingabemengen ist also ein potentieller Kandidat f r eine neue kompatible Menge union n Daher wird die Schnittmenge I Hot B der Zustandspaare gebildet Existieren nun alle kompatiblen Zustandsmengen der Gr e n 7 2
67. f r die Einteilung in Spezifikationsklassen gefordert wird Benutzergesteuerte Transitionen d rfen niemals zwischen zwei verschiedenen Zust nden derselben Spezifikationsklasse bestehen Formal ausgedr ckt Definition 4 4 1 Erweiterung der Definition von Spezifikationsklassen Sei M die Menge der Zust nde U die Menge der benutzergesteuerten Transitionen und C die Menge der Spezifikationsklassen eines Systems Zus tzlich zu Definition 3 2 1 gelte VS S EM S SJEU A S S gt TAC EC S EC A S EC Diese Forderung erscheint auf Anhieb sinnvoll da jede Aktion des Benutzers eine sichtbare Wirkung haben sollte wie schon in Kapitel 2 herausgearbeitet wurde Doch zweifelsohne stellt sie eine Einschr nkung des Verfahrens dar Nichtsdestotrotz verhindert sie die M glichkeit dass augmenting states auftreten wie im folgenden Teilkapitel gezeigt werden wird Unabh ngig davon folgt aus dieser Bedingung noch nicht dass der Reduktionsalgorithmus alle drei Korrektheitskriterien einh lt wie der Beweis des folgenden Satzes zeigt Satz 4 4 2 Der Reduktionsalgorithmus gew hrleistet nicht die Vermeidung von restricting states Beweis von Satz 4 4 2 ber Widerspruch Angenommen der Algorithmus vermeidet restricting states Dann muss er deren Existenz in allen berechneten Oberfl chenmodellen generell ausschlie en Es werde nun das Maschinenmodell in Abbildung 4 4 5 betrachtet Dieses Modell entspricht bis auf eine Ausnahme dem zweiten Be
68. faces ab Es stellt sich die Frage welche Informationen nach au en getragen werden m ssen damit die korrekte Bedienbarkeit einer Maschine gew hrleistet ist Der Benutzer sollte jederzeit in der Lage sein zu erkennen in welchem Zustand sich das System befindet und was etwaige Handlungen f r Konsequenzen haben Das mag bei einem simplen Radiowecker noch relativ belanglos erscheinen bei sicherheitskritischen Systemen wie dem Autopiloten eines Flugzeugs entscheiden diese Kriterien aber mitunter ber Leben und Tod In dem Buch Taming HAL Designing Interfaces Beyond 2001 DEGANI 2004 beschreibt Asaf Degani vom NASA Ames Research Center in Kalifornien mehrere solcher F lle Ausreichende Information ist jedoch nur die eine Seite Genauso sollte der Benutzer nicht mit irrelevanten Informationen konfrontiert werden denn sie stellen eine unn tige kognitive Belastung dar There is a clear advantage for simpler interfaces they usually are cheaper to 1 Kapitel 1 Einleitung produce they make user manuals smaller and less confusing and place less of a burden on the user DEGANI 2004 S 161 Eine Schnittstelle gen gt im optimalen Fall also v llig unabh ngig aller sthetischen und ergonomischen Gesichtspunkte den Bedingungen dass einerseits die erfolgreiche Ausf hrung aller spezifizierten Aufgaben bestm glich unterst tzt wird und andererseits der Umfang der angezeigten Zust nde und Ereignisse auf ein Minimum reduzier
69. fl chenmodells resultiert verschwiegen werden Aus diesem Grund werden in create_all_transitions vorerst alle berg nge die zwischen den in diesen Zust nden zusammengefassten Systemzust nden hin und herschalten generiert for each user model mode and each event label that emanates from it we determine the set of all constituent machine model target states HEYMANN amp DEGANI 2006 S 22 Angenommen also ein Zustand des Interfaces beschreibt die maximal kompatible Zustandsmenge S Ss Intern f hre ein Ereignis J von S zu T von S aus hingegen zu T daraus folgt nebenbei dass 30 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen T und T kompatibel sein m ssen Dann werden mit J gelabelte Transitionen zwischen und allen Interface Zust nden die sowohl T als auch T beinhalten erstellt Offensichtlich k nnen sich nicht deterministische Situationen ergeben wenn mehrere Zust nde aus internen Folgezustanden hier aus T und T hervorgehen Dieser Nicht Determinismus kann aber nie in error states m nden weil er nur innerhalb von Spezifikationsklassen auftritt VGL HEYMANN amp DEGANI 2006 S 23 Er l sst sich beseitigen indem redundante Transitionen einfach entfernt werden delete_nondeterministic_innerclass_transitions Dabei werden bevorzugt solche berg nge bewahrt die wieder direkt zum Ausgangszustand zur ckf hren Denn delete _automatic_self_loops l scht im n chsten
70. fsmaterialien ist korrekt wenn die spezifizierte Aufgabe stets erf llbar ist und keiner der folgenden Zust nde existiert e error state Der vom Interface repr sentierte Zustand entspricht nicht dem internen Zustand des Systems e restricting state Der Benutzer kann einen Zustandswechsel ausl sen der vom Interface nicht angezeigt und von den Hilfsmaterialien verschwiegen wird e augmenting state Das Interface oder eins der Hilfsmaterialien verhei t einen m glichen Zustandswechsel der intern nicht ausl sbar ist In HEYMANN amp DEGANI 2002 I wird nur von error states und blocking states gesprochen letztere entsprechen den restricting states VGL HEYMANN amp DEGANI 2002 I S 11 Doch nur zusammen mit den augmenting states erh lt man die gew nschte Spezifikation Wieso entspricht diese Spezifikation eines korrekten Interfaces der oben stehenden sprachlichen Definition Um diese Frage zu beantworten seien die drei gerade genannten Zustandsarten kurz genauer erkl rt Ein error state ist ein Indikator f r einen Widerspruch zwischen Interface und unterliegendem System bez glich der Aufgabenanforderung Die Bedienungsoberfl che gibt ihren Zustand nicht wahrheitsgem an der eigentlich aktuelle Zustand ist dem Benutzer folgerichtig nicht bekannt oft aber nicht zwangsl ufig treten error states nach scheinbar nicht deterministischen Reaktionen der Maschine auf an error state is a direct result of non deterministic behavior
71. genau dann nicht deterministisch wenn ein und dasselbe Ereignis J ausgel st in einem Zustand aus Sicht des Benutzers zwei oder mehr verschiedene Folgezust nde mit amp Z 3 haben kann Kapitel 2 Grundlegende Probleme und Ziele des User Interface Designs Anders ausgedr ckt eine Bedienungsoberfl che ist als nicht deterministisch zu deklarieren wenn der Benutzer nicht vorherzuschen vermag was in Abh ngigkeit zu seiner n chsten Aktion passieren wird Abbildung 2 1 2 verbildlicht die Definition noch einmal It is important to understand it because this is the fundamental problem that plagues interfaces and causes much confusion to the users DEGANI 2004 S 30 3 B po Abbildung 2 1 2 Nicht Determinismus schematisch Als Beispiel sei eine bliche Funktionstaste eines Mobiltelefons angef hrt die bei einem laufenden Gespr ch den Abbruch von selbigem bewirkt ansonsten aber der Einwahl ins Internet dient Angenommen Person A will ein Gespr ch mit Person B beenden so bet tigt A die Taste Hat sein Gegen ber B was A nicht wissen kann nun bereits kurz zuvor die gleiche Aktion ausgef hrt es kann sich hier um Bruchteile von Sekunden handeln wird A f lschlicherweise das Internet betreten ohne dass ihm das angezeigt wurde Damit werden unn tige Kosten verursacht Weitere Beispiele werden im Laufe dieser Arbeit folgen Vor allem dort wo das Verhalten des Systems aus der Erf llung von Bedingungen resu
72. gnisse werden also maskiert Innerhalb der implementierten Software findet etwa eine Umbenennung in B P P usw statt Dem Benutzer wird also vermittelt dass es sich um verschiedene Ereignisse handelt Abbildung 4 4 10 zeigt das resultierende Oberfl chenmodell des abstrakten Systems aus Abbildung 4 4 7 in dem der Name eines der Ereignisse 03 durch 03 ersetzt wurde eles i a3 Abbildung 4 4 10 Korrektes und minimales Oberflachenmodell des Systems ans Abbildung 4 4 7 46 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Im folgenden Teilkapitel wird gezeigt werden dass auf diese Weise das Auftreten von concealing states ausgeschlossen wird Vorher sei aber noch betrachtet was f r Konsequenzen die ge nderte Spezifikation des Algorithmus f r das Beispiel aus Abbildung 4 4 5 hat bei dem ein restricting state nachgewiesen wurde Es ergibt sich jetzt folgendes Oberfl chenmodell Abbildung 4 4 11 gie l Abbildung 4 4 11 Korrektes und minimales Oberflachenmodell des Systems aus Abbildung 4 4 5 Das benutzergesteuerte Ereignis ud wurde also einmal in ud umbenannt W hrend das ndern eines automatischen Ereignisses keinen bedeutungsvollen Einfluss auf das zu entwickelnde User Interface hat ist das in diesem Fall anders Denn ein weiteres benutzergesteuertes Ereignis impliziert dass der Benutzer des Systems eine weitere Aktion t tigen k nnen muss das hei t ein zus tzliches Bedienel
73. gsanleitung dargelegt ist oder nicht ergibt sich daher entweder das in Abbildung 3 3 3 oder das in Abbildung 3 3 4 dargestellte Oberfl chenmodell Beide blenden alle internen Ereignisse vollst ndig aus cool down cool down heat up Abbildung 3 3 4 Oberfl chenmodell des Heiz und K hlsystems mit externen Zusatzinformationen 19 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces Wie dem auch sei ohne Anwendung eines speziellen Verfahrens lasst sich erkennen dass beide Oberflachenmodelle keine korrekte Bedienbarkeit erm glichen Ersteres macht falsche Aussagen ber die m glichen Zustandswechsel verschweigt genauer gesagt den bergang von COOL nach HOT Damit konstituiert COOL einen restricting state Bei zweiterem liegt auf der Hand dass es ein nicht deterministisches Interface repr sentiert der Benutzer kann im Zustand COOL nicht vorhersagen welcher Folgezustand aus dem Dr cken von heat up resultiert Es kann somit geschlossen werden dass das User Interface aus Abbildung 3 3 2 sowie das zugeh rige Modell der Oberfl che die in Kapitel 2 2 aufgef hrten Korrektheitskriterien nicht erf llt Die beiden Modelle liefern dennoch eine wichtige Beobachtung mit Blick auf das Interface The user model is based on the interface because it directly relates to the indications displayed there Thus the interface is actually embedded in the user model HEYMANN amp DEGANI 2006 S 8 D
74. h Inhalt von Kapitel 6 ebenso wie ein Ausblick auf weitere Forschungsans tze und etwaige Erweiterungen der Software Kapitel 2 Grundlegende Probleme und Ziele des User Interface Designs 2 GRUNDLEGENDE PROBLEME UND ZIELE DES USER INTERFACE DESIGNS Humans do make mistakes but with proper design the incidence of error and its effects can be minimized NORMAN 1989 S Ix 2 1 MENSCHLICHES HANDELN UND DARAUS RESULTIERENDE FEHLERQUELLEN Der Umgang mit dem Computer und anderen technischen Ger ten ist f r viele Menschen zur Selbstverst ndlichkeit geworden Meist verl uft die Bedienung einer Maschine problemlos vor allem wenn es sich um gewohnte Vorg nge handelt Dennoch ergeben sich immer wieder Konfliktsituationen in denen sich ein Ger t oder Programm anders als erwartet verh lt oder in denen es zu Fehlverhalten seitens des Benutzers kommt Sie gr nden sich in einer gro en Bandbreite an Ursachen die von u eren Einfl ssen wie etwa klimatischen Verh ltnissen ber die generellen Grenzen menschlicher Leistungsf higkeit bis hin zu eindeutigen Programmier oder Konstruktionsfehlern des Systems bzw der Maschine reichen Es w re vermessen alle von ihnen aufz hlen geschweige denn genauer untersuchen zu wollen Eingeschr nkt auf den direkten Kontext der Mensch Maschine Interaktion aber lassen sich zwei grunds tzliche Kategorien von Problemtypen unterscheiden diejenigen die als Quelle menschliches Versagen in irgendei
75. hinenmodell auftreten und ihr von den bergangsklassen mitgeteilt werden und berechnet als Folge alle f r die Erstellung des Maschinenmodells wichtigen Informationen Zweitere bernimmt einerseits dieselben Aufgaben f r das Oberfl chenmodell Andererseits ist sie insbesondere diejenige in welcher der Reduktionsalgorithmus ausgef hrt wird in der also das Verfahren von Heymann und Degani umgesetzt ist Beide Klassen kommunizieren mit der DataControl zur Erzeugung Ver nderung L schung oder Ermittlung von Daten ber Zust nde Kindklassen von Statelnformation und Transitionen TransitionInformation sowie Spezifikationsklassen SpecClassInformation und kompatiblen Zustandsmengen Compatiblelnformation und beordern danach die MainGUl etwaige Aktualisierungen der Oberfl che vorzunehmen Sie erben von der abstrakten Oberklasse AbstractModelControl in der unter anderem von beiden ben tigte Methoden wie die Berechnung der Punkte einer Transition oder die Selektion und Bewegung von Objekten des Modells enthalten sind Die letzte noch zu nennende Kontrollklasse des Programms ist die GUIStateControl Sie ist zust ndig f r das Aktivieren und Deaktivieren von Bedienelementen der Benutzeroberfl che Dieser unterliegt n mlich ein Zustandsautomat mittels dem nach jeder Aktion herausgefunden wird welche Funktionen f r den Benutzer als n chstes sinnvoll sind Die GUIStateControl erfragt f r das Aktualisieren des Zustands bestimmte Daten von der Da
76. ie M glichkeit das Modell einer Oberfl che auf seine Korrektheit hin zu verifizieren Kapitel 3 Bislang basiert der bliche Prozess beim User Interface Design mehr oder minder auf intuitivem Vorgehen in Kombination mit empirischen Heuristiken Die stetig ansteigende Bedeutung und Komplexit t von technischen Systemen in Alltag Forschung und sicherheitskritischen Bereichen verdeutlicht aber dass ein Wandel zur automatisierten Generierung von Interfaces in nicht ferner Zukunft erforderlich sein wird Heymann und Degani haben ein Konzept entwickelt aus dem Modell der Maschine das Modell der Oberfl che formal abzuleiten Das entsprechende Verfahren wurde sowohl abstrakt als auch anschaulich beschrieben Ihm liegen mathematische Algorithmen zugrunde die spezifikations quivalente Zust nde auch kompatibel genannt berechnen und zusammenfassen und aus diesen eine berdeckung des Maschinenmodells bilden Kapitel 4 1 bis 4 3 Es wurde jedoch gezeigt dass das Konzept Schwachstellen birgt also die M glichkeit besteht dass das resultierende Interface zu nicht gen gend beobachtbaren Situationen f hren kann F r dieses Problem wurde anschlie end Abhilfe geleistet indem einerseits eine zus tzliche Bedingung f r Spezifikationsklassen gefordert wurde andererseits aber auch eine wirkliche nderung des 64 Kapitel 6 Zusammenfassung und Ausblick Reduktionsalgorithmus durchgef hrt worden ist Aus den Fehlerbehebungen folgt die bew
77. ie jeweils drei Zust nde des Systems repr sentieren f llt auf dass sie beide nicht deterministische ausgehende Transitionen namens 03 aufweisen Ein Ereignis wie 03 l st jedoch nur Zustandswechsel innerhalb der Spezifikationsklasse aus vgl Kapitel 4 2 und so l sst sich der Nicht Determinismus aufheben indem redundante Transitionen gel scht werden In diesem Fall geschehe das bei den berg ngen die zwischen S A S B S C und S C S D S E verlaufen Als Resultat ergibt sich dass 03 nur noch als se f oop auftritt und da derlei interne Ereignisse keinen Einfluss auf den angezeigten Zustand des User Interfaces haben k nnen auch die weiteren mit 03 gelabelten Transitionen entfernt werden Ferner ist ersichtlich dass oT und 02 ebenso wie 04 und 05 ausschlie lich zusammen an den berg ngen auftreten Genau wenn diese Situation vorliegt k nnen zwei solche Ereignisse gruppiert werden so dass sie im Oberfl chenmodell als ein und dasselbe Ereignis erscheinen Daher werden hier oT und 02 zu o a abstrahiert 04 und 05 zu o b Da das Software Tool der sinnvollen Vergabe von Labels kaum gerecht werden kann w rden dort beispielsweise 04 und 05 einfach zu o405 zusammengezogen was der Benutzer im Nachhinein aber noch ndern k nnte Unabh ngig davon werden die Bezeichnungen der zu P Q und R f hrenden Transitionen hingegen beibehalten denn die zugeh rigen Ereignisse treten in verschiedener Kombination auf und so kann eine Untersch
78. iesene Korrektheit des Verfahrens Kapitel 4 4 und 4 5 Dennoch bleiben noch weiter zu behandelnde Aspekte offen So wurde f r die Vermeidung von Zust nden in denen der Benutzer in Unkenntnis ber eine f r ihn m gliche Aktion ist restricting states nur ein provisotischer L sungsansatz geliefert Verbesserungen des Reduktionsalgorithmus diesbez glich werden mit der berarbeitung seiner Kernberechnungen einhergehen Dar ber hinaus beinhaltet das Verfahren Einschr nkungen die noch nicht konkreter untersucht worden sind deren Entfernung aber der Anwendbarkeit zutr glich w re Zum Beispiel ist die Frage nicht gekl rt wie mit zeitlich gesteuerten Ereignissen timed events umzugehen ist Wie kann der Algorithmus etwa erkennen dass es einen Zusammenhang zwischen after three seconds und after five seconds gibt und wie muss auf dies reagiert werden Und mehr noch Wie kann abgesichert werden dass zeitliche Kopplungen f r einen Benutzer beobachtbar sind Unabh ngig solcher Schwierigkeiten best nde wie schon am Ende von Kapitel 4 implizit angesprochen gro er Nutzen in der Portierung des Verfahrens auf andere Modelltypen etwa auf Petri Netze Sicherlich lassen sich noch einige andere Forschungsans tze f r die vorliegende Thematik finden aber bereits die angesprochenen Punkte legen offen dass noch Handlungsbedarf besteht Neben der schriftlichen Bearbeitung der angesprochenen Inhalte wurde im Rahmen dieser Arbeit
79. im Grunde rein mathematisches Verfahren angewendet wird besteht nicht zwangsl ufig ein logischer Zusammenhang zwischen zusammengefassten Zust nden und deren Bedeutung innerhalb des Systems Ihe proposed reduction procedure generates interfaces that are not necessarily intuitive or easily correlated with the underlying system HEYMANN amp DEGANI 2002 I S 30 Vor allem entspricht es etwa nicht der Vorstellung die ein Benutzer blicherweise von einem technischen Ger t oder Programm hat dass ein interner Zustand durch mehr als einen Zustand des Interfaces repr sentiert werden kann Diese Tatsache zeigt den essentiellen Unterschied zwischen dem menschlichen Abstraktionsprozess und dem hier vorgestellten Verfahren Doch die steigende Komplexit t aktueller und zuk nftiger Systeme und die gleichzeitig steigenden Sicherheitsanspr che an selbige zeigen dass ein Wechsel zu einem automatisierten Designprozess fr her oder sp ter kaum vermeidbar sein wird VGL HEYMANN amp DEGANI 2002 I S 30 Mit dieser Konklusion soll die Besch ftigung mit der Generierung korrekter und minimaler Oberfl chenmodelle zum Abschluss kommen Es wurde herausgestellt dass das Verfahren von Heymann und Degani inklusive der genannten Verbesserungen einen innovativen und n tzlichen L sungsweg f r die Erzeugung von Interfaces darstellt der jedoch Aspekte aufweist die es noch zu evaluieren gilt Das Vorgehen des Reduktionsalgorithmus wurde hinreichend analysiert
80. immer noch durch die Anzahl der Transitionen es ist leicht zu berlegen dass ein normales System viel mehr Transitionen als Zust nde hat Sondern die obere Schranke definiert sich durch die Gr e der gr ten Spezifikationsklasse Es lassen sich generell kaum genaue Annahmen ber die Kardinalit t der gr ten Klasse im Vergleich zu der der Zustandsmenge machen sicherlich kann jedoch ausgesagt werden dass sie bei komplexeren Systemen um ein Vielfaches geringer ist Dar ber hinaus haben die Beispiele verdeutlicht dass in der Regel die Kompatibilit t vieler Zustandspaare schnell ausgeschlossen werden kann Im Gegensatz zu der intuitiven Ableitung einer Benutzungsschnittstelle erm glicht das Verfahren von Heymann und Degani somit einen Gro teil des Betrachtungsgegenstands bereits zu einem fr hen Zeitpunkt vernachl ssigen zu k nnen und erlaubt es dadurch auch f r viele realistische Systeme beweisbar korrekte Interfaces zu generieren the reduction algorithm has been successfully applied to machine models with more than 500 internal states It may be possible by improving the efficiency of our algorithm to reduce even larger machines HEYMANN amp DEGANI 2006 S 25 51 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Ein letzter Punkt der hier angesprochen werden soll ist die Frage nach der Angemessenheit des vom Reduktionsalgorithmus generierten Oberfl chenmodells Da ein allgemeines und
81. inkonsistenten Zustand Warm C HOT Das User Interface besagt offensichtlich dass das System sich im Modus HOT befindet obwohl es tats chlich in einem Zustand der Spezifikationsklasse WARM ist Es handelt sich bei solch einem Zustand um einen error state Given such a display there is nothing we can do to alleviate the problem no additional training no better user manual procedures or any other countermeasures will help HEYMANN amp DEGANI 2006 S 11 Es folgt dass auch dieser Vorschlag f r ein User Interface inkorrekt ist 23 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces heat up Cool A fetele ma Warm AR ALU Hot A Bile cool down cool down A cool cool down cool p heat up Cool B ele Ry Warm BNZEN cool down i Hot B Mills Cool B 10 i heat up T Warm C Ee I E l i i i cool cool down I cool down i I Wwarm c RUGU i Cool C ee By Hot C Bile Abbildung 3 3 10 Zusammengesetztes Modell des Heiz und K hlsystems das einen error state gran hinterlegt aufweist Nat rlich lie e sich das bis hierher verfolgte Vorgehen zum Finden eines korrekten Interfaces weiterf hren indem solange neue Oberfl chenmodelle verifiziert werden bis kein Fehler mehr gefunden wird Ein solcher Ansatz ist aber nicht nur ineffizient und bei h herer Komplexit t der Systeme im schlechten Fall praktisch endlos sondern er m ndet vor
82. ispiel aus HEYMANN amp DEGANI 2006 W hrend dort eine 42 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen ausgehende benutzergesteuerte Transition ud aus dem Zustand 42 in den Zustand 32 f hrt VGL HEYMANN amp DEGANI 2006 S 21 ist der Folgezustand hier 51 Abbildung 4 4 5 Maschinenmodell eines abstrakten Systems inklusive Spezifikationsklassen Die Anwendung des Reduktionsalgorithmus sei hier nicht genauer beschrieben Sie verl uft bis auf die Erzeugung der Transitionen des Oberfl chenmodells ann hernd genauso wie sie in HEYMANN amp DEGANI 2006 beschrieben wird liefert insbesondere die gleiche berdeckung durch maximal kompatible Zustandsmengen Das resultierende Oberfl chenmodell ist in Abbildung 4 4 6 dargestellt Abbildung 4 4 6 Vom Reduktionsalgorithmus berechnetes Oberflachenmodell des abstrakten Systems aus Abbildung 4 4 5 Es zeigt sich dass das benutzergesteuerte Ereignis ud welches aus allen internen Zust nden der Spezifikationsklasse B einen Wechsel in die Klasse A bewirkt im Oberfl chenmodell dutch keine Transition repr sentiert wird Das liegt daran dass weder A 1 noch A 2 alle m glichen Zust nde 43 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen beinhaltet die sich mittels ud aus einem der Zust nde aus B erreichen lassen 31 51 53 ist also weder Teilmenge von 12 21 22 31 32 51 noch von 11 21 22 31 32 53 Daraus
83. it ist Darauf aufbauend werden Ziele f r diesen Bereich des User Interface Designs definiert In Kapitel 3 wird die Modellierung von Maschinen und Oberfl chen durch Zust nde und Ereignisse sowie der Aufgabenspezifikation durch so genannte Spezifikationsklassen vorgestellt Ausgehend von intuitiven Analysetechniken findet sich dann eine ausf hrliche Beschreibung des Verfahrens zur Verifikation eines User Interfaces das am Beispiel eines halbautomatischen Heiz und K hlsystems graphisch und inhaltlich veranschaulicht wird Kapitel 4 behandelt den Kernaspekt dieser Arbeit Die Generierung des Modells der Oberfl che wird als Reduktion des Modells der Maschine herausgestellt au erdem werden mathematische Prinzipien auf die sich der Reduktionsalgorithmus st tzt erl utert Anhand des Heiz und K hlsystems wird die Entwicklung des Oberfl chenmodells Schritt f r Schritt durchlaufen Danach wird aufgedeckt dass das Verfahren in der gegebenen Form nicht korrekt ist und aufgezeigt welche Verbesserungen m glich sind Abschlie end werden die Grenzen des Vorgehens analysiert Kapitel 5 widmet sich der technischen Umsetzung des Software Tools Neben der Architektur und den Funktionalit ten des Systems beschreibt dieser Abschnitt wie sich mit dem Programm der Weg von der Erstellung eines Maschinenmodells bis hin zur Nachbearbeitung des Modells der Benutzeroberfl che umsetzen l sst Eine Zusammenfassung der erarbeiteten Ergebnisse ist schlie lic
84. ktionsalgorithmus anhand eines abstrakten Systems vorgestellt Ob die resultierenden Oberfl chenmodelle wirklich die Korrektheitskriterien erf llen und auch nicht weiter reduziert werden k nnen ist anschlie end Thema von Kapitel 4 4 Wie bereits in Aussicht gestellt wurde wird sich dort untere anderem eine Schwachstelle in der Definition der Spezifikationsklassen zeigen der sich mithilfe einer zus tzlichen Bedingung entgegenwirken l sst 4 3 KONKRETE ANWENDUNG DES ALGORITHMUS ZUR GENERIERUNG VON OBERFL CHENMODELLEN In Kapitel 3 wurde aufgezeigt dass die intuitive Erzeugung eines korrekten und minimalen Oberfl chenmodells schwer durchf hrbar ist Das bereits dort eingef hrte Maschinenmodell des halbautomatischen Heiz und K hlsystems vgl Abbildung 3 3 1 wird nun dazu dienen den soeben behandelten Ablauf des Reduktionsalgorithmus zu demonstrieren Die Berechnung der Zust nde des User Interfaces startet mit den trivialerweise kompatiblen Zustandsmengen welche durch die neun internen Zust nde gegeben sind Anhand dieser wird 31 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen die initiale Resolution der merger table ermittelt Sei zuvor jedoch das Vorgehen der entwickelten Software betrachtet das der folgende Pseudocode zusammenfasst Zur Vereinfachung sei angenommen dass die Zust nde des Maschinenmodells von oben nach unten und links nach rechts durchnummeriett sind Compute the initial re
85. l eines Interfaces im Englischen user model das wie folgt formal definiert ist 13 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces Definition 3 1 2 Oberflachenmodell user model Das Oberflachenmodell eines Systems ist ein endlicher Zustandsautomat der die einem User Interface inklusive aller zugeh rigen Hilfsmaterialien entnehmbaren Informationen beschreibt Es ist formal definiert durch ein 6 Tupel 214 Zoo OY Gy Ores Sa mit e endlichen Eingabealphabeten 2 f r benutzergesteuerte Ereignisse und 2 f r ggf maskierte automatische Ereignisse e einer endlichen Menge Q an Zust nden inklusive eines Startzustands g Q Ubergangsfunktionen 6 0 x X gt Q und I 0 x IY 0 auto Es handelt sich bei amp user um dieselbe Menge wie die des Maschinenmodells Der Zusammenhang zwischen den Eingabealphabeten 2 und 2 auto auto wird in Kapitel 3 3 genauer charakterisiert Wie bereits implizit gesagt erh lt der Benutzer bei dem gegebenen User Interface der Ampel nicht gen gend R ckmeldung um sich jederzeit des Zustands des Systems bewusst zu sein F r das Wissen ber den Erfolg seiner Aktion das Dr cken des Knopfes sollte es also Feedback geben Aus diesem Grund haben gerade in den letzten Jahren viele solcher Fu g ngerampeln oberhalb von Rot und Gr n oder eingebettet in den Druckknopf eine weitere Anzeige erhalten die beispielsweise einen Text wie
86. lls enthalten sind Die Abbildungsvorschrift kann durch Aufteilung von 2 in drei disjunkte Teilmengen X XY und 2 beschrieben werden amp bezeichnet die Menge beobachteter Ereignisse observed events welche tats chlich auch im Oberfl chenmodell sichtbar sind 2 weiter die Menge maskierter Ereignisse masked events Wie bereits angesprochen werden diese gruppiert mit anderen zusammen als ein Ereignis im Oberfl chenmodell aufgef hrt Schlie lich sind die unbeobachteten Ereignisse unobserved events in amp diejenigen welche das Oberfl chenmodell verschweigt Das Eingabealphabet 2 besteht also aus MZY und der Projektion MZ die die durch Maskierung ermittelten Ereignisse verk rpert Au erdem kann m das leere Wort als Repr sentant f r die unbeobachteten Ereignisse angesehen werden Ein M System wird also durch Ereignisse aus 2 automatisch beeinflusst w hrend der Benutzer dies auto durch die angezeigten Ereignisse aus a auto verfolgen kann Die Zustandsentwicklungen des Systems und des User Interfaces verlaufen somit parallel Sie sind jedoch nicht vollends synchronisiert denn das Interface liefert nur einen Ausschnitt aus dem Verhalten des Systems VGL HEYMANN amp DEGANI 2002 I S 12F Das zusammengesetzte Modell wird nun so konstruiert dass es die parallel verlaufenden Prozesse schrittweise nachvollzieht Beginnend bei den beiden Startzust nden werden f r jedes Zustandspaar anhand de
87. ltiert kann ein nicht deterministisches User Interface Verwirrung hervorrufen im Zweifelsfall gar schlimmere Folgen haben In diesem Fall n mlich wird sich die Erwartung bez glich des Folgezustands manchmal best tigen manchmal nicht Nicht Determinismus tritt an vielen Stellen auf und ist oft begr ndet in unzureichender Anzeige oder schlechter Abstraktion Doch er liegt nicht zwangsl ufig aufgrund von Fehlern bei der Entwicklung vor im Gegenteil wenn es der Vereinfachung der Bedienung dient und keinen negativen Einfluss auf die Erf llung der Aufgabe aus bt wird eine Oberfl che oftmals bewusst nicht deterministisch konstruiert So zeigt etwa ein Geldautomat im Voraus nicht in welcher Konstellation von Scheinen das angeforderte Guthaben ausbezahlt werden wird Da dies dem Zweck nicht entgegensteht l sst sich wenig dagegen einwenden Doch sobald Nicht Determinismus die korrekte Bedienung erschwert stellt er eine unn tige Fehlerquelle dar und muss vermieden werden An dieser Stelle sind die wesentlichen Problemtypen die als Grundlagen f r die noch zu formulierenden Ziele dienen ausreichend abgehandelt Es kann daher nun definiert werden welche Anforderungen an eine Benutzungsschnittstelle in diesem Kontext zu stellen sind 2 2 ZIELE HINSICHTLICH DER VERMITTELTEN INFORMATION BEOBACHTBARKEIT ALS ZENTRALE QUALIT T Zusammengefasst f hren die bisherigen Ergebnisse dahin dass ein User Interface so entwickelt werden sollte dass das
88. mation Abbildung 5 1 1 Vereinfachtes Klassendiagramm des implementierten Software Tools Beim Start des Programms erzeugt die main Methode in der Klasse MainControl die MainGUl sowie alle im Klassendiagramm sichtbaren Kontrollklassen Sie ist au erdem f r die n tigen Berechnungen vor dem Lesen oder Schreiben externer Daten verantwortlich deren Ergebnisse dann an die FileControl weitergeleitet werden von wo aus exklusiv nach au en kommuniziert wird Diese speichert und l dt Daten ber die Modelle in Form so genannter properties Dateien Die MainGUI erstellt bei ihrer Initialisierung die Komponenten der Oberfl che Neben den hier nicht dargestellten Klassen f r Men Tool Bar und weitere Steuerungselemente sind das vor allem das MachineModelPanel und das UserModelPanel Diese beiden Klassen erm glichen den Zugriff des Benutzers auf die Modelle und beinhalten jeweils eine Zeichenfl che 54 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen MMGraphicsPanel UMGraphicsPanel f r die Anzeige der Modelle Alle Panels erben von abstrakten Klassen die grundlegende Funktionen anbieten Allgemein implementiert jede Ubergangsklasse das Interface Boundarylnterface das Methoden f r das Setzen des Zustands und sprachspezifische Ausgabewerte aufweist vgl unten Zwei zentrale Klassen im System sind die MachineModelControl und die UserModelControl Erstere reagiert auf Ereignisse die durch Benutzereingaben am Masc
89. moving toward the use of formal methods for specification design and verification interface design will eventually follow suit HEYMANN amp DEGANI 2006 S 25 4 1 PRINZIPIEN DES VERFAHRENS ZUR ENTWICKLUNG EINES OBERFL CHENMODELLS Im vorigen Kapitel wurde vorgestellt wie sich ein konkretes User Interface auf seine korrekte Bedienbarkeit hin analysieren l sst Ausgangspunkt war die Formalisierung des Verhaltens von Systemen und Interfaces durch zustandsbasierte Modelle sowie der Aufgabenanforderung durch Spezifikationsklassen Auch das Verfahren zur Generierung von Oberfl chenmodellen mit dem sich der nun folgende Abschnitt auseinandersetzt geht von diesen Gegebenheiten aus Ihe machine and the user s operational requirements are given Now the problem is to generate an interface and associated user information that enables the user to interact with the machine correctly It is further required that the interface and all user information be as simple and succinct as possible HEYMANN amp DEGANI 2002 I S 4 Es wird sich herausstellen dass diese scheinbar auf empirischen Werten und psychologischen Gesichtspunkten basierende Aufgabe des Interface Designs mittels mathematischer Algorithmen l sbar ist die auf graphentheoretische berlegungen zur ckgehen Bevor das Verfahren anhand mehrerer Beispiele veranschaulicht werden wird werden daher die unterliegenden Konzepte untersucht Das Verfahren selbst wird dann auf abstrakter
90. ner Form aufweisen und diejenigen die aus Design Fehlern des User Interfaces resultieren Insbesondere zweitere sind in dieser Arbeit von Interesse doch stehen sie nicht selten in Verbindung mit den F higkeiten eines Benutzers und so wird im Folgenden auch ein Ausschnitt aus dem Bereich der human factors angesprochen Auf die Behandlung sthetischer Entwurfskriterien wird hingegen ausdr cklich verzichtet da hier die Vermittlung von Information im Mittelpunkt steht Denn sofern nicht prim r die Optik f r das Design ausschlaggebend ist ist Information die Grundlage jedes guten Interfaces nicht sthetik if a product can t be used easily and safely how valuable is its attractiveness NORMAN 1989 S vil Ebenso werden auch ergonomische Gesichtspunkte und solche die das Bewegungssystem der menschlichen Informationsverarbeitung betreffen nicht Thema dieses Textes sein Users interact with systems or tools to achieve certain operational tasks HEYMANN amp DEGANI 2002 I S 2 Im Allgemeinen liegt es nicht in der Absicht eines Benutzers sich mit einem technischen Ger t l nger als n tig auseinanderzusetzen er arbeitet vielmehr ergebnisorientiert Donald A Norman emeritierter Leiter des Instituts f r Kognitionswissenschaften der University 4 Kapitel 2 Grundlegende Probleme und Ziele des User Interface Designs of California spticht in diesem Zusammenhang in seinem Buch The Design of Everyday Things
91. nforderungen eines Fu g ngers basiert Der Benutzer soll einerseits erkennen k nnen ob er die Stra e passieren darf Deswegen befindet sich der Zustand Walk getrennt von allen anderen Zust nden in der Klasse WALK Andererseits muss Feedback bez glich der Benutzeraktion Press gegeben werden das geschieht durch die Aufteilung in die Klassen NOT PRESSED und PRESSED so dass der Benutzer immer wei ob das Dr cken des Knopfes zum gew nschten Ergebnis gef hrt hat Drive 1 Walk Press To Walk I I y C Drive 2 NOR 1 PRESSED PRESSED l Press Abbildung 3 2 2 Maschinenmodell der Fu g ngerampel samt Spezifikationsklassen aus Sicht der Fufg ngers Bei Vergleich mit dem als korrekt vermuteten Oberfl chenmodell aus Abbildung 3 1 3 ist festzustellen dass die Zust nde jeder Klasse anscheinend jeweils komplett zusammengezogen werden k nnen Das ist aber keineswegs der Regelfall wie in Kapitel 3 3 ersichtlich sein wird 16 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces Au er vielleicht an einer Kreuzung entspricht im Allgemeinen nun das Verhalten des Systems einer Fu g ngerampel im Grunde dem der zugeh rigen Ampel f r Autos Die beiden sind unmittelbar miteinander gekoppelt lassen sich letzten Endes als ezn zusammenh ngendes System begreifen Das bekannte Modell der Maschine bezieht sicht also auch nicht nur auf die Fu g ngerampel sondern vielmehr auf das Ampelsystem insgesamt
92. nicht deterministische Transitionen oder Zust nde gleichen Namens zu erstellen ebenso wird etwa die korrekte Eingabe von Zahlenwerten berpr ft Dar ber hinaus wird bei kritischen Operationen wie dem Entfernen von Zust nden oder dem Beenden des Programms ohne Speichern eine Best tigung gefordert Weiter wird der Benutzer bei der Bearbeitung des Maschinenmodells angemessen unterst tzt er erh lt zum Beispiel bei nderung des Namens einer Transition die Wahlm glichkeit nur genau diese Transition zu editieren oder direkt alle gleichen Namens Au erdem sind wie im vorigen Teilkapitel angesprochen stets nur die Funktionen zug nglich die aktuell sinnvoll sind Existiert etwa keine einzige Spezifikationsklasse so sind die Schaltfl chen f r das Hinzuf gen von Zust nden zu einer Klasse oder das Entfernen einer solchen unn tz und werden entsprechend tempor r deaktiviert Nachdem der Editor samt seinen Funktionen ausreichend beschrieben worden ist wird die Benutzung des Programms abschlie end in den einzelnen Schritten demonstriert die zur Erstellung eines Maschinenmodells und der darauf folgenden Generierung und Nachbearbeitung des Oberfl chenmodells zu vollf hren sind Das nun anstehende letzte Teilkapitel l sst sich somit als eine Art Kurzanleitung f r das implementierte Software Tool begreifen 58 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen 5 3 EXEMPLARISCHE ANWENDUNG DER SOFTWARE
93. nis 7 7 T einem der Zust nde S S in eine andere Spezifikationsklasse C f hren Daher k nnten alle Ereignisse 7 internalisiert werden Es ndert sich somit aus Sicht des Benutzers nichts w hrend das System in einem der Zust nde S ist Daraus folgt dass der Benutzer nicht unterscheiden muss in welchem S ein internes Ereignis 6 Z t T auftritt das einen Wechsel in eine andere Spezifikationsklasse ausl st Au erdem gilt nach Definition dass in allen J die gleichen benutzergesteuerten Ereignisse ausgel st werden k nnen Sei nun S der Zustand des Oberflachenmodells welcher die Zust nde S repr sentiert Da belanglos ist in welchem S ein wie oben beschriebenes automatisches Ereignis J ausl sbar ist und alle die gleichen benutzergesteuerten Ereignisse erm glichen kann S niemals einen augmenting state user konstituieren denn nach Algorithmus werden im Oberfl chenmodell automatische Ereignisse die nicht mindestens in einem S aktiv sind ebenso wenig aufgef hrt wie benutzergesteuerte Ereignisse die nicht in allen Zust nden ausl sbar sind Aus den Beweisen von 1 2 3 und 4 folgt unmittelbar die Korrektheit von Satz 4 5 1 Satz 4 5 2 Die Anzahl an Zust nden und Vorkommen von Ereignissen des vom ge nderten Reduktionsalgorithmus berechneten Oberfl chenmodells ist minimal hinsichtlich der Erf llung der geforderten Korrektheitskriterien
94. nnten Transitionen das besprochene Problem im Oberfl chenmodell erkennbar und bildet damit eine sinnvolle Basis f r das User Interface Design 47 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen 4 5 KORREKTHEIT DES REDUKTIONSALGORITHMUS In diesem Teilkapitel geht es darum zu zeigen dass der geanderte Reduktionsalgorithmus korrekt ist also stets ein korrektes und minimales Oberfl chenmodell zu einem gegebenen Modell der Maschine und der formalisierten Aufgabenspezifikation berechnet Satz 4 5 1 Der ge nderte Reduktionsalgorithmus gew hrleistet unter der erweiterten Definition von Spezifikationsklassen Definition 4 4 1 die Einhaltung aller vier geforderten Korrektheitskriterien Beweis von Satz 4 4 2 Es ist zu beweisen dass f r jedes vom Reduktionsalgorithmus berechnete Oberfl chenmodell die vier folgenden Aussagen gelten 1 Das Oberfl chenmodell enth lt keinen error state 2 es enth lt keinen restricting state 3 es enth lt keinen augmenting state und 4 es enth lt keinen concealing state Beweis von 1 Allgemein ist klar dass nur kompatible Zust nde des Maschinenmodells im Oberfl chenmodell durch den gleichen Zustand repr sentiert werden k nnen und dass Zust nde verschiedener Spezifikationsklassen niemals kompatibel sind Daher reicht es zu zeigen dass von zwei kompatiblen Zust nden aus keine Eingabesequenz in Zust nde f hrt die nicht derselben Spezifikationsklasse angeh ren
95. nt des Auftretens des Ereignisses J nichts Das Label e dr ckt dies aus sichtbar in Abbildung 3 3 8 VGL HEYMANN amp DEGANI 2002 S 13 Mit diesen Vorkenntnissen kann nun das verbesserte Modell der Oberfl che siehe Abbildung 3 3 5 des Heiz und K hlsystems aus Abbildung 3 3 1 analysiert werden Die Konstruktion des zusammengesetzten Modells des Heiz und K hlsystems startet beim Zustandspaar Cool A COOL 1 da dies der Ausgangspunkt von Maschine und User Interface ist Das benutzergesteuerte Ereignis heat up bringt das System in den Zustand Warm B passend dazu wird im Interface der Modus WARM aktiv Au erdem kann in Cool A COOL 1 das beobachtete Ereignis cool stattfinden das im Folgezustandspaar Cool B COOL 2 resultiert Abbildung 3 3 9 veranschaulicht diesen ersten Schritt bei der Entwicklung des Modells ER Cool B ele my Abbildung 3 3 9 Ein Schritt der Konstruktion des zusammengesetzten Modells Der weitere Aufbau des gesamten Diagramms sei hier nicht explizit beschrieben es werden einfach nach und nach alle ausgehenden Transitionen aller auftretenden Zustandspaare berpr ft und im Diagramm umgesetzt Es ergibt sich das auf der folgenden Seite abgebildete vollst ndige zusammengesetzte Modell Abbildung 3 3 10 Dort zeigt sich dass auch dieser Versuch der Angabe eines korrekten Oberfl chenmodells gescheitert ist Die Transition heat up f hrt vom Zustandspaar Cool B COOL 2 aus in den grau hinterlegten
96. on voraussagen l sst An dieser Stelle ist wichtig zu sagen dass ein Interface selbst diese Eigenschaften gegebenenfalls nur partiell abdecken muss sofern die Zuhilfenahme von weiteren Materialien wie etwa einer Bedienungsanleitung zur vollst ndigen Erf llung der Kriterien f hrt Es h ngt vom Einsatzgebiet und vom Umfang des Systems ab inwiefern der unweigerliche R ckgriff auf externe Informationsquellen gerechtfertigt sein kann w hrend einfache Alltagsger te im Allgemeinen selbstbeschreibend sein sollten erscheinen Zusatzmaterialien bei sicherheitskritischen Systemen verst ndliche Notwendigkeit zu sein Nachdem im n chsten Kapitel die Repr sentation von User Interfaces durch so genannte Oberfl chenmodelle eingef hrt worden ist k nnen Anleitung und hnliches vernachl ssigt werden da sie unterschwellig in den Modellen integriert sein werden Die soeben angegebene cher inhaltliche Beschreibung des Begriffs Korrektheit ist f r die folgenden Themen allein unzureichend Um die noch vorzustellenden Verfahren von Asaf Kapitel 2 Grundlegende Probleme und Ziele des User Interface Designs Degani und Michael Heymann anwenden zu k nnen bedarf es n mlich einer Definition die sich in mathematischen Modellen ausdr cken l sst und daher technischer Natur sein muss Definition 2 2 1 Korrektheit eines Interfaces interface correctness VGL HEYMANN amp DEGANI 2006 S 9 Ein User Interface inklusive aller zugeh rigen Hil
97. ool B Cool C Warm A Warm B Warm C Hot A Hot B Abbildung 4 3 4 Endgiiltige Resolution der merger table Das hei t die Resolutionsmethode hat vier kompatible Zustandspaare herausgearbeitet n mlich Warm A Warm B Hot A Hot B Hot A Hot C und Hot B Hot C Alle anderen Zust nde d rfen zur Gew hrleistung der Beobachtbarkeit des Systems niemals zusammengefasst werden insbesondere darf entgegen den in Kapitel 3 3 vermuteten Oberfl chenmodellen keiner der Zust nde aus COOL verheimlicht werden Die Zustandspaare werden am Ende der Methode resolve_merger_table_iteratively erzeugt und anschlie end zur ckgegeben Doch stellen sie noch nicht zwangsl ufig die maximal kompatiblen Zustandsmengen dar welche gesucht sind um das Maschinenmodell bestm glich zu reduzieren Offensichtlich sind Hot A Hot B und Hot C paarweise kompatibel weswegen es sich bei Hot A Hot B Hot C um eine kompatible Zustandsmenge der Gr e 3 handelt Warm A Warm B ist hingegen maximal denn es existiert kein weiteres Paar derselben Spezifikationsklasse Das intuitive Erkennen kompatibler Zustandsmengen ist f r kleine Beispiele leicht wird ab einer gewissen Gr e der Zustandsmengen jedoch un bersichtlich Wie geht also ein Algorithmus im 35 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen Allgemeinen vor Das rekursive Verfahren des entwickelten Software Tools zur Berechnung der kompatiblen Zustandsmengen ist im folgenden Ps
98. r gew nschte Ort zum Sichern bestimmt und der Name der Datei eingegeben werden kann Als Default Extension wird wie erw hnt od angezeigt im Bedarfsfall kann aber auch eine andere Endung benutzt werden Beim n chsten Lade oder Speichervorgang wird der zuvor ausgew hlte Ordner direkt wieder aufgerufen Das vorgestellte Beispiel sollte als Einstieg in die Bedienung des Software Tools dienen Es hat einen typischen Ablauf beim Entwurf des Maschinenmodells aufgezeigt der sich aber genauso gut an vielen Stellen abwandeln lie e Dar ber hinaus sind nicht alle Bedienelemente und Funktionen zum Tragen gekommen nichtsdestotrotz m sste die Benutzung des Programms von hier an intuitiv und ohne weitere Erkl rung m glich sein Zusammen mit der Java nahen Beschreibung der internen Strukturen und Abl ufe und dem berblick ber die Funktionen seien die Eigenschaften der Software damit ausreichend behandelt Das Ende dieses Kapitels bezeichnet im Grunde ebenso das Ende des inhaltlichen Teils der Arbeit Das folgende Kapitel fasst die wesentlichen Erkenntnisse und Ergebnisse dieser Arbeit noch einmal zusammen Au erdem wird ein Ausblick auf m gliche Erweiterungen der Software sowie insbesondere auf noch zu behandelnde Themen bez glich des Verfahrens zur Generierung von korrekten und minimalen Oberfl chenmodellen gegeben 63 Kapitel 6 Zusammenfassung und Ausblick 6 ZUSAMMENFASSUNG UND AUSBLICK good interface design is all abou
99. r dort definierten ausgehenden Transitionen die nachfolgenden Paare ermittelt Um etwaige Fehler des Oberfl chenmodells aufdecken zu k nnen sind die berg nge des Modells mit Ereignissen aus 2 auto gelabelt denn die Situation wird aus Sicht des Benutzers betrachtet Sei etwa angenommen das System ist im Zustand S das Interface im entsprechenden Zustand T Im Maschinenmodell f hre eine automatische Transition J von S zu einem Zustand S Wenn ein beobachtetes Ereignis ist also M p gilt so muss auch im Oberflachenmodell eine Transition von T zu einem Zustand T vorhanden sein Daher enth lt das zusammengesetzte Modell eine mit J gelabelte Transition von S T nach S T wie Abbildung 3 3 6 verdeutlicht Ist 6 hingegen maskiert so handelt es sich bei M um das maskierte Abbild von Das Oberfl chenmodell beinhaltet einen bergang II von T nach T ebenso f hrt also wieder im zusammengesetzten Modell Abbildung 3 3 7 eine Transition von S T nach S T Abbildung 3 3 7 Maskiertes Ereignis im zusammengesetzten Modell 22 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces Abbildung 3 3 8 Unbeobachtetes Ereignis im zusammengesetzten Modell Falls jedoch als letzte M glichkeit unbeobachtet ist dann wird in T kein Zustandswechsel ausgel st der zu T schaltet Der Folgezustand von S T ist also S T denn f r den Benutzer ndert sich im Mome
100. r einen Seite diese Verfahren vorzustellen sie formal zu beschreiben und anschaulich zu erl utern Vor allem die Generierung von Interfaces steht hierbei im Fokus Dieser Teil basiert auf den Papern Formal Analysis and Automatic Generation of User Interfaces Approach Methodology and an Algorithm HEYMANN amp DEGANI 2006 sowie On Abstractions and Simplifications in the Design of Human Automation Interfaces HEYMANN amp DEGANI 2002 I Er wird dar ber hinaus aber um weitere Quellen sowie eigene Erarbeitungen erweitert werden die sich insbesondere mit der vermeintlichen Korrektheit und der Anwendbarkeit des Generierungsverfahrens besch ftigen Auf der anderen Seite ist im Rahmen dieser Arbeit ein Software Tool zu entwickeln mit dem sich das Modell einer Maschine in einem graphischen Editor erstellen l sst um daraus anschlie end mittels des angesprochenen Verfahrens ein korrektes und minimales Modell der zugeh rigen Bedienungsoberfl che automatisch generieren zu k nnen Die Umsetzung der Algorithmen und technische Hintergr nde sind ebenfalls Inhalt des schriftlichen Teils und stellen somit die Verbindung zwischen Text und Programm dar Kapitel 1 Einleitung 1 3 GLIEDERUNG Kapitel 2 behandelt m gliche Fehlerquellen bei der Interaktion zwischen Mensch und Maschine die im vorliegenden Kontext relevant sind Es wird herausgearbeitet dass die Beobachtbarkeit eines Systems von zentraler Bedeutung f r dessen Benutzbarke
101. rflachenmodellen Der erste Schritt des Verfahrens besteht nun darin alle kompatiblen Zustandsmengen ausfindig zu machen da sie die Basis f r die Reduktion des Maschinenmodells bilden Dabei ist zu beachten dass Kompatibilit t intransitiv ist das hei t etwa aus der Existenz eines kompatiblen Zustandspaars S S und eines weiteren S S kann im Allgemeinen keineswegs geschlossen werden dass auch und kompatibel sind Einerseits folgt hieraus dass eine Menge von Zust nden nur dann kompatibel ist wenn ihre Elemente paarweise kompatibel sind That is a state triple is compatible if its three constituent state pairs are compatible a state quadruple is compatible if its four constituent triples are compatible and so on HEYMANN amp DEGANI 2006 S 19 Andererseits zeigt sich dass die kompatiblen Zustandsmengen innerhalb eines Systems berlappungen haben k nnen In Kapitel 4 3 wird solch ein Modell vorgestellt Gesucht sind nun nicht alle kompatiblen Zustandsmengen sondern nur diejenigen deren Umfang nicht erweiterbar ist Definition 4 1 3 Maximal kompatible Zustandsmenge maximal compatible state set VGL HEYMANN amp DEGANI 2002 I S 18 Eine kompatible Menge an Zust nden eines Systems ist maximal wenn sie keine echte Teilmenge einer anderen kompatiblen Zustandsmenge ist Ein Zustand des durch den Reduktionsalgorithmus erhaltenen Oberfl chenmodells entspricht genau einer maximal kompatiblen Zustandsmenge
102. rgestellt wird Abbildung 3 3 1 zeigt das Maschinenmodell eines halbautomatischen Heiz und K hlsystems das bereits die Spezifikation dreier f r den Benutzer zu unterscheidenden Modi enth lt COOL WARM und HOT Jede dieser Spezifikationsklassen umfasst wiederum drei interne Zust nde zwischen denen das System bei Bedarf automatisch hin und herwechselt Grund f r diese Wechsel sind externe Temperaturschwankungen auf die das System reagiert was hier aber nicht von Interesse sein wird Hingegen ist wichtig dass f r das Triggern einer Transition innerhalb von COOL sowie zwischen Warm A und Warm B die Ereignisse cool und cool verantwortlich sind w hrend zwischen Warm B und Warm C genauso wie in HOT eine Zustands nderung das vorherige Auftreten von hot oder hot impliziert Der Benutzer kann die gew nschte Stufe des Systems durch zwei Steuerungselemente einstellen die das Schalten der entsprechenden Transitionen bewirken heat up f hrt wenn m glich zu einem Erw rmen der Umgebung cool down verringert andersherum die Temperatur cool down cool down heat up hot hot hi cool down I T 4 cool down Hot B HOT it it cool down hot cool cool down hott heat up Abbildung 3 3 1 Maschinenmodell eines halbautomatischen Heiz und K hlsystems inklusive Spezifikationsklassen Es ist nun ein Interface erforderlich das dem Benutzer erlaubt den aktuellen und n chsten Modus des Heiz und
103. rliegende Beispiel sei eine Partition der Zust nde in State1 State2 und State3 State4 vorgenommen Benannt werden die Klassen hier entsprechend 1 AND 2 und 3 AND 4 Die Erstellung der ersten Spezifikationsklasse ist in Abbildung 5 2 6 zu schen OA 9 FAR nachine model pusern Create new specification class in Name of the class to create 1 AND 2 A Abbrechen OK LY Abbildung 5 2 6 Erstellung einer Spezifikationsklasse Als Konsequenz der Existenz von Spezifikationsklassen sind alle Schaltfl chen des Tool Bars aktiviert Neben der Schaltfl che Neue Klasse erstellen finden sich von links nach rechts 61 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen Schaltfl chen f r das Hinzuf gen eines Zustands zu einer Klasse das Entfernen eines Zustands aus einer Klasse und das L schen einer Klasse Abbildung 5 2 7 Ihre Bedienung wird hier nicht vorgestellt eine Kurzbeschreibung des dabei n tigen Vorgehens ist aber wie angesprochen im unteren rechten Bereich der Oberfl che nachlesbar Lanyuaye gt N X L i BE ES PER user model Abbildung 5 2 7 Vier Schaltfl chen rechts f r den Umgang mit Spezif kationsklassen Die Konstruktion des Maschinenmodells endet an diesem Punkt Demzufolge kann jetzt das Oberfl chenmodell generiert werden Hierf r wird unter dem Men punkt Generate zuvor noch die Funktion R
104. s ffentlichen wie auch privaten Lebens ist in heutigen Tagen ohne die Einbindung technischer Ger te vorstellbar Im eigenen Wohnzimmer in Gesch ften und Banken in ffentlichen Geb uden und insbesondere auch am Arbeitsplatz ist der Mensch auf die Interaktion mit Maschinen und Programmen angewiesen Einfache Heim und Alltagsgerate wie Fernseher Mikrowelle Geld oder Fahrkartenautomat ebenso wie komplexe Systeme die sich beispielsweise in Handys Fahrzeugen und Personal Computern finden lassen haben dabei eins gemeinsam der Benutzer interagiert mit der Maschine ber eine Schnittstelle Solch ein User Interface sei es die virtuelle Oberfl che eines Programms oder die Kn pfe und Anzeigen eines Bedienpults l sst sich als Abstraktion des unterliegenden Systems begreifen Diese Abstraktion ist notwendig denn oftmals beinhalten die systeminternen Abl ufe hunderte wenn nicht gar tausende von Zust nden die durch zahlreiche manuell gesteuerte oder automatisch auftretende interne und externe Ereignisse beeinflusst werden F r die Erf llung der Aufgaben ist in der Regel jedoch nur ein sehr geringer Ausschnitt der enthaltenen Informationen relevant Eine Oberfl che zeigt dem Benutzer also bestimmte Daten verbirgt andere vor ihm Die Ausgabe dient dem Benutzer als Information die er zur Steuerung des Systems ben tigt und auch die M glichkeiten des Einflusses auf das Verhalten h ngen unmittelbar von den Gegebenheiten des User Inter
105. s Vorhaben wurde auch erfolgreich vollzogen Dennoch fehlen einzelne der Benutzbarkeit f rderlichen Produktcharakteristiken wie etwa eine Undo Redo Funktion oder eine umfassendere Online Hilfe Auch w rde eine Erweiterung der Darstellung der Modelle um die Notation als Statechart Diagramme dem Benutzer helfen komplexe Systeme besser berschauen zu k nnen Derlei Qualit tsmerkmale wurden bisher nicht umgesetzt weil sie nicht der direkten Thematik angeh ren und den Umfang der Arbeit berstiegen h tten 65 Anhang ANHANG EIDESSTATTLICHE ERKLARUNG Ich versichere dass ich die vorliegende Arbeit selbststandig und ohne unerlaubte fremde Hilfe sowie ohne Verwendung anderer als der im Literaturverzeichnis angegebenen Quellen angefertigt habe Alle Ausf hrungen die w rtlich oder sinngem bernommen wurden sind als solche gekennzeichnet Der Inhalt der Arbeit hat meines Wissens in gleicher oder hnlicher Form noch keiner anderen Pr fungsbeh rde vorgelegen Paderbotn den 10 November 2006 AUF DER BEIGEF GTEN CD ENTHALTEN Dieser Arbeit ist eine CD ROM beigef gt auf der sich das erstellte Software Tool und weitere Materialien befinden Im Einzelnen enth lt die CD die folgenden Daten Auf oberster Ebene liegt die implementierte Software als ausf hrbare JAR Datei mit dem Namen ModelTool_1_0 jar sowie eine PDF Version der vorliegenden Arbeit die WachsmuthSA pdf hei t s Im Ordner examples sind die in der
106. s zur automatischen Generierung solcher Interfaces noch genauer eingegangen Nachdem die notwendigen Fachbegriffe determiniert worden sind kann das Ziel f r die vorliegende Thematik in einem Satz beschrieben werden Um bestm gliche Vermittlung von Information und daraus resultierend Bedienbarkeit zu garantieren ist ein User Interface so zu konstruieren dass es erstens korrekt und zweitens minimal ist Vor diesem Hintergrund wird es als n chstes darum gehen eine konkrete Schnittstelle auf ihre Korrektheit hin zu analysieren um sich anschlie end der Fragestellung zu widmen inwiefern sich eine korrekte und minimale Bedienungsoberfl che aus einem gegebenen System und seinen Anforderungen formal ableiten l sst 10 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces 3 ANALYSE UND VERIFIKATION DER KORREKTHEIT VON USER INTERFACES even for machines that are seemingly simple finding a correct interface and user model is not a trivial matter HEYMANN amp DEGANI 2002 I S 30 3 1 BESCHREIBUNG VON SYSTEMEN UND USER INTERFACES DURCH ZUSTANDSBASIERTE MODELLE Wie das vorige Kapitel herausgestellt hat beschaftigt sich diese Arbeit mit der Beobachtbarkeit der Zust nde eines technischen Ger ts oder Programms Innerhalb dieser Problematik l sst sich die Anzeige zur Laufzeit durch Eingabe oder Berechnungen entstandener Daten vernachl ssigen Auch auf die explizite Angabe von Referenzwerten kann verzichte
107. sentiert durch das Maschinen und das Oberfl chenmodell m ssen stets synchron bleiben inkonsistente Zust nde also vermieden werden Genauer gesagt das Oberfl chenmodell darf weder error states noch restricting states noch augmenting states aufweisen Es ist also gefordert dass der im Interface angezeigte Zustand nach jeder beliebigen m glichen Ereignissequenz konform mit dem internen Zustand des Systems ist Das Verfahren dient nun dazu ein zusammengesetztes Modell zu erstellen das die Abbildung aller m glichen Ereignissequenzen gleichzeitig f r das Maschinen und das Oberfl chenmodell leistet Anhand der dabei entstehenden Zustandspaare bestehend aus System und Interface Zustand l sst sich beurteilen ob einer der fehlerhaften Zustandstypen vorliegt Wenn ein Zustandspaar existiert bei dem der Zustand des Systems einer anderen Spezifikationsklasse angeh rt als der des User Interfaces so stellt dies einen error state dar Findet sich eine ausgehende Transition des Zustands des Maschinenmodells die einen Wechsel der Spezifikationsklasse bewirkt und die f r den zugeh rigen Zustand des Oberfl chenmodells nicht definiert ist so begr ndet der Interface Zustand einen restricting state im umgekehrten Fall handelt es sich handelt es sich entsprechend um einen augmenting state Definition 3 3 1 Zusammengesetztes Modell composite model Das zusammengesetzte Modell eines Systems ist ein endlicher Zustandsautomat der die glei
108. sition wie die von 03 nicht internalisiert wird Daher wird nun ein weiteres Korrektheitskriterium eingef hrt das sich der Vermeidung von Zust nden widmet die m gliche interne Ereignisse verheimlichen welche einen Wechsel des Zustands des Interfaces nach sich ziehen Definition 4 4 1 Erweiterte Korrektheit von User Interfaces Ein User Interface inklusive aller zugeh rigen Hilfsmaterialien ist erweitert korrekt wenn es Definition 2 2 1 gen gt und kein wie folgt definierter Zustand existiert e concealing state Das System kann einen Zustandswechsel des User Interfaces ausl sen der vom User Interface und den Hilfsmaterialien verschwiegen wird Satz 44 3 Der Reduktionsalgorithmus gew hrleistet nicht die Vermeidung von concealing states Beweis von Satz 4 4 3 ber Widerspruch Angenommen der Algorithmus vermeidet concealing states Dann h tte er im gerade angef hrten Beispiel 03 nicht internalisieren d rfen Die Annahme muss also falsch sein was den Satz beweist E Wie kann nun der Reduktionsalgorithmus der Vermeidung von restricting states und concealing states gerecht werden Offensichtlich werden Ereignisse f lschlicherweise ausgeblendet wenn kein richtiger Folgezustand ausgemacht wird Beim ersten Schritt des Festsetzens der Transitionen werden Ereignisse wie eben ud und 03 also gar nicht erst erzeugt Ins Allgemeine bertragen wird ein ausgehendes Ereignis J von kompatiblen Systemzust nden S bei dem sie des
109. solution of the merger table PROCEDURE compute_initial_resolution states classes transitions VAR mergerTable new MergerTable states states FOR i 1 TO states DO FOR j 0 TO i 1 DO IF classes states i classes states j THEN mergerTable i j Incompatible ELSE IF transitions states i user triggered transitions states j user triggered THEN mergerTable i j ELSE mergerTable i j compute_initial_related_state_pairs states i states j transitions Incompatible RETURN mergerTable Die IF Bedingungen regeln also dass eine Zelle als inkompatibel markiert wird wenn die zwei zugeh rigen Zust nde nicht der gleichen Spezifikationsklasse angeh ren oder nicht dieselben ausgehenden benutzergesteuerten Transitionen aufweisen F r alle verbleibenden Zustandspaare werden die Zellen mit den Zustandspaaren gef llt die sich durch Ausl sen eines gemeinsamen Ereignisses erreichen lassen compute_initial_related_state_pairs Die initiale merger table besteht aus 36 9 8 2 Zellen und ist in Abbildung 4 3 1 dargestellt Cool B Warm B Warm CoolB Cool C Warm Hot 6 Cool C B Hot Warm B HOLE enot A Cool Warm A Incompatible Incompatible Incompatible Warm B Incompatible Incompatible Incompatible Warm C Incompatible Incompatible Incompatible ot A Hoti Hot A Hot C Cool A Cool B Cool A Cool B Hot A
110. stellen und in einem graphischen Software Tool umzusetzen Dar ber hinaus deckt die Arbeit Fehler im Verfahren auf welche zu User Interfaces f hren die nicht den Forderungen von Heymann und Degani gerecht werden Anschlie end werden Verbesserungen aufgezeigt aus denen die Korrektheit des Verfahrens folgt Inhaltsverzeichnis INHALTSVERZEICHNIS 1 EINLEITUNG E uw demetuces toa Sudadewauwecheve sadodees snus aveseddgesesuddesees 1 1 1 Motivation Einf hrung in das Thema 1 22 Ziele dieser Arbeit 2er arten ieh AR R a A E a a 1 3 Gliederung sr Eee 3 2 GRUNDLEGENDE PROBLEME UND ZIELE DES USER INTERFACE DESIGNS sscceesseees 4 2 1 Menschliches Handeln und daraus resultierende Fehlerquellen unsnsnenenensensensensensenennennennennennensensnnnn 4 2 2 Ziele hinsichtlich der vermittelten Information Beobachtbarkeit als zentrale Qualit t eeeeeene 7 3 ANALYSE UND VERIFIKATION DER KORREKTHEIT VON USER INTERFACES ceereeeneeeneenn 11 3 1 Beschreibung von Systemen und User Interfaces durch zustandsbasierte Modelle 11 3 2 Spezifikationsklassen als Formalisierung der Aufgabenanforderung nnnsnsnsnennensensensensenenenennensensennenns 15 3 3 Verfahren zur Verifikation des User Interfaces einer Maschine 4 GENERIERUNG VON KORREKTEN UND MINIMALEN OBERFLACHENMODELLEN 25 4 1 Prinzipien des Verfahrens zur Entwicklung eines Oberfl chenmodells usnsnsnenenennennensensensennene 25
111. t revealing the underlying structure to the user and averting surprise DEGANI A 2004 S 138 Menschen arbeiten mit Maschinen um bestimmte Aufgaben zu erf llen Fehler treten dort auf wo der Benutzer nicht versteht was im System passiert oder wo die kognitive Belastung die F higkeiten des Benutzers bersteigt Beobachtbarkeit stellt sich als zentrale Qualit t f r die Vorbeugung gegen ber solchen Gefahrenquellen heraus Der Benutzer muss auf der einen Seite zu jedem Zeitpunkt ausreichend dar ber bescheid wissen in welchem Zustand sich das unterliegende System befindet und welchen es in Abh ngigkeit zur n chsten Aktion oder m glichen internen Ereignissen erreicht Ein System das diesen Forderungen gerecht wird hei t korrekt Auf der anderen Seite sollten f r die Bedienung irrelevante Informationen ausgeblendet werden da sie dem Zweck der Konzentration auf die Aufgabe entgegenstehen Kapitel 2 Technische Ger te und Programme wie auch deren User Interfaces lassen sich f r die Analyse der Beobachtbarkeit als Zustands bergangsdiagramme modellieren Weiter stellt die Einteilung der Zust nde des Systems in Spezifikationsklassen eine Formalisierung der Aufgabenspezifikation dar die besagt welche Zust nde f r einen Benutzer zumindest inhaltlich das gleiche bedeuten Gegeben ein zustandsbasiertes Modell eines Systems samt einer solchen Aufgabenspezifikation bietet eine von Michael Heymann und Asaf Degani vorgestellte Methode d
112. t Diagramm l sst sich in einen quivalenten Zustandsautomaten umwandeln und umgekehrt We consider machines that interact with their human users interact with the environment and can act automatically HEYMANN amp DEGANI 2006 S 5 Zust nde der gerade beschriebenen Diagramme repr sentieren interne Konfigurationen oder Modi solcher Maschinen Transitionen stehen f r diskrete Zustandswechsel die durch benutzergesteuerte oder automatisch auftretende Ereignisse ausgel st werden Automatische Transitionen k nnen durch die Erf llung interner 11 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces Bedingungen getriggert werden oder durch externe Ereignisse der Umgebung zum Beispiel wenn eine Temperatur nderung dazu f hrt dass ein Heizsystem aktiviert oder deaktiviert wird Im vorliegenden Kontext wird jedoch nicht zwischen diesen Arten von automatischen Ereignissen unterschieden benutzergesteuerte Transitionen werden als durchgezogene Pfeile automatische Transitionen als gestrichelte Pfeile dargestellt VGL HEYMANN amp DEGANI 2002 I S 6 Au erdem ist anzumerken dass die wichtige Frage welche internen Ereignisse quivalent sind einem Problemfeld dem der Systementwicklung angeh rt das hier au en vor bleiben soll Sei nun also das Modell einer Maschine betrachtet Abbildung 3 1 1 zeigt das unterliegende Verhalten einer Druckknopf gesteuerten Fu g ngerampel In dem als solchem markierten b
113. t ist Daher erweist sich die sinnvolle Abstraktion also der Prozess des Analysierens welche Daten wesentlich und welche unwesentlich sind als ein fundamentaler Aspekt des User Interface Designs der letztlich zur Festlegung der im Interface anzuzeigenden Informationen f hrt vgl HEYMANN amp DEGANI 2006 S 2 1 2 ZIELE DIESER ARBEIT Die gegenw rtige Situation besteht darin dass die Erzeugung eines User Interfaces keinen formal definierten Methoden folgt sondern auf intuittvem Vorgehen beruht was die Gew hrleistung der Benutzbarkeit u erst schwierig gestaltet Currently this abstraction is performed in a heuristic and intuition based manner and its evaluation process usually involves many interface design iterations costly simulations and extensive testing HEYMANN amp DEGANI 2006 S 3 Michael Heymann vom Technion Israel Institute of Technology und Asaf Degani haben nun j ngst zwei Verfahren zur Verifikation und zur Generierung von User Interfaces entwickelt W hrend das eine dazu dient konkrete Schnittstellen auf ihre korrekte Abstraktion bez glich des zugeh rigen Systems hin zu untersuchen soll das andere erm glichen zu einer gegebenen Maschine und der Aufgabenanforderung automatisch eine korrekte und minimale Schnittstelle zu erzeugen Dabei werden Maschinen und Programme mittels Zustands bergangsdiagrammen modelliert und durchlaufen danach mathematische Algorithmen Ziel der vorliegenden Arbeit ist auf de
114. t ist Techniken aufzuzeigen mit denen sich der Weg von der Maschine repr sentiert durch das Maschinenmodell hin zum User Interface beschreiten l sst Eine Schnittstelle enth lt in der Praxis eine Steuerungseinheit mit der der Benutzer die 12 Kapitel 3 Analyse und Verifikation der Korrektheit von User Interfaces n tigen Eingaben t tigt und eine Anzeigeeinheit durch die dem Benutzer Informationen ber das System mitgeteilt werden Formaler betrachtet besteht ein Interface zusammen mit der Anleitung etc aus einer Auflistung und Beschreibung der f r den Benutzer erkennbaren Ereignisse Da ein Interface eine Abstraktion des unterliegenden Systems verk rpert beinhaltet dies nur einen Ausschnitt der automatischen Ereignisse und selbige unter Umst nden auch maskiert also als ei nach au en getragenes Ereignis VGL HEYMANN amp DEGANI 2002 I S 7F Dem entgegen geh ren nat rlich alle benutzergesteuerten Ereignisse dazu It is noteworthy that events der se cannot be displayed in the interface What can be displayed is some consequence of their occurrence HEYMANN amp DEGANI 2002 I S 8 Wie sieht nun das User Interface einer Fu g ngerampel aus die mithilfe eines Knopfes bedient wird Abbildung 3 1 2 stellt auf der linken Seite die komplette Anzeigeeinheit einer typischen Fu g ngerampel dar der Knopf der Ampel hat also selbst keine weitere Anzeige In dieser Form sind Fu g ngerampeln oft im Stra enverkehr vorz
115. t werden Ein Referenzwert ist ein Parameter der der internen Logik eines Systems zur Steuerung seines Verhaltens dient VGL DEGANI 2004 S 96 Beispiele f r Referenzwerte sind unter vielen anderen die Systemzeit eines Personal Computers die Temperatur einer Herdplatte oder die Flugh he eines Airliners Zwar kann es von Bedeutung sein die Schwellen eines solchen Wertes zu kennen etwa wenn sie zur Erf llung interner Bedingungen f hren in deren Konsequenz ein Zustandswechsel ausgel st wird Das stetige Wissen ber genaue Werte ist jedoch f r das Beobachten des Zustands im Allgemeinen unerheblich Aus diesen Gr nden bedarf es hier nicht der Beschreibung von Maschinen und Interfaces in der Weise wie es eine Turingmaschine leistet Das hei t es besteht nicht die Notwendigkeit auf ein unendliches Ged chtnis zur ckgreifen zu k nnen In diesem Fall m sste man n mlich diese Forderung auch an den Benutzer stellen Vielmehr ist hingegen eine Modellierung durch endliche Automaten in der Form von Zustands bergangsdiagrammen ausreichend Im Folgenden wie auch in dem im Rahmen dieser Arbeit entwickelten Software Tool vgl auch Kapitel 5 wird sich dabei auf flache Zustandsautomaten beschr nkt spezielle superstates oder history states wie sie in der von David Harel begr ndeten Notation der Siatecharts auftauchen VGL HAREL 1987 werden somit nicht verwendet Dies stellt keine Verminderung der Aussagekraft dar denn jedes Statechar
116. t worden um es im Gesamten betrachten zu k nnen 800 Set display options Font size of states 14 W Font size of transitions 12 f Font size of classes 12 W Width of work space 1024 N Height of work space 768 Cancel Confirm changes gt Abbildung 5 2 2 Dialog zur Einstellung von Darstellungsoptionen Die Generierung eines Oberfl chenmodells l sst sich nun wahlweise ber die Schaltfl che ganz rechts im Tool Bar vgl Abbildung 5 2 1 oder ber einen Men punkt im Men Generate starten Alle Berechnungen geschehen bis einschlie lich der Anzeige des Modells dann ohne Eingriff des Benutzers Wie bereits in Kapitel 4 erw hnt k nnen jedoch vorher Optionen f r das Vorgehen festgelegt werden Abbildung 5 2 3 auf der folgenden Seite zeigt den Inhalt des Men punkts Generate Aktuell eingestellte Optionen werden durch einen Punkt davor genauer gesagt einem radio button markiert in der Abbildung sind dies die initialen Einstellungen 57 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen MUAYTHALIL HILOL WIVUCTIETNZ VVI La View Language Generate user model Eingabe I N IE s Delete superfluous automatic self loops St E model Delete all automatic self loops A e Arrange states according to the classes et Rasterize arrangement of states XT4 Cola Method of Heymann and Degani x05 CO Avoid restricting states and concealing states X06 m T
117. taControl und gibt den zu setzenden Zustand an die bergangsklassen weiter Exemplarisch werde hier noch der Ablauf beim Generieren des Oberfl chenmodells beschrieben um einen fl chtigen Einblick in die Funktionsweise des Systems zu geben Bet tigt der Benutzer die zugeh rige Schaltfl che so wird von der MainGUI aus die entsprechende Methode in der UserModelControl aufgerufen Die UserModelControl erfragt daraufhin Daten bei der DataControl und f hrt den Reduktionsalgorithmus aus W hrend der einzelnen Schritte des Algorithmus werden ber die DataControl mehrere Male neue Daten wie die der Zust nde des Oberfl chenmodells UserStatelnformation erstellt Anschlie end wird die MainGUI zur Anzeige des Modells in der Benutzeroberfl che beauftragt deren Zustand zuletzt die GUIStateControl anpasst Dieses Teilkapitel sollte lediglich einen berblick ber die technische Seite des Software Tools geben Ausgew hlte Teile der Umsetzung des Reduktionsalgorithmus wurden au erdem schon in Kapitel 4 in Form von Pseudocode dargestellt Eine fundierte Er rterung der Implementierung ist nicht Inhalt der Arbeit Die Funktionalit ten des Programms werden im Folgenden anhand der Bedienungsoberfl che vorgestellt Dabei werden alle wesentlichen Steuerungsm glichkeiten und Anzeigen welche f r die Benutzung des Programms wichtig sind aufgelistet Ihr konkreter Einsatz wird zumindest partiell hinterher in Kapitel 5 3 besprochen 55 Kapitel 5
118. te Die Annahme muss also falsch gewesen sein was zu zeigen war Aus den Beweisen von 1 und 2 folgt unmittelbar die Korrektheit von Satz 4 5 2 Satz 4 5 3 Der ge nderte Reduktionsalgorithmus ist unter der erweiterten Definition von Spezifikationsklassen Definition 4 4 1 erweitert korrekt Definition 4 4 2 Beweis von Satz 4 5 3 Die Korrektheit des Reduktionsalgorithmus folgt direkt aus den Beweisen von Satz 4 5 1 und Satz 4 5 2 E Der Korrektheitsbeweis zeigt dass das in den vorigen Teilkapiteln beschriebene Verfahren eine M glichkeit liefert das Design eines Interfaces formal durchzuf hren Ebenso rechtfertigt er die Bezeichnung der in Kapitel 4 3 entwickelten Oberfl chenmodelle als korrekt und minimal An dieser Stelle angekommen stellt sich letzten Endes die Frage inwiefern der Algorithmus auf realistische Systeme anwendbar ist Abschlie end besch ftigt sich Kapitel 4 6 deshalb mit den Grenzen des Verfahrens wobei insbesondere die worst case Laufzeit des Algorithmus eine Rolle spielen wird 4 6 GRENZEN DER ANWENDBARKEIT DES VERFAHRENS Eine erste Einschr nkung die im Rahmen dieser Arbeit herausgearbeitet wurde ist bereits durch die Eingabe des Algorithmus gegeben Einerseits wird gefordert dass das zu reduzierende System in Form eines Modells vorliegen muss welches eine Spezifikation von Zust nden und diskreten Ereignissen voraussetzt Andererseits und dies wiegt im Zweifelsfall noch schwerer wird eine
119. tion bezieht und daher in diesem Zusammenhang vernachl ssigt wird Here the emphasis is on questions regarding what information must be provided to the user and when rather than on how this information is provided HEYMANN amp DEGANI 2002 I S 5 Uber die Beobachtbarkeit hinaus muss nat rlich zus tzlich gegeben sein dass der Benutzer zu jedem Zeitpunkt Kontrolle ber das System hat und sich insbesondere die Aufgaben f r die das System konzipiert wurde stets erf llen lassen Wie bereits erw hnt ist die prim re Forderung der ein User Interface im vorliegenden Kontext zu gen gen hat Korrektheit Korrektheit meint dass die Schnittstelle gew hrleistet dass der Benutzer das System korrekt bedienen kann um seine Absichten umzusetzen Diese Eigenschaft soll nun formalisiert werden denn in Kapitel 3 wird es genau darum gehen die Korrektheit einer Schnittstelle in Bezug auf die zugeh rige Maschine zu verifizieren und ebenso verk rpert sie eins der beiden Ziele der automatischen Generierung Kapitel 4 Unter der einzigen Annahme dass das Verhalten der Maschine deterministisch ist und die Aufgaben des Benutzers mit ihr erf llbar sind VGL HEYMANN amp DEGANI 2006 S 9 leitet sich Korrektheit direkt aus der Qualit t der Beobachtbarkeit ab Eine Benutzungsschnittstelle ist korrekt wenn der aktuelle Zustand des unterliegenden Systems bekannt ist und sich der n chste Zustand in Abh ngigkeit zur n chsten Akti
120. tionsklasse angeh ren und die gleichen Aktionen 49 Kapitel 4 Generierung von korrekten und minimalen Oberflachenmodellen des Benutzers erlauben m ssen kann dies nur im Resolutionsprozess passiert sein Dort werden J und aber nur dann als inkompatibel markiert wenn eine von ihnen aus definierte Ereignissequenz in inkompatiblen Zust nden resultiert In diesem Fall m ssen zur Vermeidung von error states jedoch auch und S inkompatibel sein Es folgt dass und nicht in einen Zustand abstrahiert werden d rfen Auch Aussage b ist also falsch was im Widerspruch zur Annahme steht Beweis von 2 ber Widerspruch Angenommen die Anzahl zwischen Zust nden bestehender Transitionen ist nicht minimal Dann muss es eine mit J Pe gelabelte Transition geben die berfl ssig f r die Erf llung der Korrektheitskriterien ist Diese Transition f hre von einem Zustand des Oberflachenmodells zu einem Zustand T Die Transition ist entweder a benutzergesteuert oder b automatisch Wird die Transition im Fall a entfernt so hat der Benutzer keine Information dar ber dass das Ausl sen eines der Ereignisse p Pp Pa in S einen Wechsel nach T ausl sen kann S stellt damit einen restricting state dar Wird die Transition im Fall b entfernt so hat der Benutzer entsprechend keine Information dar ber dass ein internes Ereignis J in S einen Zustandswechsel nach T bewirken kann verk rpert somit einen concealing sta
121. ufinden keineswegs aber immer worauf noch eingegangen wird Solche Ampeln sind daf r verantwortlich dass Leute h ufig zahlreiche Male auf den Knopf dr cken um sicher zu gehen oder besser die Chance zu erh hen dass das System den Wunsch die Stra e zu berqueren registriert hat Press I Switch Switch Press Abbildung 3 1 2 Anzeigeeinheit einer Druckknopf gesteuerten Ampel links und das zur Ampel geh rige Oberflachenmodell rechts Was vermittelt dieses User Interface an Information Die rechte Seite von Abbildung 3 1 2 zeigt das Modell des Interfaces welches verdeutlicht wie der Benutzer die Zust nde des Systems wahrnehmen kann Im Zustand DON T WALK rotes stehendes M nnchen l sst sich zwar der Knopf der Ampel dr cken Press bleibt jedoch vorerst ohne sichtbares Resultat Irgendwann f hrt das automatische Ereignis Switch dazu dass der Zustand WALK gr nes laufendes M nnchen aktiviert wird Auch hier kann der Knopf bet tigt werden was dieses Mal gar jeglicher Wirkung entbehrt wie sich mit Blick auf das Maschinenmodell in Abbildung 3 1 1 erkennen l sst Erst ein erneutes Auftreten von Switch ndert wieder den Zustand f hrt n mlich zum Zur ckschalten der Ampel von Gr n zu Rot f r Fu g nger Die Bezeichnung Switch wurde hier exemplarisch ausgesucht um die Maskierung interner Ereignisse zu demonstrieren Es handelt sich bei dem abgebildeten Diagramm um das so genannte Oberfl chenmodel
122. und Cool C in COOL 1 COOL 2 und COOL 3 umbenannt Der aus Warm A und Warm B resultierende Zustand erh lt das Label WARM 1 aus Warm C wird WARM 2 Da alle Zust nde aus HOT kompatibel sind bekommt der aus ihnen hervorgehende Zustand schlie lich die Benennung HOT Aus der Eindeutigkeit der Zustands berdeckung folgt weiterhin dass im Grunde keine der Transitionen die in create_all_transitions generiert werden wieder zu entfernen ist Eine Analyse der Methode determine _transitions gibt hier nicht viel her und wird auf das folgende Beispiel verschoben Abbildung 4 3 5 zeigt die Ausgabe des Reduktionsalgorithmus das korrekte und minimale Oberfl chenmodell des Heiz und K hlsystems Nur die entstandenen self loops an WARM 1 und HOT k nnen bei Bedarf internalisiert werden Diese automatischen Ereignisse bewirken keine Zustands nderung im Oberflachenmodell ihre Anzeige w rde lediglich der Mitteilung ber interne Vorg nge dienen VGL HEYMANN amp DEGANI 2006 S 19 Wie erw hnt l sst sich diese Wahl im Software Tool einstellen Br cool cool heatup cool down it it it it hot 1 cool 1 hot li Ji i i if it cool cool down hot hot heatup cool down Abbildung 4 3 5 Korrektes und minimales Oberfl chenmodell des Heiz und K hlsystems Was nun verbleibt ist die konkrete berpr fung der Korrektheit des Oberfl chenmodells die Minimalit t wird im Kapitel 4 5 anhand des Beweises
123. und an Beispielen veranschaulicht Wie bereits mehrfach angesprochen wurde im Rahmen dieser Arbeit ein Software Tool implementiert das den Algorithmus umsetzt Da das Programm au erdem einen graphischen Editor zur Erstellung von Maschinenmodellen beinhaltet kann das Verfahren damit auch praktisch nachvollzogen werden Die technische Seite und die Funktionalit ten des Programms sind ebenso Thema des n chsten und inhaltlich letzten Kapitels wie eine Anleitung die den Einstieg in die Bedienung des Editors anhand eines exemplarischen Ablaufs erleichtern wird 52 Kapitel 5 Entwicklung einer Software zur Erzeugung von Oberflachenmodellen 5 ENTWICKLUNG EINER SOFTWARE ZUR ERZEUGUNG VON OBERFLACHENMODELLEN If there is an available path that the user can take no matter how unlikely there will be someone that will take it DEGANI 2004 S 127 5 1 TECHNISCHER HINTERGRUND ARCHITEKTUR UND INTERNE ABL UFE DER SOFTWARE In diesem Kapitel wird das im Rahmen dieser Arbeit implementierte Software Tool vorgestellt Es wurde vollst ndig in der Programmiersprache Java Version 1 4 2 entwickelt und erm glicht daher plattformunabh ngige Benutzung Das Programm findet sich auf der dieser Arbeit beigef gten CD ROM als ausf hrbare AR Datei au erdem finden sich dort der Quellcode und weitere Materialien F r eine genaue Beschreibung der Inhalte sei auf den Anhang verwiesen Ehe es gleich darum gehen wird die einzelnen
124. ustand S oder einem Zustand T ist falls beide Zust nde die gleichen Aktionen erm glichen und es f r das Verfolgen der Spezifikationsklassen ausreicht zu wissen dass entweder S oder T g ltig ist Diese Situation liegt vor wenn eine beliebige Eingabesequenz gestartet in S in die gleiche Klasse f hrt die sich gestartet in T ergeben w rde und auch die Folgezust nde wiederum die gleichen Bedingungen erf llen VGL HEYMANN amp DEGANI 2002 I S 16 Zwei so beschaffene Zust nde sind Spexifikationsaquivalent ein Interface kann und sollte sie als ein und denselben Modus anzeigen da es dem Benutzer nicht helfen w rde sie auseinander halten zu k nnen Im Gegenteil Die Information ber die interne Differenz ist irrelevant und w rde daher eine unn tige Belastung darstellen In solch einem Fall wird von kompatiblen Systemzust nden gesprochen Definition 4 1 1 kompatible Zust nde compatible states VGL HEYMANN amp DEGANI 2006 S 12 Zwei Zust nde S und T eines Systems hei en genau dann kompatibel wenn sie den folgenden drei Bedingungen gen gen 1 S und T geh ren derselben Spezifikationsklasse an 2 In Sund T k nnen dieselben benutzergesteuerten Ereignisse ausgel st werden 3 Jede f r und T definierte Eingabesequenz f hrt in Folgezust nde und T die ebenfalls den Bedingungen 1 und 2 gen gen Es ist darauf hinzuweisen dass in HEYMANN amp DEGANI 2002 I die zweite Bedingung nicht mit aufgef hrt ist was wohl
125. y make changes themselves PARASURAMAN ET AL 2000 S 6 Auch k nnen automatische Vorg nge zu Verwirrung f hren sogar den Anschein erwecken das System agiere eigenst ndig und obliege nicht mehr den Anweisungen des Benutzers Solcherlei Gegebenheiten bergen m gliche Fehlerquellen bei der Auswertung der gegenw rtigen Situation Hat der Benutzer den Zustand des Interfaces erkannt und interpretiert und darauf aufbauend sein n chstes Ziel entwickelt ist der n chste Schritt dieses Ziel umzusetzen Bei der Bedienung einer Schnittstelle bedeutet das in einer bestimmten Form eine Eingabe zu t tigen Was aber wenn nicht ersichtlich ist worauf etwaige Handlungen hinauslaufen In diesem Fall wird der Benutzer nicht erkennen k nnen was er tun muss um das gew nschte Resultat zu erreichen Einerseits ergeben sich solche Probleme dort wo weder angezeigt wird was der Folgezustand sein wird noch die Bedienungsanleitung Aussagen dar ber macht sofern berhaupt auf sie zugreifbar ist noch die intuitive Vermutung best tigt wird Andererseits finden sich aber auch nicht selten Interfaces die vom Blickpunkt des Betrachters aus nicht deterministisch erscheinen W hrend Nicht Determinismus einer Maschine ein im Grunde nur theoretisches Modell der Informatik ist existiert er schr wohl bei der Interaktion des Menschen mit einem System Definition 2 1 2 Nicht Determinismus non determinism VGL DEGANI 2004 S 35F Ein User Interface hei t
126. ystems and Humans 30 3 http www cs uml edu holly 91 549 readings sheridan autonomy pdf 29 09 2006 68

generierung von korrekten und minimalen oberflächenmodellen aus

Contents

Download Pdf Manuals

Related Search

Related Contents

generierung von korrekten und minimalen oberfl&auml;chenmodellen aus

Contents

Download Pdf Manuals

Related Search

Related Contents

generierung von korrekten und minimalen oberflächenmodellen aus