SOFTVERSKO INŽENJERSTVO

Vježbe 9: Uvod u oblikovanje,klase na razini oblikovanja

Robert Manger

Sveučilište u Zagrebu

PMF-Matematički odsjek

Akademska godina 2019/2020.

V-09 Softversko inženjerstvo 2

Sadržaj Vježbi 9

Općenito o oblikovanju

Odnos analize i oblikovanja

Održavanje modela iz analize i oblikovanja

Općenito o klasama na razini oblikovanja

Svojstva dobro oblikovanih klasa

Nasljeđivanje kao mehanizam oblikovanja

Oblikovanje obrazaca (template)

V-09 Softversko inženjerstvo 3

Općenito o oblikovanju Oblikovanje je temeljna aktivnost unutar UP koja

prevladava u zadnjem dijelu faze Elaboration i početnoj

polovici faze Construction.

Oblikovanje treba odrediti način kako da se implementira

funkcionalnost koja je opisana modelom iz analize.

Glavni rezultati oblikovanja su: podjela sustava na podsustave,

specifikacija klasa na razini oblikovanja i veza među njima,

specifikacija sučelja između podsustava,

realizacija use case-ova na razini oblikovanja.

Daljnji rezultati oblikovanja su: specifikacija komponenti,

modeliranje promjene stanja složenijih objekata,

početni prijedlog rasporeda dijelova sustava po računalima.

V-04 Softversko inženjerstvo 4

Odnos analize i oblikovanja UP ne postavlja jasnu granicu između analize i oblikovanja.

Teško je odrediti gdje prestaje analiza a počinje oblikovanje.

Sličnosti između analize i oblikovanja.

Obje aktivnosti bave se modeliranjem.

Obje aktivnosti služe se istim vrstama UML dijagrama.

Model stvoren u analizi dalje se profinjuje tijekom oblikovanja.

Razlike između analize i oblikovanja.

Model na razini analize je jednostavan i daje globalnu sliku sustava.

Model na razini oblikovanja je znatno kompliciraniji jer sadrži sve

detalje koji su potrebni za implementaciju.

Model na razini analize prikazuje sam problem (poslovni sustav) u

terminima dotične poslovne domene. Razumljiv je korisnicima.

Model na razini oblikovanja prikazuje rješenje problema (softverski

sustav) i služi se informatičkim pojmovima. Namijenjen je softverskim

inženjerima.

V-09 Softversko inženjerstvo 5

Veza između modela dobivenih analizom odnosno oblikovanjem

Veza je ilustrirana

sljedećim dijagramom.

Prikazana je kao

ovisnost sa

stereotipom <<trace>>.

Dakle model iz

oblikovanja može se

smatrati profinjenjem

modela iz analize.

V-09 Softversko inženjerstvo 6

Veza između rezultata analize odnosno oblikovanja Veza je ilustrirana

sljedećim

dijagramom. Opet je

riječ o ovisnostima

sa stereotipom

<<trace>>. Podsustavi

vuku porijeklo od

paketa, a klase na

razini oblikovanja

zajedno sa

sučeljima nastaju od

klasa na razini

analize.

V-09 Softversko inženjerstvo 7

Održavanje modela dobivenih analizom odnosno oblikovanjem (1) U idealnim uvjetima bilo bi dovoljno održavati samo jedan

model sustava. Alat za modeliranje trebao bi iz tog istog

modela proizvoditi pogled na razini analize ili oblikovanja.

Ipak, današnji UML alati to nisu u stanju korektno

napraviti. Zato se postavlja pitanje kako da održavamo

modele dobivene analizom odnosno oblikovanjem.

Moguće su četiri strategije koje su prikazane sljedećom

tablicom. Koja je strategija najbolja ovisi o vrsti projekta.

Kod malih projekata nije potrebno čuvati model iz analize, pa su

pogodne strategije 1 i 2.

Kod velikih i dugo živućih projekata treba ipak sačuvati pogled iz

analize, pa su pogodne strategije 3 i 4.

V-09 Softversko inženjerstvo 8

Održavanje modela dobivenih analizom odnosno oblikovanjem (2)Red

broj

Opis strategije Posljedice

1 Uzmi model iz analize i profinjavanjem

ga pretvori u model iz oblikovanja.

Imamo jedan model na razini

oblikovanja, no izgubili smo

model iz analize.

2 Uzmi model iz analize, profinjavanjem

ga pretvori u model iz oblikovanja,

korištenjem alata za modeliranje

reproduciraj unatrag pogled iz analize.

Imamo jedan model na razini

oblikovanja, no pogled dobiven

reprodukcijom unatraške

možda nije sasvim točan.

3 Zamrzni model iz analize, profinjavaj

kopiju tog modela da bi dobio model na

razini oblikovanja.

Imamo dva modela, no oni nisu

sasvim konzistentni.

4 Održavaj paralelno dva modela – jedan

na razini analize a drugi na razini

oblikovanja.

Imamo dva modela, oni jesu

konzistentni, no pojavio se

dodatni teret održavanja.

V-09 Softversko inženjerstvo 9

Općenito o klasama na razini oblikovanja (1) To su takve klase čije specifikacije su dovoljno detaljne

da se one mogu implementirati u programskom jeziku.

Dakle, to su klase čije specifikacije sadrže sljedeće.

Cjelovit popis atributa.

Za svaki atribut zadano je ime, tip, default-vrijednost, vidljivost.

Cjelovit popis operacija.

Za svaku operaciju zadano je ime, broj i tipovi parametara, tip

povratne vrijednosti, vidljivost.

Sljedeći dijagram prikazuje klasu BankAccount na razini

analize odnosno oblikovanja. Vidimo u kojoj mjeri

specifikacija na razini oblikovanja mora biti detaljnija.

V-09 Softversko inženjerstvo 10

Općenito o klasama na razini oblikovanja (2)

V-09 Softversko inženjerstvo 11

Nastanak klasa na razini oblikovanja (1)

Klase na razini oblikovanja dobivaju se iz dva izvora.

Iz problemske odnosno poslovne domene (problem domain).

Gledamo klase na razini analize koje ustvari opisuju problem,

profinjavamo ih, te tako dobivamo jednu ili više klasa na razini

oblikovanja.

Iz softverske domene (solution domain).

Proučavamo raspoložive softverske alate, biblioteke, GUI

okoline, komponente za ponovnu upotrebu, middleware, baze

podataka. Uočavamo dodatne klase koje su nam potrebne za

implementaciju.

V-09 Softversko inženjerstvo 12

Nastanak klasa na razini oblikovanja (2) Nastanak iz dva izvora ilustriran je sljedećom slikom.

V-04 Softversko inženjerstvo 13

Svojstva dobro oblikovanih klasa (1)

Klasa se smatra dobro oblikovanom ako ona ima

sljedeća svojstva.

Potpunost.

Klasa nudi sve one usluge koje se od nje očekuju. Na primjer, od

klase BankAccount koja nudi operaciju withdraw() očekuje se da

ponudi i operaciju deposit(). Također, za svaki javno vidljivi atribut

postoji barem funkcija za vraćanje vrijednosti tog atributa.

Dovoljnost.

Klasa ne nudi ništa više od onoga što se od nje očekuje. Na

primjer, klasa BankAccount ne bi trebala sadržavati operacije za

obradu kreditnih kartica ili operacije za prikaz dnevne tečajne

liste .

V-04 Softversko inženjerstvo 14

Svojstva dobro oblikovanih klasa (2) Primitivnost.

Usluge koje klasa nudi su jednostavne, atomarne i

neredundantne. Na primjer, ako klasa BankAccount ima

operaciju za stavljanje jednog iznosa na račun, ona ne bi

trebala imati operaciju za stavljanje dva ili više iznosa. Naime

takva složenija operacija mogla bi se realizirati višestrukom

primjenom jednostavnije operacije.

Jaka kohezija (prema unutra).

Klasa utjelovljuje jedan jasno definirani pojam, atributi i

operacije su čvrsto povezani i potrebni jedni drugima. Bilo koji

pokušaj razgradnje klase na dvije uzrokovao bi pojavu velikog

broja veza između tih novonastalih klasa.

Slaba povezanost (prema van).

Broj veza prema drugim klasama je što manji i svodi se samo

na one koje su nužne za obavljanje operacija.

V-04 Softversko inženjerstvo 15

Nasljeđivanje kao mehanizam oblikovanja (1) Nasljeđivanje smo spominjali već u analizi. No riječ je o

mehanizmu koji se još više koristi u oblikovanju.

Odluka da će neka klasa biti pod-klasa druge klase bitno

određuje način kako će ta prva klasa biti implementirana.

Dizajneri vole koristiti nasljeđivanje jer se njime postiže

ponovna upotreba već postojećeg programskog koda, te

značajna ušteda u programiranju.

U doba nastanka objektno-orijentiranog pristupa (80-te,

90-te) nasljeđivanju se davala mnogo veća važnost nego

što se daje danas. Vjerovalo se da će postojati biblioteke klasa opće namjene.

Očekivalo se da će se novi sustavi moći stvoriti nasljeđivanjem

općenitih klasa uz vrlo malo dodatnog programiranja.

V-04 Softversko inženjerstvo 16

