Software-Engineering mit der Unified Modeling Language

Dieses Kapitel gibt einen Überblick über die Aufgaben, die bei der Software-Entwicklung zu lösen sind. Abbildung 1.1 zeigt die wichtigsten Abhängigkeiten zwischen den einzelnen Kapiteln. Die Pfeilspitzen in Abb. 1.1 zeigen jeweils auf Elemente, deren Inhalt in dem jeweils anderen benutzt wird. In diesem Kapitel werden die Aufgaben und Probleme der Software-Entwicklung behandelt. Anschließend werden allgemeine Grundprinzipien des Software- Engineerings eingeführt:

Der einfache Grundgedanke objektorientierter Ansätze ist die Darstellung von Systemen als eine Reihe miteinander kooperierender Objekte. Zur Darstellung dieser Kooperation und aller damit verbundenen Einzelheiten wurde die Unified Modeling Language entwickelt. Die Unified Modeling Language, im folgenden UML abgekürzt, enthält Elemente zur Beschreibung der Struktur und des Verhaltens von Objekten in Anwendungsbereichen und IT-Systemen. Die wichtigsten Begriffe der Objektorientierung und der Kern der UML werden in diesem Kapitel eingeführt. Nach Lektüre dieses Kapitels sollte der Leser über einen hinreichend großen Wortschatz sowohl objektorientierter Begriffe als auch der UML (sozusagen „UML-light“) verfügen. Dieses Vorgehen bietet eine Reihe von Vorteilen:

Der Qualitätsbegriff ist zentral für die moderne Software-Entwicklung und findet sich bereits in der Def. 1.3.1 des Begriffes Software-Engineering. Es ist deshalb notwendig, den Begriff der Qualität zu präzisieren und so zu charakterisieren, dass qualitativ hochwertige Software systematisch konstruiert werden kann. In diesem Kapitel wird gezeigt, wodurch die Qualität von Software charakterisiert werden kann und welche prinzipiellen Maßnahmen zur Qualitätssicherung notwendig sind. Alle folgenden Themen hängen mit den hier dargestellten Qualitätskriterien eng zusammen. Solche Zusammenhänge bestehen auch dort, wo andere Kriterien, wie z.B. Wirtschaftlichkeit, im Vordergrund stehen.

Verschiedene Prinzipien sind universell in der Software-Entwicklung einsetzbar. Einige davon werden hier in allgemeiner Formulierung präsentiert, um sie bei Bedarf später zur Verfügung zu haben. Weitere Gesichtpunkte für die frühe Präsentation sind:

Die UML, deren Grundelemente bereits in Kap. 2 vorgestellt wurden, enthält Elemente zur präzisen Beschreibung von Anwendungsbereichen und IT- Systemen. Dieses Kapitel gibt eine Übersicht über die Diagramm-Typen der UML und die Grundprinzipien, an denen sich die Notation orientiert. Die UML soll Modellierungsmöglichkeiten für eine große Zahl unterschiedlichster Probleme zur Verfügung stellen. Sie bietet daher umfangreiche Ausdrucksmöglichkeiten, von denen bei Bedarf Gebrauch gemacht werden kann. In vielen Fällen wird man aber nur einen Teil der Notation benötigen. In diesem und den folgenden Kapiteln wird die UML (fast) vollständig an vielen kleinen Beispielen erläutert. Die Reihenfolge, in der die einzelnen Möglichkeiten präsentiert werden, orientiert sich an der Häufigkeit ihres Einsatzes und an ihrem Auftreten im Entwicklungsprozess.

Klassen- und Objektdiagramme zeigen die statische Struktur eines Systems. Dazu gehören die beteiligten Klassen, ggf. Objekte, die Beziehungen zwischen ihnen, Attribute und Operationen. Je nach Größe des Systems wird dieses weiter in Pakete zerlegt. In der Analyse liegt das Interesse auf der Darstellung der Strukturen im Anwendungsbereich und der Erfassung der Anforderungen an das System. Später verschiebt sich der Interessenschwerpunkt auf IT-spezifische Objekte. Die Darstellungsform bleibt während des ganzen Entwicklungsprozesses erhalten. Sie wird aber um DV-spezifische Elemente ergänzt und nach Bedarf angepasst. Die Darstellung beginnt aus mehreren Gründen mit den statischen Strukturen:

