MIS KASU ON KASUTUSMALLIDE MUDELIST (USE CASE MODEL)? (0)

Q: MIS ON KASUTUSMALLID?

Vastus leiad õppematerjalist: MIS KASU ON KASUTUSMALLIDE MUDELIST (USE CASE MODEL)?

Q: MIS KASU ON KASUTUSMALLIDE MUDELIST USE-CASE MODEL?

Vastus leiad õppematerjalist: MIS KASU ON KASUTUSMALLIDE MUDELIST (USE CASE MODEL)?

Eesti Infotehnoloogia Kolledzh - Informaatika - Infoharidus

1 Hindamata

Esitatud küsimused

MIS ON KASUTUSMALLID?
MIS KASU ON KASUTUSMALLIDE MUDELIST USE-CASE MODEL?

EESTI INFOTEHNOLOOGIA KOLLEDŽ
Andrei Belokurov
MIS KASU ON KASUTUSMALLIDE MUDELIST (USE CASE MODEL)?
Referaat
INFOTEHNOLOOGIA SÜSTEEMIDE ANALÜÜSI ÕPPEKAVA
Juhendaja : A. Mulin
Tallinn 2011

Sisu

1.MIS ON KASUTUSMALLID? 3
2.USE CASE DIAGRAMM 3
2.1.Kasutusmallide diagrammide üldinfo 3
2.2.Näitlejad 4
2.3.Kasutusmallid 4
2.4.Suhted 5
3.MIS KASU ON KASUTUSMALLIDE MUDELIST (USE-CASE MODEL)? 7

MIS ON KASUTUSMALLID?

Iga programmisüsteemi loomise eesmärk on sellise produkti loomine, mis aitab kasutajal teostada oma igapäevaseid tegevusi. Taoliste programmide loomisel kõigepealt määratakse nõudmised, mida antud programm peab täitma. Nende eesmärgid on:

väljatöötaja, tellija ja kasutaja vaheline kokkulepe sellest, mida peab tegema programmisüsteem;
väljatöötaja parema arusaamise saavutamine PS käitumisest;
süsteemse funktsionaalsuse piiramine;
aluse loomine projekti väljatöötamiseks;
kasutaja interface määratlemine.

Kuid kui paluda kasutajal loetleda need nõudmised paberil, siis tihti võib tulemusena saada funktsioonide loetelu, mille järgi on raske arvata kas tulevane süsteem täidab oma eesmärgi ja kas see saab lihtsustada kasutaja tööd. Ei ole selge, millised funktsioonid on kelle jaoks olulisemad.
Selleks, et aru saada kuidas süsteem töötab, tihti kasutatakse süsteemi funktsionaalsuse kirjeldust läbi kasutusmallide (Use Case). Kasutusmallid – on toimingute järjepidevuse kirjeldamine, mida süsteem teostab vastuseks kasutajate või teiste programmisüsteemide välismõjudele. Kasutusmallid peegeldavad süsteemi funktsionaalsust, lähtudes tähenduslikku tulemuse saamisest kasutaja poolt. Seega võimaldavad nad korrastada funktsioone, saadava tulemuse tähtsust silmas pidades.

USE CASE DIAGRAMM

Kasutusmallide diagrammide üldinfo

Kasutumallide diagrammidel näidatakse näitlejaid ja kasutusmalle, kelle vahel on suhe. Siin saab samuti näidata ka teisi elemente UML (näiteks, klassid võivad näidata millised olemused sündivad ja on kasutatud konkreetsetes ВИ´s – vt pilt.1).
Operaator – avada uus arve – füüsilise isiku arve
Joonis 1. Kasutusmallide diagramm

Näitlejad

Näitlejaks nimetame PS-välise olemuse, mis saab mõjuda vastastikku süsteemiga. Näitlejateks võivad olla nii inimesed kui ka välissüsteemid või seaded . Tuleb alati mäletada, et näitleja ei ole konkreetne inimene või seade, vaid roll (amet), mida näitleja mängib programmisüsteemi suhtes. Näiteks näitlejaks saavad olla kõik raamatupidamisosakonna töötajad. Samas üks konkreetne inimene saab täita mitut rolli süsteemi suhtes. saab olla sama nimega näitleja, kuid võib kasutada süsteemi (st täita tavalise raamatupidaja ülesandeid). Samal ajal näitlejad ei ole ilmtingimata inimesed. Kui PS peab sooritama mingisuguseid toiminguid teatud ajal, siis näitlejaks, kes algatab nende toimingute sooritamist, võib olla ka süsteemne taimer .
Näitlejate leidmine on esimeseks sammuks iga süsteemi kasutamise määramisel (nii reaalse, kui ka programmisüsteemi). Iga välistoimingu allikas, millega süsteem peab kokku puutuma , on esitatud näitlejana. Näitlejal peab olema nimi, mis peegeldab tema rolli. Diagrammides Use Case on näitleja märgitud inimese figuuriga, kuid kuju määratlemisel saab kasutada ka teisi stereotüüpe.

Kasutusmallid

Näitleja ja süsteemi vastastikkusel mõjul, kus viimane täidab rida ülesandeid, moodustatakse süsteemi kasutusmalli (use case). Iga näitleja võib kasutada süsteemi erinevalt, st erinevate ВИ moodustamisi initsieerida. Seega, iga ВИ on põhimõtteliselt mingisugune funktsionaalne nõue süsteemile (mis omakorda võib olla jagatud mitmeks väiksemaks osaks). Oma olemuselt ВИ ei ole konstruktsioon , mis realiseerub otseselt programmis . Selle käitumine realiseerub klasside ja komponentide kujul.
ВИ kirjeldab seda mida teeb PS, kuid mitte seda kuidas see seda teeb. Iga ВИ tavaliselt eeldab mitme süsteemi käitumisvariandi olemasolu (sündmuste vool), millest üks on põhiline, ja teised alternatiivsed. Põhiline sündmuste vool määrab süsteemi toimingute järjestuse, mis on suunatud antud ВИ peamise tulemuse funktsiooni täitmisele. Alternatiivsed vood kirjeldavad süsteemi käitumist ainult eriolukordades, näiteks vigade korral. Sündmuste voogude kirjeldused võivad olla nii tekstiformaadis kui ka UML diagrammide abil, mida vaadetakse üle hiljem.
Parim viis ВИ leidmiseks on üle vaadata, mida iga näitleja nõuab süsteemilt. Tuleb pidada meeles, et süsteem eksisteerib ainult kasutajate jaoks ning seda tuleb ehitada nende vajadustest lähtudes.
Iga ВИ´l peab olema nimi, mis vastab selle otstarbele. Nimi peab peegeldama seda, mida saavutatakse koostöös näitlejatega. ВИ diagrammidel see on märgitud ovaaliga.

Suhted

Assotsiatsioon – ainuke võimalik side ВИ ja näitlejate vahel. See näitab, et näitleja ja ВИ suhtlevad üksteisega, saates ja võttes vastu sõnumeid. Kui assotsiatsioon on suunatud, näitab see sõnumi saatmissuunda. Joonisel 2 operaator initsieerib ВИ poolt alustatud uue arve avamist.
Suhted ВИ´de vahel on mõeldud selleks et saada ВИ´st sellele iseloomulikke fragmente, mida on võimalik vaadelda kui eraldi abstraktseid ВИ´sid. Sellisteks osadeks võivad olla üldised fragmendid , mittekohustuslikud fragmendid ja erandid.
Kui kaks või enam ВИ on struktuuri ja käitumise poolt sarnased, siis otstarbekas on eraldada üldfragment ja ehitada uus põhi-ВИ. Alg-ВИ´d on põhi- ВИ suhtes tütar- ВИ´d. Tütar- ВИ pärib oma käitumist emavariandis kirjeldatust. Üldistamissuhe kahe ВИ vahel tähendab, et kui rakendatakse tütar- ВИ´d, siis peab olema rakendatud ja põhi- ВИ. Üldiselt, et põhi- ВИ loomune oleks otstarbekas, sellel peab olema vähemalt kaks tütar- ВИ´d. Erandiks on juhtumid kus on olemas kaks ВИ ja üks neist on teise detailiseering, kuid mõlemad saavad toimida iseseisvalt. Diagrammidel on selline suhe näidatud üldismamissuhtena (vt joonis 2b).
Sisselülitamissuhe, mida märgitakse stereotüübiga , tähendab, et selleks et täiel määral teostada põhi- ВИ, on vajalik ka sisselülitatava variandi sooritamine. Üldiselt sisselülitatavate ВИ´de eristamine on otstarbekas sellisel juhul, kui nad moodustavad mitu baasvarianti. Üldistamissuhest teab ainult põhiline kasutusvariant, mitte sisselülitatav. Sisselülitamine on märgitud punktiirnoolega, mis on suunatud põhi- ВИ juurest sisselülitatava poole (vt joonis 2b).
Juhul, kui ВИ´l on fragmendid, mis on oma loomuselt mittevajalikud või ei ole erandid ja samas ei aita ВИ peaeesmärkidest aru saada, siis need fragmendid võib viia sulgudest välja, loodes uue, laiendava ВИ. Algvariandist saab baasvariant, mis omakorda ühendub laienduse suhtega. Laiendus on märgitud punktiirnoolega, mis on suunatud laiendatava ВИ poole (vt joonis 2а, 2b).
Operaator – avada arve-avada füüsilise isiku arve-avada juriidilise isiku arve
Veateade – arve kontroll
Joonis 2а. ВИ diagrammi näide
Näitleja aktiveerib ВИ teostamise . Lähtuvalt operaatori poolt määratud tüübist, teostatakse kas või , mis on esimese laiend. Arve avamine hõlmab selle kontrolli ja vea avastamisel – sõnumi saatmise Operaatorile.
Operaator – Väljastada veateade- arve kontroll
Avada füüsilise isiku arve- avada arve
Avada juriidilise isiku arve
Joonis 2b. ВИ diagrammi näide
Joonis 2a analoog. Näitlejal on kaks töörežiimi. Ta aktiveerib kas või . Iga arve avamine hõlmab tööde teostamist, mis on ВИ´s ette nähtud, mis koosneb kahe alg ВИ käitumist.

MIS KASU ON KASUTUSMALLIDE MUDELIST (USE-CASE MODEL)?

Kasutusmallid on eelkõige mõeldud süsteemi funktsionaalsete nõuete määramiseks ja kogu väljaarendamisprotsessi juhtimiseks . Kõik põhilised toimingud , nagu analüüs, projekteerimine, testimine , täidetakse kasutusmallide alusel. Analüüsi ja projekteerimise käigus kasutusmallid võimaldavad aru saada sellest, kuidas tulemused, mida kasutaja soovib saada, mõjutavad süsteemi arhitektuuri, ja kuidas peavad käituma süsteemi komponendid, selleks et kasutajale vajalikku funktsionaalsust realiseerida.
Varem kirjeldatud kasutusmallid võimaldavad testimise käigus lihtsamalt hinnata kasutajate nõuete realiseerimistäpsust ja viia läbi nende nõuete kontrolli.
Pretsedentide kasutamise strateegia nõuete defineerimisel määrab lisaks küsimusele „Mida kasutajad ootavad antud süsteemilt?“, ka küsimuse „Mida süsteem peab tegema konkreetse kasutaja jaoks?“. Selline lähenemine võimaldab otsida funktsioone, mis on kasutajatele vajalikud ja eraldada need funktsioonid ja võimalused, mis ei saa aidata kasutajatel täita oma igapäevaseid ülesandeid.
http://www.computerbooks.ru/%D0%BA%D0%BD%D0%B8%D0%B3%D0%B0/%D1%81%D0%B0%D0%BC%D0%BE%D1%83%D1%87%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%20uml/54
www.caseclub.ru/articles/use_case.html

.DOCX Laadi alla originaalfail 8 lk · .docx · 5 allalaadimist

MIS KASU ON KASUTUSMALLIDE MUDELIST-USE CASE MODEL- #1

MIS KASU ON KASUTUSMALLIDE MUDELIST-USE CASE MODEL- #2

MIS KASU ON KASUTUSMALLIDE MUDELIST-USE CASE MODEL- #3

MIS KASU ON KASUTUSMALLIDE MUDELIST-USE CASE MODEL- #4

MIS KASU ON KASUTUSMALLIDE MUDELIST-USE CASE MODEL- #5

MIS KASU ON KASUTUSMALLIDE MUDELIST-USE CASE MODEL- #6

MIS KASU ON KASUTUSMALLIDE MUDELIST-USE CASE MODEL- #7

MIS KASU ON KASUTUSMALLIDE MUDELIST-USE CASE MODEL- #8

50 punkti Autor soovib selle materjali allalaadimise eest saada 50 punkti.

~ 8 lehte Lehekülgede arv dokumendis

2014-10-05 Kuupäev, millal dokument üles laeti

5 laadimist Kokku alla laetud

0 arvamust Teiste kasutajate poolt lisatud kommentaarid

ZlajaMolekula Õppematerjali autor

näitleja kasutusmallid operaator case raamatupidaja fragmendid

Kasutatud allikad

https://www.computerbooks.ru/%D0%BA%D0%BD%D0%B8%D0%B3%D0%B0/%D1%81%D0%B0%D0%BC%D0%BE%D1%83%D1%87%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%20uml/54

Sarnased õppematerjalid

pdf

Enesetestid teemadest 2-10

Mis on elutsükli teine samm? Vali üks: a. Infosüsteemi teostus b. Infosüsteemi väljavalimine ja planeerimine c. Infosüsteemi analüüs d. Infosüsteemi projekteerimine e. Infosüsteemi kasutamine Küsimus 1 Kuidas nimetakse inimesi, kes tegelikult iga päev kasutavad süsteemi oma tööülesannete täitmiseks? Vali üks: a. Süsteemi omanikud b. Ei ole nimetatud c. Süsteemi disainerid d. Süsteemi analüütikud e. Programmeerijad Küsimus 2 Kriitiline tee on : Vali üks: a. projektiga seotud tegevuste jada, mille läbimise tulemusena tekkib kriis b. meetod, mis võimaldab vähendada projektiriske c. Ei ole nimetatud d. maantee, mis on kiiruskaameraid ja politseid täis e. meetod, mis arvutab projekti lõpetamise päeva, lähtudes ülesannete kestvusest ja järjekorrast Küsimus 3 Tööjaotamise struktuur (WBS, work breakdown structure) tähendab Vali üks: a. Töötellimist välispartnerite käest b

Infosüsteemide analüüs ja projekteerimine

docx

Süsteemianalüüs - Kolmanda loengutöö konspekt

1. Tarkvara Nõuete analüüs Äri(...tegelt ka või see on kuradi esimene vastus??)modelleerimise (distsiblinni) tulemused annavad konteksti ning “keele” (põhimõistestiku) tarkvara nõuete püstitamiseks. Iteratiivses arendusprotsessis UP toimub tarkvara nõuete püstitamine ja analüüs põhiliselt tarkvara kasutusjuhtude kirjutmise, modelleerimise ja analüüsimise kaudu. 2. Kasutusjuhtude mudel ehk (kui te olete inglise keeles väga sitt juhuslikult) Use Case Model UP defineerib Use Case mudeli nõuete analüüsi distsiblinni sees. Use Case mudel on kõikide kasutusjuhtude hulk: süsteemi funktsionaalsuse(kasutusjuhud) ja keskkonna(tegutsejad) mudel Eesmärgid ja kasutuslood Tellijad ja lõppkasutajad omavad eesmärke (goals, UP-s needs, sest UP on needy motherfucker) ning soovivad, et süsteem aitaks neid täita. Kasutusjuhud on jutustused süsteemi kasutamisest nende eesmärkide täitmiseks. Näide: Ülikoolis käimine:

Süsteemianalüüs

Kino infosüsteemi strateegilise arenduse dokumentatsioon

110

doc

Kino infosüsteemi strateegilise arenduse dokumentatsioon

TALLINNA TEHNIKAÜLIKOOL Informaatikainstituut Infosüsteemide õppetool Iseseisev töö aines 'Infosüsteemide projekteerimine': Kino infosüsteemi strateegilise arenduse dokumentatsioon Teostajad: Indrek Kempi (001546) Pärtel Lias (010617) Eero Ringmäe (010636) Õpperühmad: LAP51 ja LAP 52 Juhendaja: Lea Elmik Tallinn 2003 Autorideklaratsioon:

Infosüsteemi projekteerimine

204

docx

Süsteemianalüüsi kontrolltöö 1

