softversko inŽenjerstvo vježbe 9: uvod u oblikovanje...
Post on 21-Jan-2020
6 Views
Preview:
TRANSCRIPT
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 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.
top related