ВІКІСТОРІНКА
Навигация:
Інформатика
Історія
Автоматизація
Адміністрування
Антропологія
Архітектура
Біологія
Будівництво
Бухгалтерія
Військова наука
Виробництво
Географія
Геологія
Господарство
Демографія
Екологія
Економіка
Електроніка
Енергетика
Журналістика
Кінематографія
Комп'ютеризація
Креслення
Кулінарія
Культура
Культура
Лінгвістика
Література
Лексикологія
Логіка
Маркетинг
Математика
Медицина
Менеджмент
Металургія
Метрологія
Мистецтво
Музика
Наукознавство
Освіта
Охорона Праці
Підприємництво
Педагогіка
Поліграфія
Право
Приладобудування
Програмування
Психологія
Радіозв'язок
Релігія
Риторика
Соціологія
Спорт
Стандартизація
Статистика
Технології
Торгівля
Транспорт
Фізіологія
Фізика
Філософія
Фінанси
Фармакологія


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

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

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

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

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

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

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

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

Або:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

© 2013 wikipage.com.ua - Дякуємо за посилання на wikipage.com.ua | Контакти