Objektno orijentisano projektovanje - Visoka poslovna Å¡kola ...
Objektno orijentisano projektovanje - Visoka poslovna Å¡kola ...
Objektno orijentisano projektovanje - Visoka poslovna Å¡kola ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Objektno</strong> <strong>orijentisano</strong><br />
<strong>projektovanje</strong><br />
Dr Borislav Jošanov, profesor<br />
<strong>Visoka</strong> <strong>poslovna</strong> škola strukovnih studija<br />
Novi Sad
Očekivanja?<br />
Upoznavanje sa objektno orijentisanim<br />
načinom razmišljanja<br />
Korišćenje grafičkih alata za prezentacije,<br />
analize i dizajn<br />
Detaljnije upoznavanje UML-a<br />
Rukovanje programskim alatom Rational<br />
Rose<br />
Izrada skica i projektnih dokumenata<br />
prema UML konceptu
Literatura (I)<br />
Martin Fowler: UML ukratko, prevod 3.<br />
izdanja, Mikro knjiga<br />
Grady Booch, James Rumbaugh, Ivar<br />
Jacobson: UML Vodič za korisnike, CET<br />
Matt Weisfeld: <strong>Objektno</strong> orijentisani način<br />
mišljenja, CET<br />
Terry Quatrani: Vizuelno modelovanje<br />
Rational Rose 2002 i UML, CET
Literatura (II)<br />
Dragan Milićev: <strong>Objektno</strong> <strong>orijentisano</strong><br />
modelovanje na jeziku UML, Mikro knjiga<br />
Ivana Stanojević, , Dušan Surla: Uvod u<br />
objedinjeni jezik modeliranja, Mala knjiga<br />
http://www.is.pmf.uns.ac.rs/bobericd/Knji<br />
ga_iz_UML.zip
Bodovi<br />
Prisustvo na predavanjima i vežbama<br />
– 5<br />
bodova<br />
Kolokvijum – 20 bodova<br />
Rad na predavanjima i vežbama<br />
– 35<br />
bodova<br />
Izrada studije slučaja<br />
– 10 bodova<br />
Pismeni ispit – 30 bodova
Perfekcija nije kada se<br />
nema šta dodati, već<br />
kada se nema šta<br />
izostaviti.<br />
Antoine de Saint-Exup<br />
Exupéry
Ideja OOP<br />
80% troškova za održavanje, 20% za razvoj<br />
Zasovana na:<br />
iskustvenom prepoznavanju objekata i<br />
njihovih obeležja<br />
razlikovanju celine objekta od njegovih<br />
delova<br />
formiranju klasa objekata uočavanjem<br />
razlika meñu njima
Odnos strukturiranog i OO<br />
projektovanja<br />
SP se zasniva na skupu funkcija koje dele<br />
zajedničko stanje<br />
OOP zasnovano je na sakrivanju, objekti<br />
se formiraju u interakcijama, oni imaju<br />
privatna stanja
Karakteristike SP<br />
Modeluju se rešenja enja (a ne problemi)<br />
Problemi se rešavaju u algoritamskim koracima<br />
na različitim itim hijerarhijskim nivoima<br />
Izmene u programima su izmene i u<br />
algoritmima<br />
Različite ite lokalizacije jedne izmene<br />
Nakon izmena neophodna provera šireg<br />
konteksta
Karakteristike OOP<br />
Modeluju se problemi, a ne rešenja<br />
enja<br />
Problemi se razlažu u na objekte<br />
Za objekte se odreñuje šta rade -> > crne kutije<br />
Nad objektima – spoljne akcije<br />
Izmene i dodavanja – u odreñenom objektu<br />
Provera – samo za menjani objekat<br />
Fleksibilno dodavanje novih objekata<br />
Laka mogućnost ponovnog korišćenja
Istorija OO programskih jezika<br />
1961. Dahl, Myhrhang i Nygaard objavljuju<br />
jezik Simula-67: uvodi u<br />
koncepte objekta i<br />
nasleñivanje – svaki objekat sopstveno<br />
ponašanje anje i podaci<br />
Xerox ranih 70-ih objavljuje Smaltalk,<br />
potpuno zasnovan na OO paradigmi<br />
1982. Stroustrup objavljuje C++ koji uvodi<br />
klase i enkapsulaciju<br />
1991. James Gosling u Sun Microsystems<br />
razvija Javu, univerzalnu softversku platformu<br />
koja ne zavisi od hardvera, zvanično<br />
no<br />
objavljena 1996.
Nedostaci OO programiranja<br />
OO jezici nemaju efikasna sredstva za<br />
specificiranje i dokumentovanje sistema<br />
Nedovoljno apstraktni koncepti OO jezika<br />
Tekstualne specifikacije manje su efikasne<br />
od vizuelnih<br />
OO programiranje ne pruža a podršku za sve<br />
faze razvoja ni prelaze iz jedne u drugu<br />
Nema efikasna sredstva za dobru<br />
dokumentaciju softvera
Zašto modelovati?<br />
Da bismo dobili dobar softver koji zadovoljava<br />
sve veće e potrebe korisnika<br />
Angažovanje korisnika na disciplinovan način<br />
radi izlaganja stvarnih zahteva sistema<br />
Da bismo razlikovali “manje važno<br />
no” od<br />
“nevažnog”<br />
Da bismo razvili softver trajnog kvaliteta<br />
Da bismo brzo i efikasno razvili softver<br />
Da bismo vizuelizovali i kontrolisali arhitekturu<br />
sistema<br />
Da bismo bolje razumeli sistem koji razvijamo
Funkcije metoda OO modelovanja<br />
Razvoj modela softvera na višem nivou<br />
apstrakcije<br />
Specifikacija modela pomoću u vizuelnih,<br />
grafičkih notacija<br />
Transformacija apstraktnih, vizuelnih<br />
modela u implementacione forme u<br />
programskim jezicima
Modelovanje<br />
Centralna aktivnost u izgradnji dobrog<br />
softvera<br />
Model je pojednostavljen prikaz realnosti<br />
Pravi se da bi se bolje razumeo sistem koji se<br />
gradi<br />
Kompleksan sistem se bez modela ne može<br />
razumeti kao kompaktna celina<br />
OOM je alternativa tradicionalnom,<br />
algoritamskom modelovanju
Ciljevi modelovanja<br />
Model služi i da prikažemo kakav sistem jeste<br />
ili kakav želimo da bude (vizuelizacija)<br />
Modelom se definiše e struktura i ponašanje<br />
anje<br />
sistema (specifikacija)<br />
Model predstavlja uzor (šablon)(<br />
kako treba<br />
konstruisati sistem (konstrukcija)<br />
Model sadrži i dokumentaciju projektnih<br />
odluka (dokumentacija)
Modelovanje kompleksnih sistema<br />
Ljudi imaju ograničenja u sposobnosti<br />
razumevanja kompleksnih problema<br />
Modelovanjem problem sužavamo na<br />
pojedine aspekte: pristup “podeli pa vladaj”<br />
Modelovanjem se pojačava ava ljudski intelekt<br />
Dobar izbor modela omogućava rad na<br />
višem nivou apstrakcije<br />
Softverske kompanije malo rade na polju<br />
formalnog modelovanja
Principi modelovanja<br />
Izbor modela ima ključan uticaj na rešavanje<br />
i oblikovanje rešenja<br />
enja<br />
Svaki model može e imati različite ite nivoe<br />
detalja<br />
Najbolji modeli su povezani sa realnim<br />
svetom<br />
Nijedan model nije dovoljan sam za sebe,<br />
svaki složeniji sistem najbolje se opisuje<br />
skupom nezavisnih modela
OO modelovanje<br />
Glavni sastavni delovi softverskog sistema su<br />
objekti i klase<br />
Objekat je opšte sredstvo u rečniku prostora<br />
problema i njegovog rešenja<br />
enja<br />
Klasa je opšti opis skupa objekata<br />
Svaki objekat ima identitet, stanje i ponašanje<br />
anje<br />
Arhitektura OO modela se sastoji iz korisničkog<br />
kog<br />
interfejsa, osnovnih programa i baze podataka
Istorija OO metodologija (1)<br />
Do sredine 80-ih dominantni metodološki<br />
pristupi zasnovani na specifikaciji funkcija<br />
sistema<br />
U 80-im nastaju ideje o grafičkim jezicima<br />
1989-1994. 1994. od 10 postojećih razvijeno više<br />
od 50 OO metoda, , meñu m<br />
njima:<br />
HP: Fusion – integralna metoda 2. generacije<br />
Sally Shlaer i Tim Malor: životni ciklus<br />
objekata<br />
Rebecca Wirfs-Brock: <strong>projektovanje</strong> voñeno<br />
odgovornostima
Istorija OO metodologija (2)(<br />
OOA/OOD – Object Oriented Analysis/Object<br />
Oriented Design,<br />
autori Yourdon & Whitehead,<br />
Coad & Yourdon
Istorija OO metodologija (3)<br />
Booch: OO Analsis – izražajna ajna tokom<br />
projektovanja i konstrukcije projekta<br />
Rumbaugh: Object Modeling Technique –<br />
najkorisnija za analizu i IS sa velikom<br />
količinom inom podataka<br />
Jacobson: OO Software Engineering –<br />
podrška korisničkim kim funkcijama za definisanje<br />
projektnih zahteva<br />
1994. Rumbaugh prelazi iz GE u Boochov<br />
Rational: Unified Method<br />
1995. Rational kupuje Objectory - pridružuje<br />
uje<br />
im se Jacobson
Istorija OO metodologija (4)<br />
1996. UML – Unified Modeling Language<br />
Object Management Group (OMG) pokreće<br />
akciju standardizacije: radnu grupu vode<br />
Mary Loomis i Jim Odell<br />
januara 1997. dostavljeno više e predloga i<br />
njihovim spajanjem prihvaćen UML 1.1<br />
danas aktuelan UML 2.22<br />
three amigos<br />
igos: : Grady Booch, Jim Rumbaugh &<br />
Ivar Jacobson
Booch<br />
Rumbaugh<br />
Jacobson<br />
Odell<br />
Klasifikacija<br />
Meyer<br />
Početni i krajnji uslovi<br />
Shlaer-Meyer<br />
Početni i krajnji uslovi<br />
UML<br />
Harel<br />
Dijagrami stanja<br />
Gamma idr<br />
Okviri, mustre i komentari<br />
Embly<br />
Singleton klase<br />
Fusion<br />
Opisi operacija, numeracija poruka<br />
Wirfs-Brock<br />
Odgovornosti
Primena OO projektovanja<br />
PowerBuilder i Visual Basic realizovani u<br />
potpunosti na OO paradigmi<br />
Primena OO paradigme kod legatnih IS:<br />
objekti se koriste kao omotači<br />
Novi IS najčešće e se razvijaju na OO<br />
paradigmi<br />
Pojava Weba i Jave u potpunosti donose OO<br />
paradigmu: Internetom putuju objekti
UML i elektronsko poslovanje<br />
radna grupa EU TMWG (Techniques(<br />
and<br />
Methodology Working Group) predložila<br />
je<br />
UML kao tehniku koja najviše e odgovara EP<br />
projekat t Instituta za primenjene<br />
računarske nauke i informacione sisteme<br />
iz Beča odabralo je 4 koncepta sa kojima<br />
se optimalno rešavaju problemi EP
Komunikacija u decentralizovanom i<br />
distribuiranom okruženju<br />
u objektno <strong>orijentisano</strong>m razvoju zasniva se na<br />
SOAP (Simple Object Access Protocol)<br />
protokolu<br />
objekti u razmeni opisuju se kao WSDL (Web<br />
Services Description Language) dokumenti<br />
XML DTD kontrolisana grupa XML dokumenata<br />
napisana pomoću u WSDL
Ciljevi UML<br />
Modelovanje sistema od koncepta do izvršnih<br />
celina korišćenjem OO tehnika<br />
Primenljivost na probleme glomaznosti u<br />
složenim sistemima sa kritičnim zadacima<br />
Stvaranje jezika za modelovanje upotrebljivog<br />
i za ljude i za računare<br />
Izrada metamodela sistema koji projektujemo<br />
ili programiramo
Načini korišćenja UML-a<br />
Izrada skica<br />
Izrada projekta<br />
Programiranje
Izrada skica<br />
Ubedljivo najčešća a primena<br />
Koristi se kao pomoćno sredstvo za<br />
opisivanje nekih aspekata sistema<br />
U razvoju i reverzibilnoj analizi<br />
Selektivan izbor u primeni<br />
Koristi se najčešće e za opise alternativa,<br />
neformalno i dinamički<br />
Korisne su u dokumentaciji, radi informisanja<br />
Ne pridržava se strogo pravila UML-a
Izrada projekta<br />
Kreiraju se potpuni opisi projekata i opisi<br />
odluka<br />
Projektant kreira uputstva programerima<br />
Analogija sa tehničkim crtežima inženjera koji<br />
se dostavljaju drugima<br />
Obuhvataju sve detalje ili samo odreñenu<br />
oblast, obično do interfejsa<br />
Često se primenjuje pomoću u CASE alata<br />
Koriste se u reverzibilnoj analizi: iz izvornog<br />
koda kreiraju dijagrame i tumačenja smeštaju<br />
u skladišta
Programiranje pomoću u UML-a<br />
CASE alati generišu u kostur programskog koda<br />
U nekim slučajevima generiše e se kompletan<br />
programski kod<br />
Zahteva veoma složene alate<br />
Modelovanje ponašanja: anja: dijagramima<br />
interakcije, stanja i aktivnosti<br />
Programeri crtaju UML dijagrame koji se<br />
neposredno prevode u izvršni kod (UML-om<br />
se opisuje izvorni kod)
Arhitektura zasnovana na modelu<br />
Model Driven Architecture (MDA) je<br />
standardna platforma za razvoj softvera u<br />
kompletnom životnom ciklusu dizajna,<br />
razvoja, i integracije aplikacija zasnovana na<br />
upotrbi modela u toku razvoja<br />
Standardni pristup korišćenja UML kao<br />
programskog jezika<br />
Standardom MDA upravlja OMG (kao i UML)
PIM i PSM<br />
Arhitektura MDA deli razvoj u PIM i PSM<br />
PIM (Platform Independent Model) je UML<br />
model koji ne zavisi od tehnologije<br />
PSM (Platform Specific Model) model l sistema<br />
namenjen odreñenom izvršnom okruženju i<br />
sadrži i specifične tehnološke informacije i<br />
kreira se za svaku izvršnu platformu<br />
Nakon toga svaki PSM se transformiše e u<br />
programski kod koji će e se izvoditi na toj<br />
platformi
CIM<br />
Iznad PIM formira se Computation<br />
Independent Model (CIM)<br />
Ovim modelom se opisuje sitem u svom<br />
poslovnom domenu i u njemu se opisuje<br />
kako de očekuje o<br />
da sistem treba da radi<br />
Ne sadrži i detalje konstrukcije
CIM<br />
ručna<br />
transformacija<br />
T<br />
PIM<br />
T<br />
PSM<br />
PSM<br />
T<br />
T<br />
kod<br />
kod
Od CIM ka PIM<br />
Poslovni procesi<br />
Slučajevi korišćenja
Izvršni UML<br />
Autor je Steve Mellor<br />
Sličan je MDA arhitekturi<br />
Počinje sa modelom ekvivalentnom PIM<br />
Prevodilac modela pretvara taj model u<br />
konačan an sistem (ne koristi PSM)<br />
Prevodilac modela zasnovan je na ponovo<br />
upotrebljivim arhetipovima<br />
Arhetip opisuje kako da izvršni UML model<br />
pretvorimo u kod za odreñenu platformu<br />
(koliko platformi toliko arhetipova)
Notacije i metamodeli<br />
UML definiše e notaciju i metamodel<br />
Notacija je skup grafičkih elemenata koji se<br />
koriste u modelima, tj. sintaksa jezika<br />
Grafički jezici modelovanja obično nisu<br />
strogi, a notacija je više e intuitivna<br />
Metamodel je dijagram koji precizno definiše<br />
koncepte jezika<br />
Od vitalnog je značaja aja za korisnike UML-a<br />
kao programskog jezika
Postupak razvoja softvera<br />
UML nastao iz više e OO metoda, čiji su se autori<br />
lako složili oko jezika modelovanja, ali nisu oko<br />
postupka razvoja softvera<br />
Dogovori o postupku razvoja odloženi za<br />
kasnije<br />
Najčešće e se spominje objedinjeni razvojni<br />
postupak kompanije Rational: USDP<br />
2 ključne grupe postupaka: kaskadni i iterativni<br />
Razlikuju se u načinu podele projekta u manje<br />
delove
Kaskadni postupak<br />
Najčešći i naziv: model vodopada<br />
Smatra se klasičnim i zastarelim<br />
Deli projekat u delove na osnovu aktivnosti<br />
Obavezne aktivnosti u izradi programa:<br />
analiza zahteva, <strong>projektovanje</strong>, pisanje<br />
programa i testiranje<br />
Česti su povratni tokovi meñu aktivnostima
Iterativni postupak<br />
Nazivi: postupni, spiralni i evolutivni<br />
Moderniji, blizak OO pristupu<br />
Deli projekat na delove po funkcijama<br />
Istraživanje prethodi iterativnom postupku<br />
U svakoj iteraciji razvoj podjednakih grupa<br />
zahteva<br />
Svaka iteracija donosi gotov integrisan<br />
softver<br />
Vremenska ograničenja za pojedine funkcije<br />
Hibridni postupak: etapna isporuka
Problemi ponovnog rada<br />
Ponovno pisanje koda u narednim iteracijama<br />
Često je efikasnije ponovo napisati neko<br />
“krpiti” kod u kasnijim iteracijama<br />
Automatizovani regresivni testovi brzo<br />
otkrivaju ošteo<br />
tečenja enja nastala od izmena: xUnit<br />
Prerañivanje (refactoring) je tehnika malih,<br />
disciplinovanih promena postojećeg eg koda<br />
Neprekidna integracija je sinhronizovan i<br />
automatizovan postupak integracije koda
Predvidljivo planiranje<br />
Glavna pitanja korisnika: koliko će e koštati i<br />
koliko će e trajati izrada softvera?<br />
Predvidljivi pristup: procene u ranim fazama<br />
Veća a predvidljivost postiže e se u toku razvoja<br />
Uz čvrst plan i dobro prikupljene zahteve<br />
očekuju se manja odstupanja<br />
Izmene zahteva u kasnim fazama remete<br />
osnove previdljivog planiranja<br />
Rano zamrzavanje zahteva može e dovesti do<br />
softvera koji ne odgovara korisniku
Prilagodljivo planiranje<br />
Zasniva se na principu neizbežnosti nosti izmena<br />
zahteva i da je često veoma teško precizno<br />
definisati zahteve<br />
Neprekidne promene su realnost i promena se<br />
smatra konstantom razvoja u cilju dobijanja<br />
najboljeg softvera<br />
Promene su kontrolisane, ali projekat nije<br />
predvidljiv<br />
Korisnici sarañuju sa timom u periodičnim<br />
procenama funkcionalnosti, rokova i cene
Unificirani proces razvoja softvera<br />
USDP: autori Jacobson, Booch i Rumbaugh<br />
Objavljen 1999. godine<br />
Proces klasificiranja iteracija u 4 grupe:<br />
početne iteracije interakcija sa stekholderima<br />
razrañene iteracije želja i potreba<br />
iteracije konstruisanja inicijalnih operacionih<br />
mogućnosti<br />
prelazne iteracije kompletiranja proizvoda
implementacija<br />
test<br />
inicijalni<br />
plan<br />
USDP<br />
zahtevi analiza i<br />
dizajn<br />
razvoj<br />
planiranje<br />
procena
Rezultati USDP<br />
Model korisničkih kih slučajeva: opisuje kako će<br />
aplikacija biti korištena<br />
Model analize: sadrži i osnovne klase rešenja<br />
enja<br />
Model dizajna: opisuje veze izmeñu klasa i<br />
odabranih objekata<br />
Model razvoja: alokacija softvera po računarima<br />
Implementacioni model: opisuje kako će e kod<br />
biti organizovan<br />
Testni model: sadrži i komponente, testne<br />
procedure i slučajeve
Stereotipna ponašanja<br />
anja<br />
Identične ne procedure u ponašanju anju 2 ili više<br />
objekata<br />
Elementi: uloge, odnosi, strukture i funkcije<br />
Integrisane celine: šabloni, stereotipi,<br />
obrasci, design patterns (DP) -> višestruka<br />
primena
Obrasci (Design Patterns)<br />
Kombinacija komponenti (obično klasa i<br />
objekata) za koje je utvrñeno da rešavaju<br />
odreñene zajedničke probleme dizajna<br />
Opisuju rezultate razvoja, tj. primere projekata<br />
Sadrže e rezultate rada najiskusnijih projektanata<br />
Erich Gamma sa trojicom kolega (Gang of Four)<br />
je 1999. opisao 23 DP<br />
Opisi sadrže e detalje zajedničkog rada objekta,<br />
prednosti, ograničenja, odstupanja i savete za<br />
realizaciju
Kategorije obrazaca<br />
Strukturni – sadrže e sastav rukovanja<br />
objektom om kao pojedinačnim nim entitetom<br />
Kreativni – opisuju kreiranje<br />
kompleksnih objekata<br />
Bihejvjuiralni<br />
– ukazuju na ponašanje<br />
anje<br />
objekata<br />
Kombinovani – na osnovu prethodnih<br />
kategorija
Izgled obrazaca<br />
Komponente sa opštim, karakterističnim za<br />
različite ite vrste softvera<br />
Mogućnost integracija u heterogene<br />
arhitekture softvera<br />
Adekvatna dokumentacija: namena,<br />
alternativni nazivi, kratak scenario, situacije<br />
primene, struktura, učesnici, u<br />
njihova<br />
saradnja, posledice, uputstvo za primenu,<br />
primeri
Osobine obrazaca<br />
Obrazac je više e od modela, jer sadrži<br />
objašnjenja i razloge zašto je baš takav<br />
U njemu se jasno opisuje problem i zašto<br />
se taj problem rešava<br />
Sadrži i opise u kojim situacijama radi, a u<br />
kojim ne<br />
Pokazuju šta je dobar model i kako ga<br />
napraviti: podučavaju na primeru
UML i postupak razvoja softvera<br />
Grafički jezici se obično koriste u kaskadnom<br />
razvoju<br />
Služe e za kreiranje dokumentacije koja se<br />
prenosi od faze do faze<br />
Upotreba UML ne podrazumeva obaveznu<br />
izradu dokumentacije ni upotrebu CASE alata<br />
UML dijagrami se često koriste za skice na<br />
sastancima<br />
U svakom postupku sprovode se analiza<br />
zahteva, <strong>projektovanje</strong>, programiranje i<br />
testiranje
Analiza zahteva<br />
Pokušava da otkrije šta korisnici očekuju o<br />
od<br />
sistema:<br />
Dijagrami slučajeva korišćenja opisuju kako<br />
korisnici komuniciraju sa sistemom<br />
Dijagram klasa je sredstvo za preciznu izradu<br />
rečnika iz neke oblasti<br />
Dijagram aktivnosti može e opisivati rokove<br />
poslova, njihov kontekst ili aktivnosti<br />
Dijagram stanja se moše e koristiti za opis<br />
životnog ciklusa nekog pojma
Projektovanje<br />
Dijagrami mogu, korišćenjem notacije,<br />
sadržati ati viže e tehničkih pojedinosti:<br />
Dijagrami klasa ih prikazuju unutar softvera i<br />
njihove meñusobne veze<br />
Dijagrami sekvence opisuju scenarije unutar<br />
programa, alternativa su CRC kartice<br />
Dijagrami paketa pokazuju opštu organizaciju<br />
softvera<br />
Dijagrami stanja služe e za opis klasa sa<br />
složenim<br />
životnim ciklusom<br />
Dijagrami razmeštanja prikazuju fizički<br />
raspored softverskih modula
CRC kartice<br />
Dijagrami klase-odgovornosti<br />
odgovornosti-saradnje: saradnje: Class-<br />
Responsibility-Collaboration<br />
Osmislio Ward Cunningham krajem 80-ih<br />
Služe e za ispitivanje interakcija izmeñu objekata<br />
Veoma popularna tehnika, nije deo UML-a<br />
Kartice sadrže e ime klase u zaglavlju i 2 kolone:<br />
Odgovornost je kratak opis šta objekat treba da<br />
uradi – aktivnosti, znanje, odluke<br />
U koloni za saradnju upisuju se druge klase sa<br />
kojima treba da se realizuje odgovornost
Primer CRC kartice<br />
Porudžbina<br />
Primi upit<br />
Proveri zalihe<br />
Odredi cenu<br />
Proveri da li je plaćeno<br />
Isporuči i robu<br />
Stavka upita<br />
Skladište<br />
Kupac<br />
Uplata<br />
Vozilo
Način rada<br />
U kaskadnom postupku: dijagrami se kreiraju<br />
i obavljaju aktivnosti po fazama<br />
UML se koristi za pravljenje projekta<br />
U iterativnom postupku: dijagrami se koriste<br />
za pravljenje skica i projekta<br />
Skice su grubi projekat, kreiraju se u toku<br />
njegovog osmišljavanja, u svakoj fazi<br />
UML projekat se pravi na početku iteracije, na<br />
osnovu čega se programira<br />
Ne kreće e se od početka, već se menjaju<br />
postojeći i dokumenti, sa naglaskom na<br />
iteraciji
Dokumentacija<br />
Formira se izborom iz radnih beleški,<br />
uglavnom skica, a detaljna se kreira nakon<br />
pisanja programskog koda<br />
Dijagram paketa je logička karta puteva kroz<br />
sistem<br />
Dijagram rasporeñivanja prikazuje fizčku<br />
sliku sistema na visokom nivou<br />
Dijagram klasa treba da bude podržan<br />
dijagramima interakcije<br />
Dijagram mašine stanja koristi se za složene<br />
životne cikluse<br />
Dijagram aktivnosti za najsloženije algoritme
Razumevanje preuzetog koda<br />
Opisi delova koda koje je pisao neko drugi<br />
Formiraju se njihove skice<br />
Obično se kreiraju dijagrami klasa i<br />
dijagrami sekvenci
Da nazdravimo za kraj idealnog prvog sastanka.
Change language