VI-Objektorientierte-Analyse-mit-UML-Teil-2 - Gruppe ...

Vorlesung Software Engineering 

VI. Objektorientierte Analyse mit 

UML – Teil 2 

Email 

Prof. Dr. Jens Grabowski 

Tel. 39 14 690 

grabowski@cs.uni-goettingen.de 

Inhalt 

• Produktdatenmodellierung mit UML 

Class und Object Diagrammen 

• Ablaufmodellierung mit UML Activity 

Charts 

• Aufbau und Funktion des 

Pflichtenheftes 

SoftwEng (SS 05) 

VI(2)-1 

SoftwEng (SS 05) Objektorientierte Analyse mit UML – Teil 2 VI(2)-2 

Produktdatenmodellierung 

Tätigkeiten und Produkte in der 

Anforderungsanalyse (revisited) 

• Aufgabe: 

• Ausgehend von den Produktdaten im Lastenheft oder einer Fließtextbeschreibung 

des Softwareprodukts und den Anwendungsfällen wird ein konzeptuelles 

Datenmodell (Domänenmodell) des Anwendungsbereiches erstellt. Es handelt sich 

dabei nicht um das interne Datenmodell des später realisierten Softwareproduktes! 

Analytiker 

Programmierer 

• Vorgehensweise: 

• Bestimmung von Objekt- bzw. Klassenkandidaten mit verschiedenen Methoden 

(Unterstreichungen im Text, CRC-Karten, Akteure, Glossar). 

• Bestimmung wichtiger Assoziationen (Beziehungen) und Attribute zuden 

identifizierten Klassen. 

• Ggf. können zunächst konkrete Objektdiagramme und danach abstrakte 

Klassendiagramme erstellt werden. 

• Meist werden noch keine Operationen bei Klassen festgelegt. 

• Alle gefundenen Klassen (& Beziehungen) sollten auch im Glossar des 

Pflichtenheftes aufgeführt werden! 

Grundlagen 

beschreiben 

Systembeschreibung 

u. 

Begriffsverzeichnis 

Akteure Anforderungen Anforderungen 

beschreiben finden beschreiben 

Aktorliste Anwendungsfall Anwendungsfall 

Diagramm Beschreibung 

Domäne 

modellieren 

Domänen 

Modell 

Analyseprototyp 

entwickeln 

Analyse 

Prototyp 



Von der realen Welt zum 

Klassendiagramm 1(5) 

Einschub: 

Einfaches UML-Klassendiagramm 

• Ursprung: Entity-Relationship-Modell 

• UML-Klassendiagramme legen die Objekt- und Beziehungsarten (Assoziationen) 

des Anwendungsbereichs mit ihren wichtigsten Attributen fest. 

• Klassen werden in dieser Phase (meist) ohne Operationen definiert 



1

Einschub: 

Einfaches UML- 

Objektdiagramm 

• Objektdiagramme dienen zur Modellierung von konkreten Szenarien 

mit Klasseninstanzen = Objekten und Assoziationsinstanzen = Links. 

• Objektdiagramme sind das Gegenstück der Datenmodellierung zu den 

funktionalen Anwendungsfällen. 

• Objektdiagramme sind manchmal hilfreich für den Übergang von der 

realen Welt zu den abstrakten Klassendiagrammen. 



• Kandidaten für Objekte und Klassen: 

• alle phyischen, berührbaren Gegenstände (wie Vehicle) 

• Personenrollen (wie Clerk, Client) 

• Institutionen (wie Company) 

• abstrakte Begriffe (wie Address) 

• durchzuführende Transaktionen (wie Renting, Payment) 

• eintretende Ereignisse (wie Accident) 

• … 

• Man beachte: 

• Nicht nur passive Datenbestände werden als Objekte 

modelliert! Auch Operationen, Transaktionen, Ereignisse, 

Prozesse, … können sinnvolle Objektkandidaten sein. 





• Zwei Möglichkeiten: 

• Identifikation von Klassenkandidaten im Fliesstext: 

• Alle Substantive in einer Softwareproduktbeschreibung 

markieren. 

• Synonyme identifizieren. 

• Irrelevante Klassenkandidaten streichen. 

• CRC-Kartenmethode 

• Nach: K. Beck, W. Cunningham: A Laboratory For Teaching Object-Oriented 

Thinking, in: Proc. OOPSLA’89, SIGPLAN Notices, Vol. 24, No. 10, ACM Press 

(1989). 



• Motor Vehicle Reservation System (MVRS) 

A rental office lends motor vehicles of different types. The assortment 

comprises cars, vans, and trucks. Vans are small trucks, which may be 

used with the same driving license as cars. Some client may reserve 

motor vehicles of a certain category for a certain period. He or she has 

to sign a reservation contract. The rental office guarantees that a 

motor vehicle of the desired category will be available for the 

requested period. The client may cancel the reservation at any time. 

When the client fetches the motor vehicle he or she has to sign a rental 

contract and optionally an associated insurance contract. Within the 

reserved period, at latest at its end, the client returns the motor vehicle 

and pays the bill. 





• Synonyme 

• Types, Assortment, Category 

• Irrelevante Substantive (werden keine Objekte) 

• Driving Licence 

• Category, Assortment, Types 

• Period 

• … 

Die CRC-Kartenmethode 

• Problem: 

• Auftraggeber (Domain Experts) haben das Wissen über den 

Anwendungsbereich, kennen aber nicht Konzepte und Sprachen 

der Softwaretechnik. 

• Auftragnehmer (Software Experts) sind zwar in der Erstellung von 

Modellen geschult, ihnen fehlt aber das Wissen über die 

Anwendung. 

• Lösung: 

• Gruppensitzung (Workshop) mit etwa 5 Teilnehmern (sowohl 

„Domain Experts” als auch „Software Experts”). 

• Beim Durchspielen konkreter Anwendungsfälle werden Klassen mit 

ihren typischen Aufgaben identifiziert. 

• Für jede identifizierte Klasse wird eine „echte” Karteikarte angelegt, 

die eine bestimmte Person verwaltet (und ihre Rolle spielt). 



2

Aufbau einer CRC-Karte 

• CRC-Karte = Class-Responsibility-Collaboration-Card 

• Class Name: ein prägnanter Name für die Klasse 

• Responsibilities: die Aufgaben der Klasse, die beim Durchspielen von 

Anwendungsfällen identifiziert wurden 

• Collaboration: eine Liste anderer Klassen, die für die Erfüllung der Aufgaben 

der betrachteten Klassen gebraucht werden 

• Achtung: 

• In diesem Stadium keine Attribute, sondern Verantwortlichkeiten von Klassen 

suchen! Die Bestimmung von Assoziationen, Attributen und Operationen folgt später. 


UseCaseals Ausgangspunkt für 

CRC-Kartentechnik 

Use Case: MakeReservation 

Actors: Clerk 

Purpose: Fahrzeug der Kategorie C wird für Zeitraum T reserviert. 

Entry Cond: Reservierungsfunktion wird aktiviert (geht immer) 

Overview: Aufgrund des Telefonanrufes, der schriftlichen Bestellung oder des persönlichen 

Erscheinens eines Kunden K (Client) gibt Clerk eine Reservierung mit Fahrzeugkategorie 

C und Zeitraum T ein. Diese Reservierung wird - soweit möglich - berücksichtigt und es 

wird eine Bestätigung dem Kunden zugeschickt. 

Exit Cond: gewählte Reservierung in DB oder unveränderte DB 

Includes: SendMail (für das Verschicken einer Reservierungsbestätigung) 

Special Req: Die Suche nach verfügbaren Fahrzeugen dauert nicht länger als 30 Sekunden. 

Category: Sehr hohe Priorität 


CRC-Beispiel: (Reservation) 

Contract 

Identifikation von Assoziationen 

• Assoziationen sind (in aller Regel zweistellige) Relationen 

zwischen Klassen. Ihre Instanzen sind Links, die Instanzen der 

vorgegebenen Klassen verbinden. 

• In erster Linie sind solche Assoziationen aufzuführen, die nicht 

