“我们的价值观”宣传提示牌 扮靓灵源山人行栈道

百度 加拿大皇家学院院士、加拿大沙省大学终身荣誉教授李胜生的演讲是“‘云横秦岭家何在’：海外华人人口变迁”。

ühtne modelleerimiskeel, lühendina UML, ka unifitseeritud modelleerimiskeel, UML-keel, ühtne mudelikeel, ühtne visualiseerimiskeel (inglise keeles Unified Modeling Language ehk UML) on üldotstarbeline noteeringukeel keerulise tarkvara, peamiselt suurte objektorienteeritud projektide spetsifitseerimiseks ja visualiseerimiseks. UML p?hineb sellistel vanematel noteeringumeetoditel nagu Booch, OMT ja OOSE.

Struktuuriskeemid

Struktuuriskeemidega saab iseloomustada süsteemi struktuurset ülesehitust. Kuid lisaks tarkvarale on olemas vahendid ka riistvara ja tarkvara seostamiseks.

UML struktuuriskeemid

Struktuuriskeemid struktuurimudelite koostamiseks:

• klassiskeem (class diagram)
• komponendiskeem (component diagram)
• liitstruktuuriskeem (composite structure diagram)
• evitusskeem (deployment diagram)
• objektiskeem (object diagram)
• paketiskeem (package diagram)

Klassiskeemid

Klassiskeemid (class diagram) moodustavad keskse osa OO meetodite puhul, sest klasside kasutamine on OO meetodite aluseks. Klassiskeem kuulub staatiliste skeemide hulka. Klassiskeem kirjeldab objektide tüüpe süsteemis ja staatilisi seoseid nende vahel. Samuti n?itab klassi omadusi e atribuute, klassi operatsioone ja piiranguid objektide vahelistele seostele. Klassi omaduste ja operatsioonide ühisnimetajaks on UML-is ?feature“, mida on t?lgitud kui erisus.

Klassiskeemi k?ige olulisemad osad on klassid ja nende vahelised seosed, siis v?ib ?elda nii, et klassid ja objektid kirjeldavad süsteemi elemente ja seosed kommunikatsiooni ehk suhtlemist. Klasside kasutamine keeruliste süsteemide kirjeldamisel on tegelikult vana nipp, mida inimkond juba tuhandeid aastaid kasutanud on.

Klassid ja objektid

Objektid eksisteerivad reaalses maailmas (v?i arusaamises maailmast). Objekt saab olla osa üksk?ik millisest süsteemist. Objektid tarkvarasüsteemis muutuvad teoreetiliseks, neid saab moodustada tegelike objektide omadusi ja k?itumist analüüsides. Objektides peegeldub inimese arusaamine maailmast. Klass kirjeldab objekti tüübi omadusi ja k?itumist. Tarkvarasüsteem loob klassist objektide eksemplarid ehk isendid. Objekti ja klassi vahel on sarnane seos nagu muutuja ja andmetüübi vahel.

Süsteemi mudelid ja vaated

