Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL. Christian Strempfer

Transkript

1 Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL Christian Strempfer Institut für Softwaretechnologie, Abteilung Software Engineering Universität Stuttgart, Postfach , Stuttgart Zusammenfassung. In diesem Bericht werden Use Case Antipatterns beschrieben. Insbesondere wird untersucht wie sich Use Case Antipatterns zur Verbesserung von Use Case Diagrammen einsetzen lassen. Außerdem wird überprüft, in wie weit man Use Case Antipatterns mit der Object Constraint Language beschreiben und suchen lassen kann. Gliederung 1.Grundlagen Entwurfsmuster Antipatterns Exkurs: Use Case Diagramme Use Case Antipatterns Definition Eigenschaften Typische Use Case Antipatterns Verbesserungen durch Use Case Antipatterns Object Constraint Language Einführung Aufbau der OCL-Ausdrücke Suche nach Use Case Antipatterns Automated Risk-Based Inspection of UC Models Bewertung und Folgerungen Literatur... 16

2 2 Christian Strempfer 1. Grundlagen In diesem Bericht werden Use Case Antipatterns (kurz: UC Antipatterns) beschrieben. Insbesondere wird untersucht wie sich UC Antipatterns zur Verbesserung von Use Case Diagrammen einsetzen lassen. Außerdem wird überprüft, in wie weit man UC Antipatterns mit der Object Constraint Language beschreiben und suchen lassen kann. Der Begriff Pattern kommt in der Informatik häufig vor. Es gibt Design Patterns, Event Patterns, reguläre Ausdrucke werden beim Pattern Matching eingesetzt, etc. Je nach Aufgabe können sich aber die Struktur und der Inhalt verschiedener Pattern -Arten stark unterscheiden. Deshalb werden in diesem Kapitel zunächst die verwendeten Begriffe erläutert. 1.1 Entwurfsmuster Auf deutsch ist die Übersetzung Entwurfsmuster gebräuchlicher als der englische Begriff Design Pattern, deshalb wird im Folgenden von Entwurfsmustern gesprochen. Die ursprüngliche Idee der Entwurfsmuster wurde durch den Architekten Christopher Alexander (1964) bekannt. Er setzte sie ein, um Strukturen von Bauwerken zu beschreiben. Die sogenannte Gang Of Four bestehend aus Erich Gamma, Richard Helm, Ralph E. Johnson und John Vlissides verhalfen Entwurfsmustern dann auch in der Softwareentwicklung zu ihrem Durchbruch (Gamma et al., 1994). Der Begriff Entwurfsmuster bezeichnet sowohl eine wiederkehrende Struktur, die zur Lösung eines bestimmten Problems eingesetzt werden kann, als auch die Dokumentation dieser Struktur. Die Bedeutung ergibt sich aus dem Kontext. Wenn Entwurfsmuster mit Bedacht eingesetzt werden, muss man das Rad nicht jedes Mal neu erfinden. Entwurfsmuster sind nur sinnvoll für Lösungsansätze, die sich in der Praxis bewährt haben. Die Darstellung spielt bei Entwurfsmustern eine wichtige Rolle. So gibt es meistens tabellarische Vorlagen für die Beschreibung oder die Muster müssen mit Hilfe einer speziellen Syntax definiert werden. Ein Entwurfsmuster muss mindestens einen Namen, eine Beschreibung des Problems und einen Lösungsansatz bieten, sonst kann keine Objektivität des Autors gewährleistet werden (vgl. Brown, 1998, p. 31 ff.). Je nach Zweck können noch andere Parameter hinzukommen. In den Entwurfsmustern von Gamma et al. (1994) werden beispielsweise Ratschläge für die Implementierung gegeben.

