Category

Kolumne

The Big Picture — Mit Entscheidern kommunizieren

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 12: The Big Picture — Mit Entscheidern kommunizieren

Logo_Kolumne_JavaMagazinRan ans Whiteboard, und erklärt! Als Softwarearchitekt kommunizieren Sie Ihre Konzepte und Endscheidungen im Entwicklungsteam. Für die meisten von uns stellt dies keine große Hürde dar. Denn Architekten sollten zuvor selbst lange als Entwickler oder Spezialist in Projekten gearbeitet haben. Oft nehmen sie ohnehin eine Doppelrolle wahr. Erfahrungshorizont und Sprache der Beteiligten liegen nahe beieinander. Was nicht heißen soll, dass es hier nicht zu Konflikten kommen kann. Aber zumindest die Wellenlänge stimmt meist überein.

Nun sind Entwickler aber nicht die einzigen, mit denen sich Architekten über das gemeinsame Vorhaben austauschen. Die Projektleitung ist an Ressourcenverbrauch und Risiken interessiert, auch Kunden und Auftraggeber wollen über den Projektfortschritt auf dem Laufenden gehalten werden, und ab und an was vorgeführt bekommen. Kommunikationsfähigkeiten sind zentrale Erfolgsfaktoren für einen Architekten [1]. Insbesondere muss er seine Ideen zielgruppenorientiert vermitteln können; er hat es mit sehr unterschiedlichen Empfängern zu tun. Zu den Kommunikationspartnern zählen regelmäßig auch Personen aus dem Management, sei es auf Seiten der Kunden und Auftraggeber, oder auch in Form eigener Vorgesetzter. Diese Leute entscheiden mitunter über die Zukunft Ihres Projektes. Effektiv auch mit dieser Zielgruppe kommunizieren zu können ist entscheidend!

„Wo sind denn auf dem Bild unsere Kunden?“ – Haben Sie schon einmal Entscheidern anhand bestehender Dokumentation die Architektur Ihres Systems erklärt? Versuch einer Antwort: „Kunden greifen vom PC per Browser auf unser System zu, die sind hier nicht mit drauf. Nur unsere Webserver sind drauf.“ Worauf hin der Entscheider denkt: „Tolle Bilder malen die, nicht mal unsere Kunden sind drauf.“ und Sie fragen sich vielleicht: „Weiss der überhaupt, was ein Browser ist?“ [2].
Entscheider lesen nicht das Java Magazin, sondern die Computerwoche („7 Spartipps fürs Rechenzentrum“). Sie operieren auf einem völlig anderen Abstraktionsniveau als wir. Entscheider versuchen vor allem betriebswirtschaftliche Anforderungen zu erfüllen. Dabei geht es um ein vernetztes Denken in den Zusammenhängen der ganzen Firma oder sogar eines Konzerns. Entscheider entwickeln Visionen und Strategien für die Zukunft. Sie verstehen nicht unmittelbar, warum OSGi eine tolle Sache ist. Stattdessen rechnen sie gerade, die gesamte IT mit Hilfe von SAP zu harmonisieren, oder die Individualentwicklung nach Tschechien auszulagern.

Konsequenterweise sind meisten in dieser Kolumne vorgestellten Arbeitsergebnisse der Architekturdokumentation, insbesondere die unterschiedlichen Sichten notiert in UML, nicht entscheiderkompatibel. Nicht notwendiger Weise deshalb, weil sie nicht verstanden werden (was zwar meist der Fall ist), sondern weil die Implikationen auf die betriebswirtschaftlichen Aspekte nicht zu erkennen sind.

Was nicht heißt, dass man für diese Zielgruppe nicht auch mit Abbildungen arbeiten kann, um zu vermitteln, was auf neudeutsch so schön „The Big Picture“ heißt. Nur muss die Argumentation anders ansetzen. Und ein (lediglich unterstützendes) managementtaugliches Bild sieht ebenfalls anders aus: Informelle Notation, viel Symbolik, sinnvoll eingesetzte Farben. Ansprechend im wahrsten Sinne des Wortes. Eine gemeinsame „Big Picture“-Abbildung eignet sich darüber hinaus, früh ein einheitliches Bild vom System im Team zu etablieren. Es besteht hier allerdings die Gefahr, dass es das einzige Bild bleibt, keine Architektursichten erstellt werden, und immer mehr Aspekte in der Abbildung vermischt werden. Trennen Sie es daher klar von Bausteinsicht, Kontextsicht, Laufzeitsicht usw. Es ist im Grunde eine weitere Sicht. Nennen Sie sie z.B. „Architekturüberblick“. Anders als bei den anderen Sichten ist die UML hier keine geeignete Notation. Es spricht nichts dagegen, einen Architekturüberblick frei von Hand zu zeichnen, wie das Beispiel von Scott Ambler in Abbildung 1 zeigt (Quelle: [3]). PowerPoint oder Visio sprechen Entscheider in der Regel mehr an, und es ist bei elektronischen Diagrammen leichter eine Änderung oder Ergänzung möglich. Da das Abstraktionsniveau eines Architekturüberblicks sehr hoch ist, sollte dies jedoch selten nötig sein. Es ist daher kein Drama, die Abbildung nicht in einem Modell mit den übrigen Artefakten zu halten. Nichts desto trotz sollte der Überblick natürlich konsistent zu den anderen Sichten sein. Ansonsten stiftet er schnell Verwirrung, oder wird im Entwicklerteam nicht ernst genommen.

Abb. 1: Beispiel für einen Architekturüberblick von Scott W. Ambler

Abb. 1: Beispiel für einen Architekturüberblick von Scott W. Ambler

 

Der Architekturüberblick unterstützt bei der Kommunikation ähnlich wie Produktkarton und Systemidee [4]. Gut gemacht ist er exzellent geeignet, neue Teammitglieder ins Boot zu holen, Sponsoren zu informieren, oder Bedenkenträger zu überzeugen. Oder auch einem Manager einen groben Überblick darüber geben, was für ein System Ihr Team gerade baut. Der Architekturüberblick ist ein wichtiger Baustein des Projektmarketings, er wird in jedem mit dem Vorhaben verbundenen Powerpoint-Foliensatz auftauchen.

Zurück in den Lenkungsausschuss. Folie zur Ist-Situation. „Oh, da sind ja unsere Kunden. Und da ist der Host. Die Host-Wartungsverträge laufen aus. Eine Verlängerung bindet uns weitere 5 Jahre …“. Dem Entscheider gelingt eine Einordnung Ihres Vorhabens in seinen Kontext. Hier können Sie anknüpfen: „In der Zeit gehen 8 der 13 Host-Entwickler in Rente. Der Markt gibt keine neuen Arbeitskräfte für diese alte Technologie her. Obwohl die Wartungskosten derzeit für das Host-System extrem niedrig sind, gilt es jetzt die Weichen neu zu stellen, damit dies in 3 Jahren auch noch der Fall ist. Ich schlage daher folgende Migrationsstrategie vor, …“. Nächste Folie. Ihr neuer Architekturüberblick. Sie haben Vertrauen gewonnen, und vielleicht auch Unterstützer.

Links & Literatur

[1] U. Vigenschow, Björn Schneider, „Soft Skills für Software-Entwickler“, Dpunkt 2007
[2] “Browser — Was sind denn jetzt noch mal Browser?”, http://netzpolitik.org/2007/kinderreporter-fragen-politiker-nach-dem-internet/
[3] S. Ambler, „Agile Modeling“, http://www.agilemodeling.com
[4] S. Zörner, “Out of the box. Produktkartons”, Java Magazin 7/2009

 

javamagazin_09_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„The Big Picture — Mit Entscheidern kommunizieren“, Java Magazin, 09/2009, 2 Seiten, S. 78

(mit freundlicher Genehmigung)

 

