U ovom poglavlju će se prikazati osnovne objektne metode i modeli koje se koriste kako za fazu analiza sistema, tako i za fazu Specifikacija aplikacija životnog ciklusa IS. U obe faze se koriste iste metode i modeli, s tim što se u fazi analize sistem posmatra globalno i izgrađuje se njegov poslovni model, a u fazi specifikacije aplikacija, svaka identifikovana aplikacija se detaljno specifikuje.
Objektno-orjentisani razvoj softvera je u velikoj meri standardizovan, definisani su modeli preko kojih se sistem opisuje sa različitih aspekata i procesa pomoću koga se sistem, uz upotrebu standardnih modela, razvija. UML (Unified Modeling Language) definiše standardni skup modela, a jedinstveni proces razvoja softvera (Unified Software Development Process) definiše standardnu metodologiju. Ovde će se opisati modeli za analizu sistema i specifikaciju aplikacija i istovremeno analizirati proces modelovanja sistema sa ovih aspekata.
Model slučajeva korišćenja
Model slučajeva korišćenja se koristi i za izgradnju poslovnog modela sistema i za specifikaciju aplikacija. I sama definicija slučaja korišćenja i način izgradnje modela slučajeva korišćenja se razlikuju za ova dva aspekta.
Sa tačke gledišta analize sistema i izgradnje njegovog poslovnog modela, Slučaj korišćenja se definiše kao specifikacija interakcije između sistema i jednog ili više aktera i sistema, zajedno sa opisom akcija sistema u ovoj interakciji.
Sa tačke gledišta specifikacije aplikacija, slučaj korišćenja se definise kao specifičan način na koji će akter da koristi jednu buduću aplikaciju IS koji se projektuje.
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 slučajevi korišćenja opštije opisuju celokupan sistem, dok u fazi specifikacije aplikacija, daju detaljan opis jedne aplikacije. Ovde ćemo prvo definisati osnovne koncepte Modela slučajeva koršćenja, a zatim ćemo pokazati kako se njima modeluju poslovni procesi i specifikuju aplikacije.
Čvorovi
Formalno model slučajeva korišćenja može da se definiše kao graf sa dva tipa čvorova:
-
čvorovi tipa akter,
-
čvorovi tipa slučaj korišćenja.
Na slici 1 je prikazan dijagram slučajeva korišćenja koji opisuje skup aplikacija koji se mogu obaviti na bankovnom automatu. Svaki slučaj korišćenja treba da bude detaljno opisan. U fazi analize sistema i specifikacije zahteva daje se struktuirani verbalni opis, a u kasnijim fazama se ovaj opis dopunjava sa formalnim opisom kolaboracije objekata preko kojih se posmatrani slučaj korišćenja realizuje.
Statički model kolaboracije se daje preko UML dijagrama klasa, a dinamički preko dijagrama interakcije, dijagram promene stanja ili dijagrama aktivnosti. Jedan 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, odnosno alternativnih funkcionisanja. Uobičajeno je da se posebno daje opis osnovnog scenarija, a posebno opis svih alternativnih načina funkcionisanja.
Model slučajeva korišćenja – Primer
Formalno model slučajeva korišćenja može da se definiše kao graf sa dva tipa čvorova:
PODIZANJE NOVCA – osnovni scenario:
1. provera kartice: komitent ubacuje karticu u automat. Automat čita karticu i proverava da li je prihvatljiva. Ako je prihvatljiva, zahteva se od komitenta da unese „tajnu šifru”,
2. proveravanje šifre: komitent unosi tajnu šifru. Ako je šifra korektna, zahteva se da korisnik izabere transakciju,
3. unos tipa transakcije: komitent bira „podizanje novca” i automat šalje računaru banke tajnu šifru da bi se dobili brojevi komitentovih računa. Dobijaju se komitentovi brojevi računa i prikazuju na ekranu automata,
4. podizanja novca: komitent bira račun i unosi iznos koji podiže. Automat šalje računaru banke zahtev za podizanje datog iznosa sa datog računa. Priprema se štampanje izveštaja za komitenta,
5. kraj: automat vraća karticu komitentu. Izdaje se izveštaj komitentu.
PODIZANJE NOVCA – alternativna scenarija:
1. Kartica nije prihvatljiva: kartica se vraća korisniku sa zvučnim signalom. Nekorektna tajna šifra: 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.
2. Prekid: korisnik može u svakom trenutku da prekine transakciju. Poništiće se svi dotadašnji efekti i vratiti kartica korisniku.
Veze
Pored već diskutovane veze tipa asocijacije između aktera i slučaja korišćenja u dijagramima slučajeva korišćenja, prvenstveno radi strukturiranja i pojednostavljivanja opisa slučaja korišcenja, uvode se i sledeće veze:
-
Veza zavisnosti u UML je najopštija moguća veza dva elementa modela čija semantika elemenat A nekako zavisi od elementa B.
-
Asocijacija koja ukazuje na postojanje veze pojavljivanja dva tipa elemenata koji su u asocijaciji.
-
Generalizacija koja vezuje elemenat podtip i elemenat nadtip podrazumevajući da podtip nasleđuje osobine i ponašanje nadtipa.
-
Realizacija koja pokazuje da jedan elemenat na neki način realizuje drugi.
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šcenja.
Include – stereotip veze zavisnosti koja opisuje ubacivanje nekog, posebno opisanog, slučaja korišćenja u posmatrani slučaj korišćenja.
UML stereotip je element modela definisan na osnovu nekog drugog već postojećeg elementa modela. On dodatno specifikuje postojeći model. Stereotipovi veze zavisnosti include i extend pokazuju šta opšta zavisnost u tim slučajevima predstavlja.
Primer
Na slici su prikazane diskutovane vrste veza. Očigledno je da i u osnovnom scenariju slučajeva korišćenja ulaganje i prenos postoje sekvence aktivnosti: provera kartice, provera tajne šifre i kraj transakcije. Sličnost scenarija slučajeva korišćenja podizanje, ulaganje i prenos sugeriše da se definiše jedan apstraktni slučaj korišćenja novčana transakcija.
Jedinstveni delovi scenarija se odvajaju u posebne slučajeve korišćenja provera kartice, Provera tajne šifre i kraj transakcije i zatim uključuju (zavisnost include) u apstraktni slučaj korišćenja novčana transakcija. Pošto postoji mogućnost da se u sve osnovne slučajeve korišćenja doda još i mogućnost registrovanja pojedinih događaja i njihovih atributa (iznos ulaganja, podizanja i prenosa, vreme obavljanja transakcije i slično), apstraktni slučaj korišćenja se proširuje sa slučajem korišćenja statistika transakcija.
Osnovni slučajevi korišćenja ulaganje, podizanje i prenos nasleđuju opis apstraktnog slučaja korišćenja novčana transakcija, dodajući mu svoje specifičnosti.
Modelovanje poslovanja pomoću modela slučajeva korišćenja
Jedan slučaj korišćenja predstavlja jedan atomski proces (funkciju) nekog poslovnog sistema. Ako bismo poredili model slučajeva korišćenja i strukturnu sistemsku analizu, mogli bismo da uspostavimo ekvivalenciju između osnovnog slučaja korišćenja i primitivnog procesa. Međutim, za razliku od strukturne sistemske analize, model slučajeva korišćenja ne sadrži koncept dekompozicije procesa, osnovni koncept za istovremeno jasno i detaljno opisivanje sistema.
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 modela slučajeva korišćenja u izgradnji poslovnih modela.
Zbog toga se u različitim pristupima modelovanju poslovnih procesa ugrađuju različiti mehanizmi dekompozicije složenih procesa. Tako se, 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) dekomponuje sistem preko specifičnih stereotipova paketa, kao što je pokazano na slici.
Paket je opšti mehanizam za grupisanje bilo kojih elemenata modela u grupe.
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. 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. Za svaki od složenih tipova dat je odgovarajući formular preko koga se opisuju procesi tog tipa, a za primitivan 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 poslovni slučajevi korišćenja. Poslovni slučajevi korišćenja daju opštiji opis nekog primitivnog poslovnog procesa, po pravilu samo njegov osnovni scenario.
Napomenimo još jedan značajan nedostatak modela slučajeva korišćenja u odnosu na SSA, sa tačke gledišta projektovanja baza podataka. U dijagramima tokova SSA se prikazuju i tokovi koji vezuju entitete van sistema, procese i skladišta, a u rečniku podataka SSA se daje opis strukture ovih tokova j skladišta. Struktura tokova i skladišta može da bude veoma dobra osnova za izgradnju konceptualnog modela baze podataka. Asocijacija između aktera i slučaja korišćenja ne predstavlja nikakav tok podataka pa se i ne opisuje struktura i sadržaj interakcije aktera sa sistemom.
Specifikacija aplikacija pomoću modela slučajeva korišćenja
Za specifikaciju aplikacija koristi se Model slučajeva korišćenja sa detaljnim opisom svih slučajeva korišćenja, sa osnovnim i svim alternativnim scenarijima. Za detaljni opis slučaja korišćenja ponekad se prezentira i korisnički interfejs preko koga će akter da koristi budući sistem. Prikaz korisničkog interfejsa, obično ekranske forme, značajno olakšava definisanje i razumevanje slučaja korišćenja.
Detaljan i formalniji opis slučaja korišćenja se može dati i preko tzv. sistemskog dijagrama sekvenci. Na slici je prikazan sistemski dijagram sekvenci za slučaj korišćenja ulaganje za bankovni automat. Dve vertikalne linije predstavljaju dva objekta koji komuniciraju razmenom poruka. Predstavljeni su neimenovani objekat klase korisnički interfejs i neimenovani objekat klase sistem. (Oznaka “:Aaa” se koristi da predstavi neimenovani objekat klase Aaa).
U UML-u dijagram sekvenci i njemu izomorfni dijagram kolaboracije, koji se jednim imenom nazivaju dijagrami interakcije, predstavljaju dinamiku kolaboracije skupa objekata preko kojih se realizuje odziv sistema na neku spoljnu akciju. Skup objekata preko kojih se realizuje neka aplikacija će biti definisan tek u fazi projektovanja aplikacije. U fazi specifikacije definiše se samo komunikacija aktera, preko korisničkog interfejsa, sa budućim sistemom kao celinom. Takav dijagram sekvenci se naziva sistemski dijagram sekvenci.
Horizontalne linije na dijagramu predstavljaju poruke koje razmenjuju objekti u interakciji. Poruka može da sadrži i argumente, podatke koji se prenose sistemu da bi ovaj mogao da realizuje korektan odziv. Po pravilu se poruke šalju u sekvenci odozgo nadole. Ako postoji neka promena ovoga redosleda, redosled (koreografija) se može specifikovati jednom vrstom pseudokoda uz levu stranu dijagrama sekvenci.
Sa tačke gledišta razvoja konceptualnog modela baze podataka sistemski dijagram sekvenci ima značajnu ulogu. Argumenti poruka nose informacije koje treba da se nađu u bazi podataka. U realnim sistemima argumenti mogu da budu i složene strukture podataka. Te strukture se u elektronskom poslovanju opisuju pomoću XML-a. Struktura XML-dokumenata, slično kao i opis tokova i skladišta podataka u SSA, je polazna osnova za izgradnju konceptualnog modela.
