Gesellschaft für Informatik e.V.

Lecture Notes in Informatics


Modellierung betrieblicher Informationssyteme - MobIS 2003, Proceedings der Tagung MobIS 2003, 9. bis 10. Oktober 2003 in Bamberg. P-38, 25-29 (2003).

GI, Gesellschaft für Informatik, Bonn
2003


Editors

Elmar J. Sinz (ed.), Markus Plaha (ed.), Peter Neckel (ed.)


Copyright © GI, Gesellschaft für Informatik, Bonn

Contents

Systemübergreifende Software-Architektur: Erfahrungen und Thesen

Johannes Siedersleben and Stephan Kurpjuweit

Abstract


Die Prinzipien der Software-Architektur sind wohlbekannt und akzeptiert: Trennung der Zuständigkeiten, Denken in Komponenten und Schnittstellen, durchgängige Behandlung von Fehlern und Ausnahmen und noch ein paar andere. Trotzdem wäre es vermessen zu behaupten, dass wir die Architektur eines einzelnen großen Systems beherrschen. Dieser Vortrag befasst sich mit dem noch schwierigeren Problem der systemübergreifenden Software-Architektur: Wie kooperieren Systeme, die verschiedene Teams mit unterschiedlicher Technik unabhängig voneinander gebaut haben? Dabei sind u.a. folgende Fragen zu beantworten: Sind die klassischen Regeln der Software-Architektur weiterhin gültig? Sind sie ausreichend oder brauchen wir neue Richtlinien? Sind moderne Web-basierte Techniken hilfreich oder hinderlich? 1. Software-Architektur im Großen: ein großes System Die Grundlagen der Software-Architektur (z.B. [P78]) sind auf jeder Ebene das Denken in Komponenten und Schnittstellen, die Trennung der Zuständigkeiten und die Berücksichtigung von Notfällen. Die Komponente (nicht die Klasse) ist die wesentliche Einheit des Entwurfs, der Planung und der Integration [BCK03]. Schnittstellen sind abstrakte Dienste, deren Syntax, Semantik und nichtfunktionalen Eigenschaften im Sinn eines Vertrags verbindlich festgelegt sind. Komponenten kommunizieren grundsätzlich über Schnittstellen, niemals direkt. So läuft jede Komponenten in einem durch Schnittstellen definierten Kontext; benachbarte Komponenten, die diese Schnittstellen implementieren, sind austauschbar. Bei der Trennung der Zuständigkeiten hat sich in der Praxis die Trennung von Anwendungssoftware (A-Software) und Techniksoftware (T-Software) als besonders nützlich herausgestellt [S03]. 25 Die Behandlung von Notfällen ist bis zum heutigen Tag ein Stiefkind der Software- Architektur. Wir empfehlen die strikte Trennung zwischen Fehlern der Anwendung und Notfällen. Notfälle sind selten (kommen aber vor) und erfordern völlig andere Maßnahmen [S03b]. 2. Software-Architektur im ganz Großen: viele große Systeme Obwohl wir kaum die Architektur eines einzelnen großen Systems beherrschen, entwerfen und betreiben wir Architekturen im ganz Großen: unternehmensweite oder unternehmensübergreifende Netze von Systemen, die verschiedene Teams mit verschiedenen Techniken zu verschiedenen Zeiten gebaut haben oder gerade bauen. Die vielfach verwendete Analogie “Softwarelandschaft“ zur Bezeichnung der Gesamtheit aller DV-Lösungen eines Unternehmens ist dabei irreführend. Während eine Landschaft sich im wesentlichen nicht ändert, stellen die systemund unternehmensübergreifenden DV-Lösungen permanente Grossbaustellen dar: Um mit den strategischen Unternehmensentscheidungen Schritt zu halten, werden ständig neue Systeme integriert, alte Systeme stillgelegt oder an neue Anforderungen angepasst. Der Begriff “Softwarestadt“ ist daher treffender: Wie richtige Städte sind Softwarestädte historisch gewachsene, dynamische, extrem langlebige und heterogene Gebilde. Oft gibt es dabei nicht einmal eine zentrale Kontrollinstanz, die für den systematischen Architekturentwurf der Systemstadt - also für die Stadtplanung - zuständig ist. Die Prinzipien für den Entwurf von Einzelsystemen (siehe Abschnitt 1) gelten bei der Städteplanung uneingeschränkt weiter. 3. Nichtfunktionale Eigenschaften von Schnittstellen Die Architektur eines einzelnen Systems1 wird im Wesentlichen bestimmt durch zwei nichtfunktionale Eigenschaften, nämlich Performance und Wartbarkeit: Wie lange dauert ein Aufruf; wie viele Aufrufe können pro Zeiteinheit verarbeitet werden? Wie viel Aufwand erfordern zukünftige Änderungen? Bei systemübergreifenden Architekturen dominieren weitere Eigenschaften: Robustheit, Sicherheit, Kosten und Verfügbarkeit. Oft sind Systeme zu integrieren, die selten verfügbar sind, langsam oder gar nicht antworten, oder im schlimmsten Fall falsche Antworten liefern. Dadurch entstehen viele neue Fehlersituationen, die alle zu planen und zu behandeln sind. Neben der eingeschränkten Testbarkeit ist dies die wohl größte Herausforderung von Integrationsprojekten.


Full Text: PDF

GI, Gesellschaft für Informatik, Bonn
ISBN 3-88579-367-9


Last changed 04.10.2013 18:00:13