1. Gibt es Werkzeuge für Tango?
2. Kann aus Tango eine UML-Beschreibung entstehen?
3. Die Testfälle in ecwin7 sehen nicht aus wie richtiges Tango. Ist die Sprachbeschreibung unvollständig?
4. Ist der lebende Link $boolZustand -> boolZustand2 && boolZustand3 korrekt?
5. Wie beschreibe ich eine Prozedur oder Funktion? Nicht alles ist oder hat ein User Interface.
6. Das Ändern der Spezifikation ist generell unerwünscht. Der Kunde würde sich bedanken, wenn die Beschreibung des Gerätes ständig geändert würde.
7. Warum fehlt die Schleife als Beschreibungshilfsmittel?
8. Ich hätte gerne mehrzeilige Kommentare. Was spricht dagegen?
Meines Wissens nicht. Vor einigen Jahren ist mir zu Ohren gekommen, dass jemand einen Emacs-Modus für Tango schreiben möchte, aber es ist nicht bekannt, wie weit dieser Ansatz entwickelt wurde.
Die Definition von Tango 1.5 ist der erste Schritt, um dieses Problem langfristig zu lösen.
Mit Tango werden Sachverhalte gesammelt, die anschließend in Form einer UML dargestellt werden können.
Die textuell orientierte Arbeitsweise von Tango hat Effizienzvorteile wenn häufige Änderungen notwendig sind, wie in der Requirements-Engineering-Phase üblich (das sagen übrigens auch einige UML-Gurus in Büchern und Workshops mit dem Tenor, man solle nicht zu viel Zeit mit dem Zeichnen von Kästchen und Pfeilchen verschwenden 8^)). Ergebnisse in Form einer grafischen Darstellung können für mehr Übersicht sorgen und damit für andere Mitarbeiter die Einarbeitung in das Thema erleichtern.
Das Zustandsdiagramm der UML 2.0 ist eine besonders geeignete Möglichkeit zur grafischen Darstellung von Tango-notierten Sachverhalten, weil beide Beschreibungen ähnliche Grundlagen haben. Beim Umsetzen der Beschreibung muss beachtet werden, dass mehrere "Tango-Zustände" auf einen einzelnen "UML-Zustand" abgebildet werden. Dies geschieht, z.B. wenn verschiedene Wege zur Bedienung des Produkts zum "selben Zustand" führen. Die Entscheidung, dass dies tatsächlich ein und derselbe Zustand ist, ist eine Design-Entscheidung. Die Tango-Beschreibung verlangt diese Entscheidung noch nicht, in der UML-Darstellung kann dies bereits relevant sein. Die Umsetzung der Tango-Spezifikation in eine UML-Darstellung ist also kein vollständig automatisierbarer Vorgang, sondern ein Prozess, in dem Design-Entscheidungen getroffen werden.
Die Sprachbeschreibung im Referenzdokument ist vollständig. Die Testfälle sind keine Tango-Spezifikation, sie verwenden nur deren Beschreibungsmittel in sehr freier Form. Dies bietet sich an, weil die Grundlage dieser Testfälle eine Tango-Spezifikation war. Tatsächlich ist diese Beschreibung eine Art Pidgin-Tango (genauer: Tango-POD), die nicht standardisiert ist und prinzipiell z.B. durch Pseudo-Basic ersetzt werden könnte.
Nein, die rechte Seite des Verweises ist eine Bedingung, diese taugt nur dazu, zu entscheiden, ob ein nachfolgender Aktivitätsblock relevant ist oder nicht. Hier ist ein Wert oder Status notwendig, also wären Gänsefüßchen eine Alternative:
$boolZustand -> "boolZustand2 && boolZustand3"
Das Innere einer formlosen Wertbeschreibung ist nicht formal festgelegt, die Beschreibung von logisch UND wie hier gezeigt mit && wäre eine Möglichkeit, ebenso wie AND, UND usw.
Die Leistung einer Prozedur/Funktion, also das von außen sichtbare Verhalten, kann mit Tango beschrieben werden. Der interne Ablauf einer Prozedur ist nicht die Domäne von Tango (dass es trotzdem prinzipiell möglich ist, tut hier nichts zur Sache).
Die Tango-gerechte Beschreibung einer Prozedur umfasst die Ursache-Wirkung-Beziehung, dazu bietet sich ein Verzweigungskonstrukt an. Dieses muss in einem Aktivitätsblock stehen. Der Definitionsblock der Prozedur könnte einen Aktivator beschreiben
!+DieseProzedur
was m.E. die beste Lösung wäre. Denkbar ist auch eine Aktion, diese Lösung wurde in älteren Tango-Spezifikationen oft genutzt:
!@DieseProzedur
Fehlerhaft wäre eine Sequenz als Kopfaspekt in einem Definitionsblock:
!-DieseProzedur // !!! FEHLER !!!
Ein Definitionsblock steht für sich allein und kann deshalb keine Kette bilden. Diese früher verwendete Variante zur Beschreibung von Prozeduren ist also methodisch falsch.
Es gibt Spezifikationen, die "eigentlich" unveränderlich sein sollten, speziell Lastenheft und Pflichtenheft. In der Praxis entstehen aus Besprechungen mit dem Kunden Vereinbarungen über Produktleistungen (oder Termine), die im Protokoll festgehalten werden und die dann Teil der Spezifikation werden. Wer an der Produktentwicklung beteiligt ist, muss neben der "unveränderlichen" Spezifikation auch den Inhalt dieser Protokolle berücksichtigen, die Spezifikation hat sich also de Facto geändert.
Eine Tango-Spezifikation soll den gesamten Prozess der Produkterstellung begleiten, dazu muss sie aktuell sein und deshalb angepasst werden können. Sie ist prinzipiell veränderlich, und wenn eine bestimmte Version als "eingefroren" betrachtet werden soll, dann ist dies eine Aufgabe des Änderungsmanagements.
Nicht jede Änderung in der Tango-Spezifikation muss für den Kunden sichtbar sein. Die an den Kunden übergebene formlose Spezifikation könnte unschärfer sein als die im Projektverlauf präzisierte Tango-Spezifikation, in diesem Fall sind Änderungen innerhalb der Unschärfe nur für die Entwickler sichtbar, nicht für den Kunden.
Weil die Schleife ein Programmkonstrukt ist, und kein Bedienkonstrukt, und Tango beschreibt keinen Programmablauf, sondern einen Bedienungsablauf.
Dies ist der älteste und häufigste Diskussionspunkt rund um Tango, und er ist besonders nützlich, um die grundlegend unterschiedliche Sichtweise zwischen Programmierung und Tango-Spezifikation aufzuzeigen. Deshalb eine ausführliche Erläuterung an dieser Stelle:
Angenommen, jemand spielt Tetris. Er spielt zwei Stunden lang und schafft 20 Partien. Die Spielerei endet, wenn der Spieler keine Lust mehr hat, weiterzuspielen (oder weil der Chef sagt, er soll das lassen, das wäre ein non-local exit und wird hier nicht betrachtet).
Ein Programm, das diese Situation nachbildet, würde eine Schleife enthalten:
do until keineLustMehr
TetrisSpielen
Der Ablauf wird damit korrekt abgebildet, das Endekriterium keineLustMehr schlägt nach zwei Stunden zu. Aus Programmierersicht ist alles Bestens.
Aus Sicht des Spielers ist diese Beschreibung unkorrekt, denn hier wird impliziert, dass der Spieler in einer Schleife gefangen ist, und die Türe geht erst auf, wenn das Endekriterium erreicht ist. Tatsächlich entscheidet sich der Spieler aber nach jeder Partie, ob er noch eine weitere spielen will. Der Wiedereinstieg in ein neues Spiel ist eine explizite Entscheidung des Spielers. Selbst wenn diese Entscheidung von Spielsucht geprägt sein sollte, ändert sich daran prinzipiell nichts. Die korrekte Beschreibung aus Sicht des Spielers (also des Bedieners) ist wie folgt:
!+TetrisSpielen
.{kann mittendrin unterbrochen werden}
+NochEinePartie
=> .*TetrisSpielen
+GenugGespielt
=> ?TetrisLäuft =
= "Ja, läuft noch"
=> .@ABBRECHEN
= "Nein, Spiel ist beendet"
=> .@NOP
Die Schleife entsteht durch eine explizite Entscheidung des Spielers, deshalb ist zur Beschreibung ein Schleifenkonstrukt weder notwendig noch hilfreich.
Das Fehlen mehrzeiliger Kommentare hat sich als Lücke erwiesen. Dies führt u.a. dazu, dass kreative Anwender vorhandene Konstrukte missbrauchen, um solche Kommentare zu simulieren, was der Klarheit der Beschreibung nicht förderlich ist.
Aus diesem Grunde wird in der nächsten Überarbeitung der Sprache ein durch /* und */ begrenzter Kommentar eingeführt. Zu der Frage, ob die Anwendung dem Muster der Gänsefüßchen folgt (formlosen Wertbeschreibung: das erste Endezeichen beendet den Kommentar) oder dem Muster der geschweiften Klammern (allgemeine formlose Beschreibung: gleiche Anzahl öffnender und schließender Klammern gefordert) ist noch nicht entschieden.
Der ursprüngliche Gedanke war, dass der Leser an jeder Stelle erkennen soll, ob er sich in einem relevanten Teil der Spezifikation befindet, oder in einem Kommentar. Ein Kommentarzeichen vor jeder Zeile hätte dieses Problem gelöst. Die Praxis zeigt, dass dieses Ziel nicht erreicht werden kann. Die Markierung von Zeilen als Kommentar muss dem darstellenden Gerät überlassen werden. Angesichts der langfristigen Speicherung von Tango-Spezifikationen im XML-Format betrifft dieses Problem ohnehin nur die Anzeige, nicht die Daten der Spezifikation.