IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE PROJEKTE Z UPORABO UML 2.0

Transcription

1 Peter Pogladič IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE PROJEKTE Z UPORABO UML 2.0 Diplomsko delo Maribor, avgust 2011

2

3 I Diplomsko delo univerzitetnega študijskega programa IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE PROJEKTE Z UPORABO UML 2.0 Študent: Študijski program: Smer: Mentor: Somentor: Peter Pogladič UN Informatika in tehnologije komuniciranja Informacijski sistemi doc. dr. Aleš Ţivkovič asist. Kristjan Košič Maribor, avgust 2011

4 II

5 III ZAHVALA Maji za vzpodbudo in čas, ki ga nisem mogel posvetiti njej. Zahvaljujem se mentorju Ţivkovič Alešu in somentorju Košič Kristjanu za pomoč in vodenje pri opravljanju diplomskega dela. Posebna zahvala velja staršem za odlično vzgojo, potrpeţljivost in za vse priloţnosti, ki so mi jih omogočili, tudi študij.

6 IV IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE PROJEKTE Z UPORABO UML 2.0 Ključne besede: tehnična dokumentacija programske opreme, odprta koda, informacijski sistemi, UML, poslovni procesi, povratno inţenirstvo, RUP, MSF. UDK: (043.2) Povzetek Odprtokodna programska oprema je za podjetja in splošne uporabnike zelo mamljiva, vendar malo uporabljena. Problem se med drugim nahaja v pomanjkljivi dokumentaciji in posledično zamujenimi možnostmi uporabe in prilagajanja odprtokodne programske opreme potrebam organizacije. V diplomski nalogi je predstavljen prilagojen proces izdelave tehnične dokumentacije odprtokodne programske opreme na osnovi procesnih modelov RUP in Microsoft MSF4ASD. Namen diplomske naloge je izdelava splošnega procesa za izdelavo tehnične dokumentacije, ki omogoča nadaljnji razvoj oziroma prilagoditev odprtokodne programske opreme potrebam organizacije.

7 V DEVELOPMENT OF TECHNICAL DOCUMENTATION FOR OPEN SOURCE PROJECTS USING UML 2.0 Key words: technical software documentation, open source, information systems, UML, business processes, reverse engineering, RUP, MSF. UDK: (043.2) Abstract Open source software is very tempting for businesses and general users, however it is not frequently used. The problem is in poor software documentation, which consequently leads to missed opportunities to use or adapt open source software for the needs of organization. The diploma thesis presents an adapted process of technical documentation for open source software based on process models IBM RUP and Microsoft MSF4ASD. The main purpose of the diploma thesis is to produce an overall documentation process, which enables further development and customization of software for the needs of the organization.

8 VI VSEBINA 1 UVOD ODPRTA KODA PRIMERJAVA ODPRTOKODNIH LICENC ODPRTOKODNI PROJEKTI ORANGE HRM Statistika Orange Human Resource Management METODOLOGIJE RAZVOJA PROGRAMSKE OPREME PRIMERJAVA MICROSOFT SOLUTIONS FRAMEWORK FOR AGILE SOFTWARE DEVELOPMENT IN IBM RATIONAL UNIFIED PROCESS IBM ZAČETNA FAZA/MSF FAZA PREDVIDEVANJA IBM ZBIRANJE INFORMACIJ/MSF FAZA NAČRTOVANJA IBM FAZA KONSTRUKCIJE/MSF FAZA RAZVOJA IN STABILIZACIJE IBM FAZA PREVZEMA/MSF FAZA NAMESTITVE IN SPREMLJANJA TEHNIČNA DOKUMENTACIJA ODPRTOKODNEGA PROJEKTA S POMOČJO UML PREGLED OBSTOJEČE DOKUMENTACIJE DOKUMENTACIJA PROGRAMSKE OPREME Z UPORABO DIAGRAMSKIH TEHNIK Analiza funkcionalnosti sistema Izdelava diagrama aktivnosti Generiranje razrednega diagrama Generiranje paketnega diagrama Podatkovni model Diagram zaporedja Diagram namestitve Zemljevid strani ZAKLJUČNA FAZA Dopolnitev dokumentacije Ugotovitve SKLEP... 26

9 VII 7 VIRI PRILOGE KAZALO SLIK KAZALO GRAFOV SEZNAM PREGLEDNIC... 30

10 VIII UPORABLJENE KRATICE RUP Rational Unified Process MSF4ASD Microsoft Solutions Framework for Agile Software Development GPL General Public License GNU GPL GNU's Not Unix General Public License OSI Open Source Initiative Orange HRM Orange Human Resource Management MsSQL Microsoft Structured Query Language http Hypertext Transfer Protocol CMMI Capability Maturity Model Integration XP Extreme Programming BPMN Business Process Modeling Notation

11 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 1 1 UVOD Odprtokodna programska oprema je na razpolago brezplačno z moţnostmi prilagajanja lete, saj je na voljo njena izvorna programska koda (odvisno od licence). Pri prilagajanju programske opreme potrebam organizacije, se pojavi problem poznavanja izvorne programske kode in funkcionalnosti sistema, ki jo posameznik ali organizacija ţeli prilagoditi. Diplomsko delo je nastalo na osnovi problematike dokumentiranja odprtokodne programske opreme, ki v splošnem ni ali pa je zelo slabo dokumentirana. Odprtokodni razvoj programske opreme je zelo razširjen, dobro podprt s strani skupnosti in predvsem perspektiven. Veliko organizacij in splošnih uporabnikov se odloča za razvoj ali uporabo odprtokodne programske opreme, pri čemer pa zaradi svobode razvoja programske opreme ni poudarka na njeni dokumentaciji. Dokumentacija je pomembna predvsem zaradi prilagajanja in nadgradenj odprtokodne programske opreme, ki jo le-ta omogoča. Diplomsko delo je nastalo v okviru zgoraj omenjene problematike dokumentiranja programske opreme in temelji na ogrodjih, ki omogočajo agilen razvoj programske opreme IBM RUP (ang. IBM Rational Unified Process) in Microsoft MSF4ASD (ang. Microsoft Solutions Framework for Agile Software Development). Ogrodji podajata dobre prakse pri razvoju programske opreme, ki omogočajo hiter in učinkovit razvoj. Na osnovi ogrodij so nastali določeni dokumenti, ki so sestavni del nastalega procesa tehnične dokumentacije odprtokodne programske opreme v posamezni fazi. Dokumenti, ki opisujejo dokumentacijo odprtokodne programske opreme so nastali na osnovi primerjave med omenjenima ogrodjema. Praktični del diplomske naloge je potekal s pomočjo izbranih orodij, ki omogočajo povratno inţenirstvo. Za izdelavo UML diagramov se je uporabljal Visual Paradigm for UML 8.0 Standard Edition, medtem ko se je za izdelavo podatkovnega modela uporabljal MySQL Workbench 5.2 CE. Večino diagramov, ki sestavljajo dokumentacijo je bilo

12 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 2 mogoče pridobiti s pomočjo povratnega inţenirstva, nekatere pa je bilo potrebno izdelati samostojno. Pri izdelavi procesa dokumentacije programske opreme je bil uporabljen IBM WebSphere Business Modeler Advanced 6.2. Proces opredeljuje faze dokumentacije programske opreme in dokumente, ki so vhodi oziroma izhodi iz posamezne faze procesa. Proces je predstavljen tudi s pomočjo spletnega vmesnika, ki opredeljuje vse vhodno izhodne dokumente, dodatno pa je podkrepljen tudi s predlogami, ki opisujejo dokumente kot rezultate posamezne faze. Spletni vmesnik je izdelan s pomočjo IBM Method Composer. V nadaljevanju bomo spoznali osnove odprte kode in pregledali odprtokodne licence, ki jih bomo navezali z moţnostmi prilaganja odprtokodne programske opreme.

13 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 3 2 ODPRTA KODA Odprtokodna programska oprema je programska oprema, katere izvorna koda je na voljo širši javnosti za brezplačno, prosto uporabo in/ali modifikacijo originalne različice izvorne kode. Kljub temu, da lahko z odprtokodno programsko opremo njeni uporabniki počno karkoli, zanjo veljajo posebna pravila, ki so opisana v licencah za odprtokodno programsko opremo. Vsem licencam je skupnih nekaj pravil, kot so [8]: 1. Odprtokodno programsko opremo je mogoče svobodno redistribuirati. Lahko jo redistribuira kdorkoli, brezplačno ali proti plačilu. 2. Izvorna programska koda je dostopna uporabniku. Licenca mora dovoljevati distribucijo v predvideni in izvorni obliki. 3. Licenca mora dovoljevati spremembe osnovne kode in izvedene oblike nove kode. 4. Kljub temu, da mora biti izvorna koda dostopna, lahko izvorni avtorji zahtevajo, da se morebitne spremembe jasno ločijo od originalne kode in tako ohranijo ločnico med prvotno in modificirano kodo (npr. v obliki popravkov ali različnih verzij). 5. Licenca ne sme omejevati katerekoli osebe ali skupine. 6. Licenca ne sme biti omejevalna glede na področje dela, v okviru katerega se programska koda uporablja. 7. Distribucija licenc mora biti enakovredna za vse uporabnike, brez dodatnih omejitev. 8. Licenca za isto programsko kodo se ne sme razlikovati, če se jo uporablja v kombinaciji z drugo programsko opremo. 9. Licenca ne sme omejevati uporabe druge programske opreme. 10. Licenca mora biti tehnološko nevtralna.

14 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 4 Vsa odprtokodna programska oprema ni distribuirana pod enako licenco. Nekatera programska oprema uporablja prosto programsko licenco (ang. Free software license), copyleft licenco ali GPL (ang. General Public License) licenco. GPL licenca je prosta, copyleft licenca, medtem ko»gnu Lesser General Public License«zajema prosto programsko licenco brez»copyleft«licence. Danes obstaja pribliţno petdeset licenc, ki so izdane pod okriljem OSI (ang. Open Source Initiative). 2.1 Primerjava odprtokodnih licenc Spodnja slika (Slika 2.1) tabelarično prikazuje primerjavo med različnimi odprtokodnimi licencami. Vsaka licenca ima določene specifike, po katerih se razlikuje od drugih licenc. Glede na primerjalne kriterije je najbolj odprta oziroma najmanj omejena licenca MIT (ang. Massachusetts Institute of Technology license). Slika 2.1: Primerjava odprtokodnih licenc [4]

