План
Введення
1. Сутність об'єктно-орієнтованого підходу
2. Основні поняття об'єктно-орієнтованого підходу - об'єкт і клас
3. Уніфікована мова моделювання UML
4. Види діаграм
4.1 Діаграма класів
4.2 Діаграма взаємодії
5. Приклад використання об'єктно-орієнтованого підходу
Висновки
Введення
Принципова відмінність між структурними та об'єктно-орієнтованим підходом полягає в способі декомпозиції системи. Об'єктно-орієнтований підхід використовує об'єктну декомпозицію, при цьому статична структура системи описується в термінах об'єктів і зв'язків між ними, а поведінка системи описується в термінах обміну повідомленнями між об'єктами. Кожен об'єкт системи має своєю власною поведінкою, моделюючим поведінку об'єкта реального світу. Поняття "об'єкт" вперше було використано близько 30 років тому в технічних засобах при спробах відійти від традиційної архітектури фон Неймана і подолати бар'єр між високим рівнем програмних абстракцій і низьким рівнем абстрагування на рівні комп'ютерів. З об'єктно-орієнтованою архітектурою також тісно пов'язані об'єктно-орієнтовані операційні системи. Однак найбільш значний внесок в об'єктний підхід був внесений об'єктними та об'єктно-орієнтованими мовами програмування: Simula, Smalltalk, C + +, Object Pascal. На об'єктний підхід вплинули також розвивалися досить незалежно методи моделювання баз даних, особливо підхід "сутність-зв'язок".
Концептуальною основою об'єктно-орієнтованого підходу є об'єктна модель. Основними її елементами є:
• абстрагування (abstraction);
• інкапсуляція (encapsulation);
• модульність (modularity);
• ієрархія (hierarchy).
Крім основних є ще три додаткові елементи, які не є на відміну від основних строго обов'язковими:
• типізація (typing),
• паралелізм (concurrency),
• стійкість (persistence).
Абстрагування - це виділення істотних характеристик деякого об'єкта, які відрізняють його від усіх інших видів об'єктів і, таким чином, чітко визначають його концептуальні кордону щодо подальшого розгляду та аналізу. Абстрагування концентрує увагу на зовнішніх особливостях об'єкта і дозволяє відокремити найістотніші особливості його поведінки від деталей їхньої реалізації. Вибір правильного набору абстракцій для заданої предметної області являє собою головне завдання об'єктно-орієнтованого проектування.
Інкапсуляція - це процес відокремлення один від одного окремих елементів об'єкта, що визначають його пристрій і поведінку. Інкапсуляція служить для того, щоб ізолювати інтерфейс об'єкта, що відображає його зовнішнє поводження, від внутрішньої реалізації об'єкта. Об'єктний підхід передбачає, що власні ресурси, якими можуть маніпулювати тільки методи самого класу, сховані від зовнішнього середовища. Абстрагування і інкапсуляція є взаємодоповнюючими операціями: абстрагування фокусує увагу на зовнішніх особливостях об'єкта, а інкапсуляція (чи, інакше, обмеження доступу) не дозволяє об'єктам-користувачам розрізняти внутрішній устрій об'єкта.
1. Сутність об'єктно-орієнтованого підходу
Модульність - це властивість системи, пов'язане з можливістю її декомпозиції на ряд внутрішньо зв'язкових, але слабко пов'язаних між собою модулів. Інкапсуляція і модульність створюють бар'єри між абстракціями.
Ієрархія - це ранжируваних або упорядкована система абстракцій, розташування їх по рівнях. Основними видами ієрархічних структур стосовно до складних систем є структура класів (ієрархія по номенклатурі) і структура об'єктів (ієрархія по складу). Прикладами ієрархії класів є просте і множинне спадкування (один клас використовує структурну або функціональну частину відповідно одного або декількох інших класів), а ієрархії об'єктів - агрегація.
Типізація - це обмеження, що накладається на клас об'єктів і перешкоджає взаємозамінності різних класів (або сильно звужуюче її можливість). Типізація дозволяє захиститися від використання об'єктів одного класу замість іншого чи принаймні керувати таким використанням.
Паралелізм - властивість об'єктів перебувати в активному або пасивному стані і розрізняти активні і пасивні об'єкти між собою.
Стійкість - властивість об'єкта існувати в часі (поза залежністю від процесу, який породив даний об'єкт) і / або в просторі (при переміщенні об'єкта з адресного простору, в якому він був створений).
2. Основні поняття об'єктно-орієнтованого підходу - об'єкт і клас
Об'єкт визначається як відчутна реальність (tangible entity) - предмет чи явище, що мають чітко визначається поведінка. Об'єкт має статки, поведінкою і індивідуальністю; структура і поведінка схожих об'єктів визначають загальний для них клас. Терміни "екземпляр класу" і "об'єкт''є еквівалентними. Стан об'єкта характеризується переліком всіх можливих (статичних) властивостей даного об'єкта і поточними значеннями (динамічними) кожного з цих властивостей. Поведінка характеризує вплив об'єкта на інші об'єкти і навпаки щодо зміни стану цих об'єктів і передачі повідомлень. Інакше кажучи, поведінка об'єкту повністю визначається його діями. Індивідуальність - це властивості об'єкта, що відрізняють його від усіх інших об'єктів.
Певний вплив одного об'єкта на інший з метою викликати відповідну реакцію називається операцією. Як правило, в об'єктних і об'єктно-орієнтованих мовах операції, що виконуються над даним об'єктом, називаються методами і є складовою частиною визначення класу.
Клас - це безліч об'єктів, пов'язаних спільністю структури і поведінки. Будь-який об'єкт є екземпляром класу. Визначення класів і об'єктів - одна з найскладніших завдань об'єктно-орієнтованого проектування.
Наступну групу важливих понять об'єктного підходу складають успадкування і поліморфізм. Поняття поліморфізму може бути інтерпретоване як здатність класу належати більш ніж одному типу.
Спадкування означає побудову нових класів на основі існуючих з можливістю додавання або перевизначення даних і методів.
Об'єктно-орієнтована система спочатку будується з урахуванням її еволюції. Успадкування та поліморфізм забезпечують можливість визначення нової функціональності класів за допомогою створення похідних класів - нащадків базових класів. Нащадки успадковують характеристики батьківських класів без зміни їх первісного опису і додають при необхідності власні структури даних і методи. Визначення похідних класів, при якому задаються тільки відмінності або уточнення, у величезній мірі економить час і зусилля при виробництві та використанні специфікацій та програмного коду.
Важливою якістю об'єктного підходу є узгодженість моделей діяльності організації і моделей проектованої системи від стадії формування вимог до стадії реалізації. Вимога узгодженості моделей виконується завдяки можливості застосування абстрагування, модульності, поліморфізму на всіх стадіях розробки. Моделі ранніх стадій можуть бути безпосередньо піддані порівнянні з моделями реалізації. За об'єктним моделями може бути простежено відображення реальних сутностей модельованої предметної області (організації) в об'єкти і класи інформаційної системи.
3. Уніфікована мова моделювання UML
Більшість існуючих методів об'єктно-орієнтованого аналізу і проектування (ООАП) включають як мова моделювання, так і опис процесу моделювання. Мова моделювання - це нотація (в основному графічна), яка використовується методом для опису проектів. Нотація являє собою сукупність графічних об'єктів, які використовуються в моделях; вона є синтаксисом мови моделювання. Наприклад, нотація діаграми класів визначає, яким чином подаються такі елементи і поняття, як клас, асоціація і множинність. Процес - це опис кроків, які необхідно виконати при розробці проекту.
Уніфікована мова моделювання UML (Unified Modeling Language) - це наступник того покоління методів ООАП, які з'явилися в кінці 80-х і початку 90-х рр.. Створення UML фактично почалося в кінці 1994 р., коли Граді Буч і Джеймс Рамбо почали роботу по об'єднанню методів Booch і ОМТ (Object Modeling Technique) під егідою компанії Rational Software. До кінця 1995 р. вони створили першу специфікацію об'єднаного методу, названого ними Unified Method, версія 0.8. Тоді ж, у 1995 р., до них приєднався творець методу OOSE (Object-oriented Software Engineering) Івар Якобсон.
Таким чином, UML є прямим об'єднанням і уніфікацією методів Буча, Рамбо і Якобсона, однак доповнює їх новими можливостями. Головними в розробці UML були наступні цілі:
• надати користувачам готовий до використання виразну мову візуального моделювання, що дозволяє розробляти осмислені моделі та обмінюватися ними;
• передбачити механізми розширюваності і спеціалізації для розширення базових концепцій;
• забезпечити незалежність від конкретних мов програмування і процесів розробки;
• забезпечити формальну основу для розуміння цієї мови моделювання;
(Мова повинна бути одночасно точним і доступним для розуміння, без зайвого формалізму);
Певний вплив одного об'єкта на інший з метою викликати відповідну реакцію називається операцією. Як правило, в об'єктних і об'єктно-орієнтованих мовах операції, що виконуються над даним об'єктом, називаються методами і є складовою частиною визначення класу.
Клас - це безліч об'єктів, пов'язаних спільністю структури і поведінки. Будь-який об'єкт є екземпляром класу. Визначення класів і об'єктів - одна з найскладніших завдань об'єктно-орієнтованого проектування.
Наступну групу важливих понять об'єктного підходу складають успадкування і поліморфізм. Поняття поліморфізму може бути інтерпретоване як здатність класу належати більш ніж одному типу.
Спадкування означає побудову нових класів на основі існуючих з можливістю додавання або перевизначення даних і методів.
Об'єктно-орієнтована система спочатку будується з урахуванням її еволюції. Успадкування та поліморфізм забезпечують можливість визначення нової функціональності класів за допомогою створення похідних класів - нащадків базових класів. Нащадки успадковують характеристики батьківських класів без зміни їх первісного опису і додають при необхідності власні структури даних і методи. Визначення похідних класів, при якому задаються тільки відмінності або уточнення, у величезній мірі економить час і зусилля при виробництві та використанні специфікацій та програмного коду.
Важливою якістю об'єктного підходу є узгодженість моделей діяльності організації і моделей проектованої системи від стадії формування вимог до стадії реалізації. Вимога узгодженості моделей виконується завдяки можливості застосування абстрагування, модульності, поліморфізму на всіх стадіях розробки. Моделі ранніх стадій можуть бути безпосередньо піддані порівнянні з моделями реалізації. За об'єктним моделями може бути простежено відображення реальних сутностей модельованої предметному області (організації) в об'єкти і класи інформаційної системи.
4. Види діаграм
4.1 Діаграма класів
Діаграми класів є центральною ланкою об'єктно-орієнтованих методів. Діаграма класів визначає типи об'єктів системи і різного роду статичні зв'язки, які існують між ними. Є два основних види статичних зв'язків:
• асоціації (наприклад, клієнт може зробити замовлення);
• підтипи (приватний клієнт є різновидом клієнта).
Рис.1 Діаграма класів
На діаграмах класів зображуються також атрибути класів, операції класів та обмеження, які накладаються на зв'язку між об'єктами.
На рис.1 зображена типова діаграма класів. Перед тим як приступити до опису діаграм класів, слід звернути увагу на один важливий момент, пов'язаний з характером використання цих діаграм розробниками. Цей момент звичайно ніяк не документується, однак робить істотний вплив на спосіб інтерпретації діаграм і тому має ножне відношенню до того, що описується за допомогою моделі.
Побудова діаграм класів можна розглядати в різних аспектах:
концептуальний аспект - діаграми класів відображають поняття досліджуваної предметної області (моделюється організації). Ці поняття, природно, будуть відповідати реалізують їх класам, однак таке пряме відповідність часто відсутня. Насправді концептуальна модель може мати вельми слабке відношення або взагалі не мати ніякого відношення до реалізовує її програмному забезпеченню, тому її можна розглядати як не залежну від засобів реалізації (мови програмування);
аспект специфікації - модель спускається на рівень ПО, але розглядаються тільки інтерфейси, а не програмна реалізація класів (під інтерфейсом тут розуміється набір операцій класу, видимих ззовні);
аспект реалізації - модель дійсно визначає реалізацію класів ПЗ. Цей аспект найбільш важливий для програмістів.
Розуміння аспекту має велике значення як для побудови, так і для читання діаграм класів. На жаль, відмінності між аспектами не настільки виразні, і більшість розробників при побудові діаграм допускають їх змішання.
При побудові діаграми необхідно вибрати єдиний аспект. При читанні діаграми слід з'ясувати, на підставі будь аспектом вона будувалася. Якщо потрібно інтерпретувати цю діаграму правильним чином, то без такого знання не обійтися.
Точка зору на діаграми класів, не будучи власне формальною частиною UML, однак при побудові та аналізі моделей є вкрай важливою. Конструкції UML можна використовувати з будь-якою з трьох точок зору. Більшість досвідчених розробників-програмістів воліють аспект реалізації. З іншого боку, очевидно, що побудова діаграм класів на стадії формування вимог до ПЗ повинно виконуватися з концептуальної точки зору.
На рис.1 зображена проста модель класів, пов'язана з обробкою замовлень клієнтів. Опишемо кожен фрагмент моделі і розглянемо його можливу інтерпретацію з різних точок зору.
Асоціації представляють собою зв'язки між екземплярами класів (особистість працює в компанії, компанія має ряд офісів).
З концептуальної точки зору асоціації представляють собою концептуальні зв'язки між класами. На діаграмі показано, що Замовлення має надійти від єдиного Клієнта, а Клієнт протягом деякого часу може зробити кілька Замовлень. Кожен з цих Замовлень містить кілька Строк замовлення, кожна з яких відповідає єдиному Продукту.
Кожна асоціація володіє двома ролями; кожна роль представляє собою напрямок асоціації. Таким чином, асоціація між Клієнтом і Замовленням містить дві ролі: одна від Клієнта до Замовлення, інша - від Замовлення до Клієнта.
Роль може бути явно пойменована за допомогою мітки. Наприклад, роль асоціації в напрямку від Замовлення до рядків замовлення називається "позиція замовлення". Якщо ця позначка відсутня, ролі присвоюється ім'я клас - цілі - таким чином, роль асоціації від Замовлення до Клієнту може бути названа Клієнт (терміни "початок" (source) і "мета" (target) вживаються для позначення класів, є відповідно початковим і кінцевим для асоціації).
4.2 Діаграма взаємодії
Діаграми взаємодії (interaction diagrams) є моделями, що описують поведінку взаємодіючих груп об'єктів.
Як правило, діаграма взаємодії охоплює поведінку об'єктів в рамках тільки одного варіанту використання. На такій діаграмі відображаються ряд об'єктів і ті повідомлення, якими вони обмінюються між собою.
Проілюструємо цей підхід на прикладі достатньо найпростішого варіанту використання, який описує таких дій:
Вікно вводу Замовлення посилає Замовленню повідомлення "приготуватися".
Замовлення посилає дане повідомлення кожної Строке замовлення в даному Замовленні.
Кожна Рядок замовлення перевіряє стан певного Запасу товару:
Якщо дана перевірка задовольняється (результат - true), то Рядок замовлення видаляє відповідну кількість товару з Запасу.
В іншому випадку кількість Запасу знижується до рівня повторного замовлення, і Запас запитує нову поставку товару.
Існують два види діаграм взаємодії: діаграми послідовності (sequence diagrams) і кооперативні діаграми (collaboration diagrams).
На діаграмі послідовності об'єкт зображується у вигляді прямокутника на вершині пунктирною вертикальної лінії (рис.2).
Ця вертикальна лінія називається лінією життя (lifeline) об'єкта. Вона являє собою фрагмент життєвого циклу об'єкта в процесі взаємодії. Таку форму представлення вперше ввів Івар Якобсон.
Рис.2 Діаграма послідовності
Кожне повідомлення представляється у вигляді стрілки між лініями життя двох об'єктів. Повідомлення з'являються в тому порядку, як вони показані на сторінці - зверху вниз. Кожне повідомлення позначається, як мінімум, ім'ям повідомлення; при бажанні можна додати також аргументи і деяку керуючу інформацію і, крім того, можна показати саме делегування (self - delegation) - повідомлення, яке об'єкт посилає самому собі, при цьому стрілка повідомлення вказує на ту ж саму лінію життя.
З усієї можливої інформації, що управляє два її види мають істотне значення. По-перше, це умова, що показує, коли надсилається повідомлення (наприклад, [нуженПовторнийЗаказ = "true"]). Повідомлення надсилається тільки при виконанні цієї умови. Інший корисний керуючий маркер - це маркер ітерації, що показує, що повідомлення надсилається багато разів для безлічі об'єктів-адресатів (наприклад, * приготуватися).
Діаграми послідовності дуже прості і наочні (в цьому полягає найбільше їх гідність) та суттєво допомагають розібратися в процесі поведінки системи.
Діаграма (див. рис.2) містить повернення, що означає не нове повідомлення, а повернення з повідомлення. На діаграмі повернення відрізняється від звичайних повідомлень тим, що його стрілка не суцільна, а має вигляд пари ліній.
Діаграми послідовності можна також використовувати для представлення паралельних процесів.
На рис.3 зображено ряд об'єктів, що беруть участь у перевірці банківської транзакції. У момент створення Транзакції вона породжує Координатор Транзакції з метою координації перевірок, виконаних транзакцій. Цей координатор створює кілька об'єктів транзакційного Контролера (в даному випадку два об'єкти), кожен з яких відповідає за певну перевірку. Такий процес полегшує створення різних додаткових процесів перевірки, оскільки кожна перевірка викликається асинхронно і виконується паралельно з іншими.
Рис.3 Паралельні процеси та активізації
Коли Перевірка Транзакції завершується, вона посилає відповідне повідомлення Координатору Транзакції. Координатор перевіряє, чи всі перевірки повідомили про своє виконання. Якщо ні, то координатор не виконує ніяких дій. Якщо ж всі перевірки завершилися успішно, як в даному випадку, то координатор повідомляє Транзакції про нормальне завершення.
У діаграму послідовності на рис.3 введено ряд нових елементів. По-перше, це активізації, що з'являються явно в тому випадку, коли метод стає активним або під час його виконання, або при очікуванні результату виконання будь-якої процедури. По-друге, половинні стрілки позначають асинхронні повідомлення. Асинхронне повідомлення не блокує роботу викликає об'єкта. Таким чином, він може продовжувати свій власний процес. Асинхронне повідомлення може виконувати одну з трьох функцій:
• створювати нову гілку процесу (в цьому випадку воно пов'язане із самою верхньою частиною активізації);
• створювати новий об'єкт;
• встановлювати зв'язок з уже виконується гілкою процесу.
Видалення об'єкта показано за допомогою великого знаку "X". Об'єкти можуть виконати самознищення або можуть бути знищені за допомогою ще одного повідомлення.
Використовуючи механізм активізації, можна більш чітко показати сенс саме делегування. Без них, або без такого позначення за допомогою стовпчиків, яке тут використовується, досить важко визначити, де ж виконуються наступні після саме делегування виклики - чи то в зухвалій методі, чи то в викликається методі. Активізації вносять ясність у це питання.
5. Приклад використання об'єктно-орієнтованого підходу
Рис.4 Початкова діаграма варіантів використання
В якості предметної області розглядається робота підрозділу обліку платників податків-організацій.
На початковій стадії (або стадії формування вимог) будується початкова діаграма варіантів використання (рис. 4).
При побудові діаграми варіантів використання в першу Черга складається список всіх основних діючих осіб (фізичних осіб або зовнішніх систем, які будуть взаємодіяти зі створюваною системою). Їх можна ідентифікувати, задаючи наступні питання:
• Хто використовує систему безпосередньо?
• Хто відповідає за експлуатацію системи?
• Яке зовнішнє обладнання використовується системою?
• Які інші системи взаємодіють з даною системою?
Варіанти використання ідентифікуються виходячи з таких міркувань: кожен варіант використання являє собою деяку функцію, виконувану системою у відповідь на вплив діючої особи, і характеризує конкретний спосіб застосування системи, діалог між дійовою особою і системою. Потрібно також мати на увазі, що згодом варіанти використання будуть служити для опису вимог до системи, спілкування з кінцевими користувачами і експериментами предметної області, а також для тестування системи.
На стадії проектування уточнюється діаграма варіантів використання і будується архітектура системи, основою якої є діаграми класів. У даному прикладі обмежимося побудовою діаграми класів і діаграми взаємодії. Діаграми взаємодії будуються для уточнення діаграми варіантів використання і переходу до діаграм класів. Так, діаграма послідовності (мал. 5) ілюструє один з можливих сценаріїв розвитку подій у рамках варіанту використання "Зареєструвати платника податків". Передбачається, що платник податку ставиться на облік вперше і всі його документи в повному порядку.
Структура програмної системи описується за допомогою декількох діаграм класів, головна з яких представляє собою діаграму пакетів, а інші діаграми розкривають зміст кожного з пакетів. При побудові діаграми класів предметної області виділення цих класів (класів-сутностей) може бути аналогічно виділенню сутностей в процесі моделювання даних. Дані класи повинні мати концептуальний характер і відповідати на запитання "що?", А не "як?". Початковий список може бути складений таким чином:
• в описі вихідних даних виділяються кандидати в класи-іменники, які потенційно можуть відповідати класам (при цьому слід пам'ятати, що іменники можуть також відноситися до об'єктів, асоціаціям чи атрибутам класів);
• аналізуються ролі кандидатів в системі. Кожен клас повинен виконувати деякі дії і взаємодіяти з іншими класами. Кожен клас повинен мати унікальне ім'я, що відображає характер абстракції, що подається даними класом. Якщо класу важко придумати коротке і змістовне ім'я, то це є характерною ознакою невдалого виділення класу. Розглядається кожна можлива пара класів і встановлюється існування асоціації між ними (за аналогією з встановленням зв'язків між сутностями в процесі моделювання даних). Присвоюються найменування ролям асоціацій, і визначається їх множинність.
Рис.5 Діаграма послідовності для варіанту використання "Зареєструвати платника податків"
Далі складається список атрибутів кожного класу (за аналогією з визначенням атрибутів сутностей при моделюванні даних). Процес визначення атрибутів повинен бути нетривалим, оскільки істотні атрибути може бути додано згодом. При цьому слід переконатися, що не пропущені істотні характеристики, представлені у вихідних даних.
Рис.6 Діаграма класів предметної області
Визначаються дії (операції), що виконуються кожним класом. При визначенні операцій потрібно враховувати наступні рекомендації:
• кожна операція повинна виконувати одну просту функцію;
• назва операції має відображати результат функції, а не те, як вона виконується.
Прикладами простих операцій можуть бути: отримати значення атрибуту, встановити значення атрибуту, додати або виключити зв'язок з іншим об'єктом, видалити даний об'єкт.
Отримана в результаті діаграма класів предметної області показана на рис.6
Висновки
Перспектива розвитку об'єктно-орієнтованого методу проектування досить велика. Його відрізняє наступне: "об'єктно-орієнтовані системи більш відкриті і легше піддаються внесенню змін, оскільки їх конструкція базується на стійких формах. Це дає можливість системі розвиватися поступово і не призводить до повної її переробки навіть у разі істотних змін вихідних вимог." До недоліків відносяться: деяке зниження продуктивності функціонування ПЗ і високі початкові витрати, ці недоліки не настільки істотні в цілому і на чаші терезів перевага буде на бік плюсів.