menke's blog vom 14.05.2009

14. Mai '09

"Kleines 1x1 der Architekturdokumentation" von Stefan Zörner bei der Rheinjug

Am Donnerstag, dem 7. Mai, war ich beim Vortrag "Kleines 1x1 der Architektur-Dokumentation" bei der rheinjug in Düsseldorf. Der Vortrag wurde gehalten von Herrn Stefan Zörner, Anwendungsarchitekt bei oose.de

Christian Frei, einer der Organisatoren, der vom 22. bis 25. Juni in Zürich stattfindenden Jazoon, war da, und vergab zu Beginn gleich 3 heißbegehrte Freikarten an aktuelle Geburtstagskinder. Für die restlichen und in großer Schar gekommenen Javauser gab es als Trostpflaster die schweizer Nationalspezialität Schokolade. Die Sprache der "Jazoon", der "International Conference On Java Technology", ist, was den offiziellen Part betrifft, durchgängig Englisch!

Der Vortrag, sehr unterhaltsam und gut nachvollziehbar, begann mit der Darstellung von 5 Punkten bezüglich der Vorgehensweise. Dies erinnerte mich an die 5 Arbeitstage einer Woche:

1. Montag Morgen (... ergäbe ein "Montags-Produkt", wenn nicht ...)
2. Entscheidungen festhalten (Ein Dienst an der Architektur. Das ist der Service.)
3. Sichten auf Architektur (Am Mittwoch den Mittelpunkt bestimmen.)
4. Ziele und Visionen (Da darf man dann auch mal T(h)or sein.)
5. Zusammenfassung, weitere Information (Am Freitag ist man dann so frei.)

Veranschaulicht über einen fiktiven, Fragen stellenden neuen Mitarbeiter:
Wie ist die Software aufgebaut? Was sind die Module? Wo finde ich die Sourcen? Wo die Dokumentation? Und wozu ist dieses und jenes nütze?

Die häufig gehörten Antworten sind dann:

1.	Das war schon so, als ich hier anfing ...
	... und das und ich werden hier auch bleiben. Im Übrigen machen das alle so.
2.	Der Code ist die Dokumentation (Wir gehen agil vor und dokumentieren nicht!)
	Der Code ist immer die Dokumentation!
	Stefan Zörner: Das Agile Manifest - Funktionierende Software vor Dokumentation!
	Man lernt erst Sprechen, dann Schreiben!
3.	Steht alles in der Wiki!
	Wenn es denn so ist!
4.	Das ist historisch gewachsen!
	Ja, und Scharen von Programmierern haben ihre Spuren, Trampelpfaden gleich, in dem Dickicht hinterlassen. Da hat sich die Rationalität ihren Weg gebahnt.

Softwarearchitektur ist die Summe der wichtigen Entscheidungen. Die Anzahl dieser Entscheidungen sollte sich auf 12 bis 14 Entscheidungen beschränken! Diese Architekturentscheidungen sind festzuhalten. Dann gilt es, den Kontext zu bestimmen und, damit einhergehend, die äußeren Einflussfaktoren. Die UML bietet mit den Use-Cases hier den, bzw. einen der richtigen Ansätze.

Mir persönlich, als DV-Kaufmann/Programmierer, ist der Softwareentwurf, also das entworfenene Modell, mehr eine Tür zur Entwicklung der Funktionalität, denn eine Dokumentation des Softwaresystems. Fehler die hier gemacht werden, beeinträchtigen die Funktionalität des ganzen Systems. Schon bei der Granularität des Entwurfs beeinflußt ein Zuwenig oder Zuviel die Änderungsfreundlichkeit erheblich. Es kann nie zu früh sein, die eigene Methodik in Frage zu stellen, im Gegenteil ist dies sogar ein den Entwicklungsprozeß begleitender Akt: Eine stete, fortlaufende Selbstkritik und die Bereitschaft, eine begonnene Entwicklung jederzeit vom Kopf auf die Füße zu stellen.

Stefan Zörner zog vom jeweiligen Kapitel Parallelen in die tägliche Praxis des Entwicklers. Anschaulich, mit Vergleichen zu Mozart, Schwanensee (Tschaikowski) und der Kinderbuchreihe "Was ist was?".

An dieser Stelle möchte ich mir eine Kritik erlauben, die sich auf folgende Stelle in den Folien zum Vortrag bezieht:

Analogie zur Softwarearchitektur: Views (Sichten)
- Es ist sinnvoll, bestimmte Aspekte einer Software mit Bildern statt textuell zu beschreiben
- Ein einzelnes Bild reicht in der Regel nicht aus
-> Unterschiedliche Sichten für unterschiedliche Aspekte

