- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •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
3.4. Методологія системного аналізу і системного моделювання
Системний аналіз як науковий напрям має давнішу історію, ніж ООП і ООАП, і власний предмет дослідження. Центральним поняттям системного аналізу є поняття системи, під якою розуміється сукупність об'єктів, компонентів або елементів довільної природи, які створюють деяку цілісність. Визначальною передумовою виділення деякої сукупності як системи є виникнення у неї нових властивостей, яких не мають складові її елементи. Прикладів систем можна привести достатньо багато – це персональний комп'ютер, автомобіль, людина, біосфера, програма і ін. Більш ортодоксальна точка зору припускає, що всі предмети, що оточують нас, є системами.
Найважливішими характеристиками будь-якої системи є її структура і процес функціонування. Під структурою системи розуміють стійку в часі сукупність взаємозв'язків між її елементами або компонентами. Саме структура зв'язує всі елементи і перешкоджає розпаду системи на окремі компоненти. Структура системи може відображати самі різні взаємозв'язки, у тому числі і вкладеність елементів однієї системи в іншу. У цьому випадку прийнято називати дрібнішу або вкладену систему підсистемою, а більшу – метасистемою.
Процес функціонування системи тісно пов'язаний із зміною її властивостей або поведінкою в часі. При цьому важливою характеристикою системи є її стан, під яким розуміється сукупність властивостей або ознак, які в кожний момент часу відображають найістотніші особливості поведінки системи.
Розглянемо наступний приклад. Як систему візьмемо "Автомобіль". Для цього випадку система охолоджування двигуна буде підсистемою "Автомобіля". З однієї сторони, двигун є елементом системи "Автомобіль". З іншої сторони, двигун сам є системою, що складається з окремих компонент, таких як циліндри, свічки запалення і ін. Тому система "Двигун" також буде підсистемою системи "Автомобіль".
Процес функціонування системи відображає поведінку системи в часі і може бути представлена як послідовна зміна її станів: якщо система змінює однин свій стан на інший, то прийнято говорити, що система переходить з одного стану в інший. Сукупність ознак або умов зміни станів системи в цьому випадку називається переходом. Для системи з дискретними станами процес функціонування може бути представлений у вигляді послідовності станів з відповідними переходами. Точніший графічний опис процесу функціонування систем буде наведений в розділі 9.
Методологія системного аналізу служить концептуальною основою системно-орієнтованої декомпозиції предметної області. У цьому випадку початковими компонентами концептуалізації є системи і взаємозв'язки між ними. При цьому поняття системи є більш загальним, ніж поняття класів і об'єктів в ООАП. Результатом системного аналізу є побудова деякої моделі системи або предметної області.
Поняття моделі так широко використовується в повсякденному житті, що придбало дуже багато смислових відтінків. Це і "Будинок моделей" відомого кутюрє, і модель престижної марки автомобіля, і модель політичного керівництва, і математична модель коливань маятника. Стосовно програмних систем нас цікавитиме тільки те поняття моделі, яке використовується в системному аналізі. А саме, під моделлю розумітимемо деяке уявлення про систему, що відображає найістотніші закономірності її структури і процес функціонування, що фіксується на деякій мові або в іншій формі.
Прикладів моделей можна привести достатньо багато. Наприклад, аеродинамічна модель гоночного автомобіля або проектованого літака, модель ракетного двигуна, модель коливальної системи, модель системи електропостачання регіону, модель виборчої компанії і ін.
Загальною властивістю всіх моделей є їх подібність оригінальній системі або системі-оригіналу. Важливість побудови моделей полягає в можливості їх використання для отримання інформації про властивості або поведінку системи-оригіналу. При цьому процес побудови і подальшого застосування моделей для отримання інформації про систему-оригінал отримав назву моделювання.
Примітка
Термін "моделювання" має досить багато смислових відтінків, наприклад, моделювання одягу або моделювання зачіски. Не заперечуючи важливості цих сфер творчості, слід зазначити, що всі ці аспекти моделювання лежать за межами книги. Розгляд особливостей мови UML пов'язаний з питаннями логічного або інформаційного моделювання систем.
Найзагальнішою моделлю системи є так звана модель "чорного ящика". У цьому випадку система представляється у вигляді прямокутника, внутрішній устрій якого прихований від аналітика або невідомий. Проте система не є повністю ізольованою від зовнішнього середовища, оскільки остання надає системі деякі інформаційні або матеріальні дії. Такі дії отримали назву вхідних дій. У свою чергу, система також виробляє на середовище або інші системи певні інформаційні або матеріальні дії, які отримали назву вихідних дій. Графічно дана модель може бути зображена таким чином (рис. 3.7).
Цінність моделей, подібних до моделі "чорного ящика", вельми умовна. Мимоволі може виникнути асоціація з "Чорним квадратом". Проте якщо оцінка образотворчих особливостей останнього не входить в завдання системного аналізу, то загальна модель системи містить деяку важливу інформацію про функціональні особливості даної системи, які дають уявлення про її поведінку.
Рис. 3.7. Графічне зображення моделі системи у вигляді "чорного ящика"
Дійсно, окрім найзагальнішої інформації про те, на які дії реагує система, і як виявляється ця реакція на навколишні об'єкти і системи, іншої інформації ми отримати не можемо. В рамках системного аналізу розроблені певні методологічні засоби, що дозволяють виконати подальшу конкретизацію загальної моделі системи. Деякі з графічних засобів представлення моделей систем будуть розглянуті в розділі 6.
Процес розроблення адекватних моделей і їх подальшого конструктивного застосування вимагає не тільки знання загальної методології системного аналізу, але й наявність відповідних образотворчих засобів або мов для фіксації результатів моделювання і їх документування. Очевидно, що природна мова не цілком підходить для цієї мети, оскільки володіє неоднозначністю і невизначеністю. Для побудови моделей були розроблені достатньо серйозні теоретичні методи, засновані на розвитку математичних і логічних засобів моделювання, а також запропоновані різні формальні і графічні нотації, що відображають специфіку вирішуваних завдань. Важливо уявляти, що уніфікація будь-якої мови моделювання тісно пов'язана з методологією системного моделювання, тобто з системою переконань і принципів розгляду складних явищ і об'єктів як моделей складних систем.
Висновки
Основою процедурно-орієнтованої методології розроблення програм була процедурна або алгоритмічна організація структури програмного коду.
. Основою розбиття програми на дрібніші фрагменти стала процедурна декомпозиція, при якій окремі частини програми або модулі були сукупністю процедур для вирішення деякої сукупності завдань. Головна особливість процедурного програмування полягає в тому, що програма завжди має початок в часі або початкову процедуру (початковий блок) і закінчення (кінцевий блок). При цьому вся програма може бути представлена візуально у вигляді направленої послідовності графічних примітивів або блоків.
Фундаментальними поняттями ООП є поняття класу і об'єкту. При цьому під класом розуміють деяку абстракцію множини об'єктів, які мають загальний набір властивостей і володіють однаковою поведінкою. Кожний об'єкт у цьому випадку розглядається як екземпляр відповідного класу. Об'єкти, які не мають повністю однакових властивостей або не володіють однаковою поведінкою, за визначенням, не можуть бути віднесені до одного класу.
Основними принципами ООП є успадкування, інкапсуляція і поліморфізм.
Виділення початкових або базових компонент предметної області, необхідних для вирішення того або іншого завдання, представляє, в загальному випадку, нетривіальну проблему. Складність даної проблеми виявляється в неформальному характері процедур або правил, які можна застосовувати для цієї мети.
Під життєвим циклом програми розуміють сукупність взаємозв'язаних і наступних в часі етапів, починаючи від розроблення вимог до неї і закінчуючи повною відмовою від її використання.
Контрольні питання
1. Методологія об'єктно-орієнтованого аналізу.
2. Методологія об'єктно-орієнтованого проектування.
3. Методологія системного аналізу.
4. Методологія системного моделювання.
РОЗДІЛ 4. Історичний огляд розвитку структурної та об'єктно-орієнтованої методологій проектування інформаційних систем
Математичні основи: теорія множин, теорія графів, семантичні мережі
Структурний системний аналіз
Основні етапи розвитку UML
У розділі описано передумови виникнення структурної та об’єктно-орієнтованої методології