Karakteristikat e përgjithshme të gjuhës UML. Llojet e diagrameve UML Llojet e diagrameve UML

Shënim: Lënda e këtij kursi është UML - Gjuha e Unifikuar e Modelimit. Ligjërata e mëparshme foli për atë që është UML, historinë e saj, qëllimin, mënyrat e përdorimit të gjuhës, strukturën e përkufizimit, terminologjinë dhe shënimin e saj. Është vërejtur se një model UML është një grup diagramesh. Në këtë leksion do të shqyrtojmë pyetjet e mëposhtme: pse nevojiten disa lloje diagramesh; llojet e diagrameve; OOP dhe sekuenca e diagramimit

Përpara se të kalojmë në diskutimin e materialit kryesor të këtij leksioni, le të flasim se pse duhet të ndërtojmë ndonjë diagram. Zhvillimi i një modeli të çdo sistemi (jo vetëm softuer) gjithmonë i paraprin krijimit ose përditësimit të tij. Kjo është e nevojshme të paktën për të imagjinuar më qartë problemin që zgjidhet. Modelet e mirëmenduara janë shumë të rëndësishme si për ndërveprimin brenda ekipit të zhvillimit ashtu edhe për mirëkuptimin e ndërsjellë me klientin. Në fund të fundit, kjo siguron që dizajni të jetë "konsistent arkitektonik" përpara se të zbatohet në kod.

Ne ndërtojmë modele të sistemeve komplekse sepse nuk mund t'i përshkruajmë plotësisht, "i hidhni një sy atyre". Prandaj, ne theksojmë vetëm vetitë e sistemit që janë thelbësore për një detyrë specifike dhe ndërtojmë modelin e tij që shfaq këto veti. Metoda e analizës së orientuar nga objekti na lejon të përshkruajmë sistemet reale komplekse në mënyrën më adekuate. Por ndërsa kompleksiteti i sistemeve rritet, lind nevoja për një teknologji të mirë modelimi. Siç kemi thënë tashmë në leksionin e mëparshëm, një unifikuar gjuha e modelimit(Unified Modeling Language, UML), e cila është një gjuhë grafike për specifikimin, vizualizimin, dizajnimin dhe dokumentimin e sistemeve. Duke përdorur UML, ju mund të zhvilloni një model të detajuar të sistemit që po krijohet, duke reflektuar jo vetëm konceptin e tij, por edhe veçoritë specifike të zbatimit të tij. Brenda modelit UML, të gjitha idetë rreth sistemit regjistrohen në formën e strukturave të veçanta grafike të quajtura diagrame.

shënim. Ne do të shqyrtojmë jo të gjitha, por vetëm disa nga llojet e diagrameve. Për shembull, diagrami i komponentëve nuk mbulohet në këtë leksion, i cili është vetëm një pasqyrë e shkurtër e llojeve të diagrameve. Numri i llojeve të diagrameve për një model specifik aplikimi nuk është i kufizuar në asnjë mënyrë. Për aplikime të thjeshta nuk ka nevojë të ndërtoni diagrame të të gjitha llojeve pa përjashtim. Disa prej tyre thjesht mund të mungojnë dhe ky fakt nuk do të konsiderohet si gabim. Është e rëndësishme të kuptohet se disponueshmëria e llojeve të caktuara të diagrameve varet nga specifikat e një projekti të caktuar. Informacioni për llojet e tjera të diagrameve (nuk diskutohet këtu) mund të gjendet në standardin UML.

Pse keni nevojë për disa lloje diagramesh

Së pari, le të përcaktojmë terminologjinë. Në hyrje të kësaj ligjërate ne kemi përdorur vazhdimisht konceptet e sistemit, modelit dhe diagramit. Autori është i bindur se secili prej nesh e kupton në mënyrë intuitive kuptimin e këtyre koncepteve, por për ta bërë plotësisht të qartë, le të shohim përsëri fjalorin dhe të lexojmë sa vijon:

Sistemi- një grup nënsistemesh të kontrolluara të ndërlidhura të bashkuara nga një qëllim i përbashkët operimi.

Po, jo shumë informuese. Çfarë është atëherë një nënsistem? Për të sqaruar situatën, le të kthehemi te klasikët:

Sistemi i referohet një grupi nënsistemesh të organizuara për të arritur një qëllim specifik dhe të përshkruara duke përdorur një grup modelesh, ndoshta nga këndvështrime të ndryshme.

Epo, nuk mund të bësh asgjë, do të duhet të kërkosh përkufizimin e një nënsistemi. Aty thotë edhe atë nënsistemështë një koleksion elementësh, disa prej të cilëve specifikojnë sjelljen e elementeve të tjerë. Ian Sommerville e shpjegon këtë koncept në këtë mënyrë:

Nënsistemiështë një sistem funksionimi i të cilit nuk varet nga shërbimet e nënsistemeve të tjera. Sistemi softuerik është i strukturuar si një koleksion nënsistemesh relativisht të pavarura. Përcaktohen gjithashtu ndërveprimet ndërmjet nënsistemeve.

Gjithashtu nuk është shumë e qartë, por është më mirë. Duke folur në gjuhën "njerëzore", sistemi përfaqësohet si një grup entitetesh më të thjeshta që janë relativisht të vetë-mjaftueshme. Kjo mund të krahasohet me mënyrën se si, në procesin e zhvillimit të një programi, ne ndërtojmë një ndërfaqe grafike nga "kube" standarde - komponentë vizualë, ose se si vetë teksti i programit ndahet gjithashtu në module që përmbajnë nënprograme, të bashkuara nga funksionaliteti, dhe ato mund të ripërdoret, në programet e mëposhtme.

Ne e kuptojmë konceptin e sistemit. Gjatë procesit të projektimit, sistemi merret parasysh nga këndvështrime të ndryshme me ndihmën e modeleve, paraqitjet e ndryshme të të cilave shfaqen në formën e diagrameve. Përsëri, lexuesi mund të ketë pyetje në lidhje me kuptimin e koncepteve modele Dhe diagramet. Ne mendojmë se është një përkufizim i bukur, por jo shumë i qartë modelet si një abstraksion semantikisht i mbyllur i sistemit Nuk ka gjasa të sqarojmë situatën, kështu që ne do të përpiqemi ta shpjegojmë "me fjalët tona".

Model- ky është një objekt i caktuar (material ose jo) që shfaq vetëm karakteristikat më domethënëse të sistemit për një detyrë të caktuar. Modelet janë të ndryshme - materiale dhe të paprekshme, artificiale dhe natyrore, dekorative dhe matematikore...

Le të japim disa shembuj. Makinat e lodrave plastike të njohura për të gjithë ne, me të cilat kemi luajtur me kaq emocione në fëmijëri, nuk janë asgjë më shumë se material dekorativ artificial modeli i një makine të vërtetë. Sigurisht, një "makinë" e tillë nuk ka motor, ne nuk e mbushim rezervuarin e saj me benzinë, dhe kutia e shpejtësisë nuk funksionon (në të vërtetë, nuk ka fare kuti ingranazhi), por si model kjo lodër përmbush plotësisht funksionet e saj. : i jep fëmijës një ide për makinën, pasi shfaq tiparet karakteristike të saj janë prania e katër rrotave, një karroce, dyer, dritare, aftësi për të drejtuar etj.

Në kërkimet mjekësore, testimi i kafshëve shpesh i paraprin sprovave klinike njerëzore. Në këtë rast, kafsha vepron si material natyral modelet njerëzore.

Ekuacioni i përshkruar më sipër është gjithashtu një model, por është një model matematik, dhe përshkruan lëvizjen e një pike materiale nën ndikimin e gravitetit.

Mbetet vetëm të thuhet se çfarë është një diagram. Diagramëështë një paraqitje grafike e shumë elementeve. Në mënyrë tipike përshkruhet si një grafik me kulme (entitete) dhe skaje (marrëdhënie). Ka shumë shembuj të diagrameve. Ky është një bllok diagram i njohur për të gjithë ne që nga vitet e shkollës, dhe diagrame instalimi për pajisje të ndryshme, të cilat mund t'i shohim në manualet e përdoruesit, dhe një pemë skedarësh dhe drejtorish në disk, të cilat mund t'i shohim duke ekzekutuar komandën e pemës në Konsola e Windows dhe shumë e shumë të tjera. Në jetën e përditshme, diagramet na rrethojnë nga të gjitha anët, sepse ne i perceptojmë vizatimet më lehtë sesa tekstin...

Por le të kthehemi te dizajni i softuerit (dhe më shumë). Në këtë industri me Diagramet mund të përdoren për të vizualizuar një sistem nga këndvështrime të ndryshme. Një nga diagramet, për shembull, mund të përshkruajë ndërveprimin e përdoruesit me sistemin, një tjetër mund të përshkruajë ndryshimin e gjendjeve të sistemit gjatë funksionimit të tij, i treti mund të përshkruajë ndërveprimin e elementeve të sistemit me njëri-tjetrin, etj. Një sistem kompleks mund dhe duhet të paraqitet si një grup modelesh të vogla dhe pothuajse të pavarura - diagrame, dhe asnjëra prej tyre nuk është e mjaftueshme për të përshkruar sistemin dhe për të marrë një pamje të plotë të tij, pasi secila prej tyre fokusohet në një aspekt specifik të funksionimit të sistemit dhe shpreh nje ndryshim niveli i abstraksionit. Me fjalë të tjera, çdo model korrespondon me një këndvështrim të caktuar, të veçantë mbi sistemin e projektuar.

Pavarësisht se në paragrafin e mëparshëm e trajtuam konceptin e një modeli shumë lirshëm, duhet kuptuar se në kontekstin e përcaktimeve të mësipërme. asnjë diagram individual nuk është model. Diagramet janë vetëm një mjet për të vizualizuar një model dhe të dy konceptet duhet të dallohen. Vetëm një grup diagramesh përbën një model sistemi dhe e përshkruan atë më plotësisht, por jo vetëm një diagram të nxjerrë jashtë kontekstit.

Llojet e tabelave

UML 1.5 e përcaktuar dymbëdhjetë lloje grafikësh, të ndarë në tre grupe:

• katër lloje diagramesh paraqesin strukturën statike të aplikacionit;
• pesë përfaqësojnë aspekte të sjelljes së sistemit;
• tre paraqesin aspektet fizike të funksionimit të sistemit (diagramet e zbatimit).

Versioni aktual i UML 2.1 nuk ka bërë shumë ndryshime. Diagramet kanë ndryshuar pak në pamje (janë shfaqur korniza dhe përmirësime të tjera vizuale), shënimi është përmirësuar pak dhe disa diagrame kanë marrë emra të rinj.

Megjithatë, numri i saktë diagramet kanonike për ne është absolutisht e parëndësishme, pasi ne do t'i konsiderojmë jo të gjitha, por vetëm disa - për arsye se numri i llojeve të diagrameve për një model specifik të një aplikacioni specifik nuk është fiksuar rreptësisht. Për aplikime të thjeshta nuk ka nevojë të ndërtohet çdo diagram i vetëm. Për shembull, për një aplikacion lokal nuk është e nevojshme të ndërtohet një diagram vendosjeje. Është e rëndësishme të kuptohet se lista e diagrameve varet nga specifikat e projektit që po zhvillohet dhe përcaktohet nga vetë zhvilluesi. Nëse lexuesi kureshtar ende dëshiron të dijë për të gjitha diagramet UML, ne do ta referojmë atë te standardi UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Ju kujtojmë se qëllimi i këtij kursi nuk është të përshkruajë absolutisht të gjitha aftësitë e UML, por vetëm të prezantojë këtë gjuhë dhe të japë një ide fillestare të kësaj teknologjie.

Pra, ne do të shikojmë shkurtimisht lloje të tilla diagramesh si:

• diagrami i rastit të përdorimit;
• diagrami i klasës;
• diagrami i objektit;
• diagrami i sekuencës;
• diagrami i ndërveprimit;
• diagrami i gjendjes;
• diagrami i aktivitetit;
• diagrami i vendosjes.

Për disa nga këto diagrame do të flasim më në detaje në ligjëratat e ardhshme. Tani për tani, ne nuk do të përqendrohemi në detaje, por do t'i vendosim vetes qëllimin që t'i mësojmë lexuesit të paktën vizualisht të dallojë llojet e diagrameve dhe të japim një ide fillestare të qëllimit të llojeve kryesore të diagrameve. Pra, le të fillojmë.

Përdor diagramin e rastit

Çdo sistem (përfshirë softuerin) është projektuar duke marrë parasysh faktin se gjatë funksionimit të tyre do të përdoren nga njerëzit dhe/ose do të ndërveprojnë me sisteme të tjera. Subjektet me të cilat sistemi ndërvepron gjatë funksionimit të tij quhen aktorët, dhe çdo aktor pret që sistemi të sillet në një mënyrë të përcaktuar rreptësisht, të parashikueshme. Le të përpiqemi të japim një përkufizim më të rreptë të një ektori. Për ta bërë këtë, ne do të përdorim një fjalor të mrekullueshëm vizual për UML Mentor Zicom:

Ektor (aktor)- ky është një grup rolesh të lidhura logjikisht që kryhen kur ndërveprojnë me precedentë ose entitete (sistem, nënsistem ose klasë). Një aktor mund të jetë një person ose një sistem tjetër, nënsistem ose klasë që përfaqëson diçka jashtë entitetit.

Grafikisht, ektori përshkruhet ose " njeri i vogël", të ngjashme me ato që kemi vizatuar si fëmijë, duke paraqitur anëtarë të familjes sonë, ose simboli i klasës me stereotipin përkatës, siç tregohet në foto. Të dyja format e paraqitjes kanë të njëjtin kuptim dhe mund të përdoren në diagrame. Forma “stereotipe” përdoret më shpesh për të përfaqësuar aktorët e sistemit ose në rastet kur një aktor ka veti dhe ato duhet të shfaqen (Fig. 2.1).

Një lexues i vëmendshëm mund të pyesë menjëherë: pse aktor dhe jo aktor? Ne jemi dakord, fjala "ektor" është pak e ashpër në veshët e popullit rus. Arsyeja pse themi këtë është e thjeshtë - ector rrjedh nga fjala veprim, që përkthehet do të thotë veprim. Përkthimi fjalë për fjalë i fjalës "ektor" është aktor- shumë i gjatë dhe i papërshtatshëm për t'u përdorur. Prandaj, ne do të vazhdojmë të flasim në këtë mënyrë.

Oriz. 2.1.

I njëjti lexues i vëmendshëm mund të ketë vënë re fjalën "precedent" duke ndezur përkufizimin e ektorit. Çfarë është ajo? Kjo pyetje do të na interesojë edhe më shumë nëse kujtojmë se tani po flasim diagrami i rastit të përdorimit. Kështu që,

Rasti i përdorimit- përshkrim i një aspekti të veçantë të sjelljes së sistemit nga këndvështrimi i përdoruesit (Butch).

Përkufizimi është mjaft i qartë dhe gjithëpërfshirës, ​​por mund të sqarohet më tej duke përdorur të njëjtin Mentor Zicom"om:

Rasti i përdorimit- një përshkrim i një grupi ngjarjesh të njëpasnjëshme (përfshirë opsionet) të kryera nga sistemi që çojnë në rezultatin e vëzhguar nga aktori. Një rast përdorimi përfaqëson sjelljen e një entiteti, duke përshkruar ndërveprimin midis aktorëve dhe sistemit. Një rast përdorimi nuk tregon "si" arrihet një rezultat i caktuar, vetëm "çfarë" është arritur.

Precedentët përcaktohen në një mënyrë shumë të thjeshtë - në formën e një elipse, brenda së cilës tregohet emri i saj. Rastet e përdorimit dhe aktorët janë të lidhur duke përdorur linja. Shpesh një figurë vizatohet në njërën skaj të rreshtit. 2.3

formimi i kërkesave të përgjithshme për sjelljen e sistemit të projektuar;

zhvillimi i një modeli konceptual të sistemit për detajimin e tij të mëvonshëm;

përgatitjen e dokumentacionit për ndërveprim me klientët dhe përdoruesit e sistemit.

Aktualisht, UML është një shënim standard për modelimin vizual të sistemeve softuerike, i miratuar nga konsorciumi i Object Managing Group (OMG) në vjeshtën e vitit 1997, i cili mbështetet nga shumë produkte CASE të orientuara nga objekti.

Standardi UML ofron grupin e mëposhtëm të diagrameve për modelim:

· Diagrami i rastit të përdorimit – për modelimin e proceseve të biznesit të një organizate ose ndërmarrjeje dhe përcaktimin e kërkesave për sistemin e informacionit që krijohet;

· Diagrami i klasës – për modelimin e strukturës statike të klasave të sistemit dhe lidhjeve ndërmjet tyre;

· diagramet e sjelljes së sistemit;

· diagramet e ndërveprimit;

· diagramet e sekuencës – për modelimin e procesit të mesazheve ndërmjet objekteve brenda një rasti përdorimi;

· Diagrami i bashkëpunimit – për modelimin e procesit të mesazheve ndërmjet objekteve brenda një rasti përdorimi;

· Diagrami i gjendjes – për modelimin e sjelljes së objekteve të sistemit gjatë kalimit nga një gjendje në tjetrën;

· Diagrami i aktivitetit – për modelimin e sjelljes së sistemit brenda kuadrit të rasteve të ndryshme të përdorimit, ose aktiviteteve të modelimit;

diagramet e zbatimit:

· diagramet e komponentëve – për modelimin e hierarkisë së komponentëve (nënsistemeve) të një sistemi informacioni;

· Diagrami i vendosjes – për modelimin e arkitekturës fizike të sistemit të projektuar të informacionit.

Në Fig. 1.1 paraqet një model të integruar të një sistemi informacioni, duke përfshirë diagramet kryesore që duhet të zhvillohen në këtë projekt kursi.

Oriz. 1. Modeli i integruar i një sistemi informacioni në shënimin UML

4.2. Përdor diagramin e rastit

Një rast përdorimi është një sekuencë veprimesh të kryera nga sistemi në përgjigje të një ngjarjeje të iniciuar nga një objekt i jashtëm (aktor). Një rast përdorimi përshkruan një ndërveprim tipik midis një përdoruesi dhe një sistemi. Në rastin më të thjeshtë, rasti i përdorimit përcaktohet në procesin e diskutimit me përdoruesin për funksionet që ai do të donte të zbatonte në këtë sistem informacioni. Në UML, një rast përdorimi përshkruhet si më poshtë:

Fig.2. Rasti i përdorimit

Një aktor është roli që një përdorues luan në lidhje me sistemin. Aktorët përfaqësojnë role, jo njerëz të veçantë apo tituj pune. Megjithëse ato përshkruhen si figura njerëzore të stilizuara në diagramet e rasteve të përdorimit, një aktor mund të jetë gjithashtu një sistem informacioni i jashtëm që ka nevojë për disa informacione nga ai sistem. Aktorët duhet të shfaqen në diagram vetëm nëse kanë nevojë për disa raste përdorimi. Në UML, aktorët përfaqësohen si forma:

Fig.3. Karakteri (aktor)

Aktorët ndahen në tre lloje kryesore:

· përdoruesit;

· sistemet;

· Sisteme të tjera që ndërveprojnë me këtë;

Koha bëhet aktor nëse nisja e ndonjë ngjarjeje në sistem varet prej saj.

4.2.1. Marrëdhëniet ndërmjet rasteve të përdorimit dhe aktorëve

Në UML, diagramet e rasteve të përdorimit mbështesin disa lloje marrëdhëniesh midis elementeve të diagramit:

· komunikimi

përfshirje (përfshirë),

· zgjatje (zgjatje),

· përgjithësim.

lidhje komunikimiështë marrëdhënia midis një rasti përdorimi dhe një aktori. Në UML, marrëdhëniet e komunikimit tregohen duke përdorur një lidhje me një drejtim (vijë e ngurtë).

Fig.4. Shembull i lidhjes së komunikimit

Aktivizo lidhjen përdoret në situata kur ka një pjesë të sjelljes së sistemit që përsëritet në më shumë se një rast përdorimi. Këto lidhje zakonisht përdoren për të modeluar një funksion të ripërdorshëm.

Komunikimi i zgjerimit përdoret për të përshkruar ndryshimet në sjelljen normale të një sistemi. Ai lejon që një rast përdorimi të përdorë funksionalitetin e një rasti tjetër përdorimi kur është e nevojshme.

Fig.5. Shembull i marrëdhënies së përfshirjes dhe zgjerimit

Lidhja e përgjithësimit tregon se disa aktorë ose klasa kanë veti të përbashkëta.

Fig.6. Shembull i lidhjes së përgjithësimit

4.3.

Diagramet e ndërveprimit të përshkruajë sjelljen e grupeve ndërvepruese të objekteve. Në mënyrë tipike, një diagram ndërveprimi mbulon sjelljen e objekteve brenda vetëm një rasti përdorimi. Një diagram i tillë shfaq një numër objektesh dhe mesazhe që ata shkëmbejnë me njëri-tjetrin.

Mesazhështë mjeti me të cilin një objekt dërgues i kërkon një objekti marrës të kryejë një nga operacionet e tij.

Mesazh informuesështë një mesazh që i siguron objektit marrës disa informacione për të përditësuar gjendjen e tij.

Kërkesë mesazh (pyetëse)është një mesazh që kërkon lëshimin e disa informacioneve rreth objektit marrës.

Mesazh imperativështë një mesazh që i kërkon objektit marrës të kryejë një veprim.

Ekzistojnë dy lloje të diagrameve të ndërveprimit: diagramet e sekuencës dhe diagramet e bashkëpunimit.

4.3.1. Diagramet e sekuencës

Diagrami i sekuencës pasqyron rrjedhën e ngjarjeve që ndodhin brenda një rasti të vetëm përdorimi.

Të gjithë aktorët (aktorët, klasat ose objektet) të përfshirë në një skenar të caktuar (rast përdorimi) tregohen në krye të diagramit. Shigjetat korrespondojnë me mesazhet e transmetuara midis një aktori dhe një objekti ose midis objekteve për të kryer funksionet e kërkuara.

Në një diagram sekuence, një objekt përshkruhet si një drejtkëndësh me një vijë vertikale me pika të tërhequr nga ai. Kjo linjë quhet litar shpëtimi i objektit . Ai përfaqëson një fragment të ciklit jetësor të një objekti në procesin e ndërveprimit.

Çdo mesazh përfaqësohet si një shigjetë midis vijave jetësore të dy objekteve. Mesazhet shfaqen sipas renditjes që shfaqen në faqe nga lart poshtë. Çdo mesazh është etiketuar me të paktën një emër mesazhi. Nëse dëshironi, mund të shtoni edhe argumente dhe disa informacione kontrolli. Ju mund të shfaqni vetë-delegimin - një mesazh që një objekt i dërgon vetes, me shigjetën e mesazhit që tregon të njëjtën linjë jetësore.

Oriz. 7. Shembull i një diagrami sekuence

4.3.2. Diagrami i bashkëpunimit

Diagramet e bashkëpunimit shfaqni rrjedhën e ngjarjeve brenda një skenari specifik (rast përdorimi). Mesazhet renditen sipas kohës, megjithëse diagramet e bashkëpunimit fokusohen më shumë në lidhjet midis objekteve. Një diagram bashkëpunimi paraqet të gjithë informacionin që është i pranishëm në një diagram sekuence, por një diagram bashkëpunimi përshkruan rrjedhën e ngjarjeve ndryshe. E bën më të lehtë të kuptosh lidhjet që ekzistojnë midis objekteve.

Në një diagram bashkëpunimi, ashtu si në një diagram sekuence, shigjetat përfaqësojnë mesazhet e shkëmbyera brenda një rasti të caktuar përdorimi. Sekuenca e tyre kohore tregohet duke numëruar mesazhet.

Oriz. 8. Shembull i një diagrami bashkëpunimi

4.4. Diagrami i klasës

4.4.1. Informacion i pergjithshem

Diagrami i klasës përcakton llojet e klasave të sistemit dhe llojet e ndryshme të lidhjeve statike që ekzistojnë ndërmjet tyre. Diagramet e klasave përshkruajnë gjithashtu atributet e klasave, operacionet e klasave dhe kufizimet që vendosen në marrëdhëniet midis klasave.

Diagrami i klasës në gjuhën UML është një grafik, nyjet e të cilit janë elementë të strukturës statike të projektit (klasat, ndërfaqet), dhe harqet janë marrëdhëniet midis nyjeve (shoqërimet, trashëgimia, varësitë).

Diagrami i klasës përshkruan elementet e mëposhtme:

· Paketa - një grup elementësh modeli të lidhur logjikisht me njëri-tjetrin;

· Klasa (klasë) - përshkrim i vetive të përbashkëta të një grupi objektesh të ngjashme;

· Ndërfaqja - një klasë abstrakte që specifikon një grup operacionesh që një objekt i një klase arbitrare të lidhur me një ndërfaqe të caktuar u ofron objekteve të tjera.

4.4.2. Klasa

Klasaështë një grup entitetesh (objektesh) që kanë veti të ngjashme, domethënë të dhëna dhe sjellje. Një përfaqësues individual i një klase quhet një objekt i klasës ose thjesht një objekt.

Sjellja e një objekti në UML i referohet çdo rregulli për ndërveprimin e një objekti me botën e jashtme dhe me të dhënat e vetë objektit.

Në diagrame, klasa përshkruhet si një drejtkëndësh me një kufi të fortë, i ndarë me vija horizontale në 3 seksione:

Seksioni i sipërm (seksioni i emrit) përmban emrin e klasës dhe veçori të tjera të përgjithshme (në veçanti, stereotipin).

Seksioni i mesëm përmban një listë të atributeve

Në fund është një listë e operacioneve të klasës që pasqyrojnë sjelljen e saj (veprimet e kryera nga klasa).

Asnjë nga seksionet e atributit dhe funksionimit mund të mos shfaqet (ose të dyja njëkohësisht). Për një seksion që mungon, nuk keni nevojë të vizatoni një vijë ndarëse ose në ndonjë mënyrë të tregoni praninë ose mungesën e elementeve në të.

Seksione shtesë, si përjashtimet, mund të futen sipas gjykimit të zbatimit specifik.

Oriz. 9. Shembull i diagramit të klasës

4.4.2.1.Stereotipet klasore

Stereotipet klasore janë një mekanizëm për ndarjen e klasave në kategori.

UML përcakton tre stereotipe të klasës kryesore:

Kufiri (kufiri);

Entitet (entitet);

Kontrolli.

4.4.2.2.Klasat kufitare

Klasat kufitare janë ato klasa që ndodhen në kufirin e sistemit dhe të gjithë mjedisit. Këto përfshijnë ekranet, raportet, ndërfaqet me harduerin (si printerët ose skanerët) dhe ndërfaqet me sisteme të tjera.

Për të gjetur klasat kufitare, duhet të ekzaminoni diagramet e rasteve të përdorimit. Çdo ndërveprim ndërmjet një aktori dhe një rasti përdorimi duhet të shoqërohet me të paktën një klasë kufitare. Është kjo klasë që lejon një aktor të ndërveprojë me sistemin.

4.4.2.3.Klasat e entitetit

Klasat e entitetit përmbajnë informacion të ruajtur. Ata kanë kuptimin më të madh për përdoruesit, dhe për këtë arsye emrat e tyre shpesh përdorin terma nga fusha e temës. Në mënyrë tipike, një tabelë krijohet në bazën e të dhënave për secilën klasë të entitetit.

4.4.2.4.Klasat e kontrollit

Klasat e kontrollit janë përgjegjëse për koordinimin e veprimeve të klasave të tjera. Në mënyrë tipike, çdo rast përdorimi ka një klasë kontrolli që kontrollon sekuencën e ngjarjeve për atë rast përdorimi. Klasa e menaxherit është përgjegjëse për koordinimin, por nuk ofron vetë ndonjë funksionalitet, pasi klasat e tjera nuk i dërgojnë shumë mesazhe. Në vend të kësaj, ai vetë dërgon shumë mesazhe. Një klasë menaxhere thjesht delegon përgjegjësinë te klasat e tjera, kjo është arsyeja pse shpesh quhet një klasë menaxhere.

Mund të ketë klasa të tjera kontrolli në sistem që janë të zakonshme për rastet e përdorimit të shumëfishtë. Për shembull, mund të ketë një klasë SecurityManager (menaxher sigurie) përgjegjëse për monitorimin e ngjarjeve të lidhura me sigurinë. Klasa TransactionManager është përgjegjëse për koordinimin e mesazheve që lidhen me transaksionet e bazës së të dhënave. Mund të ketë menaxherë të tjerë për të trajtuar elementë të tjerë të funksionimit të sistemit, të tilla si ndarja e burimeve, përpunimi i shpërndarë i të dhënave ose trajtimi i gabimeve.

Përveç stereotipeve të përmendura më lart, ju mund të krijoni tuajin.

4.4.2.5.Atributet

Një atribut është një element informacioni i lidhur me një klasë. Atributet ruajnë të dhënat e kapsuluara të klasës.

Për shkak se atributet përmbahen brenda një klase, ato janë të fshehura nga klasat e tjera. Për shkak të kësaj, mund t'ju duhet të specifikoni se cilat klasa kanë të drejtën për të lexuar dhe ndryshuar atributet. Kjo veti quhet dukshmëria e atributit.

Atributi mund të ketë katër vlera të mundshme për këtë parametër:

Publik (i përgjithshëm, i hapur). Kjo vlerë e dukshmërisë supozon se atributi do të jetë i dukshëm për të gjitha klasat e tjera. Çdo klasë mund të shikojë ose ndryshojë vlerën e një atributi. Sipas shënimit UML, një atribut i përbashkët paraprihet nga një shenjë "+".

Privat (i mbyllur, i fshehtë). Atributi përkatës nuk është i dukshëm për asnjë klasë tjetër. Një atribut privat shënohet me një shenjë “–” sipas shënimit UML.

I mbrojtur (i mbrojtur). Ky atribut është i disponueshëm vetëm për vetë klasën dhe pasardhësit e saj. Shënimi UML për një atribut të mbrojtur është shenja "#".

Paketa ose Zbatim (paketë). Supozon se atributi është i përbashkët, por vetëm brenda fushës së paketës së tij. Ky lloj dukshmërie nuk tregohet nga ndonjë ikonë e veçantë.

Me ndihmën e mbylljes ose sigurisë, është e mundur të shmanget një situatë ku vlera e një atributi ndryshon nga të gjitha klasat e sistemit. Në vend të kësaj, logjika për ndryshimin e atributit do të përmbahet në të njëjtën klasë si vetë atributi. Cilësimet e dukshmërisë që vendosni do të ndikojnë në kodin e krijuar.

4.4.2.6.Operacionet

Operacionet zbatojnë sjelljen e lidhur me një klasë. Një operacion ka tre pjesë: një emër, parametra dhe një lloj kthimi.

Parametrat janë argumentet e marra nga operacioni si hyrje. Lloji i kthimit i referohet rezultatit të operacionit.

Një diagram klasa mund të tregojë emrat e operacioneve dhe emrat e operacioneve së bashku me parametrat e tyre dhe llojin e kthimit. Për të zvogëluar ngarkesën në diagram, është e dobishme të tregohen vetëm emrat e operacioneve në disa prej tyre, dhe nënshkrimi i tyre i plotë në të tjerët.

Në UML, operacionet kanë shënimin e mëposhtëm:

Emri i operacionit (argumenti: lloji i të dhënave argumenti, argumenti2:lloji i të dhënave argument2,...): lloji i kthimit

Ekzistojnë katër lloje të ndryshme operacionesh për t'u marrë parasysh:

Operacionet e zbatimit;

Operacionet e Menaxhimit;

Operacionet e aksesit;

Operacione ndihmëse.

Operacionet e Zbatimit

Operacionet zbatuese zbatojnë disa funksione biznesi. Operacione të tilla mund të gjenden duke ekzaminuar diagramet e ndërveprimit. Ky lloj diagrami përqendrohet në funksionet e biznesit dhe çdo mesazh në diagram ka të ngjarë të krahasohet me një aktivitet implementues.

Çdo operacion zbatimi duhet të jetë lehtësisht i gjurmueshëm sipas kërkesës përkatëse. Kjo arrihet në faza të ndryshme të simulimit. Aktiviteti rrjedh nga mesazhi në diagramin e ndërveprimit, mesazhet vijnë nga një përshkrim i detajuar i rrjedhës së ngjarjeve që krijohet në bazë të rastit të përdorimit dhe ky i fundit krijohet në bazë të kërkesave. Aftësia për të gjurmuar të gjithë këtë zinxhir ju lejon të siguroheni që çdo kërkesë të zbatohet në kod dhe çdo pjesë e kodit zbaton disa kërkesa.

Operacionet e kontrollit

Operacionet e menaxherit kontrollojnë krijimin dhe shkatërrimin e objekteve. Ndërtuesit dhe destruktorët e klasave bëjnë pjesë në këtë kategori.

Operacionet e Qasjes

Atributet janë zakonisht private ose të mbrojtura. Megjithatë, klasat e tjera ndonjëherë duhet të shikojnë ose ndryshojnë vlerat e tyre. Ekzistojnë operacione aksesi për këtë qëllim. Kjo qasje bën të mundur përmbledhjen e sigurt të atributeve brenda një klase, duke i mbrojtur ato nga klasa të tjera, por duke lejuar ende akses të kontrolluar në to. Është standarde të krijohen operacione Get and Set për çdo atribut të klasës.

Operacione ndihmëse

Operacionet ndihmëse janë ato operacione të një klase që janë të nevojshme që ajo të kryejë përgjegjësitë e saj, por për të cilat klasat e tjera nuk duhet të dinë asgjë. Këto janë operacione private dhe të mbrojtura të klasës.

Për të identifikuar transaksionet, ndiqni këto hapa:

1. Mësoni diagramet e sekuencës dhe diagramet bashkëpunuese. Shumica e mesazheve në këto diagrame janë operacione implementimi. Mesazhet reflektuese do të jenë operacione ndihmëse.

2. Merrni parasysh operacionet e kontrollit. Ju mund të keni nevojë të shtoni konstruktorë dhe destruktorë.

3. Merrni parasysh operacionet e aksesit. Për çdo atribut të klasës me të cilën do të duhet të punojnë klasat e tjera, duhet të krijoni operacione Get and Set.

4.4.2.7.Lidhjet

Një marrëdhënie përfaqëson një marrëdhënie semantike midis klasave. Ai i jep një klase aftësinë për të mësuar rreth atributeve, operacioneve dhe marrëdhënieve të një klase tjetër. Me fjalë të tjera, që një klasë t'i dërgojë një mesazh një tjetri në një diagram sekuence ose diagramë bashkëpunuese, duhet të ketë një marrëdhënie midis tyre.

Ekzistojnë katër lloje të marrëdhënieve që mund të krijohen midis klasave: shoqatat, varësitë, grumbullimet dhe përgjithësimet.

Shoqata e Komunikimit

Asociacioni është një lidhje semantike midis klasave. Ato vizatohen në diagramin e klasës si një vijë e zakonshme.

Oriz. 10. Shoqata e Komunikimit

Shoqatat mund të jenë me dy drejtime, si në shembull, ose me një drejtim. Në UML, shoqatat dydrejtimshe vizatohen si një vijë e thjeshtë pa shigjeta ose me shigjeta në të dy anët. Një lidhje me një drejtim ka vetëm një shigjetë që tregon drejtimin e saj.

Drejtimi i lidhjes mund të përcaktohet duke ekzaminuar diagramet e sekuencës dhe diagramet bashkëpunuese. Nëse të gjitha mesazhet në to dërgohen vetëm nga një klasë dhe merren vetëm nga një klasë tjetër, por jo anasjelltas, ekziston një komunikim i njëanshëm midis këtyre klasave. Nëse të paktën një mesazh dërgohet në drejtim të kundërt, shoqata duhet të jetë e dyanshme.

Shoqatat mund të jenë refleksive. Lidhja refleksive përfshin një shembull të një klase që ndërvepron me shembuj të tjerë të së njëjtës klasë.

Varësia nga komunikimi

Marrëdhëniet e varësisë pasqyrojnë gjithashtu marrëdhëniet midis klasave, por ato janë gjithmonë të njëanshme dhe tregojnë se një klasë varet nga përkufizimet e bëra në një tjetër. Për shembull, klasa A përdor metoda të klasës B. Pastaj kur klasa B ndryshon, është e nevojshme të bëhen ndryshimet përkatëse në klasën A.

Një varësi përfaqësohet nga një vijë me pika e tërhequr midis dy elementeve të diagramit dhe elementi i ankoruar në fund të shigjetës thuhet se varet nga elementi i ankoruar në fillim të asaj shigjete.

Oriz. 11. Varësia nga komunikimi

Kur gjenerohet kodi për këto klasa, asnjë atribut i ri nuk do t'u shtohet atyre. Megjithatë, do të krijohen operatorë specifikë për gjuhën për të mbështetur komunikimin.

Grumbullimi i komunikimit

Grumbullimet janë një formë më e ngushtë shoqërimi. Grumbullimi është një lidhje midis së tërës dhe pjesës së saj. Për shembull, mund të keni një klasë të quajtur Makina, si dhe klasa si Motori, Gomat dhe klasa për pjesë të tjera të makinës. Si rezultat, një objekt i klasës Car do të përbëhet nga një objekt i klasës Engine, katër objekte Tyre, etj. Agregatimet vizualizohen si një vijë me një diamant pranë klasës, që është një numër i plotë:

Oriz. 11. Grumbullimi i komunikimit

Përveç grumbullimit të thjeshtë, UML prezanton një lloj grumbullimi më të fortë të quajtur përbërje. Sipas përbërjes, një objekt-pjesë mund t'i përkasë vetëm një tërësie të vetme, dhe, përveç kësaj, si rregull, cikli jetësor i pjesëve përkon me ciklin e tërësisë: ata jetojnë dhe vdesin me të. Çdo fshirje e tërësisë vlen për pjesët e saj.

Ky fshirje në kaskadë shpesh konsiderohet si pjesë e përkufizimit të agregimit, por nënkuptohet gjithmonë kur shumëfishimi i roleve është 1..1; për shembull, nëse është e nevojshme të fshihet një Klient, atëherë ky fshirje duhet të zbatohet edhe për Porositë (dhe, nga ana tjetër, për Linjat e Porosisë).

UML është një gjuhë modelimi grafik për qëllime të përgjithshme për specifikimin, vizualizimin, dizajnimin dhe dokumentimin e të gjitha objekteve të krijuara gjatë zhvillimit të sistemeve softuerike.

Ka shumë libra të mirë që përshkruajnë UML në detaje (ndonjëherë edhe me detaje të shkëlqyera), unë do të doja të mbledh në një vend konceptet bazë rreth diagrameve, entiteteve dhe lidhjeve midis tyre për rikujtim të shpejtë, diçka si një fletë mashtrimi.

Ky artikull përdor materiale nga librat: Ivanov D. Yu., Novikov F. A. Gjuha e unifikuar e modelimit UML Dhe Leonenkov. UML tutorial.

Së pari, le të vendosim për redaktorin. Në Linux, kam provuar redaktues të ndryshëm UML, mbi të gjitha më pëlqeu UMLet, megjithëse është i shkruar në Java, ai lëviz shumë shpejt dhe përmban shumicën e shablloneve të entitetit. Ekziston edhe ArgoUML, një redaktues UML ndër-platformë, i shkruar gjithashtu në Java, i cili është i pasur funksionalisht, por ngadalëson më shumë.

Unë u ndal në UMlet, instalojeni nën Arch Linux Dhe Ubuntu:

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

Në UML, të gjitha entitetet mund të ndahen në llojet e mëposhtme:

• strukturore;
• të sjelljes;
• grupimi;
• annotative;

Ekzistojnë katër lloje kryesore të marrëdhënieve të përdorura në UML:

Varësia- tregon se një ndryshim në një njësi të pavarur ndikon disi një njësi ekonomike të varur. Grafikisht, marrëdhënia e varësisë përshkruhet si një vijë me pika me një shigjetë të drejtuar nga entiteti i varur në atë të pavarur.

Shoqata- ndodh nëse një entitet lidhet drejtpërdrejt me një tjetër (ose me të tjerët - shoqata mund të jetë jo vetëm binar). Grafikisht, një shoqatë përshkruhet si një vijë e fortë me shtesa të ndryshme që lidhin entitete të lidhura.

Përgjithësimështë një marrëdhënie ndërmjet dy subjekteve, njëra prej të cilave është rast i veçantë (i specializuar) i tjetrit. Grafikisht, një përgjithësim përshkruhet si një vijë me një shigjetë trekëndore, të paplotësuar në fund, e drejtuar nga e veçanta (nënklasa) në të përgjithshmen (superklasa).

Zbatimet- Një marrëdhënie zbatimi tregon se një entitet është zbatim i një tjetri. Grafikisht, zbatimi përshkruhet si një vijë me pika me një shigjetë trekëndore të paplotësuar në fund, e drejtuar nga entiteti zbatues te entiteti që zbatohet.

NË UML 2 të përcaktuara 13 llojet e diagrameve. Sipas standardeve, çdo diagram duhet të ketë një kornizë me një drejtkëndësh (këndi i poshtëm djathtas i pjerrët) në këndin e sipërm majtas, i cili tregon identifikuesin (etiketën) e diagramit dhe titullin.

Diagrame për të përshkruar strukturën e një sistemi:

• Diagrami i komponentit (etiketa komponent);
• Diagrami i vendosjes, etiketa vendosjen);
• Diagrami i klasës (diagrami i klasës, etiketa klasës);
• Diagrami i objektit (etiketa Objekt);
• Diagrami i strukturës së përbërë, etiketa klasës);

Diagramet për paraqitjen e sjelljes së sistemit:

• Diagrami i sinkronizimit (diagrami i ndërveprimit, etiketa koha);
• Diagrami i aktivitetit (etiketa aktivitet);
• Diagrami i sekuencës, etiketa SD);
• Diagrami i komunikimit (etiketa comm);
• Diagrami i makinës së gjendjes, etiketa makinë shtetërore);
• Diagrami i pasqyrës së ndërveprimit, etiketa ndërveprim);

Diagramet dallohen:

• Përdor diagramin e rastit (diagrami i rastit të përdorimit, etiketa e rastit të përdorimit);
• Diagrami i paketës (diagrami i paketës, etiketa paketë);

Diagrami i përdorimit

Diagrami i përdorimit(diagrami i rastit të përdorimit) është përfaqësimi më i përgjithshëm i qëllimit funksional të sistemit.

Kur konsideroni një diagram të rastit të përdorimit si një model të një sistemi, mund ta lidhni atë me një model të kutisë së zezë. Çdo rast përdorimi përcakton një sekuencë veprimesh që duhet të kryhen nga sistemi i projektuar kur ai ndërvepron me aktorin përkatës.

Një diagram përdorimi përdor dy lloje të entiteteve bazë: rastet e përdorimit dhe aktorët, ndërmjet të cilëve vendosen llojet e mëposhtme bazë të marrëdhënieve.

Marrëdhënia e shoqatës- Kjo marrëdhënie specifikon se çfarë roli specifik luan një aktor kur ndërvepron me një shembull të rastit të përdorimit. Një marrëdhënie shoqëruese tregohet nga një vijë e fortë midis një aktori dhe një rasti përdorimi. Kjo linjë mund të ketë simbole shtesë, të tilla si një emër dhe një shumësi.

Marrëdhënia e zgjerimit- përcakton marrëdhënien ndërmjet rasteve të një rasti të veçantë përdorimi dhe një rasti më të përgjithshëm përdorimi, vetitë e të cilit përcaktohen në bazë të mënyrës se si këto instanca kombinohen së bashku. Kështu, nëse ka një lidhje shtrirjeje nga rasti i përdorimit A në rastin e përdorimit B, atëherë kjo do të thotë se vetitë e një shembulli të rastit të përdorimit B mund të zgjerohen për shkak të pranisë së vetive në rastin e përdorimit të zgjeruar A.

Një marrëdhënie zgjatimi midis rasteve të përdorimit tregohet nga një vijë me pika me një shigjetë (opsioni i marrëdhënies së varësisë) që tregon larg nga rasti i përdorimit që është një zgjatim i rastit të përdorimit origjinal.

Marrëdhënia e përgjithësimit shërben për të treguar faktin se një rast përdorimi A mund të përgjithësohet për të përdorur rastin B. Në këtë rast, opsioni A do të jetë një specializim i opsionit B. Në këtë rast, B quhet paraardhës ose prind i A, dhe opsioni A është një fëmijë i përdorimit të opsionit V.

Grafikisht, kjo marrëdhënie përfaqësohet nga një vijë e fortë me një shigjetë në formën e një trekëndëshi të hapur, që tregon rastin e përdorimit prind.

Një marrëdhënie përgjithësimi midis rasteve të përdorimit përdoret kur është e nevojshme të theksohet se rastet e përdorimit të fëmijëve kanë të gjitha atributet dhe sjelljen e rasteve të përdorimit të prindërve.

Marrëdhënia e përfshirjes ndërmjet dy rasteve të përdorimit tregon se disa sjellje të specifikuara për një rast përdorimi përfshihet si një komponent përbërës në sekuencën e sjelljeve të rastit tjetër të përdorimit.

Një marrëdhënie përfshirjeje e drejtuar nga rasti i përdorimit A në rastin e përdorimit B tregon se çdo shembull i rastit të përdorimit A përfshin vetitë funksionale të specifikuara për rastin e përdorimit B.

Grafikisht, kjo marrëdhënie tregohet nga një vijë me pika me një shigjetë (variant i marrëdhënies së varësisë) drejtuar nga rasti i përdorimit bazë në atë të përfshirë.

Diagrami i klasës

Diagrami i klasës(diagrami i klasës) është mënyra kryesore për të përshkruar strukturën statike të një sistemi.

Diagrami i klasës përdor një lloj entiteti kryesor: klasa (përfshirë raste të shumta të veçanta të klasave: ndërfaqe, lloje primitive, klasa shoqëruese, etj.), Ndërmjet të cilave vendosen llojet kryesore të mëposhtme të marrëdhënieve: varësitë, shoqatat, përgjithësimet, implementimet.

Marrëdhënia e varësisë në përgjithësi, tregon një lidhje semantike midis dy elementeve të modelit ose dy grupeve të këtyre elementeve, që nuk është një lidhje asocimi, përgjithësimi ose zbatimi. Një marrëdhënie varësie përdoret në një situatë ku disa ndryshime në një element model mund të kërkojnë një ndryshim në një element tjetër modeli që varet prej tij.

Një marrëdhënie varësie përfaqësohet grafikisht nga një vijë me pika midis elementeve përkatëse me një shigjetë në një skaj, me shigjetën që tregon nga klasa klient e varësisë në klasën e pavarur ose burimore.

Mund të ketë fjalë kyçe të veçanta (stereotipe) mbi shigjetën:

• "akses" - shërben për të treguar disponueshmërinë e atributeve publike dhe operacioneve të klasës burimore për klasat e klientit;
• "bind" - klasa e klientit mund të përdorë disa shabllone për parametrizimin e saj të mëvonshëm;
• "rrjedh" - atributet e klasës së klientit mund të llogariten nga atributet e klasës burimore;
• "import" - atributet publike dhe operacionet e klasës burimore bëhen pjesë e klasës së klientit, sikur të ishin deklaruar drejtpërdrejt në të;
• "përsosin" - tregon se klasa e klientit shërben si përsosje e klasës burimore për arsye historike kur informacione shtesë shfaqen gjatë rrjedhës së punës në projekt.

Marrëdhënia e shoqatës korrespondon me praninë e disa marrëdhënieve ndërmjet klasave. Kjo marrëdhënie tregohet nga një vijë e fortë me simbole të veçanta shtesë që karakterizojnë vetitë individuale të një shoqate të caktuar. Karaktere të veçanta shtesë mund të jenë emri i shoqatës, si dhe emrat dhe shumëzimet e klasave të roleve të shoqatës. Emri i shoqatës është një element opsional i përcaktimit të saj.

Marrëdhënia e grumbullimit ndodh ndërmjet disa klasave nëse njëra nga klasat përfaqëson një ent që përfshin entitete të tjera si përbërës. Përdoret për të përfaqësuar marrëdhëniet e sistemit të tipit "pjesë-e tërë".

Raporti i përbërjesështë një rast i veçantë i një relacioni grumbullimi. Kjo lidhje shërben për të nxjerrë në pah një formë të veçantë të relacionit "pjesë-tërësi", në të cilën pjesët përbërëse ndodhen në një farë kuptimi brenda tërësisë. Specifikimi i marrëdhënies ndërmjet tyre qëndron në faktin se pjesët nuk mund të veprojnë të veçuara nga e tëra, d.m.th., me shkatërrimin e së tërës, shkatërrohen të gjitha pjesët përbërëse të saj.

Marrëdhënia e përgjithësimitështë një marrëdhënie midis një elementi më të përgjithshëm (prindi ose paraardhësi) dhe një elementi më specifik ose më i specializuar (fëmijë ose pasardhës). Kur zbatohet në një diagram të klasës, kjo marrëdhënie përshkruan strukturën hierarkike të klasave dhe trashëgiminë e vetive dhe sjelljes së tyre. Kjo supozon se klasa pasardhëse ka të gjitha vetitë dhe sjelljen e klasës paraardhëse, dhe gjithashtu ka vetitë dhe sjelljen e saj që klasa paraardhës nuk i ka.

Diagrami i makinës

Diagrami i makinës(diagrami i makinës së gjendjes) ose diagrami i gjendjes në UML 1 (diagrami i grafikut të gjendjes) është një mënyrë për të përshkruar sjelljen në detaje në UML. Në thelb, diagramet e makinerive, siç sugjeron emri, janë një grafik i gjendjeve dhe tranzicioneve të një makine të gjendjes së fundme të ngarkuar me shumë detaje dhe detaje shtesë.

Një diagram i gjendjes përshkruan procesin e ndryshimit të gjendjeve të vetëm një klase, ose më saktë, një shembull të një klase të caktuar, d.m.th., ai modelon të gjitha ndryshimet e mundshme në gjendjen e një objekti specifik. Në këtë rast, një ndryshim në gjendjen e një objekti mund të shkaktohet nga ndikimet e jashtme nga objektet e tjera ose nga jashtë. Është për të përshkruar reagimin e një objekti ndaj ndikimeve të tilla të jashtme që përdoren diagramet e gjendjes.

Në një diagram automatik, përdoret një lloj entiteti kryesor - gjendje, dhe një lloj marrëdhëniesh - tranzicione, por për të dy janë përcaktuar shumë varietete, raste të veçanta dhe shënime shtesë. Automati paraqet aspektet dinamike të sistemit të modeluar në formën e një grafiku të drejtuar, kulmet e të cilit korrespondojnë me gjendjet, dhe harqet me kalimet.

Gjendja fillestareështë një rast i veçantë i një gjendjeje që nuk përmban asnjë veprim të brendshëm (pseudo-gjendje). Objekti është në këtë gjendje si parazgjedhje në kohën fillestare. Shërben për të treguar zonën grafike në diagramin e gjendjes nga e cila fillon procesi i ndryshimit të gjendjeve.

Final (përfundimtar) një shtet është një rast i veçantë i një shteti që gjithashtu nuk përmban asnjë veprim të brendshëm (pseudoshtete). Objekti do të jetë në këtë gjendje si parazgjedhje pasi makina të ketë përfunduar funksionimin e saj në momentin përfundimtar të kohës.

Diagrami i aktivitetit

Kur modeloni sjelljen e një sistemi që projektohet ose analizohet, bëhet e nevojshme jo vetëm të paraqitet procesi i ndryshimit të gjendjeve të tij, por edhe të detajohen veçoritë e zbatimit algoritmik dhe logjik të operacioneve të kryera nga sistemi.

Diagrami i aktivitetit(diagrami i aktivitetit) është një mënyrë tjetër për të përshkruar sjelljen që i ngjan vizualisht grafikut të mirë të rrjedhës së vjetër të një algoritmi. Përdoret për të modeluar procesin e kryerjes së operacioneve.

Përdorimi kryesor i diagrameve të aktiviteteve është vizualizimi i veçorive të zbatimit të operacioneve të klasës, kur është e nevojshme të paraqiten algoritme për zbatimin e tyre.

Një diagram aktiviteti përdor një lloj entiteti kryesor - veprim, dhe një lloj marrëdhënieje - tranzicione (transferime të kontrollit). Përdoren gjithashtu konstruksione të tilla si pirunët, bashkimet, lidhjet dhe degët. Rekomandohet të përdorni një folje me fjalë shpjeguese si emër të një veprimi të thjeshtë.

Diagrami i sekuencës

Diagrami i sekuencës(diagrami i sekuencës) është një mënyrë për të përshkruar sjelljen e një sistemi "duke përdorur shembuj".

Në fakt, një diagram sekuence është një regjistrim i protokollit të një sesioni specifik të sistemit (ose një fragment i një protokolli të tillë). Në programimin e orientuar nga objekti, gjëja më e rëndësishme në kohën e ekzekutimit është kalimi i mesazheve midis objekteve që komunikojnë. Është sekuenca e dërgimit të mesazhit që shfaqet në këtë diagram, pra emri.

Një diagram sekuence përdor një lloj entiteti bazë - shembuj të klasifikuesve ndërveprues (kryesisht klasa, komponentë dhe aktorë) dhe një lloj marrëdhënieje - lidhje përgjatë të cilave shkëmbehen mesazhet.

Llojet e mundshme të mesazheve (imazhi i marrë nga larin.in):

Diagrami i komunikimit

Diagrami i komunikimit(diagrami i komunikimit) - një mënyrë për të përshkruar sjelljen që është semantikisht ekuivalente me një diagram sekuence. Në fakt, ky është i njëjti përshkrim i sekuencës së shkëmbimit të mesazheve të rasteve ndërvepruese të klasifikuesve, i shprehur vetëm me mjete të tjera grafike.

Kështu, në diagramin e komunikimit, si dhe në diagramin e sekuencës, përdoret një lloj entiteti kryesor - shembuj të klasifikuesve ndërveprues dhe një lloj marrëdhëniesh - lidhje. Megjithatë, këtu theksi nuk vihet në kohën, por në strukturën e lidhjeve midis instancave specifike.

Diagrami i komponentit

Diagrami i komponentit(diagrami përbërës) - tregon marrëdhëniet ndërmjet moduleve (logjike ose fizike) që përbëjnë sistemin e modeluar.

Lloji kryesor i entiteteve në një diagram përbërës janë vetë komponentët, si dhe ndërfaqet përmes të cilave specifikohen marrëdhëniet ndërmjet komponentëve. Marrëdhëniet e mëposhtme zbatohen në një diagramë përbërëse:

• implementime ndërmjet komponentëve dhe ndërfaqeve (një komponent implementon një ndërfaqe);
• varësitë ndërmjet komponentëve dhe ndërfaqeve (komponenti përdor ndërfaqen);

Diagrami i vendosjes

Diagrami i vendosjes(diagrami i vendosjes), së bashku me shfaqjen e përbërjes dhe lidhjeve të elementeve të sistemit, tregon se si ato ndodhen fizikisht në burimet llogaritëse në kohën e ekzekutimit.

Një diagram i paraqitjes, krahasuar me një diagram përbërës, shton dy lloje entitetesh: një objekt, i cili është një zbatim i një komponenti dhe një nyje (mund të jetë ose një klasifikues që përshkruan llojin e nyjes ose një shembull specifik) dhe një marrëdhënie shoqëruese ndërmjet nyjeve, duke treguar se nyjet janë të lidhura fizikisht gjatë ekzekutimit.

Diagrami i objektit

Diagrami i objektit(diagrami i objektit) - është një shembull i një diagrami të klasës.

Një diagram objekti përdor një lloj entiteti kryesor: objektet (instancat e klasave), midis të cilave tregohen lidhje specifike (më shpesh raste të shoqatave). Diagramet e objekteve janë të një natyre ndihmëse - në fakt, këto janë shembuj (deponitë e memories, mund të thuhet) që tregojnë se cilat objekte janë të disponueshme dhe lidhjet midis tyre në një moment specifik të funksionimit të sistemit.

Diagrami i strukturës së brendshme(diagrami i strukturës së përbërë) përdoret për një paraqitje më të detajuar të klasifikuesve strukturorë, kryesisht klasave dhe komponentëve.

Një klasifikues strukturor përshkruhet si një drejtkëndësh me emrin e klasifikuesit në krye. Ka pjesë brenda. Mund të ketë disa pjesë. Pjesët mund të ndërveprojnë me njëra-tjetrën. Kjo tregohet duke përdorur lidhës të llojeve të ndryshme. Vendndodhja në kufirin e jashtëm të pjesës në të cilën lidhësi quhet port. Portet janë gjithashtu të vendosura në kufirin e jashtëm të klasifikuesit strukturor.

Diagrami i pasqyrës së ndërveprimit Një diagram i përgjithshëm i ndërveprimit është një lloj diagrami aktiviteti me një sintaksë të zgjeruar: elementët e një diagrami të përmbledhjes së ndërveprimit mund të jenë lidhje me përdorimet e ndërveprimit të përcaktuara nga diagramet e sekuencës.

Diagrami i kohës

Diagrami i kohës Diagrami i kohës është një formë e veçantë e diagramit të sekuencës që fokusohet në ndryshimin e gjendjeve të rasteve të ndryshme të klasifikuesit dhe sinkronizimin e tyre të kohës.

Diagrami i paketës

Diagrami i paketës(diagrami i paketës) është i vetmi mjet që ju lejon të menaxhoni kompleksitetin e vetë modelit.

Elementet kryesore të shënimit janë paketat dhe varësitë me stereotipe të ndryshme.

Modeli i marrëdhënies entitet (modeli ER)

Analoge diagramet e klasave(UML) ndoshta Modeli ER, i cili përdoret gjatë dizajnimit të bazave të të dhënave (modeli relacional).

Modeli i marrëdhënies entitet (ER-model) është një model i të dhënave që ju lejon të përshkruani diagramet konceptuale të një zone lëndore. Modeli ER përdoret në dizajnimin e bazës së të dhënave të nivelit të lartë (konceptual). Me ndihmën e tij, ju mund të identifikoni entitetet kryesore dhe të identifikoni lidhjet që mund të krijohen midis këtyre entiteteve. wikipedia

Çdo fragment i një zone lëndore mund të përfaqësohet si një grup entitetesh, midis të cilave ka një numër lidhjesh.

Konceptet themelore:

Thelbi(entitet) është një objekt që mund të identifikohet në një farë mënyre që e dallon atë nga objektet e tjera, për shembull, KLIENTI 777. Një entitet është në fakt një grup atributesh.

Komplet entiteti(bashkësi entiteti) - një grup entitetesh të të njëjtit lloj (që kanë të njëjtat veti).

Lidhje(marrëdhënie) është një lidhje e krijuar ndërmjet disa subjekteve.

Domeni(domain) - grup vlerash (domeni i përcaktimit) të atributit.

Ekzistojnë tre lloje të lidhjeve binare:

• nje pas nje- një shembull i vetëm i një entiteti të një klase shoqërohet me një shembull të vetëm të një entiteti të një klase tjetër, për shembull, HEAD - DEPARTMENT;
• 1 deri në N ose një në shumë- një shembull i vetëm i një entiteti të një klase shoqërohet me shumë instanca të një entiteti të një klase tjetër, për shembull, DEPARTAMENT - PUNONJËS;
• N tek M ose shumë për shumë- shumë instanca të një entiteti të një klase shoqërohen me shumë raste të një entiteti të një klase tjetër, për shembull, PUNONJËSI - PROJEKT;
Fjalori i koncepteve bazë në UML

Objekt- një entitet që është unik dhe përfshin gjendjen dhe sjelljen.

Klasa- përshkrimi i një grupi objektesh me atribute të përbashkëta që përcaktojnë gjendjen dhe operacionet që përcaktojnë sjelljen.

Ndërfaqja- një grup i emërtuar operacionesh që përcakton një grup shërbimesh që mund të kërkohen nga një konsumator dhe të ofrohen nga një ofrues shërbimi.

Bashkëpunimi- një grup objektesh që ndërveprojnë për të arritur një qëllim.

Aktori- një entitet i vendosur jashtë sistemit të modeluar dhe që ndërvepron drejtpërdrejt me të.

Komponenti- një pjesë modulare e sistemit me një grup të përcaktuar qartë të ndërfaqeve të kërkuara dhe të ofruara.

Artifakt- një element informacioni që përdoret ose gjenerohet gjatë procesit të zhvillimit të softuerit. Me fjalë të tjera, një artefakt është një njësi fizike e zbatimit që rrjedh nga një element model (si një klasë ose komponent).

Nyja- një burim kompjuterik në të cilin gjenden objektet dhe, nëse është e nevojshme, ekzekutohen.

Subjektet e sjelljes synojnë të përshkruajnë sjelljen. Ekzistojnë vetëm dy entitete kryesore të sjelljes: shteti dhe veprimi.

Shtetit- një periudhë në ciklin jetësor të një objekti, gjatë së cilës objekti plotëson një kusht të caktuar dhe kryen veprimtaritë e veta ose pret që të ndodhë ndonjë ngjarje.

Veprimi- llogaritje atomike primitive.

Makinëështë një paketë që përcakton shumë koncepte të nevojshme për të përfaqësuar sjelljen e entitetit të modeluar në formën e një hapësire diskrete me një numër të kufizuar gjendjesh dhe tranzicionesh.

Klasifikuesështë një përshkrues i një grupi objektesh të të njëjtit lloj.

Lexim shtesë

• Fowler M. UML. Bazat, Botimi i 3-të
• Buch G., Rambo D., Jacobson I. Gjuha UML. Udhëzues Përdorues

UML është një akronim që qëndron për Gjuhën e Unifikuar të Modelimit. Në fakt, është një nga teknikat më të njohura të modelimit të proceseve të biznesit dhe është një shënim standard ndërkombëtar për specifikimin, vizualizimin dhe dokumentimin e zhvillimit të softuerit. Përcaktuar nga Grupi i Menaxhimit të Objekteve, ai u shfaq si një rezultat i disa sistemeve shtesë të shënimeve UML dhe tani është bërë standardi de fakto për modelimin vizual. Parimi themelor i çdo programimi të orientuar nga objekti fillon me ndërtimin e një modeli.

UML u krijua si rezultat i kaosit që rrethon zhvillimin dhe dokumentacionin e softuerit. Në vitet 1990, kishte disa mënyra të ndryshme të të menduarit për sistemet softuerike. Kishte nevojë për një mënyrë më të unifikuar vizuale UML për të përfaqësuar këto sisteme, dhe si rezultat, ajo u zhvillua midis 1994 dhe 1996 nga tre inxhinierë softuerësh që punonin në Rational Software. Ai u miratua më vonë si standard në 1997 dhe mbetet i tillë edhe sot, me vetëm disa përditësime.

Në thelb, UML është një gjuhë modelimi me qëllim të përgjithshëm në fushën e zhvillimit të softuerit. Megjithatë, ajo tani ka gjetur rrugën e saj në dokumentimin e disa proceseve të biznesit ose rrjedhave të punës, të tilla si diagramet e aktivitetit. Një lloj diagramesh UML mund të përdoret si zëvendësim për diagramet e rrjedhës. Ato ofrojnë një mënyrë më të standardizuar për të modeluar rrjedhat e punës dhe një gamë të gjerë karakteristikash për të përmirësuar lexueshmërinë dhe efikasitetin.

Arkitektura bazohet në një meta-objekt, i cili përcakton bazën për krijimin e gjuhës UML. Është mjaft i saktë për të krijuar një aplikacion të tërë. UML plotësisht e ekzekutueshme mund të vendoset në platforma të shumta duke përdorur teknologji të ndryshme me të gjitha proceset gjatë ciklit të zhvillimit të softuerit.

UML synohet të jetë një gjuhë modelimi vizual e zhvilluar nga përdoruesi. Ai mbështet konceptet e zhvillimit të nivelit të lartë si strukturat, modelet dhe bashkëpunimi. UML është një grup elementësh të tillë si:

1. Deklarata të gjuhës programuese.
2. Aktorët - përshkruani rolin e luajtur nga përdoruesi ose ndonjë sistem tjetër që ndërvepron me objektin.
3. Veprimtaritë që duhet të kryhen për të përmbushur kontratën e punës dhe janë paraqitur në diagrame.
4. Një proces biznesi që përfshin një sërë detyrash që krijojnë një shërbim specifik për klientët, të vizualizuar nga një diagram i veprimeve të njëpasnjëshme.
5. Komponentët e softuerit logjik dhe të ripërdorshëm.

Diagramet UML ndahen në dy kategori. Lloji i parë përfshin shtatë lloje diagramesh që përfaqësojnë informacionin strukturor, i dyti - shtatë të tjerët, që përfaqësojnë llojet e përgjithshme të sjelljes. Këto diagrame përdoren për të dokumentuar arkitekturën e sistemeve dhe janë të përfshirë drejtpërdrejt në modelimin UML të sistemit.

Diagramet UML paraqiten si paraqitje statike dhe dinamike të modelit të sistemit. Pamja statike përfshin diagrame të klasës dhe përbërjes që nxjerrin në pah strukturën statike. Pamja dinamike përfaqëson ndërveprimin midis objekteve dhe ndryshimet në gjendjet e brendshme të objekteve duke përdorur diagramet e sekuencës, aktivitetit dhe gjendjes.

Një shumëllojshmëri e gjerë mjetesh modelimi UML janë në dispozicion për të thjeshtuar modelimin, duke përfshirë IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner dhe Dia.

Përdorimi i UML ka lloje të ndryshme si në dokumentacionin e zhvillimit të softuerit ashtu edhe në proceset e biznesit:

1. Skicë. Në këtë rast, diagramet UML përdoren për të përcjellë aspekte dhe karakteristika të ndryshme të sistemit. Megjithatë, kjo është vetëm një pamje e nivelit të lartë të sistemit dhe me shumë mundësi nuk do të përfshijë të gjitha detajet e nevojshme për të përfunduar projektin deri në fund.
2. Forward Design - Dizajni i skicimit bëhet përpara se aplikacioni të kodohet. Kjo është bërë për të marrë një pasqyrë më të mirë të sistemit ose rrjedhës së punës që përdoruesi po përpiqet të krijojë. Mund të identifikohen shumë probleme ose mangësi të projektimit, të cilat do të përmirësojnë shëndetin dhe mirëqenien e përgjithshme të projektit.
3. Dizajni i kundërt. Pasi të shkruhet kodi, diagramet UML shfaqen si një formë dokumentacioni për aktivitete, role, pjesëmarrës dhe rrjedha të ndryshme të punës.
4. Projekti. Në këtë rast, diagrami shërben si një dizajn i plotë që kërkon vetëm zbatimin aktual të sistemit ose softuerit. Kjo shpesh bëhet duke përdorur mjetet CASE (Mjetet e Inxhinierisë Softuerike të Ndihmuara me Kompjuter). Disavantazhi kryesor i përdorimit të mjeteve CASE është se ato kërkojnë një nivel të caktuar njohurish, trajnime të përdoruesve, si dhe menaxhim dhe staf.

UML nuk është një gjuhë programimi e pavarur si Java, C++ ose Python, por me mjetet e duhura mund të bëhet një gjuhë pseudo-programi UML. Për të arritur këtë qëllim, i gjithë sistemi duhet të dokumentohet në diagrame të ndryshme dhe, duke përdorur softuerin e duhur, diagramet mund të përkthehen drejtpërdrejt në kod. Kjo metodë mund të jetë e dobishme vetëm nëse koha e shpenzuar për vizatimin e diagrameve do të marrë më pak kohë sesa shkrimi i kodit aktual. Edhe pse UML u krijua për sistemet e modelimit, ajo ka gjetur disa aplikacione në fushat e biznesit.

Më poshtë është një shembull i një diagrami UML për modelimin e biznesit.

Një zgjidhje praktike do të ishte përfaqësimi vizual i rrjedhës së procesit për shitjet përmes teleshit përmes një diagrami aktiviteti. Nga momenti që porosia merret si hyrje deri në momentin kur porosia është përfunduar dhe jepet një dalje specifike.

Ekzistojnë disa lloje të diagrameve UML, dhe secila kryen një detyrë të ndryshme, pavarësisht nëse është zhvilluar para zbatimit ose pas, si pjesë e dokumentacionit. Dy kategoritë më të gjera, që mbulojnë të gjitha llojet e tjera, janë diagrami i sjelljes dhe diagrami i strukturës. Siç sugjeron emri, disa diagrame UML përpiqen të analizojnë dhe përshkruajnë strukturën e një sistemi ose procesi, ndërsa të tjerët përshkruajnë sjelljen e sistemit, pjesëmarrësit dhe komponentët e tij.

Llojet e ndryshme ndahen si më poshtë:

1. Jo të gjitha 14 llojet e ndryshme të diagrameve UML përdoren rregullisht gjatë dokumentimit të sistemeve dhe arkitekturave.
2. Parimi Pareto vlen edhe për përdorimin e diagrameve UML.
3. 20% e grafikëve përdoren nga zhvilluesit 80% të kohës.

Elementet më të përdorura në zhvillimin e softuerit janë:

• diagramet e përdorimit;
• diagramet e klasave;
• sekuencat.

Diagramet e aktivitetit janë diagramet më të rëndësishme UML për krijimin e modeleve të procesit të biznesit. Në zhvillimin e softuerit, ato përdoren për të përshkruar rrjedhën e aktiviteteve të ndryshme. Ato mund të jenë ose seriale ose paralele. Ato përshkruajnë objektet e përdorura, të konsumuara ose të prodhuara nga një aktivitet dhe marrëdhëniet midis aktiviteteve të ndryshme.

Të gjitha sa më sipër janë të rëndësishme për modelimin e proceseve të biznesit që çojnë nga njëri në tjetrin, pasi ato janë të ndërlidhura me një fillim dhe fund të qartë. Në mjedisin e biznesit, kjo quhet edhe hartëzimi i procesit të biznesit. Personazhet kryesore janë autori, redaktori dhe botuesi. Një shembull i UML është më poshtë. Kur një recensues shikon një draft dhe vendos se duhen bërë disa ndryshime. Autori më pas rishikon draftin dhe e kthen përsëri për të analizuar rishikimin.

Diagrami i përdorimit

Guri i themelit të sistemit - përdoret për të analizuar kërkesat e nivelit të sistemit. Këto kërkesa shprehen në raste të ndryshme përdorimi. Tre komponentët kryesorë të një diagrami UML janë:

1. Funksionale - paraqitet si raste përdorimi.
2. Një folje që përshkruan një veprim.
3. Aktorët - për të bashkëvepruar me sistemin. Roli i aktorit mund të jetë përdorues, organizata ose një aplikacion i jashtëm. Marrëdhëniet ndërmjet pjesëmarrësve përfaqësohen me shigjeta të drejta.

Për shembull, për një grafik të menaxhimit të inventarit. Në këtë rast, ekziston një pronar, një furnizues, një menaxher, një specialist i inventarit dhe një inspektor inventarizimi. Kontejnerët e rrumbullakët përfaqësojnë veprimet e kryera nga aktorët. Veprimet e mundshme: blerja dhe pagesa e aksioneve, kontrollimi i cilësisë së inventarit, kthimi i inventarit ose shpërndarja e tij.

Ky lloj diagrami është i përshtatshëm për të treguar sjellje dinamike midis pjesëmarrësve në një sistem, duke thjeshtuar paraqitjen e tij pa pasqyruar detajet e zbatimit.

E përkohshme

Diagramet e kohës UML përdoren për të përfaqësuar marrëdhëniet e objekteve ku fokusi varet nga koha. Nuk është interesante se si objektet ndërveprojnë ose ndryshojnë njëri-tjetrin, por përdoruesi dëshiron të imagjinojë se si objektet dhe subjektet veprojnë përgjatë një boshti kohor linear.

Çdo pjesëmarrës individual përfaqësohet përmes një linje shpëtimi, e cila në thelb është një linjë që formon faza ndërsa pjesëmarrësi individual lëviz nga një fazë në tjetrën. Fokusi është në kohëzgjatjen e kohës së ngjarjeve dhe ndryshimet që ndodhin në varësi të saj.

Përbërësit kryesorë të një diagrami kohor janë:

1. Lifeline është një anëtar individual.
2. Afati kohor i gjendjes - Një rrugë e vetme e jetës mund të kalojë nëpër gjendje të ndryshme brenda një procesi.
3. Një kufizim kohëzgjatjeje është një kufizim i intervalit kohor që përfaqëson kohëzgjatjen e kërkuar për të përmbushur kufizimin.
4. Kufiri kohor - kufizimi i intervalit kohor gjatë të cilit duhet të përfundojë diçka nga një pjesëmarrës.
5. Shfaqja e shkatërrimit - Shfaqja e një mesazhi që shkatërron një pjesëmarrës individual dhe përfaqëson fundin e ciklit jetësor të atij pjesëmarrësi.

Diagramet horizontale, të quajtura edhe diagramet e gjendjes, përdoren për të përshkruar gjendjet e ndryshme të një komponenti brenda një sistemi. Ai pranon një format të caktuar emri sepse një diagram është në thelb një makinë që përshkruan gjendjet e shumta të një objekti dhe se si ai ndryshon bazuar në ngjarjet e brendshme dhe të jashtme.

Një diagram shumë i thjeshtë i gjendjes së një makinerie do të ishte si një lojë shahu. Një lojë tipike shahu përbëhet nga lëvizjet e bëra nga Bardhi dhe lëvizjet e bëra nga Zi. Bardha ka lëvizjen e parë, e cila kështu nis lojën. Fundi i lojës mund të ndodhë pavarësisht nëse fiton Bardhi apo Zi. Loja mund të përfundojë me një ndeshje, një ndërprerje ose një barazim (gjendje të ndryshme të makinës). Grafikët e gjendjes përdoren kryesisht në dizajnimin e UML përpara dhe të kundërt të sistemeve të ndryshme.

Të njëpasnjëshme

Ky lloj diagrami është diagrami më i rëndësishëm UML jo vetëm në komunitetin e shkencave kompjuterike, por edhe si një model i nivelit të projektimit për zhvillimin e aplikacioneve të biznesit. Ato janë të njohura kur përshkruajnë proceset e biznesit për shkak të natyrës së tyre të vetëkuptueshme vizualisht. Siç sugjeron emri, diagramet përshkruajnë sekuencën e mesazheve dhe ndërveprimeve që ndodhin midis subjekteve dhe objekteve. Aktorët ose objektet mund të jenë aktivë vetëm kur është e nevojshme ose kur një objekt tjetër dëshiron të komunikojë me ta. Të gjitha komunikimet janë paraqitur në rend kronologjik.

Për informacion më të plotë, mund të merrni parasysh shembullin e diagramit të sekuencës UML më poshtë.

Siç sugjeron shembulli, diagramet e strukturës përdoren për të treguar strukturën e një sistemi. Më konkretisht, gjuha përdoret në zhvillimin e softuerit për të përfaqësuar arkitekturën e një sistemi dhe mënyrën se si komponentët e ndryshëm janë të ndërlidhur.

Një diagram i klasës UML është lloji më i zakonshëm i diagramit për dokumentacionin e softuerit. Meqenëse shumica e programeve të krijuara sot bazohen ende në paradigmën e programimit të orientuar nga objekti, përdorimi i diagrameve të klasave për të dokumentuar softuerin rezulton të jetë i arsyeshëm. Kjo është për shkak se OOP bazohet në klasat UML dhe marrëdhëniet midis tyre. Me pak fjalë, diagramet përmbajnë klasa, së bashku me atributet e tyre, të quajtura gjithashtu fusha të dhënash, dhe sjelljen e tyre, të quajtur funksione anëtare.

Më konkretisht, çdo klasë ka 3 fusha: emrin në krye, atributet pak poshtë emrit, operacionet/sjelljet në fund. Marrëdhënia midis klasave të ndryshme (e përfaqësuar nga një linjë lidhëse) përbën një diagram të klasës. Shembulli i mësipërm tregon një diagram të klasës bazë.

Objektet

Kur diskutoni diagramet e strukturës UML, duhet të thelloheni në konceptet e shkencës kompjuterike. Në inxhinierinë softuerike, klasat trajtohen si lloje abstrakte të të dhënave, ndërsa objektet janë instanca. Për shembull, nëse ekziston "Car", që është një lloj abstrakt i përgjithshëm, atëherë një shembull i klasës "Car" do të jetë "Audi".

Diagramet e objekteve UML ndihmojnë zhvilluesit e softuerit të kontrollojnë nëse struktura abstrakte e gjeneruar përfaqëson një strukturë të qëndrueshme kur zbatohet në praktikë, domethënë kur objektet instantohen. Disa zhvillues e konsiderojnë këtë një nivel dytësor të kontrollit të saktësisë. Ai shfaq shembuj të klasave. Më saktësisht, klasa gjenerike "Klient" tani ka një klient aktual, për shembull, të quajtur "James". James është një shembull i një klase më të përgjithshme dhe ka të njëjtat atribute, megjithatë, me vlera të dhëna. E njëjta gjë është bërë edhe me llogarinë e Llogarive dhe të Kursimeve. Ata janë të dy objekte të klasave të tyre përkatëse.

Vendosjet

Diagramet e vendosjes përdoren për të vizualizuar marrëdhënien midis softuerit dhe harduerit. Për të qenë më specifik, me diagramet e vendosjes, mund të ndërtoni një model fizik të mënyrës se si komponentët e softuerit (artefaktet) vendosen në komponentët e harduerit të njohur si nyje.

Një skemë tipike e thjeshtuar e vendosjes për një aplikacion në internet do të përfshijë:

1. Nyjet (serveri i aplikacionit dhe serveri i bazës së të dhënave).
2. Skema e objekteve të aplikacionit të klientit dhe bazës së të dhënave.

Diagrami i paketës është i ngjashëm me koleksionin makro për diagramet e vendosjes së UML që shpjeguam më sipër. Paketa të ndryshme përmbajnë nyje dhe objekte. Ata grupojnë diagramet dhe modelojnë komponentët në grupe, ashtu si hapësira e emrave përmbledh emra të ndryshëm që janë disi të lidhur. Në fund të fundit, një paketë mund të ndërtohet gjithashtu nga disa paketa të tjera për të përfaqësuar sisteme dhe sjellje më komplekse.

Qëllimi kryesor i një diagrami të paketës është të tregojë marrëdhëniet midis komponentëve të ndryshëm të mëdhenj që përbëjnë një sistem kompleks. Programuesit e shohin këtë veçori abstraksioni një përfitim të mirë për përdorimin e diagrameve të paketave, veçanërisht kur disa detaje mund të përjashtohen nga tabloja e madhe.

Si çdo gjë tjetër në jetë, për të bërë diçka siç duhet, ju nevojiten mjetet e duhura. Mjetet që ofrojnë shënime UML dhe shabllone diagramesh përdoren për të dokumentuar softuerët, proceset ose sistemet. Ka mjete të ndryshme dokumentacioni softuerësh që mund t'ju ndihmojnë të vizatoni diagramin.

Zakonisht ato ndahen në kategoritë kryesore të mëposhtme:

1. Letra dhe stilolapsi janë të lehta. Merrni letrën dhe stilolapsin, hapni kodin sintaksor UML nga Interneti dhe vizatoni çfarëdo lloj diagrami që ju nevojitet.
2. Mjetet në internet - Ka disa aplikacione në internet që mund t'i përdorni për të krijuar një grafik. Shumica e tyre ofrojnë një abonim me pagesë ose një numër të kufizuar grafikësh në nivelin falas.
3. Mjetet online falas janë pothuajse të njëjta me ato me pagesë. Dallimi kryesor është se ato me pagesë ofrojnë gjithashtu mësime dhe modele të gatshme për diagrame specifike.
4. Aplikacioni Desktop - Aplikacioni tipik i desktopit që përdoret për diagrame dhe pothuajse çdo diagram tjetër është Microsoft Visio. Ofron veçori dhe funksionalitet të avancuar. E vetmja pengesë është se ju duhet të paguani për të.

Kështu, është mjaft e qartë se UML është një aspekt i rëndësishëm i lidhur me zhvillimin e softuerit të orientuar nga objekti. Ai përdor shënimin grafik për të krijuar modele vizuale të programeve të sistemit.

Një diagram UML është një gjuhë e specializuar përshkrimi grafik e krijuar për modelimin e objekteve në zhvillimin e softuerëve të ndryshëm. Gjuha ka një profil të gjerë dhe është një standard i hapur që përdor shënime të ndryshme grafike për të krijuar një model abstrakt të një sistemi. UML u krijua për të mundësuar përcaktimin, vizualizimin, dokumentimin dhe dizajnimin e të gjitha llojeve të sistemeve softuerike. Vlen të theksohet se vetë diagrami UML nuk është një gjuhë programimi, por ofron mundësinë e gjenerimit të kodit të veçantë bazuar në të.

Pse është e nevojshme?

Përdorimi i UML nuk përfundon me modelimin e të gjitha llojeve të softuerit. Gjithashtu, kjo gjuhë përdoret në mënyrë aktive sot për modelimin e proceseve të ndryshme të biznesit, kryerjen e dizajnit të sistemit, si dhe shfaqjen e strukturave organizative.

Me UML, zhvilluesit e softuerit mund të sigurojnë marrëveshje të plotë në shënimin grafik të përdorur për të përfaqësuar konceptet e zakonshme si: komponenti, gjenerik, klasa, sjellja dhe grumbullimi. Për shkak të kësaj, arrihet një shkallë më e madhe e përqendrimit në arkitekturë dhe dizajn.

Vlen gjithashtu të përmendet se ekzistojnë disa lloje të tabelave të tilla.

Diagrami i klasës

Një diagram i klasës UML është një diagram strukturor statik i krijuar për të përshkruar strukturën e një sistemi, si dhe për të treguar atributet, metodat dhe varësitë midis disa klasave të ndryshme.

Vlen të përmendet fakti se ekzistojnë disa këndvështrime për ndërtimin e diagrameve të tilla, në varësi të mënyrës se si do të përdoren:

• Konceptuale. Në këtë rast, diagrami i klasës UML përshkruan modelin e një zone specifike lëndore dhe ofron vetëm klasa të objekteve të aplikimit.
• Specifike. Diagrami përdoret në procesin e projektimit të sistemeve të ndryshme të informacionit.
• Zbatimi. Diagrami i klasës përfshin të gjitha llojet e klasave që përdoren drejtpërdrejt në kodin e programit.

Diagrami i komponentit

Një diagram i komponentit UML është një diagram strukture plotësisht statike. Ai synon të demonstrojë ndarjen e një sistemi të caktuar softuerësh në komponentë të ndryshëm strukturorë, si dhe lidhjet midis tyre. Një diagram i komponentit UML mund të përdorë të gjitha llojet e modeleve, bibliotekave, skedarëve, paketave, ekzekutuesve dhe shumë elementë të tjerë si të tillë.

Diagrami i strukturës së përbërë/përbërë

Një diagram strukturë e përbërë/përbërëse UML është gjithashtu një diagram strukture statike, por përdoret për të treguar strukturën e brendshme të klasave. Nëse është e mundur, ky diagram mund të demonstrojë gjithashtu ndërveprimin e elementeve të vendosura në strukturën e brendshme të klasës.

Një nënlloj i tyre është diagrami i bashkëpunimit UML, i cili përdoret për të demonstruar rolet, si dhe ndërveprimin e klasave të ndryshme brenda kufijve të bashkëpunimit. Ata janë mjaft të përshtatshëm nëse keni nevojë të modeloni modele të projektimit.

Vlen të përmendet se pamjet e klasës UML dhe të diagramit të strukturës së përbërë mund të përdoren njëkohësisht.

Diagrami i vendosjes

Ky diagram përdoret për të modeluar nyjet e funksionimit, si dhe të gjitha llojet e objekteve që janë vendosur në to. Në UML 2, artefaktet vendosen në nyje të ndryshme, ndërsa në versionin e parë, vetëm komponentët u vendosën. Kështu, diagrami i vendosjes së UML përdoret kryesisht për versionin e dytë.

Një varësi manifestimi formohet midis artefaktit dhe komponentit që ai zbaton.

Diagrami i objektit

Kjo pamje ju lejon të shihni një pamje të plotë ose të pjesshme të sistemit që krijohet në një moment të caktuar kohor. Ai shfaq plotësisht të gjitha rastet e klasave të një sistemi të caktuar, duke treguar vlerat aktuale të parametrave të tyre, si dhe lidhjet midis tyre.

Diagrami i paketës

Ky diagram ka natyrë strukturore dhe përmbajtja kryesore e tij janë të gjitha llojet e paketave, si dhe marrëdhëniet ndërmjet tyre. Në këtë rast, nuk ka një ndarje të rreptë midis disa diagrameve strukturore, si rezultat i të cilave përdorimi i tyre më së shpeshti gjendet vetëm për lehtësi dhe nuk ka ndonjë kuptim semantik. Vlen të përmendet se elementë të ndryshëm mund të ofrojnë diagrame të tjera UML (shembuj: vetë paketat dhe diagramet e paketave).

Përdorimi i tyre kryhet për të siguruar organizimin e disa elementeve në grupe sipas një kriteri të caktuar për të thjeshtuar strukturën, si dhe për të organizuar punën me modelin e një sistemi të caktuar.

Diagrami i aktivitetit

Një diagram aktiviteti UML përshkruan zbërthimin e një aktiviteti specifik në disa pjesë përbërëse. Në këtë rast, koncepti i "aktivitetit" është specifikimi i një sjelljeje të caktuar të ekzekutueshme në formën e ekzekutimit paralel, si dhe të koordinuar vijues të elementëve të ndryshëm vartës - llojeve të mbivendosura të aktiviteteve dhe veprimeve të ndryshme, të bashkuara nga flukset që shkojnë nga rezultatet. të një nyje të caktuar në hyrjet e një tjetri.

Diagramet e aktivitetit UML shpesh përdoren për të modeluar procese të ndryshme biznesi, llogaritje paralele dhe sekuenciale. Ndër të tjera, ato simulojnë të gjitha llojet e procedurave teknologjike.

Diagrami i makinës

Ky lloj quhet edhe pak më ndryshe - diagrami i gjendjes UML. Ajo ka një makinë të paraqitur me gjendje të fundme me gjendje të thjeshta dhe të përbëra, si dhe me tranzicione.

Një makinë gjendje është një specifikim i një sekuence të gjendjeve të ndryshme përmes të cilave kalon një objekt i caktuar, ose ndërveprim, si përgjigje ndaj ngjarjeve të caktuara në jetën e tij, si dhe reagimi i objektit ndaj ngjarjeve të tilla. Një makinë gjendjeje që përdor një diagram të gjendjes UML është bashkangjitur në një element burimor dhe përdoret për të përcaktuar sjelljen e instancave të tij.

Të ashtuquajturat diagrame të dragoit mund të përdoren si analoge të diagrameve të tilla.

Përdorni diagramet e rasteve

Një diagram rasti i përdorimit të UML përshkruan të gjitha marrëdhëniet që ndodhin midis aktorëve, si dhe rastet e ndryshme të përdorimit. Detyra e tij kryesore është të sigurojë një mjet të plotë përmes të cilit klienti, përdoruesi përfundimtar ose çdo zhvillues mund të diskutojnë së bashku sjelljen dhe funksionalitetin e një sistemi të caktuar.

Nëse një diagram rasti i përdorimit të UML përdoret në procesin e modelimit të sistemit, atëherë analisti do të:

• Ndani qartë sistemin që modelohet nga mjedisi i tij.
• Identifikoni aktorët, mënyrat e ndërveprimit të tyre me këtë sistem, si dhe funksionalitetin e pritshëm të tij.
• Vendosni në fjalor si fushë lëndore koncepte të ndryshme që lidhen me një përshkrim të detajuar të funksionalitetit të një sistemi të caktuar.

Nëse një diagram përdorimi zhvillohet në UML, procedura fillon me një përshkrim teksti, i cili merret kur punoni me klientin. Vlen të përmendet fakti se kërkesa të ndryshme jofunksionale janë hequr plotësisht në procesin e hartimit të një modeli të rastit të përdorimit dhe për to do të gjenerohet një dokument i veçantë.

Komunikimet

Një diagram komunikimi, ashtu si diagrami i sekuencës UML, është kalimtar, domethënë shpreh ndërveprim, por në të njëjtën kohë e demonstron atë në mënyra të ndryshme dhe, nëse është e nevojshme, mund të konvertohet nga njëri në tjetrin me shkallën e kërkuar të saktësisë. .

Diagrami i komunikimit pasqyron ndërveprimet që ndodhin midis elementëve të ndryshëm të strukturës së përbërë, si dhe rolet e bashkëpunimit. Dallimi kryesor midis tij dhe një diagrami të sekuencës është se ai i bën marrëdhëniet midis disa elementeve mjaft të qarta dhe nuk e përdor kohën si një dimension të veçantë.

Ky lloj dallohet nga një format absolutisht i lirë për rregullimin e disa objekteve dhe lidhjeve në të njëjtën mënyrë siç bëhet në një diagram objekti. Nëse ka nevojë për të ruajtur rendin e mesazheve në këtë format falas, ato numërohen në mënyrë kronologjike. Leximi i këtij diagrami fillon me mesazhin fillestar 1.0, dhe më pas vazhdon në drejtimin në të cilin mesazhet transmetohen nga një objekt në tjetrin.

Në pjesën më të madhe, këto diagrame tregojnë saktësisht të njëjtin informacion që na ofron një diagram sekuence, por për shkak se ai përdor një mënyrë të ndryshme të paraqitjes së informacionit, disa gjëra në një diagram bëhen shumë më të lehta për t'u identifikuar sesa në një tjetër. Vlen gjithashtu të theksohet se një diagram komunikimi tregon më qartë se me cilat elemente ndërvepron secili element individual, ndërsa diagrami i sekuencës tregon më qartë se në çfarë rendi ndodhin ndërveprimet.

Diagrami i sekuencës

Një diagram i sekuencës UML tregon ndërveprimet midis objekteve të shumta që janë renditur sipas kohës që ndodhin. Ky diagram tregon ndërveprimin e renditur sipas kohës midis disa objekteve. Në veçanti, ai shfaq të gjitha objektet që marrin pjesë në ndërveprim, si dhe sekuencën e plotë të mesazheve të shkëmbyera ndërmjet tyre.

Elementet kryesore në këtë rast janë emërtimet e objekteve të ndryshme, si dhe linjat vertikale që përshkruajnë kalimin e kohës dhe drejtkëndëshat që përfaqësojnë veprimtarinë e një objekti të caktuar ose kryerjen e ndonjë funksioni.

Diagrami i bashkëpunimit

Ky lloj diagrami ju lejon të demonstroni ndërveprimet midis disa objekteve, duke u abstraguar nga sekuenca e përkthimit të mesazhit. Ky lloj diagrami shfaq në një formë kompakte absolutisht të gjitha mesazhet e transmetuara dhe të marra të një objekti të caktuar, si dhe formatet e këtyre mesazheve.

Për shkak se diagramet e sekuencës dhe komunikimit janë thjesht pamje të ndryshme të të njëjtave procedura, Rational Rose ofron mundësinë për të krijuar një diagram komunikimi nga një diagram sekuence ose anasjelltas, dhe gjithashtu i sinkronizon ato plotësisht automatikisht.

Diagramet e pasqyrës së ndërveprimit

Këto janë diagrame UML që janë një lloj diagrami i aktivitetit dhe përfshijnë elementët e Sekuencës dhe konstruksionet e rrjedhës së kontrollit.

Vlen të përmendet fakti se ky format kombinon diagramin e Bashkëpunimit dhe Sekuencës, të cilat ofrojnë mundësinë për të shqyrtuar ndërveprimin midis disa objekteve në sistemin që formohen nga këndvështrime të ndryshme.

Diagrami i kohës

Përfaqëson një version alternativ të një diagrami sekuence që tregon në mënyrë eksplicite ndryshimin e gjendjes përgjatë një linje shpëtimi në një shkallë të caktuar kohore. Mund të jetë mjaft i dobishëm në aplikacione të ndryshme në kohë reale.

Cilat janë avantazhet?

Vlen të përmendet disa avantazhe që dallojnë diagramin e përdorimit të UML dhe të tjerët:

• Gjuha është e orientuar nga objekti, si rezultat i së cilës teknologjitë për përshkrimin e rezultateve të analizës dhe dizajnit janë semantikisht afër metodave të programimit në të gjitha llojet e gjuhëve moderne të orientuara nga objekti.
• Duke përdorur këtë gjuhë, një sistem mund të përshkruhet pothuajse nga çdo këndvështrim i mundshëm, dhe aspekte të ndryshme të sjelljes së tij përshkruhen në të njëjtën mënyrë.
• Të gjitha diagramet janë relativisht të lehta për t'u lexuar edhe pas një prezantimi relativisht të shpejtë në sintaksën e tij.
• UML ju lejon të zgjeroni dhe gjithashtu të prezantoni stereotipet tuaja grafike dhe tekstuale, gjë që promovon përdorimin e saj jo vetëm në inxhinierinë e softuerit.
• Gjuha është bërë mjaft e përhapur dhe gjithashtu po zhvillohet mjaft aktivisht.

Të metat

Përkundër faktit se ndërtimi i diagrameve UML ka shumë përparësi, ato shpesh kritikohen për disavantazhet e mëposhtme:

• Teprica. Në shumicën dërrmuese të rasteve, kritikët thonë se UML është shumë e madhe dhe komplekse, dhe kjo shpesh është e pajustifikuar. Ai përfshin mjaft dizajne dhe diagrame të tepërta ose praktikisht të padobishme, dhe më së shpeshti një kritikë e tillë i drejtohet versionit të dytë, jo të parës, sepse rishikimet më të reja përmbajnë më shumë kompromise "të dizajnuara nga komiteti".
• Pasaktësi të ndryshme në semantikë. Për shkak se UML përcaktohet nga një kombinim i vetvetes, anglishtja dhe OCL, ajo nuk ka ngurtësinë që është e natyrshme në gjuhët e përcaktuara saktësisht nga teknikat formale të përshkrimit. Në situata të caktuara, sintaksa abstrakte e OCL, UML dhe angleze fillon të kundërshtojë njëra-tjetrën, ndërsa në raste të tjera ato janë të paplota. Pasaktësia në specifikimin e gjuhës në vetvete ndikon njësoj si përdoruesit ashtu edhe shitësit e mjeteve, duke çuar përfundimisht në papajtueshmëri të mjeteve për shkak të mënyrës unike të trajtimit të specifikimeve të ndryshme.
• Probleme në procesin e zbatimit dhe studimit. Të gjitha çështjet e mësipërme krijojnë sfida në zbatimin dhe mësimin e UML, veçanërisht kur menaxhimi i detyron inxhinierët ta përdorin atë pa njohuri paraprake.
• Kodi pasqyron kodin. Një mendim tjetër është se nuk janë të rëndësishme modelet e bukura dhe tërheqëse, por vetë sistemet e punës, domethënë kodi është projekti. Sipas kësaj pikëpamjeje, ekziston nevoja për të zhvilluar një mënyrë më efikase të shkrimit të softuerit. UML zakonisht vlerësohet në qasjet që përpilojnë modele për të rigjeneruar kodin e ekzekutueshëm ose burim. Por në realitet, kjo mund të mos jetë e mjaftueshme, sepse gjuhës i mungojnë vetitë e plotësisë Turing dhe çdo kod i gjeneruar përfundimisht do të kufizohet në atë që mjeti interpretues UML mund të hamendësojë ose përcaktojë.
• Mospërputhja e ngarkesës. Ky term vjen nga teoria e analizës së sistemeve për të përcaktuar paaftësinë e hyrjes së një sistemi të caktuar për të perceptuar një produkt tjetër. Ashtu si me çdo shënim standard, UML mund të përfaqësojë disa sisteme në mënyrë më efikase dhe koncize se të tjerët. Kështu, zhvilluesi është më i prirur drejt atyre zgjidhjeve që janë më të rehatshme për të ndërthurur të gjitha pikat e forta të UML, si dhe gjuhë të tjera programimi. Ky problem është më i dukshëm nëse gjuha e zhvillimit nuk përputhet me parimet themelore të ortodoksisë së orientuar nga objekti, domethënë nuk përpiqet të funksionojë në përputhje me parimet e OOP.
• Përpiqet të jetë universal. UML është një gjuhë modelimi për qëllime të përgjithshme që përpiqet të jetë e përputhshme me çdo gjuhë përpunimi të disponueshme sot. Në kontekstin e një projekti të caktuar, në mënyrë që ekipi i projektimit të arrijë qëllimin përfundimtar, është e nevojshme të përzgjidhen veçoritë e zbatueshme të asaj gjuhe. Për më tepër, mënyrat e mundshme për të kufizuar shtrirjen e UML-së në një zonë të caktuar janë përmes një formalizmi që nuk është plotësisht i artikuluar dhe i cili në vetvete është subjekt i kritikave.

Kështu, përdorimi i kësaj gjuhe nuk është i rëndësishëm në të gjitha situatat.