- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •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
14.1. Еволюція об'єктної моделі
14.1.1. Основні положення об'єктної моделі
Методи структурного проектування допомагають спростити процес розроблення складних систем за рахунок використання алгоритмів як готових будівельних блоків. Аналогічно, методи об'єктно-орієнтованого проектування створені, аби допомогти розробникам застосовувати потужні наглядні засоби об'єктного і об'єктно-орієнтованого програмування, що використовує в якості блоків класи і об'єкти.
В об'єктній моделі відображаються й інші фактори. Об'єктний підхід зарекомендував себе як уніфікуюча ідея всієї комп'ютерної науки, яка застосовна не лише в програмуванні, але також в проектуванні інтерфейсу користувача, баз даних і навіть архітектури комп'ютерів. Причина цього в тому, що орієнтація на об'єкти дозволяє нам справлятися із складністю систем самої різної природи.
ООАП відображають еволюційний, а не революційний розвиток проектування; нова методологія не перекреслює попередні методи, а будується з врахуванням попереднього досвіду. На жаль, більшість програмістів в даний час формально і неформально натреновані на вживання лише методів структурного проектування. Зрозуміло, багато хороших проектувальників створили і продовжують удосконалювати велику кількість програмних систем на основі цієї методології. Проте алгоритмічна декомпозиція допомагає лише до певної межі, і звернення до об'єктно-орієнтованої декомпозиції необхідне. Більш того, при спробах використовувати такі мови, як C++ або Ada, як традиційні, алгоритмічно орієнтовані, ми не лише втрачаємо їх внутрішній потенціал - швидше за все результат буде навіть гірше, ніж при використанні звичайних мов С і Pascal. Дати електродриль тесляру, який не чув про електрику, означає використовувати її як молоток. Він зігне декілька цвяхів і розіб'є собі пальці, тому що електродриль мало придатна для заміни молотка.
14.1.2. OOP, OOП і ООА
Успадкувавши від багатьох попередників, об'єктний підхід, на жаль, перейняв і заплутану термінологію. Програміст в Smalltalk користується терміном метод, в C++ - терміном віртуальна функція, в CLOS - узагальнена функція. У Object Pascal використовується термін приведення типів, а в мові Ada те ж саме називається перетворення типів. Аби зменшити плутанину, слід визначити, які властивості є об'єктно-орієнтованими, а які - ні. Визначення найвживаніших термінів і понять ви знайдете в глосарії в кінці книги.
Поняття об'єкту є центральним у всьому, що відноситься до об'єктно-орієнтованої методології. Об'єкт - це сутність, яка чітко проявляє свою поведінку. Визначення об'єкту як сутності деякою мірою відповідає на питання, однак головним в понятті об'єкту є об'єднання ідей абстракції даних і алгоритмів. У об'єктному підході акцент переноситься на конкретні характеристики фізичної або абстрактної системи, що є предметом програмного моделювання... Об'єкти володіють цілісністю, яка не повинна, - а, насправді, не може - бути порушена. Об'єкт може лише міняти стан, мати поведінку, керуватися або перебувати у в певному відношенні з іншими об'єктами. Інакше кажучи, властивості, які характеризують об'єкт і його поведінку, залишаються незмінними. Наприклад, ліфт характеризується тими незмінними властивостями, що він може рухатися вгору і вниз, залишаючись в межах шахти... Будь-яка модель повинна враховувати ці властивості ліфта, оскільки вони входять в його визначення.
Термін "об'єкт" з'явився практично незалежно в різних областях, пов'язаних з комп'ютерами, і майже одночасно на початку 70-х років для позначення того, що може мати різні прояви, залишаючись цілісним. Для того, щоб зменшити складність програмних систем, об'єктами називалися компоненти системи або фрагменти знань. Об'єктно-орієнтований підхід був пов'язаний з такими подіями:
прогрес в області архітектури ЕОМ;
розвиток мов програмування, таких як Simula, Smalltalk, CLU, Ada;
розвиток методології програмування, включаючи принципи модульності і приховування даних.
До цього ще слід додати три моменти, які здійснили значний вплив на становлення об'єктного підходу:
розвиток теорії баз даних;
дослідження в області штучного інтелекту;
досягнення філософії і теорії пізнання.
Поняття "об'єкт" вперше було використане більше 20 років тому під час конструювання комп'ютерів з descriptor-based і capability-based архітектурами. У цих роботах робилися спроби відійти від традиційної архітектури фон Неймана і здолати бар'єр між високим рівнем програмної абстракції і низьким рівнем ЕОМ. На думку прибічників цих підходів, тоді були створені якісніші засоби, що забезпечують: краще виявлення помилок, велику ефективність реалізації програм, скорочення набору інструкцій, спрощення компіляції, зниження об'єму необхідної пам'яті. Ряд комп'ютерів має об'єктно-орієнтовану архітектуру.
З об'єктно-орієнтованою архітектурою тісно пов'язані об'єктно-орієнтовані операційні системи (ОС). Дейкстра, працюючи над мультипрограмною системою THE, вперше ввів поняття машини з рівнями стану як засіб побудови системи. Серед перших об'єктно-орієнтованих ОС слід зазначити: Plessey/System 250 (для мультипроцесора Plessey 250), Hydra (для CMU C.mmp), CALTSS (для CDC 6400), CAP (для комп'ютера Cambridge CAP), UCLA Secure UNIX (для PDP 11/45 і 11/70), STAROS (для CMU Cm*), Medusa (також для CMU Cm*) і iMAX (для Intel 432).
Найзначніший вклад в розвиток об'єктного підходу внесений об'єктними і об'єктно-орієнтованими мовами програмування. Вперше поняття класів і об'єктів введені в мові Simula 67. Система Flex і діалекти Smalltalk-72, що слідували за нею -74, -76 і, нарешті -80, взявши за основу методи Simula, довели їх до логічного завершення, виконуючи всі дії на основі класів. У 1970-х роках створено ряд мов, що реалізовують ідею абстракції даних: Alphard, CLU, Euclid, Gypsy, Mesa і Modula. Потім методи, що використовуються в мовах Simula і Smalltalk, були використані в традиційних мовах високого рівня. Введення об'єктно-орієнтованого підходу в С привело до виникнення мов C++ і Objective С. На основі мови Pascal виникли Object Pascal, Eiffel і Ada. З'явилися діалекти LISP, такі, як Flavors, LOOPS і CLOS (Common LISP Object System), з можливостями мов Simula і Smalltalk.
Першим, хто вказав на необхідність побудови систем у вигляді структурованих абстракцій, був Дейкстра. Пізніше Парнас ввів ідею приховування інформації, а в 70-х роках ряд дослідників, головним чином Лісков, Жиль, Гуттаг, і Шоу розробили механізми абстрактних типів даних. Хоар доповнив ці підходи теорією типів і підкласів.
Технології побудови баз даних також здійснили свій вплив на об'єктний підхід, в першу чергу завдяки так званій моделі "сутність-відношення" (ER, entity-relationship). У моделях ER, вперше запропонованих Ченом, моделювання відбувається в термінах сутностей, їх атрибутів і відношень.
Розробники способів подання даних в області штучного інтелекту також внесли свій вклад в розуміння об'єктно-орієнтованих абстракцій. У 1975 р. Мінські висунув теорію фреймів для представлення реальних об'єктів в системах розпізнавання образів і природних мов. Фрейми стали використовуватися як архітектурна основа в різних інтелектуальних системах.
Об'єктний підхід відомий ще здавна. Грекам належить ідея про те, що світ можна розглядати в термінах як об'єктів, так і подій. А в XVII столітті Декарт відзначав, що люди зазвичай мають об'єктно-орієнтований погляд на світ. У XX столітті цю тему розвинув Ренд у своїй філософії об'єктивістської епістемології. Пізніше Мінські запропонував модель людського мислення, в якій розум людини розглядається як сукупність по-різному мислячих агентів. Він доводить, що лише спільна дія таких агентів приводить до осмисленої поведінки людини.
Об'єктно-орієнтоване програмування.
Об'єктно-орієнтоване програмування - це методологія програмування, заснована на представленні програми у вигляді сукупності об'єктів, кожний з яких є екземпляром певного класу, а класи утворюють ієрархію успадкування.
У цьому визначенні можна виділити три частини: 1) OOP використовує як базові елементи об'єкти, а не алгоритми (ієрархія "бути частиною"); 2) кожний об'єкт є екземпляром якого-небудь певного класу; 3) класи організовані ієрархічно (див. поняття про ієрархію "is_а"). Програма буде об'єктно-орієнтованою лише при дотриманні всіх трьох вказаних вимог. Зокрема, програмування, не засноване на ієрархічних відношеннях, не відноситься до OOP, а називається програмуванням на основі абстрактних типів даних.
Відповідно до цього визначення не всі мови програмування є об'єктно-орієнтованими. Якщо термін об'єктно-орієнтована мова взагалі що-небудь означає, то він повинен означати мову, що має засоби підтримки об'єктно-орієнтованого стилю програмування... Забезпечення такого стилю у свою чергу означає, що в мові зручно користуватися цим стилем. Якщо написання програм в стилі OOP вимагає спеціальних зусиль або воно неможливе зовсім, то ця мова не відповідає вимогам OOP. Теоретично можлива імітація об'єктно-орієнтованого програмування на звичайних мовах, таких, як Pascal і навіть COBOL або асемблер, але це вкрай складно. Мова програмування є об'єктно-орієнтованою тоді і лише тоді, коли виконуються наступні умови:
підтримуються об'єкти, тобто абстракції даних, що мають інтерфейс у вигляді іменованих операцій і власні дані, з обмеженням доступу до них,
об'єкти відносяться до відповідних типів (класів),
nипи (класи) можуть успадковувати атрибути супертипів (суперкласів).
Підтримка успадкування в таких мовах означає можливість встановлення відношення "is-а" ("є", "це є" " - це"), наприклад, червона троянда - це квітка, а квітка - це рослина. Мови, що не мають таких механізмів, не можна віднести до об'єктно-орієнтованих. Карделлі і Вегнер назвали такі мови об'єктними, але не об'єктно-орієнтованими. Згідно цьому визначенню об'єктно-орієнтованими мовами є Smalltalk, Object Pascal, C++ і CLOS, а Ada - об'єктна мова. Але, оскільки об'єкти і класи є елементами обох груп мов, бажано для них використовувати методи об'єктно-орієнтованого проектування.
Об'єктно-орієнтоване проектування. Програмування перш за все має на увазі правильне і ефективне використання механізмів конкретних мов програмування. Проектування, навпаки, основну увагу приділяє правильній і ефективній структуризації складних систем.
Об'єктно-орієнтоване проектування - це методологія проектування, що об’єднює в собі процес об'єктної декомпозиції і прийоми подання логічної, фізичної, статичної і динамічної моделей проектованої системи.
У цьому означенні містяться дві важливі частини: об'єктно-орієнтоване проектування 1) ґрунтується на об'єктно-орієнтованій декомпозиції; 2) використовує різні прийоми представлення моделей, що відображають логічну (класи і об'єкти) та фізичну (модулі і процеси) структуру системи, а також її статичні і динамічні аспекти.
Саме об'єктно-орієнтована декомпозиція відрізняє об'єктно-орієнтоване проектування від структурного; у першому випадку логічна структура системи відображається абстракціями у вигляді класів і об'єктів, в другому - алгоритмами. Інколи ми використовуватимемо абревіатуру OOП, для позначення методу об'єктно-орієнтованого проектування.
Об'єктно-орієнтований аналіз. На об'єктну модель вплинула модель життєвого циклу програмного забезпечення. Традиційна техніка структурного аналізу заснована на потоках даних в системі. Об'єктно-орієнтований аналіз (або OOA, object-oriented analysis) направлений на створення моделей реальної дійсності на основі об'єктно-орієнтованого світогляду.
Об'єктно-орієнтований аналіз - це методологія, в якій вимоги до системи сприймаються з точки зору класів і об'єктів, виявлених в предметній області.
Як співвідносяться ООА, OOП і OOP? На результатах ООА формуються моделі, на яких ґрунтується OOП; OOП у свою чергу створює фундамент для остаточної реалізації системи з використанням методології OOP.