Objektno orijentisano projektovanje. Dr Borislav Jošanov, profesor Visoka poslovna škola strukovnih studija Novi Sad

Size: px

Start display at page:

Download "Objektno orijentisano projektovanje. Dr Borislav Jošanov, profesor Visoka poslovna škola strukovnih studija Novi Sad"

Jerome Thornton
5 years ago
Views:

1 Objektno orijentisano projektovanje Dr Borislav Jošanov, profesor Visoka poslovna škola strukovnih studija Novi Sad

2 Očekivanja? Upoznavanje sa objektno orijentisanim načinom razmišljanja Korišćenje grafičkih alata za prezentacije, analize i dizajn Detaljnije upoznavanje UML-a Rukovanje programskim alatom Rational Rose Izrada skica i projektnih dokumenata prema UML konceptu

3 Literatura (I) Martin Fowler: UML ukratko, prevod 3. izdanja, Mikro knjiga Grady Booch, James Rumbaugh, Ivar Jacobson: UML Vodič za korisnike, CET Matt Weisfeld: Objektno orijentisani način mišljenja, CET Terry Quatrani: Vizuelno modelovanje Rational Rose 2002 i UML, CET

4 Literatura (II) Dragan Milićev: Objektno orijentisano modelovanje na jeziku UML, Mikro knjiga Ivana Stanojević,, Dušan Surla: Uvod u objedinjeni jezik modeliranja, Mala knjiga ga_iz_uml.zip

5 Bodovi Prisustvo na predavanjima i vežbama 5 bodova Kolokvijum 20 bodova Rad na predavanjima i vežbama 35 bodova Izrada studije slučaja 10 bodova Pismeni ispit 30 bodova

6 Perfekcija nije kada se nema šta dodati, već kada se nema šta izostaviti. Antoine de Saint-Exup Exupéry

10 Ideja OOP 80% troškova za održavanje, 20% za razvoj Zasovana na: iskustvenom prepoznavanju objekata i njihovih obeležja razlikovanju celine objekta od njegovih delova formiranju klasa objekata uočavanjem razlika meñu njima

11 Odnos strukturiranog i OO projektovanja SP se zasniva na skupu funkcija koje dele zajedničko stanje OOP zasnovano je na sakrivanju, objekti se formiraju u interakcijama, oni imaju privatna stanja

12 Karakteristike SP Modeluju se rešenja enja (a ne problemi) Problemi se rešavaju u algoritamskim koracima na različitim itim hijerarhijskim nivoima Izmene u programima su izmene i u algoritmima Različite ite lokalizacije jedne izmene Nakon izmena neophodna provera šireg konteksta

13 Karakteristike OOP Modeluju se problemi, a ne rešenja enja Problemi se razlažu u na objekte Za objekte se odreñuje šta rade -> > crne kutije Nad objektima spoljne akcije Izmene i dodavanja u odreñenom objektu Provera samo za menjani objekat Fleksibilno dodavanje novih objekata Laka mogućnost ponovnog korišćenja

14 Istorija OO programskih jezika Dahl, Myhrhang i Nygaard objavljuju jezik Simula-67: uvodi u koncepte objekta i nasleñivanje svaki objekat sopstveno ponašanje anje i podaci Xerox ranih 70-ih objavljuje Smaltalk, potpuno zasnovan na OO paradigmi Stroustrup objavljuje C++ koji uvodi klase i enkapsulaciju James Gosling u Sun Microsystems razvija Javu, univerzalnu softversku platformu koja ne zavisi od hardvera, zvanično no objavljena 1996.

15 Nedostaci OO programiranja OO jezici nemaju efikasna sredstva za specificiranje i dokumentovanje sistema Nedovoljno apstraktni koncepti OO jezika Tekstualne specifikacije manje su efikasne od vizuelnih OO programiranje ne pruža a podršku za sve faze razvoja ni prelaze iz jedne u drugu Nema efikasna sredstva za dobru dokumentaciju softvera

17 Zašto modelovati? Da bismo dobili dobar softver koji zadovoljava sve veće e potrebe korisnika Angažovanje korisnika na disciplinovan način radi izlaganja stvarnih zahteva sistema Da bismo razlikovali manje važno no od nevažnog Da bismo razvili softver trajnog kvaliteta Da bismo brzo i efikasno razvili softver Da bismo vizuelizovali i kontrolisali arhitekturu sistema Da bismo bolje razumeli sistem koji razvijamo

