Софтверски дизајн

Софтверски дизајн је процес којим агент ствара спецификацију софтверског артефакта, са намером да оствари циљеве, користећи скуп примитивних компоненти и предмет ограничења.[1] Софтверски дизајн се може односити на било "све активности које су укључене у концептуализацију, кадрирање, имплементацију, пуштање у рад, и на крају модификовање сложених система" или "активност следећих захтева спецификације и пре програмирања, као ... у стилизованом софтверском инжењерском процесу. "[2]

Софтверски дизајн обично укључује решавање проблема и планирање софтверског решења. Ово укључује и компоненте ниског нивоа и алгоритамски дизајн и висок ниво, архитектура.

Преглед уреди

Софтверски дизајн је процес спровођења софтверских решења за један или више скупова проблема. Један од важних делова софтверског дизајна је анализа софтверских захтева (SRA). То је део процеса развоја софтвера који наводи спецификације које се користе и софтверском инжењерству. Ако је софтвер "полуаутоматски" или кориснички центриран, дизајн софтвера може да подразумева корисничко искуство дизајна стварајући сторибоард да би се утврдиле те спецификације. Ако је софтвер потпуно аутоматизован (значи нема  кориснички интерфејс), дизајн софтвера може бити једноставан као дијаграм тока или текст који описује планирани след догађаја. Постоје и полу-стандардне методе попут Unified Modeling Language и основних концепата за моделирање. У сваком случају, нека документација плана је обично производ дизајна. Поред тога, дизајн софтвера може бити платформа-независна или платформа специфична, у зависности од расположивости технологије која се користи за дизајн.

Софтверски дизајн може се сматрати као стварање решења проблема у руци са расположивим могућностима. Основна разлика између анализе софтвера и дизајна је да се излаз анализе софтвера састоји од мањих проблема које треба решити. Такође, анализа не би требало да буде веома различита, чак и ако је дизајниран од стране разних чланова тима или група. Дизајн се фокусира на способности, и не може бити више дизајна за исти проблем зависности од амбијента који ће бити домаћин решења. Они могу да буду оперативни системи, веб странице, мобилни или чак нови облак рачунарске парадигме. Понекад дизајн зависи од окружења зе које је развијен, било да је створена из поузданих оквира или се спроводи са одговарајућим обрасцима дизајна.

Софтверски дизајн је процес и модел. Процес дизајна је низ корака који омогућавају дизајнерима да опишу све аспекте софтвера да се изгради. Важно је напоменути, међутим, да процес дизајнирања није само кувар. Креативна вештина, искуства из прошлости, смисао онога што чини "добар" софтвер, као и укупна посвећеност квалитету су критични фактори успеха за надлежни дизајн. Дизајн модела је еквивалент планова архитекте за кућу. Она почиње представљањм укупних ствари за изградњу (на пример, тродимензионални рендеринг куће) и полако поново проверава ствари да обезбеди смернице за изградњу сваког детаља (нпр распореда водовод). Слично томе, дизајн модел који је створен за софтвер нуди низ различитих ставова рачунарског софтвера. Основни принципи дизајна омогућавају софтверском инжењеру навигацију процеса пројектовања. Дејвис [ДАВ95] сугерише скуп принципа за дизајн софтвера, који су прилагођени и другима у следећој листи:

  • Процес дизајна не би требало да пати од "тунела визије." Добар дизајнер треба да размотри алтернативне приступе, судећи сваки на основу захтева проблема, расположивих ресурса да обави посао.
  • Дизајн треба да  прати модел анализе. Зато што један елемент дизајна модела често се прати на више захтева, неопходно је да постоје средства за праћење како би захтеви били задовољни од стране  дизајн модела.
  • Дизајн не треба да измишља точак. Системи су конструисани помоћу скупа дезена, од којих су се многи вероватно раније сретали. Ови обрасци увек треба да буду изабрани као алтернатива. Време је кратко, а ресурси су ограничени! Дизајн времена треба уложити у представљању нових идеја заиста и интегрисање оних узорка који већ постоје.
  • Дизајн треба да "умањи интелектуалну удаљеност" између софтвера и проблема као што постоји у стварном свету. То јест, структура софтверског дизајна мора (кад год је то могуће) имитирати структуру домена проблема.
  • Дизајн треба да показује једнообразност и интеграције. Дизајн је јединствен ако се покаже да једна особа развија целу ствар. Правила стила и формата треба да буду дефинисана за дизајнерски тим  пре него што почне дизајн посао. Дизајн је интегрисан ако се обрати пажња на дефинитивне  планове интерфејса између дизајна компоненти.
  • Дизајн треба да се прилагоди структурираним променама . Концепти дизајна разматрани у следећем одељку омогућавају дизајну да се постигне овај принцип.
  • Дизајн треба да буде структуриран и да лагано разграђује, чак и када су наишли аберантни подаци, догађаји, или услови рада. Добро дизајниран софтвер никада не треба да буде "бомба": треба бити дизајниран да се прилагоди необичној околности, а ако мора да прекине обраду, учините то на грациозан начин.
  • Дизајн није кодирање, кодирање није дизајн.Чак и када се створе детаљни процедурални пројекти за програмске компоненте, ниво апстракције на дизајн моделе је већи од изворног кода. Одлуке само дизајна направљеног на нивоу кодирања баве се ситним детаљима имплементације које омогућавају процедурални дизајн да се кодира.
  • Дизајн треба проценити за квалитет, јер се ствара, а не после тога.Мноштво дизајн концепата и мера дизајна су доступни да помогну дизајнеру у процени квалитета.
  • Дизајн треба ревидирати како би се смањили концептуално (семантичке грешке). Понекад постоји тенденција да се фокусира на ситницама када се разматра дизајн, недостаје шума од дрвећа. Дизајн тим треба да обезбеди да велики концептуални елементи дизајна (пропусти, двосмисленост, недоследност) се обрате пре бриге о синтакси дизајна модела.

Дизајн концепти уреди

Дизајн концепти пружају софтверског дизајнера са фондације из које се може применити софистицираније методе. Скуп основних концепата дизајна је еволуирао. То су као што следи:

  1. Апстракција - Апстракција је процес или резултат генерализације смањењем садржаја информација о концепту или видљивих појава, обично како би се задржале само информације које су релевантне за одређену сврху.
  2. Усавршавање- То је процес израде. Хијерархија је развијена  распадањем макроскопске изјаве функције у корак по корак начин до програмског језика изјаве су стигле. У сваком кораку, један или више упутства датог програма се разграђују у детаљнија упутства. Апстракција и усавршавање су комплементарни концепти.
  3. Модуларност - Софтверска архитектура је подељена на компоненте под називом модули.
  4. Софтвер архитектура - То се односи на укупну структуру софтвера и начина на који та структура обезбеђује концептуални интегритет за систем. Добра софтверска архитектура ће дати добар поврат на инвестицију у односу на жељени исход пројекта, на пример, у смислу ефикасности, квалитету распореда и трошкова.
  5. Хијерархијска контрола - Програм структура који представља организацију компоненти програма и подразумева хијерархију контроле.
  6. Структурна подела - Структура програма се може поделити и хоризонтално и вертикално. Хоризонталне партиције дефинишу посебне гране модуларне хијерархије за сваку главну функцију програма. Вертикална подела предлаже да контрола и рад буду дистрибуирани одозго у структури програма.
  7. Структура података - То је приказ логичног односа између појединих елемената података.
  8. Софтверска процедура - Она се фокусира на обраду сваког модула појединачно
  9. Скривање информација - Модули треба да наведу и пројектују тако да  информације садржане у модулу  буду недоступне другим модулима који немају потребу за таквим информацијама

У свом објекту модела, Grady Booch помиње апстракцију, енкапсулацију, модуларизацију, и хијерархију, као основне принципе дизајна.[3] Акроним PHAME (Принципи хијерархије, апстракције, модуларизације и енкапсулације) се понекад користи за ова четири фундаментална принципа.[4]

