Mittwoch, März 28, 2007

Was ist Software-Architektur?



Was ist Software-Architektur? Wenn Sie nach einer Definition im Internet recherchieren, werden Sie auf eine Unmenge von Vorschlägen stoßen. Wenngleich kein vollkommener Konsens besteht, so findet die Definition von Bass et al. (Software Architecture in Practice, 2nd Ed., Addison-Wesley, 2003) offenbar den meisten Anklag. In der deutschsprachigen Literatur zum Thema wird sie auch gerne herangezogen.

The software architecture of a program or computing system is the structure or structures of the system, which comprises software elements, the externally visible properties of those elements, and the relationships among them.

Ich halte diese Definition für zu kurz gegriffen -- Sie stimmt nicht mit meinen Erfahrungen aus der Praxis überein. Architektur hat nach meinem Verständnis sehr viel mit Ökonomie zu tun.

Die Architektur ist die ökonomischste Form der Beschreibung "innerer" Anforderungen, die nicht mit der Implementierung des Systems identisch ist.

Unter den "inneren" Anforderungen verstehe ich alle Maßgaben an eine Implementierung, der sich eine Organisation unterwirft (siehe auch das Bild). Das beschränkt sich nicht einzig auf Blaupausen zur Software-Organisation und arbeitsteiligen Entwicklung (dem Design), sondern bezieht auch Qualitätsmerkmale mit ein. Ob ein Softwaresystem fehlertolerant, wartbar etc. sein soll, interessiert den Kunden herzlich wenig. In der Realität ist diese Sicht etwas zu schwarz/weiß, aber sie soll klar machen, dass es Gesichtspunkte bei der Architektur gibt, die sich eine Organisation auferlegt, z.B. um ihr Software-Produkt am Markt für ein, zwei Jahrzehnte(!) am Markt positionieren und halten zu können. Es gibt Dinge, die müssen weit über den Horizont eines Kunden entschieden und bei der Software-Entwicklung durchgesetzt werden.

Am Dienstag, 27. März 2007, habe ich meine Sicht der Dinge zusammen mit weiteren Ausführungen im Workshop "Software-Architektur und Migration" im Rahmen der Konferenz "Software Engineering 2007" zur Diskussion gestellt. Ich schloss meinen Vortrag (Titel: "Was ist Software-Architektur? Ein Abgleich mit der Praxis") mit folgendem Fazit:

  • Architektur ist Ausdruck der "internen" Anforderungen

  • Architektur unterliegt ökonomischen Antriebskräften

  • Komponenten-Orientierung und Sichtkonzepte greifen als Modellierungsparadigmen für Architekturen zu kurz

  • Modellierungsansätze müssen Domänen-Modelle integrieren

  • Es fehlt eine Methodik zur Architekturmodellierung


Zu meiner eigenen Überraschung erhielt ich in vielen Punkten Zustimmung; es entstand eine lebhafte Diskussion. Möglicherweise (die Diskussionen dazu waren zu kurz) habe ich den Nerv eines Problems getroffen. Auf alle Fälle gibt es zum Thema "Software-Architektur" noch einiges zu forschen und zu bewältigen. Wir sind noch lange nicht am Ende eines umfassenden Verständnisses von Software-Architektur angekommen.

Kommentare:

Anonym hat gesagt…

Das Bild das Sie hier und in ihrer Vorlesung von SWA zeichnen halte ich in einigen wesentlichen Punkten falsch. Oder zumindest für überdramatisiert.

Sie betrachten SWA in erster Linie als eine Art interne/erweiterte Anforderungen. Auch wenn Sie damit Recht haben, so geht Architektur darüber hinaus, indem sie doch auch einen Bauplan für die SW darstellt. Natürlich gibt die Architektur keine Antworten auf alle Fragen, aber das tut ja noch nicht einmal der Code selbst. Auch der Bauplan eines Hauses gibt keine Antworten auf alle Fragen.
Sie argumentieren, das neue Anforderungen zuerst auf Codeebene geprüft werden und fragen wo dabei die Architektur bleibt.
Ich verstehe das so, dass für den Berg Anforderungen die von einem Kunden kommen, natürlich zuerst einmal praktische Überlegungen Prototypen, etc. gemacht werden müssen. Diese Überlegungen zu machen ist ein Architekturvorgang, oder zumindest eine Vorphase davon. Diese weiterhin zu auszuwerten, ordnen, strukturieren und zu sortieren ist wieder ein Architekturvorgang. Als Ergebnis steht hier ein verwertbares Architekturkonzept. Ansonsten hätte man anstelle eines einzigen Systems nur viele unzusammenhängende Prototypen oder Lösungsideen.

Bevor dann aber die tatsächliche Implementierung erstellt wird, steht also der Plan, das Konzept, oder ein Architekturgedanke wie die Implementierung auszusehen hat.
Die Kunst dabei ist es natürlich diesen Plan nach eigenen Qualitätsmerkmalen auszurichten.
Aber die oberste Eigenschaft von SWA bleibt, Struktur in die exernen Anforderungen zu bringen, denn ohne diese Struktur würde kaum ein Projekt sinnvoll bestehen können. Eine Sturktur die wiederum als Bauplan für die Impl benutzt wird.
Geht man aber diesen Weg kann die Architektur wieder als die klassische Brücke zur Implementierung gesehen werden.

mfg
ein student

dh hat gesagt…

Ich teile Ihre Meinung zwar nicht -- aber es soll Ihnen unbenommen sein, einer anderen Ansicht zu sein. Schade, dass Sie das nicht im Rahmen der Vorlesung thematisiert haben.

Sie sagen: "Aber die oberste Eigenschaft von SWA bleibt, Struktur in die externen Anforderungen zu bringen, ...". Ihrer Argumentation kann ich an der Stelle nicht folgen. Struktur in den Anforderungen hat, meiner Meinung nach, nicht viel zu tun mit der Architektur von Software.

Anonym hat gesagt…

Diese Aussage mit der
Strukturierung der Anforderungen möchte ich umformulieren.

Software soll interne und externe Anforderungen erfüllen, die als Summe zu einem riesigen Anforderungskatalog führen, der nicht einfach mal schnell auf Codeebene abgearbeitet werden kann.
Natürlich stehen zu einzelnen Forderungen Lösungen bereit, ihre Summe aber muss erst intellektuell bewältigt werden.

Die Strukturierung der Anforderungen und ihrer Einzellösungen führt daher meiner Meinung nach zu einem Architekturkonzept, da mit der Strukturierung der Anforderungen auch eine Srukturierung der Lösungen einhergeht, die zusammengefasst, geordnet, usw. werden.
Die Betonung liegt also auf Forderung+Lösung.

Noch einmal anders ausgedrückt:
Als Architekt schaue ich mir die Anforderungen (intern &extern)an, überlege wie ich sie erfüllen kann und füge die Lösungen dann zu einer Architektur zusammen.