Ein Use Case-Modellierungs-werkzeug für die ViPER-Plattform

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

1 Ein Use Case-Modellierungs-werkzeug für die ViPER-Plattform
Zwischenvortrag zur Diplomarbeit von Andreas Walter

2 Überblick Theoretische Grundlagen Existierende Werkzeugunterstützung
Begriffe, Anwendungsgebiete, Beschreibung Existierende Werkzeugunterstützung Anforderungen Umsetzung Konzeptuell Technisch Demo Zwischenfazit & Ausblick Begriffe werden nur kurz in Erinnerung gebracht, da jeder damit einigermaßen vertraut sein dürfte Existierende Werkzeugunterstützung anhand einiger Beispiele, die den unserem Wissen nach vorhandenen Funktionsumfang abdecken Anforderungen werden abgeleitet aus in der betrachteten Werkzeuglandschaft identifizierten Schwachstellen Die Beschreibung der Umsetzung wird sich konzentrieren auf die Beschreibung des Metamodells für textuelle Use Case-Beschreibungen, da dies die konzeptuelle Herausforderung der Arbeit darstellt Eine Demo wird die Funktionalität des graphischen Use Case-Editors illustrieren und einen Ausblick auf den Ansatz geben, der für die Bearbeitung textueller Use Case-Beschreibungen und der Sicherung der Konsistenz zwischen UML-Modell und textueller Use Case-Beschreibung gewählt wurde Zwischenfazit und Ausblick werden den Vortrag abrunden 21. Dezember 2006 Andreas Walter

3 Begriffe & Einsatzgebiete
System Akteur Use Case Inklusion Erweiterung Generalisierung Use Case-Instanz Use Case-Modell Einsatzgebiet: Modellierung von Systemverhalten aus der Benutzersicht Deskriptiv Präskriptiv Ausgangspunkt für Entwurf, Implementierung und Test Beispiel: Objectory-Prozessmodell (Jacobson 87) 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. 21. Dezember 2006 Andreas Walter

4 Beschreibung von Use Cases: „Lebenszyklus“
„Lebenszyklus“ eines Use Case (Bittner&Spence, 2003) Klar ist: Use Cases sind nicht nur ein gedankliches Konstrukt, sondern müssen auch dokumentiert werden, um in weiteren Aktivitäten genutzt zu werden. In den einzelnen Use Case-Stadien adressierte Risiken: 1)Systemgrenzen unklar 2)Zweideutigkeiten im Modell (mehrere Use Cases meinen das gleiche) 3)Größe/Komplexität des Systems unbekannt, Notwendigkeit einzelner UseCases unbekannt 6)Ungenaue, nicht von allen geteilte Anforderungen Nachgelagerte Aktivitäten: 1-4)Scope Management und Prototyping 6) Entwurf, Implementierung, System- und Integrationstest Zitate namhafter Autoren auf dem Gebiet der Use Cases belegen, dass die primäre Darstellungsform für Use Case-Beschreibungen der Text ist: -A.Cockburn: „Use Cases are fundamentally a text form, although they can be written using flow charts, sequence charts, Petri nets or programming languages. Under normal circumstances, they serve as a means of communication from one person to another, often among people with no special training. Simple text is, therefore, usually the best choice.“ -I. Jacobson: „By making use cases classifiers in UML, you have the tool to formally describe use cases to basically any depth you want. The difficulty is, however, to use what is available in UML in the most pragmatic way. I am still reluctant to suggest that system analysts describe use cases more formally than in some textual form.“ -Kurt Bittner, Ian Spence: "The reality is that the formalism provides a framework for the creation of our models and the diagrams provide a nice overview of the system, but the real value of a use case is in the textual use-case descriptions. It is in the use-case descriptions that the majority of the model's content resides, and it is in the authoring of the use-case descriptions where most effort will be expended." (aus "Use Case Modeling", S. 19) 21. Dezember 2006 Andreas Walter

5 Beschreibung von Use Cases: Graphische Übersicht
Übersicht durch UML2 Use Case-Diagramme Die anfangs in Erinnerung gebrachten Konzepte werden hier überblicksartig dargestellt und können vor allem für das initiale Festhalten eines neuen Use Case genutzt werden Beziehungen zwischen Use Cases werden hier jedoch allenfalls deklariert, aber nicht definiert. Dies geschieht in den Detailbeschreibungen, allen voran der textuellen 21. Dezember 2006 Andreas Walter