Дизајн разматрања уреди

Постоје многи аспекти које треба узети у обзир у дизајну делова софтвера. Значај сваког треба да одражава циљеве које софтвер покушава да постигне. Неки од ових аспеката су:

  • Компатибилност - Софтвер је у стању да ради са другим производима који су дизајнирани за интероперабилност са других производа. На пример, комад софтвера може бити компатибилан са старијом верзијом себе.
  • Растегљивост - Нове могућности се могу додати софтверу без значајних промена у основној архитектури.
  • Грешка толеранције - Софтвер је отпоран и способан да се опорави од неуспеха компоненти.
  • Способност снабдевања - Мера колико лако исправке грешака или функционалних модификација може постићи. Висока могућност одржавања може бити производ модуларности и проширења.
  • Модуларност- добијени софтвер обухвата добру дефинисаност, независне компоненте које доводе до бољег одржавања. Компоненте би могле да буду реализоване и тестиране у изолацији пре него што буду интегрисане да се формира жељени систем софтвера. Ово омогућава поделу рада у развоју софтверског пројекта.
  • Поузданост - Софтвер је у стању да обави потребну функцију под наведеним условима за одређени временски период.
  • Употребљивости - Делови или цео софтвер може да се користи и у другим пројектима са не, или само незнатно, модификацијама.
  • Недостатак толеранције - Софтвер је у стању да ради под стресом или толерише непредвидљив или неправилан унос. На пример, може бити креиран са отпорношћу на условима ниске меморије.
  • Безбедност - The software is able to withstand hostile acts and influences.
  • УпотребљивостКориснички интерфејс софтвера мора бити користан за циљ корисника / публике. Уобичајене вредности параметара морају бити изабране тако да су добар избор за већину корисника.[5]
  • Перформансе - Софтвер обавља своје задатке у оквиру кориснички прихватљивог времена. Софтвер не конзумира превише меморије.
  • Преносивост - Употребљивост истог софтвера у различитим срединама.
  • Скалабилност - Софтвер се прилагођава и повећању податка или броја корисника.

Моделирање језика уреди

Моделирање језика  је било који  вештачки језик који се користи да изрази информације или знање или система у структури која је дефинисана конзистентним скупом правила. Правила се користе за тумачење значења компоненти у структури. Моделирање језика може бити графичко или текстуално. Примери графичких језика за моделирање за дизајн софтвера су:

Дизајн обрасци  уреди

Софтверски дизајнер или архитекта може да идентификује проблем са дизајном који је решен од стране других раније. Шаблон или образац који описује решење за заједнички проблем је познат као дизајнерски образац. Поновни такви обрасци могу да убрзају процес развоја софтвера, пошто је тестирано и доказано у прошлости.[7]

Техника уреди

Потешкоће у коришћењу термина "дизајн" у односу на софтвер је да је у неком смислу, изворни код програма  дизајн за програм који се производи. У мери у којој је то истина, "дизајн софтвера" се односи на пројектовање дизајна. Едсгер Дајкстра из овог раслојавања семантичких нивоа као "радикалних  новости" од рачунарског програмирања,[8] и Donald Knut користи своје искуство писања текста да опише узалудност покушаја да дизајнира програм пре него што га примени:

Употреба уреди

Документација софтверског дизајна може се прегледати или представити да дозволи ограничења, спецификације, па чак и захтеви да се прилагоде рачунарском програмирању. Редизајн се може десити након разматрања програмиране симулације или прототипа. Могуће је да је дизајн софтвера у процесу програмирања, без плана или анализе обавезне,[9] али за сложеније пројекте то не би било могуће сматрати. Посебан дизајн пре програмирања омогућава мултидисциплинарне дизајнере и предмет стручњака (МСП) да сарађују са високо квалификованим програмерима за софтвер који је и користан и технички звук.

Види још уреди

Референце уреди

  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.

Литература уреди