vaidas giedrimas komponentiniŲ programŲ sistemŲ … · komponen tiniuprogramu si stemuurimok...

VYTAUTO DIDŽIOJO UNIVERSITETAS

MATEMATIKOS IR INFORMATIKOS INSTITUTAS

Vaidas Giedrimas

KOMPONENTINIŲ PROGRAMŲ SISTEMŲ

GENERAVIMO METODAS

Daktaro disertacija

Fiziniai mokslai (P 000)

Informatika (09 P)

Informatika, sistemų teorija (P 175)

Vilnius, 2010

Disertacija rengta 2002 – 2006 metais Matematikos ir informatikos institute.

Disertacija ginama eksternu.

Mokslinė konsultantė

doc. dr. Audronė Lupeikienė

(Matematikos ir informatikos institutas, fiziniai mokslai, informatika – 09 P)

Padeka

Uº nuolatini palaikym¡, kantryb¦ ir supratim¡ nore£iau padekoti savo ²eimaiir visu pirma ºmonai Linai.

Uº vertingas mokslines konsultacijas ir diskusijas, skatinusias tobuleti, uºpastabas ir patarimus, padejusius pagerinti ²io darbo kokyb¦ nuo²irdºiai dekojumokslinei vadovei Audronei Lupeikienei, profesoriui Albertui aplinskui irvisam Matematikos ir informatikos instituto Programu sistemu inºinerijos sky-riui, gerbiamoms recenzentems Aidai Pliu²kevi£ienei ir Dalei Dzemydienei,kolegoms i² Vilniaus universiteto ir iauliu universiteto.

Uº suteikt¡ verting¡ informacij¡ dekoju ir kolegoms i² uºsienio: J. CraigCleaveland, Margus Veanes, Vahur Kotkas, Ando Saabas, Jaan Penjam, EnnTyugu bei Estijos Kibernetikos instituto darbuotojams.

Dekoju Lietuvos valstybiniam mokslo ir studiju fondui bei iauliu univer-sitetui uº suteikt¡ nansin¦ param¡ studiju metu.

Galiausiai nore£iau padekoti visiems asmenis rengusiems respublikines artarptautines konferencijas ir kitaip prisidejusiems prie ²ios disertacijos rezultatuskelbimo.

Turinys

1. Ivadas 181.1. Tyrimu sritis ir problemos aktualumas . . . . . . . . . . . . . . 181.2. Tyrimu objektas . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3. Tyrimu tikslas ir uºdaviniai . . . . . . . . . . . . . . . . . . . . 191.4. Ginamieji disertacijos teiginiai . . . . . . . . . . . . . . . . . . . 201.5. Tyrimo metodai . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.6. Mokslinis naujumas . . . . . . . . . . . . . . . . . . . . . . . . . 211.7. Praktine darbo reik²me . . . . . . . . . . . . . . . . . . . . . . 211.8. Rezultatu aprobavimas ir publikavimas . . . . . . . . . . . . . . 211.9. Disertacijos struktura . . . . . . . . . . . . . . . . . . . . . . . 23

2. Komponentiniu programu sistemu kurimo proceso sampratair modeliai 242.1. Komponento modeliai . . . . . . . . . . . . . . . . . . . . . . . 24

2.1.1. Szypersky modelis . . . . . . . . . . . . . . . . . . . . . 252.1.2. UNU/IIST modelis . . . . . . . . . . . . . . . . . . . . . 262.1.3. UMM modelis . . . . . . . . . . . . . . . . . . . . . . . . 302.1.4. Fractal modelis . . . . . . . . . . . . . . . . . . . . . . . 302.1.5. PECOS modelis . . . . . . . . . . . . . . . . . . . . . . 322.1.6. UML komponento modelis . . . . . . . . . . . . . . . . . 332.1.7. Poernomo grupes modelis . . . . . . . . . . . . . . . . . 352.1.8. Cervantes modelis . . . . . . . . . . . . . . . . . . . . . 362.1.9. Salzmann modelis . . . . . . . . . . . . . . . . . . . . . 362.1.10. Berger grupes modelis . . . . . . . . . . . . . . . . . . . 372.1.11. Aguirre ir Maibaum modelis . . . . . . . . . . . . . . . . 382.1.12. Nierstras, Lumpe ir Schneider modelis . . . . . . . . . . 392.1.13. Yoshida ir Honiden modelis . . . . . . . . . . . . . . . . 402.1.14. Lau grupes modelis . . . . . . . . . . . . . . . . . . . . . 412.1.15. Cox ir Song modelis . . . . . . . . . . . . . . . . . . . . 422.1.16. Moschoyiannis modelis . . . . . . . . . . . . . . . . . . . 432.1.17. Whitehead modelis . . . . . . . . . . . . . . . . . . . . . 44

6 Turinys

2.1.18. SCA modelis . . . . . . . . . . . . . . . . . . . . . . . . 452.1.19. Komponavimo formos . . . . . . . . . . . . . . . . . . . 46

2.2. Komponento abstrakcijos lygmenys . . . . . . . . . . . . . . . . 482.3. Komponentu kurimo procesas . . . . . . . . . . . . . . . . . . . 502.4. Komponentiniu sistemu kurimo procesas . . . . . . . . . . . . . 512.5. Skyriaus i²vados . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3. Programu sistemu generavimo metodu lyginamoji analize 603.1. Klasikiniai formalieji metodai . . . . . . . . . . . . . . . . . . . 613.2. Deduktyviosios sintezes metodas . . . . . . . . . . . . . . . . . 67

3.2.1. Programu sistemu deduktyviosios sintezes uºdavinys . . 683.2.2. Automatinio teoremu irodymo programos . . . . . . . . 70

3.3. Strukturines programu sintezes metodas . . . . . . . . . . . . . 773.3.1. Strukturines sintezes skai£iavimo modeliai . . . . . . . . 773.3.2. Strukturines sintezes algoritmai . . . . . . . . . . . . . . 80

3.3.2.1. I²vedimo taisykles . . . . . . . . . . . . . . . . 813.3.2.2. Tiesines strukturos programu sinteze: algorit-

mas A1 . . . . . . . . . . . . . . . . . . . . . . 823.3.2.3. Besi²akojan£iu programu sinteze: algoritmas A2 833.3.2.4. Programu su pouºdaviniais sinteze: algoritmas

A3 . . . . . . . . . . . . . . . . . . . . . . . . . 853.3.2.5. Duomenu srautai: algoritmas A4 . . . . . . . . 86

3.3.3. Strukturines programu sintezes realizacijos . . . . . . . . 873.3.3.1. Klasikine strukturines sintezes sistema . . . . . 873.3.3.2. Objektines strukturines sintezes sistemos . . . 893.3.3.3. Paslaugines strukturines sintezes sistemos . . . 93

3.4. Curry-Howard protokolas . . . . . . . . . . . . . . . . . . . . . 963.5. Induktyviosios sintezes metodas . . . . . . . . . . . . . . . . . . 1003.6. Transformacines sintezes metodas . . . . . . . . . . . . . . . . . 1023.7. Skyriaus i²vados . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4. Komponentiniu programu kurimo proceso automatizavimo meto-das 110

4.1. Programinio komponento modelis . . . . . . . . . . . . . . . . . 1104.1.1. Strukturinis PKM aspektas . . . . . . . . . . . . . . . . 1124.1.2. Dinaminis PKM aspektas . . . . . . . . . . . . . . . . . 1164.1.3. Komponavimo kalba . . . . . . . . . . . . . . . . . . . . 118

4.2. Komponentine Curry-Howard protokolo realizacija . . . . . . . 1224.2.1. Loginis skai£iavimas . . . . . . . . . . . . . . . . . . . . 1224.2.2. LTT komponentinei paradigmai . . . . . . . . . . . . . . 1234.2.3. Tipu teoriju atitiktis . . . . . . . . . . . . . . . . . . . . 125

4.3. Strukturines programu sintezes elementai . . . . . . . . . . . . 125

Turinys 7

4.4. Induktyviojo metodo elementai . . . . . . . . . . . . . . . . . . 1304.5. Metodo taikymo pavyzdºiai . . . . . . . . . . . . . . . . . . . . 131

4.5.1. Vaistu dozatoriaus programa . . . . . . . . . . . . . . . 1314.5.2. Videomedºiagos transliacija . . . . . . . . . . . . . . . . 132

4.6. Skyriaus i²vados . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5. Komponentiniu sistemu generavimo metodo realizacija 1355.1. SoCoSyS sistema . . . . . . . . . . . . . . . . . . . . . . . . . 135

5.1.1. Teoremu irodymo programa SoCoProove . . . . . . . . . 1365.1.2. Komponento specikacijos lygmens programu sintezes

sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375.1.3. Komponento realizacijos lygmens programu sintezes sis-

tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385.2. Sistemos eksperimentinis tyrimas . . . . . . . . . . . . . . . . . 1405.3. Palyginimas su kitomis sistemomis . . . . . . . . . . . . . . . . 143

5.3.1. NORA/HAMMR sistema . . . . . . . . . . . . . . . . . 1435.3.2. QUASAR sistema . . . . . . . . . . . . . . . . . . . . . 1445.3.3. Component WorkBeanch sistema . . . . . . . . . . . . . 1455.3.4. CoSMIC sistema . . . . . . . . . . . . . . . . . . . . . . 147

5.4. Skyriaus i²vados . . . . . . . . . . . . . . . . . . . . . . . . . . 148

I²vados 150

Literatura 152

A. Publikaciju s¡ra²as 168

B. Komponento modeliu klasterizavimo rezultatai 170B.1. Komponento modeliu klasteriai . . . . . . . . . . . . . . . . . . 170B.2. Komponento modeliu savybiu klasteriai . . . . . . . . . . . . . 171

Lenteliu s¡ra²as

2.1 Komponento ir jo interfeiso specikaciju palyginimas [34]. . . . 342.2 KM taksonomija pagal komponavimo kriteriju [100]. . . . . . . 482.3 Komponento abstrakcijos lygmenys. . . . . . . . . . . . . . . . . 572.4 Nefunkciniai reikalavimai. Parengta pagal [165, 38]. . . . . . . 59

3.1 Konstrukciju kalbos kvantoriai. Parengta pagal [11]. . . . . . . 633.2 E. W. Dijkstra ir M. Charpentier teoriju atitikmenys. . . . . . 663.3 Predikatu transformatoriu palyginimas [33] . . . . . . . . . . . 1073.4 Automatiniu teoremu irodymo irankiu lyginamoji analize. . . . 1083.5 Curry-Howard protokolo elementai [142]. . . . . . . . . . . . . . 109

4.1 Ribojimu lygmenys. . . . . . . . . . . . . . . . . . . . . . . . . 1184.2 ITS i²vedimo taisykles (DR). . . . . . . . . . . . . . . . . . . . 1244.3 LTT tipai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244.4 LTT i²vedimo taisykles (PTR). . . . . . . . . . . . . . . . . . . 1254.5 LTT ir CTT termu atitikties funkcija etype(F ). . . . . . . . . . 1264.6 LTT ir CTT formuliu atitikties funkcija extract(pT ). . . . . . . 1274.7 SSP algoritmu sudetingumas laiko atºvilgiu. . . . . . . . . . . . 129

5.1 Komponentiniu programu generavimo sistemos . . . . . . . . . 149

Iliustraciju s¡ra²as

2.1 UNU/IIST komponentine sistema. Parengta pagal [163]. . . . . 282.2 FRACTAL komponento modelis [56]. . . . . . . . . . . . . . . . 312.3 SCA komponento modelis [18]. . . . . . . . . . . . . . . . . . . 462.4 Komponavimo formos [10]. . . . . . . . . . . . . . . . . . . . . . 472.5 Komponento modeliu elementai. . . . . . . . . . . . . . . . . . . 562.6 Komponento kurimo etapai. . . . . . . . . . . . . . . . . . . . . 582.7 Komponentiniu programu sistemu kurimo etapai. . . . . . . . . 58

3.1 Irodymu vaidmuo automatizuotame komponentiniu programukurimo procese. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.2 Programu sintezes metodu tarpusavio ry²iai. . . . . . . . . . . . 673.3 Supaprastinta R. Bazler pasiulyta automatizuoto programu kurimo

deduktyviosios sintezes metodu schema. . . . . . . . . . . . . . 693.4 Automatizuoto programu kurimo deduktyviosios sintezes meto-

du schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.5 Automatinio teoremu irodymo etapai. . . . . . . . . . . . . . . 743.6 SSP s¡ry²iai [167]. . . . . . . . . . . . . . . . . . . . . . . . . . 793.7 SSP s¡ry²iu tipai [167]. . . . . . . . . . . . . . . . . . . . . . . . 793.8 Valdymo ta²kas SSP skai£iuojamajame modelyje [167]. . . . . . 793.9 SSP s¡lygos s¡ry²is [167]. . . . . . . . . . . . . . . . . . . . . . 803.10 SSP pouºdavinio s¡ry²is [167] . . . . . . . . . . . . . . . . . . . 80

4.1 Galimi komponento modeliu ir sintezes sistemu s¡veikos modeliai.1114.2 Programinio komponento modelis . . . . . . . . . . . . . . . . . 1134.3 Programinio komponento specikacijos ir realizacijos lygmenu

komponento modelis. . . . . . . . . . . . . . . . . . . . . . . . . 1174.4 Akademiniu komponento modeliu ry²ys su Programiniu kompo-

nento modeliu. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.5 Komponentiniu technologiju ry²ys su Programinio komponento

modeliu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204.6 Komponento prievadu loginiu s¡ry²iu pavyzdºiai . . . . . . . . 123

10

5.1 SoCoProove klasiu diagrama. . . . . . . . . . . . . . . . . . . . 1375.2 Komponento specikacijos lygmens programu sintezes sistema. . 1385.3 SoCoSyS sistemos klasiu diagrama . . . . . . . . . . . . . . . 1395.4 Komponento realizacijos lygmens programu sintezes sistema. . . 1405.5 Eksperimento su SoCoSyS sistema eiga. . . . . . . . . . . . . . 1405.6 SoCoSyS ir .NET komponentu generatoriaus langai. . . . . . . 1415.7 Programu architekturos generavimo sistema QUASAR. . . . . . 1445.8 Komponentiniu programu sistemu generavimo sistema CoSMIC. 147

B.1 Komponento modeliu klasteriu dendograma. . . . . . . . . . . . 170B.2 Komponento modeliu savybiu klasteriu dendograma. . . . . . . 171

Sutrumpinimu s¡ra²as

ADL Architekturos apra²ymo kalba.

ATP Automatinio teoremu irodymo programa (angl.prover).

BMTP R.S. Boyer ir J.S. Moore sukurta teoremu irodymoprograma naudojanti induktyvini metod¡.

BPEL Pasaulinio tinklo paslaugu s¡veikos apra²ymo kalba(angl. Business Process Execution Language).

CCM CORBA pagrindu OMG konsorciumo sukurtas kom-ponento modelis (angl. CORBA Component Model).

CIP Programu sintezes sistema, realizuojanti metaprogra-mavimo metod¡.

CoC konstrukciju skai£iavimas (angl. Calculus of Construc-tions), naudotas Coq sistemoje.

COM Microsoft komponentine technologija.

CORBA Vienas i² OMG konsorciumo palaikomu komponentomodeliu (angl. Calculus of Constructions).

CSP Formalioji specikavimo kalba lygiagretiesiems proce-sams specikuoti angl. (Communicating sequentialprocesses) [40].

CTT Skai£iuojamoji tipu teorija.

12

CWB Component WorkBeanch programu sintezes sistema.

DB Duomenu baze.

DB Duomenu baziu valdymo sistema.

DAML-S Ontologiju apra²ymo kalba.

FP Funkciniu ta²ku skai£ius.

EJB Vienas i² Sun Microsotems komponento modeliu (angl.Enterprise Java Beans)[157].

ESSP I²plestasis SSP metodas (angl. Extended SSP).

FM Formalieji metodai.

HOPE Programu sintezes sistema, realizavusi metaprogra-mavimo metod¡.

ITS Intuicionistinis teiginiu skai£iavimas (angl. intuition-istic propositional calculus).

JPK Jungiantysis programinis kodas (angl. glue-code).

KK Komponentinis karkasas (angl. framework), vykdymoaplinka.

KPS Komponentine programu sistema.

KPSGC Komponentines programu sistemos gyvavimo ciklas.

KVK Klasiu veiksmu (angl. Class actions) apra²ymo kalba,Vykdomosios UML dalis.

.NET Microsoft komponentine technologija.

LCF Skai£iuojamuju funkciju logika.

LoC Kodo eilu£iu skai£ius (angl. lines of code).

LTT Logine tipu teorija.

13

MDA Modeline programu sistemu architektura (angl.Model-driven architecture).

ML Funkcinio programavimo kalba.

MOP Metaobjektu protokolas (angl. Metaobject protocol).

NuPRL Viena pirmuju programu sintezes sistemu.

NUT rus. Novyj UTOPIST SSP metod¡ realizuojantiobjektiniu programu sintezes sistema.

OCL Objektu ribojimu specikavimo kalba (angl. ObjectConstraint language) apibreºta UML standarte.

OWL-S Ontologiju apra²ymo kalba.

PECOS 20002002 metais vykdytas projektas Pervasive Com-ponent Systems (IST-1999-20398) arba projekte nau-dotas komponento modelis.

PIM Abstraktusis programos modelis MDA architekturoje(angl. Platform-independent model).

PKM Disertacijos autoriaus siulomas Programinio kom-ponento modelis, apibendrinantis kitus komponentomodelius.

PRIZ 19751977 m. pradeta kurti programu sintezes sis-tema, realizuojanti SSP metod¡.

PSM Konkretusis programos modelis MDA architekturoje(angl. platform-specic model).

PTP Pasaulinio tinklo paslaugos (angl. web-services).

QoS angl. Quality of service kokybes uºtikrinimas.

RAPTS Programu sintezes sistema, realizavusi i²plestojo kom-piliavimo metod¡ [27].

14

SCA angl. Servise Component Architecture vienas i²komponento modeliu realizuojantis paslaugin¦ ar-chitektur¡.

SETL Programu sintezes sistema, realizavusi i²plestojo kom-piliavimo metod¡.

SOFA Architekturos apra²ymo kalba.

SML Bendros paskirties moduline funkcinio programavimokalba.

SNARK Teoremu irodymo programa [156], naudota DEDALUSir Amphion sistemose.

SP Stipriausia prie² s¡lyga (angl. strongest precondi-tion).

SPP Strukturines programu sintezes metodas.

TAMPR Programu sintezes sistema, realizavusi i²plestojo kom-piliavimo metod¡ [25].

UCM Architekturiniai ruo²iniai (angl. Use Case Maps) nau-dojami programiniu produktu ²eimoms projektuoti irrealizuoti.

UMM angl. Unied Metamodel projekto UniFrame metusukurtas komponento modelis.

UML angl. Unied Modeling Langugage OMG konsorciu-mo palaikoma verslo ir programines irangos modeliav-imo kalba.

UTOPIST PRIZ sistemoje naudota specikavimo kalba.

WP Silpniausia prie² s¡lyga (angl. Weakest precondi-tion).

VA Komponentu ir ju sistemu vykdymo aplinka.

15

WSDL Pasaulinio tinklo paslaugu apra²ymo kalba (angl. WebServices Description Language).

WSDL Pasaulinio tinklo paslaugu komponavimo apra²ymokalba (angl. Web Services Flow Language), pasiulytaIBM.

XML Universali duomenu strukturu apra²ymo kalba (angl.Extensible Markup language).

XSLT angl. XSL transformations XML formato duomenutransformaciju apra²ymo kalba.

ZAP Programu sintezes sistema, realizavusi metaprogra-mavimo metod¡.

B iniu baze.

S¡voku ºodynelis

Interfeisas Komponento elgsenos abstrakcija, gaunama slepiantkomponento operacijas nuo i²ores. Skiriama patieskomponento elgsena (teikiamas interfeisas) ir i²orineskomponento aplinkos elgsena (reikalaujamas inter-feisas).

Irodomasis pro-gramavimas

Automatizuoto programu kurimo metodu klase (angl.proofs-as-programs), kuriai priklausantiems metodamsbudingas formalus uºdavinio apra²ymas logines teori-jos terminais ir programos gavimas naudojant teoremuirodymo iranki.

Generavimas Automatizuoto programu kurimo budas, daºniausiaisusietas ir su apibendrintu ruo²iniu naudojimu.

Generatorius Programa arba jos dalis, atliekanti konkre£iusprogramu generavimo proceso uºdavinius.

Kvalikacija Komponent¡ arba jo sudetinius elementus charak-terizuojanti savybe (angl. credential). Paprastaitokios savybes naudojamos komponentu patikimumui,veikimo spartai ir kt. nefunkciniams reikalavimamsi²reik²ti.

Komponavimas Komponentu jungimas tarpusavyje ir (arba) su kitomiskomponento modelyje apibreºtomis esybemis (pvz.:komponentiniu karkasu) siekiant gauti komponentin¦sistem¡.

Komponentas Komponavimo vienetas su kontraktu specikuotais in-terfeisais, atitinkantis tam tikr¡ komponento modeli.

17

Komponentomodelis

S¡voku ir taisykliu, nusakan£iu komponent¡, jo dalisir jo naudojimui reikalingas paslaugas, visuma.

Kontraktas Komponentu tarpusavio komunikavimo abstrakcija,apibreºianti veiksmu su komponentu sekas, bei gal-im¡ ²iu veiksmu itak¡ komponento busenoms (jeitokios stebimos). Skiriamas komponento kontrak-tas, nusakantis komponento teikiamas ir reikalaujamaspaslaugas, ir s¡veikos kontraktas, nusakantis kokiusvaidmenis komponentas atlieka sistemoje.

Prievadas (angl. port) Komponento s¡veikos su i²ore abstrakcija.Prievadu laikomas komponento interfeisas, ivykio ²al-tinis, ivykio jutiklis ir i² i²ores pasiekiamas atributas.

Sinteze Automatizuoto programu kurimo budas, daºniausiaisusietas su sudedamuju daliu jungim¡ i visum¡. iojedisertacijoje terminas sinteze naudojamas ir kaip ter-mino generavimas sinonimas.

1 skyrius

Ivadas

1.1. Tyrimu sritis ir problemos aktualumas

iuolaikinis programines irangos kurimo procesas yra kritinis tiek laiko, tiekkokybes poºiuriu. Programu sistemos priklauso nuo dinami²kai besikei£ian£ioverslo, todel turi buti paprastai modikuojamos ir lengvai aptarnaujamos.Siekiant ²io tikslo siulomos vis naujos programu sistemu kurimo paradigmos irmetodikos.

Programu sistemu inºinerijai praejus strukturines ir objektines paradig-mos raidos etapus pastebeta, kad norint padidinti programu kurimo metoduveiksmingum¡, butina kurti programas pakartotinai naudojant kiek imanomadidesnes apimties (angl. granularity) modulius [115].

Didºiausios apimties juodosios deºes tipo modulius siulo komponentineparadigma. Komponentiniu programu sistemu inºinerija igalina sumaºintilaiko ir kitu programu kurimui bei testavimui butinu i²tekliu poreiki. Grieºtasturiniu atskyrimo principo laikymasis palengvina tokiu sistemu aptarnavimoproces¡. Ta£iau ir komponentine paradigma negali uºtikrinti reikiamos pro-gramines irangos kokybes, todel butini nauji komponentiniu programu sistemukurimo metodai.

Praktinems programu sistemu inºinerijos problemoms spr¦sti ne kart¡ siuly-ti automatinio ir automatizuoto programavimo metodai. Automatinio progra-mavimo terminas pradetas vartoti ne veliau kaip 1954 m., kai buvo norimanusakyti pirmuosius Fortran kalbos kompiliatorius [17]. I² pradºiu programukurimo automatizavimas buvo suprantamas kaip kompiliavimo problema, kaiformali specikacija kompiliuojama siekiant gauti vykdom¡ program¡ [27, 25,53]. Velesniuose ²altiniuose ²is terminas jau apima ir specikaciju sudarym¡,ir teisingumo uºtikrinim¡, ir projektinius sprendinius, auk²to abstrakcijos lyg-mens specikacijas ver£iant i ºemesnio abstrakcijos lygmens specikacijas, irpan. Taigi, automatinis kompiliavimas ilgainiui i²sivyste i automatizuoto pro-

1.2. Tyrimu objektas 19

gramavimo paradigm¡ ir automatizuot¡ programu sistemu inºinerij¡ (angl.automated software engineering).

Per pastaruosius 20 metu daugeja programu gavimo generavimo metu idejosrealizaciju, kuriami ir pla£iai naudojami generavimo metodai [143, 59, 43, 60,69, 81]. Skiriamos kelios automatizuoto programu sistemu kurimo kryptys prik-lausomai nuo naudojamos ²io uºdavinio sampratos ir kurimo modelio. Vis delto daºniausiai akcentuojamas programu kurimo proceso automatizuotu budugreitis, o ne rezultatu patikimumas. is akcentas pastebimas ir egzistuojan£iosekomponentiniu programu sistemu generavimo sistemose [150, 132].

Auk²tesni programu generavimo rezultatu patikimum¡ uºtikrina irodomojoprogramavimo (angl. proofs-as-programs) metodas [142, 90, 74]. I² pradºiu jinaudojant buvo kuriamos nesudetingos programos, atliekan£ios skai£iavimuspagal automatizavimo irankio i²vestas formules [170, 175, 142]. Veliau bu-vo analizuojamos ivairiu logiku ir tipu teoriju savybes, bei ju taikymo ²iammetodui galimybes.

Per pastaruosius penkerius metus vel pastebimas padidej¦s mokslininkususidomejimas automatizuoto programu kurimo procesais naudojan£iais teoremuirodymus konstruktyviosiose logikose [142, 152]. Ypa£ akcentuojama tokiumetodu svarba kuriant dideles apimties (angl. industrial-scale) programin¦irang¡.

Paºangiu programu generavimo metodu savybiu pritaikymas komponenteiparadigmai galetu ne tik sumaºinti kurimo proceso trukm¦ bet ir uºtikrintikuriamos programines irangos kokyb¦.

ios disertacijos tyrimu sritis yra komponentiniu programu sistemu surinki-mo i² komponentu proceso automatizavimas.

1.2. Tyrimu objektas

Disertacijos tyrimu objektas programu sistemu automatizuoto surinkimoi² komponentu uºdavinys.

1.3. Tyrimu tikslas ir uºdaviniai

Tyrimu tikslas sudaryti deduktyviosios sintezes metod¡ komponentinemsprogramoms kurti atsiºvelgianti i strukturines komponentu savybes ir nepriklau-santi nuo konkretaus komponento modelio i² nagrinejamos komponentu klases.Tikslui pasiekti sprendºiami ²ie uºdaviniai:

• I²tirti programiniu komponentu savybes ir komponentiniu programu ku-rimo proceso ypatumus;

20 1 skyrius. Ivadas

• I²analizuoti programu sintezes ir generavimo metodus ivertinant ²iu me-todu taikymo galimybes komponentinems programoms kurti;

• Pasiulyti komponentiniu programu surinkimo i² gatavu komponentu pro-ceso automatizavimo metod¡;

• Siekiant eksperimenti²kai patikrinti komponentiniu programu surinkimoproceso automatizavimo metod¡ sukurti ir ivertinti ji realizuojan£ios sis-temos prototip¡.

1.4. Ginamieji disertacijos teiginiai

• Programu sintezes uºdavinys ir jo sprendimo budas gali buti taip su-formuluotas apibendrinto komponento modelio terminais, kad gautassprendinys gali buti pritaikomas kiekvienam i² apibendrintu komponentumodeliu panaudojant konkretizavimo, patikslinimo ir papildymo operaci-jas.

• Curry-Howard protokol¡ galima taikyti automatizuotam komponentiniuprogramu kurimui ir tokiu budu gauti specikacij¡ atitinkan£ias progra-mas.

1.5. Tyrimo metodai

Analizuojant mokslinius ir eksperimentinius pasiekimus komponentines pro-gramines irangos kurimo srityje naudoti informacijos paie²kos, sisteminimo,analizes, lyginamosios analizes ir apibendrinimo metodai.

Programinio komponento modeliui sudaryti naudoti klasterizavimo ir eksper-tinio vertinimo metodai. Klasterizavimo tikslas sudaryti komponento modeliugrupes, stebeti, pagal kuriuos poºymius modeliai galetu buti grupuojami. Klas-terizuota komponento modeliu savybiu ir komponento abstrakcijos lygmenulenteles interpretuojant kaip kategoriniu kintamuju aib¦. Atstumams matuotiparinktas Euklido atstumo kvadrato matas. Klasterizavimas atliktas statistinesanalizes programa SPSS 16.0. Kadangi klasterizavimo metodas negarantuo-ja, jog yra apibendrinamos tapa£ios s¡vokos, rezultatai patikslinti ekspertiniovertinimo metodu.

Realizuojant Curry-Howard protokol¡ komponentinei paradigmai naudotasmatematinio modeliavimo metodas. Atliekant komponentiniu sistemu generav-imo metodo eksperimentini vertinim¡ naudoti eksperimento ir apibendrinimometodai.

1.6. Mokslinis naujumas 21

1.6. Mokslinis naujumas

Darbe gauti ²ie nauji moksliniai rezultatai:

• Pasiulyta, kaip abstrahuojantis nuo konkre£iu komponentu modeliu irju savybiu, programu generavim¡ vykdyti naudojant abstra£iojo pro-graminio komponento modelio terminus;

• Siekiant uºtikrinti komponentiniu programu atitikim¡ specikacijai, pa-siulyta naudoti Curry-Howard protokol¡ ir strukturines programu sin-tezes algoritmus automatizuotam programu kurimui naudojant progra-minio komponento modeli;

• Numatyta keliu programu generavimo metodu integravimo galimybe.

1.7. Praktine darbo reik²me

Praktiniu poºiuriu disertacijos rezultatai reik²mingi del ²iu prieºas£iu:

• Siulomas metodas igalins pagerinti komponentiniu programu sistemu koky-b¦ bei sutrumpinti ju kurimo ir atnaujinimo laik¡;

• Metod¡ realizuojanti SoCoSyS sistema gali buti tiesiogiai naudojamasistemoms generuoti i² .NET komponentu. Taip pat del metodo univer-salumo, SoCoSyS sistema yra lengvai pritaikoma ivairiems komponentomodeliams.

1.8. Rezultatu aprobavimas ir publikavimas

Tyrimu rezultatai buvo pristatyti ir aptarti ²iose respublikineje mokslinesekonferencijose:

1. 2003 m. rugpju£io 29 d. Vienuoliktojoje mokslineje kompiuterininkukonferencijoje skaitytas prane²imas Komponento modelis strukturinesprogramu sintezes kontekste,

2. 2003 m. birºelio 20 d. respublikineje LMD konferencijoje skaitytasprane²imas tema Programu sistemu automatizuoto surinkimo i² gatavukomponentu uºdavinys,

3. 2003 m. birºelio 18 d. respublikineje LMD konferencijoje skaitytasprane²imas tema Komponento specikacijos formalizavimas,

4. 2004 m. birºelio 18 d. XLV-ojoje respublikineje LMD konferencijojeskaitytas prane²imas tema Komponento specikacijos formalizavimas,

22 1 skyrius. Ivadas

5. 2005 m. sausio 26 d. respublikineje konferencijoje Informacines tech-nologijos 2005 skaitytas prane²imas tema .NET komponento specikaci-ja programu sintezes kontekste,

6. 2005 m. birºelio 20 d. XLVI-ojoje respublikineje LMD konferencijojeskaitytas prane²imas tema Komponentiniu programu strukturines sin-tezes teorines problemos,

7. 2006 m. birºelio 20 d. XLVII-ojoje respublikineje LMD konferenci-joje skaitytas prane²imas tema Induktyvinis metodas komponentiniuprogramu sintezeje,

8. 2007 m. rugpju£io 14 d. Tryliktojoje mokslineje kompiuterininku konfer-encijoje skaitytas prane²imas Generavimo metodu panaudojimas kuriant.NET komponentines programu sistemas,

9. 2009 m. rugsejo 26 d. Keturioliktoje mokslineje kompiuterininku konfer-encijoje skaitytas prane²imas Modelines architekturos naudojimas kuri-ant komponentines programu sistemas.

Tarptautinese mokslinese konferencijose ir kituose renginiuose:

1. 2004 m. rugpju£io 10 d. Tarptautineje vasaros mokykloje ESSCSS'04(Estonian Summer School in Computer and System Science) skaitytasprane²imas tema Formal specication of .NET component,

2. 2004m. spalio 14 d. XLV-ojoje Rygos Technikos universiteto tarp-tautineje mokslineje konferencijoje skaitytas prane²imas Component mod-el and its formalisation for structural synthesis,

3. 2005 m. rugpju£io 9 d. tarptautineje vasaros mokykloje ESSCSS'05(Estonian Summer School in Computer and System Science) skaitytasprane²imas tema An application of SSP method to component-baseddevelopment process,

4. 2005 m. rugsejo 27 d. tarptautineje mokslineje konferencijoje GPCE'05(Generative Programming and Component Engineering) skaitytas prane²i-mas tema Component-based Software Generation: The Structural Syn-thesis Approach,

5. 2006 m. liepos 3 d. tarptautineje mokslineje konferencijoje Baltic DB&IS'06skaitytas prane²imas tema Architectures of Component-Based Struc-tural Synthesis Systems,

6. 2006 m. rugpju£io 7 d. tarptautineje vasaros mokykloje ESSCSS'06(Estonian Summer School in Computer and System Science) skaitytas

1.9. Disertacijos struktura 23

prane²imas tema Component-based Software Synthesis: the union oftwo methods,

7. 2008 m. lapkri£io 29 d. XIV-jame Lietuviu mokslo ir kurybos simpozi-ume skaitytas prane²imas tema Grid tinklo panaudojimas programinesirangos sintezei.

Tyrimo rezultatai publikuoti 7 straipsniuose recenzuojamuose Lietuvos ºur-naluose, 3 straipsniuose uºsienio ºurnaluose ir tarptautiniu konferenciju darbu-ose bei 1 straipsnyje kituose Lietuvos leidiniuose. I²samus publikaciju s¡ra²aspateiktas A priede.

1.9. Disertacijos struktura

Disertacij¡ sudaro 6 skyriai Pirmasis skyrius yra ivadinis. Jame glaustaiapra²oma tyrimu sritis ir aktualumas, tyrimo objektas, tikslas ir uºdaviniai.Taip pat pateikiamas ir skaitytu prane²imu disertacijos tema s¡ra²as.

Antrajame skyriuje pristatoma tyrimo problema. Analizuojama kom-ponento modeliu ir komponento abstrakcijos lygmenu ivairove. Apra²omakomponentu ir komponentiniu programu sistemu kurimo specika, analizuoja-mas tokiu programu sistemu kurimo uºdavinys, identikuojami probleminiaikomponentiniu programu sistemu gyvavimo ciklo etapai.

Tre£iasis skyrius analitinis. Jame analizuojamos deduktyviosios, in-duktyviosios, transformacines programu sintezes ir kiti generavimo metodai.

Ketvirtajame skyriuje apra²oma komponentiniu programu sistemu gen-eravimo metodika. Pirmiausia formalizuojamas programinio komponento mod-elis. Komponentinei paradigmai realizuojamas Curry-Howard protokolas, at-skleidºiamas strukturines sintezes ir kitu programu sintezes metodu pritaiko-mumas komponentinems sistemoms kurti automatizuotu budu.

Penktasis skyrius eksperimentinis. Jame apra²oma SoCoSys sistemair jos darbo rezultatai generuojant komponentines programas i² konkre£iukomponentu aibes. Sistema palyginta su kitomis komponentiniu programukurimui skirtomis sistemomis.

e²tajame skyriuje pateikiamos i²vados.

2 skyrius

Komponentiniu programu

sistemu kurimo proceso

samprata ir modeliai

Butina sekmingo programu sistemu kurimo proceso prielaida yra ai²kusproblemines srities identikavimas. io skyriaus tikslas i²tirti programiniukomponentu savybes ir komponentiniu programu kurimo proceso ypatumus.

Pirmiausia (2.1. poskyryje) supaºindinama su komponento s¡voka, anal-izuojama komponento modeliu ivairove. 2.2. poskyryje apra²omi komponentoabstrakcijos lygmenys.

Komponentiniu programu sistemu inºinerijoje skiriamos dvi ²akos: kompo-nentu kurimas ir komponentiniu sistemu kurimas. Kiekviena ²iu ²aku yra pris-tatoma atskiruose poskyriuose (2.3. ir 2.4. atitinkamai), ypa£ daug demesioskiriant sistemu kurimui. Apra²oma komponentu ir komponentiniu programusistemu kurimo specika, analizuojamas tokiu programu sistemu kurimo uº-davinys, identikuojami probleminiai komponentiniu programu sistemu gyvav-imo ciklo etapai.

2.1. Komponento modeliai

Komponento modelis apibreºia komponento strukturines ir dinamines savy-bes, apra²o komponento realizavimo, komponavimo, diegimo standartus [187].Paprastai kiekviena koponentine technologija remiasi vis kitu komponento mod-eliu. Komponento modeliu ivairove pastebima ir akademiniuose komponentiniuprogramu sistemu kurimo metoduose. io skyriaus poskyriuose nagrinejamikonkretus komponento modeliai siekiant identikuoti ju pana²umus ir skir-tumus. Dauguma nagrinetu programinio komponento modeliu poskyriuoseivardijami juos sukurusiu mokslininku grupiu vardais. Taip daroma del ²iu

2.1. Komponento modeliai 25

prieºas£iu:

• dauguma komponento modeliu neturi konkre£iu pavadinimu, ar registruotuprekiniu ºenklu (angl. trademark),

• skirtingus komponento modelius charakterizuojan£iu savybiu aibe yrapernelyg plati, kad j¡ butu galima glaustai ivardinti poskyrio antra²teje.

2.1.1. Szypersky modelis

Pla£iausiai naudojamos programinio komponento apibreºties autorius C.Szypersky komponent¡ apibreºia taip [159]:

Programinis komponentas komponavimo vienetas turintis kontraktaisspecikuotus interfeisus bei ai²ki¡ priklausomyb¦ nuo konteksto. Programiniskomponentas gali buti paskirstytas nepriklausomai ir yra skirtas tre£iuju

²aliu naudojimui.

C. Szypersky apibendrindamas daugiausia komercinius komponento modelius(tokius kaip COM, CORBA, JavaBeans) i²skiria ²iuos komponento bruoºus[158, 159]:

• Komponentai skirstomi i elementarius ir sudetinius. Elementarus kom-ponentas (pvz., Java JAR, .NET Assembly) apima dvi dalis: moduliir resursus. Sudetiniai komponentai sudaryti i² elementariu ir (arba)sudetiniu komponentu.

• Komponentai gali buti skirstomi ir atsiºvelgiant i ju nepriklausomum¡.Lengvu komponentu laikomas daug priklausomybiu turintis komponen-tas. Tuo tarpu sunkus komponentas yra beveik arba visi²kai nepriklau-somas.

• Vykdymo metu i² tiesu naudojami objektai, o ne komponentai. Kon-struojant sudetinius komponentus, fakti²kai sukuriamas vidiniu kompo-nentu sujungimo grafas, pagal kuri vykdymo metu (run-time) yra for-muojamas sudetinis komponentas. Ta£iau kiekvien¡ vykdymo iteracij¡gaunamas vis kitas konkretus sudetinis komponentas.

• Priklausomybiu tarp komponentu grafas privalo buti be ciklu.

• Komponentai neturi i²saugomos ilgalaikes busenos.

• Komponentai gali komunikuoti dviem budais: tiesiogiai per ivykiu mech-anizm¡ arba per tarpin¦ programin¦ irang¡ (CORBA ORB, .NET Frame-work ir pan.).

Konkre£iu komponento modeliu abstrakcijos lygmenu C. Szypersky i²reik²tiniubudu nei²skiria, daugiausiai koncetruojamasi i komponentinio objekto lygmeni.

26 2 skyrius. Komponentiniu programu sistemu kurimo proceso samprata ir modeliai

2.1.2. UNU/IIST modelis

Jungtiniu Tautu Universiteto (United Nations University) Tarptautinis pro-gramines irangos technologiju institutas (International Institute of SoftwareTechnology) nuo 2000 metu vykde projekt¡ II/1/1/5 Formal Methods for Ob-ject and Component Systems, kurio tikslas pasiulyti formaliuosius metodusobjektinems ir komponentinems sistemoms kurti [174].

S. Meng ir B. K. Aicherning [119, 120] komponentus formaliai apibreºiakaip koalgebras, nes koalgebru teorija tinka dinaminems sistemoms apra²yti,kai sistemos busenu erdve yra paslepta ir gali buti stebima tik i² i²ores. Todelkomponentas suprantamas kaip trejetas:

〈Up, α : Up → T (Up), uO ∈ Up〉 (2.1)

kur Up yra galimu busenu aibe, α funkcija U → T (U) kei£ianti komponentobusen¡, u0 pradine busena, o

TI,OB = A×B(Id×O) (2.2)

ia I ir O yra aibes, atliekan£ios interfeisu vaidmeni ir savo ruoºtu gali butiapibreºtos kaip konkre£ios koalgebros. A yra stebimos reik²mes (atributai), Id identikiatorius, o B nusako konkretu komponento elgsenos ²ablon¡.Komponentai skirstomi i aktyvius (galin£ius realizuojanti lygiagre£i¡sias veik-las) ir pasyvius (realizuojan£ius nuoseklias veiklas).2003 m. J. He, Z. Liu ir X. Li [78] apra²o komponento modeli ir Komponen-tinio skai£iavimo (Component calculus) specikavimo kalb¡. Nagrinejamoskomponento, kontrakto ir interfeiso s¡vokos. Interfeisas nusakomas pora: I =〈FDec,MDec〉 , kur FDec yra lauku, o MDec operaciju apra²u aibes. Na-grinejami tik teikiami interfeisai, reikalaujamu interfeisu nera.kontraktas nusakomas ketvertu:

Ctr = 〈I, FV al,MSpec, Init〉 , (2.3)

kur I yra interfeisas, FV al funkcija visiems interfeiso laukams suteikiantipradines reik²mes, MSpec funkcija atvaizduojanti kiekvien¡ interfeiso op-eracij¡ i jos specikacij¡, Init inicializavimo funkcija. Norint parodyti, kadinterfeise gali buti ir vidiniu, pasleptu, operaciju, kontrakto s¡voka praplesta:

GCtr = 〈Ctr, PriMDec, PriMSpec〉 , (2.4)

kur PriMDec ir PriMSpec yra atitinkamai vidiniu operaciju apra²ai ir funkci-ja atvaizduojanti juos i specikacij¡.Apra²ant komponent¡ daroma prielaida, kad jis realizuoja tik vien¡ interfeis¡.


Jei komponentas realizuoja daugiau interfeisu, tai jie pagal darbe [78] nusaky-tas taisykles yra agreguojami ir toliau traktuojami, kaip vienas interfeisas.Komponent¡ sudaro trejetas:

〈I,GCtr, ImportedMDec〉 , (2.5)

kur ImportedMDec yra kitu komponentu operacijos reikalingos uºtikrinti apra-²omojo komponento funkcionalum¡.2005 m. ta pati mokslininku grupe paskelbe darb¡ [79], kuriame daugiaukalbeta ne apie atskirus komponentus, bet apie ju sistemas. Parodyta butinybeapra²yti ne tik komponentu funkcionalum¡, bet ir nefunkcines savybes. I²skir-tos tokios specikuotinu komponentu savybiu grupes:

• interfeisai (sintaksinis lygmuo);

• funkcines savybes;

• dinamika (lygiagretumas, sinchronizavimas);

• komunikavimo protokolai;

• ribojimai (vykdymo laiko ar kitu resursu).

Pastebima, kad galimi keli poºiuriai i komponentines sistemas:

• kaip i architekturin¦ (statin¦) sistem¡;

• kaip i s¡veikaujan£i¡ (angl. behavior) sistem¡;

• kaip i paºingsniui vystom¡ (angl. renement) sistem¡.

Siekiant apjungti ²iuos poºiurius siuloma apjungti kelet¡ skirtingu teoriju:

• horizontalia kryptimi: funkcionalumo tikslinimo (angl. state-based func-tional renement), ivykiais grindºiamo s¡veikos imitavimo (angl. event-based interaction simulation), realaus laiko, atsparumo (angl. fault-tolerance), apsaugos, mobilumo ir bendrojo kokybes uºtikrinimo (angl.Quality of Service QoS ) teorijas;

• vertikalia kryptimi: dalykines srities analizes ir reikalavimu rinkimoteorijas, sistemu surinkimo i² komponentu, komponentu kurimo ir kompo-nentu i²destymo (angl. deployement) teorijas.

Pristatomas Bendrosios programavimo teorijos [83] pagrindu sukurtas perra²y-mu skai£iavimas rCOS, leidºiantis ne tik specikuoti objektines bei kompo-nentines sistemas, bet ir tas specikacijas tikslinti. Siulomame skai£iavime(rCOS) galima atlikti objektiniu konstrukciju (angl. designs) strukturines ir


2.1 pav. UNU/IIST komponentine sistema. Parengta pagal [163].

elgsenos transformacijas. Dar detaliau rCOS nagrinejamas velesniame J. He,X. Li ir Z. Liu darbe [77].Darbe [79] teigiama, kad komponentas neturi reikalaujamu interfeisu ir neturibusenos (kaip ir interfeisas). Be to, komponentas turi buti nepriklausomas nuosavo aplinkos.

X. Chen grupe [35] papildo darbuose [79, 78] apra²yt¡ komponento modeliproceso modeliu, apra²ydami komponentu tarpusavio jungimosi savybes, iriveda jungian£iojo kodo bei procesu s¡vokas. Komponentin¦ program¡, anotX. Chen [35], sudaro komponentu ²eima (angl. family) ir keletas procesu. Daliskomponentu yra paimti i² saugyklos, o kita dalis gaunama jungiant procesusir komponentu operacijas.

P. Thai ir D.V. Hung [163] apibendrina UNU/IIST darbus ir pastebi, kadrCOS turi trukumu: nera priemoniu lygiagretumui ir paveldejimui apra²yti. Jusiulom¡ komponento modeli sudaro: konstrukcija (angl. design), kontraktas,interfeisai ir komponentai. Konstrukcija apibreºiama kaip pora:

〈α, FP 〉 (2.6)

kur α operacijos naudojamu kintamuju aibe, FP Bendrojoje programavimoteorijoje [83] naudojama operacijos specikacija:

FP : p ` R ≡ ok ` p⇒ ok′ ∧R (2.7)

kur p, R atitinkamai operacijos prie² ir po s¡lygos, ok ir ok′ loginiai kin-tamieji rodantys operacijos gyvybingum¡: ok = TRUE, jei operacija starta-vo, o ok′ = TRUE, jei ji baigesi.

Darbe [163] ivedama reikalaujamo interfeiso s¡voka ir papildomos interfeiso,kontrakto ir komponento sampratos. Be to, tiek kontraktai, tiek interfeisai


skirstomi i bendruosius ir sisteminius. Taip skirstoma atsiºvelgiant i tai, kadP. H. Thai ir D. V. Hung siulomame modelyje komponentin¦ sistem¡ sudarodvieju ru²iu komponentai: aktyvusis ir pasyvusis. Aktyvuji komponent¡ su-daro reaktyvus procesai, kurie reaguoja i i²orinius (sistemos atºvilgiu) ivykiusnaudodami pasyviojo komponento paslaugas. Pasyvusis komponentas ²iek tiekprimena komponento konteinerius (pvz.: EJB ar CORBA). Ivedama uºdarojokomponento s¡voka [163]. Uºdaruoju komponentu laikomas sudetinis kompo-nentas, kuris nebeturi reikalaujamu interfeisu, t.y. visi reikiami komponentaijau ijungti.

Pasyvusis komponentas apra²omas pora 〈Ctr,Mcode〉, kur Ctr kompo-nento kontraktas, Mcode operaciju realizacija.

Komponento kontraktas, lyginant su [79, 78], pakeistas atsisakant atributureik²miu inicializavimo funkcijos FV al ir ivedant invariantus (Invp, Invr) beiprotokol¡ Pro, nusakanti leistinas operaciju kvietimo sekas:

Ctr = 〈I, Init,MSpec, Invp, Invr, P ro〉 . (2.8)

Protokolas Pro specikuojamas naudojant CSP kalb¡.Sisteminis kontraktas sudarytas i² keturiu elementu:

SysCtr = 〈SI, SMSpec, Inv,Behav〉 , (2.9)

kur Inv invariantai (nebeskirstomi i teikiamu ir reikalaujamu paslaugu,nes sisteminis interfeisas yra tik teikiamu paslaugu interfeisas); Behav i²orineselgsenos apra²as, baigtinis aibes

e,m|e ∈ E,m ∈ Smdp (2.10)

poaibis ( £ia Smdp baigtine operaciju aibe). Kiekvienas ²io poaibio elementas proceso specikacija.

Komponento interfeisas I apra²omas, kaip teikiamu ir reikalaujamu interfeisujunginys 〈Ip, Ir〉, o Sisteminis interfeisas apra²omas visi²kai kitaip, pabreºiant,kad jis skirtas reaguoti i i²orinius ivykius:

SI = 〈E,Fd, Smdp〉 (2.11)

kur E baigtine ivykiu, i kuriuos reaguojama, aibe, Fd ir Smdp savybiu iroperaciju aibes atitinkamai.Aktyvusis komponentas dar turi ir Sistemini kontrakt¡

SysCtr : 〈Ctr, SysCtr,Mcode〉 . (2.12)

Be prie² ir po s¡lygu [163] dar siuloma ivesti galimas paslaugu kvietimosekas, tai nurodant s¡veikos protokol¡. Paslaugomis £ia vadinama prieiga prie


duomenu arba operacijos. 2007 m. paskelbtas darbas [36], kuriame apiben-drinami grupeje atlikti moksliniai tyrimai ir diskutuojama butinybe naudotimodelin¦ paradigm¡ MDA. Darbe kalbama ne tik apie programini, bet irapie aparatini (angl. hardware) komponent¡, kuriam apra²yti naudojamos tospa£ios s¡vokos. 2009 m. pateiktas metod¡ realizuojantis, Eclipse aplinkos pa-grindu veikiantis komponentiniu sistemu modeliavimo irankis rCOS Modeler.

2.1.3. UMM modelis

Unied Metamodel (UMM) komponento modelis yra projekto UniFrame[173, 144, 73] rezultatas. Projekto tikslas sukurti efektyvu karkas¡ patiki-moms komponentinems i²skirstytoms sistemoms kurti. Vykdant projekt¡ buvosiekiama:

• sudaryti komponentu, ju ry²iu, kontraktu ir ribojimu metamodeli,

• siekiant uºtikrinti tarpusavio operacini suderinamum¡ (angl. interoper-ability), automati²kai generuoti tarpininkus (angl. glue and wrappers),atsiºvelgiant i specikacijas

• pateikti elementariu ir sudetiniu komponentu specikavimo ir kokybestikrinimo bendruosius reikalavimus.

UMM modelyje komponentas apra²omas trimis konceptais: objektas, paslaugair bendradarbiavimas (angl. collaboration).Kiekvienas objektas nusakomas trimis aspektais:

• skai£iuojamuoju,

• s¡veikos,

• papildomu (apima mobilum¡, apsaug¡, atsparum¡ klaidoms).

Kiekviena klase turi universaluji interfeis¡ (UI) apra²anti visu aspektu savybesbei pasiºyminti reeksijos savybe. Velesniame darbe [72] UMM komponentomodelis palygintas su .NET ir pasaulinio tinklo paslaugu komponentu modeli-ais, papildytas dar ir kontrakto s¡voka.

2.1.4. Fractal modelis

Mokslinio projekto Fractal tikslas sukurti modulini, ple£iam¡, neprik-lausom¡ nuo programavimo kalbos komponento modeli, skirt¡ sistemu projek-tavimui, realizacijai ir konguracijos keitimui [56]. Fractal komponento mod-elis kuriamas laikantis turniu atskyrimo principo.


2.2 pav. FRACTAL komponento modelis [56].

Fractal komponento modelyje [24] yra nagrinejamas vykdomasis kompo-nentas (angl. run-time entity). Komponent¡ sudaro:

• Interfeisai. Kiekvienas interfeisas apra²omas ²iomis charakteristikomis:

tipas (ar interfeisas yra teikiamu paslaugu, ar reikalaujamu),

operaciju aibe,

darna (angl. consistency) (nusako ar operacijos privalo buti atlik-tos (angl. mandatory), ar ne (angl. optional)).

kardinalumas ( nusako kiek kreipiniu i t¡ pati interfeis¡ kompo-nentas gali aptarnauti).

• Turinys (angl. content) baigtine vidiniu komponentu aibe.

• Membrana palaiko interfeisus komponentu perºiurai ir vidiniu savybiuperkonguravimui. Turi vidinius, i²orinius interfeisus ir valdymo elemen-tus leidºian£ius sustabdyti, patikrinti ir atlikti kitus veiksmus su kompo-nento vidiniais komponentais (sub-komponentais).

• Valdymo ta²kai. Fractal komponento modelyje galimi trys kontroleslygmenys:

1 lygmuo juodosios deºes. Elementarus komponentai (angl. basecomponents) kuriuos apklausti ar itakoti nera jokios galimybes.

2 lygmuo komponento interfeiso. io lygmens komponent¡ galimaapklausti, ta£iau negalima jo itakoti.


3 lygmuo leidºia itakoti visk¡. Skiriami keturi valdymo elementutipai: atributu valdymo, jung£iu, turinio (igalina papildyti sudetinikomponent¡ vidiniais komponentais arba juos pa²alinti), gyvavimociklo valdymo.

Pagrindines Fractal komponento modelio ( 2.2 pav.) savybes yra ²ios:

• rekursyvumas komponentai gali buti kitu komponentu vidiniais kom-ponentais,

• reeksija komponentai gali stebeti kitu komponentu ir savo pa£iugalimybes.

• bendro komponentu naudojimo galimybe komponento egzemplio-rius (angl. instance) gali buti naudojamas daugiau nei vieno komponen-to.

• jung£iu komponentai angl. (binding components) inkapsuliuoja betkoki (asinchronini ir sinchronini) komunikavim¡.

• nepriklausomybe nuo vykdymo modelio (angl. execution modelindependance) realizacijoje gali buti naudojamas tiek klasikinis giju,tiek ivykiais gristas, tiek kuris nors kitas modelis.

• atvirumas nefunkcines komponento savybes gali buti kei£iamos permembran¡.

Programos architektura apra²oma sudetinio komponento konstravimo taisyklemisir jungtimis (angl. bindings), kurios dar skirstomos i elementari¡sias (jomistiesiog sujungiami interfeisai) ir sudetines (komunikavimui dar naudojama vienaar daugiau tarpiniu jung£iu (angl. stubs, skeletons, adapters) ).Apibreºiami komponentai, galintys kurti naujus komponentus. Jie vadinamikomponentu gamyklomis (angl. component factory). Skiriamos dvi komponentugamyklos ru²ys:

• bendros paskirties,

• konkretaus tipo.

2.1.5. PECOS modelis

20002002 metais vykdytas projektas PECOS: Pervasive Component Sys-tems (IST-1999-20398), kurio tikslas pritaikyti komponentin¦ paradigm¡iterptinems (angl. embedded) sistemoms kurti, realizuoti aplink¡ leidºian£i¡specikuoti, komponuoti, tikrinti konguracij¡ ir i²skirstyti komponentines


iterptines sistemas [61].PECOS projekte operuojama aparatiniais-programiniais komponentais (angl.eld device), kurie apra²omi kaip interfeiso ir savybiu paketo pora. Savybiupakete nurodomos nefunkcines komponento savybes, tokios kaip laiko, at-minties ar kt. resursu naudojimas. Aparatinio-programinio komponento in-terfeis¡ sudaro prievadu s¡ra²as. ia prievadas suprantamas kaip bendrainaudojamas (angl. shared) kintamasis, leidºiantis komponentams keistis in-formacija. Prievad¡ charakterizuoja: vardas, tipas, reik²miu sritis ir kryptis.Prievado kryptis gali buti in, out arba inout ir parodo, kad kintamasis galibuti tik ra²omas, tik skaitomas arba ir ra²omas ir skaitomas atitinkamai [129].Prievadai jungiami naudojant jungtis,kurios i² esmes realizuoja prievadu ben-dro naudojimo ry²i.Komponentai skirstomi i tris grupes:

• Pasyvieji komponentai neturi valdymo elemento. Jie tik vykdo kitukomponentu komandas. Daºniausiai naudojami veiksmams, kurie vyk-domi sinchroni²kai ir greit baigiasi.

• Aktyvieji komponentai turi valdymo element¡. Naudojami ilgalaikemsveikloms realizuoti.

• Ivykiu komponentai suveikia tik ivykus numatytam ivykiui. Daugiau-sia naudojami aparatiniams komponentams modeliuoti.

Sudetinis komponentas apra²omas pora 〈C,P 〉, kur C ji sudaran£iu kom-ponentu s¡ra²as, o P prievadu s¡ra²as [61, 129]. Prievadai skirstomi ii²orinius ir vidinius. I²oriniai prievadai gali buti naudojami komponent¡ jun-giant i kitas sistemas, o vidiniai yra i² i²ores neprieinami, naudojami tik vidini-ams sudetinio komponento komponentams komunikuoti. Tokia sudetinio kom-ponento architektura rodo, kad PECOS projekte naudojamas surenkamasisprogramavimas, t.y. visa vykdymo logika inkapsuliuota i pa£ius komponentus,kokiu nors atskiru jungian£iuju daliu nera.

2.1.6. UML komponento modelis

J. Cheesman ir J. Daniels daugiausiai demesio skiria dideles apimties verslo(angl. enterprise-scale) komponentu specikavimui. Darbe [34] teigiama, kadegzistuoja keturios komponento formos:

1. komponento specikacija (atskirai aptariamas dar ir komponento inter-feiso vaidmuo ²iame lygmenyje, 2.2 lentele);

2. komponento realizacija;

3. idiegtas komponentas;


2.1 lentele Komponento ir jo interfeiso specikaciju palyginimas [34].komponento specikacija Interfeiso specikacijaInterfeisu s¡ra²as. Operaciju s¡ra²as.Apra²o skirtingu interfeisuinformaciniu modeliu priklau-somybes.

Apra²o logini informacini modeli.

Nusako kontrakt¡ su realizuotoju. Nusako kontrakt¡ su naudotoju.Apra²o realizacijos ir vykdymo (an-gl. run-time) vienet¡.

Apra²o, kaip operacijos itakojainformacini modeli arba nuo jo prik-lauso.

Apra²o operaciju realizacij¡ kituinterfeisu terminais.

Apra²o lokalu poveiki.

4. komponento objektas.

komponentu nelaikomas klasikinis objektas (nes komponento objektas galiveikti tik komponentines sistemos kontekste) ar paslauga. Skiriami du kon-trakto tipai:

• Naudojimo kontraktas, kuris sudaromas tarp komponento objektu vyk-dymo metu. Jis apra²omas interfeiso specikacijoje. Naudojimo kontrak-t¡ apra²o operacijos (sintakse, prie² ir po s¡lygos) ir informacinis modelis(abstraktus bet kokios informacijos tarp kliento ir komponento objektoapra²as, ribojimai tai informacijai).

• Realizavimo kontraktas, kuris sudaromas tarp komponento specikaci-jos ir komponento realizacijos. Apra²omas komponento specikacijoje iryra jos dalis.

J. Cheesman ir J. Daniels komponentin¦ architektur¡ apra²o kaip aib¦ taikomujuprogramu lygmens (angl. application-level) komponentu, ju strukturiniu ry²iuir elgsenos priklausomybiu (angl. behavior dependences). Elgsenos priklau-somybes gali buti ²ios:

• interfeisas →1 interfeisas;

• komponentas → interfeisas;

• komponentas → komponentas;

• vidinis komponentas → komponentas.

1ºenklu → ºymimas s¡ry²is priklauso nuo.


Komponento realizacijos lygmens architekturoje gali buti komponentu, ne-paminetu komponento specikacijoje, be to komponentai gali papildomai s¡vei-kauti.

Darbe [34] teigiama, kad gali egzistuoti keletas alternatyviu komponentoobjekto lygmens architekturu. Pvz., vieno komponento objekto funkcionalum¡gali uºtikrinti keletas skirtingu komponento objektu rinkiniu.

2.1.7. Poernomo grupes modelis

Darbe [146] pagrindinis demesys skiriamas sudetiniu komponentu kurimui,todel tipinis komponento modelis ple£iamas konstrukcijomis, egzistuojan£iomispramonineje tarpineje programineje irangoje.komponento modeli [146] sudaro:

• Kenai (angl. kens) - architekturines esybes. Papras£iausi kenai yra kom-ponentai nagrinejami kaip juodosios deºes. Kenai gali buti ir sudetiniai.

• Vartai (angl. gates) - saugo kenus. Papras£iausiu suderinamu vartupora nusako jungti. Vartus apra²o: paslaugu signatura (angl. signature),vartu protokolas, nefunkciniai paslaugu atributai.

• Jungtys yra dvieju tipu: saistymai (angl. bindings) (naudojamos su-jungti teikiamas ir reikalaujamas paslaugas) ir atitiktys (angl. mapping) naudojamos sujungti tik teikiamas paslaugas.

• Kontraktus igyvendinan£ios esybes (angl. contractual supliers):komponentai, objektai, operacijos. Pastebesime, kad ju invariantai galibuti s¡lyginiai: po s¡lyga priklauso nuo prie² s¡lygos ir atvirk²£iai.

Komponetu grupes veikia tik tam tikrame kontekste [141]. Kiekvienas kompo-nentas reikalauja paslaugos arba j¡ teikia. I. Poernomo grupes nagrinejamiemskomponentams budingos busenos, todel Component-FSM kalba komponentaiapra²omi taip:

Ctr = 〈Ec, Ac, Zc, δc, Fc, z0c〉 , (2.13)

kur Ec ivykiu aibe, Ac veiksmu aibe, Zc komponento busenu aibe, δc busenos keitimo funkcija (Z × E × AZ), Fc leistinu busenu aibe, z0c -pradine komponento busena. Kaip teigiama [146], toks modelis leidºia i² ankstoivertinti komponentiniu architekturu patikimum¡.


2.1.8. Cervantes modelis

H. Cervantes darbe [28] pagrindinis demesys kreipiamas dinaminiam pakei£i-amumui, t.y. daroma prielaida, kad ne visada paslaug¡ teikiantis komponentasyra pasiekiamas.H. Cervantes apibreºt¡ komponent¡ su i²ore sieja ²ie elementai:

• Teikiamos ir reikalaujamos paslaugos, kurias charakterizuoja darketurios savybes:

Kardinalumas, nusakantis ar priklausomybe privaloma ir nuo keliu(vienos ar daugelio) kitu paslaugu priklauso nagrinejamos paslau-gos.

Politika, nusakanti sudetinio komponento dinami²kum¡. Esantstatinei politikai, komponentine programa vis¡ gyvavimo laik¡ ne-sikei£ia, t. y. nekei£iami susiejami komponentai. Jei politikadinamine, susiejami komponentai gali keistis ir sistema gali butiperkonguruota).

Filtras, nusakantis taisykles, pagal kurias atrenkami komponentaiprogramu sistemai.

Susiejimo (angl. bind/unbind) budai.

• Igyvendinimo priklausomybes, pvz., nuo vykdymo aplinkos.

• Veiksnumas (tinkamumas). Pradºioje visi komponentai startuoja suveiksnumo poºymiu invalid ir ²is poºymis pakei£iamas i valid tik tuoatveju, jei visos priklausomybes patenkintos.

Komponento gyvavimo ciklui palaikyti naudojamas specialus konteineris (an-gl. instance manager).

2.1.9. Salzmann modelis

C. Salzmann [148] nagrineja i²skirstyt¡sias sistemas, kaip aib¦ paslaugasteikian£iu ir ju reikalaujan£iu komponentu, kurie komunikuoja per jungtis (an-gl. bindings). Darbe apra²omas komponento modelis nusakomas ²iais elemen-tais:

• Interfeisas dvikryptis kanalas apibreºiantis prane²imu tipus.


• Paslauga tai elgsenos vienetas. Kiekviena paslauga apra²oma trejetu〈if ∈ IF, beh,NS ⊆ S〉, kur if interfeisas i² interfeisu aibes IF ; beh juodosios deºes elgsenos apra²as; NS reikalaujamu paslaugu aibe;∀ns ∈ NS, ²i paslauga turi savo interfeis¡ ifns ∈ IF .

• Saistymo jungtis (angl. binding) tai ry²ys b tarp dvieju paslaugu:b ∈ B = S×S. Jungtimi susiejama vieno komponento teikiama paslaugasu kito komponento reikalaujama paslauga.

• Tranzakcija baigtine prane²imu tarp susietu paslaugu seka.

• komponentas apra²o tik struktur¡, kaip paslaugos yra realizuotos irsugrupuotos, todel jo sudetines dalys yra teikiamu ir reikalaujamu paslauguaibes, bei interfeisu aibe. Komponentas gali tureti vidiniu komponentu.

• Vykdymo vieta (angl. sandbox ) i²reik²tiniu budu adresuojama kompo-nentu buvimo vieta (konkretus kompiuteris arba tinklas).

• Konguracija (kitaip, technine architektura) komponentu, susietupagal ju teikiamas ir reikalaujamas paslaugas aibe. Tam pa£iam tiksluipasiekti gali buti keletas skirtingu konguraciju. Konguracija kei£ia-ma arba pridedant/²alinant jungti, arba perkeliant komponent¡ i kit¡vykdymo viet¡.

Komponentams specikuoti C. Salzmann [148] naudoja XML kalbos pagrindusukurt¡ SADL (Service Architecture Description Language) kalb¡.

2.1.10. Berger grupes modelis

K. Berger grupes siulom¡ komponento modeli sudaro ²ie elementai [19]:

• komponentas;

• interfeisas;

• jungtys tarp interfeisu. I²skiriama, kad jung£iu kardinalumas gali butinebutinai vienetinis, t.y. galimos tipo vienas-prie-daug ir kt. jungtys;

• laiko srautas naudojamas komponento elgsenai ksuoti ir apra²yti;

• konguracijos istorija apra²o komponentin¦ sistem¡ ir parodo, kaipkei£iasi sistema vykdymo metu: Conf = 〈I,K,Cn〉, kur I - interfeisu,K komponentu, o Cn jung£iu aibes atitinkamai. Jei komponentas, in-terfeisas ar jungtis yra pa²alinama i² sistemos, jie negali buti vel ivedami.Pa²alinus komponent¡ automati²kai pa²alinami ir jo vidiniai elementai,bei jungtys, jungian£ios t¡ komponent¡ su kitais;


• prane²imu sekos. Skirstomos i interfeiso ir komponento prane²imusekas. Gaunamu komponento prane²imu seka:

IfIn = M∗ × (Cn→M) (2.14)

siun£iamu komponento prane²imu seka:

IfOut = (Cn→M∗)×M∗ (2.15)

Gaunamu interfeiso prane²imu seka:

CompIn = I →M∗ (2.16)

siun£iamu interfeiso prane²imu seka:

CompOut = I →M∗ (2.17)

K. Berger grupes modelyje daug demesio skiriama komponentu ir ju sistemuelgsenos kitimo laike tyrimams.

2.1.11. Aguirre ir Maibaum modelis

N. Aguirre ir T. Maibaum darbe [4] komponentai suprantami kaip sistem¡sudarantys skai£iavimu vykdymo ar duomenu saugojimo strukturiniai vienetai.Komponentai skirstomi i bazinius ir sudetinius. Baziniai komponentai yranedalomi, turi atributais nusakom¡ busen¡. Jie apibreºiami trejetu:

〈Rv,At,Ac〉 , (2.18)

kur Rv specialus ieities atributai, kuriu komponentas nekontroliuoja, bet nau-doja informacijai apie aplinkos busen¡ gauti, At atributai busenai nusakyti(kitaip, lokalus kintamieji), Ac veiksmu aibe, specikuojanti komponentoelgsen¡.

Sudetiniai komponentai sudaromi i² baziniu ir sudetiniu, juos susiejantjungtimis. Jie dar vadinami posistememis, jas suprantant kaip sudedamujukomponentu konguracijas, kurios gali buti dinami²kai kei£iamos. Taigi, posiste-miu veiksmai ne tik kei£ia komponentu atributu reik²mes, bet ir modikuojasavo vidin¦ struktur¡ (pvz., sukuriami ar naikinami komponentu egzemplio-riai) bei komponentu s¡veik¡ (pvz., ²alinami jung£iu egzemplioriai). Jei dukomponentai yra sujungti, ju elgsenos yra susijusios jungties tipo s¡lygojamubudu.

Pagrindinis demesys [4] darbe skiriamas dinami²kai perkonguruojamu kom-ponentu specikavimo kalbai. Parodoma, kad komponentai gali buti speci-kuojami naudojant ²iuos elementus:


• bazinius duomenu tipus,

• bazinius komponentu tipus,

• jung£iu tipus,

• sudetiniu komponentu tipus.

Specikacijas sudaro keli hierarchi²kai organizuoti sluoksniai - nuo duomenutipu iki posistemiu architekturu specikaciju.

2.1.12. Nierstras, Lumpe ir Schneider modelis

J. G. Schneider [149] apra²om¡ komponento modeli sudaro ²ie elementai:

1. komponentai,

2. scenarijai (angl. scripts), skirti vykdymo logikai realizuoti ir komponen-tinei sistemai konguruoti,

3. jungiantysis kodas, skirtas komponentu adaptavimui,

4. koordinuojantysis elementas (komponentu konkurencija valdyti).

Modelyje komponentine programa apibreºiama taip:

komponentine programa = komponentai + scenarijai

Ypatingas demesys skiriamas antrajai dedamajai, t.y. jungian£iojo pro-graminio kodo (JPK) s¡vokai. Skiriamos ²ios JPK grupes:

• pakikliai (angl. wrappers). Inkapsuliuoja visas apgaubiamojo kompo-nento komponento operacijas ir teikia jo teikiamas paslaugas. Gaubtaidar skirstomi i dvi grupes:

1. adapteriai susieja nesuderinamus interfeisus, pvz., kei£ia operaci-jos parametru tvark¡;

2. trasformatoriai naudodami protokolu nesuderinamumui minimizuoti;

• tiltai (angl. bridges) vieno komponento reikalaujamas prielaidas ver£ia ikito komponento teikiamas prielaidas; juos gali kviesti ir specialus i²orinisagentas, kuris nebutinai yra vienas i² s¡veikaujan£iu komponentu;

• igaliotieji tarpininkai (angl. proxies) nutolusiu komponentu suro-gatai (pvz., CORBA stubs, skeletons ir pan.);


• mediatoriai (angl. mediators). Apima adapteriu bei transformatoriusavybes, ta£iau nuo tiltu skiriasi tuo, kad mediatorius turi planavimofunkcij¡, kuri nustato skirtumus. Pvz.,

(D0 → D1 +D1 → D2)⇒ D0 → D2.

Darbe [149] nurodomi reikalavimai, kuriuos turi tenkinti JPK:

1. skaidrumas (JPK egzistavimas turi buti i²ori²kai nepastebimas),

2. juodos deºes principas,

3. komponuojamumas (projektavimo metu),

4. strukturos dvidali²kumas (turi buti kei£iamoji ir pastovioji dalys),

i mokslininku grupe daugiau analizuoja komponentu ir juos sudaran£iuobjektu, bet ne komponentiniu sistemu specikavimo galimybes [128]. Speci-kavimui naudojamas algebrinis metodas ir πL bei PICOLLA kalbos.

2.1.13. Yoshida ir Honiden modelis

K. Yoshida ir S. Honiden [190] nagrineja vizualiuosius granes vartotojos¡sajos komponentus (JavaBeans ir ActiveX/COM). Autoriu teigimu kompo-nent¡ nusako ²ios savybes:

〈In,Rn, Ic,Rc,O,Exp,M〉 (2.19)

kur In komponento ivestis (gaunami duomenys, komandos ir pan.), Rn komponento atsakas ivesti, Ic komponento i²vestis nukreipta i dukteriniuskomponentus, o Rc - dukterinio komponento atsakas, O komponento darborezultatas (angl. Output), Exp prane²imai apie i²imtis (angl. exceptions),M komponento operaciju aibe. Kiekviena komponento operacija m ∈ Mapra²oma ketvertu: m = 〈Inm, Om, P reP, PostP 〉, kur Inm ir Om - operacijosivestis ir rezultatai atitinkamai. Taip pat naudojamos ir prie²proceso PreP beipostproceso PostP s¡vokos. Prie²procesas apdoroja duomenu sraut¡ i² kom-ponento ivesties Ic i dukterinio i²vesti komponentui Ic. Postprocesas apdorojaduomenu sraut¡ prie²inga kryptimi, t.y. i² dukterinio komponento atsako Rci paties komponento atsak¡ Rn.

Komponentai specikuojami algebriniu metodu. Darbe [190] ivardijami ²iereikalavimai specikacijai:

1. komponentu komponavimas beciklio medºio struktura turi buti apra²o-mas termu;


2. komponento rezultatas (angl. output) ir atsakas (angl. return) turi butigaunami kartu, kaip termo perra²ymo, atitinkan£io vykdym¡, rezultatas;

3. neapibreºtumai turi buti ai²kiai i²reik²ti;

4. turi buti nustatytos s¡lygos, kada lygybes tampa teisingomis.

K. Yoshida ir S. Honiden [190] i²skiria ²iuos komponento konstravimo budus:

• Agregavimas (angl. putChild). Komponentas inkapsuliuoja kit¡ kompo-nent¡.

• Komponavimas (angl. compose). Komponentai (tiksliau ju ivestys iri²vestys) jungiami laisvai, sudarant medºio, tinklo ar kt. strukturas.

• Nuoseklus jungimas (angl. Sequental). Komponentai jungiami nuosek-liai, t.y. vieno komponento i²vestis yra kito ivestis, medºio tipo ir kitoshierarchines strukturos neleistinos.

• Pakeitimas (angl. substitute) Vienas komponentas kei£iamas kitu.

• Rekursinis kreipinys (angl. repeat). Komponentas kvie£ia pats savo op-eracij¡.

• Parametrizavimas (angl. customize). Vienas ar daugiau komponentupateikiami kitam kaip parametrai, t.y. istatomi i i² anksto numatytasvietas. Pvz., taip ple£iamas taikomuju programu funkcionalumas spe-cialiais priedais (angl. Add-ins).

2.1.14. Lau grupes modelis

Komponento modelio svarba ypa£ akcentuojama K.-K. Lau vadovaujamosgrupes [98, 97] darbuose. Pastebima, kad komponento modelis sudaro semantinikarkas¡ ne tik komponentui apibreºti, bet ir nusakyti, kaip jis turi buti sukon-struotas, sukomponuotas ir kaip samprotauti apie visas operacijas su kompo-nentais.

Komponento modelis apibreºia ²iuos aspektus [100]:

• komponento sintaks¦ - ju konstravimo ir vaizdavimo taisykles;

• semantik¡, nusakan£i¡ kas yra komponentais;

• komponavim¡ - kaip jungiami i sudetinius.

Daugumoje dabartiniu komponento modeliu komponentams apra²yti nau-dojamos programavimo kalbos, taip pat IDL, ADL kalbos. Komponentais galibuti laikomi: klases (JavaBeans, EJB), objektai (COM, CCM, FRACTAL),


architekturiniai vienetai (Koala, SOFA). Komponent¡ apra²o teikiamu ir reika-laujamu paslaugu interfeisai. Komponentai, taip pat ir ju kompozicijos neturibusenos.

K.-K. Lau irM. Ornaghi darbe [99] pabreºia, kad kai komponentas supran-tamas kaip juoda deºe, jo interfeisas turi uºtikrinti vis¡ naudotojams reiki-am¡ informacij¡. Taigi, pasinaudoti komponentais leidºiama tik per interfeis-us, kurie pateikia informacij¡ apie operacijas ir kontekstines priklausomybes.Komponentai apibreºiami dalykinese srityse, kitaip - kontekste. Kontekstasnusakomas sukuriant pirmos eiles login¦ teorij¡, kur kontekstas Ctx apra²omaspora 〈Σ, X〉. Signatura Σ apima ru²iu simbolius, funkciju ir ry²iu deklaracijas,o rekursyvi Σ aibe X nusako dalykin¦ sriti ir leidºia samprotauti apie j¡.

Darbe [82] nagrinejama komponentinio karkaso (angl. framework) s¡vo-ka. Karkasu £ia vadinama grupe s¡veikaujan£iu objektu (ne komponentu! ).Karkas¡ apra²o:

• Klasiu aibe C. Klases operacijos vadinamos parametrizuotais atributais(kaip Catalysis projekte). Kiekvienai klasei specikuojamas jos savybius¡ra²as funs ir predikatu aibe pred.

• Ivykiu aibe M . Kiekviena operacija m ∈ M apra²oma trejetu m =〈C, T, L〉, kur T papildomi parametrai, o L - laikas.

• Faktu (ribojimu) aibe F . ia surinkti ribojimai gai buti ir lokalieji irglobalieji, todel tinka visiems invariantams, o Prie² i Po s¡lygos apra²o-mos kartu su ivykiais.

Nagrinejamos komponentiniu karkasu funkciju prapletimo galimybes panau-dojant kit¡ karkas¡.

2.1.15. Cox ir Song modelis

P.T. Cox ir B. Song komponentines sistemas apra²o taikydami tiesiniovamzdyno (angl. pipeline) metafor¡ [41]. Komponentas apibreºiamas korteºuX, kuris gali buti sudarytas i² skirtingu elementu. Programiniai komponentaiklasikuojami taip:

• komponentas-siustuvas apibreºiamas vieninteliu korteºo elementu teikiamu atributu seka outports(X).

• komponentas-imtuvas apibreºiamas vieninteliu korteºo elementu - gau-namu atributu seka inports(X).

• Elementarus komponentas kitaip dar vadinamas ltru. Jis apra²omas²iuo korteºu

X : 〈inports, outports, f, t〉 , (2.20)


kur outports atributas, inports atributu korteºas f funkcijos, t trigeriai. Funkcijos nusako komponento funkcionalum¡ ir turi toki pavi-dal¡ f : τ(a1)×τ(a2)× . . .×τ(an)→ τ(outports)), kur τ(ai) apibreºia aitip¡. Trigeriu egzistavimas parodo, kad ltras yra aktyvusis reaguoja iivykius. Atributai nusako prievadus, per kuriuos komponentai s¡veikaujatarpusavyje.

• Sudetinis komponentas apibudinamas ²iuo korteºu

X : 〈K, In,Out, Con〉 , (2.21)

kur K komponentu aibe, In ir Out skirtingu atributu sekos, Rel ry²iu tarp vidiniu komponentu atributu aibe. Con - jung£iu aibe. Jungtissudaro portu poros.

P.T. Cox ir B. Song komponento modelyje nesigilinama i komponentiniusistemu realizacines datales. Komponento modelis nagrinejamas auk²tame ab-strakcijos lygmenyje.

2.1.16. Moschoyiannis modelis

S. Moschoyiannis darbuose [123, 96] pagrindinis demesys skiriamas kom-ponento ir ji sudaran£iu elementu semantikos apra²ymui. Todel pateikiamasformalus programinio komponento modelis, kuris dar yra naudojamas sampro-tavimui apie komponentus ir ju kompoziciju savybes.

Darbe [123] pastebima, kad daugelis komponentiniu technologiju palaikogreit¡ programu sistemu surinkim¡ i² komponentu, ta£iau rezultato kokybepaai²keja tik sukurus sistem¡. Tai nera priimtina, todel autorius siekia rezul-tato kokyb¦ uºtikrinti kurimo metu, t. y. reikiam¡ sudetinio komponentoelgsen¡ gauti pasirenkant tinkamos elgsenos sudedamuosius komponentus. Ki-taip tariant, teigiama, kad apjungus komponentus, kurie tenkina reikiamassavybes, sudetinis komponentas taip pat tenkins reikiamas savybes. Analizuo-jant sudedamuju daliu kombinaciju savybes ir jungimo pasekmes, remiamasiformalia sudetinio komponento apibreºtimi ir ivestomis s¡lygomis, kuriu tuributi prisilaikoma komponavimo procese. Be to, komponavimas semantiniamelygmenyje leidºia i²spr¦sti komponento pakeitimo kitu tinkamu komponentuproblem¡ pakei£iantysis komponentas turi uºtikrinti buvusio komponentofunkcionalum¡.

Komponentas apibreºiamas nurodant jo ru²i ir elgsen¡ nusakan£iu vektoriuaib¦, t. y. pora (Σ, B) [123, 96]. komponento ru²is Σ apibreºiama trejetu(PΣ, RΣ, βΣ), kur:PΣ ⊆ I teikiamu interfeisu aibe, RΣ ⊆ I reikalaujamu interfeisu aibe, oβΣ(i) i²vardintu interfeisuose, kvietimu seku aibe, kurios poaibis, susij¦s su


interfeisu i ºymimas βΣ I²nagrinejus komponentu modeliavim¡ (CSP, CCS, SO-FA ir pan. priemonemis) darbe [123] daroma i²vada, kad norint apra²yti kom-ponent¡, butina apra²yti jo s¡veikos (angl. behavior) protokol¡, t. y. apra²ytigalimas operaciju kvietimo sekas. Todel komponento dinamines savybes speci-kuojamos apibreºiant aib¦ VΣ, kurios elementai v(i) vadinami elgsenos vek-toriais ir priklauso baigtiniu seku, kurias galima sudaryti i² aibes βΣ elementu,aibei, t. y., VΣ : IΣ → Op, tokia, kad kiekvienam i ∈ IΣ, v(i) ∈ βΣ(i)∗ (* ºymibaigtin¦ sek¡), tada B ⊆ VSigma.

Komponentas turi tenkinti eil¦ savybiu. Pirma, jo operaciju kvietimo sekuaibe turi buti diskreti, t. y. jei B - diskreti, tai ir komponentas (Σ, B) laiko-mas diskre£iuoju. Komponentu diskretumas garantuoja, kad laiko atºvilgiunera begaliniu didejan£iu ar maºejan£iu ivykiu seku; kad nera trukiu (angl.gaps) laiko kontinuume; kad yra pradinis ta²kas, kuriame dar nera ivyk¦ neivieno ivykio. Antra, siekiama, kad kiekvieno komponento elgsenoje butu bentvienas egzempliorius bet kuriam jo interfeisu operaciju kvietimo atvejui. Taiuºtikrinama, jei komponentas tenkina lokalaus uºdarumo s¡lyg¡. Jei kom-ponentas yra diskretus ir lokaliai uºdaras (angl. locally left closed) tada jisvadinamas normaliu.

Elgsenos apra²¡ (angl. behavior representation) sudaro keturiu elementujunginys: (O,Π, E, λ), kur O ivykiu (angl. occurrence) aibe, Π ⊆ ρ(O) ne-tu²£ia ta²ku (busenu) aibe, E - ivykiu (events) aibe, λ : O → E ivykiu funkcijatenkinanti

⋃π∈Π(π) = O.

Jei komponentas yra diskreti²kas ir lokaliai uºdaras (angl. locally left closed)tada jis vadinamas normaliu.Kad komponentas c yra lokaliai uºdaras tada ir tik tada kai bet kokiemsu ∈ B, i ∈ IΣ ir x ∈ βΣ(i), tenkinantiems s¡lyg¡ Λ < x < u(i) egzistuojatoks v ∈ B, kad v < u ir v(i) = x komponento lokalus uºdarumas rei²kia,kad bet kokia operaciju kvietimo tvarka yra leistinu operaciju kvietimo sekos(pirminio elgsenos vektoriaus) poaibis. Komponent¡ galima keisti kitu tik ta-da, jei kei£iamojo komponento elgsenos vektorius yra kei£ian£iojo komponentoelgsenos vektoriaus poaibis, t.y. kei£iantysis komponentas siulo ne maºesnifunkcionalum¡ nei ankstesnysis.

2.1.17. Whitehead modelis

K. Whitehead [188] ivardija ²ias komponento interfeiso (pla£i¡ja prasme)apra²ymo savybes:

• interfeisus, kuriuos jis siulo klientus, iskaitant ir galimas i²imtis (angl.exeptions);

• reikalaujamus interfeisus, kuriuos turi tenkinti besikreipiantis paslaugosklientas


• reikalaujamus interfeisus, kuriuos turi tureti kiti (pagalbiniai) kompo-nentai.

Pastebima, kad interfeisai gali buti ir sinchroniniai ir asinchroniniai (galimakalbeti ir apie ivykius ivairiuose komponento modeliuose, EJB ºinu£iu kompo-nentus (angl. Message Driven Beans)).Taip pat pastebima, kad gali buti pateikiamos ir papildomos komponentucharakteristikos:

• busenos, pakartotiniai kreipiniai (angl. re-entrancy), galimybe aptarnau-ti daugiau nei vien¡ klient¡;

• ar komponentai gali naudoti t¡ pa£i¡ tranzakcij¡ ar reikalauja naujos irt.t.;

• ar komponentas ra²o duomenis i DB, failus ir ar ne;

• parametrizavimo galimybes, apsaugos savybes;

• reikalavimai operacinei sistemai, darbines atminties poreikiui ir t.t.

2.1.18. SCA modelis

Paslaugu komponento architekturos arba SCA (angl. Service ComponentArchitecture) modelis kuriamas nuo 2005 m. siekiant supaprastinti paslauguarchitekturos stiliaus programines irangos kurimo proces¡. Modelio kurim¡palaiko IBM, Oracle, BEA, SAP ir dar 14 imoniu.

Komponentams kurti gali buti naudojama bet kuri technologija. Pavyzdºiui,SCA stiliaus komponentai kuriami naudojant Java technologijas (EJB, JavaEE Connector Architecture bei Java Message Services), jie realizuoja pasauliniotinklo paslaugas [12]. Vienas i² SCA tikslu apibreºti komponentu jungimoi sudetinius mechanizm¡, taikom¡ visiems komponentams nepriklausomai nuoto, kokia technologija buvo sukurti sudedamieji komponentai. Tam SCA speci-kuoja apibendrinto komponento modeli.

SCA komponentas yra sukonguruotas realizacijos egzempliorius. Kompo-nento realizacija (angl. implementation) rei²kia konkre£ios technologijos ele-ment¡, toki kaip Java ar C++ klase, BPEL procesas, XSLT transformacija irpan. komponentas gali funkcionuoti viename procese viename kompiuteryjear buti i²skirstytas po kelis procesus keliuose kompiuteriuose. Sudetinis kom-ponentas vadinamas kompozicija (angl. construct) ir yra logine konstrukcija.Kompozicija turi ²ias savybes:

• naudojama kaip komponento realizacija nustato komponento matomu-mo ribas (nuorodos i² i²ores neleidºiamos);


2.3 pav. SCA komponento modelis [18].

• naudojama kaip išdestymo vienetas – yra SCA domeno (organizaciniovieneto kontroliuojamu paslaugu visumos) elementas.

Sudetines konstrukcijos (angl. assembly) modelis specifikuoja ją sudarančiuskomponentus, ju interfeisus (paslaugas) ir tarpusavio ryšius, kai komponen-tai paslaugas teikia vienas kitam. Sąveikai su išore nusakyti naudojamos šiosabstrakcijos: paslauga, nuoroda (angl. reference), savybe (angl. property)ir susiejimas (angl. binding) [12, 18]. Komponentu sąveika modeliuojamapaslaugomis. Komponentas ne tik teikia paslaugas, bet ir jomis naudojasi.Reikalaujamos paslaugos specifikacija vadinama nuoroda. Jungtis (angl. wire)yra ryšio tarp reikalaujamos paslaugos specifikacijos ir ją tenkinančios paslau-gos abstraktus pavaizdavimas. Kaip konkrečiai komponentas komunikuoja (ki-tais žodžiais tariant, kaip naudojamasi teikiamomis ir reikalaujamomis paslau-gomis) nurodo susiejimai, kuriu komponentas gali tureti ne vieną, t. y. jis galisąveikauti pagal kelis skirtingus protokolus. Komponentas turi vieną ar keliassavybes, kurios naudojamos jo realizacijai konfiguruoti.

2.1.19. Komponavimo formos

Komponavimo formos priklauso nuo konkretaus komponento modelio [1]ir išreiškia galimu sudetiniu komponentu ir komponentiniu sistemu kurimotaisykles.

Darbe [10] daugiausia demesio skiriama butent komponentu ir komponen-tiniu karkasu komponavimo formoms (2.4 pav.). Autoriai pateikia tokią jutaksonomiją:

a) komponento ikomponavimas (angl. deployement) (2.4 pav., a) – kompo-nentinio karkaso ir komponento sąveikos protokolas. Komponentas, ne-galintis su karkasu sąveikauti numatytuoju budu, nepriskiriamas konkreči-am komponento modeliui, kuri palaiko karkasas.


2.4 pav. Komponavimo formos [10].

b) Karkaso ikomponavimas (2.4 pav., b) dvieju ar daugiau karkasu sud-erinimas veikti kartu (angl. interoperability). Sudaro galimybes kurtiheterogenines sluoksnines (angl. tiered) sistemas [159].

c) Elementari kompozicija (2.4 pav., c) komponentu jungimas per kon-traktu apra²yt¡ interfeis¡. i komponavimo forma sutinkama daºniausi-ai.

d) Heterogenine kompozicija (2.4 pav., d) sudetingesnis heterogeniniusistemu kurimo atvejis kai ikomponuojamas ne tik kitas karkasas, betir pastarojo palaikomas komponentas.

e) Karkaso prapletimas (2.4 pav., e) karkaso galimybiu pletimas, jungiantji su naujais komponentais. Tokie komponentai daºniausia vadinami pa-pildiniais (angl. add-ins, plug-ins).

f) komponentu apjungimas ir sistemos surinkimas. (2.4 pav., f). Skirtingainei elementarios kompozicijos atveju vienas komponentas (pavyzdyje C3) gali agreguoti kit¡ (C2). Pirklausomai nuo komponento modelioagreguotasis komponentas yra i²ori²kai matomas arba ne [10].

Egzistuoja ir kitos komponavimo formu taksonomijos [190, 147]. Disertaci-joje neanalizuojamos heterogenines komponentiniu programu sistemos, todeltoliau bus taikomos tik elementarios kompozicijos bei komponentu apjungimoir sistemos surinkimo komponavimo formos.


2.2 lentele KM taksonomija pagal komponavimo kriteriju [100].Kategorija Komp. modelis DR RR CS DC CP1 JavaBeans Taip Ne Ne Ne Taip2 EJB, COM, .NET,

CCMTaip Ne Taip Ne Ne

3 Koala, SOFA, KobrA Taip Taip Taip Taip Ne4 Fractal, PECOS,

UMLNe Ne Taip Ne Ne

2.2. Komponento abstrakcijos lygmenys

Kaip mineta 2.1. skyriuje, komponentine paradigma pasiºymi pramoniniuir akademiniu programinio komponento modeliu gausa. I²sami visu ²iu modeliuanalize yra neimanoma, todel paprastai analizuojami tik charakteringi kom-ponento modeliu pavyzdºiai. Komponento modeliu savybiu analizei atrinkti irdisertacijos 2.1.1.2.1.18. poskyriuose apºvelgti tie komponento modeliai, kurieatstovauja tam tikroms komponento modeliu grupems, pagal ²ias taksonomi-jas:

• taksonomija pagal komponavimo kriteriju [100, 101]. Komponentomodeliai suskirstyti i keturias grupes (2.2 lentele). Skirstymas atliktaspagal ²iuos poºymius:

DR: komponentu saugykla (angl. repository) gali buti papildyta kurimometu gautais naujais komponentais,

RR: kurimo metu komponentai gali buti paimti (angl. retrieve) i² kom-ponentu saugyklos,

CS: komponavimas leidºiamas kurimo metu,

DC: komponentu saugykla gali buti papildyta kurimo metu gautais nau-jais sudetiniais komponentais,

CP: komponavimas leidºiamas i²destymo (angl. deployement) metu.

• objekto ir proceso taksonomija [110]. Komponento modeliai klasi-kuojama pagal tai ar ju komponentai isaugo savo vidin¦ busen¡ ar ne.

• M.C. Goulao taksonomija [70]. Komponento modeliai klasikuojamipagal ²iuos poºymius:

pagal komponento modelio kilm¦: pramoninis, akademinis ar mi²rus;

2.3. Komponentu kurimo procesas 49

pagal komponento s¡vokos vaizdavimo bud¡: komponentai-objektai,komponentai-klases, komponentai-architekturiniai vienetai;

pagal komponento apra²ymo kalb¡: objektine kalba, IL, ADL;

pagal komponentu saugyklos naudojimo bud¡;

pagal naudojamu kontraktu tipus;

pagal tai ar modelio komponentai sertikuojami;

pagal tai ar i²skiriama sudetinio komponento s¡voka ar ne;

• taksonomija pagal abstrakcijos lygmenis [34, 7]. Komponentaiskirstomi i ²ias grupes:

komponento specikacijos lygmenyje operuojama projektuojant in-formacines, arba programu sistemas. Taip pat ²is lygmuo budingasarchitekturos apra²ymo kalbu ADL [116] komponentiniams mod-eliams.

komponento realizacijos lygmenyje operuojama pagal specikacij¡sukurtais komponentais, ta£iau nekalbama apie ju veikim¡ ir veiki-mo palaikymui reikalingas priemones.

idiegto komponento lygmenyje nurodomos konkre£ios komponentopaskirties vietos, konguruojama jo vykdymo aplinka (pvz.: varduskyrimo tarnyba).

komponentinio objekto lygmuo aktualus jau komponentines siste-mos veikimo etapui, kada pagal konkre£ioje vietoje idiegto kompo-nento taisykles sukuriami objektai. Butent objektai ir realizuojaauk²tesniuose lygiuose deklaruot¡ funkcionalum¡.

Visos minetos taksonomijos naudotos komponento modeliams atrinkti, oviena ju komponentu klasikacija pagal abstrakcijos lygmenis naudojamair likusioje disertacijoje dalyje (2.3 lentele).

Konkre£iai, komponentiniu programu kurimo procesas ²ioje disertacijo-je nagrinejamas tik komponento specikacijos ir komponento realizacija lyg-menyse, nes butent ²ie lygmenys yra naudojami sistemu kurimo etape. Idiegtokomponento ir ypa£ komponentinio objekto lygmenys glaudºiai susij¦ su siste-mos veikimo etapu ir kurimo procesui yra maºiau aktualus.


2.3. Komponentu kurimo procesas

Komponentiniu sistemu kurimo procese skiriamas komponentu ir sistemukurimas [37, 7]. Daugeliu aspektu komponentu kurimas yra pana²us i sistemukurim¡. Ju gyvavimo ciklo modelis apima reikalavimu nustatymo, analizesir specikavimo, komponento projektavimo, realizavimo, testavimo, dokumen-tavimo ir i²skirstymo2 etapus. Kuriant komponentus, gali buti naudojami armodikuojami ir anks£iau sukurti komponentai. Ta£iau komponentu kurimasturi ²iuos savus ypatumus [37]:

• Komponentai kuriami tam, kad butu pakartotinai panaudotiivairiose programu sistemose, o tai apsunkina komponentu kurimo pro-ces¡. Komponentai privalo buti lengvai pritaikomi, konguruojami, delko dideja ju sudetingumas ir apimtis.Tuo pa£iu metu komponentai pri-valo buti ir pakankamai paprasti naudoti. Kaip teigia C. Szyperski [159],tam, kad sukurti pakartotinai naudojam¡ komponent¡, reikia 3-4 kar-tus daugiau resursu nei komponent¡, kuris bus naudojamas konkre£iojeprogramu sistemoje

• Sunku nustatyti komponento reikalavimus. Viena pagrindiniu pro-gramu kurimo problemu yra neai²kios, nei²samios ar net prie²taringosreikalavimu specikacijos. Komponentai (pagal apibreºti) gali buti nau-dojami skirtingose dalykinese sistemose, kuriu i²samus s¡ra²as i² ankstonera ºinomas, ir todel ju keliami reikalavimai negali buti net nuspejami.Komponentu kurimas yra ne toks sunkus tik tuo atveju, jei ju reikalav-imai i²lieka nekintantys palyginti ilg¡ laikotarpi. Augant komponentopanaudojamumo laipsniui, dideja ir jo paklausa, ple£iasi reikalavimu,kuriuos ²is komponentas turi tenkinti, aibe. Siekiant patenkinti nau-jus reikalavimus, kuriamos naujos komponento versijos (ta£iau butinaii²laikan£ios visas ankstesniu versiju kontraktu specikuotas savybes).Ypa£ sparti evoliucija budinga pirmosioms komponento versijoms [37].I² pradºiu komponentas yra ne toks abstraktus ir ne toks bendras, todelkuriant naujas versijas reikejo didesniu pakeitimu atnaujinimu. Tuotarpu paskesnes komponento versijos pasiºymi didesniu abstraktumu,todel ²iek tiek pasikeitus reikalavimas komponento keisti nereikia, ar-ba pakanka pakeisti neºymiai. Taigi, adaptavimo mechanizmus turintysapibendrinti komponentai yra naudingiausi. Kai komponentas prade-da nebetenkinti kuriamu sistemu keliamu reikalavimu ir ²ios problemosnebegali i²spr¦sti net naujos komponento versijos (pvz., pasikeitus tech-nologijoms, paradigmoms), sakoma, kad baigesi komponento gyvavimociklas ir jis toliau nebepalaikomas. Darbe [37] taip pat atkreipiamas

2angl. deployement.

2.4. Komponentiniu sistemu kurimo procesas 51

demesys i komponento ri²lumo uºtikrinimo problem¡, kai komponentedarant daug pakeitimu ri²lumas gali buti sumaºinamas.

• Komponentus butina itin tiksliai specikuoti. Tai ypa£ svarbu,nes komponento naudotojas yra ne jo gamintojas, o komponentas papras-tai parduodamas kaip juodoji deºe, be pradiniu tekstu. Be to, siekiantuºtikrinti kuriamu programu sistemu saug¡, visi komponentai turi butipatikimi (angl. trustworthy) [107].

komponentu kurimo procesas ²ioje disertacijoje nera i²samiai nagrinejamas.Apie komponentu kurimo proces¡ bus kalbama tik sudetinio komponento kurimokontekste.

2.4. Komponentiniu sistemu kurimo procesas

Komponentiniu programu sistemu gyvavimo cikl¡ sudaro ²ie etapai [37,151, 188, 181]:

1. Reikalavimu analize (angl. Requirements analysis and denition). i-ame etape vienareik²mi²kai nurodomos sistemos ribos. Komponentiniusistemu kurimo (KSK) procese ²iame etape analizuojamos ir komponentu,kuriu s¡veika (angl. collaboration) uºtikrintu kuriamosios sistemos funk-cionalum¡, specikacijos. Tam yra butina apibreºti sistemos infrastruktur¡.KSK proceso analizes etape sprendºiami trys uºdaviniai: sistemos reika-lavimu identikavimas ir sistemos ribu nustatymas, sistemos infrastrukturos,uºtikrinan£ios komponentu s¡veik¡ nusakymas, ir reikalavimu kompo-nentams identikavimas, pagal kuriuos butu galima juos pasirinkti arbasukurti.

2. Komponentu atranka ir ivertinimas (angl. selection and evalua-tion). Komponentiniu programu sistemu kurimo procese pabreºiamasne suprojektuotos sistemos ir jos daliu realizavimas, bet jau sukurtu juo-dosios deºes komponentu pakartotinis naudojimas. iame etape ie²komatinkamu komponentu, jei reikia, jie yra parametrizuojami ir vertinami.Taigi ²i etap¡ galima skaidyti i tris poetapius:

• komponentu paie²ka. Ie²kant komponentu reikia atsiºvelgti ne tiki ju funkcines, bet ir nefunkcines savybes. Kuriant komponentinessistemas viena didºiausiu problemu yra patenkinti kuriamos siste-mos nefunkcinius reikalavimus, ºinant (arba net neºinant) kokiusreikalavimus tenkina sudedamieji komponentai. Egzistuoja ivairiosnefunkciniu reikalavimu taksonomijos [38, 155, 88, 58]. Pagrindinesnefunkciniu reikalavimu grupes parodytos 2.3 lenteleje. Nefunkciniu


reikalavimu taksonomija yra glaudºiai susijusi su komponento ab-strakcijos lygmenimis, nes kiekviename lygmenyje yra svarbus tikkai kurie 2.4 lenteleje i²vardinti reikalavimai.

• komponentu konguravimas.

• komponentu testavimas.

3. Sistemos architekturos projektavimas Paºymetina, kad architekturospasirinkimas i² dalies priklauso ir nuo parinktu naudoti komponentu[37]. Pasak [151], ²iame etape taip pat atliekamas ir reikalavimu sistemaiivertinimas bei projektiniu sprendimu pasirinkimas.

4. Sistemos realizavimas Kuriant nekomponentines programu sistemas²iame etape akcentuojamas konstravimas (angl. construction), t. y.programinis kodas kuriamas nuo nulio, arba pakartotinai panaudoja-ma labai maºa dalis anks£iau sukurto kodo. Kuriant komponentinesprogramu sistemas akcentuojamas komponavimas. Komponavimui (an-gl. composition) budinga tai, kad galutinis produktas gaunamas parenkanti² anksto paruo²tus programinius komponentus ir juos sujungiant i vien¡sistem¡. Bendruoju atveju gali prireikti realizuoti ir jungiantiji kod¡ (an-gl. glue code), ta£iau visa tokio jungian£iojo kodo apimtis, nustatoma pa-gal pasirinkt¡ vertinimo metod¡ (LoC, FP ir pan.), turi nevir²yti bendrosnaudojamu komponentu apimties [188, 50]. Jungian£iojo programiniokodo kurimas paprastai reikalauja maºiau nei 50% visai sistemai kur-ti skirtu pastangu, ta£iau viena jungian£iojo kodo eilute sukuriama triskartus grei£iau nei kodo eilute, realizuojanti komponento funkcionalum¡[16].Komponentu komponavimas vienas i² budu surinkti sistem¡ i² juo-dosios deºes komponentu. Pagal komponavimo laik¡ nagrinejami du ²ioproceso atvejai:

• Komponavimas kurimo metu daºniausiai pasitaikantis atvejis.Komponentams jungti reikiami artefaktai kuriami arba specialiuirankiu, arba naudojant speciali¡ komponavimo kalb¡, arba tiesiogprogramavimo kalb¡, pvz. C# ar JScript.

• Komponavimas vykdymo (veikimo) metu. is komponavimo atve-jis dar vadinamas dinaminiu. Dinaminis komponavimas naudo-jimas: (a) kai reikia sukurti program¡, tenkinan£i¡ trumpalaikiusnaudotoju poreikius; (b) kai reikia pakeisti sistemos, turin£ios veik-ti nenutrukstamai (pvz., elektronines prekybos, klientu aptarnavi-mo), dali.

2.4. Komponentiniu sistemu kurimo procesas 53

5. Sistemos integravimas (angl. system integration). I² anks£iau pasi-rinktu gatavu komponentu, atsiºvelgiant pasirinkt¡ i sistemos architektur¡,sudaroma pati sistema. Darbe [151] pastebima, kad ²iame etape galimasir vienu komponentu keitimas kitais, jei paai²keja, kad parinktieji kom-ponentai netenkina sistemos reikalavimu. Tokiu budu gali buti griºtamai komponentu atrankos ir ivertinimo etap¡.

6. Sistemos tikrinimas ir vertinimas. Etapo tikslas - nustatyti, arsukurta programine iranga atitinka specikacij¡ (tikrinimas) ir ar pro-gramine iranga yra tinkama, t. y. tenkina naudotoju poreikius (vertini-mas) [37]. Tikrinimo etapas yra svarbus tuo, kad jame gali buti aptinka-mi atskiru komponentu nesuderinamumo atvejai, kuriu negalejo parodytikomponentu testavimas, atliekamas ankstesniuose etapuose.

7. Sistemos palaikymas. Etap¡ galima skaidyti i poetapius [151]: palaiky-mo strategijos rengimas, problemu valdymas ir ilgalaikis sistemos palaiky-mas.

Pastebetina, kad i komponentu atrankos ir ivertinimo etap¡ gali buti griºtamatiek i² sistemos tikrinimo, tiek i² palaikymo etapu. Pirmuoju atveju - paai²kejus,kad sistema netenkina nefunkciniu reikalavimu, antruoju - pasirodºius naujomskomponentu, karkasu ar operaciniu sistemu versijoms.

Komponentiniu programu sistemu gyvavimo ciklas (KPSGC) yra ypatin-gas tuo, kad palyginti su klasikiniu programu sistemu gyvavimo ciklu, kei£iasietapu svarba ir trukme:

• komponentu atrankos etapo svarba padideja. Tiek programu sistemoskokybe, tiek kurimo i²laidos tiesiogiai priklauso nuo ²iame etape pasirinktukomponentu savybiu. Kaip jau mineta, kuriant sistem¡ nauji komponen-tai nekuriami. Tiesa, darbe [151] pateiktame gyvavimo ciklo modelyjenumatytas ir komponentu kurimo etapas, ta£iau toks poºiuris prie²ta-rauja komponentines paradigmos procesu atskyrimo principui ir ²iojedisertacijoje nebus nagrinejamas.

• Realizavimo etapo svarba ir trukme sumaºeja. Idealiu atveju sistemaisukurti pakanka vien pakartotinai naudojamu komponentu. Jei kompo-nentai nevisi²kai atitinka reikalavimus, jie konguruojami arba kuriamasnedideles apimties jungiantysis programinis kodas.

Pastebetina, kad komponentu atrankos, sistemos projektavimo, realizavi-mo bei sistemos integravimo etapai iteratyviai kartojami (2.7 pav.) tol, kolprogramu sistema maksimaliai tenkins ne tik funkcinius bet ir nefunkcinius


reikalavimus. is gyvavimo ciklas dar vadinamas I²rink-Pritaikyk-Bandyk (an-gl. Select-Adapt-Test) ciklu [37].komponentiniu programu sistemu kurimo procese pabreºiamas ne suprojektuo-tos sistemos ir jos daliu realizavimas, bet jau sukurtu komponentu pakartotinisnaudojimas [37]. is ypatumas turi ²iuos trukumus:

• pirmiausia butina rasti komponentus (pakartotinai naudojamus elemen-tus), atitinkan£ius sistemos reikalavimu specikacij¡ ir sistemos projek-tinius sprendimus;

• reikalingos papildomos pastangos siekiant adaptuoti i² dalies tinkantikomponent¡, patikrinti jo patikimum¡ ir pan.

2.5. Skyriaus i²vados 55

2.5. Skyriaus i²vados

Apibendrinant skyriu galima daryti ²ias i²vadas:

1. Komponento modeliu ivairove yra veiksnys, apsunkinantis automatizuot¡komponentiniu programu sistemu kurimo proces¡:

1.1. Apºvelgus komponento modelius, reprezentuojan£ius ºinomas mo-deliu klases, nustatyta, kad jiems apra²yti i² viso naudojamos 28s¡vokos. Kiekvienas modelis apra²omas naudojant nuo 3 iki 12s¡voku.

1.2. Komponentines programos gaunamos naudojant skirtingas kom-ponavimo formas. Kurios butent formos yra naudojamos, priklausonuo komponento modelio ir jo abstrakcijos lygmens.

1.3. Skiriami keturi komponento abstrakcijos lygmenys. Disertacijo-je nagrinejami specikacijos ir realizacijos lygmenu komponentai.Idiegto komponento ir komponentinio objekto lygmenys ²ioje dis-ertacijoje nenagrinejami, nes idiegto komponento ir komponentinioobjekto lygmenys glaudºiai susij¦ su sistemos veikimo etapu ir kurimoprocesui yra maºiau aktualus.

2. I²analizavus programiniu komponentu savybes ir komponentiniu programukurimo proceso ypatumus nustatyta:

2.1. Pagrindiniai komponentu kurimo proceso ypatumai yra ²ie: kom-ponentai kuriami tam, kad butu panaudoti daugiau nei vien¡ kart¡;jie kuriami neºinant, kokie reikalavimai jiems bus keliami konkre£iosesistemose; komponentu specikacija ir dokumentacija turi buti tik-sli ir i²sami.

2.2. Komponentiniu programu sistemu kurimo procesas, kuriame akcen-tuojamas ne suprojektuotos sistemos ir jos daliu realizavimas, betjau sukurtu komponentu pakartotinis panaudojimas turi trukumu:nei²spr¦stas detalios komponentu paie²kos uºdavinys; komponentuadaptavimui reikalingos papildomos s¡naudos.


2.5 pav. Komponento modeliu elementai.

57

2.3 lentele Komponento abstrakcijos lygmenys.Komponentomodeliai

Komponentospecikacija

Komponentorealizacija

Idiegtaskomponen-tas

Komponen-tinis objek-tas

Apperly + + + -Szypersky + - + +UNU/IIST + - - -UMM(Uniframe)

+ - - +

FRACTAL + + - -PECOS + - - -UML + + - +Poernomo + - - -Cervantes + - + -Salzmann + + - -Berger + - + +Aguirre irMaibaum

+ - + -

ObjectWeb + - - +Nierstrasz,Lumpe,Schneider

- - - +

Yoshida,Honiden

+ - + -

Lau grupe - - - +Cox ir Song + - - -Whitehead + + + -Moschoyiannis + - - -


2.6 pav. Komponento kurimo etapai.

2.7 pav. Komponentiniu programu sistemu kurimo etapai.

59

2.4lenteleNefun

kciniaireikalavim

ai.Parengtapagal[165,38].

Aktualusplanavimoetapui

Aktualusprojektavimoetapui

Aktualusveikim

oetapui

•Atsparumas,robasti²kumas

Konceptualus

inte-

gralum

as

I²baigtumas

Ri²lumas/darna

•Prieinamum

as

Pardavimokaina.

Palaikymoka²tai.

Integravim

oka²tai

•Mobilu

mas

•Pakartotinis

panaud

ojam

u-mas

•Testuojam

umas

•I²ple£iamum

as

•Konguruo

jamum

as

•Mastelio

kei£iamum

as

•Su

derinamum

assu

kitomissis-

temom

is

•Sp

arta

Na²um

as

Atsakolaikas

Reikalaujam

uresursu

kiekis

•Patikimum

as

Pasiekiam

umas

Saugum

olygis

Atsparumas

gedimam

s

•Panaudo

jamum

as

3 skyrius

Programu sistemu generavimo

metodu lyginamoji analize

Automatinio programavimo terminas pradetas vartoti ne veliau kaip 1954 m.,kai buvo norima nusakyti pirmuosius Fortran kalbos kompiliatorius [17]. A²-tuntame XX a. de²imtmetyje generavimo metodais laikyti i²plestasis kompili-avimas (naudojamas SETL, RAPTS ir TAMPR [27, 25] sistemose), metapro-gramavimas (naudojamas ZAP, HOPE, CIP [53] sistemose). Todel programukurimo automatizavimas tradici²kai buvo suprantamas kaip kompiliavimo prob-lema, kai formali specikacija kompiliuojama siekiant gauti vykdom¡ pro-gram¡. Nepaisant nauju kalbu, kurimo metodu, irankiu atsiradimo, nuolatinisdemesys automatizavimui rei²ke, kad programu kurimas ir ²io proceso na²umasyra pagrindine kompiuteriniu sistemu kurimo problema. Kita vertus, programukurimas yra daugiau nei kompiliavimas. Tai apima ir specikaciju sudarym¡,ir ju teisingumo uºtikrinim¡, ir projektinius sprendinius, auk²to abstrakcijoslygmens specikacijas ver£iant i ºemesnio abstrakcijos lygmens specikacijas,ir pan. Taigi, automatinis kompiliavimas ilgainiui i²sivyste i automatizuotoprogramavimo paradigm¡ ir automatizuot¡ programu sistemu inºinerij¡ (angl.automated software engineering).

Skiriamos kelios automatizuoto programu sistemu kurimo kryptys priklau-somai nuo naudojamos ²io uºdavinio sampratos ir kurimo modelio. Pavyzdºiui,yra ºinomos, deduktyvi paradigma [153], ºiniomis grindºiama paradigma [93],modeliais grindºiama paradigma [138], o programu sistemu kurimo procesasivardijamas kaip generavimas, sinteze, transformacine realizacija, modeliaisgrindºiamas kurimas.

Nesiekdami ivesti i²samios taksonomijos pastebesime, kad vartojami ter-minai daºnai yra susij¦ su konkre£ios mokyklos tradicijomis. Ta£iau, ai²ku,pirmiausia jais siekiama pabreºti automatizuoto kurimo proceso ypatumus.Pavyzdºiui, terminas generavimas akcentuoja: a) automatizuot¡ rezultato gav-

3.1. Klasikiniai formalieji metodai 61

im¡, b) apibendrintu ruo²iniu naudojim¡, o terminas sinteze - sudedamujudaliu jungim¡ i vien¡ visum¡. Disertacijoje vartojamas terminas generavimas.Tuo norima ne pabreºti konkre£iu procesu ir metodu ypatumus, o apibendrintaiivardinti skirtingus automatizuoto kurimo metodus. Terminas sinteze vartoja-mas kaip termino generavimas sinonimas, kai siekiama prisilaikyti konkre£iojesrityje vartojamos terminijos.

io skyriaus tikslas i²analizuoti programu sistemu automatizuoto kurimometodus ivertinant ju taikymo galimybes komponentinems programu siste-moms kurti. Metodu analize pradedama programu sistemu inºinerijoje taikytuklasikiniu formaliuju metodu (3.1. poskyris) nagrinejimu. Toliau analizuoja-mi deduktyviosios (3.2. poskyris), strukturines (3.3. poskyris), induktyviosios(3.5. poskyris) ir transformacines sintezes (3.6. poskyris) metodai. Ypatingasdemesys skiriamas 3.4. poskyryje apra²omam irodom¡ji programavim¡ apiben-drinan£iam Curry-Howard protokolui.

3.1. Klasikiniai formalieji metodai

Klasikiniais formaliaisiais metodais ²ioje disertacijoje vadinami E. Dijkstra[48] ir C.A.R. Hoare [83] darbai, bei jais besiremiantys i²vestiniaiM.Charpentier[30], R.Backhouse [11] ir J.Schumann [152] metodai.

Fundamentaliame darbe [48] E. Dijkstra programavim¡ apra²o naudodamasdeterminuotos ma²inos abstrakcij¡. Tokiai ma²inai, kaip programos vykdymoposalyga (angl. post-condition) nusakomas predikatas, rei²kiantis programosgalutini tiksl¡ (t.y. kam suskai£iuoti programa yra skirta), kokioje busenojedeterminuotos ma²ina turi atsidurti. Turint galutin¦ programos busen¡ svar-bu ºinoti i² kokiu pradiniu busenu ji gali buti pasiekiama. Jei ma²in¡ gali-ma pervesti i vien¡ i² tokiu busenu, tai ai²ku, kad skai£iavimu rezultatas buspasiektas. Visu tokiu pradiniu busenu, garantuojan£iu, kad i² ju bus pasiektagalutine busena ir ma²ina galutineje busenoje pasiliks, aibe nusakoma silpni-ausia s¡lyga (angl. weakest precondition):

wp(S,R), (3.1)

kur S deterministine ma²ina, o R po s¡lyga (norimas rezultatas). Jeiwp(S,R) s¡lyga netenkinama, tai ma²ina gali sustoti kitoje nei R busenoje arbagali i² viso nebaigti darbo. Daºnai sprendºiant skai£iuojamuosius uºdaviniusvisos galimu pradiniu busenu aibes rasti nereikia, todel naudojama pakankamas¡lyga P , pasiºyminti savybe: P ⇒ wp(S,R).Silpniausia s¡lyga pasiºymi savybemis:

wp(S, F ) = F

62 3 skyrius. Programu sistemu generavimo metodu lyginamoji analize

∀Q = R : wp(S,Q) = wp(S,R)

(wp(S,Q) ∧ wp(S,R)) = wp(S,Q ∧R)

(wp(S,Q) ∨ wp(S,R)) ⇒ (wp(S,Q ∨R))

Sakoma, kad programos konstrukcijos S semantika ºinoma pakankamai gerai,jeigu ºinomas jos predikatu transformatorius (angl. predicate transformer), t.y.funkcija, i² bet kurios po s¡lygos R gaunanti silpniausi¡ s¡lyg¡ wp(S,R).E.W. Dijkstra pabreºia, kad bet kuri programavimo kalba turi dvi paskirtis:ma²inos vykdymui ir pa£iu programos kureju naudai, kad i² programos butugalima nustatyti predikatu transformatoriu. E.W. Dijkstra darbe [48] atsklei-dºia, kaip konstruojama programavimo kalba, kurios kiekviena konstrukcijaapra²oma per predikatu transformatoriu wp:

Priskyrimo sakinys: wp(“x := E“, R) = RE→x

Funkcine kompozicija: wp(“S1;S2“, R) = wp(S1, wp(S2, R))

S¡lyginis sakinys: wp(IF,R) = (B1 ∨B2 ∨ . . . ∨Bn) ∧(B1 ⇒ wp(SL1, R)) ∧(B2 ⇒ wp(SL2, R)) ∧ . . . ∧(Bn ⇒ wp(SLn, R))

Ciklas: wp(DO,R) = (Ek : k ≥ 0 : Hk(R))

kur Hk(R) silpniausia prie² s¡lyga, tam kad konstrukcija darb¡ baigtu nedaugiau kaip po k komandu i²rinkimo.

R. Backhouse darbe [11] apra²o formalu, sintaksini programu bei ju savybiugavimo (angl. calculation) bud¡. Teigiama, kad jis uºtikrina auk²£iausi¡imanom¡ programines irangos patikimum¡. Kaip vienas motyvacijos pavyzdºiupateikiamas dvejetaines paie²kos (angl. binary search) algoritmas, bei jo real-izacija Java kalba. Siekiama atskleisti programines irangos kurimo, naudojantformaliuosius metodus svarb¡.

R. Backhouse [11] apra²o skai£iuojam¡j¡ logik¡ (angl. calculational logic)su ekvivalentumo, neigimo, disjunkcijos, priskyrimo, praleidimo (angl. skip),silpninimo (angl. weakening), s¡lygos aksiomomis. Konstrukciju apra²ymuinaudojama C.A.R. Hoare notacija: PSR1 [83, 80]. Taip pat apra²omi kvan-toriai (3.1 lentele). ia simetrinio dvejetainio operatoriaus vienetu vadinama

1£ia S - operacija.


reik²me kuri¡ tuo operatoriumi sukomponavus su bet kuriuo x gauname x :1⊕ ⊕ x = x.

3.1 lentele Konstrukciju kalbos kvantoriai. Parengta pagal [11].Operatorius Vienetas Kvantorius Reik²me

∧ true ∀ konjunkcija∨ false ∃ disjunkcija+ 0

∑sudetis

× 1∏

daugyba↓ ∞ ⇓ minimumas↑ −∞ ⇑ maksimumas≡ true ≡ ekvivalencija6 ≡ false 6 ≡ neekvivalencija∪

⋃s¡junga

∩ U⋂

sankirta

R. Backhouse [11] parodo, kaip apra²yti pagrindines programavimo kalboskonstrukcijas: nuoseklu sakiniu jungim¡ (angl. sequent composition), s¡lygossakini, cikl¡. Pabreºiama, kad konstruojant programas labai svarbus konstruk-toriaus kurybi²kumas (angl. creativity element). Kiekviena formaliai apra²ytakalbos konstrukcija formaliai apra²o ir t¡ kurybi²kumo element¡. Pavyzdºiuis¡lygos sakiniu toks elementas yra sprendimas, kaip padalinti uºdavini i dalis;nuosekliame jungime kurybingumo elementas yra sprendimas, kokia tarpines¡lyga turi buti patenkinta, kai baigiamas vykdyti pirmasis sakinys; ciklo kon-strukcijose kurybingumo elementas tinkamos invarianto savybes projektas.

Darbe [30] vystoma komponuojamuju sistemu teorija. Daugiausia demesioskiriama komponavimo taisyklems, ivedamos tokios savybes kaip asociatyvu-mas, simetrija ir idempotentumas (angl. idempotency). Darbe laikoma, kadspecikacija (tiek sistemos, tiek komponento) turima tada, kai yra i²vardi-jamos visos jos (jo) savybes. Jungiant komponentus jungiamos ir ju speci-kacijos bei tokiu budu gaunama k¡ tik sukurtos sistemos specikacija. Tai-gi, specikacijos yra transformuojamos. Jos taip pat gali buti transformuo-jamos ir siekiant gauti geresnes kompozicines specikacijas. Todel siulomasismetodas [30] remiasi predikatu transformatoriais (angl. predicate transform-ers) funkcijomis transformuojan£iomis predikatus i kitus predikatus. Kaippripaºista [30] autorius, ²ios funkcijos primena E.W. Dijkstra [48] silpniausi¡salyg¡ (angl. weakest precondition WP) ir stipriausi¡ s¡lyg¡ (angl. strongestprecondition SP) (3.2 lentele).

Daugiausia nagrinejamos sistemos sudarytos i² elementariuju komponentu,ta£iau neatmetama ir sudetiniu komponentu panaudojimo galimybe. Sistemos,


kaip ir komponentai ºymimi didºiosiomis raidemis, o komponavimo taisyklesºymimos dvinariais operatoriais: ?,

⊙.

Kadangi siuloma tik pati koncepcija, komponavimo operatorius naudoja-mas tik tam, kad parodytu jog kompozicija i² viso imanoma, neatsiºvelgiant ijos detales. Ta pati komponavimo taisykle gali buti susijusi su skirtingais sud-erinamumo operatoriais [32], kurie neaptariami darbe [30]. Sistemu savybiupredikatai arba atskiriami ta²ku (.), arba pateikiamos tokiu predikatu aibes.Pvz., jei F ir G - sistemos, turin£ios savyb¦ X tai X.F

⊙G bus ºymima

sudetine sistema i² F ir G, turinti t¡ pa£i¡ savyb¦.M. Charpentier pabreºia butinyb¦, nustatyti sistemos savybes pagal kompo-

nentu savybes ir atvirk²£iai (jei komponentu neturime, ir ju reikia ie²koti) [30].Savybiu s¡ra²as laikomas komponuojamu, jei paskutine s¡ra²o savybe i²laiko-

ma bet kurioje sistemoje, sukurtoje i² komponentu i²laikan£iu likusias savybes.Pavyzdºiui, jei nagrinesime sistem¡ (F

⊙G)?H, tai savybes (X,Y, Z, T ) butu

laikomos komponuojamomis tik jeigu⟨∀F,G,H :: X.F ∧ Y.G ∧ Z.H =⇒ T.(F

⊙G) ? H

⟩Jei T butu neºinomas, gautume lygti. ios lygties sprendiniu konjunkcijataip pat butu sprendinys, ta£iau egzistuoja ir stipriausias sprendinys (angl.strongest solution), kuris ºymimas (X

⊙Y ) ? Z.

Komponavimo savybes apibreºiamos dvejomis teoremomis:

1 teorema. (X⊙Y )?Z charakterizuoja tas sistemas, kurios gali buti gautos

komponuojant X, Y ir Z sistemas per ?,⊙. Bet kuri taip sukomponuota

sistema tenkina (X⊙Y )?Z ir bet kuri sistema, kuri tenkina (X

⊙Y )?Z,

gali buti dekomponuota:

(X⊙

Y ) ? Z.K ≡⟨∃F,G,H : X.F ∧ Y.G ∧ Z.H : (F

⊙G) ? H = K

⟩Pasinaudojus ²ia teorema galima perra²yti kompoziciniu savybiu s¡ra²oapibreºim¡: ⟨

∀K :: (X⊙

Y ) ? Z.K ⇒ T.K⟩

o tai leidºia nebekalbeti apie sistemas, o kalbeti tik apie ju savybes. Jeikuri nors posisteme yra ypatinga ir reikia pabreºti, kad ji yra sistema,galima naudoti savyb¦ buti sistema F : 〈∀G :: F=.G ≡ (F = G)〉.

Jei (X⊙Y ) ? Z yra ekvivalenti X (t.y. i²laikomos visos X savybes),

[30] sakoma, kad X gerai komponuojamas (angl. good compositionalbehavior). Gali buti ir kitaip:


• Sistema (X⊙Y ) ? Z turi daugiau savybiu nei X. Daºnai butent

to ir siekiama.

• Sistema (X⊙Y ) ? Z turi maºiau savybiu nei X

• Sistema (X⊙Y ) ? Z redukuojasi i konstant¡ true t.y. visos X

savybes prarandamos.

Lygtis S : [(S⊙Y ) ? Z ⇒ T ] turi silpniausi¡ sprendini (sprendiniu dis-

junkcija taip yra sprendinys). Egzistuoja funkcija atvaizduojanti (an-gl. maps) T i silpniausi¡ sprendini (kai Y ir Z - ksuotos savybes):((?⊙Y )?Z).T i funkcija yra predikatu transformatorius. Jis charakter-

izuoja, kokia turi buti sistema (sudetinis komponentas), kuri¡ sukompon-avus su Y ir Z, gautume sistem¡ su savybemis T . Irodºius, kad konkretisistema (komponentas) yra lygties sprendinys, kuri galima jungti i sis-tem¡ (komponuoti).

2 teorema.

((?⊙

Y ) ? Z).T.K ≡⟨∀F,G : Y.F ∧ Z.G : T.(K

⊙F ) ? G

⟩Jei ie²komasis komponentas pasiºymi savybe T ir ta savybe yra geraikomponuojama, tai ir sistema i²laikys savyb¦ T . Ta£iau, jei T , nera geraikomponuojama, gali tekti irodyti, koki¡ stipresn¦ nei T savyb¦ turi turetiie²komasis komponentas. Blogiausiu atveju, jei (?

⊙Y ) ? Z).T redukuo-

jasi i false konstant¡, komponentas, kuris tiktu sudetinei sistemai su Tsavybe neegzistuoja.

Darbe [30] parodomas M. Charpentier metodo ry²ys su E. W. Dijkstradarbais [49] (3.2 lentele).

Kiekvienas predikatu transformatorius τ turi unikalu τ∗ konjugat¡ (angl.conjugate): τ∗.X ≡ −τ.(−X). Transformatorius (?

⊙Y ) ? Z taip pat turi

konjugat¡ ((?⊙Y ) ? Z)∗, toki, kuris charakterizuoja sistemos (formuojamos

i² Y ir Z sistemu) likuti. Nors pastarasis transformatorius ir padeda rastitrukstamo komponento savybes, jis negarantuoja, kad sistema tenkins savybesT . Todel ie²komasis komponentas dar turi tenkinti ir ((?

⊙Y ) ? Z).T

M. Charpentier [30] pabreºia, kad ²os idejos ypa£ butu naudingos kuriantlygiagre£i¡sias konkurencines sistemas, modeliuojant jas laiko logikomis. Jiskomponavimo kontekste atsiribojama tiek nuo skai£iavimu, tiek nuo busenu.ios savybes laikomos neturin£iomis komponavimui itakos. Komponavimo op-eratoriai

⊙, ?, taip pat abstraktus. Nenagrinejama konkreti ju prasme ir netgi

savybes (simetrija, asociatyvumas ir pan.).


3.2 lentele E. W. Dijkstra ir M. Charpentier teoriju atitikmenys.Dijkstra/Hoare Charpentier

programu semantika komponuojamumasbusena/predikatas sistema/savybevykdyti program¡ sukonstruoti sistem¡priskirti kintam¡ji prijungti posistem¦

wlp (weakest liberal precondition) predikatu transformatorius ?, neswlp.s.p rei²kia, kad jei eilute (angl.statment) s ivykdyta ir s baigiasi,tai gaunama busena q. [30] siuloma(?⊙F=).T rei²kia, kad jei prie siste-

mos F pridesime/komponuosime Fgausime sistem¡ su T savybemis.

sp (strongest precondition) predikatu transformatorius(λX.(X

⊙Y )), nes sp.s.p rei²kia,

busena, kuri yra gaunama po to,kai busenoje, tenkinan£ioje p vyk-doma eilute s. X

⊙Y : stipriausia

savybe, kuri i²laikoma po to, kaiprie X prijungiama Y .

[p⇒ wlp.s.q] ≡ [sp.s.p⇒ q] [X ⇒ (?⊙Y ).Z] ≡ [X.Y ⇒ Z]

[wlp.(s; s′).q ≡ wlp.s.(wlp.s′.q)] [((?⊙Y ) ? Z).T ≡ (?

⊙Y ).((? ? Z).T )]

Darbe [33] i²laikomas konceptualusis poºiurus, t.y. nagrinejamos kom-pozicines sistemos nenurodant, kad nagrinejami komponentai yra programini-ai. Darbe laikomasi nuomones, kad bendruju komponavimo teoriju narinejimasgali padeti identikuoti esminius bet kokiu komponavimo formu bruoºus.

Viena didesniu komponavimo problemu yra tai, kad komponentu (ir sistemutaip pat) specikacijos yra kur kas abstraktesnes nei ju realizacijos, o tokio de-talumo gali nepakakti renkantis komponentus, tam kad juos jungiant gautumekorekti²k¡ program¡.

Darbe [33] pristatomas irodymu vaidmuo komponentiniu programu kurime(3.1 pav.). Pabreºiama, kad didºiausias teoremu irodymo sudetingumas tuributi paliktas atskiru komponentu irodymams. Tuo tarpu visos sistemos irodymasturi buti toks paprastas, koks tik gali buti. Komponentu irodymai, siste-mos irodyme yra tik naudojami, ta£iau jokiu budu negali buti modikuojami.Pasak [33], komponentu irodymu sudetingumas padeda uºtikrinti, kad siste-mos irodymas butu kuo paprastesnis, t.y. Komponento irodymas atlieka irtarpininko tarp kompoziciniu savybiu ir realizacijos detaliu vaidmeni.

3.3 lenteleje palyginti M. Charpentier predikatu transformatoriai.

3.2. Deduktyviosios sintezes metodas 67

3.1 pav. Irodymu vaidmuo automatizuotame komponentiniu programu kurimoprocese.

3.2 pav. Programu sintezes metodu tarpusavio ry²iai.

M. Charpentier kompoziciniu sistemu savybiu prognozavimo metodas galibuti taikomas numatyti ar komponentines programu sistemos atitiks nefunkciniusreikalavimus, jei ²iuos reikalavimus atitinka komponentai.

3.2. Deduktyviosios sintezes metodas

Deduktyvioje programu sintezeje taikomas deduktyvus samprotavimu budas,kuris kitaip dar vadinamas saugiu. Naudojant ²i metod¡ programa gaunamapasinaudojant uºdavinio sprendinio egzistavimo teoremos irodymu. Jei uº-davinys i²sprendºiamas, programa sudaroma irodymo proceduros pagrindu.Tai realizuojama dviem budais: interpretuojant irodym¡ arba i² jo i²gaunantprogram¡ pasirinkta kalba [111].

Deduktyvines programu sintezes metodai, kurie kaip formalizm¡ naudojakonstruktyvi¡sias teorijas, dar vadinami konstruktyviosios sintezes [55, 167],arba irodomojo programavimo (angl. proofs-as-programs) [74, 142] metodais


(3.2 pav.). Toks metodas grindºiamas Curry-Howard izomorzmu [133, 84] (ºr.3.4. poskyri). Teisingos programos sintezuojamos i² specikaciju intuicionis-tinio (konstruktyviojo) irodymo.

Konstruktyviosios sintezes metodu klaseje dar skiriamas ir strukturinesprogramu sintezes metodas. Taikant ²i metod¡ irodymo metu atsiºvelgiamatik i strukturines skai£iavimu savybes.Pla£iausiai ºinomos deduktyviosios sintezes sistemos yra ²ios:

• DEDALUS [55]. Viena pirmuju Z. Manna ir R. Waldinger sukurtusistemu. Pirma versija realizavo transformacin¦ sintez¦, ta£iau veliau jibuvo modernizuota i irodomojo programavimo sistem¡. Sistemai pateikia-ma formali specikacija, i²sami ir darni reikalavimu atºvilgiu, taip pat da-lykines srities teorija. Autoriai, atsiºvelgdami i irodomojo programavimoypatumus, sukure savo teoremu irodymo sistem¡, pavadint¡ dedukciniutablo (angl. deductive tableau).

• Amphion [6]. NASA iniciatyva sukurta sistema automatizuotam programu,skirtu dangaus kunu padetims ir palydovu trajektorijoms modeliuoti.Sistemai pateikiama formali specikacija, i²sami ir darni reikalavimuatºvilgiu, taip pat dalykines srities teorija. Specikacija sudaroma iranalizuojama granio naudotojo interfeiso pagalba. Irodymo sistemai² esmes nesiskiria nuo DEDALUS irodymo sistemos, ta£iau £ia nau-dojama automatinio teoremu irodymo programa (angl. prover) SNARK[156]. Be to, sintezes rezultatas - programa gali buti i²ver£iama i kit¡ im-peratyviojo programavimo kalb¡, pvz., Fortran. Sekmingiausi Amphionpanaudojimo rezultatai yra menulio fazes kitimo modeliavimo progra-ma (angl. phase of moon) ir saules padeties Galileo palydovo atºvilgiumodeliavimo (angl. solar incidence angle) programa.

• GeoLogica [180]. I geogranio pobudºio klausimus atsakinejanti sistema,taip pat naudojanti ATP SNARK ir naturaliosios kalbos analizatoriuGemini.

3.2.1. Programu sistemu deduktyviosios sintezes uºdavinys

Kaip teigia R. Bazler [17], visi²kai automatinio programu kurimo proceso,kuriame nedalyvautu ºmogus negali buti, todel kalbama tik apie automatizuot¡programavim¡. Pagrindiniai automatizuoto programu sistemu kurimo etapaiyra ²ie (3.3 pav.):

• neformaliosios uºdavinio specikacijos sudarymas;

• formaliosios uºdavinio specikacijos sudarymas;


3.3 pav. Supaprastinta R. Bazler pasiulyta automatizuoto programu kurimodeduktyviosios sintezes metodu schema.

• neformaliosios specikacijos perºiura ir korekcija, jei nustatoma, kad tamtikru elementu formalizuoti neimanoma;

• formaliosios specikacijos transformacija i formalu uºdavinio apra²¡ tamtikroje teorijoje (²is apra²as dar vadinamas ºemo lygmens specikacija);

• programos sinteze, remiantis formali¡ja ºemo lygmens specikacija. Na-grinejamo uºdavinio kontekste s¡vokas sinteze ir surinkimas galima suta-patinti. Yra numatyta ir formaliosios specikacijos koregavimo galimybe.Koregavimas negali buti visi²kai automatinis, todel formuojant auk²to ly-gio specikacij¡ ir j¡ transformuojant i ºemo lygio specikacij¡ butinasºmogaus dalyvavimas [17, 45].

Egzistuoja ir kita programu sistemu automatizuoto surinkimo i² jau sukurtukomponentu uºdavinio sprendimo schema [113]. Joje kalbama tik apie formal-i¡j¡ uºdavinio specikacij¡, kuri dar vadinama tiesiog uºdaviniu. Be to tarpformaliosios ºemo lygio specikacijos ir galutines programos dar gali buti vienaar daugiau tarpiniu grandºiu (3.4 pav.).

Pirmiausia uºdavinio apra²ymas (formalioji specikacija) pateikiamas kurianors deklaratyvi¡ja kalba. I² ²ios specikacijos gaunama aibe formuliu konkre£io-je teorijoje. ioje teorijoje programu kurimo uºdavinys formuluojamas kaipteorema, kuri¡ reikia irodyti. Jei uºdavinio sprendinio egzistavimo teoremairodoma, tuomet atliekama transformacija teoremos irodymas → programa.

3.4 pav. Automatizuoto programu kurimo deduktyviosios sintezes metoduschema.


Realizuojant deduktyviosios sintezes metod¡ naudojamos automatinio teo-remu irodymo programos (ATP) (3.4 pav.). Keletas ju apºvelgiama 3.2.2. skyri-uje.

3.2.2. Automatinio teoremu irodymo programos

Automatinio teoremu irodymo programa tikrina ar duota formule (teore-ma) yra teisinga [152].Nors apie automatini irodym¡ pradeta kalbeti gana anksti, tre£iajame XX a.de²imtmetyje, reik²mingesniu rezultatu pradeta pasiekti tik ²e²tajame de²imt-metyje [20].

G. Huet 1970-aisiais metais pradejo SAM irankio projekt¡ pirmos eileslogikai su ekvivalentumo s¡ry²iu Tuo metu paºangiausiomis buvo laikomos ATIsistemos visus teiginius pervedan£ios i literalu disjunktu konjunkcijas, kvanto-rius kei£ian£ios skoleminemis formomis. Toliau ²iems konjunktams buvo taiko-mas rezoliucijos metodas [57]. Procesas daºnai nekonverguodavo ir ATP daºnaidarb¡ baigdavo kai persipildydavo kompiuterio darbine atmintis [20].

Didesni pasiekimai pastebimi nuo 1970-uju, kuomet D. Knuth ir P. Bendixpasiule irodymo sisteminimo metodik¡ naudojant baigimo sekas (angl. ter-mination orders). i¡ metodik¡ realizavo J.M. Hullot ir G. Huet [85] ir taipigalino automatizuoti sprendimus dirbant su algebrinemis strukturomis. Tuopa£iu metu pradeti siulyti (pvz. [22]) automatinio irodymo indukcijos budumetodai. Be to, rezoliuciju metodas buvo apibendrintas ir pritaikytas auk²tes-nio lygmens logikoms.

Apie 1980-uosius metus Eidinburgo universiteto mokslininku grupe realiza-vo LCF sistem¡, kurios vienas esminiu bruoºu irodymo taktiku apra²ymo MLkalba galimybe.

Svarbi¡ viet¡ automatiniu teoremu irodymo irankiu raidoje turejo ir P.Martin-Löf konstruktyvioji tipu teorija. Vieni pirmuju darbu t¦sian£iu ²iasidejas: NuPRL sistema ir Programavimo metodologijos projektas vykdytasalmerso universitete (Chalmers university).

Ilg¡ laik¡ λ-skai£iavimas buvo pagrindinis irankis irodymu teorijoje. Ypa£po to, kai buvo irodytas Curry-Howard izomorzmas [133, 84] parodantis, kadgalima vienareik²me atitiktis tarp irodymo ir funkciniu programu strukturu.1980-uju metu pradºioje buvo pradetas tyrimas, kurio tikslas sukurti irodymusistem¡ praple£ian£i¡ LCF idejas ir pritaikyti ML kalb¡ ne tik kaip taktikuapra²ymo metakalb¡, bet ir kaip visos irodymu sistemos realizavimo kalb¡.Vienas i² tyrimo rezultatu buvo Caml o, dar veliau, Objective Caml kal-ba. Reminatis T. Coquand ir G. Huet darbais konstruktyvioji P. Martin-Löf tipu teorija pritaikyta Automath sistemos pletiniui konstrukciju skai£i-avimui (angl. Calculus of Constructions-CoC ). Veliau T. Coquand realiza-vo sekvencinio stiliaus (angl. sequent-style) irodymo sintezes algoritm¡ kuris


igalino konstruoti irodymo termus progresyviais pertvarkymais (angl. pro-gressive renement), naudojant taktiku aibes (kaip LCF sistemoje). Vyk-dant Formel [86] projekt¡ buvo nuspr¦sta CoC taikyti sertikuotoms pro-gramoms gebneruoti, pana²iai kaip NuPRL [68] sistemoje. Kuriant sistem¡paai²kejo, kad CoC negalima apra²yti induktyviuju duomenu strukturu, todelbuvo sukurtas induktyviuju konstrukciju skai£iavimas (angl. Calculus of In-ductive Constructions CoIC ).Devintojo XX a. de²imtme£io pabaigoje jau buvo ºinoma daug teoremu irodymoprogramu [182] tokios kaip Isabelle [185], Vampire [179]ir pan.

Egzistuoja ivairios automatinio teoremu irodymo programu taksonomijos[179, 152, 182]. Grupes, i kurias skirstomos ATP, priklauso ir nuo to, kokiemstikslams rengiamasi ²ias programas naudoti. Tam, kad teoremu irodymo pro-gram¡ butu galima panaudoti programu sistemu inºinerijos kontekste (programukurimui irodomojo programavimo budu, programu modeliu tikrinimui ar pan.)ji taip pat turi atitikti tam tikrus reikalavimus. I²samiausi¡ reikalavimu tokiomsATP s¡ra²¡ pateikia J. Schumann [152]:

1. Bendrieji reikalavimai

• rai²kos galia Kaip pastebima [152, 182], daºnai efektyviau yrapanaudoti jau egzistuojan£i¡ ATP, nei kurti nauj¡. Be to, pir-mos eiles logikas naudojan£ios ATP irodymo kelio ie²ko grei£iau.Ta£iau butina atsakyti i klausim¡ ar logikos kurioje ATP atliekaveiksmus (vadinsime tikslo logika) ir logikos, kurios teorem¡ nori-ma irodyti (toliau ²altinio logika) rai²kos galia yra vienoda? Argalima atvaizduoti tas pa£ias esybes, neprarandant reik²mingos in-formacijos?

• Pagristumas ir baigtumas

Sprendºiant realaus pasaulio problemas daºnai reikalaujama, kadirodymo paie²ka truktu ilgiau nei i² anksto numatytas laikas. Jeiirodymas nerandamas, kyla klausimas ar jis i² viso neegzistuojair teorema klaidinga ar tik irodymui rasti reikia daugiau resursu.Kitaip sakant, kyla klausimas ar ATP gali irodyti ar paneigti visasteoremas?Vertinant ATP darbo baigtum¡ skiriami du atvejai [152]:

gerybinio nebaigtumo atveju ATP nepajegi irodyti visu teoremu,ta£iau per nustatyt¡ laik¡ randa visus naudotoj¡ dominan£iustrumpus irodymas.

piktybinio nebaigtumo atveju neirodoma daug svarbiu teoremu.


Kartais, siekiant paspartinti irodymu paie²kos proces¡ apribojamasnaudojamu aksiomu kiekis.

• Patikimumas Automatinio teoremu irodymo bei tikrinimo pro-gramos turi buti ypa£ kruop²£iai kuriamos, nes net jei tokia progra-ma nustato, kad irodymas rastas, gali buti gana sunku patikrinti,ar tas irodymas yra korekti²kas.

2. Jungimosi su ATP savybes Prakti²kai naudojant ATP tampa svarbioskomunikavimo su ²ia programa detales:

• Irodymo uºduoties ivestis. Ji apima du etapus [152]: uºduotiesskaitym¡ ir uºduoties paruo²im¡. Skaitymo metu patikrinama pa-teikiamu aksiomu ir norimos irodyti teoremos signatura.

Uºduoties paruo²imo proces¡ sudaro keletas ºingsniu, kuriu skai£iusir paskirtis daºnai priklauso nuo pa£ios ATP programos:

sintaksines transformacijos;

formules transformacijos (daºnai i² auk²tesnes eiles logikos iATP pirmos eiles logik¡);

aksiomu atranka (angl. preselection);

supaprastinimas.

• ATP startavimas ir stabdymo sparta

• Rezultatu analize. Pageidautina ATP savybe kiek imanomai²samesne informacija apie nesekmingos irodymo paie²kos prieºastisir irodymo paie²kos keli¡ (kurios aksiomos panaudotos, o kurios neir pan.). Taip pat labai svarbi ir ATP galimybe termus pakeistiju keitiniais (angl. substitution) programu sistemu kurime yra.Irodomojo programavimo sistemose, tokiose kaip NUT [175] ir Am-phion [6] keitiniai naudojami programai generuoti remiantis irodymu.

3. Indukcija. Jei naudojamos rekursyvios duomenu strukturos arba rekur-syviosios funkcijos, irodymas gali buti rastas tik indukcijos budu [152].J. Schumman nuomone [152] indukcines ATP geba irodyti gana

4. Ru²ys (angl. Sorts) Kai kurie formalieji metodu programu sistemu in-ºinerijoje naudoja tipizuot¡ arba sortiruot¡ logik¡. Tokiu atveju ATPtai pat turi gebeti atlikti operacijas tokioje logikoje.


5. Aksiomu parinkimas ir generavimas. ATP pateikiama teorema,kuri¡ reikia irodyti, aksiomos, hipotezes ir pan. Tokiu budu susidaro kele-tas ²imtu aksiomu. Aksiomu skai£iaus augimas labai padidina irodymopaie²kos laik¡, todel siekiant t¡ laik¡ sutrumpinti kartais apsiribojamatik tam tikru aksiomu poaibiu [175, 152]. Siekiant pagreitinti irodymopaie²k¡ [152] siuloma kartu su aksiomomis (arba vietoj kai kuriu i² ju)itraukti ir lemas, kuriu teisingumu neabejojama.

6. Neteoremu atpaºinimas. Jei ATP neatpaºista neteoremu (t.y. neko-rekti²ku formuliu), ji gali dirbti naudodama itin daug resursu, pailgejairodymo paie²kos laikas, taip pat gali atvejai kai ATP nebaigia darbo.

7. Valdymas ATP darb¡ galima vertinti pagal kelet¡ kriteriju [152]:

• ATP turi tureti patogi¡ naudotojams s¡saj¡

• ATP turi buti sklandi, t.y. maºam irodymui, naudoti maºai resursu,buti nuspejama

• Palaikyti vien¡ i² ATI paie²kos strategiju:

(a) Per ksuot¡ laik¡ T ATP turi i²spr¦sti kiekvien¡ uºdavini kaipgalima grei£iau.

(b) Per ksuot¡ laik¡ T ATP turi i²spr¦sti kiek galima daugiauuºdaviniu.

• Paie²kos srities dydis.Pirmos eiles logikai paie²kos laukas yra eksponentinis ir nedeter-ministinis [152]. Paie²kos algoritmai neturi galimybiu prognozuotipaie²kos laiko ir likusios uºduoties (pouºdaviniu) sprendimo trukmes.

• Parametru itaka.Kaip pastebima [152] labai sunku parinkti optimalu ATP parametruskai£iu. Jei parametru per maºai - programa nelankstus, jei perdaug - daºnai nei²naudojamos visos jos galimybes, o parinkus vien-as kitam prie²taraujan£ius parametrus galima neigiamai paveiktiirodymo paie²kos proces¡.

8. Papildomi reikalavimai: stabilumas, robasti²kumas, i²sami dokumen-tacija.

J. Schumann reikalavimu automatinio teoremu irodymo programoms s¡ra²asyra i²samus, ta£iau atsiºvelgiant i kontekst¡ jis gali kisti. Pastebetina, kad net


3.5 pav. Automatinio teoremu irodymo etapai.

NORA/HAMMR sistemoje naudojama ATP tenkina ne visus reikalavimus.Komponentiniu programu sistemu kurimo kontekste ATP apsiribosime tik ²i-ais reikalavimais:

• ATP naudojamo vidinio formalizmo bei uºdavinio specikavimo kalbosrai²kos geba turi buti pakankama komponento modelio statiniam ir di-naminiam aspektams i²reik²ti.

• teoremu irodymo procesas turi buti visi²kai automatinis, t.y. be ºmogausisiki²imo nuo irodymo paie²kos proceso pradºios iki pabaigos. Rank-iniu budu gali buti pateikti tik pradiniai duomenys (uºdavinio teorija,paie²kos algoritmas, taktika ir pan.) prie² proceso pradºi¡.

• Turi buti numatytas ATP ry²ys su kitomis programomis (pvz., per APIbibliotek¡), ATP turi buti skirta tai pa£iai operacinei sistemai (OS), kuri-ai skirtas ir j¡ naudosiantis programu sistemu generavimo irankis.

Pagal ²iuos kriterijus paanalizuokime kelet¡ automatiniu teoremu irodymoprogramu (3.4 lentele):

1. HERBY ir THEO.

M. Newborn [127] apra²o dvi automatinio teoremu irodymo programas:

• HERBY semantinio medºio metod¡ naudojanti teoremu irodymoprograma.

• THEO rezoliuciju-atmetimo (angl. refutation) metod¡ naudojan-ti TIP.

Specikacijoms konvertuoti i minetoms programoms priimtin¡ format¡naudojama tre£ia programa - COMPILE.


2. Coq.

Naudojant Coq [20] program¡ termu, tipu, irodymu ir programu apra²y-mui naudojama speciali kalba Galina ir komandines eilutes irankis Ver-nacular. Kaip vidinis formalizmas naudojamas CoIC skai£iavimas. Coqbranduolys kiekvien¡ sintezuot¡ irodymo term¡ pertikrina remdamasisvartotojo pasirinkta taktika. Jau Coq 4.1 versija pasiºymejo galimybe i²irodymu i²gauti funkcines programas Caml kalba, veliau pateikiama irgrane CTCoq s¡saja, leidºianti vartotojui nurodyti, kuriame irodymopaie²kos ta²ke, kurias taktikas taikyti.Coq septintoji versijoje tapo imanoma naudoti auk²tesnio lygmens logikas,CTCoq s¡saja pakeista nauja, Java programavimo kalba sukurta PCoqs¡saja. Be to, panaudotas visi²kai naujas irodymo paie²kos algoritmas.Coq pagrindu pradeti kurti kiti projektai [20]:

• CALIFE laiko automatu modeliavimo irankis;

• Why imperatyviuju programu kurimo irankis;

• Krakatoa Java iskiepiu tikrinimo irankis

Coq interaktyvus ATP, todel yra netinkamas visi²kai automatiniamteoremu irodymui.

3. Isabelle bendroji sistema loginiu formalizmu realizavimui, sukurtanaudojant ML kalb¡ [185, 139, 130]. Naudojama ProofGeneral [9] varto-tojo s¡saja kuri savo ruoºtu naudoja Emacs tipo teksto redaktoriu. Uº-daviniai apra²omi ir koordinuojami Isar kalba. Taip pat Isabelle gali butinaudojama ir i² kitu programu per komandines eilutes kreipinius. Deja,Isabelle negali buti naudojama visi²kai automatiniam teoremu irodymui.Taip pat kaip ir Coq, Issabelle yra interaktyvus teoremu irodymo irankis.

Isabelle sudetiniai moduliai yra:

• bazinis irodymu paie²kos modulis (angl. classical reasoner),

• supaprastinimo modulis (angl. simplier) galintis normalizuotilygtis,

• i²oriniu teoremu irodymo programu panaudojimo modulis Sledge-hammer, skirtas pouºduoti konvertuoti i pasirinktai i²orinei iro-dymo programai priimtin¡ format¡ ir j¡ perduoti bei priimti rezul-tatus. Galimos jungtys su E, SPASS ir Vampire teoremu irodymoprogramomis [185].


Isabelle naudoja pla£i¡ elementarios skai£iu teorijos, analizes, algebros iraibiu teorijos aksiomu ir teoremu bibliotek¡. i biblioteka praple£iamair internete prieinama spr¦stu uºdaviniu, ju irodymu ir kitos medºiagosºiniu baze [8]. Be to bibliotekos elementai apra²yti SML kalba, todel Is-abelle ATP galimybes gali buti ple£iamos apra²ant naujas teorijas kitomsdalykinems sritims.

Pla£iausiai naudojama ²ios teoremu irodymo programos versija Isabelle/HOL skirta specikavimui ir tikrinimui auk²tesnio lygmens logikoje HOL[130]. Isabelle/ HOL leidºia vykdom¡sias specikacijas konvertuoti iSML, OCaml ar Haskell programavimo kalbu kod¡. Taip pat gali butinaudojamos ir kitos Isabelle at²akos darbui su pirmos eiles, ZF, skai£iuo-jamuju funkciju (LCF ), sekventu, Lambda Cube logikomis bei konstruk-tyvi¡ja tipu teorija (CTT) [130]. Be to programos autoriai sudare gal-imybes ir kitu at²aku kurimui naudojant Isabelle/Pure metalogik¡.

Analize parode, kad ne visos ATP yra visi²kai automatines (3.4 lentele).Be to, gana ribotos ju ry²io su kitomis programomis galimybes. Nors yra ATP,kuriu pirmini programos tekst¡ galima keisti, naudojimo galimybes riboja op-eracines sistemos pasirinkimas.

3.3. Strukturines programu sintezes metodas 77

3.3. Strukturines programu sintezes metodas

Strukturine sinteze - dedukcijos principu grindºiamas programu sintezesmetodas. Metodo pagrindas yra Curry-Howard izomorzmas, uºtikrinantisvienareik²m¦ atitikti tarp uºdavinio sprendinio teoremos konstruktyviojo irodymoir programos [84].

Nuo kitu deduktyviniu sintezes metodu, strukturine sinteze skiriasi tuo,kad konstruoti programas galima remiantis vien ju strukturinemis savybemis.Tokiu atveju uºdavinio s¡lyg¡ galima nusakyti apra²ant turimu komponentuir busimos programu sistemos strukturines savybes. Klasikinis strukturinessintezes metodas leidºia atlikti operacijas vienoje i² triju teoriju [2]:

• λ-skai£iavime,

• konstruktyviojoje tipu teorijoje,

• intuicionistineje logikoje.

3.3.1. Strukturines sintezes skai£iavimo modeliai

Tarkim S1, S2, . . . , Sk - aibes.

< s1, s2, . . . sk >∈ S1 × S2 × . . .× Sk

Bet koks Dekarto sandaugos S1 × S2 × . . . × Sk poaibis vadinamas s¡ry²iu.Sakoma, kad rinkinys < l1, . . . lk > tenkina s¡ry²i R, jeigu < l1, . . . lk >∈ R.

Lygtis f(x1, . . . xk) = 0 apibreºia s¡ry²i tarp kintamuju x1, . . . xk.

Jei µ1, µ2, . . . , µk yra kintamuju x1, . . . xk reik²miu kitimo sritys, tai bet kuriss¡ry²is R ⊆ µ1×µ2× . . .×µk yra vadinamas s¡ry²iu tarp kintamuju x1, . . . xk.

Panagrinekime s¡ry²i R(x). Tegu u ⊆ v, v ⊆ x. S¡ry²is R(x) apibreºiakintamuju u ir v (bendruoju atveju - nevienareik²mi) atvaizdi:

φR,u,v : µu 7→ µv,

kuris kiekvienai kintamojo u reik²mei u parenka toki¡ kintamojo v reik²m¦ v,kuri kartu su u yra kaºkurio s¡ry²io R elemento dalis:

φR,u,v(u) = v|(∃e)(e ∈ R ∧ u ⊆ e ∧ v ⊆ e

Siekiant supaprastinti realizacij¡ apsiribojama tik funkciniais s¡ry²iais. Darbe[167], funkcinis dvieju aibiu s¡ry²is vadinamas operatoriumi. Kitaip tariant,operatoriumi φ vadinama baigtine priskyrimu

yi := fi(x1, . . . xm), i = 1, 2, . . . n


aibe. ia x1, . . . xm - ieinantys kintamieji, o y1, . . . yn - i²einantys kintamieji.Ju aibes ºymimos in(φ) ir out(φ) atitinkamai. Operatoriai φ1, . . . φk vadinamineprie²taringais, jeigu taikant skirtingus operatorius (arba kei£iant ju vykdy-mo tvark¡) i² tu pa£iu ieinan£iu kintamuju reik²miu, gaunamos tos pa£iosi²einan£iu kintamuju reik²mes.Daliniu s¡ry²iu vadinama baigtine neprie²taringu operatoriu aibe. Pastebima[168], kad atskiras operatorius visada sudaro dalini s¡ry²i, jei in(φ)∩out(φ) = ∅Nagrinejamas dalinis s¡ry²is R(x), nusakytas operatoriu aibe Φ = φ1, . . . , φk.Kintamasis u ∈ x s¡ry²iui R(x) vadinamas:

• ieinan£iu, jei egzistuoja toks φ′ ∈ Φ, kuriam u ∈ in(φ′) ir u /∈ out(φ),jokiam φ.

• i²einan£iu, jei egzistuoja toks φ′ ∈ Φ, kuriam u ∈ out(φ′) ir u /∈ in(φ),jokiam φ.

• silpnai susietu, jei egzistuoja tokie φ′ ∈ Φ, φ′′ ∈ Φ, kuriems u ∈ in(φ′)ir u /∈ out(φ′′).

Dalinio s¡ry²io rangu Rank(R) vadinamas minimalus ²io s¡ry²io operato-riaus i²einan£iu kintamuju skai£ius.

Daliniai s¡ry²iai, pasiºymintys maksimaliu galimu skai£iumi operatoriu sumaksimaliu galimu skai£iumi i²einan£iu kintamuju, esant duotam rangui

Rank(R(x))

yra ypatingi. Visi susieti tokio s¡ry²io kintamieji silpnai susieti, o operatoriuskai£ius - Cnr , kur r - rangas, n - s¡ry²io susietu kintamuju skai£ius. Tokies¡ry²iai yra lyg£iu sistemos apibendrinimas (arba atskiru lyg£iu, kai r = 1), jievadinami visi²kai simetriniais s¡ry²iais. Pastaruosius apibendrina simetriniais¡ry²iai. Kiekvienam simetrinio s¡ry²io R(x) operatoriui teisingos lygybes:

in(φ) ∪ out(φ) = x (3.2)

|out(φ)| = Rank(R) = r (3.3)

Tarkime, kad k i²einan£iu simetrinio s¡ry²io kintamuju skai£ius. Tadabet kuriam deriniui po r− k ²io s¡ry²io silpnai susietu kintamuju atsiras oper-atorius, kuriam ²ie kintamieji yra ieinantys. Ribinis atvejis yra kai r = k, tadas¡ry²is neturi susietu kintamuju ir turi tik vien¡ operatoriu. Bet kuris daliniss¡ry²is, turintis tik vien¡ operatoriu, yra simetrinis.Strukturiniu s¡ry²iu vadinamas s¡ry²is turintis tik silpnai susietus kintamuo-sius, i² kuriu vienas yra strukturinis. m kintamuju siejantis strukturinis s¡ry²isturi lygiai m operatoriu, kurie apra²omi taip:

x :=< x1, . . . , xm−1 >, (3.4)

xi := selecti(x), i = 1, . . . ,m− 1, (3.5)


3.6 pav. SSP s¡ry²iai [167].

3.7 pav. SSP s¡ry²iu tipai [167].

kur selecti yra funkcija apskai£iuojanti i-ojo sudetinio kintamojo elementoreik²m¦.

E. Tyugu grupes mokslininkai [167, 168] skai£iuojamuoju modeliu vadinasemantini tinkl¡, kuri sudaro kintamieji susieti vienareik²miais daliniais s¡ry²i-ais2. Tarkime, kad M - skai£iuojamasis modelis, tada jo kintamuju aibe ºymi-ma var(M), o s¡ry²iu aibe rel(M).Skai£iuojamieji modeliai gali buti interpretuojami kaip grafai [168, 167].

Pateiktas skai£iuojamasis modelis neleidºia specikuoti s¡lygu, kada oper-atorius galima taikyti. Siekiant panaikinti ²i apribojim¡, jau PRIZ sistemojeivesti valdymo kintamieji [168, 167]. Grafe valdymo kintamuosius atitinkavaldymo mazgai. Valdymo mazgai yra dvieju ru²iu:

• cond-mazgai. Valdymo mazgas valdymo kintamasis susietas su vienu

2Dalinis s¡ry²is vadinamas vienareik²miu, jeigu visos to s¡ry²io operacijos yra vien-areik²mes [167].

3.8 pav. Valdymo ta²kas SSP skai£iuojamajame modelyje [167].


3.9 pav. SSP s¡lygos s¡ry²is [167].

3.10 pav. SSP pouºdavinio s¡ry²is [167]

s¡ry²iu. io kintamojo reik²me rodo ar s¡ry²is galimas (3.9 pav.). Prapletusskai£iuojam¡ji modeli cond valdymo elementais, gautasis modelis yrapakankamas kad jame butu galima i²reik²ti bet kuri algoritm¡ [167].

• sub-mazgai. Jie susieja (angl. binds) skai£iuojamojo modelio M s¡ry²iR ir s¡ry²i i² rel(M). Pastarasis s¡ry²is vadinamas s¡ry²io R pouºdaviniu(3.10 pav.). Skai£iuojamieji modeliai kuriuos sudaro tik sub valdymo ele-mentais, strukturiniais s¡ry²iai, ir s¡ry²iai: konstanta 0 ,plius 1 , prim-ityvios rekursijos operatorius, minimizavimo operatorius, yra pakankamikad jais butu galima i²reik²ti bet kuri¡ rekursyvi¡ funkcij¡. Kiekvienairekursyviai funkcijai gali buti sintezuojama programa, kuri apskai£iuojafunkcijos reik²m¦ [167].

Tipinis strukturines sintezes uºdavinys yra

Rasti r1, r2, . . . , rs pagal p1, p2, . . . , pl ºinant M ,

kur M - skai£iuojamasis modelis, r1, r2, . . . , rs - rezultatai (i²einantys kin-tamieji), p1, p2, . . . , pl - argumentai (ieinantys kintamieji).

3.3.2. Strukturines sintezes algoritmai

Pirmoji sistema, kurioje realizuotas strukturines sintezes metodas PRIZ.Irodymo planavimo modulis buvo sukurtas 1975-1977 m. [169], o a²tuntojo


de²imtme£io pradºioje galutinai suderintas [176]. PRIZ sistemoje siekiant pas-partinti sintezes proces¡ naudojamos tik specialios formos aksiomos [166]. Josei²reik²tiniu budu naudojamas apskai£iuojamumo s¡ry²is: naudojant funkcij¡f i² u galima gauti (apskai£iuoti) v :

uf7→ v.

Prie apskai£iuojamumo s¡ry²io prijungus formul¦ Γ, kuri i²rei²kia apskai£iuo-jamumo s¡lygas, gaunamas apskai£iuojamumo sakinys:

Γ ` u f7→ v, . (3.6)

Kiekviena teorijos aksioma turi toki pavidal¡:

R ` (Γ ` u f7→ v),

kur s¡ry²is R = (R1, R2, . . . Rn) rodo s¡lygas, kuriomis galima i²vesti apskai£i-uojamumo sakini.

3.3.2.1. I²vedimo taisykles

Teoremos irodymui naudojamos penkios i²vedimo taisykles:

y ⊆ x

xselectx,y7−→ y

(3.7)

xf17→ y, y

f27→ z

xf1;f27−→ z

, kur (3.8)

(f1; f2)(x) = f2(f1(x))

xf17→ y, x

f27→ z, ω = y ∪ z

xf1,f27−→ ω

, kur (3.9)

(f1, f2)(x) = f1(x) ∪ (f2(x))

Γ,Γ ` x f7→ y

xf7→ y

(3.10)

R(a), R(z) ` (Γ ` x f7→ y)

Γ′ ` x′ f7→ y′, (3.11)

kur Γ′, x′, y′ gauti vietoj a ista£ius z. Kaip teigiama [172], ²iu taisykliupakanka i²vesti bet kuriai primityviai rekursyviai funkcijai, apra²ytai ak-siomomis:


af7→ b (3.12)

ir

∀φ(cφ7→ d⇒ a

G(φ)7→ b) (3.13)

Teoremos irodymo paie²k¡ sudaro du etapai:

1. Taikant penkt¡j¡ (3.11) i²vedimo taisykl¦ i² aksiomu i²vedami apskai£i-

uojamumo sakiniai Γ ` x f7→ y,.

2. Atliekama teoremos irodymo paie²ka. Nauji sakiniai i²vedami taikantpirm¡j¡ (3.7), antr¡j¡ (3.8) ir tre£i¡j¡ (3.9) taisykles.

3.3.2.2. Tiesines strukturos programu sinteze: algoritmas A1

1 ºingsnis. ω′ := u

2 ºingsnis. Taikoma pirmoji (3.7) i²vedimo taisykle siekiant gauti

v ⊆ ω′

ω′ 7→ v.

Jei taisykle taikytina, tai teorema irodyta. Prie²ingu atveju

ω := ω′.

3 ºingsnis. Ie²koma tokio apskai£iuojamumo ry²io

xf7→ y,

kuriamx ⊆ ω ∧ y 6⊆ ω.

4 ºingsnis. jei tokio ry²io nera, tai teorema neirodoma.

5 ºingsnis. Taikoma antroji (3.8) i²vedimo taisykle siekiant gauti nauj¡ sakini:

ωf17→ x, x

f27→ y

ωf1,f27→ y

Taikoma tre£ioji (3.9) i²vedimo taisykle siekiant gauti nauj¡ busen¡:

xf17→ y, x

f27→ ω, ω′ = ω ∪ y

xf1,f27−→ ω′


6 ºingsnis. Pereinama prie 2-ojo ºingsnio.

Pastabos.

• 3-ame ºingsnyje vyksta eilinio apskai£iuojamumo s¡ry²io parinkimas. Su-paprastintoje schemoje tai daroma perrenkant visus galimus variantus,ta£iau, kaip paºymima [166], kitu euristiniu metodu naudojimas gali pro-ces¡ pagreitinti.

• Algoritmas A1 visada baigia darb¡ nes kiekvienam u ir s¡lygai R klasesT∞ teorijoje egzistuoja baigtine busena, kuri pasiekiama (suskai£iuoja-ma) atlikus baigtini ºingsniu skai£iu.

• Jei taikant algoritm¡ A1 teorema neirodoma, tai jos irodymas neegzis-tuoja.

3.3.2.3. Besi²akojan£iu programu sinteze: algoritmas A2

1 ºingsnis. ω′ := u

2 ºingsnis. Taikomas algoritmas A1 siekiant irodyti teorem¡

R ` ∃f(ω′f7→ v)

ir apskai£iuoti busen¡ ω, naudojant tik apskai£iuojamumo sakinius sutapa£iai teisingomis apskai£iuojamumo s¡lygomis. Jei teorema irodyta,tai darbas baigiamas.

3 ºingsnis. Jei nera nei vieno skai£iuojamojo sakinio priklausan£io tipui

P (z) ` x 7→ y,

kuriamz ⊆ ω ∧ x ⊆ ω ∧ y 6⊆ ω,

tai teoremaR ` ∃f(u

f7→ v)

neirodoma. Prie²ingu atveju su kiekvienu tokiu sakiniu

P (z) ` x 7→ y

atliekami ²ie veiksmai:

3.1 Daroma prielaida, kad teisingas P (z);


3.2 Rekursyviai taikant algoritm¡ A2, ie²koma teoremos

R′ ` ∃f(ωf7−→ v)

irodymo. (R′ gautas i² R pakei£iant P (z) ` x 7→ y i ` x 7→ y).

5 ºingsnis. Jei nei viena i² teoremu neirodoma, tai ir teorema

R ` ∃f(uf7→ v)

neirodoma. Prie²ingu atveju visiems sakiniams ωfi7−→ v, kur i = 1, · · · , k,

i²vestiems teoremosR′ ` ∃f(ω

f7→ v)

irodymo metu taikoma 4 taisykles (3.10) modikacija:

P1(z1) ` ω f17→ v, . . . , Pk(zk) ` ωfk7−→ v

ωf7−→ v

kur f=if p1(z1) then f1 elsif p2(z2) then f2elsif . . . elsif pk(zk) thenfk else failure if.

6 ºingsnis. Taikoma antroji (3.8) i²vedimo taisykle siekiant i²vesti sakini uf7−→

v :uf17→ ω, ω

f27→ v

uf7−→ v

7 ºingsnis. Teorema irodyta.

Pastabos.

• Algoritmas A2 visada baigia darb¡, nes algoritmas A1 baigia darb¡ klasesT1 teorijose, o kiekviena T2 klases teorija yra tam tikros T1 teorijosprapletimas prijungiant prie jos baigtini aksiomu skai£iu, kuriu kiekvienairodyme taikoma baigtini kartu skai£iu.

• Jei teorema R ` ∃f(uf7→ v) irodoma, tai i²vest¡ji sakini u

f7→ v atitinkabesi²akojanti programa, kuri apima proceduras, neturin£ias procedurostipo parametru, nuoseklieji operatoriai ir s¡lygos operatoriai.

• Kiekviena tokiu budu gauta programa baigia darb¡, nes visi teorijos ak-siomomis apra²yti operatoriai yra pilni. Bet tokio uºdavinio i²sprendºi-amumas priklauso nuo pradiniu duomenu.


3.3.2.4. Programu su pouºdaviniais sinteze: algoritmas A3

1 ºingsnis. ω′i := u

2 ºingsnis. Taikomas algoritmas A1 siekiant irodyti teorem¡

R ` ∃f(ω′f7→ v)

ir apskai£iuoti busen¡ ω, naudojant tik apskai£iuojamumo sakinius sutapa£iai teisingomis apskai£iuojamumo s¡lygomis. Jei teorema irodyta,tai darbas baigiamas.

3 ºingsnis. Ie²koma tokio sakinio Γ ` x f7→ y, kuriam

x ⊆ ω ∧ y 6⊆ ω, Γ = ∃f(u1f7→ v1)

∧. . .∧∃f(uk

f7→ vk)

rekursyviai taikant algoritm¡ A3 kiekvienam pouºdaviniui i² Γ irodoma

R ` ∃f(uif7→ vi)

4 ºingsnis. Jei tokio sakinio nera, tai pereinama prie 7 ºingsnio. Prie²ingu

atveju taikoma 4-oji (3.10) i²vedimo taisykle, siekiant i²vesti s¡ry²i xf7→ y

i² skai£iuojamojo sakinio Γ ` x f7→ y.

5 ºingsnis. Rekursyviai taikant algoritm¡ A3 konstruojamas teoremos R′ `∃f(ω

f7−→ v) irodymas.

6 ºingsnis. Jei teorema R ` ∃f(ωf7−→ v) irodoma, tai pereinama prie 10

ºingsnio. Prie²ingu atveju teorema neirodoma, darbas baigiamas.

7 ºingsnis. Kiekvienam tokiam sakiniui Γ ` x f7→ y, kurio suskai£iuojamumos¡lygos Γ apima realizuojam¡ predikat¡ P (z), kuriam

x ⊆ ω ∧ x ⊆ ω ∧ u 6⊆ ω

atliekami ²ie veiksmai:

7.1 Daroma prielaida, kad predikatas P (z) teisingas.

7.2 Rekursyviai taikant algoritm¡ A3 ie²koma teoremos

R′ ` ∃f(ωf7−→ v)

irodymo. R′ gaunamas taip pat, kaip ir A2 algoritmo 3.2 ºingsnyje.


8 ºingsnis. Jei neegzistuoja toks skai£iuojamumo sakinys Γ ` x f7→ y, kurioskai£iuojamumo s¡lygos Γ turetu predikat¡ P (z), kuriam

z ⊆ ω ∧ x ⊆ ω ∧ u 6⊆ ω,

tai teorema neirodoma.

9 ºingsnis. Jei nei viena 7.2 ºingsnyje nagrinejamu teoremu neirodoma, taiuºdavinys nei²sprendºiamas. Prie²ingu atveju sakiniams

P1(z1) ` ω f17→ v, . . . , Pk(zk) ` ωfk7→ v,

atitinkantiems teoremas R′ ` ∃f(ωf7−→ v) taikoma 4-oji (3.10) taisykle:

P1(z1) ` ω f17→ v1, . . . , Pk(zk) ` ωfk7−→ vk

ωf7−→ v

,

kur f=if p1(z1) then f1 elsif p2(z2) then f2elsif . . . elsif pk(zk) thenfk else failure if.

10 ºingsnis. Taikoma 2-oji (3.8) i²vedimo taisykle siekiant i²vesti uf17→ v:

uf17→ ω, ω

f27→ v

uf7−→

v

11 ºingsnis. Teorema irodyta.

Pastabos. Kiekvien¡ irodyme naudojam¡ sakini Γ ` x f7→ y, kurio skai£i-avimo s¡lygose yra pouºdaviniu, generuojamoje programoje atitinka procedurosrealizuojan£ios funkcij¡ f i²kvietimas ir pouºdaviniu sprendimo proceduru

apra²ymas. Jei teorema R ` ∃f(uf7−→ v) irodoma, tai irodymo budu i²vest¡ji

sakini uf7−→ v atitinka programa su paprogramemis, kuri¡ sudaro proceduros,

nuoseklieji ir s¡lyginiai operatoriai ir uºdavinio sprendimo proceduru apra²y-mai.

3.3.2.5. Duomenu srautai: algoritmas A4

Skai£iuojam¡ji modeli galima nagrineti kaip duomenu srautu modeli (an-gl. data ow). Tokiu atveju galima naudoti dar vien¡ sprendinio paie²kosalgoritm¡ [167].

Kiekvienam operatoriui priskiriamas kintamasis (skaitliukas), kurio reik²meparodo, keliu argumentu reik²mes yra dar neapskai£iuotos. Algoritmas seka


kintamuosius kuriu reik²mes tapo ºinomos, ta£iau nera patikrinta ar jos busnaudojamos. Tokie kintamieji sura²omi i aib¦ N . Pirmieji aibes N elementaiyra uºdavinio argumentai. Algoritmas baigia darb¡ tada, kai N tampa tu²£iaaibe.

I² aibesN imamas kintamasis ( tarkim x ) ir su juo atliekami tokie veiksmai:

1. Jei kintamasis negali buti nei vieno operatoriaus argumentu (t.y. grafe i²kintam¡ji atitinkan£io mazgo nera i²ejimo rodykles), tai jis pa²alinamasi² aibes N ir daugiau nebenaudojamas.

2. Jei kintamasis gali buti kokio nors operatoriaus argumentu (t.y. grafei² kintam¡ji atitinkan£io mazgo yra bent vienas i²ejimo lankas), tai ²islankas pa²alinamas (arba paºymimas kaip nepasiekiamas), o operatoriausmazgas i kuri jis veda, patikrinamas. Jei operatoriaus skaitliuko reik²meyra didesne uº 1, tai ji vienetu sumaºinama.Jei ²i reik²me lygi 1, tai kintamasis x yra paskutinis argumentas, kurioreikejo operatoriui. Tokiu atveju operatorius ivykdomas, o jo rezultatai-kintamieji i traukiami i aib¦ N .is ºingsnis taikomas kiekvienam lankui vedan£iam i² nagrinejamo maz-go.

3. Procesas kartojamas kiekvienam aibes N kintamajam.

Pastabos. Kaip duomenu srautu modeli galima nagrineti ir skai£iuojam¡jimodeli su pouºdaviniais. Ta£iau tuo atveju i pouºdavini gali buti kreipiamasikelet¡ kartu. Del ²ios prieºasties labai sumaºeja algoritmo sparta. Algoritmosudetingumas yra polinominis atminties atºvilgiu (PSPACE), kaip ir naudojantteoremu irodym¡ intuicionistiniame teiginiu skai£iavime [167, 176].

3.3.3. Strukturines programu sintezes realizacijos

Strukturines sintezes metodas naudojamas jau daugiau kaip 20 metu. Pert¡ laik¡ jis buvo pritaikytas tiek strukturinei, tiek objektinei, tiek paslaugineiparadigmoms. iame poskyryje bus apºvelgti konkretus jo taikymai.

3.3.3.1. Klasikine strukturines sintezes sistema

Kuriant sistem¡ PRIZ, jai buvo keliami tokie reikalavimai [167]:

• Sistema turi i²saugoti ir naudoti visas bent kart¡ jai suteiktas ºinias.

• Programos yra nedalomos esybes skirtos atlikti konkretiems veiksmams(angl. actions). Jos gali buti sukurtos bet kuria programavimo kalba(Pvz.: Fortran, Cobol, Assembler ir t.t.)


• Programos jungiamos tik per parametrus ir neturi sukelti jokio pa²alinioefekto. Sinchronizacijos kintamieji taip pat laikomi programu parame-trais. Galutinis tipu patikrinimas (angl. type checking) turi buti atlieka-mas programu lygmenyje o ne ºiniu atvaizdavimo lygmenyje.

PRIZ sistemoje skai£iuojamasis modelis ir uºdavinys specikuojamas UTO-PIST kalba [167, 168]. UTOPIST program¡ sudaro skai£iuojamojo modeliospecikacija (let blokas) ir teorema, kuri¡ reikia irodyti (actions blokas). Pvz.:

program Pirmojilet X,Y,Z:numeris;X + Y = 2.5Z = X - Y;actions ` X 7→ Z;end;

UTOPIST kalba uºra²ytose specikacijose naudojama operacine semantika.Semantines kalbos programa sudaryta i² dvieju daliu [168, 167]:

• programos modelio, kuri sudaro visi programos kintamieji ir operato-riai. Kintamuju tipus ir operatoriu tinkamum¡ apibreºia semantine ma²i-na. Programos modelis yra skai£iuojamasis modelis kuriame kiekvienass¡ry²is turi tik vien¡ operatoriu.

• valdymo medºio, kuris nurodo operatoriu vykdymo tvark¡. Tokiomedºio ²aknimi yra programa, o jo terminaliniai mazgai operatoriai,kuriuos tiesiogiai gali vykdyti abstrak£ioji ma²ina. ie operatoriai yravaizduojami ir programos modelyje. Neterminaliniai mazgai yra valdy-mo mazgai. Jei valdymo tipas sudetinis, ji gali sudaryti keletas valdymokintamuju. Labai svarbu kokia tvarka i² neterminalines vir²unes lankaieina i kitas vir²unes. Sukeitus lankus vietomis gali buti gaunama visaikita, specikacijos neatitinkanti programa.

Valdymo medºio neterminalinemis vir²unemis gali buti tik keturiu tipu valdy-mo mazgai:

• seq (nurodo kokia tvarka vykdomi operatoriai),

• par (nurodo kad vykdymo tvarka nesvarbi, galimas ir lygiagretusis vykdy-mas),

• case (nurodo kokioms s¡lygoms esant, kurie operatoriai turi buti vykdo-mi),

• iter (nurodo kad operatorius turi buti vykdomas tol, kol valdymo kinta-masis igis neigiam¡ reik²m¦).


O tai, kaip pastebima [167], daro semantin¦ kalb¡ specializuot¡ja kalba.Siekiant i²vengti ²io apribojimo programos modelis papildomas s¡ry²iais supouºdaviniais. Tokie daliniai s¡ry²iai gali pakeisti valdymo mazgus. Tokiuatveju neterminalines vir²unes atitinka programas, kurios kvie£ia kitas pro-gramas. (Vykdymo logika tampa tu programu vidine savybe kuri SSP nena-grinejama). Taigi, valdymo tipai seq, par, case, iter kei£iami i² anksto sukur-tais operatoriais su pouºdaviniais.

3.3.3.2. Objektines strukturines sintezes sistemos

Strukturines sintezes metodas realizuotas dviejose sistemose skirtose ob-jektinems programu sistemoms kurti: NUT sistemoje ir kitoje KibernetikosInstitute Estijoje sukurtoje sistemoje skirtoje objektiniu programu Java kalbasintezei.

NUT sistema sukurta 90-uju metu pirmoje puseje kaip projekto STARTrezultatas [171]. Lyginant su PRIZ sistema, NUT sistemoje pagrindines siste-mos naujoves yra ²ios [2, 175, 140, 170]:

• SSP metodo pritaikymas objektinei paradigmai;

• grane vartotojo s¡saja, leidºianti papras£iau specikuoti uºdavini;

• galimybe uºdavinio specikacijoje naudoti C kalbos konstrukcijas ir ge-neruoti programas C kalba. [177]

• skirtingu skai£iavimo modeliu integracija [89].

• platesne praktinio pritaikymo sritis. PRIZ sistema buvo naudojamaskai£iuojamuju matematikos ir zikos uºdaviniu sprendimui [170, 167].Tuo tarpu NUT buvo panaudota vandens ²ildymo sistemu valdymo [2],automobilio su mechanine grei£iu deºe modeliavimo, optimalaus radarui²destymo Estijos teritorijoje uºdaviniams spr¦sti. Be to ²i¡ sistem¡ gali-ma naudoti ir kitu sri£iu, pvz. tekstu apdorojimo uºdavinus spr¦sti [89].

Apie 1995 m., M. Addibpour ir V. Vlasov praplete NUT sistem¡, sukurdamirNUT iranki lygiagre£ioms programoms sintezuoti [3]. NUT sistemoje ori-entuojamasi i objektin¦ paradigm¡, todel NUT kalba uºra²yta specikacijalyginant su UTOPIST kalba turi ypatumu:

• UTOPIST budinga let sritis, kurioje apra²omi kintamieji ir jiems suteiki-amos pradines reik²mes, pakeista i dvi sritis var (kintamiesiems apra²yti)ir init (kintamuju pradinems reik²mems nurodyti).

• Siekiant trumpiau uºra²yti klases elementu ir ju sudetiniu daliu (po-elemen£iu) pavadinimus naudojami pseudonimai. Jiems apra²yti skirtaalias sritis.


• Klase gali paveldeti kitos klases savybes. Paveldin£ios klases apra²e,super srityje nurodomas paveldimosios klases vardas.

• Dinami²kai sukurti naujiems objektams naudojamas operatorius new.

iek tiek skiriasi ir pats sintezes procesas. NUT sistemoje vyksta dvieju tipusinteze:

• klases elementu (lauku) reik²miu sinteze (skai£iavimas) kaip metodo com-pute rezultatas;

• programos, realizuojan£ios objekto elementu s¡ry²i sinteze (ir jei reikiapouºdaviniu realizaciju sinteze), kai kreipiamasi i objekto elementu s¡ry²i.

Sintezes metu naudojamos objekto elementu reik²mes (busenos) ir objektory²iai, jau turintys realizacijas. S¡ry²is kurio apra²yme yra naudojami #currar#next vardai i² tiesu apima ry²iu grup¦. Konkretus s¡ry²iai gaunami vietoj#curr, #next istatant #i ir #(i+1), kur i-teigiamas skai£ius, ne didesnisnei eiles ilgis. NUT sintezes sistemoje naudojamos ²ios i²vedimo taisykles:

1.o ⊃ eo ` d

, (3.14)

kur o.e reik²me apibreºta, o x ` y rei²kia remiantis x galima apskai£iuotiy.

2. Jei objektas o turi realizuot¡ s¡ry²i (angl. preprogrammed relation) iryra ºinomi visi to s¡ry²io argumentai (iskaitant ir pouºdavinius) bei visijo silpnai susieti (angl. weak) parametrai (galima i²imtis - neºinomas tikvienas silpnai susietas parametras), tai visi jo rezultatai (angl. outputparameters) ir trukstamas silpnai susietas parametras yra apskai£iuoja-mi:

o ⊃ ins 7→ weaks, w 7→ outs; o ` ins, weakso ` w, outs

, (3.15)

3. Jei du objekto elementai yra ekvivalentus ir vienas i² ju suskai£iuojamas,tai ir kitas yra suskai£iuojamas

4. Jei objektas o turi pseudonim¡ a su elementais e1, e2 . . . e2, tai a apskai£i-uojamas i² o. Jei a apskai£iuojamas i² o, tai ir e1, e2 . . . e2 apskai£iuojamii² o.

5. Jei objekto elementas e yra sudetinis (pvz. masyvas, struktura ir pan.)ir visos jo dalys apskai£iuojamos i² objekto o, tai ir pats elementas eapskai£iuojamas i² o.


6. Jei objekto sary²io priklausomu pouºdaviniu rezultatu apskai£iuojamu-mas gali buti irodytas taikant hipotez¦, kad pouºdaviniu argumentai yraapskai£iuojami objekte, tai pouºdaviniai yra apskai£iuojami tame objek-te.

7. Jei objekto s¡ry²io nepriklausomu pouºdaviniu rezultatu apskai£iuojamu-mas naujame specikacijoje apra²ytos klases objekte gali buti irodytastaikant hipotez¦, kad pouºdaviniu argumentai yra apskai£iuojami tamepa£iame naujame objekte, tai pouºdaviniai yra apskai£iuojami tame ob-jekte.

8. Jei objekto s¡ry²io, neturin£io realizacijos, rezultatu apskai£iuojamumasgali buti irodytas taikant hipotez¦, kad to s¡ry²io argumentai yra ap-skai£iuojami, tai s¡ry²is yra apskai£iuojamas.

Apra²ant NUT [2], pagrindinis demesys skiriamas granei sintezes sistemosvartotojo s¡sajai (angl. visual graphic language). Specializuojant NUT sistem¡konkre£iai dalykinei sri£iai, jos esybes apra²omos klasemis, ir veliau vizualiaisujungiamos i vientis¡ sistem¡.

Apie 2000-uosius metus Kibernetikos Institute Estijoje pradeta kurti nau-ja sintezes sistema, naudojanti SSP metod¡ skirta programoms Java kalbageneruoti. Java kalba pasirinkta del savo lankstumo ir nepriklausomumo nuoplatformos [75]. Pirmuosiuose darbuose [103] apra²oma, kad sinteze vykstaklasiu operaciju arba funkciju lygmenyje. Skiriamos trys sudetiniu elementu(angl. building blocks) tipai:

• klasiu operacijos, kurias i²renka ir sujungia pati sintezes sistema,

• Java klases atitinkan£ios konkre£ias esybes,

• metaklases.

Logikos kalba (taip pat naudojama ILP) i²rei²kiamos tokios programines irangossavybes:

• duomenu srautai (angl. dataow) tarp moduliu;

• moduliu kvietimo tvarka (angl. control variables);

• hierarchines duomenu strukturos;

• jau realizuotu (angl. pre-programmed) valdymo strukturos (pouºdavini-ai);

• alternatyvus moduliu rezultatai (daugiausia apra²ant i²imtis angl. Ex-ceptions;


• tiesioginis moduliu jungimas (angl. implicit linking).

Taip pat numatytas ir sintezes sistemos pletimas komponentinems CORBAsistemoms kurti [75], ta£iau realizacijos pavyzdºiu nepateikiama.Kiekviena Java klase yra papildoma lauku

public static String[] SSPspec

kuriame ir uºra²oma deklaratyvioji specikacija apra²anti klases lauku s¡ry²ius.Specikacijoje naudojami dvieju tipu s¡ry²iai: lygybes ir ekvivalentumo. ek-vivalentumo s¡ry²is nurodo, kad vien¡ element¡ galima pakeisti kitu, o lygtisnaudojamos nauju formuliu i²vedimui. Jas apdoroja atskira sintezes sistemosdalis lyg£iu redaktorius [75].

Java programu sintezes sistem¡ suadro 6 s¡veikaujantys komponentai [75]:

• ºiniu baze (B),

• kompiliatorius, analizuojantis deklaratyvi¡j¡ specikacij¡ ir jos rezulta-tus patalpinantis B,

• dekoratorius, kuris sukuria speciali¡ duomenu struktur¡, skirt¡ greitamplanavimui, suteikia bandom¡sias reik²mes ²ios strukturos elementams irj¡ perduodantis planavimo moduliui,

• planavimo modulis pagal specikacij¡ generuojantis programos struktur¡(algoritm¡),

• kodo generatorius pagal programos struktur¡ generuojantis programinikod¡ Java kalba.

Ta£iau sintezes sistemos rezultatas - yra ne komponentine, o objektine progra-ma.Planavimo modulyje naudojamos ²ios irodymo paie²kos strategijos:

• Prielaidomis grista paie²ka pirmyn. Irodymo paie²ka pradedama nuo tuelementu, kuriu reik²mes jau yra ºinomos (t.y. jie pamineti specikacijo-je, kaip sistemos ivestis (angl. inputs)) ir judama pirmyn, nagrinejanttik bes¡lyginius s¡ry²ius (angl. unconditional relations). I² pradºiu visiduoti elementai itraukiami i ºinomu aib¦. Kiekviename ºingsnyje s¡ry²is,kurio visu argumentu (angl. input objects) reik²mes ºinomos, ta£iau neºi-nomas bent vienas rezultatas, itraukiamas i sintezuojam¡ji algoritm¡.Panaudojus toki s¡ry²i, jo rezultatai (angl. output objects) tampa ºino-mi ir papildo ºinomu elementu aib¦.


• Tikslu grista paie²ka atgal naudojama tuomet, kai prielaidomis gristapaie²kos pirmyn nepakanka. Operuojama tik su s¡ry²iais turin£iais pouº-davinius, kuriu elementu pradines reik²mes yra ºinomos. Planavimomodulis rekursyviai naudojamas kiekvienam s¡ry²io pouºdaviniui spr¦sti.Jei visi pouºdaviniai i²spr¦sti, s¡ry²is traukiamas i sintezuojam¡ji algo-ritm¡. Po kiekvieno s¡ry²io su pouºdaviniais i²kvietimo algoritme nau-dojamas tiesinis planavimas.

• Minimizavimas. Anks£iau naudojamos paie²kos strategijos negarantuo-ja, kad bus surastas optimalus sprendinys, maºiausiai laiko sugai²tan-tis algoritmas tikslui pasiekti. Sprendinyje gali buti naudojami ir tokius¡ry²iai, kurie tikslui pasiekti yra nebutini. Minimizavimo metu tokies¡ry²iai pa²alinami.

3.3.3.3. Paslaugines strukturines sintezes sistemos

Viena komponentu ru²is pasaulinio tinklo paslaugos PTP (angl. web-servises, WS ) [183] yra ir paslaugines architekturos (angl. service oriented ar-chitecture) realizacija. Yra dvi strukturines sintezes metodo realizacijos paslau-gines architekturos programoms kurti: Lammerman [102] ESSP metodas irJ.Rao [145] metodas.Darbe [102] yra pristatoma i²plestoji strukturine sinteze (ESSP) ir jos taiky-mai pasaulinio tinklo paslaugoms i² komponentu generuoti. ESSP metode kaiplogikos kalba naudojama intuicionistinis teiginiu skai£iavimas. Logikos kalbayra praplesta ivedant ²iuos elementus [102]:

• kvantorius,

• disjunkcij¡,

• konstant¡ ⊥.

Kvantoriai ivesti atsiºvelgiant i pasikeitusi sprendºiamo uºdavinio pobudi.Anks£iau taikant strukturines sintezes metod¡ buvo remiamasi prielaida kadsinteze vyksta tam tikros strukturos ar klases viduje ir visi tos strukturos ele-mentai yra ºinomi uºdavinio specikavimo metu. Sintezuojant PTP susiduria-ma su problema, kad konkretus komponentai tampa ºinomi tik sintezes metu,specikavimo metu jie dar neºinomi.

Disjunkcija ivesta siekiant atvaizduoti i²imtis (angl. exceptions), o kon-stant¡ ⊥ i jas reaguoti. Tiek disjunkcijos ºenklas tiek FALSE gali buti tikde²ineje s¡ry²i apra²an£ios formules puseje. ⊥ de²ineje puseje vaizduoja pro-gramos darbo nutraukim¡ ivykus i²im£iai. Disjunkcija de²ineje puseje negalibuti naudojama, nes, kaip irodyta [166], tuomet perrinkimu skai£ius didetueksponenti²kai:

(((2n)n)n . . .)n


Bendroji ESSP formules struktura yra tokia:

[∀x]n∧i=1

[∀u]ni∧j=1

Ui,j 7→ [∃v]Vi

∧ m∧j=1

Xj 7→∨ki=1

(∧ljj=1 [∃y]Yi,j

)(3.16)

kur n,m ≥ 0, n, k, li ≥ 1, Ui,j , Vi, Xj ir Yi,j yra teiginiai(angl. propositionalvariables) arba monadiniai predikatai, kuriu kintamieji nera laisvi. x ir u yrapredikatu Xj ir Ui,j kintamieji, o v, y predikatu Vi ir Yi,j kintamieji. Naujiteiginiai W ir Z bei aksiomos:

W `k∨i=1

Zi (3.17)

Zi `ljj=1 Yi,j (3.18)

I logikos kalb¡ ivedus naujus elementus i²vedimo taisykliu s¡ra²as taip patpasipilde naujomis taisyklemis. Ivestos ⊥ eliminavimo

Γ `⊥Γ ` C

,

kvantoriu ivedimo ir eliminavimo

Γ ` [a/x]A

Γ ` ∀x.A(3.19)

Γ ` ∀x.AΓ ` [t/x]A

(3.20)

Γ ` [t/x]A

Γ ` ∃x.A(3.21)

Γ ` ∃x.AΓ, u : [a/x]A ` CΓ ` C

(3.22)

(3.23)

bei disjunkcijos eliminavimo

` W 7→ A ∨B ¯Γ `WΣ, u : A ` C∆, w : B ` CΓ,Σ,∆ ` C

,

taisykles. Ry²ium su nauju elementu ivedimu ESSP naudojamas ²iek tiekpakeistas SSP irodymo paie²kos algoritmas. Aksioma, kurioje yra disjunkcijaperra²oma kitu pavidalu (kaip iprasta taikant SSP, normalizuojama) tada ir tiktada jei yra naudojama. Toliau irodymo paie²ka t¦siama naudojant nauj¡ji (k¡tik viena aksioma papildyt¡) aksiomu rinkini. Kiekvienai tokiu budu perra²y-tai aksiomai jos realizacija generuojama automati²kai, prie²ingai nei klasikinio


SSP atveju, kur tokios aksiomos realizacija jau i² anksto turejo buti pateikta.Visuotinumo kvantorius panaikinamas istatant konkre£i¡ reik²m¦, o egzistavi-mo kvantorius panaikinamas pana²iai kaip ir disjunkcija. Siekiant sumaºin-ti irodymo paie²kos algoritmo sudetingum¡ ²ie keitimai atidedami veliausiamimanomam laikui. Pirmiausia ie²kant irodymo bandoma taikyti bes¡lyginiusskai£iuojamuosius sakinius ir tik tada, jei tikslas dar nepasiektas, eliminuojamikvantoriai. Kvantorius ∃x.P (x) gali buti pakeistas i P (a), jei galima irodytiΓ ` P (a) 7→ G, kur G - tolimiausias tikslas (angl. innermost goal), a - laisvasparametras, nesieinantis ² pati G ir G i²vedimo hipotezes.Tam kad i²vesti G i² Γ ∪ P (a) turi buti aksioma

∀y.P (y) ∧ L 7→ A,

kur L yra bet kokia (taip pat ir tu²£ia) leistina logikos kalbos pagrindines imp-likacijos kaires puses subformule, y neturi buti laisvas L ir A termuose ir A yraleistina de²ine pagrindines implikacijos puse. Prie² taikant visuotinumo kvan-toriaus eliminavimo taisykl¦, turi buti i²vestas L ir ºinomas P (a). Eliminavuskvantoriu gaunama:

P (t) ∧ L 7→ A.

Darbuose [114, 145] ²i ideja pletojama. J. Rao ivede ²iuos strukturinessintezes patobulinimus:

• pasaulinio tinklo paslaugu specikavimui naudojama DAML-S/OWL-Skalba, o teoremu irodymui Tiesine logika (Linear Logic). Iki tol ne-naudota Tiesine Logika parinkta atsiºvelgiant i PTP sintezes uºdaviniospecik¡: daugybines konjunkcijos (angl. multiplicative conjunction)s¡ry²is reikalingas i²reik²ti paslaugai reikalingu resursu skai£iu; logikosmodalumo savybes (pvz. predikatas Butinai) leidºia lanks£iau modeli-uoti paslaugos pasiekiamum¡;

• pirm¡ kart¡ strukturines sintezes metode i² specikacijos i login¦ teorij¦ºinios perkeliamos ne tiesiogiai, bet naudojant dar vien¡ formalizm¡ -Petri tinklus;

• naudojami ir nefunkciniai PTP ribojimai;

• skirtingai nei Lammerman darbe [102], atsisakyta kvantoriu.


3.4. Curry-Howard protokolas

Curry-Howard izomorzmas [133, 84] tapo i²tisos automatizuotu programukurimo metodu klases, dar vadinamos irodomuoju programavimu (angl. proofs-as-programs), pagrindu.H. Curry ir W.A. Howard irode, kad bet kuriam termui p, kurio tipas yra A,egzistuoja vienareik²me atitiktis tarp p konstrukcijos (sekos termu, nurodan£iu,kaip jis gautas) ir A i²vedimo naturaliosios dedukcijos sistemoje [131]. Curry-Howard izomorz¡ nusako ²i teorema [142]:

3 teorema. Tarkime Γ = G1, . . . Gn yra prielaidu aibe, o Γ′ = xG11 , . . . , xGn

n tipizuoti irodymo termo kintamieji (angl. proof-term variables). Tada,

1. Turint naturaliosios dedukcijos irodym¡ Γ ` A, naudojantis tipui²vedimo taisyklemis galima sukonstruoti taisykling¡ irodymo ter-m¡ (angl. well-typed proof-term) pA, kurio laisvieji irodymo termokintamieji priklauso aibei Γ′

2. Turint irodymo term¡ pA kurio irodymo kintamieji yra Γ′ galimasukonstruoti naturaliosios dedukcijos irodym¡ Γ ` A

Yra ºinoma keletas irodomojo programavimo metodu pavyzdºiu: NUT,Amphion ir kt. Iki 2005 m. ²ie metodai buvo kuriami ir tobulinami neprik-lausomai, neprisilaikant kokios nors bendros metodikos [142]. I. Poernomogrupe irodomojo programavimo metodu klas¦ apibendrino ir pasiule Curry-Howard protokol¡, nusakanti tokiu metodu kurimo ir naudojimo taisykles.Siekdama universalumo I. Poernomo grupe tiek logikos, tiek programavimokalbos pasirinkimui [142] nekelia jokiu apribojimu (3.5 lentele). Pastebima,kad gali buti ivestos ir papildomos roles, ta£iau tuo atveju butu sunku metod¡apibendrinti.

Nusakant Curry-Howard protokol¡ naudojamos tipu teorijos, logikos (arbanaturaliosios dedukcijos sistemos), logines tipu teorijos ir skai£iuojamosios tiputeorijos s¡vokos.

Tipu teorijaTipu teorij¡

TT = 〈Terms(TT ), T ypes(TT ),`TT , (:), T IR〉 (3.24)

sudaro ²ie elementai:

• Termu ir tipu su rekursyviosiomis gramatikomis aibes.

3.4. Curry-Howard protokolas 97

• Egzistuoja kintamuju aibe, termu aibes poaibis V arTerms(TT ).

• (:) dvinaris termu ir tipu atitikties s¡ry²is.

• tipu i²vedimo s¡ry²is `TT tarp aibesΓ = xi : Sii=1,...,n(xi ∈ V arTerms(TT ), S ∈ Types(TT ) (vadinamojo tipukonteksto) ir vienintelio s¡ry²io termui t : S(t ∈ Terms, S ∈ Types).S¡ry²is Γ `TT t : S vadinamas tipo i²vedimu.

• S¡ry²is ` apibreºtas aibe tipo i²vedimo taisykliu TIR, Aib¦ sudaro tai-sykles pradedant keletu tipu (prielaidu) i²vadu baigiant vienu (i²vados)i²vedimu:

Γ1 `TT t1 : S1 . . .Γn `TT tn : SnΓ `TT t : S

(R)

kur (R) - unikalus taisykles vardas. SIR aibeje gali buti ir begaline. Jeit1, t2 ∈ Terms, tai bet kokiam kontekstui Γ Γ ` t1 : S ⇔,Γ ` t2 : S,tai sakoma, kad ir t1, ir t2 turi t¡ pati tip¡ S. Ra²oma tΓ : S norintdenotuoti term¡ t ir parodyti fakt¡, kad Γ ` t : S gali buti i²vestas irt vadinamas taisyklingas (angl. well typed) Γ kontekste. Jei kontekstasai²kus, ra²oma ne t : S, o tΓ : S.

• `TT turi buti apibreºtas taip, kad kiekvienas termas butu t ∈ Terms(TT )taisykligai tipizuotas.

Logika

I. Poernomo grupe [142], remdamasi D. Gabbay deduktyviuju sistemu no-tacija naturaliosios dedukcijos sistem¡ apibreºia taip:

D = 〈Formulae(D),`D, DR〉 (3.25)

• Formulae(D) taisyklingu (angl. well-formed), rekursyviosios gramatikossakiniu aibe, samprotavimams deduktyviojoje sistemoje D atlikti.

• `D s¡ry²is tarp prielaidu formuliu Γi ∈ Formulae(D) ir vienos i²vadosformules C ∈ Formulae(D),

D = Γ `L C (3.26)

is s¡ry²is vadinamas i²vedimu (angl. inference). I²vedimas apra²ytasaibe dedukcijos taisykliuDR, susidedan£iu i² taisykliu i² keleto (prielaidu)i²vedimu i vien¡ (i²vadini) i²vedim¡ tokia forma:

Γ1 `D F1 . . .Γn `D FnΓ `D F

(R) (3.27)

DR taip pat gali buti ir begaline aibe.


Logine tipu teorija (LTT)

Logine tipu teorija yra konkre£ios dedukcijos sistemos vaizdavimas (angl.presentation) tipu teorijoje. Laikantis Curry-Howardo izomorzmo LTT tipaiyra logikos formules, termai atitinka tu tipu i²vedimo ºingsnius, redukcijoss¡ry²is termams apibreºia irodymu normalizavimo strategij¡.Formaliai logine tipu teorija dedukcinei sistemai L apra²oma taip:

LLT (L) =⟨PT (L), Formulae(L), (.)(.),`L, PTR, .

⟩(3.28)

kur PT (L) irodymu termai, Formulae(L) tipai, (.)(.) tipizavimo (angl.type judgment) s¡ry²is, `L tipu i²vedimo s¡ry²is apibreºtas PTR taisyklemis.Daromos tokios prielaidos:

• irodymu termu aibe PT (L) turi atskir¡ kintamuju poaibi V arPT (L).

• PT (L) apima lambda skai£iavim¡.

• tipizavimo s¡ry²is (p)(T ), apibreºtas tarp irodymo termu p ∈ PT (L) irformuliu T ∈ Formulae(L).

• PTR aibe gali buti begaline

• egzistuoja normalizavimo s¡ry²is . apibreºtas vir² irodymu termu PT (L),generuotas kaip tranzityvus vieno ºingsnio redukcijos s¡ry²io . uºdarinys(angl. closure). S¡ry²is . apibreºtas taisykliu aibe vir² irodymu termup1 . p2. Reikalaujama [142], kad:

normalizavimas i²laikytu irodymo termu tipus, taip kad Γ `PT (L)

pA1 ir p1 . p2 duos Γ `PT (L) pA2 ;

normalizavimo s¡ry²is turi buti grieºtai normalizuojantis: kiekvien-am irodymo termui pi, kiekviena vienºingsniu redukciju seka yrabaigtine ir baigiasi termu pn;

s¡ry²is turi tenkinti Church-Rosser savyb¦: bet kokiems irodymotermams p, p1, p2, kuriems p . p1, p . p2, turi egzistuoti ir bendrastermas p3, toks kad p1 . p3, p2 . p3.

Skai£iuojamoji tipu teorija (CTT)

CTT apibreºta taip, kad tiktu kiek galima daugiau programavimo kalbu:

CTT = 〈Terms(C), T ypes(C), :,`C , T IR, .〉 , (3.29)

3.4. Curry-Howard protokolas 99

kur Term(C) - termu aibe, apibreºianti programas, Type(C) tipu aibeabibreºianti programu tipus, t : T tipizavimo s¡ry²is, i²laikomas atitinka-mai tarp programu ir ju tipu pagal tipu i²vedimo s¡ry²i `C ir taisykles TIR.

I. Poernomo [142] pastebi, kad pagal ²i apibreºim¡ imperatyviosios progra-mavimo kalbos taip pat gali buti laikomos skai£iuojamosiomis tipu teorijomis.

Curry-Howard protokolas

Curry-Howard protokolas yra i²laikomas tarp logines tipu teorijos L irskai£iuojamuosios tipu teorijos C tada kai:

1. Egzistuoja atitikties schemos (angl. extraction maps) i² L formuliu iC tipus (etype schema) ir i² L irodymo termu i C programas extractschema:

extract : PT (L) 7→ Terms(C) (3.30)

etype : Formulae(L) 7→ Types(C) (3.31)

toks, kad bet kuriam irodymui d ∈ PT (L),Γ a dA extract(d) bus C dalisir priklausys tipui etype(A).

2. Tarp programu ir formuliu egzistuoja realizuojamumo s¡ry²is r, toks kadbet kuriam irodymui

∅ `L pA ∈ PT

teisingas ir extract(p)rA.

Curry-Howard protokolo naudojimo proces¡ sudaro keturi etapai [142]:

1. apibreºiamas loginis skai£iavimas,

2. loginiam skai£iavimui apibreºiama logine tipu teorija,

3. parenkama realizavimo (programavimo) kalba ir apra²oma kaip skai£iuo-jamoji tipu teorija,

4. irodoma, kad Curry-Howard protokolas i²laikomas pasirinktose srityse.(angl. protocol to hold over the domains).


3.5. Induktyviosios sintezes metodas

Induktyvioji sinteze pla£iai taikoma loginiu programu kurimui [14, 54, 71,91, 164]. Egzistuoja net atskira loginio programavimo ²aka induktyvinisloginis programavimas [125].

Taikant induktyviuji metod¡ turimos ºinios skiriamos i dvi grupes: bazin¦teorij¡ (angl. background theory) B ir apibendrintinus duomenis E (be to,B 6|= E). Apibendrintini duomenys dar skirstomi i teigiamus E+ ir neigia-mus E− pavyzdºius. B ∧ E− 6|=⊥. I²kelta hipoteze H laikoma induktyvi¡jai²vada jeigu ji neseka i² turimu ºiniu, ta£iau paai²kina teigiamus pavyzdºiusB ∧H |= E+ neprie²taraudama neigiamiems B ∧H ∧E 6|=⊥. Egzistuoja ben-drieji algoritmai hipotezems generuoti ir joms tikrinti [125].Pagrindines induktyviojo loginio programavimo naudojimo sritys yra ²ios: vaistugamyba, palydovine oru prognoze, automatinis programavimas. Induktyvusisloginis programavimas naudojamas funkciniu programu kurimui [14, 125], ta£i-au pastaruoju metu daugeja jo taikymu strukturinei, objektinei ir aspektineiparadigmoms [21, 54, 164].

Toliau ²iame poskyryje nagrinejami konkretus induktyviojo metodo taiky-mo programinei irangai kurti atvejai.Darbe [91] apie programu sintez¦ (konkre£iai programu transformavim¡) kalba-ma kaip apie priemon¦ teoremoms irodyti induktyviuoju metodu. I²skiriamosmetaskai£iavimo (angl. metacomputation), mi²riuju skai£iavimu ir superkom-piliavimo technikos.

Kaip teigiama [91], induktyviesiems spejimams budinga bendra struktura,t.y. tam, kad irodyti indukcin¦ i²vad¡ (angl. conjecture) reikia parinkti induk-cijos schem¡ ir hipotez¦. Irodymai gali reikalauti tarpiniu lemu arba turi butigeneruota ir irodyta bendresne formule. Irodyme gali buti panaudojama ir in-formacija gauta ankstesniame nesekmingo irodymo ºingsnyje. Indukcinio kin-tamojo parinkimas, termo ir indukcines hipotezes generavimas yra realizuotikaip euristika apimanti indukcijos taisykl¦ ir irodymo sistem¡, taip uºtikri-nant didesn¦ sekmingo irodymo radimo tikimyb¦. Viena tokiu euristiku yrarekursine analize (angl. recursion analysis).

Indukcines teoremu irodymo programos induktyviuju teoremu irodymuinaudoja indukcijos taisykles. R. S. Boyer ir J. S. Moore [22] remiasi rekur-sijos ir indukcijos s¡sajomis ir naudoja teoremu irodymo program¡ realizuo-jan£i¡ strukturines indukcijos metod¡. Ju sukurta teoremu irodymo programaBMTP naudoja i²reik²tines (angl. explicit) indukcines taisykles. Rekursinesanalizes proceso metu konstruojama atitinkama indukcine taisykle ir pasiulomiindukciniai kintamieji indukcinei i²vadai (angl. conjecture) [91]. Jei kintama-sis yra funkcijos rekursyviojo argumento pozicijoje, sakoma, kad tai yra atvejisbe trukumu (angl. unawed). Jei kintamasis yra nerekursyviojo argumentopozicijoje, sakoma, kad atvejis yra su trukumais (angl. awed). Indukcijos kin-

3.5. Induktyviosios sintezes metodas 101

tamaisiais gali buti parinkti tik universaliuju kvantoriu kintamieji neturintysatveju su trukumais. Atveju su trukumais problema yra ta, kad jei tokie atvejaiyra pakeisti indukcijos terme, jie negali buti perra²yti indukcijos i²vadoje.

Tikrosios indukcijos spejimuose kintamajam x yra siulomos dvi schemos:dvieju ir vieno ºingsnio. Rekursine analize siulo dvieju ºingsniu indukcijostaisykl¦ ir indukcini kintam¡ji x. Remiantis siekiama galutine indukcine i²-vada ir pateikta preliminaria indukcine i²vada yra formuojami pagrindiniaiir ºingsnio atvejai. Naujai formuluotiems tikslams perra²yti pagrindine irrekursyvioji funkciju formules naudojamos kaip perra²ymo taisykles.Jei visi indukciniai kintamieji yra su trukumais, rekursine analize siulo visusjuos imti kaip indukcinius kintamuosius. Pastebetina, kad rekursines analizesmetodas netaikytinas jei formulese yra egzistavimo kvantoriu.

M.H. Kabir [91] nagrineja induktyviojo metodo taikymus metalygmenyje.Metaskai£iavimo procese ir pa£ios programos traktuojamos ne kaip duomenusubjektas, bet kaip duomenys. Programos, geban£ios manipuliuoti programomisyra vadinamos metaprogramomis (< Mprog >) [91]. Atliekant metaskai£iav-im¡ teoremu irodymas gali buti visi²kai automatizuotas naudojant sulenkimo(angl. unfold-fold) programu transformacijas. Teoremu naudojimui naudoja-ma superkompiliatoriaus savybe atlikti gilu funkciju apra²ymu transformav-im¡. Siekiant irodyti, kad savybe P yra teisinga teisinga visiems x (∀x.P (x)),naudojant superkompiliatoriu galima transformuoti originalu P (x) apibreºim¡i True.R. Backhouse [11] taip pat apra²o indukcijos ir invariantu naudojim¡, ta£iaudaugiau akcentuoja formuliu tikrinimo proces¡ naudojant naudojant matem-atin¦ indukcij¡.Idej¡ panaudoti logini programavim¡ (taip pat ir induktyvuji logini programav-im¡) komponentinems programu sistemoms kurti taip pat pletoja mokslininkuK.-K. Lau [97, 98] ir M. Martelli [112] vadovaujamos tyrimu grupes.Nepaisant pla£iu induktyviojo metodo galimybiu, butina atkreipti demesi, kadjis turi ir trukumu:

• Kaip pabreºia S. Muggleton [124], metodas gali buti neefektyvus tuoatveju, kai remiamasi vien tik pavyzdºiais. Pavyzdºiu aibei sudarytigali buti sunaudojama daugiau resursu (pvz.: laiko) daug daugiau neiprogramai kurti.

• Nera garantiju, kad indukcijos rezultatas visada bus korekti²kas [14, 125].Strukturine programu sinteze ir kiti deduktyviniai metodai uºtikrina,kad gauta i²vada yra teisinga. Programu sintezes sistemos, naudojan£iosdeduktyviuosius metodus rezultatas taip pat yra visada korekti²ka. Tuotarpu taikant induktyvuji metod¡ remiantis tais pa£iais pavyzdºiais galibuti gautos skirtingos i²vados.


Induktyviosios sintezes metodai leidºia kurti sistemu elementus pasinaudo-jant naujomis, k¡ tik i²vestomis ºiniomis, ta£iau, siekiant i²vengti nekorekti²korezultato, visos induktyviosios i²vados privalo buti papildomai tikrinamos.

3.6. Transformacines sintezes metodas

Transformacine sinteze bendruoju atveju apibreºiama, kaip manipuliavi-mas programos atvaizdu, pakei£iant tos programos form¡ ar sintaks¦ [160].Vadovaujantis ²iuo apibreºimu, galima teigti, kad transformacine sinteze api-ma ir kitus generavimo metodus, iskaitant ir anks£iau aptartus strukturinessintezes bei induktyvuji. Vis del to ²ioje disertacijoje transformacin¦ sintez¦nagrinesime siauresniu, darbuose [145, 55] i²reik²tu poºiuriu, t. y. kaip atskir¡metod¡.

iuolaikine transformacine sinteze neatsiejama nuo modelines architekturos(angl. model-driven architecture - MDA) metodo. iame poskyryje analizuo-jama transformacines sintezes ir MDA taikymo komponentinems programusistemoms kurti automatizuotu budu galimybes.

Viena daºniausiai nagrinejamu automatizuotos programu sintezes problemuyra tikslios specikacijos tikslumo problema. Egzistuoja didelis atotrukis tarpdalykines srities, kuriai kuriama programine iranga, ir realizacines srities (kon-kre£iu komponento modeliu, karkasu, operaciniu sistemu ir t. t.) konceptu. isatotrukis sunkina komponentiniu sistemu specikavim¡ ir realizavim¡ (konkre£i-ai - komponentu paie²k¡ ir adaptavim¡). S¡lyginai nauja modeline architekturasukurta siekiant toki atotruki paversti prana²umu. Pla£iai apra²omi tiek ben-drieji modelines architekturos principai [94, 118, 138], tiek jos taikymo konkre£i-ai programu kurimo paradigmai atvejai [5, 106, 189]. Ta£iau [?, 95] siulomiMDA taikymai komponentiniu programu sistemoms kurti nevisi²kai atitin-ka komponentin¦ paradigm¡. Paºeidºiamas vienas komponentines paradig-mos principu - komponentu ir komponentiniu sistemu kurimo procesu atskyri-mas [92, 37, 159], nes naudojant [5, 95] metodus sistemos kuriamos i² £iapat generuotu komponentu. Modeline architektura tai OMG konsorciumopalaikoma programines irangos kurimo iniciatyva, pabreºianti modeliu svarb¡programines irangos kurimo procese. Programu sistemu, kuriamu naudojantMDA, gyvavimo cikl¡, kaip ir klasikini gyvavimo cikl¡ sudaro: reikalavimurinkimas, analize, projektavimas, kodavimas, testavimas bei tiraºavimas irpalaikymas [94]. Ta£iau skiriasi kiekvieno i² ²iu etapu automatizavimo laipsnisir rezultatai.

Analizes etapo rezultatas - abstraktusis modelis (angl. platform-independentmodel - PIM ). Kuriant programu sistemos PIM modeli operuojama tik da-lykines srities s¡vokomis, nesigilinant i realizacines detales, tokias kaip progra-mavimo kalba, DBVS ir pan.

3.6. Transformacines sintezes metodas 103

Projektavimo etapo rezultatas - konkretusis modelis (angl. platform-specicmodel - PSM ). PSM modelyje operuojama jau realizacinemis s¡vokomis, de-talizuojami nuo konkre£ios operacines sistemos, karkaso, programavimo kalbosir kitu veiksniu priklausomi sprendimai. Darbe [118] pabreºiama, kad ²iuo-laikine programine iranga yra itin sudetinga, todel MDA procesas gali apimtine vien¡, o kelet¡ PIM ir kelet¡ PSM modeliu.

Dar vienas MDA prana²umas - galimybe automatizuoti programu sistemukurimo proces¡. Visi²ko arba dalinio automatizavimo objektai yra ²ie [59, 138]:

• abstrak£iojo modelio neprie²taringumo tikrinimas;

• abstrak£iojo modelio transformacija i konkretuji modeli;

• konkre£iojo modelio transformacija i programini kod¡;

• vieno konkre£iojo modelio transformacija i kit¡ (pvz., kitai OS skirt¡)konkretuji modeli.

Automatizuotas pakartotinis PSM modelio ir atitinkamai programinio kodogeneravimas pasikeitus PIM modeliui sudaro galimybes operatyviai reaguoti ireikalavimu poky£ius.

Abstraktusis modelis gali buti apra²omas tik dalykines srities s¡vokomis,ta£iau siekiant, kad modelis atitiktu komponentin¦ paradigm¡, tikslinga ir jamenaudoti komponento konceptus. Akivaizdu, kad £ia butu operuojama dalykinessrities (verslo) komponentais, o ne programiniais komponentais [109]. Z. Sto-janovi£ [154] skiria du abstrak£iuosius modelius: verslo komponentu modeli irtaikomosios programos modeli (angl. application component model). S. Gobel[67] siulo naudoti adaptyviuosius komponentus, kurie gali buti konguruojamiir pritaikomi tiek ju kurimo, tiek paskirstymo, tiek vykdymo metu. Siekiantuºtikrinti kuo didesni modelio tikslum¡ siuloma naudoti UML 2.0 kalbos poaibi- vykdom¡j¡ UML kalb¡ [117]. Pagrindinis ²ios kalbos prana²umas - galimybeitin i²samiai apra²yti esybiu dinamik¡, ir tai sudaro s¡lygas gautus vykdomu-osius modelius ivykdyti ir patikrinti jau ²iame etape. Be tradicinemis tapusiuUML kalbos priemoniu, vykdomojoje UML ivesta klasiu veiksmu (angl. ClassActions) semantika [117]. Klasiu (²iuo atveju - esybiu) veiksmai apra²omispecialia klasiu veiksmu kalba (KVK) [136]. Klasiu veiksmu naudojimas pade-da apra²yti dalykines srities logik¡, o veliau - vykdymo logik¡, abstrahuojantisnuo konkre£iu platformu ir kitu detaliu. Paºymetina, kad kaip veiksmu apra²y-mo kalb¡ galima naudoti ne tik KVK, bet ir kitas veiksmu apra²ymo kalbas,pavyzdºiui, Schlaer-Mellor [117] kalb¡. Ribojimus, kuriuos privalo tenkintidalykines srities komponentai, tikslinga apra²yti OCL kalba. Vykdomoji UMLkalba sukurta proliavimo budu praple£iant UML 2.0 kalbos baz¦ [118] ir galibuti lengvai modernizuojama sukuriant kit¡ proli, labiau pritaikyt¡ kompo-nentinei paradigmai. Be to, naudojant MOF (angl. Meta Object Facility)


metamodeliu kurimo konstrukciju aib¦ [137] galima kurti konkre£iu dalykiniusri£iu modeliavimo priemones.Konkretusis modelis, apra²ytas vykdom¡ja UML kalba, yra suvokiamas kaipmodelio kompiliavimo proceso parametras [117]. iame modelyje jau atsispin-di komponento modelio, karkaso ir kitos realizacines detales. Realizuojantprogramu sistem¡ gali tekti atsiºvelgti i ivairius jos aspektus, todel tikslinganaudoti kelet¡ konkre£iuju (vienas i² kito gaunamu) modeliu, kuriu skai£iuspriklauso nuo programu sistemos sudetingumo [94, 118]. Pavyzdºiui, S. Gobel[67] i²skiria tris konkre£iuosius modelius: kurimo, paskirstymo ir vykdymo.Po atskir¡ konkretuji modeli turetu buti kuriama ir kiekvienam kitam kompo-nento modeliui. Pavyzdºiui, nusprendus naudoti nebe CORBA, o .NET kom-ponentus, butina generuoti nauj¡ konkretuji modeli. Konkre£iajam modeliuiapra²yti tikslingiausia taip pat naudoti vykdom¡j¡ UML kalb¡ [94], nors gali-mi ir kitu kalbu [52, 138] naudojimo atvejai. Paºymetina, kad automatizuotubudu i² abstrak£iojo modelio transformacijos budu gautas konkretusis modelisgali buti nei²samus, neatitikti realizacines aplinkos. Pavyzdºiui, jame apra²ytikol kas neegzistuojantys komponentai, arba keliu realiu komponentu funkcijosapra²ytos kaip vieno. Modeliui patikslinti siuloma naudoti detalizavimo (angl.model elaboration) priemones.

S. Gobel [67] nagrineja adaptyviuosius komponentus, be kitu interfeisuturin£ius ir valdymo bei parametrizavimo interfeisus, kurie naudojami kom-ponento konguravimui ir adaptavimui. Manoma, kad kiekvienas abstrak£ia-jame modelyje naudojamas dalykines srities komponentas turi konkre£ius real-izacinius atitikmenis. Tokiu atveju modeliu transformacija yra gana paprasta.Ta£iau i² tikruju dalykines srities ir realizacines dalies komponentu prasme,skai£ius ir kitos savybes gali ivairuoti, vienareik²me atitiktis imanoma tik ide-aliu atveju, todel darbe [67] i²destytas poºiuris yra netikslus. Abstrak£iojomodelio transformacijos i konkretuji modeli etape butina atsiºvelgti i I²rink-Pritaikyk-Testuok gyvavimo ciklo specik¡. Tradiciniu budu taikant MDA²iame etape generuojamas konkretusis modelis, kuris parodo, kokia sistematuretu buti sukurta. iuolaikiniuose komponento modeliuose komponentassuprantamas kaip juodoji deºe su minimaliomis konguravimo priemonemis,todel konkretusis modelis turi parodyti, kokie esami komponentai ir kaip tuributi panaudoti. I² to i²eina, kad transformacijos metu privalo buti atliekamidar ir papildomi veiksmai:

• esamu realizaciniu komponentu paie²ka ir atranka saugykloje;

• atskiru realizaciniu komponentu konguraciju kitimo ribu tyrimas ir kom-ponentu konguravimas (jei imanomas);

• trukstamu realizaciniu komponentu identikavimas.

3.6. Transformacines sintezes metodas 105

Transformacijos uºdavinys patenka i grup¦ uºdaviniu, kurie jau yra sprendºi-ami kuriamoje komponentiniu programu sistemu sintezes sistemoje [66]. Taiigalina naudoti MDA kuriant komponentines programu sistemas, nes pakankasukurti specialius abstrak£iojo modelio transformacijos irankius naudojan£iusstrukturines sintezes ir induktyvuji generavimo metodus.komponentines programos konkre£iojo modelio transformacija i programinikod¡ ypatinga tuo, kad realizaciniai komponentai yra juodosios deºes:

• Generuojamo kodo apimtis yra daug maºesne nei tradicineje MDA. Gene-ruojamas tik jungiantysis kodas ir trukstami realizaciniai komponentaiidentikuoti ankstesnes transformacijos metu (jei tokiu buvo).

• Butina patikrinti, ar realizaciniai komponentai ( juodosios deºes) ir juveiksmu semantika atitinka dalykines srities komponentams keliamus rei-kalavimus (iskaitant ir veiksmu semantik¡). iam palyginimui atliktireikalingas specialus irankis. Pavyzdºiui, .NET komponentu atveju toksirankis turetu formuoti atitiktis tarp reeksijos budu apklausto kompo-nento IL kodo ir vykdomosios UML veiksmu semantikos.

Paºymetina, kad tiek abstrak£iojo modelio transformacija, tiek konkre£iojomodelio transformacijos gali buti iteratyviai kartojamos.



1. Programu generavimo metodai nera gryni juos sudaro keliu metoduvisuma, apimanti ir nekomponentinems sistemos kurti skirtus metodus.

1.1. Klasikiniai formalieji metodai3 tiesiogiai nera taikomi komponenti-nems programu sistemoms kurti, ta£iau yra kitu, i²vestiniu, programusintezes metodu pagrindas.

1.2. M. Charpentier kompoziciniu sistemu savybiu prognozavimo meto-das gali buti taikomas numatyti ar komponentines programu siste-mos atitiks nefunkcinius reikalavimus, jei ²iuos reikalavimus atitin-ka komponentai.

2. Curry-Howard protokolas apibendrinantis irodomojo programavimo meto-du klas¦ yra realizuotas imperatyvinei, funkcinei ir strukturinei programukurimo paradigmoms.

3. Konkre£ioms komponentiniu programu sistemu surinkimo proceso au-tomatizavimo problemoms spr¦sti gali buti naudojami strukturines sin-tezes, induktyviosios sintezes ir transformacines sintezes metodai:

3.1. Deduktyvieji metodai palaiko juodosios deºes abstrakcijas, beto, taikant deduktyvuji strukturines sintezes metod¡ uºtikrinamarezultatu (taikomuju programu) atitiktis specikacijai

3.2. Induktyvusis metodas gali padeti spr¦sti ²ias deduktyviuoju meto-du nei²sprendºiamas problemas: specikacijos nei²samumo prob-lem¡, neapibreºtuju komponentu problem¡ ir nefunkciniu reikalavi-mu problem¡.

3.3. Transformacine sinteze igalina maºinti atotruki tarp dalykines sri-ties, kuriai kuriama programine iranga, ir realizacines srities (kon-kre£iu komponento modeliu, karkasu, operaciniu sistemu ir t. t.)konceptu.

4. Deduktyviojo metodo realizacijos grindºiamos automatiniu teoremu iro-dymo irankiu naudojimu. iu irankiu analize parode, kad jie netenkina²iu reikalavimu: vidinio formalizmo bei uºdavinio specikavimo kalbosrai²kos gebos; teoremos irodymo proceso visi²ko automatizavimo; ry²iosu kitomis programomis.

3E. Dijkstra, C.A.R. Hoare, M. Charpentier, R. Backhouse ir J. Schumann

107

3.3 lentele Predikatu transformatoriu palyginimas [33]Pavadinimas ymejimas PrasmeSilpniausias egzistenci-nis transformatorius

WE.X Kokia komponento savybe turetubuti irodyta, kad uºtikrinti jog betkuri sistema naudojanti t¡ kompo-nent¡ tures savyb¦ X.

Silpniausias universalu-sis transformatorius

SE.X

1. Kas gali buti gauta (angl. de-duced) i² sistemos, kuri turibent jau vien¡ komponent¡pasiºyminti savybe X

2. Sistemu turin£iu komponent¡pasiºyminti savybe X charak-teristika

Stipriausias universalu-sis transformatorius

SU.X

1. Kas gali buti gauta i² sis-temos, kuri sukurta vien tiki² komponentu pasiºymin£iusavybe X

2. Sistemu turin£iu tik kompo-nentus pasiºymin£ius savybeX charakteristika

WE konjugatas WE∗.X

1. Kas gali buti gauta visiemskomponentams esantiems sis-temoje pasiºymin£ia savybeX

2. komponentu esan£iu sistemo-je, kuri pasiºymi savybe X,charakteristika

SE konjugatas SE∗.X Kas turi buti irodyta sistemoje, kaduºtikrinti jog visi jos komponentaitenkina X

SU konjugatas SU∗.X Kas turi buti irodyta sistemoje, kaduºtikrinti jog bent vienas jos kom-ponentas tenkina X


3.4 lentele Automatiniu teoremu irodymo irankiu lyginamoji analize.

HERBY irTHEO

Coq Isabelle SNARK

Uºdaviniospecikavimokalba/irankis

specine/COMPILE

Galina/Venecular

Isar/ Proof-General

Lisp/-

Vidinis formaliz-mas

Pirmos eilespredikatulogika

CoC, ICoC HOL,ZF, LCF,LambdaCube ir kt.

Pirmos eilespredikatulogika

Irodymo paie²kosbudas

Herbynaudojasemantinimedi,THEO -rezoliucijumetod¡

priklausonuo nau-dojamoformalizmoir autom-atizavimotaktikos

priklausonuo nau-dojamoformalizmoir autom-atizavimotaktikos

rezoliucijumetodas

Ar naudojamostaktikos?

Ne Taip Taip Ne

Ar naudojamauºdaviniu teorijubiblioteka?

Taip, nu-matytasry²ys sui²orineTPTPbiblioteka

Taip, dau-giau kaip15 skirtinguteoriju

Taip:skai£iuteorijai,analizei,algebraiir aibiuteorijai

Ne

Irodymo paie²kosautomatizavimolaipsnis

visi²kaiautomatinepaie²ka

interaktyvipaie²ka

interaktyvipaie²ka

visi²kaiautomatinepaie²ka

Ry²ys su kitomissistemomis (API)

nera nedokumen-tuotas API

API tik i² Lispprogramu

Ar pirminis pro-gramos tekstasyra pasiekiamas?

Taip Taip Taip Taip

Palaikoma OS UNIX MacOS irWindows

Linux, MacOS ir Win-dows

UNIX

Gaunamuprogramu tipas

- funkcinesCaml pro-gramos

SML,OCaml,Haskell

Lisp

109

3.5 lentele Curry-Howard protokolo elementai [142].

Role

Curry-Howardprotokoloelementas

Elemento savybes Paskirtis

Logika Naturaliosiosdedukcijossistema

Formalioji sistema api-breºianti logini skai£iav-im¡

Uºdaviniui ir teig-iniams (angl. as-sertions) apie jiapra²yti.

Irodymai Logine tiputeorija LTT

Tipu teorija igalinantioperuoti irodymais logi-niuose skai£iavimuose,pagal Curry-Howardizomorzm¡: tipaiapibreºia sakinius,termai irodymus, otipu i²vedimas atitinkalogini i²vedim¡.

Parodo teiginiuteisingum¡ arbaklaidingum¡.

Realizacine(progra-mavimo)kalba

Skai£iavimotipu teorijaCTT

Tipu teorija programav-imo kalbos operacineisemantikai i²reik²ti

Skai£iuojamosiomsprogramoms kur-ti.

4 skyrius

Komponentiniu programu

kurimo proceso automatizavimo

metodas

io skyriaus tikslas apra²yti automatizuoto komponentiniu programukurimo metod¡, sukurt¡ remiantis ankstesniuose skyriuose analizuotais faktais.Pirmiausia 4.1. poskyryje formalizuojamas Programinio komponento Modelis,po to (4.2. poskyryje) pateikta Curry-Howard protokolo realizacija komponen-tinei paradigmai. Poskyriuose 4.3. ir 4.4. atitinkamai atskleidºiamas strukturinessintezes ir induktyviosios sintezes metodu pritaikomumas komponentinems sis-temoms kurti automatizuotu budu.

4.1. Programinio komponento modelis

Skirtinguose komponento modeliuose komponento s¡vok¡ apibreºiama skir-tingai [34, 122, 123, 134, 157, 159]. Egzistuoja kelios de²imtys formaliuju[56, 61, 51, 104, 28, 104] ir su konkre£iomis komponentinemis technologijomissusietu [122, 135, 134, 157, 183] komponento modeliu.

Daºniausiai kiekvienam komponento modeliui kuriama atskira sistema (4.1pav., a). Evoliucionuojant komponentinei paradigmai, atsiradus nauju kompo-nento modeliu i²kyla butinybe vel kurti naujus sintezes metodus, nauj¡ sintezessistem¡.

Kita galimybe, kuri¡ siulo ir disertacijos autorius abstrahuojantis nuokonkre£iu komponento modeliu savybiu operuoti tik su abstrak£iu programiniokomponento modeliu ir siulyti automatizavimo sprendimus jam (4.1 pav., b).Tokio abstraktaus komponento modelio naudojimas praple£ia sintezes meto-do naudojimo ribas, metodas tampa maºiau priklausomas nuo komponentinesparadigmos evoliucijos ir ilgiau i²laiko aktualum¡.

4.1. Programinio komponento modelis 111

4.1 pav. Galimi komponento modeliu ir sintezes sistemu s¡veikos modeliai.

iame skyriuje apra²omas disertacijos autoriaus siulomas Programinio kom-ponento modelis (PKM) gautas remiantis mokslineje literaturoje nagrinejamuir praktikoje naudojamu komponento modeliu klasiu analize.

Siekiant apibendrinti komponento modelius ju esybes i² pradºiu buvo su-skirstytos i keturias grupes (2.1.19. pav.):

• strukturines esybes,

• apra²omosios esybes,

• jungian£ios (apra²an£ios sudetiniu komponentu ir ju sistemu sudarymotaisykles),

• procesines (apra²an£ios komponentiniu sistemu vykdym¡ ir jo palaikym¡vykdymo aplinkoje, valdant tranzakcijas ir kt.).

Siekiant nustatyti, kurie komponento modeliu elementai gali buti i²skiriamibendrajame programinio komponento modelyje, taikyti du metodai: klasteriza-vimo ir ekspertinio vertinimo.

Klasterizavimo tikslas sudaryti komponento modeliu grupes, stebeti, pa-gal kuriuos poºymius modeliai galetu buti grupuojami. Klasterizuota kom-ponento modeliu savybiu lentel¦ (2.1.19. pav.) ir komponento abstrakcijoslygmenu (2.3) lentel¦ interpretuojant kaip kategoriniu kintamuju aib¦. Ats-tumams matuoti parinktas Euklido atstumo kvadrato matas. Klasterizavimasatliktas statistines analizes programa SPSS 16.0.Klasterizavimo rezultatai pateikti B priede. Gauti komponento modeliu klas-teriai apra²yti B.1. poskyryje, o komponento modeliu savybiu klasteriai B.2.poskyryje.Klasterizavimo metodas yra kiekybinis ir negarantuoja, jog yra apibendri-namos tapa£ios s¡vokos. Siekiant tikslesniu rezultatu taikytas ir ekspertinio

112 4 skyrius. Komponentiniu programu kurimo proceso automatizavimo metodas

vertinimo metodas, kurio rezultatai apra²omi 4.1.1.-4.1.2. poskyriuose. Pro-graminio komponento modelis nagrinejamas dviem aspektais: strukturiniu(4.1.1. poskyris) ir dinaminiu (4.1.2. poskyris).

4.1.1. Strukturinis programinio komponento modelio aspektas

Komponentin¦ programu sistem¡ sudaro procesu s¡ra²as PRC ir vykdymoaplinku s¡ra²as V A, procesu (jei ju daugiau kaip vienas) komunikavimo pro-tokolas InterPRC, ir vykdymo aplinku komunikavimo protokolas InterV A(jei sistema heterogenine):

KPS = 〈PRC,KK, InterPRC, InterV A〉 , (4.1)

kur InterPRC procesu komunikavimo protokolas, InterV A vykdymoaplinkukomunikavimo protokolas, PRC procesu s¡ra²as:

PRC = pr1, pr2, . . . , prp (4.2)

o V A komponentines sistemos veikimui reikalingu vykdymo aplinku

V A = va1, . . . (4.3)

Vykdymo aplink¡ komponentinese technologijose (pvz. .NET) suteikiakomponentinis karkasas (angl. framework), o kartais (pvz. EJB atveju) ir komponentus aptarnaujantys konteineriai.Jei komponentine programa yra monolitine, PRC s¡ra²¡ sudaro vienintelisprocesas. Jei programu sistema i²skirstytoji, i²vardijami visi jos procesaipr1, pr2, . . . , prp.

Bet kuris procesas apra²omas pora:

pri = 〈KSi, JKi〉 , (4.4)

kur yra KSi komponentu s¡ra²as, o JKi jungiantysis kodas.Paºymetina,kad jungiantysis kodas gali buti dvieju tipu:

• pakikliu tipo (angl. wrappers) [188, 41] jungiantysis kodas JKi apibudi-namas jung£iu jngi,j s¡ra²u;

• scenarijus [149]. is jungiamasis kodo tipas nebus nagrinejamas, nes jisnaudojamas valdymo srautu architekturoje.

Jungtys sujungia komponento prievadus. Prievadu £ia vadinami bet kokiekomponento ieities ar i²eities ta²kai [41, 61, 4]. Prievadu gali buti laikomas:interfeisas, operacija, savybe, laukas, kintamasis. Pagal lygmenis prievadusklasikuotini taip:


4.2 pav. Programinio komponento modelis


1. interfeisai,;

2. operacijos, laukai, savybes, ivykiai;

3. operaciju parametrai.

Jungtimi gali buti jungiami tik to paties lygmens prievadai. Kiekviena jungtisapra²oma:

jngi,j = 〈Pin, Pout, JT ipas〉 , jngi,j ∈ JKi, (4.5)

kur j yra jungties lygmuo, Pin ir Pout prievadai, kuriuos jungtis jungia,JT ipas jungties tipas (binding, mapping ir kt.). komponentas vaizduojamastokiu trejetu:

C =⟨PRTout, PRTin,∆,Ω

C⟩, (4.6)

kur PRTin ir PRTin yra ivesties ir i²vesties prievadu aibes atitinkamai:

PRTin = =in ∪ Ein ∪ S (4.7)

PRTout = =out ∪ Eout ∪ S (4.8)

Prievadu laikomas interfeisas, ivykis arba statinis elementas:

• =out yra =in atitinkamai siulomu paslaugu (angl. provided) interfeisai irnaudojamu paslaugu (angl. required) interfeisai:

=out =Iout1 , Iout2 , . . . , Ioutn

;=in =

Iin1 , I

in2 , . . . , I

inm

, (4.9)

∆ yra ribojimai, o ΩC komponento kvalikacijos (angl. credentials).komponento kvalikaciju ideja nagrinejama darbuose [37, 10]. Kiekvienakvalikacija apra²oma trejetu:

ΩC = 〈KV,KR,KPTM〉 , (4.10)

kur KV - kvalikacijos pavadinimas, KR jos reik²me, KPTM pasik-liautinumas, t.y. nurodoma, kokiu budu reik²me buvo suteikta (pvz.ekspertui nurodºius, eksperimento budu nusta£ius ir pan.). Kiekvienasinterfeisas I gali buti specikuojamas tokiu ketvertu:

Ii =⟨Oi, Si,Ξ,Ω

Ii ,⟩, (4.11)

kur O - interfeiso operaciju aibe:

Oi = oi,1, oi,2, . . . , oi,k ; (4.12)


S - interfeiso statiniu elementu (darbuose [78, 4] interfeis¡ realizuojan£iuklasiu lauku, ²iuolaikinese komponentinese technologijose [13, 75, ?] savybiu (angl. properties)) aibe;Ξ interfeiso invariantai, ΩI

i interfeiso I kvalikacijos. Kiekviena op-eracija oi,j specikuotina kaip ketvertas:

oi,j =⟨P,R, PreC, PostC,ΩO

i,j

⟩, (4.13)

kur P ir R yra operacijos argumentu ir rezultatu aibes atitinkamai.:

P = p1, p2, . . . , pl ;R = r1, r2, . . . , rs , (4.14)

PreC yra ºymima operacijos prie²-s¡lyga, PostC po s¡lyga. Kaipir interfeisas, kiekviena operacija turi tam tikras kvalikacijas ΩO

i,j .

• Ein ir Eout ivykiu imtuvu ir ivykio ²altiniu aibes atitinkamai.

Ein = (evin,1, evin,2 . . . evin,n) (4.15)

Eout = (evout,1, evout,2 . . . evout,m) (4.16)

• S statiniu elementu aibes (angl. properties arba elds).

S = (s1, s2 . . . sl) (4.17)

Komponentineje programu sistemoje gali buti naudojami ne tik vadinamiejihorizontalieji interfeisai, jungiantys vieno lygmens elementus (pvz. Kompo-nentus) tarpusavyje, bet ir vertikalieji interfeisai jungiantys skirtingu lygmenuelementus (pvz. Komponent¡ ir komponentini karkas¡). Komponentines pro-gramu sistemos pateikties lygmuo yra ribine sistemos dalis ir literaturoje yranagrinejama labai retai. Viena to prieºas£iu komponentu vartotojo s¡sa-ja (jos i²vaizda, ergonomi²kumas ir pan.) yra priklausoma nuo komponentukureju. Komponfentai yra juodosios deºes ir sistemu kurejai turi labai maºasgalimybes jas konguruoti.

Kita vertus vartotojai reikalavimu specikacijoje gali pateikti reikalavimusvartotojo s¡sajai, vadinasi tam, kad sukurti komponentin¦ program¡ butinatureti ir komponentu vartotojo s¡sajos (jei tokia yra) specikacijas. Pro-graminio komponento modelyje tiek komponento, tiek komponentines sistemospateiktis specikuosime taip, kaip darbe [163] apra²omas sisteminis interfeisas:

SI = 〈E,Fd, Smdp〉 (4.18)


kur E baigtine ivykiu, i kuriuos reaguojama, aibe, Fd ir Smdp savybiu iroperaciju aibes atitinkamai. Be to

E ⊂ Ein ∪ Eout (4.19)

Fd ⊂ S (4.20)

Smdp ⊂i⋃Oi (4.21)

Pastebetina, kad programinio komponento modelyje nenagrinejami uºdariejikomponentai, t.y. tokie, kuriu teikiamu prievadu aibe tu²£ia. Visiems na-grinejamiems komponentams

PRTout 6= ∅. (4.22)

Disertacijoje nagrinejami tik komponento specikacijos ir komponento re-alizacijos lygmenys, todel bus naudojamas ne visas programinio komponentomodelis, o tik tik jo dalis aktuali ²iems lygmenims (4.3 pav.).

4.1.2. Dinaminis programinio komponento modelio aspektas

Komponento modelio dinaminis aspektas parodo galimas veiksmu su kom-ponentu sekas bei apibreºia koki¡ itak¡ komponento egzemplioriu busenoms(jei tokios stebimos) daro vienos ar kitos operacijos, apra²ytos interfeise [138].Programinio komponento modelyje ²i aspekt¡ nusako kontraktas. Skiriami dukontaktu tipai [10, 34]:

1. komponento kontraktas, nusakantis komponento teikiamas ir reikalau-jamas paslaugas [159, 121],

2. s¡veikos kontraktas nusakantis roles, kurias komponentas atlieka sis-temoje [46, 10, 162].

Programinio komponento modelyje komponento kontraktas nusakomas ²iuoketvertu:

Ctr = 〈I, Init,Ξ, CP 〉 , (4.23)

kur I interfeisas, kuri apra²o kontraktas, Init inicializavimo funkcija, Ξ interfeiso invarinatai, CP protokolas apra²antis, kokia tvarka gali buti kvie£i-amos operacijos, kokie yra ribojimai joms. Kokiomis priemonesmis nusakomiribojimai komponentams kituose lygmenyse parodyta 4.1 lenteleje.

komponentiniam protokolui apra²yti naudojama viena i² ²iu priemoniu:

1. CSP (Communicating sequential processes) specikacija [40];

2. Apra²ant busenas, ivykius ir leistinus veiksmus [142, 31];


4.3 pav. Programinio komponento specikacijos ir realizacijos lygmenu kom-ponento modelis.


3. Prane²imu sekomis [19];

4. S¡veikos ²ablonais [123].

4.1.3. Komponavimo kalba

Komponavimo kalba [1], turi tureti kalbos konstrukcijas skirtas apra²ytivisus tris komponentines paradigmos elementus: komponento modeli, kom-ponavimo technik¡ ir pa£i¡ komponavimo kalb¡. U. Abman taip pat ivedakomponavimo receptu (angl. composing recipes), kurie ir apra²omi butentkomponavimo kalba, s¡vok¡. Komponavimo receptai gali igauti ivairias for-mas. Darbe [1] pateikiami ²ie komponavimo receptu pavyzdºiai:

• scenarijai (pvz.: [149]),

• vizualiuju kalbu konguracijos (editing sequences),

• taisykliu rinkiniai,

• programos funkcinemis kalbomis,

• imperatyviosios programos.

U. Abman i²kelia ²ios reikalavimus komponavimo kalboms:

1. Produkto derme (angl. product-consistency). Komponavimo receptaituri uºtikrinti komponuojamos sistemos derm¦/neprie²taringum¡. Kom-ponavimo kalba turi pasiºymeti konkre£iomis savybemis, kurios galimabutu patikrinti.

2. Programines irangos proceso palaikimas (angl. software-processsupport).

4.1 lentele Ribojimu lygmenys.Lygmuo Konceptas ElementaiOperacijos PreC, PostCInterfeiso Ii Ξ−−invariantai

Ctr Ξ− invariantaiCP -protokolas

komponento C ∆− ribojimaiProgramu sistemos KPS InterPRC-protokolasHeterogenines programu sistemos KPS InterV A-protokolas


4.4 pav. Akademiniu komponento modeliu ry²ys su Programiniu komponentomodeliu.


4.5 pav. Komponentiniu technologiju ry²ys su Programinio komponento mod-eliu


3. Metakomponavimas. Patys komponavimo receptai taip pat privalobuti komponentiniai.

Praktikoje naudojamos ivairios komponavimo kalbos. Beveik kiekvienamei² 2.1. skyriuje apºvelgtu komponento modeliu naudojama vis atskira kompon-avimo kalba: CDL [161], TrustME [141], rCOS [77], RADL [146], FML [82],konkurencine logika [123]. Pana²esniais galima butu laikyti tik du sprendimus:[188] naudojama XML kalba, o [148] jos pagrindu sukurta kalba SADL.PECOS komponento modelis yra ypatingai idomus £ia naudojomos net dvikalbos: πL ir PICOLLA.

Tokia pat ivairove pastebima ir analizuojant populiariausiais komponen-tines technologijas: JavaBeans naudojama BML kalba [186], CCM CSD/CAD[135], pasaulinio tinklo paslaugu modelyje [184]. Idomu tai, kad CORBA,.NET ir EJB komponento modeliuose atskira komonavimo kalba nenaudojama,komponentai jungiami programiniu kodu.

Palyginus komponavimo kalbas, matyti, kad pla£iausiai naudojama XMLkalba arba jos pagrindu sukurtos kalbos [148, 135, 184, 186, 188, 18]. Be to, kadXML yra pla£iausiai naudojama kalba specikavimui, padedanti spr¦sti nesud-erinamumo problemas teigia ir K. Vaithed (Katerine Whitehead) [188]. Anotjos naudojant XML nebelieka parametru sekos nesutapimo problemos, kadan-gi kiekvienas parametras XML faile yra identikuojamas ne pagal pozicij¡ opagal gair¦ (angl. tag). Del i²vardintu prieºas£iu disertacijoje komponavimuispecikacijos lygmenyje taip pat bus naudojama XML kalba.


4.2. Komponentine Curry-Howard protokolo realizaci-

ja

4.2.1. Loginis skai£iavimas komponentinei paradigmai

Komponentines sistemos gali buti formalizuojamos ivairiomis priemonemis:λ-skai£iavimu [128], π-skai£iavimu [149], Petri tinklais [145], koalgebromis [77].ioje disertacijoje programinio komponento modelis nagrinejamas komponentospecikacijos ir komponento realizacijos abstrakcijos lygmenyse, todel jam for-malizuoti pasirinktas intuicionistinis teiginiu skai£iavimas (ITS):

ITS = 〈Formulae(ITS),`ITS , DR〉 , (4.24)

• Formulae(ITS): Didºiosiomis raidemis (pvz X) su indeksais (arba beju) ºymesime teiginius Programinio komponento Modeli atitinkantis kom-ponentas turi prievad¡ X ir toliau juos vadinsime propoziciniais kinta-maisias (angl. proposition variable):

X ∈ PRTin ∪ PRTout (4.25)

I²skiriamas atskiras propoziciniu kintamuju atvejis valdymo kintamieji.ie propoziciniai kintamieji ºymimi didºiosiomis arba maºosiomis raidemisi² abieju pusiu apimant lauºtiniais skliaustais, pavyzdºiui:

[PuslapisAtspausdintas]. (4.26)

Be propoziciniu kintamuju dar naudojama konjunkcija (∧), implikacija(→) ir skliaustai (()).Taisyklingu formuliu sudarymo taisykles apibreºiamos rekursyviai:

1. Kiekvienas termas yra formule.

2. Jei A yra formule, tai (A) taip pat formule.

3. Jei A ir B yra formules, tai A ∧B formule.

4. Jei A ir B yra formules tai A→ B formule

Kiekvieno komponento struktura apibreºiama tokio pavidalo aksiomomis:∧Xi →

∧j

Yj (4.27)

4.2. Komponentine Curry-Howard protokolo realizacija 123

4.6 pav. Komponento prievadu loginiu s¡ry²iu pavyzdºiai

Pavyzdºiui, jei ºinoma komponento ivesties ir i²vesties prievadu tar-pusavio priklausomybe (4.6 pav., b), komponentas specikuojamas aksiomuaibe :

((A1 ∧D) ∧R)→ I1 (4.28)

A2→ E (4.29)

R→ I2 (4.30)

Jei komponento ivesties ir i²vesties prievadu tarpusavio priklausomybeneºinoma (o taip gali buti, jei komponentas juodoji deºe, 4.6 pav., a),komponentas specikuojamas viena aksioma :

A1 ∧A2 ∧D ∧R→ I1 ∧ I2 ∧ E (4.31)

• Naudosime intuicionistinio teiginiu skai£iavimo i²vedimo taisykles (DR)pateiktas 4.2 lenteleje.

Disertacijoje nenagrinejami idiegto komponento ir komponentinio objektolygmenys, todel programinio komponento modelyje neatsispindi ir ²iems lyg-menims budingos esybes, tokios kaip lygiagretieji konkurenciniai procesai. Pro-graminio komponento modeliui formalizuoti pasirinkto intuicionistinio teiginiuskai£iavimo rai²kos geba yra pakankama.

4.2.2. Logine tipu teorija komponentinei paradigmai

iame poskyryje apra²oma logine tipu teorija (LTT), sukurta intuicionis-tinio teiginiu skai£iavimo (ITS) pagrindu:

LTT (ITS) =⟨PT (LTT ), Formulae(LTT ), (.)(.),`LTT , PTR, .

⟩(4.32)


4.2 lentele ITS i²vedimo taisykles (DR).Ivedimo taisykles Eliminavimo taisykles

Γ ` A Γ ` BΓ ` A ∧B (∧I) Γ ` A ∧B

Γ ` A (∧EL) Γ ` A ∧BΓ ` B (∧ER)

Γ, u : A ` BΓ ` A→ B

( → Iu) Γ ` A→ B Γ ` AΓ ` B (→ E)

4.3 lentele LTT tipaiPT (LTT ) elementas LTT tipas〈M,N〉 A ∧Bfst N A , jei NA∧B

snd N B , jei NA∧B

λu : A.M A→ B

• PT (LTT ) irodymu termu aib¦ sudaro ²ie elementai:

1. didºiosiomis raidemis ºymimi elementarus termai (pvz. M) prik-lausantys poaibiui V arPT (L);

2. 〈M,N〉 pora;

3. fst N pirmoji projekcija;

4. snd N ; antroji projekcija;

5. λu : A.M - lambda termas;

6. MN - termu aplikacija.

• Formulae(LTT ) termu tipai apra²yti 4.3 lenteleje.

• Tipizavimo s¡ry²is (p)(T ), apibreºtas tarp irodymo termu p ∈ PT (LTT )ir tipu T ∈ Formulae(LTT ).

• I²vedimo taisykles (PTR) Logines tipu teorijos i²vedimo taisykles paro-dytos 4.4 lenteleje.

• Normalizavimo s¡ry²is . apibreºtas vir² irodymu termu PT (L), apiben-drintas tranzityvus vieno ºingsnio redukcijos uºdarinys (angl. closure).Ji apibreºia ²ios redukcijos taisykles:

fst (< a, b >(A∧B)) .LTT aA

snd (< a, b >(A∧B)) .LTT bB

4.3. Strukturines programu sintezes elementai 125

4.4 lentele LTT i²vedimo taisykles (PTR).Ivedimo taisykles Eliminavimo taisykles

Γ `MA Γ ` NB

Γ `< M,N >A∧B(∧I) Γ `MA∧B

Γ ` fst MA(∧EL) Γ `MA∧B

Γ ` snd MB(∧ER)

Γ, uA `MB

Γ ` λu.MA→B ( → Iu) Γ ` A→MB Γ ` NA

Γ `MNB(→ E)

4.2.3. Tipu teoriju atitiktis

4.5 ir 4.6 lentelese pateiktos LTT ir CTT termu bei formuliu atitiktys,kurios yra naudojamos komponentinei programai gauti. iuo atveju pro-grama vadinama XML kalba apra²yta komponentines programu sistemosarchitektura, kuri gali buti realizuota pasirinkta programavimo kalba arbapanaudota tiesiogiai (pvz., atlikus XSLT i WSDL kalb¡).

Atliekant etype transformacij¡ (4.5 lentele) kartu tikrinama ar logines tiputeorijos formule nera Harropo [76] formule. Taip i² irodymo termu pa²alinamanekonstruktyvioji informacija. Pagal irodymo ºingsnius atitinkamai generuo-jama programa.

Pagal apibreºim¡ [76, 142] formule F vadinama Harropo [76] formule jeitenkinama bent viena s¡lyga:

• F yra pagrindine (angl. atomic) formule;

• F yra (A ∧B) pavidalo, kur A ir B - Harropo formules;

• F yra (A→ B) pavidalo, kur B yra Harropo formule;

Toliau predikat¡ formule F yra Harropo formule ºymesimeH(F ), o predikat¡formule F nera Harropo formule ºymesime ¬H(F ).

Disertacijoje apra²omame automatizuoto komponentiniu programu sistemukurimo metodas ne tik realizuoja Curry-Howard protokol¡, bet ir naudojakitu generavimo metodu elementus. Tolimesniuose poskyryje apra²oma kuriekonkretus strukturines programu sintezes (4.3. poskyris) ir induktyviojo (4.4.poskyris) metodu elementai panaudoti disertacijoje apra²omame generavimometode.

4.3. Strukturines programu sintezes elementai

Kaip jau mineta, strukturines programu sintezes metodas (ºr. 3.3. skyriu)buvo sukurtas programoms generuoti i² moduliu, veliau tirtos jo pritaikymo


4.5 lentele LTT ir CTT termu atitikties funkcija etype(F ).LTT termas F etype(F )

P komponentas

(P ) komponentas

(A ∧B) etype(A) jei ¬H(B)etype(B) jei ¬H(A)etype(A) ∗ etype(B) kitais atvejais

(A→ B) etype(B) jei ¬H(B)etype(A)→ etype(B) kitais atvejais

objektinei ir paslauginei paradigmoms galimybes. iame poskyryje pateikiamitik tie jo elementai, kurie papildo Curry-Howard protokolo realizacij¡ ir galibuti naudojami kaip automatizuoto komponentiniu programu kurimo metododalis.

Irodomojo programavimo metodu klase, kurios naudojim¡ apibendrina Curry-Howard protokolas, apima ir strukturines programu sintezes metod¡. Konkre£i-ai disertacijoje apra²omoje Curry-Howard protokolo realizacijoje panaudoti ²ieSSP elementai:

1. teiginiu i²vedimo intuicionistiniame teiginiu skai£iavime taisykles (4.2lentele),

2. uºdavinio sprendinio egzistavimo teoremoms irodyti naudojama ATP,realizuojanti strukturines sintezes algoritmus,

3. uºdavinio formulavimo budas. Komponentiniu sistemu sintezes uºdavinioatveju pakartotinai panaudojami artefaktai yra komponentai. Ta£iau sin-tezes procese veiksmai su komponentais atliekami prievadu lygmenyje:

rasti P out1 , P out2 , . . . , P outn ,ΩC turint P in1 , P in2 , . . . , P inm remiantis M.

kur P outP Pr P inj yra komponento i²vesties ir ivesties prievadai, ΩC komponento kvalikacijos. Kiekvienas propozicinis kintamasis atitin-ka konkretu prievad¡, o kiekviena aksioma apra²o ry²i tarp ivesties iri²vesties prievadu.


4.6 lentele LTT ir CTT formuliu atitikties funkcija extract(pT ).LTT formule (pT ) extract(pT )

Bet kuris irodymo termas pT (), jei H(T )

uA xujei ¬H(A)() jei H(A)

⟨aA, bB

⟩(extract(a), extract(b))

fst a fst (extract(a))

snd a snd (extract(a))

cA→BaA extract(c) jei H(A)(extract(c) extract(a)) jei ¬H(A)

Analizuojant strukturines sintezes metod¡ nustatyta, kad ji naudojant kompo-nentiniu programu sintezes sistemoje gali kilti ²ios problemos [64]:

• Nei²samios specikacijos problema. Jei vartotojo pateikta speci-kacija yra netiksli arba su klaidomis, sintezes rezultatas nekorekti²kas.Kitos uºdavinio specikavimo auk²to lygmens kalba problemos (pvz.,specikavimo kalbos rai²kos geba, patogumas vartotojui) nera budingosvien SSP metodui [62, 63], todel £ia nebus nagrinejamos.Klasikinis SSP metodas negali buti panaudojamas kitokio nei valdymosrautu ir duomenu srautu architekturos stiliu programoms kurti. S. Lam-merman ir E. Tyugu darbe [102] pasiulytas i²plestasis SSP metodas (ES-SP) igalina kurti objektinio architekturos stiliaus programas, geban£iasreaguoti i i²imtis (angl. exception). Ta£iau ir ESSP nesuteikia galimybeskurti ivykiais valdomo architekturos stiliaus programas.

• Neapibreºtuju komponentu problema. Kaip mineta 2.4. skyriuje,komponentiniu programu sistemu gyvavimo ciklas skiriasi nuo strukturi-niu programu gyvavimo ciklo, todel kurimo pradºioje daºniausiai neraºinomi visi sistemai sukurti reikalingi komponentai. Tuo tarpu naudo-jant strukturines sintezes metod¡, daroma prielaida, kad visos aksiomosturi jas realizuojan£ius komponentus ir reikia tik i²spr¦sti ju pasirinki-mo uºdavini. Sintezes sistemai neradus reikiamos aksiomos (o kartu irkomponento) daroma i²vada, kad uºdavinys nei²sprendºiamas. Sintezes


sistema negali nustatyti, kokiu konkre£iai aksiomu ir kokiu konkre£iaikomponentu truksta.

Kita aktuali problema - SSP reikalavimas, kad visos busimosios pro-gramos sudetines dalys (²iuo atveju, komponentai) butu specikuotosprie² sintezes proces¡. SSP metodo kurejai daro prielaid¡, jog visi reiki-ami komponentai jau yra, tik reikia i²spr¦sti ju pasirinkimo uºdavini.Jei nors vienas sistemai sukurti reikalingas komponentas neapra²ytas ak-sioma, gali susidaryti situacija, kai teoremai irodyti pritruks butent ²iosaksiomos.Tuo tarpu vienas i² komponentiniu programu kurimo etapu yra kompo-nentu paie²ka [149]. Be to, ²i paie²ka turi buti vykdoma realizacijoslygmenyje, jau suprojektavus programu sistem¡. Vienas i² galimu neapi-breºtuju komponentu problemos sprendimo budu - pakeisti irodymo paie²kosalgoritm¡.

Tarkime, kad M - sintezes uºdavinio aksiomu aibe. Kiekviena aksiomam turi pavidal¡:

u1, u2, . . . uk −→ v1, v2, . . . vl, (4.33)

K - visu bent vienai aksiomai priklausan£iu propoziciniu kintamuju aibe:

∀i, jui, vj ∈ K (4.34)

o A - algoritmas, analizuojantis aibes K ir M , ie²kantis teoremos

p1, p2, . . . pn −→ r1, r2, . . . rm;∀i, jpi, rj ∈ K (4.35)

irodymo. Tarkime, kad A baige darb¡, ta£iau teoremos irodymas nebuvorastas. Tada aibe M papildoma virtualiomis aksiomomis:

a : u1, u2, . . . uk −→ v1, v2, . . . vl, k, l > 0, a ∈M ′ (4.36)

ir gautai aibei M ′ = M ∪M ′′ vel taikomas algorimas A. Galima irodyti,kad aibeje M ′ algoritmas A visada baigs darb¡ ir ras maºiausiai vien¡sprendini.

Virtuliosiomis aksiomis (VA) vadinamos aksiomos, apran£ios vienu propo-ziciniu kintamuju reik²miu gavimo naudojant kitu propoziciniu kintamujureik²mes, ta£iau neturin£ios realizacijos. Turimu komponentu aibeje neranei vieno tokio, kuris butu susij¦s su kokia nors VA ry²iu vienas-su-vienu.

Algoritmui A baigus darb¡ ir radus teoremos irodym¡, sintezes sistemosnaudotojui tampa prieinama informacija apie tai, kokios VA irodyme turi


4.7 lentele SSP algoritmu sudetingumas laiko atºvilgiu.Programos struktura Sudetingumastiesine c1 · n2

besi²akojanti c1 · n2 · 2nsu pouºdaviniais c1 · n3 · 2n

buti panaudotos, o tai savo ruoºtu parodo, kokiu komponentu trukstagauti galutiniam rezultatui - komponentinei programai.

Metodas yra gana paprastas, ta£iau turi ir trukumu. Ivertinkime papildo-mu aksiomu ivedimo itak¡ teoremos irodymo paie²kos algoritmui. Tarkime,kad po papildymo aibejeM ′ yra visos aksiomos, kokias tik galima sudary-ti i² K aibes propoziciniu kintamuju. Tada, bendras aibes M ′ aksiomuskai£ius bus

n(M ′) =k∑i=1

Cik ·k∑j=1

Cjk, (4.37)

kur k propoziciniu kintamuju aibeje K skai£ius.Atmeskime i² ²ios aibes A −→ A pavidalo aksiomas, nes, kaip minetaanks£iau, tokio tipo aksiomos laikomos trivialiomis ir daºniausiai ne-naudojamos. Tokiu aksiomu gali buti tiek, kiek yra skirtingu gretiniusudarytu i² aibes K elementu, todel:

n(M ′) =k∑i=1

Cik ·k∑j=1

Cjk −k∑i=1

Cik =k∑i=1

Cik(k∑j=1

Cjk − 1). (4.38)

Yra ºinoma [105], kadk∑i=0

Cik = 2k,

todeln(M ′) = (2k − 1)(2k − 2) ≈ 22k. (4.39)

Palyginus gautus rezultatus su [166] pateiktais SSP algoritmu sudetingumoiver£iais (4.7 lentele) matyti, kad papildomu aksiomu ivedimas gali labaipadidinti irodymo paie²kos laik¡.

Kita vertus, didelis VA skai£ius gali sukelti irodymo nevienareik²mi²ku-mo ir rezultatu nepatikimumo problemas.Kuo daugiau virtualiuju aksiomu yra ivesta, tuo daugiau skirtingu teo-remos irodymu gali buti rasta. Jei kiekviename i² ²iu irodymu yra


panaudota bent viena VA, tai sekmingam sintezes procesui reikia rastij¡ atitinkanti komponent¡. Jei atitinkamas komponentas neegzistuoja,sintezes sistemos naudotojas gali ji sukurti, arba atmesti nagrinejam¡teoremos irodym¡ kaip nepagrist¡ ir proces¡ t¦sti su kitu gautu irodytu,kitais komponentais. Ivertinus komponentu paie²kos ir skirtingu irodymuivertinimo laik¡, galima teigti, kad sintezes procesas pailgeja.Didelis virtualiuju aksiomu skai£ius leidºia irodyti beveik bet koki¡ 4.35pavidalo teorem¡. Teorema neirodoma tik tuo atveju, jei jos s¡lygojeyra bent vienas propozicinis kintamasis nepriklausantis aibei K. Del ²iosprieºasties gali buti surastas toks teoremos irodymas, kad VA atitinkan-tys komponentai arba neegzistuoja, arba yra nesuderinami semantineprasme. Pavyzdºiui, teoremos irodyme panaudota aksioma

PinigineSuma −→ TaskoEkraneSpalva

neturi j¡ realizuojan£io komponento.

4.4. Induktyviojo metodo elementai komponentiniu

programu sistemu kurimo metode

Vienas induktyviojo metodo privalumu, lyginant ji su dedukciniu metodu galimybe atlikti loginiu programu sintez¦ remiantis ir nebaigtomis speci-kacijomis [125, 71]. i¡ metodo savyb¦ galima panaudoti ir komponentiniuprogramu specikacijos problemai spr¦sti.

Tokiu atveju generavimo procesas pasipildytu dar vienu etapu, kuriameindukcijos budu butu tikslinamos nebaigtos ar nekorekti²kos specikacijos. Po²io etapo sektu specikacijos analizavimo ir irodymo paie²kos etapai.

Kaip teigiama [125], induktyvusis metodas padeda nustatyti ry²ius tarpkonceptu. Pastaroji metodo savybe yra labai svarbi sprendºiant neapibreºtujukomponentu problem¡. Generavimo procese po irodymo paie²kos etapo siulomaiterpti dar vien¡ etap¡, kuriame butu analizuojama del kokiu prieºas£iu nepa-vyko irodyti teoremos. Jei teoremos irodymo etape gautas teigiamas rezul-tatas (t.y. teorema irodyta) vadinasi uºdavinys i²spr¦stas ir neapibreºtujukomponentu problemos nera. iuo atveju papildomas etapas butu tiesiogpraleidºiamas. Ta£iau, jei teoremos irodyti nepavyko, papildomame etape nau-dojant indukcijos metod¡, butu bandoma nustatyti, kokiu aksiomu truksta ir arjos gali buti realizuotos. Papildºius uºdavinio specikacij¡ naujomis generuo-tomis aksiomomis butu vel griºtama prie teoremos irodymo etapo.

Tam, kad butu i²spr¦sta nefunkciniu reikalavimu problema, generavimometodas turi uºtikrinti galimyb¦ ivertinti komponentus nefunkciniu reikalavimuatºvilgiu, t.y. sistema turi gebeti i² komponentu aibes parinkti toki kompo-nent¡, kurio veikimo sparta, apsaugos lygmuo ir kitos nefunkcines savybes

4.5. Metodo taikymo pavyzdºiai 131

geriausiai atitinka specikacij¡. Induktyvusis metodas galetu padeti nustatytikomponentu alternatyvas sistemos nefunkciniams reikalavimams patenkinti.Be to, induktyvusis metodas naudotinas ie²kant auk²tesnio lygmens desningumu(angl. high-level regularities) [125], o tai gali padeti ie²kant bendresniu kompo-nentu ar ju prievadu.

Induktyviojo metodo elementus komponentiniu programu sistemu gener-avimo procese siuloma naudoti siekiant i²spr¦sti ²ias problemas:

• specikacijos problem¡;

• neapibreºtuju komponentu problem¡;

• nefunkciniu reikalavimu problem¡.

Ta£iau, siekiant i²vengti nekorekti²ko rezultato, visos sintezes metu padarytosinduktyviosios i²vados privalo buti papildomai tikrinamos.

4.5. Metodo taikymo pavyzdºiai

Panagrinesime du supaprastintus komponentiniu programu sistemu kurimopavyzdºius.

4.5.1. Vaistu dozatoriaus programa

Reikia sukurti programu sistem¡ pagal asmens zinius duomenis rekomen-duojan£i¡ tam tikro medikamento doz¦.Turimi komponentai:

1. Komponentas CKMI, gebantis pagal asmens zinius duomenis apskai£i-uoti ºmogaus kuno mases indeks¡ (KMI). is komponentas realizuojainterfeis¡ IKMI:

interface IKMI

float KMIcalc(float svoris, float ugis)

jokiu kitu prievadu nera, komponent¡ apra²o vienintele aksioma:

→ IKMI (4.40)

2. Komponentas CMD, gebantis pagal paciento kuno mases indeks¡ ap-skai£iuoti maksimali¡ leistin¡ vaistu doz¦. is komponentas realizuojainterfeis¡ Idoze:


interface Idoze

float doze(int kartai, time periodas, float kiekis)

komponent¡ apra²o aksioma:

IKMI → Idoze (4.41)

3. Komponentas CVR, gebantis apskai£iuoti rekomenduojam¡ pagal vaistudoz¦ atsiºvelgiant i maksimalios leistinos vaistu dozes reik²m¦. is kom-ponentas realizuoja interfeis¡ IVR:

interface IVR

float rd(Collection simptomai, float kmi, int amzius)

ir reikalauja komponentu realizuojan£iu tokius interfeisus: IMKI, Idoze.Komponent¡ apra²o aksioma:

IKMI, Idoze→ IV R (4.42)

Komponentines programos uºdavini uºra²ysime kaip teorem¡:

→ IV R (4.43)

Paeiliui taikydami i²vedimo taisykles gauname teoremos irodym¡:

→ IKMI IKMI → Idoze→ Idoze IKMI, Idoze→ IV R

IKMI, Idoze→ IV R

4.5.2. Videomedºiagos transliacija

Tarkime, kad komponentu saugykloje yra keturi komponentai, skirti vaizdomedºiagos apdorojimui:

1. Vaizdo medºiagos konvertavimo (VMK) komponentas. Komponentasvien¡ pasirikto vaizdo formato rinkmen¡ konvertuoja i kito pasirikto vaiz-do formato rinkmen¡. Jei yra idiegti papildomi kodekai, komponentasgeba dirbti su ²iu formatu rinkmenomis: *.avi, *.mpeg, *.wmv :

4.5. Metodo taikymo pavyzdºiai 133

(AV I →MPEG)→ ([r]→MPEG)

(AV I →WMV )→ ([r]→WMV )

(WMV → AV I)→ ([r]→ AV I)

(WMV →MPEG)→ ([r]→MPEG)

(MPEG→WMV )→ ([r]→WMV )

(MPEG→ AV I)→ ([r]→ AV I)

2. Kodekas K1 komponentas realizuoja duomenu konvertavimo i² *.avi i*.wav format¡ algoritm¡:

AV I →WMV (4.44)

3. Kodekas K2 komponentas realizuoja duomenu konvertavimo i² *.mpegi *.avi format¡ algoritm¡:

AV I →MPEG (4.45)

4. Vaizdo medºiagos transliavimo internetu komponentas (VMT), kurio ivestis*.wav formato vaizdo rinkmena, o i²vestis - transliacija internetu:

WMV → [t] (4.46)

Spr¦skime toki uºdavini reikia sukurti programu sistem¡, kuri bet kuri¡AVI formato laikmen¡ transliuotu internetu:

[r], AV I → [t] (4.47)

Teoremos irodymas:

AV IAV I →WMVAV I →WMV (AV I →WMV )→ ([r]→WMV )

[r]→WMV WMV → [t]

[r]→ [t]



1. I²analizavus komponento modelius, reprezentuojan£ius esamas ju klases,nustatyta:

• Gali buti sukurtas apibendrintas programinio komponento modelis.

• Komponento specikacijos ir realizacijos lygmenyse naudojamasapibendrintas programinio komponento modelis turi buti sudary-tas i² ²iu elementu: komponento, prievado, jungties, kontrakto,ribojimu, kvalikaciju ir komponentines sistemos.

2. Programu sintezes uºdavinys ir jo sprendimo budas gali buti taip sufor-muluoti apibendrinto komponento modelio terminais, kad gautas sprendi-nys gali buti pritaikomas kiekvienam i² apibendrintu komponentu modeliupanaudojant konkretizavimo, patikslinimo ir papildymo operacijas.

3. Programu sintezes metodas, komponentineje paradigmoje realizuojantisCurry-Howard protokol¡, igalina automatizuotu budu kurti komponen-tines programas ir uºtikrina ²iu programu atitikti specikacijai.

5 skyrius

Komponentiniu sistemu

generavimo metodo realizacija

iame skyriuje apra²oma disertacijos autoriaus sukurta komponentiniu prog-ramu sintezes sistema SoCoSyS1. i sistema sukurta siekiant realizuoti ireksperimenti²kai patikrinti 3 skyriuje pasiulyt¡ komponentiniu programu sistemugeneravimo metod¡. io skyriaus tikslas apra²yti metodo tikrinimo eksperi-ment¡ ir jo rezultatus.

5.1. SoCoSyS sistema

Metodas, kuri realizuoja SoCoSyS sistema operuoja dviejuose kompo-nento abstrakcijos lygmenyse: komponento specikacijos ir komponento real-izacijos. Kadangi generavimo proceso rezultatas priklauso nuo lygmens, nuolygmens priklauso ir pati generavimo sistema. Kas yra budinga komponentospecikacijos lygmeniui skirtai generavimo sistemai, aptarsime 5.1.2. poskyry-je, kas budinga komponento realizacijos lygmeniui 5.1.3. poskyryje, o £ia (5.1.poskyryje) aptarsime bendrus abiems lygmenims generavimo sistemos elemen-tus.

SoCoSyS sistemos ivestimi yra uºdavinio specikacija, uºdavinio teorijair pakartotinai panaudojami artefaktai komponentai. SoCoSyS sistemosbendrieji elementai yra ²ie (5.2 pav.):

• analizatorius (angl. parser),

• planavimo modulis,

1pavadinimas parinktas naudojant pirm¡sias sistemos paskirties apibudinimo anglu kalba Software Component Synthesis System raides.

136 5 skyrius. Komponentiniu sistemu generavimo metodo realizacija

• optimizavimo modulis,

• architekturos generatorius,

Analizatorius kaip argumentus naudoja i² uºdavinio specikacijos atskirtusfunkcinius reikalavimus. Juos i²skaido i ivesties bei i²vesties kintamuosius irsuformuoja uºdavinio medi uºdavini vaizduojan£i¡ duomenu struktur¡.

Planavimo modulis pagrindine sistemos dalis. Ji, kaip argumentus imauºdavinio medi ir uºdavinio teorij¡. Modulio rezultatas yra konstruktyvusis uº-davinyje nurodytos teoremos irodymas. Planavimo modulio vaidmeni sistemo-je atlieka automatinio teoremu irodymo programa. Eksperimento metu nau-dota disertacijos autoriaus sukurta ATP SoCoProove (ºr. 5.1.1. poskyri), norsgalima naudoti ir kuri¡ nors kit¡ ATP, geban£i¡ irodyti intuicionistinio teiginiuskai£iavimo teoremas bei tenkinan£i¡ kitus reikalavimus (ºr. 3.2.2. poskyri).

Optimizavimo modulio tikslas eliminuoti nereikalingus irodymo ºingsnius.ie pertekliniai ºingsniai gali buti generuojami planavimo moduliui vykdantprielaidomis grist¡ paie²k¡ pirmyn (angl. assumption driven forward search).

Jei irodymas rastas, generatorius naudodamas gaut¡ konstruktyvuji iro-dym¡ generuoja program¡.

Programos savoka priklauso nuo nagrinejamo komponento abstrakcijoslygmens. Atskiros sintezes sistemos ²akos, adaptuotos konkre£iam lygmeniui,apra²ytos 5.1.2. ir 5.1.3. poskyriuose atitinkamai.

5.1.1. Teoremu irodymo programa SoCoProove

SoCoProove yra disertacijos autoriaus sukurta automatinio teoremu irody-mo programa, atliekanti veiksmus intuicionistinio teiginiu skai£iavimo pagrindusukurtoje logineje tipu teorijoje (4.2.2. poskyris).

SoCoProove realizuoja tris irodymo paie²kos algoritmus: A1 (3.3.2.2. posky-ris), A2 (3.3.2.3. poskyris) ir A3 (3.3.2.4. poskyris). Programa nepriskiria-ma interaktyviuju teoremu irodymo programu klasei, teoremos paie²ka vykstavisi²kai automatiniu budu, be galimybes pateikti papildomus parametrus (pvz.parinkti taktikas) paie²kos metu. i ATP neturi granes ar komandines eilutess¡sajos, ji skirta naudoti kitose sistemose kaip API funkciju biblioteka. SoCo-Proove naudojamos duomenu strukturos pavaizduotos 5.1 pav., o SoCoProoveprograma ir jos pirminis tekstas vie²ai skelbiami http://ik.su.lt/∼vaigie/socosys/svetaineje.

SoCoProove teoremu irodymo programa bendroje SoCoSyS sistemoje at-lieka planavimo modulio (5.2 pav.) vaidmeni.

5.1. SoCoSyS sistema 137

5.1 pav. SoCoProove klasiu diagrama.

5.1.2. Komponento specikacijos lygmens programu sintezessistema

ios sintezes sistemos rezultatas (anks£iau vadintas programa) programuarchitektura nusakanti komponentu jungimo schem¡ (5.2 pav.). SoCoSyS

sistemoje komponentines programos architektura apra²oma XML pagrindusukurta kalba. Naudojant XSLT transformacijas ²i¡ schema galima automa-tiniu budu uºra²yti ir kita (pvz. WSFL ar SCA modelyje naudojama) kalba.komponentiniu programu sintezes sistema privalo buti pritaikyta gyvavimociklui I²rink-Pritaikyk-Bandyk, todel ji, skirtingai nei dauguma generavimoprogramu, i²saugo informacij¡ apie sintezuotu programu architekturas.

Generatorius naudodamas teoremos irodym¡ generuoja komponentu jungi-mo schem¡, j¡ i²saugo architekturu bazeje ir pateikia kaip sintezes procesorezultat¡.komponento specikacijos lygmens programu sintezes sistema automatizuoja²iuos komponentiniu programu sistemu gyvavimo ciklo etapus:

• komponentu atranka ir ivertinimas,

• sistemos architekturos projektavimas.


5.2 pav. Komponento specikacijos lygmens programu sintezes sistema.

komponento specikacijos lygmenyje neatsiºvelgiama i nefunkcinius reikalav-imus komponentinei sistemai ir pa£iu komponentu kvalikacijas. Komponentualternatyvu parinkimas ivertinant nefunkcinius reikalavimus paliekamas tolimes-niam etapui.

SoCoSyS naudojamos duomenu strukturos pavaizduotos 5.3 pav., o patiSoCoSyS programa ir jos pirminis tekstas vie²ai skelbiami svetainejehttp://ik.su.lt/∼vaigie/socosys/.

5.1.3. Komponento realizacijos lygmens programu sintezes sis-tema

komponento realizacijos lygmens programu sintezes sistemos rezultatas komponentines programu sistemos realizacija, t.y. Komponentine programa.

Skirtingai nei specikacijos lygmens sintezes sistemoje, £ia naudojami dugeneratoriai. Architekturos generatorius savo darbo rezultat¡ komponentujungimo schem¡ perduoda programos generatoriui. Pastarasis komponentubazeje suranda reikiamus komponentus ir istatydamas juos i apibreºtas vi-etas, generuoja program¡. (5.4). Siekiant visi²ko suderinamumo su I²rink-Pritaikyk-Bandyk gyvavimo ciklu, sistema atsiºvelgia ir i nefunkcinius reikalav-imus. Tai sistemoje atlieka antrasis optimizavimo modulis. is modulis naudo-damas anks£iau i²saugot¡ jungimo schem¡ i² komponentu bazes parenka tok-ius komponentus, kurie geriau uºtikrina, kad programa tenkintu nefunkciniusreikalavimus ir jais (komponentais) pakei£ia jau esan£ius sistemoje. Eksperi-mentinio sistemos testavimo metu buvo naudoti komponentai, su ne daugiaukaip viena kvalikacija, todel tinkamesnio komponento paie²ka yra elemen-

5.1. SoCoSyS sistema 139

5.3 pav. SoCoSyS sistemos klasiu diagrama

tari. Tuo atveju, jei komponentai galetu tureti neribot¡ skai£iu skirtingukvalikaciju, komponento kokybes klausimas galetu buti sprendºiamas taikantstandartines proceduras, pavyzdºiui laikantis ISO/IEC TR 9126 standarto [87].

Neapibreºtuju komponentu problemai spr¦sti numatytas, ta£iau dar nere-alizuotas, aksiomu generavimo modulis (AGM ), kurio paskirtis apra²yta 4.4.poskyryje. komponento realizacijos lygmens programu sintezes sistema autom-atizuoja ²iuos komponentiniu programu sistemu gyvavimo ciklo etapus:

• komponentu atranka ir ivertinimas,

• sistemos architekturos projektavimas,

• sistemos realizavimas,

• sistemos integravimas.

Be to disertacijoje siulomas komponentiniu programu automatizuoto kurimometodas sumaºina tikrinimo ir ivertinimo etapo poreiki, nes gauta programineiranga visi²kai atitinka specikacij¡.


5.4 pav. Komponento realizacijos lygmens programu sintezes sistema.

5.5 pav. Eksperimento su SoCoSyS sistema eiga.

5.2. Sistemos eksperimentinis tyrimas

Siekiant patikrinti komponentiniu programu sistemu generavimo metod¡ suji realizuojan£iu prototipu SoCoSyS buvo atlikti dvieju tipu eksperimentai:

• metodo principinio igyvendinamumo ir tinkamumo komponentinems pro-gramu sistemoms kurti eksperimentas,

• sistemos rezultatu patikimumo ivertinimo eksperimentas.

Atliekant pirmojo tipo eksperimentus siekta ivertinti ar i² tiesu konkretauskomponento modelio komponentus ir ju sistemas galima apra²yti abstraktausprograminio komponento modelio terminais, ar sintezes sistemos rezultataiatitinka prognozuotus rezultatus.

Sistemos eksperimentai atlikti sprendºiant komponentiniu programu gene-ravimo i² .NET komponentu uºdavinius. .NET komponento modelis pasirink-tas laisvai ir nedaro jokios itakos eksperimento rezultatams.

5.2. Sistemos eksperimentinis tyrimas 141

5.6 pav. SoCoSyS ir .NET komponentu generatoriaus langai.

Daºnai pristatant sintezes metodus nagrinejami elementarus pavyzdºiai,sprendºiantys ne itin sudetingus uºdavinius. Siekiant ivertinti disertacijojesiulomo metodo veiksmingum¡ sudetingesnems sistemoms kurti buvo atliktastoks eksperimentas (5.5 pav.):

1. Specialiu disertacijos autoriaus sukurtu irankiu (5.6 pav.) automatizuo-tu budu generuota .NET komponentu su atsitiktiniu prievadu skai£iumi,aibe. Kiekvienam komponentui generuota ir atitinkama PKM specikaci-ja (XML kalba).

2. SoCoSyS sistemai pateiktas generavimo uºdavinys sudarytas i² aksiomuaibes ir teoremos, kuri¡ reikia irodyti. Aksiomu aibe sudaryta sistemaiautomati²kai analizuojant PKM komponentu specikacijas esan£ias nau-dotojo nurodytame aplanke. Teorema irodymui parinkta taip pat au-tomatiniu budu, atsitiktinai parenkant implikacijos kairiosios ir de²inespuses narius. Pastebetina, kad sistema leidºia ir pa£iam naudotojuiformuluoti teorem¡. is procesas papildomai automatizuotas buvo tikeksperimento tikslais siekiant patikrinti kuo daugiau generavimo uºdaviniu.


Eksperimentas kartotas 50 kartu su ivairaus dydºio komponentu aibemis,apiman£iomis nuo 10 iki 200 .NET komponentu, taip pat kaitaliojant prievaduskai£iu kiekviename komponente. Pirmo tipo eksperimentai parode, kad kom-ponentines sistemos i² principo gali buti gaunamos taikant siulom¡ metod¡,ta£iau jie dar neleidºia tvirtinti, jog gaunamas rezultatas yra prasmingas.Todel siekiant ivertinti sistemos rezultatu patikimum¡ buvo atlikti antro tipoeksperimentai sistema i²bandyta su realiais .NET komponentais, kurie gebaatlikti konkre£ias uºduotis. Tokiomis eksperimento s¡lygomis lengva patikrintiar gautoji programa i² tiesu veikia taip, kaip tiketasi ir ar ji tikrai atlieka t¡uºdavini, kuriam atlikti ir buvo sukurta. I² viso ²io tipo eksperimentai buvoatlikti su dvejomis .NET komponentu aibemis:

• farmacijos sri£iai skirtu komponentu aibe (ºr. 4.5.1. poskyri),

• multimedia medºiagos apdorojimo komponentu aibe (ºr. 4.5.2. poskyri).

Abieju tipu testu rezultatai parode, kad generavimo metodas, kuri real-izuoja SoCoSyS, tinka komponentinems programu sistemoms kurti.

5.3. Palyginimas su kitomis sistemomis 143

5.3. Palyginimas su kitomis sistemomis

iame poskyriuje apºvelgiami ir su SoCoSyS sistema lyginami pana²iospaskirties moksliniu projektu rezultatai: NORA/HAMMR, QUASAR, Com-ponent WorkBeanch ir CoSMIC sistemos.

5.3.1. NORA/HAMMR sistema

NORA/HAMMR (High adaptive multi-method retrieval) programa buvokurta kaip inºinieriaus darbo irankis, siekiant inkapsuliuoti automatin¦ teoremuirodymo program¡, paslepiant jos vidin¦ specikavimo kalb¡ [44, 152]. Sintezesuºdavinys specikuojamas VDM/SL kalba.NORA/HAMMR ie²ko komponentu, tenkinan£iu silpnesn¦ prie² salyg¡ irstipresn¦ po salyg¡:

(preq ⇒ prec) ∧ (postc ⇒ postq)

NORA/HAMMR sudaro trys strukturiniai tiesinio vamzdyno architekturosmoduliai:

1. signaturos atitikties (angl. signature matchig) ltras,

2. supaprastinimo modulis (angl. simplier),

3. Kontrapavyzdºiu generatorius (angl. counter example generator). Nau-dojamas MACE modeliu generatorius, naudojamas parenkti tokiomskintamuju reik²mems su kuriomis formule tampa neteisinga. Jis baigiadarb¡ tik tuo atveju, jei uºdavinio teorija yra baigtine. Galimu kintamujureik²miu baigtumas emuliuojamas naudojant labiausiai tiketinu kintamujureik²miu aibes [47, 152].

Yra numatyta ltruojan£iu moduliu bazes pletimo galimybe. I² viso gali butitriju tipu moduliai: sintakses atitikties, atmetimo ir patvirtinimo. Pagrindinisltru uºdavinys atmesti klaidingas formules dar iki ATP panaudojimo.

Apdorot¡ ltrais uºklaus¡ toliau sprendºia ATP SETHEO [47]. Naudoja-mas standartinis D. W. Loveleand 1978 m. apra²ytas algoritmas. Teoremuirodymo programai uºdavinio sprendimui yra skiriama tik keletas sekundºiu.Siekiant grei£iau rasti rezultat¡ naudojami lygiagretieji algoritmai. Vienu metut¡ pati uºdavini keliais budais sprendºia kelios gijos tame pa£iame, arba keliu-ose kompiuteriuose (jei dirbama kompiuteriu telkinyje su SciCoTHEO ATP).Ta gija, kuri grei£iausiai graºina rezultat¡ ir yra laimejusi, visu kitu gijuvykdymas po to nutraukiamas. Kaip teigiama [152],taikant ivairius aksiomuatrankos algoritmus sekmingai i²spr¦stu uºdaviniu skai£ius varijuoja nuo 55,9%iki 69,2%.


Sistema nera specializuota komponentinems programu sistemoms kurti. Kom-ponentu atrankos komponentu saugykloje sudarytoje i² 119 komponentu uº-davinys [152] nagrinejamas tik siekiant pademonstruoti ATP panaudojimo gal-imybes [152]. Kaip pavyzdi J. Schumann [152] apra²o NORA/HAMMR pro-gram¡, kuris skirtas generuoti uºdavini ATP siekiant atlikti paie²k¡ komponentubibliotekoje sudarytoje i² 119 komponentu.

Sistemoje NORA/HAMMR naudojamas programu generavimo metodasyra pana²us i SoCoSyS, nes abi sistemos naudoja automatinio irodymo pro-gram¡. Ta£iau metodai turi ir skirtumu:

• SoCoSyS sistema yra specializuota butent komponentiniu programusistemu generavimui;

• SoCoSyS sistemoje nekeliami grieºti ribojimai uºdavinio paie²kos laikui;

5.3.2. QUASAR sistema

Vykdant projekt¡ QUASAR (QUAlity-driven Software Architecture) [23,70] pagrindinis demesys skirtas programines irangos kokybes uºtikrinimo mod-eliams. taip pat tirtos ir komponentiniu sistemu generavimo panaudojant tikju funkcinius ir nefunkcinius reikalavimus galimybes.QUASAR projekte nagrinejamos konkre£ioms produktu ²eimoms priklau-

san£ios komponentines programu sistemos [23, 70]. Pakartotinai panaudojamipilkosios deºes (angl. grey-box ) komponentai ir anks£iau kuriant kitas sistemaspriimtu sprendimu fragmentai (architekturiniai ir projektavimo ²ablonai). Ar-chitekturiniai sprendimu fragmentai naudojami komponentams modikuoti at-siºvelgiant i sprendimu-savybiu (angl. Feature-Solution FS ) graf¡.Sintezes sistem¡ sudaro:

5.7 pav. Programu architekturos generavimo sistema QUASAR.


• Architekturinio karkaso generatorius remdamasis FS grafu uºpildoUCM (angl. Use Case Maps) ruo²inius konkre£iais fragmentais (angl.snippets). Darbe [23] tvirtinama, kad naudojama aspektiniam sistemukurimui budinga metodika.

• Ivertinimo blokas (angl. scenario-based evaluator) tikrinantis ar generuo-ta programu sistemos architektura atitinka nefunkcinius reikalavimus.Tikrinama arba dalyvaujant ekspertui, arba naudojant ontologinio matavi-mo (angl. Ontology-Driven Measurement ODM ) metod¡ [70].

Lyginant SoCoSyS su QUASAR pastebimi ²ie skirtumai:

• QUASAR sistema yra specializuota darbui su komponentiniu programusistemomis priklausan£iomis konkre£ioms produktu ²eimoms, operuoja-ma tik su komponento specikacijos lygmens komponentais. Tuo tarpuSoCoSyS leidºia operuoti tiek komponento specikacijos, tiek komponen-to realiacijos lygmenyse.

• SoCoSyS sistemoje yra auk²tesnis automatizavimo lygis, nes jos planav-imo modulis, skirtingai nei QUASAR generatorius, veikia be ºmogausisiki²imo proceso metu.

• Naudojamas metodas lemia, kad SoCoSyS sistemos rezultatas yra apriori teisingas, tuo tarpu QUASAR sistemoje generatoriaus rezultatasdar tikrinamas ivertinimo bloke.

5.3.3. Component WorkBeanch sistema

J. Oberleitner ir T. Gschwind darbe [132] pristato automatizuot¡ kompo-nentu programu kurimo iranki Component WorkBeanch CWB. Pagrindineproblema, kuriai spr¦sti irankis sukurtas heterogeniniu komponentu jungi-mas. Darbe [132] nagrinejami trys komponento modeliai: DCOM, EJB irCORBA. Anot autoriu, nors teori²kai komponentines programos kurimui pakak-tu sujungti atitinkamus interfeisus, prakti²kai toks jungimas sunkiai imanomas,del skirtingu duomenu tipu ir skirtingu realizaciniu kiekvieno komponentiniomodelio detaliu. CWB aplink¡ sudaro:

1. vieningos prieigos prie komponentu lygmuo,

2. adaptavimo lygmuo,

3. scenariju lygmuo,

4. irankio lygmuo apimantis ir programos generatoriu.


Vieningos prieigos prie komponentu lygmuo (angl. uniform componentaccess layer) realizuotas per konkre£iu komponento modeliu pakiklius (angl.wrapers). Kiekvienas pakiklis atlieka keturias uºduotis [132]:

• Egzemplioriu kurimas. Tarpininkas automati²kai inicializuoja kompo-nent¡, o jei tokio komponento egzempliorius jau yra ji susieja su sistemoskreipiniu.

• Prieigos prie komponento savybiu uºtikrinimas. Komponentines pro-gramos architektui pateikia informacij¡ apie komponento savybes.

• Vaizdavimas gra²kai. Sukuria komponento vizualu atitikmeni CWBirankio Systemos kurimo lange.

• Konguravimas. Sudaro galimybes parametrizuoti komponent¡.

Komponentu aibe, kuri¡ naudoja CWB sistema, apra²yta XML kalba,kiekvienam komponentui nurodant jo modeli, dislokacijos viet¡ ir pan.

Adaptavimo lygmuo sudaro s¡lygas komponentus jungti ivairiais budais:komponavimo, agregavimo ir t.t. CWB naudojami adapteriai geba reaguoti iivykius ir jos inicijuoti. Be to, yra sudarytos galimybes, ²iu adapteriu programinikod¡ redaguoti.

Scenariju lygmenyje apra²oma komponentines programu sistemos architek-tura ir tokios komponentu savybes, kurios negali buti i²saugotos juose pa£iuose,pavyzdºiui: pakeistas komponento pavadinimas ar sutartinis granis vaizdas.

CWB irankyje numatyta galimybe vien¡ programos generatoriu pakeistikitu. Praktiniai bandymai atlikti naudojant Java ir XML kalbas. Pastaruo-ju atveju XML faile apra²yta komponentines programos architektura, kuri¡realizuoti reiketu jau su kitu irankiu [132].

Lyginant SoCoSyS ir Component WorkBeanch sistemas pastebimi ²ie skir-tumai:

• CWB sistema leidºia kurti heterogenines komponentines sistemas, ta£i-au panaudojant tik tu modeliu komponentus, kurie buvo numatyti j¡kuriant, t.y. DCOM, EJB ir CCM. Tuo tarpu SoCoSyS sistem¡, delnaudojamo abstraktaus PKM modelio, galima taikyti platesniam kom-ponento modeliu ratui, bet negalima kurti heterogeniniu sistemu.

• Skiriasi generavimo metodu taikymo tikslas ir taikymo metas. Automa-tiniu budu CWB sistemoje generuojami tik pakikliai, o pa£i¡ komponenti-niu programu sistem¡ sukuria CWB naudojantis asmuo. Tuo tarpu So-

CoSyS sistemoje generavimo metodas taikomas butent galutinio rezul-tato gavimui.

• SoCoSyS sistemos rezultatas yra visi²kai atitinkantis specikacij¡, tuotarpu CWB sistema to negali garantuoti.


5.3.4. CoSMIC sistema

CoSMIC (angl. Component Synthesis using Model Integrated Computing)sistema skirta automatizuotu budu atrinkti, sujungti ir paskirstyti i²skirstyto-sios relaus laiko iterptines sistemos komponentus [150].Uºdaviniai, kuriuos atlieka CoSMIC sistema, yra ²ie:

• programu sistemos teikiamu paslaugu konguravimas ir paskirstymas,

• komponentu komponavimas i sudetinius programu serveriui skirtus kom-ponentus ir ju realizaciju generavimas,

• komponentu konteineriu konguravimas,

• paslaugu kokybes uºtikrinimo priemoniu generavimas,

• tarpines programines irangos konguraciju generavimas,

• tarpines programines irangos ir jos iskiepiu generavimas.

CoSMIC sistemoje realizuotos 4 pagrindines dalys (5.8 pav.): modelio interpre-tatorius, kodo generatorius, paskirstymo (diegimo) irankis ir programu serveris(angl. application server). Lyginant SoCoSyS ir CoSMIC sistemas matytiypa£ dideli skirtumai:

• Skirtingai nei SoCoSyS, CoSMIC sistema yra specializuota, skirta kurtiiterptinems sistemoms.

• CoSMIC sistema operuoja visuose komponento abstrakcijos lygmenyseiskaitant ir komponentinio objekto lygmeni. CoSMIC yra integruotasu programu serveriu aptarnaujan£iu komponentinius objektus veikimometu. SoCoSyS sistemoje operuojama tik komponento specikacijos irkomponento realizacijos lygmenyse.

5.8 pav. Komponentiniu programu sistemu generavimo sistema CoSMIC.


• CoSMIC sistema yra jautresne komponentiniu programu sistemos raidai,nes yra tampriai susieta su vienu (CMM pagrindu sukurtu CIAO) kompo-nento modeliui. SoCoSyS sistema sukurta abstrahuojantis nuo konkre-taus komponento modelio savybiu, todel yra lengviau adaptuojama.


1. Komponentiniu programu sistemu generavimo metodo eksperimentinerealizacija SoCoSyS sistemoje parode, kad metodas tinka tokioms progra-mu sistemoms kurti.

2. SoCoSyS sistem¡ palyginus su kitomis sistemomis nustatyta:

2.1. Skirtingai nei NORA/HAMMR, SoCoSyS sistema yra specializuo-ta butent komponentiniu programu sistemu generavimui;

2.2. Generavimo sistemos sukurtos siekiant skirtingu tikslu, todel gener-avimo metodai, kuriuos jos realizuoja taip pat skiriasi. I² analizuotusistemu, tik SoCoSyS sistema realizuoja metod¡, turinti keliumetodu elementu.

2.3. SoCoSyS sistemoje komponentiniu programu kurimo proceso au-tomatizavimo lygis yra auk²tesnis, nei QUASAR ir CWB siste-mose;

149

5.1lenteleKom

ponentiniu

programugeneravimosistem

os

NORA/

HAMMR

QUASA

RCWB

CoSMIC

SoCoSyS

Naudo

jamas

komponen-

tomodelis

pilkosios

deºes

abstrakcijos

CCM,

EJB

,DCOM

CCM

(CIAO)

PKM

komponento

abstrakcijos

lygm

uo(-enys)

komponento

specikacijos

(KS)

komponentore-

alizacijos(K

R),

idiegto

kom-

ponento

(IK),

komponentinio

objekto(K

O)

KS,

IK,KO

KSirKR

Generavim

ometodas

dedu

ktyvioji

sinteze

transformacine

sinteze

transformacine

sinteze

transformacine

sinteze

dedu

ktyvioji

sinteze

pagal

Curry

Howard

protokol¡,

transformacine

sinteze

Sintezes

tikslas

atrinkti

tinka-

mus

komponen-

tus.

susieti

konkre£ius

reikalavimus

suproduktu

²eim

osar-

chitekturiniais

²ablonais.

sukurti

pakik-

lius

sudarant

s¡lygas

projek-

tuoti

irkurti

heterogeniniu

komponentu

sistem

as.

sukurti

i²skirstyt¡sias

realaus

laiko

iterptines

sis-

temas.

sukurti

pasirinkto

lygm

ens

kom-

ponentin¦

sistem

¡.

I²vados

1. Komponento modeliu ivairove yra veiksnys, apsunkinantis automatizuot¡komponentiniu programu sistemu kurimo proces¡:

1.1. Apºvelgus komponento modelius, reprezentuojan£ius ºinomas mo-deliu klases, nustatyta, kad jiems apra²yti i² viso naudojamos 28 s¡-vokos. Kiekvienas modelis apra²omas naudojant nuo 3 iki 12 s¡voku.

1.2. Komponentines programos gaunamos naudojant skirtingas kom-ponavimo formas. Kurios butent formos yra naudojamos, priklausonuo komponento modelio ir jo abstrakcijos lygmens.

1.3. Skiriami keturi komponento abstrakcijos lygmenys. Disertacijo-je nagrinejami specikacijos ir realizacijos lygmenu komponentai.Idiegto komponento ir komponentinio objekto lygmenys ²ioje dis-ertacijoje nenagrinejami, nes idiegto komponento ir komponentinioobjekto lygmenys glaudºiai susij¦ su sistemos veikimo etapu ir kuri-mo procesui yra maºiau aktualus.

2. I²analizavus programiniu komponentu savybes ir komponentiniu programukurimo proceso ypatumus nustatyta:

2.1. Pagrindiniai komponentu kurimo proceso ypatumai yra ²ie: kom-ponentai kuriami tam, kad butu panaudoti daugiau nei vien¡ kart¡;jie kuriami neºinant, kokie reikalavimai jiems bus keliami konkre-£iose sistemose; komponentu specikacija ir dokumentacija tuributi tiksli ir i²sami.

2.2. Komponentiniu programu sistemu kurimo procesas, kuriame akcen-tuojamas ne suprojektuotos sistemos ir jos daliu realizavimas, betjau sukurtu komponentu pakartotinis panaudojimas turi trukumu:nei²spr¦stas detalios komponentu paie²kos uºdavinys; komponentuadaptavimui reikalingos papildomos s¡naudos.

151

3. Konkre£ioms komponentiniu programu sistemu surinkimo proceso au-tomatizavimo problemoms spr¦sti gali buti naudojami strukturines sin-tezes, induktyviosios sintezes ir transformacines sintezes metodai:

3.1. Deduktyvieji metodai palaiko juodosios deºes abstrakcijas, beto, taikant deduktyvuji strukturines sintezes metod¡ uºtikrinamarezultatu (taikomuju programu) atitiktis specikacijai.

3.2. Induktyvusis metodas gali padeti spr¦sti ²ias deduktyviuoju meto-du nei²sprendºiamas problemas: specikacijos nei²samumo prob-lem¡, neapibreºtuju komponentu problem¡ ir nefunkciniu reikalavi-mu problem¡.

3.3. Transformacine sinteze igalina maºinti atotruki tarp dalykines sri-ties, kuriai kuriama programine iranga, ir realizacines srities (kon-kre£iu komponento modeliu, karkasu, operaciniu sistemu ir t. t.)konceptu.

4. Programu sintezes uºdavinys ir jo sprendimo budas gali buti taip su-formuluotas apibendrinto programinio komponento modelio terminais,kad gautas sprendinys gali buti pritaikomas kiekvienam i² apibendrintukomponentu modeliu panaudojant konkretizavimo, patikslinimo ir pa-pildymo operacijas.

5. Programu sintezes metodas, komponentineje paradigmoje realizuojantisCurry-Howard protokol¡, igalina automatizuotu budu kurti komponen-tines programas ir uºtikrina ²iu programu atitikti specikacijai.

6. Komponentiniu programu sistemu generavimo metodo eksperimentinerealizacija SoCoSyS sistemoje parode, kad metodas tinka tokioms pro-gramu sistemoms kurti.

Literatura

[1] Abmann, U. (2003). Invasive Software Composition. Springer.

[2] Addibpour, M., Tyugu, E. (1996). Structural Synthesis of Programs fromRened User Requirements. Formal methods for industrial applications.(Abrial, J-R et al. eds.) LNCS 1165, Springer Verlag, p. 1334.

[3] Addibpour, M. (1995). Control Structures for Parallel Computing in NUT.Technical Report TRITAIT R 95:18, Stockholm: Royal Institute of Tech-nology (KTH).

[4] Aguirre, N., Maibaum, T. (2007). Temporal Specications of ComponentBased Systems with Polimorphic Dynamic Reconguration. MathematicalFrameworks for Component Software: Models for Analysis and Synthesis.(Liu, Zh., Jifeng, H. eds.) World Scientic Publishing Company.

[5] Alti, A. et al. (2007). Integrating Software Architecture Concepts Into theMDA Platform with UML Prole. Journal Of Computer Science, vol. 3(10),p. 793802.

[6] Amphion projektas. [interaktyvus]. [ºiureta 2003 m. lapkri£io 9 d.]. Prieigaper internet¡: http://ti.arc.nasa.gov/ic/projects/amphion/

[7] Apperly, H. (2005). The Component Industry Metaphor. Component BasedSoftware Engineering: Putting the Pieces Together. (Heineman, G. T.,Councill, W. T. eds.) Addison-Wesley Professional. p. 2132.

[8] The Archive of Formal Proofs. [interaktyvus]. [ºiureta 2009 m. lapkri£io 5d.]. Prieiga per internet¡: http://afp.sourceforge.net/

[9] Aspinall, D. (2000). Proof General: A Generic Tool for Proof Development.Tools and Algorithms for the Construction and Analysis of Systems, ProcTACAS, LNCS 1785, p. 3843.

[10] Bachmann, F. et al. (2000). Volume II: Technical Concepts ofComponent-Based Software Engineering, 2nd Edition. Technical

Literatura 153

Report CMU/SEI-2000-TR-008. Software Engineering Institute. [in-teraktyvus]. [ºiureta 2010 m. sausio 14 d.]. Prieiga per internet¡:http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html

[11] Backhouse, R. (2003). Program construction: calculating implementatinsfrom specications. Wiley.

[12] Barber, G. (2007) The Business Value Proposition of SCA. [in-teraktyvus]. [ºiureta 2010 m. kovo 1 d.]. Prieiga per internet¡:http://www.osoa.org/display/Main/The+Business+Value+Proposition+of+SCA

[13] Barnett, M., Schulte, W. (2002). Contracts, components ir their runtimevericationon the .NET platform. Tech. Report. Microsft Research.

[14] Barzdin', Y. M., Brazma, A. N., Kinber, E. B. (1987). Inductive synthesisof programs: State of the art, problems, prospects, Cybernetics and SystemsAnalysis, 23(6), p. 818-826. [interaktyvus]. [ºiureta 2005 m. birºelio 10 d.].Prieiga per internet¡: http://dx.doi.org/10.1007/BF01070244.

[15] Bass, L. et al. (2001). Market Assessment of Component-Based SoftwareEngineering. [interaktyvus]. [ºiureta 2009 m. gruodºio 20 d.]. Prieiga per in-ternet¡: http://www.sei.cmu.edu/library/abstracts/reports/01tn007.cfm

[16] Basili, V. R., Boehm, B. (2001). COST-Based Systems Top 10 List. IEEEComputer vol. 34(6), p. 91-95.

[17] Bazler, R. (1985). A 15 Year Perspective on Automatic Programming.IEEE Transactions On Software Engineering vol. SE-11 No. 11 , p. 1257-1268.

[18] Beisiegel, M. et. al. (2007). SCA Service Component Architecture: As-sembly Model Specication. [interaktyvus]. [ºiureta 2010 m. sausio 10 d.].Prieiga per internet¡: http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf?version=1

[19] Berger, K. et al. (2000). A Formal Model for Componentware. Foundationsof Component-Based Systems. Cambridge University Press.

[20] Bertot, Y. et al. (2004) Interactive Theorem Proving and Program Devel-opment. Springer.

[21] Binkley, D. at al. (2005). Automated Refactoring of Object Oriented Codeinto Aspects. In Proceedings of 21st IEEE International Conference onSoftware Maintenance ICSM'05, p. 2736.

154 Literatura

[22] Boyer, R. S., Moore, J. S. (1990). A theorem prover for a computation-al logic. Proceedings of the Tenth international Conference on AutomatedDeduction Springer-Verlag, New York, p. 1-15.

[23] Bruin, H., Vliet H. (2002). The Future of Component-Based Developmentis Generation, not Retrieval. Proceedings ECBS'02 Workshop on CBSE Composing Systems from Components (Crnkovic, I., Larsson, S., Staord,J. eds.), Lund. [interaktyvus]. [ºiureta 2004 m. liepos 8 d.]. Prieiga perinternet¡: http://www.cs.vu.nl/∼hans/publications/y2002/gc.pdf

[24] Bruneton, E. et al. (2006). The Fractal Component Model and Its Supportin Java. Software Practice and Experience, special issue on Experiences withAuto-adaptive and Recongurable Systems. 36(11-12), p. 1257-1284.

[25] Boyle J.M., Harmer T.J., Winter V.W. (1996). The TAMPR ProgramTransformation System Proceedings of the Durham Transformation Work-shop.

[26] Bundy, A. et al. (2005). Rippling: Meta-Level Guidance for MathematicalReasoning. Cambridge University Press.

[27] Cai, J., Paige, R. (1990). The RAPTS Transformation System. NewYork:New York University.

[28] Cervantes, H., Hall, R.S. (2004). A Framework for Constructing AdaptiveComponent-based Applications: Concepts and Experiences. In 7th Sympo-sium on Component-Based Software Engineering - CBSE, LNCS vol. 3054,Edinburgh:Springer, p. 130-137.

[29] Chan, K., Poernomo, I. (2007). QoS-aware model driven architecturethrough the UML and CIM. Frontiers of Information Systems. vol.9, p.209-224.

[30] Charpentier, M. (2002). An Approach to Composition Motivated by wp.In 5th International Conference on Fundamental Approaches to SoftwareEngineering (FASE2002), LNCS 2306, Springer-Verlag, p. 114.

[31] Charpentier, M. (2006). Composing Invariants. Science of Computer Pro-gramming., 60, p. 221243.

[32] Charpentier, M., Chandy, K. M. (2000). Theorems about composi-tion. International Conference on Mathematics of Program Construction(MPC2000), LNCS 1837, Springer-Verlag, p. 167186.

[33] Charpentier, M., Chandy, K. M. (2004). Specication transformers: apredicate transformer approach to composition. Acta Informatica. vol.40(4), p. 265301

Literatura 155

[34] Cheesman, J., Daniels, J. (2001). UML Components. Addison-Wesley.

[35] Chen, X. et. al. (2006). A Model of Component-Based Programming.Technical Report 350, Macau:UNU/IIST.

[36] Chen, Z. et. al. (2007). Renement and Verication in Component-BasedModel Driven Design. Technical Report 388, Macau:UNU/IIST.

[37] Christiansson, B., Jakobsson, L., Crnkovic, I. (2003) CBD Process. Build-ing Realiable Component-Based Software Systems. (Crnkovic, I., Larsson,M. eds.) p. 89113.

[38] Chung, L., Nixon, B. A., Yu, E., Mylopoulos, J. (2000). Non-FunctionalRequirements in Software Engineering. Kluwer Academic Publishers.

[39] Cleaveland, J. C. (2001). Program Generators with Java and XML. Pren-tice Hall PTR.

[40] Communicating Sequential Processes. The First 25 Years. (2005) Abdal-lah, Ali E.; Jones, Cli B.; Sanders, Je W. (Eds.) Springer.

[41] Cox, P. T., Song, B. (2001). A formal model for component-based soft-ware. Proc. of the IEEE Symposium on Visual/Multimedia Approaches toProgramming ir Software Engineering, Stresa, Italy, p. 304311.

[42] Crnkovic, I. et. al. (2005). Automated Component-Based Software Engi-neering. The Journal of Systems and Software 74, p. 13.

[43] Czarnecki, K. (2000). Generative programming - Methods, Tools, and Ap-plications. Addison-Wesley.

[44] Denney, E., Fischer, B. (2005). Selected References for SBMF Mini-courseon Automated Code Generation. Porto Alegre, Rio Grande do Sul, Brasil.

[45] Deville, Y., Lau K.-K. (1993). Logic program synthesis. The Journal oflogic programming, vol. 12, p. 1199.

[46] D'Souza, D. F., Wills, A. C. (1999). Objects, Components and Frame-works with UML: The Catalysis Approach. Addison Wesley Longman.[interaktyvus]. [ºiureta 2007 m. balandºio 27 d.]. Prieiga per internet¡:http://www.catalysis.org/books/ocf/index.htm

[47] Fischer, B. (2001). Deduction-Based Software Component Retrieval. PhD-thesis, Universität Passau.

[48] Dijkstra, E. W. (1976). Discipline of Programming. Prentice Hall.

156 Literatura

[49] Dijkstra, E. W., Scholten, C. S. (1990). Predicate calculus and programsemantics. Springer-Verlag.

[50] Endres, A., Rombach, D. (2003). A Handbook of Software and SystemsEngineering: Empirical Observations, Laws and Theories. Addison Wesley.

[51] Fagorzi, S., Zucca, E. (2007). A Calculus of Components with DynamicType-Checking. Proceedings of FACS 2006 (3rd International Workshop onFormal Aspects of Component Software). Electronic Notes in TheoreticalComputer Science. Vol. 182, p. 7390.

[52] Fabresse, L. et al. (2008). Foundations of a simple and unied component-oriented language. Computer Languages, Systems & Structures, vol. 34, Iss.2-3, p. 130149.

[53] Feather, M. S. (1987). A Survey and Classication of some Program Trans-formation Approaches and Techniques. Program Specication and Trans-formation. Elsevier.

[54] Ferilli, S., Esposito, F., Basile, T.M.A., Di Mauro, N. (2004). In AutomaticInduction of First-Order Logic Descriptors Type Domains from Observa-tions. LNCS 3194, Springer, p. 116131.

[55] Flener, P. (2002). Achievements and prospects of program Synthesis. Com-putational Logic: Logic Programming and Beyond: Essays in Honour ofRobert A. Kowalski, LNAI 2407., Springer-Verlag, p. 310346.

[56] Fractal Component Model Specications. [interaktyvus]. [ºiureta 2009 m.lapkri£io 9 d.]. Prieiga per internet¡: http://fractal.objectweb.org/

[57] Gallier, J. H. (2003). Foundations of Automatic Theorem Proving. Wiley.

[58] Gao, J. Z., Tsao H.-S. J., Wu, Y. (2003). Testing and Quality Assurancefor Component-based Software. Artech House.

[59] Generative Modeling Technologies (GMT) project. [interaktyvus]. [ºiureta2008 m. vasario 3 d.]. Prieiga per internet¡: http://www.eclipse.org/gmt/

[60] Generative Tools. [interaktyvus]. [ºiureta 2008 m. spalio3 d.]. Prieiga per internet¡: http://www.program-transformation.org/Transform/GenerativeTools

[61] Genssler, T. et al. (2002). PECOS in a Nutshell. [interaktyvus].[ºiureta 2003 m. vasario 19 d.]. Prieiga per internet¡: http://www.pecos-project.org/public_documents/pecosHandbook.pdf

Literatura 157

[62] Giedrimas, V. (2003). komponento modelis strukturines programu sintezeskontekste. Informacijos mokslai 26: p. 246250.

[63] Giedrimas, V., Lupeikiene, A. (2004). komponento specikacijos formal-izavimas. Lietuvos Matematikos Rinkinys. Spec. Nr. 44 p. 276280.

[64] Giedrimas, V., Lupeikiene, A. (2005). komponentiniu programustrukturines sintezes teorines problemos. Lietuvos Matematikos Rinkinys.Spec. Nr. 45, p. 139143.

[65] Giedrimas, V. (2006). Architectures of Component-based Structural Syn-thesis Systems. Proceedings of Baltic DBIS06, p. 311315.

[66] Giedrimas, V. (2007). Generavimo metodu panaudojimas kuriant .NETkomponentines programu sistemas. Informacijos mokslai, T. 4243, p. 246250.

[67] Gobel, S. (2005). An Mda Approach For Adaptable Components. In Mod-el Driven Architecture - Foundations And Applications: First EuropeanConference, Ecmda-Fa 2005 Proceedings, p. 7487.

[68] Gordon, M. (2008). Twenty Years of Theorem Proving for HOLs Past,Present and Future. Theorem Proving in Higher Order Logics. Proceedingsof 21st International Conference. Springer, p. 15.

[69] Grigorenko, P., Saabas, A., Tyugu, E. (2005). Visual Tool for GenerativeProgramming. Proc. of the ACM SIGSOFT Symposium on the Foundationsof Software Engineering, ACM Press.

[70] Goulao, M.C.P.A. (2008). Component-Based Software Engineering: aQuantitative Approach. PhD thesis. Universidade Nova de Lisboa.

[71] Guessoum, A., Komorowski. J. (1995). Induction, Deduction and Abduc-tion for Program Design and Maintenance.

[72] Gupta, N. S. (2004). An Exploratory Analysis of the .NET ComponentModel and UniFrame paradigm using a collaborative approach. M. S. Thesis,Indiana University Purdue University.

[73] Gupta, N. S. et al. (2003). Analyzing the Web Services and UniFrameParadigms. The Proceedings of SESEC 2003, the Southeastern SoftwareEngineering Conference, Huntsville.

[74] Girard, J.Y. (1989). Proofs and types. Cambridge University Press.

[75] Harf, M. et al. (2001). Automated Program Synthesis for Java Program-ming Language. Ershov Memorial Conference. p. 157164.

158 Literatura

[76] Harrop, R. (1960). Concerning Formulas of the Types A → B ∨ C, A →(Ex)B(x) in Intuitionistic Formal Systems. Journal of Symbolic Logic 25,no. 1, p. 2732.

[77] He, J., Li, X., Liu, Z. (2006). rCOS: A Renement Calculus of Objectsystems. Theretical Computer Science 365 p. 109142.

[78] He, J., Liu, Z., Li, X. (2003). Component Calculus. Technical Report 285,Macau:UNU/IIST.

[79] He, J., Li, X., Liu, Z. (2005). Component-Based Software Engineering the Need to Link Methods and their Theories. Technical Report 330,Macau:UNU/IIST.

[80] Hehner, E. (2006). Retrospective and prospetive for Unifying Theoriesof programming. Unifying Theories of Programming, First InternationalSymposium, UTP 2006, Revised Selected Papers. LNCS 4010, Springer, p.117.

[81] Herrington, J. (2003). Code Generation in Action. Manning.

[82] Ho, S-M., Lau K-K. (2007). Characterizing object-based frameworks inFirst-order predicate logic. Mathematical Frameworks for Component Soft-ware: Models for Analysis and Synthesis. (Liu, Zh., Jifeng, H. eds.) WorldScientic Publishing Company

[83] Hoare, C.A.R, He, J. (1998). Unifying Theories of Programming. PrenticeHall Series in Computer Science. Prentice Hall.

[84] Howard, W.A. (1980) The formulae-as-types notion of constructions. ToH.B.Curry: Essays on Combinatory Logic, Lambda Calculus and Formal-ism. Academic press, p. 479490.

[85] Huet, G., Hullot, J. M. (1980). Proofs by Induction in Equational Theorieswith Constructors. Foundations of Computer Science, p. 96107.

[86] Huet, G. P. (1986). Theorem Proving Systems of the Formel Project.Proceedings of the 8th international Conference on Automated Deduction.LNCS 230, Springer-Verlag, p. 687688.

[87] ISO/IEC TR 9126-3:2003 Software Engineering Product Quality Part3: Internal metrics. (2003)

[88] ISO/IEC 25051:2006 Software Engineering Software product QualityRequirements and Evaluation (SQuaRE) Requirements for quality ofCommercial O-The-Shelf (COTS) software product and instructions fortesting. (2006)

Literatura 159

[89] Institute of Cybernetics. The NUT language. [interaktyvus]. [ºiureta 2002m. spalio 10 d.]. Prieiga per internet¡: http://cs.ioc.ee/∼nut/

[90] Jablonskij, S. V. (1986). Vviedienijie v diskretnuju matematiku. Mosk-va:Mir (rusu k.)

[91] Kabir, M. H. (2007). Automatic inductive theorem proving and programconstruction methods using program transformation. PhD. thesis, DublinCity University.

[92] Kaisler, S. H. (2005). Software paradigms. Wiley-interscience.

[93] Kant, E., Barstow, D. (1981). The renement paradigm: the interaction ofcoding and eciency knowledge in program synthesis. IEEE Transactionson Software Engineering, vol. 7, no. 5 p. 458-471.

[94] Kleppe, A. (2003). Mda Explained: The Model Driven Architecture: Prac-tice And Promise. Boston: Addison-Wesley.

[95] Kum, D. K., Kim, S. D. (2006). A Systematic Method To Generate .NetComponents From Mda/Psm For Pervasive Service., Fourth InternationalConference On Software Engineering Research, Management And Applica-tions. p. 324331.

[96] Küster, J., Bowles, F. ir Moschoyiannis, S. (2007). Concurrent Logic andAutomata Combined: a Semantics for Components. In Proc. of CONCUR2006 - Foundations of Coordination Languages and Software Architectures(FOCLASA'06 ), ENTCS, 175(2): 135151, Elsevier.

[97] Lau, K.-K., Momigliano, A., Ornaghi, M. (2005). Constructive Specica-tion of Compositional Units. Proceedings of the Fourteenth InternationalWorkshop on Logic-based Program Synthesis and Transformation. LNCS3573, Springer-Verlag, p. 198214.

[98] Lau, K.-K. (2003). Component-based Software Development and LogicProgramming. Proceedings of the Nineteenth International Conference onLogic Programming. LNCS 2926, Springer-Verlag, p. 103108.

[99] Lau, K.-K., Ornaghi, M. (2001) A Formal Approach to Soft-ware Component Specication. Proceedings of Specication and Ver-ication of Component-based Systems Workshop at OOPSLA2001.[interaktyvus]. [ºiureta 2006 m. kovo 9 d.]. Prieiga per internet¡:http://citeseer.ist.psu.edu/592159.html

[100] Lau, K.-K., Wang, Z. (2005). A Taxonomy of Software Component Mod-els. Proceedings of the 31st EUROMICRO Conference on Software Engi-neering and Advanced Applications p. 8895.

160 Literatura

[101] Lau, K.-K., Wang, Z. (2007). Software Component Models. IEEE Trans-actions on Software Engineering, vol. 33 - 10, p. 709724

[102] Lammermann, S. (2002). Runtime Service composition via logic-basedprogram synthesis. PhD. thesis, KTH, Stockholm. TRITA-IT AVH 02:03ISSN 1403-5286

[103] Lammermann, S., Tyugu., E. (2002) Implementing Extended StructuralSynthesis of Programs. In Proc. AAAI 2002 Spring Symposium Series onLogic-Based Program Synthesis: State of the Art and Future Trends. AAAIPress, p. 6371.

[104] Leavens, G.T., Dhara, K.K. (2000). Concepts of Behavioral Subtyping& Foundations of Component-Based Systems. Cambridge University Press

[105] van Lint, J.H., Wilson, R.M. (2002). A Course in Combinatorics. Cam-bridge University Press.

[106] López-Sanz, M. et al. (2008). Modelling Of Service-Oriented Architec-tures With Uml. ENTCS 194(4), p. 2337.

[107] Luders, F., Lau, K.-K.,Ho S.-M. (2003). Specication of software com-ponents. CBD Process.Building Realiable Component-Based Software Sys-tems. Eds. Crnkovic.,I., Larsson., M. p. 2338.

[108] Lupeikiene, A., Giedrimas, V. (2005) Component model and its formali-sation for structural synthesis. Scientic Proc. of Riga Technical University.Computer Science, vol. 22, p. 169180.

[109] Lupeikiene, A. (2006) Integrated Enterprise Information System Devel-opment through Component Abstraction. Proceedings of the Seventh Inter-national Baltic Conference on Databases and Information Systems, (Vasile-cas, O., Eder, J., aplinskas, A. eds.), Institute of Electrical and ElectronicsEngineers, p. 168174.

[110] Lupeikiene, A. (2007) Teoriniai ir technologiniai informaciniu sistemuaspektai. Vilnius.

[111] Manna, Z., Walldinger, R. (1980). A Deductive Aproach to ProgramSynthesis. Transactions of programming Languages and Systems vol. 2, p.90121.

[112] Martelli, M., Mascardi, V., Zini F. (1999). A Logic Programming Frame-work for Component-Based Software Prototyping. Proceeding of 2nd Inter-national Workshop on Component-based Software Development in Compu-tational Logic (COCL' 99).

Literatura 161

[113] Matskin, M., Tyugu, E. (1997). Strategies of Structural Synthesis ofPrograms. Automated Software Engineering Conference. p. 305306.

[114] Matskin, M., Rao, J. (2002). Value-Added Web Services CompositionUsing Automatic Program Synthesis. CAiSE '02/ WES '02: Revised Papersfrom the International Workshop on Web Services. Springer-Verlag, p. 213224.

[115] McIlroy, M. D. (1968). Mass produced software components. Proc. NatoSoftware Eng. Conf.. Garmisch, p. 138-155.

[116] Medvidovic, N., Taylor, R. N. (2000). A Classication and Compari-sion Framework for Software Architecture Description Languages. In IEEETransactions on Software Engineering. vol. 26, p. 7093.

[117] Mellor, S.J., Balcer M. J. (2002). Executable UML: A Foundation forModel-Driven Architecture. Addison-Wesley.

[118] Mellor, J. et al. (2004). MDA Distilled: Principles of Model-driven Ar-chitecture. Addison-Wesley.

[119] Meng S., Aicherning B.K. (2002). Component-Based Coalgebraic Speci-cation and Verication in RSL. Technical Report 267, Macau:UNU/IIST.

[120] Meng S., Aicherning B.K. (2003). A Coalgebraic Calculus for ComponentBased Systems. Proceedings of the Workshop on Formal Aspects of Com-ponent Software FACS'03, H. H.D. Van , Z. Liu, eds., Pisa, Italy, pages2746.

[121] Meyer, B. (2003). The Grand Challenge of Trusted Components. In ICSE25 (International Conference on Software Engineering, Portland, Oregon,May, IEEE Computer Press.

[122] Microsoft. (1996). The component object model specication. Reportv0.99, Microsoft Standarts, Redmond WA:Microsoft Press.

[123] Moschoyiannis, S., Shields. M. W.(2003). Component-based design: to-wards guided composition. Proceedings of Application of Concurrency toSystem Design (ACSD'03), Guimaraes:IEEE Computer Society, p. 122131.

[124] Muggleton, S., Feng C. (1990). Ecient Induction Of Logic Programs.Proceedings of the 1st Conference on Algorithmic Learning Theory p. 368381.

[125] Muggleton, S.,De Raedt, L. (1994). Inductive logic programming : The-ory and methods. Journal of Logic Programming, vol. 19-20, p. 629-679.

162 Literatura

[126] Muller, P., Poetzsch-Heer, A. (2000). Modular specication and Veri-cation Techniques for Object-oriented software composition. Foundationsof Component-Based Systems. Cambridge University Press.

[127] Newborn, M. (2001). Automated Theorem Proving: Theory and Practice.Springer.

[128] Nierstrasz, O. (1995). Object-oriented Software Composition. PrenticeHall. Prieiga per internet¡: [interaktyvus]. [ºiureta 2008 m. kovo 9 d.].http://www.iam.unibe.ch/∼scg/Archive/nie95/PDF/Nier95bnie95book.pdf

[129] Nierstrasz, O. et al. (2002). A Component Model for Field Devices. Pro-ceedings First International IFIP/ACM Working Conference on Compo-nent Deployment, ACM, Berlin.

[130] Nipkow, T., Paulson, L. C., Wenzel, M. (2002). Isabelle/HOL - A ProofAssistant for Higher-order Logic. Springer.

[131] Norgela, S. (2007). Logika ir dirbtinis intelektas. V.:TEV.

[132] Oberleitner, J., Gschwind, T. (2003). Composing distributed componentswith the Component Workbench. SEM : Software engineering and middle-ware, LNCS 2596. Springer, p. 102114.

[133] Ohori, A. (1999). A Curry-Howard Isomorphism for Compilation andProgram Execution. LNCS 1581, Springer.

[134] OMG (1998). CORBA components. Report ORBOS/99-02-01, ObjectManagement Group [interaktyvus]. [ºiureta 2009 m. gruodºio 1 d.]. Prieigaper internet¡: http://www.omg.org

[135] OpenCCM - The Open CORBA Component Model Platform. [in-teraktyvus]. [ºiureta 2009 m. gruodºio 1 d.]. Prieiga per internet¡:http://openccm.objectweb.org/

[136] OMG. Unied modelling language Specication (Action Semantics). Ver-sion 2.0 [interaktyvus]. [ºiureta 2009 m. balandºio 10 d.]. Prieiga per inter-net¡: http://www.omg.org/cgi-bin/doc.cgi?ptc/02-01-09.pdf, [ºiureta 2009m. geguºes 2 d.].

[137] OMG. Meta Object Facility (MOF) Core Specication. Version 2.0[interaktyvus]. [ºiureta 2009 m. balandºio 10 d.]. Prieiga per internet¡:http://www.omg.org/spec/MOF/2.0

[138] Pastor, O., Molina, J. C. (2007). Model-Driven Architecture in Practice.Springer.

Literatura 163

[139] Paulson, L. C. (2005). The Isabelle/Isar Reference Manual. [inter-aktyvus]. [ºiureta 2008 m. rugpju£io 15 d.]. Prieiga per internet¡:http://isabelle.in.tum.de/dist/Isabelle/doc/isar-ref.pdf

[140] Penjam, J. , Tyugu, E. (1993). Constraint Semantics of NUT. TechnicalReport TRITA-IT-9309 IOC-CS-58/93, CSLab, Dept. of Teleinformatics,Stockholm:Royal Institute of Technology (KTH).

[141] Poernomo, I. H., Reussner, R., Schmidt, H. W. (2002). Architecturesof Enterprise Systems: Modelling Transactional Contexts. Component De-ployement LNSC 2370, p. 233243

[142] Poernomo, I. H., Crossley, J. N., Wirsing, M. (2005). Adapting Proofs-as-Programs: The CurryHoward Protocol. Springer.

[143] Program Generator Projects and Activities. [interaktyvus].[ºiureta 2009 m. balandºio 10 d.]. Prieiga per internet¡:http://www.craigc.com/pg/projects.html

[144] Raje, R. (2000). UMM: Unied Meta-Object Model For Open Distribut-ed Systems. Proceedings of 4th IEEE International Conference on Algo-rithms and Architecture for Parallel Processing, ICA3PP'2000, Hongkong,p. 454465

[145] Rao, J. (2004). Semantic Web Service Composition via Logic-based Pro-gram Synthesis. PhD Thesis. Department of Computer and InformationScience, Norwegian University of Science and Technology.

[146] Reussner, R.H., Schmidt, H.W., Poernomo, I.H. (2003). Reliability pre-diction for component-based software architectures. Journal if Systems andSoftware vol. 66, 3 p. 241252.

[147] Sametinger, J. (1997). Software Engineering with Reusable Components.Springer-Verlag.

[148] Salzmann, C. (2002). Invariants of Component Reconguration. Pro-ceedings of Seventh International Workshop on Component-Oriented Pro-gramming. [interaktyvus]. [ºiureta 2008 m. spalio 20 d.]. Prieiga perinternet¡: http://research.microsoft.com/∼cszypers/events/WCOP2002/12_Salzmann.pdf

[149] Schneider, J.G. (1999). Components, Scripts, ir Glue: A con-ceptual framework for software composition PhD thesis. [inter-aktyvus]. [ºiureta 2003 m. spalio 15 d.]. Prieiga per internet¡:http://www.iam.unibe.ch/∼scg/Archive/PhD/schneider-phd.pdf

164 Literatura

[150] Schmidt, D.C. et al. (2002). CoSMIC: an MDA Generative tool for Dis-tributed real-time and Embedded Component Middleware and Applica-tions. Proceedings of the OOPSLA 2002 Workshop on Generative Tech-niques in the Context of Model Driven Architecture, ACM.

[151] Schmidt, D.C. (2009). Real-time CCM with CIAO (Component Integrat-ed ACE ORB). [interaktyvus]. [ºiureta 2009 m. lapkri£io 3 d.]. Prieiga perinternet¡: http://www.cs.wustl.edu/∼schmidt/CIAO.html

[152] Schumann, J.M. (2001). Automated Theorem Proving in Software Engi-neering. Springer

[153] Smith, D. R. (1985). Top-down synthesis of divide-and-conquer algo-rithms. Articial Intelligence, vol. 27, no. 1, p. 43 - 96.

[154] Stojanovi£, Z. (2005). A Method For Component-Based And Service-Oriented Software Systems Engineering. Phd Thesis. Delft University OfTechnology.

[155] Sommerville, I. (2006). Software Engineering. 8th Ed. Addison Wesley.

[156] Stickel, E. (2008) SNARK - SRI's New Automated Reasoning Kit.[interaktyvus]. [ºiureta 2009 m. gruodºio 11 d.]. Prieiga per internet¡:http://www.ai.sri.com/∼stickel/snark.html

[157] Sun Microsystems. JavaBeans 1.01 specikacija. [interaktyvus]. [ºiureta2009 m. sausio 10 d.]. http://java.sun.com/beans

[158] Szyperski, C. (2000). Component Software and the Way Ahead. Founda-tions of Component-Based Systems. 2nd Ed. Cambridge University Press.

[159] Szyperski, C. (2000). Component Software Beyound Object-Oriented Pro-gramming. 2nd Ed. MA:Addison-Wesley.

[160] tuikys, V., Dama²evi£ius, R. (2008).Modeliu ir programu abstrak£iosiostransformacijos. Kaunas:Technologija.

[161] Teschke T., Ritter J. (2001). Towards a foundation of component-oriented software reference models. Lecture Notes in Computer Science2177, Springer. p. 7085.

[162] Tilak, O.J., Raje, R. R. (2007). Temporal Interaction Contracts for Com-ponents in a Distributed System. 11th IEEE International Enterprise Dis-tributed Object Computing Conference, IEEE press, p. 339349.

[163] Thai, P.H. Hung, D.V. (2007). Towards a Template Language forComponent-based Programming. Technical Report 354, Macau:UNU/IIST.

Literatura 165

[164] Tourwé, T., Brichau, J., Kellens, A., Gybels K. (2004). Induced inten-tional software views Computer Languages, Systems & Structures, 30(1-2),p. 3547

[165] Tracz., W. (2005). COTS Myths and Other Lessons Learned incomponent-based sofware development. Component Based Software Engi-neering: Putting the Pieces Together. (Heineman, G. T., Councill, W. T.eds.) Addison-Wesley Professional.

[166] Tyugu, E., Harf, M. (1985). Algoritmy strukturnovo sinteza program.Programirovanie. 4, p. 313. (rusu k.).

[167] Tyugu, E. (1988). Knowleadge based programming. Turing InstitutePress.

[168] Tyugu, E. (1985). Konceptualnojie programmirovanijie. Moskva:Mir.(rusu k.).

[169] Tyugu, E. (1975). A programming system with automatic program syn-thesis. LNCS 47, p. 251267.

[170] Tyugu, E. (1991). Three new-generation software environments. Comm.ACM, vol.34, No.6, p. 4659.

[171] Tyugu, E. (1994). Using Classes as Specications for Automatic Con-struction of Programs in the NUT System. Journal of Automated SoftwareEngineering.

[172] Tyugu, E. (1982). Vy£islitielnyje freimy i strukturnyj sintezis programm.Techni£eskaja kibernetika Nr. 6. (rusu k.)

[173] UniFrame Unied Meta-component Model for Distributed Systems.[interaktyvus]. [ºiureta 2007 m. balandºio 8 d.]. Prieiga per internet¡:http://www.cs.iupui.edu/uniFrame

[174] United Nations University, International Institute of Software Technolo-gy. [interaktyvus]. [ºiureta 2007 m. balandºio 8 d.]. Prieiga per internet¡:http://www.iist.unu.edu/

[175] Uustalu, T. et al. (1994). The NUT Language Report. Technical ReportTRITA-IT-R 94:14, Stockholm:Royal Institute of Technology.

[176] Voloº, B. et al. (1982). Sistema PRIZ i is£islienijie vyskazyvanii. Kiber-netika Vol. 6, p. 6370. (rusu k.)

[177] Voloº, B., Kopp, M., Tyugu., E. (1993). The NUT Graphics. TechnicalReport TRITA-IT-R 93:05, Stockholm:Royal Institute of Technology.

166 Literatura

[178] (2006). Knowledge-Based Software Engineering. E.Tyugu, T.Yamaguchi(Eds.) IOS Press.

[179] Voronkov, A. (2002). First-Order Theorem Provers: the Next Genera-tion. Proceedings of the 2002 International Workshop on Description Logics(DL2002). [interaktyvus]. [ºiureta 2007 m. spalio 13 d.]. Prieiga per inter-net¡: http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-53/voronkov.ps

[180] Walldinger, R., Jarvis, P., Dungan, J. (2004) Program Synthesis forMulti-agent Question Answering. Verication: Theory and Practice LNCS2772 p. 443458.

[181] Wallnau, K. C., Hissam S. A., Seacord R.C. (2001). Building Systemfrom Commercial Components. Addison-Wesley.

[182] Watson G.N. (1998). Proof representation in theorem provers.Technical report No 98-13. University of Queensland. [inter-aktyvus]. [ºiureta 2008 m. liepos 1 d.]. Prieiga per internet¡:http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.9242

[183] Web Services Activity. [interaktyvus]. [ºiureta 2006 m. balandºio 18 d.].Prieiga per internet¡: http://www.w3.org/2002/ws/

[184] Web Services Description Language (WSDL) Version 1.2 [inter-aktyvus]. [ºiureta 2006 m. balandºio 18 d.]. Prieiga per internet¡:http://www.w3.org/TR/2003/WD-wsdl12-20030303/wsdl12.pdf

[185] Wenzel, M., Berghofer, S. (2005). The Isabelle System Manual. [in-teraktyvus]. [ºiureta 2008 m. rugpju£io 15 d.]. Prieiga per internet¡:http://isabelle.in.tum.de/dist/Isabelle/doc/system.pdf

[186] Weerawarana, S. et al. (2001). Bean Markup Language: A CompositionLanguage for JavaBeans Components. In Proceedings of the 6th conferenceon USENIX Conference on Object-Oriented Technologies and Systems vol.6 p. 1313.

[187] Weinreich, R., Sametinger, J. (2001). Component Models and Compo-nent Services: Concepts and Principles. Component Based Software Engi-neering: Putting the Pieces Together. (Heineman, G. T., Councill, W. T.eds.) Addison-Wesley Professional. p. 2132.

[188] Whitehead, K. (2002). Component-based Development :Principles andPlaning for Business Systems. Addison-Wesley.

Literatura 167

[189] Xiao, L. (2009). An adaptive security model using agent-oriented MDA.Inf. Softw. Technol., vol. 51, no. 5, p. 933955.

[190] Yoshida, K., Honiden S. (2003). Formal specication of components in acomponent-based framework development method. Systems and Computersin Japan vol. 34, Iss. 8, p. 6276.

A priedas

Publikaciju s¡ra²as

Straipsniai recenzuojamuose Lietuvos ºurnaluose

1. Giedrimas, V. (2009). Modelines architekturos naudojimas kuriantkomponentines programu sistemas. Informacijos mokslai, nr. 50, p.168172.

2. Giedrimas, V. (2007). Generavimo metodu panaudojimas kuriant .NETkomponentines programu sistemas. Informacijos mokslai, nr. 4243, p.246250.

3. Giedrimas, V. (2006). Induktyvinis metodas komponentiniu programusintezeje. Liet. mat. rinkinys, t. 46, spec. nr., p. 103106.

4. Giedrimas, V., Lupeikiene, A. (2005). Komponentiniu programu struktu-rines sintezes teorines problemos. Liet. mat. rinkinys, t. 45, spec.nr., p.139143.

5. Giedrimas, V., Lupeikiene, A. (2004). Komponento specikacijos for-malizavimas. Liet. mat. rinkinys, t. 44, spec. nr., p. 276280.

6. Giedrimas, V. (2003). Programu sistemu automatizuoto surinkimo i²gatavu komponentu uºdavinys Liet. mat. rinkinys, t. 43, spec. nr.,228232

7. Giedrimas, V. (2003). Komponento modelis strukturines programusintezes kontekste. Informacijos mokslai, nr. 26, p. 246250.

169

Uºsienio ºurnaluose ir leidiniuose bei tarptautiniu konferencijudarbuose

1. Giedrimas, V. (2006). Architectures of Component-Based StructuralSynthesis Systems. Databases and Information Systems. Seventh In-ternational Baltic Conference on Databases and Information Systems.Communications. Vilnius:Technika, ISBN 9955-28-013-1, p. 331315.

2. Giedrimas, V. (2005). Component-based Software Generation: TheStructural Synthesis Approach. Proceedings of 7th GPCE YRW 2005,Tallinn, ISBN 9985-894-89-8, p. 1923.

3. Lupeikiene, A., Giedrimas, V. (2005). Component model and its for-malisation for structural synthesis. Scientic Proc. of Riga TechnicalUniversity. Computer Science, vol. 22, ISSN 1407-7493, p. 169180.

Kituose Lietuvos leidiniuose

1. Giedrimas, V. (2005). .NET komponento specikacija programu sin-tezes kontekste. Konferencijos Informacines technologijos 2005 medºi-aga. Kaunas, p. 382385.

B priedas

Komponento modeliu

klasterizavimo rezultatai

B.1. Komponento modeliu klasteriai

iame skyriuje pateikti komponento modeliu klasterizavimo rezultatai. Klas-terizuota siekiant atskleisti kurie komponento modeliai i kokius klasterius galibuti grupuojami. Del metodo specikos po 25-osios iteracijos visi modeliaipriskiriami vienam klasteriui, todel prasminga nagrineti tik anstyvosiose it-eracijose gautus klasterius.

Pastebima, kad po 5-osios iteracijos 17 komponento modeliu sugrupuota i9 klasterius, o po 15-osios i 4.

B.1 pav. Komponento modeliu klasteriu dendograma.

B.2. Komponento modeliu savybiu klasteriai 171

B.2. Komponento modeliu savybiu klasteriai

iame skyriuje pateikti komponento modeliu savybiu klasterizavimo rezul-tatai. Klasterizuota siekiant atskleisti kurios savybes galetu buti grupuojamos.Tikslinga nagrineti tik pirm¡sias ²ios analizes iteracijas, nes klasterizavimometodas neleidºia ivertinti atskiru savybiu pana²umo semantine prasme.

Po pirmosios iteracijos i klasterius suskirstyti ²ie elementai: valdymo ele-mentai (KA) ir membrana, konstrukcija ir sisteminis interfeisas, kenai ir at-vaizdºio tipo jungtis, paslauga ir tranzakcija. Po tre£iosios iteracijos jun-giantysis kodas ir procesas, reikalaujami ir teikiami interfeisai. Idomu tai,kad i²skyrus kenu-atvaizdºio ir paslaugos-tranzakcijos poras, grupuojamos s¡-vokos yra gana artimos ir semantine prasme. inoma, proces¡ tesiant toliau sukiekviena kita iteracija klasterizuojamu objektu semantinis pana²umas nyksta.

B.2 pav. Komponento modeliu savybiu klasteriu dendograma.

Vaidas Giedrimas

KOMPONENTINIŲ PROGRAMŲ SISTEMŲ

GENERAVIMO METODAS Daktaro disertacija

Fiziniai mokslai (P 000)

Informatika (09 P)

Informatika, sistemų teorija (P 175)

___________________________

SL 843.2010-04-02. 14,3 leidyb. apsk. l. Tiražas 20. Užsakymas 27.

Išleido VšĮ Šiaulių universiteto leidykla, Vilniaus g. 88, LT-76285 Šiauliai.

El. p. [email protected], tel. (8 ~ 41) 52 09 80, faks. (8 ~ 41) 52 09 80.

Spausdino UAB „Šiaulių knygrišykla“, P. Lukšio 9A, LT-76207, Šiauliai.

vaidas giedrimas komponentiniŲ programŲ sistemŲ … · komponen tiniuprogramu si stemuurimok...

Documents