Strokovne razprave Razvoj programske opreme z uporabo jezim um l Aleš Živkovič, Marjan Heričko, Ivan Rozman Fakulteta za elektrotehniko, računalništvo in informatiko Inštitut za informatiko e-poita: {ales.zivkovic, marjan.hericko, !.rozmari}@uni-mb.si Izvleček V prispevku je predstavljen jezik za dokumentiranje dela in rezultatov pri objektnem razvoju programske opreme. Predstavili bomo zgradbo jezika UML, diagramske tehnike in dodatne izrazne možnosti, vpeljane v obliki dopolnitev k osnovnim gradnikom jezika. Zelo natančen in dobro zasnovan standard pa ne zajema napotkov za uporabo jezika, zato potrebujemo še proces. Spoznali bomo, da univerzalnega procesa nt, prilagoditi ga moramo okolju, v katerem se uporablja, in ga nenehno izboljševati. Podali bomo priporočila za oblikovanje procesa razvoja programske opreme, kadar sledimo objektni paradigmi. Abstract In the paper language for documenting software development artifacts will be presentee/. First the structure, diagram elements and supplemental expressive possibilities introduced as an extension mechanisms for basic techniques will be described. Unfortunately, weII-formed standard doesn't define when and how to use Its elements. Therefore we need the software development process to define steps, inputs and outputs for each step. There Is no single process suitable for all the environments. Process needs to be tailored to environment specifics and continuously improved. Recommendations for forming an object-oriented software development process will also be presented. 1. Uvod Kljub vedno boljšim integriranim okoljem za razvoj programske opreme, ki nam omogočajo enostavno delo in abstrakcijo kode, ki nastaja, je potreba po modeliranju in načrtovanju programske opreme neizmerna. Tehnološki koncepti, ki vodijo do učinkovitih rešitev, so postati kompleksni. Direkten preskok v implementacijo, brez jasno začrtane poti, je praktično nemogoč, če pa že, pa je zagotovo neučinkovit in časovno potraten. Načrte potrebujemo v takšni ali drugačni obliki. Lahko jih oblikujemo čisto samoiniciativno in na svoj način ali pa sledimo natančno določenim postopkom in korakom. Veliko je odvisno od skupine, tipa in velikosti projekta in nenazadnje organizacije in vodstva. Nc glede na vse to, se razvijalci zavedamo prednosti uporabe posameznih diagramskih tehnik, ki v nobenem pogledu niso /golj lepe slikice. So način komuniciranja na višjem, bolj razumljivem nivoju abstrakcije in s tem neodvisni od izbranega programskega jezika. Zaradi množice notacij, ki so bile v preteklosti v uporabi, je bila komunikacija med razvijalci otežena in je pogosto povzročala zmedo. Po letu 1996 so različne notacije konvergirale v en sam, standarden nabor diagramskih tehnik, prvič predstavljen na konferenci OOPSLA'95 [3J. Kasneje so pobudo podprla številna podjetja, kot tudi skupina OMG[5]. Vpeljano je bilo ime Unified Modelling Language {UML) [5], ki še bolj poudarja, da proces v njem ni zajet. Dobili smo standarden jezik za dokumentiranje postopkov in rezultatov pri razvoju programske opreme. Značilnosti lahko strnemo v naslednjih točkah: m je vizualno orodje za modeliranje, ■ ima standardizirano notacijo, m omogoča zajemanje poslovnega procesa; ■ izboljša komunikacijo, ■ omogoča obvladovati kompleksnost, ■ definira arhitekturo programske opreme, ■ pospešuje ponovno uporabo, ■ omogoča uporabo poljubnega razvojnega procesa. Razvoj jezika prikazuje slika L 2. Jezik UML Jezik UML definira notacijo in metamodel jezika. Notacija je grafična predstavitev jezika, sintaksa, ki sama po sebi ne daje jasnega in nedvoumnega pomena posameznih konstruktov. Splošna uporaba notacije uptvabi uA NFOR M ATI K A 2000 številka A • letnik VIII Aleš ŽivkoviČ, Marjan Heričko, Ivan Rozman: Razvoj programske opreme z uporabo jezika UM L druge metode Slika 1: Zgodovinski razvoj jezika UML največkrat definira nekatere neformalne definicije, toda boljf bi bilo poiskati bolj formalno definicijo. Ideja rigoriznih specifikacij in jezikov načrtovanja prevladuje pri uporabi formalnih metod. Kadar uporabljamo tehnike s tega področja, izražamo specifikacije in načrtovanje s pomočjo izpeljank predikatnega računa. Takšne definicije so matematično natančne in ne dopuščajo dvoumnosti/ a na žalost niso vsesplošno uporabne. Tudi kadar lahko dokažemo, da program zadovoljuje matematično specifikacijo, nikakor ne moremo dokazati, da te specifikacije v resnici izpolnjujejo uporabnikova pričakovanja. Avtorji jezika za objektno modeliranje UML so jeziku zagotovili formalno podlago, ne da bi žrtvovali njegovo uporabnost. Ena od možnosti je definicija metamodela - največkrat razrednega diagrama, ki definira notacijo in natančno ter nedvoumno definira pomen posameznih gradnikov. Avtorji so jezik /,a objektno modeliranje UMI. zgradili štiriplastno: ■ Meta-metamodel, ki definira jezik za specifikacijo metamodela in predstavlja infrastrukturo za arhitekturo metamodela. ■ Metamodcl, ki je primerek meta-metamodela in definira jezik za specifikacijo modelov. ■ Model, ki je primerek metamodela in definira jezik za opis informacijske domene. m Uporabniški objekti, ki so primerki modela in definirajo konkretno informacijsko domeno. TakSna zasnova jezika omogoča uporabo jezika na vseli področjih, saj vsebuje gradnike, ki omogočajo modeliranje različnih sistemov. Poleg formalne zasnove jezika so avtorji dodali tudi jezik OCL (Object Conširaint Liingtiage) — jezik za določanje omejitev, ki je popolnoma formalen in omogoča oblikovanje omejitev vseh modelov (vloge v asociacijah, Števnost povezav, pred- in po-pogoji metod, ipd.). Kot kažejo izkušnje, je kombinacija formalne zasnove jezika za modeliranje prinesla prednosti na dveh področjih. Po eni strani je jezik splošno uporaben, a jasno definiran, kar omogoča uporabo jezika UML na vseh problemskih področjih, po drugi strani pa jasno definirana struktura jezika omogoča lažji razvoj podporne programske opreme. 2.1 Gradniki Iz diagramskih tehnik jezika UML lahko razberemo Štiri različne poglede na problemsko področje. Prvi je pogled na uporabniške zahteve, kjer uporabljamo diagram primerov uporabe (lise case diagram), ki izvira neposredno i/, Jacobsonpve metodologije in je bil za potrebe jezika UML poenostavljen. V drugo skupino lahko uvrstimo razredni diagram (class diagram), ki prikazuje statično sliko sistema. Razredni diagram je sestavljen iz razredov in povezav med razredi in je le nekoliko spremenjena diagramska tehnika iz metodologije OMT (Object Modeling Technique, Runibaiigh)[l\. Tretji pogled predstavlja skupina diagramskih tehnik, ki modelirajo obnašanje programskega sistema. Tu najdemo diagram prehajanja stanj (statechart diagram), s katerim opisujemo prehajanja stanj za posamezne 2000- številka4 -letnik VIII tipambnd NFORM ATIKA Aleš ŽivkoviČ, Marjan Heričko, Ivan Rozman: Razvoj programske opreme z uporabo jezika UM L razrede, in diagram aktivnosti (netivi 11/ diagram), ki prikazuje izvajanje aktivnosti in dovoljuje tudi modeliranje paralelnih aktivnosti. Tretji pogled na programski sistem je pogled na interakcijo objektov, ki zagotavljajo določeno funkcionalnost celotnega sistema. V io skupino spadajo diagram zaporedja (sequence diagram), ki prikazuje tipično interakcijo objektov v sce- narijih uporabe sistema, in diagram sodelovanja (collabo-rntion diagraftl), ki prikazuje način sodelovanja med množico objektov z namenom izvršiti določeno operacijo. Zadnjo skupino tvorijo diagrami implementacije^ s katerimi prikažemo implementacijske konstrukte. V jeziku UML so to komponentni diagram (component diagram), ki prikazuje organizacijo komponent, in diagram razvoja in dobave (deploi/mcnl diagram), s katerim prikažemo konfiguracijo programskega sistema in okolja, kamor sistem namestimo. Pogost način pomenskega združevanja in s tem dopolnjevanja posameznih diagramskih tehnik je takšen: ■ diagrami primerov uporabe -i- diagrami zaporedja 4- diagrami sodelovanja, m razredni diagrami 4- diagrami prehajanja stanj + diagrami aktivnosti, ■ diagrami komponent + arhitekturni diagrami. Jezik UMI. lahko uporabimo za: » prikaz mej sistema in osnovnih funkcionalnosti (primeri uporabe), ANALIZA IN NAČRTOVANJE Analiza Tiskanj« J Arhitekturno načrtovanje Nadzornik —i-T _ Fíame nt i diagrama I Transakcija Rebuje-^ Kgrak L±Í_ Osnovni elementi Aj. Grafično jedro Račun Potrdilo Polog Dvig iimnu Ul Gosposka bilixurHAt Aban ka . bunka Vfiflsi gonto OtiJímslecliPí idjnmnlno Načrtovanje objektov je lastnik Transakcija O vsebuje Korak Račun T Potrdilo Polog Dvig Strelnih aastltell: PC s. o ...T1 RDBMS T, Slroinik v . 1 Oanovnl «kr«n ¡zvedtf prikazuj □snovni okran WkrLcji Pr*y®fjanj» goBla io Bankomat.. Preveri Karto) ki odvzet !?y*du'pi»bori In prevari g«ilo - ■ o odvromu j LJ Timital)!d.i..:: (±3_ " ........€ 1>.1P L.133 Preveri geslo Preveri stanje " s* T ■ o og (ïir.tVLlift [ïtonja - »»o] v ¡gm X CMo Vr*«i g« o BOtpQWI ujxmtbf («INFORMATIKA 2000 étevilha 4 letnik VIII Aleš ŽivkoviČ, Marjan Heričko, Ivan Rozman: Razvoj programske opreme z uporabo jezika UM L IMPLEMENTACIJA KODA Banka -(vmesnik) <7 Bankomat Ime paketa odvisnosl ~| Ima pa kola -(vmasnik) ]| Uporabniški vmesnik TESTIRANJE 1 Ime paketa odvlanonl , Imo pakoto Slika 2: Shematsk) prikaz uporabe diagramskih tehnik Rtutvd i ■ prikaz realizacije sistema {diagrami interakcije), a prikaz statične strukture sistema (razredni diagrami), ■ modeliranje obnašanja objektov (diagrami stanj), ■ določitev fizične implementacije arhitekture (arhitekturni diagrami). Osnovne gradnike lahko dopolnimo z naslednjimi koncepti; ■ Stere&liy (stereotype) - poljubnemu elementu jezika damo nov pomen, oziroma pomen prilagodimo zahtevam razvojnega procesa. ■ Imenovnna vrednost (tagged values) - par oznaka, vrednost lahko dodamo kateremukoli elementu modela. Nekatera imena so že definirana. ■ Omejitve (constraints) - diagram lahko natančneje opišemo in dodamo natančne pogoje kdaj in pod kakšnimi pogoji se bo nekaj zgodilo. 3. Razvojni proces 3.1 Vpliv procesnega modela na projekt Iz primerjave vplivov različnih dejavnikov na projekt [7] lahko posredno sklepamo, da je urejenost postopkov in ponovljivost pri izvajanju projektov prav tako pomemben dejavnik, saj je zrelost organizacije bodisi po Zrelostno zmožnostnem modelu (Capability Maturity Model CM M) ali skladno s standardom 90003 [6] označena kot tretji najbolj pomemben dejavnik, takoj za človeškim faktorjem in pretokom informacij med vpletenimi v projekt. S poznavanjem CM M in ISO 9000-3 lahko ugotovimo posredno pomembnost uporabe procesnega modela za razvoj programske opreme. Predpostavko potrjuje povezava med uspešnostjo, obsegom projekta in uporabo procesnega modela. Iz slike 3 lahko razberemo, da je uporaba natančno določenih postopkov pri razvoju programske opreme bolj pomembna pri večjih projektih, kjer je odstotek uspešno zaključenih projektov bistveno večji v primerjavi s projekti, kjer se procesni model ni uporabljal. Povedali smo že, da je jezik UMI. zgolj notacija in ne metoda razvoja, saj nima definiranega procesa razvoja, ki je pomemben del metode. Avtorji so že na samem začetku ugotovili, da splošnega procesa razvoja ne bo moč razviti, zato predlagajo uporabo ogrodja, kjer si vsak uporabnik proces lahko prilagodi svojim zahtevam in uporabi tiste diagramske tehnike, ki so primerne in smiselne za njegov razvojni proces. 2000 - Številka 4 - letnik VIII lifwukiiulNFORMATIKA Aleš ŽivkoviČ, Marjan Heričko, Ivan Rozman: Razvoj programske opreme z uporabo jezika UM L Uspešnost projektov glede na obseg In uporabo procesnega modela S 'o majhon zelo velik Obseg p roj akta Projokl ni bil uspeien, proces se nI uporabljal Projekt ni bil uspešen, proces se je uporabljal . , Projekt je bil uspešen, 1 -* proces se ni uporabljal ,__ Projekt je bil uspešen, ™™' proces se jo uporablja! Slika 3: Vpliv uporabe procesnega modela na projekt Prototipiranje Gre za strategijo, ki jo lahko uporabljamo pri večini aktivnosti. Namen prototipiranja je iskanje informacij, potrebnih za sprejem odločitev. Zmanjšuje tveganje glede napačnih odločitev pri zajemanju zahtev in načrtovanju arhitekture sistema. Prototip je predhodna in namenoma nepopolna verzija sistema. Običajno ni prepričljivo izdelan in ne zadošča zahtevam robustnosti končnega proizvoda, S svojim obstojem povečuje zaupanje, da je želeni produkt moč izdelati. Ponovna uporaba Ponovna uporaba programske opreme je sposobnost razvoja aplikacij iz že obstoječe programske opreme in na osnovi izkušenj, dokumentiranih v obliki vzorcev. Prednosti, kijih lahko z izvajanjem sistematične in učinkovite ponovne uporabe dosežemo, so nižji stroški bodočega vzdrževanja, hitrejši razvoj, večjai kakovost in višja produktivnost. Komponente, ki jih pri razvoju lahko ponovno uporabimo, so vsi programski izdelki, ki nastanejo v katerikoli fazi razvojnega življenjskega cikla (od specifikacij zahtev do kode). Preden lahko karkoli ponovno uporabimo, mora biti ponovno uporabno. To pomeni, da morajo biti komponente razvite z namenom, da jih bomo uporabili v različnih sistemih. 3.2 Značilnost objektnega procesnega modela Predlagamo, da objektni proces razvoja IS združuje naslednje pomembne strategije: Iterativni razvoj Za mnoge razvijalce programske opreme je uporaba itcrncij ena izmed ključnih značilnosti njihovega dela. Praktično to pomeni odlašanje izvedbe za določeno časovno obdobje z namenom hitrejšega napredovanja in kasnejšega vračanja k istemu problemu, kjer dosežene rezultate izboljšamo oziroma popravimo. S takšni m načinom dela se lažje prebijemo skozi kritične točke dela. Inkrementalni razvoj Inkrement pomeni dodatek k nečemu - napredovanje. Inkrement pomeni korak bliže k izpolnitvi zadanih ciljev. Inkrementalni razvoj je strategija napredovanja v malih korakih, da bi prišli do ustreznih rezultatov, Inkrementalni pristop zahteva razdelitev problema na podprobleme tako, da jiii lahko rešujemo sočasno in izmenično. Ob rešitvi vsakega podproblema le-tega testiramo in povežemo z ostalimi deli sistema. Izraza iterativni in inkrementalni se pogosto uporabljata v navezi ali izmenično in opisujeta uporabljen procesni model pri razvoju predvsem objektnih aplikacij. Strategiji sta med seboj ločeni in neodvisni. 3.3 Zgradba Proces razvoja programske opreme je razdeljen na posamezne faze. Pri objektnem razvoju IS ločimo Štiri osnovne faze (začutim faza, zbiranje zahtev, konstrukcija, pre&zem), Faze prikazujejo časovno delitev objektnega procesa. Iterativno inkrementalna narava objektnega pristopa narekuje predstavitev procesnega modela v dveh dimenzijah: ■ po Času - predstavlja življenjski cikel procesa, ■ po aktivnostih - predstavlja sestavne dele procesa. Tovrstna predstavitev v procesnem modelu poveže dva do sedaj ločena pogleda na razvoj informacijskih sistemov. Gledano iz časovne perspektive govorimo o fazah, katere delimo na razvojne cikle - iteracije in mejnike. Tak pogled je značilen za upravljalski nivo gledanja na projekt (projektno vodenje), 1 .e-ta zajema časovno komponento, sredstva, ljudi in organizacijo dela. Gledano iz perspektive proizvodov pa razvojni proces delimo na posamezne aktivnosti. Pri tem ločimo tehnične aktivnosti in podporne aktivnosti (upravljanje konfiguracij in sprememb, vodenje projektov, uporaba metrik, upravljanje okolja). Slika 4 prikazuje le tehnične aktivnosti. I/, opisa objektnega procesa razvoja IS so izvzete tudi aktivnosti, ki se ne spremenijo z objektnim pristopom, npr. načrtovanje grafičnega uporabniškega vmesnika, oblikovanje uporabniške dokumentacije, oblikovanje tehnične dokumentacije. i (fwmín/íil NFORM ATI KA 2000 ■ številka 4 - letnik VIII Aleš ŽivkoviČ, Marjan Heričko, Ivan Rozman: Razvoj programske opreme z uporabo jezika UM L Faze o C > < Zajemanj« zahtev Analiza Arhitekturna nairlovanjo Načrtovanje objektov Implementacija Testiranje Začetna faza -V"" Zbiranje Informacij m -OZH CD- Konstrukcija H-m m- 4>- > Pravx«m fl-Cp it it. 1 it. 2 It. n-1 It. n Slika 4: Iteriicije v objektnem procesu razvoja Dinamični vidik Življenjski cikel vsake generacije1 programske opreme delimo na štiri faze. Vsaka faza se zaključi z definiranim Časovnim mejnikom in zahteva sprejem odločitev, ki lahko v veliki meri vplivajo na uspešnost projekta. Vhode in izhode posamezne faze prikazuje slika 5. Zače trnja za - projekt definiramo s poslovnega stališča in določimo njegov obseg. V ta namen poiščemo vse zunanje akterje, s katerimi bo sistem sodeloval, ter v grobem definiramo način sodelovanja. Poiskati moramo vse primere uporabe, opišemo pa le najpomembnejše. Poslovno definiranje projekta zajema določitev kriterija uspeha oziroma neuspeha projekta, ocenitev tveganj, presojo potrebnih virov in fazni načrt, iz katerega so razvidni glavni časovni mejniki. Faza i bi m i ga informacij - analiziramo problemsko področje, postavimo osnovno ogrodje arhitekture sistema, izdelamo projektni plan in razrešimo najbolj rizične elemente projekta. Arhitekturne odločitve morajo upoštevati sistem kot celoto, ktir zahteva podroben opis večine primerov uporabe in upoštevanje nekaterih dodatnih omejitev. Prototipno realiziramo sistem do te mere, da lahko prikažemo glavne primere uporabe in ovrednotimo izbrano arhitekturo. I\ia koncu te faze pregledamo podrobne cilje sistema in nje- 1 Generacijo programske opreme definiramo kot novo verzijo, ki gm skozi vse faze razvoja. gov obseg, izbiro arhitekture in morebitna tveganja. Fnzn konstrukcije - iterativno inkremen-tainim postopkom izdelamo celoten proizvod, ki je pripravljen za prenos k uporabniku. Faza konstrukcije zajema opis preostalih primerov uporabe, načrtovanje, zaključek implementacije in testiranje. Na koncu te faze moramo presoditi, ali so izdelani programska oprema kot tudi uporabniki, pripravljeni za opravljanje vsakodnevnih nalog. Faza prevzemu - osnovni cilj te faze je predaja izdelka v uporabnikovo okolje. S tem se pogosto pojavlja potreba po dodatnih popravkih, ki prilagodijo sistem, popravljajo neodkrite probleme ali dokončujejo nekatere funkcije, ki so bile namenoma izpuščene. Tipično ta faza nastopi z beta verzijo proizvoda. Na koncu te faze ocenimo nivo zadovoljitve zadanih ciljev in ali je potrebno pričeti z novim razvojnim ciklom. Seveda je to prav tako primeren trenutek za izboljšanje obstoječega procesa, izhajajoč iz pridobljenih izkušenj. Statični vidik Objektni proces razvoja informacijskega sistema lahko opazujemo tudi s stališča aktivnosti, ki jih izvajamo. Delitev je podobna kot pri strukturnem pristopu z nekaterimi spremembami oziroma dopolnitvami. Osnovna razlika je delitev aktivnosti na dve veliki skupini. Prva skupina je skupina tehničnih aktivnosti. To so aktivnosti, v katerih se osredotočimo na opravila, ki so popolnoma tehnične narave (npr. identifikacija primerov uporabe, določanje razredov, dodeljevanje odgovornosti). Druga skupina aktivnosti pa so podporne aktivnosti, ki so namenjene vodenju tehniških aktivnosti in nadzoru projekta. Teh aktivnosti v dokumentu ne bomo opisovali, saj so skupne tako strukturnemu kot objektnemu razvoju. Gre za aktivnosti upravljanja konfiguracij iti upravljanja sprememb, aktivnosti projektnega vodenja in aktivnosti upravljanja okolja. Zaje dih 11 je znhtci' - poglavitni namen je pridobiti uporabnikove zahteve za nastajajoči sistem v obliki primerov uporabe, lastnosti in ne-funkcionalnih zahtev. Izhod te aktivnosti je model primerov uporabe, scenariji primerov uporabe in opis nefunkcionalnih zahtev. Analiza - definira, katere operacije in objekti bodo prisotni v razvijajočem se sistemu, ne oziraje se na to, kako bodo te operacije in objekti izdelani. Izhod i/, te aktivnosti zajema razredni diagram in vmesnik sistema, 2000 Številka 4 letnik VIII npoi »¿n iiil NFOR M AT! KA 205 Aleš ŽivkoviČ, Marjan Heričko, Ivan Rozman: Razvoj programske opreme z uporabo jezika UM L Izdelki slrateSkega planiranja M odej primerov u porabe [glavni PU] Model analize [za glavne PU) NefunkcionEilne za h leve Neformalni opis kandidatne arhitekture Pojmovnik [osnovni] Začetna Taza Model zahtev [večina PU| Model analize [večina PU| Arhitektura sislema [osnovna) Model načrtovanja [arhitekturno pomembni Pil) Model implementacije [artilliktuml prototipi] Model testiranja [arhitekturno pomembni PUJ Mnitnt zahtev Model analize Arhitektura sistema | vzdrževan a) Model načrtovanja [osnovna funkcionalnost] Model implementacije [bela verzija, osnovna funkcionalnost] Model testiranja [za beta verzijo) Zbiranje informacij Konstrukcija Prevzem Model primerov uporahrj [glavni PUJ Model analize [za glavne PU] Nefunkcionalne zahteve Neformalni opis kandidatne arnileklure Ocen i lev iveg arija Pojmovnik [osnovni) Projektni plan [zbiranje mformacijJ Model zahtev [veČina PU) Model analize [večina PU) Arhitekiur;i sistema [osnovna] Model načrtovanja [arhitekturno pomembni PU] Model implementacij o (arhitekturni prololipi] Model testiranja [arhitekturno pomembni PU! Oceni tov tveganja [dopolnjena] Uporabniški priročnik [osnova) Projektni ji Jan [konstrukcija) Pojmovnik [dopolnjen) -; Murfel zahtev Model analize Arhileklura sislema |vzdrževana) Model načrtovanja [osnovna funkcionalnost Model imi^lememacije [beta verzija, osnovna funkcionalnost) Model lesliranja [za bela verzijo] Uporahni&ki priročnik [za beta verzijo) Projektni plan [za prevzetni Pojmovnik [dopolnjeni Arhitektura sislema Model načrtovanja Model implementacije [delujoč sistem) Model lesliranja Uporabniška dokumentacija Tehnična dok umen ladja Slika 5: Vhodi in izhodi posameznih faz > ► ki se odraža v operacijah in dogodkih. K izredni diagram analize oblikujemo na podlagi razrednega diagrama problemskega področja. Arhitekturno nnatovnnie - določa strukturo sistema glede komponent in povezav med njimi. Primarni rezultat arhitekturnega načrtovanja je fizična arhitektura sistema, ki izhaja i/ logične arhitekture. Logična arhitektura je prvi približek zgradbe sistema, katero dopolnjujemo in spreminjamo z namenom izdelati optimalno arhitekturno zgradbo sistema. Niirrtuimiijr tihicktai' -operacije priredimo objektom in sprejmemo odločitve glede dedovanja, vidljivosti in predstavitve povezav (asociacij). Opišemo tudi pristope k sočasnemu izvajanju posameznih delov sistema in s tem v povezavi tudi sinhronizacijo. Izhodi so razredni diagram načrtovanja, diagram sodelovanja objektov, začetna konfiguracija objektov in posodobljen arhitekturni diagram. Implementacija - rezultate načrtovanja implementiramo v enem izmed programskih jezikov. Pri tem upoštevamo lastnosti izbranega programskega jezika, Potrebno je razviti tako tehnološke ki it tudi poslovne razrede. Pri razvoju je potrebno upoštevati izbrano arhitekturo sistema. Upoštevati je potrebno tudi nefunkcionalne zahteve. TeMimiije ■ izvedemo testiranje izdelka. V sklopu te aktivnosti je potrebno izvesti tako testiranje enot kot tudi integracijsko testiranje. Izdelek aktivnosti je poročilo o testiranju, nastane pa tudi množica testnih primerov in testnih vzorcev, s katerimi zagotovimo ponovljivost testiranja. V primeru, ko želimo testiranje avtomatizirati, razvijemo testne razrede. i^MHWJINFORMATIKA 2000 Številka 4 ■ letnik VIII Aleš ŽivkoviČ, Marjan Heričko, Ivan Rozman: Razvoj programske opreme z uporabo jezika UM L 4. Zaključek Jezik UMI., prispeva k lažji komunikaciji med razvijalci programske opreme. Uporaba diagramskih tehnik, ki jih jezik UMI. vsebuje, poenostavlja razumevanje v s p bolj zapletenih konceptov gradnje programske opreme, omogoča dokumentiranje dela in izdelkov, gradnjo knjižnic komponent in nenazadnje tudi knjižnic idejnih rešitev skozi vzorce načrtovanja. Poenotenje izgleda notacijskih konstruktov in natančna določila za njihovo povezovanje so le začetni koraki k boljši programski opremi. Pomembno je, da določimo opravila, ki jim sledimo pri razvoju programske opreme. Opravila povežemo v skupek pravil, strategij, aktivnosti, metod in korakov, katerih namen je doseči poslovne cilje, in jih imenujemo procesni model. Univerza 1 nega procesnega modela ni, odvisen je od velikosti in tipa organizacije. V prispevku smo opisali ogrodje objektnega procesnega modela, ki lahko slu/i kot osnova za oblikovanje procesnega modela organizacije. 5. Literatura 1. Oerr Kun W.. Applying OMT: A practical step-by-step guide to using the object modeling technique, SIGS Books, 1995 2. Fowler M. Kendall S, UML Distilled ■ Applying the standard object modeling language. Add ¡son-Wesley, 1997 3. Grady Booch, James Rumbaugh, Unified Method, Rational Software Corporation, 1995 4. Institut za informatiko, Enotna metodologija razvoja informacijskih s/siemov - 4. Zvezek: Objektni razvoj IS tehnično poročilo, PERI Maribor Institut za informatiko, november 1999 5. OMG Unified Modeling Language Specification, version 1.3, June 1999, http://www.omg.org/ 6. Rozman et al., PROCESSUS - Integration of SEI CMM and ISO quality models, Software Quality Journal, Marec 1997, str. 37-63 7. Živkovič Aleš, Rozman Ivan, Značilnosti uspešni/) projektov. OTS'99 zbornik prispevkov, str, 162 - 168 ♦ Dr. Ivan Rozman je redni profesor Univerze v Mariboru, dekan Fakultete za elektrotehniko, računalništvo in informatiko v Mariboru in ustanovitelj Laboratorija za informacijske sisteme, ki ga vodi še danes. Je avtor številnih publikacij in vodja več raziskovalnih projektov Diplomiral je no Fakulteti za elektrotehniko v Ljubljani, magistriral in doktoriral pa na Tehniški fakulteti v Mariboru, e-pošta: i.rozman@uni-mb.si ♦ Dr. Marjan H e rit ko je docent na Inštitutu za informatiko na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru. Njegovo raziskovalno-razvojno delo obsega vse vidike objektne tehnologije, s poudarkom na metodologijah razvoja, orodjih ČASE, razvojnih okoljih in metrikah. Svoja spoznanja in izkušnje je predstavil v številnih prispevkih na domačih in tujih konferencah ter revijah. Aktivno sodeluje pri koordiniranju aktivnosti CenfM za objektno tehnologijo ter vodi organizacijo strokovnih srečanj OTS Objektna tehnologija v Sloveniji. Diplomiral, magistriral in doktoriral¡e na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru. http://lisa.uni-mb.si/osebje/hericko; e-pošta: marjan.hericko@uni-mb.si ♦ Mag. Aleš Živkovič je asistent na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru in aktiven član Centra za objektno tehnologijo, v okviru katerega je sodeloval pri pripravi in izvedbi številnih seminarjev in delavnic iz področja Jave, objektnega načrtovanja, porazdeljenih objektnih sistemov in Interneta. Je avtor številnih domačih in tujih člankov. Njegovo raziskovalno delo zajema javansko tehnologijo, področja objektne tehnologije, projektnega vodenja in interneta. Je ustanovitelj in koordinator skupine JUGSI (Java User Group of Slovenia). Diplomiral in magistriral je na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru, e-pošta: ales.zivkovic@uni-mb.si 2000 ■ številka 4 ■ letnik Vili uporabno! NFORM ATI KA