Oblikovanje programske potpore Arhitektura programske potpore stilovi i

Oblikovanje programske potpore Arhitektura programske potpore, stilovi i modeli

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

Teme ove prezentacije n n 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. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 3

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

Teme ove prezentacije n n 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. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 5

Od zahtjeva do koda n Veliki raskorak između problema i rješenja Zahtjevi ? ? Implementacija(e) Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 6

Uloga arhitekture prog. podrške n Zahtjevi n Dio strukturiranog procesa programskog inženjerstva. Daje apstrakciju sustava na visokoj razini. n n arhitektura prog. ? ? podrške n n n 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. Implementacije Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 7

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). Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 8

Aktivnost oblikovanja arhitekture progr. potpore n n 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 9

Prednosti definiranja arhitekture n n n n 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 10

Definicija arhitekture n “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. ” design n n “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. ” n n Garlan, 1992 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. n The IEEE Standard for Architectural Description of Software-Intensive Systems (IEEE P 1471/D 5. 3) Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 11

Definicija arhitekture n n n 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: n Elemente: dijelovi sustava n Odnose između elemenata : topologija n Vanjska vidljiva obilježja n Veličina, performanse, sigurnost, API Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 12

Opis arhitekture modelima n Više pogleda u okviru nekog konteksta predstavljaju model arhitekture programske potpore, npr. : Dinamički procesni model n komponente u izvođenju (engl. runtime) n Alocirane elemente (npr. datoteke). n… n Statičan strukturni model - Moduli n pokazuju kompoziciju/dekompoziciju sustava n 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 13

Klasifikacija arhitekture po dosegu n Koncepcijska - engl. Conceptual Architecture n n Logička - engl. Logical Architecture n n Usmjeravanje pažnje na pogodnu dekompoziciju sustava. Komunikacija s netehničkim dionicima (uprava, prodaja, korisnici). Neformalna specifikacija komponenti (npr. CRC-R cards) 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 n n Namijenjena distribuiranim i paralelnim sustavima. Pridruživanje procesa fizičkom sustavu. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 14

Teme ove prezentacije n n 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. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 15

n n 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) n n Postoji nekoliko inačica rješenja. n n To su podproblemi ukupnog problema. engl. design options Dizajner donosi odluke (engl. design decision) za rješavanje problema. n Odabir najbolje opcije između više mogućnosti rješenja problema. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 16

Prostor oblikovanja n 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 17

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

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

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

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

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

Preporučeni postupak razvoja modela arhitekture n n n Započni s grubom skicom arhitekture zasnovanoj na osnovnim zahtjevima i obrascima uporabe. Odredi temeljne potrebne dijelove sustava. Izaberi između raznih stilova arhitekture n n Savjet: nekoliko timova nezavisno radi grubu skicu arhitekture, a potom se spoje najbolje ideje. Arhitekturu dopuni detaljima tako da se: n n 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 23

Tehnika donošena dobrih odluka oblikovanja n 1. 2. 3. 4. 5. 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 24

Primjer kriterija za oblikovanje računalnog sustava (to nisu ciljevi i prioriteti u oblikovanju arhitekture programske potpore) n n n Sigurnost/Security: Podaci se ne smiju moći dešifrirati poznatim tehnikama za < 100 sati na 1 GHz Intel procesoru. Održavanje/Maintainability: Nema Performanse/CPU efficiency: Odziv < 1 s na 1 GHz Intel procesoru. Mrežno opterećenje/Network bandwidth efficiency: 8 KB po transakciji. Memorijski resursi/Memory efficiency: 200 MB 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 25

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 26

Dodatni kriteriji za odabir najpovoljnije opcije (engl. “cost-benefit” analiza) Procjena CIJENE/troškova sumira: n n 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: n n Uštedu vremena programskog inženjera. Dobrobiti mjerene kroz povećanu prodaju ili ostale financijske uštede. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 27

Teme ove prezentacije n n 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. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 28

Principi oblikovanja i kriteriji izbora arhitekture 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 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 29

1: Podijeli i vladaj engl. Divide and conquer n n n 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 30

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

2: Povećanje kohezije engl. Increase cohesion n 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) n n n n 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 32

