Transformationen zwischen UML-Use-Case-Diagrammen und tabellarischen Darstellungen JuliaPilarski julia.pilarski@arcor.de Fachgebiet Software Engineering Leibniz Universität Hannover EricKnauss eric.knauss@inf.uni-hannover.de Fachgebiet Software Engineering Leibniz Universität Hannover Transformationen zwischen UML-Use-Case-Diagrammen und tabellarischen Darstellungen D525066687E582236CBC4F6C23A24C97 GROBID - A machine learning software for extracting information from scholarly documents Abbildung 1. Effiziente Anwendungsfallspezifikation (nach [Bir06]) 1 Systemüberblick 2 Initiale UC-Definition 3 Detaillierte UC-Definition

In den frühen Phasen eines Softwareprojekts steht die Modellierung in einem besonderen Spannungsfeld: Entweder sind die Modelle formal genug, um verifizieren zu können, dass sie richtig modelliert wurden, oder umgangssprachlich genug, damit beim Kunden validiert werden kann, ob das Richtige modelliert wurde. Aus diesem Grund eignen sich komplexere Modelle zur Szenario-Darstellung (z.B. UML-Sequenz-Diagramme) nicht so gut. Andererseits haben grafische Modelle den Vorteil, einen guten Überblick zu bieten. Transformationen zwischen textuellen Beschreibungen und grafischen Modellen können dieses Spannungsfeld auflösen, indem sie es erleichtern, grafische Modelle und natürliche Sprache parallel zu nutzen. Dieser Beitrag untersucht das Verhältnis zwischen den Use-Case-Diagrammen der UML und (typischerweise tabellarischen) natürlich-sprachlichen Use-Cases. Mit Hilfe eines Basismetamodells definieren wir die gemeinsamen Konzepte beider Darstellungen. Wir beschreiben entsprechende Transformationen und geben konkrete Beispiele.
Einleitung

Use-Cases (auch Anwendungsfälle genannt) setzen sich für die Anforderungsspezifikation immer weiter durch. Als Vorteil wird vor allem die Beschreibung von funktionalen Anforderungen im Kontext von Benutzerzielen gesehen. Auch die explizite Betrachtung von Ausnahmen ist eine der Stärken von Use-Cases.

Für die konkrete Ausgestaltung von Use-Cases gibt es verschiedene Vorschläge: Auf der einen Seite gibt es die modellierungsnahe Sicht (hier repräsentiert durch die UML [OMG07]). Use-Cases werden dabei in UML-Use-Case-Diagrammen benannt und die enthaltenen Erfolgs-und Sonderszenarien werden in Interaktionsdiagrammen spezifiziert. Die Vorteile sind hierbei, dass durch die definierte Semantik der Modelle Missverständnisse vermieden werden, sowie dass die Modelle durch Abstraktion eine gute Übersicht bilden können.

Dem steht auf der anderen Seite ein eher natürlich-sprachlicher Ansatz gegenüber [Coc01]. Hier werden die Szenarien als User Stories oder als Aufzählung in tabellarischen Vorlagen (im folgenden als Template bezeichnet) formuliert. Der Vorteil der natürlichen Sprache ist, dass Kunden ohne technischen Hintergrund einen Use-Case verstehen und kritisieren können. Dies ist eine wichtige Voraussetzung, um Use-Cases validieren zu können. Zudem hat man durch eine Menge von Formulierungsrichtlinien (z.B. [Rup06]) eine Basis geschaffen, um trotz natürlicher Sprache zu einer weitgehend eindeutigen Spezifikation zu kommen. Diese Richtlinien kann man zum Teil auch automatisch überprüfen, wie zum Beispiel in [Cri06,Kna07] gezeigt wurde. Als entscheidender Nachteil bleibt jedoch die mangelnde Übersichtlichkeit.

