2. Software – Architektur

Moderne Entwurfsarchitekturen zeichnen sich durch mehrere Schichten aus. Als Standard kann die Drei – Schichten – Architektur angesehen werden.

Viele der heute „veralteten“ Systeme sind bzgl. ihrer anwendungsspezifischen Funktionalität noch ganz „modern“, während ihre Benutzungsoberfläche oder ihre Datenhaltung technisch veraltet ist. Um die Benutzungsschnittstelle zu aktualisieren, muss oft das ganze System neu geschrieben werden. Ähnlich sieht es aus, wenn eine andere Datenbank verwendet werden soll. Daher gilt heute als Stand der Softwaretechnik, dass Fachkonzept, Benutzungsoberfläche und Datenhaltung weitgehend entkoppelt werden. Änderungen oder gar ein Austausch der Benutzungsoberfläche sollen möglichst wenig Auswirkung auf das restliche System haben. Analog soll sich eine Anwendung einfach an eine neue Datenbank anpassen lassen.

Viele Informationssysteme besitzen eine Zwei – Schichten – Architektur (two-tier architecture). Sie besteht aus einer Anwendungsschicht, in der die Benutzungsoberfläche und das Fachkonzept in einer einzigen Schicht fest verzahnt sind, und einer Datenhaltungsschicht.

Drei – Schichten – Architektur

Die Drei-Schichten-Architektur

Aus dem Entwurfsziel (siehe Abschnitt 2) lässt sich aber direkt die Verwendung einer Drei – Schichten – Architektur (three-tier architecture) ableiten (s. Abbildung). Sie besteht aus

• der GUI* – Schicht (*graphical user interface)
• der Fachkonzeptschicht und
• der Datenhaltungsschicht

Die GUI – Schicht realisiert die Benutzungsoberfläche einer Anwendung.

Dazu gehören die

• Dialogführung und die
• Präsentation

aller Daten in Fenstern, Berichten usw..

Die Fachkonzeptschicht modelliert den funktionalen Kern der Anwendung. Sie wird durch die Abfragen repräsentiert. Außerdem enthält sie die Zugriffe auf die Datenhaltungsschicht.

Die Datenhaltungsschicht (Persistenzschicht) erfüllt die in ihrer jeweiligen Form die Aufgabe der Datenspeicherung. In einer relationalen Datenbank besteht sie aus den einzelnen, miteinander verknüpften Relationen.

Eine grundlegende Idee der Schichten – Architektur ist, dass keine andere Schicht direkt auf die Benutzungsoberfläche – d. h. die GUI – Schicht – zugreifen kann. Das bedeutet, dass keine andere Schicht Wissen über die Benutzungsoberfläche besitzt. Diese konsequente Trennung sorgt dafür, dass die Benutzungsoberfläche später leicht ausgetauscht werden kann. Weder die Fachkonzeptschicht noch die Datenhaltung dürfen also aktiv auf die GUI – Schicht zugreifen. Wenn die GUI – Schicht trotzdem die aktuellen Daten präsentieren soll, muss sie über alle Veränderungen informiert werden und sich dann selbst die aktuellen Daten von den anderen Schichten „holen“. Man spricht von indirekter Kommunikation.

Außerdem sind im Zeitalter des Internet oft zwei Benutzungsoberflächen für ein Anwendungssystem notwendig: eine für das so genannte Backoffice im Intranet (z.B. Windows) und eine für das World Wide Web (Hypertext-Technik).

Für die Realisierung der Datenhaltung verwenden viele Unternehmen heute relationale Datenbanken. Manchmal reichen flache Dateien (flat files) für die Datenhaltung aus. Prinzipiell muss eine objektorientierte Anwendung mit jeder Form der Datenhaltung zurechtkommen.

3. Prozessmodelle der Softwareentwicklung

Prozessmodelle (Vorgehensmodelle) bestimmen die Reihenfolge, Arten und Ergebnisse von Aktivitäten, die bei der Softwareentwicklung einzuhalten sind. Unabhängig vom verwendeten Prozessmodell hat sich folgende Vorgehensweise bewährt:

• Geschäftsprozesse ermitteln und modellieren (Ein Geschäftsprozess sind mehrere zusammenhängende Aufgaben, die durchgeführt werden, um ein Ziel oder bestimmtes Ergebnis zu erreichen.)
• Anforderungen an das neue Softwaresystem spezifizieren
• Analysemodell (fachliche Lösung) erstellen
• Entwurfsmodell (technische Lösung) erstellen
• Implementierung durchführen, d.h. eine technische Lösung mit Programmier­sprache(n) bzw. Programment­wicklungssystem(en) programmieren
• System testen
• Auslieferung und Einführung

