Diagram UML

Vsebina

 [skriti] 

• 1 Zgodovina
• 1.1 Pred UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Oblikovanje
• 2.1 Metode razvoja programske opreme
• 2.2 Modeliranje
• 3 diagrami
• 3.1 Strukturni diagrami
• 3.2 Diagrami obnašanja
• 3.2.1 Diagrami interakcij
• 4 Meta modeliranje
• 5 Sprejetje
• 6 kritik
• 6.1 Kritika UML 1.x

Zgodovina[uredi | uredi]

Zgodovina objektno usmerjenih metod in zapisa

UML se razvija od druge polovice devetdesetih let prejšnjega stoletja in ima korenine v objektno usmerjenih metodah, razvitih v poznih osemdesetih in zgodnjih devetdesetih letih prejšnjega stoletja. Časovna os (glejte sliko) prikazuje glavne poudarke zgodovine metod in zapisov objektno usmerjenega modeliranja.

Prvotno temelji na zapisih metode Booch, tehnike objektnega modeliranja (OMT) in objektno usmerjenega programskega inženiringa (OOSE), ki jih je združil v enoten jezik. ^[5]

Pred UML 1.x[uredi | uredi | uredi]

Podjetje Rational Software Corporation je leta 1994 zaposlilo Jamesa Rumbaugha iz podjetja General Electric, nato pa je podjetje postalo vir dveh najbolj priljubljenih pristopov k objektno usmerjenemu modeliranju tistega časa:^[6] Rumbaughova tehnika objektnega modeliranja (OMT) in metoda Gradyja Boocha. Pri njunih prizadevanjih jima je kmalu pomagal Ivar Jacobson, ustvarjalec metode objektno usmerjenega programskega inženiringa (OOSE), ki se jima je v podjetju Rational pridružil leta 1995. ^[1]

Pod tehničnim vodstvom teh treh (Rumbaugh, Jacobson in Booch) je bil leta 1996 organiziran konzorcij, imenovan UML Partners, ki je dokončal specifikacijo Unified Modeling Language (UML) in jo predlagal skupini Object Management Group (OMG) v standardizacijo. Partnerstvo je vključevalo tudi dodatne zainteresirane strani (na primer HP, DEC, IBM in Microsoft). Januarja 1997 je konzorcij OMG predlagal osnutek UML 1.0, ki so ga pripravili partnerji UML. V istem mesecu so partnerji UML ustanovili skupino, namenjeno opredelitvi natančnega pomena jezikovnih konstrukcij, ki ji je predsedoval Cris Kobryn, upravljal pa jo je Ed Eykholt, da bi dokončali specifikacijo in jo povezali z drugimi prizadevanji za standardizacijo. Rezultat tega dela, UML 1.1, je bil predložen OMG avgusta 1997, OMG pa ga je sprejel novembra 1997. ^[1][7]

UML 1.x[uredi | uredi | uredi]

Po prvi izdaji je bila ustanovljena^[1] delovna skupina za izboljšanje jezika, ki je izdala več manjših popravkov, 1.3, 1.4 in 1.5. ^[8]

Standardi, ki jih je pripravil (in tudi prvotni standard), so bili označeni kot dvoumni in nedosledni. ^[9][10]

UML 2.x[uredi | uredi | uredi]

Glavna revizija UML 2.0 je leta 2005 nadomestila različico 1.5, ki jo je razvil razširjeni konzorcij, da bi jezik še izboljšal in upošteval nove izkušnje pri uporabi njegovih funkcij. ^[11]

Čeprav UML 2.1 ni bil nikoli objavljen kot uradna specifikacija, sta se različici 2.1.1 in 2.1.2 pojavili leta 2007, februarja 2009 pa še UML 2.2. UML 2.3 je bil uradno objavljen maja 2010.^[12] UML 2.4.1 je bil uradno objavljen avgusta 2011.^[12] UML 2.5 je bil izdan oktobra 2012 kot različica "v postopku", uradno pa je bil izdan junija 2015. ^[12]

Specifikacija UML 2.x ima štiri dele:

1. Nadgradnja, ki opredeljuje notacijo in semantiko za diagrame in njihove elemente modela.
2. Infrastruktura, ki opredeljuje osnovni metamodel, na katerem temelji nadgradnja.
3. Jezik za omejitve objektov (OCL) za določanje pravil za elemente modela
4. Izmenjava diagramov UML, ki določa, kako se izmenjujejo postavitve diagramov UML 2

