PrIS

331

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

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

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

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

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

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

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

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

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

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

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

332

підготовчому етапу об'єктно-орієнтованого проектування. При цьому зменшується ризик засмітити проект елементами алгоритмічного аналізу.

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

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

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

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

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

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

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

333

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

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

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

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

об'єкти варто називати іменниками: theSensor або shape;

класи варто називати узагальненими іменниками: Sensors, Shapes;

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

операції-селектори повинні містити запит або форму дієслова "to be": extentOf, isOpen;

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

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

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

334

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

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

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

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

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

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

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

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

336

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

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

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

4.CRC-картки.

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

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

337

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

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

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

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

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

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

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

Мова UML являє собою загально-цільову мову візуального моделювання, яка розроблена для специфікації, візуалізації, проектування

ідокументування компонентів програмного забезпечення, бізнес-процесів

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

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

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

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

339

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

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

Мова UML призначена для вирішення певних завдань.

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

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

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

Звідси випливає важливий наслідок: для адекватного розуміння базових конструкцій мови UML важливо не тільки володіти деякими навичками об’єктно-орієнтованого програмування, але й добре уявляти собі загальну проблематику процесу розроблення моделей систем. Саме інтеґрація цих подань утворить нову парадигму ООАП, практичним наслідком і центральною ланкою якої є мова UML.

340

2.Постачати вихідні поняття мови UML можливістю розширення і спеціалізації для точнішого подання моделей систем у конкретній предметній області.

Хоча мова UML є формальною мовою специфікацій, формальність

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

Одночасно розробники з OMG вважають вкрай небажаним перевизначення базових понять мови будь-яких причин. Це може привести до неоднозначної інтерпретації і можливої плутанини. Базові поняття мови UML не треба змінювати більше, ніж це необхідно для їхнього розширення. Всі користувачі мають бути здатними будувати моделі систем для більшості звичайних програмних додатків з використанням тільки базових конструкцій мови UML без застосування механізму розширення. При цьому нові поняття й нотації доцільно застосовувати тільки в тих ситуаціях, коли наявних базових понять явно недостатньо для побудови моделей системи.

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

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

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

З іншого боку, мова UML повинна мати потенційну можливість реалізації своїх конструкцій на тій або іншій мові програмування. Звичайно, у першу чергу маються на увазі мови, що підтримують концепцію ООП, такі як C++, Java, Object Pascal. Саме ця властивість мови UML робить її сучасним засобом вирішення завдань моделювання складних систем. Одночасно, передбачається, що для програмної підтримки конструкцій мови UML можуть бути розроблені спеціальні