Warning: Cannot modify header information - headers already sent by (output started at /home/intheory/public_html/ro/despre_uml_introducere.php:2) in /home/intheory/public_html/counter.inc on line 31
 Despre UML. Introducere, generalităţi
in-theory.info

Despre UML. Introducere, generalităţi

Etichete: UML

Cuvintele sunt cu adevărat mijlocul de comunicare cel mai puţin eficient.
Ele sunt cele mai expuse la interpretări greşite şi cel mai adesea prost înţelese.
Neale Donald Walsch


UML este în primul rând un limbaj

UML (Unified Modelling Language) este, aşa cum îi spune şi numele, un limbaj. El este un limbaj pentru modelare folositor în domeniul software, la realizarea documentelor de specificaţii şi, În general, bun pentru comunicarea între ingineri.

De ce să utilizezi UML?

Aşa cum spune şi vorba populară, „o imagine exprimă cât o mie de cuvinte”. Mai mult decât atât, cele o mie de cuvinte pot fi ambigue sau pot fi interpretate diferit. Aşa cum ştim, fiecare cuvânt poate avea mai multe sensuri (iar în limba română aproape orice frază poate fi interpretată lejer ca o propunere indecentă). Cu siguranţă că exprimarea cea mai sofisticată, mai completă şi mai sigură se poate face direct în limbaj de programare, care, cel puţin după ştiinţa mea, rareori lasă loc de interpretări.


În ingineria mecanică pentru a realiza modelul complet al unei piese, inginerul foloseşte desenul tehnic ca limbaj pentru comunicare, iar ca mod de reprezentare, vederea în epură. Această vedere în epură înseamnă vizualizarea unei piese din trei puncte (din faţă, de sus şi din lateral) astfel încât piesa să fie definită complet. Un cititor avizat al desenului în epură va şti întotdeauna să refacă mental piesa desenată.





Dacă din cauza complexităţii piesei, cele trei „fotografii” nu sunt suficiente, inginerul va desena şi alte detalii, sau secţiuni ale piesei, dar privite din aceleaşi trei unghiuri.
Fiecare dintre cele trei puncte de vizualizare a piesei (noi le vom zice neaoş, view-uri) reprezintă un submodel capabil să descrie o parte a piesei, dar insuficient pentru a descrie complet piesa. Fiecare view arată piesa văzută dintr-un anumit punct de vedere iar modelul complet utilizează toate punctele de vedere relevante.

Aşa cum inginerul proiectant comunică prin desen tehnic, echipei sau oricărei alte persoane interesate, un limbaj vizual făcut să permită descrierea completă dar, în acelaşi timp, scutită de detalii inutile, inginerii software pot comunica cu maximă eficienţă în limbajul UML.

La fel ca oricare limbaj acesta trebuie învăţat şi exersat astfel încât fiecare „cuvânt” să fie înţeles, să ştim unde şi cum se foloseşte, astfel încât să ne putem exprima în „fraze” coerente, care să „spună” exact ceea ce vrem să comunicăm. Limbajul UML ne permite realizarea mai multor view-uri, ca nişte fotografii din diverse unghiuri, ale unei realităţi, astfel încât această realitate să fie surprinsă prin toate aspectele ei relevante.

În software vom utiliza două unghiuri de vedere necesare unei descrieri suficiente a realităţii: (1) structural şi (2) comportamental (behavioral).


În standardul UML, versiunea 1.4 sunt definite următoarele diagrame, pe cele două categorii:
a. pentru descrierea structurală:
- Class Diagram;
- Object Diagram;
- Component Diagram;
- Deployment Diagram.

b. pentru descrierea comportamentală:
- Use Case Diagram;
- Activity Diagram;
- Statechart Diagram;
- Sequence Diagram;
- Collaboration Diagram.

Deoarece această colecție de articole nu este un manual de UML, voi descrie doar acele diagrame care am considerat că sunt cele mai utile pentru analist.

Adrian Ionescu





Colecția:  🌻 Tutorial UML





👍 Topul celor mai citite articole

1. Analiza cerinţelor software. Introducere
Această serie de articole este destinată tuturor persoanelor implicate în proiecte de dezvoltare de software: şefi de departament, şefi de proiec...

2. Despre Analiza cerinţelor
Analiza cerinţelor software (pe care o vom numi în continuare Analiza de business sau Analiză software) este aceea dintre disciplinele existente î...

3. Axiomele dezvoltării software
Adevăruri ale dezvoltării software care susțin nevoia Analizei cerințelor. Unul dintre ele este: "Întotdeauna, într-un proiect software apar si...

4. Ciclul de dezvoltare al produsului software (SDLC)
Deşi în limba engleză este denumit Software Development Life Cycle (SDLC) am ales traducerea „Ciclul de dezvoltare al produsului software”, chi...

5. Ciclul de dezvoltare iterativ
Asumarea realităţii că întotdeauna, în decursul proiectului, cerinţele se vor schimba a condus la apariţia unui model de dezvoltare realist, ca...

6. Locul Analizei în proiectul de dezvoltare software
Analiza Software este o disciplină care se află în relaţie de dependenţă cu celelalte discipline din proiect. Concret, task-urile din proiectul ...

7. Modele teoretice de abordare a problemelor. Decompoziţia
Modalităţile teoretice de abordare a problemelor sunt universale şi pot fi folosite oriunde însă pentru domeniul nostru, este important să le co...

8. Modele teoretice de abordare a problemelor. Sinteza
Sinteza este o modalitate, prin care, din manifestări punctuale se determină problema reală. Cel mai simplu şi clar exemplu este acela al mediculu...

9. Modele teoretice de abordare a problemelor. Crearea unui trunchi de bază
De foarte multe ori, în viaţa reală, o problemă nu poate fi punctată decât cu un efort substanţial sau chiar deloc. Pur şi simplu, obţinerea ...

10. Modele teoretice de abordare a problemelor. Abordarea iterativă
Metoda iterativă presupune rezolvarea unei probleme cunoscute printr-o abordare iterativă, la fiecare iteraţie făcând un pas către rezolvarea pr...



📜 Căutare după etichetă:

Analiza Business
Baze de date
C#
Cerințe software
CSS
Dictionar IT
HTML
MySQL
PHP
Riscuri
SDLC
Specificații software
SQL
UML