Gemeine Kenntnislücken

In der dotnetpro 5/2010 habe ich in meiner Sandbox-Kolumne beklagt, dass viele .NET-Entwickler heute nicht vertraut sind mit Lambda-Funktionen oder der Funktionsweise von yield return (C# Iteratoren). Daraufhin bekam ich folgende Zuschrift eines Lesers:

“[I]n deiner neusten Sandbox ziehst du ja ganz schön über uns Entwickler her! Ich bin der Meinung, dass das ziemlich gemein ist.”

Das hat mich schon ein wenig getroffen. Denn “gemein” möchte ich ja nicht sein. Gemein findet der Leser es, dass ich die Unkenntnis von Jahre alten und grundlegenden Features des Hauptwerkzeugs von .NET-Entwicklern kritisiere, denn…

“Wenn ich meine tägliche Arbeit als Entwickler reflektiere, bin ich der Meinung das [m]an fast keine Change hat sich in alle neuen Technologien einzuarbeiten. Der tägliche Projektablauf ist halt mehr auf Codegenerierung ausgelegt. Es gibt halt von Seiten des Managements oft keine Toleranz für Weiterbildung oder den Einsatz von neuen Technologien.”

Leider liegt hier ein Missverständnis vor. Ich habe eben nicht gesagt, dass “man” (also jeder Entwickler) sich in “alle neuen Technologien” einarbeiten muss. Ich habe vielmehr geschrieben: “Zugegeben, niemand muss alles beherrschen. Und niemand kann alles beherrschen.” Und selbstverständlich habe ich Verständnis dafür, wenn im Projektdauerstress Veränderungen an Konzepten und Technologien nicht sofort nachvollzogen werden. Das kennen wir ja auch alles schon. Ja, ich weiß, lieber Leser:

“Es gibt halt von Seiten des Managements oft keine Toleranz für Weiterbildung oder den Einsatz von neuen Technologien.”

Deshalb habe ich ja eben auch nicht über die neueste Mode gesprochen und schon gar nicht über VS2010/.NET 4. Es ging mir um Features, die Jahre (!) alt sind. Es ging mir um Features des Haupt(!)werkzeugs. Nix Esoterisches.

Eine Analogie mag helfen: Wer einen Klempner trifft, in dessen übervollen Werkzeugkasten eine Bohrmaschine liegt, dessen Knöpfe er nicht erklären kann, der wird sicherlich Zweifel an der Professionalität des Klempners haben. Eine Bohrmaschine gehört zu dessen wichtigsten Werkzeugen (nehme ich an ;-). Die muss er auf dem Effeff beherrschen. Ist es dann gemein, wenn diese Unkenntnis hervorhebt und beklagt?

Nein. Natürlich ist das nicht gemein. Ich kann alles mögliche Verständnis dafür haben, warum der Klempner in den vergangenen 5 Jahren keine Zeit hatte, die Bohrmaschinenknöpfe kennenzulernen. Immer soviel zu tun. (Oder eher sowenig?) Ja, ja, schon schlimm die Auftragslage.

Doch das ändert nichts daran, dass er sein Werkzeug nicht beherrscht. Und damit frage ich mich, ob er für mich einen guten Job machen kann. Kann er die Löcher in bester Weise bohren, wenn er die Schlagbohrfunktion nicht kennt? Hm… wahrscheinlich nicht immer.

Jetzt zurück zur Softwareentwicklung. Hier ein Beispiel für die Arbeit eines Entwicklers, der nicht firm in der Verwendung von Lambda-Funktionen ist:

Ist das gut lesbar? Kaum.

Hier der Code lesbarer gemacht:

Und jetzt überlege man einmal, wie viel es ein Unternehmen jedes Mal kostet, wenn Entwickler Änderungen an schwer lesbarem Code vornehmen sollen. Dauert das 5% länger oder 10% oder gar 50%? In jedem Fall dauert es jedes, jedes Mal messbar länger.

Natürlich kostet es auch Zeit, sich mit Lambda-Funktionen auseinander zu setzen. Vielleicht 1-2 Tage. Das ist allerdings Zeit, die nur einmal anfällt. Danach stehen die Kenntnisse zur Verfügung und können helfen, Code z.B. lesbarer zu machen.

Stehen Sie nicht zur Verfügung, dann ist es ein Fass ohne Boden, wie oft Mehraufwand zu treiben ist. Das misst zwar keiner – aber es ist viel, viel teurer. Und es wird beklagt. Keine Sorge. “Warum dauert das schon wieder so lange mit dem neuen Feature?” ist (allermeistens) eine indirekte Klage darüber, dass Code unstrukturiert oder unlesbar ist. Dem, der klagt, fehlt zwar das Verständnis für den Kausalzusammenhang. Aber die Ursache ist dennoch dieselbe: mangelnde Werkzeugkenntnis. Ist das gemein? Ja, ich würde sagen, das ist gemein. Denn der, der klagt, ist wahrscheinlich gleichzeitig der (Mit)Verursacher der Unkenntnis.

Und nochmal: Ich rede nicht über exotische Features der Workflow Foundation. Ich rede über “Brot und Butter” Features des Hauptwerkzeuges jedes Programmierers: seine Programmiersprache. Man werfe mir also bitte nicht Gemeinheit vor, wenn ich darüber (schon wieder) den Kopf schüttele.

Eigentlich kann es mir ja sogar egal sein. Wenn ein Entwickler 5 Jahre oder mehr

“[…] Erkenntnisse  nicht in der Praxis einsetzen kann/darf hat man” und so “ irgendwann nur noch ein "Halbwissen"” hat,

dann ist es ja nicht mein Problem, wenn der Code schwerer als nötig lesbar ist oder er einen Job wie diesen nicht annehmen könnte:

Denn wenn dort schon TDD und Scrum im Titel stehen, dann wird man erwarten, dass der Bewerber sein Hauptwerkzeug selbstverständlich kennt. Denn TDD ohne Lambda-Funktionen ist kaum denkbar, wenn man moderne Mock-Frameworks einsetzen will.

Wer “irgendwann nur noch ein Halbwissen” hat und als Grund die mangelnde “Toleranz für Weiterbildung” beim Management anführt, der begibt sich in gefährliche Abhängigkeit. Denn wenn sich das Management in ähnlicher Weisheit wie in Bezug auf die Fortbildung entschließt, es einmal ohne den halbwissenden Entwickler zu probieren, dann wird der nächste Job kaum besser.

Gegen das Halbwissen hilft kein Händeringen und kein hoffender Blick zum Management. Halbwissen ist – das klingt hart, ist aber deshalb nicht minder wahr – im Wesentlichen selbstverschuldet. Heute noch mehr als gestern. Denn die Zeiten der verlässlichen Institutionen, die für uns die Lebensplanung übernehmen, ist vorbei. Unwiederbringlich. Verlässlichkeit und weise, gütige, wissende Lehrer, Beamte, Manager, Firmenpatriarchen oder was auch immer finden sich eher nur noch im Geschichtsbuch.

Die wahre Gemeinheit besteht also in den Kenntnislücken, die Entwicklern nicht nur das Entwickeln schwerer als nötig machen, sondern ihnen auch Freiheitsgrade bei der Gestaltung ihres Lebens nehmen.

Was dagegen tun? Am Ball bleiben. Braucht es dafür immer Freizeit? Nein. Einfach unter der Woche in der Arbeitszeit jeden Tag 30 Minuten hinsetzen und lesen. Oder etwas in Visual Studio ausprobieren. Wer soll denn da kommen und das verbieten? Der unverständige Manager? “Hey, was programmieren Sie denn da? Gehört das zum Feature X?” Und selbst wenn er es fragt, dann lautet die Antwort eben “Ja, das gehört dazu. Ich muss etwas ausprobieren.” Oder die Antwort auf einen Kommentar zum Lesen währen der Arbeit: “Ich muss etwas nachlesen, damit ich die Aufgabe besser erfülle.”

In welchem Land leben wir denn, wo nicht nur private Emails während der Arbeitszeit untersagt werden, sondern auch noch die Fortbildung? Wie viel Mikrokontrolle will denn Management ausüben?

Also, lieber Leser, es hilft nichts. Die Gemeinheit liegt nicht bei mir. Einen Missstand hervor zu heben, ist nicht gemein. Gemein ist der, der ihn herstellt – vor allem, wenn er womöglich weiß, dass er “das Personal dumm hält.”

16 Stunden in stickiger Luft und mit krummem Rücken müssen wir nicht mehr arbeiten. Gut so. Aber in einer der schnellsten Branchen zu arbeiten ohne Chance, sich durch kontinuierlichen Wissenserwerb unabhängig von einem Arbeitgeber zu halten, ist kaum besser. Das physische Leid ist vergangen. Präsent ist die aber anscheinend noch die existenzielle Abhängigkeit. Und das in einer Zeit, wo der, von dem man sich abhängig macht, überhaupt keine Garantie mehr geben kann, dass er für den Abhängigen auch angemessen sorgen kann.

Davon, dass der sinkende Wissenspegel (im Verhältnis zum Relevanten) nicht nur dem Entwickler, sondern sogar dem ignoranten Management schadet, mal ganz zu schweigen. Wo z.B. 19.000 Zeilen Code unwidersprochen in einer Klasse stehen können – ja, das habe ich neulich gesehen –, da kann mir niemand erzählen, dass irgendeinen Vorteile hätte. Das hat nur Nachteile, die viel, viel Geld kosten. Und das, weil der, der den Code geschrieben hat, mit “Halbwissen” zufrieden war. Das ist schlicht unprofessionell – und nicht nur auf Seiten des Entwicklers. Da hat das Management auch seine “Aufsichtspflicht” verletzt.

Und jetzt? Ran an den Ball. VS2010 und .NET 4 sind draußen. Auch ich muss mir das für mich Relevante jetzt drauf schaffen. Manchmal würde ich lieber mit dem Altbekannten weiter mokeln. Doch ich bin ja auch Teil der Branche und kann mich daher nicht vom Lernen ausnehmen. Wir sitzen alle im selben Boot.

Schaffe ich das mit dem Lernen übrigens komplett in dem, was ein Angestellter als seine Arbeitszeit ansehen würde? Nein. Aber es hilft nichts. Wenn ich gerade als Freiberufler weiter gefragt sein will, dann darf ich da nicht so genau sein. Zum Glück macht mir das Lernen allerdings Spaß. Ich fühle mich in dieser Branche gut aufgehoben.

PS: Bevor ich´s vergesse: Als Kritiker des allgemein nicht so rosigen Standes der Branche stehe ich nicht allein. Man lese mal hier bei SEMAT:

Software engineering is gravely hampered today by immature practices.

“Immature practices” – darum geht es. Das bezieht sich genauso auf das (oft abwesende) Vorgehensmodell wie auf die Abwesenheit von Fortbildungsplanung wie auf die Unkenntnis von zentralen Konzepten der Informatik (denn nichts anderes sind Iteratoren und Lambda-Funktionen), die präsent sind im Hauptwerkzeug eines Entwicklers.

Feingranular – Methoden als Event-Based Components

Mit Event-Based Components können Sie sehr schön top-down, bottom-up oder nach dem Jo-Jo-Prinzip entwerfen. Es ist egal.

Holarchische Modellierung

Fangen Sie einfach an. Malen Sie einfach Systeme von Funktionseinheiten, die Ihr Problem durch den Austausch von Nachrichten lösen.

Diese Funktionseinheiten sind einfach Verantwortlichkeiten. Wie sie später mal implementiert werden…? Keine Ahnung. Während der Entwurfszeit, mache ich mir da nicht viele Gedanken. Ich male einfach hin, was mir auf dem aktuellen Abstraktionsniveau in den Sinn kommt, das hilfreich sein könnte. Für eine kleine Funktionsplotteranwendung sind das halt zunächst diese beiden Funktionseinheiten.

Wenn ich dann aber weiter überlege, dann fallen mir natürlich Subfunktionalitäten ein, z.B.

Was werden denn die eingeschachtelten EBCs in der späteren Implementierung? Immer noch keine Ahnung. Muss auch nicht sein. Es sind halt Funktionseinheiten, die mir sinnvoll erscheinen. Sie zerlegen die große ganze Funktionalität in besser handhabbare Teilfunktionalitäten. Je weiter mein Verständnis der Problemdomäne voran schreitet, desto mehr solcher Teilfunktionalitäten erkenne ich. Wenn ich z.B. darüber nachdenke, wie so ein Compiler aussieht, dann komme ich auf folgende Verfeinerung:

Was sind Scanner und Parser nun am Ende in der Implementation? Keine Ahnung. Damit muss ich mich während des Entwurfs nicht beschäftigen. Das ist das schöne an einer “holarchischen Modellierung” :-)

Holarchisch ist dieser Entwurf, weil das System der Funtionseinheiten hierarchisch ist und auf jeder Ebene wieder aus “Teil-Ganzen” (Holon)  besteht. Jedes Blatt einer Ebene (im letzten Bild z.B. Parser) kann jederzeit weiter zerlegt werden. So ein EBC-Softwaresystem ist eine selbstähnliche Struktur, quasi fraktal :-)

Ein Modell ist dieser Entwurf, weil die Elemente eben keine Codeartefakte sind. Ich denke beim EBC-Entwurf nicht in Assemblies oder Klassen oder Methoden. Ob eine Funktionseinheit wie Plotter oder Scanner am Ende als dieses oder jenes Artefakt implementiert wird, das ist während des Entwurfs unwichtig. Der soll nur ein problemlösendes System entwickeln.

So weit, so gut.

Nach dem Entwurf kommt aber natürlich irgendwann doch die Implementation. Dann müssen Sie sich Gedanken machen, wie Sie die geplanten Funktionseinheiten übersetzen.

Funktionseinheiten in Klassen übersetzen

In den bisherigen Blogartikeln habe ich EBCs immer in Klassen übersetzt. Aus einem Blatt ist dort eine EBC-Bauteil-Klasse  geworden, deren Input-Pins Methoden und deren Output-Pins Events waren. (Statt Events werde ich in Zukunft jedoch normale Delegaten benutzen. Events haben einen Sonderstatus als Delegaten, der den Umgang mit Ihnen in generischer Weise manchmal erschwert.)

Das ist eine sinnige Übersetzung für die allermeisten Fälle, denke ich, die auch für Nicht-Blätter ausreicht. EBC-Platinen, d.h. Funktionseinheiten, die andere aggregieren, enthalten allerdings keine eigene Domänenfunktionalität, sondern nur Code, um ihre Konstituenten zu verdrahten. Das passiert im folgenden Beispiel im Konstruktor.

Diese Übersetzungen für Bauteile und Platinen reichen eigentlich völlig aus, um beliebig tief geschachtelte Systementwürfe in Code zu manifestieren. Es gibt keinen Impedance Mismatch zwischen Modell und Implementierung.

Funktionseinheiten in Methoden übersetzen

Eigentlich könnte ich zufrieden sein mit der Übersetzung von EBCs in Klassen. Aber irgendwie wurmt es mich, dass ich mit einerseits bei der Modellierung keine Gedanken machen soll darüber, wie die Implementierung einer Funktionseinheit aussieht. Andererseits jedoch werde ich quasi gezwungen, darüber nachzudenken, ob denn eine Funktionseinheit auch nicht kleiner als eine Klasse sei. Zwar sollte ein Architekturentwurf mit EBCs nicht zu detailliert ausfallen; immerhin soll sich ein Architekt nicht um Klassen, sondern um Komponenten kümmern. Doch irgendwie kann ich der Zerlegung nicht freien Lauf lassen, wenn Blätter zwangsweise in Klassen übersetzt werden müssen.

Beim Funktionsplotter macht mir das noch keine Probleme. Scanner, Parser, Codegenerator sind umfangreich genug, um eine Übersetzung in Klassen zu rechtfertigen. Doch wie steht es mit einer Übersetzung einer Zeichenkette in ein Dictionary? Aus “a=1;b=2;…” soll ein Dictionary<string, string> werden.

Ein Softwaresystem könnte ich mir dafür so vorstellen:

Wenn ich´s jedoch genauer bedanke, dann lohnen eigene Klassen für die Blätter in dieser Holarchie nicht. SplitInfoPairs usw. sind so einfach, dass diese Funktionseinheiten als Methoden implementiert werden können. Das erkenne ich jedoch erst am Ende; während des Entwurfs habe ich mir darüber keine Gedanken gemacht, sondern das Gesamtproblem soweit in EBCs zerlegt, wie ich Ideen für die Verarbeitungsschritte hatte.

Wenn ein Problem vor Ihnen liegt, wissen Sie einfach nicht, wie tief Sie ein Lösungssystem schachteln können, ohne zu implementiere. Deshalb wissen Sie auch nicht, ob Sie am Ende nicht bei Funktionseinheiten ankommen, die im Grunde zu klein für eine Implementierung in eigenen Klassen sind.

Aber wie können EBC-Bauteile, also Blätter des Zerlegungsbaumes, genauso systematisch in Methoden überführt werden wie in Klassen? Bei Klassen sind die Übersetzungen von Input- und Output-Pins klar. Was entspricht denen aber bei Methoden?

Ich glaube, folgende Übersetzungen sind naheliegend:

Blätter, die in Methoden übersetzt werden sollen, haben nur 1 Input-Pin, aber beliebig viele Output-Pins. Der Input kommt als Parameter in die Methode, wie bei den Input-Pin-Methoden von Klassen-EBCs. Für den Output gibt es allerdings keine globalen Output-Pin-Delegaten; stattdessen werden die ebenfalls als Parameter hineingereicht.

Warum keine Übersetzung dieser Blatt-EBCs in Funktionen? Weil ein Rückgabewert pro Input-Nachricht nur einmal geliefert werden kann. Wenn ein Input jedoch n>1 oder n=0 Output-Werte erzeugen kann, dann ist deren Lieferung über einen Rückgabewert nur umständlich möglich.

Im Sinne einer systematischen Übersetzung bin ich deshalb dafür, kleine Blatt-EBCs immer in Methoden nach dem obigen Schema zu übersetzen. Das mag zunächst eine wenig umständlich erscheinen, doch ich denke, die Regelmäßigkeit und damit leichtere Verständlichkeit ist dafür eine Entschädigung. Denken Sie also nicht über die “beste” Übersetzung nach, sondern konzentrieren Sie sich auf die Ausfleischung der systematisch erzeugten Form.

Eine Ausnahme finde ich allerdings doch akzeptabel: Wenn eine Blatt-Funktionseinheit nur einen Output-Pin hat, kann sie als Funktion mit Rückgabewert IEnumerable<T> definiert werden. So sind auch n=0 und n>1 Rückgabewerte möglich.

Das eröffnet auch Möglichkeiten der Verkettung von EBC-Methoden mittels Linq.

Für Platinen bedeuten Methoden als EBCs natürlich eine Veränderung der Verdrahtung:

Die Verdrahtung bleibt beschränkt auf den Konstruktor. Deshalb leitet der Input-Pin der Platine die Nachricht weiter an einen Delegaten, der die eigentliche Methode “umwickelt”. Der Input-Pin weiß dadurch nichts von einem evtl. Output des Pins, an den er weiterleitet.

Dasselbe gilt für die Output-Pins, die an die Methoden übergeben werden. Auch das sind Delegaten, um dem Methoden-EBC Details über die Weiterverarbeitung seines Output zu verbergen.

Ob die Platine wie hier die Methoden-EBCs selbst implementiert und somit nicht mehr sauber nur verdrahtet, sondern auch Domänenfunktionalität implementiert, ist nicht so wichtig. Ich finde das erstmal ok. Aber Sie können natürlich auch die Methoden als Delegaten via ctor-Parameter injizieren. Oder Sie könnten eine Basisklasse definieren, die nur die Methoden-EBCs implementiert und die Platine davon ableiten.

Funktionseinheiten im Flow

Methoden-EBCs wie eben gezeigt zu verdrahten, ist simpel, aber etwas nervig. Die temporären Variablen für die Lambda Funktionen machen den Code unübersichtlich. Deshalb komme ich hier auf ein Thema zurück, dass ich schon früher hier im Blog am Wickel hatte: Flows.

Wenn Methoden-EBCs so regelmäßig gebaut sind, dann ist dafür auch etwas Toolunterstützung möglich. Hier meine Idee davon, wie ein Flow-API für EBCs die Verdrahtung von Methoden-EBCs erleichtern könnte. Statt die Methoden mit Hilfsvariablen und auch noch in umgekehrter Reihenfolge zusammenzustecken

public B2()
{
  Action<W> input_z = m => Z(m, this.Output);
  Action<V> input_y = m => Y(m, input_z);
  this.input_x = m => X(m, input_y);
}

könnten Sie sie in besser lesbarer Form verdrahten:

public B2()
{
    this.input_x = Flow
                     .StartWith<string, StringBuilder>(X)
                     .Then<int>(Y)
                     .Then<bool>(Z)
                     .Finally(b => this.Output(b));
}

Hier ist vor allem die Reihenfolge erhalten, so wie die Nachrichten durch die EBCs fließen, von X nach Y nach Z.

Die Implementation des APIs dafür sieht so aus:

public static class Flow

{

    public static Flow<TInput, TOutput> StartWith<TInput, TOutput>(Action<TInput, Action<TOutput>> stage)

    {

        return new Flow<TInput, TOutput>(GenerateInputPinFactory<TInput, TOutput>(stage));

    }

 

 

    internal static Func<Action<TOutput>, Action<TInput>> GenerateInputPinFactory<TInput, TOutput>(Action<TInput, Action<TOutput>> stage)

    {

        return outputPin => message => stage(message, outputPin);

    }

}

 

 

public class Flow<TInput, TOutput>

{

    private readonly Stack<Delegate> inputPinFactories;

 

 

    internal Flow(Delegate inputPinFactoryForStage)

    {

        this.inputPinFactories = new Stack<Delegate>();

        this.inputPinFactories.Push(inputPinFactoryForStage);

    }

 

    internal Flow(Stack<Delegate> inputPinFactories,

                  Delegate inputPinFactoryForStage)

    {

        this.inputPinFactories = inputPinFactories;

        this.inputPinFactories.Push(inputPinFactoryForStage);

    }

 

 

    public Flow<TInput, TNextOutput> Then<TNextOutput>(Action<TOutput, Action<TNextOutput>> stage)

    {

        return new Flow<TInput, TNextOutput>(this.inputPinFactories,

                                            Flow.GenerateInputPinFactory(stage));

    }

 

 

    public Action<TInput> Finally(Action<TOutput> stage)

    {

        Delegate inputPin = stage;

        while(this.inputPinFactories.Count() > 0)

        {

            Delegate inputPinFactory = this.inputPinFactories.Pop();

            inputPin = (Delegate)inputPinFactory.DynamicInvoke(inputPin);

        }

        return (Action<TInput>)inputPin;

    }

}

Mit jedem Do<>() wird eine Factory-Methode auf einen Stack gelegt. Diese Methoden erzeugen später die Input-Pin-Delegaten für die Methoden. Die wiederum werden an die nächste Factory-Methode übergeben. Das geschieht in der handgeschriebenen Version mittels der temporären Delegaten wie input_z.

Fazit

Ich denke, es spricht für EBCs, dass das Konzept sich auch auf Methoden ausdehnen lässt. Bei der Planung müssen Sie sich nicht beschränken. Wenn Sie fertig sind mit dem Architekturentwurf auf beliebig vielen Abstraktionsebenen des Lösungssystems, dann schauen Sie einfach, wie Sie die Blätter des Funktionseinheitenbaums implementieren. Für viele werden sich Klassen anbieten. Für manche aber sicherlich Methoden. Für Platinen-Klassen, Bauteil-Klassen und auch Bauteil-Methoden haben Sie nun Implementierungsregeln.

Ich finde das sehr beruhigend. Denn so kann ich mich einerseits auf den Entwurf konzentrieren; dabei muss ich nicht immer im Hinterkopf schon die Frage der Implementierung wälzen. Und andererseits kann ich mich bei der Implementierung auf die Domänenlogik konzentrieren, d.h. das Ausfleischen der Funktionseinheiten; ich muss mir den Kopf nicht über ihre Form zerbrechen.

Systematik und Regelmäßigkeit helfen, den Blick auf dem Wesentlichen zu halten. Mein Gefühl ist, davon brauchen wir mehr.

Geschichtet – Event-Based Components abstrahieren und kontrollieren

Das übliche Schichtenmodell der Architektur packt Code bildlich übereinander. Aber was bedeutet das? Sind damit Abstraktionsebenen gemeint wie beim OSI-Schichtenmodell? Oder ist damit eine Kontrollhierarchie gemeint, bei der das Presentation Layer das Business Logic Layer kontrolliert usw.? Eher wohl letzteres, denn das Presentation Layer ist abhängig vom Busines Logic Layer.

Vom Abstraktionsgrad sind im Schichtenmodell daher alle Schichten gleich. Ein Presentation Layer verbirgt nichts, macht nichts einfacher verständlich. Eine so strukturierte Anwendung verstehen Sie nur im Durchstich von der obersten bis zur untersten Schicht.

Das Schichtenmodell hat sich entschieden: Es steht für eine Schichtung entlang der Dimension “Kontrolle”. Mit ihm können Sie Abhängigkeiten innerhalb einer Ebene hübsch ausrichten. Das ist auch sehr wichtig, wenn Sie mit Injection-Based Components (IBC), d.h. “traditionellen” Komponenten arbeiten.

Mit Event-Based Components hingegen ist das anders. Damit können Sie ebenfalls Schichtenarchitekturen definieren – aber Sie können das in zwei Dimensionen. Indem Sie Platinen (boards) definieren und aufeinander stecken, beschreiben Sie ein Softwaresystem auf unterschiedlichen Abstraktionsniveaus:

Innerhalb einer Platine können Sie dann aber auch noch die üblichen Schichten bilden:

Beide Sichtweisen manifestieren sich mit EBCs natürlich im Code. Platinen dienen der Definition von Abstraktionsniveaus und die Verdrahtung auf einem Board sagt etwas über die Kontrollhierarchie innerhalb eines Boards aus.

EBCs trennen damit deutlich, was im Schichtenmodell oder allgemeiner im IBC-Paradigma vermischt ist: Abstraktion und Kontrolle. Abstraktion hat etwas mit Überblick zu tun. Kontrolle mit Einblick. Bei der Abstraktion geht es um den Betrachter, bei den Abhängigkeiten “den Prozessor”.

Damit sind wir beim nächsten Problem von Abhängigkeitsdiagrammen. Wenn es denn schon dabei um “den Prozessor” bzw. einen Prozess geht, dann wird der nicht verständlich dargestellt. Denn Abhängigkeiten sind statisch, da rührt sich nichts mehr. Ein Prozess jedoch “lebt”, da ist was in Bewegung. Daten wollen verarbeitet werden.

Auf einer Platine eines EBC-Diagramms geht es nun genau darum: um den Prozess. Die Verdrahtung von EBCs gibt an, wie Daten fließen. Abhängigkeiten existieren dafür zwischen den EBCs nicht. Nur der Prozess, d.h. die Platine ist von ihren Komponenten abhängig. Doch das ist keine Linie wert; diese Abhängigkeit ist natürlich und implizit. Im Vordergrund steht also der Prozess.

Gleichzeitig dienen EBC-Diagramme dem Betrachter bzw. Planer, weil sie ihm erlauben, ein System auf dem Level zu betrachten, das ihm gerade am meisten dient. Er bewegt sich mit einem frei gewählten Maßstab durch die Diagramme als Landkarten der Applikation. Die Regeln sind dabei – wie könnte es anders sein – auf jeder “Zoomstufe” gleich. Immer sind Komponenten mit Komponenten im Sinne eines Prozesses verdrahtet. Mal ist der Prozess sehr grob beschrieben, mal ist ein kleiner Ausschnitt des Prozesses sehr detailreich dargestellt.

Gedanken zu Gedanken zum TDD

Nach einer TDD-Demonstration bei der NUG Franken hat sich eine lebhafte Diskussion um einen kritischen Blog-Artikel von René Drescher-Hackel entsponnen. Das ist ein schöner Effekt der Demonstration und gut fürs Thema.

Zu einigen Punkten finde ich das Diskussionsergebnis allerdings noch unbefriedigend.

Darf´s ein bisschen mehr sein als Visual Studio? Aber sicher doch!

René hat sich über den scheinbaren Zwang von ReSharper mokiert. Ich stehe da auf einem anderen Standpunkt und finde nichts dabei, Unternehmen den Kauf von Tools zu empfehlen, auch wenn das Investitionen von 1.000, 5.000 oder gar 10.000 EUR bedeuten sollte. Unsere Branche ist so privilegiert und deshalb verwöhnt, was die Werkzeugkosten angeht im Vergleich zu Tischlern, Klempnern, Kirmesschaustellern, Ärzten usw., dass ich über solche Beträge nicht zweimal nachdenke.

Einen Entwickler ein Jahr lang jeden Arbeitstag auch nur 15 Minuten länger an einer Aufgabe sitzen zu lassen als nötig, ist so teuer, dass ein Tool wie ReSharper oder TestDriven.Net usw. sich schnell bezahlt macht. (Beispielrechnung: 60 EUR kostet der Entwickler/Stunde, er arbeitet 200 Tage im Jahr, dann entstehen 15 EUR*200=3.000 EUR Verlust pro Jahr dadurch, dass ihm ein Tool oder auch nur Kenntnise fehlen, die seine Arbeit um nur ca. 3% beschleunigen.)

René sagt:

Viele Unternehmen, die Software entwickeln sind Microsoft-Partner. Was dies wirtschaftlich für diese Unternehmen bedeutet, brauche ich hier nicht zu erklären. Du kannst aber nicht in einem Unternehmen auflaufen und TDD propagieren und gleichzeitig sagen, "wenn wir gescheit arbeiten wollen, dann brauchen wir...". Die Grunderwartung ist: was können wir mit den gegebenen Möglichkeiten tun?

Das kann ich nachvollziehen. Das ist eine “Grunderwartung” vieler Programmierbuden. Aber nur weil die Erwartung so ist, ist sie nicht “richtig” oder realistisch. Kinder haben auch viele Erwartungen, was die Weihnachtsgeschenke angeht – leider sind viele davon auch nicht realistisch.

Softwareentwicklung ist eben keine Sache mehr, die man mit Notepad und einem Kommandozeilencompiler bewältigen könnte. Das mag 1984 noch gegangen sein – aber heute nicht mehr. Der Arzt hat heute nicht mehr nur ein Messer oder einen Haken, um einen grauen Star zu stechen. Sein Gerät ist deutlich umfangreicher und teurer. Damit musste sich die Ärztezunft auch abfinden. Wir als Patienten freuen uns darüber und wollen es nicht mehr anders.

Wer meint, mit Visual Studio allein professionelle Softwareentwicklung betreiben zu können, der ist schon lange auf dem Holzweg. Sich auf Microsoft und Visual Studio zu verlassen, ist bequem. Es macht die Toolkosten planbar, die vor allem in einer MSDN Subscription bestehen oder in einem Update alle 2-3 Jahre. Doch seit wann lassen sich Fachleute von Controllern vorschreiben, was ihre Werkzeuge sein und kosten sollten?

Für mich ist also das, was René zu ReSharper gesagt hat viel weitgreifender. ReSharper war nur ein Stein des Anstoßes. Der Punkt ist jedoch allgemeiner. Es besteht eine merkwürdige Vorstellung davon, wie Produktivität in der Softwareentwicklung entsteht. Aber ich schweife ab… ;-)

Apokalyptischer Reiter Resignation

René sagt:

Dass der Softwareentwickler die Tests für sich im Kleinen macht, ist eher Wunschdenken bzw. der Idealfall. In den Firmen/Projekten, wo ich bislang tätig war, war dafür kein Platz. Und glaube mir Thomas, irgendwann gewöhnst du es dir ab, mit deinem Projektleiter/Vorgesetzen darüber zu diskutieren - so ist das ebend.

Für das, was richtig ist, ist kein Platz. Und wenn das so ist, dann nimmt man es hin.

Verständlich mag das sein. Aber traurig ist es, nein, tragisch und vor allem kontraproduktiv. Niemand hat etwas davon – außer demjenigen, der sich in die Resignation zurückzieht. Und der auch nur kurzzeitig, denn Resignation führt auf Dauer zu Schlimmerem.

Ich halte Resignation für einen Apokalyptischen Reiter für Softwareprojekte. Wo Resignation aufkeimt, erblühen und sich verbreiten kann, da scheitern Projekte. Resignation ist das Gegenteil von Motivation.

Was kann man dagegen tun?

Masterfrage: Braucht TDD (oder eine andere Veränderung) “Platz”? Ich würde sagen, nein. Oft braucht eine Veränderung keinen “Platz” im Sinne von “Darüber müssen wir alle einig sein” oder “Dafür muss extra Zeit veranschlagt werden”. Viele Veränderungen können nämlich einfach so vom Einzelnen vorgenommen werden. Man tut schlicht etwas anderes als bisher.

Ob ich nach einer Besprechung sofort an die Tastatur hechte und den Code-Colt ziehe oder neuerdings erstmal mit einem Block auf dem Tisch nachdenke… darüber muss ich mit niemandem reden.

Ob ich mit dem Code-Colt sofort aufs Ziel schieße oder erstmal einen Spike mache oder einen Test schreibe… darüber muss ich mit niemandem reden.

Ob ich die Pfadfinderregel befolge, meine Klassen nach SRP, SoC, LSP usw. anders schneide als früher… darüber muss ich mit niemandem reden.

Wer in seiner persönlichen Begeisterung gleich andere zu Proselyten machen will, der darf sich nicht wundern, wenn er auf Gegenwehr stößt. Resignation ist dann jedoch nicht die einzig mögliche Reaktion. Man kann zunächst auch einfach den Missionsdrang runterfahren und soviel wie möglich ohne Übereinstimmung mit anderen tun. Einfach unter dem Radar der Projektleitung fliegen.

Und wenn dann einer fragt, “Solltest du nicht lieber mal programmieren, statt wieder über deinem Block zu hocken?”, dann kann man ruhig auch mal die Vertrauensfrage stellen: “Vertrauen Sie mir nicht, wenn ich erst nachdenke und dann programmiere? Ist meine Leistung schlechter geworden?” (Und wenn darauf unwahrscheinlicherweise die Antwort “Ja!” kommt, dann kann man auch mal um die Messdaten bitten, die das belegen. )

Darüber, was es bedeutet, wenn man immer wieder gegen Wände läuft mit Vorschlägen für Veränderungen, will ich mich hier nicht weiter auslassen. Jeder muss für sich selbst entscheiden, ob das ein lohnenswertes Arbeitsumfeld ist, immer wieder in seiner Motivation, Vorgehen und Ergebnisse zu verbessern, frustriert zu werden. Ob längerfristige oder gar zunehmende Resignation gesundheitszuträglich sind, sollte man dann mal einen Arzt oder Apotheker fragen ;-)

Besser wird es schon, wenn man bei sich beginnt

René sagt:

Ich bin überzeugt davon, dass wenn du testgetrieben entwickeln willst, es nur wirklich sinnvoll ist, wenn im Team alle mitziehen - andernfalls sehe ich es als Kampf gegen Windmühlen. Die gleiche Situation hast mit den Fragen zum CCD.

Warum ist testgetriebene Entwicklung nur sinnvoll, wenn alle im Team mitziehen? Natürlich wäre das besser für das Produkt, weil dann mehr Code so entwickelt würde. Aber für mich als Entwickler ist das nicht wichtig. Ich kann meine Vorteile aus TDD schon ziehen, wenn ich allein damit anfange. Und der Kunde hat auch schon etwas davon, wenn nur ich so arbeite. Denn dann ist zumindest mein Code von höherer Qualität.

Darauf zu warten, dass eine Veränderung erst allgemein akzeptiert ist, um sie selbst vorzunehmen, ist frustrierend und unnötig. Für manche ist es nicht anders möglich, z.B. die Einführung einer verbindlichen Versionskontrolle für alle oder eine Continuous Integration. TDD gehört jedoch nicht in diese Gruppe. Wer etwas anderes behauptet betreibt Prokrastination durch “Schuldverschiebung”: “Die anderen sind Schuld, dass ich nicht nach TDD arbeiten kann.”

TDD kostet kein Geld, da kein Tool gekauft werden muss. NUnit ist gratis und reicht aus. TDD braucht keinen Konsens, da ich an den Codeteilen, die ich bearbeitet, nach TDD vorgehen kann.

Wenn andere sich darüber lustig machen, dann ist das deren Problem.

Entwickler sind keine Arbeitsbienen

René sagt:

Test sollten immer vom Architekten der vorgegeben werden. Der Entwickler (die Arbeitsbine also ;-) ) setzt die Software anhand des Tests um. So ist letztlich sichergestellt, dass die Software so funktioniert, wie der Architekt die Anforderung auch umgesetzt hat. Das ist meines Erachtens auch der tiefere Sinn der TDD.

Oha, das ist starker Tobak. Und das mir als Nichtraucher… ;-) Architekten sollen Tests vorgeben? Entwickler sind Arbeitsbienen?

Architekten sollen zwar die Nützlichkeit von Software sicherstellen worin ihre Korrektheit eingeschlossen ist. Doch dass Architekten deshalb Tests vorgeben sollten… nein, das halte ich für eine irrige Vorstellung.

Architekten sollen Entwickler und/oder Kunde helfen, angemessene Testszenarien zu formulieren. Sie sollen dem Kunden klar machen, wie wichtig es ist, dass er klare Vorstellungen von Korrektheit entwickelt und dokumentiert. Am besten in Form maschinenlesbarer Dokumente, die Testläufe treiben. Tools wie Fitness machen das möglich.

Und Architekten sollen den Entwickler im Rahmen eines expliziten Entwicklungsprozesses immer wieder über sein Verständnis der Anforderungen reflektieren lassen, aus dem heraus der dann weitere Testfälle formulieren kann. Dazu gehört auch, dass der Architekt TDD im Team einführt, falls noch nicht etabliert.

Doch Tests definiert der Architekt selbst nicht. Allerdings kann er vertreten, dass ausdrückliche semantische Kontrakte für bestimmte Funktionseinheiten formuliert werden, insbesondere wenn deren Entwicklung outsourcet ist.

Der “tiefere Sinn” von TDD ist eben nicht, dass Tests von irgendwoher kommen und der Entwickler nur krampfhaft versucht, die auf grün zu bringen. Nein, dem Entwickler dienen TDD-Tests über eine Korrektheitsprüfung hinaus zu…

