Konzeption und Evaluation eines delta-orientierten modellbasierten Integrationstestverfahrens für Softwareproduktlinien

Transkript

1 TECHNISCHE UNIVERSITÄT CAROLO-WILHELMINA ZU BRAUNSCHWEIG Mastrarbit Konzption und Evaluation ins dlta-orintirtn modllbasirtn Intgrationststvrfahrns für Softwarproduktlinin Rmo Lachmann 3. April 2013 Institut für Softwartchnik und Fahrzuginformatik Prof. Dr.-Ing. Ina Schafr btrut durch: Dipl.-Inform. Malt Lochau (Institut für Programmirung und Raktiv Systm) Sascha Lity M.Sc. (Institut für Programmirung und Raktiv Systm) Prof. Dr.-Ing. Ina Schafr

2

3 Eidsstattlich Erklärung Hirmit rklär ich an Eids statt, dass ich di vorlignd Arbit slbstständig vrfasst und kin andrn als di anggbnn Hilfsmittl vrwndt hab. Braunschwig, 3. April 2013

4

5 Zusammnfassung Bim Tstn von variantnrichn Softwarsystmn, wi bispilswis Softwarproduktlinin, gilt s vil Hrausfordrungn zu bwältign. Dis bgründt sich zum inn aus inm hohn Grad an Variabilität, und zum andrn aus dr daraus ntsthndn großn Anzahl von möglichn Produktn. Ein Tstn jds inzlnn Produkts ähnlich zu Singl Softwarsystmn ist wdr ffizint noch praktikabl, da di Anzahl dr Produkt mist norm hoch ist und da s innrhalb dr Produkt zu Gminsamkitn kommn kann, di dann rdundant gtstt würdn. Stattdssn müssn Möglichkitn gfundn wrdn, Tstartfakt widrzuvrwndn, um so dn Tstaufwand zu vrringrn. Das in disr Arbit konzipirt dlta-orintirt modllbasirt Intgrationststvrfahrn stzt auf dm Modllbasirtn Tstn auf und vrbindt dis mit dm Ansatz ds Rgrssionststns. Dis soll zur Gnrirung und Widrvrwndung von variabln Tstmodlln zur Erstllung von Tstfälln und drn Widrvrwndbarkit rmöglichn. Witrhin soll di Zahl dr auszuführndn Tstfäll vrringrt wrdn. Di Tstmodll wrdn in Form von variabln Softwararchitkturn dfinirt, di durch in Anpassung ds dlta-orintirtn Modllirungsansatzs modllirt wrdn könnn. Das Zil ds inkrmntlln Tstvrfahrns soll s sin, dn Tstaufwand bi glichblibndr Tstabdckung zu vrringrn. Als Tstfäll kommn Mssag Squnc Charts zum Einsatz, di Kommunikationsausschnitt zwischn Komponntn rpräsntirn. Um di Architkturn zu modllirn wird di Architkturbschribungssprach Dltarx dfinirt, di in txtull Bschribung von variabln Softwararchitkturn rmöglicht. Es wird in Eclips-Plugin zur Modllirung und Gnrirung von Tstmodlln implmntirt. Abschlißnd wird das Tstvrfahrn mit Hilf inr Fallstudi aus dr Automobilbranch auf Anwndbarkit und Effizinz valuirt. In dism Zusammnhang rfolgt in Vrglich mit inm andrn Tstvrfahrn. Stichwörtr Softwarproduktlinin, Modllbasirts Tstn, Dlta-orintirt, Softwararchitkturn, Rgrssionststn

6

7 Abstract Tsting variation rich softwar lik softwar product lins is a domain with many challngs basd on th high dgr of variability lading to a high numbr of possibl products to b tstd. Tsting vry singl product lik in a singl softwar systm tst is infasibl, as th numbr of products ar vry larg and du to commonality among ths products rdundant tst cas applications aris. Thr is th nd to xploit th variability to minimiz th ffort of tsting such systms by rusing tst artfacts. Th contribution of this thsis is th concpt of a dlta-orintd modlbasd intgration tst approach for softwar product lins. Basd on th combination of modl-basd tsting and rgrssion tsting stratgis variabl softwar architcturs, i.., architcturs xtndd with th dlta-orintd modling approach ar usd as tst modls for th drivation of tst cass. Th incrmntal tsting approach aims for a rduction of th tsting ffort and guarnts th sam tst covrag for th tsting of SPLs. Th tst cass drivd from th tstmodls ar rprsntd as mssag squnc charts. To support th modling of such architcturs an architctur dfinition languag (ADL) is dfind. Basd on th ADL a tool is implmntd to hlp modling and gnrating architcturs with th hlp of dltas. For th purpos of valuating th tsting approach a cas study from th automobil industry is usd. Th rsults ar compard to anothr tsting approach. Kywords Softwar Product Lins, Modlbasd Tsting, Dlta-Orintd, Softwar Architcturs, Rgrssion Tsting

8

9 Inhaltsvrzichnis Vrzichnis dr Tablln Listings Vrzichnis dr Abbildungn Vrzichnis dr Abkürzungn xi xii xiv xvii 1 Einlitung Fallstudi Strukturirung dr Arbit Grundlagn Dlta-orintirt Softwarproduktlinin Softwarproduktlinin Faturs und Faturmodll Dlta-orintirt Softwarntwicklung Softwararchitkturn Tstn von Softwar Trminologi Intgrationstst innrhalb ds V-Modlls Tsttchnikn Rgrssionststn Modllbasirts Tstn Dlta-orintirt Modllirung von Softwararchitkturn Bschribungn von Softwararchitkturn Softwararchitkturbschribungssprachn Darwin Rapid Wright Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik Formal Dfinition inr Softwararchitktur Variabilität in Softwararchitkturn Grammatik dr Dlta-orintirtn Softwararchitkturbschribungssprach ix

10 Inhaltsvrzichnis 4 Dlta-orintirts Modllbasirts Intgrationststn Konzption ins Tstmodlls Dfinition dr Tstkritrin Äquivalnz von Tstmodlln Einfluss von Fatur-Intraktionn Dfinition ds Tstvrfahrns Auswahl dr Produkt Tstfallrstllung und Widrvrwndung Tstfallkatgorisirung und Entwicklung inr Produkttstsuit Tstfallslktion und Tstplanrstllung Wrkzugimplmntirung Anfordrungn Ralisirung und Implmntirung Dfinition dr Grammatik in XTxt Implmntirung ds Wizards Vrwndungswis Fallstudi Body Comfort Systm Krnarchitktur für das BCS Produktgnrirung für BCS Anwndung ds Intgrationststvrfahrns Tstfallntwicklung Auswrtung dr Tstfallwidrvrwndbarkit Fazit und Ausblick Ergbniss Ausblick Litratur 111 A Anhang 116 A.1 Klassndiagramm ds Plugins A.2 Fallstudinralisirung in Dltarx A.3 Architkturgrafikn A.4 MSCs dr Fallstudi A.5 Übrsicht dr Tstfäll B Inhalt ds Datnträgrs 227 x

11 Vrzichnis dr Tablln 2.1 Klassifikation von Fatur-Intraktionn Übrsicht dr Faturkonfigurationn für di Produkt P0 bis P Übrsicht übr di Tstfäll für di Produkt P0 bis P A.1 Tstfäll für Produkt P A.2 Tstfäll für Produkt P A.3 Tstfäll für Produkt P A.4 Tstfäll für Produkt P A.5 Tstfäll für Produkt P A.6 Tstfäll für Produkt P A.7 Tstfäll für Produkt P A.8 Tstfäll für Produkt P A.9 Tstfäll für Produkt P A.10 Tstfäll für Produkt P A.11 Tstfäll für Produkt P A.12 Tstfäll für Produkt P A.13 Tstfäll für Produkt P A.14 Tstfäll für Produkt P A.15 Tstfäll für Produkt P A.16 Tstfäll für Produkt P A.17 Tstfäll für Produkt P A.18 Tstfäll für Produkt P xi

12 Listings 3.1 Bispil inr Komponntndfinition in Darwin Zusammngstzt Komponntn in Darwin Bispil inr Komponnt in Rapid Bispil ins Constraints in Rapid Bispilsystm in Wright Valid Application Condition Invalid Application Condition Kontxtfri Grammatik dr Sprach Dltarx Sprachdfinition in XTxt Gnrirung ds Ecor-Modlls Bispilrgl für IDs Bispilrgl für Txtingabn Bispilrgl für Odr Linksrkursiv Rgl Rkursiv Rgln Bispilrgl für Optional Angabn Bispilrgl für Aufzählungn Bispilrgl für Rfrnzirungn Einstigsrgl dr Dltarx-Grammatik Rgl zur Signaldfinition Rgl dr Signaltypn Rgl zur Komponntndfinition Rgl zur Portdfinition Rgl dr Portrichtung Rgl dr Konnktordfinition Erst Konnktorrgl Zwit Konnktorrgl Rgl zur Bschribung ins Dltas Transformationsrgln Mthod chckfmconsistncy Bispil inr Architkturdfinition in Dltarx Bispil inr Architkturdfinition in Dltarx (Altrnativ) Bispil inr Dltadfinition in Dltarx Architkturdfinition ds Krnprodukts p Portgnrirung xii

13 Listings 6.3 Dlta DCLS für das Fatur CLS Dlta DLEDCLSA für das Fatur LED CLS A.1 Krnarchitktur und Dltas für BCS xiii

14 Vrzichnis dr Abbildungn 2.1 Produktkonfigurator von Volkswagn Entwicklungsprozss für Softwarproduktlinin [46] Faturmodll ds Body Comfort Systms Dlta-Konzpt am Bispil inr Softwararchitktur Bispil für in Softwararchitktur Bispil für in Squnzdiagramm mit zwi Komponntn V-Modll Prinzip ds Rgrssionststs Ablauf ds modllbasirtn Tstns Hirarchi in Softwararchitkturn Komponnt filtr in Darwin Zusammngstzt Komponnt piplin in Darwin Bispil inr Dlta-Anwndung auf Softwararchitkturn - Architkturbn Bschribung von Dlta LFP Übrsicht übr di Transformationsoprationn Ungültig Rmov-Transformationn von Komponntn Bzihung zwischn Tstfall und Tstmodll Bispil für Konnktorabdckung Schmatisch Darstllung dr Tststratgi Us Cas ds Domain Enginrings Us Cas ds Application Enginrings Arbitsablauf im Wrkzug Dltarx Aufbau ds Plugins Scrnshot ds Dltarx-Editors Scrnshot ds Dltarx Wizards für Eclips Grafisch Architkturrpräsntation für Produkt P Produktgnrirung im BCS für Produkt P MSC 1 für Produkt P Übrsicht übr di Tstfallwidrvrwndung Intrfacwchsl dr Komponnt C Vrtilung rnut zu tstndr Tstfäll Vrglich tatsächlich ausgführtr Tstfäll xiv

15 Vrzichnis dr Abbildungn A.1 Klassndiagramm ds Dltarx-Plugins A.2 Architktur von Produkt P A.3 Architktur von Produkt P A.4 Architktur von Produkt P A.5 Architktur von Produkt P A.6 Architktur von Produkt P A.7 Architktur von Produkt P A.8 Architktur von Produkt P A.9 Architktur von Produkt P A.10 Architktur von Produkt P A.11 Architktur von Produkt P A.12 Architktur von Produkt P A.13 Architktur von Produkt P A.14 Architktur von Produkt P A.15 Architktur von Produkt P A.16 Architktur von Produkt P A.17 Architktur von Produkt P A.18 Architktur von Produkt P A.19 Architktur von Produkt P A.20 p0_msc A.21 p0_msc A.22 p0_msc A.23 p0_msc A.24 p0_msc A.25 p0_msc A.26 p1_msc A.27 p1_msc A.28 p1_msc A.29 p1_msc A.30 p1_msc A.31 p1_msc A.32 p1_msc A.33 p1_msc A.34 p1_msc A.35 p1_msc A.36 p1_msc A.37 p1_msc A.38 p1_msc A.39 p1_msc A.40 p1_msc A.41 p1_msc A.42 p1_msc A.43 p1_msc A.44 p1_msc xv

16 Vrzichnis dr Abbildungn A.45 p1_msc A.46 p1_msc A.47 p2_msc A.48 p2_msc A.49 p2_msc A.50 p2_msc A.51 p2_msc A.52 p2_msc A.53 p2_msc A.54 p2_msc A.55 p3_msc A.56 p3_msc A.57 p3_msc A.58 p3_msc A.59 p3_msc A.60 p3_msc A.61 p3_msc A.62 p3_msc A.63 p3_msc A.64 p3_msc A.65 p3_msc A.66 p3_msc A.67 p5_msc A.68 p5_msc A.69 p5_msc A.70 p5_msc A.71 p5_msc A.72 p8_msc A.73 p8_msc A.74 p8_msc A.75 p8_msc A.76 p9_msc A.77 p9_msc A.78 p13_msc xvi

17 Vrzichnis dr Abkürzungn ADL BCS MSC SPL UML AS CLS EM EMH FP HMI LED RCK Ctrl Architkturbschribungssprach Body Comfort Systm Mssag Squnc Chart Softwarproduktlini Unifid Modling Languag Alarm Systm Control Locking Systm Extrior Mirror Extrior Mirror with Hating Fingr Protction Human Machin Intrfac Luchtdiod Rmot Control Ky Controllr xvii

18

19 1 Einlitung In dr Softwarntwicklung spilt das Tstn ds zu ralisirndn Produkts in wichtig Roll. Bim Softwartstn wird das zu ntwicklnd Softwar-Systm anhand sinr Spzifikationn auf Fhlvrhaltn gprüft. Frühzitigs, mit dr Entwicklung vrknüpfts Tstn, kann di Kostn für spätr Wartungsarbitn, di nach dr Produktvröffntlichung anfalln, snkn [29]. Bi dr Softwarntwicklung wrdn nbn klassischn Singl Softwarsystmn auch Softwarproduktlinin (SPL) ntwicklt. SPLs kommn mist im Rahmn dr mass customisation, also dm gziltn Anpassn inr großn Anzahl von Produktn an dn Kundn, zum Einsatz [46]. Bi SPLs wird in gminsam Plattform vrwndt, auf dnn Variationn angwndt wrdn. Si stzn sich dmnach aus viln Softwar-Systmn inr Domän zusammn und sind durch in Mng von Gminsamkitn und inn hohn Grad an Variabilität gknnzichnt [46]. In dr Praxis wrdn Softwarproduktlinin immr häufigr ingstzt, wshalb gignt Tstvrfahrn bnötigt wrdn, um dn Tstaufwand inzuschränkn bzw. zu minimirn [15]. Im Brich sichrhitskritischr Softwar-Systm, wi si bispilswis im Automobilbrich zu findn sind, kommt dm Tstn in ssntill Bdutung zu. Für dis Brich xistirn ign Normn wi bispilswis di ISO für Kraftfahrzug. Dis fordrn u.a. in vollständig Tstabdckung für jds Produkt dr Produktlini. Dis Fordrung stht im Konflikt mit dm klassischn Singl Softwar Tst, da SPLs oftmals in norm hoh Zahl potntillr Produkt rmöglichn, für di in Tst ohn di Widrvrwndung von Tstartfaktn wirtschaftlich nicht praktikabl ist [33]. Hirfür kann das von SPLs glifrt Wissn übr di gminsamn und variabln Eignschaftn dr vrschidnn Produkt vrwndt wrdn. Darauf aufbaund könnn ffizintr Tstvrfahrn für SPLs ntwicklt wrdn, di widrvrwndbar Tstartfakt wi z.b. Tstfäll nutzn. Das Zil drartigr Vrfahrn ist di Rduzirung ds Tstaufwands, was langfristig auch zur Kostninsparung führt. Um in Widrvrwndbarkit von Tstartfaktn auszunutzn, könnn modllbasirt Tsttchnikn ingstzt wrdn [29, 55]. Bi disn Tchnikn wird in abstrakts Tstmodll ds zu tstndn Systms rstllt. Daraus lässt sich in Mng von Tstfälln ntwickln. Im Rahmn von SPLs könnn di Tstmodll [33] dr inzlnn Produkt auf Grund inr gminsamn Plattform tilwis widrvrwndt wrdn. Bim Tstn wird in dr Rgl zunächst in Komponntntst für di inzlnn Komponntn durchgführt. Disr tstt di voninandr isolirtn Komponntn anhand ihrr Spzifikation. Dis gschiht oftmals in Form von Stat Machins [30], di ndlich Zustandsautomatn mit Zuständn und Transitionn rpräsntirn. Ein Komponntntstvrfahrn für SPLs wurd von Lity [30] brits konzipirt. 1 Stand:

20 1 Einlitung Das Zil dr Arbit ist di Konzption und Evaluirung ins dlta-orintirtn Intgrationststvrfahrns für SPLs. Intgrationststvrfahrn prüfn di komponntnübrgrifnd Kommunikation innrhalb inr Softwararchitktur. Dis wird als Tstmodll für das Tstvrfahrn vrwndt. Ein Softwararchitktur stzt sich dabi aus inr Mng von Komponntn, Signaln und Konnktorn zusammn. Di Evaluation soll zign, ob das Vrfahrn auf SPLs angwandt wrdn kann und ob in Effizinzstigrung ggnübr Singl Softwar Tstvrfahrn rzilt wrdn kann. Das zu ntwicklnd Intgrationststvrfahrn soll auf dm dlta-orintirtn Komponntntstvrfahrn von Lity [30] und dn Arbitn von Schafr t al. [48, 50] aufbaun. Hirfür soll zunächst dr Ansatz dr Dlta-Modllirung von Schafr auf Softwararchitkturn angwandt wrdn. Di Dlta-Modllirung bschribt inn sprachnunabhängign Ansatz zur Modllirung von Variabilität innrhalb von Softwarsystmn durch di Dfinition von Dltas. Dltas umfassn in Mng von Transformationn, di variabl Funktionalitätn ralisirn könnn. Im Rahmn disr Arbit wrdn Dltas auf Softwararchitkturn bschribn. Dis rsultirndn Architkturn solln als Tstmodll zur Entwicklung von Tstfälln gnutzt wrdn. Darauf aufbaund soll in Tststratgi für inn dlta-orintirtn Intgrationstst auf Softwararchitkturn ntwicklt wrdn. Di zu prüfndn Tstfäll wrdn in Form von Mssag Squnc Charts für di inzlnn Tstmodll ntwicklt. Si bschribn inn Kommunikationsausschnitt zwischn Komponntn. Das Tstvrfahrn soll di bidn SPL-Tstphilosophin Subst-Huristics [44], wlch dn Tst inr rpräsntativn Untrmng von Produktn vrwndt, und Rus- Tchniqus [44], in dnn di Widrvrwndbarkit von Tstartfaktn gnutzt wird, vrwndn. Zusätzlich wird di Rgrssiontsttchnik [15, 29] ingstzt, bi dr Tstfäll und Tstrgbniss widrvrwndt wrdn. Das Modllbasirt Tstn [55] wird zur Entwicklung und Widrvrwndung von Tstmodlln und Tstfälln gnutzt. Für di Tstmodllgnrirung soll auf Basis dr Dltamodllirung in prototypischs Wrkzug implmntirt wrdn, das di Dfinition inr Krntstmodlls sowi von Dltas rmöglicht. Anhand inr Produktkonfiguration soll s dm Anwndr möglich sin, in witrs Tstmodll durch di Anwndung ntsprchndr Dltas zu gnrirn. Di Evaluation ds Intgrationststvrfahrns rfolgt anhand dr Fallstudi Body Comfort Systm (BCS), di in SPL aus dm Brich dr Automobilntwicklung umfasst (sih Kapitl 1.1). Di Evaluirung soll zign, inwifrn das Tstvrfahrn auf SPLs anwndbar ist. Zusätzlich soll gprüft wrdn, ob di Effizinz ds Vrfahrns im Vrglich zu klassischn Singl Softwar Tsts dr inzlnn Produkt gstigrt wrdn konnt. Das Wrkzug wird bi dr Evaluirung zur Tstmodllgnrirung vrwndt. Di Aufgabnstllung dr Arbit lautt zusammnfassnd wi folgt: Adaption dr Dlta-Modllirung für Softwararchitkturn zur Gnrirung widrvrwndbarr Tstmodll 2

21 1.1 Fallstudi Konzption ins dlta-orintirtn Intgrationststvrfahrn für Softwarproduktlinin Implmntirung ins prototypischn Wrkzugs zur Tstmodllmodllirung und Gnrirung für in Mng von Softwarproduktn inr SPL Anwndung ds Tstvrfahrns auf di Fallstudi Body Comfort Systm Evaluation ds Tstvrfahrns in Bzug auf di Anwndbarkit auf SPLs und rzilt Effizinz Im Folgndn wird di Fallstudi Body Comfort Systm, di zur Evaluation ds Tstvrfahrns vrwndt wird, bschribn. 1.1 Fallstudi Das Tstvrfahrn, das in disr Arbit ntwicklt wird, soll anhand inr Fallstudi aus dm Automobilbrich valuirt wrdn. Dabi handlt s sich um in Komfortsystm für PKW und s wird als Body Comfort Systm (BCS) bzichnt. Das BCS wurd von Müllr t al. [32, 41] gminsam mit inm Industripartnr an dr Tchnischn Univrsität Braunschwig ntwicklt. Di Ralisirung rfolgt übr vir übr CAN-Buss mitinandr vrbundn Sturgrät, auf dnn di ntsprchndn Funktionn implmntirt sind. Das BCS bstht aus dn folgndn Elmntn: dm Human Machin Intrfac, das in zntral Sturinhit und Informationn britstllt, inm lktrischn Außnspigl (Extrior Mirror) dr bhizbar (hatabl) ist, inm lktrischn Fnstrhbr (Powr Window) dr inn Einklmmschutz (Fingr Protction) bsitzt, inr Zntralvrriglung (Cntral Locking Systm) für di Türn und di Hckklapp, inr Alarmanlag (Alarm Systm), di in Innnraumübrwachung bsitzt (Intrior Monitoring) sowi inr Funkfrnbdinung (Rmot Control Ky). Marius Zink hat das BCS in sinr Mastrarbit [56] modifizirt und in in Softwarproduktlini transformirt, um Variabilität hinzuzufügn. Dadurch wurdn inig dr Funktionalitätn optional und andr schlißn sich aus. Dis führt zu inr großn Anzahl möglichr Konfigurationn. Di SPL nthält insgsamt potntill Produktkonfigurationn. Das Fatur-Modll dr Fallstudi ist in Kapitl 2 in Abbildung 2.3 aufgführt. Im folgndn Abschnitt wird dr Aufbau dr witrn Kapitl bschribn. 3

22 1 Einlitung 1.2 Strukturirung dr Arbit Di Grundlagn für das dlta-orintirt Intgrationststvrfahrn für SPLs wrdn in Kapitl 2 bschribn. Es wird auf di dlta-orintirt Softwarntwicklung, SPLs, Softwararchitkturn und di vrschidnn Aspkt ds Softwartstns inggangn. In Kapitl 3 wird di dlta-orintirt Modllirung von Softwararchitkturn dfinirt. Hirfür wrdn zunächst Softwararchitkturn bschribn. Im Anschluss wrdn als Modllirungsmöglichkitn für Softwararchitkturn brits gnutzt Softwararchitkturbschribungssprachn (ADLs) rläutrt. Im nächstn Abschnitt wrdn di Elmnt inr Softwararchitktur und drn Variabilität formal dfinirt. Abschlißnd wird in dlta-orintirt Softwararchitkturbschribungssprach dfinirt. Das dlta-orintirt Intgrationststvrfahrn wird in Kapitl 4 ntwicklt. Es wird zunächst das Konzpt ins Tstmodlls bschribn, um im Anschluss in Tstvrfahrn durch in gignt Tststratgi zu dfinirn. In Kapitl 5 wird di Implmntirung ds prototypischn Wrkzugs rläutrt, wobi zunächst di Anfordrungn an das Wrkzug rmittlt wrdn, um im Anschluss auf di zur Ralisirung gwähltn Framworks und Tools sowi di konkrt Implmntirung inzughn. Witrhin wird di Vrwndungswis ds Wrkzugs bschribn. Kapitl 6 dint dr Evaluirung ds Tstvrfahrns aus Kapitl 4 durch di Anwndung auf di Fallstudi ds Body Comfort Systms. Dazu wird di Krnarchitktur und in Mng von Dltas mit Hilf dr in Kapitl 3 dfinirtn Softwararchitkturbschribungssprach dfinirt. Anschlißnd wird di Tstmodllgnrirung für di Produkt dr Fallstudi mit Hilf ds ntwickltn Wrkzugs durchgführt. Zultzt wird das Tstvrfahrn valuirt. In Kapitl 7 rfolgt in abschlißnds Fazit übr das ntwicklt Tstvrfahrn. Es wrdn di Ergbniss, di währnd dr Konzption und Evaluation aufgfalln sind vorgstllt und s wird in Ausblick für zukünftig Arbitn ggbn. 4

23 2 Grundlagn In dism zwitn Kapitl wrdn di Grundlagn für di vorlignd Mastrarbit vorgstllt. Si dinn als thortischs Fundamnt für di witrn Kapitl. Zunächst wrdn dlta-orintirt Softwarproduktlinin bschribn. Es wird in Vrglich zu Singl Softwarsystmn aufgstllt. Witrhin wrdn Faturmodll und di dltaorintirt Softwarntwicklung rläutrt, di in disr Arbit zur Ralisirung inr Softwarproduktlini vrwndt wrdn soll. Anschlißnd wrdn Softwararchitkturn und möglich Rpräsntationn in grafischr und txtullr Form vorgstllt. In dism Zusammnhang wird auf di Notation von Squnzdiagrammn inggangn, di zur Vrhaltnsmodllirung ins Softwarsystms dinn. Im ltztn Abschnitt wird dr Prozss ds Tstns von Softwar vorgstllt. Dis binhaltt di Trminologi, di inzlnn Tstschritt ds V-Modlls, Tsttchnikn und dn Prozss ds modllbasirtn Tstns. 2.1 Dlta-orintirt Softwarproduktlinin In dism Abschnitt wrdn zunächst Softwarproduktlinin dfinirt und in möglichr Entwicklungsprozss dafür vorgstllt. Zu dism Zwck wrdn Faturmodll rläutrt. Danach wird di dlta-orintirt Softwarntwicklung bschribn. Es wird auf di Dlta-Modllirung im Zusammnhang mit Softwarproduktlinin inggangn Softwarproduktlinin In Hrstllungsprozssn, bi dnn mass customization, also di Anpassung individull gwünschtr Produkt an in groß Zahl von Kundn [46], notwndig ist, wrdn mist Softwarproduktlinin bzw. Softwar Product Lins (SPL) ingstzt. Mass customization bschribt di Anpassung von individull gwünschtn Produktn an in groß Zahl von Kundn [46]. Softwarproduktlinin untrschidn sich von klassischn Singl Softwarsystmn durch Variabilität von Produktartfaktn auf Basis inr gminsamn Produktplattform, di alln Produktn zu Grund ligt [46]. Dis Variabilität rlaubt dn Hrstllrn in Form dr Flxibilität bi dr Frtigung individualisirtr Produkt durch das Variirn von Eignschaftn und Artfaktn. Glichzitig gibt s inn hohn Grad dr Widrvrwndbarkit, da di Plattform bi alln Produktn idntisch ist und auch zusätzlich Faturs widrvrwndt wrdn könnn (Sih Kapitl 2.1.2). Softwarproduktlinin findn Vrwndung in vrschidnn Industrizwign. In disr Arbit wird in bispilhaft Softwarproduktlini dr Automobilindustri 5

24 2 Grundlagn Abbildung 2.1: Produktkonfigurator von Volkswagn 1 ntwicklt. Vil Automobilhrstllr rlaubn s potntilln Kundn ihr gwünschts Fahrzug in vrschidnn Brichn slbst zu gstaltn. Dis wird durch Produktkonfiguratorn rmöglicht, di von dn Hrstllrn mist onlin angbotn wrdn. Dabi lassn sich di gwünschtn Produktignschaftn und Komponntn anund abwähln, um das gwünscht Produkt mit dr ntsprchndn Produktkonfiguration zu gnrirn. Di Produktfamili blibt jdoch durchghnd glich, man spricht also bispilswis witrhin von inm VW Golf, auch wnn sich zwi Modll in dn gwähltn Produktartfaktn untrschidn. Ein Bispil für inn Produktkonfigurator aus dr Automobilbranch ist in Abbildung 2.1 zu shn. Dabi handlt s sich um di angbotn Variant zur individulln Gstaltung ins Automobils von Volkswagn. Pohl t al. [46] untrschidn bi dm Entwicklungsprozss inr Softwarproduktlini zwi Prozss, das Domain Enginring und das Application Enginring. Si sind in Abbildung 2.2 dargstllt. Das Domain Enginring wird wi folgt von Pohl t al. [46] dfinirt: Domain nginring is th procss of th softwar product lin nginring in which th commonality and th variability of th product lin ar dfind and ralisd. Das Domain Enginring bschribt dmnach dn Prozss, dr di Grundlag für di Softwarproduktlini lgt. Es wrdn di Gminsamkitn und Untrschid dr Produktvariant rmittlt. Disr Aspkt führt zur Dfinition dr gminsam gnutztn 1 Scrnshot von [4] (Stand: ) 6

25 2.1 Dlta-orintirt Softwarproduktlinin Abbildung 2.2: Entwicklungsprozss für Softwarproduktlinin [46] Plattform. Dis stzt sich aus alln gminsam vrwndtn Softwarartfaktn zusammn. Softwarartfakt könnn Bdingungn, Tstfäll, Implmntirungn tc. sin. Dis wrdn durch di in Abbildung 2.2 dargstlltn fünf Subprozss rzugt, di wi folgt bschribn wrdn könnn (vgl.[46]): Product Managmnt: Das Product Managmnt bschäftigt sich mit ökonomischn Aspktn bim SPL-Enginring. Dr Fokus ligt dabi auf Marktstratgin. Es rfüllt grundsätzlich Managmntaufgabn zur Erstllung ds Produktportfolios. Di Eingab sind Untrnhmnszil, das Ergbnis ist in Produkt-Roadmap. Dis umfasst gminsam und untrschidlich Faturs von zukünftign Produktn und gibt inn Entwicklungszitplan vor. Domain Rquirmnts Enginring: Disr Subprozss bschäftigt sich mit dr Erhbung und Dokumntation dr gminsamn und variabln Anfordrungn an di SPL. Di Eingab ist di in dm Product Managmnt gnrirt Roadmap. Das Ergbnis sind di vrschidnn Anfordrungn und das Variabilitätsmodll dr Produktlini. Di rmittltn Anfordrungn bzihn sich nicht auf in spzills Produkt, sondrn auf all dnkbarn Produktvariantn. 7

26 2 Grundlagn Domain Dsign: Untr dism Bgriff fasst man all Aktivitätn zusammn, di zur Dfinition dr Rfrnzarchitktur dr Produktlini ghörn. Dabi handlt s sich um in gminsam high-lvl Struktur, di für all Produkt dr SPL vrfügbar ist. Di Eingab sind di Vorausstzungn und das Variabilitätsmodll aus dm Domain Rquirmnts Enginring. Das Rsultat diss Prozsss ist di Rfrnzarchitktur und in angpassts Variabilitätsmodll, in dm intrn Variabilität bschribn wird, di aus tchnischn Gründn bnötigt wird. Domain Ralisation: In dism Abschnitt findn Dsignprozss statt, in dnn widrvrwndbar Softwarkomponntn implmntirt wrdn. Di Eingab ist in Rfrnzarchitktur, di Ausgab sind in dtaillirts Dsign und di Implmntirung von Softwarkomponntn für di Softwarproduktlini. Domain Tsting: Disr Subprozss hat di Aufgab di zuvor bschribnn, widrvrwndbarn Komponntn zu validirn und zu vrifizirn. Di Komponntn wrdn ggn ihr Spzifikation gtstt. Zudm wrdn widrvrwndbar Tstartfakt dfinirt, um dn Tstprozss zu optimirn. Als Eingab dinn di Anfordrungn, di Rfrnzarchitktur, Dsigns und Implmntirungn von widrvrwndbarn Softwarkomponntn. Das Ergbnis sind di Rsultat dr angwndtn Tsts sowi di widrvrwndbarn Tstartfakt. Durch di Subprozss ds Domain Enginrings wrdn Domain Artfacts rzugt. Dabi handlt s sich um widrvrwndbar Entwicklungsartfakt [46]. Si wrdn in inm gminsamn Rpository gspichrt und rgbn di Plattform dr SPL. Dm Domain Enginring schlißt sich dr Prozss ds Application Enginrings an (Sih Abbildung 2.2). Pohl t al. [46] dfinirn dis wi folgt: Application Enginring is th procss of softwar product lin nginring in which th applications of th product lin ar built by rusing domain artifacts and xploiting th product lin variability. Das Application Enginring baut auf dr zuvor ntwickltn Plattform auf und bschribt di Gnrirung von Produktvariantn inr SPL. Dabi wrdn Produktartfakt und drn Variabilität vrwndt, um di vrschidnn Produkt zu rstlln. Eins dr Hauptzil ist in hohr Grad an Widrvrwndung von Domännartfaktn. Analog zum Domain Enginring wird das Application Enginring in vir Subprozss gglidrt: Application Rquirmnts Enginring: Disr Prozss umfasst all Aktivitätn, di für di Entwicklung dr Application Rquirmnts Spcification bnötigt wrdn. Di Anzahl dr widrvrwndtn Domain Artfacts hängt stark von dn Application Rquirmnts ab. Di Eingab sind di Domain Rquirmnts und di Produkt-Roadmap. Das Ergbnis sind Vorausstzungn für in bstimmt Produktvariant. 8

27 2.1 Dlta-orintirt Softwarproduktlinin Application Dsign: In dism Subprozss wrdn all Aktivitätn zusammngfasst, di zur Erstllung dr Produktarchitktur notwndig sind. Dazu wird als Input di Rfrnzarchitktur vrwndt, aus dr di für di Produktvariant bnötigtn Til ausgwählt und konfigurirt wrdn. Dis spzill Architktur stllt das Ergbnis ds Application Dsigns dar. Application Ralisation: Währnd diss Subprozsss wird das Produkt rstllt. Es wrdn widrvrwndbar Softwarbaustin ausgwählt. Di Softwar wird aus dr Produktarchitktur und di widrvrwndbarn Artfakt gnrirt. Si nthält dtaillirt Dsignartfakt. Application Tsting: Dr ltzt Subprozss dint dm Validirn und Vrifizirn ds Produkts ggn sin Spzifikation. Es wrdn di widrvrwndbarn Domain Tstartfakt aus dm Domain Tsting vrwndt. Das Ergbnis wird in Form ins Tstrports rstllt. Disr binhaltt di Ergbniss allr durchgführtn Tsts. Ähnlich zu dn Domain Artfacts ntsthn bim Application Enginring Application Artfacts. Dis umfassn all ntstandnn Entwicklungsartfakt ds Application Enginrings sowi das konfigurirt und gtstt Produkt pr s. Si ntsthn durch di brits bschribnn Subprozss. Zwischn dn Artfaktn sind Links notwndig, um u.a. di korrkt Vrwndung dr Variabilität sichrzustlln. Di ntstandnn Artfakt umfassn das Application Variability Modl, di Application Rquirmnts, di Application Architctur, Application Ralisation Artfacts und Application Tst Artfacts. Um Variabilität von SPLs zu bschribn, wurd dr Formalismus dr Faturmodll ntwicklt. Dis rlaubn s durch in Diagrammdarstllung all gültign Produktvariantn inr SPL darzustlln. Si wrdn im folgndn Untrkapitl rläutrt Faturs und Faturmodll Durch dn Einsatz von Softwarproduktlinin in dr mass customization und dr daraus ntsthndn Variabilität von Produktartfaktn sind Hilfsmittl notwndig, um dis formal zu bschribn. Dazu wurdn von Kang t al. [27] Faturmodll vorgstllt. Dis dinn als übrsichtlichs Darstllungsmittl von Variabilität und Gminsamkitn innrhalb inr SPL. Aus disr Darstllung lassn sich di darin nthaltndn, konfigurirbarn Produkt rmittln. Di Grundstruktur ist di ins hirarchisch aufgbautn Baums. Das Faturmodll für di Fallstudi ds Body Comfort Systms (vgl. Kapitl 1) ist in Abbildung 2.3 dargstllt (Grafik ntnommn aus [56]). Das grundlgnd Elmnt diss Diagrammtyps sind Faturs. Daruntr vrstht man Eignschaftn, di dn Produktn dr SPL zugwisn wrdn. Faturs sind für dn Nutzr sichtbar Aspkt odr Charaktristikn dr Domän. Durch di Faturs lassn sich di vrschidnn Produktvariantn inr SPL aufbaun. Si könnn Gminsamkitn abr auch Untrschid dr vrschidnn Produkvariantn 9

28 2 Grundlagn bschribn. Di Gnrirung dr Produkt inr Domän anhand von Faturs wird von Kang t al. [27] als Fatur-Orintd Domain Analysis (FODA) bzichnt. Dr Lsr si für witr Bschribungn auf di witrführnd Litratur vrwisn [8]. Im Zusammnhang mit dr ggbnn Variabilität innrhalb von Softwarproduktlinin wrdn Variantn dfinirt. Dis stlln variabl Objkt dar. Als Bispil sin di Variantn Rots Auto und Glbs Auto gnannt. In inr SPL nthaltnd Variantn könnn durch Faturs und Faturmodll dfinirt wrdn. Produktvariantn inr Softwarproduktlini lassn sich durch Faturkonfigurationn untr Brücksichtigung dr ggbnn Rstriktionn, wi z.b. rquir bschribn, d.h. di Komposition dr vorhandnn Faturs. Faturs könnn kausal mitinandr vrbundn wrdn, d.h. Faturs könnn sich ggnsitig bdingn, si könnn sich bnfalls ggnsitig ausschlißn. Man bzichnt dis als Constraints. Dis wrdn im Diagramm durch gstrichlt Kantn mit dr Bschriftung rquir bzw. xclud zwischn dn btroffnn Faturs dargstllt. Di rquir-kantn führn von dm abhängign Fatur zu dm bnötigtn Fatur. Ein Bispil aus Abbildung 2.3 für in Bdingung bzw. rquir-kant wär das Fatur LED Hatabl, wlchs das Fatur Hatabl ds Extrior Mirrors vorausstzt. Ein Ausschluss xistirt zwischn dm Fatur Manual Powr Window und Control Automatic Powr Window. Zusätzlich wurdn witr Notationn ingführt, um das Faturmodll zu dfinirn. Dis wrdn im Folgndn bschribn (vgl. [27]): Mandatory: Ein Fatur, das mit Mandatory gknnzichnt ist, ist in jdm Produkt bzw. jdr Produktvariant dr Produktlini nthaltn und darf nicht ntfrnt wrdn. Si rpräsntirn di gminsam Plattform auf dr all Produktvariantn aufbaun. Im Faturmodll wrdn dis mit inm ausgfülltn schwarzn Kris gknnzichnt. Ein Bispil für in solchs Fatur wär in Abbildung 2.3 das Human Machin Intrfac. Optional: Optional Faturs könnn in Produktn nthaltn sin, müssn dis abr nicht zwingnd. In dr Automobilindustri lassn sich so bispilswis optional Komfortfunktionn modllirn, di nicht im ursprünglichn Krnprodukt nthaltn sind. Als Darstllungsform dint in nicht ausgfülltr Kris. Als Bispil kann hir das Fatur Alarm Systm dr Fallstudi gnannt wrdn. Altrnativ: Di Altrnativ Faturs sind Spzialisirungn von übrgordntn Faturs. Wi dr Nam suggrirt, gibt s mhrr Altrnativn. Es kann jdoch immr nur in Altrnativ pro Produktvariant gwählt wrdn. Im Diagramm wrdn dis durch inn nicht ausgfülltn Bogn in dr Hirarchibzihung dargstllt. So kann in Kund ntwdr das Automatic Powr Window odr das Manual Powr Window wähln, jdoch nimals bids. Es gilt zu bachtn, dass das Eltrnfatur ausgwählt sin muss. Odr: Odr bzw. Or-Faturs bschribn in odr mhrr Auswahlmöglichkitn von Untrfaturs. Si wrdn durch inn schwarz ausgfülltn Halbkris 10

29 2.1 Dlta-orintirt Softwarproduktlinin LED Alarm Systm Human Machin Intrfac Status LED LED Fingr Protction Manual Powr Window LED Cntral Locking Systm Powr Window Automatic Powr Window LED Powr Window rquir Door Systm Fingr Protction LED Extrior Mirror Body Comfort Systm Extrior Mirror Elctric Hatabl rquir LED Hatabl rquir Alarm Systm Intrior Monitoring Scurity Cntral Locking Systm Automatic Locking rquir Mandatory Optional rquir Control Alarm Systm Lgnd Altrnativ Rmot Control Ky Safty Function xclud Or Control Automatic Powr Window rquir xclud Abbildung 2.3: Faturmodll ds Body Comfort Systms 11

30 2 Grundlagn zwischn dn vrschidnn Faturs dargstllt. Im Ggnsatz zu dn Altrnativn könnn mhrr Odr-Faturs glichzitig ausgwählt wrdn. Es muss trotzdm mindstns ins dr möglichn Faturs gwählt wrdn. Äquivalnt zu dn Altrnativn muss auch bi Odr-Faturs das ntsprchnd Eltrnfatur gwählt wrdn. Ein möglich Produktkonfiguration für das Faturmodll aus Abbildung 2.3 könnt aus dn folgndn Faturs bsthn: Human Machin Intrfac mit LED Alarm Systm, Automatic Powr Window, Fingr Protction, Extrior Mirror mit dr Eignschaft Hatabl sowi inm Cntral Locking Systm. Ein Bispil für in nicht lgitim Konfiguration wär: Automatic Powr Window, Human Machin Intrfac mit LED Hatabl, Extrior Mirror, Rmot Control Ky und Control Alarm Systm. Dis Konfiguration wär nicht gstattt, da di LED das Vorhandnsin inr Spiglhizung vorausstzt, dis jdoch nicht vorhandn ist. Ähnlich vrhält s sich mit dn Faturs Rmot Control Ky und Control Alarm Systm, di bid Abhängigkitn aufwisn, di nicht rfüllt wrdn. Fatur-Intraktion Wnn bstimmt Faturs mitinandr kombinirt wrdn, könnn di Abhängigkitn ihrr Implmntirungn zu unvorhrgshnm Vrhaltn führn. Das Vrhaltn bsitzt di Eignschaft, nur dann aufzutrtn, wnn gnau dis Kombination von Faturs gwählt wurd, s tritt also nicht andrwitig in Erschinung. Man bzichnt dis Bzihung von Faturkombination zu bsondrm Vrhaltn als Fatur- Intraktion. Caldr t al. [10] bschribn das Phänomn dr Fatur-Intraktion wi folgt: (...) whn svral faturs ar addd to a srvic, thr may b intractions (i.. bhavioural modifications) btwn both th faturs offrd within that srvic, as wll as with faturs offrd in anothr srvic. Whil particular intractions may b bnign, in gnral, intractions can b svrly damaging to systm dvlopmnt and to usr xpctations Fatur-Intraktionn könnn dmnach zu positivn odr harmlosn Effktn, abr auch zu ngativn bzw. schädigndn Effktn führn. Dis bzihn sich auf das gnrirt Produkt, abr auch auf das in disr Arbit ntwicklt Tstmodll. In Tabll 2.1 wird in Klassifikation von Fatur-Intraktionn vorgstllt [45]. Positiv Ngativ Babsichtigt Koopration Widrspruch Unbabsichtigt Binflussung Schadhaft/Fhlnd Tabll 2.1: Klassifikation von Fatur-Intraktionn 12

31 2.1 Dlta-orintirt Softwarproduktlinin In dr Tabll 2.1 ist zu rknnn, dass Fatur-Intraktionn zu babsichtigtn Effktn führn könnn, z.b. dr Koopration odr dm Widrspruch. Dis kann durch di Anfordrungn dr Faturs dfinirt wrdn. Es sind jdoch auch unbabsichtigt, positiv wi ngativ Einflüss möglich. Im Rahmn ds Produkttstns ist s dahr rlvant, potntill Fatur-Intraktionn fstzustlln und dis gsondrt zu bhandln [45] Dlta-orintirt Softwarntwicklung Di Dlta-Modllirung wurd von Schafr t al. als Ansatz für di Ralisirung von Variabilität in dr modllbasirtn SPL-Entwicklung vorgstllt [51, 48]. Dr sprachunabhängig Entwicklungsansatz bruht auf inm gminsamn Krn und Dltas, di Transformationn auf Systmn bschribn. Damit lassn sich widrvrwndbar Artfakt in Produktlinin modllirn. Di Variabilität von Softwarproduktlinin wird durch di Entwicklung dr Dltas abgdckt. Ein formal Dfinition dr Dltas stllt Schafr [48] bnfalls vor. Dltas könnn durch di Unabhängigkit von Sprachn odr Umgbungn flxibl ingstzt wrdn. Bi dn Ralisirungn ds Konzpts spricht man j nach Einsatzgbit z.b. von Dlta-Modllirung odr Dlta-Programmirung. In disr Arbit wird in Softwararchitktur als Grundlag für di Produktgnrirung inr Softwarproduktlini vrwndt. Es wird dahr dr Ansatz dr Dlta-Modllirung vrwndt. Als Ausgang wird in initials, abstrakts Modll dr Softwarproduktlini dfinirt, das di Variabilität ds Faturmodlls rfasst. Dis ist wi di folgndn Bschribungn in 2.4 grafisch dargstllt. Es folgn witr Modllirungsphasn, in dnn witr, dtaillirtr Aspkt dr Produkt bschribn wrdn. Auf jdr Ebn wird di Produktvariabilität durch in Krnmodll und in Mng von Dltamodlln bschribn. Das Krnmodll sollt inm gültign Produkt dr SPL ntsprchn, muss dis jdoch nicht zwangswis. Dltamodll bschribn Transformationn ds Krnmodlls, di andr Produkt rpräsntirn. Man untrschidt in add-,rmov- und modify-oprationn, di Dltas auf inm Modll durchführn könnn. Jdm Dltamodll wird in Application Condition bzw. Anwndungsbdingung hinzugfügt. Dis bschribn, für wlch Faturkonfigurationn di ntsprchndn Dltas angwandt wrdn solln. Ein Application Condition kann z.b. in bool schr Ausdruck übr inr Mng von Faturs sin. Si bschribt, für wlch Faturkonfiguration in Dlta mit sinn Oprationn angwndt wird. Um das Produktmodll für in Faturkonfiguration zu rhaltn, wrdn di dazughörign Dltas auf das Krnmodll angwndt. Di dfinirtn Application Conditions rlaubn Flxibilität, insofrn si nicht zu spzill gwählt wrdn. Di Entwicklung ins Krnmodlls wird von Schafr als krativr Prozss bschribn [48], dr durch hrkömmlichs Singl Application Enginring durchgführt wrdn kann. Das Ergbnis sollt in gültig Faturkonfiguration für in Produkt sin, d.h., dass di gnrirt Produktvariant durch das Faturmodll abgdckt sin sollt. In disr Arbit wrdn Softwararchitkturn als Modll dinn, wobi di zu 13

32 2 Grundlagn Krnprodukt Faturkonfiguration K1 K2 Dlta 1 Add K1 + +K4 K3 + Krn + Dlta 1 K1 K4 Produkt K2 K3 Faturmodll Application Condition Dlta 2 Add K1 + K4 + Krn + Dlta 1 + Dlta 2 K1 K4 K2 K3 K1 Dlta 3 Rm K3 + Krn + Dlta 1 + Dlta 2 + Dlta 3 K1 K4 K2 K3 Krn + Dlta 1 + Dlta 2 + Dlta 3 Dlta 4 Rm + Dlta 4 -K3 + K1 K2 K4 Abbildung 2.4: Dlta-Konzpt am Bispil inr Softwararchitktur bschribndn Produktkonfigurationn und Applikationsbdingungn aus dm brits bschribnn Faturmodll rstllt wrdn. Das Krnmodll wird auf Basis dr von Zink [56] und Lity [30] bschribnn Produktkonfigurationn gwählt. Im Bispil aus Abbildung 2.4 bstht das Krnprodukt zunächst aus dri Komponntn: K1, K2 und K3. Es wrdn insgsamt vir Dltas inkrmntll auf das Krnprodukt angwndt. Dabi wrdn zunächst zwi add-funktionn durchgführt, wobi di hinzugfügtn Elmnt mit inm + gknnzichnt sind. Anschlißnd wrdn zwi rmov-dltas angwndt. Di ntfrntn Elmnt wrdn hirbi mit inm notirt. Durch di inkrmntll Anwndung dr vrschidnn Dltas ntstht im Bispil in Softwararchitktur, di durch di jwils fstglgt Application Condition bstimmtn Faturs bzw. Produktn zugordnt wrdn kann. Es lässt sich somit aus 14

33 2.2 Softwararchitkturn dm Krnprodukt in wohlgformts, konfliktfris Produkt gnrirn. Bi dr Anwndung vrschidnr Dltas nachinandr kann s zu Konfliktn kommn, di dn Dfinitionn dr Dltas ntspringn. Um dis zu vrmidn, muss in Rihnfolg für di Anwndung dr Dltas fstglgt wrdn. Zu dism Zwck wird in Ordnungsrlation für jds Dlta dfinirt, di angibt, wlchs Dlta zuvor angwndt wrdn muss. Durch di Aufsplittung von Krnprodukt und Dltas könnn Produkt volutionär ntwicklt wrdn. Durch nu Dltas lassn sich nu Faturs in brits bsthnd SPLs intgrirn. Di für dis Arbit ingstztn Dltas und drn Dfinition wrdn in Kapitl 3 dtaillirt bschribn. Dabi wrdn di inzlnn Transformationn, di auf Softwararchitkturn durchgführt wrdn, rläutrt und in Zusammnhang mit Faturmodlln gbracht. Es wird rläutrt, wi in Application Condition in dr btrachttn Domän dfinirt wrdn kann, um di Anwndung von Dltas zu sturn. 2.2 Softwararchitkturn Bi dr Softwarntwicklung wird in Softwarprodukt häufig in Softwarkomponntn untrtilt. Es gstattt dn Entwicklrn gzilt inzln Komponntn unabhängig voninandr zu ntwickln und ggbnnfalls durch vrändrt Vrsionn auszutauschn, ohn zwangsläufig di Struktur andrr Tilkomponntn zu binflussn. Auch wird das Produkt durch dis Zrlgung klar strukturirt und kann von mnschlichn Btrachtrn bssr vrstandn wrdn. Di Gsamthit dr Softwarkomponntn und drn Vrbindungn untrinandr wird als Softwararchitktur bzichnt [53]. Dis wird von Russnr t al. [47] wi folgt dfinirt: Di Softwar-Architktur ist di grundlgnd Organisation ins Systms, dargstllt durch dssn Komponntn, drn Bzihung zuinandr und zur Umgbung, sowi di Prinzipin, di dn Entwurf und di Evolution ds Systms bstimmn. Währnd dr Entwicklung inr Softwararchitktur kann dis durch untrschidlich Architkturbschribungn dfinirt wrdn [3]. Architkturn könnn aus vrschidnn Sichtn bzw. Standpunktn hraus modllirt wrdn. Russnr t al. [47] sagn aus, dass dis Bschribungn grundsätzlich dm Zwck dr [...] Darstllung strukturllr Dkompositionn ins komplxn Softwar-Systms dinn. In dn ltztn Jahrn wurdn vrschidn Standards für Modllirungsformn dfinirt. Es soll auf zwi Möglichkitn, dr grafischn Darstllung sowi dn Architkturbschribungsprachn, inggangn wrdn. Di grafisch Rpräsntation von Softwararchitkturn basirt auf aussagkräftign Diagrammn, di das Systmvrhaltn odr dn Systmaufbau widrspigln. Dis vrinfacht di Kommunikation zwischn vrschidnn, an dr Entwicklung btiligtn Partin und rhöht di Vrständlichkit dr Architktur für di Btiligtn. Si ignn sich bnfalls zu Dokumntationszwckn. Di Diagrammvariantn 15

34 2 Grundlagn dr UML [43] stlln in bkannt Form dar. In dr UML wrdn vrschidn Diagrammtypn dfinirt, di zur Modllirung von Architkturn gnutzt wrdn könnn. Bi dr Darstllung von Softwararchitkturn vrwndt man mist Kompositionsstrukturdiagramm. Ein Bispil für in Kompositionsstrukturdiagramm ist in Abbildung 2.5 dargstllt. Hirbi handlt s sich um in Softwararchitktur ins Produkts dr Fallstudi ds Body-Comfort-Systms [56]. Es ist hrvorzuhbn, dass di intrn Struktur dr rpräsntirtn Komponntn nicht dargstllt wird und für disn Diagrammtyp nicht rlvant ist. Di abgrundtn Virck in Abbildung 2.5 rpräsntirn di Komponntn. Es pw_but_mv_dn pw_but_up pw_mv_dn pw_but_mv_up m_but_mv_l0 m_but_mv_right m_but_mv_up HMI pw_but_dn m_but_right m_but_down m_but_up pw_pos_up pw_pos_dn ManPW pw_mv_up m_but_mv_dn m_but_l0 fp_on fp_off fingr_dtctd FP m_mv_l0 m_mv_right m_pos_l0 m_pos_right EM m_mv_up m_mv_down m_pos_top m_pos_bo7om Abbildung 2.5: Bispil für in Softwararchitktur gibt vir Softwarkomponntn in disr Architktur: FingrProtction bzichnt inn Fingrinklmmschutz ds Fnstrs, AutoPW inn automatischr Fnstrhbr, in Human Machin Intrfac, kurz HMI, wlchs in Stur- und Informationsinhit darstllt und inn Außnspigl, im Diagramm mit EM für Extrior Mirror gknnzichnt. Drn Bdutung wurd in Kapitl 1.2 bschribn und ist im Folgndn nicht rlvant. Zwischn dn Komponntn xistirn Konnktorn, übr di Signal komponntnübrgrifnd ausgtauscht wrdn. Dis wrdn durch in Kant rpräsntirt. Di Bschriftungn dr Kantn sind di darin übrtragnn Signal. Konnktorn wrdn durch Ports mit dn Komponntn vrbundn. Ports sind durch klin Virck an dn Komponntn gknnzichnt. Si stlln di Signalschnittstlln dr Komponntn dar. Konnktorn könnn auch mit dr Umwlt bzw. dr Umgbung dr Softwar vrbundn sin, d.h. s könnn Signal aus dr Umgbung an inr Komponnt intrffn odr di Komponntn könnn Signal in di Umgbung sndn. Di Richtung ins Konnktors gibt di Sndrichtung ds Signals an. So wrdn bispilswis von dr Komponnt FingrProtction zwi Signal, fp_on und fp_off, 16

35 2.2 Softwararchitkturn an di Komponnt AutoPW gsndt. Nbn dr strukturbasirtn Darstllung wrdn bnfalls vrhaltnsbasirt Diagramm zur Modllirung von Softwararchitkturn vrwndt. Dis wrdn nbn statischn Bschribungn ingstzt, um das Vrhaltn dr Komponntn zu modllirn. In disr Arbit wrdn hirfür Squnzdiagramm bzw. Mssag Squnc Charts (MSC) vrwndt [24]. Drn Aufbau wird am Bispildiagramm in Abbildung 2.6 rläutrt. HMI FP ManPW l 1 fingr dtctd l 1 f l 2 f fp on l 1 p l 2 pw but mv dn l 1 h l 2 h pw but dn l 3 f l 4 f fp off l 2 p l 3 h pw but dn l 3 p l 3 pw mv dn l 4 p Abbildung 2.6: Bispil für in Squnzdiagramm mit zwi Komponntn Di Grundstruktur ins Squnzdiagramms bstht zunächst aus dn darin bschribnn Komponntn, wlch durch bschriftt Virck am obrn Rand dargstllt wrdn. In dm konkrtn Bispil aus Abbildung 2.6 gibt s zwi Komponntn. Si sind mit FP und AutoPW gknnzichnt (Vgl. Abbildung 2.5). Von Komponntn ghn snkrcht Lbnslinin aus. Mit disn Linin wird das im Diagramm bschribn Vrhaltn durch in- bzw. ausghnd Signal modllirt und drn zitlich Abfolg rpräsntirt. Signal wrdn durch waagrcht Kantn dargstllt. Wird in Signal gsndt bzw. mpfangn, bzichnt man dis als in intrffnds Evnt. Dis sind durch Krissymbol auf dn Lbnslinin gknnzichnt. Evnts ohn Lbnslini, im Bispildiagramm auf dr linkn Sit, ghörn zur Umgbung. Dis wird implizit modllirt und nicht als ignständig Komponnt dargstllt. Zu inm Signal ghörn stts zwi Evnts. Dis sind kausal voninandr abhängig und wrdn im Modll synchron ausgführt. Di in disr Arbit vrwndtn Squnzdiagramm sind zitlich nicht präzis dfinirt, d.h. s gibt kin fst Zitinhit innrhalb dr Diagramm. Squnzdiagramm könnn in disr Arbit nichtdtrministischs Vrhaltn bschribn. Ein Squnzdiagramm stllt immr nur inn bstimmtn Ausschnitt ds Softwarvrhaltns dar. Im konkrtn Bispil würd zunächst das Signal fingr_dtctd 17

36 2 Grundlagn von dr Umgbung an di Komponnt FP gsndt wrdn. Im nächstn Zitschritt schickt FP fp_on an di Komponnt ManPW tc. Nbn dr grafischn Darstllung von Softwararchitkturn könnn dis auch in txtullr Form bschribn wrdn. Dazu wrdn Architkturbschribungssprachn odr Architctur Dscription Languags (ADL) vrwndt [12]. ADLs könnn dn Domain Spcific Languags (DSL) zugordnt wrdn [38]. Dis sind Sprachn, di gzilt für in bstimmt Domän dfinirt wrdn und spzill darauf zugschnittn Eignschaftn bsitzn [13]. Ein ADL wird von Russnr t al. [47] wi folgt dfinirt: Ein Architkturbschribungssprach ist in Notation für di formal Bschribung von Architkturn komplxr Softwar-Systm. Di Forschung hat vrschidn ADLs hrvorgbracht. Einig populär Bispil für Sprachn sind ArTk, Darwin, Rapid odr Wright [36, 12]. Di Grundlmnt disr Sprachn sind oft ähnlich. Man untrschidt Komponntn, Konnktorn und Konfigurationn [47]. Ein ADL wird formal durch ihr Grammatik dfinirt, di widrum di Syntax dr Sprach vorgibt. In dr Grammatik könnn logisch Ausdrück vrwndt wrdn, um di Sprachnsyntax formal zu bschribn. Ein Grammatik für di Fallstudi und dn dazughörign Modlln wird in Kapitl 3 bschribn. Es wird in Architkturbschribungssprach dfinirt, drn Zil di Rpräsntation inr dlta-orintirtn Softwararchitktur inr Softwarproduktlini ist. 2.3 Tstn von Softwar Im dism Abschnitt soll in Motivation für di Notwndigkit von Tstn ggbn wrdn. Es wrdn Bgrifflichkitn aus dm Brich ds Tstns dfinirt. Anhand ds V-Modlls wird inr dr bkanntstn Tstprozss vorgstllt. Anschlißnd wird di vrändrt Vrsion ds V-Modlls dr Automobilindustri aufgzigt. Dr Fokus ligt auf dr Phas ds Intgrationststs. Es wird in Klassifizirung von Tsttchnikn vorgstllt. Ein bsondrs Augnmrk ligt auf dn Rgrssionststs. Dr Prozss ds modllbasirtn Tstns wird im ltztn Abschnitt bschribn Trminologi Als Grundlag für di folgndn Kapitl solln zunächst inig wichtig Bgriff aus dm Brich ds Softwartstns dfinirt wrdn. Dis könnn von Dfinitionn andrr Litratur abwichn. Tstn: Ein Aktivität, di zur Evaluation von Produktqualität und drn Vrbssrung ingstzt wird. Dckt Fhlr und Problm auf [55]. Tstfall: Ist in Softwarkonfiguration, di dr Tstdurchführung dint [29]. 18

37 2.3 Tstn von Softwar Tstorakl: Gibt di Sollwrt für di durchzuführndn Tstfäll vor. Kann u.a. aus dn Spzifikationn hrglitt wrdn [20]. Übrdckungsgrad: Grad dr Vollständigkit ins Tsts bzogn auf di Tsttchnik [29]. Funktional Anfordrungn: Anfordrungn, di gwünscht Funktionalitätn bschribn [20]. Nicht-funktional Anfordrungn: Anfordrungn, wlch di Qualität dr Softwar bschribn [20]. Whitboxtst: Bschribt Tstvrfahrn, in dnn di intrn Struktur ds zu tstndn Objkts bkannt ist und vrwndtt wird. Aus dr Struktur wrdn di Tstfäll und Übrdckungskritrin gnrirt [20]. Blackboxtst: Bi disn Tstvrfahrn ist di intrn Struktur ds zu tstndn Objkts unbkannt. Di Tstfäll und Übrdckungskritrin wrdn an di Spzifikation anglhnt [20] Intgrationstst innrhalb ds V-Modlls Softwarntwicklr vrsuchn ihr Produkt dn Anfordrungn ds Kundn ntsprchnd zu ralisirn. Daruntr falln funktional und nicht-funktional Anfordrungn [20]. Di Qualität ins Produkts lässt sich an vrschidnn Faktorn mssn. Ein Faktor, dr bi jdm Produkt von Bdutung ist, ist di Anzahl und Schwr dr darin nthaltndn Fhlr. Es ist davon auszughn, dass in fhlrfris Produkt nicht xistirt [20]. Nbn dr Softwarntwicklung ist dahr das Tstn ds zu ntwicklndn Produkts von höchstr Priorität. Fhlr könnn in bstimmtn, sichrhitskritischn Brichn zu drastischn Folgn für di Nutzr führn und solltn brits währnd dr Entwicklung rkannt wrdn. J frühr in Fhlr ntdckt und bsitigt wrdn kann, dsto wnigr kostt di Fhlrbrinigung für dn Entwicklr. Fhlrkostn stign mit dr zunhmndn Entwicklungsforstschritt, da s zu Sitnffktn kommn kann, di sich auf mhrr Komponntn ngativ auswirkn könnn. Di fst Vrwbung von Softwarntwicklung und Softwartstn ist in dn ltztn Jahrn immr populärr gwordn. Eins dr bkanntstn Rsultat für Softwarntwicklungsprozss ist das V-Modll. Diss bschribt di untrschidlichn Stufn ins Entwicklungsprozsss, bi dm vrschidn Stadin mitinandr vrknüpft sind. Ein Variant ds klassischn V-Modlls ist in Abbildung 2.7 dargstllt (Eigndarstllung in Anlhnung an [20]). Das V-Modll tilt sich grundsätzlich in inn ab- und inn aufstigndn Ast, wl- 19

38 2 Grundlagn Abbildung 2.7: V-Modll ch das namnsgbnd V rpräsntirn. Dr link Ast wird durch di Phasn dr Softwarkonstruktion bschribn, dr rcht Ast durch di Phasn ds Softwartstns. Dabi wrdn dis nicht linar abgarbitt, sondrn sind auch untrinandr vrwobn. Dis wird durch di Kantn zwischn dn bidn Ästn dutlich. Im Zusammnhang mit dr Aufgabnstllung wrdn nun di bidn Phasn ds Komponntn- und Intgrationststs dtaillirt bschribn. Di Bschribungn wurdn aus [20] ntnommn. Komponntntst: Dr Komponntntst stllt di rst konkrt Tstphas im V-Modll dar. Zuvor wurdn währnd dr Konstruktionsphasn Tstvorbritungn gtroffn. Im Komponntntst wrdn di inzlnn, in dr Programmirungsphas ntwickltn Komponntn gtstt. Dabi wrdn di Komponntn isolirt voninandr btrachtt. Trtn Fhlr auf, könnn dis dirkt dn fhlrhaftn Komponntn zugordnt wrdn. Di Tstbasis ist mist di Komponntnspzifikation, di in dn Konstruktionsphasn für jd Komponnt dfinirt wurd. Für dn Komponntntst wird in Tstumgbung bnötigt. Dis rmöglicht di Ausführung dr Tstfäll für Whitboxtsts. Whitboxtsts wrdn im Komponntntst vrwndt, da dr Qullcod dn Tstrn zur Vrfügung stht. Di Tstumgbung lifrt Tsttribr, wlch di Dinst, di das Tstobjkt aufrufn, simulirn. Zusätzlich gibt si Platzhaltr odr Stubs vor, di Dinst, wlch vom Tstobjkt aufgrufn wrdn, simulirn. Di Funktionalität ins Tstobjkts ist glichbdutnd mit sinm Ein- bzw. Ausgabvrhaltn. Um dis zu tstn, wird di Komponnt inr Rih von Tstfälln untrzogn. Tstzil könnn in Tst auf Robusthit, Effizinz und Wartbarkit sin. Auch Blackboxtsts könnn in dr Phas ingstzt wrdn. Für Bispil von Tst- 20

39 2.3 Tstn von Softwar tchnikn si auf Kapitl vrwisn. Intgrationstst: Di Grundlag disr Tstphas ist in abgschlossnr Komponntntst. Im Lauf dr Phas wrdn nicht di Komponntn slbst gtstt, sondrn drn Vrhaltn und Intraktion untrinandr. Diss Vorghn kann itrativ aufgbaut wrdn, um di Komponntn sukzssiv ggninandr zu tstn. Das angstrbt Ergbnis ist in funktionirnds Systm, wlchs aus alln zuvor gtsttn Komponntn bstht. Dazu wrdn di vrschidnn Komponntnschnittstlln auf ihr korrkt Funktionswis gtstt. Grundlag für di Tstfäll disr Phas ist dr tchnisch Systmntwurf in Form dr Softwararchitktur. Dis dfinirt di Schnittstlln und drn Konnktorn. Si rmöglicht di Gnrirung von Tstfälln, di di Funktionalität dr Komponntnschnittstlln und di darübr angstrbt Kommunikation zwischn Komponntn ggn di Anfordrungn tstn. In dr Litratur wrdn vrschidn Möglichkitn für Intgrationstststratgin bschribn. Dis dfinirn di Rihnfolg, in dr Komponntn in das brits bsthnd Systm hinzugfügt wrdn. Man untrschidt grundsätzlich in Top-Down und Bottom-Up-Intgrationsstratgin. Bi dr Top-Down-Intgration wird als Ersts mit dr grundlgndn Komponnt bgonnn, di andr Komponntn aufruft und slbst nur vom Btribssystm aufgrufn wird. Im Ggnsatz dazu bschribt in Bottom-Up-Intgration dn Bginn mit lmntarn Komponntn, di kin andrn Komponntn aufrufn. Di Komponntn lassn sich auch in blibigr Rihnfolg hinzufügn. Das Arbitsvorghn dr Entwicklr kann in Kritrium dafür sin. In disr Mastrarbit wird von inr Krnkonfiguration ausggangn [30], wlch in Produkt dr Fallstudi rpräsntirt. Das Hinzufügn, Ändrn bzw. Entfrnn von Komponntn in dr Systmarchitktur wird durch Dltas dr Produkt dfinirt (sih Kapitl 2.3). In dr Arbit kommn vrschidn Tstabdckungskritrin zum Einsatz, um dn Grad dr Tstfallübrdckung zu rmittln und di Tstfallgnrirung inzuschränkn. Das V-Modll rpräsntirt in Möglichkit für Softwarntwicklung, di mit Softwartstn vrzahnt ist. In dr Praxis xistirn zusätzlich andr Prozssartn. Bispil hirfür sind das Wassrfallmodll odr das W-Modll, wlchs in Erwitrung ds V-Modlls darstllt [20]. In dr Automobilindustri hat sich in angpassts V-Modll durchgstzt. Di folgndn Bschribungn wurdn [52] ntnommn. Di rst Ändrung am Tstzwig ds V-Modlls ist di Aufsplittung ds Intgrationststs in di Intgration dr Softwarkomponntn und dn anschlißndn Intgrationstst. Danach folgt di Intgration dr Systmkomponntn und dr Intgrationstst ds Systms. Dis Phasn sind im klassischn V-Modll nicht bschribn. Si bzihn sich auf di Intgration von Softwar und Hardwar. Dis ligt in dr Natur dr zu ntwicklndn Softwar, di mist für Sturgrät im Automobil gschribn wird. Nach dm Intgrationstst ds Systms rfolgt di Kalibrirung. Dis nu Tstphas bziht sich auf das konkrt Systm, dssn individullr Tst notwndig ist, da s in dr Produktion zu außrplanmäßign Abwichungn kommn kann, di spzill für das konkrt 21

40 2 Grundlagn Endprodukt ausgglichn wrdn müssn. Di ltztn bidn Tstphasn wrdn als Systm- und Akzptanztst bzichnt. Si wrdn analog zu dn im klassischn V- Modll bschribn Systmtst und Abnahmtst durchgführt. Das Systm ist das Automobil, dssn Akzptanztst in dr raln Umgbung durchgführt wird. In disr Arbit wird dr Intgrationstst an das von Schäuffl t al. [52] vorgstllt Modll anglhnt. Es wrdn zunächst Komponntn intgrirt, wobi dis durch di Produktbschribung vorggbn ist, und anschlißnd auf Systmarchitkturbn gtstt. Das vrwndt Intgrationststvrfahrn wird in Kapitl 4 dtaillirt bschribn Tsttchnikn In dr Litratur findn sich vrschidn Mthodn, um Tstfäll zu gnrirn und Tsts durchzuführn. Dis könnn nach vrschidnn Kritrin klassifizirt wrdn. Liggsmyr [29] untrschidt grundsätzlich dynamisch Softwar-Prüftchnikn und statisch Analysn. Dynamisch Tsts habn als gminsams Mrkmal di Ausführung dr Softwar mit konkrtn Eingabwrtn. Dis kann untr raln Btribsbdingungn gschhn. Untr dn dynamischn Prüftchnikn ordnt Liggsmyr [29] di folgndn Tstartn in: Strukturorintirt: Wird in kontrollflussorintirt und datnflussorintirt Tsts klassifizirt: Kontrollflussorintirt: Das Zil disr Tchnikn ist in Abdckung dr Kontrollstrukturlmnt dr Softwar. Bispil für dis Klass sind z.b. dr Anwisungsübrdckungstst, dr Zwigübrdckungstst und dr Pfadübrdckungstst. Datnflussorintirt: Dis Tsttchnikn habn di Dfinition von Rgln als Zil, mit drn Hilf in vollständig Abdckung dr Datnzugriff dr Softwar möglich ist. Bispil sind dr Rquird k-tupls-tst odr Dfs-/Uss-Kritrin. Funktionsorintirt: Hirbi handlt s sich um Blackboxvrfahrn. Si gbn Rgln vor, nach dnn aus dr Spzifikation Tstfäll abzulitn sind. Das Zil ist di vollständig Abdckung dr Spzifikation. Dr Programmcod ist unbkannt. Es gibt dahr kin garantirt Vollständigkit dr Abdckung dr Programmstruktur. Divrsifizirnd: Dis Tsttchnikn prüfn Korrkthit nicht anhand von Spzifikationn, sondrn durch dn Vrglich zu andrn Vrsionn dr zu tstndn Softwar. Für di Tstvollständigkit könnn untrschidlich Kritrin vrfasst wrdn. Als Bispil sin dr Back-to-Back-Tst und dr Rgrssionstst gnannt. 22

41 2.3 Tstn von Softwar Untr dr statischn Analys fasst man Mthodn zusammn, di kin Ausführung von Softwar binhaltn. Si könnn stts ohn Computruntrstützung durchgführt wrdn und bnötign kin Tstfäll. Si sind als manull Tsts zu vrsthn, di jdoch mit Wrkzuguntrstützung durchgführt wrdn könnn. Liggsmyr [29] untrschidt dabi in vrifizirnd und analysirnd Mthodn. Analysn findn mist auf dn Dokumntn dr Softwarntwicklung statt und umfassn z.b. Grafikn und Tablln, Stilanalysn, Datnflussanomalianalysn odr Inspktionn bzw. Rviws dr Dokumnt. Di Inspktions-und Rviwtchnikn untrschidn sich von dn zuvor gnanntn Analysn durch in fhlnd Wrkzuguntrstützung. Si wrdn von Gutachtrn durchgführt [20]. Di vrifizirndn Tchnikn umfassn formal Mthodn, di vrsuchn (...) dn Bwis dr Konsistnz zwischn inr Softwar und ihrr Spzifikation mit formaln Mittln zu rbringn. [29] Rgrssionststn Dr Rgrssionstst ist für dis Arbit von bsondrr Rlvanz. Liggsmyr [29] dfinirt Rgrssionststn wi folgt: Widrholung brits durchgführtr Tsts nach Ändrungn. Dr Rgrssionstst dint zur Übrprüfung dr korrktn Funktion nach Modifikation, wi z.b. Fhlrkorrkturn odr Funktionsrwitrungn. Dr Rgrssionstst wird dn divrsifizirndn Tchnikn zugordnt, da r vrschidn Vrsionn ins Systms odr dssn Komponntn ggninandr tstt. Es soll sichrgstllt wrdn, dass Softwar nach Ändrungn in Bzug auf ihr Funktionalität und Spzifikation witrhin fhlrfri funktionirt. Fhlr könnn durch Softwarmodifikationn ntsthn, di andr Systmtil binflussn. Dr Rgrssionstst dint dmnach dm Aufspürn von Sitnffktn durch Modifikationn. Um dis zu tstn, müsstn thortisch all brits durchgführtn Tstfäll rnut auf dm modifizirtn Systm gtstt wrdn. Di Korrkthit rnut gtsttr Tstfäll wird durch Vrglich zwischn dn nun Tstausgabn mit dnn dr Vorgängrvrsion vrglichn. Dis wrdn als Rfrnzingabn und Rfrnzrgbniss odr zusammnfassnd als Rfrnztstfäll bzichnt. Abbildung 2.8 stllt dn Zusammnhang bildlich dar (Abbildung in Anlhnung an [29]). Rgrssionststn gilt durch dn hohn Tstaufwand als di turst Tsttchnik und kann bis zu 80% dr Tstkostn ins Softwarprojkts ausmachn [15]. Dis führt in dr Forschung zu inr Rih von Mthodn, di dn Tstaufwand vrringrn solln. Ein Krnkonzpt ist di Erknnung von Rdundanz und dr Filtrung von Tstfälln, di nicht mit dn vorgnommnn Modifikationn in Vrbindung sthn [29]. In Softwarproduktlinin wird dr Rgrssionstst nicht ggn Ändrungn in dr zitlichn Entwicklung inr Softwar, sondrn auf Basis dr Variantn ds Systms 23

42 2 Grundlagn Abbildung 2.8: Prinzip ds Rgrssionststs ausgführt. Auf Grund ds hohn Grads von Variabilität innrhalb inr SPL ntstht in potntill großn Anzahl zu tstndr Produkt, di mit Anzahl dr angbotnn Faturs xponntill zunimmt. Dis führt zu inr unübrschaubar großn Anzahl von möglichn Tstfälln, di in vollständigs Rgrssionststn allr Produktkonfigurationn impraktikabl machn. Dnnoch btont Liggsmyr di Notwndigkit von Rgrssionststs, da dis von viln Standards gfordrt wrdn. Auch di Automatisirung von Rgrssionststs ist von großr Wichtigkit. Engström [15] dfinirt dahr in Zil dr Forschung innrhalb dr Softwarproduktlininntwicklung wi folgt: Evaluat possibl stratgis for improvd tst slction, aiming at minimizing th amount of rdundant tsting, in softwar product lin dvlopmnt. In Kapitl 4 wrdn möglich Mthodn zur Vrringrung ds Tstaufwands für inn Rgrssionstst auf Softwarproduktlinin vorgstllt. Ein Evaluirung disr wird in Kapitl 6 durchgführt Modllbasirts Tstn Modllbasirts Tstn bschribt bstimmt Vrfahrn zur Tstgnrirung. Utting und Lgard [55] dfinirn vir Hauptansätz für modllbasirts Tstn: Erstllung von Tstingabdatn aus inm Domain Modll 24

43 2.3 Tstn von Softwar Erstllung von Tstfälln aus inm Umgbungsmodll Erstllung von Tstfälln mit Orakln aus Vrhaltnsmodlln Erstllung von Tstskriptn aus abstraktn Tsts In disr Arbit wird dr dritt Ansatz gwählt. Als Vrhaltnsmodll dinn di zuvor bschribnn Squnzdiagramm. Das Zil ist s, Tstfäll zusammn mit dn dazughörign Tstorakln zu gnrirn. Dis dint dr Prüfung auf Korrkthit dr Tstrgbniss. Das Modll muss dahr das rwartt Vrhaltn ds Tstobjkts bschribn. Im Folgndn wird dahr di Dfinition aus [55] für modl-basd tsting vrwndt: Modl-basd tsting is th automation of th dsign of black-box tsts. Durch modllbasirts Tstn kann das Dsign von Tstfälln automatisirt wrdn. Dis wird durch di Entwicklung ins abstraktn Tstmodlls ds Systm Undr Tst (SUT) gwährlistt, anhand dssn in modllbasirts Tstwrkzug in Mng von Tstfälln gnrirn kann. Als SUT wird das zu tstnd Systm bzichnt. Modllbasirts Tstn vrkürzt di Dsignzit für Tstfäll und rlaubt s vrschidn Tstsuits aus dm slbn Modll durch vrschidn Tstkritrin zu gnrirn. Utting und Lgard untrglidrn das modllbasirt Tstn in fünf Phasn [55]: Modllirung ds Systm Undr Tst und dssn Umgbung Gnrirung von abstraktn Tstfälln Konkrtisirn dr abstraktn Tstfäll, um si ausführn zu könnn Ausführung dr Tsts auf dm SUT Analysirn dr Tstrgbniss Dr Zusammnhang dr inzlnn Phasn ist in Abbildung 2.9 grafisch dargstllt (Abbildung in Anlhnung an [55]). Di rstn bidn Phasn sind kritisch. Durch si untrschidt sich das modllbasirt Tstn von andrn Tstprozssn. Di rst Phas dr Modllirung binhaltt di Entwicklung ins abstraktn Modlls ds SUTs. Es wird als abstrakts Modll bzichnt, da das Modll kompaktr und infachr als das zu tstnd Systm sin sollt. Dr Fokus ds Modlls ligt auf dn Tiln ds Systms, di gprüft wrdn solln. Auf dm ntwickltn Modll könnn im Anschluss Vrifikationsvrfahrn durch ntsprchnd Wrkzug durchgführt wrdn, um di Konsistnz und Korrkthit ds Modlls zu prüfn. Fhlr in dm gfrtigtn Modll solltn in dr Modllirungsphas rkannt und bhobn wrdn. Hat man in abstrakts Modll, kann im Anschluss di Phas dr Tstfallgnrirung durchgführt wrdn. Dazu wird in Tstauswahlkritrium bnötigt. Diss lgt fst, wlch Tsts aus dm Modll gnrirt wrdn solln, da s potntill unndlich vil Tstfäll gibt [55]. Zur Tstauswahl könnn Tstübrdckungskritrin 25

44 2 Grundlagn 1. Modllirn Anfordrungn Tstplan 2. Gnrirn Modll Tstfallgnrator Tstfäll Rquirmnts Tracability Matrix Covrag Rport 3. Konkrtisirn Tstskript Adaptr 5. Analysirn Tstskriptgnrator Tstausführungswrkzug 4. Ausführn Tstrgbniss Sytm Undr Tst (SUT) Abbildung 2.9: Ablauf ds modllbasirtn Tstns vrwndt wrdn. Daruntr fällt z.b. das all-transitions-kritrium, das fordrt, dass all Transitionn in inm Modll mindstns inmal bnutzt wrdn. Es könnn auch Tstfallspzifikation gschribn wrdn odr man fokussirt dn Tst auf inn bstimmtn Til ds Modlls. Unabhängig von dr gwähltn Variant bstht das Ergbnis disr Phas aus dn gnrirtn, abstraktn Tstfälln für das Systm. Ein Tstfall ist in Konfiguration ds Modlls. Dis sind auf Grund ds fhlndn Dtailgrads noch nicht ausführbar. In dr zwitn Phas kann zusätzlich noch in rquirmnts tracibility matrix rstllt wrdn, di Links zwischn funktionaln Anfordrungn und dn dazughörign Tstfälln aufstllt [55]. Auch di Erstllung ins covrag rports ist möglich, dr fsthält, inwifrn di Tstfäll sämtlich Vrhaltnswisn ds Modlls abdckn [55]. In dr drittn Phas wrdn di abstraktn Tstfäll konkrtisirt und in ausführbar Tsts transformirt. Dis kann durch Vrwndung ins Transformationswrkzugs bzw. Tstskriptgnrators gschhn odr durch di Entwicklung ins Adaptrcods (sih Abbildung 2.9). Ein Vortil dr Trnnung von abstraktn und konkrtn Tst- 26

45 2.3 Tstn von Softwar fälln ist di Unabhängigkit dr abstraktn Tstfäll dr Programmirsprach ds SUTs. In dr virtn Phas wrdn di zuvor gnrirtn Tstfäll auf dm Systm Undr Tst ausgführt. Bi onlin modl-basd Tsts wrdn di Tstfäll dirkt nach ihrr Erstllung ausgführt, bim offlin-tstvrfahrn wird in Mng von Tstskripts rstllt, di dann anschlißnd von brits vrwndtn Programmn ausgführt wrdn. Di ltzt Phas binhaltt di Analys dr Tstrgbniss und falls nötig, korrigirnd Maßnahmn. Für fhlrhaft Tsts müssn di Fhlrgründ rmittlt wrdn. Fhlr könnn im SUT odr im Tstfall lign. Ligt in Fhlr im Tstfall vor, so muss dr ursprünglich Fhlr in dr vrwndtn Transformation, dm abstraktn Modll odr dn Anfordrungn lign. Das Zil dr Arbit bstht darin, inn Tstprozss zu dfinirn, dr aus dn Vrhaltnsmodlln dr Produkt Tstfäll und Orakl rstllt und dis mit dm anschlißnd durchgführtn Tst vrglicht. Disr Prozss wird in Kapitl 4 gnau bschribn. 27

46 3 Dlta-orintirt Modllirung von Softwararchitkturn In dism Kapitl wrdn Softwararchitkturn dtaillirt bschribn und drn Bstandtil dfinirt. Es wird Variabilität in Softwararchitkturn rläutrt, um anschlißnd in Softwararchitkturbschribungssprach zu dfinirn, di zur Modllirung von dlta-orintirtn Softwarproduktlinin gnutzt wrdn kann. Hirfür wrdn di Architkturbstandtil formal dfinirt und di Grammatik dr Sprach bschribn. 3.1 Bschribungn von Softwararchitkturn Softwararchitkturn rpräsntirn di Komponntnstruktur und Komponntnkommunikation ins Softwarsystms [21]. Möglich Darstllungsformn richn von inr rin grafischn Rpräsntation bis hin zu formaln, txtulln Bschribungn. Di IEEE dfinirt Softwararchitkturn wi folgt [3]: Architctur: Th fundamntal organization of a systm mbodid in its componnts, thir rlationships to ach othr and to th nvironmnt and th principls guiding its dsign and volution. Grau t al. [21] fassn vrschidn Dfinitionn zusammn als Komponntn und Konnktorn und Topologi ins Softwarsystms. Das Grundlmnt inr Softwararchitktur sind di darin nthaltndn Komponntn [19]. Dis binhaltn Vrhaltnsbschribungn blibigr Art, di auf dr Btrachtungsbn dr Softwararchitktur jdoch nicht von Rlvanz ist. Man spricht dahr auch von inr Blackbox, da dr intrn Aufbau inr Komponnt unbkannt ist. Komponntn wrdn in dr Litratur nicht inhitlich dfinirt [9]. Grau t al. [21] stlln di folgndn zwi Dfinitionn in dn Vordrgrund: A componnt is a non-trivial, narly indpndnt, and rplacabl part of a systm that fulfills a clar function in th contxt of a wll-dfind architctur. A componnt conforms to and provids th physical ralization of a st of intrfacs (Philipp Krutchn [9]). A componnt is a languag-nutral, indpndntly implmntd packag of softwar srvics, dlivrd in an ncapsulatd and rplacabl containr, accssd via on or mor publishd intrfacs. A componnt is not platform constraind or application bound (Kirby McInnis [37]). 28

47 3.1 Bschribungn von Softwararchitkturn C1 A C3 C5 C2 C4 Abbildung 3.1: Hirarchi in Softwararchitkturn Di bidn Dfinitionn wurdn aus zwi untrschidlichn Prspktivn formulirt. Krutchns Dfinition bschribt Komponntn aus Sicht ds Entwicklrs wohinggn McInnis si aus Sicht dr Nutzr dfinirt. Brown und Wallnau [9] hbn hrvor, dass di vrschidnn Dfinitionn, wlch sich in dr Litratur findn, durchaus in gminsams Konzpt bschribn. Mdvidovic und Taylor [39] sagn aus, dass s von großr Bdutung ist, kompositional Strukturn innrhalb dr Softwararchitktur zuzulassn. Es soll möglich sin, in Architktur auf untrschidlichn Ebnn zu btrachtn, bi dnn vrschidn Komponntn zu inr höhrn Entität zusammngfasst wrdn. Diss Hirarchikonzpt soll sich auf all Komponntn anwndn lassn und auch di Architktur slbst btrffn. In Abbildung 3.1 ist in Bispil für in Architktur mit hirarchischn Komponntn grafisch dargstllt. Di Architktur A in Abbildung 3.1 bstht aus zwi Hauptkomponntn, C1 und C2. Dis sind übr zwi Konnktorn mitinandr vrbundn. Währnd C1 in flach Komponnt ist, bstht C2 aus dn dri Subkomponntn C3, C4 und C5. Dis sind widrum untrinandr vrbundn, bsitzn slbst jdoch kin Untrkomponntn mhr. Dis Darstllung zigt, dass jd Komponnt slbst durch witr Subkomponntn gnaur spzifizirt wrdn kann. Aus dn vrschidnn vorgstlltn Ansätzn und Dfinitionn für Softwarkomponntn dr Litratur kann in informll Dfinition für in Softwarkomponnt abglitt wrdn. Dfinition (Softwarkomponnt). Ein Softwarkomponnt ist in ignständigr und austauschbarr Bstandtil ins Softwarsystms, dr inn klarn Zwck rfüllt. Si wird durch in intrns 29

48 3 Dlta-orintirt Modllirung von Softwararchitkturn Vrhaltn bschribn. Innrhalb inr Softwarkomponnt könnn witr Softwarkomponntn als Untrstrukturn bschribn wrdn, di durch in klar hirarchisch Bzihung mitinandr in Vrbindung sthn. Softwarkomponntn bsitzn in odr mhrr Schnittstlln, mit dnn si mit andrn Tiln ds Systms, innrn Komponntn odr dr Umwlt kommunizirn könnn. Mdvidovic und Taylor [39] konstatirn, dass di Größ von Komponntn von inr inzlnn Prozdur bis hin zu inm gsamtn Systm richn kann. Zusammn mit dm Ansatz dr Hirarchibnn innrhalb inr Komponnt führt dis zur Schlussfolgrung, dass di Architktur bnfalls in Komponnt ist, di sämtlich andrn Komponntn umfasst. Abbildung 3.1 untrstricht dis Aussag, da man sich vorstlln kann, dass di Architktur mit dr Umwlt bzw. andrn Systmn vrbundn ist und somit slbst auch in Komponnt darstlln könnt. Di Architktur kann dshalb auch als Wurzlkomponnt bzichnt wrdn, da si di Wurzl ds Hirarchibaums dr Komponntn ins Systms darstllt. Di Schnittstlln inr Komponnt wrdn durch Ports bschribn, di zur Kommunikation und Sturung mit andrn Komponntn bzw. dr Umgbung vrwndt wrdn. Garlan t al. bschribn Ports im Zusammnhang mit dr ACME ADL wi folgt [18]: Componnts intrfacs ar dfind by a st of ports. Each port idntifis a point of intraction btwn th componnt and its nvironmnt. Ports könnn Signal sndn und mpfangn und drn Inhalt für di Komponnt britstlln. Handlt s sich um inn Port inr hirarchischn Komponnt, dr Signal an Subkomponntn witrlitt, so bzichnt man disn als Dlgation Port [43]. Ports bsitzn inn Namn und in zugordnts Signal. Ein Port kann stts nur inn Signaltyp sndn odr mpfangn. Komponntn könnn blibig vil Schnittstlln durch vrschidn Ports britstlln, wobi dis durch indutig Namn diffrnzirbar sin müssn. Dfinition (Port). Ein Port ist in Kommunikationsschnittstll inr Softwarkomponnt. Er ist durch inn indutign Namn rfrnzirbar und dint dm Empfang odr dm Sndn ins Signals. Ein Port kann stts nur in Signal sndn odr mpfangn. Ports könnn als Til inr zusammngstztn Komponnt Signal mpfangn und an Subkomponntn witrlitn bzw. von disn mpfangn und nach Außn sndn. Von Ports mpfangn und gsndt Signal rpräsntirn das Kommunikationsmittl ds Systms und könnn vrschidn strukturirt sin. Signal bsitzn inn Namn und ihnn könnn Datntypn und Ports zugwisn wrdn. In andrn Darstllungn wird von Evnts gsprochn, di bi inr Komponnt auftrtn. Dfinition (Signal). Ein Signal ist in übr Ports ausgtauscht Informationsinhit ins Softwarsystms. Signal dinn als Kommunikations- und Sturungsmittl. Di übrtragnn Informationn bsitzn inn bstimmtn Datntyp und sind grichtt. 30

49 3.2 Softwararchitkturbschribungssprachn Ein Konnktor stllt di Vrbindung zwischn zwi Ports dar. Konnktorn bsthn aus zwi übr Ports mitinandr vrbundnn Komponntn, dn dazughörign Ports und dm darübr übrtragnn Signal. Garlan und Shaw bschribn Konnktorn wi folgt [19]: (...) a dscription of th intractions btwn ths componnts th connctors. Graphically spaking, this lads to a viw of an abstract architctural dscription as a graph in which th nods rprsnt th componnts and th arcs rprsnt th connctors. Konnktorn bildn das Bindglid zwischn dn inzlnn Komponntn und drn Umwlt. Si dinn als Kommunikationsmittl und führn zur Vrntzung dr inzlnn im Systm nthaltnn Komponntn, in dm si dis vrbindn und Kommunikation rmöglichn. Dfinition (Konnktor). Ein Konnktor ist in Vrbindung zwischn zwi Komponntn bzw. inr Komponnt und dr Umwlt. Er ist durch inn Namn indutig dfinirt. Konnktorn wrdn an jwils zwi Ports angstzt und übrtragn in zugtilts Signal. Konnktorn könnn laut Dfinition auch in und dislb Komponnt mitinandr vrbindn, d.h. in Schlif bildn. Diss Sznario ist zwar dnkbar, wird in disr Arbit jdoch nicht bachtt. Es wird davon ausggangn, dass Konnktorn stts zwi distinkt Komponntn mitinandr vrbindn. Dfinition (Softwararchitktur). Als Softwararchitktur bzichnt man di strukturll Komposition von Softwarkomponntn ins Softwarsystms. Nbn dr Topologi dr Komponntn wird auch drn Vrhaltn und Kommunikation untrinandr durch Konnktorn in inr Softwararchitktur bschribn. Ein Softwararchitktur kann hirarchisch sin, d.h. si kann slbst als Komponnt mit Subkomponntn bzichnt wrdn. Ein Softwararchitktur kann dahr auch als Wurzlkomponnt bzichnt wrdn. Um Softwararchitkturn modllirn zu könnn, wurdn u.a. Softwararchitkturbschribungssprachn ntwicklt, mit dnn di Topologi und das Vrhaltn von Softwararchitkturn txtull bschribn wrdn könnn. Im folgndn Kapitl wrdn dri ADLs vorgstllt. 3.2 Softwararchitkturbschribungssprachn Di txtull Rpräsntation von Softwararchitkturn kann durch dn Einsatz von Softwararchitkturbschribungssprachn bzw. Architctur Dscription Languags (ADL) rfolgn. Dis Sprachn dfinirn in Grammatik mit drn Hilf in Softwararchitktur und drn Bstandtil für in Softwarsystm bschribn wrdn könnn. Di Forschung hat vrschidn ADLs hrvorgbracht. Einig bkannt Sprachn und drn Anwndung solln im Folgndn kurz bschribn wrdn. 31

50 3 Dlta-orintirt Modllirung von Softwararchitkturn Darwin Bi Darwin [36] handlt s sich um in dklarativ ADL, d.h. si ist mit inr oprationlln Smantik vrshn. Dis basirt auf dm π-kalkül [40]. Darwin ignt sich zur Modllirung von vrtiltn und nbnläufign Systmn [47]. Architkturrpräsntationn könnn hirbi txtull odr grafisch rfolgn. Komponntn wrdn in Darwin durch Dinst bschribn, di si ntwdr anbitn könnn odr di si bnötign, um mit andrn Komponntn zu intragirn. Als Bispil ist di Komponnt filtr in Abbildung 3.2 in Darwin-Notation grafisch dargstllt (Bispil aus [36] ntnommn). Di Komponnt filtr stllt dn Dinst input filtr output Abbildung 3.2: Komponnt filtr in Darwin output zur Vrfügung und bnötigt dn Dinst input. Britgstllt Dinst wrdn durch inn ausgfülltn Kris dargstllt. Dinst, wlch von dr Komponnt bnötigt wrdn, sind in dr grafischn Rpräsntation durch inn lrn Kris gknnzichnt. Di txtull Rpräsntation dr glichn Komponnt siht in Darwin wi folgt aus: 1 componnt filtr { 2 provid output < stram char >; 3 rquir input < stram char >; 4 } Listing 3.1: Bispil inr Komponntndfinition in Darwin Dr Typ ds Dinsts wird in ckign Klammrn anggbn, r wär in dism Bispil dmnach in Stram von Symboln. Grundsätzlich könnn Komponntn blibig vil Dinst anfordrn und britstlln. Di anggbnn Namn dr Dinst sind lokal, d.h. di Komponnt muss nicht wissn, wo in xtrnr Dinst global dfinirt ist. Dis rmöglicht s, Komponntn unabhängig voninandr zu tstn. Mag t al. bzichnn dis als Kontxtunabhängigkit [36]. Einr dr Hauptaspkt von Darwin ist s, dn Architktn Composit Componnts, also zusammngstzt Komponntn, als Dsignmittl zur Vrfügung zu stlln. Dis führt zu hirarchisch strukturirtn Systmn. Zu dism Zwck vrwndt Darwin in dklarativ Notation. Zusammngstzt Komponntn dfinirn di untrgordntn Komponntn und drn Bzihung zuinandr. Als Bispil si di Komponnt piplin, wlch in Piplin blibigr Läng von filtr- Komponntn dfinirt, in Abbildung 3.3 dargstllt (Bispil ntnommn aus [36]). Txtull könnt piplin wi folgt in Darwin dfinirt sin: 32

51 3.2 Softwararchitkturbschribungssprachn piplin(n) input F[0] F[1] F[n-1] output Abbildung 3.3: Zusammngstzt Komponnt piplin in Darwin 1 componnt piplin ( i n t n) { 2 provid output ; 3 provid input ; 4 5 array F[n]: filtr ; 6 whn k < n -1; 7 bind F[k +1]. input -- F[k]. output ; 8 } 9 bind 10 F [0]. input -- input ; 11 output -- F[n -1]. output ; 12 } Listing 3.2: Zusammngstzt Komponntn in Darwin Di zusammngstzt Komponnt piplin bstht aus n filtr-komponntn, drn Inputs mit dm Output ds Nachfolgrs vrknüpft sind. Di Vrknüpfung findt durch in bind-mthod statt, di inputs outputs zuwist und umgkhrt. Di rst und ltzt filtr-komponnt wird zusätzlich an dn input und ouput von piplin vrbundn. Dis rmöglicht s Informationn auf vrschidnn Sichtbnn zu vrwaltn. Darwin prüft bi Vrknüpfungn immr, dass di mitinandr vrbundnn Dinst dn glichn Typ vrwndn, um Kompatibilitätsproblmn vorzubugn Rapid Di ADL Rapid [35] wurd an dr Stanford Univrsity ntwicklt. Es handlt sich um in vnt-gsturt, objkt-orintirt Sprach, drn Fokus auf dm Prototyping vrtiltr und nbnläufigr Systm ligt [35, 47]. Rapid rmöglicht di Simulation und Vrhaltnsanalys von Architkturn zu inm frühn Zitpunkt innrhalb ds Entwicklungsprozsss ins Softwarsystms. Rapid bstht aus fünf Hauptbstandtiln [35]: Typnsprach: In dr Typnsprach wrdn di Komponntnschnittstlln 33

52 3 Dlta-orintirt Modllirung von Softwararchitkturn dfinirt. Si untrstützt objkt-orintirt sowi abstrakt Datntypn. Auch Vrrbung zwischn altn und nun Intrfacs ist möglich. Architktursprach: Di Architktur bschribt in Mng von Komponntn und in Mng von Vrbindungn zwischn Komponntnschnittstlln. Di Architktur wird in Rapid durch in ign Syntax dargstllt. Ein Bispil (ntnommn aus [35]) könnt wi folgt ausshn: 1 architctur_dclaration ::= 2 a r c h i t c t u r idntifir ( [ paramatr_list ] ) 3 [ rturn intrfac_xprssion ] is 4 [ modul_sonstunt_list ] 5 [ connct { connction } ] 6 nd [ a r c h i t c t u r ] [ idntifir ] ; 7 8 connction ::= 9 basic_pattrn to basic_pattrn ; 10 andr Artn von pattrn connctions... Listing 3.3: Bispil inr Komponnt in Rapid Ausführungssprach: Di Ausführungssprach stllt nbnläufig, raktiv Programmirkonstrukt brit, mit dnn Modul gschribn wrdn könnn. Ein Modul wird durch in Mng von vnt-übrwachndn Prozssn dfinirt und ragirt auf Evnts durch di Ausführung blibign Cods. Modul stlln das gnrll Konstrukt zur Kapslung dr Komponntnimplmntirungn dar. Modul könnn di Größ infachr Datntypn bis hin zu Subsystmn bsitzn. Pattrn-Sprach: Di Pattrn-Sprach vrwndt vnt pattrns. Pattrns könnn durch in ign Syntax dfinirt wrdn (Sih [35]). Ein infachs Pattrn wär z.b. dr Nam inr Aktion mit optionaln Paramtrassoziationn. Bispilwis wird das Pattrn Snd(a) mit snd-evnts vrknüpft, di dn Paramtr a rhaltn. Pattrns könnn durch logisch Opratorn vrbundn wrdn. Spzifikationssprach: In dr Spzifikationssprach wird in Kombination von algbraischn Constraints und pattrn constraints ingstzt. Constraints könnn ntwdr in Intrfacs odr in Architkturn platzirt wrdn. Dis Constraints könnn auf Paramtrwrtn odr Evnts angwndt wrdn. Im Folgndn si in Bispil für inn Intrfac Constraint ggbn. Disr gibt an, dass all inghndn Nachrichtn mit dn glichn Paramtrn in in Rsult-Mng aufgnommn wrdn. 1 typ Rsourc is intrfac 2 public action Rciv ( Msg : String ); 34

53 3.2 Softwararchitkturbschribungssprachn 3 xtrn action Rsults ( Msg : String ); 4 constraint 5 match 6 ((? S i n String ) 7 ( Rciv (?S) -> Rsults (?S )))^(*~); 8 nd Rsourc ; Listing 3.4: Bispil ins Constraints in Rapid Wright Di ADL Wright wurd von Robrt Alln ntwicklt, um di Spzifikation und Analys von Softwararchitkturn zu rmöglichn [7]. Di Spzifikation inr Softwararchitktur mit Wright basirt auf dm Ansatz, Bzihungn zwischn Komponntn als Protokoll zu spzifizirn. Dis Protokoll bschribn di Art dr Komponntnintraktion. Ein Bispil für in mit Wright spzifizirts Systm ist in Listing 3.5 dargstllt (Bispil ntnommn aus [7]). 1 Systm Capitaliz 2 Componnt Split 3 p o r t In [ input protocol ] 4 p o r t Lft, Right [ output protocol ] 5 comp spc [ Split spcification ] 6 Componnt Uppr 7 p o r t In [ input protocol ] 8 p o r t Out [ output protocol ] 9 scomp spc [ Uppr spcification ] 10 Connctor Pip 11 [ Pip spcification ] 12 Instancs 13 split : Split ; uppr : Uppr ; 14 lowr : Lowr ; mrg : Mrg ; 15 p1,p2,p3,p4: Pip 16 Attachmnts 17 split. Lft as p1. Writr ; 18 uppr.in as p1. Radr ; 19 split. Right as p2. Writr ; 20 lowr.in as p2. Radr ; nd Capitaliz. Listing 3.5: Bispilsystm in Wright Di Dfinition ds Systms wird in zwi Tiln bschribn. Zunächst wrdn di Komponntn sowi Konnktorn konfigurirt. Dazu wrdn di Intrfacs dr Komponntn anggbn sowi di dr Protokoll, di Konnktorklassn rpräsntirn. 35

54 3 Dlta-orintirt Modllirung von Softwararchitkturn Im Bispil aus Listing 3.5 wrdn zwi Komponntnintrfacs Split und Uppr sowi dr Konnktortyp Pip dfinirt. Anschlißnd wird di Systmkonfiguration durch Klassninstanzn dfinirt. Im Bispil gibt s vir Komponntninstanzn von jwils vir vrschidnn Intrfacs und zusätzlich vir Konnktorinstanzn vom Typ Pip. Di Topologi dr Softwararchitktur wird durch in List von Attachmnts bschribn, wlch di Konnktorn mit dn Komponntn vrbindn. In Wright wrdn Komponntnschnittstlln durch in Sammlung von Ports dargstllt. Ports stlln hirbi Intraktionspunkt ds Systms dar. Zusätzlich könnn Intraktionn als Til inr Brchnung kombinirt wrdn. Konnktorn wrdn durch in Mng von Rgln und inr glu-spzifikation dfinirt. Rolln bschribn das rwartt lokal Vrhaltn dr btiligtn Partin. Di glu-spzifikation lgt fst, wi di Aktivitätn dr inzlnn Rolln koordinirt wrdn. Di Architktur ds Gsamtsystms wird durch in Konfiguration bschribn. Dabi handlt s sich um in Kombination von Komponntninstanzn und Konnktorn als Vrbindung zwischn Komponntn. Wright untrstützt auch hirarchisch Architkturn. Auf Basis dr in Kapitl 3.1 bschribnn Softwararchitkturn und dn in dism Kapitl vorgstlltn ADLs wrdn im folgndn Abschnitt Softwararchitkturn formal dfinirt und auf Basis disr Formalismn in dlta-orintirt Modllirungstchnik für Softwararchitkturn bschribn. 3.3 Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik In Kapitl 3.1 wurdn Softwararchitkturn brits informll bschribn und auf drn Bstandtil sowi di Zusammnhäng disr inggangn. Im folgndn Abschnitt solln dis nun formal dfinirt wrdn. Es wrdn zunächst hirarchisch Softwararchitkturn dfinirt. Anschlißnd wird di Eignschaft dr Variabilität durch di formal Einführung von Dltas intgrirt, um di Grundlag für in dltaorintirt Softwararchitkturbschribungssprach zu lgn Formal Dfinition inr Softwararchitktur Dr lmntar Bstandtil inr Softwararchitktur sind Softwarkomponntn. In Kapitl 3.1 wurd fstgstllt, dass Softwarkomponntn durch vrbindnd Konnktorn mit andrn Komponntn odr dr Umwlt kommunizirn könnn. Witrhin könnn Softwarkomponntn in dr hir vrwndtn Auffassung inr Softwararchitktur hirarchisch strukturirt sin, d.h. si könnn Subkomponntn bsitzn, di widrum di Eignschaftn inr Komponnt aufwisn. Dis rmöglicht s vrschidn Sichtn auf das Systm zu habn und auf vrschidnn Ebnn zu abstrahirn. Softwarkomponntn bsitzn witrhin in Mng von Signaln. Dis könnn zur Kommunikation mit andrn Komponntn odr dr Umwlt gnutzt. Hirfür wird für in Komponnt in Mng von Konnktorn dfinirt, di dis Signal übrtragn könnn. Jdr Konnktor kann stts nur in Signal nutzn. Di 36

55 3.3 Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik Konnktorn, di von inr Softwarkomponnt dfinirt wrdn, lign innrhalb disr Komponntn und vrbindn drn Subkomponntn untrinandr odr Subkomponntn mit dr Komponntn slbst, um Signal von Außn zu mpfangn odr nach Außn zu sndn. Dfinition (Hirarchisch Softwarkomponnt (formal)). Ein Softwarkomponnt ist in Tripl sc = (C, Π, Σ), wobi C in ndlich Mng von Subkomponntn, Π in ndlich Mng von Signaln und Σ in Mng von Konnktorn ist. Ein hirarchisch Softwarkomponnt (ab sofort als Softwarkomponnt bzichnt) bstht aus inr Mng von Signaln, inr Mng von Subkomponntn und inr Mng von Konnktorn. Wnn s sich um in Basiskomponnt sc bas handlt, di kin Subkomponntn bsitzt, also in Blatt ds Hirarchibaums dr Softwarkomponntn darstllt, dann gilt sc bas = (C, Π, Σ) mit C = und Σ =. Dis Komponntn bsitzn kin Subkomponntn und Konnktorn. Di Gsamthit allr Softwarkomponntn inr Softwararchitktur wird mit SC bzichnt. Dfinition (SC). SC = {sc 1,, sc n } ist di Mng allr Softwarkomponntn ins Softwarsystms. Für di Subkomponntn inr Softwarkomponnt gilt sc C : sc SC. Jd Softwarkomponnt vrfügt übr in Mng Π von Signaln. Signal bsitzn inn Namn und inn Typ. Di Signal inr Komponnt sind auch ihrn Subkomponntn bkannt. Dfinition (Signal (formal)). Ein Signal ist in gordnts Paar sig = (N, T ), wobi N dr Nam ist und T dr Typ dr Signals ist. Dr Typ T ist dfinirt durch: T = boolan intgr doubl char Di rlaubtn Typn ins Signals wrdn auf di vir Möglichkitn boolan, intgr, doubl und char rstriktirt, wobi dis smantisch dn aus dr Programmirung bkanntn, glichnamign, lmntarn Datntypn ntsprchn. Di Mng allr Signal innrhalb inr Softwararchitktur wird mit SIG bzichnt. Di Signal Π dr Wurzlkomponnt sind alln Subkomponntn bkannt. Si müssn dis jdoch nicht vrwndn und in ihrr Mng dr Signal aufnhmn. 37

56 3 Dlta-orintirt Modllirung von Softwararchitkturn Nu Signal wrdn in dr Softwararchitktur stts auf dr höchstn Hirarchibn ingfügt. Es lässt sich argumntirn, dass Signal auch in Komponntn und Subkomponntn ingfügt wrdn könntn, di anschlißnd in di Signalmng Π dr Architktur aufgnommn wrdn. In disr Arbit wrdn Signal global dfinirt und sind so von jdr Komponnt inr Architktur vrwndbar. Ein Subkomponnt darf kin Signal vrwndn, di dr nächsthöhrn Softwarkomponnt unbkannt sind. Dfinition (SIG). SIG = {sig 1,, sig n } ist di Mng allr Signal ins Softwarsystms. Für Signal inr Softwarkomponnt gilt sig Π : sig SIG. Konnktorn wurdn in Kapitl 3.1 als Kommunikationsinhit inr Softwararchitktur vorgstllt. Si vrknüpfn zwi Komponntn dr Architktur mitinandr und rlaubn somit in Kommunikation zwischn disn. Konnktorn könnn auch di Architktur mit dr Umwlt vrbindn, um somit Signal aus dr Umwlt zu Empfangn (Snsorik) und in dis zu Sndn (Aktorik). Dfinition (Konnktor (formal)). Ein Konnktor ist in 5-Tupl con = (N, c S, s S, s T, c T ), wobi N dr Nam, c S di Sourc-Komponnt, s S das Sourc-Signal, s T das Targt-Signal und c T di Targt-Komponnt ist. Mit s C wrdn Signal notirt, di von dr Komponnt C akzptirt, also gsndt odr mpfangn, wrdn. In disr Arbit wird angnommn, dass s kin Konnktorschlifn gibt, d.h. in Konnktor vrbindt stts zwi untrschidlich Komponntn mitinandr, so dass di Sourc- und Targt-Komponnt vrschidn sind. Es gilt: c S, c T SC und c c und s S Π CS und s T Π CT Für Konnktorn könnn in Bzug auf di Umwlt dri vrschidn Konfigurationn anggbnn wrdn [34]. Dfinition (Konnktorkonfiguration). Für jdn Konnktor con Σ inr Softwarkomponnt sc = (C, Π, Σ) gilt in dr dri folgndn Konfigurationn: 1. Wnn con = (c, sig o, sig i, c ) mit c, c = sc, dann ist con in intrnr Konnktor 2. Wnn con = (E, sig o, sig i, c ) mit c = sc, dann ist con in Inputkonnktor 38

57 3.3 Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik 3. Wnn con = (c, sig o, sig i, E) mit c = sc, dann ist con in Outputkonnktor Mit E wird in Umwltinstanz angnommn, di all Signal dr Softwararchitktur knnt und mit dr Komponntn inr Softwararchitktur intragirn kann. Di formal Dfinition inr Softwarkomponnt lässt sich auf dn Bgriff dr Softwararchitktur anwndn, da in Kapitl 3.1 fstgstllt wurd, dass sich di Hirarchiignschaft inr Softwararchitktur auf alln Ebnn anwndn lässt, d.h. man kann di Softwararchitktur slbst als Wurzlkomponnt auffassn, di all andrn Komponntn und Konnktorn umfasst. Dfinition (Softwararchitktur). Ein Softwararchitktur a ntspricht inr hirarchischn Softwarkomponnt sc, so dass gilt: a = sc = (C, Π, Σ) Di in Kapitl 3.1 bschribnn Ports wrdn für dis Arbit nicht formal ingführt, da das vrwndt Konzpt inr Softwararchitktur ohn Ports auskommn soll. Konzptionll stlln Ports di Schnittstlln dr Komponntn dar, übr di Konnktorn Signal austauschn könnn. Wnn in Konnktor mit inr Komponnt vrbundn wird, so gschiht dis dmnach übr inn ntsprchndn Port (vgl. Kapitl 3.4). In disr Arbit wird auf Ports vrzichtt, da di Signal und Komponntnschnittstlln indirkt übr di Konnktorn dfinirt wrdn. Wird also in Konnktor zwischn zwi Komponntn ohn di Angab dr Ports rzugt, vrwndt disr di ntsprchndn Schnittstlln dr Komponnt trotzdm. Si müssn jdoch nicht xplizit anggbn wrdn, um dn Modllirungsprozss zu vrinfachn. Auf Basis dr vorgstlltn formaln Dfinitionn für Softwararchitkturn und drn Bstandtil wird im folgndn Abschnitt Variabilität ingführt, um di Architkturmodll für Softwarproduktlinin gnrirn zu könnn Variabilität in Softwararchitkturn Di bishrign Dfinitionn bzihn sich auf inzln Softwarsystm. Es soll nun gzigt wrdn, wi dis um di Eignschaft dr Variabilität rwitrt wrdn könnn. Variabilität ist in gfordrt Eignschaft, da dis Arbit im Kontxt dr Softwarproduktlinin konzipirt wird. Galstr und Avgriou [17] shn in groß Bdutung für di Entwicklung gigntr Mthodn und Wrkzug, mit dnn Architktn Variabilität auf Softwararchitkturbn instzn könnn. Glichzitig stlln si jdoch auch fst, dass s drzit kinn inhitlichn Lösungsansatz für dis Problmstllung gibt. Stattdssn wird Variabilität hauptsächlich durch Fatur-Modll und Produktkonfigurationn rpräsntirt. In disr Arbit wird dr Ansatz dr dlta-orintirtn Modllirung gwählt, um Variabilität auf Ebn dr Softwararchitkturn untrstützn zu könnn. Dabi wrdn, wi brits in Kapitl bschribn, Dltas dfinirt, di Transformationn 39

58 3 Dlta-orintirt Modllirung von Softwararchitkturn auf inm Krnprodukt durchführn. Im folgndn Abschnitt wrdn Dltas für Softwararchitkturn dfinirt. Dfinition von Dltas auf Softwararchitkturn Um di Variabilität inr SPL auf di Ebn dr Softwararchitkturn zu übrtragn, wird in disr Arbit dr dlta-orintirt Modllirungsansatz von Schafr t al. gwählt [51]. Disr bschribt di Möglichkit dr Widrvrwndung von Artfaktn durch Dltas. Ein Dlta umfasst in Mng von Transformationn, di auf inm Krnprodukt angwandt wrdn. Di Konfiguration ds Krns kann inr blibign Faturkonfiguration ntsprchn. In disr Arbit ntspräch in Krnprodukt inr Softwararchitktur, drn Komponntn inm odr mhrrn Faturs zugordnt wrdn könnn. Um fstzulgn, wi Variabilität auf Softwararchitkturbn durch Dltas vrwndt wrdn kann, muss zunächst di Mng allr Faturs, di in SPL umschlißt, rfasst wrdn. Dfinition (F SPL ). F SPL = {f 1,, f n } ist di Mng allr Faturs inr Softwarproduktlini. Dltas dfinirn in Mng von Transformationn, di auf in Softwararchitktur angwandt wrdn. Im Ggnsatz zu dn von Schafr t al. [51] vorgstlltn add, rmov und modify-oprationn wrdn in disr Arbit nur Variantn dr add und rmov-transformationn vrwndt. Modifizirungn sind dmnach nur durch das Entfrnn bsthndr Elmnt und Hinzufügn inr ntsprchnd gändrtn Variant disr möglich. Auf Ebn dr Softwararchitktur kann in add-opration Komponntn, Konnktorn odr Signal hinzufügn. Bim Hinzufügn nur Elmnt ist s grundsätzlich notwndig, dis mit inm indutign, nicht brits vrwndtn Bzichnr zu dfinirn. Nbn dm Hinzufügn ist auch das Entfrnn von Komponntn, Konnktorn und Signaln durch rmov-oprationn möglich. Damit das Ergbnis dr vrwndtn Transformationn stts valid ist, könnn bstimmt Dltas durch di Angab inr aftr-bdingung so dfinirt wrdn, dass zunächst in Mng von andrn Dltas ausgführt wrdn muss. So kann in Konsistnz dr Transformationn sichrgstllt wrdn. Um fstzulgn, wlchs Dlta angwndt wrdn muss, wird für jds Dlta in Application Condition dfinirt, di angibt, für wlch Faturkonfiguration das Dlta gültig ist. Dis Bdingung ntspricht inm bool schn Ausdruck, dr für in bstimmt Faturkonfiguration dn Wahrhitsghalt wahr rhält. In dism Fall wird das Dlta untr Brücksichtigung sinr aftr-bdingung angwndt. Sowohl di aftr-bdingung als auch di Application Condition wrdn im Abschnitt Eignschaftn und Sitnbdingungn von Dltas diss Kapitls dtaillirt bschribn. Dfinition (Dlta (formal)). Ein Dlta ist in 5-Tupl δ = (N, Φ, aftr, T A, sc) wobi 40

59 3.3 Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik N dr Nam ds Dltas ist, Φ in bool schr Ausdruck übr F SPL ( Application Condition) ist, aftr FSP L FSP L in Ordnungsrlation auf dr ndlichn Mng FSP L dr dfinirtn Dltas ist, T A = {to 1,, to n } in ndlich Mng von Transformationsoprationn auf inr Softwararchitktur sc SC ist und sc in Softwarkomponnt ist, auf dr das Dlta angwandt wrdn soll. Di Transformationsopration to i ist dfinirt durch: to i := add componnt add connctor add signal add subcomponnt rmov componnt rmov connctor rmov signal rmov subcomponnt Das Prinzip soll am Bispil von Abbildung 3.4 gzigt wrdn. Di Grafik zigt in Softwararchitktur, di inm gültign Produkt dr SPL dr Fallstudi ntspricht (vgl. Abbildung 2.3). Di Faturkonfiguration dr Krnarchitktur stzt sich aus dn folgndn Faturs zusammn: Body Comfort Systm, Door Systm, Human Machin Intrfac, Manual Powr Window, Fingr Protction und Extrior Mirror. Di gwähltn Faturs sind all mandatory, d.h. si müssn ausgwählt wrdn. Bi dm Manual Powr Window muss angmrkt wrdn, dass s sich hir um in Altrnativ zu Automatic Powr Window handlt. Es muss also immr gnau ins disr bidn Faturs gwählt wrdn. Aus dn Faturs dr Porduktkonfiguration lassn sich di Komponntn dr dazughörign Architkturn ablitn. Für das Krnprodukt rgbn sich di vir Komponntn Human Machin Intrfac (HMI), Manual Powr Window (ManPW), Fingr Protction (FP) und Extrior Mirror. Dis Konfiguration soll für das Bispil als Krnprodukt gltn. Si bildt damit dn Ansatzpunkt für di Gnrirung witrr Produkt durch Dltas, di auf di Architktur ds Krnprodukts angwndt wrdn. Im Bispil aus Abbildung 3.4 wird zur Faturkonfiguration ds Krns zusätzlich das Fatur LED fingr protction ausgwählt. Dis führt auf Ebn dr Softwararchitktur zum Hinzufügn inr nun Komponntn LED Fingr Protction sowi ntsprchndn Signaln und Konnktorn, di di Funktionalität ds Faturs britstlln. Im zwitn Abschnitt von Abbildung 3.4 ist di rsultirnd Softwararchitktur zu shn, di di Funktionalität ds Faturs LED Fingr Protction nthält. Darin ist di Komponnt mit LED_FP gknnzichnt. Di Komponnt bsitzt zwi Inputkonnktorn aus dr Komponnt FP und zwi Outputkonnktorn in di Umwlt. Um di Architktur ds nun Produkts zu gnrirn, müssn in odr mhrr Dltas dfinirt wrdn, di für di ausgwähltn Faturs angwandt wrdn. Für das Bispil wird das Dlta LFP dfinirt, das angwndt wrdn soll, wnn das Fatur LED Fingr Protction für di Produktkonfiguration ausgwählt wurd. In Abbildung 3.5 ist di Struktur ds Dltas dargstllt. 41

60 3 Dlta-orintirt Modllirung von Softwararchitkturn m_mv_up m_mv_down m_mv_lft pw_but_mv_dn m_but_right m_pos_lft m_pos_right EM m_mv_right pw_but_mv_up m_but_down m_pos_top m_but_mv_lft m_but_mv_right m_but_mv_up HMI m_but_up m_but_lft m_pos_bottom m_but_mv_dn rlas_pw_but_up rlas_pw_but_dn pw_but_up pw_but_dn pw_pos_up pw_pos_dn ManPW pw_mv_up pw_mv_dn Krnprodukt fingr_dtctd FP fp_on fp_off Hinzufügn dr Funktionalität LED fingr protction m_mv_up m_mv_down m_mv_lft pw_but_mv_dn m_but_right m_pos_lft m_pos_right EM m_mv_right pw_but_mv_up m_but_down m_pos_top m_but_mv_lft m_but_mv_right m_but_mv_up HMI m_but_up m_but_lft m_pos_bottom m_but_mv_dn rlas_pw_but_up rlas_pw_but_dn pw_but_up pw_but_dn pw_pos_up pw_pos_dn ManPW pw_mv_up pw_mv_dn Krnprodukt + Dlta LFP fingr_dtctd FP fp_on fp_off LED_FP ld_fp_on ld_fp_off Abbildung 3.4: Bispil inr Dlta-Anwndung auf Softwararchitkturn - Architkturbn Das Dlta LFP bschribt, wlch Transformationn auf dr Softwararchitktur ds Krnprodukts durchgführt wrdn müssn, damit das Ergbnis in Produktarchitktur mit dr Funktionalität inr ntsprchndn Faturkonfiguration rpräsntirt. Im konkrtn Fall bdutt dis, dass zunächst dr Nam und di Application Condition (whn LED Fingr Protction) ds Dltas anggbn wrdn. Im Rumpf ds Dltas wrdn dann di konkrtn Transformationn dfinirt. Als Ersts wird das Hinzufügn inr nun Komponnt namns LED_FP fstglgt. Dis bsitzt zu dism Zitpunkt noch kin Eignschaftn außr dm Namn. Um in Vrntzung dr Komponnt mit dn brits bsthndn Systmtiln zu rzugn, müssn 42

61 3.3 Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik Dlta LFP whn LED Fingr Protction add componnt LED_FP add signal ld_fp_on add signal ld_fp_off add connctor (c1,fp,fp_on,fp_on,led_fp) add connctor (c2,fp,fp_off,fp_off,led_fp) Abbildung 3.5: Bschribung von Dlta LFP zunächst di vrwndtn Signal ld_fp_on und ld_fp_off dfinirt wrdn. Anschlißnd könnn dis von dn zwi Konnktorn c1 und c2 vrwndt wrdn. Si vrknüpfn di Komponnt FP mit LED_FP und lgn fst, wlch Signal in wlch Richtung übrtragn wrdn, wobi c1 das Signal fp_on und c2 das Signal fp_off übrträgt. Di Richtungsanwisung rfolgt durch di Rihnfolg dr Komponntn. Di link Komponnt in dr Konnktordfinition ist di Sourc-Komponnt, di rcht ist di Targt-Komponnt. Im Bispil wär FP für bid Konnktorn di Sourc-Komponnt und LED_FP di Targt-Komponnt. Das Dlta slbst bsitzt kin Angab, wo in dr Architktur di Komponnt und Konnktorn hinzugfügt wrdn solln. Im Bispil wurd klar, dass di Komponnt kin Subkomponnt ist. Es muss also kin Suprkomponnt anggbn wrdn. In dr Arbit wird ab sofort angnommn, dass in Dlta, wlchs kin Angab übr dn Anwndungsort bsitzt, auf dr höchstn Hirarchibn dr Softwararchitktur angwandt wird. In dism Fall würd das Dlta LFP also auf Ebn angwandt wrdn, auf dr di andrn Komponntn dr Krnarchitktur brits dfinirt wurdn (vgl. Abbildung 3.4). Eignschaftn und Sitnbdingungn von Dltas Damit di Anwndung von Dltas zu validn Produktn führt, müssn bstimmt Sitnbdingungn und Eignschaftn von Dltas bachtt wrdn. Elmnt könnn nur ntfrnt wrdn, wnn si zuvor brits xistirtn. Analog dazu dürfn nu Elmnt nur hinzugfügt wrdn, wnn si nicht brits zuvor hinzugfügt wurdn. Das Hinzufügn von Komponntn kann durch di hirarchisch Struktur dr Softwararchitkturn auch innrhalb andrr Komponntn rfolgn. Wird kin Vatrkomponntn anggbn, so wird angnommn, dass di Komponnt auf dr höchstn Ebn dr Softwararchitktur ingfügt wrdn soll. Es gilt zu bachtn, dass in Kapitl 3.1 in Softwararchitktur bnfalls als Komponnt dfinirt wurd. Um in Übrsichtlichkit zu bwahrn, wird jdoch witrhin von dr Softwararchitktur im Sinn ds Gsamtsystms gsprochn. Wird in Konnktor hinzugfügt, kann dis nur zwischn brits xistirndn 43

62 3 Dlta-orintirt Modllirung von Softwararchitkturn Komponntn gschhn. Di in inm nun Konnktor angsprochnn Ports wrdn auf zwi untrschidlich Wisn bhandlt. Existirn di Ports, so wird übrprüft, ob das vom Konnktor übrtragn Signal dm dr vrwndtn Ports ntspricht. Es ist auch möglich, Ports innrhalb ds Konnktors zu vrwndn, di noch nicht xistirn. Dann wrdn di ntsprchndn Ports automatisch mit dm Hinzufügn ds nun Konnktors an dn ntsprchndn Komponntn hinzugfügt. Konnktorn könnn bdingt durch di Hirarchi ds Systms auch innrhalb inr Komponnt dfinirt wrdn. Si vrbindn dann di Ports von Subkomponntn. Nu Signal dürfn nicht mit brits xistirndn Signaln kollidirn und müssn inn Typ bsitzn. Di gstatttn Typn wrdn im Dsignprozss fstglgt. In disr Arbit wrdn di folgndn primitivn Datntypn für Signal untrstützt: intgr, doubl, char und boolan. Ein hinzugfügts Signal muss nicht zwingnd von inm Port gsndt bzw. mpfangn wrdn. So könnn anglgt Signal z.b. auch rst zu inm spätrn Zitpunkt durch inn nu hinzugfügtn Konnktor vrwndt wrdn. Wird in inzlnr Port im Systm hinzugfügt, so muss di Komponnt, dr r hinzugfügt wrdn soll, zuvor brits anglgt wordn sin. Für di korrkt Anwndung von Dltas müssn witrhin di folgndn Eignschaftn gltn [49]: Di Mng dr Dltas, wlch slktirt wurdn, muss sortirt sin. Di sortirt Mng muss auf in Softwararchitktur anwndbar sin. Di ausgwählt, sortirt und anwndbar Mng muss konfliktfri sin. Dis gilt auch für di Hirarchibzihung. Wird in Sitnbdingung ins Dltas vrltzt, würd dis zu inm ungültign Produkt führn. Dahr wrdn sämtlich zuvor angwandt Transformationn bzw. Dltas vrworfn und das Ausgangsprodukt widrhrgstllt. Witr Dltas odr Transformationn, di noch angwndt wrdn solltn, wrdn bnfalls vrworfn. Damit di Rihnfolg von Dltas inghaltn wird, muss für in Faturkonfiguration F di Mng F = ( 1,, n ) FSP L von ausgwähltn Dltas sortirt sin, d.h. all Dltas dr Mng sind linar gordnt und ihr aftr-bdingung wird inghaltn. Di Ordnungsrlation aftr dfinirt di linar Ordnung, da ( FSP L, aftr) in gordnt Mng ist [30]. Für di Tilmngn von FSP L gilt dis bnfalls. Jds Dlta δ i F muss zusätzlich anwndbar sin, d.h. kin sinr Sitnignschaftn dürfn vrltzt wrdn. Zultzt muss sichrgstllt wrdn, dass di sortirt, anwndbar Mng konfliktfri ist, d.h. si muss zu inm indutign Ergbnis führn. Um gwährlistn zu könnn, dass nur Dltas zur Gnrirung ins Produkts angwandt wrdn, di Transformationn diss Produkts bschribn, bsitzn Dltas in Application Condition. Dis gibt für jds Dlta an, bi wlchr Faturkonfiguration s angwndt wird, d.h. s gibt in Vrknüpfung zwischn dn gwähltn 44

63 3.3 Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik Faturs ds Fatur-Modlls dr SPL sowi dn daraus rsultirndn Softwararchitkturn. Application Conditions wrdn in Form ins bool schn Ausdrucks dfinirt und bsitzn somit inn Wahrhitswrt, dr ntwdr wahr odr falsch ist. Dis gstattt di Vrknüpfung aussagnlogischr Trm durch Vrknüpfung (und) und Ngation (nicht). Ein Bispil für in Application Condition für das Fatur-Modll dr Fallstudi (Vgl. Kapitl 2.1.2) ist in Listing 3.6 ggbn. 1 Human Machin Intrfac 2 AND Manual Powr Window 3 AND NOT hatabl Listing 3.6: Valid Application Condition Dis Application Condition wär immr dann wahr, wnn di Faturs Human Machin Intrfac und Powr Window in inr Konfiguration nthaltn sind und das Fatur hating ds Extrior Mirrors nicht ausgwählt wurd. Bi Application Conditions sollt im Dsignprozss darauf gachtt wrdn, ausschlißlich rlaubt Konfigurationn dr SPL zuzulassn, da andr Konfigurationn zu nicht validn Transformationn dr Softwararchitkturn führn würdn. Validität bziht sich hirbi auf di Dfinition ds Fatur-Modlls, wlchs bschribt, ob und wlch Faturs andr Faturs vorausstzn odr ausschlißn. Ein invalid Auswahl von Faturs hätt in Rih von Produktn als Ergbnis, di kinr gültign Faturkonfiguration ntsprächn. In Listing 3.7 wird in Bispil für in invalid Application Condition ggbn. 1 Automatic Powr Window 2 AND Manual Powr Window Listing 3.7: Invalid Application Condition Dis Application Condition rfordrt di Auswahl dr Faturs Automatic Powr Window und Manual Powr Window. Btracht man hinggn das dazughörig Fatur-Modll, so wird klar, dass dis bidn Faturs in inr Altrnativ-Bzihung zuinandr sthn, d.h. si schlißn sich ggnsitig aus und s muss gnau ins dr bidn Faturs, jdoch nimals bid zuglich, ausgwählt wrdn. Di Application Condition würd dahr nimals dn Wahrhitsghalt wahr rhaltn, was dazu führt, das in Dlta, dass dis Application Condition bsäß, nimals ausgwählt wrdn würd. Wär dis doch dr Fall, würd s bdutn, dass in ungültig Faturkonfiguration gwählt wurd. Das Ergbnis wär in Produkt, dass nicht dn Bdingungn ds Fatur-Modlls ntspräch. Damit di Mng dr slktirtn Dltas sortirt ist, um Sitnffkt abzufangn, könnn Dltas in aftr-bdingung bsitzn, di angibt, wlch Transformationn bzw. Dltas vor inm Dlta ausgführt wrdn müssn, damit diss angwandt wrdn kann [48]. Durch di anggbn Rihnfolg soll in Konsistnz dr Transformationn gwährlistt wrdn, d.h. Transformationn solln stts Oprationn durchführn, drn Ergbnis in valid Softwararchitktur ist. Analog zu dn add- 45

64 3 Dlta-orintirt Modllirung von Softwararchitkturn Oprationn könnn rmov-oprationn bnfalls auf Komponntn, Konnktorn, Signaln und Ports durchgführt wrdn. Di Vorausstzung allr Entfrnungn ist das Vorhandnsin ds zu ntfrnndn Objkts. Dis muss durch di ntsprchnd Rihnfolg dr Anwndungn dfinirt wrdn. Um in Komponnt zu ntfrnn, müssn zuvor sämtlich Konnktorn, di dis Komponnt mit andrn Komponntn vrbundn habn, ntfrnt wrdn. Witrhin müssn all Subkomponntn ntfrnt wordn sin. Für dis gltn di glich Bdingungn. Erst wnn di Komponnt nicht mhr mit dm rstlichn Systm in Vrbindung stht und kin Subkomponntn mhr aufwist, darf si ntfrnt wrdn. Di von dr Komponnt dfinirtn Schnittstlln wrdn dabi mit ntfrnt. Das Entfrnn ins Konnktors btrifft nicht di vrbundnn Ports odr das Signal, d.h. dis xistirn witrhin und müssn ntwdr durch ntsprchnd Transformationn ntfrnt odr könnn für nu Konnktorn vrwndt wrdn. Di Löschung ins Signals bdingt, dass diss von kinm Konnktor mhr übrtragn wird. Ports, di das Signal mpfangn bzw. sndn, müssn durch das Entfrnn ds Signals auf signallos gstzt wrdn. Soll in Port ntfrnt wrdn, so darf r mit kinm Konnktor vrbundn sin. Di Komponnt blibt nach Entfrnn ins Ports bsthn. Dltaanwndung Für jds Produkt dr Softwarproduktlini kann in Produktkonfiguration dfinirt wrdn. Di Produktkonfiguration binhaltt das Krnprodukt, in valid Faturkonfiguration, di di vrwndtn Faturs dr SPL und di Komposition dr Softwararchitktur bschribt sowi in konfliktfri, anwndbar Mng von Dltas. Dfinition (Produktkonfiguration). Ein Produktkonfiguration ist in Tripl pc = (a, F, F ), wobi a = (C, Π, Σ) in Krnarchitktur, F F SP L in valid Faturkonfiguration und F = ( 1,, n ) in sortirt, anwndbar und konfliktfri Mng von Dltas auf F ist. Di von dn Dltas durchführbarn Transformationn sind das Hinzufügn und Entfrnn von Signaln, Komponntn, Subkomponntn und Konnktorn. In dism Zusammnhang wird di apply-funktion dfinirt, di fstlgt, wi in Dltatransformation auf in Architktur A angwandt wird. Dfinition (Dltaanwndung). Di Anwndung dr Transformationsopration T o = {to 1,, to n } ins Dltas auf in Softwararchitktur a = (C, Π, Σ) ist im Folgndn ggbn, wobi sc C als Indx dr Komponnt ntspricht, di durch dn Dlta-Paramtr sc rfrnzirt ist. apply(a, ) = a 46

65 3.3 Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik apply(a, ) = apply(a, T o ) = apply(apply(a, to i ), T o \{to i }) apply(a, add componnt) = a = (C, Π, Σ ) wobi C = C {componnt}, Π = Π, Σ = Σ apply(a, add subcomponnt) = a = (C, Π, Σ ), wobi C = (C\c sc ) c sc, Π = Π, Σ = Σ und c sc = (C sc {subcomponnt}, Π sc, Σ sc ) apply(a,add signal) = a = (C, Π, Σ ), wobi C = C, Π = Π {signal}, Σ = Σ apply(a,add connctor) = a = (C, Π, Σ ), wobi 1.Fall: sc =, mit C = C, Π = Π, Σ = Σ {connctor} 2.Fall: sc, mit C = (C\c sc ) c sc, Π = Π, Σ = Σ und c sc = (C sc, Π sc, Σ sc {connctor}) apply(a, rmov componnt) = a = (C, Π, Σ ) wobi C = C\{componnt}, Π = Π, Σ = Σ apply(a, rmov subcomponnt) = a = (C, Π, Σ ), wobi C = (C\c sc ) c sc, Π = Π, Σ = Σ und c sc = (C sc \{subcomponnt}, Π sc, Σ sc ) apply(a, rmov signal) = a = (C, Π, Σ ), wobi C = C, Π = Π\{signal}, Σ = Σ apply(a, rmov connctor) = a = (C, Π, Σ ), wobi 1.Fall: sc =, mit C = C, Π = Π, Σ = Σ\{connctor} 2.Fall: sc, mit C = (C\c sc ) c sc, Π = Π, Σ = Σ und c sc = (C sc, Π sc, Σ sc \{connctor}) Wnn für in Dlta kin Komponnt sc anggbn wurd, wird angnommn, dass das Dlta auf dr höchstn Hirarchibn, also auf dr Architktur slbst dfinirt wird. Hirfür wrdn di apply-funktionn für di Anwndung auf dr Architktur a sowi inr inzlnn Komponnt sc dfinirt. Um di formal Dfinition dr apply-funktion für di vrschidnn Elmnt inr Softwararchitktur lichtr nachvollzihn zu könnn, ist in Abbildung 3.6 in grafisch Übrsicht für di Transformationsoprationn dargstllt. 47

66 3 Dlta-orintirt Modllirung von Softwararchitkturn Add Componnt sig C1 C2 Add Subcomponnt sig C1 C2 Add Connctor C1 C2 Add componnt C3 Add subcomponnt C4 in C2 Add connctor (con,c1,sig,sig,c2) C1 sig C2 C1 sig C2 C1 sig C2 C3 C4 Rmov Componnt Rmov Subcomponnt Rmov Connctor C1 sig C2 C1 sig C2 C1 sig C2 C3 C1 sig Rmov componnt C3 C2 C1 sig Rmov subcomponnt C4 in C2 C2 C4 C1 Rmov connctor (con,c1,sig,sig,c2) C2 Abbildung 3.6: Übrsicht übr di Transformationsoprationn In dr Übrsicht wird jwils di add- und rmov-transformation für in Elmnt aufgführt. Zunächst wrdn di Transformationn für in Komponnt dargstllt. Wird in Softwarkomponnt (im Bispil C3 ) hinzugfügt, so xistirt noch kin Vrbindung zu andrn Softwarkomponntn. Dis muss durch add connctor nachträglich rzugt wrdn. Das Hinzufügn von Konnktorn wird im Bispil für inn Konnktor con, dr di bidn Komponntn C1 und C2 mit dm Signal sig vrbindt, dargstllt. Nbn Softwarkomponntn und Konnktorn zigt di Abbildung auch das Hinzufügn inr Subkomponnt C4, di in dr Softwarkomponnt C2 anglgt wird. Hirbi handlt s sich um in hirarchischs Hinzufügn, d.h. di Komponnt C4 ligt innrhalb von C2 und bsitzt nach dm Anlgn kinrli Vrbindungn zu andrn Komponntn. Für di dri Elmnt wird nbn dn add-transformationn auch jwils daruntr di rmov-transformation gzigt, bi dr r sich um in invrtirt add- Transformation handlt, d.h. in rmov kann in zuvor ausgführt add-transformation rückgängig machn bzw. widr aufhbn. Bvor in Komponnt odr Subkomponnt ntfrnt wird, sollt sichrgstllt wrdn, dass s kin Konnkto- 48

67 3.3 Konzption inr dlta-orintirtn Softwararchitkturmodllirungstchnik rn gibt, di dis Komponntn vrwndn. Es wird xplizit gfordrt, dass in Komponnt kompltt isolirt wird, bvor si ntfrnt wrdn kann. Es gilt! σ Σ : σ = (N, C S, S CS, S CT, C T ) mit C S = {componnt} odr C T = {componnt}, wobi {componnt} di zu ntfrnnd Komponnt ist. Glichs gilt für Komponntn, di Subkomponntn bsitzn: Um in solch Komponnt zu ntfrnn, müssn zunächst all ihr Subkomponntn und drn Konnktorn ntfrnt wordn sin. Wird in ungültig Transformation rkannt, wird dr gsamt Transformationsprozss abgbrochn und s wird dr Ausgangszustand dr Architktur widrhrgstllt. Zwi Bispil für ungültig Rmov-Oprationn von Komponntn sind in Abbildung 3.7 dargstllt. C1 sig C2 C1 C2 C4 Rmov componnt C2 X Rmov componnt C2 X Abbildung 3.7: Ungültig Rmov-Transformationn von Komponntn Im linkn Bispil soll di Komponntn C2 ntfrnt wrdn. Dis ist jdoch noch übr inn Konnktor mit dr Komponnt C1 vrbundn. Dadurch ist s nicht möglich, di Löschung von C2 vorzunhmn. Di Transformation würd abgbrochn wrdn. Auch im zwitn Bispil aus Abbildung 3.7 soll di Komponnt C2, di dismal kinn Konnktor mhr bsitzt, ntfrnt wrdn. Dismal handlt s sich jdoch um in hirarchisch Komponnt, di di Subkomponntn C4 binhaltt. Dis macht in Entfrnung unmöglich und führt zum Abbruch dr Transformationsopration. Um C2 zu Entfrnn, muss zunächst C4 ntfrnt wrdn. Es fällt auf, dass in Dfinition zusätzlich zu Komponntn, Subkomponntn und Konnktorn auch noch Transformationn für Signal dfinirt sind, dis jdoch nicht in Abbildung 3.6 grafisch dargstllt ist. Dr Grund dafür ist, dass das Hinzufügn ins Signals zunächst kinn Einfluss auf di obsrvirbar Topologi inr Softwararchitktur hat, da das Signal noch nicht vrwndt wird. Das nu Signal wird zunächst dfinirt, um s dann, durch spätr hinzukommnd Komponntn bzw. Konnktorn, vrwndn zu könnn. Dahr wird di add und rmov-transformation für Signal nicht in dr Übrsicht aufgführt, auch wnn si in Bstandtil dr möglichn Transformationn inr Softwararchitktur sind. Konnktorn könnn nach Dfinition gzilt Softwarkomponntn hinzugfügt wrdn, d.h. si könnn auch in Subkomponntn durch Dltas hinzugfügt 49

68 3 Dlta-orintirt Modllirung von Softwararchitkturn wrdn. In Dfinition wird dafür in apply-funktion auf inr Subkomponnt dfinirt. Für Konnktorn rgbn sich dri hirarchisch Konfigurationn, wobi mit C sub di ndlich Mng dr Subkomponntn inr Softwararchitktur A H zusammngfasst wird. Wnn con = (c, sig o, sig i, c ) mit c, c C sub, dann ist con in Konnktor innrhalb inr Komponnt Wnn con = (c, sig o, sig i, c ) mit c C und c C sub, dann ist con in Inputkonnktor dr Komponnt c Wnn con = (c, sig o, sig i, c ) mit c C sub und c C, dann ist con in Outputkonnktor dr Komponnt c Di Konfigurationn ähnln dn in Dfinition Vorgstlltn. Gnaur gsagt kann angnommn wrdn, dass di Umwlt inr höhrn Hirarchibn ntspricht und di Architktur das Subsystm rpräsntirt. In dism Fall lassn sich di bidn Konfigurationsdfinitionn aufinandr abbildn. Bi dr Dfinition ins konkrtn Konnktors ist darauf zu achtn, dass di vrbundnn Komponntn ntwdr bid in dr glichn Subkomponnt lign, odr abr dass di Sourc-bzw. Targt- Komponnt in dr andrn Komponnt nthaltn ist. Nachdm di Formalismn inr Softwararchitktur sowi di Gnrirung nur Produkt durch dn dlta-orintirtn Modllirungsansatz dfinirt wurdn, wird im folgndn Abschnitt di dlta-orintirt Softwararchitkturbschribungssprach Dltarx vorgstllt, mit drn Hilf hirarchisch Softwararchitkturn und dazughörig Dlta dfinirt wrdn könnn, um so in Mng von Architkturn für di Produkt inr SPL zu gnrirn. 3.4 Grammatik dr Dlta-orintirtn Softwararchitkturbschribungssprach Di zuvor formal dfinirtn Elmnt inr Softwararchitktur solln durch in igns ntwicklt Softwararchitkturbschribungssprach txtull für konkrt Systm bschribn wrdn könnn. Dazu ist s nötig di Sprach formal zu dfinirn. Um Sprachn formal zu rzugn, könnn kontxtfri Grammatikn vrwndt wrdn [6]. Auf Basis dr kontxtfrin Grammatikn soll in Grammatik und drn Rgln für in Architkturbschribungssprach (gnannt Dltarx) ggbn wrdn. Di Sprach soll di in Kapitl bschribnn Elmnt inr Softwararchitktur akzptirn. 1 Dltarx ::= a r c h i t c t u r Nam for faturmodl Fm 2 s i g n a l s { SignalSt }, 3 componnts { ComponntSt }, 4 c o n n c t o r s { ConnctorSt }, 50

69 3.4 Grammatik dr Dlta-orintirtn Softwararchitkturbschribungssprach 5 d l t a s { DltaSt } 6 7 SignalSt ::= Signal Signal, SignalSt ɛ 8 Signal ::= s i g n a l (Nam, SignalTyp ) 9 SignalTyp ::= b o o l a n doubl i n t g r char ComponntSt ::= Componnt Componnt, ComponntSt ɛ 12 Componnt ::= componnt ( Nam, PortSt, ConnctorSt, 13 ComponntSt ) ConnctorSt ::= Connctor Connctor, ConnctorSt ɛ 16 Connctor ::= connctor ( Nam, ConnctorTyp ) 17 ConnctorTyp ::= ( Componnt, Signal, Signal, Componnt ) 18 ( Componnt, Port, Signal, 19 Signal, Port, Componnt ) DltaSt ::= Dlta Dlta, DltaSt ɛ 23 Dlta ::= d l t a Nam whn AppCondition a f t r Ordr 24 add { AddElmnt } 25 rmov { RmovElmnt } AppCondition ::= Fatur ( AppCondition ) && ( Fatur ) 28 ( AppCondition ) && not ( Fatur ) ɛ 29 Fatur ::= Fatur. Nam! Fatur. Nam 30 Ordr ::= Dlta. Nam Dlta. Nam, Ordr ɛ 31 AddElmnt ::= AElmnt AddElmnt, AElmnt ɛ 32 RmovElmnt ::= RElmnt RmovElmnt, RElmnt ɛ 33 AElmnt ::= Signal Componnt Componnt i n Componnt 34 Connctor Connctor i n Componnt 35 RElmnt ::= Signal Componnt Componnt i n Componnt 36 Connctor Connctor i n Componnt Listing 3.8: Kontxtfri Grammatik dr Sprach Dltarx Di Grammatik bschribt di Konstrukt, di di Sprach Dltarx britstllt, um in Softwararchitktur txtull zu dfinirn. In dr Einstigsrgl Dltarx wird in Nam sowi in Faturmodll anggbn, für das di Architktur und di Dltas dfinirt wrdn. Witrhin bschribt di Rgl di vir Grundlmnt Signal, Komponnt, Konnktor und Dlta (Zil 1-5), di widrum jwils durch in Mng von Rgln dfinirt sind. Di Elmnt solln im Folgndn inzln bschribn wrdn. Softwararchitkturn in Dltarx bsitzn in Mng von Signaln. Dis sind global dfinirt und dahr in jdr Komponnt bkannt. Das Schlüsslwort signal litt in Signaldfinition in (Zil 8). Signal wrdn übr inn Namn rfrnzirt 51

70 3 Dlta-orintirt Modllirung von Softwararchitkturn und bsitzn inn Signaltyp (SignalTyp). Dr Signaltyp kann vom Typ boolan, doubl, intgr odr char sin (Zil 9). Dfinirt Signal könnn von sämtlichn Komponntn und Konnktorn vrwndt wrdn. Ein Softwarkomponnt wird durch di Rgln dr Ziln 11 bis 13 dfinirt. Ein Softwararchitktur kann dmnach in, mhrr odr kin Komponntn nthaltn. Dr Fall, dass kin Komponnt nthaltn ist, sollt jdoch als Sondrfall btrachtt wrdn, da s fraglich ist, ob in Softwararchitktur ohn Komponntn noch als solch zu bzichnn ist. Dnn in Architktur ohn mindstns in Softwarkomponnt stllt kinrli Funktionalität brit, di in Softwarsystm als solchs auszichnn. So dfinirt di IEEE in Systm als [2]: A collction of componnts organizd to accomplish a spcific function or st of functions. In disr Arbit wird dahr angnommn, dass in valid Softwararchitktur aus mindstns inr Softwarkomponnt bstht. Di Grammatik rlaubt dnnoch di Angab kinr Komponnt, da di gwählt Krnarchitktur nicht zwangsläufig in valid Produktkonfiguration sin muss, sondrn rst durch ntsprchnd Anwndung von Dltas zu nun, validn Produktn führn könnt [50]. Existirt mindstns in Komponnt, so wird si und all witrn durch di Rgl Componnt dfinirt (Zil 12) und wird dmnach durch das Schlüsslwort componnt und inn Namn bzichnt. Si bsitzt zusätzlich in Mng von Konnktorn und Subkomponntn. Komponntn könnn nbn Ports in Mng von Konnktorn bsitzn. Konnktorn könnn auch auf Architkturbn dfinirt wrdn. Di dazughörign Rgln sind für bid Fäll idntisch und sind in dn Ziln 20 bis 23 dr formaln Grammatik aufgführt. Konnktorn wrdn durch das Schlüsslwort connctor und inn Namn idntifizirt. In dr Grammatik wird in zwi vrschidn Konnktortypn untrschidn (Zil 22), in Konnktor muss immr gnau inm Typ ntsprchn. Entwdr dr Konnktor ist in 4-Tupl aus zwi Komponntn und zwi dazughörign Signaln, di übrtragn wrdn solln. Es wird in zwi Signal untrschidn, obwohl Konnktorn nur in Signal übrtragn, da Komponntn in Signal lokal untrschidlich bzichnn. Bi disr Konnktorvariant wrdn kin Ports vrwndt und si ist an dr Dfinition aus Kapitl 3.3 anglgt. Es ist jdoch auch möglich, Konnktorn mit Angab ins Ports zu dfinirn. Dann müssn nbn dn Komponntn und Signaln auch noch di zu vrwndtn Ports anggbn wrdn. Dis müssn für das Signal nutzbar sin. Nbn dr Dfinition inr Softwararchitktur und drn Elmntn rlaubt Dltarx auch di Dfinition von Dltas (Zil 26-29). Mit Hilf dr Dltas könnn di in Dfinition fstglgtn Transformationn bschribn wrdn. Di Anzahl dr dfinirtn Dltas kann blibig gwählt wrdn. Auf di Dltadfinition kann auch kompltt vrzichtt wrdn (Zil 26). Um in Dlta zu dfinirn, muss das Schlüsslwort dlta und in indutigr Nam anggbn wrdn (Zil 27). Zusätzlich kann in Dlta in Application Condition sowi in Rihnfolg (ordr) bsitzn. 52

71 3.4 Grammatik dr Dlta-orintirtn Softwararchitkturbschribungssprach Di Application Condition gibt an, untr wlchr Bdingung das Dlta ausgwählt wird. Si bziht sich dabi auf in Mng von Faturs dr SPL (Zil 31-32). Ein Application Condition muss anggbn wrdn. Si kann aus inm inzlnn Fatur, dssn Ngation bzw. Nichtvorhandnsin odr inr blibign Konkatnation von Faturs und ngirtn Faturs bsthn. Es handlt sich um inn bool schn Ausdruck, dr immr dn Wrt wahr odr falsch annimmt und dadurch immr auswrtbar ist. Di Ordr gibt an, ob und wlch Dltas vor dm dfinirtn Dlta auszuführn sind, damit das Ergbnis dr Transformationn valid ist (Zil 34). Ein Ordnung ist optional und kann in odr mhrr Dltas umfassn. Di vrwndbarn Transformationn wrdn grundsätzlich in add und rmov- Oprationn untrschidn (Zil 28-29). Es könnn jwils Komponntn, Konnktorn, Signal und Ports hinzugfügt und ntfrnt wrdn (Zil 37-42). Durch das Schlüsslwort in nach inr Anwisung könnn Elmnt auch hirarchisch hinzugfügt odr ntfrnt wrdn, d.h. s kann in Komponnt anggbn wrdn, für di di Transformation durchgführt wrdn soll. Ein Bispil ist di Anwisung Add Componnt B in Componnt A. Dis würd di Subkomponnt B dr Komponnt A hinzufügn. Bi A könnt s sich widrum um in Subkomponnt handln, wshalb in blibig tifr Hirarchibaum ntwicklt wrdn kann. Glichs gilt für das Entfrnn von Elmntn. Es könnn blibig vil Elmnt innrhalb ins Dltas hinzugfügt odr ntfrnt wrdn (Zil 35-36). Di in dism Kapitl vorgstlltn Softwararchitkturn sowi drn Bstandtil wrdn im nächstn Kapitl als Tstmodll für in dlta-orintirts Intgrationststvrfahrn für Softwarproduktlinin vrwndt. Anhand dr Tstmodll solln Tstfäll für di zu prüfndn Produkt ntwicklt wrdn könnn. Di Trminologi und di Tststratgi ds Tstvrfahrns wrdn im nächstn Kapitl bschribn. 53

72 4 Dlta-orintirts Modllbasirts Intgrationststn In dism Kapitl soll in Intgrationststvrfahrn für Softwarproduktlinin auf Basis dr in Kapitl 3 vorgstlltn Architkturmodll ntwicklt wrdn. Dazu wird in Tstmodll ntworfn, dass zur Entwicklung von Tstfälln gnutzt wrdn kann. Das Tstvrfahrn soll dn dlta-orintirtn Modllirungsansatz untrstützn. Es wird in Tststratgi vorgstllt, in dr Mssag Squnc Charts als Tstfäll auf Basis von Softwararchitkturn als Tstmodlln ntwicklt wrdn. Für di Tstfäll wird dr Bgriff dr Widrvrwndbarkit dfinirt. 4.1 Konzption ins Tstmodlls Wi in Kapitl 3 bschribn, kann für jds Produkt dr SPL in dazughörig Softwararchitktur gnrirt wrdn. Aus Dfinition rgibt sich, dass in Tstmodll in Softwararchitktur rpräsntirt, di sämtlich Vrhaltnsbschribungn durch di Topologi ds Produkts nthält. Di vrwndt Krnarchitktur wird auch als Krntstmodll bzichnt. Dfinition (Tstmodll). Ein Tstmodll ntspricht inr hirarchischn Softwararchitktur, so dass tm = A H = (C, Π, Σ) gilt. Das Zil ins Tstprozsss ist zu Übrprüfn, ob sich in Systm Undr Tst sinr Vrhaltnsspzifikation ntsprchnd vrhält odr ob dis durch in Fhlvrhaltn vrltzt wird. Hirfür wrdn Tstmodll ntwicklt, aus dnn sich Tstfäll ablitn lassn. Das Systm kann durch di Ausführung von Tstfälln simulirt wrdn. In dm hir vorgstlltn Tstprozss wrdn Mssag Squnc Charts (MSC) als Tstfäll vrwndt. Di Mng T C(tm) = (tc 1,, tc n ) umfasst all ablitbarn Tstfäll ins Tstmodlls. Dfinition (Tstfall). Ein Tstfall ntspricht inm Mssag Squnc Chart und ist in 4-Tupl tc = (I, Loc, λ, < co ) [31] wobi I in ndlich Mng von Komponntninstanzn, Loc = i I Loc i in ndlich Mng von Locations, di in Tilmngn von Instanzlocations Loc i für jd Komponntninstanz i I zrlgt sind, λ : Loc Π in Lablingfunktion, di in Labl dr Signalmng Π jdr Location zuwist und 54

73 4.1 Konzption ins Tstmodlls < co Loc Loc in Kausalordnung auf Instanzlocations ist. Di Kausalordnung < co dfinirt, dass in Mng von Aktionn, also das Sndn und Empfangn von Signaln σ Σ, in inr bstimmtn Rihnfolg stattfindt und das in gsndts Signal immr zu inm mpfangnn Signal an inr Location führt. Di Kausalordnung ist dfinirt als < co =< tio < msg [31], wobi < tio = i I < tio,i, mit < tio,i Loc i Loc i, so dass < tio,i in total Ordnung dr Instanzlocations i I ist. < msg = Loc Loc ist in Nachrichtnrlation, so dass für jd Location l Loc\Loc ɛ, gnau inr dr folgndn Fäll gilt: 1.!l Loc, l l : l < msg l, d.h. l rpräsntirt in sndnd Nachrichtnaktion 2.!l Loc, l l : l < msg l, d.h. l rpräsntirt in mpfangnd Nachrichtnaktion 3.!l Loc ɛ, l l : l < msg l, d.h. l rpräsntirt in ausghnd Nachrichtnaktion 4.!l Loc ɛ, l l : l < msg l, d.h. l rpräsntirt in inghnd Nachrichtnaktion Mit Loc IO Loc wird in Untrmng von Eingangs- und Ausgangsnachrichtn rfrnzirt. Locations, di nicht in LOC IO lign, wrdn als τ-aktionn bzichnt und sind von Außn nicht obsrvirbar. Es gilt Loc τ = Loc\Loc IO. MSCs bschribn inn Kommunikationsabschnitt dr Systmausführung für in bstimmt Tilarchitktur. Ein Tilarchitktur bschribt inn Ausschnitt aus inr Softwararchitktur a = (C, Π, Σ) für in Produkt. In disr Arbit wird davon ausggangn, dass in Tilarchitktur aus mindstns zwi mitinandr vrbundnn Komponntn bstht. In Abbildung 4.1 wird dr Zusammnhang zwischn inm MSC als Tstfall und dr Architktur als Tstmodll vrdutlicht (Abbildung in Anlhnung an [31]). Darin sind zwi MSCs als Tstfäll zu shn. Si bschribn di Kommunikation zwischn dn btiligtn Komponntn für inn Ausschnitt dr Softwararchitktur, di als Tstmodll fungirt. In dr Abbildung sind di Tilarchitkturn hrvorghobn, di von dn MSCs abgdckt wrdn. Würd in Komponnt ins MSCs in Nachricht an in andr, nicht im MSC nthaltn Komponnt sndn, so wird si stattdssn an di Umwlt gsndt. Di Ausführung ins Tstfalls ntspricht inm Tstlauf, wobi disr auf in ndlich Mng von Eingabsignaln aus dr Umwlt und inr obsrvirbarn Mng von Ausgangssignaln an di Umwlt ntspricht, da das intrn Komponntnvrhaltn auf Architkturbn unbkannt ist und dm Vrhaltn inr Blackbox ntspricht. Für Tstläuf und Tstfäll wird di Rlation xc T C T M, mit xc(tc, tm) : Ein Tstfall tc ist in inm Tstmodll tm ausführbar, wnn dr dazughörig Tstlauf im Tstmodll nthaltn ist 55

74 4 Dlta-orintirts Modllbasirts Intgrationststn Mssag Squnc Charts (Tstfäll) Softwararchitktur (Tstmodll) C1 C2 C1 C2 C3 C2 C3 Abbildung 4.1: Bzihung zwischn Tstfall und Tstmodll dfinirt [11]. Di Rlation xc gibt an, ob in Tstfall in inm Tstmodll ausführbar ist. Dfinition (Tstlauf). Ein Tstlauf für inn Tstfall tc = (I, Loc, λ, < co ) ist dfinirt als tr = xc(tc, tm) = (λ(l i )),, λ(l k )) Π, wobi (l i, l j,, l k ) = (l 1,, l k ) Loc IO di Projktion von tc auf in Tilsqunz dr Locations in Bzug auf in Mng von Input/Output-Aktionn von Loc IO ist [31]. Das obsrvirbar Ergbnis ins Tstlauf ist in Tilsqunz von Locations Loc IO. Anhand disr kann in Systm ntggn sinr Spzifikation durch dn Tstlauf auf Korrkthit gprüft wrdn. Ein validr Tstfall sollt immr mindstns in Eingabsignal sowi in Ausgabsignal nthaltn, da nur dis obsrvirbar sind. Somit sind nur dis Signal zur Übrprüfung auf Korrkthit dr Ausführung vrwndbar. Di gsamt Squnz aus Locations bstht zusätzlich aus dn nicht sichtbarn τ-signaln, di zwischn dn Komponntn ds MSCs ausgtauscht wrdn. Für all Eingab und Ausgabsignal gilt π n Π. Di Umwlt wird durch di Annahm dr Existnz inr Umwltkomponnt E I rpräsntirt, di spzill xtrn Locations l Loc E Loc bsitzt und übr all Signal Π dr Softwararchitktur vrfügt. Um di Erstllung von Tstfälln inzugrnzn und dn Tstprozss ffizintr zu gstaltn, wrdn Tstndkritrin bnötigt, di in gzilt Tstfallntwicklung rmöglichn und di Mng dr zu tstndn Tstfäll ingrnzn. Ohn in passnds Tstndkritrium käm s zu inr potntill risign Anzahl von Tstfälln, da di als Tstfall gwähltn MSCs nichtdtrministisch sind und s dahr shr vil vrschidn Möglichkitn gibt, bstimmt Tstsznarin zu modllirn. Witrhin wär nicht klar, wi vil MSCs bnötigt wrdn, um in Produkt ausrichnd zu tstn, um sichr zu ghn, dass sin Vrhaltn dr Spzifikation ntspricht. Das 56

75 4.1 Konzption ins Tstmodlls Tstndkritrium sowi witr gwählt Kritrin zur Tstfallrstllung für dis Arbit wrdn im folgndn Abschnitt fstglgt Dfinition dr Tstkritrin MSCs sind nichtdtrministisch und zign nur Ausschnitt dr Kommunikation und könnn potntill wig fortgstzt wrdn. Um dn Tstaufwand inzugrnzn und Tstfäll gzilt zu rstlln, muss in gignts Tstndkritrium dfinirt wrdn. Im Modllbasirtn Tstn wrdn hirfür häufig Abdckungskritrin ingstzt [11]. Dis lgn Fragmnt ins Tstmodlls fst, di bi inr Tstfallausführung travrsirt wrdn müssn. Wird in Abdckungskritrium C auf in Tstmodll angwandt, wählt diss Fragmnt ds Tstmodlls, in disr Arbit inr Softwararchitktur, aus. Dis wrdn als Tstzil G = {g 1,, g n } bzichnt. In dm in disr Arbit vorgstlltn Tstprozss solln Mssag Squnc Charts als Tstfäll vrwndt wrdn. Dahr müssn di Tstkritrin, di das Tstmodll in in Rih von Tstziln auftiln, auf Basis dr Tstmodlldfinition ntwicklt wrdn. In dr Forschung häufig ingstzt Tstkritrin sind Zustandsübrdckung (c0 ) und Transitionsübrdckung (c1 ) für Zustandsautomatn [29]. Dfinition (Abdckungskritrium). Ein Abdckungskritrium C : T M P(G) bstimmt für in Tstmodll tm = (C, Π, Σ) di ndlich Mng abzudckndr Tstzil G = C(tm). In disr Arbit soll das c1 -Kritrium für di Tstzil vrwndt wrdn. Es wird jdoch nicht auf Transitionn, sondrn Konnktorn angwandt. Konnktorn vrbindn, ähnlich zu Transitionn in Zustandsdiagrammn, jwils zwi Komponntn mitinandr. Als Sondrfall ist di Vrbindung von in und drslbn Komponnt durch inn Konnktor zu nnnn, dr in disr Arbit allrdings nicht btrachtt wird. Somit wird di c1 -Transtionsabdckung als Konnktorabdckung intrprtirt, d.h. jdr Konnktor muss mindstns inmal von inm Tstfall travrsirt wordn sin. Transitionsabdckung binhaltt automatisch di Zustandsabdckung (c0), da Transitionn Zuständ mitinandr vrbindn und wnn jd Transition gnutzt wird, so wird auch automatisch jdr, mit inr Transition vrbundn, Zustand abgdckt. Im Rahmn von Softwararchitkturn wird di c0 -Zustandsabdckung in disr Arbit als Komponntnabdckung bzichnt, da dis analog zu Zuständn ins Automatn durch Konnktorn vrbundn sind. Es wird von zusammnhängndn Architkturn ausggangn, wshalb jd Komponnt übr Konnktorn rricht wrdn kann. Daraus rsultirnd wird klar, dass Konnktorabdckung di Komponntnabdckung binhaltt. Ein Bispil für in Vrwndung dr Konnktorabdckung auf inr Softwararchitktur ist in Abbildung 4.2 dargstllt. Im Bispil ist in Softwararchitktur dargstllt. Si bstht aus dn dri Komponntn C1, C2 und C3. Witrhin nthält di Abbildung dri Tstfäll, di darauf basirnd ntworfn wurdn; tc1, tc2 und 57

76 4 Dlta-orintirts Modllbasirts Intgrationststn S1 C1 Tstmodll S2 S4 C2 S5 S3 S1 C1 S2 S3 Tstfäll C2 S6 S7 C3 S5 S4 C2 S6 C3 tc1 C3 C2 tc2 S7 S6 S5 S3 Tstfallauswahl tc3 Konnktorabdckung Tstzil G = {S1, S2, S3, S4, S5, S6, S7} tc1 tc2 Abbildung 4.2: Bispil für Konnktorabdckung tc3. Um das Bispil übrsichtlich zu haltn, wrdn di Konnktorn dr Architktur anhand ihrn übrtragnn Signaln rfrnzirt (S1, S2, tc.). Als Abdckungskritrium wurd di Konnktorabdckung gwählt, d.h. di Auswahl an Tstfälln muss mindstns jdn Konnktor mindstns inmal travrsirn. Daraus lässt sich das Tstzil G = {S1, S2, S3, S4, S5, S6, S7} ablitn. Btrachtt man di Mng von Tstfälln wird dutlich, dass tc1 und tc2 gminsam all Konnktorn abdckn und dahr das Tstzil G rfülln. Ein Hinzunahm von tc3 dckt kinn noch nicht travrsirtn Konnktor ab, und tc3 hat glichzitig in gringrn Abdckungsgrad als tc2, wshalb di Auswahl dr Tstfäll tc1 und tc2 als Tstsuit gwählt wrdn sollt, um dn Tstaufwand durch das Einsparn von Tstfall tc3 gring zu haltn und glichzitig di gfordrt Konnktorabdckung zu rrichn. Das Bispil vrdutlicht auch, dass Konnktorabdckung di Komponntnabdckung umfasst. Dnn di bidn gwähltn Tstfäll umfassn all dri Komponntn C1,C2 und C3, di in inm Tstzil G = {C1, C2, C3} für Komponntnabdckung nthaltn wärn. Für das in disr Arbit ntwicklt Tstvrfahrn wird di Konnktorabdckung 58

77 4.1 Konzption ins Tstmodlls sowi di darin binhaltt Komponntnabdckung auf Softwararchitkturn gfordrt. Hirfür kann di Rlation covrs T C G, mit covrs(tc, g) : Ein Tstfall dckt in Tstzil gnau dann ab, wnn das dazughörig Elmnt durch dn Tstlauf travrsirt wird dfinirt wrdn, wlch Tstfäll und Tstzil mitinandr vrknüpft. Wird das Abdckungskritrium vrwndt, um in Mng von Tstziln G zu dfinirn, kann in Mng von passndn Tstfälln rstllt wrdn, wlch di Tstzil abdckn. Man fasst di Mng dr ausgwähltn Tstfäll als Tstsuit zusammn. Dfinition (Tstsuit). Ein Tstsuit ts = {tc 1,, tc n } T C(tm) ist in Mng von Tstfälln tc i ts. Für in Tstsuit kann dr Bgriff dr Vollständigkit ingführt wrdn, dr dann gilt, wnn si di folgnd Eignschaft rfüllt: g G : tc ts : covrs(tc, g) Basirnd auf dr rstlltn Tstsuit lässt sich in Tstplan tp rstlln, wlchr di auszuführndn Tstfäll für inn Produkttst umfasst. Damit nicht jdr Tstfall für jds Produkt, in dm r vrwndbar wär, rnut ausgführt wird, muss zunächst fstgstllt wrdn, wann in Tstfall widrvrwndbar ist. Dazu wird in Äquivalnzkonzpt für Tstmodll ingführt Äquivalnz von Tstmodlln Um di Widrvrwndbarkit von Tstfälln auf vrschidnn Tstmodlln prüfn zu könnn, muss in Äquivalnzbgriff für Tstmodll ingführt wrdn. Um in Aussag übr di Äquivalnz zwir Tstmodll zu trffn, ist s notwndig, in gignts Kritrium zu wähln. Auf Grund dr Tatsach, dass di Tstmodll in Bzug auf di Ausführbarkit von Tstfälln gprüft wrdn solln, könnn di Tstläuf tr dr Tstmodll als Vrglichskritrium gwählt wrdn. Dmnach wird zunächst gfordrt, dass in Tstfall auf dn zu prüfndn Tstmodlln ausführbar sin muss. Es muss also xc(tc, tm) xc(tc, tm ) gltn. In dism Zusammnhang wird für in Äquivalnz von zwi Tstmodlln di Notation tm 1 T R tm 2 ingführt. Di Tstmodll sind äquivalnt, wnn in Tstfall auf bidn Tstmodlln ausführbar ist und di Mng dr Input- und Outputnachrichtn ins Tstfalls für di bidn Modll idntisch sind. Dr Äquivalnzbgriff lässt sich im Allgminn nicht auf di Komposition dr Tstmodll auswitn, da dis durch dn dlta-orintirtn Modllirungsansatz und di darin nthaltn Variabilität nimals vollständig idntisch sin wrdn, da 59

78 4 Dlta-orintirts Modllbasirts Intgrationststn s sich sonst um das glich rpräsntirt Produkt handln würd. Dahr wrdn ausschlißlich di Tstläuf auf dn Tstmodlln btrachtt, um in Äquivalnz zu rmittln, mit drn Hilf di Widrvrwndbarkit von Tstfälln auf Tstmodlln gprüft wrdn kann. Im nächstn Abschnitt wird dr Einfluss von Fatur-Intraktionn auf das Tstvrhaltn rläutrt Einfluss von Fatur-Intraktionn Wi in Kapitl bschribn, kann s zwischn dn Faturs inr SPL zu Fatur- Intraktionn kommn. In Tabll 2.1 wurdn dabi di möglichn Intraktionn bschribn, di sowohl positiv als auch ngativ sin könnn [33]. Frbr t al. [16] stlln fünf Katgorin von Fatur-Intraktionn fst: Intntional Intraction: Einig Faturs ändrn gzilt das Vrhaltn andrr Faturs, um so di Intraktion mit andrn Faturs zu binflussn. Rsourc-Usag Intraction: Einig Systmrssourcn könnn drart limitirt sin, dass nur in gwiss Untrmng von Faturs si bnutzn kann. Diss Problm kann auch durch spzill dafür ingstzt Faturs grglt wrdn, z.b. in Form von Tribrn. Environmnt Inducd Intraction: Wnn in Mng von Faturs Eignschaftn dr Umwlt übrwacht und in andr Mng von Faturs dis binflusst, kommt s zu indirktn Intraktionn zwischn disn Faturs übr di Umwlt. Dis Art von Abhängigkit ist schwirig zu rknnn, da mistns kin dirkt Vrbindung zwischn dn btroffnn Faturs xistirt. Usag Dpndncy: Di häufigst Form von Fatur-Abhängigkitn ist Vrwndung ins andrn Faturs durch in rquir-bzihung im Fatur-Modll. So könnt in Fatur z.b. in Form ins Snsors Datn für in andrs Fatur britstlln. Excludd Dpndncy: Einig Faturs könnn nicht in dr slbn Produktvariant vrwndt wrdn, da si sich ggnsitig ausschlißn. Dis wird durch in xclud-bzihung im Faturmodll gknnzichnt. Dr Ausschluss dr Faturs kann sich abr auch auf di Laufzit bzihn, so dass zwi Faturs nicht zur glichn Zit aktiv sin könnn. Bi dm in disr Arbit vrwndtn Tstmodll in Form inr Softwararchitktur könnn di Fatur-Intraktionstypn Intntional Intraction, Usag Dpndncy und Excludd Dpndncy fstgstllt wrdn und müssn dahr bi dr Erstllung dr Tstfäll brücksichtigt wrdn. Fatur-Intraktionn könnn dmnach dazu führn, dass in Tstfall tc, dr auf zwi Tstmodlln tm und tm ausführbar ist, für di Tstmodll inn untrschidlichn Tstlauf bsitzt: 60

79 4.2 Dfinition ds Tstvrfahrns xc(tc, tm) xc(tc, tm ) Durch di unbkanntn Wirkungn di Fatur-Intraktionn rzugn könnn, ist s notwndig, di Entwicklung ds Tstplans ntsprchnd anzupassn, so dass möglich Fatur-Intraktionn rkannt wrdn könnn. Hirfür müssn di vrschidnn Fatur-Kombinationn gtstt wrdn. Dis basirn auf Fatur-Abhängigkitn, di im Faturmodll dr Softwarproduktlini dfinirt wurdn. Auf Basis ds dfinirtn Tstmodlls und dr dazughörign Trminologi wird im nächstn Abschnitt in dlta-orintirts Intgrationststvrfahrn dfinirt. Es wird in Tststratgi vorgstllt, di für das Vrfahrn angwndt wrdn kann. 4.2 Dfinition ds Tstvrfahrns Das Zil disr Arbit ist s, auf Basis dr SPL-Tstphilosophin Subst-Huristics [44] und Rus-Tchniqus [44] sowi dn Rgrssionststtchnikn und ds Modllbasirtn Tstns in dlta-orintirts Intgrationststvrfahrn für SPLs zu ntwickln, dass dn Tstaufwand im Vrglich zu klassischn Singl Softwar Tsttchnikn durch di Widrvrwndung von Tstartfaktn vrringrt. Das in disr Arbit ntwicklt Intgrationststvrfahrn stzt auf dm Komponntntstvrfahrn auf, wlchs von Sascha Lity [30] konzipirt wurd. Di Strukturirung ds Intgrationststvrfahrns wird dahr an das Komponntntstvrfahrn anglhnt. Ostr t al. [44] fassn untr Subst-Huristics Tstansätz zusammn, di aus inr Mng dr möglichn Produkt inr Softwarproduktlini in rpräsntativ Mng auswähln, um dis als Tilmng allr Produkt zu tstn. Hirdurch kann das Tstn allr Produktvariantn vrmidn wrdn. Di Rus-Tchniqus wrdn von Ostr t al. [44] als Tstansätz bschribn, di dn Tstaufwand durch di Widrvrwndung von Tstartfaktn, vrringrn solln. Dazu wrdn häufig Rgrssionststs sowi Modllbasirts Tstn vrwndt. Auf Grundlag dr bidn Ansätz soll dr Tstablauf mit dn jwilign Tstschrittn dfinirt wrdn. Dis umfasst di Auswahl von Produktn, di Gnrirung von Tstmodlln und Tstfälln sowi drn Katgorisirung und Widrvrwndung innrhalb von Tstplänn. Disr Ablauf wird durch in Tststratgi bschribn, di im Folgndn dfinirt wird. Um in Softwarproduktlini mit dm Tstvrfahrn tstn zu könnn, wrdn di folgndn fünf Aktivitätn in dr konkrtn Rihnfolg für di Tststratgi dfinirt: 1. Auswahl dr zu tstndn Produkt P T P = {p 1,, p n }. Für all Produkt p i P T gilt dann: 2. Gnrirung ds Tstmodlls a = (C, Π, Σ) 3. Erstllung und Widrvrwndung dr Tstfäll T C = {tc 1,, tc n } 4. Katgorisirung von Tstfälln und Entwicklung inr Produkttstsuit 61

80 4 Dlta-orintirts Modllbasirts Intgrationststn 5. Tstfallslktion und Dfinition ins Tstplans Di Tststratgi ist in Abbildung 4.3 schmatisch dargstllt. Di bschribnn Aktivitätn wrdn im Folgndn untr zu Hilfnahm dr schmatischn Darstllung dtaillirt bschribn Auswahl dr Produkt Ein SPL umfasst in Mng von Produktn bzw. Produktvariantn, di durch di vrschidnn Faturkonfigurationn bschribn wrdn. Di Mng allr Produktvariantn wird als Produktraum bzichnt. Im Rahmn ds Tstns ist s jdoch nicht praktikabl, sämtlich Produkt ins Produktraums inzln zu tstn [44]. Dis bgründt sich u.a. dahr, dass vrschidn Produkt glichs Vrhaltn bsitzn könnn. Dis würd somit zu rdundantn Tstfälln führn, di das Tstvrfahrn inffizint wrdn lassn. Gnaur gsagt xistirn Tstläuf tr 1 T R tr 2 innrhalb dr Tstmodll, di äquivalnt zuinandr sind und dahr mhrfach gprüft wrdn würdn. Für di in dr Arbit vrwndt Fallstudi müsstn bispilswis insgsamt Produktvariantn [56] gtstt wrdn. Um dis zu vrmidn, wird auf Basis ds Subst-Huristic-Ansatzs [44] in Untrmng von Produktn ds Produktraums bstimmt, di dann rpräsntativ für di gsamt SPL gtstt wrdn. Um in Eingrnzung dr auszuwählndn Produkt durchführn zu könnn, muss in gignts Slktionskritrium dfinirt wrdn. In disr Arbit solln Faturkombinationn als Grundlag für di Slktion vrwndt wrdn, da s zu Fatur- Intraktionn (Vgl. Kapitl und 4.1.3) zwischn Faturs kommn kann, di gprüft wrdn müssn. Di Produktslktion ntspricht dr von Ostr t al. [44] vorgschlagnn Mthod ds Fatur Pairwis Tsting. Disr Ansatz bruht auf dm Combinatorial Tsting [22]. In dm Vrfahrn wrdn sämtlich Paramtr-Fatur-Blgungn für valid Fatur-Paar rmittlt. Ein solch Blgung ntsprcht ntwdr dm Vorhandsin ins Faturs odr dm Nichtvorhandnsin. Daraus wird so lang in Mng von validn Produktn gnrirt, bis jd möglich paarwis Kombination von mindstns inm Produkt abgdckt wird. Zultzt wird in rpräsntativ Mng von Produktn aus dm Produktraum ausgwählt, di di paarwisn Kombinationn abdckn. Für di gwähltn Produkt könnn di Tstmodll gnrirt wrdn. Jds Produkttstmodll basirt auf inm Krntstmodll und inr Mng von Dltas. Dahr ist s sinnvoll, das Krnprodukt bnfalls in di Mng dr rpräsntativn Produkt aufzunhmn, insofrn s sich dabi um in ignständigs Produkttstmodll handlt. Im Bispil aus Grafik 4.3 soll P0 das Krnprodukt rpräsntirn. Zusätzlich wurdn im Bispil noch di bidn Produkt P1 und P8 aus dm aus insgsamt zhn Produktn bsthndn Produktraum ausgwählt (vgl. Abbildung 4.3 Schritt 1). Da jds Produkt auf dm Krnprodukt basirt, könnn im spätrn Tstvrlauf vil Tstfäll ds Krntstmodlls für andr Tstmodll widrvrwndt wrdn. Nachdm in Mng von Produktn aus dm Produktraum ausgwählt wurd, 62

81 4.2 Dfinition ds Tstvrfahrns Produktraum P1 P0 P8 P2 P5 P6 P4 P7 P3 P9 1. Produktauswahl Auswahlkritrium Untrmng P1 P0 P8 2. Tstmodllgnrirung A P0 A P1 A P8 3. Tstfallrstllung (Dsign) und Widrvrwndung Tstsuit tc1 tc2 tc4 4. Tstfallkatgorisirung tc5 tc3 tc1 tc1 tc3 tc2 tc1 tc2 tc4 tc3 tc5 5. Tstfallslktion Tstplan P0: tc1 Tstplan P1: tc2 tc3 Tstplan P8: tc4 tc5 Tstfalllinfärbung: Widrvrwndbar Invalid Nu Abbildung 4.3: Schmatisch Darstllung dr Tststratgi 63

82 4 Dlta-orintirts Modllbasirts Intgrationststn lassn sich für dis di ntsprchndn Tstmodll gnrirn. Ein Tstmodll ntspricht nach Dfinition inr Softwararchitktur a = (C, Π, Σ) (vgl. in Abbildung 4.3 Schritt 2). Für jds gwählt Produkt wird in solch Softwararchitktur gnrirt, wobi di zu gnrirndn Komponntn, Konnktorn tc. aus dr Faturkonfiguration ds Produkts abglitt wrdn Tstfallrstllung und Widrvrwndung Das Zil diss Schritts ist s, für jds gwählt Produkt in Mng von Tstfälln zu ntwickln, um so in Produktlinintstsuit ts = (tc 1,, tc n ) (vgl. Abbildung 4.3) zu rstlln. Di Tstfallrstllung untrligt in disr Arbit vrschidnn Kritrin. Konnktorabdckung: Dis stllt das primär Abdckungskritrium dar und ntspricht dm Tstndkritrium dr Transitionsabdckung für Automatn und hat zur Folg, dass di Tstfäll für in Produkt jdn Konnktor ds Produkts mindstns inmal travrsirn müssn. Da di Tstfäll in Form von MSCs dfinirt wrdn, muss di darin bschribn Kommunikation di ntsprchndn Konnktorn vrwndn. Intrn Komponntnspzifikation: Di in dn MSCs dargstllt Kommunikation dr Komponntn basirn auf drn intrnn Vrhaltnsbschribungn, di von Sascha Lity [30] in Form von Statcharts [23] in inr frührn Arbit ntwicklt wurdn. Di Statcharts bschribn di intrnn Zuständ, di in Komponnt innhmn kann sowi di vrschidnn Kommunikationsmöglichkitn. Dis binhaltt auch di für di MSCs notwndign Informationn, wi Komponntn auf intrffnd Signal ragirn und wlch Signal Komponntn an andr Komponntn bzw. di Umwlt vrsndn. k-wis Komponntnabdckung: MSCs bschribn stts inn Kommunikationsausschnitt für in Mng von Komponntn. Dis Mng sollt nicht willkürlich gwählt wrdn, sondrn itrativ ntwicklt wrdn. Es wrdn zunächst MSCs für Komponntnpaar ntwicklt. Anschlißnd wrdn witr MSCs mit mhr als zwi Komponntn ntwicklt. Als wich Obrgrnz wird in maximal Anzahl von fünf Komponntn für MSCs gwählt, da sonst di Übrsichtlichkit und Vrständlichkit dr Tstfäll stark lidt. Di Obrgrnz wurd in dr Fallstudi (vgl. Kapitl 6) in sltnn Fälln (z.b. in p3_msc1, sih Anhang) jdoch auch übrschrittn, da s bispilswis in Mng von LEDs für in Komponnt gibt, di nur wnig Kommunikation mit dr dazughörign Komponnt bsitzn und drn Konnktorn sich stark ähnln, so dass si in inm MSC vrwndt wrdn könnn. Di Anzahl dr zu prüfndn Komponntn richtn sich bnfalls nach dm zu prüfndn Tstsznario. Tstfäll mit nur inr Komponnt wrdn trivialrwis nicht rstllt. Tstsznarin wähln: Ein witrs Kritrium für di Erstllung dr MSC ist di Vrmidung inr unnötign großn Zahl von Tstfälln, damit das Tstvrfahrn ffizint blibt. Damit dis rricht wird, wurdn di MSCs so konstruirt, dass si möglichst vil Kommunikationsabschnitt, di inm Tstsznario anghörn, abdckn. Als Bispil si di Bwgung ds Außnspigls durch das HMI gnannt. Dr 64

83 4.2 Dfinition ds Tstvrfahrns Spigl lässt sich in vir Richtungn bwgn. Ein MSC dckt dis vir Richtungn mit inm mal ab, statt vir MSCs zu ntwickln, di jwils gnau in Richtung abdckn, da dr Tstlauf stts in Mng von Eingabn und Ausgabn ist. Man kann das korrkt Vrhaltn also auch mit nur inm MSC prüfn. Natürlich sind Sznarin dnkbar, bi dnn in Auswitung ds Tstsfalls unrwünscht ist, da man inn spzilln Kommunikationsauschnitt tstn will. In inm solchn Fall macht in infachs MSC, das nur disn bstimmtn Til ds Vrhaltns prüft. Positiv Tstfäll: Bi dr Entwicklung dr Tstfäll wrdn ausschlißlich positiv Tstfäll rstllt. Ein positivr Tstfall knnzichnt sich durch di Übrprüfung, ob in durch di Spzifikation vorggbn Kommunikation zwischn dn btiligtn Komponntn auch tatsächlich stattfindt. Ein ngativr Tstfall wär di Übrprüfung, ob zwi odr mhr Komponntn, di kin Kommunikation bsitzn, untr vrschidnn Bdingungn auch wirklich unabhängig voninandr blibn. Drartig Tstfäll sind für di Übrprüfung von Sitnffktn durchaus dnkbar, wrdn in disr Arbit jdoch nicht btrachtt, da di hir vrwndtn MSCs zur Übrprüfung von Kommunikation dinn. Das Kritrium dr Konnktorabdckung müsst für dis Tstfallart bnfalls angpasst wrdn, da di btrachttn Komponntn nicht übr gminsam Konnktorn vrfügn müssn. Ein Stratgi zur Tstfallrstllung für in Produktlinintstsuit kann dmnach wi folgt zusammngfasst wrdn: Das Tstkritrium dr Konnktorabdckung muss für all Produkt rfüllt sin. Di intrn Spzifikation dr Komponntn muss vrwndt wrdn, um di Kommunikation im MSC zu modllirn. Di Tstfäll solltn, falls möglich, all sinnvolln k-wis Komponntnkombinationn abdckn, wobi in Obrgrnz von Komponntn aus Komplxitätsgründn gstzt wrdn sollt. Es wrdn grundsätzlich nur positiv Tstfäll rstllt, di das Vorhandnsin von Kommunikation prüfn. Tstfäll solltn Tstsznarin bschribn, um di Anzahl dr Tstfäll inzugrnzn. Wi in Kapitl 4.1 bschribn, ist in Tstfall tc = (I, Loc, λ, < co ) in MSC. Ein MSC ist dabi immr für in bstimmt Mng von Komponntn dfinirt. MSCs müssn im Vorfld vom Tstdsignr anhand dr Produktspzifikationn, di auch das intrn Komponntnvrhaltn umfasst, für jds Produkt modllirt wrdn. Di MSCs solln nach dm Tstndkritrium dr Konnktorabdckung sowi dn vorgstlltn Kritrin rstllt wrdn. Di Mng allr rstlltn Tstfäll wird in dr Produktlinintstsuit ts = (tc 1,, tc n ) zusammngfasst. Um dis zu rstlln müssn für di Tstzil in Mng von Tstfälln ntwicklt wrdn, di dann in di Produkttstsuit aufgnommn 65

84 4 Dlta-orintirts Modllbasirts Intgrationststn wrdn. Für jds Produkt, bi dm in Tstzil noch nicht rfüllt wird, müssn nu Tstfäll in ts aufgnommn wrdn. Im Bispil aus Abbildung 4.3 wrdn für das Produkt P0 di bidn Tstfäll tc1 und tc2 in di Produktlinintstsuit aufgnommn. Nachdm di witrn Produkt schrittwis btrachtt wurdn, bstht di Produktlinintstsuit aus dn fünf Tstfälln tc1, tc2, tc3, tc4 und tc Tstfallkatgorisirung und Entwicklung inr Produkttstsuit Für di zu tstndn Produkt müssn Tstfäll rstllt wrdn, di für di Produkt rlvant sind. Di Gsamthit allr Tstfäll wird in dr Produktlinintstsuit zusammngfasst. Di Tstfäll wrdn für jds Produkt inr dr dri folgndn Katgorin zugordnt [42]: Nu: Tstfäll di nu rstllt wrdn und für dn Produkttst ausgführt wrdn müssn Widrvrwndbar: Tstfall bstht brits und kann für nun Produkttst widrvrwndt wrdn Invalid: Dr bsthnd Tstfall kann für dn Produkttst nicht widrvrwndt wrdn. Das Tstmodll binhaltt dn Tstlauf nicht: xc(tc i, tm) Tstfäll, di nu rstllt wrdn, wrdn automatisch in di Produkttstsuit ts P ts aufgnommn. Dis konntn für kin andrs zuvor gtstts Produkt angwandt wrdn, da di Komponntn und/odr Konnktorn ds Tstfalls in disn nicht nthaltn warn. Widrvrwndbar Tstfäll wurdn brits für in zuvor gprüfts Produkt rstllt und könnn auch für das aktull gtstt Produkt vrwndt wrdn. Für di Widrvrwndbarkit ins Tstfalls tc = (I, Loc, λ, < co ) für in Tstmodll tm = A H = (C, Π, Σ) wird di Rlation applicabl T C G T M mit applicabl(tc, g, tm) : covrs(tc, g) xc(tc, tm) dfinirt [11]. Damit in Tstfall widrvrwndbar ist, muss r das gfordrt Tstzil g G abdckn und auf dm Tstmodll tm ausführbar sin. Daraus lässt sich implizirn, dass in Tstlauf tr für tc xistirt, dr zu dm Tstlauf tr aus tm äquivalnt ist, so dass tr T R tr gilt. Es gilt [30]: tc ts rus applicabl(tc, g, tm) Tstfäll, di wdr als nu noch widrvrwndbar katgorisirt wurdn, sind invalid und wrdn nicht in di Produkttstsuit ts P aufgnommn. Im Bzug auf das Rgrssionststn ntspricht di Tstfallkatgori invalid dn obsoltn Tstfälln. Ein invalidr Tstfall ist jdoch nur für das Produkt, für wlchs r als invalid ingstuft wurd, nicht vrwndbar. Für andr Produkt kann in solchr Tstfall widr valid sin. Für invalid Tstfäll gilt: 66

85 4.2 Dfinition ds Tstvrfahrns ts\(ts nw ts rus ) = ts invalid wobi ts nw ts di Mng dr nun Tstfäll, ts rus ts di Mng dr widrvrwndbarn Tstfäll ist und ts invalid ts di Tilmng dr invalidn Tstfäll ist. Als Produkttstsuit ts P rgibt sich somit: ts P = ts nw ts rus In Abbildung 4.3 ist zu shn, dass di Produkttstsuit für das Produkt P0 aus dm Tstfall tc1 bstht. Für Produkt P1 kommn di bidn Tstfäll nun Tstfäll tc1 und tc2 zu dm widrvrwndbarn Tstfall tc3 hinzu. Bi Produkt P8 wrdn di bidn nun Tstfäll tc4 und tc5 und dr widrvrwndbar Tstfall tc3 in di Tstsuit aufgnommn. Di Tstfäll tc1 und tc2 wrdn hinggn als invalid ingstuft und sind dshalb nicht in dr Produkttstsuit nthaltn. Nachdm für jds Produkt in Produkttstsuit rstllt wurd, wird in Tstfallslktion durchgführt, um dn Tstaufwand zu vrringrn Tstfallslktion und Tstplanrstllung Das Zil ds Tstvrfahrns ist s, nbn dr Entwicklung in Produkttstsuit für di slktirtn Produkt, di Anzahl dr tatsächlich auszuführndn Tstfäll zu minimirn. Zu dism Zwck wird in Tstfallslktion angwndt, di aus dn widrholbarn Tstfäll nur dijnign für dn Produkttstplan tp auswählt, di rnut ausgführt wrdn müssn. Im Rahmn disr Arbit sind Rtsts von widrholbarn Tstfälln immr dann notwndig, wnn sich di Schnittstlln inr odr mhrrr im Tstfall vrwndtn Komponntn gändrt hat. Di Ändrung bziht sich auf di Produktvariantn, für di dr ntsprchnd Tstfall brits vrwndt wurd. Findt in Ändrung inr odr mhrrr Komponntnschnittstlln statt, di in disr Art vorhr noch nicht aufgtrtn sind, muss in Rtst durchgführt wrdn. So kann sichrgstllt wrdn, dass s zu kinn ungwolltn Fatur-Intraktionn kommt. Tstfäll, di nicht für dn Rtst bstimmt wurdn, müssn nicht rnut ausgführt wrdn, da das ntsprchnd Vrhaltn brits in inm vorhrign Produkt gtstt wurd und s zu kinn binflussndn Vrändrungn in dr Produktspzifikation kam. Dis Tstfäll wrdn nicht in dn Produkttstplan aufgnommn. Dr Tstplan stzt sich also aus dr Tstfallmng ts rtst ts rus zusammn. Innrhalb dr Produkttstsuit kann s zu rdundantn Tstfälln kommn, d.h. Tstfälln, di das glich Tstzil abdckn. In disr Arbit wär dis di Konnktorabdckung. In dism Fall wär s möglich, di Anzahl dr Tstfäll witr zu minimirn, indm rdundant Tstfäll rknnt, um so in minimal Tstsuit zu ntwickln. Diss Problm ist jdoch NP-vollständig [25], was s äußrst inffizint macht, di minimal Mng von Tstfälln zu findn. Aus dism Grund wird in dr Arbit davon ausggangn, dass brits bim manulln Entwickln dr Tstfäll durch dn Tstdsignr rdundant Tstfäll sowit möglich vrhindrt wrdn odr nur in gringr Zahl auftrtn. Bi inr automatischn Tstfallgnrirung müsstn 67

86 4 Dlta-orintirts Modllbasirts Intgrationststn praktikabl Mthodn gfundn wrdn, um Rdundanz ntwdr zu vrmidn odr bi dr Tstplanrstllung zu rknnn. 68

87 5 Wrkzugimplmntirung Nachdm di formaln Grundlagn für in dlta-orintirts Intgrationststvrfahrn für SPLs dfinirt wurdn, soll in dism Kapitl di Entwicklung ins gigntn prototypischn Wrkzugs zur Gnrirung dr Tstmodll dr Produkt inr Softwarproduktlini bschribn wrdn. Dazu wrdn zunächst di Anfordrungn an in solchs Wrkzug rmittlt. Im Anschluss wird auf di konkrt Implmntirung und di dazu vrwndtn Tools und Framworks inggangn. Im Rahmn dr Implmntirung wird auch di Softwararchitkturbschribungssprach Dltarx dtaillirt bschribn, mit drn Hilf di txtull Architkturdfinition rfolgt. Zultzt wird di Vrwndung ds Wrkzugs bschribn. 5.1 Anfordrungn Zunächst solln di Anfordrungn, di an das zu ntwicklnd Wrkzug gstllt wrdn, idntifizirt wrdn. Hirfür wrdn di gwünschtn Funktionalitätn rmittlt. Di Darstllung dr Anfordrungn rfolgt in Form von Us Cass, di widrum in di bidn Prozss ds Domain Enginrings und Application Enginrings [46] untrglidrt wrdn. In Abbildung 5.1 ist das Us Cas Diagramm ds Domain Enginrings dargstllt. Domain Enginring Dltarx Krnarchitktur dfinirn Dltas dfinirn Anwndr Abbildung 5.1: Us Cas ds Domain Enginrings 69

88 5 Wrkzugimplmntirung Im Domain Enginring soll di Möglichkit ggbn sin, Artfakt zu dfinirn, di spätr für dn Tstprozss widrvrwndt wrdn könnn. Gnaur gsagt soll s dm Anwndr möglich sin, in Krnarchitktur txtull zu dfinirn und zu spichrn. Dr Nutzr kann auch mhrr Krnarchitkturn dfinirn. Di Bschribung disr rfolgt durch di von dr ADL vorggbnn Konstrukt, mit dr di inzlnn Architkturbstandtil dfinirt wrdn solln. Nbn dr Krnarchitktur solln Anwndr Dltas dfinirn könnn, di Transformationn auf dr Krnarchitktur bschribn, um nu Produkt inr SPL zu gnrirn. Dazu müssn di ntsprchndn Bdingungn dr Dltas dfinirt wrdn. Dltas wrdn bnfalls txtull durch di ADL bschribn. Im anschlißndn Application Enginring solln di im Domain Enginring dfinirtn Artfakt vrwndt wrdn. Das Us Cas hirfür ist in Abbildung 5.2 dargstllt. Application Enginring Dltarx Tstmodll gnrirn <<uss>> <<uss>> Krnarchitktur und Faturmodll wähln Fatur- Konfiguration wähln Anwndr Abbildung 5.2: Us Cas ds Application Enginrings Hirbi soll s möglich sin in Tstmodll zu gnrirn. Diss wird auf Basis dr Krnarchitkturund inr dazu anggbnn Faturkonfiguration gnrirt. Daraufhin wird in Mng von Dltas, di nbn dr Krnarchitktur dfinirt wurdn, anhand ihrr Application Condition ausgwählt, di anschlißnd durch di anggbnn Transformationn das Tstmodll gnrirn. Das Wrkzug soll zusätzlich rwitrbar sin. Dis btrifft di Sprachlmnt, di durch das Wrkzug zur Vrfügung gstllt wrdn. Möglich Erwitrungn dr Funktionalität wärn bispilswis in automatisch Auswahl von passndn Tstfälln und drn Ausführung. Auch in automatisirt Tstfallgnrirung könnt in angstrbt Wrkzugrwitrung sin. Dis könnt im Rahmn zukünftigr Arbitn gschhn, di auf dm Systm aufbaun. 70

89 5.2 Ralisirung und Implmntirung Dr angstrbt Arbitsablauf ds Wrkzugs wird in Abbildung 5.3 illustrirt. In dr Abbildung ist zu rknnn, dass zunächst di Dfinition inr Krnarchitk- Krnarchitktur dfinirn Dltas dfinirn Fatur- Konfiguration wähln Tstmodll gnrirn Abbildung 5.3: Arbitsablauf im Wrkzug Dltarx tur rfolgn soll. Dis gschiht txtull übr inn igns britgstlltn Editor. Zusätzlich könnn Dltas, di auf dr Krnarchitktur angwndt wrdn solln, dfinirt wrdn. Ist dis gschhn, soll s dm Anwndr möglich sin, in Faturkonfiguration auszuwähln, anhand drr dann im ltztn Schritt in automatisch Tstmodllgnrirung in Form inr validn Softwararchitktur gschiht. Di vrschidnn Abläuf solln durch das Wrkzug tchnisch ralisirt wrdn. Di konkrt Wrkzugimplmntirung wird im nächstn Abschnitt bschribn. 5.2 Ralisirung und Implmntirung Das Wrkzug soll in Form ins Plugins für di Eclips-IDE [54] ralisirt wrdn. Eclips untrstützt di Pluginntwicklung durch gignt Vorlagn und in igns Framwork, da Eclips slbst in Komposition aus viln vrschidnn Framworks darstllt. Das ntwicklt Plugin bstht aus dm Dltarx-Editor und inm Wizard zur Tstfallgnrirung. Dr konzptionll Aufbau ds Plugins ist in Abbildung 5.4 grafisch dargstllt. Dltarx-Plugin DltaMBT Editor - Krnarchitkturdfinition - Dltadfinition - Komfortfunktionn Wizard - Konfigurationsauswahl - Tstmodllgnrirung Configuration Rpository Faturmodll Abbildung 5.4: Aufbau ds Plugins Das Plugin stzt sich wi in Abbildung 5.4 zu shn aus dm Editor zur Modllirung dr Krnarchitktur und dr Dltas sowi dm Wizard zur Tstmodllgnrirung zusammn. Dr Wizard vrwndt nbn dr Dfinition ds Krns und dr 71

90 5 Wrkzugimplmntirung Dltas zusätzlich das Konfigurationsrpository und di Faturmodllbschribung ds Plugins DltaMBT von Sascha Lity [30]. Mit Hilf ds Editors soll s dm Anwndr rmöglicht wrdn, in Krnarchitktur sowi in Mng von Dltas für dis Architktur txtull zu bschribn. Als Grundlag dint di Dltarx-Grammatik (vgl. Listing 3.8). Für di Ralisirung inr ignn Sprach und ntsprchndn Editorn sthn vrschidn Plugins zur Vrfügung, für di im Rahmn disr Arbit zunächst di Framworks EMFTxt [5] und XTxt [1] auf Grund ihrr Anpassung an Eclips nähr btrachtt wrdn. Für di Ralisirung wird das XTxt-Framwork vrwndt. XTxt lifrt di Skriptsprach Xtnd mit, di s dm Nutzr rlaubt, inn Echtzit-Codgnrator für dn Sprachnditor zu implmntirn. In dr Arbit wird auf dn Einsatz von Xtnd vrzichtt, da di Gnrirung dr Produkttstmodll durch dn Einsatz ins Wizards gschhn soll. Ein Wizard wird dshalb ingstzt, da nbn dr Dfinition inr Krnarchitktur und dr dazughörign Dltas auch di Angab inr Produktkonfiguration bnötigt wird, di in inr xtrn dfinirtn Dati vorligt. XTxt rlaubt di Dfinition inr formaln Grammatik, für di dann in ignständigr Editor automatisch durch das Framwork und dn Einsatz dr Modling Workflow Engin 2 [1] gnrirt wird. Dr MWE2-Workflow ist in konfigurirbarr Gnrator, dr für XTxt-Projkt vrwndt wrdn kann und u.a. di Klassn und Mthodn für in dfinirt Grammatik sowi dn Sprachnditor rzugt. Dr rsultirnd Editor vrfügt übr Faturs wi z.b. Syntax-Highlighting, Autovrvollständigung, Fhlrbnachrichtigung uvm. Zusätzlich vrwndt XTxt das Eclips Modling Framwork (EMF) [14]. Das EMF stllt in Eclips- Framwork dar, mit dssn Hilf Anwndungn auf Basis von strukturirtn Datnmodlln ntwicklt wrdn könnn. Nbn dr Modllbschribung wrdn auch Gnratorn zur automatischn Codrzugung mitglifrt. Durch di Vrwndung von EMF innrhalb von XTxt, kann dr Abstract Syntax Tr (AST) für di inzlnn EMF-Objkt, di in dr Sprach dfinirt sind, zur Produktgnrirung vrwndt wrdn. Dr Nutzr kann mittls ds automatisch gnrirtn Editors in txtull Bschribung inr Softwararchitktur vornhmn, di dann zur Tstmodllgnrirung für di inzlnn Produkt inr SPL vrwndn wrdn könnn. Zusätzlich ist s möglich, im Editor Dltas für in Krnarchitktur zu dfinirn, di dann für in bstimmt Faturkonfiguration angwndt wrdn. Dr Plugintil ds Editors umfasst di folgndn Pakt: org.xtxt.dltarx: Enthält di Dfinition dr Grammatik und dr automatisch gnrirtn EMF-Klassn org.xtxt.dltarx.tsts: Bitt di Möglichkit optional Tsts zu vrfassn org.xtxt.dltarx.ui: Stllt dn Sprachnditor brit und vrwaltt Elmnt dr Eclips-Workbnch Nbn dr Britstllung ins Editors zur Dfinition dr Architkturn und Dltas wird übr dn zwitn Plugintil in Wizard zur Produktgnrirung britgstllt. 72

91 5.2 Ralisirung und Implmntirung Disr wird im Pakt dltarx.wizard dfinirt und ist übr das Kontxtmnü von Eclips zu rrichn untr dm Punkt Architctur Gnration - Dltarx Gnrator. Darin wrdn vrschidn Paramtr gfordrt, um anschlißnd für in bstimmt Produktkonfiguration in nu, valid Architktur in Dltarx zu gnrirn. Im nächstn Abschnitt wird di in XTxt dfinirt Sprach zur Bschribung von Softwararchitkturn und Dltas dtaillirt bschribn. Dazu wrdn di formaln Konstrukt zur Grammatikdfinition vorgstllt und darauf aufbaund di Grammatik dr Sprach Dltarx dfinirt Dfinition dr Grammatik in XTxt Auf Basis dr formaln Bschribung aus dm vorhrign Kapitl wurd in Grammatik für in ADL untr Vrwndung ds XTxt-Framworks dfinirt [1]. Um di Grammatik bschribn zu könnn, solln zunächst di von XTxt britgstlltn Syntaxkonstrukt vorgstllt wrdn. Im Anschluss wird di Grammatik und drn Vrwndung im Dtail bschribn. XTxt Syntax Ein XTxt-Grammatik bginnt immr mit inr Sprachdfinition. Dis gibt dn Namn dr Sprach an. Zusätzlich kann di Grammatik dr Sprach Syntaxlmnt inr andrn Grammatik rbn. Dis wird als grammar mixin bzichnt [1]. Ein Codfragmnt, bi dm in Sprach MyADL di Grammatikrgln dr Grammatik org.clips.xtxt.common.trminals rbt, könnt bispilswis wi folgt dfinirt sin: 1 grammar org. xtxt. xampl. MyADL 2 with org. clips. xtxt. common. Trminals Listing 5.1: Sprachdfinition in XTxt Anschlißnd kann durch das Schlüsslwort gnrat anggbn wrdn, dass für di Grammatik in ntsprchnds Ecor-Mtamodll anglgt wird. Diss stammt aus dm Eclips Modling Framwork (EMF) [14]. Anhand diss Modlls kann in Zugriff auf di vrschidnn Klassn und Objkt dr Grammatik und dr damit vrfasstn Softwararchitkturn gwährlistt wrdn. Das folgnd Codfragmnt fordrt di Gnrirung an: 1 gnrat myadl http :// www. clips. org /myadl Listing 5.2: Gnrirung ds Ecor-Modlls Di Grammatik slbst wird durch in Rih von Rgln anggbn. Rgln bsitzn inn indutign Namn, gfolgt auf inn Dopplpunkt dr dn Rglkopf abschlißt. Nach dm Dopplpunkt wird di Rgldfinition anggbn. Als Rglabschluss wird in Smikolon gstzt. Di rst Rgl inr Grammatik wird als Einstigspunkt rkannt und sollt andr Rgln aufrufn. Ein infach Rgl kann wi folgt dfinirt sin: 73

92 5 Wrkzugimplmntirung 1 Rul : 2 nam =ID; Listing 5.3: Bispilrgl für IDs Mit nam wird in Variabl bschribn, di im Ecor-Modll dr Grammatik vrwndt wird. In disr Rgl wird nam in ID zugwisn. Dabi handlt s sich um in von dr grbtn Grammatik org.clips.xtxt.common.trminals vorggbn Rgl, di auf inn in dr Programmirung gültign Variablnnamn vrwist, d.h. r darf z.b. nicht mit inr Zahl bginnn odr Lrzichn nthaltn. Zur Dfinition inr Rgl stllt XTxt in Rih witrr Opratorn zur Vrfügung. Dis solln anhand von kurzn Bispiln rläutrt wrdn: - Oprator: In Hochkomma gknnzichnt Txt wrdn als Zichnktt intrprtirt und vrlangn an dr gwünschtn Stll xakt dis Zichnktt als Eingab. Bispil: 1 RulString : 2 HlloWorld ; Listing 5.4: Bispilrgl für Txtingabn - Oprator: Das -Symbol gibt an, dass in Entschidung stattfindt, d.h. di Rgl kann dn linkn odr rchtn Til ds Oprators annhmn. Bispil: 1 Rul : 2 anothrrul i n t ; Listing 5.5: Bispilrgl für Odr Dis Rgl würd ntwdr in andr Rgl aufrufn (anothrrul) odr si rfordrt, dass dr Nutzr dn Txt int schribt. Das Bispil macht auch dutlich, dass Rgln andr Rgln aufrufn könnn. Auch Rkursion ist möglich, dis darf jdoch nicht linksrkursiv sin. Das bdutt, dass in Rgl, di sich slbst rkursiv aufruft, dis nicht tun darf, ohn vorhr in andrs Elmnt zu lsn bzw. in andr Rgl aufzurufn. Es ist also nicht gstattt di linksrkursiv Rgl 1 Rul : 2 Rul nam ; Listing 5.6: Linksrkursiv Rgl zu dfinirn. Es wär jdoch rlaubt in Rgl in inr dr folgndn Formn rkursiv zu dfinirn: 1 Rul : 2 OthrRul Rul nam ; 74

93 5.2 Ralisirung und Implmntirung 3 RulTwo : 4 nw RulTwo OthrRul ; Listing 5.7: Rkursiv Rgln? - Oprator: XTxt rmöglicht s Til inr Rgl als optional zu knnzichnn. Dis gschiht durch das?-symbol. Es bziht sich auf dn unmittlbar davor dfinirtn Rglabschnitt. Längr Ausdrück solltn also durch Klammrn gknnzichnt wrdn. Ein Bispil für inn optionaln Rgltil si wi folgt dfinirt: 1 Rul : 2 ( nam )? nam =ID ; Listing 5.8: Bispilrgl für Optional Angabn Dis Rgl dfinirt inn Namn dr inr ID ntsprchn muss. Zusätzlich kann vor dn Namn das Schlüsslwort nam gschribn wrdn, s muss jdoch nicht. += und * - Opratorn Di Zuwisung von Variabln rfolgt bkanntrmaßn durch das =-Symbol. Es ist jdoch auch möglich, in Mng von Zuwisungn zu rlaubn, z.b. wnn man inr Wbsit in Mng von Autorn zuwisn möcht. Dis wird durch das zusätzlich +-Symbol bi inr Zuwisung rmöglicht, wlchs das Hinzufügn mhrrr Objkt rlaubt. Um das Bispil zu Vrvollständign wird noch dr *-Oprator bnötigt, wlchr für blibig Anzahl stht. Ein Bispil si wi folgt ggbn: 1 Rul : 2 authors += Author *; Listing 5.9: Bispilrgl für Aufzählungn Es wird also fstglgt, dass s in Mng von Autorn (authors) gibt, dnn in blibig Anzahl von Autorn (Author*) zugwisn wrdn kann. Ein blibig Anzahl binhaltt auch kin Autorn, d.h. dn Wrt 0. Soll s mindstns in Zuwisung gbn, kann statt * in +-Symbol vrwndt wrdn. Es gilt zu bachtn, dass Author auf in Rgl vrwist, di bnfalls implmntirt sin muss, damit das Bispil fhlrfri ist. [] - Oprator: Bi dr Zuwisung inr Variabln ist s auch möglich, auf in Elmnt inr Rgl zu vrwisn. Dis gschiht durch dn Einsatz von ckign Klammrn. Im folgndn Bispil kann bi inm Buch zusätzlich in Autor anggbn wrdn, dr jdoch zuvor brits anglgt sin muss. 1 Rul : 2 booktitl = ID ( xtnds authornam = [ Author ])? Listing 5.10: Bispilrgl für Rfrnzirungn 75

94 5 Wrkzugimplmntirung Rgln dr Grammatik Durch di im vorhrign Abschnitt bschribnn Syntaxlmnt wird di ADL Dltarx auf Basis dr kontxtfrin Grammatik, di in Kapitl 3.4 dfinirt wurd (Vgl. Listing 3.8), als XTxt-Grammatik vrfasst. Im Folgndn wird di Dfinition dr Sprach anhand dr inzlnn XTxt-Rgln bschribn und drn smantisch Bdutung rklärt. 1 Dltarx : 2 a r c h i t c t u r nam =ID 3 for faturmodl fmdir = STRING { 4 ( s i g n a l s { ( s i g n a l s += Signal )* } )? 5 & ( componnts { ( componnts += Componnt )* } )? 6 & ( c o n n c t o r s { ( c o n n c t o r s += Connctor )* } )? 7 & ( d l t a s { ( d l t a s += Dlta )* } )? 8 & } ; Listing 5.11: Einstigsrgl dr Dltarx-Grammatik Di Einstigsrgl hißt bnso wi di Sprach Dltarx und gibt di Grundstruktur dr Architkturbschribung vor. Ein Architktur wird durch das Schlüsslwort architctur inglitt und bsitzt stts inn Namn. Ein Architktur muss mit inm Faturmodll vrknüpft wrdn. Dazu wird di Variabl fmdir gnutzt, di als Input in Zichnktt bnötigt. Dis soll bi dr Architkturdfinition dn Pfad dr Faturmodllbschribung nthaltn. Di Faturmodllbschribung rfolgt in Form dr von Lity [30] dfinirtn Faturmodll-Konfiguration als.faturmodl-dati. Zusätzlich bsitzn Architkturn in Mng von Signaln, Konnktorn, Komponntn und Dltas. Dis Elmnt sind all optional, d.h. di Architktur kann rin thortisch auch lr sin bzw. inm lrn Krnmodll ntsprchn [50]. Sämtlich Elmnt könnn in blibigr, ndlichr Anzahl auftrtn. Si müssn jdoch nachinandr anglgt wrdn, d.h. s müssn all Signal zusammn dfinirt wrdn, anschlißnd all Komponntn usw. Es gilt zu bachtn, dass in Softwararchitktur nach dr Dfinition aus Kapitl 3.1 bnfalls in Softwarkomponnt rpräsntirt. Dis wird durch di spätr Produktgnrirung umgstzt. Signal wrdn durch das Schlüsslwort signals inglitt und wrdn durch di folgnd Rgl bschribn: 1 Signal : 2 nam =ID typ = SignalTyp ; Listing 5.12: Rgl zur Signaldfinition Si bsitzn inn Namn und inn Typ. Dr Typ ist wi folgt dfinirt: 1 SignalTyp : 2 boolan char i n t doubl ; Listing 5.13: Rgl dr Signaltypn 76

95 5.2 Ralisirung und Implmntirung Signal könnn dahr di Typn boolan, char, intgr und doubl bsitzn. Es ist anzumrkn, dass dis nur in smantisch Angab ds gwähltn Typs ist. Um Komponntn zu dfinirn wird das Schlüsslwort componnts vrwndt. Komponntndfinitionn wrdn durch di folgnd Rgl spzifizirt: 1 Componnt : 2 nam =ID { 3 ( p o r t s { 4 p o r t s += Port * 5 } )? 6 ( subcomponnts { 7 subcomponnts += Componnt * 8 } )? 9 } ; Listing 5.14: Rgl zur Komponntndfinition Komponntn bsitzn stts inn Namn. Zusätzlich könnn optional in Mng von Ports und in Mng von Subkomponntn anggbn wrdn. Das Elmnt dr Ports wird im Vrglich zu dr in Kapitl 3.4 bschribn formaln Dfinition nu ingführt, damit dn Softwararchitktn, di di Sprach vrwndn wolln, in aus andrn ADLs bkannts Konstrukt zur Vrfügung stht [39]. Ports rmöglichn s di Komponntnschnittstlln xplizit zu dfinirn. Ports wrdn durch das Schlüsslwort ports inglitt, Subkomponntn durch subcomponnts. Di Subkomponntn lign hirarchisch automatisch in dr Komponnt, in dr si dfinirt wrdn. Di Rgl dr Subkomponntn ntspricht dr dr Komponntn, d.h. di Rgl wird rkursiv aufgrufn, so dass Subkomponntn widr Subkomponntn bsitzn könnn. Für di Dfinition dr Ports wird folgnd Rgl dfinirt: 1 Port : 2 dirction = PortDirction nam =ID ( s i g n a l =[ Signal ])?; Listing 5.15: Rgl zur Portdfinition Einm Port muss zunächst in Richtung zugwisn wrdn, d.h. s muss anggbn wrdn, ob dr Port sndt odr mpfängt. Dazu wird di Rgl PortDirction vrwndt. Als dritt Richtungsmöglichkit kann in Port als Dlgation Port dfinirt wrdn [43]. Ein solchr Port litt Signal von inr Komponnt zu inr Subkomponnt witr bzw. umgkhrt. Dis rmöglicht in Hirarchiübrgrifnds Sndn und Empfangn. 1 PortDirction : 2 in out d l g a t i o n ; Listing 5.16: Rgl dr Portrichtung Di Richtungsangab muss dmnach in, out odr dlgation lautn. Anschlißnd muss dm Port in indutigr Nam ggbn wrdn. Als optionals Elmnt kann inm Port in Signal zugwisn wrdn, d.h. s wird fstglgt, wlchs Signal 77

96 5 Wrkzugimplmntirung dr Port sndt bzw. mpfängt. Ports untrstützn laut Dfinition stts nur in Signal. Soll in Komponnt mhrr Signal übrtragn könnn, so müssn für jds Signal nu Ports dfinirt wrdn. Erfolgt für inn Port kin Signalzuwisung, so kann dis zu inm spätrn Zitpunkt durch di Dfinition ins Konnktors gschhn. Für Konnktorn sthn zwi Dfinitionsrgln brit, wobi bid untr dr von Dltarx aufgrufnn Rgl Connctor zusammngfasst sind: 1 Connctor : 2 nam = ID typ =( ConnctorTypOn ConnctorTypTwo ); Listing 5.17: Rgl dr Konnktordfinition Dr Grund für di Aufsplittung in zwi vrschidn Dfinitionsrgln ist di Möglichkit, inn Konnktor zwischn zwi Komponntn und drn Ports mit Angab dr zu übrtragndn Signal zu dfinirn. Wird diss Variant gwählt, muss bi dr Produktgnrirung gprüft wrdn, ob di Ports das ntsprchnd Signal übrtragn. Es ist jdoch auch möglich, dass dn Ports bi dr Erstllung kin Signal zugwisn word. Dann wird das Signal durch di Konnktorrstllung dn ntsprchndn Ports zugwisn. Di Rgl dafür lautt wi folgt: 1 ConnctorTypOn : 2 ( sourc = ID 3, portnamon =( ID EnvironmntMssag ) 4, signaltypon =[ Signal ] 5, signaltyptwo =[ Signal ] 6, portnamtwo =( ID EnvironmntMssag ) 7, dstination = ID ) ; Listing 5.18: Erst Konnktorrgl Bi dism Konnktortyp handlt s sich um in 6-Tupl, bi dm zunächst di Sourckomponnt, also dr Sndr, fstglgt wrdn muss. Anschlißnd wird anggbn, übr wlchn Port di Sourckomponnt sndn soll. Im Anschluss wrdn zwi Signal dfinirt. Dis widrspricht dr Auffassung, dass in Konnktor nur in Signal übrträgt, wlch dnnoch korrkt ist. Zwi Signalangabn wrdn bnötigt, da in Signal bi zwi Komponntn untrschidlich bnannt sin kann, abr dnnoch di glich Information transportirt. Aus Kompatibilitätsgründn ist s notwndig zwi Signal glichn Typs anzugbn, da dr Konnktor kin Informationstransformation vornimmt sondrn dis ldiglich transportirt. Äquivalnt zur Sourckomponnt müssn zultzt noch dr mpfangnd Port sowi di dazughörig mpfangnd Targtkomponnt fstglgt wrdn. Bi dr Angab dr Ports ist s trivialrwis notwndig Ports zu wähln, di Til dr vom Konnktor vrwndtn Komponntn sind. Di zwit Möglichkit inn Konnktor zu dfinirn rfolgt ohn di Angab dr gnutztn Ports. Das bdutt, dass in Konnktor durch zwi Komponntn und dn zu übrtragndn Signaln anggbn wird, ohn fstzulgn, wlch Ports dr 78

97 5.2 Ralisirung und Implmntirung Konnktor vrwndt. Wird disr Ansatz gwählt, wird bi dr Tstmodllrstllung für di zu übrtragndn Signal automatisch in ntsprchndr Port bi dn Komponntn gnrirt, dr das Signal sndt bzw. mpfängt. Es gilt, dass di Signal dn glichn Typ bsitzn müssn. Di ntsprchnd Rgl lautt: 1 ConnctorTypTwo : 2 ( sourc = ID 3, sourcsignal =[ Signal ] 4, dstinationsignal =[ Signal ] 5, dstination = ID ) ; Listing 5.19: Zwit Konnktorrgl Di Konnktordfinition ähnlt dr rstn, s fhln jdoch wi brits bschribn di Angabn dr bidn Ports. Dahr handlt s sich um in 4-Tupl, bi dm di Sourckomponnt, das gsndt sowi das mpfangn Signal und di Targtkomponnt anggbn wrdn müssn. Mit dn bschribnn Rgln lässt sich in hirarchisch Softwararchitktur dfinirn. Es ist jdoch noch nicht möglich Variabilität anzugbn. Dazu wird in virts Elmnt ingführt, mit dm Dltas dfinirt wrdn könnn. Di Dltas umfassn di in Kapitl 3 bschribnn Transformationsmöglichkitn, um witr Produkt inr SPL anhand inr Krnarchitktur zu gnrirn. 1 Dlta : 2 nam =ID ( a f t r a f t r += ID )? whn appcon = STRING { 3 ( addcomponnt { 4 ( nwcomponnt += DltaAddComponnt )* 5 } )? 6 ( rmovcomponnt { 7 ( rmovcomponnt += DltaRmovComponnt )* 8 } )? 9 ( addsignal { 10 ( nwsignal += Signal )* 11 } )? 12 ( rmovsignal { 13 ( rmovsignal += [ Signal ])* 14 } )? 15 ( addconnctor { 16 ( nwconnctor += DltaAddConnctor )* 17 } )? 18 ( rmovconnctor { 19 ( rmovconnctor += DltaRmovConnctor )* 20 } )? 21 ( addport { 22 ( nwport += DltaAddPort )* 23 } )? 79

98 5 Wrkzugimplmntirung 24 ( rmovport { 25 ( rmovport += DltaRmovPort )* 26 } )? 27 } ; Listing 5.20: Rgl zur Bschribung ins Dltas Jds Dlta bsitzt inn Namn. Zusätzlich kann in optional aftr-bdingung hinzugfügt wrdn, wlch fstlgt, wlch Dltas zuvor ausgführt wrdn müssn, damit diss Dlta angwndt wrdn kann. Anschlißnd muss in Application Condition anggbn wrdn, di bstimmt, bi wlchr Faturkonfiguration das Dlta angwndt wrdn soll. Ein Application Condition wird in Dltarx als String anggbn, dr dann übr di Variabl appcon rfrnzirt wrdn kann. Für di Application Condition wurd kin igns Rglkonstrukt dfinirt, da diss linksrkursiv gwsn wär, was zu inr komplxrn Rglstruktur gführt hätt. Bi inr tstwisn Implmntirung kam s zu Problmn mit dr Rfrnzirung dr inzlnn Faturs. Dahr wurd in Angab als Zichnktt als Lösung gwählt. Faturs wrdn innrhalb ds Strings durch AND und NOT mitinandr vrknüpft. Bi dr Produktgnrirung wird di Zichnktt und di darin anggbnn Faturs intrprtirt und ausgwrtt. Di Transformationn, di in Dlta vrwndn kann, sind in add und rmov- Transformationn (vgl. Kapitl 3.3) untrschidbar. Es könnn jwils Komponntn, Signal, Ports, Subkomponntn und Konnktorn hinzugfügt und ntfrnt wrdn. Signal wrdn in Dltarx stts global dfinirt, wshalb ihr Transformationn dirkt in dr Dlta-Rgl bschribn sind. All andrn Elmnt könnn jdoch auch hirarchisch dfinirt wrdn. Dahr wurdn di sparatn Transformationsrgln aus Listing 5.21 dfinirt. 1 DltaAddPort : 2 p o r t = Port in portcomponnt = ID; 3 DltaRmovPort : 4 portnam = ID i n portcomponnt = ID; 5 DltaAddComponnt : 6 componnt = Componnt ( i n suprcomponnt = ID )?; 7 DltaRmovComponnt : 8 componnt = ID ( i n suprcomponnt = ID )?; 9 DltaAddConnctor : 10 connctor = Connctor ( i n suprcomponnt = ID )?; 11 DltaRmovConnctor : 12 connctor = ID ( i n suprcomponnt = ID )?; Listing 5.21: Transformationsrgln Di Rgln bsitzn di glich Grundstruktur. In jdr Rgl kann optional übr das Schlüsslwort in in Suprkomponnt anggbn wrdn, in dr di Transformation stattfindn soll. Ansonstn wrdn nu Elmnt übr di brits bschribn 80

99 5.2 Ralisirung und Implmntirung Rgln Componnt, Connctor, Port und Signal dfinirt. Zu ntfrnnd Elmnt wrdn übr inn Namn rfrnzirt. Basirnd auf dr vorgstlltn Grammatik, wird übr dn MWE2 -Workflow dr Editor für di Sprach Dltarx gnrirt. Disr Editor stllt dn für dn Nutzr sichtbarn Til dr Sprachimplmntirung dar. Ein Scrnshot ds Editors mit inr göffntn Architkturbschribung ist in Abbildung 5.5 dargstllt. Abbildung 5.5: Scrnshot ds Dltarx-Editors An dm Scrnshot ist zu rknnn, das Schlüsslwörtr automatisch hrvorghobn wrdn (Syntax-Highlighting) und das di inzlnn Elmnt auch in dr Outlin ds Editors in EMF-Darstllung vorlign. Dr Editor ist dirkt in di Eclips- Workbnch intgrirt und kann mit inm Datntyp, in dr Arbit.darx, vrknüpft wrdn Implmntirung ds Wizards Dr Wizard wurd mit Hilf ds Eclips UI -Framworks, dass di nötign Datnstrukturn und Klassn für inn solchn Wizard britstllt, in Java implmntirt. Ein Scrnshot ds Wizards ist in Abbildung 5.6 zu shn. Dr Aufruf ds Wizards rfolgt übr das Eclips-Mnü Fil - Nw - Othr - Architctur Gnration - Dltarx Gnrator. Dr Wizard vrwndt in WizardPag, d.h. r bstht aus gnau inr Sit, di di ntsprchndn Eingabfldr aus Abbildung 5.6 nthält. Innrhalb ds Wizards wurdn di folgndn Eingabfldr implmntirt: Cor Architctur and Dltas: In dism Eingabfld soll dr Anwndr dn Pfad zu inr validn Softwararchitkturbschribung in Dltarx- Grammatik angbn. Es kann übr inn SlctionListnr bzw. Auswahlmnü in.darx-dati ausgwählt wrdn. Dis sollt nbn inr Krnarchitktur auch ntsprchnd Dltas nthaltn, di zur Produktgnrirung bnötigt wrdn. 81

100 5 Wrkzugimplmntirung Abbildung 5.6: Scrnshot ds Dltarx Wizards für Eclips Sav location: Disr Paramtr rfordrt di Angab ds Spichrpfads für das zu rstllnd Tstmodll. Auch dis wird übr in Auswahlmnü rmöglicht. Configuration Rpository: An disr Stll soll dr Anwndr dn Pfad zu inr.configmanagmnt-dati angbn. Sascha Lity [30] hat disn Datntyp in sinr Mastrarbit dfinirt und das Wrkzug DltaMBT ntwicklt, mit dssn Hilf drartig Konfigurationsrpositoris rstllt wrdn könnn. Das Rpository nthält in Mng von Faturkonfigurationn für in bnfalls anggbns Faturmodll. Choos a Productconfiguration: Das ltzt Paramtrfld ds Wizards ist vor dr Angab ins Konfigurationsrpositoris daktivirt. Erst nach dr Angab inr.configmanagmnt-dati wird di Dropdown-List aktivirt. Si nthält di Namn allr im Rpository anggbnn Konfigurationn. Dr Anwndr muss in disr Konfigurationn wähln. Es wird damit fstglgt, wlchs Produkttstmodll durch dn Wizard gnrirt wrdn soll. Es kann stts nur in Produkt auf inmal gnrirt wrdn. Wurdn all Paramtr anggbn, kann di Produktgnrirung durch inn Klick auf dn Knopf Finish gstartt wrdn. 82

101 5.2 Ralisirung und Implmntirung Für di Produktgnrirung wurd di Klass ProductGnrator implmntirt. Si vrwndt sämtlich Inputs ds Wizards, um daraufhin in valids Produkttstmodll anhand dr vom Anwndr gwähltn Produktkonfiguration zu gnrirn. Bvor di Tstmodllgnrirung bginnt, wird zunächst gprüft, ob di gwählt.darx-architktur das slb Faturmodll (vgl. Listing 5.11, Zil 3) vrwndt wi das gwählt Konfigurationsrpository. Dis gschiht übr das Mthod ChckFM- Consistncy, di in dr Klass ConfigChckr implmntirt ist. Di Mthod ist in Listing 5.22 aufgführt. 1 public b o o l a n chckfmconsistncy (){ 2 if (( fmarch!= null ) && ( fmconf!= null )){ 3 if( fmarch. gtblongtospl (). quals 4 ( fmconf. gtblongtospl ())){ 5 rturn tru ; 6 } 7 } 8 rturn fals ; 9 } Listing 5.22: Mthod chckfmconsistncy Si prüft übr di Mthodn blongstospl() für das Faturmodll dr Architktur und das Faturmodll dr Konfigurationsdati, ob dis für di glich Softwarproduktlini dfinirt wurdn. Ist dis dr Fall, lifrt di Mthod tru zurück. Ist das Ergbnis fals, s konnt also kin Übrinstimmung fstgstllt wrdn, wird dr Produktgnrirungsprozss abgbrochn und dr Nutzr rhält in ntsprchnd Fhlrmldung. Wird jwils das glich Faturmodll rfrnzirt, könnn di auszuführndn Dltas brchnt wrdn, um das Tstmodll zu gnrirn. Damit auf di Dltas zuggriffn wrdn kann, wird zunächst in EMF-Rsourc übr di anggbn.darx-dati instantiirt. Daraufhin kann in EObjct [14] für di Hauptrgl bzw. dr root ds ASTs durch dn Aufruf von rsourc.gtcontnts.gt(0) rzugt wrdn. Diss binhaltt ntsprchnd dr Rgl Dltarx dr XTxt-Grammatik dn Zugriff auf sämtlich EObjcts dr Krnarchitktur sowi dr dfinirtn Dltas. Aus disn könnn nun übr di Mthod computdltas dr Klass ProductGnrator dijnign brchnt wrdn, wlch für di gwählt Konfiguration angwndt wrdn müssn. Dis ist dann dr Fall, wnn ihr Application Condition rfüllt ist. Um dis zu prüfn wird di Mthod appconisfulfilld vrwndt. Zusätzlich wird bim Brchnn dr Dltas anhand ihrr aftr-bdingung gprüft, in wlchr Rihnfolg dis ausgführt wrdn müssn. Hirfür wird in tmporär List mit Dltas gführt, drn Bdingung noch nicht rfüllt ist und di dmnach spätr ausgführt wrdn müssn. Di Mthod computwaitingdltas ruft sich rkursiv auf, um all Dltas dr Wartlist sukzssiv abzuarbitn. Wird in Dadlock fstgstllt, d.h. di Application Condition ins Dltas kann nicht rfüllt wrdn und s käm zu inr Endlosschlif, so bricht di Mthod ab und lifrt inn Fhlr. 83

102 5 Wrkzugimplmntirung Nachdm di sortirt List dr anzuwndndn Dltas brchnt wurd, wrdn di darin nthaltnn Dltas durch di Mthod xcutdlta ausgführt. Dis prüft das Dlta auf di vrschidnn anggbnn Transformationn und vrsucht dis auf dm Krnmodll auszuführn. Hirbi müssn vrschidn Constraints gprüft wrdn, um sichrzustlln, dass das rsultirnd Tstmodll valid ist. Wird in Constraint bi dr Ausführung ins Dltas vrltzt, wird in ntsprchnd Fhlrmldung gnrirt und dr Gnrirungsprozss wird abgbrochn. In dism Fall wird kin Tstmodll rstllt. Bi dr Anwndung dr Dltas wird übr di Klass ConstraintChckr in Rih von Übrprüfungn dr dfinirtn Konnktorn durchgführt. So müssn di Komponntn, Ports und Signal, di in Konnktor vrwndt, zuvor dfinirt wurdn sin. Dis kann auch übr in zuvor ausgführts Dlta gschhn sin. Witrhin müssn di anggbnn Signal dn glichn Signaltyp bsitzn, da sonst kin Kommunikation übr dn Konnktor möglich wär. Wurd dr Konnktor mit dr Angab von Ports dfinirt, so müssn dis auch di ntsprchndn Signal dfinirn odr kin Signal zugwisn habn. Ein Klassndiagramm, dass in dtaillirt Übrsicht übr di Implmntirung ds Plugins samt dr darin dfinirtn Klassn, Variabln und Mthodn lifrt, bfindt sich in Anhang A. 5.3 Vrwndungswis Im Folgndn wrdn di inzlnn Schritt dr Pluginvrwndung bschribn. Dfinition inr Krnarchitktur: Als Basis für in spätr Produktgnrirung muss zunächst in Krnprodukt bzw. in Krnarchitktur dfinirt wrdn. Dis muss in dr Sprach Dltarx im ntsprchndn XTxt-Editor bschribn wrdn. Ein Bispil für in Architktur in Dltarx ist in Listing 5.23 dfinirt. 1 a r c h i t c t u r xampl { 2 s i g n a l s { 3 xamplinsignal b o o l a n 4 xamploutsignal doubl 5 } 6 componnts { 7 ExamplSourcComponnt { 8 p o r t s { 9 o u t outport xamploutsignal 10 } 11 } 12 xampltargtcomponnt { 13 p o r t s { 14 i n inport xamplinsignal 84

103 5.3 Vrwndungswis 15 } 16 } 17 } 18 c o n n c t o r s { 19 xcon ( ExamplSourcComponnt, 20 xamploutsignal, xamplinsignal, 21 xampltargtcomponnt ) 22 } 23 } Listing 5.23: Bispil inr Architkturdfinition in Dltarx Im Bispil aus Listing 5.23 wrdn zunächst (Zil 2-4) zwi Signal dfinirt, xamplinsignal und xamploutsignal. Bidn wird jwils in Datntyp zugwisn, in dism Fall boolan und doubl. Anschlißnd wrdn zwi Komponntn (Zil 6-17) dfinirt. Di rst Komponnt trägt dn Namn ExamplSourcComponnt und bsitzt inn Port namns outport. Disr bsitzt di Sndrichtung out, d.h. s handlt sich um inn sndndn Port. Das vom Port vrsndt Signal ist xamploutsignal. Analog dazu gibt s in zwit Komponnt xampltargtcomponnt, drn Port dn Nam inport trägt und als mpfangndr Port mit Sndrichtung in dfinirt wurd. Disr Port mpfängt das Signal xamplinsignal. Zultzt wird in Konnktor xcon dfinirt, dr di bidn Komponntn mitinandr vrbindt und dabi di jwilign Ports und drn Signal vrwndt. Im Bispil wurdn bidn Ports dirkt di dazughörign Signal zugwisn. Dis ist nach dr Dltarx Grammatik aus Listing 3.8 optional, d.h. in Port kann auch ohn in Signalzuwisung dfinirt wrdn. Um dn Port zu vrwndn, kann ihm durch di Dfinition ins Konnktors nachträglich in Signal zugwisn wrdn. Dis wird durch in altrnativ, zwit Konnktorrgl (vgl. Listing 5.19) rmöglicht. Dabi wird xplizit anggbn, wlchr Port dr Komponntn vrwndt wrdn soll. Bsitzn dis kin Signal, so wird das im Konnktor dfinirt Signal dm Port zugwisn. Bsitzn di Ports brits in Signal, so wird bim Erstlln gprüft, ob di Signal ds Konnktors mit dn Signaln dr Ports übrinstimmn. Falls nicht, kommt s zu inr Fhlrmldung. Di Bispilarchitktur säh in dr altrnativn Variant wi folgt aus: 1 a r c h i t c t u r xampl { 2 s i g n a l s { 3 xamplinsignal b o o l a n 4 xamploutsignal doubl 5 } 6 componnts { 7 ExamplSourcComponnt { 85

104 5 Wrkzugimplmntirung 8 p o r t s { 9 out outport 10 } 11 } 12 xampltargtcomponnt { 13 p o r t s { 14 i n inport 15 } 16 } 17 } 18 c o n n c t o r s { 19 xcon ( ExamplSourcComponnt, outport, 20 xamploutsignal, xamplinsignal, 21 inport, xampltargtcomponnt ) 22 } 23 } Listing 5.24: Bispil inr Architkturdfinition in Dltarx (Altrnativ) Dfinition von Dltas: Um Produkt auf Basis inr Krnarchitktur zu gnrirn, muss dr Anwndr Dltas dfinirn. Dis bstimmn, wlch Transformationn für wlch Faturs angwandt wrdn solln. Di Dltas bzihn sich in im Kontxt disr Arbit auf Elmnt dr Softwararchitktur, also Komponntn, Konnktorn, Ports und Signal. Dis könnn ntwdr hinzugfügt odr ntfrnt wrdn. Es ist möglich, Transformationn auf vrschidnn Hirarchibnn anzuwndn. Ein Bispil für in Dltadfinition in Dltarx wird in Listing 5.25 dfinirt. 1 a r c h i t c t u r xampl { 2 s i g n a l s { } 5 componnts { } 8 c o n n c t o r s { } 11 d l t a s { 12 xampldlta whn xamplfatur { 13 addcomponnt { 14 nwcomponnt { 15 p o r t s { 16 i n inport 86

105 5.3 Vrwndungswis 17 } 18 } 19 } 20 } 21 } 22 } Listing 5.25: Bispil inr Dltadfinition in Dltarx Wi im Bispil zu rknnn ist, wrdn Dltas in Dltarx im Rahmn inr Architkturdfinition bschribn. Das bdutt, dass zu inr Krnarchitktur all für di ntsprchnd SPL rlvantn Dltas mit dfinirt wrdn. Dis wrdn durch di Angab inr Application Bdingung gnau dann angwndt, wnn di ntsprchndn Faturs ausgwählt wurdn bzw. wnn di Bdingung dn Wahrhitsghalt wahr hat. In dism Bispil wurd in Dlta xampldlta mit dr Application Condition xamplfatur dfinirt. Würd also in inr Faturkonfiguration das Fatur xamplfatur gwählt, würd das Dlta angwandt wrdn. Das Dlta slbst bschribt di Tranformation ds Hinzufügns inr Komponntn namns nwcomponnt. Bim Hinzufügn nur Elmnt in in Architktur wrdn dis äquivalnt zu dn brits gzigtn Dfinitionn dr Krnarchitktur anggbn. So wird im Bispil aus Listing 5.25 dr nun Komponnt dirkt in mpfangndr Port inport zugwisn. Dltas könnn grundsätzlich in blibig, ndlich Mng von Transformationn bschribn. Somit lassn sich komplxr Manipulationn dr Krnarchitktur mit inm Dlta ralisirn. Es wär also im konkrtn Bispil dnkbar, zusätzlich noch inn nun Konnktor hinzuzufügn, dr di nu Komponnt mit inr dr brits xistirndn Komponntn vrbindt. Vrwndung ds Wizards zur Tstmodllgnrirung Nachdm in Krnarchitktur und dazughörig Mng von Dltas txtull dfinirt wurdn, kann in Tstfallgnrirung für witr Produkt vorgnommn wrdn. Dazu wird di Angab ds Krns, dr Dltas, ins Zilpfads sowi inr Produktkonfiguration bnötigt. Dazu kann dr Dltarx-Wizard in Eclips gnutzt wrdn. Ein Scrnshot ds Wizards ist in Abbildung 5.6 abgbildt. Dr Wizard bsitzt vir Eingabfldr, di für in rfolgrich Produktgnrirung vom Anwndr ausgfüllt wrdn müssn. Als Ersts muss di.darx-dati anggbn wrdn, di das Krnmodll sowi di Dlta nthält. Im zwitn Eingabfld wird in Zilvrzichnis für di zu rstllnd, nu Architktur anggbn. Anschlißnd wird di Angab inr Konfigurationsdati gfordrt. Dis ntspricht inm von Lity [30] implmntirtn Configuration Rpository (.configrpository), für das in Editor xistirt und das in Produktkonfiguration auf Basis ins Faturmodlls nthält. Es ist wichtig, dass s sich dabi um das slb Faturmodll 87

106 5 Wrkzugimplmntirung handlt, dass von dr Krnarchitktur vrwndt wird, damit ausschlißlich valid Produkttstmodll rstllt wrdn. Zultzt muss dr Anwndr in dr Produktkonfigurationn, di in dm anggbn Rpository nthaltn sind, auswähln. Für dis Konfiguration wird das Tstmodll gnrirt. Sind dis vir Paramtr korrkt ausgfüllt wordn, kann dr Finish-Button zur Produktgnrirung ausgführt wrdn. Anschlißnd wird in das anggbn Zilvrzichnis das nu Tstmodll gschribn. Diss ntspricht widr inr gültign Dltarx-Architktur, ohn Dltadfinitionn. 88

107 6 Fallstudi Body Comfort Systm In dism Kapitl soll in Evaluation dr zuvor vorgstlltn Softwararchitkturbschribungssprach Dltarx, dm dazughörign Eclipsplugin sowi dm Intgrationststprozss anhand dr Fallstudi Body Comfort Systm (vgl Kapitl 1.1) durchgführt wrdn. Es wird zunächst in Bispil für in konkrt Produktbschribung in Dltarx ggbn, danach wird di Tstfallntwicklung für di Fallstudi rläutrt. Anschlißnd rfolgt in Auswrtung ds Tstvrfahrns. 6.1 Krnarchitktur für das BCS Di Body Comfort Systm-Fallstudi (Vgl. Kapitl 1) umfasst insgsamt Produkt [56]. Von disn wurdn in dr Mastrarbit von Zink [56] 17 Produkt, P1 bis P17, für di Fallstudi ausgwählt. Di Produkt wurdn aus dm Produktraum als rpräsntativ Untrmng für di auftrtndn pairwis-faturkombinationn xtrahirt. Lity [30] hat darauf aufbaund in sinr Mastarbit zusätzlich in Produkt P0 ingführt, das glichzitig das Krnprodukt darstllt. Es wird dahr als Ausgangspunkt für di Gnrirung allr andrn Produkttstmodll vrwndt. Di Gnrirung rfolgt durch di Anwndung inr Mng von Dltas, di zuvor bschribn wordn sind. Zunächst wird di Dfinition dr Krnarchitktur in Listing 6.1 ggbn. 1 a r c h i t c t u r p0 for faturmodl 2 \ usrs \...\ bcs. faturmodl { 3 s i g n a l s { 4 pw_but_mv_dn b o o l a n 5 pw_but_mv_up b o o l a n 6 m_but_mv_lft b o o l a n 7 m_but_mv_right b o o l a n 8 m_but_mv_up b o o l a n 9 m_but_mv_dn b o o l a n pw_but_up b o o l a n 12 pw_but_dn b o o l a n 13 m_but_right b o o l a n 14 m_but_lft b o o l a n 15 m_but_up b o o l a n 16 m_but_down b o o l a n m_pos_lft b o o l a n 89

108 6 Fallstudi Body Comfort Systm 19 m_pos_right b o o l a n 20 m_pos_top b o o l a n 21 m_pos_bottom b o o l a n 22 m_mv_lft b o o l a n 23 m_mv_right b o o l a n 24 m_mv_up b o o l a n 25 m_mv_dn b o o l a n fingr_dtctd b o o l a n 28 fp_on b o o l a n 29 fp_off b o o l a n pos_up b o o l a n 32 pos_dn b o o l a n 33 pw_mv_up b o o l a n 34 pw_mv_dn b o o l a n 35 } 36 componnts { 37 HMI { 38 } 39 ManPW { 40 } FP { 43 } EM { 46 } 47 } 48 c o n n c t o r s { 49 hmi1 (HMI, m_but_right, m_but_right,em) 50 hmi2 (HMI, m_but_lft, m_but_lft,em) 51 hmi3 (HMI, m_but_up, m_but_up,em) 52 hmi4 (HMI, m_but_down, m_but_down,em) 53 hmi5 (HMI, pw_but_up, pw_but_up, ManPW ) 54 hmi6 (HMI, pw_but_dn, pw_but_dn, ManPW ) nv1 (ENV, pw_but_mv_dn, pw_but_mv_dn, HMI ) 57 nv2 (ENV, pw_but_mv_up, pw_but_mv_up, HMI ) 58 nv3 (ENV, m_but_mv_lft, m_but_mv_lft, HMI ) 59 nv4 ( ENV, m_but_mv_right, m_but_mv_right, HMI ) 60 nv5 (ENV, m_but_mv_up, m_but_mv_up, HMI ) 61 nv6 (ENV, m_but_mv_dn, m_but_mv_dn, HMI ) 62 nv7 (ENV, m_pos_lft, m_pos_lft,em) 90

109 6.1 Krnarchitktur für das BCS 63 nv8 (ENV, m_pos_right, m_pos_right,em) 64 nv9 (ENV, m_pos_top, m_pos_top,em) 65 nv10 (ENV, m_pos_bottom, m_pos_bottom,em) 66 nv11 ( ENV, fingr_dtctd, fingr_dtctd, FP) 67 nv12 (ENV, pw_but_dn, pw_but_dn,fp) 68 nv13 (ENV, pos_up, pos_up, ManPW ) 69 nv14 (ENV, pos_dn, pos_dn, ManPW ) fp1 (FP, fp_on, fp_on,pw) 72 fp2 (FP, fp_off, fp_off,pw) m1 (EM, m_mv_lft, m_mv_lft, ENV ) 75 m1 (EM, m_mv_right, m_mv_right, ENV ) 76 m1 (EM, m_mv_up, m_mv_up, ENV ) 77 m1 (EM, m_mv_down, m_mv_down, ENV ) pw1 (PW, pw_mv_dn, pw_mv_dn, ENV ) 80 pw2 (PW, pw_mv_up, pw_mv_up, ENV ) } 83 } Listing 6.1: Architkturdfinition ds Krnprodukts p0 Di txtull Bschribung ntspricht dr Dltarx-Grammatik und dfinirt di Architktur für das Krnprodukt P0 dr Fallstudi. Entsprchnd dr Grammatik wrdn zunächst di Signal dr Architktur dfinirt. Da in dr Fallstudi kin klar Aussag übr di Datntypn dr Signal ggbn wird, wird hir stts dr Datntyp boolan angnommn, da di Signal analog zu Statchart-Evnts dfinirt wurdn, di das intrn Vrhaltn dr Softwarkomponntn bschribn. Um di Vrständlichkit ds Bispils zu rhöhn, ist in Abbildung 6.1 di Architktur ds Krnprodukts P0 grafisch dargstllt. Si dint als Vorlag für di txtull Bschribung dr Elmnt und ist aus dr ntsprchndn Faturkonfiguration ds Produkts und dssn Komponntnspzifikationn [30] abglitt. Di Signal, di in Listing 6.1 dfinirt wurdn, ntsprchn dn Konnktorlabls aus Abbildung 6.1, da dis angbn, wlch Signal di Konnktorn übrtragn. Jds Signal wird inmalig dfinirt und ist anschlißnd global in dr Architktur vrwndbar. Nach dr Signaldfinition rfolgt di Bschribung dr Komponntn. Ein Komponnt wird stts übr inn indutign Namn rfrnzirt. Di Komponntnnamn ds Bispils ntsprchn dnn dr Fallstudi. Das Produkt P0 bstht dmnach aus dn vir Komponntn HMI bzw. Human Machin Intrfac, ManPW bzw. Manual Powr Window, FP bzw. Fingr Protction und EM bzw. Extrior Mirror. Für di Komponntn wrdn im Bispil kin witrn Eignschaftn zugordnt. Es wär jdoch möglich Ports, Konnktorn odr witr Subkomponntn für in 91

110 6 Fallstudi Body Comfort Systm pw_but_mv_dn pw_but_mv_up m_but_mv_l0 m_but_mv_right m_but_mv_up m_but_mv_dn pw_but_up pw_but_dn HMI m_but_right m_but_down m_but_up pw_pos_up pw_pos_dn ManPW m_but_l0 fp_on fp_off fingr_dtctd FP m_pos_l0 EM m_pos_right m_pos_top m_pos_bo7om Abbildung 6.1: Grafisch Architkturrpräsntation für Produkt P0 pw_mv_dn pw_mv_up m_mv_l0 m_mv_right m_mv_up m_mv_down 92

111 6.1 Krnarchitktur für das BCS Komponnt zu dfinirn. Da di Fallstudi jdoch ausschlißlich flach Softwararchitkturn ohn Hirarchi bschribt, kann auf Konnktorn und Subkomponntn innrhalb inr Komponnt vrzichtt wrdn. Es wurdn kin Ports anggbn, da dis auch implizit übr di Konnktorbschribungn gnrirt wrdn könnn, um dn Dsignprozss zu vrinfachn. Für das Produkt P0 wurd dis Variant gwählt. Im Bispil sind di anggbnn Signalpaar dr Konnktorn idntisch. Es könnn jdoch auch zwi untrschidlich Bzichnr vrwndt wrdn, da Signal bi Komponntn untr vrschidnn Namn bkannt sin könnn. Um Kompatibilitätsproblm zu vrmidn, müssn di bidn Signal dn glichn Datntyp vrwndn, ansonstn kann das Produkt nicht gnrirt wrdn. Da Konnktorn vrbindn nicht nur Softwarkomponntn untrinandr sondrn könnn auch Softwarkomponntn mit dr Umwlt vrknüpfn. Zu dism Zwck wird in Dltarx di Variabl ENV britgstllt, di bi dr Produktgnrirung als Umwltinstanz intrprtirt wird. Dr Umwlt sind all Signal, di in dr Architktur dfinirt wordn sind, bkannt. Wlch Konnktorn für di Umwlt dfinirt wrdn, muss in dr Spzifikation bschribn wrdn. Zusätzlich wurdn für Konnktorn tick-signal ingführt, mit dnn das Vrghn inr unbstimmtn Zit simulirt wird. Wird, wi im Bispil gzigt, bi dr Architkturdfinition auf Ports vrzichtt, so wrdn dis im Gnrirungsprozss durch di Konnktordfinitionn automatisch für di ntsprchndn Komponntn gnrirt. Si rhaltn dann inn Namn, dr p_signalnam ntspricht, j nach Position im Konnktor in Richtung und ihnn wird das im Konnktor vrwndt Signal zugwisn. Ein Ausnahm stllt di Umwltkomponnt dar, für di kin Ports gnrirt wrdn. Als Bispil si dr Konnktor hmi1(hmi, m_but_right, m_but_right, EM) gnannt. Disr übrträgt von dr Komponnt HMI das Signal m_but_right und sndt s an EM. Bi dr Produktgnrirung würd für HMI also dr Ausgangsport p_m_but_right und für EM dr Eingangsport p_m_but_right dfinirt wrdn. In Listing 6.2 wird dr Ausschnitt dr ntsprchndn Portgnrirung nach dr Produktgnrirung gzigt HMI { 3 p o r t s { 4 o u t p_m_but_right m_but_right 5 } 6 } 7 EM { 8 p o r t s { 9 i n p_m_but_right m_but_right 10 } 11 }

112 6 Fallstudi Body Comfort Systm Listing 6.2: Portgnrirung Um witr Produkt auf Basis inr Krnarchitktur zu gnrirn, müssn Dltas dfinirt wrdn. Di Dltas für di Produkt dr Fallstudi wrdn im nächstn Abschnitt dfinirt. 6.2 Produktgnrirung für BCS Nachdm di Architktur für das Krnprodukt P0 dfinirt wurd, muss in Mng von Dltas dfinirt wrdn, um di Produkt P1 bis P17 zu dfinirn. Di dlta-orintirt Modllirung untrligt dm Ansatz dr Widrvrwndbarkit von Artfaktn. Di Dltantwicklung sollt dahr auf inn möglichst hohn Grad von Widrvrwndbarkit dr Dltas ausglgt wrdn. Für di Arbit wurd dr Ansatz gwählt, für jds Fatur ds Faturmodlls in igns Dlta zu dfinirn, so dass dis möglichst fri kombinirbar und widrvrwndbar sind. Zusätzlich wurdn für bsondr Fäll von Faturkombinationn Dltas dfinirt. Di Vrbindung zwischn inm Fatur und dm dazughörign Dlta gschiht übr di Application Condition ds Dltas. Im Rahmn dr Arbit wurdn insgsamt 24 Dltas für di Tstmodllgnrirung dr Produkt P1 bis P17 ntwicklt. Als Bispil für in Dlta, dass di Funktionalität ins Faturs nthält, wird in Listing 6.3 das Dlta DCLS für das Fatur Cntral Locking Systm aufgführt. 1 DCLSM whn Cntral Locking Systm 2 AND Manual Powr Window { 3 addsignal { 4 ky_pos_lock b o o l a n 5 cls_lock b o o l a n 6 } 7 addcomponnt { 8 CLS { 9 } 10 } 11 addconnctor { 12 nvcls1 (ENV, ky_pos_lock, ky_pos_lock, CLS ) 13 clsnv1 (CLS, cls_lock, cls_lock, ENV ) 14 clsmanpw1 (CLS, cls_lock, cls_lock, ManPW ) 15 } 16 } Listing 6.3: Dlta DCLS für das Fatur CLS Di Namn dr in dr Fallstudi dfinirtn Dltas sind in dr Form D+Faturabkürzung+Untrschidung dfinirt. Di Untrschidung wird dann bnötigt, wnn zwi Dltas di glich Funktionalität hinzufügn, dis jdoch auf untrschidlichn Vorausstzungn tun. Im Fallbispil muss für inig Dltas untrschidn wrdn, 94

113 6.2 Produktgnrirung für BCS ob si für in Architktur angwandt wrdn, di das Manual Powr Window odr das Automatic Powr Window nthält. Das Dlta DCLSM ist dmnach das Dlta für das Fatur Cntral Locking Systm (CLS) und wird in Zusammnhang mit dr Komponnt Manual Powr Window vrwndt. Da diss Dlta kinrli Elmnt aus dr Krnarchitktur ntfrnt, sondrn nur nu Elmnt hinzufügt, nthält s nur add-transformationn. Es wrdn zunächst di bidn nun Signal ky_pos_lock und cls_lock vom Typ boolan hinzugfügt. In dr Architktur bzw. dm intrnn Komponntnvrhaltn handlt s sich nicht um zwi sondrn vir Signal, da s nbn ky_pos_lock und cls_lock auch ky_pos_unlock und cls_unlock gibt. Dis wurdn im Bispildlta jdoch indirkt mit modllirt, da di bidn Signal vom Typ boolan sind und di bidn fhlndn Signal das Ggntil dr dfinirtn Signal darstlln. Di bidn Signal könnn dmnach ingspart wrdn, ohn dass s zu inm Informationsvrlust kommt. Nbn dn bidn Signaln wird in nu Komponnt CLS hinzugfügt. Im Bispildlta wird dis ohn zusätzlich Informationn wi z.b. Ports odr Subkomponntn ingfügt, s wär jdoch möglich gwsn. Di Portdfinition dr Komponnt ist dshalb nicht notwndig, da di Komponntnschnittstlln indirkt übr di Konnktordfintionn nvcls1 und clsnv1 gschiht. Dis nutzn di zwit Variant dr Konnktordfinition (vgl. Listing 5.19), di als Paramtr di bidn zu vrbindndn Komponntn sowi di bidn Signal, di übrtragn wrdn solln, bnötigt. Disr Konnktortyp ist drart dfinirt, dass s bi dr Produktgnrirung zu inr Erzugung dr dafür bnötigtn Ports bi dn vrwndtn Komponntn kommt. Als Ergbnis disr Transformation würdn dahr di Ports in p_ky_pos_lock und out p_cls_lock bi dr Komponnt CLS und dr Port in p_cls_lock bi dr Komponntn ManPW gnrirt wrdn. Für di Umwltkomponnt ENV wrdn kin Ports dfinirt, da angnommn wird, dass di Umwlt zu sämtlichn Konnktorn und Signaln kompatibl ist. Das Dlta fügt dmnach immr dann, wnn di Faturs Cntral Locking Systm und Manual Powr Window für di Produktkonfiguration ausgwählt wurdn, di Komponnt CLS sowi di ntsprchndn Signal und Konnktorn hinzu. Das Fatur Manual Powr Window wird dshalb gprüft, da di Komponnt ds gwähltn Powr Windows durch inn Konnktor mit dr Komponntn CLS vrknüpft wird. Für dn Fall, dass das Fatur Automatic Powr Window gwählt wurd und dmnach statt dr Komponntn ManPW di Komponnt AutoPW in dr Architktur xistirt, muss in zwits Dlta für di Application Condition Cntral Locking Systm AND Automatic Powr Window dfinirt wrdn. Als Bispil für in Dlta, dass nach inm andrn Dlta ausgführt wrdn muss, ist in Listing 6.4 das Dlta DLEDCLSA dssn Application Condition di Faturs LED Cntral Locking Systm und Manual Powr Window vorausstzt. 1 DLEDCLSM a f t r DCLSM whn LED Cntral Locking Systm 2 AND Manual Powr Window { 3 addsignal { 4 cls_lock b o o l a n 95

114 6 Fallstudi Body Comfort Systm 5 ld_cls_on b o o l a n 6 } 7 addcomponnt { 8 LED_CLS { 9 10 } 11 } 12 addconnctor { 13 clsldcls1 (CLS, cls_lock, cls_lock, LED_CLS ) 14 ldclsnv1 ( LED_CLS, ld_cls_on, ld_cls_on, ENV ) 15 } 16 } Listing 6.4: Dlta DLEDCLSA für das Fatur LED CLS Das Dlta DLEDCLSM kann rst nach dm Dlta DCLSM ausgführt wrdn, da diss in dr aftr-bdingung dfinirt ist. Dis bgründt sich aus dr Tatsach, dass diss Dlta di Funktionalität ds Faturs LED Cntral Locking Systm dfinirt. Di LED kann jdoch rst in di Architktur intgrirt wrdn, wnn di Komponnt CLS vorhandn ist. Dahr muss zu rst drn Dlta ausgführt wrdn. 6.3 Anwndung ds Intgrationststvrfahrns Nachdm di Krnarchitktur für di Fallstudi in Form von Produkt P0 und 24 Dltas zur Gnrirung dr Produkt P1 bis P17 dfinirt wurdn, soll nun das Intgrationststvrfahrn auf dr Produktmng dr Fallstudi angwandt wrdn. Es wird hirfür noch inmal auf Abbildung 4.3 aus Kapitl vrwisn, in dm di Tststratgi schmatisch dargstllt ist. Di Produktauswahl rfolgt brits bi Dfinition dr Fallstudi, da dr Produktraum potntill Produktkonfigurationn umfasst [56]. Daraus wurdn di 18 Produkt P0 bis P17 als rpräsntativ Produktmng ausgwählt. In Tabll 6.1 ist in Übrsicht übr di Faturkonfigurationn dr gwähltn Produkt ggbn (Entnommn aus [30]). Di inzlnn Faturs wrdn aus Gründn dr Übrsichtlichkit in dr Tabll abgkürzt. Di Bdutungn dr Abkürzungn sind im Abkürzungsvrzichnis aufgführt. Für jds disr Produkt wird anhand sinr Faturkonfiguration das Tstmodll gnrirt. Di Tstmodllgnrirung kann auf Basis dr im vorhrign Abschnitt dfinirtn Architktur und Dltas gschhn, wobi di Krnarchitktur brits das Tstmodll für P0 darstllt. Hirfür richt s dmnach, di Architktur in Dltarx zu dfinir. Wurdn Dltas für andr Produkt gnrirt, muss das Ausgangsmodll dnnoch durch dn Produktgnrator gnrirt wrdn, damit di Dltas im rsultirndn Tstmodll nicht mhr vorhandn sind. Um in Tstmodll für in andrs Produkt zu gnrirn, muss di ntsprchndn Faturkonfiguration bi dr Gnrirung in Dltarx anggbn wrdn. Daraufhin wird in Mng von Dltas ausgwählt, drn Application Condition durch di Faturkonfiguration rfüllt ist. 96

115 6.3 Anwndung ds Intgrationststvrfahrns Fatur P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17 Scurity X X X X X X X X X X X X X LED X X X X X X X X X X LED CLS X X X X X X LED PW X X X X X X LED Hat X X X X X X X LED EM X X X X X X X LED AS X X X X X X LED FP X X X X X X X X X ManPW X X X X X X X X X AutoPW X X X X X X X X X Hatabl X X X X X X X X X X X X CLS X X X X X X X X X X X X RCK X X X X X X X X X X X AS X X X X X X X X X X X AL X X X X X X X X X CAS X X X X X X X X SF X X X X X X X X ConAPW X X X X X X IM X X X X X X X X X #Faturs Tabll 6.1: Übrsicht dr Faturkonfigurationn für di Produkt P0 bis P17 97

116 6 Fallstudi Body Comfort Systm In Abbildung 6.2 wird dr Zusammnhang von Faturkonfiguration und Dltaanwndung für Produkt P10 schmatisch dargstllt. Faturkonfiguration LED fingr Protction Automatic Powr Window Hatabl Cntral Locking Systm Rmot Control Ky Alarm Systm Control Alarm Systm Intrior Monitoring Application Condition Dlta LED_EM Add Rmov + Auswahl dr Dltas Dltas Anwndung auf Krnmodll Dlta LED_FP Add Rmov LED_EM AutoPW LED_FP ManPW AS CLS Hatabl AL RCK + Krn P0 Gnrirung ds Tstmodlls Tstmodll P10 Abbildung 6.2: Produktgnrirung im BCS für Produkt P10 Um in Produkttstmodll zu gnrirn muss zunächst di ntsprchnd Faturkonfiguration anggbn wrdn. Dis ntspricht im Bispil aus Abbildung 6.2 dn Faturs, di das Produkt P10 laut Tabll 6.1 bsitzt. Di Faturkonfiguration gibt anschlißnd di anzuwndndn Dltas vor. Dis bsitzn in Application Condition. Bi dr Produkttstmodllgnrirung wrdn di Dltas rmittlt, drn Application Condition wahr wird. Im Bispil wärn dis di Dltas LED_EM und LED_FP. Drn Namn suggrirn, dass si di Funktionalitätn für di Faturs LED Extrior Mirror und LED Fingr Protction britstlln. Nachdm di Mng dr Dltas rmittlt wurd, wrdn dis auf dr Krnarchitktur P0 angwandt, d.h. di von dn Dltas bschribnn Transformationn wrdn ausgführt. Dabi handlt s sich im Bispil um in nicht gnaur bschribn Mng von add und 98

117 6.3 Anwndung ds Intgrationststvrfahrns rmov-transformationn. Di konkrtn Dltadfinitionn samt Transformationn für all 17 Produkt dr BCS Fallstudi findn sich im Anhang A. Um nun dn in Kapitl 4 vorgstlltn Tstprozss auf dm nu gnrirtn Produkt anzuwndn, müssn di Tstfäll dfinirt wrdn. Dis wird im folgndn Abschnitt bschribn Tstfallntwicklung Für all zu tstndn Produkt wird nachinandr in Mng von Tstfälln rstllt, insofrn di dadurch gtsttn Kommunikationsauschnitt nicht brits in zuvor ntwickltn Tstfälln abgdckt wurdn. Dann wrdn di ntsprchndn Tstfäll für das gprüft Produkt als widrvrwndbar ingstuft. Für di 18 vrschidnn Produktvariantn dr Fallstudi wurdn im Rahmn dr Arbit insgsamt 64 MSCs rstllt. Di MSCs richtn sich nach dn in Kapitl vorgstlltn Tstkritrin, wobi di Konnktorabdckung als Tstndkritrium vrwndt wurd. Ein Bispil für in ntwicklts MSC ist in Abbildung 6.3 ggbn. HMI FP ManPW l 1 fingr dtctd l 1 f l 2 f fp on l 1 p l 2 pw but mv dn l 1 h l 2 h pw but dn l 3 f l 4 f fp off l 2 p l 3 h pw but dn l 3 p l 3 pw mv dn l 4 p Abbildung 6.3: MSC 1 für Produkt P0 Das MSC wurd für das Krnprodukt P0 dfinirt und umfasst di Komponntn HMI, FP und ManPW sowi in Instanz dr Umwlt, di jdoch nicht gknnzichnt ist. Dr Tstfall wird durch das Erknnn ins Fingr im Fnstr durch das 99

