Ein Use Case-Modellierungswerkzeug für die ViPER-Plattform

Präsentation zum Thema: "Ein Use Case-Modellierungswerkzeug für die ViPER-Plattform"—  Präsentation transkript:

1 Ein Use Case-Modellierungswerkzeug für die ViPER-Plattform
Abschlussvortrag zur Diplomarbeit von Andreas Walter

2 Überblick Theoretische Grundlagen Aufgabenstellung Lösung
Begriffe & Einsatzgebiete Use Cases in der UML Textbasierte Beschreibung von Use Cases Aufgabenstellung Lösung Konzeptueller Lösungsansatz Technische Realisierung Demo Zusammenfassung & Ausblick Theoretische Grundlagen werden kurz aufgefrischt, damit wir bezüglich der grundlegenden Konzepte im Bilde sind 17. April 2007 Andreas Walter

3 Begriffe & Einsatzgebiete
System Akteur Use Case Use Case-Modell Einsatzgebiete Modellierung von Systemverhalten aus Benutzersicht Deskriptiv Präskriptiv Ausgangspunkt für Entwurf, Implementierung und Test Beispiele: Objectory, (R)UP, MeDUSA Ausgangspunkt der Use Case-Modellierung: System Gruppe von Teilen oder Dingen, die zusammenarbeiten und/oder verbunden sind, um ein Ganzes zu bilden. Schlüsselaspekt des Systembegriffes ist hier, dass die Teile ein klar erkennbares Ganzes bilden, dessen Grenzen ebenso klar erkennbar sind -> wir wissen, was innerhalb und was außerhalb des Systems liegt Akteure: Abstraktion von außerhalb des Systems befindlichen Entitäten, die mit dem System in Interaktion treten, auf die Rolle(n), die sie spielen Use Case: „describes how an actor uses a system to achieve a goal and what the system does for the actor to achieve that goal. It tells the story of how the system and its actors collaborate to deliver something that is of value for at least one of the actors.“ (BS03) Use Case-Modell: Beschreibung eines Systems durch Use Cases und Akteure Use Case-Beziehungen: Beschreiben, dass bestimmte Verhaltens- oder Interaktionsmuster im Kontext mehrerer anderer Verhaltensmuster auftreten können (Include), das Verhalten optional oder im Ausnahmefalls nötig werden kann (Extend), oder dass Verhalten einen Spezialfall oder eine Generalisierung eines anderen Verhaltens darstellen kann. 17. April 2007 Andreas Walter

4 Use Cases in der UML: Use Case-Metamodell
Formale Festlegung: Use Cases, Akteure usw. sind Beschreibungen, keine Instanzen Festlegung der Arten von Beziehungen, über die Use Cases miteinander verknüpft und ein Use Case-Modell strukturiert werden können Language Unit Use Cases ist Teil des UML-Metamodells Verwendung der UML erlaubt nicht nur die Use Case-Modellierung, sondern auch die explizite und formale Verknüpfung zu Beschreibungen von Use Case-Realisierungen in nachgelagerten Aktivitäten UML ist ein Standard! 17. April 2007 Andreas Walter

5 Use Cases in der UML: Use Case-Diagramme und Modelle
UML definiert nicht nur das UML-Metamodell, sondern auch verschiedene Arten von Diagrammen, mit denen sich graphische Sichten auf ein UML-Modell darstellen lassen und über die die graphische Manipulation von UML-Modellen möglich ist Ein solches Diagramm und das zugrundeliegende UML-Modell zeigt die Abbildung 17. April 2007 Andreas Walter