Tartan-Architektur — Muster dokumentieren

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 11: Tartan-Architektur — Muster dokumentieren

Logo_Kolumne_JavaMagazinWas macht ein Schotte mit einer Kerze vor dem Spiegel? Er feiert den 2. Advent! Zu den Dingen, die jeder sofort mit Schottland in Verbindung bringt, gehören neben der angeblichen Sparsamkeit natürlich die bunt gewebten Karos [1]. Fraser, MacLeod, Campbell … – Jeder Clan hat seine eigenen Farben; Familien- oder Regimentszugehörigkeit wird durch das Tragen des gleichen Tartans signalisiert. Wer das Muster kennt, sieht sofort: Das ist ein MacDonald!

Auch in der Softwareentwicklung sind Muster (neudeutsch Pattern) sehr verbreitet; wir finden sie auf vielen Ebenen. Es gibt Analyse-, Architektur- und Entwurfsmuster, um nur einige Kategorien zu nennen. Gerade letztere (Design Patterns) haben einen hohen Bekanntheitsgrad und zählen zum Rüstzeug eines jeden, der objektorientierte Software entwirft. Mit Ihnen lassen sich nicht nur – falls angemessen – gute Lösungen reproduzieren. Die Kernidee der Lösung lässt sich mit dem Namen des Musters auch sehr effizient kommunizieren. Das setzt allerdings voraus, dass der Kommunikationspartner das Muster kennt. Aber auch dann sieht man im Klassendiagramm nicht sofort: Das ist ein Decorator! Unsere Entwürfe tragen keine Karos. Wie dokumentiert man also die Verwendung eines Softwaremusters?

Entwurfmuster werden auf der Ebene von Klassen und Schnittstellen eingesetzt. Die Dokumentation sollte eben dort erfolgen, und die einfachste Art, den Einsatz eines Musters gut kenntlich zu machen, ist ihn im Namen der Modellelemente zu verankern. Diese Technik ist auch bei der Benamsung in der Biologie sehr verbreitet. Was unterscheidet ein Hauspferd von einem Zebra? Klar, vor allem das einprägsame Muster. Was liegt also näher, als ein Merkmal, mit dem man eine Art erkennen kann, gleich im Namen zu benutzen? Die Tüpfelhyäne hat im Gegensatz zur Streifenhyäne Tüpfel, das Streifenhörnchen ebenfalls Streifen (wie das Zebra, das besser Streifenpferd heißen sollte). Auch wer noch nie einen Blaupunktrochen gesehen hatte – der Name transportiert bereits Information über das markante Äußere – man hat eine grobe Vorstellung. Teilweise werden auch Verhaltensmuster eingesetzt – besonders schön: Rückenschwimmender Kongowels. Die Verwendung von Mustern in Namen setzt auf den hohen Wiedererkennungswert, den diese haben.

Unter Ausnutzung des selben Effektes ist es bei einigen Entwurfsmustern ebenfalls hilfreich und auch sehr üblich, sie als Bestandteil im Namen beteiligter Klassen zu verwenden. Die Java-Klassenbibliothek zum Beispiel enthält nicht umsonst ca. 100 Elemente mit der Endung „Factory“. Auch bei Klassen wie DocumentBuilder (aus javax.xml.parsers) oder WebSphereDataSourceAdapter aus dem Spring Framework wird im Namen der Gebrauch eines Patterns angezeigt.

Das Benamsen mit Musteranteil ist nicht immer angebracht, und auch nicht immer so leicht möglich. Bei etwas umfangreicheren Mustern etwa spielen viele beteiligte Klassen mit, und nehmen unterschiedliche Rollen ein. Ab und an werden Muster in einem Entwurf kombiniert.

Für Entwurfsmuster bietet die UML eine reizvolle Möglichkeit, das Zusammenspiel von Klassen in Form eines Musters durch spezielle Modellelemente darzustellen. Zunächst wird das Muster als sogenannte Collaboration eingeführt, anschließend kann dessen Vorkommen (Collaboration Occurrence) im Entwurf verankert werden. Abbildung 1 zeigt als Ausschnitt eines Entwurfes ein entsprechendes Klassendiagramm. Die Musterverwendung wird als Ellipse dargestellt, und mit den beteiligten Klassen verbunden. An die Linien sind die Rollennamen, wie sie im Muster eingeführt wurden, notiert. Das Dokumentieren des Einsatzes von Entwurfsmustern lässt sich damit prima bewerkstelligen.

Abb. 1: Kennzeichnen des Einsatzes von Mustern in der UML2

Abb. 1: Kennzeichnen des Einsatzes von Mustern in der UML2

Wie sieht es bei der Verwendung von Mustern anderer Kategorien oder Abstraktionslevel aus, vor allem bei Architekturmustern? Generell sollten Sie den Gebrauch eines Musters auf der Ebene dokumentieren, auf der es wirkt. Die Mittel dazu sind die gleichen wie bei Entwurfsmustern. Bei der Bildung von Schichten [2] kennt jeder die Benutzung des Namensteils „Layer“, etwa bei Persistence Layer. Auch andere Architekturmuster sind beliebte Namensgeber, wie Interceptor [3] oder Broker [2]. Und auch hier können Sie in entsprechenden Diagrammen die Verwendung analog zu den Entwurfsmustern „taggen“. Da Architekturmuster strukturbildend für das Gesamtsystem sind, macht es Sinn ihren Einsatz zu dokumentieren und im Team geeignet zu kommunizieren. Oft erfolgt dies in Form einer Architekturentscheidung [4]; die Verwendung spiegelt sich auch in den Sichten wider, allen voran in der Bausteinsicht.

Denn was passiert, wenn der Einsatz eines Architekturmusters nicht dokumentiert wird? Oder besser: Welche Gefahren birgt es, wenn die Verwendung nicht im Team bekannt ist? Zunächst einmal vergeben Sie die Chance, dass sich die Architektur Dritten rasch erschließt. Vor allem aber könnten Teammitglieder oder später Wartungskräfte aus Unkenntnis gegen die Architektur verstoßen. Die ursprüngliche Intention und Konsistenz geht dann verloren, und das System endet als Flickenteppich. Von „Es kann nur einen (Entwurf) geben“ keine Spur.

Links & Literatur

[1] Tartans of Scotland, http://www.tartans.scotland.net
[2] Buschmann et al., „Pattern-Oriented Software Architecture 1“, Wiley & Sons, 1996
[3] Buschmann et al., „Pattern-Oriented Software Architecture 2“, Wiley & Sons, 2000
[4] S. Zörner, “Historisch gewachsen? – Entscheidungen festhalten”, Java Magazin 4/2009

 

javamagazin_08_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Tartan-Architektur — Muster dokumentieren“, Java Magazin, 08/2009, 2 Seiten, S. 69

(mit freundlicher Genehmigung)

 

 

Out of the Box — Produktkartons

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 10: Out of the Box — Produktkartons

Logo_Kolumne_JavaMagazinDie Älteren unter uns werden sich noch erinnern: Früher kaufte man Software im Laden in einem Karton. In dem befanden sich dann Disketten (siehe [1]), später CDs mit der zu installierenden Software. Heute wird kommerzielle Software in der Regel in Online Shops erworben, und heruntergeladen. Die Anbieter sichern sich mit Lizenzschlüsseln gegen eine unerwünschte Verbreitung ab. Nur Computerspiele, insbesondere solche für Konsolen, werden heute noch in nennenswertem Umfang in Schachteln verkauft.

Doch die Schachteln leben weiter: Auf einer Vielzahl von Webseiten finden sich virtuelle Produktkartons. Als Beispiel zeigt Abbildung 1 die Homepage von Apache ActiveMQ [2]. Als Open Source Middleware ist es ein besonders interessanter Vertreter, da man diese Software gar nicht käuflich erwerben kann, und sie als Software-Infrastruktur-Komponente für Außenstehende auch schwer zu begreifen ist (es gibt nichts zu klicken). Durch den Karton bekommt die Lösung trotzdem etwas Gegenständliches, sie erscheint fassbarer.

