Tema 11:Objektno orijentisane metodologije razvoja softvera

Transcription

1 Tema 11:Objektno orijentisane metodologije razvoja softvera dr Vladislav Miškovic Fakultet za računarstvo i informatiku PROJEKTOVANJE INFORMACIONIH SISTEMA 2017/2018

2 Sadržaj predavanja 1. Uvod 2. Objektno orijentisane metodologije razvoja softvera 3. Metodologija RUP 4. Ostale objektno orijentisane metodologije 5. Upravljanje promenama 2

3 1. Uvod Metodologija razvoja softvera Pojam objektno orijentisane metodologije razvoja softvera 3

4 Metodologija razvojasoftvera Metodologija razvoja(system development methodology) je standardizovani proces razvoja,koji definišeskup aktivnosti, metoda, iskustava, preporuka i automatizovanih alatakoji se koristeza razvoj ineprekidno usavršavanjeinformacionog sistema klasične metodologije: SSAD novije metodologije: spiralna, iterativna, inkrementalna, kombinovane metodologije objektno orijentisame: RUP, XP Drugi naziv za metodologiju razvoja je proces razvoja sistema 4

5 Pojam objektno orijentisane metodologije razvoja softvera Objektno orijentisana metodologija razvoja(object oriented system development methodology) uzima objekte kao osnovu 1. Posmatra se i analizira budući sistem i definišu zahtevi, kao u drugim načinima razvoja sistema 2. Identifikuju se objekti u sistemu i njihove međusobne relacije 3. Vrši se kodiranje sistema Objektno modeliranje je donekle slično tradicionalnim pristupu projektovanju sistema, jer prati sekvencijalni proces projektovanja, ali srazličitim pristupom Osnovni koraci projektovanja sistema korišćenjem objektnog modeliranja su: (1) Analiza sistema (2) Dizajn sistema (3) Dizajn objekata (4) Implementacija 5

6 2. Objektno orijentisane metodologije razvoja softvera 1. Objektno orijentisani razvoj softvera 2. Objedinjeni proces razvoja softvera(up) 6

7 2.1 Objektno orijentisani razvoj softvera Objektno orijentisani razvoj koristi apstrakcijukao metod smanjenja kompleksnosti procesa razvoja Proceduralnaapstrakcija organizuje softver prema funkcijama, a apstrakcija podataka prema strukturi podataka Objektno orijentisani pristup posmatra sistem kao skup objekata (procedura i podataka) na različitim nivoima apstrakcije koji sarađuju radi izvršenja određenog zadatka glavni program izvršavanjetransakcija podaci Račun kreditni() debitni() kreditne debitne obračunkamata if štedni then... obračuntroškova if štedni then... TekućiRačun obračunkamata() obračuntroškova() Štedni račun obračunkamata() obračuntroškova() (a) Proceduralna organizacija sistema (b) Objektna organizacija sistema 7

8 2.2 Objedinjeni proces razvoja softvera (Unified Process, UP) Proces razvoja softvera je pristup izgradnji, isporuci i održavanju softvera predstavlja parcijalno uređeni niz koraka usmerenih ka cilju cilj je efikasna i predvidiva isporuka softverskog sistema, koji zadovoljava zahteve poslovanja Objedinjeni proces (Unified Process, UP) je proces razvoja objektno orijentisanih sistema cilj objedinjenog procesa je omogućavanje izrade visokokvalitetnog softvera, koji zadovoljava korisničke zahteve za predvidivovreme i budžet za kompleksne sisteme, objedinjeni proces predviđa iterativni razvoj, koji se sastoji od niza ciklusa, od kojih svaki rezultuje izvršnom verzijom sistema 8

9 Faze objedinjenog procesa Inception Elaboration Construction Transition vreme Objedinjeni proces organizuje rad i iteracije u četiri osnovne vremenske faze: 1. Inception- početna faza, definisanje obima projekta 2. Elaboration-faza razrade, planiranje, izrada specifikacijai osnovna arhitektura 3. Construction- faza izgradnje sistema 4. Transition- faza prenosa sistema krajnjim korisnicima 9

