Modellierung von Softwaresystemen

Die Softwaretechnik (engl. software engineering) befaßt sich mit dem Erstellen umfangreicher Softwaresysteme. Sie folgt ingenieurmäßigen Prinzipien, die nach [Balzert, 1996a, S. 36] ei-nerseits „Künstlertum“ ausschließt und andererseits die ziel- und marktorientierte Entwicklung optimaler Problemlösungskompromisse unterstützt.

Der Begriff “software engineering“ wurde zum Ende der 60er Jahre als Reaktion auf die allge-meine Unzufriedenheit mit produzierter Software (Software Krise) geprägt. Bauer faßte diese Problematik im Umfeld der ersten Konferenz mit dem Titel „software engineering“ (vgl. [Naur / Randell, 1969]) passend zusammen: „The whole trouble comes from the fact that there is so much tinkering with software. It is not made in a clean fabrication process, which it should be.

[. . . ] What we need, is software engineering.“ (nach [Bauer, 1993]). Folglich wurde auch für die Entwicklung und Anwendung von Software nach (ingenieur-) wissenschaftlich fundierten Grundlagen gesucht.

Die Verwendung dieser wissenschaftlichen und mathematischen Grundlagen zur Nutzbarmach-ung von Computersystemen für den Menschen durch Programme, Verfahren und Dokumente betrachten [Boehm, 1981] und [Denert, 1991] als wesentlichen Schwerpunkt der Softwaretech-nik. Ähnlich beschreibt auch [ANSI/IEEE Std. 729, 1983] die Softwaretechnik als den syste-matischen Ansatz zur Entwicklung, zum Betrieb und zur Wartung von Software. Boehm stellt auch die Dokumentation, die zur Erstellung, zur Verwendung und zur Wartung der Software nötig ist, deutlich heraus. So definiert er in [Boehm, 1976] die Softwaretechnik als die prakti-sche Anwendung wissenschaftlicher Kenntnisse zur Entwicklung und Realisierung von Com-puterprogrammen einschließlich der zur Entwicklung, zum Betrieb und zur Wartung benötigten Dokumentation.

Auch die Entwicklung der bei der Softwareerstellung benötigten wissenschaftlichen Grundlagen ist als Aufgabe der Softwaretechnik zu sehen. Thema der Softwaretechnik ist nach [Hesse et

al., 1984] die Bereitstellung und systematische Verwendung von Methoden und Werkzeugen für die Herstellung und Anwendung von Software. Ähnlich argumentiert auch [Sommerville, 1996, S. 4]. Softwaretechnik beschäftigt sich mit Theorien, Methoden und Werkzeugen, die zur Ent-wicklung von Computersoftware benötigt werden. Diese Begriffsbildungen zusammenfassend versteht [Balzert, 1996a, S. 36f] unter Softwaretechnik die „zielorientierte Bereitstellung und sy-stematische Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung von umfangreichen Softwaresystemen.“

Die Softwaretechnik befaßt sich sowohl mit der wissenschaftlichen Entwicklung von Prinzipien, Methoden, Techniken und Werkzeugen zur Softwareentwicklung als auch mit der Anwendung dieser Mittel zur Erstellung, zum Betrieb und zur Wartung von umfangreichen Softwareprodukten.

Diskussionen verschiedener Softwaretechnik-Begriffe finden sich auch bei [Balzert, 1996a, S. 35] und [Pressman, 1997, S. 22].

2.2.1 Vorgehen zur Softwareerstellung

