Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
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.
Zur Erfassung der Zeiten soll der Mitarbeiter dem System jeweils beim Tätigkeitswechsel mitteilen, welche Tätigkeiten er in Zusammenhang mit dem vorherigen Projekt ausgeführt hat und angeben, welchem Projekt er sich im Anschluss an diese Tätigkeit zuwendet.
Projektzeiten auswerten
Der tiefere Sinn dieser Anwendung ist natürlich die Auswertung der einzelnen Zeiten, die die Mitarbeiter insgesamt für die unterschiedlichen Projekte benötigt haben. Die Werkzeuge zur Auswertung sollen nur Mitarbeiter mit den entsprechenden Berechtigungen benutzen können.
Einzel- oder Mehrbenutzeranwendung
Wenn ein Selbstständiger die Anwendung benutzt, können Frontend und Backend auf dem lokalen Rechner liegen, sobald aber mehrere Mitarbeiter Daten eingeben sollen, ist ein gemeinsames Backend zum Speichern der Daten mit je einem Frontend pro Mitarbeiter gefragt.
Zusätzlich benötigen Sie noch ein weiteres Frontend mit den Funktionen zur Auswertung der Projektzeiten.
Backend-Datenbank
Die Backend-Seite des Projektzeitmanagers enthält die Tabellen mit den Projekten, den Mitarbeitern, den Projektzeiten und weiteren Informationen (für weitere Informationen siehe Beitrag Projektzeitmanager an anderer Stelle in dieser Ausgabe).
Administrationsfrontend
Das zweite Frontend der Anwendung dient dem Verwalten der Projekte, Mitarbeiter und Projektzeiten. Es soll im weiteren Verlauf allerdings nicht weiter beschrieben werden.
Mitarbeiterfrontend
Das Mitarbeiterfrontend soll möglichst schlank sein und einfache Tätigkeiten für verschiedene Projekte und die entsprechenden Zeiten und Beschreibungen erlauben. Eine genaue Darstellung der Zusammenhänge folgt weiter unten in Kapitel 6.
Damit sind die Informationen für den ersten Grobentwurf bereits zusammengestellt. Bild 1 zeigt, wie die Anwendung derzeit aufgebaut ist. Die Daten liegen in dem Backend, auf das alle Benutzer mit dem entsprechenden Frontend zugreifen können – die Mitarbeiter mit dem Mitarbeiter-Frontend und der Administrator mit dem Administrationsfrontend.
Bild 1: Grobarchitektur der Anwendung
Die Einzelplatzvariante für den Selbstständigen, der seine Projekte komplett selbst verwaltet, könnte alle Komponenten in einer Datenbank enthalten – hier sieht die grobe Architektur noch wesentlich einfacher aus.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo