zsi2

a) pri vytváraní tohto modelu pomocou Case systému PowerDesigner je možné ako prvý diagram zvoliť tzv. Requirements Allocation view

b) v základnom dokumentovom pohľade je možné zvoliť prioritu, risk a status jednotlivých požiadaviek

c) model požiadaviek je možné prepojiť s modelom obchodných procesov

d) používatelia uvedení v traceability view modelu môžu byť objektami iného objektovoorientovaného modelu

a) znázornený je pohľad User Allocation view modelu požiadaviek

b) uvedení používatelia môžu byť objektami use case modelu 

c) riadok 2.1 Scenario 1 predstavuje určitú požiadavku modelu

d) je súčasťou interakčných objektových modelov

a) znázornený je pohľad Traceability Matrix view modelu obchodných procesov

b) položky Scenario predstavujú používateľov zodpovedných za uvedené procesy

c) položka User list je súčasťou zoznamu požiadaviek v rámci požiadavky Food Inventory

d) znázornený model obsahuje tri druhy diagramov

a) slovník pojmov 

b) skupina riešiteľov, ktorí sú zodpovední za riešenie aspoň jednej požiadavky

c) prehliadač so stromovým pohľadom

d) požiadavka, ktorá je precízne definovaná hneď po priradení aspoň jednému riešiteľovi

a) pri vytváraní šablóny modelu

b) po vytvorení modelu s implicitnými vlastnosťami

c) importovaním .rtf dokumentu

d) hneď pri vytváraní modelu

a) komponent diagramu aktivít objektovo-orientovaného modelu

b) element Operátorka je externou entitou diagramu interakcií 

c) element PrijemObjednavky je jedným z dvoch znázornených procesov

d) element DatabazaVlakov je terminátorom diagramu dátových tokov

e) aspoň jeden výskyt elementu zdroj 

a) element Student predstavuje aktéra zodpovedného za vykonanie troch zobrazených procesov 

b) organizačná jednotka diagramu je zobrazená v tzv. swimlane móde 

c) procesy Napisat_zapoctovku a Vypracovat_zadanie prebiehajú nezávisle na sebe

d) diagram nie je súčasťou objektovo-orientovaného modelu 

e) procesy Zapisat_predmet a Zapisat_znamku predstavujú elementárne procesy nulovej úrovne dekompozície

a) diagram hierarchie procesov modelu obchodných procesov

b) diagram nulovej úrovne dekompozície

c) diagram obsahujúci tri externé entity a jeden terminátor

d) diagram, ktorý je hierarchicky nadradený systémovému diagramu

a) tok dát a ich spracovanie

b) komunikácia systému s okolím

c) špecifikácia požiadaviek a ich náväznosť na udalosti z okolia

d) detailná štruktúra algoritmov

a) dátové vstupy sú transformované aktivitami používateľa a systému

b) pre modelovanie väzieb systému ako celku na okolie sa používa kontextový diagram dátových tokov

c) nie sú dekomponovateľné na elementárne procesy

d) ich súčasťami môžu byť i dátové pamäti 

e) sú orientovanými sieťovými grafmi, ktorých hrany predstavujú procesy, zdroje a externé entity

a) diagramy dátových tokov, kde dátové vstupy sú transformované aktivitami používateľa a systému

b) entitno-relačné diagramy, ktoré sú pozbavené väzieb M:N 

c) stavové diagramy, ktoré sú riadené udalosťami

d) stavové diagramy, ktoré popisujú zmeny v čase a ukazujú odpoveď systému na externé a interné udalosti 

e) modely, ktoré popisujú správanie sa systému

a) modely obchodných procesov tvoria počiatočnú fázu mnohých softvérových projektov

b) modely obchodných procesov nie sú súčasťou metodológie UML

c) diagram hierarchie procesov rieši procesnú dekompozíciou systému

d) v rámci metodológie UML sú modelom obchodných procesov graficky najpodobnejšie diagramy objektovej spolupráce 

a) inštancia entity Employee musí byť súčasťou minimálne jednej inštancie entity Team

b) inštancia entity Team musí obsahovať aspoň jednu inštanciu entity Employee

c) zo zobrazeného modelu je možné pomocou CASE nástroja PowerDesigner priamo vygenerovať fyzický dátový model

