Локальна мережа підприємства UML - Unified Modeling Language

UML - Unified Modeling Language

Unified Modeling Language, скороченоUML, застосовується на різних етапах розробки програмного забезпечення (ПЗ). UML перекладається якуніфікована мова моделювання.

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

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

Unified Modeling Language може використовуватися на різних етапах розробки ПЗ: як під час проектування, так і під час кодування конкретною мовою. Оскільки UML представлений діаграмами, ця мова використовується як програмістами, а й, наприклад, менеджерами у компаніях, які розробляють ПЗ (але у своїй потрібно знати деякі концепції ООП).

Тепер давайте уникнемо нудних визначень і подумаємо, а навіщо нам, простим програмістам, потрібен цей самий UML? Уявімо таку ситуацію: у нас є три класи, кожен по 300 рядків коду. Між класами визначено складні зв'язки. Встежити за кодом у цій ситуації досить складно. А от якщо ці класи представити UML-діаграмою, то всі класи та зв'язки між ними будуть видні на одній невеликій картинці (діаграмі).

І останнє зауваження перш ніж ми почнемо: uml досить нова мова була створена в середині 90-х років (1994-1996). На даний момент є специфікація UML 2.2. Саме версію 2 ми розглядатимемо. Відмінності між uml 1 та uml 2 нам не важливі.

Діаграми класів UML (Class diagram)

У UML можна створювати кілька типів діаграм. У більшості випадків ми користуватимемося діаграмами класів (Class diagram). У цьому типі діаграм відображається взаємодія класів програми.

Елементи діаграм UML

Діаграми UML складаються з елементів. Елементи є прямокутниками, в яких пишеться ім'я елемента. Наприклад, зобразимо в UML-діаграмі якийсь клас (наприклад, я взяв, написаний нами раніше, клас Camera):

unified

Коментарі в UML

unified

Атрибути (attribute) та операції (operation) в UML-діаграмах

Якщо C++ змінна, що належить класу, називається полем класу чи змінної-членом, то UML така змінна називається атрибутом. Також і з функцією/методом класу – в UML це операція.

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

мережа

Тип атрибута (як і тип аргументу операції) задається через двокрапку:

підприємства

Тут можна побачити всі переваги UML. У Unified Modeling Language необов'язково розписувати всі деталі класів. Це буде зроблено при написанні коду конкретною мовою (у нашому випадку – C++). У UML діаграмі можна опускати непотрібні деталі. Наприклад, до діаграми елемента можна додати лише ті операції/атрибути, які важливі для даної діаграми, неважливіособливості класу UML можна опускати.

Видимість атрибутів та операцій в UML: +, -, # (специфікатори доступу)

Специфікатори доступу мови C++ (public, private, protected) у UML відображаються символами + (public), - (private), # (protected), які ставляться перед іменем атрибута/операції. Також можливий варіант із ключовими словами public, private, protected. На малюнку нижче показано обидва варіанти:

unified

Нагадаю значення специфікаторів доступу: public – поля/методи класу видно зовні класу. Тобто. до них можуть отримати доступ об'єкти класу. private - поля/методи класу видно лише усередині визначення класу. protected - поля/методи класу видно у визначенні самого класу та визначеннях похідних класів.

Відносини між класами в ООП (UML, С++)

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

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

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

На діаграмах асоціація позначається суцільною лінією.

Наприклад напишемо простий клас:

attack(int damage) // damage - шкода

Нагадую, що стандартні типи C є класами. Ось як будевиглядати взаємодія класів MonstAr та int на діаграмі UML:

мережа

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

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

мережа

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

Для подання успадкування в UML використовується узагальнення (generalization, нагадую, що це терміни беруться зі специфікації UML). Приклад:

attack(int damage) // damage - шкода

BigMonstAr: public MonstAr // великий (big) MonstAr

SmallMonstAr: public MonstAr // маленький (small) MonstAr

локальна

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

Тепер щодо словаузагальнення(generalization). У UML використовується саме воно, а не успадкування 13 , так як в даному виді зв'язку один із класів (базовий) є загальним, а решта класів (похідні) - більш спеціалізованими.

Aggregation - агрегація, агрегування, включення до UML

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

Отже, в UML агрегація відображає зв'язок класів, коли об'єкт одногоклас є атрибутом іншого. Приклад:

unified

На діаграмах агрегація є незакрашеним ромбом.

Композиція класів - composition в UML

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

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

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

class Claws; // claws - пазурі

В даному випадку у монстра "є пазурі" (визначені в окремому класі). Можливо, приклад не надто вдалий, але тут добре видно композицію класів: не можна від монстра відокремити його пазурі (він буде дуже незадоволений). У UML композиція виглядає так:

підприємства

На діаграмах композиція є зафарбованим ромбом.

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

Реалізація - realization в UML

Останнє ставлення, яке ми розглянемо, буде realization – реалізація.Цей зв'язок показує ставлення: клас - об'єкт.

На діаграмі реалізація показується пунктирною лінією та незафарбованою стрілочкою:

локальна

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