• Ermittlung von Schwachstellen im Verständnis von Anforderungen und der Planung von Code
• angemessener Strukturierung nach SLA und SRP
• hoher Testabdeckung
• Dokumentation

TDD ist ein zentrales und unverzichtbares Entwicklungs- und Denkwerkzeug.

Und jetzt noch zur “Arbeitsbiene”. Das hat René nicht ganz ernst gemeint, aber ein wenig schon. Sonst hätte er nicht die Grenze zwischen Architekt und Entwickler so gezogen.

Dass solche Titulierung nicht zum Selbstbild von uns Softwareentwicklern gehört, ist klar. Ein solches Fremdbild mag es jedoch hier und da geben. “Ach, die klopfen doch nur Code ein.” Vielleicht ist es in manchen Projekten auch so. Und für Anfänger sind die Vorgaben sicherlich auch enger als für erfahrene Entwickler.

Am Ende könnte das Bild der “Arbeitsbiene”, d.h. eines Entwicklers, der in engen Vorgaben nur noch “runtercodiert”, nicht weiter von der Notwendigkeit entfernt sein. Entwickler dürfen keine “Arbeitsbienen” sein. Denn sobald sie das werden, bricht Software unter der Komplexitätslast zusammen.

Software ist so komplex, dass sie nicht einer vordenken kann. Weder im Hinblick auf die Umsetzung von Anforderungen, noch in Bezug auf Lösungsdetails in Algorithmen und Technologieeinsatz.

Softwareentwicklung braucht kooperative autonome Entwickler. Keine “Bienenköniginnen” oder gar “Drohnen” und keine “Arbeitsbienen”. Softwareentwickler sollten vielmehr innerhalb einem recht weiten architektonischen Rahmens viel Freiheit besitzen. Sie müssen fähig sein, lokale Probleme kreativ zu lösen. Und sie müssen fähig sein zu kommunizieren, was sie allein nicht lösen können, um es gemeinsam auf höherer Ebene zu lösen.

Holarchie – Event-Based Components für natürliche Softwaremodellierung

Software ist eine Holarchie, d.h. eine Hierarchie von Teilen, die gleichzeitig Ganzes sind. Das hatte ich während der Modellierung von Software mit “traditionellen” Komponenten schon fast wieder vergessen. Aber neulich schrieb mich jemand zu meiner Blogserie über das Softwareuniversum an, weil er Parallelen zu seiner Arbeit sah. Da habe dann versucht, meinen derzeitigen Ansatz der Event-Based Components (EBC) die damaligen Gedanken anzuschließen.

So sah 2005 eines meiner Diagramme für die grundsätzliche Struktur von Software aus:

Die Frage heute: Bin ich diesem “Ideal” nun mit EBCs ein Stück näher gekommen?  Ich will die Antwort anhand eines Beispiels versuchen, für das ich zwei Architekturen entwickle. Eine mit “traditionellen” Komponenten, eine mit EBCs.

Das Szenario ist simpel: Der Kunde wünscht sich einen Funktionsplotter. Er möchte also ein kleines Programm haben, in das er eine Formel eingeben kann – z.B. x^2+2x-3 oder Sqrt(Sin(x)*Cos(x)) –, für die dann ein Graph am Bildschirm geplottet wird.

Traditionelle Komponentenarchitektur

Wie hätte ich eine Architektur für den Funktionsplotter vor einigen Monaten geplant? Ich kann mich kaum erinnern ;-) EBCs haben sich schon so in meinem Denken breit gemacht, dass ich kaum noch ohne kann. Aber ich versuche es einmal.

Am Anfang stünde eine Softwarezellen bzw. ein System-Umwelt-Diagramm:

Eine Anwenderrolle greift auf die ganze Anwendung zu. Der Anwender ist abhängig von der Anwendung. Das System-Umwelt-Diagramm ist also ein Abhängigkeitsdiagramm.

Im nächsten Schritt würde ich die Softwarezelle zerlegen in Funktionseineiten. Nach dem Separation of Concerns Prinzip fielen mir da mindestens zwei ein: eine Funktionseinheit für die Interaktion mit der Benutzerrolle, ein Portal, und eine für den Rest, d.h. die Domänenlogik.

Bei genauerem Nachdenken würde ich dann natürlich das Portal weiter zerlegen. Eine eigene Funktionseinheit für das Plotten schiene mir angezeigt. Und auch die Logik zerfiele in mindestens zwei Funktionseinheiten:

Sollte ich es dabei bewenden lassen? Im Frontend ja. Aber die Logik… Nein, die ist noch zu grob. Ein Formelübersetzer ist – so nehme ich mal für dieses Beispiel an – keine so einfache Sache. Die will sauber in drei Pässe gegliedert sein. Es geht ja um nicht weniger als die Übersetzung von Quellcode (Formel) in Code (ausführbare Funktion). Da soll auch die kleine Plotteranwendung in puncto Systematik nicht hinter einem richtigen Compiler zurückstehen.

Und auch die vorgeschaltete Funktionseinheit scheint nicht sauber. Sie hat noch ein “und” in der Bezeichnung, sie tut also noch zweierlei. Zum einen veranlasst sie etwas (Übersetzung), zum anderen tut sie etwas (Funktionswerte berechnen). Das ist im Sinne des Single Responsibility Principle nicht schön.

Wenn ich diese Gedanken in die Architektur einfließen ließe, würde sie sich so weiter entwickeln:

Zwei Funktionseinheiten stechen darin heraus, das Rechenwerk und der Compiler. Beide haben eigentlich keine richtige Aufgabe im Sinne der Geschäftslogik. Sie sind nur Fassaden, die Details rechts von ihnen gegenüber ihren Clients verbergen. Allenfalls koordinieren sie noch die Arbeit der Funktionseinheiten, von denen sie abhängig sind. Das Rechenwerk lässt erst den Compiler die Formel übersetzen und übergibt sie dann an die Funktionswertberechnung. Der Compiler fordert zuerst den Scanner auf, die Formel in Symbole zu zerlegen. Die reicht er weiter an den Parser. Der erzeugt einen abstrakten Syntaxbaum, den der Codegenerator übersetzt.

Im Rahmen “traditioneller” Komponentenorientierung ist das völlig normal. Auf Rechenwerk und Compiler zu verzichten, würde nämlich zu ganz unschönen Abhängigkeiten führen, z.B.

Rechenwerk und Funktionswertberechnung hingen nun zusammen und würden nur den Parser ansteuern. Der lieferte ultimativ auch die übersetzte Funktion – aber natürlich nur unter Zuhilfenahme des Parsers, der wiederum den Codegenerator brauchte.

Nein, das sieht ungut aus. Warum soll ein Scanner den Parser kennen und am Ende sogar etwas mit dem generierten Code zu tun haben? Und warum sollte eine Funktionsberechnung einen Scanner kennen? Der ist ein Detail einer bestimmten Compilerimplementation.

Die Funktionseinheiten Rechenwerk und Compiler wären nötig in einer “traditionellen” Komponentenorientierung.

Und wo sind die Komponenten nun? Ich würde sagen, alle Funktionseinheiten verdienen es, als Komponenten realisiert zu werden. Z.B. Compiler, Scanner, Parser und Codegenerator in einer Komponente zusammen zu fassen, würde die Möglichkeit zur Parallelentwicklung begrenzen. Denn neben klaren Grenzen zwischen Funktionseinheiten geht es darum bei der Komponentenorientierung: hohe Produktivität, durch gleichzeitige Arbeit an Funktionseinheiten. Rechenwerk und Compiler sind dann zwar recht simple Komponenten, weil sie nur andere integrieren. Doch das macht nichts. Wenn sich z.B. der Ansatz zur Compilation ändert, dann kann wieder mehr Verantwortung in den Compiler wandern. Ihn als Verantwortlichkeit ausdrücklich zu definieren, trägt zur Evolvierbarkeit bei.

Fazit “traditionelle” Komponentenarchitektur

Was gibt es hervorzuheben an einer “traditionellen” komponentenorientierten Architektur? Was gibt es womöglich zu kritisieren? Das ist gar nicht so leicht zu sagen, wenn man tief drin steckt in dem Denken. Denn dann ist vieles ganz natürlich – was eigentlich Ballast ist. Und was fehlt, erkennt man nicht so genau.

In meinem ersten Posting zu EBCs habe ich fünf Aspekte “traditioneller” Komponenten genannt, mit denen ich mich schwer tue. Für das obige Beispiel möchte ich drei davon herausgreifen:

• Komponenten haben Abhängigkeiten. Abhängigkeiten machen das Entwicklerleben schwer. Wo Abhängigkeiten ins Spiel kommen, wird allemal das Testen schwieriger.
• Spezifikationen sind nicht kompakt. Die Spezifikation des Compilers besteht z.B. aus seinem eigenen exportierten Kontrakt sowie den importierten Kontrakten der drei Komponenten, von denen er abhängig ist.
• Die Schachtelung von Komponenten ist schwierig oder gar unmöglich.

Insbesondere die letzten beiden Punkte machen mich bei der obigen Architektur unglücklich. Ich finde es sehr unhandlich, einen Compiler nur implementieren zu können, wenn ich insgesamt vier Kontrakte zur Hand habe. Und warum sollte eine Client-Komponente den ganzen Kontrakt einer Service-Komponente kennen, wenn sie selbst davon nur einen Ausschnitt selbst braucht? Wer ist schon so konsequent und betreibt Interface Segregation, um jedem “Kunden” einer Service-Komponente nur den für ihn passenden Ausschnitt zur Verfügung zu stellen?

Viel schlimmer aber noch ist, dass die finale Architektur nur noch eine Abstraktionsebene im Code enthält. Die Komponenten liegen alle auf demselben Niveau. Ein Betrachter des Codes hat damit keine Möglichkeit, unterschiedliche Betrachtungsabstände einzunehmen, um sich Überblick zu verschaffen oder Details zu betrachten.