3 Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL Antipatterns Der Begriff Antipattern könnte als Antimuster übersetzt werden. Der englische Begriff ist aber nach meiner Erfahrung stärker verbreitet, weshalb auch hier der englische Begriff verwendet wird. Der Übergang von Entwurfsmustern zu Antipatterns ist fließend, deshalb lege ich hier auf die Abgrenzung beider Begriffe besonderen Wert. Brown et al. (1998) schreiben beispielsweise, dass ein Entwurfsmuster zu einem Antipattern wird, wenn es mehr Probleme erzeugt als es löst. Diese Definition hängt aber zu stark von der subjektiven Meinung des Betrachters ab. Brown et al. (1998) erklären weiter, dass Antipatterns Strukturen beschreiben, die überwiegend negative Konsequenzen verursachen. Zu diesem Zweck soll das Antipattern beschreiben, warum diese Struktur entstanden ist, an welchen Merkmalen man sie erkennen kann und welche negativen Konsequenzen durch sie entstehen. Als Lösungsansatz soll die Struktur überarbeitet werden. Dabei muss die ursprünglich beabsichtigte Funktionalität erhalten bleiben. Die von den Autoren vorgeschlagene Antipattern-Vorlage enthält noch viel mehr Details (vgl. Brown et al., 1998, p. 34ff.), die für die Definition des Begriffes Antipattern aber nebensächlich sind. Als Vorteile von Antipatterns zählen sie auf, dass sie eine Zuordnung allgemeiner Problemstellungen auf eine bestimmte Klasse von Lösungen bieten. Antipatterns basieren auf Praxiserfahrung, da sie nur erprobte Lösungen beschreiben. Und sie bieten ein gemeinsames Vokabular, durch das die Diskussion mit anderen Fachkundigen erleichtert wird. Smith et al. (2000) bauen auf der Definition von Brown et al. (1998) auf. Sie betonen zusätzlich, dass es für ihre Studenten wichtig war sowohl Entwurfsmuster als auch Antipatterns zu sehen, um ein Gespür für die betrachteten Probleme zu bekommen. Die explizite Aufzählung der Entstehungsgründe der Antipatterns trägt dazu bei. Abschließend können wir sagen, dass Antipatterns im Gegensatz zu Entwurfsmuster destruktiv sind. Sie stellen schlechte Gewohnheiten dar, die man vermeiden sollte, und dokumentieren diese. Sie helfen beim Finden von mangelhaften Strukturen und beim Verstehen der Entstehungsgründe für diese Strukturen. Dadurch unterstützen sie den Entwickler auch bei der Verbesserung seiner Fähigkeiten. 1.3 Exkurs: Use Case Diagramme Use Case Diagramme (zu deutsch: Anwendungsfalldiagramme) sind ein wichtiger Teil der Unified Modeling Language (UML). Booch et al. (1998) erklären, dass es sich dabei um Verhaltensdiagramme handelt, die die Beziehung zwischen Akteuren und Anwendungsfällen innerhalb eines Systems beschreiben. Use Case Diagramme sind wichtig, weil sie beschreiben wie die Software verwendet wird. Der Entwickler kann auch leichter den Aufbau der Software verstehen. In Tabelle 1 finden sie eine Übersicht über die Elemente der Use Case Diagramme, die in diesem Bericht verwendet werden.

4 4 Christian Strempfer Tabelle 1. Wichtige Elemente der Use Case Diagramme. Name Akteur: Ein Akteur bestimmt die Rolle, die ein Benutzer innerhalb des Systems spielt. Dieser Benutzer kann ein Menschen, Hardwarekomponenten oder ein anderes Systeme sein. Use Case: Ein Use Case stellt das Verhalten des Systems dar, ohne Aussagen über die Implementierung zu machen. Inklusion: Ein Use Case wird innerhalb eines oder mehrerer Basis Use Cases eingebunden. Der eingebundene Use Case kann nicht alleine ausgeführt werden. Erweiterung: Ein erweiternder Use Case erweitert einen Basis Use Cases an einem bestimmten Erweiterungspunkt. Die Erweiterung stellt optionales Verhalten dar, das nur in Ausnahmefällen benötigt wird. Generalisierung: Die Generalisierung ist für Use Cases und Akteure definiert. Das Kind erbt dabei die Eigenschaften des Elternteil. Bei Use Cases würden die Kinder das nicht festgelegte Verhalten des Elternteil definieren. Symbol Basis Basis Erw.punkt Elter Rolle Use C ase <<include>> UC <<extend>> (Erw.punkt) Erweiterung Kind Gute Use Case Modellierung ist nicht so einfach wie es auf den ersten Blick erscheinen mag. El-Attar und Miller (2006) zählen die folgenden Schwierigkeiten der Use Case Modellierung und ihrer Analyse auf. Die Textbeschreibung der Use Cases wird in natürlicher Sprache geschrieben, deshalb ist die formelle Analyse schwierig. Use Cases entstehen meistens in einem iterativen Prozess, bei dem nach und nach Verfeinerungen und Vervollständigungen vorgenommen werden. Für unfertigen Use Cases sollte aber auch Qualitätssicherung möglich sein. Use Case Modelle erfassen nur die funktionalen Anforderungen. Eine formelle Analyse ist deshalb schwierig. Das UML 2.0 Metamodell enthält eine große Anzahl von Fehler (auch im Bereich der Use Case Modellierung). Fuentes et al. (2003) haben viele dieser Fehler aufgedeckt. Für eine effektive Analyse der Use Case Modelle wird oft Fachwissen über das Arbeitsgebiet der modellierten Software benötigt.

5 Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL 5 2 Use Case Antipatterns In diesem Kapitel wird zunächst erklärt was Use Case Antipatterns sind. Es folgt ein Beispiel. Anschließend betrachten wir, welche Eigenschaften von Use Cases durch die Antipatterns verbessert werden können. In dieser Bericht konzentriere ich mich auf Antipatterns für Use Case Diagramme, weil nur zu diesen Literatur vorliegt. Es wäre aber ohne Weiteres möglich, Antipatterns für die Textbeschreibungen der Use Cases zu definieren. 2.1 Definition El-Attar et al. (2006) erweitern für die Use Case Diagramme die allgemeine Definition der Antipatterns. Neben den mangelhaften Strukturen in Use Case Diagrammen soll mit UC Antipatterns auch regelwidrige Modellierungspraktik bezeichnet bzw. dokumentiert werden. Nach ihrer Erfahrung werden die Vorgaben der Unified Modeling Language (kurz: UML) oft nicht eingehalten, sondern die Elemente der Use Case Diagramme mit anderer (falscher) Semantik verwendet. Das kann zu schwerwiegenden Fehlern in der weiteren Softwareentwicklung führen, weil sich die Entwickler an den Use Case Diagrammen orientieren. Die Analyse mit UC Antipatterns kann also Fehler im Einsatz und in der Modellierung von Use Case Diagrammen aufdecken. Außerdem könnten durch die Analyse Hinweise auf eine mangelhafte Anforderungserhebung gegeben werden. Tabelle 2. Darstellung eine Use Case Antipatterns nach El-Attar et al. (2006). Name Beschreibung Gründe Folgen Erkennung Verbesserung Titel des Antipattern Beschreibung der mangelhaften Struktur Liste von täuschenden Gründen, die für die Verwendung der mangelhaften Struktur sprechen Liste von schädlichen Folgen, die durch das Antipattern ausgelöst werden - Wo kann das Antipattern vorkommen? - Wie erkennt man es? Hinweise zur Verbesserung oder Vermeidung des Antipatterns 2.2 Eigenschaften UC Antipatterns kann man anhand der folgenden Kriterien unterteilen.

6 6 Christian Strempfer Domänen-Abhängigkeit Laut El-Attar und Miller (2006) gibt es Domänen-abhängige und Domänenunabhängige Antipatterns. Domäne bezeichnet hier eine konkrete Aufgabenstellung, die durch die modellierte Software gelöst werden soll. Domänen-unabhängige Antipatterns können auf jedes beliebige Use Case Modell angewendet werden. Es sind keine Informationen über die Aufgabenstellung notwendig. Domänen-abhängige dagegen sind von der Aufgabenstellung abhängig. Beispielsweise ist es schwieriger eine Software für ein Flugzeug als für einen Kaffeeautomaten zu modellieren. Deshalb benötigt man Experten für die Definition von Antipatterns, die sich mit speziellen Domänen beschäftigen. Domänenunabhängige Antipatterns dagegen könnte von einigen wenigen Use Case Experten definiert werden und würden allen zur Verfügung stehen Werkzeugunterstützung El-Attar et al. (2006) stellten fest, dass nicht alle UC Antipatterns Maschinen-lesbar gemacht werden können. Deshalb können diese Antipatterns nicht mit Hilfe von Werkzeugen gefunden werden. Für den Analysten kann man dann nur Richtlinien bereitstellen, die ihm die Suche erleichtern. El-Attar und Miller erwähnen es zwar nicht explizit, aber aus dem Text kann man herauslesen, dass es auch eine Mischform gibt. Die von ihnen vorgestellte Risikobasierte Suche hält nach Stellen Ausschau, die auf Antipatterns hinweisen könnten. Die endgültige Entscheidung bleibt aber einem Menschen vorbehalten. Sehen kann man das an ihrem Beispiel der Funktionalen Dekomposition mit Verwendung der extend -Beziehung (vgl. El-Attar, Miller, 2006, p.6f). Die Möglichkeit der Werkzeugunterstützung ist sehr stark von der verwendeten Formalisierung abhängig. 2.3 Typische Use Case Antipatterns Zur Veranschaulichung werde ich das Use Case Antipattern Funktionale Dekomposition nach El-Attar und Miller (2006) beschreiben. Weitere Beispiele folgen in Kapitel Use Case Antipattern: Funktionale Dekomposition Name: Funktionale Dekomposition Beschreibung: Die Funktionalität eines Use Cases wird über mehrere Use Cases verteilt. Das heisst es werden mehrere kleinere Use Cases (im Folgenden: Unterbau) erzeugt, die nur von einem übergeordneten Use Case (im Folgenden: Basis) verwendet werden. Dieses Konzept wird durch drei regelwidrige Techniken unterstützt. 1. Verwendung der include -Beziehung: Die Basis inkludiert als einziger Use Case die Unterbauten. Die Unterbauten stehen mit keinem anderen Element des Use Case Diagramms in Beziehung.

7 Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL 7 Häufig repräsentieren die Unterbauten die Funktionen oder Menüpunkte der modellierten Software. Dabei wird oft auch ignoriert, dass die Unterbauten in einer bestimmten Reihenfolge ausgeführt werden müssen. Dies kann bei funktionaler Dekomposition nicht korrekt dargestellt werden. 2. Vor- und Nachbedingungen als Ablaufsteuerung von Use Cases: Ein Basis Use Case soll nicht mit anderen Use Cases, die keine Unterbauten des Ersten sind, kommunizieren. Es ist also nicht möglich eine Reihenfolge von Basis Use Cases im System regelkonform zu modellieren. Um diese Einschränkung zu umgehen, könnten Entwickler die Vor- und Nachbedingungen missbrauchen. 3. Verwendung der extend -Beziehung: Die extend -Beziehung ist für Ausnahmesituationen gedacht. So soll ein bestimmter Use Case durch weitere Use Cases, die mit der Ausnahmesituation umgehen können, erweitert werden. Der Unterbau müsste Annahmen über den Basis machen, weil es sich sonst nur um die Auslagerung von Funktionalität handelt. Das wäre ein Fehler, in einem solchen Fall sollte die include -Beziehung verwendet werden. Gründe: Kleinere Use Cases sind leichter zu verstehen, umzusetzen und zu testen. Folgen: Das Use Case Modell soll nur das Verhalten skizzieren. Die zusätzlichen kleineren Use Cases bieten keinen zusätzlichen Nutzen, aber schränken die Entwickler in ihrer Kreativität ein. Funktionale Dekomposition beinhaltet also schon Designentscheidungen. Außerdem kann sie zu einer komplexeren Beschreibung der Interaktionen führen und das Modell dadurch anfällig für Fehler und Inkonsistenzen machen. Erkennung: Die Erkennung der Funktionalen Dekomposition ist auch von der verwendeten Technik abhängig. 1. Verwendung der include -Beziehung: Wo? Der Analyst muss alle inkludierten Use Cases betrachten. Wie? Wenn ein inkludierter Use Case nur eine Basis hat, trifft das Antipattern zu. 2. Vor- und Nachbedingungen als Ablaufsteuerung von Use Cases: Wo? Der Analyst muss alle Basis Use Cases mit Vor- oder Nachbedingungen untersuchen. Wie? Die Ablaufsteuerung kann auf unterschiedlichen Wegen erreicht werden: Eine Nachbedingung könnte die Initialisierung eines anderen Use Cases verlangen. Eine Vorbedingung könnte die erfolgreiche Ausführung eines anderen Use Cases fordern. Oder die Vorbedingung eines Use Cases und die Nachbedingung eines anderen stellen dieselbe Anforderung an einen variablen Wert. 3. Verwendung der extend -Beziehung: Wo? Der Analyst muss alle erweiternden Use Cases suchen.

8 8 Christian Strempfer Wie? Wenn der Unterbau mehr als eine Basis hat, muss er weiter untersucht werden. Dann muss überprüft werden, ob sein Verhalten zu allgemein ist und nur Funktionalität ausgelagert wird oder ob er wirklich zu allen Basen passt. In Kapitel wird eine mögliche Formalisierung der Abfragen nachgetragen. Verbesserung: Use Cases, die nur Teile einer vollständigen Handlung beschreiben, sollten in den übergeordneten Use Case integriert werden. Bei der ersten und zweiten Variante sollten also die Unterbauten in die Basis integriert werden. Bei der dritte Variante muss man unterscheiden, ob der Unterbau zu allgemeines Verhalten beschreibt. Ist das der Fall, sollte für jede Basis ein eigener Unterbau definiert werden. Handelt es sich um spezielles Verhalten, sollte die extend - Beziehung durch eine generalization -Beziehung ersetzt werden. 2.4 Verbesserungen durch Use Case Antipatterns Denger, Paech und Freimut (2005) haben sich mit der Verbesserung von Use Cases auseinandergesetzt. Sie teilen deren schlechten Eigenschaften bzw. Fehler (dort Defects genannt) in verschiedene Klassen ein. Im Umkehrschluss ergibt sich aus den Fehlerklassen folgende Liste von Qualitätsmerkmalen für Use Cases. Deshalb sind die Definitionen im Folgenden auch auf die kompletten Use Cases ausgerichtet und nicht nur auf die Use Case Diagramme. El-Attar und Miller (2006) betrachten nur die Kriterien Korrektheit, Konsistenz, Relevanz und Verständlichkeit. Die Wirkung der Antipatterns auf die Use Case- Qualität beruht zum größten Teil auf ihrer Arbeit Korrektheit Der Use Case muss den realen Benutzeranforderungen entsprechen, um korrekt zu sein. Er muss also zum beabsichtigten und erwarteten Verhalten des Systems passen. El-Attar et al. (2006) stellen UC Antipatterns vor, die riskante Strukturen beschreiben, die mit einer hohen Wahrscheinlichkeit auf fehlerhafte Modellierung hinweisen. Als Beispiel nennen sie die regelwidrige Verwendung der extend -Beziehung. Der erweiternde Use Case wird mit mehreren Basis-Use Cases verknüpft. Das ist in der Regel ein Fehler. Funktionalität, die unabhängig vom Basis Use Case ist, wird in der Regel durch einen eingebundenen Use Case ( include -Beziehung) dargestellt. Die Erweiterung dagegen benötigt meisten Informationen über den Basis Use Case, daher ist der Ablauf der Erweiterung (auch bei gleichem Ziel) anders und muss somit in unterschiedlichen Use Cases dargestellt werden. Leider gibt es kein Mittel um die Korrektheit von Use Cases zu überprüfen. Use Case Antipatterns sind auch kein solches Mittel. Rein semantische Fehler, die bei mangelhafter Anforderungserhebung entstehen, können nur teilweise als Antipatterns spezifiziert werden. Teilweise könnten sie durch Domänen-spezifische Antipatterns abgedeckt werden, die die Use Case Modelle einschränken. Trotzdem denke ich, dass UC Antipatterns die Fehlersuche unterstützen können.

