Zusammenfassung
Erfahren Sie, was Software-Architektur ist und wie Sie es für Ihre Zwecke einsetzen können.
André Minhorst, Duisburg
Wer hin und wieder eine Access-Anwendung für den Eigengebrauch aus dem Handgelenk schüttelt, ohne sich vorher Gedanken um ihre Aufbau zu machen, erleidet dadurch sicher keinen Schiffbruch. Wenn Sie aber größere Projekte angehen und dies vielleicht auch noch im Kundenauftrag, erleichtert eine vernünftige Planung Ihnen und dem Kunden das Leben.
Helmut Balzert definiert Software-Architektur in seinem “Lehrbuch der Software-Technik” (ISBN 3-8274-0301-4) folgendermaßen:
“Eine Software-Architektur ist eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Komponenten.”
Diese Definition ist nicht die einzige. Allerdings gibt es nicht “die” Definition der Software-Architektur. Sie bietet allerdings einen guten Einstieg: Software-Architektur beschreibt die Komponenten der Software und ihre Anordnung, wozu auch die Beschreibung der Beziehung der einzelnen Komponenten gehört. Daraus ergibt sich zwangsläufig die Frage, was man unter einer Komponente versteht – und ab hier ist Software-Architektur Auslegungssache … Der Hintergrund ist, dass man mit der Beantwortung der Frage nach dem Aussehen einer Komponente festlegt, wie hoch der Detaillierungsgrad bei der Beschreibung der Architektur einer Software ist. Geläufig sind wohl grobe Beschreibungen wie “Client-Server-Architektur” oder “Three-Tier-Architektur” – etwas feiner darf es dann aber doch sein.
Bevor Sie im nächsten Kapitel ein Beispiel für die Entwicklung einer Architektur für eine Software kennen lernen, sollen Sie etwas mehr über den Sinn einer solchen Architektur erfahren.
Dokumentation/Kommunikation
Die Erstellung einer Architektur einer Software ist immer mit dem Verfassen einer schriftlichen oder grafischen Dokumentation verknüpft. Das bedeutet, dass die Zusammenhänge entweder in Form von UML- oder UML-ähnlichen Diagrammen, als Text oder als Kombination von beiden festgehalten werden. Daraus ergeben sich folgende Vorteile:
Um von den Vorteilen profitieren zu können, muss die Dokumentation der Architektur nach der Erstellung gepflegt und eventuellen änderungen angepasst werden.
Außerdem sollte die für die Dokumentation gewählte “Sprache” möglichst standardisiert sein – UML ist derzeit die beste Wahl für diesen Zweck.
Organisation/Arbeitsteilung
Access-Anwendungen entstehen meist durch die Arbeit von Ein-Mann-Entwicklerteams. Dennoch ist als Vorteil der Vorab-Festlegung der Software-Architektur anzuführen, dass durch die feste Definition einzelner Komponenten eines Systems und ihrer Schnittstellen eine wesentlich höhere Flexibilität bei der Entwicklung der Software entsteht.
Vermutlich haben Sie auch schon einmal das Problem gehabt, dass Sie bei der Entwicklung an einer Stelle hängen bleiben und ohne die Lösung des aktuellen Problems auch nicht an einer anderen Stelle weitermachen können.
Das ist ein Indiz dafür, dass die Software ein wenig modularer aufgebaut werden sollte.
Es ist klar, dass bei einer Access-Anwendung mit wenigen Formularen, die sämtliche Geschäftslogik enthalten und auch noch direkt an die zugrunde liegenden Tabellen – also die Datenschicht – gebunden sind, ein einziges Problem zum Stillstand des Entwicklungsprozesses führen kann – vor allem, wenn die Formulare auch noch stark voneinander abhängig sind.
Diese “Formular-Monolithen” lassen sich allerdings leicht entwirren – das muss noch nicht einmal in einem so radikalen Schritt wie der Verwendung einer mehrschichtigen Architektur erfolgen. Wenn man aber wiederverwendbare Funktionalität in eigene Module (vielleicht sogar in ein Klassenmodul mit zusammenhängenden Methoden und Eigenschaften) auslagert und dafür sorgt, dass zwischen Formularen, die einander aufrufen, möglichst wenig Abhängigkeiten bestehen, erreicht man schon eine ganze Menge mehr Flexibilität.
Dies bezieht sich auch auf “überladene” Formulare – Sie müssen ja nicht das komplette Datenmodell in einem Formular abbilden. Wenn Sie etwa Kunden und Projekte verwalten möchten, müssen nicht die kompletten Kundendaten im Projekte-Formular enthalten sein – hier tut es durchaus ein Kunden-Detailformular, das sich vom Projekt-Formular aus per Mausklick öffnen lässt. Nebenher erhalten Sie direkt ein separates Kunden-Formular zur Verwaltung der Kunden.
Wenn Sie den Funktionsumfang beziehungsweise bei Formularen die anzuzeigenden Daten auf ein Mindestmaß reduzieren, können Sie nur gewinnen – viele kleine und überschaubare Komponenten sind allemal besser zu handhaben als große Komponenten, die viele Aufgaben gleichzeitig erledigen. Auf diese Weise können Sie sich beim Auftreten eines Problems locker einer anderen Komponente zuwenden, die sich leichter abarbeiten lässt – und das oben erwähnte, hartnäckige Problem am nächsten Tag in neuer Frische angehen.
Wenn Sie im Team tätig sind, ist der Aufbau einer Architektur mit mehreren Komponenten und sauberen Schnittstellen quasi Voraussetzung für effektives Arbeiten – auf diese Weise können sich mehrere Mitarbeiter gleichzeitig auf verschiedene Stellen der Software konzentrieren und anschließend die Ergebnisse ihrer Arbeit zusammenfügen.
Wiederverwendbarkeit
Durch die Unterteilung der Software in Komponenten wandelt man größere Elemente in kleine, leicht verdauliche Häppchen um. Die Wahrscheinlichkeit, dass Sie ein solches Häppchen an irgendeiner Stelle wieder verwenden können, ist natürlich wesentlich höher als für größere Brocken. Unter Umständen setzen Sie gar mehrere zusammenhängende Komponenten in weiteren Anwendungen ein – so lässt sich hier und da sicher einiges an Entwicklungszeit gewinnen.
Noch wichtiger sind die Auswirkungen auf das aktuelle Projekt: Es gibt immer Funktionen, die in mehreren Modulen verwendet werden. Wenn Sie dies frühzeitig erkennen, können Sie ganze Funktionsblöcke in eigene Komponenten auslagern und parametrisieren und brauchen diese nur einmal zu erstellen.
Wartung
Je länger die Fertigstellung eines Projekts zurückliegt, desto größer ist der Zeitaufwand zum Finden und Beheben von Fehlern oder für die Erweiterung der Funktionalität der Software.
Eine ausreichende Kommentierung des Quellcodes mag noch ein wenig Zeit herausschlagen, aber eine Aufteilung der Funktionalität in sinnvolle Blöcke und eine Dokumentation der Architektur gewährleistet eine wesentlich schnellere Identifizierung der fehlerhaften Stelle und deren Beseitigung.
Auch an eine für die meisten Entwickler unbeliebtere Aufgabe, nämlich das Beheben von Fehlern oder das Weiterentwickeln von Software, die man nicht selbst “verbrochen” hat, kann man etwas lockerer herangehen, wenn die Software in sinnvolle Komponenten mit wohl definierten Schnittstellen unterteilt ist. Je kleiner die Häppchen, desto geringer werden die Auswirkungen des individuellen Stils eines Entwicklers.
Planung und Kosten
Viele Softwareprojekte scheitern daran, dass die Zeit- und Kostenplanung nicht stimmt. Durch die Aufteilung der Software in kleinere Elemente bereits bei der Planung lässt sich leichter ermitteln, wie viel Zeit und damit Geld die Entwicklung einer Anwendung beanspruchen wird. Wenn Sie ein Projekt A abgewickelt haben, werden Sie nur schwer davon ableiten können, wie lange Sie für Projekt B benötigen werden. Wenn Sie aber den Aufwand für die in Projekt A verwendeten Komponenten kennen, lässt sich bei vorhandener Architektur von Projekt B schon eine wesentlich bessere Schätzung des Aufwands vornehmen.
Mit den ganzen Vorteilen der Software-Architektur im Kopf werden Sie nun vermutlich wissen wollen, wie eine solche Architektur in der Praxis aussieht.
Die Entstehung der Architektur und das fertige Aussehen werden im Folgenden am Beispiel einer Anwendung beschrieben, die Sie ebenfalls in dieser Ausgabe von Access im Unternehmen als Musterlösung finden. Mit der Programmierung und weiteren Details dieser Lösung beschäftigt sich der Beitrag namens Projektzeitmanager.
Projektzeiten managen
Der Projektzeitmanager dient dem Aufzeichnen von Zeiten, die Mitarbeiter mit Projekten verbringen, und ihrer Auswertung. Im Vordergrund steht jedoch die Möglichkeit für die Mitarbeiter, dem System möglichst einfach mitzuteilen, womit sie gerade beschäftigt sind.
Dabei lassen sich natürlich nicht alle Zeiten Projekten zuordnen, da zwischendurch noch allgemeine Tätigkeiten wie Besprechungen, Wartungsarbeiten am eigenen Rechner, Pausen und sonstige Nicht-Projektzeiten anfallen.
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
