1. Oblikovanje programske potpore
Arhitektura programske potpore, stilovi i modeli

2. Oblikovanje programske potpore
Generičke aktivnosti u procesu programskog inženjerstva:
Specifikacija (temeljem analize zahtjeva)
Oblikovanje i implementacija – uključuje izbor i dokumentiranje arhitekture programske potpore
Validacija i verifikacija
Evolucija

3. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Teme ove prezentacije
Uvesti pojmove arhitekture programske potpore.
Objasniti proces donošenja odluka u izboru i oblikovanju arhitekture programske potpore.
Definirati kriterije za izbor arhitekture.
Definirati strukturu i sadržaj dokumenata oblikovanja.
To je proces identificiranja podsustava koji čine cjelinu te okruženja za upravljanje i komunikaciju između podsustava.
Rezultat procesa oblikovanja je opis (dokumentiranje) arhitekture programske potpore.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

4. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Literatura
Izvori:
R&D laboratorij
Carnegie Mellon University, Pittsburgh, PA, USA
Utemeljen 1984
zapošljava >300 ljudi (Pittsburgh, Pennsylvania, Arlington, Virginia, i Frankfurt)
Mary Shaw and Paul Clements: The golden age of software architecture, IEEE Software, vol 23, no 2, March/April 2006.
Timothy C. Lethbridge and Robert Laganière, Object-Oriented Software Engineering: Practical Software Development using UML and Java, Second Edition, McGraw Hill, 2001
Ian Sommerville, Software Engineering, 8th, ed.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

5. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Teme ove prezentacije
Uvesti pojmove arhitekture programske potpore.
Objasniti proces donošenja odluka u izboru i oblikovanju arhitekture programske potpore.
Definirati kriterije za izbor arhitekture.
Definirati strukturu i sadržaj dokumenata oblikovanja.
To je proces identificiranja podsustava koji čine cjelinu te okruženja za upravljanje i komunikaciju između podsustava.
Rezultat procesa oblikovanja je opis (dokumentiranje) arhitekture programske potpore.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

6. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Od zahtjeva do koda
Veliki raskorak između problema i rješenja
Zahtjevi ??
Implementacija(e)
To je proces identificiranja podsustava koji čine cjelinu te okruženja za upravljanje i komunikaciju između podsustava.
Rezultat procesa oblikovanja je opis (dokumentiranje) arhitekture programske potpore.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

7. Uloga arhitekture prog. podrške
Dio strukturiranog procesa programskog inženjerstva.
Daje apstrakciju sustava na visokoj razini.
Komponente, konektori, ..
Osnovni je nositelj kvalitete sustava.
Kapitalna investicija koja se može ponovno koristiti.
Osnovica za komunikaciju između dionika.
Nužna za implementaciju.
Zahtjevi
arhitektura prog. podrške ??
Implementacije
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

8. Od programiranja do arhitekture
1950 – programiranje na bilo koji način
1960 – potprogrami i posebno prevođenje dijelova (engl. programming in the small).
1970 – apstraktni tipovi podataka, objekti, skrivanje informacije (engl. programming in the large).
1980 – razvojne okoline, cjevovodi i filtri (UNIX)
1990 – objektno usmjereni obrasci (engl. patterns), integrirana razvojna okruženja.
2000 – arhitektura programske potpore, jezici za oblikovanje (npr. UML) i metode oblikovanja (npr. modelno oblikovanje arhitekture – engl. model driven architecture MDA).
- oblikovanje stabilne arhitekture (nove značajke mogu jednostavno dodavati uz vrlo male izmjene).Time se osigurava veća pouzdanost i mogućnost jednostavnog održavanja sustava
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

9. Aktivnost oblikovanja arhitekture progr. potpore
To je proces identificiranja i strukturiranja podsustava koji čine cjelinu te okruženja za upravljanje i komunikaciju između tih podsustava.
Rezultat procesa oblikovanja je opis (dokumentacija) arhitekture programske potpore.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

10. Prednosti definiranja arhitekture
Smanjuje cijenu oblikovanja, razvoja i održavanja programskog produkta.
Omogućuje ponovnu uporabu rješenja (engl. re-use).
Poboljšava razumljivost.
Poboljšava kvalitetu produkta.
Razjašnjava zahtjeve.
Omogućuje donošenje temeljnih inženjerskih odluka.
Omogućuje ranu analizu i uočavanje pogrešaka u oblikovanju.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

