1. No category

Seminar im Bereich Informatik der Systeme
Wissensverarbeitung für die Anforderungsanalyse
Wintersemester 2005/06
Seminarausarbeitung
How to treat changing requirements -
Reuse
Marcel Pokrandt
15. Februar 2006
Universität Duisburg-Essen
·
Fachbereich Ingenieurwissenschaften
·
Arbeitsgruppe Software Engineering Prof. Dr. M. Heisel
betreut durch: Dipl.-Inform. Ina Wentzla
Abteilung Informatik
Inhaltsverzeichnis
1
Einführung
1
1.1
Motivation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Anwendungsbeispiel - Wiederverwendung von Anforderungen an ein
Münzenspiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
4
1
1
Abhängigkeitsverfolgung von Anforderungen
3
2.1
Traceability-Links
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Referenzierung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Reuse Assisted Requirement Engineering
6
3.1
Schlüsselwortextraktionen . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.2
Facettierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2.1
8
Domain-Mapping Thesaurus
. . . . . . . . . . . . . . . . . . . .
3.3
Distanzmatritzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
Ähnlichkeitsmaÿ
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
10
CBR - Case Based Reasoning
12
4.1
12
Der CBR-Zyklus
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Fazit
15
6
Literaturverzeichnis
16
i
1 Einführung
Die Thematik Reuse (deutsch: Wiederverwendung ) befasst sich im Bereich der Softwareentwicklung mit der Wiederverwendung bereits aus früheren Entwicklungsprozessen entstandenen Artefakten oder ganzer Implementierungen und deren damit verbundenen Informationen. Das Ziel ist also die Wiederverwendung von bereits erarbeitetem
Wissen, das bei der aktuellen Entwicklung hilfreich sein kann.
Bereits weit verbreitet ist die Wiederverwendung von Quellcode z.B. auf Basis der
Verwendung von Softwarebibliotheken, Komponenten oder vorgefertigten Codepatterns. Die Wiederverwendung von Anforderungen birgt allerdings groÿes Potenzial,
der reinen Codewiederverwendung überlegen zu sein.
Mit dieser Thematik befasst sich diese Ausarbeitung, indem sie die Wiederverwendungsmöglichkeit von Anforderungen betrachtet.
1.1 Motivation
Die theoretischen und sofort ersichtlichen Vorteile der Wiederverwendung von Entwicklungsprodukten sind z.B.
•
Zeitersparnis bei der Entwicklung
•
dadurch resultierend geringere Kosten
•
die Verbesserung der Qualität durch Verwendung bewährter Standards und bereits getesteter Komponenten
1.2 Anwendungsbeispiel - Wiederverwendung von
Anforderungen an ein Münzenspiel
Im Folgenden wird darauf eingegangen, wie die Wiederverwendung von Anforderungen systematisch durchgeführt werden kann. Thematisiert wird der Aufbau und die
Verwendung einer Wissensbasis (Kapitel 4), der Vergleich von Anforderungen (Kapitel
3) und die Notwendigkeit der Beachtung von Abhängigkeiten (Kapitel 2).
Zur Illustration der vorzustellenden Methoden wird basierend auf [CR00] ein Anwendungsbeispiel dargestellt:
1
Tabelle 1.1: Anforderungen des neu zu entwickelnden Münzenspiels (C), [CR00]
C1
C2
C3
C4
C5
C6
C7
The system shall depict two coins that can be ipped.
At each turn the player ips both coins.
Each coin has two sides, the head and the tail.
The coins are placed on their randomly selected sides.
Every time the coins are ipped, their face values are assigned in a random fashion.
If both coins have identical face values, the user shall win.
Otherwise the user looses.
Tabelle 1.2: Anforderungen des bereits implementierten Würfelspiels (D), [CR00]
D1
D2
D3
D4
D5
D6
D7
The system shall allow players to specify the number of dice to roll.
The player shall then roll dice.
Each die represents numbers from 1 to 6.
The dice are assigned their values randomly.
Every time the dice are rolled, their values are assigned in a randomly fashion.
If the total of both dice is even the user shall win.
Otherwise the user looses.
Für ein neu zu entwickelndes Münzenspiel wurden die Anforderungen bereits vorformuliert (Tabelle 1.1). Anhand dieser anstehenden Neuentwicklung sollen Methoden
gezeigt werden, Übereinstimmungen zu bereits vorhandenen Anforderungen vergangener Projekte zu bestimmen. Diese lassen sich dann unter Umständen für die Wiederverwendung nutzen. Es wird davon ausgegangen, dass die Anforderungen und die
Implementierung eines anderen Spiels (Würfelspiel - Tabelle 1.2) bereits vorhanden
sind.
2
2 Abhängigkeitsverfolgung von
Anforderungen
Besondere Beachtung im Software-Entwicklungsprozess im Allgemeinen verdient die
Abhängigkeitsanalyse bzw. -verfolgung. Abhängigkeiten zwischen Entwicklungsartefakten, wie sie hier gemeint sind, können in zweierlei Hinsicht in Erscheinung treten:
1. als Traceability-Links
2. als Referenzierungen
2.1 Traceability-Links
Ein Traceability-Link stellt einen gerichteten aber beidseitig verfolgbaren Pfad zwischen zwei Entwicklungsartefakten dar [BGGJ99]. Diese Pfade sind vom Entwickler
zu dokumentieren und symbolisieren für ein Artefakt die Information,
•
aus welchen Artefakten dieses hergeleitet wurde (symbolisiert als auf das Artefakt gerichtete Pfade)
•
oder welche Artefakte sich aus diesem ableiten (symbolisiert als vom Artefakt
ausgehenden Pfade)
Damit lassen sich für alle Artefakte im Entwicklungsprozess angefangen bei den
Anforderungen bis zu deren Implementierungen deren jeweiligen Folgeprodukte und
Herleitungen dokumentieren, wie in Abbildung 2.1 angedeutet. Ziel ist es, erkennbar
zu machen, ob alle Anforderungen implementiert wurden und andererseits für jede implementierte Funktion sichtbar zu machen, aus welchen Anforderungen diese resultiert.
Man spricht hierbei auch von Rück- und Vorwärtsverfolgbarkeit.
Bei der Wiederverwendung ist es durch diese Auösung aber auÿerdem möglich,
neben der Wiederverwendung der Anforderungen als solche in Form von Text auch
3
Abbildung 2.1: Traceability-Links zwischen Anforderungen und daraus folgenden Entwicklungsartefakten
sämtliche deren über Traceability-Links identizierbaren Folgeprodukte in die Wiederverwendung miteinzubeziehen. Dies dürfte wohl den gröÿten Vorteil bei der Wiederverwendung von Anforderungen bieten: Durch die typische Positionierung der Anforderungsanalyse an den Anfang des Entwicklungsprozesses lassen sich bei der Wiederverwendung von Anforderungen damit wesentlich mehr Informationen mit einbeziehen,
als es bei der reinen Quellcodewiederverwendung der Fall wäre.
Da Anforderungen aber meist nicht komplett so übernommen werden, wie sie sind,
sondern den aktuellen Bedürfnissen angepasst werden, müssen auch die über die TraceabilityLinks verbundenen Folgeprodukte auf evtl. notwendig werdende Anpassungen überprüft werden (Impact-Analyse).
Die Idealvorstellung wäre, dass dem Entwickler zu diesem Zweck ein entsprechendes Tool zur Verfügung stünde, das ihn auf mögliche Auswirkungen der geplanten
Änderungen auf die Folgeprodukte hinweist.
4
2.2 Referenzierung
Anforderungen können sich gegenseitig referenzieren und damit einer weiteren Form
der Abhängigkeit unterliegen. Beispielsweise referenziert die Anforderung R2 in Abbildung 2.2 durch das Wort then die Anforderung R1.
Abbildung 2.2: gegenseitige Referenzierung von Anforderungen
Die Wiederverwendung der Anforderung R2 ohne die Einbeziehung von R1 würde
die Referenzierung verletzen und die Aussage der Anforderung wäre nicht klar. Damit
wären auch die aus den Anforderungen abgeleiteten Folgeprodukte nicht wiederverwendbar.
Referenzierungen können aber auch bei Entwicklungs-Artefakten späterer Entwicklungsschritte bestehen, die bei ihrer Wiederverwendung beachtet werden müssen. Nimmt
man z.B. eine Klasse als Folgeprodukt einer wiederverwendeten Anforderung an, die
sich aus einer anderen Klasse ableitet, so besteht hier ebenfalls eine Referenzierung
zur Vaterklasse und sie ist somit ohne diese ungültig.
Die Wiederverwendung von Anforderungen muss also die Abhängigkeitsanalyse und
-verfolgung mit einschlieÿen, um ein konsistentes Ergebnis zu erzielen. Hierbei ist der
Entwickler vorzugsweise von einem geeigneten System teilautomatisiert zu unterstützen.
5
3 Reuse Assisted Requirement
Engineering
Ein Problem im Umgang mit natürlichsprachig vorliegenden Anforderungen ist, dass
diese meist keiner festen Struktur folgen und damit äuÿerst schwierig logisch zu repräsentieren sind. Gesucht ist eine Methode, die Übereinstimmungen zwischen zwei
Anforderungen bestimmen kann und dabei über reine Textübereinstimmungen hinausgeht.
Das Akronym RARE [CR00] steht für eine Methode, die bei der Wiederverwendung
formaler Anforderungen hilfreich sein kann: Sie stellt ein Vorgehen bereit, Ähnlichkeiten zwischen Anforderungen logisch aufzubereiten und mathematisch zu berechnen.
Dieser Vorgang wird als Codizierung bezeichnet.
Die Ähnlichkeit drückt sich schlieÿlich in Form einer Zahl aus, die sich dann als
Indiz werten lässt, inwieweit die aktuelle Anforderung mit einer bereits vorhandenen
übereinstimmt und diese sich damit ggf. für die Wiederverwendung eignet.
3.1 Schlüsselwortextraktionen
Um die bereits genannten Anforderungen an ein Münzenspiel und ein Würfelspiel (in
den Tabellen 1.1 und 1.2) mit RARE zu vergleichen, werden zunächst die jeweils für
das Verständnis der Anforderung wichtigsten Terme extrahiert und ihnen eine TermRelevanz zugeordnet. Die Term-Relevanz ist eine frei wählbare Zahl zwischen 0 und 1
und repräsentiert die Wichtigkeit des Terms für die Bedeutung der jeweiligen Aussage
(summiert sollten die Termrelevanzen allerdings 1 ergeben).
Allgemein liegt die Bedeutung eines Satzes hauptsächlich in dem Verb, dem Objekt und
dem Subjekt. Im dem Beispiel wurden nach diesem Schema jeweils 4 Terme extrahiert
und ihnen die Termrelevanzen 0.1, 0.2, 0.3 oder 0.4 zugeordnet (siehe Tabellen 3.1 und
3.2).
6
C1
C2
C3
C4
C5
C6
C7
D1
D2
D3
D4
D5
D6
D7
Tabelle 3.1: Termextraktion: Anforderungen des Münzspiels (C), [CR00]
Term-Relevanz
0.4
0.3
0.2
0.1
The system shall depict two coins that can
depict
coin
two
ip
be ipped .
ip
coin
player
both
At each turn the player ips both coins.
Each coin has two sides, the head and the
coin
side
head
tail
tail.
The coins are placed on their randomly seplace
coin
side
random
lected sides.
Every time the coins are ipped, their face
assign
value
random
every
values are assigned in a random fashion.
If both coins have identical face values, the
identical
face
win
if
user shall win.
loose
user
otherwise
Otherwise the user looses.
Tabelle 3.2: Termextraktion: Anforderungen des Würfelspiels (D), [CR00]
Term-Relevanz
0.4
0.3
0.2
0.1
The system shall allow players to specify
specify
the number of
dice
player
the number of dice to roll.
The player shall then roll dice.
roll
dice
player
then
Each dice represents numbers from 1 to
represent
dice
number
each
6.
The dice are assigned their values randomly.
Every time the dice are rolled, their values
are assigned in a randomly fashion.
If the total of both dice is even the user
shall win.
Otherwise the user looses.
assign
value
dice
random
assign
value
random
every
total
even
win
if
loose
user
otherwise
Bereits beim Vergleich der Anforderungen auf Basis der extrahierten Terme sind
Analogien z.B. zwischen den Anforderungspaaren D5-C5 und D7-C7 ersichtlich. Die
Übereinstimmungen sind vor allem darauf zurückzuführen, dass hauptsächlich für das
Verständnis unwichtige Stoppwörter weggefallen sind. Dies sind in einer Sprache häug vorkommende Wörter, die hauptsächlich grammatikalische Funktion und keinen
Einuss auf den Inhalt haben (z.B. Artikel, Präpositionen, Negationen und Konjunktionen).
Vergleicht man die Anforderungen D2 und C2 nur syntaktisch auf Basis der gerade extrahierten Terme, sind keine groÿen Übereinstimmungen festzustellen lediglich das Wort player haben beide Anforderungen gemein. Andererseits fällt aber auf,
dass beide Anforderungen einen Spielzug des jeweiligen Spiels beschreiben (Rollen des
Würfels bzw. Drehen der Münze). Sowohl dice als auch coin stehen für das zentrale
Spiel-Instrument und in beiden Fällen wird dem Spiel-Instrument auÿerdem durch den
Spielzug (roll und ip ) ein zufälliger Wert zugewiesen dem Würfel eine Zahl und
der Münze eine der beiden Seiten. Die beiden Anforderungen unterscheiden sich also
in der Wortwahl, haben aber hinsichtlich der Funktionalität eine ähnliche Bedeutung.
7
3.2 Facettierung
Um nun Anforderungen unabhängig von der Wortwahl für die aktuelle Problemstellung
(im Folgenden Problem-Domäne genannt) auf Basis der funktionalen Bedeutung für
das Design (im Folgenden Lösungs-Domäne genannt) vergleichen zu können, werden
alle Anforderungen im nächsten Schritt anhand 4 funktionaler Aspekte charakterisiert
- den sogenannten Facetten:
Die Funktion der Anforderung, die manipulierten Daten, eine Vorgehensmethode und
der Kontext.
Zum Beispiel hat die Anforderung C2 (At each turn the player ips both coins) für
das Design die erwähnte Bedeutung, dass dem Spiel-Instrument ein zufälliger Wert
zugewiesen wird genau wie die Anforderung D2. Die Zuweisung ist in dem Fall eine
ausgeführte Funktion, der Wert des Instruments wird manipuliert, die Vorgehensweise
ist zufällig und sie betrit das (Spiel-)Instrument.
Die bereits facettierten Anforderungen nden sich exemplarisch in Tabelle 3.3. Hier
fallen die Parallelen zwischen den gerade betrachteten Anforderungen D2 und C2 auf,
die zuvor auf Termbasis nicht ersichtlich waren.
D1
D2
D3
D4
D5
D6
D7
Tabelle 3.3: Facettierung der Anforderungen aus Tabelle 1.2, [CR00]
Func.
Data
Method
Environ.
Func.
Data
Method
Environ.
dene
assign
dene
assign
assign
add
end
user
instrument
instrument
any
any
success
failure
multiplicy
value
value
value
value
collection
boolean
elaboration
random
iteration
direct
direct
iteration
choice
user
instrument
instrument
instrument
instrument
success
failure
C1
C2
C3
C4
D5
C6
C7
output
assign
any
any
assign
end
end
value
value
value
value
value
boolean
boolean
direct
random
any
direct
direct
choice
choice
Man hat nun also eine Methode, die Anforderungen nicht nur auf Basis ihrer Terminologie zu vergleichen, sondern aufgrund ihrer funktionalen Bedeutung. Um die
Facettierung automatisieren zu können, bedarf es jedoch eines Algorithmus eines
Domain-Mapping Thesaurus.
3.2.1 Domain-Mapping Thesaurus
Der Domain-Mapping Thesaurus (DMT) nutzt die aus den Anforderungen extrahierten relevanten Terme in Tabelle 3.1 um auf die korrekte facettierte Darstellung der
Anforderungen zu schlieÿen. Als Quelle dient dem DMT eine zuvor zu denierende
tabellarische Aufstellung (siehe Tabelle 3.4), die jedem dieser Terme der ProblemDomäne für jede der vier Facetten einen Term der Lösungs-Domäne zuordnen kann.
Ist ein Anforderungsterm charakteristisch für einen gewissen funktionalen Aspekt,
so wird eine solche ensprechende Verknüpfung deniert.
Zum Beispiel ist laut Tabelle 3.4 das Wort coin in einer Anforderung ein Hinweis
darauf, dass der Wert des Instruments manipuliert wird (data: value, environment:
instrument). ip deutet nach diesem Schema darauf hin, dass ein zufälliger Wert zugewiesen wird (function: assign, data: value, method: random).
8
Term
Tabelle 3.4: Domain-Mapping Thesaurus - (Auszug), [CR00]
Function
Data
Method
Environment
dice
card
value
value
value
coin
...
deal
ip
player
...
win
start
assign
interact
instrument
instrument
instrument
iteration
random
value
game
user
end
...
both
...
success
pair
sequence
Dies gilt allerdings nur für die gerade betrachtete Problem-Domäne eines Spiels.
Würde man die Anforderungen eines Bezahlautomaten betrachten, hätte das Wort
coin eine andere funktionale Bedeutung. Es muss vor der Anwendung des DMT die
richtige Termbasis aufgebaut oder eine evtl. schon vorhandene ausgewählt werden.
Um für die Anforderung C2 die facettierte Darstellung zu ermitteln, werden die
Facetten-Zuordnungen der vier extrahierten Terme (ip, coin, player, both) überlagert
und führen dann zu dem Ergebnis in Tabelle 3.3. Dabei kann es wie bei der Anforderung C2 zu Überlappungen kommen, die sich zunächst widersprechen:
Den Termen ip und both wurden in der Facette Method unterschiedliche FacettenTerme zugeordnet. Dieser Konikt kann aber mit Hilfe der Berechnung einer sogenannten Priorisierung automatisch aufgelöst werden, in die unter anderem die Relevanzen
der extrahieten Terme mit einbezogen werden.
So liegen nun die facettierten Anforderungen vor (vgl. Tabelle 3.3). Mit dieser Darstellungsebene ist es nun also möglich, die Anforderungen hinsichtlich ihrer funktionalen Bedeutung zu vergleichen.
3.3 Distanzmatritzen
Mit dem bisherigen Stand lässt sich nur bestimmen, ob sie in dieser Hinsicht komplett
gleich sind, oder verschieden. Das Ziel ist aber, eine Aussage darüber treen zu können,
wie stark sich zwei Anforderungen funktional ähneln und dies in einer Zahl ausdrücken
zu können. Den Facettentermen muss also eine mathematische Bedeutung zukommen.
Für jede Facette wird dazu eine quadratische Matrix angelegt, in der alle Terme
der Facette allen anderen gegenübergestellt werden. In den Schnittpunkten (x, y ) wird
der semantische Abstand zwischen den jeweiligen beiden Termen x und y angegeben,
der als frei wählbare Zahl
>= 0
als Maÿ dafür dienen soll, wie stark die Bedeutung
der Terme voneinander abweicht. Umso kleiner die Zahl, desto näher stehen sich die
Terme auf semantischer Ebene.
Abbildung 3.1 zeigt bezogen auf das Anwendungsbeispiel exemplarisch die vollständige Distanzmatrix
Df unction
für die function-Facette. Es reicht aber aus, die untere
oder die obere Dreiecksmatrix (blau markiert) mit Werten zu befüllen, da der Abstand
(x, y)
gleich dem Abstandt
(y, x)
ist.
9
Abbildung 3.1: Beispiel für vollständige Distanzmatrix
Df unction ,
[CR00]
Aus der Matrix geht hervor, dass sich z.B. add und calculate Dagegen haben die Terme end und count sinngemäÿ nichts gemein und ihnen wurde ein entsprechend hoher
df (t1 , t2 ) berechnet die normalisierte
semantische Distanz zwischen zwei Termen t1 und t2 :
semantischer Abstand zugewiesen. Die Formel
df (t1 , t2 ) =
Df (t1 , t2 )
max Df (x, y)
x,y
Es wird die semantische Distanz der Terme aus der Distanzmatrix ermittelt und
durch den gröÿten Abstand zweier Terme derselben Matrix dividiert. Dadurch kann
dieser Wert nicht mehr unbegrenzt groÿ sein - sondern entspricht einer Zahl zwischen
0 und 1.
In der obigen Distanzmatrix ist der gröÿte semantische Abstand als
6
angegeben.
Für die Terme add und calculate ergibt sich daher die normalisierte Distanz 0,166.
3.4 Ähnlichkeitsmaÿ
Um letztendlich aus den gesammelten Informationen mit Hilfe der RARE-Methode
ein Ähnlichkeitsmaÿ für den Vergleich zweier Anforderungen zu berechnen, dienen
folgende Formeln:
vP
u
2
u (wi × di (qi , ai ))
u i
P 2
reqDist(q, a) = t
, reqSim(q, a) = 1 − reqDist(q, a)
wi
i
10
reqDist(q, a)
berechnet den auf funktionaler Ebene semantischen Unterschied zwi-
q und a als Zahl aus dem Intervall [0, 1]. reqSim
i der zwei
Facetten. Mit dem Faktor wi besteht die Möglichkeit,
schen zwei facettierten Anforderungen
berechnet analog dazu die Ähnlichkeit der Anforderungen. Der Laufzähler
Summen durchläuft dabei die
die semantische Ähnlichkeit bezüglich der Facetten unterschiedlich stark zu gewichten
(die Summe der Facettengewichte muss 1 ergeben).
Abbildung 3.2 zeigt exemplarisch die Berechnung aller Ähnlichkeitsmasse bei der
Gegenüberstellung der Anforderungen des Würfelspiels mit denen des Münzenspiels.
Erkennbar sind hier die erhoten Übereinstimmungen in der Diagonale, da diese An-
Abbildung 3.2: Ähnlichkeitswerte bei Vergleich der Anforderungen mit RARE, [CR00]
Verwendung der Facettengewichtungen (wi ) function:0.4,data:0.3,method:0.2,environment: 0.1
forderungen sich funktional am nächsten stehen. Auällig ist aber auch, dass sich abweichend davon auch hohe Ähnlichkeitswerte für andere Kombinationen ergeben, die
so nicht zu erwarten gewesen wären (z.B. D4-C2, D5-C2, D2-C4). Andererseits wäre
gerade bei der Kombination D6-C6 eigentlich eine hohe Übereinstimmung verständlich
ist aber als Ergebnis des RARE-Vergleichs nicht gegeben. Der RARE-Methode sind
also bei ihrer Tregenauigkeit enge Grenzen gesetzt.
Es wurde gezeigt, wie mithilfe der RARE-Methode Anforderungen miteinander verglichen werden können und wie ihre Ähnlichkeit in Form einer Zahl berechnet werden
kann. Dadurch bestünde also die Möglichkeit, einen Datenbestand von gesammelten
Anforderungen nach Übereinstimmungen zu den Anforderungen an das neu zu entwickelnde System zu durchsuchen, um geeignete Entwicklungsartefakte für die Wiederverwendung zu bestimmen.
11
4 CBR - Case Based Reasoning
Case Based Reasoning (deutsch: fallbasiertes Schliessen oder erinnerungsbasier-
tes Schlieÿen ) ist ein Teilgebiet der Künstlichen Intelligenz und zählt zu den maschinellen Lernverfahren.
Die Methode basiert auf dem bei Menschen beobachteten Verhalten, bei neuen Problemen Analogien zu früheren ähnlichen Fällen zu suchen und deren Lösungen zu
adaptieren also wiederzuverwenden, anstatt jeden Fall allein stehend für sich zu
betrachten. Dazu wird versucht, bereits gelöste Fälle zu nden, die zur aktuellen Problemstellung eine möglichst hohe Übereinstimmung aufweisen. Als Fall bezeichnet man
in diesem Zusammenhang die Komposition aus einer Problembeschreibung und einer
Lösung (siehe Abbildung 4.1). Die Lösung umfasst alle Informationen, die zur Lösung
des Problems erarbeitet wurden.
Abbildung 4.1: CBR-Fall: Komposition aus Problembeschreibung und Lösung
4.1 Der CBR-Zyklus
In einer zentralen Fallbasis (englisch: Case-base oder Repository ) werden vergleichbar mit einer groÿen Datenbank möglichst alle zuvor gelösten Fälle für die spätere
Wiederverwendung vorgehalten. CBR beschreibt nunmehr das Vorgehen des Aufbaus
und der Verwendung dieser Fallbasis anhand eines zyklischen Prozesses.
Die 4 elementaren Schritte des CBR [AA94] heute als der CBR-Zyklus oder das
R4 -Modell
1.
bekannt sind (vgl. Abbildung 4.2):
Retrieve
Zu der aktuellen Problembeschreibung ähnliche Fälle werden in der Fallbasis
gesucht.
2.
Reuse
Eine der Lösungen der gefundenen Fälle wird zur Wiederverwendung ausgewählt.
3.
Revise
Die ausgewählte Lösung wird in Bezug auf die aktuelle Problemstellung angepasst.
12
4.
Retain
Die erarbeitete Lösung wird zur Wissensdatenbank hinzugefügt und steht späteren CBR-Prozessen zur Verfügung.
Abbildung 4.2: Der CBR-Zyklus (basierend auf Abbildung in [AJWH98])
Um diesen Zyklus maschinell unterstützen zu können, muss die aktuelle Problembeschreibung aber zuvor in eine codierte Form übertragen werden. Da CBR eine allgemein gehaltene Methode ist, ist die Problemcodierung nicht von vornherein deniert
sondern bedarf einer eigenen Implementierung. Diese codierte Problembeschreibung
muss sich abspeichern lassen und durch den Vergleich mit einer anderen codierten
Problembeschreibung musss ein Ähnlichkeitsmaÿ ermittelbar sein. Dadurch wird der
Retrieve-Prozess ermöglicht.
Durch die Einführung der RARE-Methode steht eine Möglichkeit zur Verfügung,
CBR an die Wiederverwendung von Anforderungen zu adaptieren. Dazu fasse man
eine facettierte Anforderung als codierte Problembeschreibung auf und die aus der
Anforderung abgeleiteten durch Traceability-Links identizierbaren Folgeprodukte als
die Lösung. RARE beinhaltet bereits eine Formel zur Berechnung des Ähnlichkeitsmaÿes.
13
Ginge man im Bezug auf das Anwendungsbeispiel davon aus, man würde für die
Anforderung C2 bereits gelöste Fälle mit ähnlichen Anforderungen suchen, wäre C2
zunächst zu facettieren und läge damit in einer codierten Form vor. Nun würde der
Retrieve-Prozess folgen, in dem das CBR-System ähnlich einer Suchmaschine die
zur aktuellen Anforderung ähnlichen Fälle im Repository bestimmt. Die Anforderungen des Würfelspiels benden sich zu diesem Zetpunkt schon im Repository. Üblicherweise werden eine bestimmte Anzahl von nächsten Nachbarn die Fälle mit dem
höchsten Ähnlichkeitsmaÿ präsentiertwie wie in Abbildung 4.3 angedeutet.
Abbildung 4.3: Bestimmung der 4 nächsten Nachbarn
Der Entwickler würde dann einen Fall für die Wiederverwendung ausgewählen (reuse), die Lösung anpassen (revise) und abschlieÿend den neuen Fall im Repository ablegen. Der aktuelle Fall stünde damit zukünftigen Entwicklungen ebenfalls zur Wiederverwendung zur Verfügung.
14
5 Fazit
In der obigen Ausführung habe ich die Notwendigkeit einer Abhängigkeitsanalyse gezeigt, wie Anforderungen mithilfe der RARE-Methode facettiert und verglichen werden
können und wie mithilfe von CBR ein Repository mit gelösten Fällen aufgebaut und
genutzt werden kann. Dadurch ist es möglich, zu einer aktuellen Anforderung ähnliche
Anforderungen früherer Projekte zu bestimmen und deren Folgeprodukte wiederzuverwenden.
Der Nutzen der Wiederverwendung von Anforderungen ist damit durchaus gegeben.
Fest steht allerdings, dass die Einstiegsbarriere für den normalen Entwickler sehr
hoch ist.
15
6 Literaturverzeichnis
[AA94]
E. Plaza A. Aamodt. Case-based reasoning: foundational issues, methodical variations and system approaches. AI Communications. IOS Press,
Vol. 7, 1994.
[AJWH98] Aybüke Aurum, Ross Jeery, Claes Wohlin, and Meliha Handzic. Managing
Software Engineering Knowledge. Springer, Berlin, 1998.
[BGGJ99]
K. Suzanne Barber, Thomas J. Graser, Paul S. Grisham, and Stephen R.
Jernigan.
Requirements evolution and reuse using the systems enginee-
ring process activities (sepa). Australian Journal of Information Systems
(AJIS) - Special Issue on Requirements Engineering 7, 1999.
[CR00]
Jacob L. Cybulski and Karl Reed.
Requirement classication an reuse:
Crossing domain boundaries. Sixth International Conference on Software
Reuse, Vienna, Autria, June 27-29, 2000.
16
How to treat changing requirements –
Reuse
Wissensverarbeitung für die Anforderungsanalyse
Marcel Pokrandt
Universität Duisburg-Essen, Technische Fakultät, Institut für Informatik, Arbeitsgruppe
Software Engineering, Prof. Dr. M. Heisel
15. Februar 2006
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
1 / 30
15. Februar 2006
2 / 30
Inhalt
1
Einführung
2
Abhängigkeitsverfolgung von Anforderungen
3
Reuse Assisted Requirement Engineering
4
CBR - Case Based Reasoning
5
Fazit
Marcel Pokrandt (UniDUE-SE)
KP4RE
Einführung
1
Einführung
2
Abhängigkeitsverfolgung von Anforderungen
3
Reuse Assisted Requirement Engineering
4
CBR - Case Based Reasoning
5
Fazit
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
3 / 30
Einführung
Einführung
Wiederverwendung in der Softwareentwicklung
Wiederverwendung in früheren Entwicklungsprozessen entstandener
Artefakten oder ganzer Implementierungen und deren damit
verbundenen Informationen
Ziel: Wiederverwendung von bereits erarbeitetem Wissen
bereits weit verbreitet: Wiederverwendung von Quellcode, aber:
Wiederverwendung von Anforderungen kann der
Quellcodewiederverwendung überlegen sein
Vorteile der Wiederverwendung von Entwicklungsprodukten
+ Zeitersparnis bei der Entwicklung
+ dadurch resultierend geringere Kosten
+ die Verbesserung der Qualität durch Verwendung bewährter Standards
und bereits getesteter Komponenten
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
4 / 30
Einführung
Anwendungsbeispiel
Illustration der vorzustellenden Methoden anhand eines
Anwendungbeispiels:
Neuentwicklung eines Münzenspiels - Anforderungen
bereits formuliert
zu zeigen: Methoden, Übereinstimmungen zu bereits
vorhanden Anforderungen vergangener Projekte zu
bestimmen
als vorhanden angenommen: Anforderungen und die
Implementierung eines Würfelspiels
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
5 / 30
15. Februar 2006
6 / 30
Abhängigkeitsverfolgung von Anforderungen
1
Einführung
2
Abhängigkeitsverfolgung von Anforderungen
3
Reuse Assisted Requirement Engineering
4
CBR - Case Based Reasoning
5
Fazit
Marcel Pokrandt (UniDUE-SE)
KP4RE
Abhängigkeitsverfolgung von Anforderungen
Abhängigkeitsverfolgung von Anforderungen
Besondere Beachtung im Softwareentwicklungsprozess
verdient die Abhängigkeitsanalyse bzw. -verfolgung.
Hier gemeinte Formen der Abhängigkeiten
als Traceability-Link
als Referenzierung
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
7 / 30
Abhängigkeitsverfolgung von Anforderungen
Traceability-Links
Traceability-Link: gerichteter aber beidseitig verfolgbarer Pfad
zwischen zwei Entwicklungsartefakten [BGGJ99]
Symbolisiert für ein Artefakt die Information...
aus welchen Artefakten dies hergeleitet wurde
oder welche Artefakte sich aus diesem ableiten
Damit lassen sich für alle Artefakte im Entwicklungsprozess
deren jeweilige Folgeprodukte und Herleitungen dokumentieren.
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
8 / 30
Abhängigkeitsverfolgung von Anforderungen
Traceability-Links
Traceability-Links zwischen Anforderungen und daraus folgenden Entwicklungsartefakten
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
9 / 30
Abhängigkeitsverfolgung von Anforderungen
Traceability-Links
Nutzen
Ziele
Erkennbar zu machen, ob alle Anforderungen implementiert wurden
für jede implementierte Funktion sichtbar zu machen aus welchen
Anforderungen diese resultiert
⇒ Rück- und Vorwärtsverfolgbarkeit
Vorteile für Wiederverwendung von Anforderungen
Folgeprodukte der Anforderungen über Traceability-Links identifizierbar
damit in Wiederverwendung einbeziehbar
Durch Positionierung der Anforderungsanalyse an den Anfang des
Entwicklungsprozess lassen sich wesentlich mehr Informationen in die
Wiederverwendung einbeziehen als bei Quellcodewiederverwendung
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
10 / 30
Abhängigkeitsverfolgung von Anforderungen
Referenzierung
Anforderungen können sich gegenseitig referenzieren und damit
einer weiteren Form der Abhängigkeit unterliegen.
Referenzierung aber auch bei Entwicklungsartefakten möglich
⇒ Wiederverwendung von Anforderungen muss also die
Abhängigkeitsanalyse und -verfolgung mit einschliessen, um ein
konsistentes Ergebnis zu erzielen.
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
11 / 30
15. Februar 2006
12 / 30
Reuse Assisted Requirement Engineering
1
Einführung
2
Abhängigkeitsverfolgung von Anforderungen
3
Reuse Assisted Requirement Engineering
4
CBR - Case Based Reasoning
5
Fazit
Marcel Pokrandt (UniDUE-SE)
KP4RE
Reuse Assisted Requirement Engineering
Reuse Assisted Requirement Engineering
Probleme im Umgang mit natürlichsprachigen Anforderungen
folgen keiner festen Struktur
daher äußerst schwierig logisch zu repräsentieren
→ gesucht: Methode, die Übereinstimmungen zwischen
Anforderungen erkennen kann und über reine
Textübereinstimmungen hinausgeht
RARE
Logische Aufbereitung der Anforderungen und
mathematische Berechnung der Ähnlichkeit
Ähnlichkeitsmaß lässt sich als Indiz werten, ob sich die
verglichene Anforderung für Wiederverwendung eignet
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
13 / 30
Reuse Assisted Requirement Engineering
Schlüsselwortextraktion
Extraktion der für das Verständnis wichtigsten Terme und Zuweisung einer Termrelevanz
C1
C2
C3
C4
C5
C6
C7
D1
D2
D3
D4
D5
D6
D7
Term-Relevanz
The system shall depict two coins that can be „flipped“.
At each turn the player flips both coins.
Each coin has two sides, the head and the tail.
The coins are placed on their randomly selected sides.
Every time the coins are flipped, their face values are assigned in a random fashion.
If both coins have identical face values, the user shall win.
Otherwise the user looses.
The system shall allow players to specify the number of
dice to roll.
The player shall then roll dice.
Each dice represents numbers from 1 to 6.
The dice are assigned their values randomly.
Every time the dice are rolled, their values are assigned in
a randomly fashion.
If the total of both dice is even the user shall win.
Otherwise the user looses.
0.4
depict
flip
coin
place
assign
0.3
coin
coin
side
coin
value
0.2
two
player
head
side
random
0.1
flip
both
tail
random
every
identical
loose
face
user
win
otherwise
if
specify
the number of
dice
player
roll
represent
assign
assign
dice
dice
value
value
player
number
dice
random
then
each
random
every
total
loose
even
user
win
otherwise
if
Vergleich der Anforderungen auf Termbasis:
Ähnlichkeiten zwischen den Anforderungspaaren C5-D5 und C7-D7.
Hauptsächlich durch Stoppwortelimination
Vergleich von C2 und D2: Keine Ähnlichkeit auf Termbasis.
Aber funktional ähnlich!
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
14 / 30
Reuse Assisted Requirement Engineering
Facettierung
Klassifikation der Anforderungen anhand 4 funktionaler Aspekte
Funktion, manipulierte Daten, Methode, Kontext
C2: At each turn the player flips both coins
Funktion: Zuweisung (assign), Daten: Wert (value), Methode: zufällig
(random), Kontext: Instrument (instrument)
D1
D2
D3
D4
D5
D6
D7
Func.
define
assign
define
assign
assign
add
end
Data
multiplicy
value
value
value
value
collection
boolean
Method
elaboration
random
iteration
direct
direct
iteration
choice
Environ.
user
instrument
instrument
instrument
instrument
success
failure
C1
C2
C3
C4
D5
C6
C7
Func.
output
assign
any
any
assign
end
end
Data
value
value
value
value
value
boolean
boolean
Method
direct
random
any
direct
direct
choice
choice
Environ.
user
instrument
instrument
any
any
success
failure
⇒ Methode, um Anforderungen auf Basis ihrer funktionalen
Bedeutung zu vergleichen
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
15 / 30
Reuse Assisted Requirement Engineering
Facettierung
Domain-Mapping Thesaurus
DMT nutzt die extrahierten relevanten Terme,
um facettierte Darstellung zu ermitteln
Term
dice
card
coin
...
deal
flip
player
...
win
...
both
Function
start
assign
interact
Data
value
value
value
value
Method
Environment
instrument
instrument
instrument
iteration
random
game
user
end
success
pair
sequence
Zuordnungen Domänen-abhängig
Überlagerung der Facettenzuordnungen der rel. Terme
(C2: flip, coin, player, both)
Überlappungen möglich – auflösbar durch Priorisierung
→ Facettierte Darstellung liegt nun vor
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
16 / 30
Reuse Assisted Requirement Engineering
Distanzmatrizen
Bestimmung der Ähnlichkeit zweier Facettenterme
(x, y ) - semantischer Abstand zwischen den Termen x und y
normalisierte
semantische Distanz
df (t1 , t2 ) =
Df (t1 , t2 )
max Df (x, y )
x,y
→ Wert aus Intervall [0,1]
Distanzmatrix Dfunction , [CR00]
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
17 / 30
Reuse Assisted Requirement Engineering
Ähnlichkeitsmaß
Bestimmung der Ähnlichkeit zweier facettierter Anforderungen
Ähnlichkeitsmaß
reqDist(q, a) berechnet den
auf funktionaler Ebene
semantischen Unterschied
zwischen zwei facettierten
Anforderungen q und a als
Zahl aus dem Intervall [0, 1]
v
uP
u (wi × di (qi , ai ))2
u i
P 2
reqDist(q, a) = u
t
wi
i
reqSim(q, a) = 1 − reqDist(q, a)
reqSim(q, a) berechnet
analog dazu die Ähnlichkeit
der Anforderungen
wi Gewichtung der Facetten
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
18 / 30
Reuse Assisted Requirement Engineering
Ähnlichkeitsmaß
Berechnete Ähnlichkeitswerte für das Anwendungsbeispiel
Verwendung der Facettengewichtungen (wi ) function:0.4, data:0.3, method:0.2, environment: 0.1 , [CR00]
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
19 / 30
15. Februar 2006
20 / 30
CBR - Case Based Reasoning
1
Einführung
2
Abhängigkeitsverfolgung von Anforderungen
3
Reuse Assisted Requirement Engineering
4
CBR - Case Based Reasoning
5
Fazit
Marcel Pokrandt (UniDUE-SE)
KP4RE
CBR - Case Based Reasoning
CBR - Case Based Reasoning
deutsch: „fallbasiertes Schliessen“ oder „erinnerungsbasiertes Schließen“
Teilgebiet der Künstlichen Intelligenz
basiert auf bei Menschen beobachteten Verhalten, bei
neuen Problemen Analogien zu früheren ähnlichen Fällen
zu suchen und deren Lösung zu adaptieren
→ Wiederverwendung, statt jeden Fall einzeln zu betrachten
Fall
Komposition aus einer Problembeschreibung und einer Lösung
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
21 / 30
CBR - Case Based Reasoning
CBR-Zyklus
Speicherung aller Fälle in einer zentralen Fallbasis für die
spätere Wiederverwendung
Aufbau und Verwendung der Fallbasis beschrieben durch
CBR-Zyklus
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
22 / 30
CBR - Case Based Reasoning
CBR-Zyklus
CBR-Zyklus basierend auf [AJWH98]
Marcel Pokrandt (UniDUE-SE)
1
Retrieve
Zu der aktuellen
Problembeschreibung
ähnliche Fälle werden in der
Fallbasis gesucht.
2
Reuse
Eine der Lösungen der
gefundenen Fälle wird zur
Wiederverwendung
ausgewählt.
3
Revise
Die ausgewählte Lösung wird
in Bezug auf die aktuelle
Problemstellung angepasst.
4
Retain
Die erarbeitete Lösung wird
zur Wissensdatenbank
hinzugefügt und steht
späteren CBR-Prozessen zur
Verfügung.
KP4RE
15. Februar 2006
23 / 30
15. Februar 2006
24 / 30
CBR - Case Based Reasoning
CBR-Zyklus
Adaption an RARE
codierte Problembeschreibung
facettierte Darstellung einer Anforderung
Lösung
Folgeprodukte der Anforderung
Ähnlichkeitsmaß
Durch RARE definiert (reqSim)
Marcel Pokrandt (UniDUE-SE)
KP4RE
CBR - Case Based Reasoning
CBR-Zyklus
Bezug zum Anwendungsbeispiel
gesucht: bereits gelöste Fälle mit ähnlichen Anforderungen wie C2
1
2
3
4
5
Facettierung von C2 (codierte Problembeschreibung)
Retrieval - Bestimmung und Präsentation ähnlicher Fälle
(Fälle mit dem höchsten Ähnlichkeitswert)
Auswahl eines Falls für die Wiederverwendung (reuse)
Anpassen der Lösung (revise)
Ablegen des Falls im Repository (retain)
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
25 / 30
15. Februar 2006
26 / 30
CBR - Case Based Reasoning
CBR-Zyklus
Bezug zum Anwendungsbeispiel
Bestimmung der 4 nächsten Nachbarn
Marcel Pokrandt (UniDUE-SE)
KP4RE
Fazit
1
Einführung
2
Abhängigkeitsverfolgung von Anforderungen
3
Reuse Assisted Requirement Engineering
4
CBR - Case Based Reasoning
5
Fazit
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
27 / 30
Fazit
Fazit
gezeigt wurde
Notwendigkeit der Abhängigkeitsanalyse
Facettierung und Vergleich von Anforderungen mit RARE
Aufbau eines Repositories mit CBR und Adaption an RARE
→ Bestimmung ähnlicher Anforderungen und
Wiederverwendung von Folgeprodukten
+ Nutzen durch Wiederverwendung von Anforderungen
gegeben
- Hohe Einstiegsbarriere für den „normalen Entwickler“
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
28 / 30
Bibliography
Bibliography I
Aybüke Aurum, Ross Jeffery, Claes Wohlin, and Meliha
Handzic.
Managing Software Engineering Knowledge.
Springer, Berlin, 1998.
K. Suzanne Barber, Thomas J. Graser, Paul S. Grisham,
and Stephen R. Jernigan.
Requirements evolution and reuse using the systems
engineering process activities (sepa).
Australian Journal of Information Systems (AJIS) - Special
Issue on Requirements Engineering 7, 1999.
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
29 / 30
Bibliography
Bibliography II
Jacob L. Cybulski and Karl Reed.
Requirement classification an reuse: Crossing domain
boundaries.
Sixth International Conference on Software Reuse, Vienna,
Autria, June 27-29, 2000.
Marcel Pokrandt (UniDUE-SE)
KP4RE
15. Februar 2006
30 / 30