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 Node - containere care se referă la date 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 Nod care conține o legătură către acel rând, precum și o legătură către Nodul 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 diferite procese din cadrul companiei dvs. sau puteți descrie procesul de afaceri în cadrul căruia funcționează funcția pe care o scrieți. Depinde de dvs. să decideți cât de mult vă este util UML personal, dar oricum vă va fi util să găsiți timp și să îl cunoașteți mai detaliat. #Viacheslav Versiunea rusă a acestei postări: diagrama UML Java pe CodeGymAdnotare: 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 de 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 conduc 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
UML este acum notația standard pentru modelarea vizuală a sistemelor software, adoptată de Object Managing Group (OMG) în toamna anului 1997 și susținută de multe produse CASE orientate pe obiecte.
Standardul UML oferă următorul set de diagrame pentru modelare:
Diagrama de caz de utilizare (diagrama de caz de utilizare) - pentru modelarea proceselor de afaceri ale unei organizații sau întreprinderi și determinarea cerințelor pentru sistemul informațional creat;
diagrama de clase (diagrama de clase) - pentru modelarea structurii statice a claselor de sistem si a relatiilor dintre acestea;
diagrama comportamentului sistemului (diagramele comportamentului);
diagrame de interacțiune;
Diagrame de secvență - pentru modelarea procesului de mesagerie între obiecte într-un singur caz de utilizare;
diagramă de colaborare (diagrama de colaborare) - pentru modelarea procesului de mesagerie între obiecte din cadrul aceluiași caz de utilizare;
diagrama statechart - pentru modelarea comportamentului obiectelor de sistem în timpul trecerii de la o stare la alta;
diagramă de activitate - pentru modelarea comportamentului sistemului în cadrul diferitelor cazuri de utilizare, sau activități de modelare;
diagramă de implementare (diagrame de implementare):
Diagrame componente (diagrame componente) - pentru modelarea ierarhiei componentelor (subsistemelor) unui sistem informatic;
diagrama de implementare (diagrama de implementare) - pentru modelarea arhitecturii fizice a sistemului informatic proiectat.
Pe fig. 1.1 prezintă un model integrat al sistemului informațional, inclusiv principalele diagrame care vor fi dezvoltate în acest proiect de curs.
Orez. 1. Un model integrat al unui sistem informatic în notarea limbajului UML
4.2. Diagrama de caz de utilizare
Un caz de utilizare este o secvență de acțiuni efectuate de sistem ca răspuns la un eveniment declanșat de un obiect extern (actor). Un caz de utilizare descrie o interacțiune tipică între un utilizator și un sistem. În cel mai simplu caz, cazul de utilizare este determinat în procesul de discuție cu utilizatorul a funcțiilor pe care acesta ar dori să le implementeze în acest sistem informațional. În UML, un caz de utilizare este descris după cum urmează:
Fig.2. Utilizare caz
Un actor este un rol pe care îl joacă un utilizator în raport cu sistemul. Actorii reprezintă roluri, nu anumite persoane sau titluri de post. Deși sunt descrise ca figuri umane stilizate în diagramele de cazuri de utilizare, un actor poate fi, de asemenea, un sistem de informații extern care are nevoie de unele informații din sistem. Ar trebui să arătați actorii într-o diagramă doar atunci când au nevoie cu adevărat de anumite cazuri de utilizare. În UML, actorii sunt reprezentați ca forme:
Fig.3. Personaj (actor)
Actorii sunt împărțiți în trei tipuri principale:
Utilizatori
sisteme;
Alte sisteme care interacționează cu acesta;
Timpul devine actor dacă de el depinde declanșarea oricăror evenimente din sistem.
4.2.1. Relații între cazuri de utilizare și actori
În UML, diagramele de caz de utilizare acceptă mai multe tipuri de relații între elementele diagramei:
Comunicare (comunicare),
Includere (include),
extindere (extindere),
generalizare.
comunicare comunicare este relația dintre cazul de utilizare și actor. În UML, legăturile de comunicare sunt afișate folosind o asociere unidirecțională (linie continuă).
Fig.4. Exemplu de legătură de comunicare
Conexiune de includere utilizat în situațiile în care există o anumită parte a comportamentului sistemului care se repetă în mai multe cazuri de utilizare. Cu ajutorul unor astfel de link-uri, se modelează de obicei o funcție reutilizabilă.
Conexiune la extensie folosit pentru a descrie schimbările în comportamentul normal al unui sistem. Permite unui caz de utilizare să folosească funcționalitatea altui caz de utilizare atunci când este necesar.
Fig.5. Un exemplu de relație de includere și extindere
Generalizarea comunicării indică faptul că mai mulți actori sau clase au proprietăți comune.
Fig.6. Un exemplu de relație de generalizare
4.3.
Diagrame de interacțiune descrie comportamentul grupurilor de obiecte care interacționează. De obicei, o diagramă de interacțiune acoperă doar comportamentul obiectelor într-un singur caz de utilizare. O astfel de diagramă afișează un număr de obiecte și mesajele pe care le schimbă între ele.
mesaj este mijlocul prin care obiectul emițător solicită obiectului receptor să efectueze una dintre operațiile sale.
Mesaj informativ (informativ). este un mesaj care oferă obiectului care primește unele informații pentru a-și actualiza starea.
Solicitare mesaj (interogativ) este un mesaj care solicită ieșirea unor informații despre obiectul destinatar.
Mesaj imperativ este un mesaj care cere receptorului să efectueze o acțiune.
Există două tipuri de diagrame de interacțiune: diagrame de secvență și diagrame de colaborare.
4.3.1. Diagrame secvențe
Diagrama secvenței reflectă fluxul de evenimente care au loc într-un singur caz de utilizare.
Toți actorii (actori, clase sau obiecte) implicați într-un anumit scenariu (caz de utilizare) sunt afișați în partea de sus a diagramei. Săgețile corespund mesajelor transmise între un actor și un obiect sau între obiecte pentru a îndeplini funcțiile necesare.
Într-o diagramă de secvență, un obiect este reprezentat ca un dreptunghi, din care este trasată o linie verticală punctată în jos. Această linie se numește linia de salvare a unui obiect . Este un fragment din ciclul de viață al unui obiect în procesul de interacțiune.
Fiecare mesaj este reprezentat ca o săgeată între liniile de viață a două obiecte. Mesajele apar în ordinea în care apar pe pagină de sus în jos. Fiecare mesaj este etichetat cu cel puțin numele mesajului. Opțional, puteți adăuga și argumente și câteva informații de control. Puteți afișa autodelegarea, un mesaj pe care un obiect și-l trimite singur, cu săgeata de mesaj îndreptată către aceeași linie de salvare.
Orez. 7. Exemplu de diagramă de secvență
4.3.2. Diagrama de colaborare
Diagrame de cooperare afișează fluxul de evenimente într-un scenariu specific (caz de utilizare). Mesajele sunt ordonate în funcție de timp, deși diagramele de colaborare se concentrează mai mult pe relațiile dintre obiecte. O diagramă de colaborare arată toate informațiile pe care le are o diagramă de secvență, dar o diagramă de colaborare descrie fluxul evenimentelor într-un mod diferit. Din aceasta este mai ușor de înțeles conexiunile care există între obiecte.
Într-o diagramă de colaborare, la fel ca într-o diagramă de secvență, săgețile reprezintă mesajele care sunt schimbate într-un anumit caz de utilizare. Secvența lor de timp este indicată prin numerotarea mesajelor.
Orez. 8. Un exemplu de diagramă de cooperare
4.4. diagrama de clasă
4.4.1. Informatii generale
diagrama de clasă definește tipurile de clase de sistem și diferitele tipuri de legături statice care există între ele. Diagramele de clasă arată, de asemenea, atributele de clasă, operațiile de clasă și constrângerile care sunt aplicate relațiilor dintre clase.
O diagramă de clase în UML este un grafic ale cărui noduri sunt elementele structurii statice a proiectului (clase, interfețe), iar arcele sunt relațiile dintre noduri (asocieri, moștenire, dependențe).
Diagrama de clasă prezintă următoarele elemente:
· Pachetul (pachet) - un set de elemente ale modelului, legate logic între ele;
· Clasa (clasa) - descrierea proprietatilor comune ale unui grup de obiecte similare;
· Interfață (interfață) - o clasă abstractă care definește un set de operații pe care un obiect dintr-o clasă arbitrară asociată cu o interfață dată le oferă altor obiecte.
4.4.2. Clasă
Clasă este un grup de entități (obiecte) care au proprietăți similare, și anume date și comportament. Un membru individual al unei clase este numit obiect al clasei sau pur și simplu obiect.
Comportamentul unui obiect în UML se referă la orice reguli de interacțiune a unui obiect cu lumea exterioară și cu datele obiectului însuși.
În diagrame, o clasă este reprezentată ca un dreptunghi cu un chenar solid, împărțit prin linii orizontale în 3 secțiuni:
Secțiunea de sus (secțiunea de nume) conține numele clasei și alte proprietăți generale (în special, stereotipul).
Secțiunea din mijloc conține o listă de atribute
În partea de jos este o listă de operații de clasă care reflectă comportamentul acesteia (acțiuni efectuate de clasă).
Este posibil ca oricare dintre secțiunile de atribute și operații să nu fie afișate (sau ambele). Pentru secțiunea lipsă, nu trebuie să trasați o linie de despărțire și să indicați cumva prezența sau absența elementelor în ea.
Secțiuni suplimentare, cum ar fi Excepții, pot fi introduse la discreția unei anumite implementări.
Orez. 9. Exemplu de diagramă de clasă
4.4.2.1.Stereotipuri de clasă
Stereotiparea claselor este un mecanism de clasificare a claselor în categorii.
UML definește trei stereotipuri principale de clasă:
Graniță (graniță);
Entitate (entitate);
Control (management).
4.4.2.2.Clasele limită
Clasele limită sunt acele clase care sunt situate la granița sistemului și a întregului mediu. Acestea sunt afișaje, rapoarte, interfețe cu hardware (cum ar fi imprimante sau scanere) și interfețe cu alte sisteme.
Pentru a găsi clase de limită, trebuie să explorați diagramele de caz de utilizare. Fiecare interacțiune dintre un actor și un caz de utilizare trebuie să aibă cel puțin o clasă limită. Această clasă îi permite actorului să interacționeze cu sistemul.
4.4.2.3.Clasele de entitati
Clasele de entități conțin informații stocate. Ele au cel mai mare înțeles pentru utilizator și, prin urmare, numele lor folosesc adesea termeni din domeniul subiectului. De obicei, pentru fiecare clasă de entitate, se creează un tabel în baza de date.
4.4.2.4.Clasele de control
Clasele de control sunt responsabile pentru coordonarea acțiunilor altor clase. De obicei, fiecare caz de utilizare are o clasă de control care controlează secvența de evenimente pentru acel caz de utilizare. Clasa de control este responsabilă de coordonare, dar nu poartă nicio funcționalitate în sine, deoarece celelalte clase nu îi transmit un număr mare de mesaje. În schimb, el însuși trimite o mulțime de mesaje. Clasa de manager pur și simplu deleagă responsabilitatea altor clase, motiv pentru care este adesea denumită clasa de manager.
Pot exista și alte clase de control în sistem care sunt comune mai multor cazuri de utilizare. De exemplu, ar putea exista o clasă SecurityManager responsabilă de monitorizarea evenimentelor legate de securitate. Clasa TransactionManager se ocupă de coordonarea mesajelor legate de tranzacțiile bazei de date. Pot exista alți manageri care să se ocupe de alte elemente ale funcționării sistemului, cum ar fi partajarea resurselor, procesarea distribuită a datelor sau gestionarea erorilor.
Pe lângă stereotipurile menționate mai sus, vă puteți crea propriile dvs.
4.4.2.5.Atribute
Un atribut este o informație asociată cu o clasă. Atributele stochează date de clasă încapsulate.
Deoarece atributele sunt conținute în clasă, ele sunt ascunse de alte clase. Din acest motiv, poate fi necesar să se specifice care clase au dreptul de a citi și modifica atributele. Această proprietate se numește vizibilitate a atributului.
Atributul poate avea patru valori posibile pentru acest parametru:
Public (general, deschis). Această valoare de vizibilitate presupune că atributul va fi vizibil pentru toate celelalte clase. Orice clasă poate vizualiza sau modifica valoarea unui atribut. În conformitate cu notația UML, un atribut comun este precedat de un semn „+”.
Privat (închis, secret). Atributul corespunzător nu este vizibil pentru nicio altă clasă. Un atribut privat este notat printr-un semn „-” în conformitate cu notația UML.
Protejat (protejat). Un astfel de atribut este disponibil numai pentru clasa în sine și pentru descendenții săi. Notația UML pentru un atribut protejat este caracterul „#”.
Pachet sau Implementare (lot). Să presupunem că atributul dat este partajat, dar numai în pachetul său. Acest tip de vizibilitate nu este indicat de nicio pictogramă specială.
Cu ajutorul închiderii sau securității, este posibil să se evite situația când valoarea atributului este modificată de toate clasele sistemului. În schimb, logica de modificare a atributului va fi inclusă în aceeași clasă ca și atributul însuși. Opțiunile de vizibilitate pe care le setați vor afecta codul generat.
4.4.2.6.Operațiuni
Operațiunile implementează comportamentul legat de clasă. O operațiune are trei părți - un nume, parametri și un tip de returnare.
Parametrii sunt argumentele pe care operația le primește ca intrare. Tipul de returnare se referă la rezultatul acțiunii operației.
O diagramă de clasă poate afișa atât numele operațiunilor, cât și numele operațiilor, împreună cu parametrii și tipul de returnare a acestora. Pentru a reduce sarcina pe diagramă, este util să afișați numai numele operațiunilor pe unele dintre ele și semnătura lor completă pe altele.
În UML, operațiunile au următoarea notație:
Nume operație (argument: tip de date argument, argument2: tip de date argument2,...): tip de returnare
Există patru tipuri diferite de operațiuni de luat în considerare:
Operațiuni de implementare;
Operațiuni de management;
Operațiuni de acces;
Operatii auxiliare.
Operațiuni de implementare
Operațiunile implementatorilor implementează unele funcții de afaceri. Astfel de operațiuni pot fi găsite examinând diagramele de interacțiune. Diagramele de acest tip se concentrează pe funcțiile de business, iar fiecare mesaj din diagramă poate fi asociat, cel mai probabil, cu o operațiune de implementare.
Fiecare operațiune de implementare trebuie să fie ușor de urmărit la cerința corespunzătoare. Acest lucru se realizează în diferite etape ale simulării. Operația este derivată din mesajul din diagrama de interacțiune, mesajele sunt derivate din descrierea detaliată a fluxului de evenimente, care este generată pe baza cazului de utilizare, iar aceasta din urmă pe baza cerințelor. Posibilitatea de a urmări acest întreg lanț ajută la asigurarea faptului că fiecare cerință este implementată în cod și fiecare bucată de cod implementează o anumită cerință.
Operațiuni de management
Operațiunile managerului gestionează crearea și distrugerea obiectelor. Constructorii de clasă și destructorii se încadrează în această categorie.
Operațiuni de acces
Atributele sunt de obicei private sau protejate. Cu toate acestea, alte clase trebuie uneori să-și vadă sau să-și schimbe valorile. Există operațiuni de acces pentru aceasta. Această abordare face posibilă încapsularea în siguranță a atributelor într-o clasă, protejându-le de alte clase, dar permițând totuși acces controlat la ele. Crearea de operațiuni Get și Set (obținerea și modificarea unei valori) pentru fiecare atribut al unei clase este un standard.
Operatii auxiliare
Auxiliare (operații de ajutor) sunt acele operații ale unei clase care sunt necesare pentru ca aceasta să-și îndeplinească responsabilitățile, dar despre care alte clase nu ar trebui să știe nimic. Acestea sunt operațiuni de clasă privată și protejată.
Pentru a identifica tranzacțiile, procedați în felul următor:
1. Studiu diagramele secvențe și diagramele cooperative. Majoritatea mesajelor din aceste diagrame sunt operațiuni de implementare. Mesajele reflectorizante vor fi operații auxiliare.
2. Luați în considerare operațiunile de control. Poate fi necesar să adăugați constructori și destructori.
3. Luați în considerare operațiunile de acces. Pentru fiecare atribut de clasă cu care vor trebui să lucreze alte clase, trebuie să creați operațiuni Get și Set.
4.4.2.7.Conexiuni
O relație este o relație semantică între clase. Oferă unei clase capacitatea de a învăța despre atributele, operațiile și relațiile unei alte clase. Cu alte cuvinte, pentru ca o clasă să trimită un mesaj către alta într-o secvență sau diagramă cooperativă, trebuie să existe o legătură între ele.
Există patru tipuri de relații care pot fi stabilite între clase: asocieri, dependențe, agregari și generalizări.
Asociația de comunicare
O asociere este o relație semantică între clase. Ele sunt desenate pe diagrama de clasă ca o linie obișnuită.
Orez. 10. Asociația de comunicare
Asociațiile pot fi bidirecționale, ca în exemplu, sau unidirecționale. În UML, asociațiile bidirecționale sunt desenate ca o linie simplă fără săgeți sau cu săgeți de ambele părți ale liniei. O asociere unidirecțională are o singură săgeată care arată direcția sa.
Direcția unei asocieri poate fi determinată examinând diagramele secvențe și diagramele cooperative. Dacă toate mesajele de pe ele sunt trimise doar de o clasă și primite doar de o altă clasă, dar nu și invers, există o comunicare unidirecțională între aceste clase. Dacă cel puțin un mesaj este trimis în sens opus, asocierea trebuie să fie bidirecțională.
Asociațiile pot fi reflexive. Asocierea reflexivă înseamnă că o instanță a unei clase interacționează cu alte instanțe ale aceleiași clase.
Dependența de comunicare
Relațiile de dependență reflectă, de asemenea, relația dintre clase, dar sunt întotdeauna unidirecționale și arată că o clasă depinde de definițiile făcute în alta. De exemplu, clasa A folosește metode din clasa B. Apoi, atunci când clasa B se schimbă, este necesar să se facă modificări corespunzătoare în clasa A.
O dependență este reprezentată de o linie întreruptă trasată între două elemente de diagramă, iar elementul ancorat la sfârșitul unei săgeți se spune că este dependent de elementul ancorat la începutul acelei săgeți.
Orez. 11. Dependenta de comunicare
Când se generează cod pentru aceste clase, nu li se vor adăuga atribute noi. Cu toate acestea, vor fi creați operatorii specifici limbii necesari pentru a sprijini comunicarea.
Agregarea comunicațiilor
Agregările sunt o formă mai strânsă de asociere. Agregarea este legătura dintre întreg și partea sa. De exemplu, este posibil să aveți o clasă de mașini, precum și clase de motor, anvelope și clase pentru alte piese auto. Ca rezultat, un obiect din clasa Car va consta dintr-un obiect din clasa Engine, patru obiecte din Anvelope etc. Agregările sunt vizualizate ca o linie cu un romb pentru o clasă care este un număr întreg:
Orez. 11. Agregarea comunicării
Pe lângă agregarea simplă, UML introduce o formă mai puternică de agregare numită compoziție. Conform compoziției, o parte-obiect nu poate aparține decât unui singur întreg și, în plus, de regulă, ciclul de viață al părților coincide cu ciclul întregului: ele trăiesc și mor odată cu el. Orice îndepărtare a întregului se extinde la părțile sale.
Această ștergere în cascadă este adesea considerată parte a definiției agregării, dar este întotdeauna implicată atunci când multiplicitatea rolului este 1..1; de exemplu, dacă un Client trebuie șters, atunci ștergerea respectivă trebuie propagată către Comenzi (și, la rândul lor, Liniile de comandă).
UML este un limbaj unificat de modelare grafică pentru descrierea, vizualizarea, proiectarea și documentarea sistemelor OO. UML este conceput pentru a sprijini procesul de modelare PS bazat pe abordarea OO, pentru a organiza relația dintre conceptele conceptuale și de program și pentru a reflecta problemele de scalare a sistemelor complexe. Modelele UML sunt utilizate în toate etapele ciclului de viață al software-ului, de la analiza afacerii până la întreținerea sistemului. Diferite organizații pot folosi UML în felul lor, în funcție de zonele lor problematice și de tehnologiile utilizate.
O scurtă istorie a UML
Până la mijlocul anilor 1990, câteva zeci de metode de modelare OO au fost propuse de diverși autori, fiecare dintre acestea folosind propria sa notație grafică. În același timp, oricare dintre aceste metode avea punctele sale forte, dar nu permitea construirea unui model PS suficient de complet, pentru a-l arăta „din toate părțile”, adică toate proiecțiile necesare (vezi articolul 1). În plus, absența unui standard de modelare OO a îngreunat pentru dezvoltatori alegerea celei mai potrivite metode, ceea ce a împiedicat utilizarea pe scară largă a unei abordări OO pentru dezvoltarea software.
La solicitarea Object Management Group (OMG) - organizație responsabilă cu adoptarea standardelor în domeniul tehnologiilor obiectelor și bazelor de date, problema urgentă a unificării și standardizării a fost rezolvată de autorii celor mai populare trei metode OO - G. Booch , D. Rambo și A. Jacobson, care au combinat eforturile, au creat UML versiunea 1.1, aprobată de OMG în 1997 ca standard.
UML este un limbaj
Orice limbă constă dintr-un dicționar și reguli pentru combinarea cuvintelor pentru a face construcții semnificative. Deci, în special, sunt aranjate limbaje de programare, cum ar fi UML. Caracteristica sa distinctivă este că vocabularul limbii este format din elemente grafice. Fiecare simbol grafic are o semantică specifică, astfel încât un model creat de un dezvoltator poate fi înțeles fără ambiguitate de către altul, precum și de un instrument care interpretează UML-ul. Din aceasta, în special, rezultă că un model PS prezentat în UML poate fi tradus automat într-un limbaj de programare OO (cum ar fi Java, C++, VisualBasic), adică cu un instrument de modelare vizuală bun care acceptă UML, prin construind un model, vom obține și un gol al codului programului corespunzător acestui model.
Trebuie subliniat că UML este un limbaj, nu o metodă. Acesta explică din ce elemente să creeze modele și cum să le citească, dar nu spune nimic despre ce modele și în ce cazuri ar trebui dezvoltate. Pentru a crea o metodă bazată pe UML, este necesar să o completați cu o descriere a procesului de dezvoltare PS. Un exemplu de astfel de proces este Procesul Rațional Unificat, care va fi discutat în articolele ulterioare.
Vocabularul UML
Modelul este reprezentat sub formă de entități și relații dintre ele, care sunt prezentate pe diagrame.
Esențe sunt abstractizări care sunt elementele principale ale modelelor. Există patru tipuri de entități - structurale (clasă, interfață, componentă, caz de utilizare, cooperare, nod), comportamentale (interacțiune, stare), grupare (pachete) și adnotative (comentarii). Fiecare tip de entitate are propria sa reprezentare grafică. Entitățile vor fi discutate în detaliu atunci când se studiază diagramele.
Relaţii arată relații diferite între entități. Următoarele tipuri de relații sunt definite în UML:
- Dependenta arată o astfel de relație între două entități, când o modificare a uneia dintre ele - independentă - poate afecta semantica celeilalte - dependente. O dependență este reprezentată de o săgeată punctată care indică de la entitatea dependentă la entitatea independentă.
- Asociere este o relație structurală care arată că obiectele unei entități sunt legate de obiectele alteia. Grafic, o asociere este prezentată ca o linie care conectează entitățile aferente. Asociațiile sunt folosite pentru a naviga între obiecte. De exemplu, asocierea dintre clasele „Comandă” și „Produs” poate fi folosită pentru a găsi toate produsele specificate într-o anumită comandă - pe de o parte, sau pentru a găsi toate comenzile care conțin acest produs - pe de altă parte. Este clar că programele corespunzătoare trebuie să implementeze un mecanism care să asigure o astfel de navigare. Dacă navigarea este necesară într-o singură direcție, aceasta este indicată printr-o săgeată la sfârșitul asocierii. Un caz special de asociere este agregarea - o relație de forma „întreg” – „parte”. Grafic, se evidențiază cu un romb la capăt lângă entitate-întreg.
- Generalizare este o relație între o entitate-mamă și o entitate copil. În esență, această relație reflectă proprietatea moștenirii pentru clase și obiecte. Generalizarea este prezentată ca o linie care se termină cu un triunghi îndreptat către entitatea părinte. Copilul moștenește structura (atributele) și comportamentul (metodele) părintelui, dar în același timp poate avea noi elemente de structură și noi metode. UML permite moștenirea multiplă atunci când o entitate este legată de mai multe entități părinte.
- Implementarea- relatia dintre entitatea care defineste specificarea comportamentului (interfata) cu entitatea care defineste implementarea acestui comportament (clasa, componenta). Această relație este folosită în mod obișnuit în modelarea componentelor și va fi descrisă mai detaliat în articolele ulterioare.
Diagrame. UML oferă următoarele diagrame:
- Diagrame care descriu comportamentul sistemului:
- Diagrame de stare (diagrame de stare),
- Diagrame de activitate,
- Diagrame de obiecte,
- Diagrame secvențe,
- Diagrame de colaborare;
- Diagrame care descriu implementarea fizică a sistemului:
- Diagrame componente;
- Diagrame de implementare.
Vedere de control al modelului. Pachete.
Am spus deja că pentru ca un model să fie bine înțeles de către o persoană, este necesar să-l organizăm ierarhic, lăsând un număr mic de entități la fiecare nivel al ierarhiei. UML include un mijloc de organizare a unei reprezentări ierarhice a unui model - pachete. Orice model constă dintr-un set de pachete care pot conține clase, cazuri de utilizare și alte entități și diagrame. Un pachet poate include alte pachete, ceea ce vă permite să creați ierarhii. UML nu furnizează diagrame de pachete separate, dar acestea pot apărea în alte diagrame. Pachetul este afișat ca dreptunghi cu o filă.
Ce oferă UML.
- descrierea ierarhică a unui sistem complex prin evidențierea pachetelor;
- formalizarea cerințelor funcționale pentru sistem folosind aparatul de cazuri de utilizare;
- detalierea cerințelor pentru sistem prin construirea de diagrame de activități și scenarii;
- selectarea claselor de date și construirea unui model conceptual de date sub formă de diagrame de clase;
- selectarea claselor care descriu interfața cu utilizatorul și crearea unei scheme de navigare pe ecran;
- descrierea proceselor de interacțiune a obiectelor în îndeplinirea funcțiilor sistemului;
- descrierea comportamentului obiectelor sub formă de diagrame de activități și stări;
- descrierea componentelor software și interacțiunea acestora prin interfețe;
- descrierea arhitecturii fizice a sistemului.
Și ultimul…
În ciuda tuturor atractivității UML, ar fi dificil să-l folosești în modelarea PS reală fără instrumente de modelare vizuală. Astfel de instrumente vă permit să prezentați rapid diagrame pe ecranul de afișare, să le documentați, să generați spații libere de coduri de program în diferite limbaje de programare OO și să creați scheme de baze de date. Cele mai multe dintre ele includ posibilitatea de reinginerire a codurilor de program - restabilirea anumitor proiecții ale modelului PS prin analiza automată a codurilor sursă ale programelor, ceea ce este foarte important pentru a se asigura că modelul și codurile se potrivesc și atunci când se proiectează sisteme care moștenesc funcționalitatea sistemelor predecesoare. .
UML (Unified Modeling Language - unified modeling language) - un limbaj de descriere grafică pentru modelarea obiectelor în domeniul dezvoltării software. UML este un limbaj general, este un standard deschis care folosește notația grafică pentru a crea un model abstract al unui sistem, numit model UML. UML a fost creat pentru a defini, vizualiza, proiecta și documenta în principal sisteme software. UML nu este un limbaj de programare, dar generarea de cod este posibilă în instrumentele de rulare pentru modelele UML ca cod interpretat. Wikipedia
Produse Comerciale
Microsoft Visio
Tip: software comercial
Un produs software popular de la Microsoft care vă permite să desenați diagrame bogate, inclusiv UML:
Începând cu versiunea 2010, a devenit posibilă publicarea diagramelor pe web (SharePoint + Visio Services):
Visio Viewer- un program gratuit care vă permite să vizualizați diagrame Visio create anterior. Puteți descărca de la %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.
%0A
Microsoft%20Visual%20Studio%202010
%0A%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).
%0A
%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modelare,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.
%0A
%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Secvența%20Diagrama%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.
%0A%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Folosește%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:
%0A%0A%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Vizualizare%20și%20Modelare%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:
%0A- %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0 %0A
- %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrame%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagrame %0A
%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Vizualizarea%20și%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20
IBM Rational Rose
Oportunități:
- Diagrama cazurilor de utilizare (diagramele precedentelor);
- Diagrama de implementare (diagrame de topologie);
- Diagrama de stat (diagrame de stare);
- Diagrama de activitate (diagramele de activitate);
- Diagrama de interacțiune (diagrame de interacțiune);
- Diagrama secvenței (diagramele secvențelor de acțiuni);
- Diagrama de colaborare (diagramele de colaborare);
- Diagrama de clasă (diagramele de clasă);
- Diagrama componentelor (diagramele componentelor).
Capturi de ecran:
programe open source
StarUML
Oportunități:
- Suport UML 2.0
- MDA (Arhitectură condusă de model)
- Plug-in Architecture (puteți scrie în limbi compatibile COM: C++, Delphi, C#, VB, ...)
StarUML este scris în principal în Delphi, dar componentele pot fi adăugate și în alte limbaje, cum ar fi C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Mai jos sunt câteva capturi de ecran.
Diagrama de clasă:
Diagrama cazului de utilizare:
ArgoUML
Diagrame acceptate:
- clasă
- Stat
- cazuri de utilizare
- Activitate
- Colaborare
- Implementare
- Secvenţă
Oportunități:
- Suport pentru nouă diagrame UML 1.4
- Independent de platformă (Java 5+)
- Metamodelul standard UML 1.4
- Suport XMI
- Exportați în GIF, PNG, PS, EPS, PGML și SVG
- Limbi: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
- Suport OCL
- Înainte, inginerie inversă
Captură de ecran:
