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


Захищеність (defensiveness) - властивість, що характеризує здатність ПП протистояти навмисним або ненавмисним деструктивним (руйнівним) діям користувача.
Що таке атестація програмного продукту?

Завершуючим етапом розробки ПП є атестація ПП, що підводить підсумок всій розробці. Атестація (certification) ПП - це авторитетне підтвердження якості ПП [14.5, 14.6]. Зазвичай для атестації ПП створюється атестаційна комісія з експертів, представників замовника і представників розробника. Ця комісія проводить приймально-здавальні випробування ПП з метою отримання необхідної інформації для оцінки його якості. Під випробуванням ПП тут розуміють [14.6, 14.7] процес проведення комплексу заходів, що досліджують придатність ПП для успішної його експлуатації (застосування і супроводи) відповідно до вимог замовника. У цьому процесі перевіряється повнота і досліджується якість представленої програмної документації, проводиться необхідне тестування програм, що входять до складу ПП, а також досліджуються і інші властивості ПП, що декларують в його специфікації якості. На основі отриманої інформації комісія повинна встановити, в якому ступені ПП виконує функції, що декларують, і в якому ступені ПП володіє примітивами, що декларують, і критеріями якості. Вирішення атестаційної комісії про проведену оцінку якості ПП фіксується у відповідному документі (сертифікаті), який підписується членами комісії
Що таке комунікабельність програмного продукту?

Комунікабельність (communicativeness) - властивість, що характеризує ступінь, в якій ПП полегшує завдання або опис вхідних даних, і здатність видавати корисні відомості достатньо простий формі і з простим для розуміння змістом.

4.6. Що таке функціональна специфікація ПП?

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


Функціональна специфікація складається з трьох частин:

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

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

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

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

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

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

У чому полягає суть об'єктного підходу до розробки програмних продуктів?

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

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

Функціональна специфікація складається з трьох частин:

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

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

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

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

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


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

Що таке об'єктна модель програмного продукту?
Що таке архітектура програмного продукту?

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

Основні завдання розробки архітектури ПП:

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

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

З урахуванням ухвалюваних на цьому етапі рішень проводиться подальша конкретизація і функціональних специфікацій.
Що таке динамічна модель програмного продукту?

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

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

Що таке архітектурна функція?

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

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

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

Що таке програмний модуль?

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

Модульне програмування є втіленням в процесі розробки програм обох загальних методів боротьби з складністю (див. лекцію 3, п. 3.5): і забезпечення незалежності компонент системи, і використання ієрархічних структур. Для втілення першого методу формулюються певні вимоги, яким повинен задовольняти програмний модуль, тобто виявляються основні характеристики «хорошого» програмного модуля. Для втілення другого методу використовують деревовидні модульні структури програм (включаючи дерева із зрощеними гілками).
Що таке компонент програмного продукту?

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

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


Не всякий програмний модуль сприяє спрощенню програми [7.2]. Виділити хороший з цієї точки зору модуль є серйозним творчим завданням. Для оцінки прийнятності виділеного модуля використовуються деякі критерії. Так, Хольт [7.4] запропонував наступні два загальних таких критерію:

хороший модуль зовні простіше, ніж усередині;

2 хороший модуль простіше використовувати, чим побудувати.

Майерс [7.5] пропонує для оцінки прийнятності програмного модуля використовувати конструктивніші його характеристики:

розмір модуля

· міцність модуля

· зчеплення з іншими модулями

· рутинна модуля (незалежність від передісторії звернень до нього).

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

Міцність модуля - це міра його внутрішніх зв'язків. Чим вище міцність модуля, тим більше зв'язків він може заховати від зовнішньої

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


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

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

У модульних мовах програмування як мінімум є засоби для завдання функціонально міцних модулів (наприклад, модуль типу FUNCTION в мові ФОРТРАН). Засоби ж для завдання інформаційно міцних модулів в ранніх мовах програмування були відсутні. Ці засоби з'явилися тільки в пізніших мовах. Так в мові програмування АДА засобом завдання інформаційно міцного модуля є пакет [7.6].



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