Zwar habe ich mich in mehreren Schritten an diese “Blattebene” herangeschlichen. Doch die Funktionseinheiten auf darüber liegenden Abstraktionsniveaus sind nicht mehr sichtbar. Sie existieren nur noch auf einem Blatt Papier – und das ist bekanntlich geduldig.

Aber vielleicht sehen Sie es auch anders und meinen, die Architektur würde immer noch mehrere Abstraktionsebenen enthalten. Scanner, Parser und Codegenerator gehören dann zur untersten Ebene, Compiler liegt darüber und mit der Funktionswertberechnung gleich auf. Darüber dann das Rechenwerk, darüber das GUI. Ja, so könnte man das sehen:

Aber ist das wirklich plausibel und hilfreich? Liegt ein GUI auf einem höheren Abstraktionsniveau als ein Compiler? Ist das Abstraktionsniveau von einem Aufgabenbereich oder gar Belang abhängig? Nein, nein, damit kann ich mich gar nicht anfreunden. Außerdem würde das bedeuten, dass Kommunikation nie zwischen Funktionseinheiten auf demselben Abstraktionsniveau abliefe, sondern immer über Niveaus hinweg: der Compiler auf Level n spräche mit dem Scanner auf Level n+1 usw.

Das fühlt sich gar nicht gut an.

Abhängigkeiten definieren einen Baum. Entlang der Äste verläuft die Kommunikation. Schwer verständliche Schachtelung ist damit das Fundament der “traditionellen” Komponentenorientierung. Grauslich! Da hilft dann auch keine Dependency Injection.

Das führt übrigens auch dazu, dass so sinnlose Komponenten wie der Compiler oder das Rechenwerk auftauchen. Die tun nichts anderes, als die Kommunikation zwischen anderen Komponenten zu ermöglichen. Vom Standpunkt der Domänenlogik aus gesehen ist das nicht nötig. Aber die vertikalen Abhängigkeiten erzwingen das. Scanner, Parser und Compiler liegen auf demselben Abstraktionsniveau – und kennen sich daher nicht. Widersinnig, oder? Und wenn sie sich kennen wie in der verworfenen Architektur, dann ist das auch nicht glücklich. Denn warum sollte ein Scanner von einem Parser abhängen? Oder von mir aus auch umgekehrt: Warum sollte ein Codegenerator von einem Parser abhängen und der von einem Scanner?

Ein Codegenerator leistet etwas auf einem Input: er verwandelt einen Abstrakten Syntaxbaum (AST) in lauffähigen Code. Diese Leistung hat nichts, aber auch gar nichts mit der Erzeugung eines solchen AST zu tun. Warum sollte also ein Codegenerator die anstoßen?

Also muss ein übergeordneter Compiler her. Der tut nichts anderes, als die Kommunikation zwischen Scanner, Parser und Codegenerator angemessen herzustellen. Aber er ist eine Komponente mit vielen Abhängigkeiten. Er ist vergleichsweise schwierig zu testen und dabei so gar nicht durch die Problemdomäne motiviert. Eine unbefriedigende Situation. Koordinationskomponenten verrauschen das Architekturbild.

Ein Abhängigkeitsdiagramm ist einfach nicht genug, um eine Architektur zu beschreiben. Es ist nötig, um die vielen Kontrakte klar zu kriegen und die Abhängigkeiten sauber zu definieren. Aber wie die Kommunikation läuft, ist daraus nicht ersichtlich. Dafür brauchen wir mindestens einen zweiten Diagrammtyp. Z.B. ein Aktivitätsdiagramm oder ein Datenflussdiagramm müssen die Lücke füllen.

Meine bottom line: Eine unbefriedigende Situation. “Traditionelle” Komponenten sind besser als gar keine Komponenten. Sie befördern die Produktivität, die Flexibilität und die Korrektheit. Doch es bleibt ein Nachgeschmack.

Event-Based Component Architektur

Wie kann es mit der Architektur besser werden als mit “traditionellen” Komponenten? Ich versuche dasselbe Szenario mal mit Event-Based Components (EBC) zu beschreiben. Am Anfang steht wieder ein Systen-Umwelt Diagramm:

Das sieht der “traditionellen” Komponentenorientierung noch sehr ähnlich. Allerdings: Beachten Sie, dass auch hier schon von Nachrichten gesprochen wird und keine Abhängigkeit vorhanden sind. Die Anwendung als ganzes wird als Komponente gesehen, die asynchron gegenüber ihrer Umgebung läuft.

Das System-Umwelt Diagramm ist die höchste Abstraktionsstufe. Es besteht ja nur aus einer Funktionseinheit. Diese Funktionseinheit ist natürlich zu groß, um sie einfach so zu implementieren. Also muss ich sie zerlegen.

Wenn ich die Applikation “aufmache”, dann finde ich zwei Funktionseinheiten: ein Frontend für die Interaktion mit dem Benutzer und ein Rechenwerk, dass die Formel im angegebenen Wertebereich berechnet. Das ist immer noch eine Ebene, die ein Laie versteht. Eine Benutzeroberfläche ist etwas anderes als die Funktionalität, die Formeln berechnet.

Im Hintergrund habe ich noch die darüber liegende Hierarchieebene “durchscheinen lassen”. Sie soll uns erinnern, dass die beiden Funktionseinheiten Verfeinerungen sind.

Jetzt zur nächsten Ebene hinab steigen:

Jede Funktionseinheit der vorherigen Ebene ist verfeinert worden, d.h. zerlegt in mehrere Funktionseinheiten mit spezifischeren Verantwortungen. Diese Subfunktionseinheiten sind den übergeordneten eingeschrieben. Funktionseinheiten können also Container sein. Nicht physische Container, sondern logische, sozusagen “Verantwortungscontainer”.

Das ist ein Aspekt, der mir wichtig geworden ist. Mit EBCs ist echte Schachtelung möglich. Aber das ist keine physische Schachtelung. Wie Implementierungen von Funktionseinheiten physisch geschachtelt sind, halte ich inzwischen für einen ganz anderen Concern. Darüber muss man nachdenken – aber es hat nichts mit der Funktionalität einer Anwendung zu tun. Wie Funktionseinheiten physisch versammelt und geschachtelt werden, ist eine Sache des Entwicklungsprozesses. Darauf wirken vor allem Fragen der Parallelität von Entwicklung, von Risiko, Unsicherheit oder Komplexität/Entwicklungsdauer ein.

Aber nun weiter mit der Modellierung. Das Frontend ist abgeschlossen, doch beim Rechenwerk muss der Compiler noch zerlegt werden:

 

In dieser Abbildung sind nun alle Abstraktionsebenen ganz natürlich ineinander geschachtelt zu sehen. Je dunkler eine Komponente, desto niedriger ihr Abstraktionsniveau. Echte Domänenfunktionalität enthalten nur die Blätter, d.h. die Funktionseinheiten mit dem niedrigsten Abstraktionsniveau.

Der Schachtelungsbaum dazu sieht so aus:

Abhängigkeiten verlaufen in der Vertikalen. Sie sind im Architekturdiagramm implizit. Wenn Komponenten andere enthalten, dann sind sie von ihnen abhängig. Wichtiger ist jedoch, dass die Kommunikation hier horizontal verläuft. Das Architekturdiagramm legt den Schwerpunkt nicht auf Abhängigkeiten, sondern darauf, wie die Funktionseinheiten miteinander kommunizieren.

Wo bei “traditionellen” Komponenten zwei Diagramme nötig sind, reicht bei EBCs ein Diagramm.

Fazit Event-Based Component Architektur

Vergleichen Sie selbst die Diagramme für die “traditionelle” Komponentenarchitektur und die EBC-Architektur. Welches finden Sie aussagekräftiger, verständlicher?

Die Vorteile der EBC-Architektur scheinen mir auf der Hand zu liegen:

• Der Fokus liegt hier ganz eindeutig auf den Blättern. In denen “spielt die Musik”, dort steckt die Domänenlogik, sie mögen komplex sein. Aber sie haben keine Abhängigkeiten. Deshalb sind sie gut zu testen. Und deshalb lassen sie sich auch vergleichsweise gut wiederverwenden.
• Abhängig sind “Zwischenebenen” oder “Platinen”. Sie sind von den eingeschachtelten Funktionseinheiten abhängig. Aber das macht nichts. Diese Abhängigkeiten sind sehr einfach. “Platinen” lassen sich aus der Beschreibung der Verbindungen zwischen ihren “Bauteilen” generieren. Das macht ihre Tests sehr einfach.
• Die Abhängigkeiten sind implizit. Sie verwirren nicht das Verständnis. Die wichtigeren Kommunikationswege stehen im Vordergrund. Die Kommunikation ist horizontal zwischen Funktionseinheiten innerhalb eines “Containers” auf derselben Abstraktionsebene.
• Last but not least: Die Ebenen, die eine schrittweise Verfeinerung durchläuft, bleiben in der Architektur physisch, d.h. in Form von Artefakten (“Platinen”) erhalten. Das trägt sehr zum Verständnis der Architektur bei. Zoom-in/out ist nicht nur möglich, sondern bezieht sich auf realen Code und nicht nur “Ideen”.

EBC-Architekturen manifestieren für mich die konzeptionelle Holarchie des ersten Bildes oben. Software ist ein System mit beliebig vielen Ebenen. Auf jeder Ebene arbeiten beliebig viele Funktionseinheiten zusammen. Aus Input produzieren sie Output. Sie kennen einander nicht und sind ganz regelmäßig aufgebaut. Das erleichtert ihre Produktion (“Platinen” können generiert werden, Blätter werden parallel handcodiert). Das erleichtert die Komposition von Architektur mit ihnen. Und das ermöglicht den Einsatz von Standardkomponenten.

