- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •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
4.1.3. Семантичні мережі
Семантичні мережі отримали свій розвиток в рамках наукового напряму, пов'язаного з представленням знань для моделювання міркувань людини. Ця область наукових досліджень виникла в рамках загальної проблематики штучного інтелекту і була орієнтована на розроблення спеціальних мов і графічних засобів для представлення декларативних знань про предметну область. Результати досліджень в області семантичних мереж в подальшому були конкретизовані і успішно використані під час побудови концептуальних моделей і схем реляційних баз даних.
У загальному випадку під семантичною мережею розуміють деякий граф Gs= =(Vs, Es), у якому множина вершин Vs і множина ребер Es розділені на окремі типи, що володіють спеціальною семантикою, характерною для конкретної предметної області. У цій ситуації множина вершин може відповідати об'єктам або сутностям предметної області і мати замість номерів вершин відповідні явні імена цих сутностей. Подібні імена повинні дозволяти однозначно ідентифікувати відповідні об'єкти, при цьому загальних формальних правил запису імен не існує. Множина ребер також ділиться на різні типи, які відповідають різним видам зв'язків між сутностями цієї предметної області.
Так, під час побудови семантичної мережі для подання знань про робочий персонал деякої компанії в якості об'єктів доцільно вибрати окремих співробітників, кожного з яких ідентифікувати власним іменем і прізвищем. Додатково в мережі можуть бути присутніми такі об'єкти, як робочі проекти і підрозділи компанії. Як семантичні зв'язки можна виділити такі види, як посадове підпорядкування співробітників, участь співробітників у роботі над проектами, приналежність співробітників тому або іншому підрозділу компанії.
Важливою особливістю семантичних мереж є розроблення спеціальних графічних позначень для подання окремих типів вершин і ребер. При цьому вершини не зображаються, як раніше – крапками, а мають вид прямокутників, овалів, кіл і інших геометричних фігур, конкретний вид яких визначає той або інший тип сутності предметної області. Різноманітнішим стає і зображення ребер, що набувають вигляду різних ліній із стрілками або без них, а також що мають спеціальні позначення або прикраси у вигляді умовних значків. Відповідна система позначень, призначена для подання інформації про окремі аспекти модельованої предметної області, отримала назву графічної нотації.
Як конкретний варіант представлення інформації у вигляді семантичної мережі розглянемо приклад з класом "Автомобіль" з розділу 3. Фрагмент семантичної мережі, яка описує ієрархію класів цієї предметної області, може бути зображена таким чином (рис. 4.7). На даному рисунку окремі вершини семантичної мережі зображаються прямокутниками із закругленими кінцями і служать для умовного позначення класів предметної області. З’єднюючі вершини ребра мають цілком певний сенс або семантику. А саме, вони явно вказують, що вершина або клас, розташовані на рисунку нижче, є підкласом класу вищого за рівнем.
Рис 4.7. Фрагмент семантичної мережі для представлення ієрархії класів "Автомобіль"
Наприклад, класи "Легковий автомобіль" і "Вантажний автомобіль" є підкласами класу "Автомобіль", а класи "Модель ВАЗ-21083" і "Модель ВАЗ-21099" є підкласами класу "Легковий автомобіль виробництва ВАЗ". Ребра або зв'язки даної семантичної мережі мають єдиний тип, визначений семантикою включення класів один в одного. Тому ніяких додаткових позначень вони не містять.
Примітка
Зображений вище фрагмент семантичної мережі може бути розширений специфікою вирішуваного завдання. Можна ввести в розгляд додаткові моделі автомобілів, інші типи об'єктів, наприклад, конкретні заводи, розташовані в різних регіонах, або станції, що здійснюють технічне обслуговування автомобілів. У останньому випадку з'являються додаткові зв'язки, які можуть відповідати абсолютно іншій семантиці. Наприклад, факт обслуговування тієї або іншої моделі автомобіля на окремих станціях.
Побудова моделей складних систем, що відображають десятки різних типів об'єктів і зв'язків між ними, привела в кінці 80-х років до появи великого числа різних графічних нотацій, які в тому або іншому ступені були орієнтовані на вирішення спеціальних класів завдань. Склалася парадоксальна ситуація, яка отримала назву "Війни методів". Багато підходів, хоча і мали загальні витоки, абсолютно ігнорували інші альтернативні способи представлення семантичної інформації. Найбільшого поширення в ці роки набув підхід до моделювання програмних систем, який назвали системним структурним аналізом (ССА). Оскільки багато ідей ССА зробили безпосередній вплив на розвиток мови UML, а використовувана графічна нотація була реалізована в деяких CASE-засобах, нижче приводиться коротка характеристика основних компонент цього напряму графічного моделювання програмних систем.