Hier wäre es schön, die Vorteile der UML einsetzen zu können. Abbildung 1 zeigt schematisch, wie man nach [Bir06] bei umfangreichen Anwendungsfallspezifikationen vorgehen sollte: UML-Use-Case Diagramme (1) lassen sich bei den ersten Gesprächen einsetzen, bei denen die Diskussion noch nicht ins Detail geht und ein Systemüberblick von größerer Bedeutung ist. Nachdem das Grobverhalten des Systems dokumentiert ist, können die Anforderungen in Form von textuellen Use-Case-Templates (bspw. nach [Coc01]) verfeinert werden (2). An dieser Stelle würde eine automatisierte Transformation von einem Diagramm zu einem Template die Überführung erleichtern. Anschließend folgt eine tiefere Analyse der Kundenwünsche. Dafür werden automatisch generierte Templates vervollständigt sowie neue textuelle Use-Cases angelegt (3). Erweiternd zu [Bir06] streben wir an, die vorgenommenen Änderungen wieder im Use-Case-Diagramm darstellen zu können (1). Voraussetzung dafür ist eine automatisierte Rücktransformation, da ansonsten der Aufwand für die Synchronisation und Sicherstellung der Konsistenz zu groß würde.

Wissensbasierte Ansätze im Requirements Engineering verfolgen zum Teil einen ähnlichen Kreislauf. In [FKM+01] wird die Verknüpfung mehrerer Szenarien genutzt, um eine Wissensbasis aufzubauen. Im Gegensatz dazu beschränken wir uns auf das weniger ergeizige Ziel, zwei nicht ganz deckungsgleiche Sichten auf Funktionale Anforderungen miteinander zu kombinieren. Dadurch stehen mit textuellen und grafischen Use-Case Repräsentationen zwei spezielle Modellierungssprachen mit ihren jeweiligen Stärken zur Verfügung.

Auf Basis der Vorarbeiten in [Pil07] präsentieren wir in diesem Beitrag ein Konzept, mit dem es möglich ist diesen Zyklus auf der Basis eines gemeinsamen Metamodells durchzuführen: Abschnitt 2 enthält eine systematische Analyse der gemeinsamen Konzepte von UML-Use-Case-Diagrammen und textuellen Beschreibungen. Diese wird in einem Basismetamodell dargestellt. Nach der formalen Begriffsklärung beschreiben wir in Abschnitt 3 wie die vorgeschlagenen Transformationen auf dieser Grundlage realisiert werden können. teur besitzen, sonst rechts neben dem Use-Case durch den sie inkludiert sind. Benutzerdefinierte Positionen auf der Zeichenfläche gehören zu den Elementen, die von der Transformation nicht betroffen sind und bei einer Aktualisierung bestehen bleiben.

