- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •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
17.2. Загальна структура мови uml
Із самої загальної точки зору опис мови UML складається із двох взаємодіючих частин, таких як:
Семантика мови UML. Являє собою деяку мета-модель, що визначає абстрактний синтаксис і семантику понять об'єктного моделювання мовою UML.
Нотація мови UML. Являє собою графічну нотацію для візуального подання семантики мови UML.
Абстрактний синтаксис і семантика мови UML описується з використанням деякої підмножини нотацій UML. Крім того, нотація UML описує відповідність або відображає графічну нотацію в базові поняття семантики. Таким чином, з функціональної точки зору ці дві частини доповнюють одна одну. При цьому семантика мови UML описується на основі деякої мета-моделі, що має три окремих подання: абстрактний синтаксис, правила коректної побудови виразів і семантику. Розгляд семантики мови UML припускає деякий "напівформальний" стиль викладу, що поєднує природну і формальну мови для подання базових понять і правил їхнього розширення.
Семантика визначається для двох видів об'єктних моделей: структурних моделей і моделей поведінки. Структурні моделі, відомі також як статичні моделі, описують структуру сутностей або компонентів деякої системи, включаючи їхні класи, інтерфейси, атрибути й відношення. Моделі поведінки, які називаються інколи динамічними моделями, описують поведінку або функціонування об'єктів системи, включаючи їхні методи, взаємодію й співпрацю між ними, а також процес зміни станів окремих компонентів і системи в цілому.
Для рішення настільки широкого діапазону завдань моделювання розроблена досить повна семантика для всіх компонентів графічної нотації. Вимоги семантики мови UML конкретизуються під час побудови окремих видів діаграм, послідовний розгляд яких служить темою наступних розділів. Нотація мови UML містить в собі опис окремих семантичних елементів, які можуть застосовуватися під час побудови діаграм.
Формальний опис самої мови UML ґрунтується на деякій загальній ієрархічній структурі модельних подань, що складається із чотирьох рівнів:
Мета-Мета-модель
Мета-модель
Модель
Об'єкти користувача
Рівень мета-мета-модель утворює вихідну основу для всіх мета-модельних подань. Головне призначення цього рівня полягає в тому, щоб визначити мову для специфікації мета-моделі. Мета-Мета-модель визначає модель мови UML на найвищому рівні абстракції і є найкомпактнішим її описом. З іншого боку, мета-мета-модель може специфікувати декілька мета-моделей, чим досягається потенційна гнучкість включення додаткових понять. Хоча у цьому навчальному посібнику цей рівень не розглядається, він найбільше тісно пов'язаний з теорією формальних мов. Прикладами понять цього рівня служать мета-клас, мета-атрибут, мета-операція.
Примітка
Слід зазначити, що семантика мета-мета-моделі не входить в опис мови UML. З одного боку, це робить мову UML більш простішою для вивчення, оскільки не вимагає знання загальної теорії формальних мов і формальної логіки. З іншого боку, наявність мета-мета-моделі надає мові UML статус науковості, що необхідна їй для того, щоб бути несуперечливою формальною мовою. Якщо ці особливості можуть бути мало цікавими для багатьох програмістів, то розробники інструментальних засобів ніяк не можуть їх ігнорувати.
Мета-модель є екземпляром або конкретизацією мета-мета-моделі. Головне завдання цього рівня – визначити мову для специфікації моделей. Даний рівень є більше конструктивним, ніж попередній, оскільки володіє більше розвинутою семантикою базових понять. Всі основні поняття мови UML – це поняття рівня мета-моделі. Приклади таких понять – клас, атрибут, операція, компонент, асоціація й багато інших. Саме розгляду семантики й графічної нотації понять рівня мета-моделі присвячені наступні розділи.
Модель у контексті мови UML є екземпляром мета-моделі в тому розумінні, що будь-яка конкретна модель системи повинна використовувати тільки поняття мета-моделі, конкретизувавши їх стосовно до певної ситуації. Це рівень для опису інформації про конкретну предметну область. Однак якщо для побудови моделі використовуються поняття мови UML, необхідна повна погодженість понять рівня моделі з базовими поняттями мови UML рівня мета-моделі. Прикладами понять рівня моделі можуть служити, наприклад, імена полів проектованої бази даних, такі як ім'я й прізвище співробітника, вік, посада, адреса, телефон. При цьому дані поняття використовуються лише як імена відповідних інформаційних атрибутів.
Конкретизація понять моделі відбувається на рівні об'єктів. У справжньому контексті об'єкт є екземпляром моделі, оскільки містить конкретну інформацію про те, чому в дійсності відповідають ті або інші поняття моделі. Прикладом об'єкта може служити наступний запис у проектованій базі даних: "Любомира Лугова, 25 років, викладач, вул. Сихівська, 10- 20, 100-0000".
Опис семантики мови UML припускає розгляд базових понять тільки рівня мета-моделі, що являє собою лише приклад або окремий випадок рівня мета-мета-моделі. Мета-модель UML є за своєю суттю скоріше логічною моделлю, ніж фізичною або моделлю реалізації. Особливість логічної моделі полягає в тому, що вона зосереджує увагу на декларативній або концептуальній семантиці, опускаючи деталі конкретної фізичної реалізації моделей. При цьому окремі реалізації, що використовують дану логічну мета-модель, повинні бути погоджені з її семантикою, а також підтримувати можливості імпорту й експорту окремих логічних моделей.
У той же час, логічна мета-модель може бути реалізована різними способами для забезпечення необхідного рівня продуктивності й надійності відповідних інструментальних засобів. У цьому полягає недолік логічної моделі, яка не містить на рівні семантики вимог, обов'язкових для її ефективної наступної реалізації. Однак погодженість мета-моделі з конкретними моделями реалізації є обов'язковою для всіх розробників програмних засобів, що забезпечують підтримку мови UML.
Мета-модель мови UML має досить складну структуру, що містить у собі 90 мета-класів, більше 100 мета-асоціацій і майже 50 стереотипів, число яких зростає з появою нових версій мови. Щоб впоратися із цією складністю мови UML, всі її елементи організовані в логічні пакети. Тому розгляд мови UML на мета-модальному рівні полягає в описі трьох її найзагальніших логічних блоків або пакетів: основні елементи, елементи поведінки й загальні механізми.
Примітка
Говорячи про пакети в контексті загального опису мови, ми, по суті справи, приступаємо до розгляду графічної нотації мови UML. Справа в тому, що для опису мови UML використовуються засоби самої мови, і одним з таких засобів є пакет. У загальному випадку пакет служить для групування елементів моделі. При цьому самі елементи моделі, якими можуть бути довільні сутності, віднесені до одного пакета, виступають у ролі єдиного цілого. Пакети, так само як і інші елементи моделі, можуть бути вкладені в інші пакети. Важливою особливістю мови UML є той факт, що всі види елементів моделі UML можуть бути організовані в пакети.