9 Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL Relevanz Irrelevanten Details dürfen in Use Cases nicht dargestellt werden. Entscheidungen der Implementierung dürfen nicht vorweggenommen werden. El-Attar und Miller (2006) sagen aus, dass die Relevanz eines Use Cases verbessert werden kann. Sie begründen ihre Aussage leider nicht, aber ihr Antipattern zur Funktionalen Dekomposition könnte man als Beispiel zählen (siehe Kapitel 2.3.1). Bei der Funktionalen Dekomposition durch Verwendung der include -Beziehung werden Use Cases erzeugt, die die Freiheit bei der Implementierung einschränken. Diese zusätzlichen Use Cases müssten ihre Funktionalität in der Implementierung allen bereitstellen, obwohl sie nur bei einem Use Case verwendet werden und somit in diesen integriert werden könnten Konsistenz Es dürfen keine Widersprüche innerhalb einzelner Uses Cases und zwischen mehreren Use Cases entstehen. El-Attar und Miller (2006) betrachten die Konsistenz als eines der Qualitätsmerkmale, die verbessert werden können. Leider fehlt auch hier ihre Begründung. In ihrer Fallstudie zu den Use Case Antipatterns führen sie die Verknüpfung eines Akteurs mit einem erweiternden Use Case als Beispiel auf. Das ist ein Fehler, weil erweiternde Use Cases fast nie ohne ihren Basis Use Case ausgeführt werden können. Ich vermute die Inkonsistenz entstand in der Fallstudie, weil ein erweiternder Use Case mit einem Basis Use Case mit ähnlicher Funktionalität von den Entwicklern verwechselt wurde. Dadurch hätte dieser Use Case zwei unterschiedliche Bedeutungen. Insgesamt betrachte ich dir mir vorliegenden Informationen als nicht ausreichend, vertraue aber in diesem Fall den Ergebnis von El-Attar und Miller Verständlichkeit Use Cases sollen verständlich und nachvollziehbar sein. Außerdem sollten sie nach einer Vorlage definiert werden. El-Attar et al. (2006) erklären, dass die Verständlichkeit immer auch von Verbesserungen der Korrektheit, der Konsistenz und der Relevanz profitiert. Dieser Aussage kann ich mich anschließen. Unkorrekte und inkonsistente Use Cases verwirren den Betrachter, wenn die Fehler nicht offensichtlich sind oder zu viele Fehler im Diagramm vorkommen. Und unrelevante Elemente blähen die Use Case Diagramme unnötig auf. Reine Verbesserungen der Verständlichkeit durch UC Antipatterns sind aber vermutlich selten, weil die Darstellungsform des Diagramms nicht festgelegt ist Eindeutigkeit Es darf keinen Spielraum für verschiedene Interpretationen der Use Cases geben. Die Eindeutigkeit ist meiner Meinung nach bei Use Case Diagrammen durch den UML Standard gegeben. Missverständnisse können eher bei den Textbeschreibungen der Use Cases entstehen.

