Диаграма на UML клас; По този начин следите ориентацията на обекта! научете се да програмирате
Keylearnings:
- Как да покажем връзките между класовете с диаграма на UML класа.
- Какво трябва да се има предвид при обектно-ориентиран дизайн?
- Как да се покажат атрибутите и методите в диаграмата на класа.
- Какво е множественост?
- Как представяте връзките между класовете.
- Каква е разликата между агрегирането и състава?
- Как да представим наследяването в диаграмата на UML класа.
Вече знаем.
Ако не го направите погрешно, ще попаднете в ада!
И ние със сигурност не искаме да отидем там!
Преди да натиснете клавишите, определено трябва да помислите.
Можете да го направите в градината с готина кола. Основното е, че имате под ръка подложка за писане и молив с гума.
Или можете да използвате безплатния софтуер UMLet.
Тъй като голямо предимство на обектно-ориентирания дизайн е, че компонентите и техните взаимоотношения могат да бъдат графично представени в софтуерна система.
Точно както направихме тук с клас четириноги приятели.
Така наречената диаграма на клас UML е много интелигентен начин за визуално представяне на класове и техните взаимоотношения. UML означава унифициран език за моделиране.
Диаграмата на класовете е инструмент, който трябва спешно да добавите към вашата кутия с инструменти.
Както всеки инструмент обаче, можете да използвате ефективно диаграмата на UML класа само ако разбирате областта на приложението му.
Така че нека първо да поговорим за какви неща трябва да се тревожим в обектно-ориентиран дизайн.
Обектно-ориентиран дизайн с диаграма на класа на UML
Класът се състои от три компонента. Всеки клас има име, свойства (наричани още атрибути) и методи.
Създаваме конкретни обекти от класове (инстанцираме). Например класът кучета се превръща в екземпляр на куче с името Snoopy и тегло 20 кг.
Атрибутите на класа описват състоянието на обекта, като например Име и тегло на куче.
Методите, от друга страна, описват поведението на даден обект и му дават възможности, като че кучето може да лае.
В диаграмата на класа на UML тези три елемента са разделени един от друг с хоризонтални линии. За нашия пример за куче диаграмата на класа изглежда така:
В горната част е името на класа. В нашия случай класът се нарича куче.
Средната част съдържа атрибутите на класа. Така че името и теглото на кучето.
Всеки атрибут има тип данни, който е разделен с двоеточие след името на съответния атрибут.
Методите са изброени заедно със списъка с параметри и връщаната стойност в долната част на диаграмата на класа на UML, като типът данни за връщаната стойност следва двоеточието.
Тук имаме работа с доста просто куче. В допълнение към метода на лаене, нашият клас съдържа само методите getter и setter за атрибутите.
Няма ли нещо друго?
Сигурен съм, че вече сте забелязали!
Префиксирали сме атрибутите със знак минус - и методите със знак +.
Както знаете от основите на обектно-ориентираното програмиране, за да ги предпазите от манипулация, променливите на екземпляра не трябва да се виждат отвън, т.е. те трябва да бъдат обявени за частни.
Специалистът в тази област говори за капсулиране.
И точно това означава знакът минус -. Атрибут или метод, предшестван от знак минус, се обявява за частен, докато знакът плюс + означава атрибут или метод, дефиниран като публичен.
Разбира се, възможно е и атрибутите и методите да се дефинират като защитени.
Атрибутите, декларирани като защитени или дефинирани методи, трябва да се виждат само в самия клас и във всички подкласове.
В диаграмата на класа на UML маркираме видимостта, защитена със знак за хеш #.
Променливи на класа в диаграмата на UML класа
Досега нашите атрибути винаги са били променливи на екземпляра. Всеки екземпляр от нашия клас кучета заема своя отделна област на паметта.
Но какво, ако искаме да преброим броя на кучешките обекти, създадени?
За тази цел се нуждаем от ЕДНА целочислена променлива, до която всички екземпляри на кучета имат достъп.
Такава променлива се нарича променлива на класа и се дефинира в Java с помощта на статичната ключова дума.
В диаграмата на класа на 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 и ядем е метод на клас куче с екземпляр Fressnapf като параметър.
Примерът Fressnapf не е неразделна част от кучето, но се използва само докато методът за ядене не бъде обработен.
Такава връзка се нарича връзка на използване и е показана в диаграмата на класа на UML с помощта на стрелка, обозначена с характеристиката.
UML асоциации
Били ли сте в приют преди?
В приют за животни има животни (които биха си помислили това), зайци, котки, мишки, а също и кучета, за които се грижи зоопарк.
Очевидно има връзка между кучето и пазача в приюта за животни.
Връзката обаче не е толкова силна, че едното не може без другото.
И зоопаркът, и кучето могат да съществуват сами.
Куче може да бъде щастливо интегрирано в семейство и има зоологи, които се грижат само за полярната мечка Кнут.
Такива слаби връзки се показват с помощта на проста свързваща линия между класовете.
UML агрегации и композиции
Често се налага да имаме работа с класове, които съдържат екземпляри на други класове като атрибути.
Например, приютът за животни има случаи на пазач и куче.
Тук обаче отново е важно приемното куче и пазителят на зоопарка да съществуват без приюта за животни.
Приемното куче е още по-бедно куче без приюта за животни, а гледачът на животни е безработен животновъд без приют за животни.
Но и двамата все още са там. Такава връзка се нарича агрегиране и е маркирана с диамантен символ в диаграмата на класа на UML.
Композицията!
По-силна асоциация е така нареченият състав.
При този тип асоцииране връзката е толкова силна, че когато "контейнерният обект" бъде изтрит, интегрираният обект също изчезва.
Точно такъв е случаят с нашия Fressnapf!
Защото ако изхвърлим купата, пълна с храна, ние също губим храната, която тя съдържа.
Маркираме композиция с завършен диамантен символ.
Как се различават агрегирането и съставът при изпълнението?
Решаващата разлика между агрегирането и състава е силата на връзката.
Нека разгледаме един пример.
Тук създаваме кучешки екземпляр, който заклеймяваме в дом, използвайки конструктора на класа за приют за животни.
Какво се случва с bello, когато изтрием екземпляра на приюта?
Нищо! Тъй като инстанцията bello е в собствената си област на паметта, която е независима от района, в който се намира приютът за животни.
Екземплярът на приюта съдържа само препратка към обекта bello .
Следователно в този случай това е агрегация.
Нека да разгледаме състава.
Тук създаваме купа за храна, пълна с храна.
Генерираме храната в аргумента на конструктора Fressnapf, поради което храната е в областта на паметта, запазена за Fressnapf.
И така, какво се случва с емисията, ако изтрием екземпляра на купата?
Правилно! С купата губим и храната, поради което в случая това е композиция.
Наследяване в диаграмата на UML класа
Липсва ли ви нещо? да, аз също!
Кучето е приятел с четири крака, точно като котка или слон. Затова представяме клас четириноги приятели, в който прилагаме общите свойства на четириног приятел и извличаме от тях животните куче, котка и др.
Наследството е показано в диаграмата на класа на UML с помощта на стрелка.
Приятел с четири крака е горният клас на кучето, в който ние прилагаме методите и свойствата, които са общи за всички приятели с четири крака.
Приятелят с четири крака е висш клас на кучето, посочваме със стрелка, сочеща към класа с четири крака.
теория и практика
Описаната тук процедура се нарича модел на водопада.
С модела на водопада предполагаме, че знаем всички изисквания от самото начало и също така приемаме, че те няма да се променят по време на целия процес на разработка.
На практика това изискване за съжаление често не е изпълнено, поради което се използва итеративно разработване, при което паралелно се извършват типичните разработки като проектиране, внедряване и тестове.
Във всяка стъпка на итерация се усъвършенстват изискванията, на които трябва да отговаря софтуерът.
Agile разработването на софтуер в момента е най-популярното тук.
Не на последно място, в следващото видео бих искал да ви покажа как да конвертирате диаграмата на класа в изходен код.
Заключение: Дори ако създаването на диаграма на UML клас първоначално изглежда като ненужна допълнителна работа, в действителност правите ценна подготвителна работа, която ви спестява много корекции на грешки по време на внедряването.
Работили ли сте вече с диаграмата на класа на UML? Какъв е вашият опит Просто ми оставете коментар!
Хареса ли ви статията? След това веднага ни последвайте във Facebook!
Ким Питър
Здравейте, казвам се Ким и искам да стана страхотен програмист. Участвате ли?