M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014 IDU 5360 SÜSTEEMIANALÜÜS Loeng 1. Sissejuhatus (kontseptuaalsesse) süsteemianalüüsi.  Aine fookus  Aine taust  Eesmärgid ja õpiväljundid  Aine korraldus Aine fookus KONTSEPTUAALNE SÜSTEEMIANALÜÜS  VALDKONNA ANALÜÜS  TARKVARA NÕUETE ANALÜÜS  ITERATIIVNE ARENDUSPROTSESS Fookus: Kontseptuaalse süsteemanalüüsi meetodite rakendamine valdkonna ning tarkvara nõuete detailseks analüüsiks iteratiivses arendusprotsessis Aine taust Analüüsi ained: 1. Sissejuhatus infosüsteemidesse (IDU 3350) või Modelleerimine (IDU 3355); -> 2. -> Süsteemianalüüs (IDU 5360) -> 3. -> Infosüsteemi strateegiline analüüs (idu0021) ehk Ettevõtte äriarhitektuur (idu1321) Aine on eelduseks (OIS)

Modulatsioon

docx

Sissejuhatus infosüsteemidesse

Sissejuhatus infosüsteemidesse · Ettevõtte/organisatsiooni mõiste Paar näidet organisatsiooni definitsioonist: organiseeritud ja koordineeritud inimeste grupp koos vastavate tööviiside, reeglite, rutiinide ja vastastike ootustega, kes koos töötades üritavad saavutada ühiseid eesmärke inimeste sotsiaalne üksus, mis on süstematiseeritult struktureeritud ning hallatud (juhitud), et täita vajadusi või püüelda kollektiivse eesmärgi poole jätkusuutlikul viisil Ettevõtet defineeritakse kui vastastikuses sõltuvuses olevate ressursside (inimesed, protsessid, vastutused ja alluvusseosed, toetavad tehnoloogiad ja kapital) eesmärgipärast kombinatsiooni (n.ö. võrku), mis on: 1. vastastikuses koostoimes selleks, et koordineerida funktsioonide täitmist; vahetada informatsiooni; hankida rahastamist; luua töövooge; teha otsuseid jne 2

Infoharidus

282

pdf

Mikroprotsessortehnika

TALLINNA TEHNIKAÜLIKOOL ELEKTRIAJAMITE JA JÕUELEKTROONIKA INSTITUUT ROBOTITEHNIKA ÕPPETOOL MIKROPROTSESSORTEHNIKA TÕNU LEHTLA LEMBIT KULMAR Tallinn 1995 2 T Lehtla, L Kulmar. Mikroprotsessortehnika TTÜ Elektriajamite ja jõuelektroonika instituut. Tallinn, 1995. 141 lk Toimetanud Juhan Nurme Kujundanud Ann Gornischeff Autorid tänavad TTÜ arvutitehnika instituudi lektorit Toomas Konti ja sama instituudi dotsenti Vladimir Viiest raamatu käsikirjas tehtud paranduste ja täienduste eest.  T Lehtla, L Kulmar, 1995  TTÜ elektriajamite ja jõuelektroonika instituut, 1995 Kopli 82, 10412 Tallinn Tel 620 3704, 620 3700. Faks 620 3701 ISBN 9985-69-006-0 TTÜ trükikoda. Koskla 2/9, Tallinn EE0109 Tel 552 106 3

Tehnikalugu

210

pdf

Tarkvaratehnika kordamisküsimused

TARKVARATEHNIKA KORDAMISKÜSIMUSED 1. Mis on tarkvaratehnika? Software engineering ! “Engineers Australia” definitsioon: Tarkvaratehnika on tiimide poolt rakendatav distsipliin tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara mis rahuldab kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel. IEEE definitsioon: Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale.

Tarkvaratehnika

docx

Majandusinfosüsteemid

Majandusinfosüsteemid 1. Selgita süsteemse käsitluse põhimõtteid. · Süsteemne käsitlus põhineb arvamusel, et süsteemi elemendid toimivad erinevalt, kui need on keskkonnast või tervikust eraldatud. · Mõtlemisviis, mis käsitleb meid ümbritsevas maailmas ja meis endis toimuvat/leiduvat süsteemidena ja süsteemidesse kuuluvana. · Näiteks: majandussüsteemid (kapitalism, turumajandus), õigussüsteem jne. 2. Süsteemi definitsioon, selgita (kasuta joonist). · Süsteem omavahel seotud objektide terviklik kogum, mis on mitteamorfne ja terviklik. Süsteemi iseloomustavad elemendid ehk objektid, sidemed, hierarhia ja käitumine. Sageli on süsteemi piiritlemine keeruline. · Süsteemi struktuur ja omadused peavad garanteerima süsteemi eesmärkide täitmise. · Joonised: