UML для найменших: діаграма класів

Аве, Кодер! Діаграма класів UML ілюструє структуру системи, описуючи класи, їх атрибути, методи та відносини між об'єктами.

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

Для тих, кому ліньки читати:

Головна дійова особа

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

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

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

Ім'я класу пишеться у верхньому розподілі, потім йдуть атрибути класу, типи яких записуються після двокрапки і, нарешті, у нижньому розподілі йдуть методи.

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

Кожен параметр у методі може мати опис спрямованості методу: in, out, inout.
На цій ілюстрації, method1 використовує p1 як вхідний параметр і значення p1 якимось чином використовується методом, а метод не змінює p1.

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

Method3 використовує p3 як вихідний параметр, іншими словами, параметр служить сховищем для вихідного значення методу.

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

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

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

Специфікаційна перспектива — це коли інтерпретуються діаграми, як опис абстракцій програмного забезпечення або компонентів зі специфікаціями та інтерфейсами, але без прив'язки до конкретної реалізації.

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

Типи відносин

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

Аналогічно зв'язкам, що з'єднують об'єкти, асоціації з'єднують класи.

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

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

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

Або іноді його ще називають – генералізація.

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

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

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

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

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

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

Наприклад, у класу Person є метод hasRead з вхідним параметром book, який повертає true, якщо, наприклад, людина прочитала книгу.

p align="justify"> Залежність позначається пунктирною лінією зі стрілкою, зверненої до класу, від якого залежать, наприклад, методи іншого класу.

Особливий тип відносин між класами, коли один клас є частиною іншого.

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

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

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

Наприклад, наше тіло складається з органів, але самі по собі вони не життєздатні.

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

Фіналочка

UML буває дуже корисним для новачків, що знаходяться на етапі розуміння «що до чого має йти і від чого успадковуватися». Як кажуть наші англомовні колеги: він допомагає побачити як виглядає весь ліс за стовбурами дерев.

Тому, перед початком твого, хай і невеликого, але карколомного проекту, не хапайся відразу за код. Створи спочатку архітектуру своєї програми в UML.

UML: огляд основних типів діаграм, діаграма класів. Частина 1

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

А навіщо нам UML? Може придумаємо свою мову моделювання?

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

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

А що, якщо у нас не один розробник, а 10? Або 100?

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

Плюси UML:

• Спрощує складнощі під час розробки ПЗ
• Автоматизує виробництво програмного забезпечення та процесів
• Допомагає вирішити постійні проблеми з архітектурою
• Поліпшує якість роботи
• Скорочує витрати та час виходу на ринок

Мінуси UML:

• марнування часу на складання діаграм :)
• необхідно знати різні діаграми та їх нотації

Види діаграм у UML

Отже, приступимо до вивчення та огляду діаграм UML. Усі UML діаграми за своєю сутністю поділяються на два види:

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

До структурних діаграм відносять такі 7 типів діаграм:

• Діаграма складової структури
• Діаграма розгортання
• Діаграма пакетів
• Діаграма профілів
• Діаграма класів
• Діаграма об'єктів
• Діаграма компонентів

А до діаграм поведінки відносять такі типи діаграм:

• Діаграма діяльності
• Діаграма прецедентів
• Діаграма станів
• Діаграма послідовності
• Діаграма комунікацій
• Діаграма огляду взаємодії
• Тимчасова діаграма

Нижче на малюнку наведено ілюстрацію структури мови UML:

Пропоную сьогодні зупинитися на діаграмі класів та детально розглянути цей тип діаграм. Інші типи діаграм будуть розглянуті в наступних серіях статей.

Діаграма класів

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

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

Властивості

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

Атрибути

Атрибут визначає властивість у вигляді рядка тексту всередині прямокутника класу.
Повна форма атрибуту:
видимість ім'я: тип кратність = значення за замовчуванням

Наприклад:
ім'я: String [1] = "Без імені"

Обов'язково вказувати лише ім'я.

Розглянемо основні сутності атрибуту:

• Мітка видимість означає, чи відноситься атрибут до відкритих (+) (public) або до закритих ( ) (private).
• Ім'я атрибута - спосіб посилання класу на атрибут - відповідає імені поля в мові програмування.
• Тип атрибута накладає обмеження на вигляд об'єкта, який можна розміщувати в атрибуті. Можна вважати його аналогом типу поля у мові програмування.
• Кратність - це поняття буде розглянуто нижче.
• Значення за замовчуванням є значенням для новостворених об'єктів, якщо атрибут не визначений у процесі створення.
• Елемент дозволяє вказувати додаткові характеристики атрибута. У прикладі він дорівнює, тобто клієнти не можуть змінювати атрибут. Якщо його пропущено, то, як правило, атрибут можна модифікувати.

Асоціації

Інша сутність якості – це асоціація. Значна частина інформації, яку можна зазначити в атрибуті, з'являється в асоціації. На рисунках 3 і 4 нижче показані ті самі властивості, представлені в різних позначеннях.

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

Звісно, ​​виникає питання: «Коли слід обирати те чи інше уявлення?». Як правило, за допомогою атрибутів позначають невеликі елементи, такі як дати або логічні значення, а асоціації для значущих класів, таких як клієнти чи замовлення.

Двонаправлені асоціації

Двонаправлена ​​асоціація - Це пара властивостей, пов'язаних у протилежних напрямках. Клас Car (Автомобіль) має властивість owner:Person[1], а клас Person (Особистість) має властивість cars:Car[*].

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

Кратність

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

• 1 (Замовлення може надати тільки один клієнт)
• 0..1 (Корпоративний клієнт може мати, а може й не мати єдиного торгового представника.)
• * (Клієнт не зобов'язаний розміщувати замовлення, і кількість замовлень не обмежена. Він може розмістити нуль або більше замовлень.)

Операції

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

Повний синтаксис операцій у мові UML виглядає так:

видимість ім'я (список параметрів) : тип, що повертається

Розглянемо основні сутності операції:

• Мітка видимості, як і в атрибутах, позначає, чи операція відноситься до відкритих (+)(public) або до закритих ( ) (private)
• Ім'я – це назва операції.
• Список параметрів – список параметрів операції.
• Тип, що повертається – тип значення, що повертається, якщо таке є.
• Рядок властивостей – значення властивостей, що застосовуються до цієї операції.

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

+ balanceOn (date: Date) : Money

Узагальнення

Узагальнення поєднує кілька підкласів в один клас. Так, у нашому прикладі узагальнення поєднує індивідуального та корпоративного клієнтів деякої бізнес-системи. Незважаючи на певні відмінності, вони мають багато спільного. Поодинокі властивості можна помістити до базового класу Customer (Клієнт), при цьому клас Personal Customer (Індивідуальний клієнт) та клас Corporate Customer (Корпоративний клієнт) будуть виступати як підтипи.

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

Примітки та коментарі

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

Поради щодо застосування діаграми класів

Отже, ми розглянули основні діаграми UML та детально діаграму класів. Хочу закінчити мою першу статтю цитатами із книги Мартіна Фаулера "Основи UML". На чолі про моделювання процесів за допомогою діаграми класів Мартін дає наступні поради:

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

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

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

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

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

Навчальний посібник із діаграми класів UML: абстрактний клас з прикладами

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

Що таке діаграма класів?

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

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

Переваги діаграми класів

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

Основні елементи діаграми класів UML

Основними елементами діаграми класів UML є:

Ім'я класу

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

При поданні класу необхідно дотримуватися таких правил:

1. Ім'я класу завжди має починатися з великої літери.
2. Ім'я класу завжди має бути у центрі першого відсіку.
3. Ім'я класу завжди має бути записано у шпилька формат.
4. Ім'я абстрактного класу UML слід писати курсивом.

Атрибути

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

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

Характеристики атрибутів

• Атрибути зазвичай записуються разом із коефіцієнтом видимості.
• Публічна, приватна, захищена та пакетна - це чотири видимості, які позначаються знаками +, -, # або ~ відповідно.
• Видимість визначає доступність атрибута класу.
• Атрибути повинні мати осмислене ім'я, що описує їх використання у класі.

Відносини

В основному існують три види відносин у UML:

Залежність

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

У наведених нижче прикладах діаграм класів UML Student залежить від College.

Узагальнення:

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

У цьому прикладі клас Student є узагальненням класу Person.

Асоціація:

Цей вид відносин є статичні відносини між класами A і B. Наприклад; співробітник працює у організації.

Ось деякі правила асоціації:

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

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

множинність

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

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

агрегування

Агрегація - це особливий тип асоціації, що моделює відносини "ціле-частина" між агрегатом та його частинами.

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

Склад:

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

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

СТАТТІ ЗА ТЕМОЮ

Агрегація проти композиції

Абстрактні класи

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

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

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

Абстрактний клас не може бути ініціалізований чи створений.

Позначення абстрактного класу

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

Приклад діаграми класів UML

Створення діаграми класів – простий процес. Воно не вимагає багатьох технічних подробиць. Ось приклад:

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

Нижче наведено приклад діаграми класів UML:

Приклад діаграми класів UML

Діаграма класів у життєвому циклі розробки програмного забезпечення

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

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

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

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

найкращі практики проектування діаграми класів

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

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

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

Висновок

• UML – це стандартна мова для визначення, проектування та візуалізації артефактів програмних систем.
• Клас - це проект об'єкту
• Діаграма класів описує типи об'єктів у системі та різні види відносин, які існують між ними.
• Це дозволяє аналізувати та проектувати статичне представлення програмної програми.
• Діаграми класів - це найбільш важливі діаграми UML, які використовуються при розробці програмних програм.
• Основні елементи діаграми класів UML: 1) Клас 2) Атрибути 3) Відносини
• p align="justify"> Діаграма класів надає огляд структури додатка перед вивченням фактичного коду. Це, безперечно, скорочує час обслуговування.
• p align="justify"> Діаграма класів корисна для відображення об'єктно-орієнтованих мов програмування, таких як Java, C++, Рубін, Python, і т.д.