Es gibt zahlreiche Prozessmodelle. Sowohl das Wasserfallmodell als auch die iterative Softwareentwicklung ist ein Vorgehensmodell (Prozessmodell), dass die Abfolge der Aktivitäten (Phasen) der Softwareentwicklung generell festlegt.

Das Wasserfallmodell sieht vor, dass die Phasen zeitlich linear durchlaufen werden, d.h., dass für das komplette Softwaresystem die vorhergehende Phase vollständig abgeschlossen sein muss, bevor die nächste beginnt. Zuerst werden die Geschäftsprozesse modelliert, dann werden die Anforderungen komplett spezifiziert usw. (lineare Vorgehensweise).

Iterative Softwareentwicklung bedeutet, dass die Entwicklungsphasen nicht für das komplette Softwaresystem, sondern zunächst nur für einen (kleinen) Teil davon durchlaufen werden. Am Ende einer Iteration liegt immer ein fertig getestetes Teilsystem vor, das beim nächsten Durchgang verbessert und erweitert wird (zyklische Vorgehensweise). Sind die Teilsysteme keine Wegwerfprodukte, wird auch von evolutionärer Softwareentwicklung gesprochen.

Da bei einem komplexen Softwaresystem kein Auftraggeber die Anforderungen an dieses System von vornherein vollständig, detailliert, eindeutig und widerspruchsfrei beschreiben kann, ist die Annahme, dass ein Anwendungssystem vollständig und „richtig“ modelliert werden kann, bevor mit der Programmierung begonnen wird, illusorisch.

Damit ist das Wasserfallmodell zum Scheitern verurteilt und die iterative Softwareentwicklung heute ein Eckpfeiler aller modernen Prozessmodelle. Iterative Softwareentwicklung ermöglicht es, falsch verstandene Anforderungen und Risiken im Projekt frühzeitig zu erkennen. Deshalb wird auch die Bedeutung von Pilot­systemen deutlich. Pilotsysteme sind leicht verständliche Kommunikations­mittel, die die Machbarkeit von Systemen zeigen, eine frühzeitige Überprüfung, ob Benutzungsoberfläche und Funktionen den Vorstellungen der Anwender entsprechen, und eine  laufende Abstimmung zwischen Entwicklern und Anwendern ermöglichen.

4. Entwicklungsphasen der Softwareerstellung

4.1 Analyse

Analyse und Entwurf sollen bei der objektorientierten Entwicklung präzise getrennt werden. Das ist besonders wichtig, wenn diese Aufgaben in einem Unternehmen von unterschiedlichen Teams durchgeführt werden oder wenn ein Unternehmen nur das OOA – Modell erstellt und die Realisierung (Entwurf und Programmierung) an eine externe Firma vergibt.

Meist sind den führenden Firmenmitarbeitern die im Betrieb ablaufenden Geschäftsprozesse gut bekannt, so dass sie diese Vorgänge mit den entsprechenden Werkzeugen gut nachbilden und modellieren können. Diese Methode ist effektiver, als wenn die Prozesse umgangssprachlich beschrieben werden bzw. in langen Sitzungen und Gesprächen von den firmeninternen Fachleuten an die Systemanalytiker weitergegeben werden müssen.

4.1.1 Ziel der Analysephase

Das Ziel der Analyse ist es, die Wünsche und Anforderungen eines Auftraggebers an neues Softwaresystem zu ermitteln und zu beschreiben. Es muss ein Modell des Fachkonzepts erstellt werden, das konsistent, vollständig, eindeutig und realisierbar ist.

Diese Zielsetzung ist zunächst unabhängig davon, ob die Analyse

• • umgangssprachlich in Textform, mit
  • strukturierten Analysetechniken oder
  •  objektorientiert durchgeführt wird.

Bei der objektorientierten Analyse (OOA) gehen wir von Objekten aus, die sich in der realen Welt befinden. Das sind nicht nur „anfassbare“ Objekte oder Personen, sondern häufig Begriffe oder Ereignisse aus dem jeweiligen Anwendungsbereich.

