Логічна модель розроблюваної системи, подається на діаграмі класів (Class diagram), що визначає типи класів системи і різного роду статичні зв’язки між ними (рис. 5.6). Також на діаграмі зображуються атрибути класів, операції класів та обмеження, що накладаються на зв’язки між класами. Вид та інтерпретація діаграми класів суттєво залежить від рівня абстракції, з яким вона створюється, — класи можуть подавати сутності предметної області в процесі аналізу або елементи програмної системи під час проектування і реалізації.
Зазвичай для опису системи створюється кілька діаграм класів. На одних показують деяку підмножину класів і відношення між ними. На інших — ту саму підмножину класів, але з атрибутами та операціями класів. Треті подають пакети класів і відношення між ними.
У логічному поданні пакет — це набір класів та інших пов’язаних пакетів. Зображуються у вигляді прямокутника з закладкою.
Об’єднання може відбуватись за стереотипом класу, за функціональністю, або за комбінацією — на верхньому рівні класи групуються за функціональністю, а всередині цих пакетів — за функціональністю або стереотипом. Кожен пакет містить інтерфейс, що реалізується набором його загальнодоступних класів, тобто таких, з якими можуть спілкуватися класи з інших пакетів. Решта класів пакета — це класи реалізації, які не взаємодіють з класами в інших пакетах (див. далі параметр видимості класу).кою. Пакети групують класи, що мають сільні риси.
Загальним правилом є створення однієї діаграми, що називається головною (Main), розміщується безпосередньо під логічним поданням у браузері і містить пакети класів моделі. Усередині кожного пакета також є головна діаграма, що містити усі класи цього пакета.
Клас — це опис групи об’єктів зі спільними властивостями (атрибутами), поведінкою (операціями), відношеннями з іншими об’єктами і семантикою. Інакше кажучи, клас є певним шаблоном для створення об’єкта. Кожен об’єкт є екземпляром конкретного класу і не може бути екземпляром кількох класів.
Графічно клас зображується як прямокутник, який може бути розділений на три частини, в яких зазначаються його ім’я, атрибути (змінні) та операції (методи).
Класи виявляють у результаті вивчення потоку подій сценаріїв і діаграм взаємодії. Схожі між собою об’єкти утворюють класи. Водночас слід пам’ятати, що деякі класи при цьому не виявляються.
Кожному класу моделі слід присвоїти унікальне ім’я. У загальному випадку використовують відповідні іменники в однині. Зазвичай імена класів не містять пропусків. Регістр символів, що може використовуватись для іменування класів, визначає компаніярозробник. Загальним правилом є адекватний опис призначення класу за збереження стислості і простоти імені.
Атрибут — це фрагмент інформації, пов’язаний з класом. Для атрибутів класів в IBM Rational Rose визначають: ім’я, тип даних, стереотип, первісне значення, видимість, метод локалізації. Перші два елементи слід обов’язково визначити до початку генерування коду. Текстовий опис атрибута, якщо він є, вводиться в код, що генерується, як коментар.
Видимість атрибута (Export Control) визначає, які класи мають право читати та змінювати його:
— Public — спільний, відкритий. Атрибут видимий усім класам, будьякий з них може переглянути або змінити значення атрибута;
— Private — закритий, секретний. Атрибут невидимий жодному з інших класів. За необхідності «сторонній» клас має просити у класувласника дозвіл на перегляд або зміну значення цього атрибута, що зазвичай робиться за допомогою спільних операцій (див. далі);
— Protected — захищений — атрибут доступний лише самому класу та його нащадкам;
— Implementation — атрибут є спільним у межах пакета. У загальному випадку рекомендується атрибути визначати як закриті або захищені, що надає можливість краще контролювати сам атрибут і код.
Метод локалізації (Containment) показує, як атрибут зберігається у класі:
— By Value — за значенням — атрибут міститься всередині класу. Наприклад, якщо атрибут має тип даних string, цей рядок міститиметься всередині визначення класу;
— By Reference (за посиланням) — атрибут локалізується поза класом, але клас містить посилання на нього. Наприклад, у класу Картка табельного обліку може бути атрибут Працівник, що вказує на зовнішній об’єкт з відповідним іменем;
— Unspecified (не визначено) — під час генерування коду за умовчанням застосовується значення By Value.
Атрибут може бути визначений як статичний (Static), тоді він буде використовуватися всіма екземплярами класу, та/або як похідний (Derived) — такий, що створюється з одного або кількох інших атрибутів, зокрема в результаті розрахунків.
Операція — це пов’язана з класом поведінка. Операція складається з трьох частин — імені, параметрів, тобто аргументів, що отримуються операцією на вході, і типу значень, що повертаються. Ця інформація використовується IBM Rational Rose під час генерування коду.
Для операцій передбачаються такі стереотипи:
— реалізація — операція реалізує деяку функціональність. З такими операціями найчастіше співвідносять повідомлення діаграм взаємодії;
— керування — операція керує створенням і руйнуванням об’єктів. До цієї категорії відносять конструктори і деструктури класів, створити які IBM Rational Rose пропонує автоматично під час генерування коду;
— доступу — операція надає можливість іншим класам переглядати або редагувати атрибути даного класу. Згідно з промисловим стандартом такі операції називають Get() і Set(). їх IBM Rational Rose створює автоматично для кожного атрибута під час генерування коду;
— допоміжна — операції класу, необхідні йому для виконання його відповідальностей, про які інші класи нічого не знають. Це закриті та захищені операції класу. На діаграмах взаємодії такі операції подаються як рефлексивні повідомлення.
Стереотипи потрібні не для генерування коду, а лише для полегшення розуміння моделі і перевірки, що жодну з операцій не пропущено.
Видимість операцій задають аналогічно видимості атрибутів. Додаткові параметри, які додаються до генерованого коду як коментар і не впливають на сам код, задаються в таких полях:
— Protocol — протокол операції описує, які операції і в якому порядку може виконувати клієнт над об’єктом. Наприклад, протокол може вказувати, що операцію А не можна запускати до завершення операції Б. Ця інформація додається до генерованого коду як коментар, але не впливає на сам код;
— Qualification — уточнення ідентифікує додаткові відомості про операцію, пов’язані з конкретною мовою програмування.
— Exception — перелік виняткових ситуацій для даної операції;
— Size — розмір, припущення щодо обсягу пам’яті, потрібного операції під час її виконання;
— Time — час, припущення щодо часу виконання операції;
— Abstract — абстрактна операція, що не виконується в абстрактному класі, але може виконуватися в конкретних класахнащадках;
— Concurrency — паралельність — поведінка операції за наявності кількох потоків керування:
— Sequential — послідовна (встановлюється за умовчанням) — операція виконуватиметься правильно лише в разі єдиного потоку керування. Виконання операції має завершитися до початку виконання іншої операції;
— Guarded — така, що охороняється — за наявності кількох потоків керування операція виконується правильно, якщо взаємодія класів гарантує взаємне виключення операцій, що виконуються;
— Synchronous — синхронна — операція виконується правильно за наявності кількох потоків керування. Після звернення операція буде виконуватися в одному потоці керування аж до свого завершення. Інші операції можуть виконуватися в цей самий час в інших потоках. Клас має потурбуватися про вирішення проблем взаємного виключення, тому взаємодія з іншим класом не потрібна;
— Preconditions — передумови — умови, що їх слід виконати до запуску операції. Опис може супроводжуватися посиланням на діаграму взаємодії, що ілюструє передумови;
— Semantics — семантика — опис того, що робитиме операція, за допомогою псевдокоду або звичайного тексту.
Деяка інформація щодо операції, зокрема вимоги, що підтверджують необхідність операції, або опис її дій, може міститись у зовнішньому файлі, який можна прикріпити, або на Webсторінці, на яку можна створити посилання.
Крім звичайних (рис. 5.7, а), у середовищі IBM Rational Rose можна створювати класи спеціальних типів:
— параметризований клас (Parameterized Class, рис. 5.7, б) — різновид контейнера, шаблона. Такі класи застосовують для створення сімейств інших класів. Наприклад за допомогою екземплярів параметризованого класу Список можна створити класи СписокПрацюючих, СписокЗамовлень, СписокДоговорів тощо. У прямокутнику, обмеженому пунктирними лініями, вказують аргументи, на основі яких створюються елементи стандартного класу. Аргументом може бути інший клас, тип даних або виразконстанта. Кількість аргументів не обмежується;
— класнаповнювач (InstantiatedClass, рис. 5.7, в) — параметризований клас, аргументи якого мають фактичні значення. Якщо визначено список деяких елементів і аргумент приймає значення Співробітник, то в результаті ми одержуємо список співробітників. Ім’я класунаповнювача, згідно з нотацією UML, обмежується кутовими дужками <>;
— утиліта класу (ClassUtility, рис. 5.7, г) — сукупність операцій, що їх важко віднести до певного конкретного класу, створена для використання іншими класами системи. Утиліти класів часто застосовують для розширення функціональних можливостей мови програмування або для зберігання спільних елементів функціональності багаторазового використання, необхідних у кількох системах;
— утиліта параметризованого класу (ParameterizedClassUtility, рис. 5.7, д) — параметризований клас, який містить лише набір операцій. Це шаблон для створення утиліт класу;
— утиліта класу-наповнювача (InstantiatedClassUtility, рис. 5.7, є) — утиліта параметризованого класу, параметри якої мають фактичні значення;
— метаклас (MetaClass, рис. 5.7, ж) — клас, екземплярами якого є класи, а не об’єкти. До метакласів належать параметризовані класи та утиліти параметризованих класів.
а — звичайний, б — параметризований, в — класнаповнювач, г — утиліта класу, д — утиліта параметризованого класу, є — утиліта класунаповнювача, ж — метаклас
Специфікація класів передбачає визначення стереотипів, параметрів видимості, множинності, простору, стійкості, паралелізму. Для класів визначено три основні стереотипи:
— <> — сутність. Класисутності використовують для моделювання даних і поведінки із тривалим життєвим циклом. Такі класи подають сутності реального світу (тому їх називають класами предметної області) або внутрішні елементи системи, які не знищуються під час вимикання системи або завершення програми. Вони зазвичай не залежать від оточення і можуть використовуватися в різних додатках. Як правило, классутність відповідає окремій таблиці бази даних, його атрибути — полям таблиці, а операції — приєднаним чи збереженим процедурам. Отже структура бази даних розробляється на підставі інформації об’єктної моделі;
— <> — межа. Граничні класи розташовані на межі системи з зовнішнім середовищем, є складовими системи і безпосередньо взаємодіють з акторами. Вони використовуються для моделювання інтерфейсів системи на високому рівні — форм, звітів, інтерфейсів з апаратурою та іншими системами. Наприклад, як клас моделюється вікно, але не моделюються його діалогові елементи і кнопки. Для виявлення граничних класів вивчають пари актор — сценарій. Водночас граничні класи можуть бути неунікальними для таких пар. Якщо два актори ініціюють один і той самий прецедент, вони можуть застосовувати спільний граничний клас для взаємодії з системою;
— <> — керування. Класи керування (класи менеджери) створюються для моделювання послідовної поведінки одного або кількох прецедентів і координації подій, що реалізують закладену в ці прецеденти поведінку. Вони «виконують» прецедент, визначають його динаміку і координують дії інших класів. Відповідно, класи керування залежать від додатку. На кожній діаграмі класів має бути принаймні один клас керування, об’єктам якого надсилається невелика кількість повідомлень порівняно з кількістю повідомлень, що вони їх розсилають. На ранній стадії опрацювання класи керування додаються для кожної пари актор — прецедент. Під час подальшого аналізу та проектування їх можна виключати, розподіляти чи об’єднувати. Спільними для кількох прецедентів можуть бути класи, що відповідають за контроль подій, пов’язаних із безпекою, координацією повідомлень, що стосуються транзакцій з базою даних, розподіл ресурсів, розподілене оброблення даних, оброблення помилок тощо. За допомогою класів керування ізолюється функціональність системи, що мінімізує наслідки внесення змін у відповідні функції.
Спеціальним випадком класу, в якого є операції, але відсутні атрибути, є інтерфейс (interface) — поіменована множина операцій, які характеризують поведінку окремого елемента моделі.
Інтерфейси на діаграмі класів слугують для специфікації таких елементів моделі, що видимі ззовні, але їхня внутрішня структура залишається прихованою від клієнтів. Інтерфейси не можуть мати ані атрибутів, ані станів, ані спрямованих асоціацій. Вони містять лише операції без указівки особливостей їх реалізації. Формально інтерфейс не тільки відокремлює специфікацію операцій системи від їх реалізації, а й визначає загальні межі проектованої системи. Згодом інтерфейс слід уточнити чіткою вказівкою тих операцій, що специфікують окремий аспект поведінки системи.
Для позначення інтерфейсу використовують спеціальний графічний символ або стандартний спосіб — прямокутник класу зі стереотипом <>. Як ім’я інтерфейсів використовують іменники, що характеризують відповідну інформацію або сервіс, наприклад «Форма введення», «Датчик».
Крім зазначених стереотипів, IBM Rational Rose дає можливість створювати користувацькі стереотипи, кнопки для них і піктограми інструментів.
Параметр видимості (контроль експорту, Export Control) описує, наскільки клас та його елементи видимі ззовні пакету, в якому вони визначені:
— Public — публічний. Клас видимий ізза меж пакета і може бути імпортований до інших частин моделі. Операції доступні всім клієнтам;
— Protected, Private — захищений, закритий. Елемент доступний лише вкладеним класам, «друзям» або самому класу;
— Implementation — реалізація. Клас видимий лише з класів того самого пакета. Операція є частиною реалізації класу.
Множинність (Multiplicity) класу визначає, скільки у нього має бути екземплярів. Множинність класу керування зазвичай дорівнює 1.
Поле Space (простір) використовується для вказівки кількості абсолютної або відносної пам’яті, потрібної для кожного об’єкта класу. Це поле не заповнюється для утиліт класів, утиліт класівнаповнювачів та утиліт параметризованих класів.
Стійкість класу (Persistence) визначає, чи буде зберігатись клас після завершення додатку у базі даних або іншим способом, що забезпечує тривале зберігання (Persistent), чи ні (Transient). Це поле не заповнюється для утиліт класів, утиліт класівнаповнювачів та утиліт параметризованих класів.
У полі Concurrency (паралельність) описується, як поводитиметься клас у присутності кількох потоків керування:
— Sequential — послідовний (встановлюється за замовчуванням) — семантика класу гарантується (операції виконуватимуться так, як очікується) лише в разі єдиного потоку керування;
— Guarded — такий, що обмежує — за наявності кількох потоків керування клас поводитиметься, як очікується. Щоб класи різних потоків керування не заважали одне одному, необхідна взаємодія між ними;
— Active — активний — клас матиме свій потік керування;
— Synchronous— синхронний — семантика класу гарантується за наявності кількох потоків керування. Між ним та класами інших потоків не вимагається взаємодії, оскільки клас може самостійно обробити взаємні виключення.
IBM Rational Rose дає змогу вкладати класи один в одне, організуючи кілька рівнів вкладень. На діаграмі вкладений клас з’являється з іменем батьківського класу, обмеженим дужками (рис. 5.8).
До діаграми класів та до окремого класу в IBM Rational Rose можна прив’язати файли і посилання, зокрема з початковим кодом класу або з описом дій з тестування його функціональних можливостей. На самій діаграмі можна розташовувати примітки, що містять додаткову інформацію, у вигляді примітоккоментарів до класу, пакета, атрибута, операції чи зв’язку або текстової ділянки, в якій коментується діаграма загалом.
Зв’язок — це семантичний взаємозв’язок між класами. Він дає класу змогу дізнаватися про атрибути, операції та зв’язки іншого класу. Інакше кажучи, якщо на діаграмі взаємодії один клас надсилає повідомлення іншому класу, між ними має бути зв’язок. На діаграмі класів можуть бути зв’язки таких типів:
— асоціація (Association) — це семантичний зв’язок між класами. Асоціації можуть бути одно або двоспрямованими Якщо між класом Працівник і Посада встановлено зв’язок асоціації, клас Працівник одержить атрибут посада, щоб знати, яку посаду він обіймає, а клас Посада — атрибут працівник, який надасть можливість дізнатися, хто працює на цій посаді. Напрям асоціації визначається за діаграмами взаємодії. Односпрямовані зв’язки дають можливість виявити класикандидати на повторне використання. Якщо ж асоціація двоспрямована, кожен із класівучасників має знати про інший і не може без нього застосовуватися;
— залежність (Dependency) — завжди односпрямований зв’язок , який показує, що один клас залежить від визначень, зроблених в іншому. Спеціальні атрибути для класів, пов’язаних залежністю, IBM Rational Rose не генерує. Зв’язок залежності можна встановлювати не лише між класами, а й між пакетами. Це єдиний тип зв’язку, який можна встановити між пакетами. Зв’язок залежності між пакетами А і Б означає, що деякий клас пакета А зв’язаний односпрямованим зв’язком з деяким класом пакета Б. При створенні залежностей між пакетами рекомендується уникати циклічних залежностей, коли клас з пакету А має знати про клас із пакета Б, а деякий клас із пакета Б — знати про клас із пакета А. Отже, жоден із пакетів не можна самостійно використовувати повторно, зміни в одному з них неминуче вплинуть на інший. У таких випадках фахівці рекомендують розділяти пакети на частини;
— узагальнення (Generalization) — зв язок наслідування структури або поведінки між класами. Крім наслідуваних, кожен підклас має власні унікальні атрибути, операції та зв’язки. Зв’язки узагальнення дають можливість заощадити час і зусилля при розробці і в процесі супроводу програми. Часто створюються окремі діаграми класів, присвячені структурі наслідування, які містять мінімальну кількість даних та атрибутів;
— реалізація (Realize) — зв’язок між класами, інтерфейсами, компонентами та пакетами, що з’єднує клієнта із сервером (постачальником). Зв’язок реалізації між класом та інтерфейсом показує, що клас реалізує операції, запропоновані інтерфейсом. Якщо зв’язок реалізації пов’язує інтерфейс з іншим елементом моделі, графічно він подається суцільною лінією. Якщо зв’язок реалізації з’єднує пакет з класом, він подається як пунктирна лінія з незафарбованою стрілкою наприкінці (рис. 5.9).
Специфікація зв’язків передбачає визначення імен асоціацій (Name), ролевих імен (Role), кваліфікаторів і текстових описів для пояснення призначення зв’язку і причини його появи, якщо вона неочевидна. Рольові імена — зазвичай іменники або фрази (Працедавець, Працівник, Власник), а імена зв’язків — дієслова або віддієслівні фрази (Працює, Володіє). В IBM Rational Rose можна задати також напрям зв’язку (Name Direction), наприклад, можна сказати, що компанія наймає працівника, але не навпаки. Кваліфікатори (Keys/Qualifiers) зменшують область дії асоціації, унікально ідентифікуючи єдиний цільовий об’єкт. Для класифікації зв’язків можна використовувати стереотипи.
До початку генерування коду слід вказати множинність зв’язку (Multiplicity) — кількість екземплярів класу, що взаємодіють за допомогою зв’язку з одним екземпляром іншого класу у заданий момент часу, — інакше будуть задані значення за умовчанням. Значення множинності визначає, чи є зв’язок обов’язковим. Для форм, екранів та вікон задається множинність 0..1 з кожного боку зв’язку; це означає, що форми можуть існувати незалежно одна від одної, хоча це не завжди справедливо.
Під час генерування коду для класів, пов’язаних асоціацією, створюють атрибути, видимість яких визначається перемикачем Export Control аналогічно тому, як це встановлюється для інших атрибутів (див. вище). У двоспрямованих асоціаціях керування експортом встановлюється для атрибутів обох кінців зв’язку, а для односпрямованих — лише для одного. Також для згенерованих атрибутів визначається, чи будуть вони використовуватися всіма екземплярами класу, іншими словами, чи будуть вони статичними (Static). Якщо роль статична, то і відповідний атрибут теж буде статичним.
Для згенерованих атрибутів визначається, як вони будуть включатися до класу (Containment of):
— By Value — за значенням — ціле і частина створюються і руйнуються одночасно;
— By Reference (за посиланням) — ціле і частина створюються і руйнуються в різний час, незалежно одне від одного;
— Unspecified — не визначено.
Дружній зв’язок (Friend) передбачає, що класклієнт має право доступу до атрибутів та операцій класусервера, які не є спільними. У початковий код класусервера ввійде логіка з підтримки дружньої видимості для клієнта.
Атрибут може бути визначений як статичний (Static), тоді він буде використовуватися всіма екземплярами класу, та/або як похідний (Derived) — такий, що створюється з одного або кількох інших атрибутів, зокрема в результаті розрахунків.
Елемент зв’язку (Link Element), який ще називають класом асоціацій (Association class), позначає місце, де зберігаються атрибути, що стосуються зв’язку асоціації. Наприклад, якщо за наявності класів Працівник і Посада, є необхідність додати атрибут Стаж на посаді, який більшою мірою стосується саме зв’язку, а не одного із класів, що їх цей зв’язок поєднує, доцільно розмістити його в новий клас.
Обмеження (Constraints) подають умови, що мають бути виконані. В IBM Rational Rose можна встановити обмеження як для зв’язку загалом, так і для однієї ролі.
