5.2.2. Об’єктно-орієнтований аналіз

Межі між стадіями аналізу й проектування розмиті, але роз­в’язувані ними задачі визначаються достатньо чітко. У процесі аналізу ми моделюємо проблему, виявляючи класи й об’єкти, які становлять словник предметної області. Під час об’єктно-орієнтовного проекту­ван­ня ми винаходимо абстракції й механізми, що забезпечують необхідну поведінку.

Розглянемо перевірені практикою підходи до аналізу об’єктно-орієнтовних систем.

Класичні підходи. Різні вчені пропонують різні джерела класів і об’єктів, які необхідні згідно з вимогами предметної області. Ми називаємо ці підходи класичними, оскільки вони спираються на кла­сичну категоризацію.

Розглянемо кандидатів для класів і об’єктів.

Реальні предмети	Автомобілі, телеметричні дані, давачі тиску
Ролі	Мати, вчитель, політик
Події	Приземлення, переривання, запит
Взаємодія	Позика, зустріч, перетин

З огляду на перспективи моделювання баз даних кандидатами для класів й об’єктів є:

Люди	Людські істоти, які виконують певні функції
Місця	Області, пов’язані з людьми або предметами
Предмети	Реальний матеріальний об’єкт або група об’єктів
Організації	Формально організована сукупність людей, ресурсів, устаткування, що має певну мету й існування якої загалом не залежить від індивідуумів
Концепції	Принципи й ідеї, призначені для організації діяльності і/або спілкування, або ж для спостереження за ними
Події	Щось відбулося з чимось у заданий час або послідовно

Або:

Структури	Відношення “ціле–частина” і “загальне–часткове”
Інші системи	Зовнішні системи, з якими взаємодіє інформаційна система
Пристрої	Пристрої, з якими взаємодіє інформаційна система
Події	Події, які мають бути збережені
Виконують функції	Функції, які виконують користувачі, що працюють з інформаційною системою
Місця	Будинки, офіси й інші місця, важливі для функціонування інформаційної системи
Організаційні одиниці	Групи, до яких належать користувачі

На вищому рівні абстракції Коад уводить поняття предметної області, яка є логічно зв’язаною групою класів, які належать до високорівневих функцій системи.

Аналіз поведінки. Тоді як класичні підходи зосереджують ува­гу на реальних елементах предметної області, об’єктно-орієнтовний аналіз зосереджує увагу на динамічній поведінці як на першоджерелі об’єктів і класів. Це нагадує концептуальну кластеризацію, розглянуту вище: ми формуємо класи, ґрунтуючись на групах об’єктів, що прояв­ляють подібну поведінку.

Відповідність об’єкта – його знання і вміння. Відповідність – це спосіб виразити мету об’єкта і його місце в системі. Відповідність об’єкта є сукупністю всіх послуг, які він може надавати за всіма його конт­рактами. Тобто, ми з’єднуємо разом ті об’єкти, які мають подібні відповідності й будуємо ієрархію класів, в якій кожний підклас, вико­нуючи зобов’язання суперкласу, приносить свої додаткові послуги.

Можна ідентифікувати класи й об’єкти, аналізуючи функціо­ну­вання системи. Зіставляємо форму поведінки з частинами системи й на­магаємося зрозуміти, яка частина ініціює поведінку і які частини в ній беруть участь... Ініціатори й учасники, які виконують істотні функ­ції, розпізнаються як об’єкти й стають відповідальними за ці функції.

Функція визначається як окрема бізнес-дія кінцевого корис­тувача, тобто: введення/виведення, запит, файл або інтерфейс. Очевид­но, що ця концепція походить з галузі інформаційних систем. Однак, вона може бути застосована до будь-якої автоматизованої системи. За суттю, функція – це будь-яка видима ззовні поведінка системи, яка стосується справи.

Аналіз предметної області. Дотепер ми неявно мали на увазі розроблення єдиної ІС. Але іноді в пошуках корисних і таких, що вже довели свою працездатність, ідей корисно звернутися відразу до всіх сис­тем, що функціонують у межах цієї предметної області, як, наприк­лад, ведення історій хвороби пацієнтів, торгівля цінними паперами, розроблення компіляторів або системи керування ракетами. Якщо ви перебуваєте в середині розроблення й застрягли, аналіз якої-небудь вузької предметної області може допомогти, вказавши вам на ключові абстракції, які є корисними в подібних системах. Аналіз предметної області працює дуже добре, за винятком спеціальних ситуацій, однак такі унікальні програмні системи трапляються украй рідко.

