Софтверскиот дизајн претставува процес на решавање на проблем и планирање на решение. По дефинирањето на целта и спецификацијата, се прави план за решавање на проблемот. Се користат компоненти од ниско ниво и имплементација на алгоритми. Всушност софтверскиот дизајн е процес од неколку чекори кои се фокусираат на атрибутите од програмата како што се: податочните структури, софтверската архитектура, претставување на интерфејсот и детали за процедурите. Како и софтверските барања така и софтверскиот дизајн е документ и е дел од софтверската конфигурација.[1]
Преглед
Ако софтверот којшто се развива е ,,полуавтоматски‘‘ или кориснички насочен, тогаш во дизајнот треба да се вклучат и корисниците со што би се направиле и повеќе ,,табли со приказни‘‘ со цел поточно да се утврди спецификацијата на софтверот. Доколку софтверот е целосно автоматски, односно не е потребна никаква интеракција со корисник, тогаш софтверскиот дизајн би можел да биди едноставен и во документацијата да вклучи блок шеми или кратко опишување на некоја активност. Постојат стандардни методи за такви опишувања како Унифицираниот јазик за моделирање и Основни концепти за моделирање. И во двата случаи потребно е се да биде документирано.
Софтверскиот дизајн може да биде независен платформски зависен или независен, во зависност од можноста на технологиите кои се повикуваат во дизајнот. Дизајнот може да се смета како изградување на решение на проблемите со расположливи средства. Па оттука разликата помеѓу дизајнот и анализата е следна: По завршувањето на анализата, проблемот ќе биде поделен на помали проблеми кои треба да се решат и овие помали проблеми во глобала би биле исти доколку анализата би ја правел било кој од групата. Но дизајнот зависи од можностите, односно за едно решение може да има и повеќе софтверски дизајни и сите тие ќе зависат од можностите од околината во која што софтверот ќе работи. Решението исто така ќе зависи и од тоа дали ќе го градиме решението од ,,нула‘‘ или ќе користиме некои рамки или ќе се имплементира некој соодветен шаблон за дизајн.[1]
Предмети во софтверскиот дизајн
Концепти за дизајн
Концептите за дизајн му овозможуваат на дизајнерот добра основа за работа, со што може да користи софистицирани методи. Некои од основните концепти за дизајн се:[2]
Апстракција – е процес или резултат на генерализација, со исфрлање на непотребните информации. Се земаат предвид сами информациите што ќе бидат корисни за одредени цели.
Чистење на програмата – е процес на обработка, односно потврдување на трансформација од апстрактна формална спецификација (високо ниво) во конкретна извршна програма.
Модуларност – Се врши поделба на софтверската архитектура на компоненти наречени модули.
Софтверска архитектура – се однесува на целосната структура на софтверот и начините со кој структурата овозможува зачувување на интегритет на системот. Добра софтверска архитектура овозможува и добри перформанси, добри квалитети на системот како и намалени трошоци за одржување.
Хиерархиска контрола – програмска структура која ја претставува организацијата на програмските компоненти и нивната хиерархија.
Поделба на структурата – програмската структура може да биде поделена вертикално и хоризонтално. Хоризонталната поделба дефинира модул на хиерархија за секоја главна програмска функција, додека вертикалната поделба предлага дека контролата и работата, кај програмската структура, треба да бидат распределени од горе па надолу.
Структура на податоците – одреден начин на зачувување и организирање на податоците со цел нивно ефикасно искористување.
Криење на информации – Модулите треба да бидат дефинирани и специфицирани на тој начин што информациите коишто се наоѓаат внатре во модулите ќе бидат непристапни за останатите модули коишто немаат никаква потреба за користење на тие информации.
Разбирање на дизајнот
Дизајнот треба да биде изграден врз основа на неколку аспекти. Секој од тие аспекти е значаен за да се добие од софтверот тоа што се очекува. Тие аспекти се:[3]
Компатибилност - овозможува софтверот да соработува со другите хардверски и софтверски производи, кои имаат такви можности. Ако софтверот има надолна компатибилност (англиски: backward compatibility) тоа значи дека може да биде компатибилен на постари верзии и на хардвер и на софтвер, додека пак нагорната компатибилност (англиски: forward compatibility) значи дека е компатибилен на новите верзии.
Проширливост (англиски: extensibility) – на системот можат да бидат додадени нови можности, без притоа да се прават големи промени во основната архитектура на системот.
Толеранција на грешки – системот до извесна мера да ги толерира грешките и да може да се справи со евентуален испад на некоја негова компонента.
Одржливост – можност за промена на софтверот по неговата испорака.
Модуларност - софтверот којшто се развива треба да има добро дефинирани и независни компоненти. Тоа ќе овозможи подобра одржливост. При тоа компонентите ќе можат да бидат одделно имплементирани и испробувани пред да се вметнат во софтверскиот систем. Ова овозможува и поделба на работата на повеќе луѓе во тимот.
Пакување – пакувањето на софтверскиот производ треба да биде дизајнирано на таков начин што ќе одговара на неговите одлики и ќе биде препознаен од корисниците за кои е наменет. Во него треба да има и корисничко упатство и сите информации за компатибилноста треба да бидат видливи на надворешната страна од кутијата.
Доверливост – софтверот треба да се однесува како што се очекува од него, да изврши некои функции под одредени околности и одредено време.
Реискористливост(англиски: Reusability) – Искористување на веќе испробан, испробуван изворен код и при тоа не се прават воопшто или многу малку модификации.
Робусност (англиски: Robustness) – Степен до кој софтверот е толерантен на корисничките грешки , како што се непредвидени влезни податоци и непредвидени акции.
Сигурност – софтверот да може да издржи намерни или ненамерни напади.
Употребливост – Корисничкиот интерфејс на софтверот да биде лесен за употреба на крајните корисници. Почетните вредности на параметрите да одговараат за најголемиот дел од корисниците.
Јазици за моделирање
Јазиците за моделирање се вештачки јазици и со нив се изразуваат информации, знаења или системи со структура дефинирана од усогласени правила. Правилата се користат за интерпретација на значењето на компонентите од структурата. Јазикот за моделирање, врз основа на тоа како ги прикажува структурите, може да биде графички или текстуален. Пример за графички јазици за моделирање се следните:
Business Process Modeling Notation (BPMN) – e пример за јазик за моделирање на процеси.[4]
EXPRESS и EXPRESS-G (ISO 10303-11) – се јазици за моделирање на податоци со интернационални стандарди.[5]
Extended Enterprise Modeling Language (EEML) – најчесто се користи за моделирање на бизнис процеси низ различни нивоа.
Flowchart – графичка репрезентација на процес или опишување на чекор по чекор на некој проблем, со користење на соодветни геометриски фигури, меѓусебно поврзани.[6]
Fundamental Modeling Concepts (FMC) – јазик за моделирање на интерактивен софтвер.[7]
IDEF – фамилија на јазици за моделирање, меѓу кои најзначајни се
IDEF0 кои се користи за функционално моделирање.[8]
Jackson Structured Programming (JSP) – метод кај структурирано програмирање кои се темели на размена на податоци помеѓу податочната структура и програмската структура.[11][12]
LePUS3[13] – е објектно ориентиран за опишување на дизајнот и формален јазик за спецификација, коишто е погоден за моделирање на големи објектно – ориентирани програми ( Java, C++, C#) и шаблони за дизајн.[14][15]
Unified Modeling Language (UML) – унифициран јазик за моделирање кој ја опишува структурата на софтверот и неговото однесување, со помош на графички ознаки.[16]
Alloy (specification language) – Јазик за спецификација чијашто основна цел е опишување на комплексни структури и однесување на софтверскиот систем.[17]
Systems Modeling Language (SysML)- е нов јазик за моделирање во системското инженерство. Ја поддржува спецификацијата, анализата, дизајнот, верификацијата и валидацијата на голем опсег на системи и подсистеми. Бил пуштен во употреба како слободен софтвер, и за користење и за дистрибуција., но сега се користи како екстензија на UML.[18]
Шаблони за дизајн
Дизајнерот или архитектот на софтверот, при дизајнирање може да се соочи со проблеми што веќе се решени претходно од други. Таквите проблеми се вообичаени и често се сретнуваат. Образецот или шаблоните кои даваат решение на такви проблеми се нарекуваат шаблони за дизајн. Со нивното користење при дизајнот се забрзува развојот на софтверот и се намалува времето за испробување, затоа што таквите решенија се веќе испробани и испробувани.[19]
Документирање на дизајнот
Документот за дизајнот е напишан од страна на дизајнерот и во него е опишан софтверскиот производ, на тој начин што тимот за развивање на софтверот би ја разбрал неговата архитектура. Со документот обично оди и дијаграм со кој е претставена архитектурата, во која има покажувачи кон одредени функции од одредени делови од кодот. Со документот се овозможува добра координација на голем тим. Тој документ треба да биде добар извор на информации, да бидат наведени сите делови на софтверот и опис како тие работат, како да го олесни одржување по испораката на софтверот.
Составни делови на документацијата
Документацијата за софтверскиот дизајн го содржи следниве документи:
Податочен дизајн – ги опишува структурите што се наоѓаат во софтверот. Атрибутите и релациите помеѓу ентитети ја одредуваат податочната структура што ќе се користи.
Дизајн на архитектурата – множество од структури коишто го опишуваат системот и ги опфаќа софтверските елементи, врските меѓу нив и нивните особини.[20]
Дизајн на интерфејсот – го опишува и внатрешниот и надворешниот програмски интерфејс, како и корисничкиот интерфејс. Внатрешниот и надворешниот интерфејс се засноваат на информациите добиени од модел за анализа.
Дизајн на процедурите - ги опишува структурните концепти на програмирање, користејќи графички и текстуални нотации. Со нивна помош на дизајнерот му се овозможува да се претстави процедурата детално и се олеснува кодирањето.[21]
↑Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136
↑Amnon H. Eden, Epameinondas Gasparis, Jonathan Nicholson (2007). „LePUS3 and Class-Z Reference Manual“. University of Essex. Архивирано од изворникот на 2012-03-05. Посетено на 2012-03-27.CS1-одржување: повеќе имиња: список на автори (link)
↑UML Forum. „UML FAQ“. Архивирано од изворникот на 2010-05-09. Посетено на 2011-10-14.
↑
Clements, Paul; Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. ISBN0-321-55268-7.CS1-одржување: повеќе имиња: список на автори (link)