Im Rahmen der Strukturen, die durch Assoziationen, Aggregationen und GenSpec-Beziehungen gebildet werden, spielen sich die eigentlich interessanten Dinge ab: Das Verhalten, das die Objekte zeigen, die Kooperationen, die sie eingehen, um die Aufgaben des Systems zu erledigen. Je nachdem, welcher Aspekt gerade betrachtet wird, ist die eine oder andere Darstellungsform geeigneter oder zumindest suggestiver.

In diesem Kapitel werden die von Ivar Jacobson eingeführten Anwendungsfälle im Kontext der UML eingeführt. Diese haben sich in den letzten Jahren als wirkungsvolles Mittel zur Formulierung funktionaler Anforderungen erwiesen. Durch den Erweiterungsmechanismus der Eigenschaften ermöglicht es die UML, auch die nicht-funktionalen Anforderungen als Eigenschaften von Anwendungsfällen und (Teil-) Systemen zu formulieren. Die Aufgabe von Anwendungsfällen und Szenarios ist die Erfassung der Anforderungen an ein System in einer Form, die vom Anwender oder Auftraggeber nachvollzogen werden kann. Gleichzeitig sollen sie den Entwicklern notwendige Informationen für die Modellierung geben. Diese müssen dann im Einzelnen weiter präzisiert werden. Die Ergebnisse dieser Präzisierung finden sich in überarbeiteten Anwendungsfällen und Szenarios, vor allem aber im Klassen- und Verhaltensmodell. Später dienen Anwendungsfälle dann zur Überprüfung des Modells. Es kann an Hand von Anwendungsfällen geprüft werden, ob diese vom Modell unterstützt werden. In vielen Fällen ist es auch möglich Performance-Fragen zu klären. Sobald Programme entwickelt werden, liefern Anwendungsfälle viele der notwendigen Testfälle.

Hardware- und Software-Objekte spielen eine besondere Rolle in der Entwicklung von Systemen. Ihre Funktionalität ist durch Anforderungen der Nutzer bestimmt, ihre interne Arbeitsweise durch die Arbeitsweise der Plattformen, auf denen oder in Verbindung mit denen sie zum Einsatz kommen. Diese läßt sich durch die bisher eingeführten Diagramm-Typen sehr wohl darstellen. Die Struktur von Sourcecode oder Objectcode muss wenig mit den darin abgebildeten Objekten oder Klassen zu tun haben. Zum Teil handelt es sich hierbei um reine Konfigurationsfragen. Daher ist es sinnvoll, dafür passende Diagramme und Symbole vorzusehen, die sich insbesondere von den Klassen- und Objektsymbolen unterscheiden. Implementierungsdiagramme zeigen die Konfiguration des Systems und der Software. Durch Kombination können differenziert auch komplexe Situationen modelliert werden.

In diesem Kapitel wird der Softwareentwicklungsprozess so beschrieben, wie er von den meisten Methodikern gesehen, in zunehmend mehr Unternehmen (oder SPUs, Software Producing Units, Software Produzierenden Einheiten) durchgeführt und u. a. in [JBR99] dokumentiert wird. Dieser Entwicklungsprozess hat vier charakteristische Merkmale. Er ist

Ziel der Anforderungsarbeitsschritte ist ein vollständiges Modell der Anforderungen des Benutzers an das System. Diese werden für den Benutzer verständlich formuliert und im Laufe der Entwicklung weiter präzisiert, bei Bedarf modifiziert, und in einer auslieferungsfähigen Version der Software (hoffentlich) realisiert.

Ziel der Analyse ist es, aus den Anforderungen der Benutzer an das System ein hinreichend vollständiges Modell des Anwendungsbereiches zu entwickeln. Der Dreh- und Angelpunkt des gesamten Modells ist dabei das Modell der Klassen und ihrer Beziehungen: Assoziationen, Aggregationen und Generalisierungen. Diese Sicht auf die statische Struktur des Modells bildet die Basis aller weiteren Überlegungen. Die Anwendungsfälle und Szenarios dienen vor allem der Kommunikation mit dem Anwender und zur Detaillierung der Anforderungen. Auch Aktivitätsdiagramme können eingesetzt werden, um aus den Anwendungsfällen eine präzise Vorgabe in der Sprache der Entwickler zu gewinnen. Die in den Anforderungsarbeitschritten erarbeiteten Anwendungsfälle mit den zugehörigen Szenarios bilden eine Quelle, um die relevanten Klassen und Beziehungen für das System zu identifizieren. Sequenz- und Zustandsdiagramme dienen der Beschreibung des dynamischen Verhaltens des Systems und helfen bei der Spezifikation der Operationen. Die korrekte Analyse des sinnvoll abgegrenzten Anwendungsbereiches ist Voraussetzung für erfolgreichen Software-Einsatz. Das ist unabhängig davon, ob Software erstellt werden oder Standard-Software zum Einsatz kommen soll. Genaugenommen kann eine solche Entscheidung erst nach einer hinreichend sorgfältigen Analyse getroffen werden. Das interne funktionale Verhalten des Systems, d. h. wie die bereits erkannten Operationen benutzt werden, wird in Interaktionsdiagrammen dargestellt. Aktivitätsdiagramme werden nicht nur zur Modellierung der Anwendungsfälle im Sinne einer Geschäftsprozessmodellierung eingesetzt, sondern auch um komplexe Operationen zu spezifizieren.

Ziel der Analyse ist eine möglichst korrekte Erfassung der Anforderungen an das System. Dies umfasst:

In diesem Kapitel geht es um die Implementierung mit objektorientierten Systemen, vor allem objektorientierten Programmiersprachen. Darüberhinaus wird die Speicherung von Objekten im Zusammenhang mit Dateisystemen und objektorientierten Datenbanken diskutiert. Die meisten Beispiele basieren auf einem konsequent objektorientierten Einsatz von C++. Sie lassen sich aber mit den entsprechenden Modifikationen auf Smalltalk und Java übertragen. Im Vordergrund stehen hier folgende Punkte:

Testen wird heute als integrale Aktivität im Entwicklungsprozess angesehen, die frühest möglich beginnt und nicht erst — mehr oder weniger widerwillig — am Ende der Entwicklung durchgeführt wird. Testen als letzte Phase oder letzter Abschnitt im Entwicklungsprozess gerät fast immer unter Druck: Wenn es Terminüberschreitungen gibt, so werden diese oft erst in der Implementierung offensichtlich. Durch Verkürzung der Testzeit scheint man wieder etwas aufholen zu können.

Objektorientierte Analyse, Design und Programmierung haben in vielen Bereichen gegenüber strukturierten Methoden an Boden gewonnen. Bei Datenbanken kann ich eine solche Entwicklung noch nicht zu erkennen. Den größten Anteil unter den eingesetzten Systemen haben wohl relationale Datenbanken und dies gilt auch, wenn man den Desktop-Markt mit seinen großen Stückzahlen von Produkten wie MS-Access oder herausrechnet. Es ist daher notwendig, sich zu überlegen, wie objektorientierte Programmiersprachen mit relationalen Datenbanken sinnvoll verbunden werden können. Wenn man objektorientierte Analyse und Design als sinnvoll erachtet, so braucht man darüber hinaus eine Strategie zur Umsetzung eines Klassenmodells in ein logisches Datenbank-Design für ein relationales DBMS. Beides wird in diesem Kapitel dargestellt, wobei die Grundprinzipien relationaler Datenbanken als bekannt vorausgesetzt werden.