Vienotā modelēšanas valoda (UML): definīcija, vēsture un diagrammas
Uzzini UML: definīciju, vēsturi un svarīgākās diagrammas — praktisks ceļvedis programmatūras modelēšanai, standarts un piemēri efektīvai sistēmdizaina vizualizācijai.
Vienotā modelēšanas valoda (UML) ir vispārējas nozīmes, attīstības modelēšanas valoda programmatūras inženierijas jomā, kuras mērķis ir nodrošināt standarta veidu, kā vizualizēt sistēmas dizainu. [1]
Sākotnēji UML motivācija bija vēlme standartizēt atšķirīgās notācijas sistēmas un programmatūras projektēšanas pieejas, ko 1994.-1995. gadā izstrādāja Grady Booch, Ivar Jacobson un James Rumbaugh uzņēmumā Rational Software, un 1996. gadā viņi turpināja to attīstīt. [1]
1997. gadā UML kā standartu pieņēma Object Management Group (OMG), un kopš tā laika to pārvalda šī organizācija. Vienoto modelēšanas valodu 2005. gadā publicēja arī Starptautiskā standartizācijas organizācija (ISO) kā apstiprinātu ISO standartu.[2] Kopš tā laika tas ir periodiski pārskatīts, lai aptvertu jaunāko UML redakciju. [3]
Lai gan UML ir labi pazīstama un plaši izmantota izglītībā un akadēmiskajos darbos, no 2013. gada UML ir maz izmantota rūpniecībā, un vairums šādu lietojumu ir neoficiāli un ad hoc. [4]
Kas ir UML un kāpēc to lieto
UML ir notāciju kopums, kas ļauj attēlot gan sistēmas struktūru, gan tās uzvedību dažādos līmeņos — no augsta līmeņa biznesa procesa modeļa līdz detalizētam programmatūras komponentu aprakstam. UML nav programmēšanas valoda; tā ir modelēšanas valoda, kuru izmanto, lai komunicētu idejas starp arhitektiem, izstrādātājiem, analītiķiem un citām iesaistītajām pusēm. Modeļi var tikt izmantoti dokumentācijai, arhitektūras pārskatiem, prasību verifikācijai, kā arī kā bāze automatizētai koda ģenerēšanai vai testu izveidei.
UML veidi un diagrammu klasifikācija
UML ietver daudzveidīgu diagrammu kopu, kuras parasti iedala trīs pamatgrupās: struktūras diagrammas, uzvedības (behavior) diagrammas un interakciju (interaction) diagrammas. Biežāk izmantotās diagrammas ir:
- Klasu diagramma (Class diagram) — attēlo klases, to atribūtus, metodes un attiecības (asociācijas, generalizāciju, atkarības). Izmanto, lai modelētu statisko sistēmas struktūru.
- Objektu diagramma (Object diagram) — rāda klases instanci (objektu) stāvokli konkrētā brīdī.
- Use case (lietotāja gadījumu) diagramma — ilustrē sistēmas funkcionalitāti no lietotāja perspektīvas, attēlojot aktierus un lietotāja gadījumus.
- Secību diagramma (Sequence diagram) — attēlo objektu mijiedarbību laika secībā, piemēram, metožu izsaukumus un atbildes.
- Kopmünikācijas/Komunikācijas diagramma (Communication/Collaboration) — koncentrējas uz objektiem un to ziņojumu apmaiņu bez īpaša uzsvara uz laiku.
- Stāvokļu diagramma (State machine diagram) — modelē objektu stāvokļus un pārejas starp tiem (stāvokļu automāti).
- Aktivitāšu diagramma (Activity diagram) — attēlo darba plūsmas un loģiku (bieži izmantota biznesa procesu modelēšanai).
- Komponentu diagramma (Component diagram) — rāda programmatūras moduļus (komponentus) un to atkarības.
- Izvietojuma diagramma (Deployment diagram) — attēlo fizisko izvietojumu (serveri, ierīces, konteineri) un uz tiem izvietotās programmatūras daļas.
- Kompozīcijas struktūras diagramma (Composite structure), Laika diagramma (Timing) un Interakciju pārskata diagramma (Interaction overview) — specifiskākas diagrammas sarežģītām vajadzībām.
Galvenie UML jēdzieni
Daži pamata notācijas elementi, kurus bieži sastop UML modeļos:
- aktieri, kas pārstāv lomas ārpus sistēmas;
- klases un interfeisi, kas apraksta struktūru;
- asociācijas, atkarības, agregācijas un kompozīcijas attiecības;
- metodes (operācijas) un atribūti (dati);
- dzīves līnijas, ziņojumi un paziņojumi secību diagrammās;
- stāvokļi, pārejas, notikumi un darbības stāvokļu diagrammās.
Standarti, versijas un paplašinājumi
UML ir definēta ar formālām gramatikām un notācijas noteikumiem, un OMG regulāri izdevusi jaunas UML versijas (piem., UML 1.x -> UML 2.x). UML ir paplašināma ar profiliem, kas ļauj pieskaņot notāciju specifiskām jomām — pazīstamākie profili ir SysML (sistēmu inženierijai) un MARTE (iejūtīgām un reāllaika sistēmām). OMG arī veicināja Model-Driven Architecture (MDA) pieeju, kurā modeļi un transformācijas tiek izmantotas kā programmēšanas procesa pamats.
Rīki un prakse
Pastāv daudzi UML modelēšanas rīki, gan komerciāli, gan atvērtā koda, piemēram, IBM Rational Rose/Software Architect/Product Family, Sparx Systems Enterprise Architect, MagicDraw (tagad Cameo), ArgoUML, Papyrus u.c. Rīku iespējas var ietvert vizuālu rediģēšanu, tikšanos ar versiju kontroli, koda ģenerēšanu, atpakaļejošu inženieriju un integrāciju ar citām izstrādes vides daļām.
Stiprās un vājās puses
Stiprās puses:
- nodrošina vienotu notāciju komunikācijai starp iesaistītajām pusēm;
- atbalsta gan abstraktu, gan detalizētu modelēšanu;
- ļauj dokumentēt arhitektūru un dizainu, kā arī veicināt atkārtotu izmantojumu;
- vieglāk integrējama ar modelēšanas un automatizācijas pieejām (MDA).
Vājās puses:
- pilna UML apgūšana var būt sarežģīta un laikietilpīga;
- dažkārt modeļi tiek novesti novecojuši, ja nav procesā iekļautas modeļu uzturēšanas prakses;
- kritiķi norāda, ka UML var būt pārāk smagnēja vai birokrātiska, it īpaši ātro (agile) izstrādes vidi izmantotās komandās;
- komerciālie pielietojumi pēc 2013. gada ir samazinājušies, un daudzi izstrādātāji izmanto vieglākas vai pielāgotas notācijas.
Kā lietot UML praksē — ieteikumi
- izvēlieties tikai vajadzīgās diagrammas un vienkāršojiet notāciju, lai modeļi būtu saprotami;
- uzturiet modeļus sinhronā ar koda bāzi vai iekļaujiet modeļu pārskatīšanu izstrādes ciklā;
- izmantojiet UML profilus vai pielāgotas notācijas, ja tas palīdz skaidrāk attēlot domēnu jautājumus;
- integrējiet modeļus ar dokumentāciju, testiem un prasību pārvaldību, lai palielinātu to praktisko vērtību.
Nobeigums
UML paliek svarīgs līdzeklis sistēmu modelēšanā un izglītībā, piedāvājot bagātīgu notāciju kopu, kas aptver gan statisko, gan dinamisko sistēmu aspektu aprakstu. Lai gan tās izmantošana rūpniecībā ir mainījusies un vietām samazinājusies, UML joprojām sniedz vērtīgas koncepcijas un rīkus sistēmdizainā, it īpaši, ja to izmanto saprātīgi un pielāgo izstrādes komandas vajadzībām.
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:
- Virsbūve, kas nosaka diagrammu un to modeļa elementu notāciju un semantiku.
- Infrastruktūra, kas definē metamodeļa kodolu, uz kura balstās virsbūve.
- Objektu ierobežojumu valoda (OCL) modeļa elementu noteikumu definēšanai
- 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 diagrammas |
| Strukturālās UML diagrammas |
|
| Uzvedības UML diagrammas |
|
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]
| Šī raksta sadaļa "Kritika vai strīds" var apdraudēt neitrālo viedokli par šo tēmu. Lūdzu, iekļaujiet šīs sadaļas saturu rakstā kopumā vai pārrakstiet materiālu. (2010. gada decembris) |
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.".
Jautājumi un atbildes
J: Kas ir vienotā modelēšanas valoda (UML)?
A: Vienotā modelēšanas valoda (UML) ir modelēšanas valoda, ko izmanto programmatūras inženierijā, lai nodrošinātu standarta veidu, kā parādīt, kā izskatās sistēmas projekts.
J: Kāds bija UML sākotnējais mērķis?
A.: UML sākotnējais mērķis bija standartizēt dažādas notācijas sistēmas un pieejas programmatūras projektēšanai.
J: Kas izstrādāja UML?
A: UML izstrādāja Grady Booch, Ivar Jacobson un James Rumbaugh uzņēmumā Rational Software 1994.-1995. gadā, un 1996. gadā viņi turpināja tās izstrādi.
J: Kad UML tika pieņemts kā standarts?
A: UML kā standartu 1997. gadā pieņēma Object Management Group (OMG).
J: Kas pārvalda UML?
A: UML kopš tā pieņemšanas par standartu 1997. gadā pārvalda Object Management Group.
J: Vai UML ir atzīts par starptautisku standartu?
A: Jā, 2005. gadā Starptautiskā standartizācijas organizācija (ISO) atzina UML par starptautisku standartu.
J: Kāds ir UML mērķis programmatūras inženierijā?
A: UML mērķis programmatūras inženierijā ir nodrošināt standarta veidu, kā parādīt, kā izskatās sistēmas projekts, lai to varētu viegli saprast un paziņot izstrādātājiem un ieinteresētajām personām.
Meklēt