Mein Vorschlag: Unterschiedliche Formalismen für unterschiedliche Aspekte. Welche Eigenschaft wird betrachtet?

Man bediene sich einer Formalisierung, welche die Merkmale dieser Eigenschaft in ihrer Ausprägung betont. Damit wird der Aspekt dokumentiert. Ein Aspekt des Modells.

Denn was ist ein Aspekt anderes als die Absicht, eine bestimmte Eigenschaft zu betonen?

Besteht Einigkeit über den Betrachtungsgegenstand und den Gegenstandsbereich, schreitet die Analyse fort mit der Zerlegung des Betrachtungsgegenstandes. Was für Merkmale? Welcher Ausprägung? Die Sicht wird verfeinert.

Ein Bit ist nichts anderes als die Abstraktion eines schaltungstechnischen Zustandes.
Im Softwaresystem jedoch ist es die konkrete Repräsentation der kleinsten Informationseinheit, und das funktioniert nur mit der entsprechenden Begrifflichkeit. Diese Begrifflichkeit findet ihre Anwendung im Verstand. Haben wir das verstanden? Die Sprache ist hier der Träger der Begrifflichkeit, deren Ausdruck dessen Substanz. Der Ausdruck der Betonung eines Aspektes ist somit sein Formalismus. Ein Begriff wird gebildet, das ist Design.

Das zu dokumentierende System im Kontext eines anderen Ausdrucks. Ein Ausdruck von Rythmus und Harmonie ist die Musik, hier greifen die Noten, ein anderer Ausdruck kann jedoch der Tanz sein und noch ein anderer die Form des Gedichtes. Diese verschiedenen Ausdrücke ein und desselben Sachverhalts, eben des Rhythmus und der Harmonie, bedürfen unterschiedlicher Formalismen für die Beschreibung ihrer Abstraktion, eben des Rhythmus und der Harmonie. Man hört nicht nur einfach einen Rythmus, man hört auch immer einen Ton, man bekommt die Frequenz zu spüren, man empfindet, man fühlt. Die unterschiedlichen Aspekte betreffen deren Phänomen, die Formalismen die Dokumentation. Diese Dokumentation kann zugleich das Modell sein, muß es aber nicht. Ist dem jedoch so, so ist die Formalisierung zugleich wie eine Funktionsvorschrift. Sie dient zur Realisation des Modells. Zur Reproduktion des Modells, da dessen Realisation die Abstraktion beinhaltet.

Betrachtet man das Softwaresystem als musikalisches Werk, so ist die Komposition das Modell. Die Partitur betrifft die Teilsysteme, Besetzung und Instrumentation die Untersysteme. Die Melodie, das Werk, wird instanziert und zum Objekt. Sequenzdiagramme für Einsätze und Tempi. Die einzelne Note (oder Pause) ist in der Ablaufsicht mit ihrer Eigenschaft als Wert vertreten. Harmonien lassen sich mit Aktivitätsdiagrammen visualisieren. Die Use Cases sind die mit dem Schall verbundenen Empfindungen und skaliert man das Ganze, hat man die Fischer Chöre zu Gast. Die elektrotechnische Synthese ergibt einen Synthesizer.

Betrachtet man das Softwaresystem als Mini-Welt, so treffen bei dessen Instanzierung die Aspekte der Hardware und der Software aufeinander und bilden eine Synthese. Die Mini-Welt hat eine Hardware-Komponente, bis hinunter zu den in den Chips verdrahteten Schaltungen und elektrischen Strömen, und eine virtuelle, oder abstrakte Komponente in Form der durch Begriffe gegebenen Funktionalität innerhalb des Systems, in dem das Softwaresystem eingebettet ist. Denn diese Funktionalität ist durch ihre Begrifflichkeit gegeben. Wir haben einen Begriff von dem System, eine Vorstellung(!), und bedienen uns seiner sinngebenden Funktionalität, die sich in der Anwendung des Systems wiederfindet.

Den Vortrag von Stefan Zörner, Anwendungsarchitekt bei oose.de, fand ich abgerundet, durchgängig schlüssig und sehr unterhaltsam obendrein! Es bereitete mir keine Probleme, ihm während des Vortrages zu folgen.

Die Folie zum Vortrag steht noch bei der rheinjug, der Java User Group Düsseldorf, zum Download zu Verfügung!

Stellenweise habe ich persönlichen Anmerkungen, der besseren Ersichtlichkeit wegen, so wie hier zu sehen, abgesetzt. Harald Menke