Nach meinem Empfinden sind wir mit EBCs der lang erprobten Arbeitsweise von Elektrotechnikern und Maschinenbauern so nah wie nie zuvor. Software ist natürlich immer noch anders als physische Bauteile; aber warum soll sie nicht von denen lernen?

Ich jedenfalls kann quasi schon gar nicht mehr anders denken als in EBCs. Und mit jeder Architektur, die ich so entwerfe, wird es einfacher.

Mit EBCs sehe ich Software als Sammlung von Prozessen. Einfachen und komplizierten. Die bestehen aus Verantwortlichkeiten, die zusammen etwas verarbeiten und produzieren. Diese Verantwortlichkeiten und ihre Kooperation beschreiben EBCs.

Objekte und “traditionelle” Komponenten werden dadurch nicht überflüssig. Sie bekommen aber einen anderen Platz. Auch das macht die Architektur einfacher.

Verfeinerung der EBC-Architektur

Zum Schluss noch ein Detail, über das Sie sich keine Gedanken gemacht haben mögen. In der EBC-Architektur ist noch eine kleine Unstimmigkeit, die ich der Einfachheit halber bisher überspielt habe. In das Rechenwerk kommt eine Berechnungsanforderung rein. Die besteht aus einer Formel und einem Wertebereich, auf den die Formel angewandt werden soll, z.B. Formel “2*x” und Wertebereich 0 bis 10 in 100 Schritten.

Durch die Blätter des Rechenwerks fließt bisher nur ein Datenstrom. Das bedeutet, jede Funktionseinheit muss den Wertebereich bis zur Funktionswertberechnung durch schleifen. Was aber soll z.B. ein Scanner mit diesem Wertebereich?

Die Architektur für das Rechenwerk sähe daher besser wie folgt aus:

Split und Join sind Standard-EBCs. Sie werden in den Nachrichtenstrom eingesetzt, um Nachrichten zu transformieren und damit passend für folgende Funktionseinheiten zu machen. Das erhöht die composability (Komponierbarkeit) von Architekturen. Funktionseinheiten können leichter wiederverwendet werden, wenn sie ihren Kontrakt nicht an ihre Umgebung anpassen müssen, sondern umgekehrt kleine Standardadapter die Umgebung an eine Komponente anpassen.

Hier noch zwei Ideen, wie solche Standardkomponenten helfen könnten:

Zunächst: Bemerken Sie, wie einfach es ist, die Flughöhe zu wechseln? Im vorhergehenden Bild waren wir im Rechenwerk. Jetzt ist das Rechenwerk eine Black Box; wir fliegen höher, sehen ein bigger picture. Das Abstraktionsniveau ist gestiegen.

Auf diesem Level habe ich nun Standardkomponenten eingefügt, die die Performance und Reaktionsfähigkeit des Systems steigern sollen. Ein Cache ist zwischen Frontend und Rechenwerk geschaltet, um zu vermeiden, dass Übersetzungen und Berechnungen, die schon gelaufen sind, nochmal zeitaufwändig ausgeführt werden. Für das Frontend macht dieser Einschub keinen Unterschied. Es ist ja unabhängig von anderen Komponenten. Und auch das Rechenwerk merk davon nichts. Das ist AOP at its best ;-)

Dasselbe gilt für die Asynchronizität. Das Rechenwerk läuft nun auf einem anderen Thread als das Frontend. Berechnungen finden dem gegenüber also im Hintergrund und asynchron statt. Der Benutzer kann im Frontend andere Funktionen aufrufen, während das Rechenwerk seine Arbeit leistet. Das Frontend friert nicht ein.

Falls im Hintergrund ein Fehler auftritt, wird der als eigene Nachricht auf dem Frontend-Thread zurück gemeldet. Und Ergebnisse kommen auch auf dessen Thread an, weil sie ein Synchronization Context Switch aus dem Hintergrund in den Vordergrund holt.

Fühlen Sie die Eleganz des EBC-Ansatzes? Keine der Komponenten kennt/braucht eine andere. Die Verbesserung der nicht funktionalen Eigenschaften des Systems waren deklarativ ohne Veränderung auch nur einer existierenden Komponente möglich.

Und falls sich herausstellt, dass die Kombination Cache+Async öfter nützlich ist, kann sie ganz einfach mit einer “Platine” für die Wiederverwendung zu einer neuen Komponente zusammengeschnürt werden:

Wieder würde sich für die anderen Komponenten nichts ändern. Nur die Verdrahtung wäre betroffen, d.h. die “Platine”, die die Komponenten verbindet. Mit einem Architekturtool wäre das aber wohl nur eine Kleinigkeit. Eine simple und typische Refaktorisierung, z.B. “Komponenten zu Platine zusammenfassen”.

Im Sinne des SLA-Prinzips würde ich dann jedoch noch einen Schritt weitergehen:

Jetzt ist wieder alles auf demselben Abstraktionsniveau: ein Frontend ist verbunden mit einem Rechenwerk. Wie das genau funktioniert, ist egal. Wen das interessiert, der zoomt in das asynchrone Rechenwerk hinein.

Irgendwie geht das alles natürlich auch mit “traditionellen” Komponenten. Aber elegant finde ich es nicht mehr. Warum sollte ich mir auch nur eine Sekunde lang Gedanken über Abhängigkeiten machen? Warum sollte ich mir eine Sekunde lang Gedanken über die Größe von Interfaces machen?

Ob eine EBC-Komponente “zu groß” ist, sehe ich in einer EBC-Architektur viel leichter als in einer “traditionellen”. Ich muss nur die Input-/Output-Pins zählen. Die geben viel detailliertere und sichtbarere Auskunft über die Verantwortlichkeitsbreite einer Komponente, als ein simpler Pfeil in einem Abhängigkeitsdiagramm.

So, nun aber genug für heute. Lassen Sie sich die Diagramme einmal auf der Zunge zergehen. Ich hoffe, Sie schmecken es, wieviel einfacher, regelmäßiger, verständlicher echt holarchische Software mit EBCs sein kann.

Architekten programmieren nicht [OOP 2010]

Habe ich Ihre Aufmerksamkeit? Architekten programmieren nicht, ja das glaube ich – und stehe damit wohl gegen den (agilen?) Mainstream. Aber etwas “Gegenstrom” macht frisch und kregel ;-)

Wer etwas auf sich hält, sagt mal etwas zur Rolle des Architekten. Nach Lektüre eines weiteren Artikels von Neal Ford habe ich mir gedacht, darin sollte ich anderen nicht nachstehen. Also hier mal einige Gedanken zur Aufgabe des Architekten in der Softwareentwicklung.

Architekt als Rolle

Zunächst: Architekt ist für mich eine Rolle. Das ist ganz wichtig. Denn sonst wäre es unmöglich, dass sich kleinere Projekte einen Architekten leisten könnten. Idealerweise nimmt dann ein Projektbeteiligter (oder eine kleine Gruppe) die Rolle des Architekten ausschließlich ein – doch das ist eben nicht immer möglich. Also kann in kleinen Teams dieselbe Person sowohl Architekt wie noch etwas anderes sein.

Architekt als Schnittstellenfunktion

In Übereinstimmung mit vielen anderen bin ich sicher auch noch, wenn ich den Architekten als eine Person an der Schnittstelle zwischen anderen Projektbeteiligten sehe. Der Architekt ist insofern ein Übersetzer. Er hat Kontakt mit dem Kunden. Er muss mit der Projektleitung auf Augenhöhe sprechen. Er ist ein wichtiger technischer Ansprechpartner für das Entwicklerteam.

Ein Architekt muss daher ein gerüttelt Maß an Softskills besitzen. Er ist in ständigen Gesprächen und Verhandlungen. Er muss immer wieder auf dem Verständnisniveau seiner Gesprächspartner erklären. Er muss gut zuhören können. Er muss vermitteln/moderieren können. Und er braucht auch Durchsetzungskraft.

Architektur von Systemen von Funktionseinheiten

Ein Architekt hat aber natürlich nicht nur mit Menschen zu tun. Sein Metier ist die Software. Und da dreht sich seine Verantwortung ganz allgemein darum, Systeme von Funktionseinheiten zu entwerfen. Ja, genau so allgemeine denke ich das. Eine Funktionseinheit kann ein Betriebssystem Prozess (oder EXE) sein, das kann eine Maschine sein oder eine ganze Anwendung oder ein Cluster. In jedem Fall geht es um “Bausteine”, die Software sind oder Software ermöglichen, die zusammengeschaltet einen Kundennutzen bieten.

So allgemein möchte ich die Definition halten, um der ewigen Diskussion, was denn der Unterschied zwischen Application Architect und Enterprise Architect usw. sei, aus dem Weg zu gehen. Das sind einfach alles Architekten, die mit dem Entwurf von Funktionseinheiten zu tun haben, die nur eben auf unterschiedlichen Abstraktionsebenen liegen. Die Prinzipien sind jedoch auf allen Ebenen eher mehr als weniger gleich. Flexibilität und Effizienz müssen auch immer in Balance gehalten werden.

Und wenn Sie daraus jetzt lesen, dass dann doch jeder Entwickler auch Architekt sei, weil er Funktionseinheiten plane (allemal Klassen und Methoden), dann haben Sie Recht. Jeder Entwickler ist auch immer auf einer gewissen Ebene Architekt. (Manche nennen dann das, was er plant, Design statt Architektur, aber den Unterschied möchte ich grad mal vernachlässigen.)

Architektur als Abstraktion

Architekten gehen mit Funktionseinheiten um, Entwickler auch. Wo ist dann der Unterschied zwischen beiden?

Architekten planen, Entwickler bauen.

Das ist der entscheidende Unterschied. Er liegt wieder mal im Abstraktionsniveau. Architekten haben Überblick, Entwickler Detailblick. Architekten stehen auf einem Hügel und entwickeln Strategien, Entwickler führen aus.

