
- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •1.1. Складність програмного забезпечення
- •1.2. Структура складних систем
- •1.2.1. Приклади складних систем
- •1.2.2. П'ять ознак складної системи
- •1.2.3. Організована і неорганізована складність
- •1.3. Методи подолання складності
- •1.3.1. Роль декомпозиції
- •1.3.3. Роль абстракції
- •1.3.4. Роль ієрархії
- •1.4. Про проектування складних систем
- •1.4.1. Інженерна справа як наука і мистецтво
- •1.4.2. Сенс проектування
- •4. Методи подолання складності.
- •2.1. Базові означення
- •2.2. Методи проектування інформаційних систем
- •2.3. Види інформаційних систем
- •2.4. Рівні моделей даних
- •3. Види інформаційних систем.
- •3.1. Методологія процедурно-орієнтованого програмування
- •3.2. Методологія об'єктно-орієнтованого програмування
- •3.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •3.4. Методологія системного аналізу і системного моделювання
- •4.1. Передісторія. Математичні основи
- •4.1.1. Теорія множин
- •4.1.2. Теорія графів
- •4.1.3. Семантичні мережі
- •4.2. Діаграми структурного системного аналізу
- •4.3. Основні етапи розвитку uml
- •3. Семантичні мережі.
- •5.1. Принципи структурного підходу до проектування
- •5.2. Структурний аналіз
- •5.3. Структурне проектування
- •5.4. Методологія структурного аналізу
- •5.5. Інструментальні засоби структурного аналізу та проектування
- •6.1. Основні елементи
- •6.2. Типи зв’язків
- •6.3. Техніка побудови
- •6.4. Діаграма бізнес – функцій
- •6.4.1. Призначення діаграми бізнес-функцій
- •6.4.2. Основні елементи
- •7.1. Призначення діаграм потоків даних та основні елементи
- •7.1.1. Зовнішні сутності
- •7.1.2. Процеси
- •7.1.3. Накопичувачі даних
- •7.1.4. Потоки даних
- •7.2. Методологія побудови dfd.
- •8.1. Діаграма «сутність-зв’язок»
- •8.2. Діаграма атрибутів
- •8.3. Діаграма категоризації
- •8.4. Обмеження діаграм сутність-зв’язок
- •8.5. Методологія idef1
- •9.1. Основні елементи
- •9.2. Типи керуючих потоків
- •9.3. Принципи побудови
- •10.1. Структурні карти Константайна
- •10.2. Структурні карти Джексона
- •11.1. Призначення case-технологій
- •11.2. Інструментальний засіб bPwin
- •11.2.4. Інші діаграми bpWin
- •11.2.5. Моделі as is і to be
- •11.3.1. Основні властивості
- •11.3.2. Стандарт idef1x
- •11.4. Програмний засіб Visio
- •12.1. Системний аналіз області наукових досліджень
- •12.1.1. Аналіз предметної області
- •12.2. Системний аналіз біржі праці
- •12.2.1. Дерево цілей
- •12.2.2. Опис об’єктів предметної області
- •12.2.3. Концептуальна модель
- •14.1. Еволюція об'єктної моделі
- •14.1.1. Основні положення об'єктної моделі
- •14.2. Складові частини об'єктного підходу
- •14.2.1. Парадигми програмування
- •14.2.2. Абстрагування
- •14.2.3. Інкапсуляція
- •14.2.4. Модульність
- •14.2.5. Ієрархія
- •14.2.7. Паралелізм
- •14.2.8. Збереженість
- •14.3. Застосування об'єктної моделі
- •14.3.1. Переваги об'єктної моделі
- •14.3.2. Використання об'єктного підходу
- •14.3.3. Відкриті питання
- •15.1. Природа об'єкта
- •15.1.1. Що є й що не є об'єктом?
- •15.1.2. Стан
- •15.1.3. Поведінка
- •15.1.4. Ідентичність
- •Void drag(DisplayItem I); // Небезпечно
- •15.2. Відношення між об'єктами
- •15.2.1. Типи відношень
- •15.2.2. Зв'язки
- •15.2.3. Агрегація
- •15.3. Природа класів
- •15.3.1. Що таке клас?
- •15.3.2. Інтерфейс і реалізація
- •15.3.3. Життєвий цикл класу
- •15.4. Відношення між класами
- •15.4.1. Типи відношень
- •15.4.2. Асоціація
- •15.4.3. Успадкування
- •15.4.4. Агрегація
- •15.4.5. Використання
- •15.4.6. Інсталювання (Параметризація)
- •15.4.6. Метакласи
- •15.5. Взаємозв'язок класів і об'єктів
- •15.5.1. Відношення між класами й об'єктами
- •15.5.2. Роль класів і об'єктів в аналізі й проектуванні
- •16.1. Важливість правильної класифікації
- •16.1.1. Класифікація й об’єктно-орієнтовне проектування
- •16.1.2. Труднощі класифікації
- •16.2. Ідентифікація класів і об'єктів
- •16.2.1. Класичний і сучасний підходи
- •16.2.2. Об’єктно-орієнтований аналіз
- •16.3. Ключові абстракції й механізми
- •16.3.1. Ключові абстракції
- •16.3.2. Ідентифікація механізмів
- •17.1. Призначення мови uml
- •17.2. Загальна структура мови uml
- •17.3. Пакети в мові uml
- •17.4. Основні пакети мета-моделі мови uml
- •17.5. Специфіка опису мета-моделі мови uml
- •17.6. Особливості зображення діаграм мови uml
- •18.1. Варіант використання
- •18.2. Актори
- •18.3. Інтерфейси
- •18.4. Примітки
- •18.5. Відношення на діаграмі варіантів використання
- •18.5.1. Відношення асоціації
- •13.5.2. Відношення розширення
- •18.5.3. Відношення узагальнення
- •18.5.4. Відношення включення
- •18.6. Приклад побудови діаграми варіантів використання
- •18.7. Рекомендації з розроблення діаграм варіантів використання
- •19.1. Клас
- •19.1.1. Ім'я класу
- •19.1.2. Атрибути класу
- •19.1.3. Операція
- •19.2. Відношення між класами
- •19.2.1. Відношення залежності
- •19.2.2. Відношення асоціації
- •19.2.3. Відношення агрегації
- •19.2.4. Відношення композиції
- •19.2.5. Відношення узагальнення
- •19.3. Інтерфейси
- •19.5. Шаблони або параметризовані класи
- •19.6. Рекомендації з побудови діаграми класів
- •20.1. Автомати
- •20.2. Стан
- •20.2.1. Ім'я стану
- •20.2.2. Список внутрішніх дій
- •20.2.3. Початковий стан
- •20.2.4. Кінцевий стан
- •20.3. Перехід
- •20.3.2. Сторожова умова
- •20.3.3.Вираз дії
- •15.4. Складений стан і підстан
- •20.4.1. Послідовні підстани
- •20.4.2. Паралельні підстани
- •15.5. Історичний стан
- •20.6. Складні переходи
- •15.6.1. Переходи між паралельними станами
- •20.6.2. Переходи між складеними станами
- •20.6.3. Синхронізуючі стани
- •20.7. Рекомендації з побудови діаграм станів
- •21.1. Стан дії
- •21.2. Переходи
- •21.5. Рекомендації до побудови діаграм діяльності
- •22.1.1. Лінія життя об'єкта
- •22.1.2. Фокус керування
- •22.2. Повідомлення
- •22.2.1. Розгалуження потоку керування
- •22.2.2. Стереотипи повідомлень
- •22.2.3. Тимчасові обмеження на діаграмах послідовності
- •22.2.4. Коментарі або примітки
- •22.3. Приклад побудови діаграми послідовності
- •22.4. Рекомендації з побудови діаграм послідовності
- •23.1. Кооперація
- •23.2.1. Мультиоб'єкт
- •23.2.2. Активний об'єкт
- •23.2.3. Складений об'єкт
- •23.3. Зв'язки
- •23.3.1. Стереотипи зв'язків
- •23.4. Повідомлення
- •23.4.1. Формат запису повідомлень
- •23.5. Приклад побудови діаграми кооперації
- •23.6. Рекомендації з побудови діаграм кооперації
- •24.1. Компоненти
- •24.1.1. Ім'я компоненту
- •24.1.2. Види компонент
- •24.2. Інтерфейси
- •24.3. Залежності
- •24.4. Рекомендації з побудови діаграми компонент
- •25.1. Вузол
- •25.2. З'єднання
- •25.3. Рекомендації з побудови діаграми розгортання
- •26.1. Загальна характеристика case-засобу Rational Rose
- •26.2. Особливості робочого інтерфейсу Rational Rose
- •26.1.1. Головне меню програми
- •26.1.2. Стандартна панель інструментів
- •26.1.3. Вікно браузера
- •26.1.4. Спеціальна панель інструментів
- •26.1.5. Вікно діаграми
- •26.1.6. Вікно документації
- •26.1.7. Вікно журналу
- •26.3. Початок роботи над проектом у середовищі Rational Rose
- •26.4. Розроблення діаграми варіантів використання в середовищі Rational Rose
- •26.5. Розроблення діаграми класів у середовищі Rational Rose
- •26.6. Розроблення діаграми станів у середовищі Rational Rose
- •26.7. Розроблення діаграми послідовності в середовищі Rational Rose
- •26.8. Розроблення діаграми кооперації в середовищі Rational Rose
- •26.9. Розроблення діаграми компонентів у середовищі Rational Rose
- •26.10. Розроблення діаграми розгортання в середовищі Rational Rose
5.5. Інструментальні засоби структурного аналізу та проектування
У якості інструментальних засобів структурного аналізу і проектування виступають наступні діаграми:
BFD (Bussiness Function Diagram) - діаграма бізнес - функцій;
DFD (Data Flow Diagram) – діаграма потоків даних;
STD (State Transition Diagram) - діаграма переходів станів;
ERD (Entity Relationship Diagram) - модель «сутність-зв'язок» даних предметної області (інформаційно-логічна модель);
SSD (System Structure Diagram) - діаграма структури програмного застосування.
Проте зі всього різноманіття цих моделей найчастіше на практиці застосовуються діаграми потоків даних (DFD), діаграми «сутність-зв'язок» (ERD) і діаграми переходів станів (STD). Усі вони містять графічні та текстові засоби моделювання: для зручності демонстрування основних компонент моделі і забезпечення точного визначення її компонент і зв'язків.
Висновки
1. Структурний підхід до проектування ІС – метод визначення вхідних даних, процесів та вихідних даних системи і поділ систем на підсистеми або модулі, що показують логічну графічну модель потоків інформації.
2. Є два базових принципи структурного аналізу та проектування: принцип «розділяй та владарюй» та принцип ієрархічного впорядкування..
3. Сукупність стандартів IDEF використовується в методології структурного аналізу.
4. Інструментальними засобами структурного аналізу є: діаграма бізнес-функцій, діаграма потоків даних, діаграма сутність-зв’язок, діагарма переходів станів, діаграма структури програмного застомування.
5. Структурний підхід до проектування ІС (структурний аналіз/структурне проектування SA/SD — Structure Analyses & Structure Design) – метод визначення вхідних даних, процесів та вихідних даних системи і поділ систем на підсистеми або модулі, що показують логічну графічну модель потоків інформації.
Контрольні питання
Основні принципи структурного підходу.
Особливості структурного аналізу.
Методології структурного проектування.
Інструментальні засоби структурного аналізу та проектування.
РОЗДІЛ 6. Методологія функціонального моделювання SADT
Основні елементи діаграм.
Типи зв’язків.
Техніка побудови діаграм.
Діаграма бізнес-функцій.
У розділі викладено базові вимоги до побудови діаграм структурного проектування. Описано діаграму бізнес-функцій.
6.1. Основні елементи
Модель SADT є серією діаграм зі супровідною документацією, що розбивають складний об'єкт на складові частини, які представлені у вигляді блоків. Деталі кожного з основних блоків показані у вигляді блоків на інших діаграмах. Кожна детальна діаграма є декомпозицією блоку із загальнішої діаграми. На кожному кроці декомпозиції загальніша діаграма називається батьківською для детальнішої діаграми.
Розглянемо стисло ці основні поняття методології IDEF-SADT, які використовуються під час побудови діаграм функціонального моделювання. Діяльністю є деяка дія або набір дій, які мають фіксовану мету і приводять до деякого кінцевого результату. Іноді діяльність називають просто процесом. Моделі IDEF0 відстежують різні види діяльності системи, їх опис і взаємодію з іншими процесами. На діаграмах процес зображається прямокутником, який називається блоком. Дуга служить для позначення деякого носія або дії, які забезпечують перенесення даних або об'єктів від однієї діяльності до іншої. Дуги також необхідні для опису діяльностей і спожитих ними ресурсів. Це так звані ролі дуг – ICOM – скорочення перших букв від назв відповідних дуг IDEF0. Розрізняють дуги чотирьох видів:
I (Input) – вхід, тобто все, що поступає в процес або споживається процесом.
С(Control) – керування або обмеження на виконання операцій процесу.
О (Output) – вихід або результат процесу.
М (Mechanism) – механізм, який використовується для виконання процесу.
Методологія IDEF0 однозначно визначає, яким чином зображаються на діаграмах дуги кожного виду ICOM. Дуга Вхід (Input) виходить з лівої сторони рамки робочого поля і входить зліва в прямокутник процесу. Дуга Керування (Control) входить і виходить зверху. Дуга Вихід (Output) виходить з правої сторони процесу і входить в праву сторону рамки. Дуга Механізм (Mechanism) входить в прямокутник процесу знизу. Таким чином, базове подання процесу на діаграмах IDEF0 має наступний вигляд (рис. 6.1).
Рис. 6.1. Позначення процесу і стрілок ICOM на діаграмах IDEF0
Дуги, що входять в блок і виходять з нього на діаграмі верхнього рівня, є такими, як і дуги, що входять в діаграму нижнього рівня і виходять з неї, тому що блок і діаграма представляють одну і ту ж частину системи.
Деякі дуги приєднані до блоків діаграми обома кінцями, в інших один кінець залишається неприєднаним. Неприєднані дуги відповідають входам, управлінням і виходам батьківського блоку. Джерело або одержувач цих дуг може бути виявлений лише на батьківській діаграмі. Неприєднані кінці повинні відповідати дугам на вихідній діаграмі. Усі граничні дуги повинні продовжуватися на батьківській діаграмі, щоб вона була повною і несуперечливою.
На SADT-діаграмах не вказані явно ні послідовність, ні час. Зворотні зв'язки, ітерації, процеси, що продовжуються, і функції, що перекриваються (за часом), можуть бути подані за допомогою дуг. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень і так далі.
Як було відмічено, механізми (дуги з нижнього боку) показують засоби, за допомогою яких здійснюється виконання функцій. Механізм може бути людиною, комп'ютером або будь-яким іншим пристроєм, який допомагає виконувати дану функцію.
Кожен блок на діаграмі має свій номер. Блок будь-якої діаграми може бути далі описаний діаграмою нижнього рівня, яка, у свою чергу, може бути далі деталізована за допомогою необхідної кількості діаграм. Таким чином, формується ієрархія діаграм.
Для того, щоб вказати положення будь-якої діаграми або блоку в ієрархії, використовуються номери діаграм. Наприклад, А21 є діаграмою, яка деталізує блок 1 на діаграмі А2. Аналогічно, А2 деталізує блок 2 на діаграмі А0, яка є верхньою діаграмою моделі.