11. Definicija arhitekture
“as the size and complexity of software systems increases, the design problem goes beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a new kind of problem. This is the software architecture level of design.”
Garlan, 1992
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software components the externally visible properties of those components, and the relationships among them.”
Bass, Clements, and Kazman. Software Architecture in Practice, Addison-Wesley 1997
The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
The IEEE Standard for Architectural Description of Software-Intensive Systems (IEEE P1471/D5.3)
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

12. Definicija arhitekture
Arhitektura programske potpore je struktura ili strukture sustava koji sadrži elemente, njihova izvana vidljiva obilježja i odnose između njih.
Opis arhitekture programske potpore je skup dokumentiranih pogleda raznih dionika.
Pogled predstavlja djelomično obilježje razmatrane arhitekture programa i dokumentiran je dijagramom (nacrtom) koji sadrži:
Elemente: dijelovi sustava
Odnose između elemenata : topologija
Vanjska vidljiva obilježja
Veličina, performanse, sigurnost, API
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

13. Opis arhitekture modelima
Više pogleda u okviru nekog konteksta predstavljaju model arhitekture programske potpore, npr.:
Dinamički procesni model
komponente u izvođenju (engl. runtime)
Alocirane elemente (npr. datoteke). …
Statičan strukturni model - Moduli
pokazuju kompoziciju/dekompoziciju sustava
Arhitektura programske potpore opisuje se modelima koji svaki sadrži jedan ili više pogleda (dijagrama).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

14. Klasifikacija arhitekture po dosegu
Koncepcijska - engl. Conceptual Architecture
Usmjeravanje pažnje na pogodnu dekompoziciju sustava.
Komunikacija s netehničkim dionicima (uprava, prodaja, korisnici).
Neformalna specifikacija komponenti (npr. CRC-R cards)
Logička - engl. Logical Architecture
Precizno dopunjena.
Detaljan nacrt pogodan za razvoj komponenti.
Architecture Diagram (with interfaces), Component and Interface Specifications, Component Collaboration Diagrams, potrebna objašnjenja diskusije ....
Izvršna - engl. Execution Architecture
Namijenjena distribuiranim i paralelnim sustavima.
Pridruživanje procesa fizičkom sustavu.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

15. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Teme ove prezentacije
Uvesti pojmove arhitekture programske potpore.
Objasniti proces donošenja odluka u izboru i oblikovanju arhitekture programske potpore.
Definirati kriterije za izbor arhitekture.
Definirati strukturu i sadržaj dokumenata oblikovanja.
To je proces identificiranja podsustava koji čine cjelinu te okruženja za upravljanje i komunikaciju između podsustava.
Rezultat procesa oblikovanja je opis (dokumentiranje) arhitekture programske potpore.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

16. Proces izbora i evaluacije arhitekture = proces donošenja odluka
Alternativni stilovi arhitekture programske potpore
 Oblikovanje kao niz odluka.
Dizajner se sučeljava s rješavanjem niza problema (engl. design issues)
To su podproblemi ukupnog problema.
Postoji nekoliko inačica rješenja.
engl. design options
Dizajner donosi odluke (engl. design decision) za rješavanje problema.
Odabir najbolje opcije između više mogućnosti rješenja problema.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

17. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Prostor oblikovanja
Prostor oblikovanja je skup opcija koja su na raspolaganju uporabom različitih izbora (engl. design space ). Npr. uslužni sustav:
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

18. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Donošenje odluka
Za donošenje odluka potrebna znanja:
Zahtjeva sustava
Trenutno oblikovana arhitektura
Raspoloživa tehnologija
Principi oblikovanja i najbolja praksa (engl. best practices)
Dobra rješenja iz prošlosti
Zadaće donošenja odluka:
Postavljanje prioriteta sustava
Dekompozicija sustava
Definiranje svojstva sustava
Postavljanje sustava u kontekst
Integritet sustava
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

19. Princip oblikovanja: “od vrha prema dolje”
Engl. Top-down design
Oblikuj najvišu strukturu sustava
Postepeno razrađuj detalje
Na kraju detaljne odluke kao npr.:
Strukture podataka
Uporaba/izbor algoritama
odozgo prema dolje
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

20. Princip oblikovanja: “od dna prema vrhu”
Bottom-up design
Donošenje odluka o komponentama za ponovnu uporabu
Odluke o njihovoj uporabi za stvaranje (kompoziciju) komponenti više razine
Hibridno oblikovanje
Uporaba obje metode:
Top-down design
Daje dobru struktura sustava
Stvara komponente pogodne za ponovnu uporabu
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

21. OBLIKOVANJE PROGRAMSKOG PRODUKTA
Podaktivnosti u oblikovanju
Specifikacija zahtjeva
Oblikovanje sučelja
Oblikovanje komponenata
Oblikovanje struktura podataka
Oblikovanje algoritama
Izbor i oblikovanje arhitekture
Apstraktna specifikacija
Specifikacija sučelja
Arhitektura sustava
Specifikacija programa
Specifikacija algoritama
Specifikacija struktura podataka
Specifikacija komponenata
Produkti oblikovanja
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

22. Oblikovanje nije samo arhitektura
Oblikovanje arhitekture
Podjela u podsustave i komponente
Način povezivanja?
Način međudjelovanja?
Sučelja komponenata?
Oblikovanje korisničkog sučelja
Oblikovanje struktura podataka
Oblikovanje algoritma
Za izračunavanje, upravljanje ..
Oblikovanje protokola
Komunikacijski protokoli
ne u ovom kolegiju
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

23. Preporučeni postupak razvoja modela arhitekture
Započni s grubom skicom arhitekture zasnovanoj na osnovnim zahtjevima i obrascima uporabe.
Odredi temeljne potrebne dijelove sustava.
Izaberi između raznih stilova arhitekture
Savjet: nekoliko timova nezavisno radi grubu skicu arhitekture, a potom se spoje najbolje ideje.
Arhitekturu dopuni detaljima tako da se:
identificiraju osnovni načini komunikacije i interakcije između komponenata.
odredi kako će dijelovi podataka i funkcionalnosti raspodijeliti između komponenata.
pokušaj identificirati dijelove za ponovnu uporabu (engl. reuse).
vrati se na pojedini obrazac uporabe i podesi arhitekturu.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

24. Tehnika donošena dobrih odluka oblikovanja
uporaba prioriteta i ciljeva za odabir alternativa
Pobroji i opiši opcije (alternative) odluka oblikovanja.
Pobroji prednosti i nedostatke svake opcije u odnosu na prioritete i ciljeve.
Odredi opcije koje su u sukobu s ciljevima.
Odaberi opciju koja najbolje zadovoljavaju ciljeve.
Prilagodi prioritete za daljine donošenje odluka.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

25. Primjer kriterija za oblikovanje računalnog sustava
(to nisu ciljevi i prioriteti u oblikovanju arhitekture programske potpore)
Sigurnost/Security: Podaci se ne smiju moći dešifrirati poznatim tehnikama za < 100sati na 1GHz Intel procesoru.
Održavanje/Maintainability: Nema
Performanse/CPU efficiency: Odziv < 1s na 1GHz Intel procesoru.
Mrežno opterećenje/Network bandwidth efficiency:  8KB po transakciji.
Memorijski resursi/Memory efficiency: 200MB RAM.
Prenosivost/Portability: Windows XP, Linux
Nešto analogno navedenim prioritetima i ciljevima trebalo bi definirati za postupak izbora najpogodnije arhitekture programske potpore.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

26. Primjer odabira algoritama
kriteriji
opcije
Nešto analogno navedenim prioritetima i ciljevima trebalo bi definirati za postupak izbora najpogodnije arhitekture
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

27. Dodatni kriteriji za odabir najpovoljnije opcije
(engl. “cost-benefit” analiza)
Procjena CIJENE/troškova sumira:
Cijenu rada programskog inženjera, uključujući održavanje.
Cijenu uporabe razvojne tehnologije.
Cijenu koja tereti krajnje korisnike (uključivo i evoluciju produkta).
Procjena KORISTI/dobiti sumira:
Uštedu vremena programskog inženjera.
Dobrobiti mjerene kroz povećanu prodaju ili ostale financijske uštede.
odluku između pojedinih opcija arhitektura.
Za izračun cijene zbroji:
Inkrementalnu cijenu rada u programskom inženjerstvu, uključujući održavanje.
Inkrementalnu cijenu tehnologije za postupak oblikovanja.
Inkrementalnu cijenu koju će morati platiti krajnji korisnik i osoblje za održavanje tijekom uporabe programskog produkta.
Za izračun koristi zbroji:
Inkrementalno smanjeno vrijeme programskih inženjera tijekom oblikovanja.
Inkrementalna novčana korist od povećanje prodaje ili financijska korist korisnika.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

28. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Teme ove prezentacije
Uvesti pojmove arhitekture programske potpore.
Objasniti proces donošenja odluka u izboru i oblikovanju arhitekture programske potpore.
Definirati kriterije za izbor arhitekture.
Definirati strukturu i sadržaj dokumenata oblikovanja.
To je proces identificiranja podsustava koji čine cjelinu te okruženja za upravljanje i komunikaciju između podsustava.
Rezultat procesa oblikovanja je opis (dokumentiranje) arhitekture programske potpore.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

29. Principi oblikovanja i kriteriji izbora arhitekture
Podijeli i vladaj - Divide and conquer
Povećaj koheziju - Increase cohesion
Smanji međuovisnost - Reduce coupling
Zadrži što višu razinu apstrakcije - Keep the level of abstraction as high as possible
Povećaj ponovnu uporabivost - Increase reusability
Povećaj uporabu postojećeg - Reuse existing designs and code
Oblikuj za fleksibilnost - Design for flexibility
Planiraj zastaru - Anticipate obsolescence
Oblikuj za prenosivost - Design for portability
Oblikuj za ispitivanje - Design for testability
Oblikuj konzervativno - Design defensively
Oblikuj po ugovoru - Design by contract
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

30. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
1: Podijeli i vladaj
engl. Divide and conquer
Jednostavniji je rad s više malih dijelova.
Odvojeni timovi rade na manjim problemima.
Omogućava specijalizaciju pojedinca i tima..
Manje komponente povećana razumljivost.
Olakšana zamjena dijelova (bez opsežne intervencije u cijeli sustav).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

31. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Primjeri programskih sustava koji zadovoljavaju princip “Podijeli i vladaj”.
Distribuirani sustavi – klijenti i poslužitelji.
Podjela sustava u podsustave.
Podjela podsustava u pakete.
Podjela paketa u razrede/klase (kod npr. Objektno usmjerene arhitekture).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

32. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
2: Povećanje kohezije
engl. Increase cohesion
Podsustav ili modul ima veliku koheziju ako grupira međusobno povezane elemente, a sve ostalo stavlja izvan grupe.
Olakšava razumijevanje i promjene u sustavu.
Klasifikacija (ne za ispit)
Funkcijska – Functional;
Razinska – Layer;
Komunikacijska – Communicational:
Sekvencijska – Sequential;
Proceduralna - Procedural;
Vremenska – Temporal;
Korisnička - Utility
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

33. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Funkcijska kohezija
engl. Functional cohesion
Sav kod koji obavlja pojedinu operaciju je grupiran, sve ostalo izvan.
To se npr. događa kad modul obavlja jednu operaciju, te vraća rezultat bez popratnih efekata.
prednosti:
Olakšano razumijevanje.
Povećana ponovna uporabljivost modula.
Lakša zamjena.
Suprotan je princip nefunkcijske kohezije:
Modul mijenja bazu podatka, kreira datoteku, interakcija s korisnikom
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

34. Razinska kohezija (kohezija u istoj razini)
engl. Layer cohesion
Svi resursi za pristup skupu povezanih usluga (servisa) su na jednom mjestu, sve ostalo izvan.
Razine formiraju hijerarhiju
Viša razina može pristupiti servisima niže razine.
Niža razina ne pristupa uslugama na višoj razini.
Skup procedura kojima pojedina razina omogućava pristup servisima naziva se aplikacijsko (primjensko) programsko sučelje (engl. application programming interface (API)).
Moguća zamjena pojedine razine bez utjecaja na ostale (više ili niže) razine.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

35. Komunikacijska kohezija
engl. Communicational cohesion
Svi moduli koji pristupaju ili mijenjaju određene podatke su grupirani, sve ostalo izvan.
Klasa/razred (u objektnom pristupu) ima dobru komunikacijsku koheziju ako:
Sadrži sve usluge neophodne za rad s podacima.
Ne obavlja ništa drugo osim upravljanja podacima.
Prednost:
Prilikom promjene podatka sav kod na jednom mjestu.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

36. Sekvencijska kohezija
engl. Sequential cohesion
Postiže se grupiranjem procedura u kojoj jedna daje ulazne podatke slijedećoj, sve ostale izvan.
Na postizanje sekvencijske kohezije fokusiramo se nakon svih prethodnih kohezijskih tipova.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

