Univerza v Mariboru - core.ac.uk · We have described GoF and J2EE design patterns using our notation. Based on that, we have also developed an algorithm for guiding a dialog with

Univerza v Mariboru

Fakulteta za elektrotehniko, računalništvo in informatiko

Doktorska disertacija

Pospeševanje uporabe načrtovalskih

vzorcev s pomočjo ontološko podprtega

repozitorija

Maribor, 2009 Luka Pavlič

Univerza v Mariboru

Fakulteta za elektrotehniko, računalništvo in informatiko

Doktorska disertacija

Pospeševanje uporabe načrtovalskih vzorcev s

pomočjo ontološko podprtega repozitorija

Luka Pavlič

Mentor: prof. dr. Ivan Rozman

Somentor: prof. dr. Marjan Heričko

Maribor, 2009

III

IV

V

Ključne besede

Ponovna uporaba, načrtovalski vzorci, ontologije, semantični splet,

repozitorij načrtovalskih vzorcev, voden dialog, inteligenten algoritem.

UDK: 004.774.2:004.93(043.3)

Povzetek

Doktorska naloga se ukvarja s problematiko izboljšave ponovne uporabe

na področju programskega inženirstva. Kot ovira pri ponovni uporabi na

osnovi vzorcev se kaže težavna izbira ustreznega vzorca. Zato naloga

predstavi sistem, ki vključuje tako eksperte s področja načrtovalskih

vzorcev kot tudi neizkušene razvijalce. Na osnovi ekspertnega znanja

omogoči predlagati ustrezen načrtovalski vzorec za podan načrtovalski

problem.

V nalogi so na enem mestu zbrane in medsebojno primerjane formalne

metode predstavitve načrtovalskih vzorcev. Razvili smo tudi lastno

formalno notacijo načrtovalskih vzorcev, temelječo na ontologijah. V

lastni notaciji smo zapisali načrtovalske vzorce katalogov GoF in J2EE. Na

tej osnovi smo razvili tudi lasten algoritem, ki vodi dialog z uporabnikom.

Na osnovi ločenih ekspertnih nasvetov v obliki vprašanj in odgovorov,

zna inteligentni algoritem voditi dialog z razvijalcem. Skozi dialog

razvijalec poda svoj načrtovalski problem, na osnovi katerega je

algoritem sposoben predlagati ustrezen načrtovalski vzorec. Razvili smo

tudi lastno metodologijo in podporno platformo, ki omogočata

enostavno uporabo naprednih funkcionalnosti. Naloga jih demonstrira s

pomočjo študije primera.

Ugotovili smo, da so razvijalci sprejeli naš sistem z odobravanjem. Njihova

uspešnost se ob vodenem dialogu signifikantno poveča.

VI

Improving design pattern adoption with an

ontologybased repository

Key Words

Reuse, design patterns, ontologies, semantic web, design pattern

repository, guided dialog, intelligent algorithm.

Abstract

This dissertation addresses the issue of improving reuse in the area of software engineering. The rapidly growing number of design patterns has not yet been adequately supported by efficient search and management tools, making the patterns uninviting for a large part of the software development community. In this way, the issue of managing and selecting design patterns in a straight-forward way has become the primary challenge. In this dissertation, we will describe a possible solution for the improvement of design pattern adoption and present a platform that gives design patterns some new and long-overdue momentum. Using our technique for formal design pattern specifications, we have developed an experimental prototype for a new design pattern repository based on semantic web technologies. A new Ontology-Based Design Pattern Repository (OBDPR) has been developed that can also be used as a platform for introducing advanced services. We have described GoF and J2EE design patterns using our notation. Based on that, we have also developed an algorithm for guiding a dialog with a developer. A dialog is automatically composed from separate, simple expert advice. A dialog is used to extract the design problem from the developer. Based on that, the algorithm makes it possible to propose a design pattern to use. We have also developed a holistic methodology, including all aspects of using our system. With the help of established scientific research methods, we have found out that our methods increase design pattern adoption significantly.

VII

Zahvale

Iskreno bi se želel zahvaliti vsem, ki ste mi kakorkoli pomagali pri snovanju doktorske naloge. Brez vaše pomoči mi ne bi uspelo uresničiti zastavljenih ciljev. Za pomoč, usmerjanje, posredovana spoznanja in ideje pri doktorskem delu se zahvaljujem mentorju in somentorju, prof.dr. Ivanu Rozmanu in prof.dr. Marjanu Heričku. Za dragocene nasvete se še posebej zahvaljujem izr.prof.dr. Viliju Podgorelcu. Hvala za neprecenljive posredovane izkušnje, nasvete in prijetno delovno okolje vsem sodelavkam in sodelavcem Inštituta za informatiko. Prav posebna zahvala pa gre vsem mojim najdražjim. Predvsem staršema, ki sta me dolga leta nesebično podpirala in mi omogočala, da sproščeno uresničujem svoje želje. Neskončno se zahvaljujem svoji življenjski sopotnici Nataši, brez katere te naloge gotovo ne bi bilo. Hvala za vso tvoje razumevanje in ljubezen, zame sta kot hrana in pijača. Hvala, ker mi venomer odpuščate premajhno pozornost in čas, ki vam ga posvečam, zavoljo meni dragih dejavnosti!

VIII

Kazalo vsebine

1. UVOD ................................................................................................................................................... 1

1.1 STRUKTURA DISERTACIJE .................................................................................................................................. 1

1.2 OPREDELITEV RAZISKOVALNEGA PROBLEMA......................................................................................................... 4

1.2.1 Ponovna uporaba in načrtovalski vzorci .......................................................................................... 4

1.2.2 Način uporabe načrtovalskih vzorcev .............................................................................................. 6

1.2.3 Raziskovalna vprašanja ................................................................................................................. 11

1.2.4 Upoštevane predpostavke in omejitve .......................................................................................... 13

2. CILJI RAZISKAVE .................................................................................................................................. 15

2.1 TEZA RAZISKAVE .......................................................................................................................................... 15

2.2 IZVIRNI ZNANSTVENI PRISPEVKI DISERTACIJE ....................................................................................................... 16

2.2.1 Pregled formalnih metod predstavitve načrtovalskih vzorcev ...................................................... 16

2.2.2 Lastna formalna predstavitev vzorcev in znanja o vzorcih ............................................................ 16

2.2.3 Algoritem predlaganja vzorca ....................................................................................................... 16

2.2.4 Krovna metodologija ..................................................................................................................... 17

2.2.5 Informacijska platforma z inteligentnimi rešitvami ...................................................................... 17

2.3 UPORABLJENE METODE ZNANSTVENEGA RAZISKOVANJA ....................................................................................... 17

3. SORODNA DELA .................................................................................................................................. 20

3.1 PONOVNA UPORABA IN NAČRTOVALSKI VZORCI .................................................................................................. 20

3.2 FORMALNI ZAPISI NAČRTOVALSKIH VZORCEV IN NJIHOVE APLIKACIJE ....................................................................... 22

3.2.1 Jezik DPML ..................................................................................................................................... 25

3.2.2 Jezik RSL ......................................................................................................................................... 28

3.2.3 Jezik OCSID .................................................................................................................................... 29

3.2.4 Jezik Spine ...................................................................................................................................... 30

3.2.5 Jezik SPQR ...................................................................................................................................... 30

3.2.6 Object‐Calculus .............................................................................................................................. 30

3.2.7 Jezik RBML ..................................................................................................................................... 31

3.2.8 Jezik Slam‐SL .................................................................................................................................. 32

3.2.9 Ontološki opis načrtovalskih vzorcev z ontologijo ODOL ............................................................... 33

3.2.10 Jezik URN .................................................................................................................................. 35

3.2.11 Prevajalnik PEC ......................................................................................................................... 35

3.2.12 Jezik LePUS ................................................................................................................................ 36

3.2.13 Jeziki časovne logike, logike prvega reda, Prolog in BPSL ......................................................... 37

3.2.14 Primerjava jezikov za formalen zapis načrtovalskih vzorcev .................................................... 38

IX

3.3 NAČIN IZBIRE NAČRTOVALSKIH VZORCEV ........................................................................................................... 39

4. ONTOLOŠKO ZASNOVANA FORMALNA PREDSTAVITEV NAČRTOVALSKIH VZORCEV ............................. 44

4.1 OSNOVE ONTOLOGIJ ..................................................................................................................................... 46

4.2 TEHNOLOŠKA REŠITEV: STANDARDI IN TEHNOLOGIJE SEMANTIČNEGA SPLETA ............................................................ 48

4.2.1 Iniciativa semantičnega spleta ...................................................................................................... 48

4.2.2 Tehnologije semantičnega spleta .................................................................................................. 50

4.2.3 Zapis ontologij z jezikom OWL ....................................................................................................... 52

4.3 ZAPIS GOF IN J2EE NAČRTOVALSKIH VZORCEV ................................................................................................... 53

4.4 ZAPIS EKSPERTNEGA ZNANJA O VZORCIH ........................................................................................................... 55

4.5 PRIMER UPORABE: ALGORITEM ZA PREDLAGANJE USTREZNEGA NAČRTOVALSKEGA VZORCA ......................................... 57

4.5.1 Cilji algoritma ................................................................................................................................ 57

4.5.2 Vhodni in izhodni podatki algoritma ............................................................................................. 58

4.5.3 Združevanje podanih odgovorov v vektor relevantnosti ............................................................... 60

4.5.4 Izračun poteka dialoga na osnovi informacijske entropije ............................................................ 62

4.5.5 Lastna, na entropiji temelječa mera relevantnosti vektorja .......................................................... 64

4.5.6 Zapis algoritma in izkušnje ............................................................................................................ 69

4.5.7 Primerjava algoritma s fiksnim odločitvenim drevesom ............................................................... 71

5. METODOLOGIJA UPORABE NAČRTOVALSKIH VZORCEV IN PODPORNA PLATFORMA ............................ 75

5.1 METODOLOGIJA IN ZAHTEVE PLATFORME Z VIDIKA AVTORJEV VZORCEV ................................................................... 76

5.2 METODOLOGIJA IN ZAHTEVE PLATFORME Z VIDIKA RAZVIJALCEV ............................................................................ 77

5.3 OPIS FUNKCIONALNOSTI PLATFORME ............................................................................................................... 78

5.4 OPIS DODATNIH MODULOV ............................................................................................................................ 84

5.4.1 Modul za iskanje vzorcev ............................................................................................................... 84

5.4.2 Modul za predlaganje primernih vzorcev ...................................................................................... 85

5.4.3 Modul za trening in eksperiment ................................................................................................... 87

5.5 ŠTUDIJA PRIMERA: UPORABA METODOLOGIJE IN PLATFORME PRI REŠEVANJU KONKRETNEGA PROBLEMA ........................ 88

6. IZVEDBA RAZISKAVE ........................................................................................................................... 92

6.1 NAČRTOVANJE EKSPERIMENTA ........................................................................................................................ 92

6.2 IZVEDBA ANKETE PRED EKSPERIMENTOM........................................................................................................... 95

6.3 IZVEDBA ANKETE PO EKSPERIMENTU ................................................................................................................ 97

6.4 PREDSTAVITEV REZULTATOV EKSPERIMENTA IN ANKET ......................................................................................... 98

6.4.1 Profili udeležencev po skupinah .................................................................................................... 99

6.4.2 Rezultati skupne 1 ....................................................................................................................... 101

6.4.3 Rezultati skupne 2 ....................................................................................................................... 103

6.4.4 Rezultati skupine 3 ...................................................................................................................... 105

6.4.5 Rezultati po nalogah ................................................................................................................... 106

X 6.4.6 Zadovoljstvo kandidatov ............................................................................................................. 108

7. DISKUSIJA REZULTATOV .................................................................................................................... 109

7.1 VERODOSTOJNOST REZULTATOV ................................................................................................................... 110

7.2 REZULTATI SKUPINE 1 ................................................................................................................................. 110

7.3 REZULTATI SKUPINE 2 ................................................................................................................................. 112

7.4 PRIMERJAVA REZULTATOV PO NALOGAH ......................................................................................................... 113

7.5 PRIMERJAVA REZULTATOV SKUPINE 1 IN SKUPINE 2 ........................................................................................... 114

7.6 OBRAVNAVA HIPOTEZ ................................................................................................................................. 116

7.6.1 Obravnava hipoteze H1 ............................................................................................................... 116

7.6.2 Obravnava hipoteze H2 ............................................................................................................... 116

8. ZAKLJUČEK ....................................................................................................................................... 118

9. LITERATURA ..................................................................................................................................... 121

10. SEZNAM KRATIC, OZNAK IN PREVODOV ............................................................................................ 126

11. PRILOGE ........................................................................................................................................... 129

11.1 ONTOLOGIJA OBDPR ............................................................................................................................ 129

11.2 NAČRTOVALSKI PROBLEMI, UPORABLJENI V EKSPERIMENTU (V ANGLEŠKEM JEZIKU) ............................................ 133

XI

Kazalo slik

Slika 1: Razredni diagram vzorca »Adapter« ........................................................................................................... 8

Slika 2: Vloga vzorcev pri reševanju načrtovalskih problemov ............................................................................. 18

Slika 3: Gradniki jezika DPML (Maplesden, 2007) ................................................................................................. 26

Slika 4: Primer uporabe DPML za definiranje vzorca abstraktna tovarna (Maplesden, 2007) .............................. 26

Slika 5: Elementi za prikaz ustvarjanja objektov (Maplesden, 2007) .................................................................... 27

Slika 6: Primer ustvarjanja objektov za konkretno abstraktno tovarno (Maplesden, 2007) ................................. 27

Slika 7: Jedro jezika RBML ..................................................................................................................................... 32

Slika 8: Hierarhija razredov ontologije ODOL ........................................................................................................ 33

Slika 9: Razredi za opis lastnosti razredov vzorca ................................................................................................. 34

Slika 10: Opis abstraktne tovarne v ODOL‐u ......................................................................................................... 34

Slika 11: Elementi jezika LePUS ............................................................................................................................. 37

Slika 12: Sklad tehnologij semantičnega spleta .................................................................................................... 51

Slika 13: Preprost RDF stavek ................................................................................................................................ 51

Slika 14: Preprosta semantična mreža .................................................................................................................. 52

Slika 15: Jedro ontologije za opis vzorcev ............................................................................................................. 55

Slika 16: Jedro ontologije za zapis ekspertnega znanja o vzorcih ......................................................................... 56

Slika 17: Sprememba vektorja relevantnosti glede na podan odgovor ................................................................ 61

Slika 18: Stanje vektorja C z maksimalno in minimalno vrednostjo Rel(C) ........................................................... 66

Slika 18: Shematska predstavitev predlagane metodologije ................................................................................ 75

Slika 19: BPMN diagram z vidika eksperta ............................................................................................................ 77

Slika 20: BPMN diagram z vidika razvijalca ........................................................................................................... 78

Slika 21: Arhitektura prototipnega repozitorija vzorcev ....................................................................................... 79

Slika 22: Pregled surovih RDF podatkov ................................................................................................................ 82

Slika 23: Uporabniško prijazen pogled na vzorec .................................................................................................. 82

Slika 24: Uporabniško prijazen pogled na vsebnik ................................................................................................ 83

Slika 25: Urejanje vprašanj in odgovorov .............................................................................................................. 83

Slika 26: Pregled vprašanj in odgovorov ............................................................................................................... 84

Slika 27: Uporaba iskanja s pomočjo ključnih besed ............................................................................................. 85

Slika 28: Uporaba storitve predlaganja vzorca ...................................................................................................... 87

Slika 29: Okolje, namenjeno poteku eksperimenta .............................................................................................. 87

Slika 30: Empirično raziskovanje povezave med odvisnimi in neodvisno spremenljivko ..................................... 92

Slika 31: potek eksperimenta ................................................................................................................................ 93

Slika 32: potek eksperimenta kontrolne skupine .................................................................................................. 95

Slika 33: Grafična predstavitev pravilnosti odgovarjanja .................................................................................... 115

XII

Kazalo formul

Formula Eq1: Kombiniranje vektorja relevantnosti s podanim odgovorom ......................................................... 61

Formula Eq2: Izračun entropije vektorja relevantnosti C ..................................................................................... 64

Formula Eq3: Izračun relevantnosti vektorja C ..................................................................................................... 66

Formula Eq4: Izračun faktorja napredka vektorja C .............................................................................................. 67

Formula Eq5: Celotna formula za izračun relevantnosti vektorja C ...................................................................... 68

Kazalo tabel

Tabela 1: Primerjava predstavljenih formalnih metod ......................................................................................... 38

Tabela 2: Število in dolžina dialogov fiksnega odločitvenega drevesa v povezavi s posameznimi vzorci ............. 72

Tabela 3: Profili udeležencev eksperimenta po skupinah ................................................................................... 100

Tabela 4: Pravilnost reševanja nalog v skupini 1 ................................................................................................. 101

Tabela 5: Porabljen čas na nalogo v skupini 1 ..................................................................................................... 103

Tabela 6: Pravilnost reševanja nalog v skupini 2 ................................................................................................. 104

Tabela 7: Porabljen čas na nalogo v skupini 2 ..................................................................................................... 105

Tabela 8: Pravilnost in hitrost reševanja nalog v skupini 3 ................................................................................. 106

Tabela 9: Pravilnost odgovorov kandidatov po nalogah ..................................................................................... 107

Tabela 10: Rezultati ankete po eksperimentu .................................................................................................... 108

1 Pavlič L.: Pospeševanje uporabe načrtovalskih vzorcev s pomočjo ontološko podprtega repozitorija Doktorska naloga. Maribor, 2009.

1. Uvod

1.1 Struktura disertacije

Doktorska naloga opiše raziskavo, katere cilj je izboljšava ponovne

uporabe na področju programskega inženirstva, s pomočjo

načrtovalskih vzorcev. V nalogi sledimo uveljavljenim metodam

znanstveno-raziskovalnega dela, ki jih opišemo v 10 poglavjih.

Že v uvodnem poglavju predstavimo izzive, s katerimi se ukvarjamo

tekom raziskave. Raziskovalni problem opišemo v štirih podpoglavjih. V

prvem predstavimo glavne ideje ponovne uporabe na osnovi

načrtovalskih vzorcev. Razložimo od kod načrtovalski vzorci izhajajo ter

kako in zakaj načrtovalski vzorci dvignejo stopnjo ponovne uporabe. V

drugem podpoglavju (»Način uporabe načrtovalskih vzorcev«)

predstavimo možnosti, ki jih načrtovalski vzorci predstavljajo razvijalcem z

vidika snovanja informacijskih sistemov, komunikacije med razvijalci ter

nenazadnje še ne izkoriščene možnosti. Na tej osnovi v tretjem

podpoglavju predstavimo raziskovalna vprašanja, na katera

nameravamo tekom doktorske naloge odgovoriti. V zadnjem

podpoglavju (»Upoštevane predpostavke in omejitve«) opišemo

aspekte, ki smo jih tekom raziskave naslovili in tiste, ki smo jih namerno

izpustili tekom raziskave. Zadnje tudi argumentiramo.

Drugo poglavje (»Cilji raziskave«) natančneje opredeli prispevek

doktorske naloge. Natančno opiše teze doktorske naloge, našteje izvirne

znanstvene prispevke pričujočega dela ter nenazadnje podrobno opiše


metode znanstvenega raziskovanja, ki smo jih uporabili tekom dela na

temi doktorske naloge.

V tretjem poglavju (»Sorodna dela«) predstavimo najpomembnejše

dosedanje dosežke na področjih doktorske naloge. Tako v prvem

podpoglavju predstavimo obstoječe temeljne objave na področju

ponovne uporabe in načrtovalskih vzorcev. Predstavimo dela, ki

opisujejo pomen ustrezne formalne predstavitve znanja o načrtovalskih

vzorcih. Sorodna dela, ki se ukvarjajo s takšnimi formalnimi notacijami

predstavimo v naslednjem podpoglavju (»Formalni zapisi načrtovalskih

vzorcev in njihove aplikacije«), ki ga zaključimo s primerjalno tabelo

posameznih, najpomembnejših možnosti za formalizacijo načrtovalskih

vzorcev. Predvsem nas zanima potencial posamezne formalizacije z

vidika lažjega iskanja primernih načrtovalskih vzorcev. To podpoglavje

služi kot osnova kasneje predstavljeni lastni notaciji znanja o načrtovalskih

vzorcih. V zadnjem podpoglavju (»Način izbire načrtovalskih vzorcev«)

predstavimo sorodna dela s področja iskanja in predlaganja

načrtovalskih vzorcev. Predstavljena dela ne bazirajo zgolj na domeni

načrtovalskih vzorcev, saj služijo kot osnova lastnemu pristopu

predlaganja načrtovalskih vzorcev, ki ga v tem trenutku v literaturi še ni

zaslediti.

Poglavje »Ontološko zasnovana formalna predstavitev načrtovalskih

vzorcev« je namenjeno predstavitvi lastne formalne notacije

načrtovalskih vzorcev in znanja o njih. Najprej predstavimo pričakovanja

od formalne notacije, nato jo tudi opišemo. Ker lastna notacija temelji na

ontologijah, v prvem podpoglavju predstavimo ideje, na katerih temeljijo

ontologije. Drugo podpoglavje opiše sklad tehnologij semantičnega

spleta, saj le-tega uporabimo kot tehnološko osnovo svoje notacije in

sistema. V predzadnjih dveh podpoglavjih na primeru vzorcev GoF in

J2EE demonstriramo uporabo lastne notacije. Prikažemo tudi, kako v

lastni notaciji zapišemo ekspertno znanje. Zadnje podpoglavje predstavi

zahteve in zasnovo algoritma, ki omogoča, na osnovi predhodno


predstavljene notacije, voditi dialog z uporabnikom, ki išče ustrezen

načrtovalski vzorec za podano problemsko situacijo.

Ob četrtem tvori osrednji del naloge tudi peto poglavje: »Metodologija

uporabe načrtovalskih vzorcev in podporna platforma«. V njem opišemo

platformo, razvito na osnovi lastne notacije in način, kako se platformo

uporabi. V prvih dveh podpoglavjih opišemo metodologijo, ki ji sledijo

razvijalci in eksperti s področja načrtovalskih vzorcev. Naslednji dve

podpoglavji opišeta zasnovo in funkcionalnosti platforme, ki omogoča

predhodno predstavljeno metodologijo. Poglavje zaključimo s študijo

primera, ki demonstrira konkretno uporabo platforme in metodologije.

Šesto poglavje (»Izvedba raziskave«) podrobneje opiše izkušnje pri realni

uporabi našega sistema. Predstavimo eksperiment in anketi pred ter po

eksperimentu. Podatke analiziramo in jih kot takšne tudi predstavimo v

zadnjem podpoglavju.

Na podlagi pridobljenih rezultatov v sedmem poglavju (»Diskusija

rezultatov«) predstavimo sklepe, ki izhajajo iz podatkov. Predstavimo tudi

predvidevanja, ki presegajo okvire zastavljenih hipotez. Nakažemo še

možnosti nadaljnjega razvoja dela, predstavljenega v tej doktorski

nalogi.

Doktorsko nalogo sklenemo z zaključnim poglavjem, seznamom

uporabljene literature in prilogami, ki služijo kot podpora osnovnemu

tekstu.


1.2 Opredelitev raziskovalnega problema

»With more than 20 design patterns in the catalog to choose from, it might be hard to find the one that addresses a particular design problem, especially if the catalog is new and unfamiliar to you.« (Gamma et al., 1995). »Že če katalog ponuja komaj 20 načrtovalskih vzorcev, utegne biti težko izbrati tistega, ki naslavlja določen načrtovalski problem; še posebej če kataloga razvijalec ne pozna dovolj dobro.«

»Only experienced software engineers who have a deep knowledge of patterns can use them effectively. These developers can recognize generic situations where a pattern can be applied. Inexperienced programmers, even if they have read the pattern books, will always find it hard to decide whether they can reuse pattern or need to develop a special-purpose solution.« (Sommerville, 2004). »Le razvijalci s poglobljenim znanjem o načrtovalskih vzorcih jih lahko uporabljajo efektivno in prepoznajo situacije, kjer je vzorec možno uporabiti. Neizkušenim razvijalcem se bo vedno zdelo težko odločiti, ali uporabiti vzorec, ali razviti lastno rešitev, tudi če so prebrali nekaj knjig o načrtovalskih vzorcih.«

1.2.1 Ponovna uporaba in načrtovalski vzorci

Razvoj novih sistemov na osnovi dokazano uspešnih gradnikov in izkušenj

je eden izmed temeljev vsake inženirske discipline. Programsko inženirstvo

glede tega ni izjema. Prvi poizkusi vzpostavitve sistematične ponovne

uporabe na področju programskega inženirstva so se pojavili leta 1968,

ko je Douglas McIlroy iz Bellovih laboratorijev predlagal ponovno

uporabo na osnovi komponent (McIlroy, 1969).

Danes ponovno uporabo v programskem inženirstvu tipično delimo

glede stopnje sistematičnosti. Tako lahko imamo opravka s planirano

ponovno uporabo, kjer procesi razvoja programske opreme sami po sebi

težijo k ponovni uporabi. Na drugi strani se pogosto srečujemo tudi z

oportunistično ponovno uporabo, kjer se ponovna uporaba dogaja le

po potrebi in na ad-hoc način, pa naj bodo ponovno uporabljeni

gradniki razviti znotraj hiše ali kupljeni na trgu (Vatovec-Krmac, 1998). Pri

razvoju programske opreme kot inženirski disciplini bi seveda želeli, da se


čim več ponovne uporabe dogaja planirano in s čim manj ad-hoc

situacijami.

Na področju enostavne, hitrejše in bolj sistematične ponovne uporabe je

bilo narejeno mnogo raziskav(npr. Vatovec-Krmac, 1998). Njihovi rezultati

so med drugim botrovali tudi oblikovanju glavnih ciljev objektne

orientacije kot takšne. Zato ni naključje, da so karakteristike programske

opreme, kot so modularnost, šibka sklopljenost, močna vezljivost,

skrivanje podatkov in ločitev interesov, hkrati glavne zahteve ponovne

uporabe in prednosti, ki nam jih prinaša objektna orientacija – danes

vodilna paradigma razvoja informacijskih rešitev.

S ponovno uporabo na nivoju konkretnih delov informacijskih sistemov

(metode, razredi, vmesniki, funkcije ipd.) se srečujemo tako rekoč pri

vsakodnevnem razvoju programske opreme. Ponovno lahko

uporabljamo tako izvorno kodo rešitev kot tudi v celoti delujoče

komponente. Komponente so bile pravzaprav prva dobro raziskana in

opisana možnost ponovne uporabe. Douglas McIlroy je leta 1968 prvič

opisal komponente kot ponovno uporaben gradnik informacijskih

sistemov z natančno določenim vmesnikom in funkcionalnostjo (McIlroy,

1968).

Pri razvoju informacijskih rešitev se vsakodnevno srečujemo tudi s

ponovno uporabo s pomočjo t.i. knjižnic. Knjižnica je zbirka rutin

(razredov, metod, funkcij ipd.), ki jo uporabljamo pri razvoju programske

opreme. Razvijalci se relativno pogosto odločajo, da določen abstrakten

del informacijskih rešitev razvijajo v obliki knjižnic, ki se nato uporabljajo v

več, sicer ločenih informacijskih rešitvah. Knjižnice kot takšne so tudi

neločljiv del platform za razvoj informacijskih rešitev, kot so platforma .NET

in Javanske platforme. Torej so kot takšne bržkone najpogosteje

uporabljen mehanizem ponovne uporabe.

Pri razvoju informacijskih rešitev lahko ponovno uporabo vzpostavimo

tudi s kompleksnejšimi mehanizmi, kot so ogrodja, programske tovarne,


predloge rešitev, ciljne platforme ipd. Le-ti so bolj specializirani in

omogočajo razvoj ciljno usmerjene informacijske rešitve, zgolj s

prilagoditvijo nekaterih delov že izdelane programske opreme in

razvojem dodatnih gradnikov, ki zadostijo specifičnim funkcionalnim

zahtevam. Na takšen način lahko enostavno razvijamo celotno družino

sorodnih informacijskih rešitev. Takšen pristop je v praksi čedalje bolj

uveljavljen.

Na višjem nivoju abstrakcije se srečamo s ponovno uporabo s pomočjo

vzorcev (angl. software patterns). Vzorci ne predstavljajo konkretne

implementacije, temveč praktično preizkušene ideje, kako rešiti

določeno družino problemov. Vzorce srečamo tudi kot sestavni del

ogrodij. Ogrodja so še en mehanizem ponovne uporabe in predstavljajo

implementacijo vzorcev, ki so tipično domensko usmerjena. Na tak način

predstavljajo ogrodja opcijo ponovne uporabe kot skupni imenovalec

cele družine informacijskih rešitev.

Končni namen sistematične ponovne uporabe, in z njo načrtovalskih

vzorcev, je izboljšava kakovosti programske opreme hkrati z dvigom

produktivnosti. (Vatovec-Krmac, 1998)

1.2.2 Način uporabe načrtovalskih vzorcev

Še preden predstavimo trenutno uveljavljen način uporabe načrtovalskih

vzorcev, si poglejmo eno izmed trenutno uveljavljenih definicij:

Načrtovalski vzorec opisuje jedro rešitve določenega ponavljajočega se

problema v podanem kontekstu.

(Gamma et. al., 1995)

Če govorimo o vzorcih v programskem inženirstvu imamo pogosto v

mislih načrtovalske vzorce. Le-ti pa niso edina vrsta vzorcev. Avtorji so

glede stopnje abstrakcije zaznali celo vrsto različnih vzorcev, ki jih

uporabljamo na področju programskega inženirstva (Rising, 2007):


• vzorce informacijske analize, ki so najbolj splošna oblika vzorcev;

• arhitekturne vzorce;

• načrtovalske vzorce;

• vzorce interakcije in

• vzorce v implementaciji programske opreme (idiomi).

Vzorce na področju programskega inženirstva je mogoče deliti še dalje

(npr. vzorci v podatkovni bazi, vzorci pri gradnji ontologij, vzorci

komunikacije ipd.). Ker se bomo tudi tekom doktorske naloge omejili zgolj

na načrtovalske vzorce, bomo tudi izraz vzorec pojmovali kot

načrtovalski vzorec.

Načrtovalski vzorec kot takšen ni dokončen načrt informacijske rešitve, ki

bi ga lahko neposredno pretvorili v programsko kodo. Nakazuje le jedro

rešitve. Načrtovalski vzorci s področja objektne orientacije nakazujejo

relacije in interakcije med razredi ali objekti, predpisujejo pa tudi zgradbo

vmesnikov.

Kot primer poglejmo enega pogosteje uporabljenih načrtovalskih

vzorcev: adapter (Gamma et. al., 1995). Struktura vzorca, predstavljena z

UML razrednim diagramom, je predstavljena na sliki 1. Vzorec adapter

ponuja rešitev v primeru, ko bi želeli uporabiti določen obstoječ gradnik

(komponento) v svojem sistemu, pri čemer smo pričakovali drugačen

vmesnik od tega, ki ga komponenta ponuja. Hkrati ne želimo ali ne

moremo spremeniti vmesnika. Navkljub nezdružljivim vmesnikom pa bi

želeli povezati komponento (Adaptee) s svojo rešitvijo (Client).

Predlagana rešitev predvideva uvedbo vmesnega razreda (Adapter), ki

se zaradi dedovanja od pričakovanega vmesnika (Target) naši rešitvi

(Client) predstavi v uporabni obliki, hkrati pa s pomočjo proženja

operacij obstoječe komponente vse zahteve naše rešitve, ustrezno

delegira obstoječi komponenti.


Slika 1: Razredni diagram vzorca »Adapter«

Vidimo, da že opis namena in zgradbe načrtovalskega vzorca

omogočata relativno enostavno implementacijo konkretne rešitve, hkrati

pa je načrtovalski vzorec dovolj splošen, da ga je možno uporabiti v tako

rekoč poljubnem kontekstu: od povezovanja računalniških sistemov v

velikih organizacijah pa do prikazovanja podatkov v namizni aplikaciji.

Naloga arhitekta in razvijalca, skratka uporabnika načrtovalskih vzorcev,

je, da takšen vzorec najde ter njegovo strukturo prilagodi svoji domeni.

Torej takšno splošno rešitev prilagodi določenim domenskim zahtevam.

Uporaba načrtovalskih vzorcev ima zato posledično mnoge pozitivne

učinke (Taibi, 2006):

• Vzorci opisujejo najboljše prakse iz preteklosti, torej ponujajo dobro

izhodišče reševanja podobnih problemov v prihodnosti. Kot takšni

tudi ponujajo idealno orodje prenosa znanja iz izkušenejših na manj

izkušene razvijalce.

• Vzorci zaradi svoje fleksibilne zasnove (kontekstna neodvisnost)

omogočajo uporabo na veliko različnih načinov.

• Vzorci lahko služijo kot zelo učinkovito orodje komunikacije med

razvijalci.

• Vzorce lahko pojmujemo kot arhitekturne rešitve na mikro nivoju,

na osnovi katerega kasneje gradimo boljše, večje arhitekture.


Po predstavljenih dejstvih je jasno, da so načrtovalski vzorci zelo

pomemben koncept ponovne uporabe v programskem inženirstvu. Žal

se na podlagi vsakodnevnih izkušenj razvijalcev zdi, da poznavanje in

uporaba načrtovalskih vzorcev v praksi nikoli nista zares zaživela v smislu

vsakodnevne utečene prakse. Prav tako se je razširjanje znanja o

načrtovalskih vzorcih in njihovi uporabi ustavilo pri tiskanih katalogih

vzorcev in zelo omejenih zbirkah na svetovnem spletu.

Ti katalogi opisujejo vzorce v dokumentih, ki so le delno strukturirani s

kanonsko formo in so kot takšni neformalni. Njihov namen je predvsem

pomagati razvijalcem razumeti namen in način uporabe načrtovalskega

vzorca ter jim podati smernice pri implementaciji. Pattern Almanac iz leta

2000 (Rising, 2000) govori o tem, da imamo od pojava načrtovalskih

vzorcev v programskem inženirstvu na voljo nekaj 10 katalogov vzorcev,

z nekaj 100 vzorci. Menimo, da je v kombinaciji s tradicionalno

dokumentacijo vzorcev to tudi razlog slabše uporabe načrtovalskih

vzorcev.

Žal se je izkazalo, da sama prisotnost načrtovalskih vzorcev ni dovolj za

vzpostavitev učinkovite ponovne uporabe na tem nivoju (Manolescu,

2007). Raziskave kažejo na nizko stopnjo uporabe vzorcev (več kot

polovica razvijalcev sploh ne pozna koncepta vzorcev) v vsakodnevnih

projektih (Manolescu, 2007).

Glede na to, da so načrtovalski vzorci namenjeni tudi novincem in njihovi

komunikaciji z izkušenimi razvijalci, lahko sklepamo, da uporaba desetin

tiskanih katalogov pri tem ne more veliko pomagati. Prav tako imajo v

množici katalogov razvijalci težave pri iskanju vzorca, ki bi ga lahko

uporabili za reševanje določenega načrtovalskega problema. Težava

postaja še bolj očitna ob ugotovitvi avtorjev kataloga GoF, da se celo

njihov katalog s 24 vzorci, s tega vidika izkaže za problematičnega

(Gamma et. al., 1995). Očitno je torej, da bo z namenom učinkovitejše

uporabe vzorcev nujno vzpostaviti ustrezno informacijsko platformo, ki bo


omogočala uporabo vzorcev tudi avtomatskim orodjem, da bodo

pomagala razvijalcem. Tradicionalen opis načrtovalskih vzorcev pa tukaj

odpove.

Problema so se zavedli že mnogi avtorji (Taibi, 2006). Poleg

neformalnega opisa načrtovalskih vzorcev predlagajo še celo množico

semiformalnih in formalnih metod predstavitve načrtovalskih vzorcev, z

namenom uporabe naprednih storitev na osnovi znanja o načrtovalskih

vzorcih. Kot ugotavljajo avtorji, ki so se že spopadli s formalizacijo

načrtovalskih vzorcev, potrebujemo takšen zapis predvsem z namenom

(Taibi, 2006):

• Omogočiti želimo boljše razumevanje vzorcev in njihove

kompozicije. S tem dosežemo boljše poznavanje situacije, v kateri

lahko učinkovito uporabimo določen vzorec.

• Učinkovito želimo voditi povezave med vzorci v smislu alternativ,

različic, izključujočih vzorcev ipd.

• Omogočiti želimo podporo orodij v aktivnostih, povezanih z vzorci.

Obstoječi poizkusi formalne predstavitve načrtovalskih vzorcev obsegajo

uporabo tako čistih matematičnih zapisov na osnovi logike prvega reda,

časovne logike, specializiranih algeber ipd., kot tudi uporabo tehnologij,

ki omogočajo enostavno uporabo vzorcev s strani orodij na eni strani, in

na drugi s strani človeških uporabnikov. Menimo, da je to pravilen pristop,

zato bomo tudi tekom doktorske naloge natančneje predstavili

ontološko zasnovo našega zapisa načrtovalskih vzorcev. Ontologije

omogočajo na eni strani učinkovito uporabo znanja s strani samodejnih

orodij, na drugi strani pa pomagajo pri uporabi znanja v smislu brskanja

po njem.

V skupnosti se je pojavilo že nekaj uporabnih aplikacij, ki omogočajo

naprednejšo uporabo formalno predstavljenih načrtovalskih vzorcev.

Naslavljajo predvsem (Taibi, 2006):

• iskanje vzorcev v obstoječih rešitvah,


• samodejno generiranje izvorne kode rešitve na osnovi vzorcev in

• formalno validacijo rešitev, ki uporabljajo vzorce.

V tem seznamu zelo pogrešamo poizkuse reševanja že prej

predstavljenega problema: pomoč pri iskanju načrtovalskega vzorca v

določeni problemski situaciji. Menimo, da je, še pred pomočjo razvijalcu

pri uporabi določenega načrtovalskega vzorca, potrebno razvijalcem

omogočiti, da tak vzorec tudi relativno enostavno najdejo, skratka da

sploh ugotovijo, da rešitev njihovega trenutnega načrtovalskega

problema že naslavlja določen načrtovalski vzorec. Določeni avtorji so

sicer delno že naslovili problem iskanja vzorcev, vendar v praksi - razen

iskanja na osnovi ključnih besed – zadovoljivo delujočih rešitev v tem

trenutku še ne poznamo.

1.2.3 Raziskovalna vprašanja

Kot smo predstavili v prejšnjem poglavju, želimo v sklopu doktorske

naloge zapolniti vrzel med velikim številom načrtovalskih vzorcev in

relativno težavnem iskanju ustreznih načrtovalskih vzorcev za rešitev

danega načrtovalskega problema. Kot predpogoj za to v nalogi

predlagamo ustrezen način formalne predstavitve načrtovalskih vzorcev

in znanja o načrtovalskih vzorcih. Na tej osnovi predstavimo informacijsko

platformo, za katero verjamemo, da bo signifikantno izboljšala uporabo

načrtovalskih vzorcev. Predlagamo sistem, ki na osnovi znanja o vzorcih,

med drugim omogoča predlaganje ustreznega vzorca za rešitev

določene problemske situacije.

V okviru doktorske naloge bomo naslovili naslednji raziskovalni vprašanji:

Raziskovalno vprašanje Q1:

Ali sistem, ki omogoča predlaganje načrtovalskega vzorca za

podano problemsko situacijo, pospešuje uporabo ustreznih

načrtovalskih vzorcev?


Vsak načrtovalski problem je možno rešiti na mnogo načinov.

Prav tako si je možno pri tem pomagati z različnimi načrtovalskimi

vzorci, izmed katerih so nekateri za dano situacijo ustreznejši kot

drugi. Zanima nas torej, če sistem, ki omogoča razvijalcu

predlaganje ustreznega načrtovalskega vzorca, pomeni tudi, da

se razvijalec v danih situacijah več ne zateka k poznanim

vzorcem, temveč izbere ustreznega iz nabora, tudi njemu do

tedaj nepoznanih vzorcev.

Raziskovalno vprašanje Q2:

Ali formalna predstavitev načrtovalskih vzorcev na osnovi

ontologij in tehnologij semantičnega spleta omogoča učinkovito

zgradbo omenjenega sistema?

Prej opisan sistem nameravamo zgraditi s tehnološko naprednimi

rešitvami. Ontološki pristop naj bi omogočal relativno enostaven

razvoj inteligentnih rešitev, kakršno ponujamo tudi mi. Tehnologije

semantičnega spleta omogočajo takšen razvoj s praktičnega

vidika: s skladom specifikacij in tehnologij. Zanima nas torej, če

nam ontološka predstavitev načrtovalskih vzorcev omogoča

zgraditi želeno platformo.

Tekom doktorske naloge odgovorimo še na množico manjših

raziskovalnih vprašanj:

• Na kakšen način načrtovalski vzorci dvignejo stopnjo ponovne

uporabe?

• Čemu vse služijo vzorci?

• Ali predstavitev vzorcev vpliva na uporabnost tako

predstavljenega znanja?

• Katere predstavitve vzorcev obstajajo?

• Kateri formalni zapisi vzorcev obstajajo?

• Kakšne so aplikacije različnih predstavitev načrtovalskih vzorcev?


• Ali razvijalci sledijo ustaljenim postopkom pri uporabi načrtovalskih

vzorcev?

• Kakšne pristope uporabljamo pri iskanju vzorcev?

• Kako bi bilo možno izboljšati rezultate iskanja vzorcev?

• Kakšne bi bile možne aplikacije formalnih zapisov vzorcev, kakšne

že obstajajo?

• Ali in kako lahko pri uporabi vzorcev uporaba tehnologij

semantičnega spleta pomaga?

• Kako zelo so načrtovalski vzorci uporabljani?

• Kakšne algoritme bi bilo smiselno uporabiti pri predlaganju vzorca

v določeni problemski situaciji?

• Ali razvijalci sploh želijo uporabljati napredne storitve na osnovi


• Ali so razvijalci s ponujenimi storitvami zadovoljni?

• Ali in kako je mogoče lastno rešitev uporabiti v povezavi z

obstoječimi rešitvami (samodejno generiranje kode,

prepoznavanje vzorcev v rešitvah)?

1.2.4 Upoštevane predpostavke in omejitve

V doktorski nalogi se omejimo na načrtovalske vzorce objektne

orientacije. Brez škode za splošnost se ukvarjamo s formalizacijo in

uporabo vzorcev iz dveh katalogov: vzorci GoF (Gamma et. al., 1995) in

vzorci J2EE (Deepak, 2001).

V splošnem je formalizacijo vzorcev tako rekoč nemogoče doseči hkrati s

praktičnega kot tudi teoretičnega vidika (Zdun, 2007). Aspektov, ki jih je

mogoče formalizirati je namreč preveč (poglavje 3.2). V splošnem je

področje rešitev neskončno in kot takšno ni primerno za oblike

raziskovanja, kot jih predlagamo tukaj. Glede na to, da se omejimo na

načrtovalske vzorce objektne orientacije, je aspektov formalizacije

bistveno manj in zajemajo le koncepte objektne orientacije, povezave


med vzorci in dodatno ekspertno znanje o vzorcih (npr. znani primeri

uporabe).

Kljub temu, da se v doktorski nalogi ukvarjamo tudi z ustreznim

algoritmom za izbiro načrtovalskih vzorcev, naj opozorimo, da ne

poizkušamo poiskati najoptimalnejšega algoritma. Naš cilj je poiskati

algoritem, ki omogoča voden dialog med razvijalcem in sistemom, in ne

zahteva bistvenih intervencij ekspertov ter na tak način potencialno

izboljša uporabo ustreznih vzorcev. Razvoj algoritma, ki bi omogočal

dosego tega na najoptimalnejši možen način, prepuščamo morebitnim

kasnejšim raziskavam. Kljub temu v doktorski nalogi predstavimo več

možnih algoritmov, pri čemer v fazi eksperimenta uporabimo tistega, ki

se izkaže za najučinkovitejšega.

Prav tako se tekom doktorske naloge ne ukvarjamo s sociološkimi vidiki

uporabe načrtovalskih vzorcev. Ocenjujemo, da obstaja možnost, da

predvsem izkušenejši razvijalci našega sistema ne bi uporabili kljub temu,

da uspemo dokazati njegovo veliko korist. Predvsem izkušeni arhitekti in

razvijalci programske opreme utegnejo namreč čutiti prisotnost takšnega

sistema kot faktorja, ki utegne zmanjšati njihovo visoko kreativnost. Da bi

zmanjšali to možnost smo v sistem vgradili tudi mehanizme, ki omogočajo

uporabo načrtovalskih vzorcev na tradicionalen način (iskanje na osnovi

ključnih besed, prosto brskanje po repozitoriju vzorcev ipd.). Ocenjujemo,

da na drugi strani neizkušeni razvijalci takšnega negativnega pritiska

novega orodja ne bodo čutili. Zato predpostavljamo, da bo naš sistem

najbolje služil predvsem neizkušenim razvijalcem, ki imajo slabše znanje s

področja načrtovalskih vzorcev.


2. Cilji raziskave

2.1 Teza raziskave

V okviru doktorskega dela poizkušamo potrditi ali ovreči naslednji

hipotezi:

Hipoteza H1:

Sistem, ki omogoča predlaganje vzorca za podano problemsko

situacijo, pospešuje uporabo ustreznih načrtovalskih vzorcev.

Hipoteza H2:

Formalna predstavitev načrtovalskih vzorcev na osnovi ontologij

in tehnologij semantičnega spleta, omogoča učinkovito zgradbo

sistema, omenjenega v hipotezi H1.

Sistem, o katerem govorimo v hipotezah je sestavljen tako iz

metodologije uporabe načrtovalskih vzorcev kot tudi programske

opreme, ki to omogoča. Da bi omogočili čim enostavnejšo uporabo

sistema, predstavljena metodologija ni zastavljena bistveno drugače od

te, ki jo razvijalci že uporabljajo v povezavi z načrtovalskimi vzorci.

Predvsem želimo formalizirati utečen način uporabe načrtovalskih

vzorcev (Gamma et. al., 1995). Da bi zgradili sistem, ki omogoča

predlaganje ustreznih načrtovalskih vzorcev, se ne moremo izogniti


prisotnosti strokovnjakov s tega področja. V sam sistem jih želimo vključiti

na minimalen možen način, saj menimo, da bi le-ta v nasprotnem

primeru izgubil na uporabnosti.

2.2 Izvirni znanstveni prispevki disertacije

2.2.1 Pregled formalnih metod predstavitve načrtovalskih vzorcev

V okviru doktorske naloge na enem mestu zberemo in primerjamo

najpomembnejše formalne metode predstavitve načrtovalskih vzorcev.

Na tak način omogočimo pregled stanja formalnih predstavitev

načrtovalskih vzorcev in njihovih aplikacij.

2.2.2 Lastna formalna predstavitev vzorcev in znanja o vzorcih

Na osnovi študije obstoječih formalnih predstavitev, študije ontologij in

semantičnega spleta, predstavimo lastno predstavitev načrtovalskih

vzorcev in znanja o načrtovalskih vzorcih. Opišemo tudi, kako je mogoče

lastno predstavitev uporabiti v povezavi z že obstoječimi. Na takšen

način je lastno predstavitev mogoče razumeti kot razširitev, ki je nujna,

če želimo omogočiti lažje iskanje in uporabo načrtovalskih vzorcev.

Takšnim razširitvam poiščemo ustrezno konceptualno in tehnološko

rešitev v ontologijah in tehnologijah semantičnega spleta.

2.2.3 Algoritem predlaganja vzorca

Poiskali in realizirali smo tudi ustrezen algoritem predlaganja vzorca na

osnovi vodenega dialoga. Sistem na podlagi podajanja odgovorov

vprašanjem, ki jih zastavi sistem razvijalcu, poizkuša najti ustrezne

načrtovalske vzorce. Poiskati smo uspeli inovativen algoritem, ki je

sposoben izbire zaporedja zelo majhnega števila vprašanj, da pridobi,

kolikor je mogoče, veliko informacij o razvijalčevih potrebah.


2.2.4 Krovna metodologija

V okviru doktorske naloge predstavimo krovno metodologijo, ki zajema

opisovanje načrtovalskih vzorcev, vstavljanje ekspertnega znanja o

vzorcih in uporabo znanja, z namenom iskanja vzorcev za določeno

problemsko situacijo.

2.2.5 Informacijska platforma z inteligentnimi rešitvami

V okviru doktorske naloge je nastala platforma – prototipna rešitev, ki v

celoti podpre predstavljeno metodologijo. Omogoča napredno

uporabo načrtovalskih vzorcev tako s strani inteligentnih agentov kot tudi

razvijalcev.

2.3 Uporabljene metode znanstvenega raziskovanja

Med delom na temi doktorske naloge smo se poslužili različnih metod

znanstvenega raziskovanja. V fazi snovanja sistema smo izvedli predvsem

pregled literature in študijo primera.

S pregledom literature smo ugotovili stanje uporabe načrtovalskih

vzorcev in možnosti, ki iz tega izhajajo. Pregledali smo vse

najpomembnejše obstoječe formalne predstavitve načrtovalskih vzorcev

in jih medsebojno primerjali. Prav tako smo na osnovi pregleda literature

ugotovili, kakšni poizkusi so poznani pri iskanju ustreznih načrtovalskih

vzorcev.

Na osnovi tako pridobljenega znanja smo se odločili za uporabo in

nadgraditev ene izmed predstavitev vzorcev, z namenom lažjega

iskanja vzorcev. Pripravili smo metodologijo in prototipno implementacijo

predlaganega zapisa vzorcev v obliki repozitorija načrtovalskih vzorcev.

V nalogi najprej predstavimo uporabo metodologije in prototipnega

orodja s pomočjo študije primera.


V fazi testne uporabe sistema smo se poslužili empirične raziskave in

ankete. Merili smo učinkovitost reševanja problemov pred in po uvedbi

našega sistema. Atributi učinkovitosti, ki smo jih merili so naslednji:

• pravilnost reševanja problemov,

• hitrost reševanja problemov in

• zadovoljstvo ob uporabi orodij.

Slika 2: Vloga vzorcev pri reševanju načrtovalskih problemov

V eksperimentalnem delu raziskave smo merili učinkovitost uporabe

repozitorija načrtovalskih vzorcev. Kot je predstavljeno na sliki 2, smo se

omejili na povezavo med problemom in rešitvijo. Uspešnost uporabe

načrtovalskih vzorcev smo merili posredno: za dani problem je bila

naloga razvijalca podati načrtovalski vzorec, ki bi ga pri reševanju

problema bilo smiselno uporabiti. Ob boljšem odgovarjanju, zgolj s

spremenjenim repozitorijem vzorcev (neodvisna spremenljivka), je

smiselno sklepati, da je sprememba posledica drugačnega sistema

iskanja vzorcev.

Razvijalci so se z načrtovalskimi problemi ukvarjali individualno v

nadzorovanem okolju. Eksperiment je potekal v treh fazah:

• Najprej so se razvijalci ukvarjali z iskanjem rešitve brez možnosti

uporabe katalogov načrtovalskih vzorcev.


• V fazi 2 so imeli možnost uporabe tiskanih katalogov vzorcev in

infrastrukture iskanja po celotnem besedilu s pomočjo ključnih

besed (Google in lasten sistem).

• V fazi 3 so razvijalci dobili na voljo razvit sistem. V tej fazi so razvijalci

podali rešitev, ki se jim je osebno zdela pravilna, vključevala pa je

lastno presojo, rezultate pridobljene z iskanjem po besedilu in

rezultate, pridobljene z vodenim dialogom.

Merili smo pravilnost in hitrost odgovorov. S pomočjo statističnih metod

smo ugotovili, ali obstaja med fazami signifikantno razlikovanje v

pravilnosti in hitrosti odgovorov. S pomočjo ankete smo merili tudi

zadovoljstvo razvijalcev pri uporabi našega sistema. Ker so kandidati v

vseh treh fazah reševali iste naloge, smo poskrbeli, da le-ti med fazami

niso komunicirali. Prav tako smo uvedli kontrolne skupine, katerih člani so

se nalog lotili s samo eno izmed faz (s pomočjo našega sistema).

Udeleženci eksperimenta so sodelovali tudi v dveh anketah. Anketa

pred eksperimentom je podala odgovore o njihovih izkušnjah. Na tak

način smo lahko ločili bolj izkušene razvijalce od tistih, ki imajo manj

izkušenj. Na podlagi tega smo lahko podali dodaten sklep, katera

skupina, če katera, ima največ koristi od našega sistema.

Udeleženci so tudi po eksperimentu sodelovali v anketi, ki je zajela

podatke o zadovoljstvu uporabnikov ob uporabi našega sistema.

Na tak način smo dobili celotno sliko: morebitno razliko, ki jo opazimo pri

pravilnosti, hitrosti in zadovoljstvu razvijalcev ob uporabi našega sistema.

Tako smo tudi ugotovili, ali obstajajo razlike med bolj in manj izkušenimi

razvijalci ob uporabi našega sistema.

V eksperimentu so sodelovali študentje višjih letnikov univerzitetnih

programov računalništvo in informatika ter informatika in tehnologije

komuniciranja ter razvijalci iz partnerskih podjetij.


3. Sorodna dela

3.1 Ponovna uporaba in načrtovalski vzorci

Kot smo predstavili v uvodnem poglavju, obstajajo mehanizmi, ki

zagotavljajo učinkovito ponovno uporabo na višjih nivojih abstrakcije.

Avtorji raziskav (Manolescu, 2007) ugotavljajo, da ponovna uporaba žal

še vedno ni pristop, ki bi bil na področju programskega inženirstva dovolj

dobro izkoriščen. Raziskovalci smo si edini, da področje ponuja še mnogo

priložnosti za izboljšave.

Kot navedeno v uvodnem poglavju, poznamo na najvišji stopnji

abstrakcije ponovno uporabo idej v obliki vzorcev. Vzorci že danes

predstavljajo uveljavljen mehanizem za doseganje ponovne uporabe v

programskem inženirstvu. V doktorski nalogi se omejimo na načrtovalske

vzorce, ki jih tudi imenujemo kar vzorci. Načrtovalski vzorci so tudi sicer

najširše zastopana in uporabljena družina vzorcev v programskem

inženirstvu.

Koncept vzorcev izhaja iz gradbeništva in arhitekture. Ideja o ponovni

uporabi na osnovi vzorcev se je prvič porodila arhitektu in profesorju

Christopherju Alexandru (Alexander, 1977). Podrobneje jo je opisal v

knjigi »A Pattern Language: Towns, Buildings, Construction« (Alexander,

1977). Opazil je, da določena mesta, zgradbe in ostale arhitekturne

prvine izražajo veliko večjo skladnost, estetiko in privlačnost kot druge ter

da imajo skupne imenovalce, ne glede na to, ali so bile zgrajene v

srednjem veku, prej ali morda v novejši dobi.


Razlog temu, tako meni Alexander, naj bi se skrival v gradnji po predpisih,

ki so arhitektom dopuščali tudi nekoliko svobode, da so zgradbe

prilagajali specifičnim potrebam. Na osnovi opazovanj tradicionalne

arhitekture je identificiral in opisal 253 vzorcev (Alexander, 1977). V knjigi

je Alexander podal tudi svojo idejo načrtovalskega vzorca:

»Vzorec opisuje problem, ki ga v okolju srečujemo znova in znova, ter jedro

rešitve tega problema na takšen način, da jo lahko uporabimo milijon krat, ne

da bi jo dvakrat uporabili na enak način.«

(Alexander, 1977)

Vzorec Alexander definira kot konstrukt, sestavljen iz treh elementov:

kontekst, zbirka silnic (angl. forces) in rešitev. Kontekst odseva okoliščine,

v katerih vzorec uporabimo. Silnice se v okoliščinah pojavljajo vedno

znova in kot takšne predstavljajo problem, ki ga želimo rešiti. To pa

dosežemo s pomočjo tretjega elementa, rešitve, ki silnice izniči. Med

vzorci najdemo na primer vzorec »čakalnica« (»a place to wait«), ki

opisuje jedro rešitve za npr. avtobusno postajo, čakalnico pri

zobozdravniku, sobo, kjer pacienti čakajo na operacijo ipd., na takšen

način, da daje primerna arhitekturna izhodišča za načrtovanje takšnih

prostorov. Vzorec »delovna skupnost« (angl. work community) npr. na

predpostavki, da na delovnem mestu preživimo enako ali več časa kot

doma, daje arhitekturna izhodišča za delovno mesto, kjer se bomo

počutili prijetno kot doma, ne glede na to ali gre za prostor za delovnim

trakom, pisarno, gradbišče ali kaj drugega. Realizacija vzorca v realnem

svetu je torej pogojena s kontekstom, v katerem je vzorec uporabljen.

Vzorec naj bo takšen, da ni preveč kontekstno odvisen, hkrati pa naj da

dovolj smernic za rešitve v vseh kontekstih, ki jih pokriva.

Že Alexander je vzorce delil tudi glede na stopnjo uporabe v realnem

svetu. Pravi vzorci so le tisti, ki so že bili prepoznani v uporabi, medtem ko

med prave vzorce ne štejemo tistih, ki bi potencialno lahko bili uporabni,

njihove realne uporabe pa še ni zaslediti.


Vzorci so medsebojno povezani z relacijami kot so sorodni vzorec,

alternativa ipd. Alexander je zbirko povezanih vzorcev imenoval jezik

vzorcev (angl. pattern language), saj je vzorce pojmoval kot besednjak

konceptov pri komunikaciji med izkušenimi arhitekti in novinci (Alexander,

1977). Čeprav je tudi v programskem inženirstvu ta pomen vzorcev

ohranjen, pa njihove zbirke imenujemo »katalogi vzorcev« (npr. Gamma

et. al., 1995).

Alexandrovo delo je imelo velik vpliv na programsko inženirstvo. Leta

1987 sta Kent Beck in Ward Cunningham na konferencei OOPSLA

predstavila svoje poizkuse uporabe načrtovalskih vzorcev na področju

programskega inženirstva (Beck et.al., 1987). Nad rezultati poizkusov sta

Cunningham in Beck bila pozitivno presenečena in sta kot takšna

vplivala na nekatere druge računalniške strokovnjake kot sta Erich

Gamma in Richard Helm. Gamma in Helm sta se ukvarjala s problemom

ponavljajočih se načrtovalnih struktur pri razvoju informacijskih rešitev.

Kasneje se je okoli njiju oblikovala skupina, imenovana tudi »Gang of

Four« (GoF – Gamma, Helm, Johnson, Vlissides), ki se je osredotočila na

identifikacijo načrtovalskih vzorcev. Gotovo je njihov katalog vzorcev

(Gamma et. al., 1995), ki je izšel leta 1995, dal največ zagona uporabi

načrtovalskih vzorcev na področju programskega inženirstva.

Načrtovalski vzorci s kataloga GoF podajajo rešitve v objektni orientaciji,

ki je danes vodilna paradigma razvoja informacijskih rešitev. Tudi tekom

raziskave smo so omejili le na vzorce objektne orientacije.

3.2 Formalni zapisi načrtovalskih vzorcev in njihove aplikacije

Kot je že bilo razloženo (poglavje »1.2.1 Ponovna uporaba in načrtovalski

vzorci«), so se načrtovalski vzorci na področju programskega inženirstva

pojavili predvsem v povezavi z objektno orientacijo. Za preboj štejemo

katalog vzorcev GoF (Gamma et. al., 1995), ki je hkrati tudi postavil de-

facto standarde za opisovanje načrtovalskih vzorcev v programskem


inženirstvu. Ker je katalog pisan v obliki knjige in je kot takšen namenjen

razvijalcem (to pomeni, da ni primeren za neposredno strojno obdelavo),

je temu prilagojena tudi metoda notacije vzorcev. Vzorci so predstavljeni

v obliki semiformalnih in neformalnih metod. Tako so avtorji vzorce opisali

s kanonično formo, OTN diagrami, primeri uporabe in z razpravo. Takšno

obliko so povzeli tudi drugi avtorji, npr. (Deepak, 2001). Poleg

semiformalnih in neformalnih metod se je kasneje v skupnosti oblikovalo

tudi nekaj metod za formalno predstavitev načrtovalskih vzorcev, ki se

jim bomo podrobneje posvetili v naslednjem poglavju.

Katalog GoF (Gamma et. al., 1995) opiše vzorce s pomočjo grafične

notacije OTN in po sledeči formi:

• naziv vzorca,

• druga imena vzorca,

• namen vzorca,

• uporabnost vzorca,

• struktura vzorca,

• elementi vzorca,

• sodelujoči elementi pri uporabi vzorca,

• posledice uporabe vzorca,

• način implementacije vzorca,

• primer implementacije,

• do sedaj znani primeri uporabe in

• znani sorodni vzorci.

Poleg takšnega neformalnega, delno strukturiranega opisa načrtovalskih

vzorcev, danes srečamo tudi formalnejše oblike opisa. Večina

semiformalnih zapisov temelji na jeziku UML. Zadostujejo za osnovno

razumevanje strukture in obnašanja vzorcev, ne ponujajo pa informacij o

namenu, načinu uporabe in posledicah uporabe vzorca. Prav tako

tipično ne ponujajo informacij o sestavljanju vzorcev v kompleksnejše


strukture, kar je eden temeljev uporabe načrtovalskih vzorcev z vidika

jezika vzorcev.

Obstoječi neformalni opisi vzorcev ponujajo predvsem enostavno

berljivost in hitro seznanitev z jedrom vzorca in njegovo uporabo.

Kakorkoli že, takšna predstavitev lahko prinese tudi določene dvoumnosti

in nejasnosti ter tudi na takšen način vodi k napačni uporabi vzorcev.

Neformalne predstavitve prav tako onemogočajo uporabo katalogov

vzorcev v orodjih. Z namenom lažjega iskanja načrtovalskih vzorcev je

torej potrebno uporabiti ustrezno formalnejšo obliko predstavitve

vzorcev, saj si izboljšanja iskanja ne znamo predstavljati brez pomoči

orodij, ki so sposobna uporabiti znanje, zapisano v katalogih vzorcev.

Določene formalne metode predstavitve načrtovalskih vzorcev že

obstajajo (Taibi, 2006) in omogočajo tudi naprednejše metode

samodejnega sklepanja na tako predstavljenih podatkih.

Katalogi tipično opišejo načrtovalske vzorce kot kombinacijo

tekstualnega in grafičnega opisa ter primerov uporabe. Kot smo že

ugotovili, je namen tega enostavna uporaba vzorca z vidika razvijalca

informacijske rešitve. Izkazalo se je, da bi za učinkovito uporabo vzorcev

bilo nujno uporabiti določena orodja (Taibi, 2006). Za to bi bilo nujno

predstaviti načrtovalske vzorce v formalni obliki, primerni za samodejno

obdelavo. Formalne oblike predstavitev načrtovalskih vzorcev

potrebujemo predvsem zaradi (Taibi, 2006):

• Omogočiti želimo boljše razumevanje vzorcev in njihove

kompozicije. S tem dosežemo boljše poznavanje situacije, v kateri

lahko učinkovito uporabimo določen vzorec.

• Učinkovito želimo voditi povezave med vzorci v smislu alternativ,

različic in izključujočih vzorcev.

• Omogočiti želimo podporo orodij v aktivnostih, povezanih z vzorci.

Trenutno na področju formalne predstavitve načrtovalskih vzorcev še ni

konsolidacije. Zato bomo na kratko pregledali najpomembnejše


obstoječe metode formalnih predstavitev načrtovalskih vzorcev ter jih

poizkušali primerjati in ovrednotiti primernost za uporabo v lastni raziskavi.

Različni avtorji poizkušajo formalizirati predvsem naslednje vidike

načrtovalskih vzorcev(Taibi 2006):

• strukturo vzorca (npr. razredi, povezave, atributi, metode),

• obnašanje vzorca (npr. zaporedje klicanja metod),

• način implementacije vzorcev,

• kontekst vzorca,

• verificiranje vzorca in njegove implementacije ter

• kompozicijo vzorca in njegovih implementacij.

3.2.1 Jezik DPML

Avtorji članka »A Visual Language for Design Pattern Modeling and

Instantiation« (Maplesden, 2007) opišejo jezik za grafičen opis

načrtovalskih vzorcev – »Design pattern modeling language« (DPML).

Jezik omogoča opis rešitev določenega načrtovalskega vzorca ter opis

realizacije načrtovalskega vzorca v jezik UML. Avtorji predstavijo tudi

obstoječa orodja, ki delajo s tem opisom načrtovalskih vzorcev ter

rezultate eksperimenta, katerega namen je bil preveriti uporabnost

predlaganega pristopa.

DPML je možno uporabiti samostojno, pri čemer omogoča opisovanje

načrtovalskih vzorcev. Če ga uporabimo skupaj z jezikom UML pa

omogoča še opisovanje realizacije posameznega vzorca. Avtorji so pri

definiciji svojega jezika zasledovali predvsem naslednje cilje:

• definirati razširitve jezika UML, ki bi omogočale enostaven opis

vzorcev,

• definirati standarden jezik za opis načrtovalskih vzorcev, ki bo

predvsem enostaven, a kljub temu dovolj močen, in s tem

omogočiti enostavno izmenjavo vzorcev,


• definirati jezik, ki bi bil blizu razvijalcem in kot tak ne bi vseboval

kompleksnih matematičnih formalizmov in

• definirati jezik, ki bi ga bilo enostavno uporabiti v orodjih.

Avtorji so se osredotočili predvsem na strukturne specifikacije

načrtovalskih vzorcev. Uporabljena notacija in primer uporabe jezika

DPML sta predstavljena na slikah 3 in 4.

Slika 3: Gradniki jezika DPML (Maplesden, 2007)

Slika 4: Primer uporabe DPML za definiranje vzorca abstraktna tovarna (Maplesden, 2007)


DPML se uporablja za specificiranje strukture vzorca, medtem ko se za

specifikacijo obnašanja vzorca predvideva uporaba standardnih UML

diagramov: diagram zaporedja ali diagram sodelovanja.

DPML predvideva tudi razširitve v smislu diagramov ustvarjanja objektov

(angl. instantiation diagrams). V ta namen so uvedeni dodatni grafični

elementi in metamodel (sliki 5 in 6).

Slika 5: Elementi za prikaz ustvarjanja objektov (Maplesden, 2007)

Slika 6: Primer ustvarjanja objektov za konkretno abstraktno tovarno (Maplesden, 2007)


Avtorji so pripravili tudi prototipna orodja, ki omogočajo praktično

uporabo jezika DPML. Orodja omogočajo:

• opis vzorcev v jeziku DPML,

• zagotavljanje integritete diagramov,

• ustvarjanje konkretnih UML rešitev na podlagi tako zapisanih

vzorcev in

• upravljanje z diagrami (uvoz, izvoz, hranjenje ipd.).

Avtorji so s pomočjo predstavljenih orodij izvedli tudi empirično raziskavo.

Z njo so želeli ugotoviti, ali je njihov pristop učinkovit. Ugotovili so, da je

ločitev vzorcev, njihovih primerkov in objektnih modelov med razvijalci

bila dobro sprejeta, k čemer je v veliki meri botrovalo tudi kakovostno

orodje. Zaznali so določene slabosti v razumevanju diagramov. Sicer so

ugotovili, da je njihova notacija med razvijalci sprejeta bolje kot

konkurenčna LePUS (Gasparis, 2007). Podpore lažji izbiri ustreznega

vzorca za podano problemsko situacijo avtorji ne omenjajo.

3.2.2 Jezik RSL

Avtorji v članku »A Generic Model of Object-Oriented Patterns Specified

in RSL« (Flores, 2007) predstavijo formalen zapis vzorcev GoF na osnovi

jezika RAISE (rigorous approach to industrial software engineering) – RSL

(RAISE Specification Language). Formalizacije vzorcev so se lotili z

namenom omogočiti enostavno uporabo orodij za delo z načrtovalskimi

vzorci. Pri tem so se orientirali predvsem na modeliranje in verifikacijo

razvitih informacijskih rešitev. Svoj pristop so podprli tudi s prototipno

implementacijo podpornega orodja. Predstavljeno prototipno orodje

med drugim omogoča, preverjanje pravilne uporabe vzorcev in

preverjanje uporabe pravilnih vzorcev.

Notacija, ki omogoča predstavitev tako strukture kot tudi dinamičnega

dela vzorcev nima grafične različice. Omogoča zapis tipov, razredov,

metod, internih in zunanjih relacij. Podrobnejšo definicijo posameznih


gradnikov lahko najdemo v (Flores, 2007). Zasnova jezika je preprosta,

sama uporaba pa relativno kompleksna in terja poglobljeno študijo, z

namenom, da uporabnik ugotovi kaj notacija predstavlja. Kakorkoli že,

avtorji ugotavljajo, da se je notacija izkazala za zelo uporabno v

prototipnem orodju, s pomočjo katerega so izvedli študijo primera.

Izdelali so rešitev za podporo preprostega poslovanja izposojevalnice

knjig in filmov.

Na podlagi študije primera se je notacija RSL pri samodejni verifikaciji

informacijskih rešitev, sestavljenih s pomočjo vzorcev, izkazala za zelo

uporabno. Podporno orodje namreč omogoča tudi načrtovanje rešitev

in njihovo kasnejšo verifikacijo glede na vzorce, zapisane v RSL. Tudi v

tem delu ne zasledimo, da bi avtorji izkoristili potencial formalne

predstavitve vzorcev z namenom lažjega iskanja vzorcev.

3.2.3 Jezik OCSID

Avtorji v članku »Patterns of Collective Behavior in Ocsid« (Helin, 2007)

predstavijo formalno notacijo, ki temelji na posebni podvrsti logike, ki

upošteva veljavno časovno obdobje dejstev (Temporal Logic). Jezik

opisuje spreminjanje sistema, ki ga povzroča uporaba vzorca, torej se

osredotoči predvsem na opis obnašanja. Opis strukture vzorca prepusti

notaciji UML. Pri opisu obnašanja se avtorji omejijo na zaključen svet

(angl. Closed World Principle).

Notacija je strogo matematična in ne predvideva grafične različice. Prav

tako ni bila preizkušena – v članku so avtorji uspeli opisati le GoF

(Gamma et. al., 1995) vzorca »opazovalec« (»observer«) in »spomin«

(»memento«). Notacija avtorjem služi predvsem kot orodje razprave,

kakšne bi utegnile biti posledice uporabe popolnoma formalno opisanih

vzorcev.


3.2.4 Jezik Spine

Jezik »Spine« predstavijo avtorji v članku »Spine: Language for Pattern

Verification« (Blewitt, 2007). Jezik je namenjen opisu vzorcev, tako, da bi

bilo čim enostavneje odkriti vzorec v obstoječi kodi in preveriti pravilnost

implementacije. Pri tem se avtorji niti ne omejujejo na programski jezik niti

ne na poimenovanje razredov, metod ali atributov, kot to zahteva

katalog vzorcev. Jezik temelji na prologu. Omogoča zapis strukture

vzorca, problematike predstavitve dinamične slike vzorca ne naslavlja.

Spine opiše razrede, ki nastopajo v vzorcu in z njimi povezane omejitve. S

pomočjo pogona za dokazovanje v prologu (HedgeHog) je tako

omogočeno iskanje vzorcev v obstoječih rešitvah in iskanje morebitnih

napak pri implementaciji vzorca. Potenciala izbire ustreznega vzorca na

osnovi te predstavitve avtorji ne omenjajo.

3.2.5 Jezik SPQR

Jezik SPQR (Smith, 2007) temelji na ς-Calculusu. Le ta se pogosto

uporablja kot formalna osnova objektne orientacije. Avtorji izhajajo iz

študije primera (KillerWidget), kjer svoj jezik »The system for pattern query

and recognition« (SPQR) tudi uporabijo.

Jezik uporablja le stroge matematične predpise uporabljene algebre,

vendar le v tistih delih vzorcev, ki so relevantni pri prepoznavanju

vzorcev. Tako jezik omogoča zapis statične strukture objektov, metod,

atributov in tipov. Dalje od študije primera avtorji niso razvijali svojega

pristopa.

3.2.6 ObjectCalculus

Avtorji članka »Formalising Design Patterns as Model Transformations«

(Lano, 2007) izhajajo iz ugotovitve, da notacija UML v povezavi z jezikom

omejitev OCL v celoti zadostuje za formalen zapis vzorcev. Na tej osnovi


avtorji uporabijo objektno algebro, ki vzorce opiše kot kombinacijo

transformacij, ki jih vzorec povzroči v strukturi sistema (Lano, 2007):

• vpeljava sosednjega razreda,

• vpeljava vmesnega razreda v povezavo,

• vpeljava vmesne generalizacije v povezavo med razredoma in

• zamenjava eksplicitno pogojnega obnašanja s polimorfizmom.

V članku avtorji razvrstijo in opišejo vzorce kataloga GoF (Gamma et. al.,

1995), nadalje pristopa ne razvijajo.

3.2.7 Jezik RBML

»The Role-Based Metamodeling Language for Specifying Design

Patterns« (RBML) (Dae-Kyoo, 2007) temelji na notaciji UML. Pozna tako

grafično kot tudi tekstovno predstavitev.

Razlogi in prednosti uvedbe jezika RBML vključujejo (Dae-Kyoo, 2007):

• podporo načrtovalskim vzorcev na nivoju modela,

• opis različnih vidikov načrtovalskih vzorcev,

• razširljivost (temelji na jeziku UML),

• jezik je preprost in natančen,

• jezik je podprt z orodjem.


Slika 7: Jedro jezika RBML

Avtorji so s pomočjo jezika opisali GoF (Gamma et. al., 1995) vzorce

»opazovalec« (»observer«), »interpreter« in »iterator«. Podrobneje so

opisali orodje, ki omogoča modeliranje v notaciji UML in ponuja različne

diagramske tehnike za opis različnih vidikov načrtovalskih vzorcev. Tudi v

primeru tega zapisa avtorji niso razvili naprednejših funkcionalnosti

svojega pristopa.

3.2.8 Jezik SlamSL

Slam-SL (Herranz, 2007) je jezik, ki omogoča zapis načrtovalskih vzorcev

na takšen način, da lahko nad njimi izvajamo sklepanje. Grafičnega

zapisa jezika avtorji niso predvideli.

Avtorji so v algebro razredov uvedli lasten operator, na osnovi katerega

zapišemo načrtovalski vzorec v smislu predpogojev in popogojev.

Predpogoji opisujejo zahteve razreda za apliciranje vzorca, medtem ko

popogoji opisujejo stanje razreda po apliciranju vzorca.

Avtorji so pripravili tudi prototipno orodje, ki so ga uporabili na študiji

primera. Pokažejo, kako uporabiti notacijo pri apliciranju vzorca.


3.2.9 Ontološki opis načrtovalskih vzorcev z ontologijo ODOL

Avtorji ontologije ODOL (Dietrich et. al., 2007) so predstavili poizkus zapisa

načrtovalskih vzorcev, s pomočjo tehnologij semantičnega spleta.

Ontologijo so zato razvili v jeziku OWL, standardnem jeziku za zapis

ontologij semantičnega spleta. Takšen pristop nudi avtorjem široko

paleto pozitivnih posledic, kot je npr. enostavna dostopnost do opisov

vzorcev, enostavna izmenjava vzorcev, standardiziran jezik in posledično

široka podpora orodij. Poleg ontologije avtorji predstavijo tudi način

implementacije vzorca in orodje, ki omogoča pregled že razvitih rešitev

in iskanje vzorcev v njih.

Ontologija kot takšna je orientirana v samodejno generiranje kode na

osnovi uporabljenih vzorcev in na iskanje vzorcev v obstoječi kodi. Kot

takšna vključuje predvsem podatke o razredih, metodah in atributih,

skratka statični sliki vzorca. Avtorji so na takšen način opisali nekaj

vzorcev kataloga GoF (Gamma et. al., 1995). Orodje omogoča zapis

vzorcev neposredno v jeziku RDF (standarden jezik za zapis dejstev iz

sklada tehnologij semantičnega spleta) ali v grafični različici.

Slika 8: Hierarhija razredov ontologije ODOL


Slika 9: Razredi za opis lastnosti razredov vzorca

Slika 10: Opis abstraktne tovarne v ODOL-u


Avtorji sicer niso predvideli dodatne uporabe svoje formalne

predstavitve vzorcev, razen iskanja vzorcev v obstoječih rešitvah in

apliciranja vzorcev med razvojem, so pa nakazali možnosti povezovanja

s strani drugih rešitev, ki temeljijo na pristopih semantičnega spleta.

3.2.10 Jezik URN

Zanimiv način predstavitve načrtovalskih vzorcev so predstavili avtorji

(MussBacher, 2007) z jezikom URN (User Requirements Notation). Jezik

izhaja iz telekomunikacijskega okolja. Omogoča formalen zapis strukture,

obnašanja in ciljev programske opreme. Sestoji iz dveh sicer ločenih

jezikov: GRL (Goal-oriented Requirement Language) in UCM (Use Case

Map).

Jezik ima grafično predstavitev, kljub temu pa avtorji niso predvideli

uporabe orodja.

Avtorji opis jezika zaključijo s študijo primera, kjer na praktičnem primeru

prikažejo uporabo jezika.

3.2.11 Prevajalnik PEC

Povsem praktičen vidik predstavitve načrtovalskih vzorcev opišejo avtorji

članka »A Pattern Enforcing Compiler (PEC) for Java: A Practical Way to

Formally Specify Patterns« (Lovatt, 2007).

Avtorji so formalno opisali vzorce neposredno v programskem jeziku

Java, kjer jih je možno tudi neposredno uporabiti. Prevajalnik PEC tik pred

prevajanjem dopolni kodo do te mere, da na označene razrede aplicira

vzorce. Sposoben je tudi preverjanja pravilne uporabe vzorcev.

Avtorji v članku prikažejo jezik, funkcionalnosti prevajalnika in navržejo

primere, kako ga je možno uporabiti v lastnih projektih.


3.2.12 Jezik LePUS

LePUS(Gasparis, 2007) je široko zastopan formalni jezik za opis

načrtovalskih vzorcev. Temu gotovo botruje dejstvo, da izhaja iz logike

prvega reda ter da pozna tako tekstovno kot tudi enostavno grafično

predstavitev. Na spletu obstaja celoten repozitorij vzorcev GoF (Gamma

et. al., 1995), opisanih z jezikom LePUS, kar daje veliko možnosti uporabe

tega jezika. Tako obstaja že kar nekaj orodij, ki omogočajo sklepanje nad

tako predstavljenimi vzorci, mnoga pa so, po trditvah avtorjev(Gasparis,

2007), še v delu. Grafična predstavitev jezika je relativno preprosta, a

hkrati dovolj močna za zapis načrtovalskih vzorcev (slika 11).

Na osnovi jezika LePUS je mogoče enostavno iskati vzorce, saj obstaja

spletni repozitorij. Avtorji žal niso predvideli naprednejših metod iskanja

primernih vzorcev.


Slika 11: Elementi jezika LePUS

3.2.13 Jeziki časovne logike, logike prvega reda, Prolog in BPSL

Avtorji (Helin, 2007) primerjajo kar nekaj možnih formalnih predstavitev

načrtovalskih vzorcev, pri čemer posebej obravnavajo zapis strukture in

obnašanja vzorca. Za opis statične slike vzorca predlagajo predvsem

logiko prvega reda in Prolog. Za opis dinamične slike pa posebno

podvrsto logike, ki vključuje tudi časovno komponento – TLA (Temporal

Logic of Actions).

Do podobnih zaključkov pridejo tudi avtorji (Taibi, 2006), ki predstavijo

svoj jezik BPSL (»Balanced Pattern Specification Language«), ki združuje

logiko prvega reda za opis strukture in TLA za opis obnašanja vzorcev.

Avtorji so predvideli aplikacije predvsem v smislu sklepanja nad vzorci. Žal


pa svojega dela niso potrdili niti s študijo primera niti z opisi praktičnih

uporab.

3.2.14 Primerjava jezikov za formalen zapis načrtovalskih vzorcev

V tabeli 1 primerjamo predstavljene metode formalnih predstavitev

načrtovalskih vzorcev.

Tabela 1: Primerjava predstavljenih formalnih metod Jezik Predstavitev vzorca Obstaja orodje? Opiše statično

sliko? Opiše

dinamično sliko?

Način potrditve

jezika

Namen (poleg formalizacije)

Graf. Tekst. Mat.

DPML (gen. kode)

(UML)

Empirična raziskava

MDA

RSL (modeliranje, verifikacija)

Študija primera

Modeliranje, formalna verifikacija rešitev

OCSID (UML)

(TLA+closed

world)

Opisati spremembe sistema

SPINE (HedgeHog –

iskanje vz. in nap.)

(Prolog: razredi

in omejitve)

Odkrivanje vzorcev in verifikacija

SPQR (ρ-calculus)

Študija primera

Prepoznavanje vzorcev

Object-Calculus

(UML+OCL)

(4

transformacije)

RBML (opis, gen, kode)

MDA

Slam-SL (sklepanje)

(predpogoj,

popogoj)

Študija primera

Sklepanje

ODOL (OWL)

(iskanje vzorcev,

gen. kode)

Repozitorij, izmenjavanje, prepoznavanje vzorcev

URN (UCM)

(GRL)

Študija primera

Enostavnost in uporabnost

PEC (PEC)

(Java)

Prevajalnik, ki vsiljuje vzorce

LePUS Repozitorij, preprost formalen zapis

TLA

FOL

Prolog

BPSL Sklepanje


Za vsako notacijo navajamo, v kateri primarni predstavitvi obstaja:

grafični, tekstovni ali strogem matematičnem zapisu.

Pri naštevanju orodij se omejimo na orodja, ki so jih navajali avtorji.

Menimo, da ni nepomembno ali je notacija tudi praktično uporabna.

Pri navajanju vidikov načrtovalskih vzorcev smo se omejili na 2

najpogosteje uporabljena vidika: strukturo (statično sliko) in obnašanje

(dinamično sliko) vzorca. Vidika ekspertnega znanja o vzorcih ni naslovila

nobena tukaj predstavljena notacija. V tabeli še navajamo tip

raziskovalnih metod, ki so jih avtorji v izvirnih člankih uporabili za potrditev

svojih notacij ter osnovni namen notacije, kot so ga predvideli avtorji.

3.3 Način izbire načrtovalskih vzorcev

Doktorska naloga se ukvarja s pospeševanjem ponovne uporabe kot

posledico učinkovitega iskanja primernih načrtovalskih vzorcev. V tem

poglavju predstavljamo sorodna dela avtorjev, ki so se že spopadli s

predstavljenim izzivom. Predstavljamo tudi dela, katerih ideje so sorodne

v doktorski nalogi predpostavljenemu pristopu.

Na primer Gomes et al v svojem članku »Selection and Reuse of Software

Design Patterns Using CBR and WordNet« predlaga gradnjo seznama

ključnih besed, ki jih poveže s primeri uporabe načrtovalskih vzorcev.

Princip sklepanja na primerih (Case-Based Reasonong), na osnovi

hranjenih primerov uporabe načrtovalskih vzorcev in s tem problemskih

situacij predlaga potencialno ustrezen načrtovalski vzorec. Predpogoj za

predlaganje je, da ima razvijalec pripravljen razredni diagram rešitve.

Predpripravljene primere uporabe načrtovalskih vzorcev v realnih

nalogah avtor indeksira in ponudi za iskanje. Učinkovito delovanje

svojega sistema avtorji pokažejo na študiji primera.

Z namenom iskanja je najenostavneje vzpostaviti repozitorij (formalno ali

neformalno) opisanih načrtovalskih vzorcev z možnostjo brskanja in


iskanja po njem. Iskanje je tipično omogočeno na osnovi ključnih besed,

takšno iskanje omogočajo praktično vsi repozitoriji načrtovalskih vzorcev.

Nekateri avtorji takšen pristop nadgradijo še z določenimi naprednejšimi

funkcionalnostmi.

Problema izbire ustreznega načrtovalskega vzorca se je inovativno lotil

tudi avtor Burke et.al. v članku »Choosing the Right Design Pattern: The

Implicit Culture Approach.« Avtor prav tako izhaja iz indeksiranja besed,

ki jih najdemo pri opisu načrtovalskega vzorca. Repozitorij vzorcev avtor

ponudi razvijalcem v obliki iskalnega orodja, ki omogoča iskanje na

osnovi ključnih besed. Avtor razvijalce poveže z večagentnim sistemom,

ki omogoča enostavno komunikacijo med razvijalci in skupinsko

odločanje o primernem vzorcu. Avtor pristop obravnava zgolj teoretično,

saj empirične raziskave ni izvedel.

Poleg iskanja na osnovi ključnih besed in kategoriziranega brskanja po

katalogih vzorcev srečamo še pristop, kjer avtorji uporabijo ekspertne

sisteme. Enega takšnih sistemov je zgradil tudi avtor Kung et al., opisan v

članku »An expert system for suggesting design patterns: a methodology

and a prototype«. Avtor prototipno implementira statičen ekspertni

sistem (ekspertni sistem z vnaprej definiranimi zaporedji fiksno vstavljenih

vprašanj in možnih odgovorov), ki olajša izbiro vzorcev iz kataloga GoF.

Pri tem dialog z uporabnikom razdeli na 5 nivojev: izbira kategorije

vzorcev, izbira podkategorije vzorcev, vprašanja o namenu, vprašanja o

posameznem vzorcu, pomožna vprašanja. Avtorji so prototipni sistem

implementirali in na podlagi empirične raziskave ugotovili, da sistem

signifikantno izboljša izbiro načrtovalskih vzorcev, predvsem začetnikom.

Slabost predstavljenega orodja je predvsem v ceni vzpostavitve: težko si

je predstavljati, da bodo eksperti za vsak načrtovalski vzorec sestavili

odločitveno drevo1.

1 Termin »odločitveno drevo« je uporabljen v smislu drevesne organizacije vprašanj in možnih odgovorov, katerih zaporedje po izbrani poti pripelje do končne odločitve.


Tudi avtor Zdun je v članku »Systematic Pattern Selection Using Pattern

Language Grammars and Design Space Analysis« naslovil problem izbire

relevantnih vzorcev. Njegov pristop je splošen za vse vzorce v

programskem inženirstvu – ni omejen le na načrtovalske. Poleg izbire

vzorcev avtor naslovi tudi vrstni red apliciranja več vzorcev, če je

problem rešljiv s kombinacijo več vzorcev. Njegov pristop bazira na

atributih kakovosti, ki so formalizirani skupaj s formalnimi opisi

načrtovalskih vzorcev. Tudi postopek izbire tega avtorja poganja več

odločitvenih dreves. Avtor pristop opiše teoretično in je kot takšen

predstavljen s študijo primera, informacijske podpore še nima.

Tudi širše, v ostalih domenah, ne le na področju načrtovalskih vzorcev,

lahko zasledimo sorodne izzive izbire določenega pristopa ali orodja.

Avtor Ewald et al. v članku »An Algorithm Selection Approach for

Simulation Systems« opiše postopek izbire ustreznega algoritma pri

sistemih za simuliranje. Problematika je podobna predstavljeni v doktorski

nalogi: razvijalci simulacijskih sistemov lahko algoritme simulacije razvijejo

sami, ali pa izberejo enega od že razvitih algoritmov, če je primeren za

podano situacijo. Avtor predlaga formalen opis algoritma v smislu

vhoda, izhoda in časovne ter prostorske zahtevnosti. Na tej osnovi se

dinamično samodejno gradi odločitveno drevo. Glede na situacijo se

algoritem izbira semi-avtomatsko, kar pomeni da se do določene mere

algoritem, ki bo funkcionalno in učinkovito zadovoljil simulacijo, izbere

samodejno. Kljub vsemu pa je intervencija razvijalcev še vedno nujna, saj

morajo razvijalci za vsak algoritem, ki sodeluje v izbiri sami razviti posebno

ovojnico, da bi omogočili kasnejše merjenje učinkovitosti. Pristop je

primeren za okolja, kjer so problem, rešitev in možne poti med njima

znani in formalno opisani. Klub temu se podoben sistem z manjšimi

modifikacijami pojavlja tudi v bolj splošnih okoljih.

Avtor Houstis et al. V članku »PYTHIA-II: a knowledge/database system for

managing performance data and recommending scientific software«

uporabi izboljšan pristop pri predlaganju uporabe programske opreme.


Na osnovi repozitorija znanstvene programske opreme in podanih

podatkih, ki jih želi znanstvenik obdelati ter opcijskih dodatnih zahtevah,

zna sistem predlagati najprimernejše orodje za obdelavo podatkov.

Sistem to naredi v več fazah, ki vključujejo ugotavljanje namena,

testnega poganjanja programske opreme nad podatki in poizkusa

analize pridobljenih podatkov. Na osnovi repozitorija programske

opreme in baze metrik lahko znanstvenik tako zgolj na osnovi podatkov

in dodatnih zahtev (domena, tip podatkov, časovna zahtevnost ipd.)

enostavno izbere programsko opremo za obdelavo podatkov. Sistem je

primeren za okolja, ki lahko vhod samodejno pretvorijo na izhod ter ga

tudi ovrednotijo z uveljavljenimi metrikami. Na področju načrtovalskih

vzorcev ti kriteriji žal niso izpolnjeni.

Izbiri ustreznih načrtovalskih vzorcev bi lahko služili tudi t. i. sistemi za

predlaganje (angl. recommender systems). Njihova značilnost je, da na

osnovi podatkov o zgodovini uporabe in uporabnikovega profila poleg

njegovih eksplicitnih izbir predlagajo tudi implicitne. Ti sistemi so zelo

priljubljeni pri npr. spletnih sistemih za nakupovanje, kjer trgovina kupcem

predlaga artikle, ki bi jih utegnili zanimati. Pristop bi bilo možno aplicirati

na izbiro načrtovalskih vzorcev: vodili bi zgodovino apliciranja

načrtovalskih vzorcev v določenih problemskih situacijah profil pa bi

predstavljali podatki o trenutni problemski situaciji. Pristop bi zahteval

formalno predstavitev problemskih situacij, potreboval pa bi tudi

naprednejše mehanizme učenja. Vložek ekspertov bi bil sicer velik,

vendar po naši oceni manjši kot pri vodenju odločitvenih dreves. Eden

takšnih sistemov za predlaganje opiše avtor McDonald et al. v članku

»Expertise recommender: a flexible recommendation system and

architecture«. Sistem je sposoben semiavtomatsko zbirati podatke o

ekspertnem znanju zaposlenih in na ta način oblikovati seznam vseh

sposobnosti. Ko uporabnik v določenem trenutku išče sodelavca z

določenimi znanji, to vpiše v uporabniški vmesnik sistema, le ta pa

predlaga osebo skupaj s seznamom kompetenc. Uporabnik lahko tudi


ročno gradi ekipo strokovnjakov, pri čemer sistem predlaga primerne

sodelavce.

Avtor Burke et al. takšen pristop še nadgradi z mehanizmi, ki omogočajo

s pomočjo večagentnega sistema vzpostaviti komunikacijo med

zaposlenimi. Na takšen način je omogočeno skupinsko odločanje. Sistem

je opisan v delu »Hybrid Recommender Systems: Survey and

Experiments«. Pristop je podoben večagentnemu sistemu, kot ga Burke

et al. predlaga na področju načrtovalskih vzorcev. (Burke, 2002)

Kot bomo predstavili v nadaljevanju, naš pristop združuje večino

pozitivnih lastnosti tukaj predstavljenih poizkusov. Povezovanje vzorcev,

vodenje primerov uporab vzorcev in ključnih besed smo nadgradili z

algoritmom, ki omogoča voden dialog z minimalno vpletenostjo

ekspertov. Pri tem smo uporabili ideje iz Shannonove informacijske teorije

(Shannon, 1949). Tudi drugi avtorji so uporabili potencial izračunavanja

informacijske entropije za lažje vodenje dialoga z uporabnikom. Avtor

Ittycheriah et al. na primer v članku »Question answering using maximum

entropy components« opisuje sistem, ki omogoča podajanje odgovorov

uporabniku, pri čemur se odgovori izbirajo na osnovi izračunavanja

informacijske entropije, ki jo ustvari posamezen možen odgovor. Pristop

vključuje samodejno tvorjenje odgovorov iz dosegljive enciklopedije;

razvita formula na osnovi entropije za uporabniško podano vprašanje

izbere odgovor, ki ga zastavi uporabnik. Gre pravzaprav za napredno

iskanje po ključnih besedah. To delo je za nas pomembno iz naslednjega

vidika: tudi naš algoritem vodenega dialoga deluje na osnovi teorije o

informacijski entropiji, pri čemer se na osnovi izračuna zmanjšane

entropije izbira vprašanje, ki ga postavimo uporabniku. Kot bomo videli v

nadaljevanju, omogoča naš algoritem samodejno povezovanje, sicer

ločenih ekspertnih nasvetov v voden dialog, ki zbira podatke o

kontekstu. Na podlagi teh informacij lahko predlaga ustrezen

načrtovalski vzorec.


4. Ontološko zasnovana formalna predstavitev

načrtovalskih vzorcev

V 3. Poglavju smo predstavili obstoječe načine predstavitve

načrtovalskih vzorcev. Na formalne predstavitve smo se osredotočili, ker

želimo z raziskavo nasloviti izzive podpore iskanju in izbiri vzorcev. Le-te je

mogoče razumeti tudi kot komplementarne izzive tistim, ki so jih naslovili

že drugi avtorji: po uspešnem iskanju načrtovalskega vzorca s pomočjo

orodja bi bilo smiselno izbran vzorec ponuditi razvijalcu v obliki, ki se

samodejno preslika v konkretno rešitev.

Kljub temu da nobena od predstavljenih notacij formalnega zapisa

znanja za nas ni uporabna neposredno, vendarle uporabimo nekatere

izsledke. Poleg komplementarnosti z eno izmed notacij, ki omogoča

poenostavljeno implementacijo vzorca v končno rešitev, smo oblikovali

dodatne zahteve lastne formalne notacije. Med drugim:

• doseči želimo enostavno povezljivost z obstoječimi formalnimi

notacijami,

• vzpostaviti želimo možnost enostavnega zajema ekspertnega

znanja,

• imeti želimo možnost enostavne transformacije podatkov,

• notacija naj podpira možnosti (samodejnega) izmenjevanja

znanja,

• omogoča naj relativno enostavno strojno obdelavo znanja,

• želimo tudi obstoječo tehnično podporo formalni notaciji.


Glede na predstavljena dejstva smo se odločili, da z namenom formalne

predstavitve načrtovalskih vzorcev uporabimo ontologije in tehnologije

semantičnega spleta. Takšna odločitev združuje trdno matematično

podlago z zapisom, ki je blizu tako strojem kot tudi ljudem, zaradi

standardizacije pa je na voljo vse več orodij, ki bi s takšno predstavitvijo

lahko upravljala. Glavne prednosti so torej sledeče:

• Formalen zapis vzorcev na osnovi ontologij je enostavno

obdelovati s pomočjo računalnika in je tako primeren za

samodejno izvajanje operacij.

• Enostavno je doseči transformacije matematičnega zapisa

načrtovalskih vzorcev v uporabniško prijazen zapis.

• Tehnologije semantičnega spleta so standardizirane in čedalje bolj

uveljavljene.

• Možnost izmenjave načrtovalskih vzorcev je dosežena samodejno.

• Ontološko podprti podatki so že privzeto distribuirani.

• Na voljo je celotna paleta orodij, ki znajo delati s tehnologijami

sklada semantičnega spleta.

Odločili smo se, da oblikujemo svojo ontologijo. Pri tem smo se odločili

podpreti predvsem vidike, povezane z iskanjem vzorcev in manj vidike,

povezane s statično in dinamično sliko vzorcev. Pri tem je pomembno

poudariti, da vpeljava lastne ontologije z vidika povezljivosti s sorodnimi

ontologijami ni problematična. Lastno ontologijo lahko razumemo kot

komplementarno ontologiji ODOL (Dietrich et. al., 2007). Le ta je

orientirana na prepoznavanje vzorcev in njihovo preprosto

implementacijo, medtem ko je lastna usmerjena v upravljanje z

repozitorijem vzorcev. Torej se osredotočimo na formalizacijo objektno

orientiranih aspektov vzorca, povezav med vzorci in ekspertnega znanja

o vzorcih.


4.1 Osnove ontologij

Ontologije na področju informatike izhajajo iz področja filozofije, kjer

ontologija predstavlja poizkus raziskovanja pojma »bivanje«. Z

ontologijami je možno medsebojno povezovati in formalno opisovati

koncepte iz katerega koli področja človekovega udejstvovanja. V

informatiki ima ontologija veliko ožji pomen. S pomočjo ontologije lahko

napredno klasificiramo posamezne informacijske elemente, jih

medsebojno povezujemo in ustvarjamo poljuben sistem metapodatkov,

ki so podpora zapisanim informacijskim objektom.

Pojem ontologije se uporablja predvsem na področju upravljanja z

znanjem – natančneje s klasifikacijo posameznih informacijskih objektov.

Primitivnejše oblike klasifikacij predstavljajo:

• nadzorovan besednjak (angl. controlled vocabulary), ki omogoča

klasifikacijo informacijskih objektov v množico predpisanih terminov

(razredov),

• taksonomija, kjer so termini (razredi) slovarja hierarhično

medsebojno povezani v smislu generalizacije,

• slovar (angl. thesaur) razširja možnosti taksonomije z dodatnimi

predpisanimi relacijami, npr. »soroden« - tako lahko v slovarju

informacijske objekte med seboj povezujemo še drugače kot v

hierarhičnem smislu.

Ontologije omogočajo poleg hierarhičnih in mrežnih povezav med

informacijskimi objekti še zapisovanje aksiomov, pravil in drugih omejitev;

predvsem pa omogočajo medsebojno povezovanje s popolnoma

poljubnimi relacijami. Ontologije tako predstavljajo formalno možnost

zapisa znanja.


Ena izmed priljubljenih definicij ontologije se glasi:

Ontologija je formalna eksplicitna specifikacija deljene konceptualizacije.

(Gruber, 1993)

Kot je razbrati iz definicije torej omogoča ontologija formalen, na

matematični osnovi temelječ (deskriptivna logika) zapis znanja, kot ga

razumejo ljudje iz določenega področja in se s takšnim zapisom strinjajo.

Ontologija vsebuje naslednje elemente:

• informacijske objekte (primerke),

• razrede, ki omogočajo klasifikacijo informacijskih objektov;

pogosto razrede imenujemo tudi »koncept«; tudi razred je

informacijski objekt,

• atribute, ki predstavljajo aspekte, lastnosti, funkcionalnosti, ki so

lastne informacijskim objektom (in s tem tudi razredom); če atributi

povezujejo informacijske objekte jih imenujemo tudi relacije, tudi

atribut je informacijski objekt,

• omejitve, ki formalno opišejo kakšne zahteve morajo informacijski

objekti izpolnjevati, da jih sprejmemo kot veljavne,

• aksiomi, logične trditve, ki opisujejo teorijo o znanju določene

domene; tudi omejitve so aksiomi.

• pravila, ki služijo da se v ontologiji, poleg eksplicitno podanih

informacijskih objektov, pojavijo tudi implicitni, pravilo je tudi

aksiom.

Temelj ontologij je princip odprtega sveta (angl. open world assumption).

Le-ta v uveljavljene tehnike upravljanja z znanjem v informatiko prinaša

konceptualne novosti. Tipično se namreč uporablja princip zaprtega

sveta (angl. closed world assumption). V nasprotju z njim, v odprtem

svetu za neko trditev, ki je ne moremo potrditi, tudi ne moremo izpeljati

sklepa, da je napačna.


Sam nabor elementov, ki jih zapišemo v ontologijo se razlikuje od

tehnologije, ki takšen zapis omogoča. V nadaljevanju si bomo ogledali

tehnološko osnovo za delo z ontološko predstavljenim znanjem:

semantični splet (semantic web), ki trenutno predstavlja de-facto

standard na tem področju in za katerega skrbi konzorcij W3C.

4.2 Tehnološka rešitev: standardi in tehnologije semantičnega

spleta

4.2.1 Iniciativa semantičnega spleta

Cilj iniciative semantičnega spleta je ustvariti univerzalni medij za izmenjavo

podatkov, kjer so le-ti pripravljeni na deljenje in obdelavo s strani avtomatskih

orodij kot tudi ljudi.

(Berners-Lee, 2001)

Kljub temu, da na prvi pogled namen iniciative semantičnega spleta, kot

je razviden iz zgodnje definicije, nima veliko skupnega z ontologijami, pa

ravno standardi in tehnologije semantičnega spleta predstavljajo

trenutno najnaprednejšo tehnično osnovo ontologijam. Osnovna ideja

semantičnega spleta je ontološka organiziranost in zapis podatkov. Na

takšen način želijo avtorji premostiti prepreko med veliko količino

nestrukturirano zapisanega znanja in prepoznavanjem ter uporabo

takšnih podatkov s strani strojev. Brez bistvenega spreminjanja navad

ljudi pri uporabi podatkov in informacijskih rešitev želijo podatke

organizirati tako, da bodo pripravljeni za strojno obdelavo, v smislu

strojnega učenja in samodejnega sklepanja. Prav to pa je bistvena ideja

semantičnega spleta. Sredstvo za dosego tega cilja so v semantičnem

spletu podatki, ki govorijo o podatkih oz. jih opisujejo, torej metapodatki.

Kot že samo ime pove, je bistvo semantičnega spleta medsebojno

povezovanje »pomenov« in ne več sintaktičnih gradnikov informacijskih

objektov (virov, dokumentov, vsebin). Zaradi tega je semantični splet


zgrajen s pomočjo sistema metapodatkov, s katerimi predstavimo

semantične (pomenske) mreže. Le-te so ena izmed možnosti formalne

predstavitve znanja, ki se je v okolju medsebojno povezanih vsebin,

kakršen je svetovni splet, izkazala za najboljšo.

Zapis znanja v obliki pomenskih mrež dosežemo zelo enostavno. Splošno

poznana dejstva opisujemo s pomočjo že poznanih dejstev v obliki

enostavnih trdilnih stavkov (osebek – povedek – predmet). Da bi ideja

lahko zaživela globalno, potrebujemo najprej:

• standardiziran način poimenovanja informacijskih objektov in

način, s katerim te objekte najdemo,

• standardiziran način za opisovanje informacijskih objektov,

• standardne besednjake za pogovarjanje o informacijskih objektih

in

• standardiziran način določanja pomena informacijskim objektom.

Vse zgoraj naštete standarde iniciativa semantičnega spleta s pomočjo

ontologij uspešno naslovi. Zelo pomembno je, da je mogoče ideje in z

njimi povezane tehnologije brez težav uporabiti tudi v drugih področjih,

ne le v okolju globalno dostopnega svetovnega spleta. Uporabne so na

področju informacijskih rešitev večjih organizacij in v večjih sistemih za

upravljanje z znanjem. Z njihovo pomočjo lahko uporabnikom ponudimo

nove, inteligentnejše načine zajema podatkov in uporabe znanja.

Uporaba semantičnega spleta je še posebej primerna za uporabo v

naslednjih področjih:

• opisovanje strojno slabše uporabnih vsebin (torej vsebin,

namenjenih uporabi s strani ljudi),

• opisovanje spletnih storitev, z namenom lažje semi-avtomatske

integracije aplikacij,

• opis informacijskih storitev na spletu, z namenom lažjega lociranja

in uporabe znotraj tretjih rešitev,


• integracija informacijskih sistemov na nivoju podatkov in njihovo

predstavitev z enotnim portalom,

• poenoteno iskanje informacij v ločenih in distribuiranih

informacijskih sistemih,

• nadgradnja storitev informacijskih sistemov, ki upravljajo z znanjem,

• integracija znanja v ekspertne sisteme ipd.

Po našem mnenju lahko večino poizkusov uporabe semantičnega spleta

kategoriziramo znotraj dveh velikih področij:

• integracija aplikacij in

• upravljanje z znanjem.

Pri tem je pomembno poudariti, da semantični splet na ta področja

uvaja inteligentne storitve, ki smo jih v preteklosti srečali le na področju

konvencionalne umetne inteligence.

4.2.2 Tehnologije semantičnega spleta

Kot smo že omenili v poglavju 4.2.1, je na področju semantičnega spleta

znanje predstavljeno v obliki semantičnih mrež. To dosežemo z jezikom

RDF (Resource Description Framework), temelječim na opisnem jeziku

XML (eXtensible Markup Language). Koncepte v RDF označimo s

pomočjo URI-jev (Uniform Resource Identifier - še en W3C standard, ki je

namenjen globalno unikatnemu poimenovanju virov). Tako omogoča

RDF gradnjo podatkovnega modela za vire in relacije med njimi. Ker

poenoteno poimenovanje stvari na osnovi URI-jev ni dovolj za uporabo

znanja v inteligentnih agentih, potrebujemo še ontologije. Za zapis

ontologij je na voljo kar nekaj jezikov. S strani W3C priporočen in najširše

zastopan je OWL (Web Ontology Language). Celoten sklad tehnologij

semantičnega spleta je razviden na spletnih straneh W3C