6 Beschreibung von Use Cases: Inhalte (Bittner&Spence, 2003)
Bestandteil Erläuterung Name Name des Use Case. Muss eindeutig sein und sollte das Ziel der Interaktion zwischen System und Akteur beschreiben. Kurze Beschreibung Stellt knapp den Zweck des Use Case dar. Vorbedingungen Textuelle Beschreibung des Zustandes, der vor Ausführung des Use Case gegeben sein muss. Optional. Nachbedingungen Textuelle Beschreibung des Zustandes, der nach Ausführung des Use Case gegeben sein muss. Optional. Besondere Anforderungen Textuelle Beschreibung von Anforderungen, die nicht in der Beschreibung des Ereignisflusses enthalten sind, bspw. nichtfunktionale. Optional. Ereignisfluss Textuelle Beschreibung der Ereignisse, die bei der Ausführung des Use Case geschehen (können). Strukturiert in Basisfluss, alternative Flüsse, Teilflüsse. Erweiterungspunkte Positionen im Ereignisfluss, an denen alternative Abläufe ansetzen können. Optional. Die hier aufgeführten Inhalte sind die wesentlichen Inhalte, die die vollständige Beschreibung eines Use Case haben sollte (nach BS03). Der Hauptteil der „Verhaltenslogik“ eines Use Case steckt in den hervorgehobenen Zeilen Der Ereignisfluss ist der Oberbegriff für die Verhaltensbeschreibung und ist wie gezeigt strukturiert Erweiterungspunkte dienen der Verknüpfung von Flüssen (und Use Cases) 21. Dezember 2006 Andreas Walter

7 Beschreibung von Use Cases: Der Ereignisfluss
„Einheit“ der Use Case-Beschreibung: Ereignis Zerlegung des Systemverhaltens in sogenannte Flüsse: 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 Generell Beschränkt 21. Dezember 2006 Andreas Walter

8 Beschreibung von Use Cases: Der Ereignisfluss (2)
21. Dezember 2006 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. 21. Dezember 2006 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 21. Dezember 2006 Andreas Walter

11 Existierende Werkzeugunterstützung
Produkt Aspekt MS Office RSA VP EE Gentleware Poseidon Together 2006 Artisan Studio 6.1 ILogix Rhapsody Use Case Editor Jaczone Way Pointer UML2-MM vollständig nutzbar + - (+) Prüfung UML-Syntax Prüfung UML-Constraints Prüfung weiterer Konsistenzbed. Prinzipiell möglich Strukturierte UC-Beschreibung Explizite Erfassung von UC-Beziehungen O Konsistenz-sicherung Text - UML UML TM Die Übersicht ist zu verstehen als eher grobe Übersicht über die Features der evaluierten Tools. Wesentlich sind folgende Fragestellungen: In welchem Umfang ist die UML-Use Case-Modellierung möglich? Werden alle Konzepte aus der UML-Language Unit Use Cases angeboten? In welchem Umfang wird sichergestellt, dass die UML-Modelle konsistent sind? D.h., wird die Einhaltung der in der UML-Spec. Definierten abstrakten Syntax sichergestellt? Wird die Einhaltung der in der UML-Spec. Definierten Semantik definiert? (Einhaltung von Constraints)? Werden evtl. darüber hinaus gehende sinnvolle semantische Einschränkungen geprüft? In welchem Umfang ist die textuelle Beschreibung von Use Cases möglich? Ist dies prinzipiell (d.h. in irgendeiner Form) möglich? Gibt es eine Möglichkeit zur strukturierten Beschreibung von Use Cases, d.h., formularbasiertes Bearbeiten von Use Case-Beschreibungen? (Use Case-Beschreibungen haben ja, wie gesehen, viele Aspekte) Wird Konsistenz von UML-Modellen und den textuellen Beschreibungen von Use Cases sichergestellt? 21. Dezember 2006 Andreas Walter

12 Erkannte Probleme & Anforderungen
Oft unvollständige Implementierung und damit Unterstützung des UML2-Metamodells Oft fehlende Unterstützung für textuelle Use Case-Beschreibung Konsistenz zwischen UML-Modell und textueller Beschreibung kaum gesichert Anforderungen Graphischer Editor für UML2 Use Case-Modelle Editor für textuelle Use Case-Beschreibungen Konsistenzsicherung Innerhalb des UML2 Use Case-Modells (i.W. gem. UML2-Spec.) Zwischen textueller Beschreibung und UML2 Use Case-Modell Innerhalb der textuellen Beschreibungen Erläuterung zu den Anforderungen: Wir arbeiten „UML-getrieben“, d.h. erachten die von der UML-Spec. erfassten Konzepte für notwendig und ausreichend in der Phase der „Entdeckung“ von Use Cases. Da ein UML-Modell i.A. eine Graph und nicht eine Baumstruktur bildet, ist graphische Modellierung für viele Aspekte eines UML-Modells indiziert und auch hier sinnvoll. „Doing use case analysis is essentially writing text“ Erstellen textueller Beschreibungen von Use Cases ist nötig, da diese die für viele Menschen, die kein tieferes technisches Verständnis haben, die am einfachsten zu verstehende Form der Use Case-Beschreibung darstellen „Fehler in der Anforderungsspezifikation sind die schlimmsten“ (s. dazu auch diverse Papers in Freemind) Anforderungsspezifikation sollte so konsistent (=widerspruchsfrei) und vollständig wie möglich sein Die Entdeckung der Use Cases stellt eine frühe Phase der Anforderungsspezifikation dar, sollte deshalb nicht schon inkonsistenten Input für die Detailarbeit darstellen, und die textuelle Beschreibung sollte alle vorab spezifizierten Strukturen des UML-Modells abbilden (oder der Nutzer erklärt diese für nicht sinnvoll und verwirft sie) Strukturen im UML-Modell sollen in der textuellen Beschreibung wiedergefunden werden können, aber eindeutig. In diesem Sinne müssen Inkosistenzen innerhalb der textuellen Use Case-Beschreibung, z.B. das doppelte, semantisch inkonsistente Etablieren einer im UML-Modell definierten Beziehung verhindert werden 21. Dezember 2006 Andreas Walter

13 Konzeptueller Lösungsansatz
Konzeptuelle Modellierung: UML2-Metamodell ist vorhanden Datenmodell für UML2 Use Case-Modelle UML2 Diagram Interchange Datenmodell für graphische Darstellung Metamodell für textuelle Use Case-Beschreibungen Datenmodell für textuelle Use Case-Beschreibungen Explizite Verknüpfung von UML Use Case-Modell und textueller Beschreibung von Use Cases Konsistenzsicherung Zwischen UML- und textueller Darstellung durch „Strukturvergleich“ Innerhalb des UML-Modells und innerhalb des „Textmodells“ durch Fordern bzw. Verbieten bestimmter Verknüpfungen 21. Dezember 2006 Andreas Walter

14 UML2 Metamodell: Language Unit Use Cases
21. Dezember 2006 Andreas Walter

15 Metamodell für textuelle Use Case-Beschreibungen: Modellebene
Ausgangspunkt einer Konsistenzsicherung zwischen UML-Modell und textueller Beschreibung der enthaltenen Use Cases ist sicherlich, dass jeder Use Case überhaupt eine textuelle Beschreibung erhält. Zudem können UML-Modelle durch Namensräume wie Pakete (also auch das Modell selber) und Komponenten hierarchisch strukturiert werden. Zu diesem Zweck ist auf der gröbsten Granularitätsstufe eine textuelle Entsprechung zu UML-UseCases und –Namensräumen durch die Metaklassen NarrativeElement, NarrativeNamespace, NarrativeModel und NarrativeDescription gegeben. 21. Dezember 2006 Andreas Walter

16 Metamodell für textuelle Use Case-Beschreibungen: Use Case-Ebene
TODO: Farbliche Hervorhebungen und Kardinalitäten im Metamodell festhalten!! Wichtig ist bei der Konzipierung des textuellen Metamodells das Finden einer Repräsentation für UML-Modellbeziehungen gewesen: -Generalisierung -Inklusion -Erweiterungsbeziehung Zudem sollen alternative Abläufe, optionales Verhalten und Fehlerbehandlungen „beschränkt“ , „spezifisch“ und „generell“ nach Bittner/Spence bearbeitet werden können. Die Repräsentation der Erweiterung, Generalisierung/Spezialisierung und von alternativen Abläufen (die so etwas wie eine Vorstufe der Erweiterungsbeziehung darstellen) wird durch die Ober-Metaklasse Extension zusammengefasst. 21. Dezember 2006 Andreas Walter

17 Metamodell für textuelle Use Case-Beschreibungen: Flussebene
Fortsetzung der Beschreibung der textuellen Repräsentation von UML-Modellbeziehungen: -Inklusion: Durch einen Include-Schritt in einem Flow des inkludierenden Use Case repräsentiert. Dieser Include-Schritt referenziert die Include-Instanz im referenzierten UML-Modell -Erweiterung: Wie auch im UML-Metamodell die Erweiterungsbeziehung komplizierter spezifiziert ist als die Include-Beziehung, so ist die Erweiterungsbeziehung auch schwieriger textuell zu repräsentieren. Es gilt, die Erweiterungsbeziehung als solche, die von ihr referenzierten Erweiterungspunkte und u.U. eine Bedingung für die Erweiterungsbeziehung zu erfassen. Dies leisten die Metaklasse ExternalExtension, ExternalExtensionPoint und ExtensionTrigger, die die Beziehung, die Erweiterungspunkte und die evtl. Bedingung erfassen. Beachte: Eine Extend-Beziehung mit Bezug auf mehrere ExtensionPoints wird durch ebensoviele Flüsse, repräsentiert, die jeweils ein einzufügendes Fragment darstellen. Ein erweiternder Use Case muss also für jeden ExtensionPoint in jeder Extend-Beziehung, an der er teilnimmt, ein Verhaltensfragment spezifizieren. Darüber hinaus für jede Extend-Beziehung evtl eine Bedingung. -Generalisierung: Konzeptionell schwierig, da die UML-Spec. Hier nur die Semantik der Generalisierung zwischen Classifiern definiert, was sehr abstrakt ist. Generalisierung zwischen Use Cases muss daher zunächst mit einer entsprechenden Semantik versehen werden. Wir haben uns für eine „Template-Method“-Semantik entschieden, d.h, dass ein genereller Use Case einen generischen Ablauf definiert, der von speziellen Use Cases „gefüllt“ wird, indem Verhaltensfragmente an durch „SpecializationExtensionPoints“ definierten Stellen eingefügt werden. Zu klären ist noch die Sichtbarkeit der SpecializationExtensionPoints in den NarrativeDescriptions der spezialisierenden Use Cases. Alternative Abläufe werden durch die Metaklassen AlternativeExtension und AlternativeExtensionPoint realisiert. Beachte: Wenn eine AlternativeExtension an einem AlternativeExtensionPoint beginnt und wieder endet, is der zugehörige Fluss Kandidat für ein Erweiterungsfragment. Man könnte hier automatisch einen erweiternden Use Case auslagern. 21. Dezember 2006 Andreas Walter

18 Technische Realisierung
Verwendete Rahmenwerke: Eclipse SWT/JFace Eclipse Modeling Framework (EMF) Graphical Editor Framework (GEF) ViPER Eclipse Forms 21. Dezember 2006 Andreas Walter

19 Zwischenfazit Herausforderungen Bisher „gestemmt“ Noch zu realisieren
Konzeptuell Formalisierung textueller Use Case-Beschreibungen, ohne dem Benutzer eine bestimmte „Sprache“ aufzuzwingen Herstellung der Bezüge zwischen textueller Darstellung und UML-Modell Technisch Komplexität der Rahmenwerke wird durch ViPER nicht verborgen ViPER reift noch Bisher „gestemmt“ Realisierung des graphischen Use Case-Editors Konzipierung des textuellen Metamodells und des darauf aufbauenden Editors Struktureller Abgleich auf grobgranularer Ebene zwischen UML-Modell und textuellem Modell Noch zu realisieren Bearbeitung textueller Beschreibungen im Detail, d.h. auf der Ebene einzelner Use Cases Nice to have Use Case-Refactoring 21. Dezember 2006 Andreas Walter