10 10 Christian Strempfer Vollständigkeit Die Use Cases müssen alle möglichen Anwendungsszenarien und alle notwendigen Daten beschreiben. Die Vollständigkeit der Diagramme kann meiner Meinung nach nur in einem sehr begrenzten Rahmen mit Antipatterns verbessert werden. Ohne Vergleich mit den realen Anforderungen, gibt es nur sehr wenige Elemente bzw. Beziehungen die notwendigerweise modelliert werden müssen. Beispielsweise könnte man nicht erkennen, ob einem Use Case absichtlich kein Akteur zugeordnet wurde oder ob er vergessen wurde. Denn laut UML Standard ist er keine Pflicht (vgl. Booch et al., 1998, p. 201f.). Weiteren Untersuchungen zur Verbesserung der Vollständigkeit mit UC Antipatterns sind mir nicht bekannt. Ich gehe davon aus, dass der Aufwand für den Vergleich aller riskanten Strukturen in Bezug auf die Vollständigkeit zu groß ist, um praxistauglich zu sein Umsetzbarkeit Das beschriebene Verhalten muss auf dem festgelegten System umsetzbar sein. Die Use Cases beschreiben nur das Verhalten des Benutzers und des Systems. Implementierungsdetails sind sogar verboten. Bei Use Case Diagrammen hat man auch keine Informationen über nicht-funktionale Anforderungen. Ohne Wissen über die geplante Implementierung kann man aber die Umsetzbarkeit der Use Cases nicht einschätzen. Meiner Meinung nach kann man die Umsetzbarkeit der Use Cases nicht direkt beeinflussen, auch wenn Use Cases von einer höheren Qualität dem Entwickler bei der Umsetzung helfen Änderbarkeit und Prüfbarkeit Die Änderbarkeit bezeichnet den Schwierigkeitsgrad von Änderungen an den Use Cases. Das heisst, sie sollen leicht zu ändern sein. Prüfbarkeit bedeutet, dass der Use Case mit dem daraus gebildeten System vergleichbar sein muss. Das heisst man muss prüfen können, ob das System die Anforderungen durch den Use Cases erfüllt. Zur Änderbarkeit und Prüfbarkeit von Use Cases liegen mir keine ausreichenden Informationen vor, deshalb möchte ich keine Beurteilung abgeben. Tabelle 3. Zusammenfassung der Verbesserungsmöglichkeiten bei Use Cases. Kriterium Korrektheit Vollständigkeit Relevanz Konsistenz Verbesserung ja nein ja (ja) Eindeutigkeit - Verständlichkeit ja

11 Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL 11 Umsetzbarkeit Änderbarkeit Prüfbarkeit nein unbekannt unbekannt 3 Object Constraint Language Es wurde geklärt welche Verbesserungsmöglichkeiten mit Use Case Antipatterns aufgedeckt werden können. In der Praxis ist es aber auch wichtig, dass man schnell und effizient nach ihnen suchen kann. Dazu müssen die Antipatterns Maschinenlesbar gemacht werden. Das könnte man beispielsweise mit Hilfe der Object Constraint Language erreichen, die in diesem Kapitel beschrieben wird. 3.1 Einführung Ich möchte hier nur einen kurzen Überblick über die Object Constraint Language (kurz: OCL) geben. Weitere Informationen enthält die OCL-Spezifikation der Object Management Group (2006). Der folgende Überblick basiert ebenfalls auf diesem Dokument. Die OCL ist Teil des Unified Modeling Language Standards. Sie ist eine Prädikaten-logische Sprache und wird als Ergänzung zur Modellierung eingesetzt, um Randbedingungen festzulegen. Die Hauptaufgaben der OCL sind die Beschreibung von Invarianten, die ein Modell erfüllen muss, und die Beschreibung von Abfragen über Objekte innerhalb eines Modells. Unter anderem können auch die Vor- und Nachbedingungen einer Methode mit der OCL beschrieben werden. Die OCL ist keine Programmiersprache. Das heisst die Ausführung von OCL- Ausdrücken ändert den Zustand des Systems nicht und verursacht keine Seiteneffekte. Die Auswertung der Ausdrücke ist atomar, der Systemzustand kann sich also nicht während der Auswertung verändern. 3.2 Aufbau der OCL-Ausdrücke Im folgenden werden Beispiele für OCL-Ausdrücke aufgeführt. Die kursiv gedruckten Teilausdrücke beziehen sich auf das verwendete Metamodell. In den Beispielen beziehe ich mich auf das Use Case Metamodell (siehe auch Kapitel 3.3), OCL kann aber auf jedes beliebige UML Klassendiagramm angewendet werden. Die Ausdrücke werden aus Sicht eines Objekts des Modells ausgewertet. Beispielsweise ist die Generalisierung für Use Cases und Akteure definiert und somit haben beide eine parent -Beziehung. Um unterscheiden zu können, welches Objekt gemeint, muss man den Kontext kennen.

