Википедија

Проектирање на програмска опрема

(Пренасочено од Софтверски дизајн)

Софтверскиот дизајн претставува процес на решавање на проблем и планирање на решение. По дефинирањето на целта и спецификацијата, се прави план за решавање на проблемот. Се користат компоненти од ниско ниво и имплементација на алгоритми. Всушност софтверскиот дизајн е процес од неколку чекори кои се фокусираат на атрибутите од програмата како што се: податочните структури, софтверската архитектура, претставување на интерфејсот и детали за процедурите. Како и софтверските барања така и софтверскиот дизајн е документ и е дел од софтверската конфигурација.[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]
    • IDEF1X за информациско моделирање.[9]
    • IDEF5 за моделирање на онтологии.[10]
  • 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]

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

уреди

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

Составни делови на документацијата

уреди

Документацијата за софтверскиот дизајн го содржи следниве документи:

  1. Податочен дизајн – ги опишува структурите што се наоѓаат во софтверот. Атрибутите и релациите помеѓу ентитети ја одредуваат податочната структура што ќе се користи.
  2. Дизајн на архитектурата – множество од структури коишто го опишуваат системот и ги опфаќа софтверските елементи, врските меѓу нив и нивните особини.[20]
  3. Дизајн на интерфејсот – го опишува и внатрешниот и надворешниот програмски интерфејс, како и корисничкиот интерфејс. Внатрешниот и надворешниот интерфејс се засноваат на информациите добиени од модел за анализа.
  4. Дизајн на процедурите - ги опишува структурните концепти на програмирање, користејќи графички и текстуални нотации. Со нивна помош на дизајнерот му се овозможува да се претстави процедурата детално и се олеснува кодирањето.[21]

Наводи

уреди
  1. ↑ 1,0 1,1 Software design
  2. ↑ Planning and Design Архивирано на 2 јули 2013 г. проверено на 27.03.2012
  3. ↑ 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
  4. ↑ „BPMN Information“. Архивирано од изворникот на 2008-12-18. Посетено на 2011-03-29.
  5. ↑ ISO 10303-11:2004 Industrial automation systems and integration -- Product data representation and exchange -- Part 11: Description methods: The EXPRESS language reference manual
  6. ↑ SEVOCAB: Software and Systems Engineering Vocabulary. Term: Flow chart. Retrieved 31 July 2008.
  7. ↑ Fundamental Modeling Concepts (FMC) проверена на 28.03.2012
  8. ↑ IDEF0 Архивирано на 5 март 2016 г. проверено на 28.03.2012
  9. ↑ IDEF1X Архивирано на 8 март 2016 г. проверено на 28.03.2012
  10. ↑ IDEF5 Архивирано на 3 март 2016 г. проверено на 28.03.2012
  11. ↑ R. Wieringa (1998). "A survey of structured and object-oriented software specification methods and techniques". in: ACM Comput. Surv. 30, 4 (Dec. 1998), 459-527. DOI= http://doi.acm.org/10.1145/299917.299919
  12. ↑ Brian Henderson-Sellers and J.M. Edwards (1990). "The object-oriented systems life cycle". In: Commun. ACM 33, 9 (Sep. 1990), 142-159. DOI= http://doi.acm.org/10.1145/83880.84529
  13. ↑ Eden, Amnon; With contributions by Jonathan Nicholson (2011). Codecharts: Roadmaps and Blueprints for Object-Oriented Programs. Hoboken, New Jersey: Wiley/Blackwell. Архивирано од изворникот на 2012-03-22. Посетено на 2012-03-27.
  14. ↑ Amnon H. Eden, with contributions from Jonathan Nicholson. „Modelling Design Patterns, Chapter 11 in Codecharts: Roadmaps and Blueprints for Object-Oriented Programs“ (PDF). Архивирано од изворникот (PDF) на 2012-03-22. Посетено на 2012-03-27.
  15. ↑ 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)
  16. ↑ UML Forum. „UML FAQ“. Архивирано од изворникот на 2010-05-09. Посетено на 2011-10-14.
  17. ↑ Jackson, Daniel (2006). Software Abstractions: Logic, Language, and Analysis. MIT Press. ISBN 978-0-262-10114-1.
  18. ↑ SysML Forum. „SysML FAQ“. Архивирано од изворникот на 2013-11-04. Посетено на 2009-08-26.
  19. ↑ pattern (design pattern) проверено на 28.03.2012
  20. ↑ 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. ISBN 0-321-55268-7.CS1-одржување: повеќе имиња: список на автори (link)
  21. ↑ John Lee Cook Jr (1998). PenWell Books (уред.). Standard Operating Procedures and Guidelines. ISBN 9780912212692.
Преземено од „https://mk.wikipedia.org/w/index.php?title=Проектирање_на_програмска_опрема&oldid=5229746“