Softversko inzenjestvo - Skripta, Rezime od Softversko inženjerstvo

Preuzmite Softversko inzenjestvo - Skripta i više Rezime u PDF od Softversko inženjerstvo samo na Docsity!

Sveuˇciliˇste u Zagrebu

Prirodoslovno Matematiˇcki Fakultet

• Matematiˇcki odjel

Robert Manger

SOFTVERSKO INˇZENJERSTVO

skripta

Korigirano prvo izdanje

Zagreb, veljaˇca 2008.

ii

iv

Sadrˇzaj

Poglavlje 1

UVOD U SOFTVERSKO

INˇZENJERSTVO

1.1 Osnovni pojmovi vezani uz softversko inˇzenjerstvo

Jedan od ciljeva ovog kolegija je da poveˇze i sistematizira znanje koje smo ve´c stekli u prethodnim “softverskim” kolegijima, kao ˇsto su kursevi programskih jezika, raˇcunarski praktikumi, kursevi o algoritmima, bazama podataka, mreˇzama raˇcunala i sliˇcno. Osnovni pojmovi u ovom kolegiju odnose se na problematiku razvoja softvera i ve´c smo ih susretali u spomenutim prethodnim kolegijima. Ipak, sad tim istim pojmovima nastojimo dati preciznije znaˇcenje.

1.1.1 Softverski produkt i softversko inˇzenjerstvo

Softverski produkt je skup raˇcunalnih programa i pripadne dokumentacije, stvoren zato da bi se prodao. Moˇze biti razvijen za sasvim odredenog korisnika (engleski bespoke product, customized product) ili op´cenito za trˇziˇste (engleski generic product). Softverski produkt ˇcesto ´cemo kra´ce nazivati softver ili (softverski) sustav.

Za danaˇsnji softver se podrazumijeva da on mora biti kvalitetan. Preciznije, od softverskog produkta se oˇcekuje da se on odlikuje sljede´cim atributima kvalitete.

• Mogu´cnost odrˇzavanja. Softver se mora mo´ci mijenjati u skladu s promijenjenim potrebama korisnika.
• Pouzdanost i sigurnost. Softver se mora ponaˇsati na predvidiv naˇcin, te ne smije izazivati fiziˇcke ili ekonomske ˇstete.
• Efikasnost. Softver mora imati zadovoljavaju´ce performanse, te on treba upravljati strojnim resursima na ˇstedljiv naˇcin.
• Upotrebljivost. Softver treba raditi ono ˇsto korisnici od njega oˇcekuju, suˇcelje mu treba biti zadovoljavaju´ce, te za njega mora postojati dokumentacija.

Softversko inˇzenjerstvo je znanstvena i struˇcna disciplina koja se bavi svim aspektima proizvodnje softvera. Dakle, softversko inˇzenjerstvo bavi se modelima, metodama i alatima koji su nam potrebni da bi na ˇsto jeftiniji naˇcin mogli proizvoditi ˇsto kvalitetnije softverske produkte.

Softversko inˇzenjerstvo poˇcelo se razvijati krajem 60-tih godina 20-tog stolje´ca, kao odgovor na takoz- vanu “softversku krizu”. Naime, pojavom raˇcunala tre´ce generacije (na primjer IBM serija 360) stvorila se potreba za sloˇzenijim softverom (na primjer multi-tasking operacijski sustav). Pokrenuti razvojni projekti viˇsestruko su premaˇsili planirane troˇskove i rokove. Vidjelo se da se dotadaˇsnje neformalne

2 POGLAVLJE 1. UVOD U SOFTVERSKO INZENJERSTVOˇ

tehnike individualnog programiranja ne mogu uspjeˇsno “skalirati” na velike programe gdje sudjeluje velik broj programera. Osje´cala se potreba za sloˇzenijim metodama razvoja softvera, koje bi liˇcile na metode iz tradicionalnih tehniˇckih struka (na primjer mostogradnja) te bile u stanju kontrolirati kompleksnost velikog softverskog projekta.

Od 60-tih godina do danas, softversko inˇzenjerstvo uspjelo se etablirati kao vaˇzni dio tehnike i raˇcunar- stva. Softver se danas proizvodi daleko predvidljivije i efikasnije nego prije. Ipak, joˇs uvijek postoji prostor za poboljˇsanje. Softversko inˇzenjerstvo se i dalje intenzivno razvija, disciplina joˇs nije dosegla svoju zrelu fazu, te u njoj nema “jednoumlja”.

1.1.2 Softverski proces, metode i alati

Softverski proces je skup aktivnosti i pripadnih rezultata ˇciji cilj je razvoj ili evolucija softvera. Os- novne aktivnosti unutar softverskog procesa su: specifikacija, oblikovanje, implementacija, verifikacija i validacija, te odrˇzavanje odnosno evolucija.

Model za softverski proces je idealizirani prikaz softverskog procesa, kojim se odreduje poˇzeljni naˇcin odvijanja i medusobnog povezivanja osnovnih aktivnosti. Na primjer, model moˇze zahtijevati sekven- cijalno odnosno simultano odvijanje aktivnosti.

Metoda razvoja softvera je profinjenje i konkretizacija odabranog modela za softverski proces. Metoda uvodi specifiˇcnu terminologiju. Takoder, ona dijeli osnovne aktivnosti u pod-aktivnosti te propisuje ˇsto se sve mora raditi unutar pojedine pod-aktivnosti. Dalje, metoda uvodi konkretan naˇcin doku- mentiranja rezultata pod-aktivnosti (dijagrami, tabele, pseudo-jezik,... ), te daje naputke vezane uz organizaciju rada, stil oblikovanja, stil programiranja, itd.

Starije funkcionalno-orijentirane metode poput Yourdonove ili Jacksonove JSD (80-te godine 20- tog stolje´ca) slijede logiku starijih funkcionalno-orijentiranih programskih jezika (Cobol, C, Fortran). Novije objektno-orijentirane metode predstavljaju nadgradnju objektno-orijentiranih programskih jezi- ka (Java, C++) i danas su se integrirale u zajedniˇcki standard RUP (engleski Rational Unified Process

• Booch, Rumbaugh, Jacobson - 90-te godine) koji je utemeljen na notaciji UML (engleski Unified Modelling Language).

CASE alati (engleski Computer Aided Software Engineering) su softverski paketi koji daju automa- tiziranu podrˇsku za pojedine aktivnosti unutar softverskog procesa. Obiˇcno su napravljeni u skladu s odredenom metodom razvoja softvera, implementiraju pravila iz te metode, sadrˇze editore za odgo- varaju´ce dijagrame, te sluˇze za izradu odgovaraju´ce dokumentacije.

Takozvani upper-CASE alati daju podrˇsku za poˇcetne aktivnosti unutar softverskog procesa, kao ˇsto su specifikacija i oblikovanje. Lower-CASE alati podrˇzavaju samu realizaciju softvera, dakle programi- ranje, verifikaciju i validaciju, te eventualno odrˇzavanje.

Na vjeˇzbama iz ovog kolegija obradit ´cemo funkcionalno-orijentiranu metodu SADIE, te ´cemo raditi s odgovaraju´cim upper-CASE alatom Select Yourdon (podrˇska za funkcionalnu specifikaciju i obliko- vanje). U jednom dijelu vjeˇzbi simulirat ´cemo primjenu objektno-orijentiranih metoda, te ´cemo se sluˇziti upper-CASE alatom za objektno oblikovanje i crtanje UML dijagrama ArgoUML. Na vjeˇzbama iz drugih kolegija koristi se lower-CASE alat Microsoft Visual Studio (podrˇska za implementaciju, testiranje, debugiranje,... ).

1.2 Modeli za softverski proces

U svim modelima viˇse ili manje su prisutne sljede´ce osnovne aktivnosti koje ˇcine softverski proces:

• Specifikacija. Analiziraju se zahtjevi korisnika. Utvrduje se ˇsto softver treba raditi.
• Oblikovanje (engleski design.) Oblikuje se grada sustava, naˇcin rada komponenti, te suˇcelje izmedu komponenti. Dakle projektira se rjeˇsenje koje odreduje kako ´ce softver raditi.

4 POGLAVLJE 1. UVOD U SOFTVERSKO INZENJERSTVOˇ

Pribliˇzni opis

Simultane aktivnosti

Implementacija

Specifikacija

Verifikacija, validacija

Oblikovanje

Polazna verzija

Privremene verzije

Konaˇcna verzija

@I@

@@R

@R

Slika 1.2: evolucijski razvoj softvera.

Evolucijski razvoj ˇciji cilj je da se s korisnikom istraˇze zahtjevi te zaista proizvede konaˇcni sustav zove se istraˇzivaˇcko programiranje. Ukoliko je jedini cilj istraˇzivanje zahtjeva, tada je rijeˇc o prototipiranju

• vidi Odjeljak 2.3.

Prednosti modela evolucijskog razvoja su sljede´ce.

• Model je u stanju proizvesti brzi odgovor na zahtjeve korisnika.
• Postoji mogu´cnost da se specifikacija postepeno razvija u skladu sa sve boljim korisnikovim razumijevanjem problema.

Mane modela evolucijskog razvoja su sljede´ce.

• Proces nije transparentan za managere, naime oni ne mogu ocijeniti koliki dio posla je napravljen i kad ´ce sustav biti gotov.
• Konaˇcni sustav obiˇcno je loˇse strukturiran zbog stalnih promjena, te je nepogodan za odrˇzavanje.
• Zahtijevaju se posebni alati i natprosjeˇcni softverski inˇzenjeri.

Model se uspjeˇsno koristi za razvoj web sjediˇsta, te za male sustave s kratkim ˇzivotnim vijekom, pogotovo za sustave s nejasnim zahtjevima.

1.2.3 Model formalnog razvoja

Model formalnog razvoja (engleski formal systems development) zasniva se na koriˇstenju takozvanih formalnih metoda za razvoj softvera. Zahtjevi se precizno definiraju na formalni naˇcin, koriˇstenjem nedvosmislene matematiˇcke notacije. Zatim se ta formalna specifikacija transformira do programa, nizom koraka koji ˇcuvaju korektnost. Cijeli proces prikazan je u Slikom 1.3, dok je ideja formalnih transformacija detaljnije ilustrirana Slikom 1.4.

'

Neformalna specifikacija

Formalna specifikacija

Formalne transformacije

Integracija i testiranje sustava

Slika 1.3: proces formalnog razvoja softvera.

1.2. MODELI ZA SOFTVERSKI PROCES 5

Formalne transformacije:

Formalna specifikacija softvera

R1 R2 R3 (^) programIzvrˇsivi

D1 D2 D3 D

Sve detaljnije reprezentacije sustava

Dokazi korektnosti transformacija

Slika 1.4: formalne transformacije u sklopu formalnog razvoja softvera.

Prednosti modela formalnog razvoja su sljede´ce.

• Nakon izrade formalne specifikacije, sve daljnje faze razvoja softvera mogle bi se automatizirati.
• Postoji “matematiˇcki” dokaz da je program toˇcna implementacija polazne specifikacije; nema velike potrebe za testiranjem.

Mane modela formalnog razvoja su sljede´ce.

• Izrada formalne specifikacije zahtijeva velik trud i znanje.
• Dokazi korektnosti transformacija postaju preglomazni za iole ve´ce sustave.
• Korisnici ne mogu pratiti razvoj.
• Postoje´ci specifikacijski jezici nisu pogodni za interaktivne sustave.

Model se za sada relativno malo koristi u praksi, te se preporuˇcuje jedino za sustave gdje se zahtijeva izuzetno velika pouzdanost i sigurnost. Mogu´ce je da ´ce se model znatno viˇse koristiti u budu´cnosti ukoliko se razviju bolji specifikacijski jezici te bolji alati za automatske transformacije.

1.2.4 Model usmjeren na ponovnu upotrebu

Model usmjeren na ponovnu upotrebu (engleski reuse-oriented development) polazi od pretpostavke da ve´c postoje gotove i upotrebljive softverske cjeline, kao ˇsto su COTS sustavi (engleski Commercial Off-The-Shelf Systems) ili dijelovi prije razvijenih sustava. Novi sustav nastoji se u ˇsto ve´coj mjeri realizirati spajanjem postoje´cih dijelova, u skladu sa Slikom 1.5. Ista ideja prisutna je i u drugim tehniˇckim disciplinama: novi mehaniˇcki ili elektroniˇcki proizvod nastoji se sklopiti od standardnih dijelova (vijaka, ˇcipova,... ).

'

Specifikacija zahtjeva

Analiza raspoloˇzivih dijelova

Modifikacija zahtjeva

Oblikovanje sus- tava uz ponovnu upotrebu dijelova

Implementacija i integracija

Verifikacija i validacija sustava

Slika 1.5: proces razvoja softvera uz ponovnu upotrebu.

1.3. UPRAVLJANJE SOFTVERSKIM PROJEKTOM 7

1.3 Upravljanje softverskim projektom

Ovaj kolegij bavi se raˇcunarskim i tehniˇckim aspektima softverskog inˇzenjerstva. No podjednako vaˇzan je i organizacijski (managerski) aspekt, koji je tema posebnog kolegija, i o kojem ´cemo ovdje dati samo uvodne napomene.

Upravljanje softverskim projektom (engleski software project management) potrebno je zato da bi se softver razvio na vrijeme i u okvirima planiranih troˇskova. Posao upravljanja softverskim projektom povjerava se softverskom manageru.

1.3.1 Osobine softverskog projekta

Softverski projekt se po sljede´cim osobinama razlikuje od klasiˇcnog tehniˇckog projekta kao ˇsto je gradnja mosta ili broda.

• Produkt je “neopipljiv”. Teˇsko je vidjeti rezultat. Teˇsko je procijeniti koliki dio posla je obavljen. Manager se mora pouzdati u apstraktne dokumente.
• Nema standardnog procesa. Postoje razne metode i alati, no ne zna se ˇsto je najpogodnije u zadanim okolnostima.
• Projekt je obiˇcno “neponovljiv”. Stara iskustva obiˇcno nisu primjenjiva. Pojavljuju se nepredvi- deni problemi. Tehnologija se brzo mijenja.

Zbog ovih osobina, upravljanje softverskim projektom je izuzetno teˇzak managerski zadatak, te zahti- jeva izuzetno dobrog managera.

1.3.2 Poslovi softverskog managera

Poslovi softverskog managera medu ostalim ukljuˇcuju sljede´ce:

• pisanje prijedloga projekta,
• procjenjivanje troˇskova projekta,
• planiranje i pra´cenje projekta,
• izbor i ocjenjivanje suradnika,
• pisanje izvjeˇstaja i prezentiranje.

1.3.3 Planiranje i pra´cenje projekta

Planiranje i pra´cenje projekta predstavlja redoviti, svakodnevni i najegzaktniji posao softverskog man- agera. Planiranje i pra´cenje ukljuˇcuje sljede´ce:

• definiranje projektnih aktivnosti, njihovog trajanja i meduzavisnosti,
• odredivanje kalendara poˇcetka i zavrˇsetka svake aktivnosti,
• rasporedivanje ljudi i drugih resursa na aktivnosti,
• pra´cenje izvrˇsenja aktivnosti,
• povremena revizija svih parametara.

8 POGLAVLJE 1. UVOD U SOFTVERSKO INZENJERSTVOˇ

Za planiranje i pra´cenje projekta, manager koristi egzaktne modele i metode, poput mreˇznih planova, analize kritiˇcnih putova, Ganttovih dijagrama. Te metode i modeli implementirani su u odgovaraju´cim alatima za upravljanje projektima, na primjer Microsoft Project.

U prilozima 1.1 - 1.4 vidimo primjer projekta koji se sastoji od 12 aktivnosti sa zadanim trajanjima i meduovisnostima. Skup aktivnosti prikazan je kao mreˇza. Pronadene su kritiˇcne aktivnosti, dakle one koje se nalaze na najduljem putu izmedu ˇcvorova mreˇze koji odgovaraju poˇcetku odnosno kraju projekta. Manager treba posvetiti posebnu paˇznju kritiˇcnim aktivnostima, zato jer bi njihovo kaˇsnjenje uzrokovalo kaˇsnjenje cijelog projekta. Kalendar odvijanja aktivnosti najprije je utvrden na mreˇzi, a zatim je prikazan je kao Ganttov dijagram. Zatim su ljudi rasporedeni na aktivnosti, pa je nacrtan Ganttov dijagram zauzetosti ljudi.

10 POGLAVLJE 2. ZAHTJEVI I SPECIFIKACIJA

Studija izvodljivosti

Otkrivanje i analiza zahtjeva

Utvrdivanje zahtjeva

Validacija zahtjeva

Izvjeˇstaj o izvodljivosti

Modeli sustava

Korisniˇcki zahtjevi i zahtje- vi na sustav

Dokument o zahtjevima

Slika 2.1: pod-aktivnosti koje ˇcine aktivnost specifikacije.

2.1.3 Vrste dokumenata koji opisuju zahtjeve

Rezultat specifikacije su dokumenti koji opisuju zahtjeve. Ti dokumenti razlikuju se po svom sadrˇzaju, naˇcinu opisivanja, te detaljnosti. Uvodimo sljede´ce nazive za pojedine vrste dokumenata.

• Korisniˇcki zahtjevi. To je manje precizan tekst u prirodnom jeziku, popra´cen dijagramima i tablicama, opisuje funkcije sustava i ograniˇcenja pod kojima sustav radi. Prilagoden je krajnjim korisnicima.
• Zahtjevi na sustav. Rijeˇc je o detaljnom i preciznom opisu funkcija sustava i ograniˇcenja. Moˇze sluˇziti kao temelj ugovoru izmedu kupca i razvijaˇca softvera. Sluˇzi softverskim inˇzenjerima kao polaziˇste za oblikovanje. Pisan je u donekle strukturiranom prirodnom jeziku.
• Modeli sustava. To su dijagrami koji opisuju ponaˇsanje sustava na naˇcin koji je precizniji i jezgrovitiji od prirodnog jezika (vidi Odjeljak 2.2). Nastaju tijekom analize zahtjeva kao sredstvo komunikacije izmedu razvijaˇca softvera i budu´cih korisnika.
• Dokument o zahtjevima. Rijeˇc je o konaˇcnom rezultatu specifikacije, dobivenom kao unija svih prethodno opisanih dokumenata.
• Specifikacija softverskog designa. Ovaj dokument nije obavezan. Predstavlja apstraktni opis grade softvera i funkcija koje on obavlja, pisan u formalnom jeziku (vidi Odjeljak 2.4). Pret- postavlja odredenu arhitekturu sustava, te na osnovu nje dalje razraduje “zahtjeve na sustav”. Eventualno se stvara kao most izmedu aktivnosti specifikacije i oblikovanja. Sluˇzi razvijaˇcima softvera kao polaziˇste za daljnje oblikovanje i implementaciju.

U Prilozima 2.1 i 2.2 imamo najprije primjer razlike izmedu korisniˇckih zahtjeva i zahtjeva na sustav, a zatim prijedlog strukture dokumenta o zahtjevima.

2.1.4 Problemi koji se pojavljuju kod specifikacije

Kod specifikacije se mogu pojaviti sljede´ci problemi.

• Ukoliko novi sustav treba promijeniti sadaˇsnji naˇcin rada, tada ga je teˇsko definirati budu´ci da s njim joˇs nema iskustava.
• Razni korisnici imaju razliˇcite zahtjeve koji mogu biti u konfliktu. Konaˇcni zahtjevi su nuˇzno kompromis.
• Financijeri sustava i njegovi korisnici obiˇcno nisu isti ljudi. Kupac postavlja zahtjeve motivirane organizacijskim ili budˇzetskim ograniˇcenjima koja su u konfliktu s korisniˇckim zahtjevima.
• Poslovno i tehniˇcko okruˇzenje se mijenja. Time se mijenjaju i zahtjevi.

Ukoliko se zahtjevi ne mogu jasno izraziti, pribjegava se prototipiranju (vidi poglevlje 2.3).

2.2. MODELIRANJE SUSTAVA 11

2.2 Modeliranje sustava

Tijekom otkrivanja i analize zahtjeva sastavljaju se modeli postoje´ceg ili budu´ceg sustava. Ti modeli opisuju sustav na grafiˇcki naˇcin pomo´cu dijagrama. Precizniji su i jezgrovitiji od ekvivalentnog opisa pomo´cu prirodnog jezika. Joˇs uvijek su razumljivi korisnicima. Modeli takoder predstavljaju vaˇzan most izmedu specifikacije i oblikovanja.

Model uvijek daje apstraktnu (pojednostavnjenu) sliku sustava. Takoder, on promatra sustav iz neke odredene perspektive, pa istiˇce neke njegove osobine a zanemaruje druge. Najvaˇznije perspektive su:

• Kontekst. Odreduje se granica izmedu sustava i njegove okoline, te suˇcelja koja se uspostavljaju na toj granici.
• Ponaˇsanje. Promatraju se transformacije podataka, reakcije sustava na dogadaje, te promjene njegovih stanja.
• Struktura. Modelira se arhitektura samog sustava ili grada podataka koje on obraduje.

Da bi dobili cjelovitu sliku o sustavu, moramo imati nekoliko komplementarnih modela koji ga proma- traju iz razliˇcitih perspektiva. Svaka metoda razvoja softvera propisuje odredeni broj modela.

2.2.1 Model toka podataka

Model toka podataka (engleski data flow model) promatra sustav iz perspektive ponaˇsanja, te opisuje transformacije (obradu) podataka. Sustav se modelira kao skup procesa (funkcija) koje transformiraju podatke, tokova podataka izmedu tih procesa, te spremiˇsta (ili izvora ili ponora) za podatke. Na di- jagramu su procesi prikazani kao ovali, tokovi kao strelice, a spremiˇsta kao pravokutnici, u skladu sa Slikom 2.2. Modeliranje toka podataka postalo je popularno nakon pojave knjige T. de Marco: “Struc- tured Analysis and System Specification” - 1978, te je sastavni dio starijih funkcionalno-orijentiranih metoda.

Izvor 1

Proces 1

Izvor 2

Unutraˇsnje spremiˇste

• Proces 2 Ponor HH HHj 

HH

HHj tok 1 - tok 2 (^) tok 2

tok 3

tok 4

Slika 2.2: grafiˇcki prikaz modela toka podataka.

Kao primjer pogledajmo Prilog 2.3. Prikazano je kako se u nekoj organizaciji obraduje narudˇzba za opremu (na primjer raˇcunalo). Dijagrami mogu biti sloˇzeni u hijerarhiju s obzirom na razinu apstrakcije. Tako na primjer Prilog 2.4 prikazuje ve´ci postupak nabave i instaliranja opreme - mali postupak sa Priloga 2.3 ovdje je skupljen u jedan oval “Place equipment order”.

Model toka podataka moˇze sluˇziti i za prikaz sustava iz perspektive konteksta: u tu svrhu cijeli sustav prikazujemo kao jedan proces okruˇzen vanjskim izvorima i ponorima podataka. Druga mogu´cnost je da na sloˇzenijem dijagramu prikaˇzemo i sustav i njegovu okolinu, te da sam sustav uokvirimo - vidi Prilog 2.4.

Model toka podataka ne objaˇsnjava strukturu podataka u razmatranim tokovima. Takoder, on niˇsta ne govori o toku kontrole (kad se pokre´ce koji proces), ni o uˇcestalosti obrade podataka. Nije ˇcak ni jasno da li proces koji prima dva ulazna toka treba te tokove primati istovremeno, ili ih moˇze obradivati zasebno.

2.2. MODELIRANJE SUSTAVA 13

atributa (podataka) i pripadnih operacija (metoda, funkcija). Klasa je skup istovrsnih objekata. Na taj naˇcin objektni modeli kombiniraju svojstva modela toka podataka odnosno modela entiteta, veza i atributa.

Objektni modeli pojavili su se u novijim objektno-orijentiranim metodama za razvoj softvera (Booch, Rumbaugh, Jacobson, Coad & Yourdon - rane 90-te godine 20. stolje´ca). Prva trojica autora su krajem 90-tih u okviru zajedniˇcke tvrtke Rational, uskiladili svoje pristupe tako da je nastala objedin- jena metoda Rational Unified Process - RUP i standardna notacija (naˇcin crtanja dijagrama) Unified Modelling Language - UML.

Postoji nekoliko vrsta objektnih modela, koji se razlikuju po razmatranom tipu veze izmedu klasa. U nastavku ´cemo detaljnije opisati tri vrste.

Model nasljedivanja pokazuje veze nasljedivanja izmedu klasa, tj. hijerarhiju nad-klasa i pod-klasa. Naˇcin crtanja dijagrama vidi se na Slici 2.5. Nasljedivanje znaˇci da pod-klasa ima sve atribute i operacije kao njena nad-klasa, te joˇs neke svoje vlastite atribute i operacije. Dozvoljeno je i viˇsestruko nasljedivanje, ˇsto na razini specifikacije pravi manje problema nego u implemantaciji.

ime nadklase

atribut atribut...

operacija( ) operacija( )

...

ime podklase

atribut atribut...

operacija( ) operacija( )

...

A

A

Slika 2.5: grafiˇcki prikaz modela nasljedivanja.

Prilog 2.9 prikazuje hijerarhiju klasa za predmete pohranjene u knjiˇznici. Prilog 2.10 je hijerarhija klasa za korisnike knjiˇznice. Prilog 2.11 predstavlja primjer viˇsestrukog nasljedivanja.

Model agregacije pokazuje veze ukljuˇcivanja, tj. pokazuje koji jednostavniji objekti se pojavljuju kao sastavni dijelovi sloˇzenijeg objekta. Naˇcin crtanja dijagrama pokazan je na Slici 2.6. Prilog 2.12 prikazuje klasu za sloˇzeni objekt - kolegij, koji se sastoji od jednostavnijih objekata - predavaˇcevih biljeˇski, slajdova, zadataka za studente, videozapisa....

14 POGLAVLJE 2. ZAHTJEVI I SPECIFIKACIJA

klasa sloˇzenog objekta

atribut atribut...

operacija( ) operacija( )

...

klasa objekta dijela

atribut atribut...

operacija( ) operacija( )

...

Slika 2.6: grafiˇcki prikaz modela agregacije.

Model ponaˇsanja objekata pokazuje veze izmedu klasa koje se uspostavljaju time ˇsto objekti jedne klase pokre´cu operacije druge klase. Crtaju se sekvencijski dijagrami poput onog na Slici 2.7, gdje se vide mogu´ci scenariji komunikacije izmedu objekata.

n objekti iz odredenih klasa

niz operacija kojima objekti medusobno komuniciraju

Slika 2.7: grafiˇcki prikaz modela ponaˇsanja objekata.

Prilog 2.13 prikazuje scenarij, gdje korisnik najprije pristupa katalogu knjiˇznice da vidi da li je odredeni dokument dostupan u elektroniˇckom obliku, pa zatim traˇzi da mu se taj elektroniˇcki dokument dostavi preko mreˇze. Zbog zaˇstite autorskih prava, od korisnika se zahtijeva da prihvati ugovor o licenciranju. Mreˇzni posluˇzitelj na kraju ˇsalje dokument u komprimiranom obliku.