Softverski dizajn je proces kojim agent stvara specifikaciju softverskog artefakta, sa namerom da ostvari ciljeve, koristeći skup primitivnih komponenti i predmet ograničenja.[1] Softverski dizajn se može odnositi na bilo "sve aktivnosti koje su uključene u konceptualizaciju, kadriranje, implementaciju, puštanje u rad, i na kraju modifikovanje složenih sistema" ili "aktivnost sledećih zahteva specifikacije i pre programiranja, kao ... u stilizovanom softverskom inženjerskom procesu. "[2]

Softverski dizajn obično uključuje rešavanje problema i planiranje softverskog rešenja. Ovo uključuje i komponente niskog nivoa i algoritamski dizajn i visok nivo, arhitektura.

Pregled uredi

Softverski dizajn je proces sprovođenja softverskih rešenja za jedan ili više skupova problema. Jedan od važnih delova softverskog dizajna je analiza softverskih zahteva (SRA). To je deo procesa razvoja softvera koji navodi specifikacije koje se koriste i softverskom inženjerstvu. Ako je softver "poluautomatski" ili korisnički centriran, dizajn softvera može da podrazumeva korisničko iskustvo dizajna stvarajući storiboard da bi se utvrdile te specifikacije. Ako je softver potpuno automatizovan (znači nema  korisnički interfejs), dizajn softvera može biti jednostavan kao dijagram toka ili tekst koji opisuje planirani sled događaja. Postoje i polu-standardne metode poput Unified Modeling Language i osnovnih koncepata za modeliranje. U svakom slučaju, neka dokumentacija plana je obično proizvod dizajna. Pored toga, dizajn softvera može biti platforma-nezavisna ili platforma specifična, u zavisnosti od raspoloživosti tehnologije koja se koristi za dizajn.

Softverski dizajn može se smatrati kao stvaranje rešenja problema u ruci sa raspoloživim mogućnostima. Osnovna razlika između analize softvera i dizajna je da se izlaz analize softvera sastoji od manjih problema koje treba rešiti. Takođe, analiza ne bi trebalo da bude veoma različita, čak i ako je dizajniran od strane raznih članova tima ili grupa. Dizajn se fokusira na sposobnosti, i ne može biti više dizajna za isti problem zavisnosti od ambijenta koji će biti domaćin rešenja. Oni mogu da budu operativni sistemi, veb stranice, mobilni ili čak novi oblak računarske paradigme. Ponekad dizajn zavisi od okruženja ze koje je razvijen, bilo da je stvorena iz pouzdanih okvira ili se sprovodi sa odgovarajućim obrascima dizajna.

Softverski dizajn je proces i model. Proces dizajna je niz koraka koji omogućavaju dizajnerima da opišu sve aspekte softvera da se izgradi. Važno je napomenuti, međutim, da proces dizajniranja nije samo kuvar. Kreativna veština, iskustva iz prošlosti, smisao onoga što čini "dobar" softver, kao i ukupna posvećenost kvalitetu su kritični faktori uspeha za nadležni dizajn. Dizajn modela je ekvivalent planova arhitekte za kuću. Ona počinje predstavljanjm ukupnih stvari za izgradnju (na primer, trodimenzionalni rendering kuće) i polako ponovo proverava stvari da obezbedi smernice za izgradnju svakog detalja (npr rasporeda vodovod). Slično tome, dizajn model koji je stvoren za softver nudi niz različitih stavova računarskog softvera. Osnovni principi dizajna omogućavaju softverskom inženjeru navigaciju procesa projektovanja. Dejvis [DAV95] sugeriše skup principa za dizajn softvera, koji su prilagođeni i drugima u sledećoj listi:

  • Proces dizajna ne bi trebalo da pati od "tunela vizije." Dobar dizajner treba da razmotri alternativne pristupe, sudeći svaki na osnovu zahteva problema, raspoloživih resursa da obavi posao.
  • Dizajn treba da  prati model analize. Zato što jedan element dizajna modela često se prati na više zahteva, neophodno je da postoje sredstva za praćenje kako bi zahtevi bili zadovoljni od strane  dizajn modela.
  • Dizajn ne treba da izmišlja točak. Sistemi su konstruisani pomoću skupa dezena, od kojih su se mnogi verovatno ranije sretali. Ovi obrasci uvek treba da budu izabrani kao alternativa. Vreme je kratko, a resursi su ograničeni! Dizajn vremena treba uložiti u predstavljanju novih ideja zaista i integrisanje onih uzorka koji već postoje.
  • Dizajn treba da "umanji intelektualnu udaljenost" između softvera i problema kao što postoji u stvarnom svetu. To jest, struktura softverskog dizajna mora (kad god je to moguće) imitirati strukturu domena problema.
  • Dizajn treba da pokazuje jednoobraznost i integracije. Dizajn je jedinstven ako se pokaže da jedna osoba razvija celu stvar. Pravila stila i formata treba da budu definisana za dizajnerski tim  pre nego što počne dizajn posao. Dizajn je integrisan ako se obrati pažnja na definitivne  planove interfejsa između dizajna komponenti.
  • Dizajn treba da se prilagodi strukturiranim promenama . Koncepti dizajna razmatrani u sledećem odeljku omogućavaju dizajnu da se postigne ovaj princip.
  • Dizajn treba da bude strukturiran i da lagano razgrađuje, čak i kada su naišli aberantni podaci, događaji, ili uslovi rada. Dobro dizajniran softver nikada ne treba da bude "bomba": treba biti dizajniran da se prilagodi neobičnoj okolnosti, a ako mora da prekine obradu, učinite to na graciozan način.
  • Dizajn nije kodiranje, kodiranje nije dizajn.Čak i kada se stvore detaljni proceduralni projekti za programske komponente, nivo apstrakcije na dizajn modele je veći od izvornog koda. Odluke samo dizajna napravljenog na nivou kodiranja bave se sitnim detaljima implementacije koje omogućavaju proceduralni dizajn da se kodira.
  • Dizajn treba proceniti za kvalitet, jer se stvara, a ne posle toga.Mnoštvo dizajn koncepata i mera dizajna su dostupni da pomognu dizajneru u proceni kvaliteta.
  • Dizajn treba revidirati kako bi se smanjili konceptualno (semantičke greške). Ponekad postoji tendencija da se fokusira na sitnicama kada se razmatra dizajn, nedostaje šuma od drveća. Dizajn tim treba da obezbedi da veliki konceptualni elementi dizajna (propusti, dvosmislenost, nedoslednost) se obrate pre brige o sintaksi dizajna modela.

