vchilka.in.ua 1 ... 2 3 4
Що таке програмний інструмент розробки програмного продукту?


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

Інструменти розробки ПС можуть використовуватися протягом всього життєвого циклу ПС [16.2] для роботи з разнимі програмними документами. Так текстовий редактор може використовуватися для розробки практично будь-якого програмного документа. З погляду функцій, які інструменти виконують при розробці ПС, їх можна розбити на наступні чотири групи:

редактори

2 аналізатори

3 перетворювачі

4 інструменти, що підтримують процес виконання програм.

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

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

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


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

Зчеплення модуля - це міра його залежності за даними від інших модулів. Характеризується способом передачі даних. Чим слабкіше зчеплення модуля з іншими модулями, тим сильніше його незалежність від інших модулів. Для оцінки ступеня зчеплення Майерс пропонує [7.5] впорядкований набір з шести видів зчеплення модулів. Гіршим видом зчеплення модулів є зчеплення по вмісту. Таким є зчеплення двох модулів, коли один з них має прямі посилання на вміст іншого модуля (наприклад, на константу, що міститься в іншому модулі). Таке зчеплення модулів неприпустимо. Не рекомендується використовувати також зчеплення по загальній області - це таке зчеплення модулів, коли декілька модулів використовують одну і ту ж область пам'яті. Такий вид зчеплення модулів реалізується, наприклад, при програмуванні на мові ФОРТРАН з використанням блоків COMMON. Єдиним видом зчеплення модулів, який рекомендується для використання сучасною технологією програмування, є параметричне зчеплення (зчеплення за даними по Майерсу [7.5]) - це випадок, коли дані передаються модулю або при зверненні до нього як значення його параметрів, або як результат його звернення до іншого модуля для обчислення деякої функції. Такий вид зчеплення модулів реалізується на мовах програмування при використанні звернень до процедур (функціям).

Що таке апаратний інструмент розробки програмного продукту?

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

Що таке структурне програмування?

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

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

Часто розробка ПС проводиться на тому ж комп'ютері, на якому воно застосовуватиметься. Це досить зручно. По-перше, в цьому випадку розробник має справу тільки з комп'ютерами одного типу. А, по-друге, в ПС, що розробляється, можуть включатися компоненти самого інструментального середовища. Проте, це не завжди можливо. Наприклад, комп'ютер, на якому повинно застосовуватися ПС, може бути незручний для підтримки розробки ПС або його потужність недостатня для забезпечення функціонування необхідного інструментального середовища. Крім того, такий комп'ютер може бути недоступний для розробників цього ПС (наприклад, він постійно зайнятий іншою роботою, яку не можна переривати, або він знаходиться ще в стадії розробки). У таких випадках застосовується так званий інструментально-об'єктний підхід [16.1]. Суть його полягає в тому, що ПС розробляється на одному комп'ютері, званим інструментальним, а застосовуватися буде на іншому комп'ютері, званим цільовим (або об'єктним).


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

Сукупність інструментальних середовищ можна розбивати на різні класи, які розрізняються значенням наступних ознак:

орієнтованість на конкретну мову програмування

спеціалізованість

комплексність

орієнтованість на конкретну технологію програмування

орієнтованість на колективну розробку

інтегрованість.
Що таке покрокова деталізація програмного модуля?

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

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

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

Що таке інструментально-об'єктний підхід до розробки програмного продукту
Що таке відладка програмного продукту?

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

Відладка = Тестування + Пошук помилок + Редагування.
Які ознаки класифікації інструментальної середи розробки і супроводу програмного продукту Ви знаєте?
Що таке тестування програмного продукту?

Успіх відладки ПП в значній мірі зумовлює раціональна організація тестування. При відладці ПП відшукуються і усуваються, в основному, ті помилки, наявність яких в ПП встановлюється при тестуванні. Як було вже відмічено, тестування не може довести правильність ПП [10.9], в кращому разі воно може продемонструвати наявність в нім помилки. Іншими словами, не можна гарантувати, що тестуванням ПП практично здійснимим набором тестів можна встановити наявність кожною наявною в ПП помилки. Тому виникає два завдання. Перше завдання: підготувати такий набір тестів і застосувати до них ПП, щоб виявити в нім по можливості більше число помилок. Проте чим довше продовжується процес тестування (і відладки в цілому), тим більшою стає вартість ПП. Звідси друге завдання: визначити момент закінчення відладки ПП (або окремою його компоненти). Ознакою можливості закінчення відладки є повнота обхвату пропущеними через ПП тестами (тобто тестами, до яких застосоване ПП) безлічі різних ситуацій, що виникають при виконанні програм ПП, і відносний рідкісний прояв помилок в ПП на останньому відрізку процесу тестування. Останнє визначається відповідно до необхідного ступеня надійності ПП, вказаної в специфікації його якості.


