Програмування

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

ЗАМОК ДРАКОНА

Математика робить те, що можна, так, як треба, то як інформатика робить те, що потрібно, так, як можна.
Програмістський фольклор

Лекція 1.

Надійності програмних засобів ЯК ПРОДУКТ ТЕХНОЛОГІЇ ПРОГРАМУВАННЯ. ІСТОРИЧНИЙ І СОЦІАЛЬНИЙ КОНТЕКСТ ПРОГРАМУВАННЯ

Поняття інформаційного середовища процесу обробки даних. Програма, як формалізований опис процесу. Поняття про програмне засобі. Поняття помилки в програмному засобі. Неконструктивність поняття правильної програми. Надійність програмного засобу. Технологія програмування як технологія розробки надійних програмних засобів. Роль у суспільстві комп'ютерів і програмування, інформатизація суспільства. Взаємозв'язок програмування та інших областей знання. Застосування, зловживання і межі комп'ютерної техніки.

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

Програмний засіб

Метою програмування є опис процесів обробки даних (надалі - просто процесів). Згідно ІФІПа [REF _Ref53418985 \ n \ * MERGEFORMAT 1 ]: Дані - це представлення фактів та ідей у ​​формалізованому вигляді, придатному для передачі і переробки в якомусь процесі, а інформація - це сенс, який надається даними при їх поданні. Обробка даних - це виконання систематичної послідовності дій з даними. Дані представляються і зберігаються на т.зв. носіях даних. Сукупність носіїв даних, використовуваних при будь-якій обробці даних, будемо називати інформаційним середовищем. Набір даних, що містяться в будь-який момент в інформаційному середовищі, будемо називати станом цієї інформаційного середовища. Процес можна визначити як послідовність змінюють один одного станів деякої інформаційного середовища.
Описати процес - означає визначити послідовність станів заданої інформаційного середовища. Якщо ми хочемо, щоб по заданому опису необхідний процес породжувався автоматично на будь-якому комп'ютері, необхідно, щоб цей опис було формалізованим. Такий опис називається програмою. З іншого боку, програма повинна бути зрозумілою і людині, так як і при розробці програм, і при їх використанні часто доводиться з'ясовувати, який саме процес вона породжує. Тому програма складається на зручному для людини формалізованій мові програмування, з якого вона автоматично переводиться на мову відповідної комп'ютера за допомогою іншої програми, званої транслятором. Людині (програмісту), перш ніж скласти програму на зручному для нього мовою програмування, доводиться проробляти велику підготовчу роботу з уточнення постановки задачі, вибору методу її рішення, з'ясуванню специфіки застосування необхідної програми, проясненню загальної організації розробляється програми та багато іншого. Використання цієї інформації може істотно спростити завдання розуміння програми людиною, тому дуже корисно її якось фіксувати у вигляді окремих документів (часто не формалізованих, розрахованих тільки для сприйняття людиною).
Зазвичай програми розробляються в розрахунку на те, щоб ними могли користуватися люди, що не беруть участь в їх розробці (їх називають користувачами). Для освоєння програми користувачем крім її тексту потрібна певна додаткова документація. Програма або логічно пов'язана сукупність програм на носіях даних, забезпечена програмною документацією, називається програмним засобом (ПС). Програма дозволяє здійснювати деяку автоматичну обробку даних на комп'ютері. Програмна документація дозволяє зрозуміти, які функції виконує та чи інша програма ПС, як підготувати вихідні дані і запустити потрібну програму в процес її виконання, а також: що означають отримані результати (або який ефект виконання цієї програми). Крім того, програмна документація допомагає розібратися в самій програмі, що необхідно, наприклад, при її модифікації.

2. Неконструктивність поняття правильної програми

Таким чином, можна вважати, що продуктом технології програмування є ПС, що містить програми, які виконують необхідні функції. Тут під «програмою» часто розуміють правильну програму, тобто програму, що не містить помилок. Однак поняття помилки в програмі трактується в середовищі програмістів неоднозначно. Згідно Майерсу [REF _Ref53419498 \ n \ * MERGEFORMAT 2 ] Будемо вважати, що в програмі є помилка, якщо вона не виконує того, що розумно очікувати від неї користувачеві. «Розумне очікування» користувача формується на підставі документації щодо застосування цієї програми. Отже, поняття помилки в програмі є суттєво не формальним. У цьому випадку правильніше говорити про помилку в ПС. Різновидом помилки в ПС є неузгодженість між програмами ПС та документацією щодо їх застосування. У роботі [REF _Ref53419509 \ n \ * MERGEFORMAT 3 ] Виділяється в окреме поняття приватний випадок помилки в ПС, коли програма не відповідає своїй функціональної специфікації (опису, що розробляється на етапі, що передує безпосередньому програмування). Така помилка в зазначеній роботі називається дефектом програми. Проте виділення такого різновиду помилки в окреме поняття навряд чи виправдано, оскільки причиною помилки може виявитися сама функціональна специфікація, а не програма.
У зв'язку з тим, що завдання на ПС зазвичай формулюється не формально, а також з-за неформалізованності поняття помилки в ПС, не можна довести формальними методами (математично) правильність ПС. Не можна показати правильність ПС та тестуванням: як зазначив Дейкстра [REF _Ref53419524 \ n \ * MERGEFORMAT 4 ], Тестування може лише продемонструвати наявність в ПС помилки. Тому поняття правильної ПС неконструктивно в тому сенсі, що після закінчення роботи над створенням ПС ми не зможемо переконатися, що досягли мети.

3. 1.3. Надійність програмного засобу

Альтернативою правильного ПС є надійне ПС. Надійність ПС - це його здатність безвідмовно виконувати певні функції при заданих умовах протягом заданого періоду часу з досить великою імовірністю [REF _Ref53419550 \ n \ * MERGEFORMAT 5 ]. При цьому під відмовою в ПС розуміють вияв в ньому помилки [REF _Ref53419498 \ n \ * MERGEFORMAT 2 ]. Таким чином, надійна ПС не виключає наявності в ній помилок - важливо лише, щоб ці помилки при практичному застосуванні цього ПС в заданих умовах виявлялися досить рідко. Переконатися, що ПС має таку властивість можна при його випробуванні шляхом тестування, а також при практичному застосуванні. Таким чином, фактично ми можемо розробляти лише надійні, а не правильні ПС.
Розробляється ПС може володіти різним ступенем надійності. Як вимірювати цю ступінь? Так само як в техніці, ступінь надійності можна характеризувати [REF _Ref53419498 \ n \ * MERGEFORMAT 2 ] Ймовірністю роботи ПС без відмови в перебігу певного періоду часу. Однак у силу специфічних особливостей ПС визначення цієї імовірності наштовхується на ряд труднощів у порівнянні з вирішенням цього завдання в техніці. Пізніше ми повернемося до більш докладному обговоренню цього питання.
При оцінці ступеня надійності ПС слід також враховувати наслідки кожного відмови. Деякі помилки в ПС можуть викликати лише деякі незручності при його застосуванні, тоді як інші помилки можуть мати катастрофічні наслідки, наприклад, загрожувати людського життя. Тому для оцінки надійності ПС іноді використовують додаткові показники, що враховують вартість (шкода) для користувача кожного відмови.

4. Технологія програмування як технологія розробки надійних програмних засобів