nur temporär während der Abarbeitung einer Operation 

(Systemfunktion) existieren. 

• Kandidaten für Assoziationen: 

• A ist ein logischer/physikalischer Teil von B (Client - Company) 

• A überwacht/besitzt B (RentalOffice - MotorVehicle) 

• A benutzt B (Client - MotorVehicle) 

• A verweist auf B (InsuranceContract - RentalContract) 

• A kommuniziert mit B (Client - Clerk) 



Identifikation von Attributen 

• Attribute „speichern“ primitive Eigenschaften von 

Objekten 

• Attributwerte sind Elemente von Attributdatentypen 

• Sinnvolle Attributdatentypen sind: 

• primitive Datentypen wie Integer und String. 

• Aufzählungstypen wie Color (Black, White, … ). 

• einfache zusammengesetzte Typen wie Address und Date. 

• Attribute sind bei der Modellierung nie Zeiger auf andere 

„wichtige“ Objekte (dafür gibt es Assoziationen). 

Beispiel für Attribute und 

Attributtypen 

• Vor dem Doppelpunkt steht der Attributname. 

• Hinter dem Doppelpunkt der optionale Attributtyp. 

• Nach dem Gleichheitszeichen steht ein optionaler Initialwert. 

• Achtung: 

• Das Beispiel enthält (mindestens) einen Modellierungsfehler. 



3



• Während früher Analysephasen lässt man gerne die Typen von Attributen weg. 

• Über Sichtbarkeiten (in Java: private, protected, … ) soll man sich zu diesem 

Zeitpunkt noch keine Gedanken machen. 

• Achtung: reservedVehicle ist kein Attribut von Contract! 

• System- oder Subsystemgrenze kann durch Schachtelung definiert werden. 

• Anzahl erlaubter Objektinstanzen einer Klasse können definiert werden. 

• Akteure der realen Welt können ggf. mitmodelliert werden. 



Inhalt 

• Produktdatenmodellierung mit UML Class und 

Object Diagrammen 

• Ablaufmodellierung mit UML 

Activity Charts 

• Aufbau und Funktion des Pflichtenheftes 

Ablaufmodellierung mit 

Aktivitätsdiagrammen 

• Die Beschreibung von Systemfunktionen beschränkte sich 

bislang auf die exemplarische Modellierung einzelner 

Geschäftsvorfälle bzw. Szenarien als Anwendungsfälle. Jetzt 

werden Aktivitätsdiagramme zur Ablaufmodellierung eingesetzt. 

• Mit Aktivitätsdiagrammen (Activity Charts) wird 

• der zeitliche Zusammenhang einzelner Geschäftsvorfälle in 

Form von Geschäftsprozessen modelliert. 

• werden alle Alternativen einer Systemfunktion gleichzeitig 

erfasst. 

• erstes Augenmerk auf parallel durchführbare Aktionen gerichtet. 

• erster Zusammenhang zwischen Objekten und Aktionen 

geschaffen. 



Erinnerung: 

Anwendungsfall-Diagramme 

Vorbemerkungen zu den 


Owner erbt die 

Zugriffsrechte 

von Clerk 

Clerk 

Owner 

MVRS_System 

MakeReservation 

CancelReservation 

FetchVehicle 

ReturnVehicle 

AddVehicle 

DeleteVehicle 

Fahrzeug wird für einen 

bestimmten Zeitraum 

reserviert. 

Reservierung wird gelöscht. 

Fahrzeug wird abgeholt. 

Fahrzeug wird 

rechtzeitig zurück gebracht. 

Neues Fahrzeug wird in den 

Fuhrpark aufgenommen. 

Fahrzeug wird 

ausgemustert. 

• Aktivitätsdiagramme sind 

• die jüngste Diagrammart der UML-Familie 

• ein Hybrid aus 

• den „alten“ Datenflussdiagrammen 

• den bekannten Kontrollflussdiagrammen 

• den Zustandsdiagrammen bzw. Automaten 

• besitzen noch kein fest etabliertes Einsatzgebiet, sie werden 

• sowohl als visuelle Programmiersprache für die Implementierung 

einzelner Operationen von Klassen 

• als auch zur Modellierung von Geschäftsprozessen eingesetzt 

(Zusammenhang von Anwendungsfällen und Detaillierung) 

• Bei Aktivitätsdiagrammen handelt sich also um eine prinzipiell 

ausführbare Diagrammart. 



4

Modifizierte „Idee“ für die 

ReservationContract-Klasse 

• Instanz wird erst erzeugt, wenn alle notwendigen Daten ermittelt wurden. 

Aktivitätsdiagramm für einfachen 

Anwendungsfall 

• Das Aktivitätsdiagramm für die Erzeugung einer Reservierung besitzt nur einen 

möglichen Ablauf und benutzt nur einfache Kontrollflussdiagrammelemente 



Ergänzung alternativer 

Kontrollflüsse (Ausnahmen) 

Kommentare zum vorigen 

Aktivitätsdiagramm 

• Die Erzeugung (CreateReservation) einer Reservierung erfolgt erst, nachdem 

alle Daten eingetragen wurden (man könnte auch zuerst die „leere“ 

Reservierung anlegen und diese nach und nach mit Daten füllen). 

• Die Erhebung der Reservierungsdaten erfolgt in einer willkürlichen Reihenfolge 

• Die Behandlung von Sonderfällen wird in Form von Fallunterscheidungen in den 

normalen Ablauf eingebaut. 

• Die Beschreibung einzelner Anwendungsfällen mit Aktivitätsdiagrammen hat den 

Vorteil, dass diese von Werkzeugen ausgeführt werden. 

• Hauptsächlich sollte man aber Aktivitätsdiagramme für die Beschreibung des 

Zusammenspiels (der zeitlichen Abfolge) einzelner Anwendungsfälle benutzen. 

• Die Aktionen (Prozeduren) in den einzelnen Aktivitätsknoten sind noch keinen 

Klassen zugeordnet (diese fehlen zum großen Teil noch). 



Modellierung nebenläufiger 

Aktivitäten 

Auszeichnung von manipulierten 

Objekten 



5

Aktivitätsdiagramm zur Beschreibung 

des Gesamtprozesses 

Asynchrone Signale statt 

synchrone Methodenaufrufe 

• Es werden nicht Abläufe einzelner Systemfunktionen beschrieben, sondern es wird 

skizziert, wie alle Funktionen des Systems zusammenspielen. 

• Übergänge (Transitionen) zwischen Aktivitäten (Zuständen) werden zum großen Teil 

durch externe Ereignisse ausgelöst. 

a) „normale“ Anweisungen lesen und erzeugen Signale 

b) Symbole aus Konkurrenzmodellierungssprache SDL (Standard der 

Telekommunikationsindustrie) werden verwendet 

c) Aufschriften auf getrennten Kontrollflusspfeilen (Transitionen) 

d) eine Transitionsanschrift: warten, rechnen und Signal senden 



Aktivitätsdiagramme mit 

„Swimlanes“ 

Aktivitätsdiagramme = 

Kontrollflussdiagramme + Zustandsdiagramme 

• Bei „klassischen“ Kontrollflussdiagrammen: 

wenn System (Objekt) Aktion1 ausgeführt hat und Bedingung erfüllt ist, dann 

wird danach Aktion2 ausgeführt. 

• Bei „klassischen“ Zustandsdiagrammen: 

• Swimlanes (Kästen) gruppieren Aktivitäten in Zuständigkeitsbereiche (die z.B. 

den identifizierten Akteuren entsprechen). 

• Swimlanes können auch zur Darstellung von Teilsystemgrenzen verwendet 

werden, also zur Zuordnung von Aktivitäten zu bereits bekannten Teilsystemen. 

wenn Objekt (System) sich im Zustand1 befindet und angegebenes Ereignis 

(Signal) eintritt, dann geht Objekt (System) in den Zustand2 über und führt 

dabei Aktion aus und verschickt Signal 

• Bei den UML-Aktivitätsdiagrammen: 



Aktivitätsdiagramme = 