10 Iteracije i preseci (milestones) Inception Elaboration Construction Transition Preliminarna iteracija Iteracija 1 Iteracija 2 Iteracija i Iteracija N kontrolna tačka/presek verzija konačna verzija Sve iteracije podrazumevaju vremenski promenljiv rad na većini disciplina, nose određeni rizik i vremenski završavaju u nekoj kontrolnoj tački Pregled projekta u kontrolnoj ili presečnoj tački ocenjuje stepen zadovoljenja korisničkih zahteva i potrebu za eventualnim prestrukturiranjem projekta Svaka iteracija proizvodi novu verziju, stabilni izvršni podskup konačnog sistema (kôd) 10

11 Discipline objedinjenog procesa (UP) rezultat početne faze: Projektni zahtev rezultat aze razrade:projekt predmet Projektovanje informacionih sistema 11

12 1. Početna faza (Inception): šta treba razviti Odgovara na veći broj pitanja/dilema: vizija poslovnog rešenja ocena izvedivosti projekta odluka o samostalnom razvoju ili kupovini gruba procena troškova odluka o nastavku projekta razvoja Početna faza obuhvata rad na ustanovljavanju početnih opštih ciljevi projekta, određivanju izvedivosti i odlučivanje o daljem radu na razradi projekta Rezultati ove faze izlažu se u dokumentu Projektni zahtev 12

13 Dijagrami slučajeva korišćenja(use-case) Pomažu u rešavanju osnovnog problema u procesu projektovanja sistema: izvlačenju tačnih i neophodnih projektnih zahtevaod učesnika u razvoju i njihovo predstavljanje na način razumljiv onima koji ih verifikuju i odobravaju podaci i modeli procesa, prototipovi, specifikacije zahtevasu razumljivi projektantima, ali ne i korisnicima dolazi do nerazumevanja, usporavnja razvoja i prekoračenja troškova Podsetnik: precizno definisanje onog što je potrebno uraditi je najteži pojedinačni deo procesa razvoja softvera uključujuči sve interfejse ka ljudima, uređajima i drugim sistemima 13

14 2. Faza razrade (Elaboration): kako razviti sistem Detaljna razrada korisničkih zahteva (njihov najveći deo, oko 80%) Određivanje izvršne i stabilne arhitekture definisanje, implementacija i testiranje interfejsa glavnih komponenti identifikacija zavisnosti spoljnih komponenti i sistema delimična implementacija ključnih komponenti delimična implementacija koda (oko 10%) Arhitektura sa ključnim slučajevima korišćenja manji deo slučajeva korišćenja nosi 80% arhitekture projektovanje, implementacija i testiranje važnih slučajeva korišćenja Verifikacija arhitekture testovi opterećenja(stress) za proveru ponašanje sistema kada je na granici resursa ili ih mora konkurentno obezbediti testovi punjenja(load), performanse i skalabilnost Stalna procena poslovnih slučajeva korišćenja, rizika i plana razvoja 14

15 3. Faza izgradnje (Construction): izrada sistema Završetak modela zahteva i projekta Projektovanje, implementacija i testiranje komponenti prototip sistema za prikaz korisniku inkrementalno uključivanje izvršne arhitekture radi završetka sistema Razvija se dnevno ili nedeljno (automatizovano) Testiranje svake verzije Automatsko regresivno testiranje (potvrdase da suostali delovi sistema ostali stabilni posle završetka iteracije) Test punjenja i stresa kako bi se osigurao integritet arhitekture Isporuka funkcionalnog softvera(beta verzija) dokumentaciju uvođenja rešenja u sistem, korisnička dokumentacija i materijali za obuku Izrada opisa verzije 15

16 4. Faza prenosa (Transition): isporuka sistema Potvrda da realizovani sistem zadovoljava tražene funkcionalnosti i performanse Uvođenje inkrementalne programski korektne verzije Ažuriranje korisničkih priručnika i dokumentacije uvođenja Ažuriranje verzije Vođenje analize projekta u toku perioda zatišja 16

17 3. MetodologijaRUP Specijalizacija UP procesa razvoja Sopstveni razvojni alati 17

18 Specijalizacija UP procesa razvoja RUP je specifična implementacija objedinjenog procesa razvoja (UP) kompanije Rational(od godine deo IBM) Osnovni elementi 1. Iterativno-inkrementalni razvoj softvera upravljan rizikom 2. Upravljanje zahtevima pomoću slučajeva korišćenja i scenarija 3. Centralna uloga arhitekture softvera (component-based architecture) 4. Vizuaelni razvoj softvere (UML) 5. Kontinualno upravljanje kvalitetom i 6. Upravljanje promenama Još neke implementacije UP OpenUP- pojednostavljena verzija (Eclipse Process Framework, EPF) Agile UP/DAD - razvoj poslovnih aplikacija agilnim tehnikama 18

19 Sopstveni razvojni alati RUP ima sopstvene licencirane razvojne alate IBM Rational Method Composer(2007) -predstavlja CMS i ima proširenja RUP (capability patterns, npr. RUP za SOA, systems, COTS) postoji i open source verzija (Eclipse) 19

20 4. Ostale objektno orijentisane metodologije 1. Agilne metodologije 2. Ekstremno programiranje (XP) 3. Metodologija SCRUM 4. Microsoft Solutions Framework (MSF) 20

21 4.1 Agilne metodologije Problemi u razvoju softvera korišćenjem strogih metodologija, krajem 20. veka (npr. metodoogijavodopada) prouzrokuju pojavu manje strogih metodologija (lightweight, agile) Osnovna ideja je da manje projekte (i timove) treba manje opterećivati birokratijom, već treba naći razuman kompromis Principi agilnog pristupa: isporuka onoga što korisnik traži što češća isporuka rezultata(iterativni i inkrementalni pristup) najjednostavnije moguće rešenje prilagođavanje dobroj praksi(iskustvo) vrednovanje individualnih mogućnosti članova tima međusobna saradnja celog razvojnog tima 21

22 4.2 Ekstremno programiranje (XP) Agilna metodologija, podrazumeva i prihvata stalne promene sistema kao činjenicu Realizuje se kroz male ili srednje razvojne timove,koji rade u tesnoj saradnji s korisnikom Ne koristi se precizno planiranje, već se teži brzim, opipljivim rezultatima, koji se odmah predočavaju korisniku Metodologiju čine karakteristični elementi planiranje analiza testiranje kodiranje programiranje u parovima 22

23 Elementi metodologije ekstremnog programiranja 1. Planiranje korisnik piše scenario razvojni tim procenjuje trajanje i troškove korisnik donosi odluku o sledećem koraku jedna razvojna iteracija- nekoliko scenarija, razvoj od nekoliko nedelja 2. Analiza sistem se posmatra kao skup korisničkih scenarija jedan scenario- jedan slučaj korišćenja (kao UML Use Case, ali neformalno) 23

24 Elementi metodologije ekstremnog programiranja 3. Testiranje testovi se pišu pre programiranja sistema svaki scenario je jedan skup testova svi testovi se moraju izvršavati sve vreme 4. Kodiranje poštuju se standardi kodiranja dobar stil i dokumentacija koda kodiraju se najjednostavnije celine koje mogu da funkcionišu 5. Programiranje u parovima sav kod se piše u parovima neprekidna međusobna komunikacija, programiranje i analiza koda zamena uloga, više puta u toku dana 24

25 4.3 Metodologija Scrum Metodologija je dobila naziv po ragbi formaciji od osam igrača, koji kao grupa (jedinstvena celina) pomeraju loptu po terenu ka zajedničkom cilju Iterativnametodologija, podrazumeva da zahtevi nisu odmah jasni i poznati, već se iskustveno otkrivaju u toku razvoja Agilnametodologija, bliska XP, podrazumeva dnevne sastanke na kojima programeri iznose probleme koji utiču na napredovanje, koje razrešava tzv. Scrum Master Povratna veza prema svim učesnicima preko dnevnika mesečnih zadataka Backlog Nije pogodna za velike projekte 25

26 Principi metodologije Scrum Obuhvata upravljanje zahtevima, formiranje iteracija (planiranje sprinta), kontrole implementacije i isporuke klijentu empirijski metod i tehnike menadžment drugih projekta Dnevni sastanci, 30-dnevne iteracije 1.Šta je urađeno juče? 2.Šta će se raditi danas? 3. Kakve se prepreke danas očekuju? 26

27 4.4 Microsoft Solutions Framework (MSF) Principi, modeli, discipline, koncepti i preporukeza isporuku IT rešenja kompanije Microsoft Samo opšti principi visokog nivoa, okvir (framework) dopušta izbor metodologije (klasične ili agilne) koncentriše se na rezultate Modeli Model organizovanja (team) - ulogečlanova tima: menadžment, arhitektura, razvoj, testiranje, isporuka, podrška Model upravljanja (governance) - fazeprocesa razvoja: vizija, planiranje, razvoj, verifikacija i isporuka 27

28 5. Upravljanje promenama 1. Upravljanje promenama 2. Pojam upravljanja konfiguracijom (SCM) 3. Aktivnosti upravljanja konfiguracijom 4. Planiranje upravljanja konfiguracijom 5. Primeri sistema 28

29 5.1 Upravljanje promenama Upravljenje promenama softverskog sistema ili upravljanje konfiguracijom(software Configuration Managemet, SCM) Upravljenje promenama se bavi praćenjem u upravljanjem promenama u softveru i drugim rezultatima razvoja i omogućava pregled promena u toku projekta omogućava zapis vrste promene, izvršioca i elemente konfiguracije sistema koji se menjaju, kao i upravljanje integritetom sistema u toku promena

30 5.2 Pojam upravljanja konfiguracijom (SCM) Upravljanje konfiguracijom Ciljevi upravljanja konfiguracijom

31 Upravljanje konfiguracijom (SCM) Upravljanje konfiguracijom je proces identifikovanja, praćenja i pamćenja svih artefakata projekta razvoja softverkog sistema u upravljanju konfiguracijom, svaki aratifakt je element konfiguracije (Configuration Item, CI)

32 Ciljevi upravljanja konfiguracijom Ciljevi upravljanja konfiguracijom su osnovna bezbednost sistema zaštita sistema od međusobnog prepisivanja mogućnost povratka na prethodnu verziju zaštita sistema od uništenja

33 5.3 Aktivnosti upravljanja konfiguracijom 1. Identifikovanje konfiguracija 2. Osnovno upravljanje (Baseline control) 3. Upravljenje promenama (Change control) 4. Upravljanje verzijama (Version control)

34 5.3.1 Identifikovanje konfiguracija Izbor i označavanje objekata (artefakata sistema) koji će se pratiti brojni atributi, npr. naziv, datum, autor, istorijat promenai status

35 5.3.2 Osnovno upravljanje (Baseline Control) Osnovno upravljanje obuhvata praćenje potvrđenih promena elemenata konfiguracije Nove promene se ne mogu izvršiti bez formalne procedure upravljanja promenama Osnovno upravljanje obezbeđuje ponovljivost praćenje promena izveštavanje

36 5.3.3Upravljenje promenama (Change Control) Upravljanje promenama je proces analize troškova i koristi od predloženih izmena, potvrda da su isplative i praćenje komponenti sistema koje su izmenjene

37 5.3.4Upravljanje verzijama (Version Control) Namena upravljanje verzijama Vrste sistema za upravljanje verzijama Načini rada Primeri softvera za upravljanje verzijama

38 Namena upravljanje verzijama Osnovna namena upravljanja verzijama softverskog sistema je 1) Koordinacija promena izvornog koda između više članova razvojnog tima ili više timova 2) Zapis jedinstvene zvanične verzije koda sistema 3) Centralizacija smeštanja koda i obezbeđenje nezavisnosti računara razvojnog tima 4) Automatizacija testiranja i izgradnje sistema na zahtev ili u planiranim terminima

39 Vrste sistema za upravljanje verzijama a) Centralizovani b) Decentralizovani a) centralizovani b) decentralizovani

40 Načini rada Osnovna namena sistema za upravljanje verzijama je koordinacija deljenja fajlova između više članova razvojnog tima (npr. konkuretne izmene) U praksi se koriste dva načina načina upravljanja interakcijom s lokalnim kopijama: Lock on check out(loco)-kad jedan korisnik traži fajl s repozitorijuma, on se zaključava za ostale (serijalizacija) Merge on modify (MOM)-više korisnika može istovremeno da traži fajl s repozitorijuma, a sistem objedinjava njihove izmene

41 Primeri softvera za upravljanje verzijama Sistemi za upravljanje verzijama najčešće imaju tri vrste klijentskog softvera[crookshanks]: komande operativnog sistema, GUI klijente/dodatke s grafičkim interfejsom i dodatke (plug-ins) za druga razvojna okruženja (IDE) Primeri sistema su: IBM ClearCase Microsoft Team System CVS Git Apache Subversion- dodatak (plug-in) poznat kao"svn" Tortoise SVN- dodatak (plug-in) za Microsoft Windows File Explorer

