UML diagrama
Unifikuota modeliavimo kalba (UML) - tai programinės įrangos inžinerijos srityje naudojama bendrosios paskirties modeliavimo kalba, kuria siekiama sukurti standartinį sistemos projektavimo vizualizavimo būdą. [1]
Iš pradžių UML buvo sukurta dėl noro standartizuoti skirtingas užrašų sistemas ir programinės įrangos projektavimo metodus, kuriuos 1994-1995 m. sukūrė Grady Boochas, Ivaras Jacobsonas ir Jamesas Rumbaughas iš "Rational Software", o 1996 m. jie toliau juos tobulino. [1]
1997 m. UML kaip standartą patvirtino Objektų valdymo grupė (OMG), ir nuo to laiko ši organizacija jį administruoja. 2005 m. Tarptautinė standartizacijos organizacija (ISO) taip pat paskelbė unifikuotą modeliavimo kalbą kaip patvirtintą ISO standartą.[2] Nuo to laiko jis periodiškai peržiūrimas, kad apimtų naujausią UML versiją. [3]
Nors UML yra gerai žinoma ir plačiai naudojama švietimo ir akademiniuose darbuose, nuo 2013 m. ji mažai naudojama pramonėje, o didžioji jos dalis yra neformali ir ad hoc. [4]
Turinys
[paslÄ—pti]
- 1 Istorija
- 1.1 Prieš UML 1.x
- 1.2 UML 1.x
- 1.3 UML 2.x
- 2 Dizainas
- 2.1 Programinės įrangos kūrimo metodai
- 2.2 Modeliavimas
- 3 diagramos
- 3.1 Struktūrinės diagramos
- 3.2 Elgesio diagramos
- 3.2.1 Sąveikos diagramos
- 4 Meta modeliavimas
- 5 Priėmimas
- 6 kritika
- 6.1 UML 1.x kritika
Istorija[redaguoti šaltinį | redaguoti]
Į objektus orientuotų metodų ir užrašų istorija
UML vystėsi nuo dešimtojo dešimtmečio antrosios pusės, o jos ištakos siekia aštuntojo dešimtmečio pabaigoje ir dešimtojo dešimtmečio pradžioje sukurtus į objektus orientuotus metodus. Laiko juostoje (žr. paveikslėlį) pateikiami svarbiausi objektinio modeliavimo metodų ir užrašų istorijos momentai.
Iš pradžių ji pagrįsta Boocho metodo, objektų modeliavimo technikos (OMT) ir į objektus orientuotos programinės įrangos inžinerijos (OOSE) užrašais, kurie integruoti į vieną kalbą. [5]
Prieš UML 1.x[redaguoti šaltinį | redaguoti]
1994 m. "Rational Software Corporation" iš "General Electric" pasamdė Jamesą Rumbaughą, kuris tapo dviejų populiariausių to meto objektinio modeliavimo metodų šaltiniu:[6] J. Rumbaugh'o objektų modeliavimo metodas (OMT) ir Grady Booch'o metodas. Netrukus jiems padėjo Ivaras Jakobsonas, į objektus orientuotos programinės įrangos inžinerijos (OOSE) metodo kūrėjas, kuris 1995 m. prisijungė prie "Rational". [1]
Šiems trims (Rumbaugh, Jacobson ir Booch) techniškai vadovaujant, 1996 m. buvo suburtas konsorciumas, pavadintas UML partneriais, kurio tikslas - užbaigti Unifikuotos modeliavimo kalbos (UML) specifikaciją ir pasiūlyti ją standartizuoti Objektų valdymo grupei (OMG). Partnerystę sudarė ir kitos suinteresuotos šalys (pavyzdžiui, HP, DEC, IBM ir "Microsoft"). 1997 m. sausio mėn. konsorciumas pasiūlė OMG UML 1.0 projektą. Tą patį mėnesį "UML partneriai" sudarė grupę, skirtą tiksliai kalbos konstrukcijų reikšmei apibrėžti, kuriai pirmininkavo Crisas Kobrynas, o administravo Edas Eykholtas, kad ji užbaigtų specifikaciją ir integruotų ją su kitomis standartizacijos pastangomis. Šio darbo rezultatas - UML 1.[1][7]1 - 1997 m. rugpjūčio mėn. buvo pateiktas OMG, o 1997 m. lapkričio mėn.
UML 1.x[redaguoti šaltinį | redaguoti]
Po pirmosios versijos buvo sudaryta[1] darbo grupė kalbai tobulinti, kuri išleido keletą nedidelių 1.3, 1.4 ir 1.5 versijų. [8]
Buvo pastebėta, kad jo parengti standartai (taip pat ir pirminis standartas) yra dviprasmiški ir nenuoseklūs. [9][10]
UML 2.x[redaguoti šaltinį | redaguoti]
2005 m. UML 2.0 pagrindinė versija pakeitė 1.5 versiją, kuri buvo kuriama kartu su išsiplėtusiu konsorciumu, siekiant dar labiau patobulinti kalbą, kad būtų atsižvelgta į naują jos funkcijų naudojimo patirtį. [11]
Nors UML 2.1 niekada nebuvo išleista kaip oficiali specifikacija, 2007 m. pasirodė 2.1.1 ir 2.1.2 versijos, o 2009 m. vasarį - UML 2.2. UML 2.3 oficialiai išleista 2010 m. gegužės mėn.[12] UML 2.4.1 oficialiai išleista 2011 m. rugpjūčio mėn.[12] UML 2.5 buvo išleista 2012 m. spalio mėn. kaip "In process" versija, o oficialiai išleista 2015 m. birželio mėn. [12]
UML 2.x specifikaciją sudaro keturios dalys:
- Superstruktūra, apibrėžianti diagramų ir jų modelio elementų notaciją ir semantiką
- Infrastruktūra, apibrėžianti pagrindinį metamodelį, kuriuo grindžiama antstatas.
- Objektų apribojimų kalba (OCL), skirta modelio elementų taisyklėms apibrėžti
- UML diagramų mainai, kuriuose apibrėžiama, kaip keičiamasi UML 2 diagramų maketais
Dabartinės šių standartų versijos pateikiamos toliau: 2.4.1 versija, 2.4.1 versija, 2.3.1 versija, 2.3.1 versija ir 1.0 versija UML Diagram Interchange.[13] Ją toliau atnaujina ir tobulina peržiūros darbo grupė, kuri sprendžia visas su kalba susijusias problemas. [14]
Dizainas[redaguoti šaltinį | redaguoti]
Suvienodinta modeliavimo kalba (UML) suteikia galimybę vizualizuoti sistemos architektūrinius brėžinius diagramoje (žr. paveikslėlį), įskaitant tokius elementus kaip: [5]
- Bet kokia veikla (darbo vietos)
- Atskiri sistemos komponentai
- Ir kaip jie gali sąveikauti su kitais programinės įrangos komponentais.
- Kaip veiks sistema
- Kaip subjektai sąveikauja su kitais subjektais (komponentai ir sąsajos)
- Išorinė naudotojo sąsaja
Nors iš pradžių ji buvo skirta tik į objektus orientuotam projektavimo dokumentavimui, Unifikuota modeliavimo kalba (UML) buvo išplėsta, kad apimtų platesnį projektavimo dokumentacijos rinkinį (kaip nurodyta pirmiau), [15]ir buvo pripažinta naudinga įvairiomis aplinkybėmis. [16]
Programinės įrangos kūrimo metodai[redaguoti šaltinį | redaguoti]
UML pati savaime nėra kūrimo metodas, [17]tačiau ji buvo sukurta taip, kad būtų suderinama su to meto svarbiausiais objektinės programinės įrangos kūrimo metodais (pvz.,OMT, Boocho metodu, Objectory) ir ypač su RUP, kurį iš pradžių ketinta naudoti pradėjus dirbti "Rational Software Inc.".
Modeliavimas[redaguoti šaltinį | redaguoti]
Svarbu atskirti UML modelį nuo sistemos diagramų rinkinio. Diagrama yra dalinis grafinis sistemos modelio atvaizdavimas. Diagramų rinkinys nebūtinai turi visiškai apimti modelį, o diagramos ištrynimas modelio nepakeičia. Modelyje taip pat gali būti dokumentacija, kuria grindžiami modelio elementai ir diagramos (pavyzdžiui, rašytiniai naudojimo atvejai).
UML diagramose pateikiami du skirtingi sistemos modelio[18] vaizdai:
- Statinis (arba struktūrinis) požiūris: pabrėžia statinę sistemos struktūrą, naudojant objektus, atributus, operacijas ir ryšius. Struktūrinis vaizdas apima klasių diagramas ir sudėtines struktūros diagramas.
- Dinaminis (arba elgsenos) vaizdas: pabrėžiamas dinamiškas sistemos elgesys, parodant objektų bendradarbiavimą ir objektų vidinių būsenų pokyčius. Šiam vaizdui priskiriamos sekų diagramos, veiklos diagramos ir būsenų mašinų diagramos.
UML modeliais tarp UML įrankių galima keistis naudojant XML metaduomenų mainų formatą (XMI).
Schemos[redaguoti šaltinį | redaguoti]
| UML diagramos |
| Struktūrinės UML diagramos |
|
| Elgesio UML diagramos |
|
UML 2 turi daug diagramų tipų, kurie skirstomi į dvi kategorijas.[5] Kai kurių tipų diagramos vaizduoja struktūrinę informaciją, o likusios diagramos vaizduoja bendrus elgsenos tipus, įskaitant keletą diagramų, vaizduojančių įvairius sąveikos aspektus. Šias diagramas galima hierarchiškai suskirstyti į kategorijas, kaip parodyta toliau pateiktoje klasių diagramoje: [5]
Visose šiose diagramose gali būti komentarų ar pastabų, paaiškinančių naudojimą, apribojimus ar ketinimus.
Struktūrinės schemos[redaguoti šaltinį | redaguoti]
Struktūros diagramose pabrėžiami dalykai, kurie turi būti modeliuojamoje sistemoje. Kadangi struktūros diagramos vaizduoja struktūrą, jos plačiai naudojamos dokumentuojant programinės įrangos sistemų architektūrą. Pavyzdžiui, komponentų diagrama, kurioje aprašoma, kaip programinės įrangos sistema suskirstyta į komponentus, ir parodoma šių komponentų tarpusavio priklausomybė.
- Komponentų diagrama
- Klasės diagrama
Elgesio diagramos[redaguoti šaltinį | redaguoti]
Elgsenos diagramose pabrėžiama, kas turi įvykti modeliuojamoje sistemoje. Kadangi elgsenos diagramos iliustruoja sistemos elgseną, jos plačiai naudojamos programinės įrangos sistemų funkcionalumui aprašyti. Pavyzdžiui, veiklos diagramoje aprašoma sistemos komponentų verslo ir operacinė veikla žingsnis po žingsnio.
- Veiklos diagrama
- Naudojimo atvejų diagrama
Sąveikos diagramos[redaguoti šaltinį | redaguoti]
Sąveikos diagramose, kurios yra elgsenos diagramų poaibis, pabrėžiamas valdymo ir duomenų srautas tarp modeliuojamos sistemos elementų. Pavyzdžiui, sekos diagrama, kuri parodo, kaip objektai bendrauja tarpusavyje pranešimų seka.
- Sekos diagrama
- Komunikacijos schema
Metamodeliavimas[redaguoti šaltinį | redaguoti]
Pagrindinis straipsnis: Metaobjektų priemonė
Metaobjektų priemonės iliustracija
Objektų valdymo grupė (OMG) sukūrė metamodeliavimo architektūrą, skirtą apibrėžti unifikuotą modeliavimo kalbą (UML), vadinamą metaobjektų priemone (MOF).[19] Metaobjektų priemonė sukurta kaip keturių sluoksnių architektūra, kaip parodyta paveikslėlyje dešinėje. Viršutiniame sluoksnyje, vadinamame M3 sluoksniu, pateikiamas meta-meta modelis. Šis M3 modelis yra kalba, kurią Meta-Object Facility naudoja metamodeliams, vadinamiems M2 modeliais, kurti.
Ryškiausias 2 lygmens metaobjektų priemonės modelio pavyzdys yra UML metamodelis, t. y. modelis, kuriame aprašoma pati UML. Šie M2 modeliai aprašo M1 sluoksnio elementus, taigi ir M1 modelius. Tai būtų, pavyzdžiui, UML kalba parašyti modeliai. Paskutinis sluoksnis yra M0-sluoksnis arba duomenų sluoksnis. Jis naudojamas sistemos vykdymo metu esantiems egzemplioriams aprašyti. [20]
Metamodelis gali būti išplėstas naudojant mechanizmą, kuris vadinamas stereotipavimu. Brianas Hendersonas-Sellersas ir Cesaras Gonzalezas-Perezas knygoje "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" (Stereotipų mechanizmo naudojimas ir piktnaudžiavimas UML 1.x ir 2.0 versijose) kritikuoja šį mechanizmą kaip nepakankamą ir (arba) netinkamą. [21]
Įvaikinimas[redaguoti šaltinį | redaguoti]
UML buvo pripažinta naudinga daugelyje projektavimo kontekstų, [16]todėl IT bendruomenėje ji tapo beveik visur paplitusi. [22]
Kartais jis buvo traktuojamas kaip sidabrinė dizaino kulka, todėl kilo problemų jį naudojant. Neteisingas jo naudojimas apima perteklinį jo naudojimą (su juo projektuojama kiekviena maža sistemos kodo dalis, o tai nereikalinga) ir manymą, kad su juo bet kas gali suprojektuoti bet ką (net ir tie, kurie nėra programavę). [23]
Ji yra didelė kalba, turinti daugybę konstrukcijų. Kai kurie (įskaitant Jacobsoną) mano, kad jų yra per daug ir kad tai trukdo ją išmokti (taigi ir naudoti). [24]
Kritika[redaguoti šaltinį | redaguoti]
| Šio straipsnio skiltis "Kritika arba kontroversija" gali pakenkti neutraliam straipsnio požiūriui į temą. Prašome įtraukti skyriaus turinį į visą straipsnį arba perrašyti medžiagą. (2010 m. gruodžio mėn.) |
Pramonės atstovai dažniausiai kritikuoja UML: [4]
- nenaudinga: "[nesuteikia] jiems pranašumų, palyginti su jų dabartine, išsivysčiusia praktika ir reprezentacijomis".
- per sudėtinga, ypač bendraujant su klientais: "Geriausia priežastis nenaudoti UML yra ta, kad ji nėra "skaitoma" visoms suinteresuotosioms šalims. Ko verta UML, jei verslo naudotojas (klientas) negali suprasti jūsų modeliavimo pastangų rezultato?"
- reikia sinchronizuoti UML ir kodą, kaip ir apskritai dokumentaciją.
UML 1.x kritika[redaguoti šaltinį | redaguoti]
Kardinalumo užrašas
Kaip ir duomenų bazių Čeno, Bachmano ir ISO ER diagramose, klasių modeliuose nurodyta naudoti "look-across" kardinalumus, nors kai kurie autoriai (Merise, [25]Elmasri ir Navathe[26] ir kt[27].) pirmenybę teikia tos pačios pusės arba "look-here" vaidmenims ir mažiausiems bei didžiausiems kardinalumams. Naujausi tyrėjai (Feinerer, [28]Dullea ir kt.)[29] parodė, kad UML ir ER diagramose naudojamas "look-across" metodas yra mažiau veiksmingas ir mažiau nuoseklus, kai taikomas n-nariniams santykiams, kurių eiliškumas >2.
Feineris sako: "Problemų kyla, jei dirbame pagal UML asociacijoms naudojamą "look-across" semantiką. Hartmannas[30] tiria šią situaciją ir parodo, kaip ir kodėl įvairios transformacijos nepavyksta." (Nors minėtas "sumažinimas" yra klaidingas, nes abi 3.4 ir 3.5 diagramos iš tikrųjų yra tos pačios), taip pat "Kaip pamatysime kituose puslapiuose, "look-across" interpretacija sukelia keletą sunkumų, kurie neleidžia išplėsti paprastų mechanizmų iš dvejetainių į n-arines asociacijas".
Klausimai ir atsakymai
K: Kas yra unifikuota modeliavimo kalba (UML)?
A: Suvienodinta modeliavimo kalba (UML) yra modeliavimo kalba, naudojama programinės įrangos inžinerijoje, siekiant pateikti standartinį būdą, kaip parodyti, kaip atrodo sistemos projektas.
K: Koks buvo pirminis UML tikslas?
A.: Pirminis UML tikslas buvo standartizuoti skirtingas užrašų sistemas ir programinės įrangos projektavimo metodus.
K: Kas sukūrė UML?
A.: UML 1994-1995 m. sukūrė Grady Boochas, Ivaras Jacobsonas ir Jamesas Rumbaughas iš "Rational Software", o 1996 m. jie toliau ją tobulino.
K: Kada UML buvo priimtas kaip standartas?
A.: 1997 m. Objektų valdymo grupė (OMG) priėmė UML kaip standartą.
K: Kas valdo UML?
A.: Nuo 1997 m., kai UML buvo priimta kaip standartas, ją valdo Objektų valdymo grupė.
K: Ar UML buvo pripažintas tarptautiniu standartu?
A: Taip, 2005 m. Tarptautinė standartizacijos organizacija (ISO) pripažino UML tarptautiniu standartu.
K: Koks UML tikslas programinės įrangos inžinerijoje?
A.: UML paskirtis programinės įrangos inžinerijoje - pateikti standartinį būdą, kaip parodyti, kaip atrodo sistemos projektas, kad kūrėjai ir suinteresuotosios šalys jį lengvai suprastų ir perduotų.
