Software Methodik

Software Methodik
Software Methodik
Patrick Kupferschmid
Dozent für Software-Methodik, NDS
Zuger Techniker und Informatikerschule
Sommer 2001
Software Methodik
Inhaltsverzeichis
1
EINLEITUNG..........................................................................................................................................................6
1.1
1.2
1.3
2
HISTORISCHE ENTWICKLUNG DES SOFTWARE-ENGINEERING ...........................................................................6
SOFTWARE-ENTWICKLUNG...............................................................................................................................7
CHARAKTERISTIKA VON SOFTWARE .................................................................................................................7
SOFTWAREQUALITÄT .......................................................................................................................................9
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
3
KORREKTHEIT.................................................................................................................................................10
BENUTZERFREUNDLICHKEIT ...........................................................................................................................10
EFFIZIENZ .......................................................................................................................................................10
ROBUSTHEIT ...................................................................................................................................................10
AUSFALLSICHERHEIT ......................................................................................................................................10
KOMPATIBILITÄT/VERTRÄGLICHKEIT .............................................................................................................11
PORTABILITÄT ................................................................................................................................................11
VOLLSTÄNDIGKEIT .........................................................................................................................................11
KONSISTENZ ...................................................................................................................................................11
LESBARKEIT ...................................................................................................................................................11
ERWEITERBARKEIT .........................................................................................................................................12
WIEDERVERWENDBARKEIT .............................................................................................................................12
TESTBARKEIT..................................................................................................................................................12
WARTBARKEIT................................................................................................................................................12
SOFTWAREENTWICKLUNG ...........................................................................................................................13
3.1
3.2
3.3
4
SOFTWARE- ENTWICKLUNGSMETHODEN ........................................................................................................13
SOFTWARE-LEBENSZYKLUS............................................................................................................................14
AUFWANDVERTEILUNG ..................................................................................................................................14
PROZESSMODELLE...........................................................................................................................................15
4.1
VORGEHENSMODELLE ....................................................................................................................................15
4.1.1
V-Modell....................................................................................................................................................15
4.1.2
Rational Unified Process(RUP) ................................................................................................................17
4.1.2.1
Merkmale ......................................................................................................................................................... 17
4.1.2.2
Prozessdimensionen:........................................................................................................................................ 18
4.1.2.2.1
Phasen......................................................................................................................................................... 18
4.1.2.2.1.1 Elaboration (Entwurf) Phase................................................................................................................. 19
4.1.2.2.1.2 Construction Phase ............................................................................................................................... 19
4.1.2.2.1.3 Transition Phase ................................................................................................................................... 20
4.1.2.2.2
Workflows .................................................................................................................................................. 20
4.1.2.2.2.1 Business Modeling Workflow .............................................................................................................. 20
4.1.2.2.2.2 Requirements Workflow....................................................................................................................... 21
4.1.2.2.2.3 Analysis & Design Workflow .............................................................................................................. 21
4.1.2.2.2.4 Implementation Workflow.................................................................................................................... 22
4.1.2.2.2.5 Test Workflow...................................................................................................................................... 22
4.1.2.2.2.6 Deployment Workflow ......................................................................................................................... 22
4.1.2.2.2.7 Project Management Workflow............................................................................................................ 23
4.1.2.2.2.8 Configuration and Change Management Workflow ............................................................................. 23
4.1.2.2.2.9 Environment Workflow........................................................................................................................ 24
4.2
PHASENMODELLE ...........................................................................................................................................25
4.2.1
Wasserfallmodell.......................................................................................................................................25
4.2.1.1
4.2.1.2
4.2.1.3
4.2.1.4
4.2.1.5
4.2.1.6
4.2.1.7
4.2.2
Anforderungen/Machbarkeitsstudie (feasibility study) .................................................................................... 26
Anforderungsanalyse (requirements specification) .......................................................................................... 26
Systementwurf (system design) ....................................................................................................................... 26
Codieren und Modultest................................................................................................................................... 26
Integration und Systemtest ............................................................................................................................... 26
Auslieferung und Installation ........................................................................................................................... 26
Wartung (Maintenance) ................................................................................................................................... 26
Rapid-Prototyping.....................................................................................................................................27
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 2 von 89
Software Methodik
4.2.3
Spiralmodell (nach Boehm).......................................................................................................................28
4.2.4
Das Objektorientierte Modell....................................................................................................................29
4.3
ZUSAMMENFASSUNG ......................................................................................................................................30
5
UNIFIED MODELING LANGUAGE (UML)....................................................................................................31
6
SOFTWARE ENTWICKLUNGSPROZESS - ÜBERBLICK...........................................................................34
6.1
6.2
6.3
6.4
6.5
6.6
7
ANFORDERUNGSSPEZIFIKATION......................................................................................................................35
ANALYSE ........................................................................................................................................................35
DESIGN ...........................................................................................................................................................36
IMPLEMENTATION ...........................................................................................................................................36
TESTEN ...........................................................................................................................................................36
EINFÜHRUNG ..................................................................................................................................................36
ANFORDERUNGSSPEZIFIKATON .................................................................................................................37
7.1
ANFORDERUNGEN...........................................................................................................................................37
7.2
USE-CASE .......................................................................................................................................................38
7.2.1
Szeanrio.....................................................................................................................................................39
7.2.2
Use-Case Findung.....................................................................................................................................40
7.3
USE-CASE-DIAGRAMM ...................................................................................................................................41
7.3.1.1
7.3.1.2
7.3.1.3
7.3.1.4
Aktor ................................................................................................................................................................ 42
Generalisierung ................................................................................................................................................ 42
Include (in UML 1.1: uses) .............................................................................................................................. 42
Extend .............................................................................................................................................................. 42
7.4
CRC KARTEN(CLASS RESPONSIBILITIES COLLABORATIONS).........................................................................43
7.4.1
Identifikation der Objekt bzw. Klassen......................................................................................................44
7.4.2
Anlegen von Klassenkarten .......................................................................................................................44
7.4.3
Erfassung und Analyse der Kollaborationen ............................................................................................44
7.4.4
Gruppierung der Klassenkarten ................................................................................................................44
7.4.5
Diskussion der Verantwortungen und Kollaborationen ............................................................................45
7.4.6
Datenübertragung in das Modell ..............................................................................................................45
8
ANALYSE ..............................................................................................................................................................46
8.1
VOM USE-CASE ZUM DOMAINMODELL...........................................................................................................46
8.1.1
Klassendiagramm......................................................................................................................................47
8.1.2
System-Sequenz Diagramm .......................................................................................................................48
8.2
ANALYSEKONZEPTE........................................................................................................................................49
8.2.1
Konzeptionelles Modell .............................................................................................................................49
8.2.2
Spezifikations Konzept...............................................................................................................................49
8.2.3
Einfache Attribute .....................................................................................................................................50
8.3
GRASP-PATTERN...........................................................................................................................................51
8.3.1
Einleitung ..................................................................................................................................................51
8.3.1.1
8.3.1.2
8.3.1.3
8.3.2
8.3.3
8.3.4
8.3.5
8.3.6
9
Was sind GRASP-Patterns? ............................................................................................................................. 51
Pattern .............................................................................................................................................................. 51
Verantwortlichkeiten........................................................................................................................................ 51
Experte (expert).........................................................................................................................................52
Erzeuger (creator).....................................................................................................................................54
Kontroller (Controller) .............................................................................................................................56
Hoher Zusammenhalt (High Cohesion).....................................................................................................57
Geringe Kopplung (Low Coupling)...........................................................................................................58
DESIGN..................................................................................................................................................................60
9.1
9.2
9.3
9.4
9.5
9.6
VON DER ANALYSE ZUM DESIGN ....................................................................................................................61
ABGRENZUNG GEGENÜBER OOA....................................................................................................................61
ITERATIVE SOFTWAREENTWICKLUNG .............................................................................................................61
RESULTATE DES OOD.....................................................................................................................................62
OOD - WIE MACHT MAN DAS ?.......................................................................................................................62
KOMPONENTENMODELL .................................................................................................................................62
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 3 von 89
Software Methodik
9.7
DESIGN IN 4 KOMPONENTEN...........................................................................................................................63
9.8
DIE 6 GOLDENEN REGELN ..............................................................................................................................64
9.8.1
Regel 1: Denke in Layers ..........................................................................................................................64
9.8.1.1
9.8.1.2
9.8.1.3
Layermodell ..................................................................................................................................................... 64
Layering - wozu? ............................................................................................................................................. 65
Anwendungsarchitektur ................................................................................................................................... 65
9.8.2
Regel 2: Beachte die Änderungswahrscheinlichkeit .................................................................................66
9.8.3
Regel 3: „Vorsicht ist die Mutter des flexiblen Designs“ .........................................................................66
9.8.4
Regel 4: Gekapselte Datenmanipulation...................................................................................................66
9.8.5
Regel 5: Beachte die Metapher „Arbeitsteilung“ .....................................................................................66
9.8.6
Regel 6: Benutze etablierte Muster ...........................................................................................................66
9.9
UML-DIAGRAMME .........................................................................................................................................67
9.9.1
Klassendiagramm......................................................................................................................................67
9.9.1.1
9.9.1.2
9.9.2
Attribute spezifizieren...................................................................................................................................... 67
Operationen spezifizieren................................................................................................................................. 67
Interaktionsdiagramm ...............................................................................................................................68
9.9.2.1
9.9.2.2
9.9.2.3
Kollaborationsdiagramm.................................................................................................................................. 68
Sequenzdiagramm............................................................................................................................................ 69
Beispiele zu Klassen-, Kollaborations- und Sequenzdiagramm ....................................................................... 71
9.9.3
Zustandsdiagramm ....................................................................................................................................72
9.9.4
Aktivitätendiagramm .................................................................................................................................73
9.10
DESIGN PATTERNS ..........................................................................................................................................74
9.10.1
Singleton...............................................................................................................................................75
9.10.2
Abstract Factory...................................................................................................................................75
9.10.3
Facade..................................................................................................................................................75
9.10.4
Delegation ............................................................................................................................................75
9.10.5
Template Method ..................................................................................................................................75
10
TESTEN .................................................................................................................................................................76
10.1
10.2
10.3
10.4
10.5
11
EINFÜHRENDES BEISPIEL ................................................................................................................................76
DEBUGGEN IST NICHT TESTEN!.......................................................................................................................76
TESTARTEN .....................................................................................................................................................77
TESTVERFAHREN ............................................................................................................................................78
ZUSAMMENFASSUNG ......................................................................................................................................79
IMPLEMENTIERUNG ........................................................................................................................................80
11.1
JAVA ...............................................................................................................................................................80
11.1.1
Umgebung ............................................................................................................................................80
11.1.2
RMI.......................................................................................................................................................81
11.1.3
Objektserialisierung .............................................................................................................................81
12
ANHANG A [ANMERKUNGEN] .......................................................................................................................82
12.1
12.2
13
BUSINESS USE-CASE.......................................................................................................................................82
USE-CASE .......................................................................................................................................................82
ANHANG B [BEISPIELE] ...................................................................................................................................83
13.1
FALLBEISPIEL AUTOVERMIETUNG ..................................................................................................................83
13.1.1
Systemgrenzen festlegen:......................................................................................................................85
13.1.2
Stelle eine Reihe von Szenarien auf:.....................................................................................................85
13.1.3
Beteiligte Aktoren identifizieren ...........................................................................................................85
13.1.4
Use-Cases nur namentlich identifizieren (Seite 128)............................................................................86
13.1.5
Unechte Use-Cases eliminieren............................................................................................................86
13.1.6
Use-Cases zu Packages zusammenfassen (Seite 128) ..........................................................................86
13.1.7
Kurzbeschreibungen erstellen ..............................................................................................................86
13.1.8
Use-Cases priorisieren .........................................................................................................................87
13.1.9
Normalfall für hoch-priorisierte Use-Cases formulieren (Seite 133-137) ...........................................87
13.1.10
Pro Use-Case eine Datei anlegen.........................................................................................................87
13.1.11
Hauptdokument erstellen......................................................................................................................87
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 4 von 89
Software Methodik
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 5 von 89
Software Methodik
1 Einleitung
1.1 Historische Entwicklung des Software-Engineering
Zum Betreiben von Rechnern werden immer Programme eingesetzt. Programme werden von
Menschen entwickelt. Also sind sie stets fehlerhaft. Bei der Fehlerausmerzung eines noch so guten
Programms gilt auch heute noch:
Im besten Fall hat man soeben den vorletzten Fehler beseitigt.
Dasselbe gilt dann auch für die Behebung des nächsten Fehlers.
Zu Beginn wurden Rechner vorwiegend im technisch-wissenschaftlichen Bereich eingesetzt, wo
bekannte Lösungen, wie z.B. Differentialgleichungen, durch Programme beschleunigt wurden oder
dadurch erst in vernünftiger Zeit lösbar waren. Die Programme wurden meist von einem
Programmierer erstellt, der sie selbst auch einsetzte. Programmierfehler wirkten sich dadurch nur
lokal aus und konnten vom Benutzer bzw. Programmierer auch schnell behoben werden.
Computer durchdringen alle Lebensbereiche - und mit ihnen die Software, welche Computer
steuert. Wirtschaft und Gesellschaft sind abhängig geworden von Software. Und die Abhängigkeit
nimmt zu. Im krassen Gegensatz zu dieser Abhängigkeit steht die Tatsache, dass weltweit die
Erstellung von Software nur ungenügend beherrscht wird. Termin- und Kostenüberschreitungen bei
Softwareprojekten sind die Regel. Software, die Fehler enthält, oder sich nicht entsprechend den
Vorstellung und Bedürfnissen der Benutzenden verhält, gehört zum Alltag. Immer wieder kommt es
auch vor, dass ganze Projekte scheitern.
Schon recht triviale Fehler können unter diesen Gesichtspunkten verheerende Folgen haben. Die
markantesten Fälle werden in der Presse und auch regelmässig in Fachzeitschriften veröffentlicht:
Eine Elektrizitätsgesellschaft, deren Abrechnungswesen über EDV lief, mahnte einen Kunden
wiederholt, die offene Stromrechnung über 0,00 DM zu begleichen, bis der Kunde entnervt den
fälligen Betrag überwies.
Ein Roboter drückt einen Arbeiter an die Wand - er stirbt nach 5 Tagen. Das Roboterprogramm
war fehlerhaft.
32.000 Geldtransaktionen gehen bei der Bank of New York nach einem Systemabsturz verloren,
Verlust ca. 5 Millionen Dollar. Die Absturzursache war ein Softwarefehler.
Drei Krebspatienten sterben an den Folgen einer Überdosis von radioaktiver Substanz eines
computergesteuerten Bestrahlungsgeräts, dessen Programm fehlerhaft war.
"Der automatische Vortriebsregler unserer B737 hatte die Eigenschaft, sich manchmal während
des Startvorgangs bei exakt 60 Knoten zu verabschieden. Es waren unsere Werkstätten - und
nicht etwa der Gerätehersteller -, die anhand der glücklicherweise vorhandenen Listings die
Ursache fanden: Der Programmierer hatte festgelegt, was der Vortriebsregler unter und was er
über 60 Knoten tun sollte. Nur ihm zu sagen, wie er bei 60 Knoten reagieren sollte, das hatte er
vergessen. Wenn der Computer nun bei exakt 60 Knoten die entsprechende Bedingung abfragte,
fand er keine Anweisung vor, war verwirrt und schaltete ab."
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 6 von 89
Software Methodik
Diese Entwicklung führte um die Mitte der 60-er-Jahre zur sogenannten Softwarekrise, zu deren
Bewältigung staatliche Forschungs- und Ausbildungsprogramme initiiert wurden. In dieser Zeit
wurden die ersten Studiengänge für Informatik an den Hochschulen eingerichtet. Auf der
Forschungsseite wurden Software-Engineering Konferenzen abgehalten (Garmisch 1968 und Rom
1969).
1.2 Software-Entwicklung
Überall in der Informatik wird heute von Objektorientierung gesprochen. Dabei werden
verschiedenste Schlagworte wie OO-Methoden, OO-Betriebsysteme, OO-Datenbanken, OOBenutzerschnittstellen verwendet. Objektorientiert ist längst nicht mehr nur ein Schlagwort.
Objektorientierte Methoden werden schon seit geraumer Zeit mit grossem Erfolg in der SoftwareEntwicklung eingesetzt.
Software ist in den vergangenen Jahrzehnten zu einem wichtigen Faktor geworden, ohne den in den
hochentwickelten Ländern fast gar nichts mehr geht. Die Entwicklung von Software wird jedoch bis
heute nur ungenügend beherrscht. Software-Entwicklung ist also offenbar etwas Schwieriges.
Eines der spektakulärsten Beispiele aus jüngster Zeit ist das Scheitern des CONFIRM-Projekts: Im
Auftrag grosser amerikanischer Hotel- und Mietwagenunternehmen sollte ein neues, umfassendes
Reservierungssystem entwickelt werden. Nach drei Jahren Entwicklungszeit und Investitionen von
rund 125 Millionen Dollar wurde das Projekt 1992 eingestellt, als erkannt wurde, dass die gestellten
Anforderungen mit dem gewählten Lösungsansatz nicht erfüllbar waren.
Warum ist Software-Entwicklung so schwierig?
Dabei erscheint Programmieren auf den ersten Blick gar nicht so schwierig. Was ist ein Programm
denn eigentlich mehr als das Zusammenfügen einfacher Befehle zu einer geeigneten Folge von
Anweisungen an einem Computer. Eine einfache Antwort auf die Frage, warum SoftwareEntwicklung schwierig ist, gibt es wohl kaum. Das muss man einmal miterlebt haben. Man kann
jedoch einige Faktoren aufzeigen.
1.3 Charakteristika von Software
Unter Software versteht man Programme, Verfahren, Daten und zugehörige Dokumentation, die
Bestandteile eines Computersystems sind und den Betrieb ermöglichen. Deshalb ist es so schwierig,
geeignete ingenieurmässige Verfahren bei der Softwareerstellung einzusetzen. Führen wir uns
einmal die Unterschiede zwischen der Softwareerstellung und der klassischen technischen
Produktion vor Augen:
Software altert nicht und verschleisst nicht. Deshalb benötigt es keine Wartung im üblichen Sinn.
Ersatzteile zur Behebung eines aufgetretenen Fehlers gibt es nicht.
Software ist im allgemeinen leichter und schneller zu ändern als ein technisches Produkt.
Software ist kein Serienprodukt im herkömmlichen Sinn. Der Prototype ist bereits das
Endprodukt, welches mit minmalem Aufwand vervielfältigt werden kann.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 7 von 89
Software Methodik
Software dient dazu, ein Problem zu lösen oder zu dessen Lösung beizutragen, indem menschliche
oder technische Arbeitsvorgänge automatisiert oder unterstützt werden. Aus dieser
Zweckbestimmung folgen drei wesentliche Eigenschaften von Software:
Modell
Das Problem ist im Kontext seines Sachgebietes zu verstehen und
befriedigend zu lösen.
Komplexität
Wenn ein Problem von seiner Natur her komplex und schwierig ist, so ist die
Entwicklung der Software zur Lösung dieses Problems in der Regel nicht
weniger komplex und schwierig.
Problemlösung
Die Problemlösung muss auf adäquate Software-Strukturen abgebildet
werden, schafft jedoch neue Realitäten und weckt neue Bedürfnisse.
Die Softwareerstellung erfordert ein spezielles methodisches und Case-Tool unterstütztes
Vorgehen. Um die hohe Komplexität umfangreicher Softwarepakete mit den quantitativ
beschränkten geistigen Fähigkeiten des Menschen bewältigen zu können, müssen spezielle
Prinzipien und Methoden entwickelt werden. Objektorientierte Methoden haben in den letzten
Jahren auf diesem Gebiet sowohl beim methodischen Vorgehen als auch beim werkzeugmässigen
Einsatz einen grossen Fortschritt erzielt. Insbesondere erlaubt der OO-Ansatz eine
Beschreibungsmethode, die durch alle drei Phasen OOA, OOD und OOP durchgängig beibehalten
werden kann.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 8 von 89
Software Methodik
2 Softwarequalität
Qualität muss in die Software hineinkonstruiert werden, sie kann nicht nachträglich durch
Qualitätssicherungsmassnahmen erreicht werden, oder gar in das Produkt hinein getestet werden.
lenken
Qualität
planen
Qualität
konstruieren
Qualität
prüfen
Abbildung 1: Qualitätssicherungs-Regelkreis
Dazu ist es erforderlich, dass sich konstruktive und analytiscvhe Massnahmen ergänzen. Das Ziel
der Massnahmen ist es, ein Softwareprodukt, das die gestellten Anforderungen erfüllt, möglichst
wirtschaftlich herzustellen.
Projekt-Qualität
Termine
Kosten
Mengen
Produkt-Qualität
Leistung
Merkmale
Abbildung 2: Projekt- und Produktqualität
Ein Programm kann als eine (komplizierte) Funktion betrachtet werden, die aus irgendeiner
Eingabe (aus dem im Pflichtenheft definierten Definitionsbereich D) die gewünschte Ausgabe (aus
dem Wertebereich W) liefert.
Definitionsbereich
D
Software
Falsche
Eingabe
Wertebereich
W
Abbildung 3: Software als Funktion betrachtet
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 9 von 89
Software Methodik
2.1 Korrektheit
Das Programm liefert für jede Eingabe aus dem Definitionsbereich D die geforderte Ausgabe im
Wertebereich W. Falsche Eingaben werden sinnvoll behandelt und entsprechende Fehlermeldungen
generiert. Dies kann man durch geeignetes Design (Pulldown-Menüs, Maussteuerung) leichter
gewährleisten. Die Software entspricht exakt den in der Spezifikationen beschriebenen
Anforderungen.
Mit den heute zur Verfügung stehenden Mitteln kann die Korrektheit nicht erzwungen werden. Wir
können aber einiges tun, um sie zu fördern und dadurch die Wartungskosten tief zu halten und
Folgekosten zu vermeiden.
2.2 Benutzerfreundlichkeit
Hat ein Programm folgende Eigenschaften:
leicht erlernbar
gute Benutzerführung
einheitliche Oberfläche
Anpaßbarkeit an Benutzerwünsche?
Dies muß bereits bei der Analyse und im Design beachtet werden. Der Benutzer eines Systems hat
in der Regel mehr Probleme, als der Entwickler wahrhaben will. Wichtigste Gründe dafür sind:
Der Benutzer kennt(hoffentlich) das Innere des Systems nicht und versteht daher gewisse
Meldungen und Warnungen nicht.
Der Benutzer hat ein Bedürfnis nach Unterstützung durch das System. Er möchte beim
Benutzen eines neuen Systems oder eines bisher nicht verwendeten Kommandos Schritt für
Schritt geführt werden und bei Bedarf Erklärungen erhalten. Ein Experte möchte hingegen nicht
mehr durch Hilfestellungen behindert werden.
2.3 Effizienz
Unter Effizienz versteht man die ökonomische Nutzung der Hardware-Resourcen. Beim Design
stellt man sich deswegen die Fragen nach
Laufzeitverhalten
optimaler Ausnutzung von Ressourcen (Speicherplatzbedarf, Netz)
Preis
Meist ist das Produkt "Laufzeit*Ausnutzung" etwa konstant. Ein Programm hat hohe Effizienz,
wenn es wenige Prozessoren und andere Betriebsmittel, insbesondere wenig Speicher, für kurze
Zeit belegt. Man unterscheidet zwischen Speicher- und Laufzeit-Effizienz.
2.4 Robustheit
Sie ist ein Maß dafür, wie viele falsche Eingaben die Software erkennt und auch unter
aussergewöhnlichen Bedingungen funktioniert. Das System muss fehlertolerant sein und sich durch
leistungsfähige und komfortable Fehlerdiagnostik/-korrektur auszeichnen. Dies muß bei der
Analyse und beim UI-Design berücksichtigt werden.
2.5 Ausfallsicherheit
Stürzt das Programm bei Ausfall einer oder mehrerer Hardwarekomponenten nicht gleich ab, gehen
keine Daten verloren und kann das Programm - evtl. mit verminderter Leistungsfähigkeit weiterarbeiten?
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 10 von 89
Software Methodik
2.6 Kompatibilität/Verträglichkeit
Kompatibilität ist die Eigenschaft, welche die gemeinsame Nutzbarkeit der Software mit anderen
Komponenten (Hardware und Software) beschreibt. Lassen sich aus vorhandenen und neuen
Softwarebausteinen neue Programmsysteme herstellen?
2.7 Portabilität
Mit welchem Aufwand läßt sich ein Softwareprodukt überführen (portieren) auf andere
Betriebssysteme
Hardware
Programmiersprachen
Netzprotokolle, Datenbanken
Die Portabilität ist abhängig von
Einhaltung von Standards
Grad der Abhängigkeiten von Rechner und Betriebssystem
Grad der Kapselung
CASE-Tools legen diesbezüglich bis zum OOP noch nichts fest. Häufig ist es notwendig, ein
Programm auf eine andere virtuelle Maschine(Rechner mit Betriebssystem) oder auf eine neue
Version zu übertragen. Dabei zeigt sich, wie gut die Besonderheiten des Rechners oder des
Betriebssystems lokal gehalten wurden. Je geringer der benötigte Aufwand ist, um ein Programm
auf eine andere Hardware(oder ein anderes Betriebsystem) zu portieren, desto besser ist die
„Portierbarkeit“.
2.8 Vollständigkeit
Sind alle benutzten (referenzierten) Komponenten im System enthalten? CASE-Tools liefern hierfür
Werkzeuge.
2.9 Konsistenz
Werden alle Komponenten entsprechend ihrer Definition verwendet? CASE-Tools liefern hierfür
Werkzeuge.
2.10 Lesbarkeit
Aus dem Programmtext soll die Wirkung des Programms möglichst klar ersichtlich sein.
Hilfsmittel:
Namenskonventionen und aussagekräftige Bezeichner
saubere Struktur des Programms (z.B. in Klassenhierarchie)
ausreichende und konsistente Kommentare
Die ersten beiden Punkte werden durch CASE-Tools erzwungen, der dritte Punkt erleichtert(durch
integrierte Dokumentationstools). Bei Korrekturen oder Änderungen muss der Entwickler, der in
der Regel nicht mit dem Programm vertraut ist, die richtige Stelle im Programm und/oder der
Dokumentation finden, verstehen und die notwendigen Änderungen durchführen. Wie aufwendig
dies ist, hängt von der Lesbarkeit der Software ab. Je tiefer die Sprache, desto mehr Kommentare
tragen zum "graphischen Layout" des Programmes bei.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 11 von 89
Software Methodik
2.11 Erweiterbarkeit
Der Appetit kommt häufig erst beim Essen! Entsprechend ist es bei der Software. Nach Einsatz
eines Softwarepakets kommen häufig neue Benutzerwünsche, die noch realisiert und in das
Programm integriert werden sollten. Erweiterbarkeit beschreibt den Aufwand, der nötig ist, um die
Software an geänderte Anforderungsspezifikationen anzupassen. Diesem Punkt ist bereits bei der
Analyse die nötige Beachtung zu schenken.
Die Vererbung von Objekten bietet hier optimale Voraussetzungen!
Die Änderbarkeit des Systems ist neben der Programmstruktur auch dadurch bestimmt, wie gut es
die reale Welt modelliert und wie leicht es sich bearbeiten lässt. Das zweite hängt unter anderem
von den zur Verfügung stehenden Werkzeugen ab.
Besonders vorteilhaft ist es, wenn zukünftige Anforderungsänderungen durch Parametrisierung
bzw. Delegation gelöst wurden und daher gar keine eigentliche Programmänderungen erfordern. Im
günstigsten Fall ist der zu ändernde Bereich eng begrenzt, im schlechtesten sind zahlreiche Module
involviert.
2.12 Wiederverwendbarkeit
Einzelne Komponenten sollten so gekapselt sein, daß sie ganz oder teilweise in anderen Projekten
und Anwendungen eingesetzt werden können. Geeignete Klassenstrukturen, die meist allgemeiner
gehalten werden, als dies für den Anwendungsbereich notwendig wäre, erleichtern die
Wiederverwendbarkeit.
2.13 Testbarkeit
Schon zu Beginn der Analyse und weiter beim Design muß daran gedacht werden, wie man das
Programm testet: Generierung von Testfällen- und Testdaten, sowie Ausnahmebehandlungen.
Fragestellungen hierbei sind:
Werden alle Programmpfade durchlaufen?
Mit welchen falschen Eingaben kann der Benutzer das Programm bedienen?
Menüs und Mausbedienung minimieren dies. Dieser Punkt ist sehr kritisch und sollte frühzeitig
beachtet werden!
2.14 Wartbarkeit
Beim Einsatz des Programms können Fehler auftauchen. Hier müssen während des
Entwicklungsprozesses verständliche Diagnosemeldungen erzeugt werden. Fehlerhafte
Komponenten sollten leicht austauschbar sein. Ferndiagnose und -wartung sollten vorgesehen und
bereits bei der Analyse beachtet werden. Wartbarkeit ist die Eignung der Software zur
Fehlersuche, Fehlerkorrektur
Änderung/Anpassungen, Erweiterung
Wartungsfreundlichkeit ist abhängig von
Einhaltung von Standards
Dokumentationsqualität
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 12 von 89
Software Methodik
3 Softwareentwicklung
3.1 Software- Entwicklungsmethoden
Abbildung 4: Software- Entwicklungsmethoden
In den Anfängen der Programmierung diente der Coumputer dazu, konplexe mathematische
Berechnungen und später die Datenverarbeitung zu automatisieren. Bei reproduzierbaren Abläufen
war die Maschine eine grosse Hilfe und brachte einen enorme Zeiteinsparung. Die Programme
waren meist klein, überschaubar und testbar. Auf Wiederwerdendbarkeit wurde kaum geachtet, da
jedes Problem wieder eine etwas andere Struktur hatte. Mit Hilfe von Nassy-Schneiderman und
Jackson-Diagrammen wurden die Abläufe strukturiert dargestellt und danach in Code umgesetzt.
Strukturierte Analyse und Design(SA/SD) wurden erst Mitte der 80-er Jahre durch objektorientierte
Ansätze abgelöst. Während man in der strukturierten Programmierung mit Funktionen(Routinen,
Sub-Routinen) arbeitet, welche Daten bearbeiten(erzeugen, verändern, löschen), verwendet man in
der objektorientierten Programmierung Objekte, welche ihre Daten kapseln(Datenzugriff durch das
Objekt) und die dazu benötigten Methoden bereitstellen. Mit der objektorientierten
Programmierung ist man der "Realen Welt" einen grossen Schritt näher gerückt. Die verwendeten
Modellen repräsentieren fast 1:1 die "Reale Welt" und werden auch von Nicht-Programmierern
verstanden.
Personen oder Gegenstände werden in Klassen definiert. Um sie im Programm manipulieren zu
können, werden sie zum Leben erweckt(instanziert). Ein Objekt im Programm verhält sich wie ein
Objekt in der "Realen Welt". Es empfängt Nachrichten("Aufträge") und reagiert darauf, z.B.
Person, gib Deinen Vornamen. Als Antwork kommt zurück: Patrick.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 13 von 89
Software Methodik
3.2 Software-Lebenszyklus
Nach
der
Auftragsbeschreibung
(Problemstellung) wird das Problem analysiert,
um daraus die Anforderungsdefinition zu
schreiben, welche ein Vertrag zwischen
Auftraggeber und Auftragnehmer darstellt.
Im Entwurf
wird das System analysiert,
designed
und
danach
in
Code
umgesetzt(implementiert). Nach gründlichen
Tests kann die Software in Betrieb genommen
werden. Jetzt beginnt die Wartungsphase, in
welcher
Fehler
behoben
und
neue
Anforderungen aufgenommen werden.
Problemstellung
Betrieb
Wartung
Problemanalyse
Anforderungsdefinition
Test
Implementierung
Entwurf
Abbildung 5: Software-Lebenszyklus
Das Phasenmodell oder der Software-Life-Cycle, dient als Grundlage für die Gliederung des Projektes. Ihnen liegt die
Erkenntnis zugrunde, dass es nicht möglich ist, ein komplexes Software-Produkt, ebsowenig wie ein anderes
technisches Produkt, in einem Zuge zu entwickeln. Alle Vorgehensmodelle stützen sich auf ein Phasenmodell, wobei
die Bezeichnung der einzelnen Phase, sowie Tätigkeiten und Ergebnisse, welche den einzelnen Phasen zugeordenet
werden, sehr unterschiedlich sind.
3.3 Aufwandverteilung
Beispiel:
Ein Projekt daure 2 Jahre (=100 Wochen):
Analyse 10 Wochen
Entwurf 20 Wochen
Implementierung 20 Wochen
Test, Integration 30 Wochen
Wartung 20 Wochen
Abbildung 6: Software-Lebenszyklus
In einem Softwareprojekt werden rund 30% des Zeitbedarfes in Analyse und Design investiert.
Dabei setzt man die Anforderungen in Modelle um und dokumentiert sie. Bis dahin werden
höchstens Prototypen entworfen, um Risiken abzuschätzen, jedoch noch nicht das System
programmiert. Nur gerade 20% entfallen auf das eigentliche Codieren. Die restlichen 50% werden
für Tests und Installation der Software beim Kunden, sowie Fehlerbehebung und kleine
Erweiterungen aufgewendet.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 14 von 89
Software Methodik
4 Prozessmodelle
4.1 Vorgehensmodelle
4.1.1 V-Modell
Das V-Modell ist ein Vorgehensmodell und beschreibt/regelt die Aktivitäten(Tätigkeiten) und
Produkte(Ergebnisse), die während der Entwicklung von Software durchzuführen bzw. zu erstellen
sind, sowie deren Änderungen und Abhängigkeiten. Es ist in die vier Subsysteme Systemerstellung,
Projektmanagement, Qualitätssicherung und Konfigurationsmanagement unterteilt und hat dafür
folgende Rollen definiert:
SE-Rollen
Systemanalytiker, Systemdesigner, DV-Analytiker, DV-Designer, SW-Analytiker,
SW-Designer, Programmierer, Supportberater, Applikationsberater, HW-Berater
PM-Rollen Projektmanager, Projektleiter, Projektassistent
QS-Rollen
QS-Manager, QS-Verantwortlicher, Qualitätsprüfer, QS-Assistent
KM-Rollen KM-Leiter, Konfigurationsadministrator, Datenschutz- und Datensicherheitsbeauftragter
Es integriert die Qualitätssicherung im Wasserfallmodell. Die Verifikation und Validation der
Teilprodukte sind Bestandteile.
Unter Verifikation ist die Überprüfung der Anforderungen mit dem Software-Produkt gemeint.
Funktioniert der Code korrekt?
Unter Validation wird die Eignung eines Produktes auf seinen Einsatzzweck verstanden. Macht das
System, was in der Spezifikation gefordert wurde?
Abbildung 7: V-Modell
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 15 von 89
Software Methodik
Das V-Modell ist ein übergreifendes Modell zur Abwicklung von Software-Entwicklungsvorhaben
und 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.
Abbildung 8: Struktur des Standardisierungskonzepts
Abbildung 9: Submodell Softwareerstellung (SWE)
Da es sowohl für kleine als auch sehr große Projekte geeignet ist, definiert es alle Aspekte, welche
in Projekten auftreten können. Das Tailoring sieht vor, aus dem V-Modell durch Streichungen ein
an das Projekt angepaßtes Modell zu erstellen. Es sind jedoch auch schon Beispielsmodelle
(inklusive Dokumente) erhältlich.
Das V-Modell verlangt erhöhte
Kooperation zwischen Auftraggeber
und Auftragnehmer, kann dabei aber
Kommunikationsprobleme verringern.
Es ist neben dem militärischen Bereich
auch für den gesamten Bereich der
Deutschen Bundesverwaltung verbindlich und wird von sehr vielen
Industriefirmen als Hausstandard zur
Softwareentwicklung verwendet. Es
stellt ein Prozeßmodell dar, mit dessen
Hilfe Projekte gemäß der ISO 9001
Abbildung 10: Zusammenspiel der Submodelle
Norm abgewickelt werden können.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 16 von 89
Software Methodik
4.1.2 Rational Unified Process(RUP)
4.1.2.1 Merkmale
Software-Entwickulungsprozess, der einen geordneten Ansatz zur Verfügung stellt, um
Aufgaben und Verantwortlichkeiten innerhalb eines Entwicklungsprozesses zuzuordnen.
Erstellung qualitativ hochwertiger Software innerhalb eines vorhersagbaren Zeitrahmens
und Budgets sicherstellen, die sich an den Bedürfnissen des Anwenders orientiert, und die
diesem auch tatsächlich gerecht wird.
Standardisierte Vorgehensweise basierend auf anerkannten Richtlinien, welche die
Entwicklung von personenunabhängigen SW-Lösungen erlaubt.
Dokumentation / Review der Arbeitsresultate und Festlegung wann welches Dokument bzw.
Resultat von wem innerhalb des Entwicklungsprozesses erstellt werden muss.
Quantifizierung / Messung des Arbeitsfortschrittes und der Resultate (Metriken).
Sämtliche Informationen über den Prozess sollten online zur Verfügung stehen, d.h. eine auf
Intranet basierende Präsentation drängt sich auf. Online-Hilfen (Assistenten, Mentoren,
Suchhilfen) sollten Rat für die Bewältigung der alltäglichen Aktivitäten zur Verfügung stellen.
Vorteile gegenüber konventionellem Wasserfall-Prozess:
Risiken werden früher reduziert
Änderungen sind besser handhabbar
Grösserer Grad an Wiederverwendbarkeit
Das Projekt-Team lernt während den Arbeitsschritten
Bessere Gesamt-Qualität
Vorgehensweisen:
Iterative und inkrementelle Softwareentwicklung
Anforderungsmanagement mittels Usecase-Technik
Komponentenbasierte Architekturen
Visuelle Softwaremodellierung
Softwarequalitätssicherung
Konfigurations und Änderungsmangement
Abbildung 11: Iterations-Zyklus
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 17 von 89
Software Methodik
4.1.2.2 Prozessdimensionen:
Abbildung 12: Prozess-Architektur
Globale Architektur des Rational Unified Processes(RUP), der in der horizontalen Dimension die
Projektphasen(Organization along time) und in der vertikalen die Aktivitäten(Organization along
content) beschreibt. Der RUP basiert auf einem iterativen Vorgehen.
4.1.2.2.1 Phasen
Jede Phase wird mit einem Meilenstein abgeschlossen.
Inception (Konzept) Phase
Die Inception-Phase dient der Ideenfindung. Am Ende dieser Phase liegt ein Businessplan für das
Projekt vor. Typischerweise beträgt der Aufwand für diese Phase ca. 5 bis 10% des gesamten
Projektaufwands.
Aktivitäten:
Projektrahmen abgrenzen, Vision definieren
Business Case für das System erstellen
Alle Use Cases identifizieren, wichtigsten Use Cases beschreiben
Akteure identifizieren, High-Level Beschreibung der Interaktionen mit dem System
Phasenplan mit den wichtigsten Milestones erstellen
Risiken bewerten
benötigte Ressourcen abschätzen
erste Prototypen
Falls das Projekt diesen Milestone nicht besteht, muss es gestrichen oder wesentlich überarbeitet
werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 18 von 89
Software Methodik
4.1.2.2.1.1 Elaboration (Entwurf) Phase
Die Elaboration-Phase dient dazu, die Anforderungen an das Projekt zu konkretisieren, sowie die
Softwarearchitektur zu erarbeiten und zu verifizieren. Der Aufwand für diese Phase liegt bei 20 bis
30% des Gesamtaufwands.
Aktivitäten:
Problem-Domäne analysieren
Hauptfunktionen/nicht funktionale Anforderungen trennen, solide Software-Architektur erstellen
Projektplan entwickeln
risikoreichste Elemente beseitigen, kritische Use Cases berücksichtigen
ausführbarer Architektur-Prototyp in einer oder mehreren Iterationen erstellen(abhängig von
Umgebung, Grösse, Risiko und Neuheit des Projektes)
Wegwerf-Prototypen zur Reduzierung von Risiken entwickeln
Diese Phase ist die kritischste Phase. Am Ende dieser Phase wird der harte Engineering-Teil als
abgeschlossen betrachtet und entschieden, ob das Projekt weitergeführt wird. Für die meisten
Projekte bedeutet dies der Übergang von einer flexiblen und risikoarmen zu einer trägen, teuren und
risikoreichen Arbeitsweise. Die erarbeiteten Grundlagen müssen deshalb stabil und die Risiken
reduziert worden sein, damit die Realisierung der Software nach Aufwand oder Fixpreis vereinbart
werden kann. Falls das Projekt diesen Milestone nicht besteht, muss es abgebrochen oder
wesentlich überarbeitet werden.
4.1.2.2.1.2 Construction Phase
In der Construction-Phase erfolgt die Erstellung der Software. In dieser Phase fällt der Grossteil der
Programmier-, Integrations- und Testarbeit an. Typischerweise beträgt der Aufwand für diese Phase
ca. 60 bis 70% des Gesamtaufwands.
Aktivitäten:
Entwicklung und Produkt-Integration aller restlichen Komponenten
Gründlicher Test aller Merkmale
aktueller Release beschreiben, sowie ein Benutzerhandbuch verfassen
Diese Phase kann als Herstellungsprozess angesehen werden, wobei der Schwerpunkt auf dem
Verteilen von Ressourcen und der Kontrolle der Abläufe gelegt wird, damit Kosten, Termine und
Qualität optimiert werden. In grossen Projekten darf diese Phase parallel gestartet werden, wodurch
die Verfügbarkeit von auslieferbaren Releases signifikant beschleunigt werden kann, jedoch die
Komplexität des Ressourcen-Managements und die Synchronisation des Workflows beträchtlichen
Mehraufwand bedeuten kann. Eine robuste Architektur und ein verständlicher Plan hängen in
hohem Masse zusammen. Deshalb wurde bereits in der Elaboration Phase darauf geachtet. Falls
dieser Milestone nicht bestanden wird, kann der Übergang zum nächsten Release verschoben
werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 19 von 89
Software Methodik
4.1.2.2.1.3 Transition Phase
Schliesslich erfolgt in der Transition-Phase die Einführung der Software. Die restlichen 15% des
Projektaufwands fallen typischerweise in dieser Phase an.
Aktivitäten:
Markteinführung
Entwicklung eines neuen Releases
Fertigstellung von aufgeschobenen Features, Korrekturen
Beta-Tests um sicherzustellen, dass die Anwendererwartungen erreicht werden, z.B. paralleler
Betrieb zum Vorgänger-System
Daten-Konversion
Anwender-Dokumentation, Schulung von Anwendern und Betreuern, Reaktion auf Feedback
Einführung des Produktes im Marketing, Vertrieb und Verkaufsteam
Das Kontrollgremium/Management gibt den Auslieferungsentscheid. Die Anwender sollten ohne
Fremdunterstützung auskommen.
4.1.2.2.2 Workflows
Die Core Process Workflows sind unterteilt in sechs Core Engineering Workflows:
Business Modeling Workflow
Requirements Workflow
Analysis & Design Workflow
Implementation Workflow
Test Workflow
Deployment Workflow
Die sechs Core Engineering Workflows sollten nicht mit den Phasen eines traditionellen
Wasserfall-Modelles verwechselt werden. Die Phasen eines iterativen Prozesses sind verschieden
und die Workflows werden über den ganzen Lebenszyklus dauernd revidiert.
Und drei Supporting Workflows:
Configuration and Change Management Workflow
Project Management Workflow
Environment Workflow
Ein Projekt beinhaltet diese neun Core Workflows, die sich in jeder Iteration mit unterschiedlichem
Schwerpunkt und Intensität wiederholen.
4.1.2.2.2.1 Business Modeling Workflow
Eines der Hauptprobleme mit den meisten Business-Engineering-Bemühungen ist die mangelhafte
Kommunikation zwischen den Entwicklern und den Business-Analysten. Dies führt dazu, dass die
Resultate der einen von den anderen nicht richtig verstanden werden. Der RUP berücksichtigt
diesen Umstand mit einer gemeinsamen Sprache und einem gemeinsamen Prozess für beide
Parteien und zeigt auf, wie direkte Abstimmung zwischen Business- und Software-Modellen
erzeugt und unterhalten wird.
Business-Prozesse werden mit Use Cases dokumentiert. Damit wird ein gemeinsames Verständnis
aller Beteiligten erreicht, welche Business-Prozesse in der Organisation unterstützt werden müssen.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 20 von 89
Software Methodik
Die Business Use Cases werden analysiert, um zu verstehen, wie das Business ihren Prozess
unterstützen sollte. Dies wird in einem Business Objekt Modell dokumentiert. In vielen Projekten
wird kein Business-Modell erstellt.
4.1.2.2.2.2 Requirements Workflow
Das Ziel dieses Workflows ist eine Beschreibung was das System tun sollte und eine Vereinbarung
zwischen Entwickler und Kunden über diese Beschreibung. Zu diesem Zweck werden die
geforderte Funktionalität und die Randbedingungen definiert und dokumentiert. Die Bedürfnisse
des Auftraggebers werden abgeklärt, ein Visions-Dokument erzeugt und die Aktoren gesucht. Diese
Aktoren repräsentieren den Anwender und andere Systeme die auf das zu entwickelnde System
einwirken. Use Cases werden identifiziert, die das Verhalten des Systems repräsentieren. Da die
Use Cases den Bedürfnissen der Aktoren entsprechen, wird das System den Anwendern gerechter.
Jeder Use Case wird detailliert beschrieben. Die Beschreibung zeigt Schritt für Schritt die
Interaktionen zwischen Aktoren und System, sowie dessen Verhalten. Nicht funktionale
Anforderungen werden in sogenannten Supplementary Specifications beschrieben.
Die Use Cases ziehen sich wie ein identifizierender Faden durch den ganzen SystemEntwicklungszyklus hindurch. Das gleiche Use Case Modell wird während der Erfassung der
Requirements, während dem Analysis und Design Workflow und während dem Test Workflow
verwendet.
4.1.2.2.2.3 Analysis & Design Workflow
Dieser Workflows zeigt, wie das System während der Implementations-Phase realisiert wird. Es soll
ein System gebaut werden, das
in einer spezifischen Implementations-Umgebung die Tasks und Funktionen ausführt, die in den
Use Case Beschreibungen spezifiziert wurden
alle Anforderungen erfüllt
robust strukturiert ist (einfach zu ändern, falls die funktionalen Anforderungen ändern)
Analysis und Design führen zu einem optionalen Analysemodell und einem Designmodell. Das
Design Modell dient als Abstraktion für den Source Code, d.h. das Design Modell dient als Plan,
der angibt, wie der Source Code strukturiert und geschrieben wird.
Das Design Modell besteht aus Design Klassen, die mit wohl definierten Schnittstellen in Design
Packages und Subsysteme gegliedert sind. Design Packages und Subsysteme werden bei der
Implementation zu Komponenten. Das Design Modell beschreibt auch, wie Objekte dieser Design
Klassen zusammenarbeiten um die Use Cases auszuführen.
In der Designphase konzentriert man sich auf die Architektur, welche durch Architectural Views
repräsentiert wird. Diese Views definieren die wichtigsten Design-Entscheidungen. Im
wesentlichen sind Architectural Views Abstraktionen oder Vereinfachungen des gesamten Designs,
in dem die Hauptmerkmale und nicht Details fokusiert werden. Eine geeignete Architektur trägt bei
der Systementwicklung viel zur Qualitätssteigerung bei.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 21 von 89
Software Methodik
4.1.2.2.2.4 Implementation Workflow
Zweck:
Definition der Code-Organisation innerhalb der Subsysteme/Layers
Implementation von Klassen und Objekten der Komponenten (Source-Files, Binaries,
Executables)
Test der entwickelten Komponenten als Einheiten(Unit-Test)
Integration der erzeugten Resultate der Entwicklern oder Teams in einem ausführbaren
Programm
Das System wird durch die Implementation der Komponenten realisiert. Der RUP beschreibt wie
bestehende Komponenten wiederverwendet werden und neue Komponenten mit wohl definierten
Verantwortungsbereichen implementiert werden, um das System besser zu warten und die
Möglichkeiten einer Wiederverwendung zu erhöhen.
Komponenten werden in Implementations-Subsystemen strukturiert. Subsysteme weisen die Form
von Directories auf mit zusätzlicher struktureller oder Management-Information. Ein Subsystem
kann z.B. als Directory oder Folder in einem File-System oder als Package in Java erzeugt werden.
4.1.2.2.2.5 Test Workflow
Ziel dieses Workflows:
Verifikation der Interaktionen zwischen Objekten
Verifikation der ordnungsgemässen Integration aller Komponenten der Software
Validierung der Anforderungen
Identifikation und Sicherstellung dass Fehler vor der Auslieferung der Software behoben werden
Der RUP schlägt ein iteratives Vorgehen vor, was bedeutet, dass Tests über den gesamten
Entwicklungszyklus durchgeführt werden, um Fehler so schnell wie möglich zu finden und die
Kosten für die Fehlerbehebung drastisch zu reduzieren. Tests werden nach folgenden QualitätsKriterien durchgeführt:
Zuverlässigkeit
Funktionalität
Application-Performance
System-Performance
Für jedes dieser Kriterien beschreibt der Prozess wie der Test-Lebenszyklus bezüglich Planung,
Design, Implementation, Durchführung und Bewertung durchlaufen wird.
Strategien werden beschrieben, die zeigen, wann und wie Tests automatisiert werden können. TestAutomatisierung ist speziell bei einem iterativen Vorgehen wichtig, damit Regressions-Tests nach
jeder Iteration und nach jeder neuen Version des Produkts durchgeführt werden können.
4.1.2.2.2.6 Deployment Workflow
Dieser Workflow bringt Produktions-Releases hervor, welche an die Anwender ausgeliefert werden.
Folgende Aktivitäten fallen darunter:
Herstellung von externen Releases der Software
Packaging, Verteilung und Installation der Software
Hilfe und Unterstützung für die Anwender
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 22 von 89
Software Methodik
Häufig sind auch folgende Aktivitäten zu beachten:
Planung und Leitung von Beta-Tests
Migration von bestehender Software oder Daten
Formaler Akzeptanztest
Obwohl sich die Deployment Activities meistens auf die Transition Phase konzentrieren, müssen
viele Activities in früheren Phasen behandelt werden als Vorbereitung für das Deployment am Ende
der Construction Phase.
4.1.2.2.2.7 Project Management Workflow
Software Project Management ist die Kunst konkurrierende Ziele auszubalancieren, mit Risiken
zurechtzukommen und Druck zu überwinden, um erfolgreich ein Produkt auszuliefern, das die
Bedürfnisse der Kunden und Anwender deckt. Die Tatsache, dass wenige Projekte erfolgreich
abgeschlossen werden, unterstreicht die Notwendigkeit und Schwierigkeit dieser Aufgabe.
Dieser Workflow konzentriert sich hauptsächlich auf die spezifischen Aspekte eines iterativen
Entwicklungs-Prozesses. Die Aufgabe soll mit den folgenden Mitteln vereinfacht werden:
Ein Framework zur Überwachung und Bewältigung software-intensiver Projekte und deren
Risiken
Praktische Richtlinien zur Planung von Ressourcen, Durchführung und Ueberwachung von
Projekten
RUP bietet kein Erfolgsrezept an, definiert jedoch ein Vorgehen zur Projektführung und erhöht die
Chancen für eine erfolgreiche Software-Auslieferung markant.
4.1.2.2.2.8 Configuration and Change Management Workflow
Dieser Workflow beschreibt, wie man die zahlreichen Artifacts, welche in einem Projekt erzeugt
werden, kontrollieren soll. Kontrolle hilft Leerläufe und Missverständnisse zu vermeiden und stellt
sicher, dass bei den resultierenden Artifacts nicht folgende Probleme auftreten:
Gleichzeitiger Update
Wenn zwei oder mehr Entwickler unabhängig am selben Artifact arbeiten, kann die letzte
Änderung die vorangehenden Arbeiten zerstören.
Unvollständige Benachrichtigung
Wenn ein Problem in einem Artifact behoben wird, das auf mehrere Entwickler aufgeteilt wurde
und einige der Entwickler nicht über die Änderung benachrichtigt werden.
Mehrfache Versionen
Die meisten grossen Programme werden in evolutionären Releases entwickelt. Ein Release
könnte beim Kunden eingesetzt sein, ein anderes im Test und ein drittes befindet sich in
Entwicklung. Falls Probleme in einer dieser Versionen gefunden werden, müssen die
Bereinigungen zwischen den Versionen synchronisiert werden. Inkonsistenzen können zu teuren
Bereinigungen und Nacharbeiten führen, solange Änderungen nicht sorgfältig publiziert werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 23 von 89
Software Methodik
Der Workflow enthält Richtlinien für den Umgang mit mehreren Varianten von evolutionären
Software-Systemen, Verfolgung der verwendeten Versionen in einem bestimmten Build, Erstellung
von Builds individueller Programme oder eines gesamten Releases gemäss benutzer-definierten
Versions-Spezifikationen und Durchsetzung von site-spezifischen Entwicklungs-Grundsätzen.
Es wird beschrieben, wie parallele Entwicklungen und Entwicklungen, die an mehreren Standorten
erfolgen, durchgeführt werden und wie der Build-Prozess automatisiert werden kann. Dies ist
vorallem in einem iterativen Prozess wichtig, wo man gerne ein täglichen Build erstellen möchte.
Ohne mächtige Automatisierung wäre dies unmöglich. Es wird auch beschrieben, wie eine
Aufzeichnung über geänderte Artifacts erhalten werden kann (Grund, Zeit und Entwickler).
Der Workflow deckt auch das Change Request Management ab, d.h. wie werden Fehler gemeldet,
innerhalb des Lebenszyklus behandelt und wie werden Erkenntnisse genutzt, um Fortschritt und
Trends zu verfolgen.
4.1.2.2.2.9 Environment Workflow
Dieser Workflow bezweckt die
Bereitstellung der vom Entwicklungs-Team benötigten Software-Entwicklungsumgebung
Bereitstellung von Prozessen und Tools
Der Workflow konzentriert sich auf die Entwicklung der erforderlichen Richtlinien, die das Projekt
unterstützen. Ein Vorgehen wird mitgeliefert, das Schritt für Schritt beschreibt, wie ein Prozess in
einer Organisation eingeführt wird. Der Workflow enthält auch ein Development Kit, das die
notwendigen Richtlinien, Templates und Tools enthält, um den Prozess an die spezifischen
Bedürfnisse anzupassen. Einige Aspekte werden durch den Prozess nicht abgedeckt: Auswahl,
Erwerb und Inbetriebsetzung der Tools sowie die Pflege der Entwicklungsumgebung.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 24 von 89
Software Methodik
4.2 Phasenmodelle
Von der Festlegung des Leistungsumfangs eines Softwareprodukts bis zu seiner endgültigen
Fertigstellung wird eine Folge zeitlich sequentieller Phasen durchlaufen. In der Literatur findet man
eine Vielzahl verschieden stark detaillierter Phasenmodelle, die abhängig von der
Firmenphilosophie oder dem eingesetzten Werkzeug verwendet werden.
Nach der Auslieferung eines Produkts müssen auftretende Fehler behoben (Wartung) sowie
Anpassungen und Änderungen an Benutzerwünsche realisiert werden (Pflege). All diese Phasen
bilden den Software-Lebenszyklus.
4.2.1 Wasserfallmodell
Das Modell entstand in den 70er Jahren und besteht aus Phasen, die bei der Software-Entwicklung
streng sequentiell durchgeführt werden und jede Tätigkeit abgeschlossen wird, bevor die nächste
beginnt. Deshalb ist es ein dokumenten-getriebenes Modell, das wenig Managementaufwand
fordert. Es erlaubt die Rückkopplung zur unmittelbar vorangegangenen Phase.
Gemäss Wasserfallmodell werden alle Anforderung zuerst vollständig erfasst, danach die
Softwarearchitektur komplett definiert, die ganze Programmierung abgeschlossen und das System
vollumfänglich getestet. Durch diesen festen Lösungsweg ist eine überschaubare Aufteilung der
Gesamtaufgabe möglich und Zwischenergebnisse sind verfügbar.
Eine Benutzerbeteiligung ist nur in der Definitionsphase vorgesehen. Danach erfolgt der Entwurf
und die Implementierung ohne den Benutzer bzw. Auftraggeber. Das Wasserfallmodell
berücksichtigt keine überlappenden Aktivitäten, sondern beschränkt sich nur im Fehlerfall auf die
Rückkopplung. In der Praxis hat sich das Wasserfallmodell nicht bewährt, da erst nach der
Integrationsphase klar wird, ob das entwickelte System überhaupt läuft.
Die klassische Einteilung ist im folgenden Wasserfallmodell dargestellt:
Eine Iteration, die aufgrund entdeckter
Schwachstellen notwendig wird, ist nur
zwischen zwei aufeinander folgenden
Phasen erlaubt (Rückkopplung). Um
das Ziel nicht zu verfehlen und auf dem
jeweils definierten Stand aufbauen zu
können, sollte jede Phase durch einen
Test abgeschlossen und dokumentiert
werden.
Dieses Modell suggeriert, dass die
einzelnen Phasen komplett sequentiell
von oben nach unten durchlaufen
werden.
Abbildung 13: Wasserfallmodell mit Rückkopplungen
In der Praxis werden die ersten 5 Phasen häufig inkrementell bearbeitet, d.h. für jeweils einen
kleinen, unabhängig testbaren Teil werden diese Phasen sequentiell durchlaufen. Das
Klassenkonzept des OO-Ansatzes unterstützt dies.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 25 von 89
Software Methodik
4.2.1.1 Anforderungen/Machbarkeitsstudie (feasibility study)
Aufgaben
Problem informell und abstrahiert beschreiben
Kostenschätzung durchführen
alternative Lösungen erarbeiten
Offerte erstellen
Ergebnisse
Machbarkeitsstudie
Angebot an Auftraggeber
4.2.1.2 Anforderungsanalyse (requirements specification)
Aufgaben
Genaue Festlegung der Systemeigenschaften wie
Funktionalität
Leistung
Benutzungsschnittstelle
Portierbarkeit
Bestimmen von Testfällen
Ergebnisse
Anforderungsanalysedokument
Akzeptanztestplan
Benutzungshandbuch(1. Version)
4.2.1.3 Systementwurf (system design)
Aufgaben
Entwicklung eines Bauplans
Grobentwurf: System in Teilsysteme/Module zerlegen
Feinentwurf: Modulschnittstellen/Algorithmen vorgeben
Ergebnisse
Entwurfsdokument
Detaillierte Testpläne
4.2.1.4 Codieren und Modultest
Aufgaben
Programmieren im Kleinen
Implementierung einzelner Module
Test dieser Module
Ergebnisse
Module
Testprotokolle
4.2.1.5 Integration und Systemtest
Aufgaben
Systemintegration = Zusammenbau der Module
Gesamtsystemtest (α -Test)
Ergebnisse
fertiges System
Benutzerhandbuch
Technisches Testdokument
4.2.1.6 Auslieferung und Installation
Aufgaben
Auslieferung an ausgewählte Benutzer (β -Test)
Auslieferung an alle Benutzer
Schulung der Benutzer
Ergebnisse
fertiges System
Akzeptanztestdokument
4.2.1.7 Wartung (Maintenance)
Aufgaben
Fehler beheben (corrective maintenance)
Anpassungen durchführen (adaptive maintenance)
Verbesserungen vornehmen (perfective maintenance)
SW-Methodik(Script).doc
Ergebnisse
Softwareproblemberichte
Softwareänderungsvorschläge
neue Softwareversionen
Letzte Änderung: 10. November 2001
Seite 26 von 89
Software Methodik
Bei großen Systemen kann der Auftraggeber die Anforderungen meist zu Beginn nicht genau
definieren. Deshalb ist eine strikte Einteilung in Phasen sehr ungeschickt. Eine erste lauffähige
Version entsteht erst sehr spät. Somit müssten bei neuen Anforderungen/im Fehlerfall sämtliche
Iterationen (Rückkopplungen) bis zur Änderung wiederholt werden, da überlappende Aktivitäten
nicht berücksichtigt werden.
4.2.2 Rapid-Prototyping
Multimediale Anwendungen zeichnen sich durch ihre Komplexität aus, die meist schwer in Phasen
erfassbar ist. Das Ziel des Prototyping besteht darin, möglichst schnell ein erstes Ergebnis zu
präsentieren. Das Verfahren hat den Vorteil, dass bereits in der Planungsphase Etappen definiert,
Zwischenergebnisse präsentiert und Änderungen dynamisch vorgenommen werden können. Sind
die Anforderungen erfüllt, wird das System eingeführt, sonst wird das Konzept oder die
Realisierung überarbeitet.
Prototyping ist dann geeignet, wenn während des Projektes häufige Änderungen durch
Benutzerwünsche neue Rückkopplungen und Berichtigungen bewirken. Damit lässt sich der Design
schon in frühen Phasen überprüfen. Prototypen lassen sich schnell entwickeln, sind jedoch nur
teilweise funktionsfähig.
Abbildung 14: Phasen des Prototyping
Abbildung 15: SW-Entwicklungsprozess mit Prototyping
Es existieren unterschiedliche Arten des Prototyping:
horizontal/vertikal
Realisierung einzelner Schichten bzw. einzelner Funktionalitäten
explorativ
Frühe Präzisierung von Anwenderwünschen
experimentell
Überprüfung des Lösungskonzepts auf Softwareebene
evolutionär
Permanente Adaption, keine Trennung von Wartung und Entwicklung
Das Prototyping ist ein sinnvolles Verfahren bei der Multimedia-Entwicklung, das für folgende
Tätigkeiten eingesetzt wird:
Überprüfung der Machbarkeit
Demonstration für den Kunden
Erläuterung von Designaspekten
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 27 von 89
Software Methodik
Ein Rapid-Prototyping Prozess läuft folgendermassen ab:
Ein Prototyp des Systems wird möglichst schnell mit Hilfe von Generatoren und speziellen
Programmiersprachen realisiert (oft nur Benutzeroberfläche)
Ergebnis wird dem Auftraggeber demonstriert
Anschliessend wird der Code verworfen (throw away prototyping) und z.B. das
Wasserfallmodell zur Produktentwicklung angewandt.
Das Prototypingverfahren erlaubt die Klärung der Funktionalität, die Risikominimierung und
vermeidet Missverständnisse zwischen Entwickler und Auftraggeber durch den frühen Test der
Benutzerschnittstelle. Prototyping ist eine sinnvolle Ergänzung zu allen Lebenszyklusmodellen und
unterstützt die Wiederverwendung von Ideen und Konzepten. Es birgt jedoch die Gefahr der
Weiterverwendung des Prototypen. Daraus entsteht ein ungeplantes evolutionäres Prototyping.
Rapid-Prototyping ist bei der Erfassung von Anforderungen sehr hilfreich, kann jedoch zu
erheblichem Mehraufwand führen, da die Benutzeranforderungen trotzdem festgehalten werden
müssen.
4.2.3 Spiralmodell (nach Boehm)
Das Spiralmodell ist ein risikogetriebenes Vorgehensmodell mit phasenweisem Vorgehen und einer
festen Folge von wiederkehrenden Aktivitäten. Es bindet das evolutionäre Prototyping-Modell mit
Alternativenbewertung wie z.B. Risikoanalyse in den jeweiligen Prototypen ein.
Abbildung 16: Spiralmodell nach Barry Boehm
Jede Spirale stellt einen iterativen Zyklus durch die Teilschritte dar. Zuerst werden Ziele,
Alternativen und Randbedingungen identifiziert. Danach die Alternativen evaluiert, die Risiken
mittels Prototypen analysiert und überwunden. Nachdem das Produkt der nächsten Generation
entwickelt und mit dem Kunden verifiziert wurde, kann die nächste Phase geplant werden. Die
Ziele für jeden Zyklus werden aus den Ergebnissen des vorhergehenden Zyklus abgeleitet.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 28 von 89
Software Methodik
Das oberste Ziel ist, die Risiken zu minimieren. Eine Trennung zwischen Entwicklung und Wartung
findet nicht statt.
4.2.4 Das Objektorientierte Modell
Dieses Modell basiert auf der Wiederverwendung von Komponenten. Die Wiederverwendung
erfolgt auf den Ebenen der Analyse (Subsysteme, Klassen, Klassenhierarchien), dem Entwurf und
der Implementierung. Das Modell ist bottom-up-orientiert. Bei jeder Aktivität (Ebene) wird geprüft,
ob Komponenten wiederverwendet werden können. So kann ein bereits vorhandenes OOA-Modell
(Object Oriented Analysis) bzw. ein OOD-Modell (Object Oriented Design) in der Definitionsbzw. Entwurfsphase wiederverwendet werden. Der Fokus verschiebt sich weg von der
Eigenentwicklung hin zur Wiederverwendung von Klassen und Klassenbibliotheken. Dadurch
verbessert sich die Produktivität und Qualität merklich. Der Einsatz von objektorientierten
Methoden ist jedoch zwingend.
Abbildung 17: Das Objektorientierte Modell
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 29 von 89
Software Methodik
4.3 Zusammenfassung
Die Softwaretechnik befasst sich mit der systematischen Erstellung von Software. Hierfür
gebräuchliche Vorgehensmodelle wurden in diesem Kapitel vorgestellt.
Ein wichtiger Schritt bei der Softwareentwicklung ist der Entwurf eines Modelles(Abbildes) der
(realen) Welt, auf den sich die betrachtete Software bezieht. Der Entwurf dieses Modells ist eng
mit der Erfassung der Anforderungen an das zu entwickelnde System verknüpft (Fehler auf
dieser Ebene sind ca. um den Faktor 100 teurer als Implementierungsfehler).
Mit der Auswahl eines allgemeinen Vorgehensmodells muss eine bestimmte Methode der
Softwareentwicklung festgelegt werden (detaillierte Richtlinien, verwendete Modellierungssprachen, eingesetzte Werkzeuge).
Risiko
Wasserfall Modell
Iteratives Modell
Zeit
Abbildung 18: Risikoreduktion durch iteratives Vorgehen und früher Integration der Software
Ein iteratives und inkrementelles Vorgehen ist ein zentrales Element eines jeden praxistauglichen
Softwareentwicklungsprozesses. Weitere Anforderungen daran sind:
Der Prozess muss konkret und auf die verwendete Entwicklungsmethodik abgestimmt sein.
Reine Vorgehensmodelle(V-Modell oder Hermes), welche keine Unterstützung in der
Anwendung der Entwiclungsmethodik(OOA/OOD) bieten, sind von beschränktem Nutzen.
Der Prozess muss dem Projektleiter konkrete Hilfe für die Planung und Kontrolle des Projektes
bieten.
Der Prozess muss gut dokumentiert und mit Beispielen belegt sein.
Prozess-Modell
Primäres Ziel
V-Modell
maximale Qualität
(safe-to- market)
Projekt-Team lernt während Dokumente
den Arbeitsschritten,
bessere Gesamtqualität
minimaler
Dokumente
Managementaufwand
Risikominimierung
Code
RUP
Wasserfallmodell
Prototypen- Modell
Evolutionäres Model
Antreibendes
Moment
Dokumente
Spiralmodell
minimale Entwicklungszeit
(fast-to- market)
minimale Entwicklungszeit
(fast-to-market),
Risikorninimierung
Risikominimierung
Objektorientiertes
Modell
Zeit- und Kosten-minimierung Wiederverwenddurch Wiederverwendung
bare Komponenten
Inkrementelles Modell
SW-Methodik(Script).doc
Benutzer- Charakteristika
beteiligung
gering
sequentiell, volle Breite, Validation,
Verifikation
hoch
benutzerbezogen, sequentiell, vollumfänglich
gering
sequentiell, volle Breite
hoch
nur Teilsysteme (horizontal oder
vertikal)
nur Kernsystem, Wegwerfprototyp
Code
mittel
Code
mittel
Risiko
mittel
hoch
Letzte Änderung: 10. November 2001
volle Definition, zunächst nur
Kernsystem, Überblick verschaffen,
Prototypen weiterziehen
Entscheidung pro Zyklus über
weiteres Vorgehen
volle Breite in Abhängigkeit von
wiederverwendbaren Komponenten
Seite 30 von 89
Software Methodik
5 Unified Modeling Language (UML)
Die UML ist eine Standard-Modellierungssprache zur Visualisierung, Spezifizierung, Konstruktion
und Dokumentation von Modellen, welche im Rahmen des Software-Entwicklungsprozesses
resultieren. Sie kann unabhängig davon eingesetzt werden und hat zum Ziel:
Definition einer ausdrucksstarken Modellierungssprache
Schaffung eines Standards für OO-Modellierungssprachen
Bereitstellung einer formale Basis für das Verständnis
Unabhängigkeit gegenüber Programmiersprachen
Unterstützung höherer Entwicklungskonzepte und Bereitstellung von Erweiterungsmechanismen
UML ist die Synthese der Ansätze von Grady Booch, Ivar Jacobson und James Rumbaugh und
wurde als Standard Notation für die objektorientierte Analyse, Design und Programmierung
entwickelt. Dabei wurden andere Modellierungstechniken zu Hilfe gezogen, wie OOA/OOD, OMT
und OOSE. Allerdings hatten diese Techniken alle ihre Vor- und Nachteile. Mit UML wurde ein
passender Mittelweg gefunde. Nach der ersten Veröffentlichung der Version 0.8 im Jahr 1995
folgte erst die Einreichung der Version 1.0 bei OMG dann eine Ausbesserung in Version 1.1.
UML ist eine (graphische) Sprache für die Modellierung von SW-Systemen. UML definiert keine
Vorgehensmethode, diese muss (zur Zeit) von jeder Firma individuell festgelegt werden. UML
besteht hauptsächlich aus Techniken, um grafisch die Spezifikation und Dokumentation von
objektorientierten Systemen zu beschreiben. Diese Techniken sollen als einheitliche Notation für
viele Einsatzgebiete nutzbar sein. So kann man Datenbankanwendungen, Echtzeitsysteme,
Workflowanwendungen oder auch Grafikprogramme modellieren. Inhalt der UML sind
verschiedene Diagrammtypen mit eigenen grafischen Elementen. Jedes grafische Element hat eine
bestimmte Semantik und Notation und kann entsprechend eingesetzt werden. Bei UML gibt es für
einen bestimmten Sachverhalt oft verschiedene Möglichkeiten diese Semantik darzustellen. Es gibt
die Möglichkeit diese Modellierungssprache für eigene Bedürfnisse zu erweitern(sogenannte
“Stereotypes”). Es gibt auch ein Metamodell, womit sich UML selbst definiert.
Ebenso wie bei einem Bauplan für ein Haus gibt es verschiedene Ansichten auf das System.
Folgende Diagramme sind mit UML möglich:
Use-Case-Diagramme
Klassendiagramme
Interaktionsdiagramme (Sequenzdiagramme, Kollaborationsdiagramme)
Aktivitätsdiagramme
Zustandsdiagramme
Implementierungsdiagramme (Komponenten- und Verteilungsdiagramme)
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 31 von 89
Software Methodik
Bei der Modellierung mit UML hat man ein System und Akteure, die das System benutzen. Mit
Use-Case-Diagrammen kann man grob die verschiedenen Systemzugriffe festlegen. Dabei spricht
man dann von einem Use-Case, einem Anwendungsfall (Beispiel: Dozent erfragt vom
Bilbiothekssystem eine Liste von Dokumenten, die im Rahmen einer Lehrveranstaltung nützlich
sind). Mit den Interaktionsdiagrammen kann man solch einen Anwendungsfall innerhalb des zu
modellierenden Systems dynamisch mittels Austausch von Messages zwischen den beteiligten
Systemkomponenten beschreiben. Im Zuge der Modellierung sollte man somit immer mit den UseCases anfangen, anschließend diese Anwendungsfälle verfeinern, wobei man mit den
Interaktionsdiagrammen bereits notwendige Komponenten und deren Funktionalität des zu
entwickelnden Systems erkennt. Die statischen Beziehungen zwischen diesen Komponenten sind
mit Klassendiagrammen auf Objekttyp und Instanzebene darstellbar. Mit einem Packagediagramm
lassen sich dann grobe Funktionalitäten zu Komponenten oder Modulen zusammenfassen.
Mit diesen verschiedenen Diagrammtypen und der Möglichkeit die Darstellung mit
unterschiedlichen Beschriftungsarten zu variieren hat man eine recht umfangreiche Sprache. Damit
ist einerseits viel Ausdruckskraft gegeben, andererseits wird die Sprache dadurch unübersichtlich.
Es gibt einen Kern von UML-Notationen, der für die meisten Anwendungsfälle ausreicht. Zudem
wird immer nur das modelliert, was den darzustellenden Sachverhalt, eine bestimmte Ansicht des
zu modellierenden Systems wiederspiegelt. Dazu reicht der Kern der UML-Modellierungssprache.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 32 von 89
Software Methodik
UML bietet folgende Modellierungskonzepte an:
Use-Case Diagramm(Use-Case-Diagram): Spezifikation der Aktoren und deren Benutzung der
Systemfunktionen(=Use case). Einsatz OOA
Klassendiagramm(Class Diagram): Modellieren die (Objekt-)Klassen und die Beziehungen
zwischen den Klassen (statisches Modell). Einsatz OOA, OOD, OOP
Interaktionsdiagramm(Interaction Diagrams) (dynamisches Modell): Beschreiben die
Interaktionen zwischen den Ob- jekten via Events. Interaktionen werden mit Sequenz- und
Kollaborationsdiagrammen beschrieben. Einsatz OOA, OOD, OOP
Zustandsdiagramm(State-Transition Diagram) (dynamisches Modell): Spezifizieren die Zustände
der einzelnen Objekte, die Zustandsübergänge mit den auslösenden Events und der
resultierenden Actions. Einsatz OOA, OOD
Aktivitätendiagramm(Activity Diagrams): Diese Diagramme beschreiben Aktivitäten und
systemweite Abläufe. Sie sind eine Kombination von Petri-Netzen und Flussdiagrammen.
Einsatz OOA, OOD
Komponentendiagramm(Package Diagram): Packages gruppieren Klassen zu logischen
Einheiten. Package Diagramme modellieren die Komponenten und ihre Abhängigkeiten. Einsatz
OOD
Verteilungsdiagramm(Deployment Diagram): Aufteilung der Komponenten auf verteilte
Rechner. Einsatz OOD
Die wichtigsten Diagramme(Klassen-, Interaktions- und Zustands-Diagram) kommen in allen
Phasen einer Entwicklung zum Einsatz. Jede Phase fügt weitere Details dazu. Die verschiedenen
Diagramme modellieren Teilaspekte des zu entwickelnden Systems. Das Klas- sendiagramm ist das
Trägermodell für die anderen Diagramme. Die Diagramme müssen unterein- ander konsistent sein.
Die Sicherstellung dieser Konsistenz ist nicht immer einfach und meist nur mit
Werkzeugunterstützung zu erreichen. Ein anderes Problem ist die Vollständigkeit der Modelle: Wie
können wir sicherstellen, dass die erstellten Diagramme eine vollständiges Abbild des betrachteten
Systems vermitteln?
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 33 von 89
Software Methodik
6 Software Entwicklungsprozess - Überblick
Ein objekt-orientierter Entwicklungsprozess wird durch Use-Cases angetrieben und durchläuft in
jeder Iteration alle Phasen:
Anforderungs-Spezifikation
Einführung
Analyse
Design
Testen
Implementation
Abbildung 19: Software Entwicklungsprzess
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 34 von 89
Software Methodik
6.1 Anforderungsspezifikation
Zuerst werden die Anforderungen an das System und die Prozesse definiert, welche das System
abbilden muss. Beschrieben wird das zu entwickelnde System mit der Unified Modeling
Language(UML), einer Notation, um Systeme mit objekt-orientierten Konzepten zu modellieren.
In dieser Phase wird ein Iterationsplan erstellt, welcher die definierten Use-Cases den einzelnen
Entwicklungszyklen zuordnet.
Abbildung 20: Use-Cases den einzelnen Entwicklungszyklen zuordnen
6.2 Analyse
Analyse = Was soll das System im einzelnen tun?
Vollständige und eindeutige Untersuchung des Problems bezüglich Benutzerbedürfnissen. Punkto
Benutzerfreundlichkeit dürfen folgende Punkte nicht vergessen werden:
Benutzungsoberfläche
Bildschirmmasken entwerfen
Festlegung und Darstellung der Ein- und Ausgabedaten
Systemreaktionen(Fehlermeldungen, Warnungen, Informationen)
Steuerung des Programmablaufs durch den Benutzer(Tasten, visuelle Komponeneten)
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 35 von 89
Software Methodik
In der Analyse wird ein Problem sprachunabhängig mit Use-Cases und Konzepten beschrieben. Ein
Konzeptionelles Modell repräsentiert die Real-World Problemdomain mit Beziehungen und
Eigenschaften der Konzepte, jedoch keine organisatorischen Funktionen oder Datenbankaspekte.
Die Beziehungsnamen zwischen den Konzepten müssen so gewählt werden, dass man die Relation
als Satz lesen kann, z.B. "Ein Kunde kann mehrere Konti besitzen. Ein Konto ist eindeutig einem
Kunden zugeordnet."
Konto
1
0..n
Kunde
(f ro m U se Cas e View)
Ein Use-Case, Anwendungs- oder Geschäftsfall, wie er auch genannt wird, beschreibt eine Sequenz
von Ereignisssen, welche durch einen Aktor ausgelöst werden und ein System benötigen, um einen
Prozess auszuführen. Ein Aktor ist ein Teilnehmer in der Geschichte des Use-Cases. Der Use-Case
Titel startet mit einem Verb gefolgt von einem Nomen, z.B. "Erzeuge Kunde", "Füge Konto an"
6.3 Design
Design = Wie kann das Modelle umgesetzt werden?
Ein Designmodell repräsentiert SW- oder HW-Komponenten. Die Klassen, Methoden mit ihren
Sichtbarkeiten und Übergabeparametern, sowie die Attributtypen sind bestimmt. Die
Programmarchitektur wird durch Zerlegen des Systems in einzelne Komponenten erreicht.
6.4 Implementation
Der logische Lösungsansatz mit seinen Modellen und Diagrammen aus dem Design wird mit einer
Programmiersprache in Software umgesetzt. Dabei werden die Algorithmen innerhalb der
Methoden entwickelt, auscodiert und ins Programm integriert.
6.5 Testen
In der Testphase werden die definierten Anforderungen und Use-Cases des Produktes validiert.
Sinnvolle Testdaten und Testverfahren werden festgelegt und eine Testumgebung aufgesetzt. Über
die Tests gibt ein Testprotokoll Auskunft.
6.6 Einführung
Ist das System getestet, kann es produktiv eingesetzt werden. Neben der Infrastruktur,
Datenmigration und dem Zusammenstellen einer lauffähigen Programmversion, muss ein
Benutzerhandbuch zur Verfügung stehen, sowie die Benutzerschulung erfolgen.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 36 von 89
Software Methodik
7 Anforderungsspezifikaton
7.1 Anforderungen
Am Anfang eines jeden Software-Projekts steht eine möglichst detaillierte Beschreibung der
Anforderungen des Kunden. Diese Anforderungen werden in einem Pflichtenheft gebündelt und
von beiden Vertragsparteien unterzeichnet. Der Auftraggeber bestätigt mit seiner Unterschrift, daß
er nur diese und keine anderen Anforderungen benötigt. Der Auftragnehmer verpflichtet sich, eine
Software zu liefern, die genau diese Anforderungen erfüllt. Leider kommt es immer wieder vor, daß
der Auftraggeber nach Unterzeichnung des Pflichtenhefts noch Änderungswünsche einbringen
möchte. Bleiben diese vom Umfang her im Rahmen, ist eine Einarbeitung in das Pflichtenheft
unkritisch. Bei größeren Wünschen ist oftmals eine Nachverhandlung vor allem hinsichtlich Kosten
und Auslieferungstermin notwendig.
Die Rahmenbedingungen, welche in der Anforderungsspezifikation definiert werden, sind
vertraglich verpflichtend und dienen bei der Abnahme durch den Kunden als Validationsgrundlage.
Die wichtigsten aufzuführenden Punkte sind:
Einführender Teil: Zweck, Gültigkeitsbereich, Definition, Referenzen, Dokumentenübersicht
Allgemeine Beschreibung: Benutzergruppen, möglicher Erweiterungen, Probleme, Annahmen
und Abhängigkeiten
Anforderungen: funktional, Leistung und Menge, Schnittstelle
Randbedingungen
Merkmale bezüglich Sicherheit und Wartbarkeit
Inbetriebnahme/Installation, Konfigurierbarkeit, Betrieb
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 37 von 89
Software Methodik
7.2 Use-Case
Zur Erfassung der Anforderungen von interaktiven Software-Systemen eignen sich Use-Cases (zu
deutsch Anwendungsfälle) sehr gut. Darin werden neben den möglichen Benutzern auch Szenarien
beschrieben, wie sie sich bei der täglichen Arbeit abspielen.
Ein Use-Case(Anwendungsfall) ist eine allgemeine, informelle Beschreibung mehrerer typischer
Interaktionen zwischen einem Benutzer und dem System, welche ähnliche oder gleiche Abläufe
aufweisen und in Szenarien beschrieben sind, wie im Use-Case „Geld abheben am Bankomat“.
Kunde
Geld abheben am Bankomat
1.
2.
3.
4.
Kunde schiebt Karte ein.
Bankomat verlangt den PIN-Code.
Kunde tippt PIN-Code ein.
Bankomat offeriert Auswahlmenü mit den Optionen “Geldbezug ohne Beleg”, “Geldbezug mit
Beleg” und “Kartenrestbetrag abfragen”.
5. Kunde wählt beispielsweise “Geldbezug ohne Beleg” und tippt den Betrag ein.
6. Bankomat gibt Karte zurück und schiebt die Geldnoten hinaus.
Die an einem Use-Case beteiligten Personen(z.B. Kunde) oder externen Systeme nennt man
Akteure, wobei auch hier eine Verallgemeinerung stattfindet. Die Use-Case-Spezifikation erfolgt
textuell. Folgende Punkte werden beschrieben:
Name
Vor-/Nachbedingungen
Szenario-Beschreibung
Variationen
Regeln
Services
Ansprechpartner
oder mit Hilfe von Aktivitätendiagrammen aus konzeptioneller Sicht.
Ein Use-Case beschreibt die Funktionalität eines Systems aus der Benutzersicht. Es interessieren
nur die Interaktionen zwischen Aktoren (Benutzern) und System, nicht aber was innerhalb des
Systems geschieht. Diese Grenze wird durch die Systemgrenze verdeutlicht. In weiteren
Anwendungsfällen kann ein System wieder als Aktor erscheinen, z.B. ein Buchungssystem (eines
Reisebüros) in Bezug auf ein anderes System (Flugreservierungssystem).
Use-Cases beschreiben also nur die Aktivitäten, welche durch die zu entwickelnde Software
unterstützt werden sollen, sowie deren Berührungspunkte zum Umfeld dieser Software. Alle UseCases zusammen bilden ein Modell, das die funktionalen Anforderungen an die Software
beschreibt, aber nicht, wie das interne Verhalten des zukünftigen Systems aussieht.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 38 von 89
Software Methodik
Bei der Use-Case Analyse sollte man sich folgende Fragen stellen:
Wer führt die Aktion aus (Subjekt)?
Wer ist der Empfänger (Objekt)?
Was ist ausgeführt (Verb)?
Abstraktion/Generalisierung:
Sind die Klassen spezifisch oder allgemein?
Gibt es Klassen oder Teile einer Klasse mit gemeinsamen Charakteristiken (Attribute), Verhalten
(Methoden)?
7.2.1 Szeanrio
Ein Szeanrio beschreibt eine typische Folge von Aktionen innerhalb eines Use-Cases. Neben dem
Allgemeinfall werden auch die Spezial-/Ausnahmefälle beschrieben. Diese definieren, was
geschieht, wenn gewisse Bedingungen nicht erfüllt sind und deswegen ein anderer Ablauf
fortgesetzt werden muss.
Beispiel: Szenario des Use-Cases „Preis ändern“
Aktor
System
1. Der Mitarbeiter sucht das gewünschte Produkt durch
Eingabe der Produktenummer.
2. Das System zeigt alle Daten des
selektierten Produktes an.
3. Der Mitarbeiter trägt den neuen Gesamtpreis ein.
4. Das System prüft, ob der Preis
innerhalb der zulässigen Grenzen liegt.
5. Das System prüft, ob aktuelle Aufträge
betroffen sind und fragt, ob sie den
alten oder neuen Preis erhalten sollen.
6. Der Mitarbeiter kann die Änderung hier rückgängig
machen.
7. Der neue Preis wird übernommen.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 39 von 89
Software Methodik
7.2.2 Use-Case Findung
1. Systemgrenzen festlegen
Abgrenzen, was gehört zum System und was sicher nicht?
2. Stelle eine Reihe von Szenarien auf
- in Zusammenarbeit mit den Benutzern des Auftraggebers/Kunden
- Quellen können auch bestehende Systeme sein
3. beteiligte Aktoren identifizieren
- Systeme, Personen mit ihren Rollen, Tätigkeiten, Fähigkeiten und Aufgaben
- evtl. Aktor-Gruppen bilden
4. Use-Cases nur namentlich identifizieren
- ähnliche Szenarien gruppieren
- mit Brainstorming ca. 80% aller denkbaren UC’s (30- 120) definieren
- Haupt- und Tätigkeitswort aufschreiben, z.B. “Preis ändern”
5. Unechte Use-Cases eliminieren
- nicht-funktionale UC (Performance, Leistung), Datenschutz oder Benutzerfreundlichkeit
6. Use-Cases zu Packages zusammenfassen
- mit gleichen Aktoren
- Use-Case Modell erstellen
7. Kurzbeschreibungen erstellen
- Use-Case Name, Aktoren, Kurzbeschreibung (inkl. Zweck) mittels CRC-KärtchenTechnik(Rollenspiel) erfassen
- evtl. Benutzeroberflächen skizzieren
8. Use-Cases priorisieren
- Architektur-relevante(für OOA/OOD)
- Risiko-behaftete(für Projektmanagement)
9. Normalfall für hoch-priorisierte Use-Cases formulieren
- „Happy Day“-Szenario in 5-10 Schritten beschreiben, nicht ins Detail gehen
- Pre-/Post-Condition, Auslöser, Resultat, Alternativen, Szenarien
10. Pro Use-Case eine Datei anlegen, z.B. „101 Produkt erfassen.doc“
11. Hauptdokument erstellen
- Systemübersicht, Aktoren-(Gruppen), Use-Case-Liste, Use-Case Modell
- Systemweite nicht-funktionale Anforderungen
Use-Cases gelingen selten im ersten Wurf. Sie müssen durch Diskussionen mit dem Auftraggeber in
einem iterativen Vorgehen immer weiter verfeinert werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 40 von 89
Software Methodik
7.3 Use-Case-Diagramm
Große Software-Systeme bestehen meist aus einer Vielzahl von Use-Cases. Nachdem diese
geschrieben sind, erstellt man ein Use-Case-Diagramm, das alle an den Use-Cases beteiligten
Akteure, sowie die Namen der Use-Cases visualisiert. Dies gibt einem einen Überblick über die
Funktionlität des Systems. Darin wird dargestellt, welche Aktoren, welche Use-Cases bzw. welcher
Use-Case von welchen Aktoren ausgeführt wird.
Kasse
Kaufe Ware
Melde am
Sy stem an
Kassiererin
Kunde
Erstatte Ware zurück
Starte auf
System
Administ rator
Manager
Verwalte Benutzer
Abbildung 21: Use-Case Diagramm zum Kassensystem
Kunde
Artikel bestellen
Lagerist
Rechnung bezahlen
Artikel erfassen
Bestellung versenden
Preis ändern
Abbildung 22: Use-Case Diagramm zur Artikelbestellung
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 41 von 89
Software Methodik
Ein Use-Case-Diagramm zeigt die Beziehungen zwischen Aktoren und Anwendungsfällen in einem
System. Ein Use-Case-Diagramm für ein System besteht aus:
Systemgrenze
Aktoren
Anwendungsfällen(Use-Cases)
Beziehungen zwischen Aktoren und Anwendungsfällen
Abbildung 23: Use-Case Konzepte
7.3.1.1 Aktor
Ein Aktor ist eine Abstraktion eines Objekt außerhalb des Systems, das mit dem System interagiert
und Use-Cases ausführt, z.B. ein Benutzer. Möglich dabei sind:
mehrere Rollen für einen Benutzer
mehrere Benutzer mit der gleichen Rolle
Systeme als Aktoren
Aktoren sind durch Substantive gegeben und durch textuelle Beschreibung ihrer Rollen,
Tätigkeiten, Fähigkeiten und Aufgaben beschrieben.
7.3.1.2 Generalisierung
Generalisierung setzt spezialisierte Anwendungsfälle in Beziehung zu allgemeineren. Der
Spezialfall erbt alle Eigenschaften des allgemeinen und fügt weitere hinzu oder ersetzt sie.
7.3.1.3 Include (in UML 1.1: uses)
Einschluß bedeutet das Aufnehmen eigenständiger ähnlicher Aktionsfolgen in einen Basisfalls.
Der eingeschlossene Fall kann unabhängig vom Basisfall und von verschiedenen Basisfällen
wiederholt genutzt und wiederverwendet werden.
7.3.1.4 Extend
Erweiterungen dienen zur Definition von Variationen und Sonderfälle, damit der erweiternde Fall
den Basisfall durch entsprechende Aktionen ergänzt. Der erweiternde Fall kann nicht alleine
ausgeführt werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 42 von 89
Software Methodik
7.4 CRC Karten(Class Responsibilities Collaborations)
Bei der Kurzbeschreibungen der Use-Cases kann die CRC-Kärtchentechnik sehr hilfreich sein. In
einem Workshop werden die Anforderungen in einem Rollenspiel diskutiert. Jede Person ist für
einige Konzepte verantwortlich, welche ihm während der Diskussion zugeteilt werden. Immer wenn
das Konzept (z.B. Kunde) im Gespräch ist, notiert er sich die erwähnten Eigenschaften (Attribute)
oder Verantwortlichkeiten (Funktionen/Methoden). Die CRC-Kärtchen beschreiben zwar nicht die
Use-Cases. Der Prozess, der sich während der CRC-Technik abspielt, nämlich das Rollenspiel,
liefert einem jedoch neben den gefundenen Konzepten(je CRC-Karte eines, z.B. Kunde) auch
gerade die Use-Cases. Das "Protokoll" der Workshop-Diskussion stellt die Kurzbeschreibung und
die möglichen Szenarien der Use-Cases dar.
Natürlich kann man auch zuerst Use-Cases "ausbrüten" und danach Gedanken über Konzepte
machen. Die CRC-Technik ist teamorientiert, motivierend, liefert die Use-Cases und Konzepte in
einem Zuge und macht erst noch Spass.
Hilfsmittel zur Identifikation, Klassifizierung und Analyse der internen Objekte des zu
entwickelnden Systems
heuristische Methode, welche auf einfachen Richtlinien fundiert
auf Teamarbeit zugeschnitten
keine Unterstützung durch ein rechnergestütztes Tool nötig
Besonders wirkungsvoll nach einer UseCase-Analyse, wenn die Spezifikationen der
Nutzungsfälle und der entsprechenden Szenarien vorliegen
Karteikarten:
Nicht nur der Inhalt sondern auch die Anordnung der Karten spielt eine Rolle
CRC-Karten sind nur Diskussionsgrundlage
Vorteil: kein zwingender Formalismus, keine Einschränkung des Designers
Class
Name der Klasse
Rollen(situationsgegebenes Synonym, Zustand), z.B Fahrer, Reservierender, Rechnungsempfänger
Responsibilities
Collaborators
Aufgaben der Klasse (kurz, prägnat,
Aktivform)
verantwortlich für alles, was sie zur
Erfüllung der Aufgaben benötigt, für die sie
vorgesehen ist
Wissen, worüber ihre Objekte verfügen
müssen (Zustände und Eigenschaften)
Verhalten
ihrer
Objekte
(kurze
Beschreibungen jedes Dienstes, den die
Klasse anbietet bzw. ausführt, sowie Bedarf
an Diensten von anderen Objekte)
Klassen, die benötigt werden, um Aufgaben zu
erfüllen
• Kollaborationspartner sind Klassen, mit
denen eine Klasse zur Erfüllung ihrer Dienste
zusammenarbeitet
• Grundlage
ist
der
Client-Server
Mechanismus:
Client fordert Dienst eines anderen
Objekts an
Server stellt Dienst für andere Objekte
bereit
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 43 von 89
Software Methodik
Während der Diskussionen sollten folgende Tätigkeiten beachtet werden:
Verschieben und Umlegen von Karten
Zeigen auf Karten
Rollenspiele (Designer “spielen Klassen”)
Es gibt keine fixen Regeln. Die CRC-Technik hat eher informellen Charakter, wo neue
Bedeutungen jederzeit vereinbart werden können:
7.4.1 Identifikation der Objekt bzw. Klassen
•
•
Walkthrough durch die Spezifikation des Szenarios der UseCases
aus den Spezifikationen Kandidaten für relevante Objekte heraus filtern:
Kandidaten für die Objekte sind Prädikate bzw. Ausdrücke mit Verben
Hauptwörter und Adjektive liefern direkt Objekte oder Zustände(Attribute) von Objekten
Ergebnis: Liste mit relevanten Objekten und zugeordneten Methoden und Attributen
7.4.2 Anlegen von Klassenkarten
•
•
•
Für jede der identifizierten Klassen wird eine Klassenkarte(CRC-Karte) angelegt
Klassenkarte enthält Name, Zweck, Verantwortungen und Kollaborationen der Klasse
Klassenkarten sollten nicht ausschliesslich zu Datenbehältern werden.
7.4.3 Erfassung und Analyse der Kollaborationen
•
Agiert das Objekt als Client? Welches Objekt verfügt über Daten, aus denen die benötigten
Daten ableitbar sind? Welches Objekt bietet den benötigten Dienst an?
• Agiert das Objekt als Server? Wesentlich ist, was der Dienst bezweckt und nicht, wie er
realisiert wird.
• Überschneiden sich die Verantwortungen von mehreren Objekten? Ist die Definition einer
Vererbungsbeziehung sinnvoll?
Ergebnis: Liste der Client- und Serverobjekte (paarweise verknüpft) und Klassengruppen, welche
sich in ihren Verantwortungen überdecken.
7.4.4 Gruppierung der Klassenkarten
•
Den Klassen mit den meisten Kollaborationspartnern werden die Karten ihrer direkten und
indirekten Kollaborationspartnern zugeordnet.
• Anordnung:
nahe beieinander: Verwandtschaft, Kooperation, wechselseitige Abhängigkeit
untereinander: Steuerung, Benutzung, Abhängigkeit der unteren Klasse von der oberen,
Subklassenrelation, zeitlicher Ablauf
überlappend: Referenz, Besitz, logische oder physische Umschließung
gestapelt: Gleichartigkeit, wechselseitige Ersetzbarkeit, gemeinsames Auftreten
• bei Bedarf Kopieren der Klassenkarten, dabei Kennzeichnung der Kopie (z.B. durch andere
Farbe)
Ergebnis: Gruppierung als brauchbarer Ansatz für eine Diskussion im Team.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 44 von 89
Software Methodik
7.4.5 Diskussion der Verantwortungen und Kollaborationen
•
•
•
•
•
•
das Team sollte möglichst aus einem Anwendungsexperten, maximal 4 Entwickler und einem
neutralen Moderator bestehen
Moderator sorgt für eine zielgerechte Diskussion und notiert Vorschläge sowie ihre
Bewertungen
Brainstorming, wachsendes Verständnis über die Abläufe und der Abstimmungsprozeß führen
in der Regel zu guten Ergebnissen
Klassenkarten an Pinwand oder Magnettafel anbringen
Untersuchung der Klassen und Gruppierungen
Bildung von zusammenhängenden Klassen mit stark wechselseitiger Verantwortungen
Vereinfachung der Struktur durch Bildung von zusammenhängenden Klassengruppen
Vorschläge für die Modifikation von Klassen und Klassengruppen einbringen
7.4.6 Datenübertragung in das Modell
•
•
•
Bestandteil der Entwicklungsumgebung
enthält das Diskussionsergebnis der CRC-Methode
bildet Grundlage für die Konzipierung des logischen Modells (z.B. UML-Klassendiagramme,
Aktivitätsdiagramme)
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 45 von 89
Software Methodik
8 Analyse
8.1 Vom Use-Case zum Domainmodell
Aus der Beschreibung der Use-Cases werden die Konzepte und Schlüsselabstraktionen des
Anwendungsbereiches herausgeschält und analysiert. Dabei halten wir uns stets an folgendes
Vorgehen:
1
•
Als erstes werden aus den Use-Cases alle Hauptwörter extrahiert, die aus dem
Anwendungsbereich stammen. Daraus ergeben sich die potentiellen Klassen des
objektorientierten Analysemodells1 (OOA-Modell). Falls noch keine CRC-Kärtchen
bestehen, werden danach je Klassennamen eine eigene CRC-Karteikarten geschrieben und
auf ein grosses Flipchartpapier gelegt. Darauf lassen sie sich einfach herumschieben. Neben
dem Klassennamen werden auch die von der Klasse verwalteten Informationen festgehalten.
•
Nun werden die Klassen zu logischen Einheiten gruppiert und die Abhängigkeiten zwischen
ihnen mit Strichen (UML-Assoziationen) visualisiert. Dazu beantworten wir Fragen wie:
„Sind gewisse Klassen Attribute von anderen Klassen?“ oder „Gibt es pro Klasse X mehrere
Exemplare der Klasse Y?“
•
Wir gehen im Team den Use-Case Schritt für Schritt durch und überlegen uns, in welcher
Klasse die Aktionen ausgeführt werden. Daraus resultieren die potentiellen Operationen
dieser Klasse. Dabei ordnen wir jede Klasse einem Teammitglied zu. Wie in einem
Rollenspiel fragen wir uns, welche Aufgabe und Zustände ein Mitglied hat, welches für eine
Klasse verantwortlich ist. Solche Design-Entscheide, welche die Verantwortlichkeit einer
Klasse betreffen, halten wir jeweils auf der entsprechenden Karteikarte fest. Bei
Unsicherheiten hilft die Beantwortung folgender Fragen weiter: „Welche Klasse kennt die
Informationen?“ und „Ist es die Verantwortung der Klasse oder delegiert sie die Tätigkeit an
eine andere Klasse?“
•
Sobald wir ein stabiles Modell haben, wird das Modell mit einem UML-Design-Werkzeug
festgehalten. Zudem werden Klassen, die keinen Bezug zu anderen haben und keine
Operationen enthalten, von der Liste der potentiellen Klassen gestrichen.
•
Zum Schluss wird für jeden Use-Case das zugehörige System-Sequenzdiagramme erstellt
und das Modell mit den neuen Erkenntnissen nochmals verfeinert.
Häufig auch Geschäftsmodell oder Domain-Modell genannt.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 46 von 89
Software Methodik
8.1.1 Klassendiagramm
Aufgrund der funktionalen Anforderungen und den Use-Cases gewinnen wir mit der CRCKärtchentechnik die nötigen Informationen, um das Klassenmodell mit seinen Konzepten und
Beziehungen zu erstellen.
Position
menge
0.. n
ProduktSpezifikation
Produkt
bezeichnung
beschreibt
1 preis
serienNummer
1
0..n
produkteCode : ProduktCode
beschrieben durch
1..n
enthalten in
1..n
1
Einkauf 0..n
macht
1
enthält
erfolgt in
datum
1 zeit
1
Produkt Ka
talog
erf asse
1
Kunde
1
begleichen mit
(from Use Case View)
0..n
gelagert in
1
Bezahlung
1
1
betrag
Kasse
0..n
startet auf
1
adresse
name
besitzt
1..n
1
Laden
1
1
bedient
1
Manager
Kassiererin
(from Use Case View)
(from Use Case View)
Abbildung 24: Klassendiagramm des Kassensystems
Bei der Identifizierung von Klassen und Verantwortlichkeiten ist die Kenntnis der GRASP-Pattern
sehr hilfreich. Sie definieren wie ein Objekt erzeugt wird, welche Aufgaben ein Objekt
wahrnehmen muss und welche es delegieren kann, sowie welche Abhängigkeiten zwischen den
Objekten bestehen.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 47 von 89
Software Methodik
8.1.2 System-Sequenz Diagramm
Ist ein Use-Case etwas umfangreicher und besteht aus mehreren Aktionen, die zeitlich nacheinander
folgen, so wird dies in einem System-Sequenzdiagramm detaillierter beschrieben. Dabei
interessieren nur die Ereignisse(Events), welche der Aktor auslöst und nicht die Aktionen, welche
das System intern ausführt. Das System wird im System-Sequemzdiagramm als Black-Box
betrachtet.
: System
: Kassiererin
1: erfasseProdukt(produktCode, menge)
Use Case: Kaufe Ware
2: beendeEinkauf()
Typischer Ablauf
1. Der Use Case beginnt, wenn ein Kunde mit
Produkten an der Kasse eintrifft.
3: bucheBetrag(Betrag)
2. Die Kassiererin gibt für jedes Produkt den
Produkt Code ein. Falls mehrere gleiche Produkte
vorhanden sind, kann die Menge eingegeben
werden.
3. Das System bestimmt den Produktpreis und fügt
die Produktinformation dem Einkauf an. Preis und
Bezeichnung des aktuellen Produktes, sowie das
Total werden angezeigt.
4. Wenn alle Produkte erfasst sind, wird der
Einkauf abgeschlosssen und der Kunde bezahlt
den Betrag.
5. Das Rückgeld wird berechnet und dem Kunden
zurückgegeben. Die Buchung wird abgeschlossen
6. Das System ist für den nächsten Einkauf bereit.
Abbildung 25: System-Sequenz Diagramm für den Use-Case: Kaufe Ware des Kassensystems
Die neuen Erkenntnisse fliessen ins bestehende Klassenmodell ein. Nomen können zu potentiellen
Klassen oder Attribute werden, Verben die Funktionalität von Methoden beschreiben.
Diese Verfeinerung geschieht in mehreren Iterationen:
Iteration 1: Klassendiagramm aus Use-Cases erstellen
Iteration 2: Klassendiagramm mit Erkenntnisssen aus System-Sequenzdiagramm verfeinern
Iteration x: Erkenntnisse aus Reviewsitzung einfliessen lassen
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 48 von 89
Software Methodik
8.2 Analysekonzepte
Analysekonzepte sind ungeschriebene Verhaltensregeln, welche mit einer gewissen
Modellierfahrung selbstverständlich werden. So ist es nicht sinnvoll gleich zu Beginn ein
Klassenmodell zu erstellen, wo man bereits die Methoden einträgt. Zuerst verschafft man sich einen
Überblick mit einem Konzeptionellen Modell, welches die Konzepte(spätere Klassen) und ihre
Beziehungen aufzeigt. Beziehungen werden zu diesem Zeitpunkt noch nicht als Attribute definiert.
Die Beziehung kann jedoch mit dem zukünftigen Attributnamen bezeichnet werden. Somit hat man
der Beziehung einen Namen und eine Kardinalität gegeben. Im folgenden sind einige
Analysekonzepte kurz erläutert.
8.2.1 Konzeptionelles Modell
Ein
konzeptionelles
Modell
zeigt
real-world
Konzepte
und
nicht
SoftwareArtefakte(EinkaufDatenbank) oder Klassen(Einkauf) mit Methoden. Einem Einkauf kann man im
Laden ja auch nicht den Auftrag geben, er solle sein Total berechnen. Dafür braucht es die
Kassiererin).
Einkauf
Einkauf
EinkaufDatenbank
datum
zeit
datum
zeit
drucke()
8.2.2 Spezifikations Konzept
Eine Produkt-Spezifikation beschreibt ein konkretes Produkt, welches verkauft werden kann. Sind
alle Produkte verkauft, können mit Hilfe der Produkt-Spezifikation wieder neue Produkte
nachbestellt werden.
_Produkt
bezeichnung
preis
produkteCode
serienNumm er
ProduktSpezifikation
bezei chn ung
prei s
prod ukteCode : Prod uktCo de
SW-Methodik(Script).doc
b eschreib t
1
0..n
Produkt
serienNum mer
Letzte Änderung: 10. November 2001
Seite 49 von 89
Software Methodik
8.2.3 Einfache Attribute
Zur Attributdefinition sind in der Analyse nur primitive Datentypen erlaubt. Eigene Objekte werden
mit Assoziationen beschrieben.
Kasse
bedient
1
_Flug
1
destination
_Kassiererin
Kassiererin
name
aktuelleKasse
name
0..n
Flug
0..n
1
startet in
+Startflughafen
Flughafen
+Zielflughafen
endet in
1
Falls das Attribut ein reines Datenelement ist, kann es als Attribut definiert werden.
ProduktSpezifikation
bezeichnung
preis
produkteCode : ProduktCode
Laden
adresse
name
SW-Methodik(Script).doc
ProduktSpezifikation
Laden
befindet sich an
0..n
Produkt Code
hat
1
1
Adresse
strasse
1 ort
Letzte Änderung: 10. November 2001
Seite 50 von 89
Software Methodik
8.3 GRASP-Pattern
8.3.1 Einleitung
8.3.1.1 Was sind GRASP-Patterns?
GRASP-Patterns sind Analysemuster, welche grundlegende Prinzipien der Zuweisung von
Verantwortlichkeiten an Objekte beschreiben und über die Analysekonzepte hinausgehen. GRASP
ist ein Akronym, welches für General Responsibility Assignment Software Patterns steht.
Eigentlich müsste man GRAS-Patterns sagen. GRASP-Patterns tönt jedoch schöner, weshalb man
sich darauf geeinigt hat.
Die 5 wichtigsten GRASP-Patterns sind:
Experte (expert)
Erzeuger (creator)
Kontroller (controller)
Hoher Zusammenhalt (high cohesion)
Geringe Kopplung (low coupling)
8.3.1.2 Pattern
Entwurfsmuster, Prinzip, welches eine allgemein bekannte Lösung beschreibt und auf andere
Probleme übertragen und angewandt werden kann. Es stellt eine Anleitung zur Anpassung auf die
eigene Aufgabe zur Verfügung.
8.3.1.3 Verantwortlichkeiten
Bei der Modellierung spielen die Verantwortlichkeiten der einzelnen Klassen und ihren
Beziehungen zueinander eine wichtige Rolle. Dabei wird Verantwortlichkeit als Vertrag oder
Verpflichtung einer Klasse gesehen, bezüglich ihrem Wissen und ihren Aufgaben.
Wissen
verwaltete, gekapselte Daten
kenne Beziehung zu anderen Objekten
abgeleitetes Wissen (z.B. "Preis berechnen", dass sich aus Attributwerten und Formeln
zusammensetzt)
Aufgabe
etwas selbst tun
bei einem anderen Objekt eine Aktion auslösen
Kontrolle und Koordination von Aktionen in anderen Objekten
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 51 von 89
Software Methodik
8.3.2 Experte (expert)
Klasse, welche die notwendigen Informationen besitzt, um ihre Aufgabe zu erledigen (Funktionen
ausführen, Zustände berechnen). Dieses Muster ist in der objekt-orientierten Programmierung
zentral und repräsentiert unser tägliches Handeln. Wir erfinden ja nicht ständig das Rad neu,
sondern fragen Experten um Rat oder lassen Arbeiten von Profis ausführen. Wir geben nur den
Auftrag und delegieren somit die Problemlösung jemanden, der dies schon etliche Mal getan hat
und dafür das Wissen besitzt. In der realen Welt können Rechnungspositionen ihr Subtotal nicht
sagen – in der OO-Welt schon!
Beispiel
Wer hat das Wissen, um das Total des Einkaufs zu berechnen?
Einkauf
datum
zeit
drucke()
berechneTotal()
1
enthalt en in
1.. n
Position
menge
berechneSubtotal()
0..n
1
beschrieben durch
ProduktSpezifikation
bezeichnung
preis
produkteCode : ProduktCode
gibPreis()
Abbildung 26: Einkauf besitzt das Wissen, um das Total zu berechnen
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 52 von 89
Software Methodik
float berechneTotal() {
tot al = 0
[für jede Pos ition] {
tot al += pos.gibSubtotal()
}
ret urn total
}
1: berechneTotal()
2: * [für jede Position] pos = gibNächs te()
: Einkauf
: Kassiererin
: Position
3: gibSubtotal()
float gibSubtotal() {
return anzahl*pS.gibPreis()
}
: Position
4: gibPreis()
:
ProduktSpezifikation
Abbildung 27: "Animation" oder "Do it myself" Prinzip
Klasse
Einkauf
Position
PrduktSpezifikation
Verantwortlichkeit
kennt das Einkaufstotal
kennt das Subtotal einer Position
kennt den Preis des Produktes
Fazit
Kapselung der Daten und klare Abgrenzung der Verantwortlichkeiten führt zu robusteren
Programmen, die besser wartbar sind. Verhalten, das in einem engen Zusammenhang steht, ist in
einer Klasse gekapselt. Die Klassen sind dadurch automatisch lose gekoppelt (vgl. low coupling).
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 53 von 89
Software Methodik
8.3.3 Erzeuger (creator)
Die Klasse A ist dafür verantwortlich, eine Instanz einer Klasse B zu erzeugen, falls die Klasse A
Objekte der Klasse B
verwaltet (contains)
besitzt (owns)
eng damit zusammenarbeitet (uses)
beschreiben kann, indem sie bei der Erzeugung von A die Daten zur Initislisierung besitzt
(initializes).
Da in der objekt-orientierten Programmierung viele Objekte erzeugt und vernichtet werden, ist es
wichtig diese Aktionen konsequent zu platzieren, um erweiterbaren Code zu schreiben und keine
Speicherlecks zu produzieren.
Beispiel
Wer soll eine Einkaufsposition erzeugen?
Einkauf
datum
zeit
drucke()
berechneTotal()
erzeugePosition()
1
enthalt en in
1.. n
ProduktSpezifikation
Position
menge
berechneSubtotal()
0..n
1
beschrieben durch
bezeichnung
preis
produkteCode : ProduktCode
gibPreis()
Abbildung 28: Einkauf verwaltet Einkaufsposition und erzeugt diese deshalb.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 54 von 89
Software Methodik
2: erzeugePosition(produkt, anzahl)
1: fügeNeuePositionDazu(produkt, anzahl)
: Einkauf
: Kassiererin
3: create(produkt)
: Position
Abbildung 29: Einkauf kennt seine Objekte die er erzeugt und verwaltet.
Fazit
Die erzeugte Klasse ist der Erzeugerklasse bekannt und wird auch von ihr verwaltet. Somit hat der
Erzeuger(ebenfalls ein Experte) das Wissen darüber, was seine assoziierte Expertenklasse für eine
Aufgabe wahrnimmt und kann Verantwortung bezüglich ihrer Funktionalität delegieren. Dadurch
wird eine Klasse nur von derjenigen Klasse erzeugt, welche später auch eine Beziehung zu ihr hat.
Wird eine Beziehung mit dem Erzeugerobjekt aufgelöst, wird das assoziierte Objekt meist von ihm
vernichtet, wodurch Speicherlecks verhindert werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 55 von 89
Software Methodik
8.3.4 Kontroller (Controller)
Um die Ereignisse zu behandeln, welche in einem System ausgelöst werden, verwendet man
Kontroller. Zu diesem Zweck fragt man sich: Wer behandelt Systemevents?
Fassadenkontroller (facade controller): Mädchen für alles - repräsentiert das ganze System
oder eine ganze Organisation. Sinnvoll, wenn nur wenige Events behandelt werden müssen und
eine Trennung einen Overhead produzieren würde.
Rollenkontroller (role controller): Repräsentiert etwas in der realen Welt, welches bereits
existiert und in die Problemstellung involviert ist.
Use-Case Kontroller (use case controller): Repräsentiert einen künstlichen Handler aller UseCase Ereignisse eines Systems, z.B. EinkaufsHandler, der Ereignisse, welche im Zusammenhang
mit einem Einkauf stehen, bearbeitet.
Fenster, Applikationen, Applets und dergleichen sind keine Kontroller. Sie leiten vielmehr Events
an einen Kontroller weiter.
Beispiel
Abbildung 30: Wünschenswerte Kopplung der Präsentation an die Domänenschicht
Fazit
Mit dem Kontroller wird eine strikte Trennung von Anzeige und Modell angestrebt. Die
Präsentationsschicht kennt nicht direkt die Verkaufsposition, sondern den Kontroller Kasse, welcher
das Wissen über Einkäufe hat und damit eine Verkaufsposition erzeugen kann.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 56 von 89
Software Methodik
8.3.5 Hoher Zusammenhalt (High Cohesion)
Hoher Zusammenhalt ist dann der Fall, wenn eine Klasse eine angemessene Verantwortung in einer
funktionalen Umgebung hat und mit anderen verwandten Klassen zusammenarbeitet, um ihre
Aufgabe zu lösen. Sie ist auf ihren Aufgabenbereich spezialisiert und nicht für eine Sammlung von
andersartigen Problemstellungen zuständig. Dadurch hat diese Klasse relativ wenig eigene
Methoden, welche ihrerseits andere zur Erfüllung ihrer Aufgaben aufrufen.
Beispiel
2: b = erz euge()
1: bezahle()
: Kasse
: Kassiererin
: Bezahlung
3: fügeBezahlungDazu(b)
: Einkauf
Schlecht: Die Kasse muss Bezahlungen abwickeln können. Egal ob Bar, auf Rechnung, mit
Kredit-, Post- oder Cash-Karte.
5: bezahle()
4: bezahle()
: Kasse
: Kassiererin
: Einkauf
6: erzeuge()
: Bezahlung
Gut: Die Kasse delegiert die Bezahlung und entbindet sich der Aufgabe, kommende
Bezahlungsarten zu unterstützen.
Fazit
Hoher Zusammenhalt ist ähnlich unserem täglichen Leben. Falls eine Person zuviel Aufgaben auf
sich nimmt, die gar nicht mehr in ihrem Verantwortungsgebiet liegen und deshalb delegiert werden
sollten, ist sie nicht mehr effektiv. Teamwork ist hier angesagt!
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 57 von 89
Software Methodik
8.3.6 Geringe Kopplung (Low Coupling)
Kopplung ist ein Mass, wie stark zwei Klassen miteinander verbunden sind, sich gegenseitig
kennen oder voneinander abhängig sind. Sie stellt eine unidirektionale, hierarchische Beziehung
dar. Innerhalb einer Methode sollten andere Methoden nur von folgenden Objekten (X) aufgerufen
werden:
X hat ein Attribut(Klassen- oder Instanzvariable), welches auf eine Instanz oder auf Y selbst
zeigt.
X hat eine Methode, welche eine Instanz oder Y selbst referenziert. Typisch besitzt X ein
Parameter oder eine lokale Variable vom Typ Y.
X ist direkt oder indirekt eine Unterklasse von Y.
Y repräsentiert ein Interface, welches durch X implementiert wird.
X ist ein Element einer Sammlung von Objekten, welche Attribut des aufrufenden Objektes ist
Je weniger Parameter bei einem Methodenaufruf verwendet werden, desto geringere Kopplung
liegt vor!
Beispiel
5: bezahle()
4: bezahle()
: Kasse
: Einkauf
: Kassiererin
6: erzeuge()
: Bezahlung
Schlecht: Die Kasse kennt Bezahlung und ihre Methoden.
dieBezahlung = meineKasse.gibEinkauf().erzeugeBezahlung();
oder in zwei Schritten:
derEinkauf = meineKasse.gibEinkauf()
dieBezahlung = derEinkauf.erzeugeBezahlung()
Die Kasse hat durch die Methode
gibEinkauf()Zugriff auf den Einkauf .
Da der Einkauf die Bezahlung kennt,
kann dieser die Bezahlung der Kasse zur
Verfügung stellen.
Somit kann die Kasse direkt eine Bezahlung erzeugen und diese manipulieren. Die Kasse hat
jedoch gar keine direkte Beziehung zur Bezahlung. Wir haben in den bekannten GRASP-Pattern
schon gesehen, dass das so auch besser ist.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 58 von 89
Software Methodik
Besser: Die Kasse delegiert die Bezahlung. Somit muss sie nur die Klasse Einkauf kennen und
nicht auch die Bezahlung. Das Objekt Einkauf verwaltet somit die Bezahlung.
meineKasse.bezahle();
Kassiererin ruft auf
void bezahle() {
Kasse hat implementiert
Einkauf
verwaltet
erzeugte Bezahlung
die
meinEinkauf.erzeugeBezahlung();
}
void erzeugeBezahlung() {
meineBezahlung = new Bezahlung();
}
Fazit
Geringe Abhängigkeit bedeutet, hohe Wiederverwendbarkeit. Hohe Kopplung bringt Probleme,
da...
Änderungen in assoziierten Klassen Auswirkungen auf die eigene Klasse haben.
Isolation/Auslagerung von Funktionen schwierig ist
ungünstige Wiederverwendbarkeit
Zusammenhalt und Kopplung stehen invers miteinander in Beziehung. Steigt das eine, sinkt das
andere. Geringe Kopplung mit hohem Zusammenhalt ist gut!
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 59 von 89
Software Methodik
9 Design
Der Design ist der Zwischenschritt von der Analyse zur Implementierung. Während sich die
Analyse mit der fachlichen Seite des Problembereichs beschäftigt, befasst sich der Design
zusätzlich damit, das Realitätsmodell auf den Lösungsbereich abzubilden, damit es schliesslich in
eine Programmiersprache umgesetzt werden kann.
Während des objektorientierten Designs wird erstmals der Lösungsraum des Anwendungsproblems
betrachtet. Dabei überlegt man sich, wie die in der Analyse identifizierten Klassen und Strukturen
in einem objektorientierten Softwaresystem abzubilden sind. Zwangsläufig führen diese
Überlegungen zum Hinzufügen von Klassen, Attributen und Methoden, die für die Realisierung des
Problems gebraucht werden. Es gibt eine ganze Reihe typischer Klassen, die in Softwaresystemen
unerlässlich sind, im Anwendungsbereich aber nicht vorkommen: Darunter könnte man sich etwa
Container-Klassen vorstellen, die eine Ansammlung von Objekten des Anwendungsbereichs
enthalten, Klassen, welche für die Speicherung von Objekten verantwortlich sind oder mit der
Datenausgabe zu tun haben.
Im Design werden dem Analysemodell implementationsspezifische Erweiterungen angefügt. Dies
können einerseits logische Abstraktionen und Mechanismen sein, mit denen das Verhalten des
Analysemodells abgebildet wird, andererseits muss berücksichtigt werden, mit welchen
physikalischen Komponenten man die Anforderungen am leichtesten realisieren kann. Zur
Modellierung der physikalischen Aspekte gehört beispielsweise das Festlegen der Modularchitektur
oder bei einem Mehrprozesssystem die Zuweisung von Verarbeitungsteilen auf Prozessoren.
Zu den Designüberlegungen gehören beispielsweise auch die Wahl des Betriebsystems und der
Programmiersprache, sofern dies nicht von Anfang an feststeht. Auch die Entscheidung für eine
bestimmte Form der Datenspeicherung und für eine geeignete Benutzeroberfläche müssen
spätestens in der Designphase getroffen werden. Es ist schliesslich ein weitreichender
Designentscheidung, ob man Daten in einer relationalen Datenbank oder in einfachen ASCIIDateien ablegt; ebenso kann die Wahl der Benutzeroberfläche Auswirkungen auf die
Klassenstruktur des endgültigen Programms haben.
Es gibt eine ganze Reihe typischer "Designklassen" die in nahezu jedem Programm vorkommen.
Die Bildschirmausgabe z.B. funktioniert bei gleicher Oberfläche und Programmiersprache in jedem
Programm analog, unabhängig davon, ob man Informationen über den Kontostand eines
Bankkunden oder Verkaufszahlen von Produkten in einem MIS (Management Information System)
ausgibt. Daher ist hier die Wahrscheinlichkeit, Klassen wieder verwenden zu können besonders
gross.
Auf dem Markt gibt es inzwischen eine grosse Zahl von Klassenbibliotheken, die solche
Klassentypen enthalten. Vorhandene Entwürfe und Klassenbibliotheken können in dieser
Entwurfsphase stark in die Entwicklung einfliessen.
Die Grenzen zwischen Analyse und Design sind beim objektorientierten Ansatz recht
verschwommen. Das Identifizieren der wichtigen Klassen eines Anwendungsbereichs
beispielsweise könnte sowohl als Bestandteil der Analyse als auch des Designs betrachtet werden.
Trotzdem sind die Ziele von Analyse und Design völlig unterschiedlich. In der Analyse versucht
man, die reale Welt zu modellieren, indem man die Klassen und Objekte identifiziert, welche die
Begriffswelt des Anwendungsbereichs ausmachen. Während des Design "erfindet" man
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 60 von 89
Software Methodik
Abstraktionen und Mechanismen, mit denen die Anforderungen an die Funktionalität des
Programms befriedigt werden können.
Design kann - zumindest in den späten Phasen der Entwicklung - nicht
programmiersprachenunabhängig sein. Je früher die Konzepte der Programmiersprache mit
einfliessen, um so besser kann der Entwurf auf die Stärken und Schwächen der Sprache abgestimmt
werden. Legt man die Implementierungssprache nicht von vornherein fest, muss man eventuell
einige Überarbeitungen in Kauf nehmen. Beispielsweise müssen Vererbungsstrukturen korrigiert
werden, wenn der Entwurf mehrfache Vererbung enthält, die Sprache dies aber nicht zulässt
(vgl.Java).
Ach wenn ein Systemanalytiker oder Designer selbst kein einziges Statement kodiert, ist es sehr
wichtig, dass er die Zielsprache kennt:
..to design a piece of software succesfully you need a fairly detailed knowledge of the
chose implementation language - even if you never personally write a single line of that
software ... the good software designer builds on the strength of her implementation
langueage and - as far as possible - avoids using it in ways that cause problems for
implementers.
Stroustrup 1991
9.1 Von der Analyse zum Design
9.2 Abgrenzung gegenüber OOA
OOA definiert WAS ein System machen soll. OOD WIE das System dies tut.
OOA ist der Ausgangspunkt für OOD. OOD ist der Ausgangspunkt für OOP.
Nicht-funktionale Anforderungen spielen in OOD eine grosse Rolle:
• Performance
• Wiederverwendung von bestehenden Komponenten/Frameworks
• Flexibilität des Systems gegenüber Anforderungsänderungen
9.3 Iterative Softwareentwicklung
OOA, OOD und OOP sind Teil eines einzigen, zyklischen Prozesses.
Analyse, Prototyping, Risk Management
Design, Prototyping, Risk Management
Programming, Prototyping, Risk Management
Mit UML haben wir eine gemeinsame Sprache für OOA und OOD. RUP definiert den Prozess, wie
man von Use Cases über OOA nach OOD zur Implementierung und weiter zum Test gelangt.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 61 von 89
Software Methodik
9.4 Resultate des OOD
User Interface Design
• Entwurf des (G)UI‘s
• Gruppierung von Visualisierungsobjekten
Klassendiagramme
• statische Struktur eines Softwaresystems
• zeigen, welche Klassen es gibt, was für Services sie anbieten und wer mit ihnen
zusammenarbeitet.
Interaktionsdiagramme
• Sequenz- / Collaboration Diagramme
• visualisieren dynamische Abläufe im System
• zeigen, welche Methoden in welcher Reihenfolge aufgerufen werden, um eine Aufgabe zu
erfüllen.
9.5 OOD - Wie macht man das ?
OOD ist die Tätigkeit in einem Softwareprojekt, die am wenigsten automatisiert oder „nach
Lehrbuch“ gemacht werden kann.
„Gute“ Designs zu erreichen braucht Erfahrung.
„Gut“ kann in einem Projekt „flexibel“ bedeuten, in einem andern aber vielleicht „performant“.
Designs sind oft auch Geschmackssache. Man sollte sich bei Bewertung von Designs auf
möglichst sachliche Kritik ausrichten.
9.6 Komponentenmodell
Im Gegensatz zum Analysemodell berücksichtigt der objektorientierte Design (OOD) auch die
nichtfunktionalen Anforderungen. Die Einhaltung dieser globalen Anforderungen ist nur möglich,
wenn die Software-Architektur und der Design optimal aufeinander abgestimmt werden. So bedingt
beispielsweise die Anforderung nach Unterstützung von mehreren Tausend gleichzeitiger
Anwendern – nicht unüblich bei E-Commerce-Anwendungen - eine verteilte 2- oder 3-tierArchitektur, bei der die einzelnen Business-Klassen auf verschiedenen Rechnern implementiert
werden und über eine geeignete objektorientierte Middleware miteinander kommunizieren.
In solch komplexen Projekten, die oft auch grosse Projektorganisationen erfordern, wird
typischerweise für jedes Teilsystem ein eigenes Design-Modell erstellt. Dieses wird in der Folge
parallel zum Analyse-Modell gepflegt. In kleineren Projekten wird das Analyse-Modell oft in der
ersten Iteration in ein Design-Modell umgewandelt und nicht mehr weitergepflegt.
Neben den nichtfunktionalen Anforderungen berücksichtigt der Design auch die
Navigationsmöglichkeiten zwischen den Klassen, damit sie einander Meldungen zuschicken
können. Die Forderung nach zweckmässigen Navigationsmöglichkeiten führt dazu, dass wir im
Modell zusätzliche Verbindungen zwischen Klassen(Assoziationen) einführen oder zusätzliche
Operationen einfügen, die eine Referenz auf das gewünschte Objekt zurückgeben.
Um einen objektorientierten Design zu vereinfachen oder um zukünftige Erweiterungen zu
ermöglichen, bieten sich Design-Patterns an. Mit ihnen lassen sich die Teile eines Designs so
organisieren, dass eine Änderung in einem Teil des Systems nicht notwendigerweise Änderungen in
anderen Teilen des Systems bedingen.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 62 von 89
Software Methodik
9.7 Design in 4 Komponenten
Vorgehensmodell nach Coad-Yourdon
PDC: Problem Domain Component
Das unterliegende Datenmodell des Systems wie es zur Laufzeit existiert. Sollte nichts von der
Aussenwelt wissen (Model – View-Controller Prinzip).Ausgangspunkt ist immer das OOA
Modell ! Während des Designs sind u.a. folgende Veränderungen am OOA Modell typisch:
• Reuse von bestehenden Klassen und Bibliotheken (APIs) oder sogar ganzen Komponenten.
• Kapseln von konzeptuell zusammengehörenden Klassen mit einem neu einzuführendem
Objekt.
• Einführen von Objekten, die Performanceaspekte verbessern sollen.
• Einführen von Klassen, die die Persistenz der Domain Objekte unterstützen oder Kapseln.
• Einführen von low level Komponenten, um eine konzeptuelle Layerung zu etablieren.
HIC: Human Interaction Component
Definition des UI (Views, Useraktionen, Kommandos) und dessen Klassen. User Interfaces
sollten, wenn immer möglich, mit Prototypen (Papier oder elektronisch) getestet werden!
Vorgehen:
• Klassifiziere und gruppiere alle Benutzer des Systems (Rolle, Ausbildungsgrad,
Organisation)
• Beschreibe die Aufgaben dieser Benutzer, die Ereignisse, auf die sie reagieren müssen und
die Reihenfolge der Aktionen, die sie ausführen.
• Definiere Screens, Menupunkte und überprüfe die Vollständigkeit (Prototyp).
• Mache das Detaildesign für jeden Screen. Überprüfe wiederum die Vollständigkeit
(verfeinerter Prototyp).
• Entwerfe das User Interface Klassenmodell.
DMC: Data Management Component
Definiert die Persistenz von Objekten, z.B. speziell die Transformation von Objekten in ein
Relationales DB System
TMC: Task Management Component
Kann in Real-Time Applikationen sehr wichtig sein. Meistens jedoch übernimmt das
Betriebssystem oder die Laufzeitumgebung diese Aufgaben.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 63 von 89
Software Methodik
9.8 Die 6 Goldenen Regeln
9.8.1 Regel 1: Denke in Layers
9.8.1.1 Layermodell
User Interface
Layer
DlgKunde
DlgBestellung
Presentation
Layer
TRKunde
TRBestellung
Kunde
Bestellung
Artikel
DBKunde
DBBestellung
DBArtikel
Model
Layer
Persistency
Layer
Abbildung 31: Layerung einer Applikation
User Interface Layer
UI Klassen: Views, Controls, Menus, etc.
Presentation Layer
Schicht von Klassen, die das Datenmodell ans UI adaptiert. Ziel dabei ist, dass keine
Verunreinigung der Modellklassen mit UI spezifischen „Berechnungen“, Umformungen erfolgen.
Model Layer
Klassen der transienten Datenbasis. Das eigentliche Datenmodell. Der Teil mit der kleinsten
Aenderungswahrscheinlichkeit!
Persistency Layer
Schicht von Klassen, die die Persistenz der Modell Objekte managen. Ziel ist die Separierung der
Persistenzmechanismen vom Modell, was Flexibilität bezüglich der Datenhaltung bringt.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 64 von 89
Software Methodik
Abbildung 32: Schichtung in einem typischen objekt-orientierten Informationssystem
9.8.1.2 Layering - wozu?
1. Sinnvolle Arbeitsteilung
und Übersicht.
2. Langfristige Flexibilität in
der Systementwicklung.
3. Höheren Wiederverwendungsgrad erzielen.
9.8.1.3 Anwendungsarchitektur
Innerhalb des Model Layers werden Komponenten definiert, die Klassen umfassen, welche einen
abgeschlossenen Service(Funktionsumfang) zur Verfügung stellen, z.B. Partnerdaten verwalten.
Neuen Partner
anlegen
Kaution
verrechnen
Partner
Reservierung
Kfz reservieren
Partner
auswählen
Vertrag
Kfz abrechnen
Abrechnung
Abbildung 33: Komponenten innerhalb des Model Layers
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 65 von 89
Software Methodik
9.8.2 Regel 2: Beachte die Änderungswahrscheinlichkeit
In jedem System gibt es Klassen, die häufiger geändert werden müssen als andere.
Versuche jene mit höherer Änderungswahr-scheinlichkeit von denen mit niedrigerer zu trennen.
Ziel ist es, dort am Flexibelsten zu sein, wo die Wahrscheinlichkeit für Änderungen am grössten
ist.
„Baue Dir Deine eigene innere Welt.“
9.8.3 Regel 3: „Vorsicht ist die Mutter des flexiblen Designs“
Verlasse Dich nicht darauf, dass die Anforderungen oder Schnittstellen auch bei Auslieferung
oder im Release X noch die gleichen sein werden.
Wie könnte die zukünftige Entwicklung der Anforderungen oder Schnittstellen sein?
Wo ist Dein Design auf unerwartete Änderungen anfällig und wodurch erreicht man mehr
Flexibilität?
Was muss ändern, damit Du wirklich alles wegwerfen musst(Worst-Case Szenario)?
Könnte man durch eine kleine Änderung dieses Szenario abwenden?
9.8.4 Regel 4: Gekapselte Datenmanipulation
Vermeide Daten zentrierte Designs - keine Datencontainer.
• Es sollte nur sehr wenige Klassen im System geben, die ausser ihren Accessors kaum andere
Methoden zur Verfügung stellen.
• Diese Klassen finden sich meistens im Datenmodell Layer und sollten eine möglichst
niedrige Änderungswahrscheinlichkeit haben.
Die Gesamtzahl der Attribute in den Klassen des Systems sollte so klein wie möglich und so
gross wie nötig gehalten werden.
Merke: Ein Attribut verkörpert „einen Zustand“.
• Zustände bergen in sich die Gefahr von Inkonsistenz.
• Ausserdem entzieht es dem System Dynamik.
9.8.5 Regel 5: Beachte die Metapher „Arbeitsteilung“
Ein guter flexibler OO Design funktioniert wie eine Firma mit einem hohen Grad an
Arbeitsteilung.
• Die Aufgaben des Softwaresystems werden mit „Teams“ von Klassen gelöst.
• Jede beteiligte Klasse hat eine klar definierte und abgegrenzte Rolle.
• Jede Klasse befindet sich auf einem konsistenten Abstraktionsniveau (vgl. wiederum
Layerung)
9.8.6 Regel 6: Benutze etablierte Muster
Viele Problemstellungen des OOD kommen in vielen Projekten immer und immer wieder vor.
Mit zunehmender Erfahrung erkennt und versteht man Architektur- und Designmuster, und hat
somit die Möglichkeit erprobte Lösungen in seinen eigenen Projekten einzusetzen, was Risiken
reduziert:
• Architektur-Patterns z.B. Layersystem
• Design-Patterns: wirklich gute OO Designs enthalten „automatisch“ Design Patterns, auch
wenn der Designer sich dessen nicht bewusst ist
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 66 von 89
Software Methodik
9.9 UML-Diagramme
9.9.1 Klassendiagramm
Das Klassendiagramm beschreibt die statische, logische Struktur der Objekte in einem System,
sowie ihre Beziehungen untereinander und stellt die Klassen mit Attributen und Operationen, die
Vererbungen, sowie die Assoziationen und Kardinalitäten zwischen Klassen dar. Ausserdem
können Pakete und ihre Abhängigkeiten im Klassendiagramm modelliert werden.
9.9.1.1 Attribute spezifizieren
“Modellayer"
Kunde
KundenNr
SpezialVereinbarungen
Branche
Kundengruppe
Bonitaet
----
Die in der Analyse defnierten Attribute werden im Design
durch ihre Datentypen ergänzt. Vielfach sind die Daten in
primitiven Datentypen abgelegt, wie String, Integer, Float,
Boolean oder einem Array davon.
Beziehungen werden ebenfalls in Attributen abgebildet und
müssen von derjenigen Klasse verwaltet werden, welche auf die
Services der anderen Klasse zugreift. Man "bezieht" sich dann
meist auf komplexe, selbstdefinierte Klassen, welche auch die
passenden Methoden zur Objektmanipulation anbieten.
Im Design können durchaus noch neue Attribute hinkommen.
Abbildung 34: Attribute spezifizieren
9.9.1.2 Operationen spezifizieren
Die aus den Anforderungen und Use-Cases extrahierten
Methoden werden im Design durch neue Methoden ergänzt,
welche die Funktionalität erweitern und im Hinblick auf
Wiederverwendbarkeit allgemeine Algorithmen in separaten
---Methoden auslagern. Dadurch ist gewährleistet, dass die
fuegeVertragAn (Vertrag)
Granularität der einzelnen Services so fein ist, dass sich aus
fuegeAnsprechPartnerAn (ap)
ihnen neue, leicht variierte "zusammenbauen" lassen.
entferneAnsprechPartner (ap)
hatAnsprechPartner(ap):Boolean
Wichtig ist auch, dass die Sichtbarkeit definiert wird.
gibStandardAnschrift(Anschrift)
Attributzugriffe sollten ausserhalb des Objektes möglich
gibMengeAnschriften():Set
sein(public), interne Methoden zur Berechnung nicht(private).
Dazwischen gibt es noch Methoden, welche innerhalb der
Abbildung 35: Operationen spezifizieren
Vererbungshierarchie sichtbar sind(protected).
“Modellayer"
Kunde
In Klassendiagrammen sind folgende Elemente zu finden:
Klassen mit Attributen und Operationen
Generische Klassen (Templates)
Zusammengesetzte Klassen (Composites)
Utility-Klassen (Sammlungen von Daten oder Funktionen, vgl. Container-Klassen)
Objekte
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 67 von 89
Software Methodik
Das Objektdiagramm ist eine Spezialform des Klassendiagrammes und repräsentiert ein reales
bzw. prototypisches System, welches Objekte der Realen Welt mit eindeutiger Identität beinhaltet.
Objekte(Instanzen, Ausprägungen, Exemplare einer Klasse) haben einen individuellen Zustand und
unterscheiden sich dadurch voneinander. Klassendiagramme sind der zentrale Bestandteil der UML
und auch zahlreicher objektorientierter Methoden. Wie die Klassen ermittelt werden, darüber gibt
die UML keine Auskunft. Hierfür gibt es andere Techniken, z. B. CRC-Karten oder die SubstantivTechnik. Die UML beschreibt lediglich die Notation und die Semantik:
Objekte: Konzept, Abstraktion oder Gegenstand mit klarer Abgrenzung und präziser Bedeutung,
z. B. der "rote Apfel".
Klassen: Gruppen von Objekten mit ähnliche Eigenschaften, z. B. "Äpfel".
Klasse
Objekt
Fritz: Person
Person
name = Fri tz
geburtsTag = 0 1.02.2001
name : Stri ng
geburtsTag : Datu m
gibNam e() : String
gibAl ter() : In teger
Fritz : Person
Abbildung 36: Klasse und Objekt
Die strenge visuelle Unterscheidung zwischen Objekten und Klassen entfällt in der UML. Objekte
werden von den Klassen dadurch unterschieden, daß ihre Bezeichnung unterstrichen ist, sonst sind
die Symbole gleich. Auch können Klassen und Objekte zusammen im Klassendiagramm auftreten.
9.9.2 Interaktionsdiagramm
Interaktionsdiagramm ist der Überbegriff von Kollaborations- und Sequenzdiagramm und
beschreibt das Inter-Objektverhalten.
9.9.2.1 Kollaborationsdiagramm
Zur Beschreibung von dynamischen Beziehungen, Interaktionen und Verflechtungen zwischen
Objekten werden Kollaborationsdiagramme verwendet. Sie bestehen aus Objekten und
Verbindungen zueinander. Kollaborationsdiagramme stellen den Systemzustand vor und nach
einer Operation dar, wobei die Unterschiede zwischen den Systemzuständen mittels Annotationen
im Diagramm kennlich gemacht werden. Schwerpunkt liegt auf der strukturellen Organisation der
Objekte. Die Reihenfolge der Nachrichten muss durch explizite Nummerierung ausgedrückt
werden.
Verbindungen können einerseits permanent sein (d.h. Assoziationen aus den Klassendiagrammen),
andererseits sind auch temporäre Verbindungen vorgesehen. Mögliche Verbindungen sind:
Assoziation
Attribut
globale Variable
lokale Variable
Funktionsparameter
Selbstreferenz
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 68 von 89
Software Methodik
Verbindungen können mit Annotationen versehen werden:
Sequenznummern zur Angabe von Operationen, die vorher stattgefunden haben müssen
Aufrufsequenznummern geben an, auf welcher Ebene der Aufrufhierarchie ein Funktionsaufruf
erfolgt.
Rückgabewerte
Name der Nachricht oder der aufgerufenen Funktion
Parameter
Bedingungen
Szenario Versicherung abschließen:
Ein Fahrzeughalter beantragt eine KFZ Versicherung. Der Antrag wird vom zuständigen
Sachbearbeiter geprüft. Nach erfolgreicher Prüfung wird ein Vertrag abgeschlossen.
Abbildung 37: Kollaborationsdiagramm Versicherung
9.9.2.2 Sequenzdiagramm
Mit Sequenzdiagrammen werden Szenarien beschrieben, bei denen mehrere Objekte zur Erfüllung
einer konkreten Aufgabe miteinander kommunizieren(interagieren). Ablaufvarianten werden so
durch mehrere einander ergänzende Sequenzdiagramme modelliert. Dadurch werden zusätzliche
Klassen und Methoden identifiziert. Der Schwerpunkt liegt hier auf der Betrachtung zeitlicher
Aspekte. Dementsprechend werden folgende Elemente in Sequenzdiagrammen verwendet:
beteiligte Objekte (von der Erzeugung bis zur Zerstörung)
eine Zeitachse (die für jedes Objekt eingetragen wird)
Funktionsaufrufe oder Nachrichten (können mit Bedingungen versehen werden)
Ausdrücke mit Zeitmarkierungen
Ein Sequenzdiagramm besitzt zwei Diemnsionen:
vertikal: repräsentiert die Zeit
horizontal: Objektanordnung
Jedes Objekt wird durch die Objektlinie (gestrichelte Linie) dargestellt. Sie stellt die Existenz eines
Objektes von der Erzeugung bis zur Vernichtung dar. Es können Botschaften an anonyme Objekte
(allgemeine, Stellvertreter für beliebige Objekte der angegebenen Klasse) z.B :Person oder
spezielle Ojekte z.B Fritz:Person gesandt werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 69 von 89
Software Methodik
Szenario Versicherung abschließen:
Ein Fahrzeughalter beantragt eine KFZ Versicherung. Der Antrag wird vom zuständigen
Sachbearbeiter geprüft. Nach erfolgreicher Prüfung wird ein Vertrag abgeschlossen.
Szenario Versicherung auflösen:
Der Versicherte kündigt die Versicherung. Der Sachbearbeiter löst den Vertrag auf.
Abbildung 38: Sequenzdiagramm Versicherung
Achtung:
Das Sequenzdiagramm des obigen Beispieles erweckt den Eindruck, dass man nichtsystemrelevante Arbeitsabläufe, welche sich zwischen Personen oder Abteilungen abspielen und
nicht durch das System erfolgen, ebenfalls mit einem Sequenzdiagramm modellieren sollte. Die
Systemgrenze darf man dabei jedoch nicht aus den Augen verlieren.
Was zwischen dem Fahrzeughalter und dem Sachbearbeiter an Dokumenten und Informationen
ausgetauscht wird, kann zur Illustration aufgezeichnet werden, gehört jedoch nicht zum
Funktionsumfang unseres Sysetmes. Die Systemoperation Vertrag erstellen, welche der
Sachbearbeiter im System aufruft, interessiert uns bei der Modellierung nur, sowie die weiteren
Funktionen, welche diese Systemoperation auslöst.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 70 von 89
Software Methodik
9.9.2.3 Beispiele zu Klassen-, Kollaborations- und Sequenzdiagramm
KaffemaschinenUI
espressoTasteGedrückt()
Kaffeemaschine
machEspresso()
+mahlwerk
1
+pumpe
1
Wasserpumpe
Kaffemühle
mahleKaffee(menge)
pumpeWasser(menge, druck)
Abbildung 39: Klassendigramm der Kaffeemaschine
1: drücke E spresso tas te
Benutzer
Kaffemasch
inenUI
2: machEspresso()
Kaffeemas
chine
4: pumpeWasser(...)
3: mahleKaffee(...)
Kaffeem
ühle
Wasserp
umpe
Abbildung 40: Kollaborationsdigramm der Kaffeemaschine
Benutzer
Kaffemaschine
nUI
Kaffeemaschin
e
Kaffeemühle
Wasserpumpe
drücke Espresso taste
machEspresso()
mahleKaffee(...)
pumpeWasser(...)
Abbildung 41: Sequenzdigramm der Kaffeemaschine
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 71 von 89
Software Methodik
9.9.3 Zustandsdiagramm
Die Theorie dazu ist im Buch [Oesterreich, Bernd]auf den Seiten 192, 310-317 beschrieben.
Am Beispiel des Zustandsdiagramms eines Schachspiels, welches die generalisierten Zustände
darstellt, wird deutlich, das es auch sehr komplexe Programme oder Klassen geben kann, welche
nur über wenige Zustände verfügen, und daher ein recht einfaches Zustandsdiagramm aufweisen.
Start
H
Weiss am Zug
schachmatt
H
Schwarz
gewinnt
H
remis
patt
Weiss
zieht
Schwarz
zieht
patt
Schwarz am Zug
schachmatt
H
Weiss
gewinnt
Abbildung 42: Zustandsdiagramm des Schachspieles
Wenn man davon ausgeht das die Klassen Zündung, Getriebe, Bremse und Gaspedal Teile des
Systems Autos sind, wird klar das die Zustandsdiagramme dieser Klasse parallel ablaufen.
Zündung
H
Schlüssel umdrehen
(Getriebe in Leerlauf)
Aus
Schlüssel loslassen
Startend
An
Schlüssel zurückdrehen
Bremse
H
Bremse treten
Aus
An
Bremse loslassen
Gaspedal
H
Gaspedal treten
Aus
An
Gaspedal loslassen
Abbildung 43: Zustandsdiagramme einzelner Komponenten eines Autos
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 72 von 89
Software Methodik
In diesem Zustandsdiagramm haben wir einen übergeordneten Zustand „Vorwärts“, welcher durch
die Unterzustände genauer beschrieben werden kann.
Getriebe
Rückwärtsgang einlegen
H
Leerlauf
Rückwärts
Leerlauf einlegen
Vorwärtsgang
einlegen
Leerlauf
einlegen
hochschalten
H
Erster
hochschalten
Zweiter
runterschalten
Dritter
runterschalten
Abbildung 44: Zustandsdiagramm des Getriebes mit Unterzustand
9.9.4 Aktivitätendiagramm
Die Theorie dazu ist im Buch [Oesterreich, Bernd]auf den Seiten 191, 295-300 beschrieben.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 73 von 89
Software Methodik
9.10 Design Patterns
Design Patterns, beschreiben einfach und zugleich elegant Möglichkeiten bei verschiedenen
Problemen des objektorientierten Softwaredesigns. Dabei haben sich diese Design Patterns über
längere Zeit entwickelt und bestätigt. Einige Beispiele sind im Buch [Bernd Oesterreich] Seite 63-65
kurz erläutert.
Diese Entwurfs-Muster, um den deutschen Begriff zu benutzen, benötigen für ihre Implementierung
keine spezielle Programmiersprache. Hierfür reicht eine einfache objektorientierte Sprache, wobei
viele Muster auch ohne den objektorientierten Aspekt einer Programmiersprache umgesetzt werden
können. Die Realisation eines Anwendungsproblems mit einem Design Pattern kann allerdings
etwas mehr Aufwand als andere Lösungen erfordern - zahlt sich aber aus. Man sollte jedoch eine
Softwarearchitektur nicht zu sehr damit überladen.
Eine gut entworfene Softwarearchitektur beinhaltet Design Patterns, wobei es sich durch eine
Benutzung der richtigen Design Patterns an der richtigen Stelle, einer einfachen Benutzung, guter
Überschaubarkeit und somit natürlich der Möglichkeit der Wiederbenutzung von Designtypen
auszeichnet. Empfehlenswert ist das Buch Design-Pattern der Gang-of-Four(Gamma, Helm,
Johnson und Vlissides). Im folgend werden einige Design Pattern aufgegriffen:
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 74 von 89
Software Methodik
9.10.1 Singleton
Sichere zu, daß eine Klasse nur eine Instanz hat und stelle einen globalen Zugriffspunkt für diese
Instanz zur Verfügung.
9.10.2 Abstract Factory
Stelle ein Interface zur Verfügung um eine Familie von miteinander in Beziehung stehenden
Objekten zu erzeugen ohne daß dabei die konkreten Implementierungsklassen angegeben werden
müssen.
9.10.3 Facade
Stelle ein einheitliches Interface für eine Menge von Interfaces eines Subsystems zur Verfügung.
Dabei definiert das Facaden interface Higher-Level-Interfaces, die die Benutzung der Subsysteme
erleichtern sollen.
9.10.4 Delegation
Bei Delegation sind zwei Objekte bei der Bearbeitung einer Anforderung beteiligt. Dabei empfängt
das eine Objekt die Anforderung und leitet sie weiter zum anderen Objekt, wo die Anforderung
bearbeitet wird. Hierbei kann das delegierende erste Objekt die Bearbeitung um zusätzliche
Aktionen erweitern. Diese Vorgehensweise ist analog der Nutzung der Vererbung. Um eine
Vererbung zu umgehen, verwaltet man im delegierenden Objekt eine Instanz jenes Objektes mit der
zu benutzenden Funktionalität. Während einer Delegation tätigt man dann die entsprechenden
Aufrufe an die fremde Instanz. Der Hauptvorteil der Delegation ist die einfache Komposition und
Änderung von Verhaltensweisen zur Laufzeit. Weiterhin kann man so möglichen Restriktionen
bezüglich Vererbung umgehen.
9.10.5 Template Method
Definiere ein Skeleton eines Algorithmus in einer Operation, wobei bestimmte Teile des
Algorithmus erst von Subklassen implementiert werden. Template Methoden lassen Subklassen
bestimmte Schritte des Algorithmus ändern ohne dabei die Gesamtstruktur des Algorithmus zu
ändern. Angewendet sollte dieses Pattern werden, um die invarianten Teile eines Algorithmus
genau einmal zu schreiben und Subklassen den restlichen Teil implementieren zu lassen, der
variieren kann. Ebenso sollte man es benutzen, wenn gleiches Verhalten von Klassen in einer
Klasse realisiert ist, um einem Mehrfachvorkommen bestimmter Umsetzungen vorzubeugen.
Grundsätzlich ist aber zu sagen, daß solche Methoden so fundamental sind, daß man ihre Benutzung
sehr häufig sehen kann.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 75 von 89
Software Methodik
10 Testen
Das Testen wird oft vernachlässigt. Besonders bei Informatikprojekten, welche nicht zeitgerecht
abgeschlossen werden können, ist die Gefahr gross, dass man das Testen aus Zeitgründen
vernachlässigt. Das Testen trägt aber wesentlich zur Qualitätssicherung eines Produktes bei. Die
wird auch zunehmend erkannt. Am Besten lässt sich die Problematik anhand eines Beispieles
erklären.
10.1 Einführendes Beispiel
Erstelle ein Programm in Pseudocode, welches zwei Zahlen dividiert. Zuerst soll der Zähler (eine
reelle Zahl) eingelesen werden, dann soll der Nenner (eine reelle Zahl) eingelesen werden. Die
Eingaben sind zu überprüfen, und falls sie nicht korrekt sind, ist eine Fehlermeldung, andernfalls
das Resultat auszugeben werden. Dieses Programm soll mit Testeingaben vollständig ausgetestet
werden können. Welche Testeingaben müssen vorgesehen werden?
10.2 Debuggen ist nicht Testen!
Viele Entwickler kennen den Unterschied zwischen Debugging und Testen nicht und setzen es
gleich.
Debugging
Debugging ist ein kreativer Prozess. Man
probiert Fehler zu beheben.
Testen
Beim Testen werden Fehler gesucht. Es ist ein
destruktiver Prozess.
Debugging kann je nach Fehlerursache relativ Das Testen erfolgt nach einem Plan. Der
lange dauern. Die Fehlerbehebung ist zeitlich
Zeitaufwand ist bestimmt.
nicht bestimmt.
Das Debugging wird durch den Entwickler
durchgeführt.
Das Testen sollte durch eine aussenstehende
Person erfolgen.
Debugging kommt aus dem Englischen und stammt vom Wort “bug” ab was auf Deutsch Fehler
Bedeutet. Infolge dessen bedeutet Debugging Fehler entfernen. Beim Debugging wird also probiert,
bekannte Software-Fehler zu beheben. Ist ein Fehler behoben, bedeutet das nicht, dass damit alles
richtig funktioniert.
Die Aufgabe des Testen ist, das korrekte Verhalten eines Programms zu überprüfen.
Für die Planung der Tests ist die Festlegung eines Testabbruchkriteriums nötig. Die folgenden
Festlegungen kommen in Frage:
Der Test wird abgebrochen
wenn er x Stunden (Tage, Wochen) gedauert hat
wenn er y % der Entwicklungszeit beansprucht hat
wenn z Stunden (Tage, Wochen) lang kein Fehler mehr entdeckt wurde
wenn die Ausführung aller Testfälle die spezifizierten Ergebnisse liefern
wenn die durchschnittlichen Kosten pro entdeckten Fehler x Fr. übersteigen
wenn n Fehler gefunden sind
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 76 von 89
Software Methodik
Planung
Auswahl der Testfälle
Testvorschriften
Review der Testvorschriften
Kriterium für Testabbruch
Nachweis mit Testbericht
Wiederholung der Tests
(Regressionstests)
informelle Tests
ja?
Zufall
nein
keines
keines
nein
unmöglich
formelle Tests
Ja
Methode
ja
ja
ja
ja
möglich
Der einzige Zweck von Tests ist es Fehler zu entdecken.
Im Rahmen von Tests sollten keine Fehler behoben werden.
Eine Testaktivität beinhaltet:
Testvorbereitung
Ausführen des Programme
Auswerten der Ergebnisse (inkl. Protokoll)
Führen Sie wenn möglich nur formelle Tests durch. Vorteile:
Test ist reproduzierbar
Beweis für die Durchführung der Test ist vorhanden
wegen der Vorbereitung werden Tests besser und die Resultate sind keinem Zufall überlassen
10.3 Testarten
Einzeltest (Modul)
Integrationstest (Teilsystem)
Systemtest (Software-System)
Werkabnahme (Anlage)
Abnahme (Installierte Anlage)
Unter Testarten versteht man, welche Test bei einem Produkt durchgeführt werden:
Einzeltests oder Modultests werden in der Regel durch den Entwickler (besser den Integrator)
durchgeführt. Sie dienen der Überprüfung der Funktion von einzelnen Softwareobjekten und
Modulen.
Integrationstests werden durch den Integrator (oft auch Konfigurationsmanager) durchgeführt und
stehen unter Aufsicht der QS-Stelle. Diese Tests prüfen beim Integrieren von Softwarekomponenten
(Teilsystemen), ob das Zusammenspiel der einzelnen Teile stimmt.
Systemtest werden durch den Integrator (oft auch Konfigurations-manager) durchgeführt und
stehen unter Aufsicht der QS-Stelle. Diese Tests prüfen, ob das System den Anforderung der
Spezifikation entspricht.
Abnahmetests werden durch den Projektleiter und einen Bevollmächtigten des Kunden
durchgeführt. Diese Tests prüfen, ob die Anforderung des Kunden erfüllt werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 77 von 89
Software Methodik
10.4 Testverfahren
Review
t
Analyse
Spezifikation
Entwurf
Detailentwurf
Kodierung
Betrieb
Installation
Test
Integration
Modultest
Mit Review werden sowohl Schwachstellen und Mängel aufgezeigt, als auch positive Qualitäten
bestätigt. Reviews werden vor allen zum Validieren von Dokumenten
Benutzeranleitungen
Pflichtenhefte
...
und Modellen (Systemmodel, Klassenmodel, ..) auf Vollständigkeit und Fehler eingesetzt.
Mit Reviews will man möglichst frühzeitig Fehler entdecken. Denn:
Fehlerkosten steigen exponentiell mit der Verweilzeit eines Fehlers im System
Fehler können nur auf der Abstraktionsebene entdeckt werden, auf der sie begangen wurden
Reviews haben noch ein paar positive Nebeneffekte:
Bessere Streuung der Produktkenntnisse innerhalb des Projektteams
Ausbildung neuer Mitarbeiter
“Zwanglose” Vereinheitlichung der Qualität
Blackbox-Test
Das Programm wird als Blackbox betrachtet. Nur der Input und der Output des Programms wird für
den Test einbezogen. Es ist die Kunst des Testers, die richtigen Eingaben zu definieren, um
möglichst viele Fehler zu entdecken. Dieses Testverfahren wird oft für Abnahme- und Systemtests
verwendet. Die Güte dieses Testverfahrens hängt stark von der Beschaffenheit der Inputdaten
(Testdaten) ab.
Whitebox-Test
Beim Whitebox-Test wird die Programmstruktur mit einbezogen. Man kann z.B. verlangen, dass
jeder Kontrollpfad beim Testen durchlaufen wird. Diese Testverfahren wird oft bei Modul- und
Integrationstest verwendet.
Von der strukturierten Programmierung weiss man, dass jedes Programm mit den drei
grundlegenden Ablaufstrukturen aufgebaut werden kann. Ein Programm kann somit als Folge von
Kontrollbefehlen betrachtet werden. Betrachtet man nur die Kontrollbefehle, so entsteht aus dem
Programm ein Graph mit Konten und Kanten.
Misst man beim Testlauf, welche Pfade im Programm durchlaufen werden, so kann die Qualität des
Testes abgeschätzt werden. Man erreicht damit auch, dass die Testentwickler sich überlegen
müssen, wie getestet werden muss, um alle Pfade beim Test durchzulaufen. Die Entwickler werden
damit gezwungen, den Code zu lesen und entdecken dabei Fehler.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 78 von 89
Software Methodik
Beim Abdecken der Pfade sollte nicht nur darauf geachtet werden, dass alle Pfade, sondern auch
alle Kombinationen davon durchlaufen werden. Möchte man also alle möglichen Pfade des
vorherigen Beispiels testen, so ist der Programmcode von vorher mit vier Durchläufen zu testen.
Übung: Stelle alle möglichen Pfad-Kombinationen dar
dynamischer Test
Das Programm wird auf dem Rechner ausgeführt.
statischer Test
Das Programm wird mental durch den Menschen ausgeführt. Dieser Test wird auch Pulttest oder
Tischtest bezeichnet.
10.5 Zusammenfassung
Das Testen ist ein Ablauf, bei welchem man Fehler entdecken will.
Das frühzeitige Entwickeln von Testfällen kann sogar Fehler verhindern. Weil man auf
Fehlerquellen achtet, wird sorgfältiger programmiert. Es entstehen weniger Fehler.
Nur genaue Spezifikationen können getestet werden. Damit zwingt man genau Anforderungen
zu formulieren.
Der Test sollte wiederholbar sein.
Das Testen erhöht nicht die Qualität eines Produktes, sondern kann nur das Fehlverhalten
entdecken.
Testen ist eine Kunst.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 79 von 89
Software Methodik
11 Implementierung
11.1 Java
“ Hello World!” ist wohl das Beispiel, womit man beginnt, wenn man sich in die Eigenheiten einer
Programmiersprache einarbeitet. Dabei ist man schon sehr nur diese zwei Wörter mit der persönlich
noch unbekannten Sprache auf dem Bildschirm ausgeben zu können. Ist die Programmiersprache
auf dem jeweiligen Computer installiert, wird man sehr schnell über diese minimale Anforderung
hinauswachsen. Grund dafür ist eine hohe Verständlichkeit der Grundprinzipien dieser
Programmiersprache. Im Gegensatz zur Anwendung von Sprachen wie C oder C++ hat man
erheblich weniger Probleme mit Laufzeitfehlern. So fällt die Unterscheidung zwischen Adresse und
Inhalt der Adresse während der Arbeit mit Java weg. Genauso gut kann man sich ein explizites
Anfordern bzw. die Freigabe von Speicherplatz sparen. Dafür reicht für die Instantiierung eines
Objektes ein einfaches new auf den entsprechenden Objekttyp. Wird dieses Objekt dann nicht mehr
benutzt (nicht mehr referenziert) sammelt ein Garbage-Collector dieses Objekt ein und entscheidet
über die Freigabe des von diesem Objekt benutzten Speicherplatzes.
Verfolgt man die Presse könnte man den Eindruck bekommen, daß Java die Welt retten und alle
Übel beseitigen wird. Davon sollte man sich natürlich nicht blenden lassen. Wie immer ist eine
kritische Herangehensweise gefragt. Schließlich wird man zu dem Ergebnis kommen, daß man mit
Java wirklich ein Werkzeug in der Hand hat, daß einem viele Türen öffnet.
11.1.1 Umgebung
Java wurde unter Vorlage von C++ als objektorientierte Programmiersprache von Sun
Microsystems entwickelt. Dabei war das Hauptziel, eine einfache Sprache zu entwickeln, die auf
unterschiedlichen Plattformen und somit auch Operating-Systems nutzbar ist. Dabei sollten die
Programme sowohl auf der Ebene des Sourcecodes als auch und insbesondere der Ebene des
binären Programmcodes portable sein. So ist man bei der Entwicklung einer Java-Application und
der letztlichen Benutzung nicht auf ein bestimmtes Betriebssystem angewiesen. Durch den
Interpreteransatz und des dafür genutzten plattformunabhängigen Bytecodes erspart man sich
notwendige Änderungen bei Benutzung auf unterschiedlichen Plattformen. Dabei benötigt man für
die jeweilige Plattform nur eine Java Virtual Machine, kurz JVM, welche die Ausführung der JavaApplication überwacht und den plattformunabhängigen Bytecode mit dem JVM-Interpreter in
plattformabhängigen Assemblercode übersetzt. Jede JVM besitzt eine Menge an Kernklassen, die
die Grundstruktur für jede Java-Entwicklung bereitstellen.
Java unterstützt Packages, die als Container dienen und logisch zusammengehörende Klassen
gruppieren. Man hat die Möglichkeit den Zugriff auf bestimmte Klassen, Methoden oder
Klassenmember gezielt zu setzen. So können beispielsweise bestimmte Klassen nur im eigenen
Package sichbar sein oder nur von erbenden Klassen.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 80 von 89
Software Methodik
11.1.2 RMI
Mit Java-RMI hat man die Möglichkeit verteilte Anwendungen zu schreiben, die über sogenannte
Remote-Objects miteinander kommunizieren. Hierbei können die beteiligten Anwendungen auf
verschiedenen JVMs laufen, wobei die Remote-Objects in erster Linie normale Java-Objekte sind.
Zusätzlich müssen diese noch ein Remote-Interface implementieren, welches die
Zugriffsmöglichkeiten auf das Objekt von einem anderen Objekt aus genauer spezifiziert. Ebenso
muß das Remote-Object der RMI-Ebene der lokalen JVM durch einen Export dieser Referenz
bekannt gegeben werden. Das kann durch Erweiterung des Remote-Objects vom fertig
implementierten Typ UnicastRemoteObject bzw. Nutzung dort vorhandener statischer Methoden
geschehen. Objekte rufen Remote-Object über die Remote-Reference auf.
Weiter bietet Java-RMI eine Vielzahl von Hilfsmitteln bei der Arbeit mit verteilten Objekten an.
11.1.3 Objektserialisierung
Bei Java wurden die normalen Ein- und Ausgabestreams erweitert, so daß man auch Objekte in
einen Stream hineinpacken und an anderer Stelle herauslesen kann. Man spricht auch von der
Objektserialisierung. Damit ist die Möglichkeit gegeben Objekte persistent zu machen, sie in eine
Datei auszulagern um sie bei Bedarf wieder einzulesen. Ebenso kann man damit Objekte zwischen
verschiedenen JVMs beliebig austauschen. Bei Java-RMI wird diese Methode benutzt, um die
Parameter eines RPCs zu übertragen. Dabei muß man den Inhalt eines Objektes in die Struktur des
Objekttyps (das sind die verfügbaren Methoden und Attribute), sowie den aktuellen Zustand des
Objektes unterteilen. Es ist nicht notwendig, die Struktur des Objektes in den Stream zu packen, da
sich diese normalerweise nicht ändert. Es wird somit nur der aktuelle Zustand des Objektes
serialisiert.
Bei der Deserialization benötigt man neben den serialisierten Daten die Definition des Objekttyps,
welche mit dem Classloader der jeweiligen JVM gefunden werden. Damit kann das Objekt
rekonstruiert werden. Dabei gibt es eine write-Methode, um ein Objekt zu serialisieren und eine
read-Methode, um es zu deserialisieren. Diese Methoden werden von der JVM bereitgestellt; man
hat aber auch die Möglichkeit diese Methode in der konkreten Klassendefinition zu erweitern.
Problematisch wird es, wenn der Programmierer den Klassentyp abändert. Damit ändert sich
automatisch die Versionsnummer dieses Objekttyps und ein serialisiertes Objekt ist nicht mehr
deserialisierbar. Diese Versionsnummer wird bei Java automatisch vergeben. Hier hat der
Programmierer die Möglichkeit der Klassendefinition explizit die letzte aktuelle Versionsnummer
als Member einzutragen, womit die serialisierten Daten auch bei Änderung der Klassendefinition
auslesbar sind. Bei der Serialisierung/Deserialisierung ruft das jeweilige Objekt selbst die writeoder read-Methode auf. Zu Beginn der Deserialisierung wird somit zuerst das Objektgerüst anhand
des Klassentyps konstruiert bevor dieses Objekt die read- Methode aufrufen kann.
Objektserialisierung ist weniger für komplexe Objekte geeignet.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 81 von 89
Software Methodik
12 Anhang A [Anmerkungen]
12.1 Business Use-Case
Mit Business Use-Cases beschreiben wir organisatorische Abläufe, in denen das System einen
Business-Zweck erfüllt.
Beispiel: „Geld abheben am Bankomat“:
Kunde sucht einen Bankomaten und steckt seine Karte ein.
Der Bankomat bucht von der Karte den Geldbetrag und gibt die Geldscheine aus. Am Abend
übermittelt der Geldautomat alle Kartenbezüge ins Bankzentrum. Dort werden die Transaktionen
im Tagesendprozess von den diversen Konti abgebucht. Gleichzeitig wird an die Geldautomaten
die Liste aller Konti übermittelt, die überzogen sind.
12.2 Use-Case
Mit Use-Cases beschreiben wir die Verwendungsweise oder Bedienungsführung eines Systems.
Beispiel: Use-Case „Geld abheben am Bankomat“:
Kunde schiebt Karte ein.
Bankomat verlangt den PIN-Code.
Kunde tippt PIN-Code ein.
Bankomat offeriert Auswahlmenü mit den Optionen “Geldbezug ohne Beleg”, “Geldbezug mit
Beleg” und “Kartenrestbetrag abfragen”.
Kunde wählt beispielsweise “Geldbezug ohne Beleg” und tippt den Betrag ein.
Bankomat gibt Karte zurück und schiebt die Geldnoten hinaus.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 82 von 89
Software Methodik
13 Anhang B [Beispiele]
13.1 Fallbeispiel Autovermietung
Beispiel einer Anforderungs- und Use-Case
Erfassung am Beispiel aus dem Buch
Objektorientierte Softwareentwicklung
Analyse und Design mit der Unified Modeling Language
von Bernd Oestereich
Im folgenden wird die Checkliste aus dem Kapitel Use-Case Findung am Fallbeispiel
Autovermietung angewandt. Die Beispielsbeschreibungen sind mit markiert. Die Seitenangaben
referenzieren auf das Buch von Bernd Oestereich. Bevor wir mit der Use-Case Findung beginnen,
hier die Voraussetzungen und Anforderungen, welche gegeben sind:
Aufgabenbeschreibung (Seite 123)
In einer Autovermietung sollen alle kundenrelevanten Geschäftsprozesse durch ein durchgängiges,
einheitliches Informationssystem unterstützt werden. Bisher sind einige Geschäftsprozesse noch
nicht oder sehr ungenügend durch eine Software unterstützt. Für die übrigen existieren verschiedene
spezielle Systeme. Um einen Kunden rundum zu betreuen, müssen mehrere Systeme benutzt
werden.
Das zu entwickelnde neue System soll alle Funktionen bereitstellen, die in direktem
Zusammenhang mit der Betreuung von Kunden und anderen Geschäftspartnern(z.B. Lieferanten)
stehen. Dazu gehörten die Kundenberatung, die Verwaltung der Stammdaten(Anschriften,
Bankverbindungen etc.), die Reservierung, die Vermietung von Kfz und die Abrechnung mit dem
Kunden.
Geschäftspartnerferne und indirekte Bereiche, wie beispielsweise die interne Buchhaltung, Tarifund Produktplanung sind keine Systembestandteile.
Systemvoraussetzungen (Seite 137)
100 Mietstationen mit insgesamt 170 Terminals
500 Vermietungen/Tag
600 Reservierungen/Tag
50 Stornos/Tag
70 Reservierungsänderungen/Tag
10 Fehlabholer/Tag
20 Fehlrückgaben/Tag
210 Mietabschlüsse/Tag für mehrere Tage
31% Grosskunden, 23% Erstkunden
850 Kfz im Bestand in insgesamt 3 Kfz-Kategorien (Student, Standard, Luxus)
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 83 von 89
Software Methodik
Geschäftsobjekte (Seite 91/125/156)
Kundenakte,
Vertrag,
Rechnung,
Reservierungsbestätigung,
Rücknahmeprotokoll,
Werkstattprotokoll, Kraftfahrzeug, mobiles Zubehör (Kindersitz, Dachgepäckträger), festes
Zubehör (Klimaanlage, Anhängerkuppelung, Schiebedach), Kfz-Schlüssel, Kundenkartei,
Stellplatz, Tarifbeschreibungen, Vertragskonditionen und so weiter.
Rechnung (Seite 143)
Jede Rechnung ergibt sich aus einem Vertrag. Es gibt Einzel-, Monats-, Teil- und
Sammelrechnungen [...]
Rechnungen dürfen erstellt werden von [...], wenn [...]
Pro Niederlassung werden monatlich etwa [...] Rechnungen erstellt.
Eine Rechnung besteht aus einem Rechnungsempfänger, einem Datum, einer
Rechnungsnummer, einer Kundennummer, den Rechnungspositionen, mit denen die einzelnen
Vertragsgegenstände aufgelistet werden. Jede Position enthält eine Beschreibung, eine Anzahl,
einen Einzel- oder einen Gesamtbetrag (Positionssumme). Die Rechnung enthält eine Endsumme
(Summe aller Positionen). [...]
Anschrift (Seite 143)
Eine Anschrift gehört zu einem Unternehmen oder zu einer Person, wobei diese mehrere
Anschriften haben können. Anschriften können spezielle Bedeutungen haben:
Rechnungsanschrift
Hausanschrift
Privatanschrift
Urlaubsanschrift
Anschriften können unterschiedlich strukturiert und unterschiedlichen Inhalts sein. Folgende
Varianten sind zu unterscheiden:
Strassenanschrift (Strasse, Plz, Ort)
Postfachanschrift (Postfach, Plz, Ort)
Grosskundenanschrift (Plz, Ort)
Auslandanschrift (freier Text)
Inlandanschriften können gegen ein PLZ- und Strassenverzeichnis geprüft werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 84 von 89
Software Methodik
13.1.1 Systemgrenzen festlegen:
Mind Map erstellen(Seite 131).
Abgrenzen, was gehört zum System und was sicher nicht?
13.1.2 Stelle eine Reihe von Szenarien auf:
-
in Zusammenarbeit mit den Benutzern des Auftraggebers/Kunden
Quellen können auch bestehende Systeme sein
Anwendungsfälle (Seite 124)
13.1.3 Beteiligte Aktoren identifizieren
-
Systeme, Personen mit ihren Rollen, Tätigkeiten, Fähigkeiten und Aufgaben
evtl. Aktor-Gruppen bilden
Anwendungsfälle (Seite 124)
Aktoren (Seite126/127):
Kunde
Anfragender, Reservierender, Mieter, Zurückgebender, Neukunde, Kundenmitarbeiter,
Fahrer, Rechnungsempfänger, . . .
Mitarbeiter (Seite 125)
Telefonberater, persönlicher Berater, Kfz-Übergebender, Abrechnender, Kfz-Checkender,
Disponierender, Überführender.
Zuordnung der Rollen und Tätigkeiten
KundenberaterInnen Telefonzentrale
für Auskünfte
für Reservierungen
KundenberaterInnen in einer Niederlassung
für die Kfz-Übergabe
für die Kfz-Rücknahme
Service-MitarbeiterInnen in einer Niederlassung
für die Kfz-Check und Reparaturen
NiederlassungsleiterInnen
Koordination der Betriebsabläufe
Leitung der Telefonzentrale
Aufrechterhaltung eines 24h-Services
DisponentInnen, Kfz-ÜberführerInnen, BuchhalterInnen
nicht systemrelevant
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 85 von 89
Software Methodik
13.1.4 Use-Cases nur namentlich identifizieren (Seite 128)
-
ähnliche Szenarien gruppieren
mit Brainstorming ca. 80% aller denkbaren UCs(30- 120) definieren
Haupt- und Tätigkeitswort aufschreiben, z.B. “Af1.2 Kfz telefonisch reservieren”
13.1.5 Unechte Use-Cases eliminieren
-
nicht-funktionale UC (Performance, Leistung), Datenschutz oder Benutzerfreundlichkeit
13.1.6 Use-Cases zu Packages zusammenfassen (Seite 128)
-
mit gleichen Aktoren
Use-Case Modell erstellen
13.1.7 Kurzbeschreibungen erstellen
-
Use-Case Name, Aktoren, Kurzbeschreibung (inkl. Zweck) mittels CRC-Kärtchen erfassen
evtl. Benutzeroberflächen skizzieren
Af1.2 Kfz telefonisch reservieren (Seite 128)
Beteiligte Objekte: Kunde, Bestellannahme
•
Ein Kunde ruft an und möchte ein Kfz reservieren. Die Reservierungs- und Kundendaten
werden vom Bestellannehmer entgegengenommen und ins Reservierungssystem eingegeben.
Dem Kunden wird die Reservierungsnummer mitgeteilt.
Af2.2 Kfz übergeben (Seite 129)
Beteiligte Objekte: Kunde, Kundenbetreuer
•
Ein Kunde möchte sein gemietetes Kfz (->Af2.1 Vertrag schliessen) in der Niederlassung
entgegennehmen. Der Kundenbetreuer nimmt aus der Kundenakte den entsprechenden
Vertrag, überprüft, ob alle Vertragsgegenstände vorliegen (ausser dem Kfz evtl. Zubehör wie
Dachgepäckträger etc.) ergänzt ggf den Vertrag, händigt dem Kunden die Kfz-Papiere und den
Schlüssel aus, benennt den aktuellen Stellplatz und weist den Kunden ggf. in die Benutzung
der Vertragsgegenstände ein.
•
gewünschtes Protokoll einer AnwenderInn: „Wenn der Kunde kommt und den Schlüssel und
die Papiere zurückgibt, lade ich mir die Kundendaten und überprüfe zunächst die
Übereinstimmung mit dem Vertrag d.h. welche Gegenstände gehören dazu und welche
Bedingungen, Termine u.ä. wurden vereinbart. Wenn soweit alles in Ordnung ist, fülle ich das
Rücknahmeprotokoll aus, trage Kilometerstand, Tankfüllung und ggf. Bemerkungen ein und
mache dann die Rechnung fertig.“
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 86 von 89
Software Methodik
Af3.1 Kfz zurücknehmen (Seite 130)
Beteiligte Objekte: Kunde, Kundenbetreuer
•
Kunde gibt Kfz, Schlüssel und Papiere zurück. Die Kundenakte wird auf den Bildschirm geholt
und der Vertrag herausgesucht. Die Vertragseinhaltung wird geprüft: sind Gegenstände
komplett zurückgegeben und Termine u.a. Bedingungen eingehalten?
•
Rücknahmeprotokoll mit Kilometerstand, Tankstand und evtl. Bemerkungen wird ausgefüllt und
in die Kundenakte gelegt.
•
Anschliessend wird die Rechnung erstellt und in die Kundenakte gelegt. Der Kunde erhält eine
Ausfertigung der Rechnung. Die Kundenakte wird wieder geschlossen.
13.1.8 Use-Cases priorisieren
-
Architektur-relevante(für OOA/OOD)
Risiko-behaftete(für Projektmanagement)
Zyklus 1
Geschäftspartner (Kunde,
Stammdatenpflege sowie
Ansprechpartner von etc.).
Lieferant, Mitarbeiter etc.) verwalten. Dialoge
zur Pflege der Geschäftspartner-Beziehungen
zur
(ist
Zyklus 2
Beziehungen zwischen Reservierungen, Vermietungen, Verträgen und Geschäftspartnern
realisieren.
Zyklus 3
Abrechnung auf Grund der Verträge.
13.1.9 Normalfall für hoch-priorisierte Use-Cases formulieren
(Seite 133-137)
-
„Happy Day“-Szenario in 5-10 Schritten beschreiben, nicht ins Detail gehen
Pre-/Post-Condition, Auslöser, Resultat, Alternativen, Szenarien
13.1.10
Pro Use-Case eine Datei anlegen
z.B. Af1_2 Kfz telefonisch reservieren.doc
13.1.11
-
Hauptdokument erstellen
vgl. Anforderungsspezifikation: Systemübersicht, Aktoren-(Gruppen), Use-Case-Liste, UseCase Modell
Systemweite nicht-funktionale Anforderungen
Use-Cases gelingen selten im ersten Wurf. Sie müssen durch Diskussionen mit dem Auftraggeber in
einem iterativen Vorgehen immer weiter verfeinert werden.
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 87 von 89
Software Methodik
Abbilungsverzeichnis
ABBILDUNG 1: QUALITÄTSSICHERUNGS-REGELKREIS .........................................................................................................9
ABBILDUNG 2: PROJEKT- UND PRODUKTQUALITÄT .............................................................................................................9
ABBILDUNG 3: SOFTWARE ALS FUNKTION BETRACHTET .....................................................................................................9
ABBILDUNG 4: SOFTWARE- ENTWICKLUNGSMETHODEN ...................................................................................................13
ABBILDUNG 5: SOFTWARE-LEBENSZYKLUS ......................................................................................................................14
ABBILDUNG 6: SOFTWARE-LEBENSZYKLUS ......................................................................................................................14
ABBILDUNG 7: V-MODELL ................................................................................................................................................15
ABBILDUNG 8: STRUKTUR DES STANDARDISIERUNGSKONZEPTS .......................................................................................16
ABBILDUNG 9: SUBMODELL SOFTWAREERSTELLUNG (SWE)............................................................................................16
ABBILDUNG 10: ZUSAMMENSPIEL DER SUBMODELLE .......................................................................................................16
ABBILDUNG 11: ITERATIONS-ZYKLUS ...............................................................................................................................17
ABBILDUNG 12: PROZESS-ARCHITEKTUR ..........................................................................................................................18
ABBILDUNG 13: WASSERFALLMODELL MIT RÜCKKOPPLUNGEN........................................................................................25
ABBILDUNG 14: PHASEN DES PROTOTYPING .....................................................................................................................27
ABBILDUNG 15: SW-ENTWICKLUNGSPROZESS MIT PROTOTYPING ....................................................................................27
ABBILDUNG 16: SPIRALMODELL NACH BARRY BOEHM .....................................................................................................28
ABBILDUNG 17: DAS OBJEKTORIENTIERTE MODELL .........................................................................................................29
ABBILDUNG 18: RISIKOREDUKTION DURCH ITERATIVES VORGEHEN UND FRÜHER INTEGRATION DER SOFTWARE ............30
ABBILDUNG 19: SOFTWARE ENTWICKLUNGSPRZESS .........................................................................................................34
ABBILDUNG 20: USE-CASES DEN EINZELNEN ENTWICKLUNGSZYKLEN ZUORDNEN ...........................................................35
ABBILDUNG 21: USE-CASE DIAGRAMM ZUM KASSENSYSTEM.............................................................................................41
ABBILDUNG 22: USE-CASE DIAGRAMM ZUR ARTIKELBESTELLUNG ....................................................................................41
ABBILDUNG 23: USE-CASE KONZEPTE ..............................................................................................................................42
ABBILDUNG 24: KLASSENDIAGRAMM DES KASSENSYSTEMS ...............................................................................................47
ABBILDUNG 25: SYSTEM-SEQUENZ DIAGRAMM FÜR DEN USE-CASE: KAUFE WARE DES KASSENSYSTEMS ......................48
ABBILDUNG 26: EINKAUF BESITZT DAS WISSEN, UM DAS TOTAL ZU BERECHNEN .............................................................52
ABBILDUNG 27: "ANIMATION" ODER "DO IT MYSELF" PRINZIP .........................................................................................53
ABBILDUNG 28: EINKAUF VERWALTET EINKAUFSPOSITION UND ERZEUGT DIESE DESHALB. .............................................54
ABBILDUNG 29: EINKAUF KENNT SEINE OBJEKTE DIE ER ERZEUGT UND VERWALTET. ......................................................55
ABBILDUNG 30: WÜNSCHENSWERTE KOPPLUNG DER PRÄSENTATION AN DIE DOMÄNENSCHICHT....................................56
ABBILDUNG 31: LAYERUNG EINER APPLIKATION ..............................................................................................................64
ABBILDUNG 32: SCHICHTUNG IN EINEM TYPISCHEN OBJEKT-ORIENTIERTEN INFORMATIONSSYSTEM ................................65
ABBILDUNG 33: KOMPONENTEN INNERHALB DES MODEL LAYERS ...................................................................................65
ABBILDUNG 34: ATTRIBUTE SPEZIFIZIEREN .......................................................................................................................67
ABBILDUNG 35: OPERATIONEN SPEZIFIZIEREN ..................................................................................................................67
ABBILDUNG 36: KLASSE UND OBJEKT ...............................................................................................................................68
ABBILDUNG 37: KOLLABORATIONSDIAGRAMM VERSICHERUNG ........................................................................................69
ABBILDUNG 38: SEQUENZDIAGRAMM VERSICHERUNG.......................................................................................................70
ABBILDUNG 39: KLASSENDIGRAMM DER KAFFEEMASCHINE ..............................................................................................71
ABBILDUNG 40: KOLLABORATIONSDIGRAMM DER KAFFEEMASCHINE ...............................................................................71
ABBILDUNG 41: SEQUENZDIGRAMM DER KAFFEEMASCHINE ..............................................................................................71
ABBILDUNG 42: ZUSTANDSDIAGRAMM DES SCHACHSPIELES ............................................................................................72
ABBILDUNG 43: ZUSTANDSDIAGRAMME EINZELNER KOMPONENTEN EINES AUTOS ..........................................................72
ABBILDUNG 44: ZUSTANDSDIAGRAMM DES GETRIEBES MIT UNTERZUSTAND ...................................................................73
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 88 von 89
Software Methodik
Quellenangaben
Balzert, Heide
UML kompakt
UML kompakt mit Checklisten
Spektrum, 2001
Balzert, Helmut
Lehrbuch der Software-Technik
Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung
Spektrum, 1998
Böhm, Rolf
Fuchs, Emmerich
Pacher, Gerhard
Systems Engineering
System Entwicklung in der Wirtschaftsinformatik
Verlag der Fachvereine Zürich, 1993
Gamma, Erich
Helm, Richard
Johnson, Ralph
Vlissides, John
Entwurfsmuster
Elemente wiederverwendbarer objektorientierter Software
Deutsche Übersetzung von Dirk Riehle
Addison-Wesley, 1996
Kruchten, Philippe
Rational Unified Process – An Introduction
Addison-Wesley, 1999
Larman, Craig
Applying UML and Patterns
An Introduction to Object-Oriented Analysis and Design
Prentice Hall PTR, 1998
Oesterreich, Bernd
Objektorientierte Softwareentwicklung:
Analyse und Design mit der Unified Modeling Language
Oldenburg, 1998
Rational Rose
Rational Unified Process
http://www.rational.com/products/rup
Schürr , Prof. Dr. Andy Software-Entwicklungs-Umgebungen
http://www2.informatik.unibw-muenchen.de/Lectures/SEU/
Software Engineering I (Objektorientierte Softwaretechnik)
http://inf2-www.informatik.unibw-muenchen.de//Lectures/SEI/
Seeliger, Karl
Script: Software-Methodik
ZTI, 1999
Links:
Diverse
Links zu Vorgehensmodellen und Methoden
http://www.cetus-links.org
SW-Methodik(Script).doc
Letzte Änderung: 10. November 2001
Seite 89 von 89
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement