- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •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.3. Методологія об'єктно-орієнтованого аналізу і проектування
Необхідність аналізу предметної області до початку написання програми була усвідомлена давно під час розроблення масштабних проектів. Процес розроблення баз даних істотно відрізняється від написання програмних кодів для вирішення обчислювальної задачі. Головна відмінність полягає в тому, що при проектуванні бази даних виникає необхідність в попередньому розробленні концептуальної схеми, яка відображала б загальні взаємозв'язки предметної області і особливості організації відповідної інформації. Виділення початкових або базових компонент предметної області, необхідних для вирішення того або іншого завдання, представляє, в загальному випадку, нетривіальну проблему. Складність даної проблеми виявляється в неформальному характері процедур або правил, які можна застосовувати для цієї мети. Така робота повинна виконуватися спільно з фахівцями або експертами, обізнаними з предметною областю. Наприклад, якщо розробляється база даних для обслуговування пасажирів крупного аеропорту, то в проектуванні концептуальної схеми бази даних повинні брати участь штатні співробітники даного аеропорту. Ці співробітники повинні добре знати весь процес обслуговування пасажирів, тобто дану предметну область.
Для виділення або ідентифікації компонент предметної області було запропоновано декілька способів і правил. Сам цей процес отримав назву концептуалізації предметної області. При цьому під компонентою розуміють деяку абстрактну одиницю, яка володіє функціональністю, тобто може виконувати певні дії, пов'язані з вирішенням поставлених завдань. На попередньому етапі концептуалізації рекомендується використовувати так звані CRC-карточки (Component, Responsibility, Collaborator – компонента, обов'язок, співробітники) [1]. Для кожної виділеної компоненти предметної області розробляється власна CRC-карточка (рис. 3.6).
Рис. 3.6. Загальний вигляд CRC-карточки для опису компонент предметної області
Поява методології ООАП потребує, з однієї сторони, розроблення різних засобів концептуалізації предметної області, а з іншої – відповідних фахівців, які володіли б цією методологією. На даному етапі з'являється відносно новий тип фахівця, який отримав назву аналітика або архітектора. Разом з фахівцями з предметної області аналітик бере участь в побудові концептуальної схеми майбутньої програми, яка потім перетворюється в програмний код. При цьому окремі компоненти вибираються так, щоб при подальшому розробленні системи їх було зручно представити у формі класів і об'єктів. У цьому випадку важливе значення набуває й сама мова представлення інформації про концептуальну схему предметної області.
Розділення процесу розроблення складних програмних застосувань на окремі етапи сприяло становленню концепції життєвого циклу програми. Під життєвим циклом (ЖЦ) програми розуміють сукупність взаємозв'язаних і наступних в часі етапів, починаючи від розроблення вимог до неї і закінчуючи повною відмовою від її використання. Стандарт ISO/IEC 12207, хоча і описує загальну структуру ЖЦ програми, не конкретизує деталі виконання тих або інших етапів. Згідно прийнятим поглядам ЖЦ програми складається з таких етапів:
аналізу предметної області і формулювання вимог до програми,
проектування структури програми,
реалізації програми в кодах (власне програмування),
впровадження програми,
супровід програми,
відмови від використання програми.
На етапі аналізу предметної області і формування вимог здійснюється визначення функцій, які повинні виконувати програма, що розробляється, а також концептуалізації предметної області. Цю роботу виконують аналітики спільно з фахівцями предметної області. Результатом даного етапу повинна бути деяка концептуальна схема, що містить опис основних компонент і тих функцій, які вони повинні виконувати.
Етап проектування структури програми полягає в розробленні детальної схеми майбутньої програми, на якій вказуються класи, їх властивості і методи, а також різні взаємозв'язки між ними. Як правило, на цьому етапі можуть брати участь в роботі аналітики, архітектори і окремі кваліфіковані програмісти. Результатом даного етапу повинна стати деталізована схема програми, на якій вказуються всі класи і взаємозв'язки між ними в процесі функціонування програми. Згідно методології ООАП, саме дана схема повинна "служити” початковою інформацією для написання програмних кодів.
Етап програмування навряд чи потребує уточнення, оскільки є традиційним для програмістів. Поява інструментаріїв швидкого розроблення програм (Rapid Application Development, RAD) дозволила істотно скоротити час, і витрати на виконання цього етапу. Результатом цього етапу є програмне застосування, яке володіє необхідною функціональністю і здатне вирішувати потрібні завдання в конкретній предметній області.
Етапи впровадження і супроводу програми пов'язані з необхідністю налаштування і конфігурації середовища програми, а також з усуненням помилок, які виникли в процесі її використання. Іноді як окремий етап виділяють тестування програми, під яким розуміють перевірку працездатності програми на деякій сукупності початкових даних або при деяких спеціальних режимах експлуатації. Результатом цих етапів є підвищення надійності програмного засобу, що виключає виникнення критичних ситуацій або нанесення збитку компанії, що використовує цю інформаційну систему (програму).
Примітка
Розглядаючи різні етапи ЖЦ програми, слід зазначити одну важливу обставину. А саме, якщо поява RAD-інструментів дозволила істотно скоротити терміни етапу програмування, то відсутність відповідних засобів для перших двох етапів довгий час стримувала процес розроблення інформаційних систем. Розвиток методології ООАП був направлений на автоматизацію другого, а потім і першого етапів ЖЦ програми.
Методологія ООАП тісно пов'язана з концепцією автоматизованого розроблення програмного забезпечення (Computer Aided Software Engineering, CASE). Поява перших CASE–засобів була зустрінута з певною насторогою (див. розділ 13). З часом з'явилися як захоплені відгуки про їх застосування, так і критичні оцінки їх можливостей. Причин для таких суперечливих думок було декілька. Перша з них полягає в тому, що ранні CASE-засоби були простою надбудовою над деякою системою керування базами даних (СКБД). Хоча візуалізація процесу розроблення концептуальної схеми БД має важливе значення, вона не вирішує проблем розроблення інформаційних систем інших типів.
Друга причина має складнішу природу, оскільки пов'язана з графічною нотацією, реалізованою в тому або іншому CASE-засобі. Якщо мови програмування мають строгий синтаксис, то спроби запропонувати відповідний синтаксис для візуального представлення концептуальних схем БД були сприйняті далеко неоднозначно. З'явилося декілька підходів, які детальніше будуть розглянуті в розділі 14. На цьому фоні поява уніфікованої мови моделювання (Unified Modeling Language, UML), яка орієнтована на вирішення завдань перших двох етапів ЖЦ програм, була сприйнята з великим оптимізмом всім співтовариством корпоративних програмістів.
Останнє, на що слід звернути увагу, це усвідомлення необхідності побудови попередньої моделі програмної системи, яку, згідно сучасним концепціям ООАП, слід вважати результатом перших етапів ЖЦ програми. Оскільки мова UML навіть у своїй назві має відношення до моделювання, слід додатково зупинитися на цілому ряді достатньо важливих питань. Таким чином, ми переходимо до теми, яка традиційно не розглядається у виданнях з ООАП, але має найпряміше відношення до процесу побудови моделей і, власне, моделювання. Мова йде про методології системного аналізу і системного моделювання.