Test von Use Case basierten Produkt Linien mit dem PLUTO Ansatz ( Version 0.9 )

Transkript

1 Test von Use Case basierten Produkt Linien mit dem PLUTO Ansatz ( Version 0.9 ) Frederik Eichler, mail@frederik-eichler.de 1. Juli 2008 Universität Paderborn Seminar Software-Qualitätssicherung bei Prof. Dr. Gregor Engels betreut von Andreas Wübbeke i

2 Zusammenfassung Produktlinien werden in der Industrie eingesetzt um bei steigender Produktvielfalt gleichzeitig Kosten zu sparen, indem ähnliche Produkte zu einer Linie zusammengefasst werden. Beim Test dieser Produkte müssen neben den Gemeinsamkeiten, auch die Unterschiede getestet werden. PLUTO [2] stellt hierbei einen Ansatz dar, bei System- und Abnahmetests auch die Unterschiede innerhalb einer Produktlinie abzudecken. Im Zuge der Arbeit wird der Begriff der Produktlinie eingeführt und die Idee des Tests von Produktlinien mit Use Cases und dem PLUTO Ansatz erläutert, sowie ein Ausblick auf zukünftige Herausforderungen in diesem Forschungsbereich gegeben. Inhaltsverzeichnis 1 Einführung 1 2 Produktlinien Varianten und Variationspunkte Ausprägungen Product Line Use Cases Beschreibung Ablauf Variationen Einordnung im Entwicklungsprozess PLUTO Kategorisierung Instanzierung Ausblick PLUTO Produktlinien ii

3 1 Einführung Als US-Amerikanische Automobilhersteller in den Jahren 1980 bis 1991 auf eine best platform strategie umstellten [5], erhöhten sie damit ihren Umsatz um 35%. Diese Strategie basierte auf der Prämisse, dass durch die Nutzung einer gemeinsamen Basis oder auch Plattform die Produktion der Fahrzeuge vergünstigt werden kann. Zwar bedeutete dies für die Automobilhersteller ein höheres Anfangsinvestment für das Entwickeln einer Plattform, im Gegenzug aber auch, dass dem Verbraucher besser an seine Wünsche angepasste Fahrzeuge angeboten werden konnten. Diese Flexibilität ist laut Pohl et. al [5] die Vorraussetzung für mass customisation und bietet für diese Arbeit als Begriff der Variabilät eine wichtige Grundlage. Überträgt man diesen Begriff der Platform von der Automobilindustrie in die Softwareentwicklung, so ergibt sich laut Meyer & Lehnerd [7] folgende Definition einer Software Plattform: A software platform is a set of software subsystems and interfaces that form a common structure from which a set of derivative products can be efficiently developed and produced Wie bereits im obigen Beispiel angedeutet, bringt der Einsatz einer Plattform allerdings nicht nur erhöhte Flexibilität, sondern auch Kosten um eine neue Plattform oder Produktlinie zu etablieren mit sich. In diesem Zusammenhang stellt sich auch die Frage wie die Qualität der einzelnen Produkte einer Produktlinie mit relativ geringem Aufwand, etwa durch genau definierte Tests, sichergestellt werden können. Neben Produktlinie ist auch der Begriff der Produktfamilie [2] geläufig und wird hier synonym verwendet. Im Folgenden soll der Begriff der Produktlinie genauer erklärt und darauf eingegangen werden, wie Produkte einer solchen Linie auf Korrektheit getestet werden können. Dazu soll der PLUTO Ansatz genauer erklärt werden, der mit einer semi-formalen Notation die Abdeckung des Tests aller Varianten, die in einer Produktlinie entstehen können, sicher stellen soll. Einzelne Vorgänge werden dabei in natürlicher Sprache beschrieben. 1

