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

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

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

• Механічний зв'язок між акселератором і карбюратором (звичайне рішення).

• Під педаллю ставиться датчик тиску, що з'єднується з комп'ютером, який керує карбюратором (механізм керування через проводи).

• Карбюратора немає. Бак з пальним перебуває на даху автомобіля й паливо вільно тече у двигун. Потік палива регулюється затискачем на трубці. Натискання на педаль акселератора послабляє затискач (дуже дешево).

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

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

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

Механізми представляють тільки один із шаблонів, які ми знаходимо в структурованих системах. Так, на нижньому кінці своєрідної біологічної піраміди перебувають ідіоми. Наприклад, в CLOS не прийнято використати підкреслення в іменах функцій або змінних, хоча в Ada ця справа звичайна. Вивчаючи мову, доводиться вчити її ідіоми, які звичайно передаються у формі фольклору. Однак, ідіоми відіграють важливу роль в кодифікації шаблонів низького рівня. Багато загально програмістських дій ідіоматичні і тому розпізнання таких ідіом дозволяє використовувати конструкції C++ для вираження функціональності поза самою цією мовою зі збереженням ілюзії, що вони є частиною мови.

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

Якщо ідіоми становлять частину програмістської культури, то середовища розроблення - комерційний продукт. Наприклад, Apple MacApp і його спадкоємець Bedrock - середовища, написані на C++ і призначені для побудови ІС зі стандартним інтерфейсом користувача Macintosh. Аналогічну роль для Windows відіграють Microsoft Foundation Classes і ObjectWindows корпорації Borland.

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

Висновки

1. Ідентифікація класів і об'єктів - найважливіше завдання об’єктно-орієнтованого проектування; процес ідентифікації складається з відкриття й винаходу.

2. Класифікація є проблемою групування (кластеризації) об'єктів.

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

4. Є три підходи до класифікації: класичний розподіл за категоріями (класифікація за властивостями), концептуальна кластеризація (класифікація за поняттями) і теорія прототипів (класифікація за подібністю із прототипом).

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

6. Ключові абстракції відображають словник предметної області; їх шукають в самій області, або придумують у процесі проектування.

7. Механізми позначають стратегічні проектні рішення відносно спільної діяльності об'єктів багатьох різних типів.

Контрольні питання

1. Важливість правильної класифікації.

2. Складнощі класифікації.

3. Ідентифікація класів і об'єктів.

4. CRC-картки.

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

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

РОЗДІЛ 17. Основні компоненти мови UML

• Призначення мови UML

• Загальна структура мови UML

• Пакети в мові UML

• Основні пакети метамоделі мови UML

• Специфіка опису метамоделі мови UML

• Особливості зображення діаграм мови UML

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

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

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

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

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

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

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

Примітка

Назва "фізична модель" у термінології ООАП і мови UML відрізняється від загальноприйнятого трактування цього терміну в загальній класифікації моделей систем. В останньому випадку під фізичною моделлю системи розуміють деяку матеріальну конструкцію, що володіє властивостями подібними з формою оригіналу. Прикладами таких моделей можуть служити моделі технічних систем (літаків, кораблів), архітектурних споруджень (будинків, мікрорайонів). Що стосується використання цього терміну в ООАП і мові UML, тут фізична модель відбиває компонентний склад проектованої системи з погляду її реалізації на деякій технічній базі й обчислювальних платформах конкретних виробників.