1) Es gehört zum Domänenwissen, dass die Zahl 20 überall die gleiche Zahl ist, egal wo sie genutzt wird. Alternativ könnte man sich vorstellen, dass zu jeder Zahl ein eigener Definitionsblock besteht, der diese Zahl repräsentiert. Dann ist jede Zahl eine Referenz auf diesen Aspekt. Man könnte diese Überlegung allerdings auch als Haarspalterei bezeichnen. Tango ist eine Beschreibung für Menschen, und nicht für Maschinen wie bei Programmiersprachen, und deshalb sollte der gesunde Menschenverstand beim Lesen vorausgesetzt werden dürfen, der bei Maschinen eher selten zu finden ist..
!$20
!$21
!@Tuwas
=> .$Irgendwo := 20 // Zahl wäre eine Referenz auf den Aspekt im Definitionsblock
2) Die Schreibweise ohne Aufzählungsmarkierung findet sich häufig in Spezifikationen nach früheren Tango-Versionen. Um die eindeutige Interpretation sicherzustellen, wird empfohlen, Aufzählungsmarkierungen großzügiger zu benutzen. In Fällen, in denen die Aufzählungsmarkierung nicht verwendet werden darf, ist die Anwendung entweder sinnlos (Liste, Aktivitätsblock) oder sie führt in eine syntaktische Falle (Bedingung).
3) Die Möglichkeit, den Pfad mit oder ohne Listeneintrag zu schreiben, führt prinzipiell zu einer Mehrdeutigkeit in der Beschreibung. Es könnte terminale Aspekte geben, bei denen nicht klar ist, ob sie Unteraspekte der Einträge sind oder auf die namenlose Liste wirken. Die Eindeutigkeit der Beschreibung sicherzustellen ist Aufgabe des Schreibers, trickreiche Formulierungen sind nicht im Sinne der Tango-Beschreibungssystematik. Eine Spezifikation sollte in erster Linie zügig gelesen werden können, auch ohne tiefschürfende Analyse.
4) Ein Verweis kann auch als Ersatz verwendet werden für das WITH-Statement mancher Programmiersprachen. Der Pfad zu einem Aspekt kann damit zwar nicht weggelassen werden wie beim WITH-Statement, aber er wird abgekürzt geschrieben, was bei häufiger Wiederholung hilfreich sein kann.
5) Die Wirkung auf TxExplain ist in diesem Beispiel mehrfach beschrieben, einmal im Aktivitätsblock zu WnDetail.BtClearItem und nochmals im Aktivitätsblock zu WnOverview.LbItemList.thisItem.CHANGED. Das Prinzip jeder Tango-Beschreibung ist "Was an dieser Stelle passiert, wird an dieser Stelle niedergeschrieben", wie bereits im Kapitel 2 erläutert. Die doppelte Beschreibung der Wirkung kann genutzt werden, um die Konsistenz zu prüfen. Sich auf das implizite Auslösen des CHANGED-Events zu verlassen, wäre zwar guter Programmierstil, aber aus Tango-Sicht suboptimal, da dieser Zusammenhang nicht unmittelbar ersichtlich ist.
6) Die Kennzeichnung jedes Listeneintrags als Aktivator wie in diesem Beispiel ist nicht notwendig, denn auch die Möglichkeit, Items aus der Liste zu wählen, ist Domänenwissen zu Lb___. Ob diese Schreibweise nützlich ist oder jedes Item einfach nur aus dem Anzeigeteil TxTitle bestehen soll, kann von Fall zu Fall entschieden werden.
7) Rückgabewerte werden nicht über die Nutzungshierarchie nach oben durchgereicht, wie dies in Programmiersprachen der Fall wäre. Die Aspekte der Aktion erweitern den nutzenden Aktivitätsblock, diese Definition des Rückgabewertes könnte also eigentlich im Aktivitätsblock zu WnVerzeichnisErstellen.BtAnlegen stehen. Dies würde sich ändern, wenn in diesem Produkt explizit auf einem Rückgabewert von @JetztAnlegen geprüft würde, eine derartige Verzweigung kommt hier aber nicht vor.
8) Es steht dem Implementierer grundsätzlich frei, ob er die angedeutete Reihenfolge beachten will oder nicht, denn die Nutzung einer Aktion ist lediglich ein Erweitern der Liste von Aspekten des nutzenden Aktivitätsblocks. Wenn in der Aktion nicht nur zusätzliche Aspekte oder Verzweigungen, sondern auch Vorgänge beschrieben werden, dann erzwingt die Nutzung von Rückgabewerten die Berücksichtigung der zu Grunde liegenden Kausalität, und dies bewirkt die Synchronisierung, die der Implementierer nicht mehr ignorieren kann.
9) Die eigentliche Information vom MoreInfo ist hier nicht als Unteraspekt aufgeführt, sie steckt im Aspekt MoreInfo selbst. Es wäre aber durchaus möglich, daraus einen zusätzlichen Unteraspekt $Beschreibung unter MoreInfo zu machen.
10) Folgende Formulierung würde das Problem ebenfalls lösen:
!$EineZahl
!+BtSetzeZufallszahl
=> .EineZahl := _IntegerZufallszahl
11) Bei der Erstellung eines Softwaretests mit XUnits wären dies zwei assert-Kommandos:
12) Die Freiheit, auf eine Information zu reagieren, hat der Empfänger selbst dann, wenn die Antwort beim Sender in einer Verzweigung ausgewertet wird. Besteht die Möglichkeit, dass der Sender nicht reagiert, so wäre dieser Fall mit einer Alternative Ich antworte nicht rechtzeitig als Antwort abgedeckt.
13) Die Bedingungskaskade wird in der Praxis häufig als ein Gesamtkonstrukt gesehen, das nur am Anfang eine Aufzählungsmarkierung braucht. Dies kann zwar so formuliert werden, aber dann müssen ab der zweiten Bedingung in der Aufzählung die &-Markierungen um eins weiter links stehen, also in der Spalte des Aufzählungspunkts und nicht in der Spalte des ersten &. Um diese syntaktische Falle zu umgehen, ist der Verzicht auf Aufzählungsmarkierungen vor Bedingungen der sicherste Weg. Das Beispiel mit Aufzählungsmarkierung und korrekter Einrückung wäre:
!+Bekleidungsfrage
=> .&Wetter.SAUKALT
=> .{Handschuhe dabei}
&Straße.GLATT
=> .{Stiefel mit Profil verwenden}
14) Durch diese Notation können in einem Aktivitätsblock mit Aufzählung und Sequenz dieselben Sprachelemente verwendet werden wie sonst in der Spezifikation. Durch den Schritt über den Wirkungspfeil wird deutlich gemacht, dass sich dieser Block mit dynamischen Aspekten der Spezifikation befasst. Ohne die klare Trennung von dynamischen und statischen Beschreibungsteilen wäre eine Spezifikation mit den vorhandenen Beschreibungshilfsmitteln an vielen Stellen nicht mehr eindeutig, was die Einführung spezieller Sprachelemente für dynamische Aufzählungen und Sequenzen nach sich ziehen würde.