Для оптимізації набору тестів, тобто для підготовки такого набору тестів, який дозволяв би при заданому їх числі (або при заданому інтервалі часі, відведеному на тестування) виявляти більше число помилок в ПП, необхідно, по-перше, заздалегідь планувати цей набір і, по-друге, використовувати раціональну стратегію планування (проектування [10.1]) тестів. Проектування тестів можна починати відразу ж після завершення етапу зовнішнього опису ПП. Можливі різні підходи до вироблення стратегії проектування тестів, які можна умовно графічно розмістити (див. мал. 9.1) між наступними двома крайніми підходами [10.1]. Лівий крайній підхід полягає в тому, що тести проектуються тільки на підставі вивчення специфікацій ПП (зовнішнього опису, опису архітектури і специфікації модулів). Будова модулів при цьому ніяк не враховується, тобто вони розглядаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, оскільки інакше деякі ділянки програм ПП можуть не працювати при пропуску будь-якого тесту, а це означає, що помилки, що містяться в них, не виявлятимуться. Проте тестування ПП повним безліччю наборів вхідних даних практично нездійсненно. Правий крайній підхід полягає в тому, що тести проектуються на підставі вивчення текстів програм з метою протестувати всі шляхи виконання кожній програм ПП. Якщо взяти до уваги наявність в програмах циклів із змінним числом повторень, то різних шляхів виконання програм ПП може опинитися також надзвичайно багато, так що їх тестування також буде практично нездійсненно.
Що таке інтегрованість інструментальної середи розробки і супроводу програмного продукту?
Що таке автономна відладка програмного продукту?

Автономна відладка ПП означає послідовне роздільне тестування різних частин програм, що входять в ПП, з пошуком і виправленням в них помилок, що фіксуються при тестуванні. Вона фактично включає відладку кожного програмного модуля і відладку сполучення модулів.


При автономній відладці ПП кожен модуль насправді тестується в деякому програмному оточенні, крім випадку, коли відладжувана програма складається тільки з одного модуля. Це оточення складається [10.8] з інших модулів, частина яких є модулями відладжуваної програми, які вже відладжені, а частина - модулями, керівниками відладкою (налагоджувальними модулями, див. нижчий). Таким чином, при автономній відладці тестується завжди деяка програма (тестована програма), побудована спеціально для тестування відладжуваного модуля. Ця програма лише частково збігається з відладжуваною програмою, крім випадку, коли відладжується останній модуль відладжуваної програми. В процесі автономної відладки ПП проводиться нарощування тестованої програми відладженими модулями: при переході до відладки наступного модуля в його програмне оточення додається останній відладжений модуль. Такий процес нарощування програмного оточення відладженими модулями називається інтеграцією програми [10.1]. Налагоджувальні модулі, що входять в оточення відладжуваного модуля, залежать від порядку, в якому відладжуються модулі цієї програми, від того, який модуль відладжується і, можливо, від того, який тест пропускатиметься.
Які види інтегрованості інструментальної середи розробки і супроводу програмного продукту Ви знаєте?
Що таке комплексна відладка програмного продукту?

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

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


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

Тестування якості ПП. Метою тестування є пошук порушень вимог якості, сформульованих в специфікації якості ПП. Це найбільш важкий і найменш вивчений вид тестування. Ясно лише, що далеко не кожен примітив якості ПП може бути випробуваний тестуванням (про оцінку якості ПП див. лекцію 14). Завершеність ПП перевіряється вже при тестуванні зовнішніх функцій. На даному етапі тестування цього примітиву якості може бути продовжене, якщо потрібно отримати яку-небудь імовірнісну оцінку ступеня надійності ПП. Проте, методика такого тестування ще вимагає своєї розробки. Можуть тестуватися такі примітиви якості, як точність, стійкість, захищеність, тимчасова ефективність, в якійсь мірі - ефективність по пам'яті, ефективність по пристроях, розширюваність і, частково, незалежність від пристроїв. Кожен з цих видів тестування має свою специфіку і заслуговує на окремий розгляд. Ми тут обмежимося лише їх перерахуванням. Легкість застосування ПП (критерій якості, що включає декілька примітивів якості, див. лекцію 4) оцінюється при тестуванні документації по застосуванню ПП.

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


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



<< предыдущая страница