Abb. 1: Produktkarton auf der Homepage von Apache ActiveMQ

Abb. 1: Produktkarton auf der Homepage von Apache ActiveMQ

Wozu benötigen wir in der Softwareentwicklung etwas zum Anfassen? Das machen wir doch sonst auch nicht! Projektteams brauchen ein gemeinsames Ziel, eine Vision. Was entwickeln wir eigentlich? Was ist die Idee des Systems? Wem nützt es? Wie unterscheidet es sich von Produkten der Mitbewerber? Ich habe reichlich Projekte erlebt, wo einzelne Entwickler diese Fragen nicht, oder nur unklar beantworten konnten. Sie kannten ihren begrenzten Bereich, hatten aber keinen Blick für das große Ganze. Das kann frustrierend wirken, und verhindernd häufig auch innovative Lösungsideen. Es ist eine Ihrer Aufgaben als Softwarearchitekt, die Idee des Systems im Team zu verankern.

ActiveMQ macht es mit seiner Homepage vor. Gleich neben der Kiste entdecken Sie kurz und knapp umrissen, was die Software eigentlich leistet. Die Kartonmetapher funktioniert dabei in mehrerer Hinsicht. Ein echter Produktkarton ist nicht nur hübsch anzusehen (er soll im Regal Aufmerksamkeit erregen; der Interessent soll zu genau diesem Produkt greifen und nicht zu dem der Konkurrenz). Nimmt man ihn in die Hand, findet man die wichtigsten Fakten aufgedruckt: Leistungsmerkmale, Systemvoraussetzungen, besondere Features. Der Produktkarton hilft daher auch bei der Priorisierung von Anforderungen. Was es auf den Karton schafft, hat höchste, alles andere mittlere oder geringe Priorität. Da der Platz dort begrenzt ist, muss sein Inhalt verändert werden, wenn sich die Inhalte in den hohen Prioritäten verändern. Etwas altes muss weichen, damit ein neues hochpriorisiertes Feature auf dem Karton Platz findet. Ist die Systemidee in dieser Form fixiert, können Sie über die auch Monate beobachten, ob Ihr Projekt seine ursprünglichen Ziele überhaupt noch verfolgt.

Ein entsprechendes Arbeitsergebnis sollte jedes Projekt erstellen, zumindest textuell (Ziel: maximal eine DIN A4-Seite, 5-20 Sätze). Manche Teams bannen die Inhalte sogar auf einen echten Karton, und stellen ihn gut sichtbar im Projektzimmer auf. Für neue Teammitglieder haben Sie dann sofort etwas griffiges in der Hand, um sie auf das gemeinsame Ziel einzuschwören.

In weniger bastelfreudigen und vor allem in verteilten Teams ist das Platzieren auf der Startseite des Projektwikis ein guter Plan. Bei ActiveMQ z.B. wird die Systemidee auch nach außen getragen („Mission Statement“); sie dient nicht zuletzt auch dem (Projekt-) Marketing und dem Rekrutieren neuer Entwickler. Unterhalb der Kartongraphik finden Sie auf der Startseite die beeindruckende Featureliste. Man merkt: Diese Software erfüllt die Entwickler mit Stolz.
Die Systemidee (repräsentiert durch den Produktkarton) ist eine interessante Ergänzung zum Systemkontext [3]. Während letzterer sich darauf konzentriert, in welcher Umgebung das System eingebunden ist, mit welchen Nutzern und Fremdsystemen es interagiert – kurz abgrenzt, was draußen ist, erlaubt die Systemidee einen ersten Blick in das System. Sie hilft wie der Systemkontext dabei, den Umfang abzustecken. Deshalb sollten beide Arbeitsergebnisse sehr früh im Projektverlauf entstehen.

Man kann darüber streiten, ob es tatsächlich Ihre Aufgabe als Softwarearchitekt ist, die Systemidee zu formulieren, oder ob das nicht eher im Verantwortungsbereich eines Product Owners steht. Für mich steht aber außer Frage, dass es ein entsprechendes Arbeitsergebnis in jedem Projekt geben sollte. Und wenn Sie sich bei dieser für das Team identitätsstiftenden Maßnahme eines virtuellen Produktkartons bedienen wollen, um Ihre Projektseite damit zu zieren: Nur zu! Anleitungen zu dem Thema finden Sie zu Genüge im Netz (z.B. [4]). Wichtiger ist allerdings der beschreibende Text auf den Seiten der Kiste: Was steckt drin?

Links & Literatur

[1] Deutsches Museum, http://www.deutsches-museum.de
[2] Apache ActiveMQ, http://activemq.apache.org
[3] S. Zörner, „Kombiniere – der Systemkontext“, Java Magazin 11.2008
[4] „How to Create a Product Box in Photoshop”, http://www.wikihow.com/Create-a-Product-Box-in-Photoshop

 

javamagazin_07_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Out of the Box — Produktkartons“, Java Magazin, 07/2009, 2 Seiten, S. 90

(mit freundlicher Genehmigung)

 

Für die Ewigkeit? Die Tonne? Oder etwas dazwischen?

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 8: Für die Ewigkeit? Die Tonne? Oder etwas dazwischen?

Logo_Kolumne_JavaMagazinMein Vater hat unlängst die ursprünglich auf Zelluloid gebannten Kindheitserinnerungen seiner Sprösslinge („Stefan lernt laufen“ etc.) auf DVD gesichert. Vor ein paar Jahren hatte er bereits die original Super 8-Stummfilme mit einer Videokamera von einer Leinwand abgefilmt. Die VHS-Bänder dienten nun als Quelle für die DVD. Technologie veraltet; wer Dokumentiertes dauerhaft bewahren will, muss sich damit auseinander setzen, dass auch zukünftige Interessierte die Sachen verwenden können.

Drohen Ihrer Architekturdokumentation ebenfalls technische Umwälzungen? Architektur entsteht zu großen Teilen früh im Projekt. Die Dokumentation dazu beginnt im Idealfall gleichzeitig, die Ergebnisse (Sichten, Modelle, dokumentierte Entscheidungen) begleiten die Softwarelösung vom Laufen lernen durch die Entwicklungsiterationen bis in Betrieb und Wartung hinein. Auch sie sind der Gefahr ausgesetzt, irgendwann nicht mehr verwendet werden zu können. Aber das kann sehr unterschiedliche Ursachen haben – selten technische.

Variante 1: „Nicht mehr aufzufinden“. Beispiel: Architektur wird im Rahmen von gemeinsamen Designmeetings und –workshops entworfen, die Ergebnissicherung in Form von Fotoprotokollen (Flipcharts, Whiteboards) oder direkt erstellten Dateien erfolgt aber nicht nachhaltig. „Wo ist eigentlich die tolle Graphik, die wir Anfang des Monats mit diesem Mindmapping-Werkzeug gemeinsam am Beamer erstellt haben?“ – „Ich glaube, die hatte Uwe lokal auf seinem Notebook gespeichert.“

Variante 2: „Nicht mehr zu entziffern“. Schon viele Ergebnisse wurden nicht weiterverwendet, weil die Tools, mit denen sie ursprünglich erstellt wurden, nicht mehr, oder zumindest nicht in der geforderten Version zur Verfügung standen. „Ich würde gern UML-Diagramme in der Dokumentation aktualisieren. Mit was für einem Tool sind die gemalt worden? Die Dateiendung kenne ich gar nicht.“ – „Da hatten wir damals ’ne Eval von.“

