ID 5557
Bühne, Stan: Darstellung der Variabilität von Software-Produktfamilien durch
Use Cases / Stan Bühne - Hamburg: Diplomica GmbH, 2002
Zugl.: Essen, Universität - Gesamthochschule, Diplomarbeit, 2002
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Inhaltsverzeichnis
Inhaltsverzeichnis ___________________________________________________________________I
Abkürzungsverzeichnis _____________________________________________________________ IV
Abbildungsverzeichnis_______________________________________________________________ V
Tabellenverzeichnis ________________________________________________________________VII
1 Einleitung________________________________________________________________________ 1
1.1
Motivation dieser Arbeit _____________________________________________________ 1
1.2
Ziel der Diplomarbeit _______________________________________________________ 2
1.3
Überblick ________________________________________________________________ 3
2 Software-Produktfamilien __________________________________________________________ 4
2.1
Prozesse der SW-Produktfamilienentwicklung ____________________________________ 4
2.1.1
Domain Engineering _____________________________________________________ 5
2.1.2
Application Engineering __________________________________________________ 6
2.1.3
Effektivität einer Software-Produktfamilie____________________________________ 6
2.2
Variabilität in Software-Produktfamilien ________________________________________ 7
2.2.1
Beschreibung von Variabilität ______________________________________________ 7
2.2.2
Umsetzungsarten von Variabilität ___________________________________________ 8
2.2.3
Auftreten von Variabilität _________________________________________________ 9
2.2.4
Variabilität im RE-Kontext ________________________________________________ 9
2.3
Zusammenfassung_________________________________________________________ 11
3 Variabilität einer Software-Produktfamilie aus Kundensicht ____________________________ 12
3.1
Einführung ______________________________________________________________ 12
3.2
Sichten auf Variabilität_____________________________________________________ 14
3.3
Beispiel FIS______________________________________________________________ 14
3.4
Modell der differenzierten Kundensicht auf Variabilität ___________________________ 16
3.4.1
Abbildungs-Variabilität __________________________________________________ 16
3.4.1.1
Variabilität in Geschäftsobjekten ______________________________________ 17
3.4.1.2
Variabilität in der Datenqualität _______________________________________ 18
3.4.1.3
Abbildungs-Variabilität am Beispiel ___________________________________ 18
3.4.2
Funktions-Variabilität ___________________________________________________ 19
3.4.2.1
Variabilität in der Benutzerfunktionalität________________________________ 20
3.4.2.2
Variabilität in der Benutzerfreundlichkeit _______________________________ 21
3.4.2.3
Variabilität in der Benutzer-Dienstgüte _________________________________ 22
3.4.2.4
Funktions-Variabilität am Beispiel_____________________________________ 23
3.4.3
Technische Variabilität __________________________________________________ 24
3.4.3.1
Variabilität in Geschäftssystemen _____________________________________ 24
3.4.3.2
Technische Variabilität am Beispiel____________________________________ 25
3.5
Metamodell der PF-Variabilität ______________________________________________ 26
3.6
Zusammenfassung_________________________________________________________ 27
I
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
4 Use Cases zur Darstellung von PF-Variabilität? _______________________________________ 28
4.1
Einführung Use Cases ____________________________________________________ 28
4.2
Darstellung funktionaler Anforderungen _______________________________________ 29
4.2.1
Einzelapplikationen _____________________________________________________ 29
4.2.2
Produktfamilien ________________________________________________________ 30
4.2.3
Erweiterungen des Use Case Modells _______________________________________ 32
4.2.4
Darstellung von Abläufen und Daten(-flüssen) ________________________________ 34
4.3
Darstellung nicht-funktionaler Anforderungen __________________________________ 35
4.3.1
Begriff der nicht-funktionalen Anforderung __________________________________ 35
4.3.2
Einzelapplikationen _____________________________________________________ 35
4.3.3
Produktfamilien ________________________________________________________ 36
4.4
Zusammenfassung_________________________________________________________ 38
5 Darstellung der Variabilitäts-Sichten ________________________________________________ 39
5.1
Einführung ______________________________________________________________ 39
5.2
Darstellung der Abbildungs-Variabilität _______________________________________ 39
5.2.1
Untersuchung der Darstellbarkeit von Geschäftsobjekten ________________________ 39
5.2.2
Untersuchung der Darstellbarkeit der Geschäftsqualität _________________________ 40
5.3
Darstellung der Funktions-Variabilität ________________________________________ 40
5.3.1
Untersuchung der Darstellbarkeit der Benutzerfunktionalität _____________________ 40
5.3.1.1
Darstellung variabler Funktionen ______________________________________ 40
5.3.1.2
Darstellung variabler Abläufe und Datenflüsse___________________________ 43
5.3.2
Untersuchung der Darstellbarkeit der Dienstqualität ____________________________ 44
5.4
Darstellung der Technischen-Variabilität ______________________________________ 47
5.4.1
Untersuchung der Darstellbarkeit von Geschäftssystemen _______________________ 47
5.5
Beurteilung der Darstellbarkeit durch Use Cases ________________________________ 48
5.6
Modellerweiterungen zur Darstellung nicht-funktionaler Variabilität_________________ 50
5.6.1
Darstellung nicht-funktionaler Variabilität durch NFR-Trees _____________________ 50
5.6.2
Kombination von Use Cases und NFR-Trees _________________________________ 50
5.6.3
NFR-Trees am Beispiel der Funktions-Variabilität _____________________________ 52
5.7
Abhängigkeiten zwischen Varianten ___________________________________________ 53
5.7.1
Abhängigkeiten an einem Variationspunkt ___________________________________ 53
5.7.2
Abhängigkeiten einer Variabilitäts-Klasse____________________________________ 54
5.7.3
Abhängigkeiten einer Variabilitäts-Sicht _____________________________________ 55
5.7.4
Abhängigkeiten unterschiedlicher Variabilitäts-Sichten _________________________ 55
5.7.5
Erweiterung um Abhängigkeits-Constraints __________________________________ 56
5.8
Ganzheitliche Betrachtung der Variabilitäts-Sichten ______________________________ 57
6 Umsetzung der PF-Variabilität am Beispiel ___________________________________________ 59
6.1
Einführung ______________________________________________________________ 59
6.2
Darstellung von PF-Variabilität durch Rose ____________________________________ 60
6.2.1
Erweiterung um Stereotype _______________________________________________ 60
6.2.2
REI Rose Extensibility Interface__________________________________________ 61
6.2.3
Aufteilung in Variabilitäts-Sichten _________________________________________ 62
6.3
Beschreibung der Funktions-Variabilität durch Rose _____________________________ 63
6.3.1
Darstellung variabler Funktionen___________________________________________ 63
II
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
6.3.1.1
Allgemeine Darstellung von Funktionen durch Rose_______________________ 63
6.3.1.2
Darstellung variabler Funktionen ______________________________________ 64
6.3.1.3
Darstellung variabler Abläufe ________________________________________ 65
6.3.1.4
Abhängigkeiten zwischen UC-Varianten ________________________________ 66
6.3.2
Darstellung variabler NFRs _______________________________________________ 67
6.3.2.1
Allgemeine Darstellung von NFR-Trees durch Rose _______________________ 67
6.3.2.2
Abhängigkeiten zwischen UC und NFR_________________________________ 69
6.3.2.3
Automatische Generierung von Abhängigkeitsdiagrammen _________________ 70
6.4
Beschreibung der Abbildungs-Variabilität durch Rose ____________________________ 71
6.4.1
Darstellung variabler Daten _______________________________________________ 71
6.4.2
Abhängigkeiten zwischen UC und Daten ____________________________________ 72
6.4.3
Automatische Generierung von Abhängigkeitsdiagrammen ______________________ 72
6.5
Erstellung eines Produkt-Modells_____________________________________________ 73
6.5.1
Erstellen der minimalen Funktionalität ______________________________________ 74
6.5.2
Hinzufügen optionaler Funktionalität _______________________________________ 75
6.5.3
Auffinden der notwendigen Daten und Objekte________________________________ 75
6.5.4
Fertigstellen der Produkt-Modelle __________________________________________ 76
6.6
Bewertung von Rose _______________________________________________________ 77
7 Zusammenfassung und Ausblick____________________________________________________ 78
7.1
Zusammenfassung_________________________________________________________ 78
7.2
Resümee und Ausblick _____________________________________________________ 79
8 Literaturverzeichnis ______________________________________________________________ 80
Anhang A Rose Erweiterungen _____________________________________________________ 84
Anhang B Selbständigkeitserklärung _______________________________________________ 113
III
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Abkürzungsverzeichnis
AE
Application
Engineering
CI Check-In
CIT
Check-In
Terminal
CIS
Check-In
Schalter
CRM
Customer
Relationship
Management
DE
Domain
Engineering
ER
Entity
Relationship
ERM
Entity Relationship Model
ERP
Enterprise Resource Planning
FIS
Fluginformationssystem
HW
Hardware
IS Informationssystem
IT Informationstechnologie
NF
Nicht-funktional(e)
(non-functional)
NFR
Nicht-funktionale Anforderung (non-functional requirement)
PF
Produktfamilie
PL
Product
Line
PLA
Product Line Architecture
RE
Requirements
Engineering
UC
Use
Case
UCM
Use
Case
Modell
UCT
Use
Case
Template
UML
Unified
Modelling
Language
URN
Unified Requirements Notation
SW
Software
V Variant
VP
Variation
Point
VoIP
Voice over Internet Protocol
WAP
Wireless Application Protocol
IV
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Abbildungsverzeichnis
Abbildung 2-1 Software-Produktfamilien-Prozess ... 5
Abbildung 2-2 Produktfamilien-Architektur... 6
Abbildung 2-3 Variationspunkte und Varianten ... 8
Abbildung 2-4 RE-Welten ... 10
Abbildung 3-1 Probleme der Darstellungs-Komplexität ... 13
Abbildung 3-2 Sichten auf Variabilität ... 14
Abbildung 3-3 FIS Darstellung... 15
Abbildung 3-4 Modell einer differenzierten Kundensicht auf Variabilität... 16
Abbildung 3-5 Fachliche Sicht... 17
Abbildung 3-6 Benutzer Sicht... 19
Abbildung 3-7 System Sicht ... 24
Abbildung 3-8 Metamodell der differenzierten Betrachtung der Variabilität... 26
Abbildung 4-1 Use Case Modell... 29
Abbildung 4-2 Use Cases und Variabilität... 31
Abbildung 4-3 UML Erweiterung um Stereotype... 32
Abbildung 4-4 Use Cases und PF-Variabilität... 33
Abbildung 4-5 Zusammenhänge FR und NFR ... 35
Abbildung 5-1 FIS 1 ... 41
Abbildung 5-2 FIS 2 ... 42
Abbildung 5-3 FIS 3 ... 42
Abbildung 5-4 Beispiel Flug zahlen ... 43
Abbildung 5-5 Beispiel buche Flug ... 45
Abbildung 5-6 NF-VP mit NF-Variante ... 45
Abbildung 5-7 Funktion mit n NF-Varianten ... 47
Abbildung 5-8 Darstellung Geschäftssysteme ... 48
Abbildung 5-9 NFR als Feature Tree... 50
Abbildung 5-10 UC mit NFR-Tree... 51
Abbildung 5-11 Beispiel UC NFR-Tree ... 52
Abbildung 5-12 Abhängigkeiten eines Variationspunktes... 54
Abbildung 5-13 Abhängigkeiten einer Variabilitäts-Klasse ... 54
Abbildung 5-14 Abhängigkeiten innerhalb einer Variabilitäts-Sicht... 55
Abbildung 5-15 Abhängigkeiten auf unterschiedlichen Variabilitäts-Sichten... 56
Abbildung 5-16 UML Erweiterung um Contraints... 56
V
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Abbildung 5-17 - Ganzheitliche Variabilitäts-Sicht... 57
Abbildung 6-1 Darstellung der Variabilitäts-Sichten in Rose ... 62
Abbildung 6-2 Darstellung der Funktions-Variabilität durch Rose ... 63
Abbildung 6-3 - Rose UC Diagramm ... 63
Abbildung 6-4 variable Funktionen ... 64
Abbildung 6-5 Abhängigkeits-Beziehungen... 64
Abbildung 6-6 Beschreibung von UC-Abläufen... 65
Abbildung 6-7 Selektierte UC Abhängigkeiten im Fenster ... 66
Abbildung 6-8 Übersicht NFR durch Rose... 68
Abbildung 6-9 Nested-Class Ojekte... 68
Abbildung 6-10 Ausschnitt einer UC-NFR Zuordnung... 69
Abbildung 6-11 Use Case Relations ... 69
Abbildung 6-12 automatische Generierung UC-NFR... 70
Abbildung 6-13 variables Objektmodell in Rose... 71
Abbildung 6-14 - Abhängigkeit UC-Daten... 72
Abbildung 6-15 - autom. Abhängigkeits-Darstellung Daten-UC ... 73
Abbildung 6-16 Ergebnis der Fkt. Show minimal Product... 74
Abbildung 6-17 - Auflistung optionaler Elemente... 75
Abbildung 6-18 - Datenmodell für ausgewählte Funktionen... 75
VI
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Tabellenverzeichnis
Tabelle 2-1 - Typisierung von Variationspunkten und Varianten________________________ 8
Tabelle 2-2 - Einteilung der Variabilitäts-Arten nach [Bachma01] _____________________ 11
Tabelle 3-2- Funktions-Variabilität______________________________________________ 23
Tabelle 3-3 - Technische Variabilität ____________________________________________ 25
Tabelle 4-1 - Use Case Template (UCT) _________________________________________ 34
Tabelle 4-2 - Bsp. NFR Beschreibung ___________________________________________ 35
Tabelle 4-3 Beispiel Variationspunkt ,,Check-In" _________________________________ 36
Tabelle 4-4 Beispiel NF-Variante 1 ____________________________________________ 37
Tabelle 4-5 Beispiel NF-Variante 2 ___________________________________________ 37
Tabelle 4-6 - UC Darstellungsmöglichkeiten - und Grenzen __________________________ 38
Tabelle 5-1 - UCT "Flug zahlen" Variationspunkt __________________________________ 43
Tabelle 5-2 - UCT "Flug per Rechnung zahlen" Variante ____________________________ 44
Tabelle 5-3 - UCT "Flug per Kreditkarte zahlen" Variante ___________________________ 44
Tabelle 5-4 - Bsp. NF-Beschreibung 1 ___________________________________________ 46
Tabelle 5-5 - Bsp. NF-Beschreibung 2 ___________________________________________ 46
Tabelle 5-6 - Beurteilung der Darstellbarkeit von PF-Variabilität durch Use Cases ________ 49
Tabelle 6-1 - einzuführende Rose Stereotype ______________________________________ 61
Tabelle 6-2 Alle UC Abhängigkeiten aus Tabellen-Export __________________________ 67
VII
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
1 Einleitung
1.1 Motivation dieser Arbeit
Die Entwicklung von Software erfährt seit einigen Jahren die Schnelllebigkeit der Märkte, in
denen immer größere Softwareprojekte in immer kürzerer Zeit mit immer kleineren Budgets
realisiert werden müssen. Um diesen Ansprüchen gerecht zu werden, mehren sich die Konzepte
zur Wiederverwendung von bestehenden Code-Komponenten und es entstehen immer größer
werdende Code-Libraries, die in verschiedenen Softwareprojekten Wiederverwendung finden.
Die wachsende Komplexität, schlechte Dokumentation und fehlende Nachvollziehbarkeit
(Traceability), führen dabei allerdings meistens zu Schwierigkeiten in der Wiederverwendung
[Northr01], [Karlss96]. Da eine gezielte Wiederverwendung heutzutage, schon aus Gründen der
Entwicklungszeit und der Modellpflege unumgänglich ist, sind durchgängige Konzepte zur
Wiederverwendung notwendig, welche angefangen von der Phase Anforderungsfindung bis zur
Einführung und Pflege des jeweiligen Produkts durchgängig beschrieben und nachvollziehbar
sind, sodass ein erzieltes Ergebnis unter gleichen Bedingungen reproduzierbar ist.
Ein weiterentwickelter Gedanke der ,,einfachen" Wiederverwendung von Code-Komponenten,
sind Software-Produktfamilien. Software-Produktfamilien basieren auf dem Konzept der
Wiederverwendung von Anforderungen, Modellen, Code, Testbeschreibungen etc., welches
sich durch zwei eigenständige Prozesse auszeichnet: zum einen die Entwicklung für die
Wiederverwendung (Development for Reuse) und zum anderen die Entwicklung durch
Wiederverwendung (Development with Reuse) [Karlss96].
Das Produktfamilien-Konzept hat für die Entwicklung neuer Software-Produkte das Ziel, einen
großen Teil der zugrunde liegenden (variablen) Architektur
1
wiederzuverwenden, sodass sich
einzelne Produkte einer Architektur nur im Detail voneinander unterscheiden. Um diesem Ziel
gerecht zu werden, ist es notwendig, die sogenannte Variabilität einer Produktfamilie für die
Entwicklung eines individuellen Produktes, und zur effizienten Wiederverwendung von Teilen
der Architektur, repräsentierbar zu machen. Die Variabilität beschreibt dabei variable Aspekte
der Architektur, z.B. wie sich Funktionen eines Systems im Detail voneinander unterscheiden.
Das heißt dem Kunden soll die Funktionalität sowohl im technischen als auch im funktionalen
Sinne mit ihren unterschiedlichen Auswahlmöglichkeiten beschrieben werden können, sodass
die jeweiligen Anforderungen des Kunden, so gut wie möglich, durch die gegebene
Produktfamilien-Variabilität befriedigt werden können.
Der Wiederverwendungsgedanke sollte deshalb schon frühzeitig im RE-Prozess berücksichtigt
werden, sodass die Variabilität der Produktfamilie gut dokumentiert und für den späteren
1
Die Architektur einer SW-Produktfamilie umfasst in dem hier beschriebenen Sinne alle Teilprodukte
(bzw. Fragmente) der Entwicklung (Anforderungsspezifikationen, Modelle, Code-Komponenten, etc.)
1
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Widerverwendungsprozess nachvollziehbar und darstellbar gemacht werden kann [Jacobs97],
[Northr01].
1.2 Ziel der Diplomarbeit
Ziel der Diplomarbeit ist es, für den RE-Prozess in der Applikationsentwicklung (Application
Engineering) eine geeignete Darstellungsweise für die Variabilität von Software-Produktfamilien
zu entwickeln, die es erlaubt die PF-Variabilität aus der Sicht des Kunden abzubilden. Aus Sicht
des Kunden meint in diesem Zusammenhang, eine Betrachtung der variablen Aspekte einer
Produktfamilie, die sich auf eine externe Sicht auf das System beschränkt, d.h. auf eher
funktionale Aspekte die erläutern was ein System abbildet, welche Funktion es bietet oder wo es
zu Nutzen ist. Unberücksichtigt bleiben aus Kundensicht Variabilitäts-Aspekte, die sich auf die
Umsetzung, sprich Implementierung, etc. beziehen. Für die Darstellung der Variabilitäts-
Aspekte aus Kundensicht, sollen vorhandene Use Case Modelle untersucht und ggf. erweitert
werden.
Diese Modelle sollen den RE-Ingenieur bei der Anforderungserhebung im Application
Engineering unterstützen, dem Kunden die Möglichkeiten und Grenzen der Produktfamilie
aufzuzeigen. Zudem ermöglicht die Darstellung der Variabilität, frühzeitig die Parallelen
zwischen Kundenanforderungen und der gegebenen Funktionalität (bzw. Variabilität) zu
erkennen, sodass Kundenanforderungen so früh wie möglich durch die Wiederverwendung
befriedigt werden können.
2
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
1.3 Überblick
Das Kapitel 2 gibt eine einführende Einleitung in den Bereich der Software-Produktfamilien
und erläutert hierbei kurz die Prozesse des Domain Engineering und Application Engineering,
bevor grundlegende Aspekte der Variabilität besprochen werden und der RE-Kontext hergestellt
wird.
Das Kapitel 3 beschreibt die Variabilität von Produktfamilien aus Kundensicht und führt hierfür
eine auf die RE-Welten aufbauende differenzierte Sichtweise auf die Produktfamilien-
Variabilität ein, welches eine Klassifizierung der Variabilität in unterschiedliche Variabilitäts-
Sichten und Klassen erlaubt.
Das Kapitel 4 gibt eine kurze Einführung in UML-Use Cases und untersucht die
Darstellungsmöglichkeiten und Darstellungsgrenzen von Use Cases in Bezug auf die
Darstellbarkeit von Produktfamilien-Aspekten.
Das Kapitel 5 untersucht die Darstellungsmöglichkeit, der in Kapitel 3 erarbeiteten
Variabilitäts-Sichten und Klassen durch Use Case Modelle und beschreibt einige
Erweiterungsmöglichkeiten zur geeigneten Darstellung der durch Use Cases nicht darstellbaren
Klassen, sowie derer Abhängigkeiten untereinander, bevor diese in einer ganzheitlichen Sicht
zusammengefasst und beschrieben werden.
Das Kapitel 6 untersucht und beschreibt anhand eines Beispiels Umsetzungsmöglichkeiten des
erarbeiteten Modells, durch ein konventionelles Modellierungs-Tool (Rational Rose) und zeigt
dabei Möglichkeiten und Grenzen heutiger Werkzeuge auf.
Das Kapitel 7 gibt zum Abschluss eine zusammenfassende Beschreibung der Arbeit mit den
erlangten Erkenntnissen, sowie einen Ausblick über den möglichen Nutzen dieser Arbeit.
3
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
2 Software-Produktfamilien
2.1 Prozesse der SW-Produktfamilienentwicklung
Software-Produktfamilien werden speziell für den Nutzen einer bestimmten Domäne entwickelt
und bieten ein Konzept zur Wiederverwendung von Komponenten
2
. Die Begriffe Software-
Produktfamilie und Produktfamilie werden in dieser Arbeit alternierend benutzt und sind im
weiteren Verlauf als Synonyme zu betrachten.
Die PF-Architektur beschreibt auf Basis von Gemeinsamkeiten (Commonalities) und Varianten
(Variants) die Variabilität der Produktfamilie. Produkte einer Produktfamilie bilden ,,Fragmente"
dieser Architektur, da sie je nach Kundenanforderungen nur bestimmte Komponenten
(Varianten) der Architektur benötigen, um die Anforderungen der Kunden zu befriedigen. Ein
Produkt besteht aus einem gemeinsamen Kern, der allen Produkten der Familie gemein ist und
einer Anzahl von Varianten, die die speziellen Anforderungen des jeweiligen Kunden erfüllen.
Der Vorteil von Produktfamilien liegt hierbei in der schnelleren und kostengünstigeren
Entwicklung individueller Produkte durch die gezielte Wiederverwendung von Anforderungen,
Modellen, Code-Komponenten etc. Diese schnelle und kostengünstige Entwicklung von
individualisierten Produkten ist sowohl im Sinne der Kunden als auch im Sinne der Anbieter.
Um diesem Konzept allerdings gerecht zu werden, ist es wichtig, dass möglichst viele Teile
(Varianten) der Architektur ohne Änderungen übernommen werden können, um die
Kundenanforderungen zu erfüllen.
Der Produktfamilien-Prozess kann hierbei grundsätzlich in zwei eigenständige Prozesse
unterteilt werden: Domänenentwicklung (Domain Engineering) bzw. Entwicklung für
Wiederverwendung (Engineering for Reuse) und Applikationsentwicklung (Application Engineering)
bzw. Entwicklung durch Wiederverwendung (Engineering with Reuse), siehe [Northr01],
[Atkins01], [Jacobs97], [Karlss96]. Die folgende Abbildung (Abbildung 2-1 Software-
Produktfamilien-Prozess) nach [Atkins01] illustriert diese beiden Prozesse und deren
Beeinflussung untereinander.
2
Der Komponentenbegriff umfasst hier neben Code auch Spezifikationen, Testbeschreibungen, Modelle,
etc. und meint in dieser Arbeit zusammenhängende Bausteine (Konzepte), die neben den Spezifikationen
auch Modelle, Code und Testbeschreibungen enthalten.
4
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Domain
Asset base
Applikations-
Analyse
Applikations-
Design
Applikations-
Implementierung
Application Engineering
F
ee
d
ba
ck
Domäne
Domänen
Analyse
Domänen
Design
Domänen
Implementierung
Domain Engineering
M
od
ell
e,
...
Co
de, ...
Anfo
rderu
ngen
Code
, ...
Applikations-
Analyse
Applikations-
Design
Applikations-
Implementierung
Application Engineering
Applikations-
Analyse
Applikations-
Design
Applikations-
Implementierung
Application Engineering
Anforderungen
Gesetze
Legacy-Systeme
...
Abbildung 2-1 Software-Produktfamilien-Prozess
Der obere Teil der Abbildung stellt das Domain Engineering mit seinen Teilprozessen (Analyse,
Design und Implementierung) dar. Die Anforderungen an eine ,,neue" SW-Produktfamilie,
werden dabei durch die entsprechende Domäne beeinflusst. Die ,,Teilprodukte" des Domain
Engineering (Anforderungsbeschreibungen, Designentscheidungen, Code, etc.) werden im
Application Engineering wiederverwendet. Die einzelnen Produkte werden dabei wiederum
durch Domänenanforderungen (eines speziellen Kunden) und durch die gegebene Variabilität
beeinflusst.
In dieser Arbeit soll der Produktfamilien-Prozess aus Sicht des Requirements Engineering
betrachtet werden und beschränkt sich auf die Analysephase bzw. die Phase der
Anforderungserhebung.
2.1.1 Domain Engineering
Die Domänenentwicklung (Domain Engineering) beschäftigt sich mit der Entwicklung einer
Produktfamilien-Architektur, die zur Wiederverwendung erstellt wird. [Jacobs97] beschreibt
das Domain Engineering als:
,,A systematic reuse term that describes a systematic way of identifying a domain model,
commonality and variability, potentially reusable assets, and an architecture to enable their
reuse".
Wie fast jeder Entwicklungsprozess, beginnt auch die Domänenentwicklung mit der
Anforderungserhebung. Unter Berücksichtigung des RE-Prozesses, der sich in vier Prozesse
unterteilen lässt (Elicitation, Negotiating, Validation & Verification, Specification) werden die
Anforderungen einer Domäne erhoben und modelliert. Ein Unterschied zur Entwicklung von
Einzelapplikationen besteht in der Unterscheidung zwischen gemeinsamen (gleichen) und
variablen (unterschiedlichen) Anforderungen. Gleiche Anforderungen (Commonalities) werden
als Kern (Core Assets) und unterschiedliche Anforderungen (Variants) als Varianten modelliert
und bilden die Variabilität einer Produktfamilie.
5
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Product Line
Architecture
Variation Point
Core
Variant
n
n
n
1
1
1
n
0
Abbildung 2-2 Produktfamilien-Architektur
Weitere Schritte im Domain Engineering (DE) sind das Design, die Implementierung und das
Testen der Architektur, welche hier allerdings nicht weiter betrachtet werden sollen. Der
interessierte Leser sei auf [Jacobs97], [Karlss96], [Atkins01], [Anasta00], [Coplie98],
[Cheong98] verwiesen.
2.1.2 Application Engineering
Die Applikationsentwicklung (Application Engineering) befasst sich mit der Entwicklung
eigenständiger Produkte auf Basis der Produktfamilien-Architektur. [Karlss96] bezeichnet die
Applikationsentwicklung auch als Development with Reuse, bei dem individuelle Produkte
(Applikationen) durch die maßgeschneiderte Zusammenstellung von Komponenten der
Produktfamilien-Architektur erstellt werden.
Genau wie die Domänenentwicklung beginnt der Entwicklungsprozess beim Application
Engineering mit der Anforderungserhebung im RE-Prozess. Der
Anforderungserhebungsprozess im Application Engineering unterscheidet sich in sofern vom
Domain Engineering, als dass zur Befriedigung der Kundenanforderungen, die vorhandene
Variabilität der PF-Architektur genutzt wird. Das Ziel des RE-Ingenieur ist es hierbei,
frühzeitig, so viele Anforderungen wie möglich durch die Wiederverwendung von Varianten zu
befriedigen.
Das Ergebnis ist eine Spezifikation mit wiederverwendbaren, geänderten und neuen Varianten,
die zur Befriedigung der Kundenanforderungen dienen. Auf Basis dieser Spezifikation können
in den weiteren Entwicklungsprozessen wiederverwendbare Modelle, Code-Komponenten und
Testbeschreibungen aus der Architektur übernommen werden, sodass für den gesamten
Entwicklungsprozess ein hoher Wiederverwendungsgrad erreicht wird und redundante Prozesse
vermieden werden. Für neue und geänderte Anforderungen sind Objektmodelle, Code-
Komponenten, Testfälle usw. entsprechend zu ergänzen und zu ändern [Jacobs97], [Bosch98],
[Bosch99], [Svahn00], [Svahn01].
2.1.3 Effektivität einer Software-Produktfamilie
Der Wiederverwendungsgrad, bzw. die Effektivität einer Produktfamilie, gibt Auskunft darüber,
wie viele Anforderungen allein durch Wiederverwendung von Komponenten erfüllt werden
können, und ist dabei abhängig von der Variabilität der Produktfamilie. Um den
Wiederverwendungsgrad einer Produktfamilie zu erhöhen ist es notwendig, dass die
6
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Produktfamilie über eine hinreichende Variabilität verfügt, welche beim Application
Engineering im RE-Prozess genutzt wird, um die Anforderungen des Kunden abzubilden.
Dennoch kann nicht jede Kundenanforderung durch die Produktfamilie abgebildet werden,
sodass neue Anforderungen entstehen, die für das Produkt zu berücksichtigen sind. Neue
Anforderungen haben allerdings zur Folge, dass für die weiteren Entwicklungsprozesse im
Application Engineering mehr Ressourcen wie finanzielle Mittel, Arbeitskräfte, Zeit, etc.
benötigt werden, um diese Anforderung umzusetzen. Wichtig ist hierbei, dass sowohl Kunde als
auch RE-Ingenieur, den Trade-Off zwischen 100%iger Befriedigung der Anforderungen und
den benötigten Mehraufwand an Ressourcen erkennen, sodass eventuelle Alternativen
berücksichtigt werden können.
Grundlegend für eine effektive Wiederverwendung ist daher, dass der RE-Ingenieur die
Möglichkeiten und die Grenzen der PF-Variabilität versteht und dem Kunden, diese darstellen
kann.
2.2 Variabilität in Software-Produktfamilien
2.2.1 Beschreibung von Variabilität
"Variability is the ability to change or customize a system." [Swahn00]
Variabilität ist die Vorraussetzung für eine erfolgreiche Produktfamilie und bietet die
Möglichkeit, unterschiedliche Produkte aus einer PF-Architektur zu erstellen. Die Variabilität
einer SW-Produktfamilie wird dabei durch unterschiedliche Anforderungen der Domäne
getrieben.
Bedenkt man, dass Variabilität von Produktfamilien dazu entwickelt wird, um durch ihre
Wiederverwendung (im AE) individuelle Produkte zu erstellen, so erscheint es für die
Wiederverwendung aus RE-Sicht notwendig, Variabilität zu beschreiben und sie in geeigneten
Modellen abbildbar zu machen. Die Beschreibung von Variabilität ist dabei eine wesentliche
Voraussetzung, um die Variabilität einer Produktfamilie zu verstehen und eine erfolgreiche
Wiederverwendung zu ermöglichen. [Jacobs97], [Coplie98], [Svahn01], u.a. beschreiben
Variabilität von Produktfamilien durch Variationspunkte und Varianten (Abbildung 2-2).
Variationspunkte bilden eine abstrakte Darstellung konkreter Varianten, an denen Varianten
einer Kategorie zusammengefasst werden. So werden z.B. die Anforderungen ,,Kommunikation
via Email", ,,Kommunikation über Pop-Up Fenster (net send)" und ,,Kommunikation mittels
Voice over IP (VoIP)" an einem Variationspunkt geknüpft und als unterschiedliche Varianten
dargestellt. Durch die Auswahl (bzw. das Binden [Svahn99a]) von Varianten können
individuelle Produkte abgebildet werden (Abbildung 2-3).
7
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Kommuniktions-
quelle
Kommuniktions-
senke
Email
Email
Net send
Variantionspunkt
,,Kommunikation"
Kommuniktions-
quelle
Kommuniktions-
senke
Net send
Kommuniktions-
quelle
Kommuniktions-
senke
Variationspunkt
,,Kommunikation"
Erstellung eines Variationspunktes
Produktausprägung 1
Produktausprägung 2
Darstellung der Produktvariation
VoIP
Abbildung 2-3 Variationspunkte und Varianten
Die Auswahl von Varianten, muss wie in obiger Abbildung, nicht immer eine alternative
Auswahl von Varianten darstellen. Variabilität im weiteren Sinne beschreibt neben alternativer
Variabilität auch optionale (Zusatzfunktionalität) oder Pflicht-Variabilität. Tabelle 2-1
beschreibt hierzu unterschiedliche Variabilitätstypen. Eine ,,optionale Variabilität" wird durch
einen optionalen Variationspunkt und optionale Varianten beschrieben (a). Dies ist z.B. die
Auswahl mehrerer Sprachen bei einer Rechtschreibprüfung, bei der der Kunde entweder keine,
eine oder mehrere unterschiedliche Sprachen für die Rechtschreibprüfung auswählen kann. Eine
,,notwendige Variabilität", wird durch einen Pflicht-Variationspunkt und einer Pflicht-Optional
bzw. Pflicht-Alternativ Variante (b) dargestellt. Dies könnte z.B. eine wählbare Darstellungsart
sein, bei der der Kunde sich entweder auf eine graphische oder eine textuelle Darstellungsweise
festlegen muss. Um unterschiedliche Typen von Variabilität zu beschreiben, werden
unterschiedliche Auswahltypen für Variationspunkte (VP) und Varianten (V) gebildet
[Anasta00]. Tabelle 2-1 beschreibt hierzu Kombinationsmöglichkeiten von Variationspunkten
und Varianten, mit der die notwendige PF-Variabilität dargestellt werden kann.
Variationspunkt (Vp)
Optional (m : n) Alternativ (1 : n)
Pflicht
Optional (m : n)
Optionale
Variabilität
Alternativ (1 : n)
(a)
Alternative
Variabilität
Pflicht + Optional
(b)
Varian
te (V)
Pflicht + Alternativ
notwendige
Variabilität
Tabelle 2-1 - Typisierung von Variationspunkten und Varianten
2.2.2 Umsetzungsarten von Variabilität
Um die in Tabelle 2-1 dargestellten Typen von Variabilität zu implementieren, stehen
verschiedene Methoden zur Verfügung. Die verfügbare Literatur beschäftigt sich ausgiebig mit
verschiedenen Umsetzungsarten von Variabilität, z.B. wie kann Variabilität bei der
8
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Implementierung umgesetzt werden, welche Unterschiede sind dabei zur
Einzelapplikationsentwicklung zu betrachten und welche Variabilität muss dem Benutzer wann
zur Verfügung stehen bzw. wie sind die Bindezeitpunkte dafür zu verzögern. Svahnberg
([Svahn99a] [Svahn99b], [Svahn99c], [Svahn00], [Svahn01]) beschreibt unterschiedliche
Bindezeitpunkte von Variabilität (Spezifikation, Design, Coding, Compiling, Installations-,
Start-Up und Run-Time) und stellt heraus, dass die Bindung von Varianten in Produktfamilien
zu verzögern ist, sodass durch Late-Binding -Konzepte Kontextinformationen erst zu Laufzeit
festgelegt werden. [Jacobs97] beschreibt dazu verschiedene Arten, wie Variabilität umgesetzt
werden kann. Er stellt verschiedene objekt-orientierte Ansätze, wie Vererbung, Generalisierung,
Polymorphismus, Templates, etc. dar, um Variabilität zu implementieren.
Da der Fokus dieser Arbeit auf den RE-Prozess im Application Engineering gerichtet ist und
Variabilität, wie eingehend erwähnt, aus Sicht des Kunden betrachten soll, wird die
umsetzungstechnische Betrachtung von Variabilität hier nicht weiter fortgeführt.
2.2.3 Auftreten von Variabilität
Wie eingehend bereits angesprochen wird Variabilität durch unterschiedliche
Kundenanforderungen und Legacy-Systeme der Domäne getrieben. Diese unterschiedlichen
Anforderungen entstehen durch heterogene Systeme und heterogene Geschäftsziele. Bedingt
dadurch tritt in einer Produktfamilien-Architektur Variabilität an unterschiedlichen Stellen auf.
Genau wie die Herkunft heterogener Anforderungen lässt sich Variabilität nach [Bachma01] in
unterschiedliche Auftretensarten klassifizieren:
- Variabilität in der Funktionalität des Systems: Beschreibt Variabilitäts-Aspekte auf
Funktionsebene, d.h. optionale, alternative Funktionen.
- Variabilität in Kontrollflüssen: Beschreibt Variabilitäts-Aspekte, welche die Abläufe
von Funktionen betreffen, d.h. optionale, alternative Kontroll- und Funktionsflüsse.
- Variabilität in der Datenrepräsentation: Beschreibt Variabilitäts-Aspekte von
abzubildenden Daten und Funktionen. So sind z.B. je nach Systemkontext
unterschiedliche Daten, bzgl. Art und Umfang, durch ein Produkt abzubilden.
- Variabilität in der Technologie: Beschreibt Variabilitäts-Aspekte in der zu
verwendenden Technologie und bezieht sich auf Umsetzungsarten der Variabilität.
- Variabilität in der Systemumgebung: Beschreibt Variabilitäts-Aspekte in Systemen,
Technologien, etc. auf denen das System zum Einsatz kommen kann.
- Variabilität in Qualitätsansprüchen: Beschreibt Variabilitäts-Aspekte die aus Sicht der
Systemnutzer von Interesse sind, z.B. Sicherheit, Performanz, etc.
Die unterschiedlichen Auftretensarten von Variabilität beschreiben letztendlich verschiedene
Sichten auf die Systemvariabilität einer Produktfamilie.
2.2.4 Variabilität im RE-Kontext
Betrachtet man die Anforderungen einer Domäne, so steht jede Anforderung in einem gewissen
Kontext zu einem Informationssystem und wird von einem bestimmten Personenkreis getrieben.
Im Requirements Engineering können diese Personen (Stakeholder) nach [Pohl_a], [Rollan99],
[Jarke93], drei unterschiedlichen Welten zugeteilt werden, welche die Gesamtheit der
Anforderungen an das System beschreiben (siehe Abbildung 2-4).
9
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Subject
World
Usage
World
System
World
Development
World
Systembenutzer
Domänenexperten
Gesetze
Standards
Systemspezialisten
Entwickler
Administratoren
Abbildung 2-4 RE-Welten
Die Systementwicklung im Kontext der drei Welten ermöglicht es, die Systemgrenzen zu
spezifizieren und für die Entwicklung eines Systems nur die relevanten Teile der realen Welt zu
betrachten. [Pohl_a] und [Jarke93] sprechen hier von ,,Visions in Context". So kann nach den
RE-Welten eine Systemvision durch drei unterschiedliche Welten beschrieben werden. Die
Fachwelt (Subject World) begrenzt dabei den Kontext auf den abzubildenden Gegenstand,
Person, etc. (Objekt), der durch ein Informationssystem repräsentiert werden soll. Die
notwendigen Daten und Eigenschaften des ,,realen" Objekts, werden durch Fachpersonal,
Domänenspezialisten, etc. beschrieben. Die Benutzerwelt (Usage World) fokussiert die
Systembenutzer, und deren Anforderungen an das System. Durch die Benutzerwelt können
notwendige Funktionen und Abläufe, die zur Befriedigung der Benutzeranforderungen
notwendig sind, evaluiert werden. Die Benutzerwelt und Fachwelt bilden dabei die sog.
Diskurswelt des Systems. Die Systemwelt (System World) begrenzt den Kontext auf zum Einsatz
kommende Systeme und Technologien, auf denen das System laufen soll und setzt sich im
wesentlichen aus Systemspezialisten, Wartungspersonal usw. zusammen. In einer vierten
,,übergeordneten" Welt (Development World) findet der RE-Prozess statt. In dieser Welt sind
Stakeholder aller Welten involviert, die den Anforderungsprozess vorantreiben. Stakeholder der
Systemwelt (System World), Benutzerwelt (Usage World) und Fachwelt (Subject World) haben
dabei andere Bedürfnisse, Anforderungen sowie ein anderes Systemverständnis und eine andere
Sichtweise vom System. Im Prozess der Anforderungserhebung stellt jede Welt ihre
Anforderungen an das System, wobei die Welten keine disjunkten Einheiten bilden und
Stakeholder in mehreren Welten auftauchen können. Durch den RE-Prozess werden hier die
Anforderungen ermittelt, verhandelt, überprüft und für den weiteren Entwicklungsverlauf
dokumentiert.
Betrachtet man die Welten im Zusammenhang, so bildet die fachliche Welt Daten von Objekten
(z.B. die Leistung, Farbe, Anz. Der Türen, Fahrzeugart, etc. eines PKWs) auf Systemen der
Systemwelt ab, die dem Benutzer des Systems, durch die zur Verfügung stehenden Funktionen
und Daten, das ursprünglich reale Objekt assoziieren sollen.
10
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Vergleicht man diesen Vorgang mit der Entwicklung von Produkten einer Software-
Produktfamilie, so ist der Prozess der Auffindung der Stakeholder eines Systems, durch die
Eingrenzung des Systemkontexts, ähnlich. Da die Anforderungen der Stakeholder allerdings
nicht von Grund auf neu evaluiert werden müssen und man auf die Wiederverwendung von
Anforderungen der Produktfamilie bedacht ist (Abbildung 2-1), erscheint es für den Prozess der
Anforderungserhebung notwendig, Variabilität aus der Sicht der Stakeholder zu repräsentieren
und sie ggf. durch unterschiedliche Modelle darzustellen. Dies würde den jeweiligen
Stakeholder bei der Auswahl von Varianten zur Befriedigung seiner Anforderungen
unterstützen, ohne ihn mit zu komplexen und unverständlichen Modellen der gesamten
Produktfamilien-Variabilität zu belasten.
Betrachtet man die von [Bachma01] angesprochenen Auftretensarten von Variabilität (2.2.3), so
lassen sie sich ihrer Herkunft nach wie folgt in die RE-Welten einteilen (Tabelle 2-2).
Diskurswelt
Subject World
Usage World
System World
- Variabilität in der
Datenrepräsentation
- Variabilität in der Funktionalität
- Variabilität in Kontrollflüssen,
- Variabilität in Qualitätsansprüchen
- Variabilität in der Technologie
- Variabilität in der Systemumgebung
Tabelle 2-2 - Einteilung der Variabilitäts-Arten nach [Bachma01]
Aufbauend auf diese Einteilung lässt sich auf Basis der RE-Welten eine differenzierte
Betrachtung der PF-Variabilität schaffen, die in Kapitel 3 ausführlich beschrieben wird.
2.3 Zusammenfassung
Produktfamilien bieten eine Reuse-Architektur, die es ermöglicht, individuelle Produkte durch
Auswahl und Wiederverwendung von gegebenen Varianten zu erstellen und so unterschiedliche
Kundenanforderungen zu befriedigen. In der Domänenentwicklung wird die Produktfamilien-
Architektur erstellt, die durch die Applikationsentwicklung wiederverwendet (instantiiert) wird.
Grundlegend für die effektive Wiederverwendung ist die Variabilität einer Architektur, die sich
für durch RE-Prozess in drei Welten unterteilen lässt:
- Fachliche Welt (Subject World)
- Benutzer Welt (Usage World)
- System
Welt
(System World)
Das Kapitel 3, beschreibt anschließend die Notwendigkeit einer differenzierten Sichtweise auf
die Variabilität von Produktfamilien, bevor das Kapitel 4 die Darstellungsmöglichkeiten und
Darstellungsgrenzen von Anwendungsfällen (Use Cases), in Bezug auf die Variabilität einer
Software-Produktfamilie untersucht.
11
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
3 Variabilität einer Software-
Produktfamilie aus Kundensicht
3.1 Einführung
Das Requirements Engineering hat die Aufgabe, die Anforderungen an ein System aus Sicht des
Kunden zu ermitteln, zu verhandeln, zu überprüfen und zu dokumentieren. Ein ,,Kunde" wird
dabei in der Regel nicht durch eine Einzelperson dargestellt, sondern durch eine Gruppe
unterschiedlicher Interessenvertreter (Management, Benutzer, Administratoren, etc.), mit
unterschiedlichsten Zielen (Gewinnmaximierung, Arbeitsunterstützung, Wartbarkeit, etc.) und
unterschiedlichem Wissen (Geschäfts-, Prozess-, System- Wissen) repräsentiert.
Betrachtet man die gesamte Funktionalität einer Produktfamilie bzw. die gesamte PF-
Variabilität, so erkennt man schnell, dass variable Aspekte in der Stammdatenpflege,
Rechteverwaltung oder gewinnbringenden Prozessoptimierung für den Benutzer des Systems
nicht unbedingt von Interesse sind. Einen Benutzer interessiert meist nur sein direkter Nutzen
durch das System. Für einen System-Ingenieur ist es hingegen eher von Interesse, wie das
System zu verwalten und zu pflegen ist oder welche Integrationsmöglichkeiten und
Erweiterungsmöglichkeiten das System bietet. Einem Manager liegen dagegen die Erfüllung
seiner Geschäftsziele und die Einbindung des Systems in laufende Prozesse am Herzen.
Um einem Kunden, oder besser gesagt den Stakeholdern, die Variabilität einer Produktfamilie
zu erläutern, ist es aufgrund der differenzierten Systembetrachtung durch die RE-Welten (2.2.4)
wesentlich, nicht nur eine einzige Sicht auf die PF-Variabilität zu gewähren. Die Komplexität
der Darstellung wäre zu umfassend, als das jeder Stakeholder seinen expliziten Nutzen daraus
ziehen könnte, wodurch letztendlich der Wiederverwendungsgrad der Produktfamilie (2.1.3)
und damit der Erfolg der Produktfamilien-Architektur sinken würde. Abbildung 3-1 stellt das
Problem einer zu komplexen Variabilitäts-Darstellung aus Sicht der Anforderungserhebung im
Applikation Engineering dar. Ausgehend von einer zu komplexen Darstellung von Variabilität,
ist es für viele Stakeholder nicht möglich, die gegebene PF-Variabilität zu nutzen, um die
Anforderungen zu befriedigen. Hieraus resultierend besteht auf der einen Seite die Möglichkeit,
neue Varianten zu erstellen, welche wiederum die Komplexität erhöhen (,,Teufelskreis") und
zusätzlich den Wiederverwendungsgrad verringern. Auf der anderen Seite, kann die
Unverständlichkeit der Variabilität dazu führen, dass Stakeholder das Interesse an der
Produktfamilie verlieren, da die hervorgebrachten Anforderungen nicht befriedigt werden.
Letztendlich könnte so die komplexe, unverständliche Darstellung der Variabilität zu einem
sinkenden Produktfamilienerfolg führen.
12
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Die folgende Abbildung (Abbildung 3-1) beschreibt die zuvor besprochene These anhand einer
anschaulichen Darstellung.
Komplexe
Darstellung von
Variabilität
Anforderungen
können durch Variabilität
nicht befriedigt werden
Erstellen neuer
Varianten
PF nicht von
Interesse
Sinkender
Wiederverwendungs-
grad
Produktentwicklung
ähnelt Einzel-
Applikationsentwicklung
Sinkender
PF Erfolg
erhöht
Komplexität
Gegebene Variabilität
ist für Stakeholder
unverständlich
Abbildung 3-1 Probleme der Darstellungs-Komplexität
Um dieser beschriebenen These zu entgehen, ist eine differenzierte Sichtweise bzw. eine
Einteilung in Variabilitäts-Sichten notwendig. Eine differenzierte Sichtweise nach den RE-
Welten hat den Vorteil, dass bei der Anforderungserhebung jede Interessengruppe nur mit der
Variabilität (bzw. Funktionalität) des Systems konfrontiert wird, die für sie Erstens verständlich
und Zweitens zur Befriedigung ihrer Anforderungen von Interesse ist.
Dieses Kapitel soll dafür eine auf 2.2.4 aufbauende, Sichtweise auf die PF-Variabilität erläutern,
welche eine differenzierte Betrachtung der Variabilität nach den RE-Welten [Jarke93], [Pohl_a],
[Rollan99]:
- Subject World (Fachliche Sicht)
- Usage World (Benutzer Sicht)
- Systems World (System Sicht)
(Abbildung 2-4 RE-Welten) unterstützt.
13
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
3.2 Sichten auf Variabilität
Um die Komplexität der Darstellung auf ein Minimum zu reduzieren und durch gezielte
Darstellung den Wiederverwendungsgrad zu erhöhen, werden in diesem Abschnitt drei
unterschiedliche Sichten auf Variabilität (Abbildung 3-2) eingeführt
Wie die Abbildung illustriert, wird die Produktfamilien-Variabilität durch den Kontext der
abzubildenden Domäne, der unterstützten Systeme und die Funktionalität begrenzt. Die
Abbildungs-Variabilität des Systems beschreibt abzubildende Geschäftsobjekte mit deren
abzubildenden Daten. Die Technische Variabilität beschreibt unterstützte Systeme und
Technologien, auf denen das System zum Einsatz kommen kann. Und die Funktions-Variabilität
beschreibt die Funktionalität des Systems aus der Sicht der Systembenutzer.
Subject
World
Usage
World
System World
Development
World
Domäne
Benutzer
Systeme
Abbildung 3-2 Sichten auf Variabilität
Neben der differenzierten Betrachtung der Variabilität ist es im RE-Prozess äußerst wichtig,
widersprüchliche Anforderungen zwischen den Welten zu erkennen und Konflikte zwischen
diesen zu lösen. Dafür ist es bei der Untersuchung der Produktfamilien-Variabilität wichtig,
Abhängigkeiten zwischen einzelnen Varianten (Anforderungen) zu beschreiben, die Varianten
einer anderen Sicht beeinflussen.
3.3 Beispiel FIS
In diesem Abschnitt soll hierfür zunächst ein fiktives Beispiel für eine Produktfamilie
eingeführt werden, worauf im weiteren Verlauf der Arbeit, zu illustrativen Zwecken,
zurückgegriffen werden kann. Eine fiktive PF-Architektur für ein Flug-Informationssystem
(FIS), soll es durch die gegebene PF-Variabilität erlauben, unterschiedliche Applikationen des
FIS zu erstellen, welche über einen gemeinsamen Kern verfügen. Diese Applikationen sollen
von verschiedenen Fluggesellschaften, auf verschiedenen Flughäfen in verschiedenen Ländern
eingesetzt werden können.
14
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
Eine grobe Übersicht der Funktionalität, soll das folgende Zielmodell liefern.
Geschäftsziele
FIS
Flug-Informationssystem
Check-In
Flüge
buchen
Flüge
umbuchen
Flüge
suchen
Catering
anbinden
Zoll
anbinden
Gepäckabf.
anbinden
Mgmt.
BSC*
Passagier
Externe
Partner
Management
*Balanced Score Card
Abbildung 3-3 FIS Darstellung
Das Zielmodell des Flug-Informationssystems zeigt den Umfang des FIS auf. Das FIS soll den
Check-In ermöglichen, sowie das Suchen, Buchen und Umbuchen von Flügen erlauben. Externe
Partner (Catering, Gepäckabfertigung) und Behörden (Zoll) sollen am System angebunden
werden, um sie automatisch mit den notwendigen Informationen zu versorgen. Dem
Management soll das System ein Balanced Score Card (BSC) bereitstellen, sodass Probleme in
der Geschäftsentwicklung frühzeitig erkannt werden können.
Dabei soll es möglich sein, den Fluggesellschaften Teile der Funktionalität auf
unterschiedlichen Systemen anzubieten, sodass z.B. der Check-In (CI) entweder durch den
Passagier am CI-Terminal oder durch den CI-Mitarbeiter am CI-Schalter erfolgen kann.
Neben der Systemfunktionalität und den unterschiedlichen Einsatzsystemen, soll das System
verschiedene Dienstgütestufen bzgl. der Performanz, Sicherheit und Aktualität erlauben.
Die Auflistung der Funktionalität soll an dieser Stelle jedoch keine vollständige
Anforderungsspezifikation sein, sondern lediglich als einführendes Beispiel dienen, auf welches
im Folgenden zurückgegriffen werden kann und welches bei Bedarf erweitert bzw.
vervollständigt wird.
15
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
3.4 Modell der differenzierten Kundensicht auf Variabilität
Dieser Abschnitt erläutert die in 3.2 angesprochene differenzierte Kundensicht auf
Produktfamilien-Variabilität und beschreibt Variationsarten, die auf den unterschiedlichen
Sichten auftauchen. Das Modell in Abbildung 3-4 bietet eine abstrakte Betrachtung der Sichten
und deren Abhängigkeiten, bevor diese in den einzelnen Abschnitten detailliert betrachtet
werden.
Benutzer-
Funktionalität
Dienst-
qualität
Geschäfts-
Objekte
NFR
Dienstgüte
Benutzer-
freundlichkeit
Fu
nktions-V
ar
ia
bi
litä
t
A
bbil
dung
s-
V
ar
ia
bili
tä
t
T
echn
is
ch
e V
ar
iab
il
itä
t
Datenqualität
Geschäfts-
Systeme
Us
ag
e
W
or
ld
Subje
ct
W
or
ld
S
yst
em
W
orl
d
FR
NFR
benutzen
bilden ab
assoziieren
TR
Abbildung 3-4 Modell einer differenzierten Kundensicht auf Variabilität
Die Abhängigkeiten zwischen den Variabilitäts-Klassen werden durch gestrichelte Linien
gekennzeichnet. Wie in der Abbildung ersichtlich bestehen gerichtete Abhängigkeiten (mit
Pfeilspitze) und bidirektionale Abhängigkeiten (ohne Pfeilspitze). Neben der Einteilung von
Variabilitäts-Klassen, können funktionale Anforderungen (FR) und nicht-funktionale
Anforderungen (NFR) unterschieden werden, welche die Variabilität beeinflussen. Nicht-
funktionale Anforderungen sind dabei in der Regel Qualitätsanforderungen, welche eine
funktionale Anforderung qualitativ messbar und bewertbar machen. Zusätzlich werden durch
Geschäftssysteme technische Anforderungen (technical requirements TR) beschrieben
3.4.1 Abbildungs-Variabilität
Die Abbildungs-Variabilität beschreibt, welche Geschäftsobjekte durch die PF-Variabilität
abgebildet werden können. Objekte beschreiben dabei Daten von Gegenständen, Personen,
Unternehmensstrukturen, etc. Die Abbildungs-Variabilität wird i.d.R. durch
Domänenspezialisten, Fachpersonal, Unternehmen oder fachlich orientierte Personengruppen
16
Darstellung der Variabilität von Software-Produktfamilien durch Use Cases
bestimmt. Sie bildet die fachliche Sicht bzw. Unternehmenssicht auf das System. Aus dieser
Sicht variieren Geschäftsobjekte in Datenumfang und Datenformat, mit deren
Qualitätsattributen (Abbildung 3-5).
Geschäfts-
objekte
Datenqualität
Aktualität
Verfügbarkeit
Sicherheit
fordern
Fachliche Sicht
(Abbildungs-Variabilität)
Datenumfang
Datenformat
Abbildung 3-5 Fachliche Sicht
Das FIS (aus 3.3) soll aus Unternehmenssicht bspw. dazu dienen, Fluginformationen auf einem
System abzubilden, um bestehende Geschäftsprozesse zu optimieren und Medienbrüche zu
vermeiden. Durch das FIS abbildbare Objekte sind z.B. Flüge, Partnerflüge, Passagiere,
Flugzeuge, Mitarbeiter, etc., deren abbildbare Daten sich ebenfalls unterscheiden können.
3.4.1.1 Variabilität
in
Geschäftsobjekten
Unter Geschäftsobjekte sind hier Gegenstände, Personen, Strukturen zu verstehen, die durch ein
Informationssystem repräsentiert (bzw. abgebildet) werden sollen. Geschäftsobjekte können
innerhalb einer Produktfamilie in Art und Umfang der abzubildenden Daten variieren. Für das
Flug-Informationssystem sind z.B. Flüge, Flugpläne, Passagiere, Partnerunternehmen, etc.
abzubildende Objekte, deren Datenbeschreibung je nach Unternehmen in Art und Umfang
variieren kann. Neben der Variabilität in Art und Umfang der Daten kann sich auch die Anzahl
der Geschäftsobjekte von System zu System ändern. So könnte eine Produktfamilie bspw.
neben Flügen auch Hotels oder Mietwagen als abbildbare Geschäftsobjekte anbieten. Die
unterschiedlichen Anforderungen an die abzubildenden Geschäftsobjekte werden durch die
Variabilität abgebildet.
Der Datenumfang und das Datenformat werden durch den Systemkontext bestimmt. Hierzu
zählt neben den unterschiedlichen Unternehmenszielen und der gewünschten
Systemfunktionalität auch die Benutzergruppe, die den Datenumfang und das Datenformat
beeinflusst.
- Datenumfang: Je nach Systemkontext werden unterschiedliche Daten notwendig, um
ein Objekt angemessen zu beschreiben. Mit Daten eines Objekts (z.B.
Passagier(Kundennummer, Passagiernummer, Name, Adresse, Flugmeilen, Alter, etc.))
können Teile der realen Welt durch Informationssysteme abgebildet werden. Der
Datenumfang kann dabei von System zu System variieren.
- Datenformat: Je nach Systemkontext werden unterschiedliche Datenformate notwendig,
um das Objekt angemessen zu repräsentieren. Soll das System Videofilme abbilden, so
ist neben der textuellen Beschreibung des Objekts auch eine visuelle Abbildung
sinnvoll.
17
Ende der Leseprobe aus 122 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2002, Darstellung der Variabilität von Software-Produktfamilien durch Use Cases, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/221051
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare