Lekcija 2 - Agilni i Objektno Orijentisani Razvoj Sistema

IS280 - Analiza i projektovanje sistema

Lekcija 02

AGILNI I OBJEKTNO ORIJENTISANIRAZVOJ SISTEMA

Svetlana Cvetanović

PRIRUČNIK ZA STUDENTE

1

www.princexml.com

Prince - Non-commercial License

This document was created with Prince, a great way of getting web content onto paper.

Copyright © 2010 – UNIVERZITET METROPOLITAN, Beograd. Sva pravazadržana. Bez prethodne pismene dozvole od strane UniverzitetaMETROPOLITAN zabranjena je reprodukcija, transfer, distribucija ili memorisanjenekog dela ili čitavih sadržaja ovog dokumenta., kopiranjem, snimanjem,elektronskim putem, skeniranjem ili na bilo koji drugi način.

Copyright © 2010 BELGRADE METROPOLITAN UNIVERSITY. All rights reserved.No part of this publication may be reproduced, stored in a retrieval system ortransmitted in any form or by any means, electronic, mechanical, photocopying,recording, scanning or otherwise, without the prior written permission of BelgradeMetropolitan University.

IS280 - Analiza i projektovanje sistema

Lekcija 02

AGILNI I OBJEKTNO ORIJENTISANIRAZVOJ SISTEMA

Svetlana Cvetanović

Poglavlje 1 Agilni i objektno orijentisanirazvoj sistema

UVOD

Dok se u prethodnom predavanju govorilo o strukturnim metodama i metodamabaziranim na RAD-u, u ovom predavanju je stavljen naglasak na agilne i objektnoorijentisane metode razvoja. U agilnim metodama je u prvom planu programiranje,one podržavaju SDLC ali bez i suviše velike potrebe za modeliranjem i pravljenjemdokumentacije. Pogodne su za male sisteme.

Koncept objektno orijetisanog pristupa omogućava analitičaru da složeni sistemrazbije na manje, lako upravljive module, radi sa pojedinačnim modulima, i damodule lako spoji kako bi oformio informacioni sistem. Ova modularnostomogućava da se sistem lako shvati, lakše podeli među članove projektnog tima,lakše komunicira sa korisnicima.

Jedna od najpoznatijih metodologija koja podržava OO pristup je Unified Process.Rezultati primene objekno orijentisanog pristupa se iskazuju korišćenjem grafičkogjezika za modeliranje poznatom kao UML, o kojem će u ovom predavanju takođebiti reči.

Lekcija 01: Uvod u racunarske sisteme i programske jezike

4

Poglavlje 2 Agilni razvoj

KARAKTERISTIKE I PRIMERI

U projektima agilnog razvoja naglasak se stavlja na iterativnirazvoj aplikacija.

Metodlogija za razvoj sistema koja je još uvek u fazi nastajanja je agilni razvoj.Ova metodologija u čijem je fokusu programiranje imaja nekoliko pravila koje jemoguće veoma lako pratiti. Ona podržavaju SDLC ali bez i suviše velike potrebeza modeliranjem i pravljenjem dokumentacije na šta se troši mnogo vremena. Uprojektu se stavlja naglasak na iterativni razvoj aplikacije.

Primeri metodologija agilnog razvoja uključuju:• Extreme programming,• Scrum i• Dynamic Sistems Development Method (DSDM).

Pristup agilnog razvoja se obično koristi zajedno sa objektno orijentisanimmetodologijama.

2.1 EXTREME PROGRAMMING (XP)

KARAKTERISTIKE

Posle površnog procesa planiranja, iterativno se izvršavajufaze analize, dizajna i implementacije.

Extreme Programming (XP) se bazira na četiri osnovne vrednosti:• komunikacija,• jednostavnost,• povratna sprega i• hrabrost.

Ove četiri vrednosti pretstavljaju osnovu koju XP programeri koriste kako bi kreiralisistem.

• Prvo, XP programeri moraju da kontinuirano obezbeđuju brzi feedbackkrajnjim korisnicima.

• Drugo, XP zahteva od programera da prate principe KISS-a.

Poglavlje 2: Agilni razvoj

5

• Treće, programeri moraju tokom razvoja sistema da prave inkrementalnepromene koje moraju da detaljnije analiziraju.

• Četvrto, programeri moraju da imaju dobre i ikvalitetne mentalnekarakteristike.

• Karakteristika metodologije Extreme programiranja jeste da se poslepovršnog procesa planiranja, iterativno izvršavaju faze analize, dizajna iimplementacije. (vidi sliku 2.1.1)

• Jedna iteracija u agilnoj metodi se naziva sprint . U okviru svakog sprinta,tim radi na celom ciklusu razvoja softvera što uključuje planiranje, analizuzahteva, dizajn, kodiranje i testiranje nakon čega se softverski proizvoddemonstrira korisniku

Slika 2.1.1. Metodologija agilnograzvoja

PRINCIPI

Principi XP programiranja su neprestano testiranje,jednostavno kodiranje i veoma uska interakcija sa krajnjimkorisnicima.

Jezgro XP programiranja je testiranje i efikasno kodiranje. U suštini, kod se testirasvakog dana i priprema za integrativno testiranje. Ukoliko postoje greške, kod sevraća nazad sve dok se potpuno ne oslobodi od grešaka. XP se u velikoj merioslanja na refaktorisanje, koje pretstavlja način za restruktuiranje koda kako bi onbio što jednostavniji.XP projekat počinje sa pričom krajnjeg korisnika koji opisuje šta sistem treba daradi.

Zatim, programeri pišu male, jednostavne module i testiraju ih sve dok ne zadovoljepotrebe korisnika. Od korisnika se očekuje da sve vreme budu raspoloživi, kako bipojašnjavali pitanja i problem koji se pojavljuju.


6

Da bi se eliminisala bilo kakva konfuzija, XP tim koristi zajednički definisaneskupove imena, opisa i preporuka za kodiranje. XP metodologije brže daju rezultateod bilo kok drugog RAD pristupa i vrlo se rerko dešava da programeri dugo rade naskupljanju zahteva sistema.

KADA GA PRIMENITI ?

Korišćenje XP-a kao metodologije za razvoj velikihinformacionih sistema se stavlja pod sumnju.

Za male projekte na kojima radi visoko motivisan, stabilan i iskusan tim, XP možeda da veoma dobre rezultate. Međutim ako projekat nije mali, a tim koji radi nanjemu nije jedinstven, tada se uspeh XP razvoja može staviti pod sumnju.XP zahteva veliku disciplinu, u suprotnom program će postati nefokusiran ihaotičan. Šta više, XP se preporučuje samo za male grupe programera – ne višeod deset, i ne preporučuje se za velike aplikacije.

Zbog nepostojanja dokumentacije koja se proizvodi u analizi i dizajnu, U XPmetodologiji se dokumentacija generiše samo prilikom kodiranja, tako daodržavanje velikih sistema građenih primenom XP-a može biti nemoguće. Pošto seposlovni informacioni sistemi prave tako da služe duži period vremena, korišćenjeXP-a kao metodologije razvoja se stavlja pod sumnju.

2.2 SCRUM

SCRUM

Ova metoda je više vezana za agilno upravljanje softverskimprojektom, nego za agilno projektovanje softvera

SCRUM predstavlja agilni pristup za upravljanje razvojem softvera opšte prihvaćenu svetu. On se javlja polovinom 90-tih godina prošlog veka. Čest utisak da je topogrešan akronim. Scrum je pojam preuzet iz ragbija i označava momenat kada seprotivnički timovi skupljaju na gomilu i bore za posed lopte. To nije vezano, osimsimbolički, za softverski projekat.

Ova metoda je više vezana za agilno upravljanje softverskim projektom, negoza agilno projektovanja softvera. Ona propisuje načine upravljanja zahtevima,formiranja iteracija (planiranje sprinta), kontrole implementacije i isporukesoftverskog proizvoda klijentu. Često se upotrebljava kao način vođenja XP, ilidrugih projekta koji ne moraju obavezno da se projektuju nekom agilnom metodom.

Osnovna jedinica razvoja u SCRUM jeste sprint. Pre svakog sprinta, vrši seplaniranje u okviru kojeg se identifikuju zadaci koje treba izvršiti u okviru sprint-a i

Poglavlje 2: Agilni razvoj

7

određuje se cilj izvršenja sprint-a. Nakon sprint-a, drži se sastanak u okviru kojegse proverava da li ima napretka i identifikuju se zadaci za sledeći sprint. Za vremesvakog sprint-a, tim kreira završeni deo proizvoda.

Može se reći da ukoliko se u okviru jednog SCRUM sprint-a izvršavaju sve fazerazvoja softvera (od analize zahteva do testiranja), tada SCRUM sprint odgovarajednoj agilnoj iteraciji.

2.3 RAZLIKE IZMEĐU XP I SCRUM

ČETIRI OSNOVNE RAZLIKE

Razlike su često veoma suptilne, ali veoma važne

1. Scrum tim obično radi u iteracijama (koje se nazivaju sprint-ovi) i traju oddve nedelje do mesec dana. XP tim radi u iteracijama koje traju od jednedo dve nedelje.

2. Scrum timovi ne dozvoljavaju nikakve promene u okviru svojih sprint-ova.XP timovi mogu da izvrše promene u okviru svojih iteracija. Sve dok ekipane počne da radi na određenoj funkciji, ona može biti zamenjena novomfunkcijom ekvivalentne veličine.

3. XP tim radi po tačno utvrđenom redosledu prioriteta. Prioritete funkcijakoje se razvijaju određuje korisnik, i od tima se traži da poštuje redosledtih prioriteta. Nasuprot tome, u Scrum-u je tim taj koji određuje sekvencuu kojoj će se razvijati proizvod. Scrum tim će najpre raditi nanajprioritetnijem zadatku, zatim zadatku drugog prioriteta itd.

4. U Scrum-u se ne primenjuje nikakva inženjerska praksa; u XP-u da. UXP su zastupljene stvari poput test-driven razvoja, automatsko testiranje,programiranje u paraovima, jednostavan dizajn, refaktorisanje itd.


8

Poglavlje 3 Kriterijumi za izbormetodologije

KAKO IZABRATI NAJBOLJUMETODOLOGIJU?

Nije lako izabrati metodologiju, jer ni jedna metodologija nijenajbolja.

Pošto postoji mnogo metodologija, prvi izazvov sa kojim se sreće analitičar jeizbor metodologije koja će se koristiti. Nije lako izabrati metodologiju, jer ni jednametodologija nije najbolja. Mnoge organizacije imaju standard i politiku kojih sepridržavaju prilikom izbora metodologije. Postoje organizaćije koje imaju“odobrenu” metodologiju kao i one koje koriste nekoliko metodologija ili uopšte nekoriste metodologije.

