Strokovn e razprave Vloga ponovne uporabe pri razvoju programske opreme Eve I m Valovec Krmac Povzetek: Ponovna uporaba je koncept razvoja aplikacij na osnovi obstoječe programske opremo. Pogosto se navaja kot osnovna prednost objektne tehnologije in kot strategija izboljšanja procesa razvoja programske opreme. Ponovna uporaba je sredstvo za izboljšanje kvalitete programske opreme, povečanje produktivnosti in zmanjšanje napora pri gradnji sistemov. Učinkovita in sistematična ponovna uporaba pa zahteva organizacijske spremembe, spremembe razvojnega procesa in vlaganja. Abstract: Reuse is the ability to develop applications based on existing software, it's often described as a principa/ benefit of object technology and a strategy to improve software development process, fleuse is also means of improving software quality; increasing productivity and reducing the effort to build systems. Successful and systematic reuse requires organizational changes, changes in development process and investment. 1. UVOD Ponovna uporaba programske opreme je koncept razvoja aplikacij na osnovi obstoječe programske opreme in se pogosto navaja kot osnovna prednost objektne tehnologije. Ponovna uporaba programske opreme pa ni nova - knjižnice funkcij in modulov se pri konven-cionafnem razvoju uporabljajo že dolga leta. Uspeh ponovne uporabe je bil predvsem odvisen od navdušenosti in sposobnosti programerjev za iskanje in uporabo programov. Težko je bilo vedeti, kaj je razpoložljivega in kako neko funkcijo ali modul uporabiti. Poleg tega je bilo število argumentov v splošnih programih precej veliko, tako da je bil tudi napor, vložen v razumevanje in prilagajanje teh programov specifičnim potrebam, dokaj velik. Zaradi omenjenih problemov so se razvijalci zelo pogosto raje lotili razvoja novih programov. Objektna tehnologija je nekatere izmed omenjenih problemov rešila. Objekti in razredi so že sami po sebi bolj i e enote za ponovno uporabo - objekti so koncepti, stvari, ki opisujejo posamezne entitete realnega sveta v programskem okolju, sistema, ki ga gradimo. Objekt v sebi združuje tako podatkovno strukturo kakor obnašanje. Razredi pa so skupki objektov s podobnimi lastnostmi (atributi), obnašanjem (operacijami), pomenom in povezavami z drugimi objekti. Objekti so lažje razumljivi kot funkcije pri konvencionalnem pro- gramiranju, saj obstaja med njimi in vsakdanjimi izkušnjami večja analogija - ljudje razumemo svet preko objektov, ne preko funkcij [ 111. S pomočjo ograjevanja, skrivanja podatkov ločimo zunanje aspekle sistema, ki so dostopni ostalim objektom (vmesnik objekta - imena operacij, preko katerih lahko drugi objekti dostopajo do podatkovne strukture tega objekta), od notranje implementacije objekta (implementacija podatkovne strukture in algoritmov, ki jih uporabljajo operacije), ki je drugim objektom skrita. To zagotavlja Šibko povezanost med moduli aplikacije, ki uporabljajo isti objekt, implementacijo objekta pa lahko spremenimo, ne da bi pri tem morali spreminjati ves sistem. Glede na to, da je vmesnik edini možni način dostopa nj a do objekt o ve podatkovne strukture, je visoka stopnja ponovne uporabnosti objekta zagotovljena, saj ga lahko uporabimo v različnih sistemih, ne da bi nam bilo potrebno spreminjati njegov vmesnik. Sama objektna tehnologija pa za dosego sistematične in razširjene ponovne uporabe še ni dovolj Sistematična ponovna uporaba je institucionaliziran organizacijski pristop k načrtnemu razvoju programskih komponent za ponovno uporabo |4). Razvite komponente je nato potrebno vzdrževati in skladno uporabljati tako, da obdržijo visoko stopnjo ponovne uporabnosti. Na tak način organizacija optimizira sposob- iflxw/l'j «il NfORM AT IKA 1997 Številka 2- letnik V Strokovne razpravi; nost hitre in učinkovite izdelave programskih produktov. V praksi se je izkazalo, da se je za sistematično ponovno uporabo potrebno soočiti tako z vrsto tehničnih, kakor z vrsto netehničnih dejavnikov. Zato so potrebni ustrezni smernice, pristopi, procesi, modeli, metode in orodja. 2. KAJ 2.1. Kaj je ponovna uporaba ? Definicij ponovne uporabe je veliko. Razlikujejo se predvsem po vrsti ponovne uporabe, ki jo obravnavajo (ponovna uporaba brez spreminjanja, ponovna uporaba s prilagoditvijo, ponovna uporaba z razvojem pod-razredov - dedovanjem, direktna in indirektna ponovna uporaba, ipd.) in po vrsti ponovno uporabnih komponent. Vsem definicijam pa je skupno: ponovno uporabili obstoječo programsko opremo pri razvoju nove. Primeri "klasičnih" definicij ponovne uporabe: ■ "Ponovna uporaba je proces ponovne uporabe programske opreme, ki je bila načrtovana za ponovno uporabo." [14] ■ "Ponovna uporaba je posebna oblika "reševanja" programske opreme - ponovna uporaba programske opreme, ki ni bila načrtovana za ponovno uporabo." [14| ■ "Ponovna uporaba je sestavljanje celega ali dela sistema iz že obstoječih komponent. " [3] ■ "Ponovna uporaba programske opreme je proces kreiranja programskih sistemov iz že obstoječih programskih komponent." |Kruegcr) m "Ponovna uporaba je sposobnost razvoja aplikacij s pomočjo obstoječe programske opreme." J6| ■ "Ponovna uporaba je sposobnost uporabe predhodno, v aplikaciji definirane, programske opreme. Komponenta je pri ponovni uporabi samo razširjena, ne pa spremenjena. Komponento lahko vključimo v novo aplikacijo, vendar mora ostati še vedno povezana s svojo prvotno definicjo." [6] ■ "Ponovna uporaba se nanaša na uporabo komponent, ki so bile razvite z nekim izdelkom, v nekem drugem izdelku z drugačno funkcionalnostjo. Na tak način nam olajša razvoj drugih izdelkov. Pri tem pa ni nujno, da je ponovno uporabna komponenta modul ali del programa, lahko je načrt, del priročnika, množica testnih podatkov ali ocena stroškov," |12] 2.2. Kaj lahko ponovno uporabimo? Ponovno uporabna komponenta je katerakoli komponenta, ki je bila namensko ter načrtno razvita za uporabo in tudi dejansko uporabljena v več kot enem kontekstu. 1997 Številka2-letnikV Ponovno uporabne komponente so lahko programi, specifikacije zahtev in načrtovanja, znanje o domeni, procesi, metode, dokumentacija, testni primeri, celi sistemi ali podsistemi, modeli, vzorci, ogrodja, implementacije razredov, primerki objektov ipd. Skratka, gre za vse možne izdelke, ki nastanejo v katerikoli fazi življenjskega cikla razvoja programske opreme od analize do testiranja. Seveda pa pri ponovni uporabi velja zlato pravilo, ki pravi "preden karkoli ponovno uporabimo, mora biti ponovno uporabno". To pomeni, da mora biti komponenta : 1. razvita za ponovno uporabo, 2. shranjena v repozitoriju, kjer jo brez težav najdemo in ustrezno dokumentirana (vedeti moramo, kaj komponenta "dela" in kako jo lahko ponovno uporabimo). 3. Zgornje zahteve se nanašajo na še vedno dokaj pereče probleme kot so shranjevanje in iskanje ponovno uporabnih komponent, opis komponente in ustrezna doku men tira nos t komponente. 3. ZAKAJ Za vsako novo tehniko, metodologijo, pristop obstajajo njeni zagovorniki in nasprotniki. Tudi ponovna uporaba ni izjema. Trazc pravi, da je "ponovna uporaba religija - religija, ki je niso sprejeli vsi, vsaj ne v enaki meri" [14]. 3.1. Zakaj "da" ? Ponovna uporaba ni samo cilj, ampak sredstvo za dosego splošnih ciljev neke organizacije. Dandanes so organizacije pod precejšnjim pritiskom tržišča, prisiljene so zmanjašati tako razvojni čas kakor čas posredovanja izdelka na tržišče, povečati morajo raznolikost ponujenih izdelkov, poleg tega pa povečati standardizira nos t in interoperativnost izdelkov. Ponovna uporaba je sredstvo za dosego teh ciljev. Povečanje produktivnosti razvoja je danes v večini organizacij realna potreba. "Kriza programske opreme" obstaja - razvoj in vzdrževanje programske opreme sta predraga. Graditev in uporaba ponovno uporabne programske opreme bi morala omogočiti, da programska oprema postane premoženje, pridobitev neke organizacije. Ponovna uporaba lahko pripomore k zadovoljevanju strankinih zahtev po večji kvaliteti in funkcionalnosti programske opreme. Vendar prednosti, ki jih ponovna uporaba prinaša, še niso popolnoma izkoriščene in realizirane. Razširjene ponovne uporabe programske opreme, ki bi zajemala celotno "znanje" neke organizacije, še ni [6], Objektna tehnologija vsebuje gradnike (objekte - razrede), i/ katerih je možno graditi ponovno uporabno programsko opremo, vendar ti gradniki sami po sebi niso dovolj za dosego ponovne uporabe. Potrebna sta še primerna ufK mil* NFORM UtK A 1 Strokovne razprave organizacijska infrastruktura in upravljanje razvojnega procesa programske opreme. Ponovna uporaba torej zahteva tako programsko opremo, ki jo je možno ponovno uporabiti, kakor tudi proces kreiranja ponovno uporabne programske opreme (razvoj za ponovno uporabo). Brez teh dveh stvari se ponovna uporaba ne bo "kar zgodila". Prednosti, ki jih lahko z izvajanjem sistematične in učinkovite ponovne uporabe dosežemo, so : ■ nižji stroški bodočega vzdrževanja in samega razvoja (manj testiranja in dokumentiranja, sistemi so sestavljeni iz dobro razumljivih delov), ■ hitrejši razvoj, a večja kvaliteta (ponovno uporabna programska oprema je dobro načrtovana, dobro testirana in dokumentirana) in ■ višja produktivnost. 3.2. Zakaj "ne" ? Na drugi strani brega reke so tisti, ki jih ponovna uporaba ni prepričala. Razlogi "proti" so tako tehnične (komponente je težko integrirati in spreminjati, kvalitetnih ponovno uporabnih komponent je premalo, splošne komponente so preveč neučinkovite, komponente je težko najti) kakor tudi netehnifne narave (psihološki, sociološki in ekonomski). Tracz [141 je zbral nekatera zelo pogosta netehnič-na opravičila - razloge, ki izražajo nenavdušenje razvijalcev in programerjev nad ponovno uporabo: ■ Samo nesposobni posegajo po programski opremi; ki jo je ustvaril nekdo drug. ■ Ponovna uporaba programske opreme izničuje sposobnost ustvarjanja nove programske opreme. ■ Z vpeljavo ponovno uporabne programske opreme bom izgubil(a) službo. ■ Ponovno uporabna programska oprema ne more biti učinkovita. ■ Nočem biti prvi(a). ■ Poskušati ponovno uporabiti programsko opremo nekoga drugega je izguba časa. ■ Ne verjamem, da je ponovna uporabnost programske opreme koncept, ki bo preživel. Prva večja ovira je torej ego - vse preveč profesionalnih razvijalcev programske opreme se bo raje lotilo pisanja programske opreme na novo, kakor da bi ponovno uporabilo že razvito (in testirano) programsko opremo, ki jo je napisal nekdo drug. To je problem managementa, ki ga le-ta lahko odpravi, če je z njim seznanjen. Druga ovira je ekonomske narave. Nekateri razvijalci se poskušajo izogniti pisanju programske opreme, ki je preveč splošno namenska, ker se bojijo, da se bo s ponovno uporabo take programske opreme količina dela, ki jo morajo vložiti, preveč povečala. Tudi ta prob- lem se da rešiti z ustreznim posredovanjem managementa. Tretja ovira je problem iskanja. Neka organizacija ima lahko zelo veliko potencialno ponovno uporabnih komponent. Postavlja se vprašanje, kako te komponente shraniti, da bo iskanje učinkovito. Rešitev problema shranjevanja in iskanja komponent je tehnične narave. Danes je za ta problem podanih že kar precej različnih rešitev - že pregledovalniki, brkljalniki, CASE orodja so pri pregledovanju knjižnic lahko zelo učinkoviti (nekatere rešitve najdete v Meyer, 1987; Prieto-Diaz, 1991; Karlsson, 1995; in drugi). Četrto oviro predstavlja cena ponovne uporabe. Ponovna uporaba je draga. Tracz f!4| je stroške ponovne uporabe razdelil v tri skupine: strošek, ki ga imamo, ko želimo "nekaj" narediti ponovno uporabno, strošek pri ponovni uporabi le-tega in strošek definiranja ter implementiranja procesa ponovne uporabe. Ocenil je, da že sam postopek, ko želimo komponento narediti ponovno uporabno, poveča ceno te komponente za vsaj 60 odstotkov. Nekatere organizacije so poročale o 200 in celo več kot 4HI> odstotnem povečanju stroškov, pri projektu ponovne uporabe firme Hewlett-Packard pa je bilo to povečanje samo 11 odstotno. Peta ovira je najtežje premostljiva in rešljiva. Gre za pravne probleme, ki se porodijo pri pogodbeni programski opremi. V pogodbi, ki jo podpišeta proizvajalec in kupec programske opreme, navadno piše, da je programska oprema last stranke, kupca. Torej, če razvijalec v novem izdelku za novo stranko ponovno uporabi komponento, ki je del izdelka, ki ga je neki drugi stranki prodal, pomeni to kršitev pogodbe. Ko sta razvijalec in stranka v isti organizaciji, navadno to ni poseben problem [12]. Torej, razen pravnih problemov, ne obstajajo resnejše ovire, ki bi preprečevale implementiranje ponovne uporabe v organizaciji, ki se ukvarja z razvojem programske opreme. 4. KDAJ 4.1. Kdaj začeti s ponovno uporabo ? Zastavljeno vprašanje bi lahko tudi preoblikovali v vprašanje "kje se ponovna uporaba začne". Pri odgovoru na vprašanje se moramo osredotočiti na tri področja - na tri P-je ponovne uporabe programske opreme [141. Ti so: 1. produkt (izdelek) ali kaj bomo ponovno uporabiti, 2. proces ali kdaj bomo ponovno uporabo izvajali in 3. personal (osebje) ali kdo bo ponovno uporabo izvajal. Lahko bi jih tudi poimenovali trije K-ji ponovne uporabe : Kaj, Kdaj in Kdo. ufj(™/nriilNFORMaTIKA 1997 -Številka 2 letnik V Strokovn e razprave Odgovori na ta vprašanja so zelo pomembni, kajti če so odločimo, da bomo zgradili orodje, ki nam bo v pomoč pri ponovni uporabi programske opreme, potem moramo vedeti, kaj bomo poskušali ponovno uporabiti, kdaj bomo to storili in kdo bo (o uporabljal. 4.2. Izdelek Ce imamo pri odgovdrjanju na zastavljeno vprašanje v mislih izdelke, ki so ponovno uporabni, potem se lahko vprašamo, ali se ponovna uporaba začne s programi (navadno se pri kodi ponovna uporaba neha). Glede na to, da je vrst kode več (izvorna koda, koda objekta, stavek visokonivojskega jezika, funkcija, procedura, paket, modul ali cel program), se moramo zavedati, da je uspeh ponovne uporabe kode odvisen od zmatosti kode, ki jo ponovno uporabimo. Večja je zrnatost, boljši bo uspeli. Velja namreč, da mora biti napor, vložen v iskanje, razumevanje in integriranje ponovno uporabnih komponent manjši od napora, ki je potreben za načrtovanje in pisanje kode na novo. Zato je bolj priporočljivi) ponovno uporabiti objekte z visoko zmatostjo, kot so paketi, moduli ali razredi. Naslednji pomemben faktor uspeha je nivo abstrakcije. Ker se nahaja načrtovanje na višjem nivoju abstrakcije kot implementacija, se lahko vprašamo, ali ni umestneje, da s ponovno uporabo začnemo v fazi načrtovanja. Prednost začetka ponovne uporabe pri načrtovanju je ravno višji nivo abstrakcije - načrtovanje vključuje manj iinplementacijskih podrobnosti. Če sledimo nivoju abstrakcije, potem lahko mirno trdimo, da se ponovna uporaba lahko začne že na nivoju specifikacije ali celo, da se lahko začne z definicijo problema - zahtev. Kar zagotovo vemo, je, da se ponovna uporaba na splošno konča s ponovno uporabo kode. Kje se bo začela, je odvisno od [14|: 1, količine napora, ki ga Želimo vložiti v razvoj ponovno uporabnih izdelkov, 2, kako učinkovito lahko razvoj ponovno uporabnih izdelkov povežemo z implementacijo in 3, kako uspešno lahko implementacijo posplošimo. Pri prehajanju po fazah slapovnega (kaskadnega) modela navzdol od zahtev do implementacije, lahko ugotovimo, da je vsakemu izdelku dodanih nekaj podrobnosti. Implementacija je torej primerek načrtovanja. Za posamični načrt imamo lahko več implementacij, kakor imamo lahko več načrtov, ki zadoščajo specifikacijam. Ključnega pomena je združevanje skupnih lastnosti (osamitev sprememb), pri čemer ločimo kontekst od koncepta in vsebine, kar pomeni, da imple-mentacijski cilji, kot so specifični operacijski sistem ali odvisnosti od strojne opreme, niso del vsebine. Vsebino sestavljajo algoritem, pretok podatkov ali del specifikacije funkcionalnosti, koncept postane funkcionalna specifikacija. Vsebina postane predloga, vzorec ali 19S7 Številkah-fetntkV splošen objekt. Kontekst postane možna opredelitev parametrov. Po Tracz-ovem mnenju [14] je koda dovolj varno mesto za začetek in, v večini primerov, tudi dovolj varno mesto za zaključek ponovne uporabe. 4.3. Proces Ce opazujemo proces razvoja programske opreme, lahko ugotovimo, da se večina ponovne uporabe začne v fazi implementacije. To je seveda možno, če je bila programska oprema načrtovana za ponovno uporabo - možno jo je prenesti v nov kontekst, in če se je ne da uporabiti brez sprememb, SO predvideni in vgrajeni parametri, preko katerih je možno programsko opremo prilagoditi potrebam ali novemu kontekstu. Torej se ponovna uporaba začne že v fazi načrtovanja. Objektno usmerjeno načrtovanje pomaga zmanjšati problem načrtovanja tako, da je le-to neodvisno od implementacije, ne more pa tega problema popolnoma rešili. Ključnega pomena za nadzor procesa je še vedno pa-rametrizadja \ 14]. Če začnemo proučevati, kaj je razpoložljivega, bolj zgodaj v procesu razvoja, npr. v fazi specifikacije in analize zahtev, je možno načrtovanje prikrojiti tako, da lahko izkoristimo obstoječo programsko opremo. V klasični slapovni model življenjskega cikla razvoja programske opreme so strokovnjaki vključili novo fazo, ki podpira ponovno uporabo. To je faza analize domene. Analiza domene je posplošitev analize zahtev - namesto, da bi analizirali zahteve za specifično aplikacijo, ovrednotimo zahteve splošne aplikacije skozi konkretno domeno [ti] (analiziramo zahteve za splošne možne aplikacije znotraj domene). Najboljši trenutek za začetek ponovne uporabe je pred začetkom projekta. Takrat lahko definiramo proces razvoja, postavimo knjižnice s ponovno uporabno programsko opremo ter razvijemo standarde in orodja. Obstaja pa tudi možnost začetka ponovne uporabe po zaključenem projektu - v prvem koraku razvijemo programsko opremo, v drugem koraku pa izluščimo podobnosti med aplikacijami. Na tem mestu je vmesno Biggerstaff-ovo "pravilo treh" [ 13], ki pravi: "Ce nisi razvil treh realnih sistemov v določeni domeni, potem si nesposoben izluščiti tiste podrobnosti o domeni, ki so potrebne za uspešno ponovno uporabo v tej domeni." Drugo pravilo treh pa pravi: "Preden lahko izkoristiš prednosti ponovne uporabe, moraš izdelek najprej trikrat ponovno uporabiti." Kje se v življenjskem ciklu razvoja programske opreme ponovna uporaba začne, je odvisno od tega 114]: 1. Kako nekdo spremeni proces razvoja programske opreme, da bo izkoristil možnost ponovne uporabe, in 2. Kako nekdo bodisi spremeni bodisi razširi življenjski cikel programske opreme, da bo lahko identificiral objekte, ki jih bo "naredil" ponovno uporabne. upoMbnA NFORHATIKA J ^ Strokovne razprave 4.4 Osebje Oseb j t' predstavlja ključne akterje v igri ponovne uporabe. Prvi igralec je programer. Od njega je namreč odvisno, kako uspešno bo identificiral obstoječo ponovno uporabno programsko opremo. Lahko bi se torej ponovna uporaba začela pri programerju. Vendar, Če želi programer nekaj ponovno uporabiti, mora to že obstajati. Zato mora obstajati kritična masa kvalitetne programske opreme. Imeti prazen repozitorij ali v njem imeti nekvalitetno in slabo dokumentirano programsko opremo, za programerja ni najbolj vzpodbudno. Navedeni problem je povezan z visokimi stroški, zato mu pri tem lahko pomaga le najvišji management, ki se odloči, da bo podpri izvajanje ponovne uporabe in visoke začetne stroške. Denar pa tudi ni dovolj. Potrebno je izobraževanje, osveščanje - tečaji iz analize domene, konstrukcije aplikacij, programiranja s para m etri/, i lijem, na razpolago pa morajo biti že izdelane knjižnice komponent, ki olajšajo gradnjo novih aplikacij. Ponovna uporaba se lahko začne tudi pri razvijalcu orodij, ali pri stranki, prodajalcih (ti poznajo tržišče in potrebe po ponovno uporabnih komponentah), lahko pa celo pri sistemskem analitiku (zna analizirati problemsko domeno, zna določiti logične podsisteme in funkcije in zna določiti vsebino ali zahteve za module ter predvideti različne kontekste, v katerih lahko te module uporabimo). V proces vzpostavljanja ponovne uporabe je torej lahko vključenih kar nekaj ljudi. Nekateri odigrajo bolj tehnične, drugi povsem netehnične vloge. Dejstvo pa je, da morajo za dosego učinkovite ponovne uporabe med seboj Lesno sodelovati. 5. KAKO 5.1. Kako doseči učinkovito in sistematično ponovno uporabo ? Za uspešno in učinkovito ponovno uporabo so potrebne organizacijske spremembe, planiranje ponovne uporabe, nove vloge, širjenje "kulture" ponovne uporabe in izobraževanje, razvoj programske opreme za ponovno uporabo, katalogiziranje ponovno uporabnih komponent, predvsem pa se moramo zavedati, da ponovna uporaba ni zastonj, ampak so začetni stro£ki lahko zelo visoki. Nekateri ključni pogoji f3j, ki morajo biti v organizaciji izpolnjeni, če želimo, da bo ponovna uporaba uspešna, so: ■ višji vodilni delavci morajo razumeti in predvsem podpreti program ponovne uporabe, ■ potrebne so realne ocene stroškov predvidene investicije, a potreben je model življenjskega cikla, ki podpira in vzpodbuja ponovno uporabo (kot najprimer- nejša sta se izkazala spiralni model in model hitrega prototipi ranja), ■ potrebna je knjižnica ponovno uporabnih komponent, ■ potrebna so sredstva za dokumentiranje in dostop do komponent preko njihove specifikacije, ■ potrebna so primerna orodja, m nagrajevalnl sistem ekipe za ponovno uporabo mora biti primeren in stimulativen, ■ razvijalci morajo biti izkušeni, spretni in predvsem motivirani. Nujni koraki, ki jih mora izvesti organizacija, ki želi doseči uspešno in učinkovito ponovno uporabo (in izkoristiti prednosti, ki jih ta ponuja), so navedeni v nadaljevanju. 5.2. Ekipa Sestaviti je potrebno ekipe za ponovno uporabo, določiti vloge posameznih članov ekip in njihove aktivnosti [9]. Aktivnosti članov ekip za ponovno uporabo so: definiranje (kaj naj bo ponovno uporabljeno in kako), identificiranje (določitev komponent, ki bodo ponovno uporabne), pridobivanje (graditev, nakup ali pogodbena pridobitev ponovno uporabnih komponent), certi-ficirnnjc (sledenje smernicam spremenljivosti), klasificiranje (organiziranje in označevanje komponent), shranjevanje, komuniciranje (iskanje močnih ponovnih uporabnikov), lociranje (iskanje shranjenih komponent), ponovno pridobivanje komponent, razumevanje (določitev namena in značilnosti komponent), uporabil (integriranje komponent v nov kontekst), ažuriranje komponent (prilagajanje, spreminjanje, razširjanje, popravljanje, testiranje komponent), ažuriranje ponovnih uporabnikov (ažuriranje vseh sistemov, ki uporabljajo spremenjene komponente). Ključne vloge v ekipah za ponovno uporabo so : nadzornik (planira in nadzoruje proces ponovne uporabe), administrator (identificira in pridobiva komponente), vzdrževalec {vzdržuje obstoječe komponente v knjižnici), ocenjevalec (zagotavlja ustreznost komponent, proizvaja in iz.vaja testne plane), knjižničar (cer-tificira, kategorizira in shranjuje komponente v knjižnico, zagotavlja ujemanje dokumentacije in razširja kataloge knjižnic), inženir (gradi ponovno uporabne komponente). 5.3. Planiranje Uspešno in sistematično ponovno uporabo je potrebno planirati. Zato je potrebno sestaviti program ponovne uporabe, pri Čemer so najpomembnejše aktivnosti: ■ določitev nadzornika, nato pa še administratorja, inženirja in knjižničarja {ključne vloge), lytmih ¡«INFORMATIKA 1997 < številka Z - lelnik V Strokovn e razprave ■ oblikovanje celotne ekipe (sodelujejo lahko tudi stranke, dobavitelji, upravljala), ■ definiranje ponovne uporabe {kaj in kako ponovno uporabiti) in identificiranje ponovno uporabnih komponent, ■ izvajanje različnih klasifikacijskih shem, a certificiranje začetne množice komponent (približno 3 mesece po začetku izvajanja programa), ■ formaliziranje sheme certifiriranja in določitev načina merjenja ter ocenjevanja komponent, ki so že v repozitoriju (po šestih mesecih) - pilotski projekti, ■ ocenitev programa metrik (po enem letu). 5.4. Katalogiziranje Množice ponovno uporabnih komponent je potrebno katalogizirati | Kl|. Katalog množic ponovno uporabnih komponent programske opreme (SAC-Softvvare Asset Catalog) je elektronski katalog, podoben kartotečnemu katalogu v knjižnici, v katerem vsebuje vsak kartonček kratek opis enote, podatek o tem, kje se nahaja, kdo je njen avtor in druge informacije. Za tak katalog morajo biti definirani proces dodajanja množice komponent katalogu, iskalni mehanizem, katalog mora biti dostopen večim uporabnikom, zagotovljena mora biti varnost, vsebovati mora pripomoček za vključevanje drugih izdelkov programske opreme, definiran mora biti klasifikacijski mehanizem, realizirana mora biti registracija oz. prijava uporabnika kataloga in katalog mora biti dostopen širšemu krogu uporabnikov. Koraki pri kreiranju ali ustanovitvi kataloga množic ponovno uporabnih komponent so : 1. Kreiranje osnovnega klasifikacijskega načrta na podlagi domene (organizacija podatkov, enote v katalogu, lip kataloga, kataloška orodja in njihove iskalne sposobnosti) v sodelovanju z uporabniki kataloga, 2. Določitev repozitorija množice ponovno uporabnih komponent {SAR - Software Asset Repository) - lokacije, na kateri bodo komponente shranjene. 3. Določitev začetnega seznama množic ponovno uporabnih komponent (20 do 30 komponent). i- Kreiranje ali nakup orodja za katalogiziranje ponovno uporabnih komponent (orodje, ki zagotavlja osnovne iskalne in klasifikacijske sposobnosti). 5. Definiranje procesa dodajanja množic ponovno uporabnih komponent v katalog (definiranje procesa katalogiziranja, ki navadno vključuje odo-britveno-potrditveni korak, le-ta pa omogoča pregled množice ponovno uporabnih komponent pred vključitvijo v katalog). 6. Ponovni pregled klasifikacijskega načrta (ob povečanju števila množic ponovno uporabnih komponent) in izboljšanje le-tega,čeje potrebno. 1997 številka 2 ■ letnik V 7. Postopno dodajanje množic ponovno uporabnih komponent v katalog. Zgraditev kataloga ponovno uporabnih komponent je lahko prvi korak k doseganju ponovne uporabe, vendar brez vzpostavitve samega procesa ponovne uporabe in procesa kreiranja ponovno uporabnih komponent (razvoja za ponovno uporabo) uspeh ni zagotov Ijen. Sam proces ponovne uporabe vzpostavimo z dolgoročnim programom ponovne uporabe, ki ga pa spremljajo tudi nujne spremembe. Prieto-Diaz (93) poudarja, da problem inženirstva programske opreme ni pomanjkanje ponovne uporabe, ampak pomanjkanje razširjene, sistematične ponovne uporabe. 6. "MITI" PONOVNE UPORABE PROGRAMSKE OPREME Pred desetimi leti je Will Tracz, že tedaj zagovornik ponovne uporabe, zapisal devet "mitov" ponovne uporabe programske opreme, ki izražajo določene tehnične, organizacijske in psihološke cilje in trende raziskave inženirstva programske opreme v tistem času (kaj naj bi ponovna uporaba programske opreme bila). Ti "mili" delno tudi razložijo, zakaj se ponovna uporaba do danes, ni prav močno razširila, vsaj ne toliko kot so to predpostavljali tedanji "preroki iz sveta programiranja". !. Ponovna uporaba programske opreme je problem tehnične narave. 2. Za ponovno uporabo programske opreme so potrebna posebna orodja. 3. Rezultat ponovne uporabe kode je precej povečana produktivnost. 4. Umetna inteligenca bo rešila problem ponovne uporabe. 5. Japonci so rešili problem ponovne uporabe. 6. Ada in C+ + sta rešila problem ponovne uporabe. 7. Načrtovanje programske opreme na osnovi ponovno uporabnih delov lahko enačimo z načrtovanjem strojne opreme na osnovi integriranih vezij. 8. Ponovno uporabljena programska Oprema je isto kot ponovno uporabna programska oprema. 9. I 'ono vna uporaba se bo " kar zgodila". Leta 1994 je Tracz ponovno obdelal in preučil teh devet "mitov" in jih glede na takratno stanje (ki se marsikje ne razlikuje veliko od današnjega) ponovne uporabe preoblikoval oziroma dopolnil: 1. Ponovna uporaba je problem tako tehnične kot netehnične narave, 2. Za ponovno uporabo niso potrebna nobena "posebna" orodja. Zadostuje nam razpoložljiva tehnologija podatkovnih baz, ki jo lahko uporabimo pri organiziranju in iskanju programske opreme, shxanjene v velikih repozitorijih. i /f M jrabriof N FOR M ATI KA ^^ Strokovn e razprave 3. Samo ponovna uporaba kode ne bo povzročila velikega povečanja produktivnosti in kvalitete. 4. Umetna inteligenca ima lahko določeno vlogo pri reševanju problema ponovne uporabe. 5. Japonci so naredili prvi korak k rešitvi problema ponovne uporabe. 6. Noben programski jezik ne more sam rešiti problema ponovne uporabe, 7. Načrtovanje programske opreme s pomočjo ponovno uporabnih delov ni ravno enako kot načrtovanje strojne opreme s pomočjo integriranih vezij. 8. Ponovna uporaba programske opreme, ki ni bila načrtovana za ponovno uporabo, je težja, kakor ponovna uporaba programske opreme, načrtovane za ponovno uporabo. 9. Ponovna uporaba se ne bo "kar zgodila"; 7, NAMESTO ZAKUUČKA ali KRITIČNI FAKTORJI USPEHA Večina Študij uspešnih programov ponovne uporabe, ki jih je opravila družba Technology Trarisfer International (TT1) i/, Colorada na primerih precejšnjega števila japonskih organizacij (tudi Fujitsu, Hitachi, Oki in Toshiba), je pokazala, da so /.a uspešnost potrebni [9]: ■ Kritična masa: razpoložljivost dovolj velike množice ponovno uporabnih komponent. m Razumljivost: sposobnost razumevanja kode, ki so jo pisali drugi. ■ Integriranje: sposobnost združevanja ponovno uporabnih komponent /. novimi zahtevami. ■ Kulturno prelivanje: posredovanje pridobljene kulture ponovne uporabe novincem in pogodbenim strankam. ■ Vedenje: premostitev konzervativnih pogledov starejših razvijalcev programske opreme. Že med študijo so se med člani ekipe pojavile prepričljive ugotovitve o izboljšanju produktivnosti kot posledice sistematične ponovne uporabe: ■ razvojni čas se je skrajšal od 10 do 50 odstotkov, ■ produktivnost se je zvišala za IS do 50 odstotkov, ■ kvaliteta se je izboljšala za 20 do 35 odstotkov. Nekaj ponovne uporabe se je pojavilo tudi v lazi analize zahtev. To je možno doseči le, če si že med analizo postavimo za cilj identificirati možnosti za ponovno Uporabo. Zanimiva je tudi ugotovitev, da je večina ponovno uporabljenega koda sestavljena iz majhnih komponent (manj kot 1000 vrstic). Po mnenju članov ekipe je omenjene pridobitve možno doseči le, Če si jih predhodno postavimo kot dolgoročne cilje. 8. VLOGA PONOVNE UPORABE V SODOBNIH TEHNOLOGIJAH Trenutno v svetu vse bolj prodira tehnologija porazdeljenih objektov (distributed object technology). Le-ta nam omogoča izgradnjo programske opreme z integracijo komponent - objektov f5J. Ti porazdeljeni objekti niso vezani na noben določen program, programski jezik ali implementacijo. Eden izmed ključnih problemov, ki jih tehnologija porazdeljenih objektov naslavlja, je torej tudi ponovna uporaba (poleg prenosljivosti in povezljivosti programske opreme). Porazdeljeni objekti so posebne ponovno uporabne komponente, ki se nahajajo nekje v omrežju in so sposobne med seboj komunicirati. Na področju inženirstva programske opreme pa postaja vse bolj vroča tema tudi tehnologija komponent oziroma razvoj programske opreme na podlagi komponent (CRSD - Component Based Software Development). Ponovna uporaba in uporaba programskih komponent imata vedno večji vpliv na strukturo programskih sistemov, prav tako pa tudi na način njihove gradnje. Graditev programske opreme iz komponent obljublja več ponovne uporabe in višjo produktivnost. Sistemi naj bi bili zgrajeni i/, med seboj sodelujočih, dobro testira ni h komponent, kar zmanjša kompleksnost sistemov (v primerjavi s sodobnimi sistemi, ki so zgrajeni kot monolitni bloki iz velikega števila med seboj nepovezanih delov) in stroške vzdrževanja. V bodočnosti naj bi torej razvoj programske opreme s ponovno uporabo prevzel vodilno mesto, ki ga danes še vedno zaseda razvoj programske opreme na novo. Razvoj programske opreme naj bi prešel iz kompozicije enostavnih stavkov kode v sintezo velikih komponent iz številnih majhnih {t.i, mega program i ran je) [