ТЕХНОЛОГІЇ МЕНЕДЖМЕНТУ ЗНАНЬ

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

Теорія прототипів. Класична категоризація й концептуальна кластеризація – доволі виразні методи, цілком придатні для проектування складних програмних систем. Але є ситуації, в яких ці методи не працюють. Розглянемо найсучасніший метод класифікації, теорію прототипів, передумови якої можна знайти у книзі з психології сприйняття [21].

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

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

Поняття властивостей взаємодії – центральне для теорії прототипів. У концептуальній кластеризації ми групуємо об’єкти відповідно до різних концепцій. У теорії прототипів класифікація об’єктів здійснюється за ступенем їх подібності до конкретного прототипу.

Застосування класичних і нових теорій. Три розглянуті під-

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

171

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

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

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

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

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

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

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

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

172

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

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

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

173

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

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

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

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

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

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

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

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

174

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

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

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

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

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

175

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

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

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

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

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

176

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

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

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

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

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

зовнішні сутності; сховища даних;

сховища керівних сутностей; керівні перетворення. Кандидати у класи:

потоки даних; потоки керування.

177

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

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

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

5.3. Ключові абстракції й механізми

5.3.1. Ключові абстракції

Пошук і вибір ключових абстракцій. Ключова абстракція –

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

178

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

Як ми вже відзначали, визначення ключових абстракцій передбачає два процеси: відкриття й винахід. Ми відкриваємо абстракції, слухаючи фахівців із ПО: якщо експерт про неї говорить, то ця абстракція дійсно важлива. Винаходячи, ми створюємо нові класи і об’єкти, які не обов’язково є частиною предметної області, але корисні під час проектування або реалізації системи. Наприклад, користувач банкомату говорить “рахунок, зняти, покласти”; ці терміни – частина словника предметної області. Розробник системи використовує їх, але додає свої, такі як база даних, диспетчер екрану, список, тощо. Ці ключові абстракції створені вже не предметною областю, а проектуванням.

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

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

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

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

179

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

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

Існують такі правила:

об’єкти варто називати іменниками: theSensor або shape; класи – узагальненими іменниками: Sensors, Shapes;

операції-модифікатори називають активними дієсловами: Draw, moveLeft;

операції-селектори повинні містити запит або форму дієслова

“to be”: extentOf, isOpen;

підкреслення й використання великих літер – на ваш розсуд, намагайтеся лише не суперечити самі собі.

5.3.2. Ідентифікація механізмів

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

Розглянемо вимогу до автомобіля: натискання на акселератор має приводити до збільшення обертів двигуна, а відпускання акселератора – до їх зменшення. Як це відбувається, водієві зовсім байдуже. Може бути використаний будь-який механізм, який забезпечує потрібну поведінку, і його вибір – справа смаку розробника. Наприклад, припустимо кожне із запропонованих нижче інженерних рішень:

180