softwaretechnik - Fachbereich Informatik
Transcrição
softwaretechnik - Fachbereich Informatik
SOFTWARETECHNIK Wintersemester 2005/06 Version 1 : Stand: 27.05.04 Version 2 : Stand: 27.11.04 Version 3: Stand: 10.11.05 Urs Andelfinger, Frank Bühler, Michael Guist, Stephan Karczewski, Gerhard Raffius, Inge Schestag, Wolfgang Weber, Gerhard Winkler 1 * * 1 * * 1 Vorwort Stand 01.03.04 Sehr geehrter Leser, sehr geehrte Leserin, mit dieser Veröffentlichung lesen Sie ein Hochschulskript, das für die Studierenden am Fachbereich Informatik erstellt wurde. Dementsprechend handelt es sich weder um ein Lehrbuch noch um ein Fachbuch zur Softwaretechnik. Hinweise auf Lehr- und Fachbücher finden Sie im Literaturverzeichnis. Die Autoren dieses Skriptes empfehlen Ihnen dringend neben dem Besuch der Vorlesung auch in diesen Quellen nachzulesen und damit zu arbeiten. Die aktuellen Studien- und Prüfungsordnungen sehen vor, dass die Studierenden im Studiengang Informatik die Lehrveranstaltung Softwaretechnik im 2. und 3. Studiensemester besuchen. Neben der Vorlesung mit insgesamt 4 Semesterwochenstunden ist zusätzlich ein Praktikum mit insgesamt 3 Semesterwochenstunden verpflichtend vorgesehen. Beide Teile sind nach Meinung des Fachbereichs dringend nötig, um die Lehr- und Lerninhalte kennen zu lernen, zu verstehen, anwenden zu können und somit zu beherrschen. Vorlesung und Praktikum sind als integrierte Lehrveranstaltung konzipiert, d.h. auch, dass es aus Sicht der Lehrenden keinen Sinn macht, nur einen der beiden Teile zu absolvieren. Wenn dies aus besonderen Gründen (z.B. Nichtbestehen der Prüfung) einmal nötig werden sollte, wird diese Situation zwar akzeptiert, sie ist aber weder empfehlenswert noch etwas, was Sie anstreben sollten. Abgeschlossen werden soll die Lehrveranstaltung mit den Prüfungsleistungen Softwaretechnik I und Softwaretechnik II nach dem 2. und 3. Semester. Dieses Skript ist aber "nur" zur Unterstützung der Lehrveranstaltung Softwaretechnik entwickelt worden, zur Vorbereitung der Prüfungen also keinesfalls 2 ausreichend. Die Autoren weisen ausdrücklich darauf hin, dass dieses Skript konzipiert und entwickelt wurde, um Ihnen den Besuch der Lehrveranstaltung und die Bearbeitung der Inhalte zu erleichtern und nicht zu ersetzen. Neben den Abbildungen von in der Vorlesung verwendeten Schaubildern und Folien enthält das Skript in knapper Form die wichtigsten Aussagen und Lehrinhalte. Beispiele, Fragen und Musterlösungen runden den Inhalt ab und sollen Ihnen Anregungen für eigenes Arbeiten und Nachdenken liefern. 3 Inhaltsverzeichnis 1 Einführung.........................................................................................11 1.1 Was ist ein gutes Softwaresystem?................................................................11 1.2 Was ist Softwaretechnik?...............................................................................12 1.3 Geschichtliche Entwicklung...........................................................................13 1.4 Softwarequalität.............................................................................................14 1.5 Software-Qualitätseigenschaften...................................................................15 1.6 Phasen der Softwareentwicklung...................................................................19 1.7 Überblick über den Aufbau des SWT-Skriptes..............................................23 2 Objektorientierung............................................................................25 2.1 Einführung......................................................................................................25 2.2 Prinzipien der Objektorientierung..................................................................26 2.2.1 Abstraktion..............................................................................................26 2.2.2 Kapselung................................................................................................26 2.2.3 Wiederverwendung..................................................................................27 2.2.4 Beziehungen............................................................................................28 2.2.5 Polymorphismus......................................................................................28 2.3 Überblick Objektorientierte Programmiersprachen.......................................29 2.3.1 C++..........................................................................................................29 2.3.2 JAVA.......................................................................................................30 2.3.3 C#.............................................................................................................30 2.4 Werkzeuge für die objektorientierte Entwicklung.........................................31 2.5 Weiterführende Literatur................................................................................32 3 UML Unified Modeling Language...................................................33 3.1 Was ist die UML?...........................................................................................33 3.2 Entstehung der UML......................................................................................33 3.3 Diagramme der UML 2.0...............................................................................34 3.3.1 Klassendiagramm Class Diagram..........................................................37 3.3.1.1 Zweck...............................................................................................37 3.3.1.2 Notation............................................................................................37 3.3.1.3 Anwendungsbereich.........................................................................49 3.3.1.4 Zusammenhang................................................................................50 3.3.1.5 Hinweise für die Praxis....................................................................50 3.3.1.6 Beispiel.............................................................................................52 3.3.2 Objektdiagramm - Object Diagram.........................................................54 3.3.2.1 Zweck...............................................................................................54 3.3.2.2 Notation............................................................................................55 4 3.3.2.3 Beispiel.............................................................................................55 3.3.3 Komponentendiagramm - Component Diagram....................................55 3.3.3.1 Zweck...............................................................................................56 3.3.3.2 Notation............................................................................................56 3.3.3.3 Anwendungsbereich.........................................................................57 3.3.3.4 Zusammenhang ...............................................................................57 3.3.3.5 Hinweise für die Praxis....................................................................57 3.3.3.6 Beispiel.............................................................................................58 3.3.4 Paketdiagramm - Package Diagram........................................................58 3.3.4.1 Zweck...............................................................................................58 3.3.4.2 Notation............................................................................................59 3.3.4.3 Anwendungsbereich.........................................................................59 3.3.4.4 Zusammenhang ...............................................................................60 3.3.4.5 Beispiel ............................................................................................60 3.3.5 Anwendungsfalldiagramm - Use Case Diagram.....................................61 3.3.5.1 Zweck...............................................................................................61 3.3.5.2 Notation ...........................................................................................61 3.3.5.3 Anwendungsbereich.........................................................................63 3.3.5.4 Zusammenhang ...............................................................................64 3.3.5.5 Hinweise für die Praxis....................................................................65 3.3.5.6 Beispiel ............................................................................................66 3.3.6 Sequenzdiagramm - Sequence Diagram.................................................68 3.3.6.1 Zweck...............................................................................................68 3.3.6.2 Notation............................................................................................68 3.3.6.3 Anwendungsbereich.........................................................................71 3.3.6.4 Zusammenhang ...............................................................................72 3.3.6.5 Hinweis für die Praxis......................................................................72 3.3.6.6 Beispiel ............................................................................................73 3.3.7 Kommunikationsdiagramm - Communication Diagram........................77 3.3.7.1 Zweck................................................................................................77 3.3.7.2 Notation............................................................................................77 3.3.7.3 Anwendungsbereich.........................................................................77 3.3.7.4 Zusammenhang ...............................................................................77 3.3.7.5 Hinweise für die Praxis....................................................................78 3.3.7.6 Beispiel ............................................................................................78 3.3.8 Zeitverlaufsdiagramm - Timing-Diagram...............................................79 3.3.8.1 Zweck...............................................................................................79 3.3.8.2 Notation............................................................................................79 3.3.8.3 Anwendungsbereich.........................................................................80 5 3.3.8.4 Zusammenhang................................................................................80 3.3.8.5 Hinweis für die Praxis......................................................................80 3.3.8.6 Beispiel.............................................................................................80 3.3.9 Interaktionsübersicht Diagramm - Interaction Overview Diagram........81 3.3.9.1 Zweck...............................................................................................81 3.3.9.2 Anwendungsbereich.........................................................................82 3.3.9.3 Zusammenhang................................................................................82 3.3.9.4 Hinweis für die Praxis......................................................................82 3.3.9.5 Beispiel.............................................................................................82 3.3.10 Zustandsautomat-State Machine Diagram............................................83 3.3.10.1 Zweck.............................................................................................83 3.3.10.2 Notation..........................................................................................84 3.3.10.3 Anwendungsbereich.......................................................................89 3.3.10.4 Zusammenhang..............................................................................89 3.3.10.5 Hinweis für die Praxis....................................................................89 3.3.10.6 Beispiel...........................................................................................90 3.3.11 Aktivitätsdiagramm - Activity Diagram...............................................91 3.3.11.1 Zweck.............................................................................................91 3.3.11.2 Notation..........................................................................................92 3.3.11.3 Anwendungsbereich.......................................................................96 3.3.11.4 Zusammenhang..............................................................................96 3.3.11.5 Hinweise für die Praxis..................................................................97 3.3.11.6 Beispiel...........................................................................................98 3.3.12 Verteilungsdiagramm - Deployment-Diagram...................................100 3.3.12.1 Zweck...........................................................................................100 3.3.12.2 Notation........................................................................................101 3.3.12.3 Beispiel.........................................................................................101 3.3.13 Kompositionsstrukturdiagramm - Composite Structure Diagram......102 3.3.13.1 Zweck...........................................................................................102 3.3.13.2 Notation........................................................................................102 3.3.13.3 Anwendungsbereich.....................................................................103 3.3.13.4 Neu in UML 2..............................................................................103 3.4 Object Constraint Language.........................................................................103 3.5 Model Driven Architecture...........................................................................104 3.5.1 Was ist MDA?.......................................................................................104 3.5.2 Motivation..............................................................................................104 3.5.3 Wie funktioniert MDA?.........................................................................105 3.6 UML Profile..................................................................................................106 4 Vorgehens- und Prozessmodelle.....................................................107 6 4.1 Überblick (Motivation, Begriffe).................................................................107 4.2 Das objektorientierte Projekt........................................................................108 4.3 Wasserfallmodell, Evolutionäres Modell, Iteratives Modell.......................109 4.4 Prototyping ...................................................................................................115 4.5 Das V-Modell................................................................................................117 4.5.1 Struktur des Standardisierungskonzeptes..............................................118 4.5.2 Eigenschaften des V-Modells................................................................120 4.5.3 Produktzustände und Übergänge...........................................................120 4.5.4 Erzeugnisstruktur...................................................................................120 4.5.5 Struktur und Inhalt des V-Modells.......................................................121 4.5.6 Aktivitäten und Produkte.......................................................................121 4.5.7 Aktivitätenzerlegung..............................................................................122 4.5.8 Produktfluss und Abwicklung...............................................................123 4.5.9 Die Submodelle.....................................................................................123 4.5.10 Zusammenspiel der Submodelle.........................................................124 4.5.11 Submodell "Softwareerstellung" (SWE).............................................124 4.5.12 Systemanforderungsanalyse und -entwurf (SWE 1)...........................125 4.5.13 Systemanforderungsanalyse und -entwurf (SWE 1)...........................125 4.5.14 DV-Anforderungsanalyse und -entwurf (SWE 2)..............................125 4.5.15 DV-Anforderungsanalyse und -entwurf (SWE 2)..............................126 4.5.16 SW-Anforderungsanalyse (SWE 3)....................................................126 4.5.17 Grobentwurf (SWE 4).........................................................................126 4.5.18 Feinentwurf (SWE 5)..........................................................................127 4.5.19 Implementierung (SWE 6)..................................................................127 4.5.20 SW-Integration (SWE 7).....................................................................127 4.5.21 DV-Integration (SWE 8).....................................................................127 4.5.22 Produkte im Submodell SWE.............................................................128 4.5.23 Submodell"Qualitätssicherung" .........................................................128 4.5.24 Aktivitäten im Submodell QS.............................................................128 4.5.25 Aktivitäten im Submodell KM............................................................129 4.5.26 Submodell "Projektmanagement" (PM).............................................129 4.5.27 Aktivitäten im Submodell PM.............................................................130 4.5.28 Rollen im V-Modell............................................................................130 4.5.29 Tailoring...............................................................................................130 4.5.30 Zusammenfassung...............................................................................131 4.6 RUP ..............................................................................................................132 4.6.1 RUP-Phase "Inception".........................................................................133 4.6.2 RUP-Phase "Elaboration"......................................................................134 4.6.3 RUP-Phase "Construction"....................................................................135 7 4.6.4 RUP-Phase "Transition"........................................................................136 4.7 eXtreme Programming (XP).........................................................................137 4.7.1 Warum XP?............................................................................................137 4.7.2 Die zwölf Praktiken...............................................................................137 4.7.3 Der XP Prozess......................................................................................140 4.7.4 Die Umsetzung......................................................................................143 4.7.5 Weiterführende Literatur.......................................................................144 4.7.5.0.1 Literatur...................................................................................144 4.8 Prozessorientiertes Software-Qualitätsmanagement....................................144 4.8.1 Überblick ..............................................................................................145 4.8.2 Das ISO 15504 / ISO 12207 (SPICE) Prozessmodell..........................148 4.8.2.1 Die Kunden Lieferanten Kategorie (CUS)....................................149 4.8.2.2 Die Engineering Kategorie.............................................................151 4.8.2.3 Die unterstützenden Prozesse ........................................................153 4.8.2.4 Die Management Prozess Kategorie..............................................158 4.8.2.5 Die Organisations Prozeß Kategorie..............................................160 4.8.2.6 Prozeß Tailoring.............................................................................162 4.8.3 Das ISO 15504 / ISO 12207 Reifegradmodell.....................................162 4.8.3.1 Stufe 0 - Unvollständiger Prozess (Incomplete)............................164 4.8.3.2 Stufe 1 - Durchgeführter Prozess (Performed) .............................165 4.8.3.3 Stufe 2 - Gelenkter Prozess (Managed). .......................................165 4.8.3.4 Stufe 3 - Etablierter Prozess (Established). ...................................166 4.8.3.5 Stufe 4 - Quantitativ steuerbarer und vorhersagbarer Prozess (Predictable) ...............................................................................................168 4.8.3.6 Stufe 5 - Optimierender Prozess (Optimizing). ............................169 4.8.4 Anwendungsbeispiel der ISO 15504/12207: Reifegradstufen im Projektmanagement........................................................................................171 4.8.5 Risikomanagement gemäß ISO 15504 / ISO 12207 ............................173 4.8.6 Assessments gemäß ISO 15504 / ISO 12207 ......................................176 4.8.7 Das CMMI-Modell................................................................................179 4.8.8 Literatur .................................................................................................182 5 Requirements Engineering..............................................................183 5.1 Textuelle Beschreibung von Anwendungsfällen..........................................183 6 Der Qualitätsbegriff und die Qualitätskriterien für Software.....195 6.1 Die Qualitätseigenschaften beim fertigen Produkt:......................................195 6.1.1 Wichtige Kriterien aus Benutzersicht....................................................196 6.1.2 Wichtige Kriterien aus Entwicklersicht ..............................................197 6.2 Qualitätsmanagement...................................................................................197 6.2.1 Methoden und Werkzeuge des Qualitätsmanagements........................199 8 6.2.2 Die Bedeutung von Qualitätsstandards.................................................199 6.2.3 Die Problematik von Standards in der Softwareentwicklung...............200 6.2.4 Die Dokumentation von Software.........................................................200 6.3 Die statische Kontrolle der Qualität und anderer Softwareeigenschaften . .201 6.3.1 Softwaremaße-Softwaremessung..........................................................201 6.3.1.1 Die Function-Point Methode..........................................................202 6.3.1.2 Halstead-Maße................................................................................205 6.3.1.3 Das Mc Cabe-Maß.........................................................................209 6.3.1.4 Fan-in---Fan-out.............................................................................211 6.3.2 Reviews..................................................................................................213 6.3.2.1 Die Entwurfsinspektion.................................................................214 6.3.2.2 Die Codeinspektion.......................................................................215 6.3.3 Formale Verifikation.............................................................................217 6.3.3.1 Baumförmige Darstellung der Verifikationsregeln.......................221 6.3.3.2 Beweis der Endlichkeit von Algorithmen......................................227 7 Testen................................................................................................229 7.1 Testverfahren - Wie wird getestet? ..............................................................229 7.2 Wie findet man Testdaten.............................................................................231 7.3 Wer testet?....................................................................................................232 7.4 Testen von objektorientierter Software........................................................232 7.5 Teststrategie..................................................................................................233 7.6 Testwerkzeuge ............................................................................................234 7.7 xUnit, JUnit...................................................................................................234 8 Konfigurationsmanagement...........................................................238 8.1 Warum Konfigurationsmanagement (KM)?................................................238 8.2 Was ist (Software-)Konfigurationsmanagement (SKM)?...........................238 8.3 Einsatz von Software-Konfigurationsmanagement in Projekten................239 8.4 Weiterführende Literatur..............................................................................242 9 Petri-Netze........................................................................................243 9.1 Zustände und Ereignisse...............................................................................243 9.2 Dynamik in Petri-Netzen..............................................................................244 9.3 Regeln in Petri-Netzen..................................................................................244 9.4 Komplexe Situationen in Petri-Netzen.........................................................246 9.5 Kontakt- und Konfliktsituation....................................................................246 9.6 Gabel und Zusammenführung......................................................................247 9.7 Beispiele von Petri-Netzen...........................................................................248 9.8 Varianten von Petri-Netzen..........................................................................252 9.8.1 Bedingungs-/Ereignis-Netze..................................................................253 9.8.2 Stellen-/Transitions-Netze.....................................................................253 9 10 Entscheidungstabellen...................................................................254 10.1 Grundlagen..................................................................................................254 10.2 ET-Typen ...................................................................................................255 10.3 Anwendung von Entscheidungstabellen....................................................255 10.4 Entscheidungsbaum....................................................................................258 10.5 Weiterführende Literatur............................................................................260 10 1 Einführung Ziel der Softwaretechnik ist es gute d. h. qualitativ hochwertige Softwaresysteme erstellen zu können. 1.1 Was ist ein gutes Softwaresystem? Letztendlich ist nach [StP 00] ein gutes System eines, das den Bedürfnissen des Anwenders gerecht wird. Das System muss deshalb... • • • • • nützlich und nutzbar sein. Es muss dem Anwender das Leben möglichst stark erleichtern. zuverlässig sein. Es soll möglichst wenig Fehler enthalten. flexibel sein. Das System muss leicht an geänderte Anforderungen des Benutzers anpassbar sein. Die Fehler müssen leicht zu beheben sein. kostengünstig sein, nicht nur in der Anschaffung, sondern auch im Unterhalt. verfügbar sein. Das System muss auf jetzigen und zukünftigen Zielplattformen (Hardware, Betriebssystemen etc.) lauffähig bzw. leicht adaptierbar sein. Zur Verfügbarkeit gehört natürlich auch, dass das Softwareprodukt überhaupt existiert und zwar zu dem Zeitpunkt, zu dem es zum Einsatz kommen soll. Frage: Kennen Sie Projekte mit großen Softwareanteil, die gescheitert sind? Warum sind diese Projekte gescheitert? 11 1.2 Was ist Softwaretechnik? In dieser Vorlesung sollen Sie lernen, wie man gute Softwaresysteme erstellt, d. h. es sollen Methoden und Techniken vermittelt werden, um Software in einem gegebenen Zeitrahmen mit den oben angegebenen Eigenschaften zu realisieren. Das Fach Softwaretechnik bietet Methoden für die konstruktiven Phasen der Software Entwicklung (Analyse, Entwurf, Implementierung), die verwendet werden, um die Arbeitsergebnisse dieser Phasen zu strukturieren. Softwaretechnik stellt aber auch Modelle zur Definition von Qualität zur Verfügung (Qualitätseigenschaften, Qualitätsmodelle) und entsprechende Methoden zur Überprüfung der Phasenergebnisse (Test, Verifikation, Qualitätssicherung). Zur zeitlichen Strukturierung von Softwareprojekten sind Projektmodelle (Phasenmodelle) definiert, die eine zeitliche Gliederung eines Projektes in verschiedene Entwicklungsphasen ermöglichen. Softwaretechnik beschäftigt sich folglich mit Methoden für das "Pragrammieren im Großen". Unter Programmieren im versteht man die Abwicklung großer Softwareprojekte. Ein großes Softwareprojekt ist gekennzeichnet durch den Einsatz eines Entwicklerteams. Ein Team von mehreren Entwicklern entwickelt gemeinsam ein Softwareprodukt. Es werden in der Regel mehrere Versionen der Software erzeugt. Die Software wird weiterentwickelt und erweitert; veraltete Softwareversionen werden durch verbesserte ersetzt. Ein großes Softwareprojekt hat eine lange Entwicklungszeit. Große Systeme werden über mehrere Monate oder Jahre entwickelt. Das erfordert eine zeitliche Projektplanung und Terminüberwachung. Software hat eine lange Lebensdauer, während der das Produkt Software an neue Anforderungen angepasst werden muss. Diese Probleme bei der Software Entwicklung im Großen erfordern andere Vorgehensweisen als das Programmieren einer kleinen Anwendung (z. B. in einem Programmierpraktikum). Die Methode VHIT (Vom Hirn Ins Terminal) ist zur Entwicklung komplexer Systeme nicht geeignet. Dazu benötigt ein Entwicklerteam Prinzipien und Methoden des Software Engineering. 12 1.3 Geschichtliche Entwicklung In der "Steinzeit" der Software Entwicklung, in den 50er und 60er Jahren des 20. Jahrhunderts wurden Computer und die dafür notwendige Software fast ausschließlich im naturwissenschaftlichen Bereich eingesetzt. Die eingesetzten Programme dienten hauptsächlich der effizienten Lösung von mathematischen Problemen. Die Hardware war sehr teuer, die Software war sehr preisgünstig oder wurde von den Anwendern selbst geschrieben. Durch sinkende Hardwarepreise wurden Computer für eine größere Zielgruppe erschwinglich. Dadurch veränderten sich aber auch die Anforderungen an die Software. Es wurde Software für die verschiedensten Bereiche gebraucht. Der Umfang der Software wurde immer größer. Ihre Komplexität war mit den bis zu diesem Zeitpunkt bekannten Vorgehensweisen für das "Programmieren im Kleinen " nicht mehr zu beherrschen. Ausgelieferte Programme waren fehlerhaft und unzuverlässig. Software Projekte wurden nicht termingerecht fertig gestellt. Die zur Entwicklung eingeplanten Budgets wurden überschritten. Dieser Zustand der Software Industrie wurde mit dem Begriff der Softwarekrise charakterisiert. Wissenschaft und Forschung entwickelten als Reaktion darauf strukturierte Programmiersprachen und Entwicklungsmethoden zur Lösung der Probleme, die zur Softwarekrise führten. Der Begriff Software Engineering wurde zuerst auf einer Software-Engineering-Konferenz der NATO, die 1968 in Garmisch veranstaltet wurde, geprägt. Diese Konferenz gilt allgemein als Geburtsstunde der Softwaretechnik. Nachfolgend sind die Entwicklungsschritte der Softwaretechnik in Stichworten aufgeführt: (angelehnt an [Sch 90]) 1. Erster Ansatz zur Entwicklung übersichtlicher Programme (1968) Dijkstra schlägt die "strukturierte Programmierung" vor (Vermeidung von GOTO-Anweisungen). 2. Entwicklung von Software-Engineering-Prinzipien (1968 - 1974) Es werden die theoretischen Grundlagen (Prinzipien) erarbeitet, die der strukturierten Entwicklung von Programmen zugrundeliegen: strukturierte Programmierung, schrittweise Verfeinerung, Geheimnis-Prinzip, Programmodularisierung, Software-Lifecycle, Entity-Relationship-Modell, Software-Ergonomie 3. Entwicklung von phasenspezifischen Software-Engineering-Methoden (1972 - 1975) Umsetzen der Software-Engineering-Prinzipien in Entwurfsmethoden: HIPO, Jackson, Constantine-Methode, erste Version von Smalltalk 4. Entwicklung von phasenspezifischen Werkzeuge (1975 - 1985): Der Einsatz von SE-Methoden mit maschineller Unterstützung (z.B. Programminversion, Batchwerkzeuge) 13 5. Entwicklung von phasenübergreifenden (integrierten) Software-EngineeringMethoden (ab 1980) Es sollen die Ergebnisse einer Phase des Software-Lifecycles automatisch an die nächste Phase weitergegeben werden: Methodenverbund 6. Entwicklung von phasenübergreifenden (integrierten) Werkzeuge (ab 1980) Einsatz einer Datenbank als automatischer Schnittstelle zwischen den einzelnen Phasen des Software-Lifecycles. Interaktiver Programmaufruf durch CASWerkzeuge (Computer Aided Softwaredesign) 7. Definition verschiedener, konkurrierender objektorientierter Methoden (ab 1990) Es entstanden parallel verschiedene Objektorientierte Analyse- und Entwurfsmethoden (Booch, Jacobson, Rumbaugh, Shlaer/Mellor, Coad/Yourdon u. a.). Die Methoden wurden in CASE Tools (Computer Aided Software Engineering) realisiert. 8. Integration der OO-Methoden zur UML – Unified Modeling Language (ab 1995) Jacobson, Booch und Rumbaugh schließen sich zusammen und entwickeln die UML. In der UML sollen die Schwächen der frühen OO-Methoden beseitigt werden und ein weltweit gültiger, einheitlicher Standard geschaffen werden. Die UML 1.0 wurde 1997 verabschiedet. 9. UML 2.0 Nachdem die UML 1.0 bis zur Version UML 1.5 erweitert wurde, erschien 2004 die UML 2.0. In dieser Version wurde die Sprachelemente der UML an aktuelle Technologien angepasst; es wurden Redundanzen und Inkonsistenzen in der Sprachdefinition beseitigt. 1.4 Softwarequalität Das Produkt Software soll nach seiner Fertigstellung den Anforderungen der Benutzer entsprechen. (Es muss nicht eine "möglichst hohe" Qualität haben, sondern die vom Benutzer verlangte Qualität!) Dazu ist es notwendig die Qualitätsanforderungen der Benutzer zu definieren, für die Entwicklung Methoden und Hand- 14 lungsanweisungen zum Erreichen der geforderten Qualität zu definieren und am fertigen Produkt die entwickelte Qualität zu überprüfen. Zur Definition von Softwarequalität entstand eine Vielzahl von Begriffen, die sogenannten Qualitätseigenschaften, die verschiedene Dimensionen der Qualität beschreiben. Außer den im Folgenden beschriebenen Eigenschaften existiert eine Vielzahl weiterer Qualitätseigenschaften, die nicht einheitlich definiert sind. Nachfolgend werden, als in die Problematik einführendes Beispiel, Qualitätseigenschaften mit Hilfe eines Modells nach Raasch [Ra 92] erläutert. 1.5 Software-Qualitätseigenschaften Raasch benutzt die in Abbildung 1.5.1 beschriebene Hierarchie von Qualitätseigenschaften, die Qualität aus Benutzersicht und Qualität aus Entwicklersicht unterscheidet. Er geht davon aus, dass für diese beiden Gruppen unterschiedliche Qualitätseigenschaften wichtig sind. Der Benutzer verwendet Software, folglich sind für ihn Eigenschaften wie Funktionserfüllung, Zuverlässigkeit usw. von Bedeutung. Für den Entwickler sind Eigenschaften wie Wartbarkeit, Erweiterbarkeit usw. von Bedeutung. Qualitätseigenschaften können in einer Hierarchie verfeinert werden. Funktionserfüllung Effizienz Qualitätsmerkmale aus Benutzer sicht Qualitätsmerkmale aus Entwicklersicht Zuverlässigkeit HW-Effizienz SW-Effizienz(Performance) Benutzbarkeit Robustheit Sicherheit Fehlertoleranz Erweiterbarkeit Änderbarkeit Wartbarkeit Verständlichkeit Übertragbarkeit Testbarkeit Wiederverwendbarkeit Abbildung 1.5.1 Software - Qualitätseigenschaften 15 Funktionserfüllung: ist ein Maß für die Übereinstimmung zwischen geplantem und tatsächlich realisiertem Funktionsumfang. Je mehr ein System kann, desto vielseitiger ist es einsetzbar. Man kann mit Software jede beliebige Funktion verwirklichen, aber man sollte keine Systeme planen, die alle beliebigen Funktionen enthalten. Effizienz: ist das Ausmaß der Inanspruchnahme von Betriebsmitteln (HW) durch das Software-Produkt bei gegebenem Funktionsumfang. Die Hardware soll bei gegebenem Funktionsumfang eines Produktes möglichst sparsam benutzt werden (hohe Ablaufgeschwindigkeit, geringer Speicherbedarf). Effizienz war lange Zeit aufgrund hoher Hardwarekosten das beherrschende Qualitätsmerkmal, verliert aber bei ständig sinkenden Hardwarepreisen immer mehr an Bedeutung. Heute spielt Effizienz z. B. bei Realzeitsystemen eine große Rolle. Zuverlässigkeit: (siehe [So 01]) Man kann Zuverlässigkeit von Software durch eine Funktion R(t) beschreiben. Sei fw(t) die Wahrscheinlichkeit, dass im Zeitraum von 0 – t ein Fehler auftritt, so gilt: R(t) = 1 – fw(t) (Zuverlässigkeitsfunktion) Geht R(t) auch für große t gegen 1, dann nennt man ein Softwareprodukt zuverlässig. Falls R(t) bereits für kleine t nahe bei 0 liegt, ist das Produkt unzuverlässig. Robustheit: Robustheit ist der Grad, in dem ein Produkt eine vernünftige Reaktion bei nicht vorgesehener Verwendung erbringt und seine Funktionsfähigkeit bewahrt. Man setzt voraus, dass Hardware- und Eingabefehler vorkommen können und verlangt, dass dadurch keine Katastrophe geschehen soll. Benutzbarkeit: Benutzbarkeit (auch Benutzungskomfort oder Benutzerfreundlichkeit) umfasst alle Software-Eigenschaften, die dem Anwender ein einfaches, angenehmes, effizientes und fehlerarmes Arbeiten mit dem Software-Produkt gestatten. Dabei sind auch viele ergonomische Kriterien zu berücksichtigen wie: Lernaufwand, Installationsaufwand, einfache und einheitliche Benutzeroberfläche, Robustheit usw. ( Benutzerschnittstelle, Software Ergonomie. Fehlertoleranz: 16 Das System muss im Falle eines erkannten Fehlers den Benutzer situationsgerecht informieren. Das System muss immer bedienbar bleiben, d. h. alle auftretenden Fehlerbedingungen müssen abgefangen werden. Sicherheit: unter dem Begriff sind alle System-Eigenschaften zusammengefasst: • die verhindern, dass ein technisches System in einen gefährlichen Zustand gerät, • die verhindern, dass Software-Systeme unbefugt benutzt werden, • die verhindern, dass Daten oder Programme unbeabsichtigt oder mutwillig zerstört oder verfälscht werden, • und die dafür sorgen, dass eine ordnungsgemäße und revisionsfähige Verarbeitung im Sinne geltender Normen und Gesetze sichergestellt wird. Erweiterbarkeit: Wie einfach ist es auch noch nach Fertigstellung den Leistungsumfang des Software-Produktes durch Einbau zusätzlicher Funktionen zu verändern und dabei einer speziellen Anwendungssituation anzupassen. Änderbarkeit: Grad, in dem ein Produkt die Veränderung (Anpassung) seiner Eigenschaften durch den Benutzer zulässt. Die Änderung erfolgt über definierte Schnittstellen, nicht durch Veränderung des Quellcodes. Wartbarkeit: Die Wartbarkeit eines Systems wird nach der Zeitdauer beurteilt, die im produktiven Einsatz nach Auftreten und Meldung eines Fehlers erforderlich ist, um diesen zu lokalisieren und zu beheben. Diese Qualitätseigenschaft wird beeinflusst von der Änderbarkeit, Verständlichkeit und Testbarkeit. Verständlichkeit: Bezieht sich auf die Lesbarkeit des Codes, den Aufbau des Systems, seine Architektur, die Modularisierung der Komponenten. Je übersichtlicher ein System gegliedert (verfeinert) ist um so größer ist seine Verständlichkeit Testbarkeit Je übersichtlicher und verständlicher ein System gegliedert ist, umso einfacher ist es zu testen. Korrektur von Fehlern in der Wartung beseitigen Fehler, sie können aber neue Fehler in das System einschleusen. Testbarkeit bezeichnet den Aufwand, der zum Testen einer Anwendung nötig ist. Übertragbarkeit: 17 ein System ist portabel, wenn es leicht in neue oder andere Hardware- und Software-Umgebung überführt werden kann. Wiederverwendbarkeit: ist die Verwendung von bereits entwickelten Software-Komponenten in anderen Umgebungen, für die sie ursprünglich nicht geplant waren. Wiederverwendbarkeit ist nicht nachträglich zu erreichen. Ein System muss so konzipiert werden, dass die entwickelten Komponenten wiederverwendbar sind. Abhängigkeiten zwischen Qualitätseigenschaften Die Qualitätseigenschaften sind nicht unabhängig voneinander. Werden Maßnahmen zur Verbesserung einer Qualitätseigenschaft getroffen, so wirken sich diese möglicherweise auf andere Eigenschaften aus. Wird die Effizienz eines Systems verbessert, so kann dies ein unzuverlässigeres System bewirken; die Robustheit kann sinken, das System kann schwerer änderbar sein (weil z. B. die Effizienzsteigerung durch Assemblerprogramme erreicht wurde). Hardwarenahe Programmiersprachen wirken sich natürlich auch auf die Wartbarkeit und Übertragbarkeit aus. Maße für Qualität Wie oben beschrieben, muss schon bei der Spezifikation die Qualität der zu erstellenden Software definiert werden, so dass nach der Fertigstellung nachgeprüft werden kann, ob die Software den Qualitätsanforderungen genügt. Zum Beispiel kann die Qualitätseigenschaft Funktionserfüllung geprüft werden, indem getestet wird, ob die Software so funktioniert wie vereinbart, d.h. ob die Software das tut, was in der vom Auftraggeber abgezeichneten Spezifikation steht. Die Effizienz kann durch Angabe von maximalen Antwortzeiten spezifiziert werden, die Zuverlässigkeit durch einen Wert für R(t). Andere Maße, wie die z. B. Erweiterbarkeit oder Wartbarkeit sind schwieriger zu definieren, wir werden im Kapitel 7 Softwaremetriken näher auf mögliche Maße eingehen. 18 1.6 Phasen der Softwareentwicklung Um qualitativ hochwertige Software zu produzieren muss das Produkt modular aufgebaut werden. Zusätzlich ist es nötig auch den Produktionsprozess nach Prinzipien zu strukturieren, die auch in anderen Ingenieursdisziplinen üblich sind. Man spricht in diesem Zusammenhang von ingenieurmäßigem Vorgehen bei der Softwareentwicklung. Ein Softwareprojekt muss, wie jeder andere industrielle Fertigungsprozess auch, in mehrere Phasen eingeteilt werden. Frick beschreibt in [Frick95] die Merkmale eines industriellen Fertigungsprozesses: 1. Der Prozess läuft in Phasen ab. 2. Jede Phase liefert Ergebnisse, die die Grundlage für die Folgephase darstellen. 3. Es findet eine Überprüfung der Phasenergebnisse statt, bevor die Folgephase anläuft (wobei es notwendig werden kann, die gleiche Phase noch einmal durchzuführen). 4. In jeder Phase entsteht eine abstrakte Darstellung des Produktes, je fortgeschrittener die Phase, desto konkreter wird die Darstellung. Diese allgemeinen Anforderungen an einen Fertigungsprozess gelten auch für die Softwareerstellung. Durch den Einsatz von Phasenmodellen wird ein Softwareprojekt zeitlich strukturiert. Es wird festgelegt: • • • • • • welche Arbeiten in den einzelnen Phasen zu erledigen sind, welche Arbeitsergebnisse in den Phasen erzeugt werden müssen, welche Personen die Ergebnisse zu erarbeiten haben, wie die Ergebnisse dokumentiert werden sollen, welche Termine eingehalten werden müssen, einzuhaltende Standards und Richtlinien. Phasenmodelle regeln auch die Zusammenarbeit zwischen den am Softwareerstellungsprozess beteiligten Rollen und Personen.[Kimm79]. Es existieren verschiedene Phasenmodelle für die Softwareentwicklung. Das "Ur-Modell" ist das so genannte Wasserfallmodell, das ein rein sequentielles Durchlaufen der Phasen vorsah. Die Arbeiten einer Phase mussten abgeschlossen sein, bevor die Folgephase beginnen konnte. Dieses Vorgehen erwies sich in der 19 Praxis als undurchführbar. Es wurde so erweitert, dass Rücksprünge in zeitlich früher liegende Phasen möglich wurden. Am Ende jeder Phase werden die Ergebnisse überprüft und an die Folgephase weitergegeben. Wird dort während der Erarbeitung der eigenen Phasenergebnisse, ein Fehler in den Vorgaben festgestellt, so werden die Vorgaben an die vorhergehende Phase zurückgeführt. In den letzten Jahren hat sich eine Vielzahl von weiteren Prozessmodellen herausgebildet, die dieses Modell variieren, z. B. durch ein mehrmaliges Durchlaufen der Phasen des Wasserfallmodells in mehreren Zyklen, wobei am Ende jedes Zyklus eine weitere Ausbaustufe des Systems entsteht. Prototyping-Ansätze wurden in das Wasserfallmodell integriert. Ob wir nun in mehreren Zyklen entwickeln, d. h. erst ein Basissystem und in den Folgezyklen dieses Basissystem immer wieder durch weitere Teilsysteme ergänzen oder ob wir das Gesamtsystem als ganzes entwickeln, wir durchlaufen während des Softwareentwicklungsprozesses immer verschiedene aufeinander aufbauende Phasen: Implementierung und Test Diese zentrale Phase des Softwareentwickungsprozesses kennen wir schon aus der Lehrveranstaltung Programmieren. (Zumindest kleine Programme wurden von Ihnen bereits implementiert und getestet.) Bei großen Systemen können wir das System nicht als Ganzes implementieren und testen, sondern wir implementieren und testen zuerst die einzelnen Komponenten (Komponententest). Anschließend werden diese ausgetesteten Komponenten schrittweise zusammenmontiert und ausgetestet (Integrationstest). Vor Beginn der eigentlichen Codierung ist die Implementierungsstrategie festzulegen. Es wird entschieden, in welcher Reihenfolge die Komponenten implementiert und zusammengebaut werden (Top-Down- oder Bottom-Up-Vorgehensweise). Die einzusetzenden Bibliotheken sind festzulegen. Detaillierte Testpläne für die einzelnen Komponenten, für die Teilsysteme und das Gesamtsystem sind, falls nicht schon in vorhergehenden Phasen geschehen, zu erstellen. Abnahme Auch diese Phase kennen wir vom Programmierpraktikum. In dieser Phase wird geprüft, ob die Leistungen des Systems mit den in der Spezifikation vereinbarten Leistungen übereinstimmen (im Programmierpraktikum: mit 20 den in der Aufgabenstellung geforderten Leistungen). Ist ein externer Auftraggeber vorhanden, überprüft dieser oft die Systemfunktionen mit einem eigenen Prüfkatalog. Im Programmierpraktikum bekamen Sie dann Ihre Abnahme und der Sinn der Implementierung war erfüllt. Sie sind wieder einen Schritt in Ihrem Studium vorangekommen. Bei der kommerziellen Softwareentwicklung soll die Software nach der Implementierung natürlich auch zum Einsatz kommen. Es kommt eine weitere Phase, der eigentliche Einsatz, d. h. der Betrieb des Systems. Betrieb Bezogen auf die Lebensdauer eines Softwareproduktes ist die Betriebsphase eines Produktes die längste aller Phasen. Das erstellte Produkt wird in dieser Phase benutzt. Hier fallen mit ca. 80% der weitaus größte Teil der Kosten aller Phasen der Softwareentwicklung an, d. h. der Aufwand für die Erstellung übersichtlich entworfene und gut ausgetesteter Programme mit guter Dokumentation rentiert sich an dieser Stelle auf jeden Fall. Während des Betriebs eines Softwareproduktes werden zusätzliche Fehler und Unzulänglichkeiten am Produkt entdeckt. Diese werden dem Hersteller zur Korrektur gemeldet und verursachen Rücksprünge in zeitlich frühere Phasen. Während der Betriebszeit eines Softwareproduktes ändert sich der Einsatzzweck eines Produktes; die betrieblichen Abläufe, die von der Software unterstützt werden, ändern sich und die Software muss entsprechend angepasst oder verändert werden. Diese Aktivitäten werden häufig auch den Wartungsaktivitäten zugeordnet, bezeichnen aber eigentlich Arbeiten zur Weiterentwicklung der Software. Weitere Phasen bei der Softwareentwicklung Im Praktikum Programmieren wurde immer eine Aufgabe gestellt, d. h. die Definition war vorgegeben. Sie als Studierender mussten sich jetzt noch, falls nicht auch in der Aufgabenstellung vorgegeben, einige Gedanken über den Aufbau des Systems machen, und los ging es mit der Implementierung. Statt z. B. die Klassenstruktur inkl. der Beziehungen zwischen den Klassen graphisch darzustellen, konnten Sie, wegen der Übersichtlichkeit Ihrer kleinen Softwaresysteme, die Klassenstruktur meistens direkt als Header-File in C++ hinschreiben. Bei der Entwicklung von großen Systemen wird vor der eigentlichen Implementierung des Systems erst einmal eine Analyse durchgeführt, um zu wissen, ob und in welchem Umfang ein System erstellt werden sollte und ob eine Erstellung unter Kostengesichtspunkten ratsam und mit den Möglichkeiten der Firma 21 überhaupt möglich ist. Gemeinsam mit dem späteren Benutzer des Systems muss dann in einer Definitionsphase der Funktionsumfang genau spezifiziert und anschließend von der IT-Abteilung die IT-Lösung entworfen werden: Analyse In der Analysephase muss der Systemanalytiker zuerst das Anwendungsgebiet verstehen. Er muss begreifen was der Kunde will. Die Schwachstellen werden analysiert, Verbesserungsvorschläge werden geprüft und die zusätzlichen Wünsche an das System aufgenommen. Daraus wird abgeleitet was die Software aus fachlicher Sicht leisten soll. Die fachlichen Anforderungen an die Software werden dokumentiert und mit dem Benutzer abgestimmt. Es wird analysiert ob die Aufgabe durchführbar (lösbar) und finanzierbar ist und ob das notwendige Personal vorhanden ist. Es wird eine erste Kostenkalkulation vorgenommen. Fehler in der Analysephase sind sehr teuer, wirken sie sich doch auf alle folgenden Phasen aus. Die Dokumentation der Analyseergebnisse bilden die Kommunikationsgrundlage zwischen IT-Abteilung und Fachabteilung und müssen deshalb implementierungsunabhängig sein. Definition In dieser Phase werden die informellen Anforderungen der Analyse in eine vollständige, konsistente Spezifikation umgesetzt. Die Produktdefinition beschreibt wie das Produkt aus Benutzersicht funktionieren soll. Sie soll normalerweise implementierungsunabhängig formuliert sein. Die geforderten Qualitätseigenschaften werden in der Definitionsphase festgelegt. Der Abnahmetest wird mit dem Benutzer festgelegt. Entwurf Im Entwurf wird die IT-Lösung für das in den vorhergehenden Phasen spezifizierte Softwareprodukt entworfen. Es wird entschieden welche Hardware und welches Betriebssystem nötig sind. Die Programmiersprache wird gewählt. Benutzerschnittstelle, Datenbank und notwendige Systemschnittstellen zu Fremdsystemen werden festgelegt. Hier wird die Komponentenarchitektur definiert, d. h. das System wird in Komponenten (Klassen, Funktionen) zerlegt, die in Komponentenarchitekturdiagrammen (Klassendiagramm, Sequenzdiagramm) dargestellt werden. Das gewählte Softwareentwicklungsparadigma bestimmt die Methoden, die dafür eingesetzt werden. Komponententestpläne werden entworfen. In dem Entwurf wird festgelegt wie das System aufzubauen ist, damit es die in der Definition festgelegte Leistung erbringen kann. 22 Ergebnisse der Phasen, Reviews Als Ergebnis jeder Phase entstehen Dokumente, die als Grundlage für das Weiterarbeiten in der Folgephase dienen. Diese Ergebnisse (und evtl. auch innerhalb der Phasen an so genannten Meilensteinen anfallende Zwischenergebnisse) werden in so genannten Reviews geprüft und mit den Erstellern diskutiert. Dieser Schritt ist sehr wichtig, da Fehler in frühen Phasen der Softwareentwicklung in späteren Phasen nur mit sehr hohen Kosten behoben werden können. (Z. B. Fehler oder missverständliche Formulierungen in der Spezifikation werden erst zum Zeitpunkt der Abnahme festgestellt => alle Phasen müssen nochmals durchlaufen werden, man muss sich in den Aufbau des Programms hineindenken und Änderungen im Code sind vorzunehmen. Ein nicht zu unterschätzender Faktor ist der Test (Komponenten- und Integrationstest des gesamten Systems) und das Anpassen der Dokumentation. Eine ausführliche Betrachtung von Phasenmodellen ist in einem gesonderten Kapitel weiter hinten im Skript durchgeführt. 1.7 Überblick über den Aufbau des SWT-Skriptes In Kapitel 2 werden die Grundbegriffe der Objektorientierung wiederholt. Die Prinzipien der Objektorientierung und die objektorientierten Programmiersprachen werden zusammengefasst. Kapitel 3 gibt einen Überblick über die Modellierungssprache UML - Unified – Modeling Language. Alle Diagrammtypen der UML werden erläutert. Die wichtigsten Notationselemente werden beschrieben. Die Diagrammtypen der UML werden an einem durchgängigen Beispiel demonstriert. Kapitel 4 fasst die aktuellen Vorgehens- und Prozessmodelle zusammen. Das historische Wasserfallmodell beschreibt die Phasen eines Softwareprojektes und die Zusammenhänge zwischen den Phasen. Das V-Model ist aus dem Wasserfallmodell hervorgegangen und beschreibt als Standardmodell von Bundesbehörden das Vorgehen einer großen Organisation. RUP und extreme Programming stellen aktuelle Entwicklungen im Bereich der Vorgehensmodelle dar. Die prototypische Entwicklung wird erläutert. Im Abschnitt CMM/ISO 9000, SPICE liegt der Fokus auf der Bewertung der Qualität von Entwicklungsprozessen. 23 Der 2. Teil des Skriptes wird zum WS 04/05 erscheinen und folgenden Inhalt umfassen: • Requirements Engineering • Software Architektur und Patterns • Qualitätsmanagement • Testmanagement • Konfigurationsmanagement • vollständige Darstellung der UML • Petrinetze und Entscheidungstabellen. 24 2 Objektorientierung 2.1 Einführung Objektorientierte Programmierung (kurz OOP) ist seit den 90er Jahren das zentrale Programmiersprachenparadigma für viele Arten von Softwaresystemen. Ziel der Einführung der Objektorientierung war die Erstellung von robusteren, fehlerärmeren und besser wartbaren Programmen. Das fundamentale Konstrukt der Objektorientierung ist das Objekt, das sowohl Daten (die Attributen als Eigenschaften des Objekts) als auch das Verhalten (die Logik des Objekts) vereinigt. Damit wird es möglich, Software aus einer Sammlung von konkreten Objekten zu erstellen. Jedes Objekt ist hierbei eindeutig über einen sog. Handle (Referenz) identifizierbar. Je nach Programmierumgebung kann ein Handle beispielsweise als eine Adresse zu einem Speicherbereich realisiert sein. Objekte können durch Kenntnis des Handle mit anderen Objekten kommunizieren. Man spricht in diesem Zusammenhang von einem Nachrichtenaustausch zwischen Objekten. Aufgrund einer eingehenden Nachricht führt das Objekt eine bestimmte Operation aus. Eine Operation wird durch Aufruf einer Methode des Objekts realisiert. Eine Methode repräsentiert somit das Verhalten eines Objektes. Oft wird sprachlich nicht zwischen einer Methode und einer Operation unterschieden und beide Begriffe synonym verwendet. Als Beispiel werden nachfolgend Polygon-Objekte betrachtet (siehe Abbildung 21). Attribute - Kante - Kantenfarbe - Füllmuster Operationen - zeichnen - löschen - verschieben Abb. 2-1: Beispiel "Polygon-Objekte" 25 Ein konkretes Polygon-Objekt ist beispielsweise das Viereck. Dieses wird durch 4 Kanten beschrieben, die Kantenfarbe und das Füllmuster. Polygon-Objekte können in diesem Beispiel auf drei Nachrichten reagieren: zeichen, löschen und verschieben. Im nächsten Abschnitt werden die Grundideen der objektorientierten Programmierung erläutert. 2.2 Prinzipien der Objektorientierung 2.2.1 Abstraktion Eine der wichtigsten Ideen der objektorientierten Programmierung ist die Trennung zwischen Konzept und Umsetzung. Hierzu wurden die Begriffe Klasse und Objekt eingeführt. Ein Objekt ist eine tatsächlich existierende Repräsentation einer "Sache" aus dem zu entwickelnden Anwendungssystem. Beispiele für Objekte sind das Personenobjekt "Schmidt", das Autoobjekt "VW-Käfer" oder das Druckerobjekt "Laserdrucker1". Objekte müssen instantiiert werden, damit die Eigenschaften und das Verhalten der Objekte in einem Programm genutzt werden können. Anstelle von Objekten spricht man auch gerne von den "Instanzen einer Klasse". In diesem Skript werden diese Begriffe synonym verwendet. Eine Klasse ist die Beschreibung eines oder mehrerer ähnlicher Objekte, d.h. Objekte des gleichen Typs. Objekte einer Klasse müssen sich nicht in allen Details gleichen, aber in vielen Eigenschaften übereinstimmen. Beispiel einer Klasse ist "Auto", das die Beschreibung aller Automarken von verschiedensten Hersteller repräsentieren kann. Die Attribute und Methoden der Klasse "Auto" müssen so gewählt sein, dass hiermit die unterschiedlichsten Ausprägungen gemäß den Projekt-Anforderungen umfassend beschrieben werden können. Die Unterscheidung zwischen Klasse und Objekt kann als Abstraktion angesehen werden. Hiermit wird es möglich, Details einer Problemstellung zu ignorieren und somit die Komplexität des Problems zu reduzieren. Es findet somit eine Abbildung der realen Welt in eine abstrakte logische Ebene (bestehend aus Klassen und Objekten) statt. 2.2.2 Kapselung Eine Klasse fasst eine Menge von Daten und darauf operierender Funktionen (die sog. Methoden) zusammen. Die Daten werden durch einen Satz von Variablen repräsentiert. Diese werden als Attribute oder Instanzvariablen bezeichnet. Für die Klasse Auto könnten diese z. B. die Attribute Baujahr, Jahr der Erstzulassung, 26 Hubraum, Kennzeichen usw. sein. Für jedes Objekt wird ein eigenständiger Satz an Attributen angelegt. Die Funktionen werden in der Objektorientierung als Operationen bzw. als Methoden bezeichnet. Diese repräsentieren das Verhalten der Objekte. Die Methoden enthalten ausführbaren Programmcode und stellen die Schnittstelle zur Kommunikation mit anderen Objekten (einer anderen Klasse) dar. Das Verhalten eines Objektes ist festgelegt durch die aktuellen Attributwerte (der sog. Objektzustand) und dem Programmcode der jeweiligen Methoden. Da in der Objektorientierung Attribute und Methoden in einem Objekt zusammengefasst sind, bezeichnet man dies als Kapselung. Ein objektorientiertes System besteht somit aus einer Mengen von gekapselten Objekten (s. Abb. 2-2). m1() Abb. 2-1Objekte eines objektorientierten Systems a1() x1() 2.2.3 Wiederverwendung Durch Anwendung der Prinzipien der Abstraktion und Kapselung kann die Wiederverwendung von Programmteilen gefördert werden. Dies kann somit zur Erhöhung der Fehlerfreiheit und Effizienz beim Programmieren führen. Ein Beispiel sind die sog. Collections als Objekte, die eine Sammlung von Objekten anderen Typs verarbeiten können. Diese Collections ermöglichen sehr effizient typische Aufgaben wie beispielsweise das Durchsuchen, Sortieren oder Kopieren 27 von Elementen. Hierzu stellen die Collection-Klassen unterschiedliche Methoden als Schnittstelle (Collection-API) zur Verfügung. Allerdings gibt es auch Grenzen …. 2.2.4 Beziehungen Meistens existieren Objekte nicht isoliert sondern stehen in Beziehungen zu anderen Objekten. Hierbei werden unterschiedliche Beziehungsarten unterschieden. So kann zwischen Objekten beispielsweise eine "Teil-von"-Beziehung bestehen. Dies beschreibt eine Zusammensetzung eines Objektes aus anderen Objekten. So könnte beispielsweise ein Lampen-Objekt aus den Objekten für Birne, Fassung, Kabel und Widerstand bestehen. Eine andere zentrale Beziehung der Objektorientierung ist die Spezialisierung (istein-Beziehung). Diese wird in objektorientierten Programmiersprachen durch Vererbung ausgedrückt. Beispielsweise könnte ein Transportmittel als Schiff, Zug, Flugzeug und Strassenfahrzeug spezialisiert werden. Die Aussage ist, dass ein Schiff ein (spezielles) Transportmittel ist, aber auch ein Zug, ein Flugzeug oder ein Strassenfahrzeug. Diese Beziehung kann auch umgekehrt betrachtet werden. In diesem Falle spricht man von Generalisierung (Verallgemeinerung). Vererbungen können auch mehrstufig sein. So könnte beispielsweise ein Strassenfahrzeug weitere unterteilt werden in Auto, Zweirad und Lastkraftwagen. Auf diese Weise entstehen sog. Vererbunghierarchien, die in einer Baumstruktur (Ableitungsbaum) dargestellt werden. Die Modellierung von Vererbungshierarchien kann auch dazu eingesetzt, gegliederte Begriffstrukturen (sog. Taxonomien) für einen Anwendungsbereich zu definieren. Im Kapitel 3 werden im Rahmen der Betrachtung der UML (Unified Modelling Language) die unterschiedlichen Beziehungstypen erläutert. 2.2.5 Polymorphismus Ein anderes wichtiges Konzept von objektorientierten Programmiersprachen ist die des Polymorphismus (Vielgestaltigkeit). Hierunter versteht man die Fähigkeit von Objektvariablen, Objekte unterschiedlicher Klassen und daraus abgeleiteten Klassen aufzunehmen. Aufgrund der definierten Vererbunghierarchien wird sichergestellt, dass nur Eigenschaften berücksichtigt werden, die auf allen Ebenen der Hierarchie definiert sind. Mit Polymorphismus wird es möglich, gleiche Methoden von unterschiedlichen Objekten der Hierrachie aufzurufen. Hierbei wird das Konzept des "Late Binding" vom "Early Bindung" unterschieden. Letzteres bedeutet, dass zur Compile-Zeit der Methodenaufruf bestimmt ist. "Late Binding" bedeutet, dass erst zur Laufzeit die Festlegung getroffen wird welche Methode aufgerufen wird. Der Vorteil dieses Konzeptes liegt darin, dass der Programmieraufwand für typbasierte 28 Fallunterscheidungen verringert werden können. Allerdings sollte hiermit vorsichtig umgegangen werden, da sich hiermit unter Umständen die Verständlichkeit und Wartbarkeit eines Programms deutlich verschlechtern kann. 2.3 Überblick Objektorientierte Programmiersprachen Objektorientierte Programmierkonzepte können sehr weit rückverfolgt werden. Die erste objektorientierte Programmiersprache war Simula 67, die bereits 1967 alle wesentlichen Elemente einer objektorientierten Sprache enthielt. In den 70er und 80er Jahren des letzten Jahrhunderts dominierten prozedurale Programmiersprachen wie beispielsweise Fortran, Pascal, C und COBOL. In der Folge wurden viele etablierte Programmiersprachen um objektorientierte Sprachmittel erweitert oder neue Programmiersprachen definiert. In den 90er Jahren erlangten C++ (zunächst als Erweiterung der Sprache C), Smalltalk und Java eine hohe Aufmerksamkeit. In jüngster Zeit gewinnt C# durch die Marketingoffensive von Microsoft an Bedeutung. Während Java und C++ sich mittlerweile bei der Anwendungsentwicklung bewährt haben, muss C# sich als echte Alternative erst noch beweisen. In den nächsten Abschnitten werden die wesentlichen Eigenschaften von C++, JAVA und C# kurz beschrieben. 2.3.1 C++ Anfang der 80er Jahre entstand als objektorientierte Erweiterung von C die Programmiersprache C++. Ein zentrales Ziel von Bjarne Stroustrup, dem Erfinder der Sprache, war die Nutzung objektorientierter Konzepte unter Beibehaltung der prozeduralen Bestandteile von C. Somit zählt C++ zu den sogenannten Hybridsprachen, da verschiedene Programmiersprachenparadigmen unterstützt werden. C++ erfuhr schnell eine weite Verbreitung und wurde in vielen Projekten auch aufgrund vorhandener Entwicklungswerkzeuge gerne genutzt. Schon früh wurden umfangreiche Klassenbibliotheken entwickelt, die Lösungen für bestimmte Fragestellungen anboten. Beispielsweise entwickelte Microsoft die MFC (Microsoft Foundation Class) zur Unterstützung der Entwicklung von WindowsProgrammen. Auch eine Standard-C++-Bibliotek, die STL (Standard Template Library), zur Bearbeitung von Objektsammlungen steht Anwendungsentwickler zur Verfügung. Des Weiteren existiert eine Reihe von Spezialklassenbibliotheken wie z. B. IlogViews zur Entwicklung von anspruchsvollen grafischen Oberflächen. C++ wird auch heute noch immer dann eingesetzt, wenn die Performance der Applikation eine Rolle spielt. Einer der Gründe dafür ist, dass man mit C++ sehr effizient die Nutzung des Speicherplatzes und die Programmabarbeitung beeinflussen kann. Im Rahmen der Programmiervorlesungen im Bachelor- 29 Studiengang wird an der FH Darmstadt C++ als objektorientierte BasisProgrammiersprache gelehrt. 2.3.2 JAVA Java wurde 1995 (als Nachfolger der Sprache Oak von James Gosling) von der Firma Sun Microsystems entwickelt. Ursprünglich wurde die Programmiersprache für die Gerätesteuerung ("Comsumer devices") entwickelt, fand aber schnell weitere Anwendungsgebiete. Java ist eine plattformunabhängige, objektorientierte Programmiersprache, die es unter anderem ermöglicht, interaktive Web-Seiten zu entwickeln. Mit Java programmierte Applikationen (Applets), die per HTML in Web-Seiten integriert werden, werden beim Öffnen der Seite übers Internet automatisch gestartet und ausgeführt. Java ist in weiten Teilen nicht nur mit C++ vergleichbar, sondern sogar identisch. Allerdings wurden bei der Entwicklung von Java einige Sprachbestandteile von C++ anders umgesetzt oder konsequent eliminiert. So existieren beispielsweise keine fehlerträchtigen Pointeroperationen wie in C++. Des Weiteren sorgt ein "Garbage Collector" für eine effiziente Speicherverwaltung und gibt nicht mehr benötigten Speicher automatisch wieder frei. Inzwischen werden auch "Mission critical" Systeme mit Java entwickelt. Hierbei kann auf eine große Java-Bibliothek zurückgegriffen werden. Die Sprache Java basiert auf einer umfangreichen Klassenbibliothek, die von Hause aus eine Menge an Basisfunktionalitäten zur Verfügung stellt. In diesem Bereich ist Java der Programmiersprache C++ klar überlegen. Ein gravierender Nachteil von Java ist die im Vergleich zu C++ geringere Performance. Da Java zunächst in einen plattformunabhängigen Byte-Code übersetzt wird, muss dieser anschliessend von einem virtuellen Java-Prozessor (der Java Virtual Machine) ausgeführt werden. Durch diesen Interprationsvorgang geht wertvolle CPU-Zeit verloren. Durch Einführung der J2EE (Java 2 Enterprise Edition) und der Verfügbarkeit von sog. Applikations-Servern können mit Java auch mehrschichtige Architekturen entwickelt werden. Schliesslich unterstützt Java damit auch die komponentenorientierte Softwareentwicklung und stelle somit eine state-of-the-art Programmiersprache dar. 2.3.3 C# C# ist eine relativ neue objektorientierte Programmiersprache, die von der Firma Microsoft im Jahre 2001? veröffentlicht wurde. C# ist mit dem Anspruch entwickelt worden, einige Nachteile von C++ und Java zu beseitigen. Dennoch ist die Ähnlichkeit sehr hoch und die Frage stellt sich, ob C# sich am Markt durchsetzen wird und Java bzw. C++ längerfristig verdrängen kann. 30 C#-Programme werden in der .NET-Laufzeitumgebung ausgeführt. Das .NETFramework stellt hierzu viele Funktionen zur Verfügung. Dies bedeutet, dass viele Vorgänge im Gegensatz zu C++ nicht der Steuerung des Programmierers unterliegen. Quellen werden in Assemblierungen kompiliert, die sowohl den kompilierten Code (ausgedrückt in der .NET-Zwischensprache IL) als auch Metadaten zur Beschreibung des kompilierten Codes enthalten. Der IL-Code (Intermediate Language) wird dann in der CLR (Common Language Runtime) ausgeführt. Nachfolgend werden einige weitere Unterschiede zu C++ bzw. Java genannt. Im Gegensatz zu C++ werden bei C# keine Header-Dateien verwendet. Um eine schnellere Analyse des C#-Codes zu erzielen, werden keine Makros unterstützt. Auch auf Vorwärtsdeklarationen wurde verzichtet, da die Reihenfolge der Klassen in den Quelldateien nicht von Bedeutung ist. Das Löschen von Objekten erfolgt in C#-Programmen über die Speicherbereinigung und wird ausgeführt, wenn das Objekt nicht länger benötigt wird. Destruktoren (= Finalisierungsroutinen) können zur Durchführung von Bereinigungsaufgaben eingesetzt werden, dies jedoch nicht im gleichen Umfang wie bei C++-Destruktoren. Wegen der architekturellen und strukturellen Ähnlichkeiten von .NET und der Java-2-Technik bieten beide Sprachen einen vergleichbaren Umfang. Teilweise sind sich die Sprachen derart ähnlich, dass man schon ein zweites Mal auf den Programmcode schauen muss, um die Sprachen unterscheiden zu können. Ein wesentlicher Nachteil von C# ist, dass die entwickelten Programme nur auf den Microsoft-Plattformen ablauffähig sind. 2.4 Werkzeuge für die objektorientierte Entwicklung Um objektorientierte Softwaresysteme zu entwickeln, ist der Einsatz einer Reihe von leistungsfähigen Entwicklungswerkzeugen notwendig. Dies reicht beispielsweise von mächtigen Programmeditoren mit LSE-Fähigkeit (Language Sensitive Editing) sowie Assistenten und Wizards, komfortablen Debuggern und Analyse-Werkzeugen aber auch modernen Modellierungswerkzeugen. In den letzten Jahren sind viele leistungsfähige IDEs (Integrated Development Environments) entstanden, die viele Funktionen "unter einem Dach" dem Entwickler anbieten und oft auch durch Add-Ins (oder Plug-Ins) erweiterbar sind. Interessante Werkzeuge sind beispielsweise Visual Studio .NET von Microsoft und Eclipse der Apache Software Foundation (http://www.apache.org/). Schon sehr früh sind Modellierungswerkzeuge entstanden, die die Objektorientierte Analyse (OOA) und das Objektorientierte Design (OOD) unterstützen. Aufgrund des Bemühens, große Informationssysteme ingenieurmäßig (d.h. systematisch) und rechnergestützt zu entwickeln, entstanden leistungsfähige CASE-Werkzeuge 31 (Computer Aided Software Engineering). Ein CASE-System ist eine integrierte Software-Entwicklungsumgebung, die idealerweise den gesamten Softwarelebenszyklus unterstützt. Anfangs nutzten diese CASE-Werkzeuge unterschiedlichste Notationssprachen. Seit der weiten Verbreitung der UML (Unified Modelling Language) unterstützen alle CASE-Tools zumindest diese grafische Modellierungssprache. Durch die Integration von Methoden und Verfahren sowie deren Automatisierung soll ein rechnergestütztes System zur Unterstützung sämtlicher Phasen und Aktivitäten des Systemlebenszyklusses zur Verfügung gestellt werden. Alle marktrelevanten Tools unterstützen den Implementierungs-Prozess durch die Generierung von Programmfrakmenten in unterschiedlichen Zielsprachen aus den entwickelten UML-Modellen. Des weiteren sind moderne CASE-Werkzeuge in der Lage, den weiter entwickelten Code zu analysieren und das UML-Modell durch Reverse Engineering entsprechend anzupassen. Wird dieser Kreislauf im Rahmen eines Projektes mehrfach und systematisch genutzt, spricht man von Round-Trip Engineering. Im Rahmen des Softwaretechnik-Praktikums wird das CASE-Werkzeug Innovator der Firma MID eingesetzt. Weitere bekannte objektorientierte Modellierungswerkzeuge sind beispielsweise Rational Rose (IBM Rational), TogetherJ (Togethersoft), ObjectiF (MicroTool GmbH), Rhapsody (I-Logix) und ArgoUML (OpenSource). 2.5 Weiterführende Literatur [Graham95] Graham, Ian: Migrating To Object Technology, Addison-Wesley Publishing Company, 1995. [Meyer97] Meyer, Bertrand: Object-Oriented Software Construction, 2nd edition, Prentice Hall PTR, 1997. 32 3 UML Unified Modeling Language 3.1 Was ist die UML? Die Unified Modeling Language ist eine Modellierungssprache, also eine Sprache zur Beschreibung von Software-Systemen. Sie bietet eine einheitliche Notation, die für alle Anwendungsgebiete nutzbar ist. Sie enthält Diagramme und natürlichsprachliche Beschreibungsformen. Die UML kann zur statischen und dynamischen Modellierung von Analyse, Design und Systemarchitektur eingesetzt werden. Sie unterstützt objektorientierte Vorgehensweisen, ist aber auch zur Modellierung nicht-objektorientierter Systeme geeignet. Die UML 2.0 enthält gegenüber den Vorgängerversionen zahlreiche Neuerungen. Diese Neuerungen wurden notwendig um die aktuellen Entwicklungen im Bereich der Programmiersprachen (Java, C#) abzudecken und um technologische Entwicklungen (Komponententechnologie, Application Server), die sich nach der Definition der Versionen 1.x entwickelt haben, zu berücksichtigen. Der in den letzten Jahren expandierende Mark der Embedded Systems (eingebettete Systeme) lenkte den Fokus stärker auf die Elemente der UML, die die Modellierung von Real-Time-Systemen unterstützen. 3.2 Entstehung der UML Im Zeitraum Ende der achtziger bis Anfang der neunziger Jahre entstanden mehrere Notationen zur Modellierung von OO-Systemen. Die Grundlage der Notationen waren objektorientierte Programmiersprachen, wie Smalltalk und C++. Einige der wichtigsten Notationen waren: • • • • • • Booch (Grady Booch) OMT (James Rumbaugh) OOSE (Ivar Jacobson) Shlaer/Mellor Coad/Yourdon u. a. Seit 1994/1995 arbeiteten die "drei Amigos" Grady Booch, James Rumbaugh und Ivar Jacobson in ihrer gemeinsamen Firma Rational Rose an einer Methode, die die Vorteile der einzelnen Notationen vereinen und die ihre Nachteile eliminieren sollte. Es entstand, in Zusammenarbeit mit vielen Firmen aus der Software-Industrie, die Unified Method 0.8, die bis 1997 zur Unified Modeling Language 1.1 weiterentwickelt wurde. Die Notation der UML 1.1 war so umfangreich, dass der 33 Anspruch eine Methode zu definieren auf die Definition einer Modellierungssprache reduziert wurde. Die UML 1.1 wurde 1997 bei der Object Management Group (OMG) eingereicht und wurde ein weltweiter Standard im Bereich der Objekt-Orientierten Entwicklung. Die erste Version der UML wurde bis zur UML 1.5 weiterentwickelt. Um die UML an neue Technologien wie Componentware, serverbasierte Technologien, u. a. anzupassen, wurde die Struktur der UML 1.x gründlich überarbeitet. Zur Zeit (SS 2004) liegt die UML 2.0 als Entwurf vor. Sie wird im 2. Halbjahr 2004 verabschiedet werden. 3.3 Diagramme der UML 2.0 Die UML 2.0 definiert die nachfolgenden Diagramme. In der UML 2.0 ist es möglich Diagramme zu schachteln; man kann also eine Hierarchie von Diagrammen erstellen, bei der Details eines Diagramms in einem weiteren Diagramm "verfeinert" werden. Diagramme können über definierte Schnittstellen miteinander verknüpft werden; ein Diagramm kann Verhalten, das in einem anderen Diagramm modelliert ist über eine definierte Schnittstelle aufrufen. Es ist möglich Diagrammvererbungen zu nutzen und Vererbungsbeziehungen zwischen Diagrammen aufzubauen. Diagramme, die Verhalten modellieren, können mit Einund Ausgabeparametern versehen werden. Programmierkonstrukte wie Schleifen und Verzweigungen können dargestellt werden. • • 34 Strukturdiagramme • Klassendiagramm -Class Diagram • Objektdiagramm - Object Diagram • Komponentendiagramm - Component Diagram • Paketdiagramm - Package Diagram • Kompositionsstrukturdiagramm - Composite Structure Diagram • Verteilungsdiagramm - Deployment Diagram Verhaltensdiagramme • Aktivitätsdiagramm - Activity Diagram • Anwendungsfalldiagramm - Use Case Diagram • Zustandsdiagramm -State Machine Diagram • Interaktionsdiagramme • Interaktionsübersichsdiagramm - Interaction Overview Diagram • Sequenzdiagramm - Sequence Diagram • Kommunikationsdiagramm - Communication Diagram • Zeitverlaufsdiagramm - Timing Diagram Strukturdiagramme werden in der UML verwendet um die statische Struktur (zeitunabhängige Aspekte) von Systemen zu beschreiben. Sie können zur Beschreibung der interne Struktur einzelner Klassen bis zur Definition der Architektur komplexer Systeme verwendet werden. Die UML enthält die oben genannten Strukturdiagramme zur Beschreibung struktureller Aspekte von Klassen, Objekten, Komponenten und Paketen. Das Kompositionsstrukturdiagramm zeigt die interne Struktur eines Elementes (Klasse, Komponenten, Use Case) und seine Interaktionspunkte zu anderen Systemteilen. Das Verteilungsdiagramm zeigt die dynamische Zuordunung von Softwareelementen zu Hardwareelementen eines Systems. Verhaltensdiagramme Verhaltensdiagramme beschreiben Aspekte eines Systems, die sich mit dem dynamischen Verhalten von Systemelementen beschäftigen. Verhaltensdiagramme modellieren bestimmte dynamische Aspekte eines Systems, unter Vernachlässigung anderer Zusammenhänge. Interaktionsdiagramme sind eine Untermenge der Verhaltensdiagramme. Sie beschreiben die Kommunikation zwischen Kommunikationspartnern. 35 Begriffe der UML Da die UML Spezifikation in englischer Sprache verfasst ist, werden in Veröffentlichungen häufig deutsche und englische Begriffe verwendet. Zur Erleichterung der Übersetzung existiert eine UML Übersetzungstabelle, die alle wesentlichen englischen Begriffe in die deutsche Sprache übersetzt. Sie ist zu finden unter http://www.oose.de. Auf diesem Server befindet sich auch ein Glossar, das alle Begriffe der UML erklärt. Auch in den Spezifikationsdokumenten der UML [Omg 03Super] und [Omg 03Infra] sind die verwendeten Begriffe in einem Glossar definiert. Einige zentrale, diagrammübergreifende Begriffe der UML werden hier kurz erläutert. Artifact - Artefakt In der UML Spezifikation werden Ergebnisse oder Produkte eines Entwicklungsprozesses als artifact bezeichnet. Ein artifact ist also z. B. eine Klasse, ein Diagramm, eine Beschreibung eines Elementes. Note - Notiz, Anmerkung Jedes UML Element kann mit einer Notiz versehen werden. Die Notiz wird über eine gestrichelte Linie mit dem Element verbunden, das beschrieben wird. Abbildung 3.3.1Beispiel Notiz in UML Diagrammen Szenario Ein Szenario ist eine Szene eines Modells, also ein Ausschnitt, für den nur bestimmte Aspekte des Gesamtsystems dargestellt werden. Constraint - Einschränkung Eine Einschränkung ist eine Bedingung, die bei der Implementierung eines Systems erfüllt sein muss. Constraints werden in geschweiften Klammern geschrieben und mit einer gestrichelten Linie mit dem Element verbunden, auf das sie sich beziehen. 36 Abbildung 3.3.2Beispiel Constraint In Abbildung 3.3.2 wird die Einschränkung formuliert, dass das Immatrikulationsdatum eines Studenten immer größer sein muss, als das Geburtsdatum. Die UML benutzt die Object Constraint Language (OCL) zur formalen Spezifikation von Einschränkungen (vgl. Kapitel 3.4). Classifier Ein Classifier bezeichnet in der UML ein Grundelement der UML, z. B. eine Klasse, Assoziation, Datentyp. Die Grundelemente der UML werden zu dem Element Classifier abstrahiert. Ein Classifier steht in der UML-Spezifikation immer für ein definiertes Element der UML. Es gibt aber kein grafisches Symbol für den Classifier. Stereotype - Stereotyp Stereotypen werden verwendet um Elemente zu Kategorien von Elementen zusammenzufassen. Man kann Klassen z. B. nach ihrer Verwendung in Oberflächenklassen (Stereotyp boundary), Entitätsklassen (Stereotyp entity) und fachliche Klassen (Stereotyp control) einteilen. Die UML kann durch Definition neuer Stereotypen erweitert werden. In Abbildung 3.3.1 ist der Stereotyp entity für die Klasse angegeben. 3.3.1 Klassendiagramm Class Diagram 3.3.1.1 Zweck Klassendiagramme stellen die statische Struktur eines Systems dar. Sie zeigen die Klassen, die Eigenschaften der Klassen (Attribute), das Verhalten (Operationen) der Klassen und die Beziehungen zwischen den Klassen. Sie sind der zentrale Diagrammtyp der UML und werden in allen Phasen der Softwareentwicklung eingesetzt. 3.3.1.2 Notation 37 Symbol Bedeutung Klasse Ein Klasse kann als Rechteck dargestellt werden, das den Klassennamen enthält. Üblicherweise bestehen Klassen aus drei Bereichen; der obere Bereich enthält den Stereotyp, das Paket zu dem die Klasse gehört und den Namen. Im mittleren Bereich werden die Attribute angegeben und im unteren Bereich stehen die Operationen der Klasse. Laut UML-Spezifikation kann die Darstellung einer Klasse zusätzliche Bereiche enthalten. Abstrakte Klasse Der Name einer abstrakten Klasse wird kursiv geschrieben. Alternativ kann die Eigenschaft {abstract} angegeben werden. Parametrisierte Klasse auch Template oder Schablone genannt. Die parametrisierte Klasse hat in der rechten, oberen Ecke ein das Klassensymbol überlappendes Rechteck, das die Schablonen-Parameter der Klasse enthält. Die Funktion, die den Parameter verwendet wird angegeben. Die Klasse, die den Parameter bindet, wird über eine gestrichelte Linie mit Pfeil an dem Template verbunden. Diese trägt die Bezeichnung <<bind>>. Assoziation Eine Linie zwischen den Klassen stellt eine Assoziation dar. Eine Assoziation ist eine Beziehung zwischen Klassen. Die Objekte der Klassen kommunizieren über die Assoziationen miteinander. Die Assoziation kann einen Namen haben. Ein Pfeil an dem Assoziationsnamen gibt die Leserichtung des Namens an. An den Assoziationsenden können die Rollen der beteiligten Klassen und die Multiplizität angegeben werden. Die zweigliedrige Assoziation kann, wie die mehrgliedrige Assoziation, durch eine Raute markiert werden. 38 Symbol Bedeutung Gerichtete Assoziation Mit einem Pfeil an der Assoziation kann die Navigationsrichtung angegeben werden. Der Pfeil drückt die Zugriffsrichtung der Objekte aus. Objekt A greift auf B zu, B greift nie auf A zu. Vererbung auch Generalisierung/Spezialisierung genannt. Vererbungsbeziehungen werden mit einem Pfeil dargestellt. Die Pfeilspitze zeigt auf die Oberklasse. Die Oberklasse vererbt ihre Eigenschaften an die Unterklassen. Aggregation Eine Aggregation drückt eine Teile-Ganzes-Beziehung aus. Das Ganze-Objekt besteht aus Teil-Objekten. Die Raute befindet sich an dem Ende des Ganzen. Die Aggregation ist eine spezielle Art der Assoziation. Da das Ganze die Teile enthält, sollten am Assoziationsende der Teile ein Navigationspfeil stehen. Komposition Die Komposition ist auch eine Beziehung, die Teile zu einem Ganzen in Beziehung setzt. Die Teile und das Ganze sind bei dieser Beziehung existenzabhängig; die Teile können nicht ohne das Ganze existieren. Wird das Ganze gelöscht, so beenden auch die Teile ihre Existenz. Assoziationsklasse Ist eine Klasse von dem Vorhandensein einer Assoziation zwischen zwei Klassen abhängig, so kann dies durch eine Assoziationsklasse ausgedrückt werden. Die Assoziationsklasse beschreibt Eigenschaften, die keiner der an der Assoziation beteiligten Klassen sinnvoll zuordenbar sind. Die Assoziationsklasse wird über eine gestrichelte Linie mit der Assoziation, von der sie abhängt, verbunden. Hat die Assoziation einen Namen, dann muss die Assoziationsklasse den selben Namen erhalten. Die Assoziationsklasse ist ein Analysekonzept. 39 Symbol Bedeutung Mehrgliedrige Assoziation Eine mehrgliedrige Assoziation drückt eine Beziehung zwischen mehr als 2 gleichwertigen Klassen aus. Die Beziehung wird mit einer Raute markiert. Tabelle 1Notation Klassendiagramm Klassen Objekte und Klassen sind die zentralen Elemente objektorientierter Modelle. Die gemeinsamen Eigenschaften konkreter Objekte werden zu Klassen abstrahiert. Die Klasse definiert die Struktur ihrer Objekte. Die UML 2.0 versteht unter einer Klasse ein Element, das eine Menge Objekte beschreibt, die die selbe Spezifikation der Merkmale, Einschränkungen und Semantik teilen [Omg 03b]. Eine Klasse hat Attribute und Operationen. Attribute und Operationen können in UML spezifiziert werden. Die Syntax für die Deklaration von Attributen lautet: [Sichtbarkeit] [/] Name [:Typ] [=Wert] Die Syntax für die Deklaration von Operationen lautet: [Sichtbarkeit] Name [(Parameterliste)] [: Returntyp] Die Parameterliste ist definiert als: [Übergaberichtung] Name [: Typ] [ =Wert] Die Syntaxelemente haben nachfolgende Bedeutung: • Sichtbarkeit gibt an, wie die Sichtbarkeit eines Elementes relativ zu seiner Umgebung ist. Die Sichtbarkeit gibt also an, welche Elemente auf ein Attribut, bzw. auf eine Operation zugreifen können. Der Zugriff auf ein Attribut definiert den lesenden und schreibenden Zugriff auf das Attribut; die Sichtbarkeit von Operationen gibt an, welche Elemente die Operation aufrufen können. Folgende Sichtbarkeitsmodi sind definiert. • • 40 public: Jedes andere Element hat Zugriff. privat: Der Zugriff ist auf die Objekte der Klasse selbst beschränkt. protected: Zugriff besteht nur für die definierende Klasse und die Vererbungslinien, die von ihr ausgehen. • package: Das Element ist sichtbar für alle Klassen, die sich im selben Paket befinden. Der Slash [/] kennzeichnet ein abgeleitetes Element. Ein abgeleitetes Element kann aus einem anderen Modellelement berechnet werden. Name gibt den Namen des Attributs oder der Operation an. • • • • Typ, Returntyp gibt den Datentyp eines Attributs, eines Parameters oder Returns an. Die UML definiert einige Typen, wie Integer, String, u. a. Macht aber keine Einschränkungen zur Verwendung selbstdefinierter Typen. Es können alle Typen verwendet werden, die zur Lösung eines Problems benötigt werden. • Wert Attribute und Parameter können mit einem Wert belegt werden. • Übergaberichtung definiert die Richtung in die ein Parameter übergeben wird. • • • IN- Parameter wird an die Operation übergeben. Die Operation liest den Parameter nur. OUT - der Parameter wird von der Operation geschrieben, ohne dass sie seinen Inhalt vorher verarbeitet. INOUT - die Operation liest einen Parameter, verarbeitet ihn und schreibt ihn erneut. Beispiel Abbildung 3.3.1.2.1Klasse Konto mit UML-Deklarationen Abbildung 3.3.1.2.1 zeigt ein Beispiel einer Klasse "Konto" die in UML deklariert ist. Das Attribut "KontoNr" ist vom Typ Integer, für "Guthaben" wurde ein eigener Typ mit dem Namen Real definiert. Der Typ Real steht für eine reelle Zahl (z. B. Float in C++). Die Operation einzahlen nimmt den Parameter "Betrag" vom Typ Real an und gibt einen Boolean-Wert zurück. Die Sichtbarkeit der Elemente wurde ausgeblendet. 41 Implementierung in C++ Abbildung 3.3.1.2.2Klasse Konto mit C++-Deklarationen Abbildung 3.3.1.2.2 zeigt die Klasse Konto mit Deklarationen in C++. Bei Einsatz eines CASE-Tools kann aus der UML-Deklaration die Deklaration in einer Zielsprache generiert werden. Class Konto { private: int KontoNr; float Guthaben; public: virtual bool einzahlen(float Betrag); }; Parametrisierte Klassen werden auch Templates oder Schablonen genannt. Wenn mehrere Klassen sich nur durch die Daten, auf denen sie arbeiten unterscheiden, können sie durch parametrisierte Klassen realisiert werden. Die parametrisierten Klassen werden mit Parametern versehen, die Typen enthalten können. Somit ist es möglich typunabhängige Algorithmen zu definieren und parametrisierten Klasse zur Verarbeitung verschiedener Datentypen zu verwenden. Assoziation Im Klassendiagramm drückt eine Assoziation eine Beziehung zwischen Klassen aus. Die Assoziation kann einen Namen haben. Die Rollen der beteiligten Klassen 42 können angegeben werden, die Multiplizität muss spätestens im Designmodell angegeben werden. Beispiel Abbildung 3.3.1.2.3Assoziation in UML-Darstellung Das Beispiel in Abbildung 3.3.1.2.3 zeigt die Assoziation "studiert" zwischen den Klassen "Student" und "Fachbereich". Die Multiplizität ist mit * zu 1 angegeben; ein Student studiert immer an einem Fachbereich, ein Fachbereich hat viele Studenten. Für Assoziationen wird üblicherweise entweder ein Assoziationsname angegeben, oder die Rollennamen der beteiligten Klassen werden angegeben. Von der Multiplizität hängt es ab, wie die Assoziation implementiert wird. In diesem Beispiel muss ein Student auf einen Fachbereich zugreifen, weil der Fachbereich mit der Multiplizität 1 an der Beziehung beteiligt ist. Der Student ist mit der Multiplizität * beteiligt; der Fachbereich muss deshalb auf viele Objekte der Klasse Student zugreifen. Implementierung der Assoziation in C++ Abbildung 3.3.1.2.4Realisierung der Assoziation in C++ Abbildung 3.3.1.2.4 zeigt die Realisierung der Assoziation studiert in C++. Für die Attribute werden die Stereotypen angezeigt; Attribute vom Stereotyp <<attribute>> beschreiben fachliche Eigenschaften der Klassen, der Stereotyp <<association implementer>> kennzeichnet Attribute, die eine Assoziation implementieren. 43 Der Student muss, wie oben beschrieben, auf den einen Fachbereich zugreifen zu dem er gehört. Dafür wurde bei dem Student der Pointer "Fachbereich *fachbereich" deklariert, über den er auf den Fachbereich zugreift. Der Fachbereich muss auf viele Studenten zugreifen. Für diesen Zugriff wurde die Menge "set<Student*> students" deklariert. Ein Set ist eine Struktur der Standard Template Library und verwaltet eine Menge von Elementen. Vererbung Die Vererbung ist ein Grundkonzept objektorientierter Programmiersprachen und dient der Wiederverwendung von Quellcode. Sie wird verwendet um Eigenschaften einer Oberklasse an Unterklassen zu vererben. Alle Eigenschaften (Attribute und Operationen) der Oberklasse, die für die Unterklasse sichtbar sind, werden an diese vererbt. Sie sind in der Unterklasse benutzbar, als wären sie in der Klasse selbst definiert. Die Unterklassen dürfen weitere, speziellere Eigenschaften haben. Aus der Sichtweise der Oberklasse sind die Unterklassen immer speziellere Klassen; aus der Sichtweise der Unterklassen ist die Oberklasse die allgemeinere, generellere Klasse. Deshalb wird die Vererbung auch Generalisierung oder Spezialisierung genannt. Abbildung 3.3.1.2.5Vererbung in UML In Abbildung 3.3.1.2.5 vererbt die "Person" ihre Eigenschaften an "Student" und den "FH-Angestellten". Die "Person" ist die generelle Klasse, "Student" und "FHAngestellter" sind spezielle Personentypen. Die "Person" hat die Attribute "Adresse" und "Name". Die Attribute der "Person" haben die Sichtbarkeit protec- 44 ted, damit sie an "Student" und "FH-Angestellter" vererbt werden. Attribute mit der Sichtbarkeit private sind nur in der Klasse selbst sichtbar und werden nicht an Unterklassen vererbt. Die Operation "aendereAdresse" ist public und wird ebenfalls an die Unterklassen vererbt. Der "Student" hat in diesem Beispiel die Attribute "Adresse", "Name" und "MatNr" und die Operationen "aendereAdresse", "immatrikulieren" und "exmatrikulieren". Die Einschränkung (constraint) "{incomplete}" gibt an, dass die Vererbung nicht vollständig ist; es gibt in einer Fachhochschule noch weitere Personentypen, die in der Vererbung nicht dargestellt sind. Die UML 2.0 definiert folgende constraints für Vererbungen: • • • • complete incomplete disjoint overlapping Implementierung der Vererbung in C++ Aus dem UML-Diagramm in Abbildung 3.3.1.2.5 ergibt sich das in 3.3.1.2.6 dargestellte Diagramm in C++-Sicht. Abbildung Abbildung 3.3.1.2.6Vererbung in C++ Class Person { protected: cAdresse Adresse; 45 string Name; public: virtual bool aendereAdresse(neuAdresse); }; class Student: public Analyse::Person { private: int MatNr; Fachbereich *fachbereich; public: virtual bool immatrikulieren(einStudent); virtual int exmatrikulieren(einStudent); }; class FH_Angestellter: public Person { private: int PersonalNr; public: virtual bool aendereGehalt(neuGehalt); }; Aggregation Die Aggregation wird verwendet um zwischen Klassen eine Teile-Ganzes-Beziehung aufzubauen. Abbildung 3.3.1.2.7 zeigt ein Beispiel einer Aggregation. Die Lehrveranstaltung setzt sich aus der Vorlesung und aus einem optionalen Praktikum zusammen. Die Multiplizität "0..1" mit der das Praktikum an der Aggregation beteiligt ist, drückt aus, dass es auch Lehrveranstaltungen ohne Praktikum gibt. 46 Abbildung 3.3.1.2.7Aggregation Da die Aggregation eine Spezialform der Assoziation ist, ist die Assoziation in durch zwei Assoziationen ersetzbar. Das Diagramm in Abbildung 3.3.1.2.7 ist äquivalent zu dem Diagramm in Abbildung 3.3.1.2.8. Die Aggregation wird hier durch die Rollenbezeichnung "besteht_aus" ausgedrückt. Abbildung 3.3.1.2.8Aggregation als Assoziation Implementierung der Aggregation in C++ Da die Aggregation eine Spezialform der Assoziation ist, wird sie wie eine Assoziation implementiert. 47 Komposition Abbildung 3.3.1.2.9Komposition Das Beispiel in Abbildung 3.3.1.2.9 zeigt eine Komposition. Die Komposition ist eine strengere Form der Aggregation und drückt aus, dass das Ganze und die Teile existenzabhängig sind. Die Teile und das Ganze bilden eine untrennbare Einheit; sie können deshalb nur als Einheit existieren. Die Teile dürfen immer nur zu einem Ganzen gehören; das Ganze kann keine Multiplizität größer 1 haben. In diesem Beispiel besteht eine Rechnung aus dem Rechnungskopf und den Positionen. Eine Rechnungsposition kann nur zu einer Rechnung gehören. Es kann keine Rechnungsposition geben, wenn es keine Rechnung gibt. Wird die Rechnung gelöscht, muss sie alle Rechnungspositionen und den Rechnungskopf löschen. Assoziationsklasse Die UML 2.0 definiert eine Assoziationsklasse als eine Assoziation, die Klasseneigenschaften hat, oder als Klasse, die Assoziationseigenschaften hat. Die Assoziationsklasse bezieht sich immer auf das Vorhandensein einer Beziehung zwischen Klassen und auf die Eigenschaften, die diese Beziehung zusätzlich hat. Der Name der Beziehung und der Name der Assoziationsklasse repräsentieren dasselbe Modellelement. Hat die Assoziation zu der die Assoziationsklasse assoziiert ist, einen Namen, dann muss die Assoziationsklasse den selben Namen tragen. Es genügt jedoch einem Element einen Namen zu geben. 48 Abbildung 3.3.1.2.10Assoziationsklasse In dem Beispiel in Abbildung 3.3.1.2.10 besteht eine Assoziation zwischen "Student" und "Lehrveranstaltung". Eine Lehrveranstaltung findet statt, wenn mindestens 3 Studenten teilnehmen; ein Student kann keine, oder mehrere Lehrveranstaltungen besuchen. Der "Leistungsnachweis" ist keiner dieser beiden Klassen zuordenbar, da er sich immer auf die Verbindung (Link) eines konkreten Exemplars von "Student" mit einem konkreten Exemplar von "Lehrveranstaltung" bezieht. Da die Assoziationsklasse immer die Multiplizität 1 hat, wird die Multiplizität nicht angegeben. 3.3.1.3 Anwendungsbereich Klassendiagramme sind der zentrale Diagrammtyp der UML. Sie beschreiben die Klassen eines Systems, ihre Eigenschaften, Operationen und die Beziehungen zwischen den Klassen. Klassendiagramme werden in allen Phasen der Softwareentwicklung eingesetzt. Die modellierten Inhalte und das verwendete Vokabular müssen sich an dem Know-how der beteiligten Personengruppen orientieren. Ein Klassendiagramm modelliert einen Teilausschnitt der realen Welt. Es werden nur die Klassen und Eigenschaften berücksichtigt, die zur Beschreibung des Problembereichs benötigt werden. Bei der Modellierung von Klassendiagrammen wird zwischen dem Analysemodell und dem Designmodell unterschieden. Diese verschiedenen Sichten auf ein Klassenmodell können durch den Einsatz von Entwicklungswerkzeugen, wie z. B. Case-Tools verwaltet und konsistent gehalten werden. Klassendiagramm Analyse Klassendiagramme in der Sichtweise der Analyse stellen dar, was das System aus Anwendersicht leisten soll. Sie bilden die Klassen, Attribute, Operationen und ihre Beziehungen ab, die das spätere Softwaresystems aus der Sicht des fachlichen Bereiches, den es abdecken soll, enthalten muss. 49 Das Analysemodell beschreibt was die zukünftige Software aus fachlicher Sicht leisten soll. Für die Informatikabteilung, die das geplante Produkt entwickeln soll, stellt das Analysemodell die Basis der zukünftigen Entwicklungsarbeit dar. Da Fehler in der Analyse sehr teuer sind, muss das Analysemodell sehr sorgfältig modelliert werden. In der Analyse sollten sprechende Namen verwendet werden, die auch die beteiligte Fachabteilung versteht. Die Deklaration von Attributen und Operationen wird in UML, nicht in der späteren Programmiersprache vorgenommen. Bei Einsatz eines CASE-Tools können daraus die Deklarationen in der gewählten Programmiersprache generiert werden. Klassendiagramm Design Im Designmodell wird das Analysemodell auf die Implementierungstechnologie abgebildet. Klassendiagramme in der Sichtweise Design stellen dar, wie das System technisch aufgebaut sein muss, damit es die in der Analyse geforderten Eigenschaften realisieren kann. Die in der Systemanalyse erkannten und dokumentierten Strukturen werden um die Informationen, die nötig sind um das fachliche Modell zu implementieren, erweitert. Im Design wird die Implementierungssprache festgelegt. Es wird definiert wie Assoziationen zu implementieren sind; die Art und Weise wie die Instanzen der Klassen verwaltet werden, wird festgelegt. Die Persistenzschicht wird modelliert, d. h. es wird definiert, wie die Klassen auf eine Datenbank abgebildet werden; die Datenbank wird ausgewählt. In der Regel werden bei der Implementierung eines Modells Klassenbibliotheken verwendet, deren Verwendung im Klassenmodell dokumentiert werden muss. Die Benutzeroberfläche muss eingeführt werden. 3.3.1.4 Zusammenhang Klassen werden in fast allen UML-Diagrammen verwendet. Die Klassen des Klassendiagramms wirken sich deshalb auf alle anderen Diagramme aus und sind mit den anderen Diagrammen eines Modells konsistent zu halten. 3.3.1.5 Hinweise für die Praxis Klassen identifizieren 50 Die UML definiert eine umfangreiche Notation zur Modellierung von Softwaresystemen. Vor der Modellierung der Struktur von Softwaresystemen müssen jedoch aus natürlichsprachigen Dokumentationen der Anforderungen an Systeme die enthaltenen fachlichen Objekte identifiziert werden. Alle Klassen, die den Problembereich für eine geplant Anwendung beschreiben, sind fachliche Klassen. Diese Klassen beschreiben die wichtigsten Merkmale der Anwendung. Wie findet man die in einem Text die enthaltenen Klassen? Es gibt zwei Techniken, die hier kurz skizziert werden. Substantivmethode Rumbaugh empfiehlt in [Rumbaugh, 1991] die Substantiv-Methode zur Identifikation von Klassen. Aus den Anforderungsdefinitionen an ein geplantes System werden alle Substantive markiert. Diese Begriffe sind potenzielle Klassenkandidaten. Danach werden redundante Begriffe eliminiert. Alle Begriffe, die auf die technische Realisierung der Begriffe hindeuten werden beseitigt. Durch diese kritische Analyse der Texte erhält man eine Menge Begriffe, die als Klassen im geplanten System verwendet werden können. CRC-Methode CRC bedeutet Class, Responsibility, Collaboration und bezeichnet eine Technik bei der für jede potenzielle Klasse eine Karteikarte angelegt wird, die drei Abschnitte enthält: • • • class – Klassennamen resposibility – Zuständigkeit collaboration - Zusammenarbeit Für jede Klasse wird der Klassenname notiert. Im Abschnitt Zuständigkeit wird beschrieben für welchen Zweck die Klasse eingeführt wurde, und unter Zusammenarbeit wird angegeben mit welchen anderen Klassen sie zusammenarbeitet. Die Substantivmethode und die CRC-Methode können auch kombiniert verwendet werden, indem man die Substantivmethode zum Auffinden der Klassen verwendet und die Klasseneigenschaften danach mit CRC-Karten (oder einem Texteditor) beschreibt. Attribute identifizieren Attribute sind die Eigenschaften der Klassen. Attribute sollten nur von der Klasse zu der sie gehören abhängig sein. Bei der Suche nach Attributen muss die Frage beantwortet werden: Was muss die Klasse über sich selbst wissen, damit sie arbeiten kann? Die Adjektive in der Anforderungsdefinition sind Kandidaten für Attribute. 51 Operationen identifizieren Operationen sind die öffentlich aufrufbaren Funktionen einer Klasse. Operationen sind die Schnittstellen einer Klasse, über die sie die Dienste, die sie implementiert, allen anderen Klassen des Systems anbietet. Assoziationen identifizieren Objekte kommunizieren über Assoziationen miteinander. Bei der Suche nach Assoziationen muss die Frage gestellt werden: Welche Objekte kommunizieren miteinander? In einem Projekt sind aber nur die Assoziationen zu modellieren, die zur Lösung des gestellten Problems benötigt werden. Die Verben in der Anforderungsdefinition geben Hinweise auf mögliche Assoziationen. Vererbungsstrukturen identifizieren Bei der Suche nach Vererbungsstrukturen sucht man gemeinsame Eigenschaften von Klassen, die in einer Oberklasse zusammengefasst werden können. Die Unterklasse muss alle geerbten Eigenschaften verwenden. Vererbung liegt dann vor, wenn eine Klasse eine Speziallfall einer anderen Klasse ist. Zwischen Oberklasse und Unterklasse besteht immer eine "ist-ein" Beziehung. Style Guide • • • Vererbungshierarchien sollten von oben nach unten angeordnet werden. Unterklassen sollten unterhalb ihrer Oberklasse stehen. Kreuzungen zwischen Beziehung sollten minimiert werden. Wird ein Klassendiagramm zu groß für eine Seite (einen Bildschirm), sollte es über mehrere Seiten in Teildiagramme verteilt werden. Für die Aufteilung der Klassen in Teildiagramme sollten fachliche Kriterien herangezogen werden. Neu in UML 2.0 Die Klassendiagramme sind in allen wesentlichen Elementen unverändert gegenüber der UML 1.x. 3.3.1.6 Beispiel Identifikation der Klassen 52 Aus den Spezifikationen des Use Case Diagramms "Mensa" wurden die Klassenkandidaten abgeleitet. Für den Use Case "KarteLaden" ergaben sich aus den markierten Begriffen in der Spezifikation folgende Klassenkandidaten: Automat, Karte, Kunden, Betrag, Display, Geld, Echtheit, Geldscheins, Restbetrag, Gesamtbetrag, Schein, Taste, Quittieren, Minute, Benutzung, Strom und Wiederkehr. Folgende Begriffe sind für den Problembereich überflüssig: Geld, Echtheit, Geldscheins, Minute, Benutzung, Strom und Wiederkehr. Sie werden eliminiert. Quittieren ist der Instanzname der Klasse Taste und wird eliminiert. Der Kunde ist ein Akteur, er ist damit kein Klassenkandidat. Damit bleiben nachfolgende Klassenkandidaten für den Use Case "KarteLaden": Automat, Karte, Display, Taste. Der Betrag ist ein Attribut von Karte. Abbildung 3.3.1.6.1 zeigt das Klassendiagramm zu dem Mensa Beispiel. Die "MensaKarte" wird von einer abstrakten "FH_Karte" abgeleitet. Das Attribut "ID" der "FH_Karte" hat die Sichtbarkeit protected und wird an die "MensaKarte" vererbt. "MensaAutomat" und "Kasse" stehen jeweils über Aggregationen in Beziehung zu den angegebenen Objekten. "Display" und "LeseSchreibEinheit" sind Teil von zwei Klassen; dies ist in der UML ausdrücklich erlaubt. Da das Beispiel ein Analysemodell darstellt, sind nur Analyseeigenschaften dargestellt. Es sind keine Elemente modelliert, die sich auf die Implementierung beziehen. Um die Lesbarkeit des Modells zu verbessern, wurde Farbe eingesetzt. Die Aggregationsbeziehungen sind blau, Assoziationen schwarz und Vererbungen rot dargestellt. 53 Abbildung 3.3.1.6.1Klassendiagramm Mensa 3.3.2 Objektdiagramm - Object Diagram 3.3.2.1 Zweck 54 Objektdiagramme werden eingesetzt um einen Schnappschuss eines Systems zur Laufzeit zu darzustellen. Es werden die zur Laufzeit existierenden Objekte, Attribute und Beziehungen angegeben. 3.3.2.2 Notation Symbol Bedeutung Objekt Für jedes Objekt wird der Klassenname und der Objektname angegeben. Für die dargestellten Attribute wird der Attributname, Typ und die aktuelle Wertbelegung angegeben. Link Ein Link ist eine aktuelle Beziehung zwischen Objekten. Er wird ähnlich der Assoziation im Klassendiagramm, als Linie zwischen den Objekten dargestellt. Es kann ein Name oder Rollenbezeichnungen angegeben werden Tabelle 2Notation Objektdiagramm 3.3.2.3 Beispiel Abbildung 3.3.2.3.1Beispiel Objekt Mensakarte Das Beispiel in Abbildung 3.3.2.3.1 zeigt das Objekt mit der Identität "123" der Klasse "MensaKarte". Das Attribut "Betrag" ist vom Typ "float" und hat den aktuellen Wert "2.60". 3.3.3 Komponentendiagramm - Component Diagram 55 3.3.3.1 Zweck Ein Komponentendiagramm beschreibt die physikalischen Komponenten aus denen ein System zusammengesetzt ist. Es stellt die Komponenten eines Modells, ihre Beziehungen und die öffentlichen Schnittstellen dar. Eine Komponente ist eine modulare, autonome Einheit innerhalb eines Systems, die über definierte Schnittstellen verfügt. Eine Komponente kann Schnittstellen anbieten, bzw. erfordern. Der interne Aufbau einer Komponente ist verborgen. Komponentendiagramme geben Auskunft darüber welche Teile eines Systems zusammenarbeiten. Eine Komponente ist innerhalb eines Modells austauschbar. 3.3.3.2 Notation Symbol Beschreibung Komponente (externe Sicht) Eine Komponente wird als Rechteck dargestellt. Sie trägt die Stereotypbezeichnung <<component>> und hat einen Namen. In der rechten, oberen Ecke kann sie das Komponentensymbol tragen. Das Symbol mit dem vollen Kreis stellt eine Schnittstelle dar, die die Komponente bereitstellt; das Symbol mit dem Halbkreis bezeichnet eine Schnittstelle, die von der Komponente genutzt wird. Komponente (interne Sicht) Komponenten können, ähnlich wie Klassen, vollständig dargestellt werden. In dem Bereich unter dem Namen werden die geforderten und bereitgestellten Schnittstellen aufgeführt; im nächsten Abschnitt werden die Klassen, die die Komponente realisieren angegeben. Im unteren Bereich wird die Datei angegeben, die die Implementierung der Komponente enthält. 56 Symbol Beschreibung Beziehungen können im Komponentendiagramm als gestrichelte Linien angegeben werden. Der Pfeil gibt zu Zugriffsrichtung an. Sind die Schnittstellen der Komponenten angegeben, ergibt sich aus den Symbolen die Zugriffsrichtung. Tabelle 3Notation Komponentendiagramm 3.3.3.3 Anwendungsbereich Komponentendiagramme werden eingesetzt um komponentenorientierte Software zu modellieren. Es ist damit möglich Komponenten und ihre Abhängigkeiten für Systeme, die in Komponententechnologie wie z. B. Enterprise Java Beans, .Net oder CORBA realisiert werden zu modellieren. Komponentendiagramme können auch verwendet werden, um die physischen Komponenten eines Systems zu modellieren, das nicht in Komponententechnologie realisiert wird. Die Komponenten geben dann die Zuordnung der Klassen zu den Quellcodedateien an. 3.3.3.4 Zusammenhang Da Komponenten häufig mehrere Klassen enthalten, müssen die Klassen den Komponenten zugeordnet werden. Komponentendiagramme und Klassendiagramme müssen konsistent gehalten werden. 3.3.3.5 Hinweise für die Praxis Für ein Komponentendesign gelten die selben Designprinzipien wie für ein Design auf Klassenebene; die Komponenten sollten eine hohe Kohäsion und eine lose Kopplung aufweisen. Neu in UML 2.0 In den UML-Versionen 1.x war eine Komponente eine Implementierungseinheit. Sie legte fest in welchen Quellcodedateien die Klassen eines Modells implementiert wurden. Es war zwar möglich Komponentendiagramme zum 57 Entwurf komponentenorientierter Software zu verwenden, aber die Notation sah es nicht explizit vor. Die in UML 2.0 mögliche explizite Angabe von bereitgestellten und geforderten Schnittstellen war in UML 1.x nur implizit möglich. 3.3.3.6 Beispiel Abbildung3.3.3.6.1Beispiel, Komponentendiagramm Mensaautomat Abbildung3.3.3.6.1 zeigt eine einfache Komponentenstruktur des Beispiels Mensaautomat. Im oberen Bereich wird der Name der Komponente angegeben, der untere Bereich gibt die Klassen an, die den Komponenten zugeordnet sind. Das Pluszeichen vor dem Klassennamen gibt die Sichtbarkeit public der Klassen innerhalb der Komponente an. Es werden die Komponentensymbole der UML 1.x verwendet; dies ist in der UML 2.0 ausdrücklich erlaubt. 3.3.4 Paketdiagramm - Package Diagram 3.3.4.1 Zweck 58 Pakete werden verwendet um Mengen von Modellelementen zu Gruppen zusammenzufassen. Sie dienen der Strukturierung von UML-Modellelementen in überschaubare Einheiten. Paketdiagramme stellen die Pakete und die Beziehungen (Abhängigkeiten) zwischen den Paketen eines Modells dar. Die Kriterien, nach denen Modelle strukturiert werden, sind frei festlegbar. 3.3.4.2 Notation Paket Ein Paket fasst eine Gruppe von beliebigen Modellelementen zusammen. Pakete können verschachtelt sein. Sie definieren einen Namensraum. In diesem Beispiel umfasst das Paket a die Pakete b und c. Abhängigkeiten zwischen Paketen werden als gestrichelte Pfeile dargestellt. Sie drücken aus, dass Pakete in einem Client-Server-Verhältnis zueinander stehen. Häufige Stereotypen für Abhängigkeiten in Paketdiagrammen sind <<import>> und <<access>>, womit ausgedrückt wird, dass ein Paket ein anderes importiert, bzw. darauf zugreift. Tabelle 4Notation Paketdiagramm 3.3.4.3 Anwendungsbereich Da Pakete Modellelemente zu Gruppen zusammenfassen, können sie für verschiedene Zwecke eingesetzt werden. Pakete können verwendet werden um Subsysteme zu modellieren, in die ein großes System zerlegt wird. Pakete können auch verwendet werden um die Ergebnisse von Entwicklungsphasen festzulegen und die entsprechenden Diagramme, die einer Phase zugeordnet werden, zusammenzufassen. Darüber hinaus können Pakete für jede sinnvolle Gruppierung von Modellelementen in einem Projekt eingesetzt werden. Die Systemarchitektur kann z. B. mit Paketen abgebildet werden. Jedes Paket definiert einen Namensraum. Namensräume geben Sichtbarkeitsbereiche von Modellelementen an; in einem Paket müssen Namen eindeutig sein. Jedes Modellelement gehört zu einem Paket. Zwei Elemente, die zu unterschiedlichen Namensräumen gehören dürfen denselben Namen tragen; um sie zu unterscheiden muss der Namensraum angegeben werden. 59 Der Zugriff auf die Elemente eines Paketes kann durch die Sichtbarkeit der Elemente gesteuert werden. Die Sichtbarkeit kann public, private oder protected sein. 3.3.4.4 Zusammenhang Pakete sind eine logische Zusammenfassung von Modellelementen. Folgende Elemente werden häufig zu Paketen zusammengefasst: • • • Klassen werden zu Realisierungseinheiten zusammengefasst. In C++ werden Pakete als namespace realisiert. In Java werden Pakete als Java-Package umgesetzt. Use Cases werden zu Paketen zusammengefasst, um in frühen Entwicklungsphasen ein Projekt in Teilprojekte zu zerlegen, die von verschiedenen Entwicklergruppen bearbeitet werden können. UML-Diagramme werden zu Paketen zusammengefasst, um die Entwicklungsergebnisse eines Projekts den Entwicklungsphasen zuzuordnen. Von Paketen können keine Instanzen gebildet werden. Sie können deshalb in keinen Interaktionsdiagrammen verwendet werden. 3.3.4.5 Beispiel Abbildung 3.3.4.5.1Beispiel Paketdiagramm Mensaautomat 60 Abbildung 3.3.4.5.1 definiert eine Paketstruktur für das Beispiel Mensaautomat auf der Ebene des Use Case Modells. Jedem Paket ist ein Use Case und alle den Use Case verfeinernden Diagramme zugeordnet. Dem Paket Geldautomat wären in diesem Beispiel folgende Diagramme zugeordnet: • • das Sequenzdiagramm "KarteLaden“ das Aktivitätsdiagramm "KarteLaden“ Durch dieses Paketdiagramm werden drei Subsysteme definiert, die von verschiedenen Projektteams selbständig bearbeitet werden können. 3.3.5 Anwendungsfalldiagramm - Use Case Diagram 3.3.5.1 Zweck In Use Case Diagrammen wird das externe Systemverhalten aus Anwendersicht beschrieben. Use Case Diagramme stellen das geplante System, die Akteure, die Verwendung des geplanten Systems (Anwendungsfälle) und die Beziehungen zwischen Akteuren und Anwendungsfällen dar. Use Case Diagramme geben Auskunft darüber, was ein geplantes System aus Sichtweise der Benutzer leisten soll. 3.3.5.2 Notation Symbol Bedeutung System Das Rechteck stellt das geplante System dar. Das System erhält einen Namen. Ein Use Case Diagramm kann auch mehrere Systeme enthalten, die ineinander geschachtelt sein dürfen. Dadurch kann ein System in Teilsysteme gegliedert werden. Akteur Ein Akteur ist ein Element, das nicht zum geplanten System gehört. Er kann eine Person sein, die auf das System zugreift, oder ein anderes System, das mit dem geplanten System kommuniziert. Die UML erlaubt mehrere Symbole zur Darstellung eines Akteurs. Er kann als Strichmännchen dargestellt werden. Es ist optional erlaubt ein Klassensymbol zu verwenden, das mit dem Stereotyp <<actor>> markiert wird. Zusätzlich können eigene Symbole verwendet werden um nicht menschliche Akteure darzustellen. 61 Symbol Bedeutung Use Case Eine Ellipse stellt einen Anwendungsfall des Systems dar. Ein Anwendungsfall ist ein in sich abgeschlossener Vorgang, der für einen oder mehrere Akteure ein beobachtbares Ergebnis liefert. Er beschreibt aus Sicht der Akteure welche Leistungen das System für den Anwender zur Verfügung stellt. Ein Use Case stellt somit einen Teil der Gesamtfunktionalität des Systems dar. In UML 2.0 kann auch ein Rechteck, das mit einer Ellipse markiert wird, als Use-Case-Symbol verwendet werden. Der Name kann innerhalb oder außerhalb des Symbols stehen. Extension points Das Verhalten eines Use Case kann durch einen weiteren Use Case erweitert werden. Dies wird durch die extend-Beziehung und den extension point angegeben. Die Beziehung wird gestrichelt dargestellt; der Pfeil zeigt auf den erweiterten Use Case und trägt den Stereotyp <<extend>>. Der extension point gibt den Ort im erweiterten Use Case an, an dem der erweiternde Use Case eingefügt wird. b erweitert das Verhalten von a. b wird an dem extension point "Name" in a eingefügt. include-Assoziation Die include Beziehung definiert einen Use Case, der die Funktionalität, die ein anderer Use Case zur Verfügung stellt, importiert. Der Use Case a importiert die Funktionalität des Use Case b. Vererbungsbeziehung In Use Case Diagrammen ist die Verebungsbeziehung erlaubt. Sie kann verwendet werden um Verhalten zwischen Use Cases zu vererben. Sie kann aber auch verwendet werden, um Vererbungsbeziehungen zwischen Akteuren aufzubauen. Assoziation Eine Linie stellt eine Assoziation zwischen einem Akteur und einem Use Case dar. Sie beschreibt den Zugriff des Akteurs auf die Funktionalität, die das System in diesem Use Case zur Verfügung stellt, bzw. eine Antwort des Systems an einen Akteur. Tabelle 5Notation Use Case Diagramm Use Case Diagramme stellen das für den Anwender sichtbare Verhalten eines Systems dar. Sie bestehen aus den in Tabelle 4 aufgeführten Notationselementen. Ein 62 System stellt ein vollständiges Hard- bzw. Softwaresystem dar. Das System enthält die Use Cases. Akteure sind extern und stehen außerhalb des Systems. Ein Use Case beschreibt eine Menge von Funktionen, die das System für die Benutzer implementiert. Der Benutzer ist der Auslöser eines Use Cases; er greift über die Assoziationen auf die Use Cases zu. Use Cases können eine Spezifikation enthalten, die in Form eines weiteren Diagramms oder als Freitext realisiert werden kann. Beispiel include und extend Beziehung Abbildung 3.3.5.2.1Beispiel include, extend Beziehung Abbildung 3.3.5.2.1 zeigt ein Beispiel zu einer include und extend Beziehung. Ein "Bearbeiter" erfasst einen Auftrag; er greift auf den Use Case "Auftrag erfassen" zu. Der Use Case "Auftrag erfassen" includiert (importiert) den Use Case "Kunden prüfen", d. h. bei jedem Erfassen eines Auftrags wird der Kunde geprüft. Includierte Use Cases werden beim Ausführen des includierenden Use Case immer ausgeführt. Der Use Case "Auftrag erfassen" hat den extension point "Kunde einfügen". Dieser verweist über die extend-Beziehung und die in der angehängten Notiz enthaltene Information auf den Use Case "Kunden erfassen". Das bedeutet, dass der Use Case "Kunden erfassen" nur dann ausgeführt wird, wenn die Bedingung "Kunde=neu" erfüllt ist. Durch die Angabe des extension points bei der Bedingung wird deutlich gemacht an welcher Stelle des erweiterten Use Case ("Auftrag erfassen") der erweiternde Use Case ("Kunden erfassen") im Ablauf des erweiterten Use Case eingefügt wird. Die extend Beziehung drückt also eine optionale Erweiterung eines Use Case aus, die nur unter bestimmten Bedingungen ausgeführt wird. 3.3.5.3 Anwendungsbereich Use Case Modelle werden zur Festlegung der Anforderungen an ein Softwaresystem (Anforderungsanalyse, Requirements engineering) eingesetzt. Use Case 63 Modelle sind leicht verständlich und ein gutes Kommunikationsmittel zwischen Systemanalytiker, Anwender und Entwickler. Sie legen die Grenzen des Systems fest, die Akteure, die darauf zugreifen und die Funktionalität des Systems. Die Funktionalität wird aus Sicht der zukünftigen Benutzer des geplanten Systems analysiert und definiert. Implementierungsdetails, wie z. B. die zu verwendende Programmiersprache, Systemarchitektur (Client-Server, ....), usw. sind in diesen Phasen noch nicht wichtig und deshalb zu vernachlässigen. In der Systemanalyse wird, z. B. in Meetings zwischen Systemanalytikern und Anwendern des künftigen Systems definiert was das System aus der Sicht der Anwender leisten soll. Die einzelnen Fälle, die das System abdecken soll, werden als Use Case in die Diagramme eingezeichnet und beschrieben. Ein Use Case Diagramm stellt also eine grobe Skizze des Systems dar, das den Zweck des geplanten Systems angibt, seine Grenzen und Schnittstellen, die auf es einwirken. Alle modellierten Elemente sind in einer Spezifikation zu beschreiben. Die Spezifikation sollte das Verhalten im Normalfall, mögliche alternativen Abläufe und das Verhalten im Fehlerfall enthalten. 3.3.5.4 Zusammenhang Die Use Cases stellen jeweils eine Menge von Systemfunktionen dar. Diese Funktionen sind in einem Projekt genauer zu beschreiben. Diese Spezifikation der Use Cases kann in Form eines anderen UML-Diagramms erfolgen, oder als strukturierter Text hinterlegt werden. Folgende Diagrammtypen sind zur Spezifikation von Use Cases geeignet: • • • • Aktivitätsdiagramme Sequenzdiagramme Interaktionsübersichtsdiagramme Kommunikationsdiagramme Stehen die Geschäftsprozesse im Vordergrund, so können Aktivitätsdiagramme verwendet werden. Damit können die Abläufe der Use Cases präzise beschrieben werden. Einzelne Szenen können in Sequenzdiagrammen oder in Kommunikationsdiagrammen modelliert werden, wenn die Interaktion von Objekten eine wichtige Rolle spielt. Interaktionsübersichtsdiagramme können verschiedene Interaktionsdiagramme einem Use Case zuordnen. Die Use Case Spezifikationen enthalten wichtige Informationen für das zu entwickelnde System. Aus den Spezifikationen können erste Klassenkandidaten für das statische Modell abgeleitet werden. 64 3.3.5.5 Hinweise für die Praxis Identifikation der Akteure In der Anforderungsanalyse ist es nötig die Akteure zu identifizieren und zu benennen. Dabei müssen die Fragen beantwortet werden: • Für wen wird das System entwickelt? • Wer soll das System benutzen? • Mit welchen anderen Systemen soll das geplante System interagieren? Identifikation der Systemgrenzen Die Use Cases sind Teil des Systems und enthalten die Funktionalität des zukünftigen Systems. Akteure sind Elemente, die nicht zu dem System gehören und auf das System zugreifen. Das System grenzt die Elemente, die zum System gehören von Elementen, die nicht zu dem System gehören ab. Alle Elemente innerhalb des Systems gehören zu dem System und sind zu entwickeln. Elemente außerhalb des Systems greifen auf das System zu. Identifikation der Use Cases Use Cases beschreiben den Zweck, für den ein System entwickelt wird auf einer hohen Abstraktionsebene. Sie beschreiben die Leistung, die ein System für den Benutzer erbringt. Folgende Fragen sind zur Identifikation von Use Cases hilfreich: • • • • Für welchen Zweck soll das System eingesetzt werden? Wofür will der spätere Benutzer es einsetzen? Durch welches externe Ereignis wird ein Use Case angestoßen? Welches Ergebnis liefert ein Use Case dem späteren Nutzer? Spezifikation der Use Cases Zur Spezifikation von Use Cases ist es vorteilhaft strukturierten Text zu verwenden. Die Textstruktur könnte folgende Abschnitte enthalten: • • • • • Name des Use Case Auslösendes Ereignis Verhalten im Normalfall Verhalten im Fehlerfall Ergebnis Identifikation der Beziehungen zwischen Akteuren und Use Cases Zur Identifikation der Beziehungen hilft die Beantwortung folgender Fragen: • Auf welche Use Cases greift ein Akteur zu? 65 • • Welche Antworten erhält er vom System? Über welche externen Ereignisse muss ein Use Case informiert werden? Style Guide • • • • Akteure und Use Cases sollten niemals in einem Diagramm isoliert sein (ohne Bezug zu anderen Modellelementen). Ein Use Case Diagramm sollte nicht mehr als ca. 10 Use Cases enthalten. Bei zu vielen Use Cases wird das Diagramm unübersichtlich. Zu viele Use Cases in einem Diagramm sind ein Hinweis darauf, dass die Granularität der Use Cases nicht korrekt gewählt wurde. Sollte das System zu groß sein, ist es sinnvoll es in Teilsysteme zu zerlegen und in mehrere Use Case Diagramme zu verteilen. Kreuzungen zwischen Assoziationen sind zu vermeiden. Akteure sind außerhalb des Systems einzuzeichnen. Neu in UML 2.0 Die Notationselemente für Use Case Diagramme sind in der UML 2.0 unverändert. Vorbedingung und der extension point müssen jetzt als Notiz an der extendBeziehung angegeben werden. 3.3.5.6 Beispiel Das Use Case Modell "Mensa" besteht aus den Use Cases "EssenZahlen", "KarteLaden" und "Umsatzstatistik"; das System wird für diese Zwecke verwendet. Die Akteure "Kunde", "MensaLeitung" und "KassenFrau" greifen auf das System zu. Der Zugriff von Servicetechnikern auf das System wird in dem Beispiel nicht modelliert. Nachfolgend sind die beiden Use Cases "EssenZahlen" und "KarteLaden" spezifiziert. Der Use Case "Umsatzstatistik" wird nicht detailliert spezifiziert und modelliert. Die unterstrichenen Begriffe in den Spezifikationen stellen die ersten Klassenkandidaten dar, die beim Lesen der Spezifikation gefunden wurden. Verfahren, die zur Identifikation von Klassenkandidaten geeignet sind, werden im Kapitel Klassendiagramm beschrieben. 66 Abbildung 3.3.5.6.1Beispiel, Use Case Diagramm Mensa Spezifikation Name des Use Case: KarteLaden Auslösendes Ereignis: Kunde schiebt eine Karte in den Automat Verhalten im Normalfall: Der Automat liest und prüft die Karte. Ist die Karte gültig, so zeigt er dem Kunden den Betrag, der noch auf der Karte gespeichert ist auf dem Display an. Ist die Karte ungültig, wird sie wieder ausgeschoben. Ist die Karte gültig, kann der Kunde Geld in den Automaten einschieben. Das Geld wird auf Echtheit überprüft. Ist das Geld echt, wird der Betrag des eingelegten Geldscheins zu dem Restbetrag, der noch auf der Karte gespeichert war, addiert und der Gesamtbetrag angezeigt. Wird das Geld vom Automaten nicht als echt akzeptiert, so schiebt er den Schein wieder aus. Der Kunde kann keine oder mehrere Geldscheine einschieben. Drückt der Kunde die Taste Quittieren, wird der aktuelle Betrag auf der Karte gespeichert und die Karte wird vom Automat ausgeschoben. Hat der Kunde kein Geld eingeschoben, erhält er die Karte unverändert zurück. Verhalten im Fehlerfall: Lässt ein Kunde seine Karte länger als eine Minute in dem Automat, ohne ihn zu bedienen, dann schiebt der Automat die Karte wieder aus. 67 Fällt während der Benutzung der Strom aus, dann schiebt der Automat nach Wiederkehr des Stroms Karte und Geld wieder aus. Der Geldbetrag auf der Karte bleibt unverändert. Ergebnis: Der Kunde erhält seine Karte zurück. Name des Use Case: EssenZahlen Auslösendes Ereignis: Kunde steht mit beladenem Tablett an der Kasse Verhalten im Normalfall: Die KassenFrau tippt das Essen in die Kasse. Der zu zahlende Gesamtbetrag wird auf dem Display angezeigt. Der Kunde schiebt seine Karte ein. Der Betrag, den das Essen kostet, wird abgebucht. Ist auf der Karte nicht mehr genug Geld gespeichert, wird eine entsprechende Fehlermeldung auf dem Display ausgegeben. Die Karte wird ausgeschoben. Verhalten im Fehlerfall: Ist die Karte für die Leseeinheit des Automaten nicht lesbar, so gibt er eine Fehlermeldung auf dem Display aus. Die Karte wird heraus geschoben. Fällt der Strom aus, während eine Karte im Automat ist, wird die Karte noch Wiederkehr des Stroms heraus geschoben. Der Bezahlvorgang muss wiederholt werden. Ergebnis: Der Kunde hat das Essen bezahlt und erhält die Karte zurück. 3.3.6 Sequenzdiagramm - Sequence Diagram 3.3.6.1 Zweck Sequenzdiagramme beschreiben die Kommunikation zwischen Objekten in einer bestimmten Szene. Es wird beschrieben welche Objekte an der Szene beteiligt sind, welche Informationen (Nachrichten) ausgetauscht werden und in welcher zeitlichen Reihenfolge der Informationsaustausch stattfindet. Sequenzdiagramme enthalten eine implizite Zeitachse. Die Zeit schreitet in einem Diagramm von oben nach unten fort. Die Reihenfolge der Pfeile in einem Sequenzdiagramm gibt die zeitliche Reihenfolge der Nachrichten an. 3.3.6.2 Notation 68 Symbol Bedeutung Klasse, Objekt In dem Rechteck oberhalb der gestrichelten Linie wird der Objektname und der Klassenname angegeben. Der Name wird unterstrichen. Die senkrechte, gestrichelte Linie stellt die Lebenslinie (lifeline) eines Objekts dar. Im diesem zeitlichen Bereich existiert das Objekt. Das schmale Rechteck auf der gestrichelten Linie stellt eine Aktivierung dar. Eine Aktivierung ist der Bereich, in dem eine Methode des Objektes aktiv ist (ausgeführt wird). Auf einer Lebenslinie können mehrere Aktivierungen enthalten sein. Nachricht, Botschaft Objekte kommunizieren über Nachrichten. Nachrichten werden als Pfeile zwischen den Aktivierungen eingezeichnet. Der Name der Nachricht steht an dem Pfeil. Eine Nachricht liegt immer zwischen einem sendenden und einem empfangenden Objekt. Synchrone Nachricht (Aufruf) Der Pfeil mit der ausgefüllten Spitze bezeichnet einen synchronen Aufruf. Der Aufruf erfolgt von der Quelle zum Ziel, d. h. die Zielklasse muss eine entsprechende Methode implementieren. Die Quelle wartet mit der weiteren Verarbeitung bis die Zielklasse ihre Verarbeitung beendet hat und setzt die Verarbeitung dann fort. Ein Aufruf muss einen Namen haben; in runden Klammern können Aufrufparameter angegeben werden. Der gestrichelte Pfeil ist der Return. Die Bezeichnung des Return mit einem Namen ist optional. Asynchrone Nachricht Mit einer offenen Pfeilspitze werden asynchrone Nachrichten gekennzeichnet. Der Aufruf erfolgt von der Quelle zum Ziel. Die Quelle wartet mit der Verarbeitung nicht auf die Zielklasse, sondern setzt ihre Arbeit nach dem Senden der Nachricht fort. Asynchrone Aufrufe werden verwendet, um parallele Threads zu modellieren. Objekt erzeugen, zerstören Das Erzeugen eines Objektes wird durch eine Nachricht, die im Kopf des Objekts endet dargestellt. Das Zerstören (Löschen) eines Objektes wird durch ein x auf der Lebenslinie markiert. 69 Symbol Bedeutung Rekursion Sendet ein Objekt eine Nachricht an sich selbst, so ruft es eine Methode auf, die es selbst implementiert. Tabelle 6 Notation Sequenzdiagramm Ein Sequenzdiagramm enthält Objekte, Lebenslinien, Aktivierungen, Nachrichten und kombinierte Fragmente (combined fragment). Mit kombinierten Fragmenten können in Sequenzdiagrammen die Kontrollstrukturen höherer Programmiersprachen ausgedrückt werden. Jedes kombinierte Fragment wird als rechteckiger Block dargestellt. In der linken, oberen Ecke trägt er eine Bezeichnung, die den Typ der Kontrollstruktur angibt (interaction operator). Die wichtigsten kombinierte Fragmente der UML 2.0 sind weiter unten erläutert. Abbildung 3.3.6.2.1Prinzip Sequenzdiagramm Abbildung 3.3.6.2.1 stellt das Prinzip des Sequenzdiagramms in UML 2.0 dar. In der linken, oberen Ecke steht der Diagrammtyp (sd) und der Name des Diagramms (NameSQ). Im Diagramm sind die beiden Objekte objA und objB enthalten. Sie existieren während der gesamten Szene; das ist daran ersichtlich, dass die Lebenslinien bis zum unteren Bildrand durchgezogen sind und kein x enthalten, das das Zerstören eines Objektes ausdrückt. Sequenzdiagramme können in der UML 2.0 verschachtelt sein. Aus einem Sequenzdiagramm kann auf Sequenzen in einem anderen Diagramm verwiesen 70 werden. Der mit ref bezeichnete Block stellt einen Verweis auf ein Diagramm mit dem Namen "SQ-Diagramm 2" dar, das eine Verfeinerung des Blockes enthält. Der mit alt markierte Block beschreibt eine Alternative (Verzweigung). Ist die Bedingung [b=wahr] erfüllt, wird der Bereich oberhalb der gestrichelten Linie in dem alt-Block ausgeführt. Im else-Fall wird der Bereich unterhalb der gestrichelten Linie ausgeführt. Abbildung 3.3.6.2.2Schleife in Sequenzdiagramm Abbildung 3.3.6.2.2 zeigt eine Schleife in einem Sequenzdiagramm. Die modellierte Szene ist eine Variation des Beispiels Mensaautomat. Es sind drei Objekte an der Szene beteiligt. Das Objekt Kunde ist vom Stereotyp <<actor>>. Er ist ein Akteur (aus dem Use Case Diagramm) und greift auf den MensaAutomat zu, indem er ihm die Botschaft "geldEin" sendet; diese Botschaft übergibt den Parameter "Betrag". Danach sendet der "MensaAutomat" die Botschaft "anzeige (Betrag)" an das "Display". Das "Display" führt die Methode aus und gibt die Kontrolle über den Return wieder an den "MensaAutomat" zurück. Der "MensaAutomat" gibt die Kontrolle wieder an den "Kunden" zurück. Diese Sequenz von Botschaften wird solange ausgeführt bis die Abbruchbedingung [Summe reicht] erfüllt ist. Das Prüfen des Geldes auf Echtheit ist in diesem Beispiel nicht modelliert worden. 3.3.6.3 Anwendungsbereich Sequenzdiagramme werden zur Darstellung der Kommunikation von Objekten eingesetzt. Sie können in der Analyse und im Design eingesetzt werden. Sequenzdiagramme werden häufig verwendet, um Szenarios eines Systems zu modellieren. Ein Szenario (Szene) ist die Beschreibung einer Sicht auf einen Teil 71 eines Systems. Sequenzdiagramme können auch zur Modellierung von komplexen Operationen eines Systems verwendet werden und detaillierte Designinformationen enthalten. Ein System wird in der Regel nicht vollständig durch Sequenzdiagramme spezifiziert. Es werden nur die Szenen modelliert, die häufig vorkommen oder besonders wichtig sind. 3.3.6.4 Zusammenhang Jedes Sequenzdiagramm kann sich auf einen Use Case beziehen. Da Use Case Diagramme aber nicht in jedem Projekt verwendet werden, können Sequenzdiagramme auch unabhängig von Use Case Diagrammen eingesetzt werden. Die Klassen der Sequenzdiagramme müssen in den Klassendiagrammen enthalten sein. Ereignisse und Nachrichten erfordern entsprechende Methoden bei den Zielklassen. Alternativ zu den Sequenzdiagrammen können auch Interaktionsübersichtdiagramme, Kommunikationsdiagramme, Zeitverlaufsdiagramme oder Aktivitätsdiagramme verwendet werden. 3.3.6.5 Hinweis für die Praxis Sequenzdiagramme werden zur Modellierung von Interaktionen gewählt, wenn die Darstellung der Reihenfolge des Nachrichtenaustauschs wichtig ist. Bevor Sequenzdiagramme modelliert werden können, müssen die an der Szene beteiligten Klassen identifiziert werden. Hinweise zur Identifikation von Klassen befinden sich im Kapitel 3.3.1 Klassendiagramm. Die in Sequenzdiagrammen modellierten Objekte und Nachrichten müssen konsistent zu den Klassendiagrammen gehalten werden. Da Sequenzdiagramme dynamische Aspekte eines Systems darstellen, müssen normalerweise Instanznamen und Klassennamen angegeben werden. Häufig vernachlässigt man jedoch den Instanznamen und gibt nur den Klassennamen an. Ein solches anonymes Objekt steht stellvertretend für alle Objekte der Klasse und impliziert, dass alle Objekte der Klasse sich in der Szene gleich verhalten. Style Guide • 72 Objekte sollten so angeordnet werden, dass in einem Diagramm möglichst wenig Kreuzungen entstehen. • • • • • Nachrichten sollten von links nach rechts zeigen, Returns von rechts nach links. Nachrichtennamen sollten an der Spitze der Pfeile stehen. Beteiligte Akteure sollten am linken Rand der Diagramme stehen. Namen der Akteure sollten konsistent zu den Use Case Diagrammen sein. Klassennamen sollten konsistent zu dem Klassendiagramm sein. Neu in UML 2.0 Folgende Elemente sind in der UML 2.0 neu oder geändert gegenüber UML 1.x: • • • Verschachtelung von Diagrammen mittels Referenzen. Darstellung der Kontrollstrukturen höherer Programmiersprachen (Verzweigung, Schleifen ..) mittels kombinierter Fragmente. Es wurden zwei neue Nachrichtentypen eingeführt; "lost" und "found", die in diesem Skript nicht behandelt werden. 3.3.6.6 Beispiel Sequenzdiagramm der Szene Karte laden Abbildung 3.3.6.6.1Beispiel Sequenzdiagramm Karte laden Dieses Sequenzdiagramm modelliert die Szene "Karte laden". Es bezieht sich auf den Use Case "KarteLaden" des Use Case Diagramms "Mensa". 73 Für einige Objekte ist ein Objektnamen angegeben, bei anderen Objekten wurde er vernachlässigt. Objekte der Klassen "LeseSchreibEinheit" und "Display" tragen einen Objektnamen, weil sie Teil des Mensaautomaten und der Kasse sind. Zur Unterscheidung erhielten sie einen Objektnamen. Die Objekte der Klassen "Knopf" und "GeldEinzug" sind im Modell nur einmal vorhanden, der Objektnamen wurde deshalb nicht angegeben. Die Lebenslinien des Display-Objekts und des Karten-Objekts sind nicht bis zum unteren Rand des Diagramms durchgezogen; dadurch werden Kreuzungen vermieden, das Diagramm wird übersichtlicher. Die Nachrichtennamen stehen immer in der Nähe der Pfeilspitzen. Wenn es möglich war, wurden sie über den Pfeilen angegeben. Dadurch ist die Zuordnung der Namen eindeutig und das Diagramm ist leicht lesbar. Auf die Verwendung von kombinierten Fragmenten wurde verzichtet. Das Diagramm enthält eine Alternative, die durch Notizen an den beiden Nachrichten, die alternativ gesendet werden, markiert ist. Der Akteur "Kunde" greift auf das Objekt "mAutomat" der "LeseSchreibEinheit" zu, indem er die Nachricht "KarteEin(meineKarte)" sendet. Er übergibt über diese Nachricht den Parameter "meineKarte" an die "LeseSchreibEinheit". Die "LeseSchreibEinheit" liest die "MensaKarte" und lädt sie in ihren Speicher. Die "MensaKarte" ist ein passives Objekt (Datenträger). Auf die Verwendung eines Konstruktoraufrufs wurde verzichtet. Die "MensaKarte" gibt über den Return den "Betrag" an die "LeseSchreibEinheit" zurück. Diese sendet die Nachricht "zeige" an das Display und übergibt den "Betrag". Der Kunde kann jetzt zwischen den markierten Zweigen der Alternative wählen; er kann Geld einlegen oder den Knopf drücken und die Karte zurückfordern. Es wird jeweils der Zweig des Diagramms ausgeführt, der den beiden Alternativen folgt. Über die Nachricht "GeldEin()" wird der Geldeinzug aktiviert. Er zieht den eingelegten Schein ein und ruft seine eigene Methode "pruefeSchein()" auf. Der Return gibt TRUE oder FALSE zurück. Ist die Bedingung "[Schein nicht echt]" erfüllt, ruft der "Geldeinzug" seine eigene Methode "GeldRaus()" auf und gibt den Schein zurück. Trifft die Bedingung "[Schein echt]" zu, sendet er dem Display die Nachricht "zeige(Betrag)"; der Betrag wird auf dem Display angezeigt und danach auf die "MensaKarte" gespeichert. Da mehrere Scheine hintereinander eingeschoben werden können, kann die entsprechende Sequenz von Nachrichten mehrfach ausgeführt werden. Dies wurde durch die beiden waagrechten Linien und dem mit "repeat" bezeichneten Pfeil ausgedrückt. Das kombiniert Fragment loop wurde wegen der Einfachheit des Diagramms nicht eingesetzt. Nachdem genügend Scheine eingeschoben wurden, drückt der Kunde auf den Knopf. Der Knopf teilt dieses Ereignis über die Nachricht "knopfGedrueckt" der "LeseSchreibEinheit" mit. Diese aktiviert ihre eigene Methode "KarteRaus" und gibt die Karte wieder aus. 74 75 Sequenzdiagramm der Szene Essen zahlen Abbildung 3.3.6.6.2Beispiel, Sequenzdiagramm Karte laden Dieses Sequenzdiagramm modelliert die Szene "Essen zahlen". Es bezieht sich auf den Use Case "EssenZahlen" des Use Case Diagramms "Mensa". Aufgabe: Interpretieren Sie dieses Diagramm. 76 3.3.7 Kommunikationsdiagramm - Communication Diagram 3.3.7.1 Zweck In Kommunikationsdiagrammen wird die Interaktion zwischen Objekten dargestellt. Sie geben die Beziehungen zwischen den Objekten an und die Nachrichten, die übertragen werden. Dabei steht der Überblick der Kommunikationsstruktur im Vordergrund. Die Darstellung der zeitlichen Reihenfolge, in der die Nachrichten gesendet werden, kann durch eine Nummerierung vorgenommen werden. 3.3.7.2 Notation Symbol Beschreibung Objekt Das Rechteck stellt eine Objekt dar. Es kann einen Objektnamen und einen Klassenenamen tragen. Beziehung, Nachricht Die Kommunikationsbeziehungen zwischen Objekten werden als Linie dargestellt. An die Beziehungen werden die Nachrichten, die darüber übertragen werden geschrieben. Die Nummerierung vor den Nachrichtennamen gibt die zeitliche Reihenfolge der Nachrichten an. Der Pfeil gibt die Richtung der Nachrichten an. Tabelle 7Notation Kommunikationsdiagramm 3.3.7.3 Anwendungsbereich Kommunikationsdiagramme stellen den Informationsaustausch zwischen Objekten dar. Sie können die gesamte Struktur einer Anwendung abbilden oder sich auf Teile einer Anwendung beziehen. Kommunikationsdiagramme werden für die selben Zwecke eingesetzt wie Sequenzdiagramme. 3.3.7.4 Zusammenhang 77 Da die Kommunikationsdiagramme alternativ zu Sequenz Diagrammen verwendet werden, sind die selben Zusammenhänge zu berücksichtigen, die unter Sequenzdiagrammen beschrieben sind. 3.3.7.5 Hinweise für die Praxis Kommunikationsdiagramme werden dann als Alternative zu Sequenz Diagrammen verwendet, wenn an einer Szene viele Objekte beteiligt sind, die wenige Nachrichten austauschen. Sind wenige Objekte an einer Szene beteiligt, die viele Nachrichten austauschen, sind Sequenz Diagramme wegen der übersichtlicheren Darstellung der zeitlichen Zusammenhänge vorzuziehen. Neu in UML 2.0 Der Name der Kommunikationsdiagramme in der UML 2.0 ist neu, die Notation ist unverändert geblieben. In der UML 1.x wurden diese Diagramme mit dem Namen Kollaborationsdiagramme, Collaboration diagram bezeichnet. 3.3.7.6 Beispiel Dieses Kommunikationsdiagramm zeigt die Kommunikation der Objekte, die an der Szene "EssenZahlen" beteiligt sind. Es macht deutlich, über welche Kommunikationswege die Objekte Informationen austauschen. Die zeitliche Reihenfolge ist jedoch in dem entsprechenden Sequenzdiagramm besser zu sehen. Dass die Nachrichten "essenEin" und KarteEin" parallel erfolgen können, ist in Kommunikationsdiagrammen nicht darstellbar. Diese Information ist am übersichtlichsten in dem Aktivitätsdiagramm modellierbar. Die Nummerierung wurde so gewählt, daß die erste Stelle der Nummer den "Zweig" angibt und die zweite Stelle die Reihenfolge in einem Zweig. Es wird also zuerst die Nachricht mit der Nummer 1 und danach 1.1 gesendet. Im unteren Zweig wird in folgender Reihenfolge kommuniziert: 2, 2.1, 2.2, danach wird entweder 2.3a oder 2.3b gesendet. 78 Abbildung 3.3.7.6.1Beispiel, Kommunikationsdiagramm Essen zahlen 3.3.8 Zeitverlaufsdiagramm - Timing-Diagram 3.3.8.1 Zweck Timing-Diagramme stellen das zeitliche Verhalten von Systemelementen (Classifier z. B. Klassen, Objekte, Komponenten) in einem bestimmten Zeitraum dar. Es wird damit ausgedrückt, wann ein Objekt seinen Zustand ändert und wie lange es für eine Aktion benötigt. Werden mehrere Classifier in einem Diagramm dargestellt, können die Interaktionen zwischen den Classifiern ebenfalls modelliert werden. Timing Diagramme stammen aus der Elektrotechnik und werden zur Visualisierung von Signalverläufen eingesetzt. 3.3.8.2 Notation Die Notation des Zeitverlaufdiagramms ist in dem Beispiel erläutert. 79 3.3.8.3 Anwendungsbereich Timing Diagramme sollten verwendet werden, wenn das zeitliche Verhalten modularer Systeme spezifiziert wird. Sie eignen sich zur Visualisierung der Abhängigkeiten zwischen den Modulen. 3.3.8.4 Zusammenhang Zeitverlaufdiagramme müssen konsistent in einem Modell integriert werden. Die verwendeten Klassen müssen in dem Klassenmodell existieren. Die Zustände müssen in den Zustandsdiagrammen der entsprechenden Klassen vorhanden sein. Die Nachrichten müssen mit den restlichen Interaktionsdiagrammen und den Klassendiagrammen übereinstimmen. 3.3.8.5 Hinweis für die Praxis Neu in UML 2. Timing Diagramme sind neu in der UML 2.0. 3.3.8.6 Beispiel Das Beispiel modelliert das Laden einer Karte. Die Diagrammelemente sind mit hellgrauer Schrift bezeichnet. Der obere Bereich enthält die Lebenslinie des Mensaautomaten, der untere Bereich die Lebenslinie eines Studierenden, der den Automat benutzt. Auf der y-Achse sind die Zustände der Objekte angegeben, die xAchse enthält die Zeitskala. Die Treppenkurve zeigt die Zustandsübergänge und die Dauer, für die ein Objekt in einem Zustand bleibt. Zwischen den Lebenslinien sind die Nachrichten, über die die beteiligten Objekte miteinander interagieren angegeben. Die Zeitbedingung "T<1s" drückt aus, dass das Laden der Karte nicht länger als eine Sekunde dauern darf. Das Timing Diagramm ist vom Typ sd - Sequenzdiagramm. 80 3.3.9 Interaktionsübersicht Diagramm - Interaction Overview Diagram 3.3.9.1 Zweck Interaktionen können in der UML in verschiedenen Diagrammtypen dargestellt werden, wie z. B. Sequenzdiagramm, Aktivitätsdiagramm, Kommunikationsdiagramm, Zeitverlaufsdiagramm. Jedes dieser Diagramme stellt eine bestimmte Sicht auf ein System oder einen bestimmten Ausschnitt eines Systems dar. In Interaktionsübersichts Diagrammen können Teildiagramme in Bezug zueinander gesetzt werden. Das Interaktionsübersicht Diagramm enthält 81 Rahmen, die eine Interaktion, bzw. eine Referenz auf ein Interaktionsdiagramm darstellen. Die Rahmen werden über die aus den Aktivitätsdiagrammen bekannten Kontrollstrukturen miteinander verknüpft. Interaktionsübersicht Diagramme sind spezielle Aktivitätsdiagramme, bei den die Aktivitäten durch die Interaktionsrahmen ersetzt sind. 3.3.9.2 Anwendungsbereich Interaktionsübersicht Diagramme können zur Modellierung von System mit vielen Interaktionen verwendet werden. Interaktionsübersicht Diagramme geben eine Übersicht über das Zusammenspiel von mehreren Interaktionsdiagrammen. 3.3.9.3 Zusammenhang Da Interaktionsrahmen Referenzen auf andere Interaktionsdiagramme repräsentieren, müssen die referenzierten Diagramme konsistent gehalten werden. 3.3.9.4 Hinweis für die Praxis Neu in UML 2. Interaktionsübersicht Diagramme sind neu in der UML 2.0. 3.3.9.5 Beispiel Das Beispiel stellt ein Interaktionsübersicht Diagramm dar. Der mit sd bezeichnete Rahmen enthält ein Sequenzdiagramm. Die beiden mit ref bezeichneten Rahmen enthalten eine Interaktionsreferenz, werden also in weiteren Diagrammen verfeinert. 82 3.3.10 Zustandsautomat-State Machine Diagram 3.3.10.1 Zweck Zustandsautomaten sind Diagramme zur Spezifikation des Verhaltens von Classifiern (Elemente). Cassifier können sein: Klassen, Komponenten, Systeme, Zustandsautomaten beschreiben das Verhalten der Elemente während ihres Lebenszyklus durch Darstellung der möglichen Zustände und Zustandsübergänge. Sie zeigen Aktivitäten, die Elemente in den Zuständen ausführen und Ereignisse und Bedingungen, die Zustandsübergänge verursachen. Die UML 2.0 unterscheidet state machines, die Verhalten von Systemen oder Systemteilen beschreiben, und state machines, die Protokolle, die von einem Systemelement realisiert werden, modellieren. Zustandsautomaten werden häufig zur Darstellung des Lebenszyklus von Objekten benutzt, können sich aber auch auf andere Elemente beziehen. 83 3.3.10.2 Notation Da die Notationselemente für Zustandsautomaten sehr komplex sein können, werden sie hier in zwei Bereichen behandelt: die grundlegenden Konzepte der Zustandsautomaten werden im Abschnitt Notation - Konzept beschrieben, die weiterführenden Konzepte werden unter Notation - erweitert dargestellt. Notation - Konzept Symbol Beschreibung Anfangs-, Endzustand (initial state, final state) geben den Beginn und Ende des Lebenszyklus eines modellierten Elementes an. Wird ein Objekt erzeugt, befindet es sich im Anfangszustand, wird es gelöscht, befindet es sich im Endzustand. Zustand (state) Elemente können im Laufe ihrer Existenz eine endliche Anzahl Zustände einnehmen. Der Zustand wird als Rechteck mit abgerundeten Ecken dargestellt. Zustände können einen Namen erhalten. Ein Zustand kann durch eine waagrechte Linie unterteilt werden. Unterhalb der Linie können Aktivitäten und interne Transitionen angegeben werden. Diese werden in dem Zustand ausgeführt. Die UML definiert folgende internen Aktivitäten: entry, exit und do. Die entry-Aktivität wird beim Eintritt in den Zustand ausgeführt, die exitAktivität vor Verlassen des Zustands. DoAktivitäten werden zwischen entry und exitAktivität ausgeführt und können länger andauern. Interne Transitionen werden intern ausgeführt, führen jedoch nicht zu einem Zustandsübergang. Es kann ein Auslöser (Trigger) angegeben werden, eine Bedingung (guard), die erfüllte sein muß und eine Aktivität, die ausgeführt wird. 84 Symbol Beschreibung Zustandsübergang (Transition) Eine Transition ist ein Zustandsübergang von einem Quellzustand zu einem Zielzustand. Die Beschriftung gibt den Auslöser (Trigger) an, die Bedingung, die erfüllt sein muß (guard) und die Aktivität, die beim Übergang ausgeführt wird. Die Beschreibungselemente sind optional. Sie können beliebig kombiniert werden. Zustand (State) Der Zustand (state) eines Objekts wird durch die Attributwerte bzw. Daten und die jeweiligen Verbindungen zu anderen Objekten bestimmt [Balzert, 1999]. Die UML 2.0 unterscheidet drei Zustandstypen: • einfacher Zustand - simple state • zusammengesetzter Zustand - composite state • Unterzustandsautomatenzustand - submachine state Einfacher Zustand (simple state) Ein einfacher Zustand hat keine Unterzustände (Regionen oder submachine state machine). Ein einfacher Zustand kann entry, exit und do-Aktivitäten enthalten und interne Transitionen. Nach Erreichen eines Zustands wird sofort die entry-Aktivität ausgeführt. Vor Verlassen des Zustands wird die exit-Aktivität ausgeführt. Die doAktivität wird nach Beendigung der exit-Aktivität ausgeführt. Zustandsübergang (Transition) Eine Transition wird durch einen Auslöser (Trigger) verursacht. Der Trigger kann intern sein oder extern; er kann von dem Objekt kommen, auf das die state machine sich bezieht, oder von einem anderen Objekt. Für einen Zustandsübergang kann eine Bedingung (guard) angegeben werden, die erfüllt sein muß, damit die Transition ausgeführt wird. Bei einer Transition kann ein Objekt eine Aktivität ausführen, die zu dem Aufruf einer Methode führt. Einfacher Zustandsautomat Zustandsautomaten beschreiben den Lebenszyklus von Objekten, können sich aber auch auf komplexere Elemente beziehen, wie z. B. Komponenten, Subsysteme oder Use Cases. Sie stellen die Zustände dar, die Objekte, Komponenten usw. im 85 Laufe ihrer Existenz annehmen können und sie geben die Zustandsübergänge an, die möglich sind. Ein Zustandsautomat gibt auch an, in welchem Zustand ein Objekt auf welche Ereignisse reagiert. Diese Abbildung stellt einen einfachen Zustandsautomat einer Tür dar. Die Tür kann die beiden Zustände offen und geschlossen annehmen. Sie reagiert auf die Ereignisse schliessen und öffnen. In dem Zustand offen kann jedoch nur das Ereignis schliessen angewandt werden, in dem Zustand geschlossen kann nur das Ereignis öffnen angewandt werden. Dieses Beispiel modelliert eine Loginmaske eines Rechners. Sie hat die Zustände "UserNameEingabe" und "PasswortEingabe". In dem Zustand "UserNameEingabe" führt sie die Aktivität "ZeichenLesen" aus. Ist die Bedingung "[Cursor in Feld Passwort]" erfüllt, so wechselt sie zu dem Zustand 86 "PasswortEingabe". Sobald die Maske den Zustand betritt führt sie die entryAktivität "Echo aus" aus, sie schaltet das Echo aus und zeigt das Passwort nicht auf dem Bildschirm an. Danach liest sie mit der Aktivität "ZeichenLesen" das Passwort ein und schaltet bei Verlassen des Zustands mit der exit-Aktivität "Echo an" das Bildschirmecho wieder ein. Symbol Beschreibung Region (Region) Regionen können in zusammengesetzten Zuständen und in state machine Diagrammen verwendet werden. Sie stellen parallele Abläufe oder parallele Zustände dar. Regionen können einen Namen haben. Die Regionen in einem Zustand werden durch eine gestrichelte Linie voneinander abgegrenzt. Regionen können Zustände und Transitionen enthalten. Pseudozustände sind Knoten in einem Zustandsdiagramm, die es erlauben komplexe Zusammenhänge zwischen Zuständen darzustellen (z. B. Verzweigungen, Parallelität usw.). Pseudozuständen werden keine Aktivitäten zugeordnet. Die Erläuterung der Pseudozustände erfolgt in der nächsten Version des Skriptes. Entscheidung Kreuzung Terminator Eintrittspunkt Austrittspunkt 87 Symbol Beschreibung Gabelung Vereinigung Flache Historie Tiefe Historie Zusammengesetzter Zustand (composite state) Ein zusammengesetzter Zustand ist ein Zustand, in dem Unterzustände möglich sind. Das Beispiel stellt die Zustände einer abschließbaren Tür dar. Die Tür kann die Zustände zugeschlossen und aufgeschlossen haben. Nur in dem Zustand aufge- 88 schlossen kann sie die Unterzustände offen und geschlossen haben. Ist das untergeordnete Zustandsdiagramm zu groß um im Zustand dargestellt zu werden, kann es auch in einem Verfeinerungsdiagramm modelliert werden. Unterzustandsautomatenzustand (submachine state) Der Unterzustandsautomatenzustand ist ein gutes Beispiel für unverständliche Wortungetüme, die die deutsche Sprache hervorbringen kann. Der Submachine State bezeichnet einen Zustand, der Unterzustände enthält, die in einem untergeordneten Zustandsdiagramm verfeinert sind. Im Zustandssymbol wird der Zustandsnamen angegeben und mit Doppelpunkt getrennt der Zustandsautomat, der ihn verfeinert. 3.3.10.3 Anwendungsbereich Zustandsdiagramme werden häufig im Bereich Embedded Systems eingesetzt, sind aber auch in anderen Bereichen verwendbar. Sie werden nur für Klassen mit nicht trivialemem (interessantem) Lebenszyklus modelliert. Ein trivialer Lebenszyklus ist dann vorhanden, wenn ein Zustandsdiagramm nicht zum besseren Verständnis des Verhaltens des Objektes beiträgt. Nicht triviale Lebenszykeln von Objekten liegen dann vor, wenn die Objekte "viele" Zustände haben und in den einzelnen Zuständen nur auf eine bestimmte Art und Weise auf eingehende Nachrichten reagieren können. 3.3.10.4 Zusammenhang Ein Zustandsdiagramm kann sich auf eine Klasse des Klassendiagramms beziehen. Es kann aber auch die Zustände von komplexeren Modellelementen (Subsystemen) darstellen. Die Nachrichten auf die eine Klasse mit einem Zustandsübergang reagiert, werden von anderen Klassen oder Akteuren gesendet. 3.3.10.5 Hinweis für die Praxis Zustandsautomaten sollten nur bei komplexen Objekten verwendet werden. Ein Objekt ist dann komplex, wenn es viele Methoden oder viele Attribute hat. Bei einfach strukturierten Objekten bringt der Einsatz von Zustandsautomaten keine 89 zusätzlichen Erkenntnisse. Jeder Zustand und Pseudozustand, außer dem Anfangsund Endzustand, sollte mindestens einen ein- und eine ausfließende Transition haben. Style Guide Zustandsdiagramme sollten so gestaltet werden, dass sie von links oben nach rechts unten lesbar sind. Zustand sollte aus- und einfliessende Pfeile haben, jeder Zustand muß erreichbar sein und wieder verlassen werden können. Neu in UML 2. Der Name State Machine Diagram ist in der UML 2.0 neu. In früheren Versionen der UML wurden dieser Diagrammtyp Zustandsübergangsdiagramme, State Diagram oder State Transition Diagram genannt. Diese Bezeichnungen werden heute immer noch verwendet. 3.3.10.6 Beispiel Der Mensaautomat hat die Zustände bereit, KarteCheck, GeldFordernd, GeldEinzug und LadeKarte. Nach dem Aktivieren befindet er sich in dem Zustand bereit. Diesen Zustand verläßt er, wenn das externe Ereignis KarteEin auf ihn einwirkt. Er führt die Transition zu dem Zustand KarteCheck durch. In diesem Zustand liest er über die Aktivität lies die Mensakarte. Ist die Karte in Ordnung (Bedingung Karte = OK), führt er die Aktivität zeige aus und zeigt den Betrag an. Er wechselt den Zustand zu GeldFordernd. Trifft die Bedingung Karte = !OK zu, führt er die Aktivität KarteRaus aus und geht zurück in den Zustand bereit. Das externe Ereignis druecken() (des Rückgabeknopfes) veranlaßt den Automat zur Zustandsänderung von GeldFordernd zu bereit; er gibt die Karte zurück. In dem Zustand GeldFordernd reagiert der Mensaautomat außerdem noch auf das Ereignis GeldEin; es führt zu der Transition zu GeldEinzug. Dort wird zuerst die entryAktivität pruefeSchein ausgeführt, danach zeigt die Aktivität zeige den aktuellen Geldbetrag an. Das Ereignis GeldEin führt zu einer rekursiven Transition; der Kunde kann mehrere Geldscheine einschieben. Das Ereignis druecken führt zu der Transition zu LadeKarte, die Aktivität schreibe schreibt den aktuellen Geldbetrag auf die Karte. Die Karte wird herausgeschoben und der Automat wechselt in den Zustand bereit. 90 3.3.11 Aktivitätsdiagramm - Activity Diagram 3.3.11.1 Zweck Aktivitätsdiagramme sind Diagramme zur Flussmodellierung. Sie stellen die Aktivitäten eines Systems dar, die Aktionen, aus den die Aktivitäten sich zusammensetzen und den Fluss durch die Aktivitäten. Mit Aktivitätsdiagrammen können komplexe Abläufe in einem System modelliert werden (Geschäftsprozesse, Workflows). Da Aktivitäten aus Aktionen und deren zeitlicher Verknüpfung bestehen, können sie auch zur Modellierung der internen Logik komplexer Operationen verwendet werden und somit Algorithmen visualisieren. 91 Aktivitätsdiagramme können in Verantwortungsbereiche gegliedert werden. Damit können die Aktionen bestimmten Modellelementen, wie Klassen oder Komponenten zugeordnet werden. 3.3.11.2 Notation Symbol 92 Beschreibung Aktivität (Activity) Eine Aktivität besteht aus Knoten (Aktivitäten, Aktionen, Kontroll- und Objektknoten) und Kanten (Pfeilen), die den Kontrollfluss durch die Aktivität darstellen. Die Aktivität wird als abgerundetes Rechteck dargestellt. In der linken, oberen Ecke steht der Name der Aktivität, gefolgt vom Eingangsparameter und Typ. Die Rechtecke an beiden Seiten geben die Eingangs- bzw. Ausgangsparameter an. Die Symbole in der Aktivität stellen die Aktionen dar und die Pfeile den Kontrollfluss. Aktion (Action) Eine Aktion ist in UML das Basiselement zur Spezifikation von Verhalten. Eine Aktion kann als nicht weiter zerlegbare Funktion angesehen werden. Sie transformiert eine Eingabe zu einer Ausgabe. Aktionen sind in Aktivitäten enthalten. Die UML 2.0 unterscheidet verschiedene Typen von Aktionen. Signal (Send signal action, Accept event action) Mit diesen Symbolen kann das Senden und Empfangen von Signalen dargestellt werden. Zeitereignis (Accept time event action) Über diese Symbol wird ausgedrückt, dass eine Aktion zeitgesteuert angestoßen wird. Kontrollknoten werden benutzt um Kontrollstrukturen in einem Flussgraph anzugeben. Symbol Beschreibung Entscheidung und Zusammenführung Bei der Entscheidung wird nach Eintreffen des Tokens a entweder nach b oder nach c verzweigt. Die Bedingung, die erfüllt sein muss, kann als Ausdruck in eckigen Klammern an den Pfeilen angegeben werden. Bei der Zusammenführung wird nach Eintreffen der Token a oder b nach c verzweigt. Splitting, Synchronisation Bei einem Splitting-Knoten wird in mehrere parallele Threads verzweigt (wenn a da ist, feuern b und c). Ein Synchronisationsknoten synchronisiert mehrere Threads (wenn a und b da sind, feuert c). Start-, Endknoten, Ablaufende Ein Startknoten (Initial Node) stellt den Beginn eines Ablaufes dar. Ein Endknoten (Activity Final Node) beendet eine Aktivität vollständig. Ein Ablaufende (Flow Final Node) terminiert einen Zweig einer Aktivität, die Aktivität selbst läuft weiter. Pfeil/Kante Ein Pfeil beschreibt den Fluss zwischen den verbundenen Elementen. In einer eckigen Klammer kann eine Bedingung angegeben werden, die erfüllt sein muss, damit die Kante überquert wird. Objektknoten können in Aktivitätsdiagrammen Objekte oder Daten repräsentieren. Sie können als unabhängige Knoten in einem Diagramm benutzt werden, bzw. als Parameter für Aktionen (Input, Output Pin). Beide Darstellungen sind äquivalent. Im Bild oben ist a als Objekt eingezeichnet; im unteren Bild ist a Ausgangsparameter der linken Aktion und Eingangsparameter der rechten. 93 Symbol Beschreibung Kanten verbinden die Aktionen in einem Diagramm und stellen den Fluss dar. Kanten, die Kontrollfluss modellieren, verbinden Aktionen direkt; Objektflusskanten verbinden die Pins der beteiligten Aktionen. Tabelle 8Notation Aktivitätsdiagramm Prinzip der Aktivitätsdiagramme Aktivitätsdiagramme zeigen den Ablauf von Aktivitäten. Sie definieren die Aktionen, aus den sich Aktivitäten zusammensetzen und die zeitliche Reihenfolge ihrer Ausführung. Verzweigungen des Kontrollflusses und gleichzeitig ablaufende, parallele Zweige sind möglich. Um die ausgeführten Aktionen verfolgen zu können, werden die Zweige eines Aktivitätsdiagramms mit Tokens belegt. Ein Token ist eine Marke, die den Kontrollfluss markiert. In jedem Thread existiert ein Token. Tokens besitzen kein Symbol in der UML. Sie sind virtuelle Elemente, die den Kontrollfluss markieren. Abbildung 3.3.11.2.1Beispiel Token in Aktivitätsdiagrammen In Abbildung 3.3.11.2.1 ist das Prinzip des Token-Modells dargestellt. Nachdem der Ablauf gestartet wurde, wird das erste Token, links im Bild, erzeugt. Danach wird die Aktion a1 ausgeführt und das Token auf den Ausgang von a1 gelegt. Durch die Verzweigung in die beiden Threads p1 und p2 wird am Anfang beider Threads je ein Token gesetzt. Die Aktionen p1 und p2 werden ausgeführt; die Tokens werden auf die Ausgänge von p1 und p2 gelegt. Wenn beide Tokens da sind, wird das Eingangstoken für a2 gestartet. A2 wird ausgeführt, das Token auf den Ausgang von a2 gelegt, die Aktivität wird beendet und das Token vernichtet. Aktionstypen Die UML 2.0 definiert verschiedene Typen von Aktionen, die für bestimmte Zwecke verwendet werden können, z. B. Aktionen zum • 94 Erzeugen, Löschen von Objekten • • • • Lesen und Schreiben von Attributwerten Aufrufen von Operationen Empfangen und Senden von Signalen u. a. Verantwortungsbereiche (Partitions) Aktivitäten können komplexe Abläufe darstellen, die durch unterschiedliche Modellelemente ausgeführt werden, bzw. für die unterschiedliche Elemente verantwortlich sind. Zur Zuordnung der Aktionen einer Aktivität zu den verantwortlichen Elementen können Aktivitätsdiagramme in Partitionen (Activity Partition) unterteilt werden. Da ein entsprechend aufgeteiltes Diagramm wie eine in Schwimmbahnen eingeteiltes Schwimmbecken aussieht, werden die Activity Partitions auch swimlanes genannt. Abbildung 3.3.11.2.2Verantwortungsbereiche in Aktivitätsdiagrammen In Abbildung 3.3.6.2.2 ist das Aktivitätsdiagramm in die Bereiche Partition 1 und Partition 2 unterteilt. Die Aktionen a1 und a3 gehören zu der Partition 1; die Aktion 2 gehört zu der Partition 2. Partitionen können senkrecht und waagrecht angelegt werden. Verfeinern von Aktivitäten 95 Abbildung 3.3.11.2.3Verfeinern von Aktivitäten Aktivitäten können in weiteren Aktivitätsdiagrammen verfeinert werden. Das zu verfeinernde Element wird mit einem Gabelsymbol gekennzeichnet und kann in einem Unterdiagramm verfeinert werden. So können Hierarchien von Aktivitätsdiagrammen modelliert werden. Alle Aktivitäten sind auf der untersten Hierarchieebene auf Aktionen abzubilden. 3.3.11.3 Anwendungsbereich Aktivitätsdiagramme werden zur Modellierung von Abläufen und deren Steuerung benutzt. In Aktivitätsdiagrammen werden die einzelnen Verfahrensschritte von Aktivitäten und die Reihenfolge in der sie ausgeführt werden dargestellt. Sie können von der Modellierung von Geschäftsprozessen bis zur Visualisierung von Kontrollflüssen benutzt werden. Eine Aktivität setzt sich aus den Aktionen zusammen, die im Aktivitätsdiagramm enthalten sind. Aktivitätsdiagramme können in einem Projekt überall verwendet werden, wo Verhalten beschrieben werden muss, bzw. wo Datenflüsse oder Kontrollflüsse modelliert werden sollen. 3.3.11.4 Zusammenhang Da Aktivitätsdiagramme sehr vielfältig einsetzbar sind, können vielfältige Beziehungen zwischen Aktivitätsdiagrammen und anderen Diagrammen der UML bestehen. 96 Aktivitätsdiagramme können die Abläufe von Anwendungsfällen aus Use Case Modellen beschreiben. Sie können verwendet werden, um z. B. den Ablauf eines Geschäftsprozesses, der einem Use Case zugeordnet ist, zu modellieren. Es ist aber auch möglich, dass mehrere Aktivitätsdiagramme den Ablauf eines Use Cases modellieren; in einem Aktivitätsdiagramm könnte das Normalverhalten eines Use Case modelliert werden in einem weiteren könnte eine Alternative zum Normalverhalten beschrieben werden. Da die Darstellung der Kontrollstrukturen höherer Programmiersprachen in der Notation der Aktivitätsdiagramme enthalten ist, können sie auch zur Spezifikation von Algorithmen verwendet werden. Aktivitätsdiagramme müssen mit den anderen Diagrammen in einem Projekt konsistent gehalten werden. Aktionen können Operationen bei den Klassen eines Modells erfordern. 3.3.11.5 Hinweise für die Praxis Style Guide • • • • • • Diagramme sollten übersichtlich angeordnet werden. Kannten zwischen den Knoten sollten möglichst kreuzungsfrei sein. Besonders wenn Aktivitätsdiagramme mit Verantwortungsbereichen gezeichnet werden, entstehen große Diagramme. Zur Integration der Diagramme in einer Projektdokumentation sollte das Ausgabeformat (DIN A 4) berücksichtigt werden. Es kann sinnvoll sein große Diagramme über mehrere Seiten zu zerlegen und diese über Konnektoren miteinander zu verbinden. Bei Entscheidungsknoten sollten die Bedingungen in der Nähe des Konnektors angegeben werden. Entscheidungsknoten sollten einen Bezug zur Aktion haben, der sie nachfolgen. Start- und Endknoten sollten angegeben werden, um unmissverständlich Beginn und Ende einer Aktivität zu dokumentieren. Die Pfeilspitzen sollten so angeordnet werden, dass Diagramme von oben nach unten und von links nach rechts lesbar sind. Neu in UML 2.0 Die Aktivitätsdiagramme in UML 2.0 erfuhren die größten Veränderungen gegenüber der UML 1.x. In der UML 1.x waren die Aktivitätsdiagramme eine spezielle Form der Zustandsdiagramme. In der UML 2.0 sind die Aktivitätsdiagramme eigenständig. Einige Begriffe der UML 1.x wurden weiterverwendet, bekamen aber eine vollständig neue Bedeutung. Ein Aktivitätsdiagramm in UML 2.0 beschreibt eine Ak- 97 tivität, die Teilschritte werden Aktionen genannt. In der UML 1.x wurden die Teilschritte eines Aktivitätsdiagramms Aktivitäten genannt; die Aktivitäten der UML 1.x heißen jetzt Aktionen, das Aktivitätsdiagramm von UML 1.x heißt jetzt Aktivität. Aktivitätsmodelle haben jetzt eine starke Ähnlichkeit zu Petrinetzen. Ein Aktivitätsdiagramm darf mehrere Anfangszustände haben. Signale, Zeitereignis und das Ablaufende wurden als neue Notationselemente eingeführt. Zur Darstellung von Objektflüssen können die "fließenden" Objekte als Objektknoten angegeben werden. Aktivitätsdiagramme dürfen Ein- und Ausgabeparameter enthalten. 3.3.11.6 Beispiel Bei der Modellierung des Beispiels wurden folgende Annahmen getroffen: Die Diagramme modellieren jeweils einen Geschäftsprozess zu einem Use Case. Zur Darstellung der externen Ereignisse, die auf die Aktivitäten einwirken, sind die Akteure, die diese auslösen in den Diagrammen enthalten. Sie sind mit einer gerichteten Kante mit der Aktion, auf die sie zugreifen, verbunden. Die Diagramme zeigen den Kontrollfluss, keinen Daten- oder Objektfluss. Aktivitätsdiagramm EssenZahlen 98 Abbildung 3.3.11.6.1Beispiel Aktivitätsdiagramm Essen zahlen Hier wurden Verantwortungsbereiche angegeben. Das Diagramm hat zwei Startpunkte, da die Aktionen "Essen eintippen" und "Karte einschieben" parallel erfolgen können. Die beiden Zweige werden auf dm folgenden Synchronisationsknoten miteinander synchronisiert. Aktivitätsdiagramm KarteLaden Das Diagramm in Abbildung 3.3.6.6.2 wurde ohne Verantwortungbereiche modelliert. 99 Abbildung 3.3.11.6.2Beispiel Aktivitätsdiagramm Karte laden 3.3.12 Verteilungsdiagramm - Deployment-Diagram 3.3.12.1 Zweck 100 Das Verteilungsdiagramm stellt die physikalische Struktur eines Systems dar. Es gibt die Zuordnung von Softwarekomponenten zu den ausführenden Hardwareeinheiten (Knoten) zur Laufzeit an und beschreibt die Kommunikation zwischen den Knoten über Kommunikationspfade. 3.3.12.2 Notation Symbol Beschreibung Knoten (Node) Ein Knoten ist eine Ressource auf der Artefakte bereitgestellt und ausgeführt werden. Es kann z. B. ein Server sein. Knoten können geschachtelt sein. Es werden die Knotentypen Gerät (device) und Ausführungsumgebung (execution environment) unterschieden. Artefakt (Artifact) Ein Artefakt ist das Ergebnis oder Produkt einer Entwicklertätigkeit. Ein Artefakt kann z. B. sein: ein Modellelement, eine Softwarekomponente, eine Quellcodedatei, eine Binärdatei, eine DB-Tabelle, usw. Kommunikationspfad (communication path) Ein Kommunikationspfad ist eine Assoziationsbeziehung zwischen Knoten. Über Kommunikationspfade können Knoten Nachrichten austauschen. Kommunikationspfade werden als Linien zwischen Knoten dargestellt und können bezeichnet werden. Kommunikationspfade können ungerichtet oder gerichtet sein. Gerichtete Beziehungen werden mit einem Pfeil angegeben. 3.3.12.3 Beispiel Das Beispiel zeigt die Hardwarestruktur des Beispiels Mensaautomat. Es besteht aus den Geräten Mensaautomat, Kasse und dem Mensaserver. Den Geräten sind die Softwarekomponenten zugeordnet, die darauf installiert sind. 101 3.3.13 Kompositionsstrukturdiagramm - Composite Structure Diagram 3.3.13.1 Zweck Das Kompositionsstrukturdiagramm beschreibt die interne Struktur eines Classifiers und seine Interaktionsbeziehungen zu anderen Systemteilen. Es zeigt wie die Teile eines Classifiers den Classifier selbst bilden. Da es mit dem Kompositionsstrukturdiagramm möglich ist die Teile (Architekturelemente) eines Systems und ihre Beziehungen darzustellen, wird es auch Architekturdiagramm genannt. Das Kompositionsstrukturdiagramm eignet sich ebenfalls zur Modellierung von Entwurfsmustern. 3.3.13.2 Notation Symbol Beschreibung Teil (Part) Ein Part ist eine Laufzeitinstanz einer Klasse oder Schnittstelle. Parts werden verwendet um Kompositionsstrukturen oder Entwurfsmuster darzustellen. Parts können Eigenschaften von Klassen sein, d. h. sie können in der Klasse enthalten sein. 102 Symbol Beschreibung Kollaboration (Collaboration) Eine Kollaboration beschreibt die Struktur von zusammenarbeitenden Elementen, die gemeinsam das Gesamtverhalten der Kollaboration beschreiben. Die Kollaboration wird mit einem Namen bezeichnet. Die enthaltenen Elemente können in der Kollaboration angegeben werden, oder in einem weiteren Kompositionsstrukturdiagramm modelliert werden. Die Linie, die Part1 und Part2 verbindet ist ein Konnektor. Konnektoren werden verwendet um Kommunikationsbeziehungen zwischen Instanzen darzustellen. 3.3.13.3 Anwendungsbereich Kompositionsstrukturdiagramme können in frühen Projektphasen zur Modellierung von Systemteilen und deren Zusammenhängen eingesetzt werden. Sie können noch relativ abstrakte Modellelemente enthalten, ohne bis zur Detaillierungsebene von Klassendiagrammen ausmodelliert zu werden. Die verwendeten Strukturelemente können schrittweise verfeinert werden. 3.3.13.4 Neu in UML 2. Kompositionsstrukturdiagramme sind neu in der UML 2.0. 3.4 Object Constraint Language UML-Diagramme, wie z. B. Klassendiagramme drücken meistens nicht alle Aspekte eines Softwaresystems aus. Zusätzliche Bedingungen werden in natürlicher Sprache formuliert. Sie sind häufig nicht eindeutig und enthalten Widersprüche. Um diese Fehlerquellen zu beseitigen, wurde die Object Constraint Language definiert. Die OCL ist eine formale Sprache zur Beschreibung von 103 Constraints (Bedingungen, Einschränkungen) in UML-Modellen. Ein Constraint ist eine Bedingung oder Einschränkung, die für Modellelemente definiert wird. Die Constraints können z. B. zur Beschreibung folgender Eigenschaften verwendet werden: • • • • • • Definition von Zusicherungen über Zusammenhänge zwischen Modellelementen, bzw. Einschränkungen, Definition von Vor- und Nachbedingungen, Voraussetzungen für die Ausführung von Operationen, Zusicherungen von Ergebnissen, die Operationen liefern, Invarianten, Navigation in Uml-Modellen (query-language). Ein Beispiel zu einem Constraint findet sich in dem Kapitel 3.3 Diagramme der UML auf Seite 39. 3.5 Model Driven Architecture 3.5.1 Was ist MDA? Die Model Driven Architecture ist ein offener, herstellerunabhängiger Standard zur Modellierung von Werkzeug-unabhängigen Anwendungen. Er verfolgt das Ziel Modelle unabhängig von der aktuellen Implementierungstechnologie zu beschreiben und sie somit als Basis der Weiterentwicklung von Systemen zu nutzen, unabhängig von der sich schnell weiterentwickelnden Implementierungstechnologie. MDA trennt die Geschäftslogik von der Implementierungstechnologie und definiert dafür zwei Modelle: • PIM- Platform-Independent Model • PSM-Platform-Specific Model. 3.5.2 Motivation Software lebt; sie lebt in manchen Geschäftsbereichen sehr lange. In dem Bankbereich sind Anwendungen im Einsatz, die in so antiken 104 Programmiersprachen wie Cobol oder PLI geschrieben wurden. Die Implementierungstechnologie ist vielfältig und entwickelt sich sehr schnell weiter. Daraus ergibt sich eine Diskrepanz zwischen der Lebenszeit der fachlichen Modellen, die der Software zugrundeliegen und der aktuellen Implementierungstechnologie. Modelle können nicht oder nur schwer an neue Implementierungstechnologie angepaßt werden, obwohl die fachlichen Modelle weiterhin gültig sind. Diese Probleme motivierten die OMG zur Definition der MDA. Das Ziel der MDA ist die Verbesserung der Wiederverwendbarkeit von Modellen. Dies soll durch die Trennung von dem fachlichen Modell und der Implementierungsplattform erreicht werden. Firmen soll die Investition in langlebige Modelle, statt in Code ermöglicht werden. 3.5.3 Wie funktioniert MDA? Das Prinzip der MDA ist die Plattformunabhängigkeit von Software-Modellen. Das Plattformunabhängige Modell wird in der MDA PIM, Platform Independent Model genannt. Alle fachlichen und funktionalen Aspekte der Software werden im PIM beschrieben. Die Beschreibung erfolgt mit Standards, wie UML, OCL und XMI. Das PIM wird über ein Standardmapping auf ein oder mehrere PSM, Platform Specific Model abgebildet. Hier wird das Softwaremodell auf ein Zielsystem, wie Corba, EJB transformiert. Dieser Schritt erfolgt automatisch über das MDA-Tool. Generiert werden alle für die Zielplattform benötigten Elemente, wie z. B.: • Platform Interfaces, • fachlicher Code, • deployment descriptor, 105 DB-Schema. Das PSM beschreibt die Anwendung mit den Mitteln der Implementierungstechnologie. Aus dem PSM wird der Plattformspezifische Code generiert. • 3.6 UML Profile UML-Profile sind ein Erweiterungsmechanismus der UML. Sie werden verwendet, um die Regeln des UML-Metamodells zu erweitern oder einzuschränken. Dafür stehen in der UML folgende Konstrukte zur Verfügung: • Stereotypen, • Tagged values (Eigenschaftswerte), • in OCL formulierte constraints. Eine konkrete Anpassung der UML an eigene, bestimmte Zwecke (mit Hilfe der o. g. Konstrukte) wird Profile genannt. Über Profile können also Modelle vorkonfiguriert werden; die Regeln der UML können an eigene Zwecke angepaßt werden. Die OMG liefert viele vordefinierte Profile, wie z. B.: • UML Profile for Corba • UML Profile for Enterprise Application Integration (EAI) • UML Testing Profile 106 4 Vorgehens- und Prozessmodelle 4.1 Überblick (Motivation, Begriffe) Oft steht der Projektleiter am Anfang eines Softwareentwicklungsprojektes vor der zentralen Frage, welches Vorgehen das Beste für sein Projekt ist. In der Vorlesung Softwaretechnik wird vorrangig die objektorientierte Vorgehensweise dargestellt. Dies hat Auswirkungen auf das Projektmanagement. Einige wichtige Aspekte werden im Abschnitt 4.2 erläutert. In den nachfolgenden Abschnitten werden verschiedene Vorgehens- und Prozessmodelle vorgestellt, die in heutigen Entwicklungsprojekten eine wesentliche Rolle spielen. Im Abschnitt 4.3 werden das Wasserfallmodell sowie die evolutionären und inkrementellen Ansätze dargestellt und deren Vor- und Nachteile genannt. Viele Projekte basieren nach wie vor auf einem Wasserfallmodell trotz der Einsicht, dass bei Wasserfallmodelle Risiken oft zu einem (zu) späten Zeitpunkt erkannt und Anforderungen schlecht in einer späten Phase berücksichtigt werden können. Um Risiken möglichst früh bewerten und evtl. ausschließen zu können, ist die Entwicklung eines Prototyps ein mögliches Mittel. Im Abschnitt 4.4 werden die verschiedenen Klassifizierungsmerkmale von Prototypen herausgearbeitet und der generelle Aufbau von Prototypen dargestellt. Sogenannte schwergewichtige Prozessmodelle versuchen, ein möglichst vollständiges Rahmenwerk der Softwareentwicklung für die verschiedenen Projekttypen bereitzustellen. Im Kapitel 4.5 wird das V-Modell vorgestellt, das sowohl bei Behörden als auch in der Industrie eingesetzt wird. Ein anderes schwergewichtiges Modell ist der RUP (Rational Unified Process). Der RUP (s. Abschnitt 4.6) beschreibt ein Vorgehensmodell auf Basis von sog. "Best Practices", die erwiesenermaßen bei erfolgreichen Projekten zum Einsatz kommen. Diese umfassen im Einzelnen die iterative Entwicklung von Software, das Management von Anforderungen, die Nutzung komponentenbasierter Architekturen, die visuelle Modellierung der Software, die Verifikation der Software-Qualität und der Etablierung eines Änderungsmanagements. Im Abschnitt 4.7 wird ein agiles (leichtgewichtiges) Vorgehensmodell beschrieben, das die Programmentwicklung bzw. das Codieren in den Kern der Betrachtungen rückt. Dieses Modell wird XP (eXtreme Programming) genannt und kann in kleinere Projekten eingesetzt werden. Ziel eines jeden Projektes sollte die Entwicklung eines qualitativ hochwertigen Softwareproduktes sein. Der letzte Abschnitt in diesem Kapitel ist daher dem Thema "prozessorientiertes Software-Qualitätsmanagement" gewidmet. Eine zentrale Erkenntnis ist hierbei, dass die Produktqualität von der Prozessqualität bestimmt wird. Seit den 80er Jahren werden an verschiedenen Stellen an der Entwicklung von Standardmodellen für gute Software-Entwicklungsprozesse 107 gearbeitet. Die wichtigsten Standards (ISO 9000-Standards, insbesondere ISO 9000-3 für die Software –Entwicklung, ISO 12207, ISO 15504 (SPICE- Standard) und CMM/CMMI) werden im Abschnitt 4.8 ausführlich beschrieben. 4.2 Das objektorientierte Projekt Die Leitung eines Projektes ist grundsätzlich eine schwierige Aufgabe. Dies resultiert letztlich auf der Kollision zwischen Wünschen, festgelegten Terminen und vorhandenem Budget. Die objektorientierte Softwareentwicklung kann zusätzliche Risiken hervorbringen und erfordert daher zusätzliche Anstrengungen im Bezug auf das Projektmanagement. Im Folgenden werden wesentliche Aspekte kurz benannt. Der Einstieg in die Objektorientierung ist eine große Umstellung in allen Belangen eines Projektes (z. B. in Bezug auf erforderliches Know-How, Projektorganisation und Steuerung). Oft fehlt es an erfahrenen Projektmitarbeitern, die bereits Probleme in früheren Projekten gelöst haben und so durch Ihr Know-How Fehlentwicklungen entgegensteuern können. Der Einsatz von objektorientierter Technologie ist alleine keine Gewähr dafür, dass eine Software den Ansprüchen des Kunden genügt. Es gibt durchaus Szenarien, in denen der Einsatz von Objekttechnologie eindeutig Nachteile mit sich bringt (z. B. Performance-Verlust bei Batch-Verarbeitung auf dem Mainframe oder bei Anwendungen im Bereich "Parallel Computing"). Objektorientierte Entwicklung erfordert den Einsatz von modernen Programmiersprachen und Entwicklungswerkzeugen. Die Menge an neuen Verfahren/Methoden und Regeln verursachen in der Regel neue Risiken, die intensiver verfolgt werden müssen und ein ausgereiftes Risikomanagement erfordern. Zum Teil müssen auch vorhandene Werkzeuge und Verfahren, die seit vielen Jahren erfolgreich in einem Unternehmen eingesetzt werden, an die neuen Entwicklungsprozesse angepasst werden. Iterative und inkrementelle Entwicklung bei objektorientierten Projekten erfordert ein kompetentes Projektmanagement (z. B. Aufwandsschätzung, RessourcenPlanung, Meilensteinplanung, "politische Aspekte"). Projektleiter stehen daher oft zwischen den Stühlen. Der Lenkungsausschuss fordert einsatzbereite Software mit eingeschränktem Budget in vorgegebener Zeit und die Projektmitglieder benötigen ein gutes Umfeld sowie eine ausgereifte Entwicklungsplattform, um die gesteckten Ziele zu erreichen. Objektorientierte Projekte sind oft teurer als vergleichsweise prozedural entwickelte Anwendungen. Dies liegt insbesondere an dem notwendigen Einsatz von vergleichsweise teuren Werkzeugen und Berater, benötigter Schulung für die Entwickler und Komplexität des neuen Programmiermodells (z. B. Abstraktion, Wiederverwendbarkeit, Kapselung, Vererbung). In der Objektorientierung gibt es viele Ansätze ein Problem zu lösen 108 und viele Ansätze eine Problemlösung zu formulieren. Dagegen gibt es je nach Anwendungsszenario noch nicht genügend publizierte Standardlösungen. Daher muß zusätzliche Zeit aufgewendet werden, um evtl. Eigenentwicklungen vorzunehmen oder eigene Tools für die Werkzeugintegration zu entwickeln. Der Erfolg von objektorientierten Projekten hängt im besonderen Maße auch von der Projektkultur ab (z. B. Offenheit, Kommunikationsformen, Führungsstil). Projektleiter, die kein offenes Ohr für Entwickler haben, verlieren schnell den Bezug zur Realität und den aktuellen Problemen. Vorgehensmodelle, die in den nachfolgenden Abschnitten beschrieben werden, geben Orientierungshilfe für alle Projektmitarbeiter aber auch viele Freiheitsgrade. Wie in traditionellen Projekten auch sind viele Einzelentscheidungen zu treffen. Patentrezepte gibt es nicht! Trotz der genannten Probleme stellt die objektorientierte Softwareentwicklung eine wichtige Säule bei heutigen Projekten dar und wird in den nächsten Jahren weiter an Bedeutung gewinnen. 4.3 Wasserfallmodell, Evolutionäres Modell, Iteratives Modell Wasserfallmodell Im Wasserfallmodell wird Software von der ersten Idee zur Erstellung eines Softwaresystems bis zur Einführung und Wartung des Systems in sukzessiven Stufen entwickelt. In der Urform waren keine Rücksprünge möglich, man hat jedoch schnell bemerkt, dass diese strenge Vorgehensweise nicht durchgehalten werden kann. Bei der Entwicklung kann in einer Phase festgestellt werden, dass einige Vorgaben der vorhergehenden Phase gar nicht oder nicht im vertretbaren Zeit- und Kostenrahmen durchführbar sind. In diesem Fall müssen Rücksprünge in zeitlich früher liegende Phasen möglich sein. Als Beispiel sei hier ein Phasenmodell von Frick [Frick95] verwendet. Die Rechtecke stellen die Phase dar, die Pfeile den Informations- und Kontrollfluss zwischen den Phasen. Die Phasen werden sequentiell durchlaufen. Am Ende jeder Phase werden die Ergebnisse überprüft und an die Folgephase weitergegeben. Wird dort während der Erarbeitung der eigenen Phasenergebnisse, ein Fehler in den Vorgaben festgestellt, so werden die Vorgaben an die vorhergehende Phase zurückgeführt. Die nach oben gerichteten Pfeile der linken Seite beschreiben Rücksprünge während der Entwicklung, die Pfeile der rechten Seite kennzeichnen Rücksprünge, die während der Wartung (Fehlerkorrektur) notwendig werden können. Auf die Inhalte der einzelnen Phasen wurde schon in Kapitel 1 eingegangen. Auf eine nochmalige Beschreibung wird hier verzichtet. 109 Nachteile des Wasserfallmodells: 1 Bei großen Systemen ist die Entwicklungszeit zu lang. d. h. nach Fertigstellung des Systems ist es schon veraltet. 2 Es ist nicht sinnvoll alle Entwicklungsschritte streng sequentiell durchzuführen. (Z. B. kann es sinnvoll sein, ein Teil der Bedieneroberfläche schon bei der Definition des Systems zu Demonstrationszwecken oder spezielle technische Lösungen schon beim Entwurf des Systems zu realisieren.) 3 Risikofaktoren werden u. U. zu wenig berücksichtigt, da immer der einmal festgelegte Entwicklungsablauf durchgeführt wird Analyse Definition Entwurf Änderungen während der Entwicklung Änderungen / Fehlerkorrektur während der Wartung Implementierung und Test Abnahme Betrieb und Evaluation Abbildung 4.3.1 Wasserfallmodell Trotzdem ist das Wasserfallmodell insbesondere für kleinere Projekte evtl. unter Einbeziehung von Prototyping-Ansätzen und einer nicht so strengen Sichtweise, was den streng sequentiellen Ablauf angeht, auch heute noch durchaus anwendbar. 110 Für große Systeme ist insbesondere der Nachteil der langen Entwicklungszeit so gravierend, dass besser eines der im Folgenden beschriebenen Prozessmodelle mit mehreren zyklischen Durchläufen ausgewählt werden sollte. Evolutionäres und inkrementelles Modell Ziel heutiger Softwareentwicklungen ist es, dem Auftraggeber möglichst jedes halbe Jahr ein lauffähiges Teilprodukt zur Verfügung zu stellen. Beim evolutionären und inkrementellen Modell erstellt man das gesamte System deshalb nicht wie beim Wasserfallmodell in einem Durchlauf, sondern in mehreren Durchläufen, wobei am Ende jedes Durchlaufs ein einsatzfähiger Teil des System fertig gestellt, in Betrieb genommen und evaluiert wird. Unter Einbeziehung der Ergebnisse der Evaluation wird dann der nächste Durchlauf gestartet. Das evolutionäre Modell Die Kernanforderungen oder Mussanforderungen des Auftraggebers definieren den Produktkern. Im ersten Durchlauf wird der gesamte Software-Entwickungszyklus für diesen Produktkern durchgeführt. Das entwickelte Kernsystem wird anschließend an den Auftraggeber ausgeliefert. Der Aufraggeber sammelt Erfahrungen mit dieser Nullversion. Diese Erfahrungen fließen dann in die verbesserte und erweiterte nächste Version ein, d. h. sowohl Pflegeaktivitäten bezüglich des schon fertiggestellten Teil des Systems als auch die für die nächste Version gewünschten Erweiterungen erfolgen im nächsten Zyklus. Vorteile des evolutionären Modells: • Benutzer stehen in kurzen Zeitabständen jeweils einsatzfähige Teile des Gesamtsystems zur Verfügung. immer größere 111 1 Analyse des Teilsystems zum nächsten Zyklus Definition des Teilsystems Entwurf des Teilsystems Änderungen Implementierung und Test des Teilsystems Abnahme des Teilsystems Betrieb und Evaluation des Teilsystems Abbildung 4.3.2 Evolutionäres Modell 1 Die mit einer Version gewonnenen Erfahrungen fließen sofort in die nächste Version ein (sowohl Verbesserungen / Anpassungen an den Stand der Technik / Veränderungen des Ablaufs bezüglich des schon bestehenden Teils als auch für die Konzeption der ergänzenden Teile). 2 Geeignet, wenn der Auftraggeber seine Anforderungen noch nicht genau überblickt. Nachteile des evolutionären Modells: 112 Gefahr, dass der schon realisierte Teil des Systems völlig umgeschrieben werden muss, weil die in spätern Entwicklungszyklen gefundenen Anforderungen nicht mehr einfach Systemerweiterungen sondern Systemveränderungen verursachen. Inkrementelles Modell Der oben beschriebene Nachteil wird durch das inkrementelle Modell vermieden. In diesem Modell wird die Analyse und Definition für das Gesamtsystem erstellt. In der Phase Definition wird dabei auch die Planung der Zyklen durchgeführt. In den folgenden Phasen werden dann wie beim evolutionären Modell jeweils immer umfangreicher werdende Teilsysteme erstellt, allerdings müssen nur die Phasen Entwurf bis Betrieb und Evaluation durchlaufen werden, da die Analyse und die Definition des Gesamtsystems ja schon vor dem ersten Durchlauf durchgeführt wurden. Vorteile des Inkrementellen Modells: 5. Die Vorteile des evolutionären Modells, dass dem Benutzer in kurzen Zeitabständen jeweils immer größere einsatzfähige Teile des Gesamtsystems zur Verfügung stehen und dass die mit einer Version gewonnenen Erfahrungen sofort in die nächste Version einfließen können, sind hier auch gegeben. Der Nachteil, dass beim Erstellen der Teilsysteme die Anforderungen an das Gesamtsystem nicht berücksichtigt werden konnten, da sie noch nicht aufgenommen waren, entfällt. Nachteil des Inkrementellen Modells: • Da die ersten beiden Phasen für das Gesamtsystem durchgeführt werden, dauert es länger bis die erste Version fertig gestellt werden kann. 113 Analyse des Gesamtsystems Anpassungen auf Grund von Erfahrungen mit dem Teilsystem Definition des Gesamtsystems inkl. Zyklenplanung zum nächsten Zyklus Entwurf des Teilsystems Änderungen Implementierung und Test des Teilsystems Abnahme des Teilsystems Betrieb und Evaluation des Teilsystems Abbildung 4.3.3 Inkrementelles Modell Um den oben aufgeführten Nachteil abzuschwächen, könnte man auch eine Mischform von evolutionären und inkrementellen Modell anwenden: Wir führen keine bis ins Detail gehende Analyse und Definition des Gesamtsystems durch, sondern eine so tief gehende Analyse und Definition, so dass mit großer Wahrscheinlichkeit ausgeschlossen werden kann, dass es bei der Realisierung von späteren Erweiterungen des Gesamtsystems dazu kommt, dass diese Erweiterungen nicht oder nur mit großen Aufwand ins bereits bestehende System integriert werden können (Grobkonzeption). Für das im ersten Durchlauf zu realisierende Teilsystem werden natürlich die Phasen Analyse und Definition vollständig durchgeführt. 114 4.4 Prototyping Wir haben festgestellt, dass es bei allen vorgestellten Vorgehensmodellen vorkommen kann, dass in irgendwelchen Phasen zu vorangehenden Phasen zurückgegangen werden muss, um dort gefällte Entscheidungen zu revidieren. Dieses Zurückgehen ist sehr zeit- und kostenaufwendig. Außerdem bedeutet ein Ändern in einem bestehenden System meistens ein Strukturverfall im System. Besonders aufwendig wird ein Zurückgehen in Vorphasen, wenn zum Zeitpunkt der Abnahme festgestellt wird, dass das System nicht das tut, was es eigentlich tun soll. In diesem Fall muss oft von der Phase Abnahme bis zur Analyse zurückgegangen werden. Grund eines solche "bösen Erwachens" sind oft Fehler oder Mehrdeutigkeiten in der Spezifikation, die vom zukünftigen Benutzer des Systems nicht erkannt wurden. Durch eine ausführliche durchgeführte Istanalyse, Schwachstellenanalyse etc. durch den späteren Realisierer des Systems kann oft der Umfang solcher Fehler verringert werden und Mehrdeutigkeiten richtig interpretiert werden. Eine weitere Methode ist das Erstellen von so genannten Explorativen Prototypen, mit Hilfe derer dem zukünftigen Benutzern des Systems die Bedienung und Funktionsweise des Systems exemplarisch vorgeführt werden kann. Ein zweiter Zeitpunkt, an dem ein die Wahrscheinlichkeit für ein Zurückgehen in frühere Phasen durch Anwendung des Prototyp-Konzeps verringert werden kann, ist die Phase der Implementierung. Wenn sich in dieser Phase herausstellt, dass einige der in der Phase Definition oder Entwurf vorgesehene Konzepte gar nicht oder nur mit großen Aufwand realisierbar sind, muss, falls überhaupt möglich, eine nachträgliche Korrektur der Konzepte durchgeführt werden. Dies ist oft nur mit recht großen Aufwand oder sogar (wie z. B. bei Toll Collect) im versprochenen Zeit- und Kostenrahmen gar nicht möglich. Durch einen so genannten Technischen Prototyp kann man viele Fragen der technischen Realisierbarkeit im Vorfeld ausprobieren Klassifikation von Prototypen Es gibt drei Kriterien, nach denen Prototypen klassifiziert werden können: • Was wird durch den Prototyp getestet? • Wie ist der Prototyp aufgebaut? • Inwieweit findet der Prototyp Anwendung bei der Implementierung des endgültigen Systems? 115 Was wird durch den Prototyp getestet? • Explorativer Prototyp dient als Kommunikationsgrundlage zwischen Endbenutzer und den Systementwicklern. Spätere Arbeitsweise wird durchgespielt Schwächen und Fehler der Spezifikation werden erkannt und vor der Weiterarbeit beseitigt. • Technischer Prototyp ( Experimenteller Prototyp. Labormodell) dient den Entwicklern intern als Bewertungsgegenstand, der Fragen der technischen Umsetzung und Realisierbarkeit klären soll. Beispiel für Zielsetzungen: • Überprüfung der Machbarkeit • Abschätzung des Aufwandes und damit des Zeitbedarfs und der Kosten der Realisierung • Vergleich von Alternativen • Performance-Tests • Fragen der Konfiguration (Anschluss von Druckern, Vernetzung, …) • Einsatz von Tools Wie ist der Prototyp aufgebaut? • Horizontaler Prototyp ist dadurch gekennzeichnet, dass nur eine Ebene des Systems implementiert ist. IM Normalfall ist die Schittstelle zum Benutzer (oder ein Teil davon) implementiert. Mit Hilfe solch eines Prototyps kann das Arbeiten mit dem System gezeigt werden. Da die tieferen Ebenen fehlen, liefert das System normalerweise falsche Werte. horizontaler Prototyp Schnittstelle Verarbeitunglogik Dateizugriffe • Vertikaler Prototyp 116 ist dadurch gekennzeichnet, dass er exemplarisch ausgewählte Teilfunktionen des zukünftigen Systems vollkommen realisiert. vertikaler Prototyp • Gesamtsystem mit Lücken ist dadurch gekennzeichnet, dass alle Teile des systems realisiert sind außer Plausibilitätsprüfungen, Abfangen von Ausnahme- und Fehlersituationen, komplexe Berechnungsroutinen etc. Inwieweit findet der Prototyp Anwendung bei der Implementierung des endgültigen Systems • Throw-away-Prototype (Quick-and-dirty-Prototype, Rapid-SpecificationPrototype) findet keine Verwendung bei nachfolgender Implementierung dient einzig und allein zur Entwicklung korrekter, robuster Spezifikationen • Add-on-Prototype (Rapid-Cyclic-Prototype) wird Bei der Implementierung des Zielsystem mitverwendet Beim Rapid-CyclicPrototyping wird ausgehend von einem ersten Add-on-Prototype zum Zielsystem weiterentwickelt. 4.5 Das V-Modell Das V-Modell ist hervorgegangen aus dem Wasserfallmodell, das man um die Aktivitäten Verifikation und Validation erweitert hat. Verifikation in der Bedeutung: Prüfen, ob das Produkt seiner Spezifikation entspricht. Umgangssprachlich: "Wird ein korrektes Produkt entwickelt?" 117 Validation in der Bedeutung: Prüfen, ob das Produkt für seinen Einsatzzweck geeignet ist. Umgangssprachlich: "Wird das richtige Produkt entwickelt?" Das V-Modell ist Bestandteil des Standardisierungskonzepts der Bundesbehörden. Dieses Konzept hat folgende Eigenschaften: • verbindlich für IT-Vorhaben in Bundesbehörden (wird jedoch auch in der Wirtschaft eingesetzt) • deckt die Softwareentwicklung, das Projektmanagement, die Qualitätssicherung und das Konfigurationsmanagement ab • beschreibt die Vorgehensweise (V-Modell), die anzuwendenden Methoden und die einzusetzendenWerkzeuge Das V-Modell ist in vier Submodelle gegliedert: • Softwareerstellung (SWE) • Qualitätssicherung (QS) Konfigurationsmanagement(KM) Projektmanagement (PM) • • 4.5.1 Struktur des Standardisierungskonzeptes Die Notwendigkeit der Standardisierung in der IT-Systementwicklung ist heute unbestritten. Als Vorteile der Standardisierung werden hauptsächlich gesehen: • Bessere Planbarkeit von ITProjekten • Eindämmung der Entwicklungskosten über den Lebenszyklus • Verbesserung der Qualität • Verbesserung der Kommunikation zwischen Auftraggeber und Auftragnehmer. Der Standard besteht aus folgenden drei Ebenen: 1. Vorgehensweise "Was ist zu tun?" Diese Ebene legt fest, welche Tätigkeiten im Verlauf der Systementwicklung durchzuführen sind, welche Ergebnisse dabei zu produzieren sind und welche Inhalte diese Ergebnisse haben müssen. 2. Methoden "Wie ist etwas zu tun?" 118 Hier erfolgt eine Bestimmung, mit welchen Methoden die auf der ersten Ebene festgelegten Tätigkeiten durchzuführen und welche Darstellungsmittel in den Ergebnissen zu verwenden sind. 3. Werkzeuganforderungen "Womit ist etwas zu tun?" Auf dieser Ebene ist fixiert, welche funktionalen Eigenschaften die Werkzeuge (Tools) aufweisen müssen, die bei der Systementwicklung eingesetzt werden sollen. Auf allen Ebenen werden die Regelungen nach den Tätigkeitsbereichen, den sogenannten Submodellen gegliedert: 119 4.5.2 Eigenschaften des V-Modells Das V-Modell • beschreibt Aktivitäten und Produkte • regelt die Gesamtheit der Aktivitäten und Produkte sowie die Produktzustände und die Abhängigkeiten zwischen Aktivitäten und Produkten Wichtig: das V-Modell beschreibt den Softwareentwicklungsprozeß nur aus funktionaler Sicht, d.h. es werden keine Aussagen über die konkrete organisatorische Umsetzung getroffen. Die Aufteilung von Aufgaben auf Bearbeiter bzw. Organisationseinheiten wird vor Projektdurchführung festgelegt. 4.5.3 Produktzustände und Übergänge 4.5.4 Erzeugnisstruktur Das Gesamtsystem (inklusive HW und SW) wird in unterschiedliche Bestandteile aufgelöst: • • • • 120 Subsysteme Segmente (mit DV-Anteil/ohne DV-Anteil) Konfigurationseinheiten (SW, HW und ohne DV-Anteil) KomponentenModule/Datenbanken 4.5.5 Struktur und Inhalt des V-Modells Das V-Modell besteht aus folgenden Elementen: • Aktivitäten • Produkte • Beschreibungsmuster • Submodelle 4.5.6 Aktivitäten und Produkte Aktivitäten: Tätigkeiten, die hinsichtlich ihres Ergebnisses und ihrer Durchführung genau beschrieben werden können. Sie sind durch Teilaktivitäten verfeinerbar, die Zwischenergebnisse erzeugen. Aktivitäten der obersten Ebene werden Hauptaktivitäten genannt. Produkte: Bearbeitungsgegenstand oder Ergebnis einer Aktivität, kann wiederum auch in Teilprodukte zerlegt werden. Produkte können die Zustände geplant, in Bearbeitung, vorgelegt und akzeptiert annehmen. Notation: 121 4.5.7 Aktivitätenzerlegung Die Aktivitätenzerlegung wird bei der Verfeinerung von Aktivitäten angewendet.. Sie beschreibt den Zusammenhang von Teilaktivitäten und -produkten in graphischer Form (hier die Aktivität SWE 6/Implementierung): 122 4.5.8 Produktfluss und Abwicklung Produktflüsse beschreiben die Eingangs- und Ausgangsprodukte für eine bestimmte Aktivität 4.5.9 Die Submodelle Die Aktivitäten der Softwareentwicklung werden auf vier Submodelle verteilt: • Softwareerstellung (SWE) • Qualitätssicherung (QS) • Konfigurationsmanagement (KM) • Projektmanagement (PM) 123 4.5.10 Zusammenspiel der Submodelle 4.5.11 Submodell "Softwareerstellung" (SWE) Der linke Arm des V enthält die Planungs- und Konstruktionsphasen, der rechte Arm die Integrations- und Kontrollphasen der Systementwicklung. Auf gleicher 124 Höhe befindet sich links die Phase, die die Test- und Planungs-Unterlagen für die Phase rechts liefern muss. Dieses "V" in der Darstellung des Softwareentwicklungsprozesses hat dem gesamten Vorgehensmodell den Namen gegeben. Es legt fest, dass die Testfälle für die Verifikation eines Software-Moduls bereits mit dem Feinentwurf und während der Implementierung zu erstellen sind. Die Testfälle und sonstigen Pläne für die Integration einzelner Softwaremodule müssen bei Grobentwurf und SW-Anforderungsanalyse geschaffen werden. Der Plan für die DV-Integration ist in der DV-Anforderungsanalyse festzulegen. Die Planungsunterlagen für die endgültige Systemintegration und ihr Test sind bereits während der Systemanforderungsanalyse zu schaffen. 4.5.12 Systemanforderungsanalyse und -entwurf (SWE 1) Betrifft das Gesamtsystem und besteht aus folgenden Aktivitäten: Ist-Analyse: Datenbestände, DV-Ausrüstung, Zeit/Mengengerüst, Schwachstellen Bedrohungs- und Risikoanalyse: zu schützende Objekte, Eintrittwahrscheinlichkeiten Systemanforderungen definieren: Anforderungen an Funktionalitäten, Daten, Qualitätsmerkmale aus Anwendersicht System fachlich strukturieren: Funktions- und Datenstruktur aus Anwendersicht 4.5.13 Systemanforderungsanalyse und -entwurf (SWE 1) System technisch entwerfen: Aufteilung in Subsysteme, Segmente oder Softwarekonfigurationseinheiten Machbarkeitsanalyse: Verwendung von Fertigprodukten, Wirtschaftlichkeit, Tolerierbarkeit von Restrisiko Systemanforderungen zuordnen: Zuordnung der Anforderungen zu den Systembestandteilen Systemintegration planen: Planen des Zusammenführens der Systembestandteile, Planen der Inbetriebnahme Wichtige Produkte in SWE 1 sind die Systemarchitektur und der Systemintegrationsplan Systemanforderungen, die 4.5.14 DV-Anforderungsanalyse und -entwurf (SWE 2) Besteht aus folgenden Aktivitäten: 125 • DV-Ist-Analyse • DV-Anforderungen analysieren • Machbarkeitsanalyse • DV-Segment entwerfen • DV-Anforderungen zuordnen • DV-Integration planen 4.5.15 DV-Anforderungsanalyse und -entwurf (SWE 2) Die Aktivitäten korrespondieren mit den Aktivitäten aus SWE 1, jedoch betreffen sie hier nur einzelne DV-Segmente. Wichtige Produkte sind die DV-Anforderungen, die DV-Architektur, der Schnittstellenentwurf und der DV-Integrationsplan 4.5.16 SW-Anforderungsanalyse (SWE 3) Behandelt einzelne SWKE und besteht aus folgenden Aktivitäten: • • • • • • • Ist-Analyse Allgemeine Anforderungen definieren Anforderungen an externe Schnittstellen definieren Anforderungen an Funktionen und Daten definieren Qualitätsanforderungen definieren Anforderungen an Entwicklungsumgebung und Zielrechner definieren Als Produkt werden die SW-Anforderungen erstellt. 4.5.17 Grobentwurf (SWE 4) Zerlegt die SWKE in einzelne Prozesse und definiert die Kommunikation und Synchronisation zwischen den Prozessen.Weiter werden die SWKE dann in Module aufgeteilt. Aktivitäten sind: • SW-Architektur entwerfen • Prozesse entwerfen 126 • SWKE-interne Schnittstellen entwerfen • SWKE-Integration definieren Als Ergebnis wird die SW-Architektur, der Schnittstellenentwurf und der SWKEIntegrationsplan erstellt. 4.5.18 Feinentwurf (SWE 5) Entwurf der Realisierung der Module und Datenbanken: • Komponente/Modul/Datenbank beschreiben • Betriebsmittel- und Zeitbedarf analysieren Hieraus resultieren der Datenkatalog und der SW-Entwurf. 4.5.19 Implementierung (SWE 6) Umsetzung der Module und Datenbanken: • Module codieren • Datenbanken realisieren • Informelle Prüfung • Debugging Produkte sind Module und Datenbanken. 4.5.20 SW-Integration (SWE 7) Zusammenführung der Module und Datenbanken zu SWKE: Zu SWKETeilstruktur integrieren • Komponente informell prüfen • Zur SWKE integrieren • SWKE informell prüfen Ergebnis der SW-Integration sind die SWKE. 4.5.21 DV-Integration (SWE 8) Zusammenführung von SWKE und HWKE zu DV-Segmenten: 127 • Zum DV-Segment integrieren • Tuning • Beitrag zur Einführungsunterstützung leisten • DV-Segment informell prüfen Die DV-Integration liefert vollintegrierte und teilintegrierte DV-Segmente 4.5.22 Produkte im Submodell SWE Produkte, die bei der SWE erstellt werden: Systemprodukte: Systemanforderungen, Systemarchitektur DV-Produkte: DV-Anforderungen, DV-Architektur SW-Produkte: SW-Anforderungen, SW-Architektur, SW-Entwurf, Implementierungsdokumente Integrationsdokumente: Integrationsplan Handbuchinformation: Anwenderhandbuch, Diagnosehandbuch, Betriebshandbuch Begleitende Dokumente: Datenkatalog, Schnittstellenentwurf 4.5.23 Submodell"Qualitätssicherung" 4.5.24 Aktivitäten im Submodell QS 128 Folgende Aktivitäten werden im Submodell QS durchgeführt: QS-Initialisierung: legt den organisatorischen Rahmen im QS-Plan und in Prüfplänen fest Prozeßprüfung von Aktivitäten: Prüft die Einhaltung bestimmter Vorgehensweisen Produktprüfung vorbereiten: Erstellen von Prüfspezifikationen und -prozeduren, Erfolg und Mißerfolg einer Prüfung muß eindeutig und nachvollziehbar sein 4.5.25 Aktivitäten im Submodell KM KM-Initialisierung: legt organisatorischen Rahmen für die Konfigurationsverwaltung sowie alle Einsatzmittel fest Konfigurationsverwaltung: Verwaltung von Produkten, Konfigurationen und Rechten, Festlegung einer zentralen Datenadministration Änderungsmanagement: Erfassung von Fehlermeldungen, Problemmeldungen, Verbesserungsvorschlägen etc. Datensicherung KM-Berichtswesen: Zur Vorbereitung von Durchführungsentscheidungen und zur Information des Projektmanagements 4.5.26 Submodell "Projektmanagement" (PM) 129 4.5.27 Aktivitäten im Submodell PM Projekt initialisieren: regelt den organisatorischen Rahmen für das gesamte Projekt im Projektplan und Projekthandbuch. Legt Modalitäten für die projektinterne Zusammenarbeit und die Schnittstelle zum Auftraggeber fest. Anpassung des Vorgehensmodells (Tailoring). Projekt begleiten: Unterteil in die Phasen Initialisieren, Begleiten und Abschließen der einzelnen Aktivitäten im Projekt. Projekt abschließen: Aufbereitung der Ergebnisse, Soll-Ist-Vergleich 4.5.28 Rollen im V-Modell Das V-Modell legt Rollen fest, die durch Erfahrungen, Kenntnisse und F¨ahigkeiten definiert sind. Diese Rollen werden dann im Projektablauf den Mitarbeitern zugewiesen: SWE-Rollen: Systemanalytiker, Systemdesigner, DV-Analytiker, DV-Designer, SW-Analytiker, SW-Designer, Programmierer, Supportberater, Applikationsberater, HW-Berater, Technischer Autor PM-Rollen: Projektmanager, Projektleiter, Projektassistent QS-Rollen: QS-Manager, QS-Verantwortlicher, Qualitätsprüfer, QS-Assistent KM-Rollen: KM-Leiter, Konfigurationsadministrator, Datensicherheitsbeauftragter Datenschutz- und Den einzelnen Rollen werden detailliert Aufgaben zugeordnet (ausführend, beratend, mitwirkend). Die Zuordnung von Rollen zu Mitarbeitern kann frei erfolgen mit zwei Ausnahmen: Personen mit QS-Rollen dürfen nicht an der Erstellung der von ihnen zuprüfenden Produkte beteiligt sein (dies ist abhängig von der Kritikalität unterschiedlich streng zu handhaben) • Zu trennen ist auch die Rolle des Projektmanagers von QS- und SWE-Rollen Es ist somit eine Mindestanzahl von zwei bis drei Personen an einem Projekt beteiligt. • 4.5.29 Tailoring 130 Das V-Modell soll sowohl für kleine als auch sehr große Projekte geeignet sein. Demzufolge definiert es alle Aspekte, die in diesen Projekten auftreten können. Das Tailoring sieht vor, aus dem V-Modell durch Streichungen ein an das Projekt angepasstes Modell zu erstellen. Es sind jedoch auch schon Beispielmodelle (inklusive Dokumente) erhältlich. 4.5.30 Zusammenfassung • Das V-Modell ist ein übergreifendes Modell zur Abwicklung von Softwareentwicklungsvorhaben • • Es muß vor dem Einsatz angepaßt werden Wegen der hohen Zahl und Komplexität von zu erstellenden Produkten ist eine Werkzeugunterstützung fast zwingend Es verlangt erhöhte Kooperation zwischen Auftraggeber und Auftragnehmer; kann dabei aber Kommunikationsprobleme verringern • 131 4.6 RUP Der Rational Unified Process (RUP) ist ein Vorgehensmodell (Software Engineering Process), das von der Firma Rational Software entwickelt wurde. Dieses stellt ein umfangreiches Rahmenwerk zur Entwicklung von qualitativ hochwertiger Software bereit. Der Anwendungsbereich des RUP ist sehr weit gefasst und soll unterschiedlichste Projekttypen in Bezug auf Projektgröße, Anwendungsgebiet und Plattform unterstützen. Der RUP beschreibt ein Vorgehensmodell auf Basis von sog. "Best Practices", die erwiesenermaßen bei erfolgreichen Projekten zum Einsatz kommen. Diese umfassen im Einzelnen die iterative Entwicklung von Software, das Management von Anforderungen, die Nutzung komponentenbasierter Architekturen, die visuelle Modellierung der Software, die Verifikation der Software-Qualität und der Etablierung eines Änderungsmanagements. Um die gesteckten Ziele zu erreichen, definiert der RUP diverse Workflows (bzw. Disziplinen), Rollen und Artefakte. Ein Workflow (Disziplin) beschreibt eine Sequenz von Aktivitäten, die die Verbindung zwischen Rollen, Aktivitäten und Artefakte herstellt. Die Artefakte können Dokumente, Codestücke, Modelle oder Berichte sein und stellen das Ziel einer Aktivität dar. Die einzelnen Aktivitäten werden dabei von den Inhabern der zugeordneten Rolle ausgeführt und unterteilen sich in einzelne Schritte. Zusammengefasst ergeben die Aktivitäten folgende neun Disziplinen: Geschäftsprozessmodellierung (Business Modelling), Anforderungsanalyse (Requirements), Analyse und Design, Implementierung, Test, Softwareverteilung (Deployment), Konfigurations- und Änderungs-Management, Projektmanagement sowie IT-Infrastruktur (Environment). Diese werden in die sog. Core Process Workflows und Core Supporting Workflows unterteilt (siehe Abbildung 4-2). Dieser Teil des RUP bildet den statische Teil. Darüber hinaus wird der dynamische Teil des RUP durch Phasen, Iterationen, Zyklen und Meilensteinen dargestellt. Die vier Phasen des RUP lauten Inception, Elaboration, Construction und Transition. Jede Phase wird beim RUP in mehreren Iterationen abgehandelt. In jedem Zyklus wird eine neue Produktversion erstellt, die bestimmte Anwenderanforderungen erfüllt. Meilensteine stellen bestimmte Zeitpunkte dar, an denen wichtige Entscheidungen abhängig vom erreichten Entwicklungsstand getroffen werden können. Die Disziplinen durchziehen jeweils mehrere Phasen, allerdings mit unterschiedlicher Intensität der assoziierten Aktivitäten. Dies wird durch die dargestellte Fläche pro Disziplin verdeutlicht. 132 Abb. 4-2: Der Rational Unified Process (RUP) 4.6.1 RUP-Phase "Inception" Die Inception-Phase beschäftigt sich mit dem Aufsetzen eines Projekts und bildet den Einstiegspunkt zur Erstellung oder Änderung eines Systems. Ziel dieser Phase ist es, den Projektumfang festzulegen und einen sogenannten "Business Case " als Grundlage für das durchzuführende Projekt zu erstellen. Dies beinhaltet auch eine Risiko- sowie Zeit- und Kostenschätzung im Rahmen des Projektmanagements und beschreibt die Erfolgskriterien, die an das Produkt gestellt werden. Des Weiteren wird ein sog. "Vision"-Dokument erstellt, das die wesentlichen Rahmenbedingungen des Projektes sowie die Anforderungen und Hauptfunktionen des zu erstellenden Systems beschreibt. Ein weiterer Schwerpunkt dieser Phase bildet die Durchführung der Geschäftsprozessmodellierung. Hierfür sind neben den sog. Stakeholdern die Rollen Business-Process Analyst, Business Designer und Business Model Reviewer vorgesehen. Um ein gemeinsames Verständnis der Anwendungsdomäne zu erreichen, wird zunächst vom Business-Process Analyst ein gemeinsamer Wortschatz in Form eines Glossars erarbeitet. Danach werden von diesem Analyst die an den Geschäftsprozessen beteiligten Personen sowie die Anwendungsfällen (Use Cases) identifiziert. Eine Detaillierung dieser UseCases erfolgt vom Business Designer. Die weitere Strukturierung des Anwendungsfall-Modells fällt der Rolle des Analysten zu. Dieses Anwendungsfall-Modell wird nun vom Business Model Reviewer überprüft. 133 Neben der Geschäftsprozessmodellierung werden in der Inception-Phase die Hauptanforderungen als wichtige Grundlage für das zu erstellende System erarbeitet. Am Ende dieser Phase stehen so ein konzeptioneller Prototyp sowie ein erstes, noch unvollständiges Domainmodell für die weiteren Phasen bereit. Somit ist ein wichtiger Meilenstein (der "Lifecycle Objectives Milestone") erreicht. Sofern die Projektziele zu diesem Zeitpunkt gefährdet sind oder als nicht erreichbar eingeschätzt werden, kann ein Projekt hier beendet oder in veränderter Form neu aufgesetzt werden. 4.6.2 RUP-Phase "Elaboration" Die Aufgabe der Elaboration-Phase ist die weitere Ausarbeitung des Projekts. Dabei werden die funktionellen und nicht funktionellen Anforderungen aus der vorherigen Phase im Rahmen des Software Development Plans (SDP) erarbeitet und einen Projekt- sowie einen Iterationsplan erstellt. In diesen Plänen werden die während des Projekts zu verwendenden Ressourcen und Werkzeuge festgelegt. Der Software Development Plan liefert eine Hilfe für die Durchführung folgender RUP-Komponenten: Projektorganisation, Requirements Management Plan, Configuration Management Plan, Problem Resolution Plan, Quality Assurance Plan, Test Plan, Test Cases, Evaluation Plan und Product Acceptance Plan. Des weiteren wird in der Elaboration-Phase eine detaillierte Analyse der Problembereichen durchgeführt und die Basisarchitektur des zu erstellenden Systems festgelegt ("mile wide and inch deep view of the system"). Zusätzlich erfolgt die Identifikation und Beschreibung der Hauptrisiken. Ziel ist es, die identifizierten Hauptrisiken durch entsprechende Maßnahmen möglichst früh zu eliminieren. Zur Erstellung der Anforderungsanalyse und des Designs sind folgende sieben Rollen definiert: der System Analyst, der Use Case Specifier, der User Interface Designer, der Architect, der Designer, der Datenbank Designer und der Capsule Designer, welcher für das objektorientierte Design zuständig ist. Wichtige Artefakte dieser Phase sind der Anforderungsplan, ein detailliertes Use Case Modell, ein User Interface Prototyp (falls notwendig), ein Softwarearchitekturplan, ein Datenmodell, Klassendiagramme, ein Designmodell sowie weitere notwendige Dokumente. Welche Artefakte in dieser Phase erstellt werden müssen, hängt selbstverständlich von dem Projekttyp ab. Hierzu bietet auch der RUP die Möglichkeit, sich an die Projektgegebenheiten anzupassen ("RUP Configuration"). Zur Erstellung dieser Artefakte stehen diverse Werkzeuge zur Verfügung. Hierbei wird angestrebt, dass möglichst automatisch Artefakte der nächsten Stufe erzeugt werden können. Beispielsweise ist es möglich, aus einem Klassendiagramm die Klassen (Coderahmen) in der jeweiligen Programmiersprache zu erzeugen. Weitere Möglichkeiten stellen die Generierung der benötigten Tabellen aus einem Datenmodell dar. Am Ende dieser Phase stehen 134 eine überarbeitete Risikoabschätzung sowie die Basisarchitektur des umzusetzenden Systems. Damit sind die wichtigsten Rahmenbedingungen geschaffen, um das geforderte System in der nächsten Phase weiter zu entwickeln. Diese Phase des RUP stellt die kritischste Phase dar und die "harte EngineeringPhase" ist hiermit für das Projekt beendet ("Lifecycle Architecture Milestone"). Konzeptuell gesehen, sollte ein Grad an Sicherheit in Bezug auf Architektur, Anforderungen etc. erreicht sein, damit die nachfolgende Phase als Fix-PreisProjekt durchgeführt werden könnte. Auch hier gilt, dass ein Projekt beendet werden kann, wenn die Ziele dieser Phase nicht erreicht wurden. 4.6.3 RUP-Phase "Construction" In der Construction-Phase findet der größte der Teil der Implementierung des Systems statt. Die einzelnen Klassen bzw. Software-Komponenten werden ausprogrammiert und notwendige Schnittstellen realisiert. Zusätzlich werden Testfälle erstellt und deren Durchführung geplant. Hiermit soll eine Qualitätssicherung bereits vor der Implementierung gewährleistet werden. Die Ergebnisse jeder einzelnen Iteration dieser Phase stellen Produkt-Releases dar, die dem Kunden zur Verifikation übergeben werden können. Die Disziplin Implementierung umfasst neben der Implementierungsplanung und der Erstellung der einzelnen Softwarekomponenten auch die Planung und Durchführung der Integration der jeweils betroffenen Software-Komponenten. Auch werden die Datenbanken mit den notwendigen Tabellen erstellt. Zur Durchführung der diversen Aktivitäten sind beim RUP vier Rollen vorgesehen. Diese sind der Architect, der System Integrator, der Code Reviewer sowie der Implementierer. Der RUP legt einen klaren Schwerpunkt auf das Testen der Software vor deren Auslieferung. Hierbei durchlaufen die einzelnen Tests die Phasen Planung, Design, Implementierung, Ausführung und Evaluierung. Eine entwickelte Komponente wird sowohl isoliert von anderen Komponenten getestet (Komponententest) als auch im Verbund mit anderen Komponenten (Verbund-/Integrationstest). Die Tests helfen, unerwünschte Seiteneffekte herauszufinden, die bei der Kommunikation einzelner Komponenten auftreten können. Erst bei erfolgreicher Absolvierung dieser Tests gilt eine Komponente als fertig gestellt. Die Durchführung der Testphasen wird durch die vier Rollen, Test Designer, Designer, Implementer und Tester abgedeckt. Diese Phase des RUP kann als Produktionsprozess bezeichnet werden, da der Fokus auf das Management der vorhandenen Ressourcen und die Steuerung der Aktivitäten liegt, um so die Kosten, den Zeitplan und die geforderte Qualität einzuhalten. 135 Die Construction-Phase liefert als Ergebnis ausführbare und qualitätsgesicherte Produkt-Versionen. Die Auslieferungsplanung legt fest, wann der Kunde welche Komponenten bzw. Produktversionen erhält bzw. wann diese in Produktion gehen sollen ("Wirk- oder Produktionsumgebung"). Schließlich wird in dieser Phase auch die System- und Benutzerdokumentation erstellt. Nach Abschluss dieser Phase ist der Meilenstein "Initial Operational Capability" erreicht. Oft entspricht das erstellte Produkt dem Status eines Beta-Release. Sofern ein stabiler Produktzustand erreicht ist, kann in die nächste Phase gegangen werden. 4.6.4 RUP-Phase "Transition" In der Transition-Phase wird das erstellte System oder Teile davon (Subsystem) vollständig dem Kunden übergeben. Neben der Übergabe sieht der RUP auch eine Unterstützung bei der Inbetriebnahme und dem Umgang mit der Software vor. Hierbei auftretende Probleme werden umgehend gelöst. In der Disziplin Deployment wird zunächst ein Deployment Plan erstellt, der die Integration des Systems in die IT-Landschaft des Kunden beschreibt. Weitere Dokumente zum Umgang mit dem System werden erstellt. Zur Durchführung des Deployments sind folgende fünf Rollen definiert: der Implementer, der Technical Writer, der Deployment Manager, der Graphic Artist und der Course Developer. Die Inbetriebnahme des entwickelten Systems bedeutet, dass dieses in die ITLandschaft des Kunden integriert werden muss. Hierzu müssen unter Umständen noch Implementierungsarbeiten und Tests durchgeführt werden, die in einer früheren Phase nicht durchgeführt wurden bzw. konnten. Das Software-Produkt durchläuft somit verschiedene Stati: von dem Beta-Release, über General Availability Release bis hin zu Bug-Fixes und Enhancement Releases. Für die verschiedenen Produktstände empfiehlt sich die Ausarbeitung, Durchführung und Auswertung der Akzeptanztests, um die Abnahme des jeweiligen Produkts zu erreichen. Am Ende der Transition Phase ist der Meilenstein "Product Release" erreicht. Der Abschluss der Aktivitäten der Transition-Phase stellt damit das Projektende dar. Nach der Übergabe des Produkts an den Kunden sollte von Seiten des Softwareunternehmens bzw. Softwareerstellers eine Nachbetrachtung hinsichtlich der eingehaltenen Planungen und der notwendigen Anpassungen erfolgen. Hiermit sollen Probleme oder Mängel in zukünftigen Projekten vermieden werden. Einige Beratungsfirmen pflegen daher umfangreiche Wissens- bzw. Projektdatenbanken, um die gemachten Erfahrungen und Erkenntnisse möglichst schnell in neue Projekte einfließen lassen zu können. 136 4.7 eXtreme Programming (XP) 4.7.1 Warum XP? Im Jahr 1998 führten erste Veröffentlichungen von Kent Beck unter dem Titel eXtreme Programming (XP, Extremes Programmieren) zu bis heute anhaltenden Diskussionen. Die von ihm vorgeschlagenen Forderungen für ein Methode zur erfolgreichen Software-Entwicklung, die "das Programmieren zur Schlüsselaktivität während der gesamten Dauer eines Softwareprojektes [erklärt]" (Erich Gamma im Vorwort zu [Beck 03]), wurden und werden in ihrer "extremen" Art von manchem als provokativ empfundenen. Beck vergleicht den Software-Entwicklungsprozess mit dem Steuern eines Autos zum Erreichen eines vorgegebenen Ziels: die Lenkung des Autos erfordert eine kontinuierliche Justierung zur Zielrichtung in kleinsten Einheiten. Dieses Bild überträgt Beck auf die Forderung, den Software-Entwicklungsprozess in kleinste, iterative Schritte zu gliedern, die die Erreichung des Projekt-Ziels durch die permanente Anwendung geeigneter Regulierungspraktiken garantiert. Beck nennt vier Variablen, mit deren Hilfe man jedes Projekt kontrollieren kann: Kosten, Zeit, Qualität und Umfang – alle vier Variablen stehen in komplexen Abhängigkeiten zueinander. Der Umfang ist jedoch die wichtigste und am einfachsten zu steuernde der vier Kontrollvariablen, wenn die Softwareentwicklung in kleinsten Entwicklungseinheiten durchgeführt wird und dadurch die unmittelbare, d.h. zeitnahe Kontrolle der drei anderen Variablen ermöglicht. Die bislang angewandten Vorgehensmodelle enthielten diese Forderung nach kleinsten Iteartionsschritten mit allen zugehörigen Konsequenzen nicht in der von Beck geforderten, "extremen" Art. Beck betont die Wichtigkeit der Gesamtheit aller anzuwendenden Praktiken (vgl. 4.6.2). Werden einzelne Praktiken aus dem Gesamtkontext des XP gelöst, ist die eigentliche Idee des XP nicht mehr tatsächlich verwirklicht. "Calling the tail a leg doesn't make it one." [Jeff 04]. Unter der Gesamtheit aller IT-Projekte können solche als besonders geeignet für die Anwendung des XP als Methode zur Entwicklung von Software bezeichnet werden, die risikobehaftet sind und mit einem hohen Grad an dynamischen Anforderungen von kleinen bis mittelgroßen Teams realisiert werden. XP wurde seit 1998 bis zur heute diskutierten Form von Kent Beck, Ward Cunningham, Martin Fowler und Ron Jeffries definiert und durch umfangreiche Erprobung in Projekten ständig weiterentwickelt. 4.7.2 Die zwölf Praktiken Der Planungsprozess (Planning Process) (bzw. das Planungsspiel) hat zum Ziel, durch die Definition der Anforderungen (Requirements) eine gezielte Planung für 137 jede einzelne Iteration zu ermöglichen. Verfügbare Entwicklungsressourcen und Kundenwünsche werden dabei in Einklang gebracht. Die Aufgabe des Kunden besteht hierbei darin, seine User Stories zu definieren. Diese werden auf Karteikarten notiert und sind vergleichbar mit einer Beschreibung von Anwendungsfällen auf einer zunächst relativ generischen Ebene. Für jede Iteration werden die User Stories ggf. korrigiert und neu priorisiert, um die Hinführung des Gesamtprojekts zum Erfolg in kleinsten, validierbaren Schritten zu garantieren. Zum geeigneten Zeitpunkt werden die User Stories im Dialog der Entwickler mit dem Kunden verfeinert und ggf. neu verhandelt. Kleine Releases (Small Releases) sind das Ziel erfolgreich durchgeführter Iterationen auf der Basis des im Planungsprozess erzielten Release-Planes (Release Plan). Jedes dieser kleinen Releases erlaubt eine frühzeitige Produktionsübernahme der entsprechenden User Story und garantiert die permanente Erweiterung im Hinblick auf das Gesamtprojektziel in jeweils sehr kurzen Release-Zyklen. Ein Release-Zyklus umfasst 1-3 Monate. In dieser Phase werden mehrere Iterationen einer Dauer von 1-3 Wochen durchlaufen, die sich wiederum in Arbeitspakete einer Dauer von 1-3 Tagen gliedern. Die System-Metapher (System Metaphor) dient dazu, die Architektur bzw. einen Teil der Architektur zu beschreiben. Durch ein von allen Mitgliedern des XP Teams gemeinsam genutztes System von Bezeichern, Begriffen und Beschreibungen wird die Entwicklung und die Kommunikation unterstützt und gefördert. Einfacher Entwurf (Simple Design) bedeutet, dass zur Erreichung der aktuellen Anforderungen die minmalistischste Lösung bzgl. des Aufwandes herangezogen wird, "the simplest thing that could possibly work" [Beck 99]. Dies bedeutet u.a. auch, dass keine der zukünftigen Anforderungen bereits "mit implementiert" wird. Zur Erlangung eines guten Designs sollte insbesondere die Praxis des Refaktorisierung (s.u.) zum Einsatz kommen. Das Testen (Testing) begleitet jeden Iterationsschritt. Funktionale Akzeptanztests auf der Basis von Testfällen, die der Kunde – in Anlehnung an die jeweilige Story – definiert, werden von den Testern implementiert (Acceptance Tests). Sie sind jederzeit automatisch ausführbar und werden ergänzt von Kompontententests (Unit Tests), die von den Entwicklern zum Test ihrer Klassen vor der Implementierung der Klassen geschrieben werden (vgl. auch den Abschnitt JUnit in Kapitel 8). Diese beiden Teststrategien bilden den Kern der XP-Teststrategien und werden ergänzt durch Paralleltests und Belastungstests. Refaktorisierung (Refactoring) verbessert während des gesamten Entwicklungsprozesses das Design des Systems durch permanente Vereinfachung des Codes bei 138 gleichbleibender Semantik und wachsender Verständlichkeit. Ergänzende Dokumentationen werden mehr und mehr überflüssig gemäß dem Ziel, Code zu generieren, der durch klare Strukturen und geeignete Namensgebung letztlich selbsterklärend ist. Nach jeder Refaktorisierung muss durch Tests die unveränderte Semantik geprüft werden. Paarweise Programmierung (Pair Programming) führt nachweislich zu gleichen bzw. geringeren Kosten als bei Einzelprogrammierung – bei weniger fehlerhaftem Code und höherer Verständlichkeit des Codes. XP Entwickler arbeiten stets zu zweit an einem Rechner, wobei einer der Entwickler programmiert, während der andere logische und syntaktische Fehler beachtet sowie die Kompatibilität des Codes zum Entwurf und die Vollständigkeit der Testfälle prüft. Entwickler-Paare können sich für jedes Arbeitspaket neu bilden; hierdurch wird ein breites KnowHow jedes Entwicklers bzgl. des Gesamtsystems gewährleistet und die "Unentbehrlichkeit" einzelner Entwickler ausgeschlossen. Kollektives Eigentum von Code (Collective Ownership) bedeutet, dass jeder Entwickler jeder Zeit Änderungen an jedem Code vornehmen kann. Auch hier gewährleistet der unmittelbar anschliessende Test die unveränderte Semantik der zu testenden Einheit. Das kollektive Eigentum von Code impliziert die gemeinsame Verantwortlichkeit. Fortlaufende Integration von Code (Continuous Integration) ermöglicht schnellen Projektfortschritt dadurch, dass durch täglich mehrmalige Integration neuer Komponenten in das bestehende System größere Integrationsprobleme vermieden werden und alle beteiligten Entwickler umittelbar Gewissheit bzgl. der Integrationsfähigkeit ihrer neu entwickelten Komponente haben. Das integrierte System stellt ein in kurzen Zyklen permanent erweitertes, stets lauffähiges System dar. Die 40-Stunden-Woche (40-hour Week) minimiert die Fehleranfälligkeit von Komponenten, die durch übermüdete, erschöpfte Entwickler implementiert werden. Die Erfahrung zeigt: "Tired programmers make more mistakes." Der Kunde vor Ort (On-site Customer) ist unerlässlich, da aufgrund der geringen Granularität von Anforderungen aus dem Planungsprozess permanent Rücksprachemöglichkeit mit einem Kundenvertreter im Projektteam zur Klärung von offenen Punkten gewährleistet sein muß. Der Kunde vor Ort ist auch verantwortlich für die Definition der Testfälle zu den Akzeptanz-Tests. Programmierstandards (Coding Standard) sind ebenso unerlässlich, da insbesondere die Praktiken Paarweise Programmierung, Kollektives Eigentum von 139 Code und Refaktorisierung mit dem Ziel, selbsterklärenden Code zu implementieren, ohne Programmierstandards nicht durchführbar sind. Abbildung 4.6-1 zeigt die Abhängigkeiten der zwölf Praktiken untereinander. Eine Verbindungslinie zwischen zwei Praktiken weist darauf hin, dass diese beiden Praktiken sich gegenseitig verstärken. Kunde vor Ort Planungsspiel 40-Stunden-Woche Metapher Einfaches Design Refactoring Testen Programmieren in Paaren Kurze Releasezyklen Programmierstandards Gemeinsame Verantwortlichkeit Fortlaufende Integration Die Abhängigkeiten der zwölf Praktiken untereinander Abb. 4.6-1: Die Abhängigkeiten der zwölf Praktiken untereinander [Beck 03] Quelle: Beck, K.; Extreme Programming. Das Manifest; Addison Wesley 2003 4.7.3 Der XP Prozess 140 In diesem Abschnitt werden in Abb. 4.6.-2 zur Visualisierung eines XP-Projektes diejenigen der zwölf o.g. Praktiken in ihren zyklischen Abläufen dargestellt, die unmittelbar einer Projektphase bzw. dem Ergebnis einer Projektphase als Voraussetzung für die folgende Projektphase entsprechen. Release-Zyklus 1-3 Monate Test Scenarios User Stories Architectural Spike Requirements System Metaphor Release Planning Uncertain Estimates New User Story Project Velocity Release Plan Confident Estimates Iteration Acceptance Tests Small Releases Next Iteration Spike Iterationen von 1-3 Wochen Arbeitspakete von 1-3 Tagen Abb. 4.6-2: Zyklen im XP-Projekt, in Anlehnung an [Wells 00] Release-Zyklus (1-3 Monate) Auswahl einer priorisierten User Story als Basis für die Implementierung des nächsten kleinen Release. In die Release Planung fliesst die Systemmethapher mit ein, um Entwicklung und Kommunikation sowohl der Entwickler untereinander als auch mit dem Kunden und dem Management zu unterstützen und zu fördern. Iteration (1-3 Wochen) 141 In einzelnen Iterationen werden Komponenten implementiert und durch anschliessende Akzeptanz-Tests die Korrektheit und Vollständigkeit der Komponenten bzgl. der User Story und der zugehörigen Testfälle geprüft. 142 Arbeitspaket (1-3 Tage) Im Rahmen eines Arbeitspaketes erstellen bzw. verbessern EntwicklerPaare Komponenten (Refactoring), führen Tests durch und garantieren durch kontinuierliche Integration die Verfügbarkeit eines permanent sich weiterentwickelnden, lauffähigen Systems. Jede Iteration kann durch Korrekturen an den User Stories in Zusammenarbeit mit dem Kundenvertreter im Projektteam zu einer neuen, geänderten User Story führen. Dies erfordert eine erneute Releaseplanung, um mit dem überarbeiteten Releaseplan die nächste Iteration auf dem Weg zur Freigabe des aktuell projektierten kleinen Releases zu ermöglichen. Der Prozess der Releaseplanung ist dann abgeschlossen, wenn alle unsicheren Schätzungen (Uncertain Estimates) durch sichere Schätzungen (Confident Estimates) ersetzt worden sind. Der Release-Zyklus ist abgeschlossen, wenn das aktuell projektierte kleine Release in die Produktion übernommen wurde. 4.7.4 Die Umsetzung Die Durchführung eines XP-Projektes erfordert eine enge, permanente Zusammenarbeit zwischen den Entwicklern, dem Management und dem Kunden, der insbesondere durch seinen Kundenvertreter im Projektteam fortwährend in das Projektgeschehen involviert ist. Der Kunde muss also die Bereitschaft besitzen, sich auf alle XP-Praktiken einzulassen. Die räumliche Umgebung soll die hohen Anforderung an die Kommunikation aller Beteiligten untereinander durch eine offene Arbeitsumgebung unterstützen; die Ausstattung der Arbeitsplätze berücksichtigt die Praxis der Paar-Programmierung. Ein Entwicklerteam sollte eine Größe von 10-15 Entwicklern haben. Die Aufgabe des Managements besteht im Beobachten und Aufzeigen von Problemen, deren Lösungsmöglichkeiten vom Kunden und den Entwicklern gemeinsam erarbeitet wird. Durch die kurzen Iterationszyklen und die kontinuierliche Integration sollten Änderungskosten höchstens logarithmisch mit der Zeit steigen. Beck empfiehlt die schrittweise Einführung der einzelnen XP-Praktiken entsprechend ihrer aktuellen Dringlichkeit und unter Berücksichtigung ihrer Abhängigkeiten untereinander (vgl. Abb. 4.6.-1). Den vollständigen Wirkungsgrad erreicht man jedoch immer erst bei vollständigem Einsatz aller Praktiken. "Einzelne Elemente von XP können bedeutende Vorteile bringen. Ich glaube lediglich daran, dass man sehr viel mehr gewinnen kann, wann man alle Einzelteile zusammenfügt." [Beck 03] 143 4.7.5 Weiterführende Literatur Als weiterführende Literatur werden neben den referenzierten Büchern und URLs die folgenden "Standardwerke" und URLs empfohlen: eine Vertiefung zum Thema Extremes Programmieren planen findet man in [BeckFowl 00] bzw. in der deutschsprachige Version [BeckFowl 01], zum Schwerpunkt des Testens im Rahmen des Extremen Programmierens in [Beck 02] (vgl. hierzu auch die Literaturangaben aus Kapitel 8, Abschnitt JUnit), sowie zum Thema Refactoring in Fowler's gleichnamigem Buch in der Originalfassung [Fowl 99] und der deutschen Übersetzung [Fowl 00]. Wichtige URLs zum Thema Extreme Programming sind Ward Cunningham's Wiki Wiki Web [Cunn], Ron Jeffries‘ Seite Xprogramming [Jeff], sowie Don Wells‘ A gentle introduction zum Thema Extreme Programming [Wells 03], die durch eine Verfeinerung einer Grafik in der Art von Abb. 4.6-2 die unterschiedlichen Prozessebenen im Rahmen eines XP-Projektes sehr schön visualisiert. 4.7.5.0.1 Literatur [Beck 99] Beck, K.; Extreme Programming Explained: Embrace Change; Reading/MA: AddisonWesley 1999 [BeckFowl 00] Beck, K., Fowler, M.; Planning Extreme Programming; Addison Wesley 2000 [BeckFowl 01] Beck, K., Fowler, M.; Extreme Programming planen; Addison Wesley 2001 (deutsche Übersetzung von [Beck 00]) [Beck 02] Beck, K.; Test-Driven Development; Addison Wesley 2002 [Beck 03] Beck, K.; Extreme Programming. Das Manifest; Addison Wesley 2003 (deutsche Übersetzung von [Beck 99]) [Fowl 99] Fowler M.; Refactoring; Addison Wesley 1999 [Fowl 00] Fowler M.; Refactoring. Wie Sie das Design vorhandener Software verbessern; Addison Wesley 2000 (deutsche Übersetzung von [Fowl 99] URLs [Cunn] http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap [Jeff] www.xprogramming.com/ [Jeff 04] http://c2.com/cgi/wiki?AreYouDoingXp [Wells 00] www.extremeprogramming.org/map/project.html [Wells 03] www.extremeprogramming.org 4.8 Prozessorientiertes Software-Qualitätsmanagement 144 4.8.1 Überblick Qualität bei der Softwareentwicklung hat zwei Aspekte: Produkt- und Prozessqualität. In diesem Abschnitt geht es um die Prozessqualität, d.h. um die Qualität der Entwicklungsprozesse von Software. Warum ist die Qualität des Entwicklungsprozesses von Software wichtig? Reicht nicht die Qualität des Produktes aus, die z.B. mit guten Anforderungsdefinitionen und sorgfältigen Tests gewährleistet wird? Die Antwort darauf ist ganz einfach: Aus eigener Erfahrung werden Sie bereits Entwicklungsprojekte kennengelernt haben, in denen die nachvollziehbare Umsetzung von Anforderungen systematisch betrieben wurden. Daneben haben Sie sicherlich auch andere Entwicklungsprojekte erlebt, in denen einfach drauf los entwickelt wurde. Entsprechend unterschiedlich fällt in der Regel die Produktqualität aus. Zusammengefasst heißt dies also: Die Produktqualität bei der SoftwareEntwicklung hängt von der Qualität der Entwicklungsprozesse ab. Oder noch mehr zugespitzt: Die Produktqualität von Software wird von der Prozessqualität bestimmt. Dies ist die Ausgangshypothese der hier vorzustellenden prozessorientierten Qualitätsmanagementansätze. (Dies heißt übrigens nicht, dass produktbezogene Qualitätssicherung wie z.B. Testen jetzt überflüssig wäre!) Die gute Botschaft daran ist, dass die Produktqualität durch die Einführung guter Entwicklungsprozesse gesteuert werden kann. Doch was sind nun gute Entwiclungsprozesse? Bereits seit Anfang der 80er Jahre haben verschiedene Organisationen damit begonnen, auf der Basis einer Vielzahl echter Projekterfahrungen wichtige Elemente für erfolgreiche Software-Entwicklungsprozesse zu identifizieren. Beispiele hierfür sind: • Arbeiten mit Projektplänen • Systematische Erfassung und Umsetzung der Kundenanforderungen • Arbeiten mit Konfigurationsmanagementsystemen Die in den 80er Jahren an verschiedenen Stellen begonnenen Arbeiten zur systematischen Beschreibung, was ‚gute Software-Entwicklungsprozesse sind, hat inzwischen zu einigen wichtigen Standardmodellen geführt: • ISO 9000-Standards, insbes. ISO 9000-3 für die Software-Entwicklung • ISO 12207 • ISO 15504, der sogenannte SPICE-Standard (SPICE: Software Process Improvement and Capability dEtermination) • CMM / CMMI des Software Engineering Institutes der Carnegie Mellon University (CMMI: Capability Maturity Model Integration) Die zunehmende Relevanz und Aktualität prozessorientierten Qualitätsmanagements für die Software-Industrie wird beispielsweise daran deutlich, 145 dass sich die führenden deutschen Automobilhersteller (Daimler-Chrysler, Volkswagen, Audi, BMW und Porsche) 2003 zu einer Hersteller-Arbeitsgruppe zusammengeschlossen haben mit dem Ziel, auf Basis des SPICE-Standards einen an die Automobil-Industrie angepassten Prozesstandard zu definieren, der sowohl von ihnen selbst wie von allen Zulieferfirmen für ihre Autos bei der SoftwareEntwicklung einzuhalten ist. Die Initiative hat unter der Bezeichnung ‚HerstellerInitiative Software die bisherigen Ergebnisse im Internet unter der Adresse http://www.automotive-his.de/ bereitgestellt. Charakteristisch für SPICE und CMMI ist, dass zwei Dimensionen bei der Betrachtung der Entwicklungsprozesse unterschieden werden: die Prozessdimension und die Fähigkeitsdimension: • Die Prozessdimension enthält einen Katalog wichtiger Prozesse, die im Bereich der Software-Entwicklung eine Rolle spielen. Insgesamt werden von SPICE 5 Prozessgruppen mit insgesamt 40 Einzelprozessen definiert. • In der Fähigkeitsdimension wird für jeden Prozess bewertet, wie gut er umgesetzt wird. Die Güte der Umsetzung wird auch als Reife oder Capability-Level bezeichnet. Insgesamt werden von SPICE 6 CapabilityLevels definiert mit insgesamt 9 Fähigkeitsbereichen, den sogenannten Process Attributes. Damit entsteht eine Matrix, bei der für jeden Einzelprozess eine individuelle Bewertung der erreichten Fähigkeitsstufe möglich ist. Dieser Gesamtzusammenhang ist in der folgenden Abbildung graphisch dargestellt: Quelle: Qualität und Informatik, www.itq.ch Wichtig ist in diesem Zusammenhang, dass es durchaus möglich ist, dass eine Software-Entwicklungsorganisation bei einem Einzelprozess einen hohen Reifegrad haben kann und bei einem anderen Einzelprozess einen ganz niedrigen Reifegrad. Damit werden sehr differenzierte Fähigkeitsprofile für SoftwareEntwicklungsorganisationen möglich, wie im folgenden Beispiel dargestellt. 146 Beispielsweise ist es denkbar, dass eine Firma sowohl Prozesse zur Anforderungsanalyse definiert hat und spezielle Prozesse zum Software Entwurf einsetzt. Während beispielsweise der Software Entwurf bereits sehr gut etabliert ist, kann sie im Bereich Anforderungsanalyse noch ganz am Anfang stehen. Insgesamt lässt sich dadurch ein sehr individuelles Fähigkeitsprofil für die einzelne Firma erstellen und gezielte Verbesserungsmaßnahmen für einzelne Prozessbereiche ableiten, wie in der nachfolgenden Abbildung anschaulich dargestellt wird: Quelle: Qualität und Informatik, www.itq.ch Am dargestellten Beispiel wird auch der Nutzen eines prozessorientierten Qualitätsmanagements für die Software-Entwicklung auf Basis von SPICE oder CMMI deutlich: Mithilfe der in SPICE formulierten Prozessgebiete und den darauf bezogenen Reifegradstufen ist es möglich, das Reifegradmodell einer ganzen SoftwareEntwicklungs-Organisation systematisch, differenziert und nachvollziehbar zu bewerten. Auf der Basis des Assessment-Ergebnisses kann die SWEntwicklungsorganisation gezielte Verbesserungsprogramme in den Feldern anstoßen, wo sie den größten Nachholbedarf hat. Außerdem kann sie sich, wenn sie gewisse Levels erreicht hat, als Zulieferer für andere große Firmen oder z.B. für die öffentliche Hand qualifizieren. Normen wie SPICE oder CMMI liefern damit zusammenfassend: • ein inhaltliches Referenzmodell, welche Prozesse inhaltlich zu einem guten Software-Entwiclungsprozess gehören • bewährte und objektive Bewertungsmaßstäbe, um festzustellen, wie gut einzelne Prozesse durchgeführt werden • Hinweise für Ansatzpunkte, um gezielte Verbesserungen in den Software Entwicklungsprozessen zu erreichen. In den folgenden Abschnitten werden diese Aspekte im einzelnen vorgestellt. Da CMMI und SPICE inhaltlich zueinander konsistent sind und der gleichen Grundstruktur folgen, wird im folgenden das SPICE-Modell detaillierter betrachtet. Zunächst erfolgt eine detaillierte Darstellung des Prozessmodells von SPCIE (ISO 147 15504 / 12207). Danach werden das durch SPICE definierte Reifegradmodell und aufgrund seiner besonderen Bedeutung das Risikomanagement gemäß SPICE vorgestellt, bevor aufgezeigt wird, wie beide Aspekte zusammen (Prozess- und Reifegrad-Dimension) für sogenannte Assessments eingesetzt werden können. Zum Abschluß erfolgt ein kurze Einführung von CMM / CMMI und ein Vergleich der beiden Ansätze CMMI und SPICE. 4.8.2 Das ISO 15504 / ISO 12207 (SPICE) Prozessmodell Die ISO 15504 beschreibt ein detailliertes Prozeßmodell für die Softwareentwicklung. Die Prozeßbeschreibung enthält für jeden Prozeß den Zweck des Prozesses, die Ergebnisse, die mit dem Prozeß erreicht werden, die Grundtätigkeiten, die auszuführen sind, um die Ziele zu erreichen, und eine Beschreibung der Eingangsinformationen und Arbeitsergebnisse (Workproducts) jedes Prozesses. Es werden insgesamt 40 Einzelprozesse in 5 Kategorien beschrieben. Die Prozesse werden in 3 Gruppen eingeteilt: • Primäre Lebenszyklus Prozesse (Primary life cycle processes) mit den Kategorien • Kunden - Lieferanten Prozesse • Engineering Prozesse • Unterstützende Lebenszyklus Prozesse (Supporting life cycle processes) mit der Kategorie • Support • und organisatorische Lebenszyklus Prozesse (Organization life cycle processes) mit den Kategorien • Managment • Organisation E n g in e e rin g M anagem ent O rg a n is a tio n 148 S u p p o rt K u n d e n - L ie fe ra n te n Prozesse des Primären Lebenszyklus P r im a r y l i f e c y c l e p r o c e s s e s C u s to m e r- S u p p lie r C U S .1 A c q u is it io n C U S .2 S u p p ly C U S .4 O p e r a t io n A c q u is itio n P re p a r a tio n S u p p lie r S e le c tio n S u p p l i e r M o n it o r i n g C u s to m e r A cc e p ta n ce O p e r a tio n a l U s e C U S .3 R e q u i r e m e n t s E l ic i t a t i o n C u s to m e r S u p p o rt E n g in e erin g E N G .1 D e ve lo p m e n t S y s te m re q u ir e m e n ts a n a l y s is a n d d e s i g n S o f tw a r e in t e g r a t io n S o f tw a r e re q u ir e m e n ts a n a ly s is S o ft w a re t e s t in g S o ft w a r e d e s ig n S o ft w a r e c o n s tr u c t io n E N G .2 S y s t e m in te g r a t io n a n d t e s t in g S y s t e m a n d s o f t w a r e m a i n te n a n c e 4.8.2.1 Die Kunden Lieferanten Kategorie (CUS) CUS.1 Acquisition Process Der Zweck des Aquisitionsprozesses ist es Produkte oder Dienstleistungen zu kaufen, die den Bedarf des Kunden erfüllen. Er beginnt mit der Identifikation der Anforderungen und endet mit der Akzeptanz des Produktes oder der Leistung die der Kunde benötigt. Der Prozeß besitzt 4 weitere Unterprozesse CUS.1.1 Acquisition Preparation Process 149 Der Zweck des Akquisitions Vorbereitungs Prozesses ist es den Bedarf und die Ziele der Akquisition zu ermitteln, die Anforderungen aufzuschreiben, eine Einkaufsstrategie zu entwickeln und Akzeptanzkriterien zu definieren CUS.1.2 Supplier Selection Process Ziel des Lieferantenauswahlprozesses ist es eine Organisation zu finden, die für die Implementierung des gewünschten Produkts verantwortlich ist. Aufgabe ist es eine Ausschreibung zu erzeugen, den Lieferanten auf Grund seines Angebots und seiner Fähigkeiten auszuwählen und einen Vertrag zwischen Kunden und Lieferanten zu etablieren CUS.1.3 Supplier Monitoring Process Der Zweck des Monitoring Prozesses ist es die Aktivitäten des Lieferanten und den technischen Fortschritt während der Entwicklung durch gemeinsame Aktivitäten und die Kontrolle von regelmäßigen Informationen zu überwachen. CUS.1.4 Customer Acceptance Process Der Zweck des Akzeptanz Prozesses ist es zu überprüfen, ob das gelieferte Produkt oder die gelieferte Leistung allen definierten Kriterien und den gestellten Anforderungen entspricht CUS.2 Supply Process Der Zweck des Lieferprozesses ist es dem Kunden Software zur Verfügung zu stellen, die den vereinbarten Anforderungen genügt. Dazu gehört ein Angebot auf die Anfrage des Kunden, der Abschluß eines Vertrags zwischen Kunde und Lieferant über Entwicklung, Lieferung und Installation von Software, die Entwicklung einer Software, die den Anforderungen genügt, und die Lieferung und Installation der Software CUS.3 Requirements Elicitation Process Die Aufgabe des Requirements Elicitation Prozesses (Sammlung von Anforderungen) ist es über den Lebenszyklus eines Produkts oder einer Dienstleistung die sich entwickelnden Anforderungen der Kunden zu ermitteln und damit eine Basis für neue Software oder neue Produkte zu schaffen. Dazu wird eine regelmäßige Kommunikation mit dem Kunden etabliert, es werden die Anforderungen der Kunden definiert und ein Mechanismus zur regelmäßigen Beobachtung der Kundenbedürfnisse geschaffen. Fortschritte durch sich ändernde Technologien und Kundenbedürfnisse werden beobachtet und der Einfluß berücksichtigt. CUS.4 Operation Process 150 Der Zweck des Operations Prozesses ist es die Software in ihrer vorgesehenen Umgebung zu betreiben und den Kunden durch Support zu unterstützen. Der Prozess besitzt zwei Unterprozesse: CUS.4.1 Operational Use Process Der Zweck des Operational Use Prozesses ist es der korrekte und effiziente Betrieb der Software.. Dazu gehören die Identifikation und Überwachung von Risiken bei der Einführung der Software, der eigentliche Betrieb der Software in ihrer vorgesehenen Umgebung und die Überprüfung, dass die Software Kapazitäten den Bedürfnissen des Kunden genügen. CUS.4.2 Customer Support Process Die Aufgabe des Customer Suppport Prozesses ist es einen Service auf einem akzeptierten Level einzurichten und zu unterhalten. Dazu gehören die Erfassung und Beobachtung der Servicebedürfnisse des Kunden, die regelmäßige Evaluierung der Kundenzufriedenheit mit Service und Produkt, die Durchführung des Supports durch Unterstützung des Kunden bei operationalen Problemen 4.8.2.2 Die Engineering Kategorie ENG.1 Development process Der Zweck des Enwicklungsprozesses ist es eine Menge von Anforderungen in ein funktionierendes Softwareprodukt oder ein softwarebasiertes System zu transformieren. Der Entwicklungsprozess besitzt insgesamt sieben Teilprozesse. Die Teilprozesse müssen dabei nicht sequentiell durchgeführt werden. Die ersten Grundtätigkeiten des Testprozesses und der Integrationsprozesse werden z.B. gleichzeitig mit dem Requirements Analyse Prozess durchgeführt. In einem Iterativen Vorgehensmodell oder in einem Spiralmodell werden die Prozesse zum Teil mehrfach durchlaufen. Der am häufigsten anzutreffende Entwicklungsprozeß 151 ENG.1.1 System requirements analysis and design process Die Aufgabe des System Requirements Analysis und Design Prozesses ist es die funktionalen und nicht funktionalen Anforderungen (Requirements) an das System zu erstellen, eine System Architektur zu beschreiben und eine Zuordnung von Anforderungen zu den Hauptelementen des Systems und zu den Releases des Systems zu treffen. ENG.1.2 Software requirements analysis process Die Aufgabe des Software Requirements Analysis Prozesses ist es die Anforderungen an die Softwarekomponenten zu erstellen. Dabei werden die Anforderungen Softwarekomponenten zugeordnet und die Interfaces zwischen den Komponenten beschrieben. Die Anforderungen werden analysiert, auf Korrektheit und Testbarkeit überprüft. Der Einfluß der Softwareanforderungen auf die Laufzeitumgebung wird verstanden. Eine Software Release Strategie wird entwickelt und ein Mechanismus zur Verfolgung der Anforderungen über den Entwicklungsprozeß wird etabliert. ENG.1.3 Software design process Die Aufgabe des Design Prozesses ist es ein Design für die Software zu entwickeln, das die Anforderungen erfüllt. Dabei ist ein architektonisches Design zu entwickeln, das die Haupt Software Komponenten beschreibt, es sind die internen und externen Schnittstellen jeder Softwarekomponente zu beschreiben und es ist ein detailliertes Design ist zu entwickeln, das Softwareeinheiten beschreibt, die implementiert und getestet werden können. Es ist die Konsistenz zwischen Anforderungen und Design nachzuweisen. ENG.1.4 Software construction process Die Aufgabe des Software Konstruktions Prozesses ist es ausführbare Softwareeinheiten zu produzieren, die dem Design und den Anforderungen entsprechen. Dazu sind Verifikationskriterien für die Software zu definieren, die Softwareeinheiten müssen erzeugt werden und es muss der Test gegen die Verifikationskriterien durchgeführt werden. ENG.1.5 Software integration process Die Aufgabe des Integrationsprozesses ist es die Softwareeinheiten zu größeren integrierten Einheiten zusammenzufügen. Dazu ist eine Integrationsstrategie zu entwicklen, die beschreibt in welcher Reihenfolge und zu welchen integrierten Einheiten die Software zusammengefügt wird, es sind Verificationskriterien für die integrierten Einheiten zu entwicklen, die integrierten Einheiten sind zu produzieren und gegen die Verifikationskriterien zu testen. Die Testergebnisse werden protokolliert. Es ist eine Regressionstest Strategie zu entwickeln, die angibt welche 152 Tests bei Fehler oder Änderungen an den Softwareeinheiten durchzuführen sind. Die Regressionstests sind bei Bedarf durchzuführen. ENG.1.6 Software testing process Der Software Test Prozeß testet die integrierte Software gegen die AkzeptanzKriterien der Software Anforderungen. Dazu werden Akzeptanz Kriterien entwickelt (zeitlich normalerweise parallel zum Software Requirements Analysis Prozess), die Tests werden gegen die Akzeptanz-Kriterien durchgeführt und die Ergebnisse protokolliert. ENG.1.7 System integration and testing process Der Zweck des System Integrationsprozesses ist es die Software mit anderen Komponenten (z.B. Hardware) zu integrieren um ein Gesamtsystem zu bekommen. Es sind eine Integrationsstrategie für das System und Akzeptanzkriterien zu entwickeln. Die Integration und die Tests sind durchzuführen durch Bildung von Systemaggregaten, bis das Gesamtsystem entstanden ist. Der Nachweis aller Anforderungen (funktionale, nicht-funtionale, operationale, Wartung) am Gesamtsystem ist durchzuführen und zu protokollieren. Eine Regressionsteststrategie für Änderungen an Systemkomponenten ist zu entwickeln und bei Bedarf durchzuführen. ENG.2 System and software maintenance process Die Aufgabe des System und Software Wartungsprozesses ist es die Änderungen, Weiterentwicklungen und den Ausfall von Komponenten auf Anforderung des Kunden zu managen. Die Ursache der Anforderungen können erkannte Probleme oder der Wunsch nach Verbesserung oder Anpassung sein. Das Ziel ist es das System oder die Software zu modifizieren oder zu entfernen bei gleichzeitigem Erhalt der Integrität der Kundenprozesse. Dazu ist eine Wartungsstrategie zu schaffen, die die Änderung, die Modifikation oder die Entfernung von Systemkomponenten berücksichtigt. Es sind die Rückwirkungen auf das bestehende System zu ermitteln. Es sind die Spezifikationen, Designs und Teststrategien zu erneuern. Die modifizierten Komponenten sind zu entwickeln und zu testen. Updates sind beim Kunden einzuspielen. Auf Anforderung sind Software und System in kontrollierter Form mit minimaler Störung des Kunden zu entfernen. 4.8.2.3 Die unterstützenden Prozesse 153 S u p p o r t i n g l i f e c y c le p r o c e s s e s S U P .1 D o c u m e n t a t io n P ro c e s s S U P .2 C o n fi g u r a t io n M a n a g e m e n t P ro c e s s S U P .3 Q u a l it y A s s u r a n c e P r o c e s s S U P .4 V e r i fi c a t i o n P ro c e s s S U P .5 V a li d a t i o n P r o c e s s S U P .6 J o in t R e v i e w P r o c e s s S U P .7 A u d it P ro c e s s S U P .8 P r o b le m R e s o lu t io n P ro c e s s Die unterstützenden Prozesse, sind Hilfsprozesse die im Rahmen der Durchführung anderer Prozesse an unterschiedlichen Stellen Unterstützung leisten. SUP.1 Documentation Process Die Aufgabe des Dokumentationsprozesses ist es Dokumente zu entwickeln und zu warten die Inhalte besitzen, die von anderen Prozessen oder Aktivitäten erzeugt werden. Dazu gehört die Entwicklung einer Strategie zur eindeutigen Identifikation von Dokumenten, die Benennung von Standards zur Erzeugung von Dokumenten, die eindeutige Identifikation von Dokumenten, die Definition des Inhalts und Zwecks von Dokumenten, die Sicherstellung, dass die Dokumente den angegebenen Standards entsprechen und die Sicherstellung der Wartung von Dokumenten. Der Dokumentationsprozeß ist ein Prozeß der die Prozessattribute auf Fähigkeitslevel 2 (ISO15504) unterstützt. SUP.2 Configuration Management Process Der Zweck des Konfigurationsmanagement Prozesses ist die Einführung und Erhaltung der Integrität von allen Arbeitsergebnissen eines Projekts. Dazu ist eine Konfigurationsmanagementstrategie zu entwickeln, alle Arbeitsergebnisse eines 154 Prozesses oder Projekts sind zu identifizieren, und zu versionieren, Modifikationen und Releases sind zu kontrollieren, der Status und die Änderungsanforderungen werden protokolliert, die Vollständigkeit und Konsistenz wird sichergestellt und die Speicherung und Auslieferung von Arbeitsergebnissen wird kontrolliert. SUP.3 Quality Assurance Process Zweck des Qualitätssicherung Prozesses ist es sicherzustellen, dass die Arbeitsergebnisse und Tätigkeiten eines Prozesses oder Projekts den Anforderungen genügen und den Plänen entsprechen. Dazu wird eine Strategie zur Leitung der Qualitätssicherungsaktivitäten und Aufgaben entwickelt, durchgeführt und gewartet. Es wird sichergestellt, dass die Qualitätssicherungs-Aktivitäten und Aufgaben nachvollziehbar sind. Es wird verifiziert, dass die Software-Produkte, Prozesse und Aktivitäten den anwendbaren Standards, Prozeduren und Anforderungen genügen. Der Qualitätssicherungsprozess muss unabhängig sein und es sollte keine direkte Abhängigkeit zu Personen existieren, die die Software entwickeln oder die Entwicklung steuern. Der Qualitätssicherungsprozeß benutzt zur Durchführung weitere Support Prozesse wir Verification, Validation, Joint Reviews, Audits und den Problem Lösungs Prozeß. Die Durchführung des Qualitätssicherungsprozesses ist notwendig für alle primären Prozesse um den Reifegrad 2 zu erhalten. SUP.4 Verification Process Der Zweck des Verifikationsprozesses ist es, zu gewährleisten, dass alle Arbeitsergebnisse oder Dienstleistungen eines Prozesses oder Projektes den Anforderungen genügen. Dazu wird eine Strategie entwickelt, es werden Verifikationskriterien für alle Produkte definiert und die Produkte gegen diese Kriterien geprüft. Die Ursachen der identifizierten Defekte werden gesucht und beseitigt. Die Ergebnisse werden protokolliert und dem Kunden zugänglich gemacht. Dieser Prozeß ist eng verbunden mit dem Integrations- und dem Testprozeß, aber auch alle anderen Prozesse die Arbeitsergebnisse erzeugen werden durch diesen Prozeß unterstützt. Auch Requirementsdokumente, Designs und Projektpläne sind Arbeitsergebnisse, für die Qualitätskriterien gelten. SUP.5 Validation Process Der Zweck des Validationsprozesses ist es sicherzustellen, dass ein Produkt oder die Arbeitsergebnisse die Anforderungen für die gewünschte Anwendung erfüllt. Im Gegensatz zum Verifikationsprozeß, der die Konformität mit den gestellten Anforderungen (Requirements) nachweisen soll, wird hier überprüft, ob das daraus entstandene Produkt auch die gewünschte Anwendungsaufgabe erfüllt. Dazu ist 155 eine Validationsstrategie zu entwicklen, die Aktivitäten sind durchzuführen und zu protokollieren. Die gefundenen Probleme werden gelöst. Dieser Prozeß ist eng gekoppelt mit der Ausführung des System Integrations- und Test Prozesses. SUP.6 Joint Review Process Der Zweck des Joint Review Prozesses ist es ein gemeinsames Verständinis mit dem Kunden über den Fortschritt der Entwicklungsprojekts zu gewinnen. Joint Reviews gibt es sowohl auf dem Management als auch auf dem technischen Level und sie werden über die gesamte Projektlaufzeit in regelmäßigen Abständen und an vordefinierten besonderen Meilensteinen durchgeführt. Dabei werden der Status und die Ergebnisse von Prozessen durch gemeinsame Reviews von Kunden, Entwicklern, Zulieferern und anderen interessierten Teilen begutachtet. Aus den Reviews werden Maßnahmen abgeleitet und diese werden bis zu ihrer Erfüllung verfolgt. Dieser Prozeß ist eine unterstützender Prozeß für das Projektmanagement Attribut von Prozessen auf Level 2 der Fähigkeitenskala SUP.7 Audit Process Der Auditprozeß gewährleistet die unabhängige Beurteilung von Produkten, Prozessen, Anfoderungen, Plänen und Verträgen. Die Audits werden an vordefinierten Meilensteinen durch eine geeignete, unabhängige Partei durchgeführt, die Probleme werden protokolliert und kommuniziert. Die Probleme werden durch die für die Beseitigung verantwortliche Partei gelöst. Mögliche Audits für den Softwareentwicklungsprozeß sind • Der Vertrag genügt den Anforderungen der Organisation 4 Die Systemspezfikation genügt den Requirements 5 Das Design genügt der Spezifikation 6 Das Softwareprodukt entspricht dem Design 7 Die Testabdeckung entspricht den Qualitätssicherungsanforderungen 8 Die Qualität des Softwareprodukts entspricht den Standards der Organisation 9 Die Dokumentation stimmt mit den Kundenanforderungen überein Mögliche Audits für die Managementaktivitäten 1 Angebot im Vergleich zu Anforderungen 2 Erreichte Fortschritte im Vergleich zu Projekt- und Zeitplan 3 Risiko Kontrolle 4 Einhaltung von angemessenen Standards Besonders wichtig ist die Unabhängigkeit und fachliche Qualifikation der Auditoren, die auch eine weitgehende finanzielle Unabhängigkeit voraussetzt. Eine Beauftragung des Auditors durch den Lieferanten (ISO9000) kann dies kaum gewährleisten. 156 SUP.8 Problem Resolution Process Die Aufgabe des Problem Lösungs Prozesses ist es, sicherzustellen, dass alle entdeckten Probleme analysiert und gelöst werden. • Grundaufgaben dieses Prozesses sind die Einrichtung eines Problem Report Systems, • die Priorisierung von Problemen, • die Definitionen von Aktionen zur Behebung von Problemen, • die Verfolgung der Aktionen, • die Verteilung der Lösungen nach Review und Freigabe und • die Analyse von Problem Trends. 157 Die Organisations-Prozesse O rg a n iz a tio n a l life c y c le p ro c e s s e s M anag em ent M A N .1 M an ag e m e n t Pro ce s s M A N . 2 P r o je c t M a n a g e m e n t P r o c e s s M A N . 3 Q u a l it y M a n a g e m e n t M A N . 4 R is k M a n a g e m e n t O r g a n i z a t io n O R G .1 O r g a n i z a t i o n a l a l ig n m e n t p r o c e s s O R G .2 I m p rov e m e n t p ro ce s s P r o c e s s e s t a b li s h m e n t p r o c e s s P roc e ss a ss e ss m e n t p ro c e s s P r o c e s s im p r o ve m e n t p r o c e s s O R G .3 H u m a n R es o u rc e M an ag e m e n t p ro ce s s O R G .4 I n f ra s tr u c t u re p r o c e s s O R G .5 M ea s u re m e n t Pro ce s s O R G .6 R e u se Pro ce s s 4.8.2.4 Die Management Prozess Kategorie In der Managment Prozess Kategorie befinden sich Prozesse mit generischen Tätigkeiten, die von jedem anderen Prozess im Software Lebenszyklus benutzt werden können. 158 MAN.1 Management Process Die Aufgabe des Management Prozesses ist es den Start und die Durchführung jeglichen Prozesses oder Funktion zu initieren, zu überwachen und zu steuern, so dass sie ihre Ziele effektiv erreichen. • Dabei werden die Aktivitäten und Aufgaben, die Durchzuführen sind, um den Zweck des Prozesses zu erreichen, identifiziert, • es wird die Machbarkeit der Ziele mit den vorhandenen Ressourcen und Randbedingungen evaluiert, • die Ressourcen und Infrastrukturen werden zur Verfügung gestellt, • Aktivitäten und Aufgaben werden gestartet, • die Performance der Aktivitäten wird überwacht, • die Arbeitsprodukte werden überprüft und die Ergebnisse analysiert und evaluiert, • Aktionen zur Änderung der Performance bei Abweichungen werden durchgeführt • und die erfolgreiche Durchführung des Prozesses wird nachgewiesen. MAN.2 Project Management Process Der Projektmanagement Prozeß ist die spezielle Ausprägung von MAN.1 für Projekte. Die Aufgabe des Projekt Management Prozesses ist es alle Aufgaben, Aktivitäten und Ressourcen, die notwendig sind um ein Produkt oder eine Dienstleitung zu erhalten, zu identifizieren, einzurichten, zu koordinieren und zu überwachen. Dazu wird der Rahmen der Arbeit des Projektes definiert Die Machbarkeit des Ziels des Projekts mit vorhandenen Ressourcen und Randbedingungen evaluiert, Die Aufgaben und Ressourcen, die notwendig sind um die vollständige Arbeit zu erledigen werden in ihrer Größe geschätzt Die Schnittstellen zwischen dem Projekt und anderen Projekten oder organisatorischen Einheiten werden identifiziert und überwacht Pläne für die Ausführung des Projekts werden entwickelt und umgesetzt Der Fortschritt des Projekts wird beobachtet und berichtet Aktionen zur Korrektur von Abweichungen und zur Vermeidung der Wiederholung von Problemen werden durchgeführt, wenn die Projektziele nicht erreicht werden Der Projektmanagement Prozeß ist ein generischer Prozeß, der in anderen Prozeß wieder auftaucht. Die Grundaufgaben des jeweiligen Prozesses sind die zu planenden Aktivitäten im Projektmanagement. Eine Überprüfung dieses Prozesses bedeutet daher die Kontrolle ob jeder primäre Prozesse mindestens auf 159 Fähigkeitenlevel 2 sich befindet, dann befindet sich der Managementprozeß auf Level 1, d.h. er ist durchgeführt. Projektmanagement setzt daher die genaue Kenntnis der zu managenden Grundprozesse voraus, ihrer Grundtätigkeiten und ihrer Arbeitsprodukte. Der universelle Projektmanager, der nur Erfahrungen in Projektmanagement besitzt ist daher nicht möglich. MAN.3 Quality Management Die Aufgabe des Qualitätsmanagements ist es die Qualität der Produkte oder Dienstleistungen eines Projekts zu überwachen, so dass sie den Kunden zufrieden stellen. Dieser Prozeß geht über die Qualitätssicherung von SUP.3 hinaus. Er setzt die Messung der Qualität sowohl von Produkten als auch von Prozessen mit Hilfe von Metriken voraus, mit deren Hilfe eine Steuerung der Qualität möglich ist. MAN.4 Risk Management Die Aufgabe des Risikomanagement Prozesses ist es Projektrisiken kontinuierlich über den gesamten Lebenszyklus zu identifizieren und zu vermeiden. Dazu gehört die Identifikation, Analyse und Priorisierung von Risiken, die Planung und Durchführung von Maßnahmen zur Risikovermeidung, die Verfolgung von Risiken und die Durchführung von Korrektiven Aktionen wenn die Risikovermeidung nicht funtioniert. 4.8.2.5 Die Organisations Prozeß Kategorie Die Organisationsprozesse sind Prozesse die einer Organisation helfen die Geschäftsziele als ganzes zu erreichen. Die Organisationsprozesse sind notwendig zur Erreichung der Reifegradstufen 3-5, d.h. sie unterstützen die Wiederholbarkeit von Projekten (ORG.2.1, ORG.3, ORG.4) die Steuerbarkeit von Prozessen durch Messungen (ORG.1, ORG.5) und die Optimierung von Organisation und Prozessen (ORG.2.3, ORG.1) ORG.1 Organizational alignment process Der Zweck des Organizational Alignment Prozesses ist es, daß alle Mitarbeiter einer Organisation eine gemeinsame Vision, Kultur und Verständnis der Geschäftsziele haben. ORG.2 Improvement process Das Ziel des Improvement Prozesses ist es einen Software Lifecycle Prozeß zu etablieren, zu überwachen, zu steuern und zu verbessern. • Dazu gehört die Einrichtung einer Standardmenge von Prozessen, 160 • die detaillierten Aufgaben und Arbeitsergebnisse der Prozesse sind beschrieben, • zusammen mit erwarteten Performance Charakteristiken, • es existiert eine Strategie zur Anpassung der Prozesse an die Projektgröße (Tailoring) • es existiert eine Beschreibung zur Benutzung der Prozesse ORG.2.1 Process establishment process Die Aufgabe des Process Establishment Prozesses ist die Einrichtung eines Satzes von Standardprozessen für den Software Lebenszyklus ORG.2.2 Process assessment process Der Prozess Assessment Prozeß untersucht die Standard Softwareentwicklungsprozesse mit Hilfe von Assessments und deckt Schwachstellen auf. Die relativen Stärken und Schwächen der Standardprozesse geben Informationen für einen kontinuierlichen Verbesserungsprozeß ORG.2.3 Process improvement process Der kontinuierliche verbesserungsprozeß hat die Aufgabe durch kontrollierte Änderung der Standards die Effektivität und Effizienz der Prozesse, die in einem Unternehmen genutzt werden, ständig zu erhöhen. ORG.3 Human Resource Management process Der Zweck des Human Resource Management Prozesses ist es der Organisation und den Projekten zu genügend ausgebildete Mitarbeiter zur Verfügung zu stellen, die Fähigkeiten und Wissen besitzen um ihre Rolle effektiv zu erfüllen und als Gruppe zusammenarbeiten zu können. Dazu gehört die Identifikation der benötigten Fähigkeiten und des benötigten Trainings und die Durchführung des Trainings. ORG.4 Infrastructure process Die Aufgabe des Infrastrukturprozesses ist es eine stabile und verlässliche Infrastruktur aus Hardware, Software, Tools, Standards, Methoden, Techniken und Gebäuden für Entwicklung, Betrieb und Wartung zur Verfügung zu stellen. ORG.5 Measurement Process Das Ziel des Mess-Prozesses ist es Daten, die Produkte und die Prozesse einer Organisation betreffend, zu sammeln und zu analysieren um das Management der Prozesse effektiv zu unterstützen und die Qualität der Produkte zu demonstrieren. 161 ORG.6 Reuse Process Die Aufgabe des Reuse Prozesses ist es die Wiederverwendung von existierenden und neuen Softwareprodukten zu fördern und zu unterstützen. Dazu gehört die Entwicklung einer Wiederverwendungsstrategie und die Einrichtung und Wartung einer Infrastruktur für Wiederverwendung 4.8.2.6 Prozeß Tailoring Eine der wichtigsten Aufgaben zu Anfang eines jedes Projektes ist das Prozeßtailoring des Prozeßmodells. Die Komplexität von Softwareprojekten ist sehr unterschiedlich und kann vom kleinen Hilfsprogramm, das in einer Stunde entwickelt ist bis zum Großprojekt mit 100 Mannjahren Entwicklungsaufwand reichen. Die Aktivitäten müssen daher dem jeweiligen Projekt angepasst werden. Diesen Prozeß nennt man Prozeß-Tailoring (Tailor=Schneider). Grundsätzlich gilt die Regel: Je höher die Komplexität einer Aufgabe desto höher muß die Prozeßqualiät sein. Das Tailoring erfordert normalerweise sehr viel Erfahrung im entsprechenden Bereich. Viele Projekte scheitern, weil den Projektleitern eben diese Erfahrung fehlt und sie deshalb wichtige Tätigkeiten weglassen oder die Qualität von Arbeitsergebnissen nicht sicherstellen. Trotzdem ist zu beachten, dass auch der umgekehrte Fall vorkommen kann, dass ein Projekt scheitert, weil die Prozesse zu umfangreich sind. Dies Fall tritt aber nur sehr selten auf. Ausserdem gilt, dass gute Softwareentwicklungsprozesse eine Voraussetzung für den Erfolg sind, aber keine Garantie. Die Umkehrung gilt aber fast immer: Wenn die Entwicklungsprozesse in einem großen Projekt nicht ausreichend sind, wird das Projekt ein Mißerfolg! 4.8.3 Das ISO 15504 / ISO 12207 Reifegradmodell Wie oben bereits kurz dargestellt, ist das ISO 15504-Schema zweidimensional strukturiert, nämlich in die Prozess- und in die Reifegrad-Dimension: In der Process Dimension werden die für einen guten Software-Entwicklungsprozess geforderten Einzelprozesse beschrieben (vgl. vorigen Abschnitt). In der Capability Dimension werden verschiedene Reifegradstufen bei der Ausführung dieser Einzelprozesse unterschieden, wie in der folgenden Abbildung dargestellt wird: 162 Zur Einstufung eines Einzelprozesses in eine bestimmte Reifegradstufe werden sogenannte Prozessattribute (process attributes) herangezogen. Prozessattribute sind objektiv beobacht- und messbare Qualitätseigenschaften bei der Durchführung von Software-Entwicklungsprozessen. Prozessattribute stellen für jeden betrachteten Einzelprozess einen Bewertungsmaßstab dar für die darin erreichte Reife. Insgesamt werden von SPICE 6 Reifegradstufen (Capability Levels) mit zusammen 9 Gruppen von Prozessattributen (Process Attributes) unterschieden: Reifegradstufen und Prozess-Attribute gemäß ISO 15504-2 Process Attribute ID PA 1.1 PA 2.1 PA 2.2 PA 3.1 PA 3.2 PA 4.1 PA 4.2 PA 5.1 PA 5.2 Capability Levels and Process Attributes Level 0 : Incomplete process Level 1 : Performed process Process performance Level 2 : Managed process Performance management Work product management Level 3 : Established process Process definition Process resource Level 4 : Predictable process Measurement Process control Level 5 : Optimizing process Process change Continuous improvement Die einzelnen Reifegradstufen sind wiederum so abgestuft, dass der Fortschritt von einer zur nächsten Stufe jeweils eine signifikante Verbesserung in der Durchführung des betrachteten Einzelprozesses darstellt. Die Stufenabfolge insgesamt stellt daher einen schrittweisen Verbesserungsprozess gemäß ISO/IEC TR 15504-2 dar.: 163 Quelle: Qualität und Informatik, www.itq.ch Capability Levels als Roadmap für einen Verbesserungsprozess Im folgenden werden die einzelnen Reifegradstufen mit den Prozessattributen vorgestellt. Danach wird am Beispiel des Prozessbereichs Projektmanagement illustriert, wie die Anforderungen an die Beherrschung des Projektmanagements von Capability-Level zu Capability-Level zunehmen. In analoger Weise werden für alle von SPICE geforderten Einzelprozesse stufenweise zunehmende Anforderungen an die Beherrschung der Einzelprozesse von Capability-Level zu Capability-Level definiert. 4.8.3.1 Stufe 0 - Unvollständiger Prozess (Incomplete) Kurzbeschreibung: Es gibt nur wenige oder gar keine klar beschriebenen Ziele und Arbeitsergebnisse des Prozesses. Es ist deshalb nicht feststellbar, ob der Prozess überhaupt greifbare Ergebnisse bringt und es ist davon auszugehen, dass der Prozess nicht verstanden ist. Prozessattribute: Für die Stufe 0 gibt es keine speziellen Prozessattribute. Bei Prozessen der Stufe 0 ist unklar, wie das Ergebnis überhaupt zustande kam 164 4.8.3.2 Stufe 1 - Durchgeführter Prozess (Performed) Kurzbeschreibung: Der Gesamtprozess ist weitgehend verstanden. Die Zielsetzung und die Ergebnisse des Einzelprozesses wird in der Regel erreicht. Die Zielerreichung wird in der Regel jedoch nicht systematisch geplant und kontrolliert. Einzelpersonen innerhalb der Organisation erkennen, dass gewisse Aktionen durchgeführt werden müssen. Es ist allgemein akzeptiert, dass diese Aktion dann durchgeführt wird, wenn es notwendig ist. Die Einzelheiten des Prozesses zwischen Prozessbeginn und Prozessende sind nicht bekannt. Prozesse der Stufe 1 sind in ihren inneren Details eine ‚Black-Box Prozessattribute: Auf Stufe 1 werden folgende Prozessattribute gefordert: PA 1.1 - Process performance attribute: Das Prozessattribut PA 1.1 stellt fest, in welchem Ausmaß der Prozess mit klar definierten Inputs klar definierte Ergebnisse erzeugt. Im einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 1 - Bereich PA 1.1 - folgende generischen Qualitätsmerkmale zu erfüllen: • MP 1.1.1: Identify input and output work products • MP 1.1.2: Ensure that the scope of work is identified • MP 1.1.3 Ensure that base practices are implemented. 4.8.3.3 Stufe 2 - Gelenkter Prozess (Managed). Kurzbeschreibung: Auf der Stufe 2 werden zwei Prozessattribute unterschieden: Work product management und Performance management. Der Einzelprozess liefert definierte Arbeitsergebnisse gemäß klarer Vorgehensweisen und ist in seiner Durchführung geplant sowie kontrolliert. Die Arbeitsergebnisse erfüllen spezifizierte (Qualitäts)Standards und Anforderungen. Der hauptsächliche Unterschied zur Stufe 1 ist neben der grundsätzlichen Transparenz des Gesamtprozesses, daß die Erstellung der Arbeitsergebnisse systematisch hinsichtlich Zeit, Qualität und Aufwand gelenkt 165 (managed), d.h. geplant und systematisch kontrolliert wird. ‚Außerdem sind Zuständigkeiten und Verantwortungen zugewiesen. Prozess der Stufe 2 folgen einer grob strukturierten systematischen Vorgehensweise Prozessattribute: Auf Stufe 2 werden zwei Gruppen von Prozessattributen gefordert, eine prozessbezogene (PA 2.1) und eine produktbezogene (PA2.2): PA 2.1 - Performance management attribute: Das Prozessattribut PA 2.1 stellt fest, in welchem Ausmaß der Prozess gelenkt wird, um Ergebnisse mit klar definierten Qualitätseigenschaften zu erzeugen. Im einzelnen sind von einem EinzelProzess zur Erreichung der Stufe 2 - Bereich PA 2.1 - folgende generischen Qualitätsmerkmale zu erfüllen: 3 MP 2.1.1: Identify the objectives for the performance of the process 4 MP 2.1.2: Plan the performance of the process according to the identified objectives 5 MP 2.1.3: Plan and assign the responsibility and authority for developing the work products 6 MP 2.1.4: Manage the execution of the activities by continued tracking and replanning. PA 2.2 - Work product management attribute: Das Prozessattribut PA 2.2 stellt fest, in welchem Ausmaß der Prozess gelenkt wird, um sicherzustellen, dass die erzeugten Produkte die gestellten Anforderungen hinsichtlich Dokumentation, Kontrolle und Qualitätssicherung vollständig erfüllen. Lokale (projektbezogene) Standards sind dafür definiert. Außerdem werden die Arbeitsergebnisse systematisch verwaltet und verifiziert. Im einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 2 - Bereich PA 2.2 - folgende generischen Qualitätsmerkmale zu erfüllen: MP 2.2.1: Identify the requirements for the work products (both functional and non-functional aspects). MP 2.2.2: Manage the documentation and configuration management MP 2.2.3: Identify and define any work product dependencies MP 2.2.4: Manage the quality of work products 4.8.3.4 Stufe 3 - Etablierter Prozess (Established). 166 Kurzbeschreibung: Auf der Stufe 3 werden zwei Prozessattribute unterschieden: Process definition und Process resources. Der Einzelprozess wird durchgeführt und gelenkt durch einen definierten Prozess auf der Basis guter Software Engineering Prinzipien. Individuelle Anpassungen des Prozesses nutzen genehmigte Varianten des Standardprozesses, um die definierten Prozessergebnisse zu erzeugen. Die Ressourcen zur Durchführung der definierten Prozesse sind ebenfalls vorhanden. Der hauptsächliche Unterschied zur Stufe 2 ist, dass auf Stufe 3 ein allgemein definierter Prozess organisationsweit verfügbar und im Einsatz ist, um die definierten Arbeitsergebnisse zu erreichen. Prozesse der Stufe 3 folgen einer organisationsweit standardisierten detaillierten Vorgehensweise Prozessattribute: Auf Stufe 3 werden zwei Gruppen von Prozessattributen gefordert, eine prozessbezogene (PA 3.1) und eine organisationsbezogene (PA3.2): PA 3.1: Process definition attribute Das Prozessattribut PA 3.1 stellt fest, in welchem Ausmaß der Prozess auf Standardprozesse zurückgreifen kann, um die geforderten Ergebnisse zu erzeugen. Im einzelnen sind von einem Eizelprozess zur Erreichung der Stufe 3 - Bereich PA 3.1 - folgende generischen Qualitätsmerkmale zu erfüllen: • MP 3.1.1: Identify the standard process that supports the execution of the managed process • MP 3.1.2: Implement and / or tailor the standard process • MP 3.1.3: Gather process performance data • MP 3.1.4: Establish and refine the understanding of the process behaviour by using process performance data • MP 3.1.5: Refine the standard process PA 3.2: Process resource attribute Das Prozessattribut PA 3.2 stellt fest, in welchem Ausmaß der Prozess in der Organisation auf angemessene Ressourcen, vor allem auf qualifizierte Mitarbeiter wie auf eine geeignete Basisinfrastruktur zurückgreifen kann. Letztlich geht es also darum, inwieweit der in PA 3.1 beschriebene Standardprozess auf 167 Organisationebene umgesetzt und mit ausreichenden Ressourcen versorgt ist. Im einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 3 - Bereich PA 3.2 - folgende generischen Qualitätsmerkmale zu erfüllen: • MP 3.2.1: Identify and document the roles, responsibilities and competencies rquired to support the implementation of the defined process • MP 3.2.2: Identify and document the process infrastructure requirements • MP 3.2.3: Provide, allocate and use the resources to support the performance of the defined process • MP 3.2.4: Provide, allocate and use an adequate process infrastructure. 4.8.3.5 Stufe 4 - Quantitativ steuerbarer und vorhersagbarer Prozess (Predictable) Kurzbeschreibung: Auf der Stufe 4 werden zwei Prozessattribute unterschieden: Process measurement und Process control. Der definierte Prozess wird durchgängig in der Praxis angewandt innerhalb definierter Schwankungsbreiten, um die definierten Prozessziele zu erreichen. Detaillierte Messwerte der Prozessdurchführung werden erhoben und ausgewertet. Dies führt zu einem quantitativen Verständnis der Prozessfähigkeiten und zu einer verbesserten Vorhersagbarkeit und Steuerung der Prozesse. Die Prozessleistung wird quantitativ gesteuert. Die Qualität der Produkte ist quantitativ erfasst. Der hauptsächliche Unterschied zur Stufe 3 ist, dass der definierte Prozess jetzt konsistent innerhalb definierter Grenzen durchgeführt wird, um die definierten Arbeitsergebnisse zu erreichen. Prozess der Stufe 4 werden quantitiativ überwacht und gesteuert Prozessattribute: Auf Stufe 4 werden zwei Gruppen von Prozessattributen gefordert, eine messungsbezogene (PA 4.1) und eine prozessbezogene (PA4.2): PA 4.1: Measurement attribute Das Prozessattribut PA 4.1 stellt fest, in welchem Ausmaß quantitative Zielvorgaben sowie Maße für den Prozess und die Produkte verwendet werden, um die Leistung und die Zielerreichung im Kontext der Geschäftsziele zu messen. Im 168 einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 4 - Bereich PA 4.1 - folgende generischen Qualitätsmerkmale zu erfüllen: • MP 4.1.1: Identify product and process goals and measures • MP 4.1.2: Collect the specified product and process measures through performing the defined process • MP 4.1.3: Analyze trends in the performance of the process across the organisation. • MP 4.1.4: Measure the process capability and maintain it within defined limits across the organisation. PA 4.2: Process control attribute Das Prozessattribut PA 4.2 stellt fest, in welchem Ausmaß der Prozess quantitativ kontrolliert und gesteuert wird, um die vorgegebenen Prozess- und Produktziele zu erreichen. Im einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 4 Bereich PA 4.2 - folgende generischen Qualitätsmerkmale zu erfüllen: • MP 4.2.1: Identify suitable measurement techniques • MP 4.2.2: Collect measures and identfy process control parameters in order to perform analysis • MP 4.2.3: Control the process performance using the analysis measures to identify actions to maintain control and/or implement improvement. 4.8.3.6 Stufe 5 - Optimierender Prozess (Optimizing). Kurzbeschreibung: Auf der Stufe 5 werden zwei Prozessattribute unterschieden: Process change und Process innovation. Die Leistung des Einzelprozesses ist optimiert, um laufende Geschäftsanforderungen zu erfüllen. Der Prozess ist soweit ausgereift, dass er mit konstanter Performance wiederholbar ist. Quantitative Prozesseffektivitäts- und -effizienzziele für die Leistung sind vorhanden und bauen auf den Geschäftszielen der Organisation auf. Die kontinuierliche Prozesskontrolle gegen diese Ziele wird ermöglicht durch quantitative Überwachung. Die Verbesserung wird erreicht durch die Analyse der Ergebnisse. Die Verbesserung und Optimierung beinhaltet die Pilotierung innovativer Ideen und Technologien und die Veränderung ineffektiver Prozesse, um definierte Ziele (besser) zu erreichen. Der hauptsächliche Unterschied zur Stufe 4 ist, dass der definierte Standardprozess jetzt dynamisch weiterentwickelt wird, um aktuelle und zukünftige Geschäftsanforderungen optimal zu erfüllen. 169 Prozess der Stufe 5 arbeiten an einer ständigen Verbesserung Prozessattribute: Auf Stufe 5 werden zwei Gruppen von Prozessattributen gefordert, eine innovationsbezogene (PA 5.1) und eine verbesserungsbezogene (PA5.2): PA 5.1: Process change attribute Das Prozessattribut PA 5.1 stellt fest, in welchem Ausmaß der Prozess selbst auf der Basis quantitativer Prozessinformationen kontrolliert Prozessänderungen definiert, umsetzt und durch Ergebniskontrolle im Sinne der relevanten Geschäftsziele lenkt. Im einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 5 - Bereich PA 5.1 - folgende generischen Qualitätsmerkmale zu erfüllen: • MP 5.1.1: Identify changes to the standard process definition on the basis of a quantitative understanding of the process • MP 5.1.2: Assess the impact of all proposed changes • MP 5.1.3: Define an implementation strategy for the approved change, ensuring that any disruption to the process performance is understood and acted upon. • MP 5.1.4: Implement the approved changes • MP 5.1.5: Evaluate the effectiveness of process change on the basis of actual performance. PA 5.2: Continuous improvement attribute Das Prozessattribut PA 5.2 stellt fest, in welchem Ausmaß der Prozess kontinuierliche Verbesserungsprozesse für die Erfüllung der übergeordneten geschäftspolitischen Zielvorgaben unterstützt. Im einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 5 - Bereich PA 5.2 - folgende generischen Qualitätsmerkmale zu erfüllen: • MP 5.2.1.: Define the process improvement goals for the process • MP 5.2.2: Analyse the source of real and potential problems in the current process, identifying improvement opportunities in a systematic and proactive manner to continuously improve the process. • MP 5.2.3: Implement changes to selected areas of the tailored process according to the implementation strategy. 170 • MP 5.2.4: Validate the effectiveness of process change on the basis of actual performance and add feedback to the standard process definition. Die folgende Abbildung fasst in kompakter Weise nochmals die von Level zu Level zunehmenden Anforderungen an die Prozessbeherrschung zusammen: Quelle: Qualität und Informatik, www.itq.ch 4.8.4 Anwendungsbeispiel Projektmanagement der ISO 15504/12207: Reifegradstufen im In diesem Abschnitt wird am Beispiel des inhaltlichen Prozessbereichs ‚Projektmanagement dargestellt, wie die Beherrschung und Professionalität beim Projektmanagement von Capability-Level zu Capability-Level zunimmt. Ausgangspunkt dazu sind die von der ISO 15504 für das Projektmanagement definierten Base-Practices, d.h. Kernfähigkeiten, die vom Projektmanagement inhaltlich abzudecken sind: MAN.2.BP1 : MAN.2.BP2 : MAN.2.BP3 : MAN.2.BP4 : MAN.2.BP5 : Define the scope of work. Determine development strategy Select software life cycle model. Size and estimate tasks and resources. Develop work breakdown structure. 171 MAN.2.BP6 : MAN.2.BP7 : MAN.2.BP8 : MAN.2.BP9 : MAN.2.BP10 : MAN.2.BP11 : MAN.2.BP12 : Identify infrastructure requirements. Establish project schedule. Allocate responsibilities. Identify interfaces. Establish and implement project plans. Track progress against plans. Act to correct deviations. Je nach Reifegradstufe sind diese Base-Practices in unterschiedlichem Umfang und Perfektion zu erfüllen. Im einzelnen sind die Base-Practice auf den verschiedenen Reifegradstufen sinngemäß in der im folgenden dargestellten abgestuften Weise zu beherrschen: Stufe 0: Ein Projektmanagement ist nicht vorhanden, es gibt nicht einmal einen klaren Entwicklungsprozess. Stufe 1: Der Entwicklungsprozess wird als Black-Box betrachtet. Klarheit über die vorhandenen Input-Produkte und über die zu erstellenden Output-Ergebnisse ist vorhanden. Da der Prozess aber ansonsten nicht transparent ist, sind weitere spezifische Anforderungen an das Projektmanagement nicht vorhanden. Stufe 2: Elementare Projektplanungstechniken für jedes Einzelprojekt sowie Einzelprojektverfolgung und -steuerung werden eingesetzt. 6. Zusätzlich zu Stufe 1: Zielsetzungen für die Leistung des Prozesses hinsichtlich Zeit und Aufwänden ist vorhanden. Es sind Aufwandskennzahlen sowie Schätzmethoden im Einsatz. Für die Planung werden Werkzeuge eingesetzt sowie Methoden wie z.B. kritische-Pfad-Methoden. Außerdem sind klare Zuordnungen von Aufgaben zu Ressourcen vorgenommen einschließlich Ergebnisverantwortung. Der Ergebnisfortschritt wird regelmäßig kontrolliert und berichtet. Stufe 3: Das Projektmanagement ist auf Organisationsebene definiert und wird als integriertes Projektmanagement gelebt. 1. Zusätzlich zu Stufe 2: Organisationsweite Standard für die Durchführung von Projekten sind vorhanden. Prozess- und Projektmessdaten werden regelmäßig erhoben und zentral gesammelt. Die erhobenen Daten werden zentral ausgewertet, auf Trends hin analysiert und für ein vertieftes Verständnis der laufenden Prozesse verwendet. Die verschiedenen für das Projekt relevanten Einzelpläne werden zu einem gemeinsamen Projektplan integriert (z.B.: Meilensteinplan, Budgetplan, Ressourcenplan, Qualitätsmanagementplan, Abnahmeplan usw.). Stufe 4: Ein quantitatives Projektmanagement ist organisationsweit etabliert. 1. Zusätzlich zu Stufe 3: Die Daten von Stufe 3 werden systematisch zur Steuerung der Projekte auf Organisationsebene verwendet. Es werden systematisch projektübergreifende Soll-Ist-Vergleiche hinsichtlich Zeit, 172 Aufwand und Ergebnisse durchgeführt. Dabei werden auch vordefinierte Zielgrößen (Benchmark) eingesetzt. Die Projektsteuerung erfolgt zunehmend unter Berücksichtigung der übergeordneten geschäftspolitischen Zielsetzungen. Das Projektreporting erfolgt daher analog auch anhand aggregierter management-gerechter Indikatoren, insbesondere Zeit, Kosten, Produktivität, Risikoindikatoren. Verfahren der statistischen Qualitätssicherungen können eingesetzt werden. Stufe 5: Laufende Optimierung und Innovation der Projektdurchführung und der Projektmanagementprozesse auf Basis quantitativer Grundlagen. 1. Zusätzlich zu Stufe 4: Neben die Steuerung der Projektdurchführung tritt die ständige Optimierung und Verbesserung des Projektmanagementprozesses selbst. Abweichungen von Zielvorgaben oder neue Benchmarks werden zum Anlass genommen, den derzeit gelebten Prozess auf Verbesserungsmöglichkeiten hin zu analysieren, die Verbessserungsansätze einzuführen und deren Auswirkungen systematisch zu beobachten. 4.8.5 Risikomanagement gemäß ISO 15504 / ISO 12207 Die Bedeutung von Risikomanagement Risiken sind ein unvermeidlicher Bestandteil jeder Software oder Systementwicklung. Der richtige Umgang mit den Risiken entscheidet in vielen Fällen über den Projekterfolg. Das Risikomanagment ist der Management Prozess, der kontinuierlich versucht zu erkennen, was in einem Entwicklungsprojekt falsch gehen könnte, die Schwere und die Eintrittswahr-scheinlichkeit der Ereignisse abschätzt und daraus versucht Managementmassnahmen abzuleiten. Das Ziel des Risiko Managements ist es also Projekt Risiken frühzeitig zu erkennen und mögliche Probleme abzuschwächen oder zu vermeiden. Risiko Management bestimmt dabei in starkem Maße das Life-Cycle Modell des jeweiligen SW Projekts. Die Grundaufgaben Zu den Grundaufgaben des Risikomanagements gehören die • Identifikation von Risiken • Die Analyse und Priorisierung von Risiken • Die Definition von Strategien um die Risiken zu managen • Die Definition von Metriken um die Risiken zu überwachen • Die Durchführung der Risiko Management Strategien • Die Beobachtung der Ergebnisse der Risiko Management Strategien mit Hilfe der definierten Metriken Die Durchführung von korrektiven Massnahmen, wenn die Risikovermeidung nicht erfolgreich ist. Identifikation von Risiken 173 Die Identifikation von Risiken erfolgt in einem ersten Schritt am Anfang des Projekts und wird in regelmäßigen Abständen wiederholt, da während eines Projektes neue Risiken entstehen können. Die Identifikation erfolgt am besten im Team durch moderierte Brainstormingsitzungen und durch systematische Suche nach Risiken mit Hilfe von Checklisten. Dabei ist zu beachten, daß Risiken ganz unterschiedliche Ursachen haben können. Eine Klassifikation [CMU/SEI-93-TR-6] unterscheidet zwischen Risiken des Product Engineerings, Risiken durch Prozeßund Arbeitsumgebung und Risiken durch externe Randbedingungen. Analyse und Priorisierung von Risiken In der Analyse von Risiken wird die Schwere des Schadens die das Eintreffen eines Risikos haben kann und die Eintrittswahrscheinlichkeit eines Riskos bewertet Schwere (S) der Konsequenzen bei Eintritt des Risikos (0) vernachlässigbar (-) gering (--) kritisch (---) katastrophal Eintrittswahrscheinlichkeit (E) (0) (-) (--) (---) unwahrscheinlich gering gelegentlich wahrscheinlich Aus Eintrittswahrscheinlichkeit und möglichem Schaden ergibt sich der Handlungsbedarf Handlungsbedarf Katastrophal Schwer e Kritisch Gering Vernachlässigb ar Eintrittswahrscheinlichkeit wahscheinlich gelegentlich gering unwahrscheinlich hoch hoch mittel kein Hoch Mittel Gering Kein mittel gering gering kein kein kein kein kein Strategien zum Management von Risiken Je nach Handlungsbedarf sind unterschiedliche Strategien zur Vermeidung der Folgen bei Eintritt von Risiken zu suchen 174 hoher Handlungsbedarf: Lösungen müssen präventiv gesucht werden. Bei Produktrisiken sind Prototypen zu planen und zu entwickeln und Alternativlösungen zu erproben. mittlerer Handlungsbedarf: QS-Maßnahmen sind einzuplanen. Alternativlösungen suchen Geringer Handlungsbedarf: Das Risiko ist zu beobachten. Für jedes Risiko mit Handlungsbedarf sind Aktivitäten und Ressourcen und Termine zu planen, die im Rahmen des Projektmanagements behandelt werden. Metriken zur Überwachung von Risiken Metriken zur Überwachung von Risiken sollten zumindest die Wahrscheinlichkeit für das Auftreten eines Risikos und die Größe des Schadens berücksichtigen. Dabei ist zu beachten, dass der Schaden bei fortschreitendem Projekt immer größer werden kann. Durchführung der Risikomanagment Strategien Die Durchführung des Risikomassnahmen erfolgt im Rahmen des Projektmanagements. Je nach Massnahme werden hierdurch andere Lifecyclemodelle bevorzugt. Projekte mit hohen technischen oder anderen Produktrisiken führen zu Prototypenenwicklungen im Rahmen von Spiralmodellen, Projekte mit hohen Prozessrisiken (umfangreiche Projekte) benötigen Iterative Modelle mit Prozessen hoher Qualität. Kleine Projekte mit geringen Risiken stellen dagegen kaum Anforderungen an das zugrundeliegende Lifecyclemodell. Der Bereich komplexer Projekte mit hohen technischen Risiken ist als sehr kritisch zu betrachten. Eine umfangreiche Prototypphase in der die wichtigsten Risiken geklärt werden, gefolgt von einem iterativen Vorgehensmodell zur Bewältigung der Komplexität ist ein mögliches Vorgehensmodell. 175 K o m p le x itä t / P r o z e ß r is ik e n P roze ßb eh errsc hu n g R is ik o S ic h e r e P r o je k te V o r e n t w ic k lu n g P r o d u k t R is ik e n / te c h n is c h e R is ik e n 4.8.6 Assessments gemäß ISO 15504 / ISO 12207 Die Zielsetzung der ISO 15504 (sowie von CMMI) ist, zur Verbesserung von Software-Entwicklungsprozessen beizutragen, um damit schließlich eine Verbesserung der Software-Produktqualität sowie eine Produktivitätsverbesserung bei den Entwicklungsprozessen zu erreichen. Die Bewertung des Reifegrades von Software-Entwicklungsprozessen findet in sogenannten Assessments statt. Dabei werden die zu untersuchenden Einzelprozesse gemäß des dargestellten Reifegradmodells bewertet:: 176 Quelle: Qualität und Informatik, www.itq.ch Die Reife eines Prozesses bestimmt sich dabei nach dem Erfüllungsgrad der Prozessattribute. Pro Prozess wird für die Prozessattribute nach Auswertung vorgegebener Checkfragen ein Erfüllungsgrad in einer vierstufigen Skala vergeben: Quelle: Qualität und Informatik, www.itq.ch Ein Capability-Level gilt als erreicht, wenn alle Prozessattribute darunterliegender Level voll erfüllt sind (Fully) und jene des betreffenden Levels größtenteils oder voll erfüllt sind (Largely oder Fully): Quelle: Qualität und Informatik, www.itq.ch 177 In der folgenden Tabelle wird zusammenfassend dargestellt, welche Bedingungen ein Einzelprozess erfüllen muß, wenn er auf einem bestimmten Level bewertet werden soll: Quelle: Qualität und Informatik, www.itq.ch Mithilfe dieser Bewertungsrichtlinien können dann für verschiedene Prozesse differenzierte Bewertungsprofile erstellt werden: Quelle: Qualität und Informatik, www.itq.ch Das Ergebnis eines solchen Assessments wird schließlich in aufbereiteter Form als Assessment-Bericht für die Software-Entwicklungsorganisation zur Verfügung 178 gestellt. Darin sind dann neben der Einstufung der Einzelprozesse auch weitere detaillierte Assessment-Ergebnisse enthalten, z.B. die Darstellung von Bereichen, in denen punktuell bereits Prozess-Attribute von höheren Reifegradstufen erreicht worden sind: Quelle: Qualität und Informatik, www.itq.ch 4.8.7 Das CMMI-Modell Das CMMI-Modell hat seinen Ursprung in den USA, wo das Verteidigungsministerium (DoD) in den 80er Jahren einen Kriterienkatalog für gute Software-Lieferanten bei der Vergabe von Software-Entwicklungsaufträgen entwickeln ließ. Ziel war, bei der Auftragsvergabe für Softwareprojekte einigermaßen sicher zu sein, dass der Auftragnehmer die Software wie versprochen in der vorgesehenen Zeit, im Budget und mit der zugesagten Qualität liefern kann. Dazu entwickelte 1987 das Software Engineering Institute der Carnegie Mellon University unter Leitung von Watts Humphrey die Idee, in der Industrie bewährte Praktiken ("best practices") in einem Referenzmodell für SoftwareEntwicklungsprozesse zu vereinen, das als Fragebogen eingesetzt werden sollte. Aus dieser Arbeit entstand 1991 das Capability Maturity Modell (CMM). Zur Unterscheidung von später entwickelten weiteren CMM-Modellen nannte man dieses Modell auch "Software CMM". Unternehmen konnten diese Praktiken adaptieren, um somit besser und erfolgreicher Software zu entwickeln und dabei schrittweise verschiedene Reifegradstufen erreichen. Ein Unternehmen konnte mittels eines Assessments untersucht und beurteilt werden, auf welcher Reifegradstufe es sich befindet. Nachdem das CMM in der Anfangszeit nur von Organisationen verwendet wurde, die vom DoD als Auftraggeber dazu gezwungen wurden, stellte sich bald heraus, dass auch der Auftragnehmer einen deutlichen Nutzen von einer solchen 179 Vorgehensweise hat. Eine Reihe von Unternehmen begann daher, das CMM freiwillig zur eigenen Prozessverbesserung zu nutzen. Es verbreitete sich von USA aus schließlich schnell in die ganze Welt. Die Anwendergemeinde umfaßt heute Tausende von (aufgrund der Durchführung offizieller Assessments) registrierten Unternehmen sowie eine unbekannte Anzahl von selbständigen Anwendern. Die Version 1.0 erschien im August 1991 und die verbesserte, heute noch gültige Version 1.1 im Februar 1993. Im Lauf der Jahre sind neben dem ursprünglichen Software CMM eine Reihe weiterer Reifegradmodelle für andere Anwendungsgebiete entstanden (wie z.B. People CMM, Software Acquisition CMM). Das CMMI (Capability Maturity Model Integration) ist nun der Nachfolger des CMM. Es wurde ebenfalls am Software Engineering Institute (SEI) der CarnegieMellon University in Pittsburgh im Auftrag des DoD entwickelt. In diesem neuen CMMI sind viele Erfahrungen und Verbesserungsvorschläge zum CMM eingeflossen. Die Anforderungen sind einheitlicher strukturiert und der Anwendungsbereich ist über die Softwareentwicklung hinaus erweitert worden. Außerdem wurde durch die Einführung der kontinuierlichen, d.h. einzelprozessbezogenen Reifegradbewertung, die Konsistenz zur ISO 15504 weitgehend erreicht. Das Nebeneinander verschiedener CMM-Modelle (SoftwareCMM, People-CMM etc.) wurde ebenfalls bereinigt. Alle Informationen zum CMM und zum CMMI sind öffentlich über das Internet erhältlich auf der Homepage des SEI unter der Adresse http://www.sei.cmu.edu. Das CMMI-Modell V1.1 ist veröffentlicht als CMU/SEI-2002-TR-001. Ein Ziel bei der Entwicklung des CMMI war, konform zu SPICE (ISO 15504) zu sein. Im großen und ganzen scheint dies auch gelungen, wobei zu ergänzen ist, dass die ISO 15504 bis heute (März 2004) noch nicht endgültig verabschiedet ist. Genauso wie die ISO 15504 hilft CMMI Softwareunternehmen bei der Verbesserung der eigenen Prozesse und zeigt auf, was für eine erfolgreiche Softwareentwicklung erforderlich ist. Durch die sechs Reifegradstufen wird ein mit ISO 15504 kompatibler Verbesserungspfad beschrieben. Die Vorgehensweisen von CMMI beruhen dabei ebenfalls auf praxisbewährten Best Practices und nicht auf einem theoretischen Modell. Eine detaillierte Darstellung der inhaltlichen Unterschiede würde über den Rahmen dieses Skriptes hinausgehen, ist jedoch auch angesichts der überschaubaren Differenzen nicht erforderlich. Wichtiger sind die Unterschiede beim organisatorischen Status und bei der Durchführung von Assessments: Status bei CMMI: CMMI bietet professionellen Support durch das Software Engineering Institute (SEI) an der Carnegie Mellon University in Pittsburgh. Hierzu gehören z.B. Schulungskurse, Lead Assessoren Kurse, die Registrierung von Lead Assessoren sowie von offiziell durchgeführten Assessments in einer Datenbank mit jährlichen statistischen Auswertungen. Eine Vielzahl von Informationen kann kostenlos von 180 der SEI Website (www.sei.cmu.edu) abgerufen werden, z.B. auch die verschiedenen CMMI Modelle. Das SEIR (Software Engineering Information Respository, http://seir.sei.cmu.edu/) bietet zudem eine große Menge von wertvollen Praxisinformationen und Beispielen zu den verschiedenen Software Engineering Themengebieten. Der Stellenwert des CMMI auch für die europäische Softwareindustrie dürfte durch die Gründung des SEI Europe in Frankfurt/Main (europäische Außenstelle des SEI) im Jahre 2003 noch zunehmen. CMMI gilt deshalb als ein sehr vielversprechendes Referenzmodell und es ist zu erwarten, dass sich die Benutzergemeinde bezogen auf das Vorgängermodell CMM vervielfachen wird. Entscheidende Faktoren hierfür sind: • die Erweiterung auf (System) Engineering Prozesse • die Flexibilität zweier Repräsentationsformen bei voller inhaltlicher Kompatibilität • die Qualität, Ausführlichkeit und Verständlichkeit der Modelle • der professionelle Support Status bei ISO 15504: Hinter ISO 15504 steht keine betreuende Organisation wie bei CMM. Entsprechend gering sind die Informationen, die oftmals veraltet sind und von der SPICE User Group (http://www.seg.iit.nrc.ca/spice/) oder Forschungsorganisationen (z.B.http://www.sqi.gu.edu.au/spice/) geboten werden. Neuere Informationen, etwa zur Weiterentwicklung des TR in Hinblick auf die Norm, sind äußerst spärlich. Von einem professionellen "Support" kann daher keine Rede sein. Die 98er Version des TR wurde noch kostenlos zum Download angeboten (mittlerweile eingestellt), die gültige 99er Version (inhaltlich praktisch identisch) kann für mehrere hundert Euro von der ISO bezogen werden (www.iso.ch). Die ISO 15504 hat derzeit (März 2004) immer noch den Status Technical Report, also die letzte Vorstufe vor dem International Standard, mit dessen Erscheinen in den nächsten Jahren zu rechnen ist. Die ISO 15504 wird dabei noch einmal überarbeitet werden. Die ISO 15504 hat derzeit international im Vergleich zu den CMM-Modellen geringere Bedeutung und wird in der Praxis hauptsächlich in Australien, Europa und dort insbesondere in Deutschland angewendet. In Deutschland wird die ISO 15504 durch die Entscheidung einiger Automobilhersteller (Herstellerinitiative Software, HIS, bestehend aus Audi, BMW, DaimlerChrysler, Porsche, VW), die ISO 15504 für die Bewertung von Lieferanten einzusetzen, jedoch voraussichtlich an Bedeutung gewinnen. Durch die Konformität von CMMI zur ISO 15504 ist jedoch der Erfolg dieser Inititative noch abzuwarten. Fazit: Angesichts der geringen inhaltlichen Differenzen zwischen ISO 15504 und CMMI und angesichts der stärkeren institutionellen Unterstützung bei CMMI ist zu erwarten, dass CMMI mittelfristig die führende Rolle bei den prozessorientierten Qualitätsmanagement-Ansätzen einnehmen kann. 181 4.8.8 Literatur • • • • • • 182 Ralf Kneuper: CMMI - Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. Dpunkt.Verlag Heidelberg, 2003. Watts S. Humphrey: Characterizing the Software Process: A Maturity Framework, Software Engineering Institute, CMU/SEI-87-TR-11 Watts S. Humphrey: Managing the Software Process, Addison Wesley, Reading, MA, 1989 The Capability Maturity Model - Guidelines for Improving the Software Process, Carnegie Mellon, University, Software Engineering Institute, Addison Wesley, Reading, MA, 1994 ISO/IEC TR 15504-5:1999(E), Information technology - Software Process Assessment, First Edition 1999-05-01 Capability Maturity Model ® Integration (CMMI SM), Version 1.1, Carnegie Mellon, Software Engineering Institute, March 2002, CMU/SEI-2002-TR-001 5 Requirements Engineering 5.1 Textuelle Beschreibung von Anwendungsfällen Die Anforderungsanalyse besteht einerseits aus den nicht funktionalen Anforderungen wie Definition der Qualität des zukünftigen Systems, Festlegung des Termins, zu dem das Produkt fertig sein soll, Vorgaben für die einzusetzende Hardware und Software etc. Außer diesen nicht funktionalen Anforderungen gibt es die funktionalen Anforderungen, d. h. die Spezifikation der Funktionen des Systems. Der generelle Ablauf des Systems kann durch Workflows dargestellt werden. Die einzelnen Anwendungsfälle können mit Hilfe der Use-Caseoder Anwendungsfall-Modellierung spezifiziert werden. Wir kennen Use-Cases (Anwendungsfälle) schon aus dem 1. Teil der Vorlesung. Hier ein Beispiel, wie man Use-Cases beschreiben kann: Beispiel 1: Geldautomat (ATM) ATM Withdraw Cash Customer Fig. 1: Graphische Darstellung des UseCase Diagramms Geldautomat 1. Überschrift: Geld abheben 2. Einfache verbale Beschreibung: Nachdem der Kunde die Karte eingeschoben und die PIN und den Betrag eingegeben hat, wird der Betrag vom Konto abgebucht und die Karte und das Geld ausgegeben. Falls die PIN das 1. oder 2. Mal falsch eingegeben wurde, wird der Kunde benachrichtigt und die PIN wird erneut eingegeben. Falls die PIN ein 3. Mal falsch eingegeben wurde, protokolliert das System den Versuch, zieht die Karte ein und bricht die Kommunikation ab. Falls die Karte nicht gültig ist, wird dies dem Kunden mitgeteilt und die Karte wieder ausgegeben. Bessere und eindeutigere Schreibweise: 183 Die obige Beschreibung des Anwendungsfalls ist nicht sehr übersichtlich und auch nicht ganz eindeutig. Aus der obigen Beschreibung kann man nicht erkennen, ob zuerst die PIN geprüft wird und evtl. die Ausnahmesituation eintritt oder ob PIN und Betrag eingegeben werden und danach die Prüfung erfolgt. Cockburn hat in seinem Buch "Writing Effective Use-Cases" [Co01] erläutert, wie Anwendungsfälle besser beschrieben werden können: Wir schreiben die einzelnen Aktionen (Action-Steps) in der richtigen Reihenfolge und nummerieren jede Aktion. Jede Aktion wird durch einen einfachen Satz Subjekt, Verb, Objekt und evtl. präpositionale Ergänzungen beschrieben. Als Subjekt steht immer die Instanz, die die Aktion durchführt. Wir geben ein Use-Case-Goal an. Dieses Use-Case-Goal macht eine Aussage darüber, was das Ziel des Anwendungsfalls ist. Das Use-Case-Goal entspricht normalerweise dem Namen des Anwendungsfalls bzw. sagt aus, dass der Name das Ziel des Anwendungsfalls beschreiben sollte. Es ist immer aus der Sicht des Akteurs zu sehen, d. h. man schreibt Geld abheben, nicht Geld auszahlen. Beispiel 1: Geldautomat Use-Case-Goal: Geld abheben Basic Course: 1. 2. 3. 4. 5. 6. 7. 8. Kunde schiebt Karte ein. Das System überprüft, dass die Karte gültig ist. Kunde gibt PIN ein. Das System überprüft, dass die PIN die richtige PIN zur Karte ist. Kunde gibt gewünschten Betrag ein. System bucht Betrag vom Konto ab. System gibt Karte aus. System gibt Geld aus. In der UML gibt es noch den Begriff Use-Case-Business-Result. Dieses Use-Case-BusinessResult gibt an, welches Ergebnis nach dem erfolgreichen Durchlauf durch den Anwendungsfall entsteht. Use-Case-Business-Result: Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht. Die Karte wurde vom Automat zurückgegeben. Das System ist wieder bereit für den nächsten Kunden. Alle Fehler– und Transaktionsdaten wie z. B. Zeit und Datum der Transaktion wurden protokolliert. Was haben wir nun noch vergessen? Was passiert, wenn z. B. die PIN falsch eingegeben wird, die Karte nicht lesbar ist etc.? 184 Jeder Ausnahmefall wird nicht im Basic Course, sondern in einem speziellen Alternative Course beschrieben. Vorteil dieser Vorgehensweise ist, dass man sich als erstes Gedanken macht über den Normalfall. Im zweiten Schritt werden die Ausnahmen durchdacht. Um die Beschreibung übersichtlich zu halten, werden die Ausnahmefälle nicht in den Basic Course integriert (z. B. mit: "Wenn das und das tue dieses und jenes" - und das evtl. über mehrere Stufen), sondern in einem gesonderten Alternative Course beschrieben, der auf den Basic Course Bezug nimmt. Basic Course Alternative Course ? Business Result Alternative Courses: 4a. Das System erkennt, dass die PIN das 1. oder 2. Mal falsch eingegeben wurde: 4a1. Das System protokolliert den Versuch. 4a2. Das System benachrichtigt den Kunden. 4a3. Rückkehr nach 3. 4b. Das System erkennt, dass die PIN das 3. Mal falsch eingegeben wurde: 4b1. 4b2. 4b3. 4b4. Das System protokolliert den Versuch. Das System zieht endgültig die Karte ein. Das System benachrichtigt den Kunden. Use-Case wird abgebrochen. Aufgabe: Was passiert, wenn die Karte ungültig ist? Beschreiben Sie den Alternative Course. 185 Wie wird der Use-Case ausgelöst? Ein Use-Case wird durch einen Trigger ausgelöst. Der Trigger kann die erste Aktion im Use-Case sein (z. B.: Der Kunde schiebt die Karte ein), es kann aber auch ein Ereignis von außerhalb des eigentlichen Use-Cases sein (z. B.: Kunde ruft an und will Auftrag vergeben. Die erste Aktion ist dann: Sachbearbeiter ruft Auftragserfassungsprogramm auf) oder ein Timer Derjenige der durch die direkte Kommunikation mit dem System den Use-Case anstößt, d. h. derjenige, der die erste Aktion des Use-Case durchführt wird Primary Actor genannt Wer ist bei der Beschreibung des Use-Case zu befragen? Alle Stakeholders, d. h. alle, die an dem Use-Case interessiert sind. Das sind oft nicht nur die Akteure, sondern auch andere Personen oder Interessengruppen wie z. B. der Besitzer des zukünftigen Systems, der Abteilungsleiter, die interne Revisionsabteilung etc. Die Akteure sind zwar diejenigen, die später das System bedienen werden, sind aber oft für die Definition des UseCase nicht so wichtig wie andere Stakeholders. Typen von Alternative Courses [MOW03] - Use-Case-Exception - Verzweigt und kehrt nie mehr zurück - Erfüllt nicht die Use-Case-Business-Results In [Co01]: Use-Case-Business-Results = Success-Guarantees. die Minimal-Guarantees sind immer, d. h. auch bei Abbruch erfüllt – hier: Minimal-Guarantees: Alle Fehler– und Transaktionsdaten wurden protokolliert. Siehe Beispiel 1 (Geldautomat) zweiter Alternative Course: 4b. Das System erkennt, dass die PIN das 3. Mal falsch eingegeben wurde: 4b1. Das System protokolliert den Versuch. 4b2. Das System zieht endgültig die Karte ein. 4b3. Das System benachrichtigt den Kunden. 186 Fig. 3: Use-Case-Exception 4b4. Use-Case wird abgebrochen. - Alternative History - Verzweigt und kehrt nie mehr zurück - Erfüllt die Use-Case-Business-Results (= Success-Guarantees) Fig. Alternative History 2: Beispiel 2 Personalverwaltung: Use-Case-Goal: Mitarbeiter einstellen Basic Course: 1. Der Sachbearbeiter der Personalabteilung gibt den Namen, die Adresse und Telefonnummer des einzustellenden Mitarbeiters ein. 2. Der Sachbearbeiter der Personalabteilung gibt die Abteilung des neuen Mitarbeiters ein. 3. Das System weist dem Mitarbeiter eine eindeutige Personalnummer zu. 4. Das System zeigt die verschiedenen Entlohnungstarife an. 5. Der Sachbearbeiter der Personalabteilung selektiert einen Tarif. 6. Der Sachbearbeiter der Personalabteilung gibt die wöchentliche Arbeitszeit ein. Use-Case-Business-Results / Success-Guarantees: Der neue Mitarbeiter ist eingestellt. Der Personalstammsatz ist angelegt. + Minimal-Guarantees Minimal-Guarantees: Alle Fehler– und Transaktionsdaten wurden protokolliert. Alternative History: 5a. Der Sachbearbeiter entscheidet, dass die Position eine außertarifliche Bezahlung erfordert: 187 5a1. Der Sachbearbeiter der Personalabteilung legt das außertarifliche Monatsgehalt fest. 5a2. Der Sachbearbeiter der Personalabteilung vermerkt sonstige Nebenabreden. 5a3. Use-Case endet erfolgreich. - Alternative Part (a) (b) A - Verzweigt und kehrt zurück zu Basic Course (c) A B A B B - Erfüllt die Business-Results 3 Arten von Alternative Parts: Conditional Insertion - - Conditional Insertion Interaction Cycle Alternative interaction fragment Fig. 3: Alternative Part Beispiel 3: Studentenverwaltung Use-Case-Goal: Studierenden immatrikulieren Basic Course 1. Sachbearbeiter gibt Name und Adresse des Studierenden ein. 2. Das System vergibt eine Matrikelnummer. 3. Sachbearbeiter trägt den Fachbereich ein. 4. System druckt die Immatrikulationsbestätigungen. Alternative Course (hier: Conditional Insertion): 4a. Studierender hat noch keine Wohnung und ihm wurde ein Wohnheimplatz zugesagt: 4a1. Das System zeigt freie Wohnheimplätze an. 4a2. Dem Studierenden wird ein Wohnheimplatz zugewiesen. 4a3. Rückkehr nach 4. Bemerkung: Extension Point (hier: Action-Step 4) ist der Punkt, an dem der Base Use-Case verlassen wird. Der Action-Step des Extension Points wird nicht durchgeführt, 188 stattdessen werden die Action-Steps des Alternative Courses durchgeführt [MOW03]. Return Point ist der Punkt, an dem wieder in den Base Course zurückgesprungen wird (hier wie bei jeder Conditional Insertion = Extension Point). Der Action-Step am Return Point wird nach dem Rücksprung als nächstes durchgeführt[MOW03]. - - Interaction Circle Siehe Beispiel 1 (Geldautomat) erster Alternative Course: 4a. Das System erkennt, dass die PIN das 1. oder 2. Mal falsch eingegeben wurde: 4a1. Das System protokolliert den Versuch. 4a2. Das System benachrichtigt den Kunden. 4a3. Rückkehr nach 3. - - Alternative Interaction Fragment Beispiel 4: Auftragsverwaltung Use-Case-Goal: Auftrag erfassen Basic Course: 1. Der Auftragssachbearbeiter gibt den Namen des Kunden ein. 2. Das System zeigt alle Kunden mit diesem Namen an. 3. Der Auftragssachbearbeiter wählt den richtigen Kunden aus. 4. Das System zeigt alle Kundendaten an. 5. ... Alternative Course (hier: Alternative Interaction Fragment): 1a. Der Auftragssachbearbeiter wünscht mit Kundennummer zuzugreifen: 1a1. Eingabe der Kundennummer. Rückkehr nach 4. Abbildung zwischen textueller Beschreibung und graphischer Darstellung Es existieren 2 Welten: - UML 189 - textuelle Beschreibung Textuelle Beschreibung mit Basic Course + Alternative Courses kann sich in einen Use-Case abspielen. Aber auch möglich: In Base-Use-Case + Extension-Use-Case. Dies ist z. B. dann ratsam, falls der Alternative Course in mehreren verschiedenen Base-Use-Cases vorkommt. Abbildung zwischen textueller und graphischer Welt: Basic Course Alternative Course [condition] Extension Point Rejoin Point base use case «extend» extension use case Fig. 4 Alternative Course als eigener Use Case Darstellung von Beispiel 1 als ausgelagerte mit extend angebundene Use-Cases: 190 Geldautomat <<extend>> PIN-Eingabe Wiederholen {4,3; Condition: PIN wurde das 1. oder 2. Mal falsch eingegeben} Geld abheben Akteur2 <<extend>> Karte einziehen { 4, Abbruch; Condition: PIN wurde das 3. Mal falsch eingegeben} Fig. 5 Als eigene Use-Cases ausgelagerte alternative Courses Die Ziffern vor der Bedingung sind der Extension Point und der Return Point und definieren eindeutig den Typ des Alternative Courses. Statt Ziffern könnten im Text und in der Grafik auch Marken angegeben werden (z. B. PIN-Prüfung statt 4 – siehe unten). In der UML2 gibt es auch ein spezielles Konstrukt um Extension-Points darzustellen. Die Bedingung kann nur in Form eines Kommentars angegeben werden. Ein Konstrukt zur Darstellung von Return Points, so dass auch unterschieden werden kann, um welchen Typ von Extension es sich handelt, ist in UML2 nicht vorgesehen (könnte aber im Kommentar auch angegeben werden). Der Nachteil der Verwendung von Benannten ExtensionPoints ist, dass zum Zeitpunkt, zu dem man den Base-Use- Case erweitert, im Base-Use-Case eine Veränderung vorgenommen werden muss (Einführung einer Marke) 191 Geldautomat PIN-Eingabe Wiederholen <<extend>> {Condition: PIN wurde das 1. oder 2. Mal falsch eingegeben. extention point: PIN-Prüfung} extention points: PIN-Prüfung Akteur2 Geld abheben <<extend>> Karte einziehen {Condition: PIN wurde das 3. Mal falsch eingegeben. extention point: PIN-Prüfung} Fig. 6 Als eigene Use-Cases ausgelagerte alternative Courses dargestellt in UMLNotation Die UML-Notation lässt auch zu, dass man nicht nur die Marke, sondern zusätzlich die Aktion selbst hinschreibt, also: statt "Intentionen point: PIN-Prüfung" -> "Intentionen point PIN-Prüfung: Das System überprüft, dass die PIN die richtige PIN zur Karte ist." oder "Intentionen point 4: Das System überprüft, dass die PIN die richtige PIN zur Karte ist." Auslagern von nicht optionalen Teilen von Use-Cases Wird ein Use-Case zu lang, können auch Teile gesondert beschrieben werden. In [Co01] werden gesondert zu beschreibende Teile unterstrichen und als gesonderter Use-Case beschrieben, der eine Include-Beziehung zum Base Use-Case hat. Durch diese Vorgehensweise können sehr große UseCase Diagramme entstehen. Wir schlagen deshalb vor, gesondert zu beschreibende Teile auch im gleichen Use-Case zu beschreiben (durch Anhangen des in Klammern geschriebenen Wortes "verfeinert" am Ende der Aktion). Weiter unten kann dann die verfeinerte Aktion als unconditional insertion beschrieben werden. Extension und Return Points müssen nicht angegeben werden, da ja schon im Base Use-Case die Stelle angegeben ist, von wo aus mit der unconditional insertion fortgefahren wird, und nach der Abarbeitung der unconditional insertion wird natürlich genau nach der Aussprungstelle fortgefahren. Eine Auslagerung in einen gesonderten Use-Case sollte dann erfolgen, wenn dieser Anwendungsfall auch noch von anderen Use-Cases benötigt wird. Durch die Auslagerung als gesonderter Use-Case werden somit Redundanzen vermieden. 192 Use-Cases auf verschiedenen Ebenen In [Co01] werden mehrere Ebenen von Use-Cases definiert. Fig. 6 Levels von Use-Cases Die Use-Cases der oberen Ebenen können dabei durch Use-Cases der unteren Ebenen definiert werden. Es gibt Ziele (Goals), die auf ganz hohen Ebenen anzusiedeln sind. Das oberste Ziel wäre: Führe eine Firma, so dass Gewinn erzielt wird. Ein weiter tiefer angesiedeltes Ziel wäre: Aufträge abwickeln von der Angebotsschreibung bis zur Fakturierung und Verbuchung in der Buchführung. Diese oberen Ziele sind nach [Co01] die Summary-Goals und befinden sich auf dem White-Level, der wiederum in Kite- und Cloud-Level geteilt ist. Die von uns weiter oben ausführlich beschriebenen Use-Cases beschreiben alle die Kommunikation mit dem System. Dieser Level wird in [Co01] Blue bzw. Sea-Level genannt. Die zugehörigen Ziele heißen User-Goals. Die Use-Cases auf diesem Level werden dadurch charakterisiert, dass sie eine von der Auslösung durch den Trigger bis zum Erreichen des Business Results oder bis zum Abbruch eine Sitzung am Rechner (z. B Auftrag erfassen) bzw. einen ununterbrochenen Arbeitsfluss im Rechner darstellen (z. B. alle Pakete sortieren). 193 Unter dieser Schicht befindet sich noch der Indigo- bzw. Underwater-Level und der Black- bzw. Clam-Level. Hier sind Subfunctions angesiedelt, für die aber normalerweise keine Beschreibung mehr existiert. Weiter Möglichkeiten der Beschreibung von Use-Cases Wie können wir Use-Cases beschreiben? - - - ganz normaler Text strukturierter Text (pro Satz eine Aktion) Workflow- oder Aktivitätsdiagramme. Diese Diagramme sind besonders geeignet zur Darstellung der Abläufe im Kite- oder Cloud-Level (Siehe Kapitel Workflows). Zustandsdiagramme. Da ein Zustandsdiagramm im Grunde genommen das gleiche ist wie ein Aktivitätsdiagramm sind Use-Cases natürlich auch mit Zustandsdiagrammen beschreibbar. Als Beispiel sei hier auf das Zustandsdiagramm des Use-Cases Authentifizierung in [JRHZQ04], Kap. 11.3.1 verwiesen. Sequenzdiagramme. Diese Art von Beschreibung stellt schon die Kommunikation zwischen Klassen dar – sie ist deshalb nicht als Diskussionsgrundlage zwischen dem normalen Benutzer ohne jegliches IT-Wissen und dem Systementwickler geeignet, sondern führt schon hin zum Design des Systems. Kommunikationsdiagramme. Hier gilt das gleiche wie für Sequenzdiagramme. Literatur [Co01] Cockburn, Alistair; Writing effective use cases; Addison Wesley, 2001 [MOW03] Metz, Pierre; O’Brian, John; Weber, Wolfgang; Specifying Use Case Interaction: Types of Alternative Courses. In: Journal of Object Technology, März 2003 [MOW03] Metz, Pierre; O’Brian, John; Weber, Wolfgang; Specifying Use Case Interaction: Clarifying Extension Points and Points of Return. In: Journal of Object Technology, März 2004 [JRHZQ04] Jeckle; Rupp; Hahn; Zengler; Queins; UML2 glasklar; Hanser-Verlag; 2004 194 6 Der Qualitätsbegriff und die Qualitätskriterien für Software Es gibt 5 verschiedene Ansätze für die Qualität von Software: • • • • • Transzendent: Qualität ist eine ganzheitliche Eigenschaft. Sie lässt sich nur durch Erfahrung bewerten. (Für die Praxis untauglich: "Programmierer ist Künstler"). Produktbezogen: Qualität ist eine genau spezifizierte Größe, die das Produkt beschreibt. (Kundeninteresse wird bei diesem Ansatz leicht vernachlässigt). Sicht: Entwickler. Benutzerbezogen: Qualität wird durch den Produktbenutzer festgelegt. Produkte, die das Benutzerbedürfnis am besten befriedigen, sind qualitativ hochwertig. (Das Verkaufsergebnis als Indikator ist problematisch). Sicht: Vertrieb/Verkauf. Prozessbezogen: Qualität entsteht durch den richtigen Erstellungsprozess. Dieser muss spezifiziert und kontrolliert werden. Dadurch wird Ausschuss und Nachbesserung vermieden und die wandelnden Kundenbedürfnisse berücksichtigt. Sicht: Fertigung. Kosten/Nutzen bezogen: Qualität ist eine Funktion von Kosten und Nutzen. Ein Qualitätsprodukt ist ein Erzeugnis, das zu einem akzeptablen Preis einen bestimmten Nutzen bringt. Sicht: Finanzen Allgemeine Definitionen: Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht. (Deutsche Industrie-Norm DIN 55350, Teil 11) Qualität ist die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. (ISO 8402) 6.1 Die Qualitätseigenschaften beim fertigen Produkt: Richtigkeit: Das Softwaresystem arbeitet Spezifikation. gemäß der widerspruchsfreien Zuverlässigkeit: 195 Sei fw(t) die Wahrscheinlichkeit, dass im Zeitraum 0 bis t im System ein Fehler auftritt, so ist R(t) = 1 - fw(t) die Zuverlässigkeitsfunktion des Systems. Geht R(t) auch für große t gegen 1, so nennt man das System zuverlässig. Effizienz: Das System nutzt die Ressourcen bestmöglich aus. Hardware wird bei voller Erfüllung des Aufgabenkatalogs sparsam verwendet. Ablaufzeit ist möglichst optimal. Robustheit: Die Auswirkung eines Bedienungsfehlers ist umgekehrt proportional der Häufigkeit seines Auftretens. Funktionsumfang - Funktionserfüllung: Funktionsumfang ist dann in Ordnung, falls der Funktionsumfang des Systems gleich dem geplanten Funktionsumfang ist. Benutzerkomfort: Ist dann erfüllt, wenn dem Benutzer ein angenehmes , effizientes und fehlerarmes Benutzen möglich ist und der Lernaufwand zur Bedienung des Systems gering ist. Änderbarkeit: Anpassungen und Fehlerbehebung sind schnell und ohne Folgefehler durchführbar. Portabilität: Das System kann leicht in neue Hardwareumgebungen übertragen werden. Wiederverwendbarkeit: Systemteile sind wiederverwendbar, wenn sie aufgrund ihrer Spezifikation in unterschiedlichen Softwaresystemen als Bausteine verwendet werden können. Generell: Die Wiederverwendung ist mit weniger Aufwand verbunden als die Neuentwicklung. Je nach Interessenlage ergeben sich Unterschiede in der Bewertung der Wichtigkeit von Qualitätseigenschaften beim fertigen Produkt: 6.1.1 Wichtige Kriterien aus Benutzersicht 196 Richtigkeit Zuverlässigkeit Effizienz Robustheit Funktionsumfang - Funktionserfüllung Benutzerkomfort 6.1.2 Wichtige Kriterien aus Entwicklersicht Änderbarkeit Portabilität Wiederverwendbarkeit Auf die Softwarequalität haben unterschiedliche Faktoren Einfluss: Bild 1: Einflussfaktoren auf die Qualität 6.2 Qualitätsmanagement 197 Will man Softwarequalität erreichen, so muss der gesamte Softwareentwicklungsprozess diese Kriterien im Auge haben. Es muss darauf geachtet werden, dass der gesamte Entwicklungsprozess in systematischer Art und Weise die Qualitätskriterien unterstützt. Eine Art "Qualitätsagentur" am Ende des Entwicklungsprozesses, die das Produkt mit "Qualität" versieht ist ein unmögliches Unterfangen. Zur systematischen Erarbeitung von Softwarequalität gehört: 1. Eine Entwicklungsmethodik die folgendes erreicht: Adäquate Modellierung des Problembereichs Beherrschung der Problemkomplexität 2. Einsatz von bewährten Systemarchitekturen Bewährte Analysemuster aufdecken und benutzen Bewährte Entwurfsmuster einsetzen, finden und dokumentieren Vorhandene bewährte Klassen- und Funktionsbibliotheken verwenden, ggf. erweitern Vorgegebene "Frameworks", d.h. vorgefertigte Anwendungsbereiche, sinnvoll einsetzen 3. Den Benutzer ernsthaft bei der Festlegung der Anforderungen beteiligen 4. Konsequente Projektführung im Hinblick auf die Qualität der Software Um zu überwachen, ob ein Qualitätsziel beim Endprodukt erreicht worden ist, muss man Metriken für dieses Qualitätsmerkmal haben. Wir werden im Laufe der Vorlesung einige solcher Maße besprechen, aber insgesamt ist die Lage durch weitgehendes Fehlen der geeigneten allgemein einsetzbaren Metriken gekennzeichnet. Deshalb ist es im Softwareentwicklungsprozess meist erfolgreicher bereits im konstruktiven Prozess die Qualität des Endproduktes weitgehend zu sichern, als sich auf die Überprüfung nach Fertigstellung zu verlassen. Diese konstruktive Qualitätssicherung ist gekennzeichnet durch: Maßnahmen, die bereits in den Phasen: Analyse Definition Entwurf Implementierung systematisch und permanent stattfinden. Hierzu können gehören: • Prototyping zur Einbeziehung des Benutzers • Einsatz bewährter Analyse- und Entwurfsmuster 198 • Verwenden vorgefertigter Anwendungsframeworks generell: • Wiederverwendung zuverlässiger vorhandener Softwarelösungen für Teile des Systems (Klassenbibliotheken usw.) • Einsatz von Werkzeugen zur formalen Spezifikation (Z oder VDM oder Petrinetze) • Bewährte Abwandlungen des "Wasserfallmodells" anwenden: • V-Modell • Prototyping • Spiralmodell ( hier ist insbesondere die Risikoanalyse wichtig mit der Überprüfung, vor jeweils einer neuen Entwicklungsrunde, ob Wiederverwendung günstiger ist) • Evolutionäre Entwicklung ("Versioning") 6.2.1 Methoden und Werkzeuge des Qualitätsmanagements Das Softwarequalitätsmanagement hat drei Hauptaufgaben: • Qualitätssicherung ( durch Einrichten eines Systems von Verfahren und Regeln ("Standards") zur Entwicklung qualitativ hochwertiger Software) • Qualitätsplanung ( durch Anpassen der Verfahren und Regeln ("Standards") an das jeweilige Projekt ) • Qualitätskontrolle ( durch Entwickeln von Vorgehensweisen, die sicherstellen, dass die wichtigen Verfahren und Regeln (Standards) im Softwareentwicklungsprozess auch wirklich eingehalten werden ) 6.2.2 Die Bedeutung von Qualitätsstandards Das Qualitätsmanagement muss unabhängig vom Entwicklungsteam eine Überprüfung des Softwareentwicklungsprozesses durchführen. Ein internationaler Standard für die Entwicklung von Qualitätsmanagementsystemen ist ISO 9000, und speziell für den Bereich der Softwareentwicklung: ISO 9000-3. Es ist sinnvoll daraus eigene Standards für den Qualitätssicherungsprozess zu entwickeln, nämlich: Produktstandards (z.B. Standards für die Dokumente im Entwicklungsprozess, wie die Anforderungsdefinition, die Gestalt der Kommentare, die systematische und sinnvolle Variablenbenennung, Festlegung bestimmter Programmierstandards, um die Benutzung von negativen Eigenheiten von Programmiersprachen zu vermeiden) 199 Prozessstandards (z.B. die Festlegung, wie bestimmte Phasen abzulaufen haben und wie die Dokumente abzufassen sind, die in diesen Phasen geschaffen werden) Die beiden Arten von Standards hängen eng zusammen, da die Prozessstandards in vielen Fällen die Voraussetzung dafür sind, dass bestimmte Produktstandards erreicht werden. Gründe für das Beachten von Softwarestandards: • Sie bilden die Zusammenstellung geeigneter Entwicklungspraktiken • Sie stellen die Basis für die Qualitätskontrolle dar • Sie stellen sicher, dass das Auswechseln von Software-Entwicklern möglich wird 6.2.3 Die Problematik von Standards in der Softwareentwicklung Wenn sehr viele Regeln zur Softwareentwicklung in dicken Handbüchern vorhanden sind, wird das kaum eine große Begeisterung bei den Entwicklern hervorrufen. Deshalb sollten nicht zu viele Festlegungen getroffen werden, sondern nur wirklich sinnvolle "Standards" gefordert werden. Insbesondere sollte beachtet werden, dass die Zahl der Formulare, die während der Softwareentwicklung auszufüllen sind nicht zu groß wird. Eine sinnvolle Vorgehensweise des Qualitätsmanagers beinhaltet: 1. Für alle bürokratischen Standards, sollte er Werkzeuge zur Verfügung stellen 2. Die Standards sollten zwar gut ausgewählt und beständig sein, aber nicht für ewig aufgestellt werden. Der bessere Standard muss den guten ersetzen 3. Die Entwickler müssen bei der Erarbeitung von Standards beteiligt sein und jede Festlegung sollte stichhaltig im "Qualitäts-Handbuch" begründet sein. 6.2.4 Die Dokumentation von Software Um Verifikation und Validation von Software durchführen zu können, ist eine angemessene Dokumentation und eine präzise Festlegung der zu prüfenden Fälle unabdingbar. Das bereits früher behandelte V-Modell sieht hierin eine wichtige Aufgabe des Softwareentwicklungsteams (SWE), die vom Qualitätsmanager (QS) streng zu überwachen ist. Einige Qualitätskriterien nehmen direkt auf die Dokumentation bezug und werten Sie als (wichtigen) Indikator für die Qualität eines Softwareprodukts. 200 Kurz gesagt: Dokumentation muss korrekt, so knapp wie möglich und so umfassend wie nötig sein. Sinnvoll sind hier allgemein akzeptierte Standards in einem Software-Entwicklungsteam. 6.3 Die statische Kontrolle der Qualität und anderer Softwareeigenschaften Software zeigt ihre Eigenschaften beim dynamischen Ablauf aber teilweise auch durch theoretische Kontrolle, dh. durch statische Analyse des Programmcodes oder der Entwurfsunterlagen. Als Methoden unterscheidet man hierbei:: • Messung • Reviews • Formale Verifikation 6.3.1 Softwaremaße-Softwaremessung Im Gegensatz zur Messung in der Physik besitzt man in der Softwaretechnik keine allgemein festgelegten Grundmaße. Das gilt speziell für die Qualitätskriterien bei Software, mit Hilfe derer man die Messergebnisse ausdrücken und vergleichen könnte. Um trotzdem Aussagen über die Qualität von Softwareprodukten machen zu können, werden Hypothesen aufgestellt, die eine Reihe messbarer Größen quantitativ (in Gestalt einer Formel) als Maß für ein bestimmtes Qualitätskriterium des Softwareprodukts zusammenfassen. Es ist jedoch damit fast immer nur ein Teilaspekt dieses Kriteriums erfasst und insbesondere eine subjektive Wertung der Bedeutung einzelner messbarer Größen für die Qualität des Produktes damit verbunden. Metriken als Ausdruck für bestimmte Qualitätseigenschaften eines Softwareprodukts sollten also immer mit der gehörigen Vorsicht verwendet und bestenfalls als Maß für einen Teilaspekt der Qualität des Softwareprodukts gewertet werden. Meist weisen die Ergebnisse von Softwaremessungen nur bei einem Vergleich auf Qualitätsabweichungen unterschiedlicher Software hin. Um überhaupt Aussagen über Software machen zu können, braucht man Maße für Software-Eigenschaften. Einige davon betreffen unmittelbar die Qualität von Software. Andere tauchen in Formeln für die Qualität eines Softwareprodukts auf und dienen damit mittelbar der Qualitätsbestimmung. So wird ein Großteil der Maße für Qualitätsaussagen über die gemessene Software verwendet. Es gibt aber auch solche, die dazu benutzt werden, den Aufwand bei der Erstellung von 201 Software zu schätzen oder einfach nur Größenvergleiche unter verschiedenen Softwareprodukten anzustellen. 6.3.1.1 Die Function-Point Methode Diese Messmethode ist besonders herauszustellen, weil sie ein Maß liefert, das bereits zum Zeitpunkt der Erstellung der Anforderungsdefinition festgelegt werden kann und somit auch dazu dienen kann, den Aufwand für die Softwareerstellung zu einem sehr frühen Zeitpunkt festzustellen. In ihr werden Function-Points FP unter Beachtung bestimmter Einflussfaktoren mittels einer durch praktische Experimente verifizierten Formel berechnet: FP = UFP * TCF Die Größe UFP folgendermaßen: ( "ungewichtete Function-Points") ergibt sich dabei UFP = f1*I + f2*O + f3*L + f4*F + f5*A I O L F A Anzahl unterschiedlicher Eingabedatentypen Anzahl unterschiedlicher Ausgabedatentypen Anzahl unterschiedlicher interner logischer Datenbestände Anzahl unterschiedlicher externer Datenbestände ("Interfaces") Anzahl unterschiedlicher Abfragen fi sind Bewertungsfaktoren, die sich nach den Kriterien einfach, mittel, komplex nach folgendem Schema ergeben (Erfahrungswerte!): Merkmal I O L F A einfach (e) 3 4 7 5 3 mittel (m) 4 5 10 7 4 komple x (k) 6 7 15 10 6 Die Bewertungsfaktoren fi liegen in dem angegebenen Bereich. Für den durchschnittlichen UFP-Wert (bei mittlerer Schwierigkeit der Daten) gilt: UFPm = 4*Im + 5*Om + 10*Lm+ 7*Fm + 4*Am 202 wobei Im, Om, ... usw. die Anzahl solcher Datentypen mittlerer Schwierigkeit dieser Art ist. Analog ergeben sich UFPe und UFPk Der genaue UFP-Wert ergibt sich zu: UFP = UFPe + UFPm + UFPk Die Einschätzung e, m oder k geschieht nach folgenden Richtlinien: Eingaben: Anzahl unterschiedlicher Datenelemente (e):(1-5) (m): 6-10 (k): >10 Prüfung der Daten: (e) : formal (m): formal + logisch (k): formal+logisch+Dateizugriff Bedienerführung bei Eingabe (e): gering (m): teilweise, in der Handhabung (k): intensiv extern Ausgaben: Ebenfalls wieder Bewertung nach Anzahl unterschiedlicher Datenelemente Anzahl unterschiedlicher Zeilen in Listen Anzahl Wiederholgruppen ... usw. Hier sind Erfahrungswerte einzusetzen. Wenn nicht vorhanden, dann mittlere Bewertungsfaktoren verwenden. Der "Technical-Influence-Factor" TCF ergibt sich folgendermaßen: TCF = 0.65 + 0.01*DI , wobei DI bedeutet: "Degree of Influence" also "Einflussgrad". Der Einflussgrad kann zwischen 1 und 5 liegen und zwar werden folgende 14 Faktoren der Systemcharakteristik berücksichtigt. 203 Deren Summe ergibt den Wert DI: Faktor C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 Charakteristik Datenkommunikation Verteilte Verarbeitung Performance Intensive Systemnutzung Transaktionsrate On-Line Dateneingabe Benutzeroberfläche Online Änderungen Komplexe Verarbeitung Wiederverwendung Einfache Installation Operationale Einfachheit Externe Einbindung Änderungsfreundlichkeit DI DI-Summe: Je nach Stärke des Einflusses der jeweiligen Charakteristik wird der Wert DI zwischen 0= keinen Einfluss und 5 = starken Einfluss festgelegt. Maximal kann sich also ein DI-Wert von 70 (in der Summe) ergeben. TCF liegt also zwischen 0.65 und 1.35. Maximal kann also der Wert von FP durch TCF um 35 % nach oben und unten verändert werden. Beispiel1: Ein System mit drei internen logischen Datenbeständen L. Einem externen Datenbestand (Interface) F. Sechs Eingabedatentypen I, acht Ausgabedatentypen O und dreizehn unterschiedliche Abfragen. Komponenten einfach L(logische interne Daten- 1 x 7 = 7 bestände) F (Interfaces) I (Eingabedatentypen) 2 x3 = 6 1 204 mittel komplex Total 2 x 15 = 30 37 1 x 10 = 10 10 3 x 4 =12 1 x 6 = 6 24 vgl.:Horst Zuse: A Framework of Software Measurement, S.495f, Walter de Gruyter, 1998 O(Ausgabedatentypen) A(Abfragen) Summe 5x 4=20 6 x 3 = 18 3x5 = 15 6x4 = 24 1 x 6 = 6 35 48 156 Die Einflussfaktoren (TCF): Faktor C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 Charakteristik Datenkommunikation Verteilte Verarbeitung Performance Intensive Systemnutzung Transaktionsrate On-Line Dateneingabe Benutzeroberfläche Online Änderungen Komplexe Verarbeitung Wiederverwendung Einfache Installation Operationale Einfachheit Externe Einbindung Änderungsfreundlichkeit DI 4 3 5 4 5 5 1 4 2 2 1 4 0 3 DI-Summe: 43 Insgesamt ergibt sich in diesem Fall: FP = 156 * (0.65 + 0.01*43) = 168.48 Wir können also feststellen, dass die Technische Komplexität TCF in diesem Fall den Function-Point-Wert, zunächst ausgedrückt durch den UFP-Wert = 156, auf den endgültigen Wert von FP = 168.48 angehoben hat. 6.3.1.2 Halstead-Maße Mit den Halstead-Maßen wurde der Versuch unternommen, aufbauend auf einem neuen Maß für die Größe von Softwareprodukten, eine Theorie der Softwareentwicklung aufzustellen, die insbesondere die Wertung der verwendeten Programmiersprache mit einschließt. Außerdem kann mittels der Halstead-Maße eine Aussage über die Schwierigkeit der Softwareentwicklung gemacht werden. Anzahl der unterschiedlichen Operatoren: n1 205 Anzahl der unterschiedlichen Operanden: Anzahl des Auftretens von Operatoren: Anzahl des Auftretens von Operanden: n2 N1 N2 Primitives Beispiel zur Veranschaulichung der Maße (Programmiersprache C++, C ): void tausche(double &x, double &y) { double z; z=x; x=y; y=z; } Operatoren void ( ) double & = ; {} , n1 = 8 Anz. Auftreten 1 1 3 2 3 4 1 1 N1 = 16 Operanden x y z Anz. Auftreten 3 3 3 n2 = 3 N2 = 9 Abgeleitete Maße: Größe des Vokabulars: n = n1 + n2 Länge der Implementierung: N = N1 + N2 Im Beispiel: n = 11 (Größe des Vokabulars) 206 (1) N = 25 (Länge der Implementierung) Die Programmgröße, auch Volumen genannt, ist folgendermaßen definiert: Programmgröße (Volumen): V = N*log(n) (2) Der Name erklärt sich aus folgender Überlegung: Die n unterschiedlichen Worte können in log(n) Bits kodiert werden. Das Informationsvolumen des gesamten Programms mit insgesamt N Operatoren und Operanden kann also mit V Bits dargestellt werden. Die Größe V ist also recht gut als Maß für den Umfang eines Softwareprodukts geeignet und kann als Ersatz und zur Präzisierung des recht willkürlichen Maßes "Lines of Code" (LOC) verwendet werden. Für unser Beispiel ergibt sich V = 25 * log(11) = 25 * 3.5 = 87.5 Hinweis: In Sprachen mit reichhaltigem Operatorenangebot, die dem Problem angepasst sind, wird V klein sein, andernfalls ist V groß. Die minimale Größe für die Programmgröße V wird mit V* bezeichnet. Sie tritt auf, falls die Funktionen, die ein Programm bietet, voll als Befehle in der verwendeten Programmiersprache vorhanden sind. In diesem Fall braucht i.a. kein Operand und kein Operator wiederholt zu werden. V* = (n1* + n2* ) * log(n1* + n2*) (3) In der Idealsprache braucht nur noch die gewünschte Funktion aufgerufen und der erhaltene Wert zugewiesen zu werden. Also existieren in der "Idealsprache" für eine Problemlösung nur noch 2 verschiedene Operatoren Es ergibt sich im Idealfall also: V* = (2 + n2* ) * log(2 + n2*) (4) Im Beispiel ergäbe sich: V* = (2 + 3) * log(5) = 5 * log( 5 ) = 5 * 2.32 = 11.6 gegenüber V = 25 * log(11) = 25 * 3.5 = 87.5 207 Definition: Der Level L ist definiert als: L = V* / V (5) Der Level hängt von der Programmiersprache ab. Im Idealfall ist der Level L = 1, real ist L < 1. Im Beispiel gilt: L = 11.6 / 87.5 = 0.133 Ein Maß für die Schwierigkeit der Implementierung D (difficulty) ist definiert als: D = 1/L (6) Im Beispiel ergibt sich: D = 7.52 Der Aufwand E (effort) ist definiert als: E=V/L = V*D (7) Im Beispiel ergibt sich der Wert: E = 87.5 * 7.52 = 658.0 Einsetzen von (5) in (7) ergibt das sehr aussagekräftige Resultat: E = V2 / V* (8) Da der Wert V* für die hypothetische, ideal geeignete Programmiersprache sich nur sehrgeringfügig mit dem wachsenden Programmumfang verändert, besagt die Formel (8) in etwa: Der Aufwand zur Codierung eines Programms steigt quadratisch mit dem Programmvolumen. 208 Ein Softwaremaß, das als Maß für die "Komplexität" von Softwaremoduln intensiv verwendet wird, ist das von Mc Cabe. Bei genauerer Analyse stellt sich heraus, dass man dieses Maß als Maß für den Aufwand eines sinnvollen Tests also als Maß für die Testkomplexität verwenden kann, denn (grob gesprochen) gibt das Mc Cabe-Maß die Mindestzahl der Testläufe an, die benötigt werden, um einen sorgfältige Prüfung eines Moduls durchzuführen. In einem Modul ohne Programmschleifen, gibt das Mc Cabe Maß die Anzahl der Pfade durch das Programm an. Sind Schleifen vorhanden, so müssten streng gesprochen unendlich viele Testläufe durchgeführt werden und das Mc Cabe Maß gibt nur an, wieviel Läufe mindestens notwendig sind für einen Test, bei dem jede Schleifenbedingung mindestens einmal wahr und einmal falsch ist. 6.3.1.3 Das Mc Cabe-Maß Die zyklomatische Zahl z, die Zahl der unabhängigen Pfade1 durch den ProgrammGraphen G, ist das McCabe-Maß des Programms. Für z gilt: z(G) = e - n + 2 wobei gilt: e = Anzahl der Kanten des Graphen G n = Anzahl der Knoten von G Beispiel: 1 Ein Pfad durch den Programmgraphen ist unabhängig, wenn er mindestens eine Kante enthält, die in keinem anderen Pfad enthalten ist 209 Hier gilt: z(G) = 10 - 8 + 2 = 4 d.h. es existieren 4 unabhängige Pfade durch den Programmgraphen G. Die Pfade: 1) < 2,4,6,8,10 > 2) < 1,5 > 3) < 2,3,7,8,10 > 4) < 2,4,6,8,9,8,10 > Es gilt z.B.: Der Pfad <2,3,7,8,9,8,10> ist nicht unabhängig, weil er nur Kanten enthält, die bereits im Pfad 3) bzw. 4) enthalten sind. Folglich gilt sogar allgemein, dass alle Pfade, die die Schleife <8,9> mehrfach enthalten, abhängig sind von den Pfaden 3) und 4): Der Pfad < 2,4,6,8,(9,8),(9,8),(9,8),10 > beispielsweise ist kein unabhängiger Pfad, es gilt: <2,4,6,8,(9,8),(9,8),(9,8),10> = Pfad 1) + 3*( Pfad 4)-Pfad 1)) Die McCabe-Zahl gibt Auskunft über die Komplexität der Kontrollstruktur. Falls z(G) sehr groß ist, z.B. >>10, wird der pfad-vollständige Test sehr aufwendig. Es gibt für einfache Programm-Graphen ein vereinfachtes Verfahren, um die McCabe-Zahl zu berechnen. Es gilt nämlich: 210 z (G) = π + 1, wobei π die Anzahl der Verzweigungen über BOOLEschen Bedingungen ist. Im Beispiel ist π gleich 3 also ergibt sich aus obiger Formel ebenso der Wert z(G) = 4. Eine weithin akzeptierte Regel in Bezug auf das Maß von McCabe lautet: Große Programme sollten in Module zerlegt werden, wobei für jeden einzelnen Modul gelten muss, dass z(G) < 10 ist. 6.3.1.4 Fan-in---Fan-out Darstellung des Flusses: (Quelle, Fluss, Ziel) Lokaler Datenfluss (A, x, B) Eingabeparameter x ist Werteparameter A x B A ruft die Funktion B auf und erhält ein Ergebnis (B, B, A) A B B Globaler Datenfluss: (A, DS, B) A verändert eine globale Datenstruktur und B benutzt diese A B 211 DS Beurteilung der Software-Architektur durch Informationsfluss-Analyse: "fan-in" Zahl der Datenflüsse, die zu einem Modul m führen: FIm "fan-out" Zahl der Datenflüsse, die von einem Modul wegführen: FOm n IF4 = ∑ ( FIi * FOi ) 2 n ist Anzahl der Module i=1 IF4i = (FIi * FOi )2 IF4 (S) ist eine Maßzahl für die Architektur des Systems S IF4m (S) ist eine Maßzahl für den Modul m im System S Beispiel: A y x x B Globale Flüsse: ( B, MF, C ) ( B, MF, D ) 212 y,z C Masterfil e D Modul fan-in fan-out FI * FO IF4i A B C D 3 0 2 2 2 3 2 0 6 0 4 0 36 0 16 0 IF4 drückt die Kopplung der Module mit ihrer Umwelt aus: IF4(D) = IF4(B) < IF4(C) <IF4(A) Dies bedeutet in diesem Falle, dass A eine sehr starke Kopplung mit der Umgebung hat. IF4 kann benutzt werden, um Architekturen miteinander zu vergleichen. Deutlich geringeres IF4 bedeutet weniger starke Kopplung unter den Komponenten. Beim "Altern" der Software entartet sehr oft die Struktur. IF4 und die verschiedenen IF4i und IF4 (S) können aufzeigen, ob und wo ein Re-Engineering notwendig, bzw. sinnvoll wäre. Empirische Studien haben gezeigt, dass eine starke Abhängigkeit zwischen den obigen Informationsfluss-Maßen und dem Wartungsaufwand besteht. Es gibt aber auch Abweichungen von dieser empirischen Gesetzmäßigkeit, z.B. verursacht durch ungewöhnlich große Moduln. Eine wichtige Frage: Welches ist die optimale Größe von Moduln? Zu diesem Zweck können kombinierte Maße wie ( LOCi , IF4i ) oder (McCabei , IF4i) benutzt werden, um ausgeartete Module zu lokalisieren. 6.3.2 Reviews Bei Reviews werden der Programmcode oder die Analyse- oder Entwurfsunterlagen betrachtet, analysiert und auf Fehler untersucht, ohne dass die Software ausgeführt wird. Reviews und Tests der Software sind keine sich 213 ausschließende Verfahren. So ist zum Beispiel eine der wirksamsten ReviewTechniken die Inspektion der Testfälle eines Softwaresystems. Programminspektionen haben als Hauptziel die Entdeckung von Fehlern in der Software und beschäftigen sich weniger mit anderen Arten der Qualitätssicherung. 6.3.2.1 Die Entwurfsinspektion Die Gruppe für eine Entwurfsinspektion besteht aus 3 bis 5 Teilnehmern (bei kleineren Projekten evtl. nur 2 Teilnehmern) 1. Entwerfer 2. Moderator 3. Erfahrener Programmierer (Protokollführer für entdeckte Fehler) 4. evtl. 2-3 weitere Teilnehmer (Codierer, Wartungspersonal, Mitarbeiter aus anderen Projekten) Ablauf : 4 Nicht unterbrechbare Sitzung von 1-2 Stunden. 4 Teilnehmer erhalten die Entwurfsunterlagen möglichst einige Tage vor der Sitzung durch den Moderator zugestellt. (Sind von den Teilnehmern durchzustudieren!) 4 Anhand der Anforderungsdefinition werden die Fälle mittels des Entwurfs durchgespielt. 4 Die anhand des Entwurfs zu erwartenden Ergebnisse werden daraufhin überprüft, ob sie mit den gemäß Anforderungsdefinition zu erwartenden übereinstimmen. 4 Es wird ein Protokoll über entdeckte Fehler geführt. 4 Über kritische Stellen des Entwurfs wird mit dem Entwerfer diskutiert. 4 Auch "Schwachstellen" werden protokolliert. 4 Es wird aber noch keine Fehlerkorrektur vorgenommen. Fehler werden erst (später durch den Entwerfer) bereinigt 214 6.3.2.2 Die Codeinspektion Die Mannschaft für eine Codeinspektion besteht aus ca. 4 Teilnehmern: 1. 2. 3. 4. Programmierer des vorliegenden Produkts Moderator Testspezialist Entwerfer Ablauf : 4 Einige Stunden vor der Sitzung verteilt der Moderator die Programmliste und die Entwurfs- Spezifikation an die Teilnehmer (Durchstudieren und verstehen des Codes durch die Teilnehmer ist Voraussetzung für die Sitzung.) 4 Dauer der Sitzung 1 - 2 Stunden ununterbrochen. Wichtigste Aktivitäten 1. Der Programmierer erklärt die Programmlogik Schritt für Schritt gemäß der Anweisungen. Eventuell auftretende Fragen werden verfolgt. Der Moderator protokolliert die Fehler. Kritische Fälle werden eventuell durchgespielt und die Ergebnisse mit denen gemäß der Entwurfsspezifikation verglichen. 2. Die vorliegende Programmliste wird anhand einer Checkliste häufiger Fehler analysiert (evtl. schon vorher von jedem Teilnehmer) Der Moderator achtet darauf, dass sich auf das Entdecken von Fehlern beschränkt wird und protokolliert diese. Die Korrektur wird später durch den Programmierer vorgenommen. 215 Check-Liste für die Codeinspektion " | " Bedeutet:Fehler können vom Compiler normalerweise nicht gefunden werden, d.h. diese Punkte sind besonders wichtig für Nachprüfungen Variablenbenutzung 1.Werden Variable angesprochen, die nicht initialisiert wurden? | 2.Werden die Indexgrenzen für Felder (Arrays) eingehalten? 3.Sind die Indizes vom richtigen Typ? | 4.Werden Pointer richtig verwendet? 5.Stimmen formale Parameter und die Argumente für die Unterprogramme im Typ überein? 6.Ist die Anzahl der Argumente gleich der Argumente der formalen Parameter bei Unterprogrammen? Variablenvereinbarung 1.Sind alle Variablen vereinbart? | 2.Werden Felder richtig initialisiert? | 3.Gibt es Variable mit ähnlichen Namen? | 4.Sind die globalen Variablen an der richtigen Stelle vereinbart? Berechnungen 1.Werden Berechnungen mit nicht arithmetischen Variablen durchgeführt? 2.Gibt es Berechnungen, an denen Daten unterschiedlichen Typs beteiligt sind? | 3.Kann es Über- oder Unterlauf in Zwischenergebnissen geben? | 4.Kann irgendwo eine Division durch Null auftreten? | 5.Wo können unvertretbare Ungenauigkeiten durch die Dualdarstellung auftreten? | 6.Wurde die Priorität der Operationen beachtet? | 7.Sind die ganzzahligen Divisionen korrekt? Vergleiche 1.Werden Werte verschiedenen Typs miteinander verglichen? | 2.Sind die Vergleichsoperationen korrekt verwendet? | 3.Sind die Booleschen Ausdrücke korrekt? | 4.Treten überkomplizierte Boolesche Ausdrücke auf? 216 Programmablauf | 1.Werden bei Fallunterscheidungen alle Fälle berücksichtigt? | 2.Wird jede Schleife richtig beendet? (Endlosschleife möglich?) | 3.Hört das Programm nach endlich vielen Schritten auf? | 4.Werden Schleifen aufgrund der Eingangsbedingung nicht ausgeführt? | 5.Ist die Schrittzahl in zählenden Schleifen um eins zu hoch oder zu niedrig? Schnittstellen 1.Werden Eingabeparameter im Unterprogramm verändert? 2. Werden Konstante auf der Position von Variablenparametern als Argument übergeben? | 3.Ist die Benutzung globaler Variablen über alle Module konsistent? 4.Sind Parameter und Argumente in bezug auf Typ und Argument konsistent? Ein- und Ausgabe 1.Werden die Dateien richtig geöffnet und geschlossen? 2.Sind die Dateien richtig vereinbart? 3.Werden Zeilenende und Dateiende korrekt abgefragt? Weitere Prüfungen 1.Gibt es nicht angesprochene Variablen im Programm? 2.Erhält man bei der Übersetzung Warnungsmeldungen? 3.Werden die Eingabedaten auf Gültigkeit geprüft? | 4.Fehlen bestimmte Funktionen oder Prozeduren? 6.3.3 Formale Verifikation Jedes geschaffene Softwaresystem hat die Aufgabe, aus bestimmten Anfangsbeziehungen unter den Daten ("precondition") bestimmte Endbeziehungen ("postcondition") herbeizuführen. In der Systemspezifikation werden diese Transformationen, die das System leisten soll, festgelegt. Die formale Verifikation eines Systems verläuft nun so, dass durch ganz formales Anwenden von Regeln über die Wirkungsweise der verwendeten Algorithmenelemente der Beweis geführt wird, dass das System die gewünschten Transformationen leistet. Gelingt dieser Beweis, so hat man damit einen strengen Beweis, dass das System exakt die Spezifikation erfüllt, also korrekt ist. 217 Die Regeln über die Wirkung der Algorithmenbausteine sind sehr elementarer Art, so dass man sicher sein kann, dass sie in allen gängigen Programmiersprachen so festgelegt sind [s. Hoare69]. Die Evidenz dieser Axiome ist teilweise offensichtlich oder kann leicht eingesehen werden. Umgekehrt kann man auch so formulieren, dass die Axiome im Hinblick auf die verwendete Implementierungssprache und den eingesetzten Computer festlegen, dass die angegebene Wirkungsweise mindestens garantiert sein muss. Die Verifikationsregeln sind formuliert wie ein Vertrag: Wenn eine bestimmte Voraussetzung erfüllt ist, dann führt das Algorithmenelement eine bestimmte Beziehung (die "precondition") in eine bestimmte andere Beziehung (die "postcondition") über. Die Verifikationsregeln Die nachstehend beschriebene Verifikationsmethode entspricht dem Durchlaufen der Beweisregeln von der Folgerung zur Voraussetzung. Als Ausgangspunkt beim Beweis dient jeweils die zu beweisende Systemeigenschaft (die Systemspezifikation). Zum Bewahren der Übersicht auch bei größeren Systemen, werden die Regeln als Teilbaum formuliert und ein Beweisbaum wird konstruiert (s.u.). Für die Spezifikation der Wirkung wird folgende Schreibweise gewählt: P {A}Q P = precondition Q = postcondition A = Aktion (Algrithmenelement, Komponente oder System) 1. Regel für die Wertzuweisung: v := W Es gilt: P {v:=W} Q (Folgerung) falls erfüllt ist: P --> [QvW] (Voraussetzung) d.h., aus der precondition P folgt die postcondition Q, wenn man darin das freie Vorkommen von v durch W ersetzt. oder eine andere (etwas allgemeinere Formulierung) der Wirkung, hierbei ist V0 der Wert der Variablen V vor der Wertzuweisung: 218 Aus P(V0) & V = f(V0,Y)--> Q(V) folgt P(V) { V := f (V,Y) } Q(V) Die zweite Fassung, verbal ausgedrückt: Wenn aus der Gültigkeit von P für den Wert von V vor der Wertzuweisung und dem durch die Zuweisung erreichten neuen Wert von V die Beziehung Q folgt, dann hat die Zuweisung die gewünschte Wirkung. Beispiele: a) Sei P: X > 24 W und Q: X > V dann gilt: X > 24W {V := 24*W} X > V, weil erfüllt ist:X > 24 W --> [QV24W] b) Es gilt: x ganz & x > 0 {x := x -1} x >= 0, denn aus x > 0 & x ganz , folgt x-1 >= 0 = [Qxx-1], wenn Q : x >= 0 . 2. Regel für die Sequenz: Aus P {A1 } Q1 Q1 {A2} Q2 Q2 {A3} Q3 . . . Qn-1{An} Q folgt: P {A1; A2; . . .; An} (Voraussetzung) Q (Folgerung) Beispiel: Ein Programmstück S1 berechnet die Summe s der Elemente a1, a2, ..., an; Ein Programmstuck S2 berechnet aus s den Wert M=s/n. Aus TRUE {S1} s=a1+a2+.....+an s= a1+a2+...+an {S2} M = s/n folgt: TRUE {S1; S2} M= (a1+a2+...+an)/n 219 d.h. das zusammengesetzte Programm berechnet den Mittelwert. 3. Regel für die Alternative: Aus und P& B P & NOT B folgt: P {if B then A1 else A2} Q (Folgerung) Beispiel: Aus x reelle Zahl & x >= 0 und x reelle Zahl & x < 0 folgt {A2} {A1} Q Q (Voraussetzung) {y := x} y >= 0 {y := -x} y >= 0 x reelle Zahl {if x >= 0 then y:=x else y := -x } y >= 0 4. Regel für die while-Schleife: Aus und und P --> INV INV & B { A } INV INV & NOT B --> Q folgt: P { while B do A } Q (Falls die Schleife nach endlich vielen Schritten abbricht ("Partielle Korrektheit")) Beispiel: (Hier gleichzeitig Entwicklung des (partiell) korrekten Programms Summe der N Elemente eines Feldes a0, . . . , aN-1. Es soll ein Programm A entwickelt werden, für das gilt: N>=0 220 {A} s = ∑ aj 0<= j < N Als Invariante INV wählen wir: s = ∑ aj & 0<= i <= N 0 <= j < i Wir setzen am Anfang: i:= 0 ; s := 0; also gilt zu Beginn der Schleife P: i = 0 & s =0 Es gilt P--> INV, denn für i gleich 0 ist kein Element aufzusummieren, also auch die Summe gleich 0. Es gilt INV & i < N {s := s + ai ; i ++ } INV INV & i = N --> Q : INV & i = N folglich i = 0 & s=0 {while i < N do {s:=s+ai ; i++ }} s = ∑ aj 0<= j < N Wir haben also bewiesen: N >= 0 {i := 0; s := 0; while i < N do {s:= s + ai; i++; }} s = ∑ aj 0<= j < N 5. Regel für die repeat-Schleife Aus und und folgt: P {A} INV INV & NOT B { A } INV INV & B --> Q P {repeat A until B } Q 6.3.3.1 Baumförmige Darstellung der Verifikationsregeln 221 Die Verifikationsregeln lassen sich baumförmig darstellen, wenn wir die Verifikationsvoraussetzungen als Knoten darstellen, die durch Kanten mit der Verifikationsfolgerung verbunden sind. a) Wertzuweisung P --> [Q vW] P {v:=W} Q oder in der zweiten Fassung: P(V0) & V = f(V0,Y)--> Q(V) P(V) { V := f (V,Y) } Q(V) b) Sequenz P{A1 }Q1 Q1 {A2}Q2 Q2{ A3 } Q3 ... Qn-1 {An}Q P { A1 ; A2; . . . ; An } Q c) Alternative P& B {A1} Q P & NOT B {A2} Q P {if B then A1 else A2} Q d) While-Schleife 222 P --> INV INV & B { A } INV INV & NOT B --> Q P { while B do A } Q e) Repeat-Schleife P {A} INV INV & NOT B { A } INV INV & B --> Q P {repeat A until B } Q Die Verifikation eines Programmes verläuft so, dass ein "Verifikationsbaum" aufgebaut wird. Dieser enthält als Wurzel die Programmspezifikation. Mittels der Verifikationsregeln werden weitere Knoten entwickelt. Dies geschieht solange bis in den Blättern des Baums die Verifikationsbedingungen stehen. Falls alle Verifikationsbedingungen erfüllt sind ist der Beweis der Korrektheit für dieses Programm erfolgreich abgeschlossen, die (partielle) Korrektheit des Programms streng bewiesen. Beispiel: Es ist zu beweisen: Für X0, Y0 ganzzahlig, gilt: X > 0 & X = X0 & Y = Y0 { Z := 0; U := X; repeat 223 Z := Z + Y; U := U - 1; until U = 0 } Z = X0 * Y0 Als erster und wichtigster Schritt wird eine Invariante für die repeat-Schleife gesucht. Die geeignete Invariante (wie wir noch streng beweisen werden) ist: U * Y + Z = X0 * Y0 Wir nennen diese Invariante INV. Dass INV durch das Innere der Schleife nicht verändert wird, ist plausibel, da das Produkt U * Y jeweils bei einem Durchlauf um Y vermindert und Z um Y erhöht wird. Es werden folgende Abkürzungen im Verifikationsbaum benutzt: ENTRY EXIT INV0 INV1 INV2 Bed1 S0 S1 S2 224 ist ist ist ist ist ist ist ist ist X > 0 & X = X0 & Y = Y0 Z = X0 * Y0 X*Y + Z = X0 * Y0 U * Y + Z = X0 * Y0 INV1 & U >= 0 (U - 1) * Y + Z = X0 * Y0 Z := 0; U := X; Z := Z + Y; U := U-1; repeat S1 until U = 0 9 10 4 15 16 17 18 11 12 13 14 5 6 7 8 2 3 1 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ENTRY { S0; S2 } EXIT ENTRY {S0 } INV1 & U> 0 INV1 & U > 0 {S2 } EXIT ENTRY {Z := 0 } INV0 & X >0 INV0 & X > 0 {U := X } INV1 & U> 0 INV1 & U > 0 { S1 } INV2 INV2 & U <> 0 { S1 } INV2 (siehe 6.) INV2 & U = 0 --> Z = X0 * Y0 ENTRY & Z = 0 --> X * Y + Z = X0 * Y0 INV1 & X > 0 & U = X --> U * Y + Z = X0 * Y0 & U > 0 INV1 & U > 0 { Z := Z + Y } Bed1 & U > 0 Bed1 & U > 0 { U := U - 1 } INV2 siehe 11. siehe 12. U > 0 & U * Y + Zalt = X0 * Y0 & Z = Zalt + Y --> (U - 1) * Y + Z = X0 * Y0 & U > 0 Ualt > 0 & ( Ualt - 1 ) * Y + Z = X0 * Y0 & U = Ualt - 1 --> U >= 0 & U * Y + Z = X0 * Y0 siehe 15. 225 18 siehe 16. Wir haben durch den Beweisbaum folgendes Ergebnis erhalten: Der obige Algorithmus liefert das richtige Ergebnis, falls er bis zum Ende kommt, mit anderen Worten, wenn die Schleife nicht unendlich lange läuft. Man bezeichnet dies als den Beweis der partiellen Korrektheit. Um die totale Korrektheit eines Algorithmus festzustellen, müssen wir zusätzlich noch beweisen, dass das gewünschte Ergebnis nach endlich vielen Schritten auch wirklich erreicht wird, d.h., dass der Algorithmus wirklich endet. 226 6.3.3.2 Beweis der Endlichkeit von Algorithmen Die Endlichkeit eines Algorithmus ist genau dann gewährleistet, wenn alle zyklischen Programmteile ( also die Schleifen ) in endlich vielen Schritten vollständig durchlaufen sind. Hierzu müssen wir eine weitere Schleifeninvariante einführen bzw. finden. Falls wir einen Ausdruck e finden, für den vor und nach einem Schleifendurchlauf gelten muss: e >= 0, und dessen Wert bei jedem Durchlauf um mindestens 1 vermindert wird, dann ist die Endlichkeit der Schleife gesichert, denn es muss dann nach endlich vielen Durchläufen die Schleife verlassen werden, weil sonst für e gelten würde: e < 0, was nicht möglich ist. In unserem obigen Beispiel ist U ein solcher (ganzzahliger ) Ausdruck, denn da X > 0 gilt, ist U >= 0 eine Schleifeninvariante, aber U wird bei jedem Schleifendurchlauf um 1 vermindert. Damit ist die totale Korrektheit unseres kleinen Algorithmus bewiesen. Übungen: 1. Beweisen Sie: N<0 { N := N * N } N > 0 2. Beweisen Sie: A = A0 & B = B0 { T : = A; A : = B; B : = T } A = B0 & B = A0 3. Zeigen Sie, dass das folgende Programm, eine etwas abgeänderte und optimierte Form des behandelten Algorithmus, in Z ebenfalls das Produkt X0 * Y0 liefert, also: X>0 & X=X0 & Y=Y0 { Z:= 0; U:= X; while NOT U=0 do if (U mod 2 = 0) then { U:= U/2; Y=Y*2;} else { Z:= Z+Y; U:= U-1; } end; } 227 Z=X0*Y0 228 7 Testen Keine Software ist fehlerfrei. Beispiele, die diese Tatsache belegen, wie z. B. der Ausfall von Telefonnetzen oder Bahnhof-Leitsystemen, Absturz von ArianeRaketen, sind aus der Tagespresse bekannt. Diese Beispiele zeigen, daß Fehler in der Software sehr teuer werden können. Aber nicht nur die Folgen von SoftwareAusfällen sind teuer, auch die Kosten der Phase Test sind in großen oder sicherheitskritischen Projekten oft höher als die Entwicklungskosten. Die Phase Test in einem Software-Entwicklungsprozeß ist somit eine wichtige und kostspielige Phase. Bei den Aktivitäten in der Test-Phase werden Fehler in der zu prüfenden Software gesucht und (hoffentlich) entdeckt. Dadurch werden die Folgekosten von entdeckten Softwarefehlern erheblich reduziert. Je später im Entwicklungsprozeß ein Fehler entdeckt wird, um so höher sind die Kosten für seine Beseitigung. Ein erfolgreicher Test führt zur Entdeckung von Fehlern. Es ist durch Testen aber nicht möglich die Fehlerfreiheit von Software zu beweisen. 7.1 Testverfahren - Wie wird getestet? Ein Softwaresystem kann aus unterschiedlichen Sichten betrachtet werden, z. B. externe - interne, statische - dynamische Sicht. In jeder Sichtweise sind bestimmte Eigenschaften eines Systems sichtbar. Zur Überprüfung der Eigenschaften einer Software können verschiedene Testverfahren eingesetzt werden. Testverfahren helfen mit einem Minimum an Tests ein Maximum an Fehlern zu finden. Balzert klassifiziert in [Bal99, S. 509f] Testverfahren wie folgt: Dynamische Testverfahren • White Box Test, Strukturtest • Black Box Test, Funktionstest Statische Testverfahren • Walkthrough • Inspektionen Bei den dynamischen Verfahren wird die Software ausgeführt und mit konkreten Eingabewerten versehen. Bei den statischen Verfahren wird die Software nicht ausgeführt. Der Quellcode wird analysiert, mit dem Ziel Fehler zu finden. Vigenschow unterscheidet [Vig, S. 20ff] demonstratives Testen und destruktives Testen. In den ersten Bereich fällt z. B. der Entwicklertest, der zeigt, daß ein 229 Programm funktioniert. Destruktives Testen bezeichnet das systematische Testen von Software mit der Absicht Fehler zu finden. Black Box Test - Funktionstest Bei dem Black Box Test wird das Testobjekt (Klasse, Komponente, System) gegen seine Spezifikation getestet. Die interne Struktur des Testobjektes ist entweder unbekannt oder unwichtig. Die Testwerte werden aus der funktionalen Spezifikation abgeleitet. Mit einem Black Box Test kann herausgefunden werden, ob das Testobjekt den Anforderungen des Auftraggebers entspricht, bzw. in welcher Komponente ein Fehler auftritt. Zur genauen Lokalisierung eines entdeckten Fehlers sind weitere Tests oder Werkzeuge nötig. White Box Test - Strukturtest Beim White Box Test wird das Testobjekt gegen seine Kontrollstruktur (Implementierung) getestet. Die Kontrollstruktur kann mit Hilfe eines Kontrollflussgraphen dargestellt werden . Ein Kontrollflussgraph ist ein gerichteter Graph, der die Anweisungen und Verzweigungen im Quellcode des Testobjekts darstellt (siehe Kapitel 8.1.3 Das McCabe Maß). Der Kontrollflussgraph einer Komponente besteht aus Knoten (Anweisungen) und gerichteten Kanten (Strukturinformationen), die die Knoten verbinden. Die gerichteten Kanten nennt man Zweige. Den Weg durch eine Komponente von dem Anfangsknoten zu einem Endknoten nennt man Pfad. Durch die Berücksichtigung der Kontrollstruktur können auftretende Fehler wesentlich präziser, als bei einem Black Box Test, lokalisiert werden. Bei dem White Box Test werden die Testfälle so gewählt, daß die Anweisungen und Zweige eines Programms möglichst vollständig ausgeführt werden. Software kann wegen ihrer Komplexität nicht vollständig getestet werden. Es kann mit vertretbarem Aufwand nicht nachgewiesen werden, daß ein Programm fehlerfrei ist. Die nachfolgend aufgeführten Überdeckungsgrade dienen als Maße für den Umfang der durchgeführten Tests. Überdeckungsgrade werden meistens in Prozent angegeben. 80% Zweigüberdeckung bedeutet, daß 80 % aller Zweige bei Tests ausgeführt wurden. Die Anweisungsüberdeckung fordert die einmalige Ausführung aller Anweisungen eines Testobjekts. Die Zweigüberdeckung fordert die Ausführung aller Zweige eines Programms. Bei der Bedingungsüberdeckung werden die Bedingungen, die zu einer Verzweigung führen, getestet. Bei komplexen boolschen Bedingungen müssen alle Kombinationen von Bedingungen, die in den FALSE oder TRUE Zweig führen getestet werden; für die Zweigüberdeckung genügt die Ausführung einer Bedingung. Die Pfadüberdeckung fordert die Ausführung aller 230 Pfade durch ein Testobjekt. Für nicht-triviale Programme ist dieser Test nicht vollständig durchführbar, da die Anzahl der Pfade unendlich sein kann. Die kritischen Strukturen beim Pfadtest sind die Schleifen. Bei jedem Schleifendurchlauf ergibt sich ein neuer Pfad und damit eine neue Fehlermöglichkeit. Bei praktisch durchführbaren Pfadüberdeckungstests muß die Wiederholbarkeit von Schleifen eingeschränkt werden. (siehe Lig S. 64ff) Instrumentierung Um die im letzten Abschnitt beschriebenen Überdeckungsgrade messen zu können, werden in den Zweigen eines Testobjekts Zähler eingeführt. Daran kann festgestellt werden, welche Zweige bei einem Test ausgeführt wurden. Die Analyse des Quellcodes eines Testobjekts und das Einfügen der Zähler durch Testwerkzeug wird Instrumentierung genannt. Grey Box Test Der Grey Box Test ist eine Kombination aus Black Box und White Box Tests. Bei der Integration eines Gesamtsystems aus Teilkomponenten werden die Schnittstellen der Teilkomponenten getestet. Beim Grey Box Test ist die Komponentenstruktur bekannt; die Testfälle werden aus der Spezifikation abgeleitet. 7.2 Wie findet man Testdaten Äquivalenzklassenanalyse Es ist unmöglich ein Programm mit allen möglichen Eingabewerten zu testen. Zur Reduzierung des Testaufwands dient die Äquivalenzklassenanalyse. Die möglichen Eingaben in ein Testobjekt werden in Äquivalenzklassen eingeteilt. Alle Werte einer Äquivalenzklasse verursachen das gleiche Systemverhalten. Für jede Äquivalenzklasse wird, stellvertretend für alle Eingaben dieses Bereichs, ein Test durchgeführt. Die Testdaten werden aus Eingabewerten der Funktionen unter Berücksichtigung der Gültigkeitsbereiche gewählt. Grenzwertanalyse Bei dem Einsatz der Äquivalenzklassenanalyse sind die Übergänge zwischen den Äquivalenzklassen besonders kritisch; dort treten häufig Fehler auf. Es können Fehler entstehen durch die Verwendung falscher Vergleichsoperatoren (< statt <=), Zähler können falsch eingesetzt werden (Beginn bei 0 oder 1). Deswegen müssen die Übergänge zwischen den Äquivalenzklassen besonders getestet werden. Die entsprechenden Testfälle findet man durch die Grenzwertanalyse. Man 231 wählt als Testdaten Eingabewerte an der Grenze von Äquivalenzklassen und überprüft, ob die entsprechenden Extremwerte in den Algorithmen richtig behandelt wurden. 7.3 Wer testet? Alle Tests, deren Testgegenstand eine kleine Softwareeinheit ist, wie z. B. eine Klasse, Methode oder ein Objekt werden während der Entwicklung vom Entwickler getestet. Diese Tests dienen jedoch primär dem Nachweis, daß die entwickelten Softwareeinheiten die geplante Funktion erfüllen. Sie fallen in den Bereich des demonstrativen Testens. Die Entwickler von Software sind aus psychologischen Gründen nicht geeignet für das destruktive Testen. Sie können ihrem eigenen Werk - der Softwareeinheit - nicht mit der notwendigen destruktiven Einstellung entgegentreten. Das destruktive Testen - die aktive Suche nach Fehlern in der Software - sollte deshalb immer von einem Tester oder einem Testteam durchgeführt werden. Nur Personen, die nicht mit der Entwicklung der Software beschäftigt waren, haben die nötige objektive Distanz zu dem Produkt, um Fehler zu finden. 7.4 Testen von objektorientierter Software Die meisten Testverfahren stammen aus der vor-OO-Zeit, sind jedoch auch auf OO-Software anwendbar. In der vor-OO-Zeit bestand ein Programm aus Modulen, die Module enthielten Funktionen oder Prozeduren. OO-Software ist prinzipiell genauso aufgebaut, enthält aber zusätzlich die Konzepte der Klasse, Vererbung und Polymorphie. Klassen können in einer Vererbungshierarchie angeordnet sein und Methoden und Attribute von übergeordneten Klassen erben. Methoden können in abgeleiteten Klassen überschrieben werden. Dynamisch gebundene Methoden können in Abhängigkeit des Objekts bei dem sie aufgerufen werden zu unterschiedlichem Verhalten führen. Objektorientierte Software besteht aus vielen miteinander interagierender Einheiten (Klassen, Packages). Die Komplexität der einzelnen Einheiten ist relativ gering (und einfach zu testen). Die Abhängigkeiten zwischen den Einheiten ist aber groß. Öffentliche Methoden einer Klasse können von Methoden anderer Klassen aufrufen werden. Wird eine Klasse von einer anderen Klasse abgeleitet, ist die 232 abgeleitete Klasse von der Oberklasse abhängig. Methoden können den Zustand von Objekten ändern und so über die Zustandsattribute gekoppelt sein. Dadurch entstehen viele Abhängigkeiten, die das Testen von objektorientierter Software sehr aufwändig machen (vgl. [SnWi S. 22-25] und [Vig S. 93ff]). 7.5 Teststrategie Ein Softwaresystem wird aus seinen Komponenten zusammengesetzt. Es wird entsprechend seiner Struktur schichtweise zusammengebaut und getestet. Die Integration erfolgt entweder top-down oder bottom-up. Die jeweils fehlende Schicht wird durch Testtreiber simuliert. Bild aus [FiRi] Funktionstest, Klassentest Bei diesen Tests ist bei Einsatz einer OO-Sprache eine Methode, Klasse oder Objekt der Testgegenstand. Die Tests werden von den Softwareentwicklern selbst durchgeführt. Es werden meistens White Box Test eingesetzt. Beim Klassentest werden alle öffentlichen Methoden einer Klasse getestet. Eine Klasse kann Methoden von anderen Klasse erben und über Assoziationen mit anderen Klassen in Beziehung stehen. Diese Beziehungen einer Klasse zu den Klassen ihrer Umgebung müssen beim Testen berücksichtigt werden. Die Klassenstruktur muss entlang der Vererbungsstruktur getestet werden (siehe [Vig S. 93ff]) und sie muss 233 entlang der Assoziationen getestet werden. Wenn die Umgebungsklassen nicht zur Verfügung stehen müssen sie durch Stellvertreterobjekte simuliert werden. Modultest, Integrationstest Softwaresysteme bestehen aus mehreren Modulen, die einen bestimmten Zweck erfüllen und als Einheit gekapselt sind. Im Modultest werden die Funktionen der Module (Teilsysteme) getestet. Im Integrationstest wird das Zusammenspiel der Module getestet. Hier werden White, Grey und Black Box Tests eingesetzt. Systemtest, Anwendertest Im Systemtest wird das fertige Gesamtsystem getestet. Es wird getestet ob das System die geplante Funktion erfüllt; es wird die Bedienbarkeit und die Installation getestet. Das Verhalten des Systems unter Last wird überprüft. Der Anwender überprüft am Ende des Entwickungszyklus die Akzeptanz des Systems, die Robustheit und Stabilität während des Betriebs. Es werden hier hauptsächlich Black Box Testverfahren eingesetzt. 7.6 Testwerkzeuge Es sind verschiedene Tools auf dem Markt, die Testplanung und Testmanagement, die Durchführung dynamischer und statischer Tests unterstützen und eine Automatisierung von Testabläufen ermöglichen. Werkzeuge zur Automatisierung von GUI-Tests verwenden Skriptsprachen um die GUI-Elemente aufzurufen und mit Werten zu versorgen. Tools für Last- und Performancetests werden benötigt, um ein System unter Last zu setzen und mögliche Engpässe zu erkennen und zu beseitigen. Eine ausführliche Klassifizierung von Testwerkzeugen findet sich in [SnWi, Kapitel 11]. Eine kleine Auswahl stellt nachfolgende Liste dar: • • • • • WinRunner/Mercury Rational Robot/IBM SilkTest/Segue QA-C++/QA-Systems Telelogic Tau/Telelogic 7.7 xUnit, JUnit 234 xUnit steht für eine Familie von Open Source Frameworks, die Entwickler bei der Durchführung und Automatisierung von Tests unterstützen. Die Frameworks stehen für verschiedene Programmiersprachen zur Verfügung. Die Java Variante JUnit unterstützt die Erstellung der Tests in Java. Die Frameworks sind im Umfeld von XP entstanden und als Open-Source-Projekte realisiert worden (siehe http://c2.com/cgi/wiki?TestingFramework). Bei einer testgetriebenen, inkrementellen Entwicklung, wie XP sie vorschlägt, ist zur wirtschaftlichen Durchführung der Tests eine Testautomatisierung unerläßlich. Bei Einsatz der xUnit-Frameworks erstellen Entwickler die Tests in der selben Sprache in der auch die zu testende Anwendung entwickelt wird. Die Durchführung der Tests und die Überprüfung der Ergebnisse erfolgt automatisch. Jeder Testfall ist von allen anderen Testfällen unabhängig, damit bei einem auftretenden Fehler nicht der vollständige Testlauf abgebrochen wird. Jeder Testfall kann erfolgreich durchlaufen werden, oder einen Fehler verursachen. Zur Überprüfung der Testergebnisse werden Zusicherungen (assertions) verwendet. Die Testergebnisse werden aufgezeichnet. XP unterscheidet zwei Testebenen (vgl. Kapitel 4.7 eXtreme Programming): • Acceptance Tests werden von dem Kunden definiert und von den Entwicklern implementiert. • Unit Tests erstellen die Programmierer bevor sie die Units (Klassen, Packages, Komponenten, Module) implementieren. Diese Vorgehensweise wird testgetriebene Entwicklung (test-driven development) genannt. Die Integration der Units zu einem Gesamtsystem erfolgt erst, wenn alle Unit Tests erfolgreich laufen. 235 Struktur von xUnit, JUnit Klassendiagramm von xUnit (aus [JUcook]) Das Klassendiagramm in Bild NR beschreibt die Struktur von JUnit. Bei der Realisierung von xUnit wurden mehrere Entwurfsmuster eingesetzt. Die grau hinterlegten Pfeile bezeichnen die Entwurfsmuster, bzw. die Elemente der Muster. xUnit besteht aus 4 Klassen (siehe Bild NR). Über das Composite-Pattern ergibt sich daraus eine Baumstruktur aus Testfällen und Testsuiten. Das abstrakte Interface Test wird vererbt an die Klassen TestCase und TestSuite. Wird ein Testfall geschrieben, so wird dieser von TestCase abgeleitet. Die Methode setUp() wird vor jedem Test aufgerufen. Sie führt alle Initialisierungen (z. B. der Instanzvariablen) durch. Die Methode tearDown() sorgt nach jedem Testfall für einen definierten Endzustand. Die Methode runTest() ruft den Testfall auf, run (TestResult) übergibt das Ergebnis des Tests an die Klasse TestResult, in der die Ergebnisse gespeichert werden. Werden mehrere Testfälle benötigt, dann wird die Klasse TestSuite verwendet. Diese Klasse fügt über die Methode addTest(Test) einen Testfall in eine Menge von Tests, die TestSuite, ein. Die Klasse TestSuite hat eine Aggregationsbeziehung zu Test. Dadurch kann eine TestSuite mehrere Exemplare von TestCase und TestSuite enthalten. Die Struktur von JUnit ist ausführlich beschrieben in dem Dokument JUnit A Cook's Tour (http://junit.sourceforge.net/doc/cookstour/cookstour.htm). 236 Vorgehensweise Bei Einsatz von JUnit für einen Testfall geht man wie folgt vor: 1. Erzeugen einer Unterklasse von TestCase 2. Überschreiben der Methode runTest() 3. Test starten. Ein ausführliches Beispiel zur Verwendung von JUnit findet sich in dem Dokument JUnit Cookbook (http://junit.sourceforge.net/doc/cookstour/cookstour.htm). Literatur [Bal99] Helmut Balzert, Lehrbuch - Grundlagen der Informatik, Spektrum Akademischer Verlag, 1999. [FiRi] Daniel Fischer, Marc-Oliver Richter, Schwarze Kunst, Black-BoxMethoden zum GUI-Testen, in iX 11/2001, S. 52-55, Heise. [JUcook] Kent Beck, Erich Gamma, JUnit http://junit.sourceforge.net/doc/cookstour/cookstour.htm und Cookbook, [Lig] Peter Liggesmeyer, Modultest Wissenschaftsverlag, 1990. Modulverifikation, BI [Link] Johannes Link, Softwaretest mit JUnit, dpunkt.verlag, 2005. [SnWi] Harry M. Sneed, Mario Winter, Testen objektorientierter Software, Hanser, 2002. [Vig] Uwe Vigenschow, Objektorientiertes Testen und Testautomatisierung in der Praxis, dpunkt.verlag, 2005. 237 8 Konfigurationsmanagement 8.1 Warum Konfigurationsmanagement (KM)? Heutige Software-Entwicklungsprojekte zeichnen sich durch eine hohe Komplexität aus (vgl. [Brö00]). In SW-Entwicklungsprojekten entsteht eine Vielzahl von Software-Elementen (Artefakte), die im Laufe des Projektes iterativ in den verschiedenen Phasen geändert bzw. weiterentwickelt werden. Zentrale Artefakte sind z. B. Anforderungsdokumente, Architekturbeschreibungen, Grafiken sowie der Quellcode der verschiedenen Module/SW-Komponenten. Diese SWElemente (auch KM-Items genannt) können in unterschiedlichen Dateisystemen auf verteilten Plattformen/Rechnern sowie in unterschiedlichsten Formaten vorliegen. In der Regel bedingen heutige Entwicklungen die Einhaltung einer bestimmten Produktionskette (vom Entwicklungssystem bis zum Produktivbetrieb). Erfolgreiche Projekte basieren auf einem guten Management dieser Artefakte durch eine transparente Ablagestrategie sowie einzuhaltender Konventionen (z. B. Namenbildungsregeln für die Artefakte). Idealerweise kann zu jedem Zeitpunkt, d.h. während des gesamten Lebenszyklus des Anwendungssystems, Teile von dem Anwendungssystem oder auch das gesamte Anwendungssystem aus den Entwicklungsdaten ohne manuelle Eingaben reproduziert werden. Die hierfür notwendigen Informationen zu den Entwicklungsdaten werden zentral gespeichert. Das Konfigurationsmanagement stellt ein wichtiges Mittel dar, um Änderungen effektiv durchzuführen und diese auch später noch nachvollziehen zu können. Beim Aufbau der SW-Entwicklungsumgebung (SEU) muss berücksichtigt werden, dass die Änderung der verschiedenen Software-Elementen geordnet und nachvollziehbar erfolgt. 8.2 Was ist (Software-)Konfigurationsmanagement (SKM)? Ein Produkt durchläuft im gesamten Lebenszyklus (= Produktlebenszyklus) verschiedene Zustände, die sich in unterschiedlichen Produktstrukturen widerspiegeln können. Unter dem Begriff Konfigurationsmanagement fasst man vielfältige Aufgaben zusammen (wie z. B. Produktplanung sowie Produkt- und Konfigurationsverwaltung), die die verschiedenen Produktzustände effektiv verwalten. Der KM-Begriff stammt ursprünglich aus dem Maschinenbau und wurde auch auf die Software-Entwicklung adaptiert. In der Softwareentwicklung bezeichnet der 238 Begriff des Software Konfigurations-Managements (SKM) die Disziplin zur Verfolgung und Steuerung der Evolution von Software. KM wurde durch die Internationale Standards Organisation für die SW-Entwicklung standardisiert (-> Richtlinienwerk DIN EN ISO 9001, [Brö00]). Konfigurations-Management wurde ca. 1950 für die US-Luft- und Raumfahrtindustrie eingesetzt (z. B. im Apollo-Programm zur Verfolgung Tausender von Änderungen). In den 70er Jahren des letzten Jahrhunderts wurden Werkzeuge wie z. B. SCCS (Source Code Version Control Management Software) und MAKE etabliert. Heutzutage ist anerkannt, dass SKM-Werkzeuge eine hohe Bedeutung für Softwareprojekte besitzen. Moderne Werkzeuge (wie z. B. CVS [CVS04] und ANT [Ant04]) sind anspruchsvoll und bedingen eine Lernphase bevor diese effizient genutzt werden können. 8.3 Einsatz von Software-Konfigurationsmanagement in Projekten Software ist durch Anpassungen, Erweiterungen oder Korrekturen einem ständigen Änderungsprozess unterworfen. Das Hauptaugenmerk beim SKM liegt bei der Unterstützung der Nachvollziehbarkeit von Änderungen sowie der Produktion zumeist zahlreicher Software-Freigaben (Releases). Wird die Entwicklung durch Teams durchgeführt und bearbeiten mehrere Entwickler das gleiche Softwareobjekt, muss festgelegt sein, welches Prinzip angewandt werden soll. Ein Prinzip könnte sein, dass die jeweils letzte Änderung vorherige Änderungen einfach überschreibt („last save wins“). Alternativ kann auch das gleichzeitige Ändern untersagt werden, um evtl. ungewolltes Überschreiben grundsätzlich zu verhindern. In der Regel bestehen Abhängigkeiten zwischen den einzelnen Softwarekomponenten. Bei der Modifikation einer Komponente ist es daher oft nötig auch die davon abhängigen Komponenten anzupassen. Ändert sich beispielsweise die Schnittstelle einer Komponente, müssen Anwendungsteile, die diese Schnittstelle verwenden, ebenfalls angepasst werden. Ist die Menge der von einer Komponente abhängigen Teile nicht bekannt, muss diese bei jeder Änderung erst mühsam (evtl. manuell) ermittelt werden. Wird dabei eine Komponente, die eigentlich angepasst werden müsste, nicht beachtet und keine unmittelbare Fehlermeldung im Kompositionsprozess angezeigt, können so neben dem Zeitverlust auch Fehler entstehen, die mit erhöhtem Kostenaufwand wieder korrigiert werden können. 239 Um diesen Probleme entgegenzuwirken, enthält ein SKW-Werkzeug mächtige Änderungs- und Build-Management-Funktionen. Um die Reproduzierbarkeit der einzelnen Produkteigenschaften zu gewährleisten, bildet das Konfigurationsmanagement die diversen Produkt-Zustände in sog. Konfigurationsmappen ab. Hierbei sind verschiedene Anforderungen an die eingesetzten Techniken und Verfahren zu stellen. Jeder Entwickler hat zur erfolgreichen Durchführung des SKM zusätzlich zu seiner Arbeit am Produkt für das SKM einen Mehraufwand zu leisten. Der hieraus erwachsende Nutzen sollte jederzeit ersichtlich sein. Um dieses Bewusstsein und die Fähigkeit zur Bedienung der Werkzeuge zu fördern, sind Schulungsmaßnahmen durchzuführen. Nachfolgend werden wichtige Funktionen Konfigurationsmanagement Systems genannt: eines idealtypischen - Verwaltung aller Projektergebnisse (unabhängig vom verwendeten Dateiformat) - Verwaltung und automatisierte Pflege der Abhängigkeitsbeziehungen (Verweise) zwischen den SW-Elementen - Konsistenzsicherung zwischen den verschiedenen abhängigen SW-Elementen - Unterstützung von Änderungen an textuellen und graphischen Entwicklungsmodellen (wie z. B. Analyse- und Entwurfsmodellen) Die einzelnen Aufgaben des SKM kann man nach ihrer Wichtigkeit ordnen. Die Basis bildet die Kontrolle der Versionen einzelner SW-Elemente. Darauf aufbauend liegen Konfigurationen sowie Einstellungen für die Kompositionsprozesse im Rahmen des Build-Management. Hat eine Freigabe der Software stattgefunden, gewinnen Verfolgung und Koordination von Änderungsprozessen an Bedeutung. In dieser Phase des SW-Lebenszyklus muss ein effizientes Änderungsmanagement etabliert sein. Letztendlich fügt sich das SKM in den Gesamtprozess der Softwareentwicklung (z. B. bei V-Modell oder RUP) ein. In dem jeweiligen Vorgehensmodell sind daher entsprechende KMAbschnitte enthalten. Ziel und Aufgabe des SKM ist es, all diese Bereiche möglichst automatisiert und verteilt auf unterschiedlichen Plattformen (LAN, WAN, …) abwickeln zu können. 240 Verteilung (LAN, WAN; …) Vorgehensmodell Änderungsmanagement Konfigurationsmanagement Versionsmanagement Abbildung: Aufgaben von SKM Der in einem Projekt eingesetzte Entwicklungsprozess sollte von Anfang an SKM berücksichtigen. Schon sehr früh entstehen in einem Projekt wichtige Dokumente (wie z. B. der Projektplan und die Risikoliste), deren Änderungen nachvollziehbar sein sollten. Ist ein Projekt abgeschlossen, können die einzelnen SW-Elemente auch in anderen Projekten wieder verwendet werden. Dies sollte durch den Einsatz eines SKMWerkzeugs gefördert werden. Dies kann in der Weise geschehen, dass Projektergebnisse in einem zentralen Repository (Projektbibliothek) gespeichert werden oder Informationen über Intranets oder Entwicklerportale veröffentlicht werden. Nach dem ersten Rollout der Software ist ein besonderes Änderungsmanagement zu etablieren. Dieses hat u. a. die Aufgabe, die aufgetretenen Problem- und Fehlermeldungen zu erfassen und zu verwalten. In der nachfolgenden Abbildung sind abschließend die möglichen Zustände einer Änderung und die zugehörigen Formulare (kursive Schrift) dargestellt (vgl. [Balz96]). Änderungsvorschlag Änderungsauftrag Änderungen Abbildung: Änderungsmanagement entschließen u. Änderung bewerten beabsichtig t einleiten Änderungsantrag/Problemmeldung bean tragt beauftra gt Änderungsmitteilung Änderung abschliessen erledig t 241 Änderungs vorschlag ablehnen abgelehnt Änderung bewerten 8.4 Weiterführende Literatur [Ant04] [Balz96] Apache ANT, http://ant.apache.org/, zuletzt besucht 11/2004. H. Balzert, Lehrbuch der Software-Technik: Software-Entwicklung, Spektrum Akademischer Verlag, 1996. [Brö00] P. Brössler, J. Siedersleben (Hrsg.), Softwaretechnik: Praxiswissen für Software-Ingenieure, Hanser, 2000. [CVS04] CVS, http://www.cvshome.org/, zuletzt besucht 11/2004. 242 9 Petri-Netze Während bei vielen Methoden nicht vorgesehen ist, gleichzeitig stattfindende Vorgänge mit ihren Abhängigkeiten zu beschreiben, ermöglichen Petri-Netze sowohl die Darstellung der elementaren logischen Strukturen als auch deren möglichen parallelen Ablauf. 9.1 Zustände und Ereignisse Kernelemente von Petri-Netzen sind • Zustände (statische Knoten) und • Ereignisse (dynamische Knoten). Zustände können durch Ereignisse in neue Zustände übergehen. Die Zustände können die Bedingungen anzeigen, unter denen die Ereignisse stattfinden. Der ständige Wechsel von Ereignissen und neuen Zuständen zwingt den Benutzer dieser Methode, sich darüber klar zu werden, welche Zustände zu welchen Ereignissen führen, und welche Ereignisse notwendig sind (oder welche Bedingungen erfüllt werden müssen), um die gewünschten Zustände zu erreichen. Ein Petri-Netz ist demzufolge ein gerichteter Graph, der aus Kanten und Knoten besteht und folgende Eigenschaften aufweist: • Es gibt zwei Arten von Knoten: • den Bedingungs- bzw. Zustandsknoten (´Stelle´) • den Ereignisknoten (´Transition´). • Die Knoten treten nicht isoliert auf. • Die Pfeile laufen von Stelle zu Transition oder von Transition zu Stelle. • Die Anzahl der zu einem Knoten hinführenden Pfeile kann verschieden sein von der Anzahl der wegführenden Pfeile. Mit Hilfe solcher Petri-Netze können z.B. folgende Frage beantwortet werden: • Welche Vor- und Nachbedingungen weisen die Aktionen auf? • Nach welchen Vorschriften werden die Abläufe im System gesteuert? • In welcher Reihenfolge laufen Aktionen ab? • Welche Funktionsbereiche kommunizieren über welche Informationseinheiten miteinander? 243 Zur Erstellung von Petri-Netzen sind im Wesentlichen drei Symbole notwendig: Zustandsknoten Ereignisknoten oder Verbindungspfeile 9.2 Dynamik in Petri-Netzen Um die ablaufenden Prozesse verfolgen zu können, kann eine Stelle mit einer Markierung (schwarzer Mittelpunkt ) versehen werden, die anzeigt, dass die Bedingung erfüllt oder der Zustand eingetreten ist. Ein Vorteil von Petri-Netzen ist es, mit Hilfe dieser Marken nebenläufige oder parallele Prozesse (concurrency) darstellen zu können. Von ganz besonderer Bedeutung ist dabei, zu erkennen, an welcher Stelle des Petri-Netzes Konfliktsituationen auftreten können und ob Blockierungen des dynamischen Flusses zu erwarten sind. Das von anderen Methoden her bekannte Prinzip der schrittweisen Verfeinerung ist auch bei Petri-Netzen anwendbar, so daß ebenfalls eine top-down-Vorgehensweise möglich ist. Übersichtlich gestaltet wird dies durch entsprechende Nummerierungen. 9.3 Regeln in Petri-Netzen In der folgenden Übersicht werden die einzelnen Regeln beschrieben, nach denen Petri-Netze aufgebaut sein können: Regeln 244 Z1 E1 Z2 Es dürfen nur Knoten unterschiedlicher Art direkt miteinander verbunden werden: Ein Zustand (eine Stelle) führt immer direkt zu mindestens einem Ereignis (einer Transition) und das wiederum direkt zu mindestens einem Zustand (einer Stelle). E2 Z1 E1 Ein Ereignis (eine Transition, hier E1) kann mehrere direkte Vorgängerstellen (Zustände), die "Eingangsstellen", und mehrere direkte Nachfolgerstellen (Zustände), die "Ausgangsstellen", besitzen. Z4 Z2 Z5 Z3 E1 E3 Z3 Z1 Ebenso kann eine Stelle (ein Zustand, hier Z3) mehrere Eingangs- oder Ausgangs-ereignisse (Transitionen) aufweisen. E4 E2 Z2 E5 Z1 Z4 E1 Ein Ereignis wird nur dann stattfinden (eine Transition wird aktiv), wenn alle Eingangsbedingungen erfüllt sind, d.h. alle Eingangsstellen eine Marke tragen. Z2 Z5 Z3 Z1 Z4 E1 Z2 Z5 Z3 Findet das Ereignis einer aktivierten Transition statt, so schaltet oder "feuert" die Transition. Dieser Übergang von den Eingangsstellen zu den Ausgangsstellen wird so dargestellt, dass die Markierung bei allen Eingangsstellen entfernt und bei allen Ausgangsstellen hinzugefügt wird. Abb. Regeln für den dynamischen Ablauf in Petri-Netzen Diese Grundregeln sind bei der Darstellung und Simulation von Situationen stets einzuhalten. Trotz dieser einfachen Regeln sind aufgrund der vielfältigen Anordnung sehr komplexe Situationen darstellbar. 245 9.4 Komplexe Situationen in Petri-Netzen Wesentliche komplexe Situationen in Petri-Netzen sind die Nebenläufigkeit, bei der parallele Vorgänge simuliert werden und Blockierung (deadlock), bei der durch die Anordnung von Stellen und Transitionen gewollte oder ungewollte Situationen auftreten, die nicht auflösbar sind. Die folgende Abbildung zeigt die beiden Situationen. Z3 Z1 Z4 Z2 Z5 Nebenläufigkeit (concurrency) Z6 E2 Z7 E1 Sind mehrere Ereignisse aktiviert, können alle Ereignisse (die keine gemeinsamen Eingangsstellen haben, hier E2 und E3) willkürlich feuern. Damit sind parallel ablaufende Vorgänge darstellbar. E3 E2 Blockierung (deadlock) Z3 E1 Z2 Z1 Abb. Komplexe Situationen 9.5 Kontakt- und Konfliktsituation 246 Wenn kein Ereignis aktiviert werden kann, weil z.B. zwei Eingangsstellen niemals gleichzeitig markiert werden können, ist dieser Zweig des PetriNetzes blockiert. Es liegt entweder ein Entwurfs- oder Darstellungsfehler vor, oder aber die dargestellte Situation stellt eine reale Blockade dar. Kontakt- und Konfliksituationen treten dann auf, wenn durch die Markenbelegung ein Schalten nicht möglich ist (Kontakt) bzw. durch die Konstellation des Netzes unterschiedliche Schaltungen bei gleichem Ausgangszustand möglich sind. Die folgende Abbildung zeigt die beiden Situationen. Z1 Z3 E1 Z2 Z4 E1 E2 Kontakt Z4 ist makiert 2 E1 kann nicht schalten, obwohl Z1 und Z2 markiert sind. Konflikt Schalten von E1 (bzw. E2), führt dazu, dass E2 (bzw. E1) nicht mehr schalten kann andere Darstellungsweise: 1 2 Abb. Kontakt- und Konfliktsituationen 9.6 Gabel und Zusammenführung Die folgenden Situationen zeigen die typische Konstellation bei Graphen, wenn in einen Knoten zwei Kanten einlaufen und eine wieder heraus oder – umgekehrt – eine Kante hineinläuft und zwei wieder hinaus. Die Abbildung zeigt die daraus entstehenden vier Situationen. 247 Stelle Verzweigung (branch) Beim Markenspiel kann nur ein Zweig durchlaufen werden Begegnung (Wettbew.) (meet) Nur über einen Zweig kann die Marke belegt werden (logisches XOR) Transition Aufspaltung (split) Sammlung (wait) Die Wirkung wird gleichberechtigt verteilt, d.h. ein Pfeil löst mehrere nebenläufige Aktionen aus (beide auslaufenden Pfeile transportieren beim Schalten eine Marke) Es kann erst geschaltet werden, wenn alle einlaufenden Pfeile eingetroffen sind (aufeinander gewartet haben; logisches UND) Abb. Gabel und Zusammenführung 9.7 Beispiele von Petri-Netzen Das Hauptmann von Köpenik-Problem eignet sich, um die Blockierung eines PetriNetzes aufzuzeigen. Die Abbildung zeigt das passende Petri-Netz. 248 Abb. Das Hauptmann von Köpenik-Problem (Blockierung) Liegt in Z1 eine Marke, in Z2 und Z3 aber nicht, dann liegt das Problem des Hauptmannes von Köpenick vor. Die Arbeitserlaubnis (E1) kann nicht gegeben werden, da keine Aufenthaltsgenehmigung (Z3) vorliegt. Daher wird Z2 (Arbeit bei einer Firma) nicht erfüllbar sein. Ohne die Arbeit bei einer Firma, gibt es allerdings keine Aufenthaltsgenehmigung (Z3). Es liegt die bekannte Blockierung vor (weder Arbeit noch Aufenthaltsgenehmigung können erlaubt werden). Im folgenden Beispiel wird ein einfaches Betriebssystem in seinem Ablauf simuliert. Dieses System kann nur jeweils einen Auftrag abarbeiten, bevor der nächste Auftrag gestartet werden kann. Voraussetzung für dieses restriktive Vorgehen ist, dass es nicht erlaubt ist, dass mehrere Marken in einem Zustandsknoten liegen können. 249 Abb. Ein einfaches Betriebssystem-Modell Für ein weiteres Anwendungsbeispiel wird ein sehr einfacher und von vielen Einflußfaktoren (vor allem der Zeit) ‘bereinigter’ Ausschnitt eines Flug- und Flugzeugumlaufplans unterstellt, in dem lediglich die Zuordnung von Flugzeugen zu Flugstrecken (Flug-Nr.) und Umsteigemöglichkeiten für Passagiere (‘Zubringerfunktion’) zu beachten sind. Mit dem ersten Fall ist eine notwendige technische, mit dem zweiten Fall eine ökonomisch erwünschte Bedingungsklasse für den Flugverkehr eingeführt. Beide sollen im Folgenden jedoch zunächst unterschiedslos als ‘unabdingbare’ Bedingungen behandelt werden. Der ‘Flugplanaussschnitt’ sieht folgende Aktionsmuster vor: Flug-Nr. Strecke 151 131 141 211 511 411 250 Köln (CGN=5) – Frankfurt (FRA=1) München (MUC=3) - Frankfurt Düsseldorf (DUS=4) - Frankfurt Frankfurt - Hamburg (HAM=2) Frankfurt - Köln Frankfurt - Düsseldorf Flugzeug Zubringer für Flug-Nr. A B 211,411 C C B A Setzt man nun als Ereignis die Flug-Nr., die für den Controller zugleich Informationen über die Strecke und die Abwicklungszeit beinhaltet, und als Zustände alle die Bedingungen, die für die Realisierung der Flug-Nr. unabdingbar sind (sein sollen), hier also ‘Flugzeug Z für Flug-Nr. X vorhanden’ (z.B. ‘A 151’), ‘Flugzeug Z für Flug-Nr. X flugbereit’ (z.B. ‘A 151 ok’) und ‘Umsteigepassagiere von Flug-Nr. X für den Weiterflug bereit’ (z.B. ‘PAX 131’), so können dem Flugplan hinsichtlich Flug-Nr. 252 die folgenden Zustands-Ereignis-Abbildungen entnommen werden: Jedes Element dieser Auflistung wird in der Sprache der Petri-Netz-Theorie als Abbildung eines Prozesses bezeichnet (z.B. „Der Zustand ‘Flugzeug A 151 befindet sich am Boden’ wird durch Ereignis 151 beendet“). Die Gesamtheit der in dieser Form systematisch aufgelisteten Prozesse eines Flugplans heißt das zugehörige ‘unverbundene Netz’. Die Verbindung der Elemente des unverbundenen Netzes zu einem zusammenhängenden Prozeßnetz ist gleichbedeutend mit der Definition der coRelation. Hier verlangt die Ermittlung der co-Relation eine systematische Überprüfung und Fixierung der im Flugplan zum Ausdruck gebrachten (geplanten, aber durchaus nicht unproblematischen, weil z.B. durch Nebel und ähnliches störanfälligen) Zusammenhänge zwischen den einzelnen Prozessen. 251 Dieses Netz entspricht einer möglichen Übersetzung des Flugplanes in ein PetriNetz und zwar hier in ein zustandsunverzweigtes Netz, also ein Synchronisationsnetz. 9.8 Varianten von Petri-Netzen Für Petri-Netze sind verschiedene Varianten entwickelt worden, die für jeweils unterschiedliche Problemklassen entwickelt wurden. Die folgenden Varianten sind [Balzert] entnommen: 252 9.8.1 Bedingungs-/Ereignis-Netze Bedingungs-/Ereignis-Netze zeichnen sich dadurch aus, dass die Objekte bzw. Marken vom Typ boolean sind. Transitionen werden als Ereignisse interpretiert. Stellen bilden dann Bedingungen. Jede Stelle kann genau eine oder keine Marke enthalten. Eine Transition t kann schalten, wenn jede Eingabestelle von t eine Marke enthält und wenn jede Ausgabestelle von t leer ist. 9.8.2 Stellen-/Transitions-Netze Stellen können bei dieser Variante mehrere Marken enthalten. Transitionen müssen so viele Marken beim Schalten wegnehmen oder hinzufügen, wie die Gewichte an den Pfeilen angeben. Soll eine Stelle eine Kapazität größer 1 erhalten, dann wird dies durch „K = ...“ an der Stelle notiert. Die Kapazität definiert die maximale Anzahl von Marken, die auf einer Stelle liegen dürfen. Mit dieser Variante ist eine höhere Komplexität der Beziehungen darstellbar. Jedoch erfordern die Stellen-/ Transitions-Netze eine klare Übersicht über das System und sind in ihrer Anwendung sehr komplex. 253 10 Entscheidungstabellen 10.1 Grundlagen Entscheidungstabellen (ET) dienen dazu, Entscheidungsprozesse in übersichtlicher, tabellarischer Form darzustellen und helfen somit komplexe Verarbeitungsregeln zu spezifizieren. Eine Entscheidungstabelle fasst eine Menge aussagenlogischer Regeln zusammen. Entscheidungstabellen wurden 1957 in einer Projektgruppe der General Electric Company entwickelt und sind in DIN 66241 genormt [Balz96]. Eine Entscheidungstabelle besteht im Wesentlichen aus vier Quadranten für 2. Bedingungen 3. Aktionen 4. Bedingungsanzeiger und 5. Aktionsanzeiger Bei einer ET werden die Bedingungsanzeiger mit den jeweiligen Aktionsanzeiger verknüpft. Jede Spalte stellt hierbei eine Regel dar, die durch eine Regelnummer eindeutig bezeichnet wird. Die Regelnnummern werden über den Bedingungsanzeigerquadranten notiert. Nachfolgend ist die Basis-Struktur einer Entscheidungstabelle dargestellt. E n ts c h e id u n g s re g e ln R B B e d in g u n g e n B n bzw . -a u sp rä g u n g en i A 1 A j . . . . . . . . . . . . . . R B e d in g u n g s a n z e ig e r 1 - 1 A k tio n s a n z e ig e r A k tio n e n bzw . -a u sp rä g u n g en Abbildung: Struktur einer Entscheidungstabelle [Sch86], [Sch90] Um eine Entscheidungstabelle aufzubauen, muss zunächst für einen AnwendungsKontext analysiert werden, welche Bedingungen und welche mögliche Aktionen auftreten können. Diese werden zunächst in die Entscheidungstabelle in den beiden linken Quadranten eingetragen. 254 Anschließend werden alle Bedingungskombinationen ermittelt. Ist eine Bedingung erfüllt, wird "J" (für Ja) in dem Bedingungsanzeigerteil eingetragen. Andernfalls erfolgt die Eintragung "N" (für Nein). Ist der Erfüllungsgrad einer Bedingung irrelevant, so wird in der Tabelle "-" (Irrelevanzanzeiger) eingetragen. 10.2 ET-Typen Bei ET werden unterschiedliche Darstellungsformen für den Bedingungsteil unterschieden. Werden im Bedingungsanzeigerteil nur die Werte "J", "N" und "-" sowie "X" im Aktionsanzeigerteil verwendet, wird eine ET als "begrenzt" bezeichnet. Oft kann eine kompaktere Darstellung erzielt werden, wenn jedoch textliche Beschreibungen verwendet werden. In diesem Fall spricht man von "erweiterten" ET. Eine ET ist vollständig, wenn alle möglichen Bedingungskombinationen auch als Regeln vorkommen. Es wird hierbei zwischen "formal vollständig" und "inhaltlich vollständig" unterschieden. Bei einer formal vollständigen Tabelle werden im Bedingungsanzeigerteil alle möglichen Kombinationen dargestellt. Bei einer inhaltlich vollständigen Tabelle werden alle praktisch möglichen Kombinationen aufgeführt, d.h. es fehlen die unlogischen bzw. offensichtlich unmöglichen Kombinationen. Da bei n Bedingungen 2n Bedingungskombinationen auftreten können, versucht man nur die wichtigsten Regeln darzustellen und die irrelevanten Fälle durch eine Else-Regel abzudecken. Durch Einsatz der Else-Regel kann somit aus einer unvollständigen ET eine vollständige ET erzeugt werden. 10.3 Anwendung von Entscheidungstabellen Im Folgenden soll an einem Beispiel die Erstellung einer ET beschrieben werden. Diese dient zur Darstellung des Problemlösungswissens einer Universitätsbibliothek, die die Ausleihe von Büchern durch ein Software-System unterstützt. Gemäß der fachlichen Problemstellung müssen verschiedene Fälle betrachtet werden, wann ein Buch ausgeliehen werden kann. Einige Regeln lauten: /1/ Wenn ein Benutzer bekannt ist und kein Sperrvermerk für diesen Benutzer existiert, kann dieser das Buch ausleihen-vorausgesetzt es ist vorhanden. /2/ Auch wenn ein Benutzer gesperrt ist, dieser jedoch bekannt ist, kann ein Buch mittels Einzahlungsbeleg ausgeliehen werden. /3/ Wenn ein Buch nicht vorhanden ist, kann nicht ausgeliehen werden. Allerdings ist eine Vormerkung möglich, auch wenn der Benutzer gesperrt ist. 255 /4/ Wenn ein Benutzer im System nicht bekannt ist, dieser aber als gesperrt vermerkt ist, liegt ein Systemfehler vor. Aus der Problembeschreibung folgt die ET, die in der folgenden Abbildung dargestellt ist. Entscheidungsregeln R1 R2 R3 R4 R5 R6 R7 Bedingungsanzeiger Bedingungen B1Benutzer bekannt J J J J J N N B2Benutzer gesperrt N J J N J J J B3 Buch vorhanden J J J N N - - B4 Einzahlungsbeleg - J N - J N J Aktionsanzeiger Aktionen A1 Buch ausleihen x x x Anicht 2 ausleihen, gesperrt x A3 vormerken x A4Systemfehler A5Einzahlung eingeben x x x A6keine Aktion Abbildung: Begrenzte Entscheidungstabelle zur Darstellung des Problemlösungswissens einer Universitätsbibliothek [Sch86] Die dargestellte ET ist ein Beispiel für eine begrenzte, unvollständige ET. Sie ist "begrenzt", da nur Ja-/Nein- sowie "-" Angaben im Bedingungsanzeiger gemacht werden. Die ET ist "unvollständig", da nicht alle 16 Ja-/Nein-Kombinationen der 4 Bedingungen B1 bis B4 ausgeführt sind, sondern die Tabelle durch die Else-Regel verkürzt ist. Vereinfachte Entscheidungstabelle ET mit mehr als 4 Bedingungen können nur recht schwierig dargestellt werden. Aus diesem Grunde empfiehlt es sich, diese zu konsolidieren. So können Spalten, die den gleichen Aktionsteil haben, zusammengefasst werden. Es entsteht dadurch eine vereinfachte Entscheidungstabelle. In der obigen ET kann z.B. eine Zusammenfassung von Spalte 4 und 5 bzw. 6 und 7 erfolgen. 256 Zusätzlich kann durch Darstellung des Else-Zweiges eine vollständige ET erzeugt werden. Das Ergebnis dieser Konsolidierung ist in der nachfolgenden Abbildung dargestellt. R 1 R2 R3 R4´ R5´ ELSE B1 Benutzer bekannt J J J J N B 2 Benutzer gesperrt N - J - J B 3 Buch vorhanden J J J N - B 4 Einzahlungsbeleg - J N - - A 1 Buch ausleihen x x x A 2 nicht ausleihen, gesperrt x A 3 vormerken A 4 Systemfehler A 5 Einzahlung eingeben A 6 keine Aktion x x x Abbildung: Ausleihverkehr einer Universitätsbibliothek als vereinfachte Entscheidungstabelle dargestellt [Sch86] Sofern noch weitere Regeln aufgrund einer fachlichen Analyse als notwendig erscheinen, kann die ET entsprechend angepasst werden. Als Beispiel könnte gefordert sein, dass ein Benutzer maximal 4 Bücher ausleihen und ein Buch maximal zweimal verlängert werden darf. Diese Regeln werden am günstigsten durch textuelle Angaben realisiert. In der nachfolgenden Abbildung ist eine erweiterte ET als Beispiel angegeben. 257 E n ts c h e id u n g s re g e ln R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 B e d in g u n g s a n z e ig e r B e d in g u n g e n B e n u tz e r b e k a n n t J J J J J J J J B 1 B 2 A n z a h l a u s g e lie h e n e B ü c h e r <5 <5 <5 <5 - - - - B 3 B e n u tz e r g e s p e rrt N J N J N J N J B 4 B u c h v o rh an d en J J - - - - - - B 5 A n z a h l V e rlä n g e ru n g e n - - ≤2 ≤2 - - - - B B 6 E in z a h lu n g s b e le g - J - J - - - - 7 A nzahl M ahnungen - - - - A 1 B u c h a u s le ih e n X X A 2 B u c h v e rlä n g e rn A 3 M ahngebühr A 4 . . . . . . . . . . . 1 - 3 1 - 3 4 ,5 4 ,5 A k tio n s a n z e ig e r A k tio n e n X X 1D M 2D M 2D M 3D M Abbildung: Ausleihverkehr einer Universitätsbibliothek als gemischte Entscheidungstabelle dargestellt [Sch86] 10.4 Entscheidungsbaum Neben der Quadrantendarstellung mit vertikaler Anordnung der Regeln wird in der Praxis auch gerne eine horizontale Darstellung der Entscheidungstabelle vorgenommen. In der folgenden Abbildung ist ein Beispiel hierfür angegeben [Balz96]. Kreditgrenze überschritten? J ZahlungsVerhalten einwandfrei? J N N J N Überschreitungsbetrag < 500 Euro? J N J N J N J N Scheck einlösen Scheck nicht einlösen X X Neue Konditionen vorlegen unlogisch X X X X X X X Abbildung: Entscheidungstabelle in horizontaler Darstellungsform [Balz96] 258 Aus einer Entscheidungstabelle in horizontaler Darstellungsform lässt sich leicht die Darstellung eines Entscheidungsbaums ableiten. Hierbei werden die Alternativen explizit ausgeführt. Für obiges Beispiel wird nachfolgend die äquivalente Baumdarstellung angegeben. Überschreitungsbetrag < 500 Euro Scheck einlösen Überschreitungsbetrag >= 500 Euro Scheck einlösen und neue Konditionen verlegen Überschreitungsbetrag < 500 Euro Scheck nicht einlösen Überschreitungsbetrag >= 500 Euro Scheck nicht einlösen Überschreitungsbetrag < 500 Euro Scheck einlösen Überschreitungsbetrag >= 500 Euro Unlogisch Überschreitungsbetrag < 500 Euro Scheck einlösen Überschreitungsbetrag >= 500 Euro Unlogisch Zahlungsverhalten einwandfrei Kreditgrenze nicht überschritten Zahlungsverhalten nicht einwandfrei Scheckeinlösung Zahlungsverhalten einwandfrei Kreditgrenze nicht überschritten Zahlungsverhalten nicht einwandfrei Abbildung: Entscheidungstabelle als Entscheidungsbaum [Balz96] Für das im vorherigen Abschnitt erwähnte Beispiel ist abschließend die alternative Darstellung als Entscheidungsbaum angegeben. 259 B e n u tz e r n ic h t g e sp e rrt w e n ig e r a ls 5 B ücher a u s g e lie h e n B e n u tz e r bekannt B e n u tz e r g e sp e rrt B e n u tz e r n ic h t g e sp e rrt B e n u tz e r g e sp e rrt B u c h v o rh a n d e n B u c h a u sle ih e n A n z a h l V e rlä n g e ru n g e n ≤2 B u c h v e r lä n g e r n B u c h v o rh a n d e n A n z a h l V e rlä n g e ru n g e n ≤2 E in z a h lu n g s b e le g v o rh a n d e n B u c h a u s le ih e n E in z a h lu n g s b e le g v o rh a n d e n B u c h v e r lä n g e r n A nzahl M ahnungen 1 -3 1 D M A nzahl M ahnungen 4 -5 2 D M A nzahl M ahnungen 1 -3 2 D M A nzahl M ahnungen 4 -5 3 D M S onst K e in e A k tio n Abbildung: Entscheidungsbaum "Buch ausleihen" Wie den Darstellungen der Entscheidungsbäume entnommen werden kann, ist diese alternative Darstellungsform insoweit semantisch nicht mit der vertikalen Darstellungsform identisch, da beim Entscheidungsbaum eine Abarbeitungsfolge von links nach rechts festgelegt ist. 10.5 Weiterführende Literatur [Balz96] H. Balzert, Lehrbuch der Software-Technik: Software-Entwicklung, Spektrum Akademischer Verlag, 1996. [Sch86] H.-J. Schneider, Lexikon der Informatik und Datenverarbeitung, Oldenburg, 1986. [Sch89] F. Schöntaler, Rapid Prototyping zur Unterstützung des Konzeptuellen Entwurfs von Informationssystemen, Dissertation, Universität Karlsruhe, Fakultät Wirtschaftswissenschaften, 1989. [Sch90] A. Schulz, Software Entwurf, P. Oldenburg Verlag, München Wien, 1990. 260