BAZA ZNANJA

Kurs: Softverski dizajn

Modul: Uvod u softverski dizajn

Autor: Test Instruktor

Naziv jedinice: Osnove softverskog dizajna

U ovoj lekciji obrađivaćemo:

• Pojam softverskog dizajna
• Aktivnosti softverskog dizajna
• Pojam modularnog dizajna
• Ostvarivanje pratljivosti
• Opšti model softverskog dizajna
  
• Software Structure and Architecture

Softverski dizajn uključuje identifikaciju komponenata softverskog dizajna, njihov unutrašnji rad i njihov interfejs, na osnovu Software Requirement Specification (SRS) dokumenta. Osnovni artifakt ove aktivnosti je software design specification (SDS), koji se često naziva i software design description (SDD).

Koje su osnovne aktivnosti softverskog dizajna?

Tokom dizajn aktivnosti, softver inženjer mora dizajnirati softversku arhitekturu, što uključuje sledeće aktivnosti:

• Izvodjenje hardver/softver analize i balansa
• Dizajniranje interfejsa ka eksternim komponentama
• Dizajniranje interfejsa između komponenti
• Odluka o centralizovanoj ili distribuiranoj šemi
• Odlučivanje o konkurentnosti izvršavanja
• Dizajniranje kontrolnih strategija
• Odluka o smeštanju podataka i održavanju
• Dizajniranje baza podataka i struktura i rutina za rukovanje
• Dizajniranje procesa uključivanja i isključivanja sistema
• Dizajniranje algoritama i funkcionalnog procesiranja
• Dizajniranje procesa rukovanja greškama
• Sprovodjenje analize performansi
• Specificiranje fizičke lokacije komponenti i podataka
• Kreiranje dokumentacije sistema
• Sprovodjenje internih pregleda
• Sprovodjenje detaljnog dizajna za komponente identifikovane u softverskoj arhitekturi
• Dokumentovanje softverske arhitekture u formi SDS
• Prezentovanje detaljnih dizajn informacija na formalnim pregledima dizajna
  

Slika 1.

Ovo je značajan broj taskova koje je potrebno uraditi, a kao dodatak, većina navedenih aktivnosti se može dešavati paralelno sa ostalima ili ponavljati nekoliko puta. Jedna osoba nije u mogućnosti da sama uradi sve navedeno, pa se često formiraju timovi koji rade na aktivnostima softverskog dizajna. Samim tim, timski rad i saradnja igra značaju ulogu u uspešnom obavljanju posla.

Ne postoji generalni recept ili pravilo za kompletiranje navedenih aktivnosti softverskog dizajna. Umesto toga, zahteva se primena prakse stečenog tokom godina rada i iskustva na prethodnim projektima.

Slika 2.

Modularni dizajn

Na slici 3 je prikazana modularna dokompozicija. Ukoliko govorimo o proceduralnom aspektu, strelice predstavljaju ulaze i izlaze, a blokovi podatke i procedure. Ukoliko govorimo o objektno orijentisanom pristupu, strelice predstavljaju poruke, a blokovi klase.

Modularni dizajn je prvi put predstavljen 1972 i uključuje dekompoziciju softverskog ponašanja u enkapsulirane softverske jedinice. Modularnost je postignuta grupisanjem logički povezanih elemenata, kao što su iskazi, procedure, deklaracije varijable, atributi objekata, itd.

Slika 3. Modularna dekompozicija ^[1]

Dizajn dokumentacija

Postoji veliki broj različitih varijacija za SDS (software design specification). Jedan od njih je definisan standardom: IEEE Standard 1016-1998, IEEE Recommended Practice for Software Design Descriptions. Međutim, danas veliki broj kompanija koriste različite obrasce za ovu dokumentaciju.

Ostvarivanje pratljivosti

Radi uspešnog praćenja zahteva, od usvojene dokumentacije zahteva, kroz dizajn do kodiranja, najčešće se koristi numerički sistem označavanja kroz dokumentaciju. Na slici 4 je prikazan jedan od načina za efikasno praćenje i referenciranje kroz dokumentaciju. Sam način notacije kroz više nivoa (u primeru sa slike 4 označen sa 3.2.2.1) zavisi od sistema i konvencije u samoj organizaciji.

Slika 4. Linkovi izmedju softverske dokumentacije i koda ^[1]

Navedena grafička ilustracija na slici 4, pomaže u razumevanju procesa praćenja. U praksi, koristi se matrica praćenja radi pomoći u uzajamnom referenciranju dokumentacije i koda. Matrica se pravi tako što se u kolone smešta naziv odgovarajuće dokumentacije ili kodne jedinice, a u vrste softverski zahtevi. Primer matrice praćenja dat je na slici 5.

Slika 5. Matrica praćenja sortirana prema broju zahteva ^[1]

Opšti model softverskog dizajna

Sam proces softverskog dizajna može se ilustrovati kao na slici 6. Ulaz u ovaj proces čine zahtevi iz dokumenta zahteva, dok izlaz predstavlja skup specifikacija koje opisuju formu programskih komponeneti. 

Slika 6. Opšti model procesa softverskog dizajna ^[2]

Međutim, ovaj prikaz je prilično idealizovan pa proces razvoja dizajna softvera možemo prikazati kao na slici 7. U prvoj fazi dizajneri razvijaju apstraktni model rešenja. Ovo je inicijalno black box particionisanje problema koje se bavi prirodom i formom samog problema, a ne formom rešenja. U drugoj fazi, apstrakti elementi problema koji su identifikovani u prvoj fazi se mapiraju na tehnologiju rešenja, prevodeći black box strategiju u white box model.

Reference:

1. Phillip A. Laplante, What Every Engineer Should Know about Software Engineering, CRC Press, 2007
2. David Budgen, Software design, Addison Wesley, 2003