Physische Verlustrisiken sind beherrschbar. Und bei der Wahl der verwendeten Werkzeuge wird in der Regel auch weiter geschaut als 30 Tage. Die interessanteste Ursache ist Variante 3: „Nicht mehr aktuell“. Neue Teammitglieder stoßen bei der Einarbeitung gern auf solche Artefakte. „Ich habe eine Frage zu Eurem Dokument hier: Die dargestellte Zerlegung finde ich in der aktuellen Software so überhaupt nicht wieder.“ – „Wo hast Du das denn ausgegraben? Das pflegen wir seit der Völkerwanderung nicht mehr!“.

Wie können Sie Ihre Architekturdokumentation vor diesem Effekt schützen? Weniger ist oft mehr. Konzentrieren Sie sich auf das Wesentliche, und wählen Sie auch bewusst Sichten auf Ihre Lösung aus, die Sie berechtigt weglassen, bzw. schlank halten können.

Weiterhin hat eine gute Dokumentation wenn man mag selbst eine Architektur. Das Entwurfsprinzip, Stabiles von Instabilem zu trennen, lässt sich auch auf die Strukturierung von Architekturdokumentation wunderbar anwenden. Es kann helfen, Pflegeaufwände zu reduzieren. Auch das Zusammenspiel von Stabilität und Abstraktion kann positive Wirkung entfalten. Wenn Sie in bestimmten Teilen Stabilität anstreben, dokumentieren Sie Abstraktionen, nicht Entwürfe auf gleichem Detaillierungsgrad wie der Quelltext.

Es ist nichts Falsches daran zu entscheiden, Teile der Architekturdokumentation im Verlauf des Projektes nicht mehr zu aktualisieren, wenn der Pflegeaufwand in keinem Verhältnis mehr zum Nutzen steht. Nur sollte dies dann klar im Team kommuniziert und die Teile als solche gekennzeichnet werden, z.B. als „historisches Zeugnis“. Als attraktivere Alternative dazu ist jetzt vielleicht der Zeitpunkt gekommen, Details wegzulassen, statt sie immer wieder anzupassen, die Dokumentation so zu verdichten, und auf Abstraktionen zu reduzieren. Um auf diese Weise zu Prägnanz und Stabilität zu kommen.

Mein Vater hatte bei seinen Überspielungen nicht alle Super 8-Filme auf Video übernommen, und auch nicht alle VHS-Bänder auf DVD überführt. Er hat ausgewählt und ausgeklammert, und für den Empfänger der Dokumentation (mich) so einen Mehrwert geschaffen. Das Ergebnis ist leichter zu konsumieren und präsentieren, und erfüllt damit seinen Zweck.

javamagazin_05_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Historisch gewachsen? – Entscheidungen festhalten“, Java Magazin, 05/2009, 1 Seite, S. 83

(mit freundlicher Genehmigung)

 

Historisch gewachsen? – Entscheidungen festhalten

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 7: Historisch gewachsen? – Entscheidungen festhalten

Logo_Kolumne_JavaMagazin1815 – Europa in Aufregung. Napoleon erlebt bei Waterloo ebendieses – er verliert seine letzte Schlacht. Mittlerweile haben Historiker reichlich Papier veröffentlicht, um die Gefechtsgeschehnisse zu dokumentieren und zu bewerten. Sie sind sich nicht in allen Punkten einig. Die Entscheidungen des Kaisers der Franzosen sind zwar in Form seiner Befehle überliefert, nicht immer ist aber klar, welche Alternativen er zuvor gegeneinander abgewogen hat, und warum er sich für eine bestimmte Option entschied. In einzelnen Punkten vermuten Geschichtsschreiber Fehler in Napoleons Handeln entdeckt zu haben. Sie können aber nur spekulieren, ob er sie aus Unwissenheit beging, oder ob eine Absicht dahinter stand, die sie nicht kennen.

Entscheidungen zu treffen ist die zentrale Aufgabe im Softwareentwurf. Es gibt zwar keine allgemein anerkannte Definition des Architekturbegriffs, aber eine sehr prominente [1] charakterisiert Softwarearchitektur als „Summe signifikanter Entscheidungen […]“. Architekturentscheidungen, also solche, die im weiteren Verlauf nur schwer zurückzunehmen sind, geben den Rahmen für die Lösung vor. Sie sind ein zentrales Arbeitsergebnis – Architektur erfolgreich umzusetzen heißt vor allem, sie im Team zu kommunizieren. Darüber hinaus sollten Sie Architekturentscheidungen geeignet dokumentieren.

Warum eigentlich? Damit spätere Geschichtsschreiber Ihr Projekt leichter erforschen können? So lange brauchen Sie in der Regel nicht warten. Schon der erste neue Mitarbeiter im Team wird viele Fragen stellen, die auf zentrale Entscheidungen abzielen. „Warum habt Ihr das denn mit X-Framework gemacht? Y-Framework ist doch viel besser!“ Nicht jeder im Team wird sich vielleicht noch erinnern können, was damals für X-Framework sprach. Gerade in wachsenden Projekten, die häufig neue Mitarbeiter integrieren, kommt es zu den immer wieder gleichen Debatten, die leicht vermieden oder zumindest abgekürzt werden können. Neben der Wissensvermittlung und –erhaltung im Team sind dokumentierte Entscheidungen auch für Architekturbewertungen und Reviewes unerlässlich.

Abb. 1: Mögliche Struktur einer Architekturentscheidung

Abb. 1: Mögliche Struktur einer Architekturentscheidung

Was genau sollte festgehalten werden? Und in welcher Form? In der Praxis haben sich einfache Templates bewährt, die für jede relevante Entscheidung die gleichen Dinge abfragen. Abbildung 1 zeigt eine Mindmap mit Fragen, die Sie bei einer konkreten Architekturentscheidung, etwa in einem Workshop, leiten und unterstützen können. Die nummerierten Hauptäste eignen sich als Kapitelüberschriften einer Vorlage. Wichtig ist neben der Darstellung der Fragestellung auch, warum die Sache relevant genug ist, um sie in den Rang einer Architekturentscheidung zu erheben. Stets enthalten sein sollte natürlich die Entscheidung selbst und die Information, wann sie mit welcher Begründung getroffen wurde.

Das „wann“ wird ab und an vergessen, dabei ist es sehr wichtig. Denn zum einen macht es Sinn, Entscheidungen in ihrer chronologischen Abfolge zu betrachten. Oft beeinflusst die Wahl einer Alternative die möglichen Optionen nachfolgender Entscheidungen. Wenn sich z.B. für die Bevorzugung standardisierter APIs in einer Java-Architektur entschieden wurde, macht es später wenig Sinn, proprietäre Persistenzframeworks in die engere Wahl zu ziehen. Auch in anderen Situationen erklärt der Zeitpunkt der Entscheidung, warum bestimmte Optionen überhaupt nicht in Betracht gezogen wurden, auch wenn sie scheinbar besser passen. Vielleicht gab es Y-Framework zum Zeitpunkt der Entscheidung noch gar nicht.

Architekturentscheidungen haben in der Regel weitreichende Auswirkungen auf die Entwicklung. Jeder im Team sollte sie kennen. Ein verlässlicher Ablageort ist ein geeignet aufgesetztes Projekt-Wiki, das auch der Lebendigkeit des Architekturprozesses Rechnung tragen kann. Architekturentscheidungen als großes Worddokument in den Niederungen eines nicht teamfähigen Netzwerklaufwerkes versteckt verliert man hingegen leicht aus den Augen.

2009 – Ein Softwaresystem in der Entwicklung. Es entsteht heute in der Regel iterativ; anders als Napoleon auf dem Schlachtfeld von Waterloo kann ein Entwicklungsteam heute oft noch lernen, und Dinge revidieren. Es ist nicht angebracht, Architekturdokumentation wie Geschichtsschreibung zu betreiben. Wenn zentrale Entscheidungen zu spät dokumentiert werden, ist der Findungsprozess und die Intention dahinter bereits in Vergessenheit geraten. Sollte zu einem späteren Zeitpunkt eine Entscheidung neu bewertet und ggf. geändert werden müssen, fehlen wichtige Informationen.

