View
1
Download
0
Category
Preview:
Citation preview
Stručna praksa I
Aleksandra Aleksandra KlaKlaššnjanja--MiliMiliććevievićć
Konsultacije: Ponedeljak 14.00 Konsultacije: Ponedeljak 14.00 -- 17.30h17.30h
Kabinet 2Kabinet 2
2
Stručna praksa I
Tema 3 - Primena prezentacionih alata u različitim poslovnim aktivnostima u poslovnom sistemu i sa drugim poslovnim subjektima
Tema 4 - Korišćenje infrastrukture Interneta u različitim poslovnim aktivnostima u poslovnom sistemu i sa drugim poslovnim subjektima
3
Plan rada
Priprema za izradu praktičnog rada - mart, april
Pronalazak poslovne organizacije i usaglašavanje
sadržaja predstojećeg praktičnog rada – do 10.aprila
Izrada praktičnog rada – u toku maja
Za sve dileme, nejasnoće i pomoć u praktičnom radu u
ovoj fazi, studentima je dostupan nastavnik praktične
nastave iz ovog segmenta – ponedeljak 14-17.30 u kab2
Krajnji rok za predaju praktičnih radova – 29.maj
Modelovanje sistema korišćenjem UML-a
5
Objektno modelovanje - UML
UML (Unified Modeling Language) - objedinjeni vizuelni jezik za
poslovno i softversko modelovanje u svim fazama razvoja i za sve
tipove sistema, kao i za generalno modelovanje kojim se definišu
statičke strukture i dinamičko ponašanje.
Standardni jezik za:
vizuelizaciju
specifikaciju
konstruisanje i
dokumentovanje softverskih sistema
UML kombinuje najbolje iz:
Koncepta “Data Modeling” (Entity Relationships Diagrams)
Poslovnog modelovanja (work flow)
Objektnog i komponentnog modelovanja
6
UML
UML je projektovan kao vrlo fleksibilan i prilagodiv jezik, koji
omogućava vrlo različite vrste modelovanja, uključujući:
modele koji olakšavaju razumevanje poslovnih procesa,
odvijanja tokova događaja,
sekvenci upita,
aplikacija,
baza podataka,
arhitektura i drugog.
7
UML
UML je nastao kao rezultat evolucije objektno orijentisanih jezika za modelovanje.
Razvila ga je kompanija Rational Software objedinjavanjem tri vodeće metode objektno orijentisanog modelovanja:
Booch koji je razvio Grady Booch,
OMT (Object Modeling Technique) koji je razvio Jim Rambaugh i
OOSE (Object-Oriented Software Engineering) koji je razvio Ivar Jacobson.
8
Arhitektura softverskih sistema
Kako je sistem
struktuiran?
Koje su funkcije
sistema? Kako izgraditi
sistem?
Gde instalirati?
Kako je sistem
predstavljen?
Kako se sistem
ponaša?
9
Kategorije korisnika
UML koriste sledeće kategorije korisnika
Sistem analitičari i krajnji korisnici – specifikacija
zahtevane strukture i ponašanje sistema
Arhitekte sistema – projektanti sistema koji će
zadovoljiti zahteve
Razvojni inženjeri (developers) – transformišu
arhitekturu u izvršni kod
Kontrolori kvaliteta – provera strukture i ponašanje
sistema
Rukovodioci projekta (menagers) – vode i usmeravaju
kadrove i resurse
10
UML dijagrami
Dijagram u UML-u – grafička predstava skupa elemenata - iscrtan kao graf čvorova (stvari) i lukova (relacija)
Dijagrami UML-a prikazuju sistem iz više uglova:
Dijagram slučajeva upotrebe (Use-Case Diagram)
Dijagram klasa (Class Diagram)
Dijagram objekata (Object Diagram)
Dijagram sekvenci (Sequence Diagram)
Dijagram saradnje (Collaboration Diagram)
Dijagram promene stanja (State Diagram)
Dijagram aktivnosti (Activity Diagram)
Dijagram komponenti (Component Diagram)
Dijagram razvoja (Deployment Diagram)
11
Gradivni blokovi UML-a
Stvari (things)
Relacije (relationships)
12
Things
Postoje 4 vrste elemenata (things):
Elementi strukture – statički delovi modela koji reprezentuju konceptualne ili fizičke elemente (imenice)
Elementi ponašanja – dinamički delovi modela koji reprezentuju ponašanje kroz prostor i vreme (glagoli)
Elementi grupisanja - organizacioni delovi modela
Elementi anotacije – opisni delovi modela, komentari koji se primenjuju na bilo koji dokument
13
Statički delovi modela
Fizički i zamenljivi deo sistema koji obezbeđuje realizaciju
skupa interfejsa
Komponenta
OpisSimbolIme
Čvor
Aktivne
klase
Slučaj
upotrebe
Korisnik
Kolaboracija
(Saradnja)
Interfejs
Klasa
Fizički element koji postoji u vreme izvršavanja i predstavlja
računarski resurs – ima memoriju i mogućnost procesiranja.
Klase čiji objekti poseduju jedan ili više procesa ili niti –
mogu inicirati kontrolnu aktivnost.
Opis skupa sekvenci akcija koje sistem izvodi da bi izvršio
neki zahtev korisnika.
Spoljašnji entitet koji komunicira sa sistemom, obično osoba.
Definiše interakciju i udružuje uloge i druge elemente tako da
rade zajedno i obezbeđuju kolaborativno ponašanje.
Kolekcija operacija koje opisuju servise klase ili komponente.
Opis skupa objekata koji dele iste atribute, operacije, veze i
semantiku. Implementira 1 ili više interfejsa.
14
Dinamički delovi UML modela
OpisSimbolIme
Prikaz stanja
Interakcija
Ponašanje specificirano sekvencom stanja objekta ili
neke interakcije.
Ponašanje prilikom razmene skupa poruka između
skupa objekata da bi se objasnile specifične namene.prikaz
Čekanje
15
Organizacioni delovi UML modela
OpisSimbolIme
Paket
Grupe na koje model može biti dekomponovan.
Mehanizam opšte namene, za organizovanje elemenata
u grupe.
Paket je čisto konceptualan – postoji samo u vreme
razvoja.
16
Delovi za objašnjenja
OpisSimbolIme
Anotacija
Komentari kojima opisujemo, objašnjavamo i
naznačavamo bilo koji element u modelu.
Osnovna vrsta anotacije je napomena (note).
17
Relacije (relationships)
Semantička relacija između klasifikatora, gde jedan
klasifikator specificira ugovor koji drugi klasifikator
garantuje da će ispuniti.
Objekti specijalizovanih elemenata (dete)
predstavljaju zamene za objekte generalizovanih
elemenata (roditelj).
Vrh strelice na roditelju.
Strukturna relacija koja opisuje skup veza kojim se
postavlja veza između objekata.
Semantička relacija između nezavisne i zavisne
stvari. Nezavisna stvar utiče na semantiku zavisne.
Usmerenje – iz zavisnog slučaja.
Opis
Realizacija
Generalizacija
SimbolIme
Asocijacija
Zavisnost
0..1 *
radi radj
18
Dijagrami slučajeva upotrebe (korišćenja)
19
Dijagram slučajeva upotrebe(Use-Case Diagram)
Omogućavaju krajnjim korisnicima da razumeju sistem
Pogled korisnika na funkcionisanje sistema (šta sistem radi, a
ne kako sistem funkcioniše)
Razvoj dijagrama slučajeva upotrebe definiše se sledećim
aktivnostima:
Definisanjem učesnika
Definisanjem slučajeva upotrebe
Definisanjem tipova veza između učesnika i slučajeva upotrebe
Izradom dijagrama slučajeva upotrebe
Učesnik
Asocijativni naziv
Slučaj upotrebe
20
Primer 1.
Potrebno je napraviti aplikaciju koja će omogućiti korisniku
da preko Interneta rezerviše bioskopske ulaznice za željene
projekcije.
Takođe je potrebno omogućiti korisniku stalan uvid u
bioskopski repertoar i informacije o bioskopu u kojem
željeni film igra.
21
Dijagram slučajeva upotrebe
korisnik
Pregled filmova
Pregled bioskopa
Rezervacija
22
Dijagram slučaja upotrebeprocesa rezervacije
Odabir filma
Odabir bioskopa
Odabir termina
Rezervacija karata
Potvrda rezervacije
Unos podataka
korisnik
23
Definisanje učesnika
Korisnik je čovek koji koristi sistem, dok je učesnik specifična
uloga koju korisnik ima u komunikaciji sa sistemom
Učesnik – osoba ili veštački entitet (softver ili sistem) koji
učestvuje u slučaju upotrebe
24
Definisanje učesnika
Učesnika je moguće identifikovati na osnovu odgovora na sledeća
pitanja:
Ko će koristiti osnovnu funkcionalnost sistema (primarni
učesnici)
Ko treba da upravlja, administrira i održava sistem (sekundarni
učesnici)
Kome će biti potrebna podrška sistema u obavljanju dnevnih
zadataka
Kojim hardverskim uređajima sistem treba da upravlja
Sa kojim drugim sistemima dotični sistem treba da bude u vezi
Ko ili šta je zainteresovan za rezultate koje sistem proizvodi
25
Definisanje slučajeva upotrebe
Slučaj upotrebe – definiše funkcionalnost sistema sa
stanovišta učesnika – šablon ponašanja delova sistema
Pitanja za učesnika – identifikuju slučajeve upotrebe:
Koje funkcije učesnik zahteva od sistema – šta učesnik treba da
radi?
Da li učesnik treba da čita, kreira, briše, izmeni ili da unese
neke informacije u sistem?
Da li učesnik treba da bude obavešten o događajima u sistemu?
Da li svakodnevni rad učesnika može da se pojednostavi kroz
nove funkcije sistema?
26
Definisanje veze između učesnika i slučajeva upotrebe
Veze koje se uspostavljaju u dijagramu slučajeva upotrebe:
Asocijacija (Association)
Asocijacija između slučajeva upotrebe tipa <<include>>
Asocijacija između slučajeva upotrebe tipa <<extend>>
Generalizacija (Generalization-Inheritance)
Zavisnost (Depedency)
27
Asocijacija
Bidirekciona veza – linija koja spaja učesnike i slučajeve upotrebe
Asocijacija između samih učesnika ili slučajeva upotrebe, definiše
povezanost tih elemenata
Menadžer projekta
Inženjer razvoja
Razvoj sistema
28
Upotreba tipa <<include>>
Slično ponašanje deli se između sličnih slučajeva upotrebe
Veza <<include>> opisuje odnos između slučajeva upotrebe u
kojem jedan slučaj upotrebe koristi usluge drugog
<<include>> <<include>>
<<include>>
Razvoj softvera
Operacije sistema
Razvoj sistemaDefinicija problema
Menadžer projekta Inženjer razvojaklijent
Krajnji korisnik
29
Upotreba tipa <<include>>
Korisnik LoginPristupa Webu
<< include>>
30
Upotreba tipa <<extend>>
“Proširivanjem” jednog sučaja upotrebe opisuje se neka
složenija funkcija sistema
Proširivanje se vrši sa jednim ili više drugih postojećih
slučajeva upotrebe
Ako slučaj A proširuje slučaj B:
i slučaj A i slučaj B mogu da postoje sami
slučaj B može (a ne mora) da bude proširen slučajem A
A B<<extend>>
31
Upotreba tipa <<extends>>
<<extend>> Praćenje finansija
Praćenje dnevnog kumulativaPeriodična kontrola
<<extend>>
32
Generalizacija
Generalizacija – veza između roditelja i deteta – vezana za pojam nasleđivanja – dete nasleđuje osobine roditelja
Generalizacija učesnika – izvedeni učesnik ima sve osobine i ponašanje osnovnog (apstraktnog) učesnika, ali može dodati osobine ili redefinisati ponašanje
zaposlen
Rukovodilac Knjigovođa Kontrolor
33
Generalizacija
Generalizacija slučajeva upotrebe – izvedeni slučaj upotrebe ima
sve osobine i ponašanje apstraktnog slučaja upotrebe, ali može
dodati osobine ili redefinisati ponašanje
Novčane transakcije
UplataIsplata
34
Primer 2.
Operator
Korisnik
Banka
sesija
transakcije
uplata isplata transfer izveštaj
35
Primer 3.
službenik
pacijent
Zakazuje pregled
Otkazuje pregled
Provera pacijentove
dokumentacije
Zahteva lečenje
Različliti načini plaćanja
Plaćanje računa
Tačke proširenja
Naredni tretmani
kartoteka
doktor
Polisa osiguranja
Elektronska prodavnica knjiga
Primer 4.
37
Analiza sistema
Analiza sistema treba da omogući odgovor na pitanje: “Koja je prioritetna funkcija koju treba da ostvari sajt namenjen elektronskoj trgovini?”
Jedan od načina za realizaciju sajta je uočavanje poslovnih ciljeva, na osnovu kojih se razvija lista funkcionalnosti sistema i zahteva za informacijama.
38
Analiza sistema
Poslovni ciljevi predstavljaju jednostavnu listu mogućnosti koje od sajta očekujemo.
Funkcionalnosti sistema predstavljaju listu mogućnosti informacionog sistema koje su potrebne da bi se ostvarili poslovni ciljevi.
Informacioni zahtevi za sistem predstavljaju informacione elemente koje sistem mora da produkuje da bi se realizovali poslovni ciljevi.
Tako formirane liste moraju se dostaviti programerima da bi znali šta menadžer od njih očekuje.
39
Broj posetilaca, posećene stranice,
kupljeni proizvodi.
Sistem za praćenje i izveštaj o
sajtu
Razumeti efikasnost
marketinga.
Inventar proizvoda, ID i kontakt
izdavača.
Upravljanje inventaromMogućnost lakog ažuriranja i
proširivanja kataloga
Korisnikov ID, knjige, datum
porudžbine.
Baza podataka o
porudžbinama
Obezbediti podršku
potrošaču nakon kupovine
knjiga.
Ime, adresa, telefon i e-mail svakog
potrošača. Online registracija
korisnika.
Baza podataka potrošačaPrikupiti podatke o
potrošaču.
Naziv, autor, cena, izdavač i kratak
opis svake knjige.
Baza podataka knjigaNeposredno pretražiti katalog
i dodati knjige u potrošačku
korpu.
Upis svakog korisnika koji pristupi
sajtu.
Veza sa potrošačemPersonalizovati/kastomizovati
svaku knjigu.
Opis knjige, broj zaliha, nivo
inventara.
Baza podataka knjigaObezbediti detaljnije
informacije o knjigama.
Dinamičan tekst i grafički katalog.Digitalni katalogPrikazati knjige.
Informacioni zahteviFunkcionalnost sistemaPoslovni ciljevi
40
Specifikacija zahteva
Korisnika
Registraciju novih korisnika
Prijavljivanje starih korisnika
Pregled kataloga
Pretragu kataloga
Postavljanje odabranih knjiga u potrošačku korpu
Modifikaciju potrošačke korpe
Pražnjenje cele korpe
Administratora
Registraciju novog administratora
Izmenu lozinke registrovanog administratora
Brisanje administratora
Postavljanje novih kategorija u katalog
Uklanjanje kategorija iz kataloga
Postavljanje novih knjiga u katalog
Editovanje atributa knjige u katalogu
Uklanjanje knjiga iz kategorija
Premeštanje knjiga iz jedne u drugu kategoriju
Postavljanje novih izdavača
Modifikaciju atributa postojećih izdavača
41
Prikaz opštih slučajeva upotrebe
Login
Registracija
Pretraga kataloga
Formiranje porudžbine
Modifikacija porudžbine
Pražnjenje cele korpe
Login
Registracija
Modifikacija kategorija
Modifikacija knjiga
Modifikacija administratora
Modifikacija izdavača
korisnik administrator
42
Slučaj korišćenja: Modifikacija podataka
43
Slučaj korišćenja: Pretraga
44
Slučaj korišćenja: Logovanje administratora na sistem
Unos lozinke
provera lozinke
Dijagrami aktivnosti
46
Razvoj dijagrama aktivnosti
Poslovni proces – slučaj upotrebe – posmatra se kao sistem koji ima svoja stanja u kojima se obavljaju aktivnosti, dok prelaze iz jednog u drugo stanje koje diktiraju događaji
Prikazuje sekvencijalni tok aktivnosti
Sastoji se od:
Stanja
Akcija
Prelaza
Proces Razvoja dijagrama aktivnosti sadrži:
Definisanje plivačkih staza
Definisanje stanja dijagrama aktivnosti
Definisanje tranzicija
47
Definisanje stanja dijagrama aktivnosti
Stanje dijagrama aktivnosti može da predstavlja:
Akciju – ne može biti dekomponovana, traje kratko vreme, ne
može se prekidati
Aktivnost – ima trajanje, može se prekidati zbog nekih
događaja, može se dekomponovati
Pseudostanje ili
Stanje toka objekta
Oznaka stanja je jedinstvena:
Naziv stanja
48
Definisanje stanja dijagrama aktivnosti
Definisanje pseudostanja – stanja prelaza
Početno stanje
Krajnje stanje
Stanje odluke - grananje
Sinhronizacija
49
Definisanje tranzicija
Tranzicija - prelazak iz jednog u drugo stanje – prouzrokuje (okida) neki događaj
Događaji mogu da budu:
Spoljni – generišu se van sistema – generišu ga učesnici
Kraj aktivnosti
Vremenski – spoljni ali bez učesnika
Upravljački – generiše rukovodilac posla
Tranzicija prouzrokuje događaj koji sadrži uslove, argumente i akcije
Događaj – poruka – ako su očigledne ne prikazuju se na dijagramu
Događaj 1 (argument) [uslov 1] / Akcija 1
50
Prikaz grananja
A
C
[uslov]
[not uslov]
B
grananje
51
Prikaz grananja
postavi iterator
radi()
promeni iterator
[kraj]
[not kraj]
početno stanje
završno stanje
52
Sinhronizacija
Sinhronizacija – zadebljana horizontalna linija
Račvanja (fork) i udruživanja (join) niti – obavljaju se u
sinhronizacionim tačkama
Tranzicije koje ulaze u sinhronizaciju su uslov za paralelno
obavljanje tranzicija koje iz nje izlaze – jedna aktivnost
“čeka” na ispunjenje uslova (“pristizanje” svih događaja) za
njeno izvršenje
53
Prikaz sinhronizacije
Priprema
Aktivnost 1 Aktivnost 2
Finalizacija
Sinhronizaciona tačkaRačvanje (fork)
Udruživanja (join)
54
55
Definisanje plivačkih staza
Dijagram aktivnosti deli se u odgovarajuće logičke celine –
plivačke staze – definišu odgovornost pojedinih objekata za
izvršenje odgovarajućih akcija
Svaka staza – navode se učesnici, aktivnosti – “radna lista” –
definisana u okviru opisa radnog mesta prilikom opisa organizacije
Stanja pripadaju stazama, a tranzicije mogu da prelaze iz jedne
staze u drugu
56
Definisanje plivačkih staza
Ime 1 Ime 2 Ime 3
A
B
C
D
Plivačka
staza
57
Primer
Isporuka
korisnik prodaja magacin
Zahtev za isporukom
Prijem porudžbine
Plaćanje
Isporuka Preuzimanje
robe
Order [placed] Order
[entered]
Order [filled]
Order [delivered]
Priprema isporuke
58
Korisnik Automat Banka
Postavi karticu
Unesi PIN
Podižem iznos
Preuzmi novac
Uzmi karticu
Identifikacija
Provera stanja na računu
Umanji iznos na računu
Prikazuje stanje na računu
Vraća karticu
Dijagrami aktivnosti
Recommended