Harald Störrle UML 2 für Studenten

Größe: px

Ab Seite anzeigen:

Download "Harald Störrle UML 2 für Studenten"

Matilde Geisler
vor 6 Jahren
Abrufe

1 Harald Störrle UML 2 für Studenten ein Imprint von Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario Sydney Mexico City Madrid Amsterdam

2 UML im Kontext 3.1 Der Software-Lebenszyklus Die Rolle der Modellierung Methode, Notation, Technik Auswahl passender Modelle und Diagramme 33 ÜBERBLICK

3 3 UML IM KONTEXT In diesem Kapitel lernen Sie, was ein (UML-)Modell ist, welche Rolle Modelle im Vergleich zu Programmen und anderen Artefakten im Lebenszyklus von Software spielen und wie man Modelle erstellt. 3.1 Der Software-Lebenszyklus Wie alle anderen technischen Artefakte unterliegt auch Software einem Lebenszyklus (engl.: life cycle): Sie wird geplant, entworfen, hergestellt, in Betrieb genommen, benutzt und gepflegt und schließlich abgelöst und außer Dienst gestellt. Abbildung 3.1 zeigt schematisch den Software-Lebenszyklus. Dieser Lebenszyklus ist z. B. in der Norm [ISO (1995)] definiert und heute in dieser Form weitgehend akzeptiert, auch wenn die Terminologie sich manchmal unterscheidet (z. B. wird die Phase Einführung im V-Modell Überleitung in die Nutzung genannt). Die Vorgehensweise zur Herstellung von Software nennt man Entwicklungsprozess oder Softwareprozess. Die Abschnitte des Lebenszyklus bzw. eines Softwareprozesses nennt man häufig Phasen, ein Begriff der ursprünglich auf den sog. Wasserfall-Prozess zurückgeht (siehe Royce (1970)), der heute als die Geburtsstunde der Prozesslehre gilt. Eine ähnliche, weit verbreitete Einteilung ist im Vorgehensmodell des Bundes (siehe GMD (1997); Uthke (1997); V-Modell XT (2004)) vorgenommen, die in Abbildung 3.2 zu sehen ist. Dieses Diagramm veranschaulicht mehrere wichtige Aspekte gleichzeitig und ist wert, etwas genauer betrachtet zu werden. Zum einen definiert es die wesentlichen Aufgaben und legt ihre Abfolge fest. Dabei wird die Beziehung zwischen analytischen/entwerfenden Aufgaben auf dem linken Ast und korrespondierenden konstruktiven Aufgaben auf dem rechten Ast deutlich. Die Überlappung der Aufgaben auf der Zeitachse macht zum anderen klar, dass kein zwangsläufig streng sequentielles Vorgehen beschrieben wird, es verschiebt sich lediglich der Schwerpunkt der Tätigkeiten im Projekt von fachlichen zu technischen und wieder zurück zu fachlichen Aufgaben. Analyse Entwurf Projektdefinition Implementation Wartung Renovierung Stilllegung Betrieb Integration Migration & Einführung Abbildung 3.1: Die Phasen im Lebenszyklus von Software 30

4 3.2 Die Rolle der Modellierung Abbildung 3.2: Die Phaseneinteilung des V-Modell 97 Darüber zeigt dieses Diagramm auch auf, wie sich reine Software-Systeme von integrierten Hardware-/Software-Systemen unterscheiden bzw. wie solche Unterschiede begrifflich gefasst werden können: Der untere Teil des V ist doppelt angelegt, und soll darstellen, dass zu einem System Hardware- und Software-Komponenten gehören können, die einzeln analysiert, entworfen, implementiert und integriert werden, um anschließend in ein Gesamtsystem integriert zu werden. 3.2 Die Rolle der Modellierung Ein Modell ist ein Abbild eines Originals, anhand dessen sich z. B. Prognosen über das Original leichter, billiger, schneller oder überhaupt erst machen lassen (siehe Stachowiak (1973)). In der Softwareherstellung kommen als Original verschiedene Dinge in Betracht, z. B. ein existierendes System organisatorischer oder technischer Abläufe, dann nennt man das Modell Analyse oder Entwurf und versucht anhand dieses Modells, die Realität zu verstehen bzw. eine Vorstellung von einer neuen, zu erreichenden Realität zu entwickeln; ein existierendes Anwendungssystem, dann nennt man das Modell Dokumentation und hofft, sich durch Benutzung der Dokumentation künftig langwierige Experimente am Code zu ersparen. Die Modellierung taucht also potentiell in allen Phasen des Software-Lebenszyklus auf, traditionell liegt der Schwerpunkt aber eher in den frühen Phasen des Software- Lebenszyklus. Dies sind gleichzeitig die entscheidenden Phasen, denn nach dem Gesetz von Boehm unterlaufen Fehler am häufigsten in der Anforderungserhebung 31

5 3 UML IM KONTEXT oder beim Entwurf und sind um so teurer, je später sie entfernt werden (sieheendres u. Rombach (2003, S. 17)). Es lohnt sich also, Aufwand auf die valide und korrekte Modellierung zu verwenden. Ein zweites Argument folgt aus dem Gesetz von Corbató, wonach Produktivität und Zuverlässigkeit von der Länge eines Programms abhängen, aber nicht vom Abstraktionsniveau der verwendeten Programmiersprache (siehe Endres u. Rombach (2003, S. 72)). 1 Es lässt sich außerdem beobachten, dass die Programmierung einer bestimmten Funktionalität tendenziell zu umso kürzeren Programmen führt, je abstrakter die verwendete Sprache ist. Mit anderen Worten: Je abstrakter die Sprache ist, umso mehr Funktionalität steckt in jeder Programmzeile. Daraus folgt wiederum, dass mit steigendem Abstraktionsniveau der Sprache mehr Funktionalität pro Zeiteinheit und Programmierer geliefert wird. Daher ist es wenig erstaunlich, dass es einen immer stärkeren Trend zu (abstrakteren) Hochsprachen gibt und dass manche Leute in der UML den Prototypen der nächsten Generation von Programmiersprachen sehen. 2 Dann wäre ein Modell in UML das, was ein Programm für eine Programmiersprache ist. Insbesondere die Modellgetriebene Architektur (MDA R, engl.: Model Driven Architecture R der Herstellervereinigung OMG sowie die Anforderung der flexiblen Komposition von Web-Services in der serviceorientierten Architektur (SOA, engl.: service oriented architecture) vergrößert noch die Zahl der Anhänger des Modellierungs- Paradigmas, selbst unter den Vertretern agiler Methoden (siehe z. B. Ambler (2002)). 3.3 Methode, Notation, Technik Was wir heute als UML, also als Unified Modeling Language kennen, hieß ursprünglich Unified Method. Aber dieser Name wurde als irreführend erkannt, bietet die UML doch einerseits ein ganzes System aus Notationen, ohne jedoch andererseits explizit Techniken oder Softwareprozesse festzulegen. Eine Methode unterstützt die systematische Abarbeitung einzelner Schritte eines Softwareprozesses. Eine Methode besteht aus einer Notation und einer Technik. Eine Notation kann textuell oder grafisch sein und dient nur der Beschreibung eines Modells. Eine Technik andererseits ist eine detaillierte Vorgehensweise, eine schematische Anleitung zum Umgang mit einer Notation, also zur Erstellung des Modells. Offensichtlich gibt es enge Beziehungen zwischen den beiden, so dass sich nicht immer sauber trennen lässt. Andererseits gibt es keine zwingende eindeutige Zuordnung zwischen Notationen und Techniken: In der Regel sind verschiedene Kombinationen möglich, sinnvoll und verbreitet. Auch die UML lässt sich auf zahlreiche verschiedene Weisen einsetzen: Die UML ist weitgehend Methoden-neutral. In diesem Buch liegt der Schwerpunkt auf der Notation, für Techniken ist z. B. Noack (2001) eine gute Quelle. Das heißt nicht, dass die Vorgehensweisen weniger wichtig wären, ganz im Gegenteil. 1 Dieses Gesetz wird oft formuliert als: Die Zeilen Code pro Programmierer sind konstant unabhängig von der verwendeten Sprache. 2 [I hope] Java or C++ [will be replaced by modelling languages] the way Pascal and Fortran have replaced (to a large degree at least) assembly languages in the 60s/70s. [ ] I am not sure that UML will be the language that will do that [though] Selic (2004), siehe auch Selic (2003). 32

6 3.4 Auswahl passender Modelle und Diagramme 3.4 Auswahl passender Modelle und Diagramme Die Qualität von Modellen und Diagrammen hängt entscheidend von der Qualität des Modellierers ab. Offenbar ist, wer Deutsch spricht, deswegen noch kein Dichter und entsprechend ist auch, wer UML spricht deswegen noch kein (guter) Modellierer. Welche Modelle in einer bestimmten Situation am besten geeignet sind, einen intendierten Inhalt wiederzugeben, welche Notationen oder Notationselemente dabei zum Einsatz kommen und wie Diagramme, Formulare und Texte aufgebaut sein sollten, hängt von einer Reihe von Faktoren ab, inklusive der Phase des Lebenszyklus, dem Zweck, den verfügbaren Medien und dem Publikum. Die Beurteilung dieser Faktoren erfordert viel Erfahrung. Die Auswahl der Beispiele gibt Ihnen einen ersten Eindruck, die Tabelle in Anhang A.5 enthält zusätzlich einen Katalog der Diagramm- bzw. Modelltypen mit Auswahlkriterien. Vor allem aber das folgende Kapitel soll Ihnen helfen, die in diesem Buch vorgestellten Notationen im praktischen Kontext zu verstehen. 33

Ähnliche Dokumente

Objektorientierte Softwaretechnik

Bernd Brügge, Allen H. Dutoit Objektorientierte Softwaretechnik mit UML, Entwurfsmustern und Java ein Imprint von Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario Sydney