Klassiskeeme joonistatakse kogu analüüsi ja kavandamise jooksul ja neid joonistatakse erinevatel tasemetel. Erinevad mudelid, mida klassiskeemi abil joonistatakse on: Kontseptuaalne e. m?istemudel – skeemil kasutatakse uuritava valdkonna m?isteid. Sellel skeemi n?idatakse seoseid, mis kehtivad elus. Ehkki need m?isted v?ivad vastata ka hilisemale realisatsioonile, ei pruugi nad alati üksüheses vastavuses olla. M?istevaade tuleb joonistada ilma m?tlemata samal ajal realisatsioonile ja kindlasti programmeerimiskeelest s?ltumatult. Mudel on vajalik valdkonnast arusaamiseks. M?istemudel peaks samal ajal ka kliendile arusaadav olema. See ei pea olema süsteemi t?pne mudel, rohkem see, kuidas tegelikust süsteemist aru saadakse. Olenevalt arendusmetoodikast sobib seda nimetada ka valdkonnamudeliks (domain model). Spetsifikatsioonimudel – sellel mudelil peetakse silmas tarkvara liidest, vaadatakse tüüpe, mitte objekte. Aluseks on OO poolt tehtav range eristus objekti liidesele (see, mille kaudu saab objekti kasutada, mida n?evad teised objektid) ja realisatsioonile. Klassi tüüp on tegelikult kui liides, millel v?ivad olla erinevad realisatsioonid s?ltuvalt keskkonnast, vajalikust j?udlusest, programmeerijast, jne. OO-keeled seovad liidese ja realisatsiooni ja seep?rast vahe nende vahel j??bki teinekord m?rkamata. Realisatsioonimudel – p?hineb realisatsioonile ja seda vaadet kasutatakse k?ige enam. Siin on juba t?esti klassid ja keskendutakse sellele, kuidas klassid realiseerida. Realisatsioonimudelist v?ib olla lootust ka mingit koodi genereerida (eesm?rk – teha seda v?imalikult p?hjalikult). Klasside skeleti genereerimisega saavad juba t?nased CASE-vahendid t?iesti edukalt hakkama. Kui klassiskeemi joonistatakse, peab kogu skeemi ulatuses kasutusel olema sama vaatenurk, st mudelil peavad k?ik klassid olema samal tasemel. Valdkonnamudelile ei tohi sattuda realisatsiooni detailid. Vastasel juhul ei ole mudelit v?imalik ?igesti t?lgendada. Vaated ei kuulu UML-i alla, sest tegemist on juba kasutusmeetodiga ja mitte skeemi endaga. Skeemi joonistades on oluline vahet teha, millisel vaatel ta p?hineb. ühel arendusetapil joonistatakse üks vaade ja teisel etapil teine vaade. Milleks klassiskeemid? Klassiskeemid on alati kasulikud, kui on tegemist OO-ga. Hea, kui saab piirduda kirjeldatud v?imalustega ja ei pea kasutama nn edasij?udnute arsenali. Kes sellest teada tahab, uurigu ise kirjandusest edasi. Igal juhul ei ole vaja kogu klassiskeemi rikkust ühele konkreetsele skeemile paigutada. Olulisemad osad on seega: klassid, sidemed, atribuudid, üldistus, piirangud. Skeem tuleb joonistada konkreetsest vaatest l?htudes: Olles analüüsietapil, joonistatakse m?istevaade ja valdkonnavaade. Sellest tuleb igasugune realisatsioon eemal hoida. Olles projekteerimise juurde j?udnud, joonistatakse spetsifikatsiooni vaade. Realisatsioonivaade j?etakse vahel hoopis tegemata v?i tehakse ainult mingite osade jaoks. Parem v?hem ?igeid skeeme, kui hunnik vananenud skeeme kogu süsteemi kohta.

Komponendiskeem

UML1 tegi suuremat vahet skeemil. Vastavalt UML2-le n?eb komponendiskeem v?lja sarnane klassiskeemile. Eristamaks klassidest, saab kasutada v?ikest komponendiikooni klassi kasti sees v?i kasutada stereotüüpi <<component>>. Skeemil pole midagi uut. Komponente ühendatakse liideste kaudu, kasutatakse kuuli ja pesaga t?histust. Komponendid kui tarkvarasüsteemi osad peavad olema s?ltumatult ostetavad ja v?rskendatavad seega jaotamine komponentideks on sama palju turu otsus (mida tasub osta/müüa) kui tehniline otsus.

Liitstruktuuriskeem