Werden wichtige Entscheidungen überhaupt nicht dokumentiert, können Sie später bei Fragen neuer Mitarbeiter oder im Architekturreview unter Umständen nur noch antworten mit „das ist historisch gewachsen“.

Links & Literatur

[1] P. Kruchten, „The Rational Unified Process: An Introduction“, Addison-Wesley, 3. Aufl. 2004

 

javamagazin_04_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Historisch gewachsen? – Entscheidungen festhalten“, Java Magazin, 04/2009, 2 Seiten, S. 54

(mit freundlicher Genehmigung)

 

Von Software-Messies und Jar-File-Schlampen

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 6: Von Software-Messies und Jar-File-Schlampen

Logo_Kolumne_JavaMagazinManche Menschen können sich von nichts trennen. Sie müssen alles aufheben, es könnte ja noch gebraucht werden. Am Ende haben sie keinen Überblick mehr über die gehorteten Dinge und verlieren sich in ihnen. Die Fachwelt spricht von einer Desorganisationsproblematik, in schweren Fällen vom Vermüllungssyndrom. Umgangssprachlich bezeichnen wir solche Leute als „Messies“; sie haben „schwerwiegende Defizite in der Fähigkeit, die eigene Wohnung ordentlich zu halten und die Alltagsaufgaben zu organisieren“ [1].

Zu den Alltagsaufgaben eines IT-Architekten gehört es, Abhängigkeiten seines Softwaresystems bewusst zu planen. Hierzu zählen Beziehungen zwischen eigenen Bausteinen (zum Beispiel Subsystemen und Komponenten), zu Fremdsystemen, und insbesondere auch Abhängigkeiten zu Drittprodukten. In Java-Projekten ist es Folklore, für Funktionalität, die nicht die eigentliche Kernaufgabe berührt, auf Fremdbibliotheken zurückzugreifen. Der Open-Source-Bereich bietet hier viel Verlockendes, und hat der klassischen Entscheidung „Make or Buy“ eine dritte Alternative hinzugefügt: „Take“.

Bei Reviews von Softwaresystemen frage ich gern, welche Abhängigkeiten zu Fremdbibliotheken vorliegen. „Och, eigentlich nicht so viele – nur Spring und Hibernate“ war einmal die Antwort. Was übersehen wurde: Diese Lösungen bringen selbst reichlich Potenzial für weitere Abhängigkeiten mit. Und die Verwendung der bequemen Spring-Integrationen verschleiert schnell, was nicht noch alles benötigt wird. Im konkreten Fall waren dies zum Beispiel auch AspectJ, Quartz, und Einiges mehr. Im Projekt hatte man keinerlei Überblick darüber.

Nun sollte man meinen, dass die Abhängigkeiten spätestens dann klarer werden, wenn die Lösung irgendwo durch Dritte in Betrieb genommen werden muss. Denn beim Deployment müssen ja alle benötigten Jar-Files vorgelegt werden – ansonsten gibt es in der Produktion hässliche ClassNotFoundExceptions. Das obige Projekt behalf sich einfach, indem es alle Bibliotheken, die (Zitat) „bei Spring und Hibernate so mit dabei sind“, mit in seine Lieferung packte, und ersparte sich so den Aufwand, herauszufinden, welche es genau benötigte. Das waren dann gefühlte 100 Stück. Bei vielen war unbekannt, wozu sie gut sind. serp-1.13.1.jar? „Wir wissen nicht, was das macht, und ob wir es wirklich brauchen. Aber wir lassen es mal lieber drin – wer weiß?“ – Messies in Entwicklungsprojekten?

In den letzten Kolumnen habe ich bereits einige Sichten auf Architektur beleuchtet. Welche physikalischen Informationseinheiten (Jar-Files, DLLs …) im Rahmen des Entwicklungsprozesses erstellt bzw. benötigt werden, welche Komponenten sie manifestieren, und wie sie für den Betrieb zu verteilen sind, ist ein weiterer Aspekt. Er wird in Architekturdokumentationen in der so genannten Verteilungssicht [2] beschrieben. In der UML gibt es einen eigenen Diagrammtyp dafür: das „Deployment Diagram“ (deutsch Verteilungsdiagramm). Als Modellelemente kommen hier Knoten (z.B. Hardware, Laufzeitumgebungen) und Artefakte wie etwa Anwendungsarchive (EAR-Files etc.) zum Einsatz. Diese werden geeignet verbunden, etwa mit Dependency- oder Deployment-Beziehungen. Zentral ist aber nicht die Form der Dokumentation, sondern dass der Aspekt nicht vernachlässigt wird, und zum Beispiel die Struktur der Abhängigkeiten überhaupt geplant und verstanden wird.

Denn Jar-Files sind kein Schüttgut. Lieblos in den lib-Ordnern der Deployment-Artefakte oder gleich in der Zielumgebung abgeworfen bergen Sie Gefahren. Stellen Sie sich nur vor, in einer Fremdbibliothek wird ein Fehler entdeckt, und Sie müssen auf eine höhere Version umstellen, um ihn zu beheben! Was für Auswirkungen wird das haben? Was, wenn die Wiederverwendbarkeit eines Moduls bewertet werden soll? Was benötigt es, um zu laufen? Sind die Bibliotheken vielleicht nur zum Kompilieren erforderlich, oder nur für die Ausführung der Tests, oder zur Laufzeit? Laufen die Sachen auch unter JDK 1.4 oder Servlet 2.3? Und was, wenn der Auftraggeber nach Ursprung oder gar Lizenz der in der Lieferung enthaltenen Open-Source-Perlen fragt? Wussten Sie zum Beispiel, dass die Anzahl unterschiedlicher Lizenzen, unter denen die „Beimischungen“ eines Spring-Framework-Downloads stehen, zweistellig ist? Wenn die Unordnung der eigenen Lösung ein gewisses Maß überschritten hat, muss plötzlich Softwarearchäologie betrieben werden. Und man wundert sich, wie Lösungen in wenigen Monaten „historisch wachsen“ können.

Besonders unglücklich wird die Situation, wenn die Jar-Files aus unterschiedlichen Quellen stammen und so ungeschickt geschnitten sind, dass verschiedene Fassungen der gleichen Klasse in den Archiven enthalten sind. Wenn am Ende die Reihenfolge der Bibliotheken im Klassenpfad entscheidet, ob die Anwendung die richtige Version verwendet, sind wir dem Fegefeuer der Jar-File-Hölle nahe.

Natürlich ist in den letzten Jahren in vielen Java-Projekten Ordnung eingekehrt. Werkzeuge wie Maven und Ivy machen Abhängigkeiten zum Zeitpunkt des Builds explizit – die Projektbeschreibungen (im Falle von Maven etwa die Datei pom.xml) liefern Hinweise, was zur Laufzeit verfügbar sein muss. Mit geeigneten Werkzeugen kann man früh Abhängigkeiten visualisieren, und so gegen eine Vermüllung ankämpfen – in tragischen Fällen betrifft diese die POM-Files selbst.

Ein weiterer Lichtstrahl am Messie-Horizont: OSGi-Bundles liefern in Form von Metadaten einen regelrechten Beipackzettel mit, was sie in welcher Version benötigen und anbieten. Auf OSGi-Basis erstellte Lösungen sind nicht automatisch so sauber, dass man sich drin spiegeln kann. Aber aufgeräumter sind sie in der Regel schon. Nicht jedes Projekt braucht die Dynamik, die OSGi bietet. Abhängigkeiten explizit zu machen, ist aber in jedem Fall ein wichtiger Beitrag zu einer sauberen Architektur.

Links & Literatur

[1] „Messie-Syndrom“ bei Wikipedia, http://de.wikipedia.org/wiki/Messie
[2]  Gernot Starke, „Effektive Software-Architekturen“, Hanser Fachbuch, 5. Auflage 2011

 

