UML diagrammu izveides un datu bāzu modelēšanas rokasgrāmata

Pakotnes diagramma. To izmanto, lai ilustrētu līdzatkarības starp pakotnēm, kas veido modeli. Galvenais mērķis ir attēlos saistības starp dažādiem lieliem komponentiem, kas veido sarežģītu sistēmu. 

Profila diagramma. Šī diagramma ir mazāk diagramma, bet vairāk valoda. Profila diagramma palīdz izveidot jaunus rekvizītus un semantiku UML diagrammām, definējot pielāgotos stereotipus, atzīmētās vērtības un ierobežojumus. Šie profili ļauj jums pielāgot UML metamodeli dažādām platformām (piem., Java Platform, Enterprise Edition (Java EE) vai Microsoft .NET Framework) un jomām (piem., uzņēmējdarbības procesu modelēšana, uz pakalpojumiem orientēta arhitektūra, medicīnas programmas un ne tikai). 

Pamata UML lietojuma gadījuma diagrammas piemērs. Veidnei pieejama lejupielādei.

Lietojuma gadījuma diagramma. Šī diagramma apraksta to, ko dara sistēma, bet ne to, kā sistēma to dara. Lietojuma gadījums ir notikumu kopums, kas notiek tad, kad izpildītājs izmanto sistēmu, lai veiktu procesu. Izpildītājs ir jebkura persona vai struktūra, kas mijiedarbojas ar sistēmu (persona, organizācija vai programma), esot ārpus sistēmas. Lietojuma gadījuma diagramma vizuāli apraksta šo sekvenču kopu un atspoguļo sistēmas funkcionālās prasības. 

Mijiedarbības pārskata diagramma. Bieži vien šī diagramma ir sarežģīta, un tā ir līdzīga darbību diagrammai, jo abas parāda darbību secību. Taču mijiedarbības pārskata diagramma ir darbību diagramma, ko veido dažādas mijiedarbības diagrammas. Šī diagramma izmanto tādus pašus apzīmējumus kā darbību diagramma (sākuma, beigu, lēmuma, apvienojuma, sadalījuma un pievienošanās mezgli), ko papildina tādi elementi kā mijiedarbība, mijiedarbības lietojums, laika ierobežojums un ilguma ierobežojums. 

Hronometrāžas diagramma. Šo UML diagrammu izmanto, kad uzmanības centrā ir hronometrāža. Šo diagrammu sauc arī par sekvencēšanas vai notikuma diagrammu, jo tā nerāda, kā objekti mijiedarbojas vai maina viens otru. Funkcionāli tā uz laika skalas parāda kā objekti un izpildītāji darbojas. Uzmanības centrā ir notikumu ilgums un izmaiņas, kas rodas atkarībā no ilguma ierobežojumiem. Hronometrāžas diagrammas galvenās daļas ietver: 

• Darbības līnija: atsevišķs dalībnieks 

• Stāvokļa līnija: dažādi stāvokļi, kuriem cauri iziet darbības līnija 

• Ilguma ierobežojums: laiks, kas nepieciešams ierobežojuma izpildei 

• Laika ierobežojums: laiks, kas ir nepieciešams dalībniekam, lai kaut ko īstenotu 

• Iznīcināšanas notikums: brīdis, kad beidzas objekta darbības līnija. Pēc darbības līnijas iznīcināšanas tā vairs neparādās. 

Stāvokļa grafa diagramma. To sauc arī par stāvokļa diagrammu, šī diagramma tiek izmantota, ja objekta darbība ir sarežģīta un ļoti svarīga ir detalizēta informācija. Tā palīdz aprakstīt viena objekta (vai reizēm operatora) darbību un to, kā tā mainās atkarībā no iekšējiem un ārējiem notikumiem. 

Secības diagramma. Šī vizuāli pievilcīgā diagramma ir ne tikai populāra dizaineru kopienā, bet tā spēj labi parādīt visu veidu uzņēmējdarbības procesus. Tā vienkārši atklāj sistēmas struktūru, pārdot ziņojumu sekvenci un mijiedarbību starp izpildītājiem un objektiem hronoloģiskā veidā. Sekvences diagrammas parāda vienkāršu iterāciju un atzarojumus. Tā ir lietderīga vairāku uzdevumu vienlaicīgai izpildei. 

Saziņas diagramma. Komunikācijas jeb sadarbības diagramma ir līdzīga sekvences diagrammai. Tā liek uzsvaru uz komunikāciju starp objektiem. Tā parāda objektu, kas piedalās mijiedarbībā, organizāciju un attēlo sarežģītāku iterāciju un sazarojumus. 

Datu bāzu modeļi  

