Клас проектування являє абстракцію одного або декількох класів в реалізації системи; точний об'єкт, якому він відповідає, залежить від мови реалізації. Наприклад, в об'єктно-орієнтованої мови, такому як C ++, клас проектування може відповідати простому класу. У мові Ада клас може відповідати спеціальним типом, визначеним у видимій частині пакета.
Класи визначають об'єкти. які, в свою чергу, реалізують варіанти використання. Клас заснований на вимогах, пропонованих реалізаціями варіантів використання об'єктів системи, а також на всіх раніше розроблених моделях об'єктів.
Успішність класу багато в чому залежить від середовища реалізації. Наприклад, правильний розмір класу і його об'єктів залежить від мови програмування. Те, що видається слушним в мові Ада, може виявитися невдалим в Smalltalk. Класи повинні відображатися в конкретний феномен в мові реалізації, і структура класів повинна бути такою, щоб у результаті відображення виходив хороший код.
Незважаючи на те, що особливості мови реалізації впливають на модель проектування, ви повинні стежити за тим, щоб структура класу була простою для розуміння і модифікації. Розробляти клас слід так, як якщо б ви мали класами і инкапсуляцией, нехай і не підтримуваними в мові реалізації.
Єдиний спосіб, за допомогою якого об'єкти можуть отримати доступ до атрибутів або взаємозв'язкам даного об'єкта або вплинути на них, - це скористатися його операціями. Операції об'єкта визначаються його класом. Операції дозволяють виконувати конкретну поведінку, яке може вплинути на атрибути і взаємозв'язку об'єкта і викликати виконання інших операцій. Операція відповідає функції-члену в мові C ++ і функції або процедури в мові Ада. Поведінка, яке ви привласнюєте об'єкту, залежить від його ролі в реалізаціях варіанти використання.
У специфікації операції параметри - це формальні параметри. У кожного параметра є ім'я і тип. Для вказівки операцій і їх параметрів можна скористатися синтаксисом і семантикою мови реалізації, так що ці операції і параметри вже будуть вказані в мові реалізації до моменту початку кодування.
В системі машини для переробки вторсировини об'єкти класу Receipt Basis стежать за тим, скільки предметів певного типу поклав клієнт. Поведінка об'єкта Receipt Basis включає збільшення числа повернутих об'єктів. Ця дія виконується операцією insertItem. одержує посилання на покладений предмет.
При вказівці операцій користуйтеся синтаксисом і семантикою мови реалізації.
Операція майже завжди задає поведінку об'єкта. Операція може також задавати поведінку класу - в цьому випадку вона називається операцією класу. Це можна змоделювати в UML, задавши відповідну область дії операції.
У операції можуть бути наступні області видимості:
- Загальнодоступна. операцію бачать всі елементи моделі, крім самого класу.
- Захищена. операцію бачать тільки сам клас, його підкласи і його друзі (в різних мовах можуть бути різні назви)
- Приватна. операцію бачать тільки сам клас і його друзі
- Реалізаційна. операція видно тільки в межах самого класу.
Загальнодоступну область видимості слід застосовувати у виняткових випадках. тільки коли операція необхідна іншого класу.
Захищена область видимості повинна застосовуватися за замовчуванням; вона захищає операцію від використання зовнішніми класами, що сприяє слабкій зв'язування і інкапсуляції поведінки.
Приватну область видимості слід застосовувати, коли ви хочете запобігти спадкування операції похідними класами. Це дозволяє відокремити похідні класи від базового і витрачати менше зусиль на видалення або виключення невикористовуваних успадкованих операцій.
Реалізаційна область видимості найбільш обмежувальні; вона використовується в випадках, коли операцію може застосовувати тільки сам клас. Це різновид Приватної області видимості. цілком достатньою в більшості випадків.
Об'єкт може реагувати на повідомлення по-різному, в залежності від того, в якому стані він знаходиться; поведінку об'єкта в залежності від стану визначається на пов'язаної діаграмі станів. Для кожного можливого стану об'єкта діаграма станів описує, які повідомлення може приймати об'єкт, які операції будуть виконані і в який стан потім перейде об'єкт. Додаткова інформація наведена в розділі Технологія: діаграма станів.
Кооперування - це динамічний набір взаємодій об'єктів, в якому об'єкти обмінюються інформацією шляхом відправки повідомлень один одному. Відправлення повідомлення виконується безпосередньо в Smalltalk і за допомогою виклику підпрограми в Аді. Повідомлення відправляється приймає об'єкту, запускающему внутрішню операцію. Повідомлення вказує ім'я виконуваної операції і необхідні параметри. За надсилання повідомлень про всіх параметрів надаються фактичні параметри (значення формальних параметрів).
Пересилання повідомлень між об'єктами в реалізації варіанту використання перемикання управління між об'єктами в міру запуску операцій описані на діаграмах взаємодії. Інформація про ці діаграмах приведена в розділах Технологія: діаграма послідовності і Технологія: графік залежності.
Атрибут - це іменоване властивість об'єкта. Ім'я атрибута - це іменник, що описує роль атрибута по відношенню до об'єкта. У атрибута може бути початкове значення при створенні об'єкта.
Моделювати атрибути слід тільки в тому випадку, якщо це спростить розуміння об'єкта. Моделювати властивість об'єкта як атрибут слід лише в тому випадку, якщо це властивість тільки даного об'єкта. В іншому випадку, ви повинні змоделювати властивість з взаємозв'язком асоціації або агрегування з класом, об'єкти якого представляють цю властивість.
Не завжди просто відразу вирішити, чи слід моделювати концепцію як окремий об'єкт або як атрибут іншого об'єкта. Додавання непотрібних об'єктів в модель перевантажує документацію і підвищує обсяг роботи. З цієї причини, ви повинні встановити критерії, що дозволяють визначати важливість концепції для системи.
- Готовність. Вибір між об'єктом і атрибутом визначається не важливістю концепції в реальному житті, а необхідністю доступу до неї під час виконання варіанта використання. Якщо доступ до елементу відбувається часто, змоделюймо його як об'єкт.
- Ізольованість під час виконання. Коли варіанти використання виконуються як об'єкти, концепції моделі обробляються окремо.
- Зв'язки з іншими концепціями. Концепції моделі тісно пов'язані з деякими іншими концепціями і ніколи не використовуються окремо, але завжди опосередковано через об'єкт, як атрибут об'єкта.
- Вимоги з боку взаємозв'язків. Якщо, з якоїсь причини, ви повинні встановити взаємозв'язку з елементом з двох напрямків, то перевірте його ще раз, щоб з'ясувати, чи повинен він бути окремим об'єктом. Два об'єкти не можуть пов'язувати один і той же екземпляр типу атрибута.
- Частота появи. Якщо елемент існує тільки під час виконання варіанта використання, не моделюйте його як об'єкт. Смоделируйте його як атрибут об'єкта, що виконує потрібну поведінку, або просто вкажіть його в описі відповідного об'єкта.
- Складність. Якщо об'єкт стає занадто складним через його атрибутів, перенесіть частину атрибутів в інші об'єкти. Слідкуйте, однак, за тим, щоб таких об'єктів не стало занадто багато. З іншого боку, елементи можуть бути дуже простими. Наприклад, до розряду атрибутів відносяться 1) елементи, досить прості, щоб підтримуватися безпосередньо найпростішими типами в мові реалізації, наприклад, цілі числа в C ++, і 2) елементи, досить прості, щоб реалізовуватися за допомогою незалежних від додатків компонентів середовища реалізації, наприклад , String в C ++ і Smalltalk-80.
У різних системах концепція може моделюватися по-різному. В одній системі концепція може бути настільки важливою, що її краще моделювати як об'єкт. В іншій вона може відігравати другорядну роль, і її краще моделювати як атрибут об'єкта.
Наприклад, система, призначена для авіаційної компанії, повинна підтримувати вильоти.
Система, що підтримує вильоти. Нехай персоналу аеропорту потрібно система, що підтримує вильоти. Для кожного вильоту необхідно визначити час вильоту, рейс і місце призначення. Це можна змоделювати як об'єкт класу Виліт з атрибутами час вильоту. рейс і місце призначення.
Якщо ж система розроблена для туристичного агентства, то ситуація може бути дещо іншою.
Місця призначення рейсів утворюють свій власний об'єкт - Місце призначення.
Час вильоту, рейс і місце призначення, природно, як і раніше будуть необхідні. Однак вимоги будуть іншими, оскільки турагентство цікавить виліт в заданий місце призначення. Отже, необхідно створити окремий об'єкт для Місця призначення. Об'єкти Виліт і Місце призначення. зрозуміло, повинні бути інформовані один про одного, для чого між їх класами створюється асоціація.
При виборі атрибутів, які повинні бути визначені в класі, слід враховувати важливість тих чи інших концепцій. Атрибути класу Автомобіль. без сумніву, будуть різними в залежності від того, є його об'єкти частиною системи реєстрації транспортних засобів або системи заводу з виробництва автомобілів.
Нарешті, правила, що визначають, що слід представляти як об'єкти, а що - як атрибути, неабсолютності. Теоретично все можна моделювати як об'єкти, але це занадто обтяжливо. Просте правило полягає в тому, щоб розглядати об'єкт як щось, що на певному етапі використовується безвідносно інших об'єктів. Крім того, необов'язково моделювати кожне властивість об'єкта за допомогою атрибута - досить моделювати лише ті властивості, які необхідні для розуміння об'єкта. Не потрібно моделювати деталі, занадто тісно пов'язані з реалізацією: їх краще залишити розробнику.
атрибути класу
Атрибут майже завжди задає властивості об'єкта. Атрибут може також задавати властивості класу - в цьому випадку він називається атрибутом класу. Це можна змоделювати в UML, задавши відповідну область дії атрибута.
Об'єкт може инкапсулировать елемент, значення якого може змінюватися незалежно від поведінки об'єкта. Це може бути щось, що є насправді зовнішнім елементом, але не змодельоване як суб'єкт. Наприклад, нехай кордони системи обрані так, що в їх межі потрапляє обладнання датчика. Датчик можна потім инкапсулировать в об'єкті, так щоб вимірюваний їм значення утворювало атрибут. Після цього це значення може змінюватися безперервно або періодично незалежно від того, чи впливає на даний об'єкт будь-якої іншої об'єкт в системі.
Термометр можна змоделювати як об'єкт; у об'єкта буде атрибут, відповідний температурі, і його значення буде змінюватися у відповідь на зміну температури навколишнього середовища. Інші об'єкти можуть запитувати поточну температуру, виконуючи операцію над об'єктом термометра.
Значення атрибута температура змінюється спонтанно в об'єкті Термометр.
Ви як і раніше можете змоделювати інкапсульоване значення, змінюється таким чином, у вигляді звичайного атрибута, однак ви повинні вказати в класі об'єкта, що воно змінюється спонтанно.
У атрибута можуть бути наступні області видимості:
- Загальнодоступна. атрибут бачать і зсередини, і зовні пакету, що містить клас.
- Захищена. атрибут бачать тільки сам клас, його підкласи і його друзі (в різних мовах можуть бути різні назви)
- Приватна. атрибут бачать тільки сам клас і його друзі
- Реалізаційна. атрибут бачить тільки сам клас.
Захищена область видимості повинна застосовуватися за замовчуванням; вона захищає атрибут від використання зовнішніми класами, що сприяє слабкій зв'язування і інкапсуляції поведінки.
Приватну область видимості слід застосовувати, коли ви хочете запобігти спадкування атрибута похідними класами. Це дозволяє відокремити похідні класи від базового і витрачати менше зусиль на видалення або виключення невикористовуваних успадкованих атрибутів.
Реалізаційна область видимості найбільш обмежувальні; вона використовується в випадках, коли атрибут може застосовуватися тільки самим класом. Це різновид Приватної області видимості. цілком достатньою в більшості випадків.
Деякі класи можуть представляти складні абстракції і мають складну структуру. Під час моделювання класу проектувальник може уявити його внутрішні беруть участь елементи і їх взаємозв'язку, щоб переконатися, що реалізатор правильно реалізує кооперування в цьому класі.
В UML 2.0 класи визначаються як структуровані класи. які можуть мати внутрішню структуру і порти. Класи можуть бути розкладені в набори з'єднаних частин, також допускають розкладання. Клас може бути инкапсулирован за допомогою передачі зв'язку від зовнішніх джерел до портів віддаленого підключення, який підпорядковується оголошеним інтерфейсів.
Таким чином, крім застосування діаграм класів для подання взаємозв'язків класів (наприклад, асоціацій, композицій та агрегування) і атрибутів, проектувальник може скористатися складовою структурної діаграмою. Ця діаграма дозволяє розробнику продемонструвати, яким чином екземпляри внутрішніх частин грають свої ролі в екземплярі заданого класу.
Додаткова інформація по цій темі і приклади діаграм складових структур наведені в розділі Концепція: структурований клас.