11.1. Structura limbajului de modelare unificat

Limbajul de modelare unificat (UML) este în prezent standardul de facto pentru descrierea (documentarea) rezultatelor proiectării și dezvoltării sistemelor orientate pe obiecte. Dezvoltarea UML a început în 1994 de către Grady Booch și James Rumbaugh la Rational Software. În toamna anului 1995, li s-a alăturat Ivar Jakobson, iar în octombrie a aceluiași an, a fost lansată o versiune preliminară a metodei unificate 0.8. De atunci, au fost lansate mai multe versiuni ale specificației UML, dintre care două au statutul de standard internațional:

UML 1.4.2 - "ISO/IEC 19501:2005. Tehnologia informației. Procesare distribuită deschisă. Limbajul de modelare unificat (UML). Versiunea 1.4.2");

UML 2.4.1 - „ISO / IEC 19505-1: 2012. Tehnologia informației. Limbajul de modelare unificat al grupului de management al obiectelor (OMG UML). Partea 1. Infrastructură” (Eng. „Tehnologia informației -- Limbajul de modelare unificat al grupului de management al obiectelor (OMG). UML) - Partea 1: Infrastructură") și "ISO / IEC 19505-2: 2012. Tehnologia informației. Limbajul de modelare a grupului de management unificat al obiectelor (OMG UML). Partea 2. Suprastructură" (în engleză "Tehnologia informației - Object Management Group Unified Modeling) Limbajul (OMG UML) - Partea 2: Suprastructură").

Cea mai recentă specificație a limbii oficiale poate fi găsită la www.omg.org.

Structura generală a UML este prezentată în figura următoare.

Orez. 11.1. Structura UML

11.2. Semantica și sintaxa UML

Semantică - o secțiune de lingvistică care studiază semnificația unităților unei limbi, în primul rând cuvintele și frazele acesteia.

Sintaxă - moduri de a conecta cuvintele și formele lor în fraze și propoziții, conectați propoziții în propoziții complexe, modalități de a crea enunțuri ca parte a textului.

Astfel, în raport cu UML, semantica și sintaxa determină stilul de prezentare (modele de construcție), care combină limbajele naturale și formale pentru a reprezenta conceptele de bază (elementele modelului) și mecanismele de extindere a acestora.

11.3. Notație UML

Notația este o interpretare grafică a semanticii pentru reprezentarea sa vizuală.

UML definește trei tip de entitate :

Structural - o abstractizare care este o reflectare a unui obiect conceptual sau fizic;

Grupare - un element folosit pentru o asociere semantică a elementelor diagramei;

Explicativ (adnotare) - un comentariu la un element de diagramă.

Următorul tabel oferă o scurtă descriere a principalelor entități utilizate în notația grafică și principalele modalități de afișare a acestora.

Tabelul 11.1. Esențe

Tip	Nume	Desemnare	Definiție (semantică)
Structural	(clasă)		Un set de obiecte care au o structură și un comportament comun
	(obiect)		O abstractizare a unei entități reale sau imaginare cu granițe conceptuale bine definite, individualitate (identitate), stare și comportament. Din punct de vedere UML, obiectele sunt instanțe de clasă (instanțe de entitate)
	(actor)	Inginer servicii de cale	O entitate externă sistemului care interacționează cu sistemul și își folosește funcționalitatea pentru a atinge anumite obiective sau pentru a rezolva anumite probleme. Astfel, un actor este o sursă sau un receptor extern de informație.
	(utilizare caz)		Descrierea acțiunilor efectuate de sistem, ceea ce duce la un rezultat semnificativ pentru actor
	(stat)		Descrierea momentului din viața unei entități în care aceasta îndeplinește o anumită condiție, desfășoară o anumită activitate sau așteaptă să aibă loc un eveniment.
	Cooperare (colaborare)		Descrierea unui set de instanțe de actori, obiecte și interacțiunea acestora în procesul de rezolvare a unei anumite probleme
	(componenta)		Partea fizică a sistemului (fișier), inclusiv modulele de sistem care asigură implementarea unui set consistent de interfețe
	(interfata)	iCalcul	Un set de operațiuni care definește un serviciu (set de servicii) furnizat de o clasă sau componentă
	(nodul)		Partea fizică a sistemului (calculator, imprimantă etc.) care oferă resurse pentru rezolvarea unei probleme
Gruparea	(pachet)		Mecanism general de grupare a elementelor. Spre deosebire de o componentă, un pachet este un concept pur conceptual (abstract). Cazurile speciale ale unui pachet sunt sistemul și modelul
	(fragment)		Zona de interacțiune specifică a instanțele actorului și obiectului
	(partiție de activitate)		Un grup de operațiuni (zona de responsabilitate) efectuate de o singură entitate (actor, obiect, componentă, nod etc.)
	(regiune de activitate întreruptibilă)		Un grup de operațiuni, a căror secvență normală de execuție poate fi întreruptă ca urmare a unei situații neobișnuite
explicativ	Notă (cometariu)		Comentariu element. Atașat la elementul comentat cu o linie întreruptă

Unele surse, în special [ , ], disting, de asemenea, entitățile comportamentale interacțiuniȘi mașini de stat, dar din punct de vedere logic ele ar trebui clasificate ca diagrame.

Unele dintre entitățile de mai sus în conformitate cu implică descrierea lor detaliată în diagramele de descompunere. Pe diagrama de nivel superior, acestea sunt marcate cu o pictogramă sau etichetă specială.

Următorul tabel descrie fiecare tip relaţii UML folosit în diagrame pentru a indica relațiile dintre entități.

Tabelul 11.3. Relaţii

Nume	Desemnare	Definiție (semantică)
Asociere		O relație care descrie o relație semnificativă între două sau mai multe entități. Cel mai general tip de relație
Agregare		Un subtip al unei asocieri care descrie o relație „parte”–„întreg”, în care „partea” poate exista separat de „întreg”. Rombul este indicat din partea „întreaga”. O relație este specificată numai între entități de același tip
Compoziţie		O subspecie de agregare în care „părțile” nu pot exista separat de „întregul”. De regulă, „părțile” sunt create și distruse simultan cu „întregul”
Dependenţă		O relație între două entități în care o schimbare într-o entitate (independentă) poate afecta starea sau comportamentul celeilalte entități (dependent). Pe partea laterală a săgeții este indicată o entitate independentă
Generalizare		Relația dintre o entitate generalizată (strămoș, părinte) și o entitate specializată (copil, fiică). Triunghiul este indicat din partea părintelui. O relație este specificată numai între entități de același tip
Realizare		O relație între entități în care o entitate specifică o acțiune pe care o altă entitate se angajează să o efectueze. Relațiile sunt utilizate în două cazuri: între interfețe și clase (sau componente), între cazuri de utilizare și colaborări. Partea laterală a săgeții indică entitatea care definește acțiunea (interfață sau caz de utilizare)

Pentru asociere, agregare și compunere, puteți specifica multiplicitate (multiplicitatea engleză), care caracterizează numărul total de instanțe ale entităților care participă la relație. Acesta, de regulă, este indicat de fiecare parte a relației lângă entitatea corespunzătoare. Multiplicitatea poate fi specificată în următoarele moduri:

- * - orice număr de copii, inclusiv niciunul;

Număr întreg nenegativ - multiplicitatea este strict fixă ​​și egală cu numărul specificat (de exemplu: 1, 2 sau 5);

Interval de numere întregi nenegative „primul număr.. al doilea număr” (de exemplu: 1..5, 2..10 sau 0..5);

O gamă de numere de la o anumită valoare inițială la un „primul număr..*” final arbitrar (de exemplu: 1..*, 5..* sau 0..*);

Enumerarea numerelor întregi nenegative și a intervalelor separate prin virgule (de exemplu: 1, 3..5, 10, 15..*).

Dacă multiplicitatea nu este specificată, atunci valoarea ei se presupune a fi 1. Multiplicitatea instanțelor de entitate implicate în dependență, generalizare și implementare este întotdeauna presupusă a fi 1.

Următorul tabel oferă o descriere mecanisme de expansiune folosit pentru a rafina semantica entităților și a relațiilor. În general, mecanismul de extindere este un șir de text cuprins între paranteze sau ghilimele.

Tabelul 11.4. Mecanisme de extindere

Nume	Desemnare	Definiție (semantică)
Stereotip (stereotip)	« »	O desemnare care specifică semantica elementului de notație (de exemplu: o dependență cu stereotipul „include” este considerată o relație de includere, iar o clasă cu stereotipul „limită” este o clasă limită)
starea de gardă (condiția de gardă)		Condiție booleană (de exemplu: sau [identificare efectuată])
Prescripţie (constrângere)	{ }	O regulă care restricționează semantica unui element de model (de exemplu, (timp de execuție mai mic de 10 ms))
Valoare marcată (valoare etichetată)	{ }	O proprietate nouă sau de calificare a elementului de notație (de exemplu: (versiunea = 3.2))