Funkcijska kohezija engl. Functional cohesion n n 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. n prednosti: n n Olakšano razumijevanje. Povećana ponovna uporabljivost modula. Lakša zamjena. Suprotan je princip nefunkcijske kohezije: n Modul mijenja bazu podatka, kreira datoteku, interakcija s korisnikom Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 33

Razinska kohezija (kohezija u istoj razini) engl. Layer cohesion n Svi resursi za pristup skupu povezanih usluga (servisa) su na jednom mjestu, sve ostalo izvan. n Razine formiraju hijerarhiju n n 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 34

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

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

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

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

Kohezija pomoćnih programa engl. Utility cohesion n 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. n Npr. java. lang. Math n Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 39

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

Međuovisnost sadržaja engl. Content coupling n Jedna komponenta prikriveno mijenja interne podatke druge komponente. n U objektnom oblikovanju da bi se smanjila međuovisnost sadržaja potrebno je: n Uporaba enkapsulacije svih varijabli instancija Deklarirati ih kao private n Osigurati get i set methods (za indirektan pristup). n n Najgori oblik međuovisnost. I 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 41

Opća međuovisnost engl. Common coupling n Javlja se pri uporabi globalne varijable n n Sve komponente koje rabe globalnu varijablu postaju povezane i ovisne o komponenti koja deklarira tu varijablu. Slabiji oblik međuovisnost. I nastaje kad instancije jednog podskupa klasa pristupaju globalnoj varijabli. n n n 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 42

Upravljačka međuovisnost engl. Control coupling n Izravna kontrola rada druge procedure uporabom zastavice (npr. “case” ili “switch” naredbe) ili izravne naredbe. n n Za neku promjenu potrebno mijenjati obje procedure (pozvanu i onu koja poziva). Izbjegavanje: n n 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) n Pridruživanje naredbi odgovarajućoj metodi (proceduri). Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 43

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

4: Zadrži što višu razinu apstrakcije engl. Keep the level of abstraction as high as possible n Osigurati da oblikovanje omogući što veće sakrivanje ili odgodu razmatranja detalja, te na taj način smanji složenost. n 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. n Omogućava razumijevanje biti (suštine) podsustava bez nepotrebnih detalja. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 50

Apstrakcije u objektnom oblikovanju engl. Abstraction and classes (OO design) n Klase/razredi su podatkovne apstrakcije koje sadrže proceduralne apstrakcije (metode). n n n 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 51

5: Povećaj ponovnu uporabivost engl. Increase reusability where possible n Oblikovanje različitih aspekata sustava tako da može pridonijeti njihovoj ponovnoj uporabi. n n 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. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 52

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

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

8: Planiraj zastaru engl. Anticipate obsolescence n Planiraj promjene u tehnologiji ili okolini tako da program može i dalje raditi ili biti jednostavno promijenjen, n n n 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 55

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

10: Oblikuj za ispitivanje engl. Design for Testability n Olakšaj ispitivanje n Oblikuj program za automatsko ispitivanje. n Omogući odvojeno pokretanje svih funkcija uporabom vanjskih programa (npr. zaobilazeći grafičko sučelje). n 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 57

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

12. Oblikuj po ugovoru n n engl. Design by contract To je tehnika koja omogućava efikasan i sistematski pristup konzervativnom oblikovanju. n Osnovna ideja n n 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). n Uvjeti koje pozvana metoda mora osigurati nakon završetka izvođenja (engl. postconditions). n Invarijante na koje pozvana metoda neće djelovati (mijenjati) pri izvođenju. n Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 59

Teme ove prezentacije n n 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. Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 60

Dokumentiranje arhitekture 1 n n Potrebno zbog rane analize sustava. Temeljni nositelj obilježja kvalitete. Ključ za održavanje, poboljšanja i izmjene. Dokumentacija ne zastarijeva. n n 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. n 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 61

Dokumentiranje arhitekture 2 n n 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 n Budućim osobama zaduženim za unošenje promjena n Osobama za oblikovanje povezanih sustava ili podsustava n Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 62

Struktura dokumenta oblikovanja n n n 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). Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva 63

Što nije sadržaj dokumenta oblikovanja n n n 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 64

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