Aus einem realen Objekt wird durch Modellbildung und geeignete Abstraktion ein Objekt unseres objektorientierten Modells. Objekte, die sich durch die gleichen Eigenschaften beschreiben lassen, gehören der gleichen Klasse an.

Das Ziel der objektorientierten Analyse ist es, das zu realisierende Problem zu verstehen und in einem OOA – Modell zu beschreiben (vgl. Balzert, Heide 2009, S. 4). Dieses Modell soll die wesentliche Struktur und Semantik des Problems, aber noch keine technische Lösung beschreiben. Es darf keinerlei Optimierungen für das verwendetet Computersystem oder die benutzte Basissoftware enthalten. Es ist wichtig, dass bei der Modellbildung in der (System-)Analyse alle Aspekte der Implementierung bewusst ausgeklammert werden, denn Implementierungstechniken ändern sich schnell. Man abstrahiert von allen technischen Randbedingungen, wie beispielsweise Zugriffszeiten und Speichergröße. Auch die Verteilung der Software auf mehrere Computersysteme spielt vorerst keine Rolle. Es ist auch nicht von Bedeutung, in welcher Form die Daten gespeichert werden.

Vom Problem zur fachlichen Lösung

OOA – Modelle sind abstrakte, fachliche Lösungen. Sie ermöglichen dem Systemanalytiker, sich ein genaues Bild über das zu entwickelnde System zu machen, bevor die erste Programmzeile geschrieben wird.

4.1.2 Produkte der Analysephase

4.1.2.1 Anforderungsbeschreibung

Der erste Schritt der Systemanalyse sollte darin bestehen, zunächst Anwendungsfälle und eine Anforderungsbeschreibung zu erstellen, die dann als Ausgangsbasis für eine systematische Modellbildung dienen. In der Kommunikation mit dem Auftraggeber müssen sämtliche Anforderungen an die Datenbank möglichst genau analysiert und strukturiert dokumentiert werden. Sämtliche Anwendungsfälle gilt es in dieser Phase zu unterscheiden.
Die Anforderungsbeschreibung ist eine Beschreibung in Textform dessen, was das zu realisierende System leisten soll. Bei diesem Vorgehen sollen zwei Zielsetzungen erfüllt werden:

• • • Sie ist das Einstiegsdokument in das Projekt für alle, die das System später pflegen und warten sollen.
    • Sie soll den Systemanalytiker dazu in die Lage versetzen, das OOA – Modell zu

Die Anforderungsbeschreibung besitzt also ein niedrigeres Detaillierungsniveau als das OOA – Modell. Es ist nicht das Ziel, anhand der Anforderungsbeschreibung das System zu implementieren.

4.1.2.2 Das OOA – Modell (Analysemodell)

bildet die fachliche Lösung des zu realisierenden Systems. Man spricht daher auch vom Fachkonzept. Es besteht aus einem statischen und einem dynamischen Modell.

Welches dieser beiden Modelle in der Systemanalyse das größere Gewicht besitzt, hängt wesentlich von der jeweiligen Anwendung ab.

Das statische Modell ist bei typischen Datenbank – Anwendungen besonders wichtig. Es beschreibt insbesondere die Klassen des Systems, die Beziehungen zwischen den Objekten (Assoziationen) und zwischen den Klassen (Vererbungsstrukturen). Außerdem enthält es die Daten des Systems (Attribute). Die Pakete dienen dazu, Teilsysteme zu bilden, um bei großen Systemen einen besseren Überblick zu ermöglichen. Es ähnelt dem relationalen Datenbankmodell mit seinen Relationen, Beziehungen und Attributen.

Das dynamische Modell ist insbesondere bei stark interaktiven Systemen von Bedeutung. Es zeigt Funktionsabläufe in ihrer ganzen Dynamik.

Das Modell des Fachkonzepts muss alle Informationen enthalten, um daraus einen Prototyp der Benutzungsoberfläche abzuleiten. Oft ermöglicht erst das Vorhandensein dieses Prototyps, mit dem zukünftigen Benutzer bzw. mit dem Auftraggeber abzuklären, ob das System wirklich wie gewünscht spezifiziert ist. In diesen Prototypen gehen natürlich außer der Information aus dem Fachkonzept auch Informationen über die optimale ergonomische Gestaltung ein.