118 6 Fallstudi Body Comfort Systm Signal fingr_dtctd initiirt. Anschlißnd wird di Fingr Protction aktivirt. Durch di Umwlt wird das Signal zum Hruntrfahrn ds Fnstrs mpfangn, was di Fingr Protction daktivirt und das Fnstr hruntrfährt. Dr Tstlauf diss MSCs wär also di Abfolg dr folgndn Input und Output- Erigniss: tr = {f ingr_dtctd, pw_but_mv_dn, pw_mv_dn}, wobi fingr_dtctd und pw_but_mv_dn di kontrollirbarn Eingabsignal sind und pw_mv_dn das obsrvirbar Ausgabsignal ist. Würd das konkrt Ausgabsignal von dm rwarttn Ausgabsignal abwichn, so wär dr Tstfall für das Produkt vrltzt und würd auf in Fhlvrhaltn dr Implmntirung ggnübr dr Spzifikation hinwisn Auswrtung dr Tstfallwidrvrwndbarkit Di Tstfallrstllung rfolgt schrittwis für di inzlnn Produkt. Tstfäll, di nicht zuvor angwndt wrdn konntn, wrdn als nu katgorisirt, d.h. si könnn auf kin zuvor gprüfts Produkt angwndt wrdn, da di darin vrwndtn Komponntn und/odr Konnktorn in disr Kombination in kinm zuvor gprüftn Produkt xistirn. Wär dr zu rstllnd Tstfall brits bi inm zuvor gtsttn Produkt anwndbar, d.h. sin Vorausstzungn sind bnfalls rfüllt und s xistirt in äquivalntr Tstfall für in andrs, zuvor gtstts Produkt, wird disr Tstfall als widrvrwndbar ingstuft. Wurdn sämtlich nun und widrvrwndbarn Tstfäll für das untrsucht Produkt rmittlt, wrdn sämtlich zuvor rstlltn Tstfäll, di nicht widrvrwndbar sind, dr Katgori invalid zugordnt. Ein invalidr Tstfall bziht sich immr nur auf das Produkt, für das r als invalid ingstuft wurd. Dis bdutt, dass r für das Produkt nicht vrwndbar ist, da sin Vorausstzungn nicht rfüllt sind. Bispilwis könnt in Tstfall di Komponnt AutoPW vrwndn, wohinggn das aktull gtstt Produkt stattdssn di Komponnt ManPW bsitzt. Für in andrs zu tstnds Produkt dr Softwarproduktlini kann dr slb Tstfall jdoch widrvrwndbar und valid sin. Di Eignschaftn, di zur Katgorisirung gnutzt wrdn, umfassn di von inm Tstfall vrwndtn Komponntn, Konnktorn und Signal. Di Tstfallkatgorisirung ist stark von dr Rihnfolg dr zu tstndn Produkt abhängig, da di Katgorisirung sich auf brits gtstt Produkt und Tstfäll bziht. Ein Auswrtung dr für di Fallstudi rstlltn Tstfäll ist als Diagramm in Abbildung 6.4 dargstllt. Di Rihnfolg ntspricht ihrr Dfinition in dr Fallstudi. In dr Übrsicht wird di Gsamtzahl allr MSCs mit dr blaun Lini markirt. Di Anzahl dr nun Tstfäll für in Produkt ist mit rot gknnzichnt. Widrvrwndbar MSCs sind mit grün und invalid Tstfäll mit lila dargstllt. Di Auswrtung zigt, dass di Anzahl dr Tstfäll zunächst rapid anstigt, abr brits bi dr Mitt dr Produktanzahl fast ihrn Höhpunkt rricht hat. Dis bdutt, dass vil Komponntn und Faturkombinationn brits in dr frühn Entwicklungsphas aufgtrtn sind. Dr ltzt als nu ingstuft Tstfall wird in Produkt 13 ntwicklt. Anschlißnd xistirn sämtlich Kombinationn von Komponntn und Konnktorn in brits 100

119 6.3 Anwndung ds Intgrationststvrfahrns Abbildung 6.4: Übrsicht übr di Tstfallwidrvrwndung zuvor gtsttn Produktn, d.h. s gibt kin nun Tstfäll mhr. Di Anzahl dr widrvrwndbarn MSCs, also drr, di brits in inm vorhrign Produkt ntwicklt wurdn und widr anwndbar sind, stigt zu Bginn und schwankt dann j nach Produkt, wird jdoch nimals null. Es gibt also immr widrvrwndbar Tstfäll. Ein Ausnahm stllt natürlich das Krnprodukt P0 dar, da s das rst gnrirt Produkt ist und zuvor kin Tstfäll xistirn, di widrvrwndt wrdn könntn. Di Anzahl dr invalidn Tstfäll für di inzlnn Produkt stigt mit dr Gsamtanzahl dr Tstfäll und blibt für all Produkt rlativ hoch. Ein invalidr Tstfall wurd für in zuvor gtstts Produkt ntwicklt und kann für btroffn Produkt nicht widrvrwndt wrdn. Di hoh Zahl invalidr Tstfäll rgibt sich durch di allgmin hoh Anzahl von Tstfälln, di jwils nur für bstimmt Komponntn und Konnktorn instzbar sind. Da di inzlnn Komponntn und Konnktorn nur in inr bstimmtn Anzahl von Produktn vorkommn und inig Produkt nur in gring Anzahl Faturs und dmnach Komponntn bsitzn, sind vil dr zuvor vrwndtn Tstfäll nicht anwndbar und dahr als invalid inzustufn. Für di Evaluirung dr Effizinz dr Fallstudi richt das Diagramm aus Abbildung 6.4 nicht. Um dn Umfang dr Tstplän zu minimirn, muss gprüft wrdn, ob di als widrvrwndbar ingstuftn MSCs rnut gtstt wrdn müssn odr nicht. Es wird also gprüft, ob in Rtst dr btroffnn MSCs notwndig ist. Ein Rtst wird dann als notwndig ingstuft, wnn sich di Intrfacs dr im MSC 101

120 6 Fallstudi Body Comfort Systm nthaltnn Komponntn im Vrglich zu dnn dr ursprünglich gtsttn Produktkonfiguration gändrt habn. Ein Intrfacwchsl findt immr dann statt, wnn nu Ports an inr Komponnt hinzukommn bzw. alt Ports ntfrnt wrdn, da si für das aktull Produkt nicht vrwndt wrdn. Ein Bispil für inn Intrfacwchsl ist in Abbildung 6.5 dargstllt. A A C1 C2 Dlta dc4 C1 C2 C4 C3 C3 Abbildung 6.5: Intrfacwchsl dr Komponnt C3 Im linkn Til dr Abbildung ist in Softwararchitktur A zu shn, di aus dn dri Komponntn C1, C2 und C3 bstht. Im Bispil wird nun angnommn, dass in Dlta dc4 auf A angwndt wird. Das Ergbnis si di Softwararchitktur A, di im rchtn Til von Abbildung 6.5 zu shn ist. Das Dlta hat dmnach di Komponnt C4 sowi zwi Konnktorn hinzugfügt. In Bzug auf di Intrfacs dr Komponntn kann di Komponntn C3 hrvorghobn wrdn, da sich ihr Intrfac im Vrglich zu A gändrt hat. Dis bgründt sich aus dn bidn nun Konnktorn di in A für C3 hinzugkommn sind. Gäb s also inn Tstfall tc, dr di Komponntn C1, C2 und C3 umfasst, wär disr für A zwar widrvrwndbar, r muss jdoch rnut gtstt wrdn, da sich das Intrfac von C3 im Vrglich zu A gändrt hat. Ein zwitr Tstfall tc2 dr di Komponntn C1 und C2 umfasst wär widrvrwndbar und müsst nicht als Rtst markirt wrdn, da sich di bidn Komponntn nicht vrändrt habn. Ein Auswrtung übr di Vrtilung dr Rtsts in dr Fallstudi ist im Diagramm aus Abbildung 6.6 aufgführt. Im Diagramm sind für di Produkt P0 bis P17 jwils di Anzahl dr widrvrwndbarn Tstfäll und dazughörig di Anzahl dr rnut zu tstndn Tstfäll ingzichnt. Für das Krnprodukt P0 btragn bid Wrt trivialrwis null, da s kin zuvor rstlltn Tstfäll gab, di widrvrwndbar sind. Dahr kann s für P0 auch kin Rtsts gbn. Für di witrn Produkt gibt s stts widrvrwndbar Tstfäll. Di Anzahl dr rnut zu tstndn Tstfäll ist für all Produkt außr P1 nidrigr als di Anzahl dr widrvrwndbarn Tstfäll, d.h. für jds folgnd Produkt kann mindstns in Tstfall ohn rnuts Tstn übrnommn wrdn, da 102

121 6.3 Anwndung ds Intgrationststvrfahrns Abbildung 6.6: Vrtilung rnut zu tstndr Tstfäll di Komponntn, di in dm Tstfall vrwndt wrdn, idntisch Intrfacs habn. Dis kann daraus bgründt wrdn. Witrhin ist zu rknnn, dass di Anzahl rnut zu tstndr Tstfäll mit stigndr Anzahl von Produktn abnimmt, d.h. dr Abstand zwischn dn bidn Kurvn wird mit stigndr Produktanzahl größr. J mhr Produkt brits gtstt wurdn, umso wahrschinlichr ist s, dass di aktull Intrfacblgung dr Komponntn brits in vorhrign Produktn aufgtrtn und gtstt wurd. Sind bi dn rstn fünf Produktn noch mindstns 50% dr widrvrwndbarn Tstfäll rnut zu tstn, so nimmt di durchschnittlich Vrtilung mit stigndr Zahl ab. Von dn schs widrvrwndbarn Tstfälln für Produkt P17 ist für kins mhr in Rtst durchzuführn. Es ist anzunhmn, dass di Anzahl dr Produkt sich auf dn Grad dr Rtsts und dssn Vrtilung übr dr Mng allr Produkt stark auswirkt. Bi inr nidrign Anzahl von Produktn ist s zwar möglich, dass vil Tsts widrvrwndt wrdn könn, abr s ist auch davon auszughn, dass dr Grad dr widrholt zu tstndn Tstfäll bi inr hohn Anzahl von Produktn nidrigr ausfällt, da dis vil vrschidn Konfigurationn abdckn. TODO Um zu prüfn, wi ffizint das Tstvrfahrn ist, wird in Vrglich zu inm naivn Tstvrfahrn aufgstllt, bi dm das Rtst All-Kritrium für di Ermittlung dr rnut zu tstndn Tstfäll vrwndt wird [28]. Bi dism Ansatz wrdn sämtlich Tstfäll, di widrvrwndbar sind, rnut gtstt. In dn Tstplan wrdn 103

122 6 Fallstudi Body Comfort Systm dmnach sämtlich nun Tstfäll ts nw und sämtlich widrvrwndbarn Tstfäll ts rus aufgnommn. Diss Vrfahrn würd analog zum Tstn von Singl Softwar-Systmn für jds Produkt all anwndbarn Tstfäll rnut tstn und kin Wissn zuvor gtsttr Produkt bzw. Tstfäll ausnutzn. Für in drartigs, naivs Tstvrfahrn rgibt sich di Mng dr auszuführndn Tstfäll innrhalb ds Tstplans also als tp RtstAll = ts nw ts rus Im Vrglich dazu stht di hir vorgstllt Tstplanminimirung, bi dr di widrvrwndbarn Tstfäll auf Intrfacwchsl gprüft wrdn. Für Tstfäll, bi dnn kin Vrändrung dr btiligtn Komponntn vorligt, wurd ausgsagt, dass si nicht rnut gtstt wrdn müssn. Dr Tstplan tp wird dmnach als tp = ts nw ts rtst dfinirt. In Diagramm 6.7 wird in Vrglich dr bidn Tstvrfahrn für di Tstfäll dr Fallstudi dargstllt. Darin sind di tatsächlich auszuführndn Tstfäll für di inzlnn Produkt P0 bis P17 zu shn. Abbildung 6.7: Vrglich tatsächlich ausgführtr Tstfäll Es wird dutlich, dass durch das in disr Arbit ntwicklt Intgrationststvrfahrn für di mistn Produkt in Vrringrung dr auszuführndn Tstfäll rzilt wrdn konnt. Für inig Produkt konnt di Anzahl um mhr als 50% vrringrt 104

123 6.3 Anwndung ds Intgrationststvrfahrns wrdn. Es konnt gzigt wrdn, das di Übrprüfung auf Rtsts zu inr Vrringrung dr Tstplän gführt hat. Di Tstplän konntn dmnach für inn Großtil dr Produkt minimirt wrdn. Das Tstvrfahrn ist also ffizintr als naiv Tstvrfahrn, di ähnlich zu Singl Softwar-Systmn all Tstfäll ins Produkt rnut ausführn. In Tabll 6.2 wird in Gsamtübrsicht dr Tstfäll, drn Katgorisirung, dr nu rnut zu tstndn Tstfäll und dr Größ dr Tstplän für di Produkt P0 bis P17 ggbn. Ein dtaillirt Übrsicht, wlch MSCs für wlch Produkt vrwndt wrdn könnn und ob dis rnut gtstt wrdn müssn ist im Anhang A.5 ggbn. Darin ist in Tabll für jds Produkt und dn dazughörign Tstfälln nthaltn. Produkt # Nu # Widrvrw. # Invalid # Rtst Tstplan P P P P P P P P P P P P P P P P P P Tabll 6.2: Übrsicht übr di Tstfäll für di Produkt P0 bis P17 105

124 7 Fazit und Ausblick Das Zil dr Arbit war di Konzption und Evaluation ins dlta-orintirtn modllbasirtn Intgrationststvrfahrns für Softwarproduktlinin. Di Evaluation sollt zign, dass das Vrfahrn auf SPLs anwndbar ist und dssn Effizinz prüfn. Für das Tstvrfahrn sollt di SPL-Tstphilosophi Subst-Huristics [44] zur Auswahl inr rpräsntativn Untrmng vrwndt wrdn, um so in Tstn allr Produkt zu vrmidn. Di Tstphilosophi Rus-Tchniqus [44] soll s rlaubn, Tstartfakt widrzuvrwndn, um dn Tstaufwand zu minimirn. Witrhin solltn di Tsttchnikn ds modllbasirtn Tstns [55] zur Erstllung von Tstmodlln und ds Rgrssionststns [15] zur Rduzirung dr Tstfallausführung ingstzt wrdn. Um dis zu rmöglichn, wurdn zunächst di thmatischn Grundlagn dr Arbit rklärt. Es wurdn Softwarproduktlinin und Faturmodll vorgstllt. In dism Rahmn wurd auch auf di dlta-orintirt Softwarntwicklung, als Möglichkit Variabilität in Softwarproduktn umzustzn, inggangn [51, 48]. Softwararchitkturn wurdn als Basis für Intgrationststs vorgstllt. Das Tstn von Softwar wurd dtaillirt bschribn, wobi das Hauptaugnmrk auf Intgrationststs, Rgrssionststs und dm modllbasirtn Tstn lag. Im Anschluss an di Grundlagnbschribung wurdn Softwararchitkturn sowi Konnktorn, Signal und Komponntn formal dfinirt. Es wurdn Softwararchitkturbschribungssprachn zur Modllirung von Softwararchitkturn vorgstllt und darauf aufbaund rfolgt in Adaption dr dlta-orintirtn Modllirungstchnik für Softwararchitkturn. Hirfür wurdn add- und rmov-transformationn auf Softwararchitkturn dfinirt, di in Dfinition von Dltas rmöglichn. Für di Modllirung dr Tstmodll wurd di ADL Dltarx ntwicklt, drn formal Grammatik di Sprachkonstrukt zur Architkturmodllirung vorgibt. Dltarx rlaubt di Dfinition von Dltas, di zur Tstmodllgnrirung gnutzt wrdn könnn. Di Tstfäll, di aus dn Tstmodlln abglitt wrdn könnn, wurdn in dr Arbit in Form von Mssag Squnc Charts vorgstllt. Nach dr Dfinition dr Softwararchitktur wurd in dlta-orintirts modllbasirts Intgrationststvrfahrn ntwicklt, bi dm di zuvor dfinirtn Architkturn als Tstmodll vrwndt wrdn. In dism Zusammnhang wurdn Tstkritrin und Äquivalnzbgriff für Tstmodll ingführt. Es wurd di Trminologi für dn Intgrationstst dfinirt und darauf aufbaund in Tststratgi für SPLs vorgstllt. Dis kann zusammnfassnd wi folgt bschribn wrdn (vgl. Kapitl 4.2): 1. Auswahl dr zu tstndn Produkt. Für all Produkt gilt dann: 2. Gnrirung ds Tstmodlls 106

125 3. Erstllung und Widrvrwndung dr Tstfäll 4. Katgorisirung von Tstfälln und Entwicklung inr Produkttstsuit 5. Tstfallslktion und Dfinition ins Tstplans Di angstrbt SPL-Tstphilosophi Subst-Huristics [44] wird vrwndt, um in Schritt 1 nur in rpräsntativ Untrmng von Produktn auszuwähln, anstatt ds gsamtn Produktraums. Dr Ansatz dr Rus-Tchniqus [44] wird durch di Vrwndung von widrvrwndbarn Tstartfaktn, in dr Form von Tstmodlln und Dltas, gnutzt. Rgrssionststs [15] wrdn bnfalls ingstzt, da widrvrwndbar Tstfäll rmittlt wrdn. Dis wrdn anschlißnd auf Rtsts gprüft, um di Tstplän zu minimirn. Das Zil dr Tststratgi war in Minimirung ds Tstaufwands von SPLs durch di bschribn Konzpt. Im Anschluss an di formaln Dfinitionn wurd di Implmntirung ds prototypischn Wrkzugs Dltarx vorgstllt, das di dfinirt ADL in Form ins txtulln Editors für Eclips umstzt. Damit lassn sich Krnarchitkturn und Dltas dfinirn. Zusätzlich könnn di Tstmodll witrr Produkt durch di Vrwndung ins Wizards gnrirt wrdn. Dis rfolgt übr di Angab inr Produktkonfiguration, woraufhin in Mng von auszuführndn Dltas anhand ihrr Application Conditions rmittlt wird. Di von dn Dltas bschribnn Transformationn wrdn anschlißnd zur Tstmodllgnrirung auf dm Krnmodll ausgführt. Das Ergbnis sind valid, Dltarx-konform Architkturn für di gwähltn Produktkonfigurationn. Dis könnn als Tstmodll vrwndt wrdn. Auch di Erwitrbarkit ds Wrkzugs ist durch di Vrwndung von XTxt möglich, da di Grammatik und dr Editor jdrzit um nu Rgln rwitrt wrdn könnn. Durch di Pluginstruktur könnn auch nu Plugins in dn Workflow intgrirt wrdn, um disn zu rwitrn. Das ntwicklt Intgrationststvrfahrn wurd anhand dr Fallstudi Body Comfort Systm aus dr Automobilntwicklung (vgl. Kapitl 1.1) valuirt. Hirfür wurdn das Krnmodll und 24 Dltas durch das implmntirt Wrkzug modllirt und anschlißnd di witrn Tstmodll für di Produkt P1 bis P17 gnrirt. Anhand drr konntn insgsamt 64 Tstfäll in Form von MSCs rstllt wrdn. Di Tstfäll wurdn für di btrachttn Produkt dr Fallstudi in nu, widrvrwndbar und invalid katgorisirt (sih Tabll 6.2). Um di Effizinz ds Tstvrfahrns zu valuirn, wurdn Statistikn übr di Anzahl dr widrvrwndbarn und rnut zu tstndn Tstfäll rstllt und di rsultirndn Tstplän ggn di ins naivn Tstvrfahrns, dass dn Rtst All-Ansatz vrwndt, [28] vrglichn (vgl. Abbildung 6.7). Zusammnfassnd konnt gzigt wrdn, dass das ntwicklt, dlta-orintirt Intgrationststvrfahrn auf SPLs anwndbar ist. Es konntn Tstmodll durch di Dfinition ins Krns und Dltas mit Hilf ds prototypischn Wrkzugs gnrirt wrdn. Durch dis konntn anschlißnd Tstfäll in Form von MSCs ntwicklt wrdn. Davon lißn sich vil Tstfäll widrvrwndn, so dass di Anzahl dr 107

126 7 Fazit und Ausblick ltztndlich auszuführndn Tstfäll im Vrglich zu inm simplrn Vrfahrn vrringrt wrdn konnt. Di Effizinz ds konzipirtn Vrfahrns ist dmnach höhr inzuschätzn, als das ins Singl Softwar-Systm Tsts, dr für jds inzln Produkt angwndt wird. Di angstrbtn Tstansätz zur Minimirung ds Tstaufwands konntn rfolgrich in dr vrwndtn Tststratgi angwndt wrdn. Im Folgndn soll auf di Ergbniss und Erknntniss, di währnd dr Arbit aufgfalln sind, inggangn wrdn. 7.1 Ergbniss Bi dr Evaluirung ds Tstvrfahrns wurd dutlich, dass das Wissn übr di SPL und di darin nthaltnn Faturs für di Umstzung ds Tstns ssntill ist, da nur mittls dr notwndign Informationn di Krnarchitktur und Dltas dfinirt wrdn könnn. Es muss klar sin, wi sich di inzlnn Faturs auf di Funktionalitätn dr Softwararchitktur auswirkn. Im Rahmn dr Arbit warn dr Krn und di gwähltn Produktkonfigurationn brits bkannt, was dn initialn Aufwand vrringrt. Andrnfalls wär disr als hoch inzuschätzn. Das Faturmodll dr zu ntwicklndn SPL muss bnfalls gut durchdacht wrdn, da s untr bstimmtn Umständn dazu kommn kann, dass Komponntn in inr Architktur xistirn, di durch di gwähltn Faturs jdoch kinrli Konnktorn zu andrn Komponntn bsitzn. Dis Komponntn würdn dmnach kin Kommunikation btribn, was inn Intgrationstst disr Komponntn unmöglich macht. Ein Architktur wird in disr Arbit als zusammnhängndr Graph btrachtt, wshalb drartig Komponntn innrhalb inr Architktur nicht valid wär. Bi dr Tstfallntwicklung fil auf, dass das intrn Komponntnvrhaltn bkannt sin muss, da diss di bschribn Kommunikation binflusst. Witrhin ist di manull Entwicklung dr Tstfäll shr zitaufwndig, da gignt Sznarin konzipirt und als MSC umgstzt wrdn müssn. Glichzitig müssn vrschidn Tstkritrin, daruntr das Tstndkritrium dr Konnktorabdckung, rfüllt wrdn. Mit stigndr Zahl dr Tstfäll sinkt di Übrsichtlichkit, wlch Tstsznarin brits rfüllt wurdn und wlch durch in nus Tstmodll nu hinzukommn. Dis rschwrt di Katgorisirung. Ebnfalls wurd bim Entwickln dr Tstfäll fstgstllt, dass nicht jdr Konnktor durch in MSC abdckt wrdn kann. Dis bgründt sich daraus, dass s Konnktorn gibt, di nach dr Spzifikation dr Komponntn und drn Funktionalitätn nicht zur Kommunikation mit andrn Komponntn dinn bzw. kin Auswirkung auf andr Komponntn habn. Si sind somit nicht durch positiv Tstfäll prüfbar. Ein Bispil für inn solchn Konnktor wär car_lock, dn di Komponnt CLS bsitzt, wnn das Fatur Automatic Locking ausgwählt wurd. Drartig Konnktorn sind als Ausnahmn zu btrachtn und müssn durch inn zuvor stattfindndn Komponntntst gprüft wrdn. Auch bi dr Auswrtung, wlch dr widrvrwndbarn Tstfäll rnut gtstt 108

127 7.2 Ausblick wrdn müssn, fil in hohr Arbitsaufwand auf, da di inzlnn Komponntn auf ihr Schnittstlln in dn jwilign Produktn gprüft wrdn musstn. Dr Aufwand für di Tstfallntwicklung ist dnnoch grchtfrtigt, da di igntlich Anzahl dr ausgführtn Tstfäll nidrigr als bi andrn, naivn Vrfahrn ausfil. 7.2 Ausblick Nachdm das angstrbt Tstvrfahrn konzipirt und valuirt wurd, solln nun möglich Erwitrungn für zukünftig Arbitn vorgstllt wrdn. Für di gwählt Tststratgi kann di Tstfallntwicklung vrbssrt wrdn. Für di Fallstudi wurdn nur positiv Tstfäll btrachtt, d.h. Tstfäll di das Vorhandnsin von Kommunikation prüfn. Für zukünftig, praxisorintirt Ansätz wär s möglich, auch ngativ Tstfäll zu rstlln. Dis tstn di Komponntn auf das Nichtvorhandnsin von Kommunikation. Drartig Tsts sind für di Praxis als durchaus sinnvoll inzustufn, da so gprüft wrdn kann, ob s zu unrwünschtn Sitnffktn kommt. Witrhin wär s dnkbar dn pair-wis-tstkritrium [45] für Konnktorabdckung umzustzn. Es wird somit das Tstn jds möglichn Konnktorpaars gfordrt. Es bsitzt somit inn noch stärkrn Abdckungsgrad als di in dr Arbit ingstzt Konnktorabdckung, bi dr Konnktorn in blibigr Art gtstt wrdn konntn, untr dr Bdingung, dass jdr Konnktor mindstns inmal btrachtt wurd. Das implmntirt Plugin bsitzt bnfalls in Mng von Erwitrungsmöglichkitn. Ein Erwitrung ds Editors durch dn Einsatz von Xtnd [1] könnt zu inr frühzitign, komplxrn Fhlrrknnung währnd dr Dfinition ds Krns und dr Dltas führn. Es wär möglich, di Angab dr Application Condition innrhalb dr Dltas zur Laufzit auf Korrkthit zu prüfn. Ein grafisch Rpräsntation dr rstlltn bzw. gnrirtn Tstmodll als Architkturdiagramm wär dnkbar. Auch in automatisirt Tstfallgnrirung kann als langfristigs Zil gstzt wrdn, bnötigt jdoch noch witr Forschung im Brich dr Abdckungskritrin und automatischn MSC-Gnrirung für Softwararchitkturn. Dafür wär in Vrbindung mit dr intrnn Statchartrpräsntation [30] dr inzlnn Komponntn notwndig, um das gnau Komponntnvrhaltn bstimmn zu könnn. Di Ausführung dr Tstfäll könnt bnfalls durch in Wrkzug umgstzt wrdn, so wär s bispilswis dnkbar, Tstläuf in dm UML-Modllirungswrkzug IBM Rhapsody [26] durchführn zu könnn, um ral Tstrgbniss für di inzlnn Produkt zu rhaltn. Rhapsody rmöglicht s UML-Diagramm zu modllirn und bitt di Möglichkit inr Codgnrirung an, um di Modll in ausführbar Programm zu transformirn. Mit Hilf dr Erwitrung TstConductor ist s möglich, Tstfäll auf Modlln auszuführn. Es wär zu prüfn, inwifrn dis für di Modll dr Arbit umstzbar wär. Darauf aufbaund könnt in automatisch Tstfallauswrtung angstrbt wrdn, um di Ergbniss dr Tstläuf wrkzuggstützt auszuwrtn, und Fhlvrhaltn 109

128 7 Fazit und Ausblick ntggn dr Produktspzifikation aufzudckn. Witr Evaluationn sind notwndig, um di Ergbniss disr Arbit zu prüfn und zu fstign. Es solltn Vrändrungn in das Vrfahrn intgrirt wrdn, um dssn Wirksamkit übrprüfn zu könnn. 110

129 Litratur [1] XTxt Documntation, 72, 73, 109 [2] ; Th Institut of Elctrical and Elctronics Ehginrs (IEEE) (Vranst.): IEEE Standard Glossary of Softwar Enginring Trminology. 28. Sptmbr [3] ; IEEE (Vranst.): IEEE Rcommndd Practic for Architctural Dscription of Softwar-Intnsiv Systms - Standard , 28 [4] Volkswagn Konfigurator, [5] Stand: [6] Adámk, Jiří: Thortisch Informatik - Vorlsungsskript [7] Alln, Robrt ; Garlan, David: Byond Dfinition / Us: Architctural Intrconnction / Computr Scinc Dpartmnt, Carngi Mllon Univrsity (725). Forschungsbricht 35 [8] Apl, Svn ; Kästnr, Christian: An Ovrviw of Fatur-Orintd Softwar Dvlopmnt. In: Journal of Objct Tchnology 8 (2009), Nr. 5, S [9] Brown, Alan W. ; Wallnau, Kurt C.: Th Currnt Stat of CBS, , 29 [10] Caldr, Muffy ; Kolbrg, Mario ; Magill, Evan H. ; Riff-Marganic, Stphan: Fatur Intraction: A Critical Rviw and Considrd Forcast / adpartmnt of Computing Scinc, Univrsity of Glasgow, Unitd Kingdom Forschungsbricht 12 [11] Cichos, Harald ; Ostr, Sbastian ; Lochau, Malt ; Schürr, Andy: Extndd Vrsion of Modl-basd Covrag-Drivn Tst Suit Gnration for Softwar Product Lins. In: Procdings of th 14th intrnational confrnc on Modl drivn nginring languags and systms MODELS 11, Brlin, hidlbrg: Springr-Vrlag, , 57, 66 [12] Clmnts, Paul C.: A Survy of Architctur Dscription Languags. In: Intrnational Workshop on Softwar Spcification and Dsign 8 (1996), S

130 Litratur [13] Dursn, Ari van ; Klint, Paul ; Vissr, Joost: Domain-Spcific Languags: An Annotatd Bibliography 18 [14] Eclips Modling Framwork: Wbsit: , 73, 83 [15] Engström, Emli: Exploring Rgrssion tsting and softwar product lin tsting - rsarch and stat of practic, Lund Univrsity, Lic Dissrtation, May , 2, 23, 24, 106, 107 [16] Frbr, Stfan ; Haag, Jürgn ; Savolainn, Juha: Fatur Inraction and Dpndcis: Modling Faturs for Rnginring a Lgacy Product Lin. In: Procdings of th Scond Intrnational Confrnc on Softwar Product Lins SPLC 2, Springr-Vrlag Brlin Hidlbrg, 2002, S [17] Galstr, Matthias ; Avgriou, Paris: Handling Variability in Softwar Architctur: Problms and Implications. In: 2011 Ninth Working Confrnc on Softwar Architctur, [18] Garlan, David ; Monro, Robrt ; Wil, David: ACME: An Architctur Dscription Intrchang Languag / Computr Scinc Dpartmnt - Carngi Mllon Univrsity Forschungsbricht 30 [19] Garlan, David ; Shaw, Mary: An Introduction to Softwar Architctur / School of Computr Scinc - Carngi Mllon Univrsity, Pittsburgh Forschungsbricht 28, 31 [20] Grman Tsting Board: Basiswissn Softwartst - Crtifid Tstr , 20, 21, 23 [21] Grau, Andras ; Shihada, Basm ; Soliman, Mohamnd: Architctural Dscription Languags and thir Rol in Componnt Basd Dsign / Univrsity of Watrloo Forschungsbricht 28 [22] Grindal, Mats ; Offutt, Jff ; Andlr, Stn F.: Combination Tsting Stratgis: A Survy. In: Softwar Tsting, Vrification, and Rliability 15. John Wily & Sons, Ltd., 2005, S [23] Harl, David: Statcharts: A Visual Formalism for Complx Systms. In: Scinc of Computr Programming 8 (1987), Juni, Nr. 3, S [24] Harl, David ; Thiagarajan, P.S.: Mssag Squnc Charts. April [25] Harrold, Mary J. ; Gupta, Rajiv ; Soffa, Mary L.: A Mthodology for Controlling th Siz of a Tst Suit. In: ACM Transactions on Softwar Enginring and Mthodology Bd , S [26] IBM Rhapsody.: Wbsit:

131 Litratur [27] Kang, Kyo C. ; Cohn, Sholom G. ; Hss, Jams A. ; Novak, William E. ; Ptrson, A. S.: Fatur-Orintd Domain Analysis (FODA) Fasibility Study / Softwar Enginring Institut - Carngi Mllon Univrsity Forschungsbricht 9, 10 [28] Lung, Harton K. N. ; Whit, L: Insights into Rgrssion Tsting. In: Procdings of th Confrnc on Softwar Maintnanc, 1989, S , 107 [29] Liggsmyr, Ptr: Softwar-Qualität - Tstn, Analysirn und Vrifizirn von Softwar. Spktrum, , 2, 18, 19, 22, 23, 57 [30] Lity, Sascha: Konzption und Evaluation ins dlta-orintirtn modllbasirtn Tstvrfahrns für Softwarproduktlinin, TU Braunschwig, Mastrarbit, , 2, 14, 21, 44, 61, 64, 66, 72, 76, 82, 87, 89, 91, 96, 109 [31] Lochau, Malt ; Lity, Sascha ; Schafr, Ina ; Lachmann, Rmo ; Goltz, Ursula: Architctur-drivn Modl-basd Tsting of Dlta-orintd Softwar Product Lins. unpublishd 54, 55, 56 [32] Lochau, Malt ; Müllr, Tobias C. ; Stinr, Jns ; Goltz, Ursula ; Form, Thomas: Optimirung von AUTOSAR-Systmn durch automatisirt Architktur-Evaluation. In: 14. Intrnational Konfrnz Elktronik im Kraftfahrzug Bd. VDI-Bricht 2075, VDI Wissnsforum GmbH, 2009, S. S [33] Lochau, Malt ; Ostr, Sbastian ; Goltz, Ursula ; Schürr, Andy: Modlbasd pairwis tsting for fatur intraction covrag in softwar product lin nginring. In: Softwar Quality Journal, , 60 [34] Lochau, Malt ; Schafr, Ina ; Kamischk, Jochn ; Lity, Sascha: Incrmntal Modl-basd Tsting of Dlta-orintd Softwar Product Lins. In: 6th Intrnational Confrnc on Tsts & Proofs. Pragu, [35] Luchham, David C. ; Knny, John J. ; Augustin, Larry M. ; Vra, Jams ; Bryan, Doug ; Mann, Waltr: Spcification and Analysis of Systm Architctur Using Rapid. In: IEEE Transactions on softwar nginring 21 (1995), April, Nr. 4, S , 34 [36] Mag, Jff ; Dulay, Narankr ; Eisnbach, Susan ; Kramr, Jff: Spcifiying Distributd Softwar Architcturs. In: Fifth Europan Softwar Enginring Confrnc ESEC ESEC, , 32 [37] McInnis, Kirby: Componnt-basd Dvlopmnt: Th Concpts, Tchnology and Mthodology

132 Litratur [38] Mdvidovic, Nnad ; Rosnblum, David S.: Domains of Concrn in Softwar Architcturs and Architctur Dscription Languags. In: USENIX Confrnc on Domain-Spcific Languags, [39] Mdvidovic, Nnad ; Taylor, Richard N.: A Framwork for Classifying and Comparing Architctur Dscription Languags / Univrsity of California at Irvin Forschungsbricht 29, 30, 77 [40] Milnr, Robin: Lctur Nots in Computr Scinc. Bd. 92: A Calculus of Communicating Systms. Springr Vrlag, [41] Müllr, Tobias C. ; Lochau, Malt ; Dtring, Stfan ; Saust, Falko ; Garbrs, Hnning ; Märtin, Lukas ; Form, Thomas ; Goltz, Ursula: Umstzung ins modllbasirtn durchgängign Entwicklungsprozsss für AUTOSAR-Systm mit intgrirtr Qualitätssichrung, TU Braunschwig, Informatik-Rport, Dzmbr [42] Naslavsky, Lila ; Ziv, Hadar ; Richardson, Dbra J.: A Modl-Basd Rgrssion Tst Slction Tchniqu. In: IEEE IntrnationalConfrnc on Softwar Maintnanc, ICSM, [43] OMG: UML, Vrsion 2.4.1, OMG Spcifcation Suprstructur and Infrastructur, May , 30, 77 [44] Ostr, Sbastian ; Markrt, Florian ; Rittr, Philipp: Automatd Incrmntal Pairwis Tsting of Softwar Product Lins. In: Procdings of th 14th intrnational confrnc on Softwar product lins: going byond SPLC 10, Brlin, Hidlbrg: Springr-Vrlag, , 61, 62, 106, 107 [45] Ostr, Sbastian ; Zink, Marius ; Lochau, Malt ; Grchanik, Mark: Pairwis Fatur-Intraction Tsting for SPLs: Potntials and Limitations. In: Procdings of th 15th Intrnational Softwar Product Lin Confrnc SPLC 11, Nw York, NY, USA : ACM, , 13, 109 [46] Pohl, Klaus ; Böckl, Güntr ; Lindn, Frank van d.: Softwar Product Lin Enginring. Springr, 2005 xiv, 1, 5, 6, 7, 8, 69 [47] Russnr, Ralf ; Hasslbring, Wilhlm (Hrsg.): Handbuch dr Softwar- Architktur. dpunkt.vrlag, , 18, 32, 33 [48] Schafr, Ina: Variability Modlling for Modl-Drivn Dvlopmnt of Softwar Product Lins. In: VaMoS, 2010, S , 13, 45, 106 [49] Schafr, Ina ; Bttini, Lornzo ; Damiani, Frruccio: Compositional typchcking for dlta-orintd programming. In: Procdings of th tnth intrnational confrnc on Aspct-orintd softwar dvlopmnt ACM,

133 Litratur [50] Schafr, Ina ; Damiani, Frruccio: Pur Dlta-orintd Programming. In: Scond Intrnational Workshop on Fatur-orintd Softwar Dvlopmnt (FOSD 2010), , 52, 76 [51] Schafr, Ina ; Worrt, Alxandr ; Potsch-Hfftr, Arnd: A Modl-Basd Framwork for Automatd Product Drivation. In: Intrnational Workshop on Modl-drivn Approachs in Softwar Product Lin Enginring (MAPLE 2009), , 40, 106 [52] Schäuffl, Jörg ; Zurawka, Thomas: Automotiv Softwar Enginring: Grundlagn, Prozss, Mthodn und Wrkzug ffizint instzn. Viwg+Tubnr Vrlag, , 22 [53] Shaw, Mary: Toward highr-lvl abstractions for softwar systms. In: Data & Knowldg Enginring 5 (1990), S [54] Th Eclips Foundation: Eclips documntation, 71 [55] Utting, Mark ; Lgard, Bruno: Practical Modl-basd Tsting. Morgan Kaufmann, , 2, 18, 24, 25, 26, 106 [56] Zink, Marius: Anwndung von MoSo-PoLiT in inr Automotiv SPL, Tchnisch Univrsität Darmstadt, Mastrarbit, , 9, 14, 16, 62, 89,

134 A Anhang A.1 Klassndiagramm ds Plugins Abbildung A.1: Klassndiagramm ds Dltarx-Plugins 116