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

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

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

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

Існують такі кандидати для класів й об'єктів:

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

Виходячи з перспектив моделювання баз даних кандидатами для класів й об'єктів є:

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

Або:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Це звичайні бібліографічні картки 3х5 дюйми. На картках пишіть (обов'язково олівцем) зверху - назвуа класу, знизу в лівій половині - за що він відповідає, а в правій половині - з ким він співпрацює. Проходячи сценаріями, заводите картки на кожний виявлений клас і дописуєте в неї нові пункти. При цьому щораз обмірковуйте, що із цього виходить, і "виділяйте надлишок відповідальності" у новий клас або, що трапляється найчастіше, перенесіть відповідальності з одного великого класу на детальніші класи, або, можливо, передайте частину обов'язків іншому класу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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