
- •Перелік термінів та позначень
- •Передмова
- •Частина 1. Початок програмування в срср. Витоки розвитку
- •1.1. Поява і розвиток технології програмування (1952–2012)
- •1.2. Формування технологічних напрямів (1965–1975)
- •1.3. Становленья технології програмування (1975–1982)
- •1.4. Розвиток інтерфейсу в технології програмування (1976–1992)
- •1.5. Розвиток об’єктної технології програмування (1992–2002)
- •1.6. Індустріальні основи технології програмування (2002–2012)
- •1.7. Навчання тп у кну Тараса Шевченко (1965–2012) та філії мфті (2000–2012)
- •Контрольні питання і завдання до частини 1
- •Список літератури до частини 1
- •Частина 2. Парадигми технології програмування
- •2.1. Модульне програмування та збиральний підхід
- •2.1.1. Інтерфейс в програмуванні
- •2.1.2. Зборка модулів по а.П.Єршову
- •2.1.3. Метод зборки готових програмних елементів
- •2.1.4. Формальне подання методу збирання різномовних модулів
- •2.2. Парадигма об’єктно-орієнтованого програмування
- •2.2.1. Базові концепції ооп
- •2.2.2. Чотирьох рівневе проектування ом
- •2.2.3. Концепції об’єктного аналізу
- •2.2.4. Функції, алгебра та операції об’єктного аналізу
- •2.2.5. Моделювання моделі ПрО
- •2.2.6. Опис параметрів інтерфейсу ом
- •2.3. Парадигма uml-метода моделювання
- •2.3.1 Основні діаграми методу
- •2.3.2. Моделювання поведінки системи
- •2.3.3. Побудова пс засобами uml
- •2.4. Парадигма компонентного програмування
- •2.4.1. Теоретичні аспекти компонентного програмування
- •2.4.2. Моделі компонентного програмування
- •2.4.3. Графове подання компонентної моделі ПрО
- •2.4.4. Об’єднання компонентів. Модель середовища
- •2.4.5. Компонентна алгебра
- •2.4.6. Іінструментальні засоби кп
- •2.4.7. Технологія компонентної розробки пс
- •2.4.8. Типізація і класифікація програмних компонентів
- •2.4.9. Жц проектування пс із типових компонентів та кпв
- •Розробка вимог до пс – це формування та опис функціональних, технологічних, організаційних та ін. Властивостей програмної системи, які необхідні чи бажані з точки зору кінцевого користувача.
- •Розгортання рпс. У випадку, коли рпс створюється для конкретного замовника, який є і користувачем, то деякі завдання розгортання виконуються на попередніх етапах. До них, зокрема, відносяться:
- •Супровід рпс компонентній пс характеризується наступними особливостями.
- •2.5. Парадигма аспектно-орієнтованого програмування
- •2.5.1.Основні елементи парадигми аоп
- •2.5.2. Засоби аоп
- •2.5.3. Підтримка аоп впродовж життєвого циклу пс
- •2.5.5. Методичні аспекти аоп
- •2.6. Парадигма генерувального програмування
- •2.6.1 Предметно-орієнтована мова – dsl
- •2.6.2. Простір проблем і рішень ПрО
- •2.6.3. Інженерія ПрО і кпв
- •2.7. Сервісно-орієнтоване програмування
- •2.7.1 Базові понятті сервісу Інтернет
- •2.7.2. Сервіси wcf мs.Net з контрактами
- •2.8. Парадигми теоретичного програмування
- •2.8.1 Алгебраїчне та інсерційне програмування
- •2.8.2. Реалізація агентних програм
- •2.8.3. Експлікативне, номінативне програмування
- •2.8.4. Алгоритмічні алгебри
- •Контрольні питання і завдання до частини 2
- •Список літератури до частини 2
- •Частина 3. Моделі і засоби проектування предметних областей
- •3.1. Моделі проектування ПрО предметних областей
- •3.1.1. Концептуальні моделі пс, спс за компонентами
- •3.1.2. Моделі взаємозв’язку об’єктів
- •3.1.3. Модель інтеграції (зборка) компонентів
- •3.1.4. Тестування прикладних і інтерфейсних об'єктів
- •3.1.5. Моделі взаємодії і варіабельності пс для організації обчислень
- •3.1.6. Підхід до виконання пс в сучасних розподілених середовищах
- •3.2. Онтологічний підхід до подання знань про проблемні області
- •3.2.1. Онтологічне моделювання проблемної області
- •3.2.2. Мовний опис онтології домену чи спс
- •3.2.3. Підхід до реалізація онтології ПрО
- •3.3. Типи даних та засоби їх генерації для використання в збиральному прогрмуванні
- •3.3.1. Проблема забезпечення сумісності типів даних при зборки кпв
- •3.3.2. Аксіоматика простих типів даних
- •3.3.3. Аксіоматика структурних і складних типів даних. Структурні типи даних.
- •3.3.4. Семантичні аспекти взаємодії різнорідних програм
- •3.3.5. Характеристика типів даних для зборки програм
- •3.3.6. Фундаментальні і загальні типи даних
- •3.3.6. Баові поняття стандарту з типів даних
- •3.3.7. Перебудова загальних типів даних до фундаментальних для мп
- •3.4. Підходи і методи доказу програм
- •3.4.1. Мови специфікації програм –vdm, raise, Concept
- •3.4.2. Концепторна мова специфікації
- •3.4.3. Методи доведення правильності програм
- •3.4.4. Модель доказу програми за твердженнями
- •З.5. Проектування пс засобами жц з реалізації доменів
- •3.4.1. За загальна характеристика стандарту жц iso/iec 12207:2002
- •3.4.2. Формування конкретних моделей життєвого циклу
- •3.4.3. Підходи до моделювання ПрО мовними засобами dsl
- •3.6. Модель якості пс
- •3.6.1. Структура моделі якості
- •3.6.2. Модель витрат сосомо Боєма
- •3.6.3. Інтегрована модель витрат на спс
- •Контрольні питання і завдання до частини 3
- •Список літератури до частини 3
- •Частина 4. Методи індустрії виробицтва програм і систем
- •4.1. Загальні основи методології виробництва пс і спс
- •4.1.1. Моделі взаємодії компонентів у пс
- •4.1.2 Методологічні аспекти виробництва спс з готових ресурсів
- •4.2. Мова опису моделей взаємодії на основі xml
- •4.2.1 Подання та обмін даними в компонентних моделях
- •4.2.3 Модель конфігурації компонентів на основі xml
- •4.3. Графове подання пс і спс
- •4.3.1 Графове визначення моделі взаємодії об'єктів
- •4.3.2 Типи зв’язків об’єктів у графової моделі ПрО
- •4.4. Розробка методів побудови проблемно-орієнтованих технологій
- •4.4.1. Аналіз динаміки розвитку фабрик програм
- •4.3.2. Базисні ресурси фабрики програм
- •4.5. Загальні лінії виробництва програм з кпв
- •4.4.1. М етодологія побудови тл
- •4.4.2. Нові дисципліни індустрії наукового совтвера
- •4.4.3. Новітні засоби Grid і Cloud для обчислення задач e–sciences
- •4.4.4. Сучасні системи побудови рпс з сервісних ресурсів
- •4.4.5. Методологія розроблення тл
- •4.4.6. Принципи проектування іс
- •4.5. Методи при оцінюванні економічних характеристик проектів
- •4.5.2. Формальний апарат експертно-аналітичного оцінювання об’єктів і процесів у спс
- •4.5.3. Методи оцінки розміру
- •4.6. Створення Windows застосувань
- •4.6.1. Створення нової програми.
- •4.6.2. Властивості і дизайн програм
- •4.6.3. Компіляція програм
- •2.5. Запуск застосунка
- •4.6.4. Розширення функціональності програм
- •4.7. Інженерії тестування програмних систем
- •4.7.1. Основні поняття інженерії тестування
- •4.7.2 Становлення інженерії тестування
- •4.7.3. Методи тестування. Метрики і критерії
- •4.7.4. Інструменти тестування та оцінювання
- •4.7.5. Тестування веб-застосувань
- •Контрольні питання і завдання до частини 4
- •Список літератури до частини 4
- •5.2. Фабрика програм в кну
- •5.2.3. Створення фабрики студентів
- •5.2.4. Лінії продуктів фабрики на головної сторінки
- •5.2.5. Принципи роботи з репозиторієм програм і артефактів
- •5.2.6. Навчання дисципліні “Програмна інженерія” на фабрики
- •5.3. Репозиторій кпв
- •5.3.1. Загальний опис репозиторію
- •5.3.2. Технологія обслуговування репозиторію кпв
- •5.4. Розробка кпв
- •5.4.1. Опис моделей кпв, інтерфейсу і операцій розробки кпв
- •5.4.2. Реалізація побудови компонентної системи
- •5.4.3. Процеси технології оброблення кпв
- •5.4.4. Зборка різномовних програм у середовищі Visual Studio
- •5.5. Конфігурація кпв
- •5.5.1. Конфігурування кпв з урахуванням варіабельності
- •5.5.2. Опис прикладу використання конфігуратору програм
- •5.6. Генерація систем мовою dsl
- •5.6.1. Лінія опису та генерації доменів dsl
- •5.6.2. Опис життєвого циклу пз та його реалізації на мові dsl
- •2.7. Онтологія – обчислювальна геометрія
- •5.7.1. Онтологія домену – Обчислювальна геометрія
- •5.7.3. Опис моделі онтології ПрО «Обчислювальна геометрія»
- •5.7.4. Опис програми домену «Обчислювальна геометрія» мовою owl
- •5.8. Оцінка якості пс
- •5.8.2. Оцінка витрат на продукт
- •5.8.3. Опис модуля прогнозування трудовитрат на розробку пс
- •5.8.4. Приклад оцінювання затрат на розробку пс ас
- •5.9.1. Опис веб-технології Java ee
- •5.9.3. Приклад взаємодії Java і ms.Net через веб-сервіси
- •5.9.4. Інструкція по використанню графічного інтерфейсу прикладу
- •5.10. Генерація тд
- •5.10.1. Відображення типів даних у середовищі ітк
- •5.10.2. Система генерації загальних типів даних до фундаментальних
- •5.11. Інструментальні засоби сайта ітк
- •5. 12. Розділ сайта «Технологія навчання»
- •Контрольні питання і завдання до частини 5
- •Список літератури до частини 5
- •Післямова
- •Додаток 1. Парадигма структурного програмування
- •Додаток 2. Приклад створення служб wcf у ms Visual Studio 2010
- •Додаток 3. Онтологічний підхід з подання тестування кпв та пс
- •Додаток 4. Оцінка застосування метода сосомо на конкретних даних
- •Додаток 5. Програма курсу «Технологія програмування іс»
3.6.1. Структура моделі якості
Розгляд базових характеристик моделі якості.
Функціональність – сукупність властивостей, визначальних здатність системи надавати необхідну безліч функцій для вирішення задач відповідно до вимог. В моделі якості ця характеристика задається набором атрибутів q1 = {a11, a12, a13, a14, a15, a16}, семантика і оцінка яких приведена нижче.
a11 : функціональна повнота – властивість компоненту, яка показує ступінь достатності реалізованих в ньому функцій для вирішення задач у відповідності з його призначенням. Даний атрибут можна уявити у вигляді відношення всіх реалізованих функцій F з в компонентній системі (с), до функцій F т, заданих у вимогах (т):
;
a12 : коректність – атрибут, який указує на ступінь відповідності кожної функції F т, заданої у вимозі, і кожної функції F з, реалізованій в компонентній системі. При цьому система володіє властивістю коректності, якщо F т = F з та і часткової коректності, якщо F т F з. Для більшості систем достатньо часткової коректності. Ступінь коректності компоненту можна визначити, як ступінь функціональної коректності за формулою:
= 1– (card ( F т / F з ) /card F т.
a13 : точність – властивість, визначальна отримання системою злагоджених результатів з необхідним ступенем точності. Даний атрибут може оцінюватися відношенням різниці значення функції Fсі (Di) компоненту і значення функції Fті (Di), заданої вимогами на Di вхідному наборі до значення функції відповідно до виразу:
;
a14 : интероперабельність – властивість компоненту системи взаємодіяти з іншими компонентами і операційним середовищем;
a15 : захищеність – атрибут, який показує можливість компоненту (системи) фіксувати дефекти, які є слідством суб'єктивних помилок в його реалізації або викликані програмними або апаратними засобами при виконанні, а також помилок, пов'язаних з даними. Оцінку ступеня захищеності можна привести за допомогою виразу a15 = falz / fal, де falz – кількість дефектів, від яких компонент захищений; fal – загальна кількість дефектів в компонентах або ПС;
a16 : узгодженість – атрибут, який показує ступінь дотримання стандартів, правил і інших угод процесу розробки, і оцінюється експертне. Потім отримані якісні оцінки нівелюються відповідними ваговими коефіцієнтами.
Таким чином, характеристика функціональність q1 обчислюється підсумовуванням її атрибутів з урахуванням метрик і їх вагових коефіцієнтів:
.
Надійність ПС будемо визначати як вірогідність того, що компоненти системи або сама система функціонують безвідмовно протягом фіксованого періоду часу в заданих умовах операційного оточення/середовища. В моделі якості надійність задається на безлічі атрибутів q2 = {a21, a22, a23, a24}, які визначають здатність} системи перетворювати початкові дані в результати при умовах, залежних від періоду часу життя системи (знос і старіння не ураховуються).
Зниження надійності компонентів відбувається через помилки у вимогах, проектуванні і виконанні. Відмови і помилки в програмних компонентах можуть з'являтися на заданому проміжку часу функціонування компоненту/системи [26–30]. Розглянемо властивості кожного атрибута надійності.
a21: безвідмовність – властивість системи, яка визначає функціонування системи без відмов (програмних компонентів або устаткування). Якщо компонент містить дефект, викликаний суб'єктивними помилками при розробці, то в множині D={DeeL} всіх дефектів, можна виділити підмножину ED, для якого результати не відповідають функції Fт, заданій у вимогах на розробку. Вірогідність р безвідмовного виконання компоненту на De, випадково вибраному з D серед рівно імовірних, рівна:
р = 1– (card (E) / card (D)).
Відмова (failure) показує відхилення поведінки системи від того, що наказав і система перестає виконувати функції, що наказали їй. Крім того, поява відмови може бути причиною помилки (fault/ error), викличної його.
Якщо помилка зроблена людиною, то використовується термін mistake. Коли відмінність між fault і failure не є критичною, використовується термін defect, який означає або fault (причина), або failure (дія). Зв'язок між цими поняттями можна уявити так: fault error failure.
Існує велика різноманітність видів відмов ПО, типові з них: раптові, поступові, переміщаються (збої). Причини відмов можуть бути фізичні, структурними, відмови взаємодії і ін. Вони можуть виникати природним шляхом, вноситися людиною або зовнішнім операційним середовищем в період створення або експлуатації системи, а також бути постійними або носити тимчасовий характер.
Напрацювання на відмову як атрибут надійності визначає середній час між появою загроз, що порушують безпеку, і забезпечує важко вимірну оцінку збитку, яка наноситься відповідними загрозами.
Для обчислення середнього часу Т напрацювання на відмову застосовується формула
,
де tiE – інтервал часу безвідмовної роботи компоненту і-го відмови; N – кількість відмов в системі.
a22 : стійкість до помилок – властивість компонентів системи, яка показує на здатність програмної системи виконувати функції при аномальних умовах (збоях апаратури, помилках в даних і інтерфейсах, порушеннях в діях оператора і ін.). Оцінку стійкості можна отримати по формулі
= Nv/N
де Nv – кількість різних типів відмов, для яких передбачені засоби відновлення; N – загальна кількість всіх відмов в системі.
a23 : відновлюваність – властивість системи, яка указує на здатність відновлювати функціонування системи після відмов і відновлювати в ній пошкоджені компоненти чи дані для повторного виконання. Середній час відновлення компоненту можна визначити по формулі
,
де tib – час відновлення працездатності компоненту після і-го відмови; D – кількість дефектів і відмов в системі.
a24: узгодженість – атрибут, який відображає ступінь дотримання стандартів, технології, правил і інших угод на стадіях розробки і тестування системи для пошуку різного роду помилок розробки. Цей атрибут оцінюється експертами, вони фіксують помилки в спеціальних картах і дають експертну оцінку надійності системи.
Деякі типи систем реального часу, безпеки і інші вимагають високої надійності (неприпустимість помилок, точність, достовірність і ін.), яка в значній мірі залежить від кількості помилок, що залишилися і не усунених, в процесі її розробки на етапах життєвого циклу. В ході експлуатації помилки також можуть виявлятися і усуватися. Якщо при їх виправленні не вносяться нові або вноситься їх менше ніж усувається, то в ході експлуатації надійність системи безперервно зростає. Чим інтенсивніше проводиться експлуатація, тим інтенсивніше виявляються помилки і швидше росте надійність. До чинників, що впливають на надійність ПО, відносяться:
– загроза порушення безпеки системи;
– сукупність загроз, що приводять до порушення системи або середовища і ін.
Надійність постійно вивчається і розвивається. Новий її напрям – інженерія надійності ПО (Software reliability engineering – SRE), яка орієнтована на рішення наступних задач [20, 28]:
1) вимірювання надійності, тобто проведення її кількісної оцінки за допомогою прогнозів, збору даних про поведінку системи в процесі експлуатації і сучасних моделей надійності;
2) розробка стратегії, метрик конструювання готових компонентів і компонентної системи в цілому, а також визначення середовища функціонування, що забезпечує надійність роботи системи;
3) застосування сучасних методів інспекції, верифікації, валидації тестуванні ПС в процесі розробки, а також при експлуатації.
Практично оцінка надійності ПО є трудомістким процесом, в ньому важливе місце займає метод визначення стійкості системи до відмов ПО, тобто вірогідність того, що система відновиться мимовільно в деякій крапці після виникнення в ній відмови (fault).
Кількісна оцінка характеристики надійності системи по всіх її розглянутих кількісних атрибутах і відповідних метриках має вигляд
Зручність застосування – ця множина властивостей ПС, які показують на необхідні і придатні умови її використовування (в діалозі або без) довкола користувачів для отримання результатів виконання. Ця характеристика в моделі якості визначається на множині атрибутів, які задовольняють ергономічності, і включають атрибути:
a31 : розумність означає зусилля, затрачуване на розпізнавання логічних концепцій і умов застосування ПС;
a32 : вивченість означає зусилля користувачів при визначенні застосовності ПО за допомогою операційного контролю введення, висновку, діагностики, а також процедур аналізу документації;
a33: оперативність – реакція системи при виконанні операторів і операційного контролю;
a34: узгодженість – відповідність ПС вимогам стандартів, угод, правил, законів і розпоряджень.
Всі атрибути оцінюються експертами, які залежно від їх рівня знань, дають відповідні якісні значення.
Кількісна оцінка даної характеристики залежить від оцінок експертів, кількісного атрибута a33 і має вигляд:
Ефективність – безліч атрибутів – властивостей системи, які показують взаємозв'язок між рівнем її виконання, кількістю використовуваних ресурсів (апаратури, витратних матеріалів і ін.), послуг штатного обслуговуючого персоналу і ін.
До них відносяться:
a41 : реактивність – час відгуку, обробки і виконання функцій компоненту/системи;
a42 : ефективність – кількість використовуваних ресурсів при виконанні функцій ПС і тривалість їх обчислень;
a43 : узгодженість – відповідність даного атрибута заданим стандартам, правилам і розпорядженням.
Кількісна оцінка даної характеристики по всіх розглянутих якісних і кількісно виміряються атрибутах оцінюється експертне і аналітично з урахуванням відповідних метрик і має вигляд
Сопровождаємість – безліч властивостей, які відображають зусилля, затрачувані на проведення модифікацій (коректування, удосконалення і пристосовування) при зміні середовища виконання, вимог або специфікацій. Дана характеристика в моделі якості складається з наступних атрибутів:
a52 : анализовність – необхідні зусилля для діагностики відмов в ПС або ідентифікації частин, які будуть модифікуватися;
a53 : змінність – зусилля, які затрачуються на модифікацію компоненту, видалення помилок або внесення змін, доповнення нових можливостей в систему або середовище функціонування;
a54 : стабільність – ризик проведення модифікації компоненту /системи;
a53 : тестуємість – зусилля при проведенні верифікації в цілях виявлення помилок і невідповідностей вимогам (валидація), а також на необхідність виправлення знайдених помилок і проведення сертифікації системи;
a54 : узгодженість – відповідність даного атрибута певним стандартам, угодам, правилам і розпорядженням.
Кількісна оцінка даної характеристики по всіх її атрибутах, що виміряються експертне і аналітично з урахуванням відповідних метрик, має вигляд
Переносність – множина атрибутів, вказуючих на можливість компонентів системи пристосовуватися до роботи в нових умовах середовища виконання: організаційній, апаратній і програмній. Перенесення компонентів або всієї системи на іншу платформу або середовище пов'язано з сукупністю дій, направлених на забезпечення можливості функціонування в новому середовищі, відмінному від тієї, в якій система створювалося. До атрибутів даної характеристики згідно моделі якості відносяться:
a61 : адаптивна – зусилля, затрачувані на пристосовування системи до різних операційних середовищ. Цей атрибут можна уявити у вигляді a61 = Za / Zd, де Za – витрати на пристосовування до нового операційного середовища; Zd – витрати на розробку нової системи для нового операційного середовища;
a62 : настроюваність визначає необхідні зусилля для запуску або інсталяції програмного продукту в іншому середовищі;
a63 : співіснування – можливість використовування спеціального ПО в середовищі діючої системи;
a64 : змінюваність – можливість взаємодії (інтероперабельності) з іншими програмами при спільній їх роботі і інсталяції або пристосовуванні системи;
a65 : узгодженість – відповідність стандартам або угодам і правилам перенесення програмної системи в інше середовище.
Кількісна оцінка даної характеристики по атрибутах, експертним і аналітичним шляхом, що виміряється, з урахуванням відповідних метрик, має вигляд
Комплексна оцінка. На основі зміряних кількісних характеристик і проведення експертизи якісних показників з визначенням вагових коефіцієнтів, що нівелюють різні показники, обчислюється підсумкова оцінка якості продукту шляхом підсумовування результатів по окремих показниках і порівняння їх з еталонними показниками ПС.
Якщо у вимогах до ПС було встановлено декілька показників, то прорахований кожний показник умножається на відповідний ваговий коефіцієнт, а потім все підсумовується по всіх показниках. В результаті виходить інтегральна оцінка рівня якості ПС.
У формулах оцінювання показників якості окремого компоненту наведені метрики ai А, вагові коефіцієнти wi W для кожного атрибута. Отримані значення qj за допомогою вагових коефіцієнтів wi W приведені до єдиної системи вимірювання. Використовуючи отримані оцінки qj характеристик якості стосовно окремого компоненту (соm), одержуємо інтегральну оцінку якості одного компоненту у вигляді
.
Якщо програмна система містить N-компонентів і для них проведена кількісна оцінка, то маємо остаточну комплексну оцінку якості системи (sys):
.
Таким чином, даний підхід до аналітичної оцінки атрибутів показників якості ПС дозволяє отримати кількісну оцінку якості готового програмного продукту.