Предговор учебник icon

Предговор учебник


Смотрите также:
Аз мисля, че изобщо е излишно да се пише предговор към автобиография...
Предговор към българското издание...
Соня хинкова югославският случай етнически конфликти в Югоизточна Европа...
Тематическое планирование уроков литературы в пятых классах...
Тематическое планирование уроков литературы в пятых классах...
Предговор
Тематическое планирование курса литературы на 2011-2012 учебный год учитель: Лобова И. А...
Предговор на преводача...
Автобиография на един йогин Парамаханса Йогананда Предговор...
Учебник для вузов. Спб.: Питер, 2008. 583 с: ил. Серия «Учебник для вузов»...
Программа курса и план семинарских занятий (Бакалавриат...
Съдържание предговор...



Загрузка...
страницы:   1   2   3   4   5   6   7   8   9   ...   14
скачать


д-р ЕВЕЛИНА ПЕНЧЕВА


ИНФОРМАЦИОННИ ТЕХНОЛОГИИ

В ТЕЛЕКОМУНИКАЦИИТЕ


ПРЕДГОВОР


Учебникът разглежда специфичните за телекомуникационната индустрия софтуерни особености и принципи на изграждане. Комбинацията на индивидуалните характеристики на компютърните системи, работещи в реално време (голям обем, сложност, висока надеждност, непрекъснато обслужване, зависимост от потребителските и териториалните изисквания, сравнително дълъг живот, скорост на отговор и т.н.) в една система е уникален за телекомуникационната техника. Това налага разглеждането на основните характеристики на системите за работа в реално време и съвременните информационни технологии за тяхното разработване и поддържане.

Материалът е организиран в шест глави.

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

Във втората глава са разгледани свойствата на езиците за програмиране, в частност изискванията към тях на системите за работа в реално време. Представени са езиците на Международния съюз по далекосъобщения за проектиране, програмиране и експлоатация на телекомуникационни системи. Направено е кратко въведение в езика SDL.

Принципите на операционните системи като ядро на софтуера на системи за работа в реално време са застъпени в третата глава. Обърнато е внимание на паралелната и разпределена обработка.

В четвъртата глава е направено въведение в теорията на системите бази данни, бази обекти и бази знания. Разгледани са основните модели данни и средствата за управление на транзакциите. Примерите към раздела включват реализации на всеки един от моделите данни за проектиране и поддържане на интелигентни телекомуникационни мрежи.

Петата глава включва основните принципи в обектно-ориентираната технология. Представени са обектно-ориентираните понятия на езика SDL. Обектната ориентация е основна софтуерна рамка при разработването на големи и сложни системи за работа в реално време, като телекомуникационните системи. Разгледани са примери за обектно-ориентирана спецификация и проектиране.

Шестата глава въвежда в теорията на изкуствения интелект. Експертните системи, като продукт на изкуствения интелект със своя потенциал покриват всички области, където е необходимо използването на огромно количество знание на експерти и предлагане на решения на проблеми, които са неподатливи на третиране с конвенционална софтуерна технология. Приложението на технологията на експертните системи е илюстрирано с примери от телекомуникационната практика. Накратко са разгледани основните принципи и понятия в невронните мрежи, връзката им с другите технологии и приложението им в телекомуникациите.

Учебникът е предназначен за студентите от техническите университети. Поради големия обхват на научните области, които покрива съдържанието, за повечето от информационните технологии е дадена само идеята за основните принципи и понятия в светлината на приложението им в телекомуникационната индустрия. Съдържанието на учебника е съобразено с програмата на учебната дисциплина "Софтуерни технологии и системи в телекомуникациите", която се изучава в този си вид от 1994 г. от студентите в специализация "Телекомуникации".


Е. Пенчева.


СЪДЪРЖАНИЕ


Глава 1. Софтуер за работа в реално време


1.1. Управляващи системи за работа в реално време 4

1.1.1.Работа в реално време 4

1.1.2. Индустриални управляващи системи 5

1.1.3. Характеристики на системите за работа в реално време 6

1.1.4. Инженерен подход към проектиране на строги системи за работа в реално време 8

1.2. Софтуерно инженерство 9

1.2.1. Модел на софтуерния жизнен цикъл 9

1.2.2. Икономически аспекти на софтуерното инженерство 12

1.2.3. Класически методи за разработване на софтуер 14

1.2.4. Моделиране 18

1.2.5. Обектно-ориентирано разработване 19

1.2.6. Реализиране с трансформиране 20

1.2.7. Оценка на методите за разработване 21

1.2.8. Технологичност на софтуера за работа в реално време 21

Контрoлни въпроси и задачи 27

Използвана литература 28


Глава 2. Езици за програмиране на системи

за работа в реално време


2.1. Дефиниране на ново лингвинистично ниво 29

2.2. Общи критерии за проектиране на езици за работа в реално време от високо ниво 29

2.3. Езикови изисквания на системите за работа в реално време 31

2.4. Езици на Международния Съюз по Далекосъобщения 32

2.4.1. Език за спецификация и описание SDL 33

2.4.2. Език за програмиране от високо ниво CHILL 40

2.4.3. Език за комуникация потребител-система MML 41

Контрoлни въпроси и задачи 41

Използвана литература 42


Глава 3. Принципи на операционните системи

за работа в реално време


3.1. Изисквания към операционните системи 43

3.2. Синхронно и асинхронно изпълнение на задачи 45

3.3. Многозадачна работа 49

3.4. Синхронизация и комуникация на задачи 54

3.5. Време и управление на събитията 59

3.6. Разпределени операционни системи 60

Контрoлни въпроси и задачи 63

Използвана литература 63


Глава 4. Системи бази данни, бази обекти, бази знания


4.1. Бази данни, бази обекти и бази знания 64

4.1.1. Възможности на базите данни 64

4.1.2. Основна терминология на СУБД 67

4.1.3. Езици за бази данни 69

4.1.4. Модерни приложения на базите данни 71

4.1.5. Системи бази обекти 72

4.1.6. Системи бази знания 73

4.2. Модели данни 75

4.2.1. Прост модел данни 75

4.2.2. Релационен модел данни 77

4.2.3. Мрежов модел данни 80

4.2.4. Йерархичен модел данни 83

4.2.5 Обектен модел 85

4.2.6. Информационен модел на интелигентна мрежа 87

4.2.7. Логиката като модел данни 95

4.3. Управление на транзакциите 101

4.4. Управление на разпределени бази данни 106

4.4.1. Основни проблеми при управлението на разпределени бази данни 107

4.4.2. Проектиране на бази данни за интелигентни мрежи 108

Контрoлни въпроси и задачи 112

Използвана литература 112


Глава 5. Основни принципи на

обектно-ориентираната технология


5.1. Области на приложение 113

5.2. Основни понятия 113

5.3. Термини 116

5.4. Обектно-ориентирано паралелно програмиране 119

5.5. Обектно-ориентирани възможности на SDL 120

5.5.1. Обектно-ориентиран анализ 120

5.5.2. Обектно-ориентирани SDL понятия 120

5.5.3. Обектно-ориентирана SDL спецификация на услугите в интелигентна мрежа 126

5.6. Обектно-ориентираната технология като индустриална софтуерна платформа за телекомуникационни системи 127

5.6.1. Проектиране на архитектура 127

5.6.2. Обектно-ориентирано проектиране на телекомуникационни системи 129

Контрoлни въпроси и задачи 133

Използвана литература 133


Глава 6. Въведение в изкуствения интелект


6.1. Що е изкуствен интелект 134

6.2. Търсене в пространство на състоянията 134

6.2.1 Компоненти на системите за търсене 134

6.2.2. Основни стратегии за обхождане на графа на състоянията при пълно изчерпване 135

6.2.3. Информирано търсене 138

6.3. Представяне и използване на знанията в системите на изкуствения интелект 139

6.3.1. Основни понятия 139

6.3.2. Преглед на методите за представяне на знанията 142

6.4. Експертни системи 147

6.4.1. Основни характеристики на експертните системи 147

6.4.2. Компоненти на експертните системи 147

6.4.3. Придобиване на знания за експертните системи 149

6.4.4. Примери за използване на експертни системи в телекомуникациите 150

6.5. Невронни мрежи 156

6.5.1. Същност на невронните мрежи 156

6.5.2. Характеристики на невронните мрежи 161

6.5.3. Сравнение на невронните мрежи и експертните системи 164

6.5.4. Пример за тип невронна мрежа и алгоритъм за обучение 166

6.5.5. Приложни области на невронните мрежи 167

6.5.6. Невронни мрежи в телекомуникациите 169

Контрoлни въпроси и задачи 172

Използвана литература 173


Списък на използваните съкращения 174


^ ГЛАВА 1. СОФТУЕР ЗА РАБОТА В РЕАЛНО ВРЕМЕ


1.1. Управляващи системи за работа в реално време

1.1.1. Работа в реално време

Основната характеристика на системите за работа в реално време е операционният режим в реално време, който се дефинира по следния начин:

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

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

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

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

* Домакиня, изпълняваща всекидневните си задължения, трябва да наблюдава пералнята машина, да приготвя храната за вечеря и да се грижи за децата. Сигналите, пристигащи от нейната среда, я карат да превключва от една задача на друга и да отговаря със скорост, определена от типа на сигнала. В случай на опасност, когато е застрашено дете, тя трябва да реагира веднага.

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

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

* В система за резервиране на билети за полети на авиолинии средата се състои от клиентите, които изискват резервации за полети. Компютърът, на който се изпълнява системата, трябва да отговаря на заявките на клиентите без да ги кара да чакат повече от определен период от време, който е съобразен с тяхното търпение. Ако компютърът се забави или повреди, клиентът може да се откаже да купи билет, което означава загуба за съответната компания.

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

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

Независимо от общите характеристики, последните два примера се различават значително от другите. Шофьорът, домакинята и управляващата системата на телефонна централа оперират в много строга околна среда. Те трябва винаги да отговарят на време и не могат да прекратят действията си даже и за момент. Банковата система и системата за резервиране на полети работят в по-гъвкави среди. Компютърът трябва да има кратко средно време за отговор, но са допустими и случайни забавяния. Нещо повече в случай на неизправност може да се толерира временно подтискане на действията на системата, като се осигури запазване на данните в базата данни. Разликата е значителна. Това може да бъде изразено чрез отнасянето съответно към строги и нестроги условия за работа в реално време. Последните два примера илюстрират бизнес приложения за работа в реално време с не строги ограничения, където проблемите за интегрирането на данните имат приоритет пред проблемите свързани с времевите ограничения.

Управляващата система на телефонна централа е пример за управляващ процес със строги времеви ограничения, където изискванията за времето на изпълнение са от съществено значение. Строгите и нестрогите системи за работа в реално време се разграничават по изискванията на времевите ограничения. Средите с нестроги условия за работа в реално време се характеризират с увеличаване на разходите при увеличаване на времето за получаване на резултатите. Строгите среди за работа в реално време, не допускат такива закъснения при никакви ситуации, тъй като закъснелите реакции на компютъра или не са от полза, или даже са опасни. Например, в телефонната централа закъснение във времето на активиране на програма за приемане на цифри може да доведе до неправилно приемане на номера; или закъснение на реакцията на шофьора може да стане причина за катастрофа. С други думи, разходите от пропускане на крайните срокове в строгите среди за работа в реално време са изключително високи.


1.1.2. Индустриални управляващи системи

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

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

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

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




^ Фиг.1.1 Технически процес


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

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

Основните елементи на индустриалната управляваща система (фиг.1.2) са:

Хардуерни компоненти:

- Интерфейс на процеса: Множество от хардуерни и програмируеми устройства, които се използват за съгласуване на променливите на процеса с управляващата компютърна система.

- Компютър: Централизирана или разпределена компютърна система, която проверява състоянието на управлявания процес и изчислява контролните променливи (сигнали).

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





^ Фиг. 1.2 Управляваща система за работа в реално време


Софтуерни елементи:

- Операционна система: Множество от програми, които подпомагат изпълнението на всички други програми в компютърната система.

- Приложен софтуер: Множество от програми, реализирани за управление и контрол на даден процес.

- Помощни програми: Множество програми, необходими за разработване и реализиране на приложните програми.

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


1.1.3. Характеристики на системите за работа в реално време

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

- своевременна реакция и

- паралелна обработка.

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

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

- предсказуемост и

- надеждност.

Данните, които трябва да се обработват могат да пристигат случайно разпределени във времето, според дефиницията на режима за работа в реално време. Този факт е довел до широко разпространеното заключение, че поведението на системите за работа в реално време не може и не би могло да бъде детерминирано. Това заключение е базирано на концептуална грешка! Наистина, техническият процес може да бъде толкова сложен, че неговото поведение да изглежда случайно. Реакциите, които трябва да се изпълняват от компютъра обаче, трябва да бъдат прецизно планирани и напълно предсказуеми. Това е в сила особено в случай на едновременно настъпване на няколко събития, водещи до ситуация на състезания за услуга; това също включва преходни претоварвания и ситуации на възникване на неизправности. При тези обстоятелства потребителят очаква, че системата ще понижи техническите си характеристики бавно, по начин прозрачен и забележим за него в бъдеще. Поведението на системата в такива случай трябва да бъде напълно определено и по този начин да гарантира надеждността на програмируеми устройства за приложения, критични по отношение на надеждността. Понятието за предсказуемост и определеност, подходящо в този контекст може да бъде илюстрирано със следния пример. За къща в пламъци, не се знае кога тя ще изгори, но при нормални обстоятелства се очаква пристигането на пожарната команда, след като бъде извикана, за съвсем кратко време. Предсказуемостта на поведението на системата е от изключителна важност за режима на работа в реално време. Тя съпровожда изискването за своевременна реакция, като последното може да бъде гарантирано, ако системното поведение е прецизно предсказуемо, както във времето, така и от гледна точка на реакцията на външно събитие.

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

Дефиницията на режима за работа в реално време налага изискването за надеждност (сигурност) на системите за работа в реално време. Непрекъснатата готовност, изисквана от компютрите, работещи в този режим може да бъде осигурена само, ако системата може да запази нейните операционни характеристики при наличието на неизправности и независимо от неадекватно управление. Това изискване е в сила както за хардуера, така и за софтуера. В частност то е важно за тези приложения, за които неизправности в компютъра не само причиняват загуба на данни и големи инвестиции, но също така са опасни за сигурността и живота на хората. Естествено, очакването за висока надеждност не означава нереалистично изискване за система, която никога не се поврежда, тъй като никоя техническа система не е абсолютно надеждна. Използването на съответни средства, трябва да сведе до минимум нарушаването на крайните срокове и появата на неизправности и то така, че възникването им да е качествено допустимо (т.е. да не води до значително понижаване на техническите характеристики на системата).



^ Фиг. 1.3 Характеристики на системите за работа в реално време


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

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


1.1.4. Инженерен подход към проектиране на строги системи за работа в реално

време

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

Начална точка, от която се тръгва при разработването на всеки голям проект са изискванията към системата. Изискванията се формулират от потребителя. Често пъти на поребителят среща трудности при описание на това, което иска да бъде направено и не вигаги е наясно какво точно трябва да се направи. Обикновено изучаването на потребителските изисквания започва с тяхното описание на естествен език от поребителя. Задачата на проектанта е тяхното детайлизирано описание във вид, който може да бъде проверен за съгласуваност и валидност. Спецификацията на изискванията трябва да включва всички възможни сценарии на събития и трябва ясно да дефинира допустимо поведение в присъствието на неизправности или неадекватни реакции, когато става невъзможно да се продължи нормалното функциониране на системата.

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

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

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

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

Веднъж дефинирана спецификацията на изискванията става основа на всички понататъщни дейности, свързани с разработването на системата: проектиране, реализиране, тестване и изпитание. Тези дейности са ограничени в рамките на предварително опреления бюджет (производствените разходи) и необходимото качество (фиг.1.4).

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

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




^ Фиг.1.4 Мениджънт на софтуерното инженерство


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

 интегрирано виждане за системата - пълна спецификация на всички възможни сценарии на поведението;

 изчисление на техническите характеристики, базирано на ясно разбиране за пиковия товар, който системата трябва да издържи;

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

 архитектури на разпределен хардуер и софтуер


1.2. Софтуерно инженерство

1.2.1. Модел на софтуерния жизнен цикъл

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

^ Софтуерен конфигурационен елемент (или елемент) е съвкупност от софтуерни компоненти с добре дефинирана функционалност, например софтуера на операционна система, който е част от софтуера на комутационна система.

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

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

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

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

 Документите описват текущото състояние за разработката и са база за по-нататъшни дейности по разработването.

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

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




Фиг. 1.5. Модел на софтуерния жизнен цикъл


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

Анализ на изискванията и спецификация: На първата стъпка потребителските изисквания се анализират и документират. Валидността на дадени изисквания се проверява и доказва. Документират се някои предварителни решения, които ограничават понататъшната разработка, като например изисквания за хардуера, операционната система и програмния език. Главният резултат от стъпката е документа:

^ Спецификация на софтуерните изисквания.

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

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

^ Предварително описание на проекта;

План за тестване на софтуера.

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

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

^ Описание на софтуерната структура;

Описание на тестовите процедури на софтуера;

Описание на тестовите процедури на компонентите и единиците.

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

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

^ Изходен (source) код за всяка софтуерна единица;

Тестови процедури и резултати за всяка софтуерна единица;

Тестови процедури за всеки софтуерен компонент.

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

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

^ Изходни кодове за конфигурационни елементи, настроени и без грешки от кодиране;

Описание на системния тест, с процедурите за тестване на елементите;

^ Тестови резултати за всеки софтуерен компонент.

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

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

^ Описание на софтуерния продукт;

Ръководства за оператора и потребителя.

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

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

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

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

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

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





оставить комментарий
страница1/14
Дата04.03.2012
Размер4,12 Mb.
ТипУчебник, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы:   1   2   3   4   5   6   7   8   9   ...   14
Ваша оценка этого документа будет первой.
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

наверх