Wie auch in der Organisationstechnik wird der Softwareerstellungsprozeß durch Vorgehensmo-delle strukturiert. Ein einfaches und nicht empfehlenwertes Modell aus den ersten Tagen der Programmierung ist im code-and-fix-Modell [Boehm, 1988] zu sehen. Programmcode wurde erstellt, anschließend wurden die Fehler beseitigt. Ein auf einer Analyse- und Synthesephase beruhendes Zwei-Phasenmodell wird als Ausgangspunkt zur Entwicklung des Phasenmodells in [Royce, 1970] vorgestellt. Bei diesem Vorgehensmodell folgen die grundlegenden Entwick-lungsschritte der Softwareentwicklung nach Abnahme der Teilergebnisse aufeinander. Royce entwickelte dieses Modell anschließend zu dem von [Boehm, 1981, S. 35] als Wasserfallmodell bekannt gemachten Vorgangsmodell weiter. Die einzelnen Entwicklungsschritte können hier auch iterativ bearbeitet werden. Ebenso wurde das Wasserfallmodell um prototypische Studien ergänzt. Die in der Literatur beschriebenen Phasen der Wasserfallmodelle zur Softwareentwick-lung variieren sowohl in den Bezeichnungen wie in den jeweils zugeordneten Teiltätigkeiten. Die Grundstruktur ist jedoch für alle Modelle ähnlich und bietet ein gutes Strukturierungsmittel der einzelnen Schritte zur Softwareentwicklung. Eine ausführliche Beschreibung des kanonischen Lebenszyklus-Modells, der in Abbildung 2.2, angelehnt an Abbildung 2.1, komprimiert darge-stellt ist, findet sich z. B. in [Boehm, 1981, S. 37] oder [McDermid / Rook, 1991].

Die Softwareentwicklung beginnt in der Analysephase oder Definitionsphase (Software analysie-ren) mit der Festlegung der qualitativen und quantitativen Anforderungen an das zu realisierende System. Hierbei sind insbesondere die funktionalen Eigenschaften des Softwaresystems aus An-wendersicht zu erheben sowie die Realisierungsmöglichkeiten des Vorhabens zu überprüfen. In der Entwurfsphase (Software entwerfen) erfolgt die Entwicklung eines Realisierungskonzepts, das die zuvor definierten Anforderungen erfüllt. Die Umsetzung dieser Entwürfe in ausführbare Programme erfolgt in der Implementierungsphase oder Realisierungsphase (Software implemen-tieren). Neben der Programmierung der einzelnen Komponenten erfolgt hier auch die Integration dieser Module in das Gesamtsystem. Dieses System ist anschließend in der Einführungsphase (Software einführen) beim Anwender einzuführen. Es schließt sich die Wirkungsphase (Software

Software

implemen-tieren Software

entwerfen

Software einführen

Software betreiben und warten Software

analysieren

Requirements-Engineering

Abbildung 2.2: Ein Wasserfallmodell des Software-Lebenszyklus

betreiben und warten) mit dem Betrieb und der Pflege und Wartung des Systems an. Die Softwa-reentwicklung nach dem Wasserfallmodell läuft jedoch nicht generell sequentiell ab. Rückgriffe auf vorhergehende Schritte sowie Teilentwicklungen in unterschiedlichen Phasen sind durchaus möglich.

Das Wasserfallmodell bildet die Grundlage zur Entwicklung weiterer Vorgangsmodelle. Die be-kannteste Erweiterung ist im Spiralmodell [Boehm, 1988] (vgl. auch das zyklische Vorgehens-modell zur Organisationsgestaltung nach [Schmidt, 1980] auf Seite 17) zu sehen, in dem sowohl die schon bei [Royce, 1970] angesprochene Verwendung von Prototypen als auch die Risiko-Abschätzung der einzelnen Entwicklungsstufen weiter ausgeprägt wurde. Jede Phase der Soft-wareentwicklung (z. B. Erstellung der Machbarkeitsanalyse, Erheben der Anforderungen) wird in vier Teilschritten, der Festlegung des Phasenziels, der Risikoabschätzung, der Entwicklung und Validierung und der Planung der nächsten Phase bearbeitet.

Das Spiralmodell kann als Referenzmodell für Vorgehensmodelle zur Softwareentwicklung auf-gefaßt werden, da aus ihm ein Großteil der anderen Vorgehensmodelle abgeleitet werden kann.

[McDermid / Rook, 1991] gibt einen umfassenden Überblick zu diesen Vorgangsmodellen zur Softwareentwicklung. Weitere Diskussionen dieser Vorgehensmodelle zur Softwareerstellung findet sich z. B. auch in [Boehm, 1988] und [Lehner et al., 1995, S. 87ff].

2.2.2 Methoden des Requirements-Engineering der Softwaretechnik