Dizajn koncepti uredi

Dizajn koncepti pružaju softverskog dizajnera sa fondacije iz koje se može primeniti sofisticiranije metode. Skup osnovnih koncepata dizajna je evoluirao. To su kao što sledi:

  1. Apstrakcija - Apstrakcija je proces ili rezultat generalizacije smanjenjem sadržaja informacija o konceptu ili vidljivih pojava, obično kako bi se zadržale samo informacije koje su relevantne za određenu svrhu.
  2. Usavršavanje- To je proces izrade. Hijerarhija je razvijena  raspadanjem makroskopske izjave funkcije u korak po korak način do programskog jezika izjave su stigle. U svakom koraku, jedan ili više uputstva datog programa se razgrađuju u detaljnija uputstva. Apstrakcija i usavršavanje su komplementarni koncepti.
  3. Modularnost - Softverska arhitektura je podeljena na komponente pod nazivom moduli.
  4. Softver arhitektura - To se odnosi na ukupnu strukturu softvera i načina na koji ta struktura obezbeđuje konceptualni integritet za sistem. Dobra softverska arhitektura će dati dobar povrat na investiciju u odnosu na željeni ishod projekta, na primer, u smislu efikasnosti, kvalitetu rasporeda i troškova.
  5. Hijerarhijska kontrola - Program struktura koji predstavlja organizaciju komponenti programa i podrazumeva hijerarhiju kontrole.
  6. Strukturna podela - Struktura programa se može podeliti i horizontalno i vertikalno. Horizontalne particije definišu posebne grane modularne hijerarhije za svaku glavnu funkciju programa. Vertikalna podela predlaže da kontrola i rad budu distribuirani odozgo u strukturi programa.
  7. Struktura podataka - To je prikaz logičnog odnosa između pojedinih elemenata podataka.
  8. Softverska procedura - Ona se fokusira na obradu svakog modula pojedinačno
  9. Skrivanje informacija - Moduli treba da navedu i projektuju tako da  informacije sadržane u modulu  budu nedostupne drugim modulima koji nemaju potrebu za takvim informacijama

U svom objektu modela, Grady Booch pominje apstrakciju, enkapsulaciju, modularizaciju, i hijerarhiju, kao osnovne principe dizajna.[3] Akronim PHAME (Principi hijerarhije, apstrakcije, modularizacije i enkapsulacije) se ponekad koristi za ova četiri fundamentalna principa.[4]

Dizajn razmatranja uredi