Kontrollflußdiagramme + Datenflußdiagramme 

• Beschreibung von Datenfluss durch Parameter (wie bei “klassischen” 

Kontrollflussdiagramm): 

Weitere Elemente von 


• Mehrfachreferenzen auf dasselbe Objekt: 

Aktion1 und Aktion2 verwenden denselben Parameter x. Aktion1 kann z.B. 

Objekt x erzeugen, das von Aktion2 verändert wird. 

• Beschreibung von Datenfluss durch Objektangabe (wie mit Datenspeichern bei 

Datenflussdiagrammen): 

• Fallunterscheidungen (mit und ohne else-Zweig): 

Der Datenfluss wird explizit modelliert, der Kontrollfluss von Aktion1 nach 

Aktion2 impliziert. Aktion1 “erzeugt” Objekt der gegebenen Klasse (die Angabe 

eines Zustandes Zustand1 ist optional) 



6

Zusammenfassung 

Aktivitätsdiagramme 

• Transitionen von einer Aktion zur nächsten erfolgen entweder automatisch 

(nach Ende der Startaktion) oder durch Ereignis “getriggert”. 

• Transitionen können durch boolesche Bedingungen überwacht werden und 

schalten sobald Bedingung erfüllt ist. 

• Transitionen dürfen (vermutlich) eine eigene Aktionen auslösen, dieses 

Modellierungsmittel wird aber kaum benutzt (hier ist UML etwas unklar). 

• Es gibt atomare Aktivitäten, die ohne Unterbrechung ausgeführt werden (und 

ggf. in „normaler” Programmiersprache definiert werden). 

• Es gibt komplexe Aktionen (action states), die durch eigenes 

Aktivitätsdiagramm definiert werden und deren Ausführung unterbrechbar ist. 

• Bezüglich Nutzen und Einsatzbereiche von Aktivitätsdiagrammen gibt es noch 

(immer) keine einhellige Meinung. 

Rückblick: Beschreibung des 

Gesamtprozesses 1(3) 

• Für das Reservierungsbeispiel wurde ein Überblick über das 

Gesamtsystem in Form eines Aktivitätsdiagramms gegegeben. 







• Andere Autoren benutzen 

andere Diagrammarten um 

einen Überblick über das 

gesamte System zu 

gewinnen. Z.B. 

Klassendiagramme mit 

bestimmen Stereotypen. 

(Beispiel aus Zuser, Biffl, Grechenig, Köhle) 

• Achtung in diesem 

Analysemodell wird eine 

Systemsicht eingenommen. 

Liftknöpfe 

Knöpfe im 

Stockwerk 

Gegensprechanlage 

Überwachungsmonitor 

Überwachung 

Liftinformation 

Sensoren 

Liftsteuerung 

Stockwerk 

• Erklärung der Symbole auf der vorigen Folie: 

Schnittstelle 

• Modelliert die Interaktion zwischen dem System und einem 

Aktor (Benutzer oder anderes System). 

Controller 

• Beinhalten die gesamte dynamische Logik des Systems. 

Controller realisieren die notwendige Funktionalität um die 

Anwendungsfälle umzusetzen. 

Entität 

• Speichern alle persistenten Daten, mit welchen das System 

arbeiten muss. Beinhalten auch jegliches Verhalten zur 

Manipulation der verwalteten Daten. 



Inhalt 

• Produktdatenmodellierung mit UML Class und 

Object Diagrammen 

• Ablaufmodellierung mit UML Activity Charts 

• Aufbau und Funktion des 

Pflichtenheftes 

Pflichtenheft 1(2) 

• Rückblick Definition Lastenheft 

(aus: www.net-lexikon.de/Lastenheft.html): 

• Ein Lastenheft (auch: Grobkonzept) beschreibt die 

unmittelbaren Benutzeranforderungen, -erwartungen und - 

wünsche an ein geplantes Softwareprogramm in natürlicher 

Sprache. 

• Im Gegensatz zum Pflichtenheft muss es weder präzise noch 

vollständig detailliert sein. Es enthält aber alle wesentlichen 

Basisanforderungen. Das Pflichtenheft lässt sich auch als 

Präzisierung des Lastenhefts verstehen. 



7

Pflichtenheft 2(2) 

• Definition Pflichtenheft (aus: www.net-lexikon.de/Pflichtenheft.html): 

• Ein Pflichtenheft ist als Teil der Qualitätssicherung ein bei 

Entwicklungsprojekten von Software, Hardware oder anderer IT-Projekte 

erstelltes Dokument, in dem minutiös festgehalten wird, welche 

Eigenschaften das zu entwickelnde Produkt aufweisen soll, wie es zu 

bedienen ist und was es leisten können muss. 

• Auch wenn es keine juristisch verbindliche Definition dieses Begriffes gibt, 

ist es üblich, ein Pflichtenheft als Vertragsgrundlage zu erstellen, wenn 

Software- oder andere Projekte vereinbart werden. Auf ihm basiert die 

nachfolgende Entwicklungsarbeit und das Design des Produkts. Manchmal 

unterscheidet man auch zwischen einem Pflichtenheft, das die 

Anforderungen beschreibt, und einem Lastenheft, das die 

Produkteigenschaften darstellt. 

• Ein Pflichtenheft umfasst normalerweise die Definiton der Aufgabe, legt 

Ziele und Inhalt des Projekts fest, stellt einen Kosten- und Terminrahmen 

auf und fixiert Abnahme- sowie Bewertungsmethoden und 

Gewährleistungregelungen. 

Aufbau und Funktion eines 

Pflichtenheftes 1(9) 

• Der IEEE/ANSI-Standard 830-1993 schlägt (auf 31 Seiten) 

in etwa folgenden Aufbau für Pflichtenheft vor: 

• Einleitung mit 

• Ziel des Anforderungsdokumentes (purpose) 

• Anwendungsbereich des Produkts (scope) 

• Definitionen, Akronyme, Abkürzungen (definitions) 

• Referenzen auf andere Quellen (references) 

• Überblick über Rest des Dokumentes (overview) 

• Allgemeine Beschreibung 

• Produktionfunktionen, Benutzercharakteristika etc. 

• Spezifische Anforderungen 

• (nicht-)funktionale Anforderungen, Schnittstellenbeschreibungen etc. 

• Anhänge (mit Index) 





• Aus H. Balzert (Lehrbuch der Software-Technik (Band 1): Software- 

Entwicklung, Spektrum Akademischer Verlag, 1996) wird hier ein Vorschlag 

für den Aufbau eines Pflichtenheftes vorgestellt, der 

• das Pflichtenheft als Erweiterung des Lastenheftes ansieht, also die 

Gliederung des Lastenheftes erweitert 

• alle wichtigen Punkte der IEEE/ANSI-Norm in etwas anderer Anordnung 

übernimmt 

• sich auf die Beschreibung der Software eines Gesamtsystems konzentriert 

• vorerst die Beschreibung von Testfällen fehlt 

• Hier optional um eine Einleitung ergänzt wird (ich orientiere mich hier 

an der Vorlesung von Prof. Schürr), die 

• die erwartete Leserschaft des Pflichtenheftes festlegt, 

• die Versionsgeschichte des Pflichtenheftes erläutert, 

• auf andere relevante Dokumente wie das Lastenheft verweist, 

• den Aufbau des Pflichtenheftes beschreibt. 


Erinnerung: Aufbau und Funktion 

eines Lastenheftes 

• Nach H. Balzert (Lehrbuch der Software-Technik (Band 1): Software-Entwicklung, 

Spektrum Akademischer Verlag, 1996) ist ein Lastenheft folgendermaßen aufgebaut: 

1. Zielbestimmung: welche Ziele sollen mit dem Software-Produkt erreicht werden. 

2. Produkteinsatz: Anwendungsbereiche und Stakeholders werden genannt. 

3. Produktfunktionen: Hauptfunktionen werden beschrieben, Stakeholdergruppen 

zugeordnet und in 10er-Schritten durchnummeriert (LF nn). 

4. Produktdaten: permanent gespeicherte Hauptdaten werden festgelegt und in 

10er-Schritten durchnummeriert (LD nn). 

5. Produktleistungen: besondere Anforderungen an Hauptfunktionen oder 

Hauptdaten (Ausführungszeit, Datenumfang, … ) werden aufgezählt (LL nn). 

6. Qualitätsanforderungen: allgemeine Eigenschaften wie gute Zuverlässigkeit, 

hervorragende Benutzbarkeit, normale Effizienz, … werden festgelegt. 

7. Ergänzungen: alles was nicht in obiges Schema paßt und trotzdem wichtig ist. 

8. Glossar: alle in Punkt 1 bis 7 verwendeten wichtigen Begriffe werden erläutert. 




• Einleitung (neues Kapitel, war für „kompaktes“ Lastenheft nicht notwendig) 

• … (Inhalt siehe vor-vorige Folie) 

• Zielbestimmung (Verfeinerung des entsprechenden Lastenheftkapitels) 

Das „Warum“ steht im Vordergrund, es wird in Form der zu erreichenden 

Ziele (Kriterien für die Softwarefunktionalität) festgehalten: 

• Musskriterien: unbedingt zu erreichende Ziele 

• Wunschkriterien: nicht unabdingbare, aber sehr wünschenswerte Ziele 

• Abgrenzungskriterien: was soll mit der Software nicht erreicht werden 

• Produkteinsatz (Verfeinerung des entsprechenden Lastenheftkapitels): 

• Anwendungsbereiche: Aufgabenfelder, die unterstützt werden 

• Zielgruppen: die „Stakeholders“, die mit Softwaresystem umgehen werden 

• Betriebsbedingungen: wo und unter welchen Randbedingungen wird die 

Software eingesetzt (Büro, mobiler Einsatz, … ) 



• Produktübersicht (neuer Abschnitt): 

Überblick über das Produkt (Funktionen) sowie seine Rolle in allen 

relevanten Geschäftsprozessen (Verarbeitungsprozessen). 

Neben Fließtext können folgende UML-Diagrammarten eingesetzt 

werden: 

• Aktivitätsdiagramme für die Beschreibung von Geschäftsprozessen 

(Swimlanes werden für die Zuordnung von Aktivitäten/Systemfunktionen 

zu Anwendungsbereichen verwendet) 

• Anwendungsfall-Paketdiagramme für die Unterteilung von 

Produktfunktionen in Gruppen (orientiert an Anwendungsbereichen etc.) 

• Anwendungsfall-Diagramme mit Hauptfunktionen des Produkts als 

„primäre“ Anwendungsfälle und den Zielgruppen als Akteure (plus andere 

Teilsysteme, Sensoren, etc. bei eingebetteten Systemen) 



8



• Produktfunktionen (Verfeinerung des entsprechenden Lastenheftkapitels): 

Wie im Lastenheft durchnummeriert werden alle Produktfunktionen hier 

detaillierter beschrieben (mit Verweis auf damit umgesetzte Muss- oder 

Wunschkriterien): 

• Gliederung (Paketstruktur) wird aus der Produktübersicht übernommen und ggf. 

verfeinert. 

• Jede Hauptfunktion (primärer Anwendungsfall) wird mit Hilfe des Textschemas 

(Verweise auf Glossar!) beschrieben. 

• Spezialfälle oder oft benötigte Hilfsfunktione werden als „sekundäre“ 

Anwendungsfälle ausgelagert. 

• Der Zusammenhang von primären und sekundären Anwendungsfällen kann durch 

weitere Anwendungsfalldiagramme festgehalten werden. 

• Für eine präzisere Beschreibung von Anwendungsfällen können in Einzelfällen 

Aktivitätsdiagramme eingesetzt werden. 

• Ggf. werden statt Aktivitätsdiagrammen hierfür auch Sequenzdiagramme 

verwendet (insbesondere wenn zeitliche Aspekte wichtig sind). 




• Produktdaten (Verfeinerung des entsprechenden Lastenheftkapitels): 

Die längerfristig zu speichernden Daten des Systems werden (ggf. wie im 

Lastenheft durchnummeriert) aus Anwendersicht beschrieben (konzeptuelles 

Datenmodell). Dabei werden die Daten (mit Mengenangaben) entweder: 

• rein textuell beschrieben wie im Lastenheft (wieder Verweise auf Glossar!), 

• oder in Form von UML-Klassendiagrammen mit zusätzlichen Kommentaren erfasst. 

• Achtung: soll ein sogenanntes „ausführbares“ Pflichtenheft mit einem „Rapid 

Prototyp“ des Softwaresystems erstellt werden, so muss 

• ein feineres Klassenmodell erstellt werden, 

• ggf. das Zusammenspiel der Operationen verschiedener Klassen durch 

Interaktionsdiagramme beschrieben werden, 

• zu einigen Klassen eine Beschreibung ihres isolierten Verhaltens durch Statecharts 

(Automaten) hinzugefügt werden. 




• Produktleistungen (Verfeinerung des entsprechenden Lastenheftkapitels): 

• Weitere Angaben zu den einzelnen Produktfunktionen oder Produktdaten. Hier 

werden oft Leistungsanforderungen bzgl. Zeit und Genauigkeit angegeben. 

Verzichtet man auf diesen Abschnitt nicht ganz, dann wird man hier ggf. 

Interaktionsdiagramme und Statecharts der UML verwenden. 

• Qualitätsanforderungen (Verfeinerung des entspr. Lastenheftkapitels): 

• Softwarequalitätsmerkmale werden in Matrix-Form angegeben (siehe auch DIN ISO 

Norm 9126 zu Qualitätsanforderungen an Software). 

• Benutzungsoberfläche (neuer Abschnitt): 

• Grundlegende Anforderungen an die Benutzeroberfläche (wie Gestaltungsrichtlinien) 

werden hier festgehalten. 

• Zu einem ausführbaren Pflichtenheft gehört auch ein „Rapid Prototype“ der 

tatsächlichen späteren Benutzeroberfläche. 



• Nichtfunktionale Anforderungen (neuer Abschnitt): 

• Alle in den bisherigen Kapiteln nicht unterzubringenden Anforderungen werden hier 

aufgeführt (einzuhaltende Gesetze, Normen, Sicherheitsanforderungen, … ). 

• Technische Produktumgebung (neuer Abschnitt): 

Die Umgebung wird beschrieben, in der das zu erstellende Produkt eingesetzt 

wird. Dabei wird wie folgt unterteilt: 

• Hardware (auf der Produkt läuft): meist werden zur Beschreibung entweder 

Fließtext oder diverse Diagrammarten wie Datenfluss-Diagramme oder UML- 

Deployment-Diagramme eingesetzt. 

• Software (die das Produkt voraussetzt, mit Beschreibung von Schnittstellen): meist 

werden zur Beschreibung entweder Fließtext oder UML-Klassendiagramme 

eingesetzt, ggf. auch UML-Komponentendiagramme 

• Orgware: organisatorische Randbedingungen, die erfüllt sein müssen 





• Entwicklungsumgebung (neuer Abschnitt): 

• Die Umgebung wird beschrieben, in der das zu erstellende Produkt 

entwickelt wird (Entwicklungsplattform). Insbesondere bei eingebetteten 

Systemen unterscheidet sich die Entwicklungsplattform sehr deutlich von 

der Zielplattform. Das Kapitel ist wie das vorangegangene Kapitel aufgebaut 

(d.h. Hardware, Software, Orgware). 

• Gliederung in Teilprodukte (neuer Abschnitt): 

• Für die iterative Erstellung des Produktes (Gesamtfunktionalität wird über 

mehrere Releases hinweg „stückweise“ zur Verfügung gestellt, Unified 

Process) werden die Produktfunktionen einzelnen Teilprodukten zugeordnet. 

Die Teilprodukte werden gemäß ihrer Wichtigkeit für den Kunden 

angeordnet. 

• Glossar (das Glossar aus dem Lastenheft wird fortgeschrieben) 


9

VI-Objektorientierte-Analyse-mit-UML-Teil-2 - Gruppe ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?