Kurzpapier

Kurzpapier
Integration textueller Anforderungen und Modell-basiertem Testen mit SysML
Oliver Alt
Continental
Division Chassis & Safety
Electronic Brake Systems, ETC-PM
Guerickestrasse 7, D-60488 Frankfurt am Main
oliver.alt@contiautomotive.com
1
Einleitung
In der modernen System- und Softwareentwicklung bilden Anforderungen die Grundlage aller Entwicklungsaktivit¨aten. Diese Anforderungen liegen zumeist in nicht formaler Form als textuelle Anforderung oder Beschreibung
von Anwendungsf¨allen vor. Neben diesen informellen Entwicklungsdokumenten gibt es im Rahmen einer Modellbasierten Entwicklung aber auch die formalen Systemmodelle, die das System in seiner Architektur und seinem Verhalten beschreiben.
Damit ergibt sich eine L¨ucke zwischen den Anforderungen und den Systemmodellen, die nur durch den
menschlichen Entwickler gef¨ullt werden kann, der aus den
Anforderungen das Systemmodell erstellt. Ein formale, im
¨
Sinne von rechnerunterst¨utzter Uberf¨
uhrung der Anforderungen in Modelle und umgekehrt ist aufgrund des rein
informellen Charakters der Anforderungen nicht m¨oglich.
Im Folgenden wird ein Verfahren vorgestellt, das es
erlaubt, Anforderungen und Anwendungsf¨alle mit Hilfe
von Modellierungsmustern in ein formales Systemmodell
in Form von SysML-Aktivit¨atsdiagrammen zu u¨ berf¨uhren.
Umgekehrt lassen sich aus diesen Diagrammen auch die
informellen Anforderungen leicht gewinnen. Aus den erstellten Modellen lassen sich mit Hilfe von bereits erarbeiteten Verfahren Testf¨alle generieren und ausf¨uhren. Damit
kann ein solches Modell als Testgrundlage in einem Testprozess Verwendung finden.
2
SysML
Die Systems Modeling Language (SysML) [OMG07] ist
eine neue standardisierte grafische Modellierungssprache
zur Erstellung von Systemmodellen. SysML basiert auf
der Softwarebeschreibungssprache UML2. Viele bew¨ahrte
Konzepte der UML2 werden wiederverwendet, aber auch
neue Elemente und Diagramme hinzugef¨ugt und Teile weg
gelassen um die Erfordernisse des System Engineering optimal zu unterst¨utzen.
Eine der wichtigsten Neuerungen der SysML ist sicherlich das Anforderungsdiagramm und das Anforderungselement. Damit lassen sich textuelle Anforderungen erstmals als Elemente im Systemmodell darstellen und mit anderen Modellelementen verkn¨upfen. Dies erm¨oglicht zum
Beispiel eine Zuordnung von Anforderungen zu Architekturelementen oder Verhaltenselementen. Somit l¨asst sich
eine durchg¨angige Tracebility zwischen Anforderungen
und den Systemmodellelementen herstellen, wie sie von
vielen Entwicklungsprozessstandards heute eingefordert
wird. Durch den Einsatz von SysML kann damit auf der
informellen Ebene bereits eine Integration zwischen Anforderungen und dem Systemmodell erzielt werden.
3
Umsetzung von Anforderungen in ein Systemmodell
Um eine solche Integration nicht nur informell zu erreichen, muss ein Verfahren gefunden werden mit dem ein
Zusammenhang zwischen einer Anforderung und dem Systemmodell auf einer direktere Art und Weise hergestellt
werden kann. Dazu wurden Anwendungsf¨alle, Anforderungen und Systemmodelle im Hinblick auf Gemeinsamkeiten und Abh¨angigkeiten analysiert.
Als Illustrationsbeispiel f¨ur das entwickelte Verfahren
dient ein Tempomatsystem, also eine automatische Geschwindigkeitsregelung im Fahrzeug [MDC07].
3.1
Externe und interne Systemsicht
Als Ergebnis der Analyse ergibt sich ein Systembild wie es
in Abbildung 1 dargestellt ist. Ein Teil der Anforderungen
beschreibt das System aus externer Sicht und sieht das System dabei als Black-Box an. Diese Sicht ist auch diejenige,
die ein Systembenutzer hat. Er benutzt ausschließlich die
zur Verf¨ugung stehenden Schnittstellen, um mit dem System zu interagieren. Oftmals enthalten diese Anforderungen auch Bedingungen wann es einem Benutzer gestattet
ist, eine bestimmte Aktion mit dem System durchzuf¨uhren.
Bei den Anwendungsf¨allen findet sich so etwas als Beschreibung der Vorbedingung, die erf¨ullt ein muss, um den
Anwendungsfall durchzuf¨uhren.
System
externe
Sicht
Interne Sicht
Abbildung 1: Externe und interne Systemsicht
Der externen Sicht gegen¨uber steht die interne Systemsicht, die beschreibt wie sich das System intern verhalten
und funktionieren soll. Dort ist definiert welche Art von
Aktionen das System ausf¨uhren muss, um die gew¨unschte
Funktionalit¨at zu erf¨ullen.
Als drittes findet sich die Beschreibung der Verkn¨upfung beider Sichten, das heißt, es wird beschrieben
wie sich eine Aktion eines externen Systembenutzers auf
das Systemverhalten auswirkt und welche der internen
Abl¨aufe wie beeinflusst werden.
Benutzeraktivitäten
Systemaktivitäten
«user activity»
Tempomat einschalten
«system activity»
Geschwindigkeit
halten
«user activity»
Tempomat ausschalten
3.2
Verhaltensmodellierung
Aktivit¨atsdiagrammen
mit
SysML-
Viele etablierte und auch neuere Verfahren im Bereich
des Modell-basierten Testens benutzen Zustandsdiagramme, um das Systemverhalten zu beschreiben.
Im Gegensatz dazu wurde hier bewusst die SysMLAktivit¨atsmodellierung ausgew¨ahlt und dies begr¨undet
sich wie folgt:
• Durch die Verwendung von Aktivit¨atsdiagrammen
brauchen im Gegensatz zu Zustandsautomaten die
Systemzust¨ande nicht vor Modellerstellung gefunden
werden, sondern ergeben sich aus dem Systemmodell
implizit.
• Anforderungen und insbesondere Anwendungsfallbeschreibungen benutzen Aktivit¨aten, um die Systemfunktionalit¨at zu beschreiben. Daher k¨onnen solche Beschreibungen leicht in ein Aktivit¨atsdiagramm
umgesetzt werden.
Die Elemente der Aktivit¨atsdiagramme wurden bereits
mit der Version 2.0 der UML stark erweitert. Die SysML
erweitert diese neuerdings um neue Elemente. Insbesondere f¨uhrt die SysML einen neuen Typ von Aktion ein,
den so genannten Kontrolloperator, der es erm¨oglicht, das
Laufzeitverhalten einer Aktivit¨at bzw. Aktion von Außen
zu beeinflussen. Bislang war es nicht m¨oglich Aktionen
beispielsweise in ihrer Ausf¨uhrung zu unterbrechen und
an gleicher Stelle sp¨ater fortzusetzen. Dies wird nun durch
den Kontrolloperator m¨oglich und erweitert damit die Aktivit¨atsmodellierung um ein Konstrukt, das wie sich zeigt
f¨ur die Formalisierung von Anforderungen ben¨otigt wird.
3.3
Definition der Modellierungselemente
Bevor mit der Verhaltensbeschreibung begonnen werden
kann m¨ussen die erforderlichen Elemente, also Aktivit¨aten
und Objekte definiert werden. Um die externe von der
internen Systemsicht abzugrenzen werden die jeweiligen
Aktivit¨aten entsprechend gekennzeichnet:
Benutzeraktivit¨aten sind all die externen Aktivit¨aten, die
ein Benutzer des Systems mit diesem ausf¨uhren kann
(externe Sicht).
Systemaktivit¨aten sind die Aktivit¨aten die das System
intern durchf¨uhrt (interne Sicht).
Systemgr¨oßen speichern als Instanzen (Objekte) interne
Systemvariablen.
Abbildung 2 zeigt die definierten Aktivit¨aten und Systemgr¨oßen f¨ur das Tempomat-Beispielsystem.
Mit diesen Elementen l¨asst sich das Verhalten des Systems modellieren. Um die informellen Anforderungsdokumente zu formalisieren wurden unter Verwendung der Aktivit¨atsmodellierung drei Modellierungsmuster entwickelt,
«system activity»
Fahrzeug
beschleunigen
«user activity»
Wunschgeschwindigkeit
festsetzen
«user activity»
Fahrzeug beschleunigen
«system activity»
Fahrzeug verzögern
«user activity»
Fahrzeug verzögern
Systemgrössen
«enumeration»
Tem pom at
Einschaltzustand
«enum»
ein
au s
«valueType»
Wunschgeschwindigkeit
«valueType»
Fahrzeuggeschwindigkeit
Abbildung 2: Definition der Modellelemente f¨ur das Beispielsystem
die die in Abschnitt 3.1 gefundenen Anforderungstypen
umsetzten: Dies ist zum Einen die Beschreibung der Vorbedingung wann eine externe Benutzeraktion durchgef¨uhrt
werden kann. Zum Anderen die Darstellung wie sich eine
solche Durchf¨uhrung auf das System auswirkt und zu dritten wie das interne Systemverhalten aussieht.
Im Folgenden werden diese drei Muster f¨ur
das Beispielsystem anhand der Benutzeraktivit¨at
Wunschgeschwindigkeit festsetzen
exemplarisch gezeigt.
Vorbedingungen von Benutzeraktionen
F¨ur jede Benutzeraktivit¨at wird eine Vorbedingung modelliert. Dies wird mit Hilfe von Entscheidungsknoten
und Kontrollflusskanten mit den entsprechenden Bedingungen ausgedr¨uckt. Wenn die Vorbedingung erf¨ullt ist
soll die Benutzeraktivit¨at ausgef¨uhrt werden. Dies wird
dadurch ausgedr¨uckt, dass eine SendSignal-Aktion als
Instanz der Benutzeraktivit¨at durch die Kontrollfl¨usse aktiviert wird.
Tempomat ist ausgesch altet
«control Flow» [:Tempomat
Einschal tzustand == aus]
Tempoma t ist eingeschaltet
«controlFlow» [:Tempomat Einschaltzustand == ein]
«user activity»
:Wun schg esch wind igke it
festsetzen
Vorbedi ngung
Wunschgeschwin digkeit
festsetzen
notes
Der Benutzer darf die
Wunschgeschwindigkeit
festsetzen wenn der
Tempomat eingeschaltet
ist.
Abbildung 3: Modellierungsmuster f¨ur Vorbedingungen
Abbildung 3 zeigt die modellierte Vorbedingung f¨ur die
Aktivit¨at Wunschgeschwindigkeit festsetzen
und die zugeh¨orige a¨ quivalente Anforderung. Die Aktivit¨atsmodellierung erfordert auch die Alternativpfade zu
modellieren und geht damit sogar u¨ ber die Anforderung
hinaus (Nichterf¨ullung der Vorbedingung).
Abbildung 5 zeigt das interne Verhalten der
durch dir Benutzeraktion gestarteten Systemaktion
Geschwindigkeit halten.
¨
Verknupfung
von externem und internem Verhalten
Um das externe und interne Systemverhalten zu verkn¨upfen werden durch die AcceptEvent-Aktion als Signalempf¨anger und Gegenst¨uck zur Vorbedingung entspre¨
chende Abl¨aufe zur Anderung
des Systemzustands initiiert.
«controlFlow» [:Fahrzeuggeschwindigkeit >
Wunschgesch windigkeit]
«controlOperator»
enable
«controlFlow» [:Fahrzeuggeschwindigkeit <
Wunschgesch windigkeit]
«controlFlow» [:Fahrzeuggeschwindigkeit
== :Wunschgeschwin digkeit]
«controlOperator»
enable
controlValue
controlValue
«controlOperator»
«user activity»
:Wun schg esch wind igke it
festsetzen
disable
controlValue
«system activity»
controlValue
controlValue
:Fahrzeug verzögern
«valueSpecification»
enable
:Fahrzeug beschleunigen
:Wunschgeschwindigkeit
:Fahrzeuggeschwindigkeit value
«controlOperator»
«system activity»
Abbildung 5: Internes Verhalten der Systemaktivit¨at
Geschwindigkeit halten
controlValue
controlValue
«system activity»
:Geschwindigkeit halten
Wunschge schwindi gkeit fe stsetzen
notes
Wenn der Benutzer die Aktion
Wunschgeschwindigkeit festsetzen
durchführt, wird im Tempomat-System die
Wunschgeschwindigkeit auf den Wert der
Fahrzeuggeschwindigkeit gesetzt und die
Funktion Geschwindigkeit halten aktiviert.
Abbildung 4: Zuordnung von externen Aktionen zu internem Verhalten
Die Verkn¨upfung des externen und internen Systemverhaltens, die zugeh¨orige Anforderung und die entsprechende Formalisierung durch die Modellierung zeigt Abbildung 4.
Im Beispiel werden durch die Benutzeraktion eine valueSpecification- und eine control
operator-Aktion gestartet. Die valueSpecification ist
in der Lage einen Objektwert zu a¨ ndern. Der Kontrollope¨
rator erlaubt eine Anderung
des Laufzeitzustandes einer
Aktion von außen ohne einen expliziten Kontrollfluss
(starten, stoppen, anhalten, fortsetzten etc.).
Mit Hilfe des Kontrolloperators und der valueSpecification kann der Systemzustand, der sich aus den Systemgr¨ossen und den Laufzeitzust¨anden der Systemaktivit¨aten zusammensetzt durch die Benutzeraktionen beeinflusst werden.
Modellierung des internen Verhaltens
Als letztes muss noch das interne Verhalten der Systemaktion(en) beschrieben werden. Dies geschieht neuerlich
durch ein Aktivit¨atsdiagramm und unter Verwendung der
Kontrolloperatoren und valueSpecification-Aktionen.
Ein solches Diagramm ergibt sich aufgrund der Verzweigungen und unterschiedlichen Pfade aus mehreren
Anforderungen, die die Systemaktion beschreiben. Die
drei zugeh¨origen Anforderungen sind in Abbildung 6 gegeben.
Fahrzeug geschwi ndigkeit unter
Wunschgesch windigkeit
Fahrzeug geschwi ndigkei t über
Wunschgesch windigkeit
notes
Liegt die
Fahrzeuggeschwindigkeit unter
der Wunschgeschwindigkeit,
wird die Funktion Fahrzeug
beschleunigen aktiviert.
notes
Liegt die
Fahrzeuggeschwindigkeit über
der Wunschgeschwindigkeit,
wird die Funktion Fahrzeug
verzögern aktiviert.
Fahrze uggeschwindi gkeit
gleich Wunschg eschwindigkeit
notes
Ist die Fahrzeuggeschwindigkeit
gleich der
Wunschgeschwindigkeit, werden
sofern aktiv die Funktionen
Fahrzeug verzögern und
Fahrzeug beschleunigen
deaktiviert.
Abbildung 6: Beschreibung des internen Verhaltens als
Anforderungen
Die gezeigten Anforderungen in den Beispielen sind etwas idealisiert um die Zuordnung der Diagramme zu den
Texten deutlich zu illustrieren. Jedoch haben sich das vorgestellte Verfahren und die Muster bereits in der Praxis, bei
der Formalisierung von Anforderungen bew¨ahrt. Mit etwas
¨
Ubung
gelingt es leicht auch aus etwas anders formulierten
Anforderungen solche formalen Modelle aufzubauen.
4
Modell-basierte Testfallgewinnung
Mit einem nach den oben beschriebenen Mustern aufgebautem Modell lassen sich mit Hilfe des in fr¨uheren Arbeiten entwickelten Verfahrens (vgl. [SA07], [Alt07]) nun
Zustandsautomaten und letztendlich ausf¨uhrbare Testf¨alle
f¨ur den Systemtest gewinnen.
Das Verfahren basiert darauf, das eine sukzessive
Ausf¨uhrung der Benutzeraktivit¨aten die m¨oglichen Systemzust¨ande nacheinander hervorruft. Ein Zustandsautomat bildet das Ergebnis einer solchen Modellsimulation.
Mit Hilfe bekannter Verfahren lassen sich aus einem sol¨
chen Graphen dann Testf¨alle nach vordefinierten Uberdeckungskriterien ableiten.
Mit den vorgestellten Modellierungsmustern kann damit auf einfache Art und Weise ein Verhaltensmodell aus
Anforderungen aufgestellt werden, das nicht nur als formalere Dokumentation, sondern auch als Grundlage f¨ur
einen Modell-basierten Test und die Testfallgenerierung
dienen kann. Auch der Umgekehrte Weg der Ableitung
von Anforderungen aus solchen Verhaltensmodellen ist
m¨oglich und kann dazu beitragen alle notwendigen Anforderungen die das modellierte Systemverhalten beschreiben
zu erfassen. Dies kann beispielsweise dann eine Rolle spielen wenn innerhalb eines Entwicklungsprozesses textuelle
Anforderungen gefordert werden.
5
Verwandte Arbeiten
Ein werkzeuggest¨utztes Verfahren zur Extraktion von
Testinformationen aus Anforderungsspezifikationen beschreibt Sneed in [Sne05]. Bei diesem Verfahren werden
bestimmte Schl¨usselworte erfasst und daraus Testinformationen abgeleitet.
Einen a¨ hnlichen Mechanismus, allerdings mit dem Fokus auf Anwendungsfallbeschreibungen und deren Formalisierung beschreibt Friske in [FP05] und [FS07]. Dabei
werden Anwendungsfallbeschreibungen halbautomatisch
in UML-Aktivit¨atsdiagramme umgesetzt. Das beschriebene Verfahren ist sicherlich mit dem hier vorgestellten Ansatz kombinierbar, da es so abgewandelt werden kann ,dass
die vorgestellten Aktivit¨atsmuster ber¨ucksichtigt werden.
Gr¨unbauer beschreibt in [Gr¨u08] ein Verfahren um
Abh¨angigkeiten zwischen verschiedenen Systemfunktionen zu modellieren und f¨ur die Verifikation der Systeme zu nutzen. Im Gegensatz zum hier beschriebenen Verfahren kommt dabei jedoch keine Standardsprache wie
SysML sondern ein eigens entwickeltes Modellierungskonzept zum Einsatz.
In der Arbeit von Bramsiepe, Sikora und Pohl [BSP08]
werden Anforderungen aus Zielen und Szenarien abgeleitet. Dabei werden keine Aktivit¨atsdiagramme wie hier,
sondern Sequenzdiagramme eingesetzt. Die hier verwendeten Aktivit¨atsdiagramme haben den Vorteil, dass auch
Alternativen in einem Diagramm durch den Einsatz von
Verzweigungen u¨ bersichtlich beschrieben werden k¨onnen.
Mit den Aktivit¨asdiagrammen lassen sich somit prinzipiell
auch mehrere solcher Szenarien beschreiben oder daraus
ableiten.
6
Zusammenfassung und Ausblick
Mit Hilfe von SysML und den hier beschriebenen Modellierungsmustern wird die Formalisierung von Anforderungen erleichtert und damit die L¨ucke zwischen Anforderungen und formaler Systemmodellierung ein St¨uck weit verkleinert. Durch die Verwendung von SysML lassen sich
dar¨uber hinaus die Anforderungen auch ins Systemmodell
integrieren und eine durchg¨angige Tracebility zwischen
Anforderung, Modell und Testfall herstellen.
Weiterhin erm¨oglichen die vorgestellten Modellierungsmuster auch eine Herleitung von textuellen Anforderungen aus dem Systemmodell. An Konzepten eine solche Ableitung (teilweise) zu automatisieren, und damit das
Modell in den Mittelpunkt der Entwicklung zu r¨ucken,
wird momentan gearbeitet. Damit k¨onnte die L¨ucke zwischen Modell-basierter Entwicklung und Requirement Engineering mittelfristig zumindest in die Richtung der Anforderungen geschlossen werden.
Literatur
[Alt07]
O. Alt. Deriving reusable system test cases from
SysML models. In Proceedings of the Software and
Systems Quality Conference, D¨usseldorf, 2007.
[BSP08]
N. Bramsiepe, E. Sikora und K. Pohl. Ableitung von
Systemfunktionen aus Zielen und Szenarien. In GI,
Hrsg., Softwaretechnik-Trends, Jgg. 28, Seiten 13–14,
2 2008.
[FP05]
Mario Friske und Holger Pirk. Werkzeuggest¨utzte interaktive Formalisierung textueller Anwendungsfallbeschreibungenf¨ur den Systemtest. In Beitr¨age
der 35. Jahrestagung der Gesellschaft f¨ur Informatik (Band 2). A. B. Cremers and R. Manthey and P.
Martini and V. Steinhage, 9 2005.
[FS07]
M. Friske und H. Schlingloff. Generierung von
UML-Modellen aus formalisierten Anwendungsfallbeschreibungen. In M. Conrad, H. Giese, B. Rumpe und B. Sch¨atz, Hrsg., MBEES - Model Based
Engineering of Embedded Systems III. DagstuhlWorkshop, TU Braunschweig Report TUBS-SSE
2007-01, 1 2007.
[Gr¨u08]
J. Gr¨unbauer. Erkennung von Feature Interactions
auf Nutzungsebene - Modellierung und Verifikation
von Abh¨angigkeiten. In GI, Hrsg., SoftwaretechnikTrends, Jgg. 28, Seiten 5–6, 2 2008.
[MDC07] MDC.
Bedienungsanleitung MDC Tempomat
f¨ur smart for4 & Mitsubishi Colt CZ3/CZ30/CZT
Version 1.3, 2007.
http://www.misterdotcom.de/
BedienungsanleitungTempomat-smartfor4-Colt.pdf.
[OMG07] OMG. OMG Systems Modeling Language (OMG
SysMLTM ) - V 1.0. formal/2007-09-01, Object Management Group, 9 2007.
[SA07]
S. Schlecht und O. Alt. Strategien zur Testfallgenerierung aus SysML Modellen. In W.-G. Bleek, H. Schwetner und H. Z¨ullighoven, Hrsg., Software Engineering 2007 - Beitr¨age zu den Workshops, Seiten 101–
106, 3 2007.
[Sne05]
Harry M. Sneed. Reverse Engineering deutschsprachiger Fachkopnzepte. Softwaretechnik-Trends,
25(2):45, Mai 2005.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising