Download doc - Projektovanje Informacionih Tehnologija-Turisticka Agencija

TURISTICKA AGENCIJA

1. Opis problema

Napraviti bazu podataka za jednu turističku agenciju sa sledećim opisom: Agencija organizuje razne tipove aranžmana letovanja, zimovanja, ekskurzije, poslovne posete i td. Potrebno je za svaki aranžman voditi podatke o jednoj krajnjoj destinaciji (mestu) kao i osvim prolaznim mestima koja se posećuju. Za svako prolazno mesto u aranžmanu treba dati sadržaj posete sa satnicom. Svaki aranžman se realizuje u većem broju termina, gde se vodievidencija o datumu polaska, datumu povratka, ceni aranžmana. Za svaku realizaciju aranžmana angažuje se jedno ili više vozila istog ili različitog tip.

2. MOV

3. Relacioni model

Aranzman(AranzmanID, NazivAranzmana)Termin(TerminID,AranzmanID,MestaID,DatumPolaska, DatumPovratka, Cena)Vozilo(VoziloID, TipVozilaID, NazivVozila, RegistarskiBroj, Ispravnost)TipVozila(TipVozilaID,NazivTipaVozila, Sifra)Iznajmljuje(VoziloID, TerminID)Mesta(MestaID,NazivMesta)ProlaznaMesta(ProlaznaMestaID, MestaID, Sadrzaj, Satnica)

4. Dijagram aktivnosti

Dijagram rezervisanja vozila

Dijagram dobijanja licence

Dijagram rezervisanja aranzmana

Dijagram rezervisanja termina

5. Dijagram promene stanja

Dijagram promene stanja kreiranja aranzmana

Dijagram promene stanja popunjavanja zahteva za rezervaciju vozila

6. Dijagram slucajeva koriscenja

Ime Kreiranje aranžmana

Učesnici Direktor agencijePreduslovi Sistem je uključen. Sistem prikazuje početnu

formu.Svrha Služi za kreiranje aranžmana.

Uspešni scenario 1. Direktor agencije unosi u sistem sifru novog aranzmana.2.Direktor agencije unosi u sistem naziv destinacije. 3.Direktor agencije unosi u sistem Broj dana aranzmana.4.Direktor agencije unosi u sistem Termin aranzmana.5. Direktor agencije unosi u sistem cenu tog aranzmana.6. Direktor klikne na dugme Unesi i poziva sistem da zapamti novi aranzman7. Sistem pokazuje direktoru poruku o uspešnom unosu novog aranzman.

Alternativni tokovi 1)Ako je destinacija neispravna sistem vraca gresku.2)Ako direktor agencije unese neispravan broj vozila , neko slovo , sistem vraca gresku.

Slucaj koriscenja 1: Kreiranje aranzmana

Sistemski dijagam sekvenci za kreiranje aranzmana

Dijagram sekvenci za Kreiranje aranzmana

Dijagram klasa za Kreiranje aranzmana

Forma za kreiranje aranzmana

Slucaj koriscenja 2: Rezervacija Aranzmana

Ime Rezervacija aranzmanaUčesnici KorisnikPreduslovi Sistem je uključen. Sistem prikazuje početnu

formu.Svrha Služi za rezervisanje aranzmana.

Uspešni scenario 1)Korisnik unosi svoje ime i prezime2) Korisnik unosi svoj JMBG3)Korisnik bira destinaciju. 4)Korisnik bira termin u kojem zeli da putuje na odredjenu destinaciju5)Korisnik bira broj dana 6)Korisnik klikne na dugme rezervisi i poziva sistem da zapamti rezervaciju7) Sistem pokazuje korisniku poruku o uspesnoj rezervaciji

Alternativni tokovi 1)Ako je korisnik izabrao broj dana koji ne odgovara terminu i destinaciji sistem izbacuje poruku Greska2)Ako je dati termin pun za odredjenu destinaciju pun, sistem izbacuje poruku Nema slobodnih mesta.

Sistemski dijagram sekvenci za Rezervaciju aranzmana

Dijagram sekvenci za Rezervaciju aranzmana

Dijagram klase za Rezervaciju aranzmana

Forma za rezervaciju aranzmana

Slucaj koriscenja 3: Prodaja aranzmana

Ime Prodaja aranzmanaUcesnici AgentPreduslovi Sistem je uključen. Sistem prikazuje početnu

formuSvrha Sluzi za prodaju aranzmanaUspesni scenario 1. Agent unosi u sistem ime putnika koji je

uplatio za aranzman. 2. Agent unosi u sistem kolicinu novca koju je putnik platio za aranzman 3. Agent unosi u sistem destinaciju na koju putnik putuje4. Agent unosi u sistem u kom terminu putnik putuje.5. Agent klikne na dugme unesi i poziva sistem da zapamti novu prodaju.6. Sistem pamti novu prodaju.7. Sistem pokazuje agentu poruku o uspešnom unosu nove prodaje.

Alternativni tokovi 1)Ako agent unese pogresnu cenu aranzmana, agentu se salje poruka greska cene aranzmana.2) Ukoliko nema vise mesta za destinaciju u terminu koji putnici zele, agentu se salje poruka nije moguce izvrsiti prodaju.

Sistemski dijagram sekvenci za prodaju aranzmana

Dijagram sekvenci za prodaju aranzmana

Dijagram klasa za prodaju aranzmana

Forma za Prodaju aranzmana

Slucaj koriscenja 4:Pretraga aranzmana

Ime Pretraga aranzmanaUcesnici AgentPreduslovi Sistem je uključen. Sistem prikazuje početnu

formuSvrha Sluzi za pretragu aranzmanaUspesni scenario 1. Kupac bira destinaciju

2. Kupac bira termin u kome zeli da realizuje aranzman.3. Kupac bira koliko dana zeli da provede na datoj destinaciji.4. Kupac klikne na dugme pretraga i poziva sistem da pretrazi ovaj aranzman.5. Sistem pretrazuje aranzman.6. Sistem izbacuje rezultate pretrage.

Alternativni tokovi 1) Ako nema aranzmana za odredjenu destinaciju u zeljenom terminu, sistem izbacuje poruku korisniku Nema Aranzmana.

Sistemski dijagram sekvenci za pretragu aranzmana

Dijagram sekvenci za pretragu aranzmana

Dijagram klasa za pretragu aranzmana

Forme za pretragu aranzmana

60 Poglavlje 3 Modelovanje slucaja koriscenja

To je cinjenica koja je ignorisana u mnogim knjigama o slucajevima koriscenja.Ali ramislite o tome: Kako mozete da vozite model objekata od Slucajeva koriscenja ako ti slucajevi nisu povezani sa objektom? Kratak odgovor je da ne mozete. U isto vreme, nemate svo znanje o eventualnim modelima objekata kada pocnete da pisete slucajeve koriscenja. Kada imate znanje u tom odeđenom vremenu to je preliminarana verzija objekata modela koja opisuje problem domena u nedvosmislenim terminima-koji je domen modela. Pa link slucajka koriscenja ka domenima objekata. U praksi ovo znaci referenciju domena Slucaja po imenima u tekstu Slucaja koriscenja.

Recimo da imate domene modela koji sadrze domene casova kao: Lista zelja, Knjiga, Lista knjiga I Kolica za spoing. Praticete koriscenje tekst Slucaja koriscenja koji je “sortiran” po domenima klasa, ali se ne upucuje na njih imenom(lutajuci tekst je prikazan crvenom bojom).

Korisnik bira naziv I dodaje ga na njegovu listu knjiga da bi ga sacuvao za kasnije. Sistem pokazuje stranicu sa aodejtovanom listom I takodje pokazuje Listu naslova u korisnikovim kolicima , spremnu za cekiranje.

I ako se ovaj tekst cini jasnim, to je leglo dvosmislenosti. “Lista knjiga za cuvanje za kasnije” mozda, u sledecem scenariju Slucaja koriscenja, bude skraceno na “Listu knjiga” ili “Sacuvane knjige”, kad bi se oboje intepretiralo znacilo bi nesto komletno razlicito. Evo ispravljenog teksta (isprevljeni delovi su boldirani):

Korisnik bira Knjigu I dodaje je na njegovu Listu zelja. Sistem pokazuje stranicu sa apdejtovanom listom I takodje pokazuje Soping kolica korisnika.

Presli ste na problem pravljenja domena modela da bi ste nedvosmisleno komunicirali o detaljima sistema koji ste razvili. S obzirom da je izbegavanje dvosmislenosti u slučaju korišćenja jedan od vaših primarnih ciljeva, ne bi bilo mudro da se koristi terminologija sa kojom se vaš tim kolektivno složio u Domenu modela.

___________________________________________________________________________

VEZBA Postoji jos jedna stavka slucaja koriscenja ovog odeljka teksta koja je potencijalno dvosmislena. Mi ga pokrivamo u narednom poglavlju (’’Referentne Granicne Klase po Imenu“) , ali pogledajte da li mozete da ga primenite pre prelaska. Razmislite cime biste ga zamenili.

___________________________________________________________________________

Poglavlje 3 Modelovanje slucaja koriscenja 61

1. Referentne Granicne Klase po Imenu

Od kad ste na zadatku da piste nedvosmislena zahtevanja ponasanja, I posto zahtev za ponasanje uvek uknjucuje korisnicki interfejs, dobra je ideja da ne pisete nejasne I dvosmislene fraze kao “Sistemu pokazuje veb starnicu u vasem slucaju koriscenja”. Radije , eksplicitno ime vaseg ekrana- na pr “Sistem prikazuje proverenu starnicu”.

U mnogim slicajevima, znacajno ponasanje softvera se odnosi na interakciju stranice pre pokazivanja, I takodje treba da napisete o ovom ponasanju: “Sistem pokazuje Checkout page (Cekiranu stranicu) pokazujuci korisnikov osnovi obracun I adresu sa koje je sve stiglo (posiljajucu adresu)”. Primeticete kako korisnikov tekst postaje progresivno manje dvosmislen.

Vracamo se na listu zelja, primer, ovde je kako se tekst pojavljuje jednom kada se granicni cas odnosi na ime (ispravljen tekst je boldiran):

Korisnik bira knjigu I dodaje je na listu zelja. Sistem pokazuje Korisnikovu Listu Zelja (koja takodje pokazuje korisnikovu Soping Korpu koja je postavljena po datumu).

Primeticete da smo progresivno izbacili dvosmislenost iz slucaja koriscenja stavljajuci ga u kontekst modela objekata I GUI.

Organizovanje Slucaja koriscenja u pakete:Internet knjizara

Veoma uskoro pocecemo da pisemo neke od korisnickih slucajeva za Internet kniizaru,ali pre nego sto uradimo to,treba nam neki nacin organizovanja svih ovih slucajeva.U sistemu pristojnne velicine ,mogli bi ste da imate od 100 slucajeva pa naviše

Srecom,UML nas obezbedjuje sa paketom mehanizma,koji je nacin grupisanja povezanih elemenata.Paketi su u osnovi sadrzioci kontejneri koji sadrze bilo koji UML konstruckiju,ukljucujuci i druge pakete.Ako ste JAVA programer,UML paketi nisu skroz razliciti Java paketima,u tom vam dozvoljavaju da podelite vas rad siroko u razlicitim podrucjima.

Za internet knjizaru, Dijagram 3-5 pokazuje paket dijagram sadrzajuci 4 pakovanja. Svaki paket sadrzi puno korisnickih slucajeva.Dodatno,kupovinski paket sadrzi saucesnika (Musterija), i admin paket koji sadrzi 4 saucesnika (Korisnicki servis, Prodavac, Spedicijski sluzbenik i Vebmaster).


Dijagram 3-5. Paket dijagram za primer Internet knjizare

Dijagrami 3-9 kroz 3-6 pokazuju kroz pojedinacne dijagrame slucaja koriscenja za svaki od cetiri Paket-uzrasta. Primeticete da se nismo potrudili da ulepsamo dijagrame, ili cak da povezemo sve mehurice slucajeva koriscenja sa strelama. To je zato sto je vazniji deo posla pisanje teksta slucaja koriscenja.

Mi obezbedjujemo kratku diskusiju o odnosima koje smo nacrtali, ali kao sto cete spojiti do kraja rasprave, mi cenimo ono sto ide u tekstu slucaja koriscenja mnogo vise od odnosa izmedju slucajeva koriscenja.


Dijagram 3-6. Dijagram slucaja koriscenja za ’’opsti’’paket

PROIZVODNJA VAN ZAJEDNICKOG PONASANJA

Poslednja stvar koju zelite da uradite kada pisete slucajeve koriscenja je da ponovite isto ponasenje vise puta. Ovo je stravican gubitak napira, za koji nemate vremena, i jedan od vodecih uzroka analize paralize. Dakle, potreban vam je mehanizam za faktoring ovog uobicajenog ponasanja u svom slucaju koriscenja. Nasa prednost za ovo je udruzenje zvano <<poziva>> i njen partner u zlocinu <<prethodi>>.

Dijagram 3-7 ima strelicu oznacenu " poziva", koja ukazuje da otpremi nalog. Trebalo bi da procitate ovo u smeru strelice-drugim recima, "Preuzimanje poziva Otpremanje porudzbine". To jednostavno znaci da u toku stajanja kroz slucaj koriscenja Provera, slucaj koriscenja Otpremanje porudzbine se moze pozvati.

Treba pomenuti da se slucaj koriscenja poziva u tekstu slucaja koriscenja, u suprotnom, odnos poziva nece imati mnogo smisla. Dakle, opis slucaja koriscenja moze reci ’’korisnik klikne na dugme Potvrdi porudzbinu, poziva Otpremanje porudzbine“.

<<i>> ovo je UML oznacavanje za stereotipe. Stereotip je UML mehanizam za produzavanje, tako da moze da prosiri svoju osnovnu oznaku sa svojim sopstvenim semantika dodeljivanjem stereotipa u UML elementu.


Dijagram 3-7. Dijagram slucaja koriscenja za "administratorski" paket.

STA O <<SADRZI>> I <<PROSIRUJE>>?

UML definise neke standardne stereotipae za kretanje izmedju slucajeva koriscenja ( pre svega, podrazumeva << sadrzi i <<prosiruje>>, vise o suptilnim razlikama izmedju njih uskoro). Vi citate <<sadrzi>> udruzenja u smeru strelice, dok citate <<prosiruje>> udruzenja u obrnutom smeru.

To je dobra praksa da se Vasi slucajevi upotrebe pregledaju od " ne-UML-eksperata" kao krajnje korisnike i marketing ljude ( jer oni su ti koji razumeju kakvo bi ponasanje trebalo da bude). Primetili smo da ti ljudi ponekad budu zbunjeni pokusavajuci da procitaju dijagrame slucaja upotrebe sa nekim od udruzenja pokazujuci prema napred i neki pokazivajuci unazad. I, nakon rada sa slucajevima koriscenja 15 godina ili slicno, mi smo uvereni da su detalji unutar koriscenja su zaista vazni komadici, a ne udruzenja na dijagramima. Mozete misliti o <<poziva>> kao nadskup <<sadrzi>> i <<prosiruje>>. Ako A poziva B, mozete doci do B iz A.


i suptilne detalje ukljucivanja i prosirenja obicno nisu toliko vazne za zavrsavanje posla (vidi traku pod nazivom "slucajevi koriscenja i aspekti" kasnije u ovom poglavlju za slucaj gde su ti detalji vazni).

Podsetnik sa dijagrama 3-7 da postoji neka vrsta veze izmedju Provere i slucajeva koriscenja koji ga okruzuje. Na dijagramu 3-8 (kompletna verzija tog dijagrama slucaja upotrebe) nacrtali smo u odnosima koristeci << poziva>> strelice.

Dijagram 3-8. Dijagram slucaja koriscenja za ’’kupovni’’ paket