6 Textbasierte Beschreibung von Use Cases nach Bittner & Spence(2003): Inhalte
Bestandteil Erläuterung Name Der Name des Use Case. Muss eindeutig sein und sollte das Ziel der Interaktion zwischen System und Akteuren beschreiben. Kurze Beschreibung Stellt knapp das erfasste Interaktionsspektrum dar. Besondere Anforderungen Beschreibung derjenigen Anforderungen, die nicht in der Beschreibung des Ereignissflusses enthalten sind, beispielsweise nichtfunktionale Anforderungen. Vorbedingungen Beschreibung des Zustandes, in dem sich das System vor der Ausführung des Use Case befinden muss. Nachbedingungen Beschreibung des Zustandes, in dem sich das System nach der Ausführung des Use Case befinden muss. Ereignisfluss Beschreibung der Ereignisse, die bei der Ausführung des Use Case geschehen (können). Beziehungen Die Beziehungen, an denen der Use Case teilnimmt. Dies sind einerseits Beziehungen zu Akteuren, die an dem Use Case beteiligt sind, andererseits die Beziehungen zu anderen Use Cases. Use Case-Modellierung bedeutet nicht nur die Identifikation von Use Cases, die Ausschnitte des durch ein System und Akteure aufgespannten Verhaltensspektrums darstellen, sondern auch und vor allem die detaillierte Beschreibung von Use Cases UML definiert unter dem Begriff Interaktionen ein Metamodell und zugehörige Diagrammtypen, durch die theoretisch das von einem Use Case erfasste Verhaltensspektrum beschrieben werden könnte Für die nützlichste und gebräuchtlichste Form der Use Case-Beschreibung, die textbasierte Beschreibung, trifft die UML keine Festlegung Inhalte entstehen entlang des Lebenszyklus eines Use Case aus Autorensicht Bis zur letztendlich „vollständigen“ Use Case-Beschreibung kommen inkrementell Inhalte hinzu, die festlegen, wie das durch einen Use Case erfasste Verhalten beschaffen ist, und wie es in das durch den Use Case insgesamt erfasste Verhaltensspektrum eingebettet ist Die wichtigste inhaltliche Komponente stellt der Ereignisfluss dar. 17. April 2007 Andreas Walter

7 Beschreibung von Use Cases: Der Ereignisfluss
„Einheit“ der Use Case-Beschreibung: Ereignis (Event) Zerlegung der Beschreibung des Systemverhaltens in sogenannte Flüsse (Flow of Events): Basisfluss: Weg des geringsten Widerstands von Start zur Zielerreichung Alternative Flüsse: Optionales oder unter Umständen nötiges (System-)Verhalten, verknüpft mit dem variierten Fluss über Erweiterungspunkte Spezifisch Beschränkt Generell Nicht jedes Szenario kann einzeln beschrieben werden -> Herauspicken eines Normallfalles = Basisfluss Alle Varianten des im Basisfluss beschriebenen Verhaltens werden implizit durch ihre Unterschiede zu diesem beschrieben 17. April 2007 Andreas Walter

8 Beschreibung von Use Cases: Der Ereignisfluss (2)
17. April 2007 Andreas Walter

9 Use Case-Beschreibung (Bittner&Spence, 2003): Beispiel
Use Case Description: Authenticate Customer 1. Brief Description: This use case is included by other use cases. It is used to authenticate that the individual using the ATM (the Customer) is authorized to use the inserted bank card and that the account associated with the bank card is active. 2. Use Case Diagram: [...] 3. Preconditions The bank card has been inserted into the ATM. The bank card information has been read successfully. A Customer is in dialogue with the including use case. The ATM Session ID has been created. 4. Basic Flow: {Validate Card Information} 1. The system sends the bank card information to the Bank System to confirm that that the bank card and its associated account are active, that the card has not been reported stolen, and that the bank card information (including the PIN) read from the bank card is valid. 2. The system also sends the ATM ID and the ATM Session ID to the Bank System along with the bank card information. 3. The Bank System acknowledges that the bank card information is valid and that the card can be used. {Validate User Identity} 4. The system prompts the Customer for the PIN 5. The Customer enters the PIN. 6. The system checks that the entered PIN is identical to the PIN read from the bank card. {Use Case Ends} 7. Resume the including use case at the next step. 17. April 2007 Andreas Walter

10 Use Case-Beschreibung: Beispiel (Forts.)
5. Alternative Flows: 5.1 Handle No Communications With the Bank System At {Validate Card Information} if the Bank System cannot be contacted or does not reply within the set communication time-out period, 1. If the communications link has failed more times than the communication retry number, then the authentication attempt is abandoned and basic flow is resumed at {Use Case Ends}. 2. The system attempts to contact the Bank System until it has completed the number of retry attempts indicated by the communication retry number. 3. If communications are reestablished, the basic flow is resumed at {Validate Card Information}. 4. If there is still no response from the Bank System, the system created an event log entry to record the failure of the communications link to the Bank System. The event log entry includes the type of failure. 5. The system sends the event log to the Service Administrator to inform it that communication with the Bank System has been lost. 6. Resume the basic flow at {Use Case Ends}. [...] 6. Postconditions The Customer has been authorized to use the card. The Customer has been barred from using the card, and the card has been confiscated. The Customer has been barred from using the card, and the card has not been confiscated. 7. Public Extension Points None. 8. Special Requirements 17. April 2007 Andreas Walter

