UML diagramma

Saturs

 [hide] 

• 1 Vēsture
• 1.1 Pirms UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Dizains
• 2.1 Programmatūras izstrādes metodes
• 2.2 Modelēšana
• 3 diagrammas
• 3.1 Struktūras diagrammas
• 3.2 Uzvedības diagrammas
• 3.2.1 Mijiedarbības diagrammas
• 4 Meta modelēšana
• 5 Pieņemšana
• 6 Kritika
• 6.1 UML 1.x kritika

Vēsture[rediģēt avotu | rediģēt]

Objektorientēto metožu un apzīmējumu vēsture

UML ir attīstījusies kopš 90. gadu otrās puses, un tās saknes meklējamas objektorientētajās metodēs, kas tika izstrādātas 80. gadu beigās un 90. gadu sākumā. Laika līnijā (skat. attēlu) parādīti galvenie objektorientētās modelēšanas metožu un notācijas vēstures notikumi.

Tā sākotnēji ir balstīta uz Boocha metodes, objektu modelēšanas tehnikas (OMT) un objektorientētās programmatūras inženierijas (OOSE) notācijām, kas ir integrētas vienā valodā. ^[5]

Pirms UML 1.x[rediģēt avotu | rediģēt]

Rational Software Corporation 1994. gadā no General Electric pieņēma darbā Džeimsu Rumbo (James Rumbaugh), un pēc tam uzņēmums kļuva par divu populārāko objektorientētās modelēšanas pieeju avotu:^[6] Rumbaugh objektmodelēšanas metode (OMT) un Grady Booch metode. Drīz vien viņiem palīdzēja Ivars Jakobsons, objektorientētās programmatūras inženierijas (OOSE) metodes radītājs, kurš pievienojās Rational 1995. gadā. ^[1]

Šo trīs cilvēku (Rumbaugh, Jacobson un Booch) tehniskā vadībā 1996. gadā tika izveidots konsorcijs ar nosaukumu UML Partners, lai pabeigtu vienotās modelēšanas valodas (UML) specifikāciju un piedāvātu to Object Management Group (OMG) standartizācijai. Partnerībā bija arī citas ieinteresētās puses (piemēram, HP, DEC, IBM un Microsoft). Konsorcijs 1997. gada janvārī ierosināja OMG iesniegt UML partneru UML 1.0 projektu. Tajā pašā mēnesī UML partneri izveidoja grupu, kuras mērķis bija precīzi definēt valodas konstrukciju nozīmi un kuras priekšsēdētājs bija Cris Kobryn, bet administrators - Ed Eykholt, lai pabeigtu specifikācijas izstrādi un integrētu to ar citiem standartizācijas pasākumiem. Šī darba rezultāts - UML 1.1 - tika iesniegts OMG 1997. gada augustā, un OMG to pieņēma 1997. gada novembrī. ^[1][7]

UML 1.x[rediģēt avotu | rediģēt]

Pēc pirmās versijas tika izveidota^[1] darba grupa valodas uzlabošanai, kas izdeva vairākas nelielas versijas - 1.3, 1.4 un 1.5. ^[8]

Tā izstrādātie standarti (kā arī sākotnējais standarts) ir novērtēti kā neskaidri un nekonsekventi. ^[9][10]

UML 2.x[rediģēt avotu | rediģēt]

UML 2.0 galvenā redakcija 2005. gadā aizstāja 1.5 versiju, kas tika izstrādāta ar paplašinātu konsorciju, lai turpinātu uzlabot valodu un atspoguļotu jauno pieredzi tās funkciju izmantošanā. ^[11]

Lai gan UML 2.1 nekad netika izdota kā oficiāla specifikācija, 2007. gadā parādījās 2.1.1 un 2.1.2 versija, bet 2009. gada februārī - UML 2.2. UML 2.3 tika oficiāli izdota 2010. gada maijā.^[12] UML 2.4.1 tika oficiāli izdota 2011. gada augustā.^[12] UML 2.5 tika izdota 2012. gada oktobrī kā "In process" versija un oficiāli tika izdota 2015. gada jūnijā. ^[12]

UML 2.x specifikācijā ir četras daļas:

1. Virsbūve, kas nosaka diagrammu un to modeļa elementu notāciju un semantiku.
2. Infrastruktūra, kas definē metamodeļa kodolu, uz kura balstās virsbūve.
3. Objektu ierobežojumu valoda (OCL) modeļa elementu noteikumu definēšanai
4. UML diagrammu apmaiņa, kas nosaka, kā notiek apmaiņa ar UML 2 diagrammu izkārtojumiem.

Šo standartu pašreizējās versijas ir šādas: UML virsbūves versija 2.4.1, UML infrastruktūras versija 2.4.1, OCL versija 2.3.1 un UML diagrammu apmaiņas versija 1.0.^[13] To turpina atjaunināt un uzlabot pārskatīšanas darba grupa, kas risina visas ar valodu saistītās problēmas. ^[14]