15 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran Odprtokodni projekti Odprtokodno programsko opremo lahko definiramo kot programsko opremo, za katero je izvorna koda izdana pod zaščitno licenco, ki zadostuje osnovnim pravilom odprte kode. Licenca dovoljuje uporabo in spreminjanje programske opreme ter njeno razširjanje v spremenjeni ali nespremenjeni obliki. Ena izmed najbolj razširjenih skupnosti, kjer spodbujajo razvoj programske opreme, je SourceForge ( Na spletnem mestu je zbranih okoli odprtokodnih projektov. Med najbolj znanimi projekti so: emule, Azureus / Vuze, VLC media player, Ares Galaxy, 7 Zip, FileZila, Orange HRM ( Orange HRM (ang. Orange Human Resource Management) smo uporabili kot osnovo pri izdelavi procesa tehnične dokumentacije odprtokodne programske opreme in je tudi dokumentiran v skladu z izdelanim procesom. 2.3 Orange HRM Orange HRM je eden izmed vodilnih odprtokodnih informacijskih sistemov, ki ponuja rešitve za manjša in srednje velika podjetja na področju vodenja človeških virov. Podjetju oziroma organizaciji omogoča vodenje ključnega faktorja vsake organizacije ljudi, z moduli za upravljanje zaposlenih, z vodenjem prisotnosti, z upravljanjem zaposlovanja v organizaciji in z drugimi. Orange HRM je odprtokodni informacijski sistem, ki so ga začeli razvijati konec leta Prva delujoča različica je bila razvita ţe januarja leta Danes ima Orange HRM

16 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 6 številne uporabnike po celem svetu, katerim zagotavlja stabilno, tehnološko dovršeno in brezplačno aplikacijo za vodenje človeških virov. Zahvaljujoč licenci pod katero je izdan (GPL), se nenehno dograjuje in izpopolnjuje. Projekt je bil nagrajen z nagrado SourceForge: Projekt meseca decembra Razvit je v programskem jeziku PHP, uporablja podatkovni streţnik Microsoft SQL in http (ang. Hypertext Transfer Protocol) streţnik Apache. Izdan je pod GPL in je v skladu z licenco brezplačen. Trenutno je na voljo v stabilni verziji Statistika Orange Human Resource Management V poglavju je zbranih nekaj zanimivih grafov, ki prikazujejo statistiko projekta s spletne strani SourceForge. Na spodnjem grafu (Graf 2.1) je prikazana statistika prenosov datotek na projektu Orange HRM od začetka projekta do danes. Iz grafa je razvidno število prenosov projekta in potreba po večanju pasovne širine, rezervirane za projekt na spletni strani SourceForge.net. Graf 2.1: Statistika prenosov Orange HRM [6]

17 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 7 Spodnji graf (Graf 2.2) prikazuje spletni promet projekta na domači strani projekta. Iz grafa je razviden razvoj projekta in njegova popularnost med uporabniki. Projekt je doţivel svoj razcvet ob koncu leta 2008 in ga uţiva še danes. Graf 2.2: Spletni promet projekta na domači strani [7] Odprtokodni sistem za upravljanje s človeškimi viri ima zavidljiv milijon uporabnikov po vsem svetu in več kot prenosov projekta z uradne strani Skupnost, ki razvija projekt, se lahko pohvali tudi s sistemsko podporo uporabnikom oziroma naročnikom, ki je plačljiva.

18 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 8 3 METODOLOGIJE RAZVOJA PROGRAMSKE OPREME Razvoj programske opreme med drugim ločimo tudi po metodologijah razvoja programske opreme. Najbolj poznane med njimi so: agilne metode razvoja (MSF, SCRUM, XP), iterativne metode (RUP, Iterativni razvoj, Spiralna metoda), metode, ki temeljijo na modelu slap (Slap, CMMI), ad-hoc metode (proste metode, ki ne poznajo vodenega oziroma procesnega razvoja programske opreme). Agilne metode razvoja programske opreme temeljijo na iterativnem in inkrementalnem razvoju programske opreme. Metode podajajo skupke dobrih praks in priporočil za razvoj ţelenega projekta, ter pripomorejo k učinkovitem izvajanju nalog in vodenju projekta. Agilne metode temeljijo na procesnem vodenju razvoja programske opreme, ki: podajajo napotke glede zaporedja in sosledja aktivnosti razvojne skupine, določajo kateri izdelki bodo razviti, ter kdaj bodo razviti, usmerjajo naloge posameznikov in razvojne skupine kot celote, nudijo kriterije za spremljanje in vrednotenje projektnih izdelkov in aktivnosti. Spodnji graf (Slika 3.1) prikazuje uporabo metodologij razvoja programske opreme v organizacijah. Razvidno je, da agilne metode prednjačijo pred ostalimi metodologijami razvoja programske opreme. Zaskrbljujoče je predvsem dejstvo, da pribliţno 30 odstotkov organizacij ne uporablja nobene od procesno vodenih metodologij, temveč temeljijo na tako imenovanih ad-hoc metodah.

19 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 9 Slika 3.1: Uporaba metodologij razvoja v organizacijah [10]

20 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 10 4 PRIMERJAVA MICROSOFT SOLUTIONS FRAMEWORK FOR AGILE SOFTWARE DEVELOPMENT IN IBM RATIONAL UNIFIED PROCESS Pri izdelavi procesa tehnične dokumentacije odprtokodne programske opreme smo kot osnovo uporabili agilni metodologiji razvoja programske opreme IBM RUP in MSF4ASD. Metodologiji razvoja programske opreme povzemata skupke dobrih praks in načel pri razvoju programske opreme, ki natančno opredeljujejo vloge in opravila v posamezni fazi razvoja. IBM RUP (Slika 4.1) je razdeljen v štiri faze razvoja in podaja šest dobrih praks pri razvoju programske opreme (iterativni razvoj, upravljanje zahtev, uporaba komponentnih arhitektur, vizualno modeliranje, preverjanje kakovosti in nadzor nad spremembami [5]). Slika 4.1: Proces razvoja programske opreme po IBM RUP [5, 11, 12]

21 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 11 MSF4ASD (Slika 4.2) pri razvoju programske opreme kombira spiralni model in model slap. Cikel razvoja se zaključi z jasno definiranim mejnikom, če mejnik ni doseţen, se cikel ponovi (Slika 4.3). MSF4ASD pri razvoju programske opreme ne pozna hierarhične ureditve vlog na projektu, kar vse člane razvojne skupine postavi v enakovreden poloţaj. Slika 4.2: MSF Procesni model [1] Slika 4.3: Disciplina upravljanje [3]

22 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 12 Pri primerjavi ogrodij (Slika 4.4) najdemo podobnosti pri razvoju programske, ki so podrobneje opisane v naslednjih podpoglavjih. Slika 4.4: Primerjava po fazah [11] 4.1 IBM začetna faza/msf faza predvidevanja Na začetku vsakega projekta se sestane projektna skupina in naročnik, kjer naročnik seznani projektno skupino s problemom. Naročnik natančno doreče katere stvari ga na projektu zanimajo. Te informacije morajo biti dokumentirane, da projektna skupina in naročnik ustvarijo skupno in popolno vizijo problema [11]. Tako po RUP kot po MSF se ustvari vizija, da se zagotovi enaka ideja poslovnega problema z obeh strani (naročnik izvajalec). Prav tako se po RUP in MSF določijo meje projekta in njegov obseg. Pri določanju obsega projekta je RUP bolj temeljit, zaradi česar laţje določa fiksne meje projekta, medtem ko MSF daje obsegu projekta in njegovim mejam več svobode, kar ugaja strankinim ţeljam [11]. Ko naročnik spozna poslovni primer projekta je naloga projektne skupine predvideti in identificirati ključne elemente za ustrezno rešitev poslovnega problema. Naročnik, končni uporabniki in ostale zainteresirane skupine obvestijo projektno skupino o njihovih ţeljah, potrebah in pričakovanjih glede sistema [11].

23 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 13 Skladno z ogrodjem RUP je pridobitev čim več informacij, ki pripomorejo k splošnemu planiranju in razumevanju problema s katerim se sooča. V začetni fazi se formulirajo vse zahteve, okvirni stroški, potencialna tveganja in arhitektura sistema. MSF je agilne miselnosti, kar pomeni, da MSF skupina misli, da ni potrebno imeti vseh informacij v naprej. Agilna skupnost meni, da sprememba ni samo verjetna, ampak da je neizogibna. MSF skupina uporablja»just-in-time«pristop, kjer se določena stvar naredi, ko se potrebuje [11]. Obe metodi uporabljata ta razvojni cikel programske opreme za preučitev strankinega poslovanja, problemov in potreb za razvoj skupnega pogleda na projekt. RUP je v tej fazi bolj strikten in formalen glede obsega projekta kot MSF, ki je bolj fleksibilen in odprt do sprememb [11]. Tabela 4.1: Dokumenti začetne faze (RUP) in faze predvidevanja (MSF) [2, 11] RUP - Začetna faza MSF - Faza predvidevanja Vizija Vizija in obseg Poslovni primer Poslovne zahteve Načrt razvoja programske opreme - Struktura projekta - Poročilo o napredku razvojne skupine na projektu - Predlogi funkcionalnosti - Poročilo o napredku posameznega člana razvojne skupine - Finančni načrt Iteracijski načrt Poročilo o doseganju mejnika faze razvoja Razvojna infrastruktura Poročilo trenutne infrastrukture Slovar (ang. Glossary) Model primerov uporabe Seznam začetnih tveganj na projektu

24 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran IBM zbiranje informacij/msf faza načrtovanja V obdobju planiranja se pripravi ideja prihodnosti projekta, ocenijo se stroški in čas projekta ter se določijo sredstva. Oba procesa uporabljata vizijo kot osnovo za ustvarjanje sistemske arhitekture, identifikacijo nefunkcionalnih in funkcionalnih zahtev ter omejitev [11]. RUP ţeli pridobiti čim več informacij, kolikor je mogoče, da bi lahko projekt ocenili in načrtovali kot celoto ali po iteracijah. V fazi zbiranja informacij projektna skupina zasnuje arhitekturo in vizijo ter napravi podroben plan tveganj za celotno fazo konstrukcije ter za upravljanje in nadzor preostalih procesov. Na koncu faze zbiranja informacij so identificirane vse funkcionalne in nefunkcionalne zahteve [11]. MSF se v ciklu načrtovanja bolj osredotoča na načrtovanje iteracij kot na načrtovanje celotnega projekta, ker je načrtovanje projekta kot celote po MSF nesmiselno, saj je predvideno, da se bodo pojavile spremembe na projektu. Kjer se RUP osredotoča na načrtovanje tveganj na projektu, se MSF osredotoča na kvalitetno planiranje naslednje iteracije [11]. Tabela 4.2: Dokumenti faze zbiranja informacij (RUP) in načrtovanja (MSF) [2, 11] RUP - Zbiranje informacij MSF - Načrtovanje Načrtovalni model Logično načrtovanje Model implementacije Fizični model Načrt razvoja programske opreme Načrt razvoja programske opreme Model primerov uporabe (80%) - Uporabniške zahteve - Scenarij uporabe Dodatne specifikacije - Funkcionalne specifikacije - Sistemske zahteve - Zahteve obratovanja Smoke test Testni plan Prototip Dopolnjen seznam tveganj na projektu Proces razvoja Dokument arhitekture programske opreme

25 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran IBM faza konstrukcije/msf faza razvoja in stabilizacije Obdobje izgradnje programske opreme ima pri obeh procesih enak namen, zgraditi programsko opremo v skladu s pričakovanji in potrebami, ki so bile določene v prvem obdobju razvoja programske opreme. V tej fazi se kaţe iterativni in inkrementalni razvoj programske opreme, ki ga oba procesa spodbujata. Razvoj produkta je izdelan korak za korakom, zagotovljena pa je visoka kvaliteta produkta. Po RUP je bilo narejeno planiranje celotnega projekta in iteracij v prejšnjih fazah, zato se v tej fazi osredotoča zgolj na implementacijo produkta po iteracijah. Razvijalci programske opreme prejmejo potrebne primere uporabe (ang. Use case), funkcionalne opise in arhitekturo za implementacijo funkcionalnih zahtev sistema. Vsaka iteracija se konča z verzijo sistema, ki se predstavi naročniku, od katerega pridobimo povratno informacijo o sistemu. Projektna skupina organizira iteracijo, v kateri zagotovi sebi in naročniku informacije o napredku in statusu sistema, podatke dokumentira in preveri ali je projekt konsistenten s predhodnimi dogovori [11]. Po MSF poteka izgradnja programske opreme na tako imenovan»ad-hoc«način. Za razliko od RUP, MSF ne načrtuje celotnega projekta ampak samo naslednjo iteracijo. Delovni dan po MSF se začne s kratkim sestankom razvijalcev o statusu projekta, napredku in o delu, ki še mora biti opravljeno. Iteracija se zaključi z pregledom zastavljenih ciljev in napredka projekta.

26 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 16 Tabela 4.3: Dokumenti faze konstrukcije (RUP) in Konstrukcije (MSF) [2, 11] RUP - Konstrukcija MSF Konstrukcija (Razvoj in stabilizacija) Načrt namestitve Model implementacije Iteracijski načrt Proces razvoja Infrastruktura razvoja Podatkovni model Dodatne specifikacije Model primerov uporabe (dokončan) Poročilo testiranja in razhroščevanja Revizija sledljivosti Testne specifikacije 4.4 IBM faza prevzema/msf faza namestitve in spremljanja Ko je produkt dovolj razvit in ima pričakovan nivo kakovosti, je pripravljen na predajo stranki. Pred predajo sistema stranki je potrebno storiti naslednje: beta testiranje, da validiramo nov sistem glede na strankina pričakovanja, paralelno izvajanje sistema s prejšnjim, preureditev testne podatkovne baze, izobraževanje uporabnikov, dodatna dokumentacija (navodila za uporabo, namestitev) in podobno [11]. Po predaji projekta uporabniku se projektni cikel RUP zaključi, medtem ko ima MSF dodatno periodo cikel spremljanja produkta, katerega namen je pregled celotnega projekta, identifikacija novih tveganj, hroščev in podobno. Tabela 4.4: Dokumenti faz prevzema (RUP), Namestitve in spremljanja (MSF) [ 2, 11] RUP - Prevzema MSF - Namestitve, Spremljanja Delujoča aplikacija Pomoč uporabnikom Analiza»preteklega«projekta Dokončanje projekta

27 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 17 Pri izdelavi procesa tehnične dokumentacije odprtokodne programske opreme z uporabo UML 2.0 sta kot osnova sluţila prav Microsoft Solutions Framework in IBM Rational unified process. Na osnovi omenjenih ogrodij so definirani izhodni produkti posameznega opravila (ang. task), ki jih določa proces. Proces je podobno kot primerljivi ogrodji procesno voden in podrobno opredeljuje posamezne korake procesa. Definirane ima vloge, dokumente in opravila, ki pripomorejo k učinkoviti dokumentaciji izbrane programske opreme. Rezultat procesa je tehnična dokumentacija, ki omogoča učinkovit, hiter in kontroliran razvoj oziroma prilagoditev programske opreme potrebam organizacije. V primeru modifikacij programske opreme se lahko pri ponovni dokumentaciji preurejene programske opreme upremo na proces, ki je podrobneje predstavljen v nadaljevanju.

28 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 18 5 TEHNIČNA DOKUMENTACIJA ODPRTOKODNEGA PROJEKTA S POMOČJO UML 2.0 Proces dokumentacije odprtokodne programske opreme je razdeljen v tri zaporedne faze, ki so podrobneje opisane s pomočjo opravil, ki posamezno fazo sestavljajo. Rezultati posameznega procesa znotraj faze so dokumenti, ki zaključujejo celoten proces tehnične dokumentacije programske opreme. Proces je izdelan na osnovi praktične izdelave tehnične dokumentacije odprtokodnega projekta Orange HRM. Proces smo razvili s pomočjo orodja IBM WebSphere Business Modeler Advanced 6.2, kjer je celoten BPMN proces (ang. Business Process Modeling Notation) predstavljen grafično (Slika 5.1). Poslovni proces, izdelan s pomočjo omenjenega orodja definira procese, ter njihove vhodno izhodne dokumente. Razdeljen je na tri segmente: pregled obstoječe dokumentacije, dokumentacija programske opreme z uporabo diagramskih tehnik, zaključna faza. Spletni vmesnik vključuje poslovni proces in je nastal s pomočjo orodja IBM Method Composer, ki je namenjen spletni predstavitvi procesa. Spletni vmesnik je namenjen laţjemu sledenju, opisu opravil in dokumentov pri izdelavi tehnične dokumentacije programske opreme. Spremljanje razvoja dokumentacije je organizirano v tri skupine: vloge, dokumente, segmente.

29 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 19 Slika 5.1: Proces dokumentacije

30 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 20 Pri izdelavi praktičnega dela se je s pomočjo orodja Visual Paradigm for UML 8.0 Standard Edition generiral razredni, paketni diagram, medtem ko je bilo potrebno diagram primerov uporabe, diagram aktivnosti, diagram namestitve, zemljevid strani izdelati ročno. Izdelava entitetno relacijskega diagrama je potekala s pomočjo MySQL Workbench 5.2 CE. Spletni vmesnik procesa dokumentacije (Slika 5.2) je namenjen vodenju dokumentacije, ki jo je potrebno izdelati za določen produkt. Slika 5.2: Spletni vmesnik procesa tehnične dokumentacije odprtokodne programske opreme Proces dokumentacije opisuje vloge, aktivnosti, opravila in dokumente, ki jih je potrebno izpeljati v posamezni fazi procesa. Rezultat posamezne faze je eden ali več dokumentov, ki opisujejo dokumentiran produkt. Vsako opravilo v fazi je vodeno s koraki, ki jih je potrebno izpeljati, določa vloge, ki so odgovorne za izpeljavo opravila ter opredeljuje dokumente, ki sluţijo kot vhodni oziroma izhodni produkti. Iz procesa je natančno razvidno katera vloga je odgovorna za posamezni dokument ter v kateri fazi dokumentacije se dokument uporablja. Proces opredeljuje štiri vloge, ki jih v praksi lahko dodelimo več ljudem. Vsaka vloga ima vnaprej predviden profil osebe, ki naj bi ji ustrezal. Posamezni vlogi so dodeljena različna

31 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 21 opravila in odgovornosti, ki jih mora posameznik upoštevati za dosego ţelenega cilja, dokumentacije produkta. Vloge procesa: projektni vodja, analitik, administrator podatkovne baze, vodja razvojne skupine. Proces dokumentacije programske opreme izdelan s pomočjo IBM RMC je priloţen k diplomski nalogi na zgoščenki na kateri najdemo s praktičnimi primeri opisan proces dokumentacije odprtokodnega projekta Orange HRM po korakih, ki jih proces predvideva. V nadaljevanju so opisani koraki procesa izdelave tehnične dokumentacije. 5.1 Pregled obstoječe dokumentacije V tem koraku se zbere vsa dostopna dokumentacija projekta, ki ga ţelimo dokumentirati za nadaljnji razvoj oziroma prilagoditi potrebam organizacije. Vsi nadaljnji koraki procesa izdelave dokumentacije so odvisni prav od tega koraka. Če zbrana dokumentacija ustreza našim potrebam za nadaljnji razvoj oziroma prilagoditev projekta se proces dokumentacije zaključi ţe v prvem segmentu procesa, v nasprotnem primeru sledimo nadaljnjim korakom dokumentacije projekta, da dobimo ţeljen rezultat dokumentacije. Tabela 5.1: Vhodni in izhodni dokumenti Vhodi Izhod - Obstoječa dokumentacija Dokument obstoječe dokumentacije - Izvorna koda

32 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran Dokumentacija programske opreme z uporabo diagramskih tehnik Faza dokumentacije programske opreme z uporabo diagramskih tehnik je najpomembnejša in najobširnejša faza procesa dokumentacije, v kateri definiramo vse potrebne dokumente, ki jih faza določa za uspešen zaključek le-te. Pri dokumentaciji produkta si pomagamo z najrazličnejšimi orodji za povratno inţenirstvo, katera skrbno izberemo v skladu s produktom, ki ga dokumentiramo, saj nam ob pravilni izbiri orodja olajšajo delo, v nasprotnem primeru pa oteţijo. Faza je razdeljena v osem opravil, med katerimi se opravila»generiranje razrednega diagrama«,»generiranje paketnega diagrama«in»generiranje ER modela«izvajajo paralelno, medtem ko se ostali procesi izvajajo zaporedno Analiza funkcionalnosti sistema Diagramov primerov uporabe ne moremo pridobiti s pomočjo povratnega inţenirstva, zato jih moramo izdelati ročno. Diagram primerov uporabe pomaga dokumentirati funkcionalnosti sistema, ter omogoči enostavnejši pogled na funkcionalnosti projekta, ki ga dokumentiramo. Tabela 5.2: Vhodni in izhodni dokumenti Vhodi Izhodi - Dokument obstoječe dokumentacije - Pregled delovanja sistema (demo - Dokument funkcionalnosti sistema, ki zajema različica sistema, aktualna različica diagram primerov uporabe ter opis sistema). pomembnejših primerov uporabe iz diagrama primerov uporabe Izdelava diagrama aktivnosti Diagrame aktivnosti tako kot diagrame primerov uporabe, rišemo ročno, saj jih s pomočjo povratnega inţenirstva ne moremo generirati. Diagrame aktivnosti rišemo na osnovi posameznih primerov uporabe iz DPU. Diagram aktivnosti predstavlja interakcijo med

33 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 23 sistemom in uporabniki sistema. Diagrame aktivnosti uporabimo namesto vezanega besedila, ki smo ga uporabili za opis primerov uporabe v prejšnji točki. Tabela 5.3: Vhodni in izhodni dokumenti Vhodi Izhod - Diagram primerov uporabe Diagram aktivnosti - Opis primerov uporabe Generiranje razrednega diagrama S pomočjo orodja generiramo razredni diagram iz izvorne kode projekta, ki ga dokumentiramo. Na trţišču je na voljo več orodij za generiranje razrednih diagramov, izberemo pa tistega, ki omogoča generiranje razrednega diagrama iz izvorne kode projekta, ki ga dokumentiramo. Kvaliteta generiranega razrednega diagrama je odvisna od znanja razvijalcev, ki so aplikacijo razvili in od programskega jezika v kateri je aplikacija implementirana. Tabela 5.4: Vhodni in izhodni dokumenti Vhod Izhodi - Izvorna koda - Razredni diagram - Generirano poročilo o razredih v razrednem diagramu Generiranje paketnega diagrama Paketni diagram lahko prav tako generiramo s pomočjo orodja za povratno inţenirstvo. V vsak paket lahko dodamo predhodno generirane diagrame. Paketni diagram je posebno uporaben, kadar gre za obseţno aplikacijo in ko postane razredni diagram nepregleden. Vhodi Izhod - Razredni diagram - Paketni diagram - Izvorna koda Tabela 5.5: Vhodni in izhodni dokumenti

34 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran Podatkovni model Podatkovni model generiramo s pomočjo orodja, ki ga izberemo na osnovi podatkovne baze, ki se uporablja na izbranem projektu, ki ga dokumentiramo. Podatkovni model nam omogoča celovit vpogled na podatkovno bazo sistema, ki jo sestavlja skupek entitet in odvisnosti med njimi. Vhod Podatkovna baza sistema Tabela 5.6: Vhodni in izhodni dokumenti Izhod Entitetno relacijski model Diagram zaporedja Diagrame zaporedja lahko prav tako generiramo s pomočjo orodja za povratno inţenirstvo. Orodja za povratno inţenirstvo so omejena na programski jezik v katerem je aplikacija napisana, zato je v določenih primerih diagrame zaporedja teţko ali celo nemogoče generirati. Diagrami zaporedja prikazujejo interakcijo v obliki mnoţice sporočil, ki si jih izmenjujejo objekti v času izvajanja funkcionalnosti sistema. Vhod Izvorna koda Izhod Diagram zaporedja Tabela 5.7: Vhodni in izhodni dokumenti Diagram namestitve Diagram namestitve pomaga pri razumevanju arhitekturne namestitve sistema. Prikazuje relacije med posameznimi segmenti programske opreme, ter nam daje vpogled v arhitekturo. Diagrama namestitve ne moremo generirati s pomočjo orodij za povratno inţenirstvo, temveč ga je potrebno narisati ročno.

35 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran Zemljevid strani Zemljevid strani koristi pri pregledu preglednosti spletne strani oziroma uporabniškega vmesnika aplikacije, ki jo dokumentiramo. Zemljevid strani nam prikaţe strukturo uporabniškega vmesnika. Pri izdelavi zemljevida strani moramo biti pozorni tudi na več vrst oziroma tipov uporabnikov, ki sistem uporabljajo. Vhod Uporabniški vmesnik Tabela 5.8: Vhodni in izhodni dokumenti Izhod Zemljevid strani 5.3 Zaključna faza Zaključna faza procesa dokumentacije je namenjena pregledu dokumentov, ki so nastali v predhodnih fazah, katere pregledamo, dopolnimo in povzamemo ugotovitve oziroma izkušnje, ki smo jih skozi proces dokumentacije pridobili Dopolnitev dokumentacije Pridobljeno dokumentacijo dopolnimo s splošnimi informacijami o projektu ter z informacijami, ki dopolnjujejo vse nastale dokumente skozi proces. Dopolnitev dokumentacije sluţi za boljše razumevanje predhodno izdelane dokumentacije ter dokumentiranega projekta kot takšnega Ugotovitve Glede na pridobljeno dokumentacijo zapišemo vse ugotovitve in izkustva, ki smo jih pridobili pri dokumentaciji projekta skozi proces dokumentacije. V tem razdelku zapišemo tudi ideje o nadgradnji oziroma prilagoditvi sistema, ki smo ga dokumentirali.

36 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 26 6 SKLEP Proces izdelave tehnične dokumentacije odprtokodne programske opreme je, za razliko od ogrodij na katerih temelji, namenjen izdelavi tehnične dokumentacije ţe razvite programske opreme. Sluţi kot osnova za nadaljnji razvoj oziroma prilagoditev odprtokodne programske opreme potrebam organizacije. Proces podaja smernice in dobre prakse pri izdelavi tehnične dokumentacije odprtokodne programske opreme ter omogoča celovit pogled na delovanje sistema in njegove funkcionalnosti. Proces izdelave tehnične dokumentacije je nastal na osnovi dokumentacije odprtokodnega projekta. Bazira na uporabi diagramov UML, ki grafično prikazujejo lastnosti dokumentirane programske opreme na vsakem segmentu tako nastalega procesa. Notacija, z uporabo tehnik jezika UML, omogoča enostaven pregled delovanja sistema in identifikacijo funkcionalnosti sistema. Prednost procesa je predvsem v celovitem vpogledu na delujoč sistem, ki ga dobimo na osnovi dokumentacije sistema. Nastala dokumentacija omogoča laţje razumevanje ter hitro vpeljavo novih razvijalcev v poznavanje funkcionalnosti odprtokodnega sistema. Pomembno je, da razvijalci razumejo notacijo UML. Proces se lahko v prihodnje uporablja pri dokumentaciji nastajajoče kot tudi za dokumentacijo ţe obstoječe programske opreme. Z dosledno dokumentacijo programske opreme bi odprtokodna programska oprema pridobila na vrednosti in kvaliteti izdelave lete ter omogočala laţjo nadgradnjo in modifikacije programske opreme. Zasnova procesa ponuja še mnogo moţnosti nadgrajevanja, osnovne smernice pa so: proces dokumentacije komercialne programske opreme, procesno vodena dokumentacija programske opreme v razvoju, prilagajanje procesa in njegovo nadgrajevanje potrebam organizacije.

37 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 27 7 VIRI 1. Bb ump0103_big(en-us,TechNet.10).gif (GIF Image, 400x253 pixels), Zadnjič obiskano Chapter 1 - Introduction to the Microsoft Solutions Framework, Zadnjič obiskano Module 1: The Total Solution Life Cycle, Zadnjič obiskano Shafqat Ahmed s.net Blog: Comparison of Different Open Source Licenses - With Comparison Chart!, Zadnjič obiskano Rational Unified Process- Best practices for software development teams, 51_bestpractices_TP026B.pdf, Zadnjič obiskano SourceForge.net: Project Statistics for OrangeHRM - Human Resource Management, type=prdownload&mode=alltime&file_id=0, Zadnjič obiskano SourceForge.net: Project Statistics for OrangeHRM - Human Resource Management, type=sfweb&mode=alltime, Zadnjič obiskano Vse o Odprti kodi - COKS - Center odprte kode Slovenije", Zadnjič obiskano A Comparison between Agile and Traditional Software Development Methodologies, M.A.Awad, 2005, Between-Agile-and-Traditional-SW-Development-Methodologies, obiskano Zadnjič

38 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran Agile development: Mainstream adoption has changed agility; Dave West and To Grant, Ph.D. for application development & program management professional, Zadnjič obiskano Comparative study MSF vs. RUP4ASD: Rational unified process vs. Microsoft solutions framework for agile software development by Johan W.A. Traa: Erasus University Rotterdam, The Nederland 12. IBM Rational Unified Process for small projects, 01.ibm.com/software/awdtools/rup/, Zadnjič obiskano

39 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 29 8 PRILOGE 8.1 Kazalo slik Slika 2.1: Primerjava odprtokodnih licenc [4]... 4 Slika 3.1: Uporaba metodologij razvoja v organizacijah [10]... 9 Slika 4.1: Proces razvoja programske opreme po IBM RUP [5, 11, 12] Slika 4.2: MSF Procesni model [1] Slika 4.3: Disciplina upravljanje [3] Slika 4.4: Primerjava po fazah [11] Slika 5.1: Proces dokumentacije Slika 5.2: Spletni vmesnik procesa tehnične dokumentacije odprtokodne programske opreme Kazalo grafov Graf 2.1: Statistika prenosov Orange HRM [6]... 6 Graf 2.2: Spletni promet projekta na domači strani [7]... 7

40 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran Seznam preglednic Tabela 4.1: Dokumenti začetne faze (RUP) in faze predvidevanja (MSF) [2, 11] Tabela 4.2: Dokumenti faze zbiranja informacij (RUP) in načrtovanja (MSF) [2, 11] Tabela 4.3: Dokumenti faze konstrukcije (RUP) in Konstrukcije (MSF) [2, 11] Tabela 4.4: Dokumenti faz prevzema (RUP), Namestitve in spremljanja (MSF) [ 2, 11].. 16 Tabela 5.1: Vhodni in izhodni dokumenti Tabela 5.2: Vhodni in izhodni dokumenti Tabela 5.3: Vhodni in izhodni dokumenti Tabela 5.4: Vhodni in izhodni dokumenti Tabela 5.5: Vhodni in izhodni dokumenti Tabela 5.6: Vhodni in izhodni dokumenti Tabela 5.7: Vhodni in izhodni dokumenti Tabela 5.8: Vhodni in izhodni dokumenti... 25

41 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 31

42 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 32

43 Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 33