1.0Artjom Põldsaar Portfooliohttps://artjompoldsaar24.thkit.ee/wpadminhttps://artjompoldsaar24.thkit.ee/wp/blog/author/admin/rich600338<blockquote class="wp-embedded-content" data-secret="5EuDIrH82D"><a href="https://artjompoldsaar24.thkit.ee/wp/uml-skeemid/">UML skeemid</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://artjompoldsaar24.thkit.ee/wp/uml-skeemid/embed/#?secret=5EuDIrH82D" width="600" height="338" title="“UML skeemid” — Artjom Põldsaar Portfoolio" data-secret="5EuDIrH82D" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script type="text/javascript"> /* <![CDATA[ */ /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll('iframe[data-secret="'+t.secret+'"]'),o=l.querySelectorAll('blockquote[data-secret="'+t.secret+'"]'),c=new RegExp("^https?:$","i"),i=0;i<o.length;i++)o[i].style.display="none";for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute("style"),"height"===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):"link"===t.message&&(r=new URL(s.getAttribute("src")),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener("message",d.wp.receiveEmbedMessage,!1),l.addEventListener("DOMContentLoaded",function(){for(var e,t,s=l.querySelectorAll("iframe.wp-embedded-content"),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute("data-secret"))||(t=Math.random().toString(36).substring(2,12),e.src+="#?secret="+t,e.setAttribute("data-secret",t)),e.contentWindow.postMessage({message:"ready",secret:t},"*")},!1)))}(window,document); //# sourceURL=https://artjompoldsaar24.thkit.ee/wp/wp-includes/js/wp-embed.min.js /* ]]> */ </script> UML (Unified Modeling Language) – modeleerimiskeel UML kasutab: UML kasutab eritüüpe diagramme ja täpsustavad tekstikirjeldused. UML diagrammide tüübid Kasutuslooskeem (Use case diagram): Kasutuslooskeeme kasutatakse süsteemi moodustavate tähtsaimate elementide ja protsesside määramiseks. Primaarelemente nimetatakse “aktoriteks” (эктор) ning protsesse “kasutuslugudeks” (прецедент). Kasutuslooskeem näitab, millised aktorid suhtlevad iga kasutususlooga. Klassiskeem (Class diagram): Klassiskeemi kasutatakse nö. kasutuslooskeemi viimistlemiseks ning üksikasjaliku süsteemidisaini määramiseks. Klassiskeem liigitab kasutuslooskeemil määratud aktorid omavahel seotud klasside kogumiks. Klassidevaheline suhe või assotsiatsioon võib olla kas “on” või “omab” tüüpi. Iga klassiskeemil toodud klass on võimeline pakkuma teatud funktsionaalsust. Neid nimetatakse klassi meetoditeks. Lisaks sellele on igal klassil olemas rida atribuute mis määravad klassi üheselt. Objektiskeem (Object diagram): objektskeem on teatud tüüpi klassiskeem. Objekt esitab klassi olekut teatud ajahetkel süsteemi töö käigus. Objektiskeem esitab süsteemi erinevate klasside olekuid ning nendevahelisi relatsioone või assotsiatsioone teatud ajahetkel. Olekuskeem (State Diagram): nagu ka nimi ütleb näitab olekuskeem erinevaid olekuid, mida läbivad süsteemis olevad objektid oma elutsükli jooksul. Süsteemis olevad objektid muudavad oma olekut vastavalt süsteemis toimuvatele sündmustele. Lisaks sellele näitab olekuskeem ka objekti oleku üleminekut algolekust lõppolekusse vastavalt süsteemi mõjutavatele sündmustele. Tegevusskeem (Activity diagram): protsesside kulgemist süsteemis kirjeldatakse tegevusskeemi abil. Sarnaselt olekuskeemile koosneb ka tegevusskeem toimingutest, tegevustest, üleminekutest, alg- ja lõppolekust ning tõkisetingimustest Jadaskeem (Sequence diagram): jadaskeem esitab süsteemi objektide omavahelist suhtlemist. Jadaskeemi oluliseks omaduseks on selle ajaline järjestus. S.o. esitatakse samm-sammult täpne objektide vaheline interaktsioon. Erinevad objektid jadaskeemil suhtlevad omavahel “sõnumite” edastamise kaudu. Koostööskeem (Collaboration diagram): koostööskeem grupeerib erinevate objektide vahelise interaktsiooni. Interaktsioonid esitatakse nummerdatuna, mis lubab jälgida nende toimumise järjekorda. Koostööskeem lubab kindlaks teha kõikvõimalikud interaktsioonid mis igat objekti teistega seovad. Komponentskeem (Component diagram): komponentskeemi abil kujutatakse kõrgtaseme osi, millest süsteem koosneb. See skeem esitab millised komponendid süsteemi moodustavad ning kuidas nad omavahel seotud on. Levitusskeem (Deployment diagram): levitusskeemi abil kujutatakse rakenduse käitusaegeseid elemente. Olemi – suhteskeem (Database diagram): olemi-suhte skeemi ehk andmebaasi skeemi kasutatakse süsteemi andmestruktuuri ja tabelite vaheliste seoste kirjeldamiseks. Skeem määrab ära andmebaasi olemid (tabelid), nendes sisalduvad atribuudid (andmeväljad) ning nendevahelised relatsioonid (seosed). See on aluseks füüsilise andmebaasi loomisele, näidates täpselt, kuidas andmeid hoiustatakse ja kuidas erinevad tabelid, nagu näiteks kliendid ja tellimused, on primaar- ja välisvõtmete abil omavahel ühendatud. Storyboard Mobile App Storyboardhttps://artjompoldsaar24.thkit.ee/wp/wp-content/uploads/2026/03/2E6C8027-33D5-46DE-8C8E-D066C09F2F56-1.png1810794