Der Prototyp der Benutzungsoberfläche ist ein ablauffähiges Programm, das alle Attribute des OOA – Modells auf die Oberfläche abbildet. Der Prototyp besteht aus Fenstern, Dialogen, Menüs usw. Für die effektive Erstellung gibt es heute zahlreiche Werkzeuge. Der Zweck des Prototyps ist es, das erstellte OOA – Modell mit dem zukünftigen Benutzer oder einem Repräsentanten zu evaluieren.

Zusammenfassend kann man sagen:

In der Analysephase wird zunächst eine Anforderungsbeschreibung erstellt; davon ausgehend wird eine fachliche Lösung (Fachkonzept bzw. OOA – Modell) modelliert, die durch keinerlei Implementierungstechnik eingeschränkt ist. Es enthält ein statisches und evtl. ein dynamisches Modell und dient als Grundlage für den Prototypen.

Teilmodelle des OOA – Modells und ihre wichtigsten Teilprodukte

Vorgehensbaustein objektorientierte Analyse (OOA)

In der Kommunikation mit dem Auftraggeber müssen sämtliche Anforderungen an die Datenbank möglichst genau analysiert und strukturiert dokumentiert werden. Sämtliche Anwendungsfälle gilt es in dieser Phase zu unterscheiden.

Aufgabe der Analyse ist es, die Anforderungen und Wünsche der Anwender und Benutzer an ein neues Softwaresystem zu ermitteln und zu beschreiben, um daraus ein Modell der fachlichen Lösung (Fachkonzept) des zu realisierenden Anwendungssystems zu erstellen, das widerspruchsfrei, vollständig, eindeutig und realisierbar ist.

Notieren Sie hier, welche Anforderungen von uns an die Schuldatenbank gestellt werden.

An dieser Stelle sollen die Vorteile einer (im Idealfall weltweit) einheitlichen Symbolsprache zur Konzeptionalisierung einer Software verdeutlichen, indem die verschiedenen graphischen Modelle vorgestellt werden. Aus diesem Grund werden die folgenden Phasen der Implementierung (auch Programmierung), der Tests und der Auslieferung and den Kunden vernachlässigt. Aus Gründen der Vollständigkeit sollen sie im Folgenden jedoch kurz angesprochen werden:

4.2 Implementierung

Wurden alle Kundenwünsche hinsichtlich der Funktionalität der zu erstellenden Software berücksichtigt und im Ergebnis als Modell dargestellt, beginnt die Phase der Umsetzung, auch Implementierung genannt. In Abhängigkeit von dem bzw. den ausgewählten Werkzeug (-en) entsteht ein fertiges Produkt. So ist es z.B. bei der Erstellung einer Datenbank für das fertige Produkt entscheidend, ob es auf der Basis von MS Access oder SAP erstellt wurde. Beide Varianten hätten jedoch gemeinsam, dass  am Ende des Prozesses eine Datenbank steht. Die Auswahl des Werkzeuges bzw. der Entwicklungsumgebung erfolgt u.U. in Absprache mit dem Kunden. Jetzt sind die Entwickler und die Programmierer gefragt, mit ihrem Wissen ein den Wünschen des Kunden entsprechendes und auch funktionierendes Produkt zu entwerfen.

4.3 Testphase

Erinnern wir uns an die Ausführungen in Bezug auf die Prozessmodelle der Softwareentwicklung und in diesem Zusammenhang an die Vorteile der iterativen Softwareentwicklung, so wird schnell klar, dass es die Testphase innerhalb der Entstehung einer digitalen Anwendung nicht gibt: vielmehr handelt es sich hierbei um viele sich über den gesamten Zeitraum der Implementierung hinweg erstreckende immer wiederkehrende Prozesse, die den jeweils abgeschlossenen Arbeitsschritt auf seine Fehlerfreiheit untersuchen sollen.

4.4 Auslieferung

Am Ende eines jeden Produktionsprozesses in der Industrie steht die Auslieferung des fertigen Produkts. Auch die fertige Anwendung ist das Produkt eines mehr oder weniger langwährenden Prozesses. Sie markiert das vorläufige Ende eines Geschäftes zwischen dem Softwareunternehmen und seinem Kunden. Eventuell beinhaltet der Vertrag die weitere Betreuung während des täglichen Einsatzes bzw. die ständige Weiterentwicklung.

Wie bereits erwähnt, ist für uns im Rahmen der Kennenlernens der UML der „theoretische“ Teil der Entstehungsgeschichte einer Software vorrangig von Bedeutung, weswegen die Phasen nach der Entwicklung hier nicht weiter betrachtet werden sollen.