12 12 Christian Strempfer context UseCase Der eigentliche OCL-Ausdruck wird durch ein Schlüsselwort eingeleitet. In diesem Bericht verwende ich nur Invarianten. Sie werden mit dem Schlüsselwort inv eingeleitet und müssen einen Ergebniswert vom Typ Boolean ergeben. Ausserdem kann im Anschluss an das Schlüsselwort jeder OCL-Ausdruck optional benannt werden. Zur Übersicht werde ich diesen Teil in den Beispielen unterstrichen. context UseCase inv AusdruckName: -- hier folgt ein OCL-Ausdruck Das Kontext-Objekt kann mit dem Ausdruck self verwendet werden. Attribute der Objekt können leicht abgerufen werden, indem man an den Objektnamen einen Punkt und den Attributnamen anhängt. Auf die gleiche Weise kann man durch das Diagramm navigieren. context Actor inv: self.parent.isabstract = false -- parent führt zum Elter des Akteurs -- isabstract ist ein Attribut dieses Akteurs Wenn man einer Assoziation folgt, die eine maximale Multiplizität größer eins hat, erhält man als Rückgabe eine Liste von Objekt-Instanzen. Auf diese Listen sind zusätzliche Operationen möglich. Size fragt ab, wie viele Objekte über eine Beziehung verbunden sind. NotEmpty überprüft, ob es überhaupt Objekte gibt, die über die betrachtete Beziehung verbunden sind. context Actor inv ZweiUndMehrKinder: self.child->notempty() and -- Hat die Instanz des Akteurs Kinder? self.child->size > 2 -- Hat die Akteur-Instanz mehr als zwei Kinder? Die OCL sehr umfangreich, deshalb ist es mir nicht möglich auf alles einzugehen. Diese kurze Einführung genügt aber, um die Beispiele in diesem Bericht zu verstehen. 3.3 Suche nach Use Case Antipatterns El-Attar et al. (2006) verwenden für die Suche nach Use Case Antipatterns ein vereinfachtes UML Metamodell (Bild 1) für ihr Werkzeug ARBIUM (Kapitel 3.4). Die ersten Antipatterns können so leicht definiert werden, für komplexere Aufgaben kann es aber auch erweitert werden. Bevor man OCL-Ausdrücke verwenden kann, muss man aber erst das Use Case Diagramm in ein Objekt Modell transformieren. El-Attar und Miller argumentieren, dass das möglich ist, weil jede Instanz eines Use Case Diagramms mit dem Use Case Metamodell übereinstimmt. Die Use Case Antipatterns lassen sich also mit Hilfe der OCL suchen. Dazu muss man der Teil, der unter Erkennung zu finden ist, formalisiert werden. Oft reichen

13 Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL 13 die Informationen aus den Diagrammen allerdings nicht aus, sodass die Ergebnisse nach der maschinellen Auswertung noch einmal von einem menschlichen Analysten überprüft werden müssen. Bild 1. Vereinfachtes Use Case Metamodell nach El-Attar et al. (2006) Use Case Antipattern: Funktionale Dekomposition Das Use Case Antipattern: Funktionale Dekomposition soll nun durch die Formalisierung in OCL vervollständigt werden. 1. Verwendung der include -Beziehung: Dieser OCL-Ausdruck sucht alle Use Cases die von genau einem Use Case inkludiert werden. context UseCase inv NotJustOneInclude: not (self.base->size = 1) 2. Vor- und Nachbedingungen als Ablaufsteuerung von Use Cases: Diese Variante kann nicht überprüft werden. Die Vor- und Nachbedingungen stehen in der Textbeschreibung der Use Cases. Ich gehe in diesem Bericht davon aus, dass die Textbeschreibungen nicht für OCL formalisiert werden. 3. Verwendung der extend -Beziehung: Hiermit werden alle Use Cases gesucht, die erweitert werden oder einen anderen erweitern. context UseCase inv ExtendingMoreThanOneUseCase: not (self.extended->size + self.extendeduc->size > 1) Weitere Use Case Antipatterns El-Attar und Miller (2006) haben noch weitere UC Antipatterns mit den dazugehörigen OCL-Beschreibungen zusammengetragen. Der Kontext ist immer das Objekt UseCase aus dem Metamodell (Bild 1). Zugriff auf einen generalisierten Use Case:

14 14 Christian Strempfer Ein Aktor hat Zugriff auf den übergeordneten Use Case einer Generalisierung, der unvollständige Funktionalität enthalten könnte. inv AccessingGeneralizedUseCaseByActor: not ( not self.isabstract and self.actorend->size > 0 and self.child->size > 0 ) Zugriff auf einen erweiternden Use Case: Ein Aktor greift auf einen erweiternden Use Case zu, obwohl dieser nicht alleinstehend ausgeführt werden kann. inv AccessingExtensionUseCaseByActor: not ( self.actorend->size > 0 and (self.extended->size > 0 or self.extendeduc->size > 0) ) Implementierung eines abstrakten Use Cases durch extend und include : Ein abstrakter Use Case ist Teil von include - oder extend -Beziehungen, obwohl abstrakte Use Cases nur durch die Generalisierung-Beziehung korrekt implementiert werden können. inv UsingIncludeAndExtendToImplementAbstractUC: not ( self.isabstract and (self.inclusion->size > 0 or self.extension->size > 0 or self.extensionuc->size > 0) ) Verknüpfung mehrerer Aktoren mit einem Use Case: Ein Use Case ist mit mehreren Aktoren verknüpft, die alle dieselbe Rolle spielen wenn der Use Case ausgeführt wird. inv MultipleActorsAssociatedWithUC: not (self.actorend->size > 1) Mehrfache Generalisierung eines Use Cases: Ein Use Case hatte mehrere Eltern, die er spezialisiert. inv MultipleGeneralizationsOfOneUC: not (self.parent->size > 1) Zugriff auf einen abstrakten Use Case, der nicht implementiert wurde: Ein Akteur ist mit einem abstrakten Use Case verknüpft, der durch keinen weiteren Use Case implementiert wird. inv AccessingUnimplementedAbstractUC: not ( self.isabstract and self.actorend->size > 0 and self.child->size = 0)

15 Use Case Antipatterns: Erkennung typischer Fehlermuster mit Hilfe der OCL Automated Risk-Based Inspection of UC Models El-Attar und Miller (2006) haben das Werkzeug Automated Risk-Based Inspection of UC Models (kurz: ARBIUM) entwickelt. Es wertet die in OCL formalisierten Ausdrücke aus und zeigt die möglichen Fehlerstellen auf. Wie bereits erwähnt suchen sie nach riskanten Strukturen, die Fehler enthalten können, aber nicht enthalten müssen. Der Analyst muss bei jedem Treffer entscheiden, ob es sich um einen Fehler handelt. Das ist ein Nachteil, denn so werden auch Antipatterns aufgelistet, die immer Fehler sind und automatisch korrigiert werden könnten. Der Vorteil von ARBIUM ist, dass man keine Antipatterns übersieht und viel Zeit sparen kann. Bei der Suche durch einen Menschen dagegen, würde die Trefferquote und der Zeitaufwand stark von den Fähigkeiten des Analysten abhängen. 4 Bewertung und Folgerungen Antipatterns werden bereits in anderen Bereichen eingesetzt. Die Use Case Modellierung ist auch sehr beliebt und deshalb lohnt sich meiner Ansicht nach die Suche nach typischen Fehlermustern in den Use Cases. Grobe Fehler könnten so früh in der Entwicklung korrigiert werden und damit Kosten sparen. Selbst wenn sie nur zu Schulungszwecken eingesetzt werden können, ist das ein Gewinn für die Entwickler. Leider gibt es noch keine Untersuchungen über Antipatterns für die Textbeschreibungen der Use Cases. Die Beschränkung auf die Diagramme, lässt nur sehr wenig Raum für Verbesserungen. Und Use Case Antipatterns sind nur ein Mittel zur Qualitätssicherung und können nur in Kombination mit herkömmlichen Techniken wie dem Review eingesetzt werden. Die Auswirkungen auf die Qualität der fertigen Software wurde bisher leider auch nur oberflächlich untersucht. Man müsste beobachten wie sie sich im Praxiseinsatz auswirken. Ausserdem ist der effiziente Einsatz ist auch nur mit einem geeigneten Werkzeug möglich. Die Formalisierung mit OCL ist recht einfach, aber leider können nicht alle Antipatterns eindeutig identifiziert werden. Ein Grund dafür ist wieder die Beschränkung auf Use Case Diagramme. Die Textbeschreibung der Use Cases enthält sicher einen viel größeren Teil der Mängel. Man müsste nachforschen, in wie weit man diese mit Hilfe der OCL formalisieren könnte. Aber vermutlich ist der Aufwand zu groß und eine linguistische Analyse wären besser geeignet. Wenn man diese Einschränkungen akzeptiert, kann man ARBIUM für die Suche der Antipatterns einsetzen. Es bietet viele Erweiterungsmöglichkeiten für den professionellen Einsatz, sodass man beispielsweise auch eigene Antipatterns einsetzen könnte. Leider können Antipatterns nicht so festgelegt werden, dass sie immer Fehler darstellen und keine zusätzliche Analyse erfordern. Außerdem wäre eine Integration in die Modellierungswerkzeuge wünschenswert. Abschließend kann ich sagen, dass Antipatterns auch im Bereich der Use Case Modellierung sinnvoll wären. Die Analyse der Diagramme alleine reicht allerdings

16 16 Christian Strempfer nicht, die Textbeschreibungen müssten ebenfalls einbezogen werden. Deshalb sollte man nach Alternativen zur Formalisierung mit OCL suchen, denn die Möglichkeiten der Werkzeuge hängen stark von dieser ab. 5 Literatur Christopher Alexander (1964): Notes on the synthesis of form. Harvard University Press. Cambridge. William Brown, Raphael Malveau, Hays McCormick (1998): Anti-Patterns Refactoring Software, Architectures and Projects in Crisis. John Wiley & Sons Inc. Grady Booch, James Rumbaugh, Ivar Jacobson (1998): The Unified Modeling Language User Guide. Addison Wesley. Christian Denger, Barbara Paech, Bernd Freimut (2005): Achieving high quality of use-casebased requirements. Springer Verlag. Berlin / Heidelberg. Mohamed El-Attar, James Miller (2006): Matching Antipatterns to Improve the Quality of Use Case Models. 14th IEEE International Requirements Engineering Conference. J.M. Fuentes, V. Quintana, J. Llorens, G. Genova, R. Prieto-Diaz (2003): Errors in the UML Metamodel? ACM SIGSOFT Software Engineering Notes. Volume 28 Issue 6. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994): Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Inc.. Boston, MA, USA. Connie Smith, Lloyd Williams (2000): Software Performance Antipatterns. Proceedings of the 2nd international workshop on Software and performance. ACM. New York, USA.