Dizains[rediģēt avotu | rediģēt]

Vienotā modelēšanas valoda (UML) piedāvā veidu, kā vizualizēt sistēmas arhitektūras plānus diagrammā (sk. attēlu), ietverot tādus elementus kā: ^[5]

• Jebkuras darbības (darbavietas)
• Atsevišķas sistēmas sastāvdaļas
• Un kā tās var mijiedarboties ar citām programmatūras sastāvdaļām.
• Sistēmas darbība
• Vienību mijiedarbība ar citām vienībām (komponenti un saskarnes).
• Ārējā lietotāja saskarne

Lai gan sākotnēji tā bija paredzēta tikai objektorientētajai projektēšanas dokumentācijai, vienotā modelēšanas valoda (UML) ir paplašināta, lai aptvertu plašāku projektēšanas dokumentācijas kopumu (kā minēts iepriekš), ^[15]un ir atzīta par noderīgu daudzos kontekstos. ^[16]

Programmatūras izstrādes metodes[rediģēt avotu | rediģēt]

UML pati par sevi nav izstrādes metode, ^[17]tomēr tā tika izstrādāta tā, lai būtu saderīga ar tā laika vadošajām objektorientētās programmatūras izstrādes metodēm (piemēram,OMT, Booch metodi, Objectory) un jo īpaši ar RUP, ko sākotnēji bija paredzēts izmantot, kad darbu sāka Rational Software Inc.

Modelēšana[rediģēt avotu | rediģēt]

Ir svarīgi nošķirt UML modeli no sistēmas diagrammu kopuma. Diagramma ir sistēmas modeļa daļējs grafisks attēlojums. Diagrammu kopumam nav pilnībā jāaptver modelis, un diagrammas dzēšana nemaina modeli. Modelis var saturēt arī dokumentāciju, kas nosaka modeļa elementus un diagrammas (piemēram, rakstiskus lietojuma gadījumus).

UML diagrammas attēlo divus dažādus sistēmas modeļa^[18] skatījumus:

• Statiskais (vai strukturālais) skatījums: uzsver sistēmas statisko struktūru, izmantojot objektus, atribūtus, operācijas un attiecības. Strukturālais skats ietver klašu diagrammasun saliktās struktūras diagrammas.
• Dinamiskais (vai uzvedības) skats: uzsver sistēmas dinamisko uzvedību, parādot sadarbību starp objektiem un izmaiņas objektu iekšējos stāvokļos. Šis skats ietver secības diagrammas, darbību diagrammas un stāvokļu mašīnu diagrammas.

UML modeļus var apmainīties starp UML rīkiem, izmantojot XML metadatu apmaiņas formātu (XMI).

Diagrammas[rediģēt avotu | rediģēt]

UML 2 ir daudz diagrammu veidu, kas iedalīti divās kategorijās.^[5] Daži tipi attēlo strukturālo informāciju, bet pārējie - vispārīgus uzvedības tipus, tostarp dažus, kas attēlo dažādus mijiedarbības aspektus. Šīs diagrammas var hierarhiski iedalīt kategorijās, kā parādīts šajā klašu diagrammā: ^[5]

Visās šajās diagrammās var būt komentāri vai piezīmes, kas paskaidro lietojumu, ierobežojumus vai nolūku.

Struktūrshēmas[rediģēt avotu | rediģēt]

Struktūras diagrammās ir uzsvērtas tās lietas, kurām ir jābūt modelējamā sistēmā. Tā kā struktūras diagrammas attēlo struktūru, tās plaši izmanto programmatūras sistēmu arhitektūras dokumentēšanā. Piemēram, komponentu diagramma, kas apraksta, kā programmatūras sistēma ir sadalīta komponentēs, un parāda atkarības starp šīm komponentēm.

• Sastāvdaļu diagramma
• Klases diagramma

Uzvedības diagrammas[rediģēt avotu | rediģēt]

Uzvedības diagrammās ir uzsvērts, kam jānotiek modelētajā sistēmā. Tā kā uzvedības diagrammas ilustrē sistēmas uzvedību, tās tiek plaši izmantotas, lai aprakstītu programmatūras sistēmu funkcionalitāti. Piemēram, darbību diagramma apraksta sistēmas komponentu darbības un operatīvās darbības soli pa solim.

• Darbību diagramma
• Lietošanas gadījumu diagramma

Mijiedarbības diagrammas[rediģēt avotu | rediģēt]

Mijiedarbības diagrammās, kas ir uzvedības diagrammu apakškopa, uzsvērta vadības un datu plūsma starp modelējamās sistēmas elementiem. Piemēram, secības diagramma, kas parāda, kā objekti sazinās viens ar otru, izmantojot ziņojumu secību.