javamagazin_03_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Von Software-Messies und Jar-File-Schüttgut“, Java Magazin, 03/2009, 2 Seiten, S. 56

(mit freundlicher Genehmigung)

 

 

Laufzeitsicht: Der jüngste Spieler fängt an!

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 5: Laufzeitsicht: Der jüngste Spieler fängt an!

Logo_Kolumne_JavaMagazinBrettspiele zu entwickeln ist mit der Softwareentwicklung durchaus vergleichbar. Auch hier wird konzipiert, entworfen und getestet. Und dokumentiert! Ein Teil der Dokumentation liegt am Ende jeder Spielepackung bei: Die Anleitung. Bei komplexen Spielen kann sie sehr umfangreich sein. Die Autoren müssen sich Gedanken machen, wie man Spielidee, -regeln und vielleicht sogar Hinweise zur Taktik effektiv kommuniziert. Gut gemachte Spielanleitungen haben eine klare Struktur mit oftmals gleichem Aufbau. Den Anfang macht stets die Darstellung des Spielzieles. Ähnlich wie bei der Architekturdokumentation verwenden Spielanleitungen im Anschluss verschiedene Sichten, um unterschiedliche Aspekte zu zeigen. Kapitel wie Spielmaterial und -vorbereitung zielen eher auf statische Aspekte ab. Den weitaus größten Teil einer Anleitung nimmt aber gewöhnlich der Spielablauf – Phasen, gültige Züge – also die Dynamik ein.

Abb. 1: Spielregeln für Springer beim Schach

Abb. 1: Spielregeln für Springer beim Schach

Bei den unterschiedlichen Sichten auf Softwarearchitektur finden sich dynamische Aspekte in der sogenannten Laufzeitsicht (alternativ: Verhaltenssicht). Hier geht es darum zu beschreiben, wie Softwareelemente zur Laufzeit interagieren, bzw. wie ein Element selbst sich verhält. Verglichen mit der Bausteinsicht [1] nimmt sie in Architekturdokumentation oftmals weniger Platz ein. In vielen Situationen macht jedoch erst die Zusammenschau aus Baustein- und Laufzeitsicht klar, wie das System eigentlich funktioniert, bzw. zu verwenden oder zu erweitern ist.

Wie gehen Sie als Architekt nun an die Dokumentation dynamischer Aspekte Ihres Softwaresystems heran? Klären Sie für jede konkrete Beschreibung von Laufzeitverhalten zunächst wichtige Fragen zum „was“ und „wie“! Zunächst: Was beschreiben Sie? Das Verhalten eines einzelnen Bausteins, oder das Zusammenspiels von mehreren? Einen speziellen Ablauf exemplarisch, oder die Menge aller möglichen Abläufe? Und im Anschluss: Wie beschreiben Sie es? Textuell, oder mit Hilfe einer oder mehrerer Abbildungen?

Abb. 2: Spielregeln für Bundles im OSGi-Framework

Abb. 2: Spielregeln für Bundles im OSGi-Framework

Gerade bei Abläufen, die Alternativen oder Ausnahmen beinhalten, bieten sich Visualisierungen an. Spielanleitungen machen es vor. Selbst die sonst eher drögen offiziellen Schachregeln [2] greifen zu Abbildungen, um z.B. die möglichen Bewegungen der Figuren zu erklären (siehe Abb. 1). In der Softwareentwicklung zählen Struktogramme zu den klassischen Techniken, um Verhalten zu beschreiben. Die UML 2 kennt unter anderem Aktivitäts-, Sequenz- und Zustandsdiagramme. Als ein Beispiel für letztere visualisiert Abbildung 2 die gültigen Zustände und Zustandsübergänge im Lebenszyklus eines OSGi-Bundles. Sie ist der OSGi-Spezifikation entnommen; eine gleichwertige textuelle Beschreibung wäre offensichtlich nicht so kompakt und würde sich dem Leser auch nicht so schnell erschließen.

Trotz der Vorzüge finden sich nicht in jeder Dokumentation Abbildungen zum Verhalten. Die Servletspezifikation z.B. beinhaltet keine einzige; die dynamischen Aspekte der Elemente werden ausschließlich textuell beschrieben. Das betrifft zum Beispiel die Reihenfolge, in der ein Servlet-Container die Lebenszyklusmethoden von Komponenten aufruft. In Anbetracht der geringen Komplexität der Sachverhalte mag diese Entscheidung bewusst getroffen worden sein.

Für Ihr eigenes Softwaresystem entscheiden Sie selbst, welche dynamischen Aspekte Sie wann und wie dokumentieren wollen. Auch den Pflegeaufwand während der Entwicklung sollten Sie im Auge behalten.

Die Beschreibung dynamischer Aspekte im Rahmen der Dokumentation ist von besonders großer Bedeutung, wenn Ihr Softwaresystem gewollte Erweiterungspunkte aufweist. Wer ein neues Modul hinzufügt muss wissen, nach welchen Spielregeln das zu erfolgen hat. Das schließt neben statischen Belangen (z.B. geforderte Schnittstellen in Form von zu implementierenden Interfaces) auch dynamische ein. Wenn die Entwicklung von Erweiterungen forciert werden soll (z.B. in Plugin-Architekturen) tun Sie gut daran, hier ein besonderes Augenmerk drauf zu legen, vielleicht sogar Beispielimplementierungen in der Dokumentation zu besprechen.

Schach hat nicht den Anspruch, besonders gut erweiterbar zu sein. Man kann keine Zusatzfiguren kaufen. Viele moderne Autorenspiele hingegen bieten Ergänzungen an. Von modernen Softwareentwürfen erwartet man Erweiterbarkeit in der Regel sogar.

Links & Literatur

[1] S. Zörner: „Was ist was? Band 127: Unser Softwaresystem“, Java Magazin 1.2009
[2] Die FIDE-Schachregeln, Offizielle Übersetzung des DSB, http://www.schachbund.de

 

javamagazin_02_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Laufzeitsicht: Der jüngste Spieler fängt an!“, Java Magazin, 02/2009, 1 Seite, S. 57

(mit freundlicher Genehmigung)

 

 

Was ist was? Band 127: Unser Softwaresystem

By | Kolumne | No Comments

Kolumne „Architekturen dokumentieren“

Folge 4: Was ist was? Band 127: Unser Softwaresystem

Logo_Kolumne_JavaMagazinErinnern Sie sich noch an die „Was ist was?“-Bücher über Natur, Technik und vielem mehr [1]? Die Reihe gibt es noch immer; sie leistet mir gute Dienste, wenn meine Kinder mich mit Fragen bombardieren. Der menschliche Körper etwa ist ziemlich komplex. Um ihn zu beschreiben, zerlegen Bücher dieser Art ihn in funktionale, in sich abgeschlossene Teile. Es gibt reich bebilderte Kapitel über die Muskeln, die Atmung oder das Verdauungssystem. In diesen wird weiter verfeinert, kleinere Bauteile wie Herz und Lungen und ihr Zusammenspiel werden im Kontext des Teilsystems anschaulich erklärt.

Was das mit Architekturdokumentation zu tun hat? Softwaresysteme sind ebenfalls komplexe Gebilde. Zu ihrer Beschreibung bedient sich ein Architekt, wie in der letzten Folge ausgeführt, verschiedener Sichten. Eine davon haben Sie in dieser Reihe bereits kennen gelernt: den Systemkontext [2]. Eine weitere Sicht, die in keiner Architekturbeschreibung fehlen darf, stellt das System als Summe seiner funktionalen Teile dar, und zeigt deren Beziehungen untereinander. Die Literatur verwendet unterschiedliche Bezeichnungen (Struktursicht, Bausteinsicht, …), die Funktion ist aber stets die gleiche.

Die Zerlegung der anvisierten Softwarelösung in Bausteine ist eine zentrale Aktivität des Architekturentwurfes; Entscheidungen, die hier getroffen werden bilden den Rahmen für alles weitere. Ganz ähnlich wie jedes Organ eine bestimmte Aufgabe erfüllt, sollten auch Subsysteme und Komponenten innerhalb eines Softwaresystems klar abgegrenzte Verantwortlichkeiten haben. Eine angemessene Zerlegung des Softwaresystems in unabhängige Teile mit Schnittstellen untereinander erleichtert die Entwicklung in Teams, die Weiterentwicklung und Pflege, und sie eröffnet eine spätere Wiederverwendung oder einen Austausch von Teilen. Modularisierung ist kein Java-spezifisches Thema, doch gerade in unserer Gemeinde hochaktuell, wie das große Interesse am dynamischen Modulsystem OSGi zeigt.

Beim Entwurf der Bausteinsicht zerlegen Sie Ihr Softwaresystem top-down ausgehend von der Kontextsicht. Dort war das System noch eine Blackbox, jetzt schauen Sie hinein (Whitebox). Im ersten Schritt zeigen Sie die identifizierten Subsysteme mit ihren Abhängigkeiten untereinander. Jedes einzelne ist dann wieder eine Blackbox. Bei komplexen Systemen wiederholt sich dieser Vorgang einige Male; es entstehen Ebenen unterschiedlicher Detaillierung. Sie landen über System, Subsystemen, Modulen und Komponenten irgendwann bei der Implementierung.

Als Form der Darstellung bieten sich Visualisierungen an, da sich die Systemstruktur mit ihren Elementen und deren Beziehungen untereinander graphisch leicht kommunizieren lässt. Die UML kennt beispielsweise das Kompositionsstrukturdiagramm als mögliche Notation. Es zeigt die Struktur von Komponenten, die ein übergeordnetes Größeres realisieren (vgl. Abb. 1), und macht den Übergang zwischen den Ebenen (Blackbox, Whitebox) explizit.

Abb. 1: Ein Kompositionsstrukturdiagramm der UML2

Abb. 1: Ein Kompositionsstrukturdiagramm der UML2

Auch wenn Sie mit dieser Technik nach Belieben in das System hineinzoomen können, empfehle ich im Rahmen einer Architekturdokumentation nicht beliebig detailliert zu werden. Es wird sehr aufwendig, den Entwurf konsistent zur Implementierung zu halten. Eine veraltete Bausteinsicht bringt später keinen Mehrwert. Aktuell gehalten hingegen kann sie im weiteren Verlauf zur Kommunikation der Lösungsideen im Rahmen von Architekturbewertungen dienen, und zur Einarbeitung neuer Mitarbeiter („Was ist was?“). Formal als Modell beschrieben kann eine Bausteinsicht auch Ausgangspunkt sein für das Generieren verschiedenster Artefakte.

Zum Schluss noch einmal zurück zum menschlichen Körper. Dass man ihn in unterschiedliche „Subsysteme“ zerlegen kann, hat nicht nur die Einsteigerliteratur entdeckt. Die Ärztezunft macht sich diesen Aspekt für ihre Spezialisierungen zunutze. Ein Herzchirurg kennt sich nur mit einer Komponente, inkl. des Zusammenspiels mit den beteiligten Fremdsystemen, richtig gut aus. Bei IT-Fachkräften kann es ebenfalls schnell zu Spezialisierungen kommen. Man schaue sich nur Berater für spezielle SAP-Module an. Einen Softwarearchitekten möchte ich lieber mit einem Allgemeinmediziner vergleichen: „Wo tut’s denn weh?“

Links & Literatur

[1] „Was ist was? Band 50: Unser Körper“, Tesloff 1972, aktuelle Auflage 2005
[2] S. Zörner: „Kombiniere – der Systemkontext“, Java Magazin 11.2008

 

javamagazin_01_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Was ist was? Band 127: Unser Softwaresystem“, Java Magazin, 01/2009, 1 Seite, S. 69

(mit freundlicher Genehmigung)

 

Hat Mozart modelliert?

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 3: Hat Mozart modelliert?

Logo_Kolumne_JavaMagazinIn der Musik werden Melodien als Noten in einem speziellen Liniensystem visualisiert. Es erlaubt die Angabe von Tonhöhen, -längen und vielem mehr und ist eine seit Jahrhunderten etablierte, grafische, domänenspezifischen Sprache. Komplexe musikalische Werke wie eine Sinfonie werden allerdings nicht einfach mit einer Folge von Noten beschrieben. Die in der Softwareentwicklung bewährten Mittel, um mit Komplexität umzugehen, finden auch hier Verwendung: Abstraktion, Zerlegung, Hierarchie. Beispiele hierfür sind kompakte Beschreibungen, die sich zur schnellen Einordnung des Werkes eignen (Abstraktion, z.B. „1. Klavierkonzert op. 23 in b-Moll“), Zerlegung einer Partitur durch unterschiedliche Einzelstimmen je Musikinstrument, oder auch durch Akte, Sätzen, Takte (Hierarchiebildung). Bei Bühnenwerken kommen ggf. noch Bühnenbild und Handlung dazu. Viele Sichten auf das große Ganze werden erstellt, jede verfolgt einen besonderen Zweck und hat eine bestimmte Zielgruppe.

Mit Entwürfen von Softwaresystemen verhält es sich genau so. Auch hier werden Ideen und Konzepte gerne visualisiert, um sie zielgruppengerecht kommunizieren zu können. Allerdings reicht ein einzelnes Bild in der Regel nicht aus, um allen Adressaten gerecht zu werden, bzw. alle relevanten Aspekte zu beschreiben. Auch in Architekturbeschreibungen haben sich mehrere Sichten bewährt.

Mit der Darstellung des Systemkontextes im letzten Heft haben Sie bereits eine spezielle Sicht auf Software kennen gelernt. Ich werde in späteren Folgen weitere beleuchten. Die Literatur schlägt unterschiedliche Sichtensätze vor, am prominentesten sind vielleicht die 4 + 1 Sichten, wie sie auch im Rational Unified Process [1] Verwendung finden. Alternativ beschreibt Gernot Starke Kontext-, Baustein-, Laufzeit- und Verteilungssicht [2]. Es ist müßig, den universellen, minimalen Satz von Sichten zur optimalen Überdeckung aller Architekturaspekte finden zu wollen. Je nach Situation sind bestimmte Sichten notwendig oder auch nicht. In der Musikwelt kommt für ein Ballet die Choreographie hinzu, für einem Auftritt von Pink Floyd wird ein Beleuchtungskonzept erarbeitet.

In jedem Fall wird aber mehr als ein einzelnes großes Bild zum Entwurf eines Softwaresystems von Nöten sein. Damit stellt sich aber die Frage, wie Sie Sorge tragen können, dass unterschiedlichen Sichten untereinander konsistent entworfen werden, und es im Verlauf einer iterativen Entwicklung auch bleiben. Sichten haben unterschiedliche Zielgruppen (Auftraggeber, Entwickler, Betrieb, QS, …), und widersprüchliche Sichten führen im Verlauf eines IT-Projektes schnell zu Missklängen, Mehraufwenden, im Extremfall zum Scheitern des Vorhabens.

Mir ist ein völliges Rätsel, wie Mozart es ohne Toolunterstützung (mal abgesehen von Tinte und Feder) hinbekommen hat, die Noten der unterschiedlichen Instrumente für ein sinfonisches Werk konsistent zu halten. IT-Architekten sind in der Regel weitaus weniger genial; und daher an geeigneten Werkzeugen und Techniken zur Erstellung ihrer Arbeitsergebnisse interessiert.

Ein viel versprechender Ansatz, um die Konsistenz zwischen den unterschiedlichen Sichten einer Architektur sicherzustellen, ist es ein einheitlichen Modell darunter zu legen. Immerhin setzen erfolgreiche Ingenieursdisziplinen seit langem auf Modelle, der Automotive-Bereich etwa im Computer Aided Design. Was hat die Softwareentwicklung zu bieten?

Ein nahe liegender Kandidat ist die UML. Als grafische Notation bietet sie für unterschiedliche Sichten passende Diagramme an. Aber man kann mehr als nur ein paar Bildchen malen. Der zentrale Punkt ist, dass die unterschiedlichen Diagramme tatsächlich Sichten auf ein einheitliches Modell sind. Man muss Sichten nicht zwingend mit UML beschreiben. Bezüglich der Erhaltung der Konsistenz schneiden Powerpoint und Co. aber vergleichsweise schlecht ab, weil der Modellgedanke fehlt. Echte Alternativen sollten ihn berücksichtigen.

Aber man kann es auch übertreiben. UML-Modelle mit dem Detaillierungsgrad der Implementierung sind kaum konsistent zum Quelltext zu halten. Projekte verzichten zu Recht darauf, dieses Ziel zu erreichen. Architektursichten sind jedoch abstrakter; hier besteht berechtigter Grund zur Hoffnung, zumindest auf dieser Ebene widerspruchsfreie, zielgruppengerechte Sichten auf das Ganze zu schaffen.

Also Vorsicht. Ein Taktstock allein macht noch keinen Dirigenten. Und ebenso ein UML-Tool noch keinen erfolgreichen IT-Architekten. Entwickler spielen ohnehin, um im Bild zu bleiben, nicht gern vom Blatt ab. Sie bevorzugen es, im vorgegebenen Rahmen kreativ zu sein, treffen selbst Entscheidungen, und zu einem gewissen Grad improvisieren sie auch. Agile Projekte erinnern daher eher an Jazz mit seiner stilistischen Individualität einzelner Musiker. Trotz Freiräumen gibt es auch in diesem Musikstil klare Strukturen. Zum Beispiel einen gemeinsamen Takt.

Links & Literatur

[1] P. Kruchten, „The Rational Unified Process: An Introduction“, Addison-Wesley, 3. Aufl. 2004
[2] Gernot Starke, „Effektive Software-Architekturen“, Hanser Fachbuch, 5. Auflage 2011

 

javamagazin_12_2008Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Hat Mozart modelliert?“, Java Magazin, 12/2008, 1 Seite, S. 44

(mit freundlicher Genehmigung)

 

Kombiniere — der Systemkontext

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 2: Kombiniere — der Systemkontext

Logo_Kolumne_JavaMagazin

Waren Sie schon mal im Krimitheater? Samstagabend, 20:00 Uhr: Auf der Bühne liegt eine Leiche, ein Mord ist geschehen. Der Detektiv beginnt seine Arbeit und untersucht auf der Jagd nach Verdächtigen als erstes das Umfeld des Opfers, den Kontext. Wer hatte ein Motiv? Mit wem hat das Opfer zuletzt gesprochen?

Ihrer Softwarelösung wünsche ich natürlich nicht den baldigen IT-Tod – eine Umfeldanalyse ist aber auch hier von zentraler Bedeutung. Software agiert nicht allein, stets gibt es Beteiligte außerhalb des Systems. Anwendergruppen etwa, die Funktionalität nutzen und erwarten, oder Fremdsysteme, die zur Ausführung erforderlich sind. Betrachten wir als Beispiel das Krimitheater. Zusätzlich zum traditionellen Verkauf möchte es seine Tickets in Zukunft über das Internet anbieten. Kunden sollen selbst Plätze aussuchen, und über Kreditkarte und PayPal bezahlen. Der Versand der Karten erfolgt als PDF über E-Mail. Ihre Aufgabe: Ein neues System entwerfen, das diese Anforderungen abdeckt, und sich in die bestehende IT-Landschaft der Theaterverwaltung einbettet. Nehmen Sie sich ein Beispiel am Detektiv und betrachten das Umfeld! Im Gespräch mit dem Auftraggeber finden Sie heraus, dass für die Verwaltung des Spielplans und das Drucken von Tickets bereits Systeme in Betrieb sind. Neben den Kunden sollen auch die Mitarbeiter der telefonischen Kartenvorbestellung in Zukunft Ihre neue Anwendung nutzen.

Abb. 1: Systemkontext notiert in UML

Abb. 1: Systemkontext notiert in UML

Zur Visualisierung des Umfelds ist das Systemkontextdiagramm ein nützliches Werkzeug. Es stellt das zu beschreibende System im Mittelpunkt als Blackbox dar. Drum herum sind die direkt beteiligten Benutzer und Fremdsysteme angeordnet. Eine Verbindung zwischen einem solchen Akteur und dem System drückt Interaktion aus. Die Abbildung zeigt ein Diagramm für unser Beispiel notiert in UML. Wozu dient das alles? Zunächst einmal finden Sie so potenzielle Schnittstellen zum Zielsystem. Die Anbindung eines Fremdsystems ist regelmäßig ein technisches Risiko; solche frühzeitig zu erkennen kann entscheidend sein für den Erfolg Ihres Projektes. Darüber hinaus können Sie mit Hilfe des Systemkontextes starten Verantwortlichkeiten zu klären. Welche Fremdsysteme müssen Sie integrieren? Was leistet Ihr System, und vor allem: was leistet es nicht? Wo ist die Systemgrenze? Zuweilen erfordert das Klären des Systemkontextes wirklich detektivischen Spürsinn: Die Wahrnehmungen unterschiedlicher Zeugen (Stakeholder) des aufzuklärenden Sachverhaltes variieren mitunter erheblich. Manch üblicher Verdächtige (Akteur) entpuppt sich als unschuldig, andere haben sich womöglich Pseudonyme zugelegt. Zu unserem Beispiel: Muss der Ticket-Shop Kundendaten speichern, oder macht das ein anderes System? Wenn ja welches? Liegt es in unserem Verantwortungsbereich sicherzustellen, dass jeder Platz nur einmal pro Vorstellung verkauft wird? Oder macht das das TicketSystem? Was passiert, wenn eine Vorstellung abgesagt wird? Müssen wir die betroffenen Kunden benachrichtigen? Wie soll die Kreditkartenbezahlung integriert werden? Neben der Analyse für neu zu entwerfende Systeme kann der Systemkontext auch eingesetzt werden, um ein abzulösendes System zu modellieren (nun doch eine Softwareleiche). Wenn Sie die Komplexität eines solchen Vorhabens abschätzen, ist es interessant zu wissen, mit welchen Fremdsystemen und Benutzern das alte System interagiert. Wer nutzt gegenwärtig die Funktionalität? Auf welche Systeme stützt es sich ab, um seine Leistungen zu erbringen? Diese Verbindungen werden vermutlich auch zum neuen System bestehen. Ich habe das Diagramm oft erfolgreich in Workshops eingesetzt, bei Neuentwicklungen wie auch bei Systemablösungen. Schnell auf Flipchart oder Whiteboard geworfen ist es auch für UML-Laien intuitiv verständlich. Es hat stets frühzeitig wichtige Fragen herbeigeführt. Auch Sie werden bei der Erstellung viele offene Punkte ermitteln. Hier Verantwortlichkeiten festzulegen und Entscheidungen zu treffen ist Ihre Aufgabe als Architekt! Zurück ins Theater. 22:30 Uhr, der Täter ist identifiziert. Er stammt aus dem Umfeld des Opfers, und stand in enger Beziehung zu ihm. Zur Entlarvung stellte der Detektiv viele Fragen. Schlusssatz Dr. Watson: „Brilliant, Holmes, brilliant“. Vorhang.

 

javamagazin_11_2008

Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„Kombiniere — der Systemkontext“, Java Magazin, 11/2008, 1 Seite, S. 43

(mit freundlicher Genehmigung)