UML – nėra naujiena daugeliui programuotojų, IT sistemų projektuotojų bei analitikų. Galima rasti pakankamai literatūros šaltinių, kuriuose ši metodologija išsamiai išdėstoma. Tačiau kokią realią naudą gali duoti šios metodologijos naudojimas konkrečiai verslo įmonei? Ar UML iš tiesų yra pakankamai intuityvi ir paprasta, kad ją galėtų naudoti skirtingų sričių specialistai?
UML (Unified Modeling Language) – nėra naujiena daugeliui programuotojų, IT sistemų projektuotojų bei analitikų. Galima rasti pakankamai literatūros šaltinių, kuriuose ši metodologija išsamiai išdėstoma. Tačiau kaip ji gali būti taikoma konkrečiuose projektuose? Kokią realią naudą gali duoti šios metodologijos naudojimas konkrečiai verslo įmonei? Ar UML iš tiesų yra pakankamai intuityvi ir paprasta, kad ją galėtų naudoti skirtingų sričių specialistai?
Į šiuos klausimus paprašėme atsakyti UAB „Baltijos programinė įranga“ produktų plėtros direktoriaus Sauliaus Kaukėno, jau kelis metus dėstančio įvairius UML, „Java“, programinės įrangos kūrimo proceso bei projektų valdymo kursus Europos šalyse bei Lietuvoje.
UML – KAS TAI?
Tai kas gi yra UML (Unified Modeling Language)? Kalbant paprastai – tai komunikavimo priemonė, DAR VIENA specifikavimo kalba. Palyginti su kitomis specifikavimo kalbomis, ji yra grafinė ir labai plati. Šios dvi savybės, ko gero, ir skatina kai kuriuos skeptikus apibūdinti UML kaip „sudėtingą“. Taip, ji yra kiek sudėtinga, bet tuo pat metu universali ir palaikoma daugelio metodologų.
Pagrindinės UML savybės:
- Devynios įvairių rūšių diagramos;
- Grafinio modeliavimo kalba, nepriklausoma nuo konkrečios programavimo kalbos;
- Bendras žymėjimo (notacijos) standartas;
- Vieninga terminologija;
- Būdas:
- Vizualizuoti;
- Specifikuoti;
- Dokumentuoti.
UML susideda iš 9 skirtingų diagramų, kurių kilmė skirtinga – pradedant Harrelo „Statechart“ diagramomis ir baigiant Jacobsono „Use case“. UML visos jos yra apjungtos ir gali būti naudojamos kartu. Tuo pačiu, UML išraiškos galimybės yra kur kas didesnės nei bet kurio iš jo pirmtakų: OMT, „Booch“ ir t. t.
UML pagalba galima specifikuoti, vizualizuoti ir dokumentuoti programinės įrangos sistemų modelius – jų struktūrą ir projektus.
UML žymėjimo standartas yra labiausiai paplitęs palyginti su kitais žinomais standartais: „Booch“, OMT, „Jacobson OOSE“, „Coad and Yourdon“, be to šio standarto pavyzdžių bei nuorodų galima rasti daugelyje literatūros šaltinių ir internete.
Naudojama vieninga terminologija, taigi programuotojai, nepriklausomai nuo jų naudojamos programavimo kalbos, gali lengviau komunikuoti tarpusavyje. Pavyzdžiui tai, kas OMT buvo vadinama „moduliu“, o Boocho – „Klasių kategorija“, UML’e vadinama „paketu“. Tai, kas „Java“ arba C++ kalboje vadinama „statiniu“, UML’e vadinama „klasės“ (pl. „objekto“).
UML specifikavimo kalba leidžia aprašyti tikrovę supaprastinus ją iki valdomo informacijos kiekio, sisteminti bei klasifikuoti surinktas žinias. UML modeliavimas – tai formalizuotas būdas užfiksuoti, perduoti ir pasinaudoti žiniomis.
UML PASAULYJE
„BZ Research“ tyrimas (2003 m. birželis, JAV), rodo, kad 34 % programuotojų naudoja „UML-based modeling“ kai kurioms (94 %) arba visoms (6 %) sistemoms modeliuoti.
Lietuvoje tik nedaugelis įmonių naudoja UML notacijos sistemą. Daugeliu atveju tai telekomunikacijų bendrovės, bankai, užsienio kompanijų atstovybės Lietuvoje ir pan. Priežastys, dėl kurių vidutinio dydžio IT įmonės nenaudoja UML metodologijos yra įvairios: nepakankamas IT specialistų pasirengimas bei kvalifikacija, taupomas laikas informacinės sistemos projektavimo etapuose, ribotos finansinės galimybės įsigyti naujausiomis technologijomis pagrįstą programinę įrangą ir pan.
UML NAUDA JŪSŲ FIRMAI
IT padalinių sprendžiamos problemos
Iš pateiktų duomenų matome, kad tik 16 % projektų buvo sėkmingi (mažose kompanijose), o didelėse situacija yra prastesnė – TIK 9 % projektų atliekami laiku ir neviršijant biudžeto.
Šių tyrimų metu pateikti duomenys, kad net 56 % programinės įrangos defektų atsiranda dėl klaidų, padarytų reikalavimų rinkimo fazės metu.
Čia pateikiamos pagrindinės IT padalinių sprendžiamos problemos, tačiau yra ir kitų, ne taip akivaizdžiai pastebimų problemų.
Viena jų – įmonės veiklos procesų artefaktų fiksavimo problema
Koncentruodamos dėmesį į problemų sprendimą (pvz. į veikiančios programinės įrangos sukūrimą) kompanijos dažnai pamiršta apie šių problemų sprendimo procesų sukurtų artefaktų vertę. Būtent šie artefaktai geriausiai užfiksuoja tai, ką išmoko organizacija: žinias, patirtį. Labai dažnai ši vertė organizacijose yra negrįžtamai prarandama, ir tos pačios organizacijos išleidžia daug pinigų ir laiko, kad vėl atrastų tai, ką jos jau žinojo, bet niekad neužfiksavo.
Neefektyvi komunikacija tarp komandos narių
Ar jūsų projektuose vadovai ir programuotojai kalba ta pačia kalba ir lengvai supranta vieni kitus?
Projekto vadovo nurodymai dažnai būna neaiškūs arba neišsamūs, nes išdėstomi žodžiu, nepateikiant vizualios informacijos, kuri suvokiama žymiai efektyviau. Programuotojai dažniausiai skirtingai įsivaizduoja sistemą ir naudoja skirtingas sąvokas, kurios gali būti klaidingai interpretuojamos. Nėra vieningos notacijos sistemos, kuri užtikrintų efektyvią komunikaciją visuose projekto etapuose.
IT sistemų funkcionalumas
IT sistemos yra palyginti brangios, todėl labai svarbu, kad jos atitiktų vartotojo poreikius: darytų tik tai, ką reikia; taip, kaip reikia IR NIEKO DAUGIAU!
Sukurta IT sistema dažnai gali DAUG, t. y. atlieka NE TIK reikalingas funkcijas. Tokiu būdu nenaudojamos papildomos funkcijos dažnai yra ne privalumas, bet papildomos problemos. Labai svarbu pradedant kurti sistemą tinkamai apibrėžti ir suderinti su galutiniais vartotojais bei užsakovais visus sistemos panaudojimo atvejus (funkcijas)? Labai svarbu, kad galutinai sistemos vartotojai kuo anksčiau būtų įtraukti į kūrimo procesą. Kai galutiniai vartotojai pirmąkart pamato sistemą tik tuomet, kai jau reikia ją pradėti naudoti, jos veikimas dažnai būna pagrįstas programuotojų fantazija, o ne jos vartotojų poreikiais.
Reikalavimų kaita
Maža to, kad sudėtinga aprašyti esamus sistemos reikalavimus, jie nuolat keičiasi.
Besikeičiant verslo sąlygoms atitinkamai keičiasi ir reikalavimai IT sistemoms. Būtina užtikrinti, kad jūsų naudojamos technologijos garantuotų kiek galima neskausmingesnę sistemos modifikaciją pasikeitus verslo aplinkai.
Sistemų dokumentavimas
Ar pasirūpinote, kad išeidami specialistai firmoje „paliktų“ kiek galima daugiau turimų žinių?
IT specialistais išeina kartu su jų turimomis žiniomis. Rinkoje galima pasisamdyti žmonių su konkrečios technologijos (DBVS, programavimo kalbos) žiniomis, bet žinios apie jūsų sistemą dažnai yra unikalios. Vienintelė išeitis – tinkamai parengta sistemos dokumentacija, kuri užtikrina, kad pasikeitus įmonės personalui ar verslo aplinkai esama sistema bus įmanoma modernizuoti minimaliomis sąnaudomis.
Taisyti arba plėtoti nedokumentuotą sistemą tolygu dirbti taksistu nepažįstamame mieste be žemėlapio.
IT vadovų poreikiai:
- Projekto vėlavimo ir kaštų padidėjimo rizikos mažinimas;
- Geresnis žinių valdymas;
- Gebėjimas lanksčiai prisitaikyti prie kintančių aplinkybių;
- Efektyvesnis projekto lėšų panaudojimas.
Kaip matome, IT vadovų poreikiai dideli, kai tuo tarpu projektu statistika yra prasta. Per keletą dešimtmečių buvo pasiūlyta įvairių priemonių šioms problemoms spręsti – formalių metodologijų, naujų programavimo kalbų ir paradigmų. Vienos buvo šiek tiek sėkmingesnės, kitos – visai nesėkmingos. Bet tarp jų nebuvo nei vienos, kuri pakeistų situaciją kardinaliai.
Norėtume pristatyti jau ir Lietuvoje populiarėjančią „MagicDraw UML“ modeliavimo priemonę, bei parodyti kiek ji gali prisidėti prie ką tik išvardintų problemų ir uždavinių sprendimo.
Prie ką tik išvardintų problemų ir uždavinių sprendimo gali prisidėti jau ir Lietuvoje populiarėjanti „MagicDraw UML“ modeliavimo priemonė. Plačiau apie ją skaitykite skyriuje „Programinė įranga“.