Na sledecoj slici 3.1 je prikazano nekoliko važnih kriterijuma za izbor metodologije.Jedna od važnih stavki koja nije uzeta u obzir na ovoj slici je iskustvo timaanalitičara. Mnoge RAD bazirane metodologije zahtevaju korišćenje novih alata itehnika koje treba naučiti. Često ti alati i tehnike povećavaju složenost projekta izahtevaju dodatno vreme za učenje. Međutim, kada se tim jednom adaptira timalatima i stekne iskustvo u njihovom korišćenju, alati i tehnike mogu značajnoubrzati isporuku gotovog sistema.

Slika 3.1: Kreiterijumi za izbormetodologije

Poglavlje 3: Kriterijumi za izbor metodologije

9

Poglavlje 4 Objektno orijentisana analiza idizajn

KARAKTERISTIKE

Objektno orijentisane metodologije prave balans izmeđupodataka i procesa fokusirajući se prilikom dekompozicijeproblema na objekte koji sadrže i podatke i procese.

Objektno orijentisan pristup za razvoj informacionih sistema, tehnički govoreći,može da koristi bilo koju od tradicionalnih metoda (metodu vodopada, paralelnirazvoj, fazni rauvoj, prototajping). Međutim, objektno orijetisani pristup se najčešćespaja sa RAD metodologijom. Osnovna razlika između tradicionalnog pristupa kaošto je strukturni dizajn i objektno orijentisanog pristupa je u tome kako izvršitidekompoziciju problema . U tradicionalnom pristupu, proces dekompozicijeproblema je ili orijentisan na procesima ili podacima. Međutim, procesi i podacisu u toliko uskoj vezi da je veoma teško staviti fokus na jedno ili drugo . Noveobjektno orijentisane metodologije se baziraju na RAD sekvenci faza SDLC-a alipokušavaju da naprave balans između podataka i procesa fokusirajući se prilikomdekompozicije problema na objekte koji sadrže i podatke i procese. Oba pristupaimaju se mogu smatrati dobrim za razvoj informacionih sistema.

U skladu sa mišljem tvoraca Unified Modeling Language (UML), Grady Booch-em,Ivar Jacobson-om i James Rumbaugh-om, moderan objektno orijentisani pristup zarazvoj informacionih sistema mora da bude:

1. upravljan slučajevima korišćenja2. baziran na arhitekturi3. inkrementalan i iterativan.

UPRAVLJAN SLUČAJEVIMA KORIŠĆENJA

Slučajevi korišćenja (Use case) su primarni alat za modeliranjekojima se definiše ponašanje sistema

Upravljan slučajevima korišćenja znači da su slučajevi korišćenja (Use case)primarni alat za modeliranje kojima se definiše ponašanje sistema. Slučajkorišćenja opisuju u kakvoj su interakciji korisnik i sistem prilikom izvršenja nekihaktivnosti. Slučajevi korišćenja se koriste za identifikovanje zahteva sistema na


10

osnovu kojih programeri treba da naprave sistem. Definisanje slučajeva korišćenjase može smatrati jednostavnim, jer se fokus stavlja samo na aktivnosti.

Nasuprot tome, dijagrami za modeliranje procesa koji se koriste u tradicionalnimstrukturnim RAD metodologijama su mnogo složeniji jer zahtevaju da sistemanalitičar i korisnik razviju model celog sistema. Sa tradicionalnim metodologijama,svaka poslovna aktivnost se dekomponuje na podaktivnosti koje se daljedekomponuju na podaktivnosti itd. Nasuprot tome, slučajevi korišćenja sefokusiraju samo na jednu aktivnost u jednom trenutku vremena, pa je model koji serazvija mnogo jednostavniji.

BAZIRANOST NA ARHITEKTURI

Specifikacije, konstrukcija i dokumentacija sistema se definišuna osnovnu softerske arhitekture

Bilo koji moderan pristup za razvoja informacionih sistema treba da bude baziranna arhitekturi.

Bazirati se arhitekturi znači da se na osnovnu softerske arhitektura sistema definišuspecifikacija, konstrukcija i dokumentacija sistema. Moderan objektno orijentisanpristup u analizi i dizajnu treba da podrži najmanje tri odvojena ali povezanaarhitekturalna pogleda na sistem:

• Funkcionalni ili eksterni pogled - opisuje ponašanje sistema iz perspectivekorisnika

• Strukturni ili statički pogled - opisuje sistem u smislu atributa, metoda, klasa irelacija

• Dinamički ili pogled kojim se opisuje ponašanje sistema - opisuje ponašanjesistema u smislu poruka koje se razmenjuju između objekata i menjaju njihovostanje. .

INTERATIVNOST I INKREMENTALNOST

Na razvoju tri arhitekturalna pogleda sistema, sistem analitičar ikorisnik rade iterativno i inkrementalno

Pristup moderne analize i dizajna stavlja naglasak na iterativan i inkremetalanrazvoj koji podrazumeva kontinuirano podvrgavanje testiranju i poboljšanju sistematokom života projekta. To znači da sistem analitičar razume problem korisnikaizgradnjom tri arhitekturalna pogleda korak po korak . Sistem analitičar najpreradi sa korisnikom na kreiranju funkcionalne prezentacije sistema. Zatim, analitičarpokušava da napravi strukturnu prezentaciju sistema.

Poglavlje 4: Objektno orijentisana analiza i dizajn

11

Korišćenjem strukturne prezentacije, analitičar distribuira funkcionalnost sistemana čitavu strukturu kako bi kreirao model ponašanja sistema. Analitičar na razvojutri arhitekturalna pogleda sistema koje razvija zajedno sa korisnikom, radiiterativno. To znači da kada analitičar bolje shvati strukturni pogled ili pogledponašanja on može otkriti da su ispušteni ili pogrešno shvaćeni zahtevi ufunkcionalnom pogledu. Sva tri arhitekturalna pogleda sistema su u međusobnojvezi i zavise jedan od drugog (vidi sliku 4.1).

Slika 4.1: Inkrementalni iiterativni razvoj

KORISTI OBJEKTNO ORIJENTISANEANALIZE I DIZAJNA

Koncept objektno orijetisanog pristupa omogućava da sekreiraju rejuzibilni delovi koji se mogu ugrađivati u drugesisteme

Koncept objektno orijetisanog pristupa omogućava analitičaru da složeni sistemrazbije na manje, lako upravljive module, radi sa pojedinačnim modulima, i damodule lako spoji kako bi oformio informacioni sistem. Ova modularnostomogućava da se sistem lako shvati, lakše podeli među članove projektnog tima,lakše komunicira sa korisnicima, koji treba da postave svoje zahteve i potvrde daje sistem kroz SDLC te zahteve ispunio.Modularizovanim razvojem sistema, projektni tim kreira rejuzibilne delove koji semogu ugrađivati u druge sisteme ili koristiti kao početna tačka drugog projekta. Nakraju, to može da uštedi vreme, jer drugi projekat ne počinje od samog početka.Mnogi ljudi tvrde da je objektni način razmišljanja mnogo realističniji način dase razmišlja o svetu. Korisnici obično ne razmišljaju o procesima ili podacima


12

već svoj posao vide kroz kolekciju logičkih jedinica koje sadrže i jedno i drugo– komunikacijom u smislu objekata se unapređuje interakcija između korisnika ianalitičara ili programera

Poglavlje 4: Objektno orijentisana analiza i dizajn

13

Poglavlje 5 UML

DIJAGRAMI UML-A

UML (Unified Modeling Languange) je grafički jezik koji služi zaiskazivanje rezultata primene objetno orijetisanog pristupa

Za predstavljanje rezultata primene objektno orijentisanog pristupa naprojektovanje neke aplikacije se koristi UML (Unified Modeling Languange). UMLje vizualni, grafički jezik koji predstavlja skup konvencija za opisivanje modelaaplikacije dobijenog primenom neke objektno orijentisane metode. U UML-u semogu izdvojiti četiri grupa dijagrama koji omogućavaju prikaz različitih pogleda nadobijeni model aplikacije:

• Dijagrami za prikazivanje Use case modela• Dijagrami za opisivanje statičkog modela sistema• Dijagrami za opisivanje dinamičkog modela sistema• Dijagrami za opis fizičkog modela odnosno implementacije sistema

KOJE DIJAGRAME TREBA KORISTITI?

Pri razvoju velikih aplikacija se može generisati na stotinerazličitih UML dijagrama dok je male sisteme moguće opisatisamo sa nekoliko dijagrama

Između različitih vrsta UML dijagrama se mogu uspostaviti veze.

Najčešće, projektovanje sistema započinje od specifikacije zahteva poslovnogsistema (Business Process Requirements – BPR) koji se izražavaju preko Usecase-ova.

Nakon kreiranja Use case-ova kojima se specificira šta gotov sistem treba da radi,sugerišu su UML dijagrami koje treba koristiti u fazi analize, dizajna i razvoja ap-likacije. Mnogi projektanti kreiraju najmanje jedan Use case dijagram i nekolikosekvencijalnih i klasnih dijagrama koji predstavljaju suštinu faze analize i dizajnadok se drugi dijagrami ređe koriste.

Svaka vrsta dijagrama UML-a ima specifičnu namenu i koristi se zavisno od tipaaplikacije koja se razvija. Međutim, UML-om se ne utvrđuje obaveza da se morajuprimeniti svi ili samo neki od navedenih dijagrama kao ni redosled u kojem se


14

specifični dijagrami rade. Tako se pri razvoju velikih aplikacija može generisatina stotine različitih UML dijagrama dok je male sisteme moguće opisati samo sanekoliko klasnih i sekvencijalnih dijagrama.

5.1 DIJAGRAMI ZA PRIKAZIVANJE USECASE MODELA

VRSTE DIJAGRAMA

Za opisivanje Use case modela se koriste Use case dijagrami iUse Case opisi

Use case dijagrami predstavljaju tehniku za modeliranje funkcionalnosti ispecifikaciju zahteva sistema. Njima se opisuje ponašanje sistema odnosnonjegove funkcije s tačke gledišta interesenata i korisnika. Svaki Use case se možepredstaviti kao skup sekvenci akcija koje se izvršavaju u okviru sistema a rezultatnjihovog izvršenja su vrednosti značajne za korisnika. Sekvenca akcija se uvekinicira porukom prosleđenom od korisnika (vidi sliku 5.1.1)

Slika 5.1.1. Primer Use casedijagrama