11 Aufgabenstellung Ziel: Werkzeugunterstützung für die Use Case-Modellierung im Rahmen einer UML-zentrierten Entwicklungsmethode (MeDUSA) Use Case-Modellierung als erste Aktivität (Requirements Modeling) Identifikation von Use Cases UML-basiert und graphisch (Use Case Modeling) Detaillierte Beschreibung von Use Cases in textbasierter Form (Use Case Description Modeling) Konzeptuelle und technische Rahmenbedingung: UML-Metamodell ist unverändert zu nutzen Use Case-Modell = UML-Modell/-Diagramme (Modell) textbasierte(r) Beschreibungen 17. April 2007 Andreas Walter

12 Konzeptueller Lösungsansatz
Zweiteilung eines Use Case-Modells in UML-basierten und textbasierten Teil impliziert überlappenden Informationsgehalt beider „Hälften“ Ein insgesamt konsistentes Use Case-Modell muss einen „semantischen Kern“ besitzen, der eindeutig in beiden Hälften repräsentiert ist! Da Use Case-Beziehungen UML-basiert erfasst und textbasiert „definiert“ werden, überlappt der Informationsgehalt der Teile eines auf diese Weise zweigeteilten Use Case-Modells Ein Use Case-Modell kann insgesamt nicht als konsistent betrachtet werden, wenn sich die beiden Modelle widersprechen (dies kann dort passieren, wo Dinge in beiden Formalismen ausgedrückt werden können) Es ist jedoch wünschenswert, ein hinsichtlich diese „semantischen Kerns“ konsistentes Modell zu erhalten, denn Im Nachhinein ist u.U. schwer zu entscheiden, was gemeint war Anforderungs-Artefakte sollten per se möglichst widerspruchsfrei und konsistent sein Problem: Verwendung natürlicher Sprache vs. Formalisierung Lösungsansatz: Stark strukturierte Beschreibung von Use Cases Ermöglicht algorithmische Konsistenzprüfungen Erlaubt Verwendung natürlicher Sprache 17. April 2007 Andreas Walter

13 Metamodell für textbasierte Use Case-Beschreibungen: Repräsentation textbasierter Beschreibungen
NarrativeDescription als Repräsentation textbasierter Beschreibungen Annahme: 1:1-Entsprechung Wenn Use Cases UML-seitig identifiziert worden sind, liegt es (vor allem hinsichtlich der Konsistenzprüfung) nahe, diesen Use Cases eine Beschreibung durch explizite Verknüpfung mit der entsprechenden Instanz der UML-Metaklasse UseCase zuzuordnen 17. April 2007 Andreas Walter

14 Metamodell für textbasierte Use Case-Beschreibungen: Flüsse und Flusskontexte
Flüsse beschreiben Verhaltensfragmente, die während der Ausführung eines Use Case am Stück auftreten können Flusskontexte beschreiben in welchem Zusammenhang die Ausführung eines Flusses beginnt, und was nach dem Erreichen des Endes eines Flusses geschieht Flusskontext ist zunächst ein abstrakter Oberbegriff, konkrete Untertypen werden genutzt, um die Rolle festzulegen, die ein Fluss in der Beschreibung eines Use Case spielt. 17. April 2007 Andreas Walter

15 Metamodell für textbasierte Use Case-Beschreibungen: Flüsse und Flusskontexte (2)
Die UML unterscheidet implizit Use Cases in solche, die eigenständig zur Ausführung gebracht werden können, und solche, die nicht notwendigerweise zusammenhängendes Verhalten repräsentieren. Letztere Use Cases erweitern andere Use Cases. Die Beschreibung eines in diesem Sinne eigenständigen Use Case wird zerlegt in die Beschreibung des Verhaltens in einer als Normalfall angenommenen Konstellation und die Beschreibung solchen Verhaltens, das Abweichungen vom Normalfall darstellt Für die Flüsse einer textbasierten Beschreibung bedeutet dies, dass genau ein Fluss die Beschreibung des Normalfalles darstellt. Dies ist der sogenannte Hauptfluss, der durch die Eigenschaft mainFlow erfasst wird. Dieser Fluss ist der Fluss einer Use Case-Beschreibung, mit dessen Ausführung die Ausführung eines Use Case begonnen wird. Er ist deshalb allen anderen Flüssen übergeordnet und wird aus diesem Grund mit zwei TLFCs versehen. Alle anderen Flüsse beschreiben Verhalten, das als Erweiterung anderen Verhaltens zutage tritt, und werden daher als Erweiterungsflüsse bezeichnet und mit zwei EFCs versehen. 17. April 2007 Andreas Walter