37. Proceduralna kohezija
engl. Procedural cohesion
Procedure koje se upotrebljavaju jedna nakon druge (u nizu).
Ne moraju razmjenjivati informacije kao kod sekvencijske kohezije.
Slabija kohezija od sekvencijske.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

38. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Vremenska kohezija
engl. Temporal Cohesion
Operacije koje se obavljaju tijekom iste faze rada programa su grupirane, sve ostalo izvan.
Npr. Podizanje sustava ili inicijalizacija.
Slabija od proceduralne kohezije.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

39. Kohezija pomoćnih programa
engl. Utility cohesion
Povezani pomoćni programi (engl. utilities) koji se logički ne mogu smjestiti u ostale kohezijske grupe.
Pomoćni program je procedura ili klasa/razred koja je široko primjenjiva za različite implementirane sustave.
Npr. java.lang.Math
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

40. 3: Smanjivanje međuovisnosti
engl. Reduce coupling where possible
Povezivanje se javlja u slučaju međuovisnosti modula
Međuovisnost  promjene na jednom mjestu zahtijevaju i promjene drugdje.
Kod velike međuovisnosti teško je jasno raspoznati rad komponente.
Tipovi međuovisnostI (ne za ispit):
Content, Common, Control, Stamp, Data, Routine Call, Type use, Inclusion/Import, External
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

41. Međuovisnost sadržaja
engl. Content coupling
Jedna komponenta prikriveno mijenja interne podatke druge komponente.
U objektnom oblikovanju da bi se smanjila međuovisnost sadržaja potrebno je:
Uporaba enkapsulacije svih varijabli instancija
Deklarirati ih kao private
Osigurati get i set methods (za indirektan pristup).
Najgori oblik međuovisnostI sadržaja (teško se detektira) javlja se pri modifikaciji varijable instancije koja je sadržana u varijabli instancije (višerazinska međuovisnost).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

42. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Opća međuovisnost
engl. Common coupling
Javlja se pri uporabi globalne varijable
Sve komponente koje rabe globalnu varijablu postaju povezane i ovisne o komponenti koja deklarira tu varijablu.
Slabiji oblik međuovisnostI nastaje kad instancije jednog podskupa klasa pristupaju globalnoj varijabli.
Npr. Java package
Globalne varijable mogu biti prihvatljive za postavljanje tipičnih vrijednosti sustava (engl. default values).
Smanjenje opće međuovisnosti postiže se enkapsulacijom globalne varijable (zatvaranjem s rutinama koje joj pristupaju).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

43. Upravljačka međuovisnost
engl. Control coupling
Izravna kontrola rada druge procedure uporabom zastavice (npr. “case” ili “switch” naredbe) ili izravne naredbe.
Za neku promjenu potrebno mijenjati obje procedure (pozvanu i onu koja poziva).
Izbjegavanje:
Uporabom polimorfnih operacija u objektnom pristupu. Više procedura ima isti naziv (obavljaju istu apstraktnu operaciju) a tijekom rada određuje se koju točno proceduru treba pozvati i kako se ona izvodi (ovisno na koji razred se odnosi).
look-up tablice (indirektno pozivanje)
Pridruživanje naredbi odgovarajućoj metodi (proceduri).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

44. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Vanjska međuovisnost
engl. External coupling
Javlja se kad modul ovisi o Operacijskom sustavu, biblioteci, HW, ...
Potrebno je minimizirati broj mjesta na kojima se javlja takva povezanost.
Ili u objektnom pristupu oblikovati malo sučelje prema vanjskim komponentama (to se naziva Facade Design Pattern).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

45. 4: Zadrži što višu razinu apstrakcije
engl. Keep the level of abstraction as high as possible
Osigurati da oblikovanje omogući što veće sakrivanje ili odgodu razmatranja detalja, te na taj način smanji složenost.
Dobra apstrakcija podrazumijeva skrivanje informacija (engl. information hiding). Predložio prof. Parnas još 1972., u radu “On Criteria to be Used in Decomposing Systems Into Modules”. Temelj Objektno usmjerenog pristupa.
Omogućava razumijevanje biti (suštine) podsustava bez nepotrebnih detalja.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

