Софтуерни технологии



страница3/18
Дата16.11.2017
Размер3.19 Mb.
Размер3.19 Mb.
1   2   3   4   5   6   7   8   9   ...   18

40

3.3. Проектиране

3.3.1. Основни понятия

Проектирането на софтуерни системи обхваща всички дейности за прев-


ръщане на утвърдените изисквания в описание, определящо точно съдържани-
ето и функциите на програмите, които трябва да бъдат създадени.

Основен принцип на проектирането е изследване и разбиране на проблема


и последователното му декомпозиране на подпроблеми. На всяка стъпка се пов-
таря една и съща последователност от действия:

  • идентифициране на проблема;

  • съставяне на множество от възможни решения и сравняването им;

  • избор на оптимално (в някакъв смисъл) решение. Обикновено се избира
    познато вече решение, за да може да се осъществи повторно използване на
    софтуерни компоненти.

Декомпозирането е съществено, защото е ефективен начин за справяне
със сложността на създавания софтуер. Смята се за теоретично доказано и екс-
периментално проверено, че ако сложен проблем се декомпозира (по подхо-
дящ начин) на два подпроблема, то усилията за решаване на цялостния проблем
са по-големи от сумарните усилия за решаване на двата подпроблема.

Разграничават се два основни подхода към проектирането: функционален


и обектноориентиран.

При функционалното проектиране софтуерната система се разглежда като


съвкупност от компоненти, всяка от които реализира определена функция. Със-
тоянието на системата е централизирано и се разделя между функции, оперира-
щи върху това състояние.

При обектноориентираното проектиране системата се разглежда като съв-


купност от обекти. Състоянието на системата е децентрализирано и всеки обект
управлява собственото си състояние. Обектите имат множество от атрибу-
ти,
определящи състоянието им, и операции върху тези атрибути. Обектите
комуникират помежду си чрез съобщения.

По-нататъшното ни изложение е свързано с функционалното проектиране.



41

СЪДЪРЖАНИЕ

© Аврам Моис Ескенази, Нели Милчева Манева, 2001
© Михаил Асенов Руев, корица, 2001

lSBN954-426-311-X

УВОД 7

1.ОСНОВНИ ПОНЯТИЯ 9


  1. Програми и програмни продукти 9

  2. Характеристики на софтуера _ 11

  3. Софтуерни технологии 14

2. ЖИЗНЕН ЦИКЪЛ НА ПРОГРАМНИЯ ПРОДУКТ 18

  1. Моделиране на жизнения цикъл 18

  2. Класификация на моделите на ЖЦ на ПП 20

  3. Типове модели на ЖЦ на ПП 20

  4. Модел на Гънтър 29

3. КОНВЕНЦИОНАЛЕН ПОДХОД ЗА РАЗРАБОТВАНЕ НА СОФТУЕР 36

  1. Модели на жизнения цикъл и подходи за разработване 36

  2. Определяне на софтуерната система 37

3.3 Проектиране 41

  1. Програмиране 45

  2. Интегриране и тестване 46

4. ОБЕКТНО ОРИЕНТИРАН ПОДХОД ЗА РАЗРАБОТВАНЕ НА СОФТУЕР 48

  1. Основни понятия 48

  2. Обектно ориентиран анализ и проектиране 49

  3. Обектно ориентирано програмиране и тестване 51

  4. Управление на обектно ориентираното разработване 52

  5. Въвеждане на обектно ориентирания подход 55

5. ДЕЙНОСТИ,ОСИГУРЯВАЩИ РАЗРАБОТВАНЕТО НА ПРОГРАМНИ ПРОДУКТИ....57

  1. Откриване на дефекти 57

  2. Съпровождане 64

  3. Документиране 67

6. КАЧЕСТВО НА СОФТУЕРА 70

  1. Общи понятия 70

  2. Модели на качеството на софтуера 71

7. СОФТУЕРНИ МЕТРИКИ 83

  1. Въведение 83

  2. Измерването в софтуерното производство 83

  3. Класификация на софтуерните метрики 84

  4. Примери за софтуерни метрики 87

  5. Методологични проблеми на използването на софтуерните метрики 91

5

3.3.2. Методи и средства за проектиране

Както всяка основна дейност в разработването на софтуер и проектиране-


то може да се реализира по два начина: като ad hoc процес или като стандарти-
зиран процес. В първия случай въз основа на утвърдените изисквания се изгот-
вя неформализирано описание на естествен език, което служи за ръководство
при съставяне на програмите. По-систематичен е подходът с прилагане на т. нар.
структурни методи, които предлагат начини за описване и процедури за създа-
ване на софтуерни проекти.

