Entwicklung verteilter eingebetteter Systeme. Visual Variability Analysis for Goal Models

Transkript

1 Ausarbeitung für das Seminar Entwicklung verteilter eingebetteter Systeme zum Thema Visual Variability Analysis for Goal Models Maximilian Schwerin 1 Technische Universität Berlin maximili@cs.tu-berlin.de Matthias Weber (Betreuer) DaimlerChrysler AG matthias.n.weber@daimlerchrysler.com 24. Februar Matrikelnummer:

2 Inhaltsverzeichnis 1 Einleitung 1 2 Variabilitätsanalyse 2 3 Das Variabilitätsmodell 2 4 Ein Beispiel 3 5 Die Analysemethode Erstellen des Variabilitätsmodells Korrelieren der funktionalen und nicht-funktionalen Ziele Setzen von Prioritäten Berechnen der Ergebnisse Auswerten der Ergebnisse Bewertung der Methode und des Prototyps 10 Abbildungsverzeichnis 1 Baum des funktionalen und des nicht-funktionalen Submodells Der Analyse Prozess Verteilung der Prioritäten auf nicht-funktionale Ziele Konflikte und globale Befriedigung der Varianten Diagramme des in [1] verwendeten Beispiels I

3 1 EINLEITUNG 1 1 Einleitung In dieser Arbeit wird die in [1] vorgestellte Methode zur visuellen Analyse von Variabilitäten betrachtet. Es wird ein Überblick über den Analyseprozess gegeben und eine Bewertung der Analysemethode und des entwickelten Prototypen vorgenommen. In den Abschnitten 2 und 3 werden kurz die Bedeutung der Variabilitätsanalyse erklärt und das benutzte Variabilitätsmodell vorgestellt. In Abschnitt 4 wird ein Beispiel vorgestellt, welches in Abschnitt 5 genutzt wird, um die Analysemethode zu erläutern. In Abschnitt 6 werden dann die Methode sowie der Prototyp auf ihre Nutzbarkeit hin untersucht und bewertet.

4 2 VARIABILITÄTSANALYSE 2 2 Variabilitätsanalyse Variabilität ist die Möglichkeit ein System zu ändern oder anzupassen. Variabilität in einem System zu erhöhen, macht es einfacher bestimmte Änderungen an diesem System durchzuführen [3]. Gleichzeitig führt größere Variabilität dazu, dass ein System schwieriger zu durchschauen ist. Je nach Kontext ist demnach mehr oder weniger Variabilität in einem System wünschenswert. Variabilität tritt vor allem in zwei Zusammenhängen auf: der Zielorientierten Anforderungsanalyse und im Management von Software-Produktlinien. Während die Variabilitätsanalyse bei der Zielorientierten Anforderungsanalyse ermittelt, welche Anforderungsvariante in dem Produkt realisiert werden soll, geht es bei Software- Produktlinien darum zu entscheiden, welche Untermenge der Anforderungen im jeweiligen Produkt der Produktlinie implementiert wird. Die hier vorgestellte Analysemethode hat zum Ziel aus einer großen Menge an Varianten diejenigen herauszufinden, die eine gute (good-enough) Lösung darstellen. 3 Das Variabilitätsmodell Das in [1] verwendete Variabilitätsmodell ist eine eingeschränkte Version des in [2] vorgestellten Modells. Es besteht aus zwei Submodellen. Ein Submodell beschreibt funktionale Anforderungen und Ziele, die das System am Ende erfüllen wird. Das zweite Submodell enthält nicht-funktionale Randbedingungen, an die sich das System halten soll. Nicht-funktionale Ziele können sich z.b. mit QoS oder anderen Qualitätsmerkmalen beschäftigen. Beide Submodelle werden unter Verwendung von UND/ODER Bäumen dargestellt. Jeder ODER-Zweig im Baum des funktionalen Submodells stellt hierbei eine mögliche Variante der zukünftigen Software dar.