În plus față de stereotipurile specificate ca șir de text între ghilimele, stereotipurile grafice pot fi folosite în diagrame. Figura următoare prezintă exemple de mapare standard și stereotip.

a) denumire standard		b) denumire standard cu stereotip de text		c) stereotip grafic

Orez. 11.2. Exemple de cartografiere standard și stereotipă a clasei

Diagramă este o grupare de elemente de notație pentru a afișa unele aspecte ale sistemului informațional în curs de dezvoltare. Diagramele sunt de obicei un graf conectat în care entitățile sunt vârfuri și relațiile sunt arce. Următorul tabel oferă o scurtă descriere a diagramelor UML.

Tabelul 11.5. Diagrame

Diagramă			Scop
				după gradul de implementare fizică	prin afișarea dinamicii	după aspectul afișat
(utilizare caz)			Afișează funcțiile sistemului, interacțiunea dintre actori și funcții	logic	static	funcţional
(clasă)			Afișează un set de clase, interfețe și relații dintre ele	boolean sau fizic	static	Informații funcționale
(pachet)			Afișează un set de pachete și relațiile acestora	boolean sau fizic	static	Componentă
comportament (comportament)	(mașină de stat)		Afișează stările entităților și tranzițiile dintre ele în timpul ciclului său de viață	logic	Dinamic	comportamental
	(activitate)		Afișează procesele de afaceri din sistem (descrierea algoritmilor de comportament)
	Interacțiuni (interacţiune)	(secvenţă)	Afișează secvența mesajului care trece între obiecte și actori
		(comunicare)	Similar cu o diagramă de secvență, dar accentul principal este pe structura interacțiunii dintre obiecte
Implementări (implementare)	(componenta)		Afișează componentele sistemului (programe, biblioteci, tabele etc.) și legăturile dintre ele	Fizic	static	Componentă
	(implementare)		Afișează amplasarea componentelor în funcție de nodurile rețelei, precum și configurația acesteia

Standardul UML 2.x definește și diagrame suplimentare, foarte specializate:

Diagrama obiectului (diagrama obiectului) - asemănătoare, dar obiectele sunt afișate în loc de clase;

Diagrama temporală - descrie starea obiectului în timp;

Diagrama structurii compozite (diagrama structurii compozite) - descrie porturile (inclusiv interfețele) clasei pentru interacțiunea cu alte clase;

Diagrama de profil (diagrama de profil) - asemănătoare cu descrierea claselor incluse în acestea;

Diagrama de prezentare a interacțiunii - similară, dar cu fragmente de interacțiune ascunse (fragmente cu o etichetă de ref). Este unul contextual (conceptual), ale cărui elemente vor fi specificate pe diagrame de descompunere separate.

Pentru a lărgi reprezentarea conceptuală a arhitecturii interne a sistemului, cea mai mare parte a construcției permite utilizarea unor stereotipuri grafice bine stabilite pentru așa-numitele. O astfel de diagramă se numește 1, dar nu aparține listei de diagrame definite de standardul UML.

Când se dezvoltă un model de sistem separat, sunt construite mai multe tipuri de diagrame. Mai mult, atunci când se dezvoltă un model al unui sistem complex, de regulă, se construiesc mai multe diagrame de același tip. În același timp, nu trebuie să creați vederi grafice separate dacă nu este necesar. De exemplu, diagramele și sunt interschimbabile; sunt construite numai pentru obiecte cu comportament complex. Următorul tabel oferă recomandări cu privire la necesitatea de a dezvolta (rafina) diagrame pentru modelele de sistem.

Tabelul 11.6. Legătura de modele și diagrame

Tabelul de mai sus nu arată modelul de testare, deoarece în cadrul construcției sale, diagramele nu sunt dezvoltate, ci sunt verificate (testate) pentru completitudine și coerență.

O parte din diagrame după construirea lor necesită dezvoltare și perfecționare ca parte a dezvoltării următorului model (proces tehnologic). Deci, de exemplu, ar trebui clarificat în timpul dezvoltării. în modele.

4. Definiți termenul „”.

Cred că toată lumea a auzit în copilărie o vorbă precum „ De șapte ori măsurați tăiați o dată„. În programare, este la fel. Întotdeauna este mai bine să te gândești la implementare înainte de a petrece timp executând-o. Adesea trebuie să creezi clase în timpul implementării, să vii cu interacțiunea lor. Și de multe ori o reprezentare vizuală a acestui lucru poate ajuta la rezolvare. problema în modul cel mai corect. Aici ajutăm UML.

Ce este UML?

Dacă te uiți la imaginile din motoarele de căutare, devine clar că UML- este ceva despre scheme, săgeți și pătrate. Ceea ce este important este că UML se traduce ca Limbajul de modelare unificat. Cuvântul Unificat este important aici. Adică pozele noastre vor fi înțelese nu numai de noi, ci și de alții care cunosc UML. Se pare că aceasta este o limbă atât de internațională pentru desenarea diagramelor.

Cum spune Wikipedia

UML este un limbaj de descriere grafică pentru modelarea obiectelor în domeniile dezvoltării software, modelării proceselor de afaceri, ingineriei sistemelor și cartografierii structurilor organizaționale.

Cel mai interesant lucru la care nu toată lumea se gândește sau la care ghicește este că UML are specificații. Mai mult, există chiar și o specificație UML2. Mai multe informații despre specificație pot fi găsite pe site-ul Object Management Group. De fapt, acest grup este implicat în dezvoltarea specificațiilor UML. De asemenea, este interesant că UML nu se limitează la descrierea structurii claselor. Există multe tipuri de diagrame UML. O scurtă descriere a tipurilor de diagrame UML poate fi văzută în aceeași Wikipedia: Diagrame UML sau în videoclipul lui Timur Batyrshinov Prezentare generală a diagramelor UML. UML este, de asemenea, utilizat pe scară largă în descrierea diferitelor procese, de exemplu aici: Single sign-on folosind JWT. Revenind la utilizarea diagramelor de clasă UML, merită remarcată cartea Head First: Design Patterns, în care modelele sunt ilustrate de aceleași diagrame UML. Se pare că UML este într-adevăr folosit. Și se dovedește că cunoașterea și înțelegerea aplicației sale este o abilitate destul de utilă.

Aplicație

Să vedem cum poți lucra cu acest UML din IDE. Ca IDE, luați IntelliJ Idea. Dacă se utilizează IntelliJ Idea Ultimate, atunci vom avea pluginul instalat „din cutie” Suport UML„. Vă permite să generați automat diagrame de clasă frumoase. De exemplu, prin Ctrl + N sau elementul de meniu „Navigați” -> „Clasă” mergeți la clasă ArrayList. Acum, prin meniul contextual lângă numele clasei, selectați „Diagramă” -> „Afișați pop-up diagramă”. Drept urmare, obținem o diagramă frumoasă:

Dar dacă vrei să te desenezi și chiar dacă nu există o versiune Ultimate a Ideei? Dacă folosim IntelliJ Idea Community Edition, atunci nu avem altă opțiune. Pentru a face acest lucru, trebuie să înțelegeți cum funcționează o astfel de schemă UML. Mai întâi trebuie să instalăm Graphviz. Este un set de utilități de vizualizare grafică. Este folosit de pluginul pe care îl vom folosi. După instalare, trebuie să adăugați un director cos din directorul instalat graphviz la o variabilă de mediu CALE. După aceea, în IntelliJ Idea, selectați Fișier -> Setări din meniu. În fereastra „Setări”, selectați categoria „Plugin-uri”, faceți clic pe butonul „Răsfoiți depozitele” și instalați pluginul de integrare PlantUML. De ce este acesta atât de bun PlantUML? Folosește un limbaj de descriere a graficului numit „ punct" și acest lucru îi permite să fie mai universal, deoarece acest limbaj este folosit nu numai de PlantUML. Mai mult, tot ceea ce vom face mai jos se poate face nu numai în IDE, ci și în serviciul online planttext.com. După instalarea Plugin PlantUML, vom putea crea diagrame UML prin "File" -> "New". Să creăm o diagramă de tip "UML class". În acest timp, se generează automat un șablon cu un exemplu. Să ștergem conținutul acestuia și creăm pe al nostru, înarmați cu un articol din Habr: Relații de clasă - de la UML la cod... Și pentru a înțelege cum să descriem acest lucru în text, să luăm manualul PlantUML: plantuml class-diagram... În el, la încă de la început, există un semn cu modul de a descrie relațiile:

Despre conexiunile în sine, mai putem arunca o privire aici: „Relații între clase în UML. Exemple”. Pe baza acestor materiale, să începem să creăm diagrama noastră UML. Adăugați următorul conținut care descrie cele două clase: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Pentru a vedea rezultatul în Idea, selectați „Vizualizare” -> „Tool Windows” -> „PlantUML”. Vom obține doar două pătrate care denotă clase. După cum știm, ambele clase implementează interfața List. Această relație de clase se numește - implementare (realizare). O săgeată cu o linie punctată este folosită pentru a descrie o astfel de relație. Să-l desenăm: Listă Listă interfață< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о pachet privat element array: ~ Object elementData Acum vrem să arătăm că ArrayList conține câteva obiecte. În acest caz, tipul de conexiune va fi - agregare(agregare). Agregatul în acest caz este ArrayList , deoarece contine si alte obiecte. Alegem agregarea deoarece obiectele din listă pot trăi fără listă: nu sunt părți integrante ale acesteia. Viața lor nu este legată de durata de viață a listei. Unitatea din latină se traduce prin „colectat”, adică ceva alcătuit din ceva. De exemplu, în viață, există o unitate de pompare, care constă dintr-o pompă și un motor. Unitatea în sine poate fi dezasamblată, lăsând unele dintre componentele sale. De exemplu, pentru a vinde sau a pune în altă unitate. Deci este pe listă. Și acest lucru este exprimat sub forma unui romb gol la unitate și a unei linii continue. Să o punem astfel: clasa Object ( ) ArrayList o- Object Acum dorim să arătăm că, spre deosebire de ArrayList , clasa LinkedList conține containere Node care se referă la datele stocate. În acest caz, nodurile fac parte din LinkedList în sine și nu pot trăi separat. Node nu este conținut stocat direct, ci conține doar o referință la acesta. De exemplu, când adăugăm un rând la LinkedList, adăugăm un nou Node , care conține un link către acest rând, precum și un link către Node anterior și următor. Acest tip de conexiune se numește compoziţie(compoziţie). Pentru a afișa un compozit (unul care constă din părți), este desenat un robic umplut, o linie continuă duce la acesta. Acum să scriem asta ca afișare text a link-ului: class Node ( ) LinkedList * -- Node Și acum trebuie să învățăm cum să afișam un alt tip important de link - dependenta(relație de dependență). Este folosit atunci când o clasă folosește alta, în timp ce clasa nu conține clasa utilizată și nu este succesorul acesteia. De exemplu, LinkedList și ArrayList pot crea un ListIterator . Să afișăm asta ca săgeți punctate: clasa ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Puteți detalia atât cât aveți nevoie. Toate denumirile sunt enumerate aici: "PlantUML - Diagrama de clasă". În plus, nu există nimic supranatural în desenarea unei astfel de scheme și, atunci când lucrați la sarcinile dvs., o puteți desena rapid cu mâna. Acest lucru vă va dezvolta abilitățile de gândire privind arhitectura aplicației și vă va ajuta să identificați defectele structurii clasei de la început, nu după ce ați petrecut deja o zi implementând modelul greșit. Cred că acesta este un motiv bun să încerci?)

Automatizare

Există diferite moduri de a genera automat diagrame PlantUML. De exemplu, în idei Există un plugin SketchIT, dar nu le desenează corect. De exemplu, implementarea interfețelor este desenată incorect (afișată ca moștenire). Există, de asemenea, exemple online despre cum să includeți acest lucru în ciclul de viață al proiectului dumneavoastră. Să zicem pentru Maven există un exemplu folosind uml-java-docklet . Pentru a arăta cum se face acest lucru, să folosim Arhetipul Maven pentru a crea rapid un proiect Maven. Să executăm comanda: mvn archetype:generate La problema alegerii unui filtru ( Alegeți un număr sau aplicați filtrul) părăsiți implicit prin simpla apăsare a Enter. Va fi mereu" maven-arhetip-pornire rapidă". Selectăm cea mai recentă versiune. Apoi, răspundeți la întrebări și finalizați crearea proiectului:

Deoarece Maven nu este în centrul acestui articol, răspunsurile la întrebările dvs. despre Maven pot fi găsite în Centrul de utilizatori Maven . În proiectul generat, deschideți fișierul de descriere a proiectului pentru editare, pom.xml. Vom copia conținutul din descrierea instalării uml-java-docklet în el. Artefactul folosit în descriere nu a putut fi găsit în depozitul Maven Central. Dar a funcționat pentru mine cu asta: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . Adică în acea descriere trebuie doar să înlocuiți groupId din " info.leadinglight" pe " com.chfourie"și pune versiunea" 1.0.0 ". După aceea, putem executa în directorul în care se află fișierul pom.xml aceste comenzi sunt: ​​mvn clean install și mvn javadoc:javadoc . Acum, dacă deschidem documentația generată (explorer target\site\apidocs\index.html), vom vedea diagrame UML. Apropo, implementarea este deja afișată corect aici)

Concluzie

După cum puteți vedea, UML vă permite să vizualizați structura aplicației dvs. De asemenea, UML nu se limitează doar la asta. Cu ajutorul UML, puteți descrie diverse procese din cadrul companiei dvs. sau puteți descrie procesul de afaceri în care funcționează funcția pe care o scrieți. Cât de mult este util UML pentru dvs. personal depinde de dvs., dar găsirea timpului și cunoașterea lui mai în detaliu va fi oricum utilă. #Viacheslav Versiunea rusă a acestei postări: diagrama UML Java pe CodeGym

UML este un acronim pentru Unified Modeling Language. De fapt, este una dintre cele mai populare tehnici de modelare a proceselor de afaceri și este o notație standard internațională pentru specificarea, vizualizarea și documentarea dezvoltării software. Definit de grupul de gestionare a obiectelor, a apărut ca urmare a mai multor sisteme de notație UML suplimentare și a devenit acum standardul de facto pentru modelarea vizuală. Principiul de bază al oricărei programari orientate pe obiecte începe cu construirea modelului.

UML a fost creat din haosul din jurul dezvoltării și documentării software. În anii 1990, existau mai multe moduri diferite de a reprezenta sistemele software. Era nevoie de un mod vizual UML mai unificat de a reprezenta aceste sisteme și, ca rezultat, a fost dezvoltat între 1994 și 1996 de către trei ingineri software care lucrează la Rational Software. Ulterior a fost adoptat ca standard în 1997 și a rămas așa până în prezent cu doar câteva actualizări.

Practic, UML este un limbaj de modelare de uz general în domeniul dezvoltării software. Cu toate acestea, acum și-a găsit drumul în documentarea mai multor procese de afaceri sau fluxuri de lucru, cum ar fi diagramele de activitate. Tipul de diagramă UML poate fi utilizat ca înlocuitor pentru diagramele de flux. Acestea oferă atât o modalitate mai standardizată de modelare a fluxurilor de lucru, cât și o gamă largă de funcții pentru a îmbunătăți lizibilitatea și eficiența.

Arhitectura se bazează pe un meta-obiect, care definește baza pentru crearea limbajului UML. Este suficient de precis pentru a crea o întreagă aplicație. Un UML complet executabil poate fi implementat pe mai multe platforme folosind diferite tehnologii cu toate procesele de-a lungul întregului ciclu de dezvoltare a software-ului.

UML este conceput pentru ca utilizatorii să dezvolte un limbaj de modelare vizuală. Acceptă concepte de dezvoltare la nivel înalt, cum ar fi structuri, modele și colaborări. UML este o colecție de elemente precum:

1. Instrucțiuni de limbaj de programare.
2. Actorii descriu rolul jucat de utilizator sau de orice alt sistem care interacționează cu obiectul.
3. Activități care urmează să fie efectuate pentru executarea contractului de muncă și să fie prezentate în diagrame.
4. Un proces de afaceri care include un set de sarcini care creează un serviciu specific pentru clienți, vizualizate printr-o diagramă de acțiuni secvențiale.
5. Componente logice și software reutilizabile.

Diagramele UML se împart în două categorii. Primul tip include șapte tipuri de diagrame reprezentând informații structurale, al doilea - restul de șapte reprezentând tipuri generale de comportament. Aceste diagrame sunt folosite pentru a documenta arhitectura sistemelor și sunt direct implicate în modelarea UML a sistemului.

Diagramele UML sunt prezentate ca reprezentări statice și dinamice ale modelului de sistem. Vederea statică include diagrame de clasă și structuri compozite care subliniază structura statică. Vederea dinamică reprezintă interacțiunea dintre obiecte și modificările stărilor interne ale obiectelor folosind diagrame de secvență, activitate și stare.

O mare varietate de instrumente de modelare UML sunt disponibile pentru a simplifica modelarea, inclusiv IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner și Dia.

Utilizarea UML are diferite forme atât în ​​documentația de dezvoltare software, cât și în procesele de afaceri:

1. Schiță. În acest caz, diagramele UML sunt folosite pentru a transmite diverse aspecte și caracteristici ale unui sistem. Cu toate acestea, aceasta este doar o vedere de nivel superior a sistemului și cel mai probabil nu va include toate detaliile necesare pentru a duce proiectul până la capăt.
2. Proiectare înainte - Proiectarea schiței este realizată înainte ca aplicația să fie codificată. Acest lucru se face pentru o imagine de ansamblu mai bună a sistemului sau a fluxului de lucru pe care utilizatorul încearcă să îl creeze. Pot fi identificate multe probleme sau deficiențe de proiectare, ceea ce va îmbunătăți starea generală de sănătate și bunăstare a proiectului.
3. Design invers. Odată ce codul este scris, diagramele UML apar ca o formă de documentație pentru diferite activități, roluri, colaboratori și fluxuri de lucru.
4. Plan. În acest caz, diagrama servește ca un construct complet care necesită doar implementarea efectivă a sistemului sau a software-ului. Acest lucru se face adesea folosind instrumente CASE (Computer Aided Software Engineering Tools). Principalul dezavantaj al utilizării instrumentelor CASE este că necesită un anumit nivel de cunoștințe, instruire a utilizatorilor și management și personal.