16 Metamodell für textbasierte Use Case-Beschreibungen: Struktur eines Flusses
Ereignisbeschreibung ist elementarer Baustein eines Flusses Aus Sicht des Metamodells wird diese nicht weiter interpretiert 17. April 2007 Andreas Walter

17 Metamodell für textbasierte Use Case-Beschreibungen: Struktur eines Flusses (2)
Inklusionsschritte erfassen die Ausführung inkludierter Use Cases 17. April 2007 Andreas Walter

18 Metamodell für textbasierte Use Case-Beschreibungen: Struktur eines Flusses (4)
17. April 2007 Andreas Walter

19 Metamodell für textbasierte Use Case-Beschreibungen: Struktur eines Flusses (3)
Flussregionen sind gewissermaßen das, was man bei Bittner & Spence als Teilflüsse bezeichnet 17. April 2007 Andreas Walter

20 Metamodell für textbasierte Use Case-Beschreibungen: Erweiterungen
Erweiterungspunkte beschreiben Zeitpunkte, Erweiterungsregionen beschreiben Zeiträume während der Ausführung eines Flusses, zu denen Verhaltenserweiterungen eintreten können 17. April 2007 Andreas Walter

21 Metamodell für textbasierte Use Case-Beschreibungen: Alternative Erweiterungen
Alternative Erweiterungen beschreiben alternatives Verhalten, das als Variation von durch einen Use Case erfasstem Verhalten zu betrachten ist und selbst auch diesem zuzurechnen ist 17. April 2007 Andreas Walter

22 Metamodell für textbasierte Use Case-Beschreibungen: Alternative Erweiterungen (2)
17. April 2007 Andreas Walter

23 Metamodell für textbasierte Use Case-Beschreibungen: Externe Erweiterungen
17. April 2007 Andreas Walter

24 Metamodell für textbasierte Use Case-Beschreibungen: Externe Erweiterungen (2)
17. April 2007 Andreas Walter

25 Metamodell für textbasierte Use Case-Beschreibungen: Spezialisierung von Use Cases
Wenn man die Spezialisierung von Use Cases auf das durch sie repräsentierte Verhalten beschränkt, bedeutet dies seitens der textbasierten Beschreibungen von Use Cases, die Spezialisierungsbeziehung an ihren Flüssen festzumachen Die Beschreibung eines spezialisierten Use Case „vererbt“ ihre Flüsse an die Beschreibung des spezialisierenden Use Case, in deren Kontext diese punktuell erweitert oder in dafür vorgesehenen Regionen überschrieben werden können 17. April 2007 Andreas Walter

26 Metamodell für textbasierte Use Case-Beschreibungen: Spezialisierungs-Erweiterungen
17. April 2007 Andreas Walter

27 Metamodell für textbasierte Use Case-Beschreibungen: Spezialisierungs-Erweiterungen (2)
Da die Spezialisierungserweiterung keine dynamische, sondern eine statische Beziehung zwischen Flüssen etabliert, muss ein Spezialisierungs-Erweiterungsziel aus Sicht einer textbasierten Beschreibung eindeutig „genutzt“ werden, d.h., sie darf keine zwei Spezialisierungs-Erweiterungsflüsse enthalten, die das gleiche Ziel adressieren. 17. April 2007 Andreas Walter

28 Metamodell für textbasierte Use Case-Beschreibungen: Einbettung in ein Gesamtmodell
17. April 2007 Andreas Walter

29 Metamodell für textbasierte Use Case-Beschreibungen: Einbettung in ein Gesamtmodell (2)
17. April 2007 Andreas Walter