4 2 Produktlinien Eine Produktlinie umfasst nach [6] mit einander verwandte Produkte und setzt sich aus einer Sammlung von Elementen, die alle Produkte einer Linie gemeinsam haben ( mandatory elements ), sowie Variationspunkten ( variation points ), an denen sich die Produkte unterscheiden, zusammen. Vorteile einer Produktlinie sind nach Pohl et al. [5] unter anderem die erhöhte Qualität des Produkts durch den Einsatz von Artefakten in mehreren Produkten und außerdem die kürzeren Entwicklungszyklen, also die Zeit bis ein Produkt Marktreife erlangt. Zudem ist es aufgrund der Vergleichbarkeit der Produkte einer Linie einfacher Kostenabschätzungen für neue Produkte zu geben. Zuletzt erhält auch der Kunde einen direkten Vorteil, nämlich ein an seine Bedürfnisse angepasstes Produkt zu einem annehmbaren Preis. Wie bereits dargelegt liegen die Nachteile einer Produktlinie unter anderem in den Investments, die zum Aufbau einer Produktlinie notwendig sind, so dass die Amortisationszeit eines einzelnen Produktes innerhalb der Produktlinien zunächst entsprechend länger als die eines einzelnen Produktes ist. Besonders das Testen einer Produktlinie stellt hier eine Herausforderung dar, da die erreichte Flexibilität für jedes Produkt unterschiedliche Features bedeutet und diese alle einzeln beim Test berücksichtigt werden müssen. Der Begriff der Flexibilität wird fortan auch als Variabilität bezeichnet und steht im Fokus des PLUTO Ansatzes, der im Folgenden weiter erläutert werden soll. Hauptvorraussetzung um den Einsatz einer Produktlinie möglich zu machen ist, dass die Domäne aus der die Produktlinie entstammt eindeutig definiert ist. Ist die Domäne zu weit gefasst, das heißt die Produkte einer Linie haben nur wenig Gemeinsamkeiten, wird der Einsatz zu aufwändig und die Anzahl an Varianten zu groß, beziehungsweise der Nutzen durch die Wiederverwendbarkeit schwindet. 2.1 Varianten und Variationspunkte Um den Begriff Variante definieren zu können, müssen zunächst der Begriff Variationspunkt erklärt werden. Hierunter verstehen Böckle et al. [1] die Stelle an der die Auswahl einer oder mehrerer Varianten möglich ist. Eine Variante beschreibt dann die konkrete Ausprägung in Bezug auf einen oder mehrere Variationspunkte. Für die Variabilität ergeben sich laut [1] verschiedene Abhängigkeiten, die im Zusammenhang mit PLUTO in erläutert werden. Optionale Beziehungen, etwa die sprachliche Unterstützung von Sehbehinderten in der Softwareumgebung erlauben es Features in einem Produkt der Linie zu 2

5 Ausprägung Features Ablauf Datenumfang Datenformat Systemzugang Benutzerschnittstelle Systemschnittstelle Qualität Beispiel Zahlung per Kreditkarte Reihenfolge des Bestellvorgangs Benötigte Datenbasis für den Bestellvorgang Anzahl der Dezimalstellen beim Rechnungsbetrag Zugang zum System etwa über das Internet, Telefon sprachlich, textuelle, mediale Führung Customer Relationship Management, Warenwirtschaft, Legacy Systems Ansprüche an Sicherheit, Performanz, Vefügbarkeit, etc. Tabelle 1: Ausprägungen von Variabilität in Produktlinien verwenden und in anderen zu vernachlässigen. Alternative Beziehungen bieten die Möglichkeit eine von mehreren Variationen fest zu wählen, etwa die Entscheidung auf 2 Dezimalstellen zu runden. Pflichtbeziehungen müssen in jedem Produkt der Linie auftauchen und Ausschlussbeziehung erlauben zu definieren, dass ein genau spezifiziertes Feature nicht auftreten darf. Als Beispiel lässt sich hier die 24 Stunden Verfügbarkeit eines Banksystems nennen, die der Tatsache widerspricht, dass Buchungen nur offline durchgeführt werden können. Zudem kann die Beziehung zwischen Varianten durch sog. Constraints, wie in [1] erläutert, beschrieben werden. Requires-Beziehungen erzwingen das Vorhandensein einer Variante A, bevor eine Variante B erlaubt wird. Excludes-Beziehungen schließen genau dieses gemeinsame Auftreten aus Ausprägungen Variabilität kann in verschiedenen Ausprägungen [1] ( Tabelle 1 ) in einer Produktlinie auftreten. So können sich zum Beispiel die Features ( z.b. mögliche Zahlweisen in einem Online Shop ) eines Produktes unterscheiden. Auch im Ablauf, also zeitlich, kann es Abweichungen unter den Produkten geben. So mag bei einem Online Shop etwa die Angabe der Adresse vor oder nach der Zahlungsart kommen. Die beschriebenen Ausprägungen können nun weitere Variationen ( Tabelle 1) bedingen, die sich etwa im benötigten Datenumfang bei der Kreditkartenzahlung wiederspiegeln. 3

