Konzepte zur Erweiterung des SPES Meta-Modells um Aspekte der Variabilitäts- und Deltamodellierung
Peter Manhart1, Pedram Mir Seyed Nazari2, Bernhard Rumpe2, Ina Schaefer3, und Christoph Schulze2
1Software-Variantenmanagement, Daimler AG, http://www.daimler.com
2Software Engineering, RWTH Aachen, http://www.se-rwth.de
3Software Engineering and Automotive Informatics, TU Braunschweig, http://www.tu-bs.de/isf
Abstract:In diesem Beitrag werden Konzepte zur Erweiterung eines mehrperspekti- vischen Meta-Modells (am Beispiel des SPES Meta-Modells) um Aspekte der Varia- bilitätsmodellierung durch das Konzept der Delta-Modellierung vorgestellt. Die Kon- zepte werden exemplarisch anhand der logischen und der funktionalen Perspektive des SPES Meta-Modells illustriert. Die vorgestellten Konzepte können ohne Weiteres auch auf die Anforderungs- und die technische Perspektive angewendet werden. Eine Be- sonderheit dabei sind die Cross-Cutting-Deltas. Diese gruppieren Deltas der einzelnen Perspektiven und ermöglichen somit Deltas über mehrere Perspektiven hinweg.
1 Einleitung
Das SPES Meta-Modell [Po12] basiert auf einer schrittweisen Verfeinerung der Systembe- schreibung und wurde im Rahmen des vorangegangenen Forschungsprojekts SPES 2020 entwickelt. Ziel dieses Forschungsprojektes ist die durchgängig modulare und modellba- sierte Entwicklung von eingebetteten Systemen. Dabei wird das System aus unterschied- lichen Perspektiven (oft auch Viewpoints genannt) - Anforderungs-, funktionale oder lo- gische Perspektive - und auf unterschiedlichen Abstraktionsebenen betrachtet. Diese Auf- teilung (Abstraktionslevel und Perspektiven) teilen das SPES Meta-Modell in eine (SPES- )Matrix ein (siehe Abbildung 1). Das Meta-Modell fordert nicht ein, dass auf jedem Gra- nularitätslevel und in jeder Perspektive Systemelemente spezifiziert werden. Das bedeu- tet, dass ein Modell in Level n beispielsweise auch erst 3 Level tiefer verfeinert werden kann. Auch muss kein Modell einer bestimmten Perspektive in den anderen Perspekti- ven auf demselben Level existieren. Das SPES Meta-Modell erlaubt es, eine Vielzahl von verschiedenen Sprachen, wie zum Beispiel Sequenzdiagramme, Tabellen, Aktivitätsdia- gramme und Zustandsdiagramme, zu verwenden. Des Weiteren sind die Zellen der SPES- Matrix in der Regel modular, d.h., diese können unabhängig voneinander entwickelt wer- den. Außerdem sind weitere Erweiterungen des Meta-Modells, sowohl um Perspektiven (Viewpoints) als auch um neue Sprachen innerhalb der Perspektiven, im Zuge weiterer Forschungsarbeiten beabsichtigt.
In diesem Artikel wird ein Ansatz vorgestellt, um das SPES Meta-Modell - beispielhaft für mehrperspektivische Meta-Modelle mit beliebig vielen Abstraktionsleveln und Sprachen - um Aspekte der Variabilitätsmodellierung durch das Konzept der Delta-Modellierung zu erweitern. Die Delta-Modellierung [CHS10, Sc10] ist dafür gut geeignet, da sie eine modulare und sprachunabhängige Möglichkeit darstellt, die Variabilität von Softwarear- tefakten zu beschreiben. Eine Systemfamilie wird dabei durch ein ausgezeichnetes Kern- system und eine Menge von Deltas beschrieben. Das Kernsystem ist eine vollständige Systemvariante, die mit bewährten Prozessen entwickelt werden kann, um ihre Qualität sicherzustellen. Ein Delta beschreibt Modifikationen des Kernsystems, um weitere Sys- temvarianten zu realisieren. Modifikationen sind in der Regel das Hinzufügen, Entfernen, Verändern oder Ersetzen von Systemelementen. Durch Anwendung einer Menge von Del- tas auf das Kernsystem können diese Systemvarianten automatisch erzeugt werden. Eine konkrete Variante ist dann jeweils durch das Basismodel und einer konkreten Kombina- tion von Deltas gegeben. Dies erlaubt auch die Wiederverwendung einzelner Deltas, um unterschiedliche Varianten zu beschreiben. Zum Beispiel kann die grundsätzliche Funk- tionalität einer Steuerung für die Innenraumbeleuchtung eines Autos als Basismodell de- finiert werden. Diese schaltet abhängig vom Zustand des zugehörigen Lichtschalters das Licht an oder aus. Eine Steuerung, die unabhängig vom Zustand des Lichtschalters auch bei Öffnung der Tür das Licht einschaltet, wird dann als Variante des Basismodells de- finiert. Dazu ist es nur nötig, die zusätzliche Funktionalität und die Modifikationen der Basisfunktionalität in einem Delta zu beschreiben.
Der weitere Aufbau dieses Papiers ist wie folgt: Einen Überblick über verwandte Arbeiten gibt Abschnitt 2. Abschnitt 3 beschreibt kurz die Idee zur Erweiterung des SPES-Meta- Modells um Konzepte der Delta-Modellerierung und wird in Abschnitt 4 exemplarisch für Deltas innerhalb einer Perspektiven als auch über mehrere Perspektiven hinweg angewen- det. In Abschnitt 5 wird das Konzept anhand eines konkreten Beispiels veranschaulicht.
Abschließend fast Abschnitt 6 den vorgestellten Ansatz zusammen.
2 Verwandte Arbeiten
Variabilitätsmodelle können den Problemraum eines Systems, d.h., die Interessen und Wünsche der Stakeholder, oder den Lösungsraum erfassen. Lösungsraumvariabilität (so- lution space variability[Me07]) behandelt die Variabilität von wiederverwendbaren Arte- fakten, wie Architekturelementen oder anderen Entwicklungsdokumenten. Im Folgenden werden Variabilitätsmodellierungsansätze, für den Lösungsraum betrachtet, da sich der in diesem Artikel vorgestellte Ansatz auf den Lösungsraum bezieht. Die verschiedenen existierenden Ansätze eignen sich unterschiedlich gut zur Erweiterung der SPES Meta- Modells um Aspekte der Variabilitätsmodellierung. Die zwei wichtigen Einflussfaktoren dabei sind die Sprachunabhängigkeit und Modularität eines Ansatzes.
Annotative Ansätze (annotative approaches) fassen alle Varianten in einem einzigen Mo- dell (oft 150%-Modell genannt) zusammen, was eine feingranulare Repräsentation der Unterschiede zwischen den einzelnen Varianten erlaubt [Gr08]. Variantenannotationen, wie zum Beispiel UML-Stereotypen [Go05] oder Presence Conditions [Cz05], definieren
welche Teile des Modells entfernt werden müssen, um ein konkretes Modell eines Pro- dukts zu erhalten. Beim Orthogonal Variability Model (OVM) [PBL05] wird Variabilität in einem Variabilitätsmodell, das von den Artefakten getrennt ist, modelliert. Zwischen dem OVM und Artefakten werden explizit Verbindungen gezogen. Ist eine Variante nicht ausgewählt, werden die dazugehörigen Artefakte entfernt. Annotative Ansätze sind grund- sätzlich sprachunabhängig, jedoch wird Variabilität monolithisch und nicht modular be- schrieben. Damit sind sie eingeschränkt für das SPES-Meta-Modell verwendbar.
Kompositionale Ansätze (compositional approaches) zerlegen die Variabilität eines Sys- tems in geeignete Systemfragmente. Sie verknüpfen diese Fragmente mit Produktfeatures, so dass die Fragmente zu einer bestimmten Featurekonfiguration durch den gewählten Kompositionsmechanismus zusammengesetzt werden können. Dabei werden z.B. aspek- torientierte Mechanismen [HW07, NK08, VG07] zur Modellierung von Variabilität ver- wendet. Im feature-oriented model-driven development (FOMDD) [TBD07] werden Mo- dellfragemente, die mit einem Produktfeature verknüpft sind, zu Featuremodulen zusam- mengefasst. In diesen Featuremodulen können Modellierungselemente hinzugefügt oder verfeinert werden. Für eine bestimmte Featurekonfiguration werden die entsprechenden Featuremodule nach den Prinzipien der schrittweisen Verfeinerung [BSR04] kombiniert.
Kompositionale Ansätze beschränken die Modellierung der Variabilität auf den gewähl- ten Kompositionsmechanismus. Sie sind daher nicht sprachunabhängig und ebenfalls nur eingeschränkt zur Erweiterung des SPES-Meta-Modells geeignet.
Bei transformationalen Ansätzen (transformational approaches) wird die Variabilität ei- nes Systems durch die Transformation eines Basismodells repräsentiert, um eine Produkt- variante zu erhalten, wie z.B. in der Common Variability Language (CVL) [Ha08]. Der in diesem Beitrag verwendete Ansatz der Delta-Modellierung ist ebenfalls ein transfor- mationaler Ansatz. Ein Beispiel für die Delta-Modellierung von Softwarearchitekturen ist die ArchitekturbeschreibungsspracheΔ-MontiArc [Ha11a, Ha11b]. Transformationale Ansätze, wie die Delta-Modellierung, sind modular und sprachunabhängig, so dass diese sich ausgezeichnet für die Erweiterung des SPES-Meta-Modells eignen.
3 Delta-Modellierung im SPES Meta-Modell
Die Delta-Modellierung zur Variantenbeschreibung lässt sich aufgrund ihrer Sprachunab- hängigkeit und ihrer Modularität konzeptuell sehr gut in das SPES Meta-Modell integrie- ren. Dabei haben wir das Meta-Modell so erweitert, dass Deltas genutzt werden können, um Variabilität innerhalb einer Perspektive und über Perspektiven hinweg zu beschreiben (siehe Abbildung 1). Da innerhalb der SPES-Matrix zwischen einzelnen Artefakten un- terschiedlicher Abstraktionsebenen und auch zwischen Artefakten unterschiedlicher Per- spektiven Abhängigkeiten bestehen können, ist es notwendig, diese nach Anwendung von Modifikationen durch Deltas konsistent zu halten. Dies bedeutet, dass für jede Modifika- tion, die Elemente verändert, entfernt oder einführt, die in Abhängigkeit zu Elementen anderer Artefakte stehen, entsprechende Modifikationen auch an den jeweils anderen Ar- tefakten durchgeführt werden müssen, um das gesamte System konsistent zu halten.
*( '&
%
$#" $#! $#; $#9
)'&%$
#""'!9$&7 '#"'!
5'!31'/%#-'
+!*33(+;%%#":()'&%$
87'! 4'9!'!' 2*0'! $&&'.
5'!31'/%#-'"
9#",':
#75317/-+)7< :$+78 #6+<-34
%23-50/-+6<3.7)7.
,562
=7+<
Abbildung 1: Delta-Meta-Modell als Querschnitt im SPES-Meta-Modell
Jede Perspektive der SPES-Matrix kann durch Konzepte der Delta-Modellierung erwei- tert werden, um Deltas für die jeweiligen Artefakte der Perspektive, aber auch Deltas, welche sich auf unterschiedliche Artefakte einer oder mehrerer Perspektiven gleichzeitig auswirken, zu definieren. Dies erlaubt auch Referenzen zwischen Artefakten und zwischen Perspektiven zu modifizieren. Dabei wird die Variabilität für alle Perspektiven konzeptio- nell gleichartig beschrieben. Die Variabilität unterschiedlicher Perspektiven kann in einem gemeinsamen Delta (siehe Abschnitt 4) zusammengefasst werden, um gleichzeitig Sys- temvarianten für unterschiedliche Perspektiven zu erzeugen.
Abbildung 2 zeigt das Delta-Meta-Modell (weiße Klassen, links), welches die syntakti- sche Struktur von Deltas vorgibt. Jedes Delta wird in einer der beiden Unterklassen der abstrakten KlasseDeltaModeldefiniert.
**('&%$(#%""
!@=%(;85@=
2//-
+)D%@$B(#@?
!@=%(:7@$(%)8D -
+)D%@$B(#@?
48D%@1%
.,2 7($@D%
G77=)#(%)8D:$5@$48D&%$()D%
.,2
;85)BEC=@A@D%
+**)('&'%#
!'&$"')('&'%#
!'.(-,')('&'%#
>)A7=@!@=%(;85@=
4$8&&4<%%)D9!@=%(;85@=
"!4321/4-+ 0+-3. 0/,
48A78&)%@6&@$
3<D#%)8D
"!4321/4-+
*1)('/142
&)2-%/$)+
0@7=(#@63 0@A8I@63 G5563
HE7@
F8$%
46348D%@1%
6&@$3<D#%)8D 6348D%@1%
;85)BE63
(55&
$@A8I@&
$@7=(#@&
A85)B)@&
G=&8 G55F8$%
0@A8I@F8$% (D5 0@7=(#@F8$%
87@$(%)8D&
#)+2-
&)2-%/$)+
-
Abbildung 2: Delta-Meta-Modell (l.) und beispielhafte Erweiterung des funktionalen VPs Deltas innerhalb einer Perspektive werden in SimpleDeltaModelund Deltas über
mehrere Perspektiven hinweg inCrossCuttingDeltaModelspezifiziert. Jedes Del- ta enthält mindestens ein ModifyElement, welches den zu modifizierenden Kontext (Context) referenziert. Ein Kontext gehört zu Elementen, die innere Elemente enthal- ten können, und kann ebenfalls hierarchisch dekomponiert sein. Auf diese Weise ist es möglich, innere Elemente einer Hierarchie zu modifizieren (zum Beispiel durch Löschen oder Hinzufügen). Modifikationen des Kontexts sind als DeltaOperations spezifi- ziert und beinhalten das Hinzufügen (AddElement), Löschen (RemoveElement), Er- setzen (ReplaceElement) und Modifizieren (ModifyElement) von Elementen. Des Weiteren kann ein Delta einenApplicationOrderConstraint(AOC) enthalten, um explizit Abhängigkeiten zwischen Deltas zu modellieren. Dieser wird in Fällen be- nötigt, in denen Deltas dasselbe (Kern-)Modell modifizieren oder Produktfeatures reali- sieren, die voneinander abhängen. EinCrossCuttingDeltaModelenthält zusätzlich SimpleDeltaModels(siehe Abschnitt 4).
4 Exemplarische Erweiterung von ausgewählten SPES-Perspektiven
Deltas innerhalb eines Viewpoints Die Erweiterung des Meta-Modells um Konzep- te der Delta-Modellierung innerhalb einer Perspektive wird anhand der funktionalen Per- spektive beispielhaft am (vereinfachten) Functional-Black-Box Modell [Po12] be- schrieben (siehe 2). Diese Konzepte können ebenfalls für andere Modelle innerhalb der funktionalen und auch anderer Perspektiven angewendet werden. Solche Deltas werden durchSimpleDeltaModel-Elemente modelliert (siehe Abbildung 2).
Wir schlagen folgende (grobe) Vorgehensweise zur Erweiterung einer ModellspracheM um Konzepte der Delta-Modellierung vor:
1. Für jedes konzeptuelle SprachelementEeiner ModellspracheMist zu bestimmen, ob es modifizierbar ist bzw. sein soll (weiter mit(2)) oder nicht (weiter mit(4)).
Beispiel: In Abbildung 2 ist das ElementType nicht modifizierbar1. EinType kann somit nicht über Delta-Operationen ersetzt, gelöscht oder hinzugefügt werden, zumindest nicht direkt (siehe unten).
2. SollEmodifizierbar sein, müssen die Operationen (typischerweise Einfügen, Ent- fernen oder Ersetzen) festgelegt werden, die aufEanwendbar sind. SollEersetz- bar sein, ist eine Unterklasse von ReplaceElement zu erstellen, welche die Ersetzen-Operation für E darstellt. Analog gilt dies für die Hinzufügen- (Add- Element) und Löschen- (RemoveElement) Operationen. Beispiel: Das Element Portaus Abbildung 2 ist beispielsweise ersetzbar, weshalb es ein entsprechendes ElementReplacePortgibt. Handelt es sich beiEum ein komplexer aufgebautes Element, das heißt, ein Element, welches weitere Elemente enthalten kann, weiter mit(3), ansonsten weiter mit(4).
3. Sollen die inneren Elemente eines komplexeren SprachelementsEnicht explizit mo- difiziert werden (ohne dabeiEkomplett austauschen zu müssen), weiter mit(4). Bei-
1Dies ist lediglich eine Designentscheidung und soll als Beispiel zum Verständnis des Ansatzes beitragen.
spiel: Dies kann in Abbildung 2 beiPortder Fall sein. EinPorthat zwar einen Type, allerdings wurde aus methodischen Überlegungen entschieden, dass dieser nicht ausgetauscht werden können soll. Um den Typ eines Ports auszutauschen, muss somit der ganze Port überReplacePortausgetauscht werden. Ist eine Mo- difikation innerer Elemente möglich, wird fürEein KontextCerstellt, welcher das InterfaceContextaus Abbildung 2 implementiert. Besitzt eine UnterklasseE_Sub von Eweitere - nicht in Eenthaltene - modifizierbare Elemente, muss ebenfalls ein KontextC_SubfürE_Suberstellt werden, welcher eine Unterklasse vonCist.
Zusätzlich ist die Erstellung einer Unterklasse vonModifyElementnotwendig, welche die Modifikations-Operation fürEdarstellt. Zusätzlich kann, beispielsweise über OCL-Constraints, festgelegt werden, welche Delta-Operationen innerhalb des KontextesCerlaubt sind.
Beispiel: In Abbildung 2 sind solche hierarchische ElementeUserFunctionund CompositeUserFunction. Letzteres ist eine Unterklasse des Ersteren und kann zusätzlich zu Ports andere (Composite-)UserFunctionsenthalten. Diese Vererbungsstruktur wird ebenfalls in den beiden KontextenUFContextundCUF- Context widergespiegelt. Die Modifikations-Operation ModifyUFeignet sich sowohl fürUserFunctionals auch fürCompositeUserFunction. Eine ei- gene Modifikations-Operation fürCompositeUserFunctionist nicht notwen- dig, da abhängig vom aktuellen Kontext (UFContextoderCUFContext) mittels Constraints bestimmt werden kann, ob Delta-Operationen zum Hinzufügen (Add- UF), Löschen (RemoveUF) und Ersetzen (ReplaceUF) vonUserFunctions er- laubt sind (wennCUFContext) oder nicht. Entsprechende Delta-Operationen gibt es für die Ports einerUserFunction.
4. Gibt es weitere Sprachelemente inM, welche noch nicht betrachtet wurden, weiter mit(1), ansonsten ist die Spracherweiterung fertiggestellt.
Zu beachten ist, dass dieses grobe Verfahren unbedingt ergänzt werden sollte um spezifi- sche Überlegungen, die in weiteren Operatoren münden. Zum Beispiel sind Refactoring- artige Operatoren sinnvoll, die an mehreren Stellen gleichzeitig Typen ersetzen und so per Konstruktion Konsistenz sichern. Weitere Operatoren könnten die Expansion oder Kapse- lung von Teilstrukturen ermöglichen, etc.
Im obigem Ansatz bleibt die BasisspracheMbei der Erweiterung unverändert, stattdes- sen werden für die Spracherweiterung im Meta-Modell Adaptoren (zum BeispielUFCon- text) verwendet, um eine Verknüpfung zwischen dem Delta-Meta-Modell und dem Basis-Meta-Modell herzustellen. Das hat unter anderem den Vorteil, dass für die Basis- modelle keine Abhängigkeiten zu den Delta-Modellen entsteht.
Cross-Cutting-Deltas Im vorherigen Abschnitt wurde beschrieben, wie das SPES Meta- Modell für einen Modelltyp innerhalb einer Perspektive um Delta-Konzepte erweitert wer- den kann. Dieser Abschnitt beschäftigt sich mit der Modellierung von Cross-Cutting- Deltas. Charakteristisch für solche Deltas ist, dass sie sich in der Regel auf zwei oder mehrere Artefakte unterschiedlichen Modelltyps beziehen. Somit eignen sie sich sowohl für Artefakte unterschiedlichen Typs innerhalb derselben Perspektive, aber auch für die
"!65420 -!31!/./,
$"876420".5"313/
0".5"-7/1$"87642 0".5"313/
,+51
*")/
+*/4,5!/20 )024( )!'
0".5"-7/1(-1) '&36/7"3
,+51
*")/
(-1) '&36/7"3
%152461$"80".
%1."#1$"80".
!99$"80".
%152461('
%1."#1('
!99(' +*/4,5!/20 &%
$.,23!#.0 "!65420 &%
$.,23!#.0
Abbildung 3: Cross-Cutting Delta am Beispiel zweier Perspektiven
Modellierung von Abhängigkeiten in unterschiedlichen Perspektiven. Im Folgenden wer- den Cross-Cutting-Deltas über mehrere Perspektiven hinweg am Beispiel der funktionalen und logischen Perspektive des SPES Meta-Modells beschrieben.
In Abbildung 3 existiert zwischenLogicalComponentaus der logischen Perspekti- ve undUserFunctionaus der funktionalen Perspektive eine Aggregationsverbindung.
Die Bedeutung der gestrichelten Pfeile ist analog zu Abbildung 2. So stelltAddLogCom die Verbindung seitens derUserFunctionher. Die Modifikation der Aggregation be- trifft beide Perspektiven. Wird beispielsweise die Aggregation ausLogicalComponent entfernt, so muss diese auch ausUserFunctionentfernt werden, um beide Artefak- te konsistent zu halten. Dies wird durch einCrossCuttingDeltaModel(siehe Ab- bildung 2) mittels entsprechenden Delta-Operationen für die einzelnen Perspektiven (be- ziehungsweise Artefakte) sichergestellt. Das heißt, ein CrossCuttingDeltaModel bündelt (neben denSimpleDeltaModels, siehe Abbildung 2) für jede Perspektive die notwendigen Delta-Operationen, um ein Delta über mehrere Perspektiven umzusetzen. In Abbildung 3 wird zum Entfernen der Aggregation die Delta-OperationRemoveLogCom auf der funktionalen Perspektive undRemoveUFauf der logischen Perspektive benötigt.
Die Delta-OperationenAdd-,Remove- undReplaceLogCom, sowieAdd-,Remove- undReplaceUF erben entsprechend der Meta-Modelle in den vorherigen Abschnitten von den KlassenAdd-,Remove- undReplaceElementdes Delta-Meta-Modells (aus Platzgründen nicht abgebildet). Ein Cross-Cutting-Delta sorgt dafür, dass diese beiden Deltas auch existieren, da der Zustand inkonsistent wird, wenn nur in einer Perspektive die Aggregation entfernt wird.
Bevor die Cross-Cutting-Deltas bei der Variantengenerierung angewendet werden, werden zunächst alle Deltas, die nur eine Perspektive betreffen (SimpleDeltaModel), ange- wendet, so dass die einzelnen Perspektiven für sich in einem konsistenten Zustand sind.
Anschließend folgen die Cross-Cutting-Deltas, um die Konsistenz zwischen den Perspek- tiven sicherzustellen.
5 Beispiel
Im Folgenden wird das Erstellen einer neuen Variante über mehrere Perspektiven hinweg exemplarisch dargestellt. Das zugrunde liegende Szenario ist die Modellierung zweier Va- rianten einer Steuerung der Innenraum-Beleuchtung für Autos. Dabei ist die Komplexität der Anforderungen gering gehalten, um die Anwendung von Cross-Cutting-Deltas, bzw.
SimpleDeltas, anschaulich darzustellen. Das Kernmodell beschreibt die einfachste Varian- te der Steuerung, welche es nur ermöglicht, das Licht innerhalb des Autos mittels Schalter ein- und auszuschalten. Die zweite Variante, welche das Licht auch einschaltet, wenn eine Autotür geöffnet ist, wird durch entsprechende (Cross-Cutting-)Deltas modelliert. Sowohl das Kernmodell, als auch die Variante, welche durch Anwendung der Deltas entsteht, sind in Abbildung 4 dargestellt. Dabei sind alle hinzugefügten Elemente blau gekennzeichnet.
Elemente, die durch ein Delta entfernt wurden, sind rot gekennzeichnet.
Innerhalb der Anforderungsperspektive wurde jeder Variante einHardGoalzugeordnet, welches durch jeweils eineUserFunctionrealisiert ist. Hierbei entsteht schon die erste Beziehung zwischen zwei Perspektiven: einHardGoalist in der funktionalen Perspekti- ve als eineUserFunctionrealisiert. Eine weitere Beziehung zwischen zwei Perspekti- ven entsteht durch die Realisierung einerUserFunctiondurch entsprechende logische Komponenten. Um die VarianteInLightCtrl_DSeinzuführen, ist es wegen dieser Be- ziehungen zwischen den Perspektiven notwendig, ein Cross-Cutting-Delta zu definieren.
Dieses führt in einem ersten Schritt die zugehörigen Modifikationen in jeder Perspektive durch (einfache Deltas, grau unterlegt), um anschließend Deltas anzuwenden, welche die Beziehungen zwischen den Perspektiven modifizieren (Cross-Cutting-Deltas, hellgrau un- terlegt). Das Hinzufügen des GoalsInLightCtrl_DS, welches die angesprochene An- forderung definiert, und dessen Abhängigkeit zum GoalInLightCtrl, führt zu einer notwendigen Umstrukturierung innerhalb der funktionalen Perspektive, da die gegebene Funktionalität nun durch eine Komposition zweier Funktionen definiert wird.
Innerhalb der logischen Perspektive wird die definierte Funktionalität durch eine Modifi- kation derInLightCtrlKomponente realisiert. Zur Veranschaulichung ist in Listing 1 der Pseudocode des zugehörigen Deltas angegeben. In Zeile 2 wird die zu modifizierende logische Komponente angegeben und in den folgenden Zeilen werden zuerst notwendi- ge Ports und Komponenten hinzugefügt, um dann abschließend zugehörige Verbindungen
Delta-MontiArc
1 delta DoorState {
2 modify component InLightCtrl {
3 add port in Boolean doorStatus;
4 add component Or or;
5
6 connect SwitchStatus -> or.inputA;
7 connect DoorStatus -> or.inputB;
8 connect or.output -> LightCmd;
9 }
10 }
Listing 1: Exemplarische Modifikation der KomponenteInLightCtrldurch ein Delta.
)'&%
$&#")'&%
*('&%$#"#!?
$&#")'&%
*('&%$#"#!?<96
30 -!+))&(% #$+
?&%$# )C&#A$> #$+
;)+! &) 85?+ #2 )C&#A$ #$+ &(#+!&2!
?&%$# 2(/2..,
*. 2(+ E22! &) 2-+(> #$+ &(#+!&2!
?&%$# &) 2(,
!:8642'8&% 0%&6. 0',
*(<#!:8642'8
*('&%$#"#!?
;'#4 6C&#A$6#8#;)
;'#4 '&%$#6#8#;)
;'#4 922!6#8#;)
975<
322?+8(
3'126&% /'-5'8<84
*(<#!:8642'8
*('&%$#"#!?<96
6C&#A$6#8#;)
922!6#8#;) '&%$#"DE
+8321=4/4#%
/'-5'(24<*(<#!:8642'8
*('&%$#"#!?
BEE@28?
BEE'"
BEE=:
BEE72!#
BEE'2%"$
4+D21+
'2%"2D
BEE'2%"2D BEE=:
4+D21+
=:
BEE72!#
BEE@28?
BEE=:
Abbildung 4: Ein Cross-Cutting-Delta über drei Perspektiven.
zu etablieren. Dieses Delta kann grundsätzlich losgelöst von den jeweils anderen Deltas definiert und auch in anderem Kontext verwendet werden.
6 Zusammenfassung
In diesem Artikel wurde ein Ansatz vorgestellt, das mehrperspektivische SPES Meta- Modell um Aspekte der Variabilitätsmodellierung durch das Konzept der Delta-Model- lierung zu erweitern. Dabei wurde ein allgemeines Delta-Meta-Modell eingeführt, welches zwischen Deltas innerhalb einer Perspektive (bzw. Modelltyps) und Deltas über mehre- re Perspektiven (bzw. Modelltypen) hinweg unterscheidet. Das allgemeine Delta-Meta- Modell kann durch Hinzufügen von Adaptoren für die einzelnen Sprachen des SPES Meta-Modells angepasst werden. Das Konzept wurde anhand eines kurzen Beispiels ver- anschaulicht. Es ist geplant, dass Konzept an einem größeren Beispiel zu evaluieren, um die Komplexität beim Variantenmanagement mittels Delta-Modellierung zu untersuchen.
Literatur
[BSR04] Don S. Batory, Jacob Neal Sarvela und Axel Rauschmayer. Scaling Step-Wise Refi- nement.IEEE Trans. Software Eng., 30(6):355–371, 2004.
[CHS10] D. Clarke, M. Helvensteijn und I. Schaefer. Abstract Delta Modeling. InGPCE.
Springer, 2010.
[Cz05] Krzysztof Czarnecki. Mapping features to models: A template approach based on superimposed variants. InGPCE 2005, Seiten 422–437. Springer, 2005.
[Go05] Hassan Gomaa. Refactoring: Improving the Design of Existing Code. Addison- Wesley, Reading, 2005.
[Gr08] Hans Grönniger, Jochen Hartmann, Holger Krahn, Stefan Kriebel, Lutz Rothhardt und Bernhard Rumpe. View-Centric Modeling of Automotive Logical Architectu- res. InTagungsband des Dagstuhl-Workshops MBEES: Modellbasierte Entwicklung eingebetteter Systeme IV, 2008.
[Ha08] O. Haugen, B. Moller-Pedersen, J. Oldevik, G.K. Olsen und A. Svendsen. Adding Standardized Variability to Domain Specific Languages. InSoftware Product Line Conference, 2008. SPLC ’08. 12th International, Seiten 139 –148, sept. 2008.
[Ha11a] Arne Haber, Thomas Kutz, Holger Rendel, Bernhard Rumpe und Ina Schaefer. Delta- oriented Architectural Variability Using MontiCore. InECSA ’11 5th European Con- ference on Software Architecture: Companion Volume, New York, NY, USA, Septem- ber 2011. ACM New York.
[Ha11b] Arne Haber, Holger Rendel, Bernhard Rumpe und Ina Schaefer. Delta Modeling for Software Architectures. InTagungsband des Dagstuhl-Workshop MBEES: Mo- dellbasierte Entwicklung eingebetteterSysteme VII, Seiten 1 – 10, Munich, Germany, February 2011. fortiss GmbH.
[HW07] F. Heidenreich und C. Wende. Bridging the gap between features and models.Aspect- oriented Product Line Engineering, Seite 38, 2007.
[Me07] A. Metzger, P. Heymans, K. Pohl, P.-Y. Schobbens und G. Saval. Disambiguating the Documentation of Variability in Software Product Lines: A Separation of Concerns, Formalization and Automated Analysis. InRequirements Engineering Conference, 2007. RE ’07. 15th IEEE International, Seiten 243 –253, oct. 2007.
[NK08] N. Noda und T. Kishi. Aspect-Oriented Modeling for Variability Management. In Software Product Line Conference, 2008. SPLC ’08. 12th International, Seiten 213 –222, sept. 2008.
[PBL05] Klaus Pohl, Günter Böckle und Frank J. van der Linden. Software Product Line En- gineering: Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2005.
[Po12] Klaus Pohl, Harald Hönninger, Reinhold Achatz und Manfred Broy. Model-Based Engineering of Embedded Systems: The SPES 2020 Methodology. Springer, 2012.
[Sc10] I. Schaefer. Variability Modelling for Model-Driven Development of Software Pro- duct Lines. InIntl. Workshop on Variability Modelling of Software-intensive Systems (VaMoS 2010), 2010.
[TBD07] S. Trujillo, D. Batory und O. Diaz. Feature Oriented Model Driven Development: A Case Study for Portlets. InICSE 2007, Seiten 44 –53, may 2007.
[VG07] Markus Voelter und Iris Groher. Product Line Implementation using Aspect-Oriented and Model-Driven Software Development. InProceedings of the 11th Internatio- nal Software Product Line Conference, SPLC ’07, Seiten 233–242, Washington, DC, USA, 2007. IEEE Computer Society.
