Дијаграм на класа UML; На овој начин ја следите ориентацијата на објектот! научете да програмирате
Учење на клучни зборови:
- Како да се прикажат односите помеѓу часовите со дијаграм на класа UML.
- Што треба да се разгледа во објектно-ориентиран дизајн?
- Како да се прикажат атрибутите и методите во дијаграм на класа.
- Што е мноштво?
- Како ги претставувате односите помеѓу часовите.
- Која е разликата помеѓу агрегацијата и составот?
- Како да се претстави наследството во дијаграмот на класа UML.
Ние веќе знаеме.
Освен ако не го сториш тоа погрешно, ќе завршиш во пекол!
И, сигурно не сакаме да одиме таму!
Пред да ги погодите копчињата, дефинитивно треба да направите неколку размислувања.
Добредојдени сте да го сторите тоа во градината со кул кола. Главната работа е што имате при рака подлога за пишување и молив со гума за бришење.
Или можете да го користите слободниот софтвер UMLet.
Бидејќи голема предност на објектно-ориентираниот дизајн е тоа што компонентите и нивните односи можат графички да бидат претставени во софтверски систем.
Исто како што направивме тука со класа четвороножни пријатели.
Таканаречениот дијаграм на класа UML е многу паметен начин за визуелно претставување на часовите и нивните односи. UML се залага за унифициран јазик за моделирање.
Дијаграмот на класа е алатка што треба итно да ја додадете во полето со алатки.
Како и секоја алатка, сепак, можете ефикасно да го користите дијаграмот на класа UML ако ја разбирате неговата област на примена.
Значи, да почнеме со разговор за тоа за кои работи треба да се грижиме во објектно-ориентиран дизајн.
Објектно-ориентиран дизајн со дијаграм на класа UML
Класа се состои од три компоненти. Секоја класа има име, својства (исто така наречени атрибути) и методи.
Ние создаваме конкретни предмети од часовите (инстант). На пример, класата кучиња станува пример за кучиња со името Снупи и тежина од 20 кг.
Атрибутите на часот ја опишуваат состојбата на објектот, како што се името и тежината на кучето.
Методите, пак, го опишуваат однесувањето на некој предмет и му даваат способности, како што е кучето да лае.
Во дијаграмот за UML класа, овие три елементи се одделени едни од други со хоризонтални линии. За примерот со нашето куче, дијаграмот на часот изгледа вака:
На врвот е името на часот. Во нашиот случај класата се нарекува куче.
Средниот дел ги содржи атрибутите на класата. Значи, името и тежината на кучето.
Секој атрибут има тип на податок кој е одделен со дебело црево по соодветното име на атрибутот.
Методите се наведени заедно со списокот со параметри и повратната вредност во долниот дел од дијаграмот на UML-класа, со типот на податок на повратната вредност по дебелото црево.
Тука се занимаваме со прилично едноставно куче. Покрај методот на лаење, нашата класа ги содржи само методите на прибирање и поставување на атрибутите.
Нема ли нешто друго?
Сигурен сум дека веќе сте забележале!
Ние ги префиксиравме атрибутите со знак минус - и методите со знак +.
Како што знаете од основите на објектно-ориентираното програмирање, инстантните променливи не треба да бидат видливи однадвор за да ги заштитите од манипулација, т.е. треба да бидат прогласени за приватни.
Лицето вешто во уметноста зборува за енкапсулација.
И тоа е токму она што се залага за знакот минус -. Атрибут или метод на кој му претходи знак минус се прогласува за приватен, додека знакот плус + значи атрибут или метод дефиниран како јавен.
Се разбира, исто така е можно да се дефинираат атрибутите и методите како заштитени.
Атрибутите декларирани како заштитени или дефинирани методи треба да бидат видливи само во самата класа и во сите подкласи.
Во дијаграмот за класа UML, ја обележуваме видливоста заштитена со знакот за хаш #.
Класни променливи во дијаграмот на класа UML
Досега, нашите атрибути секогаш беа инстантни варијабли. Секоја инстанца од нашата класа на кучиња зазема своја посебна област на меморија.
Но, што ако сакаме да го изброиме бројот на создадени предмети од кучиња?
За оваа цел, потребна ни е ЕДНА цел број променлива до која имаат пристап сите инстанци на кучиња.
Таквата променлива се нарекува класна променлива и е дефинирана во Јава со користење на статички клучен збор.
Во дијаграмот на класа UML, променливите на класите се обележани со подвлечено.
Ајде! Да додадеме класна променлива на горниот дијаграм со кој можеме да го изброиме бројот на произведени кучиња.
Тоа беше лесно, нели? Единствено требаше да додадеме подвлечна цел број променлива hundZaehler на атрибутниот дел од дијаграмот на класа UML.
Мноштво во дијаграмот на класа UML
Досега си го олеснувавме тоа. Досега, нашите атрибути се состоеја само од примитивни типови на податоци. Но, што правиме ако сакаме да користиме низи или списоци со низи?
За ова постои таканаречена мноштво.
Секако, нашето куче има три омилени играчки, имено ressубовница, Лего и палка за бејзбол.
И точно по овој редослед!
Значи, ни треба низа што може да ги собере овие три елементи по даден редослед.
За да го направите ова, ја пишуваме таканаречената мноштво [1.3] и идентификаторот зад атрибутот што играчките го прифаќаат.
Ние го одредуваме капацитетот на низата преку мноштво [1.3]. Со додавањето, ние посочуваме дека играчките за клевета се подредена структура на податоци во која низата е важна.
Покрај тоа, гордо куче ќе најде нова храна секој ден што му се допаѓа.
Затоа, потребна ни е и структура на податоци што може да прими кој било број на елементи. Покрај тоа, секоја најава треба да се зачува само еднаш, т.е. јасно, во структурата на податоците.
UML обезбедува мноштво [*] и идентификатор за оваа намена.
Па, ајде да го прошириме нашиот дијаграм на класа UML уште еднаш.
Нашето куче сега може да има кој било број на омилени оброци. Сепак, секоја храна може јасно да се зачува само во омилениот атрибут на храна. Со constвездието од типот: „Омилени јадења ми се 1-та пица, 2-та и 3-та пица“ не е можно поради етикетата.
Константи во дијаграмот на класа UML
Со цел да ја зголемите одржливоста на вашите програми, треба да дефинирате вредности кои не се менуваат во константите.
Најпознатото од сите константи е Пи.Наместо да пишуваме 3.14 . каде и да пресметуваме со бројот Пи, ние ја користиме константната математика.PI .
Константите се прогласени за конечни во Јава со помош на клучниот збор и со оглед на додавањето во дијаграмот на класа UML.
Честа употреба на константи се броевите на верзиите. Па, ајде да го прошириме нашиот дијаграм на класа UML повторно.
Бидејќи верзијата на класата е иста за секоја инстанца на кучето, променливата ВЕРЗИЈА е класна променлива што мора да биде подвлечена во дијаграм на класа.
Од дијаграм на класа UML до програмски код
Целта на нашите напори е извршна програма.
Сите наши напори досега ќе бидат од корист само ако можеме што полесно да го преведеме дијаграмот на класа во изворен код на Јава.
И токму за ова сакаме да се грижиме следно.
Еве го изворниот код генериран од дијаграм на класа.
Во линиите два и три ги прогласуваме примитивните атрибути со име и тежина .
Потоа, ние користиме список со низи за складирање на омилените играчки и HashSet за чување на омилената храна на нашето куче.
Ние користиме HashSet за ова затоа што мора да го зачуваме јасно во нашата структура на податоци заради обележувањето на оброците.
На крај, но не и најважно, ја додаваме статичката бројачка променлива hundZaehler и постојаната ВЕРЗИЈА како атрибути во линиите шест и седум.
Методите се наведени на линиите осум до дванаесет.
Ова исто така појаснува што НЕ може да направи дијаграмот на класа UML. Дијаграмот на класа опишува само кои методи ги прави достапна една класа. Сепак, тоа не дава никакви индикации за тоа како функционалноста на овие методи мора да се спроведе.
Значи, дијаграмот на класата не ни помага да моделираме алгоритам. За оваа цел, сепак, UML обезбедува други дијаграми, како што е дијаграмот за низа.
Вака ги претставувате односите во дијаграмот за класа UML
Искрено! Досега, сето тоа е само досадно и воопшто не помага.
Можевте да зачукате една класа кучиња во компјутерот без сите напори.
Интересно станува само кога нашиот софтверски систем се состои од повеќе од една класа и сакаме да опишеме како овие класи се поврзани едни со други.
Исто како што постојат пријателски, романтични или деловни односи во реалниот живот, исто така има и различни видови на односи во ориентација на објектот.
Да почнеме со првиот тип, имено зависностите, кои во специјалистичката литература честопати се нарекуваат и зависности.
Зависности во дијаграмот на класа UML
Куче е гладно и јаде од сад за храна.
Fressnapf е објект што го создаваме од класа Fressnapf и јадеме е метод на класа кучиња со пример Fressnapf како параметар.
Инстанцата Fressnapf не е составен дел на кучето, туку се користи само додека не се обработи методот на јадење.
Таквата врска се нарекува употребна врска и е прикажана на дијаграмот на класа UML со помош на стрела означена со карактеристиката.
Здруженија на УМЛ
Дали сте биле претходно во прифатилиште?
Во засолниште за животни има животни (кои би помислиле дека), зајаци, мачки, глувци и исто така кучиња за кои чуварот на зоолошката градина се грижи.
Очигледно постои врска помеѓу кучето и чуварот во засолништето.
Сепак, врската не е толку силна што едниот не може без другиот.
И чувар на чувари и куче можат да постојат самостојно.
Куче може среќно да се интегрира во семејство и има чувари на зоологија кои само се грижат за поларната мечка Кнут.
Таквите слаби врски се прикажани со помош на едноставна линија за поврзување помеѓу часовите.
Агрегации и композиции на UML
Честопати се занимаваме со класи кои содржат инстанци од други класи како атрибути.
На пример, во прифатилиштето за животни има случаи на чувар и куче.
Сепак, тука повторно е важно и згрижувачкото куче и чуварот на зоолошката градина да можат да постојат без засолништето за животни.
Кучето згрижувач е уште посиромашно куче без засолниште за животни, а чувар на животни е невработен чувар на животни без засолниште за животни.
Но, и двајцата се сè уште таму. Таквата врска се нарекува агрегација и е обележана со дијамантски симбол во дијаграмот за класа UML.
Составот!
Посилна асоцијација е таканаречениот состав.
Со овој вид асоцијација, односот е толку силен што кога ќе се избрише „контејнерскиот предмет“, исто така исчезнува и интегрираниот предмет.
Ова е токму случајот со нашиот Фреснапф!
Затоа што ако го фрлиме садот исполнет со храна, ја губиме и храната што ја содржи.
Обележуваме композиција со завршен дијамантски симбол.
Како агрегацијата и составот се разликуваат во спроведувањето?
Клучната разлика помеѓу агрегацијата и составот е силата на врската.
Да погледнеме еден пример.
Тука создаваме куче на пример за куче, кое го нанесуваме во дом користејќи го конструкторот од класата за засолниште за животни.
Што се случува со бело кога ќе ја избришеме инстанцата за засолниште?
Ништо! Бидејќи инстантното бело е во сопствената мемориска област, која е независна од областа во која се наоѓа засолништето за животни.
Инстанцата за засолниште содржи само упатување на објектот бело .
Затоа, во овој случај станува збор за агрегација.
Ајде да погледнеме во составот.
Тука создаваме сад за храна исполнет со храна.
Ние ја генерираме храната во аргументот на конструкторот Fressnapf, поради што храната е во мемориската област резервирана за Fressnapf.
Па, што се случува со фидот ако ја избришеме инстанцата на садот?
Правилно! Со садот ја губиме и храната, поради што во овој случај станува збор за состав.
Наследство во дијаграмот на класа UML
Дали ви недостига нешто? Да и јас!
Куче е пријател со четири нозе, исто како мачка или слон. Затоа, воведуваме класа четвороножни пријатели во кои ги спроведуваме општите својства на четириножниот пријател и од нив ги извлекуваме животните куче, мачка и сл.
Наследството е прикажано на дијаграмот на класа UML со помош на стрела.
Пријател со четири нозе е горната класа на кучето, во кој ги имплементираме методите и својствата што ги имаат сите пријатели со четири нозе.
Пријателот со четири нозе е повисока класа на кучето, посочуваме со стрела која покажува кон класата со четири нозе.
теорија и пракса
Постапката опишана овде се нарекува модел на водопад.
Со моделот водопад, претпоставуваме дека ги знаеме сите барања од самиот почеток и исто така претпоставуваме дека тие нема да се променат во текот на целиот процес на развој.
Во пракса, ова барање, за жал, честопати не е исполнето, па затоа се користи итеративен развој во кој типичната работа за развој, како што се дизајнирање, спроведување и тестови, се одвиваат паралелно.
Во секој чекор на повторување, рафинирани се барањата што треба да ги исполнува софтверот.
Агилниот развој на софтвер во моментов е врвно куче овде.
На крај, но не и најмалку важно, во следното видео би сакал да ви покажам како да го претворите дијаграмот на класа во изворен код.
Заклучок: Дури и ако креирањето на дијаграм за класа UML првично изгледа како непотребна дополнителна работа, во реалноста вие работите вредна подготвителна работа, што ви заштедува многу корекции на грешки при имплементација.
Дали веќе сте работеле со дијаграмот на класа UML? Кое е вашето искуство Само остави ми коментар!
Дали ви се допадна статијата? Потоа следете не на Фејсбук веднаш!
Ким Питер
Здраво, јас се викам Ким и сакам да станам одличен програмер. Дали учествувате?