6 Schlüssel Goal Scope Level Precondition Trigger Primary Actor Secondary Actors Wert Play a game on a [V0] Mobile Phone and record score The [V0] Mobile Phone Summary The [V0] Mobile Phone is on Function GAMES has been selected from the main menu The Mobile Phone user The [V0] Mobile Phone, The Mobile Phone Company 2.2 Product Line Use Cases Tabelle 2: Beschreibung des Use Cases Der in dieser Arbeit dargestellte Ansatz zum Testen von Produktlinien basiert auf der Nutzung sog. Product Line Use Cases ( PLUC ), welche in semi-formaler Notation die Abläufe innerhalb der Software wiederspiegeln und zusätzlich die verschiedenen Ausprägungen von Produkten innerhalb der Produktlinie abbilden. Zur Veranschaulichung wird hier ein Beispiel-Use Case, wie in [2] eingeführt vorgestellt. Um die Komplexität des Beispiels zu reduzieren, wird das Use Case im Folgenden in drei Teilen erklärt. Variationspunkte sind hierbei in eckigen Klammern ( [VX ] ) dargestellt. Beim Beispiel handelt es sich um eine Produktlinie eines Mobiltelefonanbieters, der drei Modelle mit unterschiedlichen Ausstattungsmerkmalen, wie etwa der Möglichkeit Spiele zu spielen, anbietet. Des weiteren unterscheiden sich die Produkte in der Möglichkeit das Internet zu nutzen Beschreibung Der erste Abschnitt dieses Product Line Uses Cases, dargestellt durch Tabelle 2 enthält Informationen über den Zweck des Use Cases sowie welche Bedingungen und Aktoren mitwirken. Hier wird zwischen primary actor und secondary actor unterschieden. Letzterer interagiert zwar mit dem System, kann aber nicht den Use Case auslösen. An dieser Stelle wird bereits die Variabilität eingeführt, indem auf den Variationspunkt [V0] ( Art des Mobiltelefons ) Bezug genommen wird. 4

7 2.2.2 Ablauf Der zweite Teil des PLUC beschreibt den Ablauf des Use Cases als main success scenario, sowie mögliche Erweiterungen. Hier unterscheidet sich das PLUC nicht vom UML Use Case. 1. The system displays the list of the [V1] available games 2. The user selects a game 3. The user selects the difficulty level 4. The user starts the game and plays it until completion 5. The user records the score achieved [V 2 ] and sends the score to Club XXX via WAP Erweiterungen beschreiben, wie auch in UML üblich, welche zusätzlichen Use Cases oder Aktionen durch den Benutzer ausgelöst werden können. In diesem Beispiel wird berücksichtigt, dass während des Spielens ein Anruf über das Mobiltelefon angenommen werden kann. 1a. No game is available: 1a1. return to main menu 3a. The user starts the game and plays i t until an incoming call arrives. See CallAnswer Variationen Im Gegensatz zur Ablaufbeschreibung ( ), die mögliche Handlungsvarianten für den Benutzer bietet, stellt die folgende Liste Variationen innerhalb der Produktlinie dar. Somit kommt ihr essentielle Bedeutung für die Ableitung von Tests für ein spezifisches Produkt zu. Hier kommen auch die unter beschriebenen Abhängigkeiten zum Einsatz. Hier mögliche Variationen sind die Nutzung unterschiedlicher Mobiltelefone ( alternative Beziehung aus 2.1 ), Model 0 Model 1 5

8 Model 2 welche das Spielen von unterschiedlichen Spielen erlauben ( alternative Beziehung aus 2.1 ). i f V 0 = 0 then d i s p l a y msg no game a v a i l a b l e e l s e i f V0=1 then Snake I I o r Space Impact e l s e i f V0=2 then Snake I I o r Space Impact o r Bumper. Zudem ist es möglich, falls die Variante V0 den Wert 2 hat ein optionales Feature zu nutzen. Dies wird im PLUC durch das Schlüsselwort when ausgedrückt. Ein Beispiel hierfür findet sich auch in Abschnitt 3.1. V2: Optional when V0= Einordnung im Entwicklungsprozess Will man die Verwendung von PLUC und PLUTO im Entwicklungsprozess einordnen, so ergibt sich für das V-Modell die Abbildung 1. Wie in der Grafik zu sehen ist, stehen sich PLUC und PLUTO im V-Modell direkt auf den obersten zwei Ebenen gegenüber. Diese frühe Einordnung im Entwicklungsprozess wird leicht verständlich wenn man sich die Struktur der in Abschnitt 2.2 beschriebenen PLUC ansieht. Hier werden allgemeine Vorgänge und Produktmerkmale beschrieben und keine Entscheidungen über die zu benutzende Softwarearchitektur oder Programmstruktur gefällt. Aufgrund der Natur der PLUC ist hier festzustellen, dass PLUTO - welches aus PLUCs abgeleitet wird - nur für die Tests in der höheren Abstraktionsebene, also bei System- und Abnahmetests zum Einsatz kommt. 6