Uus skeem UML2-s. V?imalus jaotada klass hierarhiliselt oma seesmise struktuuri j?rgi. V?ib v?tta keerulise objekti ja jagada ta osadeks. N?idatakse klassi seesmist struktuuri ja millised osad vajavad ja pakuvad milliseid liideseid. Selleks kasutatakse juba tuttavat pall ja pesa-esitust. Klassi kasti sisse joonistatakse j?rgmised kastid, mis t?histavad osi. Klassi liidesed (pakutavad ja vajatavad) saab ühendada vastavate osade külge. Neist osa puhul kasutatakse ka mitmesuse n?itamise v?imalust. Asjatundjad arvavad, et need on v?ga vajalikud, kuid esialgu esitatavad kirjeldused on v?ga lakoonilised.

Evitusskeem

Evitusskeem n?itab füüsilisi seoseid tarkvara ja riistvara komponentide vahel. Sellega saab n?idata, kuidas kogu tarkvara m??da hajussüsteemi laiali paisatud on. N?itab kogu süsteemi topoloogiat – millised on seadmed, t??tavad keskkonnad ja tehised, mis on selles arhitektuuris. Saab vaadata igasse s?lme ja n?ha, mis selles s?lmes paikneb.

Komponendid

S?lm (node) – tükike riistvara, alates lisaseadmest ja l?petades suurarvutiga. Sellel saab paikneda tehis. S?lmel saavad olla alams?lmed (subnodes), mis v?ivad olla t??tavad keskkonnad. S?lm v?ib olla nii tüüp (nt teatud tüüpi protsessoriga arvuti) kui ka isend (üks konkreetne arvuti). Konkreetsete omaduste kirjeldamiseks on s?lmel atribuudid. Teinekord v?ib osutuda vajalikuks n?iteks arvuti konfiguratsiooni kirjeldamine – sellel skeemil saab ka seda teha. S?lme iseloomustamiseks v?ib kasutada stereotüüpe <<device>> ja <<execution environment>>. Seega s?lm v?ib olla ühelt poolt konkreetne seade ja teiselt poolt k?ituskeskkond (operatsioonisüsteem, andmebaasisüsteem jms) S?lme juures v?ib n?idata tema kohta igasuguseid omadusi: tootja, opsüsteem, vastavat tüüpi s?lmede arv. Viimase jaoks ei ole erit?histust ette n?htud. Seosed s?lmede vahel (connection) – millised on suhtlusteed, mida m??da süsteemis info liigub. See n?itab, et s?lmed suhtlevad üksteisega, saates üksteisele objekte v?i s?numeid. V?ib lisada stereotüübi, mis n?itab, millise protokolli abil suheldakse, nt <<TCP/IP>>. Tehised (artifacts) – Tehised saavad olla m??da s?lmi laiali paisatud. Nad kirjutatakse s?lmede sisse. Pikemate kirjelduste jaoks v?ib kasutada eraldiseisvat <<deployment spec>>-i. St pikemat kirjeldust ei ole m?istlik skeemile lisada ja spetsifikatsiooni v?ib eraldi lugeda.

Objektiskeem

Objektskeem on teatud tüüpi klassiskeem. Objekt esitab klassi olekut teatud ajahetkel süsteemi t?? k?igus. Objektiskeem esitab süsteemi erinevate klasside olekuid ning nendevahelisis relatsioone v?i assotsiatsioone teatud ajahetkel.

Paketiskeem

Pakett on konstruktsioon, mille abil saab v?tta suvalise UML-i konstruktsiooni ja grupeerida tema elemendid üldisemal tasemel. Paketiskeemiga n?idatakse tavaliselt klasside kogumeid (pakette) ja s?ltuvusi nende vahel. Kuid paketti on v?imalik kasutada ka teiste UML-i osade juures. Idee poolest saab iga klass UML-mudelis kuuluda vaid ühte paketti, kuid pakett v?ib kuuluda j?rgmisesse paketti. Tekib hierarhiline struktuur ja ühes paketis v?ivad olla koos teised paketid ja üksikud klassid. Programmeerimiskeeltes tagatakse v?imalus programmi jagada füüsiliselt erinevatesse failidesse. S?ltuvalt keelest kutsutakse seda konstruktsiooni erinevalt. M?nel puhul ka paketiks. Iga pakett on eraldi nimeruum (namespace), st klassidel ühes paketis peavad olema unikaalsed nimed. Sama nimega erinevad klassid v?ivad aga kuuluda erinevatesse pakettidesse. Iga nimi peab kuuluma mingisse nimeruumi. Kui on vaja üheselt n?idata, kuhu paketti nimi kuulub, kasutatakse pikka nime (fully qualified name), iga osa vahel on koolonid.