V nadaljevanju so navedene veljavne različice teh standardov: Nadgradnja UML različica 2.4.1, infrastruktura UML različica 2.4.1, OCL različica 2.3.1 in izmenjava diagramov UML različica 1.0.^[13] Še naprej ga posodablja in izboljšuje delovna skupina za revizijo, ki rešuje vse težave z jezikom. ^[14]

Oblikovanje[uredi vir | uredi]

Enotni jezik modeliranja (UML) ponuja način vizualizacije arhitekturnih načrtov sistema v diagramu (glejte sliko), vključno z elementi, kot so: ^[5]

• Vse dejavnosti (delovna mesta)
• Posamezni sestavni deli sistema
• In kako lahko sodelujejo z drugimi komponentami programske opreme.
• Kako bo sistem deloval
• Kako entitete komunicirajo z drugimi (komponente in vmesniki).
• Zunanji uporabniški vmesnik

Čeprav je bil prvotno namenjen izključno za objektno usmerjeno projektno dokumentacijo, je bil enotni jezik modeliranja (UML) razširjen na širši nabor projektne dokumentacije (kot je navedeno zgoraj) ^[15]in se je izkazal za uporabnega v številnih okoliščinah. ^[16]

Metode razvoja programske opreme[uredi | uredi | uredi]

UML sam po sebi ni razvojna metoda, ^[17]vendar je bil zasnovan tako, da je bil združljiv z vodilnimi metodami objektno usmerjenega razvoja programske opreme tistega časa (na primerOMT, Boochova metoda, Objectory) in zlasti z RUP, ki je bil prvotno namenjen uporabi, ko se je začelo delo v podjetju Rational Software Inc.

Modeliranje[uredi | uredi | uredi]

Pomembno je razlikovati med modelom UML in nizom diagramov sistema. Diagram je delni grafični prikaz modela sistema. Ni nujno, da množica diagramov v celoti pokriva model, črtanje diagrama pa ne spremeni modela. Model lahko vsebuje tudi dokumentacijo, ki poganja elemente modela in diagrame (kot so pisni primeri uporabe).

Diagrami UML predstavljajo dva različna pogleda na model^[18] sistema:

• Statični (ali strukturni) pogled: poudarja statično strukturo sistema z objekti, atributi, operacijami in odnosi. Strukturni pogled vključuje diagrame razredov in sestavljene strukturne diagrame.
• Dinamični (ali vedenjski) pogled: poudarja dinamično vedenje sistema s prikazom sodelovanja med objekti in spremembami notranjega stanja objektov. Ta pogled vključuje diagrame zaporedij, diagrame dejavnosti in diagrame strojev stanj.

Modeli UML se lahko izmenjujejo med orodji UML z uporabo formata za izmenjavo metapodatkov XML (XMI).

Diagrami[uredi | uredi | uredi]

UML 2 ima veliko vrst diagramov, ki so razdeljeni v dve kategoriji.^[5] Nekatere vrste predstavljajo strukturne informacije, preostale pa splošne vrste obnašanja, vključno z nekaj vrstami, ki predstavljajo različne vidike interakcij. Te diagrame je mogoče hierarhično razvrstiti, kot je prikazano v naslednjem diagramu^[5] razredov:

Vsi ti diagrami lahko vsebujejo komentarje ali opombe, ki pojasnjujejo uporabo, omejitev ali namen.

Strukturni diagrami[uredi | uredi | uredi]

Strukturni diagrami poudarjajo stvari, ki morajo biti prisotne v modeliranem sistemu. Ker strukturni diagrami predstavljajo strukturo, se pogosto uporabljajo pri dokumentiranju arhitekture programskih sistemov. Na primer diagram komponent, ki opisuje, kako je programski sistem razdeljen na komponente, in prikazuje odvisnosti med temi komponentami.

• Diagram komponent
• Diagram razredov

Diagrami obnašanja[uredi | uredi | uredi]

Diagrami obnašanja poudarjajo, kaj se mora zgoditi v modeliranem sistemu. Ker vedenjski diagrami ponazarjajo obnašanje sistema, se pogosto uporabljajo za opisovanje funkcionalnosti programskih sistemov. Kot primer lahko navedemo diagram dejavnosti, ki opisuje poslovne in operativne dejavnosti po korakih komponent v sistemu.

• Diagram dejavnosti
• Diagram primerov uporabe

Diagrami interakcij[uredi | uredi | uredi]

