ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.11.2019
Просмотров: 458
Скачиваний: 1
Погано не поклажі, злодія в гріх не вводь.
Народне прислів'я
Лекція 11.
ЗАБЕЗПЕЧЕННЯ ФУНКЦІОНАЛЬНОСТІ І
НАДІЙНОСТІ ПРОГРАМНОГО ЗАСОБУ
Функціональність і надійність як обов'язкові критерії якості програмного засобу. Забезпечення завершеності програмного засобу. Захисне програмування і забезпечення стійкості програмного модуля. Види захисту і забезпечення захищеності програмного засобу.
11.1. Функціональність і надійність як обов'язкові критерії якості програмного засобу.
На попередніх лекціях ми розглянули всі етапи розробки ПС, окрім його атестації. При цьому ми не стосувалися питань забезпечення якості ПС відповідно до його специфікації якості (див. лекцію 4). Правда, займаючись реалізацією функціональної специфікації ПС, ми тим самим обговорили основні питання забезпечення критерію функціональності. Оголосивши надійність ПС основним його атрибутом (див. лекцію 1), ми вибрали попередження помилок як основний підхід для забезпечення надійності ПС (див. лекцію 3) і обговорили його втілення на різних етапах розробки ПС. Таким чином, виявлялася теза про обов'язковість функціональності і надійності ПС як критеріїв його якості.
Проте, в специфікації якості ПС можуть бути додаткові характеристики цих критеріїв, забезпечення яких вимагають спеціального обговорення. Цим питанням і присвячена справжня лекція. Забезпечення інших критеріїв якості обговорюватиметься в наступній лекції.
Нижче обговорюються забезпечення примітивів якості ПС, що виражають критерії функціональності і надійності ПС.
11.2. Забезпечення завершеності програмного засобу.
Завершеність ПС є загальним примітивом якості ПС для виразу і функціональності і надійності ПС, причому для функціональності вона є єдиним примітивом (див. лекцію 4).
Функціональність ПС визначається його функціональною специфікацією. Завершеність ПС як примітив його якості є мірою того, в якому ступені ця специфікація реалізована в ПС, що розробляється. Забезпечення цього примітиву в повному об'ємі означає реалізацію кожній з функцій, визначеною у функціональній специфікації, зі всіма вказаними там деталями і особливостями. Всі розглянуті раніше технологічні процеси показують, як це може бути зроблено.
Проте в специфікації якості ПС можуть бути визначені декілька рівнів реалізації функціональності ПС: може бути визначена деяка спрощена (початкова або стартова) версія, яка повинна бути реалізована в першу чергу; можуть бути також визначені і декілька проміжних версій. В цьому випадку виникає додаткове технологічне завдання: організація нарощування функціональності ПС. Тут важливо відзначити, що розробка спрощеної версії ПС немає розробка його прототипу. Прототип розробляється для того, щоб краще зрозуміти умови застосування майбутнього ПС [11.1], уточнити його зовнішній опис. Він розрахований на вибраних користувачів і тому може сильно відрізнятися від необхідного ПС не тільки виконуваними функціями, але і особливостями призначеного для користувача інтерфейсу. Спрощена ж версія ПС, що розробляється, повинна бути розрахована на практично корисне застосування будь-якими користувачами, для яких призначене це ПС. Тому головний принцип забезпечення функціональності такого ПС полягає в тому, щоб із самого початку розробляти ПС таким чином, неначе потрібний ПС в повному об'ємі, доти, коли розробники матимуть справу безпосередньо з тими частинами або деталями ПС, реалізацію яких можна відкласти відповідно до специфікації його якості. Тим самим, і зовнішній опис і опис архітектури ПС повинні бути розроблене в повному об'ємі. Можна відкласти лише реалізацію тих програмних підсистем (визначених в архітектурі ПС, що розробляється), функціонування яких не вимагається в початковій версії цього ПС. Реалізацію ж самих програмних підсистем краще всього проводити методом цілеспрямованої конструктивної реалізації, залишаючи в початковій версії ПС відповідні імітатори тих програмних модулів, функціонування яких в цій версії не потрібне. Допустима також спрощена реалізація деяких програмних модулів, що опускає реалізацію деяких деталей відповідних функцій. Проте такі модулі з технологічної точки зору краще розглядати як своеобразные їх імітатори (хоча і далеко просунуті).
Досягнутий при забезпеченні функціональності ПС рівень його завершеності насправді може бути не таким, як очікувалося, із-за помилок, що залишилися в цьому ПС. Можна лише говорити, що необхідна завершеність досягнута з деякою вірогідністю, визначуваною об'ємом і якістю проведеного тестування. Для того, щоб підвищити цю вірогідність, необхідно продовжити тестування і відладку ПС. Проте, оцінювання такої вірогідності є вельми специфічним завданням, яке поки що чекає відповідних теоретичних досліджень.
11.3. Забезпечення точності програмного засобу.
Забезпечення цього примітиву якості пов'язане з діями над значеннями речових типів (точніше кажучи, із значеннями, що представляються з деякою погрішністю). Забезпечити необхідну точність при обчисленні значення тієї або іншої функції означає набути цього значення з погрішністю, що не виходить за рамки заданих меж. Видами погрішності, методами їх оцінки і методами досягнення необхідної точності (т.з. наближеними обчисленнями) займається обчислювальна математика [11.1, 11.2]. Тут ми лише звернемо увагу на деяку структуру погрішності: погрішність обчисленого значення (повна погрішність) залежить
-
від погрішності використовуваного методу обчислення (у яку ми включаємо і неточність використовуваної моделі)
-
від погрішності представлення використовуваних даних (від т.з. неусувній погрішності)
-
від погрішності округлення (неточності виконання використовуваних в методі операцій).
11.4. Забезпечення автономності програмного засобу.
Питання про автономність програмного засобу вирішується шляхом ухвалення рішення про можливість використання в ПС якого-небудь відповідного базового програмного забезпечення, що розробляється. Надійність базового програмного забезпечення, що є у розпорядженні розробників, для цільового комп'ютера може не відповідати вимогам до надійності ПС, що розробляється. Тому від використання такого програмного забезпечення доводитися відмовлятися, а його функції в необхідному об'ємі доводиться реалізовувати в рамках ПС, що розробляється. Аналогічне рішення доводиться ухвалювати при жорстких обмеженнях на використовувані ресурси (по критерію ефективності ПС). Таке рішення може бути ухвалене вже в процесі розробки специфікації якості ПС, іноді – на етапі конструювання ПС.
11.5. Забезпечення стійкості програмного засобу.
Цей примітив якості ПС забезпечується за допомогою так званого захисного програмування. Взагалі кажучи, захисне програмування застосовується при програмуванні модуля для підвищення надійності ПС в ширшому сенсі. Як затверджує Майерс [11.3], «захисне програмування засноване на важливій передумові: гірше, що може зробити модуль, – це прийняти неправильні вхідні дані і потім повернути невірний, але правдоподібний результат». Для того, щоб цього уникнути, в текст модуля включають перевірки його вхідних і вихідних даних на їх коректність відповідно до специфікації цього модуля, зокрема, повинні бути перевірені виконання обмежень на вхідні і вихідні дані і співвідношень між ними, вказані в специфікації модуля. У разі негативного результату перевірки збуджується відповідна виняткова ситуація. Для обробки таких ситуацій в кінець цього модуля включаються фрагменти другого роду – обробники відповідних виняткових ситуацій. Ці обробники крім видачі необхідній діагностичній інформації, можуть прийняти заходи або по виключенню помилки в даних (наприклад, зажадати їх повторного введення), або по ослабленню впливу помилки (наприклад, щоб уникнути поломки пристроїв, керованих за допомогою даного ПС, при аварійному припиненні виконання програми здійснюють м'яку їх зупинку).
Застосування захисного програмування модулів призводить до зниження ефективності ПС як за часом, так і по пам'яті. Тому необхідно розумно регулювати ступінь застосування захисного програмування залежно від вимог до надійності і ефективності ПС, сформульованих в специфікації якості ПС, що розробляється. Вхідні дані модуля, що розробляється, можуть поступати як безпосередньо від користувача, так і від інших модулів. Найбільш споживаним випадком застосування захисного програмування є застосування його для першої групи даних, що і означає реалізацію стійкості ПС. Це потрібно робити завжди, коли в специфікації якості ПС є вимога про забезпечення стійкості ПС. Застосування захисного програмування для другої групи вхідних даних означає спробу виявити помилку в інших модулях під час виконання модуля, що розробляється, а для вихідних даних модуля, що розробляється, спробу виявити помилку в самому цьому модулі під час його виконання. По суті, це означає часткове втілення підходу самообнаружения помилок для забезпечення надійності ПС, про що йшла мова в лекції 3. Цей випадок захисного програмування застосовується украй рідко тільки у тому випадку, коли вимоги до надійності ПС надзвичайно високі.
11.6. Забезпечення захищеності програмних засобів.
Розрізняють наступні види захисту ПС від спотворення інформації:
-
захист від збоїв апаратури;
-
захист від впливу «чужої» програми;
-
захист від відмов «своєї» програми;
-
захист від помилок оператора (користувача);
-
захист від несанкціонованого доступу;
-
захист від захисту.
11.6.1 Захист від збоїв апаратури. В даний час цей вид захисту є не дуже злободенним завданням (з урахуванням рівня досягнутої надійності комп'ютерів). Але все таки корисно знати її рішення. Це забезпечується організацією т.з. «подвійних або потрійних прорахунків». Для цього весь процес обробки даних, визначуваний ПС, розбивається за часом на інтервали так званими «опорними точками». Довжина цього інтервалу не повинна перевершувати половини середнього часу безвідмовної роботи комп'ютера. На початку кожного такого інтервалу у вторинну пам'ять записується з деякою контрольною сумою копія стану змінної в цьому процесі пам'яті («опорна точка»). Для того, щоб переконатися, що обробка даних від однієї опорної точки до наступної (тобто один «прорахунок») проведена правильно (без збоїв комп'ютера), проводиться два таких «прорахунку». Після першого «прорахунку» обчислюється і запам'ятовується вказана контрольна сума, а потім відновлюється стан пам'яті по опорній точці і робиться другий «прорахунок». Після другого «прорахунку» обчислюється знову вказана контрольна сума, яка потім порівнюється з контрольною сумою першого «прорахунку». Якщо ці дві контрольні суми співпадають, другий прорахунок вважається за правильне, інакше контрольна сума другого «прорахунку» також запам'ятовується і проводиться третій «прорахунок» (з попереднім відновленням стану пам'яті по опорній точці). Якщо контрольна сума третього «прорахунку» співпаде з контрольною сумою одного з перших двох «прорахунків», то третій прорахунок вважається за правильне, інакше потрібна інженерна перевірка комп'ютера.
11.6.2. Захист від впливу «чужої» програми. При появі мультипрограмного режиму роботи комп'ютера в його пам'яті може одночасно знаходитися у стадії виконання декілька програм, поперемінно одержуючих управління в результаті виникаючих переривань (т.з. квазіпаралельне виконання програм). Одна з таких програм (зазвичай: операційна система) займається обробкою переривань і управлінням мультипрограмним режимом. Тут під «чужою» програмою розуміється програма (або який-небудь програмний фрагмент), що виконується паралельно (або квазіпаралельний) по відношенню до програми, що захищається (або її фрагменту). Цей вид захисту повинна забезпечити, щоб ефект виконання програми, що захищається, не залежав від того, які програми виконуються паралельно з нею, і відноситься, перш за все, до функцій операційних систем.
Розрізняють два різновиди цього захисту:
-
захист від відмов «чужої» програми
-
захист від зловмисного впливу «чужої» програми.
Захист від відмов «чужої» програми означає, що на виконання функцій програмою, що захищається, не впливатимуть відмови (прояви помилок), що виникають в паралельно виконуваних програмах. Для того, щоб програма (операційна система), що управляє, могла забезпечити захист себе і інших програм від такого впливу, апаратура комп'ютера повинна реалізовувати наступні можливості:
-
захист пам'яті
-
два режими функціонування комп'ютера: привілейований і робочий (призначений для користувача)
-
два види операцій: привілейовані і ординарні
-
коректну реалізацію переривань і початкового включення комп'ютера
-
тимчасове переривання.
Захист пам'яті означає можливість програмним шляхом задавати для кожної програми недоступні для неї ділянки пам'яті. У привілейованому режимі можуть виконуватися будь-які операції (як ординарні, так і привілейовані), а в робочому режимі тільки ординарні. Спроба виконати привілейовану операцію, а також звернутися до захищеної пам'яті в робочому режимі викликає відповідне переривання. До привілейованих операцій відносяться операції зміни захисту пам'яті і режиму функціонування, а також доступу до зовнішнього інформаційного середовища. Коректна реалізація переривань і початкового включення комп'ютера означає обов'язкову установку привілейованого режиму і відміну захисту пам'яті. У цих умовах програма (операційна система), що управляє, може повністю захистити себе від впливу відмов інших програм. Для цього достатньо, щоб
-
всі точки передачі управління при початковому включенні комп'ютера і при перериваннях належали цій програмі
-
вона не дозволяла ніякий іншій програмі працювати в привілейованому режимі (при передачі управління будь-якій іншій програмі повинен включатися тільки робочий режим)
-
вона повністю захищала свою пам'ять (що містить, зокрема, всю її інформацію, що управляє, включаючи так звані вектора переривань) від інших програм.
Тоді ніхто не перешкодить їй виконувати будь-які реалізовані в ній функції захисту інших програм (у тому числі і доступу до зовнішнього інформаційного середовища). Для полегшення рішення цієї задачі частина такої програми поміщається в постійну пам'ять. Наявність тимчасового переривання дозволяє програмі, що управляє, захиститися від зациклення в інших програмах (без такого переривання вона могла б просто позбутися можливості управляти).
Захист від зловмисного впливу «чужих» програм означає, що зміна зовнішнього інформаційного середовища, наданій програмі, що захищається, з боку іншої, паралельно виконуваної програми буде неможливе або сильно утруднене без відома програми, що захищається. Для цього операційна система повинна забезпечити відповідний контроль доступу до зовнішнього інформаційного середовища. Необхідною умовою забезпечення такого контролю є забезпечення захисту від зловмисного впливу «чужих» програм хоч би самої операційної системи. Інакше такий контроль можна було б обійти шляхом зміни операційної системи з боку «зловмисної» програми.
Цей вид захисту включає, зокрема, і захист від т.з. «комп'ютерних вірусів», під якими розуміють фрагменти програм, здатні в процесі свого виконання упроваджуватися (копіюватися) в інші програми (або в окремі програмні фрагменти). «Комп'ютерні віруси», володіючи здібністю до розмноження (до впровадження в інші програми), за певних умов викликають зміну ефекту виконання «зараженої» програми, що може привести до серйозних деструктивних змін її зовнішнього інформаційного середовища. Операційна система, будучи захищеною від впливу «чужих» програм, може обмежити доступ до програмних фрагментів, що зберігаються в зовнішньому інформаційному середовищі. Так, наприклад, може бути заборонене зміна таких фрагментів будь-якими програмами, окрім деяких, які знає операційна система, або, інший варіант, може бути дозволено тільки після спеціальних підтверджень програми (або користувача).
11.6.3. Захист від відмов «своєї» програми. Забезпечується надійністю ПС, на що орієнтована вся технологія програмування, що обговорюється в справжньому курсі лекцій.
11.6.4. Захист від помилок користувача. Тут йде мова не про помилкові дані, що поступають від користувача ПС, захист від них пов'язаний із забезпеченням стійкості ПС, а про дії користувача, що приводять до деструктивної зміни стану зовнішнього інформаційного середовища ПС, не дивлячись на коректність використовуваних при цьому даних. Захист від таких дій, частково, забезпечується видачею попереджувальних повідомлень про спроби змінити стан зовнішнього інформаційного середовища ПС з вимогою підтвердження цих дій. Для випадків же, коли такі помилки здійснюються, може бути передбачена можливість відновлення стану окремих компонент зовнішнього інформаційного середовища ПС на певні моменти часу. Така можливість базується на веденні (формуванні) архіву станів (або змін стану) зовнішнього інформаційного середовища.