• Secības diagramma
• Komunikācijas diagramma

Meta modelēšana[rediģēt avotu | rediģēt]

Galvenais raksts: Metaobjektu mehānisms

Metaobjekta rīka ilustrācija

Object Management Group (OMG) ir izstrādājusi metamodelēšanas arhitektūru, lai definētu vienoto modelēšanas valodu (UML), ko sauc par metaobjektu iespēju (MOF).^[19] Metaobjektu mehānisms ir veidots kā četru līmeņu arhitektūra, kā parādīts attēlā pa labi. Tā nodrošina meta-meta modeli augšējā slānī, ko sauc par M3 slāni. Šis M3-modelis ir valoda, ko Meta-Object Facility izmanto, lai veidotu metamodeļus, ko sauc par M2-modeļiem.

Visredzamākais 2. līmeņa metaobjektu struktūras modeļa piemērs ir UML metamodelis - modelis, kas apraksta pašu UML. Šie M2 modeļi apraksta M1 slāņa elementus, tātad M1 modeļus. Tie būtu, piemēram, UML rakstīti modeļi. Pēdējais slānis ir M0-slānis jeb datu slānis. To izmanto, lai aprakstītu sistēmas izpildes laika gadījumus. ^[20]

Metamodeli var paplašināt, izmantojot mehānismu, ko sauc par stereotipizāciju. Brian Henderson-Sellers un Cesar Gonzalez-Perez rakstā "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" ("Stereotipu mehānisma lietojums un ļaunprātīga izmantošana UML 1.x un 2.0") to kritizē kā nepietiekamu/nepiemērotu. ^[21]

Pieņemšana[rediģēt avotu | rediģēt]

UML ir atzīts par noderīgu daudzos projektēšanas kontekstos, un tas ir kļuvis ^[16]tik ļoti noderīgs, ka IT nozarē ir kļuvis gandrīz par universālu līdzekli. ^[22]

Reizēm tas ir uzskatīts par dizaina "sudraba lodi", kas ir radījis problēmas tā izmantošanā. Nepareiza tās izmantošana ietver pārmērīgu tās izmantošanu (projektēt ar to katru mazāko sistēmas koda daļu, kas nav nepieciešams) un pieņēmumu, ka ikviens var projektēt jebko ar to (pat tie, kas nav programmējuši). ^[23]

Tiek uzskatīts, ka tā ir plaša valoda ar daudzām konstrukcijām. Daži (tostarp Jakobsons) uzskata, ka to ir pārāk daudz un ka tas traucē tās apguvi (un līdz ar to arī lietošanu). ^[24]

Kritika[rediģēt avotu | rediģēt]

Nozares^[4] pārstāvji bieži kritizē UML:

• nav lietderīgi: "[nepiedāvā] viņiem priekšrocības salīdzinājumā ar viņu pašreizējo, attīstīto praksi un pārstāvniecību".
• pārāk sarežģīta, jo īpaši saziņai ar klientiem: "Labākais iemesls, kāpēc neizmantot UML, ir tas, ka tas nav "lasāms" visām ieinteresētajām personām. Cik vērts ir UML, ja biznesa lietotājs (klients) nesaprot jūsu modelēšanas darba rezultātu?".
• nepieciešams sinhronizēt UML un kodu, tāpat kā ar dokumentāciju kopumā.

UML 1.x kritika[rediģēt avotu | rediģēt]

Kardinalitātes apzīmējums

Tāpat kā datubāzes Chen, Bachman un ISO ER diagrammās, klašu modeļos ir norādīts izmantot "look-across" kardinalitātes, lai gan vairāki autori (Merise, ^[25]Elmasri & Navathe^[26] u.c^[27].) dod priekšroku vienas puses vai "look-here" lomām un gan minimālajām, gan maksimālajām kardinalitātēm. Nesenie pētnieki (Feinerer, ^[28]Dullea u. c^[29].) ir pierādījuši, ka UML un ER diagrammās izmantotā "look-across" metode ir mazāk efektīva un mazāk saskaņota, ja to piemēro n-ārām attiecībām ar kārtu > 2.

Feinerers saka: "Problēmas rodas, ja mēs darbojamies saskaņā ar UML asociāciju semantiku. Hartmanis^[30] pēta šo situāciju un parāda, kā un kāpēc dažādas transformācijas neizdodas." (Lai gan minētais "samazinājums" ir nepatiess, jo abas 3.4. un 3.5. diagrammas patiesībā ir vienādas) un arī "Kā redzēsim nākamajās lappusēs, "look-across" interpretācija rada vairākas grūtības, kas neļauj paplašināt vienkāršus mehānismus no binārajām uz n-ārajām asociācijām.".