UML — ühtlustatud modelleerimiskeel: definitsioon, ajalugu ja diagrammid
UML (ühtlustatud modelleerimiskeel): definitsioon, ajalugu ja diagrammid — selged selgitused, standardi areng, peamised diagrammitüübid ja praktilised näited.
Unified Modeling Language (UML) on üldotstarbeline, arendusotstarbeline modelleerimiskeel tarkvaratehnika valdkonnas, mille eesmärk on pakkuda standardset viisi süsteemi disaini visualiseerimiseks. [1]
UML-i idee ja motivatsioon pärinevad soovist ühtlustada eri notatsioonisüsteeme ja lähenemisviise tarkvara projekteerimisel. Selle aluse panid Grady Booch, Ivar Jacobson ja James Rumbaugh, kes töötasid koos 1994–1996 Rational Software'is ning ühendasid oma mudelimisideed ühtseks notatsiooniks. Nad arendasid seda edasi kuni ametliku standardini jõudmiseni. [1]
1997. aastal võttis UMLi standardina vastu Object Management Group (OMG) ja sellest ajast alates on see organisatsiooni hallatud. 2005. aastal avaldas ühtlustatud modelleerimiskeele ka Rahvusvaheline Standardiorganisatsioon (ISO) heakskiidetud ISO standardina. [2] Pärast seda on UML-i spetsiifikatsiooni perioodiliselt uuendatud, et kajastada uusi paradigmasid ja täpsustada semantikat. [3]
Kuigi UML on tuntud ja laialdaselt kasutusel hariduses ja akadeemilistes töödes, teatasid mõned uuringud ja tööstuse ülevaated 2013. aasta seisuga, et praktilises tööstuskasutuses kasutatakse UML-i sageli vähe, pigem mitteametlikult ja ad hoc. [4]
Mis on UML ja milleks seda kasutatakse?
UML on keel, mis pakub standardset sümbolite ja notatsioonireeglite kogumit süsteemide modelleerimiseks. Peamised eesmärgid on:
- visualiseerida süsteemi arhitektuuri ja käitumist;
- täpsustada ja dokumenteerida nõudeid ning disaini;
- toetada süsteemi ehitamist ja kommunikatsiooni meeskonna vahel;
- võimaldada automaatset koodi- või mudelite transformatsiooni (nt Model-Driven Architecture, MDA) ja reverse-engineeringut.
UML ei ole programmeerimiskeel, vaid modelleerimiskeel: see kirjeldab, kuidas elemente (klassid, objektid, protsessid jms) esitada ja omavahel siduda, et oleks üheselt arusaadav nii inimestele kui tööriistadele.
Lühike ajalugu ja standardid
Algsed UML-i versioonid tulid 1990ndate keskel. UML 1.x versioonid olid laialt kasutusel, seejärel toimus suur uuendus ja ümberkorraldus UML 2.0-s, mis fixis semantikat ja lisas uusi diagrammitüüpe. Hiljem on spetsiifikatsioon täienenud ja korrigeeritud (nt UML 2.1 → 2.5 → 2.5.1), mille eesmärk oli parandada selgust ja tööriistade ühilduvust. OMG jätkab UML-i haldamist ja väljaandmist ning mõnes kontekstis on olemas ka ISO-le kinnitatud variant. [2][3]
Põhilised diagrammid
UML jagab diagrammid üldiselt kaheks rühmaks: struktuuri ja käitumise diagrammid. Peamised tüübid on:
- Struktuuridiagrammid: klassidiagramm, objekti- (instance) diagramm, komponentdiagramm, pakettdiagramm, composite structure diagramm, deployment (paigutus) diagramm.
- Käitumisdiagrammid: use case (kasutusjuht), tegevus- (activity) diagramm, oleku- (state machine) diagramm, järjestus- (sequence) diagramm, suhtlus- (communication) diagramm, ajagraafikute (timing) ja interaktsiooniülevaate (interaction overview) diagrammid.
Iga diagramm teenib erinevat eesmärki: klassidiagramm kirjeldab staatilist mudelit, järjestusdiagramm näitab objektidevahelist sõnumivahetust ajaalas, use case aitab dokumenteerida süsteemi funktsionaalsust ärinõuete tasandil jne.
Tähtsamad mõisted ja laiendatavus
- Stereotüübid ja profiilid: UML-i saab kohandada profiilide abil (nt SysML süsteemide inseneriaks või MARTE reaalajaprojektide jaoks). Need lisavad domeenispetsiifilisi semantikaid ja tähistusi.
- Metamudel: UML on ise määratletud metatasemel (metamodel), mis võimaldab tööriistadel mõista ja valideerida UML-mudeleid.
- Staatused ja kehtestatud semantika: UMLi spetsiifikatsioon määratleb nii sümboolika (süntaks) kui ka osa semantikat, kuid praktiliselt jääb osa tõlgendustest ka tööriistade ja meeskondade otsustada.
Kus ja kuidas UML-i kasutatakse?
UML-i kasutatakse erinevates etappides ja kontekstides:
- nõuete modelleerimine (use case),
- arkitektuur ja süsteemidisain (komponent-, klassi- ja paigutusdiagrammid),
- käitumise kirjelduseks (järjestus-, tegevus- ja olekudiagrammid),
- tööriistade toel koodi genereerimiseks või mudelite ja koodi sünkroonimiseks (MDA lähenemised),
- dokumentatsiooni ja kommunikatsiooni vahendina arendajate, disainerite ja huvigruppide vahel.
Populaarsed UML-tööriistad ulatuvad graafilistest (nt Enterprise Architect, MagicDraw/Cameo, IBM Rational) kuni tekstipõhiste lahendusteni (nt PlantUML) — igaühel on erinev rõhuasetus diagrammide loomiseks, versioonihalduseks ja integratsiooniks arenduskeskkondadega.
Kriitika ja piirangud
UML on saanud ka kriitikat:
- keerukus ja ulatus — kogu standard on mahukas ning kõik funktsioonid ei ole praktilised igapäevases töös;
- õppimiskõver — algajatele võib notatsioon tunduda keeruline;
- ülemodelleerimise oht — liiga detailne modelleerimine võib raisata aega ja jääda kiiresti aegunuks, kui mudelid ei ole elusad ja sünkroonis koodiga;
- metoodiline ebajärjekindlus — erinevad meeskonnad ja tööriistad võivad sama päringut eri moodi tõlgendada, mis nõuab kokkuleppeid ja malli kasutust.
Praegused parimad praktikad rõhutavad lihtsust ja vajalikku täpsust: kasutada ainult neid diagramme ja detaile, mis toetavad otsustamist ja kommunikatsiooni, ning hoida mudelid ajakohastatuna või selgelt arhiveerituna.
Kokkuvõte
UML on võimas ja laialt defineeritud modelleerimiskeel, mille tugevuseks on standardiseeritud notatsioon ja lai diagrammide valik. Samas nõuab selle efektiivne kasutamine distsipliini: valida sobivad diagrammid, hoida mudelid lihtsad ja siduda need arendustööriistadega. Kuigi praktikas on kasutusmustrid ja populaarsus võivad erineda tööstusharude ja meeskondade lõikes (sh aruanded madalamast kasutusest teatud uuringutes 2013. aasta seisuga), jääb UML tihedalt seotud tarkvara- ja süsteemiinseneri praktikaga ning seda kasutatakse nii akadeemias kui ka tööstuses vastavalt vajadusele. [4]
Sisu
[peida]
- 1 Ajalugu
- 1.1 Enne UML 1.x
- 1.2 UML 1.x
- 1.3 UML 2.x
- 2 Disain
- 2.1 Tarkvara arendamise meetodid
- 2.2 Modelleerimine
- 3 diagrammid
- 3.1 Struktuuriskeemid
- 3.2 Käitumisdiagrammid
- 3.2.1 Koostöödiagrammid
- 4 Meta-modelleerimine
- 5 vastuvõtmine
- 6 kriitikat
- 6.1 UML 1.x kriitika
Ajalugu[muuta allikas | edit]
Objektorienteeritud meetodite ja notatsiooni ajalugu
UML on arenenud alates 1990ndate teisest poolest ja selle juured on 1980ndate lõpus ja 1990ndate alguses välja töötatud objektorienteeritud meetodites. Ajakirjas (vt joonis) on esitatud objektorienteeritud modelleerimismeetodite ja notatsiooni ajaloo tipphetked.
Algselt põhineb see Boochi meetodi, objektide modelleerimise tehnika (OMT) ja objektorienteeritud tarkvaratehnika (OOSE) notatsioonidel, mis on integreeritud ühte keelde. [5]
Enne UML 1.x[muuta allikas | edit]
Rational Software Corporation palkas 1994. aastal James Rumbaugh'i General Electricust ja pärast seda sai ettevõte kahe kõige populaarsema objektorienteeritud modelleerimisviisi allikaks:[6] Rumbaugh' objektide modelleerimise tehnika (OMT) ja Grady Boochi meetod. Peagi abistas neid nende püüdlustes Ivar Jacobson, objektipõhise tarkvaratehnika (OOSE) meetodi looja, kes liitus nendega 1995. aastal Rationalis. [1]
Nende kolme (Rumbaugh, Jacobson ja Booch) tehnilise juhtimise all moodustati 1996. aastal konsortsium nimega UML Partners, et viia lõpule ühtse modelleerimiskeele (UML) spetsifikatsioon ja esitada see Object Management Groupile (OMG) standardiseerimiseks. Partnerlusse kuulusid ka teised huvitatud isikud (näiteks HP, DEC, IBM ja Microsoft). UMLi partnerite UML 1.0 eelnõu esitas konsortsium 1997. aasta jaanuaris OMG-le. Sama kuu jooksul moodustasid UMLi partnerid grupi, mille eesmärk oli määratleda keelekonstruktsioonide täpne tähendus, mille eesistujaks oli Cris Kobryn ja haldajaks Ed Eykholt, et viia spetsifikatsioon lõpule ja integreerida see teiste standardiseerimispüüdlustega. Selle töö tulemus, UML 1.1, esitati OMG-le 1997. aasta augustis ja OMG võttis selle vastu 1997. aasta novembris. [1][7]
UML 1.x[muuta allikas | edit]
Pärast esimest versiooni moodustati[1] töögrupp keele parandamiseks, mis andis välja mitu väiksemat parandust, 1.3, 1.4 ja 1.5. [8]
Tema koostatud standardid (nagu ka algne standard) on täheldatud kui mitmetähenduslikud ja ebajärjekindlad. [9][10]
UML 2.x[muuta allikas | edit]
UML 2.0 suurversioon asendas 2005. aastal versiooni 1.5, mis töötati välja koos laienenud konsortsiumiga, et parandada keelt veelgi, et kajastada selle funktsioonide kasutamise uusi kogemusi. [11]
Kuigi UML 2.1 ei avaldatud kunagi ametliku spetsifikatsioonina, ilmusid 2007. aastal versioonid 2.1.1 ja 2.1.2, millele järgnes 2009. aasta veebruaris UML 2.2. UML 2.3 avaldati ametlikult 2010. aasta mais.[12] UML 2.4.1 avaldati ametlikult 2011. aasta augustis.[12] UML 2.5 ilmus 2012. aasta oktoobris "In process" versioonina ja ametlikult avaldati 2015. aasta juunis. [12]
UML 2.x spetsifikatsioonis on neli osa:
- Superstruktuur, mis määratleb diagrammide ja nende mudelielementide notatsiooni ja semantika.
- Infrastruktuur, mis määratleb tuumiku metamudeli, millel tugineb pealisehitus.
- Object Constraint Language (OCL) mudelielementide reeglite defineerimiseks.
- UML diagrammide vahetus, mis määratleb, kuidas UML 2 diagrammide skeeme vahetatakse.
Järgnevad nende standardite praegused versioonid: UML Superstructure versioon 2.4.1, UML Infrastructure versioon 2.4.1, OCL versioon 2.3.1 ja UML Diagram Interchange versioon 1.0.[13] Seda ajakohastab ja täiustab jätkuvalt läbivaatamise töörühm, kes lahendab kõik keelega seotud probleemid. [14]
Disain[muuta allikas | edit]
Unified Modeling Language (UML) pakub võimalust visualiseerida süsteemi arhitektuuriplaanid diagrammi kujul (vt. pilt), mis sisaldab selliseid elemente nagu: [5]
- Mis tahes tegevus (töökohad)
- Süsteemi üksikud komponendid
- Ja kuidas nad saavad suhelda teiste tarkvarakomponentidega.
- Kuidas süsteem töötab
- Kuidas üksused suhtlevad teistega (komponendid ja liidesed).
- Väline kasutajaliides
Kuigi algselt oli see mõeldud ainult objektorienteeritud projekteerimisdokumentatsiooni jaoks, on ühtset modelleerimiskeelt (UML) laiendatud, et hõlmata suuremat hulka projekteerimisdokumentatsiooni (nagu eespool loetletud), [15]ning see on osutunud kasulikuks paljudes kontekstides. [16]
Tarkvaraarendusmeetodid[muuta allikas | edit]
UML ei ole iseenesest arendusmeetod, [17]kuid see on loodud nii, et see ühilduks oma aja juhtivate objektorienteeritud tarkvaraarendusmeetoditega (näiteksOMT, Boochi meetod, Objectory) ja eriti RUP-ga, mille kasutamiseks see algselt mõeldud oli, kui töö algas Rational Software Inc. juures.
Modelleerimine[muuta allikas | edit]
Oluline on teha vahet UML-mudelil ja süsteemi diagrammide kogumil. Diagramm on süsteemi mudeli osaline graafiline esitus. Diagrammide kogum ei pea mudelit täielikult katma ja diagrammi kustutamine ei muuda mudelit. Mudel võib sisaldada ka dokumentatsiooni, mis juhib mudeli elemente ja skeeme (näiteks kirjalikud kasutusjuhtumid).
UML-diagrammid kujutavad süsteemi mudeli[18] kahte erinevat vaadet:
- Staatiline (või struktuuriline) vaade: rõhutab süsteemi staatilist struktuuri, kasutades objekte, atribuute, operatsioone ja seoseid. Struktuuriline vaade hõlmab klassidiagramme ja liitstruktuuridiagramme.
- Dünaamiline (või käitumuslik) vaade: rõhutab süsteemi dünaamilist käitumist, näidates objektidevahelist koostööd ja objektide sisemiste seisundite muutusi. See vaade hõlmab järjestusdiagramme, tegevusdiagramme ja olekumasinate skeeme.
UML-mudeleid saab vahetada UML-vahendite vahel, kasutades XML Metadata Interchange (XMI) andmevahetusformaati.
Diagrammid[muuta allikas | edit]
| UML diagrammid |
| Struktuursed UML diagrammid |
|
| Käitumuslikud UML-diagrammid |
|
UML 2-s on palju diagrammitüüpe, mis jagunevad kahte kategooriasse.[5] Mõned tüübid kujutavad struktuurilist teavet ja ülejäänud kujutavad üldisi käitumistüüpe, sealhulgas mõned, mis kujutavad koostoimete erinevaid aspekte. Need diagrammid võib liigitada hierarhiliselt, nagu on näidatud järgmisel klassidiagrammil: [5]
Kõik need diagrammid võivad sisaldada kommentaare või märkusi, mis selgitavad kasutamist, piiranguid või kavatsust.
Struktuuriskeemid[muuta allikas | edit]
Struktuurdiagrammid rõhutavad asju, mis peavad modelleeritavas süsteemis olemas olema. Kuna struktuuridiagrammid kujutavad struktuuri, kasutatakse neid laialdaselt tarkvarasüsteemide tarkvaraarhitektuuri dokumenteerimisel. Näiteks komponentdiagramm, mis kirjeldab, kuidas tarkvarasüsteem on jaotatud komponentideks ja näitab nende komponentide vahelisi sõltuvusi.
- Komponentdiagramm
- Klassidiagramm
Käitumisdiagrammid[muuta allikas | edit]
Käitumisdiagrammid rõhutavad, mis peab toimuma modelleeritavas süsteemis. Kuna käitumisdiagrammid illustreerivad süsteemi käitumist, kasutatakse neid laialdaselt tarkvarasüsteemide funktsionaalsuse kirjeldamiseks. Tegevusdiagramm kirjeldab näiteks süsteemi komponentide äritegevust ja tegevussammulisi tegevusi.
- Tegevuste diagramm
- Kasutusjuhtumi skeem
Koostöödiagrammid[muuta allikas | edit]
Interaktsioonidiagrammid, mis on käitumisdiagrammide alamhulk, rõhutavad modelleeritava süsteemi asjade vahelist kontrolli- ja andmevoolu. Näiteks järjestusdiagramm, mis näitab, kuidas objektid suhtlevad üksteisega sõnumite järjestuse kaudu.
- Järjestusdiagramm
- Kommunikatsiooniskeem
Meta-modelleerimine[muuta allikas | edit]
Peamine artikkel: Meta-objekti vahend
Meta-objekti süsteemi illustratsioon
Object Management Group (OMG) on välja töötanud metamodelleerimise arhitektuuri, et määratleda Unified Modeling Language (UML), mida nimetatakse Meta-Object Facility (MOF).[19] Meta-Objektikeskkond on kavandatud neljakihilise arhitektuurina, nagu on näidatud pildil paremal. Ülemisel kihil, mida nimetatakse M3-kihiks, on meta-meta-mudel. See M3-mudel on keel, mida Meta-Object Facility kasutab metamudelite, nn M2-mudelite loomiseks.
Kõige silmapaistvam näide 2. kihi metaobjektide mudeli kohta on UMLi metamudel, mudel, mis kirjeldab UMLi ennast. Need M2-mudelid kirjeldavad M1-kihi elemente ja seega M1-mudeleid. Need oleksid näiteks UML-is kirjutatud mudelid. Viimane kiht on M0-kiht ehk andmekiht. Seda kasutatakse süsteemi tööaegsete instantside kirjeldamiseks. [20]
Meta-mudelit saab laiendada, kasutades mehhanismi, mida nimetatakse stereotüpiseerimiseks. Brian Henderson-Sellers ja Cesar Gonzalez-Perez on seda kritiseerinud kui ebapiisavat/ebakõlbmatut dokumendis "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" (Stereotüüpide mehhanismi kasutamine ja kuritarvitamine UML 1.x ja 2.0). [21]
Vastuvõtmine[muuta allikas | edit]
UML on osutunud kasulikuks paljudes projekteerimise kontekstides, [16]nii et see on muutunud IT-kogukonnas peaaegu igapäevaseks. [22]
Seda on kohati käsitletud kui disaini hõbekuuli, mis on toonud kaasa probleeme selle kasutamisel. Selle väärkasutus hõlmab selle liigset kasutamist (projekteerida sellega iga väike osa süsteemi koodist, mis on ebavajalik) ja eeldust, et igaüks võib sellega midagi projekteerida (isegi need, kes ei ole programmeerinud). [23]
Seda peetakse suureks keeleks, milles on palju konstruktsioone. Mõned (sealhulgas Jacobson) leiavad, et neid on liiga palju ja et see takistab selle õppimist (ja seega ka kasutamist). [24]
Kriitika[muuta allikas | Edit]
| Selle artikli kriitika või vastuolude osa võib ohustada artikli neutraalset seisukohta antud teema suhtes. Palun integreerige selle osa sisu artiklisse tervikuna või kirjutage materjal ümber. (detsember 2010) |
Tööstuse poolt UMLi kohta esitatud kriitika hõlmab[4] järgmist:
- ei ole kasulik: "[ei] paku neile eeliseid võrreldes nende praeguste, väljakujunenud tavade ja esindustega"
- liiga keeruline, eriti klientidega suhtlemisel: "tarbetult keeruline" ja "Parim põhjus, miks UMLi ei tohiks kasutada, on see, et see ei ole "loetav" kõigile sidusrühmadele. Kui palju on UML väärt, kui ärikasutaja (klient) ei saa aru teie modelleerimise tulemusest?"
- vajadus hoida UML ja kood sünkroonis, nagu ka dokumentatsiooni puhul üldiselt
UML 1.x kriitika[muuta allikas | edit]
Kardinaalsuse märkimine
Nagu andmebaasi Chen, Bachmani ja ISO ER-diagrammide puhul, on klassimudelid määratud kasutama "look-across" kardinaalsusi, kuigi mitmed autorid (Merise, [25]Elmasri & Navathe[26] jt[27]) eelistavad rollide puhul sama külje või "look-here" ning nii minimaalse kui ka maksimaalseid kardinaalsusi. Hiljutised uurijad (Feinerer, [28]Dullea jt[29]) on näidanud, et UML- ja ER-diagrammides kasutatav "look-across" tehnika on vähem tõhus ja vähem sidus, kui seda rakendatakse n-araliste suhete puhul, mille järjestus on >2.
Feinerer ütleb: "Probleemid tekivad, kui me tegutseme UML-i assotsiatsioonide puhul kasutatava look-across semantika alusel. Hartmann [30]uurib seda olukorda ja näitab, kuidas ja miks erinevad teisendused ebaõnnestuvad." (Kuigi mainitud "reduktsioon" on võlts, sest kaks diagrammi 3.4 ja 3.5 on tegelikult samad) ja ka "Nagu me näeme järgmistel lehekülgedel, toob look-across tõlgendus kaasa mitmeid raskusi, mis takistavad lihtsate mehhanismide laiendamist binaarsetest assotsiatsioonidest n-aarsetele assotsiatsioonidele.""
Küsimused ja vastused
K: Mis on ühtne modelleerimiskeel (Unified Modeling Language, UML)?
V: Unified Modeling Language (UML) on tarkvaraarenduses kasutatav modelleerimiskeel, mis pakub standardset võimalust näidata, kuidas süsteemi disain välja näeb.
K: Mis oli UMLi algne eesmärk?
V: UMLi algne eesmärk oli standardiseerida erinevaid märkmesüsteeme ja lähenemisviise tarkvara projekteerimisele.
K: Kes töötas UMLi välja?
V: UMLi arendasid Grady Booch, Ivar Jacobson ja James Rumbaugh Rational Software'is aastatel 1994-1995, kusjuures nad juhtisid edasist arendamist 1996. aastal.
K: Millal võeti UML standardina vastu?
V: UML võeti standardina vastu 1997. aastal Object Management Groupi (OMG) poolt.
K: Kes juhib UMLi?
V: UMLi on alates selle vastuvõtmisest standardina 1997. aastal hallanud Object Management Group.
K: Kas UML-i tunnustati rahvusvahelise standardina?
V: Jah, Rahvusvaheline Standardiorganisatsioon (ISO) tunnustas UMLi 2005. aastal rahvusvahelise standardina.
K: Mis on UMLi eesmärk tarkvaratehnoloogias?
V: UMLi eesmärk tarkvaratehnikas on pakkuda standardset võimalust näidata, kuidas süsteemi disain välja näeb, et seda oleks lihtne mõista ja edastada arendajatele ja sidusrühmadele.
Otsige