3.3.3. Emanu на проектиране

Разграничават се два основни етапа на функционалното проектиране: пред-


варително (понякога наричано външно) проектиране и детайлно (понякога на-
ричано вътрешно) проектиране. Като резултат от предварителното проектиране
се създава външният (архитектурен) проект. Той представя цялостната структура
на софтуерната система и начините, чрез които тази структура осигурява кон-
цептуалната цялост на системата. Създаденият външен проект обхваща:

  • логическата организация на данните — трансформация на създадения
    при анализа модел на данните в структури от данни, необходими за реализация
    на системата;

  • структурата на системата — основните компоненти, външнопроявими-
    те им свойства и отношенията между тях;

  • интерфейс на системата — между отделните й части, между системата и
    други софтуерни системи и между системата и потребителя.

При детайлното проектиране {component-level) софтуерната система се
представя като йерархия от „черни" кутии, които трябва да се реализират като
обособени програмни части, наречени модули. Модулът е функционално обо-
собен и стандартно оформен елемент, който е основна, самостоятелно разра-
ботвана, тествана и документирана единица. При първата стъпка се създава
схема на структурата, описваща основните модули, потока на данните и потока
на управление между тях. При втората стъпка се специфицират модулите. Все-
ки модул има име и четири основни атрибута:

  • вход и изход;

  • основна функция;

  • механизъм за реализация на функцията;

  • вътрешни данни.

3.3.4. Memogu за описване на проекти

Създадени са различни методи за описание на създаваните проекти, които


се различават по степента си на формализираност и по нагледността и разбира-
емостта на получените описания. Практиката показва, че все още се предпочи-
тат неформалните методи поради съпротивата и на потребителите, и на проек-
тантите. Възраженията на потребителите са, че формалните описания са твърде
сложни и неразбираеми за тях и те не могат да участват ефективно в обсъжда-

42

нето и проследяването на създаваните проекти. Възраженията на проектантите


срещу формализмите са следните:

  • не всички софтуерни специалисти имат необходимата теоретична под-
    готовка (например в областта на дискретната математика и математическата ло-
    гика), за да овладеят съответния апарат и да го прилагат за сложните реални
    системи;

  • някои класове софтуерни системи са сложни за формално специфицира-
    не поради необходимостта от паралелни обработки, работа в реално време и др.;

  • в софтуерните организации няма достатъчна информация за съществу-
    ващите техники за специфициране на проекти и за съответните инструментал-
    ни средства, които ги подпомагат.

Използваните техники за описания са:

а) Графично описание

Този вид описание е най-старият, доколкото блок-схемите са един от най-
предпочитаните начини за описание на алгоритми. В последните години се по-
вишава приложимостта му поради появата на графични редактори и на специа-
лизирани софтуерни средства за графично проектиране.

б) Таблично представяне

Заимствано е от теорията на вземане на решения и се състои в съставяне
на таблици, описващи анализираните условия и съответните реакции на систе-
мата за всяка комбинация от осъществени или неосъществени събития.

в) Текстови описания

Този вид описания са с различна степен на формализираност и най-общо
се делят на две: псевдокодове и езици за проектиране на програми (PDL —
Program Design Language).

Псевдокодът е ограничен и структуриран естествен език, обикновено анг-


лийски. Речникът на езика включва глаголи, имена от речника на данните и запа-
зени (ключови) думи за описване на логиката на извършваните действия. Син-
таксисът на езика допуска комбинации от линейна конструкция, конструкция
за описване на условия и конструкция за описване на цикли. По-долу следва
схематичен псевдокод за специфициране на модули. Той е създаден на основа-
та на описани в литературата псевдокодове и е успешно приложен в реални
софтуерни проекти:

СПЕЦИФИКАЦИЯ НА МОДУЛ

Module:<имe>

Рurposе:<предназначение>

Uses: <вход>

Returns: <изход>

Defines: <собствени данни>

Functional details:<описани чрез псевдокод>

Псевдокодът е неформален език — ограничен английски.

Речник:


= глаголи (прилагателните и обстоятелствените пояснения се пропускат по-
ради нееднозначното им интерпретиране);
= термини от речника на данните;
= ключови думи за описване на логиката.

43

Синтаксис:

I. Последователни конструкции

=. разказвателно описание на английски език;
=. оператор за присвояване.

II. Конструкции за условен преход:

IF
THEN
ELSE < sequential_construct_S2>

III. Конструкции за цикъл

WHILE DO
BEGIN

END


FOR

NEXT


DO ....

UNTIL

Различни начини за описване на проекти са подходящи за различните про-
екти или за части на един и същи проект. В [7] са описани следните критерии за
сравняване на методите за описване на проекти:


  • модулност;

  • простота;

  • леснота на редактиране;

  • възможност за автоматично създаване и обработка (чрез съответни ре-
    дактори);

  • съпровождаемост;

  • удобство на представяне на данните;

  • възможност за верификация;

  • сложност на прехода „проект—програма"

3.3.5. Организационни аспекти на проектирането

Успехът на проектирането зависи както от качеството на междинните


продукти, създадени през предишните фази („Технико-икономическо зада-
ние" и „Спецификация на изискванията"), така и от организацията на основ-
ните дейности. Като колективна дейност, извършвана от екип, проектиране-
то трябва да се осъществява целенасочено и систематично, с регламентира-
не на основните процедури (за комуникация във и извън екипа, за управля-
емо променяне на изискванията, за документиране на процеса и на резулта-
тите). Най-сложният проблем е определянето на подходящо ниво на деком-
позиране и оттам — на подробност на проекта. Неясните, общи описания
могат да породят проблеми при съставянето на програмите. Обратно, стре-
межът да се създадат изключително подробни предписания още на този етап
може да затрудни програмистите. Препоръката е: „Не казвай на програмис-

44

та, как да прави нещата. Казвай му само, какво трябва да се направи и оста-


ви въображението му да те изненада (приятно?!)."

3.3.6. Оценяване качеството на проекти

За да се определи кои проекти са добри, трябва да се определят съответни


характеристики на качеството, които могат да бъдат:

Пълнота — утвърдените изисквания да са отразени в проекта на cod>Tveo-
ната система.

Проектът да бъде разбираем, ясен, точно и недвусмислено описан и да


не зависи от платформата, на която ще се реализира.

Проектът да бъде проверяем, т. е. да може да се проследява вграждането


на изискванията.

Процесът на проектиране и създадените проекти да бъдат документирани.

Препоръчва се проектирането да завършва със създаването на документ,


наречен „Спецификация на проекта", който може да има следната стандартна
структура:

Спецификация на проекта

I. Цел и обхват на дейностите по проектиране

II. Описание на проектите:

а) външен проект;

б) детайлен проект.

III. Съответствие на проектите с утвърдените изисквания
IV План за модулно и системно тестване

V. Допълнителни условия и ограничения за проектирането

VI. Приложения (описание на алгоритми, алтернативни процедури таб-
лични данни, извлечения от други документи и т. н.)

3.4. Програмиране

Структурното програмиране [8] е резултат от усилията да се създават прог-


рами, които не само могат да се изпълняват, но са и разбираеми, лесни за разу-
чаване или променяне. Основната идея на структурното програмиране (поня-
кога наричано програмиране без GOTO) e използването само на три класичес-
киконструкции: линейна последователност, конструкция за условен преход IF
ТHEN ELSE и конструкция за цикъл DO WHILE. Доказано е, че всеки алгори-
тъм може да бъде описан с използване само на тези конструкции.

Техниката за написване на структурни програми съчетава низходящото про-


ектиране и постъпковото уточняване {stepwise refinement). Започва се с най-
обща схема на програмата, като всеки цикъл или проверка на условие се предста-
вят чрез съответните оператори, а всяка вложена част постепенно се разширява
докато се получи окончателната програма. Милс, Ашкрофт и Мана посочват че
всяка „правилна" (определени са изискванията към такава програма) неструк-
турна програма може да бъде трансформирана в еквивалентна на нея структурна
програма. Трансформирането е смислено, ако се налага модифицирането на съ-
ществуваща програма с усложнена или объркана управляваща структура; или

45

ако новоразработваните програми ще са структурни и след преобразуването ще


се постигне унифицирано представяне (и документиране) на всички програми.

Основно преимущество на структурното програмиране е повишаването


на разбираемостта и тестируемостта на програмите и намаляване на усилията
за тяхното разучаване и съпровождане. Твърди се, че усвояването и придържа-
нето към точно определения структурен стил на проектиране и програмиране
повишава производителността на проектантите и програмистите.

Основен недостатък на структурното програмиране е необходимостта от|


усвояване на тази специална програмистка техника и прилагането й при създава-;
не на всички програми. Консервативно настроените програмисти се съпротивля-
ват на всяка промяна в стила им на работа и обикновено разглеждат опитите за,
въвеждане на стандарти като посегателство на личната им творческа свобода.)
Друг недостатък е, че в някои случаи структурните програми изискват по-големи|
изчислителни ресурси (памет и време) от съответните неструктурни програми,

3.5. Интегриране и тестване

Основните дейности по откриване и отстраняване на грешки — настройва-


нето и тестването на програми, са разгледани подробно в глава 5. на учебника,
Тук ще се спрем накратко само на стратегиите за тестване на софтуерните сис-
теми. Стратегиите за тестване определят кои части на системата да се тестват, в
какъв ред, с какви методи и средства, в каква среда и от кого.

Разглеждаме програмната система като йерархична структура, на най-нис-


кото ниво на която са модулите. Обикновено се започва с модулно тестване
след което се преминава към тестване на компонентите от по-високо ниво. В
зависимост от обекта и целите на тестване могат да се прилагат различни техни-
ки на тестване.

Модулно (поелементно) тестване

Основната идея на модулното тестване е да провери коректността на най


малките програмни компоненти — модулите. Те могат да бъдат разгледани, раз
брани и проверени сравнително лесно и усилията за откриване и поправяне на
грешките в тях не са големи. Препоръчва се тестването да започне с проверка
на интерфейса (на входните и изходните данни) на модула и да продължи
проверка на логиката, обработката на данните и реализираните функции.

Още при проектирането някои от модулите могат да се идентифицират ка-


то "критични" поради важността на реализираните функции, сложната структу-
ра или специални изисквания. Тестването на тези модули се планира и осъщес-
твява с отчитане на тези особености.

Модулното тестване изисква специална среда. Доколкото модулът не е са


мостоятелна програмна част, за да се изпълни, е необходимо да се създадат
допълнителни програми — драйвери (drivers) за извикване на тествания модул
и опори (stubs) за представяне на модулите, извиквани от тествания модул. До
пълнителните разходи за разработването на драйвери и опори се компенсира
от намаляването на грешките, за поправянето на които в по-късни фази ще с
необходими значително повече време и средства.

46

Интеграционно тестване

Интеграционното тестване е систематична техника за конструиране на прог-
рамна структура от тествани вече елементи и организиране на тестване за отк-
риване на интерфейсни грешки.

Съставянето на програмната структура за тестване може да става по два начи-


на: интегрално или инкрементално. При първия начин след тестването на всички
модули се сглобява цялата програмна система и започва системно тестване. Преи-
мущество е, че не се разработват допълнително драйвери и опори. Основен недос-
татък е, че откриването и локализирането на грешки е много по-трудно поради
възможността за наслагване на последиците от няколко интерфейсни грешки.

При инкременталното тестване се започва с група от два тествани модула и


на всяка стъпка съществуващата до момента програмна структура се разширя-
ва само с един допълнителен модул. Така причините за новопоявяващите се
грешки се установяват много по-лесно.

И двата начина могат да се реализират възходящо или низходящо. При въз-


ходящия подход се започва от най-долното ниво на йерархията (модула), образу-
ват се подсистеми и накрая се достига до най-високото ниво — системата. При
низходящото тестване се започва с тестване на системата като цяло и се продъл-
жава с тестване на елементите от по-ниските нива. Възходящото тестване изисква
драйвери за симулиране на дейността на слепващия компонент от по-високо ни-
во. Низходящото тестване изисква опори, имитиращи компонентите, подчинени
на текущо разглеждания компонент. Всъщност най-често се прилага смесен под-
ход, наречен „сандвичово тестване", като до определено ниво в йерархията се
прилага единият, а оттам нататък — другият подход. Редът на прилагането им
зависи от особеностите на конкретната софтуерна разработка.

Тестването може да се извършва от самите разработчици, от независима


група по тестване в софтуерната организация или от външна сертифицираща
фирма. Кой да извършва конкретни тестващи дейности, зависи от целите на
тестването в даден момент.

Особено важни са т. нар. приемни тестове. Те са последна проверка на завър-


шената софтуерна система преди разпространяването й. Алфа-тестването се про-
вежда с участието и на потребители, но в средата на разработване. Бета-тества-
нето е изцяло в реална потребителска среда, като потребителите регистрират проб-
лемите и ги съобщават на разработчиците, които внасят съответните промени.

