Diagrama clasei UML; În acest fel, țineți evidența orientării obiectului! învățați să programați
Tastaturi:
- Cum se arată relațiile dintre clase cu o diagramă de clasă UML.
- Ce ar trebui luat în considerare într-un design orientat obiect?
- Cum se afișează atribute și metode în diagrama clasei.
- Ce este multiplicitatea?
- Cum reprezentați relațiile dintre clase.
- Care este diferența dintre agregare și compoziție?
- Cum se reprezintă moștenirea în diagrama clasei UML.
Știm deja.
Dacă nu faci greșit, vei ajunge în iad!
Și cu siguranță nu vrem să mergem acolo!
Deci, înainte de a apăsa tastele, ar trebui să vă gândiți cu siguranță.
Ești binevenit să faci asta în grădină cu o cola răcoroasă. Principalul lucru este că aveți la îndemână un bloc de scris și un creion cu o radieră.
Sau puteți utiliza software-ul gratuit UMLet.
Deoarece un mare avantaj al designului orientat pe obiecte este că componentele și relațiile lor pot fi reprezentate grafic într-un sistem software.
La fel cum am făcut aici cu o clasă de prieteni cu patru picioare.
Așa-numita diagramă de clasă UML este un mod foarte inteligent de a reprezenta vizual clasele și relațiile lor. UML înseamnă Unified Modeling Language.
Diagrama clasei este un instrument pe care ar trebui să-l adăugați urgent la setul de instrumente.
La fel ca orice instrument, totuși, puteți utiliza diagrama de clasă UML în mod eficient numai dacă înțelegeți zona sa de aplicație.
Deci, să vorbim mai întâi despre ce lucruri trebuie să ne îngrijorăm într-un design orientat pe obiecte.
Proiectare orientată obiect cu diagrama de clasă UML
O clasă constă din trei componente. Fiecare clasă are un nume, proprietăți (numite și atribute) și metode.
Creăm obiecte concrete din clase (instantanee). De exemplu, clasa de câine devine o instanță de câine cu numele Snoopy și o greutate de 20 kg.
Atributele clasei descriu starea obiectului, cum ar fi Numele și greutatea unui câine.
Metodele, pe de altă parte, descriu comportamentul unui obiect și îi conferă capacități, cum ar fi că un câine poate să latre.
În diagrama clasei UML, aceste trei elemente sunt separate între ele prin linii orizontale. Pentru exemplul câinelui nostru, diagrama clasei arată astfel:
În partea de sus este numele clasei. În cazul nostru, clasa se numește câine.
Partea din mijloc conține atributele clasei. Deci numele și greutatea câinelui.
Fiecare atribut are un tip de date care este scris după numele atributului respectiv, separat de două puncte.
Metodele sunt listate împreună cu lista parametrilor și valoarea returnată în partea inferioară a diagramei clasei UML, cu tipul de date al valorii returnate după colon.
Aici avem de-a face cu un câine destul de simplu. În plus față de metoda de lătrat, clasa noastră conține doar metodele getter și setter pentru atribute.
Nu există altceva?
Sunt sigur că ai observat deja!
Am prefixat atributele cu un semn minus - și metodele cu un semn +.
După cum știți din elementele de bază ale programării orientate pe obiecte, variabilele de instanță nu ar trebui să fie vizibile din exterior pentru a le proteja împotriva manipulării, adică ar trebui declarate private.
Persoana calificată în domeniu vorbește despre încapsulare.
Și tocmai asta înseamnă semnul minus -. Un atribut sau o metodă precedată de un semn minus este declarată privată, în timp ce semnul plus + reprezintă un atribut sau o metodă definită ca publică.
Desigur, este, de asemenea, posibil să se definească atributele și metodele ca fiind protejate.
Atributele declarate ca metode protejate sau definite ar trebui să fie vizibile numai în cadrul clasei în sine și în toate subclasele.
În diagrama clasei UML, marcăm vizibilitatea protejată cu semnul hash #.
Variabile de clasă în diagrama de clasă UML
Până în prezent, atributele noastre au fost întotdeauna variabile de instanță. Fiecare instanță din clasa noastră de câini ocupă propria sa zonă de memorie separată.
Dar dacă vrem să numărăm numărul de obiecte de câine create?
În acest scop avem nevoie de O variabilă întreagă la care au acces toate instanțele câinilor.
O astfel de variabilă se numește variabilă de clasă și este definită în Java folosind cuvântul cheie static.
În diagrama de clasă UML, variabilele de clasă sunt marcate cu un subliniat.
Haide! Să adăugăm o variabilă de clasă la diagrama de clasă de mai sus cu care putem număra numărul câinilor produși.
A fost ușor, nu-i așa? A trebuit să adăugăm o variabilă întreagă de subliniere hundZaehler la partea de atribut a diagramei clasei UML.
Multiplicitate în diagrama clasei UML
Până acum ne-am ușurat pentru noi înșine. Până în prezent, atributele noastre au constat doar din tipuri de date primitive. Dar ce facem când vrem să folosim tablouri sau liste de matrice?
Pentru aceasta există așa-numita multiplicitate.
Desigur, câinele nostru are trei jucării preferate, și anume amanta, Lego și o bată de baseball.
Și exact în această ordine!
Așadar, avem nevoie de o matrice care poate conține aceste trei elemente în ordinea dată.
Pentru a face acest lucru, scriem așa-numita multiplicitate [1.3] și identificatorul din spatele atributului care acceptă jucăriile.
Determinăm capacitatea matricei prin multiplicitatea [1.3]. Odată cu adăugarea, indicăm că jucăriile de calomnie sunt o structură de date ordonată în care secvența este importantă.
În plus, un câine mândru va găsi în fiecare zi mâncare nouă care îi place.
Prin urmare, avem nevoie și de o structură de date care să poată găzdui orice număr de elemente. În plus, fiecare alimentare trebuie utilizată o singură dată, adică în mod unic, stocate în structura datelor.
UML furnizează multiplicitatea [*] și identificatorul în acest scop.
Deci, să extindem încă o dată diagrama noastră de clasă UML.
Câinele nostru poate lua acum orice număr de mese preferate. Cu toate acestea, fiecare mâncare poate fi salvată în mod clar numai în atributul mâncării preferate. O constelație de genul: „Mâncărurile mele preferate sunt prima pizza, a doua pizza și a treia pizza” nu este posibilă din cauza etichetei.
Constantele din diagrama clasei UML
Pentru a crește capacitatea de întreținere a programelor dvs., ar trebui să definiți valori care nu se modifică în constante.
Cea mai faimoasă dintre constante este Pi. În loc să scriem 3.14 . oriunde calculăm cu numărul Pi, folosim constanta Math.PI .
Constantele sunt declarate finale în Java cu ajutorul cuvântului cheie și li se adaugă adăugarea în diagrama clasei UML.
O utilizare obișnuită a constantelor este numerele de versiune. Deci, să extindem din nou diagrama noastră de clasă UML.
Deoarece versiunea clasei este aceeași pentru fiecare instanță a câinelui, variabila VERSION este o variabilă de clasă care trebuie subliniată în diagrama clasei.
De la diagrama clasei UML la codul programului
Scopul eforturilor noastre este un program executabil.
Toate eforturile noastre de până acum vor fi benefice numai dacă putem traduce diagrama de clasă în cod sursă Java cât mai ușor posibil.
Și tocmai de asta vrem să avem grijă în continuare.
Iată codul sursă generat din diagrama clasei.
În rândurile două și trei declarăm atributele primitive nume și greutate .
Apoi, folosim o listă de matrice pentru a stoca jucăriile preferate și un HashSet pentru a stoca alimentele preferate ale câinelui nostru.
Folosim un HashSet pentru aceasta, deoarece trebuie să-l salvăm clar în structura noastră de date din cauza marcării de către mese.
În cele din urmă, în liniile șase și șapte, adăugăm variabile statice contoare hundZaehler și VERSIUNEA constantă ca atribute.
Metodele sunt enumerate pe liniile opt până la doisprezece.
Acest lucru clarifică și ce NU poate face diagrama de clasă UML. Diagrama clasei descrie doar ce metode pune la dispoziție o clasă. Cu toate acestea, nu oferă nicio indicație despre modul în care trebuie implementată funcționalitatea acestor metode.
Deci, diagrama de clasă nu ne ajută să modelăm un algoritm. Cu toate acestea, în acest scop, UML oferă alte diagrame, cum ar fi diagrama secvenței.
Așa reprezentați relațiile în diagrama clasei UML
Sincer! Până acum, totul este doar enervant și nu ajută deloc.
Ați fi putut ciocni o singură clasă de câine în computer fără toate eforturile.
Devine interesant doar atunci când sistemul nostru software constă în mai mult decât o singură clasă și vrem să descriem modul în care aceste clase sunt legate între ele.
Așa cum există relații prietenoase, romantice sau de afaceri în viața reală, există și diferite tipuri de relații în orientarea obiectului.
Să începem cu primul tip, și anume dependențele, care sunt deseori numite și dependențe în literatura de specialitate.
Dependențe în diagrama clasei UML
Un câine este flămând și mănâncă dintr-un bol pentru alimente.
Fressnapf este un obiect pe care îl creăm dintr-o clasă Fressnapf și mâncăm este o metodă a clasei câine cu o instanță Fressnapf ca parametru.
Instanța Fressnapf nu este o parte integrantă a câinelui, ci este utilizată numai până când metoda de mâncare a fost procesată.
O astfel de relație se numește relație de utilizare și este prezentată în diagrama clasei UML cu ajutorul unei săgeți etichetate cu caracteristica.
Asociații UML
Ai mai fost la un adăpost?
Într-un adăpost pentru animale există animale (care ar fi crezut asta), iepuri, pisici, șoareci și, de asemenea, câini de care are grijă un zoolog.
În mod evident, există o relație între câine și păzitor într-un adăpost.
Cu toate acestea, relația nu este atât de puternică încât una nu se poate descurca fără cealaltă.
Atât un zoolog cât și un câine pot exista singuri.
Un câine poate fi fericit integrat într-o familie și există îngrijitori de animale care se ocupă doar de ursul polar Knut.
Astfel de conexiuni slabe sunt prezentate cu ajutorul unei linii simple de legătură între clase.
Agregări și compoziții UML
Adesea avem de-a face cu clase care conțin instanțe din alte clase ca atribute.
De exemplu, adăpostul pentru animale are exemple de păzitor și câine.
Cu toate acestea, din nou, este important ca atât câinele adoptiv, cât și deținătorul grădinii zoologice să existe fără adăpostul pentru animale.
Câinele adoptiv este un câine și mai sărac, fără adăpost pentru animale, iar deținătorul animalului este un deținător de șomaj fără adăpost pentru animale.
Dar amândoi sunt încă acolo. O astfel de relație se numește agregare și este marcată cu un simbol de diamant în diagrama clasei UML.
Compozitia!
O asociere mai puternică este așa-numita compoziție.
Cu acest tip de asociere, relația este atât de puternică încât, atunci când „obiectul container” este șters, dispare și obiectul integrat.
Este exact cazul Fressnapf-ului nostru!
Pentru că dacă aruncăm vasul umplut cu alimente, pierdem și mâncarea pe care o conține.
Marcăm o compoziție cu un simbol de diamant completat.
Cum diferă agregarea și compoziția în implementare?
Diferența crucială dintre agregare și compoziție este forța relației.
Să vedem un exemplu.
Aici creăm o instanță de câine bello, pe care o plasăm într-o casă folosind constructorul clasei adăpost de animale.
Ce se întâmplă cu bello când ștergem instanța adăpostului?
Nimic! Deoarece exemplul bello se află în propria sa zonă de memorie, care este independentă de zona în care se află adăpostul pentru animale.
Instanța adăpostului conține doar o referință la obiectul bello .
Prin urmare, în acest caz este o agregare.
Să aruncăm o privire asupra compoziției.
Aici creăm un vas alimentar umplut cu alimente.
Generăm mâncarea în argumentul constructorului Fressnapf, motiv pentru care mâncarea se află în zona de memorie rezervată pentru Fressnapf.
Deci, ce se întâmplă cu fluxul dacă ștergem instanța bolului?
Corect! Cu bolul, pierdem și mâncarea, motiv pentru care în acest caz este o compoziție.
Moștenirea în diagrama clasei UML
Ți-e dor de ceva? da si eu!
Un câine este un prieten cu patru picioare, la fel ca o pisică sau un elefant. Prin urmare, introducem o clasă de prieteni cu patru picioare în care implementăm proprietățile generale ale unui prieten cu patru picioare și derivăm animalele câine, pisică etc.
Moștenirea este prezentată în diagrama clasei UML cu ajutorul unei săgeți.
Prietenii cu patru picioare sunt clasa superioară a câinilor, în care implementăm metodele și proprietățile pe care toți prietenii cu patru picioare le au în comun.
Prietenul cu patru picioare este o clasă superioară a câinelui, indicăm cu o săgeată îndreptată spre clasa cu patru picioare.
teorie și practică
Procedura descrisă aici se numește modelul cascadei.
Cu modelul cascadă, presupunem că cunoaștem toate cerințele de la început și, de asemenea, presupunem că acestea nu se vor schimba pe parcursul întregului proces de dezvoltare.
În practică, această cerință din păcate nu este adesea îndeplinită, motiv pentru care se folosește dezvoltarea iterativă în care lucrările tipice de dezvoltare, cum ar fi proiectarea, implementarea și testele, au loc în paralel.
În fiecare etapă de iterație, cerințele pe care ar trebui să le îndeplinească software-ul sunt rafinate.
În acest moment, dezvoltarea software-ului agil este cel mai important câine aici.
Nu în ultimul rând, în următorul videoclip aș dori să vă arăt cum să convertiți diagrama clasei în cod sursă.
Concluzie: Chiar dacă crearea unei diagrame de clasă UML pare inițial o muncă suplimentară inutilă, în realitate faceți o lucrare pregătitoare valoroasă, ceea ce vă economisește o mulțime de corecții de eroare în timpul implementării.
Ați lucrat deja cu diagrama clasei UML? Care este experiența ta Lasă-mi doar un comentariu!
Ți-a plăcut articolul? Apoi urmează-ne imediat pe Facebook!
Kim Peter
Bună, mă numesc Kim și vreau să devin un mare programator. Participi?