
- •Технологія проектування програмних систем методичні вказівки
- •(Магістри)
- •7.050102.01, 8.050102.01 «Комп’ютерні системи та мережі»
- •7.050102.02, 8.050102.02 «Системне програмування»
- •1. Опис навчальної дисципліни
- •2. Тематика і зміст лекцій
- •3. Практичні заняття по дисципліні "Технологія проектування програмних систем"
- •4. Шкала оцінювання
- •5. Оцінка успішності в балах при повному виконанні умов і графіку навчального процесу
- •Лабораторна робота № 1
- •Моделі процесу створення пз
- •2. Ітераційні моделі розробки пз
- •3. Специфікація програмного забезпечення
- •4. Проектування і реалізація пз
- •Атестація програмних систем
- •6. Еволюція програмних систем
- •7. Автоматизовані засоби розробки пз
- •Лабораторна робота № 2
- •Функціональні і нефункціональні вимоги
- •2. Користувацькі вимоги
- •Додавання структурних елементів у схему
- •Редактор повинен мати засіб, що надає користувачеві можливість додавати в схему нові структурні елементи обраного типу
- •3. Системні вимоги
- •4. Документування системних вимог
- •4. Додатки
- •5. Покажчики
- •Лабораторна робота № 3
- •1. Прототипування в процесі розробки пз
- •2. Технології швидкого прототипування
- •3. Прототипування користувацьких інтерфейсів
- •Лабораторна робота № 4
- •1. Формальні специфікації в процесі розробки пз
- •2. Специфицирование інтерфейсів
- •3. Специфікація поведінки систем
- •Лабораторна робота № 5
- •1. Проектування систем
- •2. Керуючі програми
- •3. Системи спостереження і керування
- •4. Системи збору даних
1. Формальні специфікації в процесі розробки пз
Визначено три рівні специфікації програмного забезпечення. Це користувацькі і системні вимоги і специфікація структури програмної системи. Користувацькі вимоги найбільш узагальнені, специфікація структури найбільш детальна. Формальні математичні специфікації перебувають десь між системними вимогами і специфікацією структури. Вони не містять деталей реалізації системи, але повинні представляти її повну математичну модель.
У міру розробки специфікації участь замовника зменшується, а участь підрядників і безпосередньо розробників ПЗ зростає. На ранніх стадіях розробки специфікація повинна бути “орієнтована на замовника” і написана так, щоб він міг її зрозуміти. Однак на заключній стадії процесу розробки повинна бути отримана специфікація, в основному призначена для підрядників і розробників ПЗ, оскільки вона буде бути основою для реалізації системи. Ця кінцева специфікація може бути формальною.
На рис. 6.1 показані етапи розробки специфікації ПЗ і їх взаємозв'язку із процесом проектування. Етапи розробки специфікації, показані на рис. 6.1, не є незалежними і не обов'язково розробляються в наведеній послідовності. На рис. 6.2 показано, що розробка специфікації і проектування можуть виконуватися паралельно, коли інформація від етапів розробки специфікації передається до етапів проектування і навпаки.
Рис. 6.1. Розробка специфікації і проектування
Рис. 6.2. Розробка формальної специфікації
Створення формальної специфікації вимагає детального аналізу системи, яка дозволяє виявити помилки і невідповідності в специфікації неформальних вимог. Ця можливість виявлення помилок ‒ найбільш важливий аргумент для використання формальної специфікації. Проблеми у вимогах, які залишаються невиявленими до останніх стадій процесу розробки ПЗ, зазвичай вимагають більших витрат на виправлення.
Розробка і аналіз формальної специфікації вимагають додаткових витрат. На рис. 6.3 показана вартість створення ПЗ при розробці формальної специфікації і без неї. При звичайному процесі розробки ПЗ вартість атестації системи становить близько 50% усієї вартості розробки, а вартість проектування і реалізації системи у два рази більше вартості розробки специфікації. При використанні формальної специфікації вартості розробки специфікації і реалізації системи порівнянні, а вартість атестації значно знижується, оскільки в процесі розробки формальної специфікації виявляються і усуваються недоробки у вимогах, тим самим виключається переробка системи на останніх стадіях її створення.
Існує два основні підходи до розробки формальної специфікації, які використовуються для написання деталізованих специфікацій нетривіальних програмних систем.
Алгебраїчний підхід, при якому система описується в термінах операцій і їх відносин.
Підхід, орієнтований на моделювання, при якому модель системи будується з використанням математичних конструкцій, таких, як множини і послідовності, а системні операції визначаються тим, як вони змінюють стани системи.
Рис. 6.3. Вартість розробки ПЗ з формальною специфікацією
Для розробки формальних специфікацій послідовних і паралельних систем у цей час створено кілька мов, представлених у табл. 6.1. Наведені далі приклади показують, як побудова формальних специфікацій приводить до точних і деталізованих специфікацій, але тут не обговорюються мови розробки специфікацій і методи специфікування.
Таблиця 6.1. Мови розробки формальних специфікацій
-
Тип мови
Послідовні системи
Паралельні системи
Алгебраїчний
Larch, OBJ
Lotos
Заснований на моделях
Z, VDM, В
CSP, мережі Петри