Литература

  1. Sigfried, S., Understanding OO Software Engineering. IEEE Press, 1996.

  2. Zahniser, R.A., Building Software in Groups, American Programmer, vol. 3, no7/8, July-August 1990.

  3. Sommerville I. Software Engineering, Addison-Wesley Publ.Company, Fourth Edition, 1992.

  4. Chen, P., The Entity-Relationship Approach to Logical Database Design, QED Information
    Systems, 1977.

  5. Hatley, D.J., I.A.Pirbhai, Strategies for Real-Time System Specification, Dorset House, 1987.

  6. Yourdon, E.N. and L.Constantine. Structured Design. Yourdon Press, 1978.

  7. Pressman, R. Software Engineering—A Practitioner's Approach. R.S. Pressman & Associates,
    Inc. 2000.

  8. Вирт, H. Алгоритми + Структури от данни = Програми. С. Техника, 1980.

47

4. ОБЕКТНО ОРИЕНТИРАН ПОДХОД ЗА
РАЗРАБОТВАНЕ НА СОФТУЕР

Теорията и практиката на новата обектно ориентирана (OO) парадигма са


се развили толкова, че могат да бъдат обект на отделен учебник, посветен на
обектно ориентираните софтуерни технологии. В съответствие с целите, които
сме си поставили, ще се спрем само на основните характеристики на ОО-под-
ход и на особеностите, които го разграничават от конвенционалния подход за
разработване на софтуер.

равлението на обекта подател. Чрез съобщенията се описва поведението на обек-


тите и на ОО-система като цяло.

Три основни характеристики са присъщи на ОО-подход. Те са:

а) "Капсулиране" в класа на данните и операциите върху тях. Това има
следните преимущества:


  • подробностите на вътрешната реализация остават скрити;

  • данните и операциите са обединени в едно именовано цяло — класа,
    което улеснява повторното му използване;

  • връзките между „капсулираните" обекти са опростени, защото осъщес-
    твяването им чрез съобщения не зависи от вътрешните структури от данни.

б) Наследяване. Същността на наследяването е, че всеки подклас придоби-
ва автоматично (наследява) всички атрибути и операции на съответния супер-
клас. Така се осигурява повторно използване на проектираните и реализирани
вече структури данни и алгоритми. Улеснено е внасянето на изменения, защото
те се правят само в съответното ниво в йерархията от класове и чрез наследяване-
то се разпространяват. При необходимост от нов клас той може да се конструира
изцяло или да се „вмъкне" в съществуващата йерархия от класове, като се допи-
шат само специфичните за него елементи. Допуска се и „множествено наследява-
не" от няколко различни суперкласа. To e полезно заради по-големия брой насле-
дявани свойства, но затруднява проследяването на връзките в йерархията.

в) Полиморфизъм. Това свойство дава възможност различни операции да


имат едно и също име. Така се осигурява настроеваемост и гъвкавост, защото с
унифицирано извикване могат да се реализират специфични обработки.


4.1. Основни понятия

Под обект се разбира познаваем предмет, елемент или същност (реална


или абстрактна), имащ важно функционално предназначение в разглежданата
приложна област. Всеки обект има състояние, поведение и индивидуалност
Структурата и поведението на сходни обекти определят общ за тях клас. Със-
тоянието на обекта се характеризира с изброяване на всички възможни свойс-
тва на обекта и текущите стойности на тези свойства. Разгаежданите свойства
се наричат атрибути. Всеки атрибут има област на допустимите стойности. С
всеки обект могат да се свържат операции (услуги или методи), които променят
един или няколко атрибута на обекта. Обектът наследява всички атрибути и
операции на класа, към който принадлежи.

Понятието клас е основно за ОО-подход. То обхваща (encapsulate) данни


те и алгоритмите (процедурите), чрез които може да се опише съдържанието
поведението на „нещо" от реалния свят. Класът може да се разглежда като обоб
щено описание на съвкупност от подобни обекти.

Обектите в класа наследяват неговите атрибути и операции. Суперклас е


съвкупност от класове, а подклас е екземпляр на клас. Съществува йерархия|
на класовете, като подкласовете наследяват атрибутите и операциите на cynep-
класа, но могат да имат и специфични за тях атрибути и операции.

Взаимодействието между обекти се осъществява чрез съобщения


(messages). Съобщението предизвиква реакция и промяна в поведението на обек
та получател. Той изпълнява посочената в съобщението операция и връща уп-


Сподели с приятели:
1   2   3   4   5   6   7   8   9   ...   18


©zdrasti.info 2017
отнасят до администрацията

    Начална страница