Розробка програмних модулів програмного забезпечення комп'ютерних систем. Робоча програма навчальної практики професійного модуля "Розробка програмних модулів програмного забезпечення для комп'ютерних систем" Розробка модулів програмного

МІНІСТЕРСТВО ОСВІТИ І НАУКИ

ДОНЕЦЬКОЇ НАРОДНОЇ РЕСПУБЛІКИ

ДЕРЖАВНЕ ПРОФЕСІЙНЕ

ОСВІТНЯ УСТАНОВА

«ДОНЕЦЬКИЙ ПРОМИСЛОВО-ЕКОНОМІЧНИЙ КОЛЕДЖ»

РОБОЧА ПРОГРАМА

Навчальної практики УП.01

професійного модуля ПМ.01 Розробка програмних модулів програмного забезпеченнядля комп'ютерних систем

за спеціальністю 09.02.03 «Програмування у комп'ютерних системах»

Укладачі:

Волков Володимир Олександрович, викладач комп'ютерних дисциплін кваліфікаційної категорії «спеціаліст вищої категорії», ДПОУ «Донецький промислово-економічний коледж»

Програму погоджено: Вовк Павло Андрійович, директор «Smart IT Service»


1. ПАСПОРТ ПРОГРАМИ ПРАКТИКИ
2. РЕЗУЛЬТАТИ ПРАКТИКИ
3. СТРУКТУРА І ЗМІСТ ПРАКТИКИ
4. УМОВИ ОРГАНІЗАЦІЇ ТА ПРОВЕДЕННЯ ПРАКТИКИ
5. КОНТРОЛЬ І ОЦІНКА РЕЗУЛЬТАТІВ ПРАКТИКИ

1 ПАСПОРТ ПРОГРАМИ НАВЧАЛЬНОЇ ПРАКТИКИ УП. 01

1.1 Місце навчальної практики УП.01

Програма навчальної практики УП.01 професійного модуля ПМ.01 «Розробка програмних модулів програмного забезпечення для комп'ютерних систем» спеціальності 09.02.03 «Програмування у комп'ютерних системах » укрупненої групи 09.00.00 «Інформатика та обчислювальна техніка», щодо освоєння основного виду професійної діяльності (ВПД):

Розробка програмних модулів програмного забезпечення для комп'ютерних систем та відповідних професійних компетенцій (ПК):

	Розробляти специфікації окремих компонентів.
	Здійснювати розробку коду програмного продуктуз урахуванням готових специфікацій лише на рівні модуля.
	Виконувати налагодження програмних модулів із використанням спеціалізованих програмних засобів.
	Виконувати тестування програмних модулів.
	Здійснювати оптимізацію програмного кодумодуля.
	Розробляти компоненти проектної та технічної документації з використанням графічних мов специфікацій.

Програма навчальної практики УП.01 професійного модуля ПМ.01 «Розробка програмних модулів програмного забезпечення для комп'ютерних систем» може бути використана у додатковій професійній освіті та професійній підготовці працівників для спеціальностей 09.02.03 Програмування у комп'ютерних системах за наявності середньої (повної) загальної освіти. Досвід роботи не потрібний.

1.2 Цілі та завданнянавчальної практики УП.01

З метою оволодіння зазначеним видом професійної діяльності та відповідними професійними компетенціями учнів у ході навчальної практики УП.01 повинен:

мати практичний досвід:

розроблення алгоритму поставленого завдання та реалізації його засобами автоматизованого проектування;

розроблення коду програмного продукту на основі готової специфікації на рівні модуля;

використання інструментальних засобів на етапі налагодження програмного продукту;

проведення тестування програмного модуля за певним сценарієм;

вміти:

здійснювати розробку коду програмного модуля сучасними мовами програмування;

створювати програму за розробленим алгоритмом як окремий модуль;

виконувати налагодження та тестування програми на рівні модуля;

оформляти документацію на програмні засоби;

використовувати інструментальні засоби для автоматизації оформлення документації;

знати:

основні етапи розроблення програмного забезпечення;

основні засади технології структурного та об'єктно-орієнтованого програмування;

основні засади налагодження та тестування програмних продуктів;

методи та засоби розробки технічної документації.

1.3 Кількість тижнів(годин) на освоєння програминавчальної практики УП.01

Усього 1,5 тижня, 54 години.

2 РЕЗУЛЬТАТИ ПРАКТИКИ

Результатом навчальної практики УП.01 професійного модуля ПМ.01 "Розробка програмних модулів програмного забезпечення для комп'ютерних систем" є освоєння загальних компетенцій (ОК):

	Найменування результату практики
	-
ОК 2. Організовувати власну діяльність, вибирати типові методи та способи виконання професійних завдань, оцінювати їх ефективність та якість.
ОК 3. Приймати рішення у стандартних та нестандартних ситуаціях та нести за них відповідальність.
ОК 4. Здійснювати пошук та використання інформації, необхідної для ефективного виконання професійних завдань, професійного та особистісного розвитку.
ОК 5. Використовувати інформаційно-комунікаційні технології у професійній діяльності.
ОК 6. Працювати в колективі та в команді, ефективно спілкуватися з колегами, керівництвом, споживачами.
ОК 7. Брати він відповідальність за роботу членів команди (підлеглих), результат виконання завдань.	-
	кваліфікації
ОК 9. Орієнтуватися в умовах частої зміни технологій у професійній діяльності.

професійних компетенцій (ПК):

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

3 СТРУКТУРА І ЗМІСТ ПРОГРАМИНАВЧАЛЬНОЇ ПРАКТИКИ УП.01

3.1 Тематичний план

Коди компетенцій, що формуються

Найменування професійного модуля

Обсяг часу, відведений на практику

(у тижнях, годинник)

Строки проведення

ПК 1.1 – ПК 1.6

ПМ.01 "Розробка програмних модулів програмного забезпечення для комп'ютерних систем"

1,5 тижні,

54 години

3.2 Зміст практики

Види діяльності	Види робіт		Найменування навчальних дисциплін, міждисциплінарних курсів із зазначенням тем, що забезпечують виконання видів робіт	Кількість годин (тижнів)
«Освоєння основного виду професійної діяльності »	Тема 1.Вступ. Алгоритми розв'язання задач. Структура лінійного алгоритму. Структура циклічного алгоритму. Алгоритм підпрограми (функції).	Сформовано знання з основ створення спеціальних об'єктів
	Тема2 . Середа Skratch (Скретч).	Сформовано знання з основ засобів автоматизації процесу Сформовано знання з основ анімаційних ефектів до об'єктів; використання гіперпосилань та кнопок; налаштування демонстрації; презентації, збереженої у різних форматах.	МДК.01.01 «Системне програмування»
	Тема 3 . Створення навчальної програми (урок із предмета).	Сформовано знання з основ аналізу даних з використанням функцій процесора	МДК.01.02 «Прикладне програмування»
	Тема 4.Розробка ігрової програми.	Сформовано знання з основ обчислення підсумкових характеристик	МДК.01.01 «Системне програмування»
	Тема 5.Мова графічного програмування LabVIEW.	Сформовано знання з основ створення тесту процесора.	МДК.01.02 «Прикладне програмування»
	Тема 6. Створення програми за допомогою LabVIEW.	Сформовано знання основ діалогу користувача із системою	МДК.01.02 «Прикладне програмування»
	Тема 7 Багаторазове використання фрагмента програми.	Сформовано знання з операторів та функцій системи.	МДК.01.02 «Прикладне програмування»
	Тема 8 Практикум з LabVIEW. Охорона праці під час роботи з комп'ютером робочому місці пользователя.	Сформовано знання з обчислень елементарних функцій. Сформовано знання з Охорони праці.	МДК.01.02 «Прикладне програмування». ОП.18 «Охорона праці»
	Тема 9 Висновки. Складання звіту з практики.	Сформовано вміння аналізу комп'ютерних технологій, розв'язання задач Сформовано вміння.	МДК.01.01 «Системне програмування» МДК.01.02 «Прикладне програмування» МДК.04.01 «Офісне програмне забезпечення»

4 УМОВИ ОРГАНІЗАЦІЇ ТА ПРОВЕДЕННЯ

НАВЧАЛЬНОЇ ПРАКТИКИ УП. 01

4.1 Вимоги до документації, необхідної для проведення практики:

Робоча програманавчальної практики УП.01 професійного модуля ПМ.01 «Розробка програмних модулів програмного забезпечення для комп'ютерних систем» є частиною програми підготовки фахівців середньої ланки Державною професійною освітньою установою «Донецький промислово-економічний коледж» відповідно до державного освітнього стандарту середньої професійної освіти за спеціальністю 09.02.03 «Програмування у комп'ютерних системах», засноване на навчальному планіза спеціальністю, робочою програмою з дисциплін МДК.01.01 «Системне програмування», МДК01.02 «Прикладне програмування», методичні рекомендації з навчально-методичного забезпечення практики студентів, які освоюють освітні програми середньої професійної освіти.

4.2 Вимоги до навчально-методичного забезпечення практики:

перелік затверджених завдань за видами робіт, методичних рекомендацій для студентів щодо виконання робіт, рекомендації щодо виконання звітів з практики.

4.3 Вимоги до матеріально-технічного забезпечення:

організація виробничої практики вимагає наявності кабінетів та лабораторії.

Обладнання кабінету та робочих місць:

посадкові місця за кількістю студентів (стіл, комп'ютер, стілець);

робоче місце викладача (стіл, комп'ютер, стілець);

шафа для зберігання навчально-наочних посібників та носіїв інформації;

завдання для індивідуального підходу під час навчання, організації самостійної роботи та вправ, студента на комп'ютері;

довідкової та методичної літератури;

набір системних, прикладних та навчальних програм для ПК на оптичних та електронних носіях;

журнал інструктажу студентів з охорони праці;

комплект навчально-наочних посібників.

Технічні засоби навчання:

аудиторна дошка;

персональний комп'ютер із ліцензійним програмним забезпеченням;

лазерний принтер;

навчальні ПК;
комплект інтерактивного обладнання (проектор, екран, стовпчики);
засоби пожежогасіння (вогнегасник).

Обладнання кабінету та робочих місць інструментальних засобів розробки: персональні комп'ютери (монітор, системний блок, клавіатура, миша), комплект навчально-методичної документації, програмне забезпечення відповідно до змісту дисципліни (оболонки мов програмування).

Усі комп'ютери в класі об'єднані в локальну мережу, мають доступ до мережного сховища інформації та мають доступ до мережі Інтернет.

Комунікаційне обладнання:

мережеві адаптери;

мережеві кабелі;

бездротове обладнання WiFi.

Компоненти для монтажу мереж, обладнання для монтажу.

4.4 Перелік навчальних видань, Інтернет ресурсів, додаткової літератури

Основні джерела:

Оліфер В.Г. Мережеві операційні системи: підручник для вузів/В.Г.Оліфер, Н.А.Оліфер. - 2-ге вид. - Санкт-Петербург: Пітер, 2009, 2008. - 668 с.:

е. Таненбаум. Операційні системи. Розробка та реалізація. СПб.: Пітер, 2006. – 568 с.

Пупков К.А. Освоєння операційної системи Unix/К.А.Пупков, А.С.Черніков, Н.М.Якушева. - Москва: Радіо та зв'язок, 1994. - 112 с.

Л. Бек Введення у системне програмування - М.: Світ, 1988.

Грекул В.І., Денищенко Г.М., Коровкіна Н.Л. Проектування інформаційних систем/Москва: Біном, 2008. - 304 с.

Липаєв, В. В. Програмна інженерія. Методологічні засади [Текст]: Навч. / В. В. Липаєв; Держ. ун-т – Вища школа економіки. – М.: ТЕІС, 2006. – 608 с.

Лаврищева Є. М., Петрухін В. А. Методи та засоби інженерії програмного забезпечення. - Підручник

Іан Соммервілл. Інженерія програмного забезпечення, 6-е видання: Пер. з англ. ―М. : Видавничий дім "Вільямс", 2002.-624 с.

Еxcel 2010: професійне програмування на VBA: Пер. з англ. - М: ТОВ “І.Д. Вільямс”, 2012. – 944 с. : іл. – Парал. тит. Англ

Фаулер М. Рефакторинг: покращення існуючого коду. З англ.-СПб: Символ-плюс, 2003.-432 с.

Додаткові джерела:

Волков В.А. МЕТОДИЧНІ ВКАЗІВКИ для виконання практичних робіт з дисципліни «Системне програмування», Донецьк: ДОНПЕК, 2015.

Волков В.А. Методичні вказівки до виконання курсового проекту, Донецьк: ДОНПЕК, 2015.

Інтернет- ресурси:

Системне програмування [ електронний ресурс] / Режим доступу: http://www.umk3.utmn.ru.

Програмне забезпечення та Інтернет-ресурси: http://www.intuit.ru

Література з дисципліни http://www.internet-technologies.ru/books/

Електронний підручник «Вступ до програмної інженерії» - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Електронний підручник "Технологія програмування" - http://bourabai.kz/alg/pro.htm

4.5 Вимоги до керівників практики від освітньої установи та організації

Вимоги до керівників практики від освітньої установи:

інженерно-педагогічний склад: дипломовані фахівці – викладачі міждисциплінарних курсів та загальнопрофесійних дисциплін. Досвід діяльності в організаціях відповідної професійної галузі є обов'язковим.

Майстер виробничого навчання: наявність 5-6 кваліфікаційного розряду з обов'язковим стажуванням у профільних організаціях не рідше одного разу на 3 роки. Досвід діяльності в організаціях відповідної професійної галузі є обов'язковим.

5 КОНТРОЛЬ І ОЦІНКА РЕЗУЛЬТАТІВ

НАВЧАЛЬНОЇ ПРАКТИКИ УП. 01

Форма звітності з навчальної практики УП.01 – звіт з практики, оформлений відповідно до вимог методичних рекомендацій.

Результати (Освоєні професійні компетенції)	Основні показники результату підготовки	Форми та методи контролю
ПК 1.1. Виконувати розробку специфікацій окремих компонентів	Розробка алгоритму поставленого завдання та реалізації його засобами автоматизованого проектування	Експертне спостереження та оцінка діяльності учня в процесі освоєння освітньої програми на практичних заняттях, при виконанні робіт з навчальної та виробничої практики.
ПК 1.2. Здійснювати розробку коду програмного продукту з урахуванням готових специфікацій лише на рівні модуля.	Знати основні засади технології структурного та об'єктно-орієнтованого програмування. Здійснювати розробку коду програмного модуля сучасними мовами програмування.
ПК 1.3. Виконувати налагодження програмних модулів з використанням спеціалізованих програмних засобів	Виконувати налагодження та тестування програми на рівні модуля.
ПК 1.4. Виконувати тестування програмних модулів.	Створювати програму за розробленим алгоритмом як окремий модуль.
ПК 1.5. Здійснювати оптимізацію програмного коду модуля	Розробка коду програмного продукту з урахуванням готової специфікації лише на рівні модуля.
ПК 1.6. Розробляти компоненти проектної та технічної документації з використанням графічних мов специфікацій	Знати методи та засоби розробки технічної документації. Оформляти документацію на програмні засоби. Використовувати інструментальні засоби для автоматизації оформлення документації.

Форми та методи контролю та оцінки результатів навчання повинні дозволяти перевіряти у учнів не тільки сформованість професійних компетенцій, а й розвиток загальних компетенцій та їх умінь.

Результати (Освоєні загальні компетенції)	Основні показники оцінки результату	Форми та методи контролю та оцінки
ОК 1. Розуміти сутність та соціальну значущість своєї майбутньої професії, виявляти до неї стійкий інтерес.	прояв постійного інтересу до майбутньої професії; - обґрунтованість застосування освоєних професійних компетенцій;	Експертне спостереження та оцінка на практичних заняттях при виконанні робіт з виробничої практики;
ОК 2. Організовувати власну діяльність, визначати методи та способи виконання професійних завдань, оцінювати їх ефективність та якість.	Обґрунтування постановки мети, вибору та застосування методів та способів вирішення професійних завдань; Проведення самоаналізу та корекції результатів власної роботи	Оцінка на практичних заняттях під час виконання робіт; Спостереження під час практики; Самоаналіз
ОК 3. Вирішувати проблеми, оцінювати ризики та приймати рішення у нестандартних ситуаціях.	Результативність прийняття рішень стандартних та нестандартних професійних завдань за певний час; Результативність плану щодо оптимізації якості виконаних робіт	Інтерпретація результатів спостереження за діяльністю того, хто навчається в процесі виконання завдань
ОК 4. Здійснювати пошук, аналіз та оцінку інформації, необхідної для постановки та вирішення професійних завдань, професійного та особистісного розвитку.	Відбір та аналіз необхідної інформації для чіткого та швидкого виконання професійних завдань, професійного та особистісного розвитку	Експертна оцінка під час виконання робіт; Самоконтроль у ході постановки та вирішення проблем
ОК 5. Використовувати інформаційно-комунікативні технології для вдосконалення професійної діяльності.	вміння користуватися інформаційно-комунікаційними технологіями для вирішення професійних завдань	оцінка виконання завдань
ОК 6. Працювати в колективі та команді, забезпечувати її згуртування, ефективно спілкуватися з колегами, керівництвом, споживачами.	Вміння взаємодіяти з групою, викладачами, майстром виробничого навчання
ОК 7. Ставити цілі, мотивувати діяльність підлеглих, організовувати і контролювати їхню роботу з прийняттям він відповідальності за результат виконання завдань.	- проведення самоаналізу та корекції результатів власної роботи та роботи команди	Спостереження за ходом роботи у групі у процесі виробничої практики
ОК 8. Самостійно визначати завдання професійного та особистісного розвитку, займатися самоосвітою, свідомо планувати підвищення кваліфікації.	Організація самостійної роботи з формування творчого та професійного іміджу; Організація робіт з самоосвіти та підвищення кваліфікації	Спостереження та оцінка в процесі виробничої практики; Рефлексивний аналіз (алгоритм дій учня); Щоденник з практики; Аналіз портфоліо учня
ОК 9. Бути готовим до зміни технологій у професійній діяльності.	Аналіз інновацій у галузі технологічних процесів розробки та виготовлення швейних виробів	Оцінка розв'язків ситуаційних задач; Ділові та організаційно-навчальні ігри; Спостереження та оцінка на практичних заняттях, у процесі виробничої практики

Порядок розроблення програмного модуля.

1. вивчення та перевірка специфікації модуля, вибір мови програмування; (тобто розробник, вивчаючи специфікацію, з'ясовує, зрозуміла вона йому чи ні, чи достатньо повно вона описує модуль; потім він вибирає мову програмування, якою буде написаний модуль, хоча мова програмування може бути єдиним для всього ПС)
2. вибір алгоритму та структури даних (тут з'ясовується чи не відомі будь-які алгоритми для вирішення поставленої задачі і якщо є, то скористатися ним)
3. програмування модуля (написання коду програми)
4. шліфування тексту модуля (редагування наявних коментарів, додавання додаткових коментарів, щоб забезпечити необхідну якість)
5. перевірка модуля (перевіряється логіка роботи модуля, налагоджується його)

Застосовуються такі методи контролю програмного модуля:

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

Структурне програмування.

На сьогоднішній день найпопулярнішою методикою програмування є структурне програмування «згори донизу».

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

Два принципи структурного програмування:

1. Послідовна деталізація «згори - вниз»
2. обмеженість базового набору структур для побудови алгоритмів будь-якого ступеня складності

Вимоги структурного програмування:

1. програма повинна складатися дрібними кроками, таким чином, складне завдання розбивається на досить прості частини, що легко сприймаються.
2. логіка програми повинна спиратися на мінімальну кількість досить базових керуючих структур (лінійні, розгалужувані та циклічні структури)

Основні властивості та переваги структурного програмування:

1. зменшення складності програм
2. можливість демонстрації правильності програм на різних етапах розв'язання задачі
3. наочність програм
4. простота модифікації (внесення змін) програм.

Сучасні засоби програмування повинні забезпечувати максимальний захист від можливих помилокрозробника.

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

Основна ідея структурного програмування: програма повинна бути безліч блоків, об'єднаних у вигляді ієрархічної деревоподібної структури, кожен з яких має один вхід і один вихід.

Будь-яку програму можна побудувати, використовуючи лише три основні типи блоків:

1. функціональний блок – окремий лінійний операторабо їхня послідовність;
2. блок розгалуження - If
3. узагальнений цикл – конструкція типу While

Істотно, що кожна з цих конструкцій має по управлінню лише один вхід та один вихід. Тим самим, і узагальнений оператор має лише один вхід та один вихід.

Структурне програмування іноді називають ще програмуванням без GO TO. Однак справа тут не в операторі GO TO, а в його безладному використанні. Дуже часто при втіленні структурного програмування деякими мовами програмування оператор переходу (GO TO) використовується для реалізації структурних конструкцій, не знижуючи основних переваг структурного програмування. Заплутують програму якраз "неструктурні" оператори переходу, особливо перехід на оператор, розташований у тексті модуля вище (раніше) оператора переходу, що виконується. Тим не менш, спроба уникнути оператора переходу в деяких простих випадках може призвести до занадто громіздких структурованих програм, що не покращує їхню ясність і містить небезпеку появи в тексті модуля додаткових помилок. Тому можна рекомендувати уникати використання оператора переходу всюди, де це можливо, але не ціною ясності програми.

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

Взагалі кажучи, головне у структурному програмуванні - грамотне складання правильної логічної схемипрограми, реалізація якої мовними засобами – справа вторинне.

Перехід від неформального до формального суттєво неформальний.

лекція 8.

РОЗРОБКА ПРОГРАМНОГО МОДУЛЯ

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

8.1. Порядок розроблення програмного модуля.

При розробці програмного модуля доцільно дотримуватися наступного порядку:

· Вивчення та перевірка специфікації модуля, вибір мови програмування;

· Вибір алгоритму і структури даних;

· Програмування (кодування) модуля;

· шліфування тексту модуля;

· Перевірка модуля;

· Компіляція модуля.

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

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

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

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

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

І, нарешті, останній крок розробки модуля означає завершення перевірки модуля (за допомогою компілятора) та перехід до процесу налагодження модуля.

8.2. Структурне програмування.

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

Рис. 8.1. Основні керуючі конструкції структурного програмування.

Основними конструкціями структурного програмування є: слідування, розгалуження та повторення (див. мал. 8.1). Компонентами цих конструкцій є узагальнені оператори (вузли обробки) S, S1, S2 та умова (предикат) P. Як узагальнений оператор може бути або простий оператор використовуваної мови програмування (оператори присвоєння, введення, виведення, звернення до процедури), або фрагмент програми є композицією основних керуючих конструкцій структурного програмування. Істотно, що кожна з цих конструкцій має по управлінню лише один вхід та один вихід. Тим самим, і узагальнений оператор має лише один вхід та один вихід.

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

Структурне програмування іноді називають ще програмуванням без GO TO. Однак справа тут не в операторі GO TO, а в його безладному використанні. Дуже часто при втіленні структурного програмування деякими мовами програмування (наприклад, ФОРТРАН) оператор переходу (GO TO) використовується для реалізації структурних конструкцій, що не порушує принципів структурного програмування. Заплутують програму саме "неструктурні" оператори переходу, особливо перехід до оператора, розташованому в тексті модуля вище (раньше) оператора переходу, що виконується. Тим не менш, спроба уникнути оператора переходу в деяких простих випадках може призвести до занадто громіздких структурованих програм, що не покращує їхню ясність і містить небезпеку появи в тексті модуля додаткових помилок. Тому можна рекомендувати уникати вживання оператора переходу усюди, де це можливо, але не ціною ясності програми.

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

8.3. Покрокова деталізація та поняття про псевдокод.

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

Як основний метод побудови тексту модуля сучасна технологія програмування рекомендує покрокову деталізацію. Сутність цього методу полягає у розбитті процесу розробки тексту модуля на ряд кроків. На першому

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

Покрокова деталізація пов'язана з використанням частково формалізованої мови для подання зазначених описів, яка отримала назву псевдокода. Ця мова дозволяє використовувати всі конструкції структурного програмування, які оформляються формалізовано, разом із неформальними фрагментами природною мовою для подання узагальнених операторів та умов. Як узагальнені оператори та умови можуть задаватися і відповідні фрагменти на базовій мові програмування.

· Початок модуля на базовій мові, тобто перша пропозиція або заголовок (специфікацію) цього модуля;

· Розділ (сукупність) описів на базовій мові, причому замість описів процедур і функцій - тільки їх зовнішнє оформлення;

· неформальне позначення послідовності операторів тіла модуля як одного узагальненого оператора (див. нижче), а також неформальне позначення тіла кожного опису процедури або функції як одного узагальненого оператора;

· Остання пропозиція (кінець) модуля на базовій мові.

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

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

Рис. 8.2. Основні конструкції структурного програмування на псевдокод.

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

Вихід із повторення (циклу):

Вихід із процедури (функції):

Дж. Хьюз, Дж. Мічтом. Структурний підхід до програмування. - М: Мир, 1980. - с. 29-71.

В. Турський. Методологія програмування. - М: Мир, 1981. - с.90-164.

Є.А. Жоголів. Технологічні основи модульного програмування // Програмування, 1980 №2. - С.44-49.

R.C.Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6). - p. 879-893.

Г.Майєрс. Надійність програмного забезпечення - М: Мир, 1980. - с. 92-113.

Я. Пайл. ПЕКЛО - мова вбудованих систем. М.: Фінанси та статистика, 1984. - с. 67-75.

М. Зелковець, А. Шоу, Дж. Геннон. Принципи розробки програмного забезпечення. - М: Мир, 1982, с. 65-71.

А.Л.Фуксман. Технологічні аспекти створення програмних систем. М: Статистика, 1979. - с. 79-94.

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

ВИДАЛЕННЯ У ФАЙЛІ ЗАПИСІВ ДО ПЕРШОЇ,

ЗАДОВОЛЮЄ ЗАДАНОМУ ФІЛЬТРУ:

ВСТАНОВИТИ ПОЧАТОК ФАЙЛУ.

ЯКЩО ЧЕРГОВИЙ ЗАПИС задовольняє

ФІЛЬТРУ ТО

ВИДАЛИТИ ЧЕРГОВИЙ ЗАПИС З ФАЙЛА.

ВСЕ ЯКЩО

ВСЕ, БУВАЙ

ЯКЩО ЗАПИСИ НЕ ВИДАЛЕНІ ТО

НАДРУКувати "ЗАПИСИ НЕ ВИДАЛЕНІ".

НАДРУКувати "ВИДАЛЕНО н ЗАПИСІВ".

ВСЕ ЯКЩО

Рис. 8.4. Приклад одного кроку деталізації на псевдокод.

Ідею покрокової деталізації приписують іноді Дейкстре. Однак Дейкстра пропонував принципово відмінний метод побудови тексту модуля, який нам представляється більш глибоким та перспективним. По-перше, разом з уточненням операторів він пропонував поступово (по кроках) уточнювати (деталізувати) і структури даних, що використовуються. По-друге, на кожному кроці він пропонував створювати деяку віртуальну машину для деталізації і в її термінах робити деталізацію всіх понять, для яких ця машина дозволяє це зробити. Таким чином, Дейкстра пропонував, по суті, деталізувати горизонтальними шарами, що є перенесенням його ідеї про шаруватих системах (див. лекцію 6) на рівень розробки модуля. Такий метод розробки модуля підтримується нині пакетами мови АДА та засобами об'єктно-орієнтованого програмування.
8.4. Контроль програмного модуля.
Використовуються такі методи контролю програмного модуля:
статична перевірка тексту модуля;
наскрізне простеження;
підтвердження властивостей програмного модуля.
При статичній перевірці тексту модуля цей текст прочитується з початку остаточно з метою знайти помилки в модулі. Зазвичай для такої перевірки залучають, окрім розробника модуля, ще одного або кількох програмістів. Рекомендується помилки, що виявляються при такій перевірці, виправляти не відразу, а після завершення читання тексту модуля.
Наскрізне простеження є одним із видів динамічного контролю модуля. У ньому також беруть участь кілька програмістів, які вручну прокручують виконання модуля (оператор за оператором у тому послідовності, яка випливає з логіки роботи модуля) деякому наборі тестів.
Доказу властивостей програм присвячена наступна лекція. Тут слід лише відзначити, що цей метод застосовується поки що дуже рідко.
Література для лекції 8.
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
(9.3) (n
(9.4) (n>0) p:=1; m:=1;
ПОКИ m /= n РОБИТИ
ВСЕ, БУВАЙ
Для доказу якості програми S використовуються властивості простих операторів мови програмування (ми обмежимося тут порожнім оператором і оператором присвоювання) і властивостями керуючих конструкцій (композицій), за допомогою яких будується програма з простих операторів (ми тут обмежимося трьома основними композиціями структурного програмування, див. Лекцію 8). Ці властивості зазвичай називають правилами верифікації програм.
9.2. Властивості найпростіших операторів.
Для порожнього оператора справедлива
Теорема 9.1. Нехай P – предикат над інформаційним середовищем. Тоді має місце властивість (P)(P).
Доказ цієї теореми очевидний: порожній оператор не змінює стан інформаційного середовища (відповідно до своєї семантики), тому його передумова зберігає істинність і після його виконання.
Для оператора присвоєння справедлива
Теорема 9.2. Нехай інформаційне середовище 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
Властивість розгалуження виражає така
Теорема 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) має місце властивість
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 у цьому циклені може виконуватися більше разів. Теорему доведено.
Наприклад, для розглянутого вище прикладу оператора циклу умов теореми 9.7 задовольняє функція f(n, m) = n-m. Оскільки перед виконанням оператора циклу 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. Основні поняття.
Налагодження ПС - це діяльність, спрямована на виявлення та виправлення помилок у ПС з використанням процесів виконання його програм. Тестування ПС - це процес виконання його програм на деякому наборі даних, для якого наперед відомий результат застосування або відомі правила поведінки цих програм. Зазначений набір даних називається тестовим чи просто тестом. Таким чином, налагодження можна подати у вигляді багаторазового повторення трьох процесів: тестування, в результаті якого може бути констатовано наявність у ПС помилки, пошуку місця помилки у програмах та документації ПС та редагування програм та документації з метою усунення виявленої помилки. Іншими словами:
Налагодження = Тестування + Пошук помилок + Редагування.
У зарубіжній літературі налагодження часто розуміють тільки як процес пошуку та виправлення помилок (без тестування), наявність яких встановлюється при тестуванні. Іноді тестування та налагодження вважають синонімами. У нашій країні в поняття налагодження зазвичай включають і тестування, тому ми будемо слідувати традиції, що склалася. Втім спільний розгляд у цій лекції цих процесів робить зазначене різночитання менш істотним. Слід зазначити, що тестування використовується як частина процесу атестації ПС (див. лекцію 14).
10.2. Принципи та види налагодження.
Успіх налагодження значною мірою визначає раціональна організація тестування. При налагодженні перебувають і усуваються, переважно, ті помилки, наявність яких у ПС встановлюється під час тестування. Як було зазначено, тестування неспроможна довести правильність ПС , у разі воно може продемонструвати наявність у ньому помилки. Іншими словами, не можна гарантувати, що тестуванням ПС практично здійсненним набором тестів можна встановити наявність кожної помилки, що є в ПС. Тому виникає два завдання. Перша: підготувати такий набір тестів і застосувати до них ПС, щоб виявити в ньому якомога більше помилок. Проте що довше триває процес тестування (і налагодження загалом), то більшою стає вартість ПС. Звідси друге завдання: визначити момент закінчення налагодження ПС (або його окремої компоненти). Ознакою можливості закінчення налагодження є повнота охоплення пропущеними через ПС тестами (тобто тестами, до яких застосовано ПС) безлічі різних ситуацій, що виникають при виконанні програм ПС, та відносно рідкісний прояв помилок ПС на останньому відрізку процесу тестування. Останнє визначається відповідно до необхідного ступеня надійності ПС, вказаної у специфікації його якості.
Для оптимізації набору тестів, тобто. для підготовки такого набору тестів, який дозволяв би при заданому їх числі (або при заданому інтервалі часу, відведеному на тестування) виявляти більша кількістьПомилки, необхідно, по-перше, заздалегідь планувати цей набір і, по-друге, використовувати раціональну стратегію планування (проектування) тестів. Проектування тестів можна розпочинати відразу після завершення етапу зовнішнього опису ПС. Можливі різні підходи до вироблення стратегії проектування тестів, які можна умовно графічно розмістити між наступними двома крайніми підходами (див. рис. 9.1). Лівий крайній підхід у тому, що тести проектуються лише з вивчення специфікацій ПС (зовнішнього описи, описи архітектури та специфікації модулів). Будова модулів у своїй не враховується, тобто. вони сприймаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, оскільки при використанні в якості тестів тільки частини цих наборів деякі ділянки програм ПС можуть не працювати ні на якому тесті і, отже, помилки, що містяться в них, не будуть виявлятися. Проте тестування ПС повним безліччю наборів вхідних даних практично неможливе. Правий крайній підхід у тому, що тести проектуються виходячи з вивчення текстів програм із єдиною метою протестувати всі шляхи виконання кожної програм ПС. Якщо взяти до уваги наявність у програмах циклів зі змінним числом повторень, то різних шляхів виконання програм ПС може виявитися також надзвичайно багато, тому їх тестування також буде практично нездійсненно.
Оптимальна стратегія проектування тестів розташована всередині інтервалу між цими крайніми підходами, але ближче до лівого краю. Вона включає проектування значної частини тестів за специфікаціями, виходячи з принципів: на кожну функцію або можливість, що використовується, - хоча б один тест, на кожну область і на кожну межу зміни якої-небудь вхідної величини - хоча б один тест, на кожен особливий випадок або на кожну виняткову ситуацію, зазначені у специфікаціях, – хоча б один тест. Але вона вимагає також проектування деяких тестів і за текстами програм, з принципу (як мінімум): кожна команда кожної програми ПС має опрацювати хоча б одному тесті.
Оптимальну стратегію проектування тестів можна конкретизувати на підставі наступного принципу: для кожного програмного документа (включаючи тексти програм), що входить до складу ПС, повинні проектувати свої тести з метою виявлення в ньому помилок. У всякому разі, цього принципу необхідно дотримуватися відповідно до визначення ПС та змісту поняття технології програмування як технології розробки надійних ПС (див. лекцію 1). У зв'язку з цим Майєрс навіть визначає різні видитестування залежно від виду програмного документа, виходячи з якого будуються тести. У нашій країні розрізняються два основні види налагодження (включаючи тестування): автономне та комплексне налагодження. Автономне налагодження означає тестування лише якоїсь частини програми, що входить до ПС, з пошуком та виправленням у ній фіксованих при тестуванні помилок. Вона фактично включає налагодження кожного модуля та налагодження сполучення модулів. Комплексне налагодження означає тестування ПС загалом із пошуком і виправленням фіксованих під час тестування помилок переважають у всіх документах (включаючи тексти програм ПС), які стосуються ПС загалом. До таких документів належать визначення вимог до ПС, специфікація якості ПС, функціональна специфікація ПС, опис архітектури ПС та тексти програм ПС.
10.3. Заповіді налагодження.
У цьому розділі надаються загальні рекомендації щодо організації налагодження. Але спочатку слід зазначити деякий феномен, який підтверджує важливість попередження помилок на попередніх етапах розробки: зі зростанням кількості виявлених та виправлених помилок у ПС зростає також відносна ймовірність існування в ньому невиявлених помилок. Це пояснюється тим, що при зростанні числа помилок, виявлених у ПС, уточнюється і наше уявлення про загальну кількість допущених у ньому помилок, а значить, певною мірою, і про кількість невиявлених помилок. Цей феномен підтверджує важливість раннього виявлення помилок та необхідність ретельного контролю прийнятих рішень на кожному етапі розробки ПС.
Заповідь 1. Вважайте тестування ключовим завданням розробки ПС, доручайте його кваліфікованим та обдарованим програмістам; небажано тестувати свою програму.
Заповідь 2. Хороший тест, для якого висока ймовірність виявити помилку, а не той, який демонструє правильну роботу програми.
Заповідь 3. Готуйте тести для правильних і неправильних даних.
Заповідь 4. Уникайте невідтворюваних тестів, документуйте їх пропуск через комп'ютер; детально вивчайте результати кожного тесту.
Заповідь 5. Кожен модуль підключайте до програми лише один раз; ніколи не змінюйте програму, щоб полегшити її тестування.
Заповідь 6. Пропускайте знову всі тести, пов'язані з перевіркою роботи будь-якої програми ПС або її взаємодії з іншими програмами, якщо в неї були внесені зміни (наприклад, внаслідок усунення помилки).
10.4. Автономне налагодження модуля.
При автономному налагодженні кожен модуль насправді тестується в деякому програмному оточенні, крім випадку, коли програма, що налагоджується, складається тільки з одного модуля. Це оточення складається з інших модулів, частина яких є модулями програми, які вже налагоджені, а частина - модулями, що керують налагодженням (налагоджувальними модулями, див. нижче). Таким чином, при автономному налагодженні тестується завжди деяка програма, побудована спеціально для тестування модуля, що відладжується. Ця програма лише частково збігається з програмою, що налагоджується, крім випадку, коли налагоджується останній модуль програми, що відладжується. У міру просування налагодження програми все більшу частину оточення чергового модуля, що налагоджується, будуть складати вже налагоджені модулі цієї програми, а при налагодженні останнього модуля цієї програми оточення модуля, що налагоджується, буде повністю складатися з усіх інших (вже налагоджених) модулів налагоджувальної програми (без будь-яких) модулів, тобто. у цьому випадку тестуватиметься сама програма, що налагоджується. Такий процес нарощування програми, що відладжується, налагодженими і відладжуваними модулями називається інтеграцією програми.
Налагоджувальні модулі, що входять в оточення модуля, залежать від порядку, в якому налагоджуються модулі цієї програми, від того, який модуль налагоджується і, можливо, від того, який тест буде пропускатися.
При висхідному тестуванні (див. лекцію 7) це оточення завжди буде містити тільки один налагоджувальний модуль (крім випадку, коли налагоджується останній модуль програми, що налагоджується), який буде головним у тестованій програмі і який називають ведучим (або драйвером). Ведучий налагоджувальний модуль готує інформаційне середовище для тестування модуля, що відладжується (тобто формує її стан, необхідний для тестування цього модуля, зокрема, може здійснювати введення деяких тестових даних), здійснює звернення до модуля, що налагоджується, і після закінчення його роботи видає необхідні повідомлення. При налагодженні одного модуля для різних тестів можуть складатися різні провідні модулі налагодження.
При низхідному тестуванні (див. лекцію 7) оточення модуля, що відладжується, як налагоджувальні модулі містить імітатори всіх модулів, до яких може звертатися налагоджуваний модуль, а також імітатори тих модулів, до яких можуть звертатися налагоджені модулі налагоджуваної програми (включені в це оточення), але які ще не налагоджені. Деякі з цих імітаторів при налагодженні одного модуля можуть бути змінені для різних тестів.
Насправді в оточенні модуля, що відладжується в багатьох випадках можуть утримуватися налагоджувальні модулі обох типів з нижче наступних міркувань. Як висхідне, і низхідне тестування має свої переваги і недоліки.
До переваг висхідного тестування відносяться
простота підготовки тестів та
можливість повної реалізації плану тестування модуля
Це пов'язано з тим, що тестовий стан інформаційного середовища готується безпосередньо перед зверненням до модуля, що відладжується (провідним налагоджувальним модулем). Недоліками висхідного тестування є такі його особливості:
тестові дані готуються, як правило, не в тій формі, яка розрахована на користувача (крім випадку, коли налагоджується останній, головний, модуль програм, що налагоджується);
великий обсяг налагоджувального програмування (при налагодженні одного модуля часто доводиться складати для різних тестів багато провідних модулів налагодження);
необхідність спеціального тестування сполучення модулів.
До переваг низхідного тестування належать такі його особливості:
більшість тестів готується у формі, розрахованій на користувача;
у багатьох випадках відносно невеликий обсяг налагоджувального програмування (імітатори модулів, як правило, дуже прості і кожен придатний для великої кількості, нерідко – для всіх, тестів);
відпадає необхідність тестування сполучення модулів.
Недоліком низхідного тестування є те, що тестовий стан інформаційного середовища перед зверненням до модуля, що налагоджується, готується побічно - воно є результатом застосування вже налагоджених модулів до тестових даних або даних, що видаються імітаторами. Це, по-перше, ускладнює підготовку тестів, вимагає високої кваліфікації виконавця-тестовика, а по-друге, утруднює або навіть неможливе реалізацію повного плану тестування модуля, що відладжується. Зазначений недолік іноді змушує розробників застосовувати висхідне тестування навіть у разі низхідної розробки. Однак частіше застосовують деякі модифікації низхідного тестування, або деяку комбінацію низхідного та висхідного тестування.
Виходячи з того, що низхідне тестування, в принципі, є кращим, зупинимося на прийомах, що дозволяють певною мірою подолати зазначені труднощі. Насамперед необхідно організувати налагодження програми таким чином, щоб якомога раніше були налагоджені модулі, які здійснюють введення даних, - тоді тестові дані можна готувати у формі, розрахованій на користувача, що спростить підготовку наступних тестів. Далеко не завжди це введення здійснюється в головному модулі, тому доводиться в першу чергу налагоджувати ланцюжки модулів, що ведуть до модулів, які здійснюють зазначене введення (пор. з методом цілеспрямованої конструктивної реалізації в лекції 7). Поки модулі, що здійснюють введення даних, не налагоджені, тестові дані поставляються деякими імітаторами: вони включаються до імітатора як його частина, або вводяться цим імітатором.
При низхідному тестуванні деякі стани інформаційного середовища, при яких потрібно тестувати модуль, що налагоджується, можуть не виникати при виконанні налагоджуваної програми ні при яких вхідних даних. У цих випадках можна було б взагалі не тестувати модуль, що налагоджується, так як виявляються при цьому помилки не будуть проявлятися при виконанні програми, що відладжується, ні при яких вхідних даних. Однак так чинити не рекомендується, так як при змінах програми, що налагоджується (наприклад, при супроводі ПС) не використані для тестування налагоджуваного модуля стану інформаційного середовища можуть вже виникати, що вимагає додаткового тестування цього модуля (а цього при раціональній організації налагодження можна було б не робити , якщо сам модуль не змінювався). Для здійснення тестування модуля, що налагоджується, в зазначених ситуаціях іноді використовують підходящі імітатори, щоб створити необхідний стан інформаційного середовища. Найчастіше користуються модифікованим варіантом низхідного тестування, при якому модулі, що відладжуються, перед їх інтеграцією попередньо тестуються окремо (у цьому випадку в оточенні модуля, що налагоджується, з'являється провідний налагоджувальний модуль, поряд з імітаторами модулів, до яких може звертатися налагоджуваний модуль). Однак, більш доцільною є інша модифікація низхідного тестування: після завершення низхідного тестування налагоджуваного модуля для досяжних тестових станів інформаційного середовища слід його окремо протестувати для інших необхідних станів інформаційного середовища.
Часто застосовують також комбінацію висхідного та низхідного тестування, яку називають методом сандвіча. Сутність цього методу полягає в одночасному здійсненні як висхідного, так і низхідного тестування, поки ці два процеси тестування не зустрінуться на якому-небудь модулі десь у середині структури програми, що налагоджується. Цей метод дозволяє при розумному підході скористатися перевагами як висхідного, так і низхідного тестування та значною мірою нейтралізувати їх недоліки. Цей ефект є проявом більш загального принципу: найбільшого технологічного ефекту можна досягти, поєднуючи низхідні та висхідні методи розробки програм ПС. Саме для підтримки цього методу і призначений архітектурний підхід до розробки програм (див. лекцію 7): шар кваліфіковано розроблених та ретельно відтестованих модулів суттєво полегшує реалізацію сімейства програм у відповідній предметній галузі та їх подальшу модернізацію.
Дуже важливим при автономному налагодженні є тестування модулів сполучення. Справа в тому, що специфікація кожного модуля програми, крім головного, використовується в цій програмі у двох ситуаціях: по-перше, при розробці тексту (іноді говорять: тіла) цього модуля і, по-друге, при написанні звернення до цього модуля в інших модулі програми. І в тому, і в іншому випадку в результаті помилки може бути порушена відповідність заданої специфікації модуля. Такі помилки потрібно виявляти та усувати. Для цього і призначено тестування сполучення модулів. При низхідному тестуванні тестування сполучення здійснюється попутно кожним тестом, що пропускається, що вважають найсильнішим гідністю низхідного тестування. При висхідному тестуванні звернення до модуля, що налагоджується, проводиться не з модулів налагоджуваної програми, а з провідного налагоджувального модуля. У зв'язку з цим існує небезпека, що останній модуль може пристосуватися до деяких "помилок" модуля, що відладжується. Тому, приступаючи (у процесі інтеграції програми) до налагодження нового модуля доводиться тестувати кожне звернення до раніше налагодженого модуля з метою виявлення неузгодженості цього поводження з тілом відповідного модуля (і не виключено, що винен у цьому раніше налагоджений модуль). Таким чином, доводиться частково повторювати в нових умовах тестування раніше налагодженого модуля, при цьому виникають ті ж труднощі, що при низхідному тестуванні.
Автономне тестування модуля доцільно здійснювати чотири послідовно виконуваних кроку .
Крок 1. На підставі специфікації модуля, що налагоджується, підготуйте тест для кожної можливості і кожної ситуації, для кожної межі областей допустимих значень всіх вхідних даних, для кожної області зміни даних, для кожної області недопустимих значень всіх вхідних даних і кожної недопустимої умови.
Крок 2. Перевірте текст модуля, щоб переконатися, що кожен напрямок будь-якого розгалуження буде пройдено хоча б на одному тесті. Додайте відсутні тести.
Крок 3. Переконайтеся, що для кожного циклу існує тест, для якого тіло циклу не виконується, тест, для якого тіло циклу виконується один раз, і тест, для якого тіло циклу виконується максимальне число разів. Додайте відсутні тести.
Крок 4. Перевірте за текстом модуля його чутливість до окремих особливих значень вхідних даних - усі такі значення мають входити до тестів. Додайте відсутні тести.
10.5. Комплексне налагодження програмного засобу.
Як було зазначено вище, при комплексній налагодженні тестується ПС загалом, причому тести готуються за кожним із документів ПС . Тестування цих документів проводиться, як правило, у порядку, зворотному їх розробці (виняток становить лише тестування документації із застосування, яка розробляється за зовнішнім описом паралельно з розробкою текстів програм; це тестування краще проводити після завершення тестування зовнішнього опису). Тестування при комплексному налагодженні являє собою застосування ПС до конкретних даних, які в принципі можуть виникнути у користувача (зокрема, всі тести готуються у формі, розрахованій на користувача), але, можливо, в моделюється (а не в реальному) середовищі. Наприклад, деякі недоступні при комплексному налагодженні пристрої введення та виведення можуть бути замінені їх програмними імітаторами.
Тестування архітектури ПС. Метою тестування є пошук невідповідності між описом архітектури та сукупністю програм ПС. На момент початку тестування архітектури ПС має бути вже закінчено автономне налагодження кожної підсистеми. Помилки реалізації архітектури можуть бути пов'язані насамперед із взаємодією цих підсистем, зокрема, з реалізацією архітектурних функцій (якщо вони є). Тому хотілося б перевірити усі шляхи взаємодії між підсистемами ПС. Але оскільки їх може бути занадто багато, то бажано протестувати хоча б всі ланцюжки виконання підсистем без повторного входження останніх. Якщо задана архітектура представляє ПС як малу систему з виділених підсистем, число таких ланцюжків буде цілком доступним для огляду.
Тестування зовнішніх функцій. Метою тестування є пошук розбіжностей між функціональною специфікацією та сукупністю програм ПС. Незважаючи на те, що всі ці програми вже автономно налагоджені, зазначені розбіжності можуть бути, наприклад, через невідповідність внутрішніх специфікацій програм та їх модулів (на підставі яких проводилося автономне тестування) зовнішньої функціональної специфікації ПС. Зазвичай, тестування зовнішніх функцій проводиться як і, як і тестування модулів першому кроці, тобто. як чорний ящик.
Тестування якості ПС. Метою тестування є пошук порушень вимог якості, сформульованих специфікації якості ПС. Це найважчий і найменш вивчений вид тестування. Зрозуміло лише, що не кожен примітив якості ПС може бути випробуваний тестуванням (про оцінку якості ПС див. наступну лекцію). Завершеність ПС перевіряється вже під час тестування зовнішніх функцій. На даному етапі тестування цього примітиву якості може бути продовжено, якщо потрібно отримати будь-яку ймовірнісну оцінку ступеня надійності ПС. Проте методика такого тестування ще потребує своєї розробки. Точність, стійкість, захищеність, тимчасова ефективність, певною мірою - ефективність пам'яті, ефективність пристроїв, розширюваність і, частково, незалежність пристроїв можуть тестуватися. Кожен з цих видів тестування має свою специфіку і заслуговує на окремий розгляд. Ми тут обмежимося лише їх перерахуванням. Легкість застосування ПС (критерій якості, що включає кілька примітивів якості див. лекцію 4) оцінюється при тестуванні документації із застосування ПС.
Тестування документації із застосування ПС. Метою тестування є пошук неузгодженості документації із застосування та сукупністю програм ПС, а також незручностей застосування ПС. Цей етап безпосередньо передує підключенню користувача до завершення розробки ПС (тестування вимог до ПС та атестації ПС), тому дуже важливо розробникам спочатку самим скористатися ПС так, як це робитиме користувач. Всі тести на цьому етапі готуються виключно на підставі лише документації щодо застосування ПС. Насамперед, повинні тестуватись можливості ПС як це робилося при тестуванні зовнішніх функцій, але тільки на підставі документації щодо застосування. Повинні бути протестовані всі незрозумілі місця в документації, а також усі приклади, які використані в документації. Далі тестуються найважчі випадки застосування ПС з метою виявити порушення вимог щодо легкості застосування ПС.
Тестування визначення вимог до ПС. Метою тестування є з'ясування, якою мірою ПС відповідає пред'явленому визначенню вимог щодо нього. Особливість цього виду тестування полягає в тому, що його здійснює організація-покупець або організація-користувач ПС як один із шляхів подолання бар'єру між розробником та користувачем (див. лекцію 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.3. Забезпечення точності програмного засобу.
Забезпечення цього примітиву пов'язане з діями над значеннями речових типів (точніше кажучи, зі значеннями, що подаються з деякою похибкою). Забезпечити необхідну точність при обчисленні значення тієї чи іншої функції - означає отримати це значення з похибкою, яка не виходить за межі заданих меж. Видами похибки, методами їхньої оцінки та методами досягнення необхідної точності (так званими наближеними обчисленнями) займається обчислювальна математика. Тут ми звернемо увагу на деяку структуру похибки: похибка обчисленого значення (повна похибка) залежить
від похибки використовуваного методу обчислення (у яку ми включаємо і неточність моделі, що використовується),
від похибки подання використовуваних даних (від т.зв. непереборної похибки),
від похибки округлення (неточності виконання що у методі операцій).
11.4. Забезпечення автономності програмного засобу.
Цей примітив якості забезпечується на етапі специфікації якості прийняттям рішення про використання в ПС будь-якого відповідного базового програмного забезпечення або не використанні в ньому ніякого базового програмного забезпечення. При цьому доводиться враховувати як його надійність, так і необхідні ресурси. При підвищених вимогах до надійності ПС, що розробляється, надійність базового програмного забезпечення, що є в розпорядженні розробників, може виявитися незадовільною, тому від його використання доводиться відмовлятися, а реалізацію його функцій в необхідному обсязі доводиться включати до складу ПС. Аналогічні рішення доводиться приймати при жорстких обмеження використовувані ресурси (за критерієм ефективності ПС).
11.5. Забезпечення стійкості програмного засобу.
Цей примітив якості забезпечується за допомогою захисного програмування. Взагалі кажучи, захисне програмування застосовується підвищення надійності ПС при програмуванні модуля у ширшому сенсі. Як стверджує Майєрс, "захисне програмування засноване на важливій передумові: найгірше, що може зробити модуль, - це прийняти неправильні вхідні дані і потім повернути невірний, але правдоподібний результат". Для того, щоб цього уникнути, текст модуля включає перевірки його вхідних і вихідних даних на їх коректність відповідно до специфікації цього модуля, зокрема, повинні бути перевірені виконання обмежень на вхідні та вихідні дані та співвідношень між ними, зазначені в специфікації модуля. У разі негативного результату перевірки порушується відповідна виняткова ситуація. У зв'язку з цим у кінець цього модуля включаються фрагменти другого роду - обробники відповідних виняткових ситуацій, які крім видачі необхідної діагностичної інформації, можуть вжити заходів або за винятком помилки даних (наприклад, вимагати їх повторного введення), або щодо послаблення впливу помилки (наприклад , м'яку зупинку керованих ПС пристроїв, щоб уникнути їх поломки при аварійному припиненні виконання програми).
Застосування захисного програмування модулів призводить до зниження ефективності ПС як за часом, так і по пам'яті. Тому необхідно розумно регулювати ступінь застосування захисного програмування залежно від вимог до надійності та ефективності ПС, сформульованим у специфікації якості ПС, що розробляється. Вхідні дані модуля можуть надходити як безпосередньо від користувача, так і від інших модулів. Найбільш уживаним випадком застосування захисного програмування є застосування його першої групи даних, що означає реалізацію стійкості ПС. Це потрібно робити завжди, коли в специфікації якості ПС є вимога забезпечення стійкості ПС. Застосування захисного програмування для другої групи вхідних даних означає спробу виявити помилку в інших модулях під час виконання модуля, а для вихідних даних модуля - спробу виявити помилку в самому цьому модулі під час його виконання. По-суті, це означає часткове втілення підходу самовиявлення помилок задля забезпечення надійності ПС, що йшлося у лекції 3. Цей випадок захисного програмування застосовується вкрай рідко - лише тому випадку, коли вимоги до надійності ПС надзвичайно високі.
11.6. Забезпечення захищеності програмних засобів.
Розрізняють такі види захисту ПС від спотворення інформації:
захист від збоїв апаратури;
захист від впливу "чужої" програми;
захист від відмов "своєї" програми;
захист від помилок оператора (користувача);
захист від несанкціонованого доступу;
захист від захисту.
Захист від збоїв апаратури нині не дуже злободенне завдання (з урахуванням рівня досягнутої надійності комп'ютерів). Але все ж таки корисно знати її рішення. Це забезпечується організацією про " подвійних - потрійних прорахунків " . Для цього весь процес обробки даних, який визначається ПС, розбивається за часом на інтервали так званими "опорними точками". Довжина цього інтервалу повинна перевищувати половини середнього часу безвідмовної роботи комп'ютера. Копія стану змінної у цьому процесі пам'яті кожній опорній точці записується у вторинну пам'ять з деякою контрольною сумою (числом, що обчислюється як деяка функція від цього стану) у тому випадку, коли буде вважатися, що обробка даних від попередньої опорної точки до даної (тобто один "прорахунок") зроблено правильно (без збоїв комп'ютера). Для того, щоб це з'ясувати, провадиться два такі "прорахунки". Після першого "прорахунку" обчислюється та запам'ятовується зазначена контрольна сума, а потім відновлюється стан пам'яті для попередньої опорної точки та робиться другий "прорахунок". Після другого "прорахунку" обчислюється знову зазначена контрольна сума, яка потім порівнюється з контрольною сумою першого "прорахунку". Якщо ці дві контрольні суми збігаються, другий прорахунок вважається правильним, інакше контрольна сума другого "прорахунку" також запам'ятовується і проводиться третій "прорахунок" (з попереднім відновленням стану пам'яті попередньої опорної точки). Якщо контрольна сума третього "прорахунку" збігається з контрольною сумою одного з перших двох "прорахунків", то третій прорахунок вважається правильним, інакше потрібна інженерна перевірка комп'ютера.
Захист від впливу "чужої" програми відноситься насамперед до операційних систем або програм, що виконують частково їх функції. Розрізняють два різновиди цього захисту:
захист від відмов,
захист від зловмисного впливу "чужої" програми.
При появі мультипрограмного режиму роботи комп'ютера в його пам'яті може одночасно перебувати в стадії виконання кілька програм, що поперемінно отримують управління в результаті переривань, що виникають (так зване квазіпаралельне виконання програм). Одна з таких програм (зазвичай операційна система) займається обробкою переривань і керуванням мультипрограмним режимом. У кожній з таких програм можуть виникати відмови (виявлятися помилки), які можуть вплинути на виконання функцій іншими програмами. Тому керуюча програма (операційна система) має забезпечити захист себе та інших програм від такого впливу. Для цього апаратура комп'ютера має реалізовувати такі можливості:
захист пам'яті,
два режими функціонування комп'ютера: привілейований та робочий (користувацький),
два види операцій: привілейовані та ординарні,
коректну реалізацію переривань та початкового включення комп'ютера,
тимчасове переривання.
Захист пам'яті означає можливість програмним шляхом задавати для кожної програми недоступні для неї ділянки пам'яті. У привілейованому режимі можуть виконуватися будь-які операції (як ординарні, і привілейовані), а робочому режимі - лише ординарні. Спроба виконати привілейовану операцію, а також звернутися до захищеної пам'яті у робочому режимі викликає відповідне переривання. Причому до привілейованих операцій відносяться операції зміни захисту пам'яті та режиму функціонування, а також доступу до зовнішнього інформаційного середовища. Початкове увімкнення комп'ютера та будь-яке переривання повинні автоматично включати привілейований режим та скасування захисту пам'яті. У цьому випадку керуюча програма (операційна система) може повністю захистити себе від впливу інших програм, якщо всі точки передачі управління при початковому включенні та переривання будуть належати цій програмі, якщо вона ніякій іншій програмі не дозволить працювати в привілейованому режимі (при передачі управління будь-який інший) програмі включатиметься лише робочий режим) і якщо вона повністю захистить свою пам'ять (що містить, зокрема, всю її керуючу інформацію, включаючи так звані вектори переривань) від інших програм. Тоді ніхто не завадить їй виконувати будь-які реалізовані в ній функції захисту інших програм (у тому числі доступу до зовнішнього інформаційного середовища). Для полегшення розв'язання цього завдання частина такої програми міститься у постійну пам'ять, тобто. невіддільна від самого комп'ютера. Наявність тимчасового переривання дозволяє програмі, що управляє, захиститися від зациклювання в інших програмах (без такого переривання вона могла б просто втратити можливість управляти).
Захист від відмов "своєї" програми забезпечується надійністю цієї програми, потім орієнтована вся технологія програмування, обговорювана у цьому курсі лекцій.
Захист від помилок користувача (крім помилок вхідних даних див. забезпечення стійкості ПС) забезпечується видачею попереджувальних повідомлень про спроби змінити стан зовнішнього інформаційного середовища з вимогою підтвердження цих дій, а також можливістю відновлення стану окремих компонент зовнішнього інформаційного середовища. Останнє ґрунтується на здійсненні архівування змін стану зовнішнього інформаційного середовища.
Захист від несанкціонованого доступу забезпечується використанням таємних слів (паролей). І тут кожному користувачеві надаються певні інформаційні та процедурні ресурси (послуги), використання яких потрібно пред'явлення ПС деякого пароля, раніше зареєстрованого в ПС цим користувачем. Іншими словами, користувач як би "вішує замок" на виділені йому ресурси, "ключ" від якого є тільки у цього користувача. Однак, в окремих випадках можуть бути зроблені наполегливі спроби зламати такий захист, якщо ресурси, що захищаються, становлять для когось надзвичайну цінність. Для такого випадку доводиться вживати додаткових заходів для захисту від злому захисту.
Захист від злому захисту пов'язаний з використанням у ПС спеціальних програмістських прийомів, що ускладнюють подолання захисту від несанкціонованого доступу. Використання звичайних паролів виявляється недостатнім, коли йдеться про надзвичайно наполегливе прагнення (наприклад, злочинного характеру) домогтися доступу до цінної інформації. По-перше, тому, що інформацію про паролі, яку використовує ПС для захисту від несанкціонованого доступу, "зломщик" цього захисту відносно легко може дістати, якщо він має доступ до цього ПС. По-друге, використовуючи комп'ютер, можна здійснювати досить великий перебір можливих паролів з метою знайти відповідний для доступу до інформації, що цікавить. Захиститися від такого злому можна так. Секретне слово (пароль) або просто секретне ціле число X знає тільки власник інформації, що захищається, а для перевірки прав доступу в комп'ютері зберігається інше число Y=F(X), однозначно обчислюване ПС при кожній спробі доступу до цієї інформації при пред'явленні секретного слова. При цьому функція F може бути добре відомою всім користувачам ПС, однак вона має таку властивість, що відновлення слова X по Y практично неможливо: при досить великій довжині слова X (наприклад, кілька сотень знаків) для цього потрібен астрономічний час. Таке число Y називатимемо електронним (комп'ютерним) підписом власника секретного слова X (а значить, і інформації, що захищається).
Інший різновид такого захисту пов'язаний із захистом повідомлень, що пересилаються комп'ютерними мережами, навмисних (або зловмисних) спотворень. Таке повідомлення може перехоплюватися на "перевалочних" пунктах комп'ютерної мережі та підмінятися іншим повідомленням від автора перехопленого повідомлення. Така ситуація виникає насамперед під час здійснення банківських операцій із використанням комп'ютерної мережі. Шляхом заміни такого повідомлення, що є розпорядженням власника банківського рахунку про виконання деякої банківської операції, гроші з його рахунку можуть бути переведені на рахунок "зломщика" захисту (своєрідний вид комп'ютерного пограбування банку). Захист від такого злому захисту можна здійснити в такий спосіб. Поряд з функцією F, що визначає комп'ютерний підпис власника секретного слова X, яку знає адресат повідомлення, що захищається (якщо тільки її власник є клієнтом цього адресата), в ПС визначена інша функція Stamp, за якою відправник повідомлення повинен обчислити число S=Stamp(X,R ), використовуючи секретне слово X і текст повідомлення R. Функція Stamp також вважається добре відомою всім користувачам ПС і має таку властивість, що по S практично неможливо ні відновити число X, ні підібрати інше повідомлення R з відповідним комп'ютерним підписом. Саме передане повідомлення (разом зі своїм захистом) повинно мати вигляд:
причому Y (комп'ютерний підпис) дозволяє адресату встановити істинність клієнта, а S як би скріплює захищається повідомлення R з комп'ютерним підписом Y. У зв'язку з цим називатимемо число S електронною (комп'ютерною) печаткою. У ПС визначена ще одна функція Notary, за якою одержувач повідомлення, що захищається, перевіряє істинність повідомлення, що передається:
Це дозволяє однозначно встановити, що повідомлення 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.4. Забезпечення супровідності.
С-документованість, інформативність та зрозумілість визначають склад та якість документації з супроводу (див. наступну лекцію). З іншого боку, щодо текстів програм (модулів) можна зробити такі рекомендації.
використовуйте в тексті модуля коментарі, що прояснюють та пояснюють особливості прийнятих рішень; по-можливості, включайте коментарі (хоча б у короткій формі) на ранній стадії розробки тексту модуля ;
використовуйте осмислені (мнемонічні) та стійко помітні імена (оптимальна довжина імені - 4-12 літер, цифри - наприкінці), не використовуйте подібні імена та ключові слова;
будьте обережні у використанні констант (унікальна константа повинна мати єдине входження в текст модуля: при її оголошенні або, в крайньому випадку, при ініціалізації змінної як константа);
не бійтеся використовувати не обов'язкові дужки (дужки обходяться дешевше, ніж помилки);
розміщуйте не більше одного оператора у рядку; для прояснення структури модуля використовуйте додаткові прогалини (відступи) на початку кожного рядка ;
уникайте трюків, тобто. таких прийомів програмування, коли створюються фрагменти модуля, основний ефект яких не є очевидним або прихованим (завуальованим), наприклад, побічні ефекти функцій .
Розширюваність забезпечується створенням відповідного інсталятора.
Структурованість і модульність спрощують як розуміння текстів програм, і їх модифікацію.
12.5. Забезпечення мобільності.
Література для лекції 12.
12.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.
12.3. Д. Ван Тассел. Стиль, розробка, ефективність, налагодження та випробування програм. - М: Світ, 1985. С. 8-44, 117-178.
12.4. Документація користувача програмного забезпечення/Стандарт ANSI/IEEE 1063-1987.
Лекція 13. Документування програмних засобів
13.1. Документація, створювана у процесі розробки програмних засобів.
Під час створення ПС створюється великий обсяг різноманітної документації. Вона необхідна як засіб передачі між розробниками ПС, як управління розробкою ПС як засіб передачі користувачам інформації, яка потрібна на застосування та супроводження ПС. На створення цієї документації припадає більша частка вартості ПС.
Цю документацію можна розбити на дві групи:
Документи управління розробкою ПЗ.
Документи, що входять до складу ПЗ.
Документи управління розробкою ПС (process documentation), протоколюють процеси розробки та супроводу ПС, забезпечуючи зв'язки всередині колективу розробників та між колективом розробників та менеджерами (managers) - особами, які керують розробкою. Ці документи можуть бути наступних типів:
Плани, оцінки, розклади. Ці документи створюються менеджерами для прогнозування та управління процесами розробки та супроводу.
Звіти про використання ресурсів у процесі розробки. Створюються менеджерами.
Стандарти. Ці документи наказують розробникам, яких принципів, правил, угод вони повинні слідувати у процесі розробки ПС. Ці стандарти можуть бути як міжнародними або національними, так і спеціально створеними для організації, де ведеться розробка даного ПС.
Робочі документи Це є основні технічні документи, що забезпечують зв'язок між розробниками. Вони містять фіксацію ідей та проблем, що виникають у процесі розробки, опис використовуваних стратегій та підходів, а також робочі (тимчасові) версії документів, які мають увійти до ПС.
Нотатки та листування. Ці документи фіксують різні деталі взаємодії між менеджерами та розробниками.
Документи, що входять до складу ПС (product documentation), описують програми ПС як з погляду їх застосування користувачами, і з погляду їх розробників і супровідників (відповідно до призначенням ПС). Тут слід зазначити, що ці документи будуть використовуватися не тільки на стадії експлуатації ПС (у її фазах застосування та супроводу), а й на стадії розробки для управління процесом розробки (разом із робочими документами) - у всякому разі вони мають бути перевірені (протестовані) на відповідність програм ПС. Ці документи утворюють два комплекти з різним призначенням:
Користувальницька документація ПС (П-документація).
Документація із супроводу ПС (С-документація).
13.2. Користувальницька документація програмних засобів.
Документація користувача ПС (user documentation) пояснює користувачам, як вони повинні діяти, щоб застосувати дане ПС. Вона необхідна, якщо ПС передбачає якусь взаємодію з користувачами. До такої документації відносяться документи, якими керується користувач при інсталяції ПС (при встановленні ПС з відповідним налаштуванням на середовище застосування ПС), при застосуванні ПС для вирішення своїх завдань та при управлінні ПС (наприклад, коли дане ПС взаємодіє з іншими системами). Ці документи частково торкаються питань супроводу ПС, але не стосуються питань, пов'язаних із модифікацією програм.
У зв'язку з цим слід розрізняти дві категорії користувачів ПС: ординарних користувачів ПС та адміністраторів ПС. Ординарний користувач ПС (end-user) використовує ПС на вирішення своїх завдань (у своїй предметної області). Це може бути інженер, який проектує технічний пристрій, або касир, який продає залізничні квитки за допомогою ПС. Він може не знати багатьох деталей роботи комп'ютера чи принципів програмування. Адміністратор ПС (system administrator) управляє використанням ПС ординарними користувачами та здійснює супровід ПС, не пов'язане з модифікацією програм. Наприклад, він може регулювати права доступу до ПС між ординарними користувачами, підтримувати зв'язок із постачальниками ПС або виконувати певні дії, щоб підтримувати ПС у робочому стані, якщо воно включене як частину до іншої системи.
Склад документації залежить від аудиторій користувачів, на які орієнтоване дане ПС, і від режиму використання документів. Під аудиторією тут розуміється контингент користувачів ПС, у якого є необхідність у певній документації користувача ПС . Вдалий документ користувача істотно залежить від точного визначення аудиторії, для якої він призначений. Користувацька документація повинна містити інформацію, необхідну кожної аудиторії. Під режимом використання документа розуміється спосіб, який визначає, як використовується цей документ. Зазвичай користувачеві досить великих програмних систем потрібні документи для вивчення ПС (використання в вигляді інструкції), або уточнення деякої інформації (використання як довідника).
Відповідно до робіт можна вважати типовим наступний склад користувальницької документації для досить великих ПС:
Загальне функціональне опис ПС. Дає коротку характеристику функціональних можливостей ПЗ. Призначено для користувачів, які повинні вирішити, наскільки необхідне дане ПС.
Посібник з інсталяції ПС. Призначений для системних адміністраторів. Він повинен детально розпоряджатися, як встановлювати системи в конкретному середовищі. Він повинен містити опис машинно-зчитуваного носія, на якому поставляється ПС, файли, що представляють ПС, та вимоги до мінімальної конфігурації апаратури.
Інструкція із застосування ПС. Призначена для простих користувачів. Містить необхідну інформацію щодо застосування ПС, організовану у формі зручної для її вивчення.
Довідник із застосування ПС. Призначений для простих користувачів. Містить необхідну інформацію щодо застосування ПС, організовану у формі зручної для вибіркового пошуку окремих деталей.
Посібник з управління ПС. Призначений для системних адміністраторів. Воно має описувати повідомлення, що генеруються, коли ПС взаємодіє з іншими системами і як реагувати на ці повідомлення. Крім того, якщо ПС використовує системну апаратуру, цей документ може пояснювати, як супроводжувати цю апаратуру.
Як уже говорилося раніше (див. лекцію 4), розробка документації користувача починається відразу після створення зовнішнього опису. Якість цієї документації може суттєво визначати успіх ПС. Вона повинна бути досить проста і зручна для користувача (інакше це ПС взагалі не варто створювати). Тому, хоча чернові варіанти (малюнки) документів створюються основними розробниками ПС, до створення їх остаточних варіантів часто залучаються професійні технічні письменники. Крім того, для забезпечення якості документації користувача розроблено ряд стандартів (див. наприклад, ), в яких наказується порядок розробки цієї документації, формулюються вимоги до кожного виду документів користувача і визначаються їх структура і зміст.
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.2. Види випробувань програмного засобу.
Відомі такі види випробувань ПС, що проводяться з метою атестації ПС:
випробування компонент ПС;
системні випробування;
приймально-здавальні випробування;
польові випробування;
промислові випробування.
Випробування компонентів ПС - це перевірка (тестування) працездатності окремих підсистем ПС. Проводяться лише у виняткових випадках за спеціальним рішенням атестаційної комісії.
Системні випробування ПС – це перевірка (тестування) працездатності ПС загалом. Може включати ті самі види тестування, що і при комплексному налагодженні ПС (див. лекцію 10). Проводиться за рішенням атестаційної комісії, якщо виникають сумніви щодо проведення налагодження розробниками ПС.
Прийомо-здатні випробування є основним видом випробувань при атестації ПС. Саме з цих випробувань розпочинає роботу атестаційна комісія. Ці випробування починаються з вивчення поданої документації, у тому числі, і документації з тестування та налагодження ПС. Якщо в документації відсутні досить повні результати тестування ПС, атестаційна комісія може ухвалити рішення про проведення системних випробувань ПС або припинення процесу атестації з рекомендацією розробнику провести додаткове (повніше) тестування ПС. Крім того, під час цих випробувань можуть вибірково пропускатися тести розробників, а також контрольні завдання користувачів (див. лекцію 10) та додаткові тести, підготовлені комісією для оцінки якості ПС, що атестується.
Польові випробування ПС - це демонстрація ПС разом із технічною системою, якою керує ця ПС, вузькому колу замовників у реальних умовах і здійснюється ретельне спостереження за поведінкою ПС. Замовникам має бути надана можливість завдання власних контрольних прикладів, зокрема з виходів у критичні режими роботи технічної системи, а також із викликом у ній аварійних ситуацій. Це додаткові випробування, які проводяться за рішенням атестаційної комісії лише деяких ПС, управляючих певними технічними системами.
Промислові випробування ПС – це процес передачі ПС у постійну експлуатацію користувачам. Являє собою період дослідної експлуатації ПС (див. лекцію 10) користувачами зі збором інформації про особливості поведінки ПС та її експлуатаційні характеристики. Це завершальні випробування ПС, які проводяться за рішенням атестаційної комісії, якщо на попередніх випробуваннях отримано недостатньо повну або надійну інформацію для оцінки якості ПС, що атестується.
14.3. Методи оцінки якості програмного засобу.
Оцінка якості ПС за кожним із критеріїв зводиться до оцінки кожного з примітивів, пов'язаних з цим критерієм якості ПС, відповідно до їх конкретизації, виробленої у специфікації якості цього ПС. Методи оцінки примітивів якості ПС можна поділити на чотири групи:
безпосередній вимір показників примітиву якості;
обробка програм та документації ПС спеціальними програмними інструментами (процесорами);
тестування програм ПЗ;
експертна оцінка на підставі вивчення програм та документації ПС.
Безпосередній вимір показників примітиву якості здійснюється шляхом підрахунку числа входжень у той чи інший програмний документ характерних одиниць, об'єктів, конструкцій тощо, а також шляхом вимірювання часу роботи різних пристроївта обсягу зайнятої пам'яті ЕОМ при виконанні контрольних прикладів. Наприклад, деяким показником ефективності пам'яті може бути кількість рядків програми мовою програмування, а деяким показником ефективності за часом може бути час відповіді на запит. Використання будь-яких показників для примітивів якості може визначатися специфікації якості ПС. Метод безпосереднього вимірювання показників примітиву якості може поєднуватись з використанням тестування програм.
Для встановлення наявності ПС деяких примітивів якості можуть використовуватися певні програмні інструментальні засоби. Такі програмні інструменти обробляють тексти програм або програмної документації з метою контролю будь-яких примітивів якості або отримання деяких показників цих примітивів якості. Для оцінки структурованості програм ПС, якщо вони програмувалися на відповідному структурному діалекті базової мови програмування, достатньо було б їх пропустити через конвертер структурованих програм, який здійснює синтаксичний та деякий семантичний контроль цього діалекту та перекладає тексти цих програм на вхідну мову базового транслятора. Однак таким шляхом в даний час вдається контролювати лише невелику кількість примітивів якості, та й то в окремих випадках. У ряді випадків замість програмних інструментів, що контролюють якість ПС, корисніше застосовувати інструменти, що здійснюють перетворення програми або програмної документації. Таким, наприклад, є форматер програм, що приводить тексти програм до виду, що легко читається, - обробка текстів програм ПС таким інструментом може автоматично забезпечити наявність відповідного примітиву якості у ПС.
Для оцінки деяких примітивів якості ПС використовують тестування. До таких примітивів відноситься насамперед завершеність ПС, а також його точність, стійкість, захищеність та інші примітиви якості. У ряді випадків для оцінки окремих примітивів якості ПС тестування застосовується у поєднанні з іншими методами. Так для оцінки якості документації із застосування ПС (П-документованості) тестування застосовується у поєднанні з експертною оцінкою цієї документації. Якщо при комплексному налагодженні ПС було проведено досить повне тестування, то ці тести можуть бути використані і при атестації ПС. У цьому випадку атестаційна комісія може скористатися протоколами тестування, проведеного за комплексного налагодження. Однак і в цьому випадку необхідно виконати якісь нові тести або хоча б повторно деякі старі. Якщо ж тестування при комплексному налагодженні буде визнано недостатньо повним, необхідно провести повніше тестування. У цьому випадку може бути прийняте рішення про проведення випробувань компонентів або системних випробувань ПС, а також повернення ПС розробникам на доопрацювання. Дуже важливо, щоб для оцінки ПС за критерієм легкості застосування було проведено (під час налагодження та атестації ПС) повне тестування за тестами, підготовленими на підставі документації із застосування, а за критерієм супроводжуваності – за тестами, підготовленими за кожним із документів, запропонованих для супроводу ПС.
Для оцінки більшості примітивів якості ПС нині можна застосовувати лише метод експертних оцінок. Цей метод полягає в наступному: призначається група експертів, кожен із цих експертів в результаті вивчення поданої документації складає свою думку про володіння ПС необхідним примітивом якості, а потім голосуванням членів цієї групи встановлюється оцінка необхідного примітиву якості ПС. Ця оцінка може проводитися як за двобальною системою ("має" - "не володіє"), так і враховувати ступінь володіння ПС цим примітивом якості (наприклад, проводитися за п'ятибальною системою). При цьому група експертів повинна керуватися конкретизацією цього примітиву та вказівкою про спосіб його оцінки, сформульованими у специфікації якості ПС, що атестується.
Література для лекції 14.
14.2. В.В.Ліпаєв. Тестування програм. - М: Радіо і зв'язок, 1986. - С. 231-245.
14.3. Д. Ван Тассел. Стиль, розробка, ефективність, налагодження та випробування програм. - М: Мир, 1985. - С. 281-283.
14.4. Б. Шнейдерман. Психологія програмування. - М: Радіо і зв'язок, 1984. - С. 99-127.
Лекція 15. Об'єктний підхід до розробки програмних засобів
15.1. Об'єкти та відносини у програмуванні. Сутність об'єктного підходи до розробки програмних засобів.
Навколишній світ складається з об'єктів та відносин між ними. Об'єкт втілює деяку сутність і має деякий стан, який може змінюватися згодом як наслідок впливу інших об'єктів, що знаходяться з даним у будь-якому відношенні. Він може мати внутрішню структуру: складатися з інших об'єктів, що також перебувають між собою в деяких відносинах. Виходячи з цього, можна побудувати ієрархічну будову світу з об'єктів. Однак, при кожному конкретному розгляді навколишнього світу деякі об'єкти вважаються неподільними ("точковими"), причому залежно від цілей розгляду такими (неподільними) можуть прийматися об'єкти різного рівня ієрархії. Відношення пов'язує деякі об'єкти: можна вважати, що об'єднання цих об'єктів має деяку властивість. Якщо відношення пов'язує n об'єктів, то таке відношення називається n-місцевим (n-арним). На кожному місці об'єднання об'єктів, які можуть бути пов'язані будь-яким конкретним ставленням, можуть бути різні об'єкти, але цілком певні (у цьому випадку кажуть: об'єкти певного класу). Одномісне ставлення називається властивістю об'єкта (відповідного класу). Стан об'єкта може бути вивчений за значенням властивостей цього об'єкта або неявно за значенням властивостей об'єднань об'єктів, що пов'язуються разом з тим чи іншим відношенням.
У процесі пізнання або зміни навколишнього світу ми завжди приймаємо в розгляд ту чи іншу спрощену модель світу (модельний світ), до якої включаємо деякі з об'єктів і деякі з відносин навколишнього світу і, як правило, одного рівня ієрархії. Кожен об'єкт, що має внутрішню структуру, може представляти свій модельний світ, що включає об'єкти цієї структури та відносини, що їх пов'язують. Таким чином, навколишній світ можна розглядати (у деякому наближенні) як ієрархічну структуру модельних світів.
В даний час в процесі пізнання або зміни навколишнього світу широко використовується комп'ютерна техніка для обробки різноманітних інформації. У зв'язку з цим застосовується комп'ютерне (інформаційне) уявлення об'єктів та відносин. Кожен об'єкт інформаційно може бути представлений деякою структурою даних, що відображає його стан. Властивості цього об'єкта можуть задаватися у вигляді окремих компонент цієї структури, або спеціальними функціями над цією структурою даних. N-місцеві відносини для N>1 можна уявити або активної формі, або пасивної формі. В активній формі N-місцеве відношення представляється деяким програмним фрагментом, що реалізує або N-місцеву функцію (визначає значення якості відповідного об'єднання об'єктів), або процедуру, що здійснює за станом уявлень об'єктів, що пов'язуються представленим ставленням, зміна станів деяких з них. У пасивній формі таке відношення може бути представлене деякою структурою даних (до якої можуть входити і уявлення об'єктів, що пов'язуються цим ставленням), інтерпретовану на підставі прийнятих угод щодо загальних процедур, незалежних від конкретних відносин (наприклад, реляційна база даних). У будь-якому разі подання відносини визначає деякі дії з обробки даних.
При дослідженні модельного світу користувач може по-різному одержувати (або захотіти одержувати) інформацію від комп'ютера. При одному підході його можуть цікавити отримання інформації про окремі властивості об'єктів, що його цікавлять, або результати будь-якої взаємодії між деякими об'єктами. Для цього він замовляє розробку того чи іншого ПС, що виконує функції, що його цікавлять, або деяку інформаційну систему, здатну видавати інформацію про цікаві для нього відносини, використовуючи при цьому відповідну базу даних. У початковий період розвитку комп'ютерної техніки (при мало високої потужності комп'ютерів) такий підхід до використання комп'ютерів був цілком природним. Саме він і провокував функціональний (реляційний) підхід до розробки ПС, який детально розглянули в попередніх лекціях. Сутність цього підходу полягає в систематичному використанні декомпозиції функцій (відносин) для побудови структури ПС та текстів програм, що входять до нього. При цьому самі об'єкти, до яких застосовувалися функції, що замовляються і реалізуються, представлялися фрагментарно (у тому обсязі, який необхідний для виконання цих функцій) і у формі, зручній для реалізації цих функцій. Тим самим не забезпечувалося цілісного та адекватного комп'ютерного подання модельного світу, що цікавить користувача: відображення його на використовувані ПС могло виявитися для користувача досить трудомістким завданням, спроби незначного розширення обсягу та характеру інформації про модельний світ, що цікавить користувача. одержуваної від таких ПС, могло призвести до серйозної їхньої модернізації. Такий підхід до розробки ПС підтримується більшістю мов програмування, починаючи від мов асемблерів і процедурних мов(ФОРТРАН, Паскаль) до функціональних мов (ЛІСП) та мов логічного програмування (ПРОЛОГ).
При іншому підході до дослідження модельного світу за допомогою комп'ютера користувача може цікавити спостереження за зміною станів об'єктів внаслідок їх взаємодії. Це вимагає досить цілісного представлення в комп'ютері об'єкта, що цікавить, а програмні компоненти, що реалізують відносини, в яких бере участь цей об'єкт, явно зв'язуються з ним. Для реалізації такого підходу доводилося будувати програмні засоби, що моделюють процеси взаємодії об'єктів (модельного світу). За допомогою традиційних засобів розробки це виявилося досить трудомістким завданням. Щоправда, з'явилися мови програмування, спеціально орієнтовані таке моделювання, але це лише частково спростило завдання розробки необхідних ПС. Найбільш повно відповідає розв'язанню цього об'єктний підхід до розробки ПС. Сутність його полягає у систематичному використанні декомпозиції об'єктів при побудові структури ПС та текстів програм, що входять до нього. У цьому функції (відносини), виконувані таким ПС, виражалися через відносини об'єктів різних рівнів, т. е. їхня декомпозиція суттєво залежала від декомпозиції об'єктів.
Говорячи про об'єктному підході слід також чітко розуміти про які об'єкти йдеться: об'єкти модельного світу користувача, про їх інформаційне уявлення, про об'єкти програми, за допомогою яких будується ПС. Крім того, слід розрізняти власне об'єкти (об'єкти "пасивні") та суб'єкти (об'єкти "активні").
15.2. Об'єкти та суб'єкти у програмуванні.
15.3. Об'єктний та суб'єктний підходи до розробки програмних засобів.
Декарт зазначав, що зазвичай мають об'єктно-орієнтований погляд світ ( в ).
Вважають, що об'єктно-орієнтоване проектування засноване на принципах:
виділення абстракцій,
обмеження доступу,
модульність,
ієрархія,
типізація,
паралельність,
стійкість.
Але це може застосовуватися і за функціональному підході.
Слід розрізняти переваги та недоліки загального об'єктного підходу та його окремого випадку – суб'єктно-орієнтованого підходу.
Переваги загального об'єктивного підходу:
Природне відображення реального світу на будову ПС (природне сприйняття людиною можливостей ПС не потрібно "вигадувати" будову ПС, а використовувати природні аналогії).
Використання досить змістовних структурних одиниць ПС (об'єкт як цілісність надлишкових асоціацій, інфомаційно-міцні модулі).
Зниження трудомісткості розробки ПС за рахунок використання нового рівня абстракцій (використання ієрархії "непрограмних" абстракцій при розробці ПС: класифікація об'єктів реального світу, метод аналогій у природі) як новий рівень наслідування.
15.4. Об'єктний підхід до розробки зовнішнього опису та архітектури програмного засобу.
Об'єктно-орієнтоване проектування – метод, який використовує об'єктну декомпозицію; об'єктно-орієнтований підхід має свою систему умовних позначеньта пропонує багатий набір логічних та фізичних моделей для проектування систем високого ступеняскладності. .
На об'єктний підхід зробив об'єктно-орієнтований аналіз (ООА). ООА спрямовано створення моделей, ближчих до реальності, з використанням об'єктно-орієнтованого підходу; це методологія, коли він вимоги формуються з урахуванням понять класів та об'єктів, складових словник предметної області. .
Особливості об'єктно-орієнтованого програмування.
Об'єкти, класи, поведінка об'єкта, властивості, події.
Література для лекції 15.
15.1. К. Футі, Н. Судзукі. Мови програмування та схемотехніка НВІС. - М: Світ, 1988. С. 85-98.
15.2. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.? -?
15.3. Г.Буч. Об'єктно-орієнтоване проектування з прикладами застосування: пров. з англ. - М: Конкорд, 1992.
15.4. В.Ш.Кауфман. Мови програмування. Концепції та принципи. М.: Радіо та зв'язок, 1993.

Лекція 8. Розробка програмного модуля

8.1. Порядок розроблення програмного модуля.

8.2. Структурне програмування.

8.3. Покрокова деталізація та поняття про псевдокод.

8.4. Контроль програмного модуля.

Література для лекції 8.

Лекція 9. Доказ властивостей програм

9.1. Обґрунтування програм. Формалізація властивостей програм.

9.2. Властивості найпростіших операторів.

9.3. Властивості основних конструкцій структурного програмування.

9.4. Завершеність виконання програми.

9.5. Приклад підтвердження якості програми.

Література для лекції 9.

Лекція 10. Тестування та налагодження програмного засобу

10.1. Основні поняття.

10.2. Принципи та види налагодження.

10.3. Заповіді налагодження.

10.4. Автономне налагодження модуля.

10.5. Комплексне налагодження програмного засобу.

Література для лекції 10.

Лекція 11. Забезпечення функціональності та надійності програмного засобу

11.1. Функціональність та надійність як обов'язкові критерії якості програмного засобу.

11.2. Забезпечення завершеності програмного засобу.

11.3. Забезпечення точності програмного засобу.

11.4. Забезпечення автономності програмного засобу.

11.5. Забезпечення стійкості програмного засобу.

11.6. Забезпечення захищеності програмних засобів.

Література для лекції 11.

Лекція 12. Забезпечення якості програмного засобу

12.1. Загальна характеристика процесу забезпечення якості програмного засобу.

12.3. Забезпечення ефективності програмного засобу.

Література для лекції 12.

Лекція 13. Документування програмних засобів

13.1. Документація, створювана у процесі розробки програмних засобів.

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

Література для лекції 13.

Лекція 14. Атестація програмного засобу

14.1. Призначення атестації програмного засобу.

14.2. Види випробувань програмного засобу.

14.3. Методи оцінки якості програмного засобу.

Лекція 15. Об'єктний підхід до розробки програмних засобів

15.1. Об'єкти та відносини у програмуванні. Сутність об'єктного підходи до розробки програмних засобів.

15.2. Об'єкти та суб'єкти у програмуванні.

15.3. Об'єктний та суб'єктний підходи до розробки програмних засобів.

15.4. Об'єктний підхід до розробки зовнішнього опису та архітектури програмного засобу.

Література для лекції 15.