UML nu este un limbaj de programare autonom precum Java, C++ sau Python, cu toate acestea, cu instrumentele potrivite, se poate transforma într-un limbaj de pseudo-programare UML. Pentru a atinge acest obiectiv, întregul sistem trebuie să fie documentat în diagrame diferite, iar folosind software-ul potrivit, diagramele pot fi traduse direct în cod. Această metodă poate fi utilă numai dacă timpul petrecut pentru desenarea diagramelor durează mai puțin decât scrierea codului real. Chiar dacă UML a fost creat pentru modelarea sistemului, a găsit mai multe utilizări în domeniile de afaceri.

Următorul este un exemplu de diagramă UML pentru modelarea afacerii.

O soluție practică ar fi reprezentarea vizuală a fluxului procesului pentru televânzări printr-o diagramă de activitate. Din momentul în care comanda este luată ca intrare, până în momentul în care comanda este finalizată și se dă o ieșire specifică.

Există mai multe tipuri de diagrame UML, iar fiecare dintre ele îndeplinește o sarcină diferită, fie că este dezvoltată înainte de implementare sau după, ca parte a documentației. Cele mai largi două categorii care acoperă toate celelalte tipuri sunt diagrama de comportament și diagrama structurii. După cum sugerează și numele, unele diagrame UML încearcă să analizeze și să descrie structura unui sistem sau proces, în timp ce altele descriu comportamentul sistemului, al participanților și al componentelor acestuia.

Diferitele tipuri sunt împărțite după cum urmează:

1. Nu toate cele 14 tipuri diferite de diagrame UML sunt utilizate în mod regulat atunci când se documentează sisteme și arhitecturi.
2. Principiul Pareto se aplică și utilizării diagramelor UML.
3. 20% dintre diagrame sunt folosite de dezvoltatori în 80% din timp.

Cele mai frecvent utilizate elemente în dezvoltarea de software sunt:

• diagrame de utilizare;
• diagrame de clasă;
• secvente.

Diagrame de activitate - Cele mai importante diagrame UML pentru crearea modelelor de procese de afaceri. În dezvoltarea de software, ele sunt folosite pentru a descrie fluxul diferitelor activități. Ele pot fi fie în serie, fie în paralel. Ele descriu obiectele folosite, consumate sau produse de o activitate și relația dintre diferitele activități.

Toate cele de mai sus sunt esențiale pentru modelarea proceselor de afaceri care duc de la unul la altul, deoarece sunt interconectate cu un început și un sfârșit clar. Într-un mediu de afaceri, aceasta este denumită și maparea proceselor de afaceri. Actorii principali sunt autorul, editorul și editorul. Un exemplu de UML este următorul. Când un evaluator analizează un proiect și decide că trebuie făcute unele modificări. Autorul revizuiește apoi proiectul și îl returnează din nou pentru a analiza recenzia.

Diagrama de utilizare

Piatra de temelie a sistemului - folosită pentru a analiza cerințele pentru nivelul de sistem. Aceste cerințe sunt exprimate în diferite cazuri de utilizare. Cele trei componente principale ale unei diagrame UML sunt:

1. Funcțional - prezentat ca cazuri de utilizare.
2. Un verb care descrie o acțiune.
3. Actori - pentru a interacționa cu sistemul. Actorii pot fi utilizatori, organizații sau o revendicare externă. Relațiile dintre participanți sunt reprezentate prin săgeți drepte.

De exemplu, pentru diagrama de gestionare a stocurilor. În acest caz, există un proprietar, un furnizor, un manager, un specialist în inventar și un inspector de inventar. Containerele rotunde reprezintă acțiunile pe care le realizează actorii. Acțiuni posibile: cumpărați și plătiți acțiuni, verificați calitatea stocurilor, returnați stocuri sau distribuiți stocuri.

Acest tip de diagramă este foarte potrivit pentru a arăta comportamentul dinamic între participanții într-un sistem, făcându-l mai ușor de reprezentat fără a afișa detalii de implementare.

Temporar

Diagramele de timp UML sunt folosite pentru a reprezenta relațiile obiectelor atunci când focalizarea depinde de timp. În acest caz, nu este interesant modul în care obiectele interacționează sau se schimbă între ele, dar utilizatorul dorește să-și imagineze modul în care obiectele și subiectele acționează de-a lungul unei axe liniare a timpului.

Fiecare participant individual este reprezentat printr-o linie de salvare, care este în esență o linie care formează etapele pe măsură ce un participant individual trece de la o etapă la alta. Atenția principală este acordată duratei timpului evenimentelor și modificărilor care apar în funcție de acesta.

Componentele principale ale unei diagrame de timp sunt:

1. Lifeline este un membru individual.
2. Cronologie de stat - singura cale de viață poate trece prin diferite stări în cadrul unui proces.
3. Duration constraint - o constrângere de interval de timp care reprezintă durata constrângerii necesare pentru îndeplinire.
4. Limită de timp - Limitarea intervalului de timp în care ceva trebuie să fie efectuat de un membru.
5. Apariția distrugerii - Apariția unui mesaj care distruge un membru individual și descrie sfârșitul ciclului de viață al acelui membru.

Diagramele orizontale, numite și diagrame de stări, sunt folosite pentru a descrie diferitele stări ale unei componente dintr-un sistem. Ia formatul final al numelui, deoarece diagrama este în esență o mașină care descrie stările multiple ale unui obiect și modul în care acesta se schimbă pe baza evenimentelor interne și externe.

O diagramă de stare a mașinii foarte simplă ar fi într-un joc de șah. Un joc de șah obișnuit constă în mișcări făcute de alb și mișcări făcute de negru. Albul are prima mutare, inițiind astfel jocul. Sfârșitul jocului poate avea loc indiferent dacă Albul sau Negrul câștigă. Jocul se poate încheia într-un meci, demisie sau egalitate (diferite stări ale mașinii). Diagramele de stat sunt utilizate în principal în proiectarea UML directă și inversă a diferitelor sisteme.

Secvenţial

Acest tip de diagramă este cea mai importantă diagramă UML nu numai în rândul comunității informatice, ci și ca model la nivel de proiectare pentru dezvoltarea aplicațiilor de afaceri. Ele sunt populare în descrierea proceselor de afaceri datorită naturii lor vizuale auto-explicative. După cum sugerează și numele, diagramele descriu succesiunea de mesaje și interacțiuni care au loc între subiecți și obiecte. Actorii sau obiectele pot fi active numai atunci când este necesar sau când un alt obiect dorește să comunice cu ei. Toate comunicările sunt prezentate în ordine cronologică.

Pentru mai multe informații, consultați exemplul de diagramă de secvență UML de mai jos.

După cum rezultă din exemplu, diagramele structurale sunt folosite pentru a arăta structura unui sistem. Mai precis, limbajul este folosit în dezvoltarea de software pentru a reprezenta arhitectura unui sistem și modul în care diferitele componente sunt legate.

Diagrama de clasă UML este cel mai comun tip de diagramă pentru documentația software. Deoarece majoritatea software-ului care este scris în prezent se bazează încă pe paradigma de programare orientată pe obiecte, utilizarea diagramelor de clasă pentru a documenta software-ul este de bun simț. Acest lucru se datorează faptului că OOP se bazează pe clase UML și pe relațiile dintre ele. Pe scurt, diagramele conțin clase, împreună cu atributele lor, numite și câmpuri de date, și comportamentele lor, numite funcții membre.

Mai precis, fiecare clasă are 3 câmpuri: nume în partea de sus, atribute chiar sub nume, operații/comportament în partea de jos. Relația dintre diferitele clase (reprezentată printr-o linie de legătură) formează o diagramă de clasă. Exemplul de mai sus arată o diagramă de clasă de bază.

Obiecte

Când discutați despre diagramele de structură UML, trebuie să vă aprofundați în concepte legate de informatică. În ingineria software, clasele sunt considerate tipuri de date abstracte, în timp ce obiectele sunt instanțe. De exemplu, dacă există „Mașină” care este un tip abstract generic, atunci instanța clasei „Mașină” ar fi „Audi”.

Diagramele de obiecte UML ajută dezvoltatorii de software să verifice dacă structura abstractă generată este o structură viabilă atunci când este implementată în practică, adică atunci când sunt create obiectele. Unii dezvoltatori consideră că acesta este un nivel secundar de verificare a preciziei. Afișează instanțe de clasă. Mai precis, clasa generică „Client” are acum un client real, de exemplu numit „James”. James este o instanță a unei clase mai generale și are aceleași atribute, totuși, cu valori date. La fel s-a procedat și cu contul de Conturi și Economii. Ambele sunt obiecte ale claselor lor respective.

Implementări

Diagramele de implementare sunt folosite pentru a vizualiza relația dintre software și hardware. Pentru a fi mai specific, cu diagramele de implementare este posibil să se construiască un model fizic al modului în care componentele software (artefactele) sunt implementate în componentele hardware cunoscute sub numele de noduri.

O schemă de implementare simplificată tipică pentru o aplicație web ar include:

1. Noduri (server de aplicații și server de baze de date).
2. Diagrama artefactelor aplicației client și bazei de date.

Diagrama pachetului este similară cu macrocomenzile pentru diagramele UML de implementare pe care le-am explicat mai sus. Diverse pachete conțin noduri și artefacte. Ei grupează diagramele și componentele modelului în grupuri, la fel ca un spațiu de nume încapsulează diferite nume care sunt oarecum legate. În cele din urmă, pachetul poate fi creat și de mai multe alte pachete pentru a reprezenta sisteme și comportamente mai complexe.

Scopul principal al unei diagrame de pachet este de a arăta relațiile dintre diferitele componente mari care alcătuiesc un sistem complex. Programatorii consideră că această abstractizare este un avantaj bun pentru utilizarea diagramelor de pachete, mai ales atunci când unele detalii pot fi lăsate în afara imaginii.

Ca orice alt lucru în viață, pentru a face ceva corect, ai nevoie de instrumentele potrivite. Pentru a documenta software-ul, procesele sau sistemele, utilizați instrumente care oferă adnotări UML și șabloane de diagramă. Există diverse instrumente de documentare software care pot ajuta la desenarea diagramei.

Ele se încadrează în general în următoarele categorii principale:

1. Hârtia și stiloul sunt ușor. Luați hârtie și stilou, deschideți codul de sintaxă UML de pe web și desenați orice tip de diagramă doriți.
2. Instrumente online - Există mai multe aplicații online care pot fi folosite pentru a crea o diagramă. Cele mai multe dintre ele oferă un abonament plătit sau un număr limitat de diagrame în nivelul gratuit.
3. Instrumentele online gratuite sunt aproape la fel cu cele plătite. Principala diferență este că cele plătite oferă și tutoriale și șabloane gata făcute pentru diagrame specifice.
4. Aplicație desktop - Aplicația desktop tipică de utilizat pentru diagrame și aproape orice altă diagramă este Microsoft Visio. Oferă caracteristici și funcționalități avansate. Singurul dezavantaj este că trebuie să plătești pentru asta.

Astfel, este clar că UML este un aspect important asociat cu dezvoltarea software-ului orientat pe obiecte. Folosește notația grafică pentru a crea modele vizuale ale programelor de sistem.

Adnotare: Subiectul acestui curs este UML - Unified Modeling Language. În prelegerea anterioară, am vorbit despre ce este UML, despre istoria sa, scopul, modalitățile de utilizare a limbajului, structura definiției sale, terminologia și notația sa. Sa observat că un model UML este un set de diagrame. În această prelegere, vom lua în considerare astfel de întrebări: de ce avem nevoie de mai multe tipuri de diagrame; tipuri de diagrame; OOP și diagrama secvență

Înainte de a trece la discuția despre materialul principal al acestei prelegeri, să vorbim despre motivul pentru care se construiesc diagrame. Dezvoltarea unui model al oricărui sistem (nu doar software) precede întotdeauna crearea sau actualizarea acestuia. Acest lucru este necesar cel puțin pentru a ne imagina mai clar problema rezolvată. Modelele gândite sunt foarte importante atât pentru interacțiunea în cadrul echipei de dezvoltare, cât și pentru înțelegerea reciprocă cu clientul. La urma urmei, vă permite să vă asigurați că proiectul este „consecvent din punct de vedere arhitectural” înainte de a fi implementat în cod.

Construim modele de sisteme complexe pentru că nu le putem descrie complet, „aruncă o privire la ele dintr-o privire”. Prin urmare, evidențiem numai proprietățile sistemului care sunt esențiale pentru o anumită sarcină și construim modelul său care reflectă aceste proprietăți. Metoda analizei orientate pe obiecte face posibila descrierea sistemelor complexe reale in cel mai adecvat mod. Dar, pe măsură ce sistemele devin mai complexe, este nevoie de o tehnologie bună de simulare. După cum am spus în prelegerea anterioară, un sistem unificat este folosit ca atare tehnologie „standard”. limbaj de modelare(Unified Modeling Language, UML), care este un limbaj grafic pentru specificarea, vizualizarea, proiectarea și documentarea sistemelor. Folosind UML, puteți dezvolta un model detaliat al sistemului care este creat, reflectând nu numai conceptul său, ci și caracteristicile specifice de implementare. În cadrul modelului UML, toate reprezentările despre sistem sunt fixate sub forma unor construcții grafice speciale numite diagrame.

Notă. Nu vom lua în considerare toate, ci doar câteva dintre tipurile de diagrame. De exemplu, diagrama componentelor nu este tratată în această prelegere, care este doar o scurtă prezentare generală a tipurilor de diagrame. Numărul de tipuri de diagrame pentru un anumit model de aplicație nu este limitat în niciun fel. Pentru aplicații simple, nu este nevoie să construiți diagrame de toate tipurile fără excepție. Unele dintre ele pot lipsi pur și simplu, iar acest fapt nu va fi considerat o eroare. Este important să înțelegeți că disponibilitatea diagramelor de un anumit tip depinde de specificul unui anumit proiect. Informații despre alte tipuri de diagrame (nu sunt discutate aici) pot fi găsite în standardul UML.

De ce aveți nevoie de mai multe tipuri de diagrame

Mai întâi, să definim terminologia. În prefața acestei prelegeri, am folosit în mod repetat conceptele de sistem, model și diagramă. Autorul este sigur că fiecare dintre noi înțelege în mod intuitiv sensul acestor concepte, dar, pentru a fi complet clar, să ne uităm din nou la glosar și să citim următoarele:

Sistem- un set de subsisteme controlate interconectate unite printr-un scop comun de funcționare.

Da, nu prea informativ. Ce este atunci un subsistem? Pentru a clarifica situația, să ne întoarcem la clasici:

sistem numiți un set de subsisteme organizate pentru a atinge un scop specific și descrise folosind un set de modele, eventual din puncte de vedere diferite.

Ei bine, nu poți face nimic, trebuie să cauți definiția unui subsistem. Se mai spune acolo că subsistem este un set de elemente, dintre care unele specifică comportamentul altor elemente. Ian Sommerville explică conceptul astfel:

Subsistemul este un sistem a cărui funcționare nu depinde de serviciile altor subsisteme. Sistemul software este structurat ca un set de subsisteme relativ independente. Sunt definite și interacțiunile dintre subsisteme.

De asemenea, nu foarte clar, dar mai bine. Vorbind în limbajul „uman”, sistemul este reprezentat ca un set de entități mai simple care sunt relativ autosuficiente. Acest lucru poate fi comparat cu modul în care, în procesul de dezvoltare a unui program, construim o interfață grafică din „cuburi” standard - componente vizuale, sau cu modul în care textul programului în sine este, de asemenea, împărțit în module care conțin subrutine care sunt combinate în funcție de un funcțional. caracteristică și pot fi reutilizate în următoarele programe.

Înțelegeți conceptul de sistem. În timpul procesului de proiectare, sistemul este luat în considerare din puncte de vedere diferite cu ajutorul unor modele ale căror diferite reprezentări apar sub formă de diagrame. Din nou, cititorul poate avea întrebări despre semnificația conceptelor modeleȘi diagrame. Credem o definiție frumoasă, dar nu foarte clară modele ca o abstractizare a unui sistem închis semantic este puțin probabil să clarifice situația, așa că hai să încercăm să explicăm „în propriile noastre cuvinte”.

Model- acesta este un anumit obiect (material sau nu) care afișează doar cele mai semnificative caracteristici ale sistemului pentru această sarcină. Modelele sunt diferite - tangibile și intangibile, artificiale și naturale, decorative și matematice...

Să dăm câteva exemple. Mașinile de jucărie din plastic cunoscute tuturor, pe care le-am jucat cu atâta pasiune în copilărie, nu sunt altceva decât material decorativ artificial model de masina reala. Desigur, într-o astfel de „mașină” nu există motor, nu îi umplem rezervorul cu benzină, cutia de viteze nu funcționează în ea (mai mult, lipsește deloc), dar ca model, această jucărie își îndeplinește pe deplin. funcții: îi oferă copilului o idee despre mașină, deoarece își afișează trăsăturile caracteristice sunt prezența a patru roți, o caroserie, uși, geamuri, capacitatea de a conduce etc.

În cercetarea medicală, testarea pe animale precede adesea testele clinice de medicamente la oameni. În acest caz, animalul acționează ca material natural modele umane.

Ecuația prezentată mai sus este, de asemenea, un model, dar acesta este un model matematic și descrie mișcarea unui punct material sub acțiunea gravitației.

