Objektorientierte Softwareentwicklung

Transkript

1 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 OO A/D/P Prof. Dr. Andreas Schmietendorf 1

2 Übersicht zur Vorlesung Geschäftsprozesse EPK-Darstellung Motivation zur Anforderungsanalyse Inhalte & Aufbau eines Pflichtenheft Ableitung und Untersetzung von Use Cases Prof. Dr. Andreas Schmietendorf 2

3 Geschäftsprozesse EPK-Darstellung OO A/D/P Prof. Dr. Andreas Schmietendorf 3

4 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.) Prof. Dr. Andreas Schmietendorf 4

5 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 Prof. Dr. Andreas Schmietendorf 5

6 Beispiel eine GP SchaBe Tool SchaBe Tool Rebell Tool Rebell Tool Tesy Tool PlaNet Tool PlaNet Tool SST IRON Tool MAN IRON Tool MAN Tesy Tool Tafel Tool RUBIN Tool RUBIN Tool Auftrag Auftrag Auftrag prüfen und analysieren Auftrag geprüft und analysiert Realiseirung ermitteln Realisierung ermittelt Schaltunterlagen erstellen Schaltunterlagen erstellt A ICSC Termin- Tool Ü WN-ITC Termin- Tool Ü WN-ITC WN-ITC Tafel Tool Tafel Tool Termin- Tool Ü Tool Fax Tool Fax Tool Fax Tool Tool Tool Tafel Tool SSt Tesy Tool A Aufträge zur Schaltung erteilen Aufträge erteilt Aufträge überwachen Schaltung physikalisch erstellt Messtermine koordinieren und Messung beauftragen Messung durchgefürht Auftrag als erledigt abschließen Auftrag Auftrag WN-ITC WN-ITC WN-ITC WN-ITC ICSC Prof. Dr. Andreas Schmietendorf 6

7 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 Prof. Dr. Andreas Schmietendorf 7

8 Motivation zur Anforderungsanalyse OO A/D/P Prof. Dr. Andreas Schmietendorf 8

9 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, Prof. Dr. Andreas Schmietendorf 9

10 Problemdefinition als Basis Quelle: Dumke, R.: Software Engineering, Vieweg-Verlag, Prof. Dr. Andreas Schmietendorf 10

11 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 Prof. Dr. Andreas Schmietendorf 11

12 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, Prof. Dr. Andreas Schmietendorf 12

13 Inhalte und Aufbau eines Pflichtenheftes OO A/D/P Prof. Dr. Andreas Schmietendorf 13

14 Ü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, Prof. Dr. Andreas Schmietendorf 14

15 Elemente des Pflichtenheft Prof. Dr. Andreas Schmietendorf 15

16 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! Prof. Dr. Andreas Schmietendorf 16

17 Ableitung und Untersetzung von Use Cases OO A/D/P Prof. Dr. Andreas Schmietendorf 17

18 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 (<<include>>, <<extend>>, Vererbung) Prof. Dr. Andreas Schmietendorf 18

19 Anwendungsfallbeziehungen <<include>> - Innerhalb eines Anwendungsfalles kommt ein anderer vor - Vermeidung redundanter Darstellungen <<extends>> - 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 Prof. Dr. Andreas Schmietendorf 19

20 Use Case Diagramm Beispiel Prof. Dr. Andreas Schmietendorf 20

21 Use Case Diagramm Beispiel Prof. Dr. Andreas Schmietendorf 21

22 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 Prof. Dr. Andreas Schmietendorf 22

23 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! Prof. Dr. Andreas Schmietendorf 23

24 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 Prof. Dr. Andreas Schmietendorf 24

25 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 Prof. Dr. Andreas Schmietendorf 25

26 Aktivitätsdiagramm Prof. Dr. Andreas Schmietendorf 26

27 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) Einsatzbereiche von Aktivitätsdiagrammen - Detaillierte Spezifikation mit Implementierungsbezug - Detaillierte Darstellung des Ablaufverhalten von Klassen und deren enthaltenen Operationen Prof. Dr. Andreas Schmietendorf 27

28 Aktivitätsdiagramm Quelle: Oestereich, B.: Objektorientierte Softwareentwicklung UML 2.0, Oldenbourg-Verlag, Prof. Dr. Andreas Schmietendorf 28

29 Aktivitätsdiagramm zur Untersetzung von Use Cases Aufgaben ausführen Aufgaben delegieren Mitarbeiter anlegen «extend» Authentifikation Aufgaben ermitteln [Fehlschlag] Mitarbeiter Aufgaben erteilen [überfällig] Anmelden Administrator Warnung anzeigen Aufgaben anzeigen Prof. Dr. Andreas Schmietendorf 29

30 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! Prof. Dr. Andreas Schmietendorf 30