
- •Лекція 1. Тема: ядра знань swebok
- •1.1. Аналіз і характеристика областей знань swebok
- •1.1.1 Основи програмних вимог (Software Requirements)
- •1.1.2. Проектування пз (Software design)
- •1.1.3. Конструювання пз (Software Construction)
- •1.1.4 Тестування пз (Software Testing)
- •1.1.5 Супровід пз (Software maintenance)
- •1.1.6. Управління конфігурацією пз (Software Configuration Management– scm)
- •1.1.7. Управління інженерією пз (Software Engineering Management)
- •1.1.8. Процес інженерії пз (Software Engineering Process)
- •1.1.9. Методи і засоби інженерії пз (Software Engineering Tools and Methods)
- •Лекція 2. Тема: життєвий цикл і етапи розробки програмного забезпечення
- •Лекція 3. Тема: еволюція моделей життєвого циклу програмного забезпечення
- •1.6. Прискорення розробки пз.
- •Лекція 4. Тема: оцінка якості процесів створення програмного забезпечення
- •Лекція 5. Тема: визначення вихідних даних для проектування програмного забезпечення
- •5.1 Визначення вимог до пз
- •5.2 Формування і аналіз вимог
- •5.2.1 Опорні точки зору
- •5.2.2 Сценарії
- •5.2.3 Етнографічний метод
- •5.3 Специфікація вимог
- •5.4 Атестація вимог
- •5.5 Класифікація програмних продуктів за функціональною ознакою
- •5.6 Основні експлуатаційні вимоги до програмних продуктів
- •5.7 Передпроектні дослідження предметної області
- •Лекція 6. Тема: розробка технічного завдання
- •2. Підстави для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •5. Вимоги до програмної документації
- •1. Вступ
- •2. Підстава для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •4.1. Вимоги до функціональних характеристик
- •Лекція 7. Тема: принципові рішення початкових етапів проектування
- •Контрольні питання і завдання
- •Аналіз вимог і визначення специфікацій програмного забезпечення при структурному підході
- •Лекція 8. Тема: Специфікації програмного забезпечення при структурному підході
- •Flow-форми
- •Діаграми Насси-Шнейдермана
- •Контрольні питання та завдання:
- •Лекція 9. Тема: діаграми потоків даних
- •Словник даних
- •Вміст словника даних
- •Лекція 10. Тема: діаграми «сутність-зв’язок»
- •Лекція 11. Тема: приклади побудови діаграм та специфікації процесів
- •Лекція 12 Тема: діаграми переходів станів
- •13.1. Структурна схема майбутнього програмного забезпечення
- •13.2 Використання методу покрокової деталізації для проектування структури програмного забезпечення
- •13.3 Структурні карти Константайна
- •13.4.Структурні карти Джексона
- •13.5 Характеристики хорошої моделі реалізації
- •Зчеплення
- •Зв’язаність
- •13.6 Функціональна схема
- •Лекція 14. Тема: методології структурного аналізу і проектування
- •Контрольні питання та завдання
- •Лекція 15. Тема: синтаксис діаграм
- •Контрольні питання та завдання
- •Лекція 16. Тема: Синтаксис діаграм
- •Збір інформації
- •Контрольні питання та завдання:
- •Лекція 17. Тема: побудова sadt-діаграм
- •17.2. Побудова sadt-діаграми для процесу “Побудова таблиць/графіків функцій однієї змінної”
- •Типи зв'язків між функціями
- •Лекція 18. Тема: доповнення до діаграм і моделей
- •Критерії оцінки і вибору
- •Функціональні характеристики
- •3. Загальні функції:
Лекція 12 Тема: діаграми переходів станів
Діаграма переходів станів (SDT) демонструє поведінку майбутньої програмної системи, при отриманні керуючих дій (ззовні) [ 11].
Під керуючими діями або сигналами розуміють керуючу інформацію, яку отримує система ззовні. Наприклад, керуючими діями вважають команди користувача і сигнали давачів, підключених до комп'ютерної системи. Отримавши таку керуючу дію, система повинна виконати певні дії і, або залишитися в тому ж стані, або перейти в інший стан взаємодії із зовнішнім середовищем.
Умовні позначення, які використовуються при побудові діаграм переходів станів, показані на рис. 12.1.
Якщо програмна система в процесі функціонування активно не взаємодіє з навколишнім середовищем (користувачем або давачами), наприклад, використовує примітивний інтерфейс і виконує деякі обчислення за заданими початковими даними, то діаграма переходів станів зазвичай інтересу не представляє. В цьому випадку вона демонструє тільки послідовно виконувані переходи: з початкового стану в стан введення даних потім після виконання обчислень - в стан виводу і, нарешті, в стан завершення роботи (рис. 12.2).
Для інтерактивного програмного забезпечення з розвиненим призначеним для користувача інтерфейсом основні керуючі дії - команди користувача, для програмного забезпечення реального часу — сигнали від давачів і/або оператора виробничого процесу. Загальним для цих типів програмного забезпечення є наявність стану очікування, коли програмне забезпечення припиняє працювати до отримання чергової керуючої дії. Для інтерактивного програмного забезпечення найбільш характерне отримання команд різних типів (рис. 12.3), а якщо це ще і програмне забезпечення реального часу - однотипних сигналів (або від багатьох давачів, або потребуючих тривалої обробки).
На відміну від інтерактивних систем для систем реального часу зазвичай встановлено більш жорстке обмеження на час обробки отриманого сигналу програмного забезпечення. Таке обмеження часто вимагає виконання додаткових досліджень поведінки системи в часі, наприклад, з використанням мереж Петрі або марківських процесів.
Д
о
програмного забезпечення, що вимагає
уточнення особливостей поведінки за
допомогою побудови діаграми переходів
станів, відноситься і програмне
забезпечення орієнтоване на роботу в
мережі. При цьому окремо будують моделі
поведінки сервера і клієнта, представляючи
повідомлення, що передаються між ними,
у вигляді керуючих дій.
Приклад 12.1. Розглянемо діаграму переходів станів для програми побудови графіків функцій однієї змінної.
Програма відноситься до класу інтерактивних, відповідно на етапі аналізу і визначення специфікацій доцільно уточнити поведінку програми на рівні інтерфейсу з користувачем. Один з можливих варіантів діаграми переходів станів програми представлений на рис. 12.4. Отриману діаграму переходів станів слід погоджувати із замовником програмного забезпечення.
Приводимо приклад діаграми переходів станів торгового автомата, який активно взаємодіє з навколишнім середовищем (рис.12.5).
Рисунок 12.5 – Діаграма переходів станів
торгового автомату
Контрольні запитання та завдання:
Що показує діаграма переходів станів?
Що означає стан очікування?
Побудуйте діаграму переходів станів для прикладу процесу складання розкладу для студентів.
Лекція 13.
Тема: ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ПРИ СТРУКТУРНОМУ ПІДХОДІ
Раніше ми з вами розглянули засоби структурного аналізу, які дозволяють будувати модель вимог (або ще називають логічною моделлю), що складається з безлічі взаємопов'язаних діаграм, словника даних і описів специфікацій процесів. Діаграмна техніка, яка використовувалася при цьому включає DFD, ERD і SDT діаграми і специфікації процесів. Модель вимог описує те, що повинна робити проектована система без посилань на те, як це реалізується.
Проектування – це фаза ЖЦ, на якій виробляється, як реалізуються вимоги користувача, які породжені і зафіксовані на фазі аналізу. На цьому етапі здійснюється побудова моделі реалізації (або фізичної моделі), що демонструє як система задовольнятиме вимоги, які до неї ставлять. Фактично структурне проектування є мостом між структурним аналізом і реалізацією [11].
На цій фазі ЖЦ насамперед необхідно визначити структурні компоненти і зв’язки між ними. Отримана в результаті структура ПЗ повинна бути представлена у вигляді структурної і/або функціональної схем і специфікації її компонентів.