Za´padoˇceska´ univerzita v Plzni Fakulta aplikovany´ch vˇed Katedra informatiky a vy´poˇcetn´ı techniky
Diplomov´ a pr´ ace N´ astroj pro modelov´ an´ı vlastnost´ı software
Plzeˇ n, 2013
Jan Pikl
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou pr´aci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 13. kvˇetna 2013 Jan Pikl
Podˇ ekov´ an´ı Na tomto m´ıstˇe bych pˇredevˇs´ım r´ ad podˇekoval vedouc´ımu m´e diplomov´e pr´ace Ing. Ondˇreji Rohl´ıkovi, Ph.D. za jeho ochotu, cenn´e rady a pˇripom´ınky pˇri tvorbˇe t´eto pr´ace. D´ale bych chtˇel podˇekovat m´e rodinˇe a pˇr´ atel˚ um za jejich podporu bˇehem studia.
Abstract Feature Modeling Tool This work focuses on feature modeling and its tool support. The first part of the work evaluates state of the art in the field of feature modeling tools. It begins with a brief introduction to feature modeling and its historical and current development. It also offers overview of the currently available software tools. The second part defines requirements for a modern feature modeling tool, based on the review introduced earlier, and describes its implementation. This work also contains collection of sample feature models illustrating capabilities of the implemented tool.
´ 1 Uvod Modelov´ an´ı vlastnost´ı je ˇcinnost, kter´a n´am umoˇzn ˇuje zachytit variabilitu v r´amci sloˇzit´eho syst´emu. Z´ akladn´ım prvkem t´eto ˇcinnosti je tvorba tzv. modelu vlastnost´ı, jeˇz urˇcuje shodnosti a r˚ uznorodosti mezi jednotliv´ ymi variantami popisovan´eho objektu. Tyto varianty jsou mezi sebou rozliˇseny pomoc´ı jejich d˚ uleˇzit´ ych charakteristik, oznaˇcovan´ ych jako vlastnosti. Principy modelov´ an´ı vlastnost´ı jsou obecn´e a daj´ı se pouˇz´ıt v r˚ uzn´ ych oblastech, jako je napˇr´ıklad pr˚ umyslov´a v´ yroba ˇci v´ yvoj software, tedy zejm´ena tam, kde m˚ uˇze doch´azet ke vzniku r˚ uzn´ ych variant vytv´aˇren´eho produktu. Tato pr´ ace se zab´ yv´ a problematikou modelov´an´ı vlastnost´ı, zejm´ena pak jeho podporou ze strany softwarov´ ych n´ astroj˚ u. C´ılem t´eto pr´ace je n´avrh a implementace n´astroje pro modelov´ an´ı vlastnost´ı, kter´ y by splˇ noval stanoven´e poˇzadavky. ˇ aˇr je v u Cten´ ´vodn´ı ˇc´ asti nejprve sezn´amen s principy modelov´an´ı vlastnost´ı, jeho historick´ ym a souˇcasn´ ym v´ yvojem a jeho uplatnˇen´ım v oblasti softwarov´eho inˇzen´ yrstv´ı. D´ale jsou mu pˇredstaveny nˇekter´e dostupn´e modelovac´ı n´astroje a je provedeno jejich srovn´an´ı a zhodnocen´ı. V n´ asleduj´ıc´ıch kapitol´ach jsou pak diskutov´any poˇzadavky kladen´e na modelovac´ı n´ astroj, reflektuj´ıc´ı souˇcasn´ y v´ yvoj v oblast´ı modelov´an´ı vlastnost´ı. Zb´ yvaj´ıc´ı ˇc´ast pr´ace se zab´ yv´ a n´ avrhem a popisem implementace n´astroje, splˇ nuj´ıc´ım vybranou podmnoˇzinu tˇechto poˇzadavk˚ u. Souˇc´ ast´ı pr´ace je tak´e sada pˇr´ıklad˚ u demonstruj´ıc´ıch pouˇzitelnost v´ ysledn´eho ˇreˇsen´ı.
7
2 Modelov´an´ı vlastnost´ı C´ılem t´eto kapitoly je sezn´ amit ˇcten´aˇre se z´akladn´ımi principy modelov´an´ı vlastnost´ı a jeho souvislost´ı se softwarov´ ym inˇzen´ yrstv´ım. Kapitola pak d´ale tak´e mapuje historick´ ya souˇcasn´ y v´ yvoj v oblasti modelov´an´ı vlastnost´ı.
2.1
Motivace
V oblasti v´ yroby, at’ uˇz napˇr´ıklad pr˚ umyslov´e ˇci jin´e, se ˇcasto setk´av´ame s pojmem rodina produkt˚ u (z angl. product family), naz´ yvan´ ym nˇekdy tak´e jako produktov´ a ˇrada (z angl. product line)1 . Tento pojem oznaˇcuje skupinu produkt˚ u, kter´e jsou postaveny na spoleˇcn´em z´akladu, ale liˇs´ı mezi sebou v nˇekter´ ych vlastnostech. Pˇr´ıkladem takov´e rodiny produkt˚ u m˚ uˇze b´ yt napˇr´ıklad v´ yroba automobil˚ u, kdy v´ yrobce dod´av´a na trh nˇekolik variant t´ehoˇz modelu odliˇsuj´ıc´ıch se v r˚ uzn´ ych detailech (v´ ykon, barva karoserie, pˇr´ısluˇsenstv´ı). Jin´ ym pˇr´ıkladem m˚ uˇze b´ yt v´ yroba hardware, kdy jeden produkt m˚ uˇze m´ıt opˇet nˇekolik variant (viz tab. 2.1). Oznaˇ cen´ı i5-2320 i5-2550K i5-660 i5-680 i5-760
Z´ akladn´ı frekvence (GHz) 3 3,4 3,33 3,6 2,8
Velikost cache (MB) 6 6 4 4 8
Poˇ cet jader 4 4 2 2 4
Integrovan´ a GPU Ano Ne Ano Ano Ne
AES Ano Ano Ano Ano Ne
Tabulka 2.1: Uk´ azka rodiny produkt˚ u CPU Intel Core i5. Z uveden´eho pˇr´ıkladu je vidˇet, ˇze vlastnosti (sloupce), ve kter´ ych jednotliv´e varianty (ˇr´adky) odliˇsuj´ı, mohou m´ıt r˚ uzn´ y charakter. Typicky mohou b´ yt vlastnosti v dan´e variantˇe pˇr´ıtomny ˇci nepˇr´ıtomny (integrovan´a GPU), nebo mohou b´ yt vyj´adˇreny napˇr´ıklad ˇc´ıselnou hodnotu (frekvence CPU). D˚ uleˇzit´e je si uvˇedomit, ˇze jednotliv´e vlastnosti nemus´ı b´ yt nez´ avisl´e, ale mohou b´ yt navz´ajem prov´az´any (napˇr´ıklad podpora AES m˚ uˇze vyˇzadovat frekvenci CPU vyˇsˇs´ı neˇz 3GHz). Prostˇredek, kter´ y dok´aˇze popsat jednotliv´e vlastnosti a jejich vz´ ajemn´e vazby, je tzv. model vlastnost´ı.
2.2
Dom´ enov´ e inˇ zen´ yrstv´ı
Jeˇstˇe neˇz form´ alnˇe definuje pojem model vlastnost´ı, uved’me jej nejprve do kontextu softwarov´eho inˇzen´ yrstv´ı. V pˇredchoz´ım textu jsme uvedli nˇekolik pˇr´ıklad˚ u rodin produkt˚ u z oblasti v´ yroby, avˇsak tento princip se d´ a stejn´ ym zp˚ usobem aplikovat i na v´ yvoj software. Vezmˇeme si 1
Aˇckoliv b´ yvaj´ı tyto pojmy mezi sebou ˇcasto zamˇen ˇov´ any, nemusej´ı vˇzdy vyjadˇrovat to sam´e. Pˇr´ıkladem by mohla b´ yt produktov´ a ˇrada skl´ adaj´ıc´ı se z nˇekolika odliˇsn´ ych rodin produkt˚ u.
8
Modelov´ an´ı vlastnost´ı
Dom´enov´e inˇzen´yrstv´ı
napˇr´ıklad nˇejak´ y komplexn´ı informaˇcn´ı syst´em. Takov´ y syst´em se bude pravdˇepodobnˇe skl´adat z vˇetˇs´ıho poˇctu komponent, kdy kaˇzd´a komponenta implementuje r˚ uznou funkcionalitu a nˇejak´ ym zp˚ usobem z´ avis´ı i na ostatn´ıch komponent´ach. Pˇrid´an´ım nebo odebr´an´ım pouˇzit´ ych komponent doc´ıl´ıme r˚ uzn´ ych variant p˚ uvodn´ı aplikace, kter´e se liˇs´ı v nˇekter´ ych vlastnostech. Soubor syst´em˚ u, kter´e se daj´ı t´ımto zp˚ usobem zkonstruovat, pak naz´ yv´ame jako rodina softwarov´ych produkt˚ u (z angl. software product family) ˇci nˇekdy tak´e jako produktov´ a ˇrada software (z angl. software product line, zkr´acenˇe SPL). Proces, jehoˇz u ´ˇcelem je v´ yvoj pr´avˇe takov´ ych rodin produkt˚ u, se naz´ yv´a dom´enov´e inˇzen´yrstv´ı (z angl. domain engineering 2 ). Pˇresnou definici tohoto pojmu nalezneme napˇr´ıklad v [Cza00]: Dom´enov´e inˇzen´ yrstv´ı je proces shromaˇzd’ov´an´ı, organizov´an´ı a uchov´av´an´ı poznatk˚ u z´ıskan´ ych pˇri vytv´aˇren´ı syst´em˚ u nebo jejich ˇc´ast´ı v dan´e oblasti (dom´enˇe) ve formˇe znovupouˇziteln´ ych prvk˚ u (napˇr. komponent), stejnˇe tak poskytnut´ı adekv´ atn´ıch prostˇredk˚ u (napˇr. vyhled´an´ı, kvalifikace, rozˇsiˇrov´an´ı, u ´pravy, sestaven´ı) pro znovupouˇzit´ı tˇechto prvk˚ u pˇri vytv´aˇren´ı syst´em˚ u nov´ ych. Hlavn´ım rozd´ılem oproti konvenˇcn´ımu pˇr´ıstupu, kdy se snaˇz´ıme na z´akladˇe poˇzadavk˚ u z´akazn´ıka vytvoˇrit (jedin´ y) c´ılov´ y syst´em, je zde snaha vytvoˇrit znovupouˇziteln´e celky pro tvorbu cel´e rodiny takov´ ych syst´em˚ u v dan´e dom´enˇe. Tento pˇr´ıstup m˚ uˇzeme ilustrovat obr´azkem 2.1, pˇrevzat´ ym z [Pas05].
Aplikace z rodiny produktů
Znovupoužitelné celky
Obr´ azek 2.1: Tvorba rodiny SW produkt˚ u ze znovupouˇziteln´ ych celk˚ u. Abychom lep´e pochopili vztah mezi dom´enov´ ym inˇzen´ yrstv´ım a modelov´an´ım vlastnost´ı, pop´ıˇseme detailnˇeji proces v´ yvoje rodin SW produkt˚ u, tak jak je uveden v [Cza00]. Pro ilustraci cel´eho procesu n´ am poslouˇz´ı obr´azek 2.2, pˇrevzat´ y ze zm´ınˇen´e publikace. 2
Oznaˇcovan´ y tak´e jako product line engineering ˇci product family engineering
9
Modelov´ an´ı vlastnost´ı
Dom´enov´e inˇzen´yrstv´ı
Doménové inženýrství Architektura rodiny produktů
Doménový model
Doménové znalosti
Doménová analýza
Doménová implementace
Doménový návrh
DSL Komponenty Generátory Nové požadavky
Potřeby zákazníka
Analýza požadavků
Návrh dodatečné funkcionality
Vývoj dodatečné funkcionality
Integrace a testování
Konfigurace produktu Konfigurace produktu
Vlastnosti
Aplikační inženýrství
Výsledný produkt
Obr´ azek 2.2: V´ yvoj software zaloˇzen´ y na dom´enov´em inˇzen´ yrstv´ı. Dom´ enov´ e inˇ zen´ yrstv´ı Jak jiˇz bylo zm´ınˇeno, v tomto procesu doch´az´ı k vytvoˇren´ı znovupouˇziteln´ ych celk˚ u urˇcen´ ych pro tvorbu aplikac´ı v dan´e dom´enˇe. Tento proces, oznaˇcovan´ y tak´e jako engineering for reuse, se skl´ad´a celkem ze 3 ˇc´ast´ı: • Dom´enov´ a anal´yza: Je vybr´ana a zmapov´ana c´ılov´a dom´ena. Jej´ım v´ ystupem je dom´enov´ y model popisuj´ıc´ı danou dom´enu (jej´ı rozsah, data, vlastnosti atd.). • Dom´enov´y n´ avrh: Je navrˇzena spoleˇcn´a architektura pro syst´emy v dan´e dom´enˇe a sestrojen pl´ an produkce. • Dom´enov´ a implementace: Navrˇzen´a architektura je implementov´ana v podobˇe znovupouˇziteln´ ych celk˚ u (napˇr. komponent, DSL3 , gener´ator˚ u k´odu atd.). Je vytvoˇrena celkov´ a infrastruktura a proces produkce. Aplikaˇ cn´ı inˇ zen´ yrstv´ı Zde dojde k sestaven´ı konkr´etn´ı aplikace dle poˇzadavk˚ u z´akazn´ıka z celk˚ u vytvoˇren´ ych bˇehem dom´enov´eho inˇzen´ yrstv´ı. Analogicky k pˇredchoz´ımu je tento proces oznaˇcov´ an jako engineering by reuse. • Anal´yza poˇzadavk˚ u: Jsou analyzov´any poˇzadavky z´akazn´ıka a urˇceny vlastnosti, kter´e m´ a m´ıt v´ ysledn´ y produkt. • Konfigurace produktu: Na z´akladˇe poˇzadovan´ ych vlastnost´ı jsou vybr´any celky pro implementaci produktu. Pˇr´ıpadnˇe je i proveden n´avrh chybˇej´ıc´ı celk˚ u. • Integrace a testov´ an´ı: Z vybran´ ych celk˚ u je sestaven v´ ysledn´ y produkt. Chybˇej´ıc´ı funkcionalita je doprogramov´ana. 3
Dom´enovˇe specifick´ y jazyk (domain specific language). Na rozd´ıl od univerz´ aln´ıho programovac´ıho jazyka je zamˇeˇren´ y na omezenou, konkr´etn´ı dom´enu.
10
Modelov´ an´ı vlastnost´ı
Modely vlastnost´ı
V popsan´em procesu je pro n´ as zaj´ımav´a ˇc´ast dom´enov´e anal´ yzy, kde doch´az´ı k vytvoˇren´ı dom´enov´eho modelu, jehoˇz souˇc´ ast´ı je pr´avˇe i model vlastnost´ı, zachycuj´ıc´ı r˚ uznorodosti a shodnosti mezi jednotliv´ ymi aplikacemi v rodinˇe SW produktu.
2.3
Modely vlastnost´ı
Poprv´e byly modely vlastnost´ı a jejich pouˇzit´ı ve spojitosti s dom´enov´ ym inˇzen´ yrstv´ım pops´any v roce 1990 v [Kang90]. Od t´e doby byla tato p˚ uvodn´ı verze model˚ u vlastnost´ı r˚ uzn´ ymi autory rozˇsiˇrov´ ana, nebot’ se postupnˇe objevovaly skuteˇcnosti, kter´e p˚ uvodn´ı model nedok´ azal zachytit. Pro pˇrehlednost ale nejprve uved’me p˚ uvodn´ı model vlastnost´ı, tak jak byl definov´ an ve zm´ınˇen´e publikaci.
2.3.1
Vlastnost
Vlastnost (z angl. feature) m˚ uˇzeme dle [Kang90] definovat jako parametr syst´emu, kter´ y pˇr´ımo ovlivˇ nuj´ı koncov´eho uˇzivatele. Jako pˇr´ıklad si m˚ uˇzeme pˇredstavit z´akazn´ıka vyb´ıraj´ıc´ıho konkr´etn´ı variantu dan´eho modelu automobilu. Vlastnosti, jeˇz m˚ uˇze br´at z´akazn´ık vu ´vahu, jsou napˇr´ıklad: • V´ ykon motoru. • Typ motoru (benz´ınov´ y, ˇci dieselov´ y). • Barva karoserie (1 z N nab´ızen´ ych moˇznost´ı). • To zda bude m´ıt v˚ uz automatick´e, ˇci ruˇcn´ı ˇrazen´ı. • To zda bude m´ıt v˚ uz klimatizaci ˇci ne. Ekvivalentnˇe bychom dok´ azali uv´est i pˇr´ıklady vlastnost´ı z oblasti v´ yvoje SW (napˇr. to zda bude/nebude dan´ y SW podporovat zabezpeˇcen´e pˇrihl´aˇsen´ı apod.). Jin´ı autoˇri, jako napˇr´ıklad [Cza00], uv´ adˇej´ı ponˇekud obecnˇejˇs´ı definici vlastnosti, a to jako d˚ uleˇzitou charakteristiku syst´emu, kter´ a je relevantn´ı vˇsem zainteresovan´ ym osob´am a jeˇz je urˇcena pro zachycen´ı shodnost´ı a r˚ uznorodost´ı mezi jednotliv´ ymi syst´emy z dan´e rodiny. Na rozd´ıl od t´e p˚ uvodn´ı zde jiˇz nen´ı kladen d˚ uraz na viditelnost vlastnosti pro koncov´eho z´akazn´ıka. Na uveden´em pˇr´ıkladu si tak´e vˇsimnˇeme r˚ uzn´eho charakteru popsan´ ych vlastnost´ı. Zat´ımco u nˇekter´ ych m˚ uˇzeme urˇcit pouze to, zda budou ve v´ ysledn´e variantˇe produktu zahrnuty ˇci ne, u jin´ ych m´ ame na v´ ybˇer z v´ıce moˇznost´ı. Mezi vlastnostmi m˚ uˇzou b´ yt nav´ıc definov´ any r˚ uzn´e vztahy a nelze je tedy vˇetˇsinou zachytit jako prost´ y v´ yˇcet. Pro jejich popis se pouˇz´ıv´ a pr´ avˇe zm´ınˇen´ y model vlastnost´ı.
2.3.2
Diagram vlastnost´ı
Model vlastnost´ı (z angl. feature model ) slouˇz´ı k popisu shodnost´ı a r˚ uznorodost´ı mezi jednotliv´ ymi syst´emy z dan´e rodiny produkt˚ u. Form´alnˇe se model vlastnost´ı skl´ad´a z 11
Modelov´ an´ı vlastnost´ı
Modely vlastnost´ı
diagramu vlastnost´ı (z angl. feature diagram), jeˇz graficky zn´azorˇ nuje jednotliv´e vlastnosti a jejich vazby, a dodateˇcn´ ych informac´ı, popisuj´ıc´ıch skuteˇcnosti, kter´e nebyly v diagramu zahrnuty. Jako uk´ azku diagramu vlastnost´ı uved’me pˇr´ımo pˇr´ıklad z [Kang90] (obr. 2.3). Z´akladn´ım rysem vˇsech model˚ u vlastnost´ı je, ˇze jednotliv´e vlastnosti jsou organizov´any hierarchicky a v´ ysledn´ y diagram m´ a tedy stromovou strukturu. Koˇren tohoto stromu reprezentuje popisovan´ y syst´em4 , ostatn´ı uzly pak jeho jednotliv´e vlastnosti5 . Kaˇzd´a vlastnosti by mˇela m´ıt jm´eno, kter´e odpov´ıd´a jej´ımu charakteru a kter´e ji jednoznaˇcnˇe odliˇsuje od ostatn´ıch vlastnost´ı. Pro kaˇzdou vlastnost d´ale plat´ı, ˇze m˚ uˇze b´ yt ve v´ ysledn´em syst´emu6 zahrnuta pouze tehdy, pokud je zde pˇr´ıtomn´a i j´ı pˇr´ımo nadˇrazen´a vlastnost (rodiˇc).
Automobil
Povinná vlastnost
Řazení
Ruční
Výkon
Volitelná vlastnost
Klimatizace
Automatické
Alternativní vlastnosti
Obr´ azek 2.3: Pˇr´ıklad diagramu vlastnost´ı (FODA notace). V diagramu se d´ ale pouˇz´ıvaj´ı nˇekter´a specifick´e grafick´e prvky. Vlastnost, kter´a je oznaˇcena pr´ azdn´ ym koleˇckem, naz´ yv´ ame jako volitelnou vlastnost (z angl. optional feature). U takov´e vlastnosti si m˚ uˇzeme zvolit, zda bude ve v´ ysledn´em syst´emu zahrnuta ˇci ne (za pˇredpokladu ˇze je zde pˇr´ıtomen i jej´ı rodiˇc). Analogicky k t´eto se zb´ yvaj´ıc´ı vlastnosti oznaˇcuj´ı jako povinn´e (z angl.mandatory features). Speci´aln´ım pˇr´ıpadem jsou pak tzv. alternativn´ı vlastnosti (z angl. alterative features), z nichˇz mus´ı b´ yt ve v´ ysledn´em syst´emu zahrnuta pr´ avˇe jedna. Poˇc´ ateˇcn´ı spojen´ı uzl˚ u tˇechto vlastnost´ı jsou propojena pr´azdnou v´ yseˇc´ı. Notace pouˇzit´ a v diagramu na obr´azku 2.3 se dle zdrojov´e publikace [Kang90] oznaˇcuje 4
Dle [Cza00] by mˇel koˇrenov´ y prvek oznaˇcov´ an jako konceptu´ aln´ı uzel (z angl. conceptual node), nebot’ pˇredstavuje zam´ yˇslen´ y koncept. Tento pojem je pˇrevzat´ y z oblasti konceptu´ aln´ıho modelov´ an´ı (z angl. conceptual modeling). 5 Tyto uzly oznaˇcujeme tedy jako uzly vlastnost´ı (z angl. feature nodes) 6 Dle [Cza00] bychom m´ısto mˇeli sp´ıˇse pouˇz´ıt term´ın popis instance dan´eho konceptu (z angl. description of an instance of a concept).
12
Modelov´ an´ı vlastnost´ı
Modely vlastnost´ı
jako FODA7 notace. Tato notace je jiˇz pomˇernˇe zastaral´a a byla pozdˇeji nahrazena notac´ı popsanou v [Cza98] a [Cza00]. M´ırnˇe modifikovan´ y diagram pouˇz´ıvaj´ıc´ı novˇejˇs´ı notaci m˚ uˇzeme vidˇet na obr´ azku 2.4. Hlavn´ım rozd´ılem je zde or´amov´an´ı jednotliv´ ych uzl˚ u a oznaˇcen´ı povinn´ ych vlastnost´ı vyplnˇen´ ym koleˇckem. Nav´ıc pˇribyl speci´aln´ı typ vlastnost´ı, tzv. sluˇciteln´e vlastnosti (z angl. or-features), oznaˇcen´e vyplnˇenou v´ yseˇc´ı. Pro danou mnoˇzinu sluˇciteln´ ych vlastnost´ı plat´ı, ˇze ve v´ ysledn´em syst´emu mus´ı b´ yt pˇr´ıtomna alespoˇ n jedna z nich. Z d˚ uvodu pˇrehlednost zanesme prvky t´eto notace a jejich v´ yznam do tabulky 2.2. Automobil
Střešní okénko
Řazení
Ruční
Pohon
Automatické
Benzín
Klimatizace
Elektřina
Obr´azek 2.4: Pˇr´ıklad diagramu vlastnost´ı (rozˇs´ıˇren´a notace autor˚ u Czarnecki, Eisenecker). Symbol
Pr´avˇe 1 z N vlastnost´ı mus´ı b´ yt vybr´ana, byl-li vybr´an jejich rodiˇc.
Sluˇciteln´e vlastnosti.
Alespoˇ n 1 z N vlastnost´ı mus´ı b´ yt vybr´ana, byl-li vybr´an jejich rodiˇc.
F
F
Tabulka 2.2: Pˇrehled prvk˚ u notace autor˚ u Czarnecki, Eisenecker. Pro u ´plnost je nezbytn´e poznamenat, ˇze volitelnost se d´a specifikovat i pro alternativn´ı a sluˇciteln´e vlastnosti a vznikaj´ı tak dalˇs´ı dva typy: voliteln´e alternativn´ı vlastnosti a voliteln´e sluˇciteln´e vlastnosti. Prvn´ı uveden´ y typ oznaˇcuje mnoˇzinu vlastnost´ı, z nichˇz m˚ uˇze 7
Z n´ azvu d´ıla Fature Oriented Domain Analysis.
13
Modelov´ an´ı vlastnost´ı
Modely vlastnost´ı
b´ yt ve v´ ysledn´em syst´emu pˇr´ıtomna nejv´ yˇse 1. Pokud m´ame mnoˇzinu alternativn´ıch vlastnost´ı, z nichˇz nˇekter´e jsou voliteln´e a jin´e povinn´e, je tato mnoˇzina ekvivalentn´ı mnoˇzinˇe alternativn´ıch vlastnost´ı, kde jsou voliteln´e vˇsechny (viz obr. 2.5). Druh´ y uveden´ y typ je v podstatˇe redundantn´ı, nebot’ je ekvivalentn´ı pouˇzit´ı (samostatn´ ych) voliteln´ ych vlastnost´ı, jak ukazuje obr´ azek 2.6. Oba zm´ınˇen´e obr´azky byly pˇrevzaty z [Cza00]. Proces transformace naznaˇcen´ y na tˇechto obr´azc´ıch naz´ yv´ame normalizac´ı diagramu vlastnost´ı. Pro pˇrehlednost uved’me kombinace vˇsech typ˚ u vlastnost´ı a jejich s´emantiku do tabulky 2.3 C
f1
f2
C
f3
f1
f2
f3
Obr´azek 2.5: Normalizace skupiny alternativn´ıch vlastnost´ı z nichˇz jen nˇekter´e jsou voliteln´e
C
f1
f2
C
f3
f1
f2
f3
Obr´azek 2.6: Normalizace skupiny sluˇciteln´ ych vlastnost´ı z nichˇz nˇekter´e jsou voliteln´e
Alternativn´ı vlastnosti Sluˇ citeln´ e vlastnosti
Voliteln´ a vlastnost Nejv´ yˇse 1 vlastnost z dan´e mnoˇziny mus´ı b´ yt vybr´ana. Nen´ı poˇzadavek na to kter´a vlastnost mus´ı b´ yt vybr´ana.
Povinn´ a vlastnost Pr´avˇe 1 vlastnost z dan´e mnoˇziny mus´ı b´ yt vybr´ana. Alespoˇ n 1 vlastnost z dan´e mnoˇziny mus´ı b´ yt vybr´ana.
Tabulka 2.3: Pˇrehled jednotliv´ ych kombinac´ı typ˚ u vlastnost´ı a jejich s´emantika.
14
Modelov´ an´ı vlastnost´ı
2.3.3
Modely vlastnost´ı
Doplˇ nuj´ıc´ı informace
Na zaˇc´ atku pˇredchoz´ı ˇc´ asti jsme zm´ınili, ˇze souˇc´ast´ı modelu vlastnost´ı nen´ı jen samotn´ y diagram, ale i r˚ uzn´e doplˇ nuj´ıc´ı u ´daje. N´asleduje v´ yˇcet takov´ ych moˇzn´ ych u ´daj˚ u, tak jak je uveden v [Kang90] a [Cza00]: • Popis s´emantiky: Kaˇzd´ a vlastnost by mˇela m´ıt alespoˇ n kr´atk´ y popis toho, co pˇredstavuje. Samotn´ y popis by nemusel obsahovat jen text, ale i jin´e prvky (napˇr. diagramy, pseudok´ od atd.). Popis by mˇel zajistit prov´az´an´ı vlastnosti s ostatn´ımi modely pouˇz´ıvan´ ymi pˇri v´ yvoji. • Od˚ uvodnˇen´ı: Zd˚ uvodnˇen´ı, proˇc je dan´a vlastnost v modelu zahrnuta. M˚ uˇze obsahovat doporuˇcen´ı, kdy a za jak´ ych podm´ınek vhodn´e je danou (volitelnou) vlastnost vybrat. • Zainteresovan´e osoby a aplikace: Seznam zainteresovan´ ych osob, pro kter´e je tato vlastnost d˚ uleˇzit´ a (napˇr. z´ akazn´ıci, uˇzivatel´e, v´ yvoj´aˇri atd.), pˇr´ıpadnˇe aplikace poˇzaduj´ıc´ı danou vlastnost (dan´a vlastnost pˇredstavuje funkcionalitu nˇejak´e komponenty). • Pˇr´ıklady syst´em˚ u: Pˇr´ıklady syst´emu, kter´e danou vlastnost implementuj´ı. • Priorita: Ohodnocen´ı, ud´ avaj´ıc´ı d˚ uleˇzitost vlastnosti v r´amci dan´eho projektu. • Otevˇrenost: Oznaˇcen´ı, zda bude dan´a vlastnost v budoucnu rozˇsiˇrov´ana (napˇr. o dalˇs´ı pod-vlastnosti). • Omezen´ı: Popis dalˇs´ı vazeb mezi jednotliv´ ymi vlastnostmi, kter´e neˇsly vyj´adˇrit grafickou notac´ı v diagramu. Pˇr´ıkladem (pro obr. 2.4) by mohl b´ yt napˇr´ıklad poˇzadavek klimatizace vyˇzaduje benz´ınov´y pohon (z´avislost), nebo nelze m´ıt z´ aroveˇ n stˇreˇsn´ı ok´enko a klimatizaci (vylouˇcen´ı). Tato pravidla a moˇznosti jejich z´apisu budou detailnˇeji diskutov´ ana v ˇc´ asti 2.8. • M´ısto dostupnosti : Definuje kdy, kde a komu je dan´a vlastnost v dom´enˇe dostupn´ a. • M´ısto vazby: Definuje kdy, kde a kdo m˚ uˇze danou vlastnost prov´azat se syst´emem. Rozliˇsujeme tˇri r˚ uzn´e okamˇziky, kdy m˚ uˇze k prov´az´an´ı doj´ıt: – Pˇri pˇrekladu: Pˇrekladaˇc zahrne danou vlastnost pˇri sestaven´ı aplikace. – Pˇri spuˇstˇen´ı: Vybran´e vlastnosti jsou do aplikace zahrnuty pˇri jej´ım spuˇstˇen´ı. – Za bˇehu: Vlastnost m˚ uˇze b´ yt za bˇehu aplikace interaktivnˇe aktivov´ana/deaktivov´ ana. • Zp˚ usob vazby: Urˇcuje, jak´ ym zp˚ usobem je prov´az´an´ı dan´e vlastnosti se syst´emem doc´ıleno. – Statick´ a vazba: Prov´ az´an´ı je urˇceno pˇredem. – Dynamick´ a vazba: Prov´az´an´ı je urˇceno v okamˇziku pouˇzit´ı.8 – Promˇenliv´ a vazba: Prov´az´an´ı z˚ ust´av´a mezi jednotliv´ ymi pouˇzit´ımi st´al´e, ale m˚ uˇze se zmˇenit. 8
Pˇr´ıkladem takov´e vazby m˚ uˇze b´ yt vol´ an´ı virtu´ aln´ıch metod v programovac´ıch jazyc´ıch C++ a Java.
15
Modelov´ an´ı vlastnost´ı
2.4
Modely vlastnost´ı s atributy
Modely vlastnost´ı s atributy
Od vzniku prvn´ıch definic modelu vlastnost´ı [Kang90], [Cza98] a [Cza00] se postupnˇe objevovaly skuteˇcnosti, kter´e takto definovan´ y model nedok´azal zachytit. Pˇr´ıkladem budiˇz potˇreba specifikovat v modelu ˇc´ıseln´e hodnoty (napˇr. v´ ykon automobilu). Aˇckoliv publikace [Kang90] asociaci ˇc´ıseln´e hodnoty s vlastnost´ı pˇr´ımo nevyluˇcovala, [Cza00] takovou moˇznost nijak neuvaˇzuje (u vlastnosti m˚ uˇzeme pouze specifikovat to, zda je v syst´emu zahrnuta ˇci ne). Nicm´enˇe, v pozdˇejˇs´ıch letech ti sam´ı autoˇri, na z´akladˇe praktick´ ych zkuˇsenost´ı, zav´ adˇej´ı jiˇz pojem atribut. Atribut je prvek, jeˇz slouˇz´ı k v´ ybˇeru jedn´e z vˇetˇs´ıho mnoˇzstv´ı hodnot z dan´e dom´eny. Publikace [Cza05b] uv´ ad´ı moˇznost asociovat s kaˇzdou vlastnost´ı jeden atribut zvolen´eho typu, jehoˇz hodnota je pak urˇcena pˇri konfiguraci dan´eho syst´emu. Typ atributu m˚ uˇze b´ yt bud’ element´ arn´ı (napˇr. ˇc´ıslo, ˇretˇezec), nebo m˚ uˇze pˇredstavovat odkaz (referenci) na jinou vlastnost, kter´ a je v dan´em syst´emu pˇr´ıtomna. V pˇr´ıpadˇe potˇreby m´ıt pro danou vlastnost specifikov´ ano v´ıce atribut˚ u se tyto atributy zavedou v podobˇe nˇekolika pod-vlastnost´ı (potomci dan´eho uzlu v diagramu vlastnost´ı). Pro ilustraci pouˇzit´ı atribut˚ u uved’me obr´azek 2.7 pouˇz´ıvaj´ıc´ı pro atributy notaci9 zavedenou v [Cza05b]. Pˇr´ıklad vlastnosti s atributem typu reference bude uveden pozdˇeji v ˇc´asti 2.8 po pˇredstaven´ı nˇekter´ ych dalˇs´ıch pojm˚ u. Jin´ı autoˇri, jako napˇr´ıklad [Pas05], naopak umoˇzn ˇuj´ı s jednou vlastnost´ı asociovat libovoln´ y poˇcet atribut˚ u, zde naz´ yvan´ ych jako properties. V n´astroji popsan´em v t´eto publikaci lze nav´ıc jednotliv´e atributy seskupovat do logick´ ych celk˚ u, oznaˇcovan´ ych jako property set. Autoˇri tento pˇr´ıstup od˚ uvodˇ nuj´ı praktick´ ym pouˇzit´ım, kdy re´aln´e modely vlastnost´ı mohou m´ıt i velk´ y poˇcet atribut˚ u na jednu vlastnost. Diagram takov´eho modelu by byl pˇri pouˇzit´ı pˇredchoz´ıho pˇr´ıstupu (maxim´alnˇe jeden atribut pro jednu vlastnost) velmi nepˇrehledn´ y. Automobil
Řazení
Ruční
Výkon (Integer)
Automatické
Pohon
Benzín
Barva karosérie (String)
Elektřina
Obr´ azek 2.7: Diagram vlastnost´ı obsahuj´ıc´ı atributy. 9ˇ Cten´ aˇr se m˚ uˇze pozastavit nad t´ım, ˇze v t´eto notaci nen´ı pro dan´ y atribut specifikov´ ano ˇza ´dn´e jm´eno, ale jen datov´ y typ. Vzhledem k tomu, ˇze vlastnost m˚ uˇze m´ıt pouze 1 atribut, je uveden´ı jeho jm´ena zbyteˇcn´e (s vlastnost´ı je defakto asociov´ an pouze typ atributu).
16
Modelov´ an´ı vlastnost´ı
2.5
Modely vlastnost´ı s kardinalitou
Modely vlastnost´ı s kardinalitou
Dalˇs´ı z ˇrady rozˇs´ıˇren´ı p˚ uvodn´ıho konceptu modelu vlastnost´ı bylo zaveden´ı tzv. kardinality pro jeho jednotliv´e prvky. Abychom lep´e pochopili d˚ uvod pro takov´e rozˇs´ıˇren´ı, pod´ıvejme nejprve se na obr´ azek 2.8a, obsahuj´ıc´ı diagram vlastnost´ı jednoduch´eho ˇr´ıd´ıc´ıho syst´emu. Vid´ıme, ˇze syst´em obsahuje sn´ımaˇc, kter´ y m˚ uˇze m´ıt bud’ ˇc´ast pro mˇeˇren´ı polohy, pohybu nebo teploty a volitelnˇe m˚ uˇze b´ yt schopen i autodiagnostiky. Probl´em nastane, pokud bychom potˇrebovali popsat ˇr´ıd´ıc´ı syst´em, jeˇz by mˇel takov´ ychto sn´ımaˇc˚ u nˇekolik a kde by kaˇzd´ y sn´ımaˇc mohl b´ yt nakonfigurov´an individu´aln´ım zp˚ usobem. S pouˇzit´ım p˚ uvodn´ı notace bychom museli m´ıt v diagramu nˇekolik identick´ ych podstrom˚ u a ani t´ım bychom vˇsak nedok´ azali zachytit poˇzadavek, kdy by mˇel b´ yt poˇcet takov´ ych sn´ımaˇc˚ u voliteln´ y. Na modifikovan´em obr´ azku 2.8b vid´ıme oznaˇcen´ı t´eto vlastnosti kardinalitou [1..4], kter´a n´ am ˇr´ık´ a, ˇze dan´ a vlastnost (sn´ımaˇc) mus´ı b´ yt ve v´ ysledn´em syst´emu zahrnuta v jedn´e aˇz ˇctyˇrech kopi´ıch, kde kaˇzd´a takov´a kopie m˚ uˇze b´ yt nakonfigurov´ana individu´ aln´ım zp˚ usobem. Obecnˇe vyjadˇrujeme kardinalitu vlastnosti jako interval ve tvaru [m..n], kde m je doln´ı a n horn´ı hranice poˇctu v´ yskyt˚ u dan´e vlastnosti v syst´emu (0 ≤ m ≤ n ∧ 0 < n). Nav´ıc je moˇzn´e m´ısto n dosadit z´astupn´ y symbol ∗, oznaˇcuj´ıc´ı neomezenou horn´ı hranici10 . D´ale si povˇsimnˇeme, ˇze voliteln´e a povinn´e vlastnosti jsou v t´eto interpretaci vlastnˇe speci´aln´ımi pˇr´ıpady vlastnost´ı s kardinalitou [0..1] a [1..1]. Pro tyto vlastnosti se vˇsak z d˚ uvodu pˇrehlednosti (a jejich ˇcast´eho pouˇzit´ı) vyuˇz´ıv´a v diagramu p˚ uvodn´ı notace (pr´azdn´e/vyplnˇen´e koleˇcko). Vlastnosti, kter´e maj´ı horn´ı mez kardinality vyˇsˇs´ı neˇz 1, oznaˇcujeme jako duplikovateln´e (z angl. clonnable). Dle doln´ı hranice je pak d´ale pˇresnˇeji rozdˇelujeme na voliteln´e duplikovateln´e (optional clonnable) a povinn´e duplikovateln´e (mandatory clonnable). V´ yˇse uveden´ y popis a notace je pˇrevzata z [Cza05b]. Samotn´a myˇslenka pouˇzit´ı kardinality pˇri popisu vlastnost´ı se ale prvnˇe objevila jiˇz v [Rieb02]11 , jej´ıˇz autoˇri se inspirovali UML notac´ı. Tato publikace vˇsak jeˇstˇe nezav´ad´ı kardinalitu pˇr´ımo, ale pouˇz´ıv´a ji jako prostˇredek pro zobecnˇen´ı pojm˚ u alternativn´ı a sluˇciteln´e vlastnosti. D˚ uvod pro toto zobecnˇen´ı m˚ uˇzeme uk´ azat na jiˇz zm´ınˇen´em obr´azku 2.8b. P˚ uvodn´ı notace n´am umoˇzn ˇuje zachytit pouze 4 (respektive 3) omezuj´ıc´ı podm´ınky, jak bylo uk´az´ano v tabulce 2.3. Pokud bychom tedy v r´ amci naˇseho pˇr´ıkladu potˇrebovali zachytit fakt, ˇze sn´ımaˇc m˚ uˇze m´ıt nejen 1, ale i 2 mˇeˇr´ıc´ı ˇc´ asti, museli bychom to vyj´adˇrit pomoc´ı dodateˇcn´ ych omezen´ı mimo diagram (viz podkapitola 2.8). Autoˇri [Rieb02] proto nahrazuj´ı alternativn´ı a sluˇciteln´e vlastnosti pojmem skupina vlastnost´ı (z angl. feature group), jeˇz pˇredstavuje mnoˇzinu vlastnost´ı (maj´ıc´ı spoleˇcn´eho rodiˇce), kter´ a m´ a specifikovanou kardinalitu. Kardinalitu skupiny vlastnost´ı zapisuje dle [Cza05b] jako interval ve tvaru hi − ji, s podobn´ ymi pravidly, kter´a platila pro kardinalitu vlastnost´ı. Pro danou skupinu vlastnost´ı s kardinalitou hi − ji pot´e plat´ı, ˇze ve v´ ysledn´em syst´emu mus´ı b´ yt z t´eto skupiny pˇr´ıtomno nejm´enˇe i a nejv´ıce pak j vlastnost´ı. Zde m˚ uˇzeme vidˇet, ˇze alternativn´ı a sluˇciteln´e vlastnosti lze vlastnˇe ch´apat jako speci´aln´ı pˇr´ıpad skupin s kardinalitou h1 − 1i a h1 − ki (kde k je velikost skupiny12 ). Pro tyto speci´aln´ı 10 ˇ
Cten´ aˇr sezn´ amen´ y s notac´ı UML si jistˇe povˇsiml, ˇze je tato notace v podstatˇe identick´ a. M´ısto cardinality zde bylo jeˇstˇe pouˇz´ıv´ ano oznaˇcen´ı multiplicity. 12 M´ısto k by zde ˇslo samozˇrejmˇe tak´e dosadit symbol ∗.
11
17
Modelov´ an´ı vlastnost´ı
Modely vlastnost´ı s kardinalitou
pˇr´ıpady, oznaˇcovan´e jako XOR skupina a OR skupina, se z d˚ uvodu pˇrehlednosti (a jejich ˇcast´eho pouˇzit´ı) pouˇz´ıv´ a v diagramu p˚ uvodn´ı notace (pr´azdn´a/vyplnˇen´a v´ yseˇc). Notaci pro obecnou skupinu lze vidˇet na obr. 2.8c. Řídící systém
Snímač
Snímač polohy
Snímač pohybu
CPU
Snímač teploty
Autodiagnostika
Velikost paměti (Integer)
(a) P˚ uvodn´ı notace.
Řídící systém
[1..4] Snímač
Snímač polohy
Snímač pohybu
CPU
Snímač teploty
Autodiagnostika
Velikost paměti (Integer)
(b) Nov´ a notace umoˇzn ˇuj´ıc´ı vyj´adˇrit n´asobnost vlastnosti.
Řídící systém
[1..4] Snímač
CPU
<1-2> Snímač polohy
Snímač pohybu
Snímač teploty
Autodiagnostika
Velikost paměti (Integer)
(c) Nov´a notace zav´adˇej´ıc´ı skupiny.
Obr´ azek 2.8: Zaveden´ı kardinality u diagramu vlastnost´ı.
18
Modelov´ an´ı vlastnost´ı
Symbol
F
F [0..n]
F
[m..n]
F
Modely vlastnost´ı s kardinalitou
Popis Samostatn´a vlastnost s kardinalitou [0..1], tedy voliteln´ a vlastnost. Samostatn´a vlastnost s kardinalitou [1..1], tedy povinn´ a vlastnost. Samostatn´a vlastnost s kardinalitou [0..n], 1 < n, tedy voliteln´ a duplikovateln´ a vlastnost. Samostatn´a vlastnost s kardinalitou [m..n], 1 < n ∧ 0 < m ≤ n, tedy povinn´ a duplikovateln´ a vlastnost. Seskupen´a vlastnost s kardinalitou [0..1].
F
Seskupen´a vlastnost s kardinalitou [1..1]. F
Vlastnost s atributem typu T a hodnotˇe value 13 . F (value: T)
Skupina vlastnost´ı s kardinalitou h1 − 1i, tedy XOR skupina. Skupina vlastnost´ı s kardinalitou h1 − ki (k je velikost skupiny), tedy OR skupina.
Skupina vlastnost´ı s kardinalitou hi − ji
Tabulka 2.4: Notace diagramu vlastnost´ı s kardinalitou. Modely vlastnost´ı vyuˇz´ıvaj´ıc´ı kardinalitu vlastnost´ı a skupin oznaˇcujeme dle [Cza04] souhrnnˇe jako modely vlastnost´ı s kardinalitou (z angl. cardinality-based feature models). Vlastnosti tohoto modelu pak rozdˇelujeme na tzv. seskupen´e (z angl. grouped ) a samostatn´e (z angl. solitary) dle toho, zda jsou, ˇci nejsou souˇc´ast´ı nˇejak´e skupiny. Zde je velmi d˚ uleˇzit´e upozornit na rozd´ıln´e ch´ap´an´ı seskupen´ ych vlastnost´ı oproti p˚ uvodn´ım pˇr´ıstupu. Pod´ıvejme se na obr´azek 2.8a ukazuj´ıc´ı starou notaci a 2.8c pouˇz´ıvaj´ıc´ı novou notaci popsanou v [Cza05b]. Zanedbejme nyn´ı rozd´ıln´ y v´ yznam alternativn´ıch vlastnost´ı (obr. 2.8a) a pouˇzit´e skupiny h1 − 2i (obr. 2.8c) a zamˇeˇrme se pouze na seskupen´e vlastnosti. Vid´ıme, ˇze alternativn´ı vlastnosti, kter´e byly v 2.8a povinn´e, jsou v 2.8c oznaˇceny jako voliteln´e. To je d´ ano t´ım, jak ch´apeme v´ yznam seskupen´ ych vlastnost´ı. Konkr´etn´ı 13
Hodnota atributu se uv´ ad´ı aˇz pˇri procesu konfigurace ˇci specializace, viz podkapitola 2.6.
19
Modelov´ an´ı vlastnost´ı
Konfigurace modelu vlastnost´ı
pˇr´ıpad na obr. 2.8c bychom interpretovali jako: skupina z n´ıˇz mus´ı b´ yt vybr´any 1-2 vlastnosti (kardinalita skupiny), kde kaˇzd´a vlastnost´ı mus´ı b´ yt v r´amci t´eto skupiny vybr´ana 0-1 kr´ at (kardinalita vlastnost´ı). Pokud bychom nˇejak´e ze seskupen´ ych vlastnost´ı pˇriˇraˇ aˇr dili kardinalitu [1..1], musela by b´ yt tato vlastnost v r´amci skupiny vybr´ana vˇzdy. Cten´ necht’ si porovn´ a tuto s´emantiku s p˚ uvodn´ım pˇr´ıstupem (tab. 2.3). Z d˚ uvodu tˇechto rozd´ıl˚ u proto [Cza05b] zav´ ad´ı pro seskupen´e vlastnosti odliˇsnou notaci, a to oznaˇcen´ı ˇctvereˇcky m´ısto koleˇcek (viz obr. 2.8c). Abychom shrnuli doposud uveden´a fakta, zobrazme prvky nov´e notace spolu s jejich popisem pˇrehlednˇe do tabulky 2.4 a jejich v´ yznam do tabulky 2.5. K t´eto notaci je d˚ uleˇzit´e zm´ınit nˇekolik omezen´ı. Za prv´e, vlastnost m˚ uˇze b´ yt souˇc´ast´ı pouze jedin´e skupiny. Druh´ ym omezen´ı je, ˇze seskupen´e vlastnosti mohou m´ıt kardinalitu pouze [0..1]14 a nelze je tedy duplikovat. Pokud bychom potˇrebovali m´ıt seskupenou vlastnost duplikovatelnou, museli bychom tento poˇzadavek realizovat v podobˇe jej´ı pod-vlastnosti, pro kterou jiˇz toto omezen´ı neplat´ı. Je zaj´ımav´e podotknout, ˇze napˇr´ıklad jin´ı autoˇri [Cech04] toto omezen´ı na seskupen´e vlastnost´ı nekladou. Prvek Vlastnost s kardinalitou [m..n].
Skupina vlastnost´ı s kardinalitou hi − ji.
V´ yznam Ve v´ ysledn´em syst´emu mus´ı b´ yt pˇr´ıtomno nejm´enˇe m a nejv´ıce pak n kopi´ı dan´e vlastnosti. Toto omezen´ı se vˇzdy vyhodnocuje v r´amci spoleˇcn´eho rodiˇcovsk´eho uzlu jednotliv´ ych vlastnost´ı. Z dan´e skupiny vlastnost´ı mus´ı b´ yt ve v´ ysledn´em syst´emu pˇr´ıtomno nejm´enˇe i a nejv´ıce pak j vlastnost´ı. Toto omezen´ı se vˇzdy vyhodnocuje v r´amci spoleˇcn´eho rodiˇcovsk´eho uzlu jednotliv´ ych vlastnost´ı.
Tabulka 2.5: S´emantika notace diagramu vlastnost´ı s kardinalitou. Na z´avˇer t´eto podkapitoly jeˇstˇe dodejme moˇznost dalˇs´ıho zobecnˇen´ı konceptu kardinality v modelu vlastnost´ı, tak jak ho popisuj´ı autoˇri [Cza04]. Kardinalita vlasnost´ı by mohla b´ yt ch´ap´ana ne jako jeden interval, ale jako sekvence nˇekolika interval˚ u. Napˇr´ıklad [1..1][5..10] by ud´avalo, ˇze se dan´ a vlastnost mus´ı ve v´ ysledn´em syst´emu objevit jednou ˇci 5-10 kr´at. Pro pouˇzit´ı tohoto principu i pro skupiny vˇsak sami autoˇri nevid´ı pˇr´ıliˇsn´e praktick´e uplatnˇen´ı.
2.6
Konfigurace modelu vlastnost´ı
V ˇc´asti 2.2 jsme popsali vyuˇzit´ı modelu vlastnost´ı pro f´azi anal´ yzy v dom´enov´em inˇzen´ yrstv´ı. Na z´ akladˇe takto definovan´eho modelu se pak pˇri tvorbˇe v´ ysledn´eho syst´emu vyberou 14 Respektive mohou m´ıt i kardinalitu [0..0] a [1..1], jak je vidˇet z tab. 2.4, ale tyto hodnoty se dle [Cza05b] pouˇz´ıvaj´ı aˇz pˇri procesu specializace, kter´ y bude pops´ an samostatnˇe v podkapitole 2.7. Zaj´ımav´e je podotknout, ˇze stejn´ı autoˇri ve sv´ ych pˇredchoz´ıch publikac´ıch [Cza04] a [Cza05a] nejprve kardinalitu seskupen´ ych vlastnost´ı zavrhuj´ı jako zbyteˇcnou.
20
Modelov´ an´ı vlastnost´ı
Konfigurace modelu vlastnost´ı
vlastnosti, kter´e v nˇem budou zahrnuty (napˇr´ıklad pouˇzit´ım zvolen´ ych komponent). To, kter´e kombinace vybran´ ych vlastnost´ı m˚ uˇzeme povaˇzovat za validn´ı, n´am definuje pr´avˇe model vlastnost´ı. Soubor vlastnost´ı vybran´ ych v souladu s pravidly definovan´ ymi pˇr´ısluˇsn´ ym modelem vlastnost´ı naz´ yv´ ame dle [Cza04] jako konfigurace modelu vlastnost´ı (z angl. feature model configuration) nebo pouze zkr´ acenˇe konfigurace. Proces, pˇri kter´em dojde k vybr´an´ı takov´e validn´ı kombinace vlastnost´ı, pak naz´ yv´ame procesem konfigurace. Na tomto m´ıstˇe vhodn´e je uv´est, jak´ ym zp˚ usobem reprezentovat dan´ y soubor vybran´ ych vlastnost´ı. Pokud bychom uvaˇzovali p˚ uvodn´ı model vlastnost´ı, tak jak je popsan´ y v [Kang90] a [Cza00], m˚ uˇzeme konfiguraci definovat jako pouh´ y v´ yˇcet (mnoˇzinu) vlastnost´ı. Pokud bychom uvaˇzovali model vlastnost´ı s kardinalitou a atributy, uˇz si s takto jednoduchou reprezentac´ı nevystaˇc´ıme, a to ze dvou d˚ uvod˚ u: 1. Konfigurace mus´ı pro kaˇzd´ y atribut obsahovat i jeho hodnotu dle specifikovan´eho typu (ˇc´ıslo, ˇretˇezec, reference apod.). 2. U vlastnost´ı, jejichˇz rodiˇcem je duplikovateln´a vlastnost, je nutn´e uv´est, ke kter´e z rodiˇcovsk´ ych kopi´ı jsou pˇriˇrazeny. Jin´ ymi slovy, mus´ıme definovat kontext, v jak´em jsou vybr´ any. Z tˇechto d˚ uvod˚ u se konfigurace modelu vlastnost´ı tedy reprezentuje tak´e jako stromov´ a struktura. Diagram zn´ azorˇ nuj´ıc´ı konfiguraci pak pouˇz´ıv´a stejnou notaci jako diagram modelu vlastnost´ı. Jako pˇr´ıklad si na obr´azku 2.9 ukaˇzme jednu z validn´ıch konfigurac´ı modelu z obr´azku 2.8c. Řídící systém
Snímač
Snímač polohy
Snímač
Snímač teploty
Snímač polohy
Autodiagnostika
CPU
Velikost paměti (1024: Integer)
Obr´ azek 2.9: Uk´ azka konfigurace modelu vlastnost´ı z obr. 2.8c. Kaˇzd´ y model vlastnost´ı definuje jistou mnoˇzinu validn´ıch konfigurac´ı. Tuto mnoˇzinu m˚ uˇzeme dle [Cza04] naz´ yvat jako prostor konfigurac´ı (z angl. configuration space). Dva modely vlastnost´ı pak m˚ uˇzeme povaˇzovat za ekvivalentn´ı, pokud je jejich konfiguraˇcn´ı prostor identick´ y, jak tvrd´ı [Cza00]. Pˇr´ıklad dvou model˚ u vlastnost´ı ekvivalentn´ıch na z´akladˇe t´eto definice m˚ uˇzeme vidˇet na obr´ azku 2.10. V tomto pˇr´ıpadˇe m´a pouˇzit´ı skupiny h0 − 2i na obr. 2.10a stejn´ y efekt
21
Modelov´ an´ı vlastnost´ı
Specializace modelu vlastnost´ı
jako pouˇzit´ı samostatn´ ych voliteln´ ych vlastnost´ı na obr. 2.10b. V druh´em uveden´em diagramu pak doˇslo k vyj´ adˇren´ı v´ yluˇcnosti D a E pomoc´ı dodateˇcn´eho (textovˇe zadan´eho) omezen´ı nam´ısto pouˇzit´ı XOR skupiny jako v diagramu prvn´ım. Tato omezen´ı budou pozdˇeji diskutov´ ana v ˇc´ asti 2.8. Pro uk´azku tak´e uved’me v´ yˇcet vˇsech validn´ıch konfigurac´ı popsan´ ych obˇema modely: {A, AB, AC, ABC, ACD, ACE, ABCD, ABCE}15 . Jak vid´ıme, stejn´ a situace se dala v pˇr´ıkladu vyj´adˇrit dvˇema r˚ uzn´ ymi zp˚ usoby, tedy m´ame zde redundanci. Autoˇri [Cza04] naznaˇcuj´ı, ˇze by bylo moˇzn´e prov´adˇet mezi tˇemito reprezentacemi konverzi a pˇr´ıpadnˇe i normalizaci do nˇejak´e preferovan´e formy, avˇsak toto nech´avaj´ı na implement´ atorech pˇr´ıpadn´eho modelovac´ıho n´astroje. A
A <0-2>
B
C
D
B
E
C
D
E
D mutex E
(a) Prvn´ı model.
(b) Druh´ y model.
Obr´azek 2.10: Ekvivalence dvou model˚ u vlastnost´ı z hlediska jejich prostoru konfigurac´ı.
2.7
Specializace modelu vlastnost´ı
Proces konfigurace, popsan´ y v pˇredchoz´ı ˇc´asti, umoˇzn ˇoval na z´akladˇe modelu vlastnost´ı sestrojit jednu z jeho validn´ıch konfigurac´ı. Publikace [Cza04] uv´ad´ı obecnˇejˇs´ı pˇr´ıstup, kter´ y naz´ yv´ a procesem specializace. ˇ ık´ R´ ame, ˇze diagram vlastnost´ı Y je specializac´ı diagramu vlastnost´ı X, pokud je prostor vˇsech konfigurac´ı Y podmnoˇzinou prostoru konfigurac´ı X. Jin´ ymi slovy, Y vznikl transformac´ı z X zpˇr´ısnˇen´ım nˇekter´ ych jeho omezen´ı a plat´ı tedy, ˇze libovoln´a platn´ a 16 konfigurace Y je i platnou konfigurac´ı pro X, ale ne naopak . Jako pˇr´ıklad specializace si uved’me diagramy na obr´azku 2.11. Diagram 2.11a pˇredstavuje model vlastnost´ı s moˇzn´ ymi konfiguracemi {A, AB, AC, ABC, ACD, ACE, ABCD, ABCE}. U jeho specializace na obr. 2.11b jsme provedli zmˇenu kardinality skupiny ze h0 − 2i na h0 − 1i a nav´ıc jsme v r´amci C explicitnˇe vybrali vlastnost E a eliminovali vlastnost D. Takto modifikovan´ y diagram vlastnost´ı m´a jako moˇzn´e konfigurace pouze 15
Vzhledem k nepouˇzit´ı duplikovateln´ ych vlastnost´ı jsme si ho mohli dovolit uv´est v tomto tvaru. Aˇckoliv specializujeme pouze diagram, m˚ uˇzeme tento proces souhrnnˇe oznaˇcovat jako specializace modelu vlastnost´ı. 16
22
Modelov´ an´ı vlastnost´ı
Specializace modelu vlastnost´ı
ˇ aˇr necht’ si s´am ovˇeˇr´ı, ˇze jde o podmnoˇzinu konfigurac´ı p˚ {A, AB, ACE}. Cten´ uvodn´ıho diagramu. Pro u ´plnost dodejme, ˇze na proces konfigurace se m˚ uˇzeme d´ıvat jako zvl´aˇstn´ı pˇr´ıpad procesu specializace, jehoˇz v´ ystupem je diagram vlastnost´ı maj´ıc´ı pouze jedinou platnou konfiguraci. A
V pˇr´ıpadˇe rozs´ ahl´ ych model˚ u vlastnost´ı m˚ uˇze b´ yt tvorba konfigurace zdlouhav´a a komplikovan´a. Nav´ıc m˚ uˇzou o v´ ybˇeru r˚ uzn´ ych vlastnost´ı v konfiguraci rozhodovat odliˇsn´e osoby (z´akazn´ıci, v´ yvoj´ aˇri, vedouc´ı atd.). Autoˇri [Cza04] proto navrhuj´ı postup, kter´ y naz´ yvaj´ı konfigurace ve f´ az´ıch (z angl. staged configuration). Z´akladn´ı myˇslenkou tohoto pˇr´ıstupu je rozdˇelen´ı procesu konfigurace na nˇekolik f´az´ı, kdy v kaˇzd´e f´ azi dojde k eliminaci nˇekter´ ych nechtˇen´ ych konfigurac´ı. V´ ysledkem posledn´ı f´aze je pak jedin´ a, c´ılov´ a konfigurace. Jin´ ymi slovy, v jednotliv´ ych f´az´ıch postupnˇe transformujeme model vlastnost´ı tak, abychom zmenˇsovali v´ ysledn´ y konfiguraˇcn´ı prostor. Jeden ze dvou zp˚ usob˚ u jak´ ymi doc´ılit konfigurace ve f´az´ıch je, dle [Cza04], pr´avˇe jiˇz zm´ınˇen´ y proces specializace. Druh´ ym moˇzn´ ym zp˚ usobem je pak tzv. v´ıce´ urovˇ nov´ a konfigurace (z angl. multi-level configuration), kdy je pro kaˇzdou f´azi (´ uroveˇ n) pouˇz´ıv´an odliˇsn´ y model vlastnost´ı. Pˇrechod mezi jednotliv´ ymi f´azemi prob´ıh´a tak, ˇze je na z´akladˇe v´ ystupn´ı konfigurace z n-t´e f´ aze vygenerov´an vstupn´ı model vlastnost´ı f´aze n + 1. Hlavn´ı v´ yhodou tohoto pˇr´ıstupu oproti specializaci je, ˇze osoba prov´adˇej´ıc´ı konfiguraci v dan´e f´azi vid´ı pouze malou ˇc´ ast ze vˇsech moˇzn´ ych voleb. Zat´ımco proces specializace zaˇc´ın´a s u ´pln´ ym modelem popisuj´ıc´ım vˇsechny moˇzn´e konfigurace, v´ıce´ urovˇ nov´a konfigurace m˚ uˇze m´ıt v prvn´ı f´ azi zjednoduˇsen´ y model, popisuj´ıc´ı jen nˇekolik relevantn´ıch moˇznost´ı. Detailnˇejˇs´ı popis t´eto problematiky pˇresahuje sv´ ym rozsahem r´amec t´eto pr´ace a pro dalˇs´ı informace proto odk´ aˇzeme ˇcten´aˇre na zm´ınˇenou literaturu [Cza04].
23
Modelov´ an´ı vlastnost´ı
2.8
Specifikace omezen´ı
Specifikace omezen´ı
Diagram vlastnost´ı je pomˇernˇe efektivn´ı n´astroj pro zn´azornˇen´ı jednotliv´ ych vlastnost´ı a jejich vz´ ajemn´ ych vztah˚ u, avˇsak nˇekter´e skuteˇcnosti zachytit nedok´aˇze. Pod´ıvejme se zpˇet na pˇr´ıklad z obr´ azku 2.8c, zn´ azorˇ nuj´ıc´ı jednoduch´ y ˇr´ıd´ıc´ı syst´em. V tomto diagramu jsme dok´azali vyj´ adˇrit nˇekter´ a omezen´ı pomoc´ı kardinalit vlastnost´ı (ˇr´ıd´ıc´ı syst´em m´a 1 aˇz 4 sn´ımaˇce) a skupin (sn´ımaˇc m´ a 1 aˇz 2 mˇeˇr´ıc´ı ˇc´asti). Probl´em by vˇsak nastal, pokud bychom potˇrebovali definovat omezen´ı typu: sn´ımaˇc m˚ uˇze m´ıt 2 mˇeˇr´ıc´ı ˇca ´sti, jen pokud je velikost intern´ı pamˇeti alespoˇ n 1024B. Omezen´ı prvn´ıho typu (tedy kardinality vlastnost´ı a skupin) oznaˇcuj´ı nˇekteˇr´ı autoˇri [Pas05] jako tzv. lok´ aln´ı omezen´ı (z angl. local constraints). Tato omezen´ı se vˇzdy vztahuj´ı pouze ke spoleˇcn´emu rodiˇci dan´ ych vlastnost´ı. Omezen´ı druh´eho typu, kter´e popisovala obecn´ y vztah mezi vlastnostmi z r˚ uzn´ ych ˇc´ast´ı stromu, pak [Pas05] naz´ yv´a jako glob´ aln´ı omezen´ı (z angl. global constraints). Pokud mluv´ıme v r´amci modelu vlastnost´ı obecnˇe o omezen´ıch (constraints), m´ ame na mysli vˇetˇsinou pr´avˇe omezen´ı glob´aln´ı typu a takto budeme ch´ apat i v´ yznam slova omezen´ı ve zbytku tohoto textu. Jiˇz p˚ uvodn´ı publikace [Kang90] popisovala nutnost specifikace omezen´ı, zde jeˇstˇe naz´ yvan´ ych jako kompoziˇcn´ı pravidla (z angl. composition rules). Tato omezen´ı zde byla rozdˇelena do dvou kategori´ı: 1. Omezen´ı typu z´ avislost. Napˇr´ıklad vlastnost A vyˇzaduje vlastnost B, jeˇz bychom form´ alnˇe zapsali jako A requires B. 2. Omezen´ı typu vylouˇcen´ı. Napˇr´ıklad nelze m´ıt z´ aroveˇ n A i B, form´alnˇe zapsan´e jako A mutex-with B. Obdobn´ ym zp˚ usobem jsou omezen´ı uvaˇzov´ana i v [Cza00]. Obecnˇe m˚ uˇzeme omezen´ı ch´apat jako logick´ y v´ yraz zapsan´ y v textov´e formˇe, kter´ y je pro danou konfiguraci bud’ vyhodnocen jako pravdiv´ y (konfigurace je validn´ı) nebo nepravdiv´ y (konfigurace je nevalidn´ı). Aby byl dan´ y logick´ y v´ yraz snadno strojovˇe zpracovateln´ y a vyhodnotiteln´ y, mus´ı vyhovovat pravidl˚ um gramatiky dan´eho jazyka. Tento jazyk pak oznaˇcujeme jako jazyk omezen´ı (z angl. constraint language). Jako pˇr´ıklad takov´eho jazyka si m˚ uˇzeme uv´est jednoduchou gramatiku v´ yˇse zm´ınˇen´ ych omezen´ı pˇrevzatou z [Kang90]: (‘requires’ | ‘mutex-with’) Obecnˇe vˇsak nen´ı nikde specifikov´ano, jak´ y jazyk by mˇel b´ yt k vyj´adˇren´ı omezen´ı pouˇzit. 17 Autoˇri [Cza05b] uv´ adˇej´ı moˇznost pouˇzit´ı jazyka OCL pro modely vlastnost´ı s kardinalitou. Jako v´ yhodu zmiˇ nuj´ı jeho dobˇre definovanou s´emantiku a to, ˇze s n´ım budou nˇekteˇr´ı v´ yvoj´ aˇri pravdˇepodobnˇe jiˇz obezn´ameni. Jin´ı autoˇri, napˇr´ıklad [Cech04], navrhuj´ı pro popis omezen´ı jazyk XPath18 , p˚ uvodnˇe urˇcen´ y pro zpracov´an´ı XML dokument˚ u. Dalˇs´ım pˇr´ıkladem je n´ astroj pure::variants, pouˇz´ıvaj´ıc´ı pro vyj´adˇren´ı omezen´ı vlastn´ı dialekt jazyka Prolog [Pure13]. 17 18
Object Constraint Language (http://www.omg.org/spec/OCL/) XML Path Language (http://www.w3.org/TR/xpath20/)
24
Modelov´ an´ı vlastnost´ı
Specifikace omezen´ı
Pro uk´ azku pouˇzit´ı omezen´ı uved’me pˇr´ıklad komplexnˇejˇs´ıho modelu vlastnost´ı, pˇrevzat´eho z [Cza05b], jeˇz je zn´ azornˇen´ y na obr´azku 2.12. Vid´ıme, ˇze jde o diagram vlastnost´ı imagin´ arn´ıho internetov´eho obchodu, kter´ y m´a administrativn´ı ˇc´ast (back office) a jednu nebo v´ıce prodejn´ıch m´ıst (front store). Pro administrativn´ı ˇc´ast m˚ uˇzeme vytvoˇrit nˇekolik r˚ uznˇe nakonfigurovan´ ych platebn´ıch metod a pˇr´ıpadnˇe i nˇekolik doruˇcovac´ıch metod. Jednotliv´ ym prodejn´ım m´ıst˚ um pak m˚ uˇzeme tyto platebn´ı a doruˇcovac´ı metody pˇriˇrazovat. Tento pˇr´ıklad je uk´ azka vhodn´eho pouˇzit´ı atribut˚ u typu reference, kdy se s jejich pomoc´ı m˚ uˇzeme odkazovat na jiˇz existuj´ıc´ı prvky konfigurace (doruˇcovac´ı a platebn´ı metody). Nicm´enˇe, na tomto pˇr´ıkladu si uk´aˇzeme pouˇzit´ı OCL, jako jazyka pro popis omezen´ı. N´ıˇze uveden´e pˇr´ıklady omezen´ı (v´ ypis 2.1) jsou opˇet pˇrevzaty z [Cza05b]19 . EShop [1..∗]
V´ ypis 2.1: Pˇr´ıklady omezen´ı v jazyce OCL. Prvn´ı omezen´ı ˇr´ık´ a, ˇze pokud byla vybr´ana vlastnost odhalov´an´ı podvod˚ u, mus´ı b´ yt vybr´ana i nˇejak´ a platebn´ı br´ ana (omezen´ı typu z´avislost). Druh´e omezen´ı zaruˇcuje, ˇze reference na platebn´ı br´ anu bude vˇzdy na nˇejakou existuj´ıc´ı platebn´ı br´anu odkazovat. Tˇret´ı omezen´ı ud´ av´ a, ˇze prodejn´ı m´ısto nem˚ uˇze podporovat v´ıce jak tˇri platebn´ı metody. Posledn´ı omezen´ı jednoduˇse zakazuje z´apornou ˇci nulovou pˇrepravn´ı rychlost. 19
Pouˇzit´ı OCL v tomto pˇr´ıkladˇe pˇredpokl´ ad´ a vyhodnocen´ı jeho v´ yraz˚ u nad modelem, kter´ y struktur´ alnˇe odpov´ıd´ a uveden´emu diagramu a pouˇz´ıv´ a stejn´e pojmenov´ an´ı prvk˚ u.
25
Modelov´ an´ı vlastnost´ı
Specifikace omezen´ı
Co bychom si mˇeli na uveden´e pˇr´ıkladu d´ale vˇsimnout, je vztaˇzen´ı jednotliv´ ych omezen´ı vˇzdy k nˇejak´e vlastnosti, tzv. kontextu. Specifikace kontextu je nutn´a zejm´ena pˇri pouˇz´ıv´ an´ı duplikovateln´ ych vlastnost´ı. Pod´ıvejme se na obr´azek 2.13 zn´azorˇ nuj´ıc´ı model vlastnost´ı a jeho dvˇe odliˇsn´e konfigurace. Pro tento model definujeme dvˇe r˚ uzn´a omezen´ı20 a pod´ıv´ ame se jak budou vyhodnocena: A
A
A
[1..*]
B
C
B
D
B
D
(a) Model vlastnost´ı.
B
C
D
(b) Pˇr´ıklad konfigurace 1.
B
B
C
D
(c) Pˇr´ıklad konfigurace 2.
Obr´ azek 2.13: Pˇr´ıklad modelu vlastnost´ı se dvˇema r˚ uzn´ ymi konfiguracemi.
1. C implies D 2. context B: C implies D Prvn´ı omezen´ı implikuje nutnost vybr´an´ı vlastnosti D, pokud byla vybr´ana vlastnost C. V tomto pˇr´ıpadˇe jsou obˇe dvˇe konfigurace zcela validn´ı. Druh´e omezen´ı ˇr´ık´a to sam´e, avˇsak jeho vyhodnocen´ı prob´ıh´ a vˇzdy v r´amci spoleˇcn´eho rodiˇce B. Zde jiˇz konfigurace 2.13c nevyhovuje. Ekvivalentnˇe bychom mohli tato omezen´ı zapsat i jako v´ yrazy predik´atov´e logiky 2.1 a 2.2, kde X pˇredstavuje vlastnost stejn´eho jm´ena a predik´at P (r, p) vyjadˇruje vztah rodiˇc-potomek. ∃C → ∃D
(2.1)
∀B (∃C ∧ P (B, C) → ∃D ∧ P (B, D))
(2.2)
Zaj´ımav´ ym pozorov´ an´ım je, ˇze pomoc´ı v´ yrokov´e logiky m˚ uˇzeme vyj´adˇrit i lok´aln´ı omezen´ı, definovan´ a grafickou notac´ı v diagramu vlastnost´ı, jak ukazuje tabulka 2.621 . Obdobn´ ym zp˚ usobem bychom mohli vyj´ adˇrit i cel´ y model vlastnost´ı. V takov´em pˇr´ıpadˇe by uˇz pak rozd´ıl mezi glob´ aln´ımi a lok´ aln´ımi omezen´ımi nebyl patrn´ y. Na z´ avˇer t´eto podkapitoly jeˇstˇe dodejme, ˇze aˇckoliv m˚ uˇzeme textovˇe zapsan´a omezen´ı zˇrejmˇe povaˇzovat za nejflexibilnˇejˇs´ı moˇznost vyj´adˇren´ı vztah˚ u v modelu vlastnost´ı, nejde o jedin´ y moˇzn´ y zp˚ usob. Nˇekteˇr´ı autoˇri zan´aˇsej´ı (glob´aln´ı) omezen´ı do diagramu v grafick´e podobˇe, coˇz m´ a zaj´ımav´e d˚ usledky pro jeho strukturu. Tyto odliˇsn´e reprezentace budou diskutov´ any v ˇc´ asti 2.10. 20
Pro jednoduchost jsme pouˇzili n´ ami smyˇslen´ y jazyk podobn´ y OCL. Hodnotu dan´e logick´e promˇenn´e ch´ apeme jako pravda, pokud je odpov´ıdaj´ıc´ı vlastnost v konfiguraci pˇr´ıtomna. 21
26
Modelov´ an´ı vlastnost´ı
Dalˇs´ı rozˇs´ıˇren´ı modelu vlastnost´ı
Prvek diagramu vlastnost´ı r je koˇren diagramu f1 je voliteln´ a pod-vlastnost f f1 je povinn´ a pod-vlastnost f f1 , f2 , . . . , fn tvoˇr´ı OR skupinu pod-vlastnost´ı f f1 , f2 , . . . , fn tvoˇr´ı XOR skupinu pod-vlastnost´ı f
V´ yznam r f1 → f f1 ↔ f Wn f ↔f V Wi=1 i ( ni=1 fi ↔ f ) ∧ i<j ¬(fi ∧ fj )
Tabulka 2.6: Vyj´ adˇren´ı nˇekter´ ych vztah˚ u z diagramu vlastnost´ı pomoc´ı v´ yrokov´e logiky.
2.9
Dalˇ s´ı rozˇ s´ıˇ ren´ı modelu vlastnost´ı
Aˇz doposud jsme zm´ınili jen nˇekter´a rozˇs´ıˇren´ı (atributy, skupiny, kardinality) p˚ uvodn´ıho konceptu modelu vlastnost´ı, tak jak byl definov´an v [Kang90]. Tato podkapitola ve struˇcnosti shrnuje i nˇekter´ a dalˇs´ı rozˇs´ıˇren´ı popsan´a v [Cza04].
2.9.1
Modularizace
Diagram vlastnost´ı popisuj´ıc´ı variabilitu komplexn´ıho syst´emu m˚ uˇze b´ yt velmi rozs´ahl´ y. V takov´em pˇr´ıpadˇe m´ a v´ yznam ho rozdˇelit na nˇekolik menˇs´ıch celk˚ u (podstrom˚ u), kter´e jsou spravov´ any nez´ avisle. V p˚ uvodn´ım diagramu se pak vyskytuje speci´aln´ı typ uzlu, kter´ y na tyto pod-diagramy odkazuje22 . Principi´alnˇe se m˚ uˇzeme na ten sam´ y podstrom odkazovat i ve v´ıce m´ıstech jednoho ˇci nˇekolika diagram˚ u. Pˇr´ıklad modelu vlastnost´ı pouˇz´ıvaj´ıc´ı takto popsanou referenci jsme jiˇz mohli vidˇet na obr´azku 2.12. Pozorn´ y ˇcten´ aˇr si zde jistˇe vˇsiml odliˇsn´e notace s vyplnˇenou ˇsipkou pro uzel Catalog, kter´ y reprezentuje pr´ avˇe zm´ınˇen´ y odkaz. V naˇsem pˇr´ıpadˇe se zde odkazujeme na model vlastnost´ı popisuj´ıc´ı variabilitu katalogu zboˇz´ı. Pouˇzit´ı referenc´ı na jednotliv´e prvky diagramu m˚ uˇze samozˇrejmˇe pˇrin´est probl´em rekurze, a to jak pˇr´ım´e (diagram vlastnost´ı odkazuje na svoj´ı ˇc´ast), tak nepˇr´ım´e (vz´ajemn´e odkazy mezi dvˇema a v´ıce diagramy).
2.9.2
Specifikace vztahu
V diagramu vlastnost´ı, tak jak jsme ho zde popsali, jsme pomoc´ı spojen´ı urˇcovali pouze vztah mezi rodiˇcem a potomkem, avˇsak nijak pˇresnˇe jsme nedefinovaly v´ yznam tohoto vztahu. Nˇekteˇr´ı autoˇri, jako napˇr´ıklad [Lee02], rozliˇsuj´ı aˇz ˇctyˇri r˚ uzn´e typy vztah˚ u (z angl. relationships): 1. skl´ ad´ a-se-z (composed-of ) - Vyjadˇruje vztah celku a jeho ˇc´asti, viz pˇr´ıklad ˇr´ıd´ıc´ıho syst´emu a sn´ımaˇc˚ u na obr. 2.8c. V diagramu je zn´azornˇen plnou ˇcarou. 2. zobecnˇen´ı/upˇresnˇen´ı (generalization/specialization) - Vyjadˇruje vztah mezi obecnou a konkr´etn´ı vlastnost´ı. Pˇr´ıkladem m˚ uˇze b´ yt vztah mezi vlastnostmi ˇrad´ıc´ı algoritmus 22
Zde se nejedn´ a o atribut typu reference, nebot’ ten odkazuje na prvek konfigurace, ne prvek diagramu vlastnost´ı.
27
Modelov´ an´ı vlastnost´ı
Odliˇsn´e reprezentace modelu vlastnost´ı
a algoritmus quick sort. V diagramu je zn´azornˇen teˇckovanou/ˇc´arkovanou ˇcarou. 3. je-implementov´ an (implemented-by) - Ud´av´a, ˇze jedna vlastnost je nezbytn´a pro implementaci druh´e. V diagramu je zn´azornˇeny tuˇcnou ˇcarou. Zaj´ımav´e je, ˇze posledn´ı zm´ınˇen´ y vztah m˚ uˇze zapˇr´ıˇcinit to, ˇze struktura v´ ysledn´eho diagramu nebude strom, ale acyklick´ y graf, v pˇr´ıpadˇe ˇze dan´a vlastnost potˇrebuje ke sv´e implementaci v´ıce odliˇsn´ ych vlastnost´ı (m´a v diagramu v´ıce rodiˇcovsk´ ych uzl˚ u).
2.9.3
Kategorie vlastnost´ı a anotace
P˚ uvodn´ı publikace [Kang90] rozdˇelovala jednotliv´e vlastnosti do kategori´ı podle jejich v´ yznamu. Vlastnosti pak byly podle toho oznaˇcov´any jako funkcion´ aln´ı (sluˇzby aplikace), operaˇcn´ı (interakce uˇzivatele s aplikac´ı) a prezentaˇcn´ı (prezentace informace uˇzivateli). Nˇekteˇr´ı autoˇri [Griss98] toto sch´ema rozˇsiˇruj´ı o dalˇs´ı kategorie vlastnost´ı, jako napˇr´ıklad architektonick´e (souvis´ı se strukturou syst´emu) a implementaˇcn´ı. Jin´e rozˇs´ıˇren´ı spoˇc´ıv´ a v pˇrid´ an´ı dalˇs´ıch doplˇ nuj´ıc´ıch informac´ı do modelu vlastnost´ı, dle autor˚ u [Cza04], oznaˇcovan´ ych jako anotace. P˚ uvodn´ı publikace [Kang90] zmiˇ novala pouze popis vlastnost´ı, definici omezen´ı, zd˚ uvodnˇen´ı pouˇzit´ı a ˇcas vazby. Pˇr´ıklady dalˇs´ıch takov´ ych anotac´ı jsme si jiˇz uvedli v podkapitole 2.3.3.
2.10
Odliˇ sn´ e reprezentace modelu vlastnost´ı
Aˇz doted’ jsme pro vyj´ adˇren´ı modelu vlastnost´ı pouˇz´ıvali diagram s notac´ı autor˚ u Czarnecki, Eisenecker (a kol.) [Cza00], [Cza05b] a kr´atce pˇred t´ım jsme pˇredstavili i p˚ uvodn´ı FODA notaci [Kang90]. Nicm´enˇe, v oblasti modelov´an´ı vlastnost´ı vznikli i dalˇs´ı odliˇsn´e reprezentace od r˚ uzn´ ych autor˚ u, vˇetˇsinou vyuˇz´ıvaj´ıc´ı diagram zaloˇzen´ y pr´avˇe na p˚ uvodn´ı FODA notaci. C´ılem t´eto podkapitoly je sezn´amit ˇcten´aˇre s jejich pr˚ uˇrezem. Pomˇernˇe rozs´ ahl´ y souhrn a srovn´an´ı r˚ uzn´ ych notac´ı diagram˚ u vlastnost´ı a jejich s´emantiky nalezneme v [Scho06]. Autoˇri tˇechto notac´ı popisuj´ı celkem sedm, vˇcetnˇe FODA notace (zde oznaˇcen´e jako OFT) a notace autor˚ u Czarnecki, Eisenecker (oznaˇcen´e jako GPFT). Dalˇs´ımi popsan´ ymi notacemi jsou pak OFD, RFD, VBFD, EFD a PFT23 . Vˇsechny zm´ınˇen´e maj´ı spoleˇcn´e to, ˇze pouˇz´ıvaj´ı jako z´aklad stromov´ y diagram, ale vˇetˇsinou s r˚ uznou grafickou u ´pravou a odliˇsnou s´emantikou prvk˚ u. Vyjmenujme zde proto jen nejz´ asadnˇejˇs´ı rozd´ıly mezi tˇemito notacemi: 1. Struktura diagramu - Nˇekter´e notace pouˇz´ıvaj´ı klasickou stromovou strukturu (OFT, GPFT, PFT), zat´ımco jin´e pouˇz´ıvaj´ı acyklick´ y graf (OFD, RFD, VBFD, EFD). V druh´e uveden´e skupinˇe tedy m˚ uˇze m´ıt napˇr´ıklad jedna vlastnost dva rodiˇcovsk´e prvky. 23
Tyto zkratky byly v [Scho06] zavedeny pro snadn´e rozliˇsen´ı jednotliv´ ych notac´ı. Pro jejich pˇresn´ y v´ yznam odk´ aˇzeme ˇcten´ aˇre na zm´ınˇenou publikaci.
28
Modelov´ an´ı vlastnost´ı
Odliˇsn´e reprezentace modelu vlastnost´ı
2. Typ uzl˚ u a vazeb - Vˇsechny notace maj´ı prvek s v´ yznamem povinn´e a voliteln´e vlastnosti, i kdyˇz pro nˇej nˇekdy pouˇz´ıvaj´ı odliˇsnou grafickou reprezentaci. D´ale vˇsechny notace umoˇzn ˇuj´ı vyj´ adˇrit omezen´ı nad mnoˇzinou vlastnost´ı se s´emantikou logick´e funkce and, or, xor nebo jin´e. Grafick´e zn´azornˇen´ı je nˇekdy opˇet odliˇsn´e. Nˇekter´e (GPFT, EFD) pro toto pouˇz´ıvaj´ı kardinalitu. 3. Jazyk omezen´ı - OFT, OFD, GPFT pouˇz´ıvaj´ı k vyj´adˇren´ı omezen´ı nˇejak´ y textov´ y jazyk, zat´ımco PFT pouˇz´ıv´a pro (glob´aln´ı) omezen´ı grafickou notaci, kdy jsou jednotliv´e vlastnosti napˇr´ıˇc stromem propojeny hranou s vyznaˇcenou s´emantikou. Zbyl´e RFD, VBFD, EFD umoˇzn ˇuj´ı omezen´ı definovat jak textovˇe, tak graficky. Vˇsechny notace umoˇzn ˇuj´ı nˇejak´ ym zp˚ usobem vyj´adˇrit alespoˇ n dva standardn´ı typy omezen´ı (z´ avislost a vylouˇcen´ı). Monitor Engine system
Monitor Engine Performace
Monitor Temperatures
coolant
Monitor RPM
Monitor Fuel Consumption
Meassures
Monitor exhause levels and temperature
Methods
transmission gallon/mile
l/Km oil
Based on distance
engine
Based on type of driving
Based on drive
requires
Obr´ azek 2.14: Uk´ azka diagramu vlastnost´ı pouˇz´ıvaj´ıc´ı notaci RFD. Nˇekter´e notace zav´ adˇej´ı pomˇernˇe specifick´e prvky. Napˇr´ıklad OFD rozdˇeluje diagram do vrstev dle typu vlastnost´ı (funkˇcn´ı, operaˇcn´ı, technologick´e, implementaˇcn´ı) a pouˇz´ıv´ a r˚ uznˇe zn´ azornˇen´e typy vazeb (skl´ad´a se z, zobecnˇen´ı/upˇresnˇen´ı, je implementov´an). Jin´e, jako VBFD, umoˇzn ˇuj´ı oznaˇcit vazby mezi vlastnostmi ˇcasem spojen´ı (binding time). Aby ˇcten´aˇr z´ıskal alespoˇ n pˇribliˇznou pˇredstavu, uved’me zde uk´azku diagramu pouˇz´ıvaj´ıc´ı notaci RFD (obr. 2.14), na kter´em m˚ uˇzeme vidˇet i graficky vyznaˇcen´e (glob´aln´ı) omezen´ı. Tento diagram, zn´ azorˇ nuj´ıc´ı variabilitu monitorovac´ıho syst´emu, byl pˇrevzat ze zm´ınˇen´e publikace [Scho06]. V´ yˇse uveden´e notace pouˇz´ıvali k popisu modelu vlastnost´ı grafick´ y diagram v podobˇe stromu ˇci acyklick´eho grafu, avˇsak to nemus´ı b´ yt vˇzdy jedin´ y moˇzn´ y zp˚ usob. Publikace [Bouch10] uv´ ad´ı nˇekolik nev´ yhod pouˇzit´ı diagram˚ u, jako napˇr´ıklad jejich ˇspatnou ˇsk´alovatelnost (orientace v rozs´ ahl´ ych diagramech) a to ˇze grafick´a notace neumoˇzn ˇuje vyj´adˇrit komplikovanˇejˇs´ı omezen´ı. Jej´ı autoˇri proto pˇrich´azej´ı s n´avrhem TVL24 , ˇcistˇe textovˇe zaloˇzen´ ym jazykem pro popis model˚ u vlastnost´ı. Pomoc´ı syntaxe tohoto jazyka lze 24
Text-Based Variability Language.
29
Modelov´ an´ı vlastnost´ı
Odliˇsn´e reprezentace modelu vlastnost´ı
popsat modely vlastnost´ı obsahuj´ıc´ı vˇetˇsinu popsan´ ych rozˇs´ıˇren´ı, jako napˇr´ıklad kardinalitu a atributy. Jazyk d´ ale obsahuje nˇekter´e zaj´ımav´e prvky, jako je v´ yˇctov´ y typ pro atributy, moˇznost definice konstant, pouˇz´ıv´an´ı aritmetick´ ych a logick´ ych v´ yraz˚ u ˇci dekompozici stromu na znovupouˇziteln´e ˇc´asti. Popsan´ y model m˚ uˇze m´ıt strukturu acyklick´eho grafu. Omezen´ı jsou vyj´ adˇrena jako logick´ y v´ yraz pˇriˇrazen´ y k vlastnostem. Syntaxe TVL je silnˇe inspirovan´ a jazykem C, jak m˚ uˇzeme vidˇet na n´ıˇze uveden´e uk´azce ve v´ ypisu 2.2 (jde o vyj´ adˇren´ı diagramu vlastnost´ı z obr. 2.8c). RidiciSystem { group allOf { Snimac [1..4] { group [1..2] { SnimacPolohy ; SnimacPohybu ; SnimacTeploty ; } opt Autodiagnostika ; } CPU { int VelikostPameti ; VelikostPameti >= 0; } } }
V´ ypis 2.2: Pˇr´ıklad modelu vlastnost´ı v jazyce TVL.
30
3 Dostupn´e modelovac´ı n´astroje C´ılem t´eto kapitoly je sezn´ amit ˇcten´aˇre s nˇekter´ ymi n´astroji umoˇzn ˇuj´ıc´ımi modelov´an´ı ´ celem zde nen´ı popsat vˇsechny dostupn´e n´astroje, ale sp´ıˇse jejich pr˚ vlastnost´ı. Uˇ uˇrez, zachycuj´ıc´ı r˚ uzn´e pˇr´ıstupy tˇechto n´astroj˚ u k samotn´emu modelov´an´ı. N´astroje se zde liˇs´ı zejm´ena sv´ ym rozsahem, funkcionalitou, zamˇeˇren´ım, pouˇzit´ ymi technologiemi a zp˚ usobem ovl´ad´an´ı. Valnou ˇc´ ast popsan´ ych n´ astroj˚ u tvoˇr´ı aplikace, jeˇz maj´ı sv˚ uj p˚ uvod vzniku na akademick´e p˚ udˇe. Nˇekter´e z nich slouˇz´ı v´ıcem´enˇe jako v´ yzkumn´ y prototyp pro podloˇzen´ı z´avˇer˚ u publikovan´ ych jejich autory (CaptainFeature, FMP ), zat´ımco jin´e pˇredstavuj´ı pomˇernˇe komplexn´ı a propracovan´e n´ astroje s re´alnou moˇznost´ı praktick´eho vyuˇzit´ı (FeatureIDE ). Komerˇcn´ı aplikace (pure::variants) pak tvoˇr´ı jen malou ˇc´ast ze vˇsech dostupn´ ych n´astroj˚ u. Na z´ avˇer t´eto kapitoly bude provedeno srovn´an´ı tˇechto n´astroj˚ u z hlediska jejich funkcionality, ovl´ ad´ an´ı, uˇzivatelsk´e pˇr´ıvˇetivosti a pouˇzit´ ych technologi´ı. Toto srovn´an´ı n´am pozdˇeji poslouˇz´ı jako v´ ychoz´ı bod pro definov´an´ı poˇzadavk˚ u na n´ami vytv´aˇren´ y modelovac´ı n´astroj.
3.1
CaptainFeature
CaptainFeature1 je jeden z prvn´ıch modelovac´ıch n´astroj˚ u, kter´ y umoˇzn ˇoval tvorbu model˚ u vlastnost´ı s kardinalitou i atributy. Model vlastnost´ı je zde uvaˇzov´an stejn´ ym zp˚ usobem jako v [Cza05a], vˇcetnˇe ch´ ap´ an´ı kardinalit jako posloupnosti interval˚ u. Samotn´ y n´astroj je naps´an v jazyce Java s pouˇzit´ım knihovny SWING. Model vlastnost´ı je vytv´ aˇren graficky, v podobˇe jednoho ˇci v´ıce diagram˚ u. N´astroj podporuje specializaci diagram˚ u, kter´a z´aroveˇ n slouˇz´ı z´aroveˇ n i k vytv´aˇren´ı jejich konfigurace. Pro definov´ an´ı omezen´ı je k dispozici vlastn´ı jazyk CFCL. Zaj´ımavost´ı je moˇznost prohl´ednout si pouˇzit´ y meta-model2 , kter´ y je s´am zn´azornˇen jako diagram vlastnost´ı. N´astroj pˇredstavuje v´ yzkumn´ y prototyp a jeho grafick´e rozhran´ı je tak velmi minimalistick´e, avˇsak umoˇzn ˇuje vˇsechny z´akladn´ı operace nad modelem. Tyto operace jsou vˇsak pˇr´ıstupn´e vˇetˇsinou pouze pˇres kontextov´e menu, coˇz nen´ı pˇr´ıliˇs uˇzivatelsky pˇr´ıvˇetiv´e. Bez studia pˇriloˇzen´eho manu´ alu je nav´ıc nˇekter´e funkce obt´ıˇzn´e v˚ ubec dohledat. Specializace modelu se prov´ ad´ı ve stromov´em editoru a je pomˇernˇe nepˇrehledn´a. N´astroj se v t´eto dobˇe jiˇz nevyv´ıj´ı.
3.2
Feature Modeling Plug-in
Feature Modeling Plug-in3 (FMP) je z´asuvn´ y modul pro v´ yvojov´e prostˇred´ı Eclipse4 , umoˇzn ˇuj´ıc´ı vytv´ aˇren´ı, editaci, konfiguraci i specializaci model˚ u vlastnost´ı s kardinalitou a 1
http://sourceforge.net/projects/captainfeature/ Meta-model definuje jak vypad´ a struktura dan´eho modelu, v naˇsem pˇr´ıpadˇe modelu vlastnost´ı. 3 http://gp.uwaterloo.ca/fmp/ 4 http://www.eclipse.org/ 2
31
Dostupn´e modelovac´ı n´ astroje
XFeature
Obr´ azek 3.1: Uk´ azka pr´ace s n´astrojem CaptainFeature. atributy, tak jak byly uvedeny v [Cza05b]. Tento n´astroj, popsan´ y v [Ant04], pˇredstavuje v´ yzkumn´ y prototyp a jeho v´ yvoj byl jiˇz ukonˇcen. Pro editaci je pouˇzit klasick´ y stromov´ y editor, takˇze je i editov´an´ı rozs´ahl´ ych model˚ u (do ˇs´ıˇrky) pomˇernˇe pˇrehledn´e. Model se d´a nav´ıc dekomponovat do samostatn´ ych celk˚ u, na kter´e se d´ a odkazovat pomoc´ı referenc´ı. Jako jazyk omezen´ı byl vybr´an XPath5 , coˇz umoˇzn ˇuje definovat pomˇernˇe komplexn´ı omezen´ı, vˇcetnˇe aritmetick´ ych a logick´ ych operac´ı nad atributy. Pˇri vytv´ aˇren´ı konfigurace pak uˇzivatel pouze zatrh´av´a chtˇen´e vlastnosti ve stromˇe. Editor mu u toho dopom´ah´a blokov´an´ım neplatn´ ych voleb a zobrazen´ım poˇctu zbyl´ ych validn´ıch konfigurac´ı. Stejnˇe jako u Captain Feature, i zde je moˇzn´e si prohl´ednou pouˇzit´ y meta-model, avˇsak oproti Captain Feature je zde moˇzno tento meta-model d´ale rozˇsiˇrovat a pˇrid´ avat tak do modelu vlastnost´ı nov´e prvky. Z´asadn´ım probl´emem FMP vˇsak je, ˇze samotn´a konfiguraci i specializace prob´ıh´a v tom sam´em stromˇe jako editace modelu (duplikov´an´ım a upravov´an´ım jeho ˇc´asti), coˇz cel´ y tento proces znepˇrehledˇ nuje. Vˇetˇsina akc´ı je, podobnˇe jako u Captain Feature, prov´adˇena pˇres kontextov´e menu, kter´e je tak bohuˇzel pomˇernˇe rozs´ahl´e. Z´apis omezen´ı v jazyce XPath je sice efektivn´ı, ale nˇekter´e rozs´ ahl´e v´ yrazy mohou b´ yt pak ne pˇr´ıliˇs ˇciteln´e. Uˇzivatel˚ um by nav´ıc mohla chybˇet moˇznost zobrazit si v´ ysledn´ y digram v grafick´e podobˇe.
3.3
XFeature
Autoˇri n´ astroje XFeature6 zvolili pomˇernˇe inovativn´ı pˇr´ıstup k reprezentaci modelu vlastnost´ı, popsan´ y v [Cech04]. Jak model vlastnost´ı, tak i jeho konfiguraci zde ch´apeme jako XML dokumenty se strukturou vyhovuj´ıc´ı jist´emu XML sch´ematu (jejich meta-modelu). Pro konfiguraci vlastnost´ı je toto sch´ema generov´ano XSLT transformac´ı z odpov´ıdaj´ıc´ıho 5 6
Obr´ azek 3.2: Uk´ azka pr´ace s n´astrojem Feature Modeling Plug-in. modelu vlastnost´ı. Sch´ema pro samotn´ y model vlastnost´ı vˇsak pevnˇe d´ano nen´ı. Uˇzivatel´e si mohou toto XML sch´ema vytv´aˇret sami (mus´ı vyhovovat pevnˇe dan´emu XML sch´ematu vyˇsˇs´ı u ´rovnˇe – meta-meta-modelu), nebo mohou pouˇz´ıt jiˇz nˇejak´ y existuj´ıc´ı dostupn´ y meta-model. Definice omezen´ı pak prob´ıh´a pomoc´ı jiˇz zm´ınˇen´eho jazyka XPath. Nejvˇetˇs´ı v´ yhodou cel´eho popsan´eho pˇr´ıstupu je pr´avˇe moˇznost tvorby vlastn´ıho metamodelu, dle potˇreb uˇzivatele. Dalˇs´ı v´ yhodou je tak´e velice jednoduˇse prov´adˇen´a validace (konfigurace i modelu), jeˇz spoˇc´ıv´a ve validov´an´ı v˚ uˇci dan´emu XML sch´ematu a vyhodnocen´ı v´ yraz˚ u v jazyce XPath (omezen´ı). Samotn´ı autoˇri sv˚ uj n´avrh podporovali existenc´ı velk´eho mnoˇzstv´ı XML n´ astroj˚ u, kter´e uˇzivatel˚ um usnadn´ı vytv´aˇren´ı modelu. Technick´ y popis konceptu n´ astroje XFeature lze nal´ezt v [Pas05]. J´adro tohoto n´astroje tvoˇr´ı pouze soubor XML sch´emat a XSLT transformac´ı, kter´e se daj´ı pouˇz´ıt samostatnˇe, nicm´enˇe z d˚ uvodu uˇzivatelsk´e pˇr´ıvˇetivosti byla nad t´ımto j´adrem vytvoˇrena grafick´a nadstavba v podobˇe z´ asuvn´eho modulu pro v´ yvojov´e prostˇred´ı Eclipse. Uˇzivatel zde nejprve vytvoˇr´ı soubor s popisem nastaven´ı projektu (v´ ybˇer meta-modelu apod.) a k nˇemu pot´e vytv´aˇr´ı modely vlastnost´ı (zde oznaˇcovan´e jako family model ) a jejich konfigurace (zde oznaˇcovan´e jako application model ). Samotn´a tvorba modelu prob´ıh´a editac´ı stromov´eho diagramu v grafick´em editoru, prakticky v´ yhradnˇe s pouˇzit´ım kontextov´eho menu, a dodateˇcnˇe i v pˇr´ısluˇsn´em editaˇcn´ım panelu. Pˇri konfiguraci uˇzivatel opˇet vytv´aˇr´ı stromov´ y diagram, avˇsak jsou mu nab´ızeny pouze volby validn´ı dle dan´eho modelu vlastnost´ı (podobnˇe jako u FMP). Cel´e ˇreˇsen´ı m´ a vˇsak nˇekolik nedostatk˚ u, jako napˇr´ıklad editace modelu pomoc´ı kontex33
Dostupn´e modelovac´ı n´ astroje
Software Product Lines Online Tools
tov´eho menu, jeˇz je pomˇernˇe nepˇrehledn´e a zpomaluje pˇri pr´aci. Dan´e grafick´e ztv´arnˇen´ı diagramu pak neodpov´ıd´ a ˇz´ adn´e z pouˇz´ıvan´ ych notac´ı. Editor umoˇzn ˇuje pˇriˇrazovat vlastnostem atributy pouze pˇres r˚ uzn´e pˇreddefinovan´e sestavy (attribute set), coˇz m˚ uˇze b´ yt flexibiln´ı, avˇsak pro uˇzivatele tak´e zbyteˇcnˇe komplikovan´e a zdrˇzuj´ıc´ı. Pˇri validov´an´ı modelu jsou uˇzivateli zobrazeny v´ ypisy z pˇriloˇzen´eho XML valid´atoru, kter´e nejsou vˇzdy u ´plnˇe srozumiteln´e. Zmiˇ novan´ a moˇznost vlastn´ıho meta-modelu nemus´ı b´ yt v kaˇzd´em pˇr´ıpadˇe v´ yhodou, nebot’ jeho tvorba nen´ı nijak trivi´aln´ı.
Obr´ azek 3.3: Uk´azka pr´ace s n´astrojem XFeature.
3.4
Software Product Lines Online Tools
Software Product Lines Online Tools7 (SPLOT) je n´astroj se z´amˇerem pˇren´est v´ yzkum v oblasti modelov´ an´ı vlastnost´ı bl´ıˇze k praktick´emu vyuˇzit´ı. Tento n´astroj je, pomˇernˇe netradiˇcnˇe, implementov´ an jako webov´a aplikace, coˇz mu pˇrin´aˇs´ı ˇradu zaj´ımav´ ych v´ yhod, jako napˇr´ıklad online editaci modelu vlastnosti s moˇznost´ı n´asledn´eho uloˇzen´ı do datab´aze. Jednotliv´e modely mohou nav´ıc uˇzivatel´e mezi sebou sd´ılet. Samotn´ y (stromov´ y) editor m´a lehce omezen´e schopnosti (pouze povinn´e/voliteln´e vlastnosti a OR/XOR skupiny), avˇsak jeho ovl´ad´an´ı je velice intuitivn´ı a pˇrehledn´e. Zaj´ımavˇe je ˇreˇseno definov´ an´ı omezen´ı jako Booleovsk´ ych formul´ı (ve formˇe disjunktivn´ıch klauzul´ı), kdy uˇzivatel nejprve dosad´ı vybran´e vlastnost´ı do formule jako liter´aly a n´ aslednˇe pak m˚ uˇze nˇekter´e oznaˇcit negac´ı. Tento jazyk nen´ı sice tak komplexn´ı jako napˇr. XPath, avˇsak dok´ aˇze ho pomˇernˇe rychle zvl´adnout i nezkuˇsen´ y uˇzivatel. Konfigurace prob´ıh´ a, podobnˇe jako u FMP, zatrh´av´an´ım vlastnost´ı ve stromˇe s automa7
http://www.splot-research.org/
34
Dostupn´e modelovac´ı n´ astroje
FeatureIDE
tick´ ym blokov´ an´ım nevalidn´ıch voleb. Editor zde nav´ıc uˇzivateli dok´aˇze uk´azat vlastnosti jejichˇz v´ ybˇer je v rozporu s jin´ ymi a automaticky pak konfiguraci opravovat ˇci doplˇ novat. Na stranˇe serveru je pak tato aplikace implementov´ana pomoc´ı technologie Java EE v podobˇe 2 celk˚ u: SPLOT (j´ adro webov´e aplikace) a SPLAR (knihovna algoritm˚ u pro vyhodnocov´ an´ı model˚ u vlastnost´ı).
Obr´ azek 3.5: Uk´ azka pr´ace s n´astrojem SPLOT (konfigurace).
3.5
FeatureIDE
FeatureIDE8 m˚ uˇzeme dle jeho autor˚ u [Thum12] popsat jako open-source framework pro pro v´ yvoj software postaven´ y na modelov´an´ı vlastnost´ı9 . Tento n´astroj je implementov´ an jako sada z´ asuvn´ ych modul˚ u v´ yvojov´eho prostˇred´ı Eclipse, jeˇz jsou pak s t´ımto prostˇred´ım distribuov´ any jako jeden celek. Hlavn´ım rozd´ılem oproti pˇredchoz´ım pˇr´ıklad˚ um je vˇsak zamˇeˇren´ı samotn´eho n´astroje, kter´ y se neorientuje jen pouze na f´azi dom´enov´e anal´ yzy, ale snaˇz´ı se pokr´ yt cel´ y proces dom´enov´eho inˇzen´ yrstv´ı (viz obr. 2.2). Jin´ ymi slovy, mimo samotn´e vytv´aˇren´ı model˚ u vlastnost´ı a jejich konfigurace je tak´e podporov´ano: 8 9
http://wwwiti.cs.uni-magdeburg.de/iti_db/research/featureide/ Ponˇekud nepˇresn´ y pˇreklad pojmu Feature-oriented software development.
35
Dostupn´e modelovac´ı n´ astroje
FeatureIDE
1. Mapov´ an´ı vlastnost´ı na jednotliv´e zdrojov´e ˇc´asti aplikace. 2. Sestaven´ı v´ ysledn´e aplikace dle vybran´ ych vlastnost´ı (konfigurace). Aby bylo moˇzn´e tyto dva kroky zajistit, bylo FeatureIDE integrov´ano s celou ˇradou jiˇz dostupn´ ych n´ astroj˚ u10 , jako je AHEAD, FeatureHouse, FeatureC++, DeltaJ, AspectJ, Munge a Antenna. Podporu pro dalˇs´ı n´astroje je pak moˇzn´e pˇridat skrze rozˇs´ıˇren´ı. N´astroj nejen ˇze podporuje editaci zdrojov´ ych k´od˚ u jazyk˚ u v´ yˇse zm´ınˇen´ ych n´astroj˚ u, ale integruje tyto n´ astroje s modely vlastnost´ı v jeden celek, takˇze je pro uˇzivatele napˇr´ıklad moˇzn´e urˇcit, kter´ a ˇc´ ast zdrojov´eho k´ odu odpov´ıd´a implementaci kter´e vlastnosti a naopak.
Obr´ azek 3.6: Uk´azka pr´ace s n´astrojem FeatureIDE. Zamˇeˇrme se ale zpˇet na oblast modelov´an´ı vlastnost´ı. FeatureIDE umoˇzn ˇuje vytv´aˇre modely vlastnost´ı pomoc´ı grafick´e editace diagram˚ u. U modelu vlastnost´ı jsou podporov´any pouze povinn´e/voliteln´e vlastnosti11 a OR/XOR skupiny, kde kaˇzd´a vlastnost m˚ uˇze m´ıt nav´ıc pod sebou maxim´ alnˇe jednu skupinu. Samotn´a pr´ace s editorem je velmi rychl´a a pohodln´a, aˇckoliv prob´ıh´ a v´ yhradnˇe pˇres kontextov´e menu, s pˇr´ıpadn´ ym ruˇcn´ım pˇretaˇzen´ım uzlu pod jin´eho rodiˇce. Uˇzivatel zde m´a nav´ıc moˇznost pouˇz´ıt pro strom diagramu jedno z automatick´ ych rozvrˇzen´ı m´ısto manu´aln´ıho pozicov´an´ı uzl˚ u. Zaj´ımav´a je podpora pˇr´ım´e editace zdrojov´eho k´ odu modelu (XML dokumentu), kdy jsou jeho zmˇeny automaticky prom´ıt´ any do diagramu a naopak. 10 AHEAD, FeatureHouse a FeatureC++ jsou n´ astroje ˇci jazyky zamˇeˇren´e na tzv. Feature-oriented programming. DeltaJ je rozˇs´ıˇren´ı jazyka Java pro tzv. Delta-oriented programming. AspectJ je rozˇs´ıˇren´ı jazyka Java pro aspektovˇe orientovan´e programov´ an´ı. Munge a Antenna jsou preprocesory zdrojov´eho k´ odu jazyka Java. Pro detailnˇejˇs´ı informace odk´ aˇzeme ˇcten´ aˇre na [Thum12]. 11 Nˇekter´e vlastnosti je moˇzno tak´e oznaˇcit jako skryt´e (nezobrazuj´ı se), ˇci abstraktn´ı (nemaj´ı v k´ odu ˇza ´dnou implementaci).
36
Dostupn´e modelovac´ı n´ astroje
pure::variants
Pro editaci omezen´ı nab´ız´ı FeatureIDE vlastn´ı jazyk postaven´ y na Booleovsk´e algebˇre. Editor tˇechto omezen´ı podporuje napov´ıd´an´ı a automatick´e doplˇ nov´an´ı vhodn´ ych moˇznost´ı. Dan´ a omezen´ı jsou pak zobrazena jako souˇc´ast diagramu. Proces konfigurace je velmi podobn´ y pˇredchoz´ım n´ astroj˚ um (FMP, SPLOT), kdy jsou uˇzivateli automaticky blokov´ any nevyhovuj´ıc´ı moˇznosti a je mu ukazov´an zb´ yvaj´ıc´ı poˇcet moˇzn´ ych konfigurac´ı. Uˇzivatel m´ a nav´ıc moˇznost zapnout si pokroˇcil´ y m´od konfigurace, kdy m˚ uˇze nˇekter´e vlastnosti z konfigurace explicitnˇe vyˇradit. D˚ uleˇzit´e je tak´e zm´ınit moˇznost importu ˇci exportu model˚ u z jin´ ych n´ astroj˚ u (FMP, SPLOT, SPLConqueror, GUIDSL). Pro popis ostatn´ıch vlastnost´ı FeatureIDE odk´ aˇzeme ˇcten´aˇre na [Thum12].
3.6
pure::variants
Pure::variants pˇredstavuje jedno z m´ala komerˇcn´ıch ˇreˇsen´ı pro modelov´an´ı variability software. Tento n´ astroj se, podobnˇe jako FeatureIDE, nezamˇeˇruje pouze na samotn´e modelov´an´ı vlastnost´ı, ale snaˇz´ı se pokr´ yt vˇsechny f´aze v´ yvojov´eho procesu software. N´astroj umoˇzn ˇuje pracovat celkem se ˇctyˇrmi r˚ uzn´ ymi modely: 1. Feature model - Model vlastnost´ı. 2. Family model - Definuje architekturu rodiny produkt˚ u (jej´ı logick´e i fyzick´e elementy) a mapov´ an´ı jednotliv´ ych vlastnost´ı na tuto architekturu. 3. Variant description model - Konfigurace vlastnost´ı. 4. Variant result model - V´ ystupn´ı model popisuj´ıc´ı konkr´etn´ı aplikaci z rodiny produkt˚ u a obsahuj´ıc´ı informace pro jej´ı sestaven´ı. Pro kaˇzd´ y z tˇechto uveden´ ych model˚ u (s v´ yjimkou posledn´ıho, jeˇz lze pouze zobrazit) je k dispozici samostatn´ y editor. Editace modelu vlastnost´ı prob´ıh´a v klasick´em stromov´em editoru s pouˇzit´ım kontextov´eho menu, jeˇz obsahuje vˇsechny z´akladn´ı funkce a je pomˇernˇe pˇrehledn´e. Uˇzivatel m˚ uˇze vytv´ aˇret celkem 4 typy r˚ uzn´ ych vlastnost´ı (povinn´e, voliteln´e, alternativn´ı a sluˇciteln´e), kde u posledn´ı uveden´e varianty lze v r´amci skupiny volitelnˇe nastavit i jej´ı kardinalitu. Hlavn´ım rozd´ılem oproti ostatn´ım n´astroj˚ um je zde moˇznost pˇriˇradit k vlastnostem pomˇernˇe velk´e mnoˇzstv´ı dodateˇcn´ ych informac´ı, jako je napˇr´ıklad stav, verze, priorita, popis, zd˚ uvodnˇen´ı, datum vytvoˇren´ı, autor apod. Jedn´e vlastnosti lze tak´e pˇriˇradit neomezen´e mnoˇzstv´ı atribut˚ u, jejichˇz typ nen´ı omezen pouze na z´akladn´ı datov´e typy, ale m˚ uˇze j´ıt napˇr´ıklad o datum, prioritu, URL, odkaz na jinou ˇc´ast modelu atd. Editor nav´ıc podporuje i alternativn´ı zobrazen´ı modelu vlastnost´ı jako grafov´e struktury, avˇsak pouze s omezen´ ymi moˇznostmi editace. Zaj´ımav´ y je pˇr´ıstup n´ astroje ke glob´aln´ım omezen´ım, kter´a jsou rozdˇelena do dvou skupin: omezen´ı (constraints) a tzv. restrikce (restrictions). Prvn´ı uveden´a skupina slouˇz´ı definov´ an´ı glob´ aln´ıch podm´ınek integrity cel´e konfigurace, druh´a pak slouˇz´ı k definov´an´ı podm´ınek za jak´ ych lze danou vlastnost v konfiguraci vybrat (restrikce mus´ı b´ yt tedy pˇriˇrazena vˇzdy k urˇcit´e vlastnosti). Pro z´apis obou typ˚ u omezen´ı lze pouˇz´ıt bud’ dialekt jazyka prolog pvProlog, nebo jazyk vych´azej´ıc´ı z Booleovsk´e algebry nazvan´ y pvSCL, kde druh´ y zmiˇ novan´ y pak podporuje nejen logick´e, ale relaˇcn´ı operace pro porovn´an´ı atribut˚ u. 37
Dostupn´e modelovac´ı n´ astroje
pure::variants
Oba dva jazyky lze nav´ıc pouˇz´ıt k v´ ypoˇctu poˇc´ateˇcn´ıch hodnot atribut˚ u. Mimo popsan´ a omezen´ı lze mezi jednotliv´ ymi vlastnostmi definovat tak´e pˇr´ım´ y vztah (relation), jako napˇr´ıklad vyˇzaduje ˇci je v konfliktu s.
Obr´ azek 3.7: Uk´azka pr´ace s n´astrojem pure::variants. Tvorba konfigurace prob´ıh´ a, jako u nˇekter´ ych pˇredchoz´ıch n´astroj˚ u, zatrh´av´an´ım ˇci vyˇrazov´an´ım vlastnost´ı ve stromu. N´ astroj pure::variants nab´ız´ı ze vˇsech zkouman´ ych n´astroj˚ u pravdˇepodobnˇe nejlepˇs´ı asistenci uˇzivateli pˇri tvorbˇe konfigurace, vˇcetnˇe blokov´an´ı neplatn´ ych voleb, zv´ yrazˇ nov´ an´ı chyb a moˇznostmi automatick´e opravy ˇci automatick´eho doplˇ nov´ an´ı. Nav´ıc lze jednotliv´e konfigurace od sebe navz´ajem odvozovat (dˇed´ı pak mezi sebou vybran´e vlastnosti). V´ ysledn´ y popis sestaven´e aplikace (variant result model ) je pak moˇzn´e z konfigurace vytvoˇrit transformaˇcn´ım procesem, kter´ y je bud’ standardn´ı (odvozen z informac´ı z model˚ u) nebo uˇzivatelsky definovan´ y (vyj´adˇren´ y jako XSLT transformace, nebo pomoc´ı jazyka JavaScript). Mimo tyto z´ akladn´ı editory je tak´e k dispozici, jiˇz zm´ınˇen´ y, family model editor (hierarchick´ y popis architektury s mapov´an´ım vlastnost´ı), maticov´ y editor (zobrazen´ı nˇekolika konfigurac´ı ve sloupc´ıch oproti vybran´ ym vlastnostem v ˇr´adc´ıch) ˇci compare editor (vizu´aln´ı porovn´ an´ı dvou model˚ u vlastnost´ı). Pure::variants d´ale nab´ız´ı nˇekolik pomocn´ ych pohled˚ u (views), napˇr´ıklad pro zobrazen´ı atribut˚ u a vztah˚ u mezi vlastnostmi, ˇci pro zobrazen´ı v´ ysledn´e konfigurace. Pro integraci s ostatn´ımi n´ astroji je k dispozici import a export model˚ u v r˚ uzn´ ych datov´ ych form´ atech (CSV, XML, HTML, DOT12 ). Mimo to vˇsak pure::variants obsahuje 12 Jazyk n´ astroje GraphViz (http://www.graphviz.org/), kter´ y umoˇzn ˇuje vizualizovat grafov´e struktury. Zde slouˇz´ı k z´ apisu stromov´e struktury modelu vlastnost´ı.
38
Dostupn´e modelovac´ı n´ astroje
BigLever Software Gears
i pˇr´ımou integraci do nˇekter´ ych jin´ ych komerˇcn´ıch n´astroj˚ u, jmenovitˇe napˇr´ıklad IBM Rational DOORS/ClearQuest/Rhapsody, ˇci Enterprise Architect. Popis dalˇs´ıch vlastnost´ı n´astroje pure::variants lze nal´ezt v [Pure13].
3.7
BigLever Software Gears
Gears od spoleˇcnosti BigLever Software je dalˇs´ım pˇr´ıkladem komerˇcn´ıho ˇreˇsen´ı pro v´ yvoj produktov´ ych ˇrad software. Obdobnˇe jako pure::variants, i Gears pokr´ yv´a cel´ y v´ yvojov´ y proces od f´ aze anal´ yzy aˇz po sestaven´ı konkr´etn´ı varianty aplikace, avˇsak na rozd´ıl od pure::variants nen´ı Gears jeden samostatn´ y n´astroj, ale ucelen´ y framework pro tvorbu produktov´ ych ˇrad13 . Z´akladem Gears je v´ yvojov´e prostˇred´ı nazvan´e Software Product Line Development Environment, jeˇz slouˇz´ı k n´ avrhu produktov´e ˇrady. Souˇc´ast´ı takov´eho n´avrhu je zejm´ena vytv´aˇren´ı model˚ u vlastnost´ı a jejich mapov´an´ı na jednotliv´e body variace (variation points), oznaˇcuj´ıc´ı m´ısta ve kter´ ych se mohou jednotliv´e varianty v´ ysledn´ ych aplikac´ı liˇsit. Pˇr´ıkladem takov´ ych m´ıst jsou napˇr´ıklad sloˇzky, soubory, ˇc´asti textov´ ych soubor˚ u, nebo vybran´e elementy UML model˚ u (oznaˇcen´e pomoc´ı dan´eho stereotypu). Vyhodnocen´ı jednotliv´ ych bod˚ u variace je pak provedeno pomoc´ı tzv. konfigur´atoru, jeˇz z r˚ uzn´ ych vstupn´ıch fragment˚ u (poˇzadavky, n´avrhy model˚ u, zdrojov´ y k´od, uˇzivatelsk´ a dokumentace, testovac´ı pˇr´ıpady) vytv´aˇr´ı obdobn´e fragmenty pro konkr´etn´ı variantu aplikace. To, kter´e ˇc´ asti fragment˚ u a zp˚ usob jak´ ym budou do v´ ysledn´e varianty zahrnuty, je definov´ ano pomoc´ı tzv. profil˚ u (feature profiles), obsahuj´ıc´ıch danou konfiguraci vlastnost´ı. M´ısto toho, aby Gears implementoval vlastn´ı n´astroje pro jednotliv´e f´azi v´ yvoje, poskytuje integraci s jiˇz existuj´ıc´ımi produkty, jako je napˇr´ıklad ˇrada IBM Rational (DOORS, Rhapsody, Synergy, Quality Manager, Team Concert), ˇci v´ yvojov´a prostˇred´ı Eclipse a Microsoft Visual Studio14 . Propojen´ı s tˇemito n´astroji je realizov´ano pomoc´ı rozˇs´ıˇren´ı frameworku Gears, tzv. most˚ u (bridge), jeˇz mohou b´ yt bud’ jednostrann´e (implementovan´e na stranˇe Gears), ˇci oboustrann´e (implementovan´e i jako rozˇs´ıˇren´ı na stranˇe n´astroje15 ). Gears nav´ıc nab´ız´ı SDK, kter´e umoˇzn ˇuje i ostatn´ım v´ yvoj´aˇr˚ u vytvoˇrit most pro integraci Gears s jejich vlastn´ımi aplikacemi. Pro dalˇs´ı informace odk´aˇzeme ˇcten´aˇre na [Kru13].
3.8
KConfig
Vˇsechny doted’ pˇredstaven´e n´ astroje byly pomˇernˇe univerz´aln´ı, nebot’ umoˇzn ˇovaly modelovat variabilitu prakticky libovoln´eho objektu. KConfig je uk´azkou opaˇcn´eho pˇr´ıstupu, kdy je modelov´ an´ı variability zamˇeˇreno pouze na jeden konkr´etn´ı pˇredmˇet, v tomto pˇr´ıpadˇe j´adro operaˇcn´ıho syst´emu Linux16 . Na tomto m´ıstˇe je d˚ uleˇzit´e ˇcten´aˇre upozornit, ˇze KConfig nen´ı ve sv´e podstatˇe n´astroj, 13
Product Line Engineering Lifecycle FrameworkTM , jak toto ˇreˇsen´ı naz´ yv´ a pˇr´ımo spoleˇcnost BigLever. Na Gears se tak vlastnˇe m˚ uˇzeme d´ıvat jako na integraˇcn´ı framework pro v´ yvoj SPL. 15 To zejm´ena v pˇr´ıpadˇe, ˇze zpracov´ avan´e fragmenty jsou v n´ astroji internˇe uloˇzeny v nˇejak´em propriet´ arn´ım form´ atu. 16 https://www.kernel.org/ 14
39
Dostupn´e modelovac´ı n´ astroje
KConfig
Obr´azek 3.8: Uk´ azka pr´ ace s n´ astrojem Software Product Line Development Environment (souˇc´ast frameworku Gears). ale pouze textov´ y jazyk17 , kter´ y slouˇz´ı k popisu r˚ uzn´ ych konfiguraˇcn´ıch voleb urˇcuj´ıc´ıch jak bude Linuxov´e j´ adro sestaveno. Nad konfiguraˇcn´ı datab´az´ı zapsanou v tomto jazyce pak uˇzivatel m˚ uˇze spustit jeden z dostupn´ ych konfiguraˇcn´ıch n´astroj˚ u (napˇr. menuconfig ˇci xconfig, viz obr. 3.9) a vybrat v nˇem napˇr´ıklad jak´e moduly budou do j´adra zahrnuty. Tento pˇr´ıklad zde uv´ ad´ıme zejm´ena proto, ˇze jde o re´alnou uk´azku pouˇzit´ı modelov´an´ı variability v praxi. Konfiguraˇcn´ı datab´azi j´adra Linux nav´ıc m˚ uˇzeme dle [She10] ch´apat jako na jeden z nejrozs´ ahlejˇs´ıch publikovan´ ych model˚ u vlastnost´ı. Popis moˇznost´ı jazyka KConfig a jeho vazby na koncept modelov´an´ı vlastnost´ı lze nal´ezt ve zm´ınˇen´e publikaci [She10]. Samotn´ y jazyk KConfig nen´ı vyuˇz´ıv´an pouze v Linuxov´em j´adˇre, ale i u jin´ ych projekt˚ u, jako BusyBox18 ˇci uClibc19 . Kromˇe KConfig existuj´ı i jin´e obdobnˇe koncipovan´e jazyky, napˇr´ıklad CDL, pouˇz´ıvan´ y pro vestavˇen´ y operaˇcn´ı syst´em eCos20 . 17
Obr´ azek 3.9: Uk´azka pr´ace s n´astrojem xconfig.
3.9
Nˇ ekter´ e dalˇ s´ı n´ astroje
Mimo v´ yˇse zm´ınˇen´ y v´ yˇcet existuj´ı samozˇrejmˇe i dalˇs´ı n´astroje zamˇeˇren´e na modelov´an´ı vlastnost´ı, avˇsak vˇetˇsinou se sv´ ym rozsahem a zamˇeˇren´ım od tˇech zde zm´ınˇen´ ych pˇr´ıliˇs neliˇs´ı. Pˇresto si nˇekolik dalˇs´ıch pro pˇrehled uvedeme. Mezi rozs´ ahlejˇs´ı projekty zamˇeˇren´e na v´ yvoj produktov´ ych ˇrad sofrware bychom mohli 21 zaˇradit CIDE , v´ yvojov´e prostˇred´ı, kter´e umoˇzn ˇuje program´atorovi anotovat (doslova v editoru vizu´ alnˇe obarvit) k´ od implementuj´ıc´ı r˚ uzn´e vlastnosti. Obdobn´ ym projektem je pak i Feature Commander22 , odliˇsuj´ıc´ı barevnˇe zdrojov´ y k´od jednotliv´ ych vlastnost´ı (identifikovan´ ych makry preprocesoru jazyk˚ u C/C++). Velk´ a ˇc´ ast n´ astroj˚ u je, podobnˇe jako FMP, implementov´ana jako z´asuvn´ y modul do v´ yvojov´eho prostˇred´ı Eclipse. Zde m˚ uˇzeme kupˇr´ıkladu jmenovat Feature Diagram Editor23 nebo Feature Diagrams24 , jeˇz se ˇrad´ı k jednoduˇsˇs´ım n´astroj˚ um (prakticky umoˇzn ˇuj´ı pouze tvorbu diagram˚ u vlastnost´ı). Pomˇernˇe pokroˇcilejˇs´ı z´ asuvn´e moduly Eclipse jsou pak Compositional Variability Ma21
nager25 (framework pro modelov´ an´ı variability), Feature Mapper26 (umoˇzn ˇuj´ıc´ı mapov´an´ı vlastnost´ı na r˚ uzn´e ˇc´ asti EMF model˚ u a jejich vizualizaci), Hydra27 (obsahuj´ıc´ı grafick´ y editor diagram˚ u spolu s textov´ ym editorem omezen´ı, valid´atorem a grafick´ ym konfigur´ atorem), S2T2 Configurator28 (obsahuj´ıc´ı interaktivn´ı grafick´ y konfigur´ator, viz obr. 3.10) ˇci MOSKitt Feature Modeler29 .
Obr´ azek 3.10: Interaktivn´ı konfigurace s n´astrojem S2T2 (starˇs´ı verze 0.1.1). Na tomto m´ıstˇe je d˚ uleˇzit´e zm´ınit, ˇze v r´amci v´ yvoje prostˇred´ı Eclipse existuje samostatn´ y 30 projekt EMF Feature Model , jehoˇz c´ılem je vytvoˇrit framework a editor pro modelov´an´ı vlastnost´ı. Tento projekt je zat´ım ve st´adiu poˇc´ateˇcn´ıho v´ yvoje. Posledn´ımi n´ astroji, kter´e zde jeˇstˇe uvedeme, jsou pak Feature Modeling Tool31 (rozˇs´ıˇren´ı pro Microsoft Visual Studio) a Requiline32 (umoˇzn ˇuje z´aroveˇ n modelov´an´ı vlastnost´ı i poˇzadavk˚ u). Na z´ avˇer jeˇstˇe dodejme, ˇze nˇekteˇr´ı autoˇri se nevydali cestou grafick´eho modelov´an´ı, ale pouˇz´ıvaj´ı k vyj´ adˇren´ı modelu vlastnost´ı textov´ y jazyk. Pˇr´ıkladem je napˇr´ıklad Clafer33 (jazyk pro modelov´ an´ı probl´emov´e dom´eny, umoˇzn ˇuj´ıc´ı unifikovanˇe popsat vlastnosti, tˇr´ıdy a 25
meta-modely, spolu s jejich omezen´ımi), nebo FAMILIAR34 (umoˇzn ˇuje definici, manipulaci a sluˇcov´ an´ı model˚ u vlastnost´ı).
3.10
Porovn´ an´ı n´ astroj˚ u
V t´eto kapitole jsme si pˇredstavili pomˇernˇe velk´e mnoˇzstv´ı odliˇsn´ ych n´astroj˚ u. Pokusme se zde tedy uv´est seznam jejich nejz´asadnˇejˇs´ıch rozd´ıl˚ u, jeˇz bychom mˇeli br´at v potaz pˇri n´avrhu a implementaci naˇseho vlastn´ıho n´astroje. 1. Zamˇeˇren´ı - Vˇetˇsina n´ astroj˚ u byla vytvoˇrena jako univerz´aln´ı (dok´azaly modelovat vlastnosti libovoln´eho objektu), avˇsak nˇekter´e byly zamˇeˇren´e na specifikou c´ılovou oblast (KConfig). 2. Implementaˇcn´ı technologie - Velk´a ˇc´ast n´astroj˚ u byla implementov´ana jako z´asuvn´ y modul do v´ yvojov´eho prostˇred´ı Eclipse (FMP, pure::variants, FeatureIDE, CIDE atd.), nˇekter´e v´ yjimeˇcnˇe i jako rozˇs´ıˇren´ı pro MS Visual Studio (Feature Modeling Tool). Pˇr´ıkladem dalˇs´ıch implementaˇcn´ıch technologi´ı je napˇr´ıklad pouˇzit´ı frameworku Qt s jazykem C++ (FeatureCommander) ˇci pouˇzit´ı frameworku .NET (Requiline). 3. Meta-model • Vˇetˇsina n´ astroj˚ u podporuje modelov´an´ı alespoˇ n povinn´ ych/voliteln´ ych vlastnost´ı a OR/XOR skupin35 . Nˇekter´e n´astroje (pure::variants) povolovaly specifikovat kardinalitu v r´amci skupiny, jin´e (FMP) pak i u vlastnost´ı. Zvl´aˇstn´ım pˇr´ıpadem je pak CaptainFeature, kter´ y umoˇzn ˇoval uv´est kardinalitu nejobecnˇeji, jako posloupnost interval˚ u. • Vˇetˇsina n´ astroj˚ u umoˇzn ˇovala definovat atributy, a to bud’ maxim´alnˇe jeden pro kaˇzdou vlastnost (FMP) nebo neomezen´e mnoˇzstv´ı (pure::variants). Nˇekter´e n´ astroje atributy v˚ ubec neuvaˇzovaly (FeatureIDE). Speci´aln´ım pˇr´ıpadem je pak XFeature, kter´ y umoˇzn ˇoval v r´amci meta-modelu atributy rozdˇelovat do skupin. • Zat´ımco nˇekter´e n´ astroje podporovaly pouze nˇekolik z´akladn´ı typ˚ u atribut˚ u, jako ˇc´ıslo, ˇretˇezec ˇci reference (FMP), jin´e nab´ızely i pomˇernˇe netradiˇcn´ı typy, jako kupˇr´ıkladu datum nebo URL (pure::variants). • R˚ uzn´ a byla tak´e podpora dodateˇcn´ ych informac´ı uchov´avan´ ych v r´amci modelu. Dobr´ ym pˇr´ıkladem je zde pure::variants, kter´ y umoˇzn ˇoval pro vlastnost specifikovat napˇr´ıklad prioritu, verzi, datum vytvoˇren´ı a spoustu dalˇs´ıch. 4. Rozˇsiˇritelnost meta-modelu - Vˇetˇsina n´astroj˚ u pouˇz´ıvala pevnˇe dan´ y meta-model, jeˇz nˇekter´e dok´ azaly uˇzivateli i zobrazit (CaptainFeature). FMP jako jeden z m´ala umoˇzn ˇoval do meta-modelu pˇrid´avat dodateˇcn´e prvky a speci´aln´ım pˇr´ıpadem je pak XFeature s moˇznost´ı definice vlastn´ıho meta-modelu. 34 35
http://familiar-project.github.io/ Nˇekter´e n´ astroje (FeatureIDE, pure::variants) pouˇz´ıvaj´ı oznaˇcen´ı sluˇciteln´e/alternativn´ı vlastnosti.
43
Dostupn´e modelovac´ı n´ astroje
Porovn´ an´ı n´ astroj˚ u
5. Implementaˇcn´ı technologie meta-modelu - Velk´a ˇc´ast n´astroj˚ u realizovan´ ych jako z´ asuvn´ y modul Eclipse (FMP, Feature Diagrams, S2T2 atd.) zvolila pro implementaci meta-modelu Eclipse Modeling Framework (EMF), jeˇz je souˇc´ast´ı zm´ınˇen´e platformy. Nˇekter´e n´ astroje (pure::variants, FeatureIDE), aˇc tak´e postaven´e na platformˇe Eclipse, implementuj´ı meta-model vlastn´ım zp˚ usobem. Speci´aln´ım pˇr´ıpadem je zde opˇet XFeature, jehoˇz meta-model je postaven ˇcistˇe na XML technologi´ıch. 6. Datov´y form´ at - Prakticky vˇsechny n´astroje ukl´adaly model ve form´atu XML ˇci XMI. Objevily se ale i v´ yjimky (FeatureIDE), kdy byla konfigurace uloˇzena jen jako seznam vybran´ ych vlastnost´ı po ˇr´adc´ıch. 7. Editor modelu vlastnost´ı - N´astroje v z´asadˇe pouˇz´ıvaly dva pˇr´ıstupy editace modelu, a to bud’ pomoc´ı stromov´eho editoru (FMP, SPLOT, Compositional Variability Manager) nebo grafick´eho editoru diagram˚ u (CaptainFeature, XFeature, FeatureIDE). N´ astroje pouˇz´ıvaj´ıc´ı grafick´ y editor pak umoˇzn ˇovaly bud’ pouze manu´aln´ı pozicov´an´ı prvk˚ u (XFeature) nebo i jejich automatick´e rozm´ıstˇen´ı dle jednoho ˇci v´ıce algoritm˚ u (FeatureIDE). Zvl´ aˇstn´ım pˇr´ıpadem je FeatureIDE, kter´e podporovalo souˇcasnˇe s grafickou editac´ı i pˇr´ımou editaci XML reprezentace modelu. 8. Zp˚ usob editace - N´ astroje typicky pouˇz´ıvaly pro editaci hlavnˇe kontextov´e menu, kter´e vˇsak bylo v nˇekter´ ych pˇr´ıpadech ponˇekud pˇrehledn´e (XFeature). Vyuˇzit´ı n´ astrojov´e liˇsty s tlaˇc´ıtky a kl´avesov´ ych zkratek bylo mezi editory r˚ uzn´e. Nˇekter´e grafick´e editory (S2T2) nav´ıc pouˇz´ıvaly i n´astrojovou paletu. Velk´a ˇc´ast n´astroj˚ u tak´e nˇejak´ ym zp˚ usobem podporovala pˇretaˇzen´ı prvk˚ u (drag and drop). Detaily jednotliv´ ych objekt˚ u se pak obvykle nastavovaly v pˇr´ısluˇsn´em panelu (typicky ˇslo o properties view u Eclipse). 9. Editor konfigurace vlastnost´ı - Zde vˇetˇsina n´astroj˚ u upˇrednostnila klasick´ y stromov´ y editor pˇred nˇejak´ ym grafick´ ym zp˚ usobem reprezentace konfigurace. Ve stromov´em editoru ˇslo obvykle vlastnost bud’ vybrat zatrˇzen´ım, nebo ji rovnou z konfigurace vyˇradit. Zaj´ımav´ y byl pˇr´ıstup FeatureIDE, kter´e umoˇzn ˇovalo konfiguraci v z´akladn´ım a pokroˇcil´em m´ odu (bylo povoleno v´ıce stav˚ u vlastnost´ı). Alternativn´ı grafickou reprezentaci konfigurace pak zvolilo jen nˇekolik n´astroj˚ u (XFeature, S2T2). 10. Asistence pˇri konfiguraci - V z´asadˇe vˇetˇsina n´astroj˚ u podporovala alespoˇ n detekci a zobrazen´ı konfiguraˇcn´ıch chyb a skr´ yv´an´ı neplatn´ ych konfiguraˇcn´ıch voleb. Nˇekter´e n´ astroje (SPLOT, pure::variants) dok´azaly i identifikovat konflikty a nab´ıdnout uˇzivateli jejich automatick´e odstranˇen´ı. Dalˇs´ım zaj´ımav´ ym prvkem bylo automatick´e doplˇ nov´ an´ı voleb (pure::variants, FeatureIDE) ˇci zobrazen´ı zb´ yvaj´ıc´ıho poˇctu validn´ıch konfigurac´ı (FMP, pure::variants, FeatureIDE). N´astroje s podporou kardinality (FMP, XFeature) pak umoˇzn ˇovaly i duplikaci vlastnost´ı. 11. Specializace modelu vlastnost´ı - Specializaci modelu vlastnost´ı umoˇzn ˇovaly pouze dva n´ astroje (CaptainFeature a FMP)36 . Specializace by tak´e byl pravdˇepodobnˇe schopen i XFeature, pˇri spr´avnˇe zvolen´em meta-modelu. 36
Nˇekter´e n´ astroje (pure::variants, FeatureIDE) sice umoˇzn ˇovaly pˇri konfiguraci explicitnˇe vyˇradit nˇekter´e volby, avˇsak zde o specializaci modelu vlastnost´ı nejedn´ a.
44
Dostupn´e modelovac´ı n´ astroje
Porovn´ an´ı n´ astroj˚ u
12. Definice omezen´ı - Vˇetˇsina n´astroj˚ u umoˇzn ˇovala definovat omezen´ı v textov´e formˇe, bud’ pomoc´ı nˇejak´eho vlastn´ıho jazyka vych´azej´ıc´ıho z Booleovsk´e algebry (FeatureIDE, pure::variants), nebo pomoc´ı jiˇz nˇejak´eho existuj´ıc´ıho jazyka (XPath u FMP a XFeature, pvProlog u pure::variants). Speci´aln´ım pˇr´ıpadem byl pure::variants, kter´ y u textov´ ych omezen´ı rozliˇsoval 2 typy (omezen´ı a restrikce). Jen mal´a ˇc´ast n´astroj˚ u umoˇzn ˇovala definovat mezi vlastnostmi i jin´e (netextov´e) vazby (pure::variants, S2T2). 13. Editace omezen´ı - Pro textov´a omezen´ı nab´ızely n´astroje vˇetˇsinou nˇejak´e automatick´e doplˇ nov´ an´ı vhodn´ ych kl´ıˇcov´ ych slov ˇci n´azv˚ u vlastnost´ı a jejich barevn´e zv´ yraznˇen´ı. Zaj´ımav´ y byl pˇr´ıstup n´astroje SPLOT umoˇzn ˇuj´ıc´ı uˇzivateli vytv´aˇret omezen´ı pouze s pomoc´ı myˇsi. N´ astroje podporuj´ıc´ı definici pˇr´ım´ ych vazeb mezi vlastnostmi je vytv´ aˇrely bud’ pomocn´ ym dialogem (pure::variants) ˇci graficky (S2T2). 14. Vizualizace - Nˇekter´e n´ astroje poskytovaly uˇzivateli r˚ uzn´e pomocn´e pohledy na modelovan´e objekty. Dobr´ ym pˇr´ıkladem je zde pure::variants, poskytuj´ıc´ı napˇr´ıklad pohled zobrazuj´ıc´ı vztahy mezi jednotliv´ ymi vlastnostmi. Zm´ınˇen´ y n´astroj tak´e umoˇzn ˇoval vizualizaci modelu vlastnost´ı jako grafu s omezen´ ymi moˇznostmi editace. 15. Integrace s ostatn´ımi n´ astroji - N´astroje obvykle umoˇzn ˇovaly alespoˇ n import ˇci export datov´ ych form´ at˚ u jin´ ych zn´am´ ych n´astroj˚ u (obvykle ˇslo o pure::variants), pˇr´ıpadnˇe i export do jin´eho datov´eho form´atu neˇz XML (napˇr. CSV u FeatureIDE). Pro nˇekter´e (pure::variants, Gears) byla pak d˚ uleˇzit´a i pˇr´ım´a integrace s ostatn´ımi komerˇcn´ımi n´ astroji.
45
4 Poˇzadavky na vytv´aˇren´y n´astroj V pˇredchoz´ı kapitole jsme si pˇredstavili ˇradu jiˇz existuj´ıc´ıch n´astroj˚ u a provedli jsme jejich srovn´an´ı z hlediska technick´e u ´rovnˇe, funkcionality a pˇr´ıstupu k uˇzivateli. Na z´akladˇe zjiˇstˇen´ ych fakt˚ u se nyn´ı pokus´ıme sestavit seznam poˇzadavk˚ u na n´ami vytv´aˇren´ y n´astroj.
4.1
Obecn´ e poˇ zadavky
• Zamˇeˇren´ı - N´ astroj by mˇel b´ yt univerz´aln´ı a mˇel by uˇzivatele co nejm´enˇe omezovat v tom co chce modelovat. • Implementaˇcn´ı technologie - Zvolen´a implementaˇcn´ı technologie by mˇela hlavˇe usnadnit v´ yvoj samotn´eho n´ astroje. Dalˇs´ım d˚ uleˇzit´ ym poˇzadavkem je pak multiplatformnost v´ ysledn´eho ˇreˇsen´ı. • Souˇc´ asti - N´ astroj by mˇel umoˇzn ˇovat tvorbu model˚ u vlastnost´ı a z nich odvozen´ ych konfigurac´ı. N´ astroj by pˇr´ıpadnˇe mohl i umoˇzn ˇovat specializaci model˚ u vlastnost´ı, avˇsak tato funkcionalita se nezd´a b´ yt pˇr´ıliˇs z´asadn´ı, nebot’ ji implementovalo jen velmi m´ alo n´ astroj˚ u (CaptainFeature, FMP). Umoˇznˇen´ı popisu architektury rodiny produkt˚ u a jej´ıho propojen´ı s modelem vlastnost´ı (tak jak to um´ı napˇr´ıklad pure::variants) je nad r´ amec t´eto pr´ace, a proto nebude v n´astroji ˇreˇseno.
4.2
Poˇ zadavky na meta-model
• Struktura - Model vlastnost´ı by mˇel m´ıt stromovou strukturu, a ne strukturu acyklick´eho grafu. Takto uvaˇzovala model vlastnost´ı vˇetˇsina n´astroj˚ u. • Vlastnosti - Mˇelo by b´ yt moˇzn´e vytv´aˇret z´akladn´ı typy vlastnost´ı, tedy povinn´e a voliteln´e. Aˇckoliv nˇekter´e z n´astroj˚ u nepodporovaly duplikovateln´e vlastnosti, autorovi se zd´ a b´ yt tento typ vlastnost´ı pomˇernˇe z´asadn´ı a proto by ho mˇel v´ ysledn´ y n´ astroj tak´e podporovat. Kardinalita vlastnosti by mˇela b´ yt vyj´adˇrena pouze jako interval, ne jako posloupnost interval˚ u u CaptainFeature. • Skupiny - Vˇetˇsina n´ astroj˚ u seskupov´an´ı vlastnost´ı nˇejak´ ym zp˚ usobem podporuje a mˇel by ho tedy podporovat i vytv´aˇren´ y n´astroj, vˇcetnˇe moˇznosti specifikace kardinality skupin jako intervalu. • Atributy - Jako vˇetˇsina ostatn´ıch n´astroj˚ u, i n´ami vytv´aˇren´ y n´astroj by mˇel umoˇzn ˇovat pˇriˇrazovat vlastnostem atributy. Zde se jev´ı jako nejpraktiˇctˇejˇs´ı pˇr´ıstup n´astroj˚ u typu pure::variants, kter´e umoˇzn ˇovaly neomezen´ y poˇcet atribut˚ u na jednu vlastnost. Pro atributy by mˇelo b´ yt moˇzn´e zvolit jeden ze z´akladn´ıch datov´ ych typ˚ u (alespoˇ n ˇc´ıslo a ˇretˇezec) ˇci pˇr´ıpadnˇe i typ reference. Podpora speci´aln´ıch datov´ ych typ˚ u (URL, datum a ˇcas apod.) jako u pure::variants se nezd´a b´ yt pˇr´ıliˇs z´asadn´ı, nebot’ se daj´ı vˇzdy zastoupit datov´ ym typem ˇretˇezec.
46
Poˇzadavky na vytv´ aˇren´y n´ astroj
Poˇzadavky na editaci modelu vlastnost´ı
• Dodateˇcn´e informace - Podobnˇe jako u pure::variants, i v´ ysledn´ y editor by mˇel umoˇzn ˇovat pˇriˇradit vlastnostem nejen jm´eno, ale i nˇekter´e dalˇs´ı vhodn´e informace (napˇr´ıklad popis, verzi apod.). • Dekompozice - Vytv´ aˇren´ y model by mˇelo b´ yt moˇzn´e dekomponovat do nˇekolika menˇs´ıch celk˚ u, uloˇzen´ ych napˇr´ıklad v samostatn´ ych souborech. T´ım se zv´ yˇs´ı celkov´ a pˇrehlednost editace rozs´ ahl´ ych model˚ u vlastnost´ı. • Datov´y form´ at - Model by mˇel b´ yt uloˇzen v datov´em form´atu, kter´ y je lidsky i strojovˇe ˇciteln´ y (napˇr. XML) a je ho moˇzn´e tedy zpracovat i extern´ımi n´astroji. Pˇr´ıpadnˇe by n´ astroj mohl podporovat i export do jin´ ych datov´ ych form´at˚ u. • Rozˇsiˇritelnost - Tuto moˇznost podporovalo jen nˇekolik m´alo n´astroj˚ u (FMP), tedy nezd´ a se b´ yt jako pˇr´ıliˇs z´ asadn´ı. Nav´ıc by pravdˇepodobnˇe zkomplikovala v´ yslednou 1 implementaci .
4.3
Poˇ zadavky na editaci modelu vlastnost´ı
• Struktura - Z´ asadn´ım rozhodnut´ım zde je, zda pro editaci modelu poˇzadovat stromov´ y editor ˇci grafick´ y editor diagram˚ u. Aˇckoliv m˚ uˇze b´ yt stromov´ y editor pˇri rozs´ ahl´em modelu vlastnost´ı pˇrehlednˇejˇs´ı, bylo by vhodn´e pouˇz´ıt sp´ıˇse editor grafick´ y, a to ze dvou d˚ uvod˚ u: ´ 1. Uprava modelu pˇres stromov´ y editor prob´ıhala ve vˇetˇsinˇe n´astroj˚ u hlavnˇe pˇres kontextov´e menu, kter´e nebylo vˇzdy zcela u ´plnˇe pohodln´e pouˇz´ıvat. Prov´adˇen´ı nˇekter´ ych operac´ı (typicky tˇech co mˇen´ı strukturu stromu) je v grafick´em diagramu jednoduˇs´ı a pˇrehlednˇejˇs´ı. 2. Uˇzivatel bude pravdˇepodobnˇe jiˇz sezn´amen s nˇejako grafickou notac´ı diagramu vlastnost´ı a bude pro nˇej tedy srozumitelnˇejˇs´ı i jednoduˇsˇs´ı pˇr´ımo s takov´ ym diagram pracovat. • Grafick´ a notace - Editor diagramu by mˇel pouˇz´ıvat nˇejakou zn´amou notaci, napˇr´ıklad tu kterou jsme si uk´ azali v tabulce 2.4. • Ovl´ ad´ an´ı - Editor by mˇel v rozumn´e m´ıˇre nab´ızet vˇsechny dostupn´e prvky pro editaci, jako je paleta n´ astroj˚ u, n´ astrojov´a liˇsta, kontextov´e menu, kl´avesov´e zkratky, drag and drop apod. C´ılem je zde hlavnˇe usnadnit pr´aci uˇzivateli. • Funkcionalita - Editor by mˇel podporovat kompletn´ı editaci modelu, tedy tvorbu/´ upravu/maz´ an´ı vlastnost´ı, skupin a atribut˚ u. Pro vˇsechny operace by mˇela b´ yt k dispozici moˇznost je vr´ atit ˇci znovu vyvolat (undo/redo). • Pozicov´ an´ı prvk˚ u - Editor by mˇel uˇzivateli umoˇznit jak manu´aln´ı, tak automatick´e pozicov´ an´ı prvk˚ u dle nˇejak´eho rozvrˇzen´ı. • Validace - Editor by mˇel validovat veˇsker´e vstupy a upozorˇ novat uˇzivatele na chyby. Pˇr´ıpadn´e chyby by mˇely b´ yt v editoru viditelnˇe vyznaˇceny, aby si jich uˇzivatel vˇsiml. 1
Meta-model by mˇel b´ yt navrˇzen tak, aby jeho pˇr´ıpadn´e rozˇsiˇrov´ an´ı nebylo nezbytnˇe nutn´e.
47
Poˇzadavky na vytv´ aˇren´y n´ astroj
Poˇzadavky na editaci omezen´ı
• Export diagramu - Diagram by mˇelo b´ yt moˇzn´e exportovat jako bitmapov´ y, pˇr´ıpadnˇe i jako vektorov´ y obr´ azek.
4.4
Poˇ zadavky na editaci omezen´ı
• Zp˚ usob definice omezen´ı - Omezen´ı by mˇela b´ yt zad´av´ana v textov´e podobˇe pomoc´ı nˇejak´eho jazyka omezen´ı, tak jako tomu je ve vˇetˇsinˇe existuj´ıc´ıch n´astroj˚ u. Grafick´e vyj´ adˇren´ı omezen´ı v diagramu nen´ı nutn´e. • Jazyk omezen´ı - N´ astroj by mˇel podporovat jiˇz nˇejak´ y existuj´ıc´ı jazyk omezen´ı (napˇr. XPath, OCL, ˇci pvSCL), nebo by mˇel m´ıt jazyk vlastn´ı, ovˇsem dostateˇcnˇe expresivn´ı (napˇr´ıklad na u ´rovni zm´ınˇen´eho pvSCL). • Editor - Editor omezen´ı by mˇel b´ yt vhodnˇe integrov´an do hlavn´ıho editoru diagramu vlastnost´ı. D´ ale by mˇel editor zv´ yrazˇ novat syntaxi zvolen´eho jazyka a pˇr´ıpadnˇe i napov´ıdat uˇzivateli pˇri editaci ˇci automaticky doplˇ novat vhodn´e moˇznosti (intelli-sense).
4.5
Poˇ zadavky na editaci konfigurace vlastnost´ı
• Struktura - Aˇckoliv vˇetˇsina n´astroj˚ u pouˇz´ıvala ke konfiguraci obvykle stromov´ y editor se zatrh´ av´ an´ım voleb, bylo by vhodn´e pouˇz´ıt pˇr´ıstup n´astroje XFeature. Uˇzivatel pˇri nˇem vytv´ aˇrel podobn´ y grafick´ y diagram jako u modelu vlastnost´ı, avˇsak byl omezen pouze na nˇekter´e validn´ı moˇznosti (dle pˇr´ısluˇsn´eho modelu vlastnost´ı). Tento pˇr´ıstup m´ a nˇekolik v´ yhod: 1. Uˇzivatel vid´ı obdobn´ y digram pomoc´ı kter´eho pˇred t´ım popsal model vlastnost´ı. 2. Uˇzivatel na zaˇc´ atku nevid´ı vˇsechny moˇznosti jako u stromov´eho editoru, ale zobrazen´ y diagram se postupnˇe rozv´ıj´ı (roste), jak uˇzivatel vyb´ır´a nˇekter´e moˇznosti. • Funkcionalita - Editor by mˇel umoˇznit pˇrid´av´an´ı a ub´ır´an´ı vlastnost´ı v konfiguraci a jejich pˇr´ıpadnou duplikaci (pokud to horn´ı mez kardinality dovol´ı). D´ale by mˇelo b´ yt moˇzn´e nastavovat hodnotu atribut˚ u vybran´ ych vlastnost´ı. • Ovl´ ad´ an´ı - viz stejn´ y poˇzadavek v ˇc´asti 4.3. • Validace - Editor by mˇel automaticky validovat aktu´aln´ı stav konfigurace a viditelnˇe upozorˇ novat uˇzivatele na chybn´a m´ısta. • Asistence uˇzivateli - Editor by mˇel automaticky skr´ yvat neplatn´e volby, a naopak aktivovat volby, kter´e jsou povinn´e. D´ale by editor mohl podporovat automatick´e ˇreˇsen´ı konflikt˚ u konfigurace ˇci zobrazen´ı poˇctu zb´ yvaj´ıc´ıch validn´ıch konfigurac´ı. • Synchronizace s modelem vlastnost´ı - Hlavn´ı pot´ıˇz´ı pˇri tvorbˇe konfigurace je jej´ı propojen´ı s modelem vlastnost´ı od kter´eho byla odvozena. Protoˇze pˇredpokl´ad´ame, ˇze model i konfigurace vlastnost´ı budou uloˇzeny v samostatn´ ych souborech, klademe na n´ astroj n´ asleduj´ıc´ı poˇzadavky: 48
Poˇzadavky na vytv´ aˇren´y n´ astroj
Ostatn´ı poˇzadavky
1. Konfigurace vlastnost´ı mus´ı b´ yt zobraziteln´a/editovateln´a i v pˇr´ıpadˇe nepˇr´ıtomnosti p˚ uvodn´ıho modelu vlastnost´ı. Uˇzivatel by mˇel b´ yt v takov´em pˇr´ıpadˇe na jeho nepˇr´ıtomnost upozornˇen a mˇel by m´ıt moˇznost ho znovu zvolit. 2. Editor by mˇel detekovat zmˇenu p˚ uvodn´ıho modelu vlastnost´ı a mˇel by uˇzivateli nab´ıdnout moˇznost tyto zmˇeny do jiˇz vytvoˇren´e konfigurace zahrnout2 . Pˇr´ıpadn´e zmˇeny v modelu vlastnost´ı by mˇely b´ yt uˇzivateli nˇejak vizu´alnˇe prezentov´ any.
4.6
Ostatn´ı poˇ zadavky
• Integrace s ostatn´ımi n´ astroji - Editor by mˇel umoˇzn ˇovat import ˇci export datov´ ych form´ at˚ u model˚ u vlastnost´ı jin´ ych n´astroj˚ u, zejm´ena pak tˇech nejzn´amˇejˇs´ıch (pure::variants). Zde se jako z´asadn´ı jev´ı hlavnˇe moˇznost importu, umoˇzn ˇuj´ıc´ı pˇrechod uˇzivatel˚ u ostatn´ıch n´ astroj˚ u. ˇ ym probl´emem pro uˇzivatel˚ • Vizu´ aln´ı n´ apovˇeda - Cast´ u b´ yv´a ˇspatn´a orientace v rozs´ ahl´ ych diagramech vlastnost´ı. N´astroj by mˇel proto uˇzivateli poskytnou alternativn´ı pohledy na editovan´ y model, kter´e by mu umoˇznily l´epe se zorientovat: 1. Uˇzivatel by mˇel m´ıt k dispozici zmenˇsen´ y n´ahled na cel´ y diagram pro rychlou orientaci. 2. Uˇzivatel by mˇel m´ıt moˇznost si diagram zobrazit jako klasick´ y strom s moˇznost´ı zabalov´ an´ı a rozbalov´ an´ı jeho podˇc´ast´ı. 3. Uˇzivatel by mˇel m´ıt moˇznost nechat si pˇrehlednˇe zobrazit, kter´e vlastnosti jsou ovlivnˇeny kter´ ymi omezen´ımi a naopak. Toto ˇcasto b´ yv´a pro uˇzivatele z´asadn´ı probl´em, nebot’ jedno omezen´ı m˚ uˇze ovlivˇ novat i nˇekolik vlastnost´ı, jeˇz jsou um´ıstˇeny na opaˇcn´ ych konc´ıch diagramu.
2
Pˇr´ıpadnˇe by mohl editor umoˇzn ˇovat i nˇejak´ y syst´em verzov´ an´ı model˚ u vlastnost´ı, kde by si uˇzivatel mohl vybrat jakou verzi modelu vlastnost´ı pouˇzije. Toto je d˚ uleˇzit´e zejm´ena proto, ˇze model vlastnost´ı se postupnˇe vyv´ıj´ı v ˇcase, tak jak se vyv´ıj´ı i dan´ a rodina produkt˚ u.
49
5 Pouˇzit´e technologie V t´eto kapitole budou pops´ any z´akladn´ı technologie, jeˇz byly pouˇzity pro implementaci v´ ysledn´eho n´ astroje. Konec t´eto kapitoly pak obsahuje kr´atk´e zd˚ uvodnˇen´ı v´ ybˇeru tˇechto technologi´ı.
5.1
Eclipse
Eclipse1 bychom mohli jednoduˇse popsat jako multiplatformn´ı integrovan´e v´ yvojov´e prostˇred´ı (IDE), napsan´e (z vˇetˇs´ı ˇca´sti) v programovac´ım jazyce Java. Pokud bychom chtˇeli b´ yt pˇresnˇejˇs´ı, popsali bychom Eclipse sp´ıˇse jako otevˇrenou v´ yvojovou platformu skl´adaj´ıc´ı se ze z´ akladn´ıho j´ adra a souboru z´asuvn´ ych modul˚ u, implementuj´ıc´ıch vˇetˇsinu jej´ı funkcionality. Zm´ınˇen´e z´ asuvn´e moduly pˇredstavuj´ı zˇrejmˇe nejvˇetˇs´ı v´ yhodu cel´e platformy, nebot’ lze pomoc´ı nich Eclipse libovolnˇe rozˇsiˇrovat a stavˇet na nˇem zcela nov´e n´astroje. Dostupnost mnoha existuj´ıc´ı modul˚ u s potˇrebnou funkcionalitou pak nav´ıc velmi urychluje v´ yvoj. Pomˇernˇe trefnˇe Eclipse popisuj´ı jeho samotn´ı v´ yvoj´aˇri jako IDE for everything and nothing in particular. Eclipse Platform Workbench
New Tool Team
JFace New Tool
SWT Help Workspace
New Tool
Eclipse Runtime
Obr´ azek 5.1: Architektura platformy Eclipse (verze 3). Pod´ıvejme se nyn´ı bl´ıˇze na samotnou architekturu t´eto platformy, jeˇz je zn´azornˇena na obr´azku 5.12 . Z´ akladem cel´e platformy je bˇehov´e prostˇred´ı (platform runtime), kter´e umoˇzn ˇuje naˇc´ıtat a vykon´ avat k´ od jednotliv´ ych z´asuvn´ ych modul˚ u (plug-ins). Toto bˇehov´e prostˇred´ı je postaven´e na specifikaci frameworku OSGi3 (verze 4), konkr´etnˇe jej´ı implementaci Equinox4 . Samotn´e bˇehov´e prostˇred´ı Eclipse je napsan´e v jazyce Java a vyˇzaduje 1
http://www.eclipse.org/ Obr´ azek i ˇca ´sti textu byly pˇrevzaty z [Bea06]. 3 Modul´ arn´ı syst´em pro jazyk Java, kter´ y implementuje dynamick´ y komponentov´ y model. 4 http://www.eclipse.org/equinox/ 2
50
Pouˇzit´e technologie
Eclipse
tedy pro svoj´ı funkˇcnost i bˇehov´e prostˇred´ı tohoto jazyka. Kaˇzd´ y z´ asuvn´ y modul5 je realizov´an jako JAR obsahuj´ıc´ı pˇreloˇzen´e tˇr´ıdy, zdroje (napˇr. ikony aplikace) a textov´ y soubor MANIFEST.MF s metadaty z´asuvn´eho modulu. Jako typick´ a metadata bychom mohli napˇr´ıklad uv´est oznaˇcen´ı modulu, jeho jm´eno a verzi, jak´e ostatn´ı moduly jsou pro jeho bˇeh potˇreba, nebo jak´e baliˇcky dan´ y modul importuje ˇci exportuje. Platforma Eclipse oproti OSGi pˇrid´av´a nav´ıc i soubor plugin.xml, definuj´ıc´ı tzv.: • extension points - M´ısta na kter´ ych lze rozˇs´ıˇrit funkcionalitu st´avaj´ıc´ıho z´asuvn´eho modulu. • extensions - Implementace zm´ınˇen´ ych rozˇs´ıˇren´ı. Typick´ ym pˇr´ıkladem takov´eho m´ısta rozˇs´ıˇren´ı je napˇr´ıklad hlavn´ı menu aplikace, do kter´eho mohou ostatn´ı moduly skrze sv´e rozˇs´ıˇren´ı pˇrisp´ıvat (pˇrid´avat nov´e poloˇzky). Vrat’me se ale zpˇet k obr´ azku 5.1. Pro tvorbu uˇzivatelsk´eho rozhran´ı jsou jednotliv´ ym modul˚ um k dispozici dvˇe knihovny: • SWT - N´ızko´ urovˇ nov´ a knihovna pro tvorbu grafick´eho uˇzivatelsk´eho rozhran´ı. Podobnˇe, jako napˇr´ıklad SWING, nab´ız´ı i tato knihovna multiplatformn´ı API pro tvorbu z´ akladn´ıch prvk˚ u uˇzivatelsk´eho rozhran´ı (tlaˇc´ıtka, menu atd.), avˇsak na rozd´ıl od SWING vyuˇz´ıv´ a SWT pro tyto prvky nativn´ı prostˇredky dan´eho operaˇcn´ıho syst´emu6 . • JFace - Pokroˇcilejˇs´ı nadstavba nad pˇredchoz´ı knihovnou, jej´ıˇz implementace jiˇz nen´ı (jako u SWT) syst´emovˇe z´ avisl´a. Na rozd´ıl od SWT umoˇzn ˇuje JFace pr´aci s prvky uˇzivatelsk´eho rozhran´ı s vyuˇzit´ım n´avrhov´eho vzoru MVC a pˇrid´av´a tak´e napˇr´ıklad mechanismus pro tvorbu akc´ı nebo pokroˇcil´ ych dialogov´ ych oken (napˇr. pr˚ uvodc˚ u). Na tˇechto dvou knihovn´ ach je pak postaven tzv. workbench, pˇredstavuj´ıc´ı v´ ychoz´ı bod pro tvorbu uˇzivatelsk´eho rozhran´ı v prostˇred´ı Eclipse. Samotn´ y uˇzivatel vn´ım´a workbench v podobˇe okna (obr. 5.3), skl´ adaj´ıc´ıho se z menu, n´astrojov´e a stavov´e liˇsty a str´anky (workbench page). Pro pˇrehlednost si popiˇsme jednotliv´e ˇc´asti struktury workbench, zn´azornˇen´e tak´e na obr. 5.2 (pˇrevzat´em z [Mca10]). • Workbench page - Str´ anka sdruˇzuj´ıc´ı editor a nˇekolik pohled˚ u. • Editor - Editor umoˇznuj´ıc´ı otev´ır´an´ı, modifikaci a ukl´ad´an´ı objekt˚ u. Jde typicky napˇr´ıklad textov´ y, formul´ aˇrov´ y ˇci grafick´ y editor. • View - Pohled zobrazuj´ıc´ı informace o objektech dostupn´ ych v dan´em pracovn´ım prostoru uˇzivatele. Pohled m˚ uˇze typicky slouˇzit napˇr´ıklad k zobrazen´ı seznamu chyb, seznamu souˇc´ ast´ı projektu ˇci k alternativn´ımu zobrazen´ı editovan´eho objektu. Pohled m˚ uˇze m´ıt vlastn´ı menu i n´ astrojovou liˇstu. • Perspective - Rozvrˇzen´ı editoru a nˇekolika pohled˚ u v r´amci str´anky. Jedna str´anka m˚ uˇze m´ıt i nˇekolik perspektiv, mezi kter´ ymi si uˇzivatel pˇrep´ın´a. 51
Pouˇzit´e technologie
Eclipse Modeling Framework
Workbench
Top-level menu
Workbench page
Perspective(s)
Top-level toolbar Status line Editors
Views
Perspective switcher
View toolbar
Drop-down menu
Obr´ azek 5.2: Struktura uˇzivatelsk´eho rozhran´ı Eclipse workbench (logick´ y pohled). Pomoc´ı rozˇsiˇrov´ an´ı workbench mohou ostatn´ı z´asuvn´e moduly tyto prvky do Eclipse pˇrid´avat. T´ımto zp˚ usobem bylo napˇr´ıklad vytvoˇreno JDT7 , jeˇz (velmi zjednoduˇsenˇe ˇreˇceno) pˇrid´av´ a do Eclipse vlastn´ı editor pro jazyka Java a nˇekolik nov´ ych pohled˚ u a perspektiv. Posledn´ımi komponentami cel´e architektury, kter´e jsme jeˇstˇe nepopsali, jsou pak: • Workspace - Pracovn´ı prostor uˇzivatele, obsahuj´ıc´ı vytvoˇren´e projekty, jejich souˇc´asti a nastaven´ı. • Team - Rozhran´ı pro integraci platformy s r˚ uzn´ ymi verzovac´ımi syst´emy. • Help - Rozˇsiˇriteln´ y syst´em n´apovˇedy cel´e platformy. Samotn´ a platforma Eclipse m˚ uˇze b´ yt pouˇzita dvˇema zp˚ usoby, a to bud’ jako integrovan´e v´ yvojov´e prostˇred´ı (IDE), rozˇsiˇriteln´e pomoc´ı z´asuvn´ ych modul˚ u, nebo jako tzv. Rich Client Platform (RPC), pˇredstavuj´ıc´ı bˇehov´e prostˇred´ı spolu s minim´aln´ı mnoˇzinu modul˚ u, jeˇz lze pouˇz´ıt k tvorbˇe samostatn´ ych aplikac´ı. Na z´ avˇer jeˇstˇe dodejme, ˇze v´ yˇse popsan´a architektura odpov´ıdala platformˇe Eclipse verze 3. V souˇcasn´e dobˇe prob´ıh´ a n´astup jej´ı 4. verze (oznaˇcovan´e jako e4), kter´a pˇrin´aˇs´ı nˇekolik z´ asadn´ıch zmˇen, jako napˇr´ıklad deklarativn´ı popis GUI pomoc´ı modelu, servisnˇe orientovan´ y programov´ y model postaven´ y na OSGi ˇci integraci webov´ ych technologi´ı (CSS, JavaScript) jako v´ yvojov´ ych prostˇredk˚ u pro celou platformu. e4 nav´ıc obsahuje speci´aln´ı vrstvu pro zajiˇstˇen´ı zpˇetn´e kompatibility s API verze 3.
5.2
Eclipse Modeling Framework
Eclipse Modeling Framework8 (zkr´acenˇe EMF) bychom mohli struˇcnˇe popsat jako framework pro strukturovan´e modelov´an´ı se schopnost´ı generov´an´ı zdrojov´eho k´od˚ u. Pro 5
V terminologii OSGi oznaˇcovan´ y sp´ıˇse jako bundle. Napˇr´ıklad WinAPI na syst´emu Windows ˇci knihovnu GTK+ na syst´emu Linux. 7 Bal´ık n´ astroj˚ u pro pro platformu Eclipse pro v´ yvoj aplikac´ı v jazyce Java. 8 http://www.eclipse.org/modeling/emf/ 6
52
Pouˇzit´e technologie
Workbench window
Views
Eclipse Modeling Framework
Top-level toolbar
Status line
Top-level menu
Workbench page
Perspective switcher
Editor
Obr´ azek 5.3: Struktura uˇzivatelsk´eho rozhran´ı Eclipse workbench (okno aplikace). neznal´eho ˇcten´ aˇre bude pravdˇepodobnˇe obt´ıˇzn´e si pod touto definic´ı pˇredstavit nˇeco konkr´etn´ıho, a proto vysvˇetl´ıme principy EMF na jednoduch´em pˇr´ıkladu, jeˇz je pˇrevzat´ y z knihy [Stein08]. Pˇredstavme si, ˇze jako v´ yvoj´ aˇr aplikace potˇrebujeme vytvoˇrit jednoduch´ y dom´enov´ y model (kupˇr´ıkladu pro syst´em objedn´ avek z´akazn´ık˚ u). Pravdˇepodobnˇe bychom mohli zaˇc´ıt t´ım, ˇze si model nejprve navrhneme v podobˇe UML diagramu a na z´akladˇe toho pak vytvoˇr´ıme i zdrojov´ y k´ od jednotliv´ ych tˇr´ıd a rozhran´ı. Vzhledem k tomu, ˇze je objedn´avky nutn´e uchov´avat po delˇs´ı dobu, bude nutn´e napsat i k´od, kter´ y dan´ y model uloˇz´ı a naˇcte ze souboru, typicky ve form´ atu postaven´em na XML. Aby bylo moˇzn´e takto serializovan´ y model validovat, bude nav´ıc potˇreba vytvoˇrit i pˇr´ısluˇsn´e XML sch´ema (XSD). Jak m˚ uˇzeme vidˇet, byli jsme nuceni vytvoˇrit hned nˇekolik artefakt˚ u (UML diagram tˇr´ıd, zdrojov´ y k´ od tˇr´ıd, XML sch´ema), aˇckoliv kaˇzd´ y z nich vyjadˇroval tu samou informaci (popis struktury naˇseho modelu). Tuto informaci obecnˇe oznaˇcujeme jako meta-model. Pro ujasnˇen´ı terminologie zde definujme pojem meta-model jako struktur´aln´ı popis modelu. Model pak m˚ uˇzeme ch´ apat jako instanci meta-modelu. Konkr´etn´ım pˇr´ıkladem meta-modelu a jeho instance je napˇr´ıklad dvojice tˇr´ıda, objekt nebo dvojice XML sch´ema, XML dokument. Vrat’me se ale zpˇet k naˇsemu pˇr´ıkladu, kde jsme ten sam´ y meta-model (ponˇekud zby-
53
Pouˇzit´e technologie
Eclipse Modeling Framework
UML model Zdrojový kód jazyka Java
XML schéma Ecore model
Anotace
RDB schéma
další...
Obr´ azek 5.4: Moˇznosti konverze Ecore modelu v r´amci EMF. teˇcnˇe) vyj´ adˇrili nˇekolikr´ at, pokaˇzd´e v jin´e formˇe (UML diagram tˇr´ıd, zdrojov´ y k´od tˇr´ıd, XML sch´ema). Pokud bychom m´ısto toho na zaˇc´atku pouˇzili EMF, mohli jsme si vˇetˇsinu t´eto pr´ ace uˇsetˇrit, nebot’ pr´ avˇe jedna z hlavn´ıch v´ yhod EMF je, ˇze n´am umoˇzn ˇuje metamodel definovat v univerz´ aln´ı formˇe a zn´ı pak tyto ostatn´ı formy meta-modelu jednoduˇse vygenerovat (viz obr. 5.4). Tato univerz´aln´ı forma je v r´amci EMF naz´ yv´ana jako Ecore model9 . Ilustraci toho, jak vypad´a struktura Ecore modelu, m˚ uˇzeme vidˇet na obr´azku 5.5 (upozorˇ nujeme ˇcten´ aˇre, ˇze jde pouze o velmi zjednoduˇsen´ y pohled)10 . Oba uveden´e obr´azky byly pˇrevzaty z [Stein08]. eSuperTypes 0..*
Obr´ azek 5.5: Zjednoduˇsen´e zn´azornˇen´ı struktury Ecore modelu. V´ yhodn´e je na cel´em tomto ˇreˇsen´ı zejm´ena to, ˇze v´ yvoj´aˇr nemus´ı Ecore model vytv´aˇret pˇr´ımo, ale m˚ uˇze ho vygenerovat z libovoln´eho uveden´eho artefaktu (zdrojov´ y k´od, UML model, XML sch´ema atd.), tedy mezi Ecore a ostatn´ımi vyj´adˇren´ımi meta-modelu existuje vz´ajemnˇe jednoznaˇcn´ a konverze11 . Pokud chtˇel v´ yvoj´aˇr vytvoˇrit Ecore model pˇr´ımo, m˚ uˇze 9
Vˇetˇsinou se sp´ıˇse pouˇz´ıv´ a obecnˇejˇs´ı oznaˇcen´ı EMF model. Pro zaj´ımavost uved’me, ˇze struktura Ecore modelu je v EMF vyj´ adˇrena jeho meta-modelem, kter´ ym nen´ı nic jin´eho neˇz opˇet Ecore model. Tedy, Ecore je sv´ ym vlastn´ım meta-modelem. 11 Aby mohl EMF ze zdrojov´eho k´ odu z´ıskat dostateˇcn´e informace o meta-modelu, mus´ı b´ yt tato infor10
54
Pouˇzit´e technologie
Graphical Editing Framework
to udˇelat bud’ programovˇe (pomoc´ı API frameworku EMF) nebo v grafick´em editoru, jeˇz je souˇc´ ast´ı EMF. Samotn´ y Ecore model je ve vnˇejˇs´ı pamˇeti uchov´av´an jako XMI dokument, kter´ y je pˇri naˇcten´ı do vnitˇrn´ı pamˇeti pˇreveden do objektov´e podoby. K t´eto podobˇe je pak n´ aslednˇe pˇristupov´ ano bud’ prostˇrednictv´ım vygenerovan´ ych rozhran´ı nebo skrze reflexivn´ı API. Velkou v´ yhodou zm´ınˇen´eho API je, ˇze dovoluje pˇristupovat identicky k libovoln´e instanci Ecore modelu a umoˇzn ˇuje tak tvorbu generick´ ych, znovupouˇziteln´ ych komponent. Pˇr´ıkladem takov´e komponenty je napˇr´ıklad dostupn´a generick´a implementace naˇc´ıt´an´ı a ukl´ad´an´ı libovoln´e instance Ecore modelu v podobˇe XMI dokumentu ˇci generick´a implementace n´ avrhov´eho vzoru observer, vyuˇz´ıvan´a v r´amci cel´eho EMF. EMF d´ıky v´ yˇse popsan´ ym vlastnostem pˇredstavuje velmi mocn´ y n´astroj pro tzv. modeldriven architecture. Tento pojem oznaˇcuje zp˚ usob v´ yvoje software, kdy jsou jednotliv´e ˇc´asti architektury aplikace nejprve pops´any pomoc´ı platformˇe nez´avisl´eho modelu a z nˇej je pak (automaticky) vygenerov´ an zdrojov´ y k´od aplikace. T´ımto zp˚ usobem je napˇr´ıklad moˇzn´e vygenerovat z Ecore kompletn´ı zdrojov´ y k´od (stromov´eho) editoru pro j´ım popsan´ y model. Na z´ avˇer jeˇstˇe dodejme nˇekolik fakt˚ u, jako napˇr´ıklad, ˇze framework EMF se stal od verze e4 ned´ılnou souˇc´ ast´ı j´ adra v´ yvojov´eho prostˇred´ı Eclipse. Mimo samotn´e EMF jeˇstˇe existuje jeho nˇekolik rozˇsiˇruj´ıc´ıch projekt˚ u, umoˇzn ˇuj´ıc´ıch napˇr´ıklad porovn´an´ı, sledov´an´ı zmˇen, transakˇcn´ı zpracov´ an´ı, dotazov´an´ı ˇci validaci EMF model˚ u. Vˇsechny tyto projekty jsou pak vˇcetnˇe EMF (oznaˇcovan´ ym jako EMF core) souˇc´ast´ı tzv. Eclipse Modeling Project12 .
5.3
Graphical Editing Framework
Graphical Editing Framework (GEF)13 je projekt, jehoˇz c´ılem je zprostˇredkovat technologie pro tvorbu interaktivn´ıch grafick´ ych editor˚ u a pohled˚ u pro platformu Eclipse. Samotn´ y projekt GEF se skl´ ad´ a ze tˇr´ı ˇc´ ast´ı (viz obr. 5.6), jeˇz nyn´ı samostatnˇe pop´ıˇseme. Uveden´ y obr´azek byl pˇrevzat z [Rub11].
Eclipse GEF Project Zest
GEF Draw2d
Obr´ azek 5.6: Struktura projektu GEF. mace v k´ odu vyj´ adˇrena pomoc´ı anotac´ı. Obdobnˇe jsou nˇekter´e tyto informace vyj´ adˇreny v definici XML sch´ema pomoc´ı speci´ aln´ıch atribut˚ u. 12 http://www.eclipse.org/modeling/ 13 http://www.eclipse.org/gef/
55
Pouˇzit´e technologie
5.3.1
Graphical Editing Framework
Draw2d
Draw2d pˇredstavuje element´ arn´ı ˇc´ast projektu GEF. Jeho prim´arn´ım u ´kolem je vykreslov´an´ı a um´ıst’ov´ an´ı veˇsker´ ych (dvourozmˇern´ ych) grafick´ ych prvk˚ u v r´amci kreslic´ı plochy a zajiˇstˇen´ı element´ arn´ı interakce s uˇzivatelem. Z´akladn´ım principem Draw2d je, ˇze m´ısto toho aby program´ator psal n´ızko´ urovˇ nov´ y k´od pro vykreslen´ı cel´eho diagramu, pouˇz´ıv´a jiˇz hotov´e grafick´e obrazce (tzv. figures), ze kter´ ych postupnˇe cel´ y diagram skl´ad´a. K dispozici jsou z´akladn´ı obrazce (napˇr. ˇctverec, elipsa, textov´ y popisek), jejichˇz parametry (barva, okraj, rozmˇery atd.) lze konfigurovat. Program´ ator m˚ uˇze nicm´enˇe vytv´aˇret i obrazce vlastn´ı, napˇr´ıklad kompozic´ı z tˇech jiˇz existuj´ıc´ıch. Veˇsker´e obrazce jsou v r´amci kresl´ıc´ı plochy organizov´any do hierarchick´e struktury, coˇz umoˇzn ˇuje optimalizovat vˇetˇsinu prov´adˇen´ ych operac´ı (napˇr. pˇri zmˇenˇe stavu obrazce je pˇrekreslen pouze on a jeho potomci). Jednotliv´e obrazce lze nav´ıc propojovat pomoc´ı viditeln´ ych spojen´ı (connections). Pokroˇcilejˇs´ı schopnost´ı Draw2d je pak rozm´ıst’ov´an´ı obrazc˚ u po kresl´ıc´ı ploˇse dle zvolen´ ych algoritm˚ u rozvrˇzen´ı (layouts) ˇci urˇcen´ı, jak´ ym zp˚ usobem povede spojen´ı mezi jednotliv´ ymi obrazci (connection routers). Draw2d nav´ıc umoˇzn ˇuje zpracov´avat i uˇzivatelsk´e vstupy (myˇs a kl´ avesnice) proveden´e nad jednotliv´ ymi obrazci a spojen´ımi.
5.3.2
GEF
GEF je MVC framework14 urˇcen´ y pro tvorbu interaktivn´ıch grafick´ ych editor˚ u v prostˇred´ı Eclipse. Hlavn´ı v´ yhodou cel´eho framworku je jeho velmi dobˇre navrˇzen´a architektura a zejm´ena to, ˇze neklade ˇz´ adn´e poˇzadavky na editovan´ y model, ˇci jak m´a b´ yt tento model prezentov´ an uˇzivateli. Zm´ınˇen´ a architektura je z vˇetˇs´ı ˇc´asti zaloˇzena na pouˇz´ıv´an´ı nejr˚ uznˇejˇs´ıch n´avrhov´ ych vzor˚ u, zejm´ena pak vzoru model-view-controller, jeˇz je pouˇzit pro interakci mezi uˇzivatelem, editovan´ ym modelem a zobrazen´ ym diagramem. To, jak tato interakce prob´ıh´ a, m˚ uˇzeme vidˇet obr´ azku 5.7. Z´ akladem fungov´an´ı kaˇzd´eho editoru postaven´em na GEF jsou tˇri komponenty, odpov´ıdaj´ıc´ı dan´ ym ˇc´astem vzoru MVC: • Model - Jeden ˇci v´ıce objekt˚ u editovan´ ych uˇzivatelem. GEF neklade na strukturu modelu ˇz´ adn´e poˇzadavky, m˚ uˇze j´ıt klidnˇe o prost´e objekty jazyka Java ˇci EMF model. • View - Je realizov´ an pomoc´ı jiˇz zm´ınˇen´eho Draw2d v podobˇe jeho obrazc˚ u (figures). Kaˇzd´ y obrazec zobrazuje odpov´ıdaj´ıc´ı ˇc´asti modelu uˇzivateli. ´ • Controller - Je realizov´ an pomoc´ı tzv. editparts z frameworku GEF. Ukolem tˇechto objekt˚ u je synchronizace mezi ˇc´astmi modelu a jejich protˇejˇsky v podobˇe obrazc˚ ua u ´prava modelu dle vstup˚ u uˇzivatele. Pro kaˇzd´ y prvek modelu existuje odpov´ıdaj´ıc´ı editpart. Popiˇsme si nyn´ı, jak vypad´ a takov´ y obvykl´ y ˇzivotn´ı cyklus editoru postaven´em na GEF. Po otevˇren´ı editoru prozkoum´ a GEF prvky modelu a na z´akladˇe specifikovan´e tov´arn´ı tˇr´ıdy 14 Aˇckoliv je jako GEF naz´ yv´ an cel´ y tento projekt, vˇetˇsinou se pod zkratkou GEF mysl´ı pr´ avˇe tento framework.
56
Pouˇzit´e technologie
Graphical Editing Framework
Model
Uživatel Request
EditPart
Policies
!
GEF Command
Figure
Obr´ azek 5.7: Fungov´an´ı editoru postaven´em na GEF. vytvoˇr´ı instance odpov´ıdaj´ıc´ıch editparts. Kaˇzd´ y editpart pot´e sestroj´ı pro dan´ y prvek modelu jeho vizu´ aln´ı reprezentaci v podobˇe obrazce (figure). Aby mohl editpart detekovat zmˇeny modelu a aktualizovat pak i pˇr´ısluˇsn´ y obrazec, pouˇz´ıv´a se obvykle n´avrhov´ y vzor observer, kdy modifikovan´ y objekt sv´eho pozorovatele (editpart) na tyto zmˇeny s´am upozorˇ nuje. ˇ adn´ Z´ yeditpart nikdy nepracuje s uˇzivatelsk´ ym vstupem pˇr´ımo, ale je od nˇej odst´ınˇen pomoc´ı framworku GEF. Ten zpracov´av´a element´arn´ı uˇzivatelsk´e vstupy (myˇs, kl´avesnice) a konstruuje z nich vysoko´ urovˇ nov´e poˇzadavky (requests), kter´e jsou pak teprve pˇres editparts zpracov´ any. Pˇr´ıkladem jednoho takov´eho poˇzadavku m˚ uˇze b´ yt napˇr´ıklad vytvoˇren´ı objektu, kter´ y uˇzivatel vybral v paletˇe n´astroj˚ u, nebo pˇrid´an´ı spojen´ı mezi dvˇema objekty. Zpracov´ an´ı poˇzadavk˚ u prob´ıh´a na stranˇe editparts pomoc´ı tzv. politik (policies), jichˇz m˚ uˇze m´ıt m´ıt editpart hned nˇekolik, pro kaˇzd´ y typ poˇzadavku jinou. Jednotliv´e politiky mohou b´ yt nav´ıc za bˇehu editoru dynamicky aktivov´any ˇci deaktivov´any a jde tedy vlastnˇe o aplikaci n´ avrhov´eho vzoru strategy. V pˇr´ıpadˇe, ˇze je nalezena politika, jeˇz dok´aˇze dan´ y poˇzadavek zpracovat, zkonstruuje tato politika pˇr´ıkaz (command ) zapouzdˇruj´ıc´ı operaci provedenou na modelem. GEF n´ aslednˇe tento pˇr´ıkaz pˇrijme a vykon´a. Kaˇzd´ y takov´ y pˇr´ıkaz nav´ıc uchov´ av´ a i p˚ uvodn´ı stav mˇenˇen´eho objektu, takˇze je moˇzn´e jednotliv´e zmˇeny vracet ˇci znovu aplikovat (undo/redo operace). Opˇet zde tedy m˚ uˇzeme vidˇet pouˇzit´ı n´avrhov´eho vzoru, tentokr´ ate (stejnojmenn´eho) command.
57
Pouˇzit´e technologie
5.3.3
Xtext
Zest
Zest je knihovna umoˇzn ˇuj´ıc´ı vizualizaci stromov´ ych a grafov´ ych struktur. Podobnˇe jako GEF, i Zest vyuˇz´ıv´ a pro vykreslov´an´ı Draw2d, avˇsak na rozd´ıl od GEF neumoˇzn ˇuje zobrazovan´ y objekt pˇr´ımo editovat. Tato knihovna se d´ a pouˇz´ıt dvˇema zp˚ usoby. Prvn´ı z nich spoˇc´ıv´a v ruˇcn´ım vytvoˇren´ı vˇsech objekt˚ u pˇredstavuj´ıc´ıch dan´ y graf (uzly a hrany) a jejich zobrazen´ı pomoc´ı dan´e komponenty. Tento pˇr´ıstup m´ a nev´ yhodu v tom, ˇze pokud m´ame nˇejak´ y existuj´ıc´ı model, kter´ y chceme zobrazit, mus´ıme informaci mezi n´ım a grafem ruˇcnˇe synchronizovat, tedy nen´ı zde ˇz´ adn´e oddˇelen´ı mezi modelem a jeho prezentac´ı. Druh´ y zp˚ usob je pomˇernˇe flexibilnˇejˇs´ı a obaluje pˇredchoz´ı pˇr´ıstup pouˇzit´ım n´avrhov´eho vzoru MVC, podobnˇe jako tomu bylo mezi knihovnami JFace a SWT. Program´atorovi zde v podstatˇe staˇc´ı implementovat rozhran´ı, jeˇz zprostˇredkov´av´a pˇr´ıstup k dat˚ um modelu a mapuje ho jednotliv´e uzly a hrany. Zbyl´e komponenty knihovny uˇz pak jen z´ıskan´e informace zobraz´ı v podobˇe grafu. Obdobn´ ym zp˚ usobem (implementac´ı zprostˇredkuj´ıc´ıho rozhran´ım) lze napˇr´ıklad ovlivˇ novat jak´ ym zp˚ usobem budou jednotliv´e uzly a hrany vykresleny. Pˇri pouˇzit´ı tohoto pˇr´ıstupu lze tak´e nav´ıc definovat filtry omezuj´ıc´ı viditelnou ˇc´ast grafu, coˇz m˚ uˇze pˇrin´est znaˇcn´e urychlen´ı pˇri vykreslov´an´ı rozs´ahl´ ych struktur. D˚ uleˇzitou ˇc´ ast´ı t´eto knihovny je pak sada r˚ uzn´ ych algoritm˚ u, kter´e m˚ uˇzou b´ yt pouˇzity k rozm´ıstˇen´ı jednotliv´ ych uzl˚ u (napˇr´ıklad do stromu, radi´aln´ıho stromu, mˇr´ıˇzky atd.). Tyto algoritmy mohou b´ yt nav´ıc mezi sebou kombinov´any k dosaˇzen´ı odliˇsn´ ych v´ ysledk˚ u. Pomˇernˇe zaj´ımav´ a je tak´e schopnost t´eto knihovny animovat veˇsker´e struktur´aln´ı zmˇeny grafu, vˇcetnˇe zmˇen pˇri nichˇz doch´az´ı k pˇreskupen´ı vrchol˚ u.
5.4
Xtext
Xtext15 je framework pro v´ yvoj programovac´ıch a dom´enovˇe specifick´ ych jazyk˚ u. Hlavn´ı v´ yhodou tohoto frameworku je, ˇze pokr´ yv´a vˇsechny aspekty tvorby takov´eho jazyka od jeho syntaktick´eho analyz´ atoru aˇz po jeho editor, vˇcetnˇe integrace s platformou Eclipse. Xtext, podobnˇe jako EMF, usnadˇ nuje program´atorovi pr´aci t´ım, ˇze dok´aˇze vˇetˇsinu zdrojov´eho k´ odu implementace automaticky vygenerovat. Program´atorovi staˇc´ı pouze form´alnˇe popsat syntaxi dan´eho jazyka pomoc´ı gramatiky a Xtext z n´ı pak vytvoˇr´ı n´asleduj´ıc´ı komponenty: • Lexik´ aln´ı a syntaktick´y analyz´ ator jazyka. Pro vytvoˇren´ı tˇechto souˇc´ast´ı vyuˇz´ıv´ a Xtext internˇe, jiˇz existuj´ıc´ı, gener´ator ANTLR16 . • EMF model pˇredstavuj´ıc´ı v´ ystup syntaktick´eho analyz´atoru. D´ıky pouˇzit´ı EMF m˚ uˇze program´ ator tˇeˇzit ze vˇsech v´ yhod tohoto frameworku popsan´ ych v podkapitole 5.2. Program´ ator m˚ uˇze nav´ıc vynutit i pouˇzit´ı zcela vlastn´ıho EMF modelu, jeho namapov´ an´ım prvky gramatiky jazyka. 15 16
Zd˚ uvodnˇen´ı v´ybˇeru technologi´ı a alternativy
• Textov´y editor jazyka s podporou zv´ yrazˇ nov´an´ı syntaxe, n´apovˇedou, automatick´ ym doplˇ nov´ an´ım (intelli-sense), skl´ad´an´ım blok˚ u k´odu, moˇznost´ı refaktorizace apod. Veˇsker´e uveden´e komponenty vˇcetnˇe editoru jsou vytvoˇreny v podobˇe z´asuvn´ ych modul˚ u, coˇz umoˇzn ˇuje jejich bezprobl´emovou integraci do Eclipse. Cel´ y proces generov´an´ı je nav´ıc zcela konfigurovateln´ y a v´ ysledn´e komponenty lze pˇrizp˚ usobovat pomoc´ı vkl´ad´an´ı z´avislost´ı (dependency injection). Program´ator d´ıky tomu m˚ uˇze napˇr´ıklad nadefinovat vlastn´ı barevn´e sch´ema pro zv´ yrazˇ nov´ an´ı syntaxe v editoru, ˇci zmˇenit chybov´e zpr´avy syntaktick´eho analyz´ atoru. Pro zm´ınˇen´e vkl´ad´an´ı z´avislost´ı je v r´amci Xtext pouˇz´ıv´an framework Google Guice17 .
5.5
Zd˚ uvodnˇ en´ı v´ ybˇ eru technologi´ı a alternativy
Pouˇzit´ı platformy Eclipse a frameworku EMF bylo specifikov´ano jako z´akladn´ı poˇzadavek jiˇz v zad´ an´ı t´eto pr´ ace. Nicm´enˇe, i pokud by tento poˇzadavek nebyl vznesen, byly by obˇe dvˇe technologie pravdˇepodobnˇe stejnˇe vybr´any, vzhledem k jejich v´ yhod´am popsan´ ym v podkapitol´ ach 5.1 a 5.2. Jako jedinou nev´ yhodu vid´ı autor pouze pomˇernˇe dlouhou dobu nutnou pro porozumˇen´ı a zvl´ adnut´ı tˇechto technologi´ı. Pro tvorbu grafick´ y editor˚ u v prostˇred´ı Eclipse jsou mimo GEF dostupn´e jeˇstˇe dva frameworky, a to GMF a Graphiti. GMF (Graphical Modeling Framework)18 m˚ uˇzeme ch´apat jako framework zprostˇredkov´ avaj´ıc´ı integraci mezi EMF a GEF. Z´akladn´ı vlastnost´ı GMF je, ˇze umoˇzn ˇuje na z´ akladˇe pˇredloˇzen´eho EMF modelu (a nˇekolika dalˇs´ıch) vygenerovat (t´emˇeˇr) kompletn´ı zdrojov´ y k´ od GEF editoru, jeˇz si pak m˚ uˇze program´ator pˇrizp˚ usobovat dle sv´ ych potˇreb. Stejnˇe jako GMF, i Graphiti19 je framework postaven´ y na technologi´ıch EMF a GEF, avˇsak na rozd´ıl od GMF neposkytuje Graphiti ˇz´adn´e moˇznosti generov´an´ı k´odu. M´ısto toho se tento framework zamˇeˇruje sp´ıˇse na poskytnut´ı standardn´ı implementace vˇetˇsiny funkˇcnosti editoru a nab´ız´ı API, jeˇz odstiˇ nuje program´atora od komplexnosti GEF a Draw2d. Editory postaven´e na tomto frameworku pouˇz´ıvaj´ı nav´ıc standardizovan´ y vzhled digram˚ u20 . I pˇres zm´ınˇen´e klady obou framework˚ u byl pro implementaci v´ ysledn´eho n´astroje vybr´an GEF, a to z nˇekolika d˚ uvod˚ u: • Vzhledem k delˇs´ı dobˇe existence GEF oproti GMF a Graphiti je pro nˇej dostupn´e vˇetˇs´ı mnoˇzstv´ı n´ avod˚ u a je tak´e l´epe dokumentov´an21 . • GMF je pomˇernˇe komplexnˇejˇs´ı framework neˇz GEF a jeho zvl´adnut´ı je tedy sloˇzitˇejˇs´ı a ˇcasovˇe n´ aroˇcnˇejˇs´ı. • Aˇckoliv jsou GMF a Graphiti v jist´e m´ıˇre pˇrizp˚ usobiteln´e, realizace nˇekter´ ych specifick´ ych poˇzadavk˚ u, se kter´ ymi nen´ı v tˇechto frameworc´ıch poˇc´ıt´ano, je pomˇernˇe 17
https://code.google.com/p/google-guice/ http://www.eclipse.org/modeling/gmp/ 19 http://www.eclipse.org/graphiti/ 20 Tento vzhled byl navrˇzen specialisty ze spoleˇcnosti SAP AG, odkud tento framework p˚ uvodnˇe poch´ az´ı. 21 Vzhledem k autorovˇe p˚ uvodn´ı neznalosti platformy Eclipse byl toto z´ asadn´ı d˚ uvod pro pouˇzit´ı GEF. 18
59
Pouˇzit´e technologie
Zd˚ uvodnˇen´ı v´ybˇeru technologi´ı a alternativy
problematick´ a, na rozd´ıl od n´ızko´ urovˇ nov´eho GEF. Jedn´ım takov´ ym pˇr´ıkladem je vytv´ aˇren´ y editor konfigurace, popsan´ y v kapitole 6.5, pracuj´ıc´ı rovnou nad dvˇema souvisej´ıc´ımi modely (model vlastnost´ı a konfigurace vlastnost´ı), coˇz je probl´em pˇri pouˇzit´ı GMF, nebot’ ten oˇcek´av´a pouze jedin´ y model. Zm´ınˇen´ y editor konfigurace nav´ıc pouˇz´ıv´ a i pomˇernˇe specifick´ y zp˚ usob editace bez pouˇzit´ı palety n´astroj˚ u. D˚ uvodem v´ ybˇeru posledn´ıho zm´ınˇen´eho frameworku Xtext jsou jeho popsan´e v´ yhody a nedostupnost obdobn´e alternativy pro platformu Eclipse.
60
6 Implementace n´astroje V t´eto kapitole pop´ıˇseme zp˚ usob implementace v´ ysledn´eho n´astroje a jeho jednotliv´ ych souˇc´ast´ı. Samotn´ y n´ astroj byl pr˚ ubˇehu v´ yvoje pracovnˇe oznaˇcov´an jako YAFMT1 (Yet Another Feature Modeling Tool), coˇz bylo nakonec zvoleno i jako jeho ofici´aln´ı n´azev.
6.1
Architektura n´ astroje
N´astroj YAFMT je implementov´an jako sada z´asuvn´ ych modul˚ u pro platformu Eclipse. Tyto moduly jsou nav´ıc organizov´any do ˇctyˇr skupin, tvoˇr´ıc´ıch samostatn´e komponenty2 : Feature Model Editor
- editor modelu vlastnost´ı
Feature Configuraction Editor
- editor konfigurace vlastnost´ı
Feature Model Visualizer
- vizualizace modelu vlastnost´ı
Boolean Constraint Language
- jazyk omezen´ı BoolCL
Prvn´ı tˇri uveden´e komponenty lze nainstalovat a pouˇz´ıvat naprosto samostatnˇe. Posledn´ı komponenta je pak rozˇsiˇruj´ıc´ı a umoˇzn ˇuje v r´amci ostatn´ıch komponent pouˇz´ıvat jazyk omezen´ı BoolCL. Uved’me nyn´ı struˇcn´ y popis jednotliv´ ych z´asuvn´ ych modul˚ u, ze kter´ ych jsou dan´e komponenty sloˇzeny: cz.zcu.yafmt.model
- definice EMF modelu a jeho implementace
cz.zcu.yafmt.model.validation
- valid´atory pro jednotliv´e ˇc´asti modelu
cz.zcu.yafmt.model.edit
- integrace modelu do uˇzivatelsk´eho rozhran´ı
cz.zcu.yafmt.clang
- definice extension point pro pˇrid´av´an´ı jazyk˚ u omezen´ı
cz.zcu.yafmt.clang.bcl
- implementace jazyka omezen´ı BoolCL
cz.zcu.yafmt.clang.bcl.ui
- integrace jazyka BoolCL do uˇzivatelsk´eho rozhran´ı
cz.zcu.yafmt.ui
- spoleˇcn´ y k´od modul˚ u tvoˇr´ıc´ıch uˇzivatelsk´eho rozhran´ı
cz.zcu.yafmt.ui.editors.fm
- implementace editoru modelu vlastnost´ı
cz.zcu.yafmt.ui.editors.fc
- implementace editoru konfigurace vlastnost´ı
cz.zcu.yafmt.ui.views.fm
- implementace vizualizace modelu vlastnost´ı
Zn´azornˇen´ı jednotliv´ ych z´ asuvn´ ych modul˚ u a jejich vz´ajemn´ ych z´avislost´ı je zn´azornˇeno na obr´ azku 6.1 (pro pˇrehlednost byl odstranˇen prefix cz.zcu.yafmt). Rozdˇelen´ı modul˚ u do jednotliv´ ych komponent je pak zn´azornˇeno na obr´azku 6.2. Moduly, jeˇz na obr´azku horizont´ alnˇe prot´ınaj´ı nˇekolik komponent, jsou mezi nimi sd´ıleny. 1
Vyslovov´ ano jako [waI-Ef-Em-ti:] Abychom byli pˇresn´ı, jde sp´ıˇse o seskupen´ı z´ asuvn´ ych modul˚ u tvoˇr´ıc´ı dan´ y celek funkcionality. V terminologii Eclipse je takov´e seskupen´ı oznaˇcov´ ano jako feature (toto oznaˇcen´ı nem´ a nic spoleˇcn´eho s modely 2
61
Implementace n´ astroje
Meta-model
clang.bcl.ui clang.bcl
clang
model
model.validation
ui.views.fm
model.edit ui.editors.fm ui.editors.fc
ui
Obr´ azek 6.1: Z´ asuvn´e moduly n´astroje YAFMT a jejich vz´ajemn´e z´avislosti.
6.2
Meta-model
Model i konfigurace vlastnost´ı maj´ı sv˚ uj meta-model definovan´ y ve form´atu Ecore frameworku EMF. Z tohoto popisu meta-modelu byl pak automatick´ ym procesem vygenerov´an odpov´ıdaj´ıc´ı zdrojov´ y k´ od a pˇr´ıpadnˇe byly nˇekter´e jeho ˇc´asti upraveny ˇci doplnˇeny. EMF standardnˇe generuje pro kaˇzd´ y prvek meta-modelu zvl´aˇst’ jeho rozhran´ı i jeho implementaci, coˇz bylo pouˇzito i v naˇsem pˇr´ıpadˇe. Zm´ınˇen´e definice meta-modelu i vygenerovan´ y k´od jsou um´ıstˇeny v samostatn´em modulu cz.zcu.yafmt.model. Soubory popisu meta-model˚ u FeatureModel.ecore a FeatureConfiguration.ecore lze naj´ıt v adres´ aˇri models. Generov´an´ı prob´ıhalo zpracov´an´ı souboru FeatureModel.genmodel, obsahuj´ıc´ım kromˇe odkazu na oba zm´ınˇen´e soubory i parametry cel´eho procesu generov´ an´ı. Sloˇzka src pak obsahuje vygenerovan´ y zdrojov´ y k´od rozdˇelen´ y do dvou bal´ık˚ u cz.zcu.yafmt.model.fm a cz.zcu.yafmt.model.fc, dle pˇr´ısluˇsn´eho meta-modelu.
6.2.1
Model vlastnost´ı
Meta-model modelu vlastnost´ı vych´az´ı z popisu model˚ u vlastnost´ı s kardinalitou a atributy uveden´em v [Cza05b], jeˇz jsme popsali v kapitole 2.5. Tento meta-model byl z praktick´ ych d˚ uvod˚ u m´ırnˇe modifikov´ an a rozˇs´ıˇren o nˇekter´e prvky meta-modelu n´astroje XFeature, popsan´eho v [Pas05]: vlastnost´ı).
62
Implementace n´ astroje
Meta-model
model clang model.validation model.edit clang.bcl
ui ui.editors.fm
ui.editors.fc
ui.views.fm
clang.bcl.ui
Feature Model Editor
Feature Config. Editor
Feature Model Visualizer
Boolean Constraint Language
Obr´ azek 6.2: Pouˇzit´ı z´ asuvn´ ych modul˚ u v r´amci jednotliv´ ych komponent YAFMT. 1. Kardinalita seskupen´ ych vlastnost´ı nen´ı omezena pouze na hodnotu [0..1], ale m˚ uˇze b´ yt libovoln´ a, jako u samostatn´ ych vlastnost´ı. Tedy, seskupen´e vlastnosti mohou b´ yt duplikovateln´e. 2. Vlastnost m˚ uˇze m´ıt libovoln´ y poˇcet pojmenovan´ ych atribut˚ u. D´ıky prvn´ı modifikaci jsme z´ıskali o trochu obecnˇejˇs´ı meta-model, neˇz je uveden v [Cza05b]. Pokud bylo v r´ amci p˚ uvodn´ıho meta-modelu potˇreba vytvoˇrit seskupenou duplikovatelnou vlastnost, musela b´ yt vytvoˇrena jako pod-vlastnost jin´e seskupen´e vlastnosti, jak ukazuje obr´azek 6.3a. Ekvivalentn´ı vyj´ adˇren´ı odpov´ıdaj´ıc´ı naˇsemu meta-modelu je na obr. 6.3b. Obr´azek 6.3c pak ukazuje pˇr´ıpad, kter´ y se v r´amci p˚ uvodn´ıho meta-modelu nedal zachytit3 . Druh´ a modifikace byla pˇrid´ ana z ˇcistˇe praktick´eho hlediska. V p˚ uvodn´ım meta-modelu, popsan´em v [Cza05b], muselo b´ yt v´ıce atribut˚ u na jednu vlastnost realizov´ano v podobˇe nˇekolika pod-vlastnost´ı, coˇz je pˇri jejich velk´em poˇctu nepˇrehledn´e. Struktura meta-modelu, vyj´ adˇren´a v podobˇe diagramu tˇr´ıd, je zn´azornˇena na obr. 6.4. Model vlastnost´ı (FeatureModel ) m´a pr´avˇe jednu vlastnost pˇredstavuj´ıc´ı koˇren cel´eho stromu. Pˇr´ıpadnˇe m˚ uˇze m´ıt tak´e odkazy na jin´e vlastnosti um´ıstˇen´e mimo hlavn´ı strom4 . Vlastnost (Feature) m˚ uˇze m´ıt libovoln´ y poˇcet pod-vlastnost´ı a skupin (Group), jeˇz pod sebou sdruˇzuj´ı dalˇs´ı vlastnosti. U vlastnosti i skupiny lze specifikovat doln´ı a horn´ı mez kardinality (lower, upper ). Kaˇzd´ a vlastnost m˚ uˇze m´ıt d´ale neomezen´ y poˇcet atribut˚ u (Attribute) typu pravdivostn´ı hodnota, cel´e ˇc´ıslo, desetinn´e ˇc´ıslo nebo ˇretˇezec (AttributeType). Jednotliv´e vlastnosti jsou mezi sebou rozliˇseny pomoc´ı identifik´atoru ID, kter´ y je pro nˇe v r´amci cel´eho modelu vlastnost´ı unik´atn´ı. Obdobnˇe jsou identifikov´any atributy, avˇsak jejich ID mus´ı b´ yt unik´ atn´ı pouze v r´amci pˇr´ısluˇsn´e vlastnosti. D˚ uleˇzit´e je zm´ınit zp˚ usob zachycen´ı dodateˇcn´ ych informac´ı v modelu vlastnost´ı. Na rozd´ıl od pˇr´ıstupu n´ astroje pure::variants, kdy bylo pro vlastnosti moˇzn´e definovat velk´e 3
V tomto pˇr´ıpadˇe je validn´ı konfigurac´ı jak´ akoliv dvou aˇz pˇeti prvkov´ a kombinace vlastnost´ı X a Y. Jde typicky o pˇr´ıpad, kdy uˇzivatel pˇri editaci diagramu pˇridal vlastnost, ale jeˇstˇe j´ı nepˇriˇradil ˇz´ adn´eho rodiˇce. 4
63
Implementace n´ astroje
Meta-model
A
A [0..2]
B
C'
B
C
[1..2]
C (a) Vyj´ adˇren´ı s p˚ uvodn´ım meta-modelem.
(b) Vyj´adˇren´ı s upraven´ ym meta-modelem.
X <2-5> [0..*]
[0..*]
Z
Y
(c) Model vlastnost´ı nevyj´adˇriteln´ y v p˚ uvodn´ım meta-modelu.
Obr´azek 6.3: Vyj´ adˇren´ı nˇekter´ ych model˚ u vlastnost´ı pˇri pouˇzit´ı meta-modelu n´astroje YAFMT. mnoˇzstv´ı parametr˚ u (verze, priorita, ˇcas vytvoˇren´ı, autor atd.), umoˇzn ˇuje n´aˇs meta-model pro kaˇzd´ y jeho prvek zachytit pouze parametry dva. Prvn´ı z nich (description) slouˇz´ı jako kr´atk´ y (jednoˇr´ adkov´ y) popis dan´eho elementu. Druh´ ym z nich je koment´aˇr (comment), jeˇz m˚ uˇze obsahovat libovolnˇe dlouh´ y textov´ y obsah. Uˇzivatel do nˇej tedy m˚ uˇze zapsat libovoln´e parametry ve formˇe strukturovan´eho textu. Vzhledem k tomu, ˇze nem˚ uˇzeme pˇredem pˇredpokl´ adat, jak´e parametry bude cht´ıt uˇzivatel pouˇz´ıvat, je toto nejflexibilnˇejˇs´ı ˇreˇsen´ı. Pro model vlastnost´ı lze dodateˇcnˇe specifikovat i textov´ y parametr ud´avaj´ıc´ı jeho verzi. Model vlastnost´ı m˚ uˇze m´ıt tak´e definov´an libovoln´ y poˇcet textov´ ych omezen´ı (Constraint). Jejich detailn´ı popis bude uveden aˇz v ˇc´asti 6.3.
6.2.2
Konfigurace vlastnost´ı
Diagram tˇr´ıd, jeˇz popisuje strukturu meta-modelu konfigurace vlastnost´ı, je zachycen na obr´azku 6.5. Vzhledem k tomu, ˇze model vlastnost´ı m˚ uˇze obsahovat i duplikovateln´e vlastnosti, nelze konfiguraci definovat jako prost´ y v´ yˇcet zvolen´ ych vlastnost´ı, ale jako stromovou strukturu, kop´ıruj´ıc´ı charakter p˚ uvodn´ıho modelu (viz diskuze tohoto probl´emu v kapitole 2.6). Jednotliv´e vybran´e vlastnosti jsou v konfiguraci reprezentov´any tˇr´ıdou Selection. Kaˇzd´ a takov´a vybran´ a vlastnost m˚ uˇze m´ıt libovoln´ y poˇcet potomk˚ u. Konfigurace vlastnost´ı (FeatureConfiguration) pak mus´ı obsahovat jednu vybranou vlastnost, pˇredstavuj´ıc´ı koˇren
64
Implementace n´ astroje
Meta-model
0..* FeatureModel name : EString version : EString description : EString comment : EString getFeatureById(EString) : Feature
0..*
root 1 orphans
constraints
0..*
parentFeature 0..1
Feature id : EString name : EString description : EString comment : EString lower : EInt upper : EInt
parent
1
groups
0..*
Constraint language : EString description : EString comment : EString value : EString
features
0..*
0..1
Attribute id : EString name : EString type : AttributeType description : EString comment : EString
cel´eho stromu. Propojen´ı mezi konfigurac´ı a modelem vlastnost´ı je provedeno pomoc´ı identifik´ ator˚ u ID, jeˇz jsou pro vlastnost a jej´ı protˇejˇsek v konfiguraci shodn´e. Pokud byla do konfigurace vybr´ ana vlastnost s atributy, jsou v konfiguraci pˇr´ıtomny jejich hodnoty pˇredstavovan´e abstraktn´ı tˇr´ıdou AttributeValue. Pro kaˇzd´ y typ atributu existuje jedna odvozen´ a tˇr´ıda (BooleanValue, IntegerValue, DoubleValue, StringValue). Uvedli jsme, ˇze jednotliv´e vybran´e vlastnosti (Selection) jsou rozliˇsen´e pomoc´ı ID, jehoˇz hodnota odpov´ıd´ a ID u jejich protˇejˇsku (Feature). Aby bylo tedy moˇzn´e s konfigurac´ı pracovat, mus´ı m´ıt konfigurace pˇr´ıstup i k dat˚ um z p˚ uvodn´ıho modelu vlastnost´ı, coˇz pˇredstavuje potenci´ aln´ı probl´em, nebot’ oboj´ı je uchov´av´ano ve formˇe samostatn´ ych soubor˚ u. Tˇr´ıda FeatureConfiguration proto obsahuje dvˇe poloˇzky: 1. featureModel - Odkaz na um´ıstˇen´ı souboru obsahuj´ıc´ı model vlastnost´ı. Umoˇzn ˇuje pˇr´ıstup k aktu´ aln´ı verzi modelu vlastnost´ı. 2. featureModelCopy - Kopie posledn´ı zn´ame verze modelu vlastnost´ı. D´ıky n´ı m˚ uˇze b´ yt soubor s konfigurac´ı pouˇz´ıv´an i samostatnˇe. Tˇr´ıda FeatureConfiguration sice obsahuje i atribut pro specifikaci verze, avˇsak ten je zde pˇr´ıtomen z ˇcistˇe uˇzivatelsk´eho hlediska. Hodnota tohoto atributu nen´ı nijak pouˇz´ıv´ana k porovn´ an´ı aktu´ alnosti verz´ı souboru.
6.2.3
Validace modelu
Standardnˇe m´ a v´ yvoj´ aˇr pracuj´ıc´ı s EMF dvˇe moˇznosti jak implementovat validaˇcn´ı mechanismus: 1. V r´ amci Ecore modelu lze definovat r˚ uzn´e omezuj´ıc´ı podm´ınky. Pˇri generov´an´ı k´odu je pak vytvoˇrena validaˇcn´ı tˇr´ıda, obsahuj´ıc´ı pro kaˇzdou takovou podm´ınku pˇredpˇripravenou metodu. Do tˇechto metod pak v´ yvoj´aˇr zap´ıˇse dan´ y validaˇcn´ı mechanismus. 2. Pouˇzit´ı nadstavby EMF Validation framework, funguj´ıc´ı podobn´ ym zp˚ usobem. Zde lze omezuj´ıc´ı podm´ınky zapisovat pˇr´ımo v r´amci Ecore modelu, napˇr´ıklad v jazyce OCL. Lze tak´e vytv´ aˇret omezen´ı a jejich valid´atory, jeˇz jsou znovupouˇziteln´e mezi r˚ uzn´ ymi Ecore modely. Druh´ y uveden´ y zp˚ usob je v naˇsem pˇr´ıpadˇe zbyteˇcnˇe komplikovan´ y. Z´asadn´ım probl´emem prvn´ıho pˇr´ıstupu byla nemoˇznost nechat vygenerovat validaˇcn´ı tˇr´ıdy v podobˇe samostatn´eho modulu5 . Dalˇs´ım probl´emem pak bylo, ˇze vygenerovan´ y valid´ator nedok´aˇze validovat hodnotu zadanou jako vstup od uˇzivatele, kter´a jeˇstˇe nen´ı souˇc´ast´ı modelu. Autor tedy zvolil pˇr´ıstup vytvoˇren´ı vlastn´ıho valid´atoru. Validaˇcn´ı tˇr´ıda pro model vlastnost´ı FeatureModelValidator i validaˇcn´ı tˇr´ıda pro konfiguraci vlastnost´ı FeatureConfigurationValidator implementuj´ı standardn´ı rozhran´ı EValidator z EMF, takˇze jsou pouˇziteln´e stejn´ ym zp˚ usobem jako automaticky vygenerovan´ y valid´ator. Obˇe tˇr´ıdy nav´ıc 5 Validaˇcn´ı tˇr´ıdy nemohly b´ yt souˇca ´st´ı bal´ıku cz.zcu.yafmt.model, nebot’ by mezi n´ım a cz.zcu.yafmt.clang vznikla cyklick´ a z´ avislost.
66
Implementace n´ astroje
Meta-model
implementuj´ı i rozhran´ı IStructuralFeatureValidator, jeˇz bylo pouˇzito pˇri validov´an´ı zad´avan´ ych uˇzivatelsk´ ych vstup˚ u. Hlavn´ı v´ yhodou tohoto pˇr´ıstupu je, ˇze validace modelu i uˇzivatelsk´ ych vstup˚ u je implementov´ana pouze na jedin´em m´ıstˇe. Ve v´ ysledku se tak´e nakonec uk´ azalo, ˇze vygenerovan´ y k´od by nepˇredstavoval aˇz takovou v´ yhodu, nebot’ byl jeho pomˇer k mnoˇzstv´ı (ruˇcnˇe napsan´eho) validaˇcn´ıho k´odu pomˇernˇe zanedbateln´ y. Pro model vlastnost´ı jsou validov´any vˇsechny z´akladn´ı parametry, jako napˇr´ıklad nepr´azdnost jmen, unik´ atnost ID nebo to, zda doln´ı mez u kardinality nepˇrekraˇcuje mez horn´ı. Pro kardinalitu skupin jsou nav´ıc validov´any i n´asleduj´ıc´ı podm´ınky6 X
upper(fi ) ≥ lower(g)
(6.1)
lower(fi ) ≤ upper(g)
(6.2)
i
X i
Pˇr´ıkladem nesplˇ nuj´ıc´ım podm´ınku 6.1 je skupina s kardinalitou h3 − 4i obsahuj´ıc´ı dvˇe voliteln´e vlastnosti. Je zˇrejm´e, ˇze v r´amci takov´e skupiny nelze nikdy vybrat 3 vlastnosti a nelze tedy ani sestrojit validn´ı konfiguraci. Pro konfiguraci vlastnost´ı jsou validov´ana omezen´ı specifikovan´ a pˇr´ısluˇsn´ ym modelem vlastnost´ı. Tato omezen´ı jsou dvou typ˚ u: • lok´ aln´ı - Urˇcen´e pomoc´ı kardinality vlastnost´ı a skupin. • glob´ aln´ı - Zapsan´e pomoc´ı pˇr´ısluˇsn´eho jazyka omezen´ı. Tato omezen´ı budou podrobnˇeji diskutov´ ana v podkapitole 6.3. Zm´ınˇen´e validaˇcn´ı i pomocn´e tˇr´ıdy jsou um´ıstˇeny v bal´ıˇcku cz.zcu.yafmt.model.validation, jeˇz je souˇc´ ast´ı stejnojmenn´eho z´ asuvn´eho modulu.
6.2.4
Integrace s uˇ zivatelsk´ ym rozhran´ım
Z´akladn´ı vlastnost´ı EMF je, ˇze ze vstupn´ıho Ecore modelu dok´aˇze vygenerovat nejen zdrojov´ y k´ od implementuj´ıc´ı dan´ y meta-model, ale i k´od nˇekter´ ych dalˇs´ıch souˇc´ast´ı. Jedna z tˇechto souˇc´ ast´ı, naz´ yv´ ana jako EMF.Edit, pˇredstavuje mezivrstvu mezi EMF modelem a uˇzivatelsk´ ym rozhran´ım, usnadˇ nuj´ıc´ı tak jejich propojen´ı. EMF.Edit nen´ı pevnˇe v´ az´ ano na ˇz´adnou knihovnu pro tvorbu uˇzivatelsk´eho rozhran´ı, nicm´enˇe pˇredpokl´ ad´ a ˇze bude pˇri c´ılov´e implementaci pouˇzit n´avrhov´ y vzor MVC nebo jeho obdoba. Pˇri pouˇzit´ı EMF.Edit je pro kaˇzdou tˇr´ıdu meta-modelu vygenerov´ana odpov´ıdaj´ıc´ı tˇr´ıda jm´enem N´ azevTˇr´ıdyItemProvider, jeˇz slouˇz´ı ke zprostˇredkov´an´ı z´akladn´ıch u ´daj˚ u o modelu v˚ uˇci vrstvˇe uˇzivatelsk´eho rozhran´ı. Pˇr´ıkladem takov´ ych u ´daj˚ u jsou napˇr´ıklad textov´e popisky, ikony pro jednotliv´e objekty, popis parametr˚ u, jeˇz lze editovat apod. Program´ ator m˚ uˇze k´ od tˇechto vygenerovan´ ych tˇr´ıd pˇrizp˚ usobit dle sv´ ych potˇreb. Napojen´ı na uˇzivatelsk´e rozhran´ı pak prob´ıh´a adaptac´ı zm´ınˇen´ ych tˇr´ıd. Pro zjednoduˇsen´ı pr´ace nab´ız´ı EMF jiˇz hotov´e adapt´ery pro knihovnu SWT, pouˇz´ıvanou v r´amci Eclipse. 6
g je skupina a fi pak jej´ı jednotliv´e vlastnosti. lower a upper oznaˇcuj´ı doln´ı a horn´ı mez kardinality.
67
Implementace n´ astroje
Jazyk omezen´ı
EMF.Edit je standardnˇe generov´an ve formˇe samostatn´eho modulu, v naˇsem pˇr´ıpadˇe cz.zcu.yafmt.model.edit. Mimo obvykl´ ych u ´prav byl do tohoto modulu tak´e pˇrid´an k´ od zajiˇst’uj´ıc´ı validaci vstup˚ u, vyuˇz´ıvaj´ıc´ı modul cz.zcu.yafmt.model.validation.
6.3
Jazyk omezen´ı
Pro pouˇzit´ı jazyka omezen´ı jsme mˇeli v podstatˇe dvˇe moˇznosti. Bud’ pouˇz´ıt jiˇz nˇejak´ y existuj´ıc´ı jazyk (napˇr. OCL, XPath apod.), ˇci vytvoˇrit jazyk zcela nov´ y. Probl´emem prvn´ı moˇznosti je pˇr´ıpadn´ a obt´ıˇznost integrace takov´eho jazyka do naˇseho n´astroje. Probl´emem druh´e moˇznosti je nutnost navrhnout dan´ y jazyk tak, aby byl dostateˇcnˇe expresivn´ı a vyhovoval co nejvˇetˇs´ımu poˇctu uˇzivatel˚ u. Tento probl´em byl nakonec vyˇreˇsen zcela jin´ ym zp˚ usobem, a to tak, ˇze n´astroj nepouˇz´ıv´ a pevnˇe zvolen´ y jazyk omezen´ı, ale umoˇzn ˇuje jejich pˇrid´an´ı v podobˇe rozˇsiˇruj´ıc´ıch z´asuvn´ ych modul˚ u. Uˇzivatel si tak m˚ uˇze pro kaˇzd´e omezen´ı vybrat, v jak´em jazyce bude zaps´ano. S n´ astrojem jsou standardnˇe dod´av´any dva jazyky, jeˇz budou pops´any d´ale v textu. V pˇr´ıpadˇe jejich nedostateˇcnosti m˚ uˇze kdokoliv implementovat sv˚ uj vlastn´ı jazyk omezen´ı, coˇz lze udˇelat skrze dvˇe m´ısta rozˇs´ıˇren´ı (extension points): • cz.zcu.yafmt.clang - Umoˇzn ˇuje pˇridat nov´ y jazyk omezen´ı (jeho interpret). • cz.zcu.yafmt.clang.ui - Umoˇzn ˇuje pˇridat specializovan´ y editor pro jiˇz existuj´ıc´ı jazyk omezen´ı (napˇr´ıklad s podporou zv´ yrazˇ nov´an´ı syntaxe). Uveden´ a m´ısta rozˇs´ıˇren´ı jsou definov´ana v r´amci z´asuvn´eho modulu cz.zcu.yafmt.clang. Ten tak´e obsahuje r˚ uzn´ a podp˚ urn´a rozhran´ı a tˇr´ıdy nutn´e pro implementaci nov´eho jazyka omezen´ı. V´ yvoj´ aˇr, kter´ y by chtˇel takov´ y jazyk pˇridat, mus´ı splnit dvˇe vˇeci: 1. Mus´ı v r´ amci sv´eho z´ asuvn´eho modulu definovat rozˇs´ıˇren´ı cz.zcu.yafmt.clang. Uk´azku jak vypad´ a takov´ a definice v podobˇe XML m˚ uˇzeme vidˇet ve v´ ypisu 6.1. D˚ uleˇzit´e je zde zejm´ena ID, pomoc´ı kter´eho jsou jednotliv´e jazyky navz´ajem rozliˇseny a kter´e je pak uvedeno i v instanci tˇr´ıdy Constraint. 2. Mus´ı implementovat rozhran´ı IConstraintLanguage. N´azev implementaˇcn´ı tˇr´ıdy je souˇc´ ast´ı pˇredchoz´ı definice. To, jak vypadaj´ı jednotliv´ a rozhran´ı tohoto rozˇs´ıˇren´ı, lze vidˇet na obr. 6.6. Rozhran´ı IConstraintLanguage pˇredstavuje tov´ arn´ı tˇr´ıdu, jeˇz z omezen´ı v dan´em jazyce vytv´aˇr´ı jejich reprezentaci v podobˇe IEvaluator. To pot´e slouˇz´ı k validaci dan´eho omezen´ı (napˇr. zda j´ım odkazovan´e vlastnosti opravdu existuj´ı) a k vyhodnocen´ı konfigurace vlastnost´ı (zda-li splˇ nuje dan´e omezen´ı). Pˇr´ıpadnˇe se lze pomoc´ı IEvaluator dot´azat na vlastnosti, jeˇz jsou dan´ ym omezen´ım ovlivnˇeny7 . IValidationResult a IEvaluationResult pak pˇredstavuj´ı v´ ysledek zm´ınˇen´e validace a vyhodnocen´ı. IEvaluationResult vrac´ı, kromˇe v´ ysledku a chybov´e zpr´avy, tak´e prvky modelu, kter´e zapˇr´ıˇcinily poruˇsen´ı dan´eho omezen´ı. Ty jsou pak editoru 7 Toho je vyuˇzito zejm´ena pˇri vizualizaci modelu vlastnost´ı nebo pˇri zv´ yrazˇ nov´ an´ı souvisej´ıc´ıch prvk˚ uv editoru.
68
Implementace n´ astroje
Jazyk omezen´ı
pro uˇzivatele viditelnˇe oznaˇceny. Pro uveden´a rozhran´ı existuje v bal´ıˇcku cz.zcu.yafmt.clang tak´e jejich z´ akladn´ı implementace. < extension point = " cz . zcu . yafmt . clang " > < language id = " com . example . myclang " name = " My Constraint Language " shortName = " MyCL " class = " com . example . myclang . MyConstraintLanguage " / >
V´ ypis 6.1: Uk´ azka definice rozˇs´ıˇren´ı cz.zcu.yafmt.clang. Obdobn´ ym zp˚ usobem lze pouˇz´ıt i m´ısto rozˇs´ıˇren´ı cz.zcu.yafmt.clang.ui, kde v´ yvoj´aˇr implementuje rozhran´ı IEditingSupport pˇredstavuj´ıc´ı tov´arn´ı tˇr´ıdu pro konstrukci vlastn´ıho editoru. Na zaˇc´ atku editace omezen´ı je vˇzdy vyhled´ano, zda nen´ı implementace tohoto rozhran´ı pro zvolen´ y jazyk omezen´ı dostupn´a. V takov´em pˇr´ıpadˇe je pak standardn´ı editor nahrazen t´ım specializovan´ ym. «interface» IConstraintLanguage +createEvaluator(constraint: String): IEvaluator
vytváří «interface» IEvaluator +validate(fm: FeatureModel):IValidationResult +evaluate(fc: FeatureConfiguration): IEvaluationResult +getAffectedFeatures(fm: FeatureModel): List
výsledek vyhodnocení
výsledek validace «interface» IValidationResult +isSuccess(): boolean +getErrorMessage(): String
«interface» IEvaluationResult +isSuccess(): boolean +getErrorMessage(): String +getProblemElements(): List
