SOFTWARETECHNIK - beim Fachbereich Informatik
SOFTWARETECHNIK - beim Fachbereich Informatik
SOFTWARETECHNIK - beim Fachbereich Informatik
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>SOFTWARETECHNIK</strong><br />
Wintersemester 2005/06<br />
Version 1 : Stand: 27.05.04<br />
Version 2 : Stand: 27.11.04<br />
Version 3: Stand: 10.11.05<br />
Urs Andelfinger, Frank Bühler,<br />
Michael Guist, Stephan Karczewski,<br />
Gerhard Raffius, Inge Schestag,<br />
Wolfgang Weber, Gerhard Winkler<br />
*<br />
1 *<br />
*<br />
1 *<br />
1
2<br />
Vorwort<br />
Sehr geehrter Leser, sehr geehrte Leserin,<br />
Stand 01.03.04<br />
mit dieser Veröffentlichung lesen Sie ein Hochschulskript, das für die Studierenden<br />
am <strong>Fachbereich</strong> <strong>Informatik</strong> erstellt wurde.<br />
Dementsprechend handelt es sich weder um ein Lehrbuch noch um ein Fachbuch<br />
zur Softwaretechnik. Hinweise auf Lehr- und Fachbücher finden Sie im<br />
Literaturverzeichnis. Die Autoren dieses Skriptes empfehlen Ihnen dringend neben<br />
dem Besuch der Vorlesung auch in diesen Quellen nachzulesen und damit zu<br />
arbeiten.<br />
Die aktuellen Studien- und Prüfungsordnungen sehen vor, dass die Studierenden<br />
im Studiengang <strong>Informatik</strong> die Lehrveranstaltung Softwaretechnik im 2. und 3.<br />
Studiensemester besuchen. Neben der Vorlesung mit insgesamt 4 Semesterwochenstunden<br />
ist zusätzlich ein Praktikum mit insgesamt 3 Semesterwochenstunden<br />
verpflichtend vorgesehen. Beide Teile sind nach Meinung des <strong>Fachbereich</strong>s<br />
dringend nötig, um die Lehr- und Lerninhalte kennen zu lernen, zu verstehen,<br />
anwenden zu können und somit zu beherrschen.<br />
Vorlesung und Praktikum sind als integrierte Lehrveranstaltung konzipiert, d.h.<br />
auch, dass es aus Sicht der Lehrenden keinen Sinn macht, nur einen der beiden<br />
Teile zu absolvieren. Wenn dies aus besonderen Gründen (z.B. Nichtbestehen der<br />
Prüfung) einmal nötig werden sollte, wird diese Situation zwar akzeptiert, sie ist<br />
aber weder empfehlenswert noch etwas, was Sie anstreben sollten.<br />
Abgeschlossen werden soll die Lehrveranstaltung mit den Prüfungsleistungen<br />
Softwaretechnik I und Softwaretechnik II nach dem 2. und 3. Semester.<br />
Dieses Skript ist aber "nur" zur Unterstützung der Lehrveranstaltung Softwaretechnik<br />
entwickelt worden, zur Vorbereitung der Prüfungen also keinesfalls
ausreichend. Die Autoren weisen ausdrücklich darauf hin, dass dieses Skript<br />
konzipiert und entwickelt wurde, um Ihnen den Besuch der Lehrveranstaltung und<br />
die Bearbeitung der Inhalte zu erleichtern und nicht zu ersetzen.<br />
Neben den Abbildungen von in der Vorlesung verwendeten Schaubildern und<br />
Folien enthält das Skript in knapper Form die wichtigsten Aussagen und<br />
Lehrinhalte. Beispiele, Fragen und Musterlösungen runden den Inhalt ab und sollen<br />
Ihnen Anregungen für eigenes Arbeiten und Nachdenken liefern.<br />
3
4<br />
Inhaltsverzeichnis<br />
1 Einführung.........................................................................................11<br />
1.1 Was ist ein gutes Softwaresystem?................................................................11<br />
1.2 Was ist Softwaretechnik?...............................................................................12<br />
1.3 Geschichtliche Entwicklung...........................................................................13<br />
1.4 Softwarequalität.............................................................................................14<br />
1.5 Software-Qualitätseigenschaften...................................................................15<br />
1.6 Phasen der Softwareentwicklung...................................................................19<br />
1.7 Überblick über den Aufbau des SWT-Skriptes..............................................23<br />
2 Objektorientierung............................................................................25<br />
2.1 Einführung......................................................................................................25<br />
2.2 Prinzipien der Objektorientierung..................................................................26<br />
2.2.1 Abstraktion..............................................................................................26<br />
2.2.2 Kapselung................................................................................................26<br />
2.2.3 Wiederverwendung..................................................................................27<br />
2.2.4 Beziehungen............................................................................................28<br />
2.2.5 Polymorphismus......................................................................................28<br />
2.3 Überblick Objektorientierte Programmiersprachen.......................................29<br />
2.3.1 C++..........................................................................................................29<br />
2.3.2 JAVA.......................................................................................................30<br />
2.3.3 C#.............................................................................................................30<br />
2.4 Werkzeuge für die objektorientierte Entwicklung.........................................31<br />
2.5 Weiterführende Literatur................................................................................32<br />
3 UML Unified Modeling Language...................................................33<br />
3.1 Was ist die UML?...........................................................................................33<br />
3.2 Entstehung der UML......................................................................................33<br />
3.3 Diagramme der UML 2.0...............................................................................34<br />
3.3.1 Klassendiagramm Class Diagram..........................................................37<br />
3.3.1.1 Zweck...............................................................................................37<br />
3.3.1.2 Notation............................................................................................37<br />
3.3.1.3 Anwendungsbereich.........................................................................49<br />
3.3.1.4 Zusammenhang................................................................................50<br />
3.3.1.5 Hinweise für die Praxis....................................................................50<br />
3.3.1.6 Beispiel.............................................................................................52<br />
3.3.2 Objektdiagramm - Object Diagram.........................................................54<br />
3.3.2.1 Zweck...............................................................................................54<br />
3.3.2.2 Notation............................................................................................55
3.3.2.3 Beispiel.............................................................................................55<br />
3.3.3 Komponentendiagramm - Component Diagram....................................55<br />
3.3.3.1 Zweck...............................................................................................56<br />
3.3.3.2 Notation............................................................................................56<br />
3.3.3.3 Anwendungsbereich.........................................................................57<br />
3.3.3.4 Zusammenhang ...............................................................................57<br />
3.3.3.5 Hinweise für die Praxis....................................................................57<br />
3.3.3.6 Beispiel.............................................................................................58<br />
3.3.4 Paketdiagramm - Package Diagram........................................................58<br />
3.3.4.1 Zweck...............................................................................................58<br />
3.3.4.2 Notation............................................................................................59<br />
3.3.4.3 Anwendungsbereich.........................................................................59<br />
3.3.4.4 Zusammenhang ...............................................................................60<br />
3.3.4.5 Beispiel ............................................................................................60<br />
3.3.5 Anwendungsfalldiagramm - Use Case Diagram.....................................61<br />
3.3.5.1 Zweck...............................................................................................61<br />
3.3.5.2 Notation ...........................................................................................61<br />
3.3.5.3 Anwendungsbereich.........................................................................63<br />
3.3.5.4 Zusammenhang ...............................................................................64<br />
3.3.5.5 Hinweise für die Praxis....................................................................65<br />
3.3.5.6 Beispiel ............................................................................................66<br />
3.3.6 Sequenzdiagramm - Sequence Diagram.................................................68<br />
3.3.6.1 Zweck...............................................................................................68<br />
3.3.6.2 Notation............................................................................................68<br />
3.3.6.3 Anwendungsbereich.........................................................................71<br />
3.3.6.4 Zusammenhang ...............................................................................72<br />
3.3.6.5 Hinweis für die Praxis......................................................................72<br />
3.3.6.6 Beispiel ............................................................................................73<br />
3.3.7 Kommunikationsdiagramm - Communication Diagram........................77<br />
3.3.7.1 Zweck................................................................................................77<br />
3.3.7.2 Notation............................................................................................77<br />
3.3.7.3 Anwendungsbereich.........................................................................77<br />
3.3.7.4 Zusammenhang ...............................................................................77<br />
3.3.7.5 Hinweise für die Praxis....................................................................78<br />
3.3.7.6 Beispiel ............................................................................................78<br />
3.3.8 Zeitverlaufsdiagramm - Timing-Diagram...............................................79<br />
3.3.8.1 Zweck...............................................................................................79<br />
3.3.8.2 Notation............................................................................................79<br />
3.3.8.3 Anwendungsbereich.........................................................................80<br />
5
6<br />
3.3.8.4 Zusammenhang................................................................................80<br />
3.3.8.5 Hinweis für die Praxis......................................................................80<br />
3.3.8.6 Beispiel.............................................................................................80<br />
3.3.9 Interaktionsübersicht Diagramm - Interaction Overview Diagram........81<br />
3.3.9.1 Zweck...............................................................................................81<br />
3.3.9.2 Anwendungsbereich.........................................................................82<br />
3.3.9.3 Zusammenhang................................................................................82<br />
3.3.9.4 Hinweis für die Praxis......................................................................82<br />
3.3.9.5 Beispiel.............................................................................................82<br />
3.3.10 Zustandsautomat-State Machine Diagram............................................83<br />
3.3.10.1 Zweck.............................................................................................83<br />
3.3.10.2 Notation..........................................................................................84<br />
3.3.10.3 Anwendungsbereich.......................................................................89<br />
3.3.10.4 Zusammenhang..............................................................................89<br />
3.3.10.5 Hinweis für die Praxis....................................................................89<br />
3.3.10.6 Beispiel...........................................................................................90<br />
3.3.11 Aktivitätsdiagramm - Activity Diagram...............................................91<br />
3.3.11.1 Zweck.............................................................................................91<br />
3.3.11.2 Notation..........................................................................................92<br />
3.3.11.3 Anwendungsbereich.......................................................................96<br />
3.3.11.4 Zusammenhang..............................................................................96<br />
3.3.11.5 Hinweise für die Praxis..................................................................97<br />
3.3.11.6 Beispiel...........................................................................................98<br />
3.3.12 Verteilungsdiagramm - Deployment-Diagram...................................100<br />
3.3.12.1 Zweck...........................................................................................100<br />
3.3.12.2 Notation........................................................................................101<br />
3.3.12.3 Beispiel.........................................................................................101<br />
3.3.13 Kompositionsstrukturdiagramm - Composite Structure Diagram......102<br />
3.3.13.1 Zweck...........................................................................................102<br />
3.3.13.2 Notation........................................................................................102<br />
3.3.13.3 Anwendungsbereich.....................................................................103<br />
3.3.13.4 Neu in UML 2..............................................................................103<br />
3.4 Object Constraint Language.........................................................................103<br />
3.5 Model Driven Architecture...........................................................................104<br />
3.5.1 Was ist MDA?.......................................................................................104<br />
3.5.2 Motivation..............................................................................................104<br />
3.5.3 Wie funktioniert MDA?.........................................................................105<br />
3.6 UML Profile..................................................................................................106<br />
4 Vorgehens- und Prozessmodelle.....................................................107
4.1 Überblick (Motivation, Begriffe).................................................................107<br />
4.2 Das objektorientierte Projekt........................................................................108<br />
4.3 Wasserfallmodell, Evolutionäres Modell, Iteratives Modell.......................109<br />
4.4 Prototyping ...................................................................................................115<br />
4.5 Das V-Modell................................................................................................117<br />
4.5.1 Struktur des Standardisierungskonzeptes..............................................118<br />
4.5.2 Eigenschaften des V-Modells................................................................120<br />
4.5.3 Produktzustände und Übergänge...........................................................120<br />
4.5.4 Erzeugnisstruktur...................................................................................120<br />
4.5.5 Struktur und Inhalt des V-Modells.......................................................121<br />
4.5.6 Aktivitäten und Produkte.......................................................................121<br />
4.5.7 Aktivitätenzerlegung..............................................................................122<br />
4.5.8 Produktfluss und Abwicklung...............................................................123<br />
4.5.9 Die Submodelle.....................................................................................123<br />
4.5.10 Zusammenspiel der Submodelle.........................................................124<br />
4.5.11 Submodell "Softwareerstellung" (SWE).............................................124<br />
4.5.12 Systemanforderungsanalyse und -entwurf (SWE 1)...........................125<br />
4.5.13 Systemanforderungsanalyse und -entwurf (SWE 1)...........................125<br />
4.5.14 DV-Anforderungsanalyse und -entwurf (SWE 2)..............................125<br />
4.5.15 DV-Anforderungsanalyse und -entwurf (SWE 2)..............................126<br />
4.5.16 SW-Anforderungsanalyse (SWE 3)....................................................126<br />
4.5.17 Grobentwurf (SWE 4).........................................................................126<br />
4.5.18 Feinentwurf (SWE 5)..........................................................................127<br />
4.5.19 Implementierung (SWE 6)..................................................................127<br />
4.5.20 SW-Integration (SWE 7).....................................................................127<br />
4.5.21 DV-Integration (SWE 8).....................................................................127<br />
4.5.22 Produkte im Submodell SWE.............................................................128<br />
4.5.23 Submodell"Qualitätssicherung" .........................................................128<br />
4.5.24 Aktivitäten im Submodell QS.............................................................128<br />
4.5.25 Aktivitäten im Submodell KM............................................................129<br />
4.5.26 Submodell "Projektmanagement" (PM).............................................129<br />
4.5.27 Aktivitäten im Submodell PM.............................................................130<br />
4.5.28 Rollen im V-Modell............................................................................130<br />
4.5.29 Tailoring...............................................................................................130<br />
4.5.30 Zusammenfassung...............................................................................131<br />
4.6 RUP ..............................................................................................................132<br />
4.6.1 RUP-Phase "Inception".........................................................................133<br />
4.6.2 RUP-Phase "Elaboration"......................................................................134<br />
4.6.3 RUP-Phase "Construction"....................................................................135<br />
7
8<br />
4.6.4 RUP-Phase "Transition"........................................................................136<br />
4.7 eXtreme Programming (XP).........................................................................137<br />
4.7.1 Warum XP?............................................................................................137<br />
4.7.2 Die zwölf Praktiken...............................................................................137<br />
4.7.3 Der XP Prozess......................................................................................140<br />
4.7.4 Die Umsetzung......................................................................................143<br />
4.7.5 Weiterführende Literatur.......................................................................144<br />
4.7.5.0.1 Literatur...................................................................................144<br />
4.8 Prozessorientiertes Software-Qualitätsmanagement....................................144<br />
4.8.1 Überblick ..............................................................................................145<br />
4.8.2 Das ISO 15504 / ISO 12207 (SPICE) Prozessmodell..........................148<br />
4.8.2.1 Die Kunden Lieferanten Kategorie (CUS)....................................149<br />
4.8.2.2 Die Engineering Kategorie.............................................................151<br />
4.8.2.3 Die unterstützenden Prozesse ........................................................153<br />
4.8.2.4 Die Management Prozess Kategorie..............................................158<br />
4.8.2.5 Die Organisations Prozeß Kategorie..............................................160<br />
4.8.2.6 Prozeß Tailoring.............................................................................162<br />
4.8.3 Das ISO 15504 / ISO 12207 Reifegradmodell.....................................162<br />
4.8.3.1 Stufe 0 - Unvollständiger Prozess (Incomplete)............................164<br />
4.8.3.2 Stufe 1 - Durchgeführter Prozess (Performed) .............................165<br />
4.8.3.3 Stufe 2 - Gelenkter Prozess (Managed). .......................................165<br />
4.8.3.4 Stufe 3 - Etablierter Prozess (Established). ...................................166<br />
4.8.3.5 Stufe 4 - Quantitativ steuerbarer und vorhersagbarer Prozess<br />
(Predictable) ...............................................................................................168<br />
4.8.3.6 Stufe 5 - Optimierender Prozess (Optimizing). ............................169<br />
4.8.4 Anwendungsbeispiel der ISO 15504/12207: Reifegradstufen im<br />
Projektmanagement........................................................................................171<br />
4.8.5 Risikomanagement gemäß ISO 15504 / ISO 12207 ............................173<br />
4.8.6 Assessments gemäß ISO 15504 / ISO 12207 ......................................176<br />
4.8.7 Das CMMI-Modell................................................................................179<br />
4.8.8 Literatur .................................................................................................182<br />
5 Requirements Engineering..............................................................183<br />
5.1 Textuelle Beschreibung von Anwendungsfällen..........................................183<br />
6 Der Qualitätsbegriff und die Qualitätskriterien für Software.....195<br />
6.1 Die Qualitätseigenschaften <strong>beim</strong> fertigen Produkt:......................................195<br />
6.1.1 Wichtige Kriterien aus Benutzersicht....................................................196<br />
6.1.2 Wichtige Kriterien aus Entwicklersicht ..............................................197<br />
6.2 Qualitätsmanagement...................................................................................197<br />
6.2.1 Methoden und Werkzeuge des Qualitätsmanagements........................199
6.2.2 Die Bedeutung von Qualitätsstandards.................................................199<br />
6.2.3 Die Problematik von Standards in der Softwareentwicklung...............200<br />
6.2.4 Die Dokumentation von Software.........................................................200<br />
6.3 Die statische Kontrolle der Qualität und anderer Softwareeigenschaften . .201<br />
6.3.1 Softwaremaße-Softwaremessung..........................................................201<br />
6.3.1.1 Die Function-Point Methode..........................................................202<br />
6.3.1.2 Halstead-Maße................................................................................205<br />
6.3.1.3 Das Mc Cabe-Maß.........................................................................209<br />
6.3.1.4 Fan-in---Fan-out.............................................................................211<br />
6.3.2 Reviews..................................................................................................213<br />
6.3.2.1 Die Entwurfsinspektion.................................................................214<br />
6.3.2.2 Die Codeinspektion.......................................................................215<br />
6.3.3 Formale Verifikation.............................................................................217<br />
6.3.3.1 Baumförmige Darstellung der Verifikationsregeln.......................221<br />
6.3.3.2 Beweis der Endlichkeit von Algorithmen......................................227<br />
7 Testen................................................................................................229<br />
7.1 Testverfahren - Wie wird getestet? ..............................................................229<br />
7.2 Wie findet man Testdaten.............................................................................231<br />
7.3 Wer testet?....................................................................................................232<br />
7.4 Testen von objektorientierter Software........................................................232<br />
7.5 Teststrategie..................................................................................................233<br />
7.6 Testwerkzeuge ............................................................................................234<br />
7.7 xUnit, JUnit...................................................................................................234<br />
8 Konfigurationsmanagement...........................................................238<br />
8.1 Warum Konfigurationsmanagement (KM)?................................................238<br />
8.2 Was ist (Software-)Konfigurationsmanagement (SKM)?...........................238<br />
8.3 Einsatz von Software-Konfigurationsmanagement in Projekten................239<br />
8.4 Weiterführende Literatur..............................................................................242<br />
9 Petri-Netze........................................................................................243<br />
9.1 Zustände und Ereignisse...............................................................................243<br />
9.2 Dynamik in Petri-Netzen..............................................................................244<br />
9.3 Regeln in Petri-Netzen..................................................................................244<br />
9.4 Komplexe Situationen in Petri-Netzen.........................................................246<br />
9.5 Kontakt- und Konfliktsituation....................................................................246<br />
9.6 Gabel und Zusammenführung......................................................................247<br />
9.7 Beispiele von Petri-Netzen...........................................................................248<br />
9.8 Varianten von Petri-Netzen..........................................................................252<br />
9.8.1 Bedingungs-/Ereignis-Netze..................................................................253<br />
9.8.2 Stellen-/Transitions-Netze.....................................................................253<br />
9
10<br />
10 Entscheidungstabellen...................................................................254<br />
10.1 Grundlagen..................................................................................................254<br />
10.2 ET-Typen ...................................................................................................255<br />
10.3 Anwendung von Entscheidungstabellen....................................................255<br />
10.4 Entscheidungsbaum....................................................................................258<br />
10.5 Weiterführende Literatur............................................................................260
1 Einführung<br />
Ziel der Softwaretechnik ist es gute d. h. qualitativ hochwertige Softwaresysteme<br />
erstellen zu können.<br />
1.1 Was ist ein gutes Softwaresystem?<br />
Letztendlich ist nach [StP 00] ein gutes System eines, das den Bedürfnissen des<br />
Anwenders gerecht wird.<br />
Das System muss deshalb...<br />
• nützlich und nutzbar sein. Es muss dem Anwender das Leben möglichst stark<br />
erleichtern.<br />
• zuverlässig sein. Es soll möglichst wenig Fehler enthalten.<br />
• flexibel sein. Das System muss leicht an geänderte Anforderungen des<br />
Benutzers anpassbar sein. Die Fehler müssen leicht zu beheben sein.<br />
• kostengünstig sein, nicht nur in der Anschaffung, sondern auch im Unterhalt.<br />
• verfügbar sein. Das System muss auf jetzigen und zukünftigen Zielplattformen<br />
(Hardware, Betriebssystemen etc.) lauffähig bzw. leicht adaptierbar sein. Zur<br />
Verfügbarkeit gehört natürlich auch, dass das Softwareprodukt überhaupt<br />
existiert und zwar zu dem Zeitpunkt, zu dem es zum Einsatz kommen soll.<br />
Frage: Kennen Sie Projekte mit großen Softwareanteil, die gescheitert sind?<br />
Warum sind diese Projekte gescheitert?<br />
11
12<br />
1.2 Was ist Softwaretechnik?<br />
In dieser Vorlesung sollen Sie lernen, wie man gute Softwaresysteme erstellt, d. h.<br />
es sollen Methoden und Techniken vermittelt werden, um Software in einem<br />
gegebenen Zeitrahmen mit den oben angegebenen Eigenschaften zu realisieren.<br />
Das Fach Softwaretechnik bietet Methoden für die konstruktiven Phasen der Software<br />
Entwicklung (Analyse, Entwurf, Implementierung), die verwendet werden,<br />
um die Arbeitsergebnisse dieser Phasen zu strukturieren. Softwaretechnik stellt<br />
aber auch Modelle zur Definition von Qualität zur Verfügung (Qualitätseigenschaften,<br />
Qualitätsmodelle) und entsprechende Methoden zur Überprüfung der<br />
Phasenergebnisse (Test, Verifikation, Qualitätssicherung). Zur zeitlichen Strukturierung<br />
von Softwareprojekten sind Projektmodelle (Phasenmodelle) definiert, die<br />
eine zeitliche Gliederung eines Projektes in verschiedene Entwicklungsphasen<br />
ermöglichen.<br />
Softwaretechnik beschäftigt sich folglich mit Methoden für das "Pragrammieren im<br />
Großen". Unter Programmieren im versteht man die Abwicklung großer<br />
Softwareprojekte. Ein großes Softwareprojekt ist gekennzeichnet durch den Einsatz<br />
eines Entwicklerteams. Ein Team von mehreren Entwicklern entwickelt<br />
gemeinsam ein Softwareprodukt. Es werden in der Regel mehrere Versionen der<br />
Software erzeugt. Die Software wird weiterentwickelt und erweitert; veraltete<br />
Softwareversionen werden durch verbesserte ersetzt. Ein großes Softwareprojekt<br />
hat eine lange Entwicklungszeit. Große Systeme werden über mehrere Monate oder<br />
Jahre entwickelt. Das erfordert eine zeitliche Projektplanung und<br />
Terminüberwachung.<br />
Software hat eine lange Lebensdauer, während der das Produkt Software an neue<br />
Anforderungen angepasst werden muss.<br />
Diese Probleme bei der Software Entwicklung im Großen erfordern andere Vorgehensweisen<br />
als das Programmieren einer kleinen Anwendung (z. B. in einem Programmierpraktikum).<br />
Die Methode VHIT (Vom Hirn Ins Terminal) ist zur Entwicklung komplexer Systeme<br />
nicht geeignet. Dazu benötigt ein Entwicklerteam Prinzipien und Methoden<br />
des Software Engineering.
1.3 Geschichtliche Entwicklung<br />
In der "Steinzeit" der Software Entwicklung, in den 50er und 60er Jahren des 20.<br />
Jahrhunderts wurden Computer und die dafür notwendige Software fast ausschließlich<br />
im naturwissenschaftlichen Bereich eingesetzt. Die eingesetzten Programme<br />
dienten hauptsächlich der effizienten Lösung von mathematischen Problemen.<br />
Die Hardware war sehr teuer, die Software war sehr preisgünstig oder<br />
wurde von den Anwendern selbst geschrieben.<br />
Durch sinkende Hardwarepreise wurden Computer für eine größere Zielgruppe<br />
erschwinglich. Dadurch veränderten sich aber auch die Anforderungen an die<br />
Software. Es wurde Software für die verschiedensten Bereiche gebraucht. Der<br />
Umfang der Software wurde immer größer. Ihre Komplexität war mit den bis zu<br />
diesem Zeitpunkt bekannten Vorgehensweisen für das "Programmieren im Kleinen<br />
" nicht mehr zu beherrschen. Ausgelieferte Programme waren fehlerhaft und<br />
unzuverlässig. Software Projekte wurden nicht termingerecht fertig gestellt. Die zur<br />
Entwicklung eingeplanten Budgets wurden überschritten. Dieser Zustand der<br />
Software Industrie wurde mit dem Begriff der Softwarekrise charakterisiert.<br />
Wissenschaft und Forschung entwickelten als Reaktion darauf strukturierte Programmiersprachen<br />
und Entwicklungsmethoden zur Lösung der Probleme, die zur<br />
Softwarekrise führten. Der Begriff Software Engineering wurde zuerst auf einer<br />
Software-Engineering-Konferenz der NATO, die 1968 in Garmisch veranstaltet<br />
wurde, geprägt. Diese Konferenz gilt allgemein als Geburtsstunde der Softwaretechnik.<br />
Nachfolgend sind die Entwicklungsschritte der Softwaretechnik in Stichworten<br />
aufgeführt: (angelehnt an [Sch 90])<br />
1. Erster Ansatz zur Entwicklung übersichtlicher Programme (1968)<br />
Dijkstra schlägt die "strukturierte Programmierung" vor (Vermeidung von<br />
GOTO-Anweisungen).<br />
2. Entwicklung von Software-Engineering-Prinzipien (1968 - 1974)<br />
Es werden die theoretischen Grundlagen (Prinzipien) erarbeitet, die der strukturierten<br />
Entwicklung von Programmen zugrundeliegen: strukturierte Programmierung,<br />
schrittweise Verfeinerung, Geheimnis-Prinzip, Programmodularisierung,<br />
Software-Lifecycle, Entity-Relationship-Modell, Software-Ergonomie<br />
3. Entwicklung von phasenspezifischen Software-Engineering-Methoden (1972<br />
- 1975)<br />
Umsetzen der Software-Engineering-Prinzipien in Entwurfsmethoden: HIPO,<br />
Jackson, Constantine-Methode, erste Version von Smalltalk<br />
4. Entwicklung von phasenspezifischen Werkzeuge (1975 - 1985):<br />
Der Einsatz von SE-Methoden mit maschineller Unterstützung (z.B.<br />
Programminversion, Batchwerkzeuge)<br />
13
14<br />
5. Entwicklung von phasenübergreifenden (integrierten) Software-Engineering-<br />
Methoden (ab 1980)<br />
Es sollen die Ergebnisse einer Phase des Software-Lifecycles automatisch an die<br />
nächste Phase weitergegeben werden: Methodenverbund<br />
6. Entwicklung von phasenübergreifenden (integrierten) Werkzeuge (ab 1980)<br />
Einsatz einer Datenbank als automatischer Schnittstelle zwischen den einzelnen<br />
Phasen des Software-Lifecycles. Interaktiver Programmaufruf durch CAS-<br />
Werkzeuge (Computer Aided Softwaredesign)<br />
7. Definition verschiedener, konkurrierender objektorientierter Methoden (ab<br />
1990)<br />
Es entstanden parallel verschiedene Objektorientierte Analyse- und Entwurfsmethoden<br />
(Booch, Jacobson, Rumbaugh, Shlaer/Mellor, Coad/Yourdon u. a.).<br />
Die Methoden wurden in CASE Tools (Computer Aided Software Engineering)<br />
realisiert.<br />
8. Integration der OO-Methoden zur UML – Unified Modeling Language (ab<br />
1995)<br />
Jacobson, Booch und Rumbaugh schließen sich zusammen und entwickeln die<br />
UML. In der UML sollen die Schwächen der frühen OO-Methoden beseitigt<br />
werden und ein weltweit gültiger, einheitlicher Standard geschaffen werden. Die<br />
UML 1.0 wurde 1997 verabschiedet.<br />
9. UML 2.0<br />
Nachdem die UML 1.0 bis zur Version UML 1.5 erweitert wurde, erschien 2004<br />
die UML 2.0. In dieser Version wurde die Sprachelemente der UML an aktuelle<br />
Technologien angepasst; es wurden Redundanzen und Inkonsistenzen in der<br />
Sprachdefinition beseitigt.<br />
1.4 Softwarequalität<br />
Das Produkt Software soll nach seiner Fertigstellung den Anforderungen der<br />
Benutzer entsprechen. (Es muss nicht eine "möglichst hohe" Qualität haben, sondern<br />
die vom Benutzer verlangte Qualität!) Dazu ist es notwendig die Qualitätsanforderungen<br />
der Benutzer zu definieren, für die Entwicklung Methoden und Hand-
lungsanweisungen zum Erreichen der geforderten Qualität zu definieren und am<br />
fertigen Produkt die entwickelte Qualität zu überprüfen.<br />
Zur Definition von Softwarequalität entstand eine Vielzahl von Begriffen, die<br />
sogenannten Qualitätseigenschaften, die verschiedene Dimensionen der Qualität<br />
beschreiben. Außer den im Folgenden beschriebenen Eigenschaften existiert eine<br />
Vielzahl weiterer Qualitätseigenschaften, die nicht einheitlich definiert sind.<br />
Nachfolgend werden, als in die Problematik einführendes Beispiel,<br />
Qualitätseigenschaften mit Hilfe eines Modells nach Raasch [Ra 92] erläutert.<br />
1.5 Software-Qualitätseigenschaften<br />
Raasch benutzt die in Abbildung 1.5.1 beschriebene Hierarchie von Qualitätseigenschaften,<br />
die Qualität aus Benutzersicht und Qualität aus Entwicklersicht<br />
unterscheidet. Er geht davon aus, dass für diese beiden Gruppen unterschiedliche<br />
Qualitätseigenschaften wichtig sind. Der Benutzer verwendet Software, folglich<br />
sind für ihn Eigenschaften wie Funktionserfüllung, Zuverlässigkeit usw. von<br />
Bedeutung. Für den Entwickler sind Eigenschaften wie Wartbarkeit,<br />
Erweiterbarkeit usw. von Bedeutung. Qualitätseigenschaften können in einer Hierarchie<br />
verfeinert werden.<br />
Qualitätsmerkmale aus<br />
Benutzer sicht<br />
Qualitätsmerkmale aus<br />
Entwicklersicht<br />
Funktionserfüllung<br />
Effizienz<br />
Zuverlässigkeit<br />
Benutzbarkeit<br />
Sicherheit<br />
Erweiterbarkeit<br />
Wartbarkeit<br />
Übertragbarkeit<br />
Wiederverwendbarkeit<br />
Abbildung 1.5.1 Software - Qualitätseigenschaften<br />
HW-Effizienz<br />
SW-Effizienz(Performance)<br />
Robustheit<br />
Fehlertoleranz<br />
Änderbarkeit<br />
Verständlichkeit<br />
Testbarkeit<br />
15
16<br />
Funktionserfüllung:<br />
ist ein Maß für die Übereinstimmung zwischen geplantem und tatsächlich<br />
realisiertem Funktionsumfang.<br />
Je mehr ein System kann, desto vielseitiger ist es einsetzbar. Man kann mit Software<br />
jede beliebige Funktion verwirklichen, aber man sollte keine Systeme planen,<br />
die alle beliebigen Funktionen enthalten.<br />
Effizienz:<br />
ist das Ausmaß der Inanspruchnahme von Betriebsmitteln (HW) durch das Software-Produkt<br />
bei gegebenem Funktionsumfang.<br />
Die Hardware soll bei gegebenem Funktionsumfang eines Produktes möglichst<br />
sparsam benutzt werden (hohe Ablaufgeschwindigkeit, geringer Speicherbedarf).<br />
Effizienz war lange Zeit aufgrund hoher Hardwarekosten das beherrschende<br />
Qualitätsmerkmal, verliert aber bei ständig sinkenden Hardwarepreisen immer<br />
mehr an Bedeutung. Heute spielt Effizienz z. B. bei Realzeitsystemen eine große<br />
Rolle.<br />
Zuverlässigkeit: (siehe [So 01])<br />
Man kann Zuverlässigkeit von Software durch eine Funktion R(t) beschreiben. Sei<br />
fw(t) die Wahrscheinlichkeit, dass im Zeitraum von 0 – t ein Fehler auftritt, so gilt:<br />
R(t) = 1 – fw(t) (Zuverlässigkeitsfunktion)<br />
Geht R(t) auch für große t gegen 1, dann nennt man ein Softwareprodukt zuverlässig.<br />
Falls R(t) bereits für kleine t nahe bei 0 liegt, ist das Produkt unzuverlässig.<br />
Robustheit:<br />
Robustheit ist der Grad, in dem ein Produkt eine vernünftige Reaktion bei nicht<br />
vorgesehener Verwendung erbringt und seine Funktionsfähigkeit bewahrt. Man<br />
setzt voraus, dass Hardware- und Eingabefehler vorkommen können und verlangt,<br />
dass dadurch keine Katastrophe geschehen soll.<br />
Benutzbarkeit:<br />
Benutzbarkeit (auch Benutzungskomfort oder Benutzerfreundlichkeit) umfasst alle<br />
Software-Eigenschaften, die dem Anwender ein einfaches, angenehmes, effizientes<br />
und fehlerarmes Arbeiten mit dem Software-Produkt gestatten. Dabei sind auch<br />
viele ergonomische Kriterien zu berücksichtigen wie: Lernaufwand, Installationsaufwand,<br />
einfache und einheitliche Benutzeroberfläche, Robustheit usw. (<br />
Benutzerschnittstelle, Software Ergonomie.<br />
Fehlertoleranz:
Das System muss im Falle eines erkannten Fehlers den Benutzer situationsgerecht<br />
informieren. Das System muss immer bedienbar bleiben, d. h. alle auftretenden<br />
Fehlerbedingungen müssen abgefangen werden.<br />
Sicherheit:<br />
unter dem Begriff sind alle System-Eigenschaften zusammengefasst:<br />
• die verhindern, dass ein technisches System in einen gefährlichen Zustand gerät,<br />
• die verhindern, dass Software-Systeme unbefugt benutzt werden,<br />
• die verhindern, dass Daten oder Programme unbeabsichtigt oder mutwillig zerstört<br />
oder verfälscht werden,<br />
• und die dafür sorgen, dass eine ordnungsgemäße und revisionsfähige Verarbeitung<br />
im Sinne geltender Normen und Gesetze sichergestellt wird.<br />
Erweiterbarkeit:<br />
Wie einfach ist es auch noch nach Fertigstellung den Leistungsumfang des Software-Produktes<br />
durch Einbau zusätzlicher Funktionen zu verändern und dabei<br />
einer speziellen Anwendungssituation anzupassen.<br />
Änderbarkeit:<br />
Grad, in dem ein Produkt die Veränderung (Anpassung) seiner Eigenschaften<br />
durch den Benutzer zulässt. Die Änderung erfolgt über definierte Schnittstellen,<br />
nicht durch Veränderung des Quellcodes.<br />
Wartbarkeit:<br />
Die Wartbarkeit eines Systems wird nach der Zeitdauer beurteilt, die im<br />
produktiven Einsatz nach Auftreten und Meldung eines Fehlers erforderlich ist,<br />
um diesen zu lokalisieren und zu beheben. Diese Qualitätseigenschaft wird<br />
beeinflusst von der Änderbarkeit, Verständlichkeit und Testbarkeit.<br />
Verständlichkeit:<br />
Bezieht sich auf die Lesbarkeit des Codes, den Aufbau des Systems, seine Architektur,<br />
die Modularisierung der Komponenten. Je übersichtlicher ein System gegliedert<br />
(verfeinert) ist um so größer ist seine Verständlichkeit<br />
Testbarkeit<br />
Je übersichtlicher und verständlicher ein System gegliedert ist, umso einfacher ist<br />
es zu testen. Korrektur von Fehlern in der Wartung beseitigen Fehler, sie können<br />
aber neue Fehler in das System einschleusen. Testbarkeit bezeichnet den Aufwand,<br />
der zum Testen einer Anwendung nötig ist.<br />
Übertragbarkeit:<br />
17
18<br />
ein System ist portabel, wenn es leicht in neue oder andere Hardware- und<br />
Software-Umgebung überführt werden kann.<br />
Wiederverwendbarkeit:<br />
ist die Verwendung von bereits entwickelten Software-Komponenten in anderen<br />
Umgebungen, für die sie ursprünglich nicht geplant waren. Wiederverwendbarkeit<br />
ist nicht nachträglich zu erreichen. Ein System muss so konzipiert werden, dass die<br />
entwickelten Komponenten wiederverwendbar sind.<br />
Abhängigkeiten zwischen Qualitätseigenschaften<br />
Die Qualitätseigenschaften sind nicht unabhängig voneinander. Werden Maßnahmen<br />
zur Verbesserung einer Qualitätseigenschaft getroffen, so wirken sich<br />
diese möglicherweise auf andere Eigenschaften aus. Wird die Effizienz eines Systems<br />
verbessert, so kann dies ein unzuverlässigeres System bewirken; die Robustheit<br />
kann sinken, das System kann schwerer änderbar sein (weil z. B. die<br />
Effizienzsteigerung durch Assemblerprogramme erreicht wurde). Hardwarenahe<br />
Programmiersprachen wirken sich natürlich auch auf die Wartbarkeit und<br />
Übertragbarkeit aus.<br />
Maße für Qualität<br />
Wie oben beschrieben, muss schon bei der Spezifikation die Qualität der zu erstellenden<br />
Software definiert werden, so dass nach der Fertigstellung nachgeprüft<br />
werden kann, ob die Software den Qualitätsanforderungen genügt. Zum Beispiel<br />
kann die Qualitätseigenschaft Funktionserfüllung geprüft werden, indem getestet<br />
wird, ob die Software so funktioniert wie vereinbart, d.h. ob die Software das tut,<br />
was in der vom Auftraggeber abgezeichneten Spezifikation steht. Die Effizienz<br />
kann durch Angabe von maximalen Antwortzeiten spezifiziert werden, die Zuverlässigkeit<br />
durch einen Wert für R(t). Andere Maße, wie die z. B. Erweiterbarkeit<br />
oder Wartbarkeit sind schwieriger zu definieren, wir werden im Kapitel 7<br />
Softwaremetriken näher auf mögliche Maße eingehen.
1.6 Phasen der Softwareentwicklung<br />
Um qualitativ hochwertige Software zu produzieren muss das Produkt modular<br />
aufgebaut werden. Zusätzlich ist es nötig auch den Produktionsprozess nach<br />
Prinzipien zu strukturieren, die auch in anderen Ingenieursdisziplinen üblich sind.<br />
Man spricht in diesem Zusammenhang von ingenieurmäßigem Vorgehen bei der<br />
Softwareentwicklung. Ein Softwareprojekt muss, wie jeder andere industrielle<br />
Fertigungsprozess auch, in mehrere Phasen eingeteilt werden. Frick beschreibt in<br />
[Frick95] die Merkmale eines industriellen Fertigungsprozesses:<br />
1. Der Prozess läuft in Phasen ab.<br />
2. Jede Phase liefert Ergebnisse, die die Grundlage für die Folgephase darstellen.<br />
3. Es findet eine Überprüfung der Phasenergebnisse statt, bevor die Folgephase<br />
anläuft (wobei es notwendig werden kann, die gleiche Phase noch einmal<br />
durchzuführen).<br />
4. In jeder Phase entsteht eine abstrakte Darstellung des Produktes, je fortgeschrittener<br />
die Phase, desto konkreter wird die Darstellung.<br />
Diese allgemeinen Anforderungen an einen Fertigungsprozess gelten auch für die<br />
Softwareerstellung. Durch den Einsatz von Phasenmodellen wird ein Softwareprojekt<br />
zeitlich strukturiert. Es wird festgelegt:<br />
• welche Arbeiten in den einzelnen Phasen zu erledigen sind,<br />
• welche Arbeitsergebnisse in den Phasen erzeugt werden müssen,<br />
• welche Personen die Ergebnisse zu erarbeiten haben,<br />
• wie die Ergebnisse dokumentiert werden sollen,<br />
• welche Termine eingehalten werden müssen,<br />
• einzuhaltende Standards und Richtlinien.<br />
Phasenmodelle regeln auch die Zusammenarbeit zwischen den am Softwareerstellungsprozess<br />
beteiligten Rollen und Personen.[Kimm79].<br />
Es existieren verschiedene Phasenmodelle für die Softwareentwicklung.<br />
Das "Ur-Modell" ist das so genannte Wasserfallmodell, das ein rein sequentielles<br />
Durchlaufen der Phasen vorsah. Die Arbeiten einer Phase mussten abgeschlossen<br />
sein, bevor die Folgephase beginnen konnte. Dieses Vorgehen erwies sich in der<br />
19
20<br />
Praxis als undurchführbar. Es wurde so erweitert, dass Rücksprünge in zeitlich<br />
früher liegende Phasen möglich wurden. Am Ende jeder Phase werden die Ergebnisse<br />
überprüft und an die Folgephase weitergegeben. Wird dort während der Erarbeitung<br />
der eigenen Phasenergebnisse, ein Fehler in den Vorgaben festgestellt, so<br />
werden die Vorgaben an die vorhergehende Phase zurückgeführt.<br />
In den letzten Jahren hat sich eine Vielzahl von weiteren Prozessmodellen herausgebildet,<br />
die dieses Modell variieren, z. B. durch ein mehrmaliges Durchlaufen<br />
der Phasen des Wasserfallmodells in mehreren Zyklen, wobei am Ende jedes Zyklus<br />
eine weitere Ausbaustufe des Systems entsteht. Prototyping-Ansätze wurden<br />
in das Wasserfallmodell integriert.<br />
Ob wir nun in mehreren Zyklen entwickeln, d. h. erst ein Basissystem und in den<br />
Folgezyklen dieses Basissystem immer wieder durch weitere Teilsysteme ergänzen<br />
oder ob wir das Gesamtsystem als ganzes entwickeln, wir durchlaufen während des<br />
Softwareentwicklungsprozesses immer verschiedene aufeinander aufbauende<br />
Phasen:<br />
Implementierung und Test<br />
Diese zentrale Phase des Softwareentwickungsprozesses kennen wir schon aus der<br />
Lehrveranstaltung Programmieren. (Zumindest kleine Programme wurden von Ihnen<br />
bereits implementiert und getestet.)<br />
Bei großen Systemen können wir das System nicht als Ganzes implementieren und<br />
testen, sondern wir implementieren und testen zuerst die einzelnen Komponenten<br />
(Komponententest). Anschließend werden diese ausgetesteten Komponenten<br />
schrittweise zusammenmontiert und ausgetestet (Integrationstest).<br />
Vor Beginn der eigentlichen Codierung ist die Implementierungsstrategie festzulegen.<br />
Es wird entschieden, in welcher Reihenfolge die Komponenten implementiert<br />
und zusammengebaut werden (Top-Down- oder Bottom-Up-Vorgehensweise).<br />
Die einzusetzenden Bibliotheken sind festzulegen. Detaillierte Testpläne<br />
für die einzelnen Komponenten, für die Teilsysteme und das Gesamtsystem sind,<br />
falls nicht schon in vorhergehenden Phasen geschehen, zu erstellen.<br />
Abnahme<br />
Auch diese Phase kennen wir vom Programmierpraktikum.<br />
In dieser Phase wird geprüft, ob die Leistungen des Systems mit den in der Spezifikation<br />
vereinbarten Leistungen übereinstimmen (im Programmierpraktikum: mit
den in der Aufgabenstellung geforderten Leistungen). Ist ein externer Auftraggeber<br />
vorhanden, überprüft dieser oft die Systemfunktionen mit einem eigenen Prüfkatalog.<br />
Im Programmierpraktikum bekamen Sie dann Ihre Abnahme und der Sinn der Implementierung<br />
war erfüllt. Sie sind wieder einen Schritt in Ihrem Studium<br />
vorangekommen.<br />
Bei der kommerziellen Softwareentwicklung soll die Software nach der Implementierung<br />
natürlich auch zum Einsatz kommen. Es kommt eine weitere Phase,<br />
der eigentliche Einsatz, d. h. der Betrieb des Systems.<br />
Betrieb<br />
Bezogen auf die Lebensdauer eines Softwareproduktes ist die Betriebsphase eines<br />
Produktes die längste aller Phasen. Das erstellte Produkt wird in dieser Phase<br />
benutzt. Hier fallen mit ca. 80% der weitaus größte Teil der Kosten aller Phasen der<br />
Softwareentwicklung an, d. h. der Aufwand für die Erstellung übersichtlich<br />
entworfene und gut ausgetesteter Programme mit guter Dokumentation rentiert sich<br />
an dieser Stelle auf jeden Fall.<br />
Während des Betriebs eines Softwareproduktes werden zusätzliche Fehler und Unzulänglichkeiten<br />
am Produkt entdeckt. Diese werden dem Hersteller zur Korrektur<br />
gemeldet und verursachen Rücksprünge in zeitlich frühere Phasen.<br />
Während der Betriebszeit eines Softwareproduktes ändert sich der Einsatzzweck<br />
eines Produktes; die betrieblichen Abläufe, die von der Software unterstützt<br />
werden, ändern sich und die Software muss entsprechend angepasst oder verändert<br />
werden. Diese Aktivitäten werden häufig auch den Wartungsaktivitäten zugeordnet,<br />
bezeichnen aber eigentlich Arbeiten zur Weiterentwicklung der Software.<br />
Weitere Phasen bei der Softwareentwicklung<br />
Im Praktikum Programmieren wurde immer eine Aufgabe gestellt, d. h. die Definition<br />
war vorgegeben. Sie als Studierender mussten sich jetzt noch, falls nicht auch<br />
in der Aufgabenstellung vorgegeben, einige Gedanken über den Aufbau des<br />
Systems machen, und los ging es mit der Implementierung. Statt z. B. die<br />
Klassenstruktur inkl. der Beziehungen zwischen den Klassen graphisch darzustellen,<br />
konnten Sie, wegen der Übersichtlichkeit Ihrer kleinen Softwaresysteme,<br />
die Klassenstruktur meistens direkt als Header-File in C++ hinschreiben.<br />
Bei der Entwicklung von großen Systemen wird vor der eigentlichen Implementierung<br />
des Systems erst einmal eine Analyse durchgeführt, um zu wissen, ob<br />
und in welchem Umfang ein System erstellt werden sollte und ob eine Erstellung<br />
unter Kostengesichtspunkten ratsam und mit den Möglichkeiten der Firma<br />
21
22<br />
überhaupt möglich ist. Gemeinsam mit dem späteren Benutzer des Systems muss<br />
dann in einer Definitionsphase der Funktionsumfang genau spezifiziert und<br />
anschließend von der IT-Abteilung die IT-Lösung entworfen werden:<br />
Analyse<br />
In der Analysephase muss der Systemanalytiker zuerst das Anwendungsgebiet<br />
verstehen. Er muss begreifen was der Kunde will. Die Schwachstellen werden<br />
analysiert, Verbesserungsvorschläge werden geprüft und die zusätzlichen Wünsche<br />
an das System aufgenommen. Daraus wird abgeleitet was die Software aus<br />
fachlicher Sicht leisten soll. Die fachlichen Anforderungen an die Software werden<br />
dokumentiert und mit dem Benutzer abgestimmt. Es wird analysiert ob die<br />
Aufgabe durchführbar (lösbar) und finanzierbar ist und ob das notwendige Personal<br />
vorhanden ist. Es wird eine erste Kostenkalkulation vorgenommen.<br />
Fehler in der Analysephase sind sehr teuer, wirken sie sich doch auf alle folgenden<br />
Phasen aus. Die Dokumentation der Analyseergebnisse bilden die Kommunikationsgrundlage<br />
zwischen IT-Abteilung und Fachabteilung und müssen deshalb implementierungsunabhängig<br />
sein.<br />
Definition<br />
In dieser Phase werden die informellen Anforderungen der Analyse in eine vollständige,<br />
konsistente Spezifikation umgesetzt. Die Produktdefinition beschreibt<br />
wie das Produkt aus Benutzersicht funktionieren soll. Sie soll normalerweise implementierungsunabhängig<br />
formuliert sein. Die geforderten Qualitätseigenschaften<br />
werden in der Definitionsphase festgelegt. Der Abnahmetest wird mit dem<br />
Benutzer festgelegt.<br />
Entwurf<br />
Im Entwurf wird die IT-Lösung für das in den vorhergehenden Phasen spezifizierte<br />
Softwareprodukt entworfen. Es wird entschieden welche Hardware und welches<br />
Betriebssystem nötig sind. Die Programmiersprache wird gewählt.<br />
Benutzerschnittstelle, Datenbank und notwendige Systemschnittstellen zu Fremdsystemen<br />
werden festgelegt. Hier wird die Komponentenarchitektur definiert, d. h.<br />
das System wird in Komponenten (Klassen, Funktionen) zerlegt, die in<br />
Komponentenarchitekturdiagrammen (Klassendiagramm, Sequenzdiagramm)<br />
dargestellt werden. Das gewählte Softwareentwicklungsparadigma bestimmt die<br />
Methoden, die dafür eingesetzt werden. Komponententestpläne werden entworfen.<br />
In dem Entwurf wird festgelegt wie das System aufzubauen ist, damit es die in der<br />
Definition festgelegte Leistung erbringen kann.
Ergebnisse der Phasen, Reviews<br />
Als Ergebnis jeder Phase entstehen Dokumente, die als Grundlage für das Weiterarbeiten<br />
in der Folgephase dienen. Diese Ergebnisse (und evtl. auch innerhalb der<br />
Phasen an so genannten Meilensteinen anfallende Zwischenergebnisse) werden in<br />
so genannten Reviews geprüft und mit den Erstellern diskutiert. Dieser Schritt ist<br />
sehr wichtig, da Fehler in frühen Phasen der Softwareentwicklung in späteren Phasen<br />
nur mit sehr hohen Kosten behoben werden können. (Z. B. Fehler oder missverständliche<br />
Formulierungen in der Spezifikation werden erst zum Zeitpunkt der<br />
Abnahme festgestellt => alle Phasen müssen nochmals durchlaufen werden, man<br />
muss sich in den Aufbau des Programms hineindenken und Änderungen im Code<br />
sind vorzunehmen. Ein nicht zu unterschätzender Faktor ist der Test<br />
(Komponenten- und Integrationstest des gesamten Systems) und das Anpassen der<br />
Dokumentation.<br />
Eine ausführliche Betrachtung von Phasenmodellen ist in einem gesonderten Kapitel<br />
weiter hinten im Skript durchgeführt.<br />
1.7 Überblick über den Aufbau des SWT-Skriptes<br />
In Kapitel 2 werden die Grundbegriffe der Objektorientierung wiederholt. Die<br />
Prinzipien der Objektorientierung und die objektorientierten Programmiersprachen<br />
werden zusammengefasst.<br />
Kapitel 3 gibt einen Überblick über die Modellierungssprache UML - Unified –<br />
Modeling Language. Alle Diagrammtypen der UML werden erläutert. Die<br />
wichtigsten Notationselemente werden beschrieben. Die Diagrammtypen der UML<br />
werden an einem durchgängigen Beispiel demonstriert.<br />
Kapitel 4 fasst die aktuellen Vorgehens- und Prozessmodelle zusammen. Das<br />
historische Wasserfallmodell beschreibt die Phasen eines Softwareprojektes und<br />
die Zusammenhänge zwischen den Phasen. Das V-Model ist aus dem<br />
Wasserfallmodell hervorgegangen und beschreibt als Standardmodell von<br />
Bundesbehörden das Vorgehen einer großen Organisation. RUP und extreme<br />
Programming stellen aktuelle Entwicklungen im Bereich der Vorgehensmodelle<br />
dar.<br />
Die prototypische Entwicklung wird erläutert.<br />
Im Abschnitt CMM/ISO 9000, SPICE liegt der Fokus auf der Bewertung der<br />
Qualität von Entwicklungsprozessen.<br />
23
24<br />
Der 2. Teil des Skriptes wird zum WS 04/05 erscheinen und folgenden Inhalt<br />
umfassen:<br />
• Requirements Engineering<br />
• Software Architektur und Patterns<br />
• Qualitätsmanagement<br />
• Testmanagement<br />
• Konfigurationsmanagement<br />
• vollständige Darstellung der UML<br />
• Petrinetze und Entscheidungstabellen.
2 Objektorientierung<br />
2.1 Einführung<br />
Objektorientierte Programmierung (kurz OOP) ist seit den 90er Jahren das zentrale<br />
Programmiersprachenparadigma für viele Arten von Softwaresystemen. Ziel der<br />
Einführung der Objektorientierung war die Erstellung von robusteren,<br />
fehlerärmeren und besser wartbaren Programmen.<br />
Das fundamentale Konstrukt der Objektorientierung ist das Objekt, das sowohl<br />
Daten (die Attributen als Eigenschaften des Objekts) als auch das Verhalten (die<br />
Logik des Objekts) vereinigt. Damit wird es möglich, Software aus einer<br />
Sammlung von konkreten Objekten zu erstellen. Jedes Objekt ist hierbei eindeutig<br />
über einen sog. Handle (Referenz) identifizierbar. Je nach Programmierumgebung<br />
kann ein Handle beispielsweise als eine Adresse zu einem Speicherbereich<br />
realisiert sein. Objekte können durch Kenntnis des Handle mit anderen Objekten<br />
kommunizieren. Man spricht in diesem Zusammenhang von einem<br />
Nachrichtenaustausch zwischen Objekten. Aufgrund einer eingehenden Nachricht<br />
führt das Objekt eine bestimmte Operation aus. Eine Operation wird durch Aufruf<br />
einer Methode des Objekts realisiert. Eine Methode repräsentiert somit das<br />
Verhalten eines Objektes. Oft wird sprachlich nicht zwischen einer Methode und<br />
einer Operation unterschieden und beide Begriffe synonym verwendet.<br />
Als Beispiel werden nachfolgend Polygon-Objekte betrachtet (siehe Abbildung 2-<br />
1).<br />
Attribute<br />
- Kante<br />
- Kantenfarbe<br />
- Füllmuster<br />
Operationen<br />
- zeichnen<br />
- löschen<br />
- verschieben<br />
Abb. 2-1: Beispiel "Polygon-Objekte"<br />
25
26<br />
Ein konkretes Polygon-Objekt ist beispielsweise das Viereck. Dieses wird durch 4<br />
Kanten beschrieben, die Kantenfarbe und das Füllmuster. Polygon-Objekte können<br />
in diesem Beispiel auf drei Nachrichten reagieren: zeichen, löschen und<br />
verschieben.<br />
Im nächsten Abschnitt werden die Grundideen der objektorientierten<br />
Programmierung erläutert.<br />
2.2 Prinzipien der Objektorientierung<br />
2.2.1 Abstraktion<br />
Eine der wichtigsten Ideen der objektorientierten Programmierung ist die Trennung<br />
zwischen Konzept und Umsetzung. Hierzu wurden die Begriffe Klasse und Objekt<br />
eingeführt.<br />
Ein Objekt ist eine tatsächlich existierende Repräsentation einer "Sache" aus dem<br />
zu entwickelnden Anwendungssystem. Beispiele für Objekte sind das<br />
Personenobjekt "Schmidt", das Autoobjekt "VW-Käfer" oder das Druckerobjekt<br />
"Laserdrucker1". Objekte müssen instantiiert werden, damit die Eigenschaften und<br />
das Verhalten der Objekte in einem Programm genutzt werden können. Anstelle<br />
von Objekten spricht man auch gerne von den "Instanzen einer Klasse". In diesem<br />
Skript werden diese Begriffe synonym verwendet.<br />
Eine Klasse ist die Beschreibung eines oder mehrerer ähnlicher Objekte, d.h.<br />
Objekte des gleichen Typs. Objekte einer Klasse müssen sich nicht in allen Details<br />
gleichen, aber in vielen Eigenschaften übereinstimmen. Beispiel einer Klasse ist<br />
"Auto", das die Beschreibung aller Automarken von verschiedensten Hersteller<br />
repräsentieren kann. Die Attribute und Methoden der Klasse "Auto" müssen so<br />
gewählt sein, dass hiermit die unterschiedlichsten Ausprägungen gemäß den<br />
Projekt-Anforderungen umfassend beschrieben werden können.<br />
Die Unterscheidung zwischen Klasse und Objekt kann als Abstraktion angesehen<br />
werden. Hiermit wird es möglich, Details einer Problemstellung zu ignorieren und<br />
somit die Komplexität des Problems zu reduzieren. Es findet somit eine Abbildung<br />
der realen Welt in eine abstrakte logische Ebene (bestehend aus Klassen und<br />
Objekten) statt.<br />
2.2.2 Kapselung<br />
Eine Klasse fasst eine Menge von Daten und darauf operierender Funktionen (die<br />
sog. Methoden) zusammen. Die Daten werden durch einen Satz von Variablen<br />
repräsentiert. Diese werden als Attribute oder Instanzvariablen bezeichnet. Für die<br />
Klasse Auto könnten diese z. B. die Attribute Baujahr, Jahr der Erstzulassung,
Hubraum, Kennzeichen usw. sein. Für jedes Objekt wird ein eigenständiger Satz an<br />
Attributen angelegt.<br />
Die Funktionen werden in der Objektorientierung als Operationen bzw. als<br />
Methoden bezeichnet. Diese repräsentieren das Verhalten der Objekte. Die<br />
Methoden enthalten ausführbaren Programmcode und stellen die Schnittstelle zur<br />
Kommunikation mit anderen Objekten (einer anderen Klasse) dar. Das Verhalten<br />
eines Objektes ist festgelegt durch die aktuellen Attributwerte (der sog.<br />
Objektzustand) und dem Programmcode der jeweiligen Methoden.<br />
Da in der Objektorientierung Attribute und Methoden in einem Objekt<br />
zusammengefasst sind, bezeichnet man dies als Kapselung. Ein objektorientiertes<br />
System besteht somit aus einer Mengen von gekapselten Objekten (s. Abb. 2-2).<br />
m1()<br />
x1()<br />
2.2.3 Wiederverwendung<br />
Abb. 2-1Objekte eines objektorientierten Systems<br />
Durch Anwendung der Prinzipien der Abstraktion und Kapselung kann die<br />
Wiederverwendung von Programmteilen gefördert werden. Dies kann somit zur<br />
Erhöhung der Fehlerfreiheit und Effizienz <strong>beim</strong> Programmieren führen. Ein<br />
Beispiel sind die sog. Collections als Objekte, die eine Sammlung von Objekten<br />
anderen Typs verarbeiten können. Diese Collections ermöglichen sehr effizient<br />
typische Aufgaben wie beispielsweise das Durchsuchen, Sortieren oder Kopieren<br />
a1()<br />
27
28<br />
von Elementen. Hierzu stellen die Collection-Klassen unterschiedliche Methoden<br />
als Schnittstelle (Collection-API) zur Verfügung.<br />
Allerdings gibt es auch Grenzen ….<br />
2.2.4 Beziehungen<br />
Meistens existieren Objekte nicht isoliert sondern stehen in Beziehungen zu<br />
anderen Objekten. Hierbei werden unterschiedliche Beziehungsarten unterschieden.<br />
So kann zwischen Objekten beispielsweise eine "Teil-von"-Beziehung bestehen.<br />
Dies beschreibt eine Zusammensetzung eines Objektes aus anderen Objekten. So<br />
könnte beispielsweise ein Lampen-Objekt aus den Objekten für Birne, Fassung,<br />
Kabel und Widerstand bestehen.<br />
Eine andere zentrale Beziehung der Objektorientierung ist die Spezialisierung (istein-Beziehung).<br />
Diese wird in objektorientierten Programmiersprachen durch<br />
Vererbung ausgedrückt. Beispielsweise könnte ein Transportmittel als Schiff, Zug,<br />
Flugzeug und Strassenfahrzeug spezialisiert werden. Die Aussage ist, dass ein<br />
Schiff ein (spezielles) Transportmittel ist, aber auch ein Zug, ein Flugzeug oder ein<br />
Strassenfahrzeug. Diese Beziehung kann auch umgekehrt betrachtet werden. In<br />
diesem Falle spricht man von Generalisierung (Verallgemeinerung). Vererbungen<br />
können auch mehrstufig sein. So könnte beispielsweise ein Strassenfahrzeug<br />
weitere unterteilt werden in Auto, Zweirad und Lastkraftwagen. Auf diese Weise<br />
entstehen sog. Vererbunghierarchien, die in einer Baumstruktur (Ableitungsbaum)<br />
dargestellt werden. Die Modellierung von Vererbungshierarchien kann auch dazu<br />
eingesetzt, gegliederte Begriffstrukturen (sog. Taxonomien) für einen<br />
Anwendungsbereich zu definieren.<br />
Im Kapitel 3 werden im Rahmen der Betrachtung der UML (Unified Modelling<br />
Language) die unterschiedlichen Beziehungstypen erläutert.<br />
2.2.5 Polymorphismus<br />
Ein anderes wichtiges Konzept von objektorientierten Programmiersprachen ist die<br />
des Polymorphismus (Vielgestaltigkeit). Hierunter versteht man die Fähigkeit von<br />
Objektvariablen, Objekte unterschiedlicher Klassen und daraus abgeleiteten<br />
Klassen aufzunehmen. Aufgrund der definierten Vererbunghierarchien wird<br />
sichergestellt, dass nur Eigenschaften berücksichtigt werden, die auf allen Ebenen<br />
der Hierarchie definiert sind.<br />
Mit Polymorphismus wird es möglich, gleiche Methoden von unterschiedlichen<br />
Objekten der Hierrachie aufzurufen. Hierbei wird das Konzept des "Late Binding"<br />
vom "Early Bindung" unterschieden. Letzteres bedeutet, dass zur Compile-Zeit der<br />
Methodenaufruf bestimmt ist. "Late Binding" bedeutet, dass erst zur Laufzeit die<br />
Festlegung getroffen wird welche Methode aufgerufen wird. Der Vorteil dieses<br />
Konzeptes liegt darin, dass der Programmieraufwand für typbasierte
Fallunterscheidungen verringert werden können. Allerdings sollte hiermit<br />
vorsichtig umgegangen werden, da sich hiermit unter Umständen die<br />
Verständlichkeit und Wartbarkeit eines Programms deutlich verschlechtern kann.<br />
2.3 Überblick Objektorientierte Programmiersprachen<br />
Objektorientierte Programmierkonzepte können sehr weit rückverfolgt werden. Die<br />
erste objektorientierte Programmiersprache war Simula 67, die bereits 1967 alle<br />
wesentlichen Elemente einer objektorientierten Sprache enthielt. In den 70er und<br />
80er Jahren des letzten Jahrhunderts dominierten prozedurale<br />
Programmiersprachen wie beispielsweise Fortran, Pascal, C und COBOL. In der<br />
Folge wurden viele etablierte Programmiersprachen um objektorientierte<br />
Sprachmittel erweitert oder neue Programmiersprachen definiert. In den 90er<br />
Jahren erlangten C++ (zunächst als Erweiterung der Sprache C), Smalltalk und<br />
Java eine hohe Aufmerksamkeit. In jüngster Zeit gewinnt C# durch die<br />
Marketingoffensive von Microsoft an Bedeutung. Während Java und C++ sich<br />
mittlerweile bei der Anwendungsentwicklung bewährt haben, muss C# sich als<br />
echte Alternative erst noch beweisen. In den nächsten Abschnitten werden die<br />
wesentlichen Eigenschaften von C++, JAVA und C# kurz beschrieben.<br />
2.3.1 C++<br />
Anfang der 80er Jahre entstand als objektorientierte Erweiterung von C die<br />
Programmiersprache C++. Ein zentrales Ziel von Bjarne Stroustrup, dem Erfinder<br />
der Sprache, war die Nutzung objektorientierter Konzepte unter Beibehaltung der<br />
prozeduralen Bestandteile von C. Somit zählt C++ zu den sogenannten<br />
Hybridsprachen, da verschiedene Programmiersprachenparadigmen unterstützt<br />
werden. C++ erfuhr schnell eine weite Verbreitung und wurde in vielen Projekten<br />
auch aufgrund vorhandener Entwicklungswerkzeuge gerne genutzt. Schon früh<br />
wurden umfangreiche Klassenbibliotheken entwickelt, die Lösungen für bestimmte<br />
Fragestellungen anboten. Beispielsweise entwickelte Microsoft die MFC<br />
(Microsoft Foundation Class) zur Unterstützung der Entwicklung von Windows-<br />
Programmen. Auch eine Standard-C++-Bibliotek, die STL (Standard Template<br />
Library), zur Bearbeitung von Objektsammlungen steht Anwendungsentwickler<br />
zur Verfügung. Des Weiteren existiert eine Reihe von Spezialklassenbibliotheken<br />
wie z. B. IlogViews zur Entwicklung von anspruchsvollen grafischen Oberflächen.<br />
C++ wird auch heute noch immer dann eingesetzt, wenn die Performance der<br />
Applikation eine Rolle spielt. Einer der Gründe dafür ist, dass man mit C++ sehr<br />
effizient die Nutzung des Speicherplatzes und die Programmabarbeitung<br />
beeinflussen kann. Im Rahmen der Programmiervorlesungen im Bachelor-<br />
29
30<br />
Studiengang wird an der FH Darmstadt C++ als objektorientierte Basis-<br />
Programmiersprache gelehrt.<br />
2.3.2 JAVA<br />
Java wurde 1995 (als Nachfolger der Sprache Oak von James Gosling) von der<br />
Firma Sun Microsystems entwickelt. Ursprünglich wurde die Programmiersprache<br />
für die Gerätesteuerung ("Comsumer devices") entwickelt, fand aber schnell<br />
weitere Anwendungsgebiete. Java ist eine plattformunabhängige, objektorientierte<br />
Programmiersprache, die es unter anderem ermöglicht, interaktive Web-Seiten zu<br />
entwickeln. Mit Java programmierte Applikationen (Applets), die per HTML in<br />
Web-Seiten integriert werden, werden <strong>beim</strong> Öffnen der Seite übers Internet<br />
automatisch gestartet und ausgeführt.<br />
Java ist in weiten Teilen nicht nur mit C++ vergleichbar, sondern sogar identisch.<br />
Allerdings wurden bei der Entwicklung von Java einige Sprachbestandteile von<br />
C++ anders umgesetzt oder konsequent eliminiert. So existieren beispielsweise<br />
keine fehlerträchtigen Pointeroperationen wie in C++. Des Weiteren sorgt ein<br />
"Garbage Collector" für eine effiziente Speicherverwaltung und gibt nicht mehr<br />
benötigten Speicher automatisch wieder frei.<br />
Inzwischen werden auch "Mission critical" Systeme mit Java entwickelt. Hierbei<br />
kann auf eine große Java-Bibliothek zurückgegriffen werden. Die Sprache Java<br />
basiert auf einer umfangreichen Klassenbibliothek, die von Hause aus eine Menge<br />
an Basisfunktionalitäten zur Verfügung stellt. In diesem Bereich ist Java der<br />
Programmiersprache C++ klar überlegen. Ein gravierender Nachteil von Java ist<br />
die im Vergleich zu C++ geringere Performance. Da Java zunächst in einen<br />
plattformunabhängigen Byte-Code übersetzt wird, muss dieser anschliessend von<br />
einem virtuellen Java-Prozessor (der Java Virtual Machine) ausgeführt werden.<br />
Durch diesen Interprationsvorgang geht wertvolle CPU-Zeit verloren. Durch<br />
Einführung der J2EE (Java 2 Enterprise Edition) und der Verfügbarkeit von sog.<br />
Applikations-Servern können mit Java auch mehrschichtige Architekturen<br />
entwickelt werden. Schliesslich unterstützt Java damit auch die<br />
komponentenorientierte Softwareentwicklung und stelle somit eine state-of-the-art<br />
Programmiersprache dar.<br />
2.3.3 C#<br />
C# ist eine relativ neue objektorientierte Programmiersprache, die von der Firma<br />
Microsoft im Jahre 2001? veröffentlicht wurde. C# ist mit dem Anspruch<br />
entwickelt worden, einige Nachteile von C++ und Java zu beseitigen. Dennoch ist<br />
die Ähnlichkeit sehr hoch und die Frage stellt sich, ob C# sich am Markt<br />
durchsetzen wird und Java bzw. C++ längerfristig verdrängen kann.
C#-Programme werden in der .NET-Laufzeitumgebung ausgeführt. Das .NET-<br />
Framework stellt hierzu viele Funktionen zur Verfügung. Dies bedeutet, dass viele<br />
Vorgänge im Gegensatz zu C++ nicht der Steuerung des Programmierers<br />
unterliegen. Quellen werden in Assemblierungen kompiliert, die sowohl den<br />
kompilierten Code (ausgedrückt in der .NET-Zwischensprache IL) als auch<br />
Metadaten zur Beschreibung des kompilierten Codes enthalten. Der IL-Code<br />
(Intermediate Language) wird dann in der CLR (Common Language Runtime)<br />
ausgeführt. Nachfolgend werden einige weitere Unterschiede zu C++ bzw. Java<br />
genannt.<br />
Im Gegensatz zu C++ werden bei C# keine Header-Dateien verwendet. Um eine<br />
schnellere Analyse des C#-Codes zu erzielen, werden keine Makros unterstützt.<br />
Auch auf Vorwärtsdeklarationen wurde verzichtet, da die Reihenfolge der Klassen<br />
in den Quelldateien nicht von Bedeutung ist. Das Löschen von Objekten erfolgt in<br />
C#-Programmen über die Speicherbereinigung und wird ausgeführt, wenn das<br />
Objekt nicht länger benötigt wird. Destruktoren (= Finalisierungsroutinen) können<br />
zur Durchführung von Bereinigungsaufgaben eingesetzt werden, dies jedoch nicht<br />
im gleichen Umfang wie bei C++-Destruktoren.<br />
Wegen der architekturellen und strukturellen Ähnlichkeiten von .NET und der<br />
Java-2-Technik bieten beide Sprachen einen vergleichbaren Umfang. Teilweise<br />
sind sich die Sprachen derart ähnlich, dass man schon ein zweites Mal auf den<br />
Programmcode schauen muss, um die Sprachen unterscheiden zu können. Ein<br />
wesentlicher Nachteil von C# ist, dass die entwickelten Programme nur auf den<br />
Microsoft-Plattformen ablauffähig sind.<br />
2.4 Werkzeuge für die objektorientierte Entwicklung<br />
Um objektorientierte Softwaresysteme zu entwickeln, ist der Einsatz einer Reihe<br />
von leistungsfähigen Entwicklungswerkzeugen notwendig. Dies reicht<br />
beispielsweise von mächtigen Programmeditoren mit LSE-Fähigkeit (Language<br />
Sensitive Editing) sowie Assistenten und Wizards, komfortablen Debuggern und<br />
Analyse-Werkzeugen aber auch modernen Modellierungswerkzeugen. In den<br />
letzten Jahren sind viele leistungsfähige IDEs (Integrated Development<br />
Environments) entstanden, die viele Funktionen "unter einem Dach" dem<br />
Entwickler anbieten und oft auch durch Add-Ins (oder Plug-Ins) erweiterbar sind.<br />
Interessante Werkzeuge sind beispielsweise Visual Studio .NET von Microsoft und<br />
Eclipse der Apache Software Foundation (http://www.apache.org/).<br />
Schon sehr früh sind Modellierungswerkzeuge entstanden, die die Objektorientierte<br />
Analyse (OOA) und das Objektorientierte Design (OOD) unterstützen. Aufgrund<br />
des Bemühens, große Informationssysteme ingenieurmäßig (d.h. systematisch) und<br />
rechnergestützt zu entwickeln, entstanden leistungsfähige CASE-Werkzeuge<br />
31
32<br />
(Computer Aided Software Engineering). Ein CASE-System ist eine integrierte<br />
Software-Entwicklungsumgebung, die idealerweise den gesamten<br />
Softwarelebenszyklus unterstützt. Anfangs nutzten diese CASE-Werkzeuge<br />
unterschiedlichste Notationssprachen. Seit der weiten Verbreitung der UML<br />
(Unified Modelling Language) unterstützen alle CASE-Tools zumindest diese<br />
grafische Modellierungssprache. Durch die Integration von Methoden und<br />
Verfahren sowie deren Automatisierung soll ein rechnergestütztes System zur<br />
Unterstützung sämtlicher Phasen und Aktivitäten des Systemlebenszyklusses zur<br />
Verfügung gestellt werden.<br />
Alle marktrelevanten Tools unterstützen den Implementierungs-Prozess durch die<br />
Generierung von Programmfrakmenten in unterschiedlichen Zielsprachen aus den<br />
entwickelten UML-Modellen. Des weiteren sind moderne CASE-Werkzeuge in der<br />
Lage, den weiter entwickelten Code zu analysieren und das UML-Modell durch<br />
Reverse Engineering entsprechend anzupassen. Wird dieser Kreislauf im Rahmen<br />
eines Projektes mehrfach und systematisch genutzt, spricht man von Round-Trip<br />
Engineering.<br />
Im Rahmen des Softwaretechnik-Praktikums wird das CASE-Werkzeug Innovator<br />
der Firma MID eingesetzt. Weitere bekannte objektorientierte<br />
Modellierungswerkzeuge sind beispielsweise Rational Rose (IBM Rational),<br />
TogetherJ (Togethersoft), ObjectiF (MicroTool GmbH), Rhapsody (I-Logix) und<br />
ArgoUML (OpenSource).<br />
2.5 Weiterführende Literatur<br />
[Graham95] Graham, Ian: Migrating To Object Technology, Addison-Wesley<br />
Publishing Company, 1995.<br />
[Meyer97] Meyer, Bertrand: Object-Oriented Software Construction, 2 nd<br />
edition, Prentice Hall PTR, 1997.
3 UML Unified Modeling Language<br />
3.1 Was ist die UML?<br />
Die Unified Modeling Language ist eine Modellierungssprache, also eine Sprache<br />
zur Beschreibung von Software-Systemen. Sie bietet eine einheitliche Notation, die<br />
für alle Anwendungsgebiete nutzbar ist. Sie enthält Diagramme und natürlichsprachliche<br />
Beschreibungsformen. Die UML kann zur statischen und dynamischen<br />
Modellierung von Analyse, Design und Systemarchitektur eingesetzt werden. Sie<br />
unterstützt objektorientierte Vorgehensweisen, ist aber auch zur Modellierung<br />
nicht-objektorientierter Systeme geeignet.<br />
Die UML 2.0 enthält gegenüber den Vorgängerversionen zahlreiche Neuerungen.<br />
Diese Neuerungen wurden notwendig um die aktuellen Entwicklungen im Bereich<br />
der Programmiersprachen (Java, C#) abzudecken und um technologische<br />
Entwicklungen (Komponententechnologie, Application Server), die sich nach der<br />
Definition der Versionen 1.x entwickelt haben, zu berücksichtigen. Der in den<br />
letzten Jahren expandierende Mark der Embedded Systems (eingebettete Systeme)<br />
lenkte den Fokus stärker auf die Elemente der UML, die die Modellierung von<br />
Real-Time-Systemen unterstützen.<br />
3.2 Entstehung der UML<br />
Im Zeitraum Ende der achtziger bis Anfang der neunziger Jahre entstanden mehrere<br />
Notationen zur Modellierung von OO-Systemen. Die Grundlage der Notationen<br />
waren objektorientierte Programmiersprachen, wie Smalltalk und C++. Einige der<br />
wichtigsten Notationen waren:<br />
• Booch (Grady Booch)<br />
• OMT (James Rumbaugh)<br />
• OOSE (Ivar Jacobson)<br />
• Shlaer/Mellor<br />
• Coad/Yourdon<br />
• u. a.<br />
Seit 1994/1995 arbeiteten die "drei Amigos" Grady Booch, James Rumbaugh und<br />
Ivar Jacobson in ihrer gemeinsamen Firma Rational Rose an einer Methode, die die<br />
Vorteile der einzelnen Notationen vereinen und die ihre Nachteile eliminieren<br />
sollte. Es entstand, in Zusammenarbeit mit vielen Firmen aus der Software-Industrie,<br />
die Unified Method 0.8, die bis 1997 zur Unified Modeling Language 1.1<br />
weiterentwickelt wurde. Die Notation der UML 1.1 war so umfangreich, dass der<br />
33
34<br />
Anspruch eine Methode zu definieren auf die Definition einer Modellierungssprache<br />
reduziert wurde.<br />
Die UML 1.1 wurde 1997 bei der Object Management Group (OMG) eingereicht<br />
und wurde ein weltweiter Standard im Bereich der Objekt-Orientierten Entwicklung.<br />
Die erste Version der UML wurde bis zur UML 1.5 weiterentwickelt.<br />
Um die UML an neue Technologien wie Componentware, serverbasierte Technologien,<br />
u. a. anzupassen, wurde die Struktur der UML 1.x gründlich überarbeitet.<br />
Zur Zeit (SS 2004) liegt die UML 2.0 als Entwurf vor. Sie wird im 2. Halbjahr<br />
2004 verabschiedet werden.<br />
3.3 Diagramme der UML 2.0<br />
Die UML 2.0 definiert die nachfolgenden Diagramme. In der UML 2.0 ist es<br />
möglich Diagramme zu schachteln; man kann also eine Hierarchie von Diagrammen<br />
erstellen, bei der Details eines Diagramms in einem weiteren Diagramm<br />
"verfeinert" werden. Diagramme können über definierte Schnittstellen miteinander<br />
verknüpft werden; ein Diagramm kann Verhalten, das in einem anderen Diagramm<br />
modelliert ist über eine definierte Schnittstelle aufrufen. Es ist möglich<br />
Diagrammvererbungen zu nutzen und Vererbungsbeziehungen zwischen Diagrammen<br />
aufzubauen. Diagramme, die Verhalten modellieren, können mit Einund<br />
Ausgabeparametern versehen werden. Programmierkonstrukte wie Schleifen<br />
und Verzweigungen können dargestellt werden.<br />
• Strukturdiagramme<br />
• Klassendiagramm -Class Diagram<br />
• Objektdiagramm - Object Diagram<br />
• Komponentendiagramm - Component Diagram<br />
• Paketdiagramm - Package Diagram<br />
• Kompositionsstrukturdiagramm - Composite Structure Diagram<br />
• Verteilungsdiagramm - Deployment Diagram<br />
• Verhaltensdiagramme<br />
• Aktivitätsdiagramm - Activity Diagram<br />
• Anwendungsfalldiagramm - Use Case Diagram<br />
• Zustandsdiagramm -State Machine Diagram<br />
• Interaktionsdiagramme<br />
• Interaktionsübersichsdiagramm - Interaction Overview Diagram<br />
• Sequenzdiagramm - Sequence Diagram<br />
• Kommunikationsdiagramm - Communication Diagram<br />
• Zeitverlaufsdiagramm - Timing Diagram
Strukturdiagramme<br />
werden in der UML verwendet um die statische Struktur (zeitunabhängige<br />
Aspekte) von Systemen zu beschreiben. Sie können zur Beschreibung der interne<br />
Struktur einzelner Klassen bis zur Definition der Architektur komplexer Systeme<br />
verwendet werden. Die UML enthält die oben genannten Strukturdiagramme zur<br />
Beschreibung struktureller Aspekte von Klassen, Objekten, Komponenten und Paketen.<br />
Das Kompositionsstrukturdiagramm zeigt die interne Struktur eines<br />
Elementes (Klasse, Komponenten, Use Case) und seine Interaktionspunkte zu<br />
anderen Systemteilen. Das Verteilungsdiagramm zeigt die dynamische Zuordunung<br />
von Softwareelementen zu Hardwareelementen eines Systems.<br />
Verhaltensdiagramme<br />
Verhaltensdiagramme beschreiben Aspekte eines Systems, die sich mit dem dynamischen<br />
Verhalten von Systemelementen beschäftigen. Verhaltensdiagramme<br />
modellieren bestimmte dynamische Aspekte eines Systems, unter<br />
Vernachlässigung anderer Zusammenhänge.<br />
Interaktionsdiagramme<br />
sind eine Untermenge der Verhaltensdiagramme. Sie beschreiben die Kommunikation<br />
zwischen Kommunikationspartnern.<br />
35
36<br />
Begriffe der UML<br />
Da die UML Spezifikation in englischer Sprache verfasst ist, werden in Veröffentlichungen<br />
häufig deutsche und englische Begriffe verwendet. Zur Erleichterung der<br />
Übersetzung existiert eine UML Übersetzungstabelle, die alle wesentlichen<br />
englischen Begriffe in die deutsche Sprache übersetzt. Sie ist zu finden unter<br />
http://www.oose.de. Auf diesem Server befindet sich auch ein Glossar, das alle<br />
Begriffe der UML erklärt. Auch in den Spezifikationsdokumenten der UML [Omg<br />
03Super] und [Omg 03Infra] sind die verwendeten Begriffe in einem Glossar<br />
definiert.<br />
Einige zentrale, diagrammübergreifende Begriffe der UML werden hier kurz<br />
erläutert.<br />
Artifact - Artefakt<br />
In der UML Spezifikation werden Ergebnisse oder Produkte eines Entwicklungsprozesses<br />
als artifact bezeichnet. Ein artifact ist also z. B. eine Klasse, ein Diagramm,<br />
eine Beschreibung eines Elementes.<br />
Note - Notiz, Anmerkung<br />
Jedes UML Element kann mit einer Notiz versehen werden. Die Notiz wird über<br />
eine gestrichelte Linie mit dem Element verbunden, das beschrieben wird.<br />
Abbildung 3.3.1Beispiel Notiz in UML Diagrammen<br />
Szenario<br />
Ein Szenario ist eine Szene eines Modells, also ein Ausschnitt, für den nur bestimmte<br />
Aspekte des Gesamtsystems dargestellt werden.<br />
Constraint - Einschränkung<br />
Eine Einschränkung ist eine Bedingung, die bei der Implementierung eines Systems<br />
erfüllt sein muss. Constraints werden in geschweiften Klammern geschrieben<br />
und mit einer gestrichelten Linie mit dem Element verbunden, auf das sie sich beziehen.
Abbildung 3.3.2Beispiel Constraint<br />
In Abbildung 3.3.2 wird die Einschränkung formuliert, dass das Immatrikulationsdatum<br />
eines Studenten immer größer sein muss, als das Geburtsdatum.<br />
Die UML benutzt die Object Constraint Language (OCL) zur formalen Spezifikation<br />
von Einschränkungen (vgl. Kapitel 3.4).<br />
Classifier<br />
Ein Classifier bezeichnet in der UML ein Grundelement der UML, z. B. eine<br />
Klasse, Assoziation, Datentyp. Die Grundelemente der UML werden zu dem<br />
Element Classifier abstrahiert. Ein Classifier steht in der UML-Spezifikation<br />
immer für ein definiertes Element der UML. Es gibt aber kein grafisches Symbol<br />
für den Classifier.<br />
Stereotype - Stereotyp<br />
Stereotypen werden verwendet um Elemente zu Kategorien von Elementen zusammenzufassen.<br />
Man kann Klassen z. B. nach ihrer Verwendung in Oberflächenklassen<br />
(Stereotyp boundary), Entitätsklassen (Stereotyp entity) und fachliche<br />
Klassen (Stereotyp control) einteilen. Die UML kann durch Definition neuer<br />
Stereotypen erweitert werden. In Abbildung 3.3.1 ist der Stereotyp entity für die<br />
Klasse angegeben.<br />
3.3.1 Klassendiagramm Class Diagram<br />
3.3.1.1 Zweck<br />
Klassendiagramme stellen die statische Struktur eines Systems dar. Sie zeigen die<br />
Klassen, die Eigenschaften der Klassen (Attribute), das Verhalten (Operationen)<br />
der Klassen und die Beziehungen zwischen den Klassen.<br />
Sie sind der zentrale Diagrammtyp der UML und werden in allen Phasen der Softwareentwicklung<br />
eingesetzt.<br />
3.3.1.2 Notation<br />
37
38<br />
Symbol Bedeutung<br />
Klasse<br />
Ein Klasse kann als Rechteck dargestellt werden, das<br />
den Klassennamen enthält. Üblicherweise bestehen<br />
Klassen aus drei Bereichen; der obere Bereich enthält<br />
den Stereotyp, das Paket zu dem die Klasse gehört und<br />
den Namen. Im mittleren Bereich werden die Attribute<br />
angegeben und im unteren Bereich stehen die Operationen<br />
der Klasse. Laut UML-Spezifikation kann die<br />
Darstellung einer Klasse zusätzliche Bereiche enthalten.<br />
Abstrakte Klasse<br />
Der Name einer abstrakten Klasse wird kursiv geschrieben.<br />
Alternativ kann die Eigenschaft {abstract}<br />
angegeben werden.<br />
Parametrisierte Klasse<br />
auch Template oder Schablone genannt. Die parametrisierte<br />
Klasse hat in der rechten, oberen Ecke ein das<br />
Klassensymbol überlappendes Rechteck, das die Schablonen-Parameter<br />
der Klasse enthält. Die Funktion, die<br />
den Parameter verwendet wird angegeben. Die Klasse,<br />
die den Parameter bindet, wird über eine gestrichelte<br />
Linie mit Pfeil an dem Template verbunden. Diese<br />
trägt die Bezeichnung .<br />
Assoziation<br />
Eine Linie zwischen den Klassen stellt eine Assoziation<br />
dar. Eine Assoziation ist eine Beziehung zwischen<br />
Klassen. Die Objekte der Klassen kommunizieren über<br />
die Assoziationen miteinander. Die Assoziation kann<br />
einen Namen haben. Ein Pfeil an dem Assoziationsnamen<br />
gibt die Leserichtung des Namens an. An den<br />
Assoziationsenden können die Rollen der beteiligten<br />
Klassen und die Multiplizität angegeben werden. Die<br />
zweigliedrige Assoziation kann, wie die mehrgliedrige<br />
Assoziation, durch eine Raute markiert werden.
Symbol Bedeutung<br />
Gerichtete Assoziation<br />
Mit einem Pfeil an der Assoziation kann die Navigationsrichtung<br />
angegeben werden. Der Pfeil drückt die<br />
Zugriffsrichtung der Objekte aus. Objekt A greift auf B<br />
zu, B greift nie auf A zu.<br />
Vererbung<br />
auch Generalisierung/Spezialisierung genannt. Vererbungsbeziehungen<br />
werden mit einem Pfeil dargestellt.<br />
Die Pfeilspitze zeigt auf die Oberklasse. Die Oberklasse<br />
vererbt ihre Eigenschaften an die Unterklassen.<br />
Aggregation<br />
Eine Aggregation drückt eine Teile-Ganzes-Beziehung<br />
aus. Das Ganze-Objekt besteht aus Teil-Objekten. Die<br />
Raute befindet sich an dem Ende des Ganzen. Die<br />
Aggregation ist eine spezielle Art der Assoziation. Da<br />
das Ganze die Teile enthält, sollten am Assoziationsende<br />
der Teile ein Navigationspfeil stehen.<br />
Komposition<br />
Die Komposition ist auch eine Beziehung, die Teile zu<br />
einem Ganzen in Beziehung setzt. Die Teile und das<br />
Ganze sind bei dieser Beziehung existenzabhängig; die<br />
Teile können nicht ohne das Ganze existieren. Wird<br />
das Ganze gelöscht, so beenden auch die Teile ihre<br />
Existenz.<br />
Assoziationsklasse<br />
Ist eine Klasse von dem Vorhandensein einer Assoziation<br />
zwischen zwei Klassen abhängig, so kann dies<br />
durch eine Assoziationsklasse ausgedrückt werden. Die<br />
Assoziationsklasse beschreibt Eigenschaften, die keiner<br />
der an der Assoziation beteiligten Klassen sinnvoll<br />
zuordenbar sind. Die Assoziationsklasse wird über eine<br />
gestrichelte Linie mit der Assoziation, von der sie<br />
abhängt, verbunden. Hat die Assoziation einen Namen,<br />
dann muss die Assoziationsklasse den selben Namen<br />
erhalten. Die Assoziationsklasse ist ein Analysekonzept.<br />
39
40<br />
Symbol Bedeutung<br />
Tabelle 1Notation Klassendiagramm<br />
Klassen<br />
Mehrgliedrige Assoziation<br />
Eine mehrgliedrige Assoziation drückt eine Beziehung<br />
zwischen mehr als 2 gleichwertigen Klassen aus. Die<br />
Beziehung wird mit einer Raute markiert.<br />
Objekte und Klassen sind die zentralen Elemente objektorientierter Modelle. Die<br />
gemeinsamen Eigenschaften konkreter Objekte werden zu Klassen abstrahiert. Die<br />
Klasse definiert die Struktur ihrer Objekte. Die UML 2.0 versteht unter einer<br />
Klasse ein Element, das eine Menge Objekte beschreibt, die die selbe Spezifikation<br />
der Merkmale, Einschränkungen und Semantik teilen [Omg 03b]. Eine Klasse hat<br />
Attribute und Operationen. Attribute und Operationen können in UML spezifiziert<br />
werden.<br />
Die Syntax für die Deklaration von Attributen lautet: [Sichtbarkeit] [/]<br />
Name [:Typ] [=Wert]<br />
Die Syntax für die Deklaration von Operationen lautet: [Sichtbarkeit]<br />
Name [(Parameterliste)] [: Returntyp]<br />
Die Parameterliste ist definiert als:<br />
[Übergaberichtung] Name [: Typ] [ =Wert]<br />
Die Syntaxelemente haben nachfolgende Bedeutung:<br />
• Sichtbarkeit<br />
gibt an, wie die Sichtbarkeit eines Elementes relativ zu seiner Umgebung ist. Die<br />
Sichtbarkeit gibt also an, welche Elemente auf ein Attribut, bzw. auf eine<br />
Operation zugreifen können. Der Zugriff auf ein Attribut definiert den lesenden<br />
und schreibenden Zugriff auf das Attribut; die Sichtbarkeit von Operationen gibt<br />
an, welche Elemente die Operation aufrufen können. Folgende Sichtbarkeitsmodi<br />
sind definiert.<br />
• public: Jedes andere Element hat Zugriff.<br />
• privat: Der Zugriff ist auf die Objekte der Klasse selbst beschränkt.
• protected: Zugriff besteht nur für die definierende Klasse und die Vererbungslinien,<br />
die von ihr ausgehen.<br />
• package: Das Element ist sichtbar für alle Klassen, die sich im selben Paket<br />
befinden.<br />
• Der Slash [/] kennzeichnet ein abgeleitetes Element. Ein abgeleitetes Element<br />
kann aus einem anderen Modellelement berechnet werden.<br />
• Name<br />
gibt den Namen des Attributs oder der Operation an.<br />
• Typ, Returntyp<br />
gibt den Datentyp eines Attributs, eines Parameters oder Returns an. Die UML<br />
definiert einige Typen, wie Integer, String, u. a. Macht aber keine Einschränkungen<br />
zur Verwendung selbstdefinierter Typen. Es können alle Typen<br />
verwendet werden, die zur Lösung eines Problems benötigt werden.<br />
• Wert<br />
Attribute und Parameter können mit einem Wert belegt werden.<br />
• Übergaberichtung<br />
definiert die Richtung in die ein Parameter übergeben wird.<br />
• IN- Parameter wird an die Operation übergeben. Die Operation liest den Parameter<br />
nur.<br />
• OUT - der Parameter wird von der Operation geschrieben, ohne dass sie seinen<br />
Inhalt vorher verarbeitet.<br />
• INOUT - die Operation liest einen Parameter, verarbeitet ihn und schreibt ihn<br />
erneut.<br />
Beispiel<br />
Abbildung 3.3.1.2.1Klasse Konto mit UML-Deklarationen<br />
Abbildung 3.3.1.2.1 zeigt ein Beispiel einer Klasse "Konto" die in UML deklariert<br />
ist. Das Attribut "KontoNr" ist vom Typ Integer, für "Guthaben" wurde ein eigener<br />
Typ mit dem Namen Real definiert. Der Typ Real steht für eine reelle Zahl (z. B.<br />
Float in C++). Die Operation einzahlen nimmt den Parameter "Betrag" vom Typ<br />
Real an und gibt einen Boolean-Wert zurück. Die Sichtbarkeit der Elemente wurde<br />
ausgeblendet.<br />
41
42<br />
Implementierung in C++<br />
Abbildung 3.3.1.2.2Klasse Konto mit C++-Deklarationen<br />
Abbildung 3.3.1.2.2 zeigt die Klasse Konto mit Deklarationen in C++. Bei Einsatz<br />
eines CASE-Tools kann aus der UML-Deklaration die Deklaration in einer<br />
Zielsprache generiert werden.<br />
Class Konto<br />
{<br />
};<br />
private:<br />
int KontoNr;<br />
float Guthaben;<br />
public:<br />
virtual bool einzahlen(float Betrag);<br />
Parametrisierte Klassen<br />
werden auch Templates oder Schablonen genannt. Wenn mehrere Klassen sich nur<br />
durch die Daten, auf denen sie arbeiten unterscheiden, können sie durch parametrisierte<br />
Klassen realisiert werden. Die parametrisierten Klassen werden mit Parametern<br />
versehen, die Typen enthalten können. Somit ist es möglich typunabhängige<br />
Algorithmen zu definieren und parametrisierten Klasse zur Verarbeitung verschiedener<br />
Datentypen zu verwenden.<br />
Assoziation<br />
Im Klassendiagramm drückt eine Assoziation eine Beziehung zwischen Klassen<br />
aus. Die Assoziation kann einen Namen haben. Die Rollen der beteiligten Klassen
können angegeben werden, die Multiplizität muss spätestens im Designmodell<br />
angegeben werden.<br />
Beispiel<br />
Abbildung 3.3.1.2.3Assoziation in UML-Darstellung<br />
Das Beispiel in Abbildung 3.3.1.2.3 zeigt die Assoziation "studiert" zwischen den<br />
Klassen "Student" und "<strong>Fachbereich</strong>". Die Multiplizität ist mit * zu 1 angegeben;<br />
ein Student studiert immer an einem <strong>Fachbereich</strong>, ein <strong>Fachbereich</strong> hat viele Studenten.<br />
Für Assoziationen wird üblicherweise entweder ein Assoziationsname angegeben,<br />
oder die Rollennamen der beteiligten Klassen werden angegeben. Von der Multiplizität<br />
hängt es ab, wie die Assoziation implementiert wird. In diesem Beispiel<br />
muss ein Student auf einen <strong>Fachbereich</strong> zugreifen, weil der <strong>Fachbereich</strong> mit der<br />
Multiplizität 1 an der Beziehung beteiligt ist. Der Student ist mit der Multiplizität *<br />
beteiligt; der <strong>Fachbereich</strong> muss deshalb auf viele Objekte der Klasse Student zugreifen.<br />
Implementierung der Assoziation in C++<br />
Abbildung 3.3.1.2.4Realisierung der Assoziation in C++<br />
Abbildung 3.3.1.2.4 zeigt die Realisierung der Assoziation studiert in C++. Für die<br />
Attribute werden die Stereotypen angezeigt; Attribute vom Stereotyp <br />
beschreiben fachliche Eigenschaften der Klassen, der Stereotyp kennzeichnet Attribute, die eine Assoziation implementieren.<br />
43
44<br />
Der Student muss, wie oben beschrieben, auf den einen <strong>Fachbereich</strong> zugreifen zu<br />
dem er gehört. Dafür wurde bei dem Student der Pointer "<strong>Fachbereich</strong><br />
*fachbereich" deklariert, über den er auf den <strong>Fachbereich</strong> zugreift. Der <strong>Fachbereich</strong><br />
muss auf viele Studenten zugreifen. Für diesen Zugriff wurde die Menge<br />
"set students" deklariert. Ein Set ist eine Struktur der Standard<br />
Template Library und verwaltet eine Menge von Elementen.<br />
Vererbung<br />
Die Vererbung ist ein Grundkonzept objektorientierter Programmiersprachen und<br />
dient der Wiederverwendung von Quellcode. Sie wird verwendet um Eigenschaften<br />
einer Oberklasse an Unterklassen zu vererben. Alle Eigenschaften (Attribute und<br />
Operationen) der Oberklasse, die für die Unterklasse sichtbar sind, werden an diese<br />
vererbt. Sie sind in der Unterklasse benutzbar, als wären sie in der Klasse selbst<br />
definiert. Die Unterklassen dürfen weitere, speziellere Eigenschaften haben. Aus<br />
der Sichtweise der Oberklasse sind die Unterklassen immer speziellere Klassen;<br />
aus der Sichtweise der Unterklassen ist die Oberklasse die allgemeinere, generellere<br />
Klasse. Deshalb wird die Vererbung auch Generalisierung oder Spezialisierung<br />
genannt.<br />
Abbildung 3.3.1.2.5Vererbung in UML<br />
In Abbildung 3.3.1.2.5 vererbt die "Person" ihre Eigenschaften an "Student" und<br />
den "FH-Angestellten". Die "Person" ist die generelle Klasse, "Student" und "FH-<br />
Angestellter" sind spezielle Personentypen. Die "Person" hat die Attribute<br />
"Adresse" und "Name". Die Attribute der "Person" haben die Sichtbarkeit protec-
ted, damit sie an "Student" und "FH-Angestellter" vererbt werden. Attribute mit der<br />
Sichtbarkeit private sind nur in der Klasse selbst sichtbar und werden nicht an<br />
Unterklassen vererbt. Die Operation "aendereAdresse" ist public und wird ebenfalls<br />
an die Unterklassen vererbt. Der "Student" hat in diesem Beispiel die Attribute<br />
"Adresse", "Name" und "MatNr" und die Operationen "aendereAdresse",<br />
"immatrikulieren" und "exmatrikulieren". Die Einschränkung (constraint) "{incomplete}"<br />
gibt an, dass die Vererbung nicht vollständig ist; es gibt in einer<br />
Fachhochschule noch weitere Personentypen, die in der Vererbung nicht dargestellt<br />
sind. Die UML 2.0 definiert folgende constraints für Vererbungen:<br />
• complete<br />
• incomplete<br />
• disjoint<br />
• overlapping<br />
Implementierung der Vererbung in C++<br />
Aus dem UML-Diagramm in Abbildung 3.3.1.2.5 ergibt sich das in Abbildung<br />
3.3.1.2.6 dargestellte Diagramm in C++-Sicht.<br />
Abbildung 3.3.1.2.6Vererbung in C++<br />
Class Person<br />
{<br />
protected:<br />
cAdresse Adresse;<br />
45
46<br />
};<br />
string Name;<br />
public:<br />
virtual bool aendereAdresse(neuAdresse);<br />
class Student: public Analyse::Person<br />
{<br />
};<br />
private:<br />
int MatNr;<br />
<strong>Fachbereich</strong> *fachbereich;<br />
public:<br />
virtual bool immatrikulieren(einStudent);<br />
virtual int exmatrikulieren(einStudent);<br />
class FH_Angestellter: public Person<br />
{<br />
};<br />
private:<br />
int PersonalNr;<br />
public:<br />
virtual bool aendereGehalt(neuGehalt);<br />
Aggregation<br />
Die Aggregation wird verwendet um zwischen Klassen eine Teile-Ganzes-Beziehung<br />
aufzubauen. Abbildung 3.3.1.2.7 zeigt ein Beispiel einer Aggregation. Die<br />
Lehrveranstaltung setzt sich aus der Vorlesung und aus einem optionalen<br />
Praktikum zusammen. Die Multiplizität "0..1" mit der das Praktikum an der<br />
Aggregation beteiligt ist, drückt aus, dass es auch Lehrveranstaltungen ohne<br />
Praktikum gibt.
Abbildung 3.3.1.2.7Aggregation<br />
Da die Aggregation eine Spezialform der Assoziation ist, ist die Assoziation in<br />
durch zwei Assoziationen ersetzbar. Das Diagramm in Abbildung 3.3.1.2.7 ist<br />
äquivalent zu dem Diagramm in Abbildung 3.3.1.2.8. Die Aggregation wird hier<br />
durch die Rollenbezeichnung "besteht_aus" ausgedrückt.<br />
Abbildung 3.3.1.2.8Aggregation als Assoziation<br />
Implementierung der Aggregation in C++<br />
Da die Aggregation eine Spezialform der Assoziation ist, wird sie wie eine Assoziation<br />
implementiert.<br />
47
48<br />
Komposition<br />
Abbildung 3.3.1.2.9Komposition<br />
Das Beispiel in Abbildung 3.3.1.2.9 zeigt eine Komposition. Die Komposition ist<br />
eine strengere Form der Aggregation und drückt aus, dass das Ganze und die Teile<br />
existenzabhängig sind. Die Teile und das Ganze bilden eine untrennbare Einheit;<br />
sie können deshalb nur als Einheit existieren. Die Teile dürfen immer nur zu einem<br />
Ganzen gehören; das Ganze kann keine Multiplizität größer 1 haben.<br />
In diesem Beispiel besteht eine Rechnung aus dem Rechnungskopf und den Positionen.<br />
Eine Rechnungsposition kann nur zu einer Rechnung gehören. Es kann<br />
keine Rechnungsposition geben, wenn es keine Rechnung gibt. Wird die Rechnung<br />
gelöscht, muss sie alle Rechnungspositionen und den Rechnungskopf löschen.<br />
Assoziationsklasse<br />
Die UML 2.0 definiert eine Assoziationsklasse als eine Assoziation, die<br />
Klasseneigenschaften hat, oder als Klasse, die Assoziationseigenschaften hat. Die<br />
Assoziationsklasse bezieht sich immer auf das Vorhandensein einer Beziehung<br />
zwischen Klassen und auf die Eigenschaften, die diese Beziehung zusätzlich hat.<br />
Der Name der Beziehung und der Name der Assoziationsklasse repräsentieren<br />
dasselbe Modellelement. Hat die Assoziation zu der die Assoziationsklasse assoziiert<br />
ist, einen Namen, dann muss die Assoziationsklasse den selben Namen tragen.<br />
Es genügt jedoch einem Element einen Namen zu geben.
Abbildung 3.3.1.2.10Assoziationsklasse<br />
In dem Beispiel in Abbildung 3.3.1.2.10 besteht eine Assoziation zwischen<br />
"Student" und "Lehrveranstaltung". Eine Lehrveranstaltung findet statt, wenn<br />
mindestens 3 Studenten teilnehmen; ein Student kann keine, oder mehrere<br />
Lehrveranstaltungen besuchen. Der "Leistungsnachweis" ist keiner dieser beiden<br />
Klassen zuordenbar, da er sich immer auf die Verbindung (Link) eines konkreten<br />
Exemplars von "Student" mit einem konkreten Exemplar von "Lehrveranstaltung"<br />
bezieht. Da die Assoziationsklasse immer die Multiplizität 1 hat, wird die Multiplizität<br />
nicht angegeben.<br />
3.3.1.3 Anwendungsbereich<br />
Klassendiagramme sind der zentrale Diagrammtyp der UML. Sie beschreiben die<br />
Klassen eines Systems, ihre Eigenschaften, Operationen und die Beziehungen<br />
zwischen den Klassen. Klassendiagramme werden in allen Phasen der Softwareentwicklung<br />
eingesetzt. Die modellierten Inhalte und das verwendete Vokabular<br />
müssen sich an dem Know-how der beteiligten Personengruppen orientieren. Ein<br />
Klassendiagramm modelliert einen Teilausschnitt der realen Welt. Es werden nur<br />
die Klassen und Eigenschaften berücksichtigt, die zur Beschreibung des Problembereichs<br />
benötigt werden. Bei der Modellierung von Klassendiagrammen wird<br />
zwischen dem Analysemodell und dem Designmodell unterschieden.<br />
Diese verschiedenen Sichten auf ein Klassenmodell können durch den Einsatz von<br />
Entwicklungswerkzeugen, wie z. B. Case-Tools verwaltet und konsistent gehalten<br />
werden.<br />
Klassendiagramm Analyse<br />
Klassendiagramme in der Sichtweise der Analyse stellen dar, was das System aus<br />
Anwendersicht leisten soll. Sie bilden die Klassen, Attribute, Operationen und ihre<br />
Beziehungen ab, die das spätere Softwaresystems aus der Sicht des fachlichen Bereiches,<br />
den es abdecken soll, enthalten muss.<br />
49
50<br />
Das Analysemodell beschreibt was die zukünftige Software aus fachlicher Sicht<br />
leisten soll.<br />
Für die <strong>Informatik</strong>abteilung, die das geplante Produkt entwickeln soll, stellt das<br />
Analysemodell die Basis der zukünftigen Entwicklungsarbeit dar. Da Fehler in der<br />
Analyse sehr teuer sind, muss das Analysemodell sehr sorgfältig modelliert<br />
werden.<br />
In der Analyse sollten sprechende Namen verwendet werden, die auch die beteiligte<br />
Fachabteilung versteht. Die Deklaration von Attributen und Operationen wird<br />
in UML, nicht in der späteren Programmiersprache vorgenommen. Bei Einsatz<br />
eines CASE-Tools können daraus die Deklarationen in der gewählten Programmiersprache<br />
generiert werden.<br />
Klassendiagramm Design<br />
Im Designmodell wird das Analysemodell auf die Implementierungstechnologie<br />
abgebildet. Klassendiagramme in der Sichtweise Design stellen dar, wie das System<br />
technisch aufgebaut sein muss, damit es die in der Analyse geforderten Eigenschaften<br />
realisieren kann. Die in der Systemanalyse erkannten und dokumentierten<br />
Strukturen werden um die Informationen, die nötig sind um das fachliche Modell<br />
zu implementieren, erweitert.<br />
Im Design wird die Implementierungssprache festgelegt. Es wird definiert wie<br />
Assoziationen zu implementieren sind; die Art und Weise wie die Instanzen der<br />
Klassen verwaltet werden, wird festgelegt. Die Persistenzschicht wird modelliert,<br />
d. h. es wird definiert, wie die Klassen auf eine Datenbank abgebildet werden; die<br />
Datenbank wird ausgewählt. In der Regel werden bei der Implementierung eines<br />
Modells Klassenbibliotheken verwendet, deren Verwendung im Klassenmodell<br />
dokumentiert werden muss. Die Benutzeroberfläche muss eingeführt werden.<br />
3.3.1.4 Zusammenhang<br />
Klassen werden in fast allen UML-Diagrammen verwendet. Die Klassen des<br />
Klassendiagramms wirken sich deshalb auf alle anderen Diagramme aus und sind<br />
mit den anderen Diagrammen eines Modells konsistent zu halten.<br />
3.3.1.5 Hinweise für die Praxis<br />
Klassen identifizieren
Die UML definiert eine umfangreiche Notation zur Modellierung von Softwaresystemen.<br />
Vor der Modellierung der Struktur von Softwaresystemen müssen jedoch<br />
aus natürlichsprachigen Dokumentationen der Anforderungen an Systeme die<br />
enthaltenen fachlichen Objekte identifiziert werden. Alle Klassen, die den Problembereich<br />
für eine geplant Anwendung beschreiben, sind fachliche Klassen.<br />
Diese Klassen beschreiben die wichtigsten Merkmale der Anwendung.<br />
Wie findet man die in einem Text die enthaltenen Klassen? Es gibt zwei<br />
Techniken, die hier kurz skizziert werden.<br />
Substantivmethode<br />
Rumbaugh empfiehlt in [Rumbaugh, 1991] die Substantiv-Methode zur<br />
Identifikation von Klassen. Aus den Anforderungsdefinitionen an ein geplantes<br />
System werden alle Substantive markiert. Diese Begriffe sind potenzielle<br />
Klassenkandidaten. Danach werden redundante Begriffe eliminiert. Alle Begriffe,<br />
die auf die technische Realisierung der Begriffe hindeuten werden beseitigt. Durch<br />
diese kritische Analyse der Texte erhält man eine Menge Begriffe, die als Klassen<br />
im geplanten System verwendet werden können.<br />
CRC-Methode<br />
CRC bedeutet Class, Responsibility, Collaboration und bezeichnet eine Technik<br />
bei der für jede potenzielle Klasse eine Karteikarte angelegt wird, die drei Abschnitte<br />
enthält:<br />
• class – Klassennamen<br />
• resposibility – Zuständigkeit<br />
• collaboration - Zusammenarbeit<br />
Für jede Klasse wird der Klassenname notiert. Im Abschnitt Zuständigkeit wird<br />
beschrieben für welchen Zweck die Klasse eingeführt wurde, und unter Zusammenarbeit<br />
wird angegeben mit welchen anderen Klassen sie zusammenarbeitet.<br />
Die Substantivmethode und die CRC-Methode können auch kombiniert verwendet<br />
werden, indem man die Substantivmethode zum Auffinden der Klassen verwendet<br />
und die Klasseneigenschaften danach mit CRC-Karten (oder einem Texteditor)<br />
beschreibt.<br />
Attribute identifizieren<br />
Attribute sind die Eigenschaften der Klassen. Attribute sollten nur von der Klasse<br />
zu der sie gehören abhängig sein. Bei der Suche nach Attributen muss die Frage<br />
beantwortet werden: Was muss die Klasse über sich selbst wissen, damit sie arbeiten<br />
kann? Die Adjektive in der Anforderungsdefinition sind Kandidaten für Attribute.<br />
51
52<br />
Operationen identifizieren<br />
Operationen sind die öffentlich aufrufbaren Funktionen einer Klasse. Operationen<br />
sind die Schnittstellen einer Klasse, über die sie die Dienste, die sie implementiert,<br />
allen anderen Klassen des Systems anbietet.<br />
Assoziationen identifizieren<br />
Objekte kommunizieren über Assoziationen miteinander. Bei der Suche nach<br />
Assoziationen muss die Frage gestellt werden: Welche Objekte kommunizieren<br />
miteinander? In einem Projekt sind aber nur die Assoziationen zu modellieren, die<br />
zur Lösung des gestellten Problems benötigt werden. Die Verben in der Anforderungsdefinition<br />
geben Hinweise auf mögliche Assoziationen.<br />
Vererbungsstrukturen identifizieren<br />
Bei der Suche nach Vererbungsstrukturen sucht man gemeinsame Eigenschaften<br />
von Klassen, die in einer Oberklasse zusammengefasst werden können. Die Unterklasse<br />
muss alle geerbten Eigenschaften verwenden. Vererbung liegt dann vor,<br />
wenn eine Klasse eine Speziallfall einer anderen Klasse ist. Zwischen Oberklasse<br />
und Unterklasse besteht immer eine "ist-ein" Beziehung.<br />
Style Guide<br />
• Vererbungshierarchien sollten von oben nach unten angeordnet werden. Unterklassen<br />
sollten unterhalb ihrer Oberklasse stehen.<br />
• Kreuzungen zwischen Beziehung sollten minimiert werden.<br />
• Wird ein Klassendiagramm zu groß für eine Seite (einen Bildschirm), sollte es<br />
über mehrere Seiten in Teildiagramme verteilt werden. Für die Aufteilung der<br />
Klassen in Teildiagramme sollten fachliche Kriterien herangezogen werden.<br />
Neu in UML 2.0<br />
Die Klassendiagramme sind in allen wesentlichen Elementen unverändert gegenüber<br />
der UML 1.x.<br />
3.3.1.6 Beispiel<br />
Identifikation der Klassen
Aus den Spezifikationen des Use Case Diagramms "Mensa" wurden die<br />
Klassenkandidaten abgeleitet. Für den Use Case "KarteLaden" ergaben sich aus<br />
den markierten Begriffen in der Spezifikation folgende Klassenkandidaten:<br />
Automat, Karte, Kunden, Betrag, Display, Geld, Echtheit, Geldscheins, Restbetrag,<br />
Gesamtbetrag, Schein, Taste, Quittieren, Minute, Benutzung, Strom und Wiederkehr.<br />
Folgende Begriffe sind für den Problembereich überflüssig: Geld, Echtheit, Geldscheins,<br />
Minute, Benutzung, Strom und Wiederkehr. Sie werden eliminiert.<br />
Quittieren ist der Instanzname der Klasse Taste und wird eliminiert.<br />
Der Kunde ist ein Akteur, er ist damit kein Klassenkandidat.<br />
Damit bleiben nachfolgende Klassenkandidaten für den Use Case "KarteLaden":<br />
Automat, Karte, Display, Taste.<br />
Der Betrag ist ein Attribut von Karte.<br />
Abbildung 3.3.1.6.1 zeigt das Klassendiagramm zu dem Mensa Beispiel. Die<br />
"MensaKarte" wird von einer abstrakten "FH_Karte" abgeleitet. Das Attribut "ID"<br />
der "FH_Karte" hat die Sichtbarkeit protected und wird an die "MensaKarte"<br />
vererbt. "MensaAutomat" und "Kasse" stehen jeweils über Aggregationen in Beziehung<br />
zu den angegebenen Objekten. "Display" und "LeseSchreibEinheit" sind<br />
Teil von zwei Klassen; dies ist in der UML ausdrücklich erlaubt. Da das Beispiel<br />
ein Analysemodell darstellt, sind nur Analyseeigenschaften dargestellt. Es sind<br />
keine Elemente modelliert, die sich auf die Implementierung beziehen.<br />
Um die Lesbarkeit des Modells zu verbessern, wurde Farbe eingesetzt. Die Aggregationsbeziehungen<br />
sind blau, Assoziationen schwarz und Vererbungen rot dargestellt.<br />
53
54<br />
Abbildung 3.3.1.6.1Klassendiagramm Mensa<br />
3.3.2 Objektdiagramm - Object Diagram<br />
3.3.2.1 Zweck
Objektdiagramme werden eingesetzt um einen Schnappschuss eines Systems zur<br />
Laufzeit zu darzustellen. Es werden die zur Laufzeit existierenden Objekte,<br />
Attribute und Beziehungen angegeben.<br />
3.3.2.2 Notation<br />
Symbol Bedeutung<br />
Objekt<br />
Für jedes Objekt wird der Klassenname und der<br />
Objektname angegeben. Für die dargestellten Attribute<br />
wird der Attributname, Typ und die aktuelle Wertbelegung<br />
angegeben.<br />
Link<br />
Tabelle 2Notation Objektdiagramm<br />
3.3.2.3 Beispiel<br />
Abbildung 3.3.2.3.1Beispiel Objekt Mensakarte<br />
Ein Link ist eine aktuelle Beziehung zwischen Objekten.<br />
Er wird ähnlich der Assoziation im Klassendiagramm, als<br />
Linie zwischen den Objekten dargestellt. Es kann ein<br />
Name oder Rollenbezeichnungen angegeben werden<br />
Das Beispiel in Abbildung 3.3.2.3.1 zeigt das Objekt mit der Identität "123" der<br />
Klasse "MensaKarte". Das Attribut "Betrag" ist vom Typ "float" und hat den<br />
aktuellen Wert "2.60".<br />
3.3.3 Komponentendiagramm - Component Diagram<br />
55
56<br />
3.3.3.1 Zweck<br />
Ein Komponentendiagramm beschreibt die physikalischen Komponenten aus<br />
denen ein System zusammengesetzt ist. Es stellt die Komponenten eines Modells,<br />
ihre Beziehungen und die öffentlichen Schnittstellen dar. Eine Komponente ist eine<br />
modulare, autonome Einheit innerhalb eines Systems, die über definierte Schnittstellen<br />
verfügt. Eine Komponente kann Schnittstellen anbieten, bzw. erfordern. Der<br />
interne Aufbau einer Komponente ist verborgen. Komponentendiagramme geben<br />
Auskunft darüber welche Teile eines Systems zusammenarbeiten. Eine<br />
Komponente ist innerhalb eines Modells austauschbar.<br />
3.3.3.2 Notation<br />
Symbol Beschreibung<br />
Komponente (externe Sicht)<br />
Eine Komponente wird als Rechteck dargestellt.<br />
Sie trägt die Stereotypbezeichnung<br />
und hat einen Namen. In der<br />
rechten, oberen Ecke kann sie das<br />
Komponentensymbol tragen. Das Symbol mit<br />
dem vollen Kreis stellt eine Schnittstelle dar, die<br />
die Komponente bereitstellt; das Symbol mit dem<br />
Halbkreis bezeichnet eine Schnittstelle, die von<br />
der Komponente genutzt wird.<br />
Komponente (interne Sicht)<br />
Komponenten können, ähnlich wie Klassen,<br />
vollständig dargestellt werden. In dem Bereich<br />
unter dem Namen werden die geforderten und<br />
bereitgestellten Schnittstellen aufgeführt; im<br />
nächsten Abschnitt werden die Klassen, die die<br />
Komponente realisieren angegeben. Im unteren<br />
Bereich wird die Datei angegeben, die die<br />
Implementierung der Komponente enthält.
Symbol Beschreibung<br />
Beziehungen<br />
Tabelle 3Notation Komponentendiagramm<br />
3.3.3.3 Anwendungsbereich<br />
können im Komponentendiagramm als<br />
gestrichelte Linien angegeben werden. Der Pfeil<br />
gibt zu Zugriffsrichtung an. Sind die<br />
Schnittstellen der Komponenten angegeben,<br />
ergibt sich aus den Symbolen die<br />
Zugriffsrichtung.<br />
Komponentendiagramme werden eingesetzt um komponentenorientierte Software<br />
zu modellieren. Es ist damit möglich Komponenten und ihre Abhängigkeiten für<br />
Systeme, die in Komponententechnologie wie z. B. Enterprise Java Beans, .Net<br />
oder CORBA realisiert werden zu modellieren.<br />
Komponentendiagramme können auch verwendet werden, um die physischen<br />
Komponenten eines Systems zu modellieren, das nicht in<br />
Komponententechnologie realisiert wird. Die Komponenten geben dann die<br />
Zuordnung der Klassen zu den Quellcodedateien an.<br />
3.3.3.4 Zusammenhang<br />
Da Komponenten häufig mehrere Klassen enthalten, müssen die Klassen den<br />
Komponenten zugeordnet werden. Komponentendiagramme und<br />
Klassendiagramme müssen konsistent gehalten werden.<br />
3.3.3.5 Hinweise für die Praxis<br />
Für ein Komponentendesign gelten die selben Designprinzipien wie für ein Design<br />
auf Klassenebene; die Komponenten sollten eine hohe Kohäsion und eine lose<br />
Kopplung aufweisen.<br />
Neu in UML 2.0<br />
In den UML-Versionen 1.x war eine Komponente eine Implementierungseinheit.<br />
Sie legte fest in welchen Quellcodedateien die Klassen eines Modells<br />
implementiert wurden. Es war zwar möglich Komponentendiagramme zum<br />
57
58<br />
Entwurf komponentenorientierter Software zu verwenden, aber die Notation sah es<br />
nicht explizit vor. Die in UML 2.0 mögliche explizite Angabe von bereitgestellten<br />
und geforderten Schnittstellen war in UML 1.x nur implizit möglich.<br />
3.3.3.6 Beispiel<br />
Abbildung3.3.3.6.1Beispiel, Komponentendiagramm Mensaautomat<br />
Abbildung3.3.3.6.1 zeigt eine einfache Komponentenstruktur des Beispiels<br />
Mensaautomat. Im oberen Bereich wird der Name der Komponente angegeben, der<br />
untere Bereich gibt die Klassen an, die den Komponenten zugeordnet sind. Das<br />
Pluszeichen vor dem Klassennamen gibt die Sichtbarkeit public der Klassen<br />
innerhalb der Komponente an.<br />
Es werden die Komponentensymbole der UML 1.x verwendet; dies ist in der UML<br />
2.0 ausdrücklich erlaubt.<br />
3.3.4 Paketdiagramm - Package Diagram<br />
3.3.4.1 Zweck
Pakete werden verwendet um Mengen von Modellelementen zu Gruppen zusammenzufassen.<br />
Sie dienen der Strukturierung von UML-Modellelementen in<br />
überschaubare Einheiten. Paketdiagramme stellen die Pakete und die Beziehungen<br />
(Abhängigkeiten) zwischen den Paketen eines Modells dar. Die Kriterien, nach<br />
denen Modelle strukturiert werden, sind frei festlegbar.<br />
3.3.4.2 Notation<br />
Tabelle 4Notation Paketdiagramm<br />
3.3.4.3 Anwendungsbereich<br />
Paket<br />
Ein Paket fasst eine Gruppe von beliebigen<br />
Modellelementen zusammen. Pakete können<br />
verschachtelt sein. Sie definieren einen<br />
Namensraum. In diesem Beispiel umfasst<br />
das Paket a die Pakete b und c.<br />
Abhängigkeiten<br />
zwischen Paketen werden als gestrichelte<br />
Pfeile dargestellt. Sie drücken aus, dass Pakete<br />
in einem Client-Server-Verhältnis zueinander<br />
stehen. Häufige Stereotypen für<br />
Abhängigkeiten in Paketdiagrammen sind<br />
und , womit ausgedrückt<br />
wird, dass ein Paket ein anderes<br />
importiert, bzw. darauf zugreift.<br />
Da Pakete Modellelemente zu Gruppen zusammenfassen, können sie für verschiedene<br />
Zwecke eingesetzt werden. Pakete können verwendet werden um Subsysteme<br />
zu modellieren, in die ein großes System zerlegt wird. Pakete können auch<br />
verwendet werden um die Ergebnisse von Entwicklungsphasen festzulegen und die<br />
entsprechenden Diagramme, die einer Phase zugeordnet werden, zusammenzufassen.<br />
Darüber hinaus können Pakete für jede sinnvolle Gruppierung von<br />
Modellelementen in einem Projekt eingesetzt werden. Die Systemarchitektur kann<br />
z. B. mit Paketen abgebildet werden.<br />
Jedes Paket definiert einen Namensraum. Namensräume geben Sichtbarkeitsbereiche<br />
von Modellelementen an; in einem Paket müssen Namen eindeutig sein. Jedes<br />
Modellelement gehört zu einem Paket. Zwei Elemente, die zu unterschiedlichen<br />
Namensräumen gehören dürfen denselben Namen tragen; um sie zu unterscheiden<br />
muss der Namensraum angegeben werden.<br />
59
60<br />
Der Zugriff auf die Elemente eines Paketes kann durch die Sichtbarkeit der<br />
Elemente gesteuert werden. Die Sichtbarkeit kann public, private oder protected<br />
sein.<br />
3.3.4.4 Zusammenhang<br />
Pakete sind eine logische Zusammenfassung von Modellelementen. Folgende<br />
Elemente werden häufig zu Paketen zusammengefasst:<br />
• Klassen werden zu Realisierungseinheiten zusammengefasst. In C++ werden<br />
Pakete als namespace realisiert. In Java werden Pakete als Java-Package umgesetzt.<br />
• Use Cases werden zu Paketen zusammengefasst, um in frühen Entwicklungsphasen<br />
ein Projekt in Teilprojekte zu zerlegen, die von verschiedenen<br />
Entwicklergruppen bearbeitet werden können.<br />
• UML-Diagramme werden zu Paketen zusammengefasst, um die Entwicklungsergebnisse<br />
eines Projekts den Entwicklungsphasen zuzuordnen.<br />
Von Paketen können keine Instanzen gebildet werden. Sie können deshalb in<br />
keinen Interaktionsdiagrammen verwendet werden.<br />
3.3.4.5 Beispiel<br />
Abbildung 3.3.4.5.1Beispiel Paketdiagramm Mensaautomat
Abbildung 3.3.4.5.1 definiert eine Paketstruktur für das Beispiel Mensaautomat auf<br />
der Ebene des Use Case Modells. Jedem Paket ist ein Use Case und alle den Use<br />
Case verfeinernden Diagramme zugeordnet. Dem Paket Geldautomat wären in<br />
diesem Beispiel folgende Diagramme zugeordnet:<br />
• das Sequenzdiagramm "KarteLaden“<br />
• das Aktivitätsdiagramm "KarteLaden“<br />
Durch dieses Paketdiagramm werden drei Subsysteme definiert, die von verschiedenen<br />
Projektteams selbständig bearbeitet werden können.<br />
3.3.5 Anwendungsfalldiagramm - Use Case Diagram<br />
3.3.5.1 Zweck<br />
In Use Case Diagrammen wird das externe Systemverhalten aus Anwendersicht<br />
beschrieben. Use Case Diagramme stellen das geplante System, die Akteure, die<br />
Verwendung des geplanten Systems (Anwendungsfälle) und die Beziehungen zwischen<br />
Akteuren und Anwendungsfällen dar. Use Case Diagramme geben Auskunft<br />
darüber, was ein geplantes System aus Sichtweise der Benutzer leisten soll.<br />
3.3.5.2 Notation<br />
Symbol Bedeutung<br />
System<br />
Das Rechteck stellt das geplante System dar. Das System erhält<br />
einen Namen. Ein Use Case Diagramm kann auch mehrere Systeme<br />
enthalten, die ineinander geschachtelt sein dürfen. Dadurch<br />
kann ein System in Teilsysteme gegliedert werden.<br />
Akteur<br />
Ein Akteur ist ein Element, das nicht zum geplanten System gehört.<br />
Er kann eine Person sein, die auf das System zugreift, oder<br />
ein anderes System, das mit dem geplanten System kommuniziert.<br />
Die UML erlaubt mehrere Symbole zur Darstellung eines Akteurs.<br />
Er kann als Strichmännchen dargestellt werden. Es ist optional<br />
erlaubt ein Klassensymbol zu verwenden, das mit dem Stereotyp<br />
markiert wird. Zusätzlich können eigene Symbole<br />
verwendet werden um nicht menschliche Akteure darzustellen.<br />
61
62<br />
Symbol Bedeutung<br />
Use Case<br />
Eine Ellipse stellt einen Anwendungsfall des Systems dar. Ein<br />
Anwendungsfall ist ein in sich abgeschlossener Vorgang, der für<br />
einen oder mehrere Akteure ein beobachtbares Ergebnis liefert. Er<br />
beschreibt aus Sicht der Akteure welche Leistungen das System<br />
für den Anwender zur Verfügung stellt. Ein Use Case stellt somit<br />
einen Teil der Gesamtfunktionalität des Systems dar. In UML 2.0<br />
kann auch ein Rechteck, das mit einer Ellipse markiert wird, als<br />
Use-Case-Symbol verwendet werden. Der Name kann innerhalb<br />
oder außerhalb des Symbols stehen.<br />
Extension points<br />
Das Verhalten eines Use Case kann durch einen weiteren Use Case<br />
erweitert werden. Dies wird durch die extend-Beziehung und den<br />
extension point angegeben. Die Beziehung wird gestrichelt<br />
dargestellt; der Pfeil zeigt auf den erweiterten Use Case und trägt<br />
den Stereotyp . Der extension point gibt den Ort im<br />
erweiterten Use Case an, an dem der erweiternde Use Case eingefügt<br />
wird. b erweitert das Verhalten von a. b wird an dem extension<br />
point "Name" in a eingefügt.<br />
include-Assoziation<br />
Die include Beziehung definiert einen Use Case, der die Funktionalität,<br />
die ein anderer Use Case zur Verfügung stellt, importiert.<br />
Der Use Case a importiert die Funktionalität des Use Case b.<br />
Vererbungsbeziehung<br />
In Use Case Diagrammen ist die Verebungsbeziehung erlaubt. Sie<br />
kann verwendet werden um Verhalten zwischen Use Cases zu<br />
vererben. Sie kann aber auch verwendet werden, um Vererbungsbeziehungen<br />
zwischen Akteuren aufzubauen.<br />
Assoziation<br />
Eine Linie stellt eine Assoziation zwischen einem Akteur und<br />
einem Use Case dar. Sie beschreibt den Zugriff des Akteurs auf die<br />
Funktionalität, die das System in diesem Use Case zur Verfügung<br />
stellt, bzw. eine Antwort des Systems an einen Akteur.<br />
Tabelle 5Notation Use Case Diagramm<br />
Use Case Diagramme stellen das für den Anwender sichtbare Verhalten eines Systems<br />
dar. Sie bestehen aus den in Tabelle 4 aufgeführten Notationselementen. Ein
System stellt ein vollständiges Hard- bzw. Softwaresystem dar. Das System enthält<br />
die Use Cases. Akteure sind extern und stehen außerhalb des Systems. Ein Use<br />
Case beschreibt eine Menge von Funktionen, die das System für die Benutzer<br />
implementiert. Der Benutzer ist der Auslöser eines Use Cases; er greift über die<br />
Assoziationen auf die Use Cases zu. Use Cases können eine Spezifikation enthalten,<br />
die in Form eines weiteren Diagramms oder als Freitext realisiert werden kann.<br />
Beispiel include und extend Beziehung<br />
Abbildung 3.3.5.2.1Beispiel include, extend Beziehung<br />
Abbildung 3.3.5.2.1 zeigt ein Beispiel zu einer include und extend Beziehung. Ein<br />
"Bearbeiter" erfasst einen Auftrag; er greift auf den Use Case "Auftrag erfassen"<br />
zu. Der Use Case "Auftrag erfassen" includiert (importiert) den Use Case "Kunden<br />
prüfen", d. h. bei jedem Erfassen eines Auftrags wird der Kunde geprüft. Includierte<br />
Use Cases werden <strong>beim</strong> Ausführen des includierenden Use Case immer ausgeführt.<br />
Der Use Case "Auftrag erfassen" hat den extension point "Kunde einfügen". Dieser<br />
verweist über die extend-Beziehung und die in der angehängten Notiz enthaltene<br />
Information auf den Use Case "Kunden erfassen". Das bedeutet, dass der Use Case<br />
"Kunden erfassen" nur dann ausgeführt wird, wenn die Bedingung "Kunde=neu"<br />
erfüllt ist. Durch die Angabe des extension points bei der Bedingung wird deutlich<br />
gemacht an welcher Stelle des erweiterten Use Case ("Auftrag erfassen") der<br />
erweiternde Use Case ("Kunden erfassen") im Ablauf des erweiterten Use Case<br />
eingefügt wird. Die extend Beziehung drückt also eine optionale Erweiterung eines<br />
Use Case aus, die nur unter bestimmten Bedingungen ausgeführt wird.<br />
3.3.5.3 Anwendungsbereich<br />
Use Case Modelle werden zur Festlegung der Anforderungen an ein Softwaresystem<br />
(Anforderungsanalyse, Requirements engineering) eingesetzt. Use Case<br />
63
64<br />
Modelle sind leicht verständlich und ein gutes Kommunikationsmittel zwischen<br />
Systemanalytiker, Anwender und Entwickler. Sie legen die Grenzen des Systems<br />
fest, die Akteure, die darauf zugreifen und die Funktionalität des Systems. Die<br />
Funktionalität wird aus Sicht der zukünftigen Benutzer des geplanten Systems<br />
analysiert und definiert. Implementierungsdetails, wie z. B. die zu verwendende<br />
Programmiersprache, Systemarchitektur (Client-Server, ....), usw. sind in diesen<br />
Phasen noch nicht wichtig und deshalb zu vernachlässigen.<br />
In der Systemanalyse wird, z. B. in Meetings zwischen Systemanalytikern und<br />
Anwendern des künftigen Systems definiert was das System aus der Sicht der<br />
Anwender leisten soll. Die einzelnen Fälle, die das System abdecken soll, werden<br />
als Use Case in die Diagramme eingezeichnet und beschrieben.<br />
Ein Use Case Diagramm stellt also eine grobe Skizze des Systems dar, das den<br />
Zweck des geplanten Systems angibt, seine Grenzen und Schnittstellen, die auf es<br />
einwirken. Alle modellierten Elemente sind in einer Spezifikation zu beschreiben.<br />
Die Spezifikation sollte das Verhalten im Normalfall, mögliche alternativen Abläufe<br />
und das Verhalten im Fehlerfall enthalten.<br />
3.3.5.4 Zusammenhang<br />
Die Use Cases stellen jeweils eine Menge von Systemfunktionen dar. Diese<br />
Funktionen sind in einem Projekt genauer zu beschreiben. Diese Spezifikation der<br />
Use Cases kann in Form eines anderen UML-Diagramms erfolgen, oder als strukturierter<br />
Text hinterlegt werden.<br />
Folgende Diagrammtypen sind zur Spezifikation von Use Cases geeignet:<br />
• Aktivitätsdiagramme<br />
• Sequenzdiagramme<br />
• Interaktionsübersichtsdiagramme<br />
• Kommunikationsdiagramme<br />
Stehen die Geschäftsprozesse im Vordergrund, so können Aktivitätsdiagramme<br />
verwendet werden. Damit können die Abläufe der Use Cases präzise beschrieben<br />
werden. Einzelne Szenen können in Sequenzdiagrammen oder in Kommunikationsdiagrammen<br />
modelliert werden, wenn die Interaktion von Objekten eine<br />
wichtige Rolle spielt. Interaktionsübersichtsdiagramme können verschiedene Interaktionsdiagramme<br />
einem Use Case zuordnen.<br />
Die Use Case Spezifikationen enthalten wichtige Informationen für das zu entwickelnde<br />
System. Aus den Spezifikationen können erste Klassenkandidaten für das<br />
statische Modell abgeleitet werden.
3.3.5.5 Hinweise für die Praxis<br />
Identifikation der Akteure<br />
In der Anforderungsanalyse ist es nötig die Akteure zu identifizieren und zu<br />
benennen. Dabei müssen die Fragen beantwortet werden:<br />
• Für wen wird das System entwickelt?<br />
• Wer soll das System benutzen?<br />
• Mit welchen anderen Systemen soll das geplante System interagieren?<br />
Identifikation der Systemgrenzen<br />
Die Use Cases sind Teil des Systems und enthalten die Funktionalität des zukünftigen<br />
Systems. Akteure sind Elemente, die nicht zu dem System gehören und auf<br />
das System zugreifen. Das System grenzt die Elemente, die zum System gehören<br />
von Elementen, die nicht zu dem System gehören ab. Alle Elemente innerhalb des<br />
Systems gehören zu dem System und sind zu entwickeln. Elemente außerhalb des<br />
Systems greifen auf das System zu.<br />
Identifikation der Use Cases<br />
Use Cases beschreiben den Zweck, für den ein System entwickelt wird auf einer<br />
hohen Abstraktionsebene. Sie beschreiben die Leistung, die ein System für den<br />
Benutzer erbringt.<br />
Folgende Fragen sind zur Identifikation von Use Cases hilfreich:<br />
• Für welchen Zweck soll das System eingesetzt werden?<br />
• Wofür will der spätere Benutzer es einsetzen?<br />
• Durch welches externe Ereignis wird ein Use Case angestoßen?<br />
• Welches Ergebnis liefert ein Use Case dem späteren Nutzer?<br />
Spezifikation der Use Cases<br />
Zur Spezifikation von Use Cases ist es vorteilhaft strukturierten Text zu<br />
verwenden. Die Textstruktur könnte folgende Abschnitte enthalten:<br />
• Name des Use Case<br />
• Auslösendes Ereignis<br />
• Verhalten im Normalfall<br />
• Verhalten im Fehlerfall<br />
• Ergebnis<br />
Identifikation der Beziehungen zwischen Akteuren und Use Cases<br />
Zur Identifikation der Beziehungen hilft die Beantwortung folgender Fragen:<br />
• Auf welche Use Cases greift ein Akteur zu?<br />
65
66<br />
• Welche Antworten erhält er vom System?<br />
• Über welche externen Ereignisse muss ein Use Case informiert werden?<br />
Style Guide<br />
• Akteure und Use Cases sollten niemals in einem Diagramm isoliert sein (ohne<br />
Bezug zu anderen Modellelementen).<br />
• Ein Use Case Diagramm sollte nicht mehr als ca. 10 Use Cases enthalten. Bei zu<br />
vielen Use Cases wird das Diagramm unübersichtlich. Zu viele Use Cases in<br />
einem Diagramm sind ein Hinweis darauf, dass die Granularität der Use Cases<br />
nicht korrekt gewählt wurde. Sollte das System zu groß sein, ist es sinnvoll es in<br />
Teilsysteme zu zerlegen und in mehrere Use Case Diagramme zu verteilen.<br />
• Kreuzungen zwischen Assoziationen sind zu vermeiden.<br />
• Akteure sind außerhalb des Systems einzuzeichnen.<br />
Neu in UML 2.0<br />
Die Notationselemente für Use Case Diagramme sind in der UML 2.0 unverändert.<br />
Vorbedingung und der extension point müssen jetzt als Notiz an der extend-<br />
Beziehung angegeben werden.<br />
3.3.5.6 Beispiel<br />
Das Use Case Modell "Mensa" besteht aus den Use Cases "EssenZahlen",<br />
"KarteLaden" und "Umsatzstatistik"; das System wird für diese Zwecke verwendet.<br />
Die Akteure "Kunde", "MensaLeitung" und "KassenFrau" greifen auf das System<br />
zu. Der Zugriff von Servicetechnikern auf das System wird in dem Beispiel nicht<br />
modelliert. Nachfolgend sind die beiden Use Cases "EssenZahlen" und<br />
"KarteLaden" spezifiziert. Der Use Case "Umsatzstatistik" wird nicht detailliert<br />
spezifiziert und modelliert. Die unterstrichenen Begriffe in den Spezifikationen<br />
stellen die ersten Klassenkandidaten dar, die <strong>beim</strong> Lesen der Spezifikation<br />
gefunden wurden. Verfahren, die zur Identifikation von Klassenkandidaten<br />
geeignet sind, werden im Kapitel Klassendiagramm beschrieben.
Abbildung 3.3.5.6.1Beispiel, Use Case Diagramm Mensa<br />
Spezifikation<br />
Name des Use Case: KarteLaden<br />
Auslösendes Ereignis: Kunde schiebt eine Karte in den Automat<br />
Verhalten im Normalfall: Der Automat liest und prüft die Karte. Ist die Karte<br />
gültig, so zeigt er dem Kunden den Betrag, der noch auf der Karte gespeichert ist<br />
auf dem Display an. Ist die Karte ungültig, wird sie wieder ausgeschoben. Ist die<br />
Karte gültig, kann der Kunde Geld in den Automaten einschieben. Das Geld wird<br />
auf Echtheit überprüft. Ist das Geld echt, wird der Betrag des eingelegten Geld-<br />
scheins zu dem Restbetrag, der noch auf der Karte gespeichert war, addiert und der<br />
Gesamtbetrag angezeigt. Wird das Geld vom Automaten nicht als echt akzeptiert,<br />
so schiebt er den Schein wieder aus. Der Kunde kann keine oder mehrere<br />
Geldscheine einschieben. Drückt der Kunde die Taste Quittieren, wird der aktuelle<br />
Betrag auf der Karte gespeichert und die Karte wird vom Automat ausgeschoben.<br />
Hat der Kunde kein Geld eingeschoben, erhält er die Karte unverändert zurück.<br />
Verhalten im Fehlerfall: Lässt ein Kunde seine Karte länger als eine Minute in<br />
dem Automat, ohne ihn zu bedienen, dann schiebt der Automat die Karte wieder<br />
aus.<br />
67
68<br />
Fällt während der Benutzung der Strom aus, dann schiebt der Automat nach<br />
Wiederkehr des Stroms Karte und Geld wieder aus. Der Geldbetrag auf der Karte<br />
bleibt unverändert.<br />
Ergebnis: Der Kunde erhält seine Karte zurück.<br />
Name des Use Case: EssenZahlen<br />
Auslösendes Ereignis: Kunde steht mit beladenem Tablett an der Kasse<br />
Verhalten im Normalfall: Die KassenFrau tippt das Essen in die Kasse. Der zu<br />
zahlende Gesamtbetrag wird auf dem Display angezeigt. Der Kunde schiebt seine<br />
Karte ein. Der Betrag, den das Essen kostet, wird abgebucht. Ist auf der Karte nicht<br />
mehr genug Geld gespeichert, wird eine entsprechende Fehlermeldung auf dem<br />
Display ausgegeben. Die Karte wird ausgeschoben.<br />
Verhalten im Fehlerfall: Ist die Karte für die Leseeinheit des Automaten nicht<br />
lesbar, so gibt er eine Fehlermeldung auf dem Display aus. Die Karte wird heraus<br />
geschoben. Fällt der Strom aus, während eine Karte im Automat ist, wird die Karte<br />
noch Wiederkehr des Stroms heraus geschoben. Der Bezahlvorgang muss wiederholt<br />
werden.<br />
Ergebnis: Der Kunde hat das Essen bezahlt und erhält die Karte zurück.<br />
3.3.6 Sequenzdiagramm - Sequence Diagram<br />
3.3.6.1 Zweck<br />
Sequenzdiagramme beschreiben die Kommunikation zwischen Objekten in einer<br />
bestimmten Szene. Es wird beschrieben welche Objekte an der Szene beteiligt sind,<br />
welche Informationen (Nachrichten) ausgetauscht werden und in welcher<br />
zeitlichen Reihenfolge der Informationsaustausch stattfindet. Sequenzdiagramme<br />
enthalten eine implizite Zeitachse. Die Zeit schreitet in einem Diagramm von oben<br />
nach unten fort. Die Reihenfolge der Pfeile in einem Sequenzdiagramm gibt die<br />
zeitliche Reihenfolge der Nachrichten an.<br />
3.3.6.2 Notation
Symbol Bedeutung<br />
Klasse, Objekt<br />
In dem Rechteck oberhalb der gestrichelten Linie wird der<br />
Objektname und der Klassenname angegeben. Der Name wird<br />
unterstrichen. Die senkrechte, gestrichelte Linie stellt die<br />
Lebenslinie (lifeline) eines Objekts dar. Im diesem zeitlichen<br />
Bereich existiert das Objekt. Das schmale Rechteck auf der<br />
gestrichelten Linie stellt eine Aktivierung dar. Eine Aktivierung<br />
ist der Bereich, in dem eine Methode des Objektes aktiv ist<br />
(ausgeführt wird). Auf einer Lebenslinie können mehrere<br />
Aktivierungen enthalten sein.<br />
Nachricht, Botschaft<br />
Objekte kommunizieren über Nachrichten. Nachrichten werden<br />
als Pfeile zwischen den Aktivierungen eingezeichnet. Der Name<br />
der Nachricht steht an dem Pfeil. Eine Nachricht liegt immer<br />
zwischen einem sendenden und einem empfangenden Objekt.<br />
Synchrone Nachricht (Aufruf)<br />
Der Pfeil mit der ausgefüllten Spitze bezeichnet einen synchronen<br />
Aufruf. Der Aufruf erfolgt von der Quelle zum Ziel, d. h. die<br />
Zielklasse muss eine entsprechende Methode implementieren.<br />
Die Quelle wartet mit der weiteren Verarbeitung bis die<br />
Zielklasse ihre Verarbeitung beendet hat und setzt die<br />
Verarbeitung dann fort. Ein Aufruf muss einen Namen haben; in<br />
runden Klammern können Aufrufparameter angegeben werden.<br />
Der gestrichelte Pfeil ist der Return. Die Bezeichnung des Return<br />
mit einem Namen ist optional.<br />
Asynchrone Nachricht<br />
Mit einer offenen Pfeilspitze werden asynchrone Nachrichten<br />
gekennzeichnet. Der Aufruf erfolgt von der Quelle zum Ziel. Die<br />
Quelle wartet mit der Verarbeitung nicht auf die Zielklasse,<br />
sondern setzt ihre Arbeit nach dem Senden der Nachricht fort.<br />
Asynchrone Aufrufe werden verwendet, um parallele Threads zu<br />
modellieren.<br />
Objekt erzeugen, zerstören<br />
Das Erzeugen eines Objektes wird durch eine Nachricht, die im<br />
Kopf des Objekts endet dargestellt.<br />
Das Zerstören (Löschen) eines Objektes wird durch ein x auf der<br />
Lebenslinie markiert.<br />
69
70<br />
Symbol Bedeutung<br />
Tabelle 6 Notation Sequenzdiagramm<br />
Rekursion<br />
Sendet ein Objekt eine Nachricht an sich selbst, so ruft es eine<br />
Methode auf, die es selbst implementiert.<br />
Ein Sequenzdiagramm enthält Objekte, Lebenslinien, Aktivierungen, Nachrichten<br />
und kombinierte Fragmente (combined fragment). Mit kombinierten Fragmenten<br />
können in Sequenzdiagrammen die Kontrollstrukturen höherer<br />
Programmiersprachen ausgedrückt werden. Jedes kombinierte Fragment wird als<br />
rechteckiger Block dargestellt. In der linken, oberen Ecke trägt er eine<br />
Bezeichnung, die den Typ der Kontrollstruktur angibt (interaction operator). Die<br />
wichtigsten kombinierte Fragmente der UML 2.0 sind weiter unten erläutert.<br />
Abbildung 3.3.6.2.1Prinzip Sequenzdiagramm<br />
Abbildung 3.3.6.2.1 stellt das Prinzip des Sequenzdiagramms in UML 2.0 dar. In<br />
der linken, oberen Ecke steht der Diagrammtyp (sd) und der Name des<br />
Diagramms (NameSQ). Im Diagramm sind die beiden Objekte objA und objB<br />
enthalten. Sie existieren während der gesamten Szene; das ist daran ersichtlich,<br />
dass die Lebenslinien bis zum unteren Bildrand durchgezogen sind und kein x<br />
enthalten, das das Zerstören eines Objektes ausdrückt.<br />
Sequenzdiagramme können in der UML 2.0 verschachtelt sein. Aus einem<br />
Sequenzdiagramm kann auf Sequenzen in einem anderen Diagramm verwiesen
werden. Der mit ref bezeichnete Block stellt einen Verweis auf ein Diagramm mit<br />
dem Namen "SQ-Diagramm 2" dar, das eine Verfeinerung des Blockes enthält.<br />
Der mit alt markierte Block beschreibt eine Alternative (Verzweigung). Ist die<br />
Bedingung [b=wahr] erfüllt, wird der Bereich oberhalb der gestrichelten Linie in<br />
dem alt-Block ausgeführt. Im else-Fall wird der Bereich unterhalb der gestrichelten<br />
Linie ausgeführt.<br />
Abbildung 3.3.6.2.2Schleife in Sequenzdiagramm<br />
Abbildung 3.3.6.2.2 zeigt eine Schleife in einem Sequenzdiagramm. Die<br />
modellierte Szene ist eine Variation des Beispiels Mensaautomat. Es sind drei<br />
Objekte an der Szene beteiligt. Das Objekt Kunde ist vom Stereotyp . Er<br />
ist ein Akteur (aus dem Use Case Diagramm) und greift auf den MensaAutomat zu,<br />
indem er ihm die Botschaft "geldEin" sendet; diese Botschaft übergibt den<br />
Parameter "Betrag". Danach sendet der "MensaAutomat" die Botschaft "anzeige<br />
(Betrag)" an das "Display". Das "Display" führt die Methode aus und gibt die<br />
Kontrolle über den Return wieder an den "MensaAutomat" zurück. Der<br />
"MensaAutomat" gibt die Kontrolle wieder an den "Kunden" zurück. Diese<br />
Sequenz von Botschaften wird solange ausgeführt bis die Abbruchbedingung<br />
[Summe reicht] erfüllt ist. Das Prüfen des Geldes auf Echtheit ist in diesem<br />
Beispiel nicht modelliert worden.<br />
3.3.6.3 Anwendungsbereich<br />
Sequenzdiagramme werden zur Darstellung der Kommunikation von Objekten<br />
eingesetzt. Sie können in der Analyse und im Design eingesetzt werden.<br />
Sequenzdiagramme werden häufig verwendet, um Szenarios eines Systems zu<br />
modellieren. Ein Szenario (Szene) ist die Beschreibung einer Sicht auf einen Teil<br />
71
72<br />
eines Systems. Sequenzdiagramme können auch zur Modellierung von komplexen<br />
Operationen eines Systems verwendet werden und detaillierte Designinformationen<br />
enthalten.<br />
Ein System wird in der Regel nicht vollständig durch Sequenzdiagramme<br />
spezifiziert. Es werden nur die Szenen modelliert, die häufig vorkommen oder<br />
besonders wichtig sind.<br />
3.3.6.4 Zusammenhang<br />
Jedes Sequenzdiagramm kann sich auf einen Use Case beziehen. Da Use Case<br />
Diagramme aber nicht in jedem Projekt verwendet werden, können<br />
Sequenzdiagramme auch unabhängig von Use Case Diagrammen eingesetzt<br />
werden.<br />
Die Klassen der Sequenzdiagramme müssen in den Klassendiagrammen enthalten<br />
sein. Ereignisse und Nachrichten erfordern entsprechende Methoden bei den<br />
Zielklassen.<br />
Alternativ zu den Sequenzdiagrammen können auch Interaktionsübersichtdiagramme,<br />
Kommunikationsdiagramme, Zeitverlaufsdiagramme oder<br />
Aktivitätsdiagramme verwendet werden.<br />
3.3.6.5 Hinweis für die Praxis<br />
Sequenzdiagramme werden zur Modellierung von Interaktionen gewählt, wenn die<br />
Darstellung der Reihenfolge des Nachrichtenaustauschs wichtig ist.<br />
Bevor Sequenzdiagramme modelliert werden können, müssen die an der Szene<br />
beteiligten Klassen identifiziert werden. Hinweise zur Identifikation von Klassen<br />
befinden sich im Kapitel 3.3.1 Klassendiagramm.<br />
Die in Sequenzdiagrammen modellierten Objekte und Nachrichten müssen<br />
konsistent zu den Klassendiagrammen gehalten werden.<br />
Da Sequenzdiagramme dynamische Aspekte eines Systems darstellen, müssen<br />
normalerweise Instanznamen und Klassennamen angegeben werden. Häufig<br />
vernachlässigt man jedoch den Instanznamen und gibt nur den Klassennamen an.<br />
Ein solches anonymes Objekt steht stellvertretend für alle Objekte der Klasse und<br />
impliziert, dass alle Objekte der Klasse sich in der Szene gleich verhalten.<br />
Style Guide<br />
• Objekte sollten so angeordnet werden, dass in einem Diagramm möglichst<br />
wenig Kreuzungen entstehen.
• Nachrichten sollten von links nach rechts zeigen, Returns von rechts nach links.<br />
• Nachrichtennamen sollten an der Spitze der Pfeile stehen.<br />
• Beteiligte Akteure sollten am linken Rand der Diagramme stehen.<br />
• Namen der Akteure sollten konsistent zu den Use Case Diagrammen sein.<br />
• Klassennamen sollten konsistent zu dem Klassendiagramm sein.<br />
Neu in UML 2.0<br />
Folgende Elemente sind in der UML 2.0 neu oder geändert gegenüber UML 1.x:<br />
• Verschachtelung von Diagrammen mittels Referenzen.<br />
• Darstellung der Kontrollstrukturen höherer Programmiersprachen (Verzweigung,<br />
Schleifen ..) mittels kombinierter Fragmente.<br />
• Es wurden zwei neue Nachrichtentypen eingeführt; "lost" und "found", die in<br />
diesem Skript nicht behandelt werden.<br />
3.3.6.6 Beispiel<br />
Sequenzdiagramm der Szene Karte laden<br />
Abbildung 3.3.6.6.1Beispiel Sequenzdiagramm Karte laden<br />
Dieses Sequenzdiagramm modelliert die Szene "Karte laden". Es bezieht sich auf<br />
den Use Case "KarteLaden" des Use Case Diagramms "Mensa".<br />
73
74<br />
Für einige Objekte ist ein Objektnamen angegeben, bei anderen Objekten wurde er<br />
vernachlässigt. Objekte der Klassen "LeseSchreibEinheit" und "Display" tragen<br />
einen Objektnamen, weil sie Teil des Mensaautomaten und der Kasse sind. Zur<br />
Unterscheidung erhielten sie einen Objektnamen. Die Objekte der Klassen "Knopf"<br />
und "GeldEinzug" sind im Modell nur einmal vorhanden, der Objektnamen wurde<br />
deshalb nicht angegeben.<br />
Die Lebenslinien des Display-Objekts und des Karten-Objekts sind nicht bis zum<br />
unteren Rand des Diagramms durchgezogen; dadurch werden Kreuzungen<br />
vermieden, das Diagramm wird übersichtlicher.<br />
Die Nachrichtennamen stehen immer in der Nähe der Pfeilspitzen. Wenn es<br />
möglich war, wurden sie über den Pfeilen angegeben. Dadurch ist die Zuordnung<br />
der Namen eindeutig und das Diagramm ist leicht lesbar.<br />
Auf die Verwendung von kombinierten Fragmenten wurde verzichtet. Das<br />
Diagramm enthält eine Alternative, die durch Notizen an den beiden Nachrichten,<br />
die alternativ gesendet werden, markiert ist.<br />
Der Akteur "Kunde" greift auf das Objekt "mAutomat" der "LeseSchreibEinheit"<br />
zu, indem er die Nachricht "KarteEin(meineKarte)" sendet. Er übergibt über diese<br />
Nachricht den Parameter "meineKarte" an die "LeseSchreibEinheit". Die<br />
"LeseSchreibEinheit" liest die "MensaKarte" und lädt sie in ihren Speicher. Die<br />
"MensaKarte" ist ein passives Objekt (Datenträger). Auf die Verwendung eines<br />
Konstruktoraufrufs wurde verzichtet. Die "MensaKarte" gibt über den Return den<br />
"Betrag" an die "LeseSchreibEinheit" zurück. Diese sendet die Nachricht "zeige"<br />
an das Display und übergibt den "Betrag". Der Kunde kann jetzt zwischen den<br />
markierten Zweigen der Alternative wählen; er kann Geld einlegen oder den Knopf<br />
drücken und die Karte zurückfordern. Es wird jeweils der Zweig des Diagramms<br />
ausgeführt, der den beiden Alternativen folgt.<br />
Über die Nachricht "GeldEin()" wird der Geldeinzug aktiviert. Er zieht den<br />
eingelegten Schein ein und ruft seine eigene Methode "pruefeSchein()" auf. Der<br />
Return gibt TRUE oder FALSE zurück. Ist die Bedingung "[Schein nicht echt]"<br />
erfüllt, ruft der "Geldeinzug" seine eigene Methode "GeldRaus()" auf und gibt den<br />
Schein zurück. Trifft die Bedingung "[Schein echt]" zu, sendet er dem Display die<br />
Nachricht "zeige(Betrag)"; der Betrag wird auf dem Display angezeigt und danach<br />
auf die "MensaKarte" gespeichert. Da mehrere Scheine hintereinander<br />
eingeschoben werden können, kann die entsprechende Sequenz von Nachrichten<br />
mehrfach ausgeführt werden. Dies wurde durch die beiden waagrechten Linien und<br />
dem mit "repeat" bezeichneten Pfeil ausgedrückt. Das kombiniert Fragment loop<br />
wurde wegen der Einfachheit des Diagramms nicht eingesetzt.<br />
Nachdem genügend Scheine eingeschoben wurden, drückt der Kunde auf den<br />
Knopf. Der Knopf teilt dieses Ereignis über die Nachricht "knopfGedrueckt" der<br />
"LeseSchreibEinheit" mit. Diese aktiviert ihre eigene Methode "KarteRaus" und<br />
gibt die Karte wieder aus.
Sequenzdiagramm der Szene Essen zahlen<br />
Abbildung 3.3.6.6.2Beispiel, Sequenzdiagramm Karte laden<br />
76<br />
Dieses Sequenzdiagramm modelliert die Szene "Essen zahlen". Es bezieht sich auf<br />
den Use Case "EssenZahlen" des Use Case Diagramms "Mensa".<br />
Aufgabe: Interpretieren Sie dieses Diagramm.
3.3.7 Kommunikationsdiagramm - Communication Diagram<br />
3.3.7.1 Zweck<br />
In Kommunikationsdiagrammen wird die Interaktion zwischen Objekten<br />
dargestellt. Sie geben die Beziehungen zwischen den Objekten an und die<br />
Nachrichten, die übertragen werden. Dabei steht der Überblick der<br />
Kommunikationsstruktur im Vordergrund.<br />
Die Darstellung der zeitlichen Reihenfolge, in der die Nachrichten gesendet<br />
werden, kann durch eine Nummerierung vorgenommen werden.<br />
3.3.7.2 Notation<br />
Symbol Beschreibung<br />
Objekt<br />
Das Rechteck stellt eine Objekt dar. Es kann einen<br />
Objektnamen und einen Klassenenamen tragen.<br />
Beziehung, Nachricht<br />
Tabelle 7Notation Kommunikationsdiagramm<br />
3.3.7.3 Anwendungsbereich<br />
Die Kommunikationsbeziehungen zwischen Objekten<br />
werden als Linie dargestellt. An die Beziehungen werden<br />
die Nachrichten, die darüber übertragen werden<br />
geschrieben. Die Nummerierung vor den<br />
Nachrichtennamen gibt die zeitliche Reihenfolge der<br />
Nachrichten an. Der Pfeil gibt die Richtung der<br />
Nachrichten an.<br />
Kommunikationsdiagramme stellen den Informationsaustausch zwischen Objekten<br />
dar. Sie können die gesamte Struktur einer Anwendung abbilden oder sich auf<br />
Teile einer Anwendung beziehen. Kommunikationsdiagramme werden für die<br />
selben Zwecke eingesetzt wie Sequenzdiagramme.<br />
3.3.7.4 Zusammenhang<br />
77
78<br />
Da die Kommunikationsdiagramme alternativ zu Sequenz Diagrammen verwendet<br />
werden, sind die selben Zusammenhänge zu berücksichtigen, die unter<br />
Sequenzdiagrammen beschrieben sind.<br />
3.3.7.5 Hinweise für die Praxis<br />
Kommunikationsdiagramme werden dann als Alternative zu Sequenz Diagrammen<br />
verwendet, wenn an einer Szene viele Objekte beteiligt sind, die wenige<br />
Nachrichten austauschen. Sind wenige Objekte an einer Szene beteiligt, die viele<br />
Nachrichten austauschen, sind Sequenz Diagramme wegen der übersichtlicheren<br />
Darstellung der zeitlichen Zusammenhänge vorzuziehen.<br />
Neu in UML 2.0<br />
Der Name der Kommunikationsdiagramme in der UML 2.0 ist neu, die Notation<br />
ist unverändert geblieben. In der UML 1.x wurden diese Diagramme mit dem<br />
Namen Kollaborationsdiagramme, Collaboration diagram bezeichnet.<br />
3.3.7.6 Beispiel<br />
Dieses Kommunikationsdiagramm zeigt die Kommunikation der Objekte, die an<br />
der Szene "EssenZahlen" beteiligt sind. Es macht deutlich, über welche<br />
Kommunikationswege die Objekte Informationen austauschen. Die zeitliche<br />
Reihenfolge ist jedoch in dem entsprechenden Sequenzdiagramm besser zu sehen.<br />
Dass die Nachrichten "essenEin" und KarteEin" parallel erfolgen können, ist in<br />
Kommunikationsdiagrammen nicht darstellbar. Diese Information ist am<br />
übersichtlichsten in dem Aktivitätsdiagramm modellierbar.<br />
Die Nummerierung wurde so gewählt, daß die erste Stelle der Nummer den<br />
"Zweig" angibt und die zweite Stelle die Reihenfolge in einem Zweig. Es wird also<br />
zuerst die Nachricht mit der Nummer 1 und danach 1.1 gesendet. Im unteren Zweig<br />
wird in folgender Reihenfolge kommuniziert: 2, 2.1, 2.2, danach wird entweder<br />
2.3a oder 2.3b gesendet.
Abbildung 3.3.7.6.1Beispiel, Kommunikationsdiagramm Essen zahlen<br />
3.3.8 Zeitverlaufsdiagramm - Timing-Diagram<br />
3.3.8.1 Zweck<br />
Timing-Diagramme stellen das zeitliche Verhalten von Systemelementen<br />
(Classifier z. B. Klassen, Objekte, Komponenten) in einem bestimmten Zeitraum<br />
dar. Es wird damit ausgedrückt, wann ein Objekt seinen Zustand ändert und wie<br />
lange es für eine Aktion benötigt. Werden mehrere Classifier in einem Diagramm<br />
dargestellt, können die Interaktionen zwischen den Classifiern ebenfalls modelliert<br />
werden. Timing Diagramme stammen aus der Elektrotechnik und werden zur<br />
Visualisierung von Signalverläufen eingesetzt.<br />
3.3.8.2 Notation<br />
Die Notation des Zeitverlaufdiagramms ist in dem Beispiel erläutert.<br />
79
80<br />
3.3.8.3 Anwendungsbereich<br />
Timing Diagramme sollten verwendet werden, wenn das zeitliche Verhalten<br />
modularer Systeme spezifiziert wird. Sie eignen sich zur Visualisierung der<br />
Abhängigkeiten zwischen den Modulen.<br />
3.3.8.4 Zusammenhang<br />
Zeitverlaufdiagramme müssen konsistent in einem Modell integriert werden. Die<br />
verwendeten Klassen müssen in dem Klassenmodell existieren. Die Zustände<br />
müssen in den Zustandsdiagrammen der entsprechenden Klassen vorhanden sein.<br />
Die Nachrichten müssen mit den restlichen Interaktionsdiagrammen und den<br />
Klassendiagrammen übereinstimmen.<br />
3.3.8.5 Hinweis für die Praxis<br />
Neu in UML 2.<br />
Timing Diagramme sind neu in der UML 2.0.<br />
3.3.8.6 Beispiel<br />
Das Beispiel modelliert das Laden einer Karte. Die Diagrammelemente sind mit<br />
hellgrauer Schrift bezeichnet. Der obere Bereich enthält die Lebenslinie des<br />
Mensaautomaten, der untere Bereich die Lebenslinie eines Studierenden, der den<br />
Automat benutzt. Auf der y-Achse sind die Zustände der Objekte angegeben, die x-<br />
Achse enthält die Zeitskala. Die Treppenkurve zeigt die Zustandsübergänge und die<br />
Dauer, für die ein Objekt in einem Zustand bleibt. Zwischen den Lebenslinien sind<br />
die Nachrichten, über die die beteiligten Objekte miteinander interagieren<br />
angegeben. Die Zeitbedingung "T
3.3.9 Interaktionsübersicht Diagramm - Interaction Overview Diagram<br />
3.3.9.1 Zweck<br />
Interaktionen können in der UML in verschiedenen Diagrammtypen dargestellt<br />
werden, wie z. B. Sequenzdiagramm, Aktivitätsdiagramm,<br />
Kommunikationsdiagramm, Zeitverlaufsdiagramm. Jedes dieser Diagramme stellt<br />
eine bestimmte Sicht auf ein System oder einen bestimmten Ausschnitt eines<br />
Systems dar. In Interaktionsübersichts Diagrammen können Teildiagramme in<br />
Bezug zueinander gesetzt werden. Das Interaktionsübersicht Diagramm enthält<br />
81
82<br />
Rahmen, die eine Interaktion, bzw. eine Referenz auf ein Interaktionsdiagramm<br />
darstellen. Die Rahmen werden über die aus den Aktivitätsdiagrammen bekannten<br />
Kontrollstrukturen miteinander verknüpft. Interaktionsübersicht Diagramme sind<br />
spezielle Aktivitätsdiagramme, bei den die Aktivitäten durch die Interaktionsrahmen<br />
ersetzt sind.<br />
3.3.9.2 Anwendungsbereich<br />
Interaktionsübersicht Diagramme können zur Modellierung von System mit vielen<br />
Interaktionen verwendet werden. Interaktionsübersicht Diagramme geben eine<br />
Übersicht über das Zusammenspiel von mehreren Interaktionsdiagrammen.<br />
3.3.9.3 Zusammenhang<br />
Da Interaktionsrahmen Referenzen auf andere Interaktionsdiagramme<br />
repräsentieren, müssen die referenzierten Diagramme konsistent gehalten werden.<br />
3.3.9.4 Hinweis für die Praxis<br />
Neu in UML 2.<br />
Interaktionsübersicht Diagramme sind neu in der UML 2.0.<br />
3.3.9.5 Beispiel<br />
Das Beispiel stellt ein Interaktionsübersicht Diagramm dar. Der mit sd bezeichnete<br />
Rahmen enthält ein Sequenzdiagramm. Die beiden mit ref bezeichneten Rahmen<br />
enthalten eine Interaktionsreferenz, werden also in weiteren Diagrammen<br />
verfeinert.
3.3.10 Zustandsautomat-State Machine Diagram<br />
3.3.10.1 Zweck<br />
Zustandsautomaten sind Diagramme zur Spezifikation des Verhaltens von<br />
Classifiern (Elemente). Cassifier können sein: Klassen, Komponenten, Systeme,<br />
Zustandsautomaten beschreiben das Verhalten der Elemente während ihres<br />
Lebenszyklus durch Darstellung der möglichen Zustände und Zustandsübergänge.<br />
Sie zeigen Aktivitäten, die Elemente in den Zuständen ausführen und Ereignisse<br />
und Bedingungen, die Zustandsübergänge verursachen.<br />
Die UML 2.0 unterscheidet state machines, die Verhalten von Systemen oder Systemteilen<br />
beschreiben, und state machines, die Protokolle, die von einem Systemelement<br />
realisiert werden, modellieren. Zustandsautomaten werden häufig zur<br />
Darstellung des Lebenszyklus von Objekten benutzt, können sich aber auch auf<br />
andere Elemente beziehen.<br />
83
84<br />
3.3.10.2 Notation<br />
Da die Notationselemente für Zustandsautomaten sehr komplex sein können,<br />
werden sie hier in zwei Bereichen behandelt: die grundlegenden Konzepte der Zustandsautomaten<br />
werden im Abschnitt Notation - Konzept beschrieben, die weiterführenden<br />
Konzepte werden unter Notation - erweitert dargestellt.<br />
Notation - Konzept<br />
Symbol Beschreibung<br />
Anfangs-, Endzustand (initial state, final state)<br />
geben den Beginn und Ende des Lebenszyklus<br />
eines modellierten Elementes an. Wird ein Objekt<br />
erzeugt, befindet es sich im Anfangszustand, wird<br />
es gelöscht, befindet es sich im Endzustand.<br />
Zustand (state)<br />
Elemente können im Laufe ihrer Existenz eine endliche<br />
Anzahl Zustände einnehmen. Der Zustand<br />
wird als Rechteck mit abgerundeten Ecken dargestellt.<br />
Zustände können einen Namen erhalten. Ein<br />
Zustand kann durch eine waagrechte Linie unterteilt<br />
werden. Unterhalb der Linie können Aktivitäten<br />
und interne Transitionen angegeben werden.<br />
Diese werden in dem Zustand ausgeführt. Die<br />
UML definiert folgende internen Aktivitäten:<br />
entry, exit und do. Die entry-Aktivität wird <strong>beim</strong><br />
Eintritt in den Zustand ausgeführt, die exit-<br />
Aktivität vor Verlassen des Zustands. Do-<br />
Aktivitäten werden zwischen entry und exit-<br />
Aktivität ausgeführt und können länger andauern.<br />
Interne Transitionen werden intern ausgeführt,<br />
führen jedoch nicht zu einem Zustandsübergang.<br />
Es kann ein Auslöser (Trigger) angegeben werden,<br />
eine Bedingung (guard), die erfüllte sein muß und<br />
eine Aktivität, die ausgeführt wird.
Symbol Beschreibung<br />
Zustandsübergang (Transition)<br />
Eine Transition ist ein Zustandsübergang von<br />
einem Quellzustand zu einem Zielzustand. Die Beschriftung<br />
gibt den Auslöser (Trigger) an, die Bedingung,<br />
die erfüllt sein muß (guard) und die Aktivität,<br />
die <strong>beim</strong> Übergang ausgeführt wird. Die<br />
Beschreibungselemente sind optional. Sie können<br />
beliebig kombiniert werden.<br />
Zustand (State)<br />
Der Zustand (state) eines Objekts wird durch die Attributwerte bzw. Daten und die<br />
jeweiligen Verbindungen zu anderen Objekten bestimmt [Balzert, 1999].<br />
Die UML 2.0 unterscheidet drei Zustandstypen:<br />
• einfacher Zustand - simple state<br />
• zusammengesetzter Zustand - composite state<br />
• Unterzustandsautomatenzustand - submachine state<br />
Einfacher Zustand (simple state)<br />
Ein einfacher Zustand hat keine Unterzustände (Regionen oder submachine state<br />
machine). Ein einfacher Zustand kann entry, exit und do-Aktivitäten enthalten und<br />
interne Transitionen. Nach Erreichen eines Zustands wird sofort die entry-Aktivität<br />
ausgeführt. Vor Verlassen des Zustands wird die exit-Aktivität ausgeführt. Die do-<br />
Aktivität wird nach Beendigung der exit-Aktivität ausgeführt.<br />
Zustandsübergang (Transition)<br />
Eine Transition wird durch einen Auslöser (Trigger) verursacht. Der Trigger kann<br />
intern sein oder extern; er kann von dem Objekt kommen, auf das die state<br />
machine sich bezieht, oder von einem anderen Objekt. Für einen Zustandsübergang<br />
kann eine Bedingung (guard) angegeben werden, die erfüllt sein muß, damit die<br />
Transition ausgeführt wird. Bei einer Transition kann ein Objekt eine Aktivität<br />
ausführen, die zu dem Aufruf einer Methode führt.<br />
Einfacher Zustandsautomat<br />
Zustandsautomaten beschreiben den Lebenszyklus von Objekten, können sich aber<br />
auch auf komplexere Elemente beziehen, wie z. B. Komponenten, Subsysteme<br />
oder Use Cases. Sie stellen die Zustände dar, die Objekte, Komponenten usw. im<br />
85
86<br />
Laufe ihrer Existenz annehmen können und sie geben die Zustandsübergänge an,<br />
die möglich sind. Ein Zustandsautomat gibt auch an, in welchem Zustand ein<br />
Objekt auf welche Ereignisse reagiert.<br />
Diese Abbildung stellt einen einfachen Zustandsautomat einer Tür dar. Die Tür<br />
kann die beiden Zustände offen und geschlossen annehmen. Sie reagiert auf die Ereignisse<br />
schliessen und öffnen. In dem Zustand offen kann jedoch nur das Ereignis<br />
schliessen angewandt werden, in dem Zustand geschlossen kann nur das Ereignis<br />
öffnen angewandt werden.<br />
Dieses Beispiel modelliert eine Loginmaske eines Rechners. Sie hat die Zustände<br />
"UserNameEingabe" und "PasswortEingabe". In dem Zustand<br />
"UserNameEingabe" führt sie die Aktivität "ZeichenLesen" aus. Ist die Bedingung<br />
"[Cursor in Feld Passwort]" erfüllt, so wechselt sie zu dem Zustand
"PasswortEingabe". Sobald die Maske den Zustand betritt führt sie die entry-<br />
Aktivität "Echo aus" aus, sie schaltet das Echo aus und zeigt das Passwort nicht auf<br />
dem Bildschirm an. Danach liest sie mit der Aktivität "ZeichenLesen" das Passwort<br />
ein und schaltet bei Verlassen des Zustands mit der exit-Aktivität "Echo an" das<br />
Bildschirmecho wieder ein.<br />
Pseudozustände<br />
Symbol Beschreibung<br />
Region (Region)<br />
Regionen können in zusammengesetzten Zuständen<br />
und in state machine Diagrammen verwendet<br />
werden. Sie stellen parallele Abläufe oder parallele<br />
Zustände dar. Regionen können einen Namen<br />
haben. Die Regionen in einem Zustand werden<br />
durch eine gestrichelte Linie voneinander<br />
abgegrenzt. Regionen können Zustände und<br />
Transitionen enthalten.<br />
sind Knoten in einem Zustandsdiagramm, die es erlauben komplexe Zusammenhänge<br />
zwischen Zuständen darzustellen (z. B. Verzweigungen, Parallelität usw.).<br />
Pseudozuständen werden keine Aktivitäten zugeordnet. Die Erläuterung der Pseudozustände<br />
erfolgt in der nächsten Version des Skriptes.<br />
Entscheidung<br />
Kreuzung<br />
Terminator<br />
Eintrittspunkt<br />
Austrittspunkt<br />
87
88<br />
Symbol Beschreibung<br />
Gabelung<br />
Vereinigung<br />
Flache Historie<br />
Tiefe Historie<br />
Zusammengesetzter Zustand (composite state)<br />
Ein zusammengesetzter Zustand ist ein Zustand, in dem Unterzustände möglich<br />
sind. Das Beispiel stellt die Zustände einer abschließbaren Tür dar. Die Tür kann<br />
die Zustände zugeschlossen und aufgeschlossen haben. Nur in dem Zustand aufge-
schlossen kann sie die Unterzustände offen und geschlossen haben. Ist das untergeordnete<br />
Zustandsdiagramm zu groß um im Zustand dargestellt zu werden, kann es<br />
auch in einem Verfeinerungsdiagramm modelliert werden.<br />
Unterzustandsautomatenzustand (submachine state)<br />
Der Unterzustandsautomatenzustand ist ein gutes Beispiel für unverständliche<br />
Wortungetüme, die die deutsche Sprache hervorbringen kann. Der Submachine<br />
State bezeichnet einen Zustand, der Unterzustände enthält, die in einem<br />
untergeordneten Zustandsdiagramm verfeinert sind. Im Zustandssymbol wird der<br />
Zustandsnamen angegeben und mit Doppelpunkt getrennt der Zustandsautomat,<br />
der ihn verfeinert.<br />
3.3.10.3 Anwendungsbereich<br />
Zustandsdiagramme werden häufig im Bereich Embedded Systems eingesetzt, sind<br />
aber auch in anderen Bereichen verwendbar. Sie werden nur für Klassen mit nicht<br />
trivialemem (interessantem) Lebenszyklus modelliert. Ein trivialer Lebenszyklus<br />
ist dann vorhanden, wenn ein Zustandsdiagramm nicht zum besseren Verständnis<br />
des Verhaltens des Objektes beiträgt. Nicht triviale Lebenszykeln von Objekten<br />
liegen dann vor, wenn die Objekte "viele" Zustände haben und in den einzelnen<br />
Zuständen nur auf eine bestimmte Art und Weise auf eingehende Nachrichten reagieren<br />
können.<br />
3.3.10.4 Zusammenhang<br />
Ein Zustandsdiagramm kann sich auf eine Klasse des Klassendiagramms beziehen.<br />
Es kann aber auch die Zustände von komplexeren Modellelementen (Subsystemen)<br />
darstellen. Die Nachrichten auf die eine Klasse mit einem Zustandsübergang reagiert,<br />
werden von anderen Klassen oder Akteuren gesendet.<br />
3.3.10.5 Hinweis für die Praxis<br />
Zustandsautomaten sollten nur bei komplexen Objekten verwendet werden. Ein<br />
Objekt ist dann komplex, wenn es viele Methoden oder viele Attribute hat. Bei<br />
einfach strukturierten Objekten bringt der Einsatz von Zustandsautomaten keine<br />
89
90<br />
zusätzlichen Erkenntnisse. Jeder Zustand und Pseudozustand, außer dem Anfangsund<br />
Endzustand, sollte mindestens einen ein- und eine ausfließende Transition<br />
haben.<br />
Style Guide<br />
Zustandsdiagramme sollten so gestaltet werden, dass sie von links oben nach rechts<br />
unten lesbar sind. Zustand sollte aus- und einfliessende Pfeile haben, jeder Zustand<br />
muß erreichbar sein und wieder verlassen werden können.<br />
Neu in UML 2.<br />
Der Name State Machine Diagram ist in der UML 2.0 neu. In früheren Versionen<br />
der UML wurden dieser Diagrammtyp Zustandsübergangsdiagramme, State Diagram<br />
oder State Transition Diagram genannt. Diese Bezeichnungen werden heute<br />
immer noch verwendet.<br />
3.3.10.6 Beispiel<br />
Der Mensaautomat hat die Zustände bereit, KarteCheck, GeldFordernd,<br />
GeldEinzug und LadeKarte. Nach dem Aktivieren befindet er sich in dem Zustand<br />
bereit. Diesen Zustand verläßt er, wenn das externe Ereignis KarteEin auf ihn<br />
einwirkt. Er führt die Transition zu dem Zustand KarteCheck durch. In diesem<br />
Zustand liest er über die Aktivität lies die Mensakarte. Ist die Karte in Ordnung<br />
(Bedingung Karte = OK), führt er die Aktivität zeige aus und zeigt den Betrag an.<br />
Er wechselt den Zustand zu GeldFordernd. Trifft die Bedingung Karte = !OK zu,<br />
führt er die Aktivität KarteRaus aus und geht zurück in den Zustand bereit. Das<br />
externe Ereignis druecken() (des Rückgabeknopfes) veranlaßt den Automat zur<br />
Zustandsänderung von GeldFordernd zu bereit; er gibt die Karte zurück. In dem<br />
Zustand GeldFordernd reagiert der Mensaautomat außerdem noch auf das Ereignis<br />
GeldEin; es führt zu der Transition zu GeldEinzug. Dort wird zuerst die entry-<br />
Aktivität pruefeSchein ausgeführt, danach zeigt die Aktivität zeige den aktuellen<br />
Geldbetrag an. Das Ereignis GeldEin führt zu einer rekursiven Transition; der<br />
Kunde kann mehrere Geldscheine einschieben. Das Ereignis druecken führt zu der<br />
Transition zu LadeKarte, die Aktivität schreibe schreibt den aktuellen Geldbetrag<br />
auf die Karte. Die Karte wird herausgeschoben und der Automat wechselt in den<br />
Zustand bereit.
3.3.11 Aktivitätsdiagramm - Activity Diagram<br />
3.3.11.1 Zweck<br />
Aktivitätsdiagramme sind Diagramme zur Flussmodellierung. Sie stellen die Aktivitäten<br />
eines Systems dar, die Aktionen, aus den die Aktivitäten sich zusammensetzen<br />
und den Fluss durch die Aktivitäten.<br />
Mit Aktivitätsdiagrammen können komplexe Abläufe in einem System modelliert<br />
werden (Geschäftsprozesse, Workflows).<br />
Da Aktivitäten aus Aktionen und deren zeitlicher Verknüpfung bestehen, können<br />
sie auch zur Modellierung der internen Logik komplexer Operationen verwendet<br />
werden und somit Algorithmen visualisieren.<br />
91
92<br />
Aktivitätsdiagramme können in Verantwortungsbereiche gegliedert werden. Damit<br />
können die Aktionen bestimmten Modellelementen, wie Klassen oder<br />
Komponenten zugeordnet werden.<br />
3.3.11.2 Notation<br />
Symbol Beschreibung<br />
Aktivität (Activity)<br />
Eine Aktivität besteht aus Knoten (Aktivitäten,<br />
Aktionen, Kontroll- und Objektknoten) und<br />
Kanten (Pfeilen), die den Kontrollfluss durch<br />
die Aktivität darstellen. Die Aktivität wird als<br />
abgerundetes Rechteck dargestellt. In der linken,<br />
oberen Ecke steht der Name der Aktivität,<br />
gefolgt vom Eingangsparameter und Typ. Die<br />
Rechtecke an beiden Seiten geben die Eingangs-<br />
bzw. Ausgangsparameter an. Die Symbole<br />
in der Aktivität stellen die Aktionen dar<br />
und die Pfeile den Kontrollfluss.<br />
Aktion (Action)<br />
Eine Aktion ist in UML das Basiselement zur<br />
Spezifikation von Verhalten. Eine Aktion kann<br />
als nicht weiter zerlegbare Funktion angesehen<br />
werden. Sie transformiert eine Eingabe zu einer<br />
Ausgabe. Aktionen sind in Aktivitäten enthalten.<br />
Die UML 2.0 unterscheidet verschiedene<br />
Typen von Aktionen.<br />
Signal (Send signal action, Accept event action)<br />
Mit diesen Symbolen kann das Senden und<br />
Empfangen von Signalen dargestellt werden.<br />
Zeitereignis (Accept time event action)<br />
Über diese Symbol wird ausgedrückt, dass eine<br />
Aktion zeitgesteuert angestoßen wird.<br />
Kontrollknoten<br />
werden benutzt um Kontrollstrukturen in einem<br />
Flussgraph anzugeben.
Symbol Beschreibung<br />
Entscheidung und Zusammenführung<br />
Bei der Entscheidung wird nach Eintreffen des<br />
Tokens a entweder nach b oder nach c<br />
verzweigt. Die Bedingung, die erfüllt sein muss,<br />
kann als Ausdruck in eckigen Klammern an den<br />
Pfeilen angegeben werden.<br />
Bei der Zusammenführung wird nach Eintreffen<br />
der Token a oder b nach c verzweigt.<br />
Splitting, Synchronisation<br />
Bei einem Splitting-Knoten wird in mehrere<br />
parallele Threads verzweigt (wenn a da ist, feuern<br />
b und c). Ein Synchronisationsknoten synchronisiert<br />
mehrere Threads (wenn a und b da<br />
sind, feuert c).<br />
Start-, Endknoten, Ablaufende<br />
Ein Startknoten (Initial Node) stellt den Beginn<br />
eines Ablaufes dar. Ein Endknoten (Activity<br />
Final Node) beendet eine Aktivität vollständig.<br />
Ein Ablaufende (Flow Final Node) terminiert<br />
einen Zweig einer Aktivität, die Aktivität selbst<br />
läuft weiter.<br />
Pfeil/Kante<br />
Ein Pfeil beschreibt den Fluss zwischen den<br />
verbundenen Elementen. In einer eckigen<br />
Klammer kann eine Bedingung angegeben<br />
werden, die erfüllt sein muss, damit die Kante<br />
überquert wird.<br />
Objektknoten<br />
können in Aktivitätsdiagrammen Objekte oder<br />
Daten repräsentieren. Sie können als unabhängige<br />
Knoten in einem Diagramm benutzt<br />
werden, bzw. als Parameter für Aktionen (Input,<br />
Output Pin). Beide Darstellungen sind<br />
äquivalent. Im Bild oben ist a als Objekt eingezeichnet;<br />
im unteren Bild ist a Ausgangsparameter<br />
der linken Aktion und Eingangsparameter<br />
der rechten.<br />
93
94<br />
Symbol Beschreibung<br />
Kanten<br />
Tabelle 8Notation Aktivitätsdiagramm<br />
Prinzip der Aktivitätsdiagramme<br />
verbinden die Aktionen in einem Diagramm<br />
und stellen den Fluss dar. Kanten, die Kontrollfluss<br />
modellieren, verbinden Aktionen direkt;<br />
Objektflusskanten verbinden die Pins der beteiligten<br />
Aktionen.<br />
Aktivitätsdiagramme zeigen den Ablauf von Aktivitäten. Sie definieren die Aktionen,<br />
aus den sich Aktivitäten zusammensetzen und die zeitliche Reihenfolge ihrer<br />
Ausführung. Verzweigungen des Kontrollflusses und gleichzeitig ablaufende,<br />
parallele Zweige sind möglich. Um die ausgeführten Aktionen verfolgen zu<br />
können, werden die Zweige eines Aktivitätsdiagramms mit Tokens belegt. Ein Token<br />
ist eine Marke, die den Kontrollfluss markiert. In jedem Thread existiert ein<br />
Token. Tokens besitzen kein Symbol in der UML. Sie sind virtuelle Elemente, die<br />
den Kontrollfluss markieren.<br />
Abbildung 3.3.11.2.1Beispiel Token in Aktivitätsdiagrammen<br />
In Abbildung 3.3.11.2.1 ist das Prinzip des Token-Modells dargestellt. Nachdem<br />
der Ablauf gestartet wurde, wird das erste Token, links im Bild, erzeugt. Danach<br />
wird die Aktion a1 ausgeführt und das Token auf den Ausgang von a1 gelegt.<br />
Durch die Verzweigung in die beiden Threads p1 und p2 wird am Anfang beider<br />
Threads je ein Token gesetzt. Die Aktionen p1 und p2 werden ausgeführt; die<br />
Tokens werden auf die Ausgänge von p1 und p2 gelegt. Wenn beide Tokens da<br />
sind, wird das Eingangstoken für a2 gestartet. A2 wird ausgeführt, das Token auf<br />
den Ausgang von a2 gelegt, die Aktivität wird beendet und das Token vernichtet.<br />
Aktionstypen<br />
Die UML 2.0 definiert verschiedene Typen von Aktionen, die für bestimmte Zwecke<br />
verwendet werden können, z. B. Aktionen zum<br />
• Erzeugen, Löschen von Objekten
• Lesen und Schreiben von Attributwerten<br />
• Aufrufen von Operationen<br />
• Empfangen und Senden von Signalen<br />
• u. a.<br />
Verantwortungsbereiche (Partitions)<br />
Aktivitäten können komplexe Abläufe darstellen, die durch unterschiedliche<br />
Modellelemente ausgeführt werden, bzw. für die unterschiedliche Elemente<br />
verantwortlich sind. Zur Zuordnung der Aktionen einer Aktivität zu den verantwortlichen<br />
Elementen können Aktivitätsdiagramme in Partitionen (Activity Partition)<br />
unterteilt werden. Da ein entsprechend aufgeteiltes Diagramm wie eine in<br />
Schwimmbahnen eingeteiltes Schwimmbecken aussieht, werden die Activity<br />
Partitions auch swimlanes genannt.<br />
Abbildung 3.3.11.2.2Verantwortungsbereiche in Aktivitätsdiagrammen<br />
In Abbildung 3.3.6.2.2 ist das Aktivitätsdiagramm in die Bereiche Partition 1 und<br />
Partition 2 unterteilt. Die Aktionen a1 und a3 gehören zu der Partition 1; die<br />
Aktion 2 gehört zu der Partition 2. Partitionen können senkrecht und waagrecht<br />
angelegt werden.<br />
Verfeinern von Aktivitäten<br />
95
96<br />
Abbildung 3.3.11.2.3Verfeinern von Aktivitäten<br />
Aktivitäten können in weiteren Aktivitätsdiagrammen verfeinert werden. Das zu<br />
verfeinernde Element wird mit einem Gabelsymbol gekennzeichnet und kann in<br />
einem Unterdiagramm verfeinert werden. So können Hierarchien von Aktivitätsdiagrammen<br />
modelliert werden. Alle Aktivitäten sind auf der untersten<br />
Hierarchieebene auf Aktionen abzubilden.<br />
3.3.11.3 Anwendungsbereich<br />
Aktivitätsdiagramme werden zur Modellierung von Abläufen und deren Steuerung<br />
benutzt. In Aktivitätsdiagrammen werden die einzelnen Verfahrensschritte von<br />
Aktivitäten und die Reihenfolge in der sie ausgeführt werden dargestellt. Sie<br />
können von der Modellierung von Geschäftsprozessen bis zur Visualisierung von<br />
Kontrollflüssen benutzt werden. Eine Aktivität setzt sich aus den Aktionen zusammen,<br />
die im Aktivitätsdiagramm enthalten sind.<br />
Aktivitätsdiagramme können in einem Projekt überall verwendet werden, wo<br />
Verhalten beschrieben werden muss, bzw. wo Datenflüsse oder Kontrollflüsse<br />
modelliert werden sollen.<br />
3.3.11.4 Zusammenhang<br />
Da Aktivitätsdiagramme sehr vielfältig einsetzbar sind, können vielfältige Beziehungen<br />
zwischen Aktivitätsdiagrammen und anderen Diagrammen der UML bestehen.
Aktivitätsdiagramme können die Abläufe von Anwendungsfällen aus Use Case<br />
Modellen beschreiben. Sie können verwendet werden, um z. B. den Ablauf eines<br />
Geschäftsprozesses, der einem Use Case zugeordnet ist, zu modellieren. Es ist<br />
aber auch möglich, dass mehrere Aktivitätsdiagramme den Ablauf eines Use Cases<br />
modellieren; in einem Aktivitätsdiagramm könnte das Normalverhalten eines Use<br />
Case modelliert werden in einem weiteren könnte eine Alternative zum Normalverhalten<br />
beschrieben werden.<br />
Da die Darstellung der Kontrollstrukturen höherer Programmiersprachen in der<br />
Notation der Aktivitätsdiagramme enthalten ist, können sie auch zur Spezifikation<br />
von Algorithmen verwendet werden.<br />
Aktivitätsdiagramme müssen mit den anderen Diagrammen in einem Projekt<br />
konsistent gehalten werden. Aktionen können Operationen bei den Klassen eines<br />
Modells erfordern.<br />
3.3.11.5 Hinweise für die Praxis<br />
Style Guide<br />
• Diagramme sollten übersichtlich angeordnet werden. Kannten zwischen den<br />
Knoten sollten möglichst kreuzungsfrei sein.<br />
• Besonders wenn Aktivitätsdiagramme mit Verantwortungsbereichen gezeichnet<br />
werden, entstehen große Diagramme. Zur Integration der Diagramme in einer<br />
Projektdokumentation sollte das Ausgabeformat (DIN A 4) berücksichtigt<br />
werden. Es kann sinnvoll sein große Diagramme über mehrere Seiten zu<br />
zerlegen und diese über Konnektoren miteinander zu verbinden.<br />
• Bei Entscheidungsknoten sollten die Bedingungen in der Nähe des Konnektors<br />
angegeben werden.<br />
• Entscheidungsknoten sollten einen Bezug zur Aktion haben, der sie nachfolgen.<br />
• Start- und Endknoten sollten angegeben werden, um unmissverständlich Beginn<br />
und Ende einer Aktivität zu dokumentieren.<br />
• Die Pfeilspitzen sollten so angeordnet werden, dass Diagramme von oben nach<br />
unten und von links nach rechts lesbar sind.<br />
Neu in UML 2.0<br />
Die Aktivitätsdiagramme in UML 2.0 erfuhren die größten Veränderungen gegenüber<br />
der UML 1.x.<br />
In der UML 1.x waren die Aktivitätsdiagramme eine spezielle Form der Zustandsdiagramme.<br />
In der UML 2.0 sind die Aktivitätsdiagramme eigenständig.<br />
Einige Begriffe der UML 1.x wurden weiterverwendet, bekamen aber eine vollständig<br />
neue Bedeutung. Ein Aktivitätsdiagramm in UML 2.0 beschreibt eine Ak-<br />
97
98<br />
tivität, die Teilschritte werden Aktionen genannt. In der UML 1.x wurden die Teilschritte<br />
eines Aktivitätsdiagramms Aktivitäten genannt; die Aktivitäten der UML<br />
1.x heißen jetzt Aktionen, das Aktivitätsdiagramm von UML 1.x heißt jetzt Aktivität.<br />
Aktivitätsmodelle haben jetzt eine starke Ähnlichkeit zu Petrinetzen.<br />
Ein Aktivitätsdiagramm darf mehrere Anfangszustände haben.<br />
Signale, Zeitereignis und das Ablaufende wurden als neue Notationselemente eingeführt.<br />
Zur Darstellung von Objektflüssen können die "fließenden" Objekte als<br />
Objektknoten angegeben werden.<br />
Aktivitätsdiagramme dürfen Ein- und Ausgabeparameter enthalten.<br />
3.3.11.6 Beispiel<br />
Bei der Modellierung des Beispiels wurden folgende Annahmen getroffen:<br />
Die Diagramme modellieren jeweils einen Geschäftsprozess zu einem Use Case.<br />
Zur Darstellung der externen Ereignisse, die auf die Aktivitäten einwirken, sind die<br />
Akteure, die diese auslösen in den Diagrammen enthalten. Sie sind mit einer<br />
gerichteten Kante mit der Aktion, auf die sie zugreifen, verbunden.<br />
Die Diagramme zeigen den Kontrollfluss, keinen Daten- oder Objektfluss.<br />
Aktivitätsdiagramm EssenZahlen
Abbildung 3.3.11.6.1Beispiel Aktivitätsdiagramm Essen zahlen<br />
Hier wurden Verantwortungsbereiche angegeben. Das Diagramm hat zwei Startpunkte,<br />
da die Aktionen "Essen eintippen" und "Karte einschieben" parallel erfolgen<br />
können. Die beiden Zweige werden auf dm folgenden Synchronisationsknoten<br />
miteinander synchronisiert.<br />
Aktivitätsdiagramm KarteLaden<br />
Das Diagramm in Abbildung 3.3.6.6.2 wurde ohne Verantwortungbereiche<br />
modelliert.<br />
99
Abbildung 3.3.11.6.2Beispiel Aktivitätsdiagramm Karte laden<br />
3.3.12 Verteilungsdiagramm - Deployment-Diagram<br />
100<br />
3.3.12.1 Zweck
Das Verteilungsdiagramm stellt die physikalische Struktur eines Systems dar. Es<br />
gibt die Zuordnung von Softwarekomponenten zu den ausführenden Hardwareeinheiten<br />
(Knoten) zur Laufzeit an und beschreibt die Kommunikation<br />
zwischen den Knoten über Kommunikationspfade.<br />
3.3.12.2 Notation<br />
Symbol Beschreibung<br />
3.3.12.3 Beispiel<br />
Knoten (Node)<br />
Ein Knoten ist eine Ressource auf der Artefakte bereitgestellt<br />
und ausgeführt werden. Es kann z. B. ein Server sein.<br />
Knoten können geschachtelt sein. Es werden die<br />
Knotentypen Gerät (device) und Ausführungsumgebung<br />
(execution environment) unterschieden.<br />
Artefakt (Artifact)<br />
Ein Artefakt ist das Ergebnis oder Produkt einer Entwicklertätigkeit.<br />
Ein Artefakt kann z. B. sein: ein Modellelement,<br />
eine Softwarekomponente, eine Quellcodedatei, eine<br />
Binärdatei, eine DB-Tabelle, usw.<br />
Kommunikationspfad (communication path)<br />
Ein Kommunikationspfad ist eine Assoziationsbeziehung<br />
zwischen Knoten. Über Kommunikationspfade können<br />
Knoten Nachrichten austauschen. Kommunikationspfade<br />
werden als Linien zwischen Knoten dargestellt und können<br />
bezeichnet werden. Kommunikationspfade können<br />
ungerichtet oder gerichtet sein. Gerichtete Beziehungen<br />
werden mit einem Pfeil angegeben.<br />
Das Beispiel zeigt die Hardwarestruktur des Beispiels Mensaautomat. Es besteht<br />
aus den Geräten Mensaautomat, Kasse und dem Mensaserver. Den Geräten sind<br />
die Softwarekomponenten zugeordnet, die darauf installiert sind.<br />
101
102<br />
3.3.13 Kompositionsstrukturdiagramm - Composite Structure Diagram<br />
3.3.13.1 Zweck<br />
Das Kompositionsstrukturdiagramm beschreibt die interne Struktur eines<br />
Classifiers und seine Interaktionsbeziehungen zu anderen Systemteilen. Es zeigt<br />
wie die Teile eines Classifiers den Classifier selbst bilden. Da es mit dem<br />
Kompositionsstrukturdiagramm möglich ist die Teile (Architekturelemente) eines<br />
Systems und ihre Beziehungen darzustellen, wird es auch Architekturdiagramm<br />
genannt. Das Kompositionsstrukturdiagramm eignet sich ebenfalls zur<br />
Modellierung von Entwurfsmustern.<br />
3.3.13.2 Notation<br />
Symbol Beschreibung<br />
Teil (Part)<br />
Ein Part ist eine Laufzeitinstanz einer Klasse oder<br />
Schnittstelle. Parts werden verwendet um<br />
Kompositionsstrukturen oder Entwurfsmuster<br />
darzustellen. Parts können Eigenschaften von<br />
Klassen sein, d. h. sie können in der Klasse<br />
enthalten sein.
Symbol Beschreibung<br />
3.3.13.3 Anwendungsbereich<br />
Kollaboration (Collaboration)<br />
Eine Kollaboration beschreibt die Struktur von<br />
zusammenarbeitenden Elementen, die gemeinsam<br />
das Gesamtverhalten der Kollaboration<br />
beschreiben. Die Kollaboration wird mit einem<br />
Namen bezeichnet. Die enthaltenen Elemente<br />
können in der Kollaboration angegeben werden,<br />
oder in einem weiteren<br />
Kompositionsstrukturdiagramm modelliert<br />
werden. Die Linie, die Part1 und Part2 verbindet<br />
ist ein Konnektor. Konnektoren werden<br />
verwendet um Kommunikationsbeziehungen<br />
zwischen Instanzen darzustellen.<br />
Kompositionsstrukturdiagramme können in frühen Projektphasen zur<br />
Modellierung von Systemteilen und deren Zusammenhängen eingesetzt werden.<br />
Sie können noch relativ abstrakte Modellelemente enthalten, ohne bis zur<br />
Detaillierungsebene von Klassendiagrammen ausmodelliert zu werden.<br />
Die verwendeten Strukturelemente können schrittweise verfeinert werden.<br />
3.3.13.4 Neu in UML 2.<br />
Kompositionsstrukturdiagramme sind neu in der UML 2.0.<br />
3.4 Object Constraint Language<br />
UML-Diagramme, wie z. B. Klassendiagramme drücken meistens nicht alle<br />
Aspekte eines Softwaresystems aus. Zusätzliche Bedingungen werden in<br />
natürlicher Sprache formuliert. Sie sind häufig nicht eindeutig und enthalten<br />
Widersprüche. Um diese Fehlerquellen zu beseitigen, wurde die Object Constraint<br />
Language definiert. Die OCL ist eine formale Sprache zur Beschreibung von<br />
103
104<br />
Constraints (Bedingungen, Einschränkungen) in UML-Modellen. Ein Constraint ist<br />
eine Bedingung oder Einschränkung, die für Modellelemente definiert wird.<br />
Die Constraints können z. B. zur Beschreibung folgender Eigenschaften verwendet<br />
werden:<br />
• Definition von Zusicherungen über Zusammenhänge zwischen<br />
Modellelementen, bzw. Einschränkungen,<br />
• Definition von Vor- und Nachbedingungen,<br />
• Voraussetzungen für die Ausführung von Operationen,<br />
• Zusicherungen von Ergebnissen, die Operationen liefern,<br />
• Invarianten,<br />
• Navigation in Uml-Modellen (query-language).<br />
Ein Beispiel zu einem Constraint findet sich in dem Kapitel 3.3 Diagramme der<br />
UML auf Seite 39.<br />
3.5 Model Driven Architecture<br />
3.5.1 Was ist MDA?<br />
Die Model Driven Architecture ist ein offener, herstellerunabhängiger Standard zur<br />
Modellierung von Werkzeug-unabhängigen Anwendungen. Er verfolgt das Ziel<br />
Modelle unabhängig von der aktuellen Implementierungstechnologie zu<br />
beschreiben und sie somit als Basis der Weiterentwicklung von Systemen zu<br />
nutzen, unabhängig von der sich schnell weiterentwickelnden<br />
Implementierungstechnologie. MDA trennt die Geschäftslogik von der<br />
Implementierungstechnologie und definiert dafür zwei Modelle:<br />
• PIM- Platform-Independent Model<br />
• PSM-Platform-Specific Model.<br />
3.5.2 Motivation<br />
Software lebt; sie lebt in manchen Geschäftsbereichen sehr lange. In dem<br />
Bankbereich sind Anwendungen im Einsatz, die in so antiken
Programmiersprachen wie Cobol oder PLI geschrieben wurden. Die<br />
Implementierungstechnologie ist vielfältig und entwickelt sich sehr schnell weiter.<br />
Daraus ergibt sich eine Diskrepanz zwischen der Lebenszeit der fachlichen<br />
Modellen, die der Software zugrundeliegen und der aktuellen<br />
Implementierungstechnologie. Modelle können nicht oder nur schwer an neue<br />
Implementierungstechnologie angepaßt werden, obwohl die fachlichen Modelle<br />
weiterhin gültig sind. Diese Probleme motivierten die OMG zur Definition der<br />
MDA. Das Ziel der MDA ist die Verbesserung der Wiederverwendbarkeit von<br />
Modellen. Dies soll durch die Trennung von dem fachlichen Modell und der<br />
Implementierungsplattform erreicht werden. Firmen soll die Investition in<br />
langlebige Modelle, statt in Code ermöglicht werden.<br />
3.5.3 Wie funktioniert MDA?<br />
Das Prinzip der MDA ist die Plattformunabhängigkeit von Software-Modellen.<br />
Das Plattformunabhängige Modell wird in der MDA PIM, Platform Independent<br />
Model genannt. Alle fachlichen und funktionalen Aspekte der Software werden im<br />
PIM beschrieben. Die Beschreibung erfolgt mit Standards, wie UML, OCL und<br />
XMI.<br />
Das PIM wird über ein Standardmapping auf ein oder mehrere PSM, Platform<br />
Specific Model abgebildet. Hier wird das Softwaremodell auf ein Zielsystem, wie<br />
Corba, EJB transformiert. Dieser Schritt erfolgt automatisch über das MDA-Tool.<br />
Generiert werden alle für die Zielplattform benötigten Elemente, wie z. B.:<br />
• Platform Interfaces,<br />
• fachlicher Code,<br />
• deployment descriptor,<br />
105
106<br />
• DB-Schema.<br />
Das PSM beschreibt die Anwendung mit den Mitteln der Implementierungstechnologie.<br />
Aus dem PSM wird der Plattformspezifische Code<br />
generiert.<br />
3.6 UML Profile<br />
UML-Profile sind ein Erweiterungsmechanismus der UML. Sie werden verwendet,<br />
um die Regeln des UML-Metamodells zu erweitern oder einzuschränken. Dafür<br />
stehen in der UML folgende Konstrukte zur Verfügung:<br />
• Stereotypen,<br />
• Tagged values (Eigenschaftswerte),<br />
• in OCL formulierte constraints.<br />
Eine konkrete Anpassung der UML an eigene, bestimmte Zwecke (mit Hilfe der o.<br />
g. Konstrukte) wird Profile genannt. Über Profile können also Modelle<br />
vorkonfiguriert werden; die Regeln der UML können an eigene Zwecke angepaßt<br />
werden.<br />
Die OMG liefert viele vordefinierte Profile, wie z. B.:<br />
• UML Profile for Corba<br />
• UML Profile for Enterprise Application Integration (EAI)<br />
• UML Testing Profile
4 Vorgehens- und Prozessmodelle<br />
4.1 Überblick (Motivation, Begriffe)<br />
Oft steht der Projektleiter am Anfang eines Softwareentwicklungsprojektes vor der<br />
zentralen Frage, welches Vorgehen das Beste für sein Projekt ist. In der Vorlesung<br />
Softwaretechnik wird vorrangig die objektorientierte Vorgehensweise dargestellt.<br />
Dies hat Auswirkungen auf das Projektmanagement. Einige wichtige Aspekte<br />
werden im Abschnitt 4.2 erläutert. In den nachfolgenden Abschnitten werden<br />
verschiedene Vorgehens- und Prozessmodelle vorgestellt, die in heutigen<br />
Entwicklungsprojekten eine wesentliche Rolle spielen.<br />
Im Abschnitt 4.3 werden das Wasserfallmodell sowie die evolutionären und<br />
inkrementellen Ansätze dargestellt und deren Vor- und Nachteile genannt. Viele<br />
Projekte basieren nach wie vor auf einem Wasserfallmodell trotz der Einsicht, dass<br />
bei Wasserfallmodelle Risiken oft zu einem (zu) späten Zeitpunkt erkannt und<br />
Anforderungen schlecht in einer späten Phase berücksichtigt werden können. Um<br />
Risiken möglichst früh bewerten und evtl. ausschließen zu können, ist die<br />
Entwicklung eines Prototyps ein mögliches Mittel. Im Abschnitt 4.4 werden die<br />
verschiedenen Klassifizierungsmerkmale von Prototypen herausgearbeitet und der<br />
generelle Aufbau von Prototypen dargestellt.<br />
Sogenannte schwergewichtige Prozessmodelle versuchen, ein möglichst<br />
vollständiges Rahmenwerk der Softwareentwicklung für die verschiedenen<br />
Projekttypen bereitzustellen. Im Kapitel 4.5 wird das V-Modell vorgestellt, das<br />
sowohl bei Behörden als auch in der Industrie eingesetzt wird. Ein anderes<br />
schwergewichtiges Modell ist der RUP (Rational Unified Process). Der RUP (s.<br />
Abschnitt 4.6) beschreibt ein Vorgehensmodell auf Basis von sog. "Best Practices",<br />
die erwiesenermaßen bei erfolgreichen Projekten zum Einsatz kommen. Diese<br />
umfassen im Einzelnen die iterative Entwicklung von Software, das Management<br />
von Anforderungen, die Nutzung komponentenbasierter Architekturen, die visuelle<br />
Modellierung der Software, die Verifikation der Software-Qualität und der<br />
Etablierung eines Änderungsmanagements.<br />
Im Abschnitt 4.7 wird ein agiles (leichtgewichtiges) Vorgehensmodell beschrieben,<br />
das die Programmentwicklung bzw. das Codieren in den Kern der Betrachtungen<br />
rückt. Dieses Modell wird XP (eXtreme Programming) genannt und kann in<br />
kleinere Projekten eingesetzt werden.<br />
Ziel eines jeden Projektes sollte die Entwicklung eines qualitativ hochwertigen<br />
Softwareproduktes sein. Der letzte Abschnitt in diesem Kapitel ist daher dem<br />
Thema "prozessorientiertes Software-Qualitätsmanagement" gewidmet. Eine<br />
zentrale Erkenntnis ist hierbei, dass die Produktqualität von der Prozessqualität<br />
bestimmt wird. Seit den 80er Jahren werden an verschiedenen Stellen an der<br />
Entwicklung von Standardmodellen für gute Software-Entwicklungsprozesse<br />
107
108<br />
gearbeitet. Die wichtigsten Standards (ISO 9000-Standards, insbesondere ISO<br />
9000-3 für die Software –Entwicklung, ISO 12207, ISO 15504 (SPICE- Standard)<br />
und CMM/CMMI) werden im Abschnitt 4.8 ausführlich beschrieben.<br />
4.2 Das objektorientierte Projekt<br />
Die Leitung eines Projektes ist grundsätzlich eine schwierige Aufgabe. Dies<br />
resultiert letztlich auf der Kollision zwischen Wünschen, festgelegten Terminen<br />
und vorhandenem Budget. Die objektorientierte Softwareentwicklung kann<br />
zusätzliche Risiken hervorbringen und erfordert daher zusätzliche Anstrengungen<br />
im Bezug auf das Projektmanagement. Im Folgenden werden wesentliche Aspekte<br />
kurz benannt.<br />
Der Einstieg in die Objektorientierung ist eine große Umstellung in allen Belangen<br />
eines Projektes (z. B. in Bezug auf erforderliches Know-How, Projektorganisation<br />
und Steuerung). Oft fehlt es an erfahrenen Projektmitarbeitern, die bereits<br />
Probleme in früheren Projekten gelöst haben und so durch Ihr Know-How<br />
Fehlentwicklungen entgegensteuern können. Der Einsatz von objektorientierter<br />
Technologie ist alleine keine Gewähr dafür, dass eine Software den Ansprüchen<br />
des Kunden genügt. Es gibt durchaus Szenarien, in denen der Einsatz von<br />
Objekttechnologie eindeutig Nachteile mit sich bringt (z. B. Performance-Verlust<br />
bei Batch-Verarbeitung auf dem Mainframe oder bei Anwendungen im Bereich<br />
"Parallel Computing").<br />
Objektorientierte Entwicklung erfordert den Einsatz von modernen<br />
Programmiersprachen und Entwicklungswerkzeugen. Die Menge an neuen<br />
Verfahren/Methoden und Regeln verursachen in der Regel neue Risiken, die<br />
intensiver verfolgt werden müssen und ein ausgereiftes Risikomanagement<br />
erfordern. Zum Teil müssen auch vorhandene Werkzeuge und Verfahren, die seit<br />
vielen Jahren erfolgreich in einem Unternehmen eingesetzt werden, an die neuen<br />
Entwicklungsprozesse angepasst werden.<br />
Iterative und inkrementelle Entwicklung bei objektorientierten Projekten erfordert<br />
ein kompetentes Projektmanagement (z. B. Aufwandsschätzung, Ressourcen-<br />
Planung, Meilensteinplanung, "politische Aspekte"). Projektleiter stehen daher oft<br />
zwischen den Stühlen. Der Lenkungsausschuss fordert einsatzbereite Software mit<br />
eingeschränktem Budget in vorgegebener Zeit und die Projektmitglieder benötigen<br />
ein gutes Umfeld sowie eine ausgereifte Entwicklungsplattform, um die gesteckten<br />
Ziele zu erreichen. Objektorientierte Projekte sind oft teurer als vergleichsweise<br />
prozedural entwickelte Anwendungen. Dies liegt insbesondere an dem<br />
notwendigen Einsatz von vergleichsweise teuren Werkzeugen und Berater,<br />
benötigter Schulung für die Entwickler und Komplexität des neuen<br />
Programmiermodells (z. B. Abstraktion, Wiederverwendbarkeit, Kapselung,<br />
Vererbung). In der Objektorientierung gibt es viele Ansätze ein Problem zu lösen
und viele Ansätze eine Problemlösung zu formulieren. Dagegen gibt es je nach<br />
Anwendungsszenario noch nicht genügend publizierte Standardlösungen. Daher<br />
muß zusätzliche Zeit aufgewendet werden, um evtl. Eigenentwicklungen<br />
vorzunehmen oder eigene Tools für die Werkzeugintegration zu entwickeln.<br />
Der Erfolg von objektorientierten Projekten hängt im besonderen Maße auch von<br />
der Projektkultur ab (z. B. Offenheit, Kommunikationsformen, Führungsstil).<br />
Projektleiter, die kein offenes Ohr für Entwickler haben, verlieren schnell den<br />
Bezug zur Realität und den aktuellen Problemen. Vorgehensmodelle, die in den<br />
nachfolgenden Abschnitten beschrieben werden, geben Orientierungshilfe für alle<br />
Projektmitarbeiter aber auch viele Freiheitsgrade. Wie in traditionellen Projekten<br />
auch sind viele Einzelentscheidungen zu treffen. Patentrezepte gibt es nicht! Trotz<br />
der genannten Probleme stellt die objektorientierte Softwareentwicklung eine<br />
wichtige Säule bei heutigen Projekten dar und wird in den nächsten Jahren weiter<br />
an Bedeutung gewinnen.<br />
4.3 Wasserfallmodell, Evolutionäres Modell, Iteratives Modell<br />
Wasserfallmodell<br />
Im Wasserfallmodell wird Software von der ersten Idee zur Erstellung eines<br />
Softwaresystems bis zur Einführung und Wartung des Systems in sukzessiven<br />
Stufen entwickelt. In der Urform waren keine Rücksprünge möglich, man hat<br />
jedoch schnell bemerkt, dass diese strenge Vorgehensweise nicht durchgehalten<br />
werden kann. Bei der Entwicklung kann in einer Phase festgestellt werden, dass<br />
einige Vorgaben der vorhergehenden Phase gar nicht oder nicht im vertretbaren<br />
Zeit- und Kostenrahmen durchführbar sind. In diesem Fall müssen Rücksprünge in<br />
zeitlich früher liegende Phasen möglich sein. Als Beispiel sei hier ein<br />
Phasenmodell von Frick [Frick95] verwendet. Die Rechtecke stellen die Phase dar,<br />
die Pfeile den Informations- und Kontrollfluss zwischen den Phasen. Die Phasen<br />
werden sequentiell durchlaufen. Am Ende jeder Phase werden die Ergebnisse<br />
überprüft und an die Folgephase weitergegeben. Wird dort während der<br />
Erarbeitung der eigenen Phasenergebnisse, ein Fehler in den Vorgaben festgestellt,<br />
so werden die Vorgaben an die vorhergehende Phase zurückgeführt. Die nach oben<br />
gerichteten Pfeile der linken Seite beschreiben Rücksprünge während der<br />
Entwicklung, die Pfeile der rechten Seite kennzeichnen Rücksprünge, die während<br />
der Wartung (Fehlerkorrektur) notwendig werden können.<br />
Auf die Inhalte der einzelnen Phasen wurde schon in Kapitel 1 eingegangen. Auf<br />
eine nochmalige Beschreibung wird hier verzichtet.<br />
109
110<br />
Nachteile des Wasserfallmodells:<br />
1 Bei großen Systemen ist die Entwicklungszeit zu lang. d. h. nach Fertigstellung<br />
des Systems ist es schon veraltet.<br />
2 Es ist nicht sinnvoll alle Entwicklungsschritte streng sequentiell durchzuführen.<br />
(Z. B. kann es sinnvoll sein, ein Teil der Bedieneroberfläche schon bei der<br />
Definition des Systems zu Demonstrationszwecken oder spezielle technische<br />
Lösungen schon <strong>beim</strong> Entwurf des Systems zu realisieren.)<br />
3 Risikofaktoren werden u. U. zu wenig berücksichtigt, da immer der einmal<br />
festgelegte Entwicklungsablauf durchgeführt wird<br />
Analyse<br />
Änderungen<br />
während der<br />
Entwicklung<br />
Definition<br />
Entwurf<br />
Abbildung 4.3.1 Wasserfallmodell<br />
Implementierung<br />
und Test<br />
Abnahme<br />
Änderungen /<br />
Fehlerkorrektur<br />
während der<br />
Wartung<br />
Betrieb und<br />
Evaluation<br />
Trotzdem ist das Wasserfallmodell insbesondere für kleinere Projekte evtl. unter<br />
Einbeziehung von Prototyping-Ansätzen und einer nicht so strengen Sichtweise,<br />
was den streng sequentiellen Ablauf angeht, auch heute noch durchaus anwendbar.
Für große Systeme ist insbesondere der Nachteil der langen Entwicklungszeit so<br />
gravierend, dass besser eines der im Folgenden beschriebenen Prozessmodelle mit<br />
mehreren zyklischen Durchläufen ausgewählt werden sollte.<br />
Evolutionäres und inkrementelles Modell<br />
Ziel heutiger Softwareentwicklungen ist es, dem Auftraggeber möglichst jedes<br />
halbe Jahr ein lauffähiges Teilprodukt zur Verfügung zu stellen. Beim<br />
evolutionären und inkrementellen Modell erstellt man das gesamte System deshalb<br />
nicht wie <strong>beim</strong> Wasserfallmodell in einem Durchlauf, sondern in mehreren<br />
Durchläufen, wobei am Ende jedes Durchlaufs ein einsatzfähiger Teil des System<br />
fertig gestellt, in Betrieb genommen und evaluiert wird. Unter Einbeziehung der<br />
Ergebnisse der Evaluation wird dann der nächste Durchlauf gestartet.<br />
Das evolutionäre Modell<br />
Die Kernanforderungen oder Mussanforderungen des Auftraggebers definieren den<br />
Produktkern. Im ersten Durchlauf wird der gesamte Software-Entwickungszyklus<br />
für diesen Produktkern durchgeführt. Das entwickelte Kernsystem wird<br />
anschließend an den Auftraggeber ausgeliefert. Der Aufraggeber sammelt<br />
Erfahrungen mit dieser Nullversion. Diese Erfahrungen fließen dann in die<br />
verbesserte und erweiterte nächste Version ein, d. h. sowohl Pflegeaktivitäten<br />
bezüglich des schon fertiggestellten Teil des Systems als auch die für die nächste<br />
Version gewünschten Erweiterungen erfolgen im nächsten Zyklus.<br />
Vorteile des evolutionären Modells:<br />
• Benutzer stehen in kurzen Zeitabständen jeweils immer größere<br />
einsatzfähige Teile des Gesamtsystems zur Verfügung.<br />
111
1<br />
112<br />
Änderungen<br />
Analyse des<br />
Teilsystems<br />
Definition des<br />
Teilsystems<br />
Entwurf des<br />
Teilsystems<br />
Abbildung 4.3.2 Evolutionäres Modell<br />
Implementierung<br />
und Test des<br />
Teilsystems<br />
Abnahme des<br />
Teilsystems<br />
Betrieb und<br />
Evaluation des<br />
Teilsystems<br />
zum nächsten<br />
Zyklus<br />
1 Die mit einer Version gewonnenen Erfahrungen fließen sofort in die nächste<br />
Version ein (sowohl Verbesserungen / Anpassungen an den Stand der Technik /<br />
Veränderungen des Ablaufs bezüglich des schon bestehenden Teils als auch für<br />
die Konzeption der ergänzenden Teile).<br />
2 Geeignet, wenn der Auftraggeber seine Anforderungen noch nicht genau<br />
überblickt.<br />
Nachteile des evolutionären Modells:
Gefahr, dass der schon realisierte Teil des Systems völlig umgeschrieben<br />
werden muss, weil die in spätern Entwicklungszyklen gefundenen<br />
Anforderungen nicht mehr einfach Systemerweiterungen sondern<br />
Systemveränderungen verursachen.<br />
Inkrementelles Modell<br />
Der oben beschriebene Nachteil wird durch das inkrementelle Modell vermieden.<br />
In diesem Modell wird die Analyse und Definition für das Gesamtsystem erstellt.<br />
In der Phase Definition wird dabei auch die Planung der Zyklen durchgeführt. In<br />
den folgenden Phasen werden dann wie <strong>beim</strong> evolutionären Modell jeweils immer<br />
umfangreicher werdende Teilsysteme erstellt, allerdings müssen nur die Phasen<br />
Entwurf bis Betrieb und Evaluation durchlaufen werden, da die Analyse und die<br />
Definition des Gesamtsystems ja schon vor dem ersten Durchlauf durchgeführt<br />
wurden.<br />
Vorteile des Inkrementellen Modells:<br />
5. Die Vorteile des evolutionären Modells, dass dem Benutzer in kurzen<br />
Zeitabständen jeweils immer größere einsatzfähige Teile des Gesamtsystems<br />
zur Verfügung stehen und dass die mit einer Version gewonnenen Erfahrungen<br />
sofort in die nächste Version einfließen können, sind hier auch gegeben. Der<br />
Nachteil, dass <strong>beim</strong> Erstellen der Teilsysteme die Anforderungen an das<br />
Gesamtsystem nicht berücksichtigt werden konnten, da sie noch nicht<br />
aufgenommen waren, entfällt.<br />
Nachteil des Inkrementellen Modells:<br />
• Da die ersten beiden Phasen für das Gesamtsystem durchgeführt werden,<br />
dauert es länger bis die erste Version fertig gestellt werden kann.<br />
113
114<br />
Analyse des<br />
Gesamtsystems<br />
Änderungen<br />
Definition des<br />
Gesamtsystems<br />
inkl. Zyklenplanung<br />
Anpassungen auf<br />
Grund von Erfahrungen<br />
mit dem Teilsystem<br />
Entwurf des<br />
Teilsystems<br />
Implementierung<br />
und Test des<br />
Teilsystems<br />
Abnahme des<br />
Teilsystems<br />
zum nächsten<br />
Zyklus<br />
Betrieb und<br />
Evaluation des<br />
Teilsystems<br />
Abbildung 4.3.3 Inkrementelles Modell<br />
Um den oben aufgeführten Nachteil abzuschwächen, könnte man auch eine<br />
Mischform von evolutionären und inkrementellen Modell anwenden: Wir führen<br />
keine bis ins Detail gehende Analyse und Definition des Gesamtsystems durch,<br />
sondern eine so tief gehende Analyse und Definition, so dass mit großer<br />
Wahrscheinlichkeit ausgeschlossen werden kann, dass es bei der Realisierung von<br />
späteren Erweiterungen des Gesamtsystems dazu kommt, dass diese Erweiterungen<br />
nicht oder nur mit großen Aufwand ins bereits bestehende System integriert<br />
werden können (Grobkonzeption). Für das im ersten Durchlauf zu realisierende<br />
Teilsystem werden natürlich die Phasen Analyse und Definition vollständig<br />
durchgeführt.
4.4 Prototyping<br />
Wir haben festgestellt, dass es bei allen vorgestellten Vorgehensmodellen<br />
vorkommen kann, dass in irgendwelchen Phasen zu vorangehenden Phasen<br />
zurückgegangen werden muss, um dort gefällte Entscheidungen zu revidieren.<br />
Dieses Zurückgehen ist sehr zeit- und kostenaufwendig. Außerdem bedeutet ein<br />
Ändern in einem bestehenden System meistens ein Strukturverfall im System.<br />
Besonders aufwendig wird ein Zurückgehen in Vorphasen, wenn zum Zeitpunkt<br />
der Abnahme festgestellt wird, dass das System nicht das tut, was es eigentlich tun<br />
soll. In diesem Fall muss oft von der Phase Abnahme bis zur Analyse<br />
zurückgegangen werden. Grund eines solche "bösen Erwachens" sind oft Fehler<br />
oder Mehrdeutigkeiten in der Spezifikation, die vom zukünftigen Benutzer des<br />
Systems nicht erkannt wurden.<br />
Durch eine ausführliche durchgeführte Istanalyse, Schwachstellenanalyse etc.<br />
durch den späteren Realisierer des Systems kann oft der Umfang solcher Fehler<br />
verringert werden und Mehrdeutigkeiten richtig interpretiert werden.<br />
Eine weitere Methode ist das Erstellen von so genannten Explorativen Prototypen,<br />
mit Hilfe derer dem zukünftigen Benutzern des Systems die Bedienung und<br />
Funktionsweise des Systems exemplarisch vorgeführt werden kann.<br />
Ein zweiter Zeitpunkt, an dem ein die Wahrscheinlichkeit für ein Zurückgehen in<br />
frühere Phasen durch Anwendung des Prototyp-Konzeps verringert werden kann,<br />
ist die Phase der Implementierung. Wenn sich in dieser Phase herausstellt, dass<br />
einige der in der Phase Definition oder Entwurf vorgesehene Konzepte gar nicht<br />
oder nur mit großen Aufwand realisierbar sind, muss, falls überhaupt möglich, eine<br />
nachträgliche Korrektur der Konzepte durchgeführt werden.<br />
Dies ist oft nur mit recht großen Aufwand oder sogar (wie z. B. bei Toll Collect)<br />
im versprochenen Zeit- und Kostenrahmen gar nicht möglich. Durch einen so<br />
genannten Technischen Prototyp kann man viele Fragen der technischen<br />
Realisierbarkeit im Vorfeld ausprobieren<br />
Klassifikation von Prototypen<br />
Es gibt drei Kriterien, nach denen Prototypen klassifiziert werden können:<br />
• Was wird durch den Prototyp getestet?<br />
• Wie ist der Prototyp aufgebaut?<br />
• Inwieweit findet der Prototyp Anwendung bei der Implementierung des<br />
endgültigen Systems?<br />
115
116<br />
Was wird durch den Prototyp getestet?<br />
• Explorativer Prototyp<br />
dient als Kommunikationsgrundlage zwischen Endbenutzer und den<br />
Systementwicklern. Spätere Arbeitsweise wird durchgespielt Schwächen und<br />
Fehler der Spezifikation werden erkannt und vor der Weiterarbeit beseitigt.<br />
• Technischer Prototyp ( Experimenteller Prototyp. Labormodell)<br />
dient den Entwicklern intern als Bewertungsgegenstand, der Fragen der<br />
technischen Umsetzung und Realisierbarkeit klären soll. Beispiel für<br />
Zielsetzungen:<br />
• Überprüfung der Machbarkeit<br />
• Abschätzung des Aufwandes und damit des Zeitbedarfs und der Kosten<br />
der Realisierung<br />
• Vergleich von Alternativen<br />
• Performance-Tests<br />
• Fragen der Konfiguration (Anschluss von Druckern, Vernetzung, …)<br />
• Einsatz von Tools<br />
Wie ist der Prototyp aufgebaut?<br />
• Horizontaler Prototyp<br />
ist dadurch gekennzeichnet, dass nur eine Ebene des Systems implementiert ist.<br />
IM Normalfall ist die Schittstelle zum Benutzer (oder ein Teil davon)<br />
implementiert. Mit Hilfe solch eines Prototyps kann das Arbeiten mit dem<br />
System gezeigt werden. Da die tieferen Ebenen fehlen, liefert das System<br />
normalerweise falsche Werte.<br />
• Vertikaler Prototyp<br />
horizontaler Prototyp<br />
Schnittstelle<br />
Verarbeitunglogik<br />
Dateizugriffe
ist dadurch gekennzeichnet, dass er exemplarisch ausgewählte Teilfunktionen<br />
des zukünftigen Systems vollkommen realisiert.<br />
• Gesamtsystem mit Lücken<br />
ist dadurch gekennzeichnet, dass alle Teile des systems realisiert sind außer<br />
Plausibilitätsprüfungen, Abfangen von Ausnahme- und Fehlersituationen,<br />
komplexe Berechnungsroutinen etc.<br />
Inwieweit findet der Prototyp Anwendung bei der Implementierung des<br />
endgültigen Systems<br />
• Throw-away-Prototype (Quick-and-dirty-Prototype, Rapid-Specification-<br />
Prototype)<br />
findet keine Verwendung bei nachfolgender Implementierung dient einzig und<br />
allein zur Entwicklung korrekter, robuster Spezifikationen<br />
• Add-on-Prototype (Rapid-Cyclic-Prototype)<br />
wird Bei der Implementierung des Zielsystem mitverwendet Beim Rapid-Cyclic-<br />
Prototyping wird ausgehend von einem ersten Add-on-Prototype zum<br />
Zielsystem weiterentwickelt.<br />
4.5 Das V-Modell<br />
vertikaler Prototyp<br />
Das V-Modell ist hervorgegangen aus dem Wasserfallmodell, das man um die<br />
Aktivitäten Verifikation und Validation erweitert hat.<br />
Verifikation in der Bedeutung: Prüfen, ob das Produkt seiner Spezifikation<br />
entspricht. Umgangssprachlich: "Wird ein korrektes Produkt entwickelt?"<br />
117
118<br />
Validation in der Bedeutung: Prüfen, ob das Produkt für seinen Einsatzzweck<br />
geeignet ist. Umgangssprachlich: "Wird das richtige Produkt entwickelt?"<br />
Das V-Modell ist Bestandteil des Standardisierungskonzepts der Bundesbehörden.<br />
Dieses Konzept hat folgende Eigenschaften:<br />
• verbindlich für IT-Vorhaben in Bundesbehörden (wird jedoch auch in der<br />
Wirtschaft eingesetzt)<br />
• deckt die Softwareentwicklung, das Projektmanagement, die Qualitätssicherung<br />
und das Konfigurationsmanagement ab<br />
• beschreibt die Vorgehensweise (V-Modell), die anzuwendenden Methoden und<br />
die einzusetzendenWerkzeuge<br />
Das V-Modell ist in vier Submodelle gegliedert:<br />
• Softwareerstellung (SWE)<br />
• Qualitätssicherung (QS)<br />
• Konfigurationsmanagement(KM)<br />
• Projektmanagement (PM)<br />
4.5.1 Struktur des Standardisierungskonzeptes<br />
Die Notwendigkeit der Standardisierung in der IT-Systementwicklung ist heute<br />
unbestritten.<br />
Als Vorteile der Standardisierung werden hauptsächlich gesehen:<br />
• Bessere Planbarkeit von ITProjekten<br />
• Eindämmung der Entwicklungskosten über den Lebenszyklus<br />
• Verbesserung der Qualität<br />
• Verbesserung der Kommunikation zwischen Auftraggeber und Auftragnehmer.<br />
Der Standard besteht aus folgenden drei Ebenen:<br />
1. Vorgehensweise "Was ist zu tun?"<br />
Diese Ebene legt fest, welche Tätigkeiten im Verlauf der Systementwicklung<br />
durchzuführen sind, welche Ergebnisse dabei zu produzieren sind und welche<br />
Inhalte diese Ergebnisse haben müssen.<br />
2. Methoden "Wie ist etwas zu tun?"
Hier erfolgt eine Bestimmung, mit welchen Methoden die auf der ersten Ebene<br />
festgelegten Tätigkeiten durchzuführen und welche Darstellungsmittel in den<br />
Ergebnissen zu verwenden sind.<br />
3. Werkzeuganforderungen "Womit ist etwas zu tun?" Auf dieser Ebene ist fixiert,<br />
welche funktionalen Eigenschaften die Werkzeuge (Tools) aufweisen müssen,<br />
die bei der Systementwicklung eingesetzt werden sollen.<br />
Auf allen Ebenen werden die Regelungen nach den Tätigkeitsbereichen, den<br />
sogenannten Submodellen gegliedert:<br />
119
120<br />
4.5.2 Eigenschaften des V-Modells<br />
Das V-Modell<br />
• beschreibt Aktivitäten und Produkte<br />
• regelt die Gesamtheit der Aktivitäten und Produkte sowie die<br />
Produktzustände und die Abhängigkeiten zwischen Aktivitäten und<br />
Produkten<br />
Wichtig: das V-Modell beschreibt den Softwareentwicklungsprozeß nur aus<br />
funktionaler Sicht, d.h. es werden keine Aussagen über die konkrete organisatorische<br />
Umsetzung getroffen.<br />
Die Aufteilung von Aufgaben auf Bearbeiter bzw. Organisationseinheiten wird vor<br />
Projektdurchführung festgelegt.<br />
4.5.3 Produktzustände und Übergänge<br />
4.5.4 Erzeugnisstruktur<br />
Das Gesamtsystem (inklusive HW und SW) wird in unterschiedliche Bestandteile<br />
aufgelöst:<br />
• Subsysteme<br />
• Segmente (mit DV-Anteil/ohne DV-Anteil)<br />
• Konfigurationseinheiten (SW, HW und ohne DV-Anteil)<br />
• KomponentenModule/Datenbanken
4.5.5 Struktur und Inhalt des V-Modells<br />
Das V-Modell besteht aus folgenden Elementen:<br />
• Aktivitäten<br />
• Produkte<br />
• Beschreibungsmuster<br />
• Submodelle<br />
4.5.6 Aktivitäten und Produkte<br />
Aktivitäten: Tätigkeiten, die hinsichtlich ihres Ergebnisses und ihrer<br />
Durchführung genau beschrieben werden können. Sie sind durch Teilaktivitäten<br />
verfeinerbar, die Zwischenergebnisse erzeugen. Aktivitäten der obersten Ebene<br />
werden Hauptaktivitäten genannt.<br />
Produkte: Bearbeitungsgegenstand oder Ergebnis einer Aktivität, kann wiederum<br />
auch in Teilprodukte zerlegt werden. Produkte können die Zustände geplant, in<br />
Bearbeitung, vorgelegt und akzeptiert annehmen.<br />
Notation:<br />
121
122<br />
4.5.7 Aktivitätenzerlegung<br />
Die Aktivitätenzerlegung wird bei der Verfeinerung von Aktivitäten angewendet..<br />
Sie beschreibt den Zusammenhang von Teilaktivitäten und -produkten in<br />
graphischer Form (hier die Aktivität SWE 6/Implementierung):
4.5.8 Produktfluss und Abwicklung<br />
Produktflüsse beschreiben die Eingangs- und Ausgangsprodukte für eine<br />
bestimmte Aktivität<br />
4.5.9 Die Submodelle<br />
Die Aktivitäten der Softwareentwicklung werden auf vier Submodelle verteilt:<br />
• Softwareerstellung (SWE)<br />
• Qualitätssicherung (QS)<br />
• Konfigurationsmanagement (KM)<br />
• Projektmanagement (PM)<br />
123
124<br />
4.5.10 Zusammenspiel der Submodelle<br />
4.5.11 Submodell "Softwareerstellung" (SWE)<br />
Der linke Arm des V enthält die Planungs- und Konstruktionsphasen, der rechte<br />
Arm die Integrations- und Kontrollphasen der Systementwicklung. Auf gleicher
Höhe befindet sich links die Phase, die die Test- und Planungs-Unterlagen für die<br />
Phase rechts liefern muss. Dieses "V" in der Darstellung des Softwareentwicklungsprozesses<br />
hat dem gesamten Vorgehensmodell den Namen gegeben. Es<br />
legt fest, dass die Testfälle für die Verifikation eines Software-Moduls bereits mit<br />
dem Feinentwurf und während der Implementierung zu erstellen sind. Die Testfälle<br />
und sonstigen Pläne für die Integration einzelner Softwaremodule müssen bei<br />
Grobentwurf und SW-Anforderungsanalyse geschaffen werden. Der Plan für die<br />
DV-Integration ist in der DV-Anforderungsanalyse festzulegen. Die Planungsunterlagen<br />
für die endgültige Systemintegration und ihr Test sind bereits<br />
während der Systemanforderungsanalyse zu schaffen.<br />
4.5.12 Systemanforderungsanalyse und -entwurf (SWE 1)<br />
Betrifft das Gesamtsystem und besteht aus folgenden Aktivitäten:<br />
Ist-Analyse: Datenbestände, DV-Ausrüstung, Zeit/Mengengerüst, Schwachstellen<br />
Bedrohungs- und Risikoanalyse: zu schützende Objekte, Eintrittwahrscheinlichkeiten<br />
Systemanforderungen definieren: Anforderungen an Funktionalitäten, Daten,<br />
Qualitätsmerkmale aus Anwendersicht<br />
System fachlich strukturieren: Funktions- und Datenstruktur aus Anwendersicht<br />
4.5.13 Systemanforderungsanalyse und -entwurf (SWE 1)<br />
System technisch entwerfen: Aufteilung in Subsysteme, Segmente oder<br />
Softwarekonfigurationseinheiten<br />
Machbarkeitsanalyse: Verwendung von Fertigprodukten, Wirtschaftlichkeit,<br />
Tolerierbarkeit von Restrisiko<br />
Systemanforderungen zuordnen: Zuordnung der Anforderungen zu den<br />
Systembestandteilen<br />
Systemintegration planen: Planen des Zusammenführens der Systembestandteile,<br />
Planen der Inbetriebnahme<br />
Wichtige Produkte in SWE 1 sind die Systemanforderungen, die<br />
Systemarchitektur und der Systemintegrationsplan<br />
4.5.14 DV-Anforderungsanalyse und -entwurf (SWE 2)<br />
Besteht aus folgenden Aktivitäten:<br />
125
126<br />
• DV-Ist-Analyse<br />
• DV-Anforderungen analysieren<br />
• Machbarkeitsanalyse<br />
• DV-Segment entwerfen<br />
• DV-Anforderungen zuordnen<br />
• DV-Integration planen<br />
4.5.15 DV-Anforderungsanalyse und -entwurf (SWE 2)<br />
Die Aktivitäten korrespondieren mit den Aktivitäten aus SWE 1, jedoch betreffen<br />
sie hier nur einzelne DV-Segmente.<br />
Wichtige Produkte sind die DV-Anforderungen, die DV-Architektur, der<br />
Schnittstellenentwurf und der DV-Integrationsplan<br />
4.5.16 SW-Anforderungsanalyse (SWE 3)<br />
Behandelt einzelne SWKE und besteht aus folgenden Aktivitäten:<br />
• Ist-Analyse<br />
• Allgemeine Anforderungen definieren<br />
• Anforderungen an externe Schnittstellen definieren<br />
• Anforderungen an Funktionen und Daten definieren<br />
• Qualitätsanforderungen definieren<br />
• Anforderungen an Entwicklungsumgebung und Zielrechner definieren<br />
• Als Produkt werden die SW-Anforderungen erstellt.<br />
4.5.17 Grobentwurf (SWE 4)<br />
Zerlegt die SWKE in einzelne Prozesse und definiert die Kommunikation und<br />
Synchronisation zwischen den Prozessen.Weiter werden die SWKE dann in<br />
Module aufgeteilt. Aktivitäten sind:<br />
• SW-Architektur entwerfen<br />
• Prozesse entwerfen
• SWKE-interne Schnittstellen entwerfen<br />
• SWKE-Integration definieren<br />
Als Ergebnis wird die SW-Architektur, der Schnittstellenentwurf und der SWKE-<br />
Integrationsplan erstellt.<br />
4.5.18 Feinentwurf (SWE 5)<br />
Entwurf der Realisierung der Module und Datenbanken:<br />
• Komponente/Modul/Datenbank beschreiben<br />
• Betriebsmittel- und Zeitbedarf analysieren<br />
Hieraus resultieren der Datenkatalog und der SW-Entwurf.<br />
4.5.19 Implementierung (SWE 6)<br />
Umsetzung der Module und Datenbanken:<br />
• Module codieren<br />
• Datenbanken realisieren<br />
• Informelle Prüfung<br />
• Debugging<br />
Produkte sind Module und Datenbanken.<br />
4.5.20 SW-Integration (SWE 7)<br />
Zusammenführung der Module und Datenbanken zu SWKE: Zu SWKE-<br />
Teilstruktur integrieren<br />
• Komponente informell prüfen<br />
• Zur SWKE integrieren<br />
• SWKE informell prüfen<br />
Ergebnis der SW-Integration sind die SWKE.<br />
4.5.21 DV-Integration (SWE 8)<br />
Zusammenführung von SWKE und HWKE zu DV-Segmenten:<br />
127
128<br />
• Zum DV-Segment integrieren<br />
• Tuning<br />
• Beitrag zur Einführungsunterstützung leisten<br />
• DV-Segment informell prüfen<br />
Die DV-Integration liefert vollintegrierte und teilintegrierte DV-Segmente<br />
4.5.22 Produkte im Submodell SWE<br />
Produkte, die bei der SWE erstellt werden:<br />
Systemprodukte: Systemanforderungen, Systemarchitektur<br />
DV-Produkte: DV-Anforderungen, DV-Architektur<br />
SW-Produkte: SW-Anforderungen, SW-Architektur, SW-Entwurf,<br />
Implementierungsdokumente<br />
Integrationsdokumente: Integrationsplan<br />
Handbuchinformation: Anwenderhandbuch, Diagnosehandbuch,<br />
Betriebshandbuch<br />
Begleitende Dokumente: Datenkatalog, Schnittstellenentwurf<br />
4.5.23 Submodell"Qualitätssicherung"<br />
4.5.24 Aktivitäten im Submodell QS
Folgende Aktivitäten werden im Submodell QS durchgeführt: QS-Initialisierung:<br />
legt den organisatorischen Rahmen im QS-Plan und in Prüfplänen fest<br />
Prozeßprüfung von Aktivitäten: Prüft die Einhaltung bestimmter<br />
Vorgehensweisen<br />
Produktprüfung vorbereiten: Erstellen von Prüfspezifikationen und -prozeduren,<br />
Erfolg und Mißerfolg einer Prüfung muß eindeutig und nachvollziehbar sein<br />
4.5.25 Aktivitäten im Submodell KM<br />
KM-Initialisierung: legt organisatorischen Rahmen für die Konfigurationsverwaltung<br />
sowie alle Einsatzmittel fest Konfigurationsverwaltung:<br />
Verwaltung von Produkten, Konfigurationen und Rechten, Festlegung einer<br />
zentralen Datenadministration Änderungsmanagement: Erfassung von<br />
Fehlermeldungen, Problemmeldungen, Verbesserungsvorschlägen etc.<br />
Datensicherung<br />
KM-Berichtswesen: Zur Vorbereitung von Durchführungsentscheidungen und zur<br />
Information des Projektmanagements<br />
4.5.26 Submodell "Projektmanagement" (PM)<br />
129
130<br />
4.5.27 Aktivitäten im Submodell PM<br />
Projekt initialisieren: regelt den organisatorischen Rahmen für das gesamte<br />
Projekt im Projektplan und Projekthandbuch. Legt Modalitäten für die<br />
projektinterne Zusammenarbeit und die Schnittstelle zum Auftraggeber fest.<br />
Anpassung des Vorgehensmodells (Tailoring).<br />
Projekt begleiten: Unterteil in die Phasen Initialisieren, Begleiten und<br />
Abschließen der einzelnen Aktivitäten im Projekt.<br />
Projekt abschließen: Aufbereitung der Ergebnisse, Soll-Ist-Vergleich<br />
4.5.28 Rollen im V-Modell<br />
Das V-Modell legt Rollen fest, die durch Erfahrungen, Kenntnisse und<br />
F¨ahigkeiten definiert sind. Diese Rollen werden dann im Projektablauf den<br />
Mitarbeitern zugewiesen:<br />
SWE-Rollen: Systemanalytiker, Systemdesigner, DV-Analytiker, DV-Designer,<br />
SW-Analytiker, SW-Designer, Programmierer, Supportberater,<br />
Applikationsberater, HW-Berater, Technischer Autor<br />
PM-Rollen: Projektmanager, Projektleiter, Projektassistent<br />
QS-Rollen: QS-Manager, QS-Verantwortlicher, Qualitätsprüfer, QS-Assistent<br />
KM-Rollen: KM-Leiter, Konfigurationsadministrator, Datenschutz- und<br />
Datensicherheitsbeauftragter<br />
Den einzelnen Rollen werden detailliert Aufgaben zugeordnet (ausführend,<br />
beratend, mitwirkend). Die Zuordnung von Rollen zu Mitarbeitern kann frei<br />
erfolgen mit zwei Ausnahmen:<br />
• Personen mit QS-Rollen dürfen nicht an der Erstellung der von ihnen<br />
zuprüfenden Produkte beteiligt sein (dies ist abhängig von der Kritikalität<br />
unterschiedlich streng zu handhaben)<br />
• Zu trennen ist auch die Rolle des Projektmanagers von QS- und SWE-Rollen<br />
Es ist somit eine Mindestanzahl von zwei bis drei Personen an einem Projekt<br />
beteiligt.<br />
4.5.29 Tailoring
Das V-Modell soll sowohl für kleine als auch sehr große Projekte geeignet sein.<br />
Demzufolge definiert es alle Aspekte, die in diesen Projekten auftreten können.<br />
Das Tailoring sieht vor, aus dem V-Modell durch Streichungen ein an das Projekt<br />
angepasstes Modell zu erstellen. Es sind jedoch auch schon Beispielmodelle<br />
(inklusive Dokumente) erhältlich.<br />
4.5.30 Zusammenfassung<br />
• Das V-Modell ist ein übergreifendes Modell zur Abwicklung von<br />
Softwareentwicklungsvorhaben<br />
• Es muß vor dem Einsatz angepaßt werden<br />
• Wegen der hohen Zahl und Komplexität von zu erstellenden Produkten ist eine<br />
Werkzeugunterstützung fast zwingend<br />
• Es verlangt erhöhte Kooperation zwischen Auftraggeber und Auftragnehmer;<br />
kann dabei aber Kommunikationsprobleme verringern<br />
131
132<br />
4.6 RUP<br />
Der Rational Unified Process (RUP) ist ein Vorgehensmodell (Software<br />
Engineering Process), das von der Firma Rational Software entwickelt wurde.<br />
Dieses stellt ein umfangreiches Rahmenwerk zur Entwicklung von qualitativ<br />
hochwertiger Software bereit. Der Anwendungsbereich des RUP ist sehr weit<br />
gefasst und soll unterschiedlichste Projekttypen in Bezug auf Projektgröße,<br />
Anwendungsgebiet und Plattform unterstützen.<br />
Der RUP beschreibt ein Vorgehensmodell auf Basis von sog. "Best Practices", die<br />
erwiesenermaßen bei erfolgreichen Projekten zum Einsatz kommen. Diese<br />
umfassen im Einzelnen die iterative Entwicklung von Software, das Management<br />
von Anforderungen, die Nutzung komponentenbasierter Architekturen, die visuelle<br />
Modellierung der Software, die Verifikation der Software-Qualität und der<br />
Etablierung eines Änderungsmanagements.<br />
Um die gesteckten Ziele zu erreichen, definiert der RUP diverse Workflows (bzw.<br />
Disziplinen), Rollen und Artefakte. Ein Workflow (Disziplin) beschreibt eine<br />
Sequenz von Aktivitäten, die die Verbindung zwischen Rollen, Aktivitäten und<br />
Artefakte herstellt. Die Artefakte können Dokumente, Codestücke, Modelle oder<br />
Berichte sein und stellen das Ziel einer Aktivität dar. Die einzelnen Aktivitäten<br />
werden dabei von den Inhabern der zugeordneten Rolle ausgeführt und unterteilen<br />
sich in einzelne Schritte.<br />
Zusammengefasst ergeben die Aktivitäten folgende neun Disziplinen:<br />
Geschäftsprozessmodellierung (Business Modelling), Anforderungsanalyse<br />
(Requirements), Analyse und Design, Implementierung, Test, Softwareverteilung<br />
(Deployment), Konfigurations- und Änderungs-Management, Projektmanagement<br />
sowie IT-Infrastruktur (Environment). Diese werden in die sog. Core Process<br />
Workflows und Core Supporting Workflows unterteilt (siehe Abbildung 4-2).<br />
Dieser Teil des RUP bildet den statische Teil.<br />
Darüber hinaus wird der dynamische Teil des RUP durch Phasen, Iterationen,<br />
Zyklen und Meilensteinen dargestellt. Die vier Phasen des RUP lauten Inception,<br />
Elaboration, Construction und Transition. Jede Phase wird <strong>beim</strong> RUP in mehreren<br />
Iterationen abgehandelt. In jedem Zyklus wird eine neue Produktversion erstellt,<br />
die bestimmte Anwenderanforderungen erfüllt. Meilensteine stellen bestimmte<br />
Zeitpunkte dar, an denen wichtige Entscheidungen abhängig vom erreichten<br />
Entwicklungsstand getroffen werden können. Die Disziplinen durchziehen jeweils<br />
mehrere Phasen, allerdings mit unterschiedlicher Intensität der assoziierten<br />
Aktivitäten. Dies wird durch die dargestellte Fläche pro Disziplin verdeutlicht.
Abb. 4-2: Der Rational Unified Process (RUP)<br />
4.6.1 RUP-Phase "Inception"<br />
Die Inception-Phase beschäftigt sich mit dem Aufsetzen eines Projekts und bildet<br />
den Einstiegspunkt zur Erstellung oder Änderung eines Systems. Ziel dieser Phase<br />
ist es, den Projektumfang festzulegen und einen sogenannten "Business Case " als<br />
Grundlage für das durchzuführende Projekt zu erstellen. Dies beinhaltet auch eine<br />
Risiko- sowie Zeit- und Kostenschätzung im Rahmen des Projektmanagements<br />
und beschreibt die Erfolgskriterien, die an das Produkt gestellt werden. Des<br />
Weiteren wird ein sog. "Vision"-Dokument erstellt, das die wesentlichen<br />
Rahmenbedingungen des Projektes sowie die Anforderungen und Hauptfunktionen<br />
des zu erstellenden Systems beschreibt.<br />
Ein weiterer Schwerpunkt dieser Phase bildet die Durchführung der<br />
Geschäftsprozessmodellierung. Hierfür sind neben den sog. Stakeholdern die<br />
Rollen Business-Process Analyst, Business Designer und Business Model<br />
Reviewer vorgesehen.<br />
Um ein gemeinsames Verständnis der Anwendungsdomäne zu erreichen, wird<br />
zunächst vom Business-Process Analyst ein gemeinsamer Wortschatz in Form<br />
eines Glossars erarbeitet. Danach werden von diesem Analyst die an den<br />
Geschäftsprozessen beteiligten Personen sowie die Anwendungsfällen (Use Cases)<br />
identifiziert. Eine Detaillierung dieser UseCases erfolgt vom Business Designer.<br />
Die weitere Strukturierung des Anwendungsfall-Modells fällt der Rolle des<br />
Analysten zu. Dieses Anwendungsfall-Modell wird nun vom Business Model<br />
Reviewer überprüft.<br />
133
134<br />
Neben der Geschäftsprozessmodellierung werden in der Inception-Phase die<br />
Hauptanforderungen als wichtige Grundlage für das zu erstellende System<br />
erarbeitet. Am Ende dieser Phase stehen so ein konzeptioneller Prototyp sowie ein<br />
erstes, noch unvollständiges Domainmodell für die weiteren Phasen bereit. Somit<br />
ist ein wichtiger Meilenstein (der "Lifecycle Objectives Milestone") erreicht.<br />
Sofern die Projektziele zu diesem Zeitpunkt gefährdet sind oder als nicht erreichbar<br />
eingeschätzt werden, kann ein Projekt hier beendet oder in veränderter Form neu<br />
aufgesetzt werden.<br />
4.6.2 RUP-Phase "Elaboration"<br />
Die Aufgabe der Elaboration-Phase ist die weitere Ausarbeitung des Projekts.<br />
Dabei werden die funktionellen und nicht funktionellen Anforderungen aus der<br />
vorherigen Phase im Rahmen des Software Development Plans (SDP) erarbeitet<br />
und einen Projekt- sowie einen Iterationsplan erstellt. In diesen Plänen werden die<br />
während des Projekts zu verwendenden Ressourcen und Werkzeuge festgelegt.<br />
Der Software Development Plan liefert eine Hilfe für die Durchführung folgender<br />
RUP-Komponenten: Projektorganisation, Requirements Management Plan,<br />
Configuration Management Plan, Problem Resolution Plan, Quality Assurance<br />
Plan, Test Plan, Test Cases, Evaluation Plan und Product Acceptance Plan.<br />
Des weiteren wird in der Elaboration-Phase eine detaillierte Analyse der Problembereichen<br />
durchgeführt und die Basisarchitektur des zu erstellenden Systems<br />
festgelegt ("mile wide and inch deep view of the system"). Zusätzlich erfolgt die<br />
Identifikation und Beschreibung der Hauptrisiken. Ziel ist es, die identifizierten<br />
Hauptrisiken durch entsprechende Maßnahmen möglichst früh zu eliminieren.<br />
Zur Erstellung der Anforderungsanalyse und des Designs sind folgende sieben<br />
Rollen definiert: der System Analyst, der Use Case Specifier, der User Interface<br />
Designer, der Architect, der Designer, der Datenbank Designer und der Capsule<br />
Designer, welcher für das objektorientierte Design zuständig ist. Wichtige<br />
Artefakte dieser Phase sind der Anforderungsplan, ein detailliertes Use Case<br />
Modell, ein User Interface Prototyp (falls notwendig), ein Softwarearchitekturplan,<br />
ein Datenmodell, Klassendiagramme, ein Designmodell sowie weitere notwendige<br />
Dokumente. Welche Artefakte in dieser Phase erstellt werden müssen, hängt<br />
selbstverständlich von dem Projekttyp ab. Hierzu bietet auch der RUP die<br />
Möglichkeit, sich an die Projektgegebenheiten anzupassen ("RUP Configuration").<br />
Zur Erstellung dieser Artefakte stehen diverse Werkzeuge zur Verfügung. Hierbei<br />
wird angestrebt, dass möglichst automatisch Artefakte der nächsten Stufe<br />
erzeugt werden können. Beispielsweise ist es möglich, aus einem<br />
Klassendiagramm die Klassen (Coderahmen) in der jeweiligen<br />
Programmiersprache zu erzeugen. Weitere Möglichkeiten stellen die Generierung<br />
der benötigten Tabellen aus einem Datenmodell dar. Am Ende dieser Phase stehen
eine überarbeitete Risikoabschätzung sowie die Basisarchitektur des<br />
umzusetzenden Systems. Damit sind die wichtigsten Rahmenbedingungen<br />
geschaffen, um das geforderte System in der nächsten Phase weiter zu entwickeln.<br />
Diese Phase des RUP stellt die kritischste Phase dar und die "harte Engineering-<br />
Phase" ist hiermit für das Projekt beendet ("Lifecycle Architecture Milestone").<br />
Konzeptuell gesehen, sollte ein Grad an Sicherheit in Bezug auf Architektur,<br />
Anforderungen etc. erreicht sein, damit die nachfolgende Phase als Fix-Preis-<br />
Projekt durchgeführt werden könnte. Auch hier gilt, dass ein Projekt beendet<br />
werden kann, wenn die Ziele dieser Phase nicht erreicht wurden.<br />
4.6.3 RUP-Phase "Construction"<br />
In der Construction-Phase findet der größte der Teil der Implementierung des<br />
Systems statt. Die einzelnen Klassen bzw. Software-Komponenten werden<br />
ausprogrammiert und notwendige Schnittstellen realisiert. Zusätzlich werden<br />
Testfälle erstellt und deren Durchführung geplant. Hiermit soll eine<br />
Qualitätssicherung bereits vor der Implementierung gewährleistet werden. Die<br />
Ergebnisse jeder einzelnen Iteration dieser Phase stellen Produkt-Releases dar, die<br />
dem Kunden zur Verifikation übergeben werden können. Die Disziplin<br />
Implementierung umfasst neben der Implementierungsplanung und der Erstellung<br />
der einzelnen Softwarekomponenten auch die Planung und Durchführung der<br />
Integration der jeweils betroffenen Software-Komponenten. Auch werden die<br />
Datenbanken mit den notwendigen Tabellen erstellt. Zur Durchführung der<br />
diversen Aktivitäten sind <strong>beim</strong> RUP vier Rollen vorgesehen. Diese sind der<br />
Architect, der System Integrator, der Code Reviewer sowie der Implementierer.<br />
Der RUP legt einen klaren Schwerpunkt auf das Testen der Software vor deren<br />
Auslieferung. Hierbei durchlaufen die einzelnen Tests die Phasen Planung, Design,<br />
Implementierung, Ausführung und Evaluierung. Eine entwickelte Komponente<br />
wird sowohl isoliert von anderen Komponenten getestet (Komponententest) als<br />
auch im Verbund mit anderen Komponenten (Verbund-/Integrationstest). Die Tests<br />
helfen, unerwünschte Seiteneffekte herauszufinden, die bei der Kommunikation<br />
einzelner Komponenten auftreten können. Erst bei erfolgreicher Absolvierung<br />
dieser Tests gilt eine Komponente als fertig gestellt. Die Durchführung der<br />
Testphasen wird durch die vier Rollen, Test Designer, Designer, Implementer und<br />
Tester abgedeckt.<br />
Diese Phase des RUP kann als Produktionsprozess bezeichnet werden, da der<br />
Fokus auf das Management der vorhandenen Ressourcen und die Steuerung der<br />
Aktivitäten liegt, um so die Kosten, den Zeitplan und die geforderte Qualität<br />
einzuhalten.<br />
135
136<br />
Die Construction-Phase liefert als Ergebnis ausführbare und qualitätsgesicherte<br />
Produkt-Versionen. Die Auslieferungsplanung legt fest, wann der Kunde welche<br />
Komponenten bzw. Produktversionen erhält bzw. wann diese in Produktion gehen<br />
sollen ("Wirk- oder Produktionsumgebung"). Schließlich wird in dieser Phase<br />
auch die System- und Benutzerdokumentation erstellt. Nach Abschluss dieser<br />
Phase ist der Meilenstein "Initial Operational Capability" erreicht. Oft entspricht<br />
das erstellte Produkt dem Status eines Beta-Release. Sofern ein stabiler<br />
Produktzustand erreicht ist, kann in die nächste Phase gegangen werden.<br />
4.6.4 RUP-Phase "Transition"<br />
In der Transition-Phase wird das erstellte System oder Teile davon (Subsystem)<br />
vollständig dem Kunden übergeben. Neben der Übergabe sieht der RUP auch eine<br />
Unterstützung bei der Inbetriebnahme und dem Umgang mit der Software vor.<br />
Hierbei auftretende Probleme werden umgehend gelöst.<br />
In der Disziplin Deployment wird zunächst ein Deployment Plan erstellt, der die<br />
Integration des Systems in die IT-Landschaft des Kunden beschreibt. Weitere<br />
Dokumente zum Umgang mit dem System werden erstellt. Zur Durchführung des<br />
Deployments sind folgende fünf Rollen definiert: der Implementer, der Technical<br />
Writer, der Deployment Manager, der Graphic Artist und der Course Developer.<br />
Die Inbetriebnahme des entwickelten Systems bedeutet, dass dieses in die IT-<br />
Landschaft des Kunden integriert werden muss. Hierzu müssen unter Umständen<br />
noch Implementierungsarbeiten und Tests durchgeführt werden, die in einer<br />
früheren Phase nicht durchgeführt wurden bzw. konnten. Das Software-Produkt<br />
durchläuft somit verschiedene Stati: von dem Beta-Release, über General<br />
Availability Release bis hin zu Bug-Fixes und Enhancement Releases. Für die<br />
verschiedenen Produktstände empfiehlt sich die Ausarbeitung, Durchführung und<br />
Auswertung der Akzeptanztests, um die Abnahme des jeweiligen Produkts zu<br />
erreichen.<br />
Am Ende der Transition Phase ist der Meilenstein "Product Release" erreicht. Der<br />
Abschluss der Aktivitäten der Transition-Phase stellt damit das Projektende dar.<br />
Nach der Übergabe des Produkts an den Kunden sollte von Seiten des<br />
Softwareunternehmens bzw. Softwareerstellers eine Nachbetrachtung hinsichtlich<br />
der eingehaltenen Planungen und der notwendigen Anpassungen erfolgen. Hiermit<br />
sollen Probleme oder Mängel in zukünftigen Projekten vermieden werden. Einige<br />
Beratungsfirmen pflegen daher umfangreiche Wissens- bzw. Projektdatenbanken,<br />
um die gemachten Erfahrungen und Erkenntnisse möglichst schnell in neue<br />
Projekte einfließen lassen zu können.
4.7 eXtreme Programming (XP)<br />
4.7.1 Warum XP?<br />
Im Jahr 1998 führten erste Veröffentlichungen von Kent Beck unter dem Titel<br />
eXtreme Programming (XP, Extremes Programmieren) zu bis heute anhaltenden<br />
Diskussionen. Die von ihm vorgeschlagenen Forderungen für ein Methode zur erfolgreichen<br />
Software-Entwicklung, die "das Programmieren zur Schlüsselaktivität<br />
während der gesamten Dauer eines Softwareprojektes [erklärt]" (Erich Gamma im<br />
Vorwort zu [Beck 03]), wurden und werden in ihrer "extremen" Art von manchem<br />
als provokativ empfundenen. Beck vergleicht den Software-Entwicklungsprozess<br />
mit dem Steuern eines Autos zum Erreichen eines vorgegebenen Ziels: die Lenkung<br />
des Autos erfordert eine kontinuierliche Justierung zur Zielrichtung in kleinsten<br />
Einheiten. Dieses Bild überträgt Beck auf die Forderung, den Software-Entwicklungsprozess<br />
in kleinste, iterative Schritte zu gliedern, die die Erreichung des<br />
Projekt-Ziels durch die permanente Anwendung geeigneter Regulierungspraktiken<br />
garantiert. Beck nennt vier Variablen, mit deren Hilfe man jedes Projekt kontrollieren<br />
kann: Kosten, Zeit, Qualität und Umfang – alle vier Variablen stehen in komplexen<br />
Abhängigkeiten zueinander. Der Umfang ist jedoch die wichtigste und am<br />
einfachsten zu steuernde der vier Kontrollvariablen, wenn die Softwareentwicklung<br />
in kleinsten Entwicklungseinheiten durchgeführt wird und dadurch die unmittelbare,<br />
d.h. zeitnahe Kontrolle der drei anderen Variablen ermöglicht. Die<br />
bislang angewandten Vorgehensmodelle enthielten diese Forderung nach kleinsten<br />
Iteartionsschritten mit allen zugehörigen Konsequenzen nicht in der von Beck<br />
geforderten, "extremen" Art. Beck betont die Wichtigkeit der Gesamtheit aller<br />
anzuwendenden Praktiken (vgl. 4.6.2). Werden einzelne Praktiken aus dem<br />
Gesamtkontext des XP gelöst, ist die eigentliche Idee des XP nicht mehr tatsächlich<br />
verwirklicht. "Calling the tail a leg doesn't make it one." [Jeff 04].<br />
Unter der Gesamtheit aller IT-Projekte können solche als besonders geeignet für<br />
die Anwendung des XP als Methode zur Entwicklung von Software bezeichnet<br />
werden, die risikobehaftet sind und mit einem hohen Grad an dynamischen Anforderungen<br />
von kleinen bis mittelgroßen Teams realisiert werden.<br />
XP wurde seit 1998 bis zur heute diskutierten Form von Kent Beck, Ward Cunningham,<br />
Martin Fowler und Ron Jeffries definiert und durch umfangreiche Erprobung<br />
in Projekten ständig weiterentwickelt.<br />
4.7.2 Die zwölf Praktiken<br />
Der Planungsprozess (Planning Process) (bzw. das Planungsspiel) hat zum Ziel,<br />
durch die Definition der Anforderungen (Requirements) eine gezielte Planung für<br />
137
138<br />
jede einzelne Iteration zu ermöglichen. Verfügbare Entwicklungsressourcen und<br />
Kundenwünsche werden dabei in Einklang gebracht. Die Aufgabe des Kunden besteht<br />
hierbei darin, seine User Stories zu definieren. Diese werden auf Karteikarten<br />
notiert und sind vergleichbar mit einer Beschreibung von Anwendungsfällen auf<br />
einer zunächst relativ generischen Ebene. Für jede Iteration werden die User<br />
Stories ggf. korrigiert und neu priorisiert, um die Hinführung des Gesamtprojekts<br />
zum Erfolg in kleinsten, validierbaren Schritten zu garantieren. Zum geeigneten<br />
Zeitpunkt werden die User Stories im Dialog der Entwickler mit dem Kunden verfeinert<br />
und ggf. neu verhandelt.<br />
Kleine Releases (Small Releases) sind das Ziel erfolgreich durchgeführter Iterationen<br />
auf der Basis des im Planungsprozess erzielten Release-Planes (Release<br />
Plan). Jedes dieser kleinen Releases erlaubt eine frühzeitige Produktionsübernahme<br />
der entsprechenden User Story und garantiert die permanente Erweiterung im Hinblick<br />
auf das Gesamtprojektziel in jeweils sehr kurzen Release-Zyklen. Ein Release-Zyklus<br />
umfasst 1-3 Monate. In dieser Phase werden mehrere Iterationen einer<br />
Dauer von 1-3 Wochen durchlaufen, die sich wiederum in Arbeitspakete einer<br />
Dauer von 1-3 Tagen gliedern.<br />
Die System-Metapher (System Metaphor) dient dazu, die Architektur bzw. einen<br />
Teil der Architektur zu beschreiben. Durch ein von allen Mitgliedern des XP<br />
Teams gemeinsam genutztes System von Bezeichern, Begriffen und Beschreibungen<br />
wird die Entwicklung und die Kommunikation unterstützt und gefördert.<br />
Einfacher Entwurf (Simple Design) bedeutet, dass zur Erreichung der aktuellen<br />
Anforderungen die minmalistischste Lösung bzgl. des Aufwandes herangezogen<br />
wird, "the simplest thing that could possibly work" [Beck 99]. Dies bedeutet u.a.<br />
auch, dass keine der zukünftigen Anforderungen bereits "mit implementiert" wird.<br />
Zur Erlangung eines guten Designs sollte insbesondere die Praxis des Refaktorisierung<br />
(s.u.) zum Einsatz kommen.<br />
Das Testen (Testing) begleitet jeden Iterationsschritt. Funktionale Akzeptanztests<br />
auf der Basis von Testfällen, die der Kunde – in Anlehnung an die jeweilige Story<br />
– definiert, werden von den Testern implementiert (Acceptance Tests). Sie sind<br />
jederzeit automatisch ausführbar und werden ergänzt von Kompontententests (Unit<br />
Tests), die von den Entwicklern zum Test ihrer Klassen vor der Implementierung<br />
der Klassen geschrieben werden (vgl. auch den Abschnitt JUnit in Kapitel 8). Diese<br />
beiden Teststrategien bilden den Kern der XP-Teststrategien und werden ergänzt<br />
durch Paralleltests und Belastungstests.<br />
Refaktorisierung (Refactoring) verbessert während des gesamten Entwicklungsprozesses<br />
das Design des Systems durch permanente Vereinfachung des Codes bei
gleichbleibender Semantik und wachsender Verständlichkeit. Ergänzende Dokumentationen<br />
werden mehr und mehr überflüssig gemäß dem Ziel, Code zu generieren,<br />
der durch klare Strukturen und geeignete Namensgebung letztlich selbsterklärend<br />
ist. Nach jeder Refaktorisierung muss durch Tests die unveränderte Semantik<br />
geprüft werden.<br />
Paarweise Programmierung (Pair Programming) führt nachweislich zu gleichen<br />
bzw. geringeren Kosten als bei Einzelprogrammierung – bei weniger fehlerhaftem<br />
Code und höherer Verständlichkeit des Codes. XP Entwickler arbeiten stets zu<br />
zweit an einem Rechner, wobei einer der Entwickler programmiert, während der<br />
andere logische und syntaktische Fehler beachtet sowie die Kompatibilität des<br />
Codes zum Entwurf und die Vollständigkeit der Testfälle prüft. Entwickler-Paare<br />
können sich für jedes Arbeitspaket neu bilden; hierdurch wird ein breites Know-<br />
How jedes Entwicklers bzgl. des Gesamtsystems gewährleistet und die "Unentbehrlichkeit"<br />
einzelner Entwickler ausgeschlossen.<br />
Kollektives Eigentum von Code (Collective Ownership) bedeutet, dass jeder<br />
Entwickler jeder Zeit Änderungen an jedem Code vornehmen kann. Auch hier gewährleistet<br />
der unmittelbar anschliessende Test die unveränderte Semantik der zu<br />
testenden Einheit. Das kollektive Eigentum von Code impliziert die gemeinsame<br />
Verantwortlichkeit.<br />
Fortlaufende Integration von Code (Continuous Integration) ermöglicht<br />
schnellen Projektfortschritt dadurch, dass durch täglich mehrmalige Integration<br />
neuer Komponenten in das bestehende System größere Integrationsprobleme vermieden<br />
werden und alle beteiligten Entwickler umittelbar Gewissheit bzgl. der Integrationsfähigkeit<br />
ihrer neu entwickelten Komponente haben. Das integrierte System<br />
stellt ein in kurzen Zyklen permanent erweitertes, stets lauffähiges System<br />
dar.<br />
Die 40-Stunden-Woche (40-hour Week) minimiert die Fehleranfälligkeit von<br />
Komponenten, die durch übermüdete, erschöpfte Entwickler implementiert werden.<br />
Die Erfahrung zeigt: "Tired programmers make more mistakes."<br />
Der Kunde vor Ort (On-site Customer) ist unerlässlich, da aufgrund der geringen<br />
Granularität von Anforderungen aus dem Planungsprozess permanent Rücksprachemöglichkeit<br />
mit einem Kundenvertreter im Projektteam zur Klärung von offenen<br />
Punkten gewährleistet sein muß. Der Kunde vor Ort ist auch verantwortlich<br />
für die Definition der Testfälle zu den Akzeptanz-Tests.<br />
Programmierstandards (Coding Standard) sind ebenso unerlässlich, da insbesondere<br />
die Praktiken Paarweise Programmierung, Kollektives Eigentum von<br />
139
140<br />
Code und Refaktorisierung mit dem Ziel, selbsterklärenden Code zu implementieren,<br />
ohne Programmierstandards nicht durchführbar sind.<br />
Abbildung 4.6-1 zeigt die Abhängigkeiten der zwölf Praktiken untereinander. Eine<br />
Verbindungslinie zwischen zwei Praktiken weist darauf hin, dass diese beiden<br />
Praktiken sich gegenseitig verstärken.<br />
Kunde vor Ort<br />
Metapher<br />
Refactoring<br />
Programmieren<br />
in Paaren<br />
Gemeinsame Verantwortlichkeit<br />
Programmier-<br />
standards<br />
40-Stunden-Woche<br />
Einfaches Design<br />
Testen<br />
Planungsspiel<br />
Kurze Releasezyklen<br />
Fortlaufende Integration<br />
Die Abhängigkeiten der zwölf Praktiken untereinander<br />
Abb. 4.6-1: Die Abhängigkeiten der zwölf Praktiken untereinander<br />
[Beck 03]<br />
4.7.3 Der XP Prozess<br />
Quelle: Beck, K.; Extreme Programming. Das Manifest; Addison Wesley 2003
In diesem Abschnitt werden in Abb. 4.6.-2 zur Visualisierung eines XP-Projektes<br />
diejenigen der zwölf o.g. Praktiken in ihren zyklischen Abläufen dargestellt, die<br />
unmittelbar einer Projektphase bzw. dem Ergebnis einer Projektphase als<br />
Voraussetzung für die folgende Projektphase entsprechen.<br />
User Stories<br />
Architectural<br />
Spike<br />
System<br />
Metaphor<br />
Uncertain<br />
Estimates<br />
Requirements<br />
Release<br />
Planning<br />
Spike<br />
Test Scenarios<br />
New User Story<br />
Project Velocity<br />
Release<br />
Plan<br />
Confident<br />
Estimates<br />
Arbeitspakete<br />
von 1-3 Tagen<br />
Release-Zyklus<br />
1-3 Monate<br />
Iteration<br />
Next Iteration<br />
Iterationen<br />
von 1-3 Wochen<br />
Abb. 4.6-2: Zyklen im XP-Projekt, in Anlehnung an [Wells 00]<br />
Acceptance<br />
Tests<br />
Small<br />
Releases<br />
Release-Zyklus (1-3 Monate)<br />
Auswahl einer priorisierten User Story als Basis für die Implementierung des<br />
nächsten kleinen Release.<br />
In die Release Planung fliesst die Systemmethapher mit ein, um Entwicklung und<br />
Kommunikation sowohl der Entwickler untereinander als auch mit dem Kunden<br />
und dem Management zu unterstützen und zu fördern.<br />
Iteration (1-3 Wochen)<br />
141
142<br />
In einzelnen Iterationen werden Komponenten implementiert und durch anschliessende<br />
Akzeptanz-Tests die Korrektheit und Vollständigkeit der Komponenten<br />
bzgl. der User Story und der zugehörigen Testfälle geprüft.
Arbeitspaket (1-3 Tage)<br />
Im Rahmen eines Arbeitspaketes erstellen bzw. verbessern Entwickler-<br />
Paare Komponenten (Refactoring), führen Tests durch und garantieren<br />
durch kontinuierliche Integration die Verfügbarkeit eines permanent sich<br />
weiterentwickelnden, lauffähigen Systems.<br />
Jede Iteration kann durch Korrekturen an den User Stories in Zusammenarbeit<br />
mit dem Kundenvertreter im Projektteam zu einer neuen, geänderten User<br />
Story führen. Dies erfordert eine erneute Releaseplanung, um mit dem überarbeiteten<br />
Releaseplan die nächste Iteration auf dem Weg zur Freigabe des aktuell<br />
projektierten kleinen Releases zu ermöglichen. Der Prozess der Releaseplanung<br />
ist dann abgeschlossen, wenn alle unsicheren Schätzungen (Uncertain Estimates)<br />
durch sichere Schätzungen (Confident Estimates) ersetzt worden sind.<br />
Der Release-Zyklus ist abgeschlossen, wenn das aktuell projektierte kleine Release<br />
in die Produktion übernommen wurde.<br />
4.7.4 Die Umsetzung<br />
Die Durchführung eines XP-Projektes erfordert eine enge, permanente Zusammenarbeit<br />
zwischen den Entwicklern, dem Management und dem Kunden, der insbesondere<br />
durch seinen Kundenvertreter im Projektteam fortwährend in das Projektgeschehen<br />
involviert ist. Der Kunde muss also die Bereitschaft besitzen, sich auf<br />
alle XP-Praktiken einzulassen. Die räumliche Umgebung soll die hohen Anforderung<br />
an die Kommunikation aller Beteiligten untereinander durch eine offene Arbeitsumgebung<br />
unterstützen; die Ausstattung der Arbeitsplätze berücksichtigt die<br />
Praxis der Paar-Programmierung. Ein Entwicklerteam sollte eine Größe von 10-15<br />
Entwicklern haben.<br />
Die Aufgabe des Managements besteht im Beobachten und Aufzeigen von Problemen,<br />
deren Lösungsmöglichkeiten vom Kunden und den Entwicklern gemeinsam<br />
erarbeitet wird. Durch die kurzen Iterationszyklen und die kontinuierliche Integration<br />
sollten Änderungskosten höchstens logarithmisch mit der Zeit steigen.<br />
Beck empfiehlt die schrittweise Einführung der einzelnen XP-Praktiken entsprechend<br />
ihrer aktuellen Dringlichkeit und unter Berücksichtigung ihrer Abhängigkeiten<br />
untereinander (vgl. Abb. 4.6.-1). Den vollständigen Wirkungsgrad erreicht<br />
man jedoch immer erst bei vollständigem Einsatz aller Praktiken. "Einzelne Elemente<br />
von XP können bedeutende Vorteile bringen. Ich glaube lediglich daran,<br />
dass man sehr viel mehr gewinnen kann, wann man alle Einzelteile zusammenfügt."<br />
[Beck 03]<br />
143
144<br />
4.7.5 Weiterführende Literatur<br />
Als weiterführende Literatur werden neben den referenzierten Büchern und URLs<br />
die folgenden "Standardwerke" und URLs empfohlen: eine Vertiefung zum Thema<br />
Extremes Programmieren planen findet man in [BeckFowl 00] bzw. in der<br />
deutschsprachige Version [BeckFowl 01], zum Schwerpunkt des Testens im<br />
Rahmen des Extremen Programmierens in [Beck 02] (vgl. hierzu auch die<br />
Literaturangaben aus Kapitel 8, Abschnitt JUnit), sowie zum Thema Refactoring in<br />
Fowler's gleichnamigem Buch in der Originalfassung [Fowl 99] und der deutschen<br />
Übersetzung [Fowl 00]. Wichtige URLs zum Thema Extreme Programming sind<br />
Ward Cunningham's Wiki Wiki Web [Cunn], Ron Jeffries‘ Seite Xprogramming<br />
[Jeff], sowie Don Wells‘ A gentle introduction zum Thema Extreme<br />
Programming [Wells 03], die durch eine Verfeinerung einer Grafik in der Art von<br />
Abb. 4.6-2 die unterschiedlichen Prozessebenen im Rahmen eines XP-Projektes<br />
sehr schön visualisiert.<br />
4.7.5.0.1 Literatur<br />
[Beck 99] Beck, K.; Extreme Programming Explained: Embrace Change;<br />
Reading/MA: AddisonWesley 1999<br />
[BeckFowl 00] Beck, K., Fowler, M.; Planning Extreme Programming; Addison<br />
Wesley 2000<br />
[BeckFowl 01] Beck, K., Fowler, M.; Extreme Programming planen; Addison<br />
Wesley 2001 (deutsche Übersetzung von [Beck 00])<br />
[Beck 02] Beck, K.; Test-Driven Development; Addison Wesley 2002<br />
[Beck 03] Beck, K.; Extreme Programming. Das Manifest; Addison Wesley<br />
2003 (deutsche Übersetzung von [Beck 99])<br />
[Fowl 99] Fowler M.; Refactoring; Addison Wesley 1999<br />
[Fowl 00] Fowler M.; Refactoring. Wie Sie das Design vorhandener<br />
Software verbessern; Addison Wesley 2000 (deutsche<br />
Übersetzung von [Fowl 99]<br />
URLs<br />
[Cunn] http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap<br />
[Jeff] www.xprogramming.com/<br />
[Jeff 04] http://c2.com/cgi/wiki?AreYouDoingXp<br />
[Wells 00] www.extremeprogramming.org/map/project.html<br />
[Wells 03] www.extremeprogramming.org<br />
4.8 Prozessorientiertes Software-Qualitätsmanagement
4.8.1 Überblick<br />
Qualität bei der Softwareentwicklung hat zwei Aspekte: Produkt- und<br />
Prozessqualität. In diesem Abschnitt geht es um die Prozessqualität, d.h. um die<br />
Qualität der Entwicklungsprozesse von Software. Warum ist die Qualität des<br />
Entwicklungsprozesses von Software wichtig? Reicht nicht die Qualität des<br />
Produktes aus, die z.B. mit guten Anforderungsdefinitionen und sorgfältigen Tests<br />
gewährleistet wird? Die Antwort darauf ist ganz einfach:<br />
Aus eigener Erfahrung werden Sie bereits Entwicklungsprojekte kennengelernt<br />
haben, in denen die nachvollziehbare Umsetzung von Anforderungen systematisch<br />
betrieben wurden. Daneben haben Sie sicherlich auch andere Entwicklungsprojekte<br />
erlebt, in denen einfach drauf los entwickelt wurde. Entsprechend unterschiedlich<br />
fällt in der Regel die Produktqualität aus.<br />
Zusammengefasst heißt dies also: Die Produktqualität bei der Software-<br />
Entwicklung hängt von der Qualität der Entwicklungsprozesse ab. Oder noch mehr<br />
zugespitzt: Die Produktqualität von Software wird von der Prozessqualität<br />
bestimmt. Dies ist die Ausgangshypothese der hier vorzustellenden<br />
prozessorientierten Qualitätsmanagementansätze. (Dies heißt übrigens nicht, dass<br />
produktbezogene Qualitätssicherung wie z.B. Testen jetzt überflüssig wäre!) Die<br />
gute Botschaft daran ist, dass die Produktqualität durch die Einführung guter<br />
Entwicklungsprozesse gesteuert werden kann. Doch was sind nun gute<br />
Entwiclungsprozesse?<br />
Bereits seit Anfang der 80er Jahre haben verschiedene Organisationen damit<br />
begonnen, auf der Basis einer Vielzahl echter Projekterfahrungen wichtige<br />
Elemente für erfolgreiche Software-Entwicklungsprozesse zu identifizieren.<br />
Beispiele hierfür sind:<br />
• Arbeiten mit Projektplänen<br />
• Systematische Erfassung und Umsetzung der Kundenanforderungen<br />
• Arbeiten mit Konfigurationsmanagementsystemen<br />
Die in den 80er Jahren an verschiedenen Stellen begonnenen Arbeiten zur<br />
systematischen Beschreibung, was ‚gute Software-Entwicklungsprozesse sind, hat<br />
inzwischen zu einigen wichtigen Standardmodellen geführt:<br />
• ISO 9000-Standards, insbes. ISO 9000-3 für die Software-Entwicklung<br />
• ISO 12207<br />
• ISO 15504, der sogenannte SPICE-Standard<br />
(SPICE: Software Process Improvement and Capability dEtermination)<br />
• CMM / CMMI des Software Engineering Institutes der Carnegie Mellon<br />
University (CMMI: Capability Maturity Model Integration)<br />
Die zunehmende Relevanz und Aktualität prozessorientierten Qualitätsmanagements<br />
für die Software-Industrie wird beispielsweise daran deutlich,<br />
145
146<br />
dass sich die führenden deutschen Automobilhersteller (Daimler-Chrysler,<br />
Volkswagen, Audi, BMW und Porsche) 2003 zu einer Hersteller-Arbeitsgruppe<br />
zusammengeschlossen haben mit dem Ziel, auf Basis des SPICE-Standards einen<br />
an die Automobil-Industrie angepassten Prozesstandard zu definieren, der sowohl<br />
von ihnen selbst wie von allen Zulieferfirmen für ihre Autos bei der Software-<br />
Entwicklung einzuhalten ist. Die Initiative hat unter der Bezeichnung ‚Hersteller-<br />
Initiative Software die bisherigen Ergebnisse im Internet unter der Adresse<br />
http://www.automotive-his.de/ bereitgestellt.<br />
Charakteristisch für SPICE und CMMI ist, dass zwei Dimensionen bei der<br />
Betrachtung der Entwicklungsprozesse unterschieden werden: die Prozessdimension<br />
und die Fähigkeitsdimension:<br />
• Die Prozessdimension enthält einen Katalog wichtiger Prozesse, die im<br />
Bereich der Software-Entwicklung eine Rolle spielen. Insgesamt werden von<br />
SPICE 5 Prozessgruppen mit insgesamt 40 Einzelprozessen definiert.<br />
• In der Fähigkeitsdimension wird für jeden Prozess bewertet, wie gut er<br />
umgesetzt wird. Die Güte der Umsetzung wird auch als Reife oder<br />
Capability-Level bezeichnet. Insgesamt werden von SPICE 6 Capability-<br />
Levels definiert mit insgesamt 9 Fähigkeitsbereichen, den sogenannten<br />
Process Attributes.<br />
Damit entsteht eine Matrix, bei der für jeden Einzelprozess eine individuelle<br />
Bewertung der erreichten Fähigkeitsstufe möglich ist. Dieser<br />
Gesamtzusammenhang ist in der folgenden Abbildung graphisch dargestellt:<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
Wichtig ist in diesem Zusammenhang, dass es durchaus möglich ist, dass eine<br />
Software-Entwicklungsorganisation bei einem Einzelprozess einen hohen<br />
Reifegrad haben kann und bei einem anderen Einzelprozess einen ganz niedrigen<br />
Reifegrad. Damit werden sehr differenzierte Fähigkeitsprofile für Software-<br />
Entwicklungsorganisationen möglich, wie im folgenden Beispiel dargestellt.
Beispielsweise ist es denkbar, dass eine Firma sowohl Prozesse zur<br />
Anforderungsanalyse definiert hat und spezielle Prozesse zum Software Entwurf<br />
einsetzt. Während beispielsweise der Software Entwurf bereits sehr gut etabliert ist,<br />
kann sie im Bereich Anforderungsanalyse noch ganz am Anfang stehen. Insgesamt<br />
lässt sich dadurch ein sehr individuelles Fähigkeitsprofil für die einzelne Firma<br />
erstellen und gezielte Verbesserungsmaßnahmen für einzelne Prozessbereiche<br />
ableiten, wie in der nachfolgenden Abbildung anschaulich dargestellt wird:<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
Am dargestellten Beispiel wird auch der Nutzen eines prozessorientierten<br />
Qualitätsmanagements für die Software-Entwicklung auf Basis von SPICE oder<br />
CMMI deutlich:<br />
Mithilfe der in SPICE formulierten Prozessgebiete und den darauf bezogenen<br />
Reifegradstufen ist es möglich, das Reifegradmodell einer ganzen Software-<br />
Entwicklungs-Organisation systematisch, differenziert und nachvollziehbar zu<br />
bewerten. Auf der Basis des Assessment-Ergebnisses kann die SW-<br />
Entwicklungsorganisation gezielte Verbesserungsprogramme in den Feldern<br />
anstoßen, wo sie den größten Nachholbedarf hat. Außerdem kann sie sich, wenn<br />
sie gewisse Levels erreicht hat, als Zulieferer für andere große Firmen oder z.B. für<br />
die öffentliche Hand qualifizieren.<br />
Normen wie SPICE oder CMMI liefern damit zusammenfassend:<br />
• ein inhaltliches Referenzmodell, welche Prozesse inhaltlich zu einem guten<br />
Software-Entwiclungsprozess gehören<br />
• bewährte und objektive Bewertungsmaßstäbe, um festzustellen, wie gut<br />
einzelne Prozesse durchgeführt werden<br />
• Hinweise für Ansatzpunkte, um gezielte Verbesserungen in den Software<br />
Entwicklungsprozessen zu erreichen.<br />
In den folgenden Abschnitten werden diese Aspekte im einzelnen vorgestellt. Da<br />
CMMI und SPICE inhaltlich zueinander konsistent sind und der gleichen<br />
Grundstruktur folgen, wird im folgenden das SPICE-Modell detaillierter betrachtet.<br />
Zunächst erfolgt eine detaillierte Darstellung des Prozessmodells von SPCIE (ISO<br />
147
148<br />
15504 / 12207). Danach werden das durch SPICE definierte Reifegradmodell und<br />
aufgrund seiner besonderen Bedeutung das Risikomanagement gemäß SPICE<br />
vorgestellt, bevor aufgezeigt wird, wie beide Aspekte zusammen (Prozess- und<br />
Reifegrad-Dimension) für sogenannte Assessments eingesetzt werden können.<br />
Zum Abschluß erfolgt ein kurze Einführung von CMM / CMMI und ein Vergleich<br />
der beiden Ansätze CMMI und SPICE.<br />
4.8.2 Das ISO 15504 / ISO 12207 (SPICE) Prozessmodell<br />
Die ISO 15504 beschreibt ein detailliertes Prozeßmodell für die Softwareentwicklung.<br />
Die Prozeßbeschreibung enthält für jeden Prozeß den Zweck des<br />
Prozesses, die Ergebnisse, die mit dem Prozeß erreicht werden, die<br />
Grundtätigkeiten, die auszuführen sind, um die Ziele zu erreichen, und eine<br />
Beschreibung der Eingangsinformationen und Arbeitsergebnisse (Workproducts)<br />
jedes Prozesses. Es werden insgesamt 40 Einzelprozesse in 5 Kategorien<br />
beschrieben.<br />
Die Prozesse werden in 3 Gruppen eingeteilt:<br />
• Primäre Lebenszyklus Prozesse (Primary life cycle processes) mit den<br />
Kategorien<br />
• Kunden - Lieferanten Prozesse<br />
• Engineering Prozesse<br />
• Unterstützende Lebenszyklus Prozesse (Supporting life cycle processes) mit<br />
der Kategorie<br />
• Support<br />
• und organisatorische Lebenszyklus Prozesse (Organization life cycle<br />
processes) mit den Kategorien<br />
• Managment<br />
• Organisation<br />
K u n d e n - L i e f e r a n t e n<br />
E n g i n e e r i n g<br />
M a n a g e m e n t<br />
O r g a n i s a t i o n<br />
S u p p o r t
Prozesse des Primären Lebenszyklus<br />
P r i m a r y l i f e c y c l e p r o c e s s e s<br />
C u s t o m e r - S u p p l i e r<br />
C U S . 1 A c q u i s i t i o n<br />
E n g i n e e r i n g<br />
A c q u i s i t i o n P r e p a r a t i o n<br />
S u p p l i e r S e l e c t i o n<br />
S u p p l i e r M o n i t o r i n g<br />
C u s t o m e r A c c e p t a n c e<br />
C U S . 3<br />
R e q u i r e m e n t s E l i c i t a t i o n<br />
E N G . 1 D e v e l o p m e n t<br />
S y s t e m r e q u i r e m e n t s<br />
a n a l y s i s a n d d e s i g n<br />
S o f t w a r e r e q u i r e m e n t s<br />
a n a l y s i s<br />
S o f t w a r e d e s i g n<br />
S o f t w a r e c o n s t r u c t i o n<br />
C U S . 2 S u p p l y<br />
C U S . 4 O p e r a t i o n<br />
O p e r a t i o n a l U s e<br />
C u s t o m e r S u p p o r t<br />
S o f t w a r e i n t e g r a t i o n<br />
S o f t w a r e t e s t i n g<br />
S y s t e m i n t e g r a t i o n a n d t e s t i n g<br />
E N G . 2 S y s t e m a n d s o f t w a r e m a i n t e n a n c e<br />
4.8.2.1 Die Kunden Lieferanten Kategorie (CUS)<br />
CUS.1 Acquisition Process<br />
Der Zweck des Aquisitionsprozesses ist es Produkte oder Dienstleistungen zu<br />
kaufen, die den Bedarf des Kunden erfüllen. Er beginnt mit der Identifikation der<br />
Anforderungen und endet mit der Akzeptanz des Produktes oder der Leistung die<br />
der Kunde benötigt. Der Prozeß besitzt 4 weitere Unterprozesse<br />
CUS.1.1 Acquisition Preparation Process<br />
149
150<br />
Der Zweck des Akquisitions Vorbereitungs Prozesses ist es den Bedarf und die<br />
Ziele der Akquisition zu ermitteln, die Anforderungen aufzuschreiben, eine<br />
Einkaufsstrategie zu entwickeln und Akzeptanzkriterien zu definieren<br />
CUS.1.2 Supplier Selection Process<br />
Ziel des Lieferantenauswahlprozesses ist es eine Organisation zu finden, die für die<br />
Implementierung des gewünschten Produkts verantwortlich ist. Aufgabe ist es eine<br />
Ausschreibung zu erzeugen, den Lieferanten auf Grund seines Angebots und seiner<br />
Fähigkeiten auszuwählen und einen Vertrag zwischen Kunden und Lieferanten zu<br />
etablieren<br />
CUS.1.3 Supplier Monitoring Process<br />
Der Zweck des Monitoring Prozesses ist es die Aktivitäten des Lieferanten und den<br />
technischen Fortschritt während der Entwicklung durch gemeinsame Aktivitäten<br />
und die Kontrolle von regelmäßigen Informationen zu überwachen.<br />
CUS.1.4 Customer Acceptance Process<br />
Der Zweck des Akzeptanz Prozesses ist es zu überprüfen, ob das gelieferte Produkt<br />
oder die gelieferte Leistung allen definierten Kriterien und den gestellten<br />
Anforderungen entspricht<br />
CUS.2 Supply Process<br />
Der Zweck des Lieferprozesses ist es dem Kunden Software zur Verfügung zu<br />
stellen, die den vereinbarten Anforderungen genügt. Dazu gehört ein Angebot auf<br />
die Anfrage des Kunden, der Abschluß eines Vertrags zwischen Kunde und<br />
Lieferant über Entwicklung, Lieferung und Installation von Software, die<br />
Entwicklung einer Software, die den Anforderungen genügt, und die Lieferung<br />
und Installation der Software<br />
CUS.3 Requirements Elicitation Process<br />
Die Aufgabe des Requirements Elicitation Prozesses (Sammlung von<br />
Anforderungen) ist es über den Lebenszyklus eines Produkts oder einer<br />
Dienstleistung die sich entwickelnden Anforderungen der Kunden zu ermitteln und<br />
damit eine Basis für neue Software oder neue Produkte zu schaffen. Dazu wird eine<br />
regelmäßige Kommunikation mit dem Kunden etabliert, es werden die<br />
Anforderungen der Kunden definiert und ein Mechanismus zur regelmäßigen<br />
Beobachtung der Kundenbedürfnisse geschaffen. Fortschritte durch sich ändernde<br />
Technologien und Kundenbedürfnisse werden beobachtet und der Einfluß<br />
berücksichtigt.<br />
CUS.4 Operation Process
Der Zweck des Operations Prozesses ist es die Software in ihrer vorgesehenen<br />
Umgebung zu betreiben und den Kunden durch Support zu unterstützen. Der<br />
Prozess besitzt zwei Unterprozesse:<br />
CUS.4.1 Operational Use Process<br />
Der Zweck des Operational Use Prozesses ist es der korrekte und effiziente Betrieb<br />
der Software.. Dazu gehören die Identifikation und Überwachung von Risiken bei<br />
der Einführung der Software, der eigentliche Betrieb der Software in ihrer<br />
vorgesehenen Umgebung und die Überprüfung, dass die Software Kapazitäten den<br />
Bedürfnissen des Kunden genügen.<br />
CUS.4.2 Customer Support Process<br />
Die Aufgabe des Customer Suppport Prozesses ist es einen Service auf einem<br />
akzeptierten Level einzurichten und zu unterhalten. Dazu gehören die Erfassung<br />
und Beobachtung der Servicebedürfnisse des Kunden, die regelmäßige Evaluierung<br />
der Kundenzufriedenheit mit Service und Produkt, die Durchführung des Supports<br />
durch Unterstützung des Kunden bei operationalen Problemen<br />
4.8.2.2 Die Engineering Kategorie<br />
ENG.1 Development process<br />
Der Zweck des Enwicklungsprozesses ist es eine Menge von Anforderungen in ein<br />
funktionierendes Softwareprodukt oder ein softwarebasiertes System zu<br />
transformieren. Der Entwicklungsprozess besitzt insgesamt sieben Teilprozesse.<br />
Die Teilprozesse müssen dabei nicht sequentiell durchgeführt werden. Die ersten<br />
Grundtätigkeiten des Testprozesses und der Integrationsprozesse werden z.B.<br />
gleichzeitig mit dem Requirements Analyse Prozess durchgeführt. In einem<br />
Iterativen Vorgehensmodell oder in einem Spiralmodell werden die Prozesse zum<br />
Teil mehrfach durchlaufen.<br />
Der am häufigsten anzutreffende Entwicklungsprozeß<br />
151
152<br />
ENG.1.1 System requirements analysis and design process<br />
Die Aufgabe des System Requirements Analysis und Design Prozesses ist es die<br />
funktionalen und nicht funktionalen Anforderungen (Requirements) an das System<br />
zu erstellen, eine System Architektur zu beschreiben und eine Zuordnung von<br />
Anforderungen zu den Hauptelementen des Systems und zu den Releases des<br />
Systems zu treffen.<br />
ENG.1.2 Software requirements analysis process<br />
Die Aufgabe des Software Requirements Analysis Prozesses ist es die<br />
Anforderungen an die Softwarekomponenten zu erstellen. Dabei werden die<br />
Anforderungen Softwarekomponenten zugeordnet und die Interfaces zwischen den<br />
Komponenten beschrieben. Die Anforderungen werden analysiert, auf Korrektheit<br />
und Testbarkeit überprüft. Der Einfluß der Softwareanforderungen auf die<br />
Laufzeitumgebung wird verstanden. Eine Software Release Strategie wird<br />
entwickelt und ein Mechanismus zur Verfolgung der Anforderungen über den<br />
Entwicklungsprozeß wird etabliert.<br />
ENG.1.3 Software design process<br />
Die Aufgabe des Design Prozesses ist es ein Design für die Software zu<br />
entwickeln, das die Anforderungen erfüllt. Dabei ist ein architektonisches Design<br />
zu entwickeln, das die Haupt Software Komponenten beschreibt, es sind die<br />
internen und externen Schnittstellen jeder Softwarekomponente zu beschreiben und<br />
es ist ein detailliertes Design ist zu entwickeln, das Softwareeinheiten beschreibt,<br />
die implementiert und getestet werden können.<br />
Es ist die Konsistenz zwischen Anforderungen und Design nachzuweisen.<br />
ENG.1.4 Software construction process<br />
Die Aufgabe des Software Konstruktions Prozesses ist es ausführbare<br />
Softwareeinheiten zu produzieren, die dem Design und den Anforderungen<br />
entsprechen. Dazu sind Verifikationskriterien für die Software zu definieren, die<br />
Softwareeinheiten müssen erzeugt werden und es muss der Test gegen die<br />
Verifikationskriterien durchgeführt werden.<br />
ENG.1.5 Software integration process<br />
Die Aufgabe des Integrationsprozesses ist es die Softwareeinheiten zu größeren<br />
integrierten Einheiten zusammenzufügen. Dazu ist eine Integrationsstrategie zu<br />
entwicklen, die beschreibt in welcher Reihenfolge und zu welchen integrierten<br />
Einheiten die Software zusammengefügt wird, es sind Verificationskriterien für die<br />
integrierten Einheiten zu entwicklen, die integrierten Einheiten sind zu produzieren<br />
und gegen die Verifikationskriterien zu testen. Die Testergebnisse werden<br />
protokolliert. Es ist eine Regressionstest Strategie zu entwickeln, die angibt welche
Tests bei Fehler oder Änderungen an den Softwareeinheiten durchzuführen sind.<br />
Die Regressionstests sind bei Bedarf durchzuführen.<br />
ENG.1.6 Software testing process<br />
Der Software Test Prozeß testet die integrierte Software gegen die Akzeptanz-<br />
Kriterien der Software Anforderungen. Dazu werden Akzeptanz Kriterien<br />
entwickelt (zeitlich normalerweise parallel zum Software Requirements Analysis<br />
Prozess), die Tests werden gegen die Akzeptanz-Kriterien durchgeführt und die<br />
Ergebnisse protokolliert.<br />
ENG.1.7 System integration and testing process<br />
Der Zweck des System Integrationsprozesses ist es die Software mit anderen<br />
Komponenten (z.B. Hardware) zu integrieren um ein Gesamtsystem zu bekommen.<br />
Es sind eine Integrationsstrategie für das System und Akzeptanzkriterien zu<br />
entwickeln. Die Integration und die Tests sind durchzuführen durch Bildung von<br />
Systemaggregaten, bis das Gesamtsystem entstanden ist. Der Nachweis aller<br />
Anforderungen (funktionale, nicht-funtionale, operationale, Wartung) am<br />
Gesamtsystem ist durchzuführen und zu protokollieren. Eine<br />
Regressionsteststrategie für Änderungen an Systemkomponenten ist zu entwickeln<br />
und bei Bedarf durchzuführen.<br />
ENG.2 System and software maintenance process<br />
Die Aufgabe des System und Software Wartungsprozesses ist es die Änderungen,<br />
Weiterentwicklungen und den Ausfall von Komponenten auf Anforderung des<br />
Kunden zu managen. Die Ursache der Anforderungen können erkannte Probleme<br />
oder der Wunsch nach Verbesserung oder Anpassung sein. Das Ziel ist es das<br />
System oder die Software zu modifizieren oder zu entfernen bei gleichzeitigem<br />
Erhalt der Integrität der Kundenprozesse. Dazu ist eine Wartungsstrategie zu<br />
schaffen, die die Änderung, die Modifikation oder die Entfernung von<br />
Systemkomponenten berücksichtigt. Es sind die Rückwirkungen auf das<br />
bestehende System zu ermitteln. Es sind die Spezifikationen, Designs und<br />
Teststrategien zu erneuern. Die modifizierten Komponenten sind zu entwickeln<br />
und zu testen. Updates sind <strong>beim</strong> Kunden einzuspielen.<br />
Auf Anforderung sind Software und System in kontrollierter Form mit minimaler<br />
Störung des Kunden zu entfernen.<br />
4.8.2.3 Die unterstützenden Prozesse<br />
153
154<br />
S u p p o r t i n g l i f e c y c l e p r o c e s s e s<br />
S U P . 1 D o c u m e n t a t i o n P r o c e s s<br />
S U P . 2 C o n f i g u r a t i o n M a n a g e m e n t P r o c e s s<br />
S U P . 3 Q u a l i t y A s s u r a n c e P r o c e s s<br />
S U P . 4 V e r i f i c a t i o n P r o c e s s<br />
S U P . 5 V a l i d a t i o n P r o c e s s<br />
S U P . 6 J o i n t R e v i e w P r o c e s s<br />
S U P . 7 A u d i t P r o c e s s<br />
S U P . 8 P r o b l e m R e s o l u t i o n P r o c e s s<br />
Die unterstützenden Prozesse, sind Hilfsprozesse die im Rahmen der Durchführung<br />
anderer Prozesse an unterschiedlichen Stellen Unterstützung leisten.<br />
SUP.1 Documentation Process<br />
Die Aufgabe des Dokumentationsprozesses ist es Dokumente zu entwickeln und zu<br />
warten die Inhalte besitzen, die von anderen Prozessen oder Aktivitäten erzeugt<br />
werden. Dazu gehört die Entwicklung einer Strategie zur eindeutigen Identifikation<br />
von Dokumenten, die Benennung von Standards zur Erzeugung von Dokumenten,<br />
die eindeutige Identifikation von Dokumenten, die Definition des Inhalts und<br />
Zwecks von Dokumenten, die Sicherstellung, dass die Dokumente den<br />
angegebenen Standards entsprechen und die Sicherstellung der Wartung von<br />
Dokumenten.<br />
Der Dokumentationsprozeß ist ein Prozeß der die Prozessattribute auf<br />
Fähigkeitslevel 2 (ISO15504) unterstützt.<br />
SUP.2 Configuration Management Process<br />
Der Zweck des Konfigurationsmanagement Prozesses ist die Einführung und<br />
Erhaltung der Integrität von allen Arbeitsergebnissen eines Projekts. Dazu ist eine<br />
Konfigurationsmanagementstrategie zu entwickeln, alle Arbeitsergebnisse eines
Prozesses oder Projekts sind zu identifizieren, und zu versionieren, Modifikationen<br />
und Releases sind zu kontrollieren, der Status und die Änderungsanforderungen<br />
werden protokolliert, die Vollständigkeit und Konsistenz wird sichergestellt und<br />
die Speicherung und Auslieferung von Arbeitsergebnissen wird kontrolliert.<br />
SUP.3 Quality Assurance Process<br />
Zweck des Qualitätssicherung Prozesses ist es sicherzustellen, dass die<br />
Arbeitsergebnisse und Tätigkeiten eines Prozesses oder Projekts den<br />
Anforderungen genügen und den Plänen entsprechen. Dazu wird eine Strategie zur<br />
Leitung der Qualitätssicherungsaktivitäten und Aufgaben entwickelt, durchgeführt<br />
und gewartet. Es wird sichergestellt, dass die Qualitätssicherungs-Aktivitäten und<br />
Aufgaben nachvollziehbar sind. Es wird verifiziert, dass die Software-Produkte,<br />
Prozesse und Aktivitäten den anwendbaren Standards, Prozeduren und<br />
Anforderungen genügen.<br />
Der Qualitätssicherungsprozess muss unabhängig sein und es sollte keine direkte<br />
Abhängigkeit zu Personen existieren, die die Software entwickeln oder die<br />
Entwicklung steuern.<br />
Der Qualitätssicherungsprozeß benutzt zur Durchführung weitere Support Prozesse<br />
wir Verification, Validation, Joint Reviews, Audits und den Problem Lösungs<br />
Prozeß.<br />
Die Durchführung des Qualitätssicherungsprozesses ist notwendig für alle<br />
primären Prozesse um den Reifegrad 2 zu erhalten.<br />
SUP.4 Verification Process<br />
Der Zweck des Verifikationsprozesses ist es, zu gewährleisten, dass alle<br />
Arbeitsergebnisse oder Dienstleistungen eines Prozesses oder Projektes den<br />
Anforderungen genügen. Dazu wird eine Strategie entwickelt, es werden<br />
Verifikationskriterien für alle Produkte definiert und die Produkte gegen diese<br />
Kriterien geprüft. Die Ursachen der identifizierten Defekte werden gesucht und<br />
beseitigt. Die Ergebnisse werden protokolliert und dem Kunden zugänglich<br />
gemacht.<br />
Dieser Prozeß ist eng verbunden mit dem Integrations- und dem Testprozeß, aber<br />
auch alle anderen Prozesse die Arbeitsergebnisse erzeugen werden durch diesen<br />
Prozeß unterstützt. Auch Requirementsdokumente, Designs und Projektpläne sind<br />
Arbeitsergebnisse, für die Qualitätskriterien gelten.<br />
SUP.5 Validation Process<br />
Der Zweck des Validationsprozesses ist es sicherzustellen, dass ein Produkt oder<br />
die Arbeitsergebnisse die Anforderungen für die gewünschte Anwendung erfüllt.<br />
Im Gegensatz zum Verifikationsprozeß, der die Konformität mit den gestellten<br />
Anforderungen (Requirements) nachweisen soll, wird hier überprüft, ob das daraus<br />
entstandene Produkt auch die gewünschte Anwendungsaufgabe erfüllt. Dazu ist<br />
155
156<br />
eine Validationsstrategie zu entwicklen, die Aktivitäten sind durchzuführen und zu<br />
protokollieren. Die gefundenen Probleme werden gelöst.<br />
Dieser Prozeß ist eng gekoppelt mit der Ausführung des System Integrations- und<br />
Test Prozesses.<br />
SUP.6 Joint Review Process<br />
Der Zweck des Joint Review Prozesses ist es ein gemeinsames Verständinis mit<br />
dem Kunden über den Fortschritt der Entwicklungsprojekts zu gewinnen. Joint<br />
Reviews gibt es sowohl auf dem Management als auch auf dem technischen Level<br />
und sie werden über die gesamte Projektlaufzeit in regelmäßigen Abständen und an<br />
vordefinierten besonderen Meilensteinen durchgeführt. Dabei werden der Status<br />
und die Ergebnisse von Prozessen durch gemeinsame Reviews von Kunden,<br />
Entwicklern, Zulieferern und anderen interessierten Teilen begutachtet. Aus den<br />
Reviews werden Maßnahmen abgeleitet und diese werden bis zu ihrer Erfüllung<br />
verfolgt.<br />
Dieser Prozeß ist eine unterstützender Prozeß für das Projektmanagement Attribut<br />
von Prozessen auf Level 2 der Fähigkeitenskala<br />
SUP.7 Audit Process<br />
Der Auditprozeß gewährleistet die unabhängige Beurteilung von Produkten,<br />
Prozessen, Anfoderungen, Plänen und Verträgen. Die Audits werden an<br />
vordefinierten Meilensteinen durch eine geeignete, unabhängige Partei<br />
durchgeführt, die Probleme werden protokolliert und kommuniziert. Die Probleme<br />
werden durch die für die Beseitigung verantwortliche Partei gelöst.<br />
Mögliche Audits für den Softwareentwicklungsprozeß sind<br />
• Der Vertrag genügt den Anforderungen der Organisation<br />
4 Die Systemspezfikation genügt den Requirements<br />
5 Das Design genügt der Spezifikation<br />
6 Das Softwareprodukt entspricht dem Design<br />
7 Die Testabdeckung entspricht den Qualitätssicherungsanforderungen<br />
8 Die Qualität des Softwareprodukts entspricht den Standards der Organisation<br />
9 Die Dokumentation stimmt mit den Kundenanforderungen überein<br />
Mögliche Audits für die Managementaktivitäten<br />
1 Angebot im Vergleich zu Anforderungen<br />
2 Erreichte Fortschritte im Vergleich zu Projekt- und Zeitplan<br />
3 Risiko Kontrolle<br />
4 Einhaltung von angemessenen Standards<br />
Besonders wichtig ist die Unabhängigkeit und fachliche Qualifikation der<br />
Auditoren, die auch eine weitgehende finanzielle Unabhängigkeit voraussetzt. Eine<br />
Beauftragung des Auditors durch den Lieferanten (ISO9000) kann dies kaum<br />
gewährleisten.
SUP.8 Problem Resolution Process<br />
Die Aufgabe des Problem Lösungs Prozesses ist es, sicherzustellen, dass alle<br />
entdeckten Probleme analysiert und gelöst werden.<br />
• Grundaufgaben dieses Prozesses sind die Einrichtung eines Problem Report<br />
Systems,<br />
• die Priorisierung von Problemen,<br />
• die Definitionen von Aktionen zur Behebung von Problemen,<br />
• die Verfolgung der Aktionen,<br />
• die Verteilung der Lösungen nach Review und Freigabe und<br />
• die Analyse von Problem Trends.<br />
157
158<br />
Die Organisations-Prozesse<br />
O r g a n i z a t i o n a l l i f e c y c l e p r o c e s s e s<br />
M a n a g e m e n t<br />
M A N . 1 M a n a g e m e n t P r o c e s s<br />
M A N . 2 P r o j e c t M a n a g e m e n t P r o c e s s<br />
M A N . 3 Q u a l i t y M a n a g e m e n t<br />
M A N . 4 R i s k M a n a g e m e n t<br />
O r g a n i z a t i o n<br />
O R G . 1 O r g a n i z a t i o n a l a l i g n m e n t p r o c e s s<br />
O R G . 2 I m p r o v e m e n t p r o c e s s<br />
P r o c e s s e s t a b l i s h m e n t p r o c e s s<br />
P r o c e s s a s s e s s m e n t p r o c e s s<br />
P r o c e s s i m p r o v e m e n t p r o c e s s<br />
O R G . 3 H u m a n R e s o u r c e M a n a g e m e n t p r o c e s s<br />
O R G . 4 I n f r a s t r u c t u r e p r o c e s s<br />
O R G . 5 M e a s u r e m e n t P r o c e s s<br />
O R G . 6 R e u s e P r o c e s s<br />
4.8.2.4 Die Management Prozess Kategorie<br />
In der Managment Prozess Kategorie befinden sich Prozesse mit generischen<br />
Tätigkeiten, die von jedem anderen Prozess im Software Lebenszyklus benutzt<br />
werden können.
MAN.1 Management Process<br />
Die Aufgabe des Management Prozesses ist es den Start und die Durchführung<br />
jeglichen Prozesses oder Funktion zu initieren, zu überwachen und zu steuern, so<br />
dass sie ihre Ziele effektiv erreichen.<br />
• Dabei werden die Aktivitäten und Aufgaben, die Durchzuführen sind, um<br />
den Zweck des Prozesses zu erreichen, identifiziert,<br />
• es wird die Machbarkeit der Ziele mit den vorhandenen Ressourcen und<br />
Randbedingungen evaluiert,<br />
• die Ressourcen und Infrastrukturen werden zur Verfügung gestellt,<br />
• Aktivitäten und Aufgaben werden gestartet,<br />
• die Performance der Aktivitäten wird überwacht,<br />
• die Arbeitsprodukte werden überprüft und die Ergebnisse analysiert und<br />
evaluiert,<br />
• Aktionen zur Änderung der Performance bei Abweichungen werden<br />
durchgeführt<br />
• und die erfolgreiche Durchführung des Prozesses wird nachgewiesen.<br />
MAN.2 Project Management Process<br />
Der Projektmanagement Prozeß ist die spezielle Ausprägung von MAN.1 für<br />
Projekte.<br />
Die Aufgabe des Projekt Management Prozesses ist es alle Aufgaben, Aktivitäten<br />
und Ressourcen, die notwendig sind um ein Produkt oder eine Dienstleitung zu<br />
erhalten, zu identifizieren, einzurichten, zu koordinieren und zu überwachen.<br />
Dazu wird der Rahmen der Arbeit des Projektes definiert<br />
Die Machbarkeit des Ziels des Projekts mit vorhandenen Ressourcen und<br />
Randbedingungen evaluiert,<br />
Die Aufgaben und Ressourcen, die notwendig sind um die vollständige Arbeit zu<br />
erledigen werden in ihrer Größe geschätzt<br />
Die Schnittstellen zwischen dem Projekt und anderen Projekten oder<br />
organisatorischen Einheiten werden identifiziert und überwacht<br />
Pläne für die Ausführung des Projekts werden entwickelt und umgesetzt<br />
Der Fortschritt des Projekts wird beobachtet und berichtet<br />
Aktionen zur Korrektur von Abweichungen und zur Vermeidung der<br />
Wiederholung von Problemen werden durchgeführt, wenn die Projektziele nicht<br />
erreicht werden<br />
Der Projektmanagement Prozeß ist ein generischer Prozeß, der in anderen Prozeß<br />
wieder auftaucht. Die Grundaufgaben des jeweiligen Prozesses sind die zu<br />
planenden Aktivitäten im Projektmanagement. Eine Überprüfung dieses Prozesses<br />
bedeutet daher die Kontrolle ob jeder primäre Prozesse mindestens auf<br />
159
160<br />
Fähigkeitenlevel 2 sich befindet, dann befindet sich der Managementprozeß auf<br />
Level 1, d.h. er ist durchgeführt.<br />
Projektmanagement setzt daher die genaue Kenntnis der zu managenden<br />
Grundprozesse voraus, ihrer Grundtätigkeiten und ihrer Arbeitsprodukte. Der<br />
universelle Projektmanager, der nur Erfahrungen in Projektmanagement besitzt ist<br />
daher nicht möglich.<br />
MAN.3 Quality Management<br />
Die Aufgabe des Qualitätsmanagements ist es die Qualität der Produkte oder<br />
Dienstleistungen eines Projekts zu überwachen, so dass sie den Kunden zufrieden<br />
stellen. Dieser Prozeß geht über die Qualitätssicherung von SUP.3 hinaus. Er setzt<br />
die Messung der Qualität sowohl von Produkten als auch von Prozessen mit Hilfe<br />
von Metriken voraus, mit deren Hilfe eine Steuerung der Qualität möglich ist.<br />
MAN.4 Risk Management<br />
Die Aufgabe des Risikomanagement Prozesses ist es Projektrisiken kontinuierlich<br />
über den gesamten Lebenszyklus zu identifizieren und zu vermeiden. Dazu gehört<br />
die Identifikation, Analyse und Priorisierung von Risiken, die Planung und<br />
Durchführung von Maßnahmen zur Risikovermeidung, die Verfolgung von<br />
Risiken und die Durchführung von Korrektiven Aktionen wenn die<br />
Risikovermeidung nicht funtioniert.<br />
4.8.2.5 Die Organisations Prozeß Kategorie<br />
Die Organisationsprozesse sind Prozesse die einer Organisation helfen die<br />
Geschäftsziele als ganzes zu erreichen. Die Organisationsprozesse sind notwendig<br />
zur Erreichung der Reifegradstufen 3-5, d.h. sie unterstützen die Wiederholbarkeit<br />
von Projekten (ORG.2.1, ORG.3, ORG.4) die Steuerbarkeit von Prozessen durch<br />
Messungen (ORG.1, ORG.5) und die Optimierung von Organisation und<br />
Prozessen (ORG.2.3, ORG.1)<br />
ORG.1 Organizational alignment process<br />
Der Zweck des Organizational Alignment Prozesses ist es, daß alle Mitarbeiter<br />
einer Organisation eine gemeinsame Vision, Kultur und Verständnis der<br />
Geschäftsziele haben.<br />
ORG.2 Improvement process<br />
Das Ziel des Improvement Prozesses ist es einen Software Lifecycle Prozeß zu<br />
etablieren, zu überwachen, zu steuern und zu verbessern.<br />
• Dazu gehört die Einrichtung einer Standardmenge von Prozessen,
• die detaillierten Aufgaben und Arbeitsergebnisse der Prozesse sind<br />
beschrieben,<br />
• zusammen mit erwarteten Performance Charakteristiken,<br />
• es existiert eine Strategie zur Anpassung der Prozesse an die Projektgröße<br />
(Tailoring)<br />
• es existiert eine Beschreibung zur Benutzung der Prozesse<br />
ORG.2.1 Process establishment process<br />
Die Aufgabe des Process Establishment Prozesses ist die Einrichtung eines Satzes<br />
von Standardprozessen für den Software Lebenszyklus<br />
ORG.2.2 Process assessment process<br />
Der Prozess Assessment Prozeß untersucht die Standard Softwareentwicklungsprozesse<br />
mit Hilfe von Assessments und deckt Schwachstellen auf.<br />
Die relativen Stärken und Schwächen der Standardprozesse geben Informationen<br />
für einen kontinuierlichen Verbesserungsprozeß<br />
ORG.2.3 Process improvement process<br />
Der kontinuierliche verbesserungsprozeß hat die Aufgabe durch kontrollierte<br />
Änderung der Standards die Effektivität und Effizienz der Prozesse, die in einem<br />
Unternehmen genutzt werden, ständig zu erhöhen.<br />
ORG.3 Human Resource Management process<br />
Der Zweck des Human Resource Management Prozesses ist es der Organisation<br />
und den Projekten zu genügend ausgebildete Mitarbeiter zur Verfügung zu stellen,<br />
die Fähigkeiten und Wissen besitzen um ihre Rolle effektiv zu erfüllen und als<br />
Gruppe zusammenarbeiten zu können.<br />
Dazu gehört die Identifikation der benötigten Fähigkeiten und des benötigten<br />
Trainings und die Durchführung des Trainings.<br />
ORG.4 Infrastructure process<br />
Die Aufgabe des Infrastrukturprozesses ist es eine stabile und verlässliche<br />
Infrastruktur aus Hardware, Software, Tools, Standards, Methoden, Techniken und<br />
Gebäuden für Entwicklung, Betrieb und Wartung zur Verfügung zu stellen.<br />
ORG.5 Measurement Process<br />
Das Ziel des Mess-Prozesses ist es Daten, die Produkte und die Prozesse einer<br />
Organisation betreffend, zu sammeln und zu analysieren um das Management der<br />
Prozesse effektiv zu unterstützen und die Qualität der Produkte zu demonstrieren.<br />
161
162<br />
ORG.6 Reuse Process<br />
Die Aufgabe des Reuse Prozesses ist es die Wiederverwendung von existierenden<br />
und neuen Softwareprodukten zu fördern und zu unterstützen. Dazu gehört die<br />
Entwicklung einer Wiederverwendungsstrategie und die Einrichtung und Wartung<br />
einer Infrastruktur für Wiederverwendung<br />
4.8.2.6 Prozeß Tailoring<br />
Eine der wichtigsten Aufgaben zu Anfang eines jedes Projektes ist das<br />
Prozeßtailoring des Prozeßmodells. Die Komplexität von Softwareprojekten ist<br />
sehr unterschiedlich und kann vom kleinen Hilfsprogramm, das in einer Stunde<br />
entwickelt ist bis zum Großprojekt mit 100 Mannjahren Entwicklungsaufwand<br />
reichen. Die Aktivitäten müssen daher dem jeweiligen Projekt angepasst werden.<br />
Diesen Prozeß nennt man Prozeß-Tailoring (Tailor=Schneider).<br />
Grundsätzlich gilt die Regel: Je höher die Komplexität einer Aufgabe desto höher<br />
muß die Prozeßqualiät sein. Das Tailoring erfordert normalerweise sehr viel<br />
Erfahrung im entsprechenden Bereich. Viele Projekte scheitern, weil den<br />
Projektleitern eben diese Erfahrung fehlt und sie deshalb wichtige Tätigkeiten<br />
weglassen oder die Qualität von Arbeitsergebnissen nicht sicherstellen. Trotzdem<br />
ist zu beachten, dass auch der umgekehrte Fall vorkommen kann, dass ein Projekt<br />
scheitert, weil die Prozesse zu umfangreich sind. Dies Fall tritt aber nur sehr selten<br />
auf. Ausserdem gilt, dass gute Softwareentwicklungsprozesse eine Voraussetzung<br />
für den Erfolg sind, aber keine Garantie. Die Umkehrung gilt aber fast immer:<br />
Wenn die Entwicklungsprozesse in einem großen Projekt nicht ausreichend sind,<br />
wird das Projekt ein Mißerfolg!<br />
4.8.3 Das ISO 15504 / ISO 12207 Reifegradmodell<br />
Wie oben bereits kurz dargestellt, ist das ISO 15504-Schema zweidimensional<br />
strukturiert, nämlich in die Prozess- und in die Reifegrad-Dimension: In der<br />
Process Dimension werden die für einen guten Software-Entwicklungsprozess<br />
geforderten Einzelprozesse beschrieben (vgl. vorigen Abschnitt). In der Capability<br />
Dimension werden verschiedene Reifegradstufen bei der Ausführung dieser Einzelprozesse<br />
unterschieden, wie in der folgenden Abbildung dargestellt wird:
Zur Einstufung eines Einzelprozesses in eine bestimmte Reifegradstufe werden<br />
sogenannte Prozessattribute (process attributes) herangezogen. Prozessattribute<br />
sind objektiv beobacht- und messbare Qualitätseigenschaften bei der Durchführung<br />
von Software-Entwicklungsprozessen. Prozessattribute stellen für jeden<br />
betrachteten Einzelprozess einen Bewertungsmaßstab dar für die darin erreichte<br />
Reife. Insgesamt werden von SPICE 6 Reifegradstufen (Capability Levels) mit<br />
zusammen 9 Gruppen von Prozessattributen (Process Attributes) unterschieden:<br />
Reifegradstufen und Prozess-Attribute gemäß ISO 15504-2<br />
Process<br />
Capability Levels<br />
Attribute ID<br />
and Process Attributes<br />
Level 0 : Incomplete process<br />
Level 1 : Performed process<br />
PA 1.1 Process performance<br />
Level 2 : Managed process<br />
PA 2.1 Performance management<br />
PA 2.2 Work product management<br />
Level 3 : Established process<br />
PA 3.1 Process definition<br />
PA 3.2 Process resource<br />
Level 4 : Predictable process<br />
PA 4.1 Measurement<br />
PA 4.2 Process control<br />
Level 5 : Optimizing process<br />
PA 5.1 Process change<br />
PA 5.2 Continuous improvement<br />
Die einzelnen Reifegradstufen sind wiederum so abgestuft, dass der Fortschritt von<br />
einer zur nächsten Stufe jeweils eine signifikante Verbesserung in der<br />
Durchführung des betrachteten Einzelprozesses darstellt. Die Stufenabfolge<br />
insgesamt stellt daher einen schrittweisen Verbesserungsprozess gemäß ISO/IEC<br />
TR 15504-2 dar.:<br />
163
164<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
Capability Levels als Roadmap für einen Verbesserungsprozess<br />
Im folgenden werden die einzelnen Reifegradstufen mit den Prozessattributen<br />
vorgestellt. Danach wird am Beispiel des Prozessbereichs Projektmanagement<br />
illustriert, wie die Anforderungen an die Beherrschung des Projektmanagements<br />
von Capability-Level zu Capability-Level zunehmen. In analoger Weise werden<br />
für alle von SPICE geforderten Einzelprozesse stufenweise zunehmende<br />
Anforderungen an die Beherrschung der Einzelprozesse von Capability-Level zu<br />
Capability-Level definiert.<br />
4.8.3.1 Stufe 0 - Unvollständiger Prozess (Incomplete)<br />
Kurzbeschreibung:<br />
Es gibt nur wenige oder gar keine klar beschriebenen Ziele und Arbeitsergebnisse<br />
des Prozesses. Es ist deshalb nicht feststellbar, ob der Prozess überhaupt greifbare<br />
Ergebnisse bringt und es ist davon auszugehen, dass der Prozess nicht verstanden<br />
ist.<br />
Prozessattribute:<br />
Für die Stufe 0 gibt es keine speziellen Prozessattribute.<br />
Bei Prozessen der Stufe 0 ist unklar, wie das Ergebnis überhaupt zustande kam
4.8.3.2 Stufe 1 - Durchgeführter Prozess (Performed)<br />
Kurzbeschreibung:<br />
Der Gesamtprozess ist weitgehend verstanden. Die Zielsetzung und die Ergebnisse<br />
des Einzelprozesses wird in der Regel erreicht. Die Zielerreichung wird in der<br />
Regel jedoch nicht systematisch geplant und kontrolliert. Einzelpersonen innerhalb<br />
der Organisation erkennen, dass gewisse Aktionen durchgeführt werden müssen.<br />
Es ist allgemein akzeptiert, dass diese Aktion dann durchgeführt wird, wenn es<br />
notwendig ist. Die Einzelheiten des Prozesses zwischen Prozessbeginn und<br />
Prozessende sind nicht bekannt.<br />
Prozesse der Stufe 1 sind in ihren inneren Details eine ‚Black-Box<br />
Prozessattribute:<br />
Auf Stufe 1 werden folgende Prozessattribute gefordert:<br />
PA 1.1 - Process performance attribute:<br />
Das Prozessattribut PA 1.1 stellt fest, in welchem Ausmaß der Prozess mit klar<br />
definierten Inputs klar definierte Ergebnisse erzeugt. Im einzelnen sind von einem<br />
Einzelprozess zur Erreichung der Stufe 1 - Bereich PA 1.1 - folgende generischen<br />
Qualitätsmerkmale zu erfüllen:<br />
• MP 1.1.1: Identify input and output work products<br />
• MP 1.1.2: Ensure that the scope of work is identified<br />
• MP 1.1.3 Ensure that base practices are implemented.<br />
4.8.3.3 Stufe 2 - Gelenkter Prozess (Managed).<br />
Kurzbeschreibung:<br />
Auf der Stufe 2 werden zwei Prozessattribute unterschieden: Work product<br />
management und Performance management. Der Einzelprozess liefert definierte<br />
Arbeitsergebnisse gemäß klarer Vorgehensweisen und ist in seiner Durchführung<br />
geplant sowie kontrolliert. Die Arbeitsergebnisse erfüllen spezifizierte (Qualitäts)-<br />
Standards und Anforderungen. Der hauptsächliche Unterschied zur Stufe 1 ist<br />
neben der grundsätzlichen Transparenz des Gesamtprozesses, daß die Erstellung<br />
der Arbeitsergebnisse systematisch hinsichtlich Zeit, Qualität und Aufwand gelenkt<br />
165
166<br />
(managed), d.h. geplant und systematisch kontrolliert wird. ‚Außerdem sind<br />
Zuständigkeiten und Verantwortungen zugewiesen.<br />
Prozess der Stufe 2 folgen einer grob strukturierten systematischen<br />
Vorgehensweise<br />
Prozessattribute:<br />
Auf Stufe 2 werden zwei Gruppen von Prozessattributen gefordert, eine<br />
prozessbezogene (PA 2.1) und eine produktbezogene (PA2.2):<br />
PA 2.1 - Performance management attribute:<br />
Das Prozessattribut PA 2.1 stellt fest, in welchem Ausmaß der Prozess gelenkt<br />
wird, um Ergebnisse mit klar definierten Qualitätseigenschaften zu erzeugen. Im<br />
einzelnen sind von einem EinzelProzess zur Erreichung der Stufe 2 - Bereich PA<br />
2.1 - folgende generischen Qualitätsmerkmale zu erfüllen:<br />
3 MP 2.1.1: Identify the objectives for the performance of the process<br />
4 MP 2.1.2: Plan the performance of the process according to the identified<br />
objectives<br />
5 MP 2.1.3: Plan and assign the responsibility and authority for developing the<br />
work products<br />
6 MP 2.1.4: Manage the execution of the activities by continued tracking and<br />
replanning.<br />
PA 2.2 - Work product management attribute:<br />
Das Prozessattribut PA 2.2 stellt fest, in welchem Ausmaß der Prozess gelenkt<br />
wird, um sicherzustellen, dass die erzeugten Produkte die gestellten Anforderungen<br />
hinsichtlich Dokumentation, Kontrolle und Qualitätssicherung vollständig erfüllen.<br />
Lokale (projektbezogene) Standards sind dafür definiert. Außerdem werden die<br />
Arbeitsergebnisse systematisch verwaltet und verifiziert. Im einzelnen sind von<br />
einem Einzelprozess zur Erreichung der Stufe 2 - Bereich PA 2.2 - folgende<br />
generischen Qualitätsmerkmale zu erfüllen:<br />
MP 2.2.1: Identify the requirements for the work products (both functional and<br />
non-functional aspects).<br />
MP 2.2.2: Manage the documentation and configuration management<br />
MP 2.2.3: Identify and define any work product dependencies<br />
MP 2.2.4: Manage the quality of work products<br />
4.8.3.4 Stufe 3 - Etablierter Prozess (Established).
Kurzbeschreibung:<br />
Auf der Stufe 3 werden zwei Prozessattribute unterschieden: Process definition<br />
und Process resources. Der Einzelprozess wird durchgeführt und gelenkt durch<br />
einen definierten Prozess auf der Basis guter Software Engineering Prinzipien.<br />
Individuelle Anpassungen des Prozesses nutzen genehmigte Varianten des<br />
Standardprozesses, um die definierten Prozessergebnisse zu erzeugen. Die<br />
Ressourcen zur Durchführung der definierten Prozesse sind ebenfalls vorhanden.<br />
Der hauptsächliche Unterschied zur Stufe 2 ist, dass auf Stufe 3 ein allgemein<br />
definierter Prozess organisationsweit verfügbar und im Einsatz ist, um die<br />
definierten Arbeitsergebnisse zu erreichen.<br />
Prozesse der Stufe 3 folgen einer organisationsweit standardisierten detaillierten<br />
Vorgehensweise<br />
Prozessattribute:<br />
Auf Stufe 3 werden zwei Gruppen von Prozessattributen gefordert, eine<br />
prozessbezogene (PA 3.1) und eine organisationsbezogene (PA3.2):<br />
PA 3.1: Process definition attribute<br />
Das Prozessattribut PA 3.1 stellt fest, in welchem Ausmaß der Prozess auf<br />
Standardprozesse zurückgreifen kann, um die geforderten Ergebnisse zu erzeugen.<br />
Im einzelnen sind von einem Eizelprozess zur Erreichung der Stufe 3 - Bereich PA<br />
3.1 - folgende generischen Qualitätsmerkmale zu erfüllen:<br />
• MP 3.1.1: Identify the standard process that supports the execution of the<br />
managed process<br />
• MP 3.1.2: Implement and / or tailor the standard process<br />
• MP 3.1.3: Gather process performance data<br />
• MP 3.1.4: Establish and refine the understanding of the process behaviour by<br />
using process performance data<br />
• MP 3.1.5: Refine the standard process<br />
PA 3.2: Process resource attribute<br />
Das Prozessattribut PA 3.2 stellt fest, in welchem Ausmaß der Prozess in der<br />
Organisation auf angemessene Ressourcen, vor allem auf qualifizierte Mitarbeiter<br />
wie auf eine geeignete Basisinfrastruktur zurückgreifen kann. Letztlich geht es also<br />
darum, inwieweit der in PA 3.1 beschriebene Standardprozess auf<br />
167
168<br />
Organisationebene umgesetzt und mit ausreichenden Ressourcen versorgt ist. Im<br />
einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 3 - Bereich PA<br />
3.2 - folgende generischen Qualitätsmerkmale zu erfüllen:<br />
• MP 3.2.1: Identify and document the roles, responsibilities and<br />
competencies rquired to support the implementation of the defined process<br />
• MP 3.2.2: Identify and document the process infrastructure requirements<br />
• MP 3.2.3: Provide, allocate and use the resources to support the performance<br />
of the defined process<br />
• MP 3.2.4: Provide, allocate and use an adequate process infrastructure.<br />
4.8.3.5 Stufe 4 - Quantitativ steuerbarer und vorhersagbarer Prozess<br />
(Predictable)<br />
Kurzbeschreibung:<br />
Auf der Stufe 4 werden zwei Prozessattribute unterschieden: Process measurement<br />
und Process control. Der definierte Prozess wird durchgängig in der Praxis<br />
angewandt innerhalb definierter Schwankungsbreiten, um die definierten<br />
Prozessziele zu erreichen. Detaillierte Messwerte der Prozessdurchführung werden<br />
erhoben und ausgewertet. Dies führt zu einem quantitativen Verständnis der<br />
Prozessfähigkeiten und zu einer verbesserten Vorhersagbarkeit und Steuerung der<br />
Prozesse. Die Prozessleistung wird quantitativ gesteuert. Die Qualität der Produkte<br />
ist quantitativ erfasst. Der hauptsächliche Unterschied zur Stufe 3 ist, dass der<br />
definierte Prozess jetzt konsistent innerhalb definierter Grenzen durchgeführt wird,<br />
um die definierten Arbeitsergebnisse zu erreichen.<br />
Prozess der Stufe 4 werden quantitiativ überwacht und gesteuert<br />
Prozessattribute:<br />
Auf Stufe 4 werden zwei Gruppen von Prozessattributen gefordert, eine<br />
messungsbezogene (PA 4.1) und eine prozessbezogene (PA4.2):<br />
PA 4.1: Measurement attribute<br />
Das Prozessattribut PA 4.1 stellt fest, in welchem Ausmaß quantitative<br />
Zielvorgaben sowie Maße für den Prozess und die Produkte verwendet werden, um<br />
die Leistung und die Zielerreichung im Kontext der Geschäftsziele zu messen. Im
einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 4 - Bereich PA<br />
4.1 - folgende generischen Qualitätsmerkmale zu erfüllen:<br />
• MP 4.1.1: Identify product and process goals and measures<br />
• MP 4.1.2: Collect the specified product and process measures through<br />
performing the defined process<br />
• MP 4.1.3: Analyze trends in the performance of the process across the<br />
organisation.<br />
• MP 4.1.4: Measure the process capability and maintain it within defined<br />
limits across the organisation.<br />
PA 4.2: Process control attribute<br />
Das Prozessattribut PA 4.2 stellt fest, in welchem Ausmaß der Prozess quantitativ<br />
kontrolliert und gesteuert wird, um die vorgegebenen Prozess- und Produktziele zu<br />
erreichen. Im einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 4 -<br />
Bereich PA 4.2 - folgende generischen Qualitätsmerkmale zu erfüllen:<br />
• MP 4.2.1: Identify suitable measurement techniques<br />
• MP 4.2.2: Collect measures and identfy process control parameters in order<br />
to perform analysis<br />
• MP 4.2.3: Control the process performance using the analysis measures to<br />
identify actions to maintain control and/or implement improvement.<br />
4.8.3.6 Stufe 5 - Optimierender Prozess (Optimizing).<br />
Kurzbeschreibung:<br />
Auf der Stufe 5 werden zwei Prozessattribute unterschieden: Process change und<br />
Process innovation. Die Leistung des Einzelprozesses ist optimiert, um laufende<br />
Geschäftsanforderungen zu erfüllen. Der Prozess ist soweit ausgereift, dass er mit<br />
konstanter Performance wiederholbar ist. Quantitative Prozesseffektivitäts- und<br />
-effizienzziele für die Leistung sind vorhanden und bauen auf den Geschäftszielen<br />
der Organisation auf. Die kontinuierliche Prozesskontrolle gegen diese Ziele wird<br />
ermöglicht durch quantitative Überwachung. Die Verbesserung wird erreicht durch<br />
die Analyse der Ergebnisse. Die Verbesserung und Optimierung beinhaltet die<br />
Pilotierung innovativer Ideen und Technologien und die Veränderung ineffektiver<br />
Prozesse, um definierte Ziele (besser) zu erreichen. Der hauptsächliche Unterschied<br />
zur Stufe 4 ist, dass der definierte Standardprozess jetzt dynamisch<br />
weiterentwickelt wird, um aktuelle und zukünftige Geschäftsanforderungen<br />
optimal zu erfüllen.<br />
169
170<br />
Prozess der Stufe 5 arbeiten an einer ständigen Verbesserung<br />
Prozessattribute:<br />
Auf Stufe 5 werden zwei Gruppen von Prozessattributen gefordert, eine<br />
innovationsbezogene (PA 5.1) und eine verbesserungsbezogene (PA5.2):<br />
PA 5.1: Process change attribute<br />
Das Prozessattribut PA 5.1 stellt fest, in welchem Ausmaß der Prozess selbst auf<br />
der Basis quantitativer Prozessinformationen kontrolliert Prozessänderungen<br />
definiert, umsetzt und durch Ergebniskontrolle im Sinne der relevanten<br />
Geschäftsziele lenkt. Im einzelnen sind von einem Einzelprozess zur Erreichung<br />
der Stufe 5 - Bereich PA 5.1 - folgende generischen Qualitätsmerkmale zu erfüllen:<br />
• MP 5.1.1: Identify changes to the standard process definition on the basis of a<br />
quantitative understanding of the process<br />
• MP 5.1.2: Assess the impact of all proposed changes<br />
• MP 5.1.3: Define an implementation strategy for the approved change, ensuring<br />
that any disruption to the process performance is understood and acted upon.<br />
• MP 5.1.4: Implement the approved changes<br />
• MP 5.1.5: Evaluate the effectiveness of process change on the basis of actual<br />
performance.<br />
PA 5.2: Continuous improvement attribute<br />
Das Prozessattribut PA 5.2 stellt fest, in welchem Ausmaß der Prozess<br />
kontinuierliche Verbesserungsprozesse für die Erfüllung der übergeordneten<br />
geschäftspolitischen Zielvorgaben unterstützt. Im einzelnen sind von einem<br />
Einzelprozess zur Erreichung der Stufe 5 - Bereich PA 5.2 - folgende generischen<br />
Qualitätsmerkmale zu erfüllen:<br />
• MP 5.2.1.: Define the process improvement goals for the process<br />
• MP 5.2.2: Analyse the source of real and potential problems in the current<br />
process, identifying improvement opportunities in a systematic and<br />
proactive manner to continuously improve the process.<br />
• MP 5.2.3: Implement changes to selected areas of the tailored process<br />
according to the implementation strategy.
• MP 5.2.4: Validate the effectiveness of process change on the basis of actual<br />
performance and add feedback to the standard process definition.<br />
Die folgende Abbildung fasst in kompakter Weise nochmals die von Level zu<br />
Level zunehmenden Anforderungen an die Prozessbeherrschung zusammen:<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
4.8.4 Anwendungsbeispiel der ISO 15504/12207: Reifegradstufen im<br />
Projektmanagement<br />
In diesem Abschnitt wird am Beispiel des inhaltlichen Prozessbereichs<br />
‚Projektmanagement dargestellt, wie die Beherrschung und Professionalität <strong>beim</strong><br />
Projektmanagement von Capability-Level zu Capability-Level zunimmt.<br />
Ausgangspunkt dazu sind die von der ISO 15504 für das Projektmanagement<br />
definierten Base-Practices, d.h. Kernfähigkeiten, die vom Projektmanagement<br />
inhaltlich abzudecken sind:<br />
MAN.2.BP1 : Define the scope of work.<br />
MAN.2.BP2 : Determine development strategy<br />
MAN.2.BP3 : Select software life cycle model.<br />
MAN.2.BP4 : Size and estimate tasks and resources.<br />
MAN.2.BP5 : Develop work breakdown structure.<br />
171
172<br />
MAN.2.BP6 : Identify infrastructure requirements.<br />
MAN.2.BP7 : Establish project schedule.<br />
MAN.2.BP8 : Allocate responsibilities.<br />
MAN.2.BP9 : Identify interfaces.<br />
MAN.2.BP10 : Establish and implement project plans.<br />
MAN.2.BP11 : Track progress against plans.<br />
MAN.2.BP12 : Act to correct deviations.<br />
Je nach Reifegradstufe sind diese Base-Practices in unterschiedlichem Umfang und<br />
Perfektion zu erfüllen. Im einzelnen sind die Base-Practice auf den verschiedenen<br />
Reifegradstufen sinngemäß in der im folgenden dargestellten abgestuften Weise zu<br />
beherrschen:<br />
Stufe 0: Ein Projektmanagement ist nicht vorhanden, es gibt nicht einmal einen<br />
klaren Entwicklungsprozess.<br />
Stufe 1: Der Entwicklungsprozess wird als Black-Box betrachtet. Klarheit über die<br />
vorhandenen Input-Produkte und über die zu erstellenden Output-Ergebnisse ist<br />
vorhanden. Da der Prozess aber ansonsten nicht transparent ist, sind weitere<br />
spezifische Anforderungen an das Projektmanagement nicht vorhanden.<br />
Stufe 2: Elementare Projektplanungstechniken für jedes Einzelprojekt sowie<br />
Einzelprojektverfolgung und -steuerung werden eingesetzt.<br />
6. Zusätzlich zu Stufe 1: Zielsetzungen für die Leistung des Prozesses hinsichtlich<br />
Zeit und Aufwänden ist vorhanden. Es sind Aufwandskennzahlen sowie<br />
Schätzmethoden im Einsatz. Für die Planung werden Werkzeuge eingesetzt<br />
sowie Methoden wie z.B. kritische-Pfad-Methoden. Außerdem sind klare<br />
Zuordnungen von Aufgaben zu Ressourcen vorgenommen einschließlich<br />
Ergebnisverantwortung. Der Ergebnisfortschritt wird regelmäßig kontrolliert<br />
und berichtet.<br />
Stufe 3: Das Projektmanagement ist auf Organisationsebene definiert und wird als<br />
integriertes Projektmanagement gelebt.<br />
1. Zusätzlich zu Stufe 2: Organisationsweite Standard für die Durchführung von<br />
Projekten sind vorhanden. Prozess- und Projektmessdaten werden regelmäßig<br />
erhoben und zentral gesammelt. Die erhobenen Daten werden zentral ausgewertet,<br />
auf Trends hin analysiert und für ein vertieftes Verständnis der<br />
laufenden Prozesse verwendet. Die verschiedenen für das Projekt relevanten<br />
Einzelpläne werden zu einem gemeinsamen Projektplan integriert (z.B.:<br />
Meilensteinplan, Budgetplan, Ressourcenplan, Qualitätsmanagementplan,<br />
Abnahmeplan usw.).<br />
Stufe 4: Ein quantitatives Projektmanagement ist organisationsweit etabliert.<br />
1. Zusätzlich zu Stufe 3: Die Daten von Stufe 3 werden systematisch zur<br />
Steuerung der Projekte auf Organisationsebene verwendet. Es werden<br />
systematisch projektübergreifende Soll-Ist-Vergleiche hinsichtlich Zeit,
Aufwand und Ergebnisse durchgeführt. Dabei werden auch vordefinierte<br />
Zielgrößen (Benchmark) eingesetzt. Die Projektsteuerung erfolgt zunehmend<br />
unter Berücksichtigung der übergeordneten geschäftspolitischen Zielsetzungen.<br />
Das Projektreporting erfolgt daher analog auch anhand aggregierter<br />
management-gerechter Indikatoren, insbesondere Zeit, Kosten, Produktivität,<br />
Risikoindikatoren. Verfahren der statistischen Qualitätssicherungen können<br />
eingesetzt werden.<br />
Stufe 5: Laufende Optimierung und Innovation der Projektdurchführung und der<br />
Projektmanagementprozesse auf Basis quantitativer Grundlagen.<br />
1. Zusätzlich zu Stufe 4: Neben die Steuerung der Projektdurchführung tritt die<br />
ständige Optimierung und Verbesserung des Projektmanagementprozesses<br />
selbst. Abweichungen von Zielvorgaben oder neue Benchmarks werden zum<br />
Anlass genommen, den derzeit gelebten Prozess auf Verbesserungsmöglichkeiten<br />
hin zu analysieren, die Verbessserungsansätze einzuführen und<br />
deren Auswirkungen systematisch zu beobachten.<br />
4.8.5 Risikomanagement gemäß ISO 15504 / ISO 12207<br />
Die Bedeutung von Risikomanagement<br />
Risiken sind ein unvermeidlicher Bestandteil jeder Software oder<br />
Systementwicklung. Der richtige Umgang mit den Risiken entscheidet in vielen<br />
Fällen über den Projekterfolg. Das Risikomanagment ist der Management Prozess,<br />
der kontinuierlich versucht zu erkennen, was in einem Entwicklungsprojekt falsch<br />
gehen könnte, die Schwere und die Eintrittswahr-scheinlichkeit der Ereignisse<br />
abschätzt und daraus versucht Managementmassnahmen abzuleiten. Das Ziel des<br />
Risiko Managements ist es also Projekt Risiken frühzeitig zu erkennen und<br />
mögliche Probleme abzuschwächen oder zu vermeiden. Risiko Management<br />
bestimmt dabei in starkem Maße das Life-Cycle Modell des jeweiligen SW<br />
Projekts.<br />
Die Grundaufgaben<br />
Zu den Grundaufgaben des Risikomanagements gehören die<br />
• Identifikation von Risiken<br />
• Die Analyse und Priorisierung von Risiken<br />
• Die Definition von Strategien um die Risiken zu managen<br />
• Die Definition von Metriken um die Risiken zu überwachen<br />
• Die Durchführung der Risiko Management Strategien<br />
• Die Beobachtung der Ergebnisse der Risiko Management Strategien mit<br />
Hilfe der definierten Metriken<br />
Die Durchführung von korrektiven Massnahmen, wenn die Risikovermeidung<br />
nicht erfolgreich ist.<br />
Identifikation von Risiken<br />
173
Die Identifikation von Risiken erfolgt in einem ersten Schritt am Anfang des<br />
Projekts und wird in regelmäßigen Abständen wiederholt, da während eines<br />
Projektes neue Risiken entstehen können. Die Identifikation erfolgt am besten im<br />
Team durch moderierte Brainstormingsitzungen und durch systematische Suche<br />
nach Risiken mit Hilfe von Checklisten. Dabei ist zu beachten, daß Risiken ganz<br />
unterschiedliche Ursachen haben können. Eine Klassifikation [CMU/SEI-93-TR-6]<br />
unterscheidet zwischen Risiken des Product Engineerings, Risiken durch Prozeßund<br />
Arbeitsumgebung und Risiken durch externe Randbedingungen.<br />
Analyse und Priorisierung von Risiken<br />
In der Analyse von Risiken wird die Schwere des Schadens die das Eintreffen eines<br />
Risikos haben kann und die Eintrittswahrscheinlichkeit eines Riskos bewertet<br />
Schwere (S) der Konsequenzen bei Eintritt des Risikos<br />
(0) vernachlässigbar<br />
(-) gering<br />
(--) kritisch<br />
(---) katastrophal<br />
Eintrittswahrscheinlichkeit (E)<br />
(0) unwahrscheinlich<br />
(-) gering<br />
(--) gelegentlich<br />
(---) wahrscheinlich<br />
Aus Eintrittswahrscheinlichkeit und möglichem Schaden ergibt sich der<br />
Handlungsbedarf<br />
Handlungsbedarf<br />
Schwer<br />
e<br />
174<br />
Eintrittswahrscheinlichkeit<br />
wahscheinlich gelegentlich gering unwahrscheinlich<br />
Katastrophal hoch Hoch mittel kein<br />
Kritisch hoch Mittel gering kein<br />
Gering mittel Gering gering kein<br />
Vernachlässigb<br />
ar<br />
kein Kein kein kein<br />
Strategien zum Management von Risiken<br />
Je nach Handlungsbedarf sind unterschiedliche Strategien zur Vermeidung der<br />
Folgen bei Eintritt von Risiken zu suchen
hoher Handlungsbedarf:<br />
Lösungen müssen präventiv gesucht werden. Bei Produktrisiken sind<br />
Prototypen zu planen und zu entwickeln und Alternativlösungen zu<br />
erproben.<br />
mittlerer Handlungsbedarf:<br />
QS-Maßnahmen sind einzuplanen. Alternativlösungen suchen<br />
Geringer Handlungsbedarf:<br />
Das Risiko ist zu beobachten.<br />
Für jedes Risiko mit Handlungsbedarf sind Aktivitäten und Ressourcen und<br />
Termine zu planen, die im Rahmen des Projektmanagements behandelt werden.<br />
Metriken zur Überwachung von Risiken<br />
Metriken zur Überwachung von Risiken sollten zumindest die Wahrscheinlichkeit<br />
für das Auftreten eines Risikos und die Größe des Schadens berücksichtigen. Dabei<br />
ist zu beachten, dass der Schaden bei fortschreitendem Projekt immer größer<br />
werden kann.<br />
Durchführung der Risikomanagment Strategien<br />
Die Durchführung des Risikomassnahmen erfolgt im Rahmen des<br />
Projektmanagements. Je nach Massnahme werden hierdurch andere<br />
Lifecyclemodelle bevorzugt. Projekte mit hohen technischen oder anderen<br />
Produktrisiken führen zu Prototypenenwicklungen im Rahmen von<br />
Spiralmodellen, Projekte mit hohen Prozessrisiken (umfangreiche Projekte)<br />
benötigen Iterative Modelle mit Prozessen hoher Qualität. Kleine Projekte mit<br />
geringen Risiken stellen dagegen kaum Anforderungen an das zugrundeliegende<br />
Lifecyclemodell. Der Bereich komplexer Projekte mit hohen technischen Risiken<br />
ist als sehr kritisch zu betrachten. Eine umfangreiche Prototypphase in der die<br />
wichtigsten Risiken geklärt werden, gefolgt von einem iterativen Vorgehensmodell<br />
zur Bewältigung der Komplexität ist ein mögliches Vorgehensmodell.<br />
175
176<br />
K o m p l e x i t ä t / P r o z e ß r i s i k e n<br />
P r o z e ß b e h e r r s c h u n g<br />
R i s i k o<br />
S i c h e r e P r o j e k t e V o r e n t w i c k l u n g<br />
P r o d u k t R i s i k e n / t e c h n i s c h e R i s i k e n<br />
4.8.6 Assessments gemäß ISO 15504 / ISO 12207<br />
Die Zielsetzung der ISO 15504 (sowie von CMMI) ist, zur Verbesserung von<br />
Software-Entwicklungsprozessen beizutragen, um damit schließlich eine<br />
Verbesserung der Software-Produktqualität sowie eine Produktivitätsverbesserung<br />
bei den Entwicklungsprozessen zu erreichen. Die Bewertung des Reifegrades von<br />
Software-Entwicklungsprozessen findet in sogenannten Assessments statt. Dabei<br />
werden die zu untersuchenden Einzelprozesse gemäß des dargestellten<br />
Reifegradmodells bewertet::
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
Die Reife eines Prozesses bestimmt sich dabei nach dem Erfüllungsgrad der<br />
Prozessattribute. Pro Prozess wird für die Prozessattribute nach Auswertung<br />
vorgegebener Checkfragen ein Erfüllungsgrad in einer vierstufigen Skala vergeben:<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
Ein Capability-Level gilt als erreicht, wenn alle Prozessattribute darunterliegender<br />
Level voll erfüllt sind (Fully) und jene des betreffenden Levels größtenteils oder<br />
voll erfüllt sind (Largely oder Fully):<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
177
178<br />
In der folgenden Tabelle wird zusammenfassend dargestellt, welche Bedingungen<br />
ein Einzelprozess erfüllen muß, wenn er auf einem bestimmten Level bewertet<br />
werden soll:<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
Mithilfe dieser Bewertungsrichtlinien können dann für verschiedene Prozesse<br />
differenzierte Bewertungsprofile erstellt werden:<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
Das Ergebnis eines solchen Assessments wird schließlich in aufbereiteter Form als<br />
Assessment-Bericht für die Software-Entwicklungsorganisation zur Verfügung
gestellt. Darin sind dann neben der Einstufung der Einzelprozesse auch weitere<br />
detaillierte Assessment-Ergebnisse enthalten, z.B. die Darstellung von Bereichen,<br />
in denen punktuell bereits Prozess-Attribute von höheren Reifegradstufen erreicht<br />
worden sind:<br />
Quelle: Qualität und <strong>Informatik</strong>, www.itq.ch<br />
4.8.7 Das CMMI-Modell<br />
Das CMMI-Modell hat seinen Ursprung in den USA, wo das Verteidigungsministerium<br />
(DoD) in den 80er Jahren einen Kriterienkatalog für gute<br />
Software-Lieferanten bei der Vergabe von Software-Entwicklungsaufträgen<br />
entwickeln ließ. Ziel war, bei der Auftragsvergabe für Softwareprojekte<br />
einigermaßen sicher zu sein, dass der Auftragnehmer die Software wie versprochen<br />
in der vorgesehenen Zeit, im Budget und mit der zugesagten Qualität liefern kann.<br />
Dazu entwickelte 1987 das Software Engineering Institute der Carnegie Mellon<br />
University unter Leitung von Watts Humphrey die Idee, in der Industrie bewährte<br />
Praktiken ("best practices") in einem Referenzmodell für Software-<br />
Entwicklungsprozesse zu vereinen, das als Fragebogen eingesetzt werden sollte.<br />
Aus dieser Arbeit entstand 1991 das Capability Maturity Modell (CMM).<br />
Zur Unterscheidung von später entwickelten weiteren CMM-Modellen nannte man<br />
dieses Modell auch "Software CMM". Unternehmen konnten diese Praktiken<br />
adaptieren, um somit besser und erfolgreicher Software zu entwickeln und dabei<br />
schrittweise verschiedene Reifegradstufen erreichen. Ein Unternehmen konnte<br />
mittels eines Assessments untersucht und beurteilt werden, auf welcher Reifegradstufe<br />
es sich befindet.<br />
Nachdem das CMM in der Anfangszeit nur von Organisationen verwendet wurde,<br />
die vom DoD als Auftraggeber dazu gezwungen wurden, stellte sich bald heraus,<br />
dass auch der Auftragnehmer einen deutlichen Nutzen von einer solchen<br />
179
180<br />
Vorgehensweise hat. Eine Reihe von Unternehmen begann daher, das CMM<br />
freiwillig zur eigenen Prozessverbesserung zu nutzen. Es verbreitete sich von USA<br />
aus schließlich schnell in die ganze Welt. Die Anwendergemeinde umfaßt heute<br />
Tausende von (aufgrund der Durchführung offizieller Assessments) registrierten<br />
Unternehmen sowie eine unbekannte Anzahl von selbständigen Anwendern. Die<br />
Version 1.0 erschien im August 1991 und die verbesserte, heute noch gültige<br />
Version 1.1 im Februar 1993. Im Lauf der Jahre sind neben dem ursprünglichen<br />
Software CMM eine Reihe weiterer Reifegradmodelle für andere<br />
Anwendungsgebiete entstanden (wie z.B. People CMM, Software Acquisition<br />
CMM).<br />
Das CMMI (Capability Maturity Model Integration) ist nun der Nachfolger des<br />
CMM. Es wurde ebenfalls am Software Engineering Institute (SEI) der Carnegie-<br />
Mellon University in Pittsburgh im Auftrag des DoD entwickelt. In diesem neuen<br />
CMMI sind viele Erfahrungen und Verbesserungsvorschläge zum CMM<br />
eingeflossen. Die Anforderungen sind einheitlicher strukturiert und der<br />
Anwendungsbereich ist über die Softwareentwicklung hinaus erweitert worden.<br />
Außerdem wurde durch die Einführung der kontinuierlichen, d.h.<br />
einzelprozessbezogenen Reifegradbewertung, die Konsistenz zur ISO 15504<br />
weitgehend erreicht. Das Nebeneinander verschiedener CMM-Modelle (Software-<br />
CMM, People-CMM etc.) wurde ebenfalls bereinigt. Alle Informationen zum<br />
CMM und zum CMMI sind öffentlich über das Internet erhältlich auf der<br />
Homepage des SEI unter der Adresse http://www.sei.cmu.edu. Das CMMI-Modell<br />
V1.1 ist veröffentlicht als CMU/SEI-2002-TR-001.<br />
Ein Ziel bei der Entwicklung des CMMI war, konform zu SPICE (ISO 15504) zu<br />
sein. Im großen und ganzen scheint dies auch gelungen, wobei zu ergänzen ist,<br />
dass die ISO 15504 bis heute (März 2004) noch nicht endgültig verabschiedet ist.<br />
Genauso wie die ISO 15504 hilft CMMI Softwareunternehmen bei der<br />
Verbesserung der eigenen Prozesse und zeigt auf, was für eine erfolgreiche<br />
Softwareentwicklung erforderlich ist. Durch die sechs Reifegradstufen wird ein mit<br />
ISO 15504 kompatibler Verbesserungspfad beschrieben. Die Vorgehensweisen von<br />
CMMI beruhen dabei ebenfalls auf praxisbewährten Best Practices und nicht auf<br />
einem theoretischen Modell.<br />
Eine detaillierte Darstellung der inhaltlichen Unterschiede würde über den Rahmen<br />
dieses Skriptes hinausgehen, ist jedoch auch angesichts der überschaubaren<br />
Differenzen nicht erforderlich. Wichtiger sind die Unterschiede <strong>beim</strong><br />
organisatorischen Status und bei der Durchführung von Assessments:<br />
Status bei CMMI:<br />
CMMI bietet professionellen Support durch das Software Engineering Institute<br />
(SEI) an der Carnegie Mellon University in Pittsburgh. Hierzu gehören z.B.<br />
Schulungskurse, Lead Assessoren Kurse, die Registrierung von Lead Assessoren<br />
sowie von offiziell durchgeführten Assessments in einer Datenbank mit jährlichen<br />
statistischen Auswertungen. Eine Vielzahl von Informationen kann kostenlos von
der SEI Website (www.sei.cmu.edu) abgerufen werden, z.B. auch die<br />
verschiedenen CMMI Modelle. Das SEIR (Software Engineering Information<br />
Respository, http://seir.sei.cmu.edu/) bietet zudem eine große Menge von<br />
wertvollen Praxisinformationen und Beispielen zu den verschiedenen Software<br />
Engineering Themengebieten. Der Stellenwert des CMMI auch für die europäische<br />
Softwareindustrie dürfte durch die Gründung des SEI Europe in Frankfurt/Main<br />
(europäische Außenstelle des SEI) im Jahre 2003 noch zunehmen.<br />
CMMI gilt deshalb als ein sehr vielversprechendes Referenzmodell und es ist zu<br />
erwarten, dass sich die Benutzergemeinde bezogen auf das Vorgängermodell CMM<br />
vervielfachen wird. Entscheidende Faktoren hierfür sind:<br />
• die Erweiterung auf (System) Engineering Prozesse<br />
• die Flexibilität zweier Repräsentationsformen bei voller inhaltlicher<br />
Kompatibilität<br />
• die Qualität, Ausführlichkeit und Verständlichkeit der Modelle<br />
• der professionelle Support<br />
Status bei ISO 15504:<br />
Hinter ISO 15504 steht keine betreuende Organisation wie bei CMM.<br />
Entsprechend gering sind die Informationen, die oftmals veraltet sind und von der<br />
SPICE User Group (http://www.seg.iit.nrc.ca/spice/) oder<br />
Forschungsorganisationen (z.B.http://www.sqi.gu.edu.au/spice/) geboten werden.<br />
Neuere Informationen, etwa zur Weiterentwicklung des TR in Hinblick auf die<br />
Norm, sind äußerst spärlich. Von einem professionellen "Support" kann daher<br />
keine Rede sein. Die 98er Version des TR wurde noch kostenlos zum Download<br />
angeboten (mittlerweile eingestellt), die gültige 99er Version (inhaltlich praktisch<br />
identisch) kann für mehrere hundert Euro von der ISO bezogen werden<br />
(www.iso.ch). Die ISO 15504 hat derzeit (März 2004) immer noch den Status<br />
Technical Report, also die letzte Vorstufe vor dem International Standard, mit<br />
dessen Erscheinen in den nächsten Jahren zu rechnen ist. Die ISO 15504 wird<br />
dabei noch einmal überarbeitet werden.<br />
Die ISO 15504 hat derzeit international im Vergleich zu den CMM-Modellen<br />
geringere Bedeutung und wird in der Praxis hauptsächlich in Australien, Europa<br />
und dort insbesondere in Deutschland angewendet. In Deutschland wird die ISO<br />
15504 durch die Entscheidung einiger Automobilhersteller (Herstellerinitiative<br />
Software, HIS, bestehend aus Audi, BMW, DaimlerChrysler, Porsche, VW), die<br />
ISO 15504 für die Bewertung von Lieferanten einzusetzen, jedoch voraussichtlich<br />
an Bedeutung gewinnen. Durch die Konformität von CMMI zur ISO 15504 ist<br />
jedoch der Erfolg dieser Inititative noch abzuwarten.<br />
Fazit:<br />
Angesichts der geringen inhaltlichen Differenzen zwischen ISO 15504 und CMMI<br />
und angesichts der stärkeren institutionellen Unterstützung bei CMMI ist zu<br />
erwarten, dass CMMI mittelfristig die führende Rolle bei den prozessorientierten<br />
Qualitätsmanagement-Ansätzen einnehmen kann.<br />
181
182<br />
4.8.8 Literatur<br />
• Ralf Kneuper: CMMI - Verbesserung von Softwareprozessen mit Capability<br />
Maturity Model Integration. Dpunkt.Verlag Heidelberg, 2003.<br />
• Watts S. Humphrey: Characterizing the Software Process: A Maturity<br />
Framework, Software Engineering Institute, CMU/SEI-87-TR-11<br />
• Watts S. Humphrey: Managing the Software Process, Addison Wesley,<br />
Reading, MA, 1989<br />
• The Capability Maturity Model - Guidelines for Improving the Software<br />
Process, Carnegie Mellon, University, Software Engineering Institute,<br />
Addison Wesley, Reading, MA, 1994<br />
• ISO/IEC TR 15504-5:1999(E), Information technology - Software Process<br />
Assessment, First Edition 1999-05-01<br />
• Capability Maturity Model ® Integration (CMMI SM), Version 1.1, Carnegie<br />
Mellon, Software Engineering Institute, March 2002, CMU/SEI-2002-TR-001
5 Requirements Engineering<br />
5.1 Textuelle Beschreibung von Anwendungsfällen<br />
Die Anforderungsanalyse besteht einerseits aus den nicht funktionalen Anforderungen wie<br />
Definition der Qualität des zukünftigen Systems, Festlegung des Termins, zu dem das Produkt<br />
fertig sein soll, Vorgaben für die einzusetzende Hardware und Software etc.<br />
Außer diesen nicht funktionalen Anforderungen gibt es die funktionalen Anforderungen, d. h. die<br />
Spezifikation der Funktionen des Systems. Der generelle Ablauf des Systems kann durch<br />
Workflows dargestellt werden. Die einzelnen Anwendungsfälle können mit Hilfe der Use-Caseoder<br />
Anwendungsfall-Modellierung spezifiziert werden.<br />
Wir kennen Use-Cases (Anwendungsfälle) schon aus dem 1. Teil der Vorlesung. Hier ein Beispiel,<br />
wie man Use-Cases beschreiben kann:<br />
Beispiel 1: Geldautomat (ATM)<br />
Customer<br />
1. Überschrift: Geld abheben<br />
2. Einfache verbale Beschreibung:<br />
Nachdem der Kunde die Karte eingeschoben und die PIN und den Betrag eingegeben hat, wird der<br />
Betrag vom Konto abgebucht und die Karte und das Geld ausgegeben. Falls die PIN das 1. oder 2.<br />
Mal falsch eingegeben wurde, wird der Kunde benachrichtigt und die PIN wird erneut eingegeben.<br />
Falls die PIN ein 3. Mal falsch eingegeben wurde, protokolliert das System den Versuch, zieht die<br />
Karte ein und bricht die Kommunikation ab. Falls die Karte nicht gültig ist, wird dies dem Kunden<br />
mitgeteilt und die Karte wieder ausgegeben.<br />
Bessere und eindeutigere Schreibweise:<br />
ATM<br />
Withdraw<br />
Cash<br />
Fig. 1: Graphische Darstellung des Use-<br />
Case Diagramms<br />
Geldautomat<br />
183
184<br />
Die obige Beschreibung des Anwendungsfalls ist nicht sehr übersichtlich und auch nicht ganz<br />
eindeutig. Aus der obigen Beschreibung kann man nicht erkennen, ob zuerst die PIN geprüft wird<br />
und evtl. die Ausnahmesituation eintritt oder ob PIN und Betrag eingegeben werden und danach<br />
die Prüfung erfolgt. Cockburn hat in seinem Buch "Writing Effective Use-Cases" [Co01] erläutert,<br />
wie Anwendungsfälle besser beschrieben werden können: Wir schreiben die einzelnen Aktionen<br />
(Action-Steps) in der richtigen Reihenfolge und nummerieren jede Aktion. Jede Aktion wird durch<br />
einen einfachen Satz Subjekt, Verb, Objekt und evtl. präpositionale Ergänzungen beschrieben. Als<br />
Subjekt steht immer die Instanz, die die Aktion durchführt. Wir geben ein Use-Case-Goal an.<br />
Dieses Use-Case-Goal macht eine Aussage darüber, was das Ziel des Anwendungsfalls ist. Das<br />
Use-Case-Goal entspricht normalerweise dem Namen des Anwendungsfalls bzw. sagt aus, dass der<br />
Name das Ziel des Anwendungsfalls beschreiben sollte. Es ist immer aus der Sicht des Akteurs zu<br />
sehen, d. h. man schreibt Geld abheben, nicht Geld auszahlen.<br />
Beispiel 1: Geldautomat<br />
Use-Case-Goal: Geld abheben<br />
Basic Course:<br />
1. Kunde schiebt Karte ein.<br />
2. Das System überprüft, dass die Karte gültig ist.<br />
3. Kunde gibt PIN ein.<br />
4. Das System überprüft, dass die PIN die richtige<br />
PIN zur Karte ist.<br />
5. Kunde gibt gewünschten Betrag ein.<br />
6. System bucht Betrag vom Konto ab.<br />
7. System gibt Karte aus.<br />
8. System gibt Geld aus.<br />
In der UML gibt es noch den Begriff Use-Case-Business-Result. Dieses Use-Case-Business-<br />
Result gibt an, welches Ergebnis nach dem erfolgreichen Durchlauf durch den Anwendungsfall<br />
entsteht.<br />
Use-Case-Business-Result:<br />
Das Geld wurde vom Automat ausgegeben und vom Konto<br />
abgebucht.<br />
Die Karte wurde vom Automat zurückgegeben.<br />
Das System ist wieder bereit für den nächsten Kunden.<br />
Alle Fehler– und Transaktionsdaten wie z. B. Zeit und Datum<br />
der Transaktion wurden protokolliert.<br />
Was haben wir nun noch vergessen?<br />
Was passiert, wenn z. B. die PIN falsch eingegeben wird, die Karte nicht lesbar ist etc.?
Basic Course<br />
?<br />
Business<br />
Result<br />
Jeder Ausnahmefall wird nicht im Basic Course, sondern in einem speziellen Alternative<br />
Course beschrieben. Vorteil dieser Vorgehensweise ist, dass man sich als erstes Gedanken<br />
macht über den Normalfall. Im zweiten Schritt werden die Ausnahmen durchdacht. Um die<br />
Beschreibung übersichtlich zu halten, werden die Ausnahmefälle nicht in den Basic Course<br />
integriert (z. B. mit: "Wenn das und das tue dieses und jenes" - und das evtl. über mehrere<br />
Stufen), sondern in einem gesonderten Alternative Course beschrieben, der auf den Basic<br />
Course Bezug nimmt.<br />
Alternative<br />
Course<br />
Alternative Courses:<br />
4a. Das System erkennt, dass die PIN das 1. oder 2.<br />
Mal falsch eingegeben wurde:<br />
4a1. Das System protokolliert den Versuch.<br />
4a2. Das System benachrichtigt den Kunden.<br />
4a3. Rückkehr nach 3.<br />
4b. Das System erkennt, dass die PIN das 3. Mal<br />
falsch eingegeben wurde:<br />
4b1. Das System protokolliert den Versuch.<br />
4b2. Das System zieht endgültig die Karte ein.<br />
4b3. Das System benachrichtigt den Kunden.<br />
4b4. Use-Case wird abgebrochen.<br />
Aufgabe: Was passiert, wenn die Karte ungültig ist?<br />
Beschreiben Sie den Alternative Course.<br />
185
186<br />
Wie wird der Use-Case ausgelöst?<br />
Ein Use-Case wird durch einen Trigger ausgelöst. Der Trigger kann die erste Aktion im Use-Case<br />
sein (z. B.: Der Kunde schiebt die Karte ein), es kann aber auch ein Ereignis von außerhalb des<br />
eigentlichen Use-Cases sein (z. B.: Kunde ruft an und will Auftrag vergeben. Die erste Aktion ist<br />
dann: Sachbearbeiter ruft Auftragserfassungsprogramm auf) oder ein Timer<br />
Derjenige der durch die direkte Kommunikation mit dem System den Use-Case anstößt, d. h.<br />
derjenige, der die erste Aktion des Use-Case durchführt wird Primary Actor genannt<br />
Wer ist bei der Beschreibung des Use-Case zu befragen?<br />
Alle Stakeholders, d. h. alle, die an dem Use-Case interessiert sind. Das sind oft nicht nur die<br />
Akteure, sondern auch andere Personen oder Interessengruppen wie z. B. der Besitzer des<br />
zukünftigen Systems, der Abteilungsleiter, die interne Revisionsabteilung etc. Die Akteure sind<br />
zwar diejenigen, die später das System bedienen werden, sind aber oft für die Definition des Use-<br />
Case nicht so wichtig wie andere Stakeholders.<br />
Typen von Alternative Courses [MOW03]<br />
- Use-Case-Exception<br />
- Verzweigt und kehrt nie mehr zurück<br />
- Erfüllt nicht die Use-Case-Business-Results<br />
In [Co01]: Use-Case-Business-Results =<br />
Success-Guarantees. die Minimal-Guarantees<br />
sind immer, d. h. auch bei Abbruch erfüllt – hier:<br />
Minimal-Guarantees:<br />
Alle Fehler– und Transaktionsdaten wurden protokolliert.<br />
Siehe Beispiel 1 (Geldautomat) zweiter Alternative Course:<br />
4b. Das System erkennt, dass die PIN das 3. Mal<br />
falsch eingegeben wurde:<br />
4b1. Das System protokolliert den Versuch.<br />
4b2. Das System zieht endgültig die Karte ein.<br />
4b3. Das System benachrichtigt den Kunden.<br />
Fig. 3:<br />
Use-Case-Exception
4b4. Use-Case wird abgebrochen.<br />
- Alternative History<br />
- Verzweigt und kehrt nie mehr zurück<br />
- Erfüllt die Use-Case-Business-Results<br />
(= Success-Guarantees)<br />
Beispiel 2 Personalverwaltung:<br />
Use-Case-Goal: Mitarbeiter einstellen<br />
Basic Course:<br />
1. Der Sachbearbeiter der Personalabteilung gibt den Namen,<br />
die Adresse und Telefonnummer des einzustellenden<br />
Mitarbeiters ein.<br />
2. Der Sachbearbeiter der Personalabteilung gibt die<br />
Abteilung des neuen Mitarbeiters ein.<br />
3. Das System weist dem Mitarbeiter eine eindeutige<br />
Personalnummer zu.<br />
4. Das System zeigt die verschiedenen Entlohnungstarife an.<br />
5. Der Sachbearbeiter der Personalabteilung selektiert einen<br />
Tarif.<br />
6. Der Sachbearbeiter der Personalabteilung gibt die<br />
wöchentliche Arbeitszeit ein.<br />
Use-Case-Business-Results / Success-Guarantees:<br />
Der neue Mitarbeiter ist eingestellt.<br />
Der Personalstammsatz ist angelegt.<br />
+ Minimal-Guarantees<br />
Minimal-Guarantees:<br />
Alle Fehler– und Transaktionsdaten wurden protokolliert.<br />
Alternative History:<br />
5a. Der Sachbearbeiter entscheidet, dass die Position<br />
eine außertarifliche Bezahlung erfordert:<br />
Fig. 2:<br />
Alternative<br />
History<br />
187
188<br />
5a1. Der Sachbearbeiter der Personalabteilung legt das<br />
außertarifliche Monatsgehalt fest.<br />
5a2. Der Sachbearbeiter der Personalabteilung vermerkt<br />
sonstige Nebenabreden.<br />
5a3. Use-Case endet erfolgreich.<br />
- Alternative Part<br />
- Verzweigt und kehrt zurück zu Basic Course<br />
- Erfüllt die Business-Results<br />
3 Arten von Alternative Parts:<br />
- - Conditional Insertion<br />
Beispiel 3: Studentenverwaltung<br />
Basic Course<br />
Use-Case-Goal: Studierenden immatrikulieren<br />
1. Sachbearbeiter gibt Name und Adresse des<br />
Studierenden ein.<br />
2. Das System vergibt eine Matrikelnummer.<br />
3. Sachbearbeiter trägt den <strong>Fachbereich</strong> ein.<br />
4. System druckt die Immatrikulationsbestätigungen.<br />
Alternative Course (hier: Conditional Insertion):<br />
(a) (b) (c)<br />
A A<br />
4a. Studierender hat noch keine Wohnung und ihm wurde ein<br />
Wohnheimplatz zugesagt:<br />
4a1. Das System zeigt freie Wohnheimplätze an.<br />
4a2. Dem Studierenden wird ein Wohnheimplatz<br />
zugewiesen.<br />
4a3. Rückkehr nach 4.<br />
Bemerkung:<br />
Extension Point (hier: Action-Step 4) ist der Punkt, an dem der Base Use-Case<br />
verlassen wird. Der Action-Step des Extension Points wird nicht durchgeführt,<br />
Conditional<br />
Insertion<br />
B<br />
Interaction<br />
Cycle<br />
Fig. 3: Alternative Part<br />
B<br />
A<br />
Alternative interaction<br />
fragment<br />
B
- - Interaction Circle<br />
stattdessen werden die Action-Steps des Alternative Courses durchgeführt<br />
[MOW03].<br />
Return Point ist der Punkt, an dem wieder in den Base Course zurückgesprungen<br />
wird (hier wie bei jeder Conditional Insertion = Extension Point). Der Action-Step<br />
am Return Point wird nach dem Rücksprung als nächstes durchgeführt[MOW03].<br />
Siehe Beispiel 1 (Geldautomat) erster Alternative Course:<br />
4a. Das System erkennt, dass die PIN das 1. oder 2.<br />
Mal falsch eingegeben wurde:<br />
4a1. Das System protokolliert den Versuch.<br />
4a2. Das System benachrichtigt den Kunden.<br />
4a3. Rückkehr nach 3.<br />
- - Alternative Interaction Fragment<br />
Beispiel 4: Auftragsverwaltung<br />
Use-Case-Goal: Auftrag erfassen<br />
Basic Course:<br />
1. Der Auftragssachbearbeiter gibt den Namen des Kunden ein.<br />
2. Das System zeigt alle Kunden mit diesem Namen an.<br />
3. Der Auftragssachbearbeiter wählt den richtigen<br />
Kunden aus.<br />
4. Das System zeigt alle Kundendaten an.<br />
5. ...<br />
Alternative Course (hier: Alternative Interaction Fragment):<br />
1a. Der Auftragssachbearbeiter wünscht mit<br />
Kundennummer zuzugreifen:<br />
1a1. Eingabe der Kundennummer.<br />
Rückkehr nach 4.<br />
Abbildung zwischen textueller Beschreibung und graphischer Darstellung<br />
Es existieren 2 Welten:<br />
- UML<br />
189
190<br />
- textuelle Beschreibung<br />
Textuelle Beschreibung mit<br />
Basic Course +<br />
Alternative Courses<br />
kann sich in einen Use-Case abspielen.<br />
Aber auch möglich:<br />
In Base-Use-Case + Extension-Use-Case.<br />
Dies ist z. B. dann ratsam, falls der Alternative Course in mehreren verschiedenen Base-Use-Cases<br />
vorkommt.<br />
Abbildung zwischen textueller und graphischer Welt:<br />
Extension<br />
Point<br />
Rejoin<br />
Point<br />
base<br />
use case<br />
Basic Course<br />
Fig. 4 Alternative Course als eigener Use<br />
Case<br />
Darstellung von Beispiel 1 als ausgelagerte mit extend angebundene Use-Cases:<br />
«extend»<br />
Alternative<br />
Course<br />
[condition]<br />
extension<br />
use case
Akteur2<br />
Geld abheben<br />
Geldautomat<br />
<br />
{ 4, Abbruch;<br />
Condition:<br />
PIN wurde das 3. Mal falsch eingegeben}<br />
<br />
PIN-Eingabe<br />
Wiederholen<br />
{4,3;<br />
Condition:<br />
PIN wurde das 1. oder 2.<br />
Mal falsch eingegeben}<br />
Karte einziehen<br />
Fig. 5 Als eigene Use-Cases ausgelagerte alternative Courses<br />
Die Ziffern vor der Bedingung sind der Extension Point und der Return Point und definieren<br />
eindeutig den Typ des Alternative Courses. Statt Ziffern könnten im Text und in der Grafik auch<br />
Marken angegeben werden (z. B. PIN-Prüfung statt 4 – siehe unten).<br />
In der UML2 gibt es auch ein spezielles Konstrukt um Extension-Points darzustellen. Die<br />
Bedingung kann nur in Form eines Kommentars angegeben werden.<br />
Ein Konstrukt zur Darstellung von Return Points, so dass auch unterschieden werden kann, um<br />
welchen Typ von Extension es sich handelt, ist in UML2 nicht vorgesehen (könnte aber im<br />
Kommentar auch angegeben werden). Der Nachteil der Verwendung von Benannten Extension-<br />
Points ist, dass zum Zeitpunkt, zu dem man den Base-Use- Case erweitert, im Base-Use-Case eine<br />
Veränderung vorgenommen werden muss (Einführung einer Marke)<br />
191
192<br />
Akteur2<br />
extention points:<br />
PIN-Prüfung<br />
Geld abheben<br />
Geldautomat<br />
<br />
<br />
{Condition: PIN wurde<br />
das 3. Mal falsch eingegeben.<br />
extention point: PIN-Prüfung}<br />
PIN-Eingabe<br />
Wiederholen<br />
{Condition: PIN wurde das 1.<br />
oder 2. Mal falsch eingegeben.<br />
extention point: PIN-Prüfung}<br />
Karte einziehen<br />
Fig. 6 Als eigene Use-Cases ausgelagerte alternative Courses dargestellt in UML-<br />
Notation<br />
Die UML-Notation lässt auch zu, dass man nicht nur die Marke, sondern zusätzlich die Aktion<br />
selbst hinschreibt, also: statt "Intentionen point: PIN-Prüfung" -> "Intentionen point PIN-Prüfung:<br />
Das System überprüft, dass die PIN die richtige PIN zur Karte ist." oder "Intentionen point 4: Das<br />
System überprüft, dass die PIN die richtige PIN zur Karte ist."<br />
Auslagern von nicht optionalen Teilen von Use-Cases<br />
Wird ein Use-Case zu lang, können auch Teile gesondert beschrieben werden. In [Co01] werden<br />
gesondert zu beschreibende Teile unterstrichen und als gesonderter Use-Case beschrieben, der eine<br />
Include-Beziehung zum Base Use-Case hat. Durch diese Vorgehensweise können sehr große Use-<br />
Case Diagramme entstehen. Wir schlagen deshalb vor, gesondert zu beschreibende Teile auch im<br />
gleichen Use-Case zu beschreiben (durch Anhangen des in Klammern geschriebenen Wortes<br />
"verfeinert" am Ende der Aktion). Weiter unten kann dann die verfeinerte Aktion als unconditional<br />
insertion beschrieben werden. Extension und Return Points müssen nicht angegeben werden, da ja<br />
schon im Base Use-Case die Stelle angegeben ist, von wo aus mit der unconditional insertion<br />
fortgefahren wird, und nach der Abarbeitung der unconditional insertion wird natürlich genau nach<br />
der Aussprungstelle fortgefahren.<br />
Eine Auslagerung in einen gesonderten Use-Case sollte dann erfolgen, wenn dieser<br />
Anwendungsfall auch noch von anderen Use-Cases benötigt wird. Durch die Auslagerung als<br />
gesonderter Use-Case werden somit Redundanzen vermieden.
Use-Cases auf verschiedenen Ebenen<br />
In [Co01] werden mehrere Ebenen von Use-Cases definiert.<br />
Fig. 6 Levels von Use-Cases<br />
Die Use-Cases der oberen Ebenen können dabei durch Use-Cases der unteren Ebenen definiert<br />
werden. Es gibt Ziele (Goals), die auf ganz hohen Ebenen anzusiedeln sind. Das oberste Ziel wäre:<br />
Führe eine Firma, so dass Gewinn erzielt wird. Ein weiter tiefer angesiedeltes Ziel wäre: Aufträge<br />
abwickeln von der Angebotsschreibung bis zur Fakturierung und Verbuchung in der Buchführung.<br />
Diese oberen Ziele sind nach [Co01] die Summary-Goals und befinden sich auf dem White-Level,<br />
der wiederum in Kite- und Cloud-Level geteilt ist.<br />
Die von uns weiter oben ausführlich beschriebenen Use-Cases beschreiben alle die<br />
Kommunikation mit dem System. Dieser Level wird in [Co01] Blue bzw. Sea-Level genannt. Die<br />
zugehörigen Ziele heißen User-Goals. Die Use-Cases auf diesem Level werden dadurch<br />
charakterisiert, dass sie eine von der Auslösung durch den Trigger bis zum Erreichen des Business<br />
Results oder bis zum Abbruch eine Sitzung am Rechner (z. B Auftrag erfassen) bzw. einen<br />
ununterbrochenen Arbeitsfluss im Rechner darstellen (z. B. alle Pakete sortieren).<br />
193
194<br />
Unter dieser Schicht befindet sich noch der Indigo- bzw. Underwater-Level und der Black- bzw.<br />
Clam-Level. Hier sind Subfunctions angesiedelt, für die aber normalerweise keine Beschreibung<br />
mehr existiert.<br />
Weiter Möglichkeiten der Beschreibung von Use-Cases<br />
Wie können wir Use-Cases beschreiben?<br />
- ganz normaler Text<br />
- strukturierter Text (pro Satz eine Aktion)<br />
- Workflow- oder Aktivitätsdiagramme. Diese Diagramme sind besonders geeignet zur<br />
Darstellung der Abläufe im Kite- oder Cloud-Level (Siehe Kapitel Workflows).<br />
- Zustandsdiagramme. Da ein Zustandsdiagramm im Grunde genommen das gleiche ist wie<br />
ein Aktivitätsdiagramm sind Use-Cases natürlich auch mit Zustandsdiagrammen<br />
beschreibbar. Als Beispiel sei hier auf das Zustandsdiagramm des Use-Cases Authentifizierung<br />
in [JRHZQ04], Kap. 11.3.1 verwiesen.<br />
- Sequenzdiagramme. Diese Art von Beschreibung stellt schon die Kommunikation zwischen<br />
Klassen dar – sie ist deshalb nicht als Diskussionsgrundlage zwischen dem normalen<br />
Benutzer ohne jegliches IT-Wissen und dem Systementwickler geeignet, sondern führt<br />
schon hin zum Design des Systems.<br />
- Kommunikationsdiagramme. Hier gilt das gleiche wie für Sequenzdiagramme.<br />
Literatur<br />
[Co01] Cockburn, Alistair; Writing effective use cases; Addison Wesley, 2001<br />
[MOW03] Metz, Pierre; O’Brian, John; Weber, Wolfgang; Specifying Use Case Interaction:<br />
Types of Alternative Courses.<br />
In: Journal of Object Technology, März 2003<br />
[MOW03] Metz, Pierre; O’Brian, John; Weber, Wolfgang; Specifying Use Case Interaction:<br />
Clarifying Extension Points and Points of Return.<br />
In: Journal of Object Technology, März 2004<br />
[JRHZQ04] Jeckle; Rupp; Hahn; Zengler; Queins; UML2 glasklar; Hanser-Verlag; 2004
6 Der Qualitätsbegriff und die Qualitätskriterien für Software<br />
Es gibt 5 verschiedene Ansätze für die Qualität von Software:<br />
• Transzendent: Qualität ist eine ganzheitliche Eigenschaft. Sie lässt<br />
sich nur durch Erfahrung bewerten. (Für die Praxis untauglich:<br />
"Programmierer ist Künstler").<br />
• Produktbezogen: Qualität ist eine genau spezifizierte Größe, die das<br />
Produkt beschreibt. (Kundeninteresse wird bei diesem Ansatz leicht<br />
vernachlässigt). Sicht: Entwickler.<br />
• Benutzerbezogen: Qualität wird durch den Produktbenutzer<br />
festgelegt. Produkte, die das Benutzerbedürfnis am besten befriedigen,<br />
sind qualitativ hochwertig. (Das Verkaufsergebnis als Indikator ist<br />
problematisch). Sicht: Vertrieb/Verkauf.<br />
• Prozessbezogen: Qualität entsteht durch den richtigen<br />
Erstellungsprozess. Dieser muss spezifiziert und kontrolliert werden.<br />
Dadurch wird Ausschuss und Nachbesserung vermieden und die<br />
wandelnden Kundenbedürfnisse berücksichtigt. Sicht: Fertigung.<br />
• Kosten/Nutzen bezogen: Qualität ist eine Funktion von Kosten und<br />
Nutzen. Ein Qualitätsprodukt ist ein Erzeugnis, das zu einem<br />
akzeptablen Preis einen bestimmten Nutzen bringt. Sicht: Finanzen<br />
Allgemeine Definitionen:<br />
Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes<br />
oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener<br />
Erfordernisse bezieht. (Deutsche Industrie-Norm DIN 55350, Teil 11)<br />
Qualität ist die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung,<br />
festgelegte und vorausgesetzte Erfordernisse zu erfüllen. (ISO 8402)<br />
6.1 Die Qualitätseigenschaften <strong>beim</strong> fertigen Produkt:<br />
Richtigkeit:<br />
Das Softwaresystem arbeitet gemäß der widerspruchsfreien<br />
Spezifikation.<br />
Zuverlässigkeit:<br />
195
196<br />
Sei fw(t) die Wahrscheinlichkeit, dass im Zeitraum 0 bis t im System ein Fehler<br />
auftritt, so ist R(t) = 1 - fw(t) die Zuverlässigkeitsfunktion des Systems. Geht R(t)<br />
auch für große t gegen 1, so nennt man das System zuverlässig.<br />
Effizienz:<br />
Das System nutzt die Ressourcen bestmöglich aus. Hardware wird bei voller<br />
Erfüllung des Aufgabenkatalogs sparsam verwendet. Ablaufzeit ist möglichst<br />
optimal.<br />
Robustheit:<br />
Die Auswirkung eines Bedienungsfehlers ist umgekehrt proportional der<br />
Häufigkeit seines Auftretens.<br />
Funktionsumfang - Funktionserfüllung:<br />
Funktionsumfang ist dann in Ordnung, falls der Funktionsumfang des Systems<br />
gleich dem geplanten Funktionsumfang ist.<br />
Benutzerkomfort:<br />
Ist dann erfüllt, wenn dem Benutzer ein angenehmes , effizientes und fehlerarmes<br />
Benutzen möglich ist und der Lernaufwand zur Bedienung des Systems gering ist.<br />
Änderbarkeit:<br />
Anpassungen und Fehlerbehebung sind schnell und ohne Folgefehler<br />
durchführbar.<br />
Portabilität:<br />
Das System kann leicht in neue Hardwareumgebungen übertragen<br />
werden.<br />
Wiederverwendbarkeit:<br />
Systemteile sind wiederverwendbar, wenn sie aufgrund ihrer Spezifikation in<br />
unterschiedlichen Softwaresystemen als Bausteine verwendet werden können.<br />
Generell: Die Wiederverwendung ist mit weniger Aufwand verbunden als die<br />
Neuentwicklung.<br />
Je nach Interessenlage ergeben sich Unterschiede in der Bewertung der Wichtigkeit<br />
von Qualitätseigenschaften <strong>beim</strong> fertigen Produkt:<br />
6.1.1 Wichtige Kriterien aus Benutzersicht
Richtigkeit<br />
Zuverlässigkeit<br />
Effizienz<br />
Robustheit<br />
Funktionsumfang - Funktionserfüllung<br />
Benutzerkomfort<br />
6.1.2 Wichtige Kriterien aus Entwicklersicht<br />
Änderbarkeit<br />
Portabilität<br />
Wiederverwendbarkeit<br />
Auf die Softwarequalität haben unterschiedliche Faktoren Einfluss:<br />
Bild 1: Einflussfaktoren auf die Qualität<br />
6.2 Qualitätsmanagement<br />
197
198<br />
Will man Softwarequalität erreichen, so muss der gesamte Softwareentwicklungsprozess<br />
diese Kriterien im Auge haben. Es muss darauf geachtet werden, dass der<br />
gesamte Entwicklungsprozess in systematischer Art und Weise die<br />
Qualitätskriterien unterstützt. Eine Art "Qualitätsagentur" am Ende des<br />
Entwicklungsprozesses, die das Produkt mit "Qualität" versieht ist ein unmögliches<br />
Unterfangen.<br />
Zur systematischen Erarbeitung von Softwarequalität gehört:<br />
1. Eine Entwicklungsmethodik die folgendes erreicht:<br />
Adäquate Modellierung des Problembereichs<br />
Beherrschung der Problemkomplexität<br />
2. Einsatz von bewährten Systemarchitekturen<br />
Bewährte Analysemuster aufdecken und benutzen<br />
Bewährte Entwurfsmuster einsetzen, finden und dokumentieren<br />
Vorhandene bewährte Klassen- und Funktionsbibliotheken verwenden, ggf.<br />
erweitern<br />
Vorgegebene "Frameworks", d.h. vorgefertigte Anwendungsbereiche,<br />
sinnvoll einsetzen<br />
3. Den Benutzer ernsthaft bei der Festlegung der Anforderungen beteiligen<br />
4. Konsequente Projektführung im Hinblick auf die Qualität der Software<br />
Um zu überwachen, ob ein Qualitätsziel <strong>beim</strong> Endprodukt erreicht worden ist,<br />
muss man Metriken für dieses Qualitätsmerkmal haben. Wir werden im Laufe der<br />
Vorlesung einige solcher Maße besprechen, aber insgesamt ist die Lage durch<br />
weitgehendes Fehlen der geeigneten allgemein einsetzbaren Metriken<br />
gekennzeichnet.<br />
Deshalb ist es im Softwareentwicklungsprozess meist erfolgreicher bereits im<br />
konstruktiven Prozess die Qualität des Endproduktes weitgehend zu sichern, als<br />
sich auf die Überprüfung nach Fertigstellung zu verlassen.<br />
Diese konstruktive Qualitätssicherung ist gekennzeichnet durch:<br />
Maßnahmen, die bereits in den Phasen:<br />
Analyse<br />
Definition<br />
Entwurf<br />
Implementierung<br />
systematisch und permanent stattfinden.<br />
Hierzu können gehören:<br />
• Prototyping zur Einbeziehung des Benutzers<br />
• Einsatz bewährter Analyse- und Entwurfsmuster
• Verwenden vorgefertigter Anwendungsframeworks<br />
generell:<br />
• Wiederverwendung zuverlässiger vorhandener Softwarelösungen für Teile<br />
des Systems (Klassenbibliotheken usw.)<br />
• Einsatz von Werkzeugen zur formalen Spezifikation (Z oder VDM oder<br />
Petrinetze)<br />
• Bewährte Abwandlungen des "Wasserfallmodells" anwenden:<br />
• V-Modell<br />
• Prototyping<br />
• Spiralmodell ( hier ist insbesondere die Risikoanalyse wichtig mit der<br />
Überprüfung, vor jeweils einer neuen Entwicklungsrunde, ob<br />
Wiederverwendung günstiger ist)<br />
• Evolutionäre Entwicklung ("Versioning")<br />
6.2.1 Methoden und Werkzeuge des Qualitätsmanagements<br />
Das Softwarequalitätsmanagement hat drei Hauptaufgaben:<br />
• Qualitätssicherung ( durch Einrichten eines Systems von Verfahren und<br />
Regeln ("Standards") zur Entwicklung qualitativ hochwertiger Software)<br />
• Qualitätsplanung ( durch Anpassen der Verfahren und Regeln ("Standards")<br />
an das jeweilige Projekt )<br />
• Qualitätskontrolle ( durch Entwickeln von Vorgehensweisen, die sicherstellen,<br />
dass die wichtigen Verfahren und Regeln (Standards) im<br />
Softwareentwicklungsprozess auch wirklich eingehalten werden )<br />
6.2.2 Die Bedeutung von Qualitätsstandards<br />
Das Qualitätsmanagement muss unabhängig vom Entwicklungsteam eine<br />
Überprüfung des Softwareentwicklungsprozesses durchführen. Ein internationaler<br />
Standard für die Entwicklung von Qualitätsmanagementsystemen ist ISO 9000,<br />
und speziell für den Bereich der Softwareentwicklung: ISO 9000-3.<br />
Es ist sinnvoll daraus eigene Standards für den Qualitätssicherungsprozess zu<br />
entwickeln, nämlich:<br />
Produktstandards (z.B. Standards für die Dokumente im Entwicklungsprozess,<br />
wie die Anforderungsdefinition, die Gestalt der Kommentare, die<br />
systematische und sinnvolle Variablenbenennung, Festlegung bestimmter<br />
Programmierstandards, um die Benutzung von negativen Eigenheiten von<br />
Programmiersprachen zu vermeiden)<br />
199
200<br />
Prozessstandards (z.B. die Festlegung, wie bestimmte Phasen abzulaufen<br />
haben und wie die Dokumente abzufassen sind, die in diesen Phasen<br />
geschaffen werden)<br />
Die beiden Arten von Standards hängen eng zusammen, da die Prozessstandards in<br />
vielen Fällen die Voraussetzung dafür sind, dass bestimmte Produktstandards<br />
erreicht werden.<br />
Gründe für das Beachten von Softwarestandards:<br />
• Sie bilden die Zusammenstellung geeigneter Entwicklungspraktiken<br />
• Sie stellen die Basis für die Qualitätskontrolle dar<br />
• Sie stellen sicher, dass das Auswechseln von Software-Entwicklern möglich<br />
wird<br />
6.2.3 Die Problematik von Standards in der Softwareentwicklung<br />
Wenn sehr viele Regeln zur Softwareentwicklung in dicken Handbüchern<br />
vorhanden sind, wird das kaum eine große Begeisterung bei den Entwicklern<br />
hervorrufen. Deshalb sollten nicht zu viele Festlegungen getroffen werden, sondern<br />
nur wirklich sinnvolle "Standards" gefordert werden.<br />
Insbesondere sollte beachtet werden, dass die Zahl der Formulare, die während der<br />
Softwareentwicklung auszufüllen sind nicht zu groß wird.<br />
Eine sinnvolle Vorgehensweise des Qualitätsmanagers beinhaltet:<br />
1. Für alle bürokratischen Standards, sollte er Werkzeuge zur Verfügung stellen<br />
2. Die Standards sollten zwar gut ausgewählt und beständig sein, aber nicht für<br />
ewig aufgestellt werden. Der bessere Standard muss den guten ersetzen<br />
3. Die Entwickler müssen bei der Erarbeitung von Standards beteiligt sein und<br />
jede Festlegung sollte stichhaltig im "Qualitäts-Handbuch" begründet sein.<br />
6.2.4 Die Dokumentation von Software<br />
Um Verifikation und Validation von Software durchführen zu können, ist eine<br />
angemessene Dokumentation und eine präzise Festlegung der zu prüfenden Fälle<br />
unabdingbar. Das bereits früher behandelte V-Modell sieht hierin eine wichtige<br />
Aufgabe des Softwareentwicklungsteams (SWE), die vom Qualitätsmanager (QS)<br />
streng zu überwachen ist. Einige Qualitätskriterien nehmen direkt auf die<br />
Dokumentation bezug und werten Sie als (wichtigen) Indikator für die Qualität<br />
eines Softwareprodukts.
Kurz gesagt: Dokumentation muss korrekt, so knapp wie möglich und so<br />
umfassend wie nötig sein. Sinnvoll sind hier allgemein akzeptierte Standards in<br />
einem Software-Entwicklungsteam.<br />
6.3 Die statische Kontrolle der Qualität und anderer Softwareeigenschaften<br />
Software zeigt ihre Eigenschaften <strong>beim</strong> dynamischen Ablauf aber teilweise auch<br />
durch theoretische Kontrolle, dh. durch statische Analyse des Programmcodes oder<br />
der Entwurfsunterlagen.<br />
Als Methoden unterscheidet man hierbei::<br />
• Messung<br />
• Reviews<br />
• Formale Verifikation<br />
6.3.1 Softwaremaße-Softwaremessung<br />
Im Gegensatz zur Messung in der Physik besitzt man in der Softwaretechnik keine<br />
allgemein festgelegten Grundmaße. Das gilt speziell für die Qualitätskriterien bei<br />
Software, mit Hilfe derer man die Messergebnisse ausdrücken und vergleichen<br />
könnte. Um trotzdem Aussagen über die Qualität von Softwareprodukten machen<br />
zu können, werden Hypothesen aufgestellt, die eine Reihe messbarer Größen<br />
quantitativ (in Gestalt einer Formel) als Maß für ein bestimmtes Qualitätskriterium<br />
des Softwareprodukts zusammenfassen. Es ist jedoch damit fast immer nur ein<br />
Teilaspekt dieses Kriteriums erfasst und insbesondere eine subjektive Wertung der<br />
Bedeutung einzelner messbarer Größen für die Qualität des Produktes damit<br />
verbunden.<br />
Metriken als Ausdruck für bestimmte Qualitätseigenschaften eines<br />
Softwareprodukts sollten also immer mit der gehörigen Vorsicht verwendet und<br />
bestenfalls als Maß für einen Teilaspekt der Qualität des Softwareprodukts<br />
gewertet werden. Meist weisen die Ergebnisse von Softwaremessungen nur bei<br />
einem Vergleich auf Qualitätsabweichungen unterschiedlicher Software hin.<br />
Um überhaupt Aussagen über Software machen zu können, braucht man Maße für<br />
Software-Eigenschaften. Einige davon betreffen unmittelbar die Qualität von<br />
Software. Andere tauchen in Formeln für die Qualität eines Softwareprodukts auf<br />
und dienen damit mittelbar der Qualitätsbestimmung. So wird ein Großteil der<br />
Maße für Qualitätsaussagen über die gemessene Software verwendet. Es gibt aber<br />
auch solche, die dazu benutzt werden, den Aufwand bei der Erstellung von<br />
201
202<br />
Software zu schätzen oder einfach nur Größenvergleiche unter verschiedenen<br />
Softwareprodukten anzustellen.<br />
6.3.1.1 Die Function-Point Methode<br />
Diese Messmethode ist besonders herauszustellen, weil sie ein Maß liefert, das<br />
bereits zum Zeitpunkt der Erstellung der Anforderungsdefinition festgelegt werden<br />
kann und somit auch dazu dienen kann, den Aufwand für die Softwareerstellung<br />
zu einem sehr frühen Zeitpunkt festzustellen.<br />
In ihr werden Function-Points FP unter Beachtung bestimmter Einflussfaktoren<br />
mittels einer durch praktische Experimente verifizierten Formel berechnet:<br />
FP = UFP * TCF<br />
Die Größe UFP ( "ungewichtete Function-Points") ergibt sich dabei<br />
folgendermaßen:<br />
UFP = f1*I + f2*O + f3*L + f4*F + f5*A<br />
I Anzahl unterschiedlicher Eingabedatentypen<br />
O Anzahl unterschiedlicher Ausgabedatentypen<br />
L Anzahl unterschiedlicher interner logischer Datenbestände<br />
F Anzahl unterschiedlicher externer Datenbestände<br />
("Interfaces")<br />
A Anzahl unterschiedlicher Abfragen<br />
fi sind Bewertungsfaktoren, die sich nach den Kriterien einfach, mittel, komplex<br />
nach folgendem Schema ergeben (Erfahrungswerte!):<br />
Merkmal einfach mittel komple<br />
(e) (m) x (k)<br />
I 3 4 6<br />
O 4 5 7<br />
L 7 10 15<br />
F 5 7 10<br />
A 3 4 6<br />
Die Bewertungsfaktoren fi liegen in dem angegebenen Bereich. Für den<br />
durchschnittlichen UFP-Wert (bei mittlerer Schwierigkeit der Daten) gilt:<br />
UFPm = 4*Im + 5*Om + 10*Lm+ 7*Fm + 4*Am
wobei Im, Om, ... usw. die Anzahl solcher Datentypen mittlerer Schwierigkeit<br />
dieser Art ist.<br />
Analog ergeben sich UFPe und UFPk<br />
Der genaue UFP-Wert ergibt sich zu: UFP = UFPe + UFPm + UFPk<br />
Die Einschätzung e, m oder k geschieht nach folgenden Richtlinien:<br />
Eingaben:<br />
Anzahl unterschiedlicher Datenelemente (e):(1-5) (m): 6-10 (k): >10<br />
Prüfung der Daten: (e) : formal (m): formal + logisch (k):<br />
formal+logisch+Dateizugriff<br />
Bedienerführung bei Eingabe (e): gering (m): teilweise, in der Handhabung (k):<br />
intensiv extern<br />
Ausgaben:<br />
Ebenfalls wieder Bewertung nach Anzahl unterschiedlicher Datenelemente<br />
Anzahl unterschiedlicher Zeilen in Listen<br />
Anzahl Wiederholgruppen<br />
... usw. Hier sind Erfahrungswerte einzusetzen. Wenn nicht vorhanden, dann<br />
mittlere Bewertungsfaktoren verwenden.<br />
Der "Technical-Influence-Factor" TCF ergibt sich folgendermaßen:<br />
TCF = 0.65 + 0.01*DI<br />
, wobei DI bedeutet: "Degree of Influence" also "Einflussgrad".<br />
Der Einflussgrad kann zwischen 1 und 5 liegen und zwar werden folgende 14<br />
Faktoren der Systemcharakteristik berücksichtigt.<br />
203
204<br />
Deren Summe ergibt den Wert DI:<br />
Faktor Charakteristik DI<br />
C1 Datenkommunikation<br />
C2 Verteilte Verarbeitung<br />
C3 Performance<br />
C4 Intensive Systemnutzung<br />
C5 Transaktionsrate<br />
C6 On-Line Dateneingabe<br />
C7 Benutzeroberfläche<br />
C8 Online Änderungen<br />
C9 Komplexe Verarbeitung<br />
C10 Wiederverwendung<br />
C11 Einfache Installation<br />
C12 Operationale Einfachheit<br />
C13 Externe Einbindung<br />
C14 Änderungsfreundlichkeit<br />
DI-Summe:<br />
Je nach Stärke des Einflusses der jeweiligen Charakteristik wird der Wert DI<br />
zwischen 0= keinen Einfluss und 5 = starken Einfluss festgelegt. Maximal kann<br />
sich also ein DI-Wert von 70 (in der Summe) ergeben.<br />
TCF liegt also zwischen 0.65 und 1.35.<br />
Maximal kann also der Wert von FP durch TCF um 35 % nach oben und unten<br />
verändert werden.<br />
Beispiel 1 : Ein System mit drei internen logischen Datenbeständen L. Einem<br />
externen Datenbestand (Interface) F. Sechs Eingabedatentypen I, acht<br />
Ausgabedatentypen O und dreizehn unterschiedliche Abfragen.<br />
Komponenten einfach mittel komplex Total<br />
L(logische interne Datenbestände)<br />
1 x 7 = 7 2 x 15 = 30 37<br />
F (Interfaces) 1 x 10 = 10 10<br />
I (Eingabedatentypen) 2 x3 = 6 3 x 4 =12 1 x 6 = 6 24<br />
1 vgl.:Horst Zuse: A Framework of Software Measurement, S.495f, Walter de Gruyter, 1998
O(Ausgabedatentypen) 5x 4=20 3x5 = 15 35<br />
A(Abfragen) 6 x 3 = 18 6x4 = 24 1 x 6 = 6 48<br />
Summe 156<br />
Die Einflussfaktoren (TCF):<br />
Faktor Charakteristik DI<br />
C1 Datenkommunikation 4<br />
C2 Verteilte Verarbeitung 3<br />
C3 Performance 5<br />
C4 Intensive Systemnutzung 4<br />
C5 Transaktionsrate 5<br />
C6 On-Line Dateneingabe 5<br />
C7 Benutzeroberfläche 1<br />
C8 Online Änderungen 4<br />
C9 Komplexe Verarbeitung 2<br />
C10 Wiederverwendung 2<br />
C11 Einfache Installation 1<br />
C12 Operationale Einfachheit 4<br />
C13 Externe Einbindung 0<br />
C14 Änderungsfreundlichkeit 3<br />
DI-Summe: 43<br />
Insgesamt ergibt sich in diesem Fall: FP = 156 * (0.65 + 0.01*43) = 168.48<br />
Wir können also feststellen, dass die Technische Komplexität TCF in diesem Fall<br />
den Function-Point-Wert, zunächst ausgedrückt durch den UFP-Wert = 156, auf<br />
den endgültigen Wert von<br />
FP = 168.48 angehoben hat.<br />
6.3.1.2 Halstead-Maße<br />
Mit den Halstead-Maßen wurde der Versuch unternommen, aufbauend auf einem<br />
neuen Maß für die Größe von Softwareprodukten, eine Theorie der Softwareentwicklung<br />
aufzustellen, die insbesondere die Wertung der verwendeten<br />
Programmiersprache mit einschließt. Außerdem kann mittels der Halstead-Maße<br />
eine Aussage über die Schwierigkeit der Softwareentwicklung gemacht werden.<br />
Anzahl der unterschiedlichen Operatoren: n1<br />
205
206<br />
Anzahl der unterschiedlichen Operanden: n2<br />
Anzahl des Auftretens von Operatoren: N1<br />
Anzahl des Auftretens von Operanden: N2<br />
Primitives Beispiel zur Veranschaulichung der Maße (Programmiersprache C++, C<br />
):<br />
void tausche(double &x, double &y)<br />
{<br />
double z;<br />
z=x;<br />
x=y;<br />
y=z;<br />
}<br />
Operatoren Anz. Auftreten Operanden Anz. Auftreten<br />
void 1 x 3<br />
( ) 1 y 3<br />
double 3 z 3<br />
& 2<br />
= 3<br />
; 4<br />
{ } 1<br />
, 1<br />
n1 = 8 N1 = 16 n2 = 3 N2 = 9<br />
Abgeleitete Maße:<br />
Größe des Vokabulars: n = n1 + n2<br />
Länge der Implementierung: N = N1 + N2 (1)<br />
Im Beispiel:<br />
n = 11 (Größe des Vokabulars)
N = 25 (Länge der Implementierung)<br />
Die Programmgröße, auch Volumen genannt, ist folgendermaßen definiert:<br />
Programmgröße (Volumen): V = N*log(n) (2)<br />
Der Name erklärt sich aus folgender Überlegung:<br />
Die n unterschiedlichen Worte können in log(n) Bits kodiert werden. Das<br />
Informationsvolumen des gesamten Programms mit insgesamt N Operatoren und<br />
Operanden kann also mit V Bits dargestellt werden.<br />
Die Größe V ist also recht gut als Maß für den Umfang eines Softwareprodukts<br />
geeignet und kann als Ersatz und zur Präzisierung des recht willkürlichen Maßes<br />
"Lines of Code" (LOC) verwendet werden.<br />
Für unser Beispiel ergibt sich<br />
V = 25 * log(11) = 25 * 3.5 = 87.5<br />
Hinweis: In Sprachen mit reichhaltigem Operatorenangebot, die dem Problem<br />
angepasst sind, wird V klein sein, andernfalls ist V groß. Die minimale Größe für<br />
die Programmgröße V wird mit V* bezeichnet.<br />
Sie tritt auf, falls die Funktionen, die ein Programm bietet, voll als Befehle in der<br />
verwendeten Programmiersprache vorhanden sind.<br />
In diesem Fall braucht i.a. kein Operand und kein Operator wiederholt zu werden.<br />
V* = (n1 * + n2 * ) * log(n1 * + n2 *) (3)<br />
In der Idealsprache braucht nur noch die gewünschte Funktion aufgerufen und der<br />
erhaltene Wert zugewiesen zu werden. Also existieren in der "Idealsprache" für<br />
eine Problemlösung nur noch 2 verschiedene Operatoren<br />
Es ergibt sich im Idealfall also:<br />
V* = (2 + n2 * ) * log(2 + n2 *) (4)<br />
Im Beispiel ergäbe sich:<br />
gegenüber<br />
V* = (2 + 3) * log(5) = 5 * log( 5 ) = 5 * 2.32 = 11.6<br />
V = 25 * log(11) = 25 * 3.5 = 87.5<br />
207
208<br />
Definition:<br />
Der Level L ist definiert als:<br />
L = V* / V (5)<br />
Der Level hängt von der Programmiersprache ab. Im Idealfall ist der Level L = 1,<br />
real ist<br />
L < 1.<br />
Im Beispiel gilt:<br />
L = 11.6 / 87.5 = 0.133<br />
Ein Maß für die Schwierigkeit der Implementierung D (difficulty) ist definiert als:<br />
D = 1/L (6)<br />
Im Beispiel ergibt sich:<br />
D = 7.52<br />
Der Aufwand E (effort) ist definiert als:<br />
E = V / L = V * D (7)<br />
Im Beispiel ergibt sich der Wert:<br />
E = 87.5 * 7.52 = 658.0<br />
Einsetzen von (5) in (7) ergibt das sehr aussagekräftige Resultat:<br />
E = V2 / V* (8)<br />
Da der Wert V * für die hypothetische, ideal geeignete Programmiersprache sich nur<br />
sehrgeringfügig mit dem wachsenden Programmumfang verändert, besagt die<br />
Formel (8) in etwa:<br />
Der Aufwand zur Codierung eines Programms steigt quadratisch mit dem<br />
Programmvolumen.
Ein Softwaremaß, das als Maß für die "Komplexität" von Softwaremoduln intensiv<br />
verwendet wird, ist das von Mc Cabe. Bei genauerer Analyse stellt sich heraus,<br />
dass man dieses Maß als Maß für den Aufwand eines sinnvollen Tests also als Maß<br />
für die Testkomplexität verwenden kann, denn (grob gesprochen) gibt das Mc<br />
Cabe-Maß die Mindestzahl der Testläufe an, die benötigt werden, um einen<br />
sorgfältige Prüfung eines Moduls durchzuführen. In einem Modul ohne<br />
Programmschleifen, gibt das Mc Cabe Maß die Anzahl der Pfade durch das<br />
Programm an. Sind Schleifen vorhanden, so müssten streng gesprochen unendlich<br />
viele Testläufe durchgeführt werden und das Mc Cabe Maß gibt nur an, wieviel<br />
Läufe mindestens notwendig sind für einen Test, bei dem jede Schleifenbedingung<br />
mindestens einmal wahr und einmal falsch ist.<br />
6.3.1.3 Das Mc Cabe-Maß<br />
Die zyklomatische Zahl z, die Zahl der unabhängigen Pfade 1 durch den Programm-<br />
Graphen G, ist das McCabe-Maß des Programms. Für z gilt:<br />
z(G) = e - n + 2<br />
wobei gilt:<br />
e = Anzahl der Kanten des Graphen G<br />
n = Anzahl der Knoten von G<br />
Beispiel:<br />
1 Ein Pfad durch den Programmgraphen ist unabhängig, wenn er mindestens eine Kante enthält, die in keinem<br />
anderen Pfad enthalten ist<br />
209
210<br />
Hier gilt: z(G) = 10 - 8 + 2 = 4<br />
d.h. es existieren 4 unabhängige Pfade durch den Programmgraphen G.<br />
Die Pfade:<br />
1) < 2,4,6,8,10 > 2) < 1,5 ><br />
3) < 2,3,7,8,10 > 4) < 2,4,6,8,9,8,10 ><br />
Es gilt z.B.:<br />
Der Pfad ist nicht unabhängig, weil er nur Kanten enthält, die<br />
bereits im Pfad 3) bzw. 4) enthalten sind.<br />
Folglich gilt sogar allgemein, dass alle Pfade, die die Schleife mehrfach<br />
enthalten, abhängig sind von den Pfaden 3) und 4):<br />
Der Pfad < 2,4,6,8,(9,8),(9,8),(9,8),10 > beispielsweise ist kein unabhängiger<br />
Pfad, es gilt:<br />
= Pfad 1) + 3*( Pfad 4)-Pfad 1))<br />
Die McCabe-Zahl gibt Auskunft über die Komplexität der Kontrollstruktur.<br />
Falls z(G) sehr groß ist, z.B. >>10, wird der pfad-vollständige Test sehr<br />
aufwendig.<br />
Es gibt für einfache Programm-Graphen ein vereinfachtes Verfahren, um die<br />
McCabe-Zahl zu berechnen. Es gilt nämlich:
z (G) = π + 1,<br />
wobei π die Anzahl der Verzweigungen über BOOLEschen Bedingungen ist. Im<br />
Beispiel ist π gleich 3 also ergibt sich aus obiger Formel ebenso der Wert z(G)<br />
= 4.<br />
Eine weithin akzeptierte Regel in Bezug auf das Maß von McCabe lautet:<br />
Große Programme sollten in Module zerlegt werden, wobei für jeden einzelnen<br />
Modul gelten muss, dass z(G) < 10 ist.<br />
6.3.1.4 Fan-in---Fan-out<br />
Darstellung des Flusses: (Quelle, Fluss, Ziel)<br />
Lokaler Datenfluss (A, x, B)<br />
Eingabeparameter x ist Werteparameter<br />
A ruft die Funktion B auf und erhält ein Ergebnis (B, B, A)<br />
Globaler Datenfluss: (A, DS, B)<br />
B<br />
A<br />
B<br />
A verändert eine globale Datenstruktur und B benutzt diese<br />
A<br />
A B<br />
x<br />
B<br />
211
212<br />
DS<br />
Beurteilung der Software-Architektur durch Informationsfluss-Analyse:<br />
"fan-in" Zahl der Datenflüsse, die zu einem Modul m führen: FIm<br />
"fan-out" Zahl der Datenflüsse, die von einem Modul wegführen: FOm<br />
n<br />
IF4 = ∑ ( FIi * FOi ) 2 n ist Anzahl der Module<br />
i=1<br />
IF4i = (FIi * FOi ) 2<br />
IF4 (S) ist eine Maßzahl für die Architektur des Systems S<br />
IF4m (S) ist eine Maßzahl für den Modul m im System S<br />
Beispiel:<br />
Globale Flüsse:<br />
( B, MF, C )<br />
( B, MF, D )<br />
A<br />
x x y,z<br />
B C D<br />
Masterfil<br />
e<br />
y
Modul fan-in fan-out FI * FO IF4i<br />
A 3 2 6 36<br />
B 0 3 0 0<br />
C 2 2 4 16<br />
D 2 0 0 0<br />
IF4 drückt die Kopplung der Module mit ihrer Umwelt aus:<br />
IF4(D) = IF4(B) < IF4(C)
214<br />
ausschließende Verfahren. So ist zum Beispiel eine der wirksamsten Review-<br />
Techniken die Inspektion der Testfälle eines Softwaresystems.<br />
Programminspektionen haben als Hauptziel die Entdeckung von Fehlern in der<br />
Software und beschäftigen sich weniger mit anderen Arten der Qualitätssicherung.<br />
6.3.2.1 Die Entwurfsinspektion<br />
Die Gruppe für eine Entwurfsinspektion besteht aus 3 bis 5 Teilnehmern (bei<br />
kleineren Projekten evtl. nur 2 Teilnehmern)<br />
1. Entwerfer<br />
2. Moderator<br />
3. Erfahrener Programmierer (Protokollführer für entdeckte Fehler)<br />
4. evtl. 2-3 weitere Teilnehmer (Codierer, Wartungspersonal, Mitarbeiter aus<br />
anderen Projekten)<br />
Ablauf :<br />
4 Nicht unterbrechbare Sitzung von 1-2 Stunden.<br />
4 Teilnehmer erhalten die Entwurfsunterlagen möglichst einige Tage vor der<br />
Sitzung durch den Moderator zugestellt. (Sind von den Teilnehmern<br />
durchzustudieren!)<br />
4 Anhand der Anforderungsdefinition werden die Fälle mittels des Entwurfs<br />
durchgespielt.<br />
4 Die anhand des Entwurfs zu erwartenden Ergebnisse werden daraufhin<br />
überprüft, ob sie mit den gemäß Anforderungsdefinition zu erwartenden<br />
übereinstimmen.<br />
4 Es wird ein Protokoll über entdeckte Fehler geführt.<br />
4 Über kritische Stellen des Entwurfs wird mit dem Entwerfer diskutiert.<br />
4 Auch "Schwachstellen" werden protokolliert.<br />
4 Es wird aber noch keine Fehlerkorrektur vorgenommen. Fehler werden erst<br />
(später durch den Entwerfer) bereinigt
6.3.2.2 Die Codeinspektion<br />
Die Mannschaft für eine Codeinspektion besteht aus ca. 4 Teilnehmern:<br />
1. Programmierer des vorliegenden Produkts<br />
2. Moderator<br />
3. Testspezialist<br />
4. Entwerfer<br />
Ablauf :<br />
4 Einige Stunden vor der Sitzung verteilt der Moderator die Programmliste und<br />
die Entwurfs- Spezifikation an die Teilnehmer (Durchstudieren und verstehen<br />
des Codes durch die Teilnehmer ist Voraussetzung für die Sitzung.)<br />
4 Dauer der Sitzung 1 - 2 Stunden ununterbrochen.<br />
Wichtigste Aktivitäten<br />
1. Der Programmierer erklärt die Programmlogik Schritt für Schritt gemäß der<br />
Anweisungen. Eventuell auftretende Fragen werden verfolgt. Der Moderator<br />
protokolliert die Fehler. Kritische Fälle werden eventuell durchgespielt und die<br />
Ergebnisse mit denen gemäß der Entwurfsspezifikation verglichen.<br />
2. Die vorliegende Programmliste wird anhand einer Checkliste häufiger<br />
Fehler analysiert (evtl. schon vorher von jedem Teilnehmer)<br />
Der Moderator achtet darauf, dass sich auf das Entdecken von Fehlern beschränkt<br />
wird und protokolliert diese. Die Korrektur wird später durch den Programmierer<br />
vorgenommen.<br />
215
216<br />
Check-Liste für die Codeinspektion<br />
" | " Bedeutet:Fehler können vom Compiler normalerweise nicht gefunden werden,<br />
d.h. diese Punkte sind besonders wichtig für Nachprüfungen<br />
Variablenbenutzung<br />
1.Werden Variable angesprochen, die nicht initialisiert wurden?<br />
| 2.Werden die Indexgrenzen für Felder (Arrays) eingehalten?<br />
3.Sind die Indizes vom richtigen Typ?<br />
| 4.Werden Pointer richtig verwendet?<br />
5.Stimmen formale Parameter und die Argumente für die Unterprogramme im<br />
Typ überein?<br />
6.Ist die Anzahl der Argumente gleich der Argumente der formalen Parameter bei<br />
Unterprogrammen?<br />
Variablenvereinbarung<br />
1.Sind alle Variablen vereinbart?<br />
| 2.Werden Felder richtig initialisiert?<br />
| 3.Gibt es Variable mit ähnlichen Namen?<br />
| 4.Sind die globalen Variablen an der richtigen Stelle vereinbart?<br />
Berechnungen<br />
1.Werden Berechnungen mit nicht arithmetischen Variablen durchgeführt?<br />
2.Gibt es Berechnungen, an denen Daten unterschiedlichen Typs beteiligt sind?<br />
| 3.Kann es Über- oder Unterlauf in Zwischenergebnissen geben?<br />
| 4.Kann irgendwo eine Division durch Null auftreten?<br />
| 5.Wo können unvertretbare Ungenauigkeiten durch die Dualdarstellung auftreten?<br />
| 6.Wurde die Priorität der Operationen beachtet?<br />
| 7.Sind die ganzzahligen Divisionen korrekt?<br />
Vergleiche<br />
1.Werden Werte verschiedenen Typs miteinander verglichen?<br />
| 2.Sind die Vergleichsoperationen korrekt verwendet?<br />
| 3.Sind die Booleschen Ausdrücke korrekt?<br />
| 4.Treten überkomplizierte Boolesche Ausdrücke auf?
Programmablauf<br />
| 1.Werden bei Fallunterscheidungen alle Fälle berücksichtigt?<br />
| 2.Wird jede Schleife richtig beendet? (Endlosschleife möglich?)<br />
| 3.Hört das Programm nach endlich vielen Schritten auf?<br />
| 4.Werden Schleifen aufgrund der Eingangsbedingung nicht ausgeführt?<br />
| 5.Ist die Schrittzahl in zählenden Schleifen um eins zu hoch oder zu niedrig?<br />
Schnittstellen<br />
1.Werden Eingabeparameter im Unterprogramm verändert?<br />
2. Werden Konstante auf der Position von Variablenparametern als Argument<br />
übergeben?<br />
| 3.Ist die Benutzung globaler Variablen über alle Module konsistent?<br />
4.Sind Parameter und Argumente in bezug auf Typ und Argument konsistent?<br />
Ein- und Ausgabe<br />
1.Werden die Dateien richtig geöffnet und geschlossen?<br />
2.Sind die Dateien richtig vereinbart?<br />
3.Werden Zeilenende und Dateiende korrekt abgefragt?<br />
Weitere Prüfungen<br />
1.Gibt es nicht angesprochene Variablen im Programm?<br />
2.Erhält man bei der Übersetzung Warnungsmeldungen?<br />
3.Werden die Eingabedaten auf Gültigkeit geprüft?<br />
| 4.Fehlen bestimmte Funktionen oder Prozeduren?<br />
6.3.3 Formale Verifikation<br />
Jedes geschaffene Softwaresystem hat die Aufgabe, aus bestimmten<br />
Anfangsbeziehungen unter den Daten ("precondition") bestimmte Endbeziehungen<br />
("postcondition") herbeizuführen. In der Systemspezifikation werden diese<br />
Transformationen, die das System leisten soll, festgelegt.<br />
Die formale Verifikation eines Systems verläuft nun so, dass durch ganz formales<br />
Anwenden von Regeln über die Wirkungsweise der verwendeten<br />
Algorithmenelemente der Beweis geführt wird, dass das System die gewünschten<br />
Transformationen leistet. Gelingt dieser Beweis, so hat man damit einen strengen<br />
Beweis, dass das System exakt die Spezifikation erfüllt, also korrekt ist.<br />
217
Die Regeln über die Wirkung der Algorithmenbausteine sind sehr elementarer Art,<br />
so dass man sicher sein kann, dass sie in allen gängigen Programmiersprachen so<br />
festgelegt sind [s. Hoare69]. Die Evidenz dieser Axiome ist teilweise<br />
offensichtlich oder kann leicht eingesehen werden.<br />
Umgekehrt kann man auch so formulieren, dass die Axiome im Hinblick auf die<br />
verwendete Implementierungssprache und den eingesetzten Computer festlegen,<br />
dass die angegebene Wirkungsweise mindestens garantiert sein muss.<br />
Die Verifikationsregeln sind formuliert wie ein Vertrag: Wenn eine bestimmte<br />
Voraussetzung erfüllt ist, dann führt das Algorithmenelement eine bestimmte<br />
Beziehung (die "precondition") in eine bestimmte andere Beziehung (die<br />
"postcondition") über.<br />
Die Verifikationsregeln<br />
Die nachstehend beschriebene Verifikationsmethode entspricht dem Durchlaufen<br />
der Beweisregeln von der Folgerung zur Voraussetzung. Als Ausgangspunkt <strong>beim</strong><br />
Beweis dient jeweils die zu beweisende Systemeigenschaft (die<br />
Systemspezifikation).<br />
Zum Bewahren der Übersicht auch bei größeren Systemen, werden die Regeln als<br />
Teilbaum formuliert und ein Beweisbaum wird konstruiert (s.u.).<br />
Für die Spezifikation der Wirkung wird folgende Schreibweise gewählt:<br />
P { A } Q<br />
P = precondition<br />
Q = postcondition<br />
A = Aktion (Algrithmenelement, Komponente oder System)<br />
218<br />
1. Regel für die Wertzuweisung: v := W<br />
Es gilt: P {v:=W} Q (Folgerung)<br />
falls erfüllt ist: P --> [Q v W] (Voraussetzung)<br />
d.h., aus der precondition P folgt die postcondition Q, wenn man darin das freie<br />
Vorkommen von v durch W ersetzt.<br />
oder eine andere (etwas allgemeinere Formulierung) der Wirkung, hierbei ist V 0<br />
der Wert der Variablen V vor der Wertzuweisung:
Aus P(V 0 ) & V = f(V 0 ,Y)--> Q(V)<br />
folgt P(V) { V := f (V,Y) } Q(V)<br />
Die zweite Fassung, verbal ausgedrückt:<br />
Wenn aus der Gültigkeit von P für den Wert von V vor der Wertzuweisung und<br />
dem durch die Zuweisung erreichten neuen Wert von V die Beziehung Q folgt,<br />
dann hat die Zuweisung die gewünschte Wirkung.<br />
Beispiele:<br />
a) Sei P: X > 24 W<br />
und Q: X > V dann gilt: X > 24W {V := 24*W} X > V,<br />
weil erfüllt ist:X > 24 W --> [Q V 24W]<br />
b) Es gilt: x ganz & x > 0 {x := x -1} x >= 0, denn<br />
aus x > 0 & x ganz , folgt x-1 >= 0 = [Q x x-1], wenn Q : x >= 0 .<br />
2. Regel für die Sequenz:<br />
Aus P {A1 } Q1<br />
Q1 {A2} Q2<br />
Q2 {A3} Q3<br />
.<br />
.<br />
.<br />
Qn-1{An} Q (Voraussetzung)<br />
folgt: P {A1; A2; . . .; An} Q (Folgerung)<br />
Beispiel:<br />
Ein Programmstück S1 berechnet die Summe s der Elemente a1, a2, ..., an;<br />
Ein Programmstuck S2 berechnet aus s den Wert M=s/n.<br />
Aus TRUE {S1} s=a1+a2+.....+an<br />
s= a1+a2+...+an {S2} M = s/n<br />
folgt: TRUE {S1; S2} M= (a1+a2+...+an)/n<br />
219
220<br />
d.h. das zusammengesetzte Programm berechnet den Mittelwert.<br />
3. Regel für die Alternative:<br />
Aus P & B {A1} Q<br />
und P & NOT B {A2} Q (Voraussetzung)<br />
folgt: P {if B then A1 else A2} Q (Folgerung)<br />
Beispiel:<br />
Aus x reelle Zahl & x >= 0 {y := x} y >= 0<br />
und x reelle Zahl & x < 0 {y := -x} y >= 0<br />
folgt x reelle Zahl {if x >= 0 then y:=x else y := -x } y >= 0<br />
4. Regel für die while-Schleife:<br />
Aus P --> INV<br />
und INV & B { A } INV<br />
und INV & NOT B --> Q<br />
folgt: P { while B do A } Q<br />
(Falls die Schleife nach endlich vielen Schritten abbricht ("Partielle Korrektheit"))<br />
Beispiel: (Hier gleichzeitig Entwicklung des (partiell) korrekten Programms<br />
Summe der N Elemente eines Feldes a0, . . . , aN-1.<br />
Es soll ein Programm A entwickelt werden, für das gilt:<br />
N>=0 { A } s = ∑ aj<br />
0
Als Invariante INV wählen wir: s = ∑ aj & 0
222<br />
Die Verifikationsregeln lassen sich baumförmig darstellen, wenn wir die<br />
Verifikationsvoraussetzungen als Knoten darstellen, die durch Kanten mit der<br />
Verifikationsfolgerung verbunden sind.<br />
a) Wertzuweisung<br />
oder in der zweiten Fassung:<br />
b) Sequenz<br />
c) Alternative<br />
d) While-Schleife<br />
P --> [Q v W]<br />
P {v:=W} Q<br />
P(V 0 ) & V = f(V 0 ,Y)--> Q(V)<br />
P(V) { V := f (V,Y) } Q(V)<br />
P{A1 }Q1 Q1 {A2}Q2 Q2{ A3 } Q3 . . . Qn-1 {An}Q<br />
P { A1 ; A2; . . . ; An } Q<br />
P & B {A1} Q P & NOT B {A2} Q<br />
P {if B then A1 else A2} Q
P --> INV INV & B { A } INV INV & NOT B --> Q<br />
e) Repeat-Schleife<br />
P { while B do A } Q<br />
P {A} INV INV & NOT B { A } INV INV & B --> Q<br />
P {repeat A until B } Q<br />
Die Verifikation eines Programmes verläuft so, dass ein "Verifikationsbaum"<br />
aufgebaut wird. Dieser enthält als Wurzel die Programmspezifikation. Mittels der<br />
Verifikationsregeln werden weitere Knoten entwickelt. Dies geschieht solange bis<br />
in den Blättern des Baums die Verifikationsbedingungen stehen. Falls alle<br />
Verifikationsbedingungen erfüllt sind ist der Beweis der Korrektheit für dieses<br />
Programm erfolgreich abgeschlossen, die (partielle) Korrektheit des Programms<br />
streng bewiesen.<br />
Beispiel:<br />
Es ist zu beweisen: Für X0, Y0 ganzzahlig, gilt:<br />
X > 0 & X = X0 & Y = Y0<br />
{ Z := 0;<br />
U := X;<br />
repeat<br />
223
224<br />
Z = X0 * Y0<br />
Z := Z + Y;<br />
U := U - 1;<br />
until U = 0 }<br />
Als erster und wichtigster Schritt wird eine Invariante für die repeat-Schleife<br />
gesucht. Die geeignete Invariante (wie wir noch streng beweisen werden) ist:<br />
U * Y + Z = X0 * Y0<br />
Wir nennen diese Invariante INV. Dass INV durch das Innere der Schleife nicht<br />
verändert wird, ist plausibel, da das Produkt U * Y jeweils bei einem Durchlauf<br />
um Y vermindert und Z um Y erhöht wird.<br />
Es werden folgende Abkürzungen im Verifikationsbaum benutzt:<br />
ENTRY ist X > 0 & X = X0 & Y = Y0<br />
EXIT ist Z = X0 * Y0<br />
INV0 ist X*Y + Z = X0 * Y0<br />
INV1 ist U * Y + Z = X0 * Y0<br />
INV2 ist INV1 & U >= 0<br />
Bed1 ist (U - 1) * Y + Z = X0 * Y0<br />
S0 ist Z := 0; U := X;<br />
S1 ist Z := Z + Y; U := U-1;<br />
S2 ist repeat S1 until U = 0
9 10 15 16 17 18<br />
4 5<br />
2<br />
11 12 13 14<br />
1<br />
6 7 8<br />
1. ENTRY { S0; S2 } EXIT<br />
2. ENTRY {S0 } INV1 & U> 0<br />
3. INV1 & U > 0 {S2 } EXIT<br />
4. ENTRY {Z := 0 } INV0 & X >0<br />
5. INV0 & X > 0 {U := X } INV1 & U> 0<br />
6. INV1 & U > 0 { S1 } INV2<br />
7. INV2 & U 0 { S1 } INV2 (siehe 6.)<br />
8. INV2 & U = 0 --> Z = X0 * Y0<br />
9. ENTRY & Z = 0 --> X * Y + Z = X0 * Y0<br />
10. INV1 & X > 0 & U = X --> U * Y + Z = X0 * Y0 & U > 0<br />
11. INV1 & U > 0 { Z := Z + Y } Bed1 & U > 0<br />
12. Bed1 & U > 0 { U := U - 1 } INV2<br />
13. siehe 11.<br />
14. siehe 12.<br />
15. U > 0 & U * Y + Zalt = X0 * Y0 & Z = Zalt + Y<br />
--> (U - 1) * Y + Z = X0 * Y0 & U > 0<br />
16. Ualt > 0 & ( Ualt - 1 ) * Y + Z = X0 * Y0 & U = Ualt - 1<br />
--> U >= 0 & U * Y + Z = X0 * Y0<br />
17. siehe 15.<br />
3<br />
225
226<br />
18 siehe 16.<br />
Wir haben durch den Beweisbaum folgendes Ergebnis erhalten: Der obige<br />
Algorithmus liefert das richtige Ergebnis, falls er bis zum Ende kommt, mit<br />
anderen Worten, wenn die Schleife nicht unendlich lange läuft. Man bezeichnet<br />
dies als den Beweis der partiellen Korrektheit.<br />
Um die totale Korrektheit eines Algorithmus festzustellen, müssen wir zusätzlich<br />
noch beweisen, dass das gewünschte Ergebnis nach endlich vielen Schritten auch<br />
wirklich erreicht wird, d.h., dass der Algorithmus wirklich endet.
6.3.3.2 Beweis der Endlichkeit von Algorithmen<br />
Die Endlichkeit eines Algorithmus ist genau dann gewährleistet, wenn alle<br />
zyklischen Programmteile ( also die Schleifen ) in endlich vielen Schritten<br />
vollständig durchlaufen sind. Hierzu müssen wir eine weitere Schleifeninvariante<br />
einführen bzw. finden.<br />
Falls wir einen Ausdruck e finden, für den vor und nach einem Schleifendurchlauf<br />
gelten muss: e >= 0, und dessen Wert bei jedem Durchlauf um mindestens 1<br />
vermindert wird, dann ist die Endlichkeit der Schleife gesichert, denn es muss dann<br />
nach endlich vielen Durchläufen die Schleife verlassen werden, weil sonst für e<br />
gelten würde: e < 0, was nicht möglich ist.<br />
In unserem obigen Beispiel ist U ein solcher (ganzzahliger ) Ausdruck, denn da<br />
X > 0 gilt, ist U >= 0 eine Schleifeninvariante, aber U wird bei jedem<br />
Schleifendurchlauf um 1 vermindert.<br />
Damit ist die totale Korrektheit unseres kleinen Algorithmus bewiesen.<br />
Übungen:<br />
1. Beweisen Sie: N 0<br />
2. Beweisen Sie:<br />
A = A0 & B = B0 { T : = A; A : = B; B : = T } A = B0 & B = A0<br />
3. Zeigen Sie, dass das folgende Programm, eine etwas abgeänderte und<br />
optimierte Form des behandelten Algorithmus, in Z ebenfalls das Produkt X0 *<br />
Y0 liefert, also:<br />
X>0 & X=X0 & Y=Y0<br />
{ Z:= 0;<br />
U:= X;<br />
while NOT U=0 do<br />
if (U mod 2 = 0) then<br />
{ U:= U/2; Y=Y*2;}<br />
else<br />
{ Z:= Z+Y; U:= U-1; }<br />
end; }<br />
227
228<br />
Z=X0*Y0
7 Testen<br />
Keine Software ist fehlerfrei. Beispiele, die diese Tatsache belegen, wie z. B. der<br />
Ausfall von Telefonnetzen oder Bahnhof-Leitsystemen, Absturz von Ariane-<br />
Raketen, sind aus der Tagespresse bekannt. Diese Beispiele zeigen, daß Fehler in<br />
der Software sehr teuer werden können. Aber nicht nur die Folgen von Software-<br />
Ausfällen sind teuer, auch die Kosten der Phase Test sind in großen oder<br />
sicherheitskritischen Projekten oft höher als die Entwicklungskosten. Die Phase<br />
Test in einem Software-Entwicklungsprozeß ist somit eine wichtige und<br />
kostspielige Phase. Bei den Aktivitäten in der Test-Phase werden Fehler in der zu<br />
prüfenden Software gesucht und (hoffentlich) entdeckt. Dadurch werden die<br />
Folgekosten von entdeckten Softwarefehlern erheblich reduziert. Je später im<br />
Entwicklungsprozeß ein Fehler entdeckt wird, um so höher sind die Kosten für<br />
seine Beseitigung. Ein erfolgreicher Test führt zur Entdeckung von Fehlern. Es ist<br />
durch Testen aber nicht möglich die Fehlerfreiheit von Software zu beweisen.<br />
7.1 Testverfahren - Wie wird getestet?<br />
Ein Softwaresystem kann aus unterschiedlichen Sichten betrachtet werden, z. B.<br />
externe - interne, statische - dynamische Sicht. In jeder Sichtweise sind bestimmte<br />
Eigenschaften eines Systems sichtbar. Zur Überprüfung der Eigenschaften einer<br />
Software können verschiedene Testverfahren eingesetzt werden. Testverfahren<br />
helfen mit einem Minimum an Tests ein Maximum an Fehlern zu finden.<br />
Balzert klassifiziert in [Bal99, S. 509f] Testverfahren wie folgt:<br />
Dynamische Testverfahren<br />
• White Box Test, Strukturtest<br />
• Black Box Test, Funktionstest<br />
Statische Testverfahren<br />
• Walkthrough<br />
• Inspektionen<br />
Bei den dynamischen Verfahren wird die Software ausgeführt und mit konkreten<br />
Eingabewerten versehen. Bei den statischen Verfahren wird die Software nicht<br />
ausgeführt. Der Quellcode wird analysiert, mit dem Ziel Fehler zu finden.<br />
Vigenschow unterscheidet [Vig, S. 20ff] demonstratives Testen und destruktives<br />
Testen. In den ersten Bereich fällt z. B. der Entwicklertest, der zeigt, daß ein<br />
229
230<br />
Programm funktioniert. Destruktives Testen bezeichnet das systematische Testen<br />
von Software mit der Absicht Fehler zu finden.<br />
Black Box Test - Funktionstest<br />
Bei dem Black Box Test wird das Testobjekt (Klasse, Komponente, System) gegen<br />
seine Spezifikation getestet. Die interne Struktur des Testobjektes ist entweder<br />
unbekannt oder unwichtig. Die Testwerte werden aus der funktionalen<br />
Spezifikation abgeleitet. Mit einem Black Box Test kann herausgefunden werden,<br />
ob das Testobjekt den Anforderungen des Auftraggebers entspricht, bzw. in<br />
welcher Komponente ein Fehler auftritt. Zur genauen Lokalisierung eines<br />
entdeckten Fehlers sind weitere Tests oder Werkzeuge nötig.<br />
White Box Test - Strukturtest<br />
Beim White Box Test wird das Testobjekt gegen seine Kontrollstruktur<br />
(Implementierung) getestet. Die Kontrollstruktur kann mit Hilfe eines<br />
Kontrollflussgraphen dargestellt werden . Ein Kontrollflussgraph ist ein gerichteter<br />
Graph, der die Anweisungen und Verzweigungen im Quellcode des Testobjekts<br />
darstellt (siehe Kapitel 8.1.3 Das McCabe Maß). Der Kontrollflussgraph einer<br />
Komponente besteht aus Knoten (Anweisungen) und gerichteten Kanten<br />
(Strukturinformationen), die die Knoten verbinden. Die gerichteten Kanten nennt<br />
man Zweige. Den Weg durch eine Komponente von dem Anfangsknoten zu einem<br />
Endknoten nennt man Pfad.<br />
Durch die Berücksichtigung der Kontrollstruktur können auftretende Fehler<br />
wesentlich präziser, als bei einem Black Box Test, lokalisiert werden.<br />
Bei dem White Box Test werden die Testfälle so gewählt, daß die Anweisungen<br />
und Zweige eines Programms möglichst vollständig ausgeführt werden. Software<br />
kann wegen ihrer Komplexität nicht vollständig getestet werden. Es kann mit<br />
vertretbarem Aufwand nicht nachgewiesen werden, daß ein Programm fehlerfrei<br />
ist. Die nachfolgend aufgeführten Überdeckungsgrade dienen als Maße für den<br />
Umfang der durchgeführten Tests. Überdeckungsgrade werden meistens in Prozent<br />
angegeben. 80% Zweigüberdeckung bedeutet, daß 80 % aller Zweige bei Tests<br />
ausgeführt wurden.<br />
Die Anweisungsüberdeckung fordert die einmalige Ausführung aller<br />
Anweisungen eines Testobjekts. Die Zweigüberdeckung fordert die Ausführung<br />
aller Zweige eines Programms. Bei der Bedingungsüberdeckung werden die<br />
Bedingungen, die zu einer Verzweigung führen, getestet. Bei komplexen boolschen<br />
Bedingungen müssen alle Kombinationen von Bedingungen, die in den FALSE<br />
oder TRUE Zweig führen getestet werden; für die Zweigüberdeckung genügt die<br />
Ausführung einer Bedingung. Die Pfadüberdeckung fordert die Ausführung aller
Pfade durch ein Testobjekt. Für nicht-triviale Programme ist dieser Test nicht<br />
vollständig durchführbar, da die Anzahl der Pfade unendlich sein kann. Die<br />
kritischen Strukturen <strong>beim</strong> Pfadtest sind die Schleifen. Bei jedem<br />
Schleifendurchlauf ergibt sich ein neuer Pfad und damit eine neue<br />
Fehlermöglichkeit. Bei praktisch durchführbaren Pfadüberdeckungstests muß die<br />
Wiederholbarkeit von Schleifen eingeschränkt werden. (siehe Lig S. 64ff)<br />
Instrumentierung<br />
Um die im letzten Abschnitt beschriebenen Überdeckungsgrade messen zu können,<br />
werden in den Zweigen eines Testobjekts Zähler eingeführt. Daran kann<br />
festgestellt werden, welche Zweige bei einem Test ausgeführt wurden. Die Analyse<br />
des Quellcodes eines Testobjekts und das Einfügen der Zähler durch Testwerkzeug<br />
wird Instrumentierung genannt.<br />
Grey Box Test<br />
Der Grey Box Test ist eine Kombination aus Black Box und White Box Tests. Bei<br />
der Integration eines Gesamtsystems aus Teilkomponenten werden die<br />
Schnittstellen der Teilkomponenten getestet. Beim Grey Box Test ist die<br />
Komponentenstruktur bekannt; die Testfälle werden aus der Spezifikation<br />
abgeleitet.<br />
7.2 Wie findet man Testdaten<br />
Äquivalenzklassenanalyse<br />
Es ist unmöglich ein Programm mit allen möglichen Eingabewerten zu testen. Zur<br />
Reduzierung des Testaufwands dient die Äquivalenzklassenanalyse. Die möglichen<br />
Eingaben in ein Testobjekt werden in Äquivalenzklassen eingeteilt. Alle Werte<br />
einer Äquivalenzklasse verursachen das gleiche Systemverhalten. Für jede<br />
Äquivalenzklasse wird, stellvertretend für alle Eingaben dieses Bereichs, ein Test<br />
durchgeführt. Die Testdaten werden aus Eingabewerten der Funktionen unter<br />
Berücksichtigung der Gültigkeitsbereiche gewählt.<br />
Grenzwertanalyse<br />
Bei dem Einsatz der Äquivalenzklassenanalyse sind die Übergänge zwischen den<br />
Äquivalenzklassen besonders kritisch; dort treten häufig Fehler auf. Es können<br />
Fehler entstehen durch die Verwendung falscher Vergleichsoperatoren (< statt<br />
232<br />
wählt als Testdaten Eingabewerte an der Grenze von Äquivalenzklassen und<br />
überprüft, ob die entsprechenden Extremwerte in den Algorithmen richtig<br />
behandelt wurden.<br />
7.3 Wer testet?<br />
Alle Tests, deren Testgegenstand eine kleine Softwareeinheit ist, wie z. B. eine<br />
Klasse, Methode oder ein Objekt werden während der Entwicklung vom<br />
Entwickler getestet. Diese Tests dienen jedoch primär dem Nachweis, daß die<br />
entwickelten Softwareeinheiten die geplante Funktion erfüllen. Sie fallen in den<br />
Bereich des demonstrativen Testens. Die Entwickler von Software sind aus<br />
psychologischen Gründen nicht geeignet für das destruktive Testen. Sie können<br />
ihrem eigenen Werk - der Softwareeinheit - nicht mit der notwendigen destruktiven<br />
Einstellung entgegentreten. Das destruktive Testen - die aktive Suche nach Fehlern<br />
in der Software - sollte deshalb immer von einem Tester oder einem Testteam<br />
durchgeführt werden. Nur Personen, die nicht mit der Entwicklung der Software<br />
beschäftigt waren, haben die nötige objektive Distanz zu dem Produkt, um Fehler<br />
zu finden.<br />
7.4 Testen von objektorientierter Software<br />
Die meisten Testverfahren stammen aus der vor-OO-Zeit, sind jedoch auch auf<br />
OO-Software anwendbar. In der vor-OO-Zeit bestand ein Programm aus Modulen,<br />
die Module enthielten Funktionen oder Prozeduren. OO-Software ist prinzipiell<br />
genauso aufgebaut, enthält aber zusätzlich die Konzepte der Klasse, Vererbung und<br />
Polymorphie. Klassen können in einer Vererbungshierarchie angeordnet sein und<br />
Methoden und Attribute von übergeordneten Klassen erben. Methoden können in<br />
abgeleiteten Klassen überschrieben werden. Dynamisch gebundene Methoden<br />
können in Abhängigkeit des Objekts bei dem sie aufgerufen werden zu<br />
unterschiedlichem Verhalten führen.<br />
Objektorientierte Software besteht aus vielen miteinander interagierender Einheiten<br />
(Klassen, Packages). Die Komplexität der einzelnen Einheiten ist relativ gering<br />
(und einfach zu testen). Die Abhängigkeiten zwischen den Einheiten ist aber groß.<br />
Öffentliche Methoden einer Klasse können von Methoden anderer Klassen<br />
aufrufen werden. Wird eine Klasse von einer anderen Klasse abgeleitet, ist die
abgeleitete Klasse von der Oberklasse abhängig. Methoden können den Zustand<br />
von Objekten ändern und so über die Zustandsattribute gekoppelt sein.<br />
Dadurch entstehen viele Abhängigkeiten, die das Testen von objektorientierter<br />
Software sehr aufwändig machen (vgl. [SnWi S. 22-25] und [Vig S. 93ff]).<br />
7.5 Teststrategie<br />
Ein Softwaresystem wird aus seinen Komponenten zusammengesetzt. Es wird<br />
entsprechend seiner Struktur schichtweise zusammengebaut und getestet. Die<br />
Integration erfolgt entweder top-down oder bottom-up. Die jeweils fehlende<br />
Schicht wird durch Testtreiber simuliert.<br />
Bild aus [FiRi]<br />
Funktionstest, Klassentest<br />
Bei diesen Tests ist bei Einsatz einer OO-Sprache eine Methode, Klasse oder<br />
Objekt der Testgegenstand. Die Tests werden von den Softwareentwicklern selbst<br />
durchgeführt. Es werden meistens White Box Test eingesetzt. Beim Klassentest<br />
werden alle öffentlichen Methoden einer Klasse getestet. Eine Klasse kann<br />
Methoden von anderen Klasse erben und über Assoziationen mit anderen Klassen<br />
in Beziehung stehen. Diese Beziehungen einer Klasse zu den Klassen ihrer<br />
Umgebung müssen <strong>beim</strong> Testen berücksichtigt werden. Die Klassenstruktur muss<br />
entlang der Vererbungsstruktur getestet werden (siehe [Vig S. 93ff]) und sie muss<br />
233
234<br />
entlang der Assoziationen getestet werden. Wenn die Umgebungsklassen nicht zur<br />
Verfügung stehen müssen sie durch Stellvertreterobjekte simuliert werden.<br />
Modultest, Integrationstest<br />
Softwaresysteme bestehen aus mehreren Modulen, die einen bestimmten Zweck<br />
erfüllen und als Einheit gekapselt sind. Im Modultest werden die Funktionen der<br />
Module (Teilsysteme) getestet. Im Integrationstest wird das Zusammenspiel der<br />
Module getestet. Hier werden White, Grey und Black Box Tests eingesetzt.<br />
Systemtest, Anwendertest<br />
Im Systemtest wird das fertige Gesamtsystem getestet. Es wird getestet ob das<br />
System die geplante Funktion erfüllt; es wird die Bedienbarkeit und die Installation<br />
getestet. Das Verhalten des Systems unter Last wird überprüft. Der Anwender<br />
überprüft am Ende des Entwickungszyklus die Akzeptanz des Systems, die<br />
Robustheit und Stabilität während des Betriebs. Es werden hier hauptsächlich<br />
Black Box Testverfahren eingesetzt.<br />
7.6 Testwerkzeuge<br />
Es sind verschiedene Tools auf dem Markt, die Testplanung und Testmanagement,<br />
die Durchführung dynamischer und statischer Tests unterstützen und eine<br />
Automatisierung von Testabläufen ermöglichen. Werkzeuge zur Automatisierung<br />
von GUI-Tests verwenden Skriptsprachen um die GUI-Elemente aufzurufen und<br />
mit Werten zu versorgen. Tools für Last- und Performancetests werden benötigt,<br />
um ein System unter Last zu setzen und mögliche Engpässe zu erkennen und zu<br />
beseitigen.<br />
Eine ausführliche Klassifizierung von Testwerkzeugen findet sich in [SnWi,<br />
Kapitel 11]. Eine kleine Auswahl stellt nachfolgende Liste dar:<br />
• WinRunner/Mercury<br />
• Rational Robot/IBM<br />
• SilkTest/Segue<br />
• QA-C++/QA-Systems<br />
• Telelogic Tau/Telelogic<br />
7.7 xUnit, JUnit
xUnit steht für eine Familie von Open Source Frameworks, die Entwickler bei der<br />
Durchführung und Automatisierung von Tests unterstützen. Die Frameworks<br />
stehen für verschiedene Programmiersprachen zur Verfügung. Die Java Variante<br />
JUnit unterstützt die Erstellung der Tests in Java. Die Frameworks sind im Umfeld<br />
von XP entstanden und als Open-Source-Projekte realisiert worden (siehe<br />
http://c2.com/cgi/wiki?TestingFramework). Bei einer testgetriebenen,<br />
inkrementellen Entwicklung, wie XP sie vorschlägt, ist zur wirtschaftlichen<br />
Durchführung der Tests eine Testautomatisierung unerläßlich. Bei Einsatz der<br />
xUnit-Frameworks erstellen Entwickler die Tests in der selben Sprache in der auch<br />
die zu testende Anwendung entwickelt wird. Die Durchführung der Tests und die<br />
Überprüfung der Ergebnisse erfolgt automatisch. Jeder Testfall ist von allen<br />
anderen Testfällen unabhängig, damit bei einem auftretenden Fehler nicht der<br />
vollständige Testlauf abgebrochen wird. Jeder Testfall kann erfolgreich<br />
durchlaufen werden, oder einen Fehler verursachen. Zur Überprüfung der<br />
Testergebnisse werden Zusicherungen (assertions) verwendet. Die Testergebnisse<br />
werden aufgezeichnet.<br />
XP unterscheidet zwei Testebenen (vgl. Kapitel 4.7 eXtreme Programming):<br />
• Acceptance Tests werden von dem Kunden definiert und von den Entwicklern<br />
implementiert.<br />
• Unit Tests erstellen die Programmierer bevor sie die Units (Klassen, Packages,<br />
Komponenten, Module) implementieren. Diese Vorgehensweise wird<br />
testgetriebene Entwicklung (test-driven development) genannt. Die Integration<br />
der Units zu einem Gesamtsystem erfolgt erst, wenn alle Unit Tests erfolgreich<br />
laufen.<br />
235
236<br />
Struktur von xUnit, JUnit<br />
Klassendiagramm von xUnit (aus [JUcook])<br />
Das Klassendiagramm in Bild NR beschreibt die Struktur von JUnit. Bei der<br />
Realisierung von xUnit wurden mehrere Entwurfsmuster eingesetzt. Die grau<br />
hinterlegten Pfeile bezeichnen die Entwurfsmuster, bzw. die Elemente der Muster.<br />
xUnit besteht aus 4 Klassen (siehe Bild NR). Über das Composite-Pattern ergibt<br />
sich daraus eine Baumstruktur aus Testfällen und Testsuiten. Das abstrakte<br />
Interface Test wird vererbt an die Klassen TestCase und TestSuite. Wird<br />
ein Testfall geschrieben, so wird dieser von TestCase abgeleitet. Die Methode<br />
setUp() wird vor jedem Test aufgerufen. Sie führt alle Initialisierungen (z. B.<br />
der Instanzvariablen) durch. Die Methode tearDown() sorgt nach jedem Testfall<br />
für einen definierten Endzustand. Die Methode runTest() ruft den Testfall auf, run<br />
(TestResult) übergibt das Ergebnis des Tests an die Klasse TestResult, in<br />
der die Ergebnisse gespeichert werden. Werden mehrere Testfälle benötigt, dann<br />
wird die Klasse TestSuite verwendet. Diese Klasse fügt über die Methode<br />
addTest(Test) einen Testfall in eine Menge von Tests, die TestSuite, ein. Die<br />
Klasse TestSuite hat eine Aggregationsbeziehung zu Test. Dadurch kann eine<br />
TestSuite mehrere Exemplare von TestCase und TestSuite enthalten.<br />
Die Struktur von JUnit ist ausführlich beschrieben in dem Dokument JUnit A<br />
Cook's Tour (http://junit.sourceforge.net/doc/cookstour/cookstour.htm).
Vorgehensweise<br />
Bei Einsatz von JUnit für einen Testfall geht man wie folgt vor:<br />
1. Erzeugen einer Unterklasse von TestCase<br />
2. Überschreiben der Methode runTest()<br />
3. Test starten.<br />
Ein ausführliches Beispiel zur Verwendung von JUnit findet sich in dem<br />
Dokument JUnit Cookbook<br />
(http://junit.sourceforge.net/doc/cookstour/cookstour.htm).<br />
Literatur<br />
[Bal99] Helmut Balzert, Lehrbuch - Grundlagen der <strong>Informatik</strong>, Spektrum<br />
Akademischer Verlag, 1999.<br />
[FiRi] Daniel Fischer, Marc-Oliver Richter, Schwarze Kunst, Black-Box-<br />
Methoden zum GUI-Testen, in iX 11/2001, S. 52-55, Heise.<br />
[JUcook] Kent Beck, Erich Gamma, JUnit Cookbook,<br />
http://junit.sourceforge.net/doc/cookstour/cookstour.htm<br />
[Lig] Peter Liggesmeyer, Modultest und Modulverifikation, BI<br />
Wissenschaftsverlag, 1990.<br />
[Link] Johannes Link, Softwaretest mit JUnit, dpunkt.verlag, 2005.<br />
[SnWi] Harry M. Sneed, Mario Winter, Testen objektorientierter Software,<br />
Hanser, 2002.<br />
[Vig] Uwe Vigenschow, Objektorientiertes Testen und Testautomatisierung in<br />
der Praxis, dpunkt.verlag, 2005.<br />
237
238<br />
8 Konfigurationsmanagement<br />
8.1 Warum Konfigurationsmanagement (KM)?<br />
Heutige Software-Entwicklungsprojekte zeichnen sich durch eine hohe<br />
Komplexität aus (vgl. [Brö00]). In SW-Entwicklungsprojekten entsteht eine<br />
Vielzahl von Software-Elementen (Artefakte), die im Laufe des Projektes iterativ<br />
in den verschiedenen Phasen geändert bzw. weiterentwickelt werden. Zentrale<br />
Artefakte sind z. B. Anforderungsdokumente, Architekturbeschreibungen, Grafiken<br />
sowie der Quellcode der verschiedenen Module/SW-Komponenten. Diese SW-<br />
Elemente (auch KM-Items genannt) können in unterschiedlichen Dateisystemen<br />
auf verteilten Plattformen/Rechnern sowie in unterschiedlichsten Formaten<br />
vorliegen.<br />
In der Regel bedingen heutige Entwicklungen die Einhaltung einer bestimmten<br />
Produktionskette (vom Entwicklungssystem bis zum Produktivbetrieb).<br />
Erfolgreiche Projekte basieren auf einem guten Management dieser Artefakte durch<br />
eine transparente Ablagestrategie sowie einzuhaltender Konventionen (z. B.<br />
Namenbildungsregeln für die Artefakte). Idealerweise kann zu jedem Zeitpunkt,<br />
d.h. während des gesamten Lebenszyklus des Anwendungssystems, Teile von dem<br />
Anwendungssystem oder auch das gesamte Anwendungssystem aus den<br />
Entwicklungsdaten ohne manuelle Eingaben reproduziert werden. Die hierfür<br />
notwendigen Informationen zu den Entwicklungsdaten werden zentral gespeichert.<br />
Das Konfigurationsmanagement stellt ein wichtiges Mittel dar, um Änderungen<br />
effektiv durchzuführen und diese auch später noch nachvollziehen zu können.<br />
Beim Aufbau der SW-Entwicklungsumgebung (SEU) muss berücksichtigt werden,<br />
dass die Änderung der verschiedenen Software-Elementen geordnet und<br />
nachvollziehbar erfolgt.<br />
8.2 Was ist (Software-)Konfigurationsmanagement (SKM)?<br />
Ein Produkt durchläuft im gesamten Lebenszyklus (= Produktlebenszyklus)<br />
verschiedene Zustände, die sich in unterschiedlichen Produktstrukturen<br />
widerspiegeln können. Unter dem Begriff Konfigurationsmanagement fasst man<br />
vielfältige Aufgaben zusammen (wie z. B. Produktplanung sowie Produkt- und<br />
Konfigurationsverwaltung), die die verschiedenen Produktzustände effektiv<br />
verwalten.<br />
Der KM-Begriff stammt ursprünglich aus dem Maschinenbau und wurde auch auf<br />
die Software-Entwicklung adaptiert. In der Softwareentwicklung bezeichnet der
Begriff des Software Konfigurations-Managements (SKM) die Disziplin zur<br />
Verfolgung und Steuerung der Evolution von Software. KM wurde durch die<br />
Internationale Standards Organisation für die SW-Entwicklung standardisiert (-><br />
Richtlinienwerk DIN EN ISO 9001, [Brö00]).<br />
Konfigurations-Management wurde ca. 1950 für die US-Luft- und<br />
Raumfahrtindustrie eingesetzt (z. B. im Apollo-Programm zur Verfolgung<br />
Tausender von Änderungen). In den 70er Jahren des letzten Jahrhunderts wurden<br />
Werkzeuge wie z. B. SCCS (Source Code Version Control Management Software)<br />
und MAKE etabliert. Heutzutage ist anerkannt, dass SKM-Werkzeuge eine hohe<br />
Bedeutung für Softwareprojekte besitzen. Moderne Werkzeuge (wie z. B. CVS<br />
[CVS04] und ANT [Ant04]) sind anspruchsvoll und bedingen eine Lernphase<br />
bevor diese effizient genutzt werden können.<br />
8.3 Einsatz von Software-Konfigurationsmanagement in Projekten<br />
Software ist durch Anpassungen, Erweiterungen oder Korrekturen einem ständigen<br />
Änderungsprozess unterworfen. Das Hauptaugenmerk <strong>beim</strong> SKM liegt bei der<br />
Unterstützung der Nachvollziehbarkeit von Änderungen sowie der Produktion<br />
zumeist zahlreicher Software-Freigaben (Releases).<br />
Wird die Entwicklung durch Teams durchgeführt und bearbeiten mehrere<br />
Entwickler das gleiche Softwareobjekt, muss festgelegt sein, welches Prinzip<br />
angewandt werden soll. Ein Prinzip könnte sein, dass die jeweils letzte Änderung<br />
vorherige Änderungen einfach überschreibt („last save wins“). Alternativ kann<br />
auch das gleichzeitige Ändern untersagt werden, um evtl. ungewolltes<br />
Überschreiben grundsätzlich zu verhindern.<br />
In der Regel bestehen Abhängigkeiten zwischen den einzelnen<br />
Softwarekomponenten. Bei der Modifikation einer Komponente ist es daher oft<br />
nötig auch die davon abhängigen Komponenten anzupassen. Ändert sich<br />
beispielsweise die Schnittstelle einer Komponente, müssen Anwendungsteile, die<br />
diese Schnittstelle verwenden, ebenfalls angepasst werden.<br />
Ist die Menge der von einer Komponente abhängigen Teile nicht bekannt, muss<br />
diese bei jeder Änderung erst mühsam (evtl. manuell) ermittelt werden. Wird dabei<br />
eine Komponente, die eigentlich angepasst werden müsste, nicht beachtet und<br />
keine unmittelbare Fehlermeldung im Kompositionsprozess angezeigt, können so<br />
neben dem Zeitverlust auch Fehler entstehen, die mit erhöhtem Kostenaufwand<br />
wieder korrigiert werden können.<br />
239
240<br />
Um diesen Probleme entgegenzuwirken, enthält ein SKW-Werkzeug mächtige<br />
Änderungs- und Build-Management-Funktionen. Um die Reproduzierbarkeit der<br />
einzelnen Produkteigenschaften zu gewährleisten, bildet das Konfigurationsmanagement<br />
die diversen Produkt-Zustände in sog. Konfigurationsmappen ab.<br />
Hierbei sind verschiedene Anforderungen an die eingesetzten Techniken und<br />
Verfahren zu stellen. Jeder Entwickler hat zur erfolgreichen Durchführung des<br />
SKM zusätzlich zu seiner Arbeit am Produkt für das SKM einen Mehraufwand zu<br />
leisten. Der hieraus erwachsende Nutzen sollte jederzeit ersichtlich sein. Um dieses<br />
Bewusstsein und die Fähigkeit zur Bedienung der Werkzeuge zu fördern, sind<br />
Schulungsmaßnahmen durchzuführen.<br />
Nachfolgend werden wichtige Funktionen eines idealtypischen<br />
Konfigurationsmanagement Systems genannt:<br />
- Verwaltung aller Projektergebnisse (unabhängig vom verwendeten Dateiformat)<br />
- Verwaltung und automatisierte Pflege der Abhängigkeitsbeziehungen (Verweise)<br />
zwischen den SW-Elementen<br />
- Konsistenzsicherung zwischen den verschiedenen abhängigen SW-Elementen<br />
- Unterstützung von Änderungen an textuellen und graphischen<br />
Entwicklungsmodellen (wie z. B. Analyse- und Entwurfsmodellen)<br />
Die einzelnen Aufgaben des SKM kann man nach ihrer Wichtigkeit ordnen. Die<br />
Basis bildet die Kontrolle der Versionen einzelner SW-Elemente. Darauf<br />
aufbauend liegen Konfigurationen sowie Einstellungen für die<br />
Kompositionsprozesse im Rahmen des Build-Management. Hat eine Freigabe der<br />
Software stattgefunden, gewinnen Verfolgung und Koordination von<br />
Änderungsprozessen an Bedeutung. In dieser Phase des SW-Lebenszyklus muss<br />
ein effizientes Änderungsmanagement etabliert sein. Letztendlich fügt sich das<br />
SKM in den Gesamtprozess der Softwareentwicklung (z. B. bei V-Modell oder<br />
RUP) ein. In dem jeweiligen Vorgehensmodell sind daher entsprechende KM-<br />
Abschnitte enthalten. Ziel und Aufgabe des SKM ist es, all diese Bereiche<br />
möglichst automatisiert und verteilt auf unterschiedlichen Plattformen (LAN,<br />
WAN, …) abwickeln zu können.
Verteilung (LAN, WAN; …)<br />
Vorgehensmodell<br />
Änderungsmanagement<br />
Konfigurationsmanagement<br />
Versionsmanagement<br />
Abbildung: Aufgaben von SKM<br />
Der in einem Projekt eingesetzte Entwicklungsprozess sollte von Anfang an SKM<br />
berücksichtigen. Schon sehr früh entstehen in einem Projekt wichtige Dokumente<br />
(wie z. B. der Projektplan und die Risikoliste), deren Änderungen nachvollziehbar<br />
sein sollten.<br />
Ist ein Projekt abgeschlossen, können die einzelnen SW-Elemente auch in anderen<br />
Projekten wieder verwendet werden. Dies sollte durch den Einsatz eines SKM-<br />
Werkzeugs gefördert werden. Dies kann in der Weise geschehen, dass<br />
Projektergebnisse in einem zentralen Repository (Projektbibliothek) gespeichert<br />
werden oder Informationen über Intranets oder Entwicklerportale veröffentlicht<br />
werden.<br />
Nach dem ersten Rollout der Software ist ein besonderes Änderungsmanagement<br />
zu etablieren. Dieses hat u. a. die Aufgabe, die aufgetretenen Problem- und<br />
Fehlermeldungen zu erfassen und zu verwalten. In der nachfolgenden Abbildung<br />
sind abschließend die möglichen Zustände einer Änderung und die zugehörigen<br />
Formulare (kursive Schrift) dargestellt (vgl. [Balz96]).<br />
Änderungsantrag/Problemmeldung<br />
bean<br />
-<br />
tragt<br />
Änderung<br />
bewerten<br />
Änderungsvorschlag<br />
Änderungen<br />
Abbildung: Änderungsmanagement<br />
beabsichtig<br />
t<br />
Änderungs<br />
vorschlag<br />
ablehnen<br />
entschließen u.<br />
einleiten<br />
Änderungsauftrag<br />
beauftra<br />
gt<br />
Änderung<br />
abschliessen<br />
Änderungsmitteilung<br />
erledig<br />
t<br />
241
242<br />
Änderung<br />
bewerten<br />
abgelehnt<br />
8.4 Weiterführende Literatur<br />
[Ant04] Apache ANT, http://ant.apache.org/, zuletzt besucht 11/2004.<br />
[Balz96] H. Balzert, Lehrbuch der Software-Technik: Software-Entwicklung,<br />
Spektrum Akademischer Verlag, 1996.<br />
[Brö00] P. Brössler, J. Siedersleben (Hrsg.), Softwaretechnik: Praxiswissen für<br />
Software-Ingenieure, Hanser, 2000.<br />
[CVS04] CVS, http://www.cvshome.org/, zuletzt besucht 11/2004.
9 Petri-Netze<br />
Während bei vielen Methoden nicht vorgesehen ist, gleichzeitig stattfindende<br />
Vorgänge mit ihren Abhängigkeiten zu beschreiben, ermöglichen Petri-Netze<br />
sowohl die Darstellung der elementaren logischen Strukturen als auch deren<br />
möglichen parallelen Ablauf.<br />
9.1 Zustände und Ereignisse<br />
Kernelemente von Petri-Netzen sind<br />
• Zustände (statische Knoten) und<br />
• Ereignisse (dynamische Knoten).<br />
Zustände können durch Ereignisse in neue Zustände übergehen. Die Zustände<br />
können die Bedingungen anzeigen, unter denen die Ereignisse stattfinden. Der<br />
ständige Wechsel von Ereignissen und neuen Zuständen zwingt den Benutzer<br />
dieser Methode, sich darüber klar zu werden, welche Zustände zu welchen<br />
Ereignissen führen, und welche Ereignisse notwendig sind (oder welche<br />
Bedingungen erfüllt werden müssen), um die gewünschten Zustände zu erreichen.<br />
Ein Petri-Netz ist demzufolge ein gerichteter Graph, der aus Kanten und Knoten<br />
besteht und folgende Eigenschaften aufweist:<br />
• Es gibt zwei Arten von Knoten:<br />
• den Bedingungs- bzw. Zustandsknoten (´Stelle´)<br />
• den Ereignisknoten (´Transition´).<br />
• Die Knoten treten nicht isoliert auf.<br />
• Die Pfeile laufen von Stelle zu Transition oder von Transition zu Stelle.<br />
• Die Anzahl der zu einem Knoten hinführenden Pfeile kann verschieden sein<br />
von der Anzahl der wegführenden Pfeile.<br />
Mit Hilfe solcher Petri-Netze können z.B. folgende Frage beantwortet werden:<br />
• Welche Vor- und Nachbedingungen weisen die Aktionen auf?<br />
• Nach welchen Vorschriften werden die Abläufe im System gesteuert?<br />
• In welcher Reihenfolge laufen Aktionen ab?<br />
• Welche Funktionsbereiche kommunizieren über welche<br />
Informationseinheiten miteinander?<br />
243
244<br />
Zur Erstellung von Petri-Netzen sind im Wesentlichen drei Symbole notwendig:<br />
Zustandsknoten<br />
Ereignisknoten oder<br />
Verbindungspfeile<br />
9.2 Dynamik in Petri-Netzen<br />
Um die ablaufenden Prozesse verfolgen zu können, kann eine Stelle mit einer<br />
Markierung (schwarzer Mittelpunkt ) versehen werden, die anzeigt, dass die<br />
Bedingung erfüllt oder der Zustand eingetreten ist.<br />
Ein Vorteil von Petri-Netzen ist es, mit Hilfe dieser Marken nebenläufige oder<br />
parallele Prozesse (concurrency) darstellen zu können. Von ganz besonderer<br />
Bedeutung ist dabei, zu erkennen, an welcher Stelle des Petri-Netzes<br />
Konfliktsituationen auftreten können und ob Blockierungen des dynamischen<br />
Flusses zu erwarten sind.<br />
Das von anderen Methoden her bekannte Prinzip der schrittweisen Verfeinerung ist<br />
auch bei Petri-Netzen anwendbar, so daß ebenfalls eine top-down-Vorgehensweise<br />
möglich ist. Übersichtlich gestaltet wird dies durch entsprechende<br />
Nummerierungen.<br />
9.3 Regeln in Petri-Netzen<br />
In der folgenden Übersicht werden die einzelnen Regeln beschrieben, nach denen<br />
Petri-Netze aufgebaut sein können:<br />
Regeln
Z1<br />
Z2<br />
Z4<br />
Z5<br />
Z1<br />
Z2<br />
Z3<br />
Z1 E1 Z2 E2<br />
E1<br />
E1<br />
E2<br />
E1<br />
Z 4<br />
Z 5<br />
Z3<br />
Z1<br />
Z2<br />
Z3<br />
Z4<br />
Z5<br />
E 1<br />
E3<br />
E4<br />
E5<br />
Z 1<br />
Z 2<br />
Z 3<br />
Abb. Regeln für den dynamischen Ablauf in Petri-Netzen<br />
Es dürfen nur Knoten unterschiedlicher Art<br />
direkt miteinander verbunden werden: Ein<br />
Zustand (eine Stelle) führt immer direkt zu<br />
mindestens einem Ereignis (einer Transition)<br />
und das wiederum direkt zu mindestens einem<br />
Zustand (einer Stelle).<br />
Ein Ereignis (eine Transition, hier E1) kann<br />
mehrere direkte Vorgängerstellen (Zustände),<br />
die "Eingangsstellen", und mehrere direkte<br />
Nachfolgerstellen (Zustände), die "Ausgangsstellen",<br />
besitzen.<br />
Ebenso kann eine Stelle (ein Zustand, hier Z3)<br />
mehrere Eingangs- oder Ausgangs-ereignisse<br />
(Transitionen) aufweisen.<br />
Ein Ereignis wird nur dann stattfinden (eine<br />
Transition wird aktiv), wenn alle Eingangsbedingungen<br />
erfüllt sind, d.h. alle Eingangsstellen<br />
eine Marke tragen.<br />
Findet das Ereignis einer aktivierten Transition<br />
statt, so schaltet oder "feuert" die Transition.<br />
Dieser Übergang von den Eingangsstellen<br />
zu den Ausgangsstellen wird so dargestellt,<br />
dass die Markierung bei allen<br />
Eingangsstellen entfernt und bei allen Ausgangsstellen<br />
hinzugefügt wird.<br />
Diese Grundregeln sind bei der Darstellung und Simulation von Situationen stets<br />
einzuhalten. Trotz dieser einfachen Regeln sind aufgrund der vielfältigen<br />
Anordnung sehr komplexe Situationen darstellbar.<br />
245
246<br />
9.4 Komplexe Situationen in Petri-Netzen<br />
Wesentliche komplexe Situationen in Petri-Netzen sind die Nebenläufigkeit, bei<br />
der parallele Vorgänge simuliert werden und Blockierung (deadlock), bei der durch<br />
die Anordnung von Stellen und Transitionen gewollte oder ungewollte Situationen<br />
auftreten, die nicht auflösbar sind. Die folgende Abbildung zeigt die beiden<br />
Situationen.<br />
Z 1<br />
Z 2<br />
Z3<br />
Z1<br />
E 1<br />
Z 3<br />
Z 4<br />
Abb. Komplexe Situationen<br />
9.5 Kontakt- und Konfliktsituation<br />
Z 5<br />
E2<br />
E1<br />
E 2<br />
E 3<br />
Z2<br />
Z 6<br />
Z 7<br />
Nebenläufigkeit (concurrency)<br />
Sind mehrere Ereignisse aktiviert,<br />
können alle Ereignisse (die keine<br />
gemeinsamen Eingangsstellen haben,<br />
hier E2 und E3) willkürlich feuern.<br />
Damit sind parallel ablaufende Vorgänge<br />
darstellbar.<br />
Blockierung (deadlock)<br />
Wenn kein Ereignis aktiviert werden<br />
kann, weil z.B. zwei Eingangsstellen<br />
niemals gleichzeitig markiert werden<br />
können, ist dieser Zweig des Petri-<br />
Netzes blockiert. Es liegt entweder ein<br />
Entwurfs- oder Darstellungsfehler vor,<br />
oder aber die dargestellte Situation stellt<br />
eine reale Blockade dar.
Kontakt- und Konfliksituationen treten dann auf, wenn durch die Markenbelegung<br />
ein Schalten nicht möglich ist (Kontakt) bzw. durch die Konstellation des Netzes<br />
unterschiedliche Schaltungen bei gleichem Ausgangszustand möglich sind. Die<br />
folgende Abbildung zeigt die beiden Situationen.<br />
Z 1 Z 3<br />
Z 2<br />
E 1<br />
E 1<br />
E 2<br />
Z 4<br />
andere Darstellungsweise:<br />
Abb. Kontakt- und Konfliktsituationen<br />
9.6 Gabel und Zusammenführung<br />
1<br />
2<br />
Kontakt<br />
Z4 ist makiert 2<br />
E1 kann nicht schalten, obwohl Z1 und<br />
Z2 markiert sind.<br />
Konflikt<br />
Schalten von E1 (bzw. E2), führt<br />
dazu, dass E2 (bzw. E1) nicht mehr<br />
schalten kann<br />
Die folgenden Situationen zeigen die typische Konstellation bei Graphen, wenn in<br />
einen Knoten zwei Kanten einlaufen und eine wieder heraus oder – umgekehrt –<br />
eine Kante hineinläuft und zwei wieder hinaus. Die Abbildung zeigt die daraus<br />
entstehenden vier Situationen.<br />
247
248<br />
Verzweigung<br />
(branch)<br />
Beim Markenspiel kann nur ein<br />
Zweig durchlaufen werden<br />
Aufspaltung<br />
(split)<br />
Die Wirkung wird<br />
gleichberechtigt verteilt, d.h. ein<br />
Pfeil löst mehrere nebenläufige<br />
Aktionen aus (beide<br />
auslaufenden Pfeile<br />
transportieren <strong>beim</strong> Schalten<br />
eine Marke)<br />
Abb. Gabel und Zusammenführung<br />
9.7 Beispiele von Petri-Netzen<br />
Stelle<br />
Transition<br />
Begegnung (Wettbew.)<br />
(meet)<br />
Nur über einen Zweig kann die<br />
Marke belegt werden (logisches<br />
XOR)<br />
Sammlung<br />
(wait)<br />
Es kann erst geschaltet werden,<br />
wenn alle einlaufenden Pfeile<br />
eingetroffen sind (aufeinander<br />
gewartet haben; logisches UND)<br />
Das Hauptmann von Köpenik-Problem eignet sich, um die Blockierung eines Petri-<br />
Netzes aufzuzeigen. Die Abbildung zeigt das passende Petri-Netz.
Abb. Das Hauptmann von Köpenik-Problem (Blockierung)<br />
Liegt in Z1 eine Marke, in Z2 und Z3 aber nicht, dann liegt das Problem des<br />
Hauptmannes von Köpenick vor. Die Arbeitserlaubnis (E1) kann nicht gegeben<br />
werden, da keine Aufenthaltsgenehmigung (Z3) vorliegt. Daher wird Z2 (Arbeit<br />
bei einer Firma) nicht erfüllbar sein. Ohne die Arbeit bei einer Firma, gibt es<br />
allerdings keine Aufenthaltsgenehmigung (Z3). Es liegt die bekannte Blockierung<br />
vor (weder Arbeit noch Aufenthaltsgenehmigung können erlaubt werden).<br />
Im folgenden Beispiel wird ein einfaches Betriebssystem in seinem Ablauf<br />
simuliert. Dieses System kann nur jeweils einen Auftrag abarbeiten, bevor der<br />
nächste Auftrag gestartet werden kann. Voraussetzung für dieses restriktive<br />
Vorgehen ist, dass es nicht erlaubt ist, dass mehrere Marken in einem<br />
Zustandsknoten liegen können.<br />
249
250<br />
Abb. Ein einfaches Betriebssystem-Modell<br />
Für ein weiteres Anwendungsbeispiel wird ein sehr einfacher und von vielen<br />
Einflußfaktoren (vor allem der Zeit) ‘bereinigter’ Ausschnitt eines Flug- und<br />
Flugzeugumlaufplans unterstellt, in dem lediglich die Zuordnung von Flugzeugen<br />
zu Flugstrecken (Flug-Nr.) und Umsteigemöglichkeiten für Passagiere<br />
(‘Zubringerfunktion’) zu beachten sind. Mit dem ersten Fall ist eine notwendige<br />
technische, mit dem zweiten Fall eine ökonomisch erwünschte Bedingungsklasse<br />
für den Flugverkehr eingeführt. Beide sollen im Folgenden jedoch zunächst<br />
unterschiedslos als ‘unabdingbare’ Bedingungen behandelt werden.<br />
Der ‘Flugplanaussschnitt’ sieht folgende Aktionsmuster vor:<br />
Flug-Nr. Strecke Flugzeug<br />
151 Köln (CGN=5) – Frankfurt (FRA=1)<br />
A<br />
Zubringer<br />
für Flug-Nr.<br />
131 München (MUC=3) - Frankfurt B 211,411<br />
141 Düsseldorf (DUS=4) - Frankfurt C<br />
211 Frankfurt - Hamburg (HAM=2) C<br />
511 Frankfurt - Köln B<br />
411 Frankfurt - Düsseldorf A
Setzt man nun als Ereignis die Flug-Nr., die für den Controller zugleich<br />
Informationen über die Strecke und die Abwicklungszeit beinhaltet, und als<br />
Zustände alle die Bedingungen, die für die Realisierung der Flug-Nr. unabdingbar<br />
sind (sein sollen), hier also ‘Flugzeug Z für Flug-Nr. X vorhanden’ (z.B. ‘A 151’),<br />
‘Flugzeug Z für Flug-Nr. X flugbereit’ (z.B. ‘A 151 ok’) und ‘Umsteigepassagiere<br />
von Flug-Nr. X für den Weiterflug bereit’ (z.B. ‘PAX 131’), so können dem<br />
Flugplan hinsichtlich Flug-Nr. 252 die folgenden Zustands-Ereignis-Abbildungen<br />
entnommen werden:<br />
Jedes Element dieser Auflistung wird in der Sprache der Petri-Netz-Theorie als<br />
Abbildung eines Prozesses bezeichnet (z.B. „Der Zustand ‘Flugzeug A 151<br />
befindet sich am Boden’ wird durch Ereignis 151 beendet“). Die Gesamtheit der in<br />
dieser Form systematisch aufgelisteten Prozesse eines Flugplans heißt das<br />
zugehörige ‘unverbundene Netz’.<br />
Die Verbindung der Elemente des unverbundenen Netzes zu einem<br />
zusammenhängenden Prozeßnetz ist gleichbedeutend mit der Definition der co-<br />
Relation. Hier verlangt die Ermittlung der co-Relation eine systematische<br />
Überprüfung und Fixierung der im Flugplan zum Ausdruck gebrachten (geplanten,<br />
aber durchaus nicht unproblematischen, weil z.B. durch Nebel und ähnliches<br />
störanfälligen) Zusammenhänge zwischen den einzelnen Prozessen.<br />
251
252<br />
Dieses Netz entspricht einer möglichen Übersetzung des Flugplanes in ein Petri-<br />
Netz und zwar hier in ein zustandsunverzweigtes Netz, also ein<br />
Synchronisationsnetz.<br />
9.8 Varianten von Petri-Netzen<br />
Für Petri-Netze sind verschiedene Varianten entwickelt worden, die für jeweils<br />
unterschiedliche Problemklassen entwickelt wurden. Die folgenden Varianten sind<br />
[Balzert] entnommen:
9.8.1 Bedingungs-/Ereignis-Netze<br />
Bedingungs-/Ereignis-Netze zeichnen sich dadurch aus, dass die Objekte bzw.<br />
Marken vom Typ boolean sind. Transitionen werden als Ereignisse interpretiert.<br />
Stellen bilden dann Bedingungen. Jede Stelle kann genau eine oder keine Marke<br />
enthalten. Eine Transition t kann schalten, wenn jede Eingabestelle von t eine<br />
Marke enthält und wenn jede Ausgabestelle von t leer ist.<br />
9.8.2 Stellen-/Transitions-Netze<br />
Stellen können bei dieser Variante mehrere Marken enthalten. Transitionen müssen<br />
so viele Marken <strong>beim</strong> Schalten wegnehmen oder hinzufügen, wie die Gewichte an<br />
den Pfeilen angeben. Soll eine Stelle eine Kapazität größer 1 erhalten, dann wird<br />
dies durch „K = ...“ an der Stelle notiert. Die Kapazität definiert die maximale<br />
Anzahl von Marken, die auf einer Stelle liegen dürfen. Mit dieser Variante ist eine<br />
höhere Komplexität der Beziehungen darstellbar. Jedoch erfordern die Stellen-/<br />
Transitions-Netze eine klare Übersicht über das System und sind in ihrer<br />
Anwendung sehr komplex.<br />
253
254<br />
10 Entscheidungstabellen<br />
10.1 Grundlagen<br />
Entscheidungstabellen (ET) dienen dazu, Entscheidungsprozesse in übersichtlicher,<br />
tabellarischer Form darzustellen und helfen somit komplexe Verarbeitungsregeln<br />
zu spezifizieren. Eine Entscheidungstabelle fasst eine Menge aussagenlogischer<br />
Regeln zusammen. Entscheidungstabellen wurden 1957 in einer Projektgruppe der<br />
General Electric Company entwickelt und sind in DIN 66241 genormt [Balz96].<br />
Eine Entscheidungstabelle besteht im Wesentlichen aus vier Quadranten für<br />
2. Bedingungen<br />
3. Aktionen<br />
4. Bedingungsanzeiger und<br />
5. Aktionsanzeiger<br />
Bei einer ET werden die Bedingungsanzeiger mit den jeweiligen Aktionsanzeiger<br />
verknüpft. Jede Spalte stellt hierbei eine Regel dar, die durch eine Regelnummer<br />
eindeutig bezeichnet wird. Die Regelnnummern werden über den<br />
Bedingungsanzeigerquadranten notiert. Nachfolgend ist die Basis-Struktur einer<br />
Entscheidungstabelle dargestellt.<br />
B 1<br />
-<br />
-<br />
B i<br />
A 1<br />
-<br />
-<br />
-<br />
-<br />
A j<br />
B e d i n g u n g e n<br />
A k t i o n e n<br />
E n t s c h e i d u n g s r e g e l n<br />
R 1 . . . . . . . . . . . . . . R n<br />
B e d i n g u n g s a n z e i g e r<br />
b z w .<br />
- a u s p r ä g u n g e n<br />
A k t i o n s a n z e i g e r<br />
b z w .<br />
- a u s p r ä g u n g e n<br />
Abbildung: Struktur einer Entscheidungstabelle [Sch86], [Sch90]<br />
Um eine Entscheidungstabelle aufzubauen, muss zunächst für einen Anwendungs-<br />
Kontext analysiert werden, welche Bedingungen und welche mögliche Aktionen<br />
auftreten können. Diese werden zunächst in die Entscheidungstabelle in den beiden<br />
linken Quadranten eingetragen.
Anschließend werden alle Bedingungskombinationen ermittelt. Ist eine Bedingung<br />
erfüllt, wird "J" (für Ja) in dem Bedingungsanzeigerteil eingetragen. Andernfalls<br />
erfolgt die Eintragung "N" (für Nein). Ist der Erfüllungsgrad einer Bedingung<br />
irrelevant, so wird in der Tabelle "-" (Irrelevanzanzeiger) eingetragen.<br />
10.2 ET-Typen<br />
Bei ET werden unterschiedliche Darstellungsformen für den Bedingungsteil<br />
unterschieden. Werden im Bedingungsanzeigerteil nur die Werte "J", "N" und "-"<br />
sowie "X" im Aktionsanzeigerteil verwendet, wird eine ET als "begrenzt"<br />
bezeichnet. Oft kann eine kompaktere Darstellung erzielt werden, wenn jedoch<br />
textliche Beschreibungen verwendet werden. In diesem Fall spricht man von<br />
"erweiterten" ET.<br />
Eine ET ist vollständig, wenn alle möglichen Bedingungskombinationen auch als<br />
Regeln vorkommen. Es wird hierbei zwischen "formal vollständig" und "inhaltlich<br />
vollständig" unterschieden. Bei einer formal vollständigen Tabelle werden im<br />
Bedingungsanzeigerteil alle möglichen Kombinationen dargestellt. Bei einer<br />
inhaltlich vollständigen Tabelle werden alle praktisch möglichen Kombinationen<br />
aufgeführt, d.h. es fehlen die unlogischen bzw. offensichtlich unmöglichen<br />
Kombinationen.<br />
Da bei n Bedingungen 2 n Bedingungskombinationen auftreten können, versucht<br />
man nur die wichtigsten Regeln darzustellen und die irrelevanten Fälle durch eine<br />
Else-Regel abzudecken. Durch Einsatz der Else-Regel kann somit aus einer<br />
unvollständigen ET eine vollständige ET erzeugt werden.<br />
10.3 Anwendung von Entscheidungstabellen<br />
Im Folgenden soll an einem Beispiel die Erstellung einer ET beschrieben werden.<br />
Diese dient zur Darstellung des Problemlösungswissens einer Universitätsbibliothek,<br />
die die Ausleihe von Büchern durch ein Software-System<br />
unterstützt. Gemäß der fachlichen Problemstellung müssen verschiedene Fälle<br />
betrachtet werden, wann ein Buch ausgeliehen werden kann. Einige Regeln lauten:<br />
/1/ Wenn ein Benutzer bekannt ist und kein Sperrvermerk für diesen Benutzer<br />
existiert, kann dieser das Buch ausleihen-vorausgesetzt es ist vorhanden.<br />
/2/ Auch wenn ein Benutzer gesperrt ist, dieser jedoch bekannt ist, kann ein Buch<br />
mittels Einzahlungsbeleg ausgeliehen werden.<br />
/3/ Wenn ein Buch nicht vorhanden ist, kann nicht ausgeliehen werden. Allerdings<br />
ist eine Vormerkung möglich, auch wenn der Benutzer gesperrt ist.<br />
255
Bedingungen<br />
B1Benutzer<br />
bekannt<br />
B2Benutzer<br />
gesperrt<br />
B3Buch<br />
vorhanden<br />
B4Einzahlungsbeleg<br />
Aktionen<br />
A1Buch<br />
ausleihen<br />
A2 nicht ausleihen, gesperrt<br />
A3vormerken<br />
A4Systemfehler<br />
A5Einzahlung<br />
eingeben<br />
A6keine<br />
Aktion<br />
256<br />
/4/ Wenn ein Benutzer im System nicht bekannt ist, dieser aber als gesperrt<br />
vermerkt ist, liegt ein Systemfehler vor.<br />
Aus der Problembeschreibung folgt die ET, die in der folgenden Abbildung<br />
dargestellt ist.<br />
R1 R2 R3 R4 R5 R6 R7<br />
J<br />
J J J J N N<br />
N J J N J J J<br />
J J J N N<br />
- J N -<br />
x x<br />
Entscheidungsregeln<br />
Bedingungsanzeiger<br />
x<br />
J<br />
-<br />
N<br />
Aktionsanzeiger<br />
x<br />
x x<br />
-<br />
J<br />
x x<br />
Abbildung: Begrenzte Entscheidungstabelle zur Darstellung des<br />
Problemlösungswissens einer Universitätsbibliothek [Sch86]<br />
Die dargestellte ET ist ein Beispiel für eine begrenzte, unvollständige ET. Sie ist<br />
"begrenzt", da nur Ja-/Nein- sowie "-" Angaben im Bedingungsanzeiger gemacht<br />
werden. Die ET ist "unvollständig", da nicht alle 16 Ja-/Nein-Kombinationen der 4<br />
Bedingungen B1 bis B4 ausgeführt sind, sondern die Tabelle durch die Else-Regel<br />
verkürzt ist.<br />
Vereinfachte Entscheidungstabelle<br />
ET mit mehr als 4 Bedingungen können nur recht schwierig dargestellt werden.<br />
Aus diesem Grunde empfiehlt es sich, diese zu konsolidieren. So können Spalten,<br />
die den gleichen Aktionsteil haben, zusammengefasst werden. Es entsteht dadurch<br />
eine vereinfachte Entscheidungstabelle. In der obigen ET kann z.B. eine<br />
Zusammenfassung von Spalte 4 und 5 bzw. 6 und 7 erfolgen.
Zusätzlich kann durch Darstellung des Else-Zweiges eine vollständige ET erzeugt<br />
werden. Das Ergebnis dieser Konsolidierung ist in der nachfolgenden Abbildung<br />
dargestellt.<br />
B1<br />
B2<br />
B3<br />
B4<br />
A1<br />
A2<br />
A3<br />
A4<br />
A5<br />
A6<br />
Benutzer bekannt<br />
Benutzer gesperrt<br />
Buch vorhanden<br />
Einzahlungsbeleg<br />
Buch ausleihen<br />
nicht ausleihen, gesperrt<br />
vormerken<br />
Systemfehler<br />
Einzahlung eingeben<br />
keine Aktion<br />
R1 R2 R3 R4´ R5´<br />
J J J J N<br />
N - J - J<br />
J J J N<br />
- J N - -<br />
x x<br />
x<br />
x<br />
-<br />
x<br />
ELSE<br />
Abbildung: Ausleihverkehr einer Universitätsbibliothek als vereinfachte<br />
Entscheidungstabelle dargestellt [Sch86]<br />
Sofern noch weitere Regeln aufgrund einer fachlichen Analyse als notwendig<br />
erscheinen, kann die ET entsprechend angepasst werden. Als Beispiel könnte<br />
gefordert sein, dass ein Benutzer maximal 4 Bücher ausleihen und ein Buch<br />
maximal zweimal verlängert werden darf. Diese Regeln werden am günstigsten<br />
durch textuelle Angaben realisiert. In der nachfolgenden Abbildung ist eine<br />
erweiterte ET als Beispiel angegeben.<br />
x<br />
x<br />
257
258<br />
B 1<br />
B 2<br />
B 3<br />
B 4<br />
B 5<br />
B 6<br />
B e d i n g u n g e n<br />
B e n u t z e r b e k a n n t<br />
A n z a h l a u s g e l i e h e n e B ü c h e r<br />
B e n u t z e r g e s p e r r t<br />
B u c h v o r h a n d e n<br />
A n z a h l V e r l ä n g e r u n g e n<br />
E i n z a h l u n g s b e l e g<br />
B 7 A n z a h l M a h n u n g e n<br />
A 1<br />
A 2<br />
A 3<br />
A 4<br />
A k t i o n e n<br />
B u c h a u s l e i h e n<br />
B u c h v e r l ä n g e r n<br />
M a h n g e b ü h r<br />
. . . . . . . . . . .<br />
R 1 R 2 R 3 R 4 R 5 R 6 R 7<br />
J J J J J<br />
X<br />
E n t s c h e i d u n g s r e g e l n<br />
B e d i n g u n g s a n z e i g e r<br />
A k t i o n s a n z e i g e r<br />
J J J<br />
< 5 < 5 < 5 < 5 - - - -<br />
N J N J N J N J<br />
J J - - - - - -<br />
- -<br />
- J - J - -<br />
- - - -<br />
X<br />
≤ 2 ≤ 2<br />
X X<br />
- - - -<br />
- -<br />
R 8<br />
1 - 3 1 - 3 4 , 5 4 , 5<br />
1 D M 2 D M 2 D M 3 D M<br />
Abbildung: Ausleihverkehr einer Universitätsbibliothek als gemischte<br />
Entscheidungstabelle dargestellt [Sch86]<br />
10.4 Entscheidungsbaum<br />
Neben der Quadrantendarstellung mit vertikaler Anordnung der Regeln wird in der<br />
Praxis auch gerne eine horizontale Darstellung der Entscheidungstabelle<br />
vorgenommen. In der folgenden Abbildung ist ein Beispiel hierfür angegeben<br />
[Balz96].<br />
Kreditgrenze<br />
überschritten?<br />
Zahlungs-<br />
Verhalten<br />
einwandfrei?<br />
Überschreitungsbetrag<br />
< 500 Euro?<br />
Scheck<br />
einlösen<br />
Scheck<br />
nicht<br />
einlösen<br />
Neue<br />
Konditionen<br />
vorlegen<br />
J J J X<br />
N X X<br />
N J X<br />
N X<br />
N J J X<br />
N X<br />
N J X<br />
N X<br />
unlogisch<br />
Abbildung: Entscheidungstabelle in horizontaler Darstellungsform [Balz96]
Aus einer Entscheidungstabelle in horizontaler Darstellungsform lässt sich leicht<br />
die Darstellung eines Entscheidungsbaums ableiten. Hierbei werden die<br />
Alternativen explizit ausgeführt. Für obiges Beispiel wird nachfolgend die<br />
äquivalente Baumdarstellung angegeben.<br />
Scheckeinlösung<br />
Kreditgrenze<br />
nicht überschritten<br />
Kreditgrenze<br />
nicht überschritten<br />
Zahlungsverhalten<br />
einwandfrei<br />
Zahlungsverhalten<br />
nicht einwandfrei<br />
Zahlungsverhalten<br />
einwandfrei<br />
Zahlungsverhalten<br />
nicht einwandfrei<br />
Überschreitungsbetrag<br />
< 500 Euro<br />
Überschreitungsbetrag<br />
>= 500 Euro<br />
Überschreitungsbetrag<br />
< 500 Euro<br />
Überschreitungsbetrag<br />
>= 500 Euro<br />
Überschreitungsbetrag<br />
< 500 Euro<br />
Überschreitungsbetrag<br />
>= 500 Euro<br />
Überschreitungsbetrag<br />
< 500 Euro<br />
Überschreitungsbetrag<br />
>= 500 Euro<br />
Abbildung: Entscheidungstabelle als Entscheidungsbaum [Balz96]<br />
Scheck einlösen<br />
Scheck einlösen<br />
und neue<br />
Konditionen<br />
verlegen<br />
Scheck nicht<br />
einlösen<br />
Scheck nicht<br />
einlösen<br />
Scheck einlösen<br />
Unlogisch<br />
Scheck einlösen<br />
Unlogisch<br />
Für das im vorherigen Abschnitt erwähnte Beispiel ist abschließend die alternative<br />
Darstellung als Entscheidungsbaum angegeben.<br />
259
260<br />
B e n u t z e r<br />
b e k a n n t<br />
S o n s t<br />
w e n i g e r a l s<br />
5 B ü c h e r<br />
a u s g e l i e h e n<br />
B e n u t z e r<br />
n i c h t<br />
g e s p e r r t<br />
B e n u t z e r<br />
g e s p e r r t<br />
B e n u t z e r<br />
n i c h t<br />
g e s p e r r t<br />
B e n u t z e r<br />
g e s p e r r t<br />
B u c h v o r h a n d e n<br />
A n z a h l V e r l ä n g e r u n g e n<br />
≤ 2<br />
B u c h v o r h a n d e n<br />
A n z a h l V e r l ä n g e r u n g e n<br />
≤ 2<br />
A n z a h l M a h n u n g e n<br />
1 - 3<br />
A n z a h l M a h n u n g e n<br />
4 - 5<br />
A n z a h l M a h n u n g e n<br />
1 - 3<br />
A n z a h l M a h n u n g e n<br />
4 - 5<br />
Abbildung: Entscheidungsbaum "Buch ausleihen"<br />
E i n z a h l u n g s -<br />
b e l e g<br />
v o r h a n d e n<br />
E i n z a h l u n g s -<br />
b e l e g<br />
v o r h a n d e n<br />
B u c h a u s l e i h e n<br />
B u c h v e r l ä n g e r n<br />
B u c h a u s l e i h e n<br />
B u c h v e r l ä n g e r n<br />
1 D M<br />
2 D M<br />
2 D M<br />
3 D M<br />
K e i n e A k t i o n<br />
Wie den Darstellungen der Entscheidungsbäume entnommen werden kann, ist<br />
diese alternative Darstellungsform insoweit semantisch nicht mit der vertikalen<br />
Darstellungsform identisch, da <strong>beim</strong> Entscheidungsbaum eine Abarbeitungsfolge<br />
von links nach rechts festgelegt ist.<br />
10.5 Weiterführende Literatur<br />
[Balz96] H. Balzert, Lehrbuch der Software-Technik: Software-Entwicklung,<br />
Spektrum Akademischer Verlag, 1996.<br />
[Sch86] H.-J. Schneider, Lexikon der <strong>Informatik</strong> und Datenverarbeitung,<br />
Oldenburg, 1986.<br />
[Sch89] F. Schöntaler, Rapid Prototyping zur Unterstützung des Konzeptuellen<br />
Entwurfs von Informationssystemen, Dissertation, Universität<br />
Karlsruhe, Fakultät Wirtschaftswissenschaften, 1989.<br />
[Sch90] A. Schulz, Software Entwurf, P. Oldenburg Verlag, München Wien, 1990.