
- •Лекція 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. Загальні функції:
Контрольні питання та завдання
Що показують функціональні діаграми?
Хто запропонував методологію функціонального моделювання SADT? Що спонукало до створення цієї методології?
Що є основним поняттям в ?
Скільки містить SADT-діаграма блоків і дуг, а також можливих версій?
Що використовують для позначення різних версій?
Що відображають на діаграмі блоки, а що дуги?
При розгалуженні та з’єднанні дуги зберігають свої об’єкти?
Лекція 15. Тема: синтаксис діаграм
Як вже наголошувалося, кожна SADT-діаграма містить блоки і дуги. Блоки зображають функції системи, дуги зв'язують блоки і відображають взаємодії і взаємозв'язки між ними. Діаграмі дається назва, яка розташовується внизу.
Функціональні блоки зображають прямокутниками. Оскільки блоки відображають функції системи, то в назві блоків використовують дієслова (розрахувати, виконати завдання і т.д.).
Блоки на SADT-діаграмі ніколи не розміщуються випадковим чином. Вони розміщуються по ступеню важливості, як її розуміє автор діаграми. У SADT цей відносний порядок називається домінуванням. Під домінуванням розуміється вплив одного блоку на інші блоки діаграми. Наприклад, самим домінуючим блоком діаграми може бути перший з необхідної послідовності функцій. Найбільш домінуючий блок зазвичай розташовується у верхньому лівому кутку діаграми, а найменш домінуючий – в правому нижньому кутку діаграми. В результаті маємо ступінчасту схему.
Блоки в SADT повинні бути пронумеровані. Номери блоків служать однозначними ідентифікаторами для системних функцій і автоматично організовують ці функції в ієрархію моделі.
Дуги на SADT-діаграмі зображуються одинарними лініями із стрілками на кінцях. Дуги зображують об'єкти (або дані), тому вони описуються іменниками або іменниками з визначеннями (набір інструментів, креслення і т.д.)
Між об'єктами і функціями можливі 4 відношення: вхід, керування, вихід і механізм. Кожне з цих відношень зображується дугою і пов'язано з певною стороною блоку (ліва сторона – вхідні дуги, права сторона – вихідні дуги, верхня сторона – керуючі дуги, нижня сторона – дуги механізму).
Вхідні дуги зображують об'єкти, які використовуються і перетворюються функціями. Керуючі дуги представляють інформацію, яка керує діями функцій. Зазвичай керуючі дуги несуть інформацію, яка вказує, що повинна виконувати функція. Вихідні дуги зображають об'єкти, в які перетворяться вхідні. Дуги механізмів відображують, принаймні частково, як функції реалізуються, за допомогою чого або кого.
Таким чином, SADT-діаграма складена з блоків, зв’язаних дугами, які визначають, як блоки впливають один на одного. Цей вплив може бути вираженим або в передачі вихідної інформації до другої функції для подальшого перетворення, або в виробництві керуючої інформації, яка вказує, що саме повинна виконувати друга функція. Тому SADT-діаграми неможливо відносити до блок-схем або діаграм потоків даних. Скоріш за все, це наказуючі діаграми, які показують вхідні-вихідні перетворення і вказують правила цих перетворень.
У функціональних діаграмах SADT розрізняють п'ять типів впливів блоків один на одного:
• вхід – вихід блоку подається на вхід блоку з меншим домінуванням, тобто Наступного (рис. 15.1, а);
• керування – вихід блоку використовується як керування для блоку з меншим домінуванням (наступного) (рис. 15.1, б);
• зворотній зв'язок по входу – вихід блоку подається на вхід блоку з великим домінуванням (попереднього) (рис. 15.1, в);
• зворотній зв'язок по керуванню — вихід блоку використовується як керуюча інформація для блоку з більшим домінуванням (попереднього) (рис. 15.1, г);
• вихід-механізм – вихід блоку використовується як механізм для іншого блоку (рис. 15.1, д).
Рисунок 15.2 – приклад типів впливів блоків один на одного
Зв'язки по керуванню і входу є простими, оскільки вони відображують прямі дії, які інтуїтивно зрозумілі і дуже прості. Відношення керування виникає тоді, коли вихід одного блоку безпосередньо впливає на блок з меншим домінуванням. Приклад: Блок "Керувати виконанням завдання" впливає на блок "Виконати завдання" відповідно до плану виконання завдання (рис.15.2).
Відношення входу виникає тоді, коли вихід одного блоку стає входом для блоку з меншим домінуванням. Приклад: вихід "Завершене або незавершене завдання" є входом функції "Контролювати якість виконання" при виконанні функції "Виконати завдання".
Зворотній зв'язок по керуванню і зворотній зв'язок по входу є складнішими, оскільки вони є ітерацією або рекурсією. А саме виходи однієї функції впливають на майбутнє виконання інших функцій, які надалі впливають на початкову функцію.
Зворотній зв’язок по керуванню виникає тоді, коли вихід деякого блока впливає на блок с більшим домінуванням. Приклад: функція "Керувати виконанням завдання" обмежує дію функції "Контролювати якість виконання" за допомогою креслення, в якому вказані дозволені допуски. Крім цього, дуга штамп "прийнято", яка є виходом блока "контролювати якість виконання" організовує роботу блока "керувати виконанням завдання", оскільки саме штамп "прийнято" вказує, що завдання завершене. Таким чином, штамп "прийнято" впливає на майбутню діяльність блока "керувати виконанням завдання", тому відповідна дуга направлена назад.
Зв'язок по вхідному зворотному зв'язку має місце тоді, коли вихід одного блоку стає входом іншого блоку з великим домінуванням. Приклад: завдання, знехтувані функцією "контролювати якість виконання", відсилаються на вхід блоку "виконати завдання" як брак.
Зв'язки "вихід-механізм" зустрічаються рідко. Вони відображують ситуацію, коли вихід однієї функції стає засобом досягнення мети іншої функції. Зв'язки "вихід-механізм" характерні при розподілі джерел ресурсів (наприклад, необхідні інструменти, навчений персонал, фізичний простір, устаткування, фінансування і т. д.).
Дуга в SADT рідко зображає один об'єкт. Зазвичай вона символізує набір об'єктів. Наприклад, дуга "робочий комплект" відображує "технічне завдання", "креслення", "план-графік", деяка "сировина і заготовки". Оскільки дугами є набори об'єктів, вони можуть мати безліч початкових точок (джерел) і кінцевих точок (призначень). Тому дуги можуть розгалужуватися і з'єднуватися різними складними способами. Приклад: дуга “прийняте завдання” розгалужується на дугу “штамп прийнято", яка є керуючою інформацією для блоку "керувати виконанням завдання" і дугу “деталь з біркою”, яка є вхідною для того ж блоку.
Бувають варіанти, коли дві різні дуги об'єднуються і утворюють більший набір об'єктів.
Для пояснення того, як дуги представляють роз'єднання і з'єднання наборів об'єктів, в SADT були розроблені спеціальні угоди.
Розгалуження дуг.
Розгалуження дуг, що зображуються у вигляді ліній, що розходяться, означають, що весь вміст дуг або його частина може з'явитися в кожному відгалуженні дуги. Дуга завжди позначається до розгалуження, щоб дати назву всьому набору. Крім того, кожна дуга може бути помічена або непомічена відповідно до наступних правил:
непомічені гілки містять всі об'єкти, вказані в мітці дуги перед розгалуженням (тобто всі об'єкти належать цим гілкам);
гілки, помічені після точки розгалуження, містять всі об'єкти або їх частину, вказані в мітці дуги перед розгалуженням (тобто кожна мітка гілки уточнює, що саме містить гілку) (рис.15.3).
З
лиття
дуг.
Злиття дуг в SADT, що зображується як лінії, що сходяться разом, вказує, що вміст кожної гілки йде на формування мітки для дуги, що є результатом злиття початкових дуг. Після злиття результуюча дуга завжди позначається для вказівки нового набору об'єктів, що виникає після об'єднання.
Крім того, кожна гілка перед злиттям може позначатися або не позначатися відповідно до наступних правил:
непомічені гілки містять всі об'єкти, вказані в загальній мітці дуги після злиття (тобто всі об'єкти виходять зі всіх гілок);
помічені перед злиттям гілки містять всі або деякі об'єкти з перерахованих в загальній мітці після злиття (тобто мітка гілки ясно вказує, що містить гілку).
Синтаксис моделей і робота з ними
Одна SADT-діаграма складна сама по собі, оскільки містить від трьох до шести блоків, зв'язаних безліччю дуг. Для адекватного опису системи потрібно декілька таких діаграм. Діаграми, зібрані і зв'язані разом, стають SADT-моделлю. У SADT додатково до синтаксису діаграм існують правила синтаксису моделей.
SADT-модель є ієрархічно організованою сукупністю діаграм, що складається з 3-6 блоків. При цьому кожен блок може розумітися як окремий ретельно визначений об'єкт. Кожен блок в SADT розглядається як формальна межа деякої частини цілої системи. Іншими словами, блок і дуги, що стосуються його, визначають точну межу діаграми, що представляє декомпозицію цього блоку.
Принцип обмеження об'єкту зустрічається на кожному рівні. Один блок і декілька дуг на самому верхньому рівні використовується для визначення межі всієї системи. Діаграма, що складається з одного блоку і його дуг, визначає межу системи і називається контекстною діаграмою моделі.
Окрім цього на контекстній діаграмі відображається мета системи і точка зору.
Поняття мети системи.
SADT-модель дає повний, точний і адекватний опис системи, що має конкретне призначення. Це призначення називають метою системи. Таким чином, метою моделі є отримання відповідей на сукупність питань. Якщо модель відповідає не на всі питання або її відповіді недостатньо точні, то говорять про те, що модель не досягла своєї мети. Визначаючи модель таким чином, SADT закладає основи практичного моделювання.
Точка зору моделі.
Із визначенням моделі тісно пов’язана позиція, з якої спостерігається система і створюється її модель. Ця позиція і називається "точкою зору" даної моделі. "Точку зору" краще всього представляти собі як місце (позицію) людини або об’єкта, в яке потрібно встати, щоб побачити систему в дії.
Побудуємо контекстну діаграму моделі виготовлення нестандартної деталі.
Визначимо спершу мету і точку зору моделі.
Мета: визначити, які функції повинні бути включені в процес виготовлення нестандартної деталі і як ці функції взаємозв'язані між собою.
Точка зору: краще всього описати всі функції може начальник цеху, в якому виготовляються нестандартні деталі (рис.15.4).
Рисунок 15.4 – Контекстна діаграма
SADT-моделі розвиваються в процесі структурної декомпозиції зверху вниз. Спочатку піддається декомпозиції один блок, що є межею моделі. Назва діаграми співпадає з назвою блоку, який піддаємо декомпозиції. У методології SADT ідентифікується кожна діаграма даної моделі за допомогою "Номера вузла". Номер вузла для контекстної діаграми має наступний вигляд: назва моделі або абревіатура, коса риска, заголовна буква A (activity у функціональних діаграмах), дефіс і нуль.
Номером вузла діаграми, яка є наслідком декомпозиції контекстної діаграми, є той же номер вузла, але без дефіса (рис.15.2).