(http://www.w3c.org).


Slika 12: Sklad tehnologij semantičnega spleta

Kot je iz sheme (slika 12) razvidno, si svetovni splet in sodobne

informacijske rešitve s semantičnim spletom delijo iste temeljne

tehnologije. Jezik RDF, ki je zgrajen nad njimi, je dokaj preprost in odprt, a

kljub temu ni namenjen uporabi brez primernih orodij. V RDF zapišemo

metapodatke. Le-ti niso omejeni s shranjevanjem na točno določenem

mestu (datotečni sistem, podatkovna baza, specializirane podatkovne

shrambe, spletni strežniki, ipd.), še več, metapodatke v RDF lahko celo

kar pripnemo virom, ki jih opisujejo. Jezik RDF omogoča tvorbo preprostih

stavkov oz. dejstev v obliki osebek-povedek-predmet (Slika 13). Z

množico takšnih stavkov lahko zelo preprosto oblikujemo usmerjen graf,

ki ga imenujemo tudi semantična mreža in predstavlja formalno

predstavitev znanja (slika 14). Bolj kot so koncepti v mreži povezani, več

znanja nosijo.

Slika 13: Preprost RDF stavek


Slika 14: Preprosta semantična mreža

Ontološki slovar je v semantičnem spletu predstavljen z jezikom OWL

(jezik temelječ na XML). Jezik predstavlja konsolidacijo preteklih jezikov za

opis ontologij (DAML, OIL). V operativni uporabi je od leta 2004, ko je

postal uradno priporočilo konzorcija W3C.

4.2.3 Zapis ontologij z jezikom OWL

V prejšnjem poglavju nismo izpostavili tehničnih težav, ki jih zapis znanja z

ontologijami prinaša. Poleg velike časovne in prostorske zahtevnosti

naprednih operacij je največja ovira pri polni uporabi ontologij tudi

možna nedeterminističnost: za poljubno ontologijo ni mogoče trditi, da

bo obdelana v realnem času. Ker si takšne tehnologije v produkcijskih

okoljih ni mogoče privoščiti, obstaja jezik OWL v treh različicah:

• OWL Lite omogoča zapis razredov, informacijskih objektov ter

enostavnih omejitev. V postopku sklepanja so upoštevane le

hierarhične povezave med razredi. OWL Lite omogoča revno

izraznost, hkrati pa hitro in učinkovito izvajanje informacijskih rešitev.

• OWL DL nadgradi OWL Lite. Ponuja maksimalno možno izraznost

hkrati z garantirano izračunljivostjo ontologije – vsa sklepanja se

bodo zaključila v realnem času. OWL DL je omejen z operacijami,

ki jih predvideva deskriptivna logika. Relacije med informacijskimi


objekti lahko tudi vsebujejo določene lastnosti, kot npr. tranzitivna

relacija, inverzna ali simetrična relacija.

Primer sklepanja z OWL DL:

jeOce owl:inverseOf jeSin

jeSin rdfs:subPropertyOf jeOtrok

jeOtrok rdfs:inverseOf jeStars

sklep: jeOce rds:subPropertyOf jeStars

• Jezik OWL Full pred razvijalca ne postavlja nobenih omejitev.

Omogočeno je celotno sklepanje, ki ga določen pogon

implementira. Napake v sistemih, ki uporabljajo OWL Full lahko

imajo dokaj usodne posledice, saj izračunljivost modela ni

zagotovljena.

V splošnem obstaja priporočilo s strani W3C, da razvijalci uporabijo

najšibkejšo različico jezika OWL, ki omogoča zahtevane funkcionalnosti

informacijske rešitve.

Jezik OWL predvideva več možnih informacijskih konstruktov:

• Razredi; obstajajo tudi posebne oblike razredov: identifikator,

seznam objektov, omejitev lastnosti, presek razredov, unija

razredov, komplement razredov. Obstajata 2 vnaprej določena

identifikatorja razreda: owl:Thing, ki predstavlja vse informacijske

objekte in owl:Nothing, ki predstavlja prazno množico.

• Lastnosti, ki so lahko različnih tipov in omejene glede dosega in

kardinalnosti. Obstaja mnogo že predefiniranih lastnosti: rdf:type,

owl:subclassOf, owl:sameAs, owl:inverseProperty ipd.

• Objekti.

4.3 Zapis GoF in J2EE načrtovalskih vzorcev

Tekom doktorske naloge smo razvili lastno notacijo načrtovalskih vzorcev,

ki temelji na ontologijah. Lastno notacijo lahko razumemo kot


komplementarno ontologiji ODOL (Dietrich et. al., 2007), saj se na njo

lahko preprosto povežemo in s tem brez podvajanja truda uporabimo

formalizirane tudi tiste aspekte, ki smo jih mi izpustili. Naša formalizacija se

osredotočimo na formalizacijo objektno orientiranih aspektov vzorca,

povezav med vzorci in ekspertnega znanja o vzorcih.

Ekspertno znanje o vzorcih predstavljajo testni primeri, sestavljeni iz

besedila načrtovalskega problema in ustrezne rešitve, in pari vprašanj ter

odgovorov, ki so povezani z vzorci v smislu primernosti.

Takšen opis vzorcev zaradi naslednjih lastnosti odpira mnoge možnosti

inteligentnim storitvam, kot je predlaganje primernega vzorca:

• Osnova zapisu podatkov so splošno sprejeti standardi konzorcija

W3C.

• Opis znanja, temelječ na ontologijah je primeren za strojno

obdelavo in kot tak omogoča uporabnost v inteligentnih agentih.

• Z relativno enostavnimi transformacijami je mogoče doseči

drugačno predstavitev znanja na osnovi OWL (tekstualno, grafično

ipd.)

• Tehnologije za delo z ontologijami, zapisanimi v OWL, so že

uveljavljene in preizkušene.

• Izmenjava takšnega znanja je mogoča zelo preprosto.

• Znanje, zapisano v OWL je že po naravi distribuirano.

Jedro lastne ontologije (v nadaljevanju DPO), uporabljene za opis

načrtovalskih vzorcev, je predstavljeno na sliki 15. Na sliki ni predstavljena

podrobnejša razgradnja na atribute konceptov. Koncept »Pattern« je

skupen ontologiji ODOL in ontologiji DPO, kar omogoča morebitno

enostavno povezovanje.


Slika 15: Jedro ontologije za opis vzorcev

Ontologija DPO uvaja hierarhičen pogled na vsebnike vzorcev

(»PatternContainer«). Vsak vsebnik lahko vsebuje več vsebnikov in

vzorcev (»Pattern«). S takšnim pristopom lahko zajamemo različne

poglede na klasifikacijo posameznih katalogov, ne le standardnih. Vsak

vzorec je namreč lahko umeščen tudi v več vsebnikov. Vzorce lahko

povezujemo tudi medsebojno v smislu sestavljenih vzorcev, povezanih

vzorcev, različic vzorca in alternativnih vzorcev. V ontologiji DPO s pridom

uporabljamo tranzitivno relacijo (»isMemberOf«), ki poenostavi pogled

nad vzorci v posameznem vsebniku.

Na takšen način smo opisali vzorce, ki jih najdemo v katalogu vzorcev

GoF (Gamma et. al., 1995) In J2EE (Deepak, 2001). Vzorce smo

medsebojno povezali, kot to predvidevata izvorna kataloga, poleg

standardnih pa smo uvedli tudi lastne razdelitve po vsebnikih.

4.4 Zapis ekspertnega znanja o vzorcih

Poleg možnosti predstavitve ekspertnega znanja s pomočjo vzorcev smo

v ontologijo DPO dodali še koncepte, ki omogočajo zajem implicitnega

ekspertnega znanja s pomočjo vprašanj in odgovorov. Jedro

uporabljene ontologije je predstavljeno na sliki 16.


Slika 16: Jedro ontologije za zapis ekspertnega znanja o vzorcih

Eksperti lahko prispevajo znanje o tem, kako se v določeni situaciji

odločiti (koncept »Question«) za določen vzorec (koncept »Answer«). To

znanje je s konkretnimi vzorci ali vsebniki povezano s pomočjo koncepta

»AnswerRelevance«, ki zajema predvideno relevantnost kandidata

(vzorec, »Pattern« ali vsebnik, »PatternContainer«) za uporabo ob

podanem odgovoru. Eksperti lahko podajo predvideno relevantnost

tako za situacijo, ko se bo kandidat uporabil, kot tudi da kandidat v dani

situaciji ni primeren. Po našem mnenju so ti podatki ključni pri boljšem

iskanju vzorcev v repozitoriju vzorcev. To bomo v naslednjih poglavjih

podprli tudi z dejstvi.

Pomemben vidik ontologije so tudi primeri iz realnega sveta, ki vključujejo

uporabo vzorca. Ta vidik je zajet s konceptom »TestCase«. Primeri so

opisani v obliki načrtovalskega problema (vezano besedilo) in ustrezne

rešitve (»caseSolution«).


4.5 Primer uporabe: algoritem za predlaganje ustreznega

načrtovalskega vzorca

4.5.1 Cilji algoritma

Lastno formalno notacijo načrtovalskih vzorcev smo definirali predvsem z

razlogom, da poleg osnovnih objektnih aspektov vzorcev zajamemo še

eksplicitno in implicitno ekspertno znanje o njih (poglavje 4.4). To znanje

bi želeli uporabiti v inteligentni komponenti, ki bo na osnovi vodenega

dialoga razvijalcu predlagala ustrezen vzorec za podano problemsko

situacijo. Pri tem smo se želeli izogniti zapisovanju statičnih odločitvenih

dreves, saj menimo da ontološko zapisano znanje ponuja več potenciala

v združevanju sicer ločenih podatkov, hkrati pa je vložek pri gradnji

statičnih odločitvenih dreves zelo velik. Zato je bile naše vodilo pri

načrtovanju ontologije, da ekspertov s področja načrtovalskih vzorcev

ne želimo obremenjevati z izrazitim dodatnim delom, da bi naša

komponenta lahko delovala. Namesto tega smo zasnovali ontologijo

DPO na takšen način, da lahko vsak ekspert prispeva le majhen del

svojega znanja, komponenta pa ga zna sama ustrezno združiti in kot

takšnega ponuditi končnim uporabnikom. Cilj algoritma, ki ga

predstavljamo tukaj, je torej, da iz množice nepovezanih (v smislu

odločitvenih dreves) vprašanj različnih avtorjev, izbere zaporedje čim

manj vprašanj, katerih odgovor bo podal največjo možno informacijo o

razvijalčevem problemu. Na osnovi te informacije naj bo algoritem

sposoben predlagati ustrezen vzorec, ki bo problemsko situacijo rešil.

Izhajamo iz popolnoma praktičnega, vsakodnevnega scenarija prenosa

znanja od eksperta do manj izkušenega razvijalca. Na primer:

Razvijalec: imam obstoječ razred, ki bi ga rad uporabil malce drugače,

kot mi to dopušča implementacija.


Ekspert s področja načrtovalskih vzorcev: Bi ga rad samo uporabil ali mu

želiš hkrati poenostaviti vmesnik? V prvem primeru uporabi vzorec

adapter, v drugem primeru bi morda bilo bolje uporabiti vzorec fasada.

V tem poglavju bomo pokazali, kako zna naš algoritem množico takšnih

ekspertnih nasvetov samodejno povezati v voden dialog z uporabnikom.

4.5.2 Vhodni in izhodni podatki algoritma

Ontologija DPO predpisuje obstoj nepovezanih vprašanj. Vsako

vprašanje ima lahko več možnih odgovorov, le-ti pa so v smislu

relevantnosti povezani s kandidati, lahko neposredno z vzorci, lahko pa z

vsebniki. (glej sliko ontologije 16)

Relevantnost je podana kot številka na intervalu [0, 1]. Ta številka

preprosto pove, kakšna je predvidena relevantnost določenega

kandidata, da bo uporaben ob podanem odgovoru:

• vrednost 0 pomeni, da kandidat ni primeren kot rešitev podanega

problema,

• vrednost 1 pomeni, da je zelo verjetno, da bo kandidat uporaben

kot končna rešitev problema,

• vrednosti med 0 in 1 pomenijo predvideno relevantnost, s katero

smo za posameznega kandidata prepričani, da je relevanten kot

končni odgovor. Na primer vrednost 0.5 pomeni, da nimamo

nobenega podatka o tem ali bo kandidat primeren kot končni

odgovor ali ne; 0.25 pomeni, da je zelo malo verjetno, da bi

kandidat bil primeren kot končna rešitev, 0.75 pa npr., da obstaja

velika verjetnost, da je kandidat tudi končna rešitev.

Vprašanja, odgovore in predvidene relevantnosti vstavijo eksperti.

Podatke smo zbirali še pred razvojem algoritma, saj nismo želeli, da bi

eksperti morali znanje vnašati po predpisani šabloni, temveč smo jim

pustili svobodo: določeni možni odgovori so povezani z veliko kandidati,


spet drugi le z enim ali dvema. Naš algoritem dobro deluje tudi na osnovi

tako naravno zbranih podatkov.

Poglejmo si preprost primer ekspertnega vprašanja:

Kakšno vrsto razdelitve želite vpeljati v vaš sistem?

• po nivojih: z vmesnikom in ločeno implementacijo namestnik:

0.6, fasada: 0.85, most: 0.7, adapter: 0.65, mediator: 0.7

• po delih, ki jih obdelujem ločeno iterator: 0.9

• po delih, pri čemer so vsi deli obveščeni o spremembi v enem delu

opazovalec: 1.0

Algoritem na vhodu prejme seznam vseh vprašanj in kandidatov, ki v

vprašanjih nastopajo. Kandidate predstavimo z vektorjem predvidenih

relevantnosti:

C=[c(p1), c(p2), c(p3), …, c(pn-1), c(pn)],

kjer je pi (1<=i<=n) kandidat, c(pi) pa trenutna relevantnost kandidata pi.

Tudi vrednosti vektorja (c(pi)) ležijo v intervalu [0,1]. Nosijo podoben

pomen kot prej predstavljene predvidene relevantnosti kandidatov pri

odgovorih: 0 pomeni, da kandidat ni primeren kot končni odgovor, 1

pomeni, da je kandidat gotovo končni odgovor, 0.5, da nimamo

nobenega podatka o primernosti kandidata ipd. Začetne vrednosti vseh

c(pi) so torej 0.5.

Z namenom lažje berljivosti, se bomo v nadaljevanju na vektor

C=[c(p1), c(p2), c(p3), …, c(pn-1), c(pn)]

sklicevali kar v obliki:

C=[c1, c2, c3, …, cn-1, cn].

Torej, kjerkoli je mogoče se bomo z zapisom ci dejansko sklicevali na

relevantnost kandidata pi, skratka c(pi).


Tudi izhod algoritma je vektor C, ki je na podlagi uporabnikovih

odgovorov ustrezno modificiran. Kandidat z največjo relevantnostjo je

najbolj primeren, da je tudi dejanska rešitev načrtovalskega problema.

Na kakšen način predlagamo spreminjanje vektorja C v odvisnosti od

podanih odgovorov opisuje naslednje podpoglavje.

4.5.3 Združevanje podanih odgovorov v vektor relevantnosti

V tem podpoglavju še ne bomo obravnavali načina, po katerem je

izbrano vprašanje, na katerega naj uporabnik odgovori. Privzemimo

torej, da je uporabnik podal odgovor na neko vprašanje iz ontologije

DPO.

Na podlagi odgovora se kreira vektor: A=[a(p1), a(p2), a(p3), …, a(pn-1),

a(pn)]. Tudi tukaj se dogovorimo za notacijo ai=a(pi).

Vrednosti ai predstavljajo uteži relevantnosti za posameznega kandidata

pi. Za kandidate, katerih relevantnost ne poznamo, vstavimo vrednost 0.5

(0.5 je srednja vrednost, ni podatka). Če bi torej uporabnik iz primera v

podpoglavju 4.5.1 izbral odgovor »po delih, pri čemer so vsi deli

obveščeni o spremembi v enem delu«, bi to pomenilo, da ima vektor A

same vrednosti 0.5, razen pri kandidatu opazovalec, bo vrednost 1.0.

Glede na to, da algoritem transformira začetno stanje vektorja C (ci=0.5

za vsak i) v končno obliko na podlagi podanih vektorjev A, nas zanima

formula za transformacijo vektorja C. Pri razvoju formule smo sledili

naslednjim vodilom:

• Vrednosti ci morajo tudi po transformaciji ostati na intervalu [0,1].

• Če je katera izmed vrednosti ai=0.5, se priležna vrednost vektorja

C, to je ci, naj ne spremeni – glede na to da vektor A ni o tem

kandidatu podal nobenih novih informacij.

• Bolj kot vrednost ai odstopa od priležne vrednosti vektorja C ci, bolj

se mora vrednost vektorja C ci spremeniti – navzdol, če je ai<ci in

navzgor, če je ai>ci. Na takšen način se izognemo situaciji, ko bi


zadnji odgovor determiniral končni rezultat, saj ocenjujemo, da je

možno podati več odgovorov, ki obravnavajo iste kandidate.

• Več odgovorov, kot je podanih glede določenega kandidata,

manjši naj bodo vplivi na skupno vrednost ci. Na takšen način

posredno favoriziramo vprašanja, ki v začetnih fazah dialoga

zajamejo več kandidatov, v kasnejših fazah pa fino profilirajo

posamezne kandidate.

Slika 17 grafično prikazuje kombiniranje vektorja relevantnosti s podanim

odgovorom: c(pi) se spremeni v novo vrednost cn(pi) le v primerih, ko je

a(pi) različna od 0.5. Vpliv odgovora na cn(pi)naj se kaže na vmesnem

delu med c(pi) and a(pi).

Slika 17: Sprememba vektorja relevantnosti glede na podan odgovor

Predlagamo zelo enostavno formulo Eq1 za izračun novih vrednosti

vektorja C: cn(pi). Formula dela s preprostimi povprečji:

2 ; 0.5

; 0.5

Formula Eq1: Kombiniranje vektorja relevantnosti s podanim odgovorom

Formula v celoti izpolnjuje vse prej naštete kriterije. Poleg tega je dokaj

neobčutljiva na kontradiktorno odgovarjanje: če uporabnik poda


odgovor v prid določenemu kandidatu, kasneje pa odgovor, ki istega

kandidata negira, se vrednost ci zopet postavi blizu vrednosti 0.5

(območje »ni informacije«).

Vrednosti vektorja C se ob začetnih podanih odgovorih spreminjajo zelo,

kasneje malo. Primer: uporabnik poda 3 odgovore, ki izrazito favorizirajo

določenega kandidata (s predvideno relevantnostjo 1.0), potem v

prvem koraku relevantnost kandidata skoči na 0.75, v drugem na 0.875 in

v tretjem na 0.9375. Če tako opazujemo posameznega kandidata, ga je

metoda sposobna dovolj gotovo potrditi že po treh ustreznih odgovorih.

4.5.4 Izračun poteka dialoga na osnovi informacijske entropije

V predhodnem podpoglavju smo opisali postopek, ki je sposoben na

osnovi uporabnikovih odgovorov ugotoviti, kateri kandidat je v dani

situaciji najprimernejši. Vendar je bistvo algoritma v ustrezni izbiri vrstnega

reda vprašanj. Oglejmo si nekaj možnosti.

Konvencionalni ekspertni sistemi so sosledje vprašanj določali s pomočjo

odločitvenega drevesa, ki ga je tipično sestavil ekspert. Odločitveno

drevo takšnih sistemov statično določa, v kakšnem vrstnem redu se naj

izbirajo vprašanja in na podlagi izbrane poti skozi drevo predlaga

končno rešitev. Takšen način bi gotovo bil primeren, saj bi nabor vprašanj

bil bržkone optimalen. Naslednja možnost bi bila, da uporabniku

postavimo vsa vprašanja, ki obstajajo v ontologiji DPO. Prva možnost ni

ustrezna, ker ne želimo dodatnih intervencij ekspertov, druga pa ni

ustrezna, ker je število vprašanj preprosto preveliko.

Morda bi bila boljša možnost v postavljanju naključnih vprašanj, dokler

relevantnost določenega kandidata ne doseže mejne vrednosti. Takšen

način bi bil ustreznejši, saj bi bilo pričakovati manjše število postavljenih

vprašanj.

Kot referenco pri iskanju čim boljšega algoritma za izbiro vrstnega reda

vprašanj, smo sestavili fiksno odločitveno drevo. Na osnovi našega


drevesa uporabniku postavimo 3 do 6 vprašanj, da dobimo relevantno

odločitev. V nalogi zato opišemo algoritem, ki se je izmed preizkušenih

po številu odgovorov, ki jih mora podati uporabnik, najbolj približal

fiksnemu odločitvenemu drevesu. Tako bo vsaj bistveno boljši od

postavljanja naključnih vprašanj.

Odločitev o vprašanju, ki bo postavljeno, lahko algoritem sprejme

izključno na podlagi trenutnega stanja vektorja C. Spraševanje se izvaja

toliko časa, da bo vektor dovolj izrazito favoriziral določenega

kandidata. Odločitev o tem, da je določen kandidat dovolj favoriziran

pa ni preprosta in vsebuje celo množico kriterijev. Ni dovolj, da zgolj

izluščimo maksimalno vrednost. Kaj pa če ostali kandidati sploh niso bili

naslovljeni z vprašanji? Se maksimalna vrednost dovolj razlikuje od

ostalih? Koliko je to »dovolj«? So vsi kandidati bili zajeti v postopku

spraševanja? Če ne, je za neupoštevane sploh mogoče, da so

relevantni? Takšnih vprašanj bi lahko postavili še mnogo. Odločili smo se,

da vektorja C ne vrednotimo na podlagi takšnih parcialnih kriterijev, ki

vrednosti ci neposredno primerjajo, ampak da vrednotimo vektor C v

celoti.

Ena izmed idej izbire vprašanja, na kateri bazira tudi naša končna rešitev

je zgrajena na ideji informacijske entropije iz Shannonove informacijske

teorije (Shannon, 1949). V informacijski teoriji entropija meri nezmožnost

sporočila, da postane vir informacij: več informacij kot nosi sporočilo,

manjša je entropija. Ideja je torej trivialna: izračunati entropijo vektorja C,

tekom dialoga pa izbirati takšna vprašanja, ki bodo vrednost entropije

vektorja C najbolj zmanjšala. Z izbiro vprašanj nadaljujemo, dokler

entropija vektorja C ne doseže neke mejne vrednosti. Pri spraševanju

izbiramo vprašanja, ki entropijo zmanjšajo tudi v najmanj ugodnem

primeru.

Po Shannonovi teoriji se formula za izračun entropije v našem primeru

glasi takole:


· log

Formula Eq2: Izračun entropije vektorja relevantnosti C

Formula deluje po pričakovanjih. Kljub temu da smo s predstavljeno

formulo uspeli voditi dialog, ki je bil krajši od naključnega spraševanja, z

rezultati nismo bili povsem zadovoljni. V vmesnih korakih (pri

»razgibanem« vektorju C) se formula žal ni izkazala za najbolj ustrezno:

izračun entropije je podoben ali izstopa samo en kandidat ali jih izstopa

več. V določenih primerih občutno izboljšanje vektorja C poslabša

entropijo (npr. ci=0.8 za vsak i; 1 kandidat izgubi na relevantnosti, 1 pa

pridobi). Tudi mejo entropije, ki zadošča končnemu odgovoru o

ustreznem vzorcu, je na podlagi splošne formule za entropijo bilo

potrebno določati dinamično: večje število kandidatov tudi občutno

spremeni vrednosti, ki jih formula vrača. Zaradi vseh teh razlogov smo se

odločili izhajati iz ideje o zmanjševanju entropije, vendar namesto

uporabe splošne entropične formule razviti lastno formulo za merjenje

relevantnosti podanega vektorja C kot končnega odgovora. V doktorski

nalogi predstavljamo formulo, ki se tudi dejansko uporablja v končni

rešitvi.

4.5.5 Lastna, na entropiji temelječa mera relevantnosti vektorja

Tudi formulo za izračun lastne mere relevantnost vektorja C smo uskladili s

karakteristikami, katerim zadošča Shannon-ova splošna formula za

izračun informacijske entropije:

• Kontinuiteta: sprememba enega elementa v vektorju mora

povzročiti majhno spremembo entropije.

• Simetrija: spremenjen vrstni red elementov vektorja ne sme

spremeniti vrednosti entropije.

• Maksimum: maksimalno entropijo dosežemo takrat, ko je vrednost

vsakega elementa vektorja naključna z enako verjetnostjo.


• Aditivnost: celotno entropijo vektorja je možno izračunati iz entropij

podvektorjev s predpostavko da poznamo razmerja med

podvektorji.

Kljub temu da lastna mera temelji na teoriji o informacijski entropiji, je ne

bomo imenovali entropija, saj bi tako morebiti nepotrebno zavedli

bralca. Poimenujmo svojo mero »relevantnost vektorja C« in jo označimo

z Rel(C)2. Pred razvojem končne formule za relevantnost naštejmo

zahteve, ki jih (poleg zgoraj naštetih) mora izpolnjevati:

• Za enako vrednost relevantnosti vseh kandidatov (ci je enak za

vsak i) mora Rel(C) biti maksimalna, saj na podlagi takšnega

vektorja ni mogoče sprejeti nikakršnega sklepa o relevantnosti

posameznega kandidata.

• Rel(C) mora biti minimalna, če so vse vrednosti v vektorju C enake

0, razen ene, ki nosi maksimalno vrednost 1.

• Več kandidatov kot nosi vrednost 0.5 (področje »ne vemo«), večja

naj bo vrednost Rel(C).

• Manj kandidatov kot izstopa iz povprečja pomeni manjšo vrednost

Rel(C), saj s tem dobimo več informacij o relevantnosti manj

kandidatov – v idealnem primeru enega samega.

Slika 18 kaže situaciji vektorja C, ki naj imata maksimalno vrednost mere

Rel(C) in minimalno vrednost mere Rel(C). Tudi izračun entropije po

formuli Eq2 (Ent(C)) daje primerljive rezultate.

2 Ker izhajamo iz ideje informacijske entropije, pomeni vrednost Rel(C) pravzaprav nerelevantnost vektorja C: manjše vrednosti pomenijo, da je vektor C bolj relevanten.


Slika 18: Stanje vektorja C z maksimalno in minimalno vrednostjo Rel(C)

Kot je možno razbrati iz prej naštetih kriterijev, mora biti izračun Rel(C)

odvisen od vrednosti maksimalnega elementa, povprečne vrednosti

elementov v vektorju ter števila elementov, ki močno izstopajo v pozitivni

smeri (nad 0.5), saj so ti kandidati zanimivi za končni rezultat. Formula se

glasi takole:

1 ·

Formula Eq3: Izračun relevantnosti vektorja C

V formuli pomeni

• cmax je maksimalna vrednost vektorja C (cmax>=ci za vsak i)

• je povprečna vrednost vektorja C, izračunana kot ∑

• D(C) je faktor, ki zajame napredovanje vektorja relevantnosti; v

tem trenutku predpostavimo da nosi konstantno vrednost 1. Sicer

se vrednosti faktorja D gibljejo v intervalu [0,1].

Teoretično in praktično formula Eq3 deluje veliko bolje od splošne

entropične formule: nudi hiter in konstanten napredek k nizkim

vrednostim Rel(D), izbira bolj smiselna vprašanja.

Ko smo formulo preizkusili na realnih vprašanjih in odgovorih, ki so jih

vnesli eksperti, se je izkazalo, da formula več ne deluje po pričakovanjih.

Formula namreč deluje zelo dobro pri vektorju C, ki že kaže nekaj

napredka (majhno število vrednosti 0.5). Pri posebnih primerih vektorja


(ko npr. izstopa samo 1 kandidat, o ostalih pa še nimamo nikakršne

informacije; ali ko je nek vektor očitno boljši, povprečje in maksimum pa

se ne razlikujeta) se je tudi formula Eq2 izkazala kot šibko. Kot predvideno

so eksperti namreč vnesli vprašanja, ki so povezovala zelo majhno število

kandidatov. Poleg tega smo ugotovili, da je število vprašanj v primerjavi s

številom kandidatov relativno majhno – v povprečju manj kot 2 vprašanji

na kandidata. Pojavita se dve možnosti: sestaviti vprašanja, ki bodo

povezovala veliko število kandidatov ali spremeniti formulo. Prva možnost

se nam ni zdela smiselna, saj je že od vsega začetka bil naš cilj vzpostaviti

voden dialog z neprirejenimi, realnimi podatki. Zato smo se odločili v

originalno formulo Rel(C) vnesti še faktor napredka vektorja C, D(C):

faktor naj bo majhen v začetnih fazah dialoga in zelo blizu vrednosti 1 v

kasnejših fazah dialoga. Tako smo dosegli, da se v začetnih fazah

favorizirajo vprašanja, ki povezujejo veliko število kandidatov, v kasnejših

fazah dialoga pa se favorizirajo vprašanja, ki potrjujejo ali zavračajo

posamezne kandidate. Na nek način torej faktor D omogoča izračun

Rel(C) na takšen način, da najprej postavljamo »groba« vprašanja, v

kasnejših fazah pa sprašujemo bolj ciljno usmerjeno. Izračun faktorja D

smo definirali takole:

4 · 1 3 ·4 · 1

Formula Eq4: Izračun faktorja napredka vektorja C

Kjer pomeni:

• n je število kandidatov

• st(c05) število kandidatov z vrednostjo 0.5 in

• st(cmax) pa število kandidatov z maksimalno vrednostjo.

Poglejmo, kako formula deluje: vektorji z manjšim številom vrednosti 0.5 in

samo enim izstopajočim kandidatom naj imajo manjšo vrednost Rel(C).

Glede na to, da želimo v začetnih fazah čim več kandidatov prestaviti iz

vrednosti 0.5 in šele kasneje profilirati čim manj končnih kandidatov, smo


(na podlagi preizkusov) utežili število nenaslovljenih kandidatov v faktorju

napredka s 75% in s 25% število maksimalnih vrednosti. Največja

teoretično možna efektivna vsota obeh deležev znaša 2(n-1). Utežene

vrednosti st(c05) in st(cmax) sta torej odšteti od največje možne vrednosti,

nato rezultat z njo še delimo. Očitno je torej, da bo faktor napredka

vektorja C D(C) nosil majhne vrednosti v začetnih fazah in vrednosti blizu

1 v končnih fazah (po nekaj zastavljenih vprašanjih) dialoga. Formula Eq3

je okrajšana in poenostavljena; pot do nje je trivialna.

Končna, v rešitvi uporabljena formula za izbiro naslednjega vprašanja je

torej sledeča:

1 ·

4 · 1 3 ·4 · 1

Formula Eq5: Celotna formula za izračun relevantnosti vektorja C

Algoritem na osnovi predstavljenih formul uporabniku postavi vprašanje,

ki bo v vsakem primeru najbolj zmanjšalo vrednost Rel(C) vektorja C.

Formulo smo testirali tako na velikem številu naključnih podatkov, kot tudi

na realnih vprašanjih s strani ekspertov. Na podlagi izvajanja vodenih

dialogov na realnih podatkih smo ugotovili, da vektorji, katerih vrednost

Rel(C) je manjša od 0.45, že nosijo dovolj informacij, da je možno sklepati

o relevantnem kandidatu.

Kot zanimivost podajmo še izračune relevantnosti vektorja C nad

naključnim vektorjem. Ugotovili smo, da je vrednost Rel(C) naključnega

vektorja C s 5000 kandidati 0.509 s standardno deviacijo 0.014 (število

poizkusov N=5000); vrednost Rel(C) naključnega vektorja s 30 kandidati

pa je 0.545 s standardno deviacijo 0.173 (število poizkusov N=5000).

Predstavljena formula torej v celoti zadošča postavljenim kriterijem in je

ustrezna podlaga za algoritem, ki ga predstavljamo v naslednjem

podpoglavju.


4.5.6 Zapis algoritma in izkušnje

Predstavljene okoliščine in izpeljane formule lahko sedaj strnemo v

algoritem, ki na osnovi podanih ločenih vprašanj in odgovorov vodi

dialog z uporabnikom, da bi ugotovil, kateri načrtovalski vzorec naj

uporabi za reševanje problemske situacije. Uporabnik lahko, poleg

popolnoma kontroliranega vodenega dialoga, na podlagi svojega

osebnega mnenja, ob spreminjanju vektorja relevantnosti, sam prekine

algoritem. Na postavljena vprašanja lahko tudi ne odgovori.

kreiraj seznam VPR vseh vprašanj kreiraj seznam P vseh kandidatov #algoritem prejme seznam vseh vprašanj ter seznam kandidatov vodi_dialog(VPR, P)

TRESHHOLD=0.45 kreiraj vektor C, vsak ci=0.5, 1<=i<=n, n=število kandidatov dokler VPR ni prazen

V=izberi_vprašanje(VPR,C) Če (V==prazen) izpiši C, konec odstrani V iz množice VPR shrani uporabnikov odgovor v ODG če (ODG različen od »ne vem«)

kreiraj vektor V_ODG odgovora ODG C=kombiniraj_odgovor_z_vektorjem(C,V_ODG) izpiši C če (uporabnik ne želi nadaljevati) konec če (izračunaj_relevantnost_vektorja(C)< TRESHHOLD) konec

sicer nadaljuj ponovi

konec


#algoritem prejme seznam nezastavljenih vprašanj in vektor relevantnosti #algoritem vrne vprašanje, ki tudi v najneugodnejšem podanem # odgovoru maksimalno zmanjša funkcijo relevantnosti – manjša mera # relevantnosti je bolj ugodna #če več ni vprašanja, ki bi izboljšalo stanje vektorja, ne vrne ničesar izberi_vprašanje(NVPR, TC) vprašanje

kreiraj prazen vektor minimalnih razlik MIN; MIN[i]=1 za vsak i trenutna_relevantnost= izračunaj_relevantnost_vektorja(TC) za vsako vprašanje v množici NVPR

minimalna_razlika=1 za vsak možen odgovor vprašanja

kreiraj vektor odgovora A začasenC=kombiniraj_odgovor_z_vektorjem(TC,A) ustvarjena_razlika= trenutna_relevantnost- izračunaj_relevantnost_vektorja(začasenC) če (ustvarjena_razlika< minimalna_razlika) minimalna_razlika= ustvarjena_razlika

nadaljuj MIN[trenutno vprašanje]= minimalna_razlika

nadaljuj najdi indeks i maksimuma v vektorju MIN če (MIN[i]<0) končaj brez vrnjenega vprašanja vrni vprašanje NVPR[i]

konec #algoritem prejme vektor relevantnosti #algoritem vrne relevantnost vektorja C; 1=vektor ni relevanten izračunaj_relevantnost_vektorja(C) rel

izračunaj napredek vektorja C po formuli 4 · 1 3 ·

4 · 1

izračunaj relevantnost vektorja po formuli 1 ·

vrni Rel konec #algoritem prejme vektor relevantnosti in vektor odgovora #vrne nov vektor relevantnosti kombiniraj_odgovor_z_vektorjem(C,A) nov_C

kreiraj vektor CN; spremeni vrednosti v vektorju CN po formuli

2 ; 0.5 vrni vektor CN

konec


4.5.7 Primerjava algoritma s fiksnim odločitvenim drevesom

Delovanje predstavljenega algoritma smo primerjali s fiksnim

odločitvenim drevesom, sestavljenim s strani eksperta. Za fiksno

odločitveno drevo verjamemo, da vodi dialog optimalno. Odločitveno

drevo poveže 36 vprašanj s 23 kandidati. Možnih poti skozi odločitveno

drevo in s tem tudi število različnih dialogov je 72, od tega 3 poti skozi

drevo ne dajo odgovora (na podlagi dialoga ni možno predlagati

ustreznega vzorca). Število različnih poti ter njihova minimalna in

maksimalna dolžina (število vprašanj) za posamezen vzorec so prikazane

v tabeli 2.


Tabela 2: Število in dolžina dialogov fiksnega odločitvenega drevesa v povezavi s posameznimi vzorci

Načrtovalski vzorec Število poti (različnih dialogov)

Najkrajša pot – število vprašanj

Najdaljša pot – število vprašanj

Dolžine vseh dialogov

Tovarniška metoda 3 4 6 4,4,6 Abstraktna tovarna 2 4 6 4,6 Graditelj 2 2 4 2,4 Prototip 4 4 5 4,4,4,5 Edinec 2 2 4 2,4 Adapter 5 3 7 3,3,5,7,7 Most 2 3 5 3,5 Kompozicija 5 3 7 3,3,4,7,7 Dekorator 4 3 7 3,3,7,7 Fasada 5 3 7 3,3,5,7,7 Namestnik 5 3 7 3,3,5,7,7 Interpreter 4 3 7 3,6,7,7 Predloga metode 2 3 4 3,4 Veriga odgovornosti 2 3 4 3,4 Ukaz 3 3 5 3,3,5 Iterator 2 3 5 3,5 Posrednik 2 3 6 3,6 Spomin 3 4 5 4,4,5 Zrno 2 3 5 3,5 Opazovalec 2 3 3 3,3 Stanje 2 3 4 3,4 Strategija 7 3 7 3,3,4,4,5,7,7 Obiskovalec 2 3 4 3,4

Vzemimo enega najbolj tipičnih načrtovalskih problemov, ko želimo

povezati dva razreda z različnima vmesnikoma, pri čemer vmesnikov ni

potrebno poenostavljati. Ta problem naslavlja vzorec adapter. Primer

tipičnega dialoga pri reševanju omenjenega načrtovalskega problema,

sestavljenega s fiksnim odločitvenim drevesom:

• Sistem: Kaj želite narediti?

Uporabnik izbere: Ne vem, prosim za več možnosti.


Uporabnik izbere: Razdeliti sistem na več delov.

• Sistem: Kakšno razdelitev želite imeti v sistemu?

Uporabnik izbere: Po nivojih: z vmesnikom in ločeno

implementacijo.

• Sistem: So vmesniki, s katerimi morate biti skladni že določeni?

Uporabnik izbere: Da.


• Sistem: Kako bi radi povezali obstoječe objekte z vmesniki?

Uporabnik izbere: Na ciljni razred se bom povezal preko lastnega

vmesnika.

• Sistem: Uporabite vzorec »Adapter«

Tudi naš algoritem izbira vprašanja izmed 36 možnih, iščemo kandidata

med 23 možnostmi. Poglejmo si primer dialoga za opisan načrtovalski

problem, vodenega s predhodno opisanim algoritmom:

• Sistem: Želite spremeniti način uporabe obstoječih funkcionalnosti

v vašem razredu?

Uporabnik izbere: Ne.

• Sistem: Katere aspekte obnašanja vašega sistema želite

spremeniti?

Uporabnik izbere: Način komunikacije objektov.


Uporabnik izbere: Definirati ali spremeniti strukturo arhitekture

razredov.

• Sistem: Kako se nameravate povezati z vmesnikom obstoječega

razreda?

Uporabnik izbere: Povezal se bom preko svojega lastnega

vmesnika, ki je drugačen od ciljnega vmesnika.

• Sistem: Imate opravka z več metodami, ki morajo biti izbrane v

času izvajanja programa?


• Sistem: Ali si kreirani razredi delijo podobno obnašanje?

Uporabnik izbere: Da.

• Sistem: Želite imeti možnost vračanja v prejšnje stanje objektov?


• Sistem: Na kakšen način želite delati z različnimi razredi v času

kreiranja objektov?

Uporabnik izbere: Kreirati želim enostavne objekte.


• Sistem: Želite, da se zbirka objektov odziva na spremembo enega

objekta?


• Sistem: Uporabite vzorec »Adapter«

V predstavljenem dialogu je uporabnik podal 9 odgovorov, na 2

vprašanji ni odgovoril. Predstavljen dialog se ni zaključil na podlagi

dosežene mejne relevantnosti (dosežena je vrednost 0.73), temveč na

podlagi izčrpanja zbirke možnih vprašanj – algoritem ni več našel

vprašanja, ki bi zagotovo zmanjšalo vrednost relevantnosti. Uporabnik bi

lahko dialog prekinil že predčasno, saj je vzorec »adapter« vidno izstopal

že po podanem 6. odgovoru.

Tudi sicer so po naših izkušnjah dialogi, gnani z našim algoritmom, dolgi

med 7 in 10 vprašanj, pri čemer uporabnik izpusti do 3 vprašanja. Dialog

se tipično zaključi tako na podlagi dosežene mejne vrednosti kot tudi

izčrpanja množice vprašanj. Menimo, da bi večje število vprašanj stanje

še izboljšalo.

Če primerjamo delovanje lastnega algoritma s pristopom, kjer izbiramo

naključna vprašanja, ugotovimo, da lasten pristop deluje bistveno bolje.

Pri naključno podanih odgovorih je v povprečju potrebno odgovoriti na

vsaj 12 vprašanj, pri čemer na vsaj 10 vprašanj uporabnik ne more podati

odgovora (dogovori: »Ne vem«).

Lasten algoritem torej deluje bolje od naključnega izbora vprašanj. Do

določene mere se uspe celo približati s strani eksperta sestavljenemu

statičnemu odločitvenemu drevesu, ki poganja dialog. Čeprav se je

izkazalo, da na podlagi trenutnega nabora vprašanj dialogi z vidika

razvijalca niso vedno sestavljeni z vprašanji v najbolj smiselnem

zaporedju, pa se je izkazalo tudi, da kljub temu na podlagi podanih

odgovorov algoritem zbere dovolj informacij o uporabnikovem

načrtovalskem problemu.


5. Metodologija uporabe načrtovalskih vzorcev in

podporna platforma

V tem poglavju predlagamo način uporabe v prejšnjih poglavjih

predstavljenih pristopov, tako z vidika ekspertov s področja načrtovalskih

vzorcev kot tudi razvijalcev. Predstavimo tudi platformo, ki smo jo

implementirali z namenom prototipne podpore predlagane

metodologije.

Jedro metodologije je shematsko predstavljeno na sliki 18.

Slika 18: Shematska predstavitev predlagane metodologije


Metodologija pri vnosu podatkov o vzorcih ter znanja o njih vključuje

eksperte s tega področja. Takšen repozitorij formalno predstavljenega

znanja je uporabljen v postopku izpraševanja razvijalca. Le-ta na podlagi

odgovorov podaja informacijo o problemski situaciji. Na podlagi tega v

poglavju 4.5 opisan algoritem izbere najverjetnejše kandidate za rešitev

podane problemske situacije.

5.1 Metodologija in zahteve platforme z vidika avtorjev vzorcev

V poglavju 3 (»Sorodna dela«) smo predstavili poizkuse drugih avtorjev pri

izboljšanju izbire ustreznih načrtovalskih vzorcev. Avtorji temeljijo na že v

osnovi drugačnih lastnih notacijah in postopkih. Pri večini avtorjev

zasledimo (npr. Burke, 2002) potrebo po korenito večji intervenciji

uporabnikov v primerjavi z neuporabo predlaganih rešitev. Menimo, da

veliko obremenjevanje avtorjev načrtovalskih vzorcev z vnosom in

vzdrževanjem ekspertnega znanja, ki ga takšen sistem potrebuje, vpliva

negativno na sprejetost predlaganega sistema. Zato predlagamo

preprost in nevsiljiv način uporabe našega sistema z vidika ekspertov.

Povzema ga proces, predstavljen na sliki 19.

V primeru, da ekspert želi vstaviti nov, parcialen ekspertni nasvet v sistem,

uporabi le tri nove aktivnosti: zapis vprašanj, možnih odgovorov in njihovo

povezovanje z morebitnimi kandidati. Ne predvidevamo, da bi eksperti

takšno znanje morali v prihodnosti vzdrževati ali ga celo medsebojno

povezovati v dialoge, matrike, odločitvena drevesa ipd. Na podlagi

vstavljenega nasveta naš sistem to naredi samodejno.


Slika 19: BPMN diagram z vidika eksperta

Iz slike 19 je razvidno tudi, da v primeru, ko nek vzorec še ni vstavljen v

sistem, predvidevamo tudi preprost vpis vzorca, njegovo povezovanje z

ostalimi vzorci in umestitev v vsebnik(e). Na takšen način lahko razvijalci

nov vzorec najdejo tudi sami, brez uporabe inteligentne komponente za

predlaganje ustreznega vzorca.

5.2 Metodologija in zahteve platforme z vidika razvijalcev

Tudi z vidika razvijalcev predlagamo podobno metodologijo, kot je že v

uporabi (Gamma et. al., 1995). Predstavljena je na sliki 20.

Ob identifikaciji načrtovalskega problema uporabniki na osnovi izkušenj

poiščejo vzorce s pomočjo brskanja po tiskanih ali elektronskih katalogih

vzorcev. Pomagajo si lahko tudi z iskanjem po ključnih besedah. V

primeru, da najdejo ustrezen načrtovalski vzorec, ga uporabijo, sicer

morajo načrtovalski problem nasloviti samostojno.


Slika 20: BPMN diagram z vidika razvijalca

Naša metodologija predstavlja nadgradnjo v fazi iskanja ustreznega

načrtovalskega vzorca, kjer predvidevamo opcijsko uporabo vodenega

dialoga.

5.3 Opis funkcionalnosti platforme

Lastna prototipna implementacija repozitorija načrtovalskih vzorcev,

temelječega na predstavljeni formalni metodi zapisa s pomočjo

ontologije, se imenuje OBDPR (Ontology-Based Design Pattern

Repository). Repozitorij je zasnovan tako, da ni le repozitorij vzorcev,

temveč je platforma, na osnovi katere lahko gradimo inteligentne

storitve, ki omogočajo boljšo uporabo načrtovalskih vzorcev. Osnova

platformi so tehnologije semantičnega spleta. Repozitorij že sam po sebi

poleg integriranja znanja iz raznovrstnih podatkovnih virov (integrira

podatke z uveljavljenih katalogov, spleta, wikipedije ipd.) in upravljanja

tega znanja, omogoča mnoge dodatne storitve:

• Omogoča, da eksperti obstoječe opise načrtovalskih vzorcev

opremijo z dodatnim znanjem.

• Integrira podatke iz svetovnega spleta in dodatnih podatkovnih

virov.


• Transformira podatke, zapisane v jeziku RDF v uporabniško prijazno

obliko.

• Vodi indeks besed, uporabljenih v repozitoriju in dodatnih

podatkovnih virih z namenom zagotoviti možnost iskanja s

pomočjo ključnih besed.

• Ponuja vse podatke v surovi RDF obliki, kar lahko s pridom izkoristijo

dodatne storitve, zgrajene na platformi.

• Vodi zbirko primerov iz realnega sveta ki služijo na eni strani

treningu razvijalcev na drugi strani pa lažjemu iskanju vzorcev.

Na sliki 21 je predstavljena arhitektura implementiranega prototipa

repozitorija načrtovalskih vzorcev.

Slika 21: Arhitektura prototipnega repozitorija vzorcev


Prototipna implementacija vsebuje vse zgoraj naštete funkcionalnosti,

poleg njih pa uvaja že 3 storitve, ki tečejo na predstavljeni platformi:

• možnost uporabe iskanja po celotnem besedilu (ne indeksiramo

samo lokalnih podatkov, temveč tudi podatke s svetovnega

spleta kot so drugi repozitoriji načrtovalskih vzorcev in

enciklopedije (npr. wikipedia)),

• uporabo storitve predlaganja vzorca s pomočjo vprašanj in

odgovorov,

• storitev treninga neizkušenih razvijalcev, kjer se uporabljajo primeri

iz realnega sveta.

Prototipna implementacija vsebuje vse vzorce katalogov GoF (Gamma

et. al., 1995) in J2EE (Deepak, 2001). Repozitorij ni zaprt za morebitne

druge kataloge vzorcev, je pa takšen repozitorij že dovolj bogat, da

omogoča preizkušanje in testiranje v praksi, kajti avtorji (Gamma et. al.,

1995) so ugotovili, da so repozitoriji takšne velikosti že problematični z

vidika iskanja vzorcev.

Osnova platformi je v 4. poglavju predstavljena lastna formalna notacija

načrtovalskih vzorcev in ekspertnega znanja o njih.

Tehnološka osnova repozitoriju sta platforma JavaEE in knjižnica

Jena(http://jena.sourceforge.net/), ki omogoča delo s tehnologijami

semantičnega spleta (RDF, OWL, SPARQL). Na osnovi platforme JavaEE

so enostavno dosežene tudi nefunkcionalne zahteve platforme OBDPR

kot so nadzorovano okolje, transkacijsko obnašanje in varnost. Platforma

pozna 6 varnostnih nivojev:

• brskanje po podatkih,

• urejanje vprašanj,

• uporaba brez omejitev,

• eksperiment,

• eksperiment – iskanje in

• eksperiment – predlaganje.


Posamezni uporabniki imajo pravico uporabe platforme v določenih

varnostnih nivojih.

Nivo brskanja po podatkih omogoča pregled surovih RDF/OWL

podatkov ter poganjanje SPARQL poizvedb. Uporabnik lahko tudi brska

po vsebnikih, vzorcih in vprašanjih ter poganja storitvi iskanja po besedilu

in predlaganja vzorca.

Nivo urejanja vprašanj poleg pravic nivoja brskanja omogoča še

dodajanje in urejanje vprašanj, možnih odgovorov in povezav s

kandidati.

Nivo uporabe brez omejitev uporabniku omogoča upravljanje in pregled

vseh podatkov, poleg tega pa so dostopne še določene operativne

funkcionalnosti kot so osveževanje indeksa iskalnih besed, zagon in

ustavitev eksperimenta, pregled rezultatov eksperimentov z možnostjo

samodejnega preverjanja pravilnosti odgovorov in analiz pravilnosti po

nalogah in kandidatih.

Varnostni nivoji, namenjeni eksperimentu, omogočajo uporabo zgolj

okolja znotraj eksperimenta, uporabo storitev brskanja po podatkih in

iskanja s ključnimi besedami ali pa uporabo vodenega dialoga.

Slika 22 prikazuje pregled surovih RDF/OWL podatkov; platforma OBDPR

omogoča tudi enostavno navigacijo po semantični mreži s pomočjo

povezav.


Slika 22: Pregled surovih RDF podatkov

Slika 23 prikazuje uporabniško prijazen ogled načrtovalskih vzorcev, ki

vsebuje tudi opis vzorca, pridobljen iz internetnih virov – predvsem

Wikipedie. Ob levi strani ima uporabnik možnost brskati tudi po vsebnikih.

Slika 23: Uporabniško prijazen pogled na vzorec


Slika 24 prikazuje podoben prikaz kot slika 23, le da tokrat prikazujemo

vsebnik vzorcev.

Slika 24: Uporabniško prijazen pogled na vsebnik

Slika 25 prikazuje uporabniško prijazen urejevalnik vprašanj, kjer ekspert

nivo relevantnosti nastavlja s premikanjem drsnikov.

Slika 25: Urejanje vprašanj in odgovorov


Slika 26 prikazuje izsek strani, ki omogoča hiter pregled vprašanj.

Vprašanja in odgovore je možno pregledovati tudi glede posameznih

kandidatov (prikaz zgolj vprašanj, ki se nanašajo na izbranega

kandidata).

Slika 26: Pregled vprašanj in odgovorov

5.4 Opis dodatnih modulov

5.4.1 Modul za iskanje vzorcev

Iskanje vzorcev na osnovi ključnih besed je ena temeljnih funkcionalnosti

platforme OBDPR. Realizirana je s pomočjo knjižnice Apache Lucene

(http://lucene.apache.org). Le-ta omogoča vodenje seznama ključnih

besed, povezanih z viri. Tako v procesu, ki kreira indeks ključnih besed, z

vzorci povezujemo ključne besede, najdene v semantični mreži. Proces

indeksira tudi spletne strani, na katere kažejo povezave v opisu vzorcev

oz. vsebnikov. Pri vzorcu »adapter« je npr. avtor navedel, da so

podrobne informacije o tem vzorcu na voljo na »wikipediji« in v


elektronski knjigi GoF, zato se tudi ključne besede, najdene na teh

spletnih straneh povežejo z vzorcem »adapter«.

Knjižnica Apache Lucene omogoča pridobivanje povezanih virov na

osnovi ključnih besed. Primer takšnega iskanja je prikazan na sliki 27.

Slika 27: Uporaba iskanja s pomočjo ključnih besed

5.4.2 Modul za predlaganje primernih vzorcev

Algoritem, opisan v poglavju 4.5, je implementiran znotraj modula za

predlaganje primernih vzorcev. Ker smo poleg lastnega preizkušali še

druge strategije vodenega dialoga (statično drevo vprašanj in

odgovorov, naključna vprašanja, vsa vprašanja, vodenje na osnovi

entropije, vodenje na osnovi mere relevantnosti), smo znotraj modula

implementirali vse omenjene strategije. Izbiro strategije, ki se bo dejansko

uporabljala tekom vodenega dialoga, je možno določiti tudi v času

izvajanja platforme OBDPR. Da smo to dosegli, smo uporabili GoF vzorec

»strategija«. Na takšen način smo omogočili tudi morebitno prihodnje

eksperimentiranje z drugačnimi postopki izbire vprašanj.


Vsak algoritem vodenega dialoga mora implementirati poseben

vmesnik, ki se uporablja v postopku vodenega dialoga:

public interface ProposeStrategy { String getStrategyName(); void postAnswer(Question q, Answer a); Question getNextQuestion(); Question getCurrentQuestion(); Map<String, Double> getCurrentSolutions(); List<ProposeActionStateItem> getHistory(); void returnToHistory(String questionURIHash); int getAnswersGivenCount(); boolean canQuestionBeSkipped(); boolean isUndoSupported(); String getStrategyUserInfo();

}

Metoda »getStrategyName« vrača ime strategije, kot se pojavi na

uporabniškem vmesniku. Metodi »getNextQuestion« in

»getCurrentQuestion« sta namenjeni pridobivanju naslednjega vprašanja

in trenutnega še ne odgovorjenega vprašanja. Metodo »postAnswer«

pokliče modul takrat, ko uporabnik na določeno vprašanje poda

odgovor. Metoda »getCurrentSolutions« je namenjena spremljanju

trenutnega stanja kandidatov – relevantnosti kandidatov glede na potek

dialoga. Metoda »getHistory« vrača vsa vprašanja in podane odgovore,

metoda »returnToHistory« pa je poklicana, ko želi uporabnik ponovno

odgovarjati na že odgovorjeno vprašanje. Predvidevamo, da določene

metode ne bodo omogočale vračanja v zgodovino, kar pove metoda

»isUndoSupported«. Metoda »canQuestionBeSkipped« pove, če

strategija omogoča ignoriranje postavljenega vprašanja. Strategija, ki je

vodena s statičnim drevesom npr. tega ne omogoča. Metodi

»getAnswersGivenCount« in »getStrategyUserInfo« sta namenjeni

prikazovanju uporabniško zanimivih podatkov na uporabniškem

vmesniku: npr. število podanih odgovorov, število ignoriranih vprašanj,

trenutna vrednost formule relevantnosti vektorja ipd.

Primer poteka dialoga prikazuje slika 28.


Slika 28: Uporaba storitve predlaganja vzorca

5.4.3 Modul za trening in eksperiment

Celoten eksperiment je potekal s pomočjo posebej razvitega modula v

platformi OBDPR (slika 29). Kot takšno, omogoča okolje tudi izvajanje

eksperimenta preko lokalnega omrežja in interneta.

Slika 29: Okolje, namenjeno poteku eksperimenta

Modul razdeli okno brskalnika na 2 dela: v zgornjem delu kandidati

rešujejo ankete in podajajo odgovore na zastavljene načrtovalske


probleme. V spodnjem delu okna pa glede na fazo eksperimenta lahko

uporabljajo v tistem trenutku dostopne funkcionalnosti. Vsi podatki o

odgovorih in aktivnostih uporabnika se beležijo in so ob ustreznem

varnostnem nivoju na voljo.

5.5 Študija primera: uporaba metodologije in platforme pri

reševanju konkretnega problema

Z namenom ilustracije preprostosti uporabe naše metodologije in

platforme OBDPR v tem poglavju predstavljamo realne načrtovalske

probleme in pozitivno vlogo platforme OBDPR pri reševanju le-teh.

Primer ekspertnega uporabnika A:

Uporabnik se sreča z načrtovalskim problemom integracije

komunikacijske komponente v svojo rešitev. Komponenta omogoča

pošiljanje e-pošte z naslednjimi metodami: nastaviStrežnik,

kreirajSporočilo, pošljiSporočilo.

Predhodno je razvijalec A uporabljal lastno rešitev, ki je bila tej na las

podobna. Uporabljal je razred, poimenovan Posiljatelj, z metodami

nastaviPosiljanje, dobiBesedilo, poslji. Ker gre za izkušenega uporabnika,

je na podlagi znanja in izkušenj uporabil vzorec »adapter« ter na takšen

način novo, boljšo komponento integriral s svojim sistemom, ne da bi le

tega bistveno spreminjal.

Hkrati je uporabnik A začel razvijati nek drug sistem, kjer prav tako

potrebuje pošiljanje elektronskih sporočil. Ker si je želel poenostaviti delo,

je za pošiljanje predvidel le eno metodo: pošlji. Metoda prejme sporočilo

skupaj z vsemi potrebnimi podatki o strežnikih, avtorizaciji ipd. Glede na

to, da se je nova komponenta za pošiljanje elektronskih sporočil v prvi

rešitvi obnesla zadovoljivo, jo je želel vključiti tudi v novo nastajajočo

rešitev. Glede na izkušnje je komunikacijsko komponento tokrat vključil s


pomočjo vzorca fasada, saj dostopa do komponente na poenostavljen

način.

Ti dve sveži izkušnji sta v razvijalcu porodili dva nasveta glede uporabe

načrtovalskih vzorcev, ki jih je v obliki vprašanj in odgovorov vstavil v

platformo OBDPR:

1. vprašanje:

Želite do obstoječe komponente dostopati s poenostavljenim

vmesnikom?

• Ne: adapter(relevantnost 1.0), fasada (relevantnost 0.0)

• Da: adapter(relevantnost 0.0), fasada (relevantnost 1.0)

2. vprašanje:

Želite spremeniti način uporabe obstoječih funkcionalnosti vašega

razreda?

• Ne: adapter(relevantnost 1.0), fasada (relevantnost 0.0)

• Da: adapter(relevantnost 0.0), fasada (relevantnost 1.0)

Primer ekspertnega uporabnika B:

Tudi ekspertni uporabnik B razvija novo informacijsko rešitev. Razvoja se je

lotil komponentno: vsak del sistema razvija ločeno v obliki komponente,

ki jih bo kasneje integriral v celoto. Glede na to, da gre za ekspertnega

uporabnika, mu uporaba vzorcev ne bo predstavljala težav. Pri

razmisleku o vzorcih, ki jih bo uporabil, se je domislil zanimivega nasveta

za manj izkušene razvijalce in ga je v obliki vprašanja in možnih

odgovorov vstavil v platformo OBDPR.

3. vprašanje:

Kakšno vrsto razdelitve želite vpeljati v vaš sistem?

• po nivojih: z vmesnikom in ločeno implementacijo: namestnik

(relevantnost 0.69), fasada (relevantnost 0.85), most (relevantnost

0.7), adapter (relevantnost 0.65), mediator (relevantnost 0.7)


• po delih, ki jih obdelujem ločeno: iterator (relevantnost 0.9)

• po delih, pri čemer so vsi deli obveščeni o spremembi v enem

delu: opazovalec (relevantnost 1.0)

Primer razvijalca C:

Razvijalec C ima manj izkušenj iz uporabe načrtovalskih vzorcev, čeprav

se zaveda njihovega pomena. Piše povsem običajno spletno aplikacijo

za vodenje seznama opravil. Aplikacija se preko vmesnika JDBC poveže

na podatkovno bazo, kjer poizveduje po podatkih in zapisuje nove.

Povezovanje s podatkovno bazo je razvil v ločenem razredu

PovezavaNaBazo, kjer s pomočjo atributov določi pot do podatkovne

baze ter uporabniško ime in geslo za dostop. Metodi dobiPovezavo in

zapriPovezavo pa uporablja z namenom povezovanja in sproščanja

povezav s podatkovno bazo.

Po začetnih uspehih se je rešitev uveljavila med znanci: veliko število

uporabnikov je začelo hkrati uporabljati aplikacijo. Zaradi tega je

nastopil problem pri velikem številu hkrati odprtih povezav do

podatkovne baze, ki je vsakodnevno povzročal izpad aplikacije. S

pomočjo platforme OBDPR je razvijalec C iskal rešitev, ki bi omogočala

velikemu številu uporabnikom hkrati dostopati do ene podatkovne baze.

Že prvi zadetek pri iskanju s pomočjo ključne besede »database

connection« je ponudil J2EE vzorec »Data Access Object«. V opisu

vzorca je predstavljen tudi koncept bazena povezav, ki rešuje natančno

ta problem, na katerega je naletel uporabnik. Na spletu je razvijalec C

poiskal enega izmed številnih prosto dostopnih implementacij bazena

povezav. Dobljen bazen povezav ne vsebuje izvorne kode; kot takega

ga ni mogoče spreminjati. Predpisuje pa vmesnik z dvema metodama:

getConnection, returnConnection. Glede na to, da razvijalec C ni želel

bistveno spreminjati svoje rešitve, je s pomočjo platforme OBDPR iskal

možnost enostavne integracije takšnega gradnika v obstoječo

aplikacijo. S pomočjo vodenega dialoga, ki je v celoti predstavljen v


poglavju 4.5.7, je ugotovil da njegov načrtovalski problem elegantno reši

vzorec »adapter«. V dialogu so nastopala tudi vprašanja, ki sta ju

prispevala razvijalec A in razvijalec B. Razvijalec C je tako med nov

bazen povezav in svoj razred PovezavaNaBazo vstavil adapter in

elegantno, tako rekoč brez popravkov originalne aplikacije, rešil problem

preobremenitve podatkovnega strežnika.

Predstavljen primer demonstrira, kako je mogoče, s sicer ločenimi

načrtovalskimi nasveti, omogočiti enostavno iskanje vzorcev, ki uspešno

naslovijo načrtovalske probleme. Čeprav načrtovalski problemi

razvijalcev A, B in C na prvi pogled nimajo veliko skupnega, pa nasveti

razvijalcev A in B odločilno pomagajo pri iskanju ustreznega vzorca za

naslovitev načrtovalskega problema razvijalca C.


6. Izvedba raziskave

V poglavju 2.3 smo opisali, na kakšen način bomo preverili pravilnost v

poglavju 2.1 postavljenih hipotez. Tukaj opisujemo empirično raziskavo, s

pomočjo katere smo želeli preveriti vzročno-posledično povezavo med

neodvisno in odvisnimi spremenljivkami (Slika 30). Udeležencem

eksperimenta smo dali na voljo različno stopnjo podpore pri izbiri

načrtovalskega vzorca, ki jim reši podani načrtovalski problem, pri tem

pa smo merili njihovo učinkovitost. Omejili smo se na pravilnost reševanja,

potreben čas ter tudi na njihovo zadovoljstvo ob uporabi naše

informacijske podpore.

Slika 30: Empirično raziskovanje povezave med odvisnimi in neodvisno spremenljivko

6.1 Načrtovanje eksperimenta

Eksperiment smo zasnovali tako, da je potekal v 5 fazah (Slika 31).


V 1. fazi so kandidati rešili anketo, iz katere smo lahko izluščili njihov profil.

Pri analizi rezultatov smo kandidate na osnovi te ankete razdelili v dve

skupini: manj in bolj izkušene razvijalce.

V naslednji fazi smo razvijalcem predstavili preproste načrtovalske

probleme. Naloga kandidatov je bila, podati odgovor o tem, kateri

načrtovalski vzorec po njihovem mnenju reši podan problem. Pri tem so

imeli različne stopnje podpore:

• V 2. fazi eksperimenta nismo udeležencem dovolili uporabljati

nobene dodane podpore; želeli smo, da problem naslovijo

popolnoma na osnovi svojega znanja in dosedanjih izkušenj.

• V 3. fazi eksperimenta smo udeležencem dovolili uporabljati vse

pripomočke, ki jih uporabljajo tudi sicer. Pri tem smo še posebej

izpostavili možnost uporabe storitve iskanja po celotnem besedilu

znotraj OBDPR. Poleg našega iskalnika, ki indeksira podatke v

OBDPR, kakor tudi povezane zunanje vire na spletu (wikipedia, Sun

blueprints, dofactory ipd.), smo uporabnikom dovolili uporabo

globalnih iskalnikov, kot je Google.

• V 4. fazi eksperimenta so kandidati kot pomoč pri reševanju

načrtovalskih problemov uporabljali storitev vodenega dialoga

naše platforme.

Po rešitvi nalog so udeleženci eksperimenta rešili še anketo, ki je podala

njihove vtise o koristi vodenega dialoga glede na ostale možnosti.

Slika 31: potek eksperimenta


V vseh treh fazah so udeleženci reševali iste naloge. Naloge so bile

kratke, jedrnate in po mnenju ekspertov dovolj očitno rešljive le z enim

načrtovalskim vzorcem. Prav tako udeleženci nalog predhodno niso

poznali. Pripravili smo 21 takšnih nalog. Udeleženci so reševali njihovo

podmnožico, saj bi zahteva po reševanju vseh 21 problemov, po našem

mnenju, vplivala negativno zaradi posledične utrujenosti in slabše

koncentracije udeležencev. Rešitve nalog smo omejili na naslednje

načrtovalske vzorce:

• 5x adapter,

• 2x most,

• 2x graditelj,

• 2x zrno,

• 1x ukaz ali spomin (oba odgovora sta bila pravilna),

• 1x dekorator,

• 1x fasada,

• 1x interpreter,

• 1x iterator,

• 1x opazovalec,

• 1x prototip,

• 1x strategija,

• 1x predloga metode,

• 1x obiskovalec.

Ker smo z eksperimentom želeli tudi globalno nasloviti razvijalce, smo

naloge in ankete pripravili v angleškem jeziku. Predpogoj udeležbe je

torej bil tekoče znanje angleškega jezika.

Da reševanje nalog v posamezni fazi ni vplivalo na rezultate naslednje

faze, smo poskrbeli tako, da med kandidati med posameznimi fazami ni

bilo komunikacije: reševanje je potekalo povsem individualno. Da bi

morebitne vplive prejšnjih faz eksperimenta na rezultate tudi uspešno


zaznali, smo uvedli kontrolno skupino. Potek eksperimenta kontrolne

skupine je prikazan na sliki 32.

Slika 32: potek eksperimenta kontrolne skupine

Kontrolna skupina je načrtovalske probleme reševala neposredno in

samo z uporabo vodenega dialoga v naši platformi. Če bi se rezultati

kontrolne skupine statistično signifikantno razlikovali od rezultatov 4. faze

običajnega eksperimenta, bi to pomenilo, da podatki eksperimenta niso

relevantni zaradi medsebojnih vplivov med posameznimi fazami

eksperimenta.

6.2 Izvedba ankete pred eksperimentom

Pred eksperimentom smo med udeleženci izvedli anketo. Namen ankete

je bil pridobiti informacije o obstoječem znanju in izkušnjah udeležencev,

kot to mislijo sami. Na tak način smo v kasnejši analizi podatkov lahko

ločili bolj izkušene razvijalce od tistih, ki imajo manj izkušenj. Na podlagi

tega smo lahko ugotovili tudi dodatne sklepe, kot recimo kako so koristi

našega sistema povezane s preteklimi izkušnjami.

Anketa je zajela osebne podatke in podatke o izkušnjah. Struktura

ankete:

• Osebni podatki:

o Ime, priimek, e-pošta,

o Največkrat uporabljan programski jezik, možnosti:


Java / C++ / C# / C / Delphi/Pascal / VisualBasic.Net

/ VisualBasic / Smalltalk / Ruby / Groovy / Python /

Drugo / Ne uporabljam programskih jezikov

o Največ uporabljano razvojno okolje, možnosti:

Eclipse / NetBeans / JBuilder / JDeveloper / Rational

Application Developer / Drugo okolje, ki temelji na

platformi Eclipse / Delphi / C++ Builder / KDevelop /

C# Builder / Visual Studio / Visual Studio.Net / Drugo /

Ne uporabljam razvojnega okolja

o Vloga v organizaciji, možnosti:

Študent / Inženir/razvijalec / Vodstven kader/vodja

projektov / Vodja službe za avtomatsko obdelavo

podatkov / Raziskovalec / Uprava podjetja / IT

strokovnjak / Drugo

• Izkušnje

o Poznavanje načrtovalskih vzorcev, lestvica:

0=kaj so to načrtovalski vzorci?

1=sem slišal…

2=šibko

3=srednje

4=dobro

5=sem ekspert s področja načrtovalskih vzorcev

o Poznavanje GoF načrtovalskih vzorcev, lestvica:

0=kaj so to GoF načrtovalski vzorci?

1=sem slišal…

2=šibko

3=srednje

4=dobro

5=sem ekspert s področja GoF načrtovalskih vzorcev

o Koliko let izkušenj pri razvoju programske opreme imate?


o Pogostost uporabe načrtovalskih vzorcev, lestvica:

0=Nikoli

1=redko

2=pogosto

3=dnevno

o Katere načrtovalske vzorce uporabljate najpogosteje?

o Kakšno vrsto podpore uporabljate pri iskanju opisov


6.3 Izvedba ankete po eksperimentu

Udeleženci so tudi po eksperimentu sodelovali v anketi, ki je zajela

podatke o zadovoljstvu uporabnikov ob uporabi našega sistema. Na tak

način smo poleg eksaktnih podatkov o pravilnosti in hitrosti reševanja

načrtovalskih problemov dobili še podatke o zadovoljstvu razvijalcev ob

uporabi našega sistema.

Struktura ankete:

• Se vam je zdela storitev svetovanja uporabna, ko ste iskali rešitev

načrtovalskega problema? Možnosti:

o Takšno storitev želim uporabljati pri vsakodnevnem razvoju.

o Storitev je zelo pomagala.

o Storitev je pomagala.

o Ne morem se odločiti.

o Storitev ni zelo pomagala.

o Storitev sploh ni pomagala.

• Z orodjem in storitvijo predlaganja sem lahko identificiral:

o Veliko več načrtovalskih vzorcev

o Več načrtovalskih vzorcev

o V določenih primerih sem lahko identificiral vzorec

o Nič več vzorcev kot brez orodja


o Manj vzorcev kot brez orodja

o Veliko manj vzorcev kot brez orodja.

• Želite biti obveščeni, ko bo sistem javno objavljen na spletu?

o Da / Ne

• Želite sodelovati kot ekspert pri urejanju ekspertnega znanja o

vzorcih?

o Da / Ne

• Želite biti obveščeni o rezultatih raziskave?

o Da / Ne

6.4 Predstavitev rezultatov eksperimenta in anket

Eksperiment smo izvedli štirikrat v obdobju december 2008 – maj 2009.

Kandidati so bili študentje 4. letnika univerzitetnega študijskega progama

»Računalništvo in informatika«, študentje 2. letnika programa »Informatika

in tehnologije komuniciranja« s končanim predmetom »Arhitekture in

vzorci«, podiplomski študentje pri predmetu »Ponovna uporaba pri

razvoju informacijskih sistemov« ter razvijalci z večletnimi izkušnjami pri

razvoju programske opreme pri partnerskih podjetjih. Eksperimenta se je

udeležilo 64 kandidatov; od tega jih je 40 sodelovalo v celotnem

eksperimentu, 24 kandidatov pa je predstavljalo kontrolno skupino.

Za izvedbo eksperimenta smo pripravili 21 nalog s strukturo rešitev, kot je

predstavljena v poglavju 6.1.

Analizo tako pridobljenih podatkov smo izvajali ločeno po treh skupinah:

• Skupna 1: Manj izkušeni razvijalci

• Skupina 2: Bolj izkušeni razvijalci

• Skupina 3: Kontrolna skupina

Skupina 1 zajema 22 kandidatov, skupina 2 zajema 16 kandidatov,

skupina 3 pa 21 kandidatov. Iz analize smo umaknili 5 kandidatov, ki so

odgovorili pravilno le na 1 ali 0 zastavljenih nalog.


Iz analize smo umaknili tudi 2 nalogi, torej smo pri obdelavi podatkov

zajeli 19 nalog. Ene naloge ni nihče odgovoril pravilno – ocenjujemo, da

smo jo slabo zastavili; drugo nalogo pa so pravilno rešili vsi udeleženci –

očitno je bila vendarle preveč trivialna.

6.4.1 Profili udeležencev po skupinah

Profile udeležencev po treh skupinah predstavlja tabela 3.


Tabela 3: Profili udeležencev eksperimenta po skupinah

Skupina 1 (manj izkušeni razvijalci)

Skupina 2 (bolj izkušeni razvijalci)

Skupina 3 (kontrolna skupina)

Število kandidatov 22 16 21 Vloga v organizaciji

Študentje: 22 Razvijalci: 5 vodja razvija: 1 Študentje: 10

Razvijalci: 10 Študentje: 11

Število let izkušenj pri razvoju programske opreme

Povprečno: 1,25 let (standardna deviacija: 1,5) 1x4 leta 4x3 leta 1x2 leti 2x1 leto ostali: 0 let

Povprečno: 5,3 let (standardna deviacija: 1,8; minimalno: 3 leta; maksimalno: 10 let)

Povprečno: 4,8 let (standardna deviacija: 2,85)

Uporaba načrtovalskih vzorcev

4x nikoli 9x redko 2x pogosto 7x niso podali odgovora

1x nikoli 11x redko 4x pogosto

3x nikoli 12x redko 6x pogosto

Poznavanje načrtovalskih vzorcev (0 najslabše – 5 ekspert)

Povprečno: 1,82 (standardna deviacija: 1,26)



Poznavanje GoF načrtovalskih vzorcev (0 najslabše – 5 ekspert)




Največkrat uporabljeni vzorci

14 odgovorov: adapter (7), edinec (6), iterator (5), opazovalec (4), fasada (2), graditelj, strategija, dekorator, namestnik, kompozicija

2 odgovora: adapter(2), iterator, opazovalec, fasada

15 odgovorov: adapter (8), edinec (9), iterator (2), opazovalec (2), fasada (3), strategija

Največkrat uporabljen vir podatkov o vzorcih

12 odgovorov: Google (10), wiki (8), knjige(4)

2 odgovora: Google (2), wiki, dofactory

7 odgovorov: Google(7), wiki(2)

Najbolj uporabljen programski jezik

Java (9), C# (7), ni odgovor (6)

Java (8), C#(8) Java (15), C#(6)

Najbolj uporabljeno razvojno okolje

NetBeans (5), Eclipse (2), VS.Net (3), VS (3), Drugo (1), ni odgovora (6)

NetBeans (4), Eclipse (2), VS.Net (6), VS (2), Drugo (2)

NetBeans (7), Eclipse (8), VS.Net(6)


6.4.2 Rezultati skupne 1

Tabela 4 prikazuje stopnjo pravilnosti reševanja zastavljenih načrtovalskih

problemov v skupini 1 (manj izkušeni razvijalci).

Tabela 4: Pravilnost reševanja nalog v skupini 1

Kandidat % pravilnih A

% pravilnih B

% pravilnih C

Faktor izboljšanja A B

Faktor izboljšanja A C

Faktor izboljšanja B C

1 38 38 25 1,00 0,67 0,672 25 25 25 1,00 1,00 1,003 08 46 38 6,00 5,00 0,834 33 33 33 1,00 1,00 1,005 17 17 17 1,00 1,00 1,006 11 11 17 1,00 1,50 1,507 13 25 25 2,00 2,00 1,008 6 17 17 3,00 3,00 1,009 38 25 25 0,67 0,67 1,00

10 13 13 38 1,00 3,00 3,0011 17 17 33 1,00 2,00 2,0012 50 50 63 1,00 1,25 1,2513 38 38 50 1,00 1,33 1,3314 38 50 63 1,33 1,67 1,2515 25 25 25 1,00 1,00 1,0016 25 38 25 1,50 1,00 0,6717 7 21 21 3,00 3,00 1,0019 50 75 100 1,50 2,00 1,3319 33 0 67 0,00 2,00 0,0020 13 25 38 2,00 3,00 1,5021 25 38 38 1,50 1,50 1,0022 20 0 60 0,00 3,00 0,00

Mediana 25 28 38 1,48 1,89 1,11Stand. deviacija 14 18 21 1,25 1,07 0,61

A B T‐Test: p=0,2290

A C T‐Test: p=0,0007

B C T‐Test: p=0,0322


Okrajšave se sklicujejo na posamezne stopnje eksperimenta:

• A: ad-hoc odgovori na podlagi dosedanjega znanja in izkušenj,

• B: odgovori z dosedanjo podporo (besedilo, iskanje s ključnimi

besedami),

• C: odgovori s pomočjo vodenega dialoga.

Tabela najprej navede pravilnost reševanja nalog v odstotkih, nato pa

faktor spremembe uspešnosti med posameznimi fazami eksperimenta.

Podane so še srednje vrednosti in standardne deviacije, med pravilnostjo

odgovarjanja posameznih faz pa smo izračunali še statistično

signifikantno razlikovanje s pomočjo Studentovega T-Testa.

Tabela 5 za vsakega kandidata eksperimenta prikazuje povprečen

potreben čas za reševanje 1 naloge. Časi so podani v sekundah.

Podana sta še izračuna srednje vrednosti in standardne deviacije. S

pomočjo Studentovega T-Testa smo ugotovili, da se časi reševanja v

posameznih fazah ne razlikujejo statistično signifikantno:

• p=0,53 med fazama A in B,

• p=0,053 med fazama B in C,

• p=0,15 med fazama A in C.


Tabela 5: Porabljen čas na nalogo v skupini 1

Kandidat Čas za A, 1 naloga [s] Čas za B, 1 naloga [s] Čas za C, 1 naloga [s]1 82,88 74,75 233,382 139,75 46,50 157,883 130,69 156,15 74,924 193,67 76,33 145,675 123,33 117,58 86,176 70,33 71,72 77,947 89,00 150,75 120,008 166,61 58,61 44,839 111,75 68,50 179,13

10 87,63 102,75 162,2511 145,17 203,33 193,8312 122,13 103,38 92,0013 96,13 116,50 137,6314 95,13 104,88 93,0015 108,88 60,88 154,1316 149,38 92,13 90,8817 86,93 108,93 65,7119 179,25 214,50 311,5019 169,67 177,00 278,0020 107,38 163,75 119,3821 103,75 97,13 152,0022 150,00 189,40 200,20

Mediana 123,15 116,16 144,11Stand. deviacija 34,52 49,58 68,79

6.4.3 Rezultati skupne 2

Tabela 6 prikazuje stopnjo pravilnosti reševanja zastavljenih načrtovalskih

problemov v skupini 2 (bolj izkušeni razvijalci).




besedami),


Tabela najprej navede pravilnost reševanja nalog v odstotkih, nato pa

faktor spremembe uspešnosti med posameznimi fazami eksperimenta.


Podane so še srednje vrednosti in standardne deviacije, med pravilnostjo

odgovarjanja posameznih faz pa smo izračunali še statistično

signifikantno razlikovanje s pomočjo Studentovega T-Testa.

Tabela 6: Pravilnost reševanja nalog v skupini 2

Kandidat % pravilnih A

% pravilnih B

% pravilnih C

Faktor izboljšanja A B

Faktor izboljšanja A C

Faktor izboljšanja B C

1 100 100 100 1,00 1,00 1,002 21 57 100 2,67 4,67 1,753 32 42 32 1,33 1,00 0,754 9 27 27 3,00 3,00 1,005 7 7 27 1,00 4,00 4,006 36 29 36 0,80 1,00 1,257 5 16 26 3,00 5,00 1,678 40 40 20 1,00 0,50 0,509 47 73 100 1,57 2,14 1,36

10 15 54 100 3,50 6,50 1,8611 11 17 17 1,50 1,50 1,0012 24 29 35 1,25 1,50 1,2013 38 25 50 0,67 1,33 2,0014 11 32 32 3,00 3,00 1,0015 10 30 100 3,00 10,00 3,3316 74 84 100 1,14 1,36 1,19

Mediana 30 41 56 1,84 2,97 1,55Stand. deviacija 26 26 36 0,99 2,56 0,93

A B T‐Test: p=0,00635

A C T‐Test: p=0,0057

B C T‐Test: p=0,0202

Tabela 7 za vsakega kandidata eksperimenta prikazuje povprečen

potreben čas za reševanje 1 naloge. Časi so podani v sekundah.

Podana sta še izračuna srednje vrednosti in standardne deviacije. S

pomočjo Studentovega T-Testa smo ugotovili, ali se časi reševanja v

posameznih fazah razlikujejo statistično signifikantno:

• p=0,07 med fazama A in B,

• p=0,21 med fazama B in C,


• p=0,02 med fazama A in C.

Tabela 7: Porabljen čas na nalogo v skupini 2

Kandidat Čas za A, 1 naloga [s] Čas za B, 1 naloga [s] Čas za C, 1 naloga [s]1 608,00 410,50 260,502 89,57 60,79 87,573 91,79 48,47 60,794 113,73 137,82 83,915 0,73 113,40 43,406 143,71 46,21 58,437 78,84 100,11 75,748 215,60 199,00 236,609 121,60 60,07 82,67

10 110,92 86,15 68,0011 131,06 85,44 17,3312 109,71 31,47 66,8813 117,75 115,50 102,3814 66,53 108,74 32,4715 189,40 99,40 121,3016 105,79 45,84 68,74

Mediana 143,42 109,31 91,67Stand. deviacija 132,90 90,72 66,35

6.4.4 Rezultati skupine 3

Tabela 8 prikazuje stopnjo pravilnosti reševanja podanih nalog

kandidatov kontrolne skupine. Tabela prikazuje še izračun srednje

vrednosti in standardne deviacije. S pomočjo Studentovega T-testa smo

izračunali tudi, ali se pravilnost reševanja skupine statistično signifikantno

razlikuje od reševanja kandidatov skupin 1 in 2 v fazi C.

Tabela podaja tudi povprečen čas v sekundah, potreben za reševanje 1

naloge. Tudi morebitno statistično signifikantno razlikovanje časov s

kandidati skupin 1 in 2 v fazah C, potrebnih za reševanje, smo preverili s

pomočjo Studentovega T-testa. Podaja ju tabela 8.


Tabela 8: Pravilnost in hitrost reševanja nalog v skupini 3

Kandidat % pravilnih odgovorov z vodenim dialogom

Povprečen čas za 1 nalogo [s]

1 44 410,502 69 60,793 56 48,474 75 137,825 75 91,796 63 113,737 50 0,738 38 143,719 50 78,84

10 56 215,6011 68 121,6012 42 110,9213 42 131,0614 37 109,7115 32 117,7516 32 66,5317 32 233,3818 32 157,8819 37 74,9220 53 145,6721 26 86,17

Mediana: 48 126,55Standardna deviacija: 15,2035 83,72156

T‐Test s fazo C skupin 1 in 2:p=0,7

T‐Test s fazo C skupin 1 in 2: p=0,77

6.4.5 Rezultati po nalogah

Tabela 9 prikazuje stopnjo pravilnosti reševanja po zastavljenih

načrtovalskih problemih.




besedami),



Tabela 9: Pravilnost odgovorov kandidatov po nalogah

Naloga Rešitev Podanih odg.

% podanih pravilnih odg. A

% podanih pravilnih odg. B

% podanih pravilnih odg. C

Faktor Izboljšanja A B

Faktor Izboljšanja B C

Faktor Izboljšanja A C

1 Obiskovalec 11 36 55 64 1,50 1,17 1,752 Fasada 33 52 61 61 1,18 1,00 1,183 Dekorator 26 54 58 62 1,07 1,07 1,144 Prototip 30 10 20 23 2,00 1,17 2,335 Opazovalec 29 24 31 48 1,29 1,56 2,006 Zrno 17 29 29 47 1,00 1,60 1,607 Dekorator 29 31 52 62 1,67 1,20 2,008 Adapter 16 19 13 25 0,67 2,00 1,339 Interpreter 15 13 13 40 1,00 3,00 3,00

10 Most 16 6 6 25 1,00 4,00 4,00

11 Ukaz ali spomin 17 24 53 65 2,25 1,22 2,75

12 Adapter 30 7 17 23 2,50 1,40 3,5013 Graditelj 36 11 28 28 2,50 1,00 2,50

14 Predloga metode 15 20 27 33 1,33 1,25 1,67

15 Adapter 18 39 50 61 1,29 1,22 1,5716 Strategija 17 6 24 41 4,00 1,75 7,0017 Graditelj 14 7 21 29 3,00 1,33 4,0018 Iterator 28 14 14 14 1,00 1,00 1,0019 Adapter 15 7 27 40 4,00 1,50 6,00

Med. 22 31 42 1,80 1,55 2,65Stand. dev. 15 17 17 1,00 0,76 1,64

A B T‐Test: p=0,00017

B C T‐Test: p=0,00001

A C T‐Test: p= 0,0000002

Tabela 9 za vsako nalogo podaja pravilnost odgovorov v odstotkih ter

odstotni faktor izboljšave med posameznimi fazami reševanja. V analizo

so zajeti samo odgovori kandidatov skupin 1 in 2, saj so kandidati skupine

3 (kontrolna skupina) odgovarjali le s pomočjo vodenega dialoga.

Tabela prikazuje še srednjo vrednost in vrednost standardne deviacije

pravilnosti in faktorjev izboljšav. Med stopnjami pravilnosti posameznih faz


smo s pomočjo Studentovega T-Testa izračunali signifikantno razlikovanje.

Tudi te vrednosti podaja tabela 9.

6.4.6 Zadovoljstvo kandidatov

Tabela 10 podaja rezultate ankete, ki je bila izvedena neposredno po

reševanju praktičnih nalog. Kandidate smo vprašali, ali se jim je zdel

voden dialog pri reševanju načrtovalskih problemov uporaben ter ali se

jim zdi, da so s pomočjo vodenega dialoga našli več pravilnih rešitev na

zastavljene načrtovalske probleme.

Podatki, dani v tabeli torej odsevajo subjektivno mnenje kandidatov v

eksperimentu.

Tabela 10: Rezultati ankete po eksperimentu

Skupina 1 (manj izkušeni razvijalci)

Skupina 2 (bolj izkušeni razvijalci)

Skupina 3 (kontrolna skupina)

Se vam zdi voden dialog uporaben?

2x primeren pri vsakodnevnem razvoju 12x je zelo uporaben 5x je uporaben 3x ne vem



Se vam zdi da ste z vodenim dialogom uspeli identificirati več pravilnih rešitev? (0=ne – 6=da)

Mediana: 5,36 Stand. deviacija: 1,62




7. Diskusija rezultatov

Tekom doktorske naloge smo poizkušali potrditi ali ovreči naslednji

hipotezi:

Hipoteza H1:

Sistem, ki omogoča predlaganje vzorca za podano problemsko

situacijo, pospešuje uporabo ustreznih načrtovalskih vzorcev.

Hipoteza H2:

Formalna predstavitev načrtovalskih vzorcev na osnovi ontologij

in tehnologij semantičnega spleta omogoča učinkovito zgradbo

sistema, omenjenega v hipotezi H1.

Pri tem smo razvili lasten prototipni sistem. Ta sledi metodologiji snovanja

in uporabe načrtovalskih vzorcev in na podlagi formalne notacije

načrtovalskih vzorcev omogoča vodenje dialoga z razvijalcem. To nam

je služilo kot osnova pridobivanja podatkov tekom eksperimenta,

podrobno opisanega v poglavju 6.

V tem poglavju povzamemo najpomembnejše empirično pridobljene

podatke in izpeljemo na njih temelječe zaključke.


7.1 Verodostojnost rezultatov

Vsi podatki so bili pridobljeni tekom nadzorovanega eksperimenta, kot je

opisano v poglavju 6. Da bi preverili ali je zaradi zasnove eksperimenta, ki

predvideva reševanje istih nalog v treh fazah, prišlo do neželenih vplivov

predhodnih faz na reševanje s pomočjo vodenega dialoga, smo uvedli

kontrolno skupino (skupina 3, opisana v poglavju 6). Profil razvijalca

kontrolne skupine se bistveno ne razlikuje od profila razvijalcev, ki so

sodelovali v celotnem eksperimentu. Kontrolno skupino so sestavljali

kandidati s povprečno 4,8 leti izkušenj pri razvoju razvoja programske

opreme, kandidati v skupini 1 in 2 pa so imeli v povprečju 1,25 let oz. 5,3

let izkušenj v razvoju programske opreme.

Kandidati kontrolne skupine so s pomočjo vodenega dialoga uspeli v

povprečju rešiti pravilno 48% zastavljenih nalog. Rezultat se statistično ne

razlikuje signifikantno od dosežkov kandidatov skupin 1 in 2 v fazi C

(p=0,7). Tudi čas, ki je v povprečju bil potreben za reševanje ene naloge

(127 sekund) se statistično signifikantno ne razlikuje od meritev časov

skupin 1 in 2 v fazi C (p=0,77).

Iz predstavljenih rezultatov lahko zaključimo, da so podatki, pridobljeni v

fazah A, B in C relevantni in da nanje potek eksperimenta ni imel

negativnih vplivov.

7.2 Rezultati skupine 1

Skupino 1 so sestavljali manj izkušeni razvijalci. To so bili študentje, ki so v

povprečju imeli 1,25 let izkušenj v razvoju programske opreme. Glede na

anketo pred eksperimentom kažejo dobro izobraženost o načrtovalskih

vzorcih (poznavanje načrtovalskih vzorcev v razmerju do izkušenj), tudi

nabor naštetih vzorcev, ki jih kandidati poznajo je bogat; zajema


predvsem enostavnejše vzorce nabora GoF (adapter, edinec, iterator,

opazovalec, fasada).

V fazi A (ad-hoc odgovori na podlagi dosedanjega znanja in izkušenj) so

pravilno odgovorili na 25% predstavljenih načrtovalskih problemov.

Podatki kažejo, da jim pomoč v obliki utečene podpore (prisotnost

dokumentacije o vzorcih, možnost iskanja s ključnimi besedami)

signifikantno ni pomagala (p=0,23) pri reševanju. Ob tej podpori so

dosegli rezultat 28%. Glede na to, da gre za manj izkušene, vendar v

načrtovalskih vzorcih relativno dobro izobražene kandidate, je morda

rezultat pričakovan, še posebej ob upoštevanju ugotovitve avtorja

Sommerville (Sommerville, 2004), ki pravi da so pri identificiranju ustreznih

načrtovalskih vzorcev bolj pomembne izkušnje kot formalno poznavanje

le-teh. Zanimiva je naslednja ugotovitev, ki jo dajejo podatki: čas iskanja

rešitve se kljub podpori infrastrukture v fazi B ni signifikantno zmanjšal.

V fazi C (odgovori s pomočjo vodenega dialoga) so kandidati v

povprečju pravilno odgovorili na 38% zastavljenih nalog. Rezultat je

signifikantno boljši tako v razmerju do rezultata faze A (p=0,0007), kot v

razmerju do rezultatov faze B (p=0,032). Očitno je, da ekspertno znanje,

povezano v voden dialog, izboljša iskanje relevantnih vzorcev. Glede na

to, da takšen dialog terja določen časovni vložek, podatki pravijo, da je

v povprečju faza C trajala najdlje (144 sekund , fazi A in B pa 123 in 116

sekund), vendar ta čas ni statistično signifikantno večji od faz A in B.

Manj izkušenim razvijalcem torej naša metoda signifikantno pomaga pri

iskanju primernih načrtovalskih vzorcev (s faktorjem 189% glede na lastno

poznavanje vzorcev in 111% glede na uporabo mehanizmov iskanja in

vpogleda v dokumentacijo vzorcev).

Časovno gledano vidimo, da manj izkušenim razvijalcem naša metoda

ne pomaga, da bi rešitve našli hitreje. Na drugi strani pa časa,

potrebnega za iskanje vzorca, tudi, bistveno ne podaljša, kar

ocenjujemo kot pozitivno.


Tudi subjektivno mnenje kandidatov v skupini manj izkušenih razvijalcev je

naši metodi naklonjeno: dialog se jim zdi zelo uporaben, prav tako so

mnenja, da je zelo pripomogel k njihovemu pravilnemu izboru ustreznega

načrtovalskega vzorca. Takšna ugotovitev se nam zdi smiselna, saj dialog

razvijalca s pomočjo kratkih in jasnih vprašanj vodi k odgovoru.

7.3 Rezultati skupine 2

Skupino 2 so sestavljali bolj izkušeni razvijalci. To so bili profesionalni

razvijalci in študentje, ki so v povprečju imeli 5,3 let izkušenj v razvoju

programske opreme. Glede na anketo pred eksperimentom kažejo

dobro izobraženost o načrtovalskih vzorcih (poznavanje načrtovalskih

vzorcev v razmerju do izkušenj).

V fazi A (ad-hoc odgovori na podlagi dosedanjega znanja in izkušenj) so

pravilno odgovorili na 30% predstavljenih načrtovalskih problemov.

Podatki kažejo, da jim je pomoč v obliki utečene podpore (prisotnost

dokumentacije o vzorcih, možnost iskanja s ključnimi besedami)

signifikantno pomagala (p=0,00635) pri reševanju. Ob tej podpori so

dosegli rezultat 41%. Rezultat se nam zdi razumljiv, saj se bolj izkušeni

razvijalci očitno zanašajo na svojo kreativnost; če pa jim ponudimo

ustrezno orodje pa si znajo z njim tudi ustrezno pomagati. Iskanje vzorcev

na podlagi ključnih besed vendarle zahteva določeno razumevanje

predstavljene problematike. Tudi pri bolj izkušenih razvijalcih se čas

iskanja vzorca ne razlikuje bistveno od časa lastnega odgovarjanja.

V fazi C (odgovori s pomočjo vodenega dialoga) so kandidati v

povprečju pravilno odgovorili na 56% zastavljenih nalog. Rezultat je

signifikantno boljši tako v razmerju do rezultata faze A (p=0,0057) kot v

razmerju do rezultatov faze B (p=0,0202). Veseli nas, da se je, hkrati z

dvigom pravilnih odgovorov z uporabo naše metode, statistično

signifikantno zmanjšal tudi potreben čas za iskanje pravilne rešitve glede


na fazo A (p=0,02). Kakorkoli že, potrebni časi med fazami A in B ter B in

C se statistično signifikantno ne razlikujejo.

Tudi bolj izkušenim razvijalcem torej naša metoda signifikantno pomaga

pri iskanju primernih načrtovalskih vzorcev (s faktorjem 297% glede na

lastno poznavanje vzorcev in 155% glede na uporabo mehanizmov

iskanja in vpogleda v dokumentacijo vzorcev).

Časovno gledano vidimo, da bolj izkušenim razvijalcem naša metoda

glede na utečeno prakso iskanja ne pomaga, da bi rešitve našli hitreje.

Je pa čas signifikantno krajši v primerjavi z reševanjem brez vsake

podpore. Tudi dejstvo, da smo tekom eksperimenta vendarle beležili

časovne izboljšave, interpretiramo kot pozitivno.

Subjektivno mnenje kandidatov v skupini bolj izkušenih razvijalcev je naši

metodi naklonjeno: dialog se jim zdi zelo uporaben, prav tako so

mnenja, da je zelo pripomogel k njihovemu pravilnemu izboru ustreznega

načrtovalskega vzorca. Takšna ugotovitev se nam zdi smiselna, saj dialog

razvijalca s pomočjo kratkih in jasnih vprašanj vodi k odgovoru.

7.4 Primerjava rezultatov po nalogah

V fazi A so praktične naloge z načrtovalskimi problemi v povprečju

dobile 22% pravilnih odgovorov. Najboljše rezultate so beležile naloge, ki

so imele za rešitev prav vzorce, ki so jih v anketi pred eksperimentom

navedli tudi razvijalci (adapter, fasada, dekorator, obiskovalec), skratka

poznani vzorci, kar se nam zdi smiselno. Tako faza B kot faza C statistično

signifikantno izboljšata pravilnost rezultatov. V fazi B je v povprečju 31%

pravilnih odgovorov, kar je signifikantno bolje kot v fazi A (p=0.00017). V

fazi C doseže povprečna pravilnost kar 42%, kar je signifikantno

izboljšanje tako glede na fazo A (p=0,0000002) kot glede na fazo B

(p=0,00001).


Iz podatkov izhaja tudi ugotovitev, da v fazi C največ pridobijo vzorci, ki

jih sicer razvijalci ne poznajo tako dobro (opazovalec, most, strategija,

graditelj, ukaz, spomin, interpreter).

7.5 Primerjava rezultatov skupine 1 in skupine 2

Kljub temu, da v hipotezah ne zasledujemo sklepa, ki bi glede uporabe

ustreznih načrtovalskih vzorcev diferenciral manj in bolj izkušene

razvijalce, pa lahko ob predstavljenih podatkih izpeljemo tudi določene

ugotovitve v tej smeri.

Če še dodatno primerjamo profile bolj in manj izkušenih razvijalcev, ne le

po letih izkušenj, ugotovimo, da ima skupina manj izkušenih razvijalcev

relativno večje znanje o načrtovalskih vzorcih, hkrati pa manj praktičnih

izkušenj. Kljub temu smo pri bolj izkušenih razvijalcih v vseh fazah beležili

več pravilnih odgovorov o načrtovalskih vzorcih, kot pri manj izkušenih

razvijalcih. Ta informacija ponovno podpre že omenjeno ugotovitev

avtorja Sommerville (Sommerville, 2004), ki daje izkušnjam prednost pred

formalno izobrazbo.

Zanimivo je tudi, da bolj izkušenim razvijalcem iskanje s pomočjo ključnih

besed (faza B) statistično signifikantno pomaga, manj izkušenim

razvijalcem pa ne. Očitno je potrebno tudi pri tovrstnem iskanju že imeti

določene izkušnje in do določene mere vedeti, kaj želimo poiskati.

Slika 33 grafično prikazuje pravilnost reševanja načrtovalskih problemov v

fazah A, B in C z namenom lažje primerjave med skupinama 1 in 2.


Slika 33: Grafična predstavitev pravilnosti odgovarjanja

Naša metoda manj izkušenim razvijalcem pomaga, da postanejo njihovi

rezultati primerljivi rezultatom izkušenih razvijalcev, ko le-ti na osnovi

izkušenj ali s pomočjo ključnih besed iščejo ustrezne načrtovalske vzorce.

To ugotovitev interpretiramo kot zelo pozitivno, saj kaže na to, da naš

sistem z integracijo parcialnih nasvetov v voden dialog dejansko

omogoča prenos izkušenj iz bolj na manj izkušene razvijalce – kar je že od

Alexandra naprej eden izmed osnovnih namenov načrtovalskih vzorcev.

Na podlagi tega smo tudi mnenja, da omogoča metoda tudi postopno

izboljševanje razvijalcev, saj ne vodi razvijalca k odgovoru na slepo,

temveč mora razvijalec tekom dialoga razmišljati o trenutnem

načrtovalskem problemu in na takšen način pridobi novo izkušnjo, ki jo

poveže s predlaganim načrtovalskim vzorcem.

Kaže se, da naša metoda pri iskanju ustreznih načrtovalskih vzorcev bolj

pomaga izkušenim razvijalcem. Le-tem se tudi čas, potreben da pridejo

do ustrezne rešitve signifikantno zmanjša, česar pa pri manj izkušenih

razvijalcih ne zasledimo. Menimo, da bolj izkušeni razvijalci prej in bolj

natančno razumejo vprašanja, ki jih prejmejo tekom vodenega dialoga.

Pred eksperimentom smo bili mnenja, da izkušeni razvijalci nad našo

metodo ne utegnejo biti zelo navdušeni, saj bi voden dialog utegnili


razumeti kot omejevanje njihove kreativnosti. Kljub temu podatki kažejo,

da se obema skupinama zdi uporaba vodenega dialoga smiselna, zdi se

jim, da pomaga in da bi jo bili pripravljeni pogosto uporabljati. To nas

navdaja z optimizmom, saj bi metoda ob možnosti vsakodnevne

uporabe gotovo bila uporabljana.

7.6 Obravnava hipotez

7.6.1 Obravnava hipoteze H1

V sklopu doktorske naloge smo predlagali in predstavili sistem, ki je

zmožen voditi dialog z razvijalcem, da bi le-ta lažje identificiral ustrezen

načrtovalski vzorec. Z uveljavljenimi metodami znanstveno-

raziskovalnega dela smo uspeli dokazati, da sistem na osnovi naše

metodologije in prototipnega orodja omogoča statistično signifikantno

izboljšavo pri iskanju ustreznih načrtovalskih vzorcev za podan

načrtovalski problem. Pokazali smo, da je to res tudi, če ga primerjamo z

obstoječimi metodami izbire načrtovalskih vzorcev. Metodologijo

uporabe smo zasnovali tako, da eksperti, ki v platformo vstavljajo

ekspertno znanje, nimajo izrazitega dodatnega dela, saj je platforma

sposobna samodejno integrirati nasvete ločenih ekspertov in jih ponuditi

v obliki vodenega dialoga. Ugotovili smo, da so razvijalci z našim

sistemom zadovoljni. Ugotovili smo tudi, da naš sistem časa iskanja

ustreznega načrtovalskega vzorca ne podaljša, prej nasprotno: če

iskalno orodje uporablja izkušen razvijalec, se čas iskanja bistveno skrajša.

Na podlagi zgoraj naštetih dejstev lahko zaključimo, da smo z našim

sistemom uspeli uspešno potrditi hipotezo H1.

7.6.2 Obravnava hipoteze H2

Tekom doktorske naloge smo podrobneje opisali prototipno orodje, ki

omogoča predlaganje ustreznega načrtovalskega vzorca. Orodje


temelji na notaciji načrtovalskih vzorcev in ekspertnega znanja o njih, na

podlagi ontologij, zapisanih s tehnologijami semantičnega spleta.

Prednosti in pridobitve tako predstavljenega znanja smo podrobneje

opisali v poglavju 4.3. Glavne pridobitve so predvsem:

• na matematičnih principih temelječa predstavitev znanja s

potencialom enostavne, človeku prijazne notacije,

• temelji v industrijsko priznanih standardih konzorcija W3C,

• široka zastopanost z orodji,

• distribuiranost znanja z enostavno možnostjo integracije,

• povezljivost s sorodnimi notacijami, temelječimi na ontologijah.

Na tej osnovi in na podlagi dejstva, da smo uspeli sistem, ki vsebuje

inteligentno komponento predlaganja vzorcev, sestaviti enostavno,

lahko trdimo, da smo uspešno potrdili tudi hipotezo H2.


8. Zaključek

V doktorski nalogi smo se ukvarjali s problematiko izboljšave ponovne

uporabe na področju programskega inženirstva. Kot v ostalih inženirskih

disciplinah, je tudi v programskem inženirstvu ponovna uporaba eden

izmed temeljnih principov pri razvoju kakovostnih izdelkov v krajšem času

in z nižjimi stroški. Zato smo v doktorski nalogi predstavili načrtovalske

vzorce, kot pomemben mehanizem ponovne uporabe na višjem nivoju

abstrakcije.

Predstavili smo problematiko rasti števila katalogov načrtovalskih vzorcev

v zadnjih letih in povzeli avtorje, ki ugotavljajo, da postaja izbira

ustreznega načrtovalskega vzorca za podan načrtovalski problem

čedalje težavnejša. Izbira ustreznega vzorca je težavna že, če katalog

vsebuje komaj več kot 20 načrtovalskih vzorcev; še posebej če je

razvijalec neizkušen.

Tekom pregleda literature smo ugotovili, da avtorji reševanje

predstavljene problematike naslavljajo le izjemoma, pa še takrat se

omejujejo le na najosnovnejše možnosti pri iskanju vzorcev, kot so iskanje

po vezanem besedilu s pomočjo ključnih besed. Zato smo se odločili

vzpostaviti sistem, ki bi vključeval tako eksperte s področja načrtovalskih

vzorcev kot tudi neizkušene razvijalce ter omogočal, na osnovi

ekspertnega znanja, predlagati ustrezen načrtovalski vzorec za podan

načrtovalski problem.


Doktorska naloga postreže s kar nekaj izvirnimi prispevki. Na enem mestu

smo zbrali in medsebojno primerjali formalne metode predstavitve

načrtovalskih vzorcev. Ugotovili smo, da je formalna notacija vzorcev

osnova, na kateri moramo takšen sistem zgraditi. Razvili smo lastno

formalno notacijo načrtovalskih vzorcev, temelječo na ontologijah. Pri

formalizaciji smo se omejili na objektno-orientirane vidike načrtovalskih

vzorcev, njihove medsebojne povezave in ekspertno znanje o njih. V

lastni notaciji smo zapisali načrtovalske vzorce katalogov GoF (Gamma

et. al., 1995) in J2EE (Deepak, 2001). Ontološka notacija načrtovalskih

vzorcev ima mnoge prednosti, izmed katerih so najpomembnejše

porazdeljena narava ontologij, temelji v splošno sprejetih standardih,

stroga matematična osnova ter možnost enostavne integracije s

sorodnimi, na ontologijah temelječimi notacijami, na primer ODOL

(Dietrich, 2007).

Razvili smo tudi lasten algoritem, ki na osnovi ontološko predstavljenega

ekspertnega znanja o vzorcih vodi dialog z uporabnikom. Na osnovi

ločenih ekspertnih nasvetov v obliki vprašanj in odgovorov, zna

inteligentni algoritem voditi dialog. Skozi dialog uporabnik poda svoj

načrtovalski problem, na osnovi katerega je algoritem sposoben

predlagati ustrezen načrtovalski vzorec.

Razvili smo tudi lastno metodologijo in podporno platformo, ki

omogočata enostavno uporabo naprednih funkcionalnosti tako

ekspertom kot tudi neizkušenim razvijalcem. Platforma poleg modula, ki

vodi dialog z uporabnikom, omogoča še iskanje po integriranem

vezanem besedilu, pri čemer smo upoštevali tudi spletne vire o

načrtovalskih vzorcih.

Tekom dela na doktorski nalogi smo sledili uveljavljenim metodam

znanstveno-raziskovalnega dela. Predpostavke in smernice raziskave

smo oblikovali na osnovi pregleda literature. Po zasnovi formalne

notacije, metodologije, inteligentnega algoritma in prototipne platforme


OBDPR, smo način uporabe predstavili s študijo primera. V začetku

postavljeni hipotezi smo uspeli formalno dokazati s pomočjo

nadzorovanega eksperimenta, ki je ob uporabi našega orodja meril

pravilnost ter hitrost izbire primernih vzorcev in s pomočjo ankete

zadovoljstvo uporabnikov pri tem. Ugotovili smo, da so razvijalci sprejeli

naš sistem z odobravanjem. Njihova uspešnost se ob vodenem dialogu

signifikantno poveča, izkušenim razvijalcem celo omogoča bistveno

hitrejše reševanje načrtovalskih problemov. Veseli smo tudi, da naš sistem

ekspertov s področja načrtovalskih vzorcev ne obremenjuje z bistvenim

dodatnim delom.

Kljub dosežkom, predstavljenim tekom doktorske naloge, se zavedamo,

da obstaja še nekaj prostora za izboljšave. Pri raziskovanju smo namreč

sprejeli določene omejitve. Čeprav smo poiskali algoritem, ki uspešno

vodi dialog z uporabnikom, verjamemo, da ga je možno še izboljšati. Za

dejansko operativno uporabo naše platforme OBDPR bi bilo potrebno

razviti tudi dodatke v smislu integracije v razvojna okolja. Le-ti bi v

povezavi s sorodnimi ontologijami, npr. ODOL, lahko bili osnova

samodejni implementaciji načrtovalskega vzorca, ki bi ga uporabnik

izbral na osnovi vodenega dialoga. Tudi sama zasnova platforme pušča

odprte možnosti za dodatne module, ki bi inteligentno podprli delo z

načrtovalskimi vzorci. Npr. poenostavljeno izbiro načrtovalskega vzorca,

če primerjamo le določen nabor vzorcev; validiranje izbranega

načrtovalskega vzorca ipd.

Zaključimo lahko, da smo v doktorski nalogi na osnovi uveljavljenih

metod znanstveno-raziskovalnega dela uspeli pokazati, da izvirni

prispevki predstavljajo dobro osnovo za nadaljnje inteligentne rešitve.

Tudi naše nadaljnje raziskave bodo usmerjene v dodatne metode

izboljšanja ponovne uporabe v programskem inženirstvu, še posebej na

osnovi vzorcev.


9. Literatura

• Alexander, C. The timeless way of building. Oxford University Press. 1979. • Alexander, C., Ishikawa, S., & Silverstein, M. A pattern language: Towns,

buildings, construction. Oxford University Press. 1977. • Beck, K., & Cunningham, W. Using pattern languages for object-

oriented programs (Tech. Rep. No. CR-87-43). Tektronix Inc, Computer Research Laboratory. 1987.

• Berners-Lee, J. Hendler, O. Lassila. The Semantic Web. Scientific American, 284 (5). p. 28-37. 2001.

• Birukuo, Blanzieri E., Giorgini P. Choosing the Right Design Pattern: The Implicit Culture Approach. Arturo Hinojosa, A Cognitive Model of Design Pattern Selection. Technical Report DIT-06-007. Informatica e Telecomunicazioni. University of Trento. 2006.

• Blewitt. Spine: Language for Pattern Verification. p. 109-122. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Budinsky J., Finnie M. A., Vlissides J. M., Yu P. S. Automatic Code Generation from Design Patterns. IBM Systems Journal. 36 (2) p. 151-171. 1996.

• Burke R. Hybrid Recommender Systems: Survey and Experiments. Journal User Modeling and User-Adapted Interaction. Springer Netherlands, Volume 12, Number 4. p.331-370. November, 2002.

• Chatzigeorgiou, Tsantalis N., Deligiannis I., An empirical study on students’ ability to comprehend design patterns. Computers & Education, 51 (3). p.1007-1016. November 2008.

• Dae-Kyoo. The Role-Based Metamodeling Language for Specifying Design Patterns. p.183-205. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Deepak, J. Crupi, D. Malks. Core J2EE Patterns: Best Practices and Design Strategies. Sun Microsystems. Palo Alto. 2001.


• Dietrich, C. Elgar. An Ontology Based Representation of Software Design Patterns. p. 258-279. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Eden H., Yehudai A., Gil J. Precise Specification and Automatic Application of Design Patterns. 12th IEEE International Conference on Automated Software Engineering. IEEE Press. Proceedings, p. 143-152. 1997.

• Ewald, R.; Himmelspach, J.; Uhrmacher, A.M. An Algorithm Selection Approach for Simulation Systems, Principles of Advanced and Distributed Simulation, 2008. PADS apos;08. 22nd Workshop on, Volume , Issue , 3-6. p. 91-98. 2008.

• Flores, A. Cechich, G. Aranda. A Generic Model of Object-Oriented Patterns Specified in RSL. p. 44-72. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Fontoura, Lucena C. Extending UML to Improve the Representation of Design Patterns. Journal of Object-Oriented Programming, 13(11). p.12-19. 2001.

• Fowler M. Patterns of Enterprise Application Architecture. Addison-Wesley. 2003.

• France B., Kim D. K., Ghosh S. Song E. A UML-Based Pattern Specification Technique. IEEE Transactions on Software Engineering, 30(3). p. 193-206. 2004.

• Gamma, E., Helm, R., Johnson R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. 1995.

• Gasparis E. LePUS: A Formal Language for Modeling Design Patterns. p. 357-372. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Gomes, F.C., Pereira, P., Paiva, N., Seco, P., Carreiro, J., Ferreira, C., Bento. Selection and Reuse of Software Design Patterns Using CBR and WordNet. 15th International Conference on Software Engineering and Knowledge Engineering, SEKE 2003, Proceedings, (SEKE'03). p. 289-296. 2003.

• Gruber T.R. Towards Principles for the Design of Ontologies used for Knowledge Sharing. In N. Guarino & R. Poli (eds.), Internbational Workshop on Formal Ontology, Padova, Italy. 1993.

• Helin J., Kellomäki P., Mikkonen T. Patterns of Collective Behavior in Ocsid. p. 73-93. Design Patterns Formalization Techniques. IGI Publishing. March 2007.


• Herranz, J. J. Moreno-Navarro. Modeling and Reasoning about Design Patterns in Slam-Sl. p. 206-235. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Houstis, E. N., Catlin, A. C., Rice, J. R., Verykios, V. S., Ramakrishnan, N., and Houstis, C. E. 2000. PYTHIA-II: a knowledge/database system for managing performance data and recommending scientific software. ACM Trans. Math. Softw. 2000.

• Ittycheriah, A., Franz, M., Zhu, W., Ratnaparkhi, A., and Mammone, R. J. 2001. Question answering using maximum entropy components. In Second Meeting of the North American Chapter of the Association For Computational Linguistics on Language Technologies 2001. Pittsburgh, Pennsylvania. 2001.

• J. Dong, P. Alencar, D. Cowan. Formal Specification and Verification of Design Patterns. p. 94-108. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Kim K. et al. A UML-based Metamodeling Language to Specify Design Patterns. Proceedings of the Workshop Software Model Eng. (WiSME) with Unified Modeling Language Conf. 2003. Oktober 2003.

• Kung, D. C., H. Bhambhani, R. Shah, G. Pancholi. 2003. An expert system for suggesting design patterns: a methodology and a prototype. In Software Engineering With Computational Intelligence, ed. T. M. Khoshgoftaar. Kluwer Int. Lazovik, A., M. Aiello, and M. Papazoglou. 2006.

• Lano, K. Formalising Design Patterns as Model Transformations. p. 156-182. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Lovatt, A. M. Sloane, D. R. Verity. A Pattern Enforcing Compiler (PEC) for Java: A Practical Way to Formally Specify Patterns. p. 324-356. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Manolescu D. Kozaczynski W., Miller A., Hogg J. The Growing Divide in the Patterns World. IEEE Software, Vol. 24, No. 4. p. 61-67. 2007.

• Maplesden, J. Hosking, J. Grundy. A Visual Language for Design Pattern Modeling and Instantiation. p. 20-43. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• McDonald, D. W. and Ackerman, M. S. 2000. Expertise recommender: a flexible recommendation system and architecture. In Proceedings of the 2000 ACM Conference on Computer Supported Cooperative Work (Philadelphia, Pennsylvania, United States). 2000.


• McIlroy. Mass-produced Software Components. Proceedings of Software Engineering Concepts and Techniques. Nato Conference on Software Engineering. J. M. Buxton, P. Naur, and B. Randell, Editors. p. 138-155. New York. 1969.

• Mussbacher D., Amyot M., Weiss. Formalizing Patterns with the User Requirements Notation. p. 302-323. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Raje R., Chinnasamy S., Olson A. M., Hidgon W. The Applications and Enhancement of LePUS for Specifying Design Patterns. p. 236-257. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Rising, L. The Pattern Almanac 2000. Addison Wesley. 2000. • Rising, L. Understanding the Power of Abstraction in Patterns. IEEE

Software, 24 (4). P. 46-51. 2007. • Rosengard J. M., Ursu M. F. Ontological Representations of Software

Patterns. Lecture Notes in Computer Science (Proceedings of the of KES’04), 3215 . p. 31-37. 2004.

• Safiz M., P. Adamczyk, R.E. Johnson. Organizing Security Patterns. IEEE Software, 24 (4). P. 52-60. 2007.

• Schmidt, D.C. Using Design Patterns to Develop Reusable Object-Oriented Communication Software. Communications of the ACM. Oktober 1995.

• Smith J., Stotts D.. Intent-Oriented Design Pattern Formalization Using SPQR. p. 123-155. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Soundarajan, J. O. Hallstrom. Precision, Flexibility, and Tool Support: Essential Elements of Pattern Formalization. p. 280-301. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Sunyé, G. Guennec, A.L., Jézéquel, J.M. Design Patterns Application in UML. Lecture Notes in Computer Science (ECOOP'2000 proceedings), 1850. p. 44-62. 2000.

• Taibi T. An Integrated Approach to Design Patterns Formalization. p. 1-19. Design Patterns Formalization Techniques. IGI Publishing. Marec 2007.

• Taibi T. Design Patterns Formalization Techniques. United Arab Emirates University - UAE. Preface. IGI Publishing. December 2006.

• Zdun U. Systematic Pattern Selection Using Pattern Language Grammars and Design Space Analysis. Software: Practice & Experience, vol. 37, no. 9. p. 983-1016. Wiley. 2007.


• Vatovec-Krmac, E. Ponovna uporaba komponent pri objektno usmerjenem razvoju programske opreme. Portorož : Fakulteta za pomorstvo in promet. Ljubljana: Univerzitetna tiskarna. 1998.

Spletni viri

• W3C Semantic Web, http://www.w3.org/2001/sw/. • Berners-Lee, “Business Model for the Semantic Web”,

http://www.w3.org/ DesignIssues/Overview.html. • SPARQL Query Language for RDF, http://www.w3.org/TR/rdf-sparql-

query. • RDF/XML Syntax Specification, http://www.w3.org/TR/rdf-syntax-

grammar. • OWL Web Ontology Language Overview, http://www.w3.org/TR/owl-

features. • Wikipedia, the free encyclopedia. http://en.wikipedia.org. • Code reuse, Wikipedia, the free encyclopedia.

http://en.wikipedia.org/wiki/Code_reuse. • Design pattern. Wikipedia, the free encyclopedia.

http://en.wikipedia.org/wiki/Design_patterns. • Library (computing). Wikipedia, the free encyclopedia.

http://en.wikipedia.org/wiki/Library_(computer_science). Avgust 2008. • Microsoft, Microsoft Patterns & Practices,

http://msdn.microsoft.com/practices. • Core J2EE Patterns, http://java.sun.com/blueprints/ corej2eepatterns. • EuroPLoP 2007 Focus Group.

http://www.patternforge.net/wiki/index.php?title=EuroPLoP_2007_Focus_Group.

• Hillside.net - Online Pattern Catalog. http://hillside.net/patterns/onlinepatterncatalog.htm.


10. Seznam kratic, oznak in prevodov

Abstraktna

tovarna

Abstract Factory (vzorec)

Adapter Adapter (vzorec)

angl. angleško

BPSL Balanced Pattern Specification Language

CBR Case-Based Reasonong

DAML The DARPA Agent Markup Language

Dekorator Decorator (vzorec)

DPML Design Pattern Modeling Language

DPO Design Pattern Ontology

Edinec Singleton (vzorec)

et. al. in drugi

Fasada Facade (vzorec)

GoF Gang Of Four; Erich Gamma, Richard Helm, Ralph Johnson,

John Vlissides

Graditelj Builder (vzorec)

GRL Goal-oriented Requirement Language

Interpreter Interpreter (vzorec)

ipd. in podobno

Iterator Iterator (vzorec)

itn. in tako naprej

J2EE Java 2, Enterprise Edition

Kompozicija Composite (vzorec)

LePUS Language for Patterns Uniform Specification


Most Bridge (vzorec)

Namestnik Proxy (vzorec)

OBDPR Ontology-Based Design Pattern Repository

Obiskovalec Visitor (vzorec)

OCL Object Constraint Language

ODOL Object Oriented Software Design Ontology

OIL Ontology Inference Layer

Opazovalec Observer (vzorec)

OWL DL OWL Description Language

OWL Web Ontology Language

PEC A Pattern Enforcing Compiler

Posrednik Mediator (vzorec)

Predloga

metode

Template Method (vzorec)

Prototip Prototype (vzorec)

RAISE Rigorous approach to industrial software engineering

RBML Role-Based Metamodeling Language

RDF Resource Description Framework

RDFS RDF Schema

RIF Rule Interchange Format

RSL RAISE Specification Language

SPARQL Query Language for RDF

Spomin Memento (vzorec)

SPQR The system for pattern query and recognition

Stanje State (vzorec)

Strategija Strategy (vzorec)

t.i. tako imenovano

TLA Temporal Logic of Actions

Tovarniška

metoda

Factory Method (vzorec)

UCM Use Case Map

Ukaz Command (vzorec)

UML Unified Modeling Language


URI Uniform Resource Identifier

URN User Requirements Notation

Veriga

odgovornosti

Chain of Responsibility (vzorec)

W3C World Wide Web Consortium; http://www.w3c.org

Zrno Flyweight (vzorec)


11. Priloge

11.1 Ontologija OBDPR

<?xml version="1.0"?> <rdf:RDF xmlns="http://lisa.uni-mb.si/wwdot/skillonto.owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xml:base="http://lisa.uni-mb.si/dprepository/dponto.owl" > <owl:Ontology rdf:about="" /> <owl:DatatypeProperty rdf:ID="Name"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#PatternContainer"/> <owl:Class rdf:about="#Pattern"/> </owl:unionOf> </owl:Class> </rdfs:domain> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Desc"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#PatternContainer"/> <owl:Class rdf:about="#Pattern"/> </owl:unionOf> </owl:Class> </rdfs:domain> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Image"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#PatternContainer"/> <owl:Class rdf:about="#Pattern"/> </owl:unionOf> </owl:Class> </rdfs:domain> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:ID="Link"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#PatternContainer"/> <owl:Class rdf:about="#Pattern"/> </owl:unionOf>

130 Pavlič L.: Pospeševanje uporabe načrtovalskih vzorcev s pomočjo ontološko podprtega repozitorija Doktorska naloga. Maribor, 2009. </owl:Class> </rdfs:domain> <rdfs:range rdf:resource="#WebLink"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasMember"> <rdfs:domain rdf:resource="#PatternContainer"/> <rdfs:range> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#PatternContainer"/> <owl:Class rdf:about="#Pattern"/> </owl:unionOf> </owl:Class> </rdfs:range> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="relatedPattern"> <rdfs:domain rdf:resource="#Pattern"/> <rdfs:range rdf:resource="#PatternRelationship"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="alternativePattern"> <rdfs:domain rdf:resource="#Pattern"/> <rdfs:range rdf:resource="#PatternRelationship"/> </owl:ObjectProperty> <owl:DatatypeProperty rdf:ID="title"> <rdfs:domain rdf:resource="#WebLink" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="URL"> <rdfs:domain rdf:resource="#WebLink" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="relationName"> <rdfs:domain rdf:resource="#PatternRelationship" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:ID="patternLink"> <rdfs:domain rdf:resource="#PatternRelationship"/> <rdfs:range rdf:resource="#Pattern"/> </owl:ObjectProperty> <owl:DatatypeProperty rdf:ID="Text"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Question"/> <owl:Class rdf:about="#Answer"/> </owl:unionOf> </owl:Class> </rdfs:domain> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:ID="hasAnswer"> <rdfs:domain rdf:resource="#Question"/> <rdfs:range rdf:resource="#Answer"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="answerConsequence"> <rdfs:domain rdf:resource="#Answer"/> <rdfs:range rdf:resource="#AnswerRelevance"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="appliesToEntity"> <rdfs:domain rdf:resource="#AnswerRelevance"/> <rdfs:range> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#PatternContainer"/> <owl:Class rdf:about="#Pattern"/> </owl:unionOf> </owl:Class> </rdfs:range> </owl:ObjectProperty>

131 Pavlič L.: Pospeševanje uporabe načrtovalskih vzorcev s pomočjo ontološko podprtega repozitorija Doktorska naloga. Maribor, 2009. <owl:DatatypeProperty rdf:ID="relevance"> <rdfs:range rdf:resource="#AnswerRelevance"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#double"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="userName"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="password"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="realName"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="realSurname"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="eMail"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="userTitle"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="userEnabled"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="allowedBROWSING_MODE"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="allowedEDITING_QUESTION_MODE"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="allowedEXPERIMENT_MODE_NO_HELP"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="allowedEXPERIMENT_MODE_SEARCHING"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="allowedEXPERIMENT_MODE_PROPOSING"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="allowedMASTER_MODE"> <rdfs:domain rdf:resource="#User" /> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> </owl:DatatypeProperty> <owl:Class rdf:ID="PatternContainer" > <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#Name"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf>

132 Pavlič L.: Pospeševanje uporabe načrtovalskih vzorcev s pomočjo ontološko podprtega repozitorija Doktorska naloga. Maribor, 2009. <owl:Restriction > <owl:onProperty rdf:resource="#Desc"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Pattern" > <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#Name"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#Desc"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="WebLink" > <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#title"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#URL"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="PatternRelationship" > <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#relationName"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#patternLink"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Question" > <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#Text"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#hasAnswer"/> <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Answer" > <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#Text"/>

133 Pavlič L.: Pospeševanje uporabe načrtovalskih vzorcev s pomočjo ontološko podprtega repozitorija Doktorska naloga. Maribor, 2009. <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#answerConsequence"/> <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="AnswerRelevance" > <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#appliesToEntity"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction > <owl:onProperty rdf:resource="#relevance"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="User" > </owl:Class> <owl:Class rdf:ID="ExperimentResolution" > </owl:Class> <owl:Class rdf:ID="ExperimentResolutionLink" > </owl:Class> <owl:Class rdf:ID="TestCase" > </owl:Class> <owl:Class rdf:ID="TestCaseCollection" > </owl:Class> <owl:Class rdf:ID="TestCaseAnswer" > </owl:Class> <owl:Class rdf:ID="SurveyEvaluationMapping" > </owl:Class> </rdf:RDF>

11.2 Načrtovalski problemi, uporabljeni v eksperimentu (V

angleškem jeziku)

Simple Reporting (Prototype)

You are developing a component for generating reports. Each report is

represented with class the Report. Reports are built with rich components

having multiple attributes.

The company using your component will generate all reports with a set

of the same components, which are also quite complicated (header,


footer, company address etc.). Defining the same framework for a report

can be quite time consuming for users. You also want to avoid writing

code for generating a report from several templates again and again.

This is why you want to enable company employees to define report

templates. All reports should be automatically based on selected

templates. Reports should be able to apply some editing with the same

set of tools as editing report templates.

Which design pattern should be applied to class Report to achieve

template functionalities?

Designing Reports (Command or Memento)

You are developing a component for editing reports. Each report is

represented with the class Report. Reports are built with rich components

having multiple attributes.

The components in the reports are various: lines, labels, images etc. Your

product will enable additional components, that means you have no

idea what kinds of report components will be available.

Operations on components are also not defined at this time. Some

components can only be added to the report, others can be resized,

some components can be rotated etc. But you would like to establish

the same principle for canceling some changes made in the report. For

example, when you rotate an image, resize another currently not existing

component and move a label you notice that the report is

unsatisfactory. With one click you want to return to the state that existed

before rotating and resizing the image.

Which design pattern do you apply to the class Report to solve this

problem?


Hard Drinking (Visitor)

You have quite a large class hierarchy. The class Drink is on top and

direct subclasses are AlcoholicDrink and NonalcoholicDrink. There are

also classes such as Beer, Whisky, Soda, AppleJuice etc. All drinks have

implemented the method drink(). Now you have the brilliant idea of

introducing the new method, called drinkItAlot(). But you have no idea

where in the class hierarchy to introduce this method, so as not to pollute

it with new method classes that can not be hard-drunk. For example if

we introduce a new method in the class Drink you have a problem

because there are some drinks, which should not be drunken in excess,

i.e. AppleJuice, but it is ok if you drink a lot of Soda. It might be a very

good idea to introduce drinkItAlot() in the class Beer, but there are also

some special kinds of beers that can make people die of alcohol

poisoning and this is really something you do not want to cause.

Can you think of any design pattern that enables hard drinking only on

some Drinks, without introducing the method drinkItAlot()?

Displaying Paragraph(Adapter)

We are developing text processing software and have already

developed a Paragraph class. Now we have to develop a Java AWT

component for displaying formatted text. We want to reuse the

Paragraph class that enables formatting.

Each AWT Component inherits its data and methods from a class called

Component. Our FormattedTextComponent will inherit from

TextComponent:

public class TextComponent extends Component {

public void append(String str) { ... }

public String getText() { ... }

...


}

Which design pattern would you use when designing

FormattedTextComponent?

Good Legacy (Decorator)

You have a legacy system that is very complex. It functions perfectly and

you do not want to tamper with it. The legacy system accepts several

parameters, performs a simulation and returns an image with the curve

showing the simulation result. Your task is to design an extension that

preserves the same interface as the legacy system but on top of the

image also draws a grid of lines.

What design pattern should be applied here?

Incompatible Class (Adapter)

You are developing a PhoneBook class. It will enable you to manage

your contacts in your mobile phone. A PhoneBook class should reuse

already existing classes that enable the easy use of mobile phones, for

example calling contacts or sending an SMS to a contact. At

development time you do not know what the classes would look like, so

you use your own dummy-class MyPhone. After getting the class

NokiaPhone you notice that MyPhone and NokiaPhone are similar but

have different methods covering the same functionality. You want to use

the NokiaPhone class, but are not willing to change your classes and

keep using MyPhone to use NokiaPhone functionalities.

Which design pattern would you use to solve the issue?

Making Clients Thinner (Facade)

You are maintaining business applications, built on client-server

architecture. You have to add new functionalities to the system. There


are many various kinds of clients and business logic is mainly

implemented there - the same business logic is implemented repeatedly

among clients.

In order to implement new functionalities you have to move business

logic from clients to the server, so that further maintenance will be easier.

Functionalities will be implemented only once in one place, they will be

accessible via interface that enables only functionalities needed by

clients and in the way that the number of calls to the interface will be

minimal.

Which design pattern would you use to achieve those goals?

Unified Informing (Adapter)

You have an application for distributing messages through several

channels (e-mail, SMS, MMS etc.). Your company has purchased an out-

of-the-box product that enables GPS tracking. They want you to

integrate this product with an existing application that is quite out of the

date. The problem is you have no access to the GPS-tracking source

code, and only its interface is available. You are also not willing to

change the existing informing application since this would be very risky;

again you have interfaces you want to use.

Which design pattern do you propose to solve this integration problem?

War Game (Interpreter)

You are designing a game with a general that has to fulfill specific

missions using available army resources. The army resources consist of

airplanes, tanks and infantry units. The general will only state how many

airplanes, tanks and infantry units from the available ones should perform

specific tasks. This will be stated in the form of a command like: Destroy

bridge at location x,y; Conquer city at x, y; etc.


What design pattern is particularly useful when designing a game that

implements such functionality?

Cheapest Flight – WS (Adapter)

Suppose you should design an application that enables clients to book

the cheapest flight to a destination of their choice from a number of

providers. You want to be open for all kinds of technologies that your

partners may use. Many airlines offer on-line booking services as web

services.

Which design pattern can be used to incorporate such an airline as a

flight provider in the system above?

Pizza Store (Template Method)

You are developing software for an automated pizza store franchise. You

want your associates to be able to add new pizza recipes to their stores.

But the autocook is limited, since new recipes must be constructed using

steps that determine the basic way of making a pizza (make crust, add

base and toppings, bake pizza, pack etc.).

Which design pattern would you apply to your system to be able bake a

pizza according to new recipes?

Memory Consumption (Flyweight)

You developed an application that holds a large collection of objects in

its memory. Objects are costly to maintain in the memory because their

state is composed of much data. Some of the data is independent of

the objects and is found several times across the application. Now you

would like to solve the memory consumption problem without

excessively changing the application.

Which design pattern do you propose to solve this problem?


Taxi Wallpapers (Observer)

You are an inventor. You have invented technology that enables you to

change the colors of cars with a single click of the button. A taxi

company is interested in using your technology in every taxi. They desire

that all their taxi cars can change their roof colors. Taxis would have a

green roof in the morning, a red roof during the day and a yellow roof

through the night. They also have an idea for a new advertisement

model: the customer would send them an image and they would be

able to upload that image to every taxi and the image would also

appear on taxi doors.

To simplify the solution you want to have a single managing application

for setting the color of taxi roofs and uploading an image. When you set

an image or color of the roof in this management application every taxi

roof should instantly change color or an image should appear on the

doors. All communication will be done using existing communication

channels.


Unified Messaging (Bridge)

You are tired of using several instant messaging applications (MSN

Messenger, ICQ, Google Chat, Yahoo Messenger etc.). As a good

developer you start developing an instant messaging client that supports

all messaging protocols and message types. Since you want to be able

to add new protocols and message types in the future you want open

architecture. For the beginning you will support only Yahoo messenger

and Google Chat, exchanging simple text or binary messages. The only

presumption you have made is that all messages will be binary, but with

different sets of attributes (can be serialized/deserialized to/from binary

data).


As previously mentioned , when you want to add new instant messaging

protocol to a message type this should be done with little or no changes

to the existing application.


View on Colors (Adapter)

You are developing an application for displaying data from a digital

camera. At every moment you can read the color at particular

coordinates. But the data you get is quite raw. All you get is one 32-bit

integer, every 8 bits defines the intensity of red, green or blue colors.

You are using data to calculate the intensity of a particular color. There is

a class Reading, having a method getValue() that returns the previously

mentioned 32-bit integer. Since you do not find this solution acceptable

you want to have separate methods for returning red, greed and blue

color intensity, but at the same time you are not allowed to change the

class Reading.


Cheapest Flight (Iterator)

Suppose you want to design an application, which enables clients to

book the cheapest flight to a destination of their choice from a number

of providers. Assume every provider is known in advance, and

implements an interface IFlightProvider, which provides operations for

querying for a connection, and for booking a flight. In this application

you will need a way to enable clients to interface with these providers

and book the cheapest flight on offer for the destination and date they

are interested in. Flight providers should require (and receive) no

knowledge of other flight providers known to the system.

Which design pattern could you use?


Formatting Paragraph (Strategy)

We are developing text processing software. We have to develop a

class called Paragraph. It has many lines of text. We want the paragraph

to always be formatted. Therefore when a new line is added or an

existing line is changed, the formatting should be immediately applied. It

must be possible to set a formatting algorithm (left, right, centered etc.)

at runtime. It must also be available to add new formatting algorithms at

a later time without changing the Paragraph class.

Which design pattern would you use to solve the issue?

Tetris (Flyweight)

A Tetris field is essentially a big collection of stones, some representing

empty fields, and some representing parts of a Tetris block, either just

falling or landing at the bottom of a playground. Whenever a block

lands, it breaks apart into its individual stones, which are considered

independent from then on. It makes sense, therefore, to represent each

stone with an individual object in an object-oriented Tetris application.

Doing so naively results in a large amount of objects being allocated,

deleted, and moved all the time.

What design pattern can be applied to optimize this, taking advantage

of the fact that the stones are really very similar?

Image Effects (Decorator)

You are developing image editing software. You have developed the

class Image that enables you to load, rotate, resize and save an image

to a file. Your application now also enables special effects on images, for

example blurring. Therefore you have a BlurredImage class. When the

image is loaded into the BlurredImage class it is blurred, all other

operations are the same as in the Image class. You have noticed that

every special effect you implement results in almost the same class as


others but with slight differences. In addition, the current solution does

not have good support for combining effects ? for example applying a

blur effect on an image with an artistic image.

What design pattern could be used to reduce code duplicates in image

effect classes and enable easy combining effects?

Phone Contacts (Builder)

You have developed a component that handles contacts in mobile

phone. Each contact is represented as an instance of the class Contact.

Since contacts can go to an invalid state there is a method called

isValid() which returns a ?false? when contact is in an invalid state.

You want to get rid of the method isValid().


Tourist Agency (Builder)

You are developing a Tourist Agency Hotel Reservation System. The

component for data exchange with hotels is one of the crucial parts.

Different hotels support different types of protocols and data formats:

from simple text-based format to XML-based data exchange. The

exchanged data more or less cover the same attributes (number of

rooms reserved, number of nights, starting date etc).

You have represented all those attributes in a single class named

Reservation with multiple methods for sending data to a particular

protocol (to serialize data into a specific format).

You are becoming annoyed with the changing of the Reservation class

every time a new data format has to be supported.

Now you are trying to have a stable class Reservation, which means you

want to separate data representation with actual data that is contained

in the class Reservation.





Documents

Univerza v Mariboru - core.ac.uk · We have described GoF and J2EE design patterns using our notation. Based on that, we have also developed an algorithm for guiding a dialog with