Eine solche Aufgabenteilung halte ich für absolut natürlich und naheliegend. Führung und Ausführung sind zwei ganz unterschiedliche Tätigkeiten. Sozusagen unterschiedliche concerns der Softwareentwicklung.

Ein Dirigent führt ein Orchester, ein Musik spielt darin ein Instrument. Das heißt nicht, dass ein Dirigent kein Instrument spielen müsse. Im Gegenteil! Dirigenten sind immer ausgewiesene Instrumentalisten sogar auf mehreren Instrumenten. Aber während ein Dirigent dirigiert, spielt er (gewöhnlich) keines seiner Instrumente.

Daraus leite ich auch ab, dass ein Architekt eben nicht programmieren sollte. Zumindest nicht in dem Projekt, für das er Architekt ist. Das wäre ein Widerspruch zum Prinzip der Separation of Concerns, das auch auf Organisationen angewandt werden sollte.

Ein Architekt soll technisch absolut fit sein. Keine Frage! Er muss sich fit halten, er muss dem Team, das seine Architektur technisch auf Augenhöhe begegnen, er muss Erfahrung im Einsatz von Technologien haben, damit er sie planen kann. Dazu braucht es Praxis, Praxis, Praxis. Aber diese Praxis sollte ein Architekt sich nicht (!) in dem Projekt holen, in dem er Architekt ist.

Er mag im Pair Programming mit Entwicklern arbeiten – aber nicht als Driver. Er  mag Spikes entwickeln, um eine Architekturvision abzuklopfen. Er soll natürlich in Reviews eine sehr aktive Rolle spielen. Aber von Produktionscode sollte er die Hände lassen.

Der Grund ist ganz einfach: Wenn der Architekt seine Hände im Produktionscode schmutzig macht, gewinnt er soviel Detailwissen, verstrickt er sich so sehr im Tagesgeschäft, dass er seine Aufgabe als derjenige, der Überblick behält, nicht mehr erfüllen kann. Denn Überblick, Weitblick, Strategie: darum geht es bei Architektur. Bezogen auf die Abstraktionsebene soll der Architekt die Interessen des Großen Ganzen vertreten. Dazu braucht es jedoch Distanz von den nitty gritty details.

Architekt als Bewahrer

Und was ist das Große Ganze, für das der Architekt verantwortlich ist? Was ist das Ergebnis seiner Schnittstellenfunktion? Er grenzt sich zunächst von Projektmanagement oder auch einem ScrumMaster und ProductOwner ab, die auch das Große Ganze im Blick haben. Aber ganz untechnisch. Deren Interesse ist es, dass es voran geht. Die wollen nicht unter die Haube der Benutzeroberfläche einer Anwendung schauen. “Muss laufen!” ist ihr Credo. (Wobei der ScrumMaster sogar noch weniger Anspruch hat. Ihm geht es nur darum, dass das Vorgehensmodell korrekt gelebt wird. Wohin damit dann gegangen wird, ist ihm eigentlich egal.)

Der Architekt ist also der technische “Großverantwortliche”. Er muss den Einsatz von Technik und technischen Konzepten so planen, dass sie die Kundenwünsche erfüllt. Er wie die anderen ist er dabei selbstverständlich dem Zeit- und Kostenrahmen verpflichtet.

Konkret ist die Aufgabe des Architekten, dass die folgenden Aspekte von Software im Sinne des Kunden ausgeprägt und in Balance sind:

• Nützlichkeit
• Benutzbarkeit
• Belastbarkeit
• Evolvierbarkeit

Zu dieser Liste hat mich die Alte Definition von (Bau)Architektur in Wikipedia inspiriert. Nach der beruht Architektur auf drei Prinzipien: Stabilität, Nützlichkeit und Anmut (firmitas, utilitas, venustas).

Software ist kein Bauwerk. Also geht es bei Softwarearchitektur auch um anderes als Bauarchitektur. Dennoch glaube ich daran, dass Softwarearchitektur genauso scharf definiert werden sollte. Diese Aspekte scheinen mir das so zu leisten, dass keiner wegfallen darf und keiner mehr dazu kommen muss. (Oder habe ich eine –keit übersehen?)

Nützlichkeit: Software hat nur einen Zweck: Dem Kunden zu nutzen nach seinen Anforderungen. Das technisch sicherzustellen, ist die vornehmste Aufgabe des Architekten. Software die nicht nutzt, ist ihr Geld nicht wert. Nützlichkeit ist hergestellt, wenn die funktionalen Anforderungen wie auch nicht funktionale Anforderungen erfüllt sind. Nur wenn die Software tut, was sie tun soll, wenn sie das schnell genug tut und sicher genug usw., dann nützt sie. Darauf ist das System der Funktionseinheiten und die Nutzung von Technologien auszurichten.

Benutzbarkeit: Alle Nützlichkeit nützt nichts, wenn sie dem Anwender nur schwer zugänglich oder verständlich ist. Den Architekten sehe ich daher – vielleicht etwas untypisch – in der Verantwortung, die Usability im Blick zu behalten. Er muss das Team immer wieder dazu anhalten, Funktionalität nicht nur irgendwie auf die Straße zu bringen, sondern in einer Weise, dass sie dem Anwender auch “ohne Verrenkungen” zur Verfügung steht. Dem Kunden (ProductOwner) kann es nicht überlassen werden, schon bei der Anforderungsdarlegung oder durch Nörgeln beim Test von Releases Usability einzufordern. Die Softwareentwicklung selbst muss davon eine Vision haben – und die vertritt der Architekt.

Belastbarkeit: Software läuft nicht immer nur in Schönwetter. Benutzerzahlen steigen ungeplant, Datenvolumina nehmen unerwartet zu, Angreifer suchen nach Schlupflöchern, Anwender gehen unsachgemäß mit ihr um, Hardware fällt aus… Software ist vielen Belastungen diesseits und jenseits expliziter Kundenanforderungen ausgesetzt. Der Architekt muss das voraussehen und seine Planung angemessen darauf abstellen. Er  muss Toleranzen “einrechnen” und Spielräume schaffen. Dazu ist natürlich Erfahrung nötig – aber keine Glaskugel ;-) Belastbarkeit bedeutet, dass Software ihre Nützlichkeit auch über die unmittelbaren Anforderungen hinaus behält oder mit wenig Aufwand wiedergewinnen kann.

Evolierbarkeit: Zuguterletzt ist der Architekt dafür zuständig, über die Anforderungen des Kunden heute hinaus zu sehen. Zumindest er muss das Verständnis haben, dass Software sich ständig wandelt und daher eine Struktur haben muss, die sich an solchen Wandel immer wieder leicht anpassen lässt. Ein Architekt kennt den Kunden insofern besser als der sich selbst ;-) Auch wenn der Kunde meint, alle Wünsche geäußert zu haben, weiß der Architekt, dass das hochwahrscheinlich nicht der Fall ist – und muss seine Architektur (angemessen) flexibel halten. Software soll dem Kunden nicht nur heute dienen, sondern auch morgen und übermorgen. Evolvierbarkeit ist die Bedingung für die Möglichkeit zukünftiger Nützlichkeit.

Zur Evolvierbarkeit gehört auch, dass Veränderungen nicht nur möglich sind, sondern das auch mit vertretbarem Aufwand. Allemal hier schwingt also auch die Produktionseffizienz als Aspekt mit. Speziell herausgehoben habe ich sie jedoch nicht, da sie ansonsten der allgemeinen Verantwortung des Architekten unterliegt, der – wie die anderen Projektverantwortlichen auch – darauf achtet, dass mit Zeit und Geld sorgsam umgegangen wird.

Und ein Wort noch zur Korrektheit: Nützlichkeit schließt Korrektheit ein. Deshalb habe ich die Korrektheit nicht in dieser Verantwortlichkeitsliste ausdrücklich aufgeführt. Sie ist so grundlegend, dass sie eigentlich keiner Erwähnung bedarf. Ohne die Möglichkeit, Korrektheit jeder Funktionseinheit “auf Zuruf” belegen (oder zumindest überprüfen) zu können, ist das Ergebnis der Planung eines Architekten nicht wirklich Architektur zu nennen. Nützlichkeit und Evolvierbarkeit sind ohne Korrektheit bzw. ihre ständige systematische und damit automatisierte Prüfung nicht denkbar.

Der Architekt plant eine Software, d.h. ein System aus Funktionseinheiten, so, dass die Aspekte Nützlichkeit, Benutzbarkeit, Belastbarkeit und Evolvierbarkeit im Sinne absehbarer Kundenanforderungen ausbalanciert sind. Das ist keine leichte Aufgabe. Sie erfordert viel Erfahrung und technisches Know-How.

Vor allem erfordert sie aber eben ein strategisches Denken, das sich nicht gemein machen darf mit Codierungsdetails. Deshalb glaube ich ganz fest, dass ein Architekt nicht in seinem Architekturprojekt programmieren sollte. Er verliert sonst die Distanz, die nötig ist, um sich für diese vier wichtigen Aspekte gegen den Druck zu stemmen, den unweigerlich Projektmanagement, Kunde und Team auf ihn ausüben.

Call for Papers: prio.conference – Verteilte Architektur

Am 19. und 20. Oktober 2010 ist es wieder soweit: Die prio.conference (www.prioconference.de) widmet sich einem Thema, das viele Entwickler bewegt. In diesem Jahr ist das “Verteilte Architektur”.

Wie in den Vorjahren bin ich Technical Chair und suche spannende, wegweisende, lehrreiche Vorträge. Wer seine Erfahrung zum Thema “Verteilte Architektur” weitergeben möchte oder jemanden kennt, der etwas zu sagen hat, der melde sich per Email an techchair (at) prioconference.de.

Der offizielle Call for Papers ist hier: http://www.prioconference.de/Call-for-Papers

Ich bin gespannt auf Ihre Einreichungen…