46. Apstrakcije u objektnom oblikovanju
engl. Abstraction and classes (OO design)
Klase/razredi su podatkovne apstrakcije koje sadrže proceduralne apstrakcije (metode).
Razina apstrakcije se povećava definiranjem što više privatnih varijabli (nedostupnih izvana).
Poboljšava se smanjivanjem broja javnih metoda.
Superklase (nasljeđivanja) i sučelja (engl. interface) povećavaju razinu apstrakcije.
Atributi i asocijacije (dvije vrste varijabli instancija) također predstavljaju podatkovne apstrakcije.
Apstrakcija se povećava sa smanjivanjem broja argumenata procedura (metoda).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

47. 5: Povećaj ponovnu uporabivost
engl. Increase reusability where possible
Oblikovanje različitih aspekata sustava tako da može pridonijeti njihovoj ponovnoj uporabi.
Generaliziraj oblikovanje što je više moguće.
Uporabi prethodne principe oblikovanja Povećaj koheziju, Smanji povezanost, Zadrži visoku razinu apstrakcije
Oblikuj sustav tako da sadrži kopče (engl. hooks), t.j. sučelje koje omogućavaju pristup u program nekom dodatnom korisničkom kodu. Korisnik vidi kopče kao otvore u kodu koji su dostupni u trenutku pojave nekog događaja ili zadovoljenja nekog uvjeta.
Maksimalno pojednostavi oblikovanje.
(A hook offers the opportunity to execute one or more user-supplied program fragments at some designated place in a program. From a user's point of view, hooks may be regarded as openings of a program, which are effective when some event happens, or if some condition is fulfilled.)
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

48. 6:Povećaj uporabu postojećeg
engl. Reuse existing designs and code where possible
Princip je komplementaran povećanju ponovne uporabivosti.
Veća aktivna ponovna uporaba komponenti smanjuje trošak i povećava stabilnost sustava.
Treba iskoristiti ranije investicije.
“kloniranje“ (engl. cloning), t.j. ponavljanje istih linija koda se ne računa kao uporaba nekog postojećeg dijela u sustavu.
(Clonning = ponovno pisanje istih linija koda)
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

49. 7: Oblikuj za fleksibilnost
engl. Design for flexibility
Aktivno predviđaj buduće moguće promjene i provedi pripremu za njih tako da:
Smanji međuovisnost i povećaj koheziju.
Stvaraj apstrakcije.
Ne upotrebljavaj izravno umetanje podataka ili konfiguracija u izvorni programski kod (engl. hard code).
Ostavi otvorene opcije za kasniju.modifikaciju
Upotrebljavaj ponovo gotovi kod i radi ga takvog (teži što većoj ponovnoj uporabi i uporabivosti).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

50. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
8: Planiraj zastaru
engl. Anticipate obsolescence
Planiraj promjene u tehnologiji ili okolini tako da program može i dalje raditi ili biti jednostavno promijenjen,
Izbjegavaj uporabu novih izdanja (engl. release) tehnologija.
Izbjegavati knjižnice namijenjene specifičnim okolinama.
Izbjegavaj nedokumentirane ili rijetko upotrebljavane dijelove knjižnica.
Izbjegavaj SW/HW bez izgleda za dugotrajniju podršku.
Uporabi tehnologije i jezike podržane od više dobavljača.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

51. 9: Oblikuj za prenosivost
engl. Design for Portability
Omogući rad programske potpore na što većem broju različitih platformi.
Izbjegavaj specifičnosti neke okoline.
Npr. knjižnice koje postoje samo u Microsoft Windows.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

52. 10: Oblikuj za ispitivanje
engl. Design for Testability
Olakšaj ispitivanje
Oblikuj program za automatsko ispitivanje.
Omogući odvojeno pokretanje svih funkcija uporabom vanjskih programa (npr. zaobilazeći grafičko sučelje).
Npr. U Javi, kreiraj main() metodu u svakoj klasi tako da se mogu ispitati druge metode (procedure).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

53. 11: Oblikuj konzervativno
engl. Design Defensively
Ne koristiti pretpostavke kako će netko koristiti oblikovanu komponentu.
Obradi sve slučajeve u kojima se komponenta može neprikladno upotrijebiti.
Provjeri valjanost ulaza u komponentu provjerom definiranih pretpostavki.
Pretjerano obrambeno oblikovanje – često dovodi do nepotrebnih provjera (usporavanja rada sustava).
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

54. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
12. Oblikuj po ugovoru
engl. Design by contract
To je tehnika koja omogućava efikasan i sistematski pristup konzervativnom oblikovanju.
Osnovna ideja
Sve metode imaju ugovor s pozivateljima.
Ugovor ima skup definiranih zahtjeva, t.j.:
Preduvjeti koje pozvana metoda traži da budu ispunjeni prije početka izvođenja (engl. preconditions).
Uvjeti koje pozvana metoda mora osigurati nakon završetka izvođenja (engl. postconditions).
Invarijante na koje pozvana metoda neće djelovati (mijenjati) pri izvođenju.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

55. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva
Teme ove prezentacije
Uvesti pojmove arhitekture programske potpore.
Objasniti proces donošenja odluka u izboru i oblikovanju arhitekture programske potpore.
Definirati kriterije za izbor arhitekture.
Definirati strukturu i sadržaj dokumenata oblikovanja.
To je proces identificiranja podsustava koji čine cjelinu te okruženja za upravljanje i komunikaciju između podsustava.
Rezultat procesa oblikovanja je opis (dokumentiranje) arhitekture programske potpore.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

56. Dokumentiranje arhitekture 1
Potrebno zbog rane analize sustava.
Temeljni nositelj obilježja kvalitete.
Ključ za održavanje, poboljšanja i izmjene.
Dokumentacija ne zastarijeva.
govori umjesto arhitekta danas i nakon 20 godina (ukoliko je sustav oblikovan, održavan i mijenjan sukladno dokumentaciji).
U praksi je danas dokumentacija nejednoznačna i često kontradiktorna.
Najčešće samo pravokutnici i linije koje mogu značiti: A šalje upravljačke signale do B, A šalje podatke do B, A šalje poruku do B, A kreira B, A dobavlja vrijednost od B, …
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

57. Dokumentiranje arhitekture 2
Dokumenti arhitekture su pomoć pri izradi boljih budućih oblikovanja.
Traže izričitost i obrađuju najvažnija pitanja prije faze implementacije.
Omogućuju vrednovanje oblikovanja i poboljšanje.
Sredstvo komunikacije prema:
Timu za implementaciju
Budućim osobama zaduženim za unošenje promjena
Osobama za oblikovanje povezanih sustava ili podsustava
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

58. Struktura dokumenta oblikovanja
Svrha (koji sustav ili dio sustava ovaj dokument opisuje te označi referenciju prema dokumentu zahtjeva na koji se ovaj dokument oslanja – slijed dokumenata).
Opći prioriteti (opiši prioritete koji su vodili proces oblikovanja).
Skica sustava (navedi opis sustava s najviše razine promatranja kako bi čitatelj razumio osnovnu ideju).
Temeljna pitanja u oblikovanju (diskutiraj osnovne probleme koji su se morali razriješiti, navedi razmatrane opcijska rješenja, konačnu odluku i razloge za njeno donošenje).
Detalji oblikovanja (koji su čitatelju zanimljivi a u dokumentu još nisu razmatrani).
(Struktura dokumenta oblikovanja)
Svrha (koji sustav ili dio sustava ovaj dokument opisuje te označi referenciju prema dokumentu zahtjeva na koji se ovaj dokument oslanja - slijedivost).
Opći prioriteti (opiši prioritete koji su vodili proces oblikovanja).
Skica sustava (navedi opis s najviše razine promatranja kako bi čitatelj razumio osnovnu ideju).
Temeljna pitanja u oblikovanju (diskutiraj osnovne probleme koji se moraju razriješiti, navedi razmatrana alternative rješenja, konačnu odluku i razloge za njeno donošenje).
Detalji oblikovanja (koji u dokumentu još nisu razmatrani).
Izbjegavaj: a) opis informacije koja je očigledna, b) informacije koja bi bolje pristajala komentiranju koda, c) pisanje detalja koji se automatizirano mogu izvući iz koda.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

59. Što nije sadržaj dokumenta oblikovanja
Izbjegavati dokumentiranje informacija koje su očite iskusnim programerima i dizajnerima.
Ne pisati detalje koji su dio komentara koda.
Ne pisati detalje koji su vidljivi u strukturi koda.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva

60. ZAKLJUČAK o izboru i dokumentiranju arh. prog. potpore
Izbor i dokumentiranje arhitekture mora rezultirati u dokumentu koji je:
Dobar
Tehnički jasno prezentiran.
Ispravan
Doseže potrebe i ciljeve ključnih dionika (zahtjevi ?).
Uspješan
Upotrebljava se u stvarnom razvoju sustava kojim se postižu strateške prednosti.
Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva