Acesta este un scurt tutorial despre diagramele de clasa UML. Vom discuta despre ce sunt, de ce sunt necesare, cateva lucruri tehnice si apoi ne vom arunca intr-un exemplu.

Sa presupunem ca trebuie sa proiectezi un sistem. Inainte de a implementa o gramada de clase, veti dori sa aveti o intelegere conceptuala a sistemului – adica, de ce clase am nevoie? Ce functionalitate si informatii vor avea aceste clase? Cum interactioneaza intre ei? Cine poate vedea aceste cursuri? Si asa mai departe.

Aici intervin diagramele de clasa. Diagramele de clasa sunt un mod ordonat de a vizualiza clasele din sistemul dvs. inainte de a incepe efectiv sa le codificati. Sunt o reprezentare statica a structurii sistemului dvs.

Exemplu de diagrama de clasa pentru un sistem bancar

Aceasta este o diagrama destul de simpla. Cu toate acestea, pe masura ce sistemul dvs. se extinde si creste, devine din ce in ce mai dificil sa tineti evidenta tuturor acestor relatii. A avea o diagrama precisa, organizata si directa pentru a face acest lucru pentru dvs. este parte integranta a succesului sistemului dvs.

  1. Planificarea si modelarea din timp fac programarea mult mai usoara.
  2. In afara de aceasta, modificarea diagramelor de clasa este usoara, in timp ce functionarea diferita a codarii dupa fapt este cam deranjanta.
  3. Cand cineva vrea sa construiasca o casa, nu doar apuca un ciocan si se apuca de treaba. Ei trebuie sa aiba un plan – un plan de proiectare – astfel incat sa poata ANALIZA si modifica sistemul lor.
  4. Nu aveti nevoie de prea multe cunostinte tehnice / specifice limbii pentru a le intelege.

Reprezentarea clasei in UML

O clasa este reprezentata ca o cutie cu 3 compartimente. Cel mai de sus contine numele clasei. Cel din mijloc contine atributele clasei, iar ultimul contine metodele clasei. Ca aceasta:

Acestia adera la urmatoarea conventie:

nume atribut: tip

numele metodei (parametru: tip)

Vizibilitatea membrilor clasei

Membrii clasei (atribute si metode) au o vizibilitate specifica atribuita acestora. Vedeti tabelul de mai jos pentru a le reprezenta in UML.

vizibilitate si cum sa o denotam

Sa specificam vizibilitatea membrilor clasei BankAccount de mai sus.

Am facut „proprietarul” si soldul privat, precum si metoda de retragere . Dar am pastrat metoda de depunere publica. (Oricine poate pune bani, dar nu toata lumea poate scoate bani. La fel cum ne place noi.)

Rezumatul tipurilor de relatii si notatia acestora

Asociere

o relatie intre doua clase separate. Se alatura doua entitati complet separate. Exista patru tipuri diferite de asociere: bidirectionala, unidirectionala, agregare (include agregarea compozitiei) si reflexiva. Asocierile bidirectionale si unidirectionale sunt cele mai frecvente.

Acest lucru poate fi specificat folosind multiplicitate (unu la unu, unul la multi, multi la multi etc.).

O implementare tipica in Java este prin utilizarea unui camp de instanta. Relatia poate fi bidirectionala, fiecare clasa avand o referinta la cealalta.

Mostenire

indica faptul ca copilul (subclasa) este considerat a fi o forma specializata a parintelui (super clasa). De exemplu, luati in considerare urmatoarele:

Mai sus avem o clasa de parinte animal cu toate campurile membre publice. Puteti vedea sagetile provenite din clasele de rata, peste si zebra care indica faptul ca mostenesc toti membrii din clasa animalelor. Nu numai asta, dar isi implementeaza si propriile campuri de membri unice. Puteti vedea ca clasa rata are o metoda swim (), precum si o metoda quack ().

Realizare / Implementare

o relatie intre doua elemente model, in care un element model implementeaza / executa comportamentul specificat de celalalt element model.

exemplu de unelte

Dependenta

Agregare

o forma speciala de asociere, care este o relatie unidirectionala (cunoscuta si ca sens unic) intre clase. Cel mai bun mod de a intelege aceasta relatie este sa o numiti o relatie „are o” sau „face parte din”. De exemplu, luati in considerare cele doua clase: Wallet si Money. Un portofel „are” bani. Dar banii nu trebuie sa aiba in mod necesar un portofel, deci este o relatie unidirectionala.

Compozitie

o forma restrictionata de agregare in care doua entitati (sau puteti spune clase) sunt foarte dependente una de cealalta.

Un om are nevoie de o inima pentru a trai si o inima are nevoie de un corp uman pentru a functiona. Cu alte cuvinte, cand clasele (entitatile) sunt dependente una de cealalta si durata lor de viata este aceeasi (daca una moare si alta), atunci este o compozitie.

Multiplicitate

dupa specificarea tipului de relatie de asociere prin conectarea claselor, puteti declara, de asemenea, cardinalitatea dintre entitatile asociate. De exemplu:

Diagrama UML de mai sus arata ca o casa are exact o bucatarie, exact o baie, cel putin un dormitor (poate avea multe), exact o cutie postala si cel mult o ipoteca (zero sau una).