Home

Modellierung grafischer Dialogsysteme mit

1. This syntax section overloads the standard one inhented fom Gene Button SYNTAX main enterhigh iLEFT exitdehigh sDOIT end INTERACTION_OBJECT INTERACTION_OBJECT FillinField is FROM Genericltern IVARS position legend word METHODS Draw null goes not display word SYNTAX main exitdehigh Act Edit wword viCHAR end INTERACTION_OBJECT Abbildung 9 3 Spezifikation Passwortdialog Teil 2 Fortsetzung von Abbildung 9 2 nach Jacob Spezifikation der Unterkomponenten des Formulars FillinButton und FillinField In TOKENS Abschnitt des FillinButtons ist zu sehen dass bei Erkennen des TOKENS sDOIT an das bergeordnete Objekt in diesem Fall das Formular die Nachricht des Erkennens des Tokens per Funktionsaufruf SendTo parent verschickt wird Im Syntaxdiagramm ist der entsprechende bergang sDOIT aufgef hrt der nach einem linken Mausklick repr sentiert durch das Token iLEFT nach vorheriger Positionierung der Maus im Button erfolgt Die Positionierung im Button ist in einem Subdiagramm namens enterhigh enthalten welches den bergang nach dem Start im Detail spezifiziert 130 9 0 Koroutinen Konzept von Jacob INTERACTION OBJECT FillinField ist die Spezifikation der beiden Felder zur Eingabe des alten und neuen Passworts in FillinForm Es sei hier noch erw hnt dass im FROM Abschnitt Vererbung von anderen Objektspezifikationen n mlich von GenericButton und Genericltem angegeben ist Im ESD wird das
2. 4 1 2 1 Rekursion Wie durch Einf hrung von Zyklen kann eine Stellenreduktion erreicht werden wenn wir Rekursion in unserer Darstellung im Modellgrafen erlauben Rekursion liegt im hierarchischen Modellgrafen dann vor wenn eine zusammengesetzte Stelle in der durch die Hierarchie Relation definierten transitiven H lle als Teilstelle von sich selbst auftritt Dies bedeutet bez glich der Darstellung im Modellgrafen dass die Stelle als Knoten des der Stelle selbst zugeordneten Grafen oder an einem Knoten eines Subgrafen dieses Grafen usw aufgef hrt ist Formel Formel 2 Formel Formel Abbildung 4 9 Beispiel f r Rekursion im hierarchischen Dialogmodellgrafen Die Abbildung zeigt das Modell eines Formeleditors in Anlehnung an EICKEL01 Die ber die dargestellten Kanten begehbaren Dialogpfade beinhalten einen rekursiven Aufruf des Formeldialogs In der Darstellung ist auf eine Annotation der Ereignistypen verzichtet Alle Knoten k nnen o B d A als Eingabestellen betrachtet werden Die vom Rand eines Rechtecks Knotens nach innen gehenden Kanten definieren den bergang zu u U alternativen Startknoten im Subgrafen So erfolgt z B bei Eingabe von Add ein bergang zum Summendialog mit den Alternativen Eingabe Formel f r Summandl oder Eingabe Formel f r Summand2 oder Eingabe Plus Wir k nnen dann sagen die Stelle tritt rekursiv auf In der Grafhierarchie wird also dieselbe Stelle durch zwei Knoten repr
3. Asynchrone Wahrnehmung durch Benutzer Das Ereignis der Wahrnehmung eines Ereignisses an der Dialogschnittstelle ist ebenfalls ein asynchrones Ereignis Wir k nnen grunds tzlich nicht erwarten dass die Ausgabe bzw Darstellung einer Information durch das System auch synchron also zeitlich unmittelbar danach vom Benutzer zur Kenntnis genommen wird Synchrone Ereignisse Ausgabeereignisse sind h ufig unmittelbar synchron aufgrund eines Vorg ngerereignisses ausgel ste Ereignisse d h es kann kein anderes Ereignis zwischen Vorg ngerereignis und dem Ausgabeereignis erfolgen oder es ist ein Ereignis zumindest eine notwendige Folge eines anderen Die Notwendigkeit liegt im Allgemeinen in einer Programmvorschrift begr ndet die eine unmittelbare Reaktion auf ein bestimmtes Vorg ngerereignis definiert Ebenso sind Leseereignisse durch das System h ufig synchrone Ereignisse Im vorangehenden Abschnitt haben wir Kriterien erarbeitet die die Reihenfolge von Dialogschritten begr nden Dabei haben wir festgestellt dass bestimmte berg nge von Dialogereignis zu Dialogereignis logisch aus der Aufgabenstellung begr ndbar sind dass berg nge teilweise aus einer mehr oder weniger logischen oder technischen Gliederung der Informationseinheiten resultieren und dass es berg nge gibt die im Sinne der vorgegebenen Logik willk rlich erscheinen Sie spiegeln zum einen die Freiheit des Benutzers wider von einem logischen Dialogkontext in einen ander
4. go F sei nun wie folgt durch ein eingeschr nktes Ereignisstellenmodell definiert E S So a RO RC gro erc seien die wie oben definierten Mengen Relationen und Abbildungen eines vereinfachten Ereignisstellenmodells ohne W C P t we start KRO KRC TRO E Zuordnung der Ereignismenge pro Zustand Q Potenzmenge E qo sei als Startzustand definiert ber e qo U s So E So E die Menge der Ereignisse diene nun f r den Ereignisstellenautomaten als Menge der Token f rgqge QundeeE q e q wobeig gq q ungleich q falls gilt 3s s e Smite sro s s und s s RO und Je eo s unde g e q wobei e q die q zugeordnete Ereignismenge oder 85 5 Ereignisstellenmodell 3s s e Smite e erc s s und s s RC und Je eo s unde e e q wobei e q die q zugeordnete Ereignismenge und CaS mit s e S amp s s e RO und s e S amp s s e RC d h bei Eintreten eines Ereignisses e erfolgt ein bergang von Zustand q in einen anderen Zustand q dessen Menge akzeptierter Ereignisse aus der Menge der Ereignisse des Vorg ngerzustands q besteht erweitert um die Ereignismengen der gerade ge ffneten Stellen und vermindert um die Ereignismengen der gerade geschlossenen Stellen Dies gilt falls 1 das Ereignis ffne Ereignis an Stelle s f r eine Stelle s darstellt e eRO S s und die Stelle s nicht bereits ge ffnet ist u
5. und Eingabe von B und nur von B Stellen wir uns allerdings auf den Standpunkt nach dem in Kap 5 vorgestellten Modell vorzugehen so haben wir zwei Ereignismengen sl O A und s2 I B zu implementieren was der letzteren Variante entspricht Betrachten wir nun die Zusammenf hrung der berg nge zu und von den Stellen die auf eine Instanz abgebildet werden sollen Auch hier gibt es mehrere denkbar sinnvolle Arten der Vereinigung Sollen z B an der Instanz nur die Ereignisse die ihren Ursprung aus Stelle s1 haben er ffnet werden oder alle Ereignisse wenn laut Modelldiagramm ein ffnepfeil in Stelle sl endet Nach strenger Interpretation des Modells ist hier wiederum die erste Variante vorzuziehen Ebenso ergibt sich die Frage f r die Zusammenf hrung ausl sender Ereignisse Sollen z B alle Ereignisse der Instanz das ffnen von Ereignissen an einer anderen Instanz bzw Stelle 155 10 Realisierung im Prototyp ausl sen wenn nach Modelldiagramm ein ffnepfeil von s1 ausgeht der keine explizite Annotation ausl sender Ereignisse besitzt Nach strenger Modellinterpretation gilt dass dann die gesamte Ereignismenge der Stelle sl die Menge der ausl senden Ereignisse darstellt nicht aber die gesamte Menge der Ereignisse die der Instanz durch Zusammenfassung von sl und s2 zugeordnet ist Als widerspr chlich erweist sich im Normalfall die Geometrie zumindest die Position der Stellen mit gleichem Bezei
6. 10 Realisierung im Prototyp Die Adapterklasse ist in der Regel eine Ableitung einer Java Swing Klasse Adapterklassen der wichtigsten Swingklassen werden wie oben bereits erw hnt vom Prototyp dem Anwender zur Verf gung gestellt und k nnen im Editor des Prototypen per Selektion aus einer Liste einer Ereignisstelle zugeordnet werden Die Source der Adapterklassen also auch die Methode getModel kann vom Anwender den Bed rfnissen der Applikation angepasst werden Generell k nnen jedoch auch vom Anwender eigene Adapterklassen eingef hrt werden die dann mittels Annotation der Ereignisstelle mitgegeben werden m ssen W hrend die Adapterklasse in der Regel eine einfache Ableitung einer Java Swing Klasse oder einer Komfortklasse des Prototypen darstellt und Objekte der Oberfl che repr sentiert verbirgt sich hinter der Modelklasse im Allgemeinen die Applikationslogik Die Signatur der Methode getModel zur Zuordnung eines Modelobjektes lautet DiaModel getModel String variationName Event e Der Methode wird beim Aufruf im generierten Code ein Bezeichner variationName mitgegeben der eine Zuordnung des gesuchten Models zur gew nschten Variation erm glicht Au erdem wird die Methode mit dem konkreten Ereignis das die Variation ausl st versorgt Variationsfunktionen der Aspekte Cardinality und Identity Als Methoden des Modelobjektes werden bestimmte Funktionen erwartet die je nach Aspekt der Variation in ihrer Signatur unterschie
7. i ordro sei eine geeignete Ordnungsfunktion auf den Paaren sk s1 RO die jeweils allen Paaren mit gleicher Ausgangsstelle sk eine eindeutige Ordnungszahl zuordnet und ti Os falls si Dialogstelle ti Ms sonst enext null sonst Bleiben noch S und S zu definieren Ein bergang kann das ffnen oder Schlie en von Stellen bewirken und damit die Menge der m glichen Ereignisse erweitern und oder einschr nken In der n chsten Klammerung werden die Kriterien f r das ffnen einer Stelle und in der darauf folgenden die f r das Schlie en festgelegt Dies geschieht in Form der Definition zweier Stellen Teilmengen S bzw S bzw zweier Relationen RO und RC die RO bzw RC einschr nken 1 Definition S Zu ffnende Stellen S Voraussetzung f r das ffnen einer Stelle s ist dass die Stelle s an der das Ereignis stattfindet ber RO in Beziehung steht Es m ssen jedoch noch weitere Bedingungen erf llt sein die zu einer weiteren Einschr nkung der berg nge s nach s in RO f hren Wir definieren also S respektive ROH S eF s s e ROH s s RO oder 3 s s e RO und 3 s s HSStart d h s ist Startknoten von s HSStart eine Stelle u ist Startstelle von t sei dabei wie folgt definiert und t u e HSStart amp 3k Tupel so Si Sk Mit So Si Sk S i k N und s t und s u und si s1 HS f
8. zugeordnet Ist umgekehrt das Ziel zu einer abstrakten logischen Darstellung des Systems zu gelangen findet im Rahmen des Modells eine Ersetzung konkreter durch abstrakte Elemente statt Dieser Weg wird beispielsweise dann beschritten wenn in einer Phase der Analyse aus kon kreten exemplarischen Vorstellungen des Benutzers eine abstrakte logische Darstellung gewonnen werden soll Der Weg der Abstraktion kann auch dann gew hlt werden wenn eine Implementierung bereits vorliegt und eine nachtr gliche Umsetzung in eine andere Konkretisierung erfolgen soll z B eine Umsetzung in eine andere Dialogart Der Designer soll also nicht zu einer Vorgehensweise Top down oder Bottom up gezwungen sein 2 1 Abgeleitete Ziele und Rahmenbedingungen Die im Folgenden genannten Ziele vertiefen die oben genannten Kernziele bzw stellen wesentliche Rahmenbedingungen f r die Entwicklung des Modellsystems dar Grafische Darstellung Ziel ist die Modellierung weitgehend in grafischer Darstellung durchf hren zu k nnen Die grafische Darstellung wird angestrebt weil wir annehmen dass diese Darstellungsform f r den Entwickler wie auch den Benutzer einen schnellen und umfassenden Zugang zum Modell bietet Ergebnisorientierte Darstellung Damit verbunden ist dass wir in erster Linie aber nicht notwendigerweise die Darstellung grafischer Oberfl chen anstreben und diese in WYSIWYG Darstellung bereits im Modell erfassen wollen Der Entwickler wie au
9. 1 1 1 0 Zustands bergangsdiagramme Basis einer ganzen Reihe von Modellen ist die Darstellung der Dynamik mithilfe von Zustands bergangsdiagrammen ZUD FOLE90 GREEN86 20 1 1 Abstrakte Modellsysteme Einfache Zustands bergangsdiagramme bestehen aus Knoten grafisch dargestellt durch Kreise und gerichteten Kanten Pfeile Die Knoten definieren die Zust nde die Kanten die Zustands berg nge An den Kanten k nnen Ereignisse und oder Aktionen notiert werden Ereignisse die den Zustands bergang ausl sen bzw Aktionen die beim bergang ausgef hrt werden Die Aktionen k nnen auch in den Knoten eingetragen werden Eine Erweiterung der einfachen Zustands bergangsdiagramme stellen so genannte rekursive Zustands bergangsdiagramme RTN s Recursive Transition Networks und Augmented Transition Networks ATN s dar In einem RTN repr sentieren Knoten ggf den rekursiven Aufruf eines Subdiagramms In einem ATN sind zus tzlich Variablen und Funktionen erlaubt mittels derer z B Bedingungen f r Zustands berg nge und Wertzuweisungen formuliert werden k nnen Manchmal wird ein ATN als Erweiterung eines RTN gesehen in anderer Literatur werden ATN s mit rekursiven Subdiagrammen auch als Augmented Recursive Transition Networks bezeichnet Generell k nnen wir die erweiterten Zustands bergangsdiagramme in eine Klasse verallgemeinerter Transitionssysteme einordnen EICKELO1 Ein Vorteil bei einfachen Zustand bergangsdiagrammen li
10. 1995 Schreiber S Spezifikationstechniken und Generierungswerkzeuge f r graphische Benutzungsoberfl chen Herbert Utz Verlag Wissenschaft 1997 Shebanek M The Complete Guide to the NeXTSTEP User Environment Springer Verlag Telos 1993 Siemens Nixdorf Informationssysteme AG Dialog Builder SQL V2 1 Datenbankerweiterung f r Dialog Builder Benutzerhandbuch 1994 Szwillus G Objektorientierte Dialogspezifikation mit ODSN Softwaretechnik 1997 VANDER88 Vander Zanden B T Constraint Grammars in User Interface Management Systems Proceedings of Graphics Interface 88 Canadian Inf Process Soc p 176 184 1988 VANDER95 Vander Zanden B Myers B A Demonstrational and Constraint Based WELLNS9 ZEIDL92 ZIEGLE93 Techniques for Pictorially Specifying Application Objects and Behaviours ACM Transactions on Computer Human Interaction Vol 2 No 4 p 308 356 1995 Wellner P D Statemaster A UIMS based on Statecharts for Prototyping and Target Implementation CHI 89 proceedings ACM 1989 Zeidler A Zellner R Software Ergonomie Techniken der Dialoggestaltung Oldenbourg 1992 Ziegler J Benutzergerechte Software Gestaltung Standards Methoden und Werkzeuge Oldenbourg 1993 167 Anhang A Anhang A Rekursive Modellierung der Fakult tsfunktion Fakult tsfunktion in einem Ereignisstellendiagramm In obiger Abbildung entspricht di
11. Annotation der Ereignisse Durch die Annotation von Ereignistypen und Wertebereichen werden implizit in der grafischen Darstellung Ereignismengen definiert Die Ereignismenge entsteht dadurch dass die im formalen Modell vorgestellten ein Ereignis repr sentierenden Tripel bestehend aus Stelle Wert und Typ aus der Kombination der Stelle mit jedem Wert aus dem annotierten Wertebereich und jedem einzelnen annotierten Typ I O oder M entsteht Einer Stelle k nnen alternativ oder zus tzlich zur Annotation der Ereignistypen und Werte Wertebereiche die an der Stelle m glichen Ereignisse als Annotation mitgegeben werden Gekennzeichnet wird die Annotation wie bei der Zuordnung der Ereignisse zu Stellen durch ein vorangestelltes E mit Doppelpunkt E und einem Bezeichner f r die Ereignismenge oder mit einer expliziten Auflistung von Typ Wert oder Typ Wertebereichs Paaren Darstellung der Conditions Das ffnen und Schlie en von Stellen kann an Bedingungen gekn pft werden Im formalen Modell wird dies ber eine Menge von Conditions C ausgedr ckt Eine Condition kann einem Stellenpaar aus den ffne und Schlie e Relationen RO und RC zugeordnet werden Dies geschieht im formalen Modell ber die Zuordnungsfunktionen Kro bzw KRC In der grafischen Darstellung wird dies wahlweise in zwei Arten dargestellt 1 Annotation der Conditions an Triggerkanten Die Condition kann am ffne Pfeil oder Schlie e Pfeil annotiert werden Dies geschieht d
12. Menge ERO Sq Sq um Ey Damit wird bei Eintreten des Ereignisses eq an der Stelle sq die Stelle sq neuer Zustand q er ffnet Falls sq ungleich s4 f gen wir ebenso ein Paar Sq sy in RC ein und erweitern die Menge ERC Sq Sq UM egt Dies bedeutet dass dann durch das Ereignis eq das Schlie en der Stelle sq alter Zustand q ausgel st wird e T sind als Projektionen von E eindeutig definiert Die Funktionen KRO KRC und TRO bilden jeweils auf die leere Menge ab da keine Conditions und bertragunsgfunktionen ben tigt werden Dies bedeutet insbesondere dass bei einem Stellen bergang die Menge der erzeugten neuen Ereignisse enext leer ist also kein weiterer automatischer bergang propagiert wird Alle an den Stellen akzeptierten Ereignisse wurden auch als per Definition asynchrone Ereignisse vom Typ Ig definiert start kann beliebig gew hlt werden Es ist nun leicht zu sehen dass ein bergang im endlichen Automaten von einem Zustand q in einen Zustand q ber ein Token t genau dann erfolgt wenn an der ge ffneten Stelle sq sich ein Ereignis eq ereignet und damit die Stelle sq er ffnet die Stelle sq jedoch geschlossen wird falls sq und s sich unterscheiden Umgekehrt k nnen wir bei bestimmten Einschr nkungen des Ereignisstellenmodells dieses leicht auf einen deterministischen endlichen Automaten abbilden wie das im folgenden Abschnitt gezeigt wird 84 5 2 Abbildung von eingeschr nkten p
13. Sind beide Stellen neue Stellen gilt entsprechend dass die Vorkommen beider Exemplarstellen orig s und orig s gegen s bzw s ausgetauscht werden In gleicher Weise gilt f r KRC KRC s s K RC s s f r s s RC und f r RO nRO s s n RO s s f r s s RO F r die ausl senden Ereignisse der Stellen berg nge gilt ERO ERO s s ERO S S falls s s e RO d h die ausl senden Ereignisse der alten Stellen berg nge aus RO bleiben erhalten EeRO s s eRO s orig s falls s e Sneu und s orig s e RO d h es bleiben ebenso die Ausl seereignisse bei berg ngen von alten Stellen zu neuen Stellen dieselben ERO s s s t evar we evar evar ERO orig s orig s falls s Sneu und orig s orig s RO d h bei berg ngen von neuen Stellen zu neuen oder alten Stellen muss die jeweilige Exemplarstelle gegen die neue Stelle ausgetauscht werden Entsprechendes gilt bei ERC ERC S S ERC S S falls s s RC ERC s s ERC s orig s falls s e Sneu und s orig s e RC ERC S s s T evar we evar evar eRC orig s orig s falls s Sneu und orig s orig s RC SStart SStart SStart U SStartneu mit SStartneu s s SSubneu und orig s SStart d h die Menge der Startstellen wird um die neuen Stellen e
14. Text Text Title Name KeyTyped KeyTyped ValueChanged KeyTyped Mouse Pressed Abbildung 10 1 Defaultabbildung abstrakter Ereignisstellen mit Triggerfunktion auf Java Swing Klassen oder abgeleitete Komfortklassen Pro vorliegender Typ und Wertannotation an einer primitiven oder zusammengesetzten Stelle werden jeweils Widgetklasse Belegung des konkreten Value Attributs z B Text und konkretes Triggerereignis f r die Ausl sung von Ereignissen an anderen Stellen angegeben Eine h ufig gegebene Situation des Entwurfs in der fr hen Phase ist die dass die Designer der Dialogoberfl che eines Systems sich noch nicht auf konkrete Widgetklassen festlegen wollen In vielen F llen m chte man zun chst lediglich die Struktur des Dialogs in seinen Dialogeinheiten festhalten ohne auch noch konkrete Wertebereiche an einer Dialogstelle zu bestimmen Manchmal ist auch selbst der Ereignistyp Eingabe Ausgabe oder Eingabe und Ausgabe noch nicht klar 153 10 Realisierung im Prototyp Nicht zuletzt f r dieses Anwendungsszenario sieht der Prototyp die automatische Abbildung abstrakter Ereignisstellen auf konkrete Widgets und Widgetattribute vor Der Codegenerator erzeugt aus dieser schwach best ckten Spezifikation bereits automatisch ein ablauff higes Programm das zumindest zum Zweck des Tests der Dialogstruktur genutzt werden kann In den Tabellen in Abbildung 10 1 und Abbildung 10 2 wird die defaul
15. die wir durch Einsatz von Sprachelementen zur Abfrage des konkreten Wertes ersetzen werden siehe 4 1 3 Wir wollen zur weitergehenden Erl uterung ein neues Dialogbeispiel einf hren n mlich den Dialog mit einem Bankautomaten der in Abbildung 4 7 wiederum in Form eines Grafen dargestellt ist Hier gibt es im Modell zwei Stellen an denen die Eingabe unterschiedlicher Werte an ein und derselben Stelle m glich ist n mlich die Eingabe einer Geheimzahl zur Authentifizierung des Kartenbesitzers und die Eingabe eines vom Kunden bestimmten beliebigen nicht standardm ig vom Automaten angebotenen Betrages der vom Konto abgehoben werden soll Bei der Eingabe einer Geheimzahl ist es nahe liegend dass diese der Benutzer eingeben muss und dass nicht der Automat alle g ltigen oder alle potentiell m glichen Werte zur Auswahl anbietet Es ist aus Sicht des Dialogsystems also zun chst ungewiss welcher konkrete Wert f r die Geheimzahl eingegeben wird Die beliebige Angabe eines abzuhebenden Geldbetrags allerdings wird bei manchen Automaten auch durch die Auswahl einer Menge vorgegebener Betr ge ersetzt oder manchmal auch erg nzt Um nun die verschiedenen Werte der Eingabe also die verschiedenen Eingabeereignisse im Modell darzustellen nutzen wir die bereits in unserem Grundmodell nicht ausgeschlossene M glichkeit einer Stelle eine Ereignismenge und damit auch mehrere Werte zuzuordnen Die Menge der zugelassenen Werte k nnen wir als Werteber
16. dynamisch zur Laufzeit Im anderen Extremfall steht die Variation bereits zum Modellierungszeitpunkt fest In letzterem Fall dient die exemplarische Darstellung dann nur der bersichtlichkeit und der Ersparnis von Darstellungsaufwand Ein Fall zwischen diesen beiden Extremen ist wenn z B die Variante zum Startzeitpunkt der Anwendung entschieden wird in einer Initialisierungsphase des Systems aufgrund von Startparametern Als letztes Kriterium soll hier ein Variationsmerkmal eingef hrt werden in folgenden Beispielen als Variationstyp bezeichnet das zwischen einer sogenannten vollst ndigen Variation und einer inkrementellen Variation unterscheidet Bei einer vollst ndigen Variation werden alle durch eine Exemplarmenge repr sentierten Varianten vollst ndig gegen die neu bestimmten Varianten ausgetauscht Bei einer inkrementellen werden die neuen Varianten der alten Variantenmenge hinzugef gt 7 3 Einfaches Variationsbeispiel Nehmen wir an wir arbeiten mit einem Baukastensystem in dem u a Dialog Objekte vom Typ Toolbar und Dialog Objekte vom Typ Icon zur Verf gung stehen Ein Icon sei durch folgende spezifischen Attribute beschrieben Symbol Bitmap beschreibender Text bei Selektion auszul sender Dialog Daneben besitze ein Icon wie jedes andere grafische Objekt des Baukastens die Attribute Gr e Position Hintergrundfarbe Vordergrundfarbe und sei in einem anderen Objekt 114 7 3 Einfaches Variationsbeispiel Parent a
17. e E o e s und enext E gilt q s e gt q s enext lt gt 78 5 0 Formale Darstellung e e q e muss in der Menge der m glichen Ereignisse von q liegen und s e Y Uos U o s ses ses Die q zugeordnete Menge m glicher Ereignisse ergibt sich aus der Menge im Ausgangszustand q erweitert um die Ereignismenge der neu zu ffnenden Stellen S Definition siehe unten und vermindert um die Ereignismenge der zu schlie enden Stellen S Definition siehe unten und VsteS s st wele falls st s s st s st sonst Die neue Wertezuordnung as nach bergang ergibt sich an allen Stellen aus der alten mit Ausnahme an der Stelle s wo der Wert mit dem Wert des Ereignisses e also we e belegt wird vereinfachter Fall und Mit dem ffnen einer Stelle s also der Realisierung eines Stellen ber gangs s S werden unter Umst nden auch Schreibereignisse des Systems er ffnet Dies ist dann der Fall wenn der Stelle s eine Ereignismenge zugeordnet ist die auch Ereignisse der Typen Os oder Ms enth lt In diesem Falle wird ber die s s zugeordnete Propagationsfunktion die Entscheidung gef llt welches der m glichen Ereignisse als n chstes an der Stelle s stattfinden soll Hier wird der Sicht des Modells Rechnung getragen dass auch das Schreiben des Systems an Ausgabestellen und Hilfsstellen ber Ereignisse mit entsprechenden Zustand berg n
18. ffnen durch einen so genannten ffne Pfeil dargestellt Dies ist eine gerichtete Kante die von der Stelle an der das Ereignis eintritt zu der Stelle die ge ffnet wird f hrt Zur Verdeutlichung wird der ffne Pfeil wahlweise mit einem T Trigger oder mit einem O Open beschriftet Den ffne Pfeil wollen wir auch als Triggerpfeil oder Triggerkante bezeichnen Der Pfeil beginnt jeweils am Rahmen eines Stellenrechtecks und endet an einem Rahmen Entsprechend gibt es zur Darstellung der Schlie e Relation den so genannten Schlie e Pfeil Dieser wird zur eindeutigen Interpretation wahlweise an der Spitze mit einem durchkreuzten Kreis Symbol des Schlie ens versehen und oder mit einem C Close beschriftet Im Folgenden werden zwei Schreibweisen bez glich der Pfeildarstellung vorgeschlagen die die Anzahl der Kanten reduziert und damit die bersicht im Diagramm steigern kann 1 Als Kurzschreibweise f hren wir eine gerichtete Kante ein die am Schaft also in N he der Stelle aus der die Kante weggef hrt wird mit einem durchkreuzten Kreis versehen ist Es handelt sich dabei um eine Kombination aus Schlie e und ffne Pfeil Dieser Schlie e ffne Pfeil kann zwischen den Stellen A und B gezogen werden wenn durch ein Ereignis an der Stelle A die Stelle A selbst geschlossen und Stelle B ge ffnet wird 2 Als weitere Kurzschreibweise erlauben wir dass ffnepfeile Triggerkanten von Teilstellen an den Rechtecksrand einer be
19. ffnen eines anderen Objektes bzw jede Auswirkung auf ein anderes Objekt aufgrund eines Ereignisses in einem Objekt in einer Stelle wieder als ein Ereignis Metaereignis an einer anderen Stelle mittels ffnepfeil und oder Wert bertragungspfeil grafisch dargestellt Damit kann der Zusammenhang des Dialogs ber alle Stellen in der Implementierung ggf Objekte in einem Diagramm dargestellt werden Der Grundansatz ist im ESD dass Ereignisse prinzipiell Ereignisse an anderen Stellen oder an den gleichen Stellen nach sich ziehen wobei es sich dann in letzteren Fall um eine mehrere Ereignisse zusammenfassende Stelle handelt ChangePasswordDialog Cond rongConfirmatio ewPassword Co Abbildung 9 4 Ereignisstellendiagramm ESD eines Dialogs zur Passwort nderung Verk rzte Schreibweise f r Kanten mit Conditions Statt mehrere gerichtete Kanten von der Ausgangsstelle zur Zielstelle mit Konditionen darzustellen wird bei identischen oder sich logisch negierenden Konditionen die Kondition mit ihrer Ausgangskante nur einmal gezeichnet Die Kanten zu den Zielstellen verzweigen dann von der Kondition aus den entsprechenden Ausg ngen true oder false Die drei Konditionen sind au erdem hintereinandergeschaltet Dies stellt ebenfalls eine Alternative zu einer Darstellung mit drei Konditionen dar deren Kanten direkt nebeneinander aus der Stelle Change gef hrt w rden Die Konditionen w ren dann entsprechend so zu for
20. r alle i 0 k 1 d h si ist Teilstelle von s und s e So f r alle i 1 k d h s ist aus der Menge der Startstellen So 171 Anhang B Definition von RO und s s RO s s RO und Ereignis e muss aus der Menge der ausl senden Ereignisse stammen die dem Ubergang s s zum Offnen zugeordnet ist also e ERO S S und Die dem potentiellen bergang s s aus RO zugeordnete Condition muss bei der aktuell g ltigen Wertebelegung wsden Wert TRUE liefern c Oat TRUE mit c Kro sROs und Oakt OS Sc wobei sjs die aktuelle Wertezuordnung os eingeschr nkt auf die f r c definierte Stellenmenge Se Ende Definition S ROH mit aktuellen berg ngen s s zum ffnen s und 2 Definition S Zu schlie ende Stellen S hnlich zu 1 muss nun ein potentieller bergang s s aus RCH existieren der durch RC sowie die Teilstellenhierarchie HS definiert ist und auch noch weitere Bedingungen erf llt Definition S respektive RCH ss e RCR amp s s e RC oder 3 s 5 e RC und 3 s s e HS d h s ist Teilstelle von s und s e S e s s e RC amp s s e RC und e erc s s und C Oak TRUE mit c rc sRCs und akt OSise 172 Anhang B bergangsfunktion f r das hierarchische ESM wobei sjs die akt
21. r die Entwicklung von Dialogsystemen ableiten Zum einen soll die M glichkeit der logischen Modellierung des Dialogs aus dem modellbasierten Ansatz mit den M glichkeiten zur Darstellung der Dynamik wie er bei direkter Programmierung nahezu uneingeschr nkt gegeben ist verbunden werden Damit sollen die bisher bestehenden Einschr nkungen zur Darstellung der Dynamik in grafisch orientierten Modellen beseitigt werden Zum anderen soll eine Integration logischer Modellierung mit layoutnaher WYSIWYG Darstellung erfolgen wie sie in grafischen Rapid Development Systemen geboten wird Es soll einerseits eine intuitive Darstellung auch f r den potentiellen Benutzer des Systems erm glicht werden Andererseits soll auch im Vorgang des Entwurfs ein zwangloses Umschalten von konkreter zu abstrakter Darstellung und umgekehrt erm glicht werden 2 0 0 Logische Dialogmodellierung unter Einbeziehung der Dynamik Ein erstes Kernziel ist die Entwicklung einer problemnahen Modellsprache die eine einfache bersichtliche Modellierung der logischen Dialogoberfl che unter Einbeziehung der Dialogdynamik erlaubt Wir wollen im Folgenden informell die Begriffe die das erste Ziel der Arbeit umschreiben n mlich die Modellierung von logischem Dialog und Dialogdynamik etwas genauer um rei en 2 0 0 0 Begriffskl rung logischer Dialog Unter logischem Dialog wollen wir alle Merkmale oder Eigenschaften des Dialogs verstehen die zur Erf llung
22. umfassende Dialogstelle des ESD in eine Webseite umsetzt Wie die gr nen Pfeile in 147 9 Vergleich mit bekannten Ans tzen Abbildung 9 8 definieren die gr nen Pfeile im ESD das ffnen der jeweiligen Zielstellen aufgrund eines Ereignisses an der Ausgangsstelle Wenn wir annehmen dass bei der Wahl von Checkboxen oder Buttons als konkrete Stellenrealisierung standardm ig ein Mausklick das zugeh rige ausl sende Ereignis darstellt stimmt auch das ausl sende Ereignis bei Interpretation des ESD mit der Standard Interpretation des Pfeils in DENIM berein Im vorliegenden Prototyp ist eine derartige Standardabbildung vorhanden siehe dazu Kap 10 la Checkout Checkout Shopping Cart Shopping Cart Order List Socks 9 99 Tennis Racquet 37 00 Tank Top 16 20 Order List Socks 9 99 Tennis Racquet 37 00 Tank Top 16 20 Checkout Shopping Cart Order List Socks Abbildung 9 9 Ereignisstellendiagramm f r Zust nde der Checkout Seite im Shoppingsystem Im ESD in Abbildung 9 9 sind gem der formalen Definition des Ereignisstellen Modells Pfeile gezeichnet die das Schlie en der jeweiligen Stellen bestimmt Es wird eine einen Zustand der Seite Checkout repr sentierende Stelle geschlossen wenn eine andere Zustands stelle ge ffnet wird Ebenso wird die Stelle geschlossen wenn ein bergang auf eine Folge seite Card Wrap CardAndWrap Shipping bei Mausklick auf den OK Butto
23. 4 1 1 Hierarchienbildung 51 4 1 1 0 Zusammenfassung von Dialogfolgen 52 4 1 11 Zusammenfassung von Teilgrafen 52 4 1 2 Schleifenbildung und Rekursion 54 4 1 2 0 Zyklen 54 4 1 2 1 Rekursion 55 4 1 3 Entscheidungsmechanismen f r Stellen berg nge und Wertebelegungen 56 4 1 3 0 Bedingungen Conditions 56 4 1 3 1 Hilfsstellen 57 4 1 3 2 Ubertragungsfunktionen Propagationsfunktionen 37 4 2 Logische Abstraktion zeitlicher Folgen 59 4 2 0 Differenzierung der Stellentransitionen 59 4 2 1 Kriterien der Dialogdynamik 60 4 2 1 0 Ereignisse bewirken Ereignisse 60 4 2 1 1 Logisch begr ndete Dialogreihenfolgen 61 4 2 1 2 Technische und layoutbedingte Reihenfolgen 66 4 2 1 3 Asynchrone und synchrone Ereignisse 67 4 2 2 Reduktion auf logische Stellen berg nge 68 5 Ereignisstellenmodell 76 5 0 Formale Darstellung 76 5 1 Abbildung eines determinist endlichen Automaten auf die Ereignisstellendarstellung _ 84 5 2 Abbildung einer eingeschr primitiven Ereignisstellendarstellg auf endl Automaten 85 5 3 Grafische Darstellung 87 5 3 0 Kernaspekte der grafischen Darstellung 87 5 3 1 Darstellungselemente eines Ereignisstellendiagramms ESD 88 5 3 2 Modellsichten 96 5 3 2 0 Zielsetzung 96 5 3 2 1 Ausblenden von Teilstellen 97 3 3 2 2 Darstellung der Hierarchie in Modellsichten 97 3 3 2 3 Gegenseitige Erg nzung von Stellen 99 3 3 2 4 Zusammenf hrung der Teilsichten 99 6 Abstraktion vom konkreten Widget 102 6 0 hnlichkeit von Stellendarstellung u
24. B in Folgebildschirmen oder Subfenstern anzubieten die ber entsprechende Verweise erreichbar sind Wir wandeln damit wiederum Information die auf einer Fl che gleichzeitig dargestellt wird in Information die zeitlich hintereinander angeboten wird um diesmal jedoch nicht wie oben beim Beispiel des Handy Displays aus technischer Notwendigkeit sondern aus Aspekten der Ergonomie Dazu sei vermerkt dass wir bei der Aufteilung der Information nach logischen Gesichtspunkten vorgehen und nicht eine rein technische Aufteilung im Sinne eines Seitenumbruchs logisch unstrukturierter Information durchf hren Hier scheint eine Trennung zwischen Logik und Layoutgestaltung im Modell schwierig bzw unn tig da wir eine Einheit von Form und Inhalt erreichen die logische Informationseinheit entspricht jeweils der technischen Einheit eines Bildschirm fensters Widgets Wir k nnen festhalten dass zeitliche Reihenfolgen in der Dialogf hrung und damit also die Dialogdynamik im Allgemeinen sehr stark durch Belange des Benutzers seine Erwartungen seine Aufnahmef higkeit usw gepr gt ist und das Dialogmodell in der Lage sein sollte entsprechende daraus resultierende Anforderungen an die Dynamik auszudr cken 4 2 1 3 Asynchrone und synchrone Ereignisse Asynchrone Ereignisse Wie wir oben Echtzeitereignisse gerade als asynchrone Ereignisse eingeordnet haben gibt es eine Reihe anderer Ereignisse die wir als asynchron bezeichnen wollen Generell verst
25. Bankautomaten 50 Abbildung 4 8 Hierarchische Darstellung am Beispiel des Laufwerksdialogs 33 Abbildung 4 9 Beispiel f r Rekursion im hierarchischen Dialogmodellgrafen 55 Abbildung 4 10 Entkoppelung von Eingabe der Daten und Durchf hrung der Aufgabe 62 Abbildung 4 11 Dialog zur Adresserfassung in Modell mit expliziter Darstellung der berg nge und Modelldarstellung mit nebenl ufigen Dialogen n nncn 69 Abbildung 4 12 Beispieldialog Auftragserfassung 00 2222000ssssnsnnenssennneenssnnnnennennnnn 70 Abbildung 4 13 Auftragserfassung mit primitiven Teildialogen und bergang zur Preisberechnung gesteuert durch Benutzereingabe nesennennennnnennneen 71 Abbildung 4 14 Auftragserfassung mit Condition und automatischem bergang zu Pr isberechnung seene e EA a AE E A E a 72 Abbildung 4 15 Auftragserfassung mit Condition und Propagationsfunktionen 73 Abbildung 4 16 Logische und willk rliche berg nge schematische Darstellung zweier Debenlaufiser Dialoge sn fen anerkennen 74 Abbildung 5 1 Hierarchie von Stellen in geschachtelten Rechtecken 0 89 Abbildung 5 2 Darstellung der ffne und Schlie e Relation durch ffne und Schlie e Pfeil EE END EEG EE ARRIE RER TENR RUN R SP TER EEA EEEE DENE OEA FREE 90 Abbildung 5 3 Beispiel Annotationen an Stellen uus
26. Berechnung eines Wertes annotiert werden siehe Implementierung Modellsystem Als Kurzform sei erlaubt Steht nur ein Gleichheitszeichen nach P also P so bedeutet dies dass der Wert der Stelle aus der die Kante f hrt identisch an die Zielstelle bertragen wird Annotation der Propagationsfunktionen an Wert bertragungskanten Um grafisch sichtbar zu machen von welchen Stellen Werte in die Berechnung eingehen und an welche Stelle der berechnete Wert bertragen wird f hren wir so genannte Wert bertragungskanten ein siehe oben Datenflussaspekt der grafischen Darstellung Wenn grafisch dargestellt werden soll dass bei Eintritt eines Ereignisses an einer Stelle A der Wert einer Stelle B an eine Stelle C bertragen werden soll zeichnen wir eine gerichtete Kante zwischen B und C Wert bertragungskante und f hren eine Triggerkante von A auf die Wert bertragungskante siehe Abbildung 5 5 Darstellungen der Propagationsfunktion An die Wert bertragungskante annotieren wir die Propagationsfunktion die den Wert von B als Eingangsparameter erh lt und den berechneten Wert an C bertr gt Im einfachen Fall handelt es sich bei der Propagationsfunktion wiederum um die Identit tsfunktion d h der Wert von B wird identisch an C bergeben In Sprechweise des Ereignisstellenmodells handelt es sich bei der Wert bertragung um die Berechnung des Wertes eines Ereignisses das an C eintritt nachdem ein bestimm
27. Conditions Darstellung der Propagationsfunktionen Propagationsfunktionen haben wir eingef hrt um dynamisch bestimmen zu k nnen welcher Wert an einer Ausgabestelle oder an einer Hilfsstelle gesetzt werden soll wenn sich dort ein Ausgabeereignis Typ Os bzw Schreibereignis Typ Ms ereignet Es handelt sich dabei um Stellen an denen Ereignisse mit unterschiedlichen Werten auftreten k nnen Dabei gehen in Propagationsfunktionen u U aktuelle Werte bestimmter definierter Stellen ein die als Parameter bergeben werden Im formalen Modell sind die Propagationsfunktionen in der Menge P dargestellt Deren Zuordnung zu Stellenpaaren in der ffne Relation RO wurde mit nro bezeichnet 92 3 3 Grafische Darstellung Propagationsfunktion auf Triggerkante Propagationsfunktion als Pseudostelle Abbildung 5 5 Darstellungen der Propagationsfunktion Annotation der Propagationsfunktionen an Triggerkanten Im einfachen Fall werden Propagationsfunktionen hnlich Conditions an Triggerkanten annotiert Dies geschieht indem mit vorangestelltem P der Name der Propagationsfunktion gefolgt von den kommagetrennten geklammerten Eingangsparametern an die Triggerkante geschrieben wird Die Eingangsparameter sind wiederum Bezeichner von Stellen deren aktuelle Werte zur Bestimmung des Funktionswertes ben tigt werden Anstelle eines Funktionsnamens mit geklammerten Parametern kann auch ein Gleicheitszeichen gefolgt von einem Ausdruck zur
28. Dialogereignisfolgen In der Modelldarstellung dienen die einzelnen Bilder als Stellen Modellstellen Nach unserem Grundmodell haben wir ein Tupel E T W S F T Als Ereignismenge E haben wir E e0 el8 T Ip Os 5 W schiebt Diskette ein Programm installieren Ja Nein Installation in vollem Umfang Installation in Vollumfang Installation in Minimalumfang Installation erfolgreich beendet Fehler bei Vollinstallation Fehler bei Minimalinstallation Installation abgebrochen gibt Diskette aus S Bild0 Bild18 F fl e0 el e2 e3 e4 e5 e6 e7 f2 e0 el e8 e9 e10 f3 e0 el e2 e3 e11 e12 e13 e14 f4 e0 el e2 e3 e4 e5 e15 e16 f5 e0 el e2 e3 e11 e12 e17 e18 Die Funktionen T O f r die einzelnen Ereignisse in E lauten F r e0 Is BildO schiebt Diskette ein el Os Bildl Programm installieren e2 Is Bild2 Ja e3 Os Bild3 Installation in vollem Umfang el8 Os Bild18 gibt Diskette aus Die Funktion o liefert den Wert einer Stelle identisch zum Wert des Ereignisses an der Stelle Also o Bild0 e0 schiebt Diskette ein Bildl el Programm installieren o amp Bild18 p el8 gibt Diskette aus Wir haben hier eine bijektive Abbildung zwischen den Stellen im Modell und den Ereignissen Jedes Bild zei
29. Ereignismengen zugeordnet die den bergang bzw das ffnen und Schlie en der Zielstelle ausl sen In manchen F llen stimmt die Menge dieser Ereignisse mit der Menge der Ereignisse berein die der Ausgangsstelle als Ereignismenge zugeordnet ist D h alle Ereignisse an der Stelle bewirken alle berg nge In vielen F llen muss allerdings differenziert werden Wir ben tigen deshalb dann eine explizite Zuordnung der Menge der ausl senden Ereignisse f r den jeweiligen Stellen bergang Im formalen Modell wird dies durch die Zuordnungen ero bzw erc ausgedr ckt Im ESD bewerkstelligen wir dies durch Annotation der Ereignismenge am ffne bzw Schlie epfeil und zwar um Verwechslungen mit Zielereignismengen siehe unten zu vermeiden in der N he der Stelle von der die Kante wegf hrt Gekennzeichnet wird die Annotation wie bei der Zuordnung der Ereignisse zu Stellen durch ein vorangestelltes E mit Doppelpunkt E und einem Bezeichner f r die Ereignismenge oder mit einer expliziten Auflistung von Typ Wert oder Typ Wertebereichs Paaren siehe Implementierung Modellsystem Annotation zum ffnen und Schlie en von Ereignisteilmengen Zielereignisse Bei Stellen die nicht ein einzelnes Ereignis sondern eine Ereignismenge repr sentieren ist es manchmal sinnvoll das Er ffnen oder das Schlie en Sperren nur f r eine Teilmenge durchzuf hren Im obigen formalen Modell ist dieser Fall nicht ausgef hrt Der Fall tritt zum Beispie
30. Ereignisstellen mit konkreten Widgets zu arbeiten die dann weitgehend in WYSIWYG Qualit t das hei t in der Erscheinungsform zur Laufzeit dargestellt werden siehe dazu auch Ausf hrungen in Kap 6 Abstraktion vom konkreten Widget Wie die abstrakten Ereignisstellen k nnen die Widgets mit denselben dynamischen Relationen in Bezug gesetzt und mit entsprechenden Annotationen versehen werden 151 10 Realisierung im Prototyp Mischung abstrakter und konkreter Elemente Der Benutzer hat die Wahl sich stellenspezifisch zwischen einer abstrakten Darstellung einer Stelle und der Darstellung eines konkreten Widgets zu entscheiden Er hat au erdem die Wahl in einem Modus mit ausschlie lich abstrakter Darstellung aller Ereignisstellen zu arbeiten Robustheit bei nderungen Besonderes Augenmerk bei der Implementierung des Editors wurde auf die leichte nderbarkeit von Modellelementen gelegt mit dem Ziel bei nderungen m glichst viel an bereits vorhandenen Informationen ber die nderung hinaus beizubehalten So ist es z B jederzeit m glich die Hierarchie der Ereignisstellen durch wenige Mausklicks zu ndern z B den Parent zu wechseln oder zus tzliche Hierarchieebenen an beliebiger Stelle in der Hierarchie einzuziehen ohne dabei Elemente l schen zu m ssen oder bereits mitgegebene andere Information Widgetklasse Bez ge zu anderen Objekten etc der Elemente zu verlieren Ebenso ist es m glich beispielsweise zugeordenete Widgetkl
31. Erl uterung dieses Falls hinter die Dialogschritte zur Auswahl des Installationsumfangs Dialogstellen zur Auswahl des Laufwerkes auf das die neue Software installiert werden soll eingef hrt Danach soll weiterhin die Meldung erfolgen dass der Start der Installation erfolgt ist und in welchem Umfang die Installation erfolgt Nach der Zusammenfassung der in Abbildung 4 5 noch zweifach dargestellten Laufwerksaus wahl zu gemeinsamen Stellen in Abbildung 4 6 erfolgt eine von der Vorgeschichte abh ngige Verzweigung in unterschiedliche Startmeldungen Die Vorgeschichte ist in Abbildung 4 6 nicht mehr unmittelbar aus den Stellen an denen die Verzweigung erfolgen soll e20 und e21 abzuleiten D h die Situation des Dialogsystems wird durch diese Stellen alleine nicht mehr ausreichend repr sentiert Es wird an den Stellen zus tzliche Information erforderlich die f r die Entscheidung des weiteren Dialogablaufs abgefragt werden kann Um diesen Mechanismus zur Abfrage der Historie in unserem Modell zu beschreiben ben tigen wir neben den bisher vorgestellten Elementen des Grafen nun ein neues Sprachmittel das wir in Form so genannter Conditions einf hren wollen siehe 4 1 3 Abbildung 4 6 Zusammenf hrung der beiden Darstellungen des Laufwerksdialogs mit anschlie ender historienabh ngiger Verzweigung Die Darstellung ist hier so gew hlt dass der Laufwerksdialog mit all seinen Dialogstellen nur einmal gezeigt wird und er aus verschiedenen St
32. Euphorie weicht jedoch h ufig einem Stadium der Ern chterung Dies gilt sowohl f r Systeme zum Rapid Prototyping und Rapid Development als auch f r Systeme die einen 10 0 0 Allgemeine Problemstellung streng modellbasierten Ansatz zur Top down Analyse mit mehr oder weniger automatischer Umsetzung in die Implementierung erlauben Auch sogenannte Round Trip Systeme die iterativ eine Umsetzung des Modells auf die Implementierungsebene und eine R ckf hrung implementierter Codesequenzen auf die Modellebene versprechen haben bisher keinen Durchbruch in der breiten Anwendung gefunden Die Gr nde daf r sind vielseitig Einer davon ist sicherlich dass keines der auf dem Markt verf gbaren Systeme eine Sprache bzw Technik bietet mit der ein logisches Design des Dialogs insbesondere auch der Dialog dynamik unabh ngig von einer konkreten Wahl der spezifischen Implementierung der Oberfl che m glich wird Die zur Zeit als der Standard der Modellierung geltende UML Unified Modelling Language bietet zwar eine Reihe verschiedenster Diagramme f r ein objektorientiertes Design der Anwendung Auf die spezifische Notwendigkeit einer Darstellung des Dialogs wird aber wenig Wert gelegt Die daf r manchmal empfohlenen State Charts stellen keine befriedigende L sung dar siehe sp ter In der Regel verl sst man sich im Projekt auf eine dann meist unvollst ndige prototypische Realisierung ohne vorangehendes systematisches Design das auch mit p
33. In der Ellipse rechts oben sieht man die WYSIWYG Darstellung im Fensterausschnitt darunter mittlere Ellipse den entsprechenden HTML Code und im Eigenschaftenfenster des Editors die Attribute des Hyperlink Tags mit dem Attribut Hyperlink Ellipse unten links 16 1 0 Einsatz von Systemen zum Rapid Development partner hotels off room rata See Details Rent five vehicles fom Global in the next month arf you may qualify for free gifs See GE Indulge yourself by travelling in one of our Rental Classic Automobiles with one of our chauffeurs to whisk you to wherever your destination might be Safety Tips Global Car Rental is concerned about the safty of our loyal customers Read hese tips to ensure your next trip goes off without a hitch 73 rate See Details 24 lt hr SIZE 3 gt 2 Rent five vehicles rom blobal in the next month and you may qua gt 76 for free gifts lt a href gt See Details lt a gt lt td gt Hyperlink Definition n Lex 4 gt lt body gt lt table gt lt tr gt lt td gt lt table gt lt tr gt lt td gt lt a gt v Eigenschaften X Gr e Keine FAL BI Q uperlink Jindex htm gare 30 Zel 8051360 sKTI0Sck Abbildung 1 2 Attribute zur Definition der Dialogdynamik in HTML basierten Systemen am Beispiel Dreamweaver der Firma Macromedia 1 0 1 2 Ereignisgesteuerte Routinen Die wohl am meisten verwend
34. Programming by Example System EAGER CYPHER91 und Programming by Demonstration z B System Pursuit MODUG93 umschrieben werden k nnen Das System DENIM ist ein Beispiel eines Sketchingsystems zum Entwurf von Webseiten mit dem Kernmodell von Seiten und berg ngen die durch Pfeile dargestellt werden In der Arbeit von Lin Thomson und Landay LINTHO2 werden am Beispiel DENIM einige Nachteile heutiger Sketchingsysteme diskutiert wie die Explosion von berg ngen bei Darstellung aller m glichen WYSIWYG Kombinationen und redundanter Darstellung immer wiederkehrender Seitenelemente Um diesen Nachteilen zu begegnen werden in DENIM zus tzliche Sprachelemente eingef hrt n mlich so genannte Components Conditionals und Enhanced Arrows Components in DENIM Components in DENIM sind vermutlich in Anlehnung an den g ngigen Component Begriff Dialogelemente die der Designer einmalig in Storyboarding Technik definiert Custom Components z B eine Check Box mit zwei Zust nden On und Off und die er in anderen Dialogelementen Internetseiten wieder verwenden kann Daneben gibt es entsprechend so genannte Intrinsic Components die bereits im System vordefiniert vorliegen Conditionals in DENIM Conditionals erm glichen in einem benutzerfreundlichen Dialog die Definition von Bedin gungen Z B k nnen Zustandskombinationen mehrerer Checkboxen auf einer Seite jeweils einer Bedingung in einem so genannten Condition Stack
35. Stelle und Wert unterscheiden Wenn Typ und Stelle bereits aus der aktuellen Situation heraus gegeben sind bleibt nur noch den Wert zu bestimmen F r die Wertebestimmung f hren wir nun Funktionen ein die hnlich zu den oben beschriebenen Conditions auf Basis von aktuellen Werten an bestimmten Stellen einen der m glichen Alternativwerte bestimmen der f r die Realisierung des anstehenden Folgeereignisses ben tigt wird Eine derartige Funktion wollen wir bertragungsfunktion oder Propagationsfunktion nennen da sie f r die Werte bertragung bzw f r die Propagation eines bestimmten Ereignisses durch das System verwendet wird Formal bedeutet dies folgende Modellerweiterung P Menge von bertragungsfunktionen Propagationsfunktionen paisi der Form Pesis WSpesi ss gt W Pais ist jeweils einem Stellen bergang si sj siehe oben zugeordnet WSpesi sj Ist hnlich zur Definitionsmenge von Conditions siehe oben eine Menge von Wertezuordnungen auf einer f r die bertragungsfunktion definierten Stellenmenge Sp si sj Mit einer bertragungsfunktion wird es nun dem System erm glicht zu entscheiden welches der m glichen alternativen Schreibereignisse des Systems an einer bestimmten aktuellen Folgestelle propagiert werden soll Dabei bestimmt die Propagationsfunktion den Wert des Ereignisses Typ und Stelle des Ereignisses ergeben sich aus der brigen Modelldarstellung die Propagationsfunktion ist eindeutig einem S
36. Stellennamen genannt werden allerdings nicht nur dazu verwendet um es einem Benutzer zu erm glichen die Stellen im Diagramm anzusprechen Mit Stellennamen kann z B auch Rekursivit t ausgedr ckt werden Taucht eine Stelle innerhalb einer zusammengesetzten Stelle mit gleichem Bezeichner auf handelt es sich um einen rekursiven Aufruf Auf eine formale Darstellung der Rekursivit t wird in dieser Arbeit verzichtet da es sich um eine bekannte Technik handelt wie sie auch in g ngigen Programmiersprachen eingesetzt wird 88 3 3 Grafische Darstellung N Gesamtdialog Abbildung 5 1 Hierarchie von Stellen in geschachtelten Rechtecken Ein Ereignisstellendiagramm zeigt Dialogstellen in hierarchischer Struktur mittels in sich geschachtelter Rechtecke Der Stellenbezeichner Stellenname ist entweder au en annotiert oder im Rechteck nach M glichkeit links oben angebracht Eine Stelle ist eindeutig ber den kompletten Pfad der Bezeichner in der Hierarchie definiert D h Teilstellen mit unterschiedlichen bergeordneten Stellen k nnen denselben Bezeichner besitzen Beispiel in der Abbildung zwei Stellen mit Bezeichner DialogD unter DialogA und DialogB Gerichtete beschriftete Kanten f r ffne und Schlie erelationen Bei Eintritt eines Ereignisses an einer Stelle kann eine andere Stelle ge ffnet oder geschlossen werden Im formalen Modell wird dies durch die beiden zweistelligen Relationen RO und RC ausgedr ckt Grafisch wird das
37. System synchron ausgel sten bergang handelt Wenn wir uns nun von einer indifferenten Darstellung aller m glichen mehr oder weniger willk rlichen Ereignisfolgen l sen und etwa nur die vom System oder nur vom Dialogsystem verantworteten unmittelbar bewirkten berg nge beschreiben und die vom Benutzer und ggf auch der Applikationslogik bewirkten berg nge nur soweit beschreiben als sie von der Dialogkomponente erm glicht werden m ssen gewinnen wir eine wesentlich effizientere und bersichtlichere Darstellung 4 2 1 Kriterien der Dialogdynamik Wir wollen im Folgenden einige informelle Grund berlegungen dazu anstellen wieweit es m glich bzw notwendig oder sinnvoll ist im Dialogmodell unterschiedlich begr ndete Zusammenh nge der einzelnen Dialogschritte darzustellen und welche unterschiedlichen Sprachelemente dazu von Nutzen sein k nnten Die Untersuchung der Zusammenh nge dient dem Ziel diese beschreiben zu k nnen und damit in einem Modell zu erfassen Letztlich resultiert auch daraus welche Sprachelemente wir im Modell zur Beschreibung der Dynamik ben tigen Insbesondere ist zu pr fen inwieweit der bisher eingef hrte Ereignisbegriff den wir anstelle des gerade benutzten Begriffs Dialogschritt im Modell verwenden durch andere Sprachelemente erg nzt oder ersetzt werden muss um die Kontrolle und Steuerung des Dialogablaufes zu beschreiben 4 2 1 0 Ereignisse bewirken Ereignisse Wenn wir vom Grundmodell ausgehen
38. Um das Ereignis ber einen bestimmten Zeitraum ablesen zu k nnen wird es in Form eines Wertes eines zugeordneten Widgetattributes gespeichert In bestimmten F llen handelt es sich dabei nicht um Widgetattribute im strengen Sinn sondern um allgemein gesprochen bestimmte der Widgetinstanz zugeordnete Ressourcen Beispiel List Widget mit List Items Ebenso kann das Ereignis auch in manchen F llen einer bestimmten Ressource z B Selektion eines List Items zugeordnet werden Um also gem unserem Modell ein Ereignis zu realisieren f hren wir zun chst diese Abbildung auf Widgetinstanz Widgetklasse Widgetereignis Ressourceereignis Widgetattribut Widgetressource in Java Property und Attributwert Ressourcewert durch Basierend auf dieser Information kann der Codegenerator dann den notwendigen Code erzeugen um diese Zuordnung zum richtigen Zeitpunkt im Programmablauf zu realisieren 152 10 2 Schritte zur Codegenerierung Gem Modell ben tigen wir im Wesentlichen Code der zum einen ein Ereignis oder mehrere an einem bestimmten Widget erm glicht der also das Widget samt zugedachtem Ereignis verf gbar macht und die Darstellung des Wertes f r das bestimmte Widgetattribut bewerkstelligt Zum anderen ben tigen wir Code der umgekehrt die Darstellung eines Ereignisses oder auch mehrerer Ereignisse verhindert und letztlich die dem Ereignis zugedachten Ressourcen freigibt Konkret bedeutet dies dass ein Widget bzw eine Wid
39. VarAspects Card und dass VarS 1 also die Variation genau eine Exemplarstelle besitzt Dann bestimmen sich die Elemente der Konfiguration mConfig wie folgt Ss S S U Sneu U SSubneu mit Sneu c SUniv Sneu endlich projS varConfig SvarConfig und varConfig varFunc e mConfig und Sneu SvarConfig S projS sei die Projektion von S definiert auf der Menge der Konfigurationen MConfigs projS MConfigs Potenzmenge SUniv 179 Anhang E Wir wollen im Folgenden generell die Projektionen der einzelnen Tupelelemente einer Konfiguration mit proj lt Tupelelement gt bezeichnen also projE projRO usw F r jede Stelle aus Sneu die nicht bereits in S enthalten ist echte neue Stelle wird dieselbe Teilstellenstruktur angenommen die auch die Exemplarstelle besitzt D h es werden in die Modellkonfiguration entsprechende neue Teilstellen aufgenommen SSubneu ist die Erweiterung der Stellen aus Sneu um ihre Teilstellen entsprechend der Hierarchie der Exemplarstelle svar D h es gibt jeweils eine bez glich der Hierarchie strukturtreue bijektive Abbildung der Menge der Teilstellen SSubsvar von svar auf jeweils die Menge der Teilstellen SSubsne f r ein bestimmtes sneu aus Sneu SSub ist wie folgt definiert SSub s s s aus HS dabei definiere HS die transitive und reflexive H lle von HS HS HS ist die in der neuen Konfiguration mConfig sich ergebende hierarchische Relati
40. Weise kann im ESD ein ffnen und Schlie en einer Stelle grafisch durch den Stellen bergang angezeigt werden INTERACTION_OBJECT FillinForm is WARS position but new INTERACTION_OBJECT FillinButtonf position gt position oldpw new INTERACTION_OBJECT FillinFieldf position gt position HeightfFillinButton legend gt Old password word gt newpw new INTERACTION_OBJECT FillinField position gt position HeightfFillinButton HeightfFillinField legend gt New password METHODS Draw DrawBorder position TOKENS oOERRORMSG ShowErrorMsg Please enter old password first SYNTAX Main Act ChangePasswdioldpw word newpw word Cond oldpw word Cond oldm oERRORMSG vord end INTERACTION_OBJECT Abbildung 9 2 Spezifikation eines Dialogs zur Passwort nderung nach Jacob JACOBS86 1 Teil Definition des Formulars zur Passwort nderung FillinForm Der Abschnitt zur Variablendefinition TVARS enth lt neben der Variablen position die drei Component Objects but oldpw und newpw Definition siehe n chste Abbildung Im Methoden Abschnitt gibt es eine Methode Draw zum Zeichen des Formularrahmens F r das einzige Token des Formulars OERRORMSG ist im TOKEN Abschnitt die Implementierung angegeben die die Ausgabe einer Fehlermeldung bestimmt Im Syntaxdiagramm Abschnitt SYNTAX erfolgt aus dem Startzustand der als Eingabezustand mit gekennzeichnet i
41. abgesehen vom neu hinzugekommenen Element Vars das oben beschrieben ist Dabei ist S aus ESM jeweils durch SUniv zu ersetzen SStart ist dabei die Menge der lokalen und globalen Startstellen im ESM Kap 5 mit So bezeichnet SStart darf nicht mit So in mkonfigo verwechselt werden Die SStart sind jeweils Teilmenge von S und ndern sich von Konfiguration zu Konfiguration weil z B ggf neue Stellen eingef hrt werden und oder die HS variieren Das sich ergebende erweiterte ESM Modell das wir ESMD ESM Dynamisch nennen wollen stellt sich als folgendes Tupel dar ESMD SUniv T W FMConfigs C P wobei FMConfigs die Folge der Modellkonfigurationen mConfig i 0 1 ie N darstellt mit mConfigo als fest vorgegebener Startkonfiguration T W C P seien wie im ESM Kap 5 definiert nderungen der Funktion dyn gegen ber der Funktion des ESM aus Kapitel 5 Bevor der bergang von q nach q und der bergang von oS zu S durchgef hrt wird wird eine Variation der Teilkonfiguration S SStart E RO RC HS Varsi eRO ERC KRO KRC TRO S vorgenommen falls das Ereignis e eine Variation ausl st Dies bedeutet dyn ei mConfig 178 Anhang E Formale Darstellung der Exemplarvariation Sini SStarti Em1 ROi1 RCi 1 HSi 1 Vars H EROj 1 ERCi 1 KROj 1 KRCi 1 TRO oStarti qi Si 1 eNeXti 1 mit qi Sir enextj core e variation e mConfig core sei
42. auch oben festgestellt haben dass es aus logischen Gesichtspunkten heraus gleichg ltig ist ob zun chst Postleitzahl oder Ort eingegeben werden d rfte es in der Erwartung des Benutzers liegen dass bei einer Adresserfassung die Postleitzahl zuerst und unmittelbar danach der Ortsname einzugeben ist Damit ergibt sich eine entsprechende r umliche und auch zeitliche Anordnung der Erfassungsdialoge Auch die F higkeiten und Kenntnisse des Benutzers bestimmen die Aufteilung der Information in einzelnen Dialogschritten Dies beginnt bereits z B mit den physiologischen Gegebenheiten des Menschen zur Wahrnehmung von Information Die begrenzte M glichkeit zur gleichzeitigen Aufnahme von Information durch den Menschen legt es nahe die Information entsprechend zu portionieren und ggf auch zeitlich hintereinander anzubieten magical number seven etc Wir wollen hier nicht weiter auf physiologische Aspekte der Wahrnehmung und allgemein auf software ergonomische Aspekte der Dialoggestaltung eingehen Dazu sei auch auf Literatur zum Thema Software Ergonomie Erarbeitung von Benutzermodellen etc verwiesen ZEIDL92 DIN88 ISO90 66 4 2 Logische Abstraktion Wir wollen bei obigem Beispiel der Auftragserfassung bleiben Sicherlich ist es nicht optimal den 20 Zoll Bildschirm mit s mtlichen erdenklichen Informationen zu einem Auftrag zu berfrachten Stattdessen ist es sinnvoll die Information in logisch eing ngige Einheiten aufzuteilen und z
43. auf Felder positionieren l sst Formulardialoge bieten durch das parallele Angebot der Felder am Bildschirm gegen ber dem Frage Antwort Dialog und dem Kommandodialog einen gr eren berblick f r den Benutzer sowie ein bestimmtes Ma an Dialogf hrung Grafischer Dialog Dialogart die auf Basis hochaufl sender Bildschirme mit Pixeltechnik die Darstellung grafisch gestalteter Dialogobjekte bietet F r die Eingabe stehen dem Benutzer neben der Tastatur im Allgemeinen Ger te Maus Griffel Pen zur Selektion und direkten Manipulation dieser grafischen Objekte zur Verf gung Grundlage des grafischen Dialogs ist die so genannte Fenstertechnik die es erlaubt den Bildschirm in verschiedene unter Umst nden auch berlappende Teilfl chen zu unterteilen Im grafischen 163 12 Glossar Dialog kann die Vorstellungswelt des Benutzers durch die Nachbildung realer Umgebungen und Objekte auf den Bildschirm bertragen werden Desktop Metapher etc Kommandodialog Dialogart in der der Benutzer Auftr ge an das System in Form von Kommandos bergibt und gegebenenfalls das System in einer R ckmeldung das Ergebnis des Auftrags bekannt gibt Ein Kommando wird dabei in der Regel in textueller Form bestehend aus einem Kommando Schl sselwort und danach folgenden Kommandooptionen in einer Kommandozeile formuliert Ein Charakteristikum des Kommandodialogs ist dass der Benutzer weitgehend die Initiative im Dialog besitzt und das System reagiert D
44. beeinflussen Wir nehmen in unser Grundmodell zwei Typen von Relationen auf n mlich zum einen Relationen die eine Bestandteilshierarchie ausdr cken die wir jeweils zwischen Dialogereignissen zwischen Dialogstellen und Dialogwerten definieren k nnen Der zweite Typ ist der einer Folgerelation deren Auspr gungen jeweils Folgen ebenfalls zwischen Ereignissen Stellen und letztlich auch Werten definieren Besitzt einerseits die Bestandteilshierarchie einen eher statischen Charakter dient andererseits die Folgerelation zur Beschreibung der Dynamik 3 0 3 0 Hierarchie Hierarchie der Ereignisse Ereignisse k nnen aus Ereignissen so genannten Teilereignissen bestehen und werden dann zusammengesetzte Ereignisse genannt Diese Beziehung zwischen zusammengesetztem Ereignis und Teilereignis sen ergibt die bliche Bestandteilshierarchie Der Dialog der im Modell beschrieben werden soll kann als zusammengesetztes Ereignis betrachtet werden das alle anderen im Modell beschrieben Ereignisse als unmittelbare oder mittelbare Teilereignisse enth lt Ereignisse die keine Teilereignisse enthalten werden primitive Ereignisse genannt Hierarchie der Stellen Stellen k nnen ebenso in einer Stellenhierarchie geordnet werden Durch die Stellenhierarchie k nnen Hierarchien von Ereignismengen und Ereignissen induziert werden Alle an einer primitiven Stelle stattfindenden Ereignisse definieren eine der Stelle zugeordnete Ereignismenge Alle an den Teilst
45. bergangsfunktion f r das hierarchische Ereignisstellenmodell zu sehen Im Wesentlichen sind dabei die Relationen RO und RC durch ROH und RCH ersetzt 83 5 Ereignisstellenmodell 5 1 Abbildung eines deterministischen endlichen Automaten auf die Ereignisstellendarstellung Sei A ein deterministischer endlicher Automat mit endlicher Zustandsmenge QA Anfangszustand qo QA Endzust nden FA c QA TA Menge der Token Eingabesymbole und A der bergangsfunktion 8A QA x TA gt QA Dann l sst sich ein Ereignisstellenmodell ESA wie folgt konstruieren F r jeden Zustand q QA wird genau eine Stelle s S konstruiert Die go entsprechende Stelle so wird Anfangsstelle von ESA also So so Ebenso werden die den Endzust nden entsprechenden Stellen als Endstellen in ESA ausgezeichnet Dazu m ssen wir allerdings unser Ereignisstellenmodell um die M glichkeit der Auszeichnung von Endstellen erweitern was aber keine wesentliche nderung des oben vorgestellten Modells bedeutet F r jedes Token t e TA und jeden Zustand q QA der das Token t als Eingabe akzeptiert definieren wir ein Ereignis eg E mit eq Wi Sy Ip Dabei sei w ein jedem Token zugeordneter eindeutiger Wert aus W z B k nnen wir W als Teilmenge der Menge der nat rlichen Zahlen w hlen s ist die dem Zustand q zugeordnete Stelle aus S F r jeden bergang A q t q sehen wir ein Paar sq sg in RO vor und erweitern die
46. chenst ck am Bildschirm repr sentiert Es gibt bei Widgets wie bei Ereignisstellen eine hierarchische Beziehung Parent Child Beziehung die meist durch die Einbettung des untergeordneten Widgets Child Widgets innerhalb der Fl che des bergeordneten Widgets Container Widgets erkennbar ist wie das auch bei der gew hlten Darstellung von Teilstellen im ESD der Fall ist Ebenso sind den Widgets hnlich wie den Ereignisstellen bestimmte Ereignisse zugeordnet die Aktionen bzw Ereignisse an anderen Widgets bzw Stellen ausl sen k nnen Die heute in g ngigen Baukastensystemen Toolkits Frameworks gebotenen Widgets k n nen als Beispiel einer Konkretisierung von Stellen in unserem Modellsystem betrachtet wer den Im Zuge der Realisierung eines konkreten Dialogs zur Laufzeit k nnen wir also Modell stellen auf Widgets eines Baukastensystems leicht abbilden Wesentlich f r das Verst ndnis des Stellenbegriffs wie er im ESM verwendet wird ist allerdings dass diese Abbildung nicht immer eine 1 1 Abbildung einer Modellstelle auf eine r umlich verstandene Laufzeitstelle bzw auf ein Widget bedeutet Mehrere Stellen im Modell k nnen mitunter einem Widget entsprechen und umgekehrt kann eine Modellstelle auf mehrere Widgets zur Laufzeit umgesetzt werden Dies liegt daran dass ein Widget oft mehrfach f r die Darstellung von Ereignissen verwendet wird f r deren Beschreibung wir jeweils eine eigene Modellstelle verwenden und dass umgekehrt
47. der Benutzer Information an einer Dialogschnittstelle eingibt bzw verf gbar macht Sehen wir das Ereignis als Ergebnis einer Operation k nnen wir diese im bertragenen Sinne auch als Schreiben des Benutzers bezeichnen Ausgabe Entsprechend ist ein Ausgabeereignis dann zu verzeichnen wenn das System Information an einer Dialogschnittstelle zur Verf gung stellt Die zugrunde liegende Operation kann als Schreiben des Systems bezeichnet werden Wenn wir Eingabe und Ausgabe als Ereignisse in unser Modell aufnehmen entspricht dies einer symmetrischen Sicht der Dialogschnittstelle zwischen den Dialogpartnern Benutzer und System bzw Applikationslogik Die ersten beiden Typen von Dialogereignissen reichen in vielen F llen aus um auf einer mehr oder weniger abstrakten Ebene die Vorg nge des Informationsaustauschs hinreichend exakt zu beschreiben Mit dem Vorgang der Eingabe wird meist implizit angenommen dass damit die Entgegennahme der Information durch das System verbunden ist Ebenso wird meist mit der Ausgabe von Information die Wahrnehmung derselben durch den Benutzer angenommen Streng genommen m ssen wir jedoch zwischen dem Vorgang des Schreibens auf der einen Seite und des Lesens der Information auf der anderen Seite unterscheiden Dies ist zumindest dann notwendig wenn wir ausdr cken wollen dass die Abnahme der Information durch den Benutzer oder das System zu einem anderen Zeitpunkt erfolgt als das Zuf hren der Information also d
48. der exakten Laufzeitdarstellung bereits zum Definitionszeitpunkt weitgehend ann hern D h die Definition des dynamischen Verhaltens geschieht durch ein Vorspielen ein Durchlaufen des dynamischen Verhaltens in m glichst echter Zeit Der Modellierer des Systems erzeugt also bei der Definition nicht zun chst ein statisches Programm Sondern er spielt Schritt f r Schritt Ereignis f r Ereignis an simulierten realen Stellen den echt zeitlichen Ablauf des gew nschten Systems durch hnliche Ans tze sind in der Methode Programming by Example CYPHE91 oder bei der Makroaufzeichnung in Excel MICROO1 wieder zu erkennen Dieser zun chst vielleicht etwas extrem anmutende Ansatz ist f r viele F lle durchaus reali sierbar Stellen wir uns einen Modelleditor vor der neben dem Zeichnen statischer Widgets auch erlaubt Kommandos abzusetzen die Ereignisse auf diesen Widgets bewirken wie z B ffnen Setzen oder L schen eines Wertes etc Ereignisse die dann sofort am Bildschirm umgesetzt und aber auch protokolliert werden Es handelt sich dann bei diesem Modelleditor um im Wesentlichen nichts anderes als einen Kommandointerpreter der auf Basis mehr oder weniger primitiver konkreter Dialogereignisse auf konkreten Dialogstellen operiert Im Idealfall k nnen die Kommandos mit Hilfe der Technik der direkten Manipulation an der Dialogstelle durchgef hrt werden Z B kann das Setzen eines Wertes in einem Textwidget durch direktes Hineinschr
49. derselben primitiven Stelle seien Ereignisse der Typen Os oder Ig gleichzeitig mit Ereignissen des Typs Ms nicht erlaubt Eine nicht zusammengesetzte Stelle an der das System schreibt ist also eindeutig entweder eine verborgene Hilfsstelle oder eine Stelle an der Dialogoberfl che 4 1 3 2 bertragungsfunktionen Propagationsfunktionen Da wir in unserer Modelldarstellung in der Regel alternative Ereignisse an ein und derselben Stelle zusammengefasst haben ben tigen wir nicht nur einen Entscheidungsmechanismus f r 57 4 Bottom up Modellierung und Abstraktion die Wahl alternativer Stellen berg nge sondern auch f r die Wahl alternativer Ereignisse D h ist z B im Dialog eine Situation erreicht in der das System eine Ausgabe an einer Stelle durchf hren soll an der potentiell unterschiedliche Ausgaben gemacht werden k nnen braucht das System eine Handhabe um zu entscheiden welches Ereignis propagiert werden soll Diese Entscheidungsnotwendigkeit gilt wiederum nicht nur f r Ausgabeereignisse sondern generell f r alle Ereignisse die vom System zu realisieren sind und f r die Alternativen bestehen also auch f r Schreibvorg nge an Nicht Dialogstellen Hilfsstellen der Dialogkomponente Die Entscheidung f r ein Ereignis alternativer Ereignisse an einer Schreibstelle ist quivalent zur Entscheidung welcher Wert an die Stelle bertragen werden soll Dies resultiert daraus dass wir in unserem Modell Ereignisse nur nach Typ
50. des Informationsaustausches in einer Anwendung im Sinne der Aufgaben stellung einer Anwendung wesentlich oder bedeutend sind Es sind also Merkmale des Dialogs die zur Entscheidung daf r herangezogen werden k nnen ob der Dialog f r die Erf llung der Aufgabe der Anwendung geeignet ist Unwesentlich oder unbedeutend sind Merkmale die zur Durchf hrung der Aufgabe unn tig sind oder Merkmale die durch andere ersetzt werden k nnen ohne die Erf llung der Aufgabenstellung zu beeintr chtigen Die Merkmale des logischen Dialogs ergeben sich beispielsweise aus einer systematischen Analyse der Aufgabenstellung einer Anwendung und insbesondere des sich daraus resultierenden notwendigen Informationsaustausches Unwesentlich sind besonders Merkmale die eine bestimmte austauschbare Form oder Art des Dialogs einen bestimmten austauschbaren Dialogstil kurz ein bestimmtes austauschbares Layout siehe unten beschreiben Dabei nehmen wir an dass die eigentliche Aufgabenstellung einer Anwendung im allge meinen nicht die Wahl eines bestimmten Layouts vorgibt Wesentlich sind in der Regel Merkmale die den Inhalt der im Dialog bermittelten Informati on beschreiben 26 2 0 Kernziele Dabei muss davon ausgegangen werden dass der Inhalt des Dialogs von der logischen Aufgabenstellung dem Aufgabenmodell einerseits und andererseits von der logischen Sicht der Benutzer dem Benutzermodell abgeleitet wird Durch ein Benutzermodell wird die log
51. die Funktion aus ESM Kap 5 die statt der beiden Parameter q und S als Parameter eine gesamte Modellkonfiguration mConfig aus MConfigs der Menge aller Modellkonfigurationen enth lt core Funktion core E MConfigs QE WSHist E core entsteht aus der Funktion aus Kap 5 indem die dort verwendeten Bezeichner S So E RO RC HS eRO eRC KRO KRC TRO als Bezeichner der Elemente einer Modellkonfiguration mConfig gesehen werden die als Parameter bergeben wird Ansonsten gilt entsprechend die Beschreibung in Kap 5 variation ist eine Funktion variation E MConfigs MConfigs die abh ngig von einem Ereignis e und einer Modellkonfiguration mConfig eine neue Modellkonfiguration mConfig bestimmt Die Funktion variation sei wie folgt definiert F r e E mConfig S SStart E RO RC HS Vars RO eRC KRO KRC TRO q S mConfig S SStart E RO RC HS Vars ERO ERC KRO KRC TRO q S und variation Funktion variation E MConfigs MConfigs gilt variation e mConfig mConfig lt falls nicht gilt e VarEvents mit var VarEvents VarS VarAspects VarType varFunc f r ein var Vars dann mConfig mConfig andernfalls Wir nehmen zun chst an es gibt genau ein var f r das e e VarEvents gilt Au erdem nehmen wir an dass diese Variation vom Typ inkrementell ist also VarType inc dass
52. die letztlich Ereignisse eines bestimm ten Typs mit bestimmten Werten repr sentieren Diese Stellen sind wie bereits in Abschnitt 3 0 1 erw hnt eine Abstraktion einer konkreten Ressource mittels derer zur Laufzeit die zugeordneten Ereignisse realisiert werden Allerdings ist in den Abbildungen mancher vorangehender Beispiele etwa dem Beispiel des Modells zur Auftragserfassung Abbildung 4 13 Abbildung 4 14 Abbildung 4 15 eine Darstellung zu sehen die einer m glichen konkreten Darstellung zur Laufzeit sehr nahe kommt Dies liegt im Wesentlichen daran dass das vorgestellte Modell der Ereignisstellen ESM mit einer Darstellung konkreter Dialoge durch bestimmte Widgets stark bereinstimmt Die Gr nde f r die bereinstimmung werden im folgenden Abschnitt diskutiert Danach zeigen wir anhand des Beispiels RadioButton wie ein Ereignisstellenmodell durch verschiedene Widgets zur Laufzeit realisiert werden kann und untersuchen im darauf folgenden Abschnitt die M glichkeit der Mischung konkreter Widgetdarstellungen mit abstrakten Ereignisstellen in einem Ereignisstellendiagramm 6 0 hnlichkeit von Stellendarstellung und Widgets Besondere bereinstimmung zwischen der Darstellung abstrakter Ereignisstellen im ESD mit konkreten Widgets liegt bei bestimmten h ufig verwendeten Widget Typen vor Textwidgets repr sentieren auf einer rechteckigen Fl che einen Eingabewert oder Ausgabewert in textueller Form Die Bedeutung bzw logische Einor
53. dies als Merge von Szenarien bezeichnen Die andere Art der Interpretation ist die dass wir mit den verschiedenen Stellen die auf eine Instanz abgebildet werden verschiedene Zust nde der Instanz meinen die prinzipiell voneinander zu trennende Aussagen beschreiben 10 2 1 0 Merge von Szenarienstellen Die Vereinigung mehrerer Stellen im Sinne von beispielhaften Szenarien setzt voraus dass die Aussagen an beiden Ereignisstellen nicht widerspr chlich sind bzw im Konfliktfall eine Aufl sung des Konflikts durch den Codegenerator vorgenommen werden kann So macht es z B keinen Sinn die Stellen mit unterschiedlichen Widgetklassen auszustatten In diesem Fall ist undefiniert welche der Klassen vom Codegenerator f r die Instanz gew hlt wird Die generelle Strategie ist dass alle Aussagen die an den einzelnen Stellen getroffen sind in der Instanz bernommen werden wenn diese nicht widerspr chlich sind Allerdings zeigt sich dass es mehrere M glichkeiten der Zusammenfassung der Aussagen mehrerer Stellen zu widerspruchsfreien Aussagen gibt Wie soll z B die Zusammenf hrung erfolgen wenn eine Stelle als Ausgabestelle f r einen Wert A eine andere gleichnamige Stelle als Eingabestelle f r Wert B definiert ist Hier haben wir die M glichkeit durch die Zusammenfassung eine Stelle f r sowohl Eingabe als auch Ausgabe beider Werte A und B zu bilden oder aber eine Stelle f r Ausgabe von A und nur von A
54. f hren m ssen wenn wir eine Wiederholung eines Ereignisses an besagter Stelle unmittelbar nach einem Ereignis an der Nachfolgerstelle oder unmittelbar nach einem Ereignis an der Stelle selbst erm glichen wir sagen auch er ffnen wollen Wir sparen nun wiederum eine Vielzahl sonst n tiger expliziter Definitionen von Kanten sprich Definitionen von berg ngen wenn wir auch annehmen dass eine Stelle solange verf gbar oder ge ffnet ist solange sie nicht explizit geschlossen wird D h das Eintreten eines Ereignisses an einer ohne Beschr nkung der Allgemeinheit primitiven Stelle f hrt nicht notwendig zum Schlie en dieser Stelle Ereignisse k nnen an der Stelle solange wiederholt werden bis die Stelle explizit geschlossen wird Dies bedeutet dass zwei Stellen A und B mit Folgebeziehung B folgt auf A zu nebenl ufigen Stellen werden sobald die nachfolgende Stelle B einmal z B durch ein Ereignis in A ge ffnet wurde In unserem Beispiel der Auftragserfassung bedeutet diese Interpretation dass die Teildialoge zum Erfassen der Kundendaten und der Auftragspositionen auch ge ffnet bleiben nachdem der Preis ermittelt und ausgegeben wurde 75 5 Ereignisstellenmodell 5 Ereignisstellenmodell Unter Einbeziehung der letzten berlegungen gelangen wir ausgehend von unserem Grundmodell Kapitel 3 zu einer Modelldarstellung des Dialogs die wir als Ereignisstellen modell oder Ereignisstellendarstellung bezeichnen wollen Deren g
55. f r Instrumentelle Mathematik an der Universit t Bonn H 2 1962 Parigot D Roussel G Jourdan M Duris E Dynamic Attribute Grammars Programming Languages Implementations Logics and Programs PLIP 96 Proceedings LNCS Springer 1996 166 13 Literaturverzeichnis PUERTA99 Puerta A Eisenstein J Towards a General Computational Framework for RUMBA91 SCHLU9S SCHREI9A SCHREI95 SCHREI97 SHEBA93 SIEMEN94 SZWILL97 Model Based Interface Development Systems IUI 99 Redondo Beach CA USA ACM 1999 Rumbaugh M et al Object Oriented Modeling and Design Prentice Hall 1991 Schlungbaum E Elwert T Modellierung von graphischen Benutzungsschnittstellen im Rahmen des TADEUS Ansatzes Software Ergonomie 95 Proceedings Teubner 1995 Schreiber S Specification and Generation of User Interfaces with the BOSS System in Cypher A Gornostaev Hrsg Proceedings East West International Conference on Human Computer Interaction EWCHI 94 ICSTI Moscow 1994 also in Human Computer Interaction Selected Papers EWCHIT 94 Conference Springer LNCS 876 Schreiber S The BOSS System Coupling Visual Programming with Model Based Interface Design in Paterno F Hrsg Proceedings Eurographics Workshop Design Specification Verification of Interactive Systems 1994 Carrara Italy June 8 10 1994 Springer Focus on Computer Graphics Series ISBN 3 540 59480 9
56. findet ben tigen wir wiederum ein Ged chtnis aus dem wir ermitteln k nnen an welcher Stelle der Subdialog aufgerufen wurde und wo demnach fortzusetzen ist Bei einer Hierarchisierung ber mehrere Stufen gelangen wir letztlich zu einem Ged chtnis das als so genannter Keller organisiert ist 4 1 1 1 Zusammenfassung von Teilgrafen Neben der Zusammenfassung einfacher Sequenzen bilden wir im Allgemeinen Hierarchien indem wir ganze Teilgrafen zu einer Stelle reduzieren D h in die Zusammenfassung werden auch alternative Dialogpfade mit einbezogen Sobald jedoch Alternativen der Dialogf hrung im Subdialog enthalten sind kann es nach Abschluss des Subdialogs und R ckkehr zur Aufrufstelle erforderlich sein zu unterscheiden welche der Alternativen im Subdialog gew hlt wurde Die Fortsetzung einer zusammengefassten Dialogstelle ist dann durch den inneren Ablauf Zustand der Dialogstelle bestimmt Dieser ist zun chst aus der Darstellung des Dialogs als gefaltete Stelle mit berg ngen zu Folgestellen nicht ersichtlich Um diesen Mangel an Information auszugleichen gibt es beispielsweise die M glichkeit 1 der besonderen Darstellung der Aufrufstelle des Subdialogs mit mehreren alternativen Anschl ssen d h wir sehen im Subdialog nicht eine einzige R ckkehrstelle vor sondern eine R ckkehrstelle f r jede der Alternativen Im Grafen des Subdialogs bedeutet dies f r jede Alternative einen Endknoten An der Aufrufstelle ist dann
57. hler mit aktuellem Wert n e N samt Druckknopf als eine Eingabestelle k nnen wir den logischen Wert des Ereignisses Knopf dr cken mit 1 bewerten und den Wert des Z hlers nach dem Eingabeereignis mit nt Wir gehen auch davon aus dass Speicherstellen in der Lage sind ihren einmal zugeteilten Wert ber einen gewissen Zeitraum beizubehalten so dass dieser Wert auch nach Eintreten weiterer Ereignisse an anderen Stellen an besagter Stelle abgelesen werden kann Au erdem nehmen wir an dass bestimmte Stellen bereits zum Startzeitpunkt eines Dialogs einen ablesbaren Wert besitzen Dies f hrt zur Annahme der Existenz einer partiellen Funktion zur Zuordnung eines Wertes zu einer Ereignisstelle s nach Eintreten einer Teilfolge von Ereignissen eo e1 i Sinnvollerweise k nnen wir annehmen dass diese Funktion zumindest dann nicht definiert ist wenn eine Ereignisteilfolge in keiner der Ereignisfolgen f e F als Anfang vorkommt Dass die Funktion als partielle eingef hrt wird geschieht aber deshalb weil wir davon ausgehen dass manche Stellen nicht ber den gesamten Zeitraum des Dialogs verf gbar sind o erlaubt uns also nur teilweise nach einem bestimmten Ereignis in einer Ereignisfolge fan einer Ereignisstelle s einen Wert abzulesen Wir fordern diese Funktion ohne zun chst eine Aussage dar ber zu treffen wie diese Funktion in einer Implementierung realisiert wird Ziel unseres Grundmodells ist es auch generell nicht dies
58. hren ist Da die Maximalanzahl aber sehr gro bzw unendlich sein kann ist diese L sung ungen gend Wird w hrend des Entwurfs eines Systems festgestellt dass der gemachte Ansatz nur einige konkrete F lle von einer noch nicht vollst ndig absehbaren Menge von F llen abdeckt ist in g ngigen Entwicklungssystemen ein bliches notwendiges Vorgehen dass der zun chst gemachte konkrete Ansatz verworfen und ein neuer Ansatz mit anderen Sprachmitteln begonnen wird Denken wir z B an die Darstellung von Icons in einer Toolbar In einem 112 7 0 Problemstellung fr hen Stadium des Systementwurfs seien die Icons der Toolbar bekannt und ihre Anzahl auf einige wenige beschr nkt Der Entwickler modelliert die Toolbar deshalb indem er beispielsweise in direkter Manipulation die konkreten bekannten Icons als fixe Teilelemente in die Toolbar legt Zu einem sp teren Stadium des Systementwurfs oder vielleicht erst nachdem das System bereits im Einsatz ist wird erkannt dass die Anzahl und damit auch die Auspr gung der Icons in der Toolbar variabel zu gestalten ist und unter Umst nden sogar vom Benutzer zur Laufzeit ver ndert werden kann G ngige Vorgehensweise ist dann dass die fix entworfene Toolbar aus der Anwendung beseitigt wird und stattdessen auf der Ebene einer Programmiersprache ein konstruktiver Ansatz zum dynamischen Aufbau der Toolbar gew hlt wird 7 1 Zielsetzung der Exemplarvariation Ziel ist nun zu einer allgemein g ltigen d
59. im Modell bereits bekannt in S enthalten angenommen und deren Eigenschaften bleiben unver ndert sieht man von dem Hinzu kommen der Rolle als ausl sende Stelle f r den Druckdialog ab Zum Unterschied waren im obigen Beispiel der Toolbaricons die Stellen Icons selbst Gegenstand der Variation und haben von der zu variierenden Modellstelle Eigenschaften bernommen 117 7 Exemplarische Darstellung und Variation Wir wollen dass von jeder Dialogstelle aus der Druckdialog ge ffnet werden kann Deshalb geben wir als Zeitpunkt der Variationsberechnung jeweils das ffnen jeder Dialogstelle an Wir fordern zu diesem Zweck von unserem System dass es in der Lage ist nicht nur konkrete voll qualifizierte Ereignisse als Zeitpunkte einer Variation zu akzeptieren sondern auch die Spezifikation von Ereignispatterns die implizit eine Menge von Ereignissen beschreiben In diesem Fall beschreibt das Ereignispattern Ereignisse mit beliebiger Stelle und konkret vorgegebenem Wert Tastenkombination Shift Print und konkretem Typ I e Shift Print Ip Als Variationsfunktion geben wir hier eine im System standardm ig vorhandene Funktion an die den Bezeichner der Stelle zur ckliefert an der das die Variation ausl sende Ereignis eingetreten ist Damit kann das System dann eine Implementierung vornehmen die bewirkt dass bei Eintreten der Tastenkombination Shift Print mit Focus auf dem gerade ge ffneten Dialogel
60. in Form von Hilfsstellen Pr dikate Conditions und Propagationsfunktionen die Hierarchisierung die Bildung von Schleifen und Rekursionen und die Einf hrung nebenl ufiger Stellen Hintergrund dieser berlegungen war es immer mit den vorliegenden Sprachelementen eine grafische intuitive Darstellung zu entwickeln wie dies in den vorangehenden Abbildungen bereits skizziert wurde ohne dass wir dort schon von formal definierten g ltigen Darstellungselementen eines Ereignisstellendiagrammes gesprochen haben Im Folgenden soll nun zusammenfassend gezeigt werden wie Ereignisstellenmodelle ESM s in eine grafische Darstellung mit Hilfe so genannter Ereignis Stellen Diagramme ESD s umgesetzt werden k nnen Dabei werden auch mehrere Varianten der Darstellung entwickelt Hierarchische Stellenstruktur Die wesentlichen grafischen Elemente dieser Darstellung bilden Rechtecke f r die Stellen die wiederum Rechtecke als Teilstellen enthalten k nnen Die Rechtecke sind ggf ber Pfeile gerichtete Kanten miteinander verbunden Kontrollflussaspekt Dabei ist ein Aspekt der Verbindung ber Pfeile die Darstellung des Er ffnens von Ereignissen und des Sperrens von Ereignissen an Stellen aufgrund von Ereignissen an anderen Stellen Wir k nnen dies als Aspekt des Kontrollflusses bezeichnen Dieser Aspekt entspricht in der oben entwickelten Modellsprache im Wesentlichen den Relationen RO und RC Datenflussaspekt Ein weiterer As
61. in diesem Fall von modellbasierten Systemen kurz Modellsyste men sprechen Wir werden im Folgenden wesentliche Vor und Nachteile beider Ans tze im berblick aufzeigen Auf einzelne Systeme bzw Modellans tze soll in sp teren Abschnitten noch einge gangen werden siehe Kap 9 Beide Extreme stellen zwei Ausgangspunkte f r eine Integration in der sp ter vorgestellten Systematik zur Modellierung und Realisierung in Ereignisstellendiagrammen dar 1 0 Einsatz von Systemen zum Rapid Development Rapid Development Systeme zur Realisierung von Dialoganwendungen zielen im Allgemeinen darauf mittels spezifischer Werkzeuge Spezialeditoren und problemspezifischer oft auch deskriptiver Sprachelemente h ufig auch mit grafischen Hilfsmitteln eine Dialoganwendung zu beschreiben um diese dann m glichst schnell und automatisch in entsprechenden Programmcode meist einer universellen Programmiersprache umzusetzen Eine umfassende systematische Klassifizierung derartiger Systeme soll hier nicht vorgenom men werden Wir wollen hier jedoch einige wesentliche Merkmale aufzeigen die f r die Ziel setzung dieser Arbeit von Bedeutung sind Insbesondere sollen wesentliche Ausdrucksmittel zur Darstellung von Dynamik in g ngigen Systemen zum Rapid Development angesprochen werden 1 0 0 WYSIWYG Darstellung statischer Dialogkomponenten Eine Vielzahl von Systemen zum Rapid Development von Dialogsystemen enth lt eine Komponente mit der die statisc
62. ist dass CurrentJobName auch eine Eingabestelle repr sentieren soll liegt in der Entscheidung ob die nderung des Jobnamens durch den Benutzer erlaubt sein soll oder nicht Die Teilstellen JobStepName SourceStepl und SourceStep2 der jeweiligen Stellen JobStep1 und JobStep2 sind Stellen die sowohl die Ausgabe als auch die Eingabe von Werten erlauben 8 2 2 Hilfsstelle SaveToModel Durch die Kennzeichnung mit Ereignistyp M ist die Ereignisstelle SaveToModel als Hilfsstelle definiert die f r den Benutzer unsichtbar ist Die Stelle repr sentiert letztlich den im System verborgenen Ablauf einer Ereigniskette In der Implementierung realisiert die Stelle das Abspeichern der im Dialog JobStepDetails neu eingegebenen oder ge nderten Werte Dabei ist es nicht die Intention des Dialogmodells den genauen inneren Ablauf der Ereignisstelle SaveToModel darzustellen Es soll hier lediglich der Ansto dazu definiert werden Dazu wird mit dem Er ffnen dem Start der Stelle der Wert der Stelle JobStepDetails JobStepName an die Teilstelle JobStepName von SaveToModel bergeben 8 2 3 Variationen Dynamische Belegung der Werte ber Variation Woher kommen nun die Werte an den Ereignisstellen Prinzipiell kann ein Wert an einer Stelle entweder als Konstante im Modell bereits sozusagen a priori festgelegt werden oder die Bestimmung des Wertes kann erst zur Laufzeit erfolgen In letzterem Fall kann die Darstellung im Diagramm h chstens ein Exempla
63. ist die Dialogstruktur auf der Ebene der Fenster bzw so genannter Sichten ZIEGLE93 die jeweils einen zusammenh ngenden Aufgabenkomplex f r den Benutzer im Dialog umfassen Er unterscheidet die Fensterebene von der Objektebene die primitive Dialogobjekte in den Fenstern z B Buttons umfassen Die Dynamik auf Objektebene wird nicht mit Netzen sondern mithilfe so genannter Constraints HUDS89 beschrieben wobei ein Teil der Dynamikbeschreibung letztlich einer Programmiersprache berlassen bleibt die in einem Ziel System UIMS verf gbar ist Constraints f r Mikrodialog So genannte One way Constraints legen prinzipiell die Abh ngigkeit des Wertes einer variablen Gr e 0 B d A linke Seite von anderen variablen Gr en in Ausdruck auf rechter Seite fest und sorgen f r die permanente G ltigkeit der definierten Abh ngigkeit ndert sich der Wert einer Gr e auf der rechten Seite sorgt der Constraint Mechanismus automatisch f r die Neuberechnung des Wertes der Variablen auf der linken Seite Janssen verwendet Constraints f r die Belegung von Variablen bzw Werten der Attribute auf der Objektebene beispielsweise f r die Steuerung der Sensitivit t von Eingabewidgets Buttons etc und die Werte von Ausgabewidgets z B Labels in Abh ngigkeit von Ausdr cken ggf mit Bedingungen die wiederum auf Variablen oder Attributwerte von Objekten zur ckgreifen Vergleich mit ESD hnlichkeiten finden sich bei Ereignisstellen Diagra
64. jeweils eine der Eingaben zu einem Zeitpunkt erfolgen kann Das gleiche gilt f r die Ausgabe Die Visualisierung des aktuellen Zustands f r den Benutzer erfolgt ber die Ausgabestellen Eine Abbildung der abstrakten Stellen auf konkrete Stellen zur Laufzeit kann nun in unterschiedlichsten Varianten erfolgen Wir wollen im Folgenden zwei Varianten vorstellen Dabei gehen wir davon aus dass uns zur Implementierung ein Baukastensystem mit Widgets z B ohne Beschr nkung der Allgemeinheit Widgets der Swing Klassen in Java FISCHEO00 zur Verf gung steht 6 1 0 Konkretisierung als Instanz der Klasse JRadioButton Alle vier Modellstellen werden auf eine Instanz der Klasse JRadioButton abgebildet Zum Startzeitpunkt wird der RadioButton instantiiert und in den Zustand selected false versetzt Der im Modell dargestellte Dialog ben tigt bei einer Implementierung mithilfe der Klasse JRadioButton lediglich dieser Instantiierung Alle durch das Modell ausgedr ckten 104 6 1 Abbildung der Ereignisstellen auf konkrete Widgets wesentlichen Merkmale des Dialogs werden allein durch die Implementierung der Klasse selbst repr sentiert und bed rfen keines zus tzlichen Implementierungsaufwands D h die Ausgabe also die Visualisierung des Wertes Aus Stelle S1 wird mit dem Zustand des Buttons selected false erreicht entsprechend die Visualisierung von An Stelle S gt ber den Zustand selected true Die beiden Eingabe
65. r umliche Ressource auf k nnen wir diese Ressource zur gleichzeitigen Darstellung mehrerer Dialogereignisse durch Aufteilung der Bildschirmfl che in mehrere Felder verwenden Wir ordnen dann im realen Ablauf den Dialogereignissen unterschiedliche rtliche Stellen zu Alternativ dazu ist es jedoch oft m glich dieselben Dialogereignisse in nur einem Feld zeitlich hintereinander darzustellen Damit ordnen wir den Ereignissen unterschiedliche zeitliche Stellen genauer Zeitabschnitte unter Verwendung einer einzigen rtlichen Stelle zu Im einen Fall verbrauchen wir mehr an Ressource Raum im anderen Fall mehr an Ressource Zeit Im Modell sprechen wir auf h chster Abstraktionsstufe nur von einer wie auch immer gearteten Stelle der ein Ereignis zugeordnet wird Triggerstellen Werden an einer Stelle Ereignisse unmittelbar an andere Stellen weitergegeben was wir oben bereits mit dem Vorgang des synchronen oder passiven Lesens an dieser Stelle in Verbindung gebracht haben sprechen wir von einer Triggerstelle Speicherstellen Um ein asynchrones Lesen von Eingaben an einer Dialogschnittstelle m glich zu machen muss eine Stelle in der Lage sein die eingegebene Information ber einen ausreichend langen Zeitraum zu speichern Wir bezeichnen derartige Stellen als Speicherstellen 32 3 0 Zentrale Begriffe des Dialogmodells 3 0 2 Dialogwert Mit jedem Ereignis ist eine Informationseinheit verbunden die entweder an die Dialogstelle abge
66. sentiert die in unterschiedlichen Hierarchieebenen dargestellt sind und hierarchisch einander zugeordnet sind 55 4 Bottom up Modellierung und Abstraktion Wird die Hierarchie aufgel st und werden die Stellen durch untergeordnete Teilstellen ersetzt ben tigt man bekannterma en hnlich wie bei Zyklen ein Abbruchkriterium um irgendwann den Ersetzungsmechanismus die Produktion von Teilstellen der rekursiv auftretenden Stelle zu beenden Wir ben tigen in unserem Grafen also eine Bedingung die ausdr ckt dass die durch die Stel le repr sentierten Dialogereignisse in einer bestimmten Dialogsituation nicht mehr nachfolgen k nnen 4 1 3 Entscheidungsmechanismen f r Stellen berg nge und Wertebelegungen In den vorangehenden Abschnitten haben wir festgestellt dass durch die Reduktion der Stellen in der Modelldarstellung in manchen F llen Information ber die Fortf hrung des Dialogs verloren geht Wir ben tigen dann einen zus tzlichen Entscheidungsmechanismus der die Auswahl aus alternativen berg ngen zu anderen Dialogstellen vornimmt Dieser Entscheidungsmechanismus wird generell ben tigt wenn in unserem Modell alternative Fortf hrungen vorhanden sind die vom System also sowohl von der Dialogkomponente als auch von der Applikationslogik gesteuert werden sollen Dies gilt also insbesondere f r die Fortf hrung des Dialogs zu alternativen Stellen die eine Systemausgabe darstellen Bereits im ersten Beispiel des Instal
67. so sprechen wir dort von Folgen von Dialogereignis sen n mlich Eingaben und Ausgaben die sich aus nicht weiter beschriebenen Gr nden anein anderreihen In Anbetracht des Aspektes der Reihenfolge sprechen wir bei Dialogereignissen auch von Dialogschritten wohl im Sinne von einzelnen Gliedern die eine Dialogfolge ergeben Ein Dialogschritt kann somit verstanden werden als ein einzelnes in einer Folge befindlicher Dialogereignisse Dass wir den Ereignisbegriff verwenden ist nahe liegend nicht zuletzt weil er in g ngigen Modellen zur Beschreibung der Dialogdynamik verwendet wird So ist er ein zentraler Begriff bei den so genannten Ereignismodellen GREEN86 Aber auch beispielsweise bei Zustands bergangsdiagrammen sprechen wir von Ereignissen die einen bergang von einem Zustand in einen anderen bewirken Der Ansto f r das Ausf hren von Aktionen wird in her k mmlichen Modellsystemen an Ereignisse oder das Eintreten von Bedingungen gekn pft Ben tigen wir nun aber neben dem Ereignisbegriff einen weiteren Begriff der eben den Dialogschritt im Sinne einer Reaktion auf ein eingetretenes Ereignis oder eine eingetretene Bedingung beschreibt etwa den Begriff Aktion Oder kommen wir mit weniger Sprachmitteln genauso aus um den Ablauf des Dialogs die Steuerung die Reihenfolge zu 60 4 2 Logische Abstraktion beschreiben Reicht es nicht aus lediglich die Dialogschritte als Ereignisse darzustellen und sie selbst zu ordnen wo es appli
68. sung wird der Wert als Wertebereich mit einem Element interpretiert Intelligentere L sungen ziehen weitere Angaben im Modell zur Ableitung des Wertebereichs heran So kann z B die Wahl der Widgetklasse eine automatische Ableitung des Wertebereichs beeinflussen Ein PushButton z B legt einen einelementigen Wertebereich nahe w hrend ein Textwidget auf einen Wertebereich schlie en l sst der mehr Elemente besitzt etwa vom Typ Zahl bis hin zu beliebigem Text Im formalen Modell wird die Belegung der Stellen mit Startwerten durch die Funktion ostart bezeichnet Die Menge aller Werte ist dort mit W bezeichnet v lt SomeTex gt N MyName1 6 E aron arom 0 MyName2 My Text off Abbildung 5 3 Beispiel Annotationen an Stellen Die Stelle mit Stellenbezeichner MyNamel N MyNamel ist eine Ausgabestelle Typ O mit Wertebereich SomeText Dabei wird vorausgesetzt dass SomeText bekannt ist Als exemplarischer Wert und als Startwert der Stelle ist My Text eingetragen Die Stelle MyName 2 hat als Wertebereich die Werte On und Off ist vom Typ Eingabe I und hat als exemplarischen Wert der Eingabe Off F r die Implementierung kann dieser Wert als Startwert Defaultwert der Eingabe benutzt werden In einem Textwidget w rde dann z B Off bereits angeboten werden Bei Realisierung mit einem RadioButton w rde dann konsequenterweise der Button so initialisiert dass die erste Eingabe das Ausschalten erm glicht
69. und Jahr oder als eine is a Beziehung Beispiel Tag ist 1 ter oder 2 ter oder 31 ter betrachten k nnen Es werden h ufig alternative Stellen zusammengefasst wenn sie in ihren Eigenschaften in ihrer Bedeutung hnlichkeiten aufweisen die die Zusammenfassung als sinnvoll erscheinen lassen oder auch wenn der nachfolgende Dialogfluss durch die Zusammenfassung kaum ber hrt ist also nahezu oder vollst ndig unabh ngig ist Wir erreichen durch die Zusammenfassung nicht nur eine rein technische Verringerung der Stellen sondern auch h ufig eine semantische Strukturierung 4 1 1 0 Zusammenfassung von Dialogfolgen Eigentlich trivial eine Sequenz von Ein Ausgabedialogen wird zu einem Dialog zusammengefasst Wir stellen in unserem Grafen die Sequenz nur mehr als eine Stelle dar Wollen wir die Detailinformation ber die Einzelschritte nicht verlieren definieren wir diese Stelle als zusammengesetzte Stelle die einen Subdialog repr sentiert in dem die urspr ngliche Dialogsequenz dargestellt ist Zum Ged chtnisverlust bez glich Historie Solange wir nur eine bestimmte Teilsequenz zu einer Stelle mit Subdialog zusammenfassen und der entstandene Subdialog einzig dieser zusammengefassten Stelle zugedacht ist ben tigen wir noch kein zus tzliches Ged chtnis f r die richtige Fortsetzung nach Ablauf des Subdialogs Erst wenn der gleiche Subdialog und das ist ein weiterer Schritt der Zusammenfassung an mehreren Stellen Verwendung
70. verhaftet und dadurch z B f r eine WYSIWYG Darstellung wenig geeignet 1 1 1 1 Petrinetze Petrinetze PETRI62 HERRT89 OBERQ87 wurden urspr nglich f r die Darstellung von Produktionsprozessen eingef hrt Den Kern der verschiedenen Varianten von Petrinetz Modellen einfache Petrinetze Pl tze Transitions Netze Pr dikats Transitionsnetze RFA Netze bilden Stellen auch Pl tze genannt Transitionen und gerichtete Kanten Transitionen werden ber die Kanten mit Eingangs und Ausgangsstellen verbunden Um dynamische Prozesse zu modellieren werden den Stellen so genannte Marken zugeordnet Eine Transition feuert in einem einfachen Petrinetz wenn alle Eingangsstellen eine Marke aufweisen und reine Ausgangsstellen ohne Marke sind Die Marken der Eingangsstellen werden mit dem Feuern beseitigt Daf r wird jede Ausgangsstelle mit einer Marke versehen Petrinetze sind insbesondere f r die Darstellung nebenl ufiger Vorg nge geeignet Aufeine Variante die Dialognetze JANSS96 wird in Kapitel 9 noch gesondert eingegangen Ein Nachteil der Petrinetze liegt darin dass die Begriffe der Welt der Dialogmodellierung teilweise erst in die Begriffswelt der Petrinetze umgesetzt werden muss 21 1 G ngige Ans tze der Realisierung von Dialogsystemen und somit die intuitive Darstellung leidet Dieser Nachteil kann noch ausgemerzt werden wenn eine Transformation in dialogspezifische Sprachelemente durchgef hrt wird wie dies z B bei
71. von Netzanwendungen ohne hier den Anspruch auf Vollst ndigkeit zu erheben Es sind dies generell die Ans tze die unmittelbar das zur Verf gung stehende Basissystem zur Realisierung nutzen das Sprachelemente auf einer eher technischen Ebene und weniger logischen Ebene zur Realisierung der Anwendung bietet Eine exakte und vor allem umfassende Abgrenzung soll und kann im Rahmen dieser Arbeit nicht erfolgen Etwas pragmatisch k nnen wir diese Ans tze auch als solche umschreiben die weder auf Basis einer Sprache zur Beschreibung eines logischen Dialogmodells noch mit Hilfe eines Werkzeuges zur grafischen WYSIWYG Darstellung arbeiten H ufig ist in derartigen Ans tzen der direkten Programmierung ein Ereignismodell in Form bestimmter Sprachelemente bzw durch bestimmte Klassen Bibliotheken X Windows Eventhandler Java Listener Konzept unterst tzt 1 2 0 Vorteile Die Vorteile der direkten Programmierung werden vor allem von versierten Entwicklern gesch tzt Flexibilit t wegen vollst ndigem Repertoire an Sprachmitteln des Basissystems Der Entwickler ist in der Lage alle M glichkeiten des Basissystems auszusch pfen da er direkt in der Sprache des Basissystems arbeitet Die Flexibilit t des Systems erlaubt in der Regel exakt die geforderte Funktionalit t der Anwendung umzusetzen Hoch dynamisch und potentiell generisch Die M chtigkeit der verf gbaren Sprache des Basissystems erlaubt im Allgemeinen das Programm
72. wegen einer eingeschr nkten und manchmal auch nicht problemnahen Sprache in eine konkrete Oberfl che schwierig und umst ndlich Der gro e Vorteil der direkten Verwendung einer Programmiersprache ist hingegen dass alle M glichkeiten insbesondere zur Implementierung dynamischer Dialogteile unmittelbar zur Verf gung stehen Wie bei Rapid Development Systemen ist allerdings eine bersichtliche logische und leicht zug ngliche Darstellung der Dynamik und in diesem Fall auch der statischen Teile nicht vorhanden Ein Einsatz aller drei geschilderten Ans tze f hrt zu Inkonsistenz und Doppelarbeit Auch neuere Versuche zur Integration in sogenannten Round Trip Systemen die einen nahtlosen bergang vom Modell zum generierten Code und umgekehrt vom teilweise manuell erstellten oder ge nderten Code zur ck zur Modelldarstellung erlauben haben sich bisher nicht durchgesetzt Nach Meinung des Autors liegt dies zum Teil an den mangelnden und wenig intuitiven Darstellungsm glichkeiten insbesondere der Dialogdynamik auf der logischen Modellebene 25 2 Neuer integrierter Modellierungsansatz 2 Neuer integrierter Modellierungsansatz 2 0 Kernziele Aus der oben gef hrten Diskussion ber Vor und Nachteile des Rapid Development Ansatzes modellbasierter Ans tze und der Ans tze mit direkter Programmierung resultiert ein integrativer Ansatz der die wesentlichen Vorteile der diskutierten Ans tze vereint Aus ihm lassen sich zwei Kernziele f
73. wir nach M glichkeit alle Ereignisse des Dialogs in allen m glichen Ablauffolgen explizit aufzeigen In einer extrem extensiven Darstellung bedeutet dies dass wir alle Ablauffolgen voneinander getrennt an getrennten Modellstellen nachweisen In der statischen Darstellung in einem Grafen kann das so erfolgen dass jede Dialogfolge in einem eigenen unabh ngigen Teilgrafen dargestellt 1st Wir verlieren allerdings keine nennenswerte Information wenn die alternativen Folgen im Grafen in Baumform dargestellt werden Erst wenn die Folgenglieder der alternativen Folgen unterschiedliche Ereignisse aufweisen wird im Grafen ber unterschiedliche Kanten verzweigt und die Ereignisse werden in unterschiedlichen Knoten des Grafen dargestellt Abbildung 4 3 Die bisher im Dialog erfolgte Ereignisfolge wird eindeutig durch den erreichten Knoten im Baumgrafen festgehalten Betrachten wir den Dialog als ein in sich geschlossenes deterministisches System wissen wir die eindeutige Fortsetzung des Dialogs also das n chste Dialogereignis wenn wir wissen in welchem Knoten wir uns aktuell befinden Wir ben tigen kein zus tzliches Ged chtnis bez glich des bisher durchgef hrten Dialogs um die Fortsetzung zu steuern bzw das n chste Dialogereignis zu bestimmen Erst die Beeinflussung des Systems durch unbestimmbare Ereignisse von au en f hrt zu m glichen alternativen Verzweigungen etwa alternative Ein gaben des Benutzers oder alternative Ausgaben der
74. zugeordnet werden In einem weiteren Dialog k nnen die einzelnen Bedingungen im Stack aktiviert werden W hrend eine Bedingung aktiv ist k nnen dann Aktionen festgelegt werden die bei G ltigkeit der Bedingung ablaufen sollen So kann z B durch Malen eines Pfeiles von einem Button zu einer Seite das ffnen der Seite f r den Fall definiert werden dass der Benutzer auf den Button klickt w hrend die Bedingung erf llt ist Sukzessive kann so der Bedingungsstack abgearbeitet werden Enhanced Arrows Den Pfeilen Arrows die normalerweise berg nge von einer Seite zu einer anderen definieren die per Mausklick ausgel st werden k nnen bei Enhanced Arrows andere Ereignisse wie z B das Ablaufen eines Timers zugeordnet werden 146 9 6 Sketchingsysteme Vergleich mit ESD s Der in der vorliegenden Arbeit ausgef hrte Bottom up Ansatz bietet hnlich wie bei Sketchingsystemen die M glichkeit Dialogabl ufe auf einer konkreten naiven Ebene darzustellen In einem Ereignisstellen Diagramm kann schrittweise Ereignis f r Ereignis an jeweils eigenen Ereignisstellen hintereinander festgehalten werden Danach erfolgt eine Zuordnung zu konkreten Widgets und damit eine Zusammenf hrung der Ereignisstellen auf ein einziges Dialogelement und die damit verbundene Programmlogik Insofern bieten Ereigisstellen die Voraussetzung f r die Anwendung der Storyboarding Technik Dies wird durch die Darstellung in Modellsichten weiter unterst tzt Da
75. zun chst dadurch ausdr cken dass wir die beiden Teildialoge Erfassen Kundendaten und Erfassen Auftragspositionen als nebenl ufige Dialoge darstellen und in einem bergeordneten Dialog Erfassen Kundendaten und Leistungen zusammenfassen dem der Preisdialog folgt Der Pfeil in Abbildung 4 12 dr ckt also die einzige definierte Abh ngigkeit zwischen den Dialogen aus 70 4 2 Logische Abstraktion Abbildung 4 13 Auftragserfassung mit primitiven Teildialogen und bergang zur Preisberechnung gesteuert durch Benutzereingabe F r eine vollst ndige detaillierte Definition bis zur Ebene der primitiven Teildialoge Abbildung 4 13 ist es noch not wendig gem der im Zusammenhang mit der Einf hrung hierarchischer Dialoge gew hlten Dar stellung Abschnitt 3 0 3 0 die Anschluss ereignisse zu definieren die den bergang zum Preisdialog erm glichen D h wir m ssen im Ein zelnen definieren welche Ereignisse in den jeweili gen Teildialogen einen bergang zum Preisdialog erlauben welche Ereignis se bzw Stellen also innere Anschlussstellen zum Pfeil auf der obersten Hierarchieebene darstellen Gem Modell in Abbildung 4 12 erfolgt der bergang zum Preisdialog dann wenn der Benutzer den bergang w nscht was er durch Eingabe von Berechnen ausdr ckt Im konkret realisierten Dialog kann dies z B das Dr cken eines PushButtons sein oder aber auch quivalent dazu etwa in einem Kommandodialog die Einga
76. 2 werden als Teilstellen von s bernommen Bei Namensgleichheit gelten wiederum die gerade beschriebenen Regeln der Zusammenf hrung 156 10 2 Schritte zur Codegenerierung 10 2 1 1 Stellen als Zust nde einer Instanz Um die Interpretation der Stellen als Zust nde Zustandsstellen einer Widgetinstanz zu interpretieren ist im Prototyp eine weitere Annotation eingef hrt Wir kennzeichnen eine Zustandsstelle mit der Annotation S n wobei n einen Index f r den entsprechenden Zustand darstellt Alternativ dazu kann der Index in Klammern hinter dem Stellenbezeichner stehen F r die Interpretation der Zustandsstellen einer Widgetinstanz gelten im Sinne der Stellen unseres Ereignisstellenmodells in Kap 5 folgende Besonderheiten 1 Wird eine Zustandsstelle ge ffnet werden alle brigen Zustandsstellen derselben Instanz geschlossen 2 Es muss sichergestellt sein dass nicht zwei verschiedene Zustandsstellen derselben Instanz gleichzeitig ge ffnet werden da dies zu einem nicht definierten Verhalten f hrt Die Interpretation der Zustandsstellen entspricht sonst der Interpretation der Stellen des Ereignisstellenmodells in Kap 5 mit eben der Ausnahme dass die Notwendigkeit entf llt explizit die anderen Zustandsstellen derselben Instanz mittels Schlie epfeil zu schlie en wenn eine Zustandsstelle ge ffnet wird Im Gegensatz zum oben beschriebenen Merge ist nun die Strategie bei der Codegene rierung bei einem ffnenden Stellen ber
77. Applikationslogik Abbildung 4 3 Beispieldialogfolgen als Pfade eines Baums in einem Grafen Jeder Knoten im Baum repr sentiert einen eindeutigen Pfad und damit eine eindeutige Ereignisfolge und Dialogsituation im Sinne der Historie des bisher durchgef hrten Dialogs 44 4 0 WYSIWYG Ansatz 4 0 2 Grenzen der WYSIWYG Modellierung Der obige Beispieldialog ist derart einfach dass er in all seinen alternativen Abl ufen in einem Grafen relativ bersichtlich vollst ndig zu sehen ist Insbesondere ist die Anzahl seiner alternativen Folgen endlich ebenso die Anzahl Dialogschritte innerhalb einer Alternative Der Graf stellt ein vollst ndiges Modell des Dialogs aus Sicht des Benutzers dar Wie nun bereits aus der Literatur bekannt z B JACOBS6 JANSS96 ist die Darstellung eines Dialogsystems in Form von Zust nden und Zustands berg ngen im Allgemeinen nur schwer handhabbar Dies gilt insbesondere dann wenn im System sehr viele Zust nde und oder m gliche Zustands berg nge vorkommen Die oben beschriebene Form der extensiven Darstellung stellt eine derartig potentiell pathologische Beschreibungsform dar Jede Stelle der extensiven Darstellung kann als Zustand jeder bergang von einer Stelle zur anderen als Transition interpretiert werden Da wir die Darstellung jeder m glichen Ereignisfolge und damit aller m glichen Zust nde und Zustands berg nge vorsehen kommen wir in bereits relativ einfachen F llen zu einer sehr gro e
78. Condition und automatischem bergang zu Preisberechnung In einer anderen Variante des Modells siehe Abbildung 4 14 soll die Berechnung der Preise automatisch erfolgen ohne dass der Benutzer dazu ein Kommando er teilt Nun kann der ber gang zur Ausgabe der Preise nach Eingabeereig nissen in fast allen Teil dialogen des Kundendia logs und des Dialogs zur Erfassung der Auftragspo sitionen erfolgen Ledig lich die Erfassung von Telefon Fax und Email sind nicht obligatorisch In dieser Modellvariante muss nun nach jedem Ereignis mittels Condition die Vollst ndigkeit der Daten berpr ft werden um dann ggf die Preisberechnung zu triggern Vorschlag Um auch die hier etwas aufw ndige Definitionsarbeit aller Anschlussereignisse zu sparen k nnen wir vereinbaren dass ein bergang aus jedem der Ereignisse in den Teildialogen erfolgen kann dass also defaultm ig alle Ereignisse des Dialogs den bergang triggern es sei denn es werden explizit Anschlussereig nisse im jeweiligen Teildialog angegeben Abbildung 4 15 n chste Seite zeigt ein erweitertes Beispiel des Auftragsdialoges im Modell unter Verwendung einer Condition und zweier bertragungsfunktionen Dabei ist die Variante mit expliziter Ansteuerung der Preisberechnung durch den Benutzer gew hlt Je nach Ergebnis der Auswertung der Condition erfolgt entweder die Preisberechnung oder ein einfacher Dialog mit Ausgabe einer Fehlermeldung In einer komfortab
79. D Typ Typ Name Wert ffnen Schlie en So I An So I An S O Aus S O Aus S2 O An S2 O An 175 Anhang D Stelle Er Widget Ereignis Attribut Operationen ab eig konkret strakt nis Typ Wert Klasse Instanz ID 176 Typ Typ Name Wert ffnen Schlie en Anhang E Formale Darstellung der Exemplarvariation Anhang E Formale Darstellung der Exemplarvariation Es folgt eine Einf hrung der Exemplarvariation in das Ereignisstellenmodell in formaler Darstellung am Beispiel der inkrementellen Variation einer Exemplarstelle und Variation des Aspekts Kardinalit t Dazu wird das in Kap 5 vorgestellte Ereignisstellen Modell erweitert Den Kern der Erweiterung stellt die Einf hrung einer Funktion variation dar die dynamisch das Modell in verschiedene so genannte Modellkonfigurationen ab ndert Wir erweitern die bergangsfunktion 8 die wir zum Unterschied von aus dem Ereignisstellen Modell ESM in Kap 5 nun dyn nennen wollen und die nun zus tzlich die dynamische nderung unseres Modells hinsichtlich folgender Modellelemente aus ESM Kap 5 ausdr ckt S E RO RC HS ERO ERC KRO KRC TRO Wir f hren bei einer Variation h ufig neue Stellen Stellenmenge S in unser System ein die wir aus einem ideal gesehen unendlichen Stellenreservoir SUniv sch pfen Dass sich die Menge der Ereignisse E ndern kann li
80. D h wir m ssen in diesen F llen daf r sorgen dass die Darstellung an der Dialogschnittstelle m glichst unmittelbar mit dem Eintreten des Ereignisses bereinstimmt Besonders ist es bei Echtzeitdarstellung wenig sinnvoll die Reihenfolge der Darstellung der Zeitereignisse zu vertauschen Auch im Dialogsystem synchron dargestellte Echtzeitereignisse im Dialogsystem Echtzeitverhalten simulierende bzw im Dialogsystem erzeugte und Echtzeit darstellende Ereignisse k nnen als Ereignisse betrachtet werden deren Reihenfolge vorbestimmt ist Mit anderen Worten Echtzeitereignisse sind per se zeitkritisch und liegen in Zeitpunkt und Reihenfolge der Darstellung fest Reale nicht simulierte Echtzeitereignisse sind aber weitgehend entkoppelt von anderen Ereignissen im Dialogsystem zu sehen und k nnen deshalb als asynchrone extern gesteuerte Ereignisse so paradox das auch klingt betrachtet werden Dies muss im Modell entsprechend ausgedr ckt werden k nnen 63 4 Bottom up Modellierung und Abstraktion Logische nicht zeitlich gegebene Ordnungen Neben den echt durch die Zeit gegebenen Reihenfolgen der Dialogschritte gibt es Reihen folgen die aufgrund irgendwelcher anderen vorgegebenen Ordnungskriterien definiert sind die nicht durch die Zeit bestimmt sind Im Dialog darzustellende Elemente oder Objekte k nnen beispielsweise nach Ma zahlen wie Gr e Gewicht Volumen etc nat rlich geordnet sein Es kann nun eine Anforderung resultieren
81. Design Environment in Vanderdonckt Hrsg Computer Aided Design of User Interfaces Proceedings ofthe 2nd International Workshop on Computer Aided Design of User Interfaces CADUI 96 Namur 5 7 June 1996 p 37 56 Presses Universitaires Namur ISBN 2 87037 232 9 1996 Reinke Solutions Team Microsoft Excel 2002 Das Handbuch Microsoft Press ISBN 3860631608 2001 MILNER80 Milner R A Calculus of Communicating Systems Lecture Notes in Computer Science Vol 92 Springer Verlag 1980 MILNER99 Milner R Communicating and Mobile Systems the n Calculus Cambridge MODUG93 MYERSSS8 OBERQ87 OESTER97 PARRO95 PETRI62 PRJD96 University Press 1999 Modugno F Myers B A Graphical Representation and Feedback in a PBD System in Watch What I Do Programming by Demonstration A Cypher Editor MIT Press Cambridge MA pp 415 422 1993 Myers B A Creating User Interfaces by Demonstration Academic Press 1988 Oberquelle H Benutzerorientierte Beschreibung von interaktiven Systemen mit RFA Netzen Software Ergonomie 87 Tagung IV 1987 des German Chapter ofthe ACM p 271 284 Oestereich B Objektorientierte Softwareentwicklung mit der Unified Modeling Language R Oldenbourg 1997 Parrow J Interaction Diagrams Nordic Journal of Computing p 407 443 1995 Petri C A Kommunikation mit Automaten Schriften des Rhein Westfael Institutes
82. Dialogs durchzuf hren Es entf llt damit der Druck in der Designphase bereits m hevoll konkrete Elemente auszuar beiten bei gleichzeitiger M glichkeit wo gew nscht konkrete Elemente des Dialogs z B Widgets einzuf hren In der Modellsprache sind Sprachelemente enthalten die insbesondere auch die Dynamik des Dialogs modellierbar macht und einen berblick ber den m glichen Ablauf des Dialogs bietet Die gew hlte Form der grafischen Darstellung dieser Sprachelemente gibt einen intui tiven Eindruck der sp teren zur Laufzeit vorliegenden grafischen Dialogoberfl che Dennoch kann die Sprache so abstrakt gew hlt werden dass eine Umsetzung in andere Dialogarten z B Kommandodialog ebenso m glich ist Die entwickelte Modellsprache r ckt die Objekte des Dialogs und die Ereignisse darauf in den Vordergrund und zeigt die Wirkung dieser Er eignisse auf die Objekte bzw Stellen auf Im Gegensatz zu anderen abstrakten Modell ans tzen Zustands bergangsdiagramme Petrinetze wird eine intuitive dialogobjekt orienterte Darstellung m glich die zudem auch komplexen dynamischen Anforderungen gen gt Die Entwicklung dieser Art von Darstellung geschieht in einem Bottom Up Ansatz Ein wesentliches Ergebnis der Entwicklung sind die Sprachelemente des sogenannten Ereignis stellendiagramms und die Einbettung in eine praxisorientierte Modellierungsumgebung mit der Integration abstrakter Diagrammkomponenten und konkreter Darste
83. Form der Darstellung intuitiv klar Dabei setzen wir nat rlich dennoch immer einen gewissen Grad an Vorkenntnis und Abstraktionsf higkeit voraus Um den Dialog letztlich als Benutzer durchf hren zu k nnen muss dieser etwa bei unserem Beispiel wissen was unter Mausklick zu verstehen ist Wir h tten in unsere Darstellung allerdings auch die Eingabe Mausklick bildlich mit aufnehmen und noch n her spezifizieren k nnen dass standardm ig die linke Maustaste gemeint ist Wir machen in unserem Modell also implizite Annahmen ber einen bereits bekannten Kontext oder aber wir lassen bestimmte Beschreibungsmerkmale im Sinne einer sp teren Konkretisierung offen F r die Zielsetzung der benutzerzentrierten Modellierung des Dialogs erscheint die gew hlte Art der Darstellung des Dialogs wegen seiner intuitiven und klaren Form zumindest was dieses einfache Beispiel betrifft sehr gut geeignet Die Umsetzung einer derartigen Modelldarstellung in ein ablauff higes Programm ben tigt eine Formalisierung der oben gezeigten Darstellung die von einer Maschine entsprechend interpretiert werden kann Als Ansatz dient das oben bereits vorgestellte Grundmodell Nach Grundmodell entspricht jedem Ereignis eine Stelle hier ein Bild Umgekehrt ist wie oben erw hnt in jedem Bild ein 40 4 0 WYSIWYG Ansatz Ereignis enthalten Ausgehend vom ersten Bild erhalten wir ber die Folgebilder unter Ber cksichtigung der alternativen Verzweigungen eine Menge von
84. Handler die darauf folgende prozedural verstandene Abarbeitung beschreibt Im Ereignisstellenmodell steckt die prozedurale Sicht der Abarbeitung in den Propagationsfunktionen Der Grundansatz im ESM der zum Stellenbegriff f hrt liegt darin dass logischer Dialog aus einer Struktur voneinander abh ngiger oder unabh ngiger Ereignisse besteht Ein wesentlicher Unterschied zwischen Ereignismodell und ESM ist dass in Form der ffne und Schlie e Relationen unmittelbar Abh ngigkeiten zwischen Ereignissen ausgedr ckt werden Die Struktur des Dialogs wird damit explizit sichtbar Ein Ereignis an einer Stelle hat Ereignisse an anderen Stellen zur Folge oder erm glicht zumindest diese Ereignisse Dabei handelt es sich sowohl um Ausgabe wie um Eingabeereignisse Es ist eine konsequent symmetrische Sicht des Dialogs zwischen Ausgabe und Eingabe im Wechsel ausgedr ckt Ebenso k nnen Ereignisse unmittelbar Ereignisse an anderen Stellen oder an derselben Stelle unm glich machen Das Ereignismodell ist zun chst f r eine grafische Darstellung wie Green selbst betont GREEN86 nicht geeignet Dies liegt wohl in erster Linie an der stark prozeduralen Sicht des Event Handlers mit Event Handler Prozeduren Im Gegensatz dazu ist der Ansatz im ESM gerade der mit Ereigisstellen Diagrammen eine grafische Darstellung zu erm glichen und au erdem WYSIWYG Komponenten als konkrete Ergebnisse bzw Darstellungsmittel von Ausgabe und Eingabe in die Darstellung mit
85. Im Folgenden Kapitel wird eine Sicht des Dialogs entwickelt die im weiteren Verlauf als Grundlage f r die Diskussion der Modellierung dienen soll Wir wollen diese Sicht als Grundmodell bezeichnen Es werden darin zentrale Elemente des Dialogs und wichtige Relationen dieser Elemente zueinander festgelegt die als Ausgangspunkt f r die Entwicklung einer Modellsprache zur Beschreibung von statischer und dynamischer Dialogstruktur dienen soll Das Grundmodell beschreibt den Dialog auf einer abstrakten allgemeing ltigen Ebene D h die durch das Grundmodell vermittelte Sicht auf den Dialog kann auf unterschiedlichste Konkretisierungen abgebildet werden 3 0 Zentrale Begriffe des Dialogmodells 3 0 0 Dialogereignis Der Begriff des Ereignisses ist bekannt aus anderen formalen Modellans tzen wie z B Zustands bergangsdiagrammen Zustandsautomaten oder Ereignismodellen Ein Ereignis dr ckt im Allgemeinen einen dynamischen Vorgang aus D h mit einem Ereignis ist auf konkreter physikalischer Ebene Zeit und Ort verbunden an dem das Ereignis festgestellt werden kann Wenn wir von der konkreten physikalischen Ebene abstrahieren wollen wir das Ereignis einer Stelle in einem virtuellen Stellenraum siehe unten zuordnen Dialogereignisse tragen dem dynamischen Vorgang des Austausches von Information Rechnung Der Austausch der Information kann in Form von vier Ereignistypen beschrieben werden Eingabe Ein Eingabeereignis ist dann zu verzeichnen wenn
86. Institut f r Informatik der Technischen Universit t M nchen Modellierung grafischer Dialogsysteme mit Ereignisstellen Diagrammen in WYSIWYG orientierter Darstellung Alfred Zeidler Vollst ndiger Abdruck der von der Fakult t f r Informatik der Technischen Universit t M nchen zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften Dr rer nat genehmigten Dissertation Vorsitzender Univ Prof Dr Peter Paul Spies Pr fer der Dissertation 1 Univ Prof Dr Dr h c J rgen Eickel 2 Univ Prof Dr Helmut Seidl Die Dissertation wurde am 15 Januar 2004 bei der Technischen Universit t M nchen eingereicht und durch die Fakult t f r Informatik am 22 Juli 2004 angenommen Danksagung Herrn Professor Eickel gilt herzlicher Dank zun chst daf r dass er mir spontan die Gelegenheit zur Durchf hrung dieser Arbeit an seinem Lehrstuhl er ffnete dann f r die Geduld die er ber die langen Jahre bis zum Durchbruch und Abschluss aufbrachte und selbstverst ndlich nicht zuletzt f r die kritische Betrachtung und die zahlreichen fruchtbaren Hinweise Herzlichen Dank an Herrn Professor Seidl als zweitem Gutachter auch f r die Anregungen in der Schlussphase die die Aufnahme weiterer interessanter Aspekte in die Arbeit zur Folge hatten Frau Remmes gilt ganz besonderer Dank f r ihr so freundliches Engagement mit dem sie die durch meine externe berufliche T tigkeit bedingte r umliche Entfernung zum L
87. Komponenten Modelleditor und Codegenerator in Java Der vom Codegenerator erzeugte Code ist ebenfalls Java Code 150 10 0 Zielsetzung und Rahmenbedingungen Unterst tzt werden in einer exemplarischen Auswahl die wichtigsten Klassen zur Gestaltung von Dialogoberfl chen aus Java Swing Diese werden im Modelleditor neben den abstrakten Ereignisstellen als konkrete Widgets zur Modellierung angeboten und dargestellt Der durch den Codegenerator erzeugte Code verwendet die im Modell gew hlten Swingklassen zur Realisierung der modellierten Anwendung 10 0 2 Zus tzliche Adapter und Komfortklassen Alternativ und in Erg nzung zur direkten Umsetzung von Ereignisstellen in Instanzen von Java Swingklassen wird im Modelleditor eine Reihe von Klassen angeboten die zum einen als Zwischenschicht im Sinne eines virtuellen Baukastensystems f r die leichtere Abbildung auf auch andere konkrete Toolkits dienen k nnen und zum anderen Komfortklassen darstellen die in Java Swing nicht enthaltene Funktionalit t bieten z B mit Labeln versehene Textfelder Widgets mit automatischer Plausibilisierung von Eingabewerten etc Au erdem werden diese Adapterklassen f r den Anschlu der Applikationslogik z B bei der Realisierung der Variation verwendet siehe unten Die zus tzlichen Klassen stehen dem Anwender mit Sourcecode zur Verf gung 10 1 Editor zur Modellierung von Ereignisstellendiagrammen Die in der Arbeit in den Abbildungen dargestellten Beispiele
88. Name DefaultWert DefaultWert DefaultWert DefaultWert gesetzt gesetzt gesetzt gesetzt Wertebereich LabeledTextfield LabeledTextfield LabeledTextfield LabeledTextfield JPane FramedJPanel LabelText Name LabelText Name LabelText Name LabelText Name Title Name Text Text Text Text Abbildung 10 2 Defaultabbildung abstrakter Ereignisstellen ohne Triggerfunktion auf Java Swing Klassen oder abgeleitete Komfortklassen 10 2 0 1 Individuelle Abbildung auf Widgetklassen und Attribute Alternativ zur automatischen Abbildung besteht die M glicheit den abstrakten Ereignisstellen explizit konkrete Widgetklassen Widgetattribute und Attributwerte zuzuordnen oder von vorneherein anstelle einer abstrakten Dialogstelle ein konkretes Widget zu verwenden Im derzeitigen Prototyp sind dabei die vom System in einem Auswahldialog angebotenen Klassen und Attribute wie oben bereits erw hnt auf die wichtigsten Java Swing Klassen und einige Adapter und Komfortklassen beschr nkt Allerdings kann der Benutzer selbst durch Annotation des Klassenbezeichners prinzipiell eine beliebige Klasse zur Realisierung einer Ereignisstelle zuordnen Voraussetzung ist allerdings dass die Klasse eine vom Codegenerator geforderte Schnittstelle besitzt die das Erzeugen einer Instanz die 154 10 2 Schritte zur Codegenerierung Einordnung in die Widgethierarchie das ffnen und Schlie en sowie das Setzen und Ab
89. Passwortdialog Teil 2 nach Jacob ee 130 Abbildung 9 4 Ereignisstellendiagramm ESD eines Dialogs zur Passwort nderung 131 8 Abbildungsverzeichnis Abbildung 9 5 State Chart f r Set Clock Dialog nach Rumbaugh RUMBAJI1 137 Abbildung 9 6 Set Clock Dialog in ESD Darstellung uesennnenenneennnnn 138 Abbildung 9 7 Grafische Darstellung des Pi Kalk ls mit Interaction Diagrams 141 Abbildung 9 8 Storyboarding Beispiel Entwurf eines Shoppingsystems een 147 Abbildung 9 9 Ereignisstellendiagramm f r Zust nde der Checkout Seite im Shoppingsystem a a ae E R 148 Abbildung 9 10 Ereignisstellendiagramm mit intensivierter Darstellung der Checkout Seite IK SHOPPITIOS VOTE DI nein suite 149 Abbildung 10 1 Defaultabbildung abstrakter Ereignisstellen mit Triggerfunktion auf Java Swing Klassen oder abgeleitete Komfortklassen 2220400ssssnnnnesennneeeeennnnn 153 Abbildung 10 2 Defaultabbildung abstrakter Ereignisstellen ohne Triggerfunktion auf Java Swing Klassen oder abgeleitete Komfortklassen 22244000ssssnnneeeneneeneennenn 154 0 Einf hrung 0 0 Allgemeine Problemstellung Mit der Einf hrung von Dialogsystemen und insbesondere mit der Entwicklung grafischer Bedienoberfl chen seit nunmehr gut zwei Jahrzehnten einer der Meilensteine war wohl nach Arbeiten bei Rank Xerox die Einf hrung des Apple Macintos
90. Prototyp 10 0 Zielsetzung und Rahmenbedingungen 10 0 0 Kernfunktionalit t f r Integration in eine Entwicklungsumgebung 10 0 1 Realisierung in Java f r Swing Klassen 10 0 2 Zus tzliche Adapter und Komfortklassen 10 1 Editor zur Modellierung von Ereignisstellendiagrammen 10 2 Schritte zur Codegenerierung 10 2 0 Abbildung abstrakter Ereignisse auf Widgets Widgetattribute und Attributwerte 10 2 0 0 Defaultmechanismus zur Abbildung auf Widgetressourcen 10 2 0 1 Individuelle Abbildung auf Widgetklassen und Attribute 10 2 1 Zuordnung von Widgetinstanzen 10 2 1 0 Merge von Szenarienstellen 10 2 1 1 Stellen als Zust nde einer Instanz 10 2 2 Interpretation des formalen ffnens und Schlie ens 10 2 3 Codegenerierung f r stellenspezifische Klassen 10 2 4 Realisierung von Conditions und Propagationsfunktionen 10 2 5 Prototypische Realisierung der Exemplarvariation 10 2 5 0 Aspekte der Variation im Prototyp 10 2 5 1 Variationsereignisse 10 2 5 2 Realisierung der Variationsfunktion Zusammenfassung und Ausblick Glossar Literaturverzeichnis 118 119 120 120 121 121 122 123 123 125 125 126 127 127 132 134 136 139 143 146 150 150 Inhaltsverzeichnis Anhang A Rekursive Modellierung der Fakult tsfunktion Anhang B bergangsfunktion f r das hierarchische Ereignisstellenmodell Anhang C Induktion von Ereignishierarch
91. Relation sind dabei als Exemplare zu betrachten Der nach dem ffnen tats chlich zur Laufzeit im JobStepGraph dargestellte Inhalt wird zum Teil explizit durch die Exemplare selbst und zum Teil durch die den Exemplaren zugeordnete Variationsinformation bestimmt siehe unten Ein Triggerpfeil ausgehend von der Ereignisstelle Ready triggert die Wert bertragung von LoadingJob JobName zu CurrentJobName Das Eintreffen eines Ereignisses an der Stelle Details in der zusammengesetzten Stelle JobStep2 er ffnet den JobStepDetails Dialog der wiederum ein zusammengesetztes Ereignis repr sentiert Ein Eintreffen eines Ereignisses an der Teilstelle OK triggert die Ereignisse an der Ereignisstelle SaveToModel und ein Triggerpfeil ebenfalls ausgehend von OK triggert die Wert bertragung zwischen den beiden Stellen JobStepName in JobStepDetails und SaveToModel Die Pfeile in Rot definieren ein Schlie en der Ereignisstelle Der Pfeil aus der Ereignisstelle Quit schlie t somit den gesamten Dialog und damit alle Teilstellen Der Schlie epfeil von Ready den Teildialog LoadingJob entsprechend bedeuten die Pfeile von OK und Cancel das Schlie en der Teilstelle JobStepDetails Schlie en bedeutet dass kein Ereignis an der Stelle mehr m glich ist bis nicht explizit per ffnepfeil wieder er ffnet wird 8 2 1 Ereignistypen Von wem ob von Benutzer oder System die Dialoge nun wirklich durchgef hrt werden d h durch wen an den Stellen entsprechende Ereign
92. S Zuordnung von Ereignissen die ffnen ausl sen ero S S Potenzmenge E mit ero s s c 6 Hs U V ss Ee S amp S ERO s s falls s s e RO ero s s sonst Zuordnung von Ereignissen die Schlie en ausl sen ERC S S Potenzmenge E mit erc s s c o s U Y s s e S 9 ERC s s falls s s RC erc s s sonst Menge der Pr dikate Conditions c als Funktionen der Form c WS TRUE FALSE wobei WS Menge aller Wertezuordnungen auf einer definierten Stellenmenge Se c S also WS sc sc ist Funktion sc Se gt W Zuordnung von Condition zu ffne Relation KrO RO gt C L die f r die Entscheidung des ffnens von Stelle s bei Ereignis an Stelle s mit s s e RO herangezogen wird Zuordnung von Condition zu Schlie e Relation Krc RC gt C u die f r die Entscheidung des Schlie ens von Stelle s bei Ereignis an Stelle s mit s s e RC herangezogen wird 77 5 Ereignisstellenmodell P Menge von bertragungsfunktionen Propagationsfunktionen p der Form p WSp gt W WSp ist hnlich zur Definitionsmenge von Conditions siehe oben eine Menge von Wertezuordnungen auf einer f r die bertragungsfunktion p definierten Stellenmenge Sp TRO Zuordnung von bertragungsfunktion zu ffne Relation nro RO gt P L Durch obiges Modell wird eine bergangsfunktion amp wie folgt definiert bergangsf
93. S oO Aus JLabel OutLabel Ausf hren Labellcon LampeAn Widget LampeAus Operation kreieren Icon setzen zum sichtbar oder Widget Setzen setzen unsichtbar Attribut LampeAn setzen wert Icon setzen oder l schen S2 0 An JLabel OnLabel Ausf hren Labellcon LampeAn Widget LampeAus Operation kreieren Icon setzen zum sichtbar oder Widget Setzen setzen unsichtbar Attribut LampeAn setzen wert Icon setzen oder l schen S I Aus JButton OutButton Mausklick Widget Widget kreieren insensitiv sichtbar setzen oder setzen unsichtbar sensitiv setzen oder setzen l schen Abbildung 6 4 Tabelle zur Implementierung des RadioButton Modells mit vier Widgets Die Tabelle zeigt schematisch die Umsetzung der vier abstrakten Ereignisstellen des RadioButton Modells auf vier Java Widgets mit konkret verwendeten Ereignissen Attributen Ressourcen und Operationen Da die zum Triggern der Eingabeereignisse benutzte Buttonklasse JButton kein Attribut zum Speichern des Eingabewertes besitzt entfallen hier die Angaben zu Attributtyp und Wert Die Operationen zum Erm glichen ffnen des Ereignisses sind alle erforderlich und werden soweit sie nicht von vorher wirksam sind beim bergang zur Stelle ausgef hrt Die Operationen zum Schlie en k nnen alternativ f r die Implementierung gew hlt werden 106 6 1 Abbildung der Ereignisstellen auf ko
94. Toolbar F llung nach sich ziehen k nnte H tten wir als Variationstyp inkrementell angegeben erwarten wir von der Variationsfunktion siehe nachfolgend dass sie bei wiederholtem Aufruf nur neu hinzuzuf gende Icons liefert und die bereits in der Toolbar befindlichen Icons erhalten bleiben Variationsfunktion zur Berechnung der Varianten Es fehlt nun noch festzulegen wie die zu variierenden Attribute bzw Attributwerte bestimmt werden 115 7 Exemplarische Darstellung und Variation Eine nahe liegende einfache Art ist dass wir eine Funktion angeben die uns die Varianten ermittelt Dazu legen wir die Parameter fest deren Werte zum definierten Zeitpunkt der Berechnung in die Funktion eingehen Die Funktion kann in einer im Entwicklungssystem verf gbaren Programmiersprache realisiert werden In unserem Beispiel wird die Funktion beim ffnen der Toolbar mit den entsprechenden Parameterwerten versorgt und aufgerufen Als Parameter k nnte in unserem Beispiel etwa die Identifikation des aktuellen Benutzers der Anwendung eingehen Wir nehmen an dass die Id des Benutzers im Modell als Wert einer Dialogstelle vorliegt Mit der Benutzeridentifikation sind in der Praxis etwa entsprechende Datenbankeintr ge als weitere Parameter verbunden auf die die Implementierung der Funktion dem Modell verborgen zugreift Die Funktion liefert in einer definierten Struktur die Anzahl der zu ffnenden Icons deren Bezeichner deren Position Bitm
95. abeslots sein Diese dienen der Speicherung von Werten der Eingabe des Benutzers bzw der Ausgabe zur Benutzeroberfl che Neben den Slots kann ein Tupel Hit wiederum entsprechende Messageports mit einer den Slots entsprechenden Typisierung besitzen 143 9 Vergleich mit bekannten Ans tzen Regeln definieren letztlich Aktionen in denen Argumentwerte in Resultatwerte umgewandelt werden Bei der Ausf hrung von Regeln werden Werte aus so genannten Slots oder Messageports die den Hits zugeordnet sind ausgelesen und gehen in eine Berechnung ein deren Ergebnisse wiederum anderen Slots oder Messageports zugef hrt werden Regeln besitzen so genannte Vorbedingungen die dar ber entscheiden ob eine Regel in einer bestimmten Situation ausgel st werden kann Es gibt verschiedene Regeltypen die sich durch die Art der Aktivierung Ausl sung in ihrer Versorgung mit Argumentwerten in der Weiterleitung ihrer Resultatwerte bzw in ihrer Wirkung unterscheiden Gleichungsregeln Gleichungsregeln werden berechnet ausgel st wenn beispielsweise die entsprechende HIT Instanz instantiiert wird oder wenn bei einem durch ein Ereignis ausgel sten Zustands bergang der Instanz eines der Argumente der Regel betroffen ist Gleichungsregeln haben als Argumente Slots genauer Slotvorkommen in den Instanzen und keine Messageports Weitere erlaubte Argumente sind jeweils Referenzen auf Eingabeslots Eingabe Messageports Benutzertransaktionsregeln und Insta
96. ache dient Kapitel 4 zeigt wie in einer Bottom up Vorgehensweise ausgehend vom Grundmodell und einer naiven konkreten und extensiven Darstellung in mehreren Schritten eine intensivierte abstrahierte Darstellung gewonnen werden kann Dabei werden die wesentlichen Sprachelemente des Ereignisstellendiagramms erarbeitet und Grund berlegungen f r die Entwicklung dieser Sprachelemente ausgef hrt Kapitel 5 stellt das Ergebnis der in den vorangegangenen Kapiteln vorgestellten berle gungen dar das Ereignisstellenmodell Es wird dort zun chst in seiner primitiven Variante dann mit Einbeziehung einer Hierarchierelation formal eingef hrt wobei die Semantik in Form einer bergangsfunktion eines Transitionssystems definiert wird Es folgt die Abbildung eines deterministischen endlichen Automaten auf die Ereignisstellendarstellung und umgekehrt die Abbildung einer eingeschr nkten Ereignisstellendarstellung auf einen endlichen Automaten Danach werden die grafischen Sprachelemente eines Ereignisstellen diagrammes vorgestellt In diesem Zusammenhang wird ein Konzept von Modellsichten erarbeitet das eine flexible Aufteilung eines Modells in verschiedenen Diagrammen bzw Diagrammsichten erlaubt Kapitel 6 diskutiert die Einbeziehung konkreter Widgetdarstellungen in das zun chst in Kapitel 5 vorgestellte Ereignisstellendiagramm das dort nur abstrakte Dialog Elemente Dialog Stellen enth lt Kapitel 7 behandelt die Einf hrung des Begriffes der Exemp
97. adurch dass ein Bezeichner der Condition gefolgt von einer Klammer mit den Parametern die in die Condition eingehen annotiert wird Alternativ dazu kann ein 91 5 Ereignisstellenmodell boolescher Ausdruck annotiert werden Sowohl dem Bezeichner wie auch dem booleschen Ausdruck wird ein C mit Doppelpunkt vorangestellt Die mit Komma getrennten Parameter in der Klammer nach dem Conditionbezeichner sind Stellenbezeichner der Stellen deren aktuelle Werte in die Auswertung der Condition eingehen 2 Darstellung der Condition als Pseudostelle mit Ausg ngen TRUE und FALSE Eine Alternative zur Annotation an eine Kante ist die Darstellung einer Condition in einem Rechteck Im Rechteck sind zwei Rechtecke mit Beschriftung TRUE bzw FALSE eingebettet Die Beschriftung des Rechtecks entspricht der oben beschriebenen Annotation also C gefolgt vom Bezeichner und der Parameterklammer bzw gefolgt vom booleschen Ausdruck Zum Rechteck f hrt eine Triggerkante Von den Teilrechtecken mit Beschriftung TRUE bzw FALSE gehen jeweils ffne oder Schlie e Pfeile aus Mit dieser Darstellung k nnen mehrere mit einer Condition oder deren Negation annotierte Kanten zusammengefasst werden die von der selben Stelle ausgehen und denen die identische Menge an ausl senden Ereignissen zugeordnet ist Condition auf Triggerkante DialogA C condName P1 P2 DialogB T Condition als Pseudostelle Abbildung 5 4 Darstellungen von
98. agiert wird Von der Stelle an der ein Ereignis eintritt das die Propagation ausl st wird eine Triggerkante zum Rechteck der Propagationsfunktion gef hrt Die Rechtecke die Eingangsparameter darstellen k nnen wahlweise mit Bezeichnern f r die formalen Parameter der Propagationsfunktion ausgestattet werden In diesem Fall ist es nicht n tig hinter dem Namen der Propagationsfunktion die Parameter anzugeben Falls jedoch andererseits die Parameter in Klammern angegeben sind ist es nicht notwendig Teilrechtecke f r Eingabeparameter zu zeichnen Gibt es mehrere Ausgangswerte m ssen diese bezeichnet werden Gibt es nur einen Ausgabewert kann das Teilrechteck daf r entfallen Die Wert bertragungspfeile zu den Zielstellen gehen dann vom Rand des Rechtecks der Propagationsfunktion aus Entfallen die Teilrechtecke f r die Eingabeparameter f hren die Wert bertragungskanten der Eingabewerte zum Rand des Rechtecks der Propagationsfunktion Gesamtdialog Abbildung 5 6 Kennzeichnung von Startstellen Nach Definition wird eine Stelle nur ge ffnet wenn mindestens ein ffnepfeil von einer anderen Stelle zur Stelle f hrt oder wenn es sich um eine Startstelle handelt Startstellen werden dadurch erkannt dass entweder kein ffnepfeil in die Stelle m ndet oder dass ein Pfeil ohne Ausgangsstelle aus der leeren Fl che auf die Stelle zeigt Im Beispiel gilt letzteres f r die Stellen B und CloseB B ist eine globale CloseB eine lokale Sta
99. agrams nach Parrow aus PARRO95 Diagrammausschnitte Dargestellt sind in Abbildung 9 7 zwei Diagrammausschnitte die zwei Prozesse vor und nach der Durchf hrung einer Interaktion zeigen Der Prozess OS Operating System stellt dem Prozess P ber den Port b ein Objekt a an der Stelle c zur Verf gung Bei a handelt es sich dabei um eine Verbindung Link zu einem anderen Prozess oder zu einer Ressource im Beispiel Parrows einen Drucker ber die Verbindung k nnen nach erfolgter Interaktion Daten von P oder einer anderen Komponente ber P an den Drucker gesendet werden Die mit doppelter Linie gezogene Kante zwischen a und b repr sentiert eine Ausgabe nach obiger Darstellung im Kalk l out b a bzw das Senden von a nach b Der mit einfach gezogener Line gef hrte Pfeil repr sentiert das Gegenst ck f r eine Interaktion n mlich in b c bzw das Empfangen eines Objektes c ber Port b Dabei ist c nur Platzhalter was in Interaktionsdia grammen mittels schwach schattierter oder leerer Kreise dargestellt wird Konkrete Objekte werden als gef llte Kreise dargestellt Neben den oben dargestellten Diagramm Elementen gibt es eine Reihe weiterer z B doppelt und einfach umrandete Rechtecke zur Darstellung von Replikation und Rekursion polyadische Pfeile zur Darstellung der bertragung von Datenvektoren etc Mithilfe von Interaktionsdiagrammen k nnen letztlich mit relativ wenigen und einfachen grafischen Elementen auch mehr oder wen
100. alit t f r Integration in eine Entwicklungsumgebung Ziel des Prototyps war nicht die Realisierung einer vollst ndigen integrierten Entwicklungsumgebung eines Integrated Development Environments IDE f r die Realisierung kompletter Anwendungen mit den damit verbundenen Komponenten zur Projektverwaltung zum Debugging zum Configuration Management Deployment etc Der Prototyp realisiert vielmehr die Kernfunktionalit t zur Modellierung und Realisierung des Dialogs mit Ereignisstellendiagrammen Zur Anwendung innerhalb eines IDE ist die Integra tion dieser Funktionalit t innerhalb entsprechender Komponenten des IDE erforderlich Ebenso wurde im Prototyp auf eine Reihe von Funktionalit t verzichtet wie sie in einem kommerziellen System als n tzlicher Bestandteil angeboten wird Funktionalit t die aber f r den Nachweis der Modellierung und die Realisierung nicht unbedingt erforderlich ist Z B ist auf eine komfortable M glichkeit zur Edition s mtlicher Widgetattribute in Form eines Attributeditors oder die Integration eines speziellen Editors f r die Definition geometrischer Layout Constraints verzichtet Es darf jedoch angenommen werden dass eine Erg nzung um derartige heute bereits in markt blichen Systemen angebotenen Funktionen nicht im Widerspruch zu den im Prototyp realisierten Konzepten und deren Implementierung steht 10 0 1 Realisierung in Java f r Swing Klassen Die Realisierung des Prototyp selbst erfolgte in seinen beiden
101. anden ist Wenn wir in einer Bottom up Vorgehensweise im WYSIWYG Ansatz siehe Kap 4 von Ereignissen sprechen meinen wir zun chst den konkreten Ereignisbegriff Im extensiven WYSIWYG Ansatz wird zun chst jedes konkrete Ereignis aufgez hlt und jedes Ereignis entspricht auch genau einer Ereignisstelle im Modell Erst durch 35 3 Einf hrung in ein allgemeines Grundmodell f r Dialogstatik und Dynamik die Reduktion der Stellen fassen wir die konkreten Ereignisse zusammen und abstrahieren damit auch in der Darstellung des Modells die konkreten Ereignisse zu abstrakteren Ereignissen Zusammengesetzter Dialog Ein System zusammengesetzter Dialoge HD liegt vor wenn obiges Tupel modifiziert und um eine zweistellige Relation H c E E erweitert wird die hierarchische Zusammensetzungen der Ereignisse beschreibt HD E T W S F t H Falls e1 e2 H sagen wir Ereignis e2 ist Teilereignis von Ereignis e1 H sei die transitive und reflexive H lle von H Eine hierarchische Relation von Ereignissen in einer Ereignisfolge wird induziert wenn wir beispielsweise eine Hierarchie von Stellen X c S amp S einf hren Falls s1 s2 X sagen wir sz ist Teilstelle von s X sei wiederum die transitive und reflexive H lle von X Eine formale Darstellung der durch die Stellenhierarchie induzierten Ereignishierarchien findet sich im Anhang C F r die Ausf hrungen in den folgenden Kapiteln ist nur von Bedeutung dass
102. ann u a auch die Klasse der Laufzeitinstanz dynamisch ver ndert werden Wie f r Ereignistypen ist im Prototypen auch eine implizite automatische Zuordnung konkreter Laufzeitstellen implementiert D h das Diagramm kann per Codegenerierung unmittelbar in ein sinnvolles ablauff higes Testsystem umgewandelt werden siehe Kap 10 8 2 5 Anbindung der Applikationslogik Im derzeitigen Prototypen erfolgt die Anbindung der Applikationslogik entweder durch den Aufruf einer entsprechenden Methode eines einer Laufzeitinstanz zugeordneten Modelobjekts MVC Konzept das in einer Variationsannotation angegeben wird siehe oben z B Variationsfunktionen zur Ermittlung der variablen Ausgabewerte und der Teilstellenstruktur in JobStepGraph oder durch die Zuordnung der konkreten Laufzeitklasse die die Applikationslogik oder zumindest eine Schnittstelle zu ihr beinhaltet Ein Beispiel ist im obigen Diagramm der LoadingJob Dialog dessen konkrete Laufzeitklasse dann bei Instantiierung auch das Laden aus der Datenbank selbst vornimmt Ein weiteres Beispiel ist die pinkfarbene Ereignisstelle SaveToModel Sie stellt eine f r den sp teren Benutzer des Dialogsystems unsichtbare Komponente dar eine komplexe Hilfsstelle die letztlich die Instanz einer Klasse repr sentiert die f r das Ablegen der Daten der Oberfl che in ein Modelobjekt zust ndig ist 125 8 Modellbeispiel 8 2 6 Darstellung von Teilsichten Obiges Ereignisstellendiagramm ist nicht n
103. apitel soll das bisher vorgestellte Ereignisstellenmodell an einem Anwendungsbeispiel aus der unmittelbaren Praxis des Autors beispielhaft erl utert und diskutiert werden Es handelt sich bei der zu modellierenden Anwendung um ein Dialogsystem zur Darstellung und Edition von Batchabl ufen im Umfeld von zeitintensiven Berechnungen von Massendaten f r das Risikomanagement einer Bank DailyCash DailyCash L Bensumes Pecounrions AccountFlows i A Loadinterests account iome CashFlowGent y EveryDay Koawecsun Koaanereste SingleAccounts BaseProducts Cana Variation JobStepDetailsYariation Objects JobStepDetails Aspects JobStepName value SourceStep1 value SourceStep2 value JobStepType value Grid value FieldGroup value ProductTree value Events JobStepDetails Open M Yariation JobStepYariation Objects JobStep1 JobStep2 Aspects Cardinality Identity Position JobStepName value SourceStep1 value SourceStep2 value Events LoadingJob Ready Ready 0 AccountF lows Variation StepRelationvariation Objects StepRelation Aspects Cardinality Identity FromPosition ToPosition Events LoadingJob Ready Ready O Abbildung 8 1 JobEditor als Anwendungsbeispiel eines Ereignisstellendiagramms 119 8 Modellbeispiel In Abbildung 8 1 handelt es sich um eine Teilsicht auf das Modell in einem Ereignisstellendiag
104. aps Texte sowie die Bezeichner der zugeordneten Dialoge zur ck Die von der Funktion gelieferten Daten werden nun vom System automatisch dazu verwendet um die Icons in der Toolbar anzuzeigen Die nicht variierenden Werte werden aus den Exemplaren gewonnen Wenn wir davon ausgehen dass eine m chtige Programmiersprache im Entwicklungssystem vorhanden ist ist dies ein im Allgemeinen gangbarer Weg zur Bestimmung der Varianten Damit wird zwar ein Teil der L sung unserer Aufgabe auf die Ebene einer anderen Programmiersprache ausgelagert und bleibt was die Darstellung im Modell betrifft im Verborgenen In der Praxis erscheint dies jedoch als ein durchaus gangbarer und auch sinnvoller Weg wenn die Ermittlung der Varianten komplex ist F r einfache F lle der Bestimmung der Varianten k nnen wir in unserer Modellsprache Sprachelemente zulassen die eine Auslagerung in eine gesonderte Programmiersprache unn tig macht So k nnen wir z B alternativ zur Definition einer Funktion die Angabe von Ausdr cken zur Zuweisung einfacher Stellenwerte erlauben 7 4 Im ESM implizit vorhandene Variationsarten Built in Variations Die Variation von Stellenwerten ist eine spezielle Art von Variation die wir bereits im ESM vorfinden Im Abschnitt grafische Darstellung Abschnitt 5 3 wurde bereits erw hnt dass in einer Stelle exemplarisch ein Wert eingetragen werden kann Eine Variation dieses Wertes im gerade oben erl uterten Sinn findet statt wenn bei Ei
105. as Schreiben an der Schnittstelle Wir f hren deshalb zwei weitere Typen von Dialogereignis ein 30 3 0 Zentrale Begriffe des Dialogmodells Lesen durch System bergang einer Informationseinheit von der Schnittstelle zu einer anderen Stelle im System In bestimmten F llen ist es sinnvoll das Ereignis der Abnahme der Information von der Dialogschnittstelle zu beschreiben bzw festzuhalten Die Abnahme der Information kann ab dem Zeitpunkt der Verf gbarkeit in einem bestimmten Zeitraum an der Schnittstelle erfolgen Mit der Abnahme von einer Stelle ist eine unmittelbare Wirkung an einer anderen Stelle verbunden die wir ohne Beschr nkung der Allgemeinheit als ein Schreiben von Information an einer anderen Stelle bezeichnen wollen Dabei ist die andere Stelle nicht unbedingt eine Dialogstelle Wahrnehmung durch Benutzer Zumindest aus Symmetriegr nden f hren wir diesen Typ ebenfalls ein wenn er auch nicht Gegenstand unserer Modellierung sein wird Die Wahrnehmung der Information an der Dialogschnittstelle ist das Pendant der Abnahme von Information durch die Applikationslogik Komponente Der vorletzte Ereignistyp Lesen durch System wird besonders dann sinnvoll wenn wir das System in eine Dialogkomponente und eine Restkomponente Systemlogik oder Applikationslogik unterteilen und wir den bergang der Information vom Benutzer zur Dialogkomponente einerseits und von der Dialogkomponente zur Logikkomponente unterscheiden und beschreiben
106. assen ohne Verlust der Bez ge zu anderen abstrakten Ereignisstellen oder konkreten Widgets zu ndern Realisierung von Modellsichten Das in Abschnitt 5 3 2 eingef hrte Konzept der Modellsichten ist im Editor in der Form umgesetzt dass der Benutzer zwischen verschiedenen Sichten auf das Modell w hlen kann in denen er jeweils beliebige Ereignisstellen ausblenden kann Mit dem Ausblenden der Stelle werden automatisch die Bez ge zu oder von der Stelle mit ausgeblendet Wird eine Stelle unsichtbar bleiben zun chst ihre Teilstellen sichtbar Umgekehrt k nnen wahlweise beliebige Teilstellen aus der Sicht entfernt werden Damit wird es m glich in einer Sicht beispielsweise die Details einer Stelle unter Weglassung ihrer umfassenden Stellen zu bearbeiten in einer anderen eine Grobsicht des Modells z B auf Ebene der Fenster bzw der f r die Dynamik der Fenster ausschlaggebenden Stellen ohne Darstellung der brigen Details innerhalb der Fenster 10 2 Schritte zur Codegenerierung 10 2 0 Abbildung abstrakter Ereignisse auf Widgets Widgetattribute und Attributwerte Wie in Kapitel 6 2 am Beispiel des Radio Button Modells ausgef hrt erfolgt die Realisierung eines Ereignisses einer abstrakten Ereignisstelle ohne Beschr nkung der Allgemeinheit etwa im Falle der Umsetzung auf eine Java Anwendung durch die Abbildung auf eine Widgetinstanz einer bestimmten Klasse und letztlich dort auf die Realisierung eines dieser Instanz zugeordneten Ereignisses
107. ation vorsieht und die Ausgabeinformation bereits durch die Darstellung des Widgets am Bildschirm realisiert wird Als Beispiel dient die oben geschilderte Modelldarstellung eines RadioButtons In abstrakter Darstellung haben wir dort vier Modellstellen angegeben die in WYSIWYG Darstellung beispielsweise auf zwei WYSIWYG Stellen zur ckgef hrt werden kann Die WYSIWYG Stelle des RadioButtons repr sentiert dann sowohl die Ausgabe des aktuellen Zustandes als auch die m gliche Eingabe also im Sinne der abstrakten Darstellung zwei Ereignisse Bei den von der Stelle ausgehenden Kanten ist es dann notwendig zu kennzeichnen auf welches der beiden repr sentierten Ereignisse sich die Kante bezieht Wir haben hier also allgemein gesprochen den Fall dass mehrere Modellstellen mit einzelnen Ereignissen durch eine WYSIWYCG Stelle mit mehreren Ereignissen repr sentiert wird N Generator nl ff 1 Ei On 0 Off gt Generator On Off Ei OM Generator On Off jE 1 Off 0 On N Generator n ff 2 Abbildung 6 5 Darstellung des RadioButton Modells in zwei WYSIWYG Stellen Die Abbildung zeigt einen RadioButton in WYSIWYG Darstellung seiner beiden Zust nde Klasse JRadioButton in Java Es handelt sich um ein Ereignisstellendiagramm mit zwei Stellen namens GeneratorOn Off 1 und GeneratorOn Off 2 Die eine Stelle er ffnet die Eingabe von On bei gleichzeitiger Ausgabe Information Off An der an
108. ation zu verstehen Anstelle des einen Pfeils wird zum Variationszeitpunkt von einer den Konventionen entsprechenden Variationsmethode Information ber die Anzahl der tats chlich anzuzeigenden Pfeile geliefert Ebenso werden von entsprechenden Methoden die der Anzahl entsprechenden Identifikatoren der Instanzen der Pfeilklasse sowie die Werte zu den beiden Attributen FromPosition und ToPosition geliefert die vom System ben tigt werden um die Pfeile entsprechend richtig zu positionieren Bei der Pfeilklasse handelt es sich um eine spezielle dem Standard Widgetrepertoire hinzugef gte Klasse die im angestrebten Entwicklungssystem zus tzlich angeboten wird 124 8 2 Erl uterung und Diskussion des Beispiel Diagramms Variation JobStepDetails Bei der dritten Variation in unserem Modellbeispiel handelt es sich um eine Variation die im Gegensatz zu den anderen beiden Beispielen nicht die Anzahl der Exemplare ver ndert Als Variationsaspekte sind lediglich die Werte von Teilstellen angegeben Die Variation findet statt wenn das Dialogobjekt JobStepDetails ge ffnet wird Dieses Beispiel zeigt dass wir in die Ereignismenge bestimmte Metaereignisse wie z B das ffnen einer Stelle oder das Schlie en mit aufnehmen Randbemerkung Im derzeitigen Prototyp sind die oben beschriebenen Variationen etwas anders zu definieren da dort die Variation von Teilstellenattributen z B SrcNamel value sowie eine automatische Umsetzung der logischen Ere
109. ation zur Umsetzung in die Implementierung genutzt Dazu sei insbesondere auf das folgende Kapitel verwiesen 111 7 Exemplarische Darstellung und Variation 7 Exemplarische Darstellung und Variation Im folgenden Kapitel wird eine informelle Einf hrung in den durch diese Arbeit neu eingef hrten Begriff der exemplarischen Darstellung und Variation kurz Exemplarvaria tion gegeben Nach einer Skizzierung der Problemstellung und der daraus resultierenden Zielsetzung werden die wichtigen Aspekte zur Definition einer Exemplarvariation festgehalten und an zwei Beispielen erl utert 7 0 Problemstellung Der Bottom up Ansatz mit dem Ziel des konkreten Darstellens der Dialogelemente und des Ablaufs kommt bisher u a an seine Grenzen wenn prinzipiell sehr viele alternative Elemente aufzuzeichnen sind und die Darstellung schlicht an der Menge der darzustellenden Elemente scheitert wenn insbesondere einzelne Elemente in alternativen Situationen h ufig ihre Eigenschaften ndern Dies ist z B dann der Fall wenn ein Dialogelement durch direkte Manipulation z B durch Ziehen der Maus in Position oder Gr e ver ndert wird dynamische grafische Elemente wenn der konkrete Ablauf und die Ausgestaltung des Dialogs von Kriterien abh ngt die erst im konkreten Einsatzfall der konkreten Anwendung in einem spezifischen Kontext dynamisch bestimmt werden k nnen Ein Beispiel f r letzteren Fall ist die Darstellung eines Suchergebnisses eine
110. aufnehmen zu k nnen Deshalb wurde hier der Stellenbegriff und die Relationen zwischen Stellen zum ffnen und Schlie en eingef hrt Au erdem wird ber Wert bertragungskanten in der grafischen Darstellung die bertragung von Werten zwischen Stellen visualisierbar Im Ereignismodell fehlt zudem ein hierarchischer Ansatz 133 9 Vergleich mit bekannten Ans tzen 9 2 Dialognetze Janssen JANSS96 verwendet f r die Modellierung der Dialogdynamik so genannte Dialognetze Er setzt dabei auf einer Variante der Petrinetze so genannten beschrifteten Bedingungs Ereignisnetzen B E Netzen JESSEN87 auf die er um einige Sprachelemente erweitert Er f hrt so genannte optionale Fl sse modale Stellen komplexe Stellen den dynamischen Aufruf von Unterdialognetzen und Makros ein Interpretation der Marken in Dialognetzen Ein Kernkonzept der einfachen Petrinetze ist dass eine Transition nur feuert wenn alle Eingangsstellen der Transition eine so genannte Marke aufweisen und alle reinen Ausgangsstellen keine Marke besitzen Bei Dialognetzen stehen Stellen f r Fenster und der Besitz einer Marke wird interpretiert als Fenster ge ffnet Nach dem Feuern der Transition wandern die Marken von den Eingangsstellen zu den Ausgangsstellen Dies bedeutet bei Dialognetzen dass die Fenster der Eingangsstellen geschlossen die der Ausgangsstellen ge ffnet werden Nebenl ufigkeit Die Nebenl ufigkeit von Dialogen wird in Dialognetzen n
111. b MICROO1 Herrtwich F G Hommel G Kooperation und Konkurrenz nebenl ufige verteilte und echtzeitabh ngige Programmsysteme Springer Verlag Studienreihe Informatik p 145 161 1989 Hoare C Communicating Sequential Processes Prentice Hall 1985 Hudson S E Graphical Specification of Flexible User Interface Displays Proceedings ofthe ACM SIGGRAPH Symposium on User Interface Software and Technology ACM press p 105 114 1989 ISO ISO 9241 Ergonomic requirements for office work with visual display terminals VDT Draft 12 1990 Jacob R J K A Specification Language for Direct Manipulation User Interfaces ACM Transactions on Graphics Vol 5 No 4 p 283 317 1986 Janssen C Dialogentwicklung f r objektorientierte graphische Benutzungsschnittstellen IPA IAO Forschung und Praxis Springer 1996 Jessen E Valk R Modelle f r Rechensysteme Springer 1987 Lin J Thomson M Landay J A A Visual Language for Sketching Large and Complex Interactive Designs CHI 2002 Minneapolis Minnesota USA DiavACM 2002 Lonczewski F Providing User Support for Interactive Applications with FUSE IUI 97 ACM 1997 Lonczeswski F Schreiber S Generating User Interfaces with the FUSE System Technischer Bericht Technische Universit t M nchen Technical Report TUM I9612 1996 Lonczeswski F Schreiber S The FUSE System An Integrated User Interface
112. be eines entsprechenden Kommandos Die hier gew hlte Modellvariante erlaubt zu jedem Zeitpunkt nach Er ffnen des Dialogs zur Auftragserfassung die Eingabe des Kommandos Berechnen Ebenso erlaubt es die v llig nebenl ufige Eingabe aller anderen Daten im Kundendialog und gleichzeitig im Dialog zur Erfassung der Auftragspositionen Es handelt sich also bei dieser Wahl des Modells um eine relativ freiz gige Gestaltung des Dialogs Aus aufgabenlogischer Sicht kann der bergang zum Preisdialog allerdings erst tats chlich erfolgen wenn alle notwendigen Daten zum Kunden und mindestens eine Auftragspositionen vorliegen Die Erf llung der logisch geforderten Bedingung f r den bergang zum Preisdialog kann sowohl durch ein Ereignis aus dem Dialog Erfassen Kundendaten als auch aus dem Dialog Erfassen Auftragsposition erfolgen Denn die Vollst ndigkeit der zu erfassenden Daten kann grunds tzlich durch Eingaben aus beiden nebenl ufigen Teildialogen erreicht werden Die Pr fung der Vollst ndigkeit der Daten geschieht nun mittels einer entsprechend zu definierenden Bedingung Condition die wir pr fen nachdem der Benutzer den Wunsch zur Preisberechnung ge u ert hat Erst wenn alle Daten vorliegen erfolgt gem der formulierten Bedingung der bergang zum Preisdialog d h die Ausgabe der Preisdaten tats chlich siehe Abbildung 4 15 71 4 Bottom up Modellierung und Abstraktion Abbildung 4 14 Auftragserfassung mit
113. bei Entwurf und Realisierung von Dialogsystemen beschrieben wie sie in der Regel in Projekten verfolgt werden n mlich der Einsatz eines Werkzeuges zum Rapid Prototyping oder Rapid Development der Einsatz eines modellbasierten Systems zur Top down Modellierung und die Realisierung rein auf Ebene der Programmierung wie z B in Java C oder einer Skriptsprache ohne Einsatz eines der erstgenannten Hilfsmittel Sie sollen als Ausgangspunkte f r die Entwicklung der vorgestellten neuen Methodik dienen Die ersten beiden Ans tze werden wenn berhaupt manchmal alternativ manchmal nebeneinander sich erg nzend im selben Projekt angewendet Die eine Methodik ist unter Verwendung eines Werkzeuges zum Rapid Prototyping oder Rapid Development ein grafi sches Dialogsystem prototypisch zu entwerfen bzw im Fall von Rapid Development Syste men mit oder nach ersten Entwurfsschritten die Entwicklung f r den produktiven Einsatz durchzuf hren Wir wollen im Folgenden in der Regel ohne Einschr nkung der Allgemein heit von Rapid Development Systemen RDS sprechen und Rapid Prototyping Systeme wenn nicht besonders hervorgehoben mit einschlie en Wir k nnen derartige RD Systeme in die Kategorie der sogenannten Lower Case Tools einordnen Die alternative Methodik ist der Einsatz eines sogenannten Upper Case Tools zum Aufbau eines zun chst abstrakten Modells unter Verwendung einer entsprechenden abstrakten Model lierungssprache Wir wollen
114. bei jedes Ereignis ein Tupel aus Wert Stelle und Typ e w s t Ee Ec W amp S amp T T Menge von Ereignistypen T Ig Os Ms Im Gegensatz zum Grundmodell sehen wir im ESM vereinfachend keine Leseereignisse explizit vor Der Vorgang des Lesens ist implizit ber eine zustandsspezifische Wertezuordnung zu Stellen siehe unten WSHist Menge der Wertezuordnungen im Modell enthalten Es wird angenommen dass Eingabeereignisse entspricht Typ Ig vom System wahrgenommen also gelesen werden k nnen bis die dem Ereignis zugeordnete Stelle geschlossen wird Ebenso wird gefordert dass Ausgabeereignisse und Schreibereignisse an Hilfsstellen Typen Os bzw M von Benutzer bzw System gelesen werden k nnen bis die zugeordnete Stelle geschlossen wird W Menge von Werten S Menge von Ereignisstellen So Menge von Startstellen So c S T Zuordnungsfunktion von Ereignistypen t E gt T o Funktion zur Zuordnung von Stellen zu Ereignissen o E gt S 76 OC Start RO RC ERO ERC KRO KRC 5 0 Formale Darstellung Wir fordern t e1 Ms A 1 e2 Os v t e2 IB gt o e1 o e2 d h Stellen sind entweder Hilfsstellen oder Dialogstellen Funktion zur Zuordnung eines Wertes zu Ereignis e E gt W partielle Funktion zur Zuordnung eines Wertes zu einer Ereignisstelle zum Startzeitpunkt Start Ss W ffne Relation O f r Open ROc S S Schlie e Relation C f r Close RC c S 8
115. ber eine Stellenhierarchie die an den Teilstellen einer zusammengesetzten Stelle stattfindenden Ereignisse zu einem Ereignis an der zusammengesetzten Stelle zusammengefasst werden k nnen Wenn wir Ereignishierarchien mit zusammengesetzten Ereignissen einf hren ist es sinnvoll die Menge T der Ereignistypen um die Kombinationen aus den vier Grundtypen zu erweitern Wir erhalten dann eine Menge T c T T Is Os Ls Lg IsOs IsLs IsLg OsLs OsLg LsL IsOsLs IsOsLg IsLsLg Os Ls Le IsOsLegeLs Entsprechend haben wir dann auch eine Funktion T E gt T T ordnet zusammengesetzten Ereignissen die entsprechenden zusammengesetzten Typen zu 36 4 0 WYSIWYG Ansatz 4 Bottom up Modellierung und Abstraktion Im nun folgenden Kapitel wird auf Basis des oben vorgestellten Verst ndnisses von Dialog das wir in einem sogenannten Grundmodell des Dialogs zusammengefasst haben ein Bottom up Ansatz der Dialogmodellierung diskutiert Der Bottom up Ansatz geht von der terminalen konkreten Erscheinungsform des Dialogs zur Laufzeit aus und versucht so weit wie m glich diese Erscheinungsform im Modell direkt widerzuspiegeln im Folgenden WYSIWYG Darstellung auch extensive Darstellung genannt Da wir bei einer konsequenten WYSIWYG Darstellung erwartungsgem sehr schnell an Grenzen unter anderem bez glich der Vollst ndigkeit sto en werden einige wenige aber wesentliche Schritte von der konkreten zu einer abstrakteren reduzie
116. ch auf den Fall dass der Wert von der neuen Stelle gelesen wird wenn er vorher von der urspr nglichen Exemplarstelle abgelesen wurde Wir f hren dazu formal eine Funktion ein die eine entsprechende Vertauschung der Stellen bez glich der Werteversorgung ber cksichtigt die wir jeweils K RO K RC und r RO nennen wollen K RO RO gt CUVO K RO s s c mit s s RO c EC wobei die Condition c C sich von c RO orig s orig s dadurch unterscheidet dass bei allen Wertezuordnungen im Definitionsbereich die Stellen orig s bzw orig s ersetzt werden durch die Stellen s bzw s falls orig s bzw orig s dort vorkommen Entsprechend wie K RO sind auch K RC und n RO zu interpretieren Damit ergibt sich nun f r KRO KRO s s K RO s s f r s s RO Handelt es sich bei s und s um keine neuen Stellen gilt K RO s s KRO orig s orig s da dann orig s s und orig s s und ein Vertauschen von Stellen in den Wertezuordnun gen des Definitionsbereichs der Condition wirkungslos ist 181 Anhang E Ist eine der beiden Stellen s s 0 B d A s eine neue Stelle wird in den Wertezuordnungen die die Elemente des Definitionsbereichs von c KkRO orig s orig s darstellen ein Vorkommen der entsprechenden Exemplarstelle orig s gegen s ausgetauscht Somit ergibt sich dann per Definition die Condition c K RO s s
117. ch der potentielle Benutzer sollen m glichst fr h einen konkreten Eindruck vom zu erstellenden System erhalten Offenes System Wir gehen davon aus dass eine vollst ndige Darstellung des zu erstellenden Systems nicht mit rein grafischen Sprachelementen der zu entwickelnden Modellsprache m glich ist Ziel ist deshalb eine Kombination der grafischen Sprachelemente mit textuellen Elementen sowie mit der M glichkeit komplexe Sachverhalte auch in einer Programmiersprache des Basissystems ausdr cken zu k nnen ohne dabei den grafisch definierten Teil des Modells verwerfen zu m ssen Grafische und textuelle Darstellung sowie die Darstellung in einer Programmiersprache des Basissystems sollen sich erg nzen Freiheit im Entwurf Das angestrebte System zur Modellierung soll Entwurf Implementierung und Dokumentation unterst tzen Insbesondere soll die Phase des Entwurfs von Anfang an durch das angestrebte System begleitet werden Dies bedeutet dass z B zun chst skizzenhafte unvollst ndige Modellinformation schrittweise erg nzt und vervollst ndigt werden kann Besonders verfolgt wird in dieser Arbeit das Ziel dass der Systemdesigner in einem Bottom up Ansatz ausgehend von konkreten Beispielen m glichst nahtlos zu einer vollst ndigen Beschreibung gelangen kann 29 3 Einf hrung in ein allgemeines Grundmodell f r Dialogstatik und Dynamik 3 Einf hrung in ein allgemeines Grundmodell zur Beschreibung von Dialogstatik und Dynamik
118. ch f zuordnet Das zusammengesetzte Ereignis entsteht dabei so dass alle an einer Stelle und deren Teilstellen in einer Ereignisfolge f stattfindenden Ereignisse zu einem der Stelle zugeordneten Gesamtereignis zusammengefasst werden I S F gt E Gpartiell amp ist partiell definiert da ggf nicht in allen Ereignisfolgen aus F an allen Stellen aus S Ereignisse auftreten H kann nun z B definiert werden als die Relation eine Polyhierarchie die alle durch die Stellenhierarchie X induzierten Hierarchien H vereint H U Hr feF 174 Tabellarische Gegen berstellung von Implementierungen des RadioButton Modells Anhang D RadioButton Modell implementiert mit einem und vier Widgets Tabellarische Gegen berstellung zur Implementierung der Stellen des Ereignisstellenmodells eines RadioButtons Kap 6 mit vier Widgetinstanzen und einer Instanz JRadioButton Die Operationen die zur Realisierung der logischen Ereignisse So bis S bei der Implementierung mit einer einzigen RadioButton Instanz Abschnitt 6 1 angegeben sind sind nur notwendig wenn ein bergang von einer Stelle au erhalb zur jeweiligen Stelle So S S2 oder S erfolgt berg nge zwischen den Stellen So S S2 und S sind interne berg nge innerhalb der RadioButton Instanz und werden automatisch durch den Code des RadioButtons geleistet Stelle Er Widget Ereignis Attribut Operationen ab eig konkret strakt nis Typ Wert Klasse Instanz I
119. chen Ablauf die Vorgeschichte des Dialogs nicht daf r ausschlaggebend sein kann welche der m glichen Schritte eingeschlagen wird Beispielsweise kann nach Auswahl der Vollinstallation ein Fehler auftreten weil der vorhandene Speicherplatz nicht ausreicht und deshalb die Fehlermeldung ausgegeben wird w hrend nach Wahl der Minimalinstallation die Installation erfolgreich verl uft und entsprechend die Erfolgsmeldung am Bildschirm erscheint D h dass die Gesamtsituation im System z B nach der Wahl einer Alternative zum Installationsumfang durchaus unterschieden werden muss Betrachtet man jedoch lediglich die Teilkomponente Dialogsystem und l sst die Applikationslogik Komponente au er Acht sind die m glichen Folgeschritte nach der alternativen Auswahl dieselben Das Dialogsystem hat also in beiden F llen gleich ob Minimalumfang oder Vollinstallation gew hlt wurde eine Reaktion auf den Fehlerfall und eine Reaktion auf den erfolgreichen Ausgang vorzusehen Welche der beiden Meldungen dann ausgegeben werden ist von der Applikationslogik Komponente zu entscheiden siehe Einf hrung von Conditions 4 1 3 46 4 1 Reduktion von Stellen und Transitionen Dies bedeutet umgekehrt dass f r die Applikationslogik selbstverst ndlich relevant sein kann welcher Pfad von alternativen Dialogpfaden eingeschlagen wurde Wenn wir in unserem Dialogmodell also alternative Dialogpfade wieder auf einen gemeinsamen Pfad zusammenf hren setzen wir vorau
120. chenobjekten im Modelldiagramm geschaffen SetClockDialog P increaseM Minutes P decreaseMi Minutes P increaseH Hours P decreaseH Hours Abbildung 9 6 Set Clock Dialog in ESD Darstellung Die Abbildung zeigt die Modellierung des Rumbaugh Beispiels Abbildung 9 5 mit einem Ereignisstellen Diagramm Im Gegensatz zum State Chart sind hier den Ausgabe und Eingabeereignissen jeweils Stellen zugeordnet deren Typ durch die Annotationen I bzw O erkennbar ist Aktionen werden lediglich in Form von Propagationsfunktionen zum Hochz hlen und Erniedrigen der Stellenwerte eingesetzt Die angegebenen exemplarischen Werte 00 dienen als Voreinstellung 138 9 4 Pi Kalk l 9 4 Pi Kalk l Robin Milner stellt mit dem so genannten Pi Kalk l MILNER99 eine Theorie vor mit der der Ablauf und das Zusammenwirken konkurrierender Prozesse beschrieben werden kann Ein besonderes Augenmerk des Kalk ls liegt auf der Beschreibung des dynamischen Aufbaus und Abbaus von Verbindungen process links zwischen existierenden Prozessen was mit dem Begriff Mobilit t von Prozessen bzw besser Mobilit t von Prozessverbindungen charak terisiert wird Als Anwendungsbeispiele werden von Milner etwa der Mobilfunk das Internet aber auch Prozessabl ufe innerhalb eines Rechners z B die Zuteilung von Ressourcen an Prozesse etc genannt Der Ansatz ist jedoch so allgemein dass er auch f r die Beschreibung von Dialogsystemen und die Mod
121. cher Typ welcher Wert und ggf welche Stelle genau falls das dargestellte Widget ein Ereignis an einer Teilkomponente aufweist gemeint ist Wir m ssen nun im Folgenden untersuchen inwieweit eine WYSIWYG Darstellung nach wie vor m glich ist nachdem im Ereignisstellendiagramm von einer Darstellung von Folgeschritten einzelner Ereignisse abgewichen werden kann und das Ereignisstellenmodell die in Abschnitt 4 und 5 besprochenen Schritte der Reduktion der extensiven Darstellung zu einer komprimierten intensiven Darstellung erlaubt 108 6 2 WYSIWYG Darstellung der Ereignisstellen 1 zu 1 Darstellung Modellstelle mit einem Ereignis zu Widget mit einem Ereignis Das Konzept der Ereignisstellen in einem ESM unterst tzt neben allen M glichkeiten der komprimierten Darstellung nach wie vor eine extensive Darstellung bei der eine Ereignisstelle genau ein Ereignis repr sentiert Hier kann die WYSIWYG Darstellung so erfolgen wie dies in Abbildung 4 1 angedeutet ist Das zur Laufzeit f r die Realisierung verwendete Widget wird visualisiert zusammen mit einer geeigneten Darstellung des dort erfolgenden Ereignisses der Eingabe oder Ausgabe Zusammenfassung mehrerer abstrakter Modellstellen zu einer WYSIWYG Stelle In manchen F llen ist es sinnvoll in der WYSIWYG Darstellung mehrere abstrakte Ereignisstellen zu einer WYSIWYG Stelle zusammenzufassen Dies gilt z B dann wenn ein Widget sowohl eine Ausgabe von Information als auch die Eingabe von Inform
122. chern von Werten in der Datenbank dass eine Propagationsfunktion die Hilfsstelle Datenbank so beschreibt dass dort die neuen Werte eingef gt werden Wir werden derartige Hilfsstellen nat rlich nicht vollst ndig beschreiben d h ausmodellieren wollen wenn wir ein Dialogmodell f r eine Datenbankapplikation erstellen wollen Wir k nnen z B im Allgemeinen nicht den Anfangswert einer derartigen Hilfsstelle f r den Start des Systems angeben In der Praxis werden wir uns also damit behelfen dass wir beispielsweise als Wert der Hilfsstelle einen Bezeichner f r die Datenbank angeben wobei wir uns dessen bewusst sind dass die formal korrekte Propagationsfunktion bei jeder ihrer Anwendungen auf den dynamisch sich ndernden aktuellen Inhalt der Datenbank und nicht nur auf den konstanten Bezeichner zugreift und ein entsprechendes aktuelles Ergebnis f r die Ausgabe liefert F r das Abspeichern in der Datenbank gilt hnliches Formal korrekt berechnet die Propagationsfunktion einen neuen Wert der Hilfsstelle Datenbank der dort abgelegt wird In der Praxis geben wir jedoch die Datenbank nicht als Ausgabeparameter bzw Hilfsstelle an Es handelt sich dann sozusagen um eine verborgene nicht im Modell dargestellte Stelle deren Beschreiben durch die Implementierung der Propagationsfunktion realisiert wird Um die verborgene Stelle im Modell sichtbar zu machen k nnte man beispielsweise einen besonders ausgezeichneten Typ von Hilfsstel
123. chner im Diagramm Wird also die Position der Instanz zur Lauf zeit aus der Position der Stellen im Diagramm abgeleitet muss hier letztlich eine Entschei dung f r eine der Stellen getroffen werden Die Entscheidung ist allerdings irrelevant f r die Codegenerierung wenn die Geometrie mittels Layoutattributen des Widgets dynamisch zur Laufzeit entschieden wird oder die Layoutgestaltung generell in einem anderen Editor durchgef hrt wird Die Vorgehensweise der Zusammenf hrung der Aussagen an den Stellen ist derzeit im Prototyp festgelegt und kann nicht beeinflusst werden Hier w re es ggf sinnvoll weitere Sprachelemente einzuf hren die die Art der Zusammenf hrung steuerbar machen Die Zusammenf hrung wird im Prototyp wie folgt implementiert O B d A beschreiben wir die Zusammenf hrung nur zweier Stellen in einer Instanz Zwei Diagrammstellen sl und s2 mit gleichem Bezeichner und gleicher hierarchisch berge ordneter Stelle werden so interpretiert als w re es eine Stelle s die alle Sprachelemente im Diagramm von den beiden zusammenzuf hrenden Stellen bernimmt Dies bedeutet insbesondere f r Eingehende Pfeile in s enden alle Pfeile die urspr nglich in s1 oder s2 enden Die Annotationen der Pfeile bleiben erhalten Ausgehende Pfeile von s gehen alle Pfeile aus die urspr nglich von s1 und s2 ausgehen Die Annotationen der ausgehenden Pfeile bleiben ebenso erhalten Annotationen der Stelle Alle Annotationen werden
124. chnittstelle ber Bildschirm Tastatur und Maus ist jedoch in der Regel mindestens die Eingabe ber Tastatur sequenziell Jedoch ist es auch hier implementierungstechnisch m glich die Eingabe quasiparallel durchzuf hren und jederzeit von einem Teildialog in den anderen zu wechseln Unsere logische Darstellung im Modell entspricht also in diesem Fall auch einer blichen Implementierungstechnik bei grafischen Oberfl chen 69 4 Bottom up Modellierung und Abstraktion Abbildung 4 12 Beispieldialog Auftragserfassung Abbildung 4 12 zeigt am Beispiel der Auftragserfassung einen Dialog der im Wesentlichen den eben vorgestellten Dialog als Teildialog enth lt Insgesamt besteht der Dialog aus drei Teildialogen n mlich der Erfassung der Kundendaten entspricht obigem Dialog Adresserfassung einem Dialog zur Erfassung der Auftragspositionen und einem dritten zur Darstellung des Preises Dabei sei aus der logischen Analyse der Auftragserfassung hervorgegangen dass die Ermittlung des Preises automatisch durch das System erfolgen soll und vor der Ermittlung des Preises die Kundendaten und die Auftragspositionen bekannt sein m ssen Somit haben wir eine logische Abh ngigkeit des Preisdialogs von den beiden anderen Dialogen die zueinander nebenl ufig gestaltet werden k nnen Die Erfassung der Kundendaten kann logisch unabh ngig von der Erfassung der Auftragspositionen erfolgen Dies k nnen wir nun auf einer relativ abstrakten Hierarchie Ebene
125. cht auf andere Dialogarten ab Informeller Modellvergleich zum ESM Der Modellansatz des Pi Kalk ls wie auch des Vorg ngers CCS weist eine Reihe interessanter Gemeinsamkeiten mit dem Ansatz auf der zum Ereignisstellenmodell ESM f hrte Wie im ESM werden Aktionen und Ereignisse gleichgesetzt Milner geht sogar soweit dass er Aktionen auch als Beobachtungen Observations bezeichnet womit der Vorgang des Lesens im ESM Ereignistyp L f r Lesen als eine Seite der Interaktion zwischen zwei kommunizierenden Komponenten zum Ausdruck gebracht wird Im Gegensatz dazu sind die internen Ereignisse innerhalb eines Prozesses nicht beobachtbar Transition t im Pi Kalk l Im ESM d rfte diese Sicht in etwa der synchronen Abarbeitung von Ereignissen in der Maschine an unsichtbaren Stellen Hilfsstellen entsprechen Wie im ESM ist die Nebenl ufigkeit durch einfaches Nebeneinanderstellen Komposition der nebenl ufigen Komponenten ausgedr ckt Die Darstellung von Abh ngigkeiten im sequentiellen Ablauf werden im Pi Kalk l durch Pr fixe ausgedr ckt im ESM entspricht dies im Wesentlichen den Relationen zum ffnen und Schlie en der Stellen Alternative berg nge wie sie im Pi Kalk l mittels der Summation beschrieben werden werden im ESM in einer Kombination von ffne Schlie e Relation und Conditions sowie Propagationsfunktionen gesteuert Welche der Alternativen einer Summation zum bergang jeweils gew hlt wird h ngt im Pi Kalk
126. chteile 19 11 Abstrakte Modellsysteme 20 1 1 0 Statische Objektmodellierung 20 1 1 1 Modellierung der Dynamik 20 1 1 1 0 Zustands bergangsdiagramme 20 1 1 1 1 Petrinetze 21 1 1 1 2 Dialog Grammatiken 22 1 1 1 3 Ereignismodelle 22 1 2 Direkte Programmierung 23 1 2 0 Vorteile 23 1 2 1 Nachteile 24 1 3 Res mee 24 Neuer integrierter Modellierungsansatz 26 2 0 Kernziele 26 2 0 0 Logische Dialogmodellierung unter Einbeziehung der Dynamik 26 2 0 0 0 Begriffskl rung logischer Dialog 26 2 0 0 1 Abgrenzung zum Layout 27 2 0 0 2 Definition der Dynamik 28 2 0 1 Integration logischer und layoutbehafteter Darstellung 28 2 1 Abgeleitete Ziele und Rahmenbedingungen 29 Einf hrung in ein allgemeines Grundmodell zur Beschreibung von Dialogstatik und Dynamik 30 3 0 Zentrale Begriffe des Dialogmodells 30 3 0 0 Dialogereignis 30 3 0 1 Dialogstelle 31 3 0 2 Dialogwert 33 3 0 3 Relationen des Dialogs 33 3 0 3 0 Hierarchie 33 3 0 3 1 Dialogfolge 34 3 1 Formale Darstellung des Grundmodells 34 Bottom up Modellierung und Abstraktion 37 4 0 WYSIWYG Ansatz 37 4 0 0 Ein einfaches Beispiel der WYSIWYG Modellierung 39 4 Inhaltsverzeichnis 4 0 1 Wahl von Widgets als Stellenmenge zur Laufzeit 42 4 0 2 Grenzen der WYSIWYG Modellierung 45 4 1 Reduktion von Stellen und Transitionen 45 4 1 0 Zusammenfassung von Werten 48
127. d aus der Aufgabenanalyse sein diese Ordnung im Dialog auszudr cken Dann haben wir z B die M glichkeit die Elemente durch entsprechende Zuordnung r umlicher Koordinaten in einer bestimmten Reihenfolge anzuordnen Wir k nnen die Reihenfolge der Elemente auch beispielsweise mittels Zuord nung einer bestimmten Farbe auf die durch die Frequenzen des Farbspektrums gegebene Ordnung abbilden Eine andere M glichkeit der Darstellung ist es eben auch die gegebene Ordnung durch eine entsprechende zeitliche Reihenfolge auszudr cken Es handelt sich hier um eine Abbildung der gegebenen Ordnung der darzustellenden Elemente auf die durch die zeitliche Reihenfolge der Darstellung gegebene Ordnung Aus logischer Sicht ist hier die zeitliche Anordnung nicht notwendigerweise erforderlich Sie ist aber eine legitime Alternative der Darstellung der vorgegebenen Ordnung Abh ngigkeiten im Sinne des Frage Antwort Dialogs Eine sofort einleuchtende Abh ngigkeit in der Reihenfolge von Dialogschritten liegt in einer ganzen Reihe von Dialogen begr ndet die ein Charakteristikum der Frage Antwort Dialoge teilen Es scheint auf den ersten Blick unmittelbar klar dass zwischen Frage und Antwort eine zeitliche Abh ngigkeit besteht die die Frage vor die folgende Antwort stellt Beim Frage Antwort Dialog verstanden als eine der bekannten Dialogarten stellt das System die Frage und der Benutzer antwortet Wesentlich f r unsere momentane Betrachtung ist dass generel
128. d ein eindeutiger Bezeichner bestimmt Dass hier Identity angegeben ist verdeutlicht dies ist aber nicht notwendig Da wir uns bei den zu variierenden Exemplaren auf der Ebene konkreter Widgets befinden ist es bereits m glich auch Attribute der Widgets als Variable anzugeben In der sinnvollen Annahme dass die Widgets in einem Container positioniert werden m ssen geben wir als zu variierendes Attribut die Position mit Die Angaben zur Variation der Teilstellenwerte setzen hier voraus dass eine Standardabbildung des abstrakten Attributes value auf ein konkretes Attribut des f r die Teilstelle verwendeten Widgets existiert In unserem Beispiel k nnen wir annehmen dass value auf das Attribut Text der hier benutzten Java Widgetklasse JTextArea unter Verwendung der Schnittstellenfunktion setText abgebildet wird Da bei der Variationsinformation die Angaben zum Aufruf einer Variationsfunktion fehlen k nnen wir wiederum annehmen dass ein Default Protokoll zum Aufruf einer Variationsfunktion verwendet wird Im realisierten Prototypen ist die Konvention dass zu jedem Dialogobjekt dem ein Variationsereignis zugeordnet wird ein Model Objekt existiert das f r die einzelnen zu variierenden Aspekte eine entsprechende Methode besitzt die die gew nschten Daten zur Variation zur ckliefert siehe dazu auch Prototyp Kap 10 Variation StepRelationVariation Die Variation StepRelationVariation ist hnlich zur vorherig beschriebenen Vari
129. damit mehrere Teilsichten auf das 100 5 3 Grafische Darstellung Modell dargestellt werden Dies erh ht die berschaubarkeit und ist unabdingbar f r komplexe Anwendungsf lle Insbesondere kann damit auch in vielen F llen erreicht werden dass die Stellen relativ ortsgetreu dargestellt werden k nnen Stellen die sich in einer koordinatentreuen WYSIWYG Darstellung berlagern werden in mehrere Diagramme mit Teilsichten aufgeteilt Generell gesehen haben wir dann mehrere Diagramme die jeweils nur eine Teilsicht des gesamten Modells bieten Erst in ihrer Zusammenf hrung ergibt sich wieder ein Gesamtbild des Modells Durch die Vergabe von eindeutigen Stellenbezeichnern kann definiert werden wie die Zusammenf hrung erfolgen kann Sp testens dann wenn das Modell vollst ndig spezifiziert sein soll muss die unvollst ndig dargestellte Stelle an anderer Diagrammstelle im selben Ereignisstellendiagramm oder in einem anderen Diagramm vervollst ndigt werden 101 6 Abstraktion vom konkreten Widget 6 Abstraktion vom konkreten Widget In Abbildung 4 1 haben wir ein einfaches Modellierungsbeispiel gesehen das konkrete Widgets aus einer realen Laufzeitumgebung im Dialogablauf zeigt In den dann nachfolgen den Abbildungen wurde auf die konkrete Darstellung von Widgets verzichtet An die Stelle von Widgets traten in der Darstellung der Modell Grafen Knoten die wir auch als Dialogstel len oder auch nur als Stellen bezeichnet haben Stellen
130. den so genannten Dialoggraphen SCHLU95 der Fall ist Ein vielleicht schwerer wiegender Nachteil ist dass mit Petrinetzen die Darstellung des Datenflusses nur mit zus tzlichen nicht grafischen Sprachmitteln erreicht werden kann 1 1 1 2 Dialog Grammatiken Eine weitere bekannte Technik der Modellierung von Dialog ist die Beschreibung in Form einer Grammatik GREEN86 Die Struktur des Dialogs wird dabei mit Hilfe der Produktionsregeln unter Verwendung terminaler und nichtterminaler Symbole festgelegt ber die Produktionsregeln kann die Analyse der Benutzer Eingaben durchgef hrt werden Werden w hrend der Analyse bestimmte Produktionen erkannt wird den einzelnen Produktionen zugeordnete Information zum Aufruf von Anwendungsfunktionen und zur Ausgabe von Information an der Pr sentationsschnittstelle genutzt Eine formale Darstellung der Produktionsregeln kann textuell etwa in bekannter BNF Notation erfolgen Als grafische Variante der Darstellung dienen Syntaxdiagramme oder baumartige Darstellungen der Produktionsregeln EICKELO1 Eine Variante zur Dialogmodellierung mit Grammatiken bilden Attribut Grammatiken bei denen jedem nichtterminalen Symbol ein Attribut des Typs Applikation zugeordnet ist EICKELO1 Ein Vorteil des Einsatzes von Grammatiken ist dass es sich um eine insbesondere im Umfeld des Compilerbaus bew hrte Technik handelt die teilweise auch Anwendungsprogrammierern nicht unbekannt ist Die Darstellung einer sequenzie
131. deren ist umgekehrt die Eingabe von Off m glich und es wird On ausgegeben Dies ist durch Annotation an der jeweiligen Stelle sichtbar GeneratorOn Off 1 ist Startstelle was durch den Triggerpfeil ohne Ausgangsstelle aus dem Leeren angedeutet ist 109 6 Abstraktion vom konkreten Widget Die Pfeile mit dem durchkreuzten Kreis legen fest dass bei der durch Annotation angegebenen Ereignismenge die Ereignismenge der Ausgangsstelle gesperrt und die Ereignismenge an der Zielstelle ge ffnet wird Zusammenfassung von ffne und Schlie epfeil in jeweils einem Beide Stellen werden auf dasselbe Widget zur Laufzeit abgebildet Im vorliegenden Prototypen des Modellerditors geschieht das in diesem Fall dadurch dass die Namen der beiden Stellen sich nur im so genannten Indexteil 1 und 2 unterscheiden Generell wird bei der Umsetzung des Diagramms in die Implementierung Information f r die Abbildung der Stellen auf Widgetinstanzen ben tigt Diese kann durch zus tzliche Annotation den Stellen mitgegeben werden oder wird aus der Namensgebung der Stellen automatisch ermittelt Desweiteren ist f r die Implementierung eine Zuordnung der hier gezeigten logischen Ereignisse auf die m glichen Ereignisse der Widgetinstanz n tig Ein intelligenter Abbildungsmechanismus erkennt in diesem Fall dass nur ein logisches Eingabeereignis pro Stelle existiert und bildet standardm ig dieses Ereignis auf Mausklick ab Ebenso ka
132. det an einer Dialog Stelle statt Solange nichts dar ber ausgesagt ist wie diese Stelle konkretisiert wird handelt es sich um einen abstrakten virtuellen Begriff Die abstrakte Stelle dient allerdings als Platzhalter f r eine konkretere Stelle Die abstrakten Stellen finden ihre Abbildung in konkreteren Stellen auf dem Wege der 31 3 Einf hrung in ein allgemeines Grundmodell f r Dialogstatik und Dynamik Implementierung bzw Realisierung der Dialogoberfl che Sie k nnen in Zwischenstufen der Realisierung zun chst noch relativ virtuell sein wie z B die Menge der Widget Objekte innerhalb eines Programms oder aber konkret physikalisch erfassbar wie die Pixel am Bildschirm die Tasten einer Tastatur oder Frequenzbereiche eines Radiosenders Eine Stelle repr sentiert letztendlich wird abgebildet auf eine Ressource an der das Ereignis erfolgt bzw an der ein Ereignis erfolgen kann Stellen k nnen f r bestimmte Ereignisse ber einen bestimmten Zeitraum verf gbar gemacht reserviert ge ffnet sensitiv aktiviert werden Ebenso k nnen sie wieder unbrauchbar gesperrt geschlossen insensitiv deaktiviert werden Mit einem Ereignis an einer Stelle ist die Darstellung einer Informationseinheit an eben dieser Stelle verbunden siehe unten Dialogwert An der Stelle wird bei Eintreten des Ereignisses die Information bergeben bzw abgeholt Der landl ufige Sprachgebrauch verbindet mit dem Begriff Stelle auch die Einordnung eine
133. die Nachteile beim Einsatz derartiger Systeme zumindest was den aktuellen Leistungsstand der Tools betrifft Die Nachteile werden insbesondere dann sichtbar wenn die Komplexit t der Anwendung steigt bzw dynamische Aspekte eine verst rkte Rolle spielen WYSIWYG nur f r statische Komponenten Die einfache Erstellung der Dialoge in WYSIWYG Manier kann im Allgemeinen nur f r a priori in Struktur und Inhalt festliegende Dialogobjekte durchgef hrt werden Dies schr nkt die Anwendbarkeit der Tools gerade da stark ein wo eigentlich ihr entscheidender Vorteil erwartet wird Rudiment re unvollst ndige Darstellung der Dynamik Nur in wenigen Werkzeugen und dann nur rudiment r ist eine Darstellung der Dialogdynamik mittels deskriptiver und oder grafischer Sprachelemente bisher unterst tzt In vielen F llen muss zur Darstellung der Dynamik auf eine Skriptsprache oder allgemeine Programmiersprache zur ckgegriffen werden Fehlende Gesamtsicht des Makrodialogs der Dialogstruktur Weder der Benutzer des Systems noch der Entwickler erhalten insbesondere eine Gesamtsicht auf die Struktur des Dialogs Allerdings kann der Ablauf meist sehr schnell simuliert werden Keine abstrahierende logische Darstellung Rapid Development Tools sehen keine M glichkeit einer abstrakten von der konkreten Implementierung losgel sten Darstellung des Dialogs Verfr hte Festlegung auf konkrete Objekte Der Entwickler ist gezwungen sich sofort auf ein
134. dlich festgelegt sind F r die Variation der Anzahl eines Exemplares Aspekt Cardinality beispielsweise sind zwei Funktionen vorgesehen die im generierten Code zum Zeitpunkt der Variation zur Bestimmung der Anzahl und zur damit implizit verbundenen Bestimmung der Identit t der einzelnen Instanzen aufgerufen werden int getCardinality String variationName String locationName Event e String getObjectld int index String variationName String locationName Event e getCardinality liefert die Anzahl der Instanzen und getObjectld liefert zum jeweiligen Index einen String der als eindeutiger Identifikator einer Instanz dient Dabei wird angenommen dass die Instanzen mittels Index durchnumeriert sind Der Parameter locationName ist der Name einer Exemplarstelle die variiert wird Der vom Codegenerator erzeugte Code sorgt f r einen Aufruf der oben beschriebenen Methoden immer dann wenn Information ber die Anzahl und die Identit t der variierten Exemplarstellen ben tigt wird D h dass die Methoden nicht nur beim Kreieren der Instanzen sondern auch zu sp teren Zeitpunkten z B bei Wert bertragungen oder Variation anderer Aspekte als die der Kardinalit t oder Identit t genutzt werden um die Menge der angesprochenen Instanzen zu bestimmen Was die Variation der Aspekte Kardinalit t und Identit t betrifft weicht hier die Implementierung im Prototypen von der Beschreibung in Kap 7 und der formalen Darstellung insofern ab als die Variat
135. dnung in den Kontext wird ebenfalls durch ein Labelwidget mit entsprechendem F hrungstext dargestellt Ein Labelwidget kombiniert mit einem leeren Textwidget entspricht im Wesentlichen der Darstellung einer Stelle in unserem Modellgrafen wenn die Stelle ohne konkreten Wert aber mit ihrer Stellenbezeichnung dargestellt ist Bei einer Implementierung einer Modellstelle durch eben diese Kombination von Label und Textwidget ist die Darstellung der Modellstelle also nahezu identisch mit der Darstellung zur Laufzeit Abbildung 6 1 Eingabestelle im Modell links und Implementierung durch Label und Textwidget mit Java rechts Eine hnliche bereinstimmung mit der Darstellung im Modell gilt z B f r PushButtons Auch hier ist das Wesentliche in der Darstellung des Pushbuttons die grafisch abgehobene Schaltfl che die mit dem Text versehen ist der die Bedeutung der Bet tigung des Buttons beschreibt Bei Text Label und Pushbutton Widgets kommt die abstrakte Modelldarstellung der konkreten Darstellung nicht zuletzt deshalb so nahe weil die Widgets selbst bereits einen hohen Grad an Abstraktion der Darstellung per se bieten Die Beschreibung einer Aussage in 102 6 0 hnlichkeit von Stellendarstellung und Widgets Form eines pr gnanten Begriffes einer nat rlichen Sprache in textueller Form stellt bereits eine Abstraktion dar die im Modell kaum bertroffen werden muss berhaupt sind Widgets in der Regel ber ein ggf umrandetes Fl
136. e Darstellung der in Kap 5 beschriebenen Form Dabei wurde auf die Annotation von Wertebereichen und Ereignistypen verzichtet Es kann f r alle Stellen der Ereignistyp M Schreibereignis an unsichtbarer Speicherstelle angenommen werden Als Wertebereich gilt f r alle Stellen die Menge der nat rlichen Zahlen gt 0 N Die Kantenannotationen c n gt 1 und e n 1 definieren die Bedingung des jeweiligen bergangs Die grau dargestellten Stellen n mlich die innere Stelle Fac sowie die Stellen Mult und Subl sind Teilsichten deren vollst ndige Definition anderswo ausgearbeitet ist Fac 168 Anhang A Rekursive Modellierung der Fakult tsfunktion in einem ESD als bergeordnete Stelle im selben Diagramm Die Substellen dieser Stellen werden nur dargestellt soweit sie als Anschl sse von und nach au en dienen In der zweiten Abbildung ist die grafische Form weiter vereinfacht um die bersichtlichkeit zu steigern Dabei wurde auf die Angabe der Propagationsfunktion die hier standardgem als Gleichheitsfunktion angenommen wird verzichtet Die gelben Kanten beschreiben eine Wert bertragung Die gr nen Kanten triggern ein Ereignis an der Eingangsstelle aufgrund eines Ereignisses an der Ausgangsstelle bzw triggern eine Wert bertragung Die von der Stelle n der inneren Stelle Fac ausgehenden drei gr nen Triggerkanten sind hier zu einer sich verzweigenden Kante zusammengefasst Die Kanten in Orange stellen eine Kombina
137. e e alle im Bild nicht mehr vorkommenden Widgets des Vorg ngerbildes ffne alle Widgets aller aktuellen Folgeglieder falls nicht bereits geschehen und erm gliche damit die potentiellen Eingaben aller aktuellen Folgeglieder Warte auf Eingabe Sobald Eingabe erfolgt l sche Aktivmarkierung aller aktiven Folgen mit alternativen Eingaben im aktuellen Folgeglied Speichere Identifikator der aktuellen Modellstelle der noch aktiven Folgen und aktuellen Eingabewert Kommentar Speichern dient zum Festhalten der Historie f r sp tere Entscheidungen durch Applikationslogik Andernfalls Fehler Kommentar Ein Mischfall n mlich dass in einer Situation aktive Folgen im aktuellen Folgeglied Eingaben und Ausgaben ausweisen sei nicht erlaubt Dies impliziert eine Einschr nkung in der Darstellung Die Folgeglieder einer Verzweigung des Dialogs im Sinne einer Baumdarstellung d rfen nur ausschlie lich Eingaben oder ausschlie lich Ausgaben ausweisen Erh he aktuellen Gliedindex um 1 3 Falls Anzahl der aktuellen Folgeglieder der aktiven Folgen 0 Programmende Andernfalls Falls Anzahl der aktuellen Folgenglieder kleiner als vor dem Hochz hlen Kommentar Eine der alternativen Folgen ist dann zu Ende Frage Applikationslogik ob Programm zu Ende Falls ja Ende Andernfalls Fahre fort mit 2 Andernfalls Fahre fort mit 2 Voraussetzung f r das Funktionieren des obigen Algorithmus ist dass in bestimmten Situationen die Applikationslogik um ei
138. e Implementierung eines Werkzeuges f r die Modellierung von Dialogsystemen mit Hilfe des Ereignisstellenmodells und der Darstellung in Ereignisstellendiagrammen Er umfasst im Wesentlichen eine Komponente zum Editieren von Ereignisstellendiagrammen Modelleditor und eine damit gekoppelte Komponente zur Generierung des aus einem Modell resultierenden Programmcodes Codegenerator Die wichtigsten Ziele des Prototyps sind und waren der Nachweis des praktischen Einsatzes von ESD s in der Modellierung bis hin zur automatischen Codegenerierung Der Prototyp erlaubt damit die Darstellung aller wesentlichen Sprachelemente von Ereignisstellendiagrammen und ihre automatische Umsetzung in ablauff higen Programmcode Um den Nachweis f r die Realisierung auch relativ komplexer realistischer Anwendungen zu erbringen wurde und wird der Prototyp im konkreten Projektumfeld des Autors eingesetzt die Gewinnung von Erfahrung im konkreten praktischen Einsatz hinsichtlich der Gestaltung und Erfordernis der Sprachelemente des Modells Insbesondere sollten damit auch gegebenenfalls Widerspr che und etwaige Defizite in der Modellsprache aufgedeckt werden Die Priorit ten im praktischen Einsatz bez glich erforderlicher Leistungsmerkmale an Modellierungssysteme sollten in Erg nzung zu bereits vorliegenden Erfahrungen erarbeitet bzw berpr ft werden Experimentell sollten verschiedene Varianten der Umsetzung des Modells verifiziert werden 10 0 0 Kernfunktion
139. e Widgetgr e dynamisch berechnet werden soll Dies und die Art der Layoutberechnung kann nun wiederum ber Attribute gesteuert werden Layoutmanagerzuordnung in Visual Cafe f r Java Constraints in Motif ber die Zuordnung eines Models Model View Conroller Konzept MVC Konzept kann z B auch der Inhalt eines Widgets etwa die Anzahl der Eintr ge einer Liste dynamisch gesteuert werden Ein dem MVC Konzept zugeordneter definierter Eventing Mechanismus sorgt dann automatisch daf r dass etwa bei nderungen des Models das Widget als View Objekt benachrichtigt und aktualisiert wird Generell gibt es eine Reihe von Attributen ber die das dynamische Verhalten von Dialog objekten bei Eintreten bestimmter Ereignisse gesteuert werden kann Z B auch Bewegung des Vollbilds oder Bewegung nur eines Schattenrahmens etc Die eigene Erstellung von Programmcode ist dabei in der Regel nicht erforderlich da entweder das Entwicklungssystem die Interpretation der Attribute und die Umsetzung in entsprechenden Code bernimmt oder die Interpretation der Attribute bereits in den jeweiligen Klassen der Dialogobjekte implementiert ist Auch in HTML basierten Systemen kann Dialogdynamik ber Attribute definiert werden die den Tags mitgegeben werden Abbildung 1 2 n chste Seite zeigt im System Dreamweaver die Definition eines Hyperlinks der bewirkt dass bei Mausklick auf das Feld See Details eine HTML Seite namens index htm ge ffnet wird
140. eben Danach besprechen wir speziell M glichkeiten der redundanzfreien Darstellung hierarchischer Stellen und darauf folgend ein einfaches Konzept das eine Zusammenf hrung von Teilsichten zu einem Gesamtmodell erm glichen soll 5 3 2 1 Ausblenden von Teilstellen In einem ESD das dann eine Teilsicht repr sentiert k nnen alle oder einige direkte Teilstellen einer Dialogstelle weggelassen werden Grafisch wird dies durch drei waagrecht angeordnete Punkte im Rechteck der Stelle visualisiert Dies f hrt dazu dass eventuell von diesen Teilstellen ausgehende oder hinf hrende Kanten ebenfalls unsichtbar sind Mit dem Weglassen einer direkten Teilstelle sind im Normalfall auch alle deren Teilstellen im Sinne der transitiven H lle nicht dargestellt Allerdings ist es auch m glich indirekte Teilstellen dennoch in der Sicht darzustellen also nur bestimmte im Sinne der Hierarchie zwischengelagerte Teilstellen auszulassen Eine Teilstelle deren bergeordnete Stelle n in der Darstellung fehlt fehlen wird gesondert gekennzeichnet Dies kann dadurch geschehen dass eine gestrichelte Linie von links oben an das Rechteck herangef hrt wird siehe Abbildung 5 7 oder und dass dem Bezeichner der Stelle drei Punkte vorangestellt werden Wir nennen derartige Stellen in einem Diagramm Jokerstellen Jokerstellen haben keine eindeutige hierarchische Einordnung Sie dienen als Vorlage f r andere Stellen und f hren bei Implementierung des Modells zu keiner eig
141. ebenen mittels Subdiagrammen siehe z B komplexe Stellen bei Dialognetzen JANSS96 5 3 2 3 Gegenseitige Erg nzung von Stellen Erscheint dieselbe Teilstelle in unterschiedlichen Sichten kann die Darstellung dieser Teilstelle in einigen oder in allen Sichten unvollst ndig sein Die verschiedenen Darstellungen der Teilstelle erg nzen sich dann gegenseitig Dies wird wiederum durch das Drei Punkte Symbol gekennzeichnet Wir legen fest dass die unvollst ndigen Darstellungen im Rechteck drei Punkte enthalten Au erdem gehen wir davon aus dass die Teilstellen ohne drei Punkte die vollst ndige Darstellung der Teilstelle zeigen Dass es sich um dieselbe Teilstelle in den unterschiedlichen Sichten handelt erkennen wir dabei am identischen Stellenbezeichner und derselben hierarchischen Einordnung Die Erg nzung einer unvollst ndigen Stelle durch eine Jokerstelle ist nur ein Spezialfall mit einer Erweiterung des Konzeptes dass sich Stellen in verschiedenen Sichten wechselseitig oder in einer Richtung erg nzen k nnen Die Erweiterung besteht lediglich darin dass eine Jokerstelle mehrere Stellen fester hierarchischer Einordnung vertritt bzw erg nzt 5 3 2 4 Zusammenf hrung der Teilsichten Wir wollen dem Benutzer des Modellsystems erlauben in verschiedenen zun chst voneinander unabh ngigen Teilen das Modell zu entwerfen Diese unabh ngigen Teilmodelle sollen dann zu einem konsistenten Gesamtmodell zusammengef hrt werden so dass wir d
142. echenden Pr fungen durch das System sind zun chst in unserem Modell nicht dargestellt da sie an der Dialogoberfl che nur durch die nach der Pr fung erfolgende Reaktion des Systems festgestellt werden kann Das Ziel der Darstellung in unserem Modell ist zun chst nur die Darstellung der Oberfl che Aus nicht im Modell dargestellten Ursachen erfolgt nach der Eingabe der Geheimzahl eine Verzweigung in alternative Dialogstellen n mlich in eine Stelle mit Fehlermeldung die eine nicht erlaubte Eingabe anzeigt oder aber in eine Stelle die eine erfolgreiche Fortsetzung des Dialogs repr sentiert Wir wissen dass die unterschiedliche Fortsetzung jeweils von unterschiedlichen Eingabewerten an der Eingabestell abh ngt Um diesen Sachverhalt im Modell ausdr cken zu k nnen ben tigen wir wiederum wie im Falle der Zusammenlegung identischer Teilfolgen ein Sprachmittel das ber die Darstellung im bisherigen Grafen hinausgeht Die Zusammenfassung von Stellen mit alternativen Werten zu einer Stelle f hrt selbstver st ndlich ebenfalls wie die Zusammenlegung identischer Teilfolgen zu einem Verlust der Information im Grafen Wir k nnen aus der Stelle selbst keinen eindeutigen Verlauf des Dialogs hinsichtlich der eingegeben Werte und damit der erfolgten Dialogereignisse mehr feststellen Wollten wir dies alleine mit den Sprachmitteln des Grafen also mit Knoten Stellen und Kanten erreichen m ssten wir wie vor der Zusammenfassung jeden der m gli ch
143. efinition S Zu ffnende Stellen S Voraussetzung f r das ffnen einer Stelle s ist dass die Stelle s an der das Ereignis stattfindet ber RO in Beziehung steht Es m ssen jedoch noch weitere Bedingungen erf llt sein die zu einer weiteren Einschr nkung der berg nge s nach s in RO f hren Wir definieren also S respektive RO s e F e s s RO s s e RO und Ereignis e muss aus der Menge der ausl senden Ereignisse stammen die dem bergang s s zum Offnen zugeordnet ist also e ERO S S und Die dem potentiellen bergang s s aus RO zugeordnete Condition muss bei der aktuell g ltigen Wertebelegung ws den Wert TRUE liefern c Oat TRUE mit c Kro sROs und Oakt OS Sc wobei sjs die aktuelle Wertezuordnung os eingeschr nkt auf die f r c definierte Stellenmenge Se Ende Definition S RO mit aktuellen berg ngen s s zum ffnen s und 2 Definition S Zu schlie ende Stellen S hnlich zu 1 muss nun ein potentieller bergang s s aus RC existieren der auch noch weitere Bedingungen erf llt Definition S respektive RC s S s s e RC amp s s e RC und e erc s s und 80 5 0 Formale Darstellung C ak TRUE mit c rc sRCs und akt OSise wobei sjs die aktuelle Wertezuordnung s eingeschr nkt auf die f r c definierte Stellenmenge Se Ende Definitio
144. egenden Arbeit bereits hinreichend erw hnt und wie auch durch das obige Beispiel und die Ausf hrungen von Lin Thomsen und Landay belegt ist die Darstellung der Dynamik in Form einfacher berg nge von Bild zu Bild bzw von Zustand zu Zustand in vielen F llen zu aufwendig und un bersichtlich weshalb f r Sketchingsysteme nun nach Mitteln zu einer intensiveren Darstellung gesucht wird Abbildung 9 10 zeigt nun in Fortf hrung des Beispiels eine alternative intensivere Darstellung in einem Ereignisstellendiagramm Checkout Shopping Cart Order List Socks 9 99 Tennis Racquet 37 00 Tank Top 16 20 gt Giftwyrap C CardOnly amp CWrapOnlyg gt GiftCard C CardAndWrapo Abbildung 9 10 Ereignisstellendiagramm mit intensivierter Darstellung der Checkout Seite im Shoppingsystem Anstelle der extensiven expliziten Darstellung der Zust nde die durch die Mausklicks auf die Buttons zur Auswahl von Geschenkverpackung und Begleitkarte erreicht werden k nnen wird jetzt nur eine Stelle gezeigt und die berg nge mittels geeigneter Conditions gesteuert 149 10 Realisierung im Prototyp 10 Realisierung im Prototyp Begleitend zu den in den vorangegangenen Kapiteln gemachten Ausf hrungen wurde ein Prototyp in Form eines Programmsystems erstellt der in diesem Kapitel in seinen wesentlichen Merkmalen beschrieben wird 10 0 Zielsetzung und Rahmenbedingungen Der Prototyp ist die beispielhaft
145. egt in dem klaren Konzept und der M glichkeit einer intuitiv eing ngigen grafischen Darstellung Durch die Erweiterungen in den Modellen wird die M chtigkeit signifikant gesteigert Dabei nimmt der Anteil der Grafik jedoch ab und die Darstellung verlagert sich immer mehr hin zur textuellen Notation Der Anwender ist gezwungen eine eigene Modellsprache zu erlernen die zun chst nicht mehr sofort einsichtig ist Ein Kernproblem bei der Darstellung von Zust nden und berg ngen ist dass schon bei nicht allzu komplexen Anwendungen die Anzahl der Zust nde und die Anzahl der berg nge extrem ansteigt Dies wirkt sich ganz besonders negativ aus wenn nebenl ufige Vorg nge beschrieben werden sollen Im Kapitel 9 werden wir auf zwei herausragende Ans tze n her eingehen die das Problem der Nebenl ufigkeit in Zustands bergangsdiagrammen adressieren n mlich das Koroutinenkonzept von Jacob JACOB86 und die State Charts HAREL87 OESTER97 wobei letztere ihren Eingang in die Unified Modelling Language UML f r objektorientierte Modellierung und Design gefunden haben Es sei jedoch bereits hier angemerkt dass beide Modelle f r eine benutzergerechte und auch entwicklergerechte Modellierung von grafischen Dialogsystemen nur bedingt tauglich sind Bei Jacobs Koroutinen Konzept geht der Vorteil der grafischen Darstellung verloren und State Charts sind wenn auch eine grafische Darstellung paralleler Zust nde m glich ist zu sehr der Zustandssicht
146. egt schon daran dass neue Stellen in unser System eingef hrt werden Bei Eintreten eines Ereignisses das die Berechnung einer Variation ausl st k nnen ggf zus tzlich Stellen zu ffnen RO oder zu schlie en RC sein Die Stellen von denen aus Stellen berg nge erfolgen k nnen sich ndern Die hierarchische Struktur HS der Teilstellen kann variieren Mit neuen Stellen berg ngen gibt es auch neue Mengen ausl sender Ereignisse und damit ge nderte Zuordnungen ero ERC Prinzipiell wollen wir auch erlauben dass die Menge der akzeptierten Ereignisse einer Stelle dynamisch bestimmt werden kann sowie die Menge der einen bergang ausl senden Ereignisse die ber gro erc zugeordnet werden Ebenso ndern k nnen sich die Zuordnungen von Conditions zu Stellen berg ngen KRO und KRC sowie die von Propagationsfunktionen TRO Dies liegt ebenfalls schon daran dass neue Stellen berg nge definiert werden denen entsprechende Conditions und Propagationsfunktionen zuzuordnen sind Schlie lich ist Start der ggf ge nderten Stellenmenge anzupassen Vars sei nun die Menge der Variationen oder Variationsvorschriften var Vars mit var VarEvents VarS VarAspects varType varFunc VarEvents Menge der Ereignisse VarEvents c SUniv T amp W VarS Menge der Variationsstellen als Gegenst nde der Variation VarS lt SUniv VarAspects Menge der zu variierenden Aspekte VarAspects lt Aspects wobei Aspects Card Id PS Va
147. ehen wir unter asynchronen Ereignissen diejenigen Ereignisse deren Zeitpunkt der Darstellung aus Sicht der Steuerung der Dialogkomponente des Systems nicht von vorneherein vorherbe stimmt werden kann Besitzt das Ereignis ein definiertes Vorg ngerereignis so tritt es zeitlich versetzt zu einem unbestimmten Zeitpunkt und nicht unbedingt unmittelbar danach auf Das asynchrone Ereig nis kann allerdings auch eines oder mehrere Nachfolgeereignisse besitzen Die Existenz von Vorg nger und Nachfolgerereignissen legt es nahe ggf von teilsynchronisierten Ereignissen zu sprechen da in gewissem Sinne eine zeitliche Einordnung Synchronisation des Ereignis ses doch erfolgt Siehe Diskussion des Begriffs asynchron im Anhang Das Eintreten eines asynchronen Ereignisses und damit auch seine Darstellung an der Dialogschnittstelle wird im Allgemeinen extern also von einer Komponente oder Instanz au erhalb der Dialogkomponente gesteuert In der Regel k nnen wir nur einen mehr oder weniger langen Zeitraum bzw Zustand im Dialogsystem angeben in dem wir ein asynchro nes Ereignis erwarten Dieser Zeitraum ist durch Vorg nger und Nachfolgeereignisse eingegrenzt Asynchrone Ausgabeereignisse Ausgabeereignisse k nnen also wenn das in Dialogsystemen auch nicht die berwiegende Mehrheit sein mag asynchron gesteuert sein Asynchrone Ausgabeereignisse gehen ohne Beschr nkung der Allgemeinheit von der Applikationslogik Komponente des Systems aus Async
148. ehrstuhl stets u erst herzlich und hilfreich berbr ckte Ebenfalls herzlichen Dank an die Herren Professoren Endres und Struss ber die der Kontakt zum Lehrstuhl zustande kam Mein freundschaftlicher Dank geht an meine Kollegen Theo Bodensteiner Eberhard Dittmar Brian Hill und Dirk Nasri Roudsari die mir ber die lange Zeit sowohl moralisch als auch inhaltlich mit einer Reihe von Anmerkungen und Tipps zur Seite standen Nicht zuletzt aber danke ich vor allem meiner Familie ganz besonders meiner Frau Marianne und meinen Kindern Ohne ihre Aufmunterung Unterst tzung und den wie ich doch annehme allen schwerfallenden Verzicht auf gemeinsam verbrachte Zeit w re die Arbeit nicht entstanden Ursensollen 31 Dezember 2003 Inhaltsverzeichnis 0 1 Abbildungsverzeichnis 8 Einf hrung 10 0 0 Allgemeine Problemstellung 10 0 1 Zielsetzung der Arbeit 12 0 2 Kapitel bersicht 13 G ngige Ans tze der Realisierung von Dialogsystemen 14 1 0 Einsatz von Systemen zum Rapid Development 14 1 0 0 WYSIWYG Darstellung statischer Dialogkomponenten 14 1 0 1 Darstellung der Dynamik 15 1 0 1 0 Dynamik in vorgefertigten Komponenten 15 1 0 1 1 Attributgesteuerte Dynamik 16 1 0 1 2 Ereignisgesteuerte Routinen 17 1 0 1 3 Wizards zur Codegenerierung 17 1 0 1 4 Grafische Ans tze 18 1 0 2 Vorteile 18 1 0 3 Na
149. eiben geschehen ein sich ffnendes Widget wird einfach direkt am Bildschirm an die gew nschte Stelle hinge malt etc Der Editor speichert in einem Aufzeichnungsmodus bei Durchf hrung der Kom mandos nicht nur die statische Information der Widgets sondern auch den Ablauf der einzel nen Dialogschritte Vorteile Der Modellierer kann bereits unmittelbar in der Definitionsphase Schritt f r Schritt exakt das Aussehen und Verhalten der Oberfl che verifizieren Er arbeitet mit primitiven berschaubaren Operationen die den Ablauf Schritt f r Schritt vorantreiben also ohne komplexe Logik Nachteile siehe unten Ansatz 2 Explizite statisch r umliche Darstellung der Dialogdynamik bzw generell der Dialogereignisse r umlich extensiv explizit extensional Anstelle der zeitgetreuen Darstellung k nnen wir im Modell eine statische Darstellung w hlen D h wir bilden das Zeitverhalten die Dynamik statisch ab Dies geschieht beispielsweise dadurch dass wir eine Zeichenfl che nutzen und dort unsere Dialog Ereignisse verteilt an aufeinander folgenden Stellen aufzeichnen Wir zeichnen eine Bilderfolge mit den konkreten Ereignissen auf die Fl che Auf diese Weise gewinnen wir eine nach wie vor mit Ausnahme des Echtzeitverhaltens konkrete Darstellung Der Vorteil der statischen Darstellung ist dass der Betrachter auf einen Blick eine Folge oder Teilfolge des Dialogs berschauen kann Ihm wird keine zeitliche Reihenfol
150. eich der Stelle bezeichnen Wir haben also etwas formaler betrachtet eine Funktion die jeder Stelle eine Menge von Werten ihren so genannten Wertebereich zuordnet Diese ist h ufig definiert als die Funktion die die Stelle auf die Menge aller Werte aller m glichen Eingabeereignisse an der Stelle abbildet Wie bereits bei der Darstellung des Grundmodells erw hnt muss jedoch der Wert einer Stelle nach Eintreten eines Ereignisses an der Stelle nicht unbedingt mit dem Wert dieses Ereignis ses bereinstimmen Somit kann beim Zusammenfassen von Stellen der Wertebereich der zu sammengefassten Stelle sich auch von der Wertemenge unterscheiden die durch die Ereignis se an der Stelle definiert ist 49 4 Bottom up Modellierung und Abstraktion Bankautomat Bitte Karte einschieben Bitte Geheimzahl eingeben eheimzahl OK Abheben Betrag oder Geheimzahl falsch Einsehen Kontostand Bitte Betrag w hlen Ausgabe Kontostand 50 100 200 300 Euro oder Betrag abheben anderen Betrag System schiebt Karte aus Bitte Karte entnehmen vielen Dank f r Ihren Besuch Abbildung 4 7 Graf zur Darstellung des Dialogablaufs eines Bankautomaten ohne Zyklen Die Knoten des Grafen hier als Rechtecke dargestellt sind mit Ereignistypen I Input O Output annotiert Die in Orange hinterlegten Knoten repr sentieren Eingabestellen denen ein Wertebereich zugeordnet werden muss der die m glichen Werte der Eingabeereignisse festlegt Alle a
151. eichner besitzt und deren hierarchische Einordnung mit der hierarchischen 98 5 3 Grafische Darstellung Einordnung der Jokerstelle vereinbar ist Als weitere Voraussetzung gilt dass die Aufrufstelle mit drei Punkten gekennzeichnet ist sie also unvollst ndig definiert ist Die hierarchische Einordnung ist genau dann zwischen der Stelle und der Jokerstelle vereinbar wenn die hierarchisch bergeordneten Stellen der Jokerstelle im Hierarchiepfad der anderen Stelle enthalten und gleich geordnet sind Auf diese Weise kann eine Jokerstelle ihre Information an mehrere Stellen bertragen Besitzt die Jokerstelle wie gerade oben angef hrt in der Teilsicht in der sie aufgef hrt ist keine bergeordnete Stelle au er dem Gesamtdialog bertr gt sie Information an alle gleichnamigen unvollst ndigen Aufrufstellen ungeachtet deren hierarchischer Einordnung Gerade wenn im Modell mehrere Stellen auftreten die sich in ihrer inneren Struktur d h in den Teilstellen und deren Relationen zueinander gleichen besteht das Interesse diese innere Struktur nicht mehrfach redundant definieren zu m ssen Subdiagramme als spezielle Teilsichten Wird eine zusammengesetzte Stelle in einem Diagramm ohne innere Teilstellen dargestellt und werden in zus tzlichen eigenen Diagrammen wiederum rekursiv jeweils lediglich die unmittelbaren Teilstellen beschrieben handelt es sich im Wesentlichen um die bekannte Technik der Darstellung einzelner Hierarchie
152. eignisse wahrgenommen werden k nnen Mit Stellen k nnen Stellen in einem rtlichen wie in einem zeitlichen Raum verstanden werden Allerdings sieht das dem ESD standardm ig zugeordnete Implementierungskonzept vor dass wie oben erw hnt Stellen auf Objektinstanzen bzw Attribute von Objektinstanzen abgebildet werden Dieser Default Abbildungsmechanismus erm glicht dann eine rasche direkte Umsetzung in die Implementierung Wird die WYSIWYG Darstellung im Modell gew hlt ist die Abbil dung der Stelle auf ein konkretes Widget bereits unmittelbar vorgegeben 9 1 Ereignismodell von Green Die modelltheoretische Basis g ngiger auf dem Markt befindlicher Systeme zur Realisierung von grafischen Dialogoberfl chen ist in der Regel ein Ereignismodell Green stellt ein abstraktes Ereignismodell vor Er betont dabei dass in der Praxis das Modell in eine Programmiersprache eingebettet ist die dem Modell entsprechende M chtigkeit verleiht Merkmale des Ereignismodells Im Vordergrund stehen Ereignisse und damit verbunden so genannte Event Handler Ein Ereignis ist ein Tripel aus Name des Event Handlers an dem das Ereignis entgegengenommen wird Name des Ereignisses und Wert des Ereignisses In der Praxis stellen f r Green Event Handler Routinen einer Programmiersprache dar Im abstrakten Modell sind jedem Event Handler eine Reihe von Registern zugeordnet die Ereigniswerte oder Namen von Event Handlern speichern k nnen Ein Event Handler kan
153. eise Verz gerungen im Ablauf zu vermeiden muss sp testens dann die Information verf gbar sein wenn ein Dialogpartner f r die Durchf hrung seiner Aufgabe diese ben tigt Es ist dann prim r nicht entscheidend wann die Information von einem Kommunikationspartner an der Schnittstelle zur Verf gung gestellt wurde sondern nur entscheidend dass sie dann verf gbar ist wenn die die Information abnehmende Komponente die Information braucht Entscheidend ist also in diesem Fall nicht der Zeitpunkt der Eingabe sondern der der notwendigen Abnahme der Information Benutzer Dialogschicht DialogTask1 DialogTask2 Eingeben Daten f r Task2 1 Eingeben Date f r Task1 Starten Task1 Abbildung 4 10 Entkoppelung von Eingabe der Daten und Durchf hrung der Aufgabe Das Sequenzdiagramm zeigt ein Szenario in dem mithilfe der Trennung von Dialog und Applikationslogik der Eingabedialog f r die Durchf hrung der Aufgabe Task2 Schritt 1 vor dem Eingabedialog f r Aufgabe Task1 Schritt 2 erfolgen kann obwohl aufgabenlogisch Task2 Schritt 4 von Taskl Schritt 3 abh ngt Nehmen wir zwei Arbeitsschritte Al und A2 an denen jeweils Eingabedialoge E Al und E A2 sowie Ausgabedialoge A A1 und A A2 zugeordnet sind Beispiell Al ist vor A2 logisch notwendig Daraus folgt nicht automatisch dass E Al vor E A2 erfolgen muss Die Eingabe f r Al kann auch nach der f r A2 erfolgen falls nicht 62 4 2 Logische Abstrakt
154. eitere Variationen ergeben sich bei nderung der Anzahl allerdings auf der Ebene der zugeordneten konkreten Laufzeitinstanzen Wenn wir etwa als Laufzeitinstanz ein Widget zuordnen m ssen wir auch die Position variieren zumindest falls die Kardinalit t gr er 1 Ist Im Folgenden sollen die im Beispiel definierten drei Variationen besprochen werden Sie sind im Modell in Fu notendarstellung definiert und ber die entsprechenden Sternsymbole mit den zugeh rigen Objekten oder Exemplaren der Variation verkn pft Variation JobStepVariation Die Variation mit Namen JobStepVariation hat als Exemplare oder Objekte der Variation die beiden Ereignisstellen JobStepl und Jobstep2 Als Aspekte der Variation werden genannt Cardinality Identity Position und die Werte bestimmter Teilstellen definiert durch JobStepName value SourceStepl value und SourceStep2 value Als Zeitpunkt der Variation wird das Ausgabeereignis mit Wert Ready an der Stelle LoadingJob Ready genannt Dies bedeutet dass anstelle der beiden genannten Objekte nach Eintreffen dieses Ereignisses eine Menge von Objekten bestimmt wird die an die Stelle der beiden Exemplare im Modell treten und ge ffnet werden Dass die Anzahl der Objektmenge dynamisch bestimmt wird ist durch Angabe des Aspekts Cardinality erreicht Andernfalls bliebe die Anzahl der Exemplare fix bei zwei Mit der Anzahl der Objekte variiert notwendigerweise auch die Identit t der Objekte und f r jedes Objekt wir
155. ekursion 4 1 2 0 Zyklen Die Einf hrung von Zyklen Schleifen in unserem Graphen geschieht blicherweise indem wir einen Pfad an einer Stelle fortsetzen indem wir eine gerichtete Kante auf eine Stelle zur ckf hren die bereits im selben Pfad enthalten ist Mit der Bildung von Zyklen wird die bisherige Eigenschaft im Modell aufgegeben dass eine Stelle nur h chstens einmal erreicht wird Eine Stelle kann mehrmals durchlaufen werden d h eine Stelle repr sentiert im Sinne der konkreten Abfolge von Ereignissen nicht mehr nur genau ein potentielles Ereignis im Dialogablauf sondern mehrere potentielle konkrete Ereignisse Die Zyklenbildung f hrt also zu einer weiteren Art Zusammenfassung oder Abstraktion eines Ereignisses bzw einer Ereignisstelle die Identit t der Stelle an sich macht keine Unterscheidung mehr bez glich des eindeutigen Vorg ngerpfades m glich Der potentiell ab der Stelle nachfolgende Verlauf des Pfads ist unabh ngig von unterschiedlichen Vorg ngerpfaden Wollen wir den Folgepfad von der Vorgeschichte abh ngig machen insbesondere davon wie oft der Zyklus bereits durchlaufen wurde m ssen wir dies wiederum mit gesonderten Sprachmitteln bewerkstelligen etwa zum Test einer Abbruch Bedingung Das Einf hren von Zyklen bedeutet das wiederholte Aufrufen derselben Dialogsequenz desselben Teilgrafen aus einer unterschiedlichen Historie also im Sinne der durchlaufenen Historie aus unterschiedlichen Zus
156. ellen heraus angesprochen wird 4 1 0 Zusammenfassung von Werten Eine bliche Technik Stellen und berg nge zu reduzieren wird meist intuitiv in der Modellierung angewandt indem alternative Stellen also Stellen die von einer Stelle aus durch alternative berg nge erreicht werden k nnen zu einer Stelle mit unterschiedlichen 48 4 1 Reduktion von Stellen und Transitionen alternativen Wertebelegungen geb ndelt werden Es erfolgt dann im Modell nur mehr ein einziger bergang zu einer Stelle die als Wertebereich das ganze B ndel der einzelnen Werte der vormaligen Alternativstellen beinhaltet Beispiel Dialog zur Eingabe eines Datums Aus der Sicht der m glichen Eingaben eines Datumswertes gibt es sehr viele konkrete M glichkeiten eines Datumsdialogs die wir alle konkret im Modell hinmalen m ssten wenn wir sie durch primitive Dialoge mit konkreten Werten ausdr cken wollten n mlich f r jeden m glichen Wert eine Stelle mit entsprechenden berg ngen von den Ausgangsstellen und zu den Folgestellen Stattdessen stellen wir eine Dialogstelle dar die im Wertebereich alle m glichen Datumswerte beinhaltet Wir abstrahieren in diesem Fall also vom konkreten Wert was wiederum dazu f hrt dass wir an sp teren Stellen in der Folge unter Umst nden berg nge in Abh ngigkeit vom konkret eingegebenen Datumswert durch explizite Abfrage unterscheiden m ssen Durch die Abstraktion geht also zun chst im Modell Information verloren
157. ellen zugeordneten Ereignismengen einer zusammengesetzten Stelle bilden eine der Stelle zugeordnete zusammengesetzte Ereignismenge Wie gerade oben erw hnt k nnen Ereignisse als Teilereignisse zu einem zusammengesetzten Ereignis zusammengefasst werden So kann es Sinn machen alle in einem Dialog an einer Stelle stattfindenden Ereignisse wieder als ein dann zusammengesetztes Ereignis zu 33 3 Einf hrung in ein allgemeines Grundmodell f r Dialogstatik und Dynamik betrachten Ist diese Stelle Teilstelle einer anderen Stelle bilden dann wiederum die zusammengesetzten Ereignisse Teilereignisse eines zusammengesetzten Ereignisses der bergeordneten Stelle In diesem Sinne wird ber die Stellen und Teilstellen eine Hierarchie zusammengesetzter Ereignisse definiert Beispiel Die Eingabe eines Wortes in einem Formularfeld ergibt sich als zusammengesetztes Ereignis aus der Eingabe einer bestimmten Folge einzelner Buchstaben deren einzelne Eingaben wir als Teilereignisse im Formularfeld sehen k nnen Das Formularfeld sei dabei eine primitive Stelle die wir in unserem Modell nicht mehr weiter in Teilstellen aufteilen wollen Die Eingabe im Formular die sich aus der Eingabe der Worte in die einzelnen Formularfelder ergibt stellt nun wiederum ein zusammengesetztes Ereignis dar 3 0 3 1 Dialogfolge Ereignisse k nnen andere Ereignisse ausl sen oder Ereignisse k nnen andere Ereignisse erm glichen Ereignisse k nnen also entweder potentiell
158. ellierung von Dialog zwischen Mensch und Maschine in Betracht gezogen werden kann und n her untersucht werden muss Im Rahmen dieser Arbeit sollen nur einige wesentliche Charakteristika im Vergleich mit dem vorgestellten Ereignisstellenmodell angesprochen werden Eine ausf hrliche Beschreibung und Untersuchung kann und soll hier nicht vorgenommen werden Der Pi Kalk l baut auf einem vorangehend entwickelten Prozess Kalk l Calculus of Communicating Systems CCS MILNER80 auf Andere Beitr ge zum Thema Kommunikation konkurrierender Prozesse stammen z B von Hoare Communicating Sequential Processes HOARESS5 Der Pi Kalk l umfasst einige wenige Sprachkonstrukte mit denen so genannte Prozessaus dr cke P formuliert werden k nnen P m Pi P P2 newaP IP Ein Prozessausdruck setzt sich also aus Summation Komposition Restriktion oder Replikation zusammen Summation ni P Eine Summation z B in x y A out w z B stellt im Wesentlichen alternative Prozessabl ufe im Beispiel also die beiden Alternativen in x y A und out w z B dar Anstelle von in und out werden in der Darstellung bei Milner auch alternativ bei Eingaben in und bei Ausgaben out weggelassen und stattdessen Namen f r Ausgabeaktionen mit obenliegendem Querbalken versehen Dabei sind in x y bzw out w z sogenannte Aktions Pr fixe die den Prozesskomponenten A bzw B vorangestellt sind in x y bzw out w z sind Aktionen die durchgef hrt
159. ellung von Werten die in Argumentslots und Resultatslots unterschieden werden Die Hit Bausteine die die alternati ven Teilkomponenten eines Alternativenhits bilden besitzen die gleichen Argumentslots und Resultatslots wie der sie zusammenfassende Alternativen Hit so dass die Werte der Argu mentslots des Alternativen Hits an die ausgew hlte Teilkomponente weitergegeben werden k nnen bzw aus den Resultatsslots der ausgew hlten Teilkomponente an den Alternativen Hit zur ck bergeben werden k nnen Neben den Slots besitzt ein Alternativen Hit auch ggf so genannte Messageports als Argumente oder Resultate Im Wesentlichen unterscheiden sich Messageports von Slots dadurch dass sie so genannte Nachrichten aufnehmen k nnen und diese auch an andere Stellen weitergeben propagieren k nnen Messageports besitzen etwas informell gesagt einen mehr aktiven und Slots einen eher passiven Charakter Die Werte die beispielsweise in Slots oder Messageports gespeichert werden werden durch die Zuordnung ganz bestimmter so genannter Sorten zu den Slots bzw Messageports typisiert Eine entsprechende Sortierung gilt auch bez glich Werten anderer Hitelemente siehe unten Regeln Vorbedingungen etc Tupel Hits Ein Tupelhit besitzt eine u U auch leere Menge von Hits als Teilkomponenten sowie eine Menge von Regeln Neben Argument und Resultatslots hat ein Tupelhit au erdem so genannte lokale Slots Lokale Slots k nnen so genannte Eingabe oder Ausg
160. ement der Druckdialog ge ffnet wird Wir fordern dabei von unserem System dass es diese Implementierung nicht vornimmt wenn sie bereits erfolgt ist oder wenn das ge ffnete Dialogelement der Druckdialog selbst oder einer seiner Teilstellen ist Letzteres w re allerdings insofern nicht problematisch falls das ffnen einer bereits ge ffneten Stelle nichts bewirkt Als Variationstyp geben wir in diesem Beispiel inkrementelle Variation an Denn wir erhalten durch die Variationsfunktion pro Variation jeweils nur die Referenz einer Dialogstelle die mit dem Druckdialog in Beziehung gesetzt werden soll Alle anderen Referenzen auf bereits ge ffnete Stellen bleiben bestehen und die referenzierten Stellen behalten somit die M glichkeit des Druckdialogstarts bei F r dieses Beispiel k nnen wir zusammenfassen Die Information dass der Druckdialog per Tastenkombination an einer Dialogstelle ge ffnet werden kann wird im Modell exemplarisch grafisch festgehalten ffne Pfeil zwischen den beiden Dialogstellen Durch Hinzuf gen von Variationsinformation wird diese Funktionalit t auf alle Dialogobjekte durch das System automatisch erweitert Die im Beispiel gezeigte Art der Variation wollen wir als Anwendungsvariation bezeichnen die Anwendung bzw der Aufruf des Druckdialogs wird im Modell beispielhaft an einem Dialog gezeigt und variiert dann ber alle Dialogstellen Etwas formaler betrachtet wird ein Stellenpaar der Relation RO durch ei
161. en aber genau eine Instanz eines Fensters Ein Subnetz besitzt mitunter mehrere Start Transitionen so dass ein Subnetz an den entsprechenden komplexen Aufrufstellen unterschiedlich angesprungen werden kann Dynamischer Aufruf von Unterdialognetzen Um bei mehrmaligem bergang zu einer komplexen Stelle jeweils das Kreieren einer neuen Fensterinstanz zu bewirken werden komplexe Stellen mit einem Stern versehen 134 9 2 Dialognetze Makros Ein Dialognetz kann als so genanntes Makro als Muster f r mehrere verschiedene Unterdialognetze dienen Die unterschiedliche Verwendung ergibt sich aus dem Ersetzen von Platzhaltern des Makros in den Beschriftungen Bezeichnung in spitzen Klammern die durch die aktuellen Werte an den Aufrufstellen Werte in runden Klammern belegt werden Voll spezifiziertes Dialognetz Ein voll spezifiziertes Dialognetz zeichnet sich durch Beschriftungen an den Stellen und Kanten aus Es sind dies im Wesentlichen in den Stellen Aktionen die beim ffnen der Stelle bzw beim Schlie en der Stelle ausgef hrt werden sowie in den Transitionen ein Tripel das aus Ereignis Bedingung und Aktion besteht Die Transition wird ber Ereignis und Bedingung zus tzlich zu den brigen Schaltregeln gesteuert Die Aktion der Transition wird ggf nach der Schlie e Aktion der Eingangsstellen und vor den ffne Aktionen der Ausgangsstellen durchgef hrt Spezifikation des Makrodialogs Ziel der Darstellung mit Dialognetzen
162. en die er durch eine Beschreibung der Variation dieser Elemente zu einer vollst ndigen Darstellung der allge meinen Programmlogik erweitert Die Beschreibungsm glichkeit der dynamischen Variation von Ereignissen bzw Stellen durch Einf hrung von Variationsnotationen an der Modellstelle steigern den praktischen Nutzen der Modelldarstellung hnliche Ans tze finden wir in constraint basierten Systemen und Systemen zum Programming by Demonstration z B VANDER9S5 MYERS88 12 0 1 Zielsetzung der Arbeit Eine Implementierung des grafischen Dialogs aus dem Modell heraus ist im Sinne von Rapid Development auf sehr kurzem Weg auf Wunsch weitestgehend automatisch machbar 0 2 Kapitel bersicht In Kapitel 1 werden drei g ngige methodische Ans tze der Realisierung von Dialogsystemen n mlich der Einsatz von Systemen zum Rapid Development Rapid Prototyping die Nutzung abstrakter Modellsysteme sowie die direkte Programmierung im berblick diskutiert und deren wesentliche Vor und Nachteile besprochen Kapitel 2 stellt die Kernziele des zu erarbeitenden integrierten Ansatzes vor der eine logische Dialogmodellierung unter Einbeziehung der Dialogdynamik und einer WYSIWYG orientierten Darstellung erlaubt Kapitel 3 schafft die Grundlage zur Erarbeitung des integrierten Ansatzes mit der Einf hrung eines einfachen allgemeinen Modells Grundmodells zum Verst ndnis von Dialog das als Ausgangspunkt f r die zu erarbeitende Modellspr
163. en Eingabewerte durch einen Knoten eine Stelle repr sentieren Um den Verlauf des Dialogs mithilfe unseres Modells auch nach Zusammenfassung von Stel len alternativer Wertebelegungen steuern zu k nnen verwenden wir wieder als Sprachmittel die oben bereits erw hnte Condition siehe auch unten 4 1 3 4 1 1 Hierarchienbildung Nach der Zusammenfassung mehrerer Stellen zu einer Stelle k nnen wir diese neue Stelle in unserem Modell nach wie vor als eine primitive Stelle betrachten Wir k nnen aber auch die Zusammenfassung selbst in unserem Modell festhalten indem wir diese neue Stelle als eine zusammengesetzte Stelle im Modell definieren und die zusammengefassten Stellen als 51 4 Bottom up Modellierung und Abstraktion Teilstellen der zusammengesetzten Stelle auff hren Dies machen wir im Allgemeinen dann wenn z B nicht allzu viele Teilstellen aufzuzeigen sind oder wenn die Teilstellen sp ter f r die Implementierung ganz bestimmten unterschiedlichen Laufzeitstellen zugeordnet werden sollen Z B kann ein Datum mit drei konkreten Teilstellen Tag Monat und Jahr auch auf drei Felder am Bildschirm abgebildet werden In Point and click Dialogen sehen wir h ufig dass dann konkrete Tage Monate und Jahre auch explizit zur Auswahl z B in Pop up Men s angeboten werden Zwischen den Teilstellen und der zusammengesetzten Stelle besteht eine hierarchische Beziehung die wir h ufig als eine has a Beziehung obiges Beispiel Datum hat Tag Monat
164. en Pfeils sind alle brigen Pfeile Auspr gungen von bereits vorgestellten Pfeilen eines Ereignisstellendiagramms die gr nen Pfeile stellen ffne Pfeile oder Pfeile zum Triggern von Wert bertragungen dar die Pfeile in Rot sind Schlie e Pfeile Die orangefarbenen Pfeile repr sentieren die Wert bertragung von einer Ereignisstelle zur anderen getriggert durch einen gr nen Pfeil Variationsannotation Einigen Elementen im Modell ist Variationsinformation zugeordnet die hier als Fu noten im Diagramm angef gt sind siehe auch unten Die Zuordnung der Variationsinformation zu den Dialogelementen ist durch die annotierten Fu notensterne zu erkennen 8 2 Erl uterung und Diskussion des Beispiel Diagramms Wie ist das Diagramm nun zu interpretieren 8 2 0 Dynamik Start mit SelectOperations Dialog Mit Start der Applikation wird der Dialog die Ereignisstelle JobEditor und in ihm der Teildialog Teilereignisstelle SelectOperations er ffnet Dies geschieht per Definition deshalb weil weder in diese Ereignisstellen noch in hierarchisch bergeordnete Ereignisstellen ffne Pfeile m nden Startstellen Das gleiche gilt f r alle Teildialoge von SelectOperations Es handelt sich hier um nebenl ufige Ereignisstellen die sofort mit dem Er ffnen des bergeordneten Dialogs verf gbar sind Ansto JobSelection Die Durchf hrung eines durch die Stelle LoadJob repr sentierten Ereignisses er ffnet den Dialog zur Selektion der aus der Da
165. en zu wechseln zum anderen tragen sie der Tatsache Rechnung dass unvorhergesehene bzw asynchrone Ereignisse im System bzw der Applikationslogik Komponente im System auftreten Dieser Wechsel des Kontexts kommt dadurch zustande dass w hrend des Dialogablaufs nebenl ufige Dialogfolgen quasiparallel oder auch echt parallel bedient und aber wiederum auf eine einzige Sequenz von Dialogereig nissen abgebildet werden 4 2 2 Reduktion auf logische Stellen berg nge Bisher haben wir im Modell alle diese unterschiedlich begr ndbaren berg nge ohne Unterschied dargestellt Wir erreichen nun eine drastische Reduktion in der Darstellung der berg nge wenn wir zwischen den berg ngen zwischen nebenl ufigen Dialogen und den berg ngen innerhalb logisch begr ndbar zusammenh ngender Dialoge unterscheiden 68 4 2 Logische Abstraktion Die Reduktion wird dadurch erreicht dass wir dann nur mehr die logisch begr ndbaren bzw logisch notwendigen berg nge explizit darstellen und auf die Darstellung der berg nge zwischen nebenl ufigen Dialogen mit Ausnahmen grunds tzlich verzichten Dialoge zwischen denen keine expliziten berg nge definiert sind gelten somit als nebenl ufig Als Ersatz f r die nunmehr fehlende explizite Auszeichnung der berg nge fordern wir aber dass Dialogschritte in nebenl ufigen Dialogen parallel oder quasiparallel durchf hrbar sind Dies bedeutet insbesondere dass jederzeit von einem Dialog in den ande
166. ender Dialog beschreibender Text sowie Bezeichner unterscheiden Dies wird vom System als Hinweis daf r genutzt dass diese Attribute zusammen mit der Anzahl der Instanzen sich ebenfalls ndern In gleicher Weise sei die automatische Erkennung der nicht variierenden Attribute durch das System deshalb erfolgt weil die drei Icons in Gr e Hintergrund und Vordergrundfarbe bereinstimmen In jedem Fall aber kann eine automatische Festlegung der variierenden Merkmale vom Benutzer berschrieben werden wenn beispielsweise erwartet wird dass sich zuk nftige Icons auch in Gr e und Farben unterscheiden k nnten kann der Benutzer des Entwurfssystems Gr e Hinter und Vordergrundfarbe ebenfalls als zu variierende Merkmale festlegen Ebenso ist denkbar dass der Benutzer bei der Position eine Differenzierung machen m chte und definiert dass die Position nur in der horizontalen Koordinate variieren darf Als Zeitpunkt der Berechnung Bestimmung der Variation wird das ffnen der Toolbar gew hlt Der Zeitpunkt zu dem die Variation stattfinden wirken soll sei ebenfalls das ffnen der Toolbar Als Variationstyp geben wir an dass es sich um eine vollst ndige Variation handelt Dies bedeutet dass bei jedem ffnen der Toolbar die Menge der Iconvarianten komplett neu bestimmt und ausgetauscht wird Dies h tte etwa zur Konsequenz dass eine nderung der Daten in der Benutzerdatenbank durch erneutes ffnen der Toolbar eine komplett neue
167. ene B ndelung durchzuf hren nehmen wir umgekehrt im Modellierungsprozess h ufig auch eine Verfeinerung in mehreren Hierarchiestufen vor Im Sinne einer Granulierung des Dialogs kommen wir zu einem Feinheitsgrad der aus aufgabenlogischer und oder aus dialogtechnischer Sicht f r die Modellierung irrelevant wird Das obige Beispiel der Modellierung einer Datumseingabe kann z B im Extremfall im Sinne einer weiteren Detaillierung bis auf eine Ebene fortgesetzt werden in der auch noch die einzelnen Ziffern einer Jahreszahl als Teilstellen modelliert werden In vielen F llen ist aber bereits die Detaillierung der Eingabe eines Datums in Tag Monat und Jahr uninteressant Zum einen ist es in vielen F llen nicht in allen aufgabenlogisch unwichtig wie ein Datum und welches Datum eingegeben wird In vielen F llen bleibt insbesondere eine Fortsetzung des Dialogpfades von der Eingabe eines bestimmten Datumswertes unbeeinflusst D h unser Modellgraf ndert sich in der Darstellung der potentiell nachfolgenden Dialoge nicht mehr wenn wir eine h here Feinheit der Dialogdarstellung der Ausgangsstelle w hlen Die notwendige Verfeinerung ergibt sich auch aus der Ebene ab der in konkrete vorgefertigte Laufzeitstellen abgebildet werden kann Wenn z B bereits auf der Ebene der Implementierung ein komfortables Datumswidget existiert ist eine detaillierte Darstellung des Datumseingabedialogs auf Modellebene unn tige Doppelarbeit 4 1 2 Schleifenbildung und R
168. enen Instanz Ausblenden von Kanten Zur besseren bersicht ist es h ufig sinnvoll nur Kanten zwischen den Teilstellen einer Stelle wegzulassen In diesem Fall zeichnen wir als Hinweis der Weglassung in das Rechteck der Stelle einen Pfeil mit gestrichelter Linie Ausblenden von Annotationen Mit dem Ausblenden von Teilstellen oder Kanten ist automatisch das Ausblenden aller zugeh rigen Annotationen verbunden Dar berhinaus sei es der Implementierung des Modelleditors berlassen einzelne Annotationen oder Annotationstypen an sichtbaren Teilstellen oder Kanten auszublenden 5 3 2 2 Darstellung der Hierarchie in Modellsichten Die Hierarchieinformation einer zusammengesetzten Stelle kann in ein eigenes Diagramm ausgelagert werden D h zusammengesetzte Stellen k nnen auch ohne ihre Teilstellen oder nur mit einer Teilmenge der Teilstellen dargestellt werden Hierbei nutzen wir obigen allgemeinen Ansatz dass wir in einer Teilsicht einerseits Detailinformation ausblenden k nnen zum anderen in einer anderen Teilsicht die komplette Umgebung einer Stelle In der Teilsicht mit ausgeblendeten Teilstellen zeichnen wir zur Kennzeichnung der Weglassung von Information drei Punkte Umgekehrt zeichnen wir in der anderen Sicht in der lediglich die zusammengesetzte Stelle mit ihren Teilstellen dargestellt ist au erhalb der Stelle drei waagrechte Punkte und kennzeichnen die Stelle selbst mit einer gepunkteten schr gen Linie siehe Abbildung 5 7 zum Hin
169. er Kommandodialog erfordert relativ geringe technische Voraussetzungen Kommandozeile und Tastatur und ist einer der klassischen Dialogarten Layout Unter Layout wird im weiteren Sinne die konkrete Ausgestaltung des Dialogs in einer bestimmten Dialogart und oder in einem bestimmten Dialogstil verstanden Das Layout des Dialogs ist in diesem Verst ndnis in Abgrenzung zum logischen Dialog zu sehen der die eher inhaltlichen Aspekte des Dialogs umschreibt Im engeren Sinne wird im grafischen Dialog unter Layout die Anordnung der verschiedenen Dialogobjekte die Aufteilung der Bildschirmfl che auf die Objekte die Zuordnung von Abst nden der Objekte zueinander etc verstanden Men dialog Dialogart in der vom System Operationen und Werte dem Benutzer zur Auswahl einzeln hintereinander oder in Gruppen angeboten werden Der Men dialog ist in der Regel hierarchisch organisiert so dass der Benutzer durch sukzessive Auswahl von Men punkten einen Auftrag absetzt bzw einen Wert bestimmt Im Men dialog liegt die Initiative beim System Der Benutzer wird durch das System gef hrt Der Men dialog ben tigt relativ geringe technische Ressourcen und wird h ufig in Systemen mit kleinen Ausgabedisplays eingesetzt Multimedialer Dialog Der multimediale Dialog kann als eine Erweiterung des grafischen Dialogs gesehen werden Er nutzt verschiedene Medien f r Eingabe und Ausgabe insbesondere neben den visuellen M glichkeiten der Bildschirmdarstellung die a
170. er Stellen definiert mit den blichen Eigenschaften einer Hierarchie siehe auch Abschnitt 3 0 3 0 Grundmodell Ein hierarchisches Ereignisstellenmodell ESMH ist somit ein Tupel E T W S So HS RO RC C P T ERO ERC e start KRO KRC TRO wobei alle Elemente des Tupels au er T t und HS wie oben definiert sind und HS eine hierarchische Relation ber S als Teilmenge von S S darstellt T und t sind die entsprechenden Erweiterungen von T und t f r zusammengesetzte Stellen und zusammengesetzte Ereignisse siehe auch Abschnitt 3 1 Formale Darstellung des Grundmodells T Ip Os Ms IsOs IMs IsOsMs OsMs und T E gt T Die oben definierte bergangsfunktion ist dann so zu erweitern dass die berg nge von Stellen zu zusammengesetzten Stellen und ihren Teilstellen eindeutig definiert sind 81 5 Ereignisstellenmodell Dazu sind insbesondere die beiden Relationen RO RC die die ffne bzw Schlie erelation in einem nicht hierarchischen Modell ausdr cken durch Relationen auszutauschen die die Hierarchie von Stellen mit einbezieht Wir definieren deshalb zwei Relationen ROH und RCH die aufsetzend auf den Relationen RO RC wie oben definiert und HS festhalten wann eine Stelle aufgrund eines Ereignisses an einer anderen Stelle er ffnet bzw geschlossen wird Definition von ROR c S 8 S J s s ROR amp J s s e RO oder 3 s s RO
171. er und nebenl ufiger Zust nde Zust nde lassen sich in State Charts hierarchisch beliebig tief schachteln d h in Unterzust nde aufteilen bzw lassen sich umgekehrt gesehen Bottom up in Gruppierungs zust nden zusammenfassen Unterzust nde im Folgenden auch Teilzust nde genannt k nnen dabei nebenl ufig aktiv sein Dies wird durch die Zusammenfassung in einem so genannten AND Grouper Zustand manifestiert Stellen die Zust nde dagegen sich gegenseitig ausschlie ende Alternativen dar werden sie in einem so genannten XOR Grouper Zustand geb ndelt In State Charts werden Zust nde in abgerundeten Rechtecken dargestellt wobei alternative Teilzust nde in Form abgerundeter Rechtecke innerhalb des bergeordneten Zustands rechtecks liegen Zur Darstellung paralleler Teil Zust nde wird das Rechteck des bergeord neten Zustands AND Grouper durch gestrichelte Linien unterteilt wobei die so sich erge benden Teilfl chen jeweils einen nebenl ufigen Unterzustand beschreiben Der Vorteil der Darstellung liegt darin dass durch die hierarchische Unterteilung in Teilzust nde die Anzahl der Zust nde bzw Zustands berg nge stark reduziert wird Es m ssen nicht mehr alle m glichen Zust nds berg nge von einem Zustand einer Gruppe zu einem Zustand der anderen Gruppe gezeichnet werden Zustands berg nge von den 136 9 3 State Charts Unterzust nden nach au en oder von u eren Zust nden nach innen in die XOR Gruppe bzw AND Gru
172. ereignisse an den Stellen So und S werden automatisch durch das Eingabeereignis vom Typ Mouse click auf dem RadioButton realisiert Wir haben also eine Abbildung der beiden logischen Eingaben An und Aus auf ein konkretes Ereignis Mouse click das standardm ig mit der Konstruktion der Instanz aktiviert ist Das ffnen der einzelnen Modellstellen wird auf die leere Operation abgebildet falls die Instanz bereits existiert Leere Operation sei hier so verstanden dass wir bei der Implementierung mit Hilfe der Klasse JRadioButton keinen zus tzlichen Aufwand ben tigen da die Operation bereits im Code der Klasse implizit als Realisierung des Zustandswechsels enthalten ist Ebenso wird das Schlie en der Stellen auf die leere Operation abgebildet solange nur eine der anderen Modellstellen ge ffnet ist und diese im Zuge der Interpretation des Ereignisses auch nicht geschlossen werden soll Letztere Voraussetzungen sind im dargestellten Modell immer gegeben Das Schlie en einer Stelle geschieht im Modell immer zusammen mit dem ffnen einer anderen Stelle oder es bleiben beim Schlie en einer Stelle andere Stellen ge ffnet Das ffnen und Schlie en der Modellstellen aufgrund von Ereignissen an einer der Stellen bewirkt also kein ffnen oder Schlie en der Widget Instanz in der hier gew hlten Implementierung Stattdessen erfolgt ein Zustandswechsel der sich ber die Wert nderung des Attributs selected bzw eine Visualisier
173. es in eine konkrete Implementierung umzusetzen sondern eine Basis f r die Entwicklung anderer konkret einsetzbarer Modelle zu schaffen Bemerkung zum Ereignisbegriff Der Begriff Ereignis kann auf unterschiedlichen Ebenen der Konkretisierung Verwendung finden Manchmal ist es n tig zwischen einem konkreten Ereignis und einem abstrakten Ereignis zu unterscheiden Einem konkreten Ereignis kann z B ein genauer Zeitpunkt zugeordnet werden Bei einem etwas abstrakteren Verst ndnis k nnen wir beispielsweise vom konkreten Zeitpunkt absehen Es handelt sich dann bei einem so verstandenen Ereignis eher um eine Klasse konkreter Ereignisse bzw umgekehrt bei den konkreten Ereignissen eher um Ereignisvorkommen des abstrakten Ereignisses Entsprechend dieser unterschiedlichen Abstraktionsebene und dem unterschiedlichen Verst ndnis von Ereignis ist in einem Fall dann die Funktion f 0 n E eine injektive Funktion deren inverse f zumindest auf f 0 n definiert ist und jedem Ereignis genau ein i 0 n zuordnet Die Zuordnung eines Index in der Folge der Ereignisse ist allerdings bereits eine Abstraktion von einem konkreten Zeitstempel Auch die Funktion o E gt S ist entsprechend zu interpretieren je nachdem ob wir die Stellen als Stellen betrachten die den Zeitpunkt des Ereignisses mit einbeziehen Ist dies der Fall gehen wir notwendigerweise in unserem Modell davon aus dass mit Ereignis der konkrete Ereignisbegriff verst
174. ete Art der Darstellung des dynamischen Verhaltens eines Dialogsystems ist die Formulierung von Programmcode in einer spezifischen Skriptsprache oder einer g ngigen Sprache der dritten Generation Java C C J Visual Basic Perl PHP Es werden dabei Routinen geschrieben die bei Eintreten bestimmter Ereignisse angesto en werden Callback Routinen Eventhandler in Motif Eventlistener in Java ber entsprechende Methoden der Dialogobjektklassen k nnen die Widgets beispielsweise kreiert ge ffnet geschlossen und gel scht werden Viele Attribute k nnen ebenso ber Methoden dynamisch abgefragt und gesetzt werden 1 0 1 3 Wizards zur Codegenerierung Ein weiteres Hilfsmittel zur Beschreibung von Dynamik sind so genannte Wizards oder Programmassistenten die den Programmierer bei der Erzeugung von Code unterst tzen Es handelt sich dabei um Dialogsequenzen in denen der Benutzer vom System gef hrt in einer Art Frage Antwort Dialog eine Aufgabe l st Dabei handelt es sich hier beispielsweise um die Beschreibung der notwendigen Reaktionen auf ein bestimmtes Ereignis In mehreren Schritten wird der Benutzer durch den Assistenten gefragt auf welches Ereignis welche Aktionen an welchen Objekten durchgef hrt werden sollen Dazu werden dem Benutzer die m glichen Antworten bereits zur einfachen Auswahl angeboten Das System setzt dann die Antworten des Benutzers meist sofort automatisch in entsprechenden Programmcode um Der Ausgangs
175. f r jeden dieser Endknoten eine alternative Anschlussstelle vorzusehen 52 4 1 Reduktion von Stellen und Transitionen 2 einer einzigen R ckkehrstelle und dann der Formulierung von Bedingungen an den berg ngen von der Aufrufstelle zu Folgestellen siehe auch Abbildung 4 8 LaufwerkDialog E Abbildung 4 8 Hierarchische Darstellung am Beispiel des Laufwerksdialogs Statt der Reduktion von Stellen und Stellen berg ngen in Abbildung 4 6 durch einmalige Darstellung wird hier ein Dialog mit Namen LaufwerkDialog zweimal gezeigt Der Dialog fasst mehrere Subdialoge zusammen An der einen Stelle wird der Dialog entfaltet an der anderen gefaltet gezeigt Der Laufwerk Dialog hat nur einen Ausgang Welcher der alternativen internen Stellen durchlaufen wurde ist aus der Fortf hrung des Grafen ber eine Ausgangsstelle nicht mehr ersichtlich Wir ben tigen ein zus tzliches Ged chtnis das wir im sp teren Verlauf abfragen k nnen siehe sp ter Hilfsstellen und Conditions Die Zusammenfassung kann wie oben bereits erw hnt in mehreren Stufen erfolgen Letztlich kann der gesamte Dialog einer Stelle in einem Grafen zugeordnet werden der nur diese Stelle als Knoten beinhaltet Graf der Hierarchiestufe null Die Stelle repr sentiert das gesamte zusammengesetzte Dialogereignis 53 4 Bottom up Modellierung und Abstraktion Grad der notwendigen oder sinnvollen Verfeinerung Statt die oben beschrieb
176. fassung sind zun chst die beiden Teildialoge zur Erfassung der Kundendaten und zur Erfassung der Auftragspositionen voneinander unabh ngig Ebenso sind in vielen F llen auch die einzelnen Auftragspositionen voneinander logisch unabh ngig Dasselbe gilt f r die Kundendaten Logisch gesehen k nnten alle Daten gleichzeitig erfasst werden In der Praxis bedeutet dies dass zumindest die Daten in beliebiger Reihenfolge erfassbar sind Der Benutzer kann also bei der Erfassung beliebig von Feld zu Feld von Teildialog zu Teildialog springen Er ist dabei nicht gezwungen einen Teildialog abgeschlossen zu haben wenn er einen anderen aufnimmt oder fortsetzt Damit ergibt sich eine Vielzahl m glicher berg nge von einem einzelnen atomaren Dialogereignis zu einem anderen In modernen Dialogsystemen ist die Realisierung einer derartigen Flexibilit t des Dialogs mit entsprechender Freiheit der Dialogf hrung f r den Benutzer selbstverst ndlich Den gegebenen M glichkeiten muss auch im Modell entsprechend Rechnung getragen werden Selbst wenn logische Abh ngigkeiten zwischen den einzelnen Teildialogen bestehen kann es dennoch sinnvoll sein dem Benutzer die maximale Freiheit in der Wahl seiner Dialogschritt folge zu belassen In obigem Beispiel der Auftragserfassung k nnte z B eine automatische Einblendung des Ortes gew nscht sein wenn der Benutzer die Postleitzahl im Kundendaten Dialog eingibt Dennoch sollte das System dem Benutzer erlauben de
177. festgelegt sein dass die Festlegung eines Preises erst dann erfolgen soll wenn die im Auftrag enthaltenen Leistungen definiert sind und auch erst dann wenn der Kunde bekannt ist Da der Preis durch das System automatisch berechnet werden soll muss daher die Eingabe der Leistungsdaten des Auftrags und die Erfassung der Kundendaten durch den Mitarbeiter vor der Ausgabe des automatisch errechneten Preises liegen Ablaufoptimierende Reihenfolge Gehen wir etwa davon aus dass die Zielsetzung einer Dialoganwendung wie die anderer Anwendungssysteme auch dadurch definiert ist m glichst effizient kostenoptimierend bestimmte Aufgaben durchzuf hren und Ergebnisse zu liefern Dann ist entscheidend dass die beteiligten Instanzen oder Teilkomponenten des Systems die die Aufgaben zu erledigen haben rechtzeitig mit der gew nschten oder ben tigten Information versorgt werden um ihre 61 4 Bottom up Modellierung und Abstraktion Arbeit ohne Zeitverz gerung ausf hren zu k nnen Bei einer Dialoganwendung haben wir als beteiligte Instanzen zum einen den Benutzer zum anderen die Applikationskomponente die ber die Dialogkomponente bzw Dialogschnittstelle mit Information zu versorgen sind Daraus ergibt sich als Ziel der Modellierung des Dialogs den notwendigen Austausch der Information an der Dialogschnittstelle diesem Ziel der Ablaufoptimierung unterzuordnen Wodurch wird dann der Zeitpunkt der einzelnen Dialogschritte bestimmt Um beispielsw
178. fragen von Werten erm glicht Damit ist im Prototyp grunds tzlich die Anbindung von Klassen m glich die ber die Funktionalit t von reinen Oberfl chenelementen hinausgeht Z B k nnte im Konstruktor einer Instanz nicht nur das Erzeugen eines Widgets f r die Darstellung an der Oberfl che sondern auch der Zugriff auf eine Datenbank implementiert sein 10 2 1 Zuordnung von Widgetinstanzen Wie bereits in Kapitel 6 erw hnt ist es m glich mehreren Ereignisstellen des Modelldia gramms dieselbe Widgetinstanz zuzuordnen Dies ist im Prototyp ber die Stellenbezeichner gesteuert Haben Ereignisstellen denselben Bezeichner und sind die Stellen hierarchisch gleich eingeordnet d h sind sie Teilstelle derselben bergeordneten Stelle sorgt der Codegenerator f r die Erzeugung einer einzigen Instanz f r diese Stellen In allen anderen F llen wird jede Stelle eindeutig auf eine eigene Instanz abgebildet ber das Sprachmittel der Exemplarvariation siehe Kap 7 und unten k nnen au erdem einer Stelle mehrere Instanzen zugedacht werden Im Folgenden werden zwei verschiedene Arten der Interpretation vorgestellt wie sie auch im Prototyp realisiert werden Die eine Art zielt auf Anwendungsf lle in denen z B im ersten Entwurf ein Dialog an mehreren Stellen in seinen Eigenschaften unvollst ndig im Sinne der Darstellung verschiedener Szenarios oder Teilaspekte modelliert wird die in einer Widgetinstanz gleichsam verschmolzen werden Wir k nnen
179. funktion von Ereignistypen t E gt T o Funktion zur Zuordnung von Stellen zu Ereignissen o E gt S Funktion zur Zuordnung eines Wertes zu Ereignis E gt W partielle Funktion zur Zuordnung eines Wertes zu einer Stelle nach einer Reihe von Ereignissen o S EHIST gt W mit EHIST ehist ehist E und 3 f F ie N K0 f1 fG ehist Zum Grundmodell insbesondere zur Funktion noch einige Erl uterungen 34 3 0 Zentrale Begriffe des Dialogmodells Einem Ereignis ist in unserem Grundmodell eine Stelle zugeordnet Funktion o Wir sagen das Ereignis e findet an der Stelle s statt wenn gilt o e s Wir ordnen ebenfalls jedem Ereignis einen bestimmten Wert zu Funktion Wir wollen nun zus tzlich annehmen dass prinzipiell auch an einer Stelle zu bestimmten Zeitpunkten Werte abgelesen werden k nnen Dass dies Sinn macht ist evident wenn wir uns vorstellen dass nach dem Einwirken Stattfinden eines Ereignisses an einer Stelle an dieser auch ein bestimmter Wert vorliegt Dieser Wert ndert sich im Allgemeinen in Abh ngigkeit der an der Stelle stattfindenden Ereignisse Der gerade g ltige Wert der Stelle kann mit dem Wert des letzten Ereignisses an der Stelle bereinstimmen oder kann zumindest durch den Wert des letzten Ereignisses beeinflusst worden sein Beispiel Jede Bet tigung eines Druckknopfes an einem Z hler erh he den Wert des Z hlers um 1 Betrachten wir den Z
180. funktionen als dynamischer Vorgang spezifiziert werden Triggerereignisse unterschiedlicher Auspr gung k nnen als Annotationen an die entsprechenden Triggerkanten angebracht werden siehe dazu auch Abbildung 6 6 WYSIWYG Darstellung eines RadioButton mit nur einer Stelle 2 Aufl sung der Ereignisstelle in mehrere WYSIWYG Stellen pro Einzelwert Zur urspr nglichen extensiven WYSIWYG Darstellung nach Beispiel in Abbildung 4 1 gelangen wir wiederum wenn wir die abstrakte Ereignisstelle mit ihren mehreren m glichen Werten in alternative WYSIWYG Stellen aufl sen die jeweils eines der einzelnen Ereignisse konkret darstellen Dies macht nur da Sinn wo die Anzahl der m glichen Werte nicht zu gro ist Dies kann formal auch betrachtet werden als die Aufl sung einer abstrakten Modellstelle in mehrere zun chst abstrakte Stellen die dann jeweils auf eine WYSIWYG Stelle abgebildet werden 3 Exemplarische Darstellung und Annotation der Variation Eine besondere Art Varianten von Ereignissen an einer WYSIWYG Stelle zu beschreiben ist die dass wir exemplarisch eines der Ereignisse im WYSIWYG Modus zeigen und das Exemplar wiederum mit einer speziellen Annotation versehen die beschreibt in welcher Weise die Darstellung in den alternativen F llen abweichen kann Dabei wird die Information die in der WYSIWYG Darstellung enthalten ist nicht nur als exemplarische Visualisierung f r den Benutzer des Modelleditors sondern weitgehend als Spezifik
181. g sind sofort evident Verk rzung des Entwicklungszyklus Die Erstellung eines Prototyps bei Rapid Prototyping Systemen bzw die Erstellung eines ersten einsatzf higen Systems ist zumindest in einfachen F llen relativ schnell mit wenig Aufwand machbar Fr hzeitige Erkennung von Fehlern Der relativ kurze Entwicklungszyklus erm glicht ein iteratives Vorgehen im Projektablauf Fehler oder M ngel k nnen schnell erkannt und behoben werden Fr hzeitige Abstimmung mit potentiellen Nutzern Nicht nur der Entwickler erh lt in einem fr hen Stadium der Entwicklung des Dialogsystems einen unmittelbaren Eindruck vom zu erwartenden Endergebnis sondern auch der sp tere Benutzer Ist dieser in die Entwurfs und Entwicklungsphase aktiv mit einbezogen erh ht dies seine Akzeptanz gegen ber dem zu erstellenden System erheblich 18 1 0 Einsatz von Systemen zum Rapid Development Standardisierung f r Oberfl che und technische Implementierung Die automatische Codegenerierung bringt in gewissem Grad eine Standardisierung sowohl was die Benutzeroberfl che betrifft als auch im Hinblick auf die erzeugte technische Implementierung Ein eventuell sp ter notwendiger Eingriff in den generierten und damit relativ normierten Code d rfte in der Regel leichter vorzunehmen sein als ein Eingriff in unter Umst nden durch mehrere Entwickler individuell erstellten Code 1 0 3 Nachteile So evident die Vorteile erscheinen so gravierend sind
182. gang zu einer Zustandsstelle die Aussagen der brigen Zustandsstellen der Instanz ung ltig zu machen und daf r alle Aussagen der aktuellen Zustandsstelle zu aktivieren Dies bedeutet insbesondere dass alle Widgets die Ausgabestellen realisieren geschlossen und Widgets die ausschlie lich Eingabeereignisse realisieren insensitiv gesetzt werden falls sie nicht als Startstellen der zu ffnenden Zustandsstelle erkannt werden Nachdem wie oben beschrieben festliegt welcher Widgetklasse bzw welchen einzelnen Widgetressourcen die Ereignisstellen zugeordnet sind und welche Instanzen erzeugt werden sollen kann mithilfe dieser Information Code f r die Realisierung der Ereignisstellen bzw das ffnen und Schlie en der Stellen generiert werden 10 2 2 Interpretation des formalen ffnens und Schlie ens Im Prototyp werden die im formalen Modell eingef hrten Begriffe des ffnens und Schlie ens von Ereignisstellen wie folgt umgesetzt Widgetinstanzen die primitive Eingabestellen repr sentieren d h Stellen denen Eingabeereignisse zugeordnet sind werden mit ihren Container Widgets ge ffnet d h erzeugt und sichtbar gesetzt Die Eingabe wird aber erst dann erm glicht wenn die Stelle nach Definition im formalen Modell zu ffnen ist Ist die Stelle eine Startstelle ist dies sofort mit dem ffnen der bergeordneten Stelle also o B d A dem ffnen des Container Widgets der Fall Im anderen Fall muss erst ein entsprechendes Ereignis ei
183. ge der Beobachtung aufgezwungen Er kann die dargestellte Folge nach eigenem Gutd nken vorw rts und r ckw rts verfolgen Die zeitliche Abfolge ist f r ihn aber dennoch erkennbar Zum anderen sind wir in unserer Modellierung nicht an ein Medium gebunden das Dynamik unterst tzt 38 4 0 WYSIWYG Ansatz 4 0 0 Ein einfaches Beispiel der WYSIWYG Modellierung Fortsetzung von Bild 4 links unten KA Bild Bila2 Bid System wirft Disk aus Ende Fortsetzung von Bild 1 Alternative zu Bild2 Quickinstall Bid3 Bid Ouickinstatl Bilde Bilda Installation abgebrochen Fortsetzung Bild 5 rechts oben Bildt0 System wirft Disk aus Ende Abbildung 4 1 Beispiel f r WYSIWYG Modellierung Teil 1 Teil 2 in Abbildung 4 2 Jedes Ausgabe und Eingabeereignis wird Schritt f r Schritt in einem eigenen Bild festgehalten Abbildung 4 1 und Abbildung 4 2 zeigen einen einfachen Dialog zur Installation eines Softwarepaketes in einer Folge von Bildern Jedes Bild in den Abbildungen zeigt eine Momentaufnahme des Dialogs die ein Eingabe oder Ausgabeereignis repr sentieren soll Im Standardfall zeigt die Bildreihenfolge auch die Reihenfolge der Ereignisse Im Dialog ergeben sich jedoch alternative Verzweigungen Um diese darstellen zu k nnen sind die Bilder durchnumeriert und gegebenenfalls mit entsprechenden Fortsetzungshinweisen versehen Wir erleben bei Betrachtung de
184. geben Eingabe Ausgabeereignis oder von der Stelle abgelesen wird Lesen durch System bzw Wahrnehmung durch Benutzer Diese Informationseinheit k nnen wir auch als Dialogwert des Ereignisses beschreiben Ebenso k nnen wir einer Dialogstelle einen Dialogwert zuordnen Der Dialogwert der Dialogstelle wird durch den Wert eines Eingabe Ereignisses oder Ausgabe Ereignisses das an der Stelle stattfindet beeinflusst D h durch die Eingabe eines Wertes an einer Stelle wird der Wert einer Dialogstelle ggf ver ndert Der Wert der Ereignisstelle kann beim Leseereignis abgegriffen werden Dialogwert von Triggerstellen Bei einer Triggerstelle besteht unter Umst nden der Dialogwert darin dass lediglich die Information an andere Stellen weitergegeben wird dass ein Ereignis eingetreten ist Der Wert des synchronen Lesevorgangs besteht also im Triggern von Ereignissen an anderen Stellen Besitzt die Triggerstelle keine Speicherfunktion ist nach dem Triggervorgang kein Ablesen eines Dialogwertes mehr m glich Im Ereignisstellenmodell Kap 5 ist das Triggern eines Ereignisses im Wesentlichen durch die ffne Relation ausgedr ckt 3 0 3 Relationen des Dialogs Zwischen Ereignissen Stellen und Werten des Dialogs bestehen eine Reihe von Beziehungen die im Modell festgehalten werden sollen Es gibt dabei Beziehungen die rein statischen Charakter haben und Beziehungen die im Gegensatz zu diesen das dynamische Verhalten des Dialogs beschreiben bzw
185. gen Um allerdings die Kontrolle des Dialogablaufs f r die Implementierung des Systems zu spezifizieren m ssen dann die systemseitigen Ursachen f r Dialogschritte also Ereignisse bzw Aktionen im System die zu Ereignissen bzw Aktionen an der Dialogschnittstelle f hren hinzugef gt werden Im Folgenden sollen einige Kriterien zur Beschreibung der zeitlichen Reihenfolge von Dialogereignissen herausgearbeitet werden Wir werden sehen dass es logisch und technisch begr ndete Reihenfolgen gibt Reihenfolgen die sich aus der Darstellung echtzeitlichen Geschehens ergeben und zufallsbedingte Reihenfolgen bzw Reihenfolgen die nicht von vorneherein im Dialogmodell erfassbar sind 4 2 1 1 Logisch begr ndete Dialogreihenfolgen Wenn wir sehr weit vom konkret durchgef hrten Dialog abstrahieren und nur die grundlegen de Zielsetzung einer Dialoganwendung betrachten also eine rein aufgabenlogische Sicht et wa resultierend aus der Phase der Aufgabenanalyse einnehmen k nnen bereits Anforderun gen definiert werden die die zeitliche Reihenfolge einzelner Dialogschritte bei der Dialogmo dellierung bestimmen Logisch bedingte Abl ufe von Teilaufgaben Aus der Aufgabenanalyse heraus ergeben sich h ufig Abh ngigkeiten einzelner Teilaufgaben die den Dialogablauf in eine bestimmte Reihenfolge zwingen Beispielsweise kann bei einem Dialog zur Auftragserfassung aufgrund der Definition der logischen Anforderungen an den Ablauf der Auftragsannahme
186. gen abgehandelt werden wobei die Abarbeitung dieser Ereignisse unmittelbar nach dem ffnen der Stelle also synchron erfolgt Wenn nun mehrere Stellen berg nge bei einem bergang erfolgen muss ber eine Ordnungsfunktion auf den Stellenpaaren in RO entschieden werden in welcher Reihenfolge die Abarbeitung der Schreibereignisse erfolgen soll Diese Ordnung ergibt dann die Reihenfolge im Tupel enext der propagierten Ereignisse enext o i m 0 lt i lt m mit im N falls S m 1 mit e Prsrosi s Si ti mit si S tie Os Ms falls p srosi definiert also nro sROs P sROsi null ess null sonst und ordro s s i ordro sei eine geeignete Ordnungsfunktion auf den Paaren sk s1 RO die jeweils allen Paaren mit gleicher Ausgangsstelle sk eine eindeutige Ordnungszahl zuordnet und ti Os falls si Dialogstelle ti Ms sonst enext null sonst und 79 5 Ereignisstellenmodell Bleiben noch S und S zu definieren Ein 6 bergang kann das ffnen oder Schlie en von Stellen bewirken und damit die Menge der m glichen Ereignisse erweitern und oder einschr nken In der n chsten Klammerung werden die Kriterien f r das ffnen einer Stelle und in der darauf folgenden die f r das Schlie en festgelegt Dies geschieht in Form der Definition zweier Stellen Teilmengen S bzw S bzw zweier Relationen RO und RC die RO bzw RC einschr nken 1 D
187. gen werden kann Dies geschieht so dass ber Werte an bestimmten Stellen die Historie des Dialogablaufs aufgezeichnet wurde siehe dazu unten auch Werte bertragungen und von diesen Stellen nun zur Entscheidungsfindung mittels Condition die Werte abgelesen werden 4 1 3 1 Hilfsstellen Um im System auch Schreibereignisse zuzulassen die weder als Benutzer Eingabe noch als Systemausgabe gedacht sind f hren wir einen neuen Ereignistyp Ms Memorize by System oder Merken durch System ein Ereignisse des Typs Ms die auch als verborgene Schreibereignisse des Systems charakterisiert werden k nnen dienen z B dazu Werte zur Beschreibung der Dialoghistorie an Stellen zu speichern die nicht an der Dialogoberfl che wahrgenommen werden Die diesen Ereignissen zugeordneten f r den Benutzer verborgenen Stellen wollen wir als Hilfsstellen oder auch als reine Speicherstellen bezeichnen Auf diese Hilfsstellen kann nun zus tzlich mittels Conditions s o oder bertragungsfunktionen s u zugegriffen werden Formal erweitern wir also unsere Menge von Ereignis Typen T T Ip Os Ms Lpg Ls Die Menge der m glichen Ereignistypen T f r zusammengesetzte Ereignisse erweitert sich um entsprechende Kombinationsm glichkeiten mit Typ Ms Ereignisfolgen k nnen sich nunmehr aus reinen Dialogereignissen gemischt mit verborgenen Schreibereignissen des Typs Ms zusammensetzen Eine sinnvolle Einschr nkung sei noch gefordert An
188. gert Nach Erkennen der elementaren Tokensequenz durch das Unterobjekt erfolgt dort ein Zustands bergang in dem das erkannte Synthetic Token versendet wird wodurch dann der Zustands bergang des auf das Token wartenden bergeordneten Objektes durchgef hrt wird Vergleich mit ESD Zustands berg nge k nnen in einem ESD mittels Stellen berg ngen realisiert werden bei denen alle Stellen die nicht den jeweiligen Zustand repr sentieren geschlossen werden und umgekehrt alle Stellen die den neuen Zustand darstellen ge ffnet werden Im einfachen Fall bei dem eine Stelle genau einen Zustand darstellt bedeutet dies mit jeder ffnenden Kante von einer Stelle zur n chsten auch eine schlie ende Kante von der Ausgangsstelle auf sich selbst zu f hren In einem ESD ist ebenso eine Hierarchie der Diagramme mit rekursivem Aufruf vorgesehen Die Conditions im ESD entsprechen denen bei Jacob Aktionen k nnen ber Propagations funktionen ausgef hrt werden Ein entscheidender Unterschied ist jedoch dass Propagations 128 9 0 Koroutinen Konzept von Jacob funktionen in der Regel auf andere Stellen wirken Im ESD werden damit Werte an anderen Stellen belegt und damit gleichzeitig ein Ereignis ausgel st das ggf wiederum andere Ereignisse nach sich zieht Die Wirkung auf die Stelle durch die Propagationsfunktion wird grafisch mit der Darstellung des Stellen bergangs dem die Propagationsfunktion zugeordnet ist angedeutet In gleicher
189. getressource f r die Darstellung eines Ereignisses gesperrt geschlossen oder g nzlich gel scht wird In Java bedeutet letzteres die explizite oder implizite Freigabe zur Garbage Collection 10 2 0 0 Defaultmechanismus zur Abbildung auf Widgetressourcen Annotation Primitive Stelle Zusammengesetzte von Stelle Topstelle Typ Ohne Typangabe I O I O L O I O Wert Kein Wert JPushButton JPushButton JLabel JPushButton JPanel FramedJPanel annotiert Text Name Text Name Text Name Text Name Title Name MouseReleased MouseReleased ValueChanged MouseReleased Mouse Pressed Wert annotiert JPushButton JPushButton JLabel JPushButton JPanel FramedJPanel Text Wert Text Wert Text Wert Text Wert Title Wert MouseReleased MouseReleased ValueChanged MouseReleased Mouse Pressed Werteliste JList JList JList JList JPanel FramedJPanel Item pro Wert Item pro Wert Item pro Wert Item pro Wert Title Name MouseReleased MouseReleased ItemChanged MouseReleased Mouse Pressed Werteliste JList JList JList JList JPanel FramedJPanel Defaultwert Item pro Wert Item pro Wert Item pro Wert Item pro Wert Title Name setSelected setSelected setSelected setSelected Mouse Pressed Default Wert Default Wert Default Wert Default Wert MouseReleased MouseReleased ItemChanged MouseReleased Wertebereich JTextField JTextField JTextField JTextField JPanel FramedJPanel Text Text
190. gs Dies soll durch folgendes Beispiel erl utert werden Ein Druckdialog soll in einem System von jedem Dialogelement aus durch eine bestimmte Tastenkombination ge ffnet werden k nnen Mit exemplarischer Darstellung und Variation l sen wir diese Aufgabe wie folgt Wir zeichnen im Modell von einer einzigen Dialogstelle aus einen ffnepfeil zur Dialogstelle die den Druckdialog repr sentiert und definieren folgende Variation Gegenstand der Variation ist der ffne Pfeil zwischen den beiden Dialogstellen formal gesprochen also ein Stellenpaar aus der ffne Relation RO Als Aspekt der Variation wird wiederum die Anzahl der durch den Pfeil als Exemplar repr sentierten Menge angegeben sowie als weiterer Aspekt die Dialogstelle von der der Pfeil ausgeht Um exakt zu sein meinen wir hier nicht die Stelle selbst sondern eine Referenz auf die Stelle D h wir wollen in diesem Fall nicht die Eigenschaften der Dialogstelle selbst ver ndern sondern nur den Bezug des Pfeils auf die Dialogstelle deren spezifisches Ereignis das ffnen des Druckdialogs ausl st Zu diesem Zweck sehen wir als M glichkeiten der Angabe eines Variationsaspektes die Unterscheidung zwischen Referenz auf die Stelle und Stelle selbst vor Der Unterschied zeigt sich darin dass dann nicht die Stelle von der exemplarisch im Modell der Pfeil ausgeht zur Ver nderung bzw Belegung der Eigenschaften der referenzierten Stelle verwendet wird Die referenzierte Stelle wird als
191. gt auch konkret wie ein Ereignis zur Laufzeit mit Hilfe eines Widgets realisiert wird Wir haben hier also auch eine Abbildung der Ereignisse bzw der Modellstellen auf Laufzeitstellen Hier ist zun chst noch nichts dar ber ausgesagt ob es sich bei den Laufzeitstellen an den Modellstellen um jeweils unterschiedliche Instanzen von Widgets handelt oder ob f r unterschiedliche Modellstellen dieselben Instanzen verwendet werden sollen Mithilfe der formalen Darstellung k nnen wir einen Algorithmus definieren der den oben be schriebenen Dialog zur Laufzeit realisiert Der Algorithmus sei im Folgenden kurz skizziert Kommentar in kursiver Schrift 1 Setze den aktuellen Folgenindex i auf 1 Markiere alle Folgen als aktiv 2 Falls alle Ereignisse im aktuellen Glied i aller aktiven Folgen Ausgabeereignisse 41 4 Bottom up Modellierung und Abstraktion Falls mehrere alternative Ausgabeereignisse in aktuellen Folgegliedern Frage die Applikationslogik welches der Ausgabeereignisse durchzuf hren ist Markiere alle Folgen mit anderen Ausgabeereignissen bzw Modellstellen als nicht aktiv F hre Ausgabe durch Schlie e alle im aktuellen Bild nicht mehr vorkommenden Widgets des Vorg ngerbilds falls vorhanden ffne alle Widgets im zugeordneten Bild falls nicht schon vorher geschehen und gib im gekennzeichneten Widget den Ausgabewert aus Andernfalls Falls alle Ereignisse im aktuellen Glied aller aktiven Folgen Eingabeereignisse Schli
192. h Anfang der achziger Jahre geht die Entwicklung von Techniken Methoden und Werkzeugen zum Entwurf und zur Implementierung im Bereich der computerunterst tzten Software Entwicklung einher Zahlreiche Arbeiten zum Thema Bedienoberfl chen insbesondere unter dem Aspekt der benutzerfreundlichen Gestaltung des Dialogs sind erschienen Die immer noch ansteigende weltweite Nutzung des Internets in den letzten Jahren brachte weitere neue Sprachen und Techniken der Implementierung und mit der Anwendung eines immer gr er werdenden Kreises von Benutzern zunehmende Anforderungen an die Gestaltung und Realisierung der mit dem Internet verbundenen Kommunikationstechniken Neben sogenannte Standalone Anwendungen mit grafischen Oberfl chen realisiert etwa auf Basis von Windows X Windows Java Swing traten immer mehr browsergest tzte Anwendungen mit zun chst primitiven Point and click Oberfl chen Dabei hat die rasante Entwicklung der Basistechnik mit dem Schwerpunkt einer einfachen global g ltigen Definition des Austausches der Information ber allgemein anerkannte Sprachen und Protokolle HTML XML HTTP sowie serverseitige Implementierungstechniken Servlets Active Server Pages ASP JSP die Bem hungen um eine systematische benutzergerechte und auch f r den Entwickler effiziente Modellierung der grafischen Oberfl chen in den Hintergrund gedr ngt Lag der Schwerpunkt der Funktionalit t der angebotenen Entwicklungsumgebungen anfangs
193. hen Dialogobjekte am Bildschirm im sogenannten WYSIWYG Modus erstellt werden k nnen WYSIWYG What You See Is What You Get bedeutet in diesem Falle dass die Objekte durch den Entwickler mithilfe eines entsprechen 14 1 0 Einsatz von Systemen zum Rapid Development den Werkzeuges eines Dialogobjekteditors Screenpainters am Bildschirm bereits so dargestellt werden k nnen wie sie dann sp ter zur Laufzeit also im Echteinsatz ebenfalls f r den Benutzer der Anwendung erscheinen Einzelne Objekttypen werden beispielsweise in sogenannten Toolbars angeboten k nnen dort vom Entwickler ausgew hlt und auf einer Arbeitsfl che mithilfe direkter Manipulation beispielsweise im Drag and Drop Modus zusammengestellt werden Die einzelnen Komponenten bilden dabei eine Hierarchie D h es gibt eine Reihe von sogenannten Container Komponenten in die wiederum Subcontainer oder letztlich primitive Komponenten eingef gt werden k nnen Die einzelnen Objektattribute k nnen zum Teil alternativ zur direkten Manipulation oder in Erg nzung zu dieser mit Hilfe spezieller Attributeditoren in ihren Werten textuell angezeigt erfasst und ge ndert werden Es handelt sich hier zun chst um die Montage statischer Komponenten Statisch sei hier so verstanden dass ein aus Teilkomponenten zusammengestelltes Objekt auch zur Laufzeit mit all seinen Komponenten ber eine bestimmte Zeit existiert Aus Sicht des Benutzers vom Zeitpunkt des ffnens am Bildschirm b
194. hoch dynamisch und generisch zu gestalten Der Entwickler kann die Architektur des Codes weitgehend selbst bestimmen und somit die Dynamik sowie die generischen Eigenschaften der Implementierung optimal steuern Durchg ngig einheitliche verbreitete Sprache Der Grad der Verbreitung der Sprache des Basissystems ist in der Regel gr er als der eines speziellen Upper oder Lower case Tools Dies erleichtert auch dem Management mitunter die Entscheidung f r die direkte Programmierung Zum einen ist dann eine Entwicklungsmannschaft mit dem erforderlichen Know how schneller zu rekrutieren zum anderen ist zu erwarten dass die Wartbarkeit langfristig ohne Abh ngigkeit vom Tool Hersteller gew hrleistet ist 23 1 G ngige Ans tze der Realisierung von Dialogsystemen 1 2 1 Nachteile Die direkte Programmierung hat allerdings entscheidende Nachteile die vor allem aus Gesichtspunkten eines idealen kosteng nstigen Software Engineerings die Entscheidung gegen diesen Ansatz und f r die Verwendung eines Rapid Development Systems oder eines modellbasierten Systems nahe legen k nnen Wenig direkte Transparenz Mit der direkten Programmierung ist in der Praxis die Codierung nach den individuellen Vorstellungen durch die einzelnen Entwickler verbunden es sei denn im Projekt wird auf andere Weise mit Zusatzaufwand f r die Einhaltung einer durchg ngigen Architektur und die Umsetzung eines Konzeptes zur softwaretechnischen Qualit tssicherung geso
195. hrones Lesen durch Applikationskomponente Leseereignisse durchgef hrt durch die Applikationslogik sind ebenfalls Ereignisse die nicht von der Dialogkomponente des Systems sondern von der Applikationslogik ausgel st werden k nnen Sie k nnen ebenfalls als asynchron betrachtet werden wenn der Zeitpunkt des Lesens nicht unmittelbar von der Dialogkomponente bestimmt ist 67 4 Bottom up Modellierung und Abstraktion Asynchrone Benutzereingaben Benutzereingaben sind als asynchrone Ereignisse einzustufen Wir gehen davon aus dass die Eingabe des Benutzers prinzipiell nicht vom Dialogsystem bestimmt werden kann Es liegt grunds tzlich im Ermessen des Benutzers ob und wann er eine Eingabe vornimmt Das System kann eine Benutzereingabe nur insofern steuern als es eine Eingabeschnittstelle zur Verf gung stellt an der die Eingabe dann vom Benutzer get tigt werden kann Das System kann den Benutzer nur insoweit zu einer Eingabe zwingen als es nur eine begrenzte M glichkeit von Eingaben vorsieht und der Benutzer diese begrenzte Anzahl von M glichkeiten nutzen muss wenn er den Dialog fortsetzen m chte Eine derartige Situation liegt im so genannten modalen Dialog vor Eingaben des Benutzers sind also Ereignisse die nicht unbedingt und unwillk rlich einem anderen Dialogereignis nachfolgen Es gibt keinen unausweichlichen deterministischen Zusammenhang zwischen einem Ereignis an der Dialogschnittstelle und einer nachfolgenden Benutzereingabe
196. ie Teile als Teilsichten des Gesamtmodells betrachten k nnen Soll diese Zusammenf hrung vom System durchgef hrt werden ben tigen wir ein Konzept bzw Verfahren das es der Maschine erm glicht die einzelnen Elemente der Teilsichten im Gesamtmodell richtig einzuordnen Prinzipieller Ansatz der Zusammenf hrung ist dass die Darstellungselemente des Gesamtmodells eine Vereinigung aller Darstellungselemente der Teilsichten sind Hier ist nun zu kl ren welche der Elemente der Teilsichten im Sinne des Gesamtmodells als identisch erkannt werden 99 5 Ereignisstellenmodell Dazu ist es notwendig dass vom System erkannt werden kann welche Stellen der Teilsichten mit welchen Stellen in anderen Teilsichten im Sinne des Gesamtmodells identisch sind und wie deren hierarchische Beziehung definiert ist Ausgehend davon k nnen dann die brigen Modellaussagen wie etwa die Relationen der Stellen zum ffnen und Schlie en zugeordnete Ereignismengen etc eingeordnet werden Wir wollen im Folgenden informell skizzieren wie aus den Teilsichten die Menge der Stellen des Gesamtmodells und deren hierarchische Struktur ermittelt werden kann Wie oben bereits erw hnt wollen wir zwei Stellen aus zwei Sichten als identisch definieren wenn ihre Stellenbezeichner gleich sind und ihre in der Hierarchie der jeweiligen Teilsicht bergeordneten Stellen falls vorhanden identisch sind F r Stellen die keine Jokerstellen oder deren Teilstellen sind l
197. iels wurde das Ergebnis der Arbeit mit einigen bekannten Konzepten verglichen und eine Umsetzung der berlegungen in einen Prototypen beschrieben Eine nahe liegende Fortf hrung der Arbeit liegt nun im Ausbau des Prototypen der bisher nur beispielhaft f r eine bestimmte Menge von Java Widgetklassen die Funktionalit t der Modellsprache umsetzt Es ist au erdem ein Konzept zu entwickeln das die Integration der Funktionalit t in bestehende Entwicklungsumgebungen in softwaretechnisch eleganter Form erlaubt Ein m gliches Zielsystem k nnte z B das Eclipse Framework darstellen Der Prototyp ist derzeit auf Basis von Java f r Java Swing Oberfl chen realisiert Das Ereignisstellenmodell ist allerdings nicht auf eine Implementierung mit Java festgelegt Was die Ebene der abstrakten Ereignisstellen betrifft ist es von einer bestimmten Implemen tierungssprache unabh ngig und kann auf verschiedene Dialogarten abgebildet werden Was die Darstellung der konkreten Dialogelemente in den Ereignisstellendiagrammen betrifft ist es zun chst nahe liegend als Implementierungssystem ein Sytem zu w hlen das das Konzept von hierarchisch organisierten Oberfl chenobjekten mit zugeh rigen Attributen und eine Ereignisbehandlung im Sinne des Ereignismodells unterst tzt Ein unmittelbar anstehendes Ziel ist die erfolgversprechende Umsetzung auf HTML basierte Systeme Ein weiteres Ziel ist den Gedanken der Exemplarvariation weiter auszubauen Er wurde in der
198. ien ber Stellenhierarchie Anhang D RadioButton Modell implementiert mit einem und vier Widgets Tabelle Anhang E Formale Darstellung der Exemplarvariation 168 170 174 175 177 Abbildungsverzeichnis Abbildung 1 1 FileSelectionBox Beispiel einer vorgefertigten Dialogkomponente zur Realisierung eines Dialogs mit hohem Anteil an Dialogdynamik 15 Abbildung 1 2 Attribute zur Definition der Dialogdynamik in HTML basierten Systemen am Beispiel Dreamweaver der Firma Macromedia s4usssneneeneneennnnnenneennnnnnnnn 17 Abbildung 1 3 Webseiten bersicht in NetObjects Fusion Grafische Darstellung einer hierarchischen Aufrufstruktur uu shnasesansenee een 18 Abbildung 4 1 Beispiel f r WYSIWYG Modellierung Teil 1 Teil 2 in Abbildung 4 2 39 Abbildung 4 2 WYSIWYG Beispiel Teil2 Fortsetzung von Abbildung 4 1 40 Abbildung 4 3 Beispieldialogfolgen als Pfade eines Baums in einem Grafen 44 Abbildung 4 4 Zusammenf hrung identischer Folgen bzw Stellen 46 Abbildung 4 5 Das Beispiel des Installationsdialogs wird um einen Dialog zur Auswahl eines La fwerks erweitert a ee ne ee 47 Abbildung 4 6 Zusammenf hrung der beiden Darstellungen des Laufwerksdialogs mit anschlie ender historienabh ngiger Verzweigung unnsennnnnenenneenennnnennnnnen 48 Abbildung 4 7 Graf zur Darstellung des Dialogablaufs eines
199. ig fixierten einzigen Ablauf des zu realisierenden Dia logs gibt bedeutet dies die explizite Darstellung aller m glichen alternativen Dialogfol gen sprich das Aufzeigen aller in unserem obigen Grundmodell definierten Folgen b Darstellung der Ereignisse an den realen Dialogstellen WYSIWYG bedeutet auch eine Darstellung des Dialogs so wie er sich tats chlich zur Laufzeit visuell akustisch taktil darstellt Nach unserem Grundmodell bedeutet dies eine konkrete Darstellung aller Dia logstellen und der Ereignisse an ihnen d h die Abbildung des Dialogs mit realen auch zur Laufzeit verwendeten Ressourcen Ansatz 1 Explizite Darstellung der Dialogdynamik in echt zeitlicher Abwicklung Im Extremfall der Bottom up Vorgehensweise d h in einer u erst konsequenten L sung der Aufgabe den Dialog bei der Modellierung bereits laufzeit hnlich darzustellen muss nicht nur das statische Aussehen der Dialogstellen sondern auch das dynamische Verhalten der Schnittstelle m glichst explizit und konkret dargestellt werden 34 4 Bottom up Modellierung und Abstraktion Der Extremfall bedeutet Wir nehmen unser Endprodukt n mlich die Darstellung des Dialogs zur Laufzeit als unser Modell Hier bei t sich prinzipiell die Katze nat rlich in den Schwanz In den meisten F llen ist der Dialog so wie er sich zur Laufzeit darstellen soll nicht fertig vorhanden Wir wollen ihn ja gerade erst definieren Aber wir k nnen uns diesem Extremfall
200. iger komplexe Funktionen und Speicherstrukturen in der Art von Schaltpl nen dargestellt werden Vergleich Interaction Diagram mit ESD Mit den Darstellungselementen eines Interaction Diagrams sind keine einfachen WYSIWYG orientierten Darstellungen einer grafischen Dialogoberfl che m glich Dies liegt z B neben anderen Eigenschaften eines Interaction Diagrams daran dass eine detaillierte Darstellung der Interaktion n mlich eine Darstellung sowohl des Sendens als auch des Empfangens eines Datums ber einen Port vorgenommen wird Dies f hrt bereits zu drei Stellen im Diagramm die mit Pfeilen verbunden sind In einem ESD wird dagegen f r die Darstellung der Interaktion zwischen Mensch und Maschine in der Regel eine Stelle ben tigt die mit den 141 9 Vergleich mit bekannten Ans tzen entsprechenden Typen f r Eingabe Ausgabe oder beides versehen wird Was die Interaktion zwischen Komponenten auf der Maschine betrifft resultieren die Bez ge zwischen diesen in einem ESD in den Pfeilen die ein ffnen Schlie en oder die bertragung eines Wertes kennzeichnen Auch hier werden nur zwei Stellen n mlich Quelle und Ziel ben tigt Auf die Darstellung eines Ports wird verzichtet Sind die beiden Stellen Dialogstellen der Oberfl che entsprechen diese in der Regel den Stellen die auch in der sp teren Konkretisierung als grafische Elemente am Bildschirm erscheinen nat rlich vorausgesetzt wir bilden auf eine grafische Oberfl che und ni
201. ignis des Widgets zugeordnet ist Dies setzt wiederum voraus dass das im Modell definierte ausl sende Ereignis auf ein entsprechendes Ereignis des Widgets abgebildet werden kann 107 6 Abstraktion vom konkreten Widget ffnen und Schlie en von Teilstellen Gehen wir davon aus dass die Einwirkung von anderen Dialogstellen auf das Modell des RadioButtons nur so erfolgen soll dass die charakteristische Funktionsweise des Modells dadurch nicht zerst rt wird Als sinnvolle Einflussnahme auf Teilstellen verstehen wir dann a eine nderung des Zustands von An nach Aus oder umgekehrt b die Eingabe f r den Benutzer zu sperren Im Folgenden sollen beide F lle bez glich Darstellung im Modell und bez glich Implementierung behandelt werden nderung des Zustands An bzw Aus 1 Darstellung im Modell Im Modell bedeutet dies berg nge von der angenommenen anderen Dialogstelle zum ffnen und Schlie en aller vier Teilstellen des RadioButtons zu definieren die mit entsprechenden Bedingungen Conditions versehen sind Die Conditions sind dabei ggf unter Einsatz von Hilfsstellen so formuliert dass sie den aktuellen Wert des RadioButtons pr fen und abh ngig davon die entsprechenden Stellen ge ffnet bzw geschlossen werden 2 Implementierung In der Implementierung mit der Instanz der Widgetklasse JRadioButton bedeutet nun wiederum das ffnen und Schlie en der Stellen lediglich ein Umsetzen des Zustandes des Radi
202. ignisse LoadingJob Ready Ready O auf konkrete Ereignisse der Implementierung noch nicht realisiert ist Stattdessen m ssen im Prototyp pro Teilstelle eigene Variationen definiert und als Ereignis ein konkretes Ereignis des zur Implementierung verwendeten Widgets angegeben werden Z B kann dort als Ereignis das Metaereignis Open f r die Stelle Ready angegeben werden 8 2 4 Zuordnung konkreter Laufzeitstellen Das obige Diagramm macht abgesehen von den WYSIWYG dargestellten Dialogen keine explizite Aussage wie die Modellstellen in konkrete Laufzeitstellen umzusetzen sind Ob es sich also z B bei der Auswahl der Operationen im SelectOperations Dialog etwa um einen Kommandodialog handelt der auf einer Kommandozeile die Eingabe eines Kommandos durch den Benutzer erm glicht oder ob es sich um ein grafisches Panel mit einer Gruppe von Buttons oder gar einen Baum zur Selektion per Mausklick handelt ist offen Eine Konkretisierung kann nun erfolgen indem Information zur Abbildung auf eine konkrete Laufzeitstelle der Modellstelle zugeordnet wird Im realisierten Prototypen geschieht dies zum einen durch die Annotation einer in Java implementierten Klasse Dies bedeutet zun chst dass zur Laufzeit eine oder mehrere Instanzen der Klasse erzeugt werden Zum anderen geschieht dies durch Zuordnung von Variationsinformation ber die Anzahl der zu erzeugenden Instanzen siehe oben Kardinalit tsvariation Mithilfe einer Variationsannotation k
203. ignisse an der Ereignisstelle eingef gt Code in Konstruktoren Grunds tzlich beinhalten Konstruktoren den Code der unmittelbar mit dem Kreieren einer Stelle verbunden werden kann Z B kann ein Konstruktor Code zum ffnen einer Teilstelle ffnen verstanden im Sinne des formalen Ereignisstellenmodells nur beinhalten wenn diese als Startstelle definiert ist Im anderen Fall kann die Teilstelle allenfalls als Instanz erzeugt aber noch nicht sichtbar oder sensitiv gesetzt werden Die Konstruktoren beinhalten gegebenenfalls Aufrufe zur Erzeugung der Instanzen der Teilstellen das Setzen von Startwerten f r das der Stelle zugeordnete Widgetattribut entsprechenden Code zur Realisierung einer Widgetressource z B ListItem Code zum Sichtbarmachen der Teilstellen Code zum sensitiv Setzen der Teilstellen und die Aktivierung von Listenerinstanzen Listenerklassen zur Realisierung der Stellen berg nge Grob gesehen implementiert in der Regel eine Listener Klasse den Code der einem Pfeil zum ffnen Schlie en oder zur Wert bertragung ggf kombiniert mit ffnepfeil in einem Ereignisstellendiagramm entspricht Die Listener Klassen beinhalten Methoden zur Reaktion auf bestimmte Ereignisse In diesen Methoden k nnen hnliche Codesequenzen generiert sein wie dies in Konstruktoren der Fall ist D h es werden dort ebenfalls z B Instanzen anderer Stellen erzeugt und ge ffnet die dann allerdings in der Regel keine Teilstelle
204. im Allgemeinen auch Ausgabeereignisse Dabei beinhalten die Ausgabeereignisse oft nur den Benutzer unterst tzende Information die auf die m gliche Eingabe hinweist Prompting Abh ngig von der verf gbaren Stellenmenge im Modell k nnen wir die Ereignisse auf die Stellen aufteilen Mittels einer Vorschrift werden die Ereignisse und Stellen des Modells dann auf Ereignisse und Stellen zur Laufzeit bertragen d h die Laufzeitstellen mit ihren Ereignissen werden realisiert Wird zur Laufzeit f r jedes Ereignis ein eigenes Widget verwendet haben wir eine bijektive Abbildung der Laufzeitstellen auf die Modellstellen Wird ein Widget zur Laufzeit f r mehrere Ereignisse hintereinander verwendet d h finden an ein und derselben Laufzeitstelle hintereinander mehrere Ereignisse statt zeichnen wir dasselbe Widget an mehreren Modellstellen da wir ja bis jetzt jedenfalls jedes Ereignis einer eigenen Modellstelle zuordnen Wir haben in diesem Fall eine redundante Darstellung der Laufzeitstellen im Modell und es wird notwendig eine Zuordnung von Modellstellen auf Identit ten von Laufzeitstellen vorzunehmen Wir haben dann eine surjektive Abbildung der Ereignisstellen im Modell auf die Ereignisstellen zur Laufzeit Dazu ein Beispiel zur Laufzeit kann generell innerhalb einer Applikation ein und dasselbe Textwidget f r Fehlermeldungen verwendet werden Jede Fehlermeldung stellt ein Ausgabeereignis dar das auf demselben Widget passiert Im Modell habe
205. in der Unterst tzung der Realisierung der Dialogoberfl che UIMS Systeme so konzentrierte sich in letzter Zeit der Mehrwert neuer Freigaben sogenannter integrierter Entwicklungsumgebungen Integrated Development Environments auf Aspekte der Verteilung von Anwendungen im Netz etwa auf der Grundlage standardisierter Software Architekturen Stichwort J2EE net Application Server EJB Erwiesen sich bereits in der Vergangenheit zahlreiche Dialoganwendungen stand alone wie auch im Client Server Betrieb als relativ komplex d rfte die Komplexit t des Dialogs bei Internetanwendungen mit immer gr erem Spektrum der Anwendungen ebenso zunehmen Umso mehr ist es erforderlich Verfahren Techniken und Werkzeuge anzubieten die es erlauben unabh ngig von den sich relativ schnell ndernden Basistechniken der Implementie rung ein benutzerkonformes anwendungsgerechtes und logisches Design der Bedienober fl che durchzuf hren Nicht zuletzt unter dem Druck immer k rzerer Entwicklungszyklen je doch soll mit dem Entwurf der logischen Dialogoberfl che f r den Entwickler eine effiziente schnelle und komfortable Umsetzung in die jeweils aktuelle Implementierungstechnik m glich sein Die Vergangenheit zeigt dass bei Entwicklern und Managern von IT Projekten eine prinzipielle Bereitschaft existiert zur Steigerung der Produktivit t und Qualit t Werkzeuge f r Design und Implementierung grafischer Dialogsysteme einzusetzen Anf ngliche
206. in einer Modellstelle eine Menge von Ereignissen zusammengefasst sein kann die ihre Darstellung zur Laufzeit in verschiedenen Instanzen von Widgets finden Zum anderen ist wesentlich dass ein und dieselbe Stelle durch unterschiedliche Typen von Widgets konkretisiert werden kann Wesentlich ist letztlich auch dass eine Stelle tats chlich eine Abstraktion darstellt die nicht unbedingt auf ein Widget im engeren Sinne verstanden als Element eines bestimmten Widget Toolkits abzubilden ist Dialogstellen sind auch in nicht grafischen zeichen und zeilenorientierten Dialogarten wie z B Kommandodialog oder Men dialog zu erkennen Die Implementierung letzterer Dialogarten muss nicht notwendigerweise mit grafischen Toolkits unter Verwendung von Widgets erfolgen 6 1 Abbildung der Ereignisstellen auf konkrete Widgets Wir wollen die eben erw hnte Tatsache dass eine Stelle durch unterschiedliche Typen von Widgets konkretisiert werden kann in diesem Abschnitt anhand des Beispiels der Abstraktion eines RadioButtons in einem ESM erl utern Ein RadioButton unterst tzt die Eingabe zweier Werte n mlich An und Aus oder gedr ckt und nicht gedr ckt bzw true und false Die Eingabe wird f r den Benutzer visualisiert und steht f r das System zur Abfrage zur Verf gung Au erdem kann der Button auch vom Programm aus gesetzt werden Eine Besonderheit des RadioButtons ist dass die gleiche Eingabeaktion des Benutzer
207. inden die es erlaubt eine logische Darstellung der Dialogoberfl che in m glichst intutitiver Form zu finden Die Darstellung sollte den Designer wie auch den sp teren Systembenutzer bereits in einer fr hen Entwurfsphase unterst tzen und es sollte andererseits eine rasche Umsetzung des Entwurfs in ein ablauff higes System erm glicht werden Dabei sollte insbesondere der dynamische Aspekt der Oberfl che ber cksichtigt und ein berblick ber die statische und dynamische Struktur des Dialogs gew hrleistet werden Nachteile und M ngel bekannter Ans tze sollten dabei beseitigt werden Nach einer Diskussion dieser Ans tze wurde zun chst ein Grundmodell zum allgemeinen Verst ndnis des Dialogs entwickelt das als Basis der dann folgenden berlegungen diente Um eine m glichst einfache intuitive Darstellung zu ermitteln wurde im Bottom up Ansatz ausgehend von einer rigorosen extensiven Darstellung der Dialogereignisse zu intensiveren Darstellungsformen bergegangen Ergebnis ist ein Ereignisstellenmodell mit zugeh rigen grafischen Darstellungselementen des Ereignisstellendiagrammes Um die Variabilit t komplexer Anwendungen ausdr cken zu k nnen wurde das ESM um das Konzept der Exemplarvariation erweitert die es erlaubt die einfache grafische Darstellung mit der M chtigkeit g ngiger Programmiersprachen zu verbinden wobei die Anbindung in einer weitgehend deskriptiven Form erfolgt Nach der Erl uterung anhand eines konkreten Beisp
208. ion A A1 f r E A2 ben tigt wird Entscheidend ist nur dass bei Start der Aufgabe Al die Eingabe zur Verf gung steht Der Zeitpunkt der Informationseingabe zur Durchf hrung der Aufgabe kann aber vom Start der eigentlichen Durchf hrung der Aufgabe entkoppelt sein Beispiel2 Al dauert l nger als A2 Dann ist A2 nicht notwendig logisch von Al abh ngig aber dennoch ist es evtl aus Performanzgr nden sinnvoll Al eher zu starten als A2 Es macht dann auch Sinn E Al vor E A2 zu erledigen Wir wollen unser obiges Beispiel der Auftragserfassung ausweiten und erlauben dass der Mitarbeiter der einen Auftrag erfasst auch alternativ zur automatischen Preisberechnung den Preis selbst festlegen kann der Preis aber anschlie end vom System auf Plausibilit t gepr ft werden soll Dann ist zun chst die Reihenfolge der Eingabe von Preis Leistungs und Kundendaten irrelevant Und zwar ist sie irrelevant dann wenn die Pr fung des Preises durch das System von der Eingabe der Preisdaten durch den Benutzer entkoppelt ist und das Lesen der Preisdaten durch die Applikationslogik erst zu einem sp teren Zeitpunkt durchgef hrt wird Zum Zeitpunkt der Pr fung der Preisdaten m ssen dann zus tzlich die Leistungsdaten und die Kundendaten des Auftrags vorliegen Erst dann kann die entsprechende Buchung des Auftrags vorgenommen werden Wir haben in diesem Beispiel also eine Trennung der Eingabenzeitpunkte von den Zeitpunkten des Lesens und der Verarbeitung de
209. ionsfunktion zur Bestimmung der Anzahl und Identit t nicht nur zum angegebenen Variationszeitpunkt sondern auch zu anderen Zeitpunkten aufgerufen wird Letztlich liegt es dann bei der Implementierung der Methoden getCardinality und getObjectld ob sich die Menge der Instanzen nur zum definierten Zeitpunkt der Variation oder auch zu anderen Zeitpunkten ndert Der Zeitpunkt kann u a durch das mitgegebene Ereignis erkannt werden F r eine Variation des Aspektes Identit t ohne Variation der Kardinalit t er brigt sich der Aufruf der Methode getCardinality Zur Bestimmung der Objectld wird eine Methode getObjectld ohne Index als Parameter verwendet 160 10 2 Schritte zur Codegenerierung Variationsfunktionen anderer Aspekte F r die Variation weiterer Aspekte existieren ebenfalls entsprechende Schnittstellen methoden die wiederum in der Modelklasse des Modelobjektes erwartet werden das per Aufruf von getModel siehe oben zum Variationszeitpunkt referenziert wird Als Beispiel seien hier die Methoden Size getSize String variationName String locationName Event e und Size getSize int index String variationName String locationName Event e genannt die bei Variation des Aspektes Size in den F llen ohne Variation der Kardinalit t bzw mit Variation der Kardinalit t verwendet werden 161 11 Zusammenfassung und Ausblick 11 Zusammenfassung und Ausblick Ziel der Arbeit war eine Modell Darstellung eines Dialogsystems zu f
210. irksam wird Hierbei ist zu verstehen dass es bei einem Dialogsystem um ein zeitlich sich ver nderndes System handelt und die Darstellung eines Exemplares die Darstellung eines Objektes im System zu einem bestimmten Zeitpunkt bedeuten kann D h das Exemplar repr sentiert eine Moment aufnahme im System Die Variation besteht dann in der Ver nderung dieses Exem plars bzw bestimmter Aspekte des Exemplares zu verschiedenen Zeitpunkten w h rend des Ablaufes der Anwendung Das Exemplar variiert innerhalb der Laufzeit einer Anwendung fortlaufende dynamische Variation In einem anderen Fall kann die Variation verstanden werden als die einmalige Abwandlung und der einmalige Aus tausch eines Exemplares im Modell gegen eine Variante des Exemplares f r eine aktu elle Anwendung die ber die gesamte Dauer der Anwendung anh lt Es handelt sich dann um eine Variantenbildung pro Anwendung in gewissem Sinne um eine stati sche Variation des Modellexemplares Letztere berlegung f hrt zu einem weiteren Kriterium zur Beschreibung der Varia tion das wir gesondert hervorheben k nnen n mlich den Zeitpunkt bzw das Ereignis zu dem die jeweilige Variation entschieden werden kann d h zu dem die konkreten Variationsergebnisse oder Varianten berechnet werden k nnen Dabei k nnen zwei Extremf lle unterschieden werden in einem Fall wird die Variation unmittelbar zu dem Ereignis entschieden zu dem dann auch die Variation stattfindet und zwar
211. is zum Schlie en aus Sicht des Programms vom Zeitpunkt des Kreierens des Objektes bis zum L schen aus dem Arbeitsspeicher oder einem Sekund rspeicher Allerdings steckt implizit in vielen der so definierten Objekte bereits dynamisches Verhalten siehe unten 1 0 1 Darstellung der Dynamik 1 0 1 0 Dynamik in vorgefertigten Komponenten Implizit ist in vielen der im Dialogobjekt Editor vorgegebenen Objekte bereits dynamisches Verhalten enthalten Dieses wird jedoch eben nicht explizit gesondert beim Aufbau der Kom ponenten angegeben sondern steckt bereits von vorne herein in der Definition der vorgegebe nen Komponente Dies gilt f r dynamisches Verhalten einzelner primitiver Objekte im Detail Mikrodialog z B bei einem editierbaren Textfeld wie f r Dynamik in amp ffnen L Eigene Dateien Arbeitsplatz EZ d Bei amp I AUTOEY ar IC I CONFIG Gemeinsame Dokumente C Satorpa 3 CD RW Laufwerk D 2 N INSTAL DVD Laufwerk E Lokaler Datentr ger F pagene Dateiname Dateitypen Alle Dateien v ffnen Abbrechen Abbildung 1 1 FileSelectionBox Beispiel einer vorgefertigten Dialogkomponente zur Realisierung eines Dialogs mit hohem Anteil an Dialogdynamik 15 1 G ngige Ans tze der Realisierung von Dialogsystemen zusammengesetzten Komponenten Makrodialog z B bei einer Kombobox oder besonders bei einer bereits komplett vorgefertigten Komponente zur Dateiau
212. ische Sicht des Benutzers auf die Aufgabenstellung die durchzuf hrenden T tigkeiten und die zu bearbeitenden Informations Objekte beschrieben Entsprechend sind bei der Erarbeitung des logischen Dialogmodells die bekannten Forderungen der Softwareergonomie nach Aufgabenangemessenheit und Erwartungskonformit t zu ber cksichtigen Einordnung logischen Dialog in semantische Ebene des Schichtenmodells nach Foley Das Sprachenmodell von Foley FOLEY74 unterscheidet nach einer konzeptuellen semantischen syntaktischen und lexikalischen Ebene in der die Realisierung eines Dialogsystems beschrieben werden kann Wenn wir von dieser Schichtung durch Foley ausgehen ist ein logisches Dialogmodell am ehesten der semantischen Ebene zuzuordnen Erst in einer darunter liegenden Schicht wird die Art des Dialogs der Dialogstil festgelegt In der konzeptuellen Ebene wird die Aufgabenstellung des Systems gekl rt Hier werden die Leistungen Funktionen des zu erstellenden Systems beschrieben Es wird definiert was das Anwendungsprogramm zu tun hat Die konzeptuelle Ebene spiegelt das Benutzermodell vom System wider Es wird keine Aussage ber das Wie der Realisierung gemacht In der semantischen Ebene wird eine Detaillierung dahingehend vorgenommen dass Informationseinheiten definiert werden die zwischen System und Benutzer auszutauschen sind Die semantische Ebene kennt die Systemfunktionen die f r die Bedienoberfl che relevant sind und im Dialog ange
213. isierung mit vier Instanzen Das Modell des RadioButtons l t sich auch mit zwei Instanzen der Klasse JButton und zwei Instanzen der Klasse JLabel realisieren Jede der vier Modellstellen wird dabei auf jeweils eine eigene Widget Instanz abgebildet F r die Ausgabe der Information Aus bzw An verwenden wir die beiden Widgets der Klasse JLabel Dabei werden in unserem Beispiel in jedem Label die Werte Aus bzw An auf zwei Icons eine leuchtende und eine nicht leuchtende Lampe abgebildet Das ffnen und Schlie en der Modellstellen S und S2 w rde bei einer Standardimplementierung durch sichtbar machen bzw unsichtbar machen der beiden entsprechenden Widgets erfolgen Alternativ dazu w hlen wir hier jedoch die nderung der beiden Icons des jeweiligen Labels Die Eingabeereignisse An und Aus realisieren wir diesmal mit zwei Buttons der Klasse JButton und den zugeordneten Ereignissen vom Typ Mouse click Dabei werden gem Standardimplementierung die logischen Eingabewerte ber den Text der Buttons im Beispiel der Abbildung in der englischsprachigen Variante On und Off visualisiert Stelle Ereignis Widget Ereignis Attribut Operationen abstrakt konkret Typ Wert Klasse Instanz ID Typ Typ Name Wert ffnen Schlie en So I An JButton OnButton Mausklick Widget Widget kreieren insensitiv sichtbar setzen oder setzen unsichtbar sensitiv setzen oder setzen l schen
214. isse erzeugt werden h ngt vom Typ der zugeordneten Ereignisse ab Die explizite Typzuordnung ist in obigem Diagramm an den entsprechenden Annotationen I f r Eingabe O f r Ausgabe M f r Schreibereignis an Hilfsstelle O f r Stelle mit Eingabe und Ausgabeereignissen zu erkennen Der Prototyp in dem oben dargestelltes Diagramm editiert wurde realisiert auch eine implizite Zuordnung im Rahmen der Codegenerierung So werden primitive Ereignisstellen prinzipiell mit dem Typ Eingabe belegt bei Wertzuweisung zus tzlich mit dem Typ Ausgabe Der durch die Selektion im Dialog JobSelection ermittelte Wert wird in der Ereignisstelle JobName repr sentiert Um einen sinnvollen Wert an der Stelle ablesen zu k nnen setzen wir voraus dass entweder eine Eingabe an der Stelle durch den Benutzer erfolgt ist oder das 122 8 2 Erl uterung und Diskussion des Beispiel Diagramms System ein Ausgabeereignis durchgef hrt hat Wir k nnen die Stelle also mit dem Ereignistyp T O versehen In unserem Modell wird es sicher Sinn machen Ready als reine Ausgabestelle zu kennzeichnen Denn das Ereignis Ready signalisiert den Abschlu des Ladevorgangs und die Bereitstellung der Daten eines Jobs durch die Applikationslogik zur nachfolgenden Darstellung an der Dialogschnittstelle Ebenso wird die Teilstelle CurrentJobName mit dem Namen des aktuell geladenen Jobs belegt CurrentJobName ist also notwendigerweise mindestens eine Ausgabestelle Ob es gew nscht
215. kationslogisch oder dialogtechnisch gesehen erforderlich ist Diese Frage hat sich teilweise in der bisherigen Darstellung unseres Grundmodells durch die Gleichsetzung des Begriffs Dialogschritt mit dem Begriff Dialogereignis beantwortet Denn der Ansto eines Dialogschritts aufgrund eines Ereignisses ist begrifflich bereits auf den Ansto eines Dialogereignisses durch ein anderes Dialogereignis zur ckgef hrt Der Dialog setzt sich also im Wesentlichen in unserem Modell ausschlie lich aus einer Folge von Ereignissen die in gleicher Weise auch als Aktionen gesehen werden k nnen zusammen Wird die Modellsprache dazu verwendet um tats chlich durchgef hrte Dialoge lediglich zu protokollieren sind die Ereignisse die einen Dialogschritt ausl sen die aber selbst keine Dialogschritte sind nicht unbedingt zur Darstellung n tig Es kann auch ausreichen nur die durchgef hrten Dialogschritte ohne die ausl senden Ereignisse bzw die ausl senden Ursachen darzustellen Ebenso k nnen die ausl senden Ereignisse fehlen wenn nur prinzipiell d h ohne Betrachtung der Bedingungen Ereignisse potentiell m gliche Dialogschritte aufgezeigt werden sollen F r den Benutzer wie f r den Modellierer kann es sinnvoll sein den potentiellen bergang von einem Dialogschritt zum anderen im berblick darzustellen ohne dabei zun chst die Bedingungen Ereignisse bzw Aktionen die diese berg nge bewirken aber au erhalb der Dialogschnittstelle liegen zu zei
216. kkustische Ausgabe ber Lautsprecher und Eingabe ber Mikrophon Neben diskreter Ausgabe einzelner grafischer Objekte tritt der Einsatz von Bildanimation und die filmische Darstellung Widget Unter Widget wird in dieser Arbeit im allgemeinen Sinne jegliches Objekt einer grafischen Dialogoberfl che verstanden wie es in mehr oder weniger unterschiedlichen Auspr gungen in Baukastensystemen Toolkits zur grafischen Dialoggestaltung zur Verf gung steht Im engeren Sinne kann ein Widget als eine Instanz einer Widgetklasse bekannt aus auf X Windows aufsetzenden Systemen wie dem Xt Toolkit System verstanden werden In dieser Arbeit sind damit beispielsweise auch die Objekte anderer Baukastensysteme wie z B Java Swing etc gemeint WYSIWYG Darstellung WYSIWYG steht f r what you see is what you get und wurde urspr nglich f r die exakte Wiedergabe der Ausgabe des Drucker auf dem Bildschirm gepr gt Ein erweitertes Verst ndnis des Begriffes wie er in dieser Arbeit verwendet wird bedeutet eine m glichst laufzeitgetreue Abbildung von Dialogobjekten und Dialogabl ufen in einem Editor in der Phase des Dialogentwurfs 164 13 Literaturverzeichnis 13 Literaturverzeichnis BALZE94 BASTI90 BOOCHO1 CYPHE91 DINSS EICKEL90 EICKEL91 EICKELO1 EISENO0 EISENO1 FAEHNS5 FAEHNS7 FISCHE00 FOLEY74 FOLEY90 Balzert H Das JANUS System Automatisierte wissensbasierte Generierung von Me
217. komponenten Dabei l sst sich das System in zwei Bereiche aufteilen n mlich in einen Bereich der unmittelbar f r die Realisierung des Dialogs verantwortlich ist also die Dialogschnittstelle realisiert und unmittelbar den Kontakt zum Benutzer herstellt Dialogkomponente und einen Bereich der mittelbar ber diese Dialogkomponente als Dialogpartner kommuniziert den wir h ufig auch als Applikationslogik Komponente oder Systemlogik Komponente bezeichnen ein Teil der die eigentlichen und oder nicht dialogspezifischen dem EDV System zugedachten Aufgaben im Sinne der Gesamtapplikation oder des Gesamtsystems Mensch Maschine realisiert Dialogstil Dialogstil wird manchmal im Sinne von Dialogart siehe oben gesehen Im Zusammenhang mit grafischem Dialog kann der Begriff Dialogstil aber auch verstanden werden als eine Sammlung von Darstellungsattributen die die grafische Ausgestaltung bestimmen So kann beispielsweise die Wahl eines bestimmten Zeichensatzes f r bestimmte Abschnitte oder die Wahl einer Bestimmten Hintergrundfarbe einem bestimmten Dialogstil zugeordnet werden Formulardialog Dialogart in der Eingaben und Ausgaben berwiegend in Formularen mit Formularfeldern durchgef hrt werden Ein Formulardialog setzt eine Bildschirmfl che Gesamtbildschirm oder Fenster voraus auf der ein Formular mit mehreren Feldern gleichzeitig dargestellt werden kann sowie einen Mechanismus der den Eingabefokus in vorgegebener Reihenfolge oder beliebig
218. konkretes Dialogobjekt eine bestimmte Widgetklasse f r die Realisierung des Dialogs festzulegen Dies birgt die Gefahr in sich dass der Entwickler sich auf Implementierungsdetails konzentriert bevor berhaupt wichtige logische Aspekte des Dialogs gekl rt sind H ufig muss dann mit der Implementierung von neuem begonnen werden wenn eine auch nur leichte Korrektur auf der Ebene der logischen Anforderungen an die Funktionalit t des Dialogs n tig wird Z B erfordert die nachtr gliche Erkenntnis dass an einer Stelle im Dialog mit einer variablen Anzahl von Werten statt mit einer fixen Anzahl zu rechnen ist in vielen F llen die Wahl einer neuen Widgetklasse und damit das Verwerfen der kompletten Implementierung Das Widget muss u U anders kreiert werden Werte m ssen mit anderen Funktionen gesetzt und abgefragt werden usw Fehlende Flexibilit t bei Umsetzung auf andere Dialogstile Dialogarten Die sofortige Festlegung auf konkrete Dialogobjekte bereits in einer fr hen Phase der Entwicklung erzwingt die fr he Wahl eines bestimmten Dialogstils bzw einer bestimmten Dialogart Eine automatische Umsetzung wird durch Rapid Development Systeme wenn berhaupt nur insofern unterst tzt dass ggf eine Transformation in ein anderes Basissystem der Implementierung und oder in ein anderes Look and Feel z B von Motifzu Windows gewechselt werden kann Eine Umsetzung in unterschiedliche Dialogarten etwa ein Wechsel von grafischem Dialog in Kom
219. l eine Abh ngigkeit zwischen Frage und Antwort besteht die im Normalfall eine zeitliche Abh ngigkeit definiert Wir finden diese Eigenschaft jedoch bei einer Reihe anderer Dialogarten wie zum Beispiel dem Kommandodialog bei dem der Benutzer den Auftrag erteilt das System den Auftrag ggf best tigt erf llt und schlie lich mit dem Ergebnis des Auftrags antwortet Generell k nnen wir vielleicht sagen dass zun chst ein Problem von einem der Dialogpartner formuliert wird und der andere Partner mit der Probleml sung antwortet Dies gilt z B insbesondere auch f r Information Retrieval Systeme bei denen der Benutzer eine Suchfrage stellt und das System Information zur Suchfrage ausgibt hnliches gilt f r ein Kalkulator Programm in das der Benutzer eine Rechenformel mit Parametern eingibt und das Programm mit dem errechneten Ergebnis antwortet usw Wir k nnen nun die Frage stellen inwieweit diese Abh ngigkeit zwischen Frage und Antwort eine logisch notwendige Abh ngigkeit darstellt die immer die zeitliche Reihenfolge zwischen Formulierung des Problems und Darstellung der Probleml sung erfordert Denn wir k nnen uns z B auch vorstellen Problemstellung und Probleml sung gleichzeitig darzustellen Gelingt uns dies so kann sich der Benutzer dieses so gestalteten Systems die Fragestellung an das System sparen Er kann die Probleml sung unmittelbar neben der formulierten Problemstellung ablesen Denken wir z B an eine Tabelle mit den wich
220. l auf wenn wir zusammengesetzte Stellen im Modell nicht mehr weiter detaillieren wollen und der zusammengesetzten Stelle zur Implementierung direkt ein Widget zugeordnet wird das mehrere Ereignisse repr sentiert siehe unten im Anschluss Kap 6 Wir bringen dazu am ffne oder Schlie epfeil eine Annotation einer Ereignismenge siehe oben Annotation der Triggerereignisse an der wir im Gegensatz zur Annotation von Triggerereignissen ein ZE lt Zielereignismenge voranstellen Au erdem wird die Annotation in N he der Zielstelle positioniert 95 5 Ereignisstellenmodell 5 3 2 Modellsichten 5 3 2 0 Zielsetzung Im vorangegangenen Abschnitt haben wir gezeigt wie ein Ereignisstellenmodell ESM in einem Ereignisstellen Diagramm ESD mit grafischen Elementen spezifiziert werden kann Wir haben dabei die einzelnen Sprachelemente der formalen Darstellung des ESM den Sprachelementen eines ESD gegen bergestellt In vielen F llen in der Praxis ergibt sich dass trotz der bisher vorgestellten M glichkeiten einer komprimierten Darstellung eine vollst ndige Spezifikation in einem einzigen ESD zu komplex und damit un bersichtlich w rde Beispielsweise gehen wir bisher noch davon aus dass eine zusammengesetzte Stelle alle ihre Teilstellen beinhaltet Wir wollen im Folgenden ein Konzept diskutieren das die Aufteilung der Modellinformation in so genannte Modellsichten erm glicht Dies ist ein Ansatz der nicht nur die hierarchische St
221. l von der Synchronisation mit anderen Prozesskomponenten ab Hier ist der Ansatz im Pi Kalk l rigoroser durchg ngiger als im ESM wo auf Conditions und Propagationsfunktionen die in einer g ngigen Programmiersprache zu schreiben sind die Entscheidung f r die Fortsetzung ausgelagert wird Allerdings tr gt dieser konsequente Ansatz im Pi Kalk l nicht zu einer einfachen Realisierung und bersichtlichen Darstellung bei Im ESM ist bewusst die Auslagerung komplexer Vorg nge auf Funktionen einer g ngi gen m chtigen Programmiersprache gew hlt um die bersicht in einer Diagrammdarstellung zu vereinfachen und um die Programmierung in einer gewohnten m chtigen Sprache zu erm glichen hnliche berlegungen gelten wenn wir das Sprachelement der Replikation im Pi Kalk l mit dem Variationskonzept im ESM bzw in der Erg nzung zum ESM vergleichen Die Flexibili t t die durch die Replikation ausgedr ckt werden kann ist in einem ESD weitgehend in die Annotation von Variationsinformation ausgelagert F r die Replikation gibt es im ESM ohne Variation was dem grafischen Anteil der Darstellung im ESD entspricht kein eigenes Sprachelement Der new Operator des Pi Kalk ls entspricht weitgehend der Erzeugung einer neuen Instanz Auch hierf r gibt es im ESM ohne Variation selbst kein entsprechendes Sprachelement Welche Menge von Instanzen einer Stelle in der Implementierung zugeordnet werden wird ebenfalls ber textuelle Variationsinfor
222. larvariation Mit Hilfe der exemplarischen Darstellung von Dialogen in Ereignisstellendiagrammen und der M glichkeit mit zus tzlichen Sprachelementen die dynamische Variation der Dialoge zu beschreiben wird das Ereignisstellenmodell in seiner M chtigkeit wesentlich erweitert Kapitel 8 beschreibt ein Modellbeispiel aus der unmittelbaren Praxis des Autors im Abriss und zeigt den Einsatz der vorher vorgestellten Elemente von Ereignisstellendiagrammen inklusive Exemplarvariation Kapitel 9 bringt den Vergleich des Ereignisstellenmodells mit verschiedenen bekannten und relevanten Ans tzen der Dialogmodellierung Es werden zun chst klassische Ans tze wie das Koroutinenkonzept von Jacob das Ereignismodell von Green Janssens Dialognetze und State Charts von Harel dann modernere Ans tze wie die HIT Technik von Schreiber und Sketchingsysteme aufgef hrt Es werden au erdem Parallelen und Gegens tze zu Modellen konkurrierender Prozesse anhand eines Vergleichs mit Milners Pi Kalk l angesprochen Kapitel 10 stellt die prototypische Realisierung eines Systems zur Modellierung mit Ereignisstellendiagrammen vor Zusammenfassung und Ausblick in Kapitel 11 Glossar in Kapitel 12 Literaturverzeichnis in Kapitel 13 sowie Anhang A D schlie en die Arbeit ab 13 1 G ngige Ans tze der Realisierung von Dialogsystemen 1 G ngige Ans tze der Realisierung von Dialogsystemen Im Folgenden werden drei grunds tzlich unterschiedliche Ans tze der Methodik
223. lationsdialogs hatten wir die Situation dass eine alternative Verzweigung f r den Fall einer gelungenen und einer fehlerhaften Installation vorgesehen war In diesem Fall ist es die Aufgabe der Applikationslogik die Entscheidung zwischen den Alternativen zu f llen und an die Dialogkomponente weiterzugeben die letztlich dann die Entscheidung f r die Fortf hrung der Darstellung an der Dialog Oberfl che trifft Gibt es im Dialog alternative Eingabestellen des Benutzers liegt die Entscheidung f r die zu w hlende Eingabestelle beim Benutzer Hier ist das System nur insofern gefordert als es von vornherein entscheiden muss ob es alle zun chst im Modell dargestellten alternativen Fortf hrungen zu diesen Eingabestellen tats chlich in einer bestimmten Dialogsituation verf gbar macht 4 1 3 0 Bedingungen Conditions Um nun ein Hilfsmittel zur Verf gung zu stellen mit dem das System entscheiden kann ob ein bergang zu einer potentiellen Fortsetzungsstelle erfolgen soll f hren wir eine Funktion mit booleschem R ckgabewert ein die einem bergang zwischen zwei Stellen zugeordnet werden kann Liefert die Funktion den Wert TRUE soll der bergang von der Ausgangsstelle zur Zielstelle erfolgen d h das Ereignis an der Zielstelle findet statt Im FALSE Fall erfolgt entsprechend kein bergang Ohne Beschr nkung der Allgemeinheit besitzt die jeweilige Funktion eine Reihe von Eingangsparametern in Form von Werten an definierten Stellen Die bo
224. ldialoge betrachtet werden Abbildung 4 16 zeigt zwei nebenl ufige Dialoge A und B die in sich jeweils eine Folge von Ausgaben O und Eingaben I enthalten Die Folgen dr cken eine logische Abh ngigkeit in dem Sinne aus dass erst ein Ereignis aus der definierten Ereignismenge der Vorg ngerstelle den Dialog also das Eintreten eines Ereignisses an der Nachfolgerstelle erm glicht Diese Abh ngigkeiten des Dialogablaufs sind in der Abbildung durch Pfeile mit durchgezogenen Linien zwischen den Stellen ausgedr ckt Die Pfeile mit gestrichelter Linie zeigen eine der m glichen tats chlichen Ablauffolgen von Ereignissen Diese Folge ergibt sich dadurch dass der Benutzer zwischen den beiden neben l ufigen Dialogen in seiner Bedienung der Eingabestellen abwechselt und den Dialog quasiparallel abwickelt Beide Dialoge werden abwechselnd vorangetrieben Die Abbildung zeigt auch dass ein bergang von A nach B oder umgekehrt nur immer an die jeweils aktuelle Stelle des anderen Dialogs erfolgen kann Mit aktueller Stelle ist die Nachfolgestelle der Stelle gemeint an der das letzte Ereignis im jeweiligen Teil Dialog eingetreten war Diese aktuelle Stelle wollen wir auch als verf gbare ereignisbereite oder ge ffnete Stelle bezeichnen Dialog A Dialog B Abbildung 4 16 Logische und willk rliche berg nge schematische Darstellung zweier nebenl ufiger Dialoge Wir sehen also dass der Pfeil mit durchgezogener Linie nich
225. le etwa Typ blind einf hren der bei der automatischen Umsetzung in die Implementierung nicht eingeht 4 2 Logische Abstraktion zeitlicher Folgen Die oben angef hrten zum Teil trivialen manchmal intuitiv oder auch bewusst durchgef hr ten Schritte zur Reduktion der Ereignisstellen in unserem Modell reichen bei weitem noch nicht aus um in einer Vielzahl von Anwendungen das Modell auf ein vern nftiges Ma von Modellstellen einzuschr nken Durch die Zusammenfassung identischer Stellenfolgen das Einf hren von Stellen mit Wertebereichen die Mehrfachverwendung von Subgrafen das Einf hren von Zyklen und Rekursion ist es zwar gelungen die Darstellung der konkreten Ereignisse an einzelnen Stellen im Modell zur ckzuf hren auf eine Darstellung von Ereignismengen Jede Modellstelle repr sentiert eine Menge von Ereignissen Durch die Stellen des Modells wird die Menge aller Ereignisse auf Ereignisklassen reduziert Wir gehen bisher aber immer noch davon aus alle m glichen berg nge von einem Dialoger eignis zu einem anderen auch als bergang in unserem Modell explizit auszuweisen Dies ge schieht dadurch dass wir alle m glichen berg nge von einer Ereignisklasse zu einer anderen Ereignisklasse im Modell in Form einer Kante unseres Grafen repr sentieren Dabei gibt es nun berg nge die im Sinne der logischen Modellierung unseres Dialogs irrelevant sind D h es gibt berg nge die einfach aus der Annahme in unserem Gru
226. leren Ausgestal tung ist der Fehlerdialog wiederum ein zusammengesetzter Dialog der pr zise auf den Fehler in den erforderlichen Daten hinweist und zur Korrektur bzw Vervollst ndigung der Daten auffordert In exemplarischer Form siehe auch Abschnitt Exemplarische Darstellung und Variation sind zwei bertragungsfunktionen abgebildet die die jeweilig auszugebenden Werte im Preisdia log f r die Auftragsposition 3 bestimmen Die eine bertr gt einfach den identischen Wert der Auftragsposition 3 aus dem vorangegangenen Dialog Auftragspositionen Die andere berech net den Preis der Position in Abh ngigkeit von den Angaben der Auftragsposition und den Kundendaten Ausgel st werden die Funktionen falls die Conditionauswertung TRUE liefert 72 4 2 Logische Abstraktion C DatenYollst ndig Nein T Bu FP Preis Position3 Kunde Abbildung 4 15 Auftragserfassung mit Condition und Propagationsfunktionen Wir gehen davon aus dass bei Umsetzung des Modells zur Laufzeit die Eingabewerte der Funktionen zur Verf gung stehen und die Ergebnisse der Funktionsaufrufe an den entsprechenden Ausgabestellen gesetzt werden 73 4 Bottom up Modellierung und Abstraktion Im obigen Beispiel haben wir nebenl ufige Teildialoge die in sich wiederum keine logischen Abh ngigkeiten ihrer Subdialoge enthalten Im Folgenden soll noch einmal dieser Fall an einem schematischen Beispiel zweier Teildialoge mit definierten inneren Abh ngigkeiten ihrer Tei
227. liche Darstellung der inkrementellen Erweiterung und der schrittweisen Reduktion von akzeptierten Ereignismengen an unterschiedlichen Stellen ist in State Charts so nicht gegeben Was zun chst als Nachteil eines ESD angesehen werden k nnte n mlich dass die Stellen in einem ESD explizit geschlossen werden m ssen damit sie keine Ereignisse mehr akzeptieren erweist sich in vielen F llen als Vorteil Set Clock time fwdfincrement minutes time fwa increment hours set clock Set minutes Set hours do show minutes do show hours set clock time back decrement minutes time back decrement hours Abbildung 9 5 State Chart f r Set Clock Dialog nach Rumbaugh RUMBA91 Die Abbildung zeigt ein State Chart mit einem Xor Gruppierungs Zustand Set Clock der zwei sich gegenseitig ausschlie ende Unterzust nde Set minutes und Set hours zum Einstellen der Uhrzeit enth lt set minutes ist Startzustand Das Ereignis set clock bewirkt einen Wechsel in Zustand Set hours und umgekehrt Innerhalb eines Zustands laufen permanent Aktivit ten die die Ausgabe show minutes bzw show hours realisieren sollen Die Ereignisse time fwd bzw time back bewirken jeweils die dahinter stehende Aktion Das State Chart zeigt eine typische Modellierung mit dem Zustandsparadigma wobei Ausgaben in Aktionen versteckt auftreten und Eingaben als Ereignisse an Kanten zu finden sind 137 9 Vergleich mit bekannten An
228. lichen Abl ufe der Ein Ausgabeereignisse in Form von Tokens Details von Layout grafischer Repr sentation und Ger teverwaltung sind Internas der Tokendefinition Interactive Objects mit Objekthierarchie und Vererbung Die Objekte im Modell von Jacob k nnen andere Objekte im Sinne der Bestandteilshierarchie Component Objects beinhalten Au erdem k nnen Objekte von anderen Objekten erben Inheritance Executive F r die Beschreibung des Gesamtzusammenhangs f hrt er ein Executive ein das die Ereignisse an die Objekte mittels Aufruf einer dem jeweiligen Objekt zugeordneten Koroutine verteilt Die Objekte erhalten nach Aufruf der Koroutine die Kontrolle und arbeiten die ankommenden Ereignisse ab bis sie ein Ereignis empfangen das sie gem ihrem aktuellen Zustand im Zustands bergangsdiagramm nicht akzeptieren Die Objekte behalten den bis dahin erreichten Zustand und setzen ihre Arbeit in diesem Zustand wieder fort sobald sie vom Executive wieder ein Ereignis zugeordnet bekommen das sie in diesem Zustand akzeptieren Mit dem Konzept tr gt Jacob der Nebenl ufigkeit von Dialogen Rechnung und der Tatsache dass die Darstellung aller berg nge der Kontrolle von einem Objekt zum anderen mittels 127 9 Vergleich mit bekannten Ans tzen Zustands bergang in einem alle Objekte umfassenden bergangs Diagramm zu einer Unmenge von berg ngen f hren w rde Dabei liegt der Ehrgeiz bei Jacob noch darin alle diese berg nge
229. lick auf das Gesamtmodell betrifft da die Information ber das Gesamtmodell durch die Bildung der Teilsichten nicht beeinflusst wird F r den Benutzer erfordert die Darstellung von Teilsichten allerdings den intellektuellen Aufwand die Einordnung der dargestellten Elemente in den Gesamtzusammenhang zu bringen Deshalb ist es sinnvoll den Benutzer bei der Wahl vern nftiger Teilsichten zu unterst tzen und z B zumindest grafisch zu visualisieren dass Information in den Teilsichten ausgespart wurde 2 Zusammenf hrung von Teilsichten Ein anderer Ausgangspunkt f r Teilsichten ist der dass blicherweise der Entwurf des Systems nicht in einem Guss erfolgt sondern sukzessive Teilinformation festgehalten und zusammengefasst wird Um diesen Vorgang zu unterst tzen macht es Sinn in einem Modelleditor die Definition von Information in Teilen zu erm glichen die dann durch die Maschine unterst tzt zu einem Modell zusammengef hrt wird In diesem Fall ben tigen wir ein Konzept das es nicht nur dem Benutzer intellektuell sondern auch dem Modelleditor erm glicht die Darstellungselemente aus den einzelnen Teilsichten in ein Gesamtmodell einzuordnen 96 5 3 Grafische Darstellung Im Folgenden wollen wir einige sinnvolle M glichkeiten des Ausblendens von Modellin formation besprechen und dazu einfache grafische Elemente einf hren die dem Benutzer und dem System einen Hinweis auf die Unvollst ndigkeit der Information in einer Teilsicht g
230. lle bilden vielmehr eher eine konzeptuelle Grundlage f r eine Reihe von Basissystemen aber auch User Interface Management Systemen gekoppelt mit direkter Programmierung siehe unten zur Implementierung von Dialogsystemen wie dies z B in X Windows Motif Microsoft Windows Java Swing aber auch in Skriptsprachen wie Java Script der Fall ist Wegen seiner technischen Orientierung und der Aufteilung des Systems auf verschiedene Eventhandler deren Eventroutinen auszuprogrammieren sind ist das Ereignismodell 22 1 1 Abstrakte Modellsysteme zun chst nicht f r eine intuitive und bersichtliche Darstellung des logischen Dialogs geeignet Das Ereignismodell bildet jedoch eine wesentliche Grundlage auch f r das in dieser Arbeit entwickelte Ereignisstellenmodell mit der grafischen Modellierung in Ereignisstellendia grammen 1 2 Direkte Programmierung Als wesentliche dritte Kategorie von Ans tzen wollen wir die Ans tze mit direkter Programmierung bezeichnen Dies sind Ans tze bei denen relativ implementierungsnah etwa mit einer Skriptsprache Java Script Perl oder einer allgemeinen Programmiersprache Java C C direkt vom Entwickler die Anwendung realisiert wird Wir wollen dazu im weiteren Sinne auch die Verwendung spezifischer Protokollsprachen z hlen wie etwa HTML und darauf aufsetzender Techniken wie ASP Active Server Pages JSP Java Server Pages oder den Einsatz von Servlets im Umfeld der Realisierung
231. llen Dialogstruktur wie diese etwa in einem Kommandodialog Frage Antwort Dialog oder Men dialog vorkommt ist in Form von Produktionen nahe liegend F r den Benutzer ist die Darstellung der Dialogstruktur in Form einzelner Produktionen allerdings etwa im Vergleich zu Zustands bergangsdiagrammen weniger geeignet JANSS96 Ein weiterer Nachteil ist dass mit Ausnahme einiger Erweiterungen die Darstellung von Nebenl ufigkeit nicht unterst tzt wird 1 1 1 3 Ereignismodelle Ereignismodelle basieren auf der Sicht dass in einem Dialogsystem so genannte Eventhandler meist parallel auf bestimmte Ereignisse warten Bei Eintreffen eines Ereignisses in der Regel aber nicht notwendig eines hardwarenahen Eingabeereignisses z B Mausklick wird dieses Ereignis von einer zentralen Instanz aufgenommen und an die oder den entsprechenden Eventhandler verteilt Der jeweilige Eventhandler arbeitet dann das Ereignis etwa mit Aufruf einer Applikationsfunktion der Durchf hrung einer Ausgabe dem Versenden eines weiteren Ereignisses oder dem Aktivieren oder Deaktivieren eines anderen Eventhandlers ab um dann ggf die Kontrolle wieder an die zentrale Instanz zu bergeben siehe auch Abschnitt 9 1 Ereignismodell nach Green Ereignismodelle heben sich von den bisher genannten Modellen in einigen Gesichtspunkten ab Sie sind zun chst nicht f r eine grafische Modellierung wie dies bei Petrinetzen und Zustands bergangsdiagrammen der Fall ist gedacht Ereignismode
232. llt werden Im obigen formalen Modell sind Stellen durch die Menge S repr sentiert Stellen k nnen Teilstellen enthalten sind also ggf hierarchisch geordnet Im formalen Modell entspricht dies der Relation HS Stellen als Rechtecke mit Stellenbezeichnern Eine Stelle wird im ESD als umrandetes Rechteck gezeichnet In einem Rechteck k nnen wiederum Rechtecke enthalten sein die jeweils eine Teilstelle der bergeordneten Stelle repr sentieren Wir geben der Darstellung als Rechteck den Vorzug gegen ber der Darstellung als Kreis oder Oval weil sich zum einen f r Beschriftungen innerhalb von Rechtecken f r Teilstellen mehr Fl che ergibt weniger Fl chenverschnitt und zum anderen bliche Fenster und Felder am Bildschirm suggeriert werden Um auf Stellen im Modell textuell verweisen zu k nnen f hren wir Stellenbezeichner f r die Modellstellen in Form von Textstrings ein Der Stellenbezeichner steht blicherweise links oben im Rechteck oder kann au erhalb des Rechtecks normalerweise links oben angebracht werden Im letzteren Fall muss die Zuordnung der Annotation allerdings klar erkennbar sein Dies erreichen wir etwa durch das Anbringen der Annotation mit gestrichelter Linie zum Rechtecksrahmen Um weiter Verwechslungen zu vermeiden kann dem Bezeichner auch ein N mit Doppelpunkt N vorangestellt werden Stellenbezeichner tauchen in der oben beschriebenen formalen Darstellung des ESM nicht auf Stellenbezeichner im Folgenden auch
233. llung von Widgets anstelle abstrakter Ereignisstellen vorgesehen Ansonsten geschieht die Zuordnung konkreter Widgets zu Ereignisstellen ber entsprechende Annotation von Abbildungsinformation die z B die zu verwendende Widgetklasse zu verwendende Widgetattribute und weitere f r die Umsetzung jeweils n tige Information beinhaltet 145 9 Vergleich mit bekannten Ans tzen 9 6 Sketchingsysteme Die in den letzten Jahren entwickelten Sketchingsysteme z B SILK oder DENIM LANDAY00 haben zum Ziel den Designer bereits in einer fr hen Entwurfsphase bei der Entwicklung von Dialogsystemen zu unterst tzen Sie nutzen eine visuelle Sprache in der der Designer oder Entwickler mehr oder weniger naiv den Verlauf des Dialogs skizziert Das System soll dabei ist der Anspruch von System zu System graduell unterschiedlich aus teilweise handgefertigten Skizzen nach M glichkeit automatisch die statischen Dialogelemente die Aktionen des Benutzers und die daraus resultierenden Aktionen des Systems erkennen und in eine Implementierung umsetzen Der Designer malt beispielsweise auf einem so genannten Storyboard die Dialogoberfl che vor und nach einer Aktion des Benutzers auf Das System stellt die Unterschiede zwischen beiden Darstellungen fest und leitet daraus die notwendigen Reaktionen des Systems auf eine Benutzeraktion ab z B System Anecdote HARADA96 Die j ngsten Arbeiten stellen u a eine Fortsetzung der Arbeiten dar die mit den Stichworten
234. llungselemente Ein wesentlicher Nachteil der Darstellung grafischen Dialogs in Zustands bergangsdiagram men beispielsweise n mlich die Notwendigkeit einer kaum handhabbaren Vielzahl von Zustands berg ngen wird durch eine besondere Definition von Dialogstellen und die Einf h rung von Metaereignissen ffnen Schlie en von Stellen beseitigt Im Vergleich zu State Charts z B HAREL87 OESTER97 ist die Darstellung nebenl ufiger Dialoge noch flexibler gel st Im Gegensatz zum Einsatz von Petrinetzen z B JANSS96 die urspr nglich f r andere Anwendungsgebiete geschaffen wurden bietet das Ereignisstellendiagramm einen nat rlicheren mehr dem spezifischen Problem angepassten und m chtigeren Zugang zur Darstellung der Dialogdynamik Das Ziel ist unter anderem mit m glichst wenigen und eing ngigen Sprachelementen die Schnittstelle zwischen Benutzer und System zu beschreiben die auch dem Modellier Laien also etwa dem k nftigen Anwender des Systems das Modell verst ndlich und handhabbar macht Neben einem systematischen Top down Entwurf wird z B mit der unmittelbaren Integra tion konkreter Dialogobjekte in Ereignisstellendiagramme ein Bottom up Ansatz im Vorgehen des Designs erm glicht D h der Designer kann im Entwurf mit einer konkreten Darstellung beginnen und diese bei Bedarf sukzessive mit abstrakteren verallgemeinernden Sprachmitteln fortf hren Er kann u a eine exemplarische Darstellung w hl
235. ls Kind enthalten Wie alle Objekte des Baukastensystems besitze ein Icon einen eindeutigen Bezeichner zur Identifikation Im Modell werden in eine Toolbar im ersten Entwurf drei Icons gelegt Nachdem erkannt wird dass die Anzahl der Icons variabel zu halten ist wird eine Variation wie folgt definiert Exemplare und damit auch Gegenstand der Variation seien die drei Icons Zur n heren Bestimmung der Variation wird auf bestimmte den Variationsgegenst nden zuzuordnende Aspekte eingeschr nkt Als ein Aspekt der Variation sei angegeben die Anzahl der Exemplare etwas formaler die Anzahl der Instanzen die durch die Modellexemplare repr sentiert werden Mit der Variation der Anzahl der Instanzen ist notwendigerweise eine Variation der eindeutigen Bezeichner f r eine Iconinstanz verbunden Au erdem variieren die den Icons zugeordneten Symbole Bitmaps die Position der Icons deren beschreibender Text sowie die Dialoge die bei Selektion eines der Icons getriggert werden sollen Alle anderen Merkmale der Variationsexemplare werden beibehalten Gr e Hintergrundfarbe Vordergrundfarbe und Parent Die Festlegung welche Attribute Aspekte der Exemplare variieren und welche nicht kann optional vom System automatisch getroffen werden indem es die gew hlten Exemplare in ihren Attributen und Attributwerten vergleicht Die automatische Bestimmung der variierenden Attribute ist in unserem Beispiel m glich weil sich jeweils Position auszul s
236. lue Menge der m glichen Aspekte Card Konstante die f r Variation der Kardinalit t steht Id Konstante die f r Variation der Stellenidentit t steht PS Konstante die f r Variation der Teilstellen steht PartialStructure Value Konstante die f r Variation des Stellenwertes steht VarType e inc abs wobei VarType den so genannten Variationstyp bezeichnet und 177 Anhang E inc eine Konstante die f r eine inkrementelle Variation steht abs eine Konstante die f r eine so genannte absolute Variation steht varFunc ist eine so genannte Variationsfunktion aus einer Menge von Funktionen der Form varFunc E MConfigs gt MConfigs Wir gehen davon aus dass sich die Variationen mit Eintritt eines Ereignisses ebenso ndern k nnen Dies z B schon deshalb weil sich durch die Hinzunahme weiterer Stellen die Menge der eine Variation var ausl senden Ereignisse VarEvents ndern kann Mit der Folge der Ereignishistorie ehisto ehistj wobei ehist o e1 ei f r i N eo sei das Ereignis des Starts e1 e E erhalten wir somit eine Folge von Modellkonfigurationen mConfig Si SStart E RO RC HS Varsi EROj ERCj KROj KRCi TTRO qi Si wobei gilt dyn ei mConfig mConfig enextj 1 mit enexti E Die mit dem Index versehenen Tupelelemente einer Modellkonfiguration sind dabei entsprechend den Tupelelementen ohne Index im ESM Modell Kapitel 5 definiert
237. mandodialog auf einer Kommandozeile ist damit nicht m glich 19 1 G ngige Ans tze der Realisierung von Dialogsystemen 1 1 Abstrakte Modellsysteme Als Alternative zum Einsatz eines Werkzeuges zum Rapid Development oder Rapid Prototyping also eines so genannten Lower Case Tools bietet sich prinzipiell der Einsatz einer abstrakten Modellsprache das eventuell hinsichtlich Modellspezifikation und Generierung einer konkreten Implementierung durch so genannte Upper Case Tools unterst tzt wird Wir wollen im Folgenden auf einige zu Grunde liegende Modell Ans tze kurz eingehen Es sind dies Ans tze die zum einen die statische Modellierung der Dialogkomponenten und oder die Modellierung der Dialogdynamik unterst tzen 1 1 0 Statische Objektmodellierung Zur Darstellung und Erzeugung von Dialogkomponenten kann ein statisches Objektmodell oder Datenmodell herangezogen werden Es kann nahe liegend zum einen dazu dienen die Statik von Oberfl chenelementen am Bildschirm festzulegen zum anderen aber auch aller dings in eingeschr nktem Ma e zur automatischen Ableitung der mit den Oberfl chen elementen verbundenen Dialogdynamik und Applikationslogik Dies gilt insbesondere f r Datenbank Applikationen Generierung von Statik und Dynamik aus Datenmodell So gibt es zum Beispiel Systeme die f r die Generierung der Dialogobjekte Klassendiagram me einer objektorientierten Modellierung zu Grunde legen Beispiel Janus System BALZE94 A
238. mat ist zur Darstellung auf dem Handy Display gezwungen den inhaltlich gleichen Dialog in bestimmter zeitlicher Folge hintereinander anzuordnen den er auf dem Gro bildschirm gleichzeitig auf einmal darstellen kann Durch die technischen Gegebenheiten sind also unterschiedliche Layouts n tig Auf dem Handy Display ergibt sich ein Layout in dem z B Formularfeld f r Formularfeld zeitlich hintereinender angeboten werden muss w hrend auf dem 20 Zoll Bildschirm das Formular mit allen Feldern komplett auf einen Blick sichtbar ist Benutzerkonforme Reihenfolgen Benutzergerechte Layoutgestaltung Wir haben oben bereits von zeitlichen Anordnungen aufgrund von Anforderungen an den Ablauf gesprochen den wir aus der aufgabenlogischen Analyse ableiten Dabei wurde bereits der Benutzer als Teil des Gesamtsystems angesprochen der zur Erf llung seiner Aufgaben rechtzeitig mit der n tigen Information versorgt werden muss Die zeitliche Darbietung der Information f r den Benutzer und die zeitliche Darstellung durch den Benutzer wird aber nicht nur durch rein aufgabenlogische optimierende Gesichtspunkte beeinflusst Qualit tskriterium Aufgabenangemessenheit Hier spielen nat rlich auch die Gewohnheiten und Erwartungen des Benutzers eine wichtige Rolle die die Anordnung der Information und damit auch die zeitliche Reihenfolge beeinflussen Qualit tskriterium Erwartungskonformit t Ein einfaches Beispiel sei wiederum die Eingabe einer Adresse Wenn wir
239. mation bestimmt 142 9 5 Hierarchical Interactive Graph Templates HITs 9 5 Hierarchical Interactive Graph Templates HITs Im Rahmen der Gesamtarchitektur von FUSE Formal User Interface Specification Environment LOSCH96b LOSCH96a stellt Schreiber im System BOSS Benutzer Oberfl chen Spezifikations System SCHREI94 SCHREI9S5 die so genannte HIT Spezifikationstechnik vor SCHREI97 Hierarchical Interactive Graph Templates HITs stellen Bausteine dar mit denen hierarchisch strukturiert das Modell einer Dialoganwendung formuliert werden kann Basis der Technik sind so genannte dynamische Attributgrammatiken GANZ78 PRJD96 die um ein Ereigniskonzept erweitert wurden Es werden im Folgenden die wesentlichen Sprachelemente der Hitspezifikation angesprochen soweit dies zum Vergleich mit den Elementen eines ESM notwendig ist Zu einer exakten vollst ndigen Beschreibung sei auf SCHREI97 verwiesen Bausteine der HIT Spezifikation Die wesentlichen zusammenfassenden Bausteine der Modellierung sind so genannte Tupel Hits und Alternativen Hits Eine Hitspezifikation setzt sich aus einer Hierarchie dieser Bausteine zusammen Alternativen Hits Ein Alternativen Hit der als Teilkomponenten wiederum Hits beinhaltet dient zur alternati ven Auswahl und Aktivierung einer seiner Teilkomponenten Ob ein Hit aktiv wird h ngt von seiner zugeordneten Anwendbarkeitsbedingung ab Ein Alternativen Hit besitzt so genannte Slots zur Darst
240. mente der Sprache sind die Exemplare als zu variierende Objekte sowie Aspekte Eigenschaften Attribute dieser Objekte in ihren m glichen Abwandlungen oder Alternativen Dabei ist zu ber cksichtigen dass diese Abwandlungen bei Eintritt bestimmter Ereignisse oder Bedingungen in einem bestimmten Kontext erfolgen bzw wahrgenommen werden k nnen Wenn wir von unserem Modell ausgehen sind die Objekte der Variation grunds tzlich die Elemente unseres Modells in erster Linie die Stellen Als Aspekte der Variation einer Stelle kommt alles in Frage was sich an Aussagen zu einer Stelle im Modell befindet also die Struktur der Stelle d h die Relation X im Bezug zu s aus S die Aussage wann die Stelle ge ffnet bzw geschlossen wird was durch Elemente in RO bzw RC festgehalten ist sowie die Werte und Ereignisse die mit einer Stelle in Verbindung stehen im Modell ausgedr ckt durch o s sowie Wertebereiche und Propagationsfunktionen 113 7 Exemplarische Darstellung und Variation 7 2 Merkmale der Exemplarvariation Als wesentliche Merkmale der Variation ergeben sich 1 2 der Gegenstand der Variation bestehend aus Objekten mit ihren Aspekten bzw den die Aspekte eines Objektes beschreibenden Modellelementen eine Beschreibung unter welchen Bedingungen und Abh ngigkeiten welche Varianten zutreffen bzw eine Beschreibung der Vorschrift zur Erzeugung der jeweiligen Variante Bildungsgesetz der Zeitpunkt zu dem die Variation w
241. mmen und Dialognetzen insbesondere im grunds tzlichen Ansatz dass Dialoge ber Stellen repr sentiert werden und Stellen ber Ereignisse aktiviert bzw ge ffnet werden was im Wesentlichen durch Stellen berg nge beschrieben wird Allerdings interpretiert Janssen in Dialognetzen auch in der Hierarchie komplexer Stellen Stellen nur als Fenster Ereignisstellen Diagramme er ffnen in der Interpretation ihrer hierarchischen Struktur die Implementierung von Dialogobjekten auf der Ebene primitiver Dialogobjekte In diesem Zusammenhang ist in Dialognetzen auch nicht an die grafische Darstellung von Wert bertragungen zwischen Stellen gedacht Ebenso gibt es bei Dialognetzen keine Differenzierung in Eingabe und Ausgabe Das gilt f r Stellen wie f r Ereignisse 135 9 Vergleich mit bekannten Ans tzen Die Vorstellung des Markenflusses wie er in Petrinetzen eingef hrt ist erfordert vom Entwickler und potentiellen Systembenutzer einen Paradigmenwechsel und behindert manchmal eher eine intuitive Vorstellung vom Dialogablauf Zur Darstellung der Dynamik auf der Ebene primitiver Dialogobjekte schl gt Janssen die Anwendung von Constraints vor In Ereignisstellen Diagrammen k nnen dagegen Wertzuweisungen ber Propagationsfunktionen definiert und mittels Anwendung von Wert bertragungspfeilen grafisch visualisiert werden Anstelle der Constraints tritt als deskriptives Sprachelement die Exemplarvariation die die M glichkeiten der Beschreibung
242. mulieren dass sich die berg nge gegenseitig ausschlie en Die gerichteten Kanten in Gr n die das Er ffnen eines Dialogs bedeuten sind hier aus den Ausg ngen der OK Dialoge in verk rzender Schreibweise auf eine Zielstelle zusammengef hrt 131 9 Vergleich mit bekannten Ans tzen Im ES Modell ist auch neben dem Objektbegriff kein Zustandsbegriff explizit vorgesehen sondern nur Stellen Erst mit der Zusammenfassung von Ereignissen an ein und derselben Stelle kann es Sinn machen in der Implementierung mit jedem dieser Ereignisse an der Stelle einen neuen Zustand der zusammenfassenden Stelle zu verbinden statt der Stelle f r die einzelnen Ereignisse Substellen zuzuordnen Das Koroutinenkonzept von Jacob wird im Grunde beim ESD als gegeben vorausgesetzt Nebenl ufige Stellen werden einfach nebeneinander dargestellt Ein Verteilungsmechanismus der Ereignisse an die akzeptierenden Stellen wird als gegeben gefordert So stellt das Konzept von Jacob in gewisser Weise eine Basis oder Erg nzung zum ESD dar das aber nicht eigens modelliert werden muss Mit der Einf hrung des Objektbegriffs ist Jacob viel n her an der Implementierung als das ESD mit dem Stellenbegriff Denn Stellen k nnen sich in der Implementierung in Objekte aber auch in Objekt Zust nde oder in andere Ph nomene Ressourcen wie z B Objektattribu te etc verwandeln Stellen stehen grunds tzlich f r irgendwelche Ressourcen an denen bzw ber die Informations Er
243. n Anzahl von Zust nden und Transitionen 4 1 Reduktion von Stellen und Transitionen Um den wesentlichen Nachteil der extensiven Darstellung die sehr hohe und h ufig unendliche Anzahl von Stellen zu beseitigen m ssen wir trivialerweise die Anzahl der ben tigten Stellen reduzieren Dasselbe gilt f r die berg nge zwischen den Stellen Die Reduktion der Stellen und Transitionen wollen wir auch als Intensivierung der Darstellung bezeichnen Zusammenf hrung identischer Teilfolgen alternativer Dialoge Mit der Darstellung des Dialogablaufes in Baumform sind wir bereits von einer extrem exten siven Darstellung aller alternativen Folgen mit einer Aufz hlung aller einzelnen Folgen mit allen einzelnen Ereignissen an jeweils eigenen Modellstellen abgewichen Eine weitere einfa che Reduktion der Knoten und Kanten bzw der Modellstellen und ihrer berg nge erreicht man wenn nun nicht nur identische Teilfolgen am Anfang wie bei der Baumdarstellung der Fall sondern generell identische Teilfolgen alternativer Folgen zu einem einzigen Teilpfad im Grafen zusammengefasst werden Dabei fassen wir Teilfolgen als identisch auf wenn die einzelnen Folgenglieder in Typ und Wert des dargestellten Ereignisses bereinstimmen Dies geschieht nun wiederum problemlos wenn die Zusammenfassung nicht zu einem Infor mationsverlust f hrt der eine Fortsetzung nach der zusammengefassten Teilfolge mit den bisher gegeben Mitteln der Darstellung in unserem Grafen u
244. n Ort explizit vor der Postleitzahl einzugeben f r den Fall dass dem Benutzer die Postleitzahl nicht bekannt ist Im Modell m ssen wir nun sowohl diese logische Abh ngigkeit zwischen Postleitzahl und Ort als auch die M glichkeit des Einstiegs ber die Eingabe des Ortsnamens ausdr cken k nnen 65 4 Bottom up Modellierung und Abstraktion Logisch gleichzeitige Ereignisse Der Vollst ndigkeit halber sei hier auch erw hnt dass bei bestimmten Ereignissen gefordert sein kann dass sie echt gleichzeitig eintreten m ssen 4 2 1 2 Technische und layoutbedingte Reihenfolgen Wir haben oben einige Gr nde f r die logische Ordnung der Dialogschritte in zeitlicher Reihenfolge genannt und herausgearbeitet dass in vielen F llen eine Unabh ngigkeit von Dialogschritten aus aufgabenlogischer Sicht vorliegt H ufig ergibt sich erst durch die Implementierungstechnik die notwendige Wahl einer bestimmten Reihenfolge Dies gilt insbesondere dann wenn aufgrund eines Mangels an sonstigen Ausdrucksmitteln bzw Ressourcen zur Darstellung die Ressource Zeit verwendet werden muss um die Information zu bermitteln Wir k nnen dann von implementierungstechnisch bedingten und damit auch layoutbedingten Reihenfolgen sprechen Denken wir z B an den Dialog auf einem Handy Display mit stark eingeschr nkter Anzahl gleichzeitig darstellbarer Zeichen im Vergleich zu einem Dialog auf einem 20 Zoll Bildschirm Der Dialogdesigner sei er ein Mensch oder ein Auto
245. n S RC mit aktuellen berg ngen s s zum Schlie en s Ende Definition bergangsfunktion Zusammenfassend halten wir fest Bei Eintreten eines Ereignisses e geht die Menge der q zugeordneten m glichen Ereignisse in die q zugeordnete Menge e q ber falls 1 das Ereignis e ein ffne Ereignis an Stelle s f r eine Stellenmenge S darstellt e ero s s s e S die ffne Bedingung c erf llt ist oder und 2 das Ereignis e ein Schlie e Ereignis an Stelle s f r eine Stellenmenge S darstellt e ERC S S S e S und die Schlie e Bedingung c erf llt ist Der Wert an der Stelle s nimmt den Wert des Ereignisses e an Au erdem werden ggf Schreibereignisse des Systems enext E an Stellen in S propagiert die dann unmittelbar synchron weitere berg nge nachfolgen lassen Dies bedeutet dass Ereignisse die von au en an das System herangetragen werden also 0 B d A vom Benutzer verursachte und aktuell anstehende Ereignisse erst abgehandelt werden wenn alle vom System erzeugten Ereignisse enext abgearbeitet sind Erzeugt die Abarbeitung der Ereignisse in enext wiederum neue Ereignisse werden diese unmittelbar nach den in enext stehenden Ereignissen und vor allen von au en erzeugten und noch anstehenden Ereignissen behandelt Hierarchisches Modell In einem hierarchischen Ereignisstellenmodell ist zus tzlich eine zweistellige Relation HS lt S S aufder Menge d
246. n Stellenbezeichner von Fixstelle und Jokerstelle Die Teilehierarchie der so gefundenen Jokerstelle kann nun verwendet werden um die Teilehierarchie der Fixstelle entsprechend zu erweitern Dies geschieht indem alle in der Jokerstelle enthaltenen Stellen mit fixer hierarchischer Einordnung relativ zur Jokerstelle in die Teilehierarchie der Fixstelle mit aufgenommen werden F r die so neu gewonnenen Fixstellen kann nun wiederum nach Jokerstellen gesucht werden Dies geschieht so lange bis f r alle gefundenen Fixstellen alle Jokerstellen untersucht wurden und keine neuen Fixstellen mehr produziert werden k nnen Um ein endloses Einh ngen von Jokerstellen mit rekursivem Vorkommen von Stellenbezeich nern zu verhindern stellen wir sicher dass die gefundene Jokerstelle selbst nicht mehr bei der Suche nach Jokerstellen f r die eigenen Teilstellen verwendet wird Sind die Stellen des Gesamtmodells erkannt kann die Zuordnung der mit den Stellen verbundenen Information erfolgen In einem einfachen Fall l sen wir diese Aufgabe so dass die Information der Stelle im Gesamtmodell die Vereinigung der Information aller Stellenvorkommen an den Teilstellen bedeutet Dabei fordern wir dass diese Informationen nicht widerspr chlich sind Die Auslagerung bzw Verteilung von Information auf mehrere Diagramme ist ein allgemeiner Ansatz der nicht nur die Auslagerung einzelner Hierarchieebenen auf verschiedene Diagramme erm glicht Es k nnen generell
247. n der Stelle sein m ssen der das aktuelle Ereignis der Listenermethode zuzuordnen ist Ebenso k nnen dort andere Listener Instanzen aktiviert werden etc Es k nnen aber auch andere Stellen geschlossen werden Insbesondere erfolgt dort auch die Einbettung der Aufrufe von Conditions und Propagationsfunktionen siehe unten 10 2 4 Realisierung von Conditions und Propagationsfunktionen Die im Ereignisstellendiagramm angegebenen Conditions oder Propagationsfunktionen werden als Methoden der Klasse realisiert die der Codegenerator f r die ausl sende Stelle generiert Mit ausl sender Stelle ist die Stelle gemeint an der ein Ereignis stattfindet das den Stellen bergang mit der zugeordneten Condition oder Propagationsfunktion bewirkt Der Code f r die Condition oder Propagationsfunktion wird im Allgemeinen vom Anwender des Prototypen zur Verf gung gestellt und vor der Kompilation in den generierten Code der Klasse integriert Im derzeitigen Prototyp wird dabei der Aufruf der Condition oder Propagationsfunktion aus der Annotation direkt bernommen und im Code an eine Variable evob die die ausl sende Stelle repr sentiert angeh ngt 158 10 2 Schritte zur Codegenerierung evob lt String aus Annotation zur Bezeichnung der Condition gt evob lt String aus Annotation zur Bezeichnung der Propagationsfunktion gt 10 2 5 Prototypische Realisierung der Exemplarvariation Die in Kap 7 vorgestellte exemplarische Darstellung mit Variationsan
248. n erfolgt Wenn wir nun annehmen dass die Implementierung der vier Zustandsstellen der Seite Checkout ber dieselbe Objekt Instanz erfolgt muss in der Implementierung sichergestellt sein dass z B das Schlie en einer Zustandsstelle nicht das ffnen einer anderen Zustandsstelle ungewollt beeintr chtigt Wir k nnen die Implementierung nicht einfach von vorneherein so w hlen dass das ffnen einer Stelle etwa das Erzeugen einer Instanz und das Schlie en das L schen der Instanz bedeutet wenn nicht sichergestellt ist dass prinzipiell bei Abarbeitung eines Ereignisses das Schlie en immer vor dem ffnen durchgef hrt wird Bei 148 9 6 Sketchingsysteme Abbildung zweier Stellen auf dieselbe Instanz k nnte das andernfalls zu dem ungewollten Effekt f hren dass die Instanz ge ffnet und sofort wieder geschlossen wird Im Prototyp ist eine Annotation vorgesehen die es erlaubt Zustandsstellen mit S lt Zustandsbezeichnung gt also z B S 1 S 2 zu kennzeichnen Stellen werden genau dann als Zustand einer einzigen Widgetinstanz implementiert wenn die Stellen den gleichen Bezeichner besitzen dieselbe bergeordnete Stelle auch die leere Stelle und eine geeignete Zustandsannotation Bei derartiger Darstellung von Zustandsstellen kann dann auf die Schlie epfeile beim bergang zu einer Zustandsstelle verzichtet werden In Abbildung 9 9 sind redundant zu den Schlie epfeilen diese Zustandsbezeichner verwendet Wie in der vorli
249. n mehrere Ereignistypen verarbeiten Die an den Event Handler gesendeten noch nicht verarbeiteten Ereignisse werden in einer Ereignisschlange gehalten Jedem Ereignistyp wird eine so genannte Event Handler Prozedur zugeordnet die in ihrem Rumpf eine Folge von Statements enth lt Die vorgesehenen sechs Typen von Statements sind Expressions zur Berechnung neuer Registerwerte bestehend aus Registern Konstanten und Operatoren Senden von Ereignissen an einen Event Handler Kreieren eines neuen Event Handlers L schen eines Event Handlers Ifcondition THEN statement ELSE statement das auch geschachtelt auftreten darf wobei conditions aus Registern Konstanten Operatoren und logischen Konnektoren besteht und 132 9 1 Ereignismodell von Green Dem Aufruf von sogenannten Applikationsprozeduren denen wiederum Expressions als Parameter bergeben werden Ein Ereignissystem besteht nun aus einer endlichen Menge von Event Handlern wobei die Anzahl der Event Handler sich dynamisch ver ndern kann Eingaben einer Pr sentationskomponente werden in Ereignisse abgebildet die den daran interessierten Event Handlern in ihre Ereignisschlange gestellt werden Das n chste anstehende Ereignis in der Schlange wird von der entsprechenden Event Handler Prozedur abgearbeitet dabei werden die Registerwerte des Event Handlers ver ndert und ggf Ereignisse in die eigene Ereignisschlange oder die anderer Event Handler gestellt Die Event Ha
250. n wir aber mit der expliziten Ereignisdarstellung das Textwidget an mehreren Modellstellen Die Kennzeich nung dass es sich zur Laufzeit um ein und dasselbe Widget handelt wird z B ber einen der Modellstelle zus tzlich zugeordneten eindeutigen Laufzeitstellennamen vorgenommen Darstellung der Dialogfolgen in einem Grafen Die m glichen Dialogfolgen k nnen auch in Form eines gerichteten Grafen dargestellt werden Die Bilder bzw Modellstellen sind die Knoten des Grafen Die Kanten repr sentieren jeweils den bergang von einem Bild zum Folgebild so dass ein Pfad des Grafen eine der alternati ven Dialogfolgen darstellt Im Folgenden wollen wir aus Gr nden der Platzersparnis von der Darstellung konkreter Widgets im Grafen abstrahieren F r die nun gef hrte Diskussion zur Darstellung der Dialogfolgen ist die Wahl konkreter Widgets ohne Belang Wir weisen die Knoten des Grafen meist dann in Form von beschrifteten und annotierten Ellipsen oder Rechtecken aus Dabei bezeichnet die Beschriftung innerhalb der Ellipse entweder einen Kommentar der das Ereignis an der jeweiligen Stelle umschreibt oder den mit dem Ereignis verbundenen Ausgabewert oder Eingabewert in Textform Die Annotation steht f r einen Identifikator der Stelle Modellstelle und den Typ des Ereignisses an der Stelle Eingabe E bzw I oder Ausgabe A bzw O 43 4 Bottom up Modellierung und Abstraktion Nach dem oben vorgestellten Ziel der WYSIWYG Darstellung wollen
251. nbank zu ladenden Jobs JobSelection zur Anzeige des Ladevorgangs LoadingJob zur grafischen Darstellung und Edition der JobSteps JobStepGraph 120 8 1 Elemente eines Ereignisstellendiagramms f r das JobEditor Modell sowie zur Darstellung und Edition der Detail Information zu einem JobStep JobStepDetails Eine besondere Rolle kommt der Ereignisstelle SaveToModel als reiner Hilfsstelle wir sagen auch Applikationsstelle zu siehe unten In den genannten Ereignisstellen sind weitere Teilstellen enthalten LoadJob NewJob usw Ein Teil des Diagramms ist in WYSIWYG Darstellung gezeigt Dies gilt f r die primitiven Dialoge Load OK und Cancel und f r den Inhalt des Dialogs JobStepGraph Dies gilt f r die beiden Dialoge JobStepl und JobStep2 sowie f r den Pfeil StepRelation der die Abh ngigkeit des Rechenschrittes Sensitivities vom Rechenschritt AccountFlows definiert Zur Berechnung von Risikokennziffern einer Bankposition m ssen erst alle Cashflows dieser Position ermittelt werden Das Diagramm zeigt also eine Momentaufnahme des Entwurfsvorganges in der bestimmte Dialogelemente konkret bereits feststehen andere erst abstrakt vorliegen Es k nnte jedoch genauso gut der Entwurfsvorgang bereits abgeschlossen sein und nur f r bestimmte Dialogelemente gerade statt der konkreten Sicht die abstrakte Sicht gew hlt worden sein Pfeile zum Triggern von Ereignissen mit Wert bertragung Mit Ausnahme des schwarz
252. nd 2 das Ereignis e Schlie e Ereignis an Stelle s f r eine Stelle s darstellt e erc s s und die Stelle s nicht bereits geschlossen ist Es gilt e q e U Uos U o s s es ses q q wobei q q sonst d h andernfalls wird der Zustand q beibehalten 86 5 3 Grafische Darstellung 5 3 Grafische Darstellung Im Folgenden soll im Einzelnen auf alle grafischen Elemente n her eingegangen werden Die Elemente sind teilweise aus vorher angef hrten Beispielen bereits bekannt werden aber hier alle noch einmal der Vollst ndigkeit halber aufgef hrt Zuvor soll noch einleitend auf einige grundlegende Aspekte der gew hlten grafischen Darstellung eingegangen werden 5 3 0 Kernaspekte der grafischen Darstellung In dem in diesem Kapitel bisher vorgestellten Ereignisstellenmodell sind Sprachelemente enthalten die es erlauben den Dialog zwischen Mensch und Maschine in einer relativ komprimierten Darstellung zu beschreiben Wir haben im vorhergehenden Kapitel Kap 4 diskutiert wie wir von einer extensiven konkreten Darstellung von Ereignisfolgen in mehreren Stufen zu dieser intensivierten Darstellung gelangen Unser Augenmerk lag dabei ausgehend von einem Grundmodell mit Ereignisfolgen auf der Vermeidung zu vieler Folgenstellen und Stellen berg nge Dazu trugen im Wesentlichen bei die Zusammenfassung einwertiger Stellen zu Stellen mit Wertebereichen die Einf hrung eines Ged chtnisses
253. nd Widgets 102 6 1 Abbildung der Ereignisstellen auf konkrete Widgets 103 6 1 0 Konkretisierung als Instanz der Klasse JRadioButton 104 6 1 1 Konkretisierung mit vier Instanzen 106 6 l 2 Einbettung des Modells RadioButton in anderen Dialog 107 6 2 WYSIWYG Darstellung der Ereignisstellen 108 7 Exemplarische Darstellung und Variation 112 7 0 Problemstellung 112 7 1 Zielsetzung der Exemplarvariation 113 7 2 Merkmale der Exemplarvariation 114 7 3 Einfaches Variationsbeispiel 114 7 4 Im ESM implizit vorhandene Variationsarten Built in Variations 116 7 5 Variation einer Existenzvariation 117 7 5 0 Beispiel Variation zur Ausl sung eines Druckdialogs 117 5 8 9 10 11 12 13 7 3 Variation der Zielstelle Modell Beispiel 8 0 Aufgabenstellung des zu modellierenden Systems 8 1 Elemente eines Ereignisstellen Diagramms f r das JobEditor Modell 8 2 Erl uterung und Diskussion des Beispiel Diagramms 8 2 0 Dynamik 8 2 1 Ereignistypen 8 2 2 Hilfsstelle SaveToModel 8 2 3 Variationen 8 2 4 Zuordnung konkreter Laufzeitstellen 8 2 5 Anbindung der Applikationslogik 8 2 6 Darstellung von Teilsichten Vergleich mit bekannten Ans tzen 9 0 Koroutinen Konzept von Jacob 9 1 Ereignismodell von Green 9 2 Dialognetze 9 3 State Charts UML Harel 9 4 Pi Kalk l 9 5 Hierarchical Interactive Graph Templates HITs 9 6 Sketchingsysteme Realisierung im
254. nd zwei weitere Parameter die die Berechnung beeinflussen Auf sie soll hier nicht n her eingegangen werden da sie f r die Diskussion unseres Modells nur beispielhaften Charakter als bestimmte Attribute eines zu erfassenden bzw zu pflegenden Datenbank Re cords haben Die einzelnen Teilschritte eines Jobs sollen nun im JobEditor in ihren Attributen JobStepName SourceStepl FieldGroup definiert werden Insbesondere sollen die Abh ngigkeiten der JobSteps voneinander grafisch visualisert und ebenfalls grafisch editiert werden k nnen 8 1 Elemente eines Ereignisstellen Diagramms f r das JobEditor Modell Abb 8 1 zeigt die Dialogmodell Teilsicht des JobEditors in einem Ereignisstellendiagramm wie es derzeit in einem Prototypen dargestellt werden kann Die verschiedenen Farben der Diagrammelemente haben formal keine Bedeutung f r die Interpretation Die Elemente sind auch ohne Farbe eindeutig definiert Sie werden hier aber als n tzliches Hilfsmittel zur leichteren Unterscheidung auch in der folgenden Diskussion verwendet Ereignisstellen als Rechtecke Die Rechtecke zeigen Ereignisstellen bzw die dadurch repr sentierten Dialoge in ihrer hierarchischen Struktur Das graue umfassende Rechteck repr sentiert den kompletten JobEditor Dialog die alle Stellen zusammenfassende Stelle Darin enthalten sind Ereignisstellen zur Abwicklung des Dialogs zur Auswahl der Operationen SelectOperations zur Auswahl eines aus der Date
255. ndere Systeme verwenden das durch ein Datenbankschema vorliegende Datenmodell zum Aufbau der Oberfl chenelemente wie z B der Formulare und zur Realisierung der zugeh rigen Dialoge und Applikationslogik zum Erfassen ndern und Suchen der Daten Beispiel DialogBuilder Dialoggenerator SIEMEN94 In der Regel ist das Ergebnis von Modellierung und Generierung eine relativ schematische stereotype Umsetzung an der Oberfl che die aber in einfachen Anwendungsf llen ausreichen mag Das statische Datenmodell bzw Objektmodell gen gt allerdings nicht f r eine umfas sende und flexible Definition der Dynamik des Dialogs im allgemeinen Fall 1 1 1 Modellierung der Dynamik F r eine spezifische Darstellung der Dialogdynamik gibt es eine Reihe von Modellans tzen die zum Gro teil auf allgemeinen Modellans tzen zur Darstellung von Dynamik beruhen zum Teil auch aus anderen Anwendungsgebieten bernommen und f r die spezifischen Anforderungen der Dialogmodellierung erweitert bzw angepasst wurden Wir wollen im Folgenden nur kurz auf diese Ans tze eingehen da sie aus der Literatur als bekannt vorausgesetzt werden k nnen Es sollen nur die wesentlichen Merkmale im Hinblick auf Vor und Nachteile f r die Dialogmodellierung angesprochen werden die diese Arbeit insbesondere die Entwicklung des Ereignisstellenmodells beeinflusst haben oder mit ihr vergleichbar sind Auf in diesem Sinne wichtige Beispiele wird im Kapitel 9 noch n her eingegangen
256. nderen Dialogstellen repr sentieren jeweils ein Ereignis mit einem einzigen Wert 50 4 1 Reduktion von Stellen und Transitionen Allgemeiner formuliert haben wir deshalb eine Funktion amp wes die einer Stelle s genau die Menge aller Werte als Wertebereich zuordnet auf die die Funktion die Paare s ehist mit beliebigen Ereignisteilfolgen ehist EHIST abbildet Die Wertebereichszuordnung ist eine Funktion WwEB S gt Potenzmenge W dabei gilt WB wweg s w w e W mit 3 ehist EHIST mit o s ehist w s ehist steht dabei wie bereits bei Definition des Grundmodells erw hnt f r eine Stelle s in einer bestimmten Situation des Dialogs n mlich nach Eintreten einer Teilfolge ehist f 0 fG von Ereignissen in einer Folge f f r eini e N Wenn wir eine neue Stelle s durch Zusammenfassung einer Menge von Stellen S konstruieren k nnen wir den Wertebereich wie folgt festlegen WB owegB s w we W mit 3 S ehist EHIST mit s ehist w wobei S die Menge der zusammengefassten Stellen bezeichnet An beiden genannten Eingabestellen unseres Bankautomaten Beispiels erfolgt nach der Ein gabe eine Pr fung des eingegebenen Wertes Die eingegebene Geheimzahl muss selbstver st ndlich mit der der eingeschobenen Karte zugeordneten Geheimzahl bereinstimmen und bei dem eingegebenen Geldbetrag darf unter Umst nden ein gesetztes Limit nicht berschrit ten werden Die entspr
257. ndler arbeiten unabh ngig voneinander die Ereignisse ab Es wird auch keine Aussage ber die Reihenfolge des Sendens von Ereignissen an verschiedene Event Handler gemacht Abgrenzung zum ESM Ereignisse die durch Typ und Wert charakterisiert werden sind sowohl im Ereignismodell wie auch im Ereignisstellenmodell ein zentraler Begriff Dabei ist im ESM der Ereignistyp der nach Eingabe Ausgabe und internem Schreibereignis unterscheidet abstrakter als der im Ereignismodell wo zun chst an physikalische Ereignisse die ber Eingabeger te erzeugt werden gedacht ist Aber auch im Ereignismodell werden Ereignistypen erlaubt die frei definiert und den Bed rfnissen der Applikation angepasst werden k nnen GREEN86 An die Stelle der Event Handler tritt im ESM der Stellenbegriff Interessant ist dass im Ereignismodell Event Handler kreiert und gel scht werden k nnen wie dies in hnlicher Form f r Stellen im ESM geschehen kann die er ffnet und geschlossen werden k nnen Der Begriff Event Handler dr ckt die Vorstellung der prozeduralen Abarbeitung der zugeordneten Ereignisse aus Eine Stelle im Ereignismodell ist im Unterschied dazu ein abstrakter Begriff der die Ressource in Ort und Zeit repr sentiert an der ein Ereignis festgestellt werden kann und an der u U ein Wert als Resultat des Ereignisses abgelesen werden kann Eine Ereignisstelle repr sentiert also mehr die Quelle des Ereignisses oder das Ereignis selbst w hrend der Event
258. ndmodell resultieren dass alle Ereignisse im Dialogablauf in einer bestimmten Reihenfolge einzuordnen sind wobei aber die Reihenfolge dieser Dialogschritte logisch unbedeutend ist Ziel des folgenden Abschnittes ist es zu einer weiteren Reduktion der notwendigen Darstel lung von berg ngen in unserem Modell zu kommen um damit eine Modellierung in der Praxis zu erm glichen bzw diese signifikant zu verbessern 4 2 0 Differenzierung der Stellentransitionen Bisher haben wir den Dialogfluss in homogener Weise durch die Ereignisfolge beschrieben Im Grundmodell wird jeder m gliche Schritt von einem Ereignis zum n chsten in gleicher 59 4 Bottom up Modellierung und Abstraktion Weise durch aufeinander folgende Folgenglieder e ei 1 in einer Folge f dargestellt Im bisher entwickelten Modell Grafen bedeutet dies zwei Ereignisstellen als Knoten mit einer gerichteten Kante zu verbinden Der bergang von einer Stelle zur anderen bedeutet das Eintreten eines Ereignisses aus der Menge der Ereignisse an der Folgestelle nach dem Eintreten eines Ereignisses aus der Menge der Ereignisse der Vorg ngerstelle Die Darstellung ist f r jeden bergang gleich d h es wird keine Aussage ber die Ursache der Ereignisfolge d h den Zusammenhang der beiden nachfolgenden Ereignisse bzw Ereignismengen gemacht ob beispielsweise der bergang von einem Ereignis zum anderen rein zuf llig ist oder ob es sich um einen unausweichlichen z B modalen oder vom
259. ne Entscheidung bez glich des weiteren Verlaufs des Dialogs gefragt werden kann Um dabei die Applikationslogik zu unterst tzen werden wie oben angedeutet Identifikatoren f r die durchlaufenen Modellstellen und Eingabewerte gespeichert auf die die Applikationslogik zugreifen kann Eine weitere Voraussetzung ist dass die gew hlten Widgets dazu geeignet sind die mit den Ereignissen verbundenen Werte der Eingabe und Ausgabe in definierter Weise darzustellen 4 0 1 Wahl von Widgets als Stellenmenge zur Laufzeit Wie oben erw hnt wird letztlich jedes Ereignis einer Stelle zur Laufzeit zugeordnet Betrachten wir beispielsweise den Bildschirm als unsere Stellenmenge w hrend des Ablaufs des Dialogprogrammes Dann k nnen wir die Pixel als primitive Teilstellen interpretieren die mittels Eingabe und Ausgabeereignissen mit Pixelwerten belegt werden 42 4 0 WYSIWYG Ansatz Betrachten wir hingegen die Menge aller denkbaren Widgetinstanzen als unsere Stellenmen ge so k nnen wir ein Widget als eine einem Dialogereignis zugeordnete Dialogstelle inter pretieren Diese Widgetinstanzen werden wiederum auf die Pixelstellen am Bildschirm abgebildet Eine Dialogstelle ist h ufig zusammengesetzt aus Ausgabe und Eingabestellen Erlaubt das Widget keine Eingabe handelt es sich um reine Ausgabeereignisse an der Stelle und damit um eine reine Ausgabestelle Handelt es sich um ein Widget zur Eingabe repr sentiert das Widget neben Eingabeereignissen
260. ne Menge von Stellenpaaren ersetzt bei denen sich jeweils die erste Stelle unterscheidet 7 5 1 Variation der Zielstelle Wenn wir die Stelle in die der Pfeil einm ndet also im Beispiel den Druckdialog als weiteren Variationsgegenstand mit in unser Variations Beispiel aufnehmen und als weiteren Aspekt der Variation die Identifikation dieser Stelle angeben k nnen wir damit auch die Instanz des Druckdialogs variieren In die Ausgabestruktur der Variationsfunktion ist dann noch der Bezeichner f r die jeweilige Instanz des Druckdialogs mit aufzunehmen Da wir die Stelle selbst und nicht die Referenz auf die Stelle als Gegenstand der Variation definieren bedeutet dies dass vom System eine Instanz mit dem von der Variationsfunktion gelieferten Bezeichner falls n tig erzeugt und mit den Merkmalen des Druckdialogexemplares belegt wird Wir haben bisher den Gedanken der Exemplarvariation informell und m glichst allgemein g ltig ausgef hrt Zu einer formalen Darstellung der Exemplarvariation f r den Aspekt Kardinalit t mit inkrementeller Variation sei auf Anhang E verwiesen Dazu wird eine Erweiterung des Ereignisstellenmodells aus Kap 5 vorgenommen und es werden sogenannte Modellkonfigurationen die eine dynamische nderung des Modells beschreiben eingef hrt Die Anregung zur formalen Darstellung der Systemzust nde als Folge von Konfigurationen stammt dabei aus EICKELO1 118 8 0 Modellbeispiel 8 Modell Beispiel In diesem K
261. ngefasst wurden Umgekehrt k nnen im ESM bekannterma en abstrakte Ereignisstellen mehrere Ereignisse zusammenfassen die unterschiedliche Werte und unterschiedliche Typen besitzen Die Ereignisse mit ihren unterschiedlichen Werten k nnen dabei hintereinander eintreffen und oder stellen Alternativen f r ein zeitlich gesehen einmaliges Ereignis dar Wenn wir die abstrakte Stelle 1 zu 1 mit einer WYSIWYCG Stelle darstellen wollen haben wir prinzipiell dieselbe Problemstellung wie bei der oben geschilderten Zusammenfassung mehrerer abstrakter Stellen an einer WYSIWYG Stelle Die WYSIWYG Darstellung ist nur eine Momentaufnahme also ein bestimmter Zustand bzw eine bestimmte alternative Auspr gung der Stelle mit einer ganz konkreten Belegung von Werten 110 6 2 WYSIWYG Darstellung der Ereignisstellen Hier gibt es wie oben verschiedene M glichkeiten der Darstellung die einer gew nschten WYSIWYCG Charakteristik unterschiedlich nahe kommen 1 Exemplarische Darstellung mit Annotationen Wir k nnen das Problem so l sen wie wir es oben am RadioButton Beispiel auch f r den Fall der Zusammenfassung mehrerer abstrakter Stellen mit einelementigen Ereignismengen geschildert haben Die WYSIWYG Darstellung wird nur als exemplarische Darstellung aufgefasst und soweit n tig werden Annotationen angef gt So k nnen Wertebereich und Ereignistypen und oder Ereignismengen annotiert werden Wert bertragungen an die Stelle k nnen mithilfe von Propagations
262. nkrete Widgets 6 1 2 Einbettung des Modells RadioButton in anderen Dialog In der Regel ist ein RadioButton nat rlich in einen umfangreicheren Dialog eingebettet und es gibt dann h ufig Abh ngigkeiten zu anderen Teildialogen Im ESM k nnen sich Abh ngigkeiten eines Dialogs wie er z B durch das Modell RadioButton im Folgenden auch einfach RadioButton oder rad genannt beschrieben ist zu anderen Dialogen aufgrund der in der formalen Modelldarstellung gegebenen Relationen wie folgt ergeben 1 Der RadioButton ist hierarchisch in einen Dialog als Teildialog eingeordnet Zur Erinnerung an die formale Definition Es gibt dann ein Element s rad HS mit seS 2 Aufgrund eines Ereignisses an einer anderen Dialogstelle wird der durch den RadioButton ausgedr ckte Dialog er ffnet oder geschlossen Zur Erinnerung an die formale Definition in Kap 5 Es gibt dann ein Element s rad ROH oder s rad e RCH 3 Aufgrund eines Ereignisses an einer anderen Dialogstelle werden Ereignisse an einer der Teilstellen er ffnet bzw gesperrt Teilstelle wird ge ffnet bzw geschlossen Gegebenenfalls wird ein der Teilstelle zugeordnetes Ausgabeereignis propagiert Zur Erinnerung an die formale Definition Es gibt dann ein Element s S ROH oder s S RCH f r ein S mit S Teilstelle von rad i 0 1 2 oder 3 Ggf existiert dann eine Propagationsfunktion p mit rRO sRoSi p so dass das propagierte Ereignis e p o
263. nm glich macht Ein Informationsverlust liegt dann vor wenn es nach den zusammengefassten Teilfolgen aufgrund des vorher abgelaufenen Dialogs jeweils alternative Fortsetzungen der Ereignisfol gen gibt Ohne den Aufbau eines zus tzlichen Ged chtnisses das uns sagt aus welcher der alternativen Dialogabl ufe wir urspr nglich zum aktuellen Knoten gelangt sind k nnen wir dann keine Entscheidung mehr bez glich der Fortsetzung unseres Dialoges f llen D h aus der Kenntnis des aktuellen Knotens im Grafen allein k nnen wir die Fortsetzung des Dialogs nicht mehr bestimmen Wie man im gew hlten Beispiel schnell sieht k nnen dort die Teilfolgen am Ende zu einem einzigen Teilpfad zusammengefasst werden Abbildung 4 4 Die Ereignisfolgen am Ende der zusammengef hrten Alternativpfade sind unabh ngig von den vorher eingeschlagenen alter nativen Wegen 45 4 Bottom up Modellierung und Abstraktion Abbildung 4 4 Zusammenf hrung identischer Folgen bzw Stellen Im Beispiel ist der Dialogschritt System gibt Diskette aus allen drei Pfaden gemein und somit generell von der Vorgeschichte im Dialog unabh ngig Die Dialogschritte Fehler bei Installation und Installation erfolgreich sind von der vorhergehenden Auswahl des Installa tionsumfangs unabh ngig Unabh ngig ist hier so zu verstehen dass die m glichen Dialog schritte in den jeweiligen Pfaden identisch sind Dies bedeutet nat rlich nicht dass beim tats chli
264. nmittelbar ein Wert zugeordnet werden kann n mlich einem Slot bzw einem Messageport Stattdessen existiert im ESM in der Regel eine Hierarchie von Stellen Es gibt keine explizite Unterscheidung zwischen Alternativ und Tupelstellen Ob eine Stelle alternativ zu einer anderen Stelle ge ffnet instantiiert wird wird ber entsprechende alternative Conditions an Stellen berg ngen zu diesen Stellen gesteuert Es bedeutet weiter dass der Begriff Stelle im ESM auch die Aufgabe der Begriffe Slot und Messageport bernimmt Dies liegt im Wesentlichen daran dass eine Stelle einerseits wie ein Slot oder Messageport einen Wert besitzt und andererseits eine Stelle Ereignisse erwarten kann die wiederum Ereignisse mit Werten an anderen Stellen propagieren k nnen was in der 144 9 5 Hierarchical Interactive Graph Templates HITs Hitsprechweise dem Verbreiten einer Nachricht via Messageport entspricht hnlich wie bei einem Messageport kann eine Stelle einen bergang eine Transaktion ausl sen wenn ein Ereignis an der Stelle sich ereignet was beim Messageport in diesem Sinne dem Eintreffen einer Nachricht und Propagieren der Nachricht gleichgesetzt werden kann Stellen im ESM werden nach Typ Eingabe Ausgabe und Hilfsstelle lt verborgene Stelle f r Schreibereignisse des Systems unterschieden Eine differenziertere Typisierung wie die der Slots und Messageports mit Argument und Resultatslots sowie lokalen Slots wobei nur diese Eingabe ode
265. nn hier standardm ig die Ausgabe von Off auf isSelected false erfolgen ZE tl On OO Ei On O Oo co On gt Generator On Off E l On E Of SomeDialog1 SomeDialog2 Abbildung 6 6 WYSIWYG Darstellung eines RadioButton mit nur einer Stelle Hier wird das RadioButton Modell mit nur einer Stelle gezeigt Der WYSIWYG dargestellte RadioButton kann nur exemplarisch einen Zustand darstellen Die Stelle des Ereignisstellendiagramms fasst alle vier abstrakten Stellen Abbildung 6 2 Abstraktion eines Radio Buttons mit 4 ESD Stellen zu einer Stelle zusammen der alle m glichen Ereignisse annotiert sind Die Zustandswechsel des RadioButtons sind hier nicht mehr durch Kanten gezeigt Dies ist allerdings f r eine korrekte Implementierung nicht n tig da die Zustandswechsel in der Implementierung der Klasse JRadioButton bereits enthalten sind Allerdings muss jetzt explizit eine Zuordnung der logischen Ereignisse zu den m glichen konkreten Ereignissen des RadioButtons erfolgen Au erdem muss durch Annotation gekennzeichnet werden welche z B der m glichen Eingabe Ereignisse einen Stellen bergang bewirken wenn nur bestimmte Ereignisse an der Stelle als Triggerereignis in Betracht kommen WYSIWYG Darstellung einer abstrakten Ereignisstelle mit mehrelementiger Ereignismenge Wir haben eben alternative WYSIWYG Darstellungen eines Modells diskutiert in dem primitive abstrakte Stellen an WYSIWYG Stellen zusamme
266. notation ist im Prototyp soweit implementiert dass Anwendungen der Art des in Kap 8 beschriebenen JobStepEditors realisiert werden k nnen Gegen ber der in Kap 8 beschriebenen Notation gelten im derzeitigen Entwicklungsstand noch einige Einschr nkungen bzw Abweichungen die aber die notwendige Funktionalit t f r die Implementierung des Beispiels von Kap 8 nicht beeintr chtigen Die Abweichungen stellen sinnvolle und diskussionsw rdige Alternativen zur Notation in Kap dar 10 2 5 0 Aspekte der Variation im Prototyp Dies bedeutet dass insbesondere als Aspekte der Variation die Anzahl eines Exemplars Cardinality die Identit t eines Exemplars Identity der Wert Value sowie die Klasse des Widgets Class auf die eine Ereignisstelle abgebildet wird variieren k nnen Sind dies Attribute die auch einer abstrakten Stelle zugeschrieben werden k nnen sind als weitere Aspekte der Variation Attribute konkreter Widgets wie Position und Gr e zugelassen 10 2 5 1 Variationsereignisse Als m gliche Ereignisse die eine Variation ausl sen sind im Prototyp vorgesehen Der Start der Applikation EventType ApplicationsStart Das Kreieren des Parentobjektes EventType ParentCreation Das Kreieren oder ffnen des Exemplars selbst EventType Creation oder Open Das Kreieren einer anderen Widget Instanz EventType Creation oder Open EventObject lt ObjectName gt KeyEvents einer Widget Instanz EventType KeyEvent E
267. nsch Computer Schnittstellen Informatik Forschung und Entwicklung 9 1 3 1994 Bastide R Palanque P Petri Net Objects for the Design Validation and Prototyping of User Driven Interfaces Diaper et al editors Human Computer Interaction INTERACT9O proceedings Elsevier Science Publishers 1990 Booch G Rumbaugh J Jacobsen I The Unified Modeling Language User Guide 9 printing Object Technology Series Addison Wesley 2001 Cypher A EAGER Programming Repetitive Tasks by Example Human Factors in Computing Systems Proceedings of SIGCHI 91 ACM p 33 39 1991 DIN Deutsches Institut f r Normung DIN 66 234 Teil 8 Grunds tze ergonomischer Dialoggestaltung Beuth Berlin K ln 1988 Eickel J Logical and Layout Structures of Documents Computer Physics Communication 61 201 208 1990 Eickel J Architektur von generativen Oberfl chenwerkzeugen Personal Communications 1991 Eickel J Generierung von Bedienoberfl chen Vorlesungen an der TU M nchen Sommersemester 2001 Eisenstein J Puerta A Adaptation in User Interface Design TUI 2000 New Orleans ACM 2000 Eisenstein J Vanderdonckt J Puerta A Applying Model Based Techniques to the Development of UIs for Mobile Computers TUT O1 Santa Fe New Mexico USA ACM 2001 F hnrich K P Ziegler J Direkte Manipulation als Interaktionsform an Arbeitsplatzrechnern Software E
268. ntiierungsregeln Transaktionsregeln Im Gegensatz zu Gleichungsregeln besitzen Transaktionsregeln neben Slots mindestens einen Messageport als Argument und k nnen als Ausg nge sowohl Slots als auch wieder Messagepotts besitzen an die Nachrichten weitergegeben werden k nnen Transaktionsregeln werden ausgel st wenn an all ihren Messageporteing ngen Nachrichten anliegen Benutzertransaktionsregeln Benutzertransaktionsregeln sind eine besondere Form von Transaktionsregeln Sie werden durch ein Benutzerereignis ausgel st und k nnen zus tzlich so genannte interaktive Argumente besitzen die bei Eingabe vom Benutzer mitgegeben werden Benutzertransaktionsregeln gleichen bez glich ihrer Eing nge sonst den Gleichungsregeln und bez glich ihrer Ausg nge den anderen Transaktionsregeln Instantiierungsregeln Statt der Erzeugung von Resultatwerten haben Instantiierungsregeln die Wirkung dass eine Hitinstanz angelegt wird Sie werden wie Benutzertransaktionsregeln ausgel st und k nnen die gleichen Argumentarten besitzen Informelle Gegen berstellung Hit Spezifikation und ESM Im ESM tritt als zentraler Begriff die Ereignisstelle an die Stelle der Begriffe Hit Slot und Messagepott einer Hitspezifikation Dies bedeutet dass im ESM kein begrifflicher Unterschied gemacht wird zwischen einer zusammenfassenden Einheit wie dem Hit einserseits der zudem noch in Alternativen und Tupelhit differenziert wird und einer Einheit andererseits der u
269. ntreten das den bergang zum ffnen ausl st Erst dann wird das Widget sensitiv gesetzt bzw f r die Eingabe aktiviert Bei reinen Ausgabestellen und allen nicht primitiven Stellen bedeutet das formale ffnen einer Stelle auch genau das ffnen der Widgetinstanz im blichen Sprachgebrauch im Sinne von kreieren falls dies nicht schon geschehen und sichtbar machen Entsprechend wird im Prototyp das Schlie en interpretiert Ist eine primitive Eingabestelle formal zu schlie en wird das Widget f r die Eingabe gesperrt bleibt aber sichtbar Es wird erst mit dem Container unsichtbar In allen anderen F llen ist wiederum das formale Schlie en mit dem unsichtbar machen eines Widgets gleichzusetzen 157 10 Realisierung im Prototyp 10 2 3 Codegenerierung f r stellenspezifische Klassen Dabei wird prinzipiell f r jede Ereignisstelle eine entsprechende Klassendefinition codiert wobei wiederum f r Stellen gleichen Namens mit gleicher bergeordneter Stelle dieselbe Klassendefinition gilt die dann entsprechend nur einmal erzeugt werden muss siehe oben Merge von Stellen und Zustandsstellen Die generierte Klasse erh lt als Namen den Namen der Ereignisstelle dem ein Prefix zur eindeutigen Unterscheidung von etwaigen generierten Instanznamen oder Klassen anderer Stellen vorangestellt wird In die Klassendefinition werden im Wesentlichen Konstruktoren zur Erzeugung der Instanzen sowie Listener Klassen zur Verarbeitung der Ere
270. ntritt eines Ereignisses mithilfe einer Propagationsfunktion ein neuer Wert ermittelt wird und dieser ber ein Ausgabeereignis an der Stelle eingetragen wird Die Stelle kann als ein Exemplar betrachtet werden das stellvertretend f r verschiedene Varianten mit unterschiedlichen Stellenwerten im Modell dargestellt ist Die Propagationsfunktion bernimmt in diesem Fall die Aufgabe der Variationsfunktion Ebenso kann im erweiterten Sinne als eine Variation betrachtet werden wenn eine Stelle vom Zustand geschlossen in den Zustand ge ffnet wechselt oder umgekehrt Dabei betrachten wir den Zustand des Ge ffnet Seins als ein Attribut der Stelle mit booleschem Wert TRUE oder FALSE Eine Condition die bei Eintritt eines bestimmten Ereignisses ausgewertet wird kann dann als Variationsfunktion betrachtet werden die den neuen Wert des Ge ffnet Zustandes berechnet In diesem Sinne kann der Wechsel des Ge ffnet Zustands von TRUE nach FALSE und umgekehrt auch als ein Dialog Ereignis betrachtet werden Im oben geschilderten Beispiel wurde dies bereits stillschweigend angenommen als wir die Durchf hrung der Variation an das Ereignis des ffnens der Toolbar gekoppelt haben Eine exakte Definition bzw Interpretation dieses Ereignistyps sei allerdings der formalen Darstellung vorbehalten 116 7 4 Im ESM implizit vorhandene Variationsarten Die Variation des Ge ffnet Zustands wollen wir im Folgenden ebenfalls etwas salopp als Existen
271. oButtons setSelected true false nach Pr fung des Attributes selected mittels isSelected Sperren der Benutzereingabe In der Sprache des Modells bedeutet das Sperren der Eingabe f r den Benutzer beide Ein gabestellen So und S zu schlie en In der Implementierung bedeutet dies ein Insensitiv Setzen des RadioButtons mittels Methodenaufruf setEnabled false 6 2 WYSIWYG Darstellung der Ereignisstellen Im vorangegangenen Abschnitt haben wir anhand eines Beispiels diskutiert wie abstrakte Ereignisstellen auf konkrete Widgets in der Implementierung zur Laufzeit abgebildet werden k nnen Im Folgenden wollen wir nun erarbeiten wie bereits in einer Darstellung im Modell eine WYSIWYG Darstellung der Ereignisstellen unter Verwendung konkreter Widgets verwirklicht werden kann Wir werden zeigen dass damit eine gemischt abstrakt konkrete Darstellung im Modell m glich wird die einen relativ nahtlosen bergang von abstrakter zu konkreter Modellierung und umgekehrt innerhalb einer Modelldarstellung er ffnet Die WYSIWYG Darstellung in Abbildung 4 1 Beispiel f r WYSIWYG Modellierung zeigt konkrete Widgets in einzelnen Bildern Dabei repr sentiert jedes Bild ein Ereignis des Typs Eingabe oder Ausgabe Soweit notwendig wird das Ereignis das auf dem Widget bzw mit der Darstellung des Widgets erfolgt noch besonders gekennzeichnet Damit wird sowohl dem Betrachter als auch f r das System klar welche Art von Ereignis d h wel
272. odell nach Green GREENS6 Janssens Dialognetze JANSS96 die in die UML eingegangenen State Charts von Harel HAREL87 RUMBA91 Den genannten im Umfeld der Dialogmodellierung bekannten Modellen folgen Ausf hrungen zum Pi Kalk l von Milner MILNER99 einem allgemeinen Ansatz zur Modellierung von Interprozesskommunikation sowie modernere Ans tze zur Dialogmodellierung wie das HIT Konzept von Schreiber SCHREI97 und so genannte Sketchingsysteme z B LANDAYO00 9 0 Koroutinen Konzept von Jacob Rekursive Zustands bergangsdiagramme mit Aktionen und Bedingungen Ausgangspunkt bei Jacob sind Zustands bergangsdiagramme Jacob sieht allerdings keine zusammenh ngende Darstellung von Ereignissen und Zust nden aller Dialogobjekte in einem Zustands bergangsdiagramm Zustands bergangsdiagramme sind nur jeweils einzelnen Dialogobjekten den Interactive Objects zugeordnet Ein Zustands bergangsdiagramm kann Subdiagramme mit rekursiven Aufrufen beinhalten berg nge k nnen mit Aktionen Actions und Bedingungen Conditions belegt werden Tokens f r Eingabe und Ausgabe Interessant ist dass auch bei ihm Ausgabeereignisse als bergangsereignisse dargestellt werden Es gibt also Zust nde die durch Ausgaben erreicht werden Jacob sieht den Dialog als Folge abstrakter Eingabe und Ausgabeereignisse wobei Layout und grafische Details davon getrennt zu beschreiben sind Er sieht die Dialogspezifikation zun chst als die Darstellung der m g
273. oder aber unbedingt in Folge eines anderen Ereignisses oder in Folge anderer Ereignisse geschehen Die Folgebeziehung zweier Ereignisse kann kausalen Ursprung haben also in der Logik der Applikation begr ndet sein etwa im Sinne einer notwendigen Reaktion auf eine vorangegangene Aktion Sie kann auch aus dialogtechnischen Gr nden heraus bestimmt sein wenn wir etwa an die sukzessive seitenweise Ausgabe einer Liste von Werten denken die sich nicht logisch gegenseitig bedingen Wir haben dann eine logisch willk rliche Folge der Ausgabeereignisse bedingt etwa durch eingeschr nkte Verf gbarkeit von Ressourcen wie z B der Bildschirmfl che siehe dazu auch berlegungen in Abschnitt 4 2 0 1 3 1 Formale Darstellung des Grundmodells Das oben informell dargestellte Grundverst ndnis des Mensch Maschine Dialogs soll im folgenden Abschnitt in einer etwas formaleren Darstellung zusammengefasst werden Es sei hier darauf hingewiesen dass das Grundmodell nur als ein Ausgangspunkt f r die Erarbeitung eines f r die Systementwicklung nutzbaren Modells dient Ein System primitiver Dialoge D ist ein Tupel E T W S F 1 mit E Menge von Ereignissen T Menge von Ereignistypen T IB Os Ls Lg W Menge von Werten S Menge von Dialogstellen auch Ereignisstellen genannt F Menge von Ereignisfolgen auch Dialoge genannt f eo 1 En mit e eEf ri 0 1 n undneN f ist also eine Funktion f 0 n gt E t Zuordnungs
274. ogischen Dialog meist irrelevant Allerdings kann auch hier bei falscher Wahl manchmal die Qualit tsanforderung der Aufgabenangemessenheit verletzt sein Denken wir z B an die Wahl der Schriftgr e bei Sehbehinderten etc Der Vollst ndigkeit halber sei hier angemerkt dass Stylesheets etwa bei XML auch dazu verwendet werden k nnen um den Inhalt der Information zu beeinflussen z B zu filtern Diese Funktionalit t ist aber nicht als Merkmal eines bestimmten Dialogstils zu sehen 2 0 0 2 Definition der Dynamik Unter Dynamik des Dialogs verstehen wir allgemein seine zeitliche Entwicklung Dies umfasst im Wesentlichen die m gliche Abfolge von Eingaben und Ausgaben an der Dialogschnittstelle sowie den Ablauf des Dialogs in Abh ngigkeit der spezifischen Situation des aktuellen Kontexts der Anwendung Wir k nnen hier wiederum zwischen einer Dynamik des Dialogs unterscheiden die sich aus der logischen Aufgabenstellung ergibt und einer Dynamik die aus der Wahl eines bestimmten Layouts und der technischen Implementierung resultiert In Abschnitt 4 2 1 wird noch n her auf Kriterien der Dialogdynamik eingegangen Als Beispiel f r eine layoutbedingte Dynamik sei hier genannt dass von der Dialogart abh ngig der Ablauf des Dialogs bestimmt werden kann W hrend in einem Formulardialog mehrere Datenfelder gleichzeitig am Bildschirm erscheinen und h ufig in beliebiger Reihenfolge dort Werte eingegeben werden k nnen werden in einem Frage Antwor
275. olesche Funktion soll im Folgenden als Condition oder Pr dikat siehe EickelO1 bezeichnet werden In der formalen Darstellung unseres Modells f hren wir somit ein FS Menge der durch die Ereignisfolgen induzierten Stellenfolgen fs fs Ne S wobei fs durch eine Ereignisfolge f F F Menge der Dialogereignisfolgen wie folgt definiert ist fs j o e f r ej e f und j Nr 0 n N Definitionsbereich von f Relation der Stellen berg nge c S x S wobei s s amp J i e N fs e FS mit fs i sin RG 1 s 56 4 1 Reduktion von Stellen und Transitionen also s Vorg nger von s f r ein fs e FS C Menge der Conditions Beis als Funktionen der Form Pesi sj WS gisis gt TRUE FALSE I wobei WSgii s Menge aller Wertezuordnungen auf einer definierten Stellenmenge Spesi sj em S also WSpci sj s s ist Funktion s Spesi sj gt W X Ein bergang von Stelle s nach Stelle sj soll nur dann stattfinden wenn die Condition esi sj angewandt auf die aktuell g ltige Wertebelegung s x an den Stellen in Spesi den Wert TRUE liefert also wenn gilt Besisj Sakt TRUE Die aktuelle g ltige Wertebelegung wird definiert durch Sak S s ehist f r s Sgi mit ehist EHIST als aktuell abgelaufener Teilfolge von Ereignissen Auf diese Weise wird beispielsweise erm glicht dass die Historie der Dialogf hrung f r die Entscheidung der Fortsetzung herangezo
276. on die durch Variation von HS entsteht HS HS U HSubneu U HSuperneu HSuperneu ist die hierarchische Einordnung der Stellen aus Sneu unter die mit der Exemplarstelle svar gemeinsamen bergeordneten Stelle falls diese vorhanden HSuperneu s s mit s Sneu und s svar HS und svar VarS und f r HSubneu gilt s s e HSubneu amp J3s e Sneu mit s s SSub und origSneu s origSneu s e HS origS ist eine bez glich der Hierarchie strukturtreue Abbildung f r alle Teilstellen von s aus Sneu die jeder der Teilstellen von Stellen aus Sneu inklusive der Stellen aus Sneu selbst die in der hierarchischen Struktur entsprechende exemplarische Teilstelle bzw Stelle aus SSubsvar zuordnet origSneu U SSub SSubsvar seSneu Es gilt s s HS lt origSneu s origSneu s HS f r alle s e USSub seSneu Im Folgenden sei SSubneu USSub seSneu die Vereinigung aller Teilstellen von Sneu inkl Stellen selbst Au erdem wollen wir die Funktion origSneu im Definitionsbereich und Wertebereich erweitern zu einer Funktion orig SUniv gt SUniv die f r alle nicht neuen Stellen die Identit t liefert Dies erlaubt uns in den folgenden Ausf hrungen eine verk rzte Schreibweise Also orig s s falls s nicht eSSubneu orig s origSneu s sonst E FE E U Eneu 180 Anhang E Formale Darstellung der Exemplarvariation mit Eneu sneu t e
277. otentiellen k nftigen Nutzern abgestimmt ist Auch nach Fertigstellung des Systems und Freigabe f r Produktion und Wartung existiert kein berblick ber die Struktur des Dialogs keine Gesamtsicht des Dialogs die auch dem Designer oder Entwickler den Zugang zu relevanten Stellen der Imple mentierung zum Zwecke der nderung und Wartung erleichtern w rde Eine m hsame Suche im Code wird erforderlich wenn nicht wider Erwarten manuell erzeugte Dokumentation zum aktuellen Stand der Entwicklung vorhanden ist In g ngigen Entwicklungswerkzeugen f r grafische Oberfl chen fehlen grafische Darstel lungsm glichkeiten der Dialogdynamik v llig oder sind nur ansatzweise und dann nur auf der Ebene konkreter Oberfl chenelemente vorhanden Einige wenige Systeme zum Rapid Prototyping Rapid Development unterst tzen die Darstellung der Dialogdynamik rudiment r z B mit Wizards zur Codierung einfacher Ereignisroutinen oder ersten noch unvollst ndigen Ans tzen einer grafischen Darstellung dynamischer Relationen zwischen Objekten der Oberfl che Aber auch die Entwicklung der statischen Elemente der Oberfl che l sst W nsche offen Denn in der Phase des Designs ist die Wahl eines konkreten Dialogelementes h ufig noch nicht entschieden obwohl vielleicht Aspekte der dynamischen Anbindung des Objektes bereits festliegen Der Entwickler oder Designer ist dann dennoch gezwungen eine bestimmte Wahl f r ein konkretes Objekt zu treffen Eine sp tere nde
278. peicherung von Information besitzt und somit gezwungen ist sich Information zeitlich hintereinander zu beschaffen zu speichern und zu verarbeiten Fazit Die Modellierung der Dialogeinheiten und die zeitliche Reihenfolge der Darstellung ergibt sich also aus einem bestimmten Informationsbedarf eines der Dialogpartner Um m glichst effizient an die gew nschte Information zu kommen ist es notwendig dem anderen Dialogpartner sein Informationsbed rfnis mitzuteilen da dieses wiederum dem Partner in der Regel nicht unmittelbar bekannt ist Logisch nebenl ufige Ereignisse In vielen F llen ergibt eine Analyse der Aufgabenstellung dass aus logischer Sicht eine bestimmte Reihenfolge in den Dialogen bzw Teildialogen nicht vorgegeben ist Die Dialoge k nnen aus logischer Sicht in beliebiger Reihenfolge oder auch gleichzeitig abgearbeitet werden Wir sprechen dann von nebenl ufigen Dialogen bzw Teildialogen Im Zusammenhang mit einer m glichen Trennung zwischen der Eingabe von Daten und der darauf folgenden Abarbeitung durch die Applikationskomponente haben wir oben bereits ein derartiges Beispiel angesprochen die Reihenfolge der Dateneingabe kann z B irrelevant sein wenn das Lesen der Daten durch die Applikationskomponente erst erfolgt wenn alle Daten erfasst sind Die Eingabe der Daten kann also parallel bzw in beliebiger Reihenfolge durchgef hrt werden soweit nicht logische Abh ngigkeiten dagegen sprechen Im obigen Beispiel der Auftragser
279. pekt ist die Darstellung der Abh ngigkeiten der Ereigniswerte an den ge ffneten Stellen und damit auch der Abh ngigkeit der resultierenden Stellenwerte von 87 5 Ereignisstellenmodell Werten an anderen Stellen was wir als Aspekt des Datenflusses auffassen k nnen Dieser Aspekt steckt im oben dargestellten formalen Modell im Wesentlichen in den Definitions bereichen der Propagationsfunktionen mit denen definiert ist welche Stellen f r die Berechnung des Wertes an der Zielstelle des zugeordneten Stellen bergangs aus RO herangezogen werden Wir k nnen diese Abh ngigkeit der Werte auch als Wertetrans formation oder bertragung der Werte von Ausgangsstellen zu Zielstellen verstehen Ein hnlicher Aspekt f r den Pfeile als grafisches Ausdrucksmittel verwendet werden ist die Abh ngigkeit der einzelnen Pr dikate von Werten bestimmter Stellen zum Zeitpunkt eines potentiellen Stellen bergangs 5 3 1 Darstellungselemente eines Ereignisstellendiagramms ESD Im Folgenden werden die einzelnen Elemente der grafischen Darstellung aufgef hrt und den oben vorgestellten formalen Elementen des ESM gegen bergestellt Darstellung der Stellen und Stellenhierarchie Zentrales Element in einem Ereignis Stellen Diagramm ist die Ereignisstelle manchmal auch Dialogstelle oder auch nur kurz Stelle oder Dialog genannt Stellen k nnen ge ffnet und geschlossen werden Ist eine Stelle ge ffnet k nnen an ihr Ereignisse geschehen bzw festgeste
280. pid Development Systemen Die Definition der Dynamik der Oberfl che findet im Wesentlichen im Programmcode statt und ist schwer zug nglich Generell wird keine abstrakte logische Modellierung des Dialogs unterst tzt Rapid Development Systeme mit grafischen Dialogobjekt Editoren erm glichen eine schnelle konkrete Darstellung statischer Elemente des Dialogs und nur in einfachen F llen eine rasche Implementierung von Dynamik Modellbasierte Systeme hingegen unterst tzen im Prinzip einen abstrakten systematischen Entwurf Einige modellbasierte Systeme bieten insbesondere den Ansatz der Darstellung der Dynamik Die M glichkeiten zur Darstellung der Dynamik sind jedoch auch bei bisherigen Systemen mit grafischer Darstellung stark eingeschr nkt In modellbasierten Systemen fehlt zudem eine ausreichend intuitive Darstellung des Dialogs die auch einem potentiellen Benutzer und EDV Laien eine Vorstellung der Bedienoberfl che des zuk nftigen Systems erschlie t kein WYSIWYG Auch f r den Entwickler ist h ufig eine umfassende Gesamtdarstellung von Statik und Dynamik des Dialogs nicht m glich Dies 24 1 3 Res mee gilt insbesondere weil einerseits nicht an eine Gesamtdarstellung der Zusammenh nge gedacht ist Ereignismodell eine Darstellung der Nebenl ufigkeit in den meisten F llen nicht praktikabel ist z B Zustands bergangsdiagramme oder generell nicht unterst tzt wird Grammatiken Eine Umsetzung des Modells ist nicht zuletzt
281. ppe k nnen teilweise durch jeweils einen bergang zum bergeordneten Gruppenzustand ersetzt werden Ein bergang zum bergeordneten Zustand XOR Grouper oder AND Grouper bedeutet implizit auch einen bergang zu einem dann aktiven Unterzustand im XOR Grouper bzw zu allen Unterzust nden eines AND Grouper Zustands Vergleich mit Ereignisstellendiagrammen ESD s Der Gedanke der hierarchischen Aufteilung und der Darstellung nebenl ufiger Zust nde ist aus den State Charts in die Darstellung in Ereignisstellendiagrammen eingegangen Allerdings sind in Ereignisstellendiagrammen Stellen die nicht auf einem Pfad ber Triggerkanten direkt oder indirekt verbunden sind grunds tzlich als nebenl ufige Stellen aufzufassen d h als Stellen an denen prinzipiell gleichzeitig Ereignisse akzeptiert werden Die Aufteilung eines Zustandes respektive einer Stelle durch gestrichelte Linien entf llt Hinzu kommt dagegen die Notwendigkeit bzw M glichkeit eine Stelle explizit zu schlie en um zu kennzeichnen dass die Stelle keine Ereignisse mehr annimmt W hrend bei State Charts der bergang von einem Zustand A zu einem anderen Zustand B automatisch den Zustand A schlie t bleibt die Stelle A in einem ESD nach wie vor ge ffnet d h akzeptiert Ereignisse wenn ein bergang zu einer Stelle B erfolgt Der bergang zu Stelle B bedeutet nur ein zus tzliches Er ffnen einer weiteren Menge von Ereignissen oder ein Schlie en der Stelle B Die damit m g
282. punkt der Abfrage ist in der Regel das Objekt an dem ein Ereignis stattfindet Entsprechend ist der generierte Code dann Teil einer Routine die bei Eintreten des definierten Ereignisses angesprungen wird siehe oben ereignisgesteuerte Routinen 17 1 G ngige Ans tze der Realisierung von Dialogsystemen 1 0 1 4 Grafische Ans tze Einige Systeme bieten erste Ans tze zu einer grafischen Darstellung der Beschreibung des dynamischen Verhaltens von Dialogobjekten Eines der ersten Systeme dieser Art war z B ein Editor im System NeXT SHEBA93 Mithilfe von Pfeilen zwischen einzelnen Objekten konnten bestimmte Aktionen angedeutet werden hnliches gilt auch f r die grafische Darstellung dynamischer Bez ge etwa in der Entwicklungsumgebung Visual Cafe Dort f hrt ein Aktivieren des Pfeils zum Aufruf eines wie oben beschriebenen Code Wizards NetObjects Fusion CAT Computer Application Technology BAX Datei Bearbeiten Ansicht Gehezu Werkzeuge Hilfe a Fa Ei EH Eigenschaften 2l IxI g Online Site Seite Design Verwalten Pi e publizieren Struktur Gliederung z E Seitenname Home Seitentitel Home Benutzerdefinierte Namen Seitentyp Standard Master Rahmen DefaultlMasterBorder vr R Q Abbildung 1 3 Webseiten bersicht in NetObjects Fusion Grafische Darstellung einer hierarchischen Aufrufstruktur 1 0 2 Vorteile Die Vorteile des Einsatzes von Rapid Development Systemen mit WYSIWYG Darstellun
283. r berhinaus bieten ESD s allerdings die M glichkeiten einer komprimierten intensivierten d h redundanzfreien Darstellung auch komplexer Anwendungen mithilfe der zus tzlich vorhandenen Sprachmittel Abbildung 9 8 Storyboarding Beispiel Entwurf eines Shoppingsystems aus LINTH02 Gezeigt wird ein System Ausschnitt mit den Webseiten Checkout Card Wrap Card and Wrap und Shipping im System DENIM Checkout ist in 4 Zust nden zu sehen die sich durch die 4 Kombinationsm g lichkeiten der Eingabe in den Checkboxen Gift Wrap und Gift Card ergeben Je nach Zustand wird bei Mausklick auf Next die entsprechende Folgeseite ge ffnet Die Pfeile repr sentieren den bergang von einer Seite zur anderen oder zwischen Momentaufnahmen derselben Seite nach Mausklick auf das jeweilige Dialogelement Ist z B weder GiftCard noch GiftWrap angekreuzt erfolgt bei Mausklick auf Next das ffnen der Shipping Seite zur Angabe der Versandbedingungen Beispiel Shopping System Abbildung 9 9 auf folgender Seite zeigt wie mithilfe eines Ereignisstellendiagramms der Entwurf in Art der in Abbildung 9 8 dargestellten Storyboarding Technik durchgef hrt werden kann Dabei repr sentieren die vier Stellen des Diagramms mit Bezeichner Checkout vier Zust nde der gleichnamigen Webseite Wir d rfen dabei annehmen dass eine geeignete Implementierung f r das Ereignisstellendiagramm existiert die eine
284. r Ausgabeslots sein k nnen ist im ESM nicht gemacht An die Stelle der Anwendbarkeitsbedingung und der Vorbedingungen tritt im Wesentlichen im ESM die Condition Dabei ist allerdings zu unterscheiden dass eine Condition einem Stellen bergang zugeordnet wird w hrend Anwendbarkeitsbedingungen den Hitbausteinen unmittelbar zugeordnet und Vorbedingungen den Regeln Eingabe Messageports und Eingabeslots zugewiesen sind Letztlich kann aber ber beide Mechanismen vergleichbar gesteuert werden ob Objekte instantiiert werden ob Ereignisse stattfinden und bestimmte Werte gesetzt werden k nnen Die Funktion der verschiedenen Regeln der Hitspezifikation kann in gewissem Sinne im Kern mit der von Propagationsfunktionen die Stellen berg ngen im ESM zugeordnet sind gleichgesetzt werden Regeln werden wie Propagationsfunktionen bei Eintreten bestimmter Ereignisse aktiviert und berechnen Werte die an Slots und Messageports respektive Ereignisstellen weitergegeben werden Instantiierungsregeln bernehmen dabei zus tzlich die Aufgabe der Instantiierung eines Hits was beim ESM bereits alleine durch den Stellen bergang einer ffnerelation bewirkt wird Insgesamt kann festgestellt werden dass die verwendeten Begriffe im ESM weniger differenziert und bewusst auf einer einfachen klar strukturierten abstrakten Ebene gehalten sind Im Vergleich dazu werden in der Hitspezifikation die Elemente bereits st rker differenziert Die Sprache ist komplexer Der Benu
285. r Datenbank recherche im einfachsten Fall ist die Ausgabe in den Ergebniswerten variabel und die Struktur der Ausgabe noch fix z B fixes Ausgabeformular H ufig ist aber auch die Struktur der Ausgabe flexibel zu gestalten etwa variabel in der Anzahl der Felder des Formulars oder variabel in Spalten und Zeilen etwa bei tabellarischer Ausgabe Tabellen oder Formularfelder k nnen selbst wieder rekursiv Tabellen oder Formulare beinhalten Ist das Ergebnis der Suche z B eine Baumstruktur ist h ufig neben der Anzahl der jeweiligen Unterknoten auch z B die Anzahl der Hierarchieebenen variabel blicher genereller Weg ist zur L sung oben genannter Probleme die Verallgemeinerung Zusammenfassung Abstraktion Im Ereignisstellenmodell sind wir diesen Weg teilweise bereits gegangen indem wir z B Dialogstellen mit verschiedenen Werten zusammenfassen zu Stellen mit Wertebereichen Hierarchien bilden und indem wir Schleifen und Rekursivit t erlauben Die bisher gebotenen Sprachelemente sind aber in vielen der oben angeschnittenen F lle noch nicht ausreichend So haben wir beispielsweise noch kein komfortables Sprachelement im ESM daf r dass eine variable Anzahl von Dialogelementen bei Eintritt eines Ereignisses ge ffnet werden soll Wir k nnen dies zwar ausdr cken indem wir z B die Maximalanzahl der Elemente explizit auff hren und ber jeweils ein Pr dikat abpr fen ob der jeweilige Stellen bergang zum ffnen des Dialogelements durchzuf
286. r Information durch die Applikationslogik und somit die Befreiung von applikationslogischen Abh ngigkeiten auf der Eingabeseite Fazit Die Reihenfolge der einzelnen Dialogschritte kann durch logische den Ablauf optimierende Gesichtspunkte vorgegeben sein Dabei sind Abh ngigkeiten auf der Seite der Informationsabnahme also der Seite der Leseereignisse zum einen und Abh ngigkeiten auf der Seite der Versorgung der Dialogschnittstelle also der schreibenden Seite zum anderen mitunter getrennt zu betrachten Echtzeitliche Abh ngigkeiten Eine besondere Art von Abh ngigkeit in der Reihenfolge bzw in den Zeitpunkten der Darstellung von Dialogereignissen liegt vor wenn die Dialogschritte Ereignisse in Echtzeit darstellen sollen Dies ist z B dann der Fall wenn die absolute Zeit oder relative Zeitereignisse kontinuierlich oder in bestimmten Zeitintervallen anzuzeigen sind Hier ist die Reihenfolge der Zeitereignisse untereinander zum einen durch die Echtzeit diktiert Zum anderen finden die Ereignisse weitgehend unabh ngig von anderen Ereignissen im System statt Diese Eigenschaft echtzeitlicher Ereignisse legt somit nahe sie in die Klasse der aus Sicht des Dialogsystems asynchronen Ereignisse siehe unten einzuordnen deren Eintreten durch eine externe Ereignisquelle n mlich eine extern vorhandene Uhr bestimmt wird Eine Entkoppelung der Darstellung von Echtzeitereignissen von ihrem realen Eintreten selbst macht in vielen F llen wenig Sinn
287. r aus dem der Stelle zugeordneten Wertebereich darstellen Die Werte der Teilstellen JobStepName etc bestimmen sich erst fr hestens nachdem der Benutzer sich f r das Laden eines bestimmten Jobs aus der Datenbank entschieden hat Hier kommt die Einf hrung einer Variationsannotation zum Tragen Der mit dem Ausgabeereignis darzustellende Wert ist variabel und wird erst dynamisch zu einem bestimmten Zeitpunkt definiert Variationen von Teilstellen in JobStepGraph und von JobStepDetails Genauso wie die Werte der primitiven Ereignisstellen JobStepName SourceStepl und SourcStep2 variieren ist auch die Anzahl der diese Stellen enthaltenden zusammengesetzten Stellen JobStepl und Jobstep2 variabel Denn wir wissen erst nach dem Laden aus der Datenbank wie viele JobSteps ein Job enth lt Das gleiche gilt f r die Abh ngigkeiten der JobSteps die durch jeweils einen schwarzen Pfeil StepRelation repr sentiert werden Wir betrachten deshalb JobStepl und JobStep2 sowie StepRelation als Exemplare oder Repr sentanten einer Menge von Ereignisstellen deren Kardinalit t erst bei Eintreten des Ereignisses Ready bestimmt wird Die zu definierende Variation wird wiederum mittels einer bestimmten Funktion durchgef hrt Dabei ist zu bedenken dass mit der Anzahl der zu 123 8 Modellbeispiel ffnenden Teilstellen auch andere Attribute von Teilstellen variieren In unserem Beispiel variieren mit der Anzahl auch die Werte der primitiven Teilstellen W
288. r020000000000senoeenennesnennnsnsnnnnnennn 91 Abbildung 5 4 Darstellungen von Conditions 022224400402snsnnenessnnneennsnnnnennnennennennnnn 92 Abbildung 5 5 Darstellungen der Propagationsfunktion 2200ssssssssnesssnsenssnnnnennennnnn 93 Abbildung 5 6 Kennzeichnung von Startstellen 222200000022nsnesssennnensnsnnnnenensnnnnnnnnnnen 94 Abbildung 5 7 Auslagerung und gegenseitige Erg nzung in Teilsichten 98 Abbildung 6 1 Eingabestelle im Modell links und Implementierung durch Label und Textwidget mit Java rechts ass e ne 102 Abbildung 6 2 Abstraktion eines Radio Buttons mit 4 ESD Stellen u 104 Abbildung 6 3 Alternative Realisierung eines RadioButtons mit vier Widgets 105 Abbildung 6 4 Tabelle zur Implementierung RadioButton Modell mit vier Widgets 106 Abbildung 6 5 Darstellung des RadioButton Modells in zwei WYSIWYG Stellen 109 Abbildung 6 6 WYSIWYG Darstellung eines RadioButton mit nur einer Stelle 110 Abbildung 8 1 JobEditor als Anwendungsbeispiel eines Ereignisstellendiagramms 119 Abbildung 9 1 Beispieldiagramm nach Jacob aus JACOB86 mit Anzeige eines Oberfl chenobjektes ber Funktionsaufruf uueesessesssssnnnesnsnneeneennnnnnennnnnn 128 Abbildung 9 2 Spezifikation eines Dialogs zur Passwort nderung nach Jacob 1 Teil 129 Abbildung 9 3 Spezifikation
289. ramm die hier n her besprochen werden soll Das Gesamtmodell ergibt sich aus einer Reihe von Teilsichten die im Wesentlichen jeweils den Dialog darstellen der sich aus der Selektion einer der Hauptfunktionen Operationen des Systems ergeben 8 0 Aufgabenstellung des zu modellierenden Systems Zun chst wollen wir noch kurz die Aufgabenstellung des zu erstellenden Dialogsystems erl utern Ein Batchablauf sei im Folgenden auch als Job bezeichnet Jeder Job besteht aus einer Menge von Teilschritten JobSteps wobei ein Teilschritt von jeweils zwei Vorg nger Teilschritten SourceStepl und SourceStep2 abh ngig sein kann Dass nur zwei Vorg ngerschritte erlaubt sind ist historisch aus der Anwendung begr ndet und soll hier keine weitere Rolle in der Diskussion spielen Jeder Teilschritt repr sentiert im Wesentlichen einen Berechnungsschritt der zu einem Berechnungsergebnis f hrt das ggf in Folgeschritten zur Weiterverarbeitung ben tigt wird Zur Beschreibung der Art der Berechnung und zur Beschreibung des Ergebnisses des Rechenschrittes sind jedem JobStep neben den beiden Vorg ngerschritten eine Reihe weiterer Attribute zugeordnet Als Beispiel seien hier nur JobStepType FieldGroup ProductTree und Grid aufgezeigt Hinter dem JobStepType verbirgt sich letztlich das Programm das zur Berechnung des Rechenschrittes aufgerufen werden soll FieldGroup ist der Name einer Gruppe von Datenfeldern die zu berechnen sind ProductTree und Grid si
290. raphische Form nennen wir Ereignisstellendiagramm An die Stelle der expliziten Darstellung aller m glichen berg nge von einem Ereignis zum anderen mit einer expliziten Darstellung aller Ereignisse an eigenen Modellstellen in Form konkreter alternativer Ereignisfolgen tritt im Wesentlichen eine Darstellung der Stellen mit ihren Ereignissen und eine Darstellung zweier Relationen n mlich der so genannten ffne und der so genannten Schlie erelation zwischen Stellen Das ffnen und Schlie en einer Stelle kann dabei jeweils als Metaereignis betrachtet werden das durch ein konkretes Ereignis ausgel st wird und das jeweils eine Menge von Ereignissen einer Stelle er ffnet bzw sperrt Entsprechend der in den vorangegangenen Abschnitten gemachten berlegungen werden au erdem in das Modell Pr dikate Conditions und bertragungsfunktionen mit aufgenommen Nach einer formalen Darstellung des Ereignisstellenmodells wird im Folgenden der Zusammenhang mit Zustandsautomaten diskutiert Wir werden feststellen dass jeder deterministische endliche Automat in eine entsprechende Ereignisstellendarstellung abgebildet werden kann und umgekehrt unter gewissen Bedingungen jede primitive Ereignisstellendarstellung einem deterministischen endlichen Automaten entspricht 5 0 Formale Darstellung Ein primitives Ereignisstellenmodell ESM ist ein Tupel E T W S So RO RC C P t ERO ERC e start KRO KRC TRO mit E Menge von Ereignissen wo
291. ren nebenl ufigen Dialog gewechselt werden kann a NY NY N Vorname Stra e Abbildung 4 11 Dialog zur Adresserfassung in Modell mit expliziter Darstellung der berg nge und Modelldarstellung mit nebenl ufigen Dialogen Wir f hren im Modell eine Darstellung ein in der die vielen m glichen berg nge zwischen nebenl ufigen Dialogen nicht mehr angegeben werden Abbildung 4 11 zeigt am Beispiel eines Dialogs zur Adresserfassung ein Modell dieses Dialogs mit expliziter Darstellung aller m glichen berg nge alte Modelldarstellung und ein Modell in dem die Teildialoge zur Erfassung des Namens Vornamens usw als unabh ngige nebenl ufige Dialoge ohne notwendige logische berg nge aufgefasst werden neue Darstellung Kein Teildialog setzt in der Reihenfolge der Abarbeitung einen anderen Teildialog voraus Implizit wird per Definition dieser Darstellung angenommen dass jedoch von jedem Teildialog in einen beliebigen anderen jederzeit gewechselt werden kann Bei Start des Dialogs zur Adresserfassung stehen per Definition alle Teildialoge zur Verf gung d h es kann mit jedem der Teildialoge begonnen werden Theoretisch k nnen alle Teildialoge echt zeitgleich bedient werden wenn dies die tats chliche Implementierung erlaubt Dies setzt zumindest voraus dass die Teildialoge in der Implementierung durch unterschiedliche parallel bedienbare Ressourcen realisiert werden Bei einer blichen Implementierung der Dialogs
292. rgeordneten Stelle gef hrt werden und dann vom Rechtecksrand der bergeordneten Stelle nur mehr eine Triggerkante weitergef hrt wird Die weitergef hrte Triggerkante ist als B ndelung der auf den Rand gef hrten Triggerkanten der Teilstellen zu interpretieren Dies ist nur erlaubt wenn von der bergeordneten Stelle selbst kein Triggerereignis ausgeht also keine Verwechslung m glich ist Die Darstellung ist dann m glich wenn wir fordern dass eine bergeordnete Stelle immer ge ffnet ist wenn eine Teilstelle offen ist und deshalb ein ffnen einer bergeordneten Stelle von einer Teilstelle aus keinen Sinn macht 89 5 Ereignisstellenmodell Dialog1 Abbildung 5 2 Darstellung der ffne und Schlie e Relation durch ffne und Schlie e Pfeil Der mit T gekennzeichnete Pfeil Offnepfeil oder Triggerpfeil genannt triggert er ffnet bei Eintreten eines Ereignisses an der Stelle Dialogl Ereignisse an Stelle Dialog2 Der mit C und dem durchkreuzten Kreis gekennzeichnete Pfeil Schlie epfeil schlie t bei Eintreten eines Ereignisses in Dialogl die Stelle Dialog3 d h an dieser Stelle sind keine Ereignisse mehr m glich Die Annotation C k nnte immer auch weggelassen werden da der durchkreuzte Kreis den Pfeiltyp eindeutig macht T kann ebenso fehlen da bei einem einfachen Pfeil ohne Annotation angenommen wird dass es sich um einen Triggerpfeil handelt Die unterschiedlichen Farben sind nicht obligatorisch
293. rgonomie 85 Mensch Computer Interaktion B G Teubner 1985 F hnrich K P Hrsg Software Ergonomie Oldenbourg 1987 Fischer P Grafik Programmierung mit Java Swing Addison Wesley 2000 Foley J D Wallace V L The Art of Natural Graphic Man Machine Conversation Proceedings IEEE Vol 62 No 4 p 462 470 1974 Foley J D et al Computer Graphics Principles and Practice Addison Wesley 1990 FOWLER97 Fowler M Scott K UML Distilled Applying the Standard Object GANZ78 GREENS6 HARELS87 HARELS8 Modeling Language 2 printing Object Technology Series Addison Wesley 1997 Ganzinger H Optimierende Erzeugung von bersetzerteilen aus implementierunngsorientierten Sprachbeschreibungen Dissertation Technische Universit t M nchen 1978 Green M A Survey of Three Dialogue Models ACM Transcations on Graphics Vol 5 No 3 p 244 275 1986 Harel D Statecharts A Visual Formalism For Complex Systems Science of Computer Programming North Holland p 231 274 1987 Harel D On Visual Formalisms Communications of the ACM Volume 31 1988 HENTEN96 Van Hentenryck P Saraswat V et al Strategic Directions in Constraint Programming ACM Computing Surveys Vol 28 No 4 1996 165 13 Literaturverzeichnis HERRTS9 HOARES5 HUDSS9 ISO90 JACOBS6 JANSS96 JESSENS87 LINTH02 LONCZ97 LOSCH96a LOSCH96
294. rgt Dies f hrt dazu dass die Einarbeitung in die Funktionalit t des Systems und deren Implementierung erfahrungsgem viel Aufwand erfordert Fehlende Benutzern he Insbesondere wird durch die direkte Programmierung der Zugang f r den Benutzer und auch das Management in keiner Weise unterst tzt Der Benutzer kann erst nach Fertigstellung das Ergebnis des Entwicklungsprozesses berpr fen falls nicht vor der Entwicklungsphase eine gesonderte Phase der Abstimmung mithilfe zus tzlicher Dokumentation bzw aufw ndiger Spezifikation erfolgt Keine Unterst tzung f r logisches Design Die direkte Verwendung der Implementierungssprache des Basissystems bietet keine Unterst tzung f r ein systematisches logisches Design des Dialogs Dies birgt die Gefahr noch st rker als bei Rapid Development Systemen in sich dass das Design falls es berhaupt durchgef hrt wird von technischen Details beherrscht wird und dass dabei wichtige logische Gesichtspunkte bersehen werden Starke Abh ngigkeit von der aktuellen Technik Die komplette Implementierung mittels direkter Programmierung erh ht naturgem die Abh ngigkeit vom jeweilig verwendeten Basissystem Eine Umsetzung in ein anderes System wird dadurch sehr schwierig und f hrt in den meisten F llen zu einer h ufig unn tigen Neuentwicklung 1 3 Res mee Eine bersichtliche systematische und logische Darstellung der dynamischen Strukturen des Dialogs fehlt in derzeitigen Ra
295. rimitiven Ereignisstellendarstellungen 9 2 Abbildung einer eingeschr nkten primitiven Ereignisstellendarstellung auf einen endlichen Automaten Wenn wir von Werten und bertragungsfunktionen Conditions und ihren Zuordnungen zu den Stellen absehen und einige in der Praxis ohnehin naheliegende Annahmen bez glich Endlichkeit darin vorkommender Elementmengen machen k nnen wir diese eingeschr nkte primitive Ereignisstellendarstellung leicht in einen endlichen Automaten abbilden Kern der berlegung ist dabei dass jeweils ein Zustand dieses Automaten durch die Menge der Ereignisse aller gerade ge ffneten Stellen definiert ist Ein Zustands bergang von einem Zustand q zu einem Zustand q mit q ungleich q erfolgt genau dann wenn eine Stelle ge ffnet bzw geschlossen wird Dies bedeutet dass die Menge der akzeptierten Ereignisse erweitert bzw verringert wird und zwar jeweils um die Ereignismenge der ge ffneten bzw geschlossenen Stelle Die im Automaten erwarteten Token k nnen als die Werte gesehen werden die den Ereignissen zugeordnet sind Dabei sind diese Ereignisse auf verschiedene Stellen der Dialogschnittstelle verteilt Eine formale Darstellung des oben grob skizzierten Ereignisstellenautomaten ESA Q Endliche Menge von Zust nden E Endliche Menge von Token bergangsfunktion 6 IQxE gt Q go Startzustand F Menge der Endzust nde F c Q Der deterministische endliche Automat ESA Q E
296. rte und Wertebereiche Jedem Ereignis das an einer Stelle eintreten kann ist ein Wert zugeordnet Zur Beschreibung der m glichen Werte wird die Bezeichnung eines Wertebereichs an der Stelle angegeben Wir f hren also in der grafischen Darstellung Bezeichner f r Wertebereiche ein und fordern dass diese dann anderswo definiert sind Diese Bezeichner werden an der Stelle annotiert Um Verwechslungen mit anderen Annotationen zu vermeiden wird dem Bezeichner des Wertebereichs ein V mit nachfolgendem Doppelpunkt vorangestellt V V steht f r Value und wahlweise zur Verdeutlichung der Bezeichner in spitze Klammern gesetzt Alternativ kann dem V eine Aufz hlung einzelner Werte die dann zur Unterscheidung von Wertebereichsbezeichnern in Hochkommata gesetzt werden Es gibt Stellen an denen sich nur Ereignisse mit genau einem Wert ereignen Zum anderen wollen wir im Modell auch Werte an einer Stelle exemplarisch darstellen und Startwerte angeben k nnen Zu diesem Zweck erlauben wir zus tzlich zur Angabe eines Wertebereichs die Beschriftung mit einem Einzelwert Der Einzelwert wird in der Regel in die Mitte des 90 5 3 Grafische Darstellung Rechtecks gesetzt Ist ein Einzelwert angegeben wird dieser als Startwert und als exemplarischer Wert an der Stelle interpretiert Ist kein Wertebereich angegeben wird aus dem angegebenen Einzelwert der Wertebereich erschlossen abh ngig von Implementierung des Modellsystems In einer Primitivl
297. rten Darstellung im Modell vorgestellt Diese Abstraktions oder Reduktionsschritte die auch zur Einf hrung weiterer Sprachelemente im Modell f hren erm glichen uns eine kompaktere intensivere Darstellung des Dialogs erlauben aber immer noch eine weitgehend intuitive Form Diese Sprachelemente gehen letztendlich im Kapitel 5 und folgende in die Darstellungsm glichkei ten des Ereignisstellendiagrammes ein 4 0 WYSIWYG Ansatz Der WYSIWYG Ansatz im Modell erlaubt uns eine weitgehend realistische und damit auch anschauliche Darstellung des Dialogs Er kann deshalb als Ausgangspunkt f r eine benutzerzentrierte Modellierung dienen Ein Ziel ist dann aus der WYSIWYG Darstellung sukzessive eine Darstellung zu gewinnen die es auch erlaubt den n tigen Programmcode f r die Realisierung der Dialogkomponente zu erzeugen Der WYSIWYG Ansatz liefert zun chst eine auf ein bestimmtes Layout fixierte und in vielen F llen noch unvollst ndige Darstellung des Systems Von der konkreten Darstellung ausgehend kann in einigen Modellierungsschrit ten jedoch ein vom Layout abstrahierendes logisches und vollst ndiges Modell gewonnen werden Als wichtige Charakteristika einer konsequenten WYSIWYG Darstellung wollen wir zwei Merkmale festhalten a WYSIWYG Darstellung der Dynamik d h die m glichst zeitgetreue Darstellung des tat s chlichen realen Dialogablaufs eine m glichst zeitgetreue Folge der Dialogereignisse Da es in der Regel keinen eindeut
298. rtstelle Weitere Startstellen sind A Close unter B Close unter C und OpenC wobei A wiederum global ist Globale Startstellen werden sofort mit Start des Gesamtdialogs er ffnet Dies gilt in unserem Fall also f r die Dialogstellen A und B lokale Startstellen werden mit ihrer jeweils direkt bergeordneten Stelle ge ffnet 94 5 3 Grafische Darstellung Darstellung der Startstellen Startstellen sind Ereignisstellen die zum Startzeitpunkt der Applikation ge ffnet sind globale Startstellen oder Teilstellen bergeordneter Stellen der Stellenhierarchie die sofort mit dem ffnen der bergeordneten Stelle ge ffnet sind lokale Startstelle Wir erkennen Startstellen in der grafischen Darstellung implizit oder durch explizite Kennzeichnung Eine implizite Erkennung ist dadurch m glich dass keine Triggerkante also kein ffnepfeil in die Stelle f hrt Ist die Stelle keine Teilstelle einer anderen handelt es sich dann um eine globale Startstelle andernfalls um eine lokale Startstelle Falls eine Triggerkante in eine Stelle die als Startstelle fungieren soll f hrt m ssen wir diese explizit kennzeichnen Dies geschieht durch eine Triggerkante die aus dem Leeren kommt die also von keinem Rechteck ausgeht Im formalen Modell sind Startstellen in der Menge So zusammengefasst Annotation der Triggerereignisse Den Stellen berg ngen zum ffnen oder Schlie en einer Stelle grafisch ffne und Schlie e Pfeile sind jeweils
299. ruktur der Stellen f r eine Aufteilung der Information in verschiedene Sichten nutzt sondern generell davon ausgeht dass beliebige Teilmengen der Modellinformation in Teilsichten darstellbar sind Durch die Einf hrung dieser Modellsichten wird auch der Tatsache Rechnung getragen dass im Entwurfsprozess h ufig zun chst bottom up Teilsichten des Dialogablaufs entstehen die dann sukzessive zu einer Gesamtsicht verschmolzen werden Wir gehen von zwei verschiedenen Ausgangspunkten im Entwurf aus 1 Ausblenden aus Gesamtdiagramm Zum einen ben tigen wir Modellsichten um ein einmal komplett erstelltes Modell in bersichtliche Teile aufzuteilen Dies erreichen wir relativ einfach wenn wir von einem Ereignisstellendiagramm ausgehen k nnen das das gesamte Modell beschreibt Wir k nnen dann prinzipiell beliebige Teilsichten erzeugen indem wir jeweils eine bestimmte Menge von Darstellungselementen f r die spezifische Teilsicht als unsichtbar definieren und ausblenden In einer Darstellung des Modells am Bildschirm bedeutet dann die Auswahl einer bestimmten Sicht im primitiven Fall einfach das Ausblenden der als unsichtbar definierten Elemente Gegebenfalls k nnen wir f r jede Sicht noch das Layout wie etwa die Gr e und Position der dargestellten Stellen variieren etc F r den auf dem Rechner realisierten Modelleditor gibt es dabei keine Probleme was die logische Zuordnung der einzelnen dargestellten Elemente in den Teilsichten im Hinb
300. rung seiner Wahl wird schwierig Er ist in der Regel gezwungen s mtliche Information zum alten Objekt zu beseitigen und auch die dynamische Anbindung des dann neuen Objektes erneut zu formulieren Modellbasierte Systeme bieten grunds tzlich die M glichkeit zun chst auf einer implemen tierungsneutralen Ebene diese Objekte darzustellen Sie haben aber damit wiederum den Nachteil dass bei Situationen in denen eine Konkretisierung f r den Entwickler klar auf der Hand liegt erst eine meist umst ndliche Abbildung erfolgen muss Das Modell liegt zudem in einer zun chst sehr abstrakten Darstellung vor die keinen unmittelbaren Eindruck des konkret resultierenden Dialogs vermittelt Dies ist eine Darstellung die in der Entwurfsphase etwa zur Diskussion mit einem zuk nftigen Benutzer ungeeignet ist und nat rlich auch dem Designer oder Entwickler keinen Eindruck vom echten Dialog zur Laufzeit vermittelt 11 0 Einf hrung 0 1 Zielsetzung der Arbeit In der vorliegenden Arbeit wird eine Technik vorgestellt die es erlaubt eine benutzer zentrierte Modellierung einer grafischen Dialogoberfl che durchzuf hren in der konkrete Dialogelemente mit abstrakten aber intuitiven Sprachelementen kombiniert in einer Modell Darstellung zur Anwendung kommen k nnen Ein wesentlicher Bestandteil der Arbeit ist somit die Entwicklung einer integrierten Darstellung von Dialog die es erlaubt auf unter schiedlichen Ebenen der Abstraktion die Modellierung des
301. rweitert deren entsprechende Exemplarstellen Startstellen der Vorg ngerkonfiguration sind Vars Die Variationen bleiben beim bergang von einer Konfiguration zu einer anderen im Falle einer Kardinalit tsvariation bis auf eine eventuelle Erweiterung der jeweiligen Ereignismengen VarEvents erhalten 182 Anhang E Formale Darstellung der Exemplarvariation Es gilt var VarEvents VarS VarAspects VarType varFunc Vars lt var VarEvents VarS VarAspects VarType varFunc Vars mit VarEvents VarEvents U VarEventsneu und VarEventsneu sneu t evar e evar mit evar e VarEvents o evar orig sneu und sneu e SSubneu d h eine Ereignismenge VarEvents wird jeweils um die Ereignisse erweitert die sich an neuen Stellen ereignen k nnen f r die exemplarisch ein entsprechendes Ereignis in VarEvents an einer relevanten Exemplarstelle definiert ist os F ist die Erweiterung von S bez glich der neuen Stellen oS s o S s f r s S SSubneu S s S orig s f r s SSubneu q q Durch die Funktion variation wollen wir die Menge der ge ffneten Stellen die durch q bzw q beschrieben wird nicht ver ndern Dies geschieht erst durch Anwendung der Funktion core auf die durch variation ver nderte Konfiguration mConfig Ende Definition mConfig in variation falls e aus VarEvents f r ein var aus Vars Ende Definition Funktion variation 183
302. s Si Os s ist dabei die im entsprechenden Zustand g ltige Wertezuordnung zu Stellen in einem definierten Stellentupel s Wie schlagen sich nun die oben geschilderten m glichen Beziehungen anderer Modellstellen zu den Modellstellen des RadioButton in der Implementierung nieder Wenn insbesondere das Modell RadioButton durch die Klasse JRadioButton realisiert wird kann die Konkretisierung folgenderma en aussehen Hierarchische Einordnung als Teildialog Die hierarchische Einordnung als Teildialog eines anderen Dialogs erfolgt entweder ber die bliche im Widgetkonzept gegebene hierarchische Zuordnung Die Instanz der Klasse JRadioButton wird als Kind einem Container Widget zugeordnet Dies setzt voraus dass der bergeordnete Dialog als Container Widget realisiert werden kann wovon wir in der Regel ausgehen k nnen Andernfalls muss die hierarchische Beziehung der Dialogstellen des Modells gesondert implementiert werden ffnen oder Schlie en ber Ereignis an anderer Dialogstelle Wenn wir wiederum davon ausgehen k nnen dass die andere Dialogstelle als Instanz einer Widgetklasse instantiiert werden kann bedeutet das ffnen der Modellstelle RadioButton im Wesentlichen das Kreieren einer Instanz als Kind eines passenden Container Widgets falls nicht bereits erfolgt und das Sichtbar Machen des Widgets setVisible true Die beiden Operationen werden blicherweise in einer Ereignisroutine aufgerufen die dem entsprechenden Ere
303. s Objektes oder eines Ereignisses im r umlichen und oder zeitlichen Sinne wo und wann oder die Einordnung innerhalb einer diskreten Menge von Objekten oder Ereignissen im Sinne von an welcher Stelle oder Position befindet sich ein Objekt oder geschieht ein Ereignis Dieser Aspekt der Einordnung spielt auch in unserem Modell eine wesentliche Rolle da dort die statische und insbesondere die dynamische Struktur der Dialogereignisse beschrieben werden soll Wir wollen beschreiben wo und wann also an welcher Stelle ein Dialogereignis geschieht bzw geschehen kann siehe auch unten Relationen des Dialogmodells Wie Ereignisse k nnen Dialogstellen strukturiert sein und deren Struktur kann ber Relationen beschrieben werden Eine erste nahe liegende Strukturierung ist wiederum eine Hierarchie von Stellen und Teilstellen siehe unten Relationen Stelle als Abstraktion von Zeit und Ort Abbildung auf Zeitstellen oder Ortsstellen Die Abstraktion durch den Begriff Stelle im Modell von einer bestimmten und in der letzten Stufe der Realisierung physikalischen Ressource die im realen Ablauf des Dialogs zum Informationsaustausch verwendet wird macht uns w hrend des Modellierungsvorganges zun chst davon frei uns fr hzeitig auf eine bestimmte Ressource festzulegen Insbesondere haben wir z B die Freiheit zwischen einer Abbildung der Stelle auf die Dimension Zeit oder auf die Dimension Raum zu w hlen Fassen wir beispielsweise den Bildschirm als eine
304. s dass die Applikationslogik Komponente n tigenfalls rechtzeitig ein eigenes Ged chtnis bez glich der aktuellen Situation aufbaut Denn alleine aus der Stelle im Dialog heraus kann nicht mehr auf die aktuelle Gesamtsituation geschlossen werden siehe wiederum Entscheidungsmechanismen in Abschnitt 4 1 3 Im Gegensatz zur Darstellung in Abbildung 4 3 sind nun einige identische Stellen bzw berg nge zusammengefasst e13 wird auf e6 zur ckgef hrt e17 auf e15 e10 e14 e16 e18 auf e7 e8 aufell Damit sind auch berg nge ersetzt e13 e14 durch e6 e7 e17 e18 durch e6 e7 e12 e17 durch e12 e6 usw Wenn nun identische Folgen alternativer Pfade in der Darstellung im Grafen auf denselben Teilpfad zusammengef hrt werden kann in vielen F llen nicht davon ausgegangen werden dass die nachfolgenden Dialogschritte von der Vorgeschichte also dem Verlauf des Dialogs vor Durchlauf der zusammengefassten Pfade unabh ngig sind In diesem Fall ist in der bisher gew hlten Darstellung dann ein echter Informationsverlust bez glich der Dialogsteuerung gegeben Abbildung 4 5 Das Beispiel des Installationsdialogs wird um einen Dialog zur Auswahl eines Laufwerks erweitert Der Laufwerksdialog wird an zwei Stellen n mlich nach der Wahl der Vollinstallation und nach der Entscheidung f r eine Installation im Minimalumfang dargestellt 47 4 Bottom up Modellierung und Abstraktion In unserem Installationsbeispiel werden zur
305. s tzen Sie m ssen nicht mehr explizit ge ffnet werden wenn an anderen Stellen Ereignisse stattgefunden haben Abgesehen von den nicht mehr n tigen gestrichelten Linien sind also auch keine expliziten berg nge mehr in die Stellen zum erneuten Offnen notwendig In State Charts fehlt im Gegensatz zu ESD s die direkte Visualisierung von Wert bertra gungen Die Kanten im State Chart zeigen den durch Ereignisse gesteuerten Kontrollfluss von Zustand zu Zustand Der Datenflussaspekt der sich in den Kanten zur Wert bertragung im ESD widerspiegelt ist in State Charts nicht grafisch unterst tzt Dies manifestiert sich auch darin dass Ausgaben am Bildschirm in Aktionen verborgen sind und bei Ereignissen zun chst an Eingabeereignisse gedacht wird WELLNS89 In ESD s hingegen sind Ausgaben wie Eingaben Stellen zugewiesen an denen als Resultat der dort stattfindenden Ereignisse Werte vom Benutzer bzw System gelesen werden k nnen Dies ist Voraussetzung f r eine WYSIWYG hnliche Darstellung von grafischem Dialog Insgesamt gesehen sind Ereignisstellendiagramme mehr am Ereignismodell orientiert das g ngigen Systemen zur Realisierung grafischer Oberfl chen zu Grunde liegt Der Modellierer denkt bei ESD s in erster Linie an Stellen an denen Ereignisse passieren und nicht an Zust nde Dabei ist aber sehr wohl eine Darstellung von Zust nden m glich Im Gegensatz zu State Charts sind ESD s f r eine WYSIWYG Darstellung von Oberfl
306. s im Wechsel eine unterschiedliche Bedeutung signalisiert n mlich abwechselnd An oder Aus respektive true oder false Eine vom konkreten Widget abstrahierende Darstellung im ESM kann wie folgt gew hlt werden Wir nehmen vier Modellstellen also S So S S2 S3 Die Menge der Ereignisse unterteilen wir in vier Klassen die wir den vier unterschiedlichen Stellen zuordnen 1 e0 Eingabe An durch Benutzer So 103 6 Abstraktion vom konkreten Widget 2 el Ausgabe Aus durch System S 3 e2 Ausgabe An durch System S2 4 e3 Eingabe Aus durch Benutzer S3 Also E e0 An So Is el Aus S1 Os e2 An S2 Os e3 Aus S3 Ig j Es gelten folgende Bez ge zwischen den Stellen Nach dem Start des Dialogs werden So und S ge ffnet Ereignis in So schlie t So und S ffnet S2 und S3 Ereignis in S schlie t S und S2 ffnet So und S Also RO So S2 So S3 S3 So S3 S und RC So So So S1 S3 S3 S3 S2 5 Abbildung 6 2 Abstraktion eines Radio Buttons mit 4 ESD Stellen Das ffnen der Stellen zur Eingabe f r den Benutzer bewirkt das Warten des Systems auf die asynchron erfolgende Eingabe Das ffnen der Ausgabestellen bewirkt die unmittelbare synchrone Ausgabe der Information durch das System Das wechselseitige ffnen und Schlie en der Eingabestellen gew hrleistet dass nur
307. s statischen Bildes nat rlich nicht konkret das echtzeitliche dynamische Erscheinen des Ereignisses Ein Ereignis wird letztlich nur durch sein Ergebnis im Bild erkennbar So f hrt z B das Ereignis der Ausgabe eines Widgets dazu dass wir es am Bild wahrnehmen k nnen Die Eingabe des Benutzers stellen wir ebenfalls durch ein Ergebnis der Eingabe fest also z B anhand eines Wertes den wir in einem Eingabewidget feststellen k nnen 39 4 Bottom up Modellierung und Abstraktion Fortsetzung von Bild 3 Alternative zu Bild 4 Fortsetzung von Bild B Alternative zu Bild 6 Quickinstall i Bid16 System wirft Disk aus Ende Biidt1 Bilid12 Fortsetzung von Bild gz Alternative zu Bild 13 Quickinstali Bildt 3 Bildfd System wirft Disk aus Ende Bits System wirft Disk aus Ende Abbildung 4 2 WYSIWYG Beispiel Teil2 Fortsetzung von Abbildung 4 1 Da in unserem Beispiel in einem Bild nicht nur das Ergebnis des aktuell letzten Ereignisses zu sehen ist sondern auch zum Teil die Ergebnisse bereits vorangegangener Ereignisse ben tigen wir ein Merkmal zur Unterscheidung zwischen den alten Ereignissen und dem neuen Wir erkennen das neue Ereignis einmal durch einen Vergleich mit dem Vorg ngerbild oder dadurch dass wir es besonders grafisch hervorheben siehe z B ovale Umrahmung in den Abbildungen F r den menschlichen Betrachter der Bilderfolge wird der Ablauf des Dialogs in dieser
308. so we e belegt wird vereinfachter Fall Mit dem ffnen einer Stelle s also der Realisierung eines Stellen ber gangs s S werden unter Umst nden auch Schreibereignisse des Systems er ffnet Dies ist dann der Fall wenn der Stelle s eine Ereignismenge zugeordnet ist die auch Ereignisse der Typen Os oder Ms enth lt In diesem Falle wird ber die s s zugeordnete Propagationsfunktion die Entscheidung gef llt welches der m glichen Ereignisse als n chstes an der Stelle s stattfinden soll Hier wird der Sicht des Modells Rechnung getragen dass auch das Schreiben des Systems an Ausgabestellen und Hilfsstellen ber Ereignisse mit entsprechenden Zustand berg ngen abgehandelt werden wobei die Abarbeitung dieser Ereignisse unmittelbar nach dem ffnen der Stelle also synchron erfolgt Wenn nun mehrere Stellen berg nge bei einem bergang erfolgen muss ber eine Ordnungsfunktion auf den Stellenpaaren in RO entschieden werden in welcher Reihenfolge die Abarbeitung der Schreibereignisse erfolgen soll Diese Ordnung ergibt dann die Reihenfolge im Tupel enext der propagierten Ereignisse enext o i m 0 lt i lt m mit im N 170 und Anhang B bergangsfunktion f r das hierarchische ESM falls m 1 mit e Paerosi os Si ti mit si S ti Os Ms falls p srosi definiert also nro sROs P sROsi null ess null sonst und ordro s s
309. sprochen werden Ebenso wird definiert welche Objekte an der Oberfl che pr sentiert werden sollen Es wird festgelegt welche Bez ge zwischen den auszutauschenden Einheiten im Sinne der Aufgabenstellung bestehen etwa eine notwendige Reihenfolge beim Aufruf von Funktionen etc Die semantische Ebene kennt alle genannten Funktionen und Objekte in ihrer Bedeutung nicht aber in der Form der Realisierung In der syntaktischen Ebene erfolgt letztlich die Festlegung der tats chlich m glichen sprachlichen Einheiten Token und der konkret m glichen Folge der einzelnen Dialogschritte Hier wird z B bestimmt in welchem Zustand welche Eingaben erlaubt sind Erst in der lexikalischen Ebene werden die sprachlichen Einheiten der Eingabe Ausgabesprache auf konkrete Hardware Ressourcen z B Eingabeger te bzw Ereignisse abgebildet 2 0 0 1 Abgrenzung zum Layout Logischer Dialog ist gegen das Layout des Dialogs abzugrenzen Unter Layout verstehen wir u a die verschiedenen Dialogarten in denen derselbe logische Dialog realisiert werden kann Ebenso kann ein und der derselbe logische Dialog meist in unterschiedlichen Dialogstilen ausgearbeitet sein Dialogarten Als klassische Dialogarten kennen wir z B den Frage Antwort Dialog Kommandodialog Men dialog Formulardialog sowie den grafischen Dialog ZEIDL92 Wir k nnen diese ohne Anspruch auf Vollst ndigkeit durch die Kategorien Kiosksysteme und multimedialen Dialog erweitern Im Frage Ant
310. sst sich dies leicht feststellen Z B k nnen wir rekursiv in jeder Teilsicht von oben beginnend nach unten alle Pfade f r Nicht Jokerstellen bestehend aus den Stellenbezeichnern aufbauen Die so erhaltene Menge von Bezeichner Pfaden kann elementweise verglichen werden Alle jeweils bereinstimmen den Pfade definieren eine Stelle des Gesamtmodells Wir gehen davon aus dass die Menge der so erhaltenen Stellen Fixstellenmenge nicht leer ist sonst w rden alle Teilsichten nur mit Jokerstellen in der obersten Hierarchieebene beginnen F r jedes Element der Fixstellenmenge k nnen wir nun nach Jokerstellen suchen die zur Erg nzung jeweils einer Fixstelle herangezogen werden k nnen Dies geschieht indem wir die Pfade der Fixstellen mit den Pfaden der Jokerstellen vergleichen Der Pfad einer Jokerstelle entsteht dadurch dass alle Stellenbezeichner der bergeordneten Rechtecke von oben beginnend aneinander gereiht werden und vor dem Stellenbezeichner einer Jokerstelle im Pfad statt eines Stellenbezeichners drei Punkte eingetragen werden Der Pfad einer Fixstelle stimmt dann mit dem Pfad einer Jokerstelle berein wenn alle Teilsequenzen des Jokerstellenpfades die hintereinander aus echten Stellenbezeichnern bestehen in gleicher Weise direkt hintereinander als Teilsequenz im Pfad der Fixstelle vorkommen und diese Teilsequenzen ebenfalls in gleicher Reihenfolge in den Pfaden auftreten Die letzte Teilsequenz besteht dann aus dem gemeinsame
311. st der bergang rDOIT wenn das Synthetic Token DOIT von einem anderen Interaktionsobjekt im Beispiel dem FillinButton but siehe n chste Abbildung erkannt wurde und mittels sDOIT versendet wurde Danach folgt die Pr fung auf Eingabe eines Passworts Conditions eingeleitet mit Cond und in Abh ngigkeit ggf die Ausgabe der Fehlermeldung oder der Aufruf der Aktion eingeleitet mit Act zum Durchf hren der Passwort nderung Abbildung 9 3 zeigt die Spezifikation f r die Component Objects FillinButton und FillinField Abbildung 9 4 zeigt zum Vergleich eine Spezifikation mit einem Ereignisstellendiagramm 129 9 Vergleich mit bekannten Ans tzen Hinter einer Stelle steckt 0 B d A zum Zeitpunkt der Implementierung ein Objekt oder ein Objektattribut Entsprechend wird erwartet dass das ffnen und Schlie en sowie die Propagationsfunktion entsprechend implementiert wird Wird der Stelle z B eine Widgetinstanz als Implementierungsobjekt zugeordnet bedeutet das ffnen im Default Fall auch tats chlich das ffnen des Widgets am Bildschirm falls nicht bereits in Zusammenhang mit einer fr heren Stelle geschehen Der von der Propagationsfunktion gelieferte Wert wird standardm ig dem Attribut des Widgets zugeordnet das als Default Wertattribut festgelegt ist z B das Value Attribut im Widget JText INTERACTION_O BJECT FillinButton is FROM GenericButton IVARS position legend Change Password TOKENS sDOIT SendToiparent
312. swahl FileSelectionBox Jedem editierbaren Textfeld ist standardm ig bereits ein Editor einprogrammiert der die Ver nderung des Textfeldes w hrend des Editionsvorgangs steuert Ebenso muss das Aufklappen der Auswahlliste einer Kombobox die Selektion einzelner Listeneintr ge das Nachtragen des selektierten Wertes im editierbaren Feld der Box nicht neu modelliert oder programmiert werden hnliches gilt f r den Dialog der in der FileSelectionBox vorgegeben ist und letztlich zur Darstellung eines Dateinamens nach durchgef hrter Auswahl ber einige Mausklicks f hrt 1 0 1 1 Attributgesteuerte Dynamik Der objektbasierte Ansatz der meisten Systeme erm glicht es Dialogobjekte als Instanzen be stimmter Objektklassen zu definieren ber die in einer Klasse zusammengefassten Attribute k nnen nun statische aber auch dynamische Aspekte einer Objektinstanz beschrieben wer den Unter zun chst eher statischen Aspekten verstehen wir beispielsweise die H he und Breite eines Widgets seine Farbe oder die Zuordnung zu seiner bergeordneten Komponente Dynamische Aspekte sind z B Angaben dar ber wann ein Widget geschlossen werden soll z B kann eine Dialog Box beim Dr cken seines Ok Buttons per Attributangabe wahlweise entweder automatisch geschlossen werden oder aber ge ffnet bleiben Autoclose Attribut in Motif Genauso kann jedoch auch die Gr e eines Widgets als dynamisch ver nderbar definiert werden Dies gilt z B dann wenn di
313. t nden Sehen wir den Modellgrafen allerdings als Zustands bergangsdiagramm befinden wir uns nach jedem bergang in die Anfangsstelle des Zyklus im selben Zustand Wir abstrahieren also hier von der Anzahl des Durchlaufens des Zyklus Wenn wir also eine Unterscheidung des m glichen Folgedialogs in Abh ngigkeit von der Anzahl der Zyklenwiederholung treffen wollen ben tigen wir wiederum ein Ged chtnis zus tzlich zum vorliegenden Modellgrafen mit entsprechenden Sprachmitteln zur Abfrage Semantisch kann die Zusammenfassung von Teildialogen durch die Einf hrung von Schleifen unterschiedlich interpretiert werden So kann das nochmalige Durchlaufen einer Dialogstelle bedeuten dass vorher an der Dialogstelle gemachte Aussagen im Sinne einer Korrektur oder Erg nzung berschrieben oder erweitert werden sollen Es handelt sich dann um eine Art Wiederaufnahme und Fortsetzung des alten Dialogs Es kann aber auch z B bedeuten dass 54 4 1 Reduktion von Stellen und Transitionen ein v llig neuer Dialog begonnen wird der nur in seiner Bedeutung in Form und Inhalt hnlich zu verstehen ist aber eine neue Aussage darstellt die die vorher gemachten Aussagen an der Dialogstelle nicht ber hrt Entsprechend kann auch in der sp teren Implementierung dieselbe Dialogstelle z B dasselbe Formular bei Neudurchlauf der Stelle mit der gleichen Inkarnation eines Widgets realisiert werden oder es kann eine neue Inkarnation weiteres Formular kreiert werden
314. t Dialog die Felder einzeln hintereinander ausgegeben und sukzessive in bestimmter Reihenfolge abgefragt Dieses Beispiel zeigt dass das was im Formulardialog intuitiv als statische Komponente gesehen wird n mlich das Formular mit seinen fix vorgegebenen Feldern in einer anderen Dialogart in eine dynamische Komponente umgesetzt wird n mlich im Beispiel in eine Dialogfolge mit Ausgabe der einzelnen Felder 2 0 1 Integration logischer und layoutbehafteter Darstellung Ein weiteres Kernziel ist die Verbindung des Ansatzes des modellbasierten Dialogentwurfs mit wesentlichen Vorteilen des Rapid Development Ansatzes n mlich der konkreten WYSIWYG Darstellung und der schnellen direkten Umsetzung in ein ablauff higes System Die Erfahrung zeigt dass in der Phase des Entwurfs eines Dialogsystems Vorstellungen ber die Gestaltung der Bedienoberfl che auf unterschiedlich konkreter bzw abstrakter Ebene vorliegen In der Modellsprache bzw im die Sprache unterst tzenden Werkzeug sollen deshalb diese konkreten und abstrakten Vorstellungen erfasst und weiter entwickelt werden 28 2 0 Kernziele k nnen Im Idealfall k nnen dann je nach Zielsetzung sukzessive abstrakte Elemente konkretisiert und umgekehrt konkrete Elemente abstrahiert werden Liegt das Ziel darin zu einem ablauff higen System zu gelangen werden schrittweise abstrakte Elemente durch ihre Konkretisierungen ersetzt bzw den abstrakten Elementen werden konkrete Implementierungen
315. t die unmittelbare Folge der Ereignisse bez glich aller Ereignisse im Gesamtdialog ausdr ckt D h unmittelbares Nachfolgeereignis ist nicht unbedingt ein Ereignis an der durch den Pfeil ausgedr ckten Nachfolgerstelle Die durchgezogenen Pfeile zeigen jedoch genau die Folge im Teildialog an die sich trivialerweise ergibt wenn man alle Ereignisse des jeweiligen anderen Teildialogs aus der Gesamtfolge streicht Dies gilt unter der Annahme dass der Pfeil so als gerichtete Kante eines Grafen interpretiert wird wie wir dies auch in der bisher vorangegangenen Entwicklung unserer Modelldarstel lung getan haben durch die Verfolgung der Kanten vom Startknoten aus ermitteln wir eine Folge von Ereignissen die einen m glichen zeitlichen Ablauf des Dialogs widerspiegelt Insbesondere kann eine Stelle nur dann wiederholt erreicht werden wenn ein Zyklus im Grafen existiert in dem die Stelle als Knoten vertreten ist Ist die Stelle in keinem Zyklus vertreten kann sie h chstens einmal erreicht werden Die Stelle ist dann auch nur h chstens einmal ge ffnet Handelt es sich beispielsweise um eine primitive Stelle ereignet sich an der Stelle dann nur h chstens einmal ein Ereignis die Stelle ist danach nie mehr ge ffnet bzw f r den gesamten restlichen Dialogablauf geschlossen 74 4 2 Logische Abstraktion Diese Art der Darstellung f hrt dazu dass wir von jeder Nachfolgerstelle oder von der Stelle selbst aus eine gerichtete Kante zur Stelle
316. tehen als n chste m gliche Aktionen die Aktionen in x y bzw out x z ber den gemeinsamen Port x an Die rechte Komponente sendet dabei ber Port x das Objekt z mittels out x z das von der linken Komponente empfangen wird in x y Namensersetzung bei Reaktion Nun erfolgt eine Ersetzung von y durch z in dem nach in x y folgenden Ausdruck P was in der obigen Regel durch das Voranstellen von z y auf der rechten Seite der Ersetzungsregel ausgedr ckt wird Taucht nun innerhalb von P vor der Namensersetzung y als Port auf etwa in der Form out y w ist nach der Ersetzung an der Stelle von y nun z und damit z als Port zugeordnet Als Ergebnis der Reaktion bzw Interaktion beider Prozesskomponenten oder Prozesse bleiben nun die beiden Prozesskomponenten oder Prozesse P und Q Die Alternativen Prozessabl ufe M bzw N fallen weg 140 9 4 Pi Kalk l Grafische Darstellung Die Entwicklung des Kalk ls geschieht nicht im Hinblick auf eine intuitive grafische Darstellung Das Ziel ist vielmehr eine Theorie zu entwickeln um Aussagen etwa ber die quivalenz von Prozessstrukturen im Sinne eines quivalenten Verhaltens der Prozesse machen zu k nnen Einf hrung des Begriffs der Bisimulation etc Ein Vorschlag zur grafischen Visualisierung stammt jedoch z B von Joachim Parrow PARRO95 Before interaction jaa I i After interaction I L Abbildung 9 7 Grafische Darstellung des Pi Kalk ls mit Interaction Di
317. tellen bergang si sj zugeordnet Also handelt es sich um ein Ereignis an der Stelle sj Au erdem kann es sich nur um ein Schreibereignis des Systems handeln also entweder vom Typ Os oder Ms Wegen oben gemachter Einschr nkung ist an einer Stelle nur einer der beiden Typen erlaubt und damit eine eindeutige Zuordnung des Typs m glich co sj liefert uns alle Ereignisse an der Stelle und damit auch das Ereignis vom Typ Os oder Ms mit dem von der Propagationsfunktion gelieferten Wert Gemeinsam mit den oben eingef hrten Conditions wird damit die komplette Steuerung der Dialogereignisse soweit sie in der Hand des Systems liegt erm glicht Hier nehmen wir allerdings eine etwas idealisierte Sicht im Modell ein Wir gehen davon aus dass mit den Hilfsstellen letztlich der komplette Speicher repr sentiert wird der f r die Realisierung einer Anwendung ben tigt wird und dass wir durch Anwendung entsprechender Propagations funktionen diesen Speicher abfragen und mit Werten belegen In der Praxis bedeutet dies dass eine oder mehrere sehr gro e Hilfsstellen ben tigt werden die bedeutende Teile des Speichers der Applikation abdecken Wenn wir beispielsweise eine Datenbankfrage absetzen m ssen wir die Datenbank mit all ihrer Nutz und Verwaltungsinformation als Hilfsstelle betrachten auf die eine Propagationsfunktion zugreift um das Suchergebnis zu ermitteln Umgekehrt gilt beim 58 4 1 Reduktion von Stellen und Transitionen Abspei
318. tenbank zu ladenden Jobbeschreibung Die Selektion des Jobs ist hier als zusammengesetzte Ereignisstelle modelliert Sie besteht aus einer Ereignisstelle zur Darstellung des Jobidentifikators und einer Ereignisstelle ber die der Dialog zum Laden des Jobs der Jobbeschreibung angesto en wird 121 8 Modellbeispiel LoadingJob Das Ansto en wird durch den ffnepfeil von der Ereignisstelle Load zur Ereignisstelle LoadingJob angedeutet Ein weiterer Triggerpfeil von der Ereignisstelle Load triggert die Wert bernahme von der Ereignisstelle JoebName der JobSelection Stelle an die Teilstelle JoebName in der Ereignisstelle LoadingJob Wert bernahme bedeutet in Diktion des Ereignisstellenmodells Bei Eintritt eines Ereignisses an der Stelle JobSelection Load wird ein Ausgabeereignis an der Stelle LoadingJob JobName propagiert dessen Wert durch eine Propagationsfunktion bestimmt wird In diesem Falle handelt es sich um die Identit tsfunktion die ihren Wert aus dem Wert der Stelle JobSelection JobName herleitet Ein Wert bernahmepfeil wirkt somit nur dann wenn durch einen zugeordneten Triggerpfeil ein Ereignis ausgel st wird ffnen JobStepGraph Die Ereignisstelle Ready markiert den Abschluss des LoadingJob Ereignisses und er ffnet ber einen ffnepfeil die Ereignisstelle zur Darstellung und Edition der JobSteps eines selektierten Jobs n mlich die zusammengesetzte Ereignisstelle JobStepGraph Die Stellen JobStepl JobStep2 und Step
319. tes Ereignis an Stelle A eingetreten ist 93 5 Ereignisstellenmodell Propagationsfunktion als Pseudostelle mit Eingangs und Ausgangssubstellen Um grafisch zeigen zu k nnen dass eine Propagationsfunktion von mehreren Stellen aus mit Parameterwerten versorgt wird und au erdem mehrere Ausgabewerte besitzt die an verschiedene Stellen bertragen werden f hren wir die Darstellung einer Propagationsfunk tion in einem Rechteck ein das eingebettet Rechtecke Teilrechtecke f r die Eingangsparameter und die Ausgangsparameter besitzt Im obigen formalen Modell fehlt der Fall dass mehrere Ausgabewerte durch eine Propaga tionsfunktion geliefert werden Es handelt sich formal gesehen jedoch hier einfach um das gleichzeitige Ausf hren mehrerer Propagationsfunktionen in einer zusammenfassenden Funktion Im formalen Modell wird davon ausgegangen dass alle relevanten Propagationsfunktionen die von einem Ereignis ausgel st werden quasi gleichzeitig ausgef hrt werden und sich nicht gegenseitig beeinflussen In die Rechtecke f r die Eingangsparameter f hren Wert bertragungskanten von den jeweiligen Stellen aus denen die Parameterwerte bertragen werden Von den die Ausgangsparameter repr sentierenden Rechtecken aus f hren wiederum Wert bertragungs kanten zu den jeweiligen Zielstellen an denen ein Ereignis propagiert wird Alle diese Stellen werden dem formalen Modell gem auch ge ffnet bevor das Ereignis prop
320. tigsten Hauptst dten der Erde und den dazugeh rigen aktuellen Temperaturen Rein problemlogisch gesehen im Sinne des logisch physikalischen Sachverhaltes der Zuordnung zwischen Ort und Temperatur haben wir keine Abh ngigkeit zwischen dem St dtenamen und der Temperatur die es erfordern w rde erst den St dtenamen und dann die Temperatur darzustellen Es ist genauso denkbar dass erst eine bestimmte Temperatur und danach die zugeh rigen St dte sichtbar werden oder eben dass beides gleichzeitig in der Tabelle angeboten wird Die notwendige zeitliche Abh ngigkeit ergibt sich allerdings doch in Abh ngigkeit von den Bed rfnissen eines der beiden Dialogpartner in einer aktuellen Situation Die so verstandene aufgabenlogische Abh ngigkeit ergibt sich z B daraus dass f r den Benutzer der Ort als 64 4 2 Logische Abstraktion Reiseziel festliegt er jedoch nicht die aktuelle Temperatur kennt Umgekehrt k nnte der Benutzer sein Reiseziel erst aufgrund einer gew nschten Temperatur w hlen wollen Die Reihenfolge der Darstellung von Information liegt in diesem Fall also darin begr ndet dass ein Dialogpartner nur ber einen Teil der von ihm ben tigten Information zu einem bestimmten Zeitpunkt verf gt und sich ber diese Teilinformation vom anderen Dialogpartner die erg nzende Information verschaffen m chte Dies ist wiederum darauf zur ckzuf hren dass ein Dialogpartner nur beschr nkte Kapazit t zur gleichzeitigen Aufnahme und S
321. tion aus einer gr nen Triggerkante und einer gelben Kante zur Wert bertragung dar und symbolisieren das Ausl sen einer Wert bertragung bei der die Ausgangsstelle des zu bertragenden Wertes mit der Stelle des ausl senden Ereignisses bereinstimmt 169 Anhang B Anhang B bergangsfunktion f r das hierarchische Ereignisstellenmodell bergangsfunktion 6 QE WSHist E gt QE WSHist E QE Menge der Ereigniszust nde wobei ein Ereigniszustand jeweils implizit definiert ist durch die Menge der m glichen Ereignisse WSHist Menge der Wertezuordnungen die in einem Zustand an den Stellen S gelesen werden k nnen WSHist lt Funktion S gt W F r q q QE os os e WSHist e E o e s und enext e E gilt q s e gt q s enext lt gt e e q und und und e muss in der Menge der m glichen Ereignisse von q liegen eq e09 Y Uo C U o6 ses ses Die q zugeordnete Menge m glicher Ereignisse ergibt sich aus der Menge im Ausgangszustand q erweitert um die Menge der neu zu ffnenden Stellen S Definition siehe unten und vermindert um die Menge der zu schlie enden Stellen S Definition siehe unten VsteS s st wele falls st s s st s st sonst Die neue Wertezuordnung as nach bergang ergibt sich an allen Stellen aus der alten mit Ausnahme an der Stelle s wo der Wert mit dem Wert des Ereignisses e al
322. tion new a P mit dem Restriktionsoperator new wird der Name a innerhalb P als lokal g ltiger Name gekennzeichnet Der Scope von a ist auf P eingeschr nkt Replikation P Das Zeichen kennzeichnet dass der nachfolgende Ausdruck beliebig oft auftreten kann Da mittels Replikation auch Rekursivit t ausgedr ckt werden kann wird auf letztere als Sprachmittel zugunsten einer minimierten Darstellung im Pi Kalk l verzichtet Transitionssystem Labelled Transition System LTS Die oben skizzierten Prozessausdr cke stellen jeweils Zust nde eines Systems konkurrieren der Prozesse dar Ein Prozessausduck definiert letztlich welche Zustands berg nge im System m glich sind Dabei wird zwischen den berg ngen innerhalb eines Prozesses und den berg ngen unterschieden die durch Interaktion der Prozesse miteinander erfolgen F r die m glichen berg nge von einem Prozessausdruck zum anderen werden f nf sogenannte Reaktionsregeln TAU REACT PAR RES und STRUCT definiert die die Basis f r die Transitionen eines Transitionssystems bilden Als wohl charakteristische Regel f r das Kalk l sei hier die Regel REACT n her erl utert REACT inx y P M outx z Q N z y P Q Die Regel beschreibt den bergang des Systems der dann erfolgt wenn zwei nebenl ufige Prozesskomponenten ber einen gemeinsamen Port interagieren In obiger Formel sind dies die Komponenten in x y P M und out x z Q N In beiden Komponenten s
323. tm ige Abbildung der abstrakten Ereignisstellen auf konkrete Widgets f r die F lle gezeigt in denen keinerlei Annotation an der Stelle vom Designer gemacht wurde bis hin zu den F llen in denen bereits Angaben zu den Stellenwerten und zu Ereignistypen durchgef hrt wurden Der Codegenera tor unterscheidet f r die Wahl des geeigneten Widgets ob von der Stelle aus ein Ereignis an einer anderen Stelle getriggert wird ob also ein Pfeil zum ffnen Schlie en oder zum Ausl sen einer Wert bertragung von der Stelle ausgeht Abb 10 1 oder keine Triggerfunktion der Stelle vorliegt Abb 10 2 Stelle ohne Trigger Pfeil Annotation Primitive Stelle Zusammengesetzte von Stelle Topstelle Typ Ohne Typangabe I O I O L O I O Wert Ohne Wert LabeledTextfield LabeledText JLabel LabeledText JPanel FramedJPanel annotation LabelText Name LabelText Name LabelText Name LabelText Name Title Name Wert LabeledTextfield LabeledTextfield LabeledTextfield LabeledTextfield JPane FramedJPanel annotiert LabelText Name LabelText Name LabelText Name LabelText Name Title Wert Text Wert Text Wert Text Wert Text Wert Werteliste Liste Liste Liste Liste JPane FramedJPanel mitCheckButtons mitCheckButtons mitCheckButtons mitCheckButtons Title Name Werteliste Liste Liste Liste Liste JPane FramedJPanel Defaultwert mitCheckButtons mitCheckButtons mitCheckButtons mitCheckButtons Title
324. tzer ist dadurch eher gezwungen im Entwurf bereits bestimmte spezifische Elemente einzusetzen Die Wahl der Begriffe der Hitspezifikation ist eher technisch abstrakt und weniger an die Vorstellungen und Bed rfnisse auch laienhafter Benutzer angepasst F r die fr he Entwurfsphase scheint daher die ESM Sprache eher geeignet Ebenso ist die gew hlte Struktur im ESM Modell eher geeignet eine grafische WYSIWYG Darstellung der Dialog Oberfl che zu erzielen da im Zentrum eines ESM die Eingabe und Ausgabestellen stehen an denen Ereignisse passieren sowie die dynamischen Relationen zwischen den Stellen Hit Bausteine erm glichen ebenfalls eine grafische Darstellung Allerdings ist hier mehr eine hierarchische abstrakt logische Darstellung der Implementierungseinheiten eines Dialogsystems gemeint In diesem Sinne wird in der Hitspezifikation auch streng zwischen logischer Spezifikation und der Umsetzung in ein konkretes Layout unterschieden Die Anbindung des Layouts geschieht dabei ber Gleichungsregeln die den logischen Hitbausteinen zus tzlich zugeordnet werden k nnen Diese Gleichungsregeln beinhalten eine Beschreibung der Layoutstruktur der f r den logischen Hitbaustein zu verwendenden Dialogobjekte Dies sind Objekte eines virtuellen Baukastensystems das dann auf ein jeweils konkretes Baukastensystem Motif Java umgesetzt wird In den grafischen Darstellungen des ESM den Ereignisstellen Diagrammen ESD s ist die konkrete Darste
325. uelle Wertezuordnung os eingeschr nkt auf die f r c definierte Stellenmenge Se Ende Definition S RCH mit aktuellen berg ngen s s zum Schlie en s Ende Definition bergangsfunktion 173 Anhang C Anhang C Induktion von Ereignishierarchien ber Stellenhierarchie Es macht in vielen F llen Sinn eine Folge bzw Teilfolge von Ereignissen wieder als ein Ereignis zu betrachten In diesem Verst ndnis k nnen ber die im Grundmodell Kap 3 angegebenen Ereignisfolgen Hierarchien von Ereignissen konstruiert werden Eine m gliche Unterteilung in Teilfolgen erreichen wir wenn wir alle Ereignisse in einer Ereignisfolge die an derselben Stelle stattfinden als Teilfolge betrachten Alle Ereignisse dieser Teilfolge k nnen wir als ein zusammengesetztes Ereignis interpretieren Existiert nun eine Hierarchie ber den Stellen k nnen so gewonnene zusammengesetzte Ereignisse an Teilstellen wiederum zu einem Ereignis einer bergeordneten Stelle zusammengefasst werden usw Eine Hierarchie der Ereignisse H bez glich einer Ereignisfolge f kann ber eine Hierarchie von Stellen X c S S wie folgt konstruiert werden e1 2 Hr o e1 o e2 EXA e o e1 f oder o e 0 amp A e1 amp o e1 f wobei amp die Funktion Konstruktionsfunktion darstellen soll die jeder Stelle s bez glich einer Folge f genau ein zusammengesetztes Ereignis das Gesamtereignis an der Stelle s bez gli
326. un dadurch ausgedr ckt dass ein Fenster als Eingangsstelle und gleichzeitig als Ausgangsstelle einer Transition fungiert D h der Zustand ge ffnet bleibt beim ffnen des Fensters eines anderen nebenl ufigen Dialogs erhalten indem eine zus tzliche gerichtete Kante von besagter Transition wieder zur Eingangsstelle zur ckf hrt Optionale Fl sse Um nun ausdr cken zu k nnen dass von einem ersten Fenster aus ein bergang zu einem zweiten Fenster mehrfach erfolgen kann obwohl das zweite Fenster unter Umst nden schon ge ffnet ist wird eine optionale Flussrelation eingef hrt gestrichelte Kante zur Ausgangsstelle Umgekehrt bedeutet eine gestrichelte Kante von einer Eingangsstelle zur Transition dass f r das Feuern einer Transition nicht unbedingt eine Marke an der Eingangsstelle existieren muss falls an einer anderen Stelle eine Marke existiert Damit wird der Erfordernis Rechnung getragen dass eine Transition schalten feuern kann auch wenn nicht alle Fenster der Eingangsstellen ge ffnet sind Modale Stellen Werden als modal gekennzeichnete Stellen fette Umrandung ge ffnet k nnen Transitionen die von anderen Stellen ausgehen nicht mehr schalten Komplexe Stellen Komplexe Stellen gekennzeichnet mit Doppelrahmen repr sentieren Dialoge die in Subnetzen n her spezifiziert werden Damit wird eine Hierarchisierung der Dialognetze erreicht Komplexe Stellen k nnen mehrfach in Netzen und Subnetzen auftreten definier
327. und 3 s s HSStart d h s ist Startknoten von s HSStart eine Stelle u ist Startstelle von t sei dabei wie folgt definiert t u e HSStart gt 3k Tupel so Si Sk Mit So Si Sk S i k N und s t und sk u und si s1 HS f r alle i 0 k 1 d h s ist Teilstelle von si und s e So f r alle i 1 k d h s ist aus der Menge der Startstellen So Definition von RCH c S S J3 s s RCP amp J s s e RC oder 3 s s e RC und 3 s s e HS d h s ist Teilstelle von s F r die bergangsfunktion ist im hierarchischen Fall des Ereignisstellenmodells der Anfangszustand go QE anders als f r ein primitives ESM zu definieren Am Anfang sind n mlich nicht alle Ereignisse der Startstellen So m glich sondern nur der Startstellen die keine bergeordneten Stellen haben oder deren bergeordnete Stellen alle auch Startstellen sind Daf r definieren wir eine neue Menge globaler Startstellen Sogiobal go Soglobal gt go So und 80 STop oder F Stop Stopund STopE So und Stop Zo HSStart Stop sei die Menge aller Stellen ohne bergeordnete Stelle also se Stp gt sd eHS gt s 5 82 5 0 Formale Darstellung Der Anfangszustand qo QE ist dann wie folgt definiert gm lt q U og goE Soglobal Im Anhang Anhang B ist die vollst ndige Definition der
328. und dienen lediglich als zus tzliche visuelle Unter st tzung Der Pfeil von Dialog zu Dialog4 ist eine Zusammenfassung eines ffnepfeils und Schlie epfeils Er besagt dass bei Ereignissen in Dialog dieser selbst geschlossen und Dialog4 ge ffnet wird Ebenso ist die Darstellung mit Dialog5 und Dialog9 der Vorschlag f r eine Kurzfassung Der Pfeil von Dialog5 zu Dialog9 ist als Fortf hrung der Pfeile aus den Dialogen D6 D7 und D8 zu interpretieren Diese Darstellung kann nur verwendet werden wenn Dialog5 selbst keine Ereignisse direkt zugeordnet hat und in Dialog5 selbst dann auch keine Triggerereignisse erfolgen Annotation der Ereignistypen Den Ereignissen die sich an einer Stelle ereignen k nnen sind jeweils Ereignistypen zugeordnet Im formalen Modell handelt es sich um die Typen Ig Benutzereingabe Os Ausgabe durch System und Ms Schreiben durch System an interner unsichtbarer Hilfsstelle Bei Stellen die Ereignisse unterschiedlichen Typs zulassen k nnen entsprechende Typenkombinationen auftreten Grafisch wird dies durch eine entsprechende Annotation des die Stelle repr sentierenden Rechtecks durch die Buchstaben I O M bzw Kombinationen ausgedr ckt Es wird damit gekennzeichnet dass die Ereignisse die sich an der Stelle ereignen einen der in der Buchstabenkombination enthaltenen Typen besitzen Falls Verwechslungen m glich sind stellen wir den Ereignistypen ein T voran Eintragung bzw Annotation der We
329. ung des Zustands an der Oberfl che ausdr ckt Beispielsweise bedeutet das Schlie en der Stelle S ein Beenden der Anzeige des Zustandes Aus an der Oberfl che und ein L schen des Wertes false im Attribut selected Dies geht im Modell einher mit dem ffnen der Stelle S2 was in der Implementierung der Visualisierung des Zustandes An und dem Setzen des Wertes true im Attribut selected entspricht Damit ist das im Modell beschriebene Verhalten vollst ndig auf ein entsprechendes Verhalten in der Implementierung abgebildet Abbildung 6 3 Alternative Realisierung eines RadioButtons mit vier Widgets Das abstrakte Modell eines RadioButtons Abbildung 6 2 Abstraktion eines Radio Buttons mit 4 ESD Stellen wird hier alternativ auf vier verschiedene Widgetinstanzen abgebildet Die vier abstrakten Ereignisstellen sind durch zwei Widgets der Klasse JButton und zwei Widgets der Klasse JLabel realisiert Eingebettet sind die vier Widgets hier in eine Instanz der Klasse JPanel Zur Darstellung der Stellenereignisse werden dabei bestimmte Merkmale dieser Widgets verwendet Die Abbildung zeigt ein Ereignisstellendiagramm mit WYSIWYG Darstellung siehe auch unten Abschnitt 6 2 In diesem Diagramm sehen wir pro Widget nur exemplarisch die Darstellung des ge ffneten Zustands der jeweiligen abstrakten Stelle also die Buttons links im sensitiven Zustand und die Labels mit leuchtenden Lampen 105 6 Abstraktion vom konkreten Widget 6 1 1 Konkret
330. unktion 6 QE WSHist E gt QE WSHist E QE Menge von Teil Zust nden die definiert sind durch die jeweilige Menge der Ereignisse an ge ffneten Stellen Erwartungszust nde oder Ereigniszust nde also f r q q QE gilt q q e q e q wobei e q amp q CE die dem jeweiligen Gesamt Zustand zugeordnete Menge der m glichen Ereignisse Zum Startzeitpunkt gilt f r den Startteilzustand qo QE amp g U 0 mit Soc sS Ssoe So Die brigen Ereignismengen e q definieren sich rekursiv WSHist Menge von Teil Zust nden definiert durch Zuordnungen von Werten zu Stellen die jeweils in einem Zustand festgestellt werden k nnen Speicherzust nde oder Ged chtniszust nde WSHist c s s Funktion s S gt W Als Wertezuordnung so zum Startzeitpunkt haben wir start Die brigen Wertezuordnungen aus WSHist werden wir im Folgenden rekursiv definieren QE WSHist definiert die Menge der Zust nde Q Es handelt sich bei einem Zustand also um eine Kombination aus einer bestimmten Menge von Ereignissen e q und einer bestimmten Wertebelegung os an den Stellen Die Menge der Ereignisse beschreibt die aktuell m glichen Ereignisse und die Wertebelegung k nnen wir auch als die aktuell g ltige Wertezuordnung bezeichnen Die nun folgende formale Darstellung ist mit zus tzlichen Kommentaren in Kursivschrift versehen F r q q QE os os e WSHist
331. ur was die Ereignistypen betrifft unvollst ndig spezifiziert Es spiegelt einen Zwischenstand der Modellierungsphase wieder und oder eine bestimmte Teilsicht So sind z B keine Folgeereignisse f r die Ereignisstellen NewJob NewJobStep und SaveJob modelliert bzw dargestellt Erg nzung unvollst ndiger Ereignisstellen durch weitere Teilsichten Die im Beispieldiagramm mit drei Punkten dargestellte Stelle JobSelection ist eine Stelle die wie die Stellen LoadingJob SelectOperations JobStepGraph und SaveToModel entweder in diesem Diagramm noch voll ausspezifiziert werden muss oder die in einer anderen Teilsicht des Modells repr sentiert durch ein anderes Ereignisstellendiagramm ausmodelliert ist Von der Stelle sind im Diagramm nur die n tigen Teilstellen JoebName und Load angezeigt Abbildung 5 7 zeigt die voll spezifizierte Teilsicht von JobSelection Der Prototyp sieht beispielsweise die Definition von Teilsichten auf das Ereignisstellendiagramm vor um ein bersichtliches Arbeiten zu gew hrleisten 126 9 0 Koroutinen Konzept von Jacob 9 Vergleich mit bekannten Ans tzen In Kapitel 1 haben wir bereits einen kurzen berblick ber bestehende und f r die Arbeit relevante Ans tze der Modellierung gegeben In den nun folgenden Abschnitten wollen wir auf einige der Arbeit nahe liegende Konzepte etwas mehr eingehen Es handelt sich dabei zum einen um klassische Ans tze wie das Koroutinen Konzept von Jacob JACOB86 das Ereignism
332. var we evar evar o orig sneu und sneu SSubneu RO RO RO u ROneu mit ROneu s sneu U sneu s mit sneu Sneu und s orig sneu orig sneu s e RO s s SUniv d h alle neuen Stellen erhalten die Stellen berg nge zum ffnen wie die Exemplarstelle bzw deren Teilstellen Entsprechendes gilt f r die Schlie e Relation RC RC RC U RCneu mit RCneu s sneu U sneu s mit sneu SSubneu und s orig sneu orig sneu s RC wobei s s SUniv Mit den ffne und Schlie e Beziehungen der Exemplarstellen werden auch die Conditions und Propagationsfunktionen an neue Stellen berg nge entsprechend bernommen Hier muss allerdings ber cksichtigt werden dass die Parameterversorgung der Conditions und Propagationsfunktionen an den neuen Stellen berg ngen gegen ber den alten berg ngen variieren kann Dies bedeutet insbesondere dass Werte von anderen Stellen gelesen werden Formal hatten wir in Kap 5 f r Conditions und Propagationsfunktionen als Definitionsbereich selbst wieder eine Menge von Funktionen definiert n mlich die Menge der Wertezuordnungen zu einer definierten Teilmenge von Stellen Diese Stellenmenge die die m gliche Parameterversorgung einer Condition beeinflusst ndert sich nun in bestimmten F llen Wir wollen uns hier nur auf einen einfachen aber sinnvollen Fall der nderung der Wertever sorgung beschr nken n mli
333. ventSubType keyTyped oder keyReleased etc MouseEvents einer Widget Instanz EventType MouseEvent EventSubType mousePressed oder mouseMoved oder mouseReleased etc ActionEvents einer Widget Instanz EventType ActionEvent Die Angabe logischer Ereignisse mit einer automatischen oder benutzerbestimmten Umsetzung auf obige konkrete Ereignisse an Widgets fehlt bisher 10 2 5 2 Realisierung der Variationsfunktion Zur Realisierung der im Modell in Kap 7 vorgestellten Variationsfunktion ist im Prototyp eine Schnittstelle aus mehreren Methoden vorgegeben die im Folgenden erl utert werden soll Vom Prototyp wird zun chst erwartet dass eine Methode getModel existiert die ein sogenanntes Modelobjekt einer von der Klasse DiaModel abgeleiteten Klasse liefert Der Begriff Model sei hier im Sinne des Model View Controller Konzepts verstanden und soll nicht mit dem Begriff Modell im Sinne von Ereignis Modell verwechselt werden Die Klasse DiaModel ist im Prototyp bereits vorgegeben Die Methode getModel muss der Klasse geh ren die der Codegenerator f r die die Variation ausl sende Stelle erzeugt Vor dem Kompilieren wird die vom Anwender zur Verf gung gestellte Methode wie bei Conditions und Propagationsfunktionen in den Code der Klasse eingebettet Alternativ dazu kann auch die bereits vorhandene Methode einer Adapterklasse verwendet werden die als bergeordnete Klasse f r die Implementierung der Stelle gew hlt wurde 159
334. von Wertabh ngigkeiten in Constraints umfasst 9 3 State Charts UML Harel State Charts haben ihren Einzug in die Unified Modelling Language UML zur Modellierung dynamischer Vorg nge gefunden Sie gehen urspr nglich auf Harel HARELS 87 zur ck Varianten existieren etwa von Wellner WELLNS89 f r die Modellierung von Dialog Eine Integration in die Objektorientierte Modellierung stammt von Rumbaugh RUMBA9I1 Wesentliche Merkmale State Charts zeigen im Wesentlichen Zust nde und Zustands berg nge die ber Ereignisse getriggert werden Sowohl Zustands berg nge wie auch Zust nde k nnen mit Aktionen versehen werden Die den Zust nden zugeordneten Aktionen k nnen f r den Eintritt und f r den Austritt aus dem Zustand bestimmt sein WELLN89 Ebenso k nnen Aktivit ten in einem Zustand permanent ausgef hrt werden bis eine Endebedingung zutrifft Guards berg nge k nnen an Bedingungen Conditions gekn pft sein Ereignisse k nnen neben den Zustands berg ngen auch den Zust nden zugeordnet werden und dort bestimmte Aktionen ausl sen Den Zust nden zugeordnete Ereignisse bewirken keinen Zustands bergang Mithilfe des so genannten Broadcasting Mechanismus k nnen Ereignisse an Zust nde propagiert werden die dann dort die zugeordneten Aktionen ausl sen Nach Definition der UML k nnen Zust nden Zustandsvariablen mitgegeben werden die eine Untermenge der Attribute einer Objektklasse darstellen Gruppierung alternativ
335. von s1 und s2 nach s bernommen Redundanzen die durch identische Bezeichner erkannt werden werden ggf gestrichen Dies bedeutet insbesondere dass alle einzelnen Annotationen zu Ereignistypen zu einzelnen Werten Wertelisten Wertebereichen sowie Annotationen mit Typ Wertpaaren von sl und s2 nach s bernommen werden Damit wird erreicht dass die Menge der Ereignisse die s zuzuschreiben sind in jedem Falle die Ereignismengen von sl und s2 enth lt bei geeigneter Wahl der Annotationsform aber eine echt umfassende Menge der beiden Ausgangsmengen darstellt War z B an sl der Ereignistyp I annotiert und in einer gesonderten Annotation der Wertebereich lt AnyText gt an s2 der Ereignistyp O und in einer gesonderten Annotation der Wertebereich lt AnyNumber gt so ergibt sich als neue Ereignismenge die Menge der Ereignisse die die Eingabe wie auch die Ausgabe von Werten aus AnyText und AnyNumber darstellt Waren dagegen Annotatio nen als spezifische Paare I lt AnyText gt und O lt AnyNumber gt gegeben bedeutet dies dass an s die Eingabe von AnyText jedoch nur die Ausgabe von AnyNumber m glich Ist Die sich ergebende Ereignismenge ist derart dass keine Unterscheidung mehr bez glich ihrer Herkunft von den urspr nglichen Stellen gemacht werden kann D h Ereignisse beider Stel len die sich in Wert und Typ nicht unterscheiden werden als identisch betrachtet Teilstellen Alle Teilstellen von s1 und s
336. vorliegenden Arbeit zun chst einerseits nur allgemein und informell und andererseits formal nur f r bestimmte allerdings wichtige und n tzliche Aspekte der Variation wie Kardinalit t Identit t und einige Widgetattribute entwickelt 162 12 Glossar 12 Glossar Dialog Dialog ist der Austausch von Informationseinheiten an einer Dialogschnittstelle zwischen Benutzer und System Dialog kann definiert werden als eine Menge von strukturierten Dialogereignissen an einer strukturierten Dialogschnittstelle durch die Information zwischen zwei oder mehreren Partnern ausgetauscht werden Wir wollen im Folgenden von zwei Partnern dem Benutzer und dem System ausgehen Im System kann je nach Betrachtung zwischen zwei Komponenten unterschieden werden n mlich der Kompo nente zur Realisierung der Applikationslogik und der Komponente die zur Realisierung der Dialogschnittstelle beitr gt Dialogart Eine Dialogart beschreibt die Art und Weise in der die Kommunikation zwischen den Dialogpartnern gef hrt wird Klassische Dialogarten sind z B Frage Antwort Dialog Kommandodialog Men dialog etc Als moderne Dialogarten k nnen wir den grafischen oder den multimedialen Dialog sehen Dialogarten h ngen zum Teil von den technischen M glichkeiten den verf gbaren Eingabe Ausgabeger ten ab siehe auch FAEHN87 Dialogpartner Als Partner fungieren ein oder mehrere Benutzer auf der einen Seite auf der anderen Seite das System oder mehrere System
337. weis dass im Diagramm bergeordnete Stellen weggelassen wurden Wie oben bereits erw hnt handelt es sich um eine so genannte Jokerstelle die mit 97 5 Ereignisstellenmodell JobEditor JobSelection SensitiviyReports DailyCash WO SomeJobName VO Abbildung 5 7 Auslagerung und gegenseitige Erg nzung in Teilsichten Die Abbildung nimmt zwei m gliche Teilsichten des Modellbeispiels von Kapitel 8 vorweg Wichtig zum Verst ndnis ist hier nur dass das obere Rechteck den Gesamtdialog JobEditor als Teilsicht zeigt was an den drei Punkten in der Fl che des JobEditor Rechtecks zu erkennen ist Die drei gezeigten Teilstellen stellen wiederum nur jeweils eine Teilsicht dar Die Teilstelle JobSelection wird nun durch die im unteren Rechteck gezeigte Teilsicht JobSelection erg nzt JobSelection selbst ist durch die vorangestellten drei Punkte im Namen eine Jokerstelle die mit der obigen Aufrufstelle oder Fixstelle JobSelection zusammengef hrt wird Die Jokerstellen JobName und Load oben in JobSelection erkennbar an den schr g zum Rechteck gef hrten Linien fallen mit den entsprechenden Stellen JobName und Load unten zusammen ihrer Information ber die Teilstellen die andere Stelle die wir als Aufrufstelle bezeichnen k nnen erg nzt Generell gilt dass eine Jokerstelle alle ihre Information an eine andere Stelle bertr gt die den gleichen Bez
338. werden m ssen bevor die durch A bzw B repr sentierten Prozessteile ablaufen k nnen Als Pr fixe kommen im Pi Kalk l drei Arten in Frage die das Senden einer Nachricht das Empfangen einer Nachricht oder die Durchf hrung einer nicht beobachtbaren Transition siehe unten Transitionssystem bedeuten also mi inx y steht f r Empfangen einer Nachricht y mittels x out w Z steht f r Senden einer Nachricht z mittels w T steht f r nicht beobachtbare Transition x y w z sind Namen die zum einen f r so genannte Ports stehen zum anderen aber f r Nachrichten bzw Objekte die mittels der Ports von einem Prozess bzw einer 139 9 Vergleich mit bekannten Ans tzen Prozesskomponente zur anderen gesendet werden Im obigen Beispiel sind mit x und w Ports mit y und z Nachrichten gemeint Entscheidend im Pi Kalk l ist aber dass derselbe Name sowohl die Rolle eines Ports als auch die Rolle einer Nachricht bernehmen kann Hinter den Namen verbergen sich letztlich Objekte die ggf im Kalk l abh ngig von der Betrachtung unterschiedliche Rollen spielen So kann eben der Name eines Ports also einer Verbindung zwischen Prozessen als Nachricht wiederum ber einen anderen Port bermittelt werden und an einer bestimmten anderen Stelle dann selbst als Port dienen siehe unten Namensersetzung bei Reaktion Komposition P P2 Das Zeichen steht f r die Nebenl ufigkeit der beiden Prozesskomponenten P1 und P2 Restrik
339. wollen Eine hnliche berlegung gilt schon aus Symmetriegr nden f r den vierten Ereignistyp da genau genommen mit der Ausgabe von Information durch das System an der Dialogschnitt stelle noch keine Wahrnehmung dieser Information durch den Benutzer gew hrleistet ist Der vierte Ereignistyp wird aber f r unsere Modellierung kaum eine Rolle spielen da die Wahr nehmung der Information durch den Benutzer nicht Gegenstand des EDV Systemmodells sein kann und soll Der Vorgang des Lesens ist im Allgemeinen als ein aktiver Vorgang verstanden Wir wollen in unserem Modell jedoch zwischen einem aktiven und passiven bzw einem asynchronen und synchronen Lesen unterscheiden Im Falle des asynchronen Lesens steuert die Systemkomponente den Lesevorgang selbst an so dass der Zeitpunkt des Lesens von der Dialogschnittstelle in der Regel nicht unmittelbar nach dem Eingabeereignis an der Schnittstelle erfolgt Im Falle des synchronen Lesens handelt es sich um einen Vorgang in dem das Eingabeereignis unmittelbar das Leseereignis bewirkt siehe auch unten Ereignisfolgen Ereignisse k nnen strukturiert sein und deren Struktur kann ber Relationen siehe unten beschrieben werden 3 0 1 Dialogstelle Dialogstellen sind Elemente unseres Modells denen jeweils eine Menge von Dialogereignis sen zugeordnet werden kann Diese Zuordnung wird dadurch definiert dass umgekehrt jedem Ereignis eine Stelle zugeordnet wird Wir sagen ein Dialog Ereignis fin
340. wort Dialog kann z B inhaltlich gesehen prinzipiell derselbe Informationsaus tausch erfolgen wie im Kommandodialog Ein wesentlicher Unterschied ist lediglich dass im 27 2 Neuer integrierter Modellierungsansatz Frage Antwort Dialog das System die F hrung des Dialogs bernimmt w hrend im Kommandodialog der Benutzer die Initiative ergreift und im Frage Antwort Dialog sich der Dialog mitunter sehr lange hinzieht bis die gew nschte Information bermittelt ist Allerdings sieht man an diesem Beispiel dass die Wahl der Dialogart nicht in allen Anwendungsf llen unbedeutend f r die Erf llung der Aufgabenstellung ist Es kann z B in bestimmten F llen entscheidend sein welcher Dialogpartner die Initiative des Informationsaustausches bernehmen kann Denken wir z B an Dialogsysteme zur Steuerung von Produktions prozessen wo sorgf ltig entschieden werden muss in welchem Umfang in kritischen Situationen das System oder der Benutzer den Dialog steuert Eine Notbremse sollte immer f r den Benutzer m glich sein Gleichzeitig muss ausgeschlossen sein dass sich der Benutzer dadurch selbst oder andere Mitarbeiter gef hrdet Dialogstile Noch unbedeutender f r die logisch bermittelte Information kann die Wahl eines bestimmten Dialogstils gesehen werden Was in der Regel in so genannten Stylesheets definiert ist wie etwa die Wahl eines bestimmten Zeichensatzes einer Schriftgr e einer bestimmten Hintergrundfarbe etc ist f r den l
341. ynamischen L sung zu kommen ohne dabei die konkreten Ans tze in Entwurf und Realisierung zu verlieren und die Architektur des Modells umwerfen zu m ssen Aus einer Skizze mit konkreter exemplarischer Darstellung oder aus einer konkreten aber nicht umfassenden Darstellung die bereits implementiert ist soll die variable allgemeine L sung unter maximaler Nutzung der zun chst durchgef hrten fixen konkreten Entwurfs und Entwicklungsschritte formuliert werden Ein weiterer Vorteil dieses Vorgehens ist dass nach wie vor auch dem Entwickler und dem zuk nftigen Benutzer des zu entwerfenden bzw zu entwickelnden Systems eine unmittelbare konkrete Vorstellung vom System durch die exemplarische Darstellung erhalten bleibt Aus dieser Zielsetzung leitet sich nun der Ansatz der exemplarischen Darstellung mit Variation ab der die Darstellung eines oder mehrerer Exemplare im Modell vorsieht dem oder denen Information zugeordnet wird die die verallgemeinernde L sung beschreibt Die dem Exemplar zugef gte Variationsbeschreibung ist grafischer oder textueller Natur und definiert die allgemeine L sung die unterschiedlichen Varianten des Exemplars Mit der Darstellung des Exemplars bleibt das Modell so konkret wie m glich Ausgehend vom konkreten Beispiel werden die verschiedenen Abwandlungen beschrieben Dies geschieht in einer Sprache die sich weitgehend am Ergebnis orientiert und weitgehend als deskriptiv verstanden werden kann Zentrale Ele
342. zu modellieren bzw das Prinzip der externen Kontrolle wie es bei grafischen Oberfl chen zugrunde liegt zu beschreiben Kommunikation mit anderen Objekten ber Funktionen Das ffnen von anderen Objekten aufgrund von Ereignissen in einem Objekt wird bei Jacob nicht als Ausgabeereignis gesehen sondern wird ber eine Applikationsfunktion erreicht w hrend wie bereits oben erw hnt durchaus Ausgabeereignisse innerhalb eines Objektes als Ereignisse mit ggf Zustandswechsel dargestellt werden SYNTAX main Act Displaytf inbox iENTER oDEHISHLISHT Abbildung 9 1 Beispieldiagramm nach Jacob aus JACOBS86 mit Anzeige eines Oberfl chenobjektes ber Funktionsaufruf Das Diagramm zeigt die Zustands berg nge eines Buttons Die mit dem Pluszeichen gekennzeichneten Zust nde sind Zust nde mit Eingabeerwartung iENTER iEXIT definieren Tokens f r die Positionierung des Mauscursors OHIGHLIGHT und oDEHIGHILIGHT stehen f r Ausgabetokens Dr cken der linken Maustaste Eingabetoken iLEFT l st die Aktion DisplayMflinbox aus die das ffnen eines anderen Dialogobjektes bewirkt Kommunikation ber Synthetic Tokens berg nge in Z D s k nnen mit so genannten Synthetic Tokens also zusammengesetzten Tokens versehen werden Das Erkennen eines derartigen Tokens bestehend aus einer Sequenz elementarer Tokens wird dann auf ein anderes in einem definierten Scope liegendes Objekt i d Regel hierarchisch untergeordnetes Objekt verla
343. zur Modellierung mit Ereignisstellendiagrammen wurden fast ausnahmslos mit dem Modelleditor des Prototyps erstellt Die Diagrammelemente wie z B die Rechtecke der abstrakten Ereignisstellen ihre Annotationen die Darstellung der Pfeile zum ffnen Schlie en zur Wert bertragung etc werden in einfacher direkter Manipulation mittels Maus kreiert und bearbeitet In gleicher Weise erfolgt die Erzeugung konkreter Widgets alternativ zu abstrakten Ereignisstellen sowie die nachtr gliche Zuordnung konkreter Widgets zu abstrakten Stellen mittels einfacher Selektionsmechanismen und z B direkter Zuordnung mittels Mausklick Zus tzlich zur Manipulation mit der Maus wurden einige wichtige Funktionen wie z B das Kopieren von Modellelementen als sogenannte Shortcuts auf bestimmte Funktionstasten der Tastatur gelegt Edition abstrakter Ereignisstellen Der Benutzer hat die Freiheit zun chst auf Ebene der abstrakten Ereignisstellen zu modellieren ohne sich dabei auf bestimmte konkrete Dialogobjekte etwa die Klassen des zu Grunde liegenden Toolkits festlegen zu m ssen Er legt damit die hierarchische Bestandteilsstruktur der Ereignisstellen und ihre dynamischen Bez ge fest ber entsprechende Annotationen k nnen den Stellen Name Typ Wertebereich Defaultwert etc entsprechend Ausf hrungen in Abschnitt 5 2 Grafische Darstellung zugeordnet werden Edition auf Ebene konkreter Widgets Alternativ hat der Benutzer die M glichkeit statt abstrakter
344. zvariation einer Stelle bezeichnen Ist eine Stelle ge ffnet ist sie f r den Benutzer des Dialogsystems bzw das System existent Im anderen Fall steht sie f r die Wahrnehmung von Eingabe oder Ausgabeereignissen bzw f r Lese und Schreiboperationen nicht zur Verf gung und ist damit aus Sicht von Benutzer und oder System nicht existent 7 5 Variation einer Existenzvariation Im obigen Beispiel der Toolbar mit Icons haben wir als Exemplare der Variation die Icons gew hlt Im Sinne eines ESM handelt es sich dabei um Konkretisierungen von Dialogstellen s aus S Diese wurden als Bezugspunkte oder Ausgangspunkte f r die Variation gew hlt In der Variation wurde die Menge der Exemplarstellen durch eine andere Menge von Dialogstellen ersetzt und gleichzeitig damit wurden Aussagen ber die Exemplarstellen wie z B die zugeordnete Bitmap ver ndert In der abstrakten Sicht eines ESM handelt es sich um Teilstellen der Exemplarstellen bzw der die Exemplarstellen ersetzenden Stellen die durch die Variation in ihren Werten ver ndert wurden In gleicher Weise k nnen nun auch die im Modell vorgesehenen Elemente der Relationen insbesondere die Stellenpaare aus den Relationen RO und RC als Ausgangspunkte einer Variation dienen Dies bedeutet dass wir dann sozusagen nicht die Dialogstellen selbst sondern Aussagen ber Beziehungen zwischen Dialogstellen als Bezugspunkt der Variation heranziehen 7 5 0 Beispiel Variation zur Ausl sung eines Druckdialo

Modellierung grafischer Dialogsysteme mit

Contents

Download Pdf Manuals

Related Search

Related Contents