Rămâne doar să spunem ce este o diagramă. Diagramă este o reprezentare grafică a unui set de elemente. De obicei, descris ca un grafic cu vârfuri (entități) și muchii (relații). Există multe exemple de diagrame. Aceasta este o diagramă bloc familiară nouă tuturor din anii de școală și diagrame de instalare pentru diferite echipamente pe care le putem vedea în manualele de utilizare și un arbore de fișiere și directoare pe un disc, pe care le putem vedea rulând comanda arbore din Consolă Windows și multe, multe altele. În viața de zi cu zi, diagramele ne înconjoară din toate părțile, pentru că o imagine este mai ușor de perceput pentru noi decât un text...

Dar să revenim la design software (și nu numai). În această industrie de când folosind diagrame, puteți vizualiza sistemul din diferite puncte de vedere. Una dintre diagrame, de exemplu, poate descrie interacțiunea utilizatorului cu sistemul, cealaltă - schimbarea stărilor sistemului în timpul funcționării acestuia, a treia - interacțiunea dintre elementele sistemului etc. Un complex sistemul poate și ar trebui să fie reprezentat ca un set de modele mici și aproape independente - diagrame, și niciuna dintre ele nu este suficientă pentru a descrie sistemul și a obține o imagine completă a acestuia, deoarece fiecare dintre ele se concentrează pe un anumit aspect al funcționării sistemului. sistem și exprimă un diferit nivelul de abstractizare. Cu alte cuvinte, fiecare model corespunde unui anumit punct de vedere specific asupra sistemului proiectat.

În ciuda faptului că în paragraful anterior am fost foarte liberi cu conceptul de model, trebuie înțeles că în contextul definițiilor de mai sus nicio diagramă nu este un model. Diagramele sunt doar un mijloc de vizualizare a modelului, iar cele două ar trebui să fie distinse. Numai un set de diagrame constituie un model de sistemși o descrie cel mai pe deplin, dar nu o diagramă scoasă din context.

Tipuri de diagrame

UML 1.5 definit douăsprezece tipuri de diagrameîmpărțit în trei grupe:

• patru tipuri de diagrame reprezintă structura statică a aplicației;
• cinci reprezintă aspectele comportamentale ale sistemului;
• trei reprezintă aspectele fizice ale funcționării sistemului (diagrame de implementare).

Versiunea actuală a UML 2.1 nu a făcut prea multe modificări. Diagramele s-au modificat ușor în aspect (au apărut cadre și alte îmbunătățiri vizuale), notația s-a îmbunătățit ușor, unele diagrame au primit denumiri noi.

Cu toate acestea, numărul exact diagrame canonice este absolut neimportant pentru noi, deoarece nu le vom lua în considerare pe toate, ci doar pe unele - pentru că numărul de tipuri de diagrame pentru un anumit model al unei anumite aplicații nu este strict fix. Pentru aplicații simple, nu este nevoie să construiți toate diagramele fără excepție. De exemplu, pentru o aplicație locală, nu este necesar să construiți o diagramă de implementare. Este important să înțelegeți că lista de diagrame depinde de specificul proiectului în curs de dezvoltare și este determinată de însuși dezvoltatorul. Dacă cititorul curios mai vrea să afle despre toate diagramele UML, îl vom trimite la standardul UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Amintiți-vă că scopul acestui curs nu este de a descrie absolut toate posibilitățile UML, ci doar de a introduce acest limbaj, de a oferi o idee inițială despre această tehnologie.

Deci, ne vom uita pe scurt la astfel de tipuri de diagrame precum:

• diagrama cazului de utilizare;
• diagrama de clase;
• diagrama obiectului;
• Diagrama secvenței;
• diagrama de interacțiune;
• diagrama de stare;
• diagrama de activitate;
• diagrama de implementare.

Despre unele dintre aceste diagrame vom vorbi mai detaliat în prelegerile următoare. Deocamdată, nu ne vom concentra pe detalii, ci ne vom stabili scopul de a-l învăța pe cititor să distingă cel puțin vizual între tipurile de diagrame, pentru a oferi o idee inițială despre scopul principalelor tipuri de diagrame. Deci, să începem.

Diagrama de caz de utilizare

Orice sisteme (inclusiv software) sunt proiectate ținând cont de faptul că în cursul activității lor vor fi utilizate de oameni și/sau vor interacționa cu alte sisteme. Sunt numite entitățile cu care sistemul interacționează în cursul activității sale actoriși fiecare actor se așteaptă ca sistemul să se comporte într-un mod strict definit, previzibil. Să încercăm să dăm o definiție mai riguroasă a unui ector. Pentru a face acest lucru, folosim un vocabular vizual minunat pentru UML Zicom Mentor:

Hector (actor)- acesta este un set de roluri legate logic îndeplinite atunci când interacționează cu precedente sau entități (sistem, subsistem sau clasă). Un actor poate fi o persoană sau un alt sistem, subsistem sau clasă care reprezintă ceva în afara entității.

Grafic, vectorul este reprezentat fie " om mic„, asemănătoare celor pe care le-am desenat în copilărie, înfățișând membrii familiei noastre, sau simbolul clasei cu stereotipul corespunzător, așa cum se arată în imagine. Ambele forme de prezentare au aceeași semnificație și pot fi folosite în diagrame. Forma „stereotipată” este folosită mai des pentru a reprezenta actorii sistemului sau în cazurile în care actorul are proprietăți care trebuie afișate (Fig. 2.1).

Cititorul atent poate pune imediat întrebarea: De ce este Hector și nu actor?? Suntem de acord, cuvântul „ektor” taie puțin urechea unui rus. Motivul pentru care spunem acest lucru este simplu - ectorul este format din cuvânt acțiune, ceea ce înseamnă în traducere acțiune. Traducerea literală a cuvântului „ektor” - actor- prea lung și incomod de utilizat. Prin urmare, vom continua să spunem asta.

Orez. 2.1.

Același cititor atent a putut observa cuvântul „precedent” fulgerător în definiția ectorului. Ce este? Această întrebare ne va interesa și mai mult dacă ne amintim despre care vorbim acum diagrama cazului de utilizare. Asa de,

Precedent (caz de utilizare)- descrierea unui anumit aspect al comportamentului sistemului din punctul de vedere al utilizatorului (Butch).

Definiția este destul de înțeleasă și exhaustivă, dar poate fi rafinată și mai mult folosind aceeași Zicom Mentor"om:

utilizare caz- descrierea ansamblului de evenimente succesive (inclusiv variante) realizate de sistem care duc la rezultatul observat de actor. Un caz de utilizare reprezintă comportamentul unei entități prin descrierea interacțiunii dintre actori și sistem. Un precedent nu arată „cum” se obține un anumit rezultat, ci doar „ce” este acesta.

Precedentele sunt indicate într-un mod foarte simplu - sub forma unei elipse, în interiorul căreia este indicat numele acestuia. Cazurile de utilizare și actorii sunt conectați cu linii. Adesea, la un capăt al liniei, sunt prezentate orezul. 2.3

formarea cerințelor generale pentru comportamentul sistemului proiectat;

dezvoltarea unui model conceptual al sistemului pentru detalierea ulterioară a acestuia;

pregătirea documentației pentru interacțiunea cu clienții și utilizatorii sistemului.

UML este un limbaj de modelare grafică de uz general pentru specificarea, vizualizarea, proiectarea și documentarea tuturor artefactelor create în dezvoltarea sistemelor software.

Există multe cărți bune care descriu în detaliu despre UML (uneori chiar foarte detaliat), aș dori să adun într-un singur loc conceptele de bază despre diagrame, entități și relații dintre ele pentru o reamintire rapidă, ceva de genul unei cheat sheet.

Nota folosește materiale din cărți: Ivanov D. Yu., Novikov F. A. Limbajul de modelare unificat UMLȘi Leonenkov. Tutorial UML.

Să începem cu editorul. Sub Linux, am încercat diferite editori UML, cel mai mult mi-a plăcut UMLet, deși este scris în Java, se mișcă foarte repede și majoritatea spațiilor de entitate sunt în el. Există și ArgoUML, un editor UML multiplatform, scris tot în Java, bogat funcțional, dar care încetinește mai mult.

m-am oprit la UMLet, instalează-l sub Arch LinuxȘi ubuntu:

# sub Arch Linux yaourt -S umlet # sub Ubuntu sudo apt-get install umlet

În UML, toate entitățile pot fi împărțite în următoarele tipuri:

• structural;
• comportamental;
• grupare;
• adnotare;

UML utilizează patru tipuri principale de relații:

Dependenţă- indică faptul că schimbarea entității independente afectează într-un fel entitatea dependentă. Grafic, o relație de dependență este reprezentată ca o linie punctată cu o săgeată care indică de la entitatea dependentă la entitatea independentă.

Asociere- are loc dacă o entitate este direct legată de alta (sau de altele - asocierea poate fi nu numai binară). Grafic, o asociere este descrisă ca o linie solidă cu diferite adăugiri care leagă entitățile înrudite.

Generalizare este o relație între două entități, dintre care una este un caz particular (de specialitate) al celeilalte. Grafic, generalizarea este reprezentată ca o linie cu o săgeată triunghiulară neumplută la sfârșit, îndreptată de la particular (subclasă) la general (superclasă).

Implementări- relația de implementare indică faptul că o entitate este o implementare a alteia. Grafic, implementarea este reprezentată ca o linie punctată cu o săgeată triunghiulară neumplută la sfârșit, îndreptată de la entitatea de implementare la cea implementată.

ÎN UML 2 este definit 13 tipuri de diagrame. Conform standardelor, fiecare diagramă ar trebui să aibă un cadru cu un dreptunghi (colțul din dreapta jos teșit) în colțul din stânga sus, care indică ID-ul diagramei (eticheta) și titlul.

Diagrame pentru a descrie structura sistemului:

• Diagrama componentelor (diagrama componentelor, tag componentă);
• Diagrama de implementare (diagrama de implementare, tag implementare);
• Diagrama de clasă (diagrama de clasă, tag clasă);
• Diagrama obiect (diagrama obiectului, tag obiect);
• Diagrama structurii interne (diagrama structurii compozite, tag clasă);

Diagrame pentru a descrie comportamentul sistemului:

• Diagrama de sincronizare (diagrama de interacțiune, tag sincronizare);
• Diagrama activității (diagrama activității, tag activitate);
• diagramă de secvență (diagrama de secvență, tag sd);
• Diagrama de comunicare (diagrama de comunicare, tag comm);
• Diagrama automată (diagrama mașinii de stare, eticheta mașină de stat);
• Diagrama de prezentare a interacțiunii, etichetă interacţiune);

Diagramele ies în evidență:

• Diagrama cazului de utilizare (diagrama cazului de utilizare, eticheta cazului de utilizare);
• Diagrama pachetului (diagrama pachetului, eticheta pachet);

Diagrama de utilizare

Diagrama de utilizare(diagrama cazului de utilizare) este cea mai generală reprezentare a scopului funcțional al sistemului.

Considerând o diagramă de caz de utilizare ca model de sistem, se poate asocia cu un model cutie neagră. Fiecare caz de utilizare definește o secvență de acțiuni care trebuie efectuate de sistemul proiectat atunci când interacționează cu actorul corespunzător.

Diagrama de utilizare folosește două tipuri de entități de bază: cazuri de utilizare și actori, între care se stabilesc următoarele tipuri de relații de bază.

relație de asociere- Această relație stabilește ce rol specific joacă un actor atunci când interacționează cu o instanță a unui caz de utilizare. O relație de asociere este indicată de o linie solidă între actor și cazul de utilizare. Această linie poate avea simboluri suplimentare, cum ar fi, de exemplu, un nume și o multiplicitate.

Relația de extindere- definește relația dintre instanțe ale unui singur caz de utilizare cu un caz de utilizare mai general, ale cărui proprietăți sunt determinate pe baza modului în care aceste instanțe sunt combinate împreună. Astfel, dacă există o relație de extensie de la cazul de utilizare A la cazul de utilizare B, atunci aceasta înseamnă că proprietățile unei instanțe de caz de utilizare B pot fi suplimentate datorită prezenței proprietăților în cazul de utilizare extins A.

O relație de extensie între cazurile de utilizare este indicată printr-o linie întreruptă cu o săgeată (cazul relației de dependență) care indică în altă parte față de cazul de utilizare care este o extensie a cazului de utilizare original.

Relația de generalizare servește pentru a indica faptul că un anumit caz de utilizare A poate fi generalizat la cazul de utilizare B. În acest caz, cazul de utilizare A va fi o specializare a cazului de utilizare B. În acest caz, B este numit strămoș sau părinte al lui A și folosește A este un descendent al utilizării cazului de utilizare a lui V.

Grafic, această relație este reprezentată de o linie continuă cu o săgeată triunghiulară deschisă care indică cazul de utilizare părinte.

O relație de generalizare între cazurile de utilizare este utilizată atunci când este necesar să rețineți că cazurile de utilizare copii au toate atributele și comportamentele cazurilor de utilizare părinte.

Relația de incluziuneîntre două cazuri de utilizare indică faptul că un anumit comportament pentru un caz de utilizare este inclus ca componentă în secvența de comportament a altui caz de utilizare.

O relație de includere, de la cazul de utilizare A la cazul de utilizare B, indică faptul că fiecare instanță a cazului de utilizare A include proprietățile funcționale specificate pentru cazul de utilizare B.

Grafic, această relație este reprezentată printr-o linie punctată cu o săgeată (variantă a relației de dependență) care indică de la cazul de utilizare de bază la cazul de utilizare inclus.

diagrama de clasă

diagrama de clasă(diagrama de clasă) - modalitatea principală de a descrie structura statică a sistemului.

Diagrama de clase folosește un tip principal de entități: clase (inclusiv numeroase cazuri speciale de clase: interfețe, tipuri primitive, clase de asociere etc.), între care se stabilesc următoarele tipuri principale de relații: dependențe, asocieri, generalizări, implementări.

Relația de dependențăîn general indică o relație semantică între două elemente de model sau două seturi de astfel de elemente care nu este o relație de asociere, generalizare sau implementare. O relație de dependență este utilizată într-o situație în care o anumită modificare a unui element de model poate necesita o modificare a altui element dependent de model.

O relație de dependență este reprezentată grafic printr-o linie întreruptă între elementele corespunzătoare cu o săgeată la un capăt, cu săgeata îndreptată de la clasa client a dependenței către clasa independentă sau sursă.

Cuvinte cheie speciale (stereotipuri) pot fi plasate deasupra săgeții:

• „acces” - servește pentru a indica disponibilitatea atributelor și operațiunilor publice ale clasei sursă pentru clasele client;
• "bind" - clasa client poate folosi un șablon pentru parametrizarea ulterioară;
• „deriva” - atributele clasei de client pot fi calculate din atributele clasei sursă;
• „import” - atributele și operațiunile publice ale clasei sursă devin parte din clasa client, ca și cum ar fi declarate direct în aceasta;
• „rafina” - indică faptul că clasa de client servește ca o rafinare a clasei sursă din motive istorice, atunci când informații suplimentare devin disponibile în cursul lucrărilor la proiect.

relație de asociere corespunde prezenţei unor relaţii între clase. Această relație este indicată de o linie continuă cu simboluri speciale suplimentare care caracterizează proprietățile individuale ale unei anumite asociații. Ca caractere speciale suplimentare, se pot folosi numele asociației, precum și numele și multiplicitatea claselor de roluri ale asociației. Numele unei asociații este un element opțional al desemnării acesteia.

Relația de agregare apare între mai multe clase dacă una dintre clase este o entitate care include alte entități ca componente. Este folosit pentru a reprezenta relații de sistem de tip „parte-întreg”.

Relația de compoziție este un caz special al unei relații de agregare. Această relație servește la evidențierea unei forme speciale a relației parte-intreg în care părțile constitutive se află într-un anumit sens în întreg. Specificul relației dintre ele constă în faptul că părțile nu pot acționa izolat de întreg, adică odată cu distrugerea întregului, toate părțile sale constitutive sunt și ele distruse.

Relația de generalizare este o relație între un element mai general (părinte sau strămoș) și un element mai specific sau mai special (copil sau descendent). Așa cum este aplicată unei diagrame de clase, această relație descrie structura ierarhică a claselor și moștenirea proprietăților și comportamentului lor. Aceasta presupune că clasa descendentă are toate proprietățile și comportamentul clasei strămoși și, de asemenea, are propriile proprietăți și comportament care nu sunt prezente în clasa strămoșilor.

diagrama automată

diagrama automată(stați diagrama mașinii) sau diagrama de stareîn UML 1 (diagrama diagramei stărilor) este o modalitate de a descrie comportamentul în detaliu în UML. În esență, diagramele automate, așa cum sugerează și numele, sunt un grafic al stărilor și tranzițiilor unui automat finit încărcat cu multe detalii și detalii suplimentare.

Diagrama de stare descrie procesul de schimbare a stărilor unei singure clase, sau mai degrabă, a unei instanțe a unei anumite clase, adică modelează toate modificările posibile ale stării unui anumit obiect. În acest caz, o schimbare a stării unui obiect poate fi cauzată de influențe externe de la alte obiecte sau din exterior. Diagramele de stare sunt folosite pentru a descrie reacția unui obiect la astfel de influențe externe.

În diagrama automată, se utilizează un tip principal de entitate - stări și un tip de relație - tranziții, dar pentru ambele sunt definite multe varietăți, cazuri speciale și denumiri suplimentare. Automatul reprezintă aspectele dinamice ale sistemului simulat sub forma unui graf direcționat, ale cărui vârfuri corespund stărilor, iar arcele corespund tranzițiilor.

Stare initiala este un caz special al unei stări care nu conține acțiuni interne (pseudo-stări). Obiectul este în această stare implicit în momentul inițial de timp. Acesta servește la indicarea pe diagrama de stare a zonei grafice din care începe procesul de schimbare a stărilor.