5 4 EIN BEISPIEL 3 4 Ein Beispiel Die Analysemethode aus [1] soll in Abschnitt 5 an einem konkreten Beispiel vorgestellt werden. Dieses Beispiel soll hier nun kurz beschrieben werden. Da Toll Collect als großes System in letzter Zeit viel Aufmerksamkeit in den Medien erhalten hat und somit hinreichend bekannt sein sollte, soll ein kleiner Ausschnitt seiner Funktionalität als Basis für dieses Beispiel dienen. Speziell wurde der Vorgang des Einbuchens einer Fahrtroute gewählt. Toll Collect bietet zwei Möglichkeiten eine Fahrtroute einzubuchen: automatisches und manuelles Einbuchen. Das automatische Einbuchen erfolgt über ein im Fahrzeug installiertes Gerät, welches die gefahrenen Kilometer automatisch per Mobilfunk an Toll Collect übermittelt. Beim manuellen Einbuchen kann die geplante Fahrtroute an einem der Mautstellen-Terminals oder über das Internet gebucht werden. Abbildung 1: Baum des funktionalen und des nicht-funktionalen Submodells Die Möglichkeiten des Einbuchens (automatisch, Mautstellen-Terminal, Internet) stellen die funktionale Ziele des Systems dar. Um eine möglichst große Variabilität zu erzeugen, werden nur ODER-Verknüpfungen verwendet. Als nicht-funktionale Randbedingungen werden eine einfache Bedienbarkeit durch die Benutzer und das Entstehen möglichst geringer Kosten beim Vorgang des Einbuchens für Betreiber wie für Benutzer gefordert (siehe Abbildung 1).

