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