UML kļūst aizvien populārāka kā notāciju risinājums datu bāzu modelēšanai. Šie modeļi ir lielisks vizuāls rīks ideju meklēšanai, diagrammu brīvai veidošanai un sadarbībai pie idejām.  

UML nav specifikāciju datu modelēšanai, bet šī valoda var būt lietderīgs rīks diagrammu izveidei, it īpaši tāpēc, ka datus no datu bāzēm var izmantot objektorientētā programmēšanā.  

Apskatīsim dažādos datu bāzu modeļu veidus, kurus varat izveidot: 

• Hierarhisks datu bāzes modelis. Vecs, bet labs, šajā modelī dati tiek organizēti kokam līdzīgā struktūrā. Šo koku veido vairākas grupas, ko sauc par segmentiem. Tā izmanto relāciju viens ar daudziem. Datu piekļuve ir paredzama. 

• Tīkla modelis. Šim modelim ir grafika forma, kurā attiecību veidi veido arkas, bet objektu veidi veido mezglus. Atšķirībā no citiem datu bāzu modeļiem, tīkla modeļa shēma nav ierobežota ar struktūru vai hierarhiju. 

• Objektorientētas datu bāzes modelis. Šis modelis izmanto objektu kolekciju vai atkārtoti izmantojamus programmatūras elementus ar piesaistītajiem līdzekļiem un metodēm. Piemēram, multivides datu bāzē varētu būt attēli, kurus nevar saglabāt relāciju datu bāzē. Vai hiperteksta datu bāze, kas ļauj veidot saites uz citiem objektiem. 

• Relāciju modelis. Šeit dati tiek strukturēti ar relāciju palīdzību, izmantojot režģim līdzīgas matemātiskas struktūras ar kolonnām un rindām. Tā faktiski ir tabula. 

• Objektu-relāciju modelis. Kā liecina nosaukums, šis modelis apvieno abus iepriekš minētos. Tas atbalsta objektus, klases, pārmantošanu un citus uz objektiem orientētus elementus, kā arī datu tipus, tabulu veida struktūras un citus elementus relāciju datu modelī. 

• Entītiju-relāciju modelis. Šo modeli veido entītiju veidi (cilvēki, vietas vai lietas). Tas parāda relācijas, kas var pastāvēt starp tām. Definējot entītijas, to atribūtus un parādot attiecības star tām, ER diagramma ilustrē datu bāzu loģisko struktūru. 

• Dokumentu modelis. Tas ir paredzēts dokumentu uzglabāšanai un pārvaldībai jeb daļēji strukturētiem datiem, nevis atsevišķiem datiem. Tai ir koka struktūra, kurā katrs mezgls ir objekts, kas pārstāv dokumenta daļu. 

• Entītijas-atribūta-vērtības modelis. EAV jeb atvērtās shēmas modelī dati tiek ierakstīti kā trīs kolonnas:   
  • Entītija (tas, ko apraksta)  

   

  • Atribūts vai parametrs (piem., nosaukums, apraksts, datu veids) 

   

  • Atribūta vērtība 

• Zvaigznes shēma. Šī ir vienkāršākā dimensiju modeļa versija, kurā dati tiek kārtoti dimensijās un faktos. To izmanto uzņēmējdarbības informācijas un datu uzglabāšanai, jo tas ir piemērots lielu datu kopu vaicājumiem. 

Vienkāršošana ar programmatūru 

Neatkarīgi no tā, vai veidojat datu bāzu modeļus vai UML diagrammas,  programmatūras rīka  izmantošana vienkāršos un uzlabos šo procesu. Izvēlieties to, kas ļauj jums: 

• Veidot profesionālas diagrammas ar gatavām veidnēm un tūkstošiem formu satura ekosistēmā, kas atbild nozares standartiem, piemēram,  UML 2,5, bet arī BPMN 2.0 un IEEE. 

• Padariet shēmas aizraujošākas, izmantojot datu pārklājumu, ikonas, krāsas un grafikas, lai padarītu datus saprotamākus, tostarp ātro  Excel datu vizualizāciju. 

• Sadarbojieties ar citiem, izmantojot koprediģēšanu, komentēšanu un anotēšanu. 

• Strādājiet ar vienu un to pašu versiju un piekļūstiet shēmām no jebkuras atrašanās vietas pārlūkprogrammā vai ierīces programmās. 

Programmatūras izstrādes un citās sistēmās daudzās nozarēs vizuālo UML diagrammu izmantošanai var būt kritiski svarīga loma darbības procesu un struktūru izstrādē. Uzziniet vairāk par UML diagrammu izveidi ar programmatūru , lasot šo detalizēto pamācību.