Diagrami interakcij, podmnožica diagramov obnašanja, poudarjajo pretok nadzora in podatkov med stvarmi v modeliranem sistemu. Na primer diagram zaporedja, ki prikazuje, kako predmeti komunicirajo med seboj v smislu zaporedja sporočil.

• Diagram zaporedja
• Komunikacijski diagram

Meta modeliranje[uredi | uredi | uredi]

Glavni članek: Metaobjektna zmogljivost

Ilustracija metaobjektne zmogljivosti

Skupina za upravljanje objektov (OMG) je razvila arhitekturo metamodeliranja za opredelitev enotnega jezika modeliranja (UML), imenovano Meta-Object Facility (MOF).^[19] Meta-Object Facility je zasnovana kot štirislojna arhitektura, kot je prikazano na sliki desno. Na zgornji plasti zagotavlja meta-meta-model, ki se imenuje plast M3. Ta model M3 je jezik, ki ga Meta-Object Facility uporablja za izgradnjo metamodelov, imenovanih modeli M2.

Najznačilnejši primer modela metaobjektne zmogljivosti plasti 2 je metamodel UML, model, ki opisuje sam UML. Ti modeli M2 opisujejo elemente plasti M1 in s tem modele M1. To so na primer modeli, napisani v UML. Zadnja plast je plast M0 ali podatkovna plast. Uporablja se za opis primerkov sistema v času izvajanja. ^[20]

Meta-model je mogoče razširiti z mehanizmom, ki se imenuje stereotipizacija. Brian Henderson-Sellers in Cesar Gonzalez-Perez sta v članku "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" kritizirala, da je ta mehanizem nezadosten/neustrezen. ^[21]

Posvojitev[uredi vir | uredi]

UML se je izkazal za uporabnega v številnih kontekstih načrtovanja, ^[16]tako zelo, da je postal skorajda vseprisoten v skupnosti IT. ^[22]

Včasih so ga obravnavali kot srebrno puško, kar je privedlo do težav pri njegovi uporabi. Napačna uporaba vključuje pretirano uporabo (z njo se oblikuje vsak najmanjši del kode sistema, kar je nepotrebno) in domnevo, da lahko z njo vsakdo oblikuje kar koli (tudi tisti, ki niso programirali). ^[23]

Videti je, da gre za obsežen jezik s številnimi konstrukcijami. Nekateri (vključno z Jacobsonom) menijo, da jih je preveč in da to ovira učenje (in s tem uporabo) tega jezika. ^[24]

Kritike[uredi | uredi | uredi]

Pogoste kritike UML s strani industrije vključujejo: ^[4]

• ni uporabno: "[jim] ne ponuja prednosti v primerjavi z njihovimi sedanjimi, razvitimi praksami in predstavitvami".
• preveč zapletena, zlasti za komunikacijo s strankami: "Najboljši razlog za neuporabo UML je, da ni 'berljiv' za vse zainteresirane strani. Koliko je UML vreden, če poslovni uporabnik (stranka) ne more razumeti rezultata vašega prizadevanja za modeliranje?"
• potreba po sinhronizaciji UML in kode, tako kot pri dokumentaciji na splošno.

Kritika UML 1.x[uredi | uredi | uredi]

Zapis kardinalnosti

Podobno kot pri diagramih ER podatkovnih baz Chen, Bachman in ISO je tudi pri modelih razredov določeno, da se uporabljajo kardinalnosti "look-across", čeprav več avtorjev (med drugim^[27] Merise, ^[25]Elmasri in Navathe)^[26] za vloge in minimalne in maksimalne kardinalnosti raje uporablja "look-here" ali "look-side". Nedavni raziskovalci (Feinerer, ^[28]Dullea idr.^[29]) so pokazali, da je tehnika "look-across", ki jo uporabljajo diagrami UML in ER, manj učinkovita in manj koherentna, kadar se uporablja za n-arne relacije reda >2.

Feinerer pravi: "Težave se pojavijo, če delujemo po semantiki "look-across", ki se uporablja za asociacije UML. Hartmann^[30] raziskuje to situacijo in pokaže, kako in zakaj različne transformacije ne uspejo." (Čeprav je omenjena "redukcija" lažna, saj sta diagrama 3.4 in 3.5 dejansko enaka) in tudi "Kot bomo videli na naslednjih nekaj straneh, razlaga look-across uvaja več težav, ki preprečujejo razširitev preprostih mehanizmov z binarnih na n-arne asociacije."