Diagrama de clasă

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 9 septembrie 2018; verificările necesită 28 de modificări .

Diagrama de clasă ( ing.  diagrama de clasă ) - o diagramă structurală a limbajului de modelare UML , care demonstrează structura generală a ierarhiei claselor de sistem , cooperările, atributele (câmpurile), metodele , interfețele și relațiile (relațiile) dintre acestea. Este utilizat pe scară largă nu numai pentru documentare și vizualizare, ci și pentru proiectare prin inginerie directă sau inversă [1] .

Introducere

Scopul creării unei diagrame de clase este o reprezentare grafică a structurii statice a elementelor declarative ale sistemului (clase, tipuri etc.) Conține și unele elemente de comportament (de exemplu, operații), dar dinamica acestora ar trebui să fie reflectată. în diagrame de alte tipuri ( diagrame de comunicare, diagrame de stare). Pentru comoditatea percepției, diagrama de clase poate fi completată și cu o reprezentare a pachetelor , inclusiv imbricate [2] .

Când reprezintă entități în lumea reală, dezvoltatorul trebuie să reflecte starea lor actuală, comportamentul și relațiile lor reciproce. În fiecare etapă, abstracția se face din detalii neimportante și concepte care nu se aplică realității (performanță, încapsulare , vizibilitate etc.). Clasele pot fi privite din perspectiva diferitelor niveluri. De regulă, ele se disting prin trei principale: nivelul analitic, nivelul de proiectare și nivelul de implementare [3] :

Elementele diagramei

Diagrama de clasă este un element cheie în modelarea orientată pe obiecte. În diagramă, clasele sunt prezentate în casete care conțin trei componente:

UML oferă mecanisme pentru reprezentarea membrilor clasei, cum ar fi atribute și metode, și informații suplimentare despre aceștia.

Vizibilitate

Pentru a seta vizibilitatea membrilor clasei (adică la orice atribute sau metode), aceste simboluri trebuie plasate înaintea numelui membrului: [4]

+ Public
- Privat (Privat)
# Protejat
/ Derivat (poate fi combinat cu altele)
~ Pachet

Domeniul de aplicare

UML definește două tipuri de domenii pentru membri: instanță și clasificator , acesta din urmă având nume subliniate . [5]

Numele este subliniat pentru a indica apartenența la clasificator , în caz contrar se presupune că domeniul de aplicare este cel implicit.

Relații

O relație este un tip special de relație logică între entități, prezentată în diagramele de clase și obiecte . UML are următoarele tipuri de relații:

Relații între obiectele clasei

Dependență

Dependența denotă o relație între clase, astfel încât o modificare a specificației clasei furnizorului poate afecta activitatea clasei dependente, dar nu invers.

Asociație

O asociere arată că obiectele unei entități (clase) sunt asociate cu obiectele unei alte entități în așa fel încât să puteți trece de la obiectele unei clase la alta. Este un caz general de compunere și agregare.

De exemplu, clasa Persoană și clasa Școala au o asociere, deoarece o persoană poate studia la o școală. O asociație poate primi numele de „studii în”.

Asociațiile duble sunt reprezentate de o linie fără săgeți la capete, care leagă două blocuri de clasă. Asociațiile de grad superior au mai mult de două capete și sunt reprezentate prin linii, dintre care un capăt merge la blocul de clasă, iar celălalt la diamantul comun. În vizualizarea asocierii unidirecționale, este adăugată o săgeată pentru a indica direcția asocierii.

O asociere poate fi numită, iar rolurile, afilierile, indicatorii, multiplicatorii, vizibilitatea sau alte proprietăți pot fi etichetate la capetele liniei care o reprezintă.

Agregare

Agregarea  este un fel de asociere în relația dintre întreg și părțile sale. Ca tip de asociere, o agregare poate fi numită. O relație de agregare nu poate include mai mult de două clase (container și conținut).

Agregarea are loc atunci când o clasă este o colecție sau un container al altora. Și implicit, agregarea se numește agregare prin referință , adică atunci când durata de viață a claselor conținute nu depinde de durata de viață a clasei care le conține. Dacă recipientul este distrus, atunci conținutul său nu este.

Grafic, o agregare este reprezentată printr-un romb gol pe o casetă de clasă și o linie de la acel diamant la clasa care o conține.

Compoziție

Compoziția  este o versiune mai strictă a agregării. Cunoscută și sub denumirea de agregare după valoare.

Compoziția are o dependență puternică de durata de viață a instanțelor clasei container și a instanțelor clasei conținute. Dacă recipientul este distrus, atunci tot conținutul său va fi, de asemenea, distrus.

Reprezentat grafic ca agregare, dar cu un diamant umplut.

Diferențele dintre compoziție și agregare

Să luăm un exemplu ilustrativ. Camera face parte din apartament, prin urmare compoziția este potrivită aici, deoarece camera nu poate exista fără apartament. Și, de exemplu, mobilierul nu este o parte integrantă a apartamentului, dar, în același timp, apartamentul conține mobilier, așa că ar trebui folosită agregarea.

Relații de clasă

Generalizare (moștenire)

Generalizarea arată că una dintre cele două clase înrudite ( subtip ) este o formă specială a celeilalte ( supertip ), care se numește o generalizare a primei. În practică, aceasta înseamnă că orice instanță a subtipului este și o instanță a supertipului. De exemplu: animalele sunt supertipul mamiferelor, care, la rândul lor, sunt supertipul primatelor și așa mai departe. Această relație este cel mai ușor descrisă de expresia „A este B” (primatele sunt mamifere, mamiferele sunt animale).//

Grafic, generalizarea este reprezentată printr-o linie cu un triunghi gol la supertip.

Generalizarea este cunoscută și ca moștenire sau „ este o relație” (sau „este o relație”).

Implementare

Implementarea este o relație între două elemente ale modelului, în care un element ( client ) implementează comportamentul specificat de celălalt ( furnizor ). Realizarea este o relație în întregime. Grafic, implementarea este reprezentată în același mod ca și moștenirea, dar cu o linie punctată.

Un furnizor este de obicei o clasă abstractă sau o clasă de interfață.

Relație generală

Dependență

O dependență este o formă slabă de relație de utilizare în care o modificare a specificației uneia implică o schimbare a specificației celeilalte fără a fi neapărat inversată. Apare atunci când un obiect apare, de exemplu, sub forma unui parametru sau variabilă locală.

Reprezentat grafic printr-o săgeată întreruptă care merge de la elementul dependent la cel de care depinde.

Există mai multe variante denumite.

O dependență poate fi între instanțe, clase sau o instanță și o clasă.

Perfecţionarea relaţiilor

Rafinamentul are de-a face cu nivelul de detaliu. Un pachet rafinează altul dacă conține aceleași elemente, dar într-o reprezentare mai detaliată. De exemplu, atunci când scrieți o carte, probabil că veți începe prin a formula o propoziție care rezumă pe scurt conținutul fiecărui capitol. Să presupunem că rezumatul fiecărui capitol este inclus ca element separat în pachetul „Propunere”. Să presupunem, de asemenea, că „Cartea finalizată” este un pachet ale cărui elemente sunt capitole completate. În acest context, pachetul „Cartea Completată” este o perfecționare a pachetului „Ofertă”.

Puterea relațiilor (Multiplicitatea)

Cardinalitatea relației (multiplicatorul) înseamnă numărul de legături dintre fiecare instanță de clasă (obiect) la începutul liniei cu instanța de clasă la sfârșitul acesteia. Există următoarele cazuri tipice:

notaţie explicaţie exemplu
0..1 Zero sau o singură instanță Pisica are un stăpân.
unu Este necesară o copie pisica are o singură mamă
0..* sau * Zero sau mai multe cazuri o pisică poate avea sau nu pisoi
unu..* Una sau mai multe cazuri o pisică are cel puțin un loc unde doarme

Vezi și

Note

  1. Booch, Rambeau, Jacobson, 2006 , Diagrama de clasă, p. 120.
  2. Butch, Jacobson, Rambo, 2006 , diagramă de clasă (diagrama de clasă), p. 226.
  3. Booch, Jacobson, Rambeau, 2006 , Clasele, p. 68.
  4. UML Reference Card, Versiunea 2.1.2 , Holub Associates, august 2007 , < http://www.holub.com/goodies/uml/ > . Preluat la 12 martie 2011. Arhivat 2 martie 2010 la Wayback Machine 
  5. OMG Unified Modeling Language (OMG UML) Superstructure Arhivat la 13 martie 2016 la Wayback Machine , Versiunea 2.3: mai 2010. Preluat la 23 septembrie 2010.

Surse

  • G. Booch, D. Rambo, I. Jacobson. Limbajul UML. Ghidul utilizatorului = Ghidul utilizatorului Unified Modeling Language. - al 2-lea. - M.  : DMK Press, 2006. - 496 p. — ISBN 5-94074-334-X .
  • G. Booch, A. Jacobson, D. Rambo,. UML. Classic CS = The Unified Modeling Language Reference Manual. - al 2-lea. - Sankt Petersburg.  : „Petru”, 2006. - 736 p. — ISBN 5-469-00599-2 .

Link -uri