Skeemi komponendid

Paketid (package) – ristkülikud, kus on kirjas ainult paketi nimi v?i ka temas sisalduvad klassid ja/v?i teised paketid. Viimased v?ivad olla v?lja joonistatud v?i ainult nimekirjana. Klassid v?ivad paketis olla public v?i private. Paketi liides tuleb teha v?imalikult v?ike ja eksportida vaid nende avalike klasside need meetodid, mida vaja on. Kuidas valida, millised klassid ühte paketti kokku panna? üheks soovituseks on j?rgmised kaks printsiipi:

• ühise sulundi printsiip (Common Closure Principe): pane kokku klassid, mida tuleb muuta samadel p?hjustel.
• ühise taaskasutuse printsiip (Common Reuse Principe): ühes paketis olevaid klasse tuleks koos korduvkasutada.

Kuid mitmed p?hjused on seotud ka klasside vaheliste s?ltuvustega.

S?ltuvus (dependency) on seos kahe mudelielemendi vahel, kus muudatus ühes (s?ltumatus) mudelielemendis m?jutab teist (temast s?ltuvat) mudelielementi. S?ltuvust kujutatakse katkendnoolena kahe paketi vahel. S?ltuvus v?ib eksisteerida ka kahe klassi vahel, kui ühe klassi kirjelduse muutmine v?ib p?hjustada muudatusi teises klassis. S?ltuvust saab p?hjustada see, kui:

• üks klass saadab teisele klassile teate;
• üks klass kuulub teise klassi andmete hulka;
• ühe klassi jaoks on teine klass m?ne meetodi parameetriks.

S?ltuvus on alati suunatud ja ei ole transitiivne, st kui klass1 s?ltub klass2st, siis automaatselt klass2 ei s?ltu klass1st. Reaalselt v?ib ka vastassuunas s?ltuvus tekkida, kuid siis on tegemist t?siste disaini probleemidega. Heaks tavaks on süsteemi ülesehitamisel tema kasutajaliidese ja sisu eraldamine. Tavaliselt on s?ltuvus sel juhul suunatud kasutajaliideselt sisu poole, st kui muutub t??tava süsteemi sisu, tuleb muuta ka kasutajaliidest, kuid kasutajaliidese muutmine ei tohiks p?hjustada süsteemi muutmist.

Pakettide vahel on samuti s?ltuvused. Esituspaketi ja valdkonnapaketi vahel on s?ltuvus siis, kui üksk?ik millisel klassil esituspaketis on s?ltuvus üksk?ik millisest klassist valdkonna paketis.

V?lislingid

Ingliskeelsed allikad

• Unified Modeling Language? (UML?) Resource Page (UML-i ametlik standard)
• UML diagrammide n?ited
• UML-i rakendused Enterprise Architect'i n?itel Sparx Systems'i kodulehel

Eestikeelsed allikad

• vallaste.ee
• UML, e-ope.ee
• Standardip?hine tarkvaratehnika s?nastik STATS. UML-i terminid eesti ja inglise keeles
• Liina Lang. UML-i ?ppematerjal. Bakalaureuset??. Tallinna Pedagoogikaülikool, Matemaatika-loodusteaduskond, Informaatika osakond. Juhendaja Juhan Ernits. Tallinn 2003