30 Beispiel für ein Use Case-Modell
Beispielsystem ist ein eingebettetes System, das der Berechnung von Flussraten in einem Rohr und der Darstellung der Berechnungsergebnisse auf verschiedenen Ausgängen dient Während der Berechnung können verschiedene Arten von Alarmen ausgelöst werden. Diese werden entweder zunächst nur registriert oder führen zum Abbruch einer Berechnungskette. Die Ausgabe der Flussrate und und Signalen zur Meldung eventuell aufgetretener Alarme geschieht auf einem analogen und einem digitalen Ausgang. Der analoge Ausgang kann zu einem Zeitpunkt nur einen Strom ausgeben, der entweder einen Flussraten-Wert oder ein Alarmsignal beschreibt, was durch die Stromstärke unterschieden werden kann Ausgabe eines Stromsignales unterscheidet sich nur hinsichtlich der Berechnung des Stromwertes und wird durch abstrakten Use Case Current Output beschrieben Spezialisierungen stellen dar, wie dieser Stromwert berechnet wird. 17. April 2007 Andreas Walter

31 Beispiel für ein Use Case-Modell (2): Textbasierte Beschreibungen
Description of Use Case Current Output Main Flow Start Preconditions: None 1 AEP: Chosse between simulation and calculation 2 SEP: Calculate actual current 3 AEP: Current stored 4 Validate that current does not exceed span limits 5 AEP: Current validated 6 Calculate PWM output signal 7 Normalize 8 Output PWM signal 9 AEP: End End Postconditions: None Alternative Flow Simulate Current Start At Choose between calculation and simulation, if simulation mode has been set 1 Store simulated value as current value End If TRUE, continue at Current stored Alternative Flow Raise „Limits exceeded“ alarm Start At Current validated, if current exceeds span limits 1 Raise „Limits exceeded“ alarm End If TRUE, Continue at End 17. April 2007 Andreas Walter

32 Beispiel für ein Use Case-Modell (3): Textbasierte Beschreibungen (2)
Description of Use Case Current Output Main Flow Start Preconditions: None 1 AEP: Chosse between simulation and calculation 2 SEP: Calculate actual current 3 AEP: Current stored 4 Validate that current does not exceed span limits 5 AEP: Current validated 6 Calculate PWM output signal 7 Normalize 8 Output PWM signal 9 AEP: End End Postconditions: None Description of Use Case Alarm Current Output Specialization Flow Calculate Alarm Current Start At Calculate actual current 1 Calculate actual current from alarm value Description of Use Case Flow Rate Current Output Specialization Flow Calculate Flow Rate Current Start At Calculate actual current 1 Calculate actual current from flow rate value 17. April 2007 Andreas Walter

33 Technische Realisierung
Verwendete Rahmenwerke und Bibliotheken: Eclipse SWT/JFace Eclipse Forms Eclipse Modeling Framework (EMF) Graphical Editor Framework (GEF) ViPER Wozu sind die Rahmenwerke prinzipiell gut? 17. April 2007 Andreas Walter

34 Technische Realisierung (2)
Graphischer Editor für UML Use Case-Modelle sc.viper.uml2.vme.behaviour.usecase: Diagrammtyp-Erweiterung für ViPER UML2 VME Editor für textbasierte Use Case-Beschreibungen sc.viper.uml2.vme.behaviour.usecase.narrativemodel EMF-basierte Implementierung des Metamodells für textbasierte Use Case-Beschreibungen Nutzung des EMF Validation Framework für die Realisierung von Konsistenzprüfungen sc.viper.uml2.vme.behaviour.usecase.narrative Implementierung des Editors für textbasierte Use Case-Beschreibungen 17. April 2007 Andreas Walter

35 Zusammenfassung und Ausblick
Herausforderungen Konzeptuell Formalisierung textbasierter Use Case-Beschreibungen, ohne die Verwendung natürlicher Sprache zu sehr einzuschränken Technisch Komplexität verwendeter Rahmenwerke ViPER reift noch Ergebnisse Metamodell für textbasierte Use Case-Beschreibungen Editor für die graphische Bearbeitung von UML-basierten Use Case-Modellen Editor für die Bearbeitung von textbasierten Use Case-Beschreibungen Integrierte Prüfung von Konsistenzbedingungen zwischen UML-Modell und Modell textbasierter Beschreibungen Ausblick Report-Generierung Simulation , interaktive Validierung 17. April 2007 Andreas Walter

36 Ende Vielen Dank! 17. April 2007 Andreas Walter