Postoje mnogi aspekti koje treba uzeti u obzir u dizajnu delova softvera. Značaj svakog treba da odražava ciljeve koje softver pokušava da postigne. Neki od ovih aspekata su:

  • Kompatibilnost - Softver je u stanju da radi sa drugim proizvodima koji su dizajnirani za interoperabilnost sa drugih proizvoda. Na primer, komad softvera može biti kompatibilan sa starijom verzijom sebe.
  • Rastegljivost - Nove mogućnosti se mogu dodati softveru bez značajnih promena u osnovnoj arhitekturi.
  • Greška tolerancije - Softver je otporan i sposoban da se oporavi od neuspeha komponenti.
  • Sposobnost snabdevanja - Mera koliko lako ispravke grešaka ili funkcionalnih modifikacija može postići. Visoka mogućnost održavanja može biti proizvod modularnosti i proširenja.
  • Modularnost- dobijeni softver obuhvata dobru definisanost, nezavisne komponente koje dovode do boljeg održavanja. Komponente bi mogle da budu realizovane i testirane u izolaciji pre nego što budu integrisane da se formira željeni sistem softvera. Ovo omogućava podelu rada u razvoju softverskog projekta.
  • Pouzdanost - Softver je u stanju da obavi potrebnu funkciju pod navedenim uslovima za određeni vremenski period.
  • Upotrebljivosti - Delovi ili ceo softver može da se koristi i u drugim projektima sa ne, ili samo neznatno, modifikacijama.
  • Nedostatak tolerancije - Softver je u stanju da radi pod stresom ili toleriše nepredvidljiv ili nepravilan unos. Na primer, može biti kreiran sa otpornošću na uslovima niske memorije.
  • Bezbednost - The software is able to withstand hostile acts and influences.
  • UpotrebljivostKorisnički interfejs softvera mora biti koristan za cilj korisnika / publike. Uobičajene vrednosti parametara moraju biti izabrane tako da su dobar izbor za većinu korisnika.[5]
  • Performanse - Softver obavlja svoje zadatke u okviru korisnički prihvatljivog vremena. Softver ne konzumira previše memorije.
  • Prenosivost - Upotrebljivost istog softvera u različitim sredinama.
  • Skalabilnost - Softver se prilagođava i povećanju podatka ili broja korisnika.

Modeliranje jezika uredi

Modeliranje jezika  je bilo koji  veštački jezik koji se koristi da izrazi informacije ili znanje ili sistema u strukturi koja je definisana konzistentnim skupom pravila. Pravila se koriste za tumačenje značenja komponenti u strukturi. Modeliranje jezika može biti grafičko ili tekstualno. Primeri grafičkih jezika za modeliranje za dizajn softvera su:

Dizajn obrasci  uredi

Softverski dizajner ili arhitekta može da identifikuje problem sa dizajnom koji je rešen od strane drugih ranije. Šablon ili obrazac koji opisuje rešenje za zajednički problem je poznat kao dizajnerski obrazac. Ponovni takvi obrasci mogu da ubrzaju proces razvoja softvera, pošto je testirano i dokazano u prošlosti.[7]

Tehnika uredi

Poteškoće u korišćenju termina "dizajn" u odnosu na softver je da je u nekom smislu, izvorni kod programa  dizajn za program koji se proizvodi. U meri u kojoj je to istina, "dizajn softvera" se odnosi na projektovanje dizajna. Edsger Dajkstra iz ovog raslojavanja semantičkih nivoa kao "radikalnih  novosti" od računarskog programiranja,[8] i Donald Knut koristi svoje iskustvo pisanja teksta da opiše uzaludnost pokušaja da dizajnira program pre nego što ga primeni:

Upotreba uredi

Dokumentacija softverskog dizajna može se pregledati ili predstaviti da dozvoli ograničenja, specifikacije, pa čak i zahtevi da se prilagode računarskom programiranju. Redizajn se može desiti nakon razmatranja programirane simulacije ili prototipa. Moguće je da je dizajn softvera u procesu programiranja, bez plana ili analize obavezne,[9] ali za složenije projekte to ne bi bilo moguće smatrati. Poseban dizajn pre programiranja omogućava multidisciplinarne dizajnere i predmet stručnjaka (MSP) da sarađuju sa visoko kvalifikovanim programerima za softver koji je i koristan i tehnički zvuk.

Vidi još uredi

Reference uredi

  1. ^ Ralph, P. and Wand, Y. (2009).
  2. ^ Freeman, Peter; David Hart (2004).
  3. ^ Booch, Grady; (2004).
  4. ^ Suryanarayana, Girish (November 2014).
  5. ^ Carroll, ed., John (1995).
  6. ^ Bell 2008
  7. ^ Judith Bishop.
  8. ^ Dijkstra, E. W. (1988).
  9. ^ Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept.

Literatura uredi