Use Case opisi predstavljaju formalizovan način za opisivanje sekvence akcija(interakcije) između korisnika i samog sistema i to korišćenjem prirodnog jezikakorisnika. Oni sadrže tekstualni opise specifičnog scenarija u kojem interesenti ikorisnici snabdevaju sistem ulazima a sistem na njih odgovara vidljivim izlazima.Use case opis može da sadrži više od jednog scenarija, pri čemu je jedan odnjih glavni, dok su ostali alternativni. Detaljan opis Use Case-ova može biti dat idijagramom aktivnosti ili dijagramom sekvenci.(vidi sliku 5.1.1)

Slika 5.1.2. Primer Use caseopisa

Poglavlje 5: UML

15

Kolekcija svih Use Case-ova, Acor-a, Stakeholder-a, Use Case dijagrama i Usecase opisa čini Use Case model. Osnovni cilj Use case modela jeste opisfunkcionalnih zahteva odnosno osnovnih funkcija sistema s tačke gledištakorisnika, koji predstavlja osnovu za dalju analizu i dizajn sistema.

5.2 DIJAGRAMI ZA OPISIVANJESTATIČKOG MODELA

VRSTE DIJAGRAMA

Za opisivanje statičkog modela se koriste Dijagrami klasa iDijagrami objekata

Dijagrami klasa prikazuju statički aspekt projektovanog sistema. Na dijagramimaklasa se prikazuju klase, njihove strukture i međusobne veze, koje mogu bititipa asocijacije, nasleđivanja, agregacije i zavisnosti. Osim klasa, mogu bitipredstavljeni i drugi elementi modela kao što su interfejsi i paketi - moduli koji sedobijaju dekompozicijom sistema u cilju savladavanja njegove složenosti. Dijagramiklasa se mogu raditi u nekoliko nivoa. (vidi sliku 5.2.1)

Slika 5.2.1. Primer klasnogdijagrama

Dijagrami objekata služe za prikazivanje objekata posmatranih klasa i njihovihmeđusobnih veza. Mogu se pojaviti u dva oblika, kao statički i dinamički. Statičkidijagram objekata predstavlja jednu pojavu dijagrama klasa i saglasan je s njim.Dinamički dijagram objekata pored objekata i njihovih veza kojima se opisuje stanjesistema, prikazuju i promene koje se dešavaju u nekom intervalu vremena kao iporuke koje objekti međusobno razmenjuju. (vidi sliku 5.2.2)


16

Slika 5.2.2. Primer objektnogdijagrama

5.3 DIJAGRAMI ZA OPISIVANJEDINAMIČKOG MODELA

VRSTE DIJAGRAMA

Za opisivanje dinamičkog modela se koriste Dijagramisekvenci, Kolaboracioni dijagrami, Dijagrami stanja i Dijagramiaktivnosti

Dijagrami sekvenci opisuju način na koji objekti u sistemu međusobnokomuniciraju, ostvarujući na taj način očekivano ponašanje. Na njima se prikazujesekvenca poruke koje se prosleđuju između objekata u cilju izvršenja određeneoperacije. Kako se njima prikazuju interakcije među objektima, pre njihove izradeneophodno je za datu aplikaciju identifikovati osnovni skup klasa odnosno njihovihobjekata. (vidi sliku 5.3.1)

Kolaboracioni dijagrami prikazuju komunikaciju između objekata kao i njihove vezeneophodne za ostvarivanje te komunikacije , ali bez naglaska na vremenskukomponentu.

Poglavlje 5: UML

17

Slika 5.3.1. Primersekvencijalnog dijagrama

Dijagrami stanja opisuju stanja objekta posmatrane klase u kojima se oni mogunaći, njihovo ponašanje u tim stanjima kao događaje koji uslovljavaju prelazak izjednog u drugo stanje.

Dijagrami aktivnosti su specijalni tip dijagrama stanja i služe za prikazivanje tokaaktivnosti (workflow) koje se izvršavaju u okviru jedne operacije. Ovi dijagrami, kojine koriste direktno objekte i klase sadržane u modelu koji se radi tokom analize,imaju za cilj da iskazu dinamičko ponašanje sistema na višem nivou od onogprikazanog sekvencijalnim i koloboracionim dijagramima. (vidi sliku 5.3.2)

Slika 5.3.2. Primer dijagramaaktivnosti


18

5.4 DIJAGRAMI ZA OPIS FIZIČKOGMODELA

VRSTE DIJAGRAMA

Za opisivanje fizičkog modela služe Dijagrami paketa,Dijagrami komponenti, Dijagrami razmeštanja

• Dijagrami paketa se koriste da se pokaže logička podela klasa na module,predstavljene paketima kao i veze koje postoje među paketima.

• Dijagrami komponenti prikazuju fizički razmeštaj klasa pri realizaciji, za razlikuod dijagrama paketa gde je prikazana njihova logička podela. Uobičajeno jeda su dijagrami paketa i dijagrami komponenti u relaciji 1:1.

• Dijagrami razmeštanja služe za opisivanje fizičke arhitekture aplikacije takoda čvorovi u dijagramima obično predstavljaju hardversku platformu

Poglavlje 5: UML

19

Poglavlje 6 Unifed Process (UP)

ŠTA JE UP?

UP: metodološki pristup koji služi da se projektnom timu u vidupreporuka daju smernice kada i koje UML dijagrame treba dakoriste

Korišćenjem ovakvog disciplinovanog pristupa u dodeljivanju zadataka iodgovornosti članovima tima se može dobiti softver visokog kvaliteta, koji u okvirupredviđenog budžeta i plana zadovoljava potrebe interesenata i korisnika.

Aktivnosti UP-a nisu fokusirane na proizvodnju velike količine papirnatedokumentacije, već na razvoj i održavanje modela, semantički bogate prezentacijesoftverskog sistema koji se razvija. Kreiranje i održavanje različitih modela jepodržano CASE alatima kojima se automatizuje veliki deo procesa.

UP-om je podržan iterativni postupak projektovanja koji je prikazan na slici 6.1.

On omogućava da se rizik čitavog projekta značajno umanji čestimizbacivanjem izvršnih verzija softvera koje testiraju krajnji korisnici, tako dase rezultati testiranja kao povratne veze uključuju u sledeću verziju softvera.

Pošto se svaka iteracija završava izvršnom verzijom, razvojni tim je stalnousredsređen na dobijanje rezultata i česte provere statusa, što pomaže dase projekat odvija po utvrđenom planu. Iterativni pristup takođe omogućava lakšeprilagođavanje taktičkim izmenama zahteva ili plana.


20

Slika 6.1: Iterativni postupakprojektovanja podržan UP-om

DIMENZIJE I FAZE

UP se može opisati kroz dve dimenzije: dinamički aspektprocesa izražen preko faza i statički aspekt procesa izraženpreko aktivnosti

UP se može opisati kroz dve dimenzije koje se prikazuju kroz dve osekoordinatnog sistema:

• horizontalnu osu koja predstavlja vreme i prikazuje dinamički aspektprocesa izražen preko faza, iteracija i kontrolnih tačaka (milestone)

• vertikalnu osu koja predstavlja statički aspekt procesa izražen prekoaktivnosti, dokumentacije, učesnika (worker-a) i disciplina (workflow-a)

što je prikazano na slici 6.2.

UP-om se jedan razvojni ciklus deli na četiri faze: početak (Inception), razrada(Elaboration), konstrukcija (Construction) i prelaz (Transition).

Svaka faza se završava kontrolnom tačkom (milestone) u kojima se daje kritičkiosvrt na rezultate završene faze u smislu postizanja njenog ključnog cilja.

Svaka faza se može odvijati kroz jednu ili više iteracija a svaka iteracija se izvršavakroz šest osnovnih disciplina (workflow-a): poslovno modeliranje, specifikacijazahteva, analiza, dizajn, implementacija i testiranje koje su prikazane na vertikalnojosi.

Poglavlje 6: Unifed Process (UP)

21

Mada svaka iteracija može da sadrži svih pet disciplina, zavisno od toga gde sedata iteracija pojavljuje u životnom ciklusu projekta, naglasak se stavlja samo najednu od njih, što je prikazano na slici 6.2.

.Slika 6.2: Faze i discipline UP-a

6.1 FAZE

FAZA: POČETAK (INCEPTION)

Identifikuju se eksterni entiteti (actor-i i stakeholder-i) i svi Usecase-ovi

UP-om se jedan razvojni ciklus deli na četiri faze (vidi sliku):• početak (Inception),• razrada (Elaboration),• konstrukcija (Construction) i• prelaz (Transition).


22

Slika 6.1.1. Faze UP-a

Početak (Inception): ima za cilj utvrđivanje poslovnih (business) Use case-ova sistema i definisanje njegovog domena. Ostvarivanje ovako postavljenogcilja je moguće identifikovanjem svih eksternih entiteta s kojima je sistem uinterakciji pretstavljenih preko actor-a i stakeholder-a, svih Use case-ova kao i opisnekih najznačajnijih. U kontrolnoj tački (milestone) koja sledi po završetku ove fazese proverava da li su isporukom odgovarajućih dokumenata i modela ispunjeniuslovi dati u sledećoj tabeli 6.1.1.

Slika 6.1.Tabela 1: Uslovi kojimoraju biti zadovoljeni nakon

faze “Početak”

FAZA: RAZRADA (ELABORATION)

Utvrđuje se područje koje sistem pokriva, specificira njegovaosnovna funkcionalnosti i definišu nefunkcionalni zahtevi.

Razrada (Elaboration): radi se s ciljem da se analizira domen problema, razvijestabilan projektni plan, definišu zahteva iz kojih su eliminisani svi rizici kakobi se mogli predvideti troškovi i plan završetka čitavog projekta i utvrditifizička arhitektura sistema koja će se koristiti za njegovu implementaciju. Da bi seispunili ovi zahtevi, potrebno je imati potpunu sliku sistema: područje koje pokriva,


23

specifikaciju njegove osnovne funkcionalnosti i definisane nefunkcionalne zahteve.Glavni kriterijumi za završetak faze su odgovori na pitanja: da li je vizija softverskogproizvoda i njegova arhitektura dovoljno stabilna i da li su razrešeni najrazličnijielementi.Uslovi koji moraju biti ispunjeni po završetku ove faze su dati u tabeli 6.1.2.


faze “Razrada”

FAZA: KONSTRUKCIJA (CONSTRUCTION)

Izlaz iz faze konstrukcije je softverski sistem, završen ispreman za beta testiranje na site-u korisnika

