4.5.3. Ідентифікація класів предметної області. Uml-діаграми ієрархії класів: моделювання підсистем, класів та зв’язків між ними

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

• класична категоризація;

• концептуальна кластеризація;

• теорія прототипів.

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

Класична категоризація прийшла до нас від Платона й Аристотеля. Останній у своїй класифікації рослин і тварин користувався технікою міркувань, що нагадує сучасну дитячу гру в 20 питань (Це мінерал, тварина чи рослина? Це покрито хутром чи пір'ям? Чи може воно літати? Чи пахне воно?). Такий підхід знайшов послідовників, найвидатнішими з яких були: Фома Аквінський, Декарт, Локк. За твердженням Фоми Аквінського: "Ми можемо йменувати речі відповідно до наших знань про їх природу, яку отримуємо через пізнання їх властивостей і дій".

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

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

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

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

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

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

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

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

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

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

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

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

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

Діаграма класів (англ. Class diagram) — статичне представлення структури моделі в UML. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм.

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

На діаграмі класи представлені у вигляді прямокутників, які містять три відділення:

Відображення класу з трьома відділеннями.

• Верхня частина містить назву класу. Вона надрукована напівжирним шрифтом і вирівняна по центру, починається з великої літери.

• Середнє відділення містить атрибути класу. Вони вирівняні по лівому краю і перша літера мала.

• Нижній відсік містить операції, які може виконувати клас. Вони також вирівняні по лівому краю і перша літера мала.

Можливо додання четветого відділення, яке містить коментарі.

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

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

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

Підсистема в UML розглядається як різновид пакета, який має самостійну функцію.

Групування в пакети може бути вкладеним, тобто складовими пакетів можуть бути класи, інші пакети та підсистеми.

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

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

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

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

Пакет, який є підсистемою або системою, зображається прямокутником з закругленими кутами.

Над прямокутником ліворуч зверху розміщується менший за розміром прямокутник, в якому подається стереотип пакета та його назва. Якщо елементи, включені до пакета, не показують, його назва розміщується у великому прямокутнику. На рис. 5.15 показано пакет, названий А 1, до котрого включено пакет В 1, клас К 1 та підсистему С 1.

Серед фіксованих стереотипів для позначення різновидів пакета введено такі: <<система>>, <<прикладна система>>, <<підсистема>>, <<елемент конфігурації>>, <<складова системи>>, <<охоплююча система>>, <<фасад>> (facade — пакет, який є інтерфейсом іншого пакета), <<каркас>> (framework — типовий зразок взаємодії об’єктів, детальніше див. п. 7.3.8.), <<заглушка>> (stub — позначення пакета, який буде описано пізніше) тощо.

Між пакетами може бути встановлено відношення з відповідними стереотипами. Наприклад, відношення А «імпортує» Б означає, що визначені в пакеті Б класи можна використовувати в класах пакета А.

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

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

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

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

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

Діаграма класів (англ. Class diagram) — статичне представлення структури моделі в UML. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм.

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

На діаграмі класи представлені у вигляді прямокутників, які містять три відділення:

• Верхня частина містить назву класу. Вона надрукована напівжирним шрифтом і вирівняна по центру, починається з великої літери.

• Середнє відділення містить атрибути класу. Вони вирівняні по лівому краю і перша літера мала.

• Нижній відсік містить операції, які може виконувати клас. Вони також вирівняні по лівому краю і перша літера мала.

Можливо додання четветого відділення, яке містить коментарі.

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

Для подальшого опису поведінки систем діаграми класів можуть бути доповнені діаграмою станів автомата або машиною станів UML.

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

Наприклад, у системі роботи з даними про персонал фірми може бути клас Employee (Співробітник). Він містить такі дані, як ідентифікаційний номер співробітника, його ім'я, адресу і номер телефону. Клас Employee має свою поведінку. Також вважається, що даний клас володіє знаннями про те, як найняти або звільнити співробітника, а також підвищити його по службі. У мові UML класи зображають за допомогою нотації:

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

Виявлення класів

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

• дійова особа; клас;

• атрибут класу;

• вираз, що не є дійовою особою, класом або атрибутом.

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

Процес створення діаграми класів, як правило викликає необхідність додавання нових класів у модель.

Спершу на діаграму розміщують стандартний клас. Це можна зробити декількома способами: за допомогою панелі інструментів, браузера і меню.

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

Стереотипи класів – це механізм, що дозволяє розділяти класи на категорії. У мові UML основними стереотипами є: Boundary (граничні), Entity (сутність) і Control (управління).

Граничні класи (boundary classes) – це класи, які розташовані на межі системи і навколишнього середовища. Вони включають усі форми, звіти, інтерфейси з апаратурою (такі, як принтери або сканери) та інтерфейси з іншими системами.

Для того, щоб знайти граничні класи, треба дослідити діаграми варіантів використання. Кожній взаємодії між дійовою особою і варіантом використання повинен відповідати принаймні один граничний клас. Саме такий клас дозволяє дійовій особі взаємодіяти із системою.

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

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

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

Управляючі класи (control classes) відповідають за координацію дій інших класів. Зазвичай у кожного варіанта використання є один управляючий клас, який контролює послідовність подій цього

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

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

Крім згаданих вище стереотипів, можна створювати і власні.

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

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

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

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

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

пунктирною лінією.

При генерації коду для цих класів до них не додаватимуться нові атрибути. Проте будуть створені специфічні для мови оператори, необхідні для підтримки зв'язку. Наприклад, на мові C++ до коду увійдуть необхідні оператори #include.

Агрегація є тіснішою формою асоціації. Агрегація – це зв'язок між цілим і його частиною.

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

Таке каскадне вилучення нерідко розглядається як частина визначення агрегації, проте воно завжди мається на увазі в тому випадку, коли множинність ролі складає 1..1.

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

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

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