d) pred vygenerovaním fyzického dátového modelu je nutné odstrániť väzbu M:N 

e) zobrazený fyzický dátový model obsahuje väzbu typu M:N 

a) medzi jednotlivými entitami fyzického dát. modelu je väzba typu M:N, ktorú je možné použiť v začiatkoch dátovej analýzy. Neskôr však musí byť prevedená na väzbu typu 1:N .

b) znázornený dátový model je nezávislý na implementácii.

c) pri určovaní primárneho kľúča v prostredí CASE nástroja PowerDesigner je nutné zvoliť vlastnosť atribútu označenú ako Mandatory.

d) väzba typu M:N bude odstránená pridaním jednej medzitabuľky

a) jedná sa o konceptuálny dátový model, z ktorého bola odstránená väzba typu M:N medzi entitami Skola a Student

b) znázornený dátový model zohľadňuje zvolenú relačnú databázu

c) zo znázorneného dátového modelu je možné vygenerovať skript pre zvolenú relačnú databázu 

d) zo znázorneného fyzického dátového modelu je možné priamo vygenerovať konceptuálny dátový model

a) je to konceptuálny dátový model, ktorý prezentuje pohľad na reálny svet ako na sústavu entít s danými atribútmi

b) kardinalita vzťahu v tomto diagrame predstavuje integritné obmedzenie, ktoré vyjadruje nutnosť existencie entity jedného typu vo vzťahu k existencii entity iného typu 

c) integritné pravidlo cascade povolí aktualizáciu údajov, ale upraví taktiež všetky záznamy v podriadených tabuľkách 

d) entita predstavuje objekt reálneho sveta, ktorý je schopný nezávislej existencie

a) identifikácie entít, priradenie popisných atribútov jednotlivým vzťahom a entitám, identifikácia vzťahov, formulácia integritných obmedzení

b) formulácia integritných obmedzení, identifikácie entít, identifikácia vzťahov, priradenie popisných atribútov jednotlivým vzťahom a entitám 

c) identifikácie entít, identifikácia vzťahov, priradenie popisných atribútov jednotlivým vzťahom a entitám, formulácia integritných obmedzení 

d) identifikácia vzťahov, identifikácie entít, priradenie popisných atribútov jednotlivým vzťahom a entitám, formulácia integritných obmedzení

a) reprezentácia organizácie dát v grafickej forme entitno-relačných diagramov

b) generovanie objektovo-orientovaného modelu a tým určenie reprezentácie CDM použitím UML

c) možnosť prevádzania denormalizácie a špecifikovanie nastavení pre cieľovú databázovú platformu

d) generovanie fyzického dátového modelu priamo, bez predchádzajúcej kontroly správnosti konceptuálneho dátového modelu

e) kontrola validity návrhu dátového modelu

a) má aspoň jednu väzbu M:N

b) študent môže, ale nemusí byť prihlásený aspoň na jeden študijný odbor

c) každý predmet musí byť zahrnutý aspoň v rámci jedného študijného odboru

d) študijný program nemusí obsahovať ani jeden predmet

e) na študijný odbor musí byť prihlásený aspoň jeden študent

a) daný diagram znázorňuje fyzický dátový model 

b) jeden typ súčiastky môže byť použitý vo viacerých typoch výrobkov

c) výrobok nemusí obsahovať žiadnu súčiastku 

d) znak predstavuje atribút Main

e) každý výrobok má len jedného výrobcu

a) vygenerovaný fyzický dátový model bude obsahovať o jednu tabuľku viac ako znázornený konceptuálny dátový model 

b) znak reprezentuje atribút Mandatory

c) každý klient môže vlastniť i viacero bankových účtov, ale vždy minimálne jeden

d) jeden bankový účet môže byť vlastníctvom viacerých bánk

a) tabuľka Bankovy_ucet vznikla rozbitím väzby M:N medzi tabuľkami Banka a Klient

b) znak reprezentuje v konceptuálnom dátovom modeli atribút primárny identifikátor

c) generovanie databázového skriptu v návrhovom prostredí CASE nástroja PowerDesigner je možné po zvolení funkcie Generate Database v menu Database

d) zo znázorneného modelu je možné vygenerovať XML model 

a) relácia typu include v smere od prípadu Uzavriet_obchod k prípadu Vytvorit_danovy_doklad

b) relácia typu extend v smere od prípadu Uzavriet_obchod k prípadu Vytvorit_danovy_doklad 

c) relácia typu include v smere od prípadu Vytvorit_danovy_doklad k prípadu Uzavriet_obchod

d) relácia typu extend v smere od prípadu Vytvorit_danovy_doklad k prípadu Uzavriet_obchod 

a) relácia typu extend v smere od prípadu Pridat_novu_krajinu_povodu k prípadu Pridat_noveho_vyrobcu

b) relácia typu include v smere od prípadu Pridat_novu_krajinu_povodu k prípadu Pridat_noveho_vyrobcu

c) relácia typu extend v smere od prípadu Pridat_noveho_vyrobcu k prípadu Pridat_novu_krajinu_povodu

d) relácia typu include v smere od prípadu Pridat_noveho_vyrobcu k prípadu Pridat_novu_krajinu_povodu

a) asociácia, ktorá predstavuje komunikačnú cestu medzi aktérom a prípadom použitia

b) generalizácia, ktorá predstavuje vzťah medzi generálnym a špecifickým elementom

c) generalizácia môže byť vytvorená medzi dvoma aktérmi a tiež medzi dvoma prípadmi použitia 

d) relácia include, ktorá sa používa v prípadoch, kde existuje rovnaká alebo podobná časť scenára opakujúca sa so viacerých prípadoch použitia

e) relácia extend, ktorá rozširuje prípad použitia o nové, doplnkové správanie 

a) základný element diagramu aktivít objektovo-orientovaného modelu

b) rolu, v ktorej vystupuje používateľ v rámci jeho komunikácie so systémom

c) v systéme môže jeden aktér vykonávať viacero prípadov použitia, no jeden prípad použitia môže byť vykonávaný iba jedným aktérom 

d) ako aktéri nemusia vystupovať iba osoby, ale aj externé systémy, ktoré potrebujú informácie z modelovaného systému, dokonca aj čas

a) reláciou extend pridáva rozširujúco prípad použitia nové, doplnkové chovanie do základného prípadu použitia

b) relácia include sa používa tam, kde je potrebné špecifikovať nové, viac sa neopakujúce sekvencie scenára

c) základný prípad použitia prepojený reláciou include, je bez rozširujúceho prípadu použitia kompletný

d) základný prípad použitia prepojený reláciou extend je sám o sebe úplne sebestačný

a) relácia extend v smere od prípadu Pridat_noveho_vyrobcu k prípadu Pridat_novy_spotrebic 

b) relácia extend v smere od prípadu Pridat_novy_spotrebic k prípadu Pridat_noveho_vyrobcu 

c) relácia include v smere od prípadu Pridat_novy_spotrebic k prípadu Pridat_noveho_vyrobcu 

d) relácia include v smere od prípadu Pridat_noveho_vyrobcu k prípadu Pridat_novy_spotrebic

a) relácia medzi oboma prípadmi použitia je typu extend

b) relácia medzi oboma prípadmi použitia je typu include

c) obaja aktéri predstavujú istý typ triedy so špecifickým stereotypom

d) vzťah medzi aktérmi označujeme pojmom generalizácia 

e) prípad Kupa_listka sa vzťahuje na aktéra Osoba 

a) agregácia, pričom triedy Class_2 a Class_3 sú komponentami supertriedy Class_1 

b) špecializácia, pričom Class_2 a Class_3 sú špecializovanými triedami všeobecnej triedy Class_1 

c) generalizácia, teda vzťah medzi obecnou triedou a jej konkrétnymi potomkami, pričom obecná trieda môže byť i abstraktná 

d) dedenie, pričom trojuholník znázorňuje smer dedenia, ukazuje na nadradenú triedu a podriadené triedy dedia jej atribúty, operácie, relácie a obmedzenia. 

a) medzi triedou A a B je väzba typu agregácia

b) medzi triedou C a B je väzba typu realizácia

c) medzi triedou C a A je väzba typu kompozícia

d) medzi triedou C a A je väzba typu silná agregácia

e) trieda A je komponentom triedy C 

a) objekt triedy A nemôže existovať samostatne bez objektu triedy C 

b) inštancia triedy C má asociáciu na nula alebo viac inštancií triedy B 

c) medzi triedami A a C existuje väzba typu silná agregácia

d) inštancia triedy B dedí z triedy A jej atribúty a operácie 

a) asociácia v diagrame tried znázorňuje vzťahy medzi jednou či viac triedami, ktoré sú abstrakciami množiny spojení medzi objektmi týchto tried

b) väzby agregácia a kompozícia v diagrame tried znamenajú, že jedna trieda je časťou druhej triedy

c) pri väzbe typu agregácia je zrejmé, že podriadený objekt nemôže existovať samostatne bez svojho nadriadeného objektu

d) kompozícia sa v metodológii UML označuje prázdnym kosoštvorcom 

a) asociačné triedy nedovoľujú priradiť atribúty a operácie k asociačnej väzbe, ktorá rieši vzťah medzi triedami typu M:N 

b) diagram tried zobrazuje štruktúru a vzťahy medzi objektovými triedami navrhovaného systému

c) inštancia je vlastne predpis pre tvorbu reálnych objektov 

d) generalizácia je vzťah medzi obecnou objektovou triedou a jej konkrétnymi potomkami

e) štruktúra triedy je definovaná svojimi atribútmi, operáciami a obmedzeniami 

a) v diagrame sa nachádza aspoň jeden vzťah realizácie

b) medzi triedou A a triedou C sa nachádza vzťah ktorý určuje, že inštancia triedy C nemôže existovať samostatne bez existencie inštancie triedy A

c) medzi triedou A a triedou B sa nachádza vzťah typu závislosť

d) inštancia triedy B dedí všetky atribúty a operácie od triedy D

e) vzťah nachádzajúci sa medzi A a B špecifikuje spojenie medzi ich inštanciami, ktoré si budú môcť posielať správy

a) vzťah medzi triedou B a C naznačuje, že trieda C dedí všetky operácie a atribúty z triedy B

b) v diagrame sa nachádzajú dva typy agregačných vzťahov

c) trieda D je rozhraním a s triedou A je prepojená vzťahom zvaným realizácia 

d) inštancia triedy C môže existovať samostatne i po zániku inštancie triedy B 

a) sa jedná o diagram objektovej spolupráce

b) patrí do skupiny interakčných diagramov

c) písmeno C označuje objekt a písmeno A označuje triedu objektu C

d) sprava4 je asynchrónnym volaním, ktoré zruší objekt C

e) sprava1 je volaním, ktoré vytvorí objekt B 

a) sprava2 je návratovým volaním objektu B

b) zvislá prerušovaná čiara reprezentuje aktivačný box objektu

c) sprava2 reprezentuje vrátenie aktivity volajúcemu objektu

d) sprava2 môže označovať paralelný proces alebo vlákno 

e) sprava3 znázorňuje predávanie správy, ktorú objekt zasiela sám sebe

a) sú jedným diagramom z kategórie diagramov objektovej spolupráce

b) zo sekvenčného diagramu je možné v prostredí CASE nástroja PowerDesigner priamo vygenerovať zodpovedajúci komunikačný diagram

c) sekvenčný diagram je súčasťou objektovo-orientovaného modelu UML metodológie a reprezentuje životný cyklus objektu za určité časové obdobie

d) je ich možné prepojiť s modelom obchodných procesov

a) aktér ako externá osoba alebo proces, ktorý spolupracuje so systémom alebo triedou

b) rekurzívna správa, kedy odosielateľ a prijímateľ predstavujú ten istý objekt

c) správy, ktoré predstavujú udalosti entry, do a exit 

d) rekurzívne volanie procedúry s aktiváciou

a) akcia „return“, ktorá označuje koniec procedúry

b) akcia „self-destroy“, kedy odosielajúci objekt varuje cieľový, že sa sám zruší

c) akcia „create“, kedy odosielajúci objekt vytvára a inicializuje inštanciu cieľového objektu 

d) akcia „asynchronous“, kedy odosielajúci objekt nečaká na výsledok a môže paralelne vykonávať inú funkciou.

a) parameter Control Flow, ktorý určuje režim, v ktorom sa správa posiela

b) parameter Message, ktorý určuje typ správy a typ akcie, ktorú správa vykonáva

c) akciu „destroy“, kedy odosielajúci objekt zruší cieľový objekt 

d) akciu „Self-destroy“, ktorá sa môže použiť len ak správa je odosielaná v režime „Procedure Call“ 

a) diagram spolupráce znázorňuje rovnaký druh informácií ako sekvenčný diagram, ale koncentruje sa viac na chronológiu posielania správ medzi objektmi 

b) v UML 2.0 sa diagram objektovej spolupráce označuje ako diagram nasadenia 

c) diagram spolupráce je súčasťou modelu obchodných procesov 

d) komunikačný diagram znázorňuje časť funkcionality systému pomocou množiny chronologických interakcií medzi objektmi 

a) sprava1 bola odoslaná v asynchrónnom režime

b) medzi objektom C a objektom B existuje inštančná (komunikačná) linka

c) tento typ diagramu patrí do skupiny diagramov nasadenia

d) tento typ diagramu je v prostredí CASE nástroja PowerDesigner priamo generovateľný zo sekvenčného diagramu

a) jedná sa o diagram objektovej spolupráce

b) súčasťou tohto diagramu by mohol byť objekt aktér

c) z tohto diagramu nie je možné v prostredí CASE nástroja PowerDesigner vygenerovať žiaden iný diagram 

d) v UML 2.0 sa tento diagram označuje ako diagram nasadenia

a) daný diagram nie je diagramom interakcie, jedná sa o diagram objektovej spolupráce

b) objekt C vznikol (prácou v nástroji PowerDesigner) zvolením možnosti Create ako hodnoty atribútu Control Flow v záložke Detail 

c) správa signal_end je asynchrónnym typom správy

d) zvislá prerušovaná čiara aktéra A sa nazýva čiarou života objektu A

a) diagramy interakcií zahŕňajú sekvenčný diagram, komunikačný diagram a diagram aktivít

b) diagramy interakcie modelujú realizácie prípadov použitia 

c) diagramy objektovej spolupráce znázorňujú spoluprácu objektov z hľadiska času

d) komunikačný diagram kladie dôraz na spoluprácu objektov, nie je však príliš vhodný pre zachytenie časovej postupnosti 

a) jedná sa o diagram, ktorý nepatrí do metodológie UML 2.0

b) v stave Stav_3 nie je definovaná vstupná udalosť 

c) na hranách diagramu medzi stavom Stav_1 a Stav_3 nie je uvedený názov akcie, ktorá sa vykonáva, uvedená je len udalosť, ktorá jej predchádza

d) objekty v zobrazovanom systéme menia v čase svoj stav

a) nepatrí do štandardnej notácie UML 2.0

b) graficky znázorňuje stavy a na ne nadväzujúce zmeny stavov

c) môže obsahovať zložité stavy

d) zvolením možnosti „Decomposed state“ v prostredí CASE nástroja PowerDesigner vytvorí nový sub-statechart diagra 

e) je ohraničený počtom možných rozkladov 

a) jedná sa o diagram aktivít s dvoma definovanými stavmi

b) písmeno X na hrane reprezentuje akciu

c) písmeno X na hrane reprezentuje udalosť

d) písmeno Y na hrane reprezentuje podmienku 

e) daný diagram neobsahuje žiadnu stráž

a) písmeno Z na hrane reprezentuje udalosť vyvolanú podmienkou Y

b) znázornený diagram môže modelovať dynamické charakteristiky prvkov diagramu tried

c) v rámci zobrazených stavov je možné došpecifikovať tri druhy akcií – entry, do a end 

d) zobrazený diagram je diagramom objektovo-orientovaného modelu

a) dynamiku stavových diagramov predstavujú prechody medzi stavmi a vyvolanými udalosťami

b) stav objektu v rámci stavového diagramu je daný hodnotami atribútov objektu, aktuálnymi spojeniami s ostatnými objektmi a práve vykonávanou operáciou

c) akcia v stavovom diagrame je neprerušiteľný, rýchlo prebiehajúci proces 

d) udalosť v stavovom diagrame je istú dobu trvajúci proces, ktorý sa vykoná po splnení určenej podmienky (ak existuke) 

e) každý stav má dve implicitné akcie – entry a exit

a) aktér Osoba je zodpovedný za vykonanie aktivít A a B 

b) nie je súčasťou objektovo-orientovaného modelu

c) nejedná sa o diagram aktivít 

d) aktivity A a B sa vykonávajú paralelne 

a) aktivity B a C sú súbežné a nezáleží na poradí ich vykonania

b) zobrazený diagram je súčasťou metodológie UML 2.0

c) tento diagram je možné prepojiť s USE CASE diagramom 

d) tento diagram nie je rozšírením stavového diagramu a nevyužíva sa na popis tried v objektovom modelovaní 

a) diagramy aktivít sa používajú na popis dynamických aspektov systému

b) diagram aktivít zobrazujú sekvenciu stavov, ktoré nastávajú v čase a ukazujú podmienky spôsobujúce prechody medzi stavmi

c) súčasťou diagramu aktivít je i element Organization Unit Swimlane

d) uzol aktivity v diagrame je veľmi podobný funkcii uzlu v diagrame nasadenia

a) diagramy aktivít sa využívajú na popis prípadov použitia a tried 

b) diagramy aktivít sa používajú na popis algoritmov

c) diagram aktivít je súčasťou modelu obchodných procesov

d) diagram aktivít je rozšírením USE CASE diagramu

a) uzol rozhodnutia/splynutia (decision/merge node) 

b) uzol rozdvojenia/spojenia (fork/join node) 

c) uzol sekvencie (sequence node

d) uzol váhy (weight node)

e) počiatočný uzol (initial node) 

a) diagramy aktivít predstavujú objektovú alternatívu vývojových diagramov

b) aktivity sú zjednodušené stavy, nie sú však atomické a neprerušiteľné

c) prechody sú aktivované ešte pred dokončením aktivity

d) zodpovednosť za jednotlivé aktivity je možné znázorniť pomocou elementov plaveckých dráh (swimlan

e) diagram aktivít môže byť asociovaný k ľubovoľnému elementu a môže tak popísať jeho správanie 

a) čas

b) objekty

c) ani jedna z možností nie je správna

d) čas aj objekty 

a) áno, vždy 

b) nie, ale ak chceme môžme si merítko zaviesť 

c) ani jedna z možností nie je správna

d) len pre prvý objekt 

a) activity diagram

b) class diagram

c) use case diagram 

d) interaction diagram 

a) len DS na SD, opačne nie

b) áno, obojsmerne

c) nie

d) len SD na DS, opačne nie 

a) <<new>> 

b) <<create>>

c) <<broadcast>>

d) <<make>>

a) každá správa je spojená s komunikačnou linkou (instance link) 

b) každá správa môže mať viacero komunikačných liniek

c) inštančná linka môže mať viacero správ

d) pri zničení komunikačnej linky sa zničia všetky správy, ktoré sú s ňou spojené

a) diagramy sekvencie

b) diagramy spolupráce

c) diagramy stavov

d) ani jedna z možností nie je správna 

a) Inception, Elaboration, Construction, Transition 

b) Inception, Elaboration 

c) Elaboration, Construction 

d) Inception, Construction, Transition 

a) statické a dynamické

b) rýchle a pomalé 

c) krátkodobé a dlhodobé

a) Diagram dátových štruktúr

b) Priebežný diagram prieskumníka

c) Entitno-relačný diagram

a) Diagram životného cyklu entít

b) Entitno- relačný diagram

c) Model Prieskumník

d) Modelovanie referenčnej integrity – rozšírenie ERD 

a) stĺpcami

b) tabuľkami 

c) atribútami 

d) entitno-relačným diagramom

a) 2:1

b) 1:N

c) M:N 

d) 2:N 

a) atribútne 

b) doménové 

c) obmedzenie veľkost

d) referenčné 

e) entitné 

a) diagramy interakcií 

b) stavové diagramy

c) diagramy aktivít 

d) diagramy tried 

a) stavový diagram

b) sekvenčný diagram

c) diagram aktivity

d) diagram spolupráce 

a) synchrónne 

b) asynchrónne

c) statické

d) dynamické 

a) Objekty si môžu posielať správy a diagram zobrazuje ich časovú postupnosť

b) Objekty si môžu posielať správy ale diagram nezobrazuje ich časovú postupnosť

c) sekvenčný diagram a diagram spolupráce sú izomorfné 

d) sekvenčné diagramy sú menej vhodné pre zdôraznenie časových súvislostí interakcií 

a) objekt

b) Sprava

c) čiara života

d) agregácia

a) sú inštanciou triedy

b) môžu byť trvalé alebo dočasné 

c) môžu byť len trvalé 

d) nemôžu posielať správy sami sebe 

a) objekt 

b) kompozícia 

c) čiara života 

d) agregácia

a) patrí k diagramom interakcií

b) objekty si môžu posielať správy, ale diagram nezobrazuje ich časovú postupnosť 

c) sekvenčný diagram a diagram spolupráce sú izomorfné 

d) diagramy spolupráce sú menej vhodné pre zdôraznenie časových súvislostí interakcií

a) Internou entitou v rámci systému

b) Môže vyjadrovať rolu užívateľa, rolu ďalšieho systému, ktorý sa dotýka hraníc vášho systému.

c) Presne zachycujú funkčnosť informačného systému.

d) Voči systému je vlastne externá entita

a) V systéme môže jeden aktér vykonávať viacero prípadov použitia.

b) V systéme môže jeden aktér vykonávať len jeden prípad použitia

c) Jeden prípad použitia môže byť vykonávaný v systéme viacerými aktérmi

d) Jeden prípad použitia môže byť vykonávaný v systéme len jedným aktérom. 

a) Triedy

b) Aktéri 

c) Prípady použitia

d) Balíky 

a) Use Case A zahŕňa Use Case B.

b) Use Case B zahŕňa Use Case A

c) Use Case B rozširuje Use Case A.

d) Use Case A rozširuje Use Case B

a) Základný prípad použitia je sám o sebe úplne sebestačný.

b) Základný prípad použitia nie je bez rozširujúceho prípadu použitia kompletný.

c) Rozširujúci prípad použitia ňou pridáva nové chovanie do základného prípadu použitia.

d) Používa sa tam, kde existuje rovnaká alebo podobná časť sekvencie scenára.

a) USCD, SEQD, COLD, ACTD, STAD 

b) USCD, SEQD, COLD, ACTD

c) USCD, ACTD, STAD

d) COLD, ACTD, STAD

a) asociácia, generalizácia

b) asociácia, závislosť 

c) asociácia, závislosť, generalizácia 

d) závislosť, generalizácia

a) časová os, objek

b) objekt, časová os existencie objektu, sledovaný riadený úsek, čas

c) čas, sledovaný riadený úsek, objek

d) časová os, sledovaný riadený úsek, objek

a) objekt, interakcia

b) objekt, správa 

c) objekt, sekvencia, správa

d) objekt, správa, sekvencia, interakcia 

a) aktér, objekt, hranice systému

b) aktér, objekt, činnosť

c) aktér, prípad použitia, hranice systému, asociácia, generalizácia

d) aktér, asociácia, objekt

a) popisuje správanie systému

b) popisuje všetky možné stavy, ktoré môžu nastať

c) reprezentuje jednu triedu

d) reprezentuje správanie všetkých tried v jednom diagrame

a) entry, do, exit

b) entry, activity, exit

c) activity, do 

d) entry, exit

a) sa dajú nahradiť stavovými a interakčnými diagramami

b) sa nedajú nahradiť stavovými a interakčnými diagramami

c) môžu znázorňovať podmienené a paralelné činnosti 

d) môžu znázorňovať iba podmienené činnosti 

a) čas 

b) objekty 

c) správy

d) metódy

a) poradie vysielania správy

b) množstvo kópií správy

c) id príjemcu správy

d) počet argumentov správy

a) rekurzívnej správy

b) asynchrónnej správy

c) synchrónnej správy

d) nikdy nečaká na odpoveď

a) diagram tried (class diagram) 

b) diagram prípadov použitia (use case)

c) diagram spolupráce (collaboration diagram) 

d) diagramy interakcie (interaction diagrams) 

a) činnosť 

b) služba

c) aktér

d) závislosti 

a) od konkrétnejšieho k všeobecnejšiemu

b) od aktéra ku službe

c) od služby ku aktérovi 

d) nemá orientáciu

a) na modelovanie celkovej štruktúry systému v pamäti

b) na modelovanie toku riadenia organizáciou 

c) na modelovanie komunikačných kanálov systému

d) na modelovanie toku riadenia v časovej následnosti