UMLi elemendid
Kasutusklassiskeemid kirjeldavad protsessis osalevate kasutusklasside ja tegijate vahelisi relatsioone ja sõltuvusi.
Tähtis on tähele panna, et kasutusklassiskeemid pole mõeldud disaini kujutamiseks ja süsteemi sisestruktuuride kirjeldamiseks. Kasutusklassiskeemid on mõeldud kergendama suhtlemist kliendi ja süsteemi tulevaste kasutajate vahel ning on eriti kasulikud süsteemi funktsionaalsuse väljaselgitamisel. Kasutusklassiskeemid peaksid ütlema, mida süsteem peab tegema, mitte aga — ja ei tohigi öelda —, kuidas tehtu saavutatakse.
Kasutusklassiskeem Umbrellos
Kasutusklass kirjeldab tegijate vaatenurgast süsteemi tegevuste gruppi, mis tagastab konkreetse ja käegakatsutava tulemuse.
Kasutusklassid on tüüpilised süsteemi kasutajate ja süsteemi enda vaheliste interaktsioonide kirjeldused. Nad esindavad süsteemi välist liidest ja määravad nõuete kogu selle kohta, mida süsteem peab tegema (ära unusta: ainult mida, mitte kuidas).
Kasutusklassidega töötades on tähtis meeles pidada mõned lihtsad reeglid:
iga kasutusklass on seotud vähemalt ühe tegijaga
igal kasutusklassil on olemas algataja (st. tegija)
Iga kasutusklass juhatab kindla tulemuseni (“ärilise väärtusega” tulemuseni)
Ka kasutusklassidel võivad teiste kasutusklassidega relatsioonid olla. Kolm tüüpilisemat kasutusklasside vaheliste relatsioonide tüüpi on:
<<include>> määrab, kas kasutusklass leiab aset teise kasutusklassi sees
<<extends>> määrab, et kindlates situatsioonides või mingis punktis (mida kutsutakse laienduspunktiks) laiendab üks kasutusklass teist
üldistus määrab, et kasutusklass pärib eellasest kasutusklassi omadused ja võib mõnesid omadusi üle kirjeldada või lisada uusi sarnaselt klassidevahelise pärilusega
Tegija on väline olem (süsteemiväline), mis suhtleb süsteemiga, võttes osa (ja sageli algatades) kasutusklassist. Tegijad võivad olla reaalsed inimesed (näiteks infosüsteemi kasutajad), teised arvutisüsteemid või välised sündmused.
Tegijad ei esinda mitte füüsilisi isikuid või süsteeme, vaid nende rolle. See tähendab, et kui isik suhtleb süsteemiga erinevatel viisidel (võttes endale erinevaid rolle), siis kujutatakse teda erinevate tegijatena. Näiteks isikut, kes tegeleb telefoni kaudu kasutajatoeteenuse jagamisega ja võtab klientidelt ka süsteemi kasutamiseks tellimusi, peaks kujutama tegijatena “Kasutajatugi” ja “Müügimees”.
Klassiskeemid kujutavad süsteemi moodustavaid klasse ja nendevahelisi suhteid. Öeldakse, et klassiskeemid on “staatilised” skeemid, sest nad kujutavad klasse, nende meetodeid ja atribuute ning nendevahelisi suhteid: millised klassid “teavad” millistest klassidest või millised klassid “on teiste klasside osadeks”, kuid ei kujuta meetodite väljakutseid nende vahel.
Klassiskeemi kuvamine Umbrellos
Klass defineerib objektide hulga atribuudid ja meetodid. Kõik klassi objektid (klassi eksemplarid) jagavad ühist käitumist ja omavad samasugust hulka atribuute (igal objektil on isiklikud atribuudid). Vahel kasutatakse klassi asemel terminit “tüüp”, kuid tähtis on märkida, et need kaks ei ole samad ja tüüp on üldisem termin.
UMLis kujutatakse klasse nelinurkadena, millel on klassi nimi ja mis võivad sisaldada ka klassi atribuutide ja operatsioonide nimesid nelinurga kahes eraldi osas.
Klassi visuaalne esitus UMLis
UMLis kuvatakse vähemalt atribuudi nimi ja võib-olla ka selle tüüp, algväärtus ja muud omadused. Lisaks on võimalik kuvada atribuudi nähtavust:
+ tähistab public atribuuti
# tähistab protected atribuuti
- tähistab private atribuuti
Operatsioonide (meetodite) puhul kuvatakse samuti vähemalt nime ja võib-olla ka parameetreid ja tagastustüüpi. Nagu atribuutide puhulgi, saab ka operatsioonide juures näidata nende nähtavust:
+ tähistab public operatsiooni
# tähistab protected operatsiooni
- tähistab private operatsiooni
Klassid võivad olla omavahel seotud mitmel moel:
Pärilus on üks objektorienteeritud programmeerimise baaskontseptsioone, kus klass “omandab” kõik atribuudid ja operatsioonid kaasa sellelt eellasklassilt, millest ta pärineb, ning tohib neid üle kirjeldada ja muuta, aga ka lisada uusi atribuute ja operatsioone.
UMLis seab üldistuse tüüpi side kahe klassi vahel nad hierarhiasse, mis esindab tuletatud klassi baasklassist pärinemise kontseptsiooni. UMLis tähistab üldistust kaht klassi ühendav sirge, millel on nool baasklassi poolses otsas.
Üldistuse visuaalne esitus UMLis
Side esindab klasside seoseid ning võtab endas kokku paljude objektidevahelist “ühenduse” tüüpide semantika ja struktuuri.
Side on mehhanism, mis võimaldab objektidel üksteisega suhelda. See kirjeldab ühendust erinevate klasside vahel (ühendust tegelike objektide vahel nimetatakse objektiühenduseks ehk lingiks).
Sidemel võib olla roll, mis määrab sideme eesmärgi ja võib olla ühe- või kahesuunaline (märgib, kas kaks seotud objekti võivad teineteisele teateid saata või teab ainult üks teise olemasolu). Sideme mõlemal otsal on ka oma mitmesusväärtus, mis sätestab, mitu objekti sideme antud otsas võib olla seotud ühe objektiga sideme teises otsas.
UMLis tähistavad sidemeid sirged, mis ühendavad seotud klasse, need võivad ka näidata rolli ja mõlema osapoole mitmesusväärtust. Mitmesust esitatakse mittenegatiivsete väärtuste vahemikuna [min...maks], kusjuures tärn (*) maksimumväärtuse asemel tähendab lõpmatust.
Sideme visuaalne esitus UMLis
Agregatsioon on spetsiaalne side, milles kaks klassi pole mitte võrdväärse staatusega, vaid moodustavad “tervik-osa” seose. Agregatsioon kirjeldab, kuidas osa, millel on terviku roll, koosneb teistest klassidest (omab teisi klasse), millel on osade roll. Agregatsiooni korral on terviku rollis klassi mitmesus alatu üks.
UMLis tähistab agregatsiooni side, millel on tervikupoolses otsas romb.
Agregatsiooniseose visuaalne esitus UMLis
Kompositsioonid on sidemed, mis esindavad väga tugevat sidet. See tähendab, et ka kompositsioon kujutab endast tervik-osa seost, kuid see seos on nii tugev, et osad ei saagi omaette eksisteerida. Nad eksisteerivad ainult terviku koosseisus ja kui kaob tervik, kaovad ka osad.
UMLis tähistab kompositsiooni täidetud romb sideme tervikupoolses otsas.
Klassiskeemid võivad lisaks klassidele sisaldada veel mitmeid elemente.
Liidesed on abstraktsed klassid, mis tähendab, et neist ei saa otseselt eksemplare luua. Nad võivad sisaldada operatsioone, aga mitte atribuute. Klassid võivad olla liideste järglased (realisatsioonisideme kaudu) ning neist skeemidest saab siis luua eksemplare.
Andmetüübid on primitiivid, mis on tavaliselt lisatud juba programmeerimiskeelde. Tüüpnäiteks on täisarvud ja tõeväärtused. Neil ei saa olla seoseid klassidega, kuid klassidel võivad olla seosed nendega.
Väärtustikud on lihtsad väärtuste nimekirjad. Tüüpnäide on nädalapäevade väärtustik. Väärtustiku võtmeid nimetatakse literaalideks. Nagu andmetüüpidel, ei saa ka neil olla seoseid klassidega, küll aga klassidel nendega.
Järgnevusskeemid näitavad teadetevahetust (st. meetodi väljakutset) mitme objekti vahel teatud ajaliselt piiratud situatsioonis. Objektid on klasside eksemplarid. Järgnevusskeemid rõhutavad erilist teadete objektidele saatmise järjekorda ja aega.
Järjestusskeemidel esindavad objekte püstised punktiirjooned, mille ülemises otsas seisab objekti nimi. Ka ajatelg on vertikaalne, suurenedes allapoole, ning ühelt objektilt teisele saadetud teateid näidatakse nooltena, millele on lisatud operatsiooni ja parameetrite nimed.
Umbrello UML Modeller järgnevusskeemiga
Teated võivad olla sünkroonsed (tavaline teatetüüp, mille korral kontroll läheb väljakutsutavale objektile, kuni meetod on töö lõpetanud) või asünkroonsed (kontroll läheb otse tagasi väljakutsuvale objektile). Sünkroonsetel teadetel on väljakutsutud otjekti poolses otsas püstkast, mis näitab programmi kontrolli kulgu.
Koostööskeemid näitavad teatud situatsioonis osalevate objektide interaktsiooni. See on enam-vähem sama info, mida leiab järgnevusskeemilt, kuid viimaste korral on rõhk asetatud sellele, kuidas interaktsioon toimub, koostööskeemi korral aga objektidevahelistele seostele ja nende topoloogiale.
Koostööskeemides esindavad ühelt objektilt teisele saadetavaid teateid nooled, mis näitavad teate nime, parameetreid ja teate järgnevust. Koostööskeemid sobivad eriti hästi esitama spetsiifilist programmikulgu või situatsiooni ning need on parim skeemitüüp konkreetse protsessi kiireks demonstreerimiseks või seletamiseks programmiloogikas.
Umbrello UML Modeller koostööskeemiga
Olekuskeemid näitavad objekti erinevaid olekuid selle eluea kestel ning stiimuleid, mis põhjustavad objekti oleku muutumise.
Olekuskeemid käsitlevad objekte olekumasinatena ehk lõplike automaatidena, mis võivad olla ühes lõplike olekute kogumis ning muuta oma olekut lõpliku stiimulikogumi vahendusel. Nii võib näiteks objekt tüübiga NetServer olla oma eluea kestel ühes järgmistest olekutest:
valmis
jälgimine
töötamine
peatatud
ning sündmused, mis põhjustavad objekti oleku muutuse, on järgmised:
objekt luuakse
objekt saab teate jälgida
klient soovib võrguühendust
klient katkestab soovi
soov täidetakse ja lõpetatakse
objekt saab teate peatuda
jne
Umbrello UML Modeller olekuskeemiga
Olekud on olekuskeemide ehituskivid. Olek kuulub täpselt ühte klassi ning esindab väärtuste kokkuvõtet, mida klassi atribuudid võivad omada. UMLi olek kirjeldab konkreetse klassi objekti seesmist olekut.
Pane tähele, et mitte kõiki objekti mõne atribuudi muutusi ei esinda olek, vaid ainult neid muutusi, mis mõjutavad märgatavalt objekti käitumist.
Kaks olekutüüpi on erilised: algus ja lõpp. Need on erilised selle poolest, et ükski sündmus ei saa põhjustada objekti tagasipöördumist algusolekusse ning mitte ükski sündmus ei saa viia objekti välja lõppolekust, kui objekt on sellesse olekusse kord juba jõudnud.
Tegevusskeemid kirjeldavad tegevuste järgnevust süsteemis tegevuste abil. Tegevusskeemid on olekuskeemide erivorm, mis sisaldavad ainult või peamiselt tegevusi.
Umbrello UML Modeller tegevusskeemiga
Tegevusskeemid on sarnased protseduuride vooskeemidega, ainult et kõik tegevused on alati selgelt seotud objektidega.
Tegevusskeemid on alati seotud klassi, operatsiooni või kasutusklassiga.
Tegevusskeemid toetavad nii järgnevaid kui ka paralleelseid tegevusi. Paralleelset täitmist esindavad harunemise/ootamise ikoonid ning paralleelselt kulgevate tegevuste korral pole oluline, millises järjekorras need sooritatakse (neid võib sooritata nii ühel ja samal ajal kui ka üksteise järel).
Tegevus on protsessi üks konkreetne samm. Üks tegevus on üks olek seesmise tegevusega ja vähemalt ühe väljuva siirdega süsteemis. Tegevustel võib olla ka enam kui üks väljuv siire, kui neil on erinevad tingimused.
Tegevused võivad moodustada hierarhia, mis tähendab, et tegevus võib koosneda mitmest “alamtegevusest”, mille korral sisenevad ja väljuvad siirded peavad sobima kokku alamtegevuste skeemi sisenevate ja väljuvate siiretega.
UMLis on mõned elemendid, millel pole mudelis reaalset semantilist väärtust, kuid mis aitavad selgitada skeemi osi. Need elemendid on järgmised:
Tekstiread
Tekstimärkused ja ankrud
Kastid
Tekstiread on abiks skeemile lühikese tekstilise info lisamisel. See on vabalt asetsev tekst, millel ei ole mingit mõju mudelile endale.
Märkused on abiks põhjalikuma info esitamisel objekti või konkreetse situatsiooni kohta. Nende suureks eeliseks on see, et märkusi saab ankurdada UMLi elementide külge ning sel moel näidata, et märkus “kuulub” konkreetse objekti või situatsiooni juurde.
Kastid on vabalt asetsevad nelinurgad, millega võib elemente ühte koondada, et skeem oleks selgem ja arusaadavam. Mudelile endas pole neil mingit tähendust.
Komponentskeemid näitavad tarkvarakomponente (kas komponenttehnoloogiat nagu KParts, CORBA komponendid või Java Beans või siis lihtsalt süsteemi selgesti eristatavaid sektsioone) ning artefakte, mis on tekkinud näiteks lähtekoodifailidest, programmi teekidest või relatsioonilistest andmebaasidest.
Komponentidel võivad olla liidesed (st. abstraktsed klassid operatsioonidega), mis võimaldavad komponentidevahelisi sidemeid.
Evitusskeemid näitavad käitusaja komponentide eksemplare ja nende sidemeid. Nende hulka kuuluvad sõlmed, mis on füüsilised ressursid (tavaliselt üksikarvutid). Nad näitavad ka liideseid ja objekte (klassi eksemplare).
Olem-seos skeemid näitavad andmebaasirakenduste kontseptuaalset ülesehitust. Nad kujutavad erinevaid olemeid (kontsepte) infosüsteemis ning nendevahelisi seoseid ja kitsendusi. Olem-seos skeemide laiendusi, mida nimentatakse laiendatud olem-seos skeemideks või täiustatud olem-seos skeemideks, kasutatakse objektorienteeritud ülesehituse põimimsieks olem-seos skeemidesse.
Umbrello olem-seos skeemiga
Olem on mis tahes iseseisvalt eksisteeriv reaalse maailma kontsept. See võib olla füüsiline objekt (näiteks arvuti või robot) või kontseptuaalne objekt (näiteks ülikoolikursus). Igal olemil on oma atribuudid, mis kirjeldavad olemi omadusi.
Märkus: olem-seos skeemide kujutamiseks puudub standardne tähistamisviis. Erinevates tekstides tähistatakse neid erinevalt. Umbrellos kasutatud laiendatud olem-seos skeemide kontseptid ja tähistamisviis on võetud järgmisest raamatust: Elmasri R., Navathe S. Fundamentals of Database Systems. 4. tr. Addison Wesley, 2004.
Olem-seos skeemis kujutatakse olemeid ristkülikutena, mille kohal on olemi nimi ja mis võivad sisaldada ka olemi atribuute ja ristküliku eraldi osas.
Olemi visuaalne esitus olem-seos skeemis
Olem-seos skeemides näidatakse olemi atribuute koos nende nimega selle olemi omaette osas, mille juurde nad kuuluvad.
Kitsendused määravad olem-seos skeemidest kindlaks andmete piirangud infoskeemis.
Umbrello toetab nelja tüüpi kitsendusi:
Primaarvõti: atribuudid, mis on deklareeritud primaarvõtmena, on olemile unikaalsed. Olemil saab olla ainult üks primaarvõti ja ükski selle atribuutidest ei saa olla NULL.
Unikaalne võti: atribuudid, mis on deklareeritud unikaalse võtmena, on olemile unikaalsed. Olemil võib olla mitmeid unikaalseid kitsendusi. Nende atribuudid võivad olla NULL. Unikaalsed võtmed ja primaarvõtmed kirjeldavad unikaalselt tabeli rida (olemit).
Võõrvõti: võõrvõti on kahe tabeli viitekitsendus. Võõrvõti kirjeldab ühe (viitava) tabeli veergu või veerge, mis vastavad veerule või veergudele teises (viidatavas) tabelis. Viidatava tabeli veerud peavad moodustama primaar- või unikaalse võtme.
Kontrollkitsendus: kontrollkitsendus (ka tabeli kontrollkitsendus) on tingimus, mis defineerib korrektsed andmed kirje lisamisel või selle uuendamisel relatsioonilise andmebaasi tabelis. Kontrollkitsendust rakendatakse tabeli kõigile ridadele. Kitsendus peab olema predikaat. See võib viidata tabeli ühele või mitmele veerule.
Näide: hind >= 0
Spetsialiseerimine on uute olemite loomise viis juba kirjeldatud olemeid kasutades. Uued ehk tuletatud olemid võtavad üle ehk pärivad olemasolevate olemite ehk baasolemite atribuudid. See on mõeldud olemasolevate andmete korduvkasutamiseks kas üldse ilma muutusteta või väheste muutustega.
Umbrellos saab valida mittepuutuva ja osaliselt kattuva spetsialiseerimise vahel
Mittepuutuv spetsialiseerimine määrab, et spetsialiseerimise alamklassid ei tohi puutuda. See tähendab, et olem võib olla maksimaalselt ühe spetsialiseerimise tuletatud olemi liige.
Mittepuutuva spetsialiseerimise visuaalne esitus laiendatud olem-skeemi skeemis
Kui tuletatud olemeid ei ole piiratud mittepuutumise nõudega, on tegemist osaliselt kattuva spetsialiseerimisega. See tähendab, et üks ja sama olem võib olla korraga rohkem kui ühe spetsialiseerimise tuletatud olemi liige.
Osaliselt kattuva spetsialiseerimise visuaalne esitus laiendatud olem-skeemi skeemis
Tuletatud olem on kategooria, kui see kujutab endast objektide kogumit, mis on kindlate olemi ühenduse alamhulk. Kategooria luuakse, kui tekib vajadus konkreetse ülem/alamklassi seose järele enam kui ühe ülemklassiga, kus ülemklassid esindajad erinevaid olemitüüpe (see sarnaneb mitmese pärilusega objektorienteeritud programmeerimises).
Kategooria visuaalne esitus laiendatud olem-skeemi skeemis
