Діаграма класів UML; Таким чином ви відстежуєте орієнтацію об’єкта! навчитися програмувати

Заробіток:

  • Як показати взаємозв'язки між класами за допомогою діаграми класів UML.
  • Що слід враховувати при об’єктно-орієнтованому дизайні?
  • Як відобразити атрибути та методи на діаграмі класів.
  • Що таке множинність?
  • Як ви представляєте відносини між класами.
  • У чому різниця між агрегацією та складом?
  • Як представити успадкування на діаграмі класів UML.

Ми вже знаємо.

Якщо ви не зробите цього неправильно, ви потрапите в пекло!

І ми точно не хочемо туди їхати!

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

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

Або ви можете використовувати безкоштовне програмне забезпечення UMLet.

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

Так само, як ми робили тут із класом чотириногих друзів.

таким

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

Діаграма класів - це інструмент, який слід терміново додати до набору інструментів.

Однак, як і будь-який інструмент, ви можете ефективно використовувати схему класів UML, лише якщо розумієте область її застосування.

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

Об'єктно-орієнтоване проектування з діаграмою класів UML

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

Ми створюємо конкретні об'єкти з класів (створюємо екземпляр). Наприклад, клас собак стає екземпляром собаки з ім’ям Снупі та вагою 20 кг.

Атрибути класу описують стан об’єкта, наприклад ім’я та вагу собаки.

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

На діаграмі класів UML ці три елементи відокремлені один від одного горизонтальними лініями. Для нашого прикладу собаки діаграма класів виглядає так:

Угорі - назва класу. У нашому випадку клас називається собакою.

Середня частина містить атрибути класу. Тож ім’я та вага собаки.

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

Методи перераховані разом зі списком параметрів і значенням повернення в нижній частині діаграми класів UML, з типом даних значення повернення після двокрапки.

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

Чи немає нічого іншого?

Я впевнений, ви вже помітили!

Ми поставили атрибути префіксом зі знаком мінус, а методи зі знаком +.

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

Фахівець у цій галузі говорить про інкапсуляцію.

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

Звичайно, також можна визначити атрибути та методи як захищені.

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

На діаграмі класів UML ми позначаємо видимість, захищену знаком хешу #.

Змінні класу в діаграмі класів UML

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

Але що, якщо ми хочемо підрахувати кількість створених об’єктів собак?

Для цього нам потрібна ОДНА цілочисельна змінна, до якої мають доступ усі екземпляри собак.

Така змінна називається змінною класу і визначається в Java за допомогою ключового слова static.

На діаграмі класів UML змінні класу позначені підкресленням.

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

Це було легко, чи не так? Нам залишалося лише додати підкреслену цілу змінну hundZaehler до атрибутивної частини діаграми класів UML.

Кратність у діаграмі класів UML

Поки що ми полегшили собі це. Наразі наші атрибути складалися лише з примітивних типів даних. Але що ми робимо, коли хочемо використовувати масиви або списки масивів?

Для цього існує так звана кратність.

Звичайно, у нашої собаки є три улюблені іграшки, а саме коханка, Лего та бейсбольна бита.

І саме в такому порядку!

Отже, нам потрібен масив, який може вміщувати ці три елементи в заданому порядку.

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

Ми визначаємо ємність масиву за кратністю [1.3]. Додаючи, ми вказуємо, що іграшки за наклеп - це впорядкована структура даних, у якій послідовність є важливою.

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

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

Для цього UML забезпечує множинність [*] та ідентифікатор.

Тож давайте ще раз розширимо нашу діаграму класів UML.

Тепер наша собака може приймати будь-яку кількість улюблених страв. Однак кожну їжу можна чітко зберегти лише в атрибуті улюбленої їжі. Сузір'я типу: "Мої улюблені страви - це 1-а піца, 2-а піца і 3-та піца" неможливо через етикетку.

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

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

Найвідоміша з усіх констант - Pi. Замість написання 3.14 ., де б ми не обчислювали з числом Pi, ми використовуємо константу Math.PI .

Константи оголошуються кінцевими в Java за допомогою ключового слова та додаються в схему класів UML.

Типовим використанням констант є номери версій. Тож давайте знову розширимо нашу діаграму класів UML.

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

Від діаграми класів UML до програмного коду

Метою наших зусиль є виконувана програма.

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

І саме про це ми хочемо подбати далі.

Ось вихідний код, згенерований із діаграми класів.

У двох та трьох рядках ми оголошуємо примітивні атрибути ім'я та вага .

Потім ми використовуємо список масивів для зберігання улюблених іграшок та HashSet для зберігання улюблених продуктів нашої собаки.

Для цього ми використовуємо HashSet, оскільки ми маємо чітко зберігати його в нашій структурі даних через маркування стравами.

Нарешті, у рядки шостий та сьомий ми додаємо статичну змінну лічильника hundZaehler та константу VERSION як атрибути.

Методи перераховані у рядках восьмий - дванадцятий.

Це також дає зрозуміти, що діаграма класів UML НЕ може робити. Діаграма класів лише описує, які методи клас робить доступними. Однак він не дає жодних вказівок на те, як має бути реалізована функціональність цих методів.

Тож діаграма класів не допомагає нам моделювати алгоритм. Однак для цієї мети UML надає інші діаграми, такі як діаграма послідовності.

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

Чесно! Поки що все це просто дратує і зовсім не допомагає.

Ви могли б забити одного класу собак у комп’ютер без усіх зусиль.

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

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

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

Залежності в діаграмі класів UML

Собака голодна і їсть з їжі.

Fressnapf - це об'єкт, який ми створюємо з класу Fressnapf, а eat - це метод класу собак з екземпляром Fressnapf як параметром.

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

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

Асоціації UML

Ви вже були в притулку?

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

Очевидно, існують стосунки між собакою та утримувачем у притулку.

Однак відносини не такі міцні, щоб одне не могло обійтися без іншого.

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

Собака може бути щасливо інтегрована в сім’ю, і є доглядачі тварин, які піклуються лише про білого ведмедя Кнута.

Такі слабкі зв’язки демонструються за допомогою простої сполучної лінії між класами.

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

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

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

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

Прийомний пес - ще бідніший собака без притулку для тварин, а утримувач тварин - безробітний утримувач тварин без притулку для тварин.

Але обидва все ще є. Такий зв'язок називається агрегацією і на діаграмі класів UML позначений символом ромба.

Склад!

Сильнішою асоціацією є так звана композиція.

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

Це саме той випадок з нашим Fressnapf!

Бо якщо ми викинемо миску, наповнену їжею, ми також втратимо їжу, яка в ній міститься.

Ми позначаємо композицію завершеним символом діаманта.

Чим відрізняються агрегація та склад у реалізації?

Найважливішою відмінністю між агрегацією та складом є міцність стосунків.

Давайте розглянемо приклад.

Тут ми створюємо екземпляр собаки, якого ми заготовляємо вдома за допомогою конструктора класу притулку для тварин.

Що відбувається з Белло, коли ми видаляємо примірник притулку?

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

Екземпляр притулку містить лише посилання на об'єкт bello .

Тому в даному випадку це агрегація.

Давайте подивимось на склад.

Тут ми створюємо миску з їжею, наповнену їжею.

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

Отже, що станеться з подачею, якщо ми видалимо екземпляр чаші?

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

Спадкування в діаграмі класів UML

Вам щось не вистачає? так, я теж!

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

Спадщина відображається на діаграмі класів UML за допомогою стрілки.

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

Чотириногий друг - вищий клас собаки, ми вказуємо стрілкою, що вказує на чотириногий клас.

теорія і практика

Описана тут процедура називається моделлю водоспаду.

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

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

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

Швидка розробка програмного забезпечення на даний момент є головною стороною тут.

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

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

Ви вже працювали з діаграмою класів UML? Який ваш досвід Просто залиште мені коментар!

Вам сподобалась стаття? Тоді негайно слідкуйте за нами у Facebook!

Кім Пітер

Привіт, мене звуть Кім, і я хочу стати чудовим програмістом. Ви берете участь?