9 PLUC Anforderungsanalyse PLUTO Abnahme-Test / Nutzung System-Architektur System-Integration System-Entwurf Integrations-Tests Software-Architektur Unit-Tests Software-Entwurf Abbildung 1: PLUC und Pluto im V-Modell 3 PLUTO Grundlage für den PLUTO Ansatz zum Test von Produktlinien bietet die Category Partion Methode ( kurz: CP ) [Ostrand et al., 1988]. CP basiert darauf, funktionale Einheiten für mögliche Tests zu identifizieren und für jede Testeinheit eine Kategorisierung festzulegen und weiter in choices, also Auswahlmöglichkeiten aufzuteilen. Im Folgenden wird dieser Ansatz exemplarisch dargestellt und der Einsatz von CP verdeutlicht. 3.1 Kategorisierung Um mit Hilfe von Category Partition zu einer Kategorisierung zu gelangen wird hier das Beispiel der drei Mobiltelefone aus 2.2 bemüht. Folglich gelangt [4] zu folgenden Kategorien, welche die Variationspunkt in dieser Produktlinie darstellen: Mobile Phone Model 7

10 Games Difficulty Level Scenarios Club Mit dieser Liste von zu berücksichtigenden Kategorien kann eine Anzahl der choices abgeleitet werden, die in der PLUC Gameplay Test Specification ( Abb. 2 ) notiert wird. Um die Verfügbarkeit ( siehe 2.1 ) einer choice innerhalb der Kategorie auszudrücken, wird im Folgenden mit dem [IF..] Selektor markiert. Kategorien werden bei PLUTO auch als Tags bezeichnet, da sie im Verlauf des Ansatzes mit Werten belegt ( 3.2 ) und somit Testfälle abgeleitet werden. Abbildung 2: PLUC Gameplay Test Specification Wie in Abbildung 2 dargestellt, sind nicht alle choices für alle Mobiltelefone verfügbar. Games sind für das Modell 0 gar nicht verfügbar und alle Spiele, sind nur mit dem Modell 2 abrufbar. Ein Beispiel für eine optionale Kategorie findet sich unter [V2] Club, welches nur bei P2 genutzt werden kann, welches über eine Internetverbindung verfügt. Dies wird hier durch den IF Selektor ausgedrückt, welcher direkt an der betroffenen choice steht. 8

11 3.2 Instanzierung Abbildung 3: PL Test List Um zu einer Liste von Testfällen 1 zu gelangen werden die Variablen, wie etwa die Property P0 mit Werten belegt und alle gültigen Kombinationen unter dieser Bedingung aufgelistet. Resultat ist die PL Test list, die exemplarisch in 3 nachzuvollziehen ist. [3] 1 [..] the precise specification of a test input, a sequence of events and the expected output. 9

12 4 Ausblick [4] schließen ihr Paper mit der Aussage, dass schon viel im Bereich der Anforderungsdefinition von Produktlinien getan sei, aber nur wenig beim wirklichen Test und der Implementierung. Im folgenden sollen die Herausforderungen vom Testen von Produktlinien mit PLUTO im speziellen und von Produktlinien allgemein herausgestellt werden. 4.1 PLUTO Eine der Herausforderungen beim Testen mit PLUTO ergibt sich aus dem Fehlen von Testbegleitenden Daten. Nimmt man sich als Beispiel die drei Mobiltelefone ( 2.2 ), so könnten diese um einen Testfall ausführen zu können PIN-Nummern oder Passwörter benötigen um die richtige Ausgangsposition oder pre-condition für den Test herzustellen. Des weiteren ist es möglich das die Überprüfung ob der Testfall ein Erfolg war, nicht sofort für den Tester offensichtlich ist, sondern von bestimmten Nachbedingungen oder post-conditions abhängt. Dies könnte ein bestimmter Systemzustand sein oder auch das Format der beim Model 2 an den Internetserver überlieferten Daten sein. All diese Bedingungen und Daten könnten auch in einem begleitenden Dokument festgehalten werden, wenn im Zusammenhang mit Produktlinien die Variabilität nicht eine bedeutende Rolle spielen würde. Je nach gewählter choice mag das Resultat der Testdaten anders aussehen und müsste sich also auch in einem begleitenden Dokument wiederspiegeln. Hier stellt sich die Frage ob es günstiger ist jedes mal, wenn ein Test ausgeführt wird die gewünschten post-conditions erneut anhand der gegebenen Variabilität zu definieren oder den PLUTO Ansatz so zu erweitern, dass Testdaten automatisch aus der Variabilität errechnet werden können. Um diese Frage zu beantworten ist es notwendig beide Möglichkeiten genauer zu definieren und dann ihren Aufwand detaillierter im Bezug auf Anzahl der Variationspunkte und choices zu untersuchen. Dies soll jedoch nicht Bestandteil dieser Arbeit sein. Eine weitere Herausforderung im Test von Produktlinien mit PLUTO ergibt sich, durch die steigende Komplexität der Testfälle bei ebenfalls steigender Anzahl von Beziehungen ( 2.1 ) zwischen den Varianten. Vergleicht man etwa die Repräsentation des optionalen Tag [V2] Club in der Testspezifikation ( Abb. 2 ) mit einer vergleichbaren Darstellung, etwa als Featurediagramm 2 ( Abb. 4 ) ließe

13 sich in direkt durch die Notation des nicht ausgefüllten Kreises am Club Knoten erkennen, dass alle folgenden choices optional sind. Liest man die Testspezifikation ( Abb. 2 ), ist allerdings eine Untersuchung aller choices auf den Selektor, hier IF, notwendig um auf die optionale Eigenschaft des Tags zu schließen. Mobile Phone Legende Model Club mandatory feature optional feature * 1 alternative features * 2 features mit logischer oder Beziehung * 1 * WAP on WAP off Abbildung 4: Feature Diagramm über Modell und Internetkonnektivität 4.2 Produktlinien Im Hinblick auf Herausforderungen und Forschungsgebiete bei Produktlinien allgemein ergeben sich laut [5] folgende Überlegungen. Im Bereich der Forschung wäre vor allem eine genauere Untersuchung der Variabilität auf den verschiedenen Teststufen ( siehe 1 ) wünschenswert, sowie die Frage zu klären welche Aspekte auf den unterschiedlichen Stufen zur, in der Anforderungsdefinition aufgestellten Variabilität, hinzukommen. Auch die Einführung von MDD ( model-driven development ) in die Softwareentwicklung von Produktlinien sehen [5] als Herausforderung für zukünftige Forschungen. Aus Projektsicht ergeben sich Herausforderungen durch die ständige Änderung von Anforderungen an Softwareprodukte innerhalb einer Produktlinie und deren Auswirkungen auf die Variabilität und somit auch die Testfälle. 11

14 Ein weiterer Punkt, den auch [4] in ihrem Schlusswort andeuten, ist die fehlende Tool-Unterstützung beim Test und der Implementierung der Produkte. Hier wären fertige Werkzeuge von Vorteil, die den Ablauf automatisieren oder zumindest vereinfachen können. Des weiteren wäre es wünschenswert sich beim Testen näher an Standards wie dem CMMI 3 zu halten um die Qualitätsanforderungen einer Produktlinie genauer definieren und einhalten zu können. Aus wirtschaftlicher Sicht ergibt sich außerdem der Wunsch in Zukunft genauer das Return on Investment ( kurz: ROI ) eines bestimmten Features / einer Variabilität einschätzen zu können um so zum Beispiel die Profabilität einer Erweiterung der Produktlinie um weitere Produkte abschätzen zu können

15 Literatur [1] Pohl Schmid Böckle, Knauper. Software product line engineering. dpunkt Verlag, , 3 [2] Bertolino et al. Pluto: A test methodology for product families. ii, 1, 4 [3] Bertolino et al. Product line use cases: Scenario-based specification and testing of requirements. 9 [4] Bertolino et al. Use case-based testing of product lines. 7, 10, 12 [5] Klaus Pohl et al. Software product line engineering. Springer Verlag, , 2, 11 [6] A. van der Hoek H. Muccini. Towards testing product line architectures [7] Alvin P. Lehnerd Marc H. Meyer. The power of product platforms. Free Press,