Finala (finala) o stare este un caz special al unei stări care, de asemenea, nu conține acțiuni interne (pseudo-stări). Obiectul va fi în această stare în mod implicit după finalizarea automatului la momentul final.

diagrama de activitate

La modelarea comportamentului unui sistem proiectat sau analizat, devine necesar nu doar prezentarea procesului de modificare a stărilor acestuia, ci și detalierea caracteristicilor implementării algoritmice și logice a operațiilor efectuate de sistem.

diagrama de activitate(diagrama activității) este un alt mod de a descrie comportamentul care seamănă vizual cu o diagramă veche a unui algoritm. Folosit pentru a simula procesul de efectuare a operațiunilor.

Direcția principală de utilizare a diagramelor de activitate este vizualizarea caracteristicilor implementării operațiilor de clasă, atunci când este necesar să se prezinte algoritmi pentru executarea acestora.

În diagrama de activitate, se folosește un tip principal de entități - acțiune, și un tip de relație - tranziții (transferuri de control). De asemenea, sunt utilizate construcții precum furci, fuziuni, conexiuni, ramificații. Se recomandă utilizarea unui verb cu cuvinte explicative ca denumire a unei acțiuni simple.

Diagrama secvenței

Diagrama secvenței(diagrama secvenței) este o modalitate de a descrie comportamentul sistemului „prin exemple”.

De fapt, o diagramă de secvență este o înregistrare a protocolului unei anumite sesiuni a sistemului (sau un fragment al unui astfel de protocol). În programarea orientată pe obiecte, cel mai esențial lucru în timpul execuției este transmiterea de mesaje între obiectele cooperante. Este secvența de trimitere a mesajelor care este afișată pe această diagramă, de unde și numele.

În diagrama de secvență, se utilizează un tip principal de entități - instanțe de clasificatori care interacționează (în principal clase, componente și actori) și un tip de relație - legături prin care se fac schimb de mesaje.

Tipuri posibile de mesaje (imagine preluată de pe larin.in):

Diagrama de comunicare

Diagrama de comunicare(diagrama de comunicare) - un mod de a descrie comportamentul, echivalent semantic cu o diagramă de secvență. De fapt, aceasta este aceeași descriere a secvenței de schimb de mesaje a instanțelor care interacționează ale clasificatorilor, exprimată doar prin alte mijloace grafice.

Astfel, în diagrama de comunicare, precum și în diagrama de secvență, se utilizează un tip principal de entități - instanțe de clasificatori care interacționează și un tip de relație - conexiuni. Totuși, aici accentul nu este pus pe timp, ci pe structura relațiilor dintre instanțe specifice.

Diagrama componentelor

Diagrama componentelor(diagrama componentelor) - arată relația dintre modulele (logice sau fizice) care alcătuiesc sistemul simulat.

Tipul principal de entitate într-o diagramă de componente sunt componentele în sine, precum și interfețele, prin care este indicată relația dintre componente. În diagrama componentelor se aplică următoarele relații:

• implementari intre componente si interfete (componenta implementeaza interfata);
• dependențe între componente și interfețe (o componentă folosește o interfață);

Diagrama de amplasare

Diagrama de amplasare(diagrama de implementare), împreună cu afișarea compoziției și relațiilor elementelor sistemului, arată modul în care acestea sunt plasate fizic pe resursele de calcul în timpul execuției.

În diagrama de plasare, în comparație cu diagrama componentelor, se adaugă două tipuri de entități: un artefact, care este o implementare a componentei și un nod (poate fi fie un clasificator care descrie tipul de nod, fie o instanță specifică) , precum și o relație de asociere între noduri, care arată că nodurile sunt conectate fizic în timpul rulării.

Diagrama obiectului

Diagrama obiectului(diagrama obiectului) - este o instanță a unei diagrame de clasă.

În diagrama obiectelor se utilizează un tip principal de entități: obiecte (instanțele de clasă), între care sunt indicate relații specifice (cel mai adesea instanțe de asociere). Diagramele de obiecte sunt de natură auxiliară - de fapt, acestea sunt exemple (s-ar putea spune, depozite de memorie) care arată ce obiecte există și conexiunile dintre ele la un anumit moment al funcționării sistemului.

Diagrama structurii interne(diagrama structurii compozite) este folosită pentru o prezentare mai detaliată a clasificatorilor structurali, în primul rând clase și componente.

Un clasificator structural este prezentat ca un dreptunghi cu numele clasificatorului în partea de sus. Înăuntru sunt piese. Pot fi mai multe părți. Părțile pot interacționa între ele. Acest lucru este indicat de conectori de diferite tipuri. Locul de pe marginea exterioară a piesei de care este atașat conectorul se numește port. Porturile sunt, de asemenea, situate la limita exterioară a clasificatorului structural.

Diagrama de prezentare a interacțiunii(diagrama de prezentare a interacțiunii) este un fel de diagramă de activitate cu o sintaxă extinsă: legăturile către interacțiuni (utilizarea interacțiunii) definite de diagramele de secvență pot acționa ca elemente ale unei diagrame de interacțiune de ansamblu.

Diagrama de timp

Diagrama de timp(diagrama temporală) este o formă specială a diagramei secvențe, în care se acordă o atenție deosebită schimbării stărilor diferitelor instanțe ale clasificatoarelor și sincronizării lor în timp.

Diagrama pachetului

Diagrama pachetului(diagrama pachetului) este singurul instrument care vă permite să gestionați complexitatea modelului în sine.

Elementele principale ale notației sunt pachetele și dependențele cu diverse stereotipuri.

Model entitate-relație (model ER)

analogic diagrame de clasă(UML) poate fi Model ER, care este utilizat în proiectarea bazelor de date (model relațional).

Modelul entitate-relație (ER-model) este un model de date care permite descrierea schemelor conceptuale ale domeniului de studiu. Modelul ER este utilizat în proiectarea bazelor de date la nivel înalt (conceptual). Cu ajutorul acestuia, poți evidenția entitățile cheie și desemna relațiile care pot fi stabilite între aceste entități. wikipedia

Orice fragment din domeniul subiectului poate fi reprezentat ca un set de entități, între care există un anumit set de relații.

Noțiuni de bază:

Esență(entitate) este o entitate care poate fi identificată într-un fel care o diferențiază de alte entități, de exemplu, CLIENTUL 777. O entitate este de fapt un set de atribute.

Set de entitati(set de entități) - un set de entități de același tip (având aceleași proprietăți).

Conexiune(relația) este o asociere stabilită între mai multe entități.

Domeniu(domeniu) - set de valori (domeniu) ale atributului.

Există trei tipuri de legături binare:

• unu la unu- o singură instanță a unei entități dintr-o clasă este asociată cu o singură instanță a unei entități dintr-o altă clasă, de exemplu, ȘEF - DEPARTAMENT;
• 1 la N sau unu la multi- o singură instanță a unei entități dintr-o clasă este asociată cu mai multe instanțe ale unei entități din altă clasă, de exemplu, DEPARTAMENT - ANGAJAT;
• N la M sau multi la multi- multe instanțe ale unei entități dintr-o clasă sunt asociate cu mai multe instanțe ale unei entități din altă clasă, de exemplu, ANGAJAT - PROIECT;
Glosar de concepte de bază în UML

obiect- o entitate care are o unicitate și încapsulează starea și comportamentul.

clasă- o descriere a unui set de obiecte cu atribute comune care definesc starea și operațiunile care definesc comportamentul.

interfata- un set numit de operațiuni care definește un set de servicii care pot fi solicitate de consumator și furnizate de furnizorul de servicii.

Cooperare- un set de obiecte care interacționează pentru a atinge un anumit scop.

Actor- o entitate care se află în afara sistemului modelat și interacționează direct cu acesta.

componentă- o parte modulară a sistemului cu un set bine definit de interfețe necesare și furnizate.

Artefact- un element de informație care este utilizat sau generat în procesul de dezvoltare a software-ului. Cu alte cuvinte, un artefact este o unitate fizică de implementare derivată dintr-un element model (cum ar fi o clasă sau o componentă).

Nodul- o resursă de calcul pe care sunt plasate artefacte și, dacă este necesar, executate.

Entitățile comportamentale sunt menite să descrie comportamentul. Există doar două entități comportamentale de bază: stare și acțiune.

stat- o perioadă din ciclul de viață al unui obiect, fiind în care obiectul satisface o anumită condiție și își desfășoară propria activitate sau așteaptă apariția unui eveniment.

acțiune- calculul atomic primitiv.

Mașinărie este un pachet care definește un set de concepte necesare pentru a reprezenta comportamentul entității modelate ca un spațiu discret cu un număr finit de stări și tranziții.

clasificator este un descriptor pentru un set de obiecte de același tip.

Lectură suplimentară

• Fowler M. UML. Fundamente, ediția a 3-a
• Butch G., Rambo D., Jacobson I. limbajul UML. Manualul utilizatorului