6 5 DIE ANALYSEMETHODE 4 5 Die Analysemethode Die hier vorgestellte Methode hat zum Ziel das Analysieren von Systemen mit großer Variabilität zu erleichtern. Um dies zu unterstützen, werden dem Analysten Diagramme zur Verfügung gestellt, die ihm helfen sollen aus allen möglichen Varianten diejenige auszuwählen, die den Anforderungen am besten entspricht. Abbildung 2: Der Analyse Prozess Die Methode unterteilt sich für den Analysten in mehrere Schritte (siehe auch Abbildung 2): 1. Erstellen des Variabilitätsmodells 2. Korrelieren der funktionalen und nicht-funktionalen Ziele 3. Prioritäten im nicht-funktionalen Submodell setzen 4. Analysieren der Ergebnisse Die einzelnen Schritte der Methode werden nun jeweils an dem in Abschnitt 4 vorgestellten Beispiel erläutert. 5.1 Erstellen des Variabilitätsmodells Bevor mit dem Analyseprozess begonnen werden kann, muss zunächst das Variabilitätsmodell (siehe Abschnitt 3 erstellt werden. Dies ist Aufgabe des Domain Experts. Die

7 5 DIE ANALYSEMETHODE 5 von ihm erstellten Submodelle werden zunächst als UND-/ODER Bäume dargestellt (siehe Abbildungen 1). Automatisch Mautstelle Internet geringe Kosten Benutzer Betreiber einfache Bedienbarkeit Tabelle 1: Linearisierte Submodelle Um die beiden Submodelle in eine von einem Algorithmus lesbare Form zu bringen, wählten die Autoren von [1] eine Tabelle als Darstellungsform. Die Bäume der beiden Submodelle werden dazu linearisiert. Das heißt, die funktionalen Ziele benennen die Zeilen, während die nicht-funktionalen Ziele die Spalten benennen (siehe Tabelle 1). 5.2 Korrelieren der funktionalen und nicht-funktionalen Ziele Die erste Aufgabe des Variant Analyst ist es die Ziele des funktionalen mit Zielen des nicht-funktionalen Submodells zu korrelieren. Hierzu werden die in [4] beschriebenen Relationen verwendet (siehe Tabelle 2). Zerstört Schadet Unbekannt Fördert Erfüllt qualitativ? + ++ quantitativ (0/-1) (0/-0.5) (0/0) (0.5/0) (1/0) Tabelle 2: Bezeichner für Korrelationen (nach [4]) Diese Korrelationen erlauben es später zu errechnen, welche Variante den gewünschten Anforderungen am besten entspricht. Zu beachten ist, dass Korrelationen nur zwischen Zielen der verschiedenen Submodelle erlaubt sind. Innerhalb eines Submodells sind keine Korrelationen zulässig. Das funktionale Ziel Einbuchen via Internet des Beispiels erfüllt so z.b. das nichtfunktionale Ziel geringe Kosten für den Betreiber, während das funktionale Ziel auto- matisches Einbuchen das nicht-funktionale Ziel geringe Kosten für den Benutzer zerstört. Der Variant Analyst wird zunächst die für ihn besser lesbaren qualitativen Bezeichner verwenden. Diese trägt er in die bereits vorbereitete Tabelle mit den linearisierten Submodellen ein (siehe Tabelle 3).

8 5 DIE ANALYSEMETHODE 6 geringe Kosten Benutzer Betreiber einfache Bedienbarkeit Automatisch - ++ Mautstelle + - Internet Tabelle 3: Korrelierte Submodelle Die qualitativen Bezeichner werden im Anschluss der besseren Verarbeitbarkeit halber in quantitative Werte konvertiert (siehe Tabelle 2). Der erste Wert der quantitativen Tupel entspricht jeweils der Erfüllbarkeit (SAT) des nicht-funktionalen Zieles, während der zweite Wert der Abstreitbarkeit (DEN) entspricht. 5.3 Setzen von Prioritäten Bevor nun die eigentliche Analyse beginnt, wird dem Variant Analyst die Möglichkeit gegeben Prioritäten im nicht-funktionalen Submodell zu setzen. Hierzu erhalten einige oder alle nicht-funktionalen Ziele prozentuale Wichtungen. Abbildung 3: Verteilung der Prioritäten auf nicht-funktionale Ziele So kann z.b. das nicht-funktionale Ziel geringe Kosten für den Benutzer als wichtiger betrachtet werden als geringe Kosten für den Betreiber. Dies ließe sich dadurch erreichen, dass dem wichtigeren Ziel eine Wichtung von z.b. 35% gegeben wird, während dem unwichtigen Ziel nur 15% zugewiesen wird. Als wichtigstes Ziel wird einfache Bedienbarkeit betrachtet. Diesem wird 50% zugewiesen.

9 5 DIE ANALYSEMETHODE Berechnen der Ergebnisse Mit dem Setzen der Prioritäten im nicht-funktionalen Modell ist die Arbeit des Variant Analyst zunächst getan. Der in [1] vorgestellte Prototyp errechnet nun zunächst alle Varianten, die aus dem funktionalen Modell erstellbar sind. Für das Beispiel ergeben sich dabei die folgenden Varianten: 1. (Automatisch) 2. (Internet) 3. (Mautstelle) 4. (Internet, Mautstelle) 5. (Automatisch, Internet) 6. (Automatisch, Mautstelle) 7. (Automatisch, Internet, Mautstelle) Zu jeder dieser Varianten werden nun die Werte für Erfüllbarkeit (SAT) und Abstreitbarkeit (DEN) durch den Baum des nicht-funktionalen Submodells propagiert. Dies geschieht unter Verwendung des in [5] vorgestellten Verfahrens. Der Algorithmus wurde allerdings so vereinfacht, dass keine Zyklen zugelassen sind. Die Prioritäten werden nun genutzt um für jede Variante einen globalen Wert für Befriedigung der nicht-funktionalen Ziele zu errechnen. 5.5 Auswerten der Ergebnisse Der Prototyp erstellt als Ausgabe sechs Diagramme. Die zwei wichtigsten Diagramme sollen hier näher betrachtet werden (siehe Abbildung 4). Das erste Diagramm zeigt die Anzahl der Konflikte, die in der jeweiligen Variante aufgetreten sind. Ein Konflikt tritt dann auf, wenn sowohl der Wert für SAT wie auch der Wert für DEN eines nicht-funktionalen Zieles ungleich Null sind. Das zweite Diagramm zeigt die globale Befriedigung pro Variante. Die globale Befriedigung ist die Summe der gewichteten Werte für Befriedigung (Wert für SAT minus DEN) aller nicht-funktionalen Ziele. Dieses Diagramm gibt einen ersten Eindruck der besten

10 5 DIE ANALYSEMETHODE 8 Abbildung 4: Konflikte und globale Befriedigung der Varianten Variante. Es ist allerdings zu beachten, dass eine Variante mit einem großen Wert für globale Befriedigung aber vielen Konflikten wie z.b. Variante 5 nicht wünschenswert ist, da hierbei einige der nicht-funktionalen Ziele sowohl als erfüllt wie auch als zerstört gelten. Findet sich in den Diagrammen keine Variante, die den gewünschten Anforderungen entspricht kann der Variant Analyst iterativ die Prioritäten neu setzen oder auch die Korrelationen zwischen den Submodellen neu definieren. Abbildung 5: Diagramme des in [1] verwendeten Beispiels

11 5 DIE ANALYSEMETHODE 9 Abbildung 5 zeigt die Ergebnisse des in [1] verwendeten Beispiels. Zu den beiden bereits besprochenen Diagrammen kommen noch vier weitere hinzu, die z.b. die Verteilung der Prioritäten oder den Beitrag einzelner nicht-funktionaler Ziele zu der Anzahl an Konflikten darstellen.

12 6 BEWERTUNG DER METHODE UND DES PROTOTYPS 10 6 Bewertung der Methode und des Prototyps Die Methode stellt eine einfache Weise dar aus einer großen Anzahl von Varianten diejenige auszuwählen, die den funktionalen und nicht-funktionalen Anforderungen an ein System am besten entspricht. Die Autoren von [1] mussten, um ihren Prototypen implementieren zu können, einige Einschränkungen akzeptieren. So ist das Variabilitätsmodell wesentlich stärker eingeschränkt als andere Modelle, wie z.b. i* [6] oder die in [5] verwendeten Modelle. Auch schränkt Microsoft Excel, das als Basis für die Implementierung des Prototypen gewählt wurde, die Anzahl an verarbeitbaren Varianten ein, da die maximale Anzahl an Zeilen bei liegt. Das von den Autoren verwendete Beispiel hatte 40 funktionale und 16 nicht-funktionale Ziele, was bereits zu beinahe 4000 Varianten führte. Bei dieser großen Anzahl an Varianten kann in Excel selbst bei maximalem Zoom (400%) nur noch wenig auf einem Standardbildschirm erkannt werden. Da die Anzahl an Varianten exponentiell mit dem Hinzufügen neuer Ziele wächst, steigt entsprechend auch der Aufwand, die Berechnungen durchzuführen. Das heißt, dass es notwendig ist effiziente Implementierungen der Algorithmen zu nutzen, soll eine große Anzahl an Varianten berechnet werden. Leider war es beim Erstellen dieser Arbeit nicht möglich den Prototypen zu testen, da vermutlich aufgrund von Inkompabilitätsproblemen zwischen verschiedenen Version von Excel nicht behebbare Fehler auftraten. Aus dem vorliegenden Wissen lässt sich aber schließen, dass sowohl die Methode, besonders aber der Prototyp eher für Systeme mit wenig Variabilität geeignet sind.

13 LITERATUR i Literatur [1] B. Gonzalez-Baixauli, J.C. Sampaio do Prado Leite, J. Mylopoulos, Visual Variability Analysis for Goal Models, Proc. RE 04-12th IEEE International Requirements Engineering Conference [2] J. Mylopoulos, L. Chung, E. Yu, B. Nixon, Representing and Using Non-functional Requirements: A Process-Oriented Approach, IEEE Trans. on SW Eng. 18(6), June 1992, pp [3] J. van Gurp, M. Svahnberg, J. Bosch, On the notion of variability in software product lines, chapter in System Family Variant Configuration and Derivation, N. Farcet (editor), wp3 of the ESI ESAPS (Engineering Software Architectures, Processes and Platforms for System-Families) project, thales wp , May 2001 [4] L. Chung, B. Nixon, E. Yu, J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000 [5] P. Giorgini, J. Mylopoulos, E. Nicchiarelli, R. Sebastian, Reasoning with goal model, Proc. ER 02, Tampere, Finland, October 2002 [6] E. Yu, Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering, Proc. RE 97, January 1997