Ідею аналізу ПО вперше запропонував Нейборс. Визначимо такий аналіз як спробу виділити ті об’єкти, операції й зв’язки, які експерти цієї області вважають найважливішими. Існують такі етапи аналізу ПО:

• побудова скелетної моделі предметної області під час кон­сультацій з експертами цієї області;

• вивчення наявних у цій області систем і подання результатів у стандартному вигляді;

• визначення подібності й відмінностей між системами за участю експертів;

• уточнення загальної моделі для пристосування до потреб конкретної системи.

Аналіз області можна здійснювати щодо аналогічних інфор­маційних систем (вертикально) або щодо аналогічних частин цієї самої інформаційної системи (горизонтально). Наприклад, починаючи про­ек­тувати систему обліку пацієнтів, є сенс розглянути наявні подібні сис­теми, щоб зрозуміти, які ключові абстракції й механізми, вико­ристані в них, будуть корисні, а які ні. Аналогічно система бух­галтерського обліку має відображати різні види звітів. Якщо вважати звіти якоюсь предметною областю, її аналіз може привести розробника до розуміння ключових абстракцій і механізмів, які обслуговують усі види звітів. Отримані в такий спосіб класи й об’єкти є множиною ключових абстракцій і механізмів, відібраних з урахуванням мети вихідної задачі: створення системи звітів. Тому остаточний проект буде простіший.

Визначимо тепер, хто такий експерт? Як експерт часто виступає просто користувач системи, наприклад, інженер або диспетчер. Він не обо­в’язково має бути програмістом, але мусить бути близько знайо­­­мим з досліджуваною проблемою й розмовляти мовою цієї проблеми.

Менеджери проектів зацікавлені в безпосередній співпраці користувачів і розробників системи. Але для дуже складних систем прикладний аналіз є формальним процесом, для якого потрібна велика кількість експертів і розробників на тривалий період. На практиці такий формальний аналіз зрідка потрібний. Зазвичай для початкового з’ясування проблеми досить короткої зустрічі експертів і розробників. Дивно, як мало інформації потрібно для продуктивної роботи розроб­ника. Однак ми вважаємо надзвичайно корисними такі зустрічі протя­гом усього процесу розроблення ІС. Аналіз ПО найкраще здійснювати крок за кроком – трохи проаналізувати, потім спроектувати тощо.

Аналіз варіантів. Окремо класичний підхід, поведінковий підхід і вивчення предметної області, розглянуті вище, дуже залежать від індивідуальних здібностей і досвіду аналітика. Для більшості реаль­них проектів одночасне застосування всіх трьох підходів неприйнятне, тому що процес аналізу стає недетермінованим і непередбачуваним.

Аналіз варіантів – це підхід, який можна успішно об’єднати з першими трьома, роблячи їх застосування впорядкованішим. Варіант застосування – це приватний приклад або зразок використання, сце­нарій, що починається з того, що користувач системи ініціює операцію або послідовність взаємозалежних подій.

Коротко кажучи, цей вид аналізу можна починати разом з аналізом вимог. У цей момент користувачі, експерти й розробники пе­ре­раховують сценарії, найістотніші для роботи системи (не заглиб­лю­ючись у деталі). Потім вони ретельно розробляють сценарії, розклада­ючи їх за кадрами, як роблять телевізійники й кінематографісти. Вони встановлюють, які об’єкти беруть участь у сценарії, які обов’язки кожного об’єкта і як вони взаємодіють у термінах операцій. Тим самим група розробників змушена чітко розподілити області впливу абст­ракцій. Далі набір сценаріїв розширюється, щоб урахувати виняткові ситуації й вторинну поведінку. Як результат з’являються нові або уточнюються наявні абстракції.

CRC-картки. CRC позначає Class-Responsibilities-Collaborators (Клас/Відповідальності/Учасники). Це простий і дуже ефективний спосіб аналізу сценаріїв. Карти CRC вперше запропонували Бек і Кан­нінгхем для навчання об’єктно-орієнтовному програмуванню, але такі картки виявилися чудовим інструментом для мозкових атак і спіл­кування розробників між собою.

Це звичайні бібліографічні картки 35 дюймів. На картках пишуть (обов’язково олівцем) зверху – назву класу, знизу в лівій половині – за що він відповідає, а в правій – з ким він співпрацює. За сценаріями заводять картки на кожний виявлений клас і дописують у нові пункти. Щоразу обмірковують, що з цього виходить, і “виділяють надлишок відповідності” у новий клас або, що трапляється найчастіше, переносять відповідальності з одного великого класу на детальніші класи, або, можливо, передають частину обов’язків іншому класу.

Картки можна розкладати так, щоб уявити форми співпраці об’єктів. Із погляду динаміки сценарію, їх розташування може пока­зати потік повідомлень між об’єктами, з погляду структури – вони відображають ієрархію класів.

Неформальний опис. Радикальна альтернатива класичному аналізу була запропонована в надзвичайно простому методі Аббота. Відповідно до цього методу треба описати завдання або його частину природною мовою, а потім підкреслити іменники й дієслова. Іменни-ки – кандидати на роль класів, а дієслова можуть стати назвами опе­рацій. Метод можна автоматизувати, і така система була побудована в Токійському технологічному інституті.

Підхід Аббота корисний, тому що він простий і змушує роз­робника займатися словником предметної області. Однак він при- б­лизний і непридатний для складних проблем. Природна мова – не­точний засіб вираження, тому список об’єктів і операцій залежить від уміння розроблювача записувати свої думки. До того ж для багатьох іменників можна знайти відповідну дієслівну форму й навпаки.

Структурний аналіз. Інша альтернатива класичній техніці об’єктно-орієнтовного аналізу передбачає структурний аналіз як основу для об’єктно-орієнтовного проектування. Такий підхід приваб­ли­вий тому, що багато аналітиків застосовують його і є значна кіль­кість програмних CASE-засобів, що підтримують автоматизацію цих методів. Нам особисто не подобається використовувати структурний аналіз як основу для об’єктно-орієнтовного проектування, але для деяких організацій такий прагматичний підхід не має альтернативи.

Після здійснення структурного аналізу ми вже маємо модель системи, описану діаграмами потоків даних й іншими продуктами структурного аналізу. Ці діаграми дають нам формальну модель проб­леми. З огляду на моделі, ми можемо приступити до визначення ос­мис­лених класів і об’єктів трьома різними способами.

Насамперед необхідно приступити до формування словника даних, а потім – до аналізу контекстних діаграм моделі. Розглядаючи список основних структур даних, варто подумати, про що в них йдеться або що вони описують. Наприклад, якщо це прикметники, то які іменники вони описують? Відповіді на такі запитання можуть поповнити список об’єктів. Ці кандидати в об’єкти походять із дов­кілля, з істотних вхідних і вихідних даних, а також продуктів, послуг та інших ресурсів.

Наступні два способи ґрунтуються на аналізі окремих діаграм потоків даних. Якщо взяти яку-небудь діаграму потоків, то канди­датами в об’єкти є:

• зовнішні сутності;

• сховища даних;

• сховища керівних сутностей;

• керівні перетворення.

Кандидати у класи:

• потоки даних;

• потоки керування.

Залишається перетворення даних, яке ми можемо розглядати як операції над наявними об’єктами або як поведінка деякого об’єкта, який ми створили спеціально для виконання потрібного перетворення.

Існує ще один метод, який називається аналізом абстракцій. Цей метод ґрунтується на ідентифікації основних сутностей, які за своєю природою аналогічні до основних перетворень у структурному проектуванні. У структурному аналізі вхідні й вихідні дані вивчають доти, доки не досягнуть найвищого рівня абстракції. Процес перетво­рення вхідних даних у вихідні є основним перетворенням. В абстракт­ному аналізі розробник так само вивчає основне перетворення для того, щоб визначити, які процеси й стани відображають найкращу абст­рактну модель системи. Після визначення основної сутності в діа­грамі потоків даних аналітик приступає до вивчення всієї інфра­структури, простежуючи вхідні й вихідні потоки даних з центру, гру­пуючи процеси й стани, що трапляються. Для практичного вико­ристання аналіз абстракцій занадто складний і як альтернативу про­понують об’єктно-орієнтований аналіз (ООА).

Необхідно відзначити, що принципи структурного проекту­ван­ня, яке слідує за структурним аналізом, повністю ортогональні прин­ципам об’єктно-орієнтованого проектування (ООП). Досвід показує, що використання структурного аналізу в процесі ООП часто при­зводить до повного провалу. Інша дуже серйозна небезпека полягає в тому, що багато аналітиків полюбляють рисувати діаграми потоків да­них, які є скоріше описом проекту, ніж моделлю системи. Дуже склад­но побу­дувати об’єктно-орієнтовну систему, якщо модель настільки очевидно орієнтована на алгоритмічну декомпозицію. Тому ми віддаємо перевагу об’єктно-орієнтованому аналізу й аналізу пред­метної області як підготовчому етапу об’єктно-орієнтованого проекту­вання. Зменшу­ється ризик засмітити проект елементами алгорит­мічного аналізу.