Відповідно до звичайного значення слова «технологія» [REF _Ref53419621 \ n \ * MERGEFORMAT 6 ] Під технологією програмування будемо розуміти сукупність виробничих процесів, що приводить до створення необхідного ПС, а також опис цієї сукупності процесів. Іншими словами, технологію програмування ми будемо розуміти тут в широкому сенсі як технологію розробки програмних засобів, включаючи в неї всі процеси, починаючи з моменту зародження ідеї цього кошти, і, зокрема, пов'язані зі створенням необхідної програмної документації. Кожен процес цієї сукупності базується на використанні будь-яких методів і засобів, наприклад, комп'ютер (у цьому випадку будемо говорити про комп'ютерної технології програмування).
У літературі є й інші, дещо відрізняються, визначення технології програмування. Ці визначення обговорюються в роботі [REF _Ref53419638 \ n \ * MERGEFORMAT 7 ]. Використовується в літературі і близьке до технології програмування поняття програмної інженерії, яка визначається як систематичний підхід до розробки, експлуатації, супроводу і вилученню з обігу програмних засобів [REF _Ref53419638 \ n \ * MERGEFORMAT 7 ]. Саме програмної інженерії (Software Engineering) присвячена згадана робота [REF _Ref53419509 \ n \ * MERGEFORMAT 3 ]. Головна відмінність між технологією програмування і програмної інженерії як дисциплінами для вивчення полягає у способі розгляду та систематизації матеріалу. У технології програмування акцент робиться на вивченні процесів розробки ПС (технологічних процесів) і порядку їх проходження - методи та інструментальні засоби розробки ПС використовуються в цих процесах (їх застосування і утворюють технологічні процеси). Тоді як у програмній інженерії вивчаються перш за все методи та інструментальні засоби розробки ПС з точки зору досягнення певних цілей - вони можуть використовуватися в різних технологічних процесах (і в різних технологіях програмування); як ці методи і засоби утворюють технологічні процеси - тут питання другорядне.
Не слід також плутати технологію програмування з методологією програмування [REF _Ref53419672 \ n \ * MERGEFORMAT 8 ]. Хоча в обох випадках вивчаються методи, але в технології програмування методи розглядаються «згори» (з точки зору організації технологічних процесів), а в методології програмування методи розглядаються «знизу» (з точки зору основ їх побудови). У роботі [REF _Ref53419684 \ n \ * MERGEFORMAT 9 , Стор 25] методологія програмування визначається як сукупність механізмів, що застосовуються в процесі розробки програмного забезпечення та об'єднаних одним загальним філософським підходом.
Маючи на увазі, що надійність є невід'ємним атрибутом ПС, ми будемо обговорювати технологію програмування як технологію розробки надійних ПС. Це означає, що, по-перше, ми будемо обговорювати всі процеси розробки ПС, починаючи з моменту виникнення задуму ПС. По-друге, нас будуть цікавити не тільки питання побудови програмних конструкцій, але і питання опису функцій та прийнятих рішень з точки зору їх людського (неформального) сприйняття, і, нарешті, в якості продукту технології ми будемо приймати надійну (а не правильну) ПС . Все це буде істотно впливати на вибір методів та інструментальних засобів у процесах розробки ПС.

5. Технологія програмування та інформатизація суспільства

Технології програмування відігравало різну роль на різних етапах розвитку програмування. У міру підвищення потужності комп'ютерів і розвитку засобів і методології програмування росла і складність розв'язуваних на комп'ютерах завдань, що призвело до підвищеної уваги до технології програмування. Різке здешевлення вартості комп'ютерів і, особливо, вартості зберігання інформації на комп'ютерних носіях призвело до широкого впровадження комп'ютерів практично у всі сфери людської діяльності, що істотно змінило спрямованість технології програмування. Людський чинник став грати в ній вирішальну роль. Сформувалося досить глибоке поняття якості ПС, в якому акценти стали ставиться не стільки на його ефективності, скільки на зручності роботи з ним для користувачів (не кажучи вже про його надійність). Широке використання комп'ютерних мереж призвело до інтенсивного розвитку розподілених обчислень, дистанційного доступу до інформації та електронного способу обміну повідомленнями між людьми. Комп'ютерна техніка із засобу вирішення окремих завдань все більше перетворюється на засіб інформаційного моделювання реального і можливого світу, здатне просто відповідати людям на їхні запитання. Починається етап глибокої і повної інформатизації (комп'ютеризації) людського суспільства. Все це ставить перед технологією програмування нові і досить важкі проблеми.
Зробимо коротку характеристику розвитку програмування по десятиліттях.
У 50-ті роки потужність комп'ютерів (комп'ютери першого покоління) була невелика, а програмування для них велося, в основному, в машинному коді. Вирішувалися, головним чином, науково-технічні завдання (рахунок за формулами), завдання на програмування вже містило, як правило, досить точну постановку задачі. Використовувалася інтуїтивна технологія програмування: майже відразу приступали до складання програми за завданням, при цьому часто завдання кілька разів змінювалося (що сильно збільшувало час і без того ітераційного процесу складання програми), мінімальна документація оформлялася вже після того, як програма починала працювати. Тим не менше, саме в цей період народилася фундаментальна для технології програмування концепція модульного програмування [REF _Ref53419823 \ n \ * MERGEFORMAT 10 ] (Для подолання труднощів програмування в машинному коді). З'явилися перші мови програмування високого рівня, з яких тільки ФОРТРАН пробився для використання в наступні десятиліття.
У 60-і роки можна було спостерігати бурхливий розвиток і широке використання мов програмування високого рівня (АЛГОЛ 60, ФОРТРАН, КОБОЛ та ін), роль яких в технології програмування явно перебільшувалася. Надія на те, що ці мови вирішать всі проблеми при розробки великих програм, не виправдалася. У результаті підвищення потужності комп'ютерів та накопичення досвіду програмування на мовах високого рівня швидко зростала складність розв'язуваних на комп'ютерах завдань, у результаті чого виявилася обмеженість мов, що проігнорували модульну організацію програм. І тільки ФОРТРАН, дбайливо зберіг можливість модульного програмування, гордо пройшов у наступні десятиліття (всі його лаяли, але його користувачі відмовитися від його послуг не могли через грандіозного накопичення фонду програмних модулів, які з успіхом використовувалися в нових програмах). Крім того, було зрозуміле, що важливо не тільки те, якою мовою ми програмуємо, але й те, як ми програмуємо [REF _Ref53419524 \ n \ * MERGEFORMAT 4 ]. Це було вже початком серйозних роздумів над методологією і технологією програмування. Поява в комп'ютерах 2-го покоління переривань призвело до розвитку мультипрограмування і створення великих програмних систем. Це стало можливим з використанням колективної розробки, яка поставила ряд серйозних технологічних проблем [REF _Ref53419854 \ n \ * MERGEFORMAT 11 ].
У 70-і роки одержали широке поширення інформаційні системи і бази даних. Цьому сприяло дуже важлива подія, що відбулася у середині 70-их років: вартість зберігання одного біта інформації на комп'ютерних носіях стала менше, ніж на традиційних. Інтенсивно розвивалася технологія програмування [REF _Ref53419498 \ n \ * MERGEFORMAT 2 , REF _Ref53419672 \ n \ * MERGEFORMAT 8 , REF _Ref53419899 \ n \ * MERGEFORMAT 12 , REF _Ref53419903 \ n \ * MERGEFORMAT 13 , REF _Ref53419906 \ n \ * MERGEFORMAT 14 ]: Обгрунтування та широке впровадження низхідній розробки та структурного програмування, розвиток абстрактних типів даних і модульного програмування (зокрема, виникнення ідеї поділу специфікації і реалізації модулів і використання модулів, що приховують структури даних), дослідження проблем забезпечення надійності та мобільності ПС, створення методики управління колективної розробкою ПС, поява інструментальних програмних засобів (програмних інструментів) підтримки технології програмування.
До корисних випадків використання оператора переходу можна віднести вихід з циклу або процедури по особливому умові, "достроково" припиняє роботу даного циклу або даної процедури, тобто завершального роботу деякої структурної одиниці (узагальненого оператора) і тим самим лише локально порушує структурованість програми. Великі труднощі (і ускладнення структури) викликає структурну реалізацію реакції на виникаючі виняткові (часто помилкові) ситуації, тому що при цьому потрібно не тільки здійснити достроковий вихід зі структурної одиниці, а й зробити необхідну обробку (виключення) цієї ситуації (наприклад, видачу відповідної діагностичної інформації). Оброблювач виняткової ситуації може перебувати на будь-якому рівні структури програми, а звернення до нього може здійснюватися з різних нижніх рівнів. Цілком прийнятною з технологічної точки зору є наступна "неструктурних" реалізація реакції на виняткові ситуації [8.7]. Обробники виняткових ситуацій поміщаються в кінці тієї чи іншої структурної одиниці і кожен такий обробник програмується таким чином, що після закінчення своєї роботи виробляє вихід з тієї структурної одиниці, в кінці якої він поміщений. Звернення до такого оброблювачу проводиться оператором переходу з даної структурної одиниці (включаючи будь-яку вкладену в неї структурну одиницю).
8.3. Покрокова деталізація і поняття про псевдокоде.
Структурне програмування дає рекомендації про те, яким повинен бути текст модуля. Виникає питання, як повинен діяти програміст, щоб побудувати такий текст. Іноді програмування модуля починають з побудови його блок-схеми, що описує в загальних рисах логіку його роботи. Однак сучасна технологія програмування не рекомендує цього робити. Хоча блок-схеми дозволяють вельми наочно уявити логіку роботи модуля, при їх кодуванні на мові програмування виникає дуже специфічний джерело помилок: відображення істотно двовимірних структур, якими є блок-схеми, на лінійний текст, який представляє модуль, містить небезпеку спотворення логіки роботи модуля, тим більше, що психологічно досить важко зберегти високий рівень уваги при повторному її розгляді. Винятком може бути випадок, коли для побудови блок-схем використовується графічний редактор і вони формалізовані настільки, що за ним автоматично генерується текст на мові програмування (як наприклад, це може робитися в Р - технології [8.6]).
В якості основного методу побудови тексту модуля сучасна технологія програмування рекомендує покрокову деталізацію [8.1, 8.3, 8.5]. Сутність цього методу полягає в розбитті процесу розробки тексту модуля на низку кроків. На першому кроці описується загальна схема роботи модуля в доступній для огляду лінійної текстовій формі (тобто з використанням дуже великих понять), причому цей опис не є повністю формалізованим і орієнтоване на сприйняття його людиною. На кожному наступному кроці проводиться уточнення і деталізація одного з понять (будемо називати його уточнюється), використаного (як правило, не формалізовано) в будь-якому описі, розробленому на одному з попередніх кроків. У результаті такого кроку створюється опис вибраного уточнюється поняття або в термінах базової мови програмування (тобто обраного для представлення модуля), або в такій же формі, що і на першому кроці з використанням нових уточнюється поняття. Цей процес завершується, коли всі уточнює поняття будуть виражені в кінцевому рахунку на базовому мовою програмування. Останнім кроком є ​​отримання тексту модуля на базовому мовою програмування шляхом заміни всіх входжень уточнюється поняття заданими їх описами і вираз всіх входжень конструкцій структурного програмування засобами цієї мови програмування.
Покрокова деталізація пов'язана з використанням частково формалізованої мови для подання зазначених описів, який отримав назву псевдокоду [8.5, 8.8]. Ця мова дозволяє використовувати всі конструкції структурного програмування, які оформляються формалізовано, разом з неформальними фрагментами на природному мовою для подання узагальнених операторів і умов. В якості узагальнених операторів і умов можуть задаватися і відповідні фрагменти на базовому мовою програмування.
Головним описом на псевдокоді можна вважати зовнішнє оформлення модуля на базовому мовою програмування, яке
повинно містити:
початок модуля на базовому мовою, тобто перше речення або заголовок (специфікацію) цього модуля [8.1];
розділ (сукупність) описів на базовому мовою, причому замість описів процедур і функцій - тільки їх зовнішнє оформлення;
неформальне позначення послідовності операторів тіла модуля як одного узагальненого оператора (див. нижче), а також неформальне позначення послідовності операторів тіла кожного опису процедури або функції як одного узагальненого оператора;
останнє речення (кінець) модуля на базовому мовою [8.1].
Зовнішнє оформлення опису процедури або функції пропонується аналогічно. Втім, якщо слідувати Дейкстри [8.2], розділ описів краще також представити тут неформальним позначенням, зробивши його деталізацію у вигляді окремого опису.
Неформальне позначення узагальненого оператора на псевдокоді виробляється на природній мові довільним пропозицією, що розкриває в загальних рисах його зміст. Єдиною формальною вимогою до оформлення такого позначення є наступне: це пропозиція повинна займати цілком одне або декілька графічних (друкованих) рядків і завершуватися крапкою.
Для кожного неформального узагальненого оператора має бути створено окремий опис, що виражає логіку його роботи (деталізує його зміст) за допомогою композиції основних конструкцій структурного програмування та інших узагальнених операторів. Як заголовок такого опису повинно бути неформальне позначення деталізіруемого узагальненого оператора. Основні конструкції структурного програмування можуть бути представлені в наступному вигляді (див. рис. 8.2). Тут умова може бути або явно задано на базовому мовою програмування в якості булевского вираження, або неформально представлено на природній мові деяким фрагментом, що розкриває в загальних рисах зміст цього умови. В останньому випадку має бути створено окремий опис, деталізують це умова, із зазначенням в якості заголовка позначення цієї умови (фрагменту на природній мові).
Проходження:
обобщенний_оператор
обобщенний_оператор
Розгалуження:
ЯКЩО умова ТО
обобщенний_оператор
ІНАКШЕ
обобщенний_оператор
ВСІ ЯКЩО
Повторення:
ПОКИ умова РОБИТИ
обобщенний_оператор
ВСІ ПОКИ
Рис. 8.2. Основні конструкції структурного програмування на псевдокоде.
Вихід з повторення (циклу):
ВИЙТИ
Вихід з процедури (функції):
ПОВЕРНУТИСЯ
Перехід на обробку виняткової ситуації:
ПОРУШИЛА імя_ісключенія
Рис. 8.3. Окремі випадки оператора переходу в якості узагальненого оператора.
В якості узагальненого оператора на псевдокоді можна використовувати зазначені вище окремі випадки оператора переходу (див. рис. 8.3). Послідовність обробників виняткових ситуацій (виключень) задається в кінці модуля або опису процедури (функції). Кожен такий обробник має вигляд:
ВИКЛЮЧЕННЯ імя_ісключенія
обобщенний_оператор
ВСІ ВИКЛЮЧЕННЯ
Відмінність обробника виняткової ситуації від процедури без параметрів полягає в наступному: після виконання процедури управління повертається до оператора, наступного за зверненням до неї, а після виконання винятку управління повертається до оператора, наступного за зверненням до модуля або процедурі (функції), в кінці якого ( якої) вміщено цей виняток.
Рекомендується на кожному кроці деталізації створювати досить змістовний опис, але легко доступне для огляду (наочне), так щоб воно розміщувалося на одній сторінці тексту. Як правило, це означає, що такий опис має бути композицією п'яти-шести конструкцій структурного програмування. Рекомендується також вкладені конструкції розташовувати із зсувом вправо на кілька позицій (див. рис. 8.4). У результаті можна отримати опис логіки роботи за наочністю цілком конкурентне з блок-схемами, але володіє істотною перевагою - зберігається лінійність опису.
ВИДАЛЕННЯ У файл запису ДО ПЕРШОЇ,
Відповідають указаним ФІЛЬТРИ:
ВСТАНОВИТИ ПОЧАТОК ФАЙЛУ.
ПОКИ НЕ КІНЕЦЬ ФАЙЛУ РОБИТИ
ПРОЧИТАТИ ЧЕРГОВУ ЗАПИС.
ЯКЩО ЧЕРГОВА ЗАПИС ЗАДОВОЛЬНЯЮТЬ
ФІЛЬТРИ ТО
ВИЙТИ
ІНАКШЕ
ВИДАЛИТИ ЧЕРГОВУ ЗАПИС З ФАЙЛУ.
ВСІ ЯКЩО
ВСІ ПОКИ
ЯКЩО ЗАПИСИ НЕ ВИДАЛЕНІ ТО
Надрукувати "ЗАПИСИ НЕ ВИДАЛЕНІ".
ІНАКШЕ
Надрукувати "ВИДАЛЕНО н ЗАПИСІВ".
ВСІ ЯКЩО
Рис. 8.4. Приклад одного кроку деталізації на псевдокоде.
Ідею покрокової деталізації приписують іноді Дейкстри [8.1]. Однак Дейкстра пропонував принципово відрізняється метод побудови тексту модуля [8.2], який нам видається більш глибоким і перспективним. По-перше, разом з уточненням операторів він пропонував поступово (по кроках) уточнювати (деталізувати) і використовувані структури даних. По-друге, на кожному кроці він пропонував створювати деяку віртуальну машину для деталізації і в її термінах виробляти деталізацію всіх уточнюється поняття, для яких ця машина дозволяє це зробити. Таким чином, Дейкстра пропонував, по-суті, деталізувати по горизонтальних верствам, що є перенесенням його ідеї про шаруватих системах (див. лекцію 6) на рівень розробки модуля. Такий метод розробки модуля підтримується в даний час пакетами мови АДА [8.7] і засобами об'єктно-орієнтованого програмування [8.9].
8.4. Контроль програмного модуля.
Застосовуються наступні методи контролю програмного модуля:
статична перевірка тексту модуля;
наскрізне простежування;
доказ властивостей програмного модуля.
При статичній перевірці тексту модуля цей текст прочитується з початку до кінця з метою знайти помилки в модулі. Зазвичай для такої перевірки залучають, крім розробника модуля, ще одного або навіть декількох програмістів. Рекомендується помилки, які виявляються при такій перевірці виправляти не відразу, а по завершенню читання тексту модуля.
Наскрізне простежування представляє собою один з видів динамічного контролю модуля. У ньому також беруть участь кілька програмістів, які вручну прокручують виконання модуля (оператор за оператором в тій послідовності, яка випливає з логіки роботи модуля) на деякому наборі тестів.
Доказу властивостей програм присвячена наступна лекція. Тут варто лише зазначити, що цей метод застосовується поки дуже рідко.

Література до лекції 8.
8.1. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980. - С. 127-154.
8.2. Е. Дейкстра. Нотатки з структурному програмуванню / / У. Дал, Е. Дейкстра, К. Хоор. Структурне програмування. - М.: Світ, 1975. - С. 24-97.
8.3. Н. Вірт. Систематичне програмування. - М.: Світ, 1977. - С. 94-164.

Лекція 9. ДОКАЗ ВЛАСТИВОСТЕЙ ПРОГРАМ
Поняття обгрунтування програм. Формалізація властивостей програм, тріади Хоорі. Правила для встановлення властивостей оператора присвоєння, умовного та складеного операторів. Правила для встановлення властивостей оператора циклу, поняття інваріанта циклу. Завершімость виконання програми.
9.1. Обгрунтування програм. Формалізація властивостей програм.
Для підвищення надійності програмних засобів дуже корисно постачати програми додатковою інформацією, з використанням якої можна істотно підвищити рівень контролю ПС. Таку інформацію можна задавати у формі неформалізованих або формалізованих тверджень, що прив'язуються до різних фрагментів програм. Будемо називати такі твердження обгрунтуваннями програми. Неформалізовані обгрунтування програм можуть, наприклад, пояснювати мотиви прийняття тих чи інших рішень, що може істотно полегшити пошук і виправлення помилок, а також вивчення програм при їх супроводі. Формалізовані ж обгрунтування дозволяють доводити деякі властивості програм як вручну, так і контролювати (встановлювати) їх автоматично.
Однією з використовуваних в даний час концепцій формальних обгрунтувань програм є використання так званих тріад Хоорі. Нехай S - деякий узагальнений оператор над інформаційним середовищем IS, P і Q - деякі предикати (затвердження) над цим середовищем. Тоді запис {P} S {Q} і називають тріадою Хоорі, в якій предикат P називають передумовою, а предикат Q - постусловіем щодо оператора S. Кажуть, що оператор (зокрема, програма) S має властивість {P} S {Q}, якщо кожного разу, коли перед виконанням оператора S правдивий предикат P, після виконання цього оператора S буде правдивий предикат Q.
Прості приклади властивостей програм:
(9.1) {n = 0} n: = n +1 {n = 1},
(9.2) {n <m} n: = n + k {n <m + k},
(9.3) {n <m + k} n: = 3 * n {n <3 * (m + k)},
(9.4) {n> 0} p: = 1; m: = 1;
ПОКИ m / = n РОБИТИ
m: = m +1; p: = p * m
ВСІ ПОКИ
{P = n!}.
Для доказу властивості програми S використовуються властивості простих операторів мови програмування (ми тут обмежимося порожнім оператором і оператором присвоєння) і властивостями керуючих конструкцій (композицій), за допомогою яких будується програма з простих операторів (ми тут обмежимося трьома основними композиціями структурного програмування, див. Лекцію 8). Ці властивості називають зазвичай правилами верифікації програм.
9.2. Властивості простих операторів.
Для порожнього оператора справедлива
Теорема 9.1. Нехай P - предикат над інформаційним середовищем. Тоді має місце властивість {P} {P}.
Доказ цієї теореми очевидно: порожній оператор не змінює стан інформаційного середовища (у відповідності зі своєю семантикою), тому його передумову зберігає істинність і після його виконання.
Для оператора присвоювання справедлива
Теорема 9.2. Нехай інформаційне середовище IS складається із змінної X і решті частини інформаційного середовища RIS:
IS = {X, RIS}.
Тоді має місце властивість
{Q (F (X, RIS), RIS)} X: = F (X, RIS) {Q (X, RIS)},
де F (X, RIS) - деяка однозначна функція, Q - предикат.
Доказ. Нехай до виконання оператора присвоювання був правдивий предикат Q (F (X0, RIS0), RIS0), де {X0, RIS0} - деяке довільне стан інформаційного середовища IS, тоді після виконання оператора присвоювання буде правдивий предикат Q (X, RIS), так як X набуде значення F (X0, RIS0), а стан RIS не змінюється даним оператором присвоювання, і, отже, після виконання цього оператора присвоювання в цьому випадку
Q (X, RIS) = Q (F (X0, RIS0), RIS0).
У силу довільності вибору стану інформаційного середовища теорема доведена.
Прикладом властивості оператора присвоювання може служить приклад 9.1.
9.3. Властивості основних конструкцій структурного програмування.
Розглянемо тепер властивості основних конструкцій структурного програмування: слідування, розгалуження і повторення.
Властивості прямування висловлює наступна
Теорема 9.3. Нехай P, Q і R - предикати над інформаційним середовищем, а S1 і S2 - узагальнені оператори, що володіють відповідно властивостями
{P} S {Q} і {Q} S2 {R}.
Тоді для складеного оператора
S1; S2 <. Blockquote>
має місце властивість
{P} S1; S2 {R}.
Доказ. Нехай для деякого стану інформаційного середовища перед виконанням оператора S1 правдивий предикат P. Тоді в силу властивості оператора S1 після його виконання буде правдивий предикат Q. Так як за семантикою складеного оператора після виконання оператора S1 буде виконуватися оператор S2, то предикат Q буде правдивий і перед виконанням оператора S2. Отже, після виконання оператора S2 в силу його властивості буде правдивий предикат R, а так як оператор S2 завершує виконання складеного оператора (відповідно до його семантикою), то предикат R буде правдивий і після виконання даного складеного оператора, що й потрібно було довести.
Наприклад, якщо мають місце властивості (9.2) і (9.3), то має
місце і властивість
{N <m} n: = n + k; n: = 3 * n {n <3 * (m + k)}.
Властивість розгалуження висловлює наступна
Теорема 9.4. Нехай P, Q і R - предикати над інформаційним середовищем, а S1 і S2 - узагальнені оператори, що володіють відповідно властивостями
{P, Q} S1 {R} і {`P, Q} S2 {R}.
Тоді для умовного оператора
ЯКЩО P ТО S1 ІНАКШЕ S2 ВСІ ЯКЩО
має місце властивість
{Q} ЯКЩО P ТО S1 ІНАКШЕ S2 ВСІ ЯКЩО {R}.
Доказ. Нехай для деякого стану інформаційного середовища перед виконанням умовного оператора правдивий предикат Q. Якщо при цьому буде правдивий також і предикат P, то виконання умовного оператора відповідно до його семантикою зводиться до виконання оператора S1. З огляду на ж властивості оператора S1 після його виконання (а у цьому випадку - і після виконання умовного оператора) буде правдивий предикат R. Якщо ж перед виконанням умовного оператора предикат P буде хибна (а Q, як і раніше, правдивий), то виконання умовного оператора відповідно до його семантикою зводиться до виконання оператора S2. З огляду на ж властивості оператора S2 після його виконання (а у цьому випадку - і після виконання умовного оператора) буде правдивий предикат R. Тим самим теорема повністю доведена.
Перш ніж переходити до властивості конструкції повторення слід відзначити корисну для подальшого
Теорему 9.5. Нехай P, Q, P1 і Q1 - предикати над інформаційним середовищем, для яких справедливі імплікації
P1 => P і Q => Q1,
і нехай для оператора S має місце властивість {P} S {Q}. Тоді має місце властивість {P1} S {Q1}.
Цю теорему називають ще теоремою про ослаблення властивостей.
Доказ. Нехай для деякого стану інформаційного середовища перед виконанням оператора S правдивий предикат P1. Тоді буде правдивий і предикат P (в силу імплікації P1 => P). Отже, в силу властивості оператора S після його виконання буде правдивий предикат Q, а значить і предикат Q1 (в силу імплікації Q => Q1). Тим самим теорема доведена.
Властивість повторення висловлює наступна
Теорема 9.6. Нехай I, P, Q і R - предикати над інформаційним середовищем, для яких справедливі імплікації
P => I (I, `Q) => R,
і нехай S - узагальнений оператор, що володіє властивістю {I} S {I}.
Тоді для оператора циклу
ПОКИ Q РОБИТИ S ВСІ ПОКИ
має місце властивість
{P} ПОКИ Q РОБИТИ S ВСІ ПОКИ {R}.
Предикат I називають інваріантом оператора циклу.
Доказ. Для доказу цієї теореми достатньо довести властивість
{I} ПОКИ Q РОБИТИ S ВСІ ПОКИ {I, `Q}
(По теоремі 9.5 на підставі наявних в умовах даної теореми імплікацій). Нехай для деякого стану інформаційного середовища перед виконанням оператора циклу правдивий предикат I. Якщо при цьому предикат Q буде хибна, то оператора циклу буде еквівалентний порожньому оператору (відповідно до його семантикою) і в силу теореми 9.1 після виконання оператора циклу буде справедливо твердження (I, `Q). Якщо ж перед виконанням оператора циклу предикат Q буде правдивий, то оператор циклу у відповідності зі своєю семантикою може бути представлений у вигляді складеного оператора S; ПОКИ Q РОБИТИ S ВСІ ПОКИ
У силу властивості оператора S після його виконання буде правдивий предикат I, і виникає вихідна ситуація для доказу властивості оператора циклу: предикат I правдивий перед виконанням оператора циклу, але вже для іншого (зміненого) стану інформаційного середовища (для якого предикат Q може бути або правдивий або хибна). Якщо виконання оператора циклу завершується, то застосовуючи метод математичної індукції ми за кінцеве число кроків, прийдемо до ситуації, коли перед його виконанням буде справедливо твердження (I, `Q). А в цьому випадку, як було доведено вище, це твердження буде справедливо і після виконання оператора циклу. Теорема доведена.
Наприклад, для оператора циклу з прикладу (9.4) має місце властивість
{N> 0, p = 1, m = 1} ПОКИ m / = n РОБИТИ
m: = m +1; p: = p * m
ВСІ ПОКИ {p = n!}.
Це випливає з теореми 9.6, так як інваріантом цього оператора циклу є предикат p = m! і справедливі імплікації (n> 0, p = 1, m = 1) => p = m! і (p = m!, m = n) => p = n!

9.4. Завершімость виконання програми.
Одне з властивостей програми, яке нас може цікавити, щоб уникнути можливих помилок в ПС, є її завершімость, тобто відсутність в ній зациклення при тих чи інших вихідних даних. У розглянутих нами структурованих програмах джерелом зациклення може бути тільки конструкція повторення. Тому для доказу завершімості програми достатньо вміти доводити завершімость оператора циклу. Для цього корисна наступна
Теорема 9.7. Нехай F - цілочисельна функція, що залежить від стану інформаційного середовища і задовольняє таким умовам:
(1) якщо для даного стану інформаційного середовища правдивий предикат Q, то її значення позитивно;
(2) вона зменшується при зміні стану інформаційного середовища в результаті виконання оператора S.
Тоді виконання оператора циклу
ПОКИ Q РОБИТИ S ВСІ ПОКИ завершується.
Доказ. Нехай is - стан інформаційного середовища перед виконанням оператора циклу і нехай F (is) = k. Якщо предикат Q (is) хибна, то виконання оператора циклу завершується. Якщо ж Q (is) правдивий, то за умовою теореми k> 0. У цьому випадку буде виконуватися оператор S один або більше разів. Після кожного виконання оператора S за умовою теореми значення функції F зменшується, а так як перед виконанням оператора S предикат Q повинен бути правдивий (за семантикою оператора циклу), то значення функції F у цей момент має бути позитивно (за умовою теореми). Тому в силу цілочисельності функції F оператор S в цьому ціклене може виконуватися більш k разів. Теорема доведена.
Наприклад, для розглянутого вище прикладу оператора ціклаусловіям теореми 9.7 задовольняє функція f (n, m) = nm. Так як перед виконанням оператора циклу m = 1, то тіло цього циклу буде виконуватись (n-1) раз, тобто цей оператор циклу завершується.
9.5. Приклад докази властивості програми.
На основі доведених правил верифікації програм можна доводити властивості програм, що складаються з операторів присвоювання і порожніх операторів і використовують три основні композиції структурного програмування. Для цього аналізуючи структуру програми і використовуючи задані її перед-і Післяумови необхідно на кожному кроці аналізу застосовувати відповідне правило верифікації. У разі застосування композиції повторення потрібно підібрати відповідний інваріант циклу.
Як приклад доведемо властивість (9.4). Це доказ буде складатися з наступних кроків.
(Крок 1). n> 0 => (n> 0, p - будь-яке, m - будь-яке).
(Крок 2). Має місце
{N> 0, p - будь-яке, m - будь} p: = 1 {n> 0, p = 1, m - будь-}.
- По теоремі 9.2.
(Крок 3). Має місце
{N> 0, p = 1, m - будь} m: = 1 {n> 0, p = 1, m = 1}.
- По теоремі 9.2.
(Крок 4). Має місце
{N> 0, p - будь-яке, m - будь} p: = 1; m: = 1 {n> 0, p = 1, m = 1}.
- По теоремі 9.3 чинності результатів кроків 2 і 3.
Доведемо, що предикат p = m! є інваріантом циклу, тобто {P = m!} m: = m +1; p: = p * m {p = m!}.
(Крок 5). Має місце {p = m!} m: = m +1 {p = (m-1)!}.
- По теоремі 9.2, якщо уявити передумову у вигляді {p = ((m +1) -1)!}.
(Дія 6). Має місце {p = (m-1)!} P: = p * m {p = m!}.
- По теоремі 9.2, якщо уявити передумову у вигляді {p * m = m!}.
(Крок 7). Має місце інваріант цикл
{P = m!} m: = m +1; p: = p * m {p = m!}.
- По теоремі 9.3 чинності результатів кроків 5 і 6.
(Крок 8). Має місце
{N> 0, p = 1, m = 1} ПОКИ m / = n РОБИТИ
m: = m +1; p: = p * m
ВСІ ПОКИ {p = n!}.
- По теоремі 9.6 чинності результату кроку 7 і маючи на увазі, що (n> 0, p = 1, m = 1) => p = m!; (p = m!, m = n) => p = n!.
(Крок 9). Має місце
{N> 0, p - будь-яке, m - будь} p: = 1; m: = 1;
ПОКИ m / = n РОБИТИ
m: = m +1; p: = p * m
ВСІ ПОКИ {p = n!}.
- По теоремі 9.3 чинності результатів кроків 3 і 8.
(Крок 10). Має місце властивість (9.4) за теоремою 9.5 чинності результатів кроків 1 і 9.

Література до лекції 9.
9.1. С.А. Абрамов. Елементи програмування. - М.: Наука, 1982. С. 85-94.
9.2. М. Зелковец, А. Шоу, Дж. Геннон. Принципи розробки програмного забезпечення. - М.: Світ, 1982. С. 98-105.

Лекція 10. ТЕСТУВАННЯ І НАЛАГОДЖЕННЯ ПРОГРАМНОГО ЗАСОБУ
Основні поняття. Стратегія проектування тестів. Заповіді налагодження. Автономна налагодження та тестування програмного модуля. Комплексне налагодження і тестування програмного засобу.
10.1. Основні поняття.
Налагодження ПС - це діяльність, спрямована на виявлення та виправлення помилок у ПС з використанням процесів виконання його програм. Тестування ПС - це процес виконання його програм на деякому наборі даних, для якого наперед відомий результат застосування або відомі правила поведінки цих програм. Зазначений набір даних називається тестовим або просто тестом. Таким чином, налагодження можна представити у вигляді багаторазового повторення трьох процесів: тестування, в результаті якого може бути констатована наявність в ПС помилки, пошуку місця помилки в програмах і документації ПС та редагування програм та документації з метою усунення виявленої помилки. Іншими словами:
Налагодження = Тестування + Пошук помилок + Редагування.
У зарубіжній літературі налагодження часто розуміють [10.1-10.3] лише як процес пошуку і виправлення помилок (без тестування), факт наявності яких встановлюється при тестуванні. Іноді тестування і налагодження вважають синонімами [10.4,10.5]. У нашій країні в поняття налагодження зазвичай включають і тестування [10.6 -10.8], тому ми будемо слідувати традицією, що склалася. Втім спільний розгляд в даній лекції цих процесів робить вказане різночитання не таким істотним. Однак слід зазначити, що тестування використовується і як частина процесу атестації ПС (див. лекцію 14).
10.2. Принципи та види налагодження.
Успіх налагодження значною мірою зумовлює раціональна організація тестування. При налагодженні відшукуються і усуваються, в основному, ті помилки, наявність яких в ПС встановлюється при тестуванні. Як було вже зазначено, тестування не може довести правильність ПС [10.9], в кращому випадку воно може продемонструвати наявність в ньому помилки. Іншими словами, не можна гарантувати, що тестуванням ПС практично здійсненним набором тестів можна встановити наявність кожної наявної в ПС помилки. Тому виникає два завдання. Перша: підготувати такий набір тестів і застосувати до них ПС, щоб виявити в ньому якомога більша кількість помилок. Однак чим довше триває процес тестування (і налагодження в цілому), тим більшою стає вартість ПС. Звідси друге завдання: визначити момент закінчення налагодження ПС (або окремої його компоненти). Ознакою можливості закінчення налагодження є повнота охоплення пропущеними через ПС тестами (тобто тестами, до яких застосовано ПС) безлічі різних ситуацій, що виникають при виконанні програм ПС, і відносно рідкісне прояв помилок у ПС на останньому відрізку процесу тестування. Остання визначається відповідно до необхідної ступенем надійності ПС, зазначеної в специфікації його якості.
Для оптимізації набору тестів, тобто для підготовки такого набору тестів, який дозволяв би при заданому їх числі (або при заданому інтервалі часу, відведеному на тестування) виявляти більшу кількість помилок, необхідно, по-перше, заздалегідь планувати цей набір і, по-друге, використовувати раціональну стратегію планування ( проектування [10.1]) тестів. Проектування тестів можна починати відразу ж після завершення етапу зовнішнього опису ПС. Можливі різні підходи до вироблення стратегії проектування тестів, які можна умовно графічно розмістити (див. рис. 9.1) між наступними двома крайніми підходами [10.1]. Лівий крайній підхід полягає в тому, що тести проектуються тільки на підставі вивчення специфікацій ПС (зовнішнього опису, опису архітектури і специфікації модулів). Будова модулів при цьому ніяк не враховується, тобто вони розглядаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, так як при використанні в якості тестів тільки частини цих наборів деякі ділянки програм ПС можуть не працювати ні на якому тесті і, значить, що містяться в них помилки не будуть проявлятися. Однак тестування ПС повним безліччю наборів вхідних даних практично нездійсненне. Правий крайній підхід полягає в тому, що тести проектуються на підставі вивчення текстів програм з метою протестувати всі шляхи виконання кожної програм ПС. Якщо взяти до уваги наявність у програмах циклів зі змінним числом повторень, то різних шляхів виконання програм ПС може виявитися також надзвичайно багато, так що їх тестування також буде практично нездійсненне.
Оптимальна стратегія проектування тестів розташована всередині інтервалу між цими крайніми підходами, але ближче до лівого краю. Вона включає проектування значної частини тестів за специфікаціями, виходячи з принципів: на кожну використовувану функцію або можливість - хоча б один тест, на кожну область і на кожну кордон зміни якоїсь вхідний величини - хоча б один тест, на кожен особливий випадок або на кожну виняткову ситуацію, зазначені в специфікаціях, - хоча б один тест. Але вона вимагає також проектування деяких тестів і по текстах програм, виходячи з принципу (як мінімум): кожна команда кожної програми ПС повинна пропрацювати хоча б на одному тесті.
Оптимальну стратегію проектування тестів можна конкретизувати на підставі наступного принципу: для кожного програмного документа (включаючи тексти програм), що входить до складу ПС, повинні проектуватися свої тести з метою виявлення в ньому помилок. У всякому разі, цей принцип необхідно дотримуватися, відповідно з визначенням ПС і змістом поняття технології програмування як технології розробки надійних ПС (див. лекцію 1). У зв'язку з цим Майерс навіть визначає різні види тестування [10.1] в залежності від виду програмного документа, на підставі якого будуються тести. У нашій країні розрізняються [10.8] два основних види налагодження (включаючи тестування): автономну і комплексне налагодження. Автономна налагодження означає тестування тільки якоїсь частини програми, що входить в ПС, з пошуком і виправленням у ній фіксуються при тестуванні помилок. Вона фактично включає налагодження кожного модуля і налагодження сполучення модулів. Комплексне налагодження означає тестування ПС в цілому з пошуком і виправленням фіксуються при тестуванні помилок у всіх документах (включаючи тексти програм ПС), що відносяться до ПС в цілому. До таких документів відносяться визначення вимог до ПС, специфікація якості ПС, функціональна специфікація ПС, опис архітектури ПС та тексти програм ПС.
10.3. Заповіді налагодження.
У даному розділі даються загальні рекомендації з організації налагодження. Але спочатку слід зазначити деякий феномен [10.1], який підтверджує важливість попередження помилок на попередніх етапах розробки: у міру зростання числа виявлених та виправлених помилок у ПС зростає також відносна ймовірність існування в ньому незнайдених помилок. Це пояснюється тим, що при зростанні числа помилок, виявлених у ПС, уточнюється і наше уявлення про загальну кількість допущених у ньому помилок, а значить, в якійсь мірі, і про кількість незнайдених ще помилок. Цей феномен підтверджує важливість раннього виявлення помилок і необхідність ретельного контролю прийнятих рішень на кожному етапі розробки ПС.
Нижче наводяться рекомендації щодо організації налагодження в формі заповідей [10.1, 10.8].
Заповідь 1. Вважайте тестування ключовим завданням розробки ПС, доручайте його найкваліфікованішим і обдарованим програмістам; небажано тестувати свою власну програму.
Заповідь 2. Гарний той тест, для якого висока ймовірність знайти помилку, а не той, який демонструє правильну роботу програми.
Заповідь 3. Готуйте тести як для правильних, так і для неправильних даних.
Заповідь 4. Уникайте невідтворюваних тестів, документуйте їх пропуск через комп'ютер; детально вивчайте результати кожного тесту.
Заповідь 5. Кожен модуль підключайте до програми тільки один раз; ніколи не змінюйте програму, щоб полегшити її тестування.
Заповідь 6. Пропускайте наново всі тести, пов'язані з перевіркою роботи якої-небудь програми ПС або її взаємодії з іншими програмами, якщо в неї були внесені зміни (наприклад, в результаті усунення помилки).
10.4. Автономна налагодження модуля.
При автономній налагодженні кожен модуль насправді тестується в деякому програмному оточенні, крім випадку, коли налагоджували програма складається тільки з одного модуля. Це оточення складається [10.8] з інших модулів, частина яких є модулі налагоджують програми, які вже налагоджені, а частина - модулями, керуючими налагодженням (оцінний модуль, див. нижче). Таким чином, при автономної налагодженні тестується завжди деяка програма, побудована спеціально для тестування відладжується модуля. Ця програма лише частково збігається з налагоджують програму, крім випадку, коли налагоджували останній модулі налагоджують програми. У міру просування налагодження програми все більшу частину оточення чергового відладжується модуля будуть складати вже налагоджені модулі цієї програми, а при налагодженні останнього модуля цієї програми оточення відладжується модуля буде цілком складатися з усіх інших (вже налагоджених) модулі налагоджують програми (без будь-яких) налагоджувальних модулів, тобто в цьому випадку тестуватися буде сама відлагоджує програми. Такий процес нарощування відлагоджує програми налагодженими і налагоджували модулями називається інтеграцією програми [10.1].
Налагодження модулі, що входять в оточення відладжується модуля, залежать від порядку, в якому відладжуються модулі цієї програми, від того, який модуль відладжується і, можливо, від того, який тест буде пропускатися.
При висхідному тестуванні (див. лекцію 7) це оточення завжди буде містити тільки один оцінний модуль (крім випадку, коли налагоджували останній модулі налагоджують програми), який буде головним у програмі, що тестується і який називають провідним (або драйвером [10.1]). Ведучий оцінний модуль готує інформаційне середовище для тестування відладжується модуля (тобто формує її стан, необхідний для тестування цього модуля, зокрема, може здійснювати введення деяких тестових даних), здійснює звернення до відладжується модулю і після закінчення його роботи видає необхідні повідомлення. При налагодженні одного модуля для різних тестів можуть складатися різні провідні налагодження модулі.
При низхідному тестуванні (див. лекцію 7) оточення відладжується модуля в якості налагоджувальних модулів містить імітатори всіх модулів, до яких може звертатися відладжується модуль, а також імітатори тих модулів, до яких можуть звертатися налагоджені модулі налагоджують програми (включені в це оточення), але які ще не налагоджені. Деякі з цих імітаторів при налагодженні одного модуля можуть змінюватись для різних тестів.
Насправді в оточенні відладжується модуля в багатьох випадках можуть міститися налагодження модулі обох типів за нижче наступних міркувань. Як висхідне, так і спадний тестування має свої переваги і свої недоліки.
До достоїнств висхідного тестування відносяться
простота підготовки тестів і
можливість повної реалізації плану тестування модуля.
Це пов'язано з тим, що тестове стан інформаційного середовища готується безпосередньо перед зверненням до відладжується модулю (провідним оцінний модуль). Недоліками висхідного тестування є наступні його особливості:
тестові дані готуються, як правило, не в тій формі, яка розрахована на користувача (крім випадку, коли налагоджували останній, головний, модулі налагоджують програм);
великий обсяг отладочного програмування (при налагодженні одного модуля часто доводиться складати для різних тестів багато провідних налагоджувальних модулів);
необхідність спеціального тестування сполучення модулів.
До достоїнств низхідного тестування відносяться наступні його особливості:
більшість тестів готується у формі, розрахованої на користувача;
в багатьох випадках відносно невеликий обсяг отладочного програмування (імітатори модулів, як правило, дуже прості і кожен придатний для великого числа, нерідко - для всіх, тестів);
відпадає необхідність тестування сполучення модулів.
Недоліком низхідного тестування є те, що тестове стан інформаційного середовища перед зверненням до відладжується модулю готується побічно - воно є результатом застосування вже налагоджених модулів до тестових даними або даними, видаваним імітаторами. Це, по-перше, ускладнює підготовку тестів, вимагає високої кваліфікації виконавця-тестовіка, а по-друге, робить скрутним або навіть неможливим реалізацію повного плану тестування відладжується модуля. Зазначений недолік іноді змушує розробників застосовувати висхідне тестування навіть у разі низхідній розробки. Однак частіше застосовують деякі модифікації низхідного тестування, або деяку комбінацію низхідного і висхідного тестування.
Виходячи з того, що спадний тестування, в принципі, є кращим, зупинимося на прийомах, які дозволяють в якійсь мірі подолати зазначені труднощі. Перш за все необхідно організувати налагодження програми таким чином, щоб якомога раніше були налагоджені модулі, які здійснюють введення даних, - тоді тестові дані можна готувати у формі, розрахованої на користувача, що істотно спростить підготовку наступних тестів. Далеко не завжди цей введення здійснюється в головному модулі, тому доводиться в першу чергу налагоджувати ланцюжка модулів, провідні до модулів, що здійснюють зазначений введення (пор. з методом цілеспрямованої конструктивної реалізації в лекції 7). Поки модулі, які здійснюють введення даних, не налагоджені, тестові дані поставляються деякими імітаторами: вони або включаються в імітатор як його частина, або вводяться цим імітатором.
При низхідному тестуванні деякі стану інформаційного середовища, при яких потрібно тестувати відладжується модуль, можуть не виникати при виконанні відлагоджує програми ні за яких вхідних даних. У цих випадках можна було б взагалі не тестувати відладжується модуль, так як виявляються при цьому помилки не будуть виявлятися при виконанні відлагоджує програми ні за яких вхідних даних. Однак так робити не рекомендується, тому що при змінах відладжується програми (наприклад, при супроводі ПС) не використані для тестування відладжується модуля стану інформаційного середовища можуть вже виникати, що вимагає додаткового тестування цього модуля (а цього при раціональній організації налагодження можна було б не робити , якщо сам цей модуль не змінювався). Для здійснення тестування відладжується модуля в зазначених ситуаціях іноді використовують підходящі імітатори, щоб створити необхідний стан інформаційного середовища. Частіше ж користуються модифікованим варіантом низхідного тестування, при якому відладжується модулі перед їх інтеграцією попередньо тестуються окремо (в цьому випадку в оточенні відладжується модуля з'являється ведучий оцінний модуль, поряд з імітаторами модулів, до яких може звертатися відладжується модуль). Проте, видається більш доцільною інша модифікація низхідного тестування: після завершення низхідного тестування відладжується модуля для досяжних тестових станів інформаційного середовища слід його окремо протестувати для решти необхідних станів інформаційного середовища.
Часто застосовують також комбінацію висхідного і низхідного тестування, яку називають методом сандвіча [10.1]. Сутність цього методу полягає в одночасному здійсненні як висхідного, так і низхідного тестування, поки ці два процеси тестування не зустрінуться на якому-небудь модулі десь у середині структури відлагоджує програми. Цей метод дозволяє при розумному підході скористатися перевагами як висхідного, так і низхідного тестування і значною мірою нейтралізувати їх недоліки. Цей ефект є проявом більш загального принципу: найбільшого технологічного ефекту можна домогтися, поєднуючи спадні і висхідні методи розробки програм ПС. Саме для підтримки цього методу і призначений архітектурний підхід до розробки програм (див. лекцію 7): шар кваліфіковано розроблених і ретельно відтестовані модулів істотно полегшує реалізацію сімейства програм у відповідній предметній області та їх подальшу модернізацію.
Дуже важливим при автономної налагодженні є тестування сполучення модулів. Справа в тому, що специфікація кожного модуля програми, крім головного, використовується в цієї програми у двох ситуаціях: по-перше, при розробці тексту (іноді кажуть: тіла) цього модуля і, по-друге, при написанні звернення до цього модуля в інших модулях програми. І в тому, і в іншому випадку в результаті помилки може бути порушено необхідну відповідність заданої специфікації модуля. Такі помилки потрібно виявляти і усувати. Для цього і призначена тестування сполучення модулів. При низхідному тестуванні тестування сполучення здійснюється попутно кожним пропускається тестом, що вважають найсильнішим гідністю низхідного тестування. При висхідному тестуванні звернення до відладжується модулю проводиться не з модулів налагоджують програму, а з провідного отладочного модуля. У зв'язку з цим існує небезпека, що останній модуль може пристосуватися до деяких "оман" налагоджує модуля. Тому розпочинаючи (у процесі інтеграції програми) до налагодження нового модуля доводиться тестувати кожне звернення до раніше отлаженному модулю з метою виявлення неузгодженості цього звернення з тілом відповідного модуля (і не виключено, що винен в цьому раніше налагоджений модуль). Таким чином, доводиться частково повторювати в нових умовах тестування раніше налагодженого модуля, при цьому виникають ті ж труднощі, що і при низхідному тестуванні.
Автономне тестування модуля доцільно здійснювати в чотири послідовно виконуваних кроку [10.1].
Крок 1. На підставі специфікації відладжується модуля підготуйте тест для кожної можливості і кожної ситуації, для кожного кордону областей допустимих значень всіх вхідних даних, для кожної області зміни даних, для кожної області неприпустимих значень всіх вхідних даних і кожного неприпустимого умови.
Крок 2. Перевірте текст модуля, щоб переконатися, що кожен напрям будь-якого розгалуження буде пройдено хоча б на одному тесті. Додайте відсутні тести.
Крок 3. Переконайтеся за текстом модуля, що для кожного циклу існує тест, для якого тіло циклу не виконується, тест, для якого тіло циклу виконується один раз, і тест, для якого тіло циклу виконується максимальне число разів. Додайте відсутні тести.
Крок 4. Перевірте за текстом модуля його чутливість до окремих особливим значенням вхідних даних - всі такі значення повинні входити в тести. Додайте відсутні тести.
10.5. Комплексне налагодження програмного засобу.
Як вже було сказано вище, при комплексній налагодженні тестується ПС в цілому, причому тести готуються по кожному з документів ПС [10.8]. Тестування цих документів здійснюється, як правило, в порядку, зворотному їх розробці (виняток становить лише тестування документації щодо застосування, що розробляється на зовнішньому опису паралельно з розробкою текстів програм; це тестування краще проводити після завершення тестування зовнішнього опису). Тестування при комплексної налагодженні представляє собою застосування ПС до конкретних даних, які в принципі можуть виникнути у користувача (зокрема, всі тести готуються у формі, розрахованої на користувача), але, можливо, в моделюється (а не в реальному) середовищі. Наприклад, деякі недоступні при комплексної налагодженні пристрої введення і виведення можуть бути замінені їх програмними імітаторами.
Тестування архітектури ПС. Метою тестування є пошук невідповідності між описом архітектури і сукупністю програм ПС. До моменту початку тестування архітектури ПС повинна бути вже закінчена автономна налагодження кожної підсистеми. Помилки реалізації архітектури можуть бути пов'язані насамперед із взаємодією цих підсистем, зокрема, з реалізацією архітектурних функцій (якщо вони є). Тому хотілося б перевірити всі шляхи взаємодії між підсистемами ПС. Але так як їх може бути дуже багато, то бажано б протестувати хоча б всі ланцюжки виконання підсистем без повторного входження останніх. Якщо задана архітектура ПС як малої системи з виділених підсистем, то число таких ланцюжків буде цілком помірна.
Тестування зовнішніх функцій. Метою тестування є пошук розбіжностей між функціональною специфікацією і сукупністю програм ПС. Незважаючи на те, що всі ці програми автономно вже налагоджені, зазначені розбіжності можуть бути, наприклад, через невідповідність внутрішніх специфікацій програм та їх модулів (на підставі яких проводилося автономне тестування) зовнішньої функціональної специфікації ПС. Як правило, тестування зовнішніх функцій проводиться так само, як і тестування модулів на першому кроці, тобто як чорного ящика.
Тестування якості ПС. Метою тестування є пошук порушень вимог якості, сформульованих у специфікації якості ПС. Це найбільш важкий і найменш вивчений вид тестування. Ясно лише, що далеко не кожен примітив якості ПС може бути випробуваний тестуванням (про оцінку якості ПС див. наступну лекцію). Завершеність ПС перевіряється вже при тестуванні зовнішніх функцій. На даному етапі тестування цього примітиву якості може бути продовжено якщо потрібно отримати будь-яку імовірнісну оцінку ступеня надійності ПС. Однак, методика такого тестування ще вимагає своєї розробки. Точність, стійкість, захищеність, тимчасова ефективність, в якійсь мірі - ефективність по пам'яті, ефективність по пристроях, розширюваність і, частково, незалежність від пристроїв можуть тестуватися. Кожен з цих видів тестування має свою специфіку і заслуговує окремого розгляду. Ми тут обмежимося лише їх перерахуванням. Легкість застосування ПС (критерій якості, що включає кілька примітивів якості, див. лекцію 4) оцінюється при тестуванні документації щодо застосування ПС.
Тестування документації щодо застосування ПС. Метою тестування є пошук неузгодженості документації щодо застосування і сукупністю програм ПС, а також труднощів застосування ПС. Цей етап безпосередньо передує підключенню користувача до завершення розробки ПС (тестування вимог до ПС та атестації ПС), тому дуже важливо розробникам спочатку самим скористатися ПС так, як це буде робити користувач [10.1]. Всі тести на цьому етапі готуються виключно на підставі тільки документації щодо застосування ПС. Перш за все, повинні тестуватися можливості ПС як це робилося при тестуванні зовнішніх функцій, але тільки на підставі документації щодо застосування. Повинні бути протестовані всі неясні місця в документації, а також всі приклади, використані в документації. Далі тестуються найбільш важкі випадки застосування ПС з метою виявити порушення вимог відносності легкості застосування ПС.
Тестування визначення вимог до ПС. Метою тестування є з'ясування, якою мірою ПС не відповідає пред'явленим визначення вимог до нього. Особливість цього виду тестування полягає в тому, що його здійснює організація-покупець або організація-користувач ПС [10.1] як один із шляхів подолання бар'єру між розробником і користувачем (див. лекцію 3). Зазвичай це тестування проводиться за допомогою контрольних завдань - типових задах, для яких відомий результат рішення. У тих випадках, коли розробляється ПС має прийти на зміну іншому варіантом ПС, який вирішує хоча б частину завдань розробляється ПС, тестування проводиться шляхом вирішення спільних завдань з допомогою як старого, так і нового ПС з подальшим зіставленням отриманих результатів. Іноді як форми такого тестування використовують дослідну експлуатацію ПС - обмежене застосування нового ПС з аналізом використання результатів у практичній діяльності. По-суті, цей вид тестування багато в чому перегукується з випробуванням ПС при його атестації (див. лекцію 14), але виконується до атестації, а іноді і замість атестації.

Література до лекції 10.
10.1. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980. - С. 171-262.
10.2. Д. Ван Тассель. Стиль, розробка, ефективність, налагодження та випробування програм. - М.: Світ, 1985. - С. 179-295.
10.3. Дж. Хьюз, Дж. Мічтом. Структурний підхід до програмування. - М.: Світ, 1980. - С. 254-268.
10.4. Дж. Фокс. Програмне забезпечення та його розробка. - М.: Світ, 1985. - С. 227-241.
10.5. М. Зелковіц, А. Шоу, Дж. Геннон. Принципи розробки програмного забезпечення. - М.: Світ, 1982. - С. 105-116.
10.6. Ю.М. Безбородов. Індивідуальна налагодження програм. - М.: Наука, 1982. - С. 9-79.
10.7. В.В. Липа. Тестування програм. - М.: Радіо і зв'язок, 1986. - С. 15-47.
10.8. Е.А. Жоголєв. Введення в технологію програмування (конспект лекцій). - М.: "ДІАЛОГ-МГУ", 1994.
10.9. Е. Дейкстра. Нотатки з структурному програмуванню. / / У. Дав, Е. Дейкстра, К. Хоор. Структурне програмування. - М.: Світ, 1975. - С. 7-13.

Лекція 11. Забезпечення функціональності та НАДІЙНОСТІ ПРОГРАМНОГО ЗАСОБУ
11.1. Функціональність і надійність як обов'язкові критерії якості програмного засобу.
На попередніх лекція ми розглянули всі етапи розробки ПС, крім його атестації. При цьому ми не торкалися питань забезпечення якості ПС відповідно до його специфікацією якості (див. лекцію 4). Правда, займаючись реалізацією функціональної специфікації ПС ми тим самим обговорили основні питання забезпечення критерію функціональності. Оголосивши надійність ПС основним його атрибутом (див. лекцію 1), ми вибрали попередження помилок в якості основного підходу для забезпечення надійності ПС (див. лекцію 3) та обговорили її втілення на різних етапах розробки ПС. Таким чином проявлявся тезу про обов'язковість функціональності і надійності ПС як критеріїв його якості.
Тим не менш, у специфікації якості ПС можуть бути додаткові характеристики цих критеріїв, забезпечення яких вимагають спеціального обговорення. Цим питанням і присвячена ця лекція. Забезпечення інших критеріїв якості буде обговорюватися в наступній лекції.
Нижче обговорюються забезпечення примітивів якості ПС, що виражають критерії функціональності і надійності ПС.
11.2. Забезпечення завершеності програмного засобу.
Завершеність ПС є загальним примітивом якості ПС для вираження і функціональності і надійності ПС, причому для функціональності вона є єдиним примітивом (див. лекцію 4).
Функціональність ПС визначається його функціональної специфікацією. Завершеність ПС як примітив його якості є мірою того, наскільки ця специфікація реалізована в даному ПС. Забезпечення цього примітиву в повному обсязі означає реалізацію кожної з функцій, визначеної у функціональній специфікації, з усіма вказаними там деталями та особливостями. Усі розглянуті раніше технологічні процеси показують, як це може бути зроблено.
Однак у специфікації якості ПС можуть бути визначені кілька рівнів реалізації функціональності ПС: може бути визначена деяка спрощена (початкова або стартова) версія, яка повинна бути реалізована в першу чергу, можуть бути також визначені і кілька проміжних версій. У цьому випадку виникає додаткова технологічна задача: організація нарощування функціональності ПС. Тут важливо зазначити, що розробка спрощеної версії ПС не є розробка його прототипу. Прототип розробляється для того, щоб краще зрозуміти умови застосування майбутнього ПС [11.1], уточнити його зовнішнє опис. Він розрахований на вибраних користувачів і тому може сильно відрізнятися від запланованого ПС не тільки виконуваними функціями, але й особливостями користувальницького інтерфейсу. Спрощена ж версія необхідного ПС повинна бути розрахована на практично корисне застосування будь-якими користувачами, для яких він призначений. Тому головний принцип забезпечення функціональності такого ПС полягає в тому, щоб з самого початку розробляти ПС таким чином, начебто потрібно ПС в повному обсязі, до тих пір, поки розробники не будуть мати справу з тими частинами або деталями ПС, реалізацію яких можна відкласти в відповідно до специфікації його якості. Тим самим, і зовнішнє опис і опис архітектури ПС повинно бути розроблено в повному обсязі. Можна відкласти лише реалізацію тих програмних підсистем, визначених у архітектурі розроблюваного ПС, функціонування яких не потрібно в початковій версії цього ПС. Реалізацію ж самих програмних підсистем найкраще робити методом цілеспрямованої конструктивної реалізації, залишаючи в початковій версії ПС підходящі імітатори тих програмних модулів, функціонування яких в цій версії не потрібно. Допустима також спрощена реалізація деяких програмних модулів, що опускає реалізацію деяких деталей відповідних функцій. Однак такі модулі з технологічної точки зору краще розглядати як своєрідні їх імітатори (хоча й далеко просунуті).
У силу наявних у розробляється ПС помилок досягнута при забезпеченні його функціональності завершеність (у відповідності зі специфікацією його якості) насправді може бути не такою, як очікувалося. Можна лише говорити, що ця завершеність досягнута з деякою ймовірністю, яка визначається обсягом і якістю проведеного тестування. Для того щоб підвищити цю вірогідність, необхідно продовжити тестування і налагодження ПС. Однак, оцінювання такої ймовірності є досить специфічною завданням (з урахуванням того, що прояв наявної в ПС помилки є функцією вихідних даних), яка поки що чекає відповідних теоретичних досліджень.
11.3. Забезпечення точності програмного засобу.
Забезпечення цього примітиву пов'язано з діями над значеннями речових типів (точніше кажучи, із значеннями, що подаються з деякою похибкою). Забезпечити необхідну точність при обчисленні значення тієї чи іншої функції - означає отримати це значення з похибкою, що не виходить за рамки заданих меж. Видами похибки, методами їх оцінки та методами досягнення необхідної точності (так званими наближеними обчисленнями) займається обчислювальна математика [11.1, 11.2]. Тут ми лише звернемо увагу на деяку структуру похибки: похибка обчисленого значення (повна похибка) залежить
від похибки використовуваного методу обчислення (до якої ми включаємо і неточність використовуваної моделі),
від похибки подання використовуваних даних (від т.зв. непереборний похибки),
від похибки округлення (неточності виконання використовуються в методі операцій).
11.4. Забезпечення автономності програмного засобу.
Цей примітив якості забезпечується на етапі специфікації якості прийняттям рішення про використання в розробляється ПС якогось придатного базового програмного забезпечення або не використання у ньому жодного базового програмного забезпечення. При цьому доводиться враховувати як його надійність, так і необхідні для його використання ресурси. При підвищених вимогах до надійності розроблюваного ПС надійність базового програмного забезпечення, наявного в розпорядженні розроблювачів, може виявитися незадовільною, тому від його використання доводиться відмовлятися, а реалізацію його функцій у необхідному обсязі доводиться включати до складу ПС. Аналогічні рішення доводиться приймати при жорстких обмеженнях на використовувані ресурси (за критерієм ефективності ПС).
11.5. Забезпечення стійкості програмного засобу.
Цей примітив якості забезпечується за допомогою так званого захисного програмування. Взагалі кажучи, захисне програмування застосовується для підвищення надійності ПС при програмуванні модуля в більш широкому сенсі. Як стверджує Майерс [11.3], "захисне програмування засноване на важливій передумові: найгірше, що може зробити модуль, - це прийняти неправильні вхідні дані і потім повернути невірний, але правдоподібний результат". Для того, щоб цього уникнути, в текст модуля включають перевірки його вхідних і вихідних даних на їх коректність у відповідності зі специфікацією цього модуля, зокрема, повинні бути перевірені виконання обмежень на вхідні і вихідні дані і співвідношень між ними, зазначені в специфікації модуля. У разі негативного результату перевірки порушується відповідна виняткова ситуація. У зв'язку з цим в кінець цього модуля включаються фрагменти другого роду - обробники відповідних виняткових ситуацій, які крім видачі необхідної діагностичної інформації, можуть вжити заходів або по виключенню помилки в даних (наприклад, вимагати їх повторного введення), або щодо зменшення впливу помилки (наприклад , м'яку зупинку керованих ПС пристроїв, щоб уникнути їх поломки при аварійному припинення виконання програми).
Застосування захисного програмування модулів приводить зниження ефективності ПС як за часом, так і по пам'яті. Тому необхідно розумно регулювати ступінь застосування захисного програмування в залежності від вимог до надійності та ефективності ПС, сформульованим у специфікації якості розроблюваного ПС. Вхідні дані розроблюваного модуля можуть надходити як безпосередньо від користувача, так і від інших модулів. Найбільш вживаним випадком застосування захисного програмування є застосування його для першої групи даних, що і означає реалізацію стійкості ПС. Це потрібно робити завжди, коли технічні характеристики якості ПС є вимога про забезпечення стійкості ПС. Застосування захисного програмування для другої групи вхідних даних означає спробу виявити помилку в інших модулях під час виконання розроблюваного модуля, а для вихідних даних розроблюваного модуля - спробу виявити помилку в самому цьому модулі під час його виконання. По-суті, це означає часткове втілення підходу самовиявлення помилок для забезпечення надійності ПС, про що йшла мова в лекції 3. Цей випадок захисного програмування застосовується вкрай рідко - тільки в тому випадку, коли вимоги до надійності ПС надзвичайно високі.
11.6. Забезпечення захищеності програмних засобів.
Розрізняють такі види захисту ПС від спотворення інформації:
захист від збоїв апаратури;
захист від впливу "чужий" програми;
захист від відмов "своєї" програми;
захист від помилок оператора (користувача);
захист від несанкціонованого доступу;
захист від захисту.
Захист від збоїв апаратури в даний час є не дуже злободенною завданням (з урахуванням рівня досягнутої надійності комп'ютерів). Але все ж таки корисно знати її рішення. Це забезпечується організацією так званих "подвійних-потрійних прорахунків". Для цього весь процес обробки даних, визначається ПС, розбивається за часом на інтервали так званими "опорними точками". Довжина цього інтервалу не повинна перевищувати половини середнього часу безвідмовної роботи комп'ютера. Копія стану змінюваної в цьому процесі пам'яті кожної опорної точці записується у вторинну пам'ять з деякою контрольною сумою (числом, обчислюваним як деяка функція від цього стану) у тому випадку, коли буде вважатися, що обробка даних від попередньої опорної точки до даної (тобто . один "прорахунок") зроблена правильно (без збоїв комп'ютера). Для того, щоб це з'ясувати, проводиться два такі "прорахунку". Після першого "прорахунку" обчислюється і запам'ятовується зазначена контрольна сума, а потім відновлюється стан пам'яті для попередньої опорної точки і робиться другий "прорахунок". Після другого "прорахунку" обчислюється знову зазначена контрольна сума, яка потім порівнюється з контрольною сумою першого "прорахунку". Якщо ці дві контрольні суми збігаються, другий прорахунок вважається правильним, у противному випадку контрольна сума другого "прорахунку" також запам'ятовується і виробляється третій "прорахунок" (з попереднім відновленням стану пам'яті для попередньої опорної точки). Якщо контрольна сума третього "прорахунку" співпаде з контрольною сумою одного з перших двох "прорахунків", то третій прорахунок вважається правильним, в іншому випадку потрібно інженерна перевірка комп'ютера.
Захист від впливу "чужий" програми відноситься перш за все до операційних систем або до програм, що виконують частково їх функції. Розрізняють два різновиди цього захисту:
захист від відмов,
захист від зловмисного впливу "чужий" програми.
При появі мультипрограмному режиму роботи комп'ютера в його пам'яті може одночасно знаходиться в стадії виконання кілька програм, поперемінно одержують управління в результаті виникають переривань (так зване квазіпараллельное виконання програм). Одна з таких програм (зазвичай: операційна система) займається обробкою переривань та управлінням мультипрограмному режимом. У кожній з таких програм можуть виникати відмови (виявлятися помилки), які можуть вплинути на виконання функцій іншими програмами. Тому керуюча програма (операційна система) повинна забезпечити захист себе та інших програм від такого впливу. Для цього апаратура комп'ютера повинна реалізовувати наступні можливості:
захист пам'яті,
два режими функціонування комп'ютера: привілейований і робочий (призначений для користувача),
два види операцій: привілейовані і ординарні,
коректну реалізацію переривань та початкової включення комп'ютера,
тимчасове переривання.
Захист пам'яті означає можливість програмним шляхом задавати для кожної програми недоступні для неї ділянки пам'яті. У привілейованому режимі можуть виконуватися будь-які операції (як ординарні, так і привілейовані), а в робочому режимі - тільки ординарні. Спроба виконати привілейовану операцію, а також звернутися до захищеної пам'яті в робочому режимі викликає відповідне переривання. Причому до привілейованих операцій відносяться операції зміни захисту пам'яті і режиму функціонування, а також доступу до зовнішньої інформаційному середовищі. Початкове включення комп'ютера і будь-яке переривання має автоматично включати привілейований режим і скасування захисту пам'яті. У цьому випадку керуюча програма (операційна система) може повністю захистити себе від впливу інших програм, якщо всі точки передачі управління при початковому включенні і перериваннях будуть належати цій програмі, якщо вона ніякий інший програмі не дозволить працювати в привілейованому режимі (при передачі управління будь-який інший програмі буде включатися тільки робочий режим) і якщо вона повністю захистить свою пам'ять (містить, зокрема, всю її керуючу інформацію, включаючи так звані вектора переривань) з інших програм. Тоді ніхто не перешкодить їй виконувати будь-які реалізовані в ній функції захисту інших програм (у тому числі і доступу до зовнішнього інформаційного середовища). Для полегшення вирішення цього завдання частина такої програми поміщається в постійну пам'ять, тобто невіддільна від самого комп'ютера. Наявність тимчасового переривання дозволяє керуючої програмі захиститися від зациклення в інших програмах (без такого переривання вона могла б просто позбутися можливості управляти).
Захист від відмов "своєї" програми забезпечується надійністю цієї програми, на що орієнтована вся технологія програмування, що обговорюється в цьому курсі лекцій.
Захист від помилок користувача (крім помилок вхідних даних, див забезпечення стійкості ПС) забезпечується видачею попереджувальних повідомлень про спроби змінити стан зовнішнього інформаційного середовища з вимогою підтвердження цих дій, а також можливістю відновлення стану окремих компонент зовнішньої інформаційного середовища. Остання базується на здійсненні архівування змін стану зовнішнього інформаційного середовища.
Захист від несанкціонованого доступу забезпечується використанням секретних слів (паролів). У цьому випадку кожному користувачеві надаються певні інформаційні та процедурні ресурси (послуги), для використання яких потрібно пред'явлення ПС деякого пароля, раніше зареєстрованого в ПС цим користувачем. Іншими словами, користувач як би "вішає замок" на виділені йому ресурси, "ключ" від якого є тільки у цього користувача. Однак, в окремих випадках можуть бути зроблені наполегливі спроби зламати такий захист, якщо захищаються ресурси становлять для кого-то надзвичайну цінність. Для такого випадку доводиться робити додаткові заходи для захисту від злому захисту.
Захист від злому захисту пов'язана з використанням в ПС спеціальних програмістських прийомів, що ускладнюють подолання захисту від несанкціонованого доступу. Використання звичайних паролів виявляється недостатньою, коли мова йде про надзвичайно наполегливому прагненні (наприклад, злочинного характеру) домогтися доступу до цінної інформації. По-перше, тому, що інформацію про паролі, яку використовує ПС для захисту від несанкціонованого доступу, "зломщик" цього захисту відносно легко може дістати, якщо він має доступ до самого цього ПС. По-друге, використовуючи комп'ютер, можна здійснювати досить великий перебір можливих паролів з метою знайти відповідний для доступу до інформації, що цікавить. Захиститися від такого злому можна наступним чином. Секретне слово (пароль) або просто секретна ціле число X знає тільки власник, що захищається, а для перевірки прав доступу в комп'ютері зберігається інше число Y = F (X), однозначно обчислюване ПС при кожній спробі доступу до цієї інформації при пред'явленні секретного слова. При цьому функція F може бути добре відомої всім користувачам ПС, проте вона має таку властивість, що відновлення слова X по Y практично неможливо: при досить великій довжині слова X (наприклад, у кілька сотень знаків) для цього потрібно астрономічне час. Таке число Y будемо називати електронної (комп'ютерної) підписом власника секретного слова X (а значить, і інформації, що захищається).
Інший різновид такого захисту пов'язана із захистом повідомлень, що пересилаються по комп'ютерних мережах, навмисних (або зловмисних) спотворень. Таке повідомлення може перехоплюватися на "перевалочних" пунктах комп'ютерної мережі і підмінятися іншим повідомленням від автора перехопленого повідомлення. Така ситуація виникає перед усім при здійсненні банківських операцій з використанням комп'ютерної мережі. Шляхом підміни такого повідомлення, який є розпорядженням власника банківського рахунку про виконання деякої банківської операції гроші з його рахунку можуть бути переведені на рахунок "зломщика" захисту (своєрідний вид комп'ютерного пограбування банку). Захист від такого злому захисту можна здійснити наступним чином [11.4]. Поряд з функцією F, визначальною комп'ютерну підпис власника секретного слова X, яку знає адресат захищається повідомлення (якщо тільки її власник є клієнтом цього адресата), в ПС визначена інша функція Stamp, за якою відправник повідомлення повинен обчислити число S = Stamp (X, R ), використовуючи секретне слово X і текст переданого повідомлення R. Функція Stamp також вважається добре відомої всім користувачам ПС і має таку властивість, що по S практично неможливо ні відновити число X, ні підібрати інше повідомлення R з відповідної комп'ютерної підписом. Саме передане повідомлення (разом зі своїм захистом) повинна мати вигляд:
RYS,
причому Y (комп'ютерна підпис) дозволяє адресату встановити істинність клієнта, а S ніби скріплює захищається повідомлення Rс комп'ютерної підписом Y. У зв'язку з цим будемо називати число S електронної (комп'ютерної) печаткою. У ПС визначена ще одна функція Notary, по якій одержувач захищається повідомлення перевіряє істинність переданого повідомлення:
Notary (R, Y, S).
Ця дозволяє однозначно встановити, що повідомлення R належить власнику секретного слова X.
Захист від захисту необхідна в тому випадку, коли користувач забув (або втратив) свій пароль. Для такого випадку повинна бути передбачена можливість для особливого користувача (адміністратора ПС), що відповідає за функціонування системи захисту, виробляти тимчасове зняття захисту від несанкціонованого доступу для господаря забутого пароля з метою дати йому можливість зафіксувати новий пароль.

Література до лекції 11.
11.1. І.С. Березін, Н.П. Жидков. Методи обчислень, т.т. 1 і 2. - М.: Физматгиз, 1959.
11.2. Н.С. Бахвалов, Н.П. Жидков, Г. М. Кобельков. Чисельні методи. - М.: Наука, 1987.
11.3. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980. С. 127-154.
11.4. О.М. Лебедєв. Захист банківської інформації та сучасна криптографія / / Питання захисту інформації, 2 (29), 1995.

Лекція 12. ЗАБЕЗПЕЧЕННЯ ЯКОСТІ ПРОГРАМНОГО ЗАСОБУ
12.1. Загальна характеристика процесу забезпечення якості програмного засобу.
Як вже зазначалося у лекції 4, специфікація якості визначає основні орієнтири (цілі), які на всіх етапах розробки ПС так чи інакше впливають при прийнятті різних рішень на вибір відповідного варіанту. Проте, кожен примітив якості має свої особливості такого впливу, тим самим, забезпечення його наявності в ПС може зажадати своїх підходів і методів розробки ПС або окремих його частин. Крім того, відзначалася також суперечливість критеріїв якості ПС і висловлюють їх примітивів якості: хороше забезпечення одного якого-небудь примітиву якості ПС може істотно утруднити чи зробити неможливим забезпечення деяких інших з цих примітивів. Тому істотна частина процесу забезпечення якості ПС складається з пошуку прийнятних компромісів. Ці компроміси частково повинні бути визначені вже в специфікації якості ПС: модель якості ПС повинна конкретизувати необхідну ступінь присутності в ПС кожного його примітиву якості і визначати пріоритети досягнення цих ступенів.
Забезпечення якості здійснюється в кожному технологічному процесі: прийняті в ньому рішення в тій або іншій мірі впливають на якість ПС в цілому. Зокрема й тому, що значна частина примітивів якості пов'язана не стільки з властивостями програм, що входять в ПС, скільки з властивостями документації. У силу зазначеної суперечливості примітивів якості досить важливо дотримуватися обраних пріоритетів у їх забезпеченні. Але у всякому випадку корисно дотримуватися двох загальних принципів:
спочатку необхідно забезпечити необхідну функціональність і надійність ПС, а потім вже доводити інші критерії якості до прийнятного рівня їх присутності в ПС;
немає ніякої необхідності і може бути навіть шкідливо домагатися більш високого рівня присутності в ПС будь-якого примітиву якості, ніж той, який визначений в специфікації якості ПС.
Забезпечення функціональності і надійності ПС було розглянуто в попередній лекції. Нижче обговорюється забезпечення інших критеріїв якості ПС.
12.2 .. Забезпечення легкості застосування програмного засобу
П-документованості ПС визначає склад користувацької документації
У попередній лекції було вже розглянуто забезпечення двох з п'яти примітивів якості (стійкість і захищеність), які визначають легкість застосування ПС.
П-документування та інформативність визначають склад і якість користувача документації (див. наступну лекцію).
Комунікабельність забезпечується створенням відповідного користувальницького інтерфейсу і відповідної реалізації виняткових ситуацій. У чому тут проблема?
12.3. Забезпечення ефективності програмного засобу.
Ефективність ПС забезпечується прийняттям відповідних рішень на різних етапах його розробки, починаючи з розробки його архітектури. Особливо сильно на ефективність ПС (особливо по пам'яті) впливає вибір структури і представлення даних. Але і вибір алгоритмів, що використовуються в тих чи інших програмних модулях, а також особливості їх реалізації (включаючи вибір мови програмування) може істотно вплинути ефективність ПС. При цьому постійно доводиться вирішувати протиріччя між тимчасової ефективністю та ефективністю по пам'яті. Тому дуже важливо, щоб у специфікації якості було явно зазначено кількісне співвідношення між показниками цих примітивів якості або хоча б задані кількісні межі для одного з цих показників. І все ж таки різні програмні модулі по-різному впливають на ефективність ПС в цілому: і за внеском в загальні витрати ПС за часом і пам'яті, і за впливом на різні примітиви якості (одні модулі можуть сильно впливати на досягнення тимчасової ефективності і практично не впливати на ефективність по пам'яті, а інші можуть істотно впливати на загальний витрата пам'яті, не роблячи помітного впливу на час роботи ПС). Більше того, цей вплив (перш за все щодо тимчасової ефективності) заздалегідь (до закінчення реалізації ПС) далеко не завжди можна правильно оцінити.
З урахуванням сказаного, рекомендується дотримуватися наступних принципів для забезпечення ефективності ПС:
спочатку потрібно розробити надійне ПС, а вже потім домагатися необхідної його ефективності згідно зі специфікацією якості цього ПС [12.2, 12.3];
для підвищення ефективності ПС використовуйте насамперед оптимізуючий компілятор - це може забезпечити необхідну ефективність [12.3];
якщо досягнута ефективність ПС не задовольняє специфікації його якості, то знайдіть найкритичніші модулі з точки зору необхідної ефективності ПС (у разі временнoй ефективності для цього буде потрібно отримати розподіл по модулях часу роботи ПС шляхом відповідних вимірювань під час виконання ПС); ці модулі і спробуйте оптимізувати в першу чергу шляхом їхньої ручної переробки [12.3];
не займайтеся оптимізацією модуля, якщо цього не потрібно для досягнення необхідної ефективності ПС.
12.4. Забезпечення сопровождаемости.
З-документування, інформативність і зрозумілість визначають склад і якість документації по супроводу (див. наступну лекцію). Крім того, щодо текстів програм (модулів) можна зробити наступні рекомендації.
використовуйте в тексті модуля коментарі, які проясняють і пояснюють особливості прийнятих рішень; по-можливості, вмикайте коментарі (хоча б у стислій формі) на самій ранній стадії розробки тексту модуля [12.3];
використовуйте осмислені (мнемонічні) і стійко помітні імена (оптимальна довжина імені - 4-12 літер, цифри - в кінці), не використовуйте подібні імена та ключові слова [12.2, 12.3];
будьте обережні у використанні констант (унікальна константа повинна мати єдине входження в текст модуля: при її оголошенні або, в крайньому випадку, при ініціалізації змінної як константи [12.2]);
не бійтеся використовувати не обов'язкові дужки (дужки обходяться дешевше, ніж помилки [12.3];
розміщуйте не більше одного оператора в рядку; для прояснення структури модуля використовуйте додаткові пробіли (відступи) на початку кожного рядка [12.2, 12.3];
уникайте трюків, тобто таких прийомів програмування, коли створюються фрагменти модуля, основний ефект яких не очевидний або прихований (завуальований), наприклад, побічні ефекти функцій [12.2].
Розширюваність забезпечується створенням відповідного інсталятора.
Структурованість і модульність спрощують як розуміння текстів програм, так і їх модифікацію.
12.5. Забезпечення мобільності.

Література до лекції 12.
12.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.
12.2. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980. С. 127-154.
12.3. Д. Ван Тассель. Стиль, розробка, ефективність, налагодження та випробування програм. - М.: Світ, 1985. С. 8-44, 117-178.
12.4. Документація користувача програмного забезпечення / Стандарт ANSI / IEEE 1063-1987.

Лекція 13. ДОКУМЕНТУВАННЯ ПРОГРАМНИХ ​​ЗАСОБІВ
13.1. Документація, що створюється в процесі розробки програмних засобів.
При розробці ПС створюється великий обсяг різноманітної документації. Вона необхідна як засіб передачі інформації між розробниками ПС, як засіб управління розробкою ПС і як засіб передачі користувачам інформації, необхідної для застосування і супроводу ПС. На створення цієї документації доводиться велика частка вартості ПС.
Цю документацію можна розбити на дві групи [13.1]:
Документи управління розробкою ПС.
Документи, що входять до складу ПС.
Документи управління розробкою ПС (process documentation), протоколюють процеси розробки і супроводу ПС, забезпечуючи зв'язки всередині колективу розробників і між колективом розробників і менеджерами (managers) - особами, які керують розробкою. Ці документи можуть бути наступних типів [13.1]:
Плани, оцінки, розклади. Ці документи створюються менеджерами для прогнозування і управління процесами розробки та супроводу.
Звіти про використання ресурсів у процесі розробки. Створюються менеджерами.
Стандарти. Ці документи наказують розробникам, якими принципами, правилами, угодами вони повинні слідувати в процесі розробки ПС. Ці стандарти можуть бути як міжнародними або національними, так і спеціально створеними для організації, в якій ведеться розробка даного ПС.
Робочі документи. Це основні технічні документи, що забезпечують зв'язок між розробниками. Вони містять фіксацію ідей і проблем, що виникають у процесі розробки, опис використовуваних стратегій і підходів, а також робітники (тимчасові) версії документів, які повинні увійти в ПС.
Нотатки та листування. Ці документи фіксують різні деталі взаємодії між менеджерами та розробниками.
Документи, що входять до складу ПС (product documentation), описують програми ПС як з точки зору їх застосування користувачами, так і з точки зору їх розробників і супровідників (відповідно до призначення ПС). Тут слід зазначити, що ці документи будуть використовуватися не тільки на стадії експлуатації ПС (у її фазах застосування та супроводу), але і на стадії розробки для управління процесом розробки (разом з робочими документами) - у всякому разі вони повинні бути перевірені (протестовані) на відповідність програмам ПС. Ці документи утворюють два комплекти з різним призначенням:
Користувацька документація ПС (П-документація).
Документація з супроводу ПС (С-документація).
13.2. Користувацька документація програмних засобів.
Користувацька документація ПС (user documentation) пояснює користувачам, як вони повинні діяти, щоб застосувати це ПС. Вона необхідна, якщо ПС передбачає будь-яке взаємодію з користувачами. До такої документації належать документи, якими керується користувач при інсталяції ПС (при установці ПС з відповідною настроюванням на середу застосування ПС), при застосуванні ПС для вирішення своїх завдань і при управлінні ПС (наприклад, коли дане ПС взаємодіє з іншими системами). Ці документи частково торкаються питань супроводу ПС, але не стосуються питань, пов'язаних з модифікацією програм.
У зв'язку з цим слід розрізняти дві категорії користувачів ПС: ординарних користувачів ПС та адміністраторів ПС. Ординарний користувач ПС (end-user) використовує ПС для вирішення своїх завдань (в своїй предметній області). Це може бути інженер, який проектує технічний пристрій, або касир, який продає залізничні квитки за допомогою ПС. Він може і не знати багатьох деталей роботи комп'ютера або принципів програмування. Адміністратор ПС (system administrator) управляє використанням ПС ординарними користувачами та здійснює супровід ПС, не пов'язане з модифікацією програм. Наприклад, він може регулювати права доступу до ПС між ординарними користувачами, підтримувати зв'язок з постачальниками ПС або виконувати певні дії, щоб підтримувати ПС в робочому стані, якщо воно включено як частину в іншу систему.
Склад користувача документації залежить від аудиторій користувачів, на які орієнтовано дане ПС, і від режиму використання документів. Під аудиторією тут розуміється контингент користувачів ПС, у якого є потреба у певній користувача документації ПС [13.2]. Вдалий користувальницький документ суттєво залежить від точного визначення аудиторії, для якої він призначений. Користувацька документація повинна містити інформацію, необхідну для кожної аудиторії. Під режимом використання документа розуміється спосіб, що визначає, яким чином використовується цей документ. Звичайно користувачеві досить великих програмних систем потрібні документи для вивчення ПС (використання у вигляді інструкції), або для уточнення деякої інформації (використання у вигляді довідника).
Відповідно до роботами [13.1, 13.2] можна вважати типовим наступний склад користувацької документації для досить великих ПС:
Загальне функціональне опис ПС. Дає коротку характеристику функціональних можливостей ПС. Призначено для користувачів, які повинні вирішити, наскільки необхідно їм дане ПС.
Керівництво по інсталяції ПС. Призначено для системних адміністраторів. Він повинен детально наказувати, як встановлювати системи в конкретному середовищі. Він повинен містити опис машинно-зчитуваного носія, на якому поставляється ПС, файли, що представляють ПС, і вимоги до мінімальної конфігурації апаратури.
Інструкція щодо застосування ПС. Призначена для ординарних користувачів. Містить необхідну інформацію щодо застосування ПС, організовану у формі зручній для її вивчення.
Довідник по застосуванню ПС. Призначений для ординарних користувачів. Містить необхідну інформацію щодо застосування ПС, організовану у формі зручній для виборчого пошуку окремих деталей.
Керівництво з управління ПС. Призначено для системних адміністраторів. Воно має описувати повідомлення, що генеруються, коли ПС взаємодіє з іншими системами, і як реагувати на ці повідомлення. Крім того, якщо ПС використовує системну апаратуру, цей документ може пояснювати, як супроводжувати цю апаратуру.
Як вже говорилося раніше (див. лекцію 4), розробка документації користувача починається відразу після створення зовнішнього опису. Якість цієї документації може істотно визначати успіх ПС. Вона повинна бути досить проста і зручна для користувача (у противному випадку це ПС, взагалі, не варто було створювати). Тому, хоча чорнові варіанти (начерки) призначених для користувача документів створюються основними розробниками ПС, до створення їх остаточних варіантів часто залучаються професійні технічні письменники. Крім того, для забезпечення якості для користувача документації розроблено ряд стандартів (див. наприклад, [13.2]), в яких пропонується порядок розробки цієї документації, формулюються вимоги до кожного виду для користувача документів і визначаються їх структура та зміст.
13.3. Документація з супроводу програмних засобів.
Документація з супроводу ПС (system documentation) описує ПС з точки зору її розробки. Ця документація необхідна, якщо ПС передбачає вивчення того, як воно влаштоване (сконструйована), і модернізацію його програм. Як вже зазначалося, супровід - це триваюча розробка. Тому в разі необхідності модернізації ПС до цієї роботи залучається спеціальна команда розробників-супровідників. Цій команді доведеться мати справу з такою ж документацією, яка визначала діяльність команди первісних (основних) розробників ПС, - з тією лише різницею, що ця документація для команди розробників-супровідників буде, як правило, чужий (вона створювалася іншою командою). Команда розробників-супровідників повинна буде вивчати цю документацію, щоб зрозуміти будову і процес розробки модернізованого ПС, та внести в цю документацію необхідні зміни, повторюючи в значній мірі технологічні процеси, за допомогою яких створювалося початкове ПС.
Документація з супроводу ПС можна розбити на дві групи:
(1) документація, яка визначає будову програм і структур даних ПС і технологію їх розробки;
(2) документацію, що допомагає вносити зміни в ПС.
Документація першої групи містить підсумкові документи кожного технологічного етапу розробки ПС. Вона включає наступні документи:
Зовнішнє опис ПС (Requirements document).
Опис архітектури ПС (description of the system architecture), включаючи зовнішню специфікацію кожної її програми.
Для кожної програми ПС - опис її модульної структури, включаючи зовнішню специфікацію кожного включеного до неї модуля.
Для кожного модуля - його специфікація і опис його будови (design description).
Тексти модулів вибраною мовою програмування (program source code listings).
Документи встановлення достовірності ПС (validation documents), що описують, як встановлювалася достовірність кожної програми ПС і як інформація про встановлення достовірності пов'язувалася з вимогами до ПС.
Документи встановлення достовірності ПС включають насамперед документацію з тестування (схема тестування і опис комплекту тестів), але можуть включати і результати інших видів перевірки ПС, наприклад, докази властивостей програм.
Документація другої групи містить
Керівництво по супроводу ПС (system maintenance guide), яке описує відомі проблеми разом з ПС, описує, які частини системи є апаратно-і програмно-залежними, і як розвиток ПС прийнято до уваги в його будові (конструкції).
Загальна проблема супроводу ПС - забезпечити, щоб всі його вистави йшли в ногу (залишалися узгодженими), коли ПС змінюється. Щоб цьому зарадити, зв'язки і залежності між документами та їх частинами повинні бути зафіксовані в базі даних управління конфігурацією.

Література до лекції 13.
13.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI / IEEE Std 1063-1988, IEEE Standard for Software User Documentation.
13.3. ANSI / IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.
13.4. ANSI / IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.
13.5. ANSI / IEEE Std 1008-1987, IEEE Standard for Software Unit Testing.
13.6. ANSI / IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans.
13.7. ANSI / IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
13.8. ANSI / IEEE Std 829-1983, IEEE Standard for Software Test Documentation.

Лекція 14. АТЕСТАЦІЯ ПРОГРАМНОГО ЗАСОБУ
Призначення атестації програмного засобу. Випробування та оцінка якості програмного засобу. Види випробувань, і методи оцінки якості програмного засобу.
14.1. Призначення атестації програмного засобу.
Атестація ПС - це авторитетне підтвердження якості ПС [14.1]. Зазвичай для атестації ПС створюється представницька (атестаційна) комісія з експертів, представників замовника та представників розробника. Ця комісія проводить випробування ПС з метою отримання необхідної інформації для оцінки його якості. Під випробуванням ПС ми будемо розуміти процес проведення комплексу заходів, які досліджують придатність ПС для успішної його експлуатації (застосування і супроводу) відповідно до вимог замовника [14.2]. Цей комплекс включає перевірку повноти і точності програмної документації, вивчення та обговорення інших її властивостей, а також необхідне тестування програм, що входять до складу ПС, і, зокрема, на відповідність цих програм наявній документації.
На основі інформації, отриманої під час випробувань ПС, перш за все повинно бути встановлено, що ПС виконує декларовані функції, а також має бути встановлено, якою мірою ПС має декларованими примітивами і критеріями якості. Таким чином, оцінка якості ПС є основним змістом процесу атестації. Вироблена оцінка якості ПС фіксується у відповідному рішенні атестаційної комісії.

14.2. Види випробувань програмного засобу.
Відомі такі види випробувань ПС [14.2,14.3], що проводяться з метою атестації ПС:
випробування компонент ПС;
системні випробування;
приймально-здавальні випробування;
польові випробування;
промислові випробування.
Випробування компонент ПС - це перевірка (тестування) працездатності окремих підсистем ПС. Проводяться тільки у виняткових випадках за спеціальним рішенням атестаційної комісії.
Системні випробування ПС - це перевірка (тестування) працездатності ПС в цілому. Може включати ті ж види тестування, що і при комплексній налагодженні ПС (див. лекцію 10). Проводиться за рішенням атестаційної комісії, якщо виникають сумніви в якості проведення налагодження розробниками ПС.
Приймально-здавальні випробування є основним видом випробувань при атестації ПС. Саме з цих випробувань починає роботу атестаційна комісія. Ці випробування починаються з вивчення наданої документації, в тому числі, та документації з тестування і налагодження ПС. Якщо в документації відсутні достатньо повні результати тестування ПС, атестаційна комісія може прийняти рішення про проведення системних випробувань ПС або про припинення процесу атестації з рекомендацією розробнику провести додаткове (більш повне) тестування ПС. Крім того, під час цих випробувань можуть вибірково пропускатися тести розробників, а також контрольні завдання користувачів (див. лекцію 10) і додаткові тести, підготовлені комісією для оцінки якості аттестуемого ПС.
Польові випробування ПС - це демонстрація ПС разом з технічною системою, якою управляє ця ПС, вузькому колу замовників в реальних умовах і здійснюється ретельне спостереження за поведінкою ПС [12.3]. Замовникам повинна бути надана можливість завдання власних контрольних прикладів, зокрема, з виходів у критичні режими роботи технічної системи, а також з викликом в ній аварійних ситуацій. Це додаткові випробування, що проводяться за рішенням атестаційної комісії тільки для деяких ПС, які управляють певними технічними системами.
Промислові випробування ПС - це процес передачі ПС в постійну експлуатацію користувачам. Являє собою період дослідної експлуатації ПС (див. лекцію 10) користувачами зі збором інформації про особливості поведінки ПС та її експлуатаційні характеристики. Це завершальні випробування ПС, які проводяться за рішенням атестаційної комісії, якщо на попередніх випробуваннях отримана недостатньо повна або надійна інформація для оцінки якості аттестуемого ПС.
14.3. Методи оцінки якості програмного засобу.
Оцінка якості ПС по кожному з критеріїв зводиться до оцінки кожного з примітивів, пов'язаних з цим критерієм якості ПС, відповідно до їх конкретизацією, виробленої в специфікації якості цього ПС [12.4]. Методи оцінки примітивів якості ПС можна розділити на чотири групи:
безпосереднє вимірювання показників примітиву якості;
обробка програм і документації ПС спеціальними програмними інструментами (процесорами);
тестування програм ПС;
експертна оцінка на підставі вивчення програм та документації ПС.
Безпосереднє вимірювання показників примітиву якості проводиться шляхом підрахунку числа входжень у той чи інший програмний документ характерних одиниць, об'єктів, конструкцій тощо, а також шляхом вимірювання часу роботи різних пристроїв та обсягу використаної пам'яті ЕОМ при виконанні контрольних прикладів. Наприклад, деяким показником ефективності по пам'яті може бути число рядків програми на мові програмування, а деяким показником ефективності за часом може бути час відповіді на запит. Використання будь-яких показників для примітивів якості може визначатися в специфікації якості ПС. Метод безпосереднього вимірювання показників примітиву якості може поєднуватися з використанням тестування програм.
Для встановлення наявності у ПС деяких примітивів якості можуть використовуватися певні програмні інструментальні засоби. Такі програмні інструменти обробляють тексти програм або програмної документації з метою контролю будь-яких примітивів якості або отримання деяких показників цих примітивів якості. Для оцінки структурованості програм ПС, якщо вони програмувались на відповідному структурному діалекті базової мови програмування, достатньо було б їх пропустити через конвертер структурованих програм, здійснює синтаксичний і деякий семантичний контроль цього діалекту і переводить тексти цих програм на вхідна мова базового транслятора. Однак таким шляхом в даний час вдається контролювати лише невелике число примітивів якості, та й то в рідкісних випадках. У ряді випадків замість програмних інструментів, контролюючих якість ПС, корисніше застосовувати інструменти, які здійснюють перетворення представлення програм або програмної документації. Таким, наприклад, є форматер програм, що призводить тексти програм до зрозумілому людині увазі, - обробка текстів програм ПС таким інструментом може автоматично забезпечити наявність відповідного примітиву якості у ПС.
Для оцінки деяких примітивів якості ПС використовується тестування. До таких примітивам відноситься перш за все завершеність ПС, а також його точність, стійкість, захищеність та інші примітиви якості. У ряді випадків для оцінки окремих примітивів якості ПС тестування застосовується в поєднанні з іншими методами. Так для оцінки якості документації щодо застосування ПС (П-документованості) тестування застосовується в поєднанні з експертною оцінкою цієї документації. Якщо при комплексній налагодженні ПС було проведено досить повне тестування, то ці ж тести можуть бути використані і при атестації ПС. У цьому випадку атестаційна комісія може скористатися протоколами тестування, проведеного за комплексного налагодження. Однак і в цьому випадку необхідно виконати будь-які нові тести або хоча б повторно деякі старі. Якщо ж тестування при комплексній налагодженні буде визнано недостатньо повним, то необхідно провести більш повне тестування. У цьому випадку може бути прийнято рішення про проведення випробувань компонент або системних випробувань ПС, а також про повернення ПС розробникам на доопрацювання. Дуже важливо, щоб для оцінки ПС за критерієм легкості застосування було проведено (під час налагодження та атестації ПС) повне тестування за тестами, підготовленим на підставі документації із застосування, а за критерієм сопровождаемости - за тестами, підготовленим по кожному з документів, які пропонують для супроводу ПС.
Для оцінки більшості примітивів якості ПС в даний час можна застосовувати тільки метод експертних оцінок. Цей метод полягає в наступному: призначається група експертів, кожен з цих експертів в результаті вивчення наданої документації складає свою думку про володіння ПС необхідним примітивом якості, а потім голосуванням членів цієї групи встановлюється оцінка необхідного примітиву якості ПС. Ця оцінка може здійснюватися як у двухбалльной системі ("володіє" - "не має"), так і враховувати ступінь володіння ПС цим примітивом якості (наприклад, здійснюватися за п'ятибальною системою). При цьому група експертів повинна керуватися конкретизацією цього примітиву і вказівкою про спосіб його оцінки, сформульованими в специфікації якості аттестуемого ПС.
Література до лекції 14.
14.1. Г. Майерс. Надійність програмного обеспечнии. - М.: Світ, 1980. - С. 174-175.
14.2. В. В. Липа. Тестування програм. - М.: Радіо і зв'язок, 1986. - С. 231-245.
14.3. Д. Ван Тассель. Стиль, розробка, ефективність, налагодження та випробування програм. - М.: Світ, 1985. - С. 281-283.
14.4. Б. Шнейдерман. Психологія програмування. - М.: Радіо і зв'язок, 1984. - С. 99-127.

Лекція 15.О'ЕКТНИЙ ПІДХІД ДО РОЗРОБКИ ПРОГРАМНИХ ​​ЗАСОБІВ
15.1. Об'єкти і відносини в програмуванні. Сутність об'єктного підходу до розробки програмних засобів.
Навколишній світ складається з об'єктів і відносин між ними [13.1]. Об'єкт втілює деяку сутність і має деякий стан, який може змінюватися з часом як наслідок впливу інших об'єктів, які перебувають з даними в будь-якому відношенні. Він може мати внутрішню структуру: складатися з інших об'єктів, що також знаходяться між собою в деяких відносинах. Виходячи з цього можна побудувати ієрархічну будову світу з об'єктів. Однак, при кожному конкретному розгляді оточуючого нас світу деякі об'єкти вважаються неподільними ("точковими"), причому в залежності від цілей розгляду такими (неподільними) можуть прийматися об'єкти різного рівня ієрархії. Ставлення пов'язує деякі об'єкти: можна вважати, що об'єднання цих об'єктів має деяким властивістю. Якщо відношення пов'язує n об'єктів, то таке відношення називається n-місним (n-арним). На кожному місці об'єднання об'єктів, які можуть бути зв'язані будь-яким конкретним ставленням, можуть перебувати різні об'єкти, але цілком певні (в цьому випадку говорять: об'єкти певного класу). Одномісне відношення називається властивістю об'єкта (відповідного класу). Стан об'єкта може бути вивчене за значенням властивостей цього об'єкта або неявно за значенням властивостей об'єднань об'єктів, що пов'язуються з цією тим чи іншим ставленням.
У процесі пізнання або зміни оточуючого нас світу ми завжди беремо до розгляду ту чи іншу спрощену модель світу (модельний світ), в яку включаємо деякі з об'єктів і деякі з відносин оточуючого нас світу і, як правило, одного рівня ієрархії. Кожен об'єкт, що має внутрішню структуру, може представляти свій модельний світ, що включає об'єкти цієї структури і відносини, які їх пов'язують. Таким чином, оточуючий нас світ, можна розглядати (в деякому наближенні) як ієрархічну структуру модельних світів.
В даний час у процесі пізнання або зміни оточуючого нас світу широко використовується комп'ютерна техніка для обробки різного роду інформації. У зв'язку з цим застосовується комп'ютерне (інформаційне) подання об'єктів і відносин. Кожен об'єкт інформаційно може бути представлений певною структурою даних, що відображає його стан. Властивості цього об'єкта можуть задаватися безпосередньо у вигляді окремих компонент цієї структури, або спеціальними функціями над цією структурою даних. N-місцеві відносини для N> 1 можна представити або в активній формі, або у пасивній формі. В активній формі N-місцеве ставлення представляється деяким програмним фрагментом, реалізують або N-місцеву функцію (визначальну значення властивості відповідного об'єднання об'єктів), або процедуру, яка здійснює за станом уявлень об'єктів, що пов'язуються акредитуючою ставленням, зміна станів деяких з них. В пасивній формі таке ставлення може бути представлено деякою структурою даних (до якої можуть входити і представлення об'єктів, що пов'язуються цим ставленням), интерпретируемую на підставі прийнятих угод за загальними процедурами, незалежних від конкретних відносин (наприклад, реляційна база даних). У будь-якому випадку подання відносини визначає деякі дії по обробці даних.
При дослідженні модельного світу користувач може по-різному отримувати (або захотіти отримувати) інформацію від комп'ютера. При одному підході його можуть цікавити отримання інформації про окремі властивості цікавлять його об'єктів або результати будь-якої взаємодії між деякими об'єктами. Для цього він замовляє розробку того чи іншого ПС, що виконує цікавлять його функції, або деяку інформаційну систему, здатної видавати інформацію про цікаві його відносинах, використовуючи при цьому відповідну базу даних. У початковий період розвитку комп'ютерної техніки (при не досить високого потужності комп'ютерів) такий підхід до використання комп'ютерів був цілком природним. Саме він і провокував функціональний (реляційний) підхід до розробки ПС, який був докладно розглянуто в попередніх лекціях. Сутність цього підходу полягає в систематичному використанні декомпозиції функцій (відносин) для побудови структури ПС і текстів програм, що входять до нього. При цьому самі об'єкти, до яких застосовувалися замовляються й реалізовані функції, представлялися фрагментарно (в тому обсязі, який необхідний для виконання цих функцій) і у формі, зручній для реалізації цих функцій. Тим самим не забезпечувалося цілісного і адекватного комп'ютерного представлення модельного світу, що цікавить користувача: відображення його на використовувані ПС могло виявитися для користувача досить трудомістким завданням, спроби незначного розширення обсягу та характеру інформації про цікавить користувача модельному світі. одержуваної від таких ПС, могло призвести до серйозної їх модернізації. Такий підхід до розробки ПС підтримується більшістю використовуваних мов програмування, починаючи від мов асемблерів і процедурних мов (ФОРТРАН, Паскаль) до функціональних мов (ЛИСП) і мов логічного програмування (ПРОЛОГ).
При іншому підході до дослідження модельного світу за допомогою комп'ютера користувача може цікавити спостереження за зміною станів об'єктів в результаті їх взаємодій. Це вимагає досить цілісного уявлення в комп'ютері цікавить користувача об'єкта, а програмні компоненти, що реалізують відносини, в яких бере участь цей об'єкт, явно зв'язуються з ним. Для реалізації такого підходу доводилося будувати програмні засоби, що моделюють процеси взаємодії об'єктів (модельного світу). За допомогою традиційних засобів розробки це виявилося досить трудомістким завданням. Правда, з'явилися мови програмування, спеціально орієнтовані на таке моделювання, але це лише частково спростило завдання розробки необхідних ПС. Найбільш повно відповідає рішенню цього завдання об'єктний підхід до розробки ПС. Сутність його полягає в систематичному використанні декомпозиції об'єктів при побудові структури ПС і текстів програм, що входять до нього. При цьому функції (відносини), що виконуються таким ПС, виражалися через відношення об'єктів різних рівнів, тобто їх декомпозиція істотно залежала від декомпозиції об'єктів.
Говорячи про об'єктному підході слід також чітко розуміти про якого роду об'єктах йде мова: об'єктах модельного світу користувача, про їх інформаційному поданні, про об'єкти програми, за допомогою яких будується ПС. Крім того, слід розрізняти власне об'єкти (об'єкти "пасивні") і суб'єкти (об'єкти "активні").
15.2. Об'єкти і суб'єкти в програмуванні.
15.3. Об'єктний і суб'єктний підходи до розробки програмних засобів.
Декарт зазначав, що люди зазвичай мають об'єктно-орієнтована погляд на світ ([29] у [13.3]).
Вважають, що об'єктно-орієнтованого проектування засновано на принципах [13.3, стор 31]:
виділення абстракцій,
обмеження доступу,
модульність,
ієрархія,
типізація,
паралельність,
стійкість.
Але все це може застосовуватися і при функціональному підході.
Слід розрізняти достоїнства і недоліки загального об'єктного підходу і його окремого випадку - суб'єктно-орієнтованого підходу.
Переваги загального об'єктивного підходу:
Природне відображення реального світу на будову ПС (природне сприйняття людиною можливостей ПС, не потрібно "вигадувати" будова ПС, а використовувати природні аналогії).
Використання досить змістовних структурних одиниць ПС (об'єкт як цілісність ненадлишкових асоціацій, інфомаційно-міцні модулі).
Зниження трудомісткості розробки ПС за рахунок використання нового рівня абстракцій (використання ієрархії "непрограмну" абстракцій при розробці ПС: класифікація об'єктів реального світу, метод аналогій в природі) як новий рівень наслідування.
15.4. Об'єктний підхід до розробки зовнішнього опису та архітектури програмного засобу.
Об'єктно-орієнтоване проектування - метод, що використовує об'єктну декомпозицію; об'єктно-орієнтований підхід має свою систему умовних позначень і пропонує багатий набір логічних і фізичних моделей для проектування систем високого ступеня складності. [13.3, стор 30].
..... На об'єктний підхід надав об'єктно-орієнтований аналіз (ООА). ООА спрямований на створення моделей, ближчих до реальності, з використанням об'єктно-орієнтованого підходу; це методологія, при якій вимоги формуються на основі понять класів та об'єктів, що становлять словник предметної області. [2, стор.42].
Особливості об'єктно-орієнтованого програмування.
Об'єкти, класи, поведінку об'єкта, властивості, події.

Література до лекції 15.
15.1. К. футі, Н. Судзукі. Мови програмування і схемотехніка НВІС. - М.: Мир, 1988. С. 85-98.
15.2. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P. ? -?
15.3. Г. Буч. Об'єктно-орієнтоване проектування з прикладами застосування: пров. з англ. - М.: Конкорд, 1992.
15.4. В. Ш. Кауфман. Мови програмування. Концепції та принципи. М.: Радіо і зв'язок, 1993.
80-ті роки характеризуються широким впровадженням персональних комп'ютерів у всі сфери людської діяльності і тим самим створенням великого і різноманітного контингенту користувачів ПС. Це призвело до бурхливого розвитку користувацьких інтерфейсів і створення чіткої концепції якості ПС [REF _Ref53419550 \ n \ h \ * MERGEFORMAT 5 , REF _Ref53419942 \ n \ h \ * MERGEFORMAT 15 , REF _Ref53419944 \ n \ h \ * MERGEFORMAT 16 , REF _Ref53419945 \ n \ h \ * MERGEFORMAT 17 , REF _Ref53419946 \ n \ h \ * MERGEFORMAT 18 ]. З'являються мови програмування (наприклад, Ада), що враховують вимоги технології програмування [REF _Ref53419973 \ n \ h \ * MERGEFORMAT 19 ]. Розвиваються методи та мови специфікації ПС [1.20-1.21]. Виходить на передові позиції об'єктний підхід до розробки ПС [REF _Ref53419684 \ n \ h \ * MERGEFORMAT 9 ]. Створюються різні інструментальні середовища розробки і супроводу ПС [REF _Ref53419509 \ n \ h \ * MERGEFORMAT 3 ]. Розвивається концепція комп'ютерних мереж.
90-ті роки знаменні широким охопленням всього людського суспільства міжнародної комп'ютерною мережею, персональні комп'ютери стали підключатися до неї як термінали. Це поставило низку проблем регулювання доступу до комп'ютерно-мережевої інформації (як технологічного, так і юридичного та етичного характеру). Гостро постала проблема захисту комп'ютерної інформації та переданих по мережі повідомлень. Стали бурхливо розвиватися комп'ютерна технологія (CASE-технологія) розробки ПС і пов'язані з нею формальні методи специфікації програм. Почався вирішальний етап повної інформатизації та комп'ютеризації суспільства.

ЛІТЕРАТУРА
1. І.Г. Гоулд, Дж.С. Тутілл. Термінологічна робота IFIP (Міжнародна федерація з обробки інформації) і ICC (Міжнародний обчислювальний центр) / / Журн. вичислив. матем. і матем. фіз., 1965, № 2. - С. 377-386.
2. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980.
3. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992.
4. Е. Дейкстра. Нотатки з структурному програмуванню / / У. Дал, Е. Дейкстра, К. Хоор. Структурне програмування. - М.: Світ, 1975. - С. 7-97.
5. Criteria for Evalution of Software. - ISO TC97/SC7 # 367 (Supersedes Document # 327).
6. С.І. Ожегов. Словник російської мови. - М.: Радянська енциклопедія, 1975.
7. Ф.Я. Дзержинський, І.М. Калініченко. Дисципліна програмування Д: концепція і досвід реалізації методичних засобів програмної інженерії. - М.: ЦНДІ інформації та техніко-економічних досліджень з атомної науки і техніки, 1988. - С. 9-16.
8. В. Турський. Методологія програмування. - М.: Світ, 1981.
9. Г. Буч. Об'єктно-орієнтоване проектування з прикладами застосування: пров. з англ. - М.: Конкорд, 1992.
10. Е.А. Жоголєв. Система програмування з використанням бібліотеки підпрограм / / Система автоматизація програмування. - М.: Физматгиз, 1961. с. 15-52.
11. Ф.П. Брукс, мл. Як проектуються і створюються програмні комплекси / Пер. з англ. А.П. Єршова. - М.: Наука, 1979.
12. RC Holt. Structure of Computer Programs: A Survey / / Proceedings of the IEEE, 1975, 63 (6). - P. 879-893.
13. Дж. Хьюз, Дж. Мічтом. Структурний підхід до програмування. - М.: Світ, 1980.
14. Е.А. Жоголєв. Технологічні основи модульного програмування / / Програмування, 1980, № 2. - С.44-49.
15. Б. Боемі, Дж. Браун, Х. Каспар і ін Характеристики якості програмного забезпечення. - М.: Світ, 1981.
16. В.В. Липа. Якість програмного забезпечення. - М.: Фінанси і статистика, 1983.
17. Б. Шнейдерман. Психологія програмування. - М.: Радіо і зв'язок, 1984.
18. Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 # 610. - Part 6.
19. В.Ш. Кауфман. Мови програмування. Концепції та принципи. М.: Радіо і зв'язок, 1993.
20. Вимоги та специфікації в розробці програм: пров. з англ. - М.: Світ, 1984.
21. В.Н. Агафонов. Специфікація програм: понятійні кошти та їх організація. - К.: Наука (Сибірське відділення), 1987.

ЗАМОК ДРАКОНА

Математика робить те, що можна, так, як треба, то як інформатика робить те, що потрібно, так, як можна. Людині властиво помилятися.
Сенека

Лекція 2.

ДЖЕРЕЛА ПОМИЛОК У ПРОГРАМНИХ ​​ЗАСОБАХ

Інтелектуальні можливості людини, які використовуються при розробці програмних систем. Поняття про простих і складних системах, про малих і великих системах. Неправильний переклад інформації з одного подання до іншого - основна причина помилок при розробці програмних засобів. Модель перекладу і джерела помилок.

1. Інтелектуальні можливості людини

Дейкстра [REF _Ref53419524 \ r \ h \ * MERGEFORMAT 1 ] Виділяє три інтелектуальні можливості людини, які використовуються при розробці ПС:
· Здатність до перебору,
· Здатність до абстракції,
· Здатність до математичної індукції.
Здатність людини до перебору пов'язана з можливістю послідовного перемикання уваги з одного предмета на інший з впізнавання шуканого предмета. Ця здатність вельми обмежена - в середньому людина може впевнено (не збиваючись) перебирати в межах 1000 предметів (елементів). Людина повинна навчитися діяти з урахуванням цієї своєї обмеженості. Засобом подолання цієї обмеженості є його здатність до абстракції, завдяки якій людина може об'єднувати різні предмети або екземпляри в одне поняття, замінювати безліч елементів одним елементом (іншого роду). Здатність людини до математичної індукції дозволяє йому справлятися з нескінченними послідовностями.
При розробці ПС людина має справу з системами. Під системою будемо розуміти сукупність взаємодіючих (що знаходяться у відносинах) один з одним елементів. ПС можна розглядати як приклад системи. Логічно зв'язаний набір програм є іншим прикладом системи. Будь-яка окрема програма також є системою. Зрозуміти систему - значить осмислено перебрати всі шляхи взаємодії між її елементами. У силу обмеженості людини до перебору будемо розрізняти прості і складні системи [REF _Ref53419906 \ r \ h \ * MERGEFORMAT 2 ]. Під простою системою будемо розуміти таку систему, в якій людина може впевнено перебрати всі шляхи взаємодії між її елементами, а під складною системою - таку систему, в якій він цього зробити не в змозі. Між простими і складними системами немає чіткої межі, тому можна говорити і про проміжному класі систем: до таких систем відносяться програми, про які програмістський фольклор стверджує, що «в кожній налагодженої програмі є хоча б одна помилка».
При розробці ПС ми не завжди можемо впевнено знати про всі зв'язки між її елементами з-за можливих помилок. Тому корисно вміти оцінювати складність системи за кількістю її елементів: числом потенційних шляхів взаємодії між її елементами, тобто n! , Де n - число її елементів. Систему назвемо малої, якщо n <7 (6! = 720 <1000), систему назвемо великий, якщо n> 7. При n = 7 маємо проміжний клас систем. Мала система завжди є простою, а більша може бути як простий, так і складною. Завдання технології програмування - навчитися робити великі системи простими.
Отримана оцінка простих систем за кількістю елементів широко використовується на практиці. Так, для керівника колективу дуже бажано, щоб у ньому не було більше шести взаємодіючих між собою підлеглих. Дуже важливо також дотримуватися правила: «все, що може бути сказано, повинно бути сказано в шести пунктах або менше». Цьому правилу ми будемо намагатися слідувати в цьому посібнику: всякі перерахування взаємопов'язаних тверджень (набір рекомендацій, список вимог і т.п.) будуть відповідним чином групуватися і узагальнюватися. Корисно йому слідувати і при розробці ПС.

2. Неправильний переклад як причина помилок у програмних засобах

Замовник
Розробник
Вимоги до ПС
Зовнішнє опис ПС
специфікація базового програмного забезпечення
Специфікація заданої апаратури
тексти програм ПС
Специфікація мови програмування
документація користувача

При розробці і використанні ПС ми багато разів маємо справу [REF _Ref53419498 \ r \ h \ * MERGEFORMAT 3 ] З перетворенням (перекладом) інформації з однієї форми в іншу (див. REF _Ref53513384 \ h \ * MERGEFORMAT Рис. 1 ). Замовник формулює свої потреби в ПС у вигляді деяких вимог. Виходячи з цих вимог, розробник створює зовнішнє опис ПС, використовуючи при цьому специфікацію (опис) заданої апаратури і, можливо, специфікацію базового програмного забезпечення. На підставі зовнішнього опису та специфікації мови програмування створюються тексти програм ПС на цій мові. За зовнішнім опису ПС розробляється й документація користувача. Текст кожної програми є вихідною інформацією при будь-якому її перетворенні, зокрема, при виправленні в ній помилки. Користувач на підставі документації виконує ряд дій для застосування ПС і здійснює інтерпретацію отриманих результатів. Скрізь тут, а також у ряді інших процесах розробки ПС, має місце зазначений переклад інформації.
Рис. SEQ Рис. \ * ARABIC 1. Груба схема розробки і застосування ПС.
На кожному з цих етапів переклад інформації може бути здійснено неправильно, наприклад, через неправильне розуміння початкового представлення інформації. Виникнувши на одному з етапів помилка в поданні інформації поширюється на наступні етапи розробки і, в кінцевому рахунку, опиниться в самому ПС.

3. Модель перекладу

Щоб зрозуміти природу помилок при перекладі розглянемо модель [REF _Ref53419498 \ n \ h \ * MERGEFORMAT 3 ], Зображену на REF _Ref53517068 \ h \ * MERGEFORMAT Рис. 2 . На ній людина здійснює переклад інформації з уявлення A до подання B. При цьому він здійснює чотири основні кроки перекладу:
· Він отримує інформацію, що міститься в поданні A, за допомогою свого читає механізму R;
· Він запам'ятовує отриману інформацію у своїй пам'яті M;
· Він вибирає зі своєї пам'яті перетворені інформацію та інформацію, що описує процес перетворення, виконує переклад і посилає результат своєму авторові механізму W;
·
ЛЮДИНА
R
A
M
Інформація, що описує процес перетворення
перетворюються інформація
W
B

за допомогою цього механізму він фіксує уявлення B.
Рис. SEQ Рис. \ * ARABIC 2. Модель перекладу.
На кожному з цих кроків людина може зробити помилку різної природи. На першому кроці здатність людини «читати між рядків» (здатність, що дозволяє йому розуміти текст, що містить неточності або навіть помилки) може стати причиною помилки в ПС. Помилка виникає в тому випадку, коли при читанні документа A людина, намагаючись відновити бракуючу інформацію, бачить те, що він чекає, а не те, що мав на увазі автор документа A. У цьому випадку краще було б звернутися до автора документа за роз'ясненнями. При запам'ятовуванні інформації людина здійснює її осмислювання (тут важливий його рівень підготовки і знання предметної області, до якої відноситься документ A). І, якщо він поверхово або неправильно зрозуміє, то інформація буде запам'ятати в спотвореному вигляді. На третьому етапі забудькуватість людини може призвести до того, що він може вибрати зі своєї пам'яті не всю перетворені інформацію або не всі правила перекладу, в результаті чого платіж буде здійснено невірно. Це зазвичай відбувається при великому обсязі погано організованої інформації. І, нарешті, на останньому етапі прагнення людини скоріше зафіксувати інформацію часто призводить до того, що подання цієї інформації виявляється неточним, створюючи ситуацію для подальшої неоднозначною її інтерпретації.

4. Основні шляхи боротьби з помилками

Враховуючи розглянуті особливості дій людини при перекладі можна вказати наступні шляхи боротьби з помилками:
· Звуження простору перебору (спрощення створюваних систем),
· Забезпечення необхідного рівня підготовки розробника (це функції менеджерів колективу розробників),
· Забезпечення однозначності інтерпретації представлення інформації,
· Контроль правильності перекладу (включаючи і контроль однозначності інтерпретації).

ЛІТЕРАТУРА

22. Е. Дейкстра. Нотатки з структурному програмуванню / / У. Дал, Е. Дейкстра, К. Хоор. Структурне програмування. - М.: Світ, 1975. - С. 7-97.
23. Е.А. Жоголєв. Технологічні основи модульного програмування / / Програмування, 1980, № 2. - С.44-49.
24. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980.

ЗАМОК ДРАКОНА

Краще - ворог хорошого.
Народна мудрість

Лекція 3.

ЗАГАЛЬНІ ПРИНЦИПИ РОЗРОБКИ ПРОГРАМНИХ ​​ЗАСОБІВ

Специфіка розробки програмних засобів. Життєвий цикл програмного засобу. Поняття якості програмного засобу. Забезпечення надійності - основний мотив розробки програмного засобу. Методи боротьби зі складністю. Забезпечення точності перекладу. Подолання бар'єру між користувачем та розробником. Забезпечення контролю правильності прийнятих рішень.

1. Специфіка розробки програмних засобів

Розробці програмних засобів притаманний ряд специфічних особливостей [REF _Ref53591201 \ r \ h \ * MERGEFORMAT 1 ]:
· Перш за все, слід відзначити деяке протистояння: неформальний характер вимог до ПС (постановки задачі) і поняття помилки в ньому, але формалізований основний об'єкт розробки - програми ПС. Тим самим розробка ПС містить певні етапи формалізації, а перехід від неформального до формального істотно неформалів.
· Розробка ПС носить істотно творчий характер (на кожному кроці доводиться робити який-небудь вибір, ухвалювати будь-яке рішення), а не зводиться до виконання будь-якої послідовності регламентованих дій. Тим самим ця розробка ближче до процесу проектування будь-яких складних пристроїв, але ніяк не до їх масового виробництва. Цей творчий характер розробки ПС зберігається до самого її кінця.
· Слід відзначити також особливість продукту розробки. Він являє собою деяку сукупність текстів (тобто статичних об'єктів), сенс ж (семантика) цих текстів виражається процесами обробки даних і діями користувачів, що запускають ці процеси (тобто є динамічним). Це зумовлює вибір розробником низки специфічних прийомів, методів і засобів.
· Продукт розробки має і іншу специфічну особливість: ПС при своєму використанні (експлуатації) не витрачається і не витрачає використовуваних ресурсів.

2. Життєвий цикл програмного засобу

Під життєвим циклом ПС розуміють весь період його розробки та експлуатації (використання), починаючи від моменту виникнення задуму ПС і закінчуючи припиненням всіх видів його використання [REF _Ref53591201 \ r \ h \ * MERGEFORMAT 1 , REF _Ref53591861 \ r \ h \ * MERGEFORMAT 2 , REF _Ref53591864 \ r \ h \ * MERGEFORMAT 3 , REF _Ref53591867 \ r \ h \ * MERGEFORMAT 4 ]. Життєвий цикл включає всі процеси створення та використання ПС (software process).
Розрізняють такі стадії життєвого циклу ПС (див. REF _Ref53591955 \ h \ * MERGEFORMAT Рис. 1 ): Розробку ПС, виробництво програмних виробів (ПІ) і експлуатацію ПС.

Рис. SEQ Рис. \ * ARABIC 1. Стадії і фази життєвого циклу ПС.
Стадія розробки (development) ПС складається з етапу його зовнішнього опису, етапу конструювання ПС, етапу кодування (програмування у вузькому сенсі) ПС та етапу атестації ПС. Усім цим етапам супроводжують процеси документування та управління (management) розробкою ПС. Етапи конструювання та кодування часто перекриваються, іноді досить сильно. Це означає, що кодування деяких частин програмного засобу може бути розпочате до завершення етапу конструювання.
Зовнішнє опис (Requirements document) ПС є описом його поведінки з точки зору зовнішнього по відношенню до нього спостерігача з фіксацією вимог щодо його якості. Зовнішнє опис ПС починається з визначення вимог до ПС з боку користувачів (замовника).
Конструювання (design) ПС охоплює процеси: розробку архітектури ПС, розробку структур програм ПС та їх детальну специфікацію.
Кодування (coding) - створення текстів програм на мовах програмування, їх відладку з тестуванням ПС.
На етапі атестації ПС проводиться оцінка якості ПС, після успішного завершення, якого розробка ПС вважається закінченою.
Програмний виріб (ПІ) - примірник чи копія, знята з розробленого ПС.
Виготовлення ПІ - це процес генерації та / або відтворення (зняття копії) програм та програмних документів ПС з метою їх поставки користувачеві для застосування за призначенням. Виробництво ПІ - це сукупність робіт по забезпеченню виготовлення необхідної кількості ПІ у встановлені терміни [REF _Ref53591201 \ r \ h \ * MERGEFORMAT 1 ]. Стадія виробництва ПС в життєвому циклі ПС є, по суті, виродженої (несуттєвою), тому що являє рутинну роботу, яка може бути виконана автоматично і без помилок. Цим вона принципово відрізняється від стадії виробництва різної техніки. У зв'язку з цим у літературі цю стадію, як правило, не включають в життєвий цикл ПС.
Стадія експлуатації ПС охоплює процеси зберігання, впровадження та супроводу ПС, а також транспортування і застосування (operation) ПІ за своїм призначенням. Вона складається з двох паралельно проходять фаз: фази застосування ПС і фази супроводу ПС [REF _Ref53591867 \ r \ h \ * MERGEFORMAT 4 , REF _Ref53419509 \ r \ h \ * MERGEFORMAT 5 ].
Застосування (operation) ПС - це використання ПС для вирішення практичних завдань на комп'ютері шляхом виконання її програм.
Супровід (maintenance) ПС - це процес збору інформації про його якість в експлуатації, усунення виявлених в ньому помилок, його доопрацювання і модифікації, а також сповіщення користувачів про внесені до нього зміни [REF _Ref53591201 \ r \ h \ * MERGEFORMAT 1 , REF _Ref53591867 \ r \ h \ * MERGEFORMAT 4 , REF _Ref53419509 \ r \ h \ * MERGEFORMAT 5 ].

3. Поняття якості програмного засобу

Кожне ПС повинне виконувати певні функції, тобто робити те, що задумано. Гарне ПС повинно мати ще цілу низку властивостей, що дозволяє успішно його використати протягом тривалого періоду, тобто володіти певною якістю. Якість ПС - це сукупність його рис та характеристик, які впливають на його здатність задовольнити потреби користувачів [REF _Ref53592864 \ r \ h \ * MERGEFORMAT 6 ]. Це не означає, що різні ПС повинні володіти однією і тією ж сукупністю таких властивостей у їх вищої можливою мірою. Цьому перешкоджає той факт, що підвищення якості ПС по одному з таких властивостей часто може бути досягнуто лише ціною зміни вартості, термінів завершення розробки і зниження якості цього ПС по інших його властивостях. Якість ПС є задовільним, коли воно має вказаними властивостями в такій мірі, щоб гарантувати успішне його використання.
Сукупність властивостей ПС, яка утворює задовільний для користувача якість ПС, залежить від умов і характеру експлуатації цього ПС, тобто від позиції, з якою має розглядатися якість цього ПС. Тому при описі якості ПС повинні бути, перш за все, фіксовані критерії відбору необхідних властивостей ПС. В даний час критеріями якості ПС прийнято вважати [REF _Ref53592864 \ r \ h \ * MERGEFORMAT 6 , REF _Ref53593336 \ r \ h \ * MERGEFORMAT 7 , REF _Ref53593338 \ r \ h \ * MERGEFORMAT 8 , REF _Ref53593340 \ r \ h \ * MERGEFORMAT 9 , REF _Ref53593342 \ r \ h \ * MERGEFORMAT 10 ]:
· Функціональність,
· Надійність,
· Легкість застосування,
· Ефективність,
· Сопровождаемость,
· Мобільність.
Функціональність - це здатність ПС виконувати набір функцій, що задовольняють заданим або імовірною потребам користувачів. Набір зазначених функцій визначається в зовнішньому описі ПС.
Надійність докладно обговорювалася в першій лекції.
Легкість застосування - це характеристики ПС, які дозволяють мінімізувати зусилля користувача з підготовки вихідних даних, застосування ПС та оцінці отриманих результатів, а також викликати позитивні емоції визначеного або подразумеваемого користувача.
Ефективність - це відношення рівня послуг, що надаються ПС користувачеві при заданих умовах, до обсягу використовуваних ресурсів.
Сопровождаемость - це характеристики ПС, які дозволяють мінімізувати зусилля по внесенню змін для усунення в ньому помилок і за його модифікації відповідно до потреб користувачів.
Мобільність - це здатність ПС бути перенесеним з одного середовища (оточення) в іншу, зокрема, з однієї ЕОМ на іншу.
Функціональність і надійність є обов'язковими критеріями якості ПС, причому забезпечення надійності буде червоною ниткою проходити по всіх етапах і процесів розроблення ПС. Інші критерії використовуються залежно від потреб користувачів відповідно до вимог до ПС - їх забезпечення буде обговорюватися у відповідних розділах курсу.

4. Забезпечення надійності - основний мотив розробки програмних засобів

Розглянемо тепер загальні принципи забезпечення надійності ПС, що, як ми вже підкреслювали, є основним мотивом розробки ПС, що задає специфічне забарвлення всім технологічним процесам розробки ПС. У техніці відомі чотири підходи забезпечення надійності [REF _Ref53419498 \ r \ h \ * MERGEFORMAT 11 ]:
· Попередження помилок;
· Самовиявлення помилок;
· Самовиправлення помилок;
· Забезпечення стійкості до помилок.
Метою підходу попередження помилок - не допустити помилок в готових продуктах, у нашому випадку - в ПС. Проведене розгляд природи помилок при розробці ПС дозволяє для досягнення цієї мети сконцентрувати увагу на наступних питаннях:
· Боротьбі зі складністю;
· Забезпечення точності перекладу;
· Подолання бар'єру між користувачем та розробником;
· Забезпечення контролю прийнятих рішень.
Цей підхід пов'язаний з організацією процесів розробки ПС, тобто з технологією програмування. І хоча, як ми вже відзначали, гарантувати відсутність помилок в ПС неможливо, але в рамках цього підходу можна досягти прийнятного рівня надійності ПС.
Решта три підходи пов'язані з організацією самих продуктів технології, в нашому випадку - програм. Вони враховують можливість помилки в програмах. Самовиявлення помилки в програмі означає, що програма містить засоби виявлення відмови у процесі її виконання. Самовиправлення помилки в програмі означає не тільки виявлення відмови у процесі її виконання, а й виправлення наслідків цієї відмови, для чого в програмі повинні бути відповідні кошти. Забезпечення стійкості програми до помилок означає, що в програмі містяться засоби, що дозволяють локалізувати область впливу відмови програми, або зменшити його неприємні наслідки, а іноді запобігти катастрофічні наслідки відмови. Однак, ці підходи використовуються дуже рідко (може бути, відносно частіше використовується забезпечення стійкості до помилок). Пов'язано це, по-перше, з тим, що багато прості методи, використовувані в техніці в рамках цих підходів, не застосовуються в програмуванні, наприклад, дублювання окремих блоків і пристроїв (виконання двох копій однієї і тієї ж програми завжди буде призводити до однакового ефекту - правильного чи неправильного). А, по-друге, додавання в програму додаткових коштів призводить до її ускладнення (іноді - значному), що в якійсь мірі заважає методів запобігання помилок.

5. Методи боротьби зі складністю

Ми вже обговорювали в лекції 2 сутність питання боротьби зі складністю при розробці ПС. Відомі два загальних методу боротьби зі складністю систем:
· Забезпечення незалежності компонент системи;
· Використання в системах ієрархічних структур.
Забезпечення незалежності компонент означає розбиття системи на такі частини, між якими мають залишитися якомога менше зв'язків. Одним із втілень цього методу є модульне програмування. Використання ієрархічних структур дозволяє локалізувати зв'язку між компонентами, допускаючи їх лише між компонентами, що належать суміжним рівнях ієрархії. Цей метод, по суті, означає розбиття великої системи на підсистеми, що утворюють малу систему. Тут істотно використовується здатність людини до абстрагування.

6. Забезпечення точності перекладу

Забезпечення точності перекладу спрямоване на досягнення однозначності інтерпретації документів різними розробниками, а також користувачами ПС. Це вимагає дотримуватися при перекладі певної дисципліни. Майерс пропонує використовувати загальну дисципліну вирішення завдань, розглядаючи переклад як рішення задачі [REF _Ref53419498 \ r \ h \ * MERGEFORMAT 11 ]. Кращим керівництвом за рішенням завдань він вважає книгу Пойа «Як вирішувати проблему» [REF _Ref53593409 \ r \ h \ * MERGEFORMAT 12 ]. Відповідно до цього весь процес перекладу можна розбити на наступні етапи:
· Зрозумійте завдання;
· Складіть план (включаючи цілі і методи рішення);
· Виконайте план (перевіряючи правильність кожного кроку);
· Проаналізуйте отримане рішення.

7. Подолання бар'єру між користувачем та розробником

Як забезпечити, щоб ПС виконувала те, що користувачеві розумно очікувати від неї? Для цього необхідно правильно зрозуміти, по-перше, чого хоче користувач, і, по-друге, його рівень підготовки і навколишню обстановку. Тому слід - залучати користувача до процесів прийняття рішень при розробці ПС, - ретельно освоїти особливості його роботи (краще всього - побувати в його «шкурі»).

8. Контроль прийнятих рішень

Обов'язковою кроком у кожному процесі (етапі) розробки ПС повинна бути перевірка правильності прийнятих рішень. Це дозволить виявляти і виправляти помилки на самій ранній стадії після її виникнення, що, по-перше, істотно знижує вартість її виправлення та, по-друге, підвищує ймовірність правильного її усунення.
З урахуванням специфіки розробки ПС необхідно застосовувати скрізь, де це можливо,
· Суміжний контроль,
· Поєднання як статичних, так і динамічних методів контролю.
Суміжний контроль означає, перевірку отриманого документа особами, які не беруть участі в його розробці, з двох сторін: по-перше, з боку автора початкового для контрольованого процесу документа, і, по-друге, особами, які будуть використовувати отриманий документ як вихідного в наступних технологічних процесах. Такий контроль дозволяє забезпечувати однозначність інтерпретації отриманого документа.
Поєднання статичних і динамічних методів контролю означає, що потрібно не тільки контролювати документ як такий, але і перевіряти, який процес обробки даних він описує. Це відображає одну із специфічних особливість ПС (статична форма, динамічний зміст).

ЛІТЕРАТУРА

25. Е.А. Жоголєв. Введення в технологію програмування (конспект лекцій). - М.: «ДІАЛОГ-МДУ», 1994.
26. М. Зелковец, А. Шоу, Дж. Геннон. Принципи розробки програмного забезпечення. - М.: Мир, 1982, с. 11.
27. К. Зіглер. Методи проектування програмних систем. - М.: Мир, 1985, с. 15-23.
28. Дж. Фокс. Програмне забезпечення та його розробка. - М.: Мир, 1985, с. 53-67, 125-130.
29. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992.
30. Criteria for Evalution of Software. - ISO TC97/SC7 # 383.
31. Revised version of DP9126 - Criteria for Evalution of Software Quality Characteristics. - ISO TC97/SC7 # 610. - Part 6.
32. Б. Боемі, Дж. Браун, Х. Каспар і ін Характеристики якості програмного забезпечення. - М.: Світ, 1981.
33. В.В. Липа. Якість програмного забезпечення. - М.: Фінанси і статистика, 1983.
34. Б. Шнейдерман. Психологія програмування. - М.: Радіо і зв'язок, 1984. - С. 99-103.
35. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980.
36. Д. Пойа. Як вирішувати проблему. - М.: Наука, 1961.

ЗАМОК ДРАКОНА

Не переходь міст, поки не дійшов до нього.
Народне прислів'я

Лекція 4.

ЗОВНІШНЄ ОПИС ПРОГРАМНОГО ЗАСОБУ

Поняття зовнішнього опису, його призначення і роль у забезпеченні якості програмного засобу. Визначення вимог до програмного засобу. Специфікація якості програмного засобу. Основні примітиви якості програмного засобу. Функціональна специфікація програмного засобу. Контроль зовнішнього опису

1. Призначення зовнішнього опису програмного засобу та його роль у забезпеченні якості програмного засобу

Розробникам великих програмних засобів доводиться вирішувати дуже специфічні і важкі проблеми, особливо, якщо це ПС має представляти собою програмну систему нового типу, в погано комп'ютеризованої предметної області. Розробка ПС починається з етапу формулювання вимог до ПС, на якому, виходячи з досить неясних побажань замовника, повинен бути отриманий документ, досить точно визначає завдання розробників ПС. Цей документ ми називаємо зовнішнім описом ПС (у літературі його часто називають специфікацією вимог [REF _Ref53591201 \ r \ h \ * MERGEFORMAT 1 ]).
Дуже часто вимоги до ПС плутають з вимогами до процесів його розробки (до технологічних процесів). Останні включати в зовнішнє опис не слід, якщо тільки вони не пов'язані з оцінкою якості ПС. У разі необхідності вимоги до технологічних процесів можна оформити у вигляді самостійного документа, який буде використовуватися при управлінні (керівництві) розробкою ПС.
Зовнішнє опис ПС грає роль точної постановки завдання, вирішення якої повинно забезпечити розробляється ПС. Більш того, воно повинно містити всю інформацію, яку необхідно знати користувачеві для застосування ПС. Воно є вихідним документом для трьох паралельно протікають процесів: розробки текстів (конструювання та кодування) програм, що входять в ПС, розробки документації щодо застосування ПС та розробки істотної частини комплекту тестів для тестування ПС. Помилки та неточності в зовнішньому описі, в кінцевому рахунку, трансформуються в помилки самої ПС і обходяться особливо дорого, по-перше, тому, що вони робляться на самому ранньому етапі розробки ПС, і, по-друге, тому, що вони поширюються на три паралельні процеси. Це вимагає особливо серйозних заходів щодо їх попередження.
Вихідним документом для розробки зовнішнього опису ПС є визначення вимог до ПС. Але так як через цей документ передається від замовника (користувача) до розробника основна інформація щодо необхідного ПС, то формування цього документа являє собою досить тривалий і важкий ітераційний процес взаємодії між замовником і розробником, з якого й починається етап розробки вимог до ПС [REF _Ref53597359 \ r \ h \ * MERGEFORMAT 2 ]. Труднощі, що виникають у цьому процесі, пов'язані з тим, що користувачі часто погано уявляють, що їм насправді потрібно: використання комп'ютера у «вузьких» місцях діяльності користувачів може насправді вимагати принципової зміни всієї технології цієї діяльності (про що користувачі, як правило, і не здогадуються). Крім того, проблеми, які необхідно відобразити у визначенні вимог, можуть не мати певної формулювання [REF _Ref53419509 \ r \ h \ * MERGEFORMAT 1 ], Що призводить до поступового зміни розуміння розробниками цих проблем. У зв'язку з цим визначенням вимог часто передує процес системного аналізу, в якому з'ясовується, наскільки доцільно і реалізоване «замовляє» ПС, як вплине таке ПС на діяльність користувачів і якими особливостями він повинен мати. Іноді для прояснення дійсних потреб користувачів доводиться розробляти спрощену версію необхідного ПС, звану прототипом ПС. Аналіз «пробного» застосування прототипу дозволяє інколи суттєво уточнити вимоги до ПС.
У визначенні зовнішнього опису легко впадають в око дві самостійні його частини. Опис поведінки ПС визначає функції, які повинна виконувати ПС, і тому його називають функціональною специфікацією ПС. Функціональна специфікація визначає допустимі фрагменти програм, що реалізують декларовані функції. Вимоги до якості ПС повинні бути сформульовані так, щоб розробнику були ясні цілі [REF _Ref53597359 \ r \ h \ * MERGEFORMAT 2 ], Які він повинен прагнути досягти при розробці цього ПС. Цю частину зовнішнього опису будемо називати специфікацією якості ПС (у літературі її часто називають нефункціональній специфікацією [REF _Ref53419509 \ r \ h \ * MERGEFORMAT 1 ], Але вона, як правило, включає і вимоги до технологічних процесів). Вона, на відміну від функціональної специфікації, реалізується неформалізовані і грає роль тих орієнтирів, які значною мірою визначають вибір відповідних альтернатив при реалізації функцій ПС, а також визначає стиль всіх документів та програм розробляється ПС. Тим самим, специфікація якості відіграє вирішальну роль у забезпеченні необхідної якості ПС.
Звичайно розробка специфікації якості передує розробці функціональної специфікації ПС, так як деякі вимоги до якості ПС можуть зумовлювати включення у функціональну специфікацію спеціальних функцій, наприклад, функції захисту від несанкціонованого доступу до деяких об'єктів інформаційного середовища. Таким чином, структуру зовнішнього опису ПС можна виразити формулою:
Зовнішнє опис ПС = специфікація якості ПС + функціональна специфікація ПС
Таким чином, зовнішнє опис визначає, що повинно робити ПС і якими зовнішніми властивостями він повинен мати. Воно не відповідає на питання, як має бути влаштовано це ПС і як забезпечити необхідні його зовнішні властивості. Воно повинно досить точно і повно визначати завдання, які повинні вирішити розробники необхідного ПС. У той же час воно має бути зрозуміло представником користувачем - на його підставі замовником досить часто приймається остаточне рішення на укладання договору на розробку ПС. Зовнішнє опис відіграє велику роль у забезпеченні необхідної якості ПС, так як специфікація якості ставить для розробників ПС конкретні орієнтири, керуючі вибором прийнятних рішень при реалізації специфікованих функцій.

2. Визначення вимог до програмного засобу

Визначення вимоги до ПС є вихідним документом розробки ПС - завданням, що виражає в абстрактній формі потреби користувача. Вони в загальних рисах визначають задум ПС, характеризують умови його використання. Неправильне розуміння потреб користувача трансформуються в помилки зовнішнього опису. Тому розробка ПС починається зі створення документа, досить повно характеризує потреби користувача і дозволяє розробнику адекватно сприймати ці потреби.
Визначення вимог являє собою суміш фрагментів на природній мові, різних таблиць і діаграм. Така суміш, повинна бути зрозумілою користувачу, який знає спеціальних програмістських позначень. Зазвичай у визначенні вимог не міститься формалізованих фрагментів, крім випадків достатньо для цього підготовлених користувачів (наприклад, математично) - формалізація цих вимог становить зміст подальшої роботи колективу розробників.
Неправильне розуміння вимог замовником, користувачами і розробниками пов'язано зазвичай з різними поглядами на роль необхідного ПС в середовищі його використання [REF _Ref53419509 \ r \ h \ * MERGEFORMAT 1 ]. Тому важливим завданням при створенні визначення вимог є встановлення контексту використання ПС, що включає зв'язку між цим ПС, апаратурою і людьми. Найкраще цей контекст у визначенні вимог представити в графічній формі (у вигляді діаграм) з додаванням описів сутностей використовуваних об'єктів (блоків ПС, компонент апаратури, персоналу тощо) та характеристики зв'язків між ними.
Відомі три способи визначення вимог до ПС [REF _Ref53597359 \ r \ h \ * MERGEFORMAT 2 ]:
· Керований користувачем,
· Контрольований користувачем,
· Незалежний від користувача.
У керованої користувачем розробці визначення вимог до ПС визначаються замовником, що представляє організацію користувачів. Це відбувається зазвичай в тих випадках, коли організація користувачів (замовник) укладає договір на розробку необхідного ПС з колективом розробників і вимоги до ПС є частиною цього договору. Роль розробника ПС в створенні цих вимог зводиться, в основному, у з'ясуванні того, наскільки зрозумілі йому ці вимоги з відповідною критикою розглянутого документа. Це може призводити до створення кількох редакцій цього документа в процесі укладення зазначеного договору.
У контрольованої користувачем розробці вимоги до ПС формулюються розробником за участю представника користувачів. Роль користувача в цьому випадку зводиться до інформування розробника про свої потреби в ПС і контролю за тим, щоб формулируемого вимоги справді висловлювали його потреби в ПС. У кінцевому рахунку розроблені вимоги, як правило, затверджуються представником користувача.
У незалежній від користувача розробці вимоги до ПС визначаються без будь-якої участі користувача (на повну відповідальність розробника). Це відбувається зазвичай тоді, коли розробник вирішує створити ПС широкого застосування в розрахунку на те, розроблене їм ПС знайде попит на ринку програмних засобів.
З точки зору забезпечення надійності ПС найбільш кращим є контрольована користувачем розробка.

3. Специфікація якості програмного засобу

Розробка специфікації якості зводиться, по суті, до побудови своєрідної моделі якості розроблюваної ПС [REF _Ref53597359 \ r \ h \ * MERGEFORMAT 2 , REF _Ref53597580 \ r \ h \ * MERGEFORMAT 3 ]. У цій моделі повинен бути перелік усіх тих достатньо елементарних властивостей, які потрібно забезпечити в розробляється ПС і які в сукупності утворюють прийнятне для користувача якість ПС. При цьому кожна з цих властивостей має бути достатньою мірою конкретизовано з урахуванням визначення вимог щодо розроблюваного ПС та можливості оцінки його наявності у розробленого ПС або необхідного ступеня володіння їм цим ПС.
Для конкретизації якості ПС по кожному з критеріїв використовується стандартизований набір досить простих властивостей ПС [REF _Ref53597580 \ r \ h \ * MERGEFORMAT 3 , REF _Ref53597600 \ r \ h \ * MERGEFORMAT 4 , REF _Ref53593336 \ r \ h \ * MERGEFORMAT 5 , REF _Ref53597605 \ r \ h \ * MERGEFORMAT 6 ], Однозначно інтерпретуються розробниками. Такі властивості ми будемо називати примітивами якості ПС. Деякі з примітивів можуть використовуватися за кількома критеріями. Нижче наводиться залежність критеріїв якості від примітивів якості ПС.
Функціональність: завершеність.
Надійність: завершеність, точність, автономність, стійкість, захищеність.
Легкість застосування: П-документування, інформативність (тільки стосовно до документації із застосування), комунікабельність, стійкість, захищеність.
Ефективність: временнaя ефективність, ефективність по пам'яті, ефективність по пристроях.
Сопровождаемость. З даним критерієм пов'язано багато різних примітивів якості. Проте їх можна розподілити за двома групами, виділивши два підкритеріїв якості: ізучаема і модифікованості. Ізучаема - це характеристики ПС, які дозволяють мінімізувати зусилля по вивченню та розумінню програм і документації ПС. Модифицируемость - це характеристики ПС, які спрощують внесення до нього необхідних змін і доробок.
Ізучаема: С-документування, інформативність (тут стосовно і до документації по супроводу), зрозумілість, структурованість, легкість для читання.
Модифицируемость: розширюваність, структурованість, модульність.
Мобільність: незалежність від пристроїв, автономність, структурованість, модульність.
Нижче даються визначення використовуваних примітивів якості ПС [REF _Ref53597580 \ r \ h \ * MERGEFORMAT 3 , REF _Ref53597600 \ r \ h \ * MERGEFORMAT 4 , REF _Ref53593336 \ r \ h \ * MERGEFORMAT 5 ].
Завершеність - властивість, що характеризує ступінь володіння ПС усіма необхідними частинами і рисами, що вимагаються для виконання своїх явних і неявних функцій.
Точність - міра, що характеризує прийнятність величини похибки в видавали програмами ПС результати з точки зору передбачуваного їх використання.
Автономність - властивість, що характеризує здатність ПС виконувати приписані функції без допомоги або підтримки інших компонент програмного забезпечення.
Стійкість - властивість, що характеризує здатність ПС продовжувати коректне функціонування, незважаючи на завдання неправильних (помилкових) вхідних даних.
Захищеність - властивість, що характеризує здатність ПС протистояти навмисним або ненавмисним деструктивним (руйнуючим) діям користувача.
П-документування - властивість, що характеризує наявність, повноту, зрозумілість, доступність і наочність навчальної, інструктивної та довідкової документації, необхідної для застосування ПС.
Інформативність - властивість, що характеризує наявність у складі ПС інформації, необхідної і достатньої для розуміння призначення ПС, прийнятих припущень, існуючих обмежень, вхідних даних і результатів роботи окремих компонент, а також поточного стану програм у процесі їх функціонування.
Комунікабельність - властивість, що характеризує ступінь, в якій ПС полегшує завдання або опис вхідних даних, а також забезпечує видачу корисних відомостей у формі та зі змістом, простими для розуміння.
Временнaя ефективність - міра, що характеризує здатність ПС виконувати покладені на нього функції за певний відрізок часу.
Ефективність по пам'яті - міра, що характеризує здатність ПС виконувати покладені на нього функції за певних обмежень на використовувану пам'ять.
Ефективність по пристроях - міра, що характеризує економічність використання пристроїв машини для вирішення поставленого завдання.
З-документіровапнность - властивість, що характеризує з точки зору наявності документації, що відбиває вимоги до ПС та результати різних етапів розробки даної ПС, що включають можливості, обмеження та інші риси ПС, а також їх обгрунтування.
Зрозумілість - властивість, що характеризує ступінь в якій ПС дозволяє вивчає його особі зрозуміти його призначення, зроблені припущення та обмеження, вхідні дані і результати роботи його програм, тексти цих програм і стан їх реалізації. Цей примітив якості синтезований нами з таких примітивів ІСО [4.4], як узгодженість, самодокументірованность, чіткість і, власне, зрозумілість.
Структурованість - властивість, що характеризує програми ПС з точки зору організації взаємопов'язаних їх частин в єдине ціле певним чином (наприклад, відповідно до принципів структурного програмування).
Удобочитаемость - властивість, що характеризує легкість сприйняття тексту програм ПС (відступи, фрагментація, формативне).
Розширюваність - властивість, що характеризує здатність ПС до використання більшого обсягу пам'яті для зберігання даних або розширення функціональних можливостей окремих компонент.
Модульність - властивість, що характеризує ПС з точки зору організації його програм з таких дискретних компонент, що зміна однієї з них надає мінімальний вплив на інші компоненти.
Незалежність від пристроїв - властивість, що характеризує здатність ПС працювати на різноманітному апаратному забезпеченні (різних типах, марках, моделях ЕОМ).

4. Функціональна специфікація програмного засобу

З урахуванням призначення функціональної специфікації ПС і важких наслідків неточностей і помилок у цьому документі, функціональна специфікація повинна бути математично точною. Це не означає, що вона повинна бути формалізована настільки, що по ній можна було б автоматично генерувати програми, вирішальні поставлене завдання. А означає лише, що вона повинна базуватися на поняттях, побудованих як математичні об'єкти, і твердженнях, однозначно розуміються розробниками ПС. Досить часто функціональна специфікація формулюється на природній мові. Тим не менше, використання математичних методів і формалізованих мов при розробці функціональної специфікації дуже бажано, тому цим питанням буде присвячена окрема лекція.
Функціональна специфікація складається з трьох частин:
· Опису зовнішнього інформаційного середовища, до якої повинні застосовуватися програми розробляється ПС;
· Визначення функцій ПС, визначених на множині станів цієї інформаційного середовища (такі функції будемо називати зовнішніми функціями ПС);
· Опис небажаних (виняткових) ситуацій, які можуть виникнути при виконанні програм ПС, і реакцій на ці ситуації, які повинні забезпечити відповідні програми.
У першій частині повинні бути визначені на концептуальному рівні всі використовувані канали введення і виведення і всі інформаційні об'єкти, до яких буде застосовуватися розробляється ПС, а також істотні зв'язки між цими інформаційними об'єктами. Прикладом опису інформаційного середовища може бути концептуальна схема бази даних або опис мережі датчиків і приладів, якою має керувати розробляється ПС.
У другій частині вводяться позначення всіх обумовлених функцій, специфицируются всі вхідні дані і результати виконання кожної обумовленою функції, включаючи вказівку їх типів і завдань всіх співвідношень (або обмежень), яким повинні задовольняти ці дані і результати. І, нарешті, визначається семантика кожної з цих функцій, що є найбільш важким завданням функціональної специфікації ПС. Зазвичай ця семантика описується неформально на природній мові - приблизно так, як це робиться при описі семантики багатьох мов програмування. Це завдання може бути в ряді випадків істотно полегшена при досить чіткому описі зовнішнього інформаційного середовища, якщо зовнішні функції задають будь-які маніпуляції з її об'єктами.
У третій частині повинні бути перераховані всі істотні з точки зору зовнішнього спостерігача (користувача) випадки, коли ПС не зможе нормально виконати ту чи іншу свою функцію (наприклад, при виявленні помилки під час взаємодії з користувачем, або при спробі застосувати яку-небудь функцію до даними, не задовольняє співвідношенням, зазначеним у її специфікації, або при отриманні результату, що порушує ліміт). Для кожного такого випадку повинна бути визначена (описана) реакція ПС.

5. Методи контролю зовнішнього опису програмного засобу

Розробка зовнішнього опису обов'язково повинна завершуватися проведенням ретельного і різноманітного контролю правильності зовнішнього опису. Метою цього процесу є знайти як можна більше помилок, зроблених на цьому етапі. Враховуючи, що результатом цього етапу є, як правило, ще неформалізований текст, то тут на перший план виступають психологічні чинники контролю. Можна виділити наступні методи контролю, які застосовуються на цьому етапі:
· Статичний перегляд,
· Суміжний контроль,
· Користувальницький контроль,
· Ручна імітація.
Перший метод передбачає уважне прочитання тексту зовнішнього опису розробником з метою перевірка його повноти і несуперечності, а також виявлення інших неточностей і помилок.
Суміжний контроль специфікації якості зверху - це її перевірка з боку розробника вимог до ПС, а суміжний контроль функціональної специфікації - це її перевірка розробниками вимог до ПС та специфікації якості. Суміжний контроль зовнішнього опису знизу - це його вивчення та перевірка розробниками архітектури ПС і текстів програм, а також розробниками документації щодо застосування та розробниками комплекту тестів.
Користувальницький контроль зовнішнього опису висловлює участь користувача (замовника) у прийнятті рішень при розробці зовнішнього опису та його контролі. Якщо розробка вимог до ПС велася під управлінням користувача, то для користувача контроль зовнішнього опису, по суті, означає його суміжний контроль зверху. Однак, якщо представнику користувача виявляється важко самостійно розібратися в зовнішньому описі, створюється спеціальна група розробників, що виконує роль користувача (і взаємодіє з них) для проведення такого контролю.
Ручна імітація висловлює своєрідний динамічний контроль зовнішнього опису, точніше кажучи, функціональної специфікації ПС. Для цього необхідно підготувати вихідні дані (тести) та на основі функціональної специфікації здійснити імітацію поведінки (роботи) розробляється ПС. При цьому цю імітацію здійснює спеціально призначений розробник, виконує, по суті, роль майбутніх програм ПС. Різновидом такого контролю є імітація за терміналом. У цьому випадку дані вводяться в комп'ютер людиною, що грає роль користувача, і передаються за допомогою нескладної програми на інший термінал, за яким сидить розробник, що виконує роль програм ПС. Отримані результати передаються через комп'ютер на перший термінал.

ЛІТЕРАТУРА

37. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992.
38. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980. с. 49-77.
39. Е.А. Жоголєв. Введення в технологію програмування (конспект лекцій). - М.: «ДІАЛОГ-МДУ», 1994.
40. Criteria for Evalution of Software. - ISO TC97/SC7 # 383.
41. Revised version of DP9126 - Criteria for Evalution of Software Quality Characteristics. - ISO TC97/SC7 # 610. - Part 6.
42. Б. Боемі, Дж. Браун, Х. Каспар і ін Характеристики якості програмного забезпечення. - М.: Світ, 1981.

ЗАМОК ДРАКОНА

Все, що взагалі може бути сказано, повинно бути сказано ясно, а про що можна говорити, про те слід мовчати.
Л. Вітгенштейн

Лекція 5.

МЕТОДИ специфікації семантики ФУНКЦІЙ

Основні підходи до специфікації семантики функцій. Табличний підхід, метод таблиць рішень. Алгебраїчний підхід: операційна, денотаціонная і аксіоматична семантика.

1. Основні підходи до специфікації семантики функцій

Для специфікації семантики функцій використовуються такі підходи: табличний, алгебраїчний і логічний REF _Ref53602543 \ h \ * MERGEFORMAT (1 ), А також графічний (5.2).
Табличний підхід для визначення функцій добре відомий ще з середньої школи. Він базується на використанні таблиць. У програмуванні ці методи отримали розвиток в методі таблиць рішень.
Алгебраїчний підхід базується на використанні рівностей для визначення функцій. У цьому випадку для визначення деякого набору функцій будується система рівностей виду:
L 1   = R 1,
(SEQ (\ * ARABIC 1). ... ... ... ..
L n = R n.
де L i і R i, i = 1, ..., n, деякі вирази, що містять зумовлені операції, константи, змінні, від яких залежать визначаються функції (формальні параметри цих функцій), і входження самих цих функцій. Семантика визначених функцій витягується в результаті інтерпретації цієї системи рівностей. Ця інтерпретація може здійснюватися по-різному (базуватися на різних системах правил), що породжує різні семантики. В даний час активно досліджуються операційна, денотаціонная і аксіоматична семантики.
Третій підхід, логічний, базується на використанні предикатів - функцій, аргументами яких можуть бути значення різних типів, а результатами яких є логічні значення (ІСТИНА і НЕПРАВДА). У цьому випадку набір функцій може визначатися за допомогою системи предикатів. Зауважимо, що система рівностей алгебраїчного підходу може бути задана за допомогою наступної системи предикатів:
ОДНО (L 1, R 1),
(SEQ (\ * ARABIC 2) ... ... ... ... ... ....
ОДНО (L n, R n),
де предикат ОДНО правдивий, якщо рівні значення першого і другого його аргументів. Це говорить про те, що логічний підхід має більші можливості для визначення функцій, проте він вимагає від розробників ПС вміння користуватися методами математичної логіки, що, на жаль, не для всіх колективів розробників виявляється прийнятним. Більш докладно це підхід у нашому курсі лекцій ми розглядати не будемо.
Графічний підхід також відомий ще з середньої школи. Але в даному випадку мова йде не про завдання функції за допомогою графіка, хоча при даному рівні розвитку комп'ютерної техніки введення в комп'ютер таких графіків можливий і вони могли б використовуватися (з відносно низькою точністю) для завдання функцій. У даному випадку мова йде про графічному завданні різних схем, що виражають складну функцію через інші функції, пов'язаними з будь-якими компонентами заданої схеми. Графічна схема може визначати ситуації, коли для обчислення представляється нею функції повинні застосовуватися пов'язані з цією схемою більш прості функції. Графічна схема може досить точно і формалізовано визначати частина семантики функції. Прикладом такої схеми може бути схема переходів станів кінцевого автомата, така, що в кожному з цих станів повинна виконуватися деяка додаткова функція, зазначена у схемі.

2. Метод таблиць рішень

Метод таблиць рішень базується на використанні таблиць наступного виду (див. REF _Ref53601942 \ h \ * MERGEFORMAT Табл. 1 ).
Верхня частина цієї таблиці визначає різні ситуації, в яких потрібно виконувати деякі дії (операції). Кожний рядок цієї частини задає ряд значень деякої зазначеної змінної або деякого вказаної умови в першому полі (стовпці) цього рядка. Таким чином, перший стовпець цій частині являє собою список змінних або умов, від значень яких залежить вибір визначених ситуацій. У кожному наступному стовпці вказується комбінація значень цих змінних (умов), що визначає конкретну ситуацію. При цьому останній стовпець визначає ситуацію, відмінну від попередніх, тобто для будь-яких інших комбінацій значень (будемо позначати їх зірочкою *), відмінних від перших, визначається одна і та ж, (m +1)-ий, ситуація. Втім, у деяких таблицях рішень цей стовпець може бути відсутнім. Ця частина таблиці рішень аналогічна відповідній частині таблиці, визначальною яку-небудь функцію звичайним способом - в ній задаються комбінації значень аргументів функції, яким ставиться у відповідність значення цієї функції.

Табл. SEQ Табл. \ * ARABIC 1. Загальна схема таблиць рішень
Змінні / умови
Ситуації (комбінації значень)
x 1
a 1,1
a 1,2
...
a 1, m
*
x 2
a 2,1
a 2,2
...
a 2, m
*
. ... ..
. ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ....
x n
a n, 1
a n, 2
...
a n, m
*
S 1
u 1,1
u 1,2
...
u 1, m
u 1, m +1
S 2
u 2,1
u 2,2
...
u 2, m
u 1, m +1
. ... ..
. ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
s 1k
u k, 1
u k, 2
...
u k, m
u k, m +1
Дії
Комбінації виконуваних дій
Нижня частина таблиці рішень визначає дії, які потрібно виконати в тій чи іншій ситуації, яка визначається у верхній частині таблиці рішень. Вона також складається з декількох (k) рядків, кожна з яких пов'язана з яким-небудь одним конкретним дією, зазначеним у першому полі (стовпці) цього рядка. В інших полях (стовпцях) цього рядка (тобто, для u ij, i = 1, ..., m +1, j = 1, ..., k) вказується, чи слід (u i, j = '+') виконувати цю дію в цій ситуації чи не слід (u i, j ='-'). Таким чином, перший стовпець нижній частині цієї таблиці представляє собою список позначень дій, які можуть виконуватися в тій чи іншій ситуації, обумовленої цією таблицею. У кожному наступному стовпці цій частині вказується комбінація дій, які слід виконати в ситуації, яка визначається в тому ж стовпці верхній частині таблиці рішень. Для ряду таблиць рішень ці дії можуть виконуватися в довільному порядку, але для деяких таблиць рішень цей порядок може бути зумовлений, наприклад, в порядку проходження відповідних рядків в нижній частині цієї таблиці.
Табл. SEQ Табл. \ * ARABIC 2. Таблиця рішень «Світлофор у пішохідної доріжки».
Умови
Ситуації
Стан світлофора








T = T кр
Ні
Ні
Так
*
*
*
*
*
T = T жел
*
*
*
Ні
Так
*
*
*
T> T зел
*
*
*
*
*
Ні
Так
Так
Поява привілейованої машини
Ні
Так
*
*
*
*
Ні
Так
Включити 
-
-
-
-
-
-
+
-
Включити 
-
+
+
-
-
-
-
-
Включити 
-
-
-
-
+
-
-
-
T: = 0
-
+
+
-
+
-
+
-
T: = T +1
+
-
-
+
-
+
-
+
Звільнення пішохідної доріжки
-
-
-
+
-
-
-
-
Пропуск пішоходів
+
+
+
-
-
-
-
-
Пропуск машин
-
-
-
-
-
+
+
+
Дії
Комбінації виконуваних дій
Розглянемо як приклад опис роботи світлофора у пішохідної доріжки. Переключення світлофора в нормальних ситуаціях повинно здійснюватися через фіксовану для кожного кольору число одиниць часу (T кр - для червоного кольору, T жел - для жовтого, T зел - для зеленого). У світлофора є лічильник таких одиниць. При перемиканні світлофора в лічильнику встановлюється 0. Робота світлофора ускладнюється необхідністю пропускати привілейовані машини (про їх появу на світлофор надходить спеціальний сигнал) з мінімальною затримкою, але при забезпеченні безпеки пішоходів. Наведена на REF _Ref53605526 \ h \ * MERGEFORMAT Табл. 2 таблиця рішень описує роботу такого світлофора і порядок руху у нього в кожну одиницю часу. Зірочка (*) в цій таблиці означає довільне значення відповідної умови.

3. Операційна семантика

В операційній семантиці алгебраїчного підходу до опису семантики функцій розглядається наступний окремий випадок системи рівностей REF _Ref53602543 \ h \ * MERGEFORMAT (1 ):
f 1 (x 1, x 2, ..., x k) = E 1,
f 2 (x 1, x 2, ..., x k) = E 2,
(SEQ (\ * ARABIC 3) ......... ... ... ... ... ...
f n (x 1, x 2, ..., x k) = E n,
де в лівих частинах рівностей явно вказані визначаються функції з формальними параметрами, що включають (для простоти) позначення всіх вхідних даних x 1, x 2, ..., x k, а праві частини являють собою вирази, які містять, взагалі кажучи, входження цих функцій з аргументами, що задаються деякими висловлюваннями, залежними від вхідних даних x 1, x 2, ..., x k.
Операційна семантика інтерпретує ці рівності як систему підстановок. Під підстановкою
| S E | | T
вираження (терма) T у ​​вираз E замість символу s (зокрема, змінної) будемо розуміти переписування вираження E з заміною кожного входження в нього символу s на вираження T. Кожне рівностей
f i (x 1, x 2, ..., x k) = E i
задає в параметричній формі безліч правил підстановок виду
| X 1, x 2, ..., x k f i (T 1, T 2, ..., T k) -> E i | | T 1, T 2, ..., T k
де T 1, T 2, ..., T K - конкретні аргументи (значення або визначають їх вираження) даної функції. Це правило допускає заміну входження лівій його частини в який-небудь вираз на його праву частину.
Інтерпретація системи рівностей REF _Ref53606174 \ h \ * MERGEFORMAT (3 ) Для отримання значень визначених функцій у рамках операційної семантики проводиться таким чином. Нехай заданий набір вхідних даних (аргументів) d 1, d 2, ..., d k. На першому кроці здійснюється підстановка цих даних в ліві і праві частини рівностей з виконанням там, де це можливо, зумовлених операцій і з виписуванням одержуваних в результаті цього рівностей. На кожному наступному кроці проглядаються праві частини отриманих рівностей. Якщо права частина є яким-небудь значенням, то воно і є значенням функції, зазначеної в лівій частині цієї рівності. В іншому випадку права частина є виразом, що містить входження будь-яких обумовлених функцій з тими чи іншими наборами аргументів. Якщо для такого входження відповідна функція з даними набором аргументів є в лівій частині будь-якого з отриманих рівностей, то або замість цього входження підставляється значення правої частини цієї рівності, якщо воно вже обчислено, з виконанням, де це можливо, зумовлених операцій. Або не було здійснено жодних змін, якщо значення цієї правої частини ще не обчислено. У тому ж випадку, якщо ця функція з даними набором аргументів не є лівою частиною ніякого з отриманих рівностей, то формується (і дописується до наявних) нове рівність. Воно виходить з вихідного рівності для даної функції з підстановкою в нього замість параметрів зазначених аргументів цієї функції. Ці кроки здійснюються до тих пір, поки всі обумовлені функції не будуть мати обчислені значення.
Як приклад операційної семантики розглянемо визначення функції факторіалу F (n) = n! Вона визначається такою системою рівностей:
F (0) = 1, F (n) = F (n-1) Чn.
Для обчислення значення F (3) здійснюються наступні кроки:

1-й крок:
F (0) = 1,
F (3) = F (2) Ч3.
2-й крок:
F (0) = 1,
F (3) = F (2) Ч3,
F (2) = F (1) Ч2.
3-й крок:
F (0) = 1,
F (3) = F (2) Ч3,
F (2) = F (1) Ч2,
F (1) = F (0) Ч1.
4-й крок:
F (0) = 1,
F (3) = F (2) Ч3,
F (2) = F (1) Ч2,
F (1) = 1.
5-й крок:
F (0) = 1,
F (3) = F (2) Ч3,
F (2) = 2,
F (1) = 1.
6-й крок:
F (0) = 1,
F (3) = 3,
F (2) = 2,
F (1) = 1.

Значення F (3) на 6-му кроці отримано.

4. Денотаціонная семантика

У денотаціонной семантиці алгебраїчного підходу розглядається також система рівностей виду REF _Ref53606174 \ h \ * MERGEFORMAT (3 ), Яка інтерпретується як система функціональних рівнянь, а визначаються функції є деяким рішенням цієї системи. У класичній математиці вивчення функціональних рівнянь (зокрема, інтегральних рівнянь) приділяється велика увага і пов'язане з побудовою достатньо глибокого математичного апарату. Стосовно до програмування цими питаннями серйозно займався Д. Скотт [REF _Ref53606730 \ r \ h \ * MERGEFORMAT 3 ].
Основні ідеї денотаціонной семантики проілюструємо на простішому випадку, коли система рівностей (5.3) є системою мовних рівнянь:
X 1 = φ 1,1  φ 1,2  ...  φ 1, k 1,
X 2 = φ 2,1  φ 2,2  ...  φ 2, k 2,
(SEQ (\ * ARABIC 4) ..... ... ... ... ... ... ... ... ... ... ...
X n = φ n, 1  φ n, 2  ...  φ n, kn,
причому i-е рівняння при k i = 0 має вигляд
X i = 
Як відомо, формальна мова - це безліч ланцюжків у деякому алфавіті. Таку систему можна розглядати як одну з інтерпретацій набору правил деякої граматики, представлену у формі Бекуса-Наура (кожне з наведених рівнянь є аналогом деякої такої формули). Нехай фіксований деякий алфавіт A = {a 1, a 2, ..., a m} термінальних символів граматики, з яких будуються ланцюжки, що утворюють використовуються в системі REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Мови. Символи X 1, X 2, ..., X n є метапеременнимі граматики, тут будуть розглядатися як змінні, значеннями яких є мови (множини значень цих метапеременних). Символи φ i, j, i = 1, ..., n, j = 1, ..., k j, позначають ланцюжка в об'єднаному алфавіті термінальних символів і метапеременних:
φ i, j  (A | {X 1, X 2, ..., X n}) *.
Ланцюжок φ i, j розглядається як деякий вираз, що визначає значення, що є мовою (безліччю ланцюжків в алфавіті A). Такий вираз визначається наступним чином. Якщо значення X 1, X 2, ..., X n задані, то ланцюжок
φ = Z 1 Z 2 ... Z k, Zi    (A | {X 1, X 2, ..., X n}),
позначає зчеплення множин Z 1 Z 2 ... Z k, причому входження в цей ланцюжок символу a j представляє безліч з одного елемента {a j}. Це означає, що φ визначає безліч ланцюжків
{P 1 p 2 ... p k | p j    Z j, j = 1, ..., k},
причому ланцюжок
p 1, p 2, ..., p k
являє собою послідовність виписаних один за одним ланцюжків p 1, p 2, ..., p k. Таким чином, кожна права частина рівнянь системи REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Являє собою об'єднання множин ланцюжків.
Рішенням системи REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Є набір значень (мов)
L 1, L 2, ..., L n
змінних X 1, X 2, ..., X n, для яких всі рівняння системи REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Перетворюються на тотожність.
Розглянемо як приклад окремий випадок системи REF _Ref53610892 \ h \ * MERGEFORMAT (4 ), Що складається з одного рівняння
X = a X  b X  c
з алфавітом A = {a, b, c}. Рішенням цього рівняння є мова
L = {φ c | φ    {a, b} *}.
Система REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Може мати кілька рішень. Так у розглянутому прикладі крім L рішеннями є також
L 1 = L  {φ a | φ    {a, b} *}
і
L 2 = L  {φ b | φ    {a, b} *}.
Відповідно до денотаціонной семантикою в якості визначається рішення системи REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Приймається найменше. Рішення (L 1, L 2, ..., L n) системи REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Називається найменшим, якщо для будь-якого іншого рішення (L '1, L' 2, ..., L 'n) виконується
L 1  L '1, L 2  L' 2, ..., L n  L 'n.
Так у розглянутому прикладі найменшим (а значить, визначеним денотаціонной семантикою) є рішення L.
В якості методу рішення систем рівнянь REF _Ref53606174 \ h \ * MERGEFORMAT (3 ) І REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Можна використовувати метод послідовних наближень. Сутність цього методу для системи REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Полягає в наступному. Позначимо праві частини рівнянь системи REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Операторами T i (X 1, X 2, ..., X n). Тоді система REF _Ref53610892 \ h \ * MERGEFORMAT (4 ) Набуде вигляду
X 1   = T 1 (X 1, X 2, ..., X n),
X 2   = T 2 (X 1, X 2, ..., X n),
(SEQ (\ * ARABIC 5) ... ... ... ... ... ... ... ... ...
X n   = T n (X 1, X 2, ..., X n).
В якості початкового наближення розв'язку цієї системи приймемо набір мов (L 1 [0], ..., L n [0]) = (, , ..., ). Кожне наступне наближення визначається за формулою:
(L 1 [0], ..., L n [0]) = (T 1 (L 1 [i-1], ..., L n [i-1]), ... ... ... ... ... .. (T n (L 1 [i-1], ..., L n [i-1])).
Оскільки операції об'єднання та зчеплення множин є монотонними функціями щодо відношення порядку Н, то цей процес сходиться до вирішення (L 1, ..., L n) системи REF _Ref53611617 \ h \ * MERGEFORMAT (5 ), Тобто
(L 1, ..., L n) = (T 1 (L 1, ..., L n), ..., T n (L 1, ..., L n))
і це рішення є найменшим. Це рішення називають ще найменшою нерухомою точкою системи операторів
T 1, T 2, ..., T n.
У розглянутому прикладі цей процес дає наступну послідовність наближень:
L [0] = , L [1] = {c}, L [2] = {c, ac, bc},
L [3] = {c, ac, bc, aac, abc, bac, bbc},
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
Цей процес сходиться до зазначеного вище найменшому рішенням L.

5. Аксіоматична семантика

У аксіоматичної семантиці алгебраїчного підходу система REF _Ref53611617 \ h \ * MERGEFORMAT (5 ) Інтерпретується як набір аксіом у рамках деякої формальної логічної системи, в якій є правила виводу і / або інтерпретації визначених об'єктів.
Для інтерпретації системи REF _Ref53602543 \ h \ * MERGEFORMAT (1 ) Вводиться поняття аксіоматичного опису (S, E) - логічно пов'язаної пари понять: S - сигнатура використовуються в системі REF _Ref53602543 \ h \ * MERGEFORMAT (1 ) Символів функцій f 1, f 2, ..., f m і символів констант (нульместних функціональних символів) c 1, c 2, ..., c m, а E - набір аксіом, як система REF _Ref53602543 \ h \ * MERGEFORMAT (1 ). Передбачається, що кожна змінна x i, i = 1, ..., k, і кожна константа c j, j = 1, ..., l, використовувана в E, належить до якого-небудь з типів даних t 1, t 2, ..., t r, а кожен символ f i, i = 1, ..., m, представляє функцію, типу
t i 1 * t i 2 * ... * T ik → t i 0.
Таке аксіоматичне опис отримає конкретну інтерпретацію, якщо будуть задані конкретні типи даних t i = t 'i, i = 1, ..., r, і конкретні значення констант c i = c' i, i = 1, ..., l . У такому випадку говорять, що задана одна конкретна інтерпретація A символів сигнатури S, звана алгебраїчною системою
A = (t '1, ..., t' r, f '1, ..., f' r, з '1, ..., з' r),
де f 'i, i = 1, ..., m, конкретна функція, що представляє символ f i. Таким чином, аксіоматичне опис (S, E) визначає клас алгебраїчних систем (окреме питання: одну алгебраїчну систему), що задовольняють системі аксіом E, тобто перетворюють рівності системи E в тотожності після підстановки в них f 'i, i = 1, ..., m, і c i = c' i, i = 1, ..., l, замість f i і c i відповідно.
У програмуванні як алгебраїчної системи можна розглядати, наприклад, тип даних, при цьому визначаються функції становлять операції, що застосовуються до даних цього типу. Так До Хоор побудував аксіоматичне визначення набору типів даних [REF _Ref53612810 \ r \ h \ * MERGEFORMAT 4 ], Які потім Н. Вірт використовував при створенні мови Паскаль.
В якості прикладу розглянемо систему рівностей:
ВИДАЛИТИ (ДОДАТИ (m, d)) = m,
ВЕРХ (ДОДАТИ (m, d)) = d,
ВИДАЛИТИ (нехай) = Порожній,
ВЕРХ (нехай) = ДНО,
де ВИДАЛИТИ, ДОДАТИ, ВЕРХ - символи функцій, а хай і ДНО - символи констант, що утворюють сигнатуру цієї системи. Нехай D, D 1 і М - деякі типи даних, такі, що m    M, d    D, ХАЙ    M, ДНО    D 1, а функціональні символи представляють функції наступних типів:
ВИДАЛИТИ: M → M,
ДОДАТИ: M * D → M,
ВЕРХ: M → D1.
Дана сигнатура разом із зазначеною системою рівностей, що розглядається як набір аксіом, утворює деякий аксіоматичне опис.
З допомогою цього аксіоматичного опису визначимо абстрактний тип даних, званий магазином, задавши наступну інтерпретацію символів її сигнатури: нехай D - безліч значень, які можуть бути елементами магазину, D 1 = D | {ДНО}, а M - множина станів магазину,
M = {d 1, d 2, ..., d n | d ni    D, i = 1, ..., n, n i 0},
НЕХАЙ = {}, ДНО - особливе значення (залежне від реалізації магазину), що не належить D. Тоді вказаний набір аксіом визначають властивості магазину.
З аксіоматичної семантикою пов'язана логіка рівностей (екваціональная логіка), яка вивчається в курсі "Математична логіка». Ця логіка містить правила виводу із заданого набору аксіом інших формул (рівностей).

6. Аксіоматична семантика

Як вже зазначалося, функціональна специфікація являє собою математично точне, але, як правило, не формальний опис поведінки ПС. Однак, формалізоване представлення функціональної специфікації має ряд переваг, головним з яких є можливість використовувати деякі види автоматизованого контролю функціональної специфікації.
Під мовою специфікацій розуміється формальний мова, призначена для специфікації функцій. У ньому використовується ряд засобів, що дозволяють фіксувати синтаксис і виражати семантику описуваних функцій. Різниця між мовами програмування і мовами специфікації може бути вельми умовним: якщо мова специфікацій має реалізацію на комп'ютері, що дозволяє як-то виконувати представлені на ньому специфікації (наприклад, за допомогою інтерпретатора), то така мова є і мовою програмування, може бути, і не дозволяє створювати досить ефективні програми. Однак, для мови специфікацій важливо не ефективність виконання специфікації (програми) на комп'ютері, а її виразність. Мова специфікації, що не є мовою програмування, може бути, тим не менш, корисний у процесі розробки ПС (для автоматизації контролю, тестування тощо).
Мова специфікації може базуватися на якому-небудь з розглянутих нами методів опису семантики функцій, а також підтримувати специфікацію функцій для будь-якої конкретної предметної області.

ЛІТЕРАТУРА

43. В.Н. Агафонов. Специфікація програм: понятійні кошти та їх організація. - К.: Наука (Сибірське відділення), 1987. - C. 30-73.
44. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992.
45. Д. Скотт. Теорія решіток, типи даних і семантика. / / Дані в мовах програмування. - М.: Світ, 1982. - C. 25-53.
46. К. Хоор. Про структурної організації даних / / У. Дал, Е. Дейкстра, К. Хоор. Структурне програмування. - М.: Світ, 1975. - C. 98-197.

ЗАМОК ДРАКОНА

Розділяй і володарюй!
Латинський вислів

Лекція 6.

АРХІТЕКТУРА ПРОГРАМНОГО ЗАСОБУ

Поняття архітектури і завдання її опису. Основні класи архітектур програмних засобів. Взаємодія між підсистемами та архітектурні функції. Контроль архітектури програмних засобів.

1. Поняття архітектури програмного засобу

Архітектура ПС - це його будова як воно видно (або повинно бути видно) ззовні його, тобто подання ПС як системи, що складається з деякої сукупності взаємодіючих підсистем. В якості таких підсистем виступають звичайно окремі програми. Розробка архітектури є першим етапом боротьби зі складністю ПС, на якому реалізується принцип виділення відносно незалежних компонент.
Основні завдання розробки архітектури ПС:
· Виділення програмних підсистем і відображення на них зовнішніх функцій (заданих в зовнішньому описі) ПС;
· Визначення способів взаємодії між виділеними програмними підсистемами.

2. Основні класи архітектур програмних засобів

Розрізняють такі основні класи архітектур програмних засобів [REF _Ref53665597 \ r \ h \ * MERGEFORMAT 1 ]:
· Цільна програма;
· Комплекс автономно виконуваних програм;
· Шарувата програмна система;
· Колектив паралельно виконуваних програм.
Цілісна програма являє вироджений випадок архітектури ПС: до складу ПС входить тільки одна програма. Таку архітектуру вибирають звичайно в тому випадку, коли ПС повинно виконувати одну яку-небудь яскраво виражену функцію та її реалізація не видається занадто складною. Природно, що така архітектура не потребує будь-якого опису (крім фіксації класу архітектури), так як відображення зовнішніх функцій на цю програму тривіально, а визначати спосіб взаємодії не потрібно (в силу відсутності будь-якого зовнішнього взаємодії програми, крім як взаємодії її з користувачем, а останнє описується в документації щодо застосування ПС).
Комплекс автономно виконуваних програм складається з набору програм, такого, що:
· Будь-яка з цих програм може бути активізована (запущена) користувачем;
· При виконанні активізованою програми інші програми цього набору не можуть бути активізовані до тих пір, поки не закінчить виконання активізована програма;
· Всі програми цього набору застосуються до однієї і тієї ж інформаційної середовищі.
Таким чином, програми цього набору з управління ніяк не взаємодіють - взаємодія між ними здійснюється тільки через загальну інформаційну середу.
Шарувата програмна система складається з деякої впорядкованої сукупності програмних підсистем, званих шарами, такий, що:
· На кожному шарі нічого не відомо про властивості (і навіть існування) подальших (вищих) шарів;
· Кожен шар може взаємодіяти з управління (звертатися до компонентів) з безпосередньо попереднім (більш низьким) шаром через заздалегідь певний інтерфейс, нічого не знаючи про внутрішню будову всіх попередніх шарів;
· Кожен шар має в своєму розпорядженні певні ресурси, які він або приховує від інших верств, або надає безпосередньо подальшого шару (через вказаний інтерфейс) деякі їх абстракції.
Таким чином, в шаруватої програмної системі кожен шар може реалізувати деяку абстракцію даних. Зв'язки між шарами обмежені передачею значень параметрів обертання кожного шару до суміжному знизу шару і видачею результатів цього звернення від нижнього шару верхнього. Неприпустимо використання глобальних даних декількома шарами.
КОМП'ЮТЕР
Прикладні програми
3: Управління вхідними і вихідними потоками даних
2: Забезпечення зв'язку з консоллю операора
1: Управління пам'яттю
0: Диспетчеризація і синхронізація процесів

В якості прикладу розглянемо використання такої архітектури для побудови операційної системи. Таку архітектуру застосував Дейкстра при побудові операційної системи THE [REF _Ref53665634 \ r \ h \ * MERGEFORMAT 2 ]. Ця операційна система складається з чотирьох шарів (див. REF _Ref53513384 \ h \ * MERGEFORMAT Рис. 1 ). На нульовому шарі проводиться обробка всіх переривань і виділення центрального процесора програмам (процесам) в пакетному режимі. Тільки цей рівень обізнаний про мультипрограмних аспектах системи. На першому шарі здійснюється управління сторінкової організацією пам'яті. Всім вищим верствам надається віртуальна безперервна (не сторінкова) пам'ять. На другому шарі здійснюється зв'язок з консоллю (пультом управління) оператора. Тільки цей шар знає технічні характеристики консолі. На третьому шарі здійснюється буферизація вхідних і вихідних потоків даних і реалізуються так звані абстрактні канали введення і виведення, так що прикладні програми не знають технічних характеристик пристроїв введення-виведення.
Рис. SEQ Рис. \ * ARABIC 1. Архітектура операційної системи THE.
Колектив паралельно діючих програм являє собою набір програм, здатних взаємодіяти між собою, перебуваючи одночасно в стадії виконання. Це означає, що такі програми, по-перше, викликані в оперативну пам'ять, активізовані і можуть поперемінно розділяти за часом один або кілька центральних процесорів, а по-друге, здійснювати між собою динамічні (у процесі виконання) взаємодії, на базі яких проводитиметься їх синхронізація. Звичайна взаємодія між такими процесами здійснюється шляхом передачі один одному деяких повідомлень.
Найпростішим різновидом такої архітектури є конвеєр, коштів, для організації якого є в операційній системі UNIX [REF _Ref53665651 \ r \ h \ * MERGEFORMAT 3 ]. Конвеєр представляє собою послідовність програм, в якій стандартний висновок кожної програми, крім самої останньої, пов'язаний зі стандартним введенням наступної програми цієї послідовності (див. REF _Ref53517068 \ h \ * MERGEFORMAT Рис. 2 ). Конвеєр обробляє деякий потік повідомлень. Кожне повідомлення цього потоку надходить на введення першій програмі, яка, обробивши його, передає перероблене повідомлення наступній програмі, а сама починає обробку чергового повідомлення потоку. Таким же чином діє кожна програма конвеєра: отримавши повідомлення від попередньої програми і обробивши його, вона передає перероблене повідомлення наступній програмі, а остання програма конвеєра виводить результат роботи всього конвеєра (результуюче повідомлення). Таким чином, в конвеєрі, що складається з n програм, може одночасно перебувати в обробці до n повідомлень. Звичайно, в силу того, що різні програми конвеєра можуть витратити на обробку чергових повідомлень різні відрізки часу, необхідно забезпечити будь-яким чином синхронізацію цих процесів (деякі процеси можуть перебувати в стадії очікування якої можливості передати перероблене повідомлення, або можливості отримати чергове повідомлення).
Перший програма
Потік повідомлень
Потік повідомлень
Друга програма
Потік повідомлень
n-а програма
Потік повідомлень
Потік повідомлень

Рис. SEQ Рис. \ * ARABIC 2. Конвеєр паралельно діючих програм.
Порт повідомлень є програмною підсистему, яка обслуговує певну чергу повідомлень: вона може приймати на зберігання від програми яке-небудь повідомлення, ставлячи його в чергу, і може видавати чергове повідомлення іншій програмі на її вимогу. Повідомлення, передане якою-небудь програмою деякого порту, вже не буде належати цій програмі (і використовувати її ресурси), але воно не буде належати і ніякий інший програмі, поки в порядку черги не буде передано будь-якій програмі за її запитом. Таким чином, програма, що передає повідомлення не буде перебувати в стадії очікування поки програма, що отримує це повідомлення, не буде готова його обробляти (якщо тільки не буде переповнений приймає порт).
Приклад програмної системи з портами повідомлень наведено на REF _Ref53665812 \ h \ * MERGEFORMAT Рис. 3 . Порт U може розглядатися як порт вступних повідомлень для представленого на цьому малюнку колективу паралельно діючих програм, а порт W - як порт вивідних повідомлень для цього колективу програм.
Програма A
Програма B
Програма C
... ... ... ... ... ... ...
Порт U
Повідомлення 1
Повідомлення 2
... ... ... ... ... ...
Повідомлення m
Порт W
Повідомлення 1
Повідомлення 2
... ... ... ... ... ...
Повідомлення n

Рис. SEQ Рис. \ * ARABIC 3. Приклад програмної системи з портами повідомлень.
Програмні системи з портами повідомлень можуть бути як жорсткою конфігурації, так і гнучкої конфігурації. У системах з портами жорсткої конфігурації з кожною програмою можуть бути жорстко пов'язані один або кілька вхідних портів. Для передачі повідомлення така програма повинна явно вказати адресу передачі: ім'я програми та ім'я її вхідного порту. У цьому випадку при зміні конфігурації системи доведеться коригувати використовувані програми: змінювати адреси передач повідомлень. У системах з портами гнучкої конфігурації з кожною програмою пов'язані як вхідні, так і вихідні віртуальні порти. Перед запуском такої системи повинна проводитися її попередня настройка за допомогою спеціальної програмної компоненти, що здійснює суміщення кожного вихідного віртуального порту з яких-небудь вхідним віртуальним портом на підставі інформації, що задається користувачем. Тим самим при зміні конфігурації системи в цьому випадку не потрібно якої-які коригування використовуваних програм - необхідні зміни повинні бути відображені в інформації для налаштування. Однак у цьому випадку потрібно мати спеціальну програмну компоненту, що здійснює налаштування системи.

3. Архітектурні функції

Для забезпечення взаємодії між підсистемами в ряді випадків не потрібно створювати якісь додаткові програмні компоненти (крім реалізації зовнішніх функцій) - для цього може бути досить заздалегідь фіксованих угод і стандартних можливостей базового програмного забезпечення (операційної системи). Так у комплексі автономно виконуваних програм для забезпечення взаємодії досить опису (специфікації) спільної зовнішньої інформаційного середовища і можливостей операційної системи для запуску програм. У шаруватої програмної системи може виявитися достатнім специфікації виділених програмних шарів і звичайний апарат звернення до процедур. У програмному конвеєрі взаємодія між програмами також може забезпечувати операційна система (як це має місце в операційній системі UNIX).
Проте у ряді випадків для забезпечення взаємодії між програмними підсистемами може знадобитися створення додаткових програмних компонент. Так для управління роботою комплексу автономно виконуваних програм часто створюють спеціалізований командний інтерпретатор, більш зручний в даній предметній області для підготовки необхідної зовнішньої інформаційного середовища і запуску необхідної програми, ніж базовий командний інтерпретатор використовуваної операційної системи. У шаруватих програмних системах може бути створений особливий апарат звернення до процедур шару (наприклад, забезпечує паралельне виконання цих процедур). У колективі паралельно діючих програм для управління портами повідомлень потрібна спеціальна програмна підсистема. Такі програмні компоненти ніяких зовнішніх функцій не виконують - вони реалізують функції, що виникли в результаті розробки архітектури програмного засобу. У зв'язку з цим такі функції ми будемо називати архітектурними.

4. Контроль архітектури програмних засобів

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

ЛІТЕРАТУРА

47. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980. - С. 78-91.
48. EW Dijkstra. The Structure of the THE-Multiprogramming / / Communications of the ACM. - 1968, 11 (5). - Pp. 341-346.
49. М. Крістіан. Введення в операційну систему UNIX. - М.: Фінанси і статистика, 1985. - С. 46-49.

ЗАМОК ДРАКОНА

Розділяй і володарюй!
Латинський вислів

Лекція 7.

РОЗРОБКА СТРУКТУРИ ПРОГРАМИ І МОДУЛЬНЕ ПРОГРАМУВАННЯ

Мета розробки структури програми. Поняття програмного модуля. Основні характеристики програмного модуля. Методи розробки структури програми. Специфікація програмного модуля. Контроль структури програми.

1. Мета модульного програмування

Приступаючи до розробки кожної програми ПС, слід мати на увазі, що вона, як правило, є великою системою, тому ми повинні вжити заходів для її спрощення. Для цього таку програму розробляють по частинах, які називаються програмними модулями [REF _Ref53672739 \ r \ h \ * MERGEFORMAT 1 , REF _Ref53673071 \ r \ h \ * MERGEFORMAT 2 ]. А сам такий метод розробки програм називають модульним програмуванням [REF _Ref53419906 \ r \ h \ * MERGEFORMAT 3 ]. Програмний модуль - це будь-який фрагмент опису процесу, що оформляється як самостійний програмний продукт, придатний для використання в описах процесу. Це означає, що кожен програмний модуль програмується, компілюється та налагоджували окремо від інших модулів програми, і тим самим, фізично розділений від інших модулів програми. Більше того, кожен розроблений програмний модуль може включатися до складу різних програм, якщо виконані умови його використання, декларовані в документації з цього модулю. Таким чином, програмний модуль може розглядатися і як засіб боротьби зі складністю програм, і як засіб боротьби з дублюванням в програмуванні (тобто як засіб накопичення та багаторазового використання програмістських знань).
Модульне програмування є втіленням у процесі розробки програм обох загальних методів боротьби зі складністю (див. лекцію «Замок дракона. Лекція 3 - Методи боротьби зі складністю»), і забезпечення незалежності компонент системи, і використання ієрархічних структур. Для втілення першого методу формулюються певні вимоги, яким повинен задовольняти програмний модуль, тобто виявляються основні характеристики «хорошого» програмного модуля. Для втілення другого методу використовують деревоподібні модульні структури програм (включаючи дерева із зрощеними гілками).

2. Основні характеристики програмного модуля

Не всякий програмний модуль сприяє спрощенню програми [REF _Ref53673071 \ r \ h \ * MERGEFORMAT 2 ]. Виділити гарний з цієї точки зору модуль є серйозною творчим завданням. Для оцінки прийнятності виділеного модуля використовуються деякі критерії. Так, Хольт [REF _Ref53673058 \ r \ h \ * MERGEFORMAT 4 ] Запропонував наступні два загальних таких критерію:
· Хороший модуль зовні простіше, ніж усередині;
· Хороший модуль простіше використовувати, ніж побудувати.
Майерс [REF _Ref53672757 \ r \ h \ * MERGEFORMAT 5 ] Пропонує використовувати більш конструктивні характеристики програмного модуля для оцінки його прийнятності: розмір модуля; міцність модуля; зчеплення з іншими модулями; рутинність модуля (незалежність від передісторії звернень до нього).
Розмір модуля вимірюється числом містяться в ньому операторів (рядків). Модуль не повинен бути занадто маленьким або занадто великим. Маленькі модулі призводять до громіздкої модульній структурі програми і можуть не окупати накладних витрат, пов'язаних з їх оформленням. Великі модулі незручні для вивчення і змін, вони можуть істотно збільшити сумарний час повторних трансляцій програми при налагодженні програми. Зазвичай рекомендуються програмні модулі розміром від кількох десятків до кількох сотень операторів.
Міцність модуля - це міра його внутрішніх зв'язків. Чим вище міцність модуля, тим більше зв'язків він може сховати від зовнішньої по відношенню до нього частини програми і, отже, тим більший внесок у спрощення програми він може внести. Для оцінки ступеня міцності модуля Майерс [REF _Ref53672757 \ r \ h \ * MERGEFORMAT 5 ] Пропонує впорядкований за ступенем міцності набір з семи класів модулів. Найслабкішою ступенем міцності має модуль, міцний по збігу. Це такий модуль, між елементами якого немає осмислених зв'язків. Такий модуль може бути виділений, наприклад, при виявленні в різних місцях програми повторення однієї і тієї ж послідовності операторів, яка і оформляється в окремий модуль. Необхідність зміни цієї послідовності в одному з контекстів може призвести до зміни цього модуля, що може зробити його використання в інших контекстах помилковим. Такий клас програмних модулів не рекомендується для використання. Взагалі кажучи, запропонована Майерсом впорядкованість за ступенем міцності класів модулів не безперечна. Однак, це не дуже суттєво, тому що тільки два вищих за міцністю класу модулів рекомендуються для використання. Ці класи ми і розглянемо докладніше.
Функціонально міцний модуль - це модуль, що виконує (реалізує) одну яку-небудь певну функцію. При реалізації цієї функції такий модуль може використовувати і інші модулі. Такий клас програмних модулів рекомендується для використання.
Інформаційно міцний модуль - це модуль, що виконує (реалізує) кілька операцій (функцій) над однією і тією ж структурою даних (інформаційним об'єктом), яка вважається невідомою поза цього модуля. Для кожної з цих операцій в такому модулі є свій вхід зі своєю формою звертання до нього. Такий клас слід розглядати як клас програмних модулів з вищим ступенем міцності. Інформаційно-міцний модуль може реалізовувати, наприклад, абстрактний тип даних.
У модульних мовами програмування як мінімум є засоби для завдання функціонально міцних модулів (наприклад, модуль типу FUNCTION в мові ФОРТРАН). Кошти ж для завдання інформаційно міцних модулів в ранніх мовами програмування відсутні - вони з'явилися тільки в більш пізніх мовами. Так було в мові програмування Ада засобом завдання інформаційно міцного модуля є пакет [REF _Ref53672950 \ r \ h \ * MERGEFORMAT 6 ].
Зчеплення модуля - це міра його залежності за даними від інших модулів. Характеризується способом передачі даних. Чим менше зчеплення модуля з іншими модулями, тим сильніше його незалежність від інших модулів. Для оцінки ступеня зчеплення Майерс пропонує [REF _Ref53672757 \ r \ h \ * MERGEFORMAT 5 ] Упорядкований набір з шести видів зчеплення модулів. Найгіршим видом зчеплення модулів є зчеплення за вмістом. Таким є зчеплення двох модулів, коли один з них має прямі посилання на вміст іншого модуля (наприклад, на константу, що міститься в іншому модулі). Таке зчеплення модулів неприпустимо. Не рекомендується використовувати також зчеплення з загальної області - це таке зчеплення модулів, коли кілька модулів використовують одну і ту ж область пам'яті. Такий вид зчеплення модулів реалізується, наприклад, при програмуванні на мові ФОРТРАН з використанням блоків COMMON. Єдиним видом зчеплення модулів, який рекомендується для використання сучасною технологією програмування, є параметричне зчеплення (зчеплення за даними по Майерсу [REF _Ref53672757 \ r \ h \ * MERGEFORMAT 5 ]) - Це випадок, коли дані передаються модулю або при зверненні до нього як значення його параметрів, або як результат його звернення до іншого модулю для обчислення деякої функції. Такий вид зчеплення модулів реалізується на мовах програмування при використанні звернень до процедур (функцій).
Рутинність модуля - це його незалежність від передісторії звернень до нього. Модуль будемо називати рутинним, якщо результат (ефект) звернення до нього залежить тільки від значень його параметрів (і не залежить від передісторії звернень до нього). Модуль будемо називати залежать від передісторії, якщо результат (ефект) звернення до нього залежить від внутрішнього стану цього модуля, що зберігає сліди попередніх звернень до нього. Майерс [REF _Ref53672757 \ r \ h \ * MERGEFORMAT 5 ] Не рекомендує використовувати залежать від передісторії (непередбачувані) модулі, так як вони провокують появу в програмах хитрих (невловимих) помилок. Однак така рекомендація є неконструктивною, оскільки в багатьох випадках саме залежить від передісторії модуль є кращою реалізацій інформаційно міцного модуля. Тому більш прийнятна наступна (більш обережна) рекомендація:
· Завжди слід використовувати рутинний модуль, якщо це не призводить до поганих (не рекомендованим) зчепленням модулів;
· Залежать від передісторії модулі варто використовувати тільки у випадку, коли це необхідно для забезпечення параметричного зчеплення;
· У специфікації залежить від передісторії модуля повинна бути чітко сформульована ця залежність таким чином, щоб було можливо прогнозувати поведінку (ефект виконання) даного модуля при різних наступних зверненнях до нього.
У зв'язку з останньою рекомендацією може бути корисним визначення зовнішнього подання (орієнтованого на інформування людини) станів залежить від передісторії модуля. У цьому випадку ефект виконання кожної функції (операції), що реалізується цим модулем, слід описувати в термінах цього зовнішнього представлення, що істотно спростить прогнозування поведінки даного модуля.

3. Методи розробки структури програми

Як вже зазначалося вище, як модульної структури програми прийнято використовувати деревоподібну структуру, включаючи дерева із зрощеними гілками. У вузлах такого дерева розміщуються програмні модулі, а спрямовані дуги (стрілки) показують статичну підпорядкованість модулів, тобто кожна дуга показує, що в тексті модуля, з якого вона виходить, є посилання на модуль, до якого вона входить. Іншими словами, кожен модуль може звертатися до підлеглих йому модулями, тобто виражається через ці модулі. При цьому модульна структура програми, в кінцевому рахунку, повинна включати і сукупність специфікацій модулів, що утворюють цю програму. Специфікація програмного модуля містить, по-перше, синтаксичну специфікацію його входів, що дозволяє побудувати на використовувану мову програмування синтаксично правильне звернення до нього (до будь-якого його входу), і, по-друге, функціональну специфікацію модуля (опис семантики функцій, виконуваних цим модулем по кожному з його входів). Функціональна специфікація модуля будується так само, як і функціональна специфікація ПС.
У процесі розробки програми її модульна структура може по-різному формуватися і використовуватися для визначення порядку програмування і налагодження модулів, зазначених у цій структурі. Тому можна говорити про різні методи розробки структури програми. Зазвичай в літературі обговорюються два методи [REF _Ref53672739 \ r \ h \ * MERGEFORMAT 1 , REF _Ref53591861 \ r \ h \ * MERGEFORMAT 7 ]: Метод висхідній розробки і метод низхідній розробки.
Метод висхідній розробки полягає в наступному. Спочатку будується модульна структура програми у вигляді дерева. Потім по черзі програмуються модулі програми, починаючи з модулів самого нижнього рівня (листя дерева модульної структури програми), в такому порядку, щоб для кожного програмованого модуля були вже запрограмовані всі модулі, до яких він може звертатися. Після того, як всі модулі програми запрограмовані, проводиться їх почергове тестування і налагодження в принципі в такому ж (висхідному) порядку, в якому велося їх програмування. На перший погляд такий порядок розробки програми здається цілком природним: кожен модуль при програмуванні виражається через вже запрограмовані безпосередньо підпорядковані модулі, а при тестуванні використовує вже налагоджені модулі. Однак, сучасна технологія не рекомендує такий порядок розробки програми. По-перше, для програмування будь-якого модуля зовсім не потрібно текстів використовуваних ним модулів - для цього достатньо, щоб кожен використовуваний модуль був лише специфікований (в обсязі, що дозволяє побудувати правильне звернення до нього), а для тестування його можливо (і навіть, як ми покажемо нижче, корисно) використовувані модулі замінювати їх імітаторами (заглушками). По-друге, кожна програма в якійсь мірі підпорядковується деяким внутрішнім для неї, але глобальним для її модулів міркувань (принципам реалізації, припущенням, структурам даних тощо), що визначає її концептуальну цілісність і формується в процесі її розробки. При висхідній розробці ця глобальна інформація для модулів нижніх рівнів ще не ясна в повному обсязі, тому дуже часто доводиться їх перепрограмувати, коли при програмуванні інших модулів проводиться істотне уточнення цієї глобальної інформації (наприклад, змінюється глобальна структура даних). По-третє, при висхідному тестуванні для кожного модуля (крім головного) доводиться створювати провідну програму (модуль), яка повинна підготувати для модуля, що тестується необхідний стан інформаційного середовища і провести необхідну звернення до нього. Це призводить до великого обсягу «отладочного» програмування і в той же час не дає ніякої гарантії, що тестування модулів вироблялося саме в тих умовах, в яких вони будуть виконуватися в робочій програмі.
Метод низхідній розробки полягає в наступному. Як і в попередньому методі спочатку будується модульна структура програми у вигляді дерева. Потім по черзі програмуються модулі програми, починаючи з модуля самого верхнього рівня (головного), переходячи до програмування будь-якого іншого модуля тільки в тому випадку, якщо вже запрограмований модуль, який до нього звертається. Після того, як всі модулі програми запрограмовані, проводиться їх почергове тестування і налагодження в такому ж (низхідному) порядку. При такому порядку розробки програми вся необхідна глобальна інформація формується своєчасно, тобто ліквідується вельми неприємний джерело прорахунків при програмуванні модулів. Істотно полегшується і тестування модулів, вироблене при низхідному тестуванні програми. Першим тестується головний модуль програми, який представляє всю тестовану програму і тому тестується при «природному» стані інформаційного середовища, при якому починає виконуватися ця програма. При цьому всі модулі, до яких може звертатися головний модуль, замінюються їх імітаторами (так звані заглушки [REF _Ref53672757 \ r \ h \ * MERGEFORMAT 5 ]). Кожен імітатор модуля представляється досить простим програмним фрагментом, що сигналізує, в основному, про сам факт звернення до імітованої модулю з необхідною для правильної роботи програми обробкою значень його вхідних параметрів (іноді з їх роздруківкою) і з видачею, якщо це необхідно, заздалегідь запасеного відповідного результату . Після завершення тестування і налагодження головного і будь-якого подальшого модуля проводиться перехід до тестування одного з модулів, які в даний момент представлені імітаторами, якщо такі є. Для цього імітатор обраного для тестування модуля замінюється на сам цей модуль і додаються імітатори тих модулів, до яких може звертатися обраний для тестування модуль. При цьому кожен такий модуль буде тестуватися при «природних» станах інформаційного середовища, що виникають до моменту звернення до цього модуля при виконанні програми, що тестується. Таким чином, великий обсяг «отладочного» програмування замінюється програмуванням досить простих імітаторів використовуються у програмі модулів. Крім того, імітатори зручно використовувати для підігрування процесу підбору тестів шляхом завдання потрібних результатів, що видаються імітаторами.
Деяким недоліком низхідній розробки, що призводить до певних ускладнень при її застосуванні, є необхідність абстрагуватися від базових можливостей використовуваної мови програмування, вигадуючи абстрактні операції, які пізніше потрібно буде реалізувати за допомогою виділених у програмі модулів. Проте здатність до таких абстракцій представляється необхідною умовою розробки великих програмних засобів, тому її потрібно розвивати.
У розглянутих методах висхідній і низхідній розробок (які ми будемо називати класичними) модульна деревоподібна структура програми повинна розроблятися до початку програмування модулів. Однак такий підхід викликає ряд заперечень: представляється сумнівним, щоб до програмування модулів можна було розробити структуру програми досить точно і змістовно. Насправді цього робити не обов'язково. Наприклад, модульна структура при конструктивному і архітектурному підходах до розробки програм [REF _Ref53591861 \ r \ h \ * MERGEFORMAT 7 ] Формується в процесі програмування модулів.
Конструктивний підхід до розробки програми представляє собою модифікацію низхідній розробки, при якій модульна деревоподібна структура програми формується в процесі програмування модуля. Спочатку програмується головний модуль, виходячи з специфікації програми в цілому, причому специфікація програми є одночасно і специфікацією її головного модуля, так як останній повністю бере на себе відповідальність за виконання функцій програми. У процесі програмування головного модуля, у разі, якщо ця програма досить велика, виділяються підзадачі (внутрішні функції), в термінах яких програмується головний модуль. Це означає, що для кожної виділеної підзадачі (функції) створюється специфікація реалізує її фрагмента програми, який в подальшому може бути представлений деяким піддерево модулів. Важливо зауважити, що тут також відповідальність за виконання виділеної функції бере головний (може бути, і єдиний) модуль цього піддерева, так що специфікація виділеної функції є одночасно і специфікацією головного модуля цього піддерева. У головному модулі програми для звернення до виділеної функції будується звернення до головного модулю зазначеного піддереві відповідно до створеної його специфікацією. Таким чином, на першому кроці розробки програми (при програмуванні її головного модуля) формується верхня початкова частина дерева, наприклад, така, яка показана на рис. REF _Ref53513384 \ h \ * MERGEFORMAT Рис. 1 .
Аналогічні дії проводяться при програмуванні будь-якого іншого модуля, який вибирається з поточного стану дерева програми з числа специфікованих, але поки ще не запрограмованих модулів. У результаті цього проводиться чергове доформування дерева програми, наприклад, таке, яке показано на рис. REF _Ref53517068 \ h \ * MERGEFORMAT Рис. 2 .
Архітектурний підхід до розробки програми представляє собою модифікацію висхідній розробки, при якій модульна структура програми формується в процесі програмування модуля. Але при цьому ставиться істотно інша мета розробки: підвищення рівня використовуваної мови програмування, а не розробка конкретної програми. Це означає, що для заданої предметної області виділяються типові функції, кожна з яких може використовуватися при вирішенні різних завдань у цій області. Далі специфицируются, а потім і програмуються окремі програмні модулі, що виконують ці функції. Так як процес виділення таких функцій пов'язані з накопиченням і узагальненням досвіду вирішення завдань у заданій предметній області, то зазвичай спочатку виділяються і реалізуються окремими модулями більш прості функції, а потім поступово з'являються модулі, що використовують раніше виділені функції. Такий набір модулів створюється з розрахунку на те, що при розробці тієї чи іншої програми заданої предметної області в рамках конструктивного підходу можуть виявитися прийнятними деякі з цих модулів. Це дозволяє істотно скоротити трудомісткість на розробку конкретної програми шляхом підключення до неї заздалегідь заготовлених і перевірених на практиці модульних структур нижнього рівня. Так як такі структури можуть багаторазово використовуватися в різних конкретних програмах, то архітектурний підхід може розглядатися як шлях боротьби з дублюванням в програмуванні. У зв'язку з цим програмні модулі, що створюються в рамках архітектурного підходу, звичайно параметризуються для того, щоб посилити застосування таких модулів шляхом налаштування їх на параметри.
У класичному методі низхідній розробки рекомендується спочатку всі модулі програми, що розробляється запрограмувати, а вже потім починати спадний їх тестування [REF _Ref53672757 \ r \ h \ * MERGEFORMAT 5 ]. Однак такий порядок розробки не представляється досить обгрунтованим: тестування і налагодження модулів може призвести до зміни специфікації підлеглих модулів і навіть до зміни самої модульної структури програми, так що в цьому випадку програмування деяких модулів може виявитися марно виконаною роботою. Нам видається більш раціональним інший порядок розробки програми, відомий у літературі як метод низхідній реалізації. У цьому методі кожен запрограмований модуль починають відразу ж тестувати до переходу до програмування іншого модуля.
Всі ці методи мають ще різні різновиди в залежності від того, в якій послідовності обходяться вузли (модулі) деревоподібної структури програми в процесі її розробки [REF _Ref53672739 \ r \ h \ * MERGEFORMAT 1 ]. Це можна робити, наприклад, по шарах (розробляючи всі модулі одного рівня, перш ніж переходити до наступного рівня). При низхідній розробці дерево можна обходити також в лексикографічному порядку (зверху-вниз, зліва-направо). Можливі й інші варіанти обходу дерева. Так, при конструктивній реалізації для обходу дерева програми доцільно слідувати ідеям Фуксмана, які він використовував у запропонованому ним методі вертикального шарування [REF _Ref53674007 \ r \ h \ * MERGEFORMAT 8 ]. Сутність такого обходу полягає в наступному. У рамках конструктивного підходу спочатку реалізуються тільки ті модулі, які необхідні для самого найпростішого варіанту програми, яка може нормально виконуватися тільки для дуже обмеженого безлічі наборів вхідних даних, але для таких даних ця задача буде вирішуватися до кінця. Замість інших модулів, на які в такій програмі є посилання, в цю програму вставляються лише їх імітатори, що забезпечують, в основному, контроль над виходом за межі цього окремого випадку. Потім до цієї програми додаються реалізації деяких інших модулів (зокрема, замість деяких з наявних імітаторів), що забезпечують нормальне виконання для деяких інших наборів вхідних даних. І цей процес триває поетапно до повної реалізації потрібної програми. Таким чином, обхід дерева програми проводиться з метою найкоротшим шляхом реалізувати той чи інший варіант (спочатку самий найпростіший) нормально діючої програми. У зв'язку з цим такий різновид конструктивної реалізації отримала назву методу цілеспрямованої конструктивної реалізації. Перевагою цього методу є те, що вже на досить ранній стадії створюється працюючий варіант програми. Психологічно це грає роль допінгу, різко підвищує ефективність розробника. Тому цей метод є досить привабливим.
Підводячи підсумок сказаному, на REF _Ref53665812 \ h \ * MERGEFORMAT Рис. 3 представлена ​​загальна схема класифікації розглянутих методів розробки структури програми.

4. Контроль структури програми

Для контролю структури програми можна використовувати три методи [REF _Ref53672757 \ r \ h \ * MERGEFORMAT 5 ]:
· Статичний контроль,
· Суміжний контроль,
· Наскрізний контроль.
Статичний контроль полягає в оцінці структури програми з точки зору, чи добре програма розбита на модулі з урахуванням значень розглянутих вище основних характеристик модуля.
Суміжний контроль зверху - це контроль з боку розробників архітектури і зовнішнього опису ПС. Суміжний контроль знизу - це контроль специфікації модулів з боку розробників цих модулів.
Наскрізний контроль - це уявне прокручування (перевірка) структури програми при виконанні заздалегідь розроблених тестів. Є видом динамічного контролю так само, як і ручна імітація функціональної специфікації чи архітектури ПС.
Слід зауважити, що характер здійснення цих методів контролю залежить від обраного методу розробки структури програми: при класичному підході вони застосовуються до початку програмування модулів, а при конструктивному і архітектурному підходах - в процесі програмування модулів (у відповідні моменти часу).

ЛІТЕРАТУРА

50. Дж. Хьюз, Дж. Мічтом. Структурний підхід до програмування. - М.: Світ, 1980. - С. 29-71.
51. В. Турський. Методологія програмування. - М.: Світ, 1981. - С.90-164.
52. Е.А. Жоголєв. Технологічні основи модульного програмування / / Програмування, 1980, № 2. - С.44-49.
53. RCHolt. Structure of Computer Programs: A Survey / / Proceedings of the IEEE, 1975, 63 (6). - P. 879-893.
54. Г. Майерс. Надійність програмного забезпечення. - М.: Світ, 1980. - С. 92-113.
55. Я. Пайл. АДА - мова вбудованих систем. М.: Фінанси і статистика, 1984. - С. 67-75.
56. М. Зелковец, А. Шоу, Дж. Геннон. Принципи розробки програмного забезпечення. - М.: Мир, 1982, с. 65-71.
57. А. Л. Фуксман. Технологічні аспекти створення програмних систем. М.: Статистика, 1979. - С. 79-94.

Лекція 8. РОЗРОБКА ПРОГРАМНОГО МОДУЛЯ
Порядок розробки програмного модуля. Структурне програмування і покрокова деталізація. Поняття про псевдокоде. Контроль програмного модуля.
8.1. Порядок розробки програмного модуля.
При розробці програмного модуля доцільно дотримуватись наступного порядку [8.1]:
вивчення та перевірка специфікації модуля, вибір мови
програмування;
вибір алгоритму і структури даних;
програмування модуля;
шліфування тексту модуля;
перевірка модуля;
компіляція модуля.
Перший крок розробки програмного модуля в значній мірі є суміжний контроль структури програми знизу: вивчаючи специфікацію модуля, розробник повинен переконатися, що вона йому зрозуміла і достатня для розробки цього модуля. На завершення цього кроку вибирається мова програмування: хоча мова програмування може бути вже зумовлений для всього ПС, все ж у ряді випадків (якщо система програмування це допускає) може бути вибрана інша мова, яка більше підходить для реалізації даного модуля (наприклад, мова асемблера).
На другому кроці розробки програмного модуля необхідно з'ясувати, чи не відомі чи є вже якісь алгоритми для вирішення поставленої і або близькою до неї завдання. І якщо знайдеться відповідний алгоритм, то доцільно ним скористатися. Вибір відповідних структур даних, які будуть використовуватися при виконанні модулем своїх функцій, в значній мірі зумовлює логіку та якісні показники розроблюваного модуля, тому його слід розглядати як дуже відповідальне рішення.
На третьому кроці здійснюється побудова тексту модуля на вибраній мові програмування. Велика кількість всіляких деталей, які повинні бути враховані при реалізації функцій, зазначених у специфікації модуля, легко можуть привести до створення досить заплутаного тексту, що містить масу помилок і неточностей. Шукати помилки в такому модулі та вносити до нього необхідні зміни може виявитися досить трудомістким завданням. Тому дуже важливо для побудови тексту модуля користуватися технологічно обгрунтованої та практично перевіреної дисципліною програмування. Вперше на це звернув увагу Дейкстра [8.2], сформулювавши та обгрунтувавши основні принципи структурного програмування. На цих принципах базуються багато дисципліни програмування, що широко застосовуються на практиці [8.3-8.6]. Найбільш поширеною є дисципліна покрокової деталізації [8.3], яка докладно обговорюється в розділах 8.2 і 8.3.
Наступний крок розробки модуля пов'язаний з приведенням тексту модуля в завершеному вигляді у відповідності зі специфікацією якості ПС. При програмуванні модуля розробник основну увагу приділяє правильності реалізації функцій модуля, залишаючи недопрацьованими коментарі і допускаючи деякі порушення вимог до стилю програми. При шліфуванні тексту модуля він повинен відредагувати наявні в тексті коментарі і, можливо, включити в нього додаткові коментарі з метою забезпечити необхідні примітиви якості [8.1]. З цією ж метою проводиться редагування тексту програми для виконання стилістичних вимог.
Крок перевірки модуля представляє собою ручну перевірку внутрішньої логіки модуля до початку його налагодження (що використовує виконання його на комп'ютері), реалізує загальний принцип, сформульований для обговорюваної технології програмування, про необхідність контролю прийнятих рішень на кожному етапі розробки ПС (див. лекцію 3). Методи перевірки модуля обговорюються розділі 8.4.
І, нарешті, останній крок розробки модуля означає завершення перевірки модуля (за допомогою компілятора) і перехід до процесу налагодження модуля.
8.2. Структурне програмування.
При програмуванні модуля слід мати на увазі, що програма повинна бути зрозумілою не тільки комп'ютеру, але і людині: і розробник модуля, та особи, що перевіряють модуль, і текстовики, що готують тести для налагодження модуля, і супровідники ПС, здійснюють необхідні зміни модуля, змушені будуть багаторазово розбирати логіку роботи модуля. У сучасних мовах програмування достатньо коштів, щоб заплутати цю логіку як завгодно сильно, тим самим, зробити модуль важко розуміється для людини і, як наслідок цього, зробити його ненадійним чи важко супроводжуваним. Тому необхідно вживати заходів для вибору відповідних мовних засобів і дотримуватися певної дисципліни програмування. Вперше на це звернув увагу Дейкстра [8.2] і запропонував будувати програму як композицію з декількох типів керуючих конструкцій (структур), які дозволяють сильно підвищити понимаемость логіки роботи програми. Програмування з використанням тільки таких конструкцій назвали структурним.
Основними конструкціями структурного програмування є: проходження, розгалуження і повторення (див. Рис. 8.1). Компонентами цих конструкцій є узагальнені оператори (вузли обробки [8.5]) S, S1, S2 і умова (предикат) P. В якості узагальненого оператора може бути або простий оператор використовуваної мови програмування (оператори присвоювання, введення, виведення, звернення до процедури), або фрагмент програми, що є композицією основних керуючих конструкцій структурного програмування. Істотно, що кожна з цих конструкцій має з управління тільки один вхід і один вихід. Тим самим, і узагальнений оператор має тільки один вхід і один вихід.
Дуже важливо також, що ці конструкції є вже математичними об'єктами (що, посуті, і пояснює причину успіху структурного програмування). Доведено, що для кожної неструктурованої програми можна побудувати функціонально еквівалентну (тобто вирішальну ту ж задачу) структуровану програму. Для структурованих програм можна математично доводити деякі властивості, що дозволяє виявляти в програмі деякі помилки. Цьому питанню буде присвячена окрема лекція.
Структурне програмування іноді називають ще "програмуванням без GO TO". Однак справа тут не в операторі GO TO, а в його безладному використанні. Дуже часто при втіленні структурного програмування на деяких мовах програмування (наприклад, на Фортраном) оператор переходу (GO TO) використовується для здійснення структурних конструкцій, не знижуючи основних достоїнств структурного програмування. Заплутують програму як раз "неструктурні" оператори переходу, особливо перехід на оператор, розташований в тексті модуля вище (раніше) виконуваного оператора переходу. Тим не менш, спроба уникнути оператора переходу в деяких простих випадках може призвести до занадто громіздким структурованим програмами, що не покращує їх ясність і містить небезпеку появи в тексті модуля додаткових помилок. Тому можна рекомендувати уникати вживання оператора переходу всюди, де це можливо, але не ціною ясності програми [8.1].
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Лекція
480.3кб. | скачати


Схожі роботи:
Основні поняття математичного програмування Побудова моделі задачі лінійного програмування
Програмування мовою С з використанням обєктно-орієнтованого програмування
Програмування мовою С з використанням об єктно орієнтованого програмування
Програмування в СІ
Програмування CMOS
Лінійне програмування 2
Цілочислове програмування
Введення в програмування
© Усі права захищені
написати до нас