Konstrukcija (Construction): ima za cilj izradu softverskog proizvoda koji jespreman za transfer do korisnika. U njoj se naglasak stavlja na upravljanjeresursima i kontrolisanje operacija kako bi se optimizovali troškovi, plan i kvalitetprojekta. U tom smislu ona predstavlja prelaz sa razvoja intelektualnih svojstavaidentifikovanih u fazi početka i razrade na razvoj proizvoda koji se može stavitiu ruke krajnjeg korisnika. Kako faza konstrukcije predstavlja razvoj izvršnearhitekture generisane u fazi razvoja u kompletan finalni sistem, u ovoj fazi senaglasak stavlja na discipline analize, dizajna i implementacije.

U fazi konstrukcije se završava model analize i model dizajna i započinjeimplementacija i testiranje. Kontrolna tačka nakon faze konstrukcije je veomajednostavna – softverski sistem je završen i spreman za beta testiranje na site-ukorisnika. Uslovi koje treba zadovoljiti su dati u tabeli.Uslovi koje treba zadovoljiti su dati u tabeli 6.1.3.


faze Konstrukcija"


24

FAZA: PRELAZ (TRANSMISIJA)

Vrši se beta testiranje, paralelni rad sa sistemom koji se menja,konverzija operativne baze podataka, obuku korisnika iodržavanje.

Prelaz (Transition): je fokusiran na aktivnosti neophodne da se softverskiproizvod preda korisnicima. Ova faza uključuje: beta testiranje kao bi se novsistem validirao prema očekivanjima korisnika, paralelni rad sa postojećimsistemom koji se menja, konverziju operativne baze podataka, obukukorisnika i održavanje. Na kraju ove faze treba dati odgovore na pitanja: da li sukorisnici zadovoljni i da li je stvarni utrošak resursa prema planiranoj potrošnji jošuvek prihvatljiv. Uslove koje treba zadovoljiti dati su tabeli 6.1.4..Uslove koje treba zadovoljiti dati su tabeli.

Slika 6.1.Tabela 4. Uslovi kojimoraju biti zadovoljeni nakon

faze “Prelaz”

6.2 DISCIPLINE

DISCIPLINA: POSLOVNO MODELIRANJE

Kao izlaz iz poslovnog modeliranja se dobijaju Poslovni Usecase model i Model poslovnih objekata

Discipline UP-a kojima se opisuje statička struktura procesa su prikazane na slici6.2.1.


25

Slika 6.2.Silka 1: Discipline UP-akojima se opisuje statička

struktura procesa

Modeliranje poslovnog sistema obuhvata aktivnosti: identifikacija poslovnihprocesa, prečišćavanje definicija poslovnih procesa i dizaniranje realizacijeposlovnih procesa pa se kao izlazi iz ove discipline dobijaju:

Poslovni Use case model (Business Use case model) opisuje poslovne procesiei njihovu interakciju sa eksternim učesnicima kao što su kupci i poslovni partneri.Ulaz u discplinu su definisani zahtevi (Requirements) za izradu Use case modela.

Model poslovnih objekata (Business Object Model) opisuje realizacijuidentifikovanih poslovnih Use case-ova a koristi se u analizi i dizajnu kao ulazza identifikaciju klasa Design modela. Modeliranje poslovnog sistema je opcionadisciplina.

DISCIPLINA: ZAHTEVI (REQUIREMENTS)

Pronale se ator-i sistema, definišu Use case-ovi, vrši detaljnaanaliza Use case-ova i struktuiranje Use case modela

Cilj discipline zahtevi je da se opiše šta softver treba da radi, da se definišugranice softverskog rešenja, da se onima koji razvijaju softver omogući date opise usklade sa korisnicima, da se obezbedi osnova za utvrđivanje cenei vremena potrebnog za razvoj softvera. Da bi se to postiglo, otkriva se,organizuje i dokumentuje zahtevana funkcionalnost softvera i to identifikovanjempotreba interesenata (stakeholder-a), korisnika (actor-a koji) ili drugih sistema kojisu u interakciji sa softverskim sistemom, koja se iskazuje preko Use case-ova.Svaki Use case se detaljno opisuje kroz Use case opis kojim se prikazuje u


26

kakvoj je interakciji softverski sistem sa korisnikom i šta on radi. Takođe se opisujui nefunkcionalni zahtevi koji se mogu odnositi na upotrebljivost, pouzdanost,performanse i podrživost softverskog rešenja.

Sa aspekta objektno orijentisane analize i dizajna su posebno važne aktivnosti:pronalaženje ator-a i Use case-ova, detaljna analiza Use case-ova i struktuiranjeUse case modela. Aktivnost koja se odnosi na postavljanje prioriteta međuidentifikovanim Use case-ovima je zaduženje onog ko definiše arhitekturu softverai radi plan projekta.

DISCIPLINA: ANALIZA I DIZAJN

Primarni ulaz za analizu i dizajn je Use case model dobijen kaoizlaz iz specifikacije zahteva a izlazi su model analize, koji nijeobavezan i model dizajna

• Cilj discipline analiza i dizajn je pokazati kako će se sistem realizovati ufazi implementacije. Primarni ulaz za analizu i dizajn je Use case modeldobijen kao izlaz iz specifikacije zahteva.

Izrada modela analize nije obavezna aktivnost već se radi samo u slučaju razvojavelikih sistema, ako se proceni da je to korisno. Odvija se kroz sledeće korake:

• Izrada dopunskih opisa Use Case-ova koji se rade da bi se dobila slika otome šta se dešava unutar sistema kako bi se generisao odgovor na porukeactor

• Identifikovanje klasa analize preko kojih se izvršava tok događaja iz UseCase-ova, najčešće korišćenjem tri različita pogleda na sistem.

• Distribucija ponašanja Use Case-ova na identifikovane klase analize• korišćenjem dijagrama Use Case realizacije (Use Case Realization).• Definisanje atributa za svaku izdvojenu klasu analize i uspostavljanje

asocijacija između klasa• Za razliku od modela analize kod kojeg se naglasak stavlja na domen

problema (poslovne zahteve) u modelu dizajna (design model) se naglasakstavlja na domen rešenja (detaljno razmatranje dizajna).

• Model dizajna služi kao apstrakcija izvornog koda, odnosno prikazujekako je izvorni kod struktuiran i napisan. On se sastoji od dizajn klasa kojesu struktuirane u dizajn pakete (package) i podsisteme sa dobro definisaniminterfejsima a sadrži i opise kojima se predstavlja način na koji objekti tih klasameđusobno kolaboriraju pri izvršenju Use

case-ova. Model dizajna se dobija izdvajanjem odgovarajućih elemenatadizajna iz elemenata dobijenih pri izradi modela analize.

Klase analize mogu evaluirati u različite vrste elemenata dizajna: klase dizajna safino definisanim svojstvima i ponašanjem (atributima i operacijama) ili podsisteme(subsistem) koji predstavljaju skup grubo definisanih odgovornosti.

Dizajniranje baze podataka podrazumeva izdvajanje perzistentnih klasa podatakaiz modela dizajna i dizajniranje odgovarajuće database strukture.


27

• Modela analize počinje na kraju faze “početak” i najvećim delom se preklapasa specifikacijom zahteva. Disciplina dizajna je primarna aktivnost u zadnjemdelu faze “početak” i u prvoj polovini faze “konstrukcija”.

DISCIPLINA: IMPLEMENTACIJA

Kod se organizuje u layer-e, objekti i klase implementiraju kaokomponente, koje se testiraju kao integrisana celina

• Svrha discipline implementacija je da se:• definiše organizacija koda u obliku informacionih podsistema

organizovanih u slojeve (layer-e)• objekti i klase implementiraju kao komponente (izvorni, binarni ili izvršni

file-ovi)• razvijene komponente testiraju kao celina i• rezultati nastali individualnim implementacijama integrišu u jedan

izvršni sistem.• Komponente se struktuiraju u informacione podsisteme koji u file sistemu

mogu imati formu direktorijuma ili foldera, u C++ ili Adi podsistema a u Javi sepojaviti kao paketi (package). Ova disciplina je u vezi sa disciplinama:

• Specifikacija zahteva kojom se preko Use Case modela opisuju zahtevi kojetreba ispuniti u implementaciji

• Analiza i dizajn kojom se opisuje model dizajna koji predstavlja primarni ulazza disciplinu implementacija

• Test kojom se opisuje kako testirati dobijeni implementacioni model da bi severifikovali svi zahtevi.

DISCIPLINA: TESTIRANJE

Vrši se verifikacija implementiranih softverskih komponenti

Svrha discipline testiranje je da se verifikuje:• iteracija između objekata,• integracija svih softverskih komponenti,• korektna implementacija svih zahteva kao i• da se identifikuju i otklone greške u softveru pre nego što se on isporuči

krajnjem korisniku.UP-om se predlaže iterativni pristup, koji podrazumeva da se testiranje vrši tokomrazvoja celog projekta. To omogućava da se greške pronađu što je moguće ranija,što radikalno smanjuje troškove fiksiranja grešaka. Kroz testiranje se proveravajutri dimenzije kvaliteta: pouzdanost, funkcionalnost i performanse softvera.


28

DISCIPLINA: RAZMEŠTANJE

Mada su aktivnosti uglavnom usmerene na fazu tranzicije,mnoge od njih su uključene u ranije faze kako bi se pripremaza razmeštanje izvršila na kraju faze razvoja.

Svrha ove discipline je uspešna proizvodnja verzije aplikacije i isporuka softvera donjegovog krajnjeg korisnika. Ona uključuje širok opseg aktivnosti kao što su:

• proizvodnja eksternih verzija softvera,• pakovanje,• distribuiranje i instalacija softvera,• pružanje pomoći i asistencije korisnicima

a u mnogim slučajevima uključuje i aktivnosti sprovođenja beta testiranja, migracijepostojećeg softvera i podataka i formalno prihvatanje.


29

Poglavlje 7 Vežba/>Kao vežbe treba ubaciti priložene tutorijale


30

Poglavlje 8 Zakljucak

ZAKLJUČAK

U ovom predavanju su opisane agilne metode i jedna od najpoznatijih metodologijakoja se bazira na OO pristupu poznata kao Unified Process (UN). UN se sastojiod faza i disciplina. UP-om se jedan razvojni ciklus deli na četiri faze: početak(Inception), razrada (Elaboration), konstrukcija (Construction) i prelaz (Transition).

Svaka faza razvoja UP-a se može odvijati kroz jednu ili više iteracija a svakaiteracija se izvršava kroz šest osnovnih disciplina (workflow-a): poslovnomodeliranje, specifikacija zahteva, analiza, dizajn, implementacija i testiranje

Poglavlje 8: Zakljucak

31

Documents

Lekcija 2 - Agilni i Objektno Orijentisani Razvoj Sistema