18 Funkcije metoda OO modelovanja Razvoj modela softvera na višem nivou apstrakcije Specifikacija modela pomoću u vizuelnih, grafičkih notacija Transformacija apstraktnih, vizuelnih modela u implementacione forme u programskim jezicima

19 Modelovanje Centralna aktivnost u izgradnji dobrog softvera Model je pojednostavljen prikaz realnosti Pravi se da bi se bolje razumeo sistem koji se gradi Kompleksan sistem se bez modela ne može razumeti kao kompaktna celina OOM je alternativa tradicionalnom, algoritamskom modelovanju

20 Ciljevi modelovanja Model služi i da prikažemo kakav sistem jeste ili kakav želimo da bude (vizuelizacija) Modelom se definiše e struktura i ponašanje anje sistema (specifikacija) Model predstavlja uzor (šablon)( kako treba konstruisati sistem (konstrukcija) Model sadrži i dokumentaciju projektnih odluka (dokumentacija)

21 Modelovanje kompleksnih sistema Ljudi imaju ograničenja u sposobnosti razumevanja kompleksnih problema Modelovanjem problem sužavamo na pojedine aspekte: pristup podeli pa vladaj Modelovanjem se pojačava ava ljudski intelekt Dobar izbor modela omogućava rad na višem nivou apstrakcije Softverske kompanije malo rade na polju formalnog modelovanja

22 Principi modelovanja Izbor modela ima ključan uticaj na rešavanje i oblikovanje rešenja enja Svaki model može e imati različite ite nivoe detalja Najbolji modeli su povezani sa realnim svetom Nijedan model nije dovoljan sam za sebe, svaki složeniji sistem najbolje se opisuje skupom nezavisnih modela

23 OO modelovanje Glavni sastavni delovi softverskog sistema su objekti i klase Objekat je opšte sredstvo u rečniku prostora problema i njegovog rešenja enja Klasa je opšti opis skupa objekata Svaki objekat ima identitet, stanje i ponašanje anje Arhitektura OO modela se sastoji iz korisničkog kog interfejsa, osnovnih programa i baze podataka

24 Istorija OO metodologija (1) Do sredine 80-ih dominantni metodološki pristupi zasnovani na specifikaciji funkcija sistema U 80-im nastaju ideje o grafičkim jezicima od 10 postojećih razvijeno više od 50 OO metoda,, meñu m njima: HP: Fusion integralna metoda 2. generacije Sally Shlaer i Tim Malor: životni ciklus objekata Rebecca Wirfs-Brock: projektovanje voñeno odgovornostima

25 Istorija OO metodologija (2)( OOA/OOD Object Oriented Analysis/Object Oriented Design, autori Yourdon & Whitehead, Coad & Yourdon

27 Istorija OO metodologija (3) Booch: OO Analsis izražajna ajna tokom projektovanja i konstrukcije projekta Rumbaugh: Object Modeling Technique najkorisnija za analizu i IS sa velikom količinom inom podataka Jacobson: OO Software Engineering podrška korisničkim kim funkcijama za definisanje projektnih zahteva Rumbaugh prelazi iz GE u Boochov Rational: Unified Method Rational kupuje Objectory - pridružuje uje im se Jacobson

dostavljeno više e predloga i njihovim spajanjem

28 Istorija OO metodologija (4) UML Unified Modeling Language Object Management Group (OMG) pokreće akciju standardizacije: radnu grupu vode Mary Loomis i Jim Odell januara dostavljeno više e predloga i njihovim spajanjem prihvaćen UML 1.1 danas aktuelan UML 2.22 three amigos igos: : Grady Booch, Jim Rumbaugh & Ivar Jacobson

29 Booch Rumbaugh Jacobson Odell Klasifikacija Meyer Početni i krajnji uslovi Shlaer-Meyer Početni i krajnji uslovi UML Harel Dijagrami stanja Gamma idr Okviri, mustre i komentari Embly Singleton klase Fusion Opisi operacija, numeracija poruka Wirfs-Brock Odgovornosti

30 Primena OO projektovanja PowerBuilder i Visual Basic realizovani u potpunosti na OO paradigmi Primena OO paradigme kod legatnih IS: objekti se koriste kao omotači Novi IS najčešće e se razvijaju na OO paradigmi Pojava Weba i Jave u potpunosti donose OO paradigmu: Internetom putuju objekti

31 UML i elektronsko poslovanje radna grupa EU TMWG (Techniques( and Methodology Working Group) predložila je UML kao tehniku koja najviše e odgovara EP projekat t Instituta za primenjene računarske nauke i informacione sisteme iz Beča odabralo je 4 koncepta sa kojima se optimalno rešavaju problemi EP

32 Komunikacija u decentralizovanom i distribuiranom okruženju u objektno orijentisanom razvoju zasniva se na SOAP (Simple Object Access Protocol) protokolu objekti u razmeni opisuju se kao WSDL (Web Services Description Language) dokumenti XML DTD kontrolisana grupa XML dokumenata napisana pomoću u WSDL

33 Ciljevi UML Modelovanje sistema od koncepta do izvršnih celina korišćenjem OO tehnika Primenljivost na probleme glomaznosti u složenim sistemima sa kritičnim zadacima Stvaranje jezika za modelovanje upotrebljivog i za ljude i za računare Izrada metamodela sistema koji projektujemo ili programiramo

34 Načini korišćenja UML-a Izrada skica Izrada projekta Programiranje

35 Izrada skica Ubedljivo najčešća a primena Koristi se kao pomoćno sredstvo za opisivanje nekih aspekata sistema U razvoju i reverzibilnoj analizi Selektivan izbor u primeni Koristi se najčešće e za opise alternativa, neformalno i dinamički Korisne su u dokumentaciji, radi informisanja Ne pridržava se strogo pravila UML-a

36 Izrada projekta Kreiraju se potpuni opisi projekata i opisi odluka Projektant kreira uputstva programerima Analogija sa tehničkim crtežima inženjera koji se dostavljaju drugima Obuhvataju sve detalje ili samo odreñenu oblast, obično do interfejsa Često se primenjuje pomoću u CASE alata Koriste se u reverzibilnoj analizi: iz izvornog koda kreiraju dijagrame i tumačenja smeštaju u skladišta

37 Programiranje pomoću u UML-a CASE alati generišu u kostur programskog koda U nekim slučajevima generiše e se kompletan programski kod Zahteva veoma složene alate Modelovanje ponašanja: anja: dijagramima interakcije, stanja i aktivnosti Programeri crtaju UML dijagrame koji se neposredno prevode u izvršni kod (UML-om se opisuje izvorni kod)

38 Arhitektura zasnovana na modelu Model Driven Architecture (MDA) je standardna platforma za razvoj softvera u kompletnom životnom ciklusu dizajna, razvoja, i integracije aplikacija zasnovana na upotrbi modela u toku razvoja Standardni pristup korišćenja UML kao programskog jezika Standardom MDA upravlja OMG (kao i UML)

39 PIM i PSM Arhitektura MDA deli razvoj u PIM i PSM PIM (Platform Independent Model) je UML model koji ne zavisi od tehnologije PSM (Platform Specific Model) model l sistema namenjen odreñenom izvršnom okruženju i sadrži i specifične tehnološke informacije i kreira se za svaku izvršnu platformu Nakon toga svaki PSM se transformiše e u programski kod koji će e se izvoditi na toj platformi

40 CIM Iznad PIM formira se Computation Independent Model (CIM) Ovim modelom se opisuje sitem u svom poslovnom domenu i u njemu se opisuje kako de očekuje o da sistem treba da radi Ne sadrži i detalje konstrukcije

41 CIM ručna transformacija T PIM T PSM PSM T T kod kod

42 Od CIM ka PIM Poslovni procesi Slučajevi korišćenja

43 Izvršni UML Autor je Steve Mellor Sličan je MDA arhitekturi Počinje sa modelom ekvivalentnom PIM Prevodilac modela pretvara taj model u konačan an sistem (ne koristi PSM) Prevodilac modela zasnovan je na ponovo upotrebljivim arhetipovima Arhetip opisuje kako da izvršni UML model pretvorimo u kod za odreñenu platformu (koliko platformi toliko arhetipova)

44 Notacije i metamodeli UML definiše e notaciju i metamodel Notacija je skup grafičkih elemenata koji se koriste u modelima, tj. sintaksa jezika Grafički jezici modelovanja obično nisu strogi, a notacija je više e intuitivna Metamodel je dijagram koji precizno definiše koncepte jezika Od vitalnog je značaja aja za korisnike UML-a kao programskog jezika

45 Postupak razvoja softvera UML nastao iz više e OO metoda, čiji su se autori lako složili oko jezika modelovanja, ali nisu oko postupka razvoja softvera Dogovori o postupku razvoja odloženi za kasnije Najčešće e se spominje objedinjeni razvojni postupak kompanije Rational: USDP 2 ključne grupe postupaka: kaskadni i iterativni Razlikuju se u načinu podele projekta u manje delove

46 Kaskadni postupak Najčešći i naziv: model vodopada Smatra se klasičnim i zastarelim Deli projekat u delove na osnovu aktivnosti Obavezne aktivnosti u izradi programa: analiza zahteva, projektovanje, pisanje programa i testiranje Česti su povratni tokovi meñu aktivnostima

47 Iterativni postupak Nazivi: postupni, spiralni i evolutivni Moderniji, blizak OO pristupu Deli projekat na delove po funkcijama Istraživanje prethodi iterativnom postupku U svakoj iteraciji razvoj podjednakih grupa zahteva Svaka iteracija donosi gotov integrisan softver Vremenska ograničenja za pojedine funkcije Hibridni postupak: etapna isporuka

48 Problemi ponovnog rada Ponovno pisanje koda u narednim iteracijama Često je efikasnije ponovo napisati neko krpiti kod u kasnijim iteracijama Automatizovani regresivni testovi brzo otkrivaju ošteo tečenja enja nastala od izmena: xunit Prerañivanje (refactoring) je tehnika malih, disciplinovanih promena postojećeg eg koda Neprekidna integracija je sinhronizovan i automatizovan postupak integracije koda

49 Predvidljivo planiranje Glavna pitanja korisnika: koliko će e koštati i koliko će e trajati izrada softvera? Predvidljivi pristup: procene u ranim fazama Veća a predvidljivost postiže e se u toku razvoja Uz čvrst plan i dobro prikupljene zahteve očekuju se manja odstupanja Izmene zahteva u kasnim fazama remete osnove previdljivog planiranja Rano zamrzavanje zahteva može e dovesti do softvera koji ne odgovara korisniku

50 Prilagodljivo planiranje Zasniva se na principu neizbežnosti nosti izmena zahteva i da je često veoma teško precizno definisati zahteve Neprekidne promene su realnost i promena se smatra konstantom razvoja u cilju dobijanja najboljeg softvera Promene su kontrolisane, ali projekat nije predvidljiv Korisnici sarañuju sa timom u periodičnim procenama funkcionalnosti, rokova i cene

51 Unificirani proces razvoja softvera USDP: autori Jacobson, Booch i Rumbaugh Objavljen godine Proces klasificiranja iteracija u 4 grupe: početne iteracije interakcija sa stekholderima razrañene iteracije želja i potreba iteracije konstruisanja inicijalnih operacionih mogućnosti prelazne iteracije kompletiranja proizvoda

52 implementacija test inicijalni plan USDP zahtevi analiza i dizajn razvoj planiranje procena

54 Rezultati USDP Model korisničkih kih slučajeva: opisuje kako će aplikacija biti korištena Model analize: sadrži i osnovne klase rešenja enja Model dizajna: opisuje veze izmeñu klasa i odabranih objekata Model razvoja: alokacija softvera po računarima Implementacioni model: opisuje kako će e kod biti organizovan Testni model: sadrži i komponente, testne procedure i slučajeve

55 Stereotipna ponašanja anja Identične ne procedure u ponašanju anju 2 ili više objekata Elementi: uloge, odnosi, strukture i funkcije Integrisane celine: šabloni, stereotipi, obrasci, design patterns (DP) -> višestruka primena

56 Obrasci (Design Patterns) Kombinacija komponenti (obično klasa i objekata) za koje je utvrñeno da rešavaju odreñene zajedničke probleme dizajna Opisuju rezultate razvoja, tj. primere projekata Sadrže e rezultate rada najiskusnijih projektanata Erich Gamma sa trojicom kolega (Gang of Four) je opisao 23 DP Opisi sadrže e detalje zajedničkog rada objekta, prednosti, ograničenja, odstupanja i savete za realizaciju

57 Kategorije obrazaca Strukturni sadrže e sastav rukovanja objektom om kao pojedinačnim nim entitetom Kreativni opisuju kreiranje kompleksnih objekata Bihejvjuiralni ukazuju na ponašanje anje objekata Kombinovani na osnovu prethodnih kategorija

58 Izgled obrazaca Komponente sa opštim, karakterističnim za različite ite vrste softvera Mogućnost integracija u heterogene arhitekture softvera Adekvatna dokumentacija: namena, alternativni nazivi, kratak scenario, situacije primene, struktura, učesnici, u njihova saradnja, posledice, uputstvo za primenu, primeri

59 Osobine obrazaca Obrazac je više e od modela, jer sadrži objašnjenja i razloge zašto je baš takav U njemu se jasno opisuje problem i zašto se taj problem rešava Sadrži i opise u kojim situacijama radi, a u kojim ne Pokazuju šta je dobar model i kako ga napraviti: podučavaju na primeru

60 UML i postupak razvoja softvera Grafički jezici se obično koriste u kaskadnom razvoju Služe e za kreiranje dokumentacije koja se prenosi od faze do faze Upotreba UML ne podrazumeva obaveznu izradu dokumentacije ni upotrebu CASE alata UML dijagrami se često koriste za skice na sastancima U svakom postupku sprovode se analiza zahteva, projektovanje, programiranje i testiranje

61 Analiza zahteva Pokušava da otkrije šta korisnici očekuju o od sistema: Dijagrami slučajeva korišćenja opisuju kako korisnici komuniciraju sa sistemom Dijagram klasa je sredstvo za preciznu izradu rečnika iz neke oblasti Dijagram aktivnosti može e opisivati rokove poslova, njihov kontekst ili aktivnosti Dijagram stanja se moše e koristiti za opis životnog ciklusa nekog pojma

62 Projektovanje Dijagrami mogu, korišćenjem notacije, sadržati ati viže e tehničkih pojedinosti: Dijagrami klasa ih prikazuju unutar softvera i njihove meñusobne veze Dijagrami sekvence opisuju scenarije unutar programa, alternativa su CRC kartice Dijagrami paketa pokazuju opštu organizaciju softvera Dijagrami stanja služe e za opis klasa sa složenim životnim ciklusom Dijagrami razmeštanja prikazuju fizički raspored softverskih modula

63 CRC kartice Dijagrami klase-odgovornosti odgovornosti-saradnje: saradnje: Class- Responsibility-Collaboration Osmislio Ward Cunningham krajem 80-ih Služe e za ispitivanje interakcija izmeñu objekata Veoma popularna tehnika, nije deo UML-a Kartice sadrže e ime klase u zaglavlju i 2 kolone: Odgovornost je kratak opis šta objekat treba da uradi aktivnosti, znanje, odluke U koloni za saradnju upisuju se druge klase sa kojima treba da se realizuje odgovornost

64 Primer CRC kartice Porudžbina Primi upit Proveri zalihe Odredi cenu Proveri da li je plaćeno Isporuči i robu Stavka upita Skladište Kupac Uplata Vozilo

65 Način rada U kaskadnom postupku: dijagrami se kreiraju i obavljaju aktivnosti po fazama UML se koristi za pravljenje projekta U iterativnom postupku: dijagrami se koriste za pravljenje skica i projekta Skice su grubi projekat, kreiraju se u toku njegovog osmišljavanja, u svakoj fazi UML projekat se pravi na početku iteracije, na osnovu čega se programira Ne kreće e se od početka, već se menjaju postojeći i dokumenti, sa naglaskom na iteraciji

66 Dokumentacija Formira se izborom iz radnih beleški, uglavnom skica, a detaljna se kreira nakon pisanja programskog koda Dijagram paketa je logička karta puteva kroz sistem Dijagram rasporeñivanja prikazuje fizčku sliku sistema na visokom nivou Dijagram klasa treba da bude podržan dijagramima interakcije Dijagram mašine stanja koristi se za složene životne cikluse Dijagram aktivnosti za najsloženije algoritme

67 Razumevanje preuzetog koda Opisi delova koda koje je pisao neko drugi Formiraju se njihove skice Obično se kreiraju dijagrami klasa i dijagrami sekvenci

68 Da nazdravimo za kraj idealnog prvog sastanka.

Biznis scenario: sekcije pk * id_sekcije * naziv. projekti pk * id_projekta * naziv ꓳ profesor fk * id_sekcije

Biznis scenario: sekcije pk * id_sekcije * naziv. projekti pk * id_projekta * naziv ꓳ profesor fk * id_sekcije Biznis scenario: U školi postoje četiri sekcije sportska, dramska, likovna i novinarska. Svaka sekcija ima nekoliko aktuelnih projekata. Likovna ima četiri projekta. Za projekte Pikaso, Rubens i Rembrant