Embed Size (px)
Citation preview
Projektovanje informacionih sistema
dr Rade Matić
Beogradska akademija poslovnih i
umetničkih strukovnih studija
UML 2.0
UML 2.0•Slučaj korišćenja (SK) je nešto što
obezbeđuje neke merljive rezultate korisniku
ili spoljašnjem sistemu.
•SK je situacija gde se vaš sistem koristi da
ispuni jedan ili više korisničkih zahteva. On
prikazuju samo deo funkcionalnosti koju
obezbeđuje naš sistem.
•SK je srce našeg modela, jer oni utiču i vode
sve ostale elemente u projektovanju. Oni
prikazuju zahteve i ostale poglede na model, a
onda prikazuju kako su ti zahtevi ispunjeni.
SK je odlična startna pozicija za svaki OO razvoj sistema, analize, projektovanje (dizajn), testiranje i dokumentaciju.
Oni objašnjavaju zahteve sistema striktno gledajući sa spoljašne strane. Preciziraju vrednost koju sistem isporučuje korisniku.
Zbog toga što SK predstavljaju sistemske funkcionalne zahteve, oni bi trebali biti prvi ozbiljan rezultat iz našeg modela nakon što je projekat započet.
UML 2.0
UML 2.0
<<include>><<include>>
Komitent <<extend>>
Prenos
Podizanje
Ulaganje Provera kartice Provera tajne šifre
Statistika transakcija
Novčana transakcija
On line Help
<<extend>>
PODIZANJE NOVCA: osnovni scenario
1. Ubaci karticu: Komitent ubacuje karticu u automat.
2. Provera kartice: Automat čita karticu i proverava da li je prihvatljiva. Ako je prihvatljiva,
zahteva se od komitenta da unese “tajnu šifru”.
3. Unos šifre: Komitent unosi tajnu šifru.
4. Provera šifre: Sistem proverava unetu šifru komitenta. Ako je šifra korektna zahteva se
da korisnik izabere transakciju.
5. Izbor tipa transakcije: Komitent bira “Podizanje novca” i dobijaju se komitentovi
brojevi računa koji se prikazuju na ekranu automata.
6. Izbor računa: Komitent bira račun.
7. Unos iznosa novca: Komitent unosi iznos koji podiže.
8. Potvrda transakcije: Komitent potvrđuje transakciju. Automat šalje računaru banke
zahtev za podizanje datog iznosa sa datog računa.
9. Izbaci karticu: Automat vraća karticu komitentu.
10. Izbaci novac: Automat izbacuje komitentu traženi iznos novca.
11. Izbaci izveštaj: Automat izdaje komitentu izveštaj.
PODIZANJE NOVCA: alternativna scenarija
2.1. Kartica se vraća korisniku sa zvučnim signalom.
4.1. Odgovarajuća poruka se prikazuje na ekranu i daje se šansa korisniku da je ponovo
unese. Dozvoljava se tri pokušaja, a zatim se vraća kartica korisniku.
5.1. Komitent može da prekine transakciju. Poništiće se svi dotadašnji efekti i vratiti kartica
korisniku.
SK precizira samo ŠTA naš sistem treba da radi, tj.
funkcionalne zahteve. Oni ne preciziraju
sistemske nefukcionalne zahteve.
Nefunkcionalni zahtevi često uključuju
performanse sistema, programske jezike, opise
korisničkih interfejsa, ograničenja za dizajn i
implementaciju.
Veoma je bitno za projektante da što pre
identifikuju sve moguće nedoumice u zahtevima,
po mogućnosti još u ranoj fazi u razvoja projekta.
UML 2.0
Dobro je kad se zahtevi predstave kao SK i
kad korisnik vidi da zahtevi imaju malo ili
uopšte nemaju vrednost za sistem.
Ako korisnik može da odbaci nepotrebne
zahteve, uštediće sebi vreme i novac. Jednom
kada se prioriteti i rizici dodele za SK, vaš SK
se može dodeliti timu ili pojedincima da bi se
implementirali.
S obzirom da SK predstavlja opipljivu
korisničku vrednost, može se pratiti napredak
projekta kroz praćenje implementacije SK.
UML 2.0
Ako i kada projekat dospe u problem sa
planovima, neki SK se može odbaciti ili
odložiti da bi se postigli oni koji su bitniji
tog trenutka.
Poslednje ali ništa manje bitnije, SK takođe
pomaže u izradi načina testiranja sistema.
SK obezbeđuje odličnu startnu poziciju za
izgradnju naših slučaja testiranje i
procedura jer oni precizno prikazuju
korisničke zahteve i uspešne kriterijume.
UML 2.0
Može konstatovati da postoje dve vrste ovih
dijagrama:
◦ dijagrami slučajeva korišćenja - DSK (Use
Case Diagrams) i
◦ poslovni dijagrami slučajeva korišćenja -
PDSK (Business Use Case Diagrams).
UML 2.0
PDSK treba da daju odgovor na pitanje „Šta
organizacija radi?“. Ovi PDSK se
izvršavaju u fazi Analize sistema i zahteva
korisnika.
DSK treba da daju odgovor na pitanje: „Šta
sistem radi?“. Ovo se radi u fazi
Specifikacije aplikacija.
UML 2.0
Pomoću DSK predstavljaju se funkcije sistema
koje će biti automatizovane, a pomoću PDSK se
predstavljaju automatizovane i manuelne
funkcionalnosti poslovnog sistema.
Komponente ovih dijagrama su akteri, uloge,
slučajevi korišćenja (SK) i relacije (Veze).
DSK i PDSK služe da bi se prikazale konkretne
funkcionalnosti sistema, odnosno organizacije.
UML 2.0
Ovi dijagrami predstavljaju vodilju za
kompletan proces razvoja softvera, pa se
često za razvoj zasnovan na UML-u kaže
da je vođen i usmeren slučajevima
korišćenja.
Kao što je rečeno, SK se koristi i za
Analizu sistema (izgradnja Poslovnog
modela sistema) i za specifikaciju
aplikacija.
UML 2.0
Sa tačke gledišta Analize sistema i izgradnje
njegovog Poslovnog modela, PDSK se
definiše kao specifikacija interakcije
između poslovnog sistema i jednog ili više
aktera, zajedno sa opisom akcija sistema
u ovoj interakciji.
Sa tačke gledišta specifikacije aplikacija
DSK se definiše kao specifičan način na
koji će akter da koristi jednu buduću
aplikaciju IS koji se projektuje.
UML 2.0
Akter se i u jednom i u drugom slučaju
definiše kao uloga koju igra neki entitet
van sistema u jednoj ili više interakcija sa
sistemom.
Već iz ovih definicija je očigledno da u fazi
Analize sistema, SK opštije opisuju
celokupan sistem, dok u fazi Specifikacije
aplikacija daju detaljan opis jedne
aplikacije.
UML 2.0
Slučaj korišćenja predstavlja skup sekvenci
događaja. Jedna sekvenca događaja se
naziva scenario.
Postoji jedan osnovni scenario i skup
mogućih izuzetaka, proširenja, odnosno
alternativnih funkcionisanja. Uobičajeno je
da se posebno daje opis osnovnog scenarija,
a posebno opis svih alternativnih načina
funkcionisanja.
UML 2.0
UML 2.0
<<include>><<include>>
Komitent <<extend>>
Prenos
Podizanje
Ulaganje Provera kartice Provera tajne šifre
Statistika transakcija
Novčana transakcija
On line Help
<<extend>>
PODIZANJE NOVCA: osnovni scenario
1. Ubaci karticu: Komitent ubacuje karticu u automat.
2. Provera kartice: Automat čita karticu i proverava da li je prihvatljiva. Ako je prihvatljiva,
zahteva se od komitenta da unese “tajnu šifru”.
3. Unos šifre: Komitent unosi tajnu šifru.
4. Provera šifre: Sistem proverava unetu šifru komitenta. Ako je šifra korektna zahteva se
da korisnik izabere transakciju.
5. Izbor tipa transakcije: Komitent bira “Podizanje novca” i dobijaju se komitentovi
brojevi računa koji se prikazuju na ekranu automata.
6. Izbor računa: Komitent bira račun.
7. Unos iznosa novca: Komitent unosi iznos koji podiže.
8. Potvrda transakcije: Komitent potvrđuje transakciju. Automat šalje računaru banke
zahtev za podizanje datog iznosa sa datog računa.
9. Izbaci karticu: Automat vraća karticu komitentu.
10. Izbaci novac: Automat izbacuje komitentu traženi iznos novca.
11. Izbaci izveštaj: Automat izdaje komitentu izveštaj.
PODIZANJE NOVCA: alternativna scenarija
2.1. Kartica se vraća korisniku sa zvučnim signalom.
4.1. Odgovarajuća poruka se prikazuje na ekranu i daje se šansa korisniku da je ponovo
unese. Dozvoljava se tri pokušaja, a zatim se vraća kartica korisniku.
5.1. Komitent može da prekine transakciju. Poništiće se svi dotadašnji efekti i vratiti kartica
korisniku.
UML 2.0
Najpre radi struktuiranja i pojednostavljivanja opisa
slučaja korišćenja, uvode se veze:
•Asocijacija - ukazuje na postojanje veze pojavljivanja
dva tipa elemenata koji su u asocijaciji.
•Generalizacija - veza opštijeg i specifičnijeg slučaja
korišćenja koji nasleđuje opis opštijeg ili veza između
opštijeg i specifičnijeg aktera koji nasleđuje sve
interakcije opštijeg sa sistemom.
•<<extend>> - stereotip veze zavisnosti koja
referencira (ubacuje) moguće dodatno "ponašanje"
opisano u posebnom slučaju korišćenja.
•<<include>> - stereotip veze zavisnosti koja opisuje
ubacivanje nekog, posebno opisanog, slučaja korišćenja
u posmatrani slučaj korišćenja.
UML 2.0
Jedan slučaj korišćenja predstavlja jedan
atomski proces (funkciju) nekog poslovnog
sistema. Ako bismo poredili DSK i SSA
(Strukturna Sistemska Analiza), mogli bismo da
uspostavimo ekvivalenciju između osnovnog
slučaja korišćenja i primitivnog procesa.
Međutim, za razliku od SSA, Dijagram
slučajeva korišćenja ne sadrži koncept
dekompozicije procesa, osnovni koncept za
istovremeno jasno i detaljno opisivanje sistema.
UML 2.0
•Postavlja se pitanje kako projektanti, u jednom
složenom sistemu, mogu direktno, bez
dekompozicije, da identifikuju veliki broj
osnovnih slučajeva korišćenja.
•Nepostojanje jasno definisanog mehanizma za
dekompoziciju složenih procesa je osnovni
nedostatak Dijagrama slučajeva korišćenja u
izgradnji poslovnih modela.
UML 2.0
Zbog toga se u različitim pristupima modelovanja
poslovnih procesa ugrađuju različiti mehanizmi
dekompozicije složenih procesa.
Na primer, u modelovanju poslovnih procesa u
elektronskom poslovanju koristi tzv. UN/CEFACT
(United Nations Centre for Trade Facilitations and
Electronic Business) Modelling Methodology (UMM)
koji dekomponuje sistem preko specifičnih stereotipova
paketa.
UML 2.0
Paket je opšti mehanizam za grupisanje bilo kojih
elemenata modela u grupe. Na sledećoj slici je prikazan
primer obrađen preko Strukturne sistemske analize
(SSA).
Za razliku od SSA gde se na svim nivoima
dekompozicije koristio samo koncept procesa, ovde se
definišu i specifični stereotipovi poslovnih procesa.
Celokupan model se predstavlja paketom
<<Business Operation Map>> koji predstavlja
agregaciju svih podprocesa i okvirno odgovara
Dijagramu konteksta u SSA.
UML 2.0Agencija za promociju
<<BusinessOperationsMap>>
Promocija (marketing)<<Process Area>>
Konkurisanje za promotera<<Process Area>>
Ang. promotera << Business Process>>
Ang. klijenta<< Business Process>>
Intervju<< Business Process>>
Analiza kandidata<< Business Process>>
Obuka promotera<<Process Area>>
Angažovanje<<Process Area>>
Prijavljivanje<< Business Process>>
Ocenjivanje<< Business Process>>
Slanje na obuku<< Business Process>>
IS Agencije za promociju
1. Konkurisanje promotera
2. Obuka promotera
1.2 Intervjuisanje
1.3 Analiza kandidata
1.1 Prijava na konkurs
2.2 Ocenjivanje promotera
2.1 Slanje promotera na obuku
3. Angažovanje
3.1 Angažovanje klijenata
3.2 Angažovanje promotera
UMM model procesa agencije za promociju
Dijagram dekompozicije IS
agencije za promociju
UML 2.0
<<Business Operation Map>> se dekomponuje tako da
može da sadrži jedan ili više složenih podprocesa tipa
<<Busines Area>> i <<Process Area>>, ili primitivnih
procesa tipa <<Business Process>>.
Jedan proces stereotipa <<Business Area>> može da
bude dekomponovan na jedan ili više složenih procesa
stereotipa <<Process Area>> ili primitivnih proces
stereotipa <<Business Process>>.
UML 2.0
Za svaki od složenih tipova dat je odgovarajući
formular preko koga se opisuju procesi tog tipa, a za
primitivni poslovni proces koji je predstavljen
Slučajem korišćenja primenjuje se opis koji smo ranije
prikazali. Prikaz formulara za opis složenih tipova
(različitih stereotipova paketa) nije ovde od interesa.
Podrazumeva se da se u UMM modelu prikazuju
PDSK.
Poslovni dijagrami slučajeva korišćenja daju opštiji
opis nekog primitivnog poslovnog procesa, po pravilu
samo njegov osnovni scenario.
UML 2.0
•Zahtev A.1: CMS će omogućiti administratoru da
kreira novi blog nalog, kojim će se obezbediti
smeštanje ličnih podataka novih blogera, a koji će se
proveravati koristeći bazu podataka akreditovanih
autora. Ne postoji specifičan „najbolji način“ za
početak analize Zahteva A.1, ali prvi koristan korak je
da se vidi koja sredstva komuniciraju sa sistemom. U
SK, ova spoljna sredstva se zovu akteri.
UML 2.0Zahtevi koji “moraju” i “trebalo bi” da budu
ispunjeni imaju specijalno i tačno značenje kada dođe
do ispunjavanja zahteva.
Oni zahtevi koji ”moraju da budu ispunjeni” zaista
moraju da budu ispunjeni. Ako se karakteristika u kojoj
je ubačen “zahtev morati” nije ispunjena u finalnoj
verziji sistema, onda sistem ne ispunjava ovaj zahtev.
“Zahtevi trebalo bi” podrazumeva da ovi zahtevi nisu
kritični za rad sistema ali su poželjni.
Ako projektanti ili programeri naiđu na probleme zbog
kojih će projekat verovatno kasniti, onda se uglavnom
prvo žrtvuju “zahtevi trebalo bi”.
UML 2.0
Odlučivanje šta jeste a šta nije
akter, je nezgodno i najbolje se
uči iskustvom. Akter ne mora
da bude stvarna osoba, on može
da bude neki drugi sistem
(aplikacija), kao što je busines-
to-business (B2B) aplikacija.
Potrebno je zamisliti aktera kao
crnu kutiju koju ne možete
promeniti i ne interesuje nas
kako ona radi, ali ona
jednostavno mora da interaktuje
sa našim sistemom.
Da li je sredstvo stvarna
osoba koja interaktuje sa sistemom ?
DA
Da li je sredstvo nešto
što ja mogu da promenim za vreme
projektovanja?
NENE
DA
Sredstvo je verovatno akter. Budite pažljivi sa ljudima jer se ponekad ljudi smatraju delom sistema !
Sredstvo verovatno nije akter. Sve na što vi možete da utičete i imate neki vid kontrole dok projektujete, najčešće se smatra delom vašeg sistema !
Identifikacija aktera
UML 2.0
Nisu svi akteri jasni eksterni sistemi ili ljudi koji
interaktuju sa našim sistemom.
Primer čestog nezgodnog aktera je sistemski sat. Samo
ime govori da je sat deo sistema, ali da li je tako?
Sistemski sat dolazi do izražaja kad poziva neko
ponašanje unutar našeg sistema. Teško je utvrditi da li
je sistemski sat akter jer sat nije jasno izvan našeg
sistema.
Iz iskustva, sistemski sat je često bolje objašnjen kao
akter jer nije nešto na šta možete da utičete.
UML 2.0
Akter je bilo šta što stupa u interakciju sa sistemom. To je
objekat van sistema koji predstavlja tip (vrstu) korisnika.
Akter može biti korisnik (čovek) ili neki drugi sistem. Treba
praviti razliku između korisnika i aktera.
Korisnik je čovek koji koristi sistem, dok je akter
specifična uloga koju korisnik ima u komunikaciji sa
sistemom.
Direktna asocijacija između dva aktera ili dva slučaja
korišćenja nije dozvoljena. Međutim, kasnije će se videti, da
su dozvoljene veze tipa generalizacije (specijalizacije)
između slučajeva korišćenja i između aktera, preko kojih se
mogu definisati neki opštiji, apstraktni slučajevi korišćenja i
apstraktni akteri.
UML 2.0
Apstraktni slučaj korišćenja služi samo za opšti
zajednički opis drugih slučajeva korišćenja, njegovih
podtipova i ne može stupiti u interakciju sa nekim
akterom.
Isto tako, apstraktni akter predstavlja
generalizaciju dva ili više aktera da bi se na taj način
prikazala neka njihova jedinstvena interakcija (slučaj
korišćenja) sa sistemom.
Kada dva aktera imaju slične uloge u odnosu na
sistem oni mogu naslediti zajedničkog apstraktnog
aktera kao na sledećoj slici.
UML 2.0
Komitent Administrator
Primaoc izveštajao ukupnom prometu
Administrator i Komitent su specijalna vrsta primaoca izveštaja
o ukupnom prometu. Da bi pokazali da Administrator i Komitent
mogu da urade sve što može običan Primalac izveštaja ali sa
nekim dodatnim opcijama, koristi se generalizacija. Na taj način,
ako postoji veza nekog SK sa ova dva aktera, ona se briše ali se
kreira nova veza SK sa apstraktnim akterom. Tako se smanjuje
broj veza (asocijacija) na dijagramu SK.
UML 2.0
SK može biti identifikovan iz korisničkih zahteva. Ovde treba da
se kristališe jasan skup poslova našeg sistema. Ako SK zaista
predstavljaju zahteve, onda oni moraju biti: ispunjeni/nisu
ispunjeni. Programer, tester i korisnik moraju eksplicitno znati da
li sistem ispunjava SK ili ne. SK može biti jednostavan, kao što
je na primer logovanje ili komplikovan kao na primer izvršavanje
distribucione transakcije preko više globalnih baza podataka.
Važna stvar je da SK, sa korisničke perspektive, mora da postoji
neka interakcija sa sistemom, ali takođe i neki izlaz iz interakcije
koji može biti normalan ili alternativan, da ne kažemo pozitivan
ili negativan. Ako govorimo o logovanju onda se korisnik može
ulogovati (normalan, pozitivan) ili ne može ulogovati ali će mu
se prikazati poruka (alternativan, negativan).
UML 2.0
Administrator
CMS
Kreiranje novog blog
naloga
Komunikaciona linija povezuje aktere i slučajeve korišćenja.
UML 2.0Dijagram koji prikazuje SK i aktere može biti odlična startna
pozicija, ali oni ne daju mnogo detalja da bi se tačno razumelo
šta sistem treba da radi. Svaki SK treba da bude detaljno opisan.
Najbolje rešenje za prikaz detaljnih opisa je tekstualni opis
svakog SK.Detalji opisa SK Šta znače detalji i zašto su korisni
Povezani zahtevi Neki zahtevi koje parcijalno ili kompletno ispunjavaju SK.
Cilj u kontekstu Kakva je uloga SK unutar sistema i zašto je ovaj SK bitan.
Preduslovi Šta treba da se desi pre nego se izvrši ovaj SK.
Zadovoljavajući ishod uslova
Koji uslovi sistema treba da budu ako se SK uspešno završi.
Nezadovoljavajući ishod uslova
Koji uslovi sistema treba da budu ako SK ne uspe da se završi.
Primarni akteriGlavni akteri koji učestvuju u sistemu. Često uključuje aktere koji okidaju ili direktno dobijaju informacije iz izvršavanih SK.
Sekundarni akteriAkteri koji učestvuju, ali nisu glavni akteri u okviru slučaja korišćenja.
Okidač Događaj ili okidač koji okida akter a koji prouzrokuje SK.
Glavni tok (normalan scenario)
Ovde se opisuju važni koraci u okviru normalnog izvršavanja SK.
Proširenja (Alternative)
Opis bilo kojih alternativnih koraka koji su navedeni u glavom toku.
UML 2.0
Uobičajeno je da se posebno daje opis normalnog toka
događaja (glavni tok) u SK, a da se posebno mogu izvući
izuzeci (proširenja, alternative).
SK je šablon ponašanja delova sistema.
Svaki SK je skup sekvenci bliskih transakciji koje izvodi
akter u dijalogu sa sistemom.
Jedan SK predstavlja skup sekvenci događaja.
Jedna sekvenca događaja se naziva scenario.
Postoji normalan scenario i skup mogućih izuzetaka i
alternativnih funkcionisanja (proširenja, alternative).
Ime slučaja korišćenja Kreiranje novog blog naloga (SK1)
Povezani zahtevi Zahtev A.1.
Cilj u kontekstuNov ili postojeći zahtev autora za novim blog nalogom od administratora.
PredusloviSistem ima momućnost da prepozna autore jer autor ima odgovarajući dokaz identiteta.
Zadovoljavajući ishod uslova Novi blog nalog je napravljen za autora.
Nezadovoljavajući ishod uslova Kreiranje novog blog nalog je odbijeno.
Primarni akteri Administrator
Sekundarni akteri Baza podataka akreditovanih autora
Okidač Administrator konsultuje CMS da napravi novi nalog.
Glavni tok (normalan scenario) Koraci Akcija
1 Administrator traži od sistema da kreira novi nalog.
2 Administrator bira tip naloga.
3 Administrator ubacuje autorove detalje (podatke).
4 Autorovi podaci su provereni (verifikovani) koristeći bazu akreditovanih autora.
5 Novi nalog je kreiran.
6 Skup podataka blog naloga poslati suautoru mejlom.
Proširenja (alternative) Koraci Grananje akcije
4.1 Akreditovana baza autora nijeverifikovala podatke autora.
4.2 Kreiranje blog nalog je odbijeno.
Administrator
CMS
Kreiranje novog blog
naloga
Baza podatakaakreditovanih autora
Dijagrama SK
sa novim akterom
Detaljan opis SK1
UML 2.0
Veze (relacije) između slučajeva korišćenja
SK opisuje način ponašanja sistema za ispunjavanje zahteva.
Kada opišemo SK primetićemo da postoje sličnosti u nekim
koracima između različitih SK. Možemo takođe naći da neki
SK funkcionišu na nekoliko različitih načina ili specijalnih
slučajeva.
Treba se osloboditi ponavljanja opisa slučaja korišćenja i
prikazati samo bitne opcione tokove izvršavanja. Ovde ćemo
pokazati ponovo iskoristiva, opciona i specijalizovana
ponašanja između SK
UML 2.0
<<include>> - stereotip veze zavisnosti koja opisuje ubacivanje
nekog posebno opisanog slučaja korišćenja u posmatrani slučaj
korišćenja.
Generalizacija - veza opštijeg i specifičnijeg slučaja korišćenja
koji nasleđuje opis opštijeg ili veza između opštijeg i
specifičnijeg aktera koji nasleđuje sve interakcije opštijeg sa
sistemom.
<<extend>> - stereotip veze zavisnosti koja referencira (ubacuje)
moguće dodatno "ponašanje" opisano u posebnom slučaju
korišćenja.
Asocijacija - ukazuje na postojanje veze pojavljivanja dva tipa
elemenata koji su u asocijaciji.
UML 2.0
<<Include>> veza
Do sada smo videli da SK uglavnom komuniciraju sa akterima
za ispunjavanje zahteva. Veze između SK se koriste da podele
sistem na lako upravljive delove a zatim i da dodaju sve što je
novo u sistemu.
UML 2.0
Prvo što primetimo je da imamo ponavljanja u opisivanju dva SK. I SK1
i SK2 treba da imaju verifikaciju autora. Ovo ponašanje se ponavlja u
opisima ova dva SK. Ponovljivo ponašanje u dva SK je najbolje odvojiti
i napraviti novi SK. Ovaj novi SK može da se iskoristi, uključi u SK1 i
SK2 koristeći <<include>> vezu.
Administrator
CMS
Kreiranje novog blog
naloga
Baza podatakaakreditovanih autora
Kreiraj novi lični Wiki
Administrator
CMS
Kreiranje novog blog
naloga
Autor akreditovane baze podatka
Kreiraj novi lični Wiki
<<include>>
Proveri identitet
<<include>>
<<Include>> veza
Dobit ove promene je da su sada izbegnute dve veze i da postoji samo
jedna i to ka SK Proveri identitet. Da bismo pokazali vezu u detaljnom
opisu SK moramo da izbrišemo iste korake koji se ponavljaju u SK1 i
SK2 i da umesto njih napišemo Include::<ime SK>, kao što je prikazano
u tabeli. Ime slučaja korišćenja Kreiranje novog blog naloga (SK1)Povezani zahtevi Zahtev A.1.
Cilj u kontekstuNov ili postojeći zahtev autora za novim blog nalogom od administratora.
Preduslovi Autor ima odgovarajući dokaz identiteta.Zadovoljavajući ishod uslova Novi blog nalog je napravljen za autora.Nezadovoljavajući ishod uslova Kreiranje novog blog nalog je odbijeno.Primarni akteri AdministratorSekundarni akteri NEMAOkidač Administrator konsultuje CMS da napravi novi
nalog.Uključeni SK Proveri identitetGlavni tok (normalan scenario) Koraci Akcija
1 Administrator traži od sistema da kreira novi nalog.
2 Administrator bira tip naloga.3 Administrator unosi autorove
detalje (podatke).4include::Proveri identitet
Autorovi podaci su provereni.
5 Novi nalog je kreiran.6 Skup podataka blog naloga
poslati su autoru mejlom.
UML 2.0Prednosti INCLUDE
veze:
•Sa <<include>> vezom
nema potrebe da sa kopira
i prebacuju tekst iz jednog
ka drugom SK. Ako dođe
do izmene SK, on se
menja samo na jednom
mestu tj. jednom SK.
•<<Include>> veza
pokazuje da
implementacija SK
Proveri identitet treba da
bude važan i ponovo
iskoristiv deo sistema.
•Prikazuje se manji broj
veza sa akterom i
dijagrami su pregledniji.
Ime slučaja korišćenja Proveri identitet (SK3)
Povezani zahtevi Zahtev A.1., Zahtev A.2.
Cilj u kontekstuPodaci autora treba da budu provereni i verifikovani.
PredusloviAutor koji se proverava ima odgovarajući dokaz identiteta.
Zadovoljavajući ishod uslova
Detalji (podaci) su verifikovani.
Nezadovoljavajući ishod uslova
Detalji (podaci) nisu verifikovani.
Primarni akteri Baza akreditovanih autora.
Sekundarni akteri NEMA
Okidač Autorovi kredencijali su prosleđeni sistemu na verifkovanje.
Glavni tok (normalan scenario)
Koraci Akcija
1 Detalji (Podaci) su prosleđeni sistemu.
2 Baza akreditovanih autora verifikuje detalje (podatke).
3 Baza akreditovanih autora vraća verifikovane detalje (podatke).
Proširenja Koraci Grananje akcije
2.1 Baza akreditovanih autora nijeverifikovala podatke.
2.2 Podaci se vraćaju verifikovani.
UML 2.0
Administrator Baza akreditovanihautora
CMS
Kreiraj novi licni Wiki
Proveri identitet
Kreiranje novog blog
naloga
Kreiranje regularnog blog naloga
Kreiranje uredničkog blog naloga
<<include>>
<<include>>
Generalizacija (Veza specijalizacije SK)
Ako želimo da opišemo opšte ponašanje za kreiranje blog naloga
opisano u SK1 (Kreiranje novog blog naloga) a zatim definišemo
specijalizovane SK u kome su nalozi kreirani kao specijalni
tipovi, kao na primer regularan nalog sa jednim blogom ili
urednički nalog koji može da menja unose više blogova.
Ime slučaja korišćenja Kreiranje uredničog blog naloga (SK4)
Povezani zahtevi Zahtev A.1.
Cilj u kontekstuNov ili postojeći zahtev autora za novim uredničkim blog nalogom od administratora.
Preduslovi Autor ima odgovarajući dokaz identiteta.
Zadovoljavajući ishod uslova Novi urednički blog nalog je kreiran za autora.
Nezadovoljavajući ishod uslova Kreiranje novog uredničkog blog nalog je odbijeno.
Primarni akteri Administrator
Sekundarni akteri NEMA
Okidač Administrator konsultuje CMS da kreira novi urednički nalog koji dozvoljava autoru da menja unose u skupu blogova.
Osnovi SK (Base Use Case) Kreiranje novog blog naloga (SK1)
Glavni tok (normalan scenario) Koraci Akcija
1 Administrator traži od sistema da kreira novi nalog.
2 Administrator bira urednički tip naloga.
3 Administrator unosi autorove podatke
4 Administrator selektuje blogove koje taj urednički nalog ima pravo da edituje (menja).
5 include::Proveri identitet
Autorovi podaci su provereni.
6 Novi urednički nalog je kreiran.
7 Svi podaci uredničkog blog naloga poslati su autoru mejlom.
Proširenja (alternativni scenario) Koraci Grananje akcije
5.1Autoru nije dozvoljeno da menja selektovane blogove.
5.2 Urednički blog nalog je odbijen.
5.3Ovo odbijanje je snimljeno u bazu kaodeo autorove istorije.
UML 2.0
<<Extend>> veza
Ovo višestruko ponavljanje ponašanja je opciono u oba slučaja.
Tačnije rečeno, ne želite i ne možete da snimite odbijanje
kreiranje naloga ako je odobreno Kreiranje novog blog naloga
ili Kreiranje ličnog naloga Wiki. Veza <<extend>> je idealna u
situacijama višestruke upotrebe, kao što se vidi na slici.
Kreiraj novi licni Wiki
Kreiranje novog blog
naloga
Snimanje neuspeha kreiranja naloga
Proveri identitet
Kreiranje uredničkog blog naloga
CMS
Administrator
Baza akreditovanihautora
Kreiranje regularnog blog naloga
<<extend>><<include>>
<<extend>> <<include>>
Ime slučaja korišćenja Kreiranje novog blog naloga (SK1)
Povezani zahtevi Zahtev A.1.
Cilj u kontekstuNov ili postojeći zahtev autora za novim blog nalogom od administratora.
Preduslovi Autor ima odgovarajući dokaz identiteta.
Zadovoljavajući ishod uslova Novi blog nalog je napravljen za autora.
Nezadovoljavajući ishod uslova Kreiranje novog blog nalog je odbijeno.
Primarni akteri Administrator
Sekundarni akteri NEMA
Okidač Administrator konsultuje CMS da napravi novi nalog.
Uključeni SK Proveri identitet
Glavni tok (normalan scenario) Koraci Akcija
1 Administrator traži od sistema da kreira novi nalog.
2 Administrator bira tip naloga.
3 Administrator unosi autorove podatke.
4 include::Proveri identitet
Autorovi podaci su provereni.
5 Novi nalog je kreiran.
6 Skup podataka blog naloga poslati su autoru mejlom.
Proširenja(alternativni scenario) Koraci Grananje akcije
4.1 Akreditovana baza autora nije verifikovala podatke autora tj., autoru nije dozvoljeno da kreira blog.
4.2 Kreiranje blog nalog je odbijeno.
4.3 Ovo odbijanje je snimljeno u bazu kao deo autorove istorije.
Potrebno je nacrtati za svaki SK njegov Sistemski dijagram sekvenci i
prve nacrte korisničkog interfejsa. Slika daje primer Sistemskog
dijagrama sekvenci za Kreiranja novog blog naloga. Prvi nacrti
korisničkog interfejsa podrazumevaju izglede formi (stranica, ekrana)
svih SK. Ovo podrazumeva prikaz svih kontrola na formama (dugme,
tekstualno polje, razne liste i sl.). Čak i ako smo planirali da neki od SK
ima dve ili više formi onda je poželjno sve detaljno nacrtati i objasniti.
:Administrator
KreirajNoviNalog()
IzaberiTipNaloga(tipNaloga)
:Sistem
UnosAutorovihPodataka(Autor)
NalogKreiran
Glavni tok (normalanscenario)
Koraci
Akcija
1 Administrator traži od sistema da kreira novi nalog.
2 Administrator bira tipnaloga.
3 Administrator ubacujeautorove detalje(podatke).
4 Autorovi podaci su provereni (verifikovani) koristeći bazu akreditovanih autora.
5 Novi nalog je kreiran.
Projektovanje informacionih sistema
HVALA !
dr Rade Matić
Beogradska akademija poslovnih i
umetničkih strukovnih studija
49
