RPP 4 Flashcards
(23 cards)
1
Q
Dizajn kao glagol
A
- Dizajn je kreativna aktivnost osmišljavanja rješenja za zadani problem.
- Aktivnost donošenja dizajnerskih odluka.
- Uloga softverskog dizajna je osmisliti apstrakcije i organizirati ih na način da ispunjavaju funkcionalne i nefunkcionalne zahtjeve.
- Apstrakcija– bilo što što reprezentira koncepte iz domene problema (npr. ljudi, poslovni procesi, dokumenti, transakcije…) ili domene rješenja (komponente, slojevi, klase,…)
- Aktivnost prevođenja korisničkih zahtjeva („što”) u dizajn („kako”)
2
Q
Dizajn kao imenica
A
- Rezultat aktivnosti softverskog dizajna:
- (1) skup dizajnerskih artefakata (obično nacrti/modeli softvera),
- (2) skup donesenih dizajnerskih odluka.
- Takvi, dizajnerski artefakti su na višoj razini apstrakcije(manje detaljni) od samog programskog kôda, ali sadrže dovoljno informacija o strukturi i ponašanju budućeg softvera da bi se pristupilo fizičkoj realizaciji (programiranju).
3
Q
Što je dizajn
A
skup dizajnerskih odluka (engl. design decisions) od kojih
svaka ima za cilj riješiti potproblem odabirom jednog od više
alternativnih rješenja.
4
Q
Procesi donošenja odluke su koji 2 i objasni ih
A
- Diversifikacija– proces generiranja dizajnerskih alternativa (u skladu sa definiranim zahtjevima)
- Konvergencija– proces evaluacije i odbijanja generiranih alternativa koje ne
ispunjavaju nefunkcionalne zahtjeve (npr. radi, ali presporo, nesigurno, nepouzdano…).
5
Q
Objasni vodopadni model
A
- Svaka aktivnost se provodi samo jedanput (u idealnom
slučaju) - Svaka aktivnost kreira softverske artefakte koji su ulaz u
sljedeću aktivnost - Po završetku aktivnosti dizajna kreira se cjelokupan softverski dizajn (cijeli SDS dokument)
6
Q
Objasni inkrementalni model
A
- Svaka aktivnost kreira softverske artefakte koji su ulaz u sljedeću aktivnost
- Svaka aktivnost se provodi više puta (u svakoj iteraciji)
- Po završetku aktivnosti dizajna kreira se samo dizajn relevantan za tekuću iteraciju.
7
Q
Zašto je tesko dizajnirati softver
A
- Softverski dizajn je proces rješavanja
problema (engl. problem-solving process), - Nema unaprijed definiranog skupa koraka koji garantira uspjeh i kvalitetu.
- Ne znamo sve moguće dizajnerske alternative.
- Teško je precizno procijeniti pozitivan i
negativan utjecaj dizajnerske odluke. - Dizajnerske odluke mogu biti međusobno u konfliktu.
- Nužni su kompromisi (engl. trade-offs)
- Ne postoji jedan „ispravan” ili optimalan dizajn, nego cijeli prostor dizajnerskih rješenja
8
Q
Dizajnersko znanje i iskustvo, koje nadilazi kontekst pojedinačnog softverskog rješenja, je obično dokumentirano kao
A
- Uzorci dizajna (engl. Design patterns) – apstraktna, ponavljajuća rješenja za česte dizajnerske probleme (npr. Observer, Strategy, Abstract Factory)
- Anti-uzorci (engl. Anti patterns, code smells) – česte, ponavljajuće pogreške u
dizajnu (npr. Duplicated code, Long method, Long class, itd.) - Principi dizajna (engl. design principles) – skup pravila i smjernica koje pomažu
programerima da kreiraju dobar dizajn (SOLID, GRASP, DRY, SOC, KISS, YAGNI,
refaktoriranje…). - Arhitekturalni stilovi– Čest skup dizajnerskih odluka koje su primjenjive na neki kontekst, neovisno o domeni (npr. mikroservisna arhitektura, cjevovodi i filteri, slojevita arhitektura, klijent-server arhitektura i sl.)
- Referentne arhitekture – Čest skup dizajnerskih odluka koje su primjenjive na neki kontekst unutar neke domene (referentne arhitekture za IoT sustave, Big data sustave, SmartCity sustave, e-commerce sustave i sl.)
9
Q
Što je modeliranje u procesu dizajna
A
Modeliranje je proces izrade apstraktnih modela sustava (originala), pri čemu svaki model predstavlja različiti pogled/perspektivu na sustav.
10
Q
Nabroji 3 kriterija modela
A
- Kriterij mapiranja – postoji „original” koji je mapiran na model.
- Kriterij redukcije – nisu sve (ali neke obavezno jesu) karakteristike originala
mapirane na model. Model je redukcija (apstrakcija) originala. - Kriterij pragmatičnosti – model može zamijeniti original u nekom kontekstu, tj.
model je koristan.
11
Q
Nabroji 4/10 principa modeliranja
A
- Princip 2: Ne kreirajte više modela nego što je potrebno.
- Princip 4: Izgradite modele koje će biti moguće izmijeniti.
- Princip 7: Težite izgradnji korisnih modela a ne savršenih modela.
- Princip 6: Prilagodite modele samom sustavu koji izgrađujete.
- Princip 1.: primarni cilj je izgraditi funkcionirajući softver a ne kreirati modele.
- Princip 3: Težite izradi najjednostavnijeg modela koji će dovoljno dobro opisati problem ili rješenje.
- Princip 5: Budite u stanju navesti svrhu svakog od izrađenih modela.
- Princip 8: Ne držite se sintakse modela kao dogme. Ukoliko model uspješno komunicira sadržaj, sama reprezentacija je sekundarna.
- Princip 9: Slušajte svoje instinkte ako vam govore da model nije dobar (napravite dodatnu analizu modela).
- Princip 10: Zatraži (i dobij) povratnu informaciju za izrađeni model čim prije moguće.
12
Q
Objasni top down dizajn
A
- Temelji se na funkcionalnoj dekompoziciji.
- Svaki od novonastalih dizajnerskih elemenata se može dalje dekomponirati na manje dijelove (komponente, klase,…).
- Dekompozicija se nastavlja dok dizajnerski elementi nisu dovoljno mali i detaljno opisani da se mogu razumjeti i ispravno implementirati.
- Čest u tradicionalnim pristupima razvoju (npr. vodopadni model)
13
Q
Top down dizajn PREDNOSTI i NEDOSTACI
A
- Prednosti:
- Prirodan način razmišljanja, vrlo čest (nacrti kuće, nacrti strojeva, opisi
procesa…) - Efikasan pristup postepenog sučeljavanja s kompleksnošću,
- Osmišljavanje arhitekture u ranoj fazi,
- Lakše planiranje resursa i podjele zaduženja,
- Jednostavna nadogradnja i održavanje softvera.
- Nedostaci:
- Donosimo važne odluke vrlo rano, kada imamo ograničeno znanje i informacije.
- Takve odluke mogu nepovoljno utjecati na odluke niže razine.
- Naknadne promjene u arhitekturi uzrokuju kaskadni efekt na cijeli sustav.
- Odgođena implementacija i testiranje
- Teško je procijeniti kada treba stati sa dekompozicijom
- Dekompozicija može rezultirati dupliciranjem elemenata dizajna u
različitim dijelovima sustava.
14
Q
Objasni bottom up dizajn
A
- Temelji se na kompoziciji.
- Započinje definiranjem osnovnih elemenata koji se zatim kombiniraju
i organiziraju u logički smislene komponente. - Nastale komponente se zatim kombiniraju kako bismo sastavili
module ili podsustave. - Proces kompozicije se nastavlja dok ne dobijemo cjelovito softversko
rješenje (sustav). - Čest u iterativnim i agilnim pristupima razvoju softvera
15
Q
Bottom up PREDNOSTI i NEDOSTACI
A
- Prednosti:
- Potiče inkrementalni razvoj i prototipiranje,
- Omogućava da vrlo rano započnemo sa programiranjem osnovnih
elemenata (podatkovnih struktura, metoda, klasa…). - Može biti korisno odgoditi dizajnerske odluke do trenutka kada ih zaista
moramo donijeti (veća je šansa da ćemo tada imati dovoljno informacija), - Jednostavnije testiranje,
- Potiče izradu samostalnih i ponovno iskoristivih komponenata.
- Nedostaci:
- Zahtjevan proces integracije,
- Nedostatak šire slike i opće arhitekture sustava, zahtijeva dosta
refaktoriranja, - Kasna detekcija arhitekturalnih problema,
- Teško je procijeniti napredak,.
- Veliki skok u razini apstrakcije sa softverskih zahtjeva na dizajn niže
razine i programiranje.
16
Q
objasni procesno orijentirani dizajn
A
- Fokusira se na procese unutar organizacije koje je potrebno automatizirati.
- Koristan je za organizacije koje imaju strogo i jasno definirane procese.
- Započinje identificiranjem ključnih procesa, slučajeva korištenja, radnih tokova,…
- Kreirani modeli specificiraju koje korake je potrebno provesti, kojim
redoslijedom, na koji način (slijedno ili istovremeno), od koga, i sl. - Podatke promatramo isključivo u kontekstu procesa, kao resurse koji
se međusobno razmjenjuju (u jednom procesu se kreiraju, u drugom
koriste). - Ne odgovara na pitanje kako su podaci međusobno povezani.
17
Q
Podatkovno-orijentirani dizajn
A
- Fokusira se organiziranje, pohranu i manipuliranje podacima na
automatiziran način. - Započinje definiranjem podatkovnog modela, potrebnih struktura
podataka, te njihove međusobne povezanosti - Tek onda se počinje govoriti o procesnim elementima koji bi trebali
kreirati i koristiti te podatke – na stabilni podatkovni model dodajemo
sloj poslovne logike.
18
Q
Objektno-orijentirani dizajn
A
- Jednaku pažnju posvećuje i procesima i podacima,
- Podaci i procesi koji rade s tim podacima se učahuruju unutar jednog
elementa – klase. - Može zahtijevati mnogo vremena da bi se savladao.
19
Q
Objasni što je Kohezija
A
- Kohezija – mjera koja pokazuje koliko su elementi nekog modula zaista srodni i čine smislenu cjelinu.
- Softverskim dizajnom pokušavamo postići visoku razinu kohezije u modulima softvera.
- Visoko kohezivni moduli su pouzdaniji, razumljiviji, te ih je lakše ponovno iskoristiti.
20
Q
Objasni povezanost
A
- Povezanost – mjera koja pokazuje koliko su klase (a također i
komponente i moduli) ovisne jedne o drugima - Softverskim dizajnom pokušavamo postići labavu povezanost (engl.
loose coupling) između elemenata softvera… - Labava povezanost čini sustav lakšim za testiranje i mijenjanje.
21
Q
Tko provodi softverski dizajn?
A
- Arhitekt softvera (engl.
software architect) - Dizajner softvera (engl.
software designer) - Programer (engl. software
developer)
22
Q
Tri zlatna pravila (engl. golden rules) za postizanje pozitivnog korisničkog iskustva:
A
- Pravilo: Stavite korisnika u kontrolu
- Pravilo: Smanjite kognitivno opterećenje korisnika
- Pravilo: Budite konzistentni kod definiranja sučelja
- Pravilo: Stavite korisnika u kontrolu
* Ne prisiljavajte korisnika na neželjene/nepotrebne korake
* Neka interakcija sa softverom bude fleksibilna
* Omogućite korisniku da prekine interakciju ili ju poništi (undo).
* Omogućite naprednim korisnicima da prilagode i automatiziraju interakciju (macros).
* Sakrijte tehničke detalje od korisnika (operacijski sustav, bazu podataka .
* Omogućite izravnu interakciju s objektima na ekranu (npr. Drag and-drop).
- Pravilo: Smanjite kognitivno opterećenje korisnika
- Ne zahtijevajte od korisnika da pamti prethodne akcije, unose ili
rezultate. - Popunite polja za unos sa smislenim defaultnim vrijednostima.
- Napravite podršku za korištenje tipkovničkih kratica.
- Izgled softvera bi trebao biti temeljen na metafori iz stvarnog svijeta
- Pravilo: Budite konzistentni kod definiranja sučelja
- Sve vizualne elemente organizirajte u skladu s pravilima koje ste unaprijed definirali.
- Načini unosa podataka i kontrole koje se za to koriste se trebaju jednako koristiti kroz cijeli softver.
- Navigacija također treba biti konzistentno primjenjena kroz cijelu aplikaciju.
23
Q
Principi za postizanje bolje upotrebljivosti UX
A
Predviđanje
Komunikacija
Konzistentnost
Kontrola pristupa
Efikasnost
Fleksibilnost
Lakoća učenja
Vrijeme odaziva
Rukoavnje greskama
Lokalizacija
