proizvodnja softvera dizajn softvera

Upload: slobodan-stanojevic-coba

Post on 06-Mar-2016

56 views

Category:

Documents


2 download

DESCRIPTION

Izvod iz knjige

TRANSCRIPT

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    1

    POGLAVLJE 3

    DIZAJN SOFTVERA

    Skraenice

    ADL Jezici opisne arhitekture CRC ema klasa, njihovih ovlaenja i

    meusobnih komponenti ERD Dijagram entiteta (objekata) i relacija IDL Jezik opisa interfejsa DFD Dijagram toka podataka PDL Pseudo-kod i jezik dizajna programa CBD Dizajn osnovnih delova

    Uvod

    U [IEEE610.12-90], dizajn je dvojako definisan, kao proces koji definie arhitekturu, komponente, interfejse i druge karakteristike sistema ili komponente i kao rezultat tog procesa. Posmatrano kao proces, dizajn softvera je aktivnost softverskog inenjerstva unutar ivotnog ciklusa razvoja softvera, gde su softverski zahtevi analizirani sa ciljem da se napravi opis unutranje strukture softvera, koji e sluiti kao osnova za njegovu izradu. Tanije reeno, dizajn softvera mora opisati softversku arhitekturu, odnosno opisati kako je softver podeljen i organizovan na komponente i interfejse koji povezuju ove komponente. Takoe dizajn mora opisati komponente i na nivou detalja kako bi se omoguila njihova izrada.

    Dizajn softvera igra vanu ulogu u razvoju softvera: on dozvoljava softver inenjerima da proizvode razliite modele kako bi formirali ideju vodilju za reenja koja e biti primenjena. Kroz analizu i vrednovanje ovih modela odluujemo da li e nam omogiiti da ispunimo razliite zahteve. Takoe, moemo ispitati i vrednovati razliita reenja. Konano, moemo koristiti ve postojee modele za planiranje sledeih razvojnih aktivnosti, posebno kao ulaznu i poetnu taku kodiranja i testiranja. U standardnom ivotnom ciklusu razvoja softvera kao u IEEE/EIA 12207 Procesi ivotnog ciklusa softvera [IEEE12207.0-96], softver dizajn se sastoji od dve aktivnosti koje stoje izmeu softverskih zahteva i softverskog kodiranja i testiranja:

    dizajn softverske arhitekture (ponekad nazvan opti nivo dizajna): koji opisuje opti nivo softverske strukture i organizacije sa identifikacijom razliitih komponenti

    detaljni dizajn softvera koji opisuje svaku komponentu dovoljno precizno da omoguava njenu izradu (kodiranje).

    Razmatrajui domen dizajna softvera, oblast znanja (KA) ne raspravlja svaku temu u kojoj se pojavljuje re "dizajn". U terminologiji DeMarko [DeM99], razmatrani KA ovde uglavnom se odnosi na D-dizajn (rastavljanje dizajna, mapiranje softvera u

    komponente). Meutim, zbog svoje vanosti i zbog irenja znaaja arhitekture softvera, spomenuemo FP-dizajn (obrazac familije dizajna, iji je cilj da izgradi pravila za upotrebu u familiji softvera). Nasuprot ovome, oblast znanja (KA) dizajna softvera ne upotrebljavaju I-dizajn (dizajn izuma, koji se obino pravi za vreme procesa softverskih zahteva sa ciljem konceptualizacije i specificiranja softvera koji e zadovoljiti nadolazee potrebe i zahteve), poto ova tema treba da bude razmatrana kao deo analize i specificiranja zahteva.

    Oblast znanja (KA) Dizajna softvera se odnosi posebno na Softverske zahteve, Konstrukciju (izradu) softvera, Upravljanje softverom, Kvalitetom softvera i odgovarajue discipline Softverskog inenjerstva.

    Pregled tema za dizajn softvera

    1. Osnove dizajna softvera

    Kocepti, nain izraavanja i terminologija koji se ovde koriste formiraju osnove za razumevanje oblasti i uloge dizajna softvera.

    1.1. Koncepti opteg dizajna

    Softver nije samo oblast gde je dizajn ukljuen. Na generalnom nivou, dizajn moemo smatrati kao reavanje problema [Bud03:c1]. Tako na primer, koncept tekog problema problem bez definitivnog reenja je interesantan za razumevanje ogranienja dizajna [Bud04:c1]. Brojni drugi primeri i koncepti su takoe od interesa za shvatanje dizajna u njegovom optem smislu: ciljevi, ogranienja, alternative, predlozi i reenja [Smi93].

    1.2. Kontekst dizajna softvera

    Za razumevanje uloge dizajna softvera, vano je razumevanje konteksta u kome se on deava odnosno, ivotni ciklus softver inenjeringa. Vano je takoe i razumevanje glavnih karakteristika analize softverskih zahteva prema dizajnu softvera, prema izradi i prema testiranju softvera [IEEE12207.0-96; Lis01:c11; Mar02; Pfl01:c2; Pre04:c2].

    1.3. Proces dizajna softvera

    Dizajn softvera je generalno razmatran u dva procesa:[Bas03; Dor02:v1c4s2; Fre83:I; IEEE12207.0-96; Lis01:c13; Mar02:D]

    1.3.1. Dizajn arhitekture Dizajn arhitekture opisuje kako je softver sastavljen i organizovan po delovima (arhitektura softvera) [IEEE 1471-00]

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    2

    1.3.2. Detaljni dizajn Detaljni dizajn opisuje ponaanje svake komponente.

    Izlaz iz ovih procesa je skup modela i dokumenata koji daju glavni opis nekog sistema i kako e on biti uraen [Bud04:c2; IEEE1016-98; Lis01:c13; Pre04:c9].

    1.4. Tehnike realizacije dizajna

    Shodno Oksfordskom reniku, princip je osnovna istina ili opti zakon ... koji se koristi za rasuivanje ili kao linija vodilja, tako i principi softverskog dizajna koji se jo i zovu tehnike realizacije dizajna, su kljuno ime za razumevanje osnova raznih pristupa i koncepata u dizajnu softvera. Tehnike realizacije dizajna napisane su u: [Bas98:c6; Bus96:c6; IEEE1016-98; Jal97:c5,c6; Lis01:c1,c3; Pfl01:c5; Pre04:c9].

    1.4.1. Uoptavanje (apstrakcija) Apstrakcija je proces zanemarivanja onih informacija koje su razliite, ali mogu biti tretirane kao da su iste. [Lis01]. U kontekstu dizajna softvera, postoje dva kljuna mehanizma uoptavanja, a to su parametrizacija i specifikacija. Putem specifikacije, apstrakcija ide u tri glavna pravca: proceduralno uoptavanje, uoptavanje podataka i kontrolno (iterativno) uoptavanje [Bas98:c6; Jal97:c5,c6; Lis01:c1,c2,c5,c6; Pre04:c1].

    1.4.2. Spajanje (kuplovanje) i sjedinjavanje (kohezija)

    Spajanje (kuplovanje) se definie kao jaka sprega izmeu modula, a sjedinjavanje (kohezija) je kako se elementi odnose i ine modul [Bas98:c6; Jal97:c5; Pfl01:c5; Pre04:c9].

    1.4.3. Razlaganje (dekompozicija) i modulizacija Razlaganje (dekompozicija) i modulizacija velikog softvera u vie manjih nezavisnih delova izvodi se sa ciljem postavljanja raznih funkcionalnosti na razliite komponente [Bas98:c6; Bus96:c6; Jal97:c5; Pfl01:c5; Pre04:c9].

    1.4.4. Saimanje (enkapsulacija) i nedostupnost koda Enkapsulacija (saimanje) i skrivanje informacija je grupisanje i pakovanje elemenata i internih podataka kroz uoptavanje inei da kod bude nedostupan [Bas98:c6; Bus96:c6; Jal97:c5; Pfl01:c5; Pre04:c9].

    1.4.5. Odvajanje (separacija) interfejsa i implementacija Odvajanje (separacija) interfejsa i implementacija podrazumeva definisanje komponenata specificiranjem javnog interfejsa, poznatog samo za klijente (korisnike), koji je odvojen od naina kako je realizovan [Bas98:c6; Bos00:c10; Lis01:c1,c9].

    1.4.6. Dovoljnost, kompletnost i jednostavnost Postizanje dovoljnosti, kompletnosti i jednostavnosti znai da softverske komponente poseduju sve vane karakteristike uoptavanja, i nita vie [Bus96:c6; Lis01:c5].

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    3

    2. Kljuna pitanja dizajna softvera

    Brojna kljuna pitanja moraju biti reena kada se dizajnira softver. Neka od njih razmatraju kako se ceo softver adresira, recimo performanse. Drugo vano pitanje je kako rastaviti, organizovati i spakovati softverske komponente. Ovo je toliko fundamentalno da svi pristupi dizajnu moraju ovo uzeti u obzir na ovaj ili onaj nain (videti taku 1.4. Tehnike realizacije dizajna i taku 6. Strategije i metode dizajna softvera). U protivnom, druga pitanja e aspekte ponaanja softvera koja nisu u domenu aplikacije postaviti kao domen podrke [Bos00]. Takva pitanja, koja esto degradiraju funkcionalnost sistema, dobie status pojave [pojave] ne ele da budu izuzeci softverske funkcionalne dekompozicije, nego ele da uu u oblast performansi ili u znaenje komponenti na sistemski nain [KLM+97]. Kljuna pitanja koja degradiraju sistem su sledea:

    2.1. Konkurentnost (istovremenost) Kako se softver razlae na procese, taskove i tredove (niti) i kako se rukuje sa efikasnou, atomizacijom, sinhronizacijom i raspodelom zadataka [Bos00:c5, Mar94:CSD, Mey97:c30, Pre04:c9].

    2.2. Kontrola i obrada dogaaja

    Kako se organizuju podaci i kako se vri kontrola toka, kako se upravlja sa odzivom sistema i privremenim dogaajima kroz razliite mehanizme kao to su podrazumevajui pozivi ili odzivi sistema na preduzetu akciju (call-backs) [Bas98:c5, Mey97:c32, Pfl01:c5].

    2.3. Distribucija komponenti Kako se softver distribuira kroz hardver, kako komponente komuniciraju, kako se centralni hardver moe upotrebiti sa heterogenim softverom [Bas03:c16, Bos00:c5, Bus96:c2, Mar94:DD, Mey97:c30, Pre04:c30].

    2.4. Greke i rukovanje izuzecima i tolerisanje greaka Kako se vri zatita od greaka i kako se toleriu greke i upravlja sa izuzecima [Lis01:c4, Mey97:c12, Pfl01:c5].

    2.5. Interakcija i predstavljanje (prezentacija) Kako se struktuira i organizuju interakcije sa korisnicima i kako se vri prikazivanje informacija (na pr. Odvajanje prikaza od logike rada softvera korienjem pristupa Model-View-Conroler) [Bas98:c6, Bos00:c5, Bus96:c2, Lis01:c13, Mey97:c32]. Treba napomenuti da ovo pitanje nije u vezi sa speficiranjem korisnikog interfejsa, jer je to zadatak dizajna korisnikog interfejsa (deo

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    4

    Softverske ergonomije); videti odgovarajue discipline softverskog inenjeringa.

    2.6. Postojanost podataka Kako da se obrade podaci koji su davno generisani, a i dalje su aktuelni [Bos00:c5, Mey97:c31].

    3. Struktura i arhitektura softvera

    U strogom smislu, softverska arhitektura je opis podsistema i komponenti softverskog sistema i relacija izmeu njih [Bus96:c6]. Prema tome, arhitektura definie internu strukturu datog softvera ili nain na koji je neto konstruisano ili organizovano. Sredinom 1990-tih, meutim, softverska arhitektura se pojavila kao iroka disciplina koja obuhvata arhitekturu i strukturu softvera na najoptiji nain [Sha96]. Ovo je dalo mnoge interesantne ideje u vezi sa dizajnom softvera na razlicitim nivoima uoptavanja. Neki od ovih koncepata korisni su za vreme dizajniranja arhitekture nekog softvera, ali isto tako i za vreme njegovog detaljnog dizajniranja (primeri niskog nivoa dizajna). Takoe su korisni i za dizajniranje optih sistema, rukovodei se dizajniranju familije programa, odnosno vie slinih programa iz skupa proizvoda nekog proizvoaa. Mnogi od ovih koncepata primenljivi su kako za opis opteg znanja dizajna, tako i za ponovnu upotrebu.

    3.1. Strukture i gledita arhitekture Razni delovi dizajna softvera na visokom nivou treba i mora da budu opisani i dokumentovani. Ovi delovi su esto nazivani aspektima: Aspekt predstavlja poseban pogled na arhitekturu softvera i specifine osobine softverskog sistema [Bus96:c6]. Ovi razliiti pogledi pripadaju razliitim oblastima dizajna softvera na primer, logiki aspekt (onaj koji zadovoljava funkcionalne zahteve), pa procesni aspekt (koji ima zahteve istovremenosti), pa fiziki aspekt (koji ispunjava zahteve raspodele hardvera), pa razvojni aspekt (kako se dizajn deli na implementacione jedinice). Drugi autori koriste razliitu terminologiju, kao ponaanje na pr. funkcionalno, strukturalno, modeliranje podataka. Uopteno gledano, dizajn softvera je proces sklapanja mozaika od relativno nezavisnih celina [Bus03:c2; Boo04:c5; Bus96:c6; IEEE1016-98; IEEE1471-00].

    Arhitektura softvera na makro planu. Vrsta arhitekture je skup ogranienja koja zadovoljavaju datu familiju arhitektura [Bas03:c2]. Stoga se vrsta arhitekture moe prikazati kao model koji moe obezbediti visok nivo organizacije softvera. Razni autori su identifikovali vie glavnih vrsta arhitekture [Bas03:c5; Boo99:c28; Bos00:c6; Bus96:c1,c6; Pfl01:c5]

    Opta struktura (na pr. lejeri, filteri, soket parovi)

    Distribuirani sistemi (na pr. klijent-server) Interaktivni sistemi (na pr. Model-View-

    Controler, Presentation-Abstraction-Control)

    Adaptabilni sistemi (na pr. mikro kernel) Ostali (na pr. interpreteri, be procedure).

    3..2. Uzorci dizajna (mikroarhitekturalni primeri) Uzorak je, tanije reeno, tipizirano reenje za tipizirani problem u datom kontekstu ili pri datim okolnostima [Jac99]. Poto vrste arhitekture mogu biti posmatrane kao tipizirana organizacija softvera na visokom nivou (makroarhitektura), onda tipizirani dizajn daje vie detalja na niem nivou (mikroarhitektura) [Bas98:c13; Boo99:c28; Bus96:c1; Mar02:DP].

    Kreativni uzorci (na pr. bilderi, prototipovi) Strukturalni uzorci (na pr. adapteri, brideri,

    proksiji) Uzorci oponaanja (na pr. komande,

    interpreteri, iteratori, templejti (mustre ili abloni))

    3.3. Familije programa i radno okruenje Jedan od pristupa koji omoguavaju ponovnu upotrebu dizajna softvera i njegovih komponenti je dizajn familije softvera, poznatiji kao linije softverskog proizvoda. Ovo se uradi tako to se prepoznaju tipini delovi koji imaju zajednike osobine tako da se uzorkovani dizajn ponovo iskoristi prema novim zahtevima. U objekto-orijentisanom programiranju kljuna stavka je radno okruenje: itavi delovi softverskog podsistema mogu biti proireni na odgovarajui specifikum [Bos00:c11; Boo99:c28; Bus96:c6].

    4. Analiza kvaliteta i vrednovanje dizajna softvera

    Ovaj odeljak ukljuuje vrednovanje i kvalitet koj se odnose na dizajn softvera. Cela oblast znanja je posveena Kvalitetu Softvera.

    4.1. Osobine kvaliteta Razni atributi se razmatraju kao vani za vrednovanje dizajna softvera. To su odrivost, prenosivost, raspoloivost za testiranje, robustnost, preciznost, svrsishodnost [Bos00:c5; Bud04:c4; Bus96:c6; ISO9126.1-01; ISO15026-98; Mar94:D, Mey97:c3, Pfl01:c5]. Interesantna je razlika izmeu navedenih atributa i atributa koji pripadaju run-time okruenju (bezbednost, raspoloivost, funkcionalnost, upotrebljivost) kao i onih atributa koji ne spadaju u run-time okruenje (prenosivost, raspoloivost na modifikacije, celovitost, ponovna upotrebljivost) i onih koji se odnose sa stvarnu arhitekturu softvera (konceptualnost, celovitost, preciznost, izgraenost, kompletnost) [Bas04:c4].

    4.2. Analiza kvaliteta i tehnike vrednovanja Razni alati i tehnike se mogu upotrebiti za obezbeenje kvaliteta dizajna softvera.

    Pregled dizajna softvera: to su nezvanine ili poluzvanine, esto grupno orijentisane tehnike za verifikaciju kvaliteta dizajna softvera (na pr. arhitekturalni pregled [Bas03:c11], pregled dizajna i provera [Bud04:c4; Fre83:VIII; IEEE1028-97;

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    5

    Jal97:c5,c7; Lis01:c14; Pfl01:c5], tehnika bazirana na scenariju [Bas98:c9; Bos00:c5], trasa zahteva [Dor02:v1c4s2; Pfl01:c11])

    Statike analize: zvanine ili poluzvanine (neizvrne) (na pr. analiza stabla greaka ili automatizovana provera kroz ceo dizajn) [Jal97:c5; Pfl01:c5]

    Simulacije i prototipovi: dinamike tehnike (na pr. karakteristike simulacije ili opravdanost izgradnje prototipa [Bas98:c10; Bos00:c5; Bud04:c4; Pfl01:c5])

    4.3. Vrednovanja Vrednovanja se koriste za procenu ili kvantitativnu ocenu atributa dizajna softvera kao to su veliina, struktura ili kvalitet. Najea vrednovanja koja se propisuju zavise od pristupa koji je korien za kreiranje dizajna. Ova vrednovanja su podeljena na dve osnovne kategorije:

    Funkcionalno-orijentisani (struktuirani) dizajn: dizajn strukture dobijen kroz funkcionalnu dekompoziciju; uopteno je predstavljen kao strukturni tok (ponekad nazvan hijerarhijski dijagram) na kojem razna vrednovanja mogu biti sprovedena [Jal97:c5,c7; Pre04:c15]

    Objektno-orijentisani dizajn: ovo je dizajn nad strukturom koji je esto nazivan i dijagram klasa. Na svakoj klasi i njenom sadraju mogu biti napravljena vrednovanja [Jal97:c6,c7; Pre04:c15].

    5. Pojmovi dizajna softvera

    Mnogi pojmovi i jezici postoje kojima se predstavlja dizajn softvera. Neki od njih se uglavnom koriste da opiu strukturnu organizaciju dizajna, a drugi da opiu ponaanje softvera. Izvesni pojmovi se koriste uglavnom za vreme dizajniranja arhitekture, a drugi uglavnom za vreme detaljnog dizajna, mada neki pojmovi se koriste u obe faze. Treba napomenuti, da se neki pojmovi koriste uglavnom u kontekstu specifinih metoda (videti odeljak Strategije i metode dizajna softvera). Ovde e pojmovi biti podeljeni na one koji opisuju strukturu (statiko gledite) i na one koji opisuju ponaanje (dinamiko gledite).

    5. 1. Strukturalno (statiko) opisivanje Navedeni pojmovi, uglavnom (ali ne uvek) plastino, opisuju i predstavljaju strukturalni aspekt dizajna softvera tj. opisuju osnovne komponente i kako su one povezane:

    Jezici opisa arhitekture (ADL) su tekstualni, esto formalni, korieni za opis softverske arhitekture kroz komponente i njihove veze [Bas03:c12]

    Klase i dijagrami objekata: koristi se za predstavljanje skupa klasa (i objekata) kao

    i njihovih meusobnih veza [Boo99:c8,c14; Jal97:c5,c6]

    Dijagram komponenti: koristi se za predstavljanje skupa komponenti (stvarnih i zamenljivih delova sistema koji podeavaju i obezbeuju realizaciju seta interfejsa [Boo99] i njihovih meusobnih odnosa ili veza [Boo99:c12,c31])

    ema klasa, njihovih ovlaenja i meusobnih komponenti (CRC): koristi se da oznai imena komponenti ili klasa, njihova ovlaenja i meusobne komponente [Boo99:c4; Bus96]

    Razvojni dijagrami: koriste se za predstavljanje skupa fizikih vorova i njihovih veza i stoga slui za modeliranje fizikih aspekata sistema [Boo99:c30]

    Dijagrami entiteta i odnosa (ERD): koriste se da predstave konceptualno modele podataka koji su u informacionom sistemu [Bud04:c6; Dor02:v1,c5; Mar02:DR]

    Jezici opisa interfejsa (IDL): to su jezici slini programskim koji se koriste da definiu interfejse (imena i vrste eksportovanih operacija) i softverske komponente [Bas98:c8; Boo99:c11]

    Dijagrami Deksonove strukture: koriste se za opisivanje struktura podataka u izrazima kao to su sekvence, selekcije i iteracije [Bud04:c6; Mar02:DR]

    Blok strukture: koriste se za opisivanje pozivajuih struktura programa (koji pozivaju module i koji su pozivani od strane drugih modula) [Bud04:c6; Jal97:c5; Mar02:DR; Pre04:c10].

    5. 2. Opis ponaanja softvera (dinamiko opisivanje) Sledei pojmovi i jezici, neki grafiki a neki tekstualni, koriste se da bi opisali dinamiko ponaanje softvera i komponenti. Mnogi od ovih pojmova su uglavnom korisni, ali ne posebno, u toku detaljnog dizajniranja.

    Dijagram aktivnosti: koristi se da prikae kontrolni tok od jedne aktivnosti (u toku neatomik operacije unutar maine) do druge [Boo99:c19]

    Dijagrami saradnje: koriste se da prikau interakcije koje se deavaju izmeu grupa objekata, sa naglaskom na objekte, njihove linkove i poruke koje oni razmenjuju sa ovim linkovima [Boo99:c18]

    Dijagrami toka podataka (DFD): koriste se da prikau tok podataka kroz set procesa [Bud04:c6; Mar02:DR; Pre04:c8]

    Dijagrami i tabele odluka: koriste se da predstave sloene kombinacije stanja i akcija [Pre04:c11]

    Blok dijagrami i struktuirani blok dijagrami: koriste se da prikau tok kontrole i pridruene akcije koje se izvode [Fre83:VII; Mar02:DR; Pre04:c11]

    Dijagrami sekvenci: koriste se za prikaz interakcija izmeu grupe objekata, sa naglaskom na vremenski redosled poruka [Boo99:c18]

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    6

    Dijagrami stanja i promena toka: koriste se za prikaz kontrole toka od jednog stanja maine u drugo stanje [Boo99:c24; Bud04:c6; Mar02:DR; Jal97:c7]

    Jezici formalne specifikacije: to su tekstualni jezici koji koriste poev od osnovnih pojmova iz matematike (na pr. logiko, skup, izraz) do strogih i apstraktnih definicija softverskih komponenti, interfejsa i ponaanja softvera, esto sa izrazima pre i posle uslova [Bud04:c18; Dor02:v1,c6,s5; Mey97:c11]

    Pseudokod i jezici dizajna programa (PDL): ovo su jezici slino struktuirani kao i programski jezici i koriste se za opisivanje, generalno u stadijumu detaljnog dizajna, ponaanja metoda ili procedura [Bud04:c6; Fre83:VII; Jal97:c7; Pre04:c8,c11].

    6. Strategije i metode dizajna softvera

    Postoje razne vrste optih strategija koje se koriste pri procesu dizajna softvera [Bud04:c9; Mar02:D]. Na suprot ovim strategijama, metode su vie konkretnije, jer obezbeuju skup pojmova koji e biti korien sa datom metodom, opisujui proces koji prati metodu i set uputstava u korienoj metodi [Bud04:c8]. Takve metode su korisne kao sredstvo za transfer znanja i kao uobiajeno radno okruenje za timove softver inenjeringa [Bud03:c8]. Videti alate i metode oblasti znanja softver inenjeringa.

    6.1. Opte strategije Neki esto citirani primeri korisnih strategija u dizajn procesu su zavadi-pa-vladaj, postepeno podeavanje [Bud04:c12; Fre83:V], odozgo-na-dole nasuprot strategiji odozdo-na-gore [Jal97:c5; Lis01:c13], apstrakcija podataka i skrivanje informacija [Fre83:V], upotreba heuristike [Bud04:c8], upotreba uzoraka i jezici uzoraka [Bud04:c10; Bus96:c5], upotreba iterativnog i narastajueg pristupa [Pfl01:c2].

    6.2. Funkcionalno orijentisani (struktuirani) dizajn [Bud04:c14; Dor02:v1c6s4; Fre83:V; Jal97:c5; Pre04:c9,c10] Ovo je jedna od klasinih metoda dizajna softvera, gde je teite na dekompoziciji glavnih softverskih

    funkcija pa onda finom pojanjavanju metodom odozgo-na-dole. Struktuirani dizajn se koristi generalno posle struktuirane analize, to proizvodi, mnoge druge stvari, dijagrame toka podataka i opisivanje pridruenih procesa. Istraivai preporuuju razne strategije (na pr. analizu transformacije, analizu transakcije) i heuristiku (na pr. uticajna oblast nasuprot uticajnoj kontroli) za transformaciju DFD u softversku arhitekturu generalno predstavljenu kroz strukturni tok.

    6.3. Objektno orijentisani dizajn Nekoliko metoda dizajna softvera je bazirano na objektima. Ova oblast se proirila poev od ranih objektno baziranih metoda sredinom 1980-te preko OO dizajna, gde nasleivanje i polimorfizam igraju kljunu ulogu, do dizajna baziran na komponentama, gde je poluinformacija definisana i dostupna (na pr. preko refleksije). Mada OO dizajn vue koren iz koncepta apstrakcije podataka, dizajn koji razmatra ovlaenja se preporuuje kao alternativa ovom dizajnu.

    6.4. Dizajn sa teitem na strukturi podataka [Bud04:c15; Fre83:III,VII; Mar02:D] Ova vrsta dizajna (na pr. Deksonov, Varnije-Orov) poiva na strukturi podataka a manje na funkcijama koje se izvravaju. Softver inenjer prvo opisuje ulaz i izlaz podataka (koristei Deksonov struktuirani dijagram na pr.), a onda razvija kontrolne programske strukture zasnovane na ovim dijagramima podataka. Vie heuristika se preporuije za specijalne sluajeve na pr. kada ne postoji nita izmeu ulaznih i izlaznih struktura.

    6.5. Dizajn baziran na komponentama (CBD) Softverska komponenta je nezavisna jedinica, koja ima dobro definisane interfejse i meuzavisnosti koje mogu da se spajaju ili rastavljaju nezavisno. Ovakav dizajn se odnosi na razvijanje, integraciju i obezbeivanje takvih komponenti od kojih se trai poboljanje ponovnom upotrebom [Bud04:c11].

    6.6. Ostale metode Ostale interesantne ali manje znaajni pristupi takoe postoje: formalne i striktne metode [Bud04:c18; Dor02:c5; Fre83; Mey97:c11; Pre04:c29] i transformacione metode [Pfl98:c2].

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    7

    Matrica naslova i referenci

    [B

    a

    s

    0

    3

    ]

    {

    B

    a

    s

    9

    8

    }

    [

    B

    o

    o

    9

    9

    ]

    [

    B

    o

    s

    0

    0

    ]

    [

    B

    u

    d

    0

    3

    ]

    [

    B

    u

    s

    9

    6

    ]

    [

    D

    o

    r

    0

    2

    ]

    [

    F

    r

    e

    8

    3

    ]

    [

    I

    E

    E

    E

    1

    0

    1

    6

    -

    9

    8

    ]

    [

    I

    E

    E

    E

    1

    0

    2

    8

    -

    9

    7

    ]

    [

    I

    E

    E

    E

    1

    4

    7

    1

    -

    0

    0

    ]

    [

    I

    E

    E

    E

    1

    2

    2

    0

    7

    .

    0

    -

    9

    6

    ]

    [

    I

    S

    O

    9

    1

    2

    6

    -

    0

    1

    ]

    [

    I

    S

    O

    1

    5

    0

    2

    6

    -

    9

    8

    ]

    [

    J

    a

    l

    9

    7

    ]

    [

    L

    i

    s

    0

    1

    ]

    [

    M

    a

    r

    0

    2

    ]

    *

    {

    M

    a

    r

    9

    4

    }

    [

    M

    e

    y

    9

    7

    ]

    [

    P

    f

    l

    0

    1

    ]

    [

    P

    r

    e

    0

    4

    ]

    [

    S

    m

    i

    9

    3

    ]

    1. Osnove dizajna softvera

    1.1. Osnove dizajna softvera

    1.2. Kontekst dizajna softvera

    1.3. Proces dizajna softvera

    1.4. Tehnike realizacije dizajna

    2. Kljuna pitanja dizajna softvera

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    8

    [B

    a

    s

    0

    3

    ]

    {

    B

    a

    s

    9

    8

    }

    [

    B

    o

    o

    9

    9

    ]

    [

    B

    o

    s

    0

    0

    ]

    [

    B

    u

    d

    0

    3

    ]

    [

    B

    u

    s

    9

    6

    ]

    [

    D

    o

    r

    0

    2

    ]

    [

    F

    r

    e

    8

    3

    ]

    [

    I

    E

    E

    E

    1

    0

    1

    6

    -

    9

    8

    ]

    [

    I

    E

    E

    E

    1

    0

    2

    8

    -

    9

    7

    ]

    [

    I

    E

    E

    E

    1

    4

    7

    1

    -

    0

    0

    ]

    [

    I

    E

    E

    E

    1

    2

    2

    0

    7

    .

    0

    -

    9

    6

    ]

    [

    I

    S

    O

    9

    1

    2

    6

    -

    0

    1

    ]

    [

    I

    S

    O

    1

    5

    0

    2

    6

    -

    9

    8

    ]

    [

    J

    a

    l

    9

    7

    ]

    [

    L

    i

    s

    0

    1

    ]

    [

    M

    a

    r

    0

    2

    ]

    *

    {

    M

    a

    r

    9

    4

    }

    [

    M

    e

    y

    9

    7

    ]

    [

    P

    f

    l

    0

    1

    ]

    [

    P

    r

    e

    0

    4

    ]

    [

    S

    m

    i

    9

    3

    ]

    2

    .

    1

    .

    K

    o

    n

    k

    u

    r

    e

    n

    t

    n

    o

    s

    t

    ( i

    s

    t

    o

    v

    r

    e

    m

    e

    n

    o

    s

    t

    )

    2

    .

    2

    .

    K

    o

    n

    t

    r

    o

    l

    a

    i

    o

    b

    r

    a

    d

    a

    d

    o

    g

    a

    a

    j

    a

    2

    .

    3

    .

    D

    i

    s

    t

    r

    i

    b

    u

    c

    i

    j

    a

    k

    o

    m

    p

    o

    n

    e

    n

    t

    i

    2

    .

    4

    .

    G

    r

    e

    k

    e

    i

    r

    u

    k

    o

    v

    a

    n

    j

    e

    i

    z

    u

    z

    e

    c

    i

    m

    a

    i

    t

    o

    l

    e

    r

    i

    s

    a

    n

    j

    e

    g

    r

    e

    a

    k

    a

    2

    .

    5

    .

    I

    n

    t

    e

    r

    a

    k

    c

    i

    j

    a

    i

    p

    r

    e

    d

    s

    t

    a

    v

    l

    j

    a

    n

    j

    e

    ( p

    r

    e

    z

    e

    n

    t

    a

    c

    i

    j

    a

    )

    2

    .

    6

    .

    P

    o

    s

    t

    o

    j

    a

    n

    o

    s

    t

    p

    o

    d

    a

    t

    a

    k

    a

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    9

    [B

    a

    s

    0

    3

    ]

    {

    B

    a

    s

    9

    8

    }

    [

    B

    o

    o

    9

    9

    ]

    [

    B

    o

    s

    0

    0

    ]

    [

    B

    u

    d

    0

    3

    ]

    [

    B

    u

    s

    9

    6

    ]

    [

    D

    o

    r

    0

    2

    ]

    [

    F

    r

    e

    8

    3

    ]

    [

    I

    E

    E

    E

    1

    0

    1

    6

    -

    9

    8

    ]

    [

    I

    E

    E

    E

    1

    0

    2

    8

    -

    9

    7

    ]

    [

    I

    E

    E

    E

    1

    4

    7

    1

    -

    0

    0

    ]

    [

    I

    E

    E

    E

    1

    2

    2

    0

    7

    .

    0

    -

    9

    6

    ]

    [

    I

    S

    O

    9

    1

    2

    6

    -

    0

    1

    ]

    [

    I

    S

    O

    1

    5

    0

    2

    6

    -

    9

    8

    ]

    [

    J

    a

    l

    9

    7

    ]

    [

    L

    i

    s

    0

    1

    ]

    [

    M

    a

    r

    0

    2

    ]

    *

    {

    M

    a

    r

    9

    4

    }

    [

    M

    e

    y

    9

    7

    ]

    [

    P

    f

    l

    0

    1

    ]

    [

    P

    r

    e

    0

    4

    ]

    [

    S

    m

    i

    9

    3

    ]

    3. Struktura i arhitektura softvera

    3.1. Strukture i gledita arhitekture

    3..2. Uzorci dizajna (mikroarhitekturalni primeri)

    3.3. Familije programa i radno okruenje

    4. Analiza kvaliteta i vrednovanje dizajna softvera

    4.1. Osobine kvaliteta

    4.2. Analiza kvaliteta i tehnike vrednovanja

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    10

    [B

    a

    s

    0

    3

    ]

    {

    B

    a

    s

    9

    8

    }

    [

    B

    o

    o

    9

    9

    ]

    [

    B

    o

    s

    0

    0

    ]

    [

    B

    u

    d

    0

    3

    ]

    [

    B

    u

    s

    9

    6

    ]

    [

    D

    o

    r

    0

    2

    ]

    [

    F

    r

    e

    8

    3

    ]

    [

    I

    E

    E

    E

    1

    0

    1

    6

    -

    9

    8

    ]

    [

    I

    E

    E

    E

    1

    0

    2

    8

    -

    9

    7

    ]

    [

    I

    E

    E

    E

    1

    4

    7

    1

    -

    0

    0

    ]

    [

    I

    E

    E

    E

    1

    2

    2

    0

    7

    .

    0

    -

    9

    6

    ]

    [

    I

    S

    O

    9

    1

    2

    6

    -

    0

    1

    ]

    [

    I

    S

    O

    1

    5

    0

    2

    6

    -

    9

    8

    ]

    [

    J

    a

    l

    9

    7

    ]

    [

    L

    i

    s

    0

    1

    ]

    [

    M

    a

    r

    0

    2

    ]

    *

    {

    M

    a

    r

    9

    4

    }

    [

    M

    e

    y

    9

    7

    ]

    [

    P

    f

    l

    0

    1

    ]

    [

    P

    r

    e

    0

    4

    ]

    [

    S

    m

    i

    9

    3

    ]

    4.3. Vrednovanja

    5. Pojmovi dizajna softvera

    5. 1. Strukturalno (statiko) opisivanje

    5. 2. Opis ponaanja softvera (dinamiko opisivanje)

    6. Strategije i metode dizajna softvera

    6.1. Opte strategije

    6.2. Funkcionalno orijentisani (struktuirani) dizajn

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    11

    [B

    a

    s

    0

    3

    ]

    {

    B

    a

    s

    9

    8

    }

    [

    B

    o

    o

    9

    9

    ]

    [

    B

    o

    s

    0

    0

    ]

    [

    B

    u

    d

    0

    3

    ]

    [

    B

    u

    s

    9

    6

    ]

    [

    D

    o

    r

    0

    2

    ]

    [

    F

    r

    e

    8

    3

    ]

    [

    I

    E

    E

    E

    1

    0

    1

    6

    -

    9

    8

    ]

    [

    I

    E

    E

    E

    1

    0

    2

    8

    -

    9

    7

    ]

    [

    I

    E

    E

    E

    1

    4

    7

    1

    -

    0

    0

    ]

    [

    I

    E

    E

    E

    1

    2

    2

    0

    7

    .

    0

    -

    9

    6

    ]

    [

    I

    S

    O

    9

    1

    2

    6

    -

    0

    1

    ]

    [

    I

    S

    O

    1

    5

    0

    2

    6

    -

    9

    8

    ]

    [

    J

    a

    l

    9

    7

    ]

    [

    L

    i

    s

    0

    1

    ]

    [

    M

    a

    r

    0

    2

    ]

    *

    {

    M

    a

    r

    9

    4

    }

    [

    M

    e

    y

    9

    7

    ]

    [

    P

    f

    l

    0

    1

    ]

    [

    P

    r

    e

    0

    4

    ]

    [

    S

    m

    i

    9

    3

    ]

    6.3. Objektno orijentisani dizajn

    6.4. Dizajn sa teitem na strukturi podataka

    6.5. Dizajn baziran na komponentama (CBD)

    6.6. Ostale metode

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    12

    Preporuene refernce za dizajn softvera

    [BCK98] L. Bass, P. Clements I R. Kazman. Arhitektura softvera u praksi, Addison Wesley. Novi i vodei posao u arhitekturi softvera. To obuhvata sve bitne teme u vezi sa softver arhitekturom: ta je arhitektura softvera, osobine kvaliteta, stilovi arhitekture, osposobljeni koncepti i tehnike (zvane pojedinane operacije), jezici opisa arhitekture, razvoj proizvodnih linija, itd. Stavie, predstavlja odreeni broj sluajeva istraivanje ilustrujui glavne arhitektonske koncepte, obuhvatajui poglavlje CORBA i jedno u WWW. Neki odeljci takoe adresiraju izdanja proizvodnih linija dizajna.

    [BMR+96] F. Buschmann, R. Mennier, H. Rohnert, P. Sommerlad i M. Stal , ablonski orijentisan softver arhitekture sistem ablona, J. Wiley i Sons. Jedan od najboljih i najjasnijih predstavljanja pojmova softver arhitekture i ablona (arhitektonski i jedan nii nivo). Posebna poglavlja su posveena arhitektonskim ablonima, dizajnu ablona i idioma niih nivoa. Druga poglavlja razmatraju veze izmeu ablona, softver arhitekture, metoda, okvira itd. Ovo poglavlje obuhvata kratku prezentaciju osposobljenih tehnika za softver arhitekturu, na primer, apstrakcija, enkapsulacija, skrivanje informacija, sparivanje I kohezija, itd.

    [Bos00] J. Bosch, Dizajn i upotreba arhitektura softvera promene i prosirenja prilaza proizvodu linija, ACM novine. Prvi deo knjige je o dizajnu softver arhitektura i predlozima prilaza na funkcionalnoj osnovi, povezanih sa naknadnim fazama procenjivanja i transformacije kao posledica arhitekture. Ove transformacije su izraene na osnovu uslova razliitih nivoa ablona (arhitektonski stilovi, arhitektonski abloni i dizajn ablona) i dodira koji oni imaju sa vie kljunih faktora kvaliteta (predavanja, podranost, sigurnost i pouzdanost). Drugi deo knjige je specifiniji za dizajn proizvodnih linija softvera, ukljuujui celo poglavlje OO okvira.

    [BRJ99] G. Booch, J. Rumbaugh, and I. Jacobson. Jedinstveni korisniki Vodi jezika modeliranja, Addison Wesley. Obuhvatna i potpuna prezentacija raznovrsnih elemenata UML-a, koja sjedinjuje mnoga objanjenja spomenuta u odeljku Objanjenje Softver Dizajna.

    [Bud94] D. Budgen. Softver dizajn, Addison Wesley. Jedna od nekoliko knjiga koje razmatraju softver dizajn poznatih autora SD KA opisa moda samo jedna koja je niti opti dnevnik softver dizajna niti opisna knjiga specifinih metoda softver dizajna. Ovo je verovatno knjiga koja se pribliava duhu sadanjeg KA opisa softver dizajna, kao njegove razmatrane teme, kao na primer sledee: priroda dizajna; proces softver dizajna; kvaliteti dizajna; gledita dizajna; predstavljanje dizajna; strategije i metode dizajna (ukljuujui kratka predstavljanja za vie takvih metoda, npr. JSP, SSASD, JSD, OOD,

    itd.). Vredno pronalaenja, u jednoj knjizi, mnogih pojmova, izbora i pribora za/o softver dizajn /u.

    [DT97] M. Dofman I R.H. Thayer (itd.) Softver inzenjering, IEEE kompijutersko udruzenje. Ova knjiga sadrzi kolekciju dokumenata softver inenjeringa uopte. Dva poglavlja su u specificnoj vezi sa softver dizajnom. Jedan od njih sadri op{ti uvod u softver dizajn, kratko predstavljajui proces softver dizajna i pojmove metoda i gledista dizajna za softver dizajn. Drugo poglavlje sadri uvod za predmetno orijentisani dizajn i poreenje za neke zanimljive OO metode. Sledei lanovi su delimicno zanimljivi za softver dizajn:

    D. Budgen, Softver dizajn: U uvodu, strane 104 115.

    L.M. Northrop, Predmetno orijentisan razvoj, strane 148 159.

    A.G. Sutcliffe, Predmetno orijentisani sistemi razvoja: Pregled strukturnih metoda, strane 160 169.

    C. Ashworth, Analize strukturnih sistema I dizajna metode (SSADM), strane 170 180.

    R. Vienneau, Pregled formalnih metoda, strane 181 192.

    J.D. Palmer, Usmerenost, strane 266 276.

    [FW83] P. Freeman I A.I. Wasserman. Pouavanje tehnikam softver dizajna, cetvrto izdanje, IEEEnovine kompijuterskog udruzenja. Iako je ovo stara knjiga, ona je zanimljiva zato to je dozvolila bolje razumevanje razvoja polja softver dizajna. Ova knjiga je kolekcija dokumenata gde svaki dokument predstavlja tehniku softver dizajna. Udaljenost tehnika od osnovnih strategija je slina koraanju ka finom vladanju, na vreme, finijih metoda kao na primer strukturi dizajn Yourdon I Constantine. Istorijski bitne reference. Sledeci lanovi su delimino zanimljivi:

    P. Freeman, Osnove dizajna, strane 2 22. D.L. Parnas, Kriterijum koji ce se koristiti u

    dekompozicionim sistemima unutar merila, strane 304 309.

    D.L. Parnas, Dizajniranje softvera za lake produavanje I skracivanje, strane 310 320.

    G. Booch, predmetno orijentisan dizajn, strane 420 436.

    W.P. Stevens, G.J. Myers I L.L. Constantine, Strukturni dizajn, strane 328 352.

    S.H. Caine I E.K. Gordon, PDL Alati za softver dizajn, strane 485 490.

    C.M. Yoder I M.L. Schrag, Nassi Schneiderman karte: Alternative karata toka za dizajn, strane 506 513.

    M.A. Jackson, Konstruktivne metode za program dizajna, strane 514 532.

    N. Wirth, Program razvoja korak po korak do finoce, strane 533 539.

    P. Freeman, U cilju unapreenja pregleda softver dizajna, strane 542 547.

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    13

    M.E. Fagan, Ispitivanja plana I pravila za smanjenje gresaka u razvojnom programu, strane 548 576.

    [IEE98] IEEE Std 1016-1998. IEEE preporueni postupak za opise softver dizajna. Ovaj dokument opisuje informacioni sadraji preporuenu organizaciju koj bi trebalo koristiti za opise softver dizajna. Opisne osobine entiteta dizajna su kratko opisane: identifikovanje, tip, svrha, funkcija, interfejsi, zavisnosti, izvori, osnovni i procesni. Zatim je objanjeno kako bi ove razliite elemente trebalo organizovati.

    [ISO95b] ISO/IEC Std 12207. Informaciona tehnologija Procesi ivotnog ciklusa softvera. Detaljan opis ISO/IEC- 12207 ivotnog ciklusa modela. Jasno pokazuje gde je poloaj softver dizajna u celokupnom razvoju ivotnog ciklusa softvera.

    [JAL97] P. Jalote. Potpun pristup softver inenjeringu, drugo izdanje, Springer- Verlag. Opti dnevnik softver inenjeringa je sa dobrim pokriem za softver dizajn, jer tri poglavlja raumatraju ovu temu: jedno funkcionalno orijentisani dizajn, drugo predmetno orijentisani dizajn, u tree detaljan dizajn. Druga zanimljiva stvar je da sva ova poglavlja imaju odeljak mere i metrike.

    [LG01] B. Liskov I J. Guttag. Program razvoja u Javi apstrakcija, specifikacija i predmetno orijentisan dizajn,Addison-Wesley, 2000. Java verzija, klasine knjige, za upotrebu apstrakcije i specifikacije u razvoju softvera [LG86]. Ova nova knjiga jo uvek razmatra, na jasan i potpun nain, proceduralane pojmove za injenice prema kontroli apstrakcije. Takoe istie vanost specifikacije prilaza za ove apstrakcije, mada je ona sada uraena neformalno (sa oznaenim pre./nak.uslovima u stilu Clu [LG86]. Knjiga takoe obuhvata poglavlje o dizajnu ablona. Veoma dobro predstavljanje za neke od osnovnih pojmova dizajna.

    [Mar94] J.J. Marciniak. Enciklopedija softver inenjeringa. J. Wiley I sinovi. Opta enciklopedija o sofver inenjeringu koja obuhvata (najmanje) tri zanimljiva lana za razmatranje softver dizajna. Prvi, dizajn (K.Shumate), je uopte vie od shvatanja dizajna razmatrajui alternative procesa razvoja (na pr., vodopad, spirala, prototip), metode dizajna (strukturne, usredsreene na podatke, modularne, predmetno orijentisane). Neka pitanja koja su u vezi sa konkurencijom su takoe pomenuta. Drugi razmatra dizajn distributivnih sistema (R.M. Adler): modeli veza, klijent-posluitelj i slube modela. Trei, Predstavljanje dizajna (J. Ebert), pokazuje vie pristupa predstavljanju dizajna. Jasno je da to nije detaljna prezentacija za neki metod; ipak, interesantno je zbog toga to pokuava eksplicitno identifikovati, za svaku takvu metodu, vrstu komponenata i veza kori}enih za vreme predstavljanja.

    [Mey97] B. Meyer. Predmetno orijentisana konstrukcija softvera (drugo izdanje), Prentice Hall, 2000. Detaljna prezentacija Eiffel OO jezika i njegove povezanosti sa Dizajn po ugovoru pristupom, koji se zasniva na upotrebi formalnih izjava (pret. / nak. uslova, in varijanti, itd.). On iznosi osnovne koncepte OO dizajna, uz razmatranje mnogih od kljunih pitanja koji su u vezi sa softver dizajnom, na pr., korisniki interfejs, konkurencija, izuzetci i trajanje.

    [Pfl98] S.L. Pfleeger. Softver inenjering teorija i praksa, Prentice Hall. Opta knjiga softver inenjeringa sa jednim poglavljem je posveena dizajnu. Kratko predstavlja i razmatra neke od glavnih arhitektonsih stilova I strategija I neke od koncepata koji su dovedeni u vezu sa pitanjima o konkurenciji. Drugi odeljak predstavlja pojmove udruivanja i kohezije, takoe se bavi problemom manipulisanja izuzetcima. Tehnike za unapreenje i procenjivanje dizajna su takoe predstavljene: dizajn po ugovoru, prototip, pregledi. Mada ovo poglavlje se nije udubilo u bilo koju temu, moe biti zanimljiva polazna taka za vise rezultata koji nisu razmatrani u nekim drugim optim dnevnicima softver inenjeringa.

    [Pre04] R.S. Pressman. Softver inenjering praktiarski pristup (esto izdanje), McGraw Hill. Klasini opti dnevnik softver inenjeringa (esto izdanje). On sadri preko 10 poglavlja koja se bave pojmovima u vezi sa softver dizajnom na jedan ili drugi nain. Osnovni koncepti I metode dizajna su predstavljeni u dva posebna poglavlja. tavie, teme koje se odnose na funkcionalno baziranom pristupu su odvojene (deo III) od onih koje se odnose na predmetno orijentisan pristup (deo IV). Nezavisna poglavlja su i dalje posvena merama pogodnim za svaki od ovih pristupa, specifini adresirani odeljak za specifine mere dizajna. Poglavlje razmatra formalne metode i druge sadanje Clean-room pristupe. Konano, drugo poglavlje razmatra klient posluitelj sisteme i distribuciona reenja.

    [SB93] G. Smith i G. Browne. Konceptualne fondacije za reavanje problema dizajna, IEEE transakcije sistema, ovek i kibernetike, br. 5 sep. okt. 1993, strane 1209 1219. Dokument koji razmatra ta je uopte dizajn. Specifinije, on prikazuje pet osnovnih koncepata dizajna: ciljeve, alternative, prezentacije, prinude I reenja. Bibliografija je dobra polazna taka za dobijanje dodatnih referenci dizajna uopte.

  • DIZAJN SOFTVERA______________________________________________________________________

    Sreko Babi, Automatika IMP _______________________ decembar/05-februar/06.

    14

  • DIZAJN SOFTVERA_____________________________________________________

    Sreko Babi, Automatika IMP _______________________april-decembar/06

    15

    Dodatak A. Lista dodatne literature

    [Boo94] G. Booch. Predmetno orijentisane analize i dizajn sa aplikacijama, drugo izdanje. Klasina u oblasti OOD a. Knjiga predstavlja vie pojmova koji bi trebalo da budu deo UML a (iako ponekad sa manjim izmenama): klase prema predmetnim dijagramima, dijagrami interakcija, karte stanja kao dijagrami, moduli i razvijanje procesa strukture dijagrama, itd. Takoe predstavlja proces korisen za OOA i OOD, proces na visokom nivou i proces na niem nivou (mikro). (Napomenimo da se tree izdanje ove knjige oekuje.)

    [Cro84] N. Cross. Razvoji u dizajn metodologiji. Ova knjiga je sastavljena od serija dokumenata u vezi sa dizajnom uopte, to je, dizajn u kontekstima razliitim od softvera. Jo uvek, mnogi pojmovi I principi su razmatrani u nekim od ovih dokumenata koji su priblini softver dizajnu, npr. ideja za reavanje opasnih problema dizajna.

    [CY91] P. Coad I E. Yourdon. Predmetno orijentisan dizajn. On je jo uvek jedan od klasinih u oblasti OOD primetimo da je drugi autor jedan od tvoraca klasinog strukturnog dizajna. OOD razvojni model sa pristupom naslednika se sastoji od sledee etri komponente koje pokuavaju da se odvoje meutim, nekim od kljunih rezultata se mora rukovoditi: problem delokruga, ljudske interakcije, zadatak menadmenta i menadment podaci.

    [CY91] D.F. Dsouza i AC. Wills. Predmeti, komponente, okviri sa UML om Kataliza pristupa. Savreno predstavljanje specifinog OO pristupa sa isticanjem komponenti dizajna. Pojmovi komponenti i konektora su predstavljeni i ilustrovani sa raznovrsnim pristupima (Java Beens, COM, Corba); kako koristiti takve komponente u razvoju okvira je takoe razmatrano. Drugo poglavlje razmatra razliite aspekte softver arhitekture. Poslednje poglavlje predstavlja sistem ablona za bavljenje sa dizajnom na niskom nivou i detaljnim dizajnom, poslednji nivo u pribliavanju mnogim kljunim pitanjima dizajna kao na primer konkurencija, distribucija, nezavisni dijalozi, itd.

    [FOW99] M. Fowler. Refaktorizacija Poboljsanje postojecih pravila dizajna. Knjiga o tome kako poboljati neka postojea (predmetno orijentisana) pravila za dizajn. Prvo poglavlje je jasan i ilustrovan primer za pristup. Poddeo poglavlja prikazuje razlicite vrste strategija, na pr., metode ureivanja, kretanje karakteristika meu predmetima, organizacije podataka, uproavanje zavisnih izraza, izrada metoda zvanih prostim.

    [FP97] N.E. Fenton i S.L. Pfleeger. Metrike softvera Rigorozan i praktian pristup (drugo izdanje). Ova knjiga sadri detaljno predstavljanje brojnih softver mera i metrika. Mada mere koje je neophodno predstaviti na osnovu razvojnog ivotnog ciklusa softvera, mnoge od ovih mera,

    posebno one u poglavlju 7 i 8, su pogodne za softver dizajn.

    [GHJV95] E. Gamma. Diyajn uzoraka Elementi upotrebljenog predmetno orijentisanog softvera. Povrsan posao na dizajnu uzoraka. Detaljan katalog uzoraka je veinom u vezi sa nivoom mikro arhitekture.

    [Hut94] A.T.F. Hutt. Predmetne analize i dizajn Opis metoda. Predmetne analize i dizajn Poreenje metoda. Ove dve knjige opisuju (prva knjiga) i porede (druga knjiga), na saet nain, veliki broj OO analiza i metoda dizajna. Koristan kao polazna tacka za dobijanje dodatnih korisnih saveta i referenci za OOD metode, ne kao najdetaljnija prezentacija ovih metoda.

    [IEE90] IEEE 610.12 1990. IEEE Renik standarda terminologije softver inenjeringa. Ovaj standard nije specifino usmeren na softver dizajn, to je zato to nije bio ukljuen meu preporuene reference. On opisuje i kratko objanjava mnoge od zajednikih termina korienih na polju softver inenjeringa, ukljuujui mnoge termine softver dizajna.

    [ISO91] ISO/IEC 9126. Informaciona tehnologija Procenjivanje proizvoda softvera Karakteristike kvaliteta i uputstva za upotrebu. Ovaj standard opisuje est karakteristika na visokom nivou koje opisuju kvalitet softvera: funkcionalnost, pouzdanost, korisnost, efikasnost, podranost, prenosivost.

    [JBR+91] J. Rumbaugh. Objektno orijentisano modeliranje i dizajn Ova knjiga je jo jedna od klasinih na polju OOA i OOD. Ona je prva predstavila odvojenost izmeu objekta, dinamikog i funkcionalnog modeliranja. Mada, nasuprot njihovom isticanju uglavnom na dizajnu, ovde je isticanje neznatno vie na analizama, iako je vie elemenata u vezi sa dizajnom takoe.

    [JBR99] I. Jacobson, G. Booch i J. Rumbaugh. Jedinstveni procesi razvoja softvera. Detaljno i savreno predstavljanje jedinstvenog procesa razvoja softvera predloenog od praktine softver korporacije. Pojam arhitekture igra glavnu ulogu u ovom procesu razvoja, proces, moe se rei postaje usredsreen na arhitekturu. Mada, srodan pojam arhitekturi koji tei da bude manje razliit od tradicionalnog baziranog na dizajnu: opis arhitekture treba da sadri izbore ne samo iz modela dizajna ve takoe iz korisnih sluajeva razvoja i implementacionih modela. Celo poglavlje je posveeno predstavljanju iterativnog i dodatnog pristupa za razvoj softvera. Dugo poglavlje je posveeno samom dizajnu, iji je cilj da stvara oba modela dizajna, koji ukljuuje logine (na pr., dijagrame klasa, kolaboracije, itd.) i procesne izbore i modele razvoja (fiziko reenje).

    [Kru95] P.B. Kruchten. 4+1 model arhitekture.

  • DIZAJN SOFTVERA_____________________________________________________

    Sreko Babi, Automatika IMP _______________________april-decembar/06

    16

    Dokument koji objasnjava na jasan i potpun nain vanost mogunosti vie izbora za opisivanje arhitekture. Ovde, arhitektura je shvaena u smislu koji je pomenut ranije u referenci [JBR99], ne na njegov ogranien dizajn relacioni nain. Prva etri izbora razmatrana u dokumentu su logiki, procesni, razvojni i fiziki izbori dok je peti korisniki sluaj koji povezuje predhodne izbore. Izbori koji su prisnije povezani sa softver dizajnom su logiki i procesni.

    [Lar98] C. Larman. Primena UML-a i uzoraka predstavljanje objektno orijentisanih analiza i dizajna. Uvodna knjiga koja obuhvata objektno orijentisane analize i dizajn radei tako u toku prouavanja sluaja u celoj knjizi. Delovi IV i VII su posveeni fazama dizajna. Oni prdstavljaju vie ablona voenja odgovornog zadatka za klase i predmete. Razliita reenja koja se tiu dizajna su takoe adresirana na pr., arhitektura sa mnogo nivoa, model razdvajanja re{enja. Uzorci [GHJV95] su takoe ispitani u kontekstu prouavanja sluajeva.

    [McC93] S. McConnell. Potpun pravilnik. Mada je ova knjiga verovatno blie u vezi sa konstrukcijom softvera, ona sadri odeljak za softver dizajn sa vie interesantnih poglavlja, npr. Karakteristike visoko kvalitetne rutine , Tri od etri programera su prouavali cenjene module, Visoki nivo dizajna u konstrukciji. Jedno od ovih poglavlja (Karakteristike [...]) sadri zanimljivu diskusiju o upotrebi tvrdnji u duhu Mayer-sovog Dizajna po ugovoru; drugo poglavlje (Tri [...]) razmatra koheziju i povezivanje kao i skrivanje informacija; tree poglavlje (Visoki nivo [...]) daje kratak uvod u neke metodologije dizajna (strukturni dizajn, OOD).

    [otSESC98] Plan preporuene prakse za informacione tehnologije sistem dizajna arhitektonski opis. Tehniki izvetaj IEEE P1471 / D4.1. Ove preporuene prakse stvaraju konceptualan okvir za arhitektonski opis. Ovaj okvir obuhvata aktivnosti ukljuene u stvaranje, analize i trajnosti arhitektura u softver jakim sistemima i beleenje takvih arhitektura kao u opisima. (Sa stanovita apstrakcije)

    [Pet92] H. Petroski. I inenjer je ovek uloga u opadanju uspeha dizajna. Ova knjiga nije o samom softver dizajnu. Autor, inenjer, razmatra kako dizajner,inenjer moe i treba da ui iz predhodnih opadanja i kako bi trebalo gledati na dizajn kao vrstu hipoteza koje e biti proverene. Zanimljivo, imajui u vidu da je softver dizajn jedini izvan 10 oblasti znanja za softver inenjering, autor je dizajn i inenjering posmatrao kao stvarne sinonime.

    [PJ00] M. Page Jones. Osnove objektno orijentisanog dizajna u UML-u. Trei deo ove knjige (Principi objektno orijentisanog dizajna) adresira vie pogodnih tehnika u specifinom kontekstu OO dizajna. Ovaj deo knjige sadri poglavlja, kao na primer sledea: Enkapsulacija i podizanje; oblasti, prepreke i

    kohezija; tipovi pogodnosti i zatvoreno ponaanje; opasnosti u inherenciji i polimorfizmu. Knjiga takoe sadri poglavlje za dizajn komponenti softvera.

    [Pre95] W. Pree. Dizajn uzoraka za objektno orijentisan razvoj softvera. Ova knjiga je delimino zanimljiva zbog njenog razmatranja upotrebe okvira dizajna, to je nazvano Opasna vonja pristup za okvire dizajna. Specifinija tema o dizajnu uzoraka je bolje adresirana u [BMR+96].

    [Rei96] A.J. Riel. Objektno orijentisan dizajn heuristika (pronalazake metode) Ova knjiga koja je u glavnom usmerena na OO dizajn, razmatra veliki broj heuristika koje se mogu koristiti u dizajnu softvera. Ove heuristike daju irok opseg reenja za oba nivoa dizajna, arhitektonski i detaljni.

    [SG96] M. Shaw, D. Garlan. Softver arhitektura: perspektive za nastupajue discipline. Jedna od ranih knjiga za arhitekturu softvera koja adresira mnoge predmete u temama: arhitektonski stilovi (ukljuujui poglavlja sa manjim opisima znanja), delovi informacionih sistema, korisniki interfejs, formalne specifikacije, lingvistika reenja, alati i obrazovanje.

    [Som95] I. Sommerville. Inenjering softvera (peto izdanje). Addison Wesley, 1995. Trei deo je posveen softver dizajnu, dajui svoja gledita na vie tema kroz sledea poglavlja: proces dizajna, arhitektonski dizajn, OO dizajn, funkcionalni dizajn. (Napomena: esto izdanje se ve moe nabaviti.)

  • DIZAJN SOFTVERA_____________________________________________________

    Sreko Babi, Automatika IMP _______________________april-decembar/06

    17

    Dodatak B. Lista standarda

    [BCK98] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. SEI Series in Software Engineering. Addison-Wesley, 1998.

    [BDA+98] P. Bourque, R. Dupuis, A. Abran, J.W. Moore, L. Tripp, J. Shyne, B. Pflug, M.Maya, and G. Tremblay. Guide to the software engineering body of knowledge a straw man version. Technical report, Dpt. dInformatique,UQAM, Sept. 1998.

    [BMR+96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-oriented Software Architecture A System of Patterns. John Wiley & Sons, 1996.

    [Boo94] G. Booch. Object Oriented Analysis and Design with Applications, 2nd ed. The Benjamin/Cummings Publis hing Company, Inc., 1994.

    [Bos00] J. Bosch. Design & Use of Software Architecture Adopting and Evolving a Product-line Approach. ACM Press, 2000.

    [BRJ99] G. Booch, J. Rumbauch, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1999.

    [Bud94] D. Budgen. Software Design. Addison-Wesley, 1994.

    [Cro84] N. Cross (ed.). Developments in Design Methodology. John Wiley & Sons, 1984.

    [CY91] P. Coad and E. Yourdon. Object-Oriented Design. Yourdon Press, 1991.

    [DeM99] T. DeMarco. The Paradox of Software Architecture and Design. Stevens Prize Lecture, August 1999.

    [DT97] M. Dorfman and R.H. Thayer. Software Engineering. IEEE Computer Society Press, 1997.

    [DW99] D.F. DSouza and A.C. Wills. Objects, Components, and Frameworks with UML The Catalysis Approach. Addison-Wesley, 1999.

    [Fow99] M. Fowler. Refactoring Improving the Design of Existing Code. Addison-Wesley, 1999.

    [FP97] N.E. Fenton and S.L. Pfleeger. Software Metrics A Rigorous & Practical Approach (Second Edition). International Thomson Computer Press, 1997.

    [FW83] P. Freeman and A.I. Wasserman. Tutorial on Software Design Techniques, fourth edition. IEEE Computer Society Press, 1983.

    [GHJV95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns Elements of Reusable Object-Oriented Software. Professional Computing Series. Addison-Wesley, 1995.

    [Hut94] A.T.F. Hutt. Object Analysis and Design Comparison of Methods. Object Analysis and Design Description of Methods. John Wiley & Sons, 1994.

    [IEE88] IEEE. IEEE Standard Dictionary of Measures to Produce Reliable Software. IEEE Std 982.1-1988, IEEE, 1988.

    [IEE88b] IEEE. IEEE Guide for the Use of Standard Dictionary of Measures to Produce Reliable Software. IEEE Std 982.2-1988, IEEE, 1988.

    [IEE90] IEEE. IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 610.12-1990, IEEE, 1990.

    [IEE98] IEEE. IEEE Recommended Practice for Software Design Descriptions. IEEE Std 1016-1998, IEEE, 1998.

    [ISO91] ISO/IEC. Information technology Software product evaluation Quality characteristics and guidelines for their use. ISO/IEC Std 9126: 1991, ISO/IEC, 1991.

    [ISO95] ISO/IEC. Open distributed processing Reference model. ISO/IEC Std 10746: 1995, ISO/IEC, 1995.

    [ISO95b] ISO/IEC. Information technology Software life cycle processes. ISO/IEC Std 12207: 1995, ISO/IEC, 1995.

    [Jal97] P. Jalote. An Integrated Approach to Software Engineering, 2nd ed. Springer, 1997.

    [JBP+91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice-Hall, 1991.

    [JBR99] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison-Wesley, 1999.

    [JCJO92] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering A Use Case Driven Approach. Addison-Wesley, 1992.

    [KLM+97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. Aspectoriented programming. In ECOOP 97 Object-Oriented Programming, pages 220-242. LNCS-1241, Springer- Verlag, 1997.

    [Kru95] P.B. Kruchten. The 4+1 view model of architecture. IEEE Software, 12(6):4250, 1995.

    [Lar98] C. Larman. Applying UML and Patterns An introduction to Object-Oriented Analysis and Design. Prentice-Hall, 1998. [LG86] B. Liskov and J. Guttag. Abstraction and Specification in Program Development. The MIT Press, 1986.

  • DIZAJN SOFTVERA_____________________________________________________

    Sreko Babi, Automatika IMP _______________________april-decembar/06

    18

    [LG01] B. Liskov and J. Guttag. Program Development in Java Abstraction, Specification, and Object-Oriented Design. Addison-Wesley, 2001. [Mar94] J.J. Marciniak. Encyclopedia of Software Engineering. John Wiley & Sons, Inc., 1994.

    [McCr93] S. McConnell. Code Complete. Microsoft Press, 1993.

    [Mey97] B. Meyer. Object-Oriented Software Construction (Second Edition). Prentice-Hall, 1997.

    [OMG98] OMG. The common object request broker: Architecture and specification. Technical Report Revision 2.2, Object Management Group, February 1998.

    [OMG99] UML Revision Task Force. OMG Unified Modeling Language specification, v. 1.3. document ad/99- 06-08, Object Management Group, June 1999.

    [otSESC98] Architecture Working Group of the Software Engineering Standards Committee. Draft recommended Dractice for information technology System design Architectural description. Technical Report IEEE P1471/D4.1, IEEE, December 1998.

    [Pet92] H. Petroski. To Engineer is Human The role of failure in successful design. Vintage Books, 1992.

    [Pfl98] S.L. Pfleeger. Software Engineering Theory and Practice. Prentice-Hall, Inc., 1998.

    [PJ00] M. Page-Jones. Fundamentals of Object-Oriented Design in UML. Addison-Wesley, 2000.

    [Pre95] W. Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley and ACM Press, 1995.

    [Pre97] R.S. Pressman. Software Engineering A Practitioners Approach (Fourth Edition). McGraw-Hill, Inc., 1997.

    [Rie96] A.J. Riel. Object-Oriented Design Heuristics. Addison-Wesley, 1996.

    [SB93] G. Smith and G. Browne. Conceptual foundations of design problem-solving. IEEE Trans. on Systems, Man, and Cybernetics, 23(5):12091219, 1993.

    [SG96] M. Shaw, D. Garlan. Software architecture: Perspectives on an emerging discipline. Prentice-Hall, 1996 .

    [Som95] I. Sommerville. Software Engineering (fifth edition). Addison-Wesley, 1995.

    [WBWW90] R. Wirfs-Brock, B. Wilkerson, and L. Wiener. Designing Object-Oriented