Objektorientierte Softwareentwicklung Anforderungsmodellierung
Die Inhalte der Vorlesung wurden primär auf Basis der angegebenen Literatur erstellt. Darüber hinaus sind viele Teile direkt aus der Vorlesung von Prof. Dr.-Ing. Faustmann (ebenfalls FHW Berlin) übernommen worden. Für die Bereitstellung dieses Vorlesungsmaterials möchte ich mich an dieser Stelle noch einmal recht herzlich bedanken.
04.05.2010 OO – A/D/P
Prof. Dr. Andreas Schmietendorf
1
Übersicht zur Vorlesung §
Geschäftsprozesse – EPK-Darstellung
§
Motivation zur Anforderungsanalyse
§
Inhalte & Aufbau eines Pflichtenheft
§
Ableitung und Untersetzung von Use Cases
04.05.2010
Prof. Dr. Andreas Schmietendorf
2
Geschäftsprozesse – EPK-Darstellung
04.05.2010 OO – A/D/P
Prof. Dr. Andreas Schmietendorf
3
Definition Geschäftsprozess “Als Geschäftsprozess bezeichnet man eine Menge von wertschöpfenden Funktionen, die durch definierte Ereignisse ausgelöst werden. Diese Funktionen verwenden vorhandene Daten und erzeugen Ausgabedaten. Geschäftsprozesse können in Teilprozesse zerlegt werden.”
(Quelle: Friedrich, M.: Betriebliche Anwendungssysteme, in Schneider, U.; Werner, D.: Taschenbuch der Informatik.)
04.05.2010
Prof. Dr. Andreas Schmietendorf
4
EPK-Grundelemente Eine EPK ist ein gerichteter Graph und hat: §
§
Knoten -
Ereignis
-
Funktion
-
Verknüpfungsoperatoren
-
Funktions- und ereignisorientierte Darstellung der Abläufe
Kanten -
Darstellung der Abhängigkeiten zwischen Ereignis und Funktion
-
Verknüpfungsoperatoren
04.05.2010
Prof. Dr. Andreas Schmietendorf
5
Beispiel eine GP
Tesy Tool SST Tesy Tool
Tafel Tool
Auftrag Auftrag
Auftrag prüfen und analysieren
ICSC
A
WN-ITC
SchaBe Tool
Rebell Tool
Rebell Tool
PlaNet Tool
PlaNet Tool
IRON Tool MAN
IRON Tool MAN
RUBIN Tool
RUBIN Tool
Realiseirung ermitteln
Realisierung ermittelt
WN-ITC
TerminTool Ü
Tafel Tool
Tafel Tool
TerminTool Ü
Tool Fax
Tool Fax
Tool Fax
E-Mail Tool
E-Mail Tool
E-Mail Tool
Aufträge zur Schaltung erteilen
Aufträge erteilt
Aufträge überwachen
WN-ITC
Schaltung physikalisch erstellt
Schaltunterlagen erstellen
Schaltunterlagen erstellt
A
WN-ITC
TerminTool Ü
WN-ITC
04.05.2010
Auftrag geprüft und analysiert
SchaBe Tool
Messtermine koordinieren und Messung beauftragen
Tafel Tool
Messung durchgefürht
WN-ITC
Prof. Dr. Andreas Schmietendorf
SSt
Tesy Tool
Auftrag als erledigt abschließen
Auftrag Auftrag
WN-ITC
ICSC
6
GP- vs. SW-Modellierung §
§
Ziele der GP-Modellierung -
Orientiert an Unternehmensmodellen und Organisationsstrukturen
-
Identifizierung rollenbasierter Abläufe entlang der Wertschöpfungskette
-
Optimierung von Prozessen
-
Funktions- und ereignisorientierte Darstellung der Abläufe
Ziele der SW-Modellierung (SW-Engineering) -
Modellierung eines Ausschnittes der realen Welt (Diskursbereich)
-
Use Case getriebene Modellierung
-
Architektur (Verschiedene Sichten auf das System)
-
Implementierung einer lauffähigen Applikation
04.05.2010
Prof. Dr. Andreas Schmietendorf
7
Motivation zur Anforderungsanalyse
04.05.2010 OO – A/D/P
Prof. Dr. Andreas Schmietendorf
8
Gründe fehlgeschlagener Projekte §
13,1% unvollständige Anforderungen
§
12,4% unzureichende Integration der späteren Nutzer
§
10,6% unzureichende Ressourcen
§
9,9% unrealistische Erwartungen
§
9,3% unzureichende Bearbeitungsunterstützung
§
8,7% zu viele Änderungen der Anforderungen
§
8,1% Schwächen bei der Planung
§
7,5% System wurde bei der Einführung nicht mehr benötigt
Quelle: Standish Group, in Pfleeger, S.L.: Software Engineering, Prentice Hall, 1998 04.05.2010
Prof. Dr. Andreas Schmietendorf
9
Problemdefinition als Basis
Quelle: Dumke, R.: Software Engineering, Vieweg-Verlag, 2003 04.05.2010
Prof. Dr. Andreas Schmietendorf
10
Anforderungsanalyse Beschreibung der fachlichen Anforderungen einer Softwareversion mit allen enthaltenen Komponenten. Hier werden die Grundfunktionen des Systems, zu nutzende Standards (z.B. Schnittstellenformate), aber auch zu unterstützende Laufzeitumgebungen festgelegt. Alle funktionalen Anforderungen werden mit einer fortlaufenden Nummer, mit der jeweiligen Priorität und dem geplanten Realisierungstermin versehen und im Rahmen der Abnahme als Testkriterien verwendet.
04.05.2010
Prof. Dr. Andreas Schmietendorf
11
Qualität von Anforderungen §
Korrekt – vom Auftraggeber als zutreffend und richtig erkannt
§
Konsistent – keine Mehrdeutigkeiten & gegensätzliche Eigenschaften
§
Vollständig – mögliche Zustände des Systems sind dargestellt
§
Realistisch – Schwierig in frühen Phasen einzuschätzen
§
Sinnvoll – Nutzerbedürfnisse (keine vergoldeten Anforderungen)
§
Prüfbar – Realisierung muss nachweisbar sein
§
Verfolgbar – im Rahmen der Entwicklungsphasen
Quelle: Dumke, R.: Software Engineering, Vieweg-Verlag, 2003
04.05.2010
Prof. Dr. Andreas Schmietendorf
12
Inhalte und Aufbau eines Pflichtenheftes
04.05.2010 OO – A/D/P
Prof. Dr. Andreas Schmietendorf
13
Überblick zur Pflichtenheft §
Aufgabe – Zusammenfassung aller fachlichen Anforderungen
§
Adressaten – Auftraggeber & Auftragnehmer
§
Inhalt – Daten, Funktionen, Leistung & Qualität (WAS, nicht WIE)
§
Form – Standardisiertes Format (grobes Gliederungsschema)
§
Sprache – detaillierte verbale Beschreibung (inkl. Nummerierung)
§
Didaktik – gut lesbar à leichte Einarbeitung
§
Zeitpunkt – Versionierung (Anforderungskonferenzen AG ßà AN)
§
Umfang – ausreichendes Detaillierungsniveau ist anzustreben
Quelle: Balzert, H.: Lehrbuch der Software-Technik, Spektrum Akademischer Verlag, 1996 04.05.2010
Prof. Dr. Andreas Schmietendorf
14
Elemente des Pflichtenheft
04.05.2010
Prof. Dr. Andreas Schmietendorf
15
Aufgabe 8 - 1 §
Erstellen Sie in groben Zügen das Pflichtenheft ihres im Rahmen dieser Vorlesung zu realisierenden Projektes. -
Analysieren Sie das Ihnen übergebene Beispiel eines Pflichtenheftens
-
Führen Sie in ihrer Gruppe ein Brainstorming zu den potentiellen Anforderungen ihres Projektes durch, berücksichtigen Sie dabei die Ihnen bereits bekannte Methode der Metaplantechnik.
-
Übertragen Sie die gewonnen Erfahrungen auf das eigene Projekt und erarbeiten Sie ein erstes grobes Pflichtenheft
-
Erstellen Sie eine entsprechende Dokumentation (z.B. Power Point) zu den erarbeiteten Ergebnissen
§
2 Gruppen präsentieren ihre Ergebnisse!
04.05.2010
Prof. Dr. Andreas Schmietendorf
16
Ableitung und Untersetzung von Use Cases
04.05.2010 OO – A/D/P
Prof. Dr. Andreas Schmietendorf
17
Use Case Diagramm §
Zeigt Beziehungen zwischen Akteuren und Anwendungsfällen auf
§
Akteure (verschiedene Stereotypisierung)
§
§
-
Person im Sinne einer konkreten Rolle innerhalb einer Anwendung
-
Technische Systeme und deren Rolle
-
Externes System mit der Auslösung eines zeitlichen Ereignisses
Anwendungsfälle -
Menge von Aktivitäten eines Systems aus Nutzersicht
-
Komplette unteilbare Beschreibung
-
Zu jedem Anwendungsfall existiert eine textuelle Beschreibung
Anwendungsfallbeziehungen (, , Vererbung)
04.05.2010
Prof. Dr. Andreas Schmietendorf
18
Anwendungsfallbeziehungen §
§
§
-
Innerhalb eines Anwendungsfalles kommt ein anderer vor
-
Vermeidung redundanter Darstellungen
-
Anwendungsfall wird durch anderen unter Umständen erweitert
-
Der Basis Anwendungsfall kann auch Erweiterung ausgeführt werden
Spezialisierung & Generalisierung -
Vererbung von Verhalten und Eigenschaften an Unter-Anwendungsfälle
04.05.2010
Prof. Dr. Andreas Schmietendorf
19
Use Case Diagramm Beispiel 1
04.05.2010
Prof. Dr. Andreas Schmietendorf
20
Use Case Diagramm Beispiel 2
04.05.2010
Prof. Dr. Andreas Schmietendorf
21
Spezifikation von Anwendungsfällen Je Ellipse existiert ein Text, der den Anwendungsfall genauer beschreibt: §
Akteur (Rollen)
§
Vor- und Nachbedingungen sowie Invarianten
§
Nicht-funktionale Anforderungen
§
Ablaufbeschreibung
§
Ausnahmen und Fehlersituationen
§
Variationen & Regeln
§
Services
§
Ansprechpartner
§
Änderungshistorie (Versionierung der Beschreibung)
§
Anmerkungen und referenzierte Diagramme
04.05.2010
Prof. Dr. Andreas Schmietendorf
22
Aufgabe 8 - 2 §
Erstellen Sie für das von Ihnen in der ersten Aufgabe angelegte Pflichtenheft ein äquivalentes Anwendungsfalldiagramm, das die wichtigsten Anwendungsfälle und ihre Beziehungen enthält.
§
-
Identifikation der beteiligten Akteure
-
Identifikation der Anwendungsfälle und potentieller Beziehungen
-
Spezifizieren der Anwendungsfälle entsprechend der Schablone
-
Dokumentieren Sie ihr Projektergebnis zur weiteren Verwendung
2 Gruppen präsentieren ihre Ergebnisse!
04.05.2010
Prof. Dr. Andreas Schmietendorf
23
Aktivitätsdiagramm 1 §
§
§
Aktivitätsdiagramme zur Beschreibung eines Kontrollflusses -
vgl. Flow Chart - Programmablaufplan
-
Spezielle Form des Zustandsdiagrammes
Aktivität (ab UML Version 2.0 à Aktionen) -
Zustand mit einer internen Aktion
-
Ein oder mehrere ausgehende Transitionen
-
Ausgehende Transition impliziert den Abschluss der internen Aktion
-
Einzelner Schritt in einem Verarbeitungsablauf
Aktivitäten oder Aktivitätsdiagramme sind entweder -
Einer Klasse
-
Einer Operation
-
Oder einem Anwendungsfall zugeordnet
04.05.2010
Prof. Dr. Andreas Schmietendorf
24
Aktivitätsdiagramm 2 §
§
§
§
Verantwortlichkeitsbereiche (swim lanes) -
Zuordnung der Aktivitäten zu anderen Strukturen
-
z.B. zu entsprechenden Klassen, Use Cases, oder Organisationseinheiten
Nebenläufigkeit (parallele Verarbeitung) -
Splitting
-
UND- und ODER Synchronisation
Bedingungen und Verzweigungen (alternative Verarbeitungspfade) -
Ursprung in einer Aktion
-
Ursprung aus einer expliziten Entscheidung
Zusammengesetzte Aktivitäten
04.05.2010
Prof. Dr. Andreas Schmietendorf
25
Aktivitätsdiagramm
04.05.2010
Prof. Dr. Andreas Schmietendorf
26
Einsatzbereiche von Aktivitätsdiagrammen §
§
§
Einsatzbereiche (GP-Modellierung) -
Modellierung von Arbeitsabläufen
-
Darstellung der zugeordneten Organisationsstrukturen
Einsatzbereiche (Analysephase) -
Untersetzung fachlicher Zusammenhänge und Abhängigkeiten die sich hinter einem Anwendungsfall verbergen
-
Beschreibung von Sachverhalten aus mehreren Anwendungsfällen bzw. Darstellung anwendungsfallübergreifender Aspekte
Einsatzbereiche (Design) -
Detaillierte Spezifikation mit Implementierungsbezug
-
Detaillierte Darstellung des Ablaufverhalten von Klassen und deren enthaltenen Operationen
04.05.2010
Prof. Dr. Andreas Schmietendorf
27
Aktivitätsdiagramm
Quelle: Oestereich, B.: Objektorientierte Softwareentwicklung – UML 2.0, Oldenbourg-Verlag, 2004 04.05.2010
Prof. Dr. Andreas Schmietendorf
28
Aktivitätsdiagramm zur Untersetzung von Use Cases Authentifikation
Aufgaben ausführen
[Fehlschlag]
Mitarbeiter anlegen Aufgaben delegieren
Aufgaben ermitteln
«extend»
[überfällig]
Aufgaben erteilen
Mitarbeiter
Administrator Anmelden
04.05.2010
Prof. Dr. Andreas Schmietendorf
Warnung anzeigen
Aufgaben anzeigen
29
Aufgabe 8 - 3 §
Untersetzen Sie das von Ihnen erstellte Anwendungsfalldiagramm unter Verwendung eines oder mehrerer Aktivitätsdiagramme.
§
Die Verwendung von Anwendungsfalldiagrammen sollte sich z.B. auf Geschäftsregeln, fachliche Abhängigkeiten oder auch Gültigkeitsaspekte beziehen.
§
-
Festlegung der aus fachlicher Sicht zu modellierenden Abläufe
-
Dokumentieren Sie ihr Projektergebnis zur weiteren Verwendung
2 Gruppen präsentieren ihre Ergebnisse!
04.05.2010
Prof. Dr. Andreas Schmietendorf
30