4 Grundlegende Struktur einer Tango-Spezifikation
| Teil II - Tango-Beschreibungsmethodik | |
4 Grundlegende Struktur einer Tango-Spezifikation |
|
Die Spezifikation besteht aus einer nicht geschachtelten Abfolge von Definitionsblöcken, in denen Aspekte des Produkts definiert und dann verfeinert werden. Die Reihenfolge, in der die Definitionsblöcke niedergeschrieben sind, ist nicht von Bedeutung. Die Aspekte können statische oder dynamische Eigenschaften des Produkts beschreiben. Die Wirkungen, die als Folge von Vorgängen innerhalb des Produkts eintreten, sind in Aktivitätsblöcken zusammengefasst.
Eine Aufteilung der Tango-Spezifikation in Bereiche kann die Lesbarkeit der Spezifikation verbessern oder die Weiterverarbeitung erleichtern. Für Inhalt und Aussage einer Spezifikation ist die Aufteilung in Bereiche ohne Bedeutung.
Eine Tango-Spezifikation kann in mehrere Dateien zerlegt sein. Die Dateien werden an beliebiger Stelle außerhalb eines Definitionsblocks in eine andere Datei eingebunden. Die Reihenfolge oder der Ort des Einbindens ist ohne Bedeutung.
4.1 Beispiel: Anmeldedialog |
|
Die nachfolgende Spezifikation für einen Anmeldedialog enthält viele Sprachelemente, auf die in der nachfolgenden Erläuterung der Struktur Bezug genommen wird. Mit den Erkenntnissen aus dem Beispiel Speichern Unter-Dialog sollte dieses Beispiel problemlos lesbar sein.
!$LoginDaten
.UserListe
...User
.UserName
.Passwort
.HomeVerzeichnis
.ZugangErlaubt : [ KannArbeiten | Gesperrt ]
.PasswortZuletztGeändert : _Datum
...
...
!+InitLogin
=> .WnLogin.OPEN
.WnLogin.TxMeldung := "Bitte melden Sie sich am System an"
.WnLogin.EtUserName := {Zuletzt verwendeter Anmeldename}
.WnLogin.EtPasswort.Inhalt := ""
.WnLogin.EtPasswort.TxAnzeige := ""
!#WnLogin
.TxMeldung
.EtUserName
.+CR
=> .@JetztAnmelden
.EtPasswort
.$Inhalt // wird editiert, aber nicht angezeigt
.TxAnzeige : [ LEER | "ein oder mehrere Sternchen" ]
.{während der Eingabe ein Sternchen pro eingetipptem Zeichen an TxAnzeige anhängen}
.{Länge von TxAnzeige darf von der Länge von $Inhalt abweichen}
.+CR
=> .@JetztAnmelden
.+BtLogin
=> .@JetztAnmelden
.+BtAbbrechen
=> .*InitLogin // alles wieder von vorn
!@JetztAnmelden
=> .?{Am System anmelden mit EtUserName und EtPasswort} =
= "Anmeldung erfolgreich"
=> .WnLogin.CLOSE
...
= "Anmeldung nicht erfolgreich"
=> .WnLogin.EtPasswort.TxAnzeige := {10 Sternchen}
.WnLogin.EtPasswort.SELECT
.WnLogin.TxMeldung := "Anmeldung fehlgeschlagen, nochmal versuchen"
!§TabWirkung
.{TAB verlässt das aktuell bearbeitete Element und geht zum geografisch nachfolgenden}
.{alle Elemente außer TxMeldung sind mit TAB erreichbar}
Diese Spezifikation besteht aus fünf Definitionsblöcken: dem Zustand $LoginDaten, einem Aktivator +InitLogin als Startpunkt, dem Fenster #WnLogin, einer Aktion @JetztAnmelden und der Eigenschaft §TabWirkung.
Der Zustand $LoginDaten enthält eine Liste aus Usern und ihren Zugangsdaten, wie sie z.B. in einer Datenbank oder Datei abgelegt sein könnten. Der Aktivator +InitLogin ist nicht Teil eines Fensters, dies ist auch nicht notwendig um ihn auslösen zu können. Er beschreibt, wie das Produkt initialisiert werden soll, aber nicht, woher der Anstoß dazu kommt. Im Aktivitätsblock zu WnLogin.BtAbbrechen löst das Ereignis *InitLogin den zugehörigen Aktivator aus und der Anfangszustand der Bedienung wird wieder hergestellt.. Die Wirkung der Tabulator-Taste ist formlos und relativ unscharf in der Eigenschaft §TabWirkung beschrieben, da die Spezifikation keine Aussagen über die Position der Elemente auf der Bedienoberfläche enthält.
Für weitere Erläuterung unbekannter Konstrukte sei auf den Referenzteil dieses Dokuments verwiesen.
4.2 Zentrale Konzepte der Beschreibung |
|
Aspekt |
 |
Aspekte sind das zentrale Element jeder Tango-Spezifikation. Die Spezifikation definiert und ordnet Aspekte, und die Gesamtheit der Aspekte beschreibt das Produkt im gewünschten Detaillierungsgrad. Ein Aspekt enthält irgendeine Aussage über das Produkt, er ist nicht an ein spezielles syntaktisches Konstrukt gebunden. Ein Aspekt wird durch seine Verwendung definiert und muss nicht explizit oder vorab definiert werden.
Im Beispiel Anmeldedialog wird mit der Aussage ZugangErlaubt : [ KannArbeiten | Gesperrt ] der Zustand ZugangErlaubt definiert, und ebenso dessen Werte KannArbeiten und Gesperrt, weil sie hier zum ersten Mal verwendet werden. Eine explizite Definition dieser Werte oder eine nähere Erläuterung sind unnötig.
Ein Aspekt kann eine Aussage sein über Elemente, Eigenschaften oder Wirkungen des Produkts. Ein Aspekt wird als Element bezeichnet, wenn er lokalisierbar ist, z.B. weil der Aspekt ein sichtbares oder bedienbares Teil einer Benutzeroberfläche beschreibt. Eine Eigenschaft ist zeitlich oder örtlich nicht exakt eingrenzbar und enthält oft implizit oder explizit Aussagen mit immer, niemals, alle oder überall. Wirkungen beschreiben das Ergebnis von Vorgängen, also das dynamische Verhalten des Produkts.
Die Zuordnung von Aspekten zu Elementen, Eigenschaften oder Wirkungen ist nicht immer klar, aber in unklaren Fällen hat diese Unterscheidung wenig praktische Bedeutung, und sie kann dann auch ignoriert werden. Insbesondere Eigenschaften können Aussagen enthalten, die eher Elementen oder Wirkungen zuzuordnen sind. Solche Eigenschaften finden sich an Stellen, an denen die Beschreibung nicht mehr weiter ins Detail ausgeführt werden soll.
Im Beispiel Anmeldedialog enthält das Element WnLogin.EtPasswort.TxAnzeige die Eigenschaft {während der Eingabe ein Sternchen pro eingetipptem Zeichen an TxAnzeige anhängen}. Diese Aussage könnte alternativ auch in einem Aktivitätsblock als Wirkung formuliert sein. Dass diese Eigenschaft eigentlich eine Wirkung beschreibt, ist ohne Bedeutung, wichtig ist nur die klare Aussage.
In einer Tango-Spezifikation können auch nichtfunktionale Aussagen über das Produkt getroffen werden. Dies können Leistungsanforderungen sein, aber ebenso organisatorische Verweise auf zusätzliche Dokumente wie z.B. Screenshots, in denen das Design von Fenstern vorgegeben wird:
!§{Das Design von Fenster #WnMain ist in Bild 2 des Protokolls vom 18.12. festgelegt}
!§{Jedes angeforderte Fenster ist in höchstens einer Sekunde sichtbar}
!§{Das System startet nach einem Stomausfall wieder selbständig die unterbrochene Applikation}
Ein Aspekt kann formlos beschrieben werden, entweder als allgemeine formlose Beschreibung oder als formlose Wertbeschreibung. Wenn auf einen Aspekt von verschiedenen Stellen der Spezifikation aus zugegriffen werden soll, so kann dem Aspekt ein Name und damit eine Identität gegeben werden. Über den Namen ist der Aspekt eindeutig referenzierbar. Zur Referenz auf einen Aspekt wird der Pfad angegeben, der vom Kopfaspekt eines Definitionsblocks aus über die Teile-Beziehung zum gewünschten Aspekt führt.
Im Beispiel Anmeldedialog wird das Feld zur Eingabe des Passworts mit dem Namen EtPasswort eindeutig identifiziert. Damit kann dieser Aspekt aus +InitLogin und @JetztAnmelden heraus referenziert werden. Im Aktivitätsblock zu +InitLogin wird ein Aspekt beschrieben mit {Zuletzt verwendeter Anmeldename}. Dieser Aspekt ist formlos beschrieben und wird nirgendwo sonst in der Spezifikation verwendet. Die Referenz auf diesen namenlosen Aspekt wäre schwierig.
Definitionsblock |
|
Eine Tango-Spezifikation besteht auf oberster Ebene aus einer nicht geordneten und nicht geschachtelten Menge von Definitionsblöcken. Es gibt keinen zentralen Aspekt, der das ganze Produkt beschreiben würde.
Jeder Definitionsblock beginnt mit der Beschreibung eines einzelnen Aspekts, genannt der Kopfaspekt. Die Nennung des Aspekts ist bereits ein korrekter Definitionsblock der besagt, dass es diesen Aspekt gibt. Wenn zu diesem Kopfaspekt noch mehr zu sagen ist, so kann die Beschreibung über die Teile-Beziehung verfeinert werden.
Erhält der Kopfaspekt einen Namen, so muss dieser Name innerhalb der Spezifikation (genauer: innerhalb dieser Datei der Spezifikation) eindeutig sein, so dass jeder Definitionsblock anhand des Namens seines Kopfaspekts eindeutig unterscheidbar ist. Daneben hat jeder Definitionsblock seinen eigenen Kontext, d.h. benannte Aspekte müssen, soweit sie in der Spezifikation tatsächlich referenziert werden, innerhalb des Definitionsblocks durch den Pfad zum Aspekt eindeutig unterscheidbar sein.
Das Beispiel Anmeldedialog enthält fünf Definitionsblöcke. Der Definitionsblock für $LoginDaten endet, wenn der nächste Definitionsblock für +InitLogin beginnt. Es gibt keine explizite Ende-Markierung für einen Definitionsblock.
Teile-Beziehung |
|
Aspekte können verfeinert werden, indem Teilaspekte (synonym: Unteraspekte) explizit niedergeschrieben werden. Diese Teilaspekte können die bereits vorhandene Beschreibung des Aspekts konkretisieren, oder sie können neue Information über den Aspekt liefern. Der Zusammenhang zwischen dem übergeordneten Aspekt und den Unteraspekten wird als Teile-Beziehung oder Verfeinerung bezeichnet.
Die Unteraspekte werden unter dem Aspekt eingerückt, den sie verfeinern. Jeder Unteraspekt kann seinerseits wieder verfeinert werden, so dass eine hierarchische Baumstruktur aus Teile-Beziehungen entsteht. Mehrere Unteraspekte zu einem Aspekt werden als Aufzählung notiert, wenn deren Reihenfolge keine Rolle spielt, andernfalls als Sequenz.Die Interpretation einer Teile-Beziehung ist variabel. Wenn ein Element durch untergeordnete Elemente verfeinert wird, so kann die Teile-Beziehung als besteht aus gelesen werden wie in diesem Beispiel:
!#WnFenster
.EtEingabe
.+BtAusKnopf
.+BtEinKnopf
Ein Aspekt kann durch die Angabe seiner Eigenschaften näher beschrieben werden, die Teile-Beziehung kann als hat folgende Eigenschaft gelesen werden:
!DieseEnte
.{kann fliegen}
.{hat sich gestern füttern lassen}
.{schläft gerade am Uferrand}
Ein Aktivitätsblock beschreibt Wirkungen, die unter bestimmten Umständen eintreten. Der Aktivitätsblock als Aspekt der Teile-Beziehung kann als hat zur Folge gelesen werden. Die einzelnen Aspekte der Aufzählung im Aktivitätsblock sind mit UND verknüpft und ohne bestimmte Reihenfolge:
!+WohnungPutzen
=> .{Teppich staubfrei}
.{Fenster sauber}
.{Schrank abgestaubt}
Eine Sequenz von Wirkungen in einem Aktivitätsblock wird als UND DANN gelesen:
!+LiedVorsingen
=> -ErsteStropheSingen
-RefrainSingen
-ZweiteStropheSingen
-RefrainSingen
-RefrainSingen
-Verbeugen
Durch die Teile-Beziehung entsteht aus jedem Definitionsblock in der Tango-Spezifikation ein hierarchischer Baum aus Aspekten. Jeder Aspekt in diesem Baum, außer Aktivitätsblöcken und ihrem Inhalt, kann referenziert werden durch einen Pfad, der beim Kopfaspekt des Definitionsblocks beginnt und durch die Teile-Beziehung bis zum gewünschten Aspekt führt.
Im Beispiel Anmeldedialog wird im Aktivitätsblock von +InitLogin über den Pfad WnLogin.EtPasswort.TxAnzeige auf die maskierte Anzeige des Passwortfeldes zugegriffen. Die einzelnen Schritte des Pfades werden immer durch einen Punkt getrennt, auch wenn in eine Sequenz hinein referenziert würde.
Mehrere Unteraspekte zu einem übergeordneten Aspekt werden in einer Aufzählung oder als Sequenz notiert. Eine Menge von gleichartigen Unteraspekten kann als Liste angegeben werden. Diese Liste ersetzt die explizite Niederschrift jedes einzelnen Listeneintrags an dieser Stelle. Die Anzahl der Einträge in einer Liste ist variabel, die Einträge selbst sind ungeordnet wie in einer Aufzählung. Wenn die Reihenfolge der Listeneinträge von Bedeutung ist, dann kann stattdessen eine geordnete Liste verwendet werden.
!$Teilnehmerliste
...Teilnehmer // ungeordnete Liste von Teilnehmern
.Name // jeder Teilnehmer hat einen Namen
.Vorname // und einen Vornamen
!$Tagesordnung
---Thema // geordnete Liste, Reihenfolge der Themen ist festgelegt
.BeschlussNotwendig : _Boolean
Die Teile-Beziehung erfordert das korrekte Einrücken von Text. Diese Einrückungen müssen unter allen Umständen beibehalten werden, damit sich die Aussage der Spezifikation nicht ändert. Wenn die Tango-Spezifikation als einfaches Text-Dokument erstellt wird, sollten in diesem Dokument entweder nur Tabulatorzeichen oder nur Leerzeichen zum Einrücken verwendet werden. Ein Zeichensatz mit einheitlicher Zeichenbreite ist empfehlenswert. Unter diesen Umständen ist gewährleistet, dass Tango-Spezifikationen mit allen Editoren korrekt gelesen werden. Das Einrücken um vier Leerzeichen pro Schachtelungsebene hat sich bewährt.
Aktivitätsblock |
|
Ein Aktivitätsblock enthält eine geordnete oder nicht geordnete Sammlung von Wirkungen, die eintreten müssen, wenn eine Vorbedingung erfüllt ist. Aktivitätsblöcke sind etwas Besonderes, weil hier Ursache-Wirkungs-Zusammenhänge beschrieben werden, also das Verhalten des Produkts, während sonst nur statische Aspekte niedergeschrieben sind. 1)
Aus einem Aktivitätsblock kann mit Pfaden auf statische Aspekte irgendwo in der Spezifikation referenziert werden, aber umgekehrt ist eine Referenz in einen Aktivitätsblock hinein nicht möglich, weder von einem statischen Aspekt aus noch aus einem anderen Aktivitätsblock. Der Grund für diese Einbahnstraße liegt darin, dass die Relevanz eines Aktivitätsblocks von Vorbedingungen abhängt, die an anderer Stelle der Spezifikation außer in eben diesem Aktivitätsblock nicht erfüllt sein können. Solche Vorbedingungen können sein:
Die Wirkungen in einem Aktivitätsblock können als Aufzählung beschrieben werden, dann ist der Aktivitätsblock eine ungeordnete Checkliste von Wirkungen, die unter den gegebenen Vorbedingungen eingetreten sein müssen. Eine Tango-Spezifikation beschreibt immer nur, was als Wirkung beobachtet werden kann, aber niemals, welche Tätigkeiten ausgeführt werden müssen, um diese Wirkung zu erzielen. Die Aufzählung der Wirkungen in einem Aktivitätsblock ist deshalb posthum, also ein Blick zurück auf das, was bereits passiert ist 2).
Ein Aktivitätsblock kann eine Sequenz von Wirkungen enthalten, die in genau dieser Reihenfolge eintreten müssen. Die Sequenz entspricht einer Checkliste, die in der vorgegebenen Reihenfolge abgearbeitet werden muss.
Bereich |
|
Eine Tango-Spezifikation kann in Bereiche gegliedert sein, um die Lesbarkeit zu verbessern, oder um solche Definitionsblöcke zusammenzufassen, die in späteren Projektschritten in gleicher Weise weiterverarbeitet werden sollen. Die Gliederung in Bereiche hat keinerlei Auswirkungen auf den Inhalt der Spezifikation. Die Reihenfolge der Definitionsblöcke ist nicht relevant, deshalb können diese Blöcke beliebig in Bereiche umgruppiert werden. Ein einzelner Definitionsblock kann per Konvention nicht in mehrere Bereiche aufgeteilt werden, obwohl selbst dies keine Auswirkung auf die Aussage der Tango-Spezifikation hätte.
Bereiche können nicht ineinander geschachtelt werden. Ein Bereich endet dort, wo ein neuer beginnt, oder am Ende der Datei. Bereiche sind eine besondere Form der Kommentierung und sind deshalb kein eigenes Sprachelement der Tango-Beschreibungssprache. Ihre Bedeutung liegt darin, dass damit die spätere Weiterverarbeitung der Spezifikation vorbereitet werden kann.
Im nachfolgenden Beispiel wird der Bereich ALIAS eingeführt. Ein Alias ist ein abstrakter Bedienschritt, der verschiedene Wege zum selben Ziel beschreibt, z.B. den Aufruf von Funktionen des Produkts wahlweise über ein Menü, ein Icon auf der Werkzeugleiste, oder ein Tastenkürzel. Diese Alternativen vorab zu identifizieren und durch einen Blick in den Programmcode zu verifizieren kann den eigentlichen funktionalen Test eines Produkts erheblich verkürzen. Der Sinn dieses Bereichs liegt also darin, dass der Inhalt nicht wie üblich in einer Testprozedur, sondern durch einen Code Review verifiziert wird.
//
// A L I A S
//
! ++Speichern
.+BtSpeichern // Knopf im (einzigen) Fenster
.+MenüDatei.Speichern // Auswahl im Menü
.+CTRL-S // Control + Taste S
Im funktionalen Test kann die Funktion Speichern (der Alias) auf beliebigem Weg ausgelöst werden, wenn vorher verifiziert wurde, dass diese Wege zum exakt identischen Ziel führen.
Einbinden von Dateien |
|
Eine Tango-Spezifikation kann auf mehrere Dateien aufgeteilt werden. Eine einzelne Datei enthält eine Menge von Definitionsblöcken, ein Definitionsblock kann sich nicht über mehr als eine Datei erstrecken. Die Aufteilung unterliegt keinen weiteren Randbedingungen, es ist also ohne Bedeutung, ob die Definitionsblöcke einer einzelnen Datei für sich selbst genommen irgendeine Aussagekraft besitzen.
Jede Datei kann in jede andere eingebunden werden, dabei ist mehrfaches oder zyklisches Einbinden möglich. Die Reihenfolge von Definitionsblöcken spielt in einer Tango-Spezifikation keine Rolle, deshalb können Dateien mit weiteren Spezifikationsteilen an jeder beliebigen Stelle eingebunden werden. Ebenso ist ohne Bedeutung, wenn das Einbinden der Datei erst nach der Nutzung des Inhalts dieser fremden Datei erfolgt.
Mit dem Einbinden erhält eine Datei einen Namen. Die Aspekte der eingebundenen Datei sind über einen Pfad zugänglich, der mit diesem Namen beginnt. Der für diese Datei vergebene Name muss wie immer eindeutig sein.
!! Modul1 <- "mueller-modul1.txt"
!#WnDiesesFenster
.TxStatus <- Modul1.WnDetail.Modifiziert
In diesem Beispiel wird die Datei mueller-modul1.txt unter dem Namen Modul1 in die aktuelle Datei eingebunden. Der Aspekt WnDiesesFenster.TxStatus erhält einen Verweis auf einen Aspekt, der in der fremden Datei.beschrieben ist.
Der Name der fremden Datei wird behandelt wie jeder Kopfaspekt eines Definitionsblocks. Eine Namenskollision der Aspekte in der fremden Datei mit den eigenen Aspekten ist ausgeschlossen, da der für die fremde Datei vergebene Name eindeutig ist und eine Referenz immer mit diesem Namen beginnt.
4.3 Wesentliche Sprachelemente |
|
Eine Tango-Spezifikation besteht aus einer Folge von Definitionsblöcken. Dies ist die einzige strukturelle Vorgabe einer Tango-Spezifikation, die gesamte restliche Beschreibung des Produkts könnte formlos niedergeschrieben werden. Die Nutzung weiterer Sprachelemente bietet gegenüber formlosen Beschreibungen zwei Vorteile:
Definitionsblock und Teile-Beziehung |
|
Ein Definitionsblock wird eingeleitet mit einem führendem Ausrufezeichen !, danach folgt der Aspekt, der in diesem Definitionsblock beschrieben werden soll (Kopfaspekt). Der Kopfaspekt allein bildet bereits einen vollständigen Definitionsblock. Weitere Informationen über den Kopfaspekt können als untergeordnete Aspekte mittels der Teile-Beziehung hinzugefügt werden.
Das Beispiel Anmeldedialog enthält fünf Definitionsblöcke, deren Aspekte mit Teile-Beziehungen näher beschrieben werden.
Jeder Aspekt in der Tango-Spezifikation ist Teil eines Definitionsblocks, entweder als Kopfaspekt, oder als ein untergeordneter Aspekt, der zur näheren Beschreibung dient. Jeder Aspekt außerhalb eines Aktivitätsblocks kann deshalb durch einen Pfad referenziert werden, der beim Kopfaspekt eines Definitionsblocks beginnt. Dies gilt auch dann, wenn auf einen Aspekt in einer anderen Datei zugegriffen werden muss, denn der Name, mit dem der Inhalt der Datei zugänglich gemacht wird, ist der Name eines Kopfaspekts eines Definitionsblocks.
Ein Definitionsblock endet, wenn der nächste Definitionsblock beginnt oder wenn die Datei endet. Definitionsblöcke können nicht geschachtelt werden.
Die Teile-Beziehung stellt eine Beziehung her zwischen einem übergeordneten Aspekt und einem Block von untergeordneten Aspekten. Der Unterblock wird gegenüber dem übergeordneten Aspekt eingerückt, er kann aus einem einzelnen Aspekt bestehen, oder aus einer Aufzählung oder einer Sequenz von Aspekten. Einer der Aspekte in einem Definitionsblock oder Unterblock kann ein Aktivitätsblock sein, der Wirkungen beschreibt, die unter bestimmten Voraussetzungen eintreten.
Formlose Beschreibung, Name und Pfad |
|
Die allgemeine formlose Beschreibung ist von geschweiften Klammern umfasst und erlaubt, einen Aspekt in beliebiger Weise zu beschreiben. Diese Beschreibung unterliegt keinerlei Einschränkungen außer der einen, dass die schließende geschweifte Klammer als solche erkennbar sein muss. Dies bedeutet, dass geschweifte Klammern in der Beschreibung selbst verwendet werden können, sie dürfen aber nur paarweise auftreten.
Die allgemeine formlose Beschreibung ist das universelle Beschreibungsmittel, und sie wird verwendet, wenn an irgendeiner Stelle der Spezifikation keine weitere Detaillierung mehr notwendig ist.
Für die Beschreibung von Werten kann statt der allgemeinen formlosen Beschreibung die formlose Wertbeschreibung verwendet werden. Die Beschreibung ist zwischen Gänsefüßchen gesetzt und unterliegt nur der einen Einschränkung, dass darin keine Gänsefüßchen vorkommen können. Werte können verwendet werden, um Zustände oder zu prüfende Alternativen in Verzweigungen oder einer Bedingung zu beschreiben, oder um Information zu beschreiben, die gesendet wird. Die formlose Wertbeschreibung enthält die Bedeutung der Werte, nicht die Werte selbst. Sie informiert vorrangig über den Sinn und Zweck des Wertes, und nicht den Inhalt. Deshalb wird ein logischer Wert nicht einfach mit "Ja" beschrieben, sondern z.B. mit "Ja, ist angekommen".
Das Beispiel Anmeldedialog enthält formlose Beschreibungen zu verschiedensten Zwecken. Im Aktivitätsblock von +InitLogin wird mit einer allgemeinen formlosen Beschreibung erklärt, welchen Wert das Eingabetextfeld WnLogin.EtUserName erhalten soll. Dieser Wert hätte auch als formlose Wertbeschreibung formuliert sein können.
Im selben Aktivitätsblock werden die Inhalte von WnLogin.EtPasswort.Inhalt und WnLogin.EtPasswort.TxAnzeige auf "" gesetzt, dies bedeutet nicht notwendigerweise, dass nichts in diesen Feldern steht. Es könnte auch ein String wie <nicht gesetzt> oder <bitte ausfüllen> in diese Felder geschrieben werden. "" beschreibt nur den Sinn, nicht den tatsächlichen Inhalt.
Im Aktivitätsblock der Aktion @JetztAnmelden wird überprüft, ob die Anmeldung erfolgreich war. Hier sind die Alternativen notiert als formlose Wertbeschreibungen. Diese sagen nichts darüber aus, welcher Wert in der Implementierung tatsächlich zurückgegeben wird, das Ergebnis wird dem Sinn nach beschrieben..
Innerhalb einer formlosen Beschreibung kann jede beliebige Beschreibungssystematik genutzt werden, egal ob chemisch, mathematisch, grafisch oder eine sonstige an eine Domäne angepasste Beschreibungsmethode. Damit kann Tango die umfassende Struktur eines Dokuments bilden, ohne auf die domänenspezifische Darstellung von Information zu verzichten.
Formlose Beschreibungen spezifizieren die Eigenschaften von Aspekten. Dies genügt, wenn ein Aspekt nur an dieser einen Stelle in der Spezifikation gebraucht wird. Soll ein Aspekt an anderen Stellen der Spezifikation referenziert werden, so ist die Referenz auf diesen Aspekt uneindeutig oder zumindest umständlich, wenn sie sich nur auf die mit diesem Aspekt beschriebenen Eigenschaften stützen kann. Mit einem eindeutigen Namen erhält der Aspekt eine Identität und er kann über diesen Namen zweifelsfrei referenziert werden.
Die Namenssyntax ist in der Tango-Beschreibungssprache nur wenig eingeschränkt, es können alle Zeichenkombinationen verwendet werden, solange sie nicht mit Konstrukten der Tango-Beschreibungssprache verwechselt werden können. Punkte und Leerzeichen können in Namen nicht vorkommen, die Groß- und Kleinschreibung ist distinktiv. Der Gebrauch von Leerzeichen vor und nach Namen ist empfehlenswert, damit Namen und Namensteile von Sprachkonstrukten unterschieden werden. Die freie Namenssyntax erlaubt die Anpassung von Namen an die Notation der jeweiligen Domäne.
Namen werden verwendet, um Pfade zu konstruieren, mit denen Aspekte in der Spezifikation referenziert werden. Mit Pfaden, die ausschließlich aus Namen bestehen, können Aspekte eindeutig referenziert werden. Pfade können außer Namen auch formlose Beschreibungen enthalten, sie wirken dann als Filter. Ein Filter referenziert immer eine Menge von Aspekten, die nur im Sonderfall aus einem einzelnen Aspekt besteht.
Ein Pfad beginnt immer beim Kopfaspekt eines Definitionsblocks. Jeder Schritt entlang einer Teile-Beziehung wird durch einen Punkt vom nächsten getrennt. Ein Pfad kann nicht in einen Aktivitätsblock hinein führen, Aspekte im Aktivitätsblock sind also von außen nicht referenzierbar. Ein Aktivitätsblock ist nur unter gewissen Vorbedingungen relevant, deshalb macht eine derartige Referenz keinen Sinn, ebensowenig eine Referenz auf einen ganzen Aktivitätsblock. Umgekehrt können aus einem Aktivitätsblock heraus Aspekte in der Spezifikation mit einem Pfad referenziert werden.
Ein absoluter Pfad enthält den Kopfaspekt eines Definitionsblocks und den gesamten Weg zum referenzierten Aspekt. Ein relativer Pfad beginnt mit einem Namen, der im gegebenen Kontext eindeutig ist und keinen Kopfaspekt bezeichnet, sodann folgt der Weg zum referenzierten Aspekt. Absolute und relative Pfade sind syntaktisch nicht unterscheidbar.
Spezialisierungsprefix und Markierung |
|
Ein Name gibt einem Aspekt eine Identität, darüber hinaus ist er die Beschreibung des Aspekts. Ein Name sollte deshalb aussagekräftig sein, auch wenn der Aspekt über die Teile-Beziehung weiter beschrieben wird. Mit einem Spezialisierungsprefix kann ein Aspekt in eine von der Domäne vorgegebene Kategorie eingeordnet werden, deren Eigenschaften in der Domäne bekannt sind, so dass sie nicht mehr explizit beschrieben werden müssen.
Die Liste der Spezialisierungsprefixe ist abhängig von der Domäne und wird für jeden Aufgabenbereich unterschiedlich sein. Die Vereinbarung, was unter einem bestimmten Spezialisierungsprefix verstanden werden soll, kann als Schema innerhalb der Tango-Spezifikation notiert werden.
Ein Spezialisierungsprefix ist Teil des Namens eines Aspekts, er ist deshalb distinktiv.
Im Beispiel Anmeldedialog werden Zwei-Buchstaben-Prefixe verwendet, die in Tango-Spezifikationen von Software üblich sind. Der Spezialisierungsprefix Bt kennzeichnet einen Bedienknopf, damit ist klar, in welche Kategorie die Aspekte BtLogin und BtAbbrechen gehören und welche Operationen damit durchgeführt werden können.
Eigenschaften von Aspekten können für die Struktur der Tango-Spezifikation relevant sein. Aspekte mit solchen Eigenschaften können mit einer Markierung versehen werden. Die Markierung ist ein Sonderzeichen vor dem Namen oder der formlosen Beschreibung eines Aspekts. Sie ist nicht Teil des Namens und deshalb nicht distinktiv.
Im Beispiel Anmeldedialog sind alle Aktivatoren mit der Markierung + versehen. An einem Aktivator können Wirkungen ausgelöst werden, deshalb ist die Markierung als Aktivator ein wichtiger strukturierender Hinweis in einer Tango-Spezifikation. Die Aktivatoren WnLogin.BtLogin und WnLogin.BtAbbrechen könnten prinzipiell allein durch den Spezialisierungsprefix als Aktivatoren erkannt werden, am Aspekt WnLogin.EtUserName.CR ist die Markierung ein wichtiger Hinweis, da der terminale Aspekt CR nicht näher beschrieben ist. Würde der Aktivitätsblock fehlen, deutet ohne die Markierung nichts auf die Aktivatoreigenschaft dieses Aspekts, was die Auswertung dieser Tango-Spezifikation erschweren würde.
Markierungen sind Teil der Tango-Beschreibungssprache und deshalb in ihrer Bedeutung festgelegt. Spezialisierungsprefixe sind eine domänenspezifische Namenskonvention und können für den jeweiligen Anwendungszweck angepasst werden.
Terminale und Ellipsen |
|
Eine Tango-Spezifikation beschreibt das Produkt in einem frei wählbaren Detaillierungsgrad. Es gibt deshalb Aspekte, die bewusst nicht mehr näher beschrieben sind. Die Grenzlinie, an der die Detaillierung endet, sollte sichtbar sein, allein schon, um die Vollständigkeit der Spezifikation überprüfen zu können.
Eine Spezifikation wird als vollständig betrachtet, wenn die Beschreibung inhaltlich konsistent ist, wenn z.B. alle Aspekte, auf die referenziert wird, auch tatsächlich vorhanden sind. Eine fehlerhafte Spezifikation liegt vor, wenn syntaktische Regeln der Tango-Beschreibungssprache verletzt sind. Eine Spezifikation kann unvollständig, aber fehlerlos sein.
Terminale Aspekte (Terminale) müssen in der Spezifikation nicht mehr verfeinert werden. Dies wird durch die Art der Niederschrift deutlich gemacht. Eine Verfeinerung solcher Aspekte kann trotzdem stattfinden, aber sie ist nicht notwendig, um die Spezifikation vollständig zu machen.
Alle formlosen Beschreibungen, also die allgemeine formlose Beschreibung und die formlose Wertbeschreibung, sind terminale Aspekte. In diesen Beschreibungen kann alles notiert sein, was über den Aspekt zu sagen ist, deshalb besteht hier prinzipiell keine Notwendigkeit zur Verfeinerung mehr.
Namen in Großbuchstaben werden als Terminale betrachtet. Bei diesen Namen wird angenommen, dass in der Domäne die Bedeutung dieses Aspekts klar ist, z.B. weil dies ein fachspezifischer Ausdruck ist.
Wenn Terminale durch die Teile-Beziehung weiter beschrieben werden, so ist dies eine Zusatzinformation, die zwar relevant, aber nicht notwendig ist. Jeder Unteraspekt eines Terminals, der von einer anderen Stelle der Spezifikation aus referenziert wird, wird als vorhanden vorausgesetzt, selbst wenn das Terminal nicht weiter verfeinert wurde, der Unteraspekt also in der Spezifikation nicht definiert ist.
Die Existenz von terminalen Aspekten selbst wird stillschweigend vorausgesetzt, Terminale müssen also nicht als Unteraspekt eines nicht-terminalen Aspekts explizit notiert sein. Die Referenz auf einen terminalen Unteraspekt kann eine Spezifikation nicht unvollständig machen, selbst wenn dieser Aspekt nicht in der entsprechenden Teile-Beziehung auftaucht.
Im Beispiel Anmeldedialog wird ein terminaler Aspekt WnLogin.CLOSE des Fensters genutzt. Dieses Terminal wurde nicht in den Unteraspekten von WnLogin definiert, es wird als vorhanden vorausgesetzt. In der Domäne ist bekannt, was die Anwendung von CLOSE auf ein Fenster bedeutet, deshalb muss dieses Terminal nicht näher erläutert werden.
Das Terminal WnLogin.EtUserName.CR wird explizit aufgeführt und verfeinert, da die Wirkung dieses Aktivators beschrieben werden soll.
Die Aspekte KannArbeiten und Gesperrt sind keine Terminale, aber mit ihrer bloßen Existenz und den aussagekräftigen Namen ist alles über diese Aspekte gesagt, sie müssen weder verfeinert noch erklärt werden. Sie könnten als Terminale notiert sein, dies ist aber nicht notwendig.
Durch eine Ellipse ... wird gekennzeichnet, dass an dieser Stelle die Spezifikation bewusst lückenhaft ist. Da dies Absicht ist, wird die Spezifikation dadurch nicht unvollständig. Eine Referenz in eine Ellipse hinein ist möglich, denn die Existenz jedes referenzierten Aspekts dahinter wird vorausgesetzt. Eine Ellipse ist dazu gedacht, nicht interessierende Teile einer Spezifikation offen zu lassen, z.B. um sie später zu konkretisieren. Die Referenz in eine Ellipse hinein unterläuft die Prüfung auf Vollständigkeit und sollte deshalb vermieden werden.
Einrücken und Zeilenumbruch |
|
Das Einrücken von Text ist in einer Tango-Spezifikation signifikant, denn dadurch wird eine Teile-Beziehung gekennzeichnet. Mit dem Einrücken beginnt ein Unterblock, und mit dem Ausrücken endet er wieder. Es gibt darüber hinaus keine speziellen Kennzeichner für Anfang oder Ende eines Blocks. Blöcke können tief geschachtelt werden, jeder Block ist gegenüber dem jeweils übergeordneten Aspekt eingerückt.
Innerhalb eines Klammerkonstrukts entsteht durch Einrücken kein neuer Block. Der Inhalt des Klammerkonstrukts wird so weit eingerückt, dass die öffnende Klammer das am weitesten links stehende Zeichen ist. Dies ist eine Konvention, welche die Lesbarkeit verbessert.
Eine neue Zeile bedeutet normalerweise die Beschreibung eines neuen Aspekts. Wenn ein Konstrukt auf einer Zeile erkennbar unvollständig ist, dann werden Zeilen davor und dahinter so zusammengefasst, dass ein sinnvolles Konstrukt entsteht. Dies ist z.B. bei Klammern der Fall, die noch nicht geschlossen sind, aber auch bei binären Sprachelementen, wenn ein Beschreibungsteil fehlt:
!#WnGrußtext // 1
.$Textmerker // 2
.TxWillkommen : // 3
[ "Herzlich Willkommen" | // 4
"Danke für den Besuch" ] // 5
.+BtMerkDirDenText // 6
=> .$Textmerker // 7
:= TxWillkommen // 8
Die Inhaltsbeschreibung von TxWillkommen in Zeile 3 ist erkennbar unvollständig, in Zeile 4 wird die offene Klammer der Auswahlliste noch nicht geschlossen, deshalb werden die Zeilen 3 bis 5 zusammengefasst. Zeile 8 ist ein unvollständiges Wertzuweisungs-Konstrukt, das erst durch Zeile 7 komplett wird, also werden Zeile 7 und 8 zusammengefasst.
Die Einrückung von Folgezeilen, die ein Konstrukt vervollständigen, ist nicht signifikant. Per Konvention werden Folgezeilen deutlich stärker eingerückt als die Zeile, in der das umfassende Konstrukt beginnt.
Eine Zeile kann explizit als unvollständig gekennzeichnet werden, indem als letztes Zeichen ein Backslash geschrieben wird. Damit wird vermieden, dass eine Zeile, die eigentlich ein Konstrukt komplettieren soll, versehentlich als eigenständiges Konstrukt interpretiert werden könnte.