Nasljeđivanje kao mehanizam oblikovanja (2) Danas prevladava realniji stav. Spoznalo se da

nasljeđivanje osim dobrih strana ima i ozbiljnih mana. To je najjači mogući oblik povezanosti (coupling) između klasa.

Znamo da je povezanost klasa nepoželjna pojava.

To je način za slabljenje učahurenosti (encapsulation) klase.

Promjene u nad-klasi imaju neposredni utjecaj na pod-klasu.

To je vrlo nefleksibilan oblik veze među klasama, koji se ne

može se mijenjati za vrijeme izvršavanja programa.

Dakle, s upotrebom nasljeđivanja ne treba pretjerivati. Nasljeđivanje je opravdano onda kad imamo istinski odnos pod-

klase i nad-klase, u smislu da je svaki objekt pod-klase zaista i

objekt nad-klase.

Nasljeđivanje se ne bi smjelo koristiti ako objekt potencijalne

pod-klase samo privremeno igra ulogu objekta iz nad-klase.

V-04 Softversko inženjerstvo 17

Primjer pogrešne upotrebe naslj (1) Sljedeći dijagram prikazuje hijerarhiju klasa kojom se

pokušavaju modelirati uloge zaposlenika. Postoji klasa

zaposlenika i dvije pod-klase za menadžere i

programere. Instanciran je objekt john tipa Programmer.

Zamislimo sada da je john

unaprijeđen u menadžera.

Tada bi u runtime-u objekt

john trebao prijeći u drugu

klasu, što je nemoguće.

Jedino što bi mogli

napraviti je da pobrišemo

postojeći objekt i stvorimo

novi, a to je prilično

neprirodan zahvat.

V-04 Softversko inženjerstvo 18

Upotreba

nasljeđivanja

zapravo je bila

pogrešna, jer

je priroda

samog

objekta bila

pomiješana s

ulogom koju

taj objekt

trenutno igra.

Bolje rješenje

vidi se na

sljedećem

dijagramu.

Primjer pogrešne upotrebe naslj (2)

V-04 Softversko inženjerstvo 19

Primjer pogrešne upotrebe naslj (3)

Sad se služimo agregacijom između klase Employee i

klase Job.

Objekt john se instancira kao zaposlenik iz klase

Employee, a radna mjesta menadžera i programera se

instanciraju kao objekti iz odgovarajućih pod-klasa

klase Job.

Uspostavlja se poveznica između objekta john i objekta

:Programmer, što znači da john trenutno obavlja posao

programera.

Johnovo unapređenje u menadžera lako se realizira u

runtime-u preusmjeravanjem poveznice, tako da ona

poveže objekt john s objektom :Manager.

V-04 Softversko inženjerstvo 20

Potreba za obrascima Rekli smo da klase na razini oblikovanja moraju biti

definirane do najsitnijih detalja. Ponekad to može ograničiti

mogućnosti ponovne upotrebe programskog koda.

Sljedeća slika prikazuje tri klase. Svaka od njih predstavlja

polje zadane duljine, no s različitim tipom elemenata. Očito je da se ove klase samo nebitno razlikuju i da implementacije

pojedinih operacija mogu u osnovi izgledati isto.

Ipak, unatoč sličnosti riječ je o različitim klasama.

V-04 Softversko inženjerstvo 21

Oblikovanje obrazaca (1) Jedan način da se iskoristi sličnost prethodnih klasa i ostvari

ušteda u programiranju je dizanje oblikovanja na višu razinu. Umjesto klasa oblikovat ćemo obrazac (template) za klasu.

Taj obrazac imat će parametre koji odgovaraju duljini polja i tipu

elemenata u polju.

Pojedina klasa dobit će se instanciranjem iz obrasca, navođenjem

konkretnih vrijednosti za parametre.

Operacija instanciranja klase iz obrasca obično se zove binding i

prikazuje se na dijagramu kao ovisnost sa stereotipom <<bind>>.

Primijetimo da generiranje objekata na osnovi obrasca

zahtijeva dvostruku instancijaciju: Najprije se iz obrasca instancira klasa,

Zatim se iz klase instancira objekt.

Obrasce ima smisla koristiti jedino ako programski jezik koji

je odabran za implementaciju podržava taj mehanizam. Java i C++ podržavaju; Python, Visual Basic i C# ne podržavaju.

V-04 Softversko inženjerstvo 22

Oblikovanje obrazaca (2) Sljedeća slika prikazuje obrazac za polje, te dvije klase koje

se dobivaju instanciranjem iz obrasca. Prva klasa predstavlja cjelobrojno polje duljine 100.

Druga klasa predstavlja polje s defaultnom duljinom 10 čiji elementi

su stringovi.