Die frühen Phasen der Softwareentwicklung werden ebenfalls unter dem Begriff Requirements-Engineering zusammengefaßt. Ziel des Requirements-Requirements-Engineering der Softwaretechnik ist es, eine vollständige, konsistente, realisierbare und eindeutige Spezifikation bereitzustellen, in der

beschrieben ist, was ein Softwaresystem tun soll [Boehm, 1979], [ANSI/IEEE Std. 729, 1983].

Die Beschreibungsmittel des Requirements-Engineering beziehen sich nur bedingt auf die Dar-stellung der Funktionsweise eines Softwaresystems. Programmiersprachen werden daher auch in den folgenden Betrachtungen ausgeklammert.

Bei den Methoden des Requirements-Engineering der Softwaretechnik werden die eher prozeß-orientierten Ansätze der (modernen) strukturierten Analyse und die objektprozeß-orientierten Ansät-ze unterschieden. In beiden AnsätAnsät-zen sind Daten bzw. Datenstrukturen, Kontrollstrukturen und funktionale Zusammenhänge einzelner Softwarebausteine zu erheben und zu beschreiben.

(Moderne) Strukturierte Analyse

Die Methoden der strukturierten Analyse (z. B. [DeMarco, 1978], [Gane / Sarson, 1979]) basieren auf der prozeßorientierten Beschreibung des Systems durch den Datenaustausch zwischen Systemprozessen. Die Modellierung nach der strukturierten Analyse beginnt mit der Abgrenzung des Softwaresystems von seiner Umwelt. Hierzu sind die Datenflußbe-ziehungen, über die das Softwaresystem mit seiner Umwelt kommuniziert, zu erheben.

Ausgehend von diesen Datenflüssen wird das Softwaresystem in Teilprozesse zerlegt, die ebenfalls durch ihren Datenaustausch charakterisiert sind. Nicht weiter zerlegte Prozesse werden durch Angabe ihrer Kontrollflüsse konkretisiert. Die moderne strukturiere Analyse [Yourdon, 1989] erweitert die strukturierte Analyse um die Beschreibung von der System-dynamik und der Informationsstrukturen. Die Steuerung der Abarbeitung der einzelnen Prozesse wird durch zusätzliche Kontrollprozesse (vgl. auch die Echt-Zeit-Variante der strukturierten Analyse [Ward / Mellor, 1985]) modelliert. Parallel und (nahezu) unabhän-gig von der Prozeßmodellierung erfolgt die Erstellung des Informationsstrukturmodells, das anschließend mit dem Datenflußmodell abgeglichen wird. Die Modellierung nach der modernen stukturierten Analyse erfolgt aus unterschiedlichen Blickwinkeln, die zusam-mengefaßt das System vollständig abbilden. Die unabhängige Entwicklung der einzelnen Teilmodelle führt jedoch leicht zu Inkonsistenzen in der Modellierung.

Objektorientierte Analyse

Während bei der (modernen) strukturierten Analyse die prozeßorientierte Untersuchung deutlich dominiert, stellen die objektorientierten Methoden (z. B. [Rumbaugh et al., 1991], [Booch, 1994], [Booch et al., 1999]) die Untersuchung der Daten einschließlich der hierauf auszuführenden Operationen in den Vordergrund. Zentraler Betrachtungsgegenstand sind Objekte, die sowohl durch ihre Datenstrukturen als auch durch ihr Verhalten charakteri-siert sind. In den objektorientierten Ansätzen werden statische und dynamische Strukturen des Systems als Sichten auf das gleiche System aufgefaßt. So besteht z. B. eine Model-lierung nach der Object Modeling Technique (OMT) [Rumbaugh et al., 1991, S. 6ff] aus einem Objektmodell, zur Beschreibung der statischen Klassen-Struktur, einem dynami-schen Modell, zur Beschreibung der Veränderungen der (internen) Systemzustände und einem funktionalen Modell zur datenflußorientierten Beschreibung des nach außen sicht-baren Verhaltens. [Booch, 1994] bzw. [Booch et al., 1999] unterscheiden analog die stati-sche bzw. die strukturelle Sicht zur Darstellung der Systemstrukturen, und die dynamistati-sche bzw. die Verhaltenssicht zur Betrachtung der Veränderungen des Systemzustands. Idealty-pische objektorientierte Modellierungen beginnen mit der Erstellung des Objektmodells.

Zunächst werden die relevanten Klassen, deren Attribute und Methoden sowie die Bezie-hungen der Klassen untereinander erhoben und beschrieben. Diese statische Modellierung bildet gemeinsam mit Szenarien, die typisches und untypisches Systemverhalten abbilden, den Ausgangspunkt zur Beschreibung des möglichen dynamischen Verhaltens der Objek-te. Erst nach Erstellung des Objektmodells und des dynamischen Modells wird nach der OMT [Rumbaugh et al., 1991, S. 179] das funktionale Modell erstellt. Hierbei werden aus-gehend von den im dynamischen Modell notierten Aktivitäten und den im Objektmodell modellierten Objekten und Attributen die Daten- und Kontrollflüsse beschrieben. Vgl. hier-zu auch die Vorgehensmodelle hier-zur objektorientierten Analyse in [Balzert, 1996a, S. 359]

oder in [Rumbaugh et al., 1991, S. 148ff].

Sowohl die strukturierte Analyse als auch die objektorientierten Methoden benötigen zum Requirements-Engineering Beschreibungsmittel, die statische und dynamische Systemaspekte hervorheben. Beide Ansätze verwenden letztendlich die gleichen oder ähnliche visuelle Sprachen (vgl. auch [Ebert / Engels, 1994]), die sich häufig nur in ihrer konkreten Notation unterscheiden und bei unterschiedlichen Methoden zu unterschiedlichen Zeitpunkten im Modellierungspro-zeß eingesetzt werden. Eine gute Übersicht über die konkreten Beschreibungsmittel, die in den verschiedenen Methoden der strukturierten Analyse oder der objektorientierten Modellierung verwendet werden, bietet auch [Wieringa, 1998].

2.2.3 Visuelle Modellierungssprachen der Softwaretechnik

So wie sich die visuellen Sprachen zur Organisationsbeschreibung sowohl auf organisatori-sche Regeln als auch auf die Einbettung in ihr organisatoriorganisatori-sches Umfeld beziehen, unterstüt-zen die Sprachen des Requirements-Engineering der Softwaretechnik sowohl die Beschreibung der Strukturen und Abläufe innerhalb eines Softwaresystems als auch die Einbettung des Soft-waresystems in seinen Anwendungskontext. Insbesondere unterstützen die Sprachen, die in der Analysephase eingesetzt werden, die Abgrenzung des zu beschreibenden Softwaresystems von seiner Systemumwelt, während die Beschreibungsmittel der Entwurfsphase eher auf die internen Zusammenhänge ausgerichtet sind.

Visuelle Modellierungssprachen des Requirements-Engineering der Software-technik dienen als Hilfsmittel zur Erhebung und Beschreibung von Softwaresy-stemen bezogen auf ihre statische und dynamische Struktur sowie auf das sie umgebende Anwendungssystem.

Diese Sprachen dienen zur Unterstützung der Erhebung und Dokumentation von Entwurfsent-scheidungen während der Softwareerstellung. Sie unterstützen darüber hinaus auch die Kommu-nikation zwischen den bei der Softwareentwicklung betroffenen Personen. Die Beschreibungs-mittel, die in der Analysephase eingesetzt werden, dienen hier als Kommunikationsmittel mit den Anwendern bzw. Auftraggebern. In der Entwurfs- und Implementierungsphase werden die-se Sprachen eher als Kommunikationsmittel zwischen Systementwicklern eingedie-setzt. Die Be-schreibungsmittel, die insbesondere in der Entwurfsphase eingesetzt werden, unterstützen den Softwareentwickler bei der Umsetzung der eher informell beschriebenen Anforderungen aus der Analysephase in formale Beschreibungen und ausführbare Progamme.

In Kapitel 3 werden auch die visuellen Modellierunssprachen des Requirements-Engineerings der Softwaretechnik ausführlicher dargestellt. Überblicksdarstellungen zu diesen graphischen und textuellen Beschreibungsmitteln bieten auch [Martin / McClure, 1985a], [Ebert / Engels, 1994], [Wieringa, 1998] und [Partsch, 1998].