42 Ilustracija: Microsoft Visual Studio Sistem Visual Studio od verzije 2015 koristi dva načina upravljanja verzijama Git(decentralizovani) -svaki razvojni inženjer ima kopiju repozitorijuma izvornog koda na svom računaru. Svaki skup promena se potvrđuje (commit). Grananja (branch) se lako lokalno kreiraju i kasnije jednostavno menjaju, spajaju (merge), objavljuju (publish) ili uklanjaju Team Foundation Version Control(centralizovani) -najčešće članovi tima imaju samo jednu verziju svakog fajla na svojim razvojnim računarima. Evidencija promena je samo na serveru. Grananja su zasnovana na putanjama, koje se kreiraju na serveru

43 5.4 Planiranje upravljanja konfiguracijom Proces planiranja definisan je standardom upravljanja konfiguracijom sistema IEEE

44 5.5 Primeri sistema Ilustracija: Dodatak(plug-in)Tortoise SVN

45 Ilustracija: Dodatak (plug-in) Tortoise SVN Primer strukture foldera minimalne C# Windows Forms apliakcije kreirane u sistemu Visual Studio 2010 [] aplikacija samo ispisuje pozdravnu poruku nakon aktiviranja tastera forme Say Hello

46 SVN: Uvoz koda Instalacija dodatka Tortoise SVN može se preuzeti sa sajta Elemente konfiguracije -fajlove aplikacije treba dodati u repozitorijum (Import)

47 SVN: Pregled repozitorijuma Logika upravljanja verzijama omogućava grananje (Branch) i označavanje (Tag) izvornog koda grananje omogućava istovremeno više paralelnih tokova promena koda označavanje omogućava dodatnu identifikaciju promena (revizija) koda

48 SVN: Funkcija usklađivanja (Checkout) Usklađivanje lokalne kopije softvera, koja se nalazi na folderu aplikacije, vrši se (desni klik) izborom funkcije SVN Checkout Checkout Depthopcija omogućava podešavanje rukovanja rekurzijom u strukturi fajlova Show logtaster otvara ekran za prikaz detalja revizije (datumi, akcije, poruke)

49 SVN: Stablo repozitorijuma Kad se izabere opcija prikaza Fully recursive, kopira se celo stablo u lokalni radni folder, a vizuelni prikaz fajlova vrši se posebnim ikonama Poseban.svn folder dodaje se u hijerarhiju foldera (na slici je prikaz za dva korisnika, koji usklađuju svoj kod)

50 SVN: Nepotvrđene promene korisnika Kad se izmene u kodu nekog korisnika sačuvaju, vide se posebne oznake promenjenih foldera i fajlova, koje označavaju nepotvrđene promene (uncommitted changes), koje treba uskladiti (Checkout)

51 SVN: Neuspešna i uspešna operacija ažuriranja (nakon SVN Update)

52 SVN: Označavanje i grananje Važne funkcije upravljanja verzijama su praćenje izmena i mogućnost konkurentnog editovanja Ostale važne mogućnosti su: Označavanje(tagging, labeling)je mehanizam identifikacije određene revizije koda kao značajne u razvoju ili isporuci softvera Grananje(branching) omogućava izolovanje određenog koda u odvojenom području. Taj kod se može zasebno menjati, bez uticaja na osnovni tok (trunk) promena koda Različiti softverski alati za upravljanje verzijama ove funkcije realizuju na različite načine

53 Primer: Istorijat izmena i struktura repozitorijuma pre izmene Istorijat promena nekog elementa dobija se izborom funkcije Revision Graphiz SVN menija

54 Primer: Istorijat i struktura repozitorijuma posle grananja i izmene

55 Literatura 1. Miškovic V., Projektovanje informacionih sistema (predavanja), Univerzitet Sinergija, Sommerville I., Software Engineering, 10thEd, Addison Wesley, Bruegge B., Dutoit A. H., Object-Oriented Software Engineering Using UML, Patterns, and Java, Prentice Hall, Schach S.R., Object-oriented Software Engineering, McGraw-Hill, Braude E. J., Bernstein M. E., Software Engineering, 2nd Ed, Waveland, Agarwal B. B., Tayal S. P., Software Emgineering, 3rd Ed, Firewall Media, Crookshanks E., Practical Software Development Techniques, Apress, IBM Rational Product Training: DEV475 Mastering Object-Oriented Analysis and Design with UML 9. Priručnici za programske alate i Web reference 55

56 dr Vladislav Miškovic Projektovanje informacionih sistema Tema 11: Objektno orijentisane metodologije razvoja softvera Pitanja? 56