Ermittlung gemeinsamer Elemente
Beispiel
EineAbbildung 3 zeigt das Use-Case-Diagramm-Metamodell, wie es in[OMG07] bereits definiert ist: Das zentrale Element dieses Metamodells ist ebenfalls ein UseCase, der mehrere «include»-und «extend»-Beziehungen haben kann. Diese Beziehungen verweisen auf einen eingeschlossenen bzw. erweiterten UseCase. Eine Erweiterung kennt den Erweiterunspunkt (ExtensionPoint) des UseCase, in dem sie unter einer Bedingung (Constraint) eintritt. Als Classifier sind zwischen Akteuren (Actor) und UseCases Assoziationen, Generalisierungen und Spezialisierungen erlaubt. Während der Analyse beider Metamodelle hat sich gezeigt, dass sich nicht alle Elemente direkt aufeinander abbilden lassen und infolgedessen ineinander nicht direkt übersetzt werden können. Als eine Abbildung wird eine Zuordnungsvorschrift bezeichnet, die jedem Element a є A eindeutig ein Element f(a) є B zuordnet [BSM+00]. Bereits bei dem ersten Betrachten fällt auf, dass die Anzahl der Elemente eines Template erheblich höher als die Anzahl der Diagramm-Elemente ist. Weiterhin stehen die Template-Elemente in komplizierteren Beziehungen zueinander. Einige Diagramm-Elemente können ausschließlich durch eine Gruppe von Elementen eines Template dargestellt werden. So verfügt bspw. ein Use-Case im Use-Case-Metamodell über ein Scenario und Interaktionsschitte (Step). Im Use-Case-Diagramm-Metamodell ist lediglich ein Element Use-
DieserBeitrag präsentiert unseren Ansatz, die jeweiligen Stärken von UML-Use-Case-Diagrammen und natürlich-sprachlichen Use-Case-Beschreibungen in tabellarischen Templates miteinander zu verbinden. Dadurch wird es möglich, ständig beide Sichten auf die funktionalen Anforderungen zu haben. Details sieht man in den ausführlichen Beschreibungen, die Übersicht erhält man in den UML-Use-Case Diagrammen. Iterative Vorgehen, bei denen mehr als einmal zwischen beiden Darstellungen gewechselt wird (z.B. nach [Bir06]), werden so erleichtert: Aus einem initialen UML-Use-Case Diagramm können die Rümpfe von Use-Cases in Templates nach [Coc01] generiert werden. Änderungen an diesen textuellen Use-Case Beschreibungen können automatisch in die Use-Case-Diagramme zurücktransformiert werden. Der Vorteil dabei ist, das Änderungen immer in der jeweils angemesseneren Modellierungsart vorgenommen werden können: Struktur und Rollenzuteilung im UML-Use-Case Diagramm, lokale Details textuell über die Templates. Auf diese Weise werden zwei domänen-spezifische Sprachen für funktionale Anforderungen miteinander kombiniert. Um dies zu erreichen, haben wir in Abschnitt 2 ein Basismetamodell verwendet, um die gemeinsamen Konzepte zu identifizieren. Am Beispiel der Include-Beziehung haben wir gezeigt, wie wir dabei vorgegangen sind. Auf Basis dieser konzeptionellen Schnittmenge von UML-Use-Cases und natürlich-sprachlichen Use-Cases haben wir Transformationen entwickelt. Uns war dabei wichtig, die beiden unterschiedlichen Sichten auf Use-Cases herauszuarbeiten und dabei die einschlägigen Metamodelle beizubehalten. Verfechter beider Ansätze können so von unserer Arbeit profitieren. Abschnitt 3 und Abschnitt 4 geben den aktuellen Stand unserer Arbeit wieder. Zur Zeit evaluieren wir einen Prototypen dieser Transformationen. Dabei untersuchen wir beispielsweise, welcher Ausschnitt des Use-Case-Modells je nach Menge und Abstraktion der Use Cases als UML-Diagramm die beste Übersichtlichkeit bietet. Eine Evaluation im Einsatz (während einer Systemanalyse) steht noch aus. Dazu halten wir auch noch einige technische Erweiterungen für erforderlich. Als nächste Schritte wollen wir die bereits vorhandenen Transformationen kontinuierlich einsetzen, um UML-Diagramme und Use-Case-Tabellen synchron zu halten. Außerdem halten wir die Einführung von Transformationssprachen für sinnvoll, um unseren Ansatz flexibel zu halten. Mit diesem Beitrag geben wir ein Beispiel für den Einsatz von Modellen und Transformationen in den frühen Phasen eines Softwareprojekts. Gerade das Spannungsfeld zwischen Verifizierbarkeit der Modelle und deren Lesbarkeit als Grundlage für die Validierung durch einen Kunden sind in diesen Phasen reizvoll. Wir laden Andere ein, unseren Ansatz in diesem Kontext zu diskutieren.
Ein potentieller Kunde möchte die Möbel in seinem Haus erneuern. Sein Erfolgsszenario umfasst folgende Aktionen: Transport der Möbelstücke organisieren, Möbel in einem Einkaufszentrum kaufen, Möbel aufbauen. Diese Schritte sind im ersten Übersichtsdiagramm (Abbildung 8) dokumentiert. Nachfolgend wird das Diagramm in Templates transformiert (siehe Abbildung 9). Für jeden Use-Case wird ein neues Template erstellt. Der Titel des jeweiligen Use-Case sowie der Name seines Hauptakteurs werden ins Template übernommen. Der Transport kann auf zwei Weisen stattfinden: entweder kümmert sich der Kunde um einen LKW, oder überlässt den Transport dem Möbelhaus (Ellipse 1). Diese Informationen sind als technische Variationen festgehalten. Der Use-Case Möbel aufbauen kann unter Bedingung Möbelstücke beschädigt durch den Use-Case Möbel umtauschen erweitert werden (Ellipse 3). Eine hohe Lautstärke beim Möbelaufbau kann in manchen Fällen Konflikte mit den Nachbarn auslösen. Das Szenario, wie diese beigeräumt werden können, wird im Use-Case Konflikt schlichten beschrieben (Ellipse 2). Letztlich werden die tabellarischen Use-Cases in das Diagramm überführt. Abbildung 11 zeigt das Ergebnis dieser Transformation. Dieses iterative Vorgehen hilft nicht nur eine Übersicht der Projektziele zu gewinnen, sondern auch alle beteiligte Akteure für weitere Gespräche zu ermitteln und ihre Zuordnung zu den entsprechenden Use-Cases zu dokumentieren.Die Vorzüge der Kombination von tabellarischen Use-Case-Notationen und einergraphischen Übersicht sowie ihre simultane Verwendung wurden im Allgemeinen inAbschnitt 1 beschrieben. Folgendes Beispiel erläutert den Kreislauf aus Abbildung 1nach [Bir06] genauer.Zu Beginn der Anforderungserhebung soll der Verlauf eines Möbeleinkaufsdokumentiert werden. Im nächsten Schritt (Abbildung 10) wird der Inhalt der Templates verfeinert bzw. umweitere Informationen ergänzt:
Abbildung 2: Use-Case-Metamodell Abbildung 3: UML-Use-Case-Metamodell Abbildung 4. Include-Schnittmenge Abbildung 5. Use-Case Basismetamodell . Die Daten der Use-Case-Templates werden mit den Daten des vereinigten Modells abgeglichen. Elemente, die im vereinigten Modell nicht existieren, werden eingetragen und gegebenenfalls als deleted markiert. Die individuellen Elemente des Use-Case-Modells können in das vereinigte Modell direkt übernommen und als sychronized markiert werden. Abbildung 11. Use-Case-Diagramm: Möbel erneuern (vollständig)
Alle Elemente aus dem Use-Case-Diagramm-Modell werden in das vereinigte Modell eingetragen. Dies ist möglich, weil alle Elemente des Use-Case-Diagramm-Modells in dem vereinigten Modell zusammenhängend sind Die individuellen Elemente des Modells können als sychronized markiert werden ABirk Erfahrungen mit Anwendungsfallspezifikation bei der Entwicklung großer IT-Systeme
München
 2006 Jahrestreffen der GI-Fachgruppe Requirements Engineering INBronstein KASemendjajew GMusiol HMühlig Taschenbuch der Mathematik Verla Harri Deutsch 2000 Classification of Model Transformation Approaches KrzysztofCzarnecki SimonHelsen online proceedings of the 2nd OOPSLA'03 Workshop on Generative Techniques in the Context of MDA
Anaheim
 October 2003 Writing Effective Use Cases ACockburn 2001 Addison Wesley CCrisp Konzept und Werkzeug zur erfahrungsbasierten Erstellung von Use Cases
Hannover
 Masterarbeit 2006 Guidelines for NL-Based Requirements Specifications GFliedl CKop WMayerthaler HMayr NLDB 2000 MNiba Bouzeghoub
Berlin Heidelberg
 Springer-Verlag 2001. 2001 LNCS 1959 MJeckle ChRupp JHahn BZengler SQueins UML 2 glasklar Hanser Wissenschaft Muenchen 2003 Einsatz computergestützter Kritiken für Anforderungen EKnauss GI Softwaretechnik-Trends 27 1 2007 Band Transformation of Use Cases to EPC Models DLübke 2006 Workshop EPK TMens KCzarnecki PVan Gorp A Taxonomy of Model Transformations 2005 Unified Modeling Language: Superstructure , Version 2.1 Object Management Group 2001 JPilarski Konzept und Implementierung von Transformationen zwischen Use Case Diagrammen und tabellarischen Darstellungen
Hannover
 Bachelorarbeit 2007 Use Case Driven Object Modeling with UML DRosenberg 1999 Addison Wesley Longman, Inc ChrisRupp Requirements-Engineering und Management Auflage. Hanser 2007 4 HStörrle UML 2 für Studenten PEARSON Studium 2005 ThStahl MVölter Modellgetriebene Softwareentwicklung dpunkt.verlag 2005