Pangkalahatang katangian ng wikang UML. Mga pangunahing diagram ng UML Ang mga uri ng linya ay ginagamit sa mga diagram ng uml

Ang UML na ngayon ang karaniwang notasyon para sa visual na pagmomodelo ng mga software system, na pinagtibay ng Object Managing Group (OMG) noong taglagas ng 1997, at sinusuportahan ng maraming produktong CASE na nakatuon sa object.

Ang pamantayan ng UML ay nag-aalok ng sumusunod na hanay ng mga diagram para sa pagmomodelo:

· Use case diagram - para sa pagmomodelo ng mga proseso ng negosyo ng isang organisasyon o negosyo at pagtukoy ng mga kinakailangan para sa sistema ng impormasyon na nilikha;

· Class diagram (class diagram) - para sa pagmomodelo ng static na istraktura ng mga klase ng system at ang mga koneksyon sa pagitan ng mga ito;

Mga diagram ng pag-uugali

· Mga diagram ng pakikipag-ugnayan;

· Mga sequence diagram - upang gayahin ang proseso ng pagpapalitan ng mga mensahe sa pagitan ng mga bagay sa loob ng iisang use case;

· Collaboration diagram - para sa pagmomodelo ng proseso ng pagmemensahe sa pagitan ng mga bagay sa loob ng isang use case;

· Statechart diagram - para sa pagmomodelo ng pag-uugali ng mga bagay ng system sa panahon ng paglipat mula sa isang estado patungo sa isa pa;

· Activity diagram - para sa pagmomodelo ng gawi ng system sa balangkas ng iba't ibang kaso ng paggamit, o mga aktibidad sa pagmomodelo;

Mga diagram ng pagpapatupad:

Component diagram - upang imodelo ang hierarchy ng mga bahagi (subsystems) ng isang sistema ng impormasyon;

· Deployment diagram - upang imodelo ang pisikal na arkitektura ng dinisenyong sistema ng impormasyon.

Sa fig. Ang 1.1 ay nagpapakita ng pinagsama-samang modelo ng sistema ng impormasyon, kabilang ang mga pangunahing diagram na dapat gawin sa proyektong ito ng kurso.

kanin. 1. Isang pinagsamang modelo ng isang sistema ng impormasyon sa notasyon ng wikang UML

4.2. Gamitin ang diagram ng case

Ang use case ay isang pagkakasunud-sunod ng mga aksyon na isinagawa ng system bilang tugon sa isang kaganapan na na-trigger ng ilang panlabas na bagay (aktor). Inilalarawan ng isang use case ang isang tipikal na pakikipag-ugnayan sa pagitan ng isang user at isang system. Sa pinakasimpleng kaso, ang use case ay tinutukoy sa pamamagitan ng pagtalakay sa user ng mga function na gusto niyang ipatupad sa isang ibinigay na sistema ng impormasyon. Sa UML, ang isang use case ay inilalarawan tulad ng sumusunod:

Larawan 2. Use case

Ang aktor ay ang papel na ginagampanan ng user kaugnay ng system. Ang mga aktor ay kumakatawan sa mga tungkulin, hindi partikular na mga tao o mga titulo sa trabaho. Bagama't inilalarawan ang mga ito bilang mga inilarawang tao sa mga diagram ng use-case, ang aktor ay maaari ding maging isang panlabas na sistema ng impormasyon na nangangailangan ng ilang impormasyon mula sa system. Ipakita lamang ang mga aktor sa iyong diagram kapag talagang kailangan nila ng ilang mga kaso ng paggamit. Sa UML, ang mga aktor ay kinakatawan bilang mga hugis:

Larawan 3. aktor (aktor)

Mayroong tatlong pangunahing uri ng mga aktor:

· Mga gumagamit;

· Mga sistema;

· Iba pang mga sistema na nakikipag-ugnayan dito;

Nagiging artista ang oras kung dito nakasalalay ang paglulunsad ng anumang kaganapan sa system.

4.2.1. Mga Relasyon sa Pagitan ng Mga Kaso ng Paggamit at Mga Aktor

Sa UML, sinusuportahan ng mga use-case diagram ang ilang uri ng mga ugnayan sa pagitan ng mga elemento ng diagram:

komunikasyon,

Pagsasama (isama),

Extension (extend),

Paglalahat.

Link ng komunikasyon Ay ang relasyon sa pagitan ng use case at ng aktor. Sa UML, ipinapakita ang mga link sa komunikasyon gamit ang one-way association (solid line).

Larawan 4. Halimbawa ng link ng komunikasyon

Link ng pagsasama nalalapat sa mga sitwasyon kung saan mayroong isang bahagi ng gawi ng system na nauulit sa higit sa isang kaso ng paggamit. Ang mga link na ito ay karaniwang ginagamit upang magmodelo ng isang magagamit muli na function.

Link ng extension ay ginagamit upang ilarawan ang mga pagbabago sa normal na pag-uugali ng isang sistema. Pinapayagan nito ang isang use case na gamitin ang functionality ng isa pang use case kapag kinakailangan.

Larawan 5. Halimbawa ng koneksyon ng pagsasama at pagpapalawig

Link ng generalization ay nagpapahiwatig na ang ilang mga aktor o klase ay may mga karaniwang katangian.

Larawan 6. Halimbawa ng link ng generalization

4.3.

Mga diagram ng pakikipag-ugnayan ilarawan ang pag-uugali ng mga nakikipag-ugnayang grupo ng mga bagay. Karaniwan, ang isang diagram ng pakikipag-ugnayan ay sumasaklaw sa gawi ng mga bagay sa loob lamang ng isang use case. Ang nasabing diagram ay nagpapakita ng isang bilang ng mga bagay at ang mga mensahe na ipinagpapalit nila sa isa't isa.

Mensahe Ay ang paraan kung saan hinihiling ng object ng nagpadala ang object ng tatanggap na gawin ang isa sa mga operasyon nito.

Mensaheng nagbibigay-kaalaman Ay isang mensahe na nagbibigay ng bagay sa tatanggap ng ilang impormasyon upang i-update ang estado nito.

Humiling ng mensahe (interogatibo) Ay isang mensahe na humihiling ng pagpapalabas ng ilang impormasyon tungkol sa bagay na tatanggap.

mensaheng pautos Ay isang mensahe na humihiling sa tatanggap na gumawa ng ilang aksyon.

Mayroong dalawang uri ng mga diagram ng pakikipag-ugnayan: mga diagram ng pagkakasunud-sunod at mga diagram ng pakikipagtulungan.

4.3.1. Mga diagram ng pagkakasunud-sunod

Sequence diagram sumasalamin sa daloy ng mga kaganapan na nangyayari sa loob ng isang kaso ng paggamit.

Ang lahat ng aktor (mga aktor, klase, o bagay) na kasangkot sa isang partikular na senaryo (use case) ay ipinapakita sa itaas ng diagram. Ang mga arrow ay tumutugma sa mga mensaheng ipinasa sa pagitan ng isang aktor at isang bagay, o sa pagitan ng mga bagay upang maisagawa ang mga kinakailangang function.

Sa isang sequence diagram, ang isang bagay ay iginuhit bilang isang parihaba na may patayong putol-putol na linya na iginuhit pababa. Ang linyang ito ay tinatawag ang lifeline ng isang bagay ... Ito ay isang fragment ng ikot ng buhay ng isang bagay sa proseso ng pakikipag-ugnayan.

Ang bawat mensahe ay kinakatawan bilang isang arrow sa pagitan ng mga linya ng buhay ng dalawang bagay. Lumilitaw ang mga mensahe sa pagkakasunud-sunod na ipinapakita sa pahina mula sa itaas hanggang sa ibaba. Ang bawat mensahe ay na-tag ng kahit man lang ang pangalan ng mensahe. Opsyonal, maaari kang magdagdag ng mga argumento at ilang impormasyon ng kontrol din. Maaari kang magpakita ng self-delegation - isang mensahe na ipinapadala ng isang bagay sa sarili nito, na may mensaheng arrow na tumuturo sa parehong lifeline.

kanin. 7. Halimbawa ng sequence diagram

4.3.2. Diagram ng pakikipagtulungan

Mga diagram ng kooperasyon ipakita ang daloy ng mga kaganapan sa loob ng isang partikular na senaryo (use case). Ang mga mensahe ay inayos ayon sa oras, bagama't ang mga diagram ng pakikipagtulungan ay higit na nakatuon sa mga ugnayan sa pagitan ng mga bagay. Kinakatawan ng collaboration diagram ang lahat ng impormasyong naglalaman ng sequence diagram, ngunit ang collaboration diagram ay naglalarawan sa daloy ng mga kaganapan sa ibang paraan. Ginagawa nitong mas madaling maunawaan ang mga koneksyon na umiiral sa pagitan ng mga bagay.

Sa isang diagram ng pakikipagtulungan, tulad ng sa isang diagram ng pagkakasunud-sunod, ang mga arrow ay nagpapahiwatig ng mga mensaheng ipinagpalit para sa isang partikular na use case. Ang kanilang temporal na pagkakasunud-sunod ay ipinahiwatig ng bilang ng mga mensahe.

kanin. 8. Halimbawa ng diagram ng kooperasyon

4.4. Class diagram

4.4.1. Pangkalahatang Impormasyon

Class diagram tumutukoy sa mga uri ng mga klase ng system at iba't ibang uri ng mga static na link na umiiral sa pagitan nila. Inilalarawan din ng mga class diagram ang mga katangian ng klase, pagpapatakbo ng klase, at mga hadlang na nalalapat sa mga ugnayan sa pagitan ng mga klase.

Ang diagram ng klase ng UML ay isang graph, ang mga node ay mga elemento ng static na istraktura ng proyekto (mga klase, interface), at ang mga arko ay ang mga ugnayan sa pagitan ng mga node (asosasyon, mana, dependencies).

Inilalarawan ng class diagram ang mga sumusunod na elemento:

· Package - isang hanay ng mga elemento ng modelo na lohikal na nauugnay sa isa't isa;

· Klase - isang paglalarawan ng mga pangkalahatang katangian ng isang pangkat ng mga katulad na bagay;

· Ang Interface ay isang abstract na klase na tumutukoy sa isang hanay ng mga operasyon na ibinibigay ng isang bagay ng isang arbitraryong klase na nauugnay sa interface na ito sa iba pang mga bagay.

4.4.2. Klase

Klase ay isang pangkat ng mga entity (mga bagay) na may magkatulad na katangian, ibig sabihin, data at pag-uugali. Ang isang indibidwal na kinatawan ng isang klase ay tinatawag na isang bagay ng klase, o isang bagay lamang.

Ang pag-uugali ng isang bagay sa UML ay nauunawaan bilang anumang mga panuntunan para sa pakikipag-ugnayan ng isang bagay sa labas ng mundo at sa data ng mismong bagay.

Sa mga diagram, ang klase ay inilalarawan bilang isang parihaba na may solidong hangganan, na hinati ng mga pahalang na linya sa 3 seksyon:

Ang tuktok na seksyon (seksyon ng pangalan) ay naglalaman ng pangalan ng klase at iba pang pangkalahatang katangian (sa partikular, ang stereotype).

Ang gitnang seksyon ay naglalaman ng isang listahan ng mga katangian

Sa ibaba ay isang listahan ng mga pagpapatakbo ng klase na nagpapakita ng pag-uugali nito (mga aksyon na ginawa ng klase).

Maaaring hindi ipakita ang alinman sa mga seksyon ng mga katangian at pagpapatakbo (pati na rin ang pareho nang sabay-sabay). Para sa isang nawawalang seksyon, hindi mo kailangang gumuhit ng linya ng paghahati at kahit papaano ay ipahiwatig ang pagkakaroon o kawalan ng mga elemento dito.

Ang mga karagdagang seksyon, tulad ng Mga Pagbubukod, ay maaaring ipakilala sa pagpapasya ng isang partikular na pagpapatupad.

kanin. 9. Halimbawang class diagram

4.4.2.1.Mga stereotype ng klase

Ang mga stereotype ng klase ay isang mekanismo para sa pagkakategorya ng mga klase.

Mayroong tatlong pangunahing stereotype ng klase na tinukoy sa UML:

Hangganan

Entidad

Kontrolin.

4.4.2.2.Mga Boundary Class

Ang mga klase sa hangganan ay mga klase na matatagpuan sa hangganan ng system at sa buong kapaligiran. Ito ay mga display, ulat, interface sa hardware (tulad ng mga printer o scanner), at mga interface sa iba pang mga system.

Upang mahanap ang mga klase sa hangganan, kailangan mong suriin ang mga diagram ng use case. Para sa bawat pakikipag-ugnayan sa pagitan ng isang aktor at isang use case, dapat mayroong kahit isang boundary class. Ito ang klase na nagpapahintulot sa aktor na makipag-ugnayan sa system.

4.4.2.3.Mga klase ng entity

Ang mga klase ng entity ay naglalaman ng nakaimbak na impormasyon. Ang mga ito ang pinakamahalaga sa gumagamit, at samakatuwid ay madalas silang gumagamit ng mga termino mula sa lugar ng paksa sa kanilang mga pangalan. Karaniwan, para sa bawat klase ng entity, ang isang talahanayan ay nilikha sa database.

4.4.2.4.Mga Klase ng Kontrol

Ang mga control class ay may pananagutan sa pag-coordinate ng mga aksyon ng ibang mga klase. Karaniwan, ang bawat use case ay may isang control class na kumokontrol sa sequence ng mga event para sa use case na iyon. Ang nagkokontrol na klase ay may pananagutan para sa koordinasyon, ngunit hindi ito nagdadala ng anumang pag-andar mismo, dahil ang ibang mga klase ay hindi nagpapadala dito ng maraming mensahe. Sa halip, siya mismo ang nagpapadala ng maraming mensahe. Ang klase ng manager ay nagtalaga lamang ng responsibilidad sa ibang mga klase, sa kadahilanang ito ay madalas itong tinutukoy bilang ang klase ng manager.

Maaaring may iba pang mga control class sa system na karaniwan sa maraming kaso ng paggamit. Halimbawa, maaaring mayroong klase ng SecurityManager na responsable para sa pagsubaybay sa mga kaganapan sa seguridad. Ang klase ng TransactionManager ay responsable para sa pag-coordinate ng mga mensahe na nauugnay sa mga transaksyon sa database. Maaaring may iba pang mga tagapamahala na haharap sa iba pang mga elemento ng pagpapatakbo ng system, tulad ng pagbabahagi ng mapagkukunan, distributed data processing, o paghawak ng error.

Bilang karagdagan sa mga stereotype na nabanggit sa itaas, maaari kang lumikha ng iyong sarili.

4.4.2.5.Mga Katangian

Ang isang katangian ay isang piraso ng impormasyong nauugnay sa isang klase. Ang mga katangian ay nag-iimbak ng naka-encapsulated na data ng klase.

Dahil ang mga katangian ay nakapaloob sa loob ng klase, nakatago ang mga ito sa ibang mga klase. Samakatuwid, maaaring kailanganin mong tukuyin kung aling mga klase ang pinapayagang magbasa at magbago ng mga katangian. Ang property na ito ay tinatawag na attribute visibility.

Ang isang katangian ay maaaring magkaroon ng apat na posibleng halaga para sa parameter na ito:

Pampubliko (pangkalahatan, bukas). Ipinapalagay ng value ng visibility na ito na makikita ang attribute ng lahat ng iba pang klase. Maaaring tingnan o baguhin ng anumang klase ang halaga ng katangian. Sa notasyon ng UML, ang karaniwang katangian ay pinangungunahan ng isang "+" sign.

Pribado (sarado, lihim). Ang kaukulang katangian ay hindi nakikita ng anumang ibang klase. Ang isang pribadong katangian ay tinutukoy ng isang "-" ayon sa notasyon ng UML.

Pinoprotektahan Ang ganitong katangian ay magagamit lamang sa klase mismo at sa mga inapo nito. Ang notasyon ng UML para sa isang protektadong katangian ay ang tanda na "#".

Package o Pagpapatupad Ipinapalagay na ang attribute na ito ay generic, ngunit sa loob lamang ng package nito. Ang ganitong uri ng visibility ay hindi ipinahiwatig ng anumang espesyal na icon.

Sa tulong ng pagsasara o seguridad, posible na maiwasan ang isang sitwasyon kapag ang halaga ng isang katangian ay binago ng lahat ng mga klase ng system. Sa halip, ang lohika para sa pagbabago ng isang katangian ay ibalot sa parehong klase bilang ang katangian mismo. Ang mga parameter ng visibility na iyong itinakda ay makakaapekto sa nabuong code.

4.4.2.6.Mga operasyon

Ang mga operasyon ay nagpapatupad ng pag-uugaling partikular sa klase. Ang isang operasyon ay may tatlong bahagi - pangalan, mga parameter at uri ng pagbabalik.

Ang mga parameter ay ang mga argumentong natanggap ng "input" na operasyon. Ang uri ng pagbabalik ay tumutukoy sa resulta ng pagkilos ng operasyon.

Sa isang class diagram, maaari mong ipakita ang parehong mga pangalan ng mga operasyon at ang mga pangalan ng mga operasyon kasama ang kanilang mga parameter at uri ng pagbabalik. Upang bawasan ang workload ng diagram, kapaki-pakinabang na ipakita lamang ang mga pangalan ng mga operasyon sa ilan sa mga ito, at sa iba ang kanilang buong lagda.

Sa UML, ang mga operasyon ay may sumusunod na notasyon:

Pangalan ng Operasyon (Argument: Uri ng Data ng Argument, Argument2: Uri ng Data ng Argument2, ...): Uri ng Pagbabalik

Mayroong apat na iba't ibang uri ng mga transaksyon na dapat isaalang-alang:

Mga operasyon sa pagpapatupad;

Kontrolin ang mga operasyon;

Mga operasyon sa pag-access;

Mga pantulong na operasyon.

Mga operasyon sa pagpapatupad

Ang mga pagpapatakbo ng tagapagpatupad ay nagpapatupad ng ilang mga function ng negosyo. Ang ganitong mga operasyon ay matatagpuan sa pamamagitan ng pagsusuri sa mga diagram ng pakikipag-ugnayan. Ang mga diagram ng ganitong uri ay nakatuon sa mga function ng negosyo, at ang bawat mensahe sa diagram ay malamang na maiugnay sa isang pagpapatakbo ng pagpapatupad.

Ang bawat hakbang sa pagpapatupad ay dapat na madaling masubaybayan sa kaukulang kinakailangan. Ito ay nakakamit sa iba't ibang yugto ng simulation. Ang isang aktibidad ay hinango mula sa isang mensahe sa isang diagram ng pakikipag-ugnayan, ang mga mensahe ay hinango mula sa isang detalyadong paglalarawan ng isang daloy ng kaganapan na nabuo batay sa isang use case, at ang huli ay hinango mula sa mga kinakailangan. Ang kakayahang masubaybayan ang buong chain na ito ay nagsisiguro na ang bawat kinakailangan ay ipinatupad sa code, at ang bawat piraso ng code ay nagpapatupad ng isang kinakailangan.

Kontrolin ang mga operasyon

Kinokontrol ng mga operasyon ng manager ang paglikha at pagkasira ng mga bagay. Ang mga constructor at destructor ng klase ay nabibilang sa kategoryang ito.

I-access ang mga operasyon

Karaniwang pribado o protektado ang mga katangian. Gayunpaman, minsan kailangan ng ibang mga klase na tingnan o baguhin ang kanilang mga halaga. Mayroong mga operasyon sa pag-access para dito. Ginagawang posible ng diskarteng ito na ligtas na i-encapsulate ang mga katangian sa loob ng isang klase, pinoprotektahan ang mga ito mula sa iba pang mga klase, ngunit pinapayagan pa rin ang kontroladong pag-access sa mga ito. Karaniwang kasanayan ang paggawa ng Get and Set operations para sa bawat attribute ng klase.

Mga pantulong na operasyon

Ang helper operations ay ang mga operasyon ng isang klase na kailangan nitong gampanan ang mga responsibilidad nito, ngunit hindi dapat malaman ng ibang klase. Ito ay pribado at protektadong mga operasyon ng klase.

Upang matukoy ang mga transaksyon, sundin ang mga hakbang na ito:

1. Galugarin ang mga sequence diagram at cooperative diagram. Karamihan sa mga mensahe sa mga diagram na ito ay mga aktibidad sa pagpapatupad. Ang mga reflective na mensahe ay magiging mga pantulong na operasyon.

2. Isaalang-alang ang mga pagpapatakbo ng kontrol. Maaaring kailanganin mong magdagdag ng mga constructor at destructor.

3. Isaalang-alang ang mga operasyon sa pag-access. Para sa bawat katangian ng klase na kakailanganing gamitin ng ibang mga klase, kailangan mong gumawa ng mga operasyong Kunin at Itakda.

4.4.2.7.Mga koneksyon

Ang isang relasyon ay isang semantikong relasyon sa pagitan ng mga klase. Nagbibigay-daan ito sa isang klase na matutunan ang tungkol sa mga katangian, pagpapatakbo, at ugnayan ng ibang klase. Sa madaling salita, para makapagpadala ng mensahe ang isang klase sa isa pa sa sequence diagram o cooperative diagram, dapat mayroong relasyon sa pagitan ng dalawa.

May apat na uri ng mga ugnayan na maaaring itatag sa pagitan ng mga klase: mga asosasyon, dependency, pagsasama-sama, at paglalahat.

Samahan ng komunikasyon

Ang asosasyon ay ang semantikong ugnayan sa pagitan ng mga klase. Ang mga ito ay iginuhit sa class diagram bilang isang ordinaryong linya.

kanin. 10. Samahan ng komunikasyon

Ang mga asosasyon ay maaaring bidirectional, tulad ng sa halimbawa, o unidirectional. Sa UML, ang mga bi-directional na asosasyon ay iginuhit bilang isang simpleng linya na walang mga arrow o may mga arrow sa magkabilang panig. Sa isang unidirectional association, isang arrow lang ang inilalarawan na nagpapakita ng direksyon nito.

Ang direksyon ng asosasyon ay maaaring matukoy sa pamamagitan ng pagsusuri sa mga sequence diagram at cooperative diagram. Kung ang lahat ng mga mensahe sa kanila ay ipinadala lamang ng isang klase at natanggap lamang ng ibang klase, ngunit hindi ang kabaligtaran, isang unidirectional na relasyon ang magaganap sa pagitan ng mga klase na ito. Kung hindi bababa sa isang mensahe ang ipinadala sa kabaligtaran na direksyon, dapat na bidirectional ang asosasyon.

Ang mga asosasyon ay maaaring maging mapanimdim. Ipinapalagay ng reflexive association na ang isang instance ng isang klase ay nakikipag-ugnayan sa ibang mga instance ng parehong klase.

Pagkagumon sa komunikasyon

Ang mga relasyon sa dependency ay sumasalamin din sa ugnayan sa pagitan ng mga klase, ngunit palagi silang unidirectional at nagpapakita na ang isang klase ay nakasalalay sa mga kahulugan na ginawa sa isa pa. Halimbawa, ang klase A ay gumagamit ng mga pamamaraan ng klase B. Pagkatapos, kapag nagbago ang klase B, kailangan mong gawin ang mga kaukulang pagbabago sa klase A.

Ang dependency ay inilalarawan bilang isang dashed line sa pagitan ng dalawang elemento ng chart, at ang elementong naka-angkla sa dulo ng arrow ay itinuturing na nakadepende sa elementong naka-angkla sa simula ng arrow na iyon.

kanin. 11. Pagkagumon sa komunikasyon

Kapag bumubuo ng code para sa mga klase na ito, walang mga bagong attribute ang idaragdag sa kanila. Gayunpaman, ang mga pahayag na tukoy sa wika na kinakailangan upang suportahan ang komunikasyon ay bubuo.

Pagsasama-sama ng link

Ang mga pagsasama-sama ay isang mas mahigpit na anyo ng samahan. Ang pagsasama-sama ay ang koneksyon sa pagitan ng kabuuan at bahagi nito. Halimbawa, maaaring mayroon kang klase para sa Kotse, pati na rin ang mga klase para sa Engine, Gulong, at mga klase para sa iba pang bahagi ng kotse. Bilang resulta, ang isang bagay ng klase ng Kotse ay bubuuin ng isang bagay ng klase ng Engine, apat na bagay ng Gulong, atbp. Ang mga pagsasama-sama ay nakikita bilang isang linya na may brilyante para sa isang klase na buo:

kanin. 11. Pagsasama-sama ng komunikasyon

Bilang karagdagan sa simpleng pagsasama-sama, ang UML ay nagpapakilala ng mas malakas na paraan ng pagsasama-sama na tinatawag na komposisyon. Ayon sa komposisyon, ang isang bagay-bahagi ay maaari lamang pag-aari sa isang solong kabuuan, at, bilang karagdagan, bilang isang panuntunan, ang siklo ng buhay ng mga bahagi ay tumutugma sa ikot ng kabuuan: sila ay nabubuhay at namamatay kasama nito. Ang anumang pag-alis ng kabuuan ay umaabot sa mga bahagi nito.

Ang cascading deletion na ito ay madalas na nakikita bilang bahagi ng kahulugan ng aggregation, ngunit ito ay palaging ipinahihiwatig kapag ang multiplicity ng mga tungkulin ay 1..1; halimbawa, kung kinakailangan na tanggalin ang isang Customer, dapat na malapat ang pagtanggal na ito sa Mga Order (at, sa turn, sa Mga Linya ng Order).

Ang lahat ng mga diagram ng UML ay maaaring halos nahahati sa dalawang grupo, ang una ay mga pangkalahatang diagram. Ang mga pangkalahatang diagram ay halos hindi nakasalalay sa paksa ng pagmomolde at maaaring magamit sa anumang proyekto ng software nang walang pagsasaalang-alang sa lugar ng paksa, lugar ng solusyon, atbp.

1.5.1. Diagram ng paggamit

Diagram ng paggamit(use case diagram) ay ang pinaka-pangkalahatang representasyon ng functional na layunin ng system.

Ang diagram ng paggamit ay inilaan upang sagutin ang pangunahing tanong sa pagmomolde: ano ang ginagawa ng system sa labas ng mundo?

Gumagamit ang use case diagram ng dalawang uri ng mga pangunahing entity, use cases 1 at aktor 2, kung saan itinatag ang mga sumusunod na pangunahing uri ng relasyon:

• ang kaugnayan sa pagitan ng aktor at use case 3;
• paglalahat sa pagitan ng mga aktor 4;
• paglalahat sa pagitan ng mga kaso ng paggamit 5;
• dependencies (ng iba't ibang uri) sa pagitan ng mga kaso ng paggamit 6.

Ang diagram ng paggamit, tulad ng iba pa, ay maaaring maglaman ng 7 komento. Bukod dito, lubos na inirerekomendang gawin ito upang mapabuti ang pagiging madaling mabasa ng mga diagram.

Ang mga pangunahing elemento ng notasyon na ginamit sa diagram ng paggamit ay ipinapakita sa ibaba. Ang isang detalyadong paglalarawan ay ibinigay sa seksyon 2.2.

1.5.2. Class diagram

Class diagram(class diagram) ay ang pangunahing paraan upang ilarawan ang istruktura ng isang sistema.

Ito ay hindi nakakagulat, dahil ang UML ay pangunahing isang object-oriented na wika, at ang mga klase ay ang pangunahing (kung hindi lamang) mga bloke ng gusali.

Sa isang diagram ng klase, isang pangunahing uri ng mga entity ang ginagamit: mga klase 1 (kabilang ang maraming mga espesyal na kaso ng mga klase: mga interface, mga primitive na uri, mga klase ng asosasyon, at marami pang iba), kung saan itinatag ang mga sumusunod na pangunahing uri ng mga relasyon:

• ugnayan sa pagitan ng mga klase 2 (na may maraming karagdagang mga detalye);
• paglalahat sa pagitan ng mga klase 3;
• dependencies (ng iba't ibang uri) sa pagitan ng 4 na klase at sa pagitan ng mga klase at interface.

Ang ilan sa mga elemento ng class diagram notation ay ipinapakita sa ibaba. Ang isang detalyadong paglalarawan ay ibinigay sa kabanata 3.

1.5.3. Automaton diagram

Automaton diagram(state machine diagram) ay isa sa mga paraan upang ilarawan nang detalyado ang gawi sa UML batay sa tahasang pag-highlight ng mga estado at paglalarawan ng mga transition sa pagitan ng mga estado.

Sa esensya, ang mga automaton diagram, gaya ng ipinahihiwatig ng pangalan, ay isang state transition graph (tingnan ang Kabanata 4), na puno ng maraming karagdagang detalye at detalye.

Sa diagram ng automat, isang pangunahing uri ng entity ang ginagamit - mga estado 1, at isang uri ng relasyon - mga transition 2, ngunit para sa pareho, maraming mga varieties, mga espesyal na kaso at karagdagang mga pagtatalaga ay tinukoy. Walang saysay na ilista ang lahat ng ito sa panimulang survey.

Ang isang detalyadong paglalarawan ng lahat ng mga variation ng automaton diagram ay ibinibigay sa seksyon 4.2, at ang sumusunod na figure ay nagpapakita lamang ng mga pangunahing elemento ng notation na ginamit sa automaton diagram.

1.5.4. Diagram ng aktibidad

Diagram ng aktibidad(activity diagram) - isang paraan upang ilarawan ang pag-uugali batay sa indikasyon ng mga kontrol na daloy at daloy ng data.

Ang diagram ng aktibidad ay isa pang paraan upang ilarawan ang gawi na nakikitang kahawig ng isang magandang makalumang flowchart. Gayunpaman, dahil sa modernized na notation, na naaayon sa object-oriented approach, at higit sa lahat, dahil sa bagong semantic component (libreng interpretasyon ng Petri nets), ang UML activity diagram ay isang makapangyarihang tool para sa paglalarawan ng gawi ng isang system.

Sa diagram ng aktibidad, isang pangunahing uri ng entity ang ginagamit - aktibidad 1, at isang uri ng relasyon - mga transition 2 (kontrol at paglilipat ng data). Ginagamit din ang mga konstruksyon tulad ng mga forks, merges, joints, branches 3, na katulad ng mga entity, ngunit sa katunayan sila ay hindi, ngunit kumakatawan sa isang graphical na paraan ng paglalarawan ng ilang mga espesyal na kaso ng multiplace relations. Ang mga semantika ng mga elemento ng diagram ng aktibidad ay detalyado sa Kabanata 4. Ang mga pangunahing elemento ng notasyon na ginamit sa isang activity diagram ay ipinapakita sa ibaba.

1.5.5. Sequence diagram

Sequence diagram(sequence diagram) ay isang paraan ng paglalarawan ng pag-uugali ng isang sistema batay sa isang indikasyon ng pagkakasunod-sunod ng mga ipinadalang mensahe.

Sa katunayan, ang isang diagram ng pagkakasunud-sunod ay isang talaan ng isang protocol ng isang partikular na session ng pagpapatakbo ng system (o isang fragment ng naturang protocol). Sa object-oriented programming, ang pinakamahalagang run-time ay ang paglipat ng mga mensahe sa pagitan ng mga bagay na nakikipag-ugnayan. Ito ay ang pagkakasunod-sunod ng pagpapadala ng mga mensahe na ipinapakita sa diagram na ito, kaya ang pangalan.

Sa sequence diagram, isang pangunahing uri ng entity ang ginagamit - mga pagkakataon ng mga nakikipag-ugnayang classifier 1 (pangunahin ang mga klase, bahagi at aktor), at isang uri ng relasyon - mga link 2, kung saan ang mga mensahe ay ipinagpapalit 3. Mayroong ilang mga paraan upang magpadala ng mga mensahe, na sa graphical na notasyon ay nakikilala sa pamamagitan ng uri ng arrow na naaayon sa kaugnayan.

Ang isang mahalagang aspeto ng sequence diagram ay ang tahasang pagpapakita ng paglipas ng panahon. Hindi tulad ng iba pang mga uri ng mga diagram, maliban marahil sa mga diagram ng pag-synchronize, sa isang sequence diagram, hindi lamang ang pagkakaroon ng mga graphic na relasyon sa pagitan ng mga elemento ay mahalaga, kundi pati na rin ang kamag-anak na posisyon ng mga elemento sa diagram. Ibig sabihin, ipinapalagay na mayroong isang (invisible) na axis ng oras, bilang default, nakadirekta mula sa itaas hanggang sa ibaba, at ang mensahe na ipinadala sa ibang pagkakataon ay iginuhit sa ibaba.

Ang axis ng oras ay maaaring idirekta nang pahalang, sa kasong ito ay itinuturing na ang oras ay dumadaloy mula kaliwa hanggang kanan.

Ang sumusunod na paglalarawan ay nagpapakita ng mga pangunahing elemento ng notasyon na ginamit sa isang sequence diagram. Upang italaga ang mga bagay na nakikipag-ugnayan mismo, ginagamit ang karaniwang notasyon - isang parihaba na may pangalan ng instance ng classifier. Ang tuldok-tuldok na linya na umaabot mula rito ay tinatawag na lifeline 4. Ito ay hindi isang pagtatalaga ng isang relasyon sa modelo, ngunit isang graphic na komentaryo na idinisenyo upang gabayan ang mata ng mambabasa sa tamang direksyon. Ang mga figure sa anyo ng makitid na mga guhit na nakapatong sa lifeline ay hindi rin mga larawan ng mga modelong entity. Ito ay isang graphic na komentaryo na nagpapakita ng mga agwat ng oras kung kailan pagmamay-ari ng object ang execution occurrence 5, o sa madaling salita, nagaganap ang object activation. Ang Pinagsamang Fragment Steps 6 ay nagbibigay-daan sa isang sequence diagram na ipakita ang mga algorithmic na aspeto ng isang protocol ng pakikipag-ugnayan. Para sa higit pang mga detalye sa sequence diagram notation, tingnan ang Kabanata 4.

1.5.6. Diagram ng komunikasyon

Diagram ng komunikasyon(diagram ng komunikasyon) - isang paraan ng paglalarawan ng pag-uugali, na katumbas ng semantiko sa isang sequence diagram.

Sa katunayan, ito ang parehong paglalarawan ng pagkakasunud-sunod ng pagpapalitan ng mensahe ng mga nag-uugnay na instance ng classifier, na ipinahayag lamang sa iba pang mga graphical na paraan. Bukod dito, ang karamihan sa mga tool ay maaaring awtomatikong i-convert ang mga sequence diagram sa mga diagram ng komunikasyon at vice versa.

Kaya, sa diagram ng komunikasyon, pati na rin sa diagram ng pagkakasunud-sunod, isang pangunahing uri ng entity ang ginagamit - mga pagkakataon ng nakikipag-ugnayan na mga classifier 1 at isang uri ng relasyon - mga link 2. Gayunpaman, ang diin dito ay hindi sa oras, ngunit sa istruktura ng mga link sa pagitan ng mga partikular na pagkakataon.

Ipinapakita ng figure ang mga pangunahing elemento ng notasyon na ginamit sa isang diagram ng komunikasyon. Upang italaga ang mga bagay na nakikipag-ugnayan mismo, ginagamit ang karaniwang notasyon - isang parihaba na may pangalan ng instance ng classifier. Ang kamag-anak na posisyon ng mga elemento sa diagram ng pakikipagtulungan ay hindi mahalaga - ang mga link lamang (madalas na mga pagkakataon ng mga asosasyon) ang mahalaga, kung saan ang mga mensahe ay ipinadala 3. Ang hierarchical decimal numbering ay ginagamit upang ipakita ang pagkakasunud-sunod ng mga mensahe sa paglipas ng panahon.

1.5.7. Component diagram

Component diagram(component diagram) - nagpapakita ng ugnayan sa pagitan ng mga module (lohikal o pisikal) na bumubuo sa simulate system.

Ang pangunahing uri ng mga entity sa component diagram ay ang mga mismong bahagi 1, pati na rin ang mga interface 2, kung saan ipinapahiwatig ang ugnayan sa pagitan ng mga bahagi. Sa isang component diagram, nalalapat ang mga sumusunod na ugnayan:

• mga pagpapatupad sa pagitan ng mga bahagi at mga interface (ang isang bahagi ay nagpapatupad ng isang interface);
• dependencies sa pagitan ng mga bahagi at mga interface (ang bahagi ay gumagamit ng isang interface) 3.

Ipinapakita ng figure ang mga pangunahing elemento ng notasyon na ginamit sa isang component diagram. Ang isang detalyadong paglalarawan ay ibinigay sa kabanata 3.

1.5.8. Diagram ng pagkakalagay

Diagram ng pagkakalagay(deployment diagram), kasama ang pagpapakita ng komposisyon at mga ugnayan ng mga elemento ng system, ay nagpapakita kung paano sila pisikal na matatagpuan sa mga mapagkukunan ng computing sa runtime.

Kaya, sa placement diagram, kung ihahambing sa component diagram, dalawang uri ng entity ang idinagdag: artifact 1, na kung saan ay ang pagpapatupad ng component 2 at node 3 (maaari itong maging classifier na naglalarawan sa uri ng node, o isang partikular na instance), pati na rin ang isang kaugnayan sa pagitan ng Nodes 4, na nagpapakita na ang mga node ay pisikal na konektado sa runtime.

Ipinapakita ng figure ang mga pangunahing elemento ng notasyon na ginamit sa placement diagram. Upang ipakita na ang isang entity ay bahagi ng isa pa, maaaring ilapat ang "deploy" dependency na relasyon 5, o ang hugis ng isang entity ay inilalagay sa loob ng hugis ng isa pang entity 6. Ang isang detalyadong paglalarawan ng diagram ay ibinigay sa kabanata 3.

11.1. Istruktura ng Pinag-isang Wika ng Pagmomodelo

Pinag-isang Wika ng Pagmomodelo (UML) ay kasalukuyang de facto na pamantayan para sa paglalarawan (pagdodokumento) ng mga resulta ng disenyo at pagbuo ng mga object-oriented system. Nagsimula ang pagbuo ng UML noong 1994 nina Grady Booch at James Rambeau ng Rational Software. Noong taglagas ng 1995, sumali sa kanila si Ivar Jacobson, at noong Oktubre ng parehong taon, isang paunang bersyon 0.8 ng Unified Method ang inilabas. Mula noon, ilang bersyon ng detalye ng UML ang inilabas, dalawa sa mga ito ay may katayuan ng isang internasyonal na pamantayan:

UML 1.4.2 - "ISO / IEC 19501: 2005. Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2" (eng. "Information technology. Open distributed processing. Unified modeling language (UML). Bersyon 1.4.2 ");

UML 2.4.1 - "ISO / IEC 19505-1: 2012. Information technology. OMG UML. Part 1. Infrastructure" (eng. "Information technology - Object Management Group Unified Modeling Language ( OMG UML) - Part 1: Infrastructure ") at" ISO / IEC 19505-2: 2012. Information technology. Unified Object Management Group Modeling Language (OMG UML). Part 2. Superstructure "(eng." Information technology - Object Management Group Unified Modeling Language (OMG UML) - Part 2 : Superstructure ").

Ang pinakabagong opisyal na detalye ng wika ay matatagpuan sa www.omg.org.

Ang pangkalahatang istraktura ng UML ay ipinapakita sa sumusunod na figure.

kanin. 11.1. Istruktura ng UML

11.2. UML semantics at syntax

Semantika - isang seksyon ng linggwistika na nag-aaral ng kahulugan ng mga yunit ng wika, pangunahin ang mga salita at parirala nito.

Syntax - mga paraan ng pagsasama-sama ng mga salita at kanilang mga anyo sa mga parirala at pangungusap, pagsasama-sama ng mga pangungusap sa kumplikadong mga pangungusap, mga paraan ng paglikha ng mga pahayag bilang bahagi ng teksto.

Kaya, gaya ng inilapat sa UML, ang mga semantika at syntax ay tumutukoy sa isang istilo ng pagtatanghal (modelong pagbuo) na pinagsasama ang natural at pormal na mga wika upang kumatawan sa mga pangunahing konsepto (mga elemento ng modelo) at mga mekanismo para sa kanilang pagpapalawig.

11.3. UML notation

Ang notasyon ay isang graphical na interpretasyon ng semantics para sa visual na presentasyon nito.

Tinutukoy ng UML ang tatlo uri ng entidad :

Structural - isang abstraction na isang salamin ng isang konseptwal o pisikal na bagay;

Pagpapangkat - isang elementong ginagamit para sa ilang semantikong pagkakaisa ng mga elemento ng diagram;

Explanatory (annotation) - isang komento sa isang elemento ng diagram.

Ang sumusunod na talahanayan ay nagbibigay ng maikling paglalarawan ng mga pangunahing entity na ginagamit sa graphical na notasyon at ang mga pangunahing paraan upang ipakita ang mga ito.

Talahanayan 11.1. Mga entidad

Uri ng	Pangalan	Pagtatalaga	Kahulugan (semantics)
Structural	(klase)		Maraming mga bagay na may karaniwang istraktura at pag-uugali
	(bagay)		Isang abstraction ng isang tunay o naisip na entity na may malinaw na tinukoy na konseptong mga hangganan, indibidwalidad (pagkakakilanlan), estado at pag-uugali. Mula sa pananaw ng UML, ang mga bagay ay mga instance ng klase (mga instance ng entity)
	(aktor)	Inhinyero mga serbisyo ng landas	Isang entity na panlabas sa system na nakikipag-ugnayan sa system at ginagamit ang functionality nito upang makamit ang ilang layunin o malutas ang mga partikular na problema. Kaya, ang aktor ay isang panlabas na mapagkukunan o tagatanggap ng impormasyon.
	(use case)		Paglalarawan ng mga aksyon na ginawa ng system, na humahantong sa isang resulta na makabuluhan para sa aktor
	(estado)		Paglalarawan ng sandali sa buhay ng isang entity kapag natugunan nito ang isang tiyak na kundisyon, nagsasagawa ng ilang aktibidad o naghihintay para sa paglitaw ng ilang kaganapan
	Pagtutulungan (pagtutulungan)		Paglalarawan ng isang hanay ng mga pagkakataon ng mga aktor, bagay at ang kanilang pakikipag-ugnayan sa proseso ng paglutas ng isang tiyak na problema
	(bahagi)		Ang pisikal na bahagi ng system (file), kabilang ang mga module ng system na nagbibigay ng pagpapatupad ng isang pare-parehong hanay ng mga interface
	(interface)	iCalculation	Isang hanay ng mga pagpapatakbo na tumutukoy sa isang serbisyo (set ng mga serbisyo) na ibinigay ng isang klase o bahagi
	(node)		Ang pisikal na bahagi ng system (computer, printer, atbp.) na nagbibigay ng mga mapagkukunan para sa paglutas ng problema
Pagpapangkat	(package)		Pangkalahatang mekanismo para sa pagpapangkat ng mga elemento. Hindi tulad ng isang bahagi, ang isang pakete ay isang simpleng konsepto (abstract). Ang mga partikular na kaso ng package ay ang sistema at ang modelo
	(fragment)		Ang lugar ng partikular na pakikipag-ugnayan sa pagitan ng mga pagkakataon ng aktor at bagay
	(activity partition)		Isang pangkat ng mga operasyon (lugar ng pananagutan) na isinagawa ng isang nilalang (aktor, bagay, bahagi, node, atbp.)
	(nagagambalang rehiyon ng aktibidad)		Isang pangkat ng mga operasyon, ang normal na pagkakasunod-sunod nito ay maaaring maputol bilang resulta ng isang hindi karaniwang sitwasyon
Nagpapaliwanag	Tandaan (komento)		Komento ng item. Naka-attach sa nagkomento na item na may putol-putol na linya

Sa ilang mga pinagmumulan, sa partikular [,], ang mga entidad ng pag-uugali ay nakikilala rin pakikipag-ugnayan at may hangganan na mga makina ng estado, ngunit mula sa isang lohikal na pananaw, dapat na mauri ang mga ito bilang mga diagram.

Ang ilan sa mga entity sa itaas, alinsunod sa implicitly, ay inilarawan nang detalyado sa mga diagram ng decomposition. Sa top-level na diagram, minarkahan sila ng isang espesyal na icon o label.

Ang sumusunod na talahanayan ay nagbibigay ng isang paglalarawan ng lahat ng mga uri relasyon UML na ginagamit sa mga diagram upang ipahiwatig ang mga ugnayan sa pagitan ng mga entity.

Talahanayan 11.3. Relasyon

Pangalan	Pagtatalaga	Kahulugan (semantics)
Samahan		Isang relasyon na naglalarawan ng makabuluhang relasyon sa pagitan ng dalawa o higit pang entity. Ang pinaka-pangkalahatang uri ng relasyon
Pagsasama-sama		Isang subtype ng asosasyon na naglalarawan sa relasyong "bahagi" - "buo", kung saan ang "bahagi" ay maaaring umiral nang hiwalay sa "buo". Ang rhombus ay ipinahiwatig mula sa "buong" gilid. Ang relasyon ay ipinahiwatig lamang sa pagitan ng mga entity ng parehong uri
Komposisyon		Isang subtype ng pagsasama-sama kung saan ang "mga bahagi" ay hindi maaaring umiral nang hiwalay sa "buo". Bilang isang patakaran, ang "mga bahagi" ay nilikha at nawasak kasabay ng "buong"
Dependency		Isang relasyon sa pagitan ng dalawang entity kung saan ang pagbabago sa isang entity (independent) ay maaaring makaapekto sa estado o pag-uugali ng isa pang entity (dependent). Ang isang independiyenteng entity ay ipinahiwatig sa gilid ng arrow
Paglalahat		Ang ugnayan sa pagitan ng isang generic na entity (ninuno, magulang) at isang espesyal na entity (anak, anak). Tinukoy ang tatsulok mula sa gilid ng magulang. Ang relasyon ay ipinahiwatig lamang sa pagitan ng mga entity ng parehong uri
Realization		Isang ugnayan sa pagitan ng mga entity, kung saan tinutukoy ng isang entity ang isang aksyon na gagawin ng isa pang entity. Ginagamit ang mga ugnayan sa dalawang sitwasyon: sa pagitan ng mga interface at mga klase (o mga bahagi), sa pagitan ng mga kaso ng paggamit at pakikipagtulungan. Ang arrow side ay nagpapahiwatig ng entity na tumutukoy sa aksyon (interface o use case)

Para sa pagsasamahan, maaaring tukuyin ang pagsasama-sama at komposisyon multiplicity (English multiplicity), na nagpapakilala sa kabuuang bilang ng mga pagkakataon ng mga entity na lumalahok sa relasyon. Karaniwan itong ipinahiwatig sa bawat panig ng relasyon malapit sa kaukulang entity. Ang multiplicity ay maaaring tukuyin sa mga sumusunod na paraan:

- * - anumang bilang ng mga kopya, kabilang ang wala;

Non-negative integer - ang multiplicity ay mahigpit na naayos at katumbas ng tinukoy na numero (halimbawa: 1, 2 o 5);

Saklaw ng mga hindi negatibong integer "unang numero .. pangalawang numero" (halimbawa: 1..5, 2..10 o 0..5);

Isang hanay ng mga numero mula sa isang partikular na inisyal na halaga hanggang sa isang arbitrary na huling "unang numero .. *" (halimbawa: 1 .. *, 5 .. * o 0 .. *);

Pag-enumerate ng mga hindi negatibong integer at hanay na pinaghihiwalay ng mga kuwit (halimbawa: 1, 3..5, 10, 15 .. *).

Kung hindi tinukoy ang multiplicity, ipinapalagay na ang value nito ay 1. Ang multiplicity ng mga instance ng entity na kalahok sa dependency, generalization at pagpapatupad ay palaging ipinapalagay na 1.

Ang sumusunod na talahanayan ay naglalarawan mekanismo para mapalawak ginamit upang linawin ang semantika ng mga entidad at relasyon. Sa pangkalahatan, ang mekanismo ng extension ay isang string ng text na nakapaloob sa mga bracket o panipi.

Talahanayan 11.4. Mga mekanismo ng extension

Pangalan	Pagtatalaga	Kahulugan (semantics)
Estereotipo (estereotipo)	« »	Ang isang pagtatalaga na tumutukoy sa mga semantika ng isang elemento ng notasyon (halimbawa: isang dependency na may "isama" na stereotype ay itinuturing na isang kaugnayan sa pagsasama, at isang klase na may isang "hangganan" na stereotype ay isang boundary class)
Kondisyon ng bantay (kondisyon ng bantay)		Boolean na kundisyon (halimbawa: o [nakumpleto ang pagkakakilanlan])
Limitasyon (pagpigil)	{ }	Panuntunang naglilimita sa mga semantika ng elemento ng modelo (halimbawa, (oras ng pagpapatupad na mas mababa sa 10ms))
Naka-tag na halaga (tag na halaga)	{ }	Bago o kwalipikadong pag-aari ng isang elemento ng notasyon (halimbawa: (bersyon = 3.2))

Bilang karagdagan sa mga stereotype, na ipinahiwatig bilang isang string ng teksto sa mga panipi, ang mga graphical na stereotype ay maaaring gamitin sa mga chart. Ang sumusunod na figure ay nagpapakita ng mga halimbawa ng standard at stereotyped na display.

a) karaniwang pagtatalaga		b) karaniwang pagtatalaga na may stereotype ng teksto		c) graphic na stereotype

kanin. 11.2. Mga halimbawa ng standard at stereotyped na pagpapakita ng klase

Diagram ay isang pagpapangkat ng mga elemento ng notasyon upang kumatawan sa ilang aspeto ng sistema ng impormasyon na binuo. Ang mga diagram ay karaniwang isang konektadong graph kung saan ang mga entity ay mga vertex at ang mga relasyon ay mga arko. Ang sumusunod na talahanayan ay nagbibigay ng maikling paglalarawan ng mga diagram ng UML.

Talahanayan 11.5. Mga diagram

Diagram			appointment
				sa pamamagitan ng antas ng pisikal na pagsasakatuparan	sa pamamagitan ng pagpapakita ng dynamics	ayon sa ipinapakitang aspeto
(use case)			Ipinapakita ang mga function ng system, pakikipag-ugnayan sa pagitan ng mga aktor at mga function	Lohikal	Static	Functional
(klase)			Nagpapakita ng isang hanay ng mga klase, interface at relasyon sa pagitan nila	Lohikal o pisikal	Static	Functional at impormasyon
(package)			Nagpapakita ng isang hanay ng mga pakete at ang kaugnayan sa pagitan ng mga ito	Lohikal o pisikal	Static	Bahagi
Pag-uugali (pag-uugali)	(makina ng estado)		Ipinapakita ang mga estado ng isang entity at mga paglipat sa pagitan ng mga ito sa panahon ng ikot ng buhay nito	Lohikal	Dynamic	Pag-uugali
	(aktibidad)		Ipinapakita ang mga proseso ng negosyo sa system (paglalarawan ng mga algorithm ng pag-uugali)
	Mga pakikipag-ugnayan (interaksyon)	(sequence)	Ipinapakita ang pagkakasunod-sunod ng pagpasa ng mga mensahe sa pagitan ng mga bagay at aktor
		(komunikasyon)	Katulad ng isang sequence diagram, ngunit ang diin ay sa istruktura ng mga pakikipag-ugnayan sa pagitan ng mga bagay
Pagpapatupad (pagpapatupad)	(bahagi)		Nagpapakita ng mga bahagi ng system (mga programa, aklatan, talahanayan, atbp.) at mga link sa pagitan ng mga ito	Pisikal	Static	Bahagi
	(deployment)		Ipinapakita ang paglalagay ng mga bahagi ng mga host, pati na rin ang pagsasaayos nito

Tinutukoy din ng pamantayang UML 2.x ang mga karagdagang, lubos na espesyalisadong diagram:

Ang isang object diagram ay magkatulad, ngunit ang mga bagay ay ipinapakita sa halip na mga klase;

Timing diagram - naglalarawan ng estado ng isang bagay sa paglipas ng panahon;

Composite structure diagram - inilalarawan ang mga port (kabilang ang mga interface) ng isang klase para sa pakikipag-ugnayan sa ibang mga klase;

Diagram ng profile - katulad ng paglalarawan ng mga klase na kasama sa kanila;

Ang diagram ng pangkalahatang-ideya ng pakikipag-ugnayan ay magkatulad, ngunit may mga nakatagong mga fragment ng pakikipag-ugnayan (mga fragment na may ref tag). Ito ay isang kontekstwal (konsepto), ang mga elemento nito ay ikonkreto sa magkakahiwalay na diagram ng agnas.

Para sa layunin ng isang pinalaki na haka-haka na representasyon ng panloob na arkitektura ng system, karamihan sa konstruksiyon ay nagbibigay-daan sa paggamit ng itinatag na mga graphical na stereotype para sa tinatawag na. Ang nasabing diagram ay tinatawag na 1, ngunit hindi kabilang sa listahan ng mga diagram na tinukoy ng pamantayan ng UML.

Kapag bumubuo ng isang hiwalay na modelo ng system, maraming uri ng mga diagram ang binuo. Bukod dito, kapag bumubuo ng isang modelo ng isang kumplikadong sistema, bilang isang panuntunan, maraming mga diagram ng parehong uri ang binuo. Kasabay nito, posible na huwag lumikha ng hiwalay na mga uri ng mga diagram, kung hindi ito kinakailangan. Halimbawa, ang mga diagram at maaaring palitan; ang mga ito ay binuo lamang para sa mga bagay na may kumplikadong pag-uugali. Ang sumusunod na talahanayan ay nagbibigay ng gabay sa pangangailangang bumuo (pinuhin) ang mga diagram ayon sa modelo ng system.

Talahanayan 11.6. Pag-uugnay ng mga Modelo at Diagram

Ang talahanayan ay hindi nagpapakita ng modelo ng pagsubok, dahil sa loob ng balangkas ng pagtatayo nito, ang mga diagram ay hindi binuo, ngunit sinusuri (nasubok) para sa pagkakumpleto at pagkakapare-pareho.

Ang bahagi ng mga diagram pagkatapos ng kanilang pagtatayo ay nangangailangan ng pag-unlad at pagpipino sa balangkas ng pagbuo ng susunod na modelo (teknolohiyang proseso). Kaya, halimbawa, ay dapat na linawin sa panahon ng pag-unlad. Sa mga modelo.

4. Magbigay ng kahulugan sa konseptong "".

10.4. UML DIAGRAM

10.4.1. Mga uri ng UML visual diagram

Pinapayagan ka ng UML na lumikha ng ilang uri ng mga visual na diagram:

Gamitin ang mga diagram ng kaso

Mga diagram ng pagkakasunud-sunod;

Mga tsart ng kooperatiba;

Mga diagram ng klase

Mga diagram ng estado;

Mga diagram ng bahagi;

Mga diagram ng pagkakalagay.

Ang mga diagram ay naglalarawan ng iba't ibang aspeto ng system. Halimbawa, ipinapakita ng cooperative diagram kung paano dapat makipag-ugnayan ang mga bagay upang maipatupad ang ilang functionality ng system. Ang bawat diagram ay may sariling layunin.

10.4.2. Gamitin ang mga diagram ng kaso

Inilalarawan ng mga use case diagram ang mga pakikipag-ugnayan sa pagitan ng mga use case na kumakatawan sa mga function ng isang system at mga aktor, na kumakatawan sa mga tao o system, pagtanggap o pagpapadala ng impormasyon sa system na iyon. Ang isang halimbawa ng isang use case diagram para sa isang ATM ay ipinapakita sa Fig. 10.1.

kanin. 10.1. Gamitin ang diagram ng case

Inilalarawan ng diagram ang mga pakikipag-ugnayan sa pagitan ng mga kaso ng paggamit at mga aktor. Sinasalamin nito ang mga kinakailangan ng system mula sa pananaw ng user. Kaya, ang mga use case ay mga function na ginagawa ng system, at ang mga aktor ay mga stakeholder kaugnay ng system na binuo. Ipinapakita ng mga diagram kung sinong mga aktor ang nagti-trigger ng mga kaso ng paggamit. Ipinapakita rin nila kapag nakatanggap ang aktor ng impormasyon mula sa use case. Sa esensya, maaaring ilarawan ng isang use case diagram ang mga kinakailangan ng system. Sa aming halimbawa, sinimulan ng kliyente ng bangko ang iba't ibang mga kaso ng paggamit: "Mag-withdraw ng pera mula sa account", "Maglipat ng pera", "Magdagdag ng pera sa account", "Ipakita ang balanse", "Palitan ang numero ng pagkakakilanlan", "Magbayad". Maaaring simulan ng klerk ng bangko ang kaso ng paggamit ng Change Identification Number. Mula sa Make Payment Use Case, mayroong isang arrow papunta sa Credit System. Ang mga panlabas na sistema ay maaari ding maging mga aktor, sa kasong ito ang Credit system ay ipinapakita nang eksakto bilang isang aktor - ito ay panlabas sa sistema ng ATM. Ang isang arrow na tumuturo mula sa use case patungo sa aktor ay nagpapahiwatig na ang use case ay nagbibigay ng ilang impormasyon sa aktor. Sa kasong ito, ang use case na "Magbayad" ay nagbibigay sa Credit System ng impormasyon tungkol sa isang pagbabayad sa credit card.

Napakaraming impormasyon tungkol sa system ang maaaring makuha mula sa mga use case diagram. Inilalarawan ng ganitong uri ng diagram ang pangkalahatang pag-andar ng system. Maaaring pag-aralan ng mga user, project manager, analyst, developer, QA specialist, at sinumang interesado sa system ang mga use case diagram para maunawaan kung ano ang dapat gawin ng system.

10.4.3. Mga diagram ng pagkakasunud-sunod

Inilalarawan ng mga sequence diagram ang daloy ng mga kaganapan na nagaganap sa loob ng isang use case. Halimbawa, ang use case na "Mag-withdraw ng pera" ay nagbibigay ng ilang posibleng pagkakasunud-sunod: pag-withdraw ng pera, sinusubukang mag-withdraw ng pera kung walang sapat na pera sa account, sinusubukang mag-withdraw ng pera gamit ang maling numero ng pagkakakilanlan, at ilang iba pa. Ang isang normal na senaryo para sa pag-withdraw ng $ 20 mula sa isang account (sa kawalan ng mga problema tulad ng isang maling numero ng pagkakakilanlan o hindi sapat na mga pondo sa account) ay ipinapakita sa Fig. 10.2.

Fig 10.2. Sequence diagram para sa pag-withdraw ng kliyenteng si Joe ng $20 mula sa kanyang account

Ang tuktok ng diagram ay nagpapakita ng lahat ng mga aktor at bagay na kinakailangan ng system upang matupad ang kaso ng paggamit ng Withdraw Money. Ang mga arrow ay tumutugma sa mga mensaheng ipinadala sa pagitan ng aktor at ng bagay, o sa pagitan ng mga bagay upang maisagawa ang mga kinakailangang function. Dapat ding tandaan na ang sequence diagram ay nagpapakita ng mga bagay, hindi ang mga klase. Ang mga klase ay kumakatawan sa mga uri ng mga bagay. Ang mga bagay ay tiyak; sa halip na klase Customer ang sequence diagram ay kumakatawan sa isang partikular na customer na si Joe.

Magsisimula ang use case kapag ipinasok ng customer ang kanilang card sa reader - ipinapakita ang bagay na ito sa parihaba sa itaas ng diagram. Binabasa nito ang numero ng card, binubuksan ang object ng Joe Account, at sinisimulan ang screen ng ATM. Tinanong ng screen si Joe para sa kanyang numero ng pagpaparehistro. Ipinasok ng customer ang numerong 1234. Sinusuri ng screen ang numero sa object ng Joe's Account at natuklasan na ito ay tama. Pagkatapos ay ipinakita ng screen kay Joe ang isang menu ng pagpili at pipiliin ni Joe ang "Mag-withdraw ng Pera". Ang screen ay nagtatanong kung magkano ang gusto niyang bawiin, at si Joe ay nagsasaad ng $20. Ang screen ay nag-aalis ng pera mula sa account. Sa paggawa nito, sinisimulan nito ang isang serye ng mga prosesong isinagawa ng object ng Joe's Account. Kasabay nito, sinusuri na mayroong hindi bababa sa $ 20 sa account na ito at ang kinakailangang halaga ay ibabawas mula sa account. Ang cash register ay pagkatapos ay inutusan na "mag-isyu ng tseke at $ 20 sa cash." Panghuli, ang parehong Joe's Account object ay nagtuturo sa card reader na ibalik ang card.

Kaya, ang sequence diagram na ito ay naglalarawan ng daloy ng Withdraw use case gamit ang isang partikular na halimbawa ng Customer Joe na nag-withdraw ng $20. Sa pamamagitan ng pagtingin sa diagram na ito, nagiging pamilyar ang mga user sa mga detalye ng kanilang trabaho. Nakikita ng mga analyst ang sequence (flow) ng mga aksyon, nakikita ng mga developer ang mga bagay na gagawin at ang kanilang mga operasyon. Mauunawaan ng mga propesyonal sa pagkontrol sa kalidad ang mga detalye ng proseso at maaaring magdisenyo ng mga pagsubok para i-verify ang mga ito. Kaya, ang mga sequence diagram ay kapaki-pakinabang sa lahat ng kasangkot sa proyekto.

10.4.4. Mga tsart ng kooperatiba

Ang mga cooperative diagram ay nagpapakita ng parehong impormasyon gaya ng mga sequence diagram. Gayunpaman, ginagawa nila ito sa ibang paraan at para sa iba't ibang layunin. Ipinapakita sa fig. 10.2 ang isang sequence diagram ay ipinapakita sa fig. 10.3 bilang isang cooperative diagram.

Tulad ng dati, ang mga bagay ay inilalarawan bilang mga parihaba, at mga character bilang mga figure. Samantalang ang isang sequence diagram ay nagpapakita ng mga pakikipag-ugnayan sa pagitan ng mga aktor at mga bagay sa paglipas ng panahon, walang kaugnayan sa oras sa isang cooperative diagram. Kaya, makikita na ang card reader ay nagtuturo sa "Joe account" upang buksan, at ang "Joe account" ay nagiging sanhi ng card reader na ibalik ang card sa may-ari. Ang mga direktang nakikipag-ugnayan na mga bagay ay konektado sa pamamagitan ng mga linya. Kung, halimbawa, ang isang card reader ay direktang nakikipag-ugnayan sa isang ATM screen, gumuhit ng linya sa pagitan nila. Ang kawalan ng isang linya ay nangangahulugan na walang direktang komunikasyon sa pagitan ng mga bagay.

kanin. 10.3. Cooperative diagram na naglalarawan sa proseso ng pag-withdraw ng pera mula sa isang account

Kaya, ang isang cooperative diagram ay nagpapakita ng parehong impormasyon bilang isang sequence diagram, ngunit ito ay kinakailangan para sa iba pang mga layunin. Ang mga propesyonal sa pagkontrol ng kalidad at mga arkitekto ng system ay mauunawaan ang pamamahagi ng mga proseso sa pagitan ng mga site. Sabihin nating ang ilang uri ng cooperative diagram ay kahawig ng isang bituin, kung saan maraming bagay ang nauugnay sa isang sentral na bagay. Maaaring isipin ng arkitekto ng system na ang sistema ay masyadong nakadepende sa sentrong pasilidad at kailangang muling idisenyo upang maipamahagi ang mga proseso nang mas pantay. Sa isang sequence diagram, ang ganitong uri ng pakikipag-ugnayan ay magiging mahirap makita.

10.4.5. Mga diagram ng klase

Ang mga class diagram ay sumasalamin sa mga pakikipag-ugnayan sa pagitan ng mga klase sa isang system. Halimbawa, ang "Joe's account" ay isang object. Ang uri ng naturang bagay ay maaaring ituring na isang account sa pangkalahatan, iyon ay, ang "Account" ay isang klase. Ang mga klase ay naglalaman ng data at pag-uugali (mga aksyon) na nakakaapekto sa data na iyon. Halimbawa, ang klase ng Account ay naglalaman ng numero ng pagkakakilanlan ng kliyente at mga pagkilos na nagpapatunay nito. Sa isang class diagram, isang klase ang nabuo para sa bawat uri ng object mula sa sequence diagram o Cooperative diagram. Ang class diagram para sa kaso ng paggamit ng Withdraw Money ay ipinapakita sa Figure 4-2. 10.4.

Ipinapakita ng diagram ang mga ugnayan sa pagitan ng mga klase na nagpapatupad ng kaso ng paggamit ng Withdraw Money. May apat na klase na kasangkot sa prosesong ito: Card Reader, Account, ATM (ATM screen), at Cash Dispenser. Ang bawat klase sa class diagram ay kinakatawan ng isang parihaba na nahahati sa tatlong bahagi. Ang unang bahagi ay tumutukoy sa pangalan ng klase, ang pangalawa - nito mga katangian. Ang isang katangian ay ilang impormasyon na nagpapakilala sa isang klase. Halimbawa, ang klase ng Account ay may tatlong katangian: Numero ng Account, PIN, at Balanse. Ang huling bahagi ay naglalaman ng mga operasyon ng klase na sumasalamin dito pag-uugali(mga aksyon na isinagawa ng klase). Ang mga linya ng pag-uugnay sa pagitan ng mga klase ay nagpapakita ng pakikipag-ugnayan sa pagitan ng mga klase.

kanin. 10.4. Class diagram

Gumagamit ang mga developer ng mga diagram ng klase upang aktwal na lumikha ng mga klase. Ang mga tool tulad ng Rose ay bumubuo ng base ng code para sa mga klase na pinupunan ng mga programmer ng mga detalye sa kanilang piniling wika. Sa mga diagram na ito, maipapakita ng mga analyst ang mga detalye ng system at mauunawaan ng mga arkitekto ang disenyo. Kung, halimbawa, ang isang klase ay nagdadala ng masyadong maraming functional load, ito ay makikita sa class diagram, at ang arkitekto ay maaaring muling ipamahagi ito sa iba pang mga klase. Maaari mo ring gamitin ang diagram upang matukoy ang mga kaso kung saan walang tinukoy na mga ugnayan sa pagitan ng mga klase sa pakikipag-usap. Dapat gumawa ng mga class diagram upang ipakita ang mga nakikipag-ugnayang klase sa bawat use case. Maaari ka ring bumuo ng mas pangkalahatang mga diagram na sumasaklaw sa lahat ng system o subsystem.

10.4.6. Mga diagram ng estado

Ang mga diagram ng estado ay idinisenyo upang i-modelo ang iba't ibang mga estado kung saan maaaring ilagay ang isang bagay. Habang ang mga class diagram ay nagpapakita ng isang static na larawan ng mga klase at ang kanilang mga relasyon, ang mga state diagram ay ginagamit upang ilarawan ang dynamics ng pag-uugali ng isang system.

Ang mga diagram ng estado ay naglalarawan ng pag-uugali ng isang bagay. Halimbawa, ang isang bank account ay maaaring magkaroon ng ilang magkakaibang estado. Maaari itong buksan, sarado, o maaaring lampasan ang kredito para dito. Ang pag-uugali ng account ay nagbabago depende sa estado kung saan ito matatagpuan. Ang diagram ng estado ay eksaktong nagpapakita ng impormasyong ito. Sa fig. Ang 10.5 ay isang halimbawa ng diagram ng estado para sa isang bank account.

kanin. 10.5. State diagram para sa klase ng Account

Ipinapakita ng diagram na ito ang mga posibleng estado ng account, pati na rin ang proseso ng paglipat ng account mula sa isang estado patungo sa isa pa. Halimbawa, kung ang isang kliyente ay humiling na isara ang isang bukas na account, ang huli ay mapupunta sa "Sarado" na estado. Tinatawag ang pangangailangan ng customer kaganapan, ito ay mga pangyayari na nagiging sanhi ng paglipat mula sa isang estado patungo sa isa pa.

Kapag ang isang kliyente ay nag-withdraw ng pera mula sa isang bukas na account, ang account ay maaaring pumunta sa "Sobrang credit" na estado. Nangyayari lamang ito kung ang balanse ng account ay mas mababa sa zero, gaya ng ipinapakita ng kundisyon [negatibong balanse] sa aming chart. Nakapaloob sa mga square bracket kundisyon tinutukoy kung kailan maaaring mangyari o hindi mangyari ang isang paglipat mula sa isang estado patungo sa isa pa.

Mayroong dalawang espesyal na estado sa diagram - inisyal at ang pangwakas. Ang paunang estado ay naka-highlight sa isang itim na tuldok: tumutugma ito sa estado ng bagay sa oras ng paglikha nito. Ang huling estado ay ipinahiwatig ng isang itim na tuldok sa isang puting bilog: tumutugma ito sa estado ng bagay bago ito nawasak. Maaaring magkaroon ng isa at isang paunang estado lamang sa isang statechart. Kasabay nito, maaaring mayroong kasing daming end state na kailangan mo, o maaaring wala talaga.

Kapag ang isang bagay ay nasa isang partikular na estado, ang ilang mga proseso ay maaaring isagawa. Sa aming halimbawa, kapag lumampas ang utang, isang kaukulang mensahe ang ipinadala sa kliyente. Ang mga prosesong nagaganap kapag ang isang bagay ay nasa isang tiyak na estado ay tinatawag mga aksyon.

Ang mga diagram ng estado ay hindi kailangang gawin para sa bawat klase, nalalapat lamang ang mga ito sa napakasalimuot na mga kaso. Kung ang isang bagay ng klase ay maaaring umiral sa ilang mga estado at kumilos nang iba sa bawat isa sa kanila, malamang na kakailanganin nito ang gayong diagram. Gayunpaman, sa maraming mga proyekto hindi sila ginagamit sa lahat. Kung, gayunpaman, ginawa ang mga diagram ng estado, maaaring gamitin ng mga developer ang mga ito kapag lumilikha ng mga klase.

Ang mga diagram ng estado ay kinakailangan pangunahin para sa mga layunin ng dokumentasyon.

10.4.7. Mga diagram ng bahagi

Ipinapakita ng mga component diagram kung ano ang hitsura ng modelo sa pisikal na layer. Inilalarawan nito ang mga bahagi ng software ng iyong system at ang mga koneksyon sa pagitan nila. Kasabay nito, dalawang uri ng mga bahagi ang nakikilala: mga executable na bahagi at mga library ng code.

Sa fig. Inilalarawan ng 10.6 ang isa sa mga component diagram para sa isang ATM system. Ang diagram na ito ay nagpapakita ng mga bahagi ng isang ATM system client. Sa kasong ito, nagpasya ang development team na buuin ang system gamit ang C ++ na wika. Ang bawat klase ay may sariling header file at file na may extension. CPP upang ang bawat klase ay maimapa sa sarili nitong mga bahagi sa diagram. Ang naka-highlight na madilim na bahagi ay tinatawag detalye ng pakete at tumutugma sa body file ng klase ng ATM sa C ++ (file na may extension na .CPP). Ang hindi napiling bahagi ay tinatawag ding detalye ng package, ngunit tumutugma ito sa C ++ class header file (file na may extension na .H). Bahagi ng ATM. Ang exe ay isang detalye para sa isang gawain at kumakatawan sa daloy ng pagproseso ng impormasyon. Sa kasong ito, ang isang thread ng pagproseso ay isang maipapatupad na programa.

Ang mga bahagi ay konektado sa pamamagitan ng isang putol-putol na linya na nagpapakita ng mga dependency sa pagitan ng mga ito. Maaaring magkaroon ng maraming component diagram ang isang system, depende sa bilang ng mga subsystem o executable. Ang bawat subsystem ay isang pakete ng mga bahagi.

Ang mga component diagram ay ginagamit ng mga kalahok sa proyekto na responsable sa pag-compile ng system. Ang component diagram ay nagbibigay sa iyo ng ideya ng pagkakasunud-sunod kung saan dapat i-compile ang mga bahagi, pati na rin kung aling mga executable na bahagi ang bubuo ng system. Ipinapakita ng diagram ang pagsusulatan ng mga klase sa mga ipinatupad na bahagi. Kaya, ito ay kinakailangan kung saan nagsisimula ang pagbuo ng code.

kanin. 10.6. Component diagram

10.4.8. Mga diagram ng pagkakalagay

Ipinapakita ng mga placement diagram ang pisikal na lokasyon ng iba't ibang bahagi ng system sa isang network. Sa aming halimbawa, ang ATM system ay binubuo ng isang malaking bilang ng mga subsystem na tumatakbo sa magkahiwalay na mga pisikal na device o node. Ang layout diagram para sa ATM system ay ipinapakita sa Fig. 10.7.

Mula sa diagram na ito, maaari mong malaman ang tungkol sa pisikal na lokasyon ng system. Ang mga programa ng kliyente ng ATM ay tatakbo sa maraming lokasyon sa iba't ibang mga site. Makikipag-ugnayan ang mga kliyente sa regional ATM server sa pamamagitan ng mga saradong network. Tatakbo ito sa software ng ATM server. Sa turn, sa pamamagitan ng lokal na network, ang regional server ay makikipag-ugnayan sa banking database server na tumatakbo sa Oracle. Sa wakas, nakakonekta ang isang printer sa regional ATM server.

Kaya ang diagram na ito ay nagpapakita ng pisikal na lokasyon ng system. Halimbawa, ang aming ATM system ay sumusunod sa isang three-tier na arkitektura, na ang unang baitang ay nagho-host ng database, ang pangalawa sa rehiyonal na server, at ang pangatlo sa kliyente.

10.7. Diagram ng pagkakalagay

Ang layout diagram ay ginagamit ng project manager, user, system architect, at operations staff para malaman ang pisikal na layout ng isang system at ang lokasyon ng mga indibidwal na subsystem nito. Ipapaliwanag ng project manager sa mga user kung ano ang magiging hitsura ng tapos na produkto. Ang mga tauhan ng operating ay makakapagplano ng gawaing pag-install ng system.

Mula sa aklat ng Microsoft Office may-akda Leontiev Vitaly Petrovich

Mga Diagram Ang mga numero sa talahanayan ay hindi palaging nagbibigay ng kumpletong impression, kahit na ang mga ito ay pinagsunod-sunod sa pinaka-maginhawang paraan para sa iyo. Gamit ang mga template ng chart na available sa Microsoft Excel, maaari kang makakuha ng visual na larawan ng iyong data ng spreadsheet nang wala

Mula sa aklat na Computer 100. Pagsisimula sa Windows Vista may-akda Zozulya Yuri

Diagram Ang mga diagram ay ginagamit upang ipakita ang tabular na data sa isang graphical na anyo, na maaaring makabuluhang mapabuti ang kalinawan ng impormasyon, ipakita ang ratio ng iba't ibang mga parameter o ang dynamics ng kanilang pagbabago. Upang magpasok ng mga chart sa Word, gamitin ang mga tool

Mula sa aklat na Effective Office Work may-akda Ptashinsky Vladimir Sergeevich

Mga Tsart Ang pinaka-visual na tampok ng Excel ay ang pagtatanghal ng mga resulta ng mga kalkulasyon o naipon na data sa anyo ng mga graph (mga tsart): kung minsan ang mga pinaka-kahanga-hangang figure ay hindi makumbinsi kung paano ito magagawa gamit ang kahit simpleng graphics. Ang Excel ay mayroon

Mula sa isang Excel workbook. Kurso sa multimedia ang may-akda Medinov Oleg

Kabanata 8 Charts Ang Excel ay kadalasang ginagamit upang lumikha ng mga dokumento na kumakatawan sa iba't ibang istatistika at analytical na ulat. Ang mga ito ay maaaring mga ulat sa pagbebenta, mga talahanayan ng mga sukat ng temperatura ng hangin, data mula sa mga poll ng opinyon, atbp. Ang mga numero ay hindi palaging

Mula sa aklat na Word 2007 Popular tutorial may-akda Krainsky I

Pagbuo ng diagram Para sa unang halimbawa, kakailanganin mong likhain ang talahanayan na ipinapakita sa Fig. 8.1. kanin. 8.1. Talahanayan ng Pagsukat ng Temperatura Bubuo tayo ng isang simpleng graph ng temperatura batay sa datos sa talahanayang ito. Piliin ang napunong hanay sa talahanayan. Pumunta sa

Mula sa aklat na Gabay sa Pag-aaral sa sarili para sa pagtatrabaho sa isang computer may-akda Kolisnichenko Denis Nikolaevich

6.6. Mga Chart Bilang karagdagan sa mga graphic na file, maaari kang magpasok ng mga chart sa mga dokumento ng Word. Sa tulong ng mga diagram, maaari mong mailarawan ang numerical na data, halimbawa, subaybayan kung paano nagbabago ang data, tingnan ang pagbuo ng isang proyekto sa dynamics. Ang mga diagram ay magkatulad

Mula sa aklat na Object Oriented Analysis and Design with C ++ Application Examples may-akda Butch Grady

14.9. Mga Chart Marahil ay oras na para gawing graphics ang mga tuyong numero, na ginagawang mas maganda at nagbibigay-kaalaman ang aming talahanayan? Para dito, ginagamit ang mga diagram. Sabihin kung ano ang gusto mo, ngunit ang isang tsart ay itinuturing na mas mahusay kaysa sa isang talahanayan. Upang bumuo ng isang tsart, kailangan mong piliin ang mga halaga kung saan

Mula sa aklat na Programming Technologies may-akda Kamaev VA

5.2. Mga Class Diagram na Mahahalaga: Mga Klase at ang Relasyon sa Pagitan Nila Ang isang class diagram ay nagpapakita ng mga klase at ang kanilang mga relasyon, kaya kumakatawan sa lohikal na aspeto ng isang proyekto. Ang isang hiwalay na diagram ng klase ay nagbibigay ng isang tiyak na pagtingin sa istraktura ng klase. Sa yugto ng pagsusuri, kami

Mula sa aklat na Modeling Business Processes with BPwin 4.0 may-akda Maklakov Sergey Vladimirovich

5.4. Object Diagrams Essential: Objects and their Relationships Ang isang object diagram ay nagpapakita ng mga umiiral na bagay at ang kanilang mga relasyon sa lohikal na disenyo ng system. Sa madaling salita, ang object diagram ay isang snapshot ng daloy ng mga kaganapan sa ilang configuration.

Mula sa OrCAD PSpice book. Pagsusuri ng electrical circuit ni Keown J.

5.7. Mga diagram ng proseso. Mahalaga: Ang mga Processor, Device, at Connections Process diagram ay ginagamit upang ipakita ang pamamahagi ng mga proseso sa mga processor sa pisikal na disenyo ng isang system. Paghiwalayin ang diagram ng proseso na nagpapakita ng isang view ng istraktura ng proseso

Mula sa VBA Book for Dummies may-akda Cummings Steve

10.4. UML DIAGRAMS 10.4.1. Mga uri ng visual diagram Ang UMLUML ay nagbibigay-daan sa iyo na lumikha ng ilang uri ng visual diagram: use case diagram; mga diagram ng pagkakasunud-sunod; mga tsart ng kooperatiba; mga diagram ng klase; diagram ng estado; mga tsart

Mula sa aklat na Tutorial para sa Macintosh may-akda na si Skrylina Sophia

1.2.6. Diagram ng wireframe Ang 1.2.26 ay nagpapakita ng tipikal na halimbawa ng decomposition diagram na may mga bounding box, na tinatawag na wireframe diagram. kanin. 1.2.26. Halimbawa ng Decomposition Diagram na may Wireframe Ang wireframe ay naglalaman ng header (itaas ng frame) at footer (ibaba).

Mula sa aklat ng may-akda

Mga Timing Diagram Upang makuha ang mga timing diagram ng input at output voltages, kailangan mong bahagyang baguhin ang input file. Tulad ng sa nakaraang halimbawa, isang sinusoidal input voltage ang gagamitin: Vi 1 0 sin (0 0.5V 5kHz) Kasama ng transient analysis

Mula sa aklat ng may-akda

Mga Chart at graph Ang isang espesyalista lamang ang makakaunawa sa kahulugan sa likod ng walang katapusang serye ng mga numero, ngunit ang lahat ay makakaunawa (o kahit man lang magpahayag na naiintindihan nila) ang isang histogram o pie chart. Ang VBA ay walang mga built-in na tool sa pag-chart, ngunit ganoon

Mula sa aklat ng may-akda

5.1.14. Mga Tsart Ang mga Tsart ay isang graphical na representasyon ng numerical table data. Nag-aalok ang mga page ng ilang uri ng mga chart: Column, Stacked Column, Bar, Stacked Bar, Line, Area, Stacked Area

Mula sa aklat ng may-akda

5.2.8. Mga Tsart Ang tsart ay isang graphical na representasyon ng data mula sa isang napiling hanay. Upang bumuo ng isang tsart, sundin ang algorithm sa ibaba: 1. Gumawa ng talahanayan ng mga kalkuladong halaga. 2. Piliin ang kinakailangang hanay (maaari itong binubuo ng hindi katabing hugis-parihaba

Ang UML ay isang pangkalahatang layunin na graphical modeling language para sa pagtukoy, pagsasalarawan, pagdidisenyo, at pagdodokumento ng lahat ng artifact na nilikha sa pagbuo ng mga software system.

Maraming magagandang libro na naglalarawan nang detalyado tungkol sa UML (sa ilang mga lugar kahit na sa napakahusay na detalye), gusto kong kolektahin sa isang lugar ang mga pangunahing konsepto tungkol sa mga diagram, entity at koneksyon sa pagitan ng mga ito para sa mabilis na paggunita, tulad ng isang cheat sheet .

Ang tala ay gumagamit ng mga materyales mula sa mga aklat: Ivanov D. Yu., Novikov F. A. Pinag-isang Modeling Language UML at Leonenkov. Tutorial sa UML.

Una, magpasya tayo sa editor. Sa ilalim ng Linux, sinubukan ko ang iba't ibang mga editor ng UML, higit sa lahat nagustuhan ko ang UMLet, kahit na nakasulat ito sa Java, mabilis itong gumagalaw at karamihan sa mga template ng entity ay nasa loob nito. Mayroon ding ArgoUML, isang cross-platform na UML editor, na nakasulat din sa Java, mayaman sa pagganap, ngunit mas nagpapabagal.

Nag-ayos na ako UMLet, itakda ito sa ilalim Arch Linux at Ubuntu:

# para sa Arch Linux yaourt -S umlet # Para sa Ubuntu sudo apt-get install umlet

Sa UML, ang lahat ng entity ay maaaring hatiin sa mga sumusunod na uri:

• istruktura;
• pag-uugali;
• pagpapangkat;
• anotasyon;

Mayroong apat na pangunahing uri ng mga ugnayang ginagamit sa UML:

Dependency- nagsasaad na ang pagpapalit ng independiyenteng entity kahit papaano ay nakakaapekto sa umaasang entity. Sa graphically, ang isang dependency na relasyon ay inilalarawan bilang isang dashed line na may arrow na tumuturo mula sa dependent entity patungo sa independent entity.

Samahan- nagaganap kung ang isang entity ay direktang nauugnay sa isa pa (o sa iba - ang asosasyon ay maaaring hindi lamang binary). Ang isang asosasyon ay graphic na inilalarawan bilang isang solidong linya na may iba't ibang mga karagdagan na nagkokonekta sa mga kaugnay na entity.

Paglalahat ay isang relasyon sa pagitan ng dalawang entity, ang isa sa mga ito ay isang espesyal na (espesyalisadong) kaso ng isa pa. Sa graphically, ang generalization ay inilalarawan bilang isang linya na may triangular, unshaded arrow sa dulo, na nakadirekta mula sa partikular (subclass) hanggang sa general (superclass).

Pagpapatupad- isang ugnayan sa pagpapatupad ay nagpapahiwatig na ang isang entity ay isang pagpapatupad ng isa pa. Sa graphically, ang pagpapatupad ay inilalarawan bilang isang dashed line na may triangular, unshaded arrow sa dulo, na nakadirekta mula sa realizing entity hanggang sa realizable.

V UML 2 ay tinukoy 13 mga uri ng mga tsart. Ayon sa mga pamantayan, ang bawat chart ay dapat na may isang kahon na may parihaba (ibabang kanang sulok na beveled) sa kaliwang sulok sa itaas, na nagpapahiwatig ng chart ID (tag) at pamagat.

Mga diagram para sa paglalarawan ng istraktura ng system:

• Component diagram (tag sangkap);
• Diagram ng deployment (tag deployment);
• Class diagram (class diagram, tag klase);
• Diagram ng bagay (tag bagay);
• Diagram ng panloob na istraktura (composite structure diagram, tag klase);

Mga diagram para sa paglalarawan ng gawi ng system:

• Diagram ng pakikipag-ugnayan (tag timing);
• Diagram ng aktibidad (tag aktibidad);
• Sequence diagram (tag sd);
• Diagram ng komunikasyon (tag comm);
• Diagram ng makina ng estado (tag makina ng estado);
• Tag ng diagram ng pangkalahatang-ideya ng pakikipag-ugnayan pakikipag-ugnayan);

Magkahiwalay ang mga diagram:

• Usage diagram (use case diagram, use case tag);
• Package diagram (tag pakete);

Diagram ng paggamit

Diagram ng paggamit(use case diagram) ay ang pinaka-pangkalahatang representasyon ng functional na layunin ng system.

Isinasaalang-alang ang isang use-case diagram bilang isang modelo ng isang system, maaari itong iugnay sa isang modelo ng black box. Ang bawat use case ay tumutukoy sa isang pagkakasunud-sunod ng mga aksyon na dapat gawin ng dinisenyong system kapag nakipag-ugnayan ito sa kaukulang aktor.

Gumagamit ang diagram ng paggamit ng dalawang uri ng mga pangunahing entity: use case at mga aktor, kung saan itinatag ang mga sumusunod na pangunahing uri ng mga relasyon.

Relasyon ng samahan- Ang relasyon na ito ay nagtatatag kung anong partikular na papel ang ginagampanan ng isang aktor kapag nakikipag-ugnayan sa isang instance ng isang use case. Ang isang kaugnayang kaugnayan ay ipinapahiwatig ng isang solidong linya sa pagitan ng aktor at ng use case. Ang linyang ito ay maaaring magkaroon ng mga karagdagang simbolo tulad ng pangalan at multiplicity.

Pagpapalawak ng ratio- tumutukoy kung paano nauugnay ang mga instance ng isang partikular na use case sa isang mas pangkalahatang use case, ang mga katangian nito ay tinutukoy batay sa kung paano pinagsama-sama ang mga instance na ito. Kaya, kung mayroong kaugnayan sa extension mula sa use case A hanggang sa case B, nangangahulugan ito na ang mga katangian ng instance ng use case B ay maaaring dagdagan dahil sa pagkakaroon ng mga property sa extended use case A.

Ang isang extension na relasyon sa pagitan ng mga use case ay ipinapahiwatig ng isang dashed line na may isang arrow (dependency relationship case) na nakaturo palayo sa use case na isang extension sa orihinal na use case.

Relasyon sa paglalahat nagsisilbing ipahiwatig ang katotohanan na ang isang partikular na kaso ng paggamit A ay maaaring gawing pangkalahatan upang gamitin ang kaso B. Sa kasong ito, ang opsyon A ay magiging isang espesyalisasyon ng opsyon B. Sa kasong ito, ang B ay tinatawag na isang ninuno o magulang na may kaugnayan sa A, at Ang opsyon A ay isang inapo kaugnay ng opsyon na paggamit ng V.

Sa graphically, ang ugnayang ito ay ipinapahiwatig ng isang solidong linya na may bukas na tatsulok na arrow na nagpapahiwatig ng kaso ng paggamit ng magulang.

Ang isang pangkalahatang ugnayan sa pagitan ng mga kaso ng paggamit ay ginagamit kapag kinakailangang tandaan na ang mga kaso ng paggamit ng bata ay may lahat ng mga katangian at gawi ng mga kaso ng paggamit ng magulang.

ratio ng pagsasama sa pagitan ng dalawang kaso ng paggamit ay nagpapahiwatig na ang ilang tinukoy na gawi para sa isang use case ay kasama bilang isang pinagsama-samang bahagi sa pagkakasunud-sunod ng pag-uugali ng isa pang use case.

Ang ugnayan ng pagsasama mula sa use case A hanggang sa use case B ay nagpapahiwatig na ang bawat instance ng opsyon A ay kinabibilangan ng functionality na tinukoy para sa opsyon B.

Sa graphically, ang relasyong ito ay tinutukoy ng isang dashed line na may isang arrow (dependency relationship case) na tumuturo mula sa base use case hanggang sa kasamang use case.

Class diagram

Class diagram(class diagram) ay ang pangunahing paraan upang ilarawan ang static na istraktura ng isang system.

Sa isang diagram ng klase, isang pangunahing uri ng mga entity ang ginagamit: mga klase (kabilang ang maraming mga espesyal na kaso ng mga klase: mga interface, primitive na uri, mga klase ng asosasyon, atbp.), Sa pagitan ng kung saan ang mga sumusunod na pangunahing uri ng mga relasyon ay itinatag: dependencies, asosasyon, generalizations , mga pagpapatupad.

Relasyon sa adiksyon karaniwang nagpapahiwatig ng ilang semantikong ugnayan sa pagitan ng dalawang elemento ng modelo o dalawang hanay ng naturang mga elemento na hindi isang kaugnayan, paglalahat, o pagpapatupad ng relasyon. Ang isang dependency na relasyon ay ginagamit sa isang sitwasyon kung saan ang ilang pagbabago sa isang elemento ng modelo ay maaaring mangailangan ng pagbabago sa isa pang umaasa na elemento sa modelo.

Ang isang dependency na relasyon ay graphic na inilalarawan na may tuldok-tuldok na linya sa pagitan ng mga katumbas na elemento na may arrow sa isa sa mga dulo nito, na may arrow na tumuturo mula sa dependency client class patungo sa independent o source class.

Maaaring may mga espesyal na keyword (stereotypes) sa itaas ng arrow:

• "access" - nagsisilbing ipahiwatig ang pagiging naa-access ng mga pampublikong katangian at pagpapatakbo ng source class para sa mga klase ng kliyente;
• "bind" - ang klase ng kliyente ay maaaring gumamit ng ilang template para sa kasunod na parameterization nito;
• "nagmula" - ang mga katangian ng klase ng kliyente ay maaaring kalkulahin mula sa mga katangian ng pinagmulang klase;
• "import" - ang mga pampublikong katangian at pagpapatakbo ng pinagmulang klase ay naging bahagi ng klase ng kliyente, na parang direktang ipinahayag dito;
• "pinuhin" - nagsasaad na ang klase ng kliyente ay nagsisilbing isang pagpipino ng klase ng pinagmulan para sa mga makasaysayang dahilan, kapag lumilitaw ang karagdagang impormasyon sa panahon ng trabaho sa proyekto.

Relasyon ng samahan tumutugma sa pagkakaroon ng ilang relasyon sa pagitan ng mga klase. Ang relasyon na ito ay tinutukoy ng isang solidong linya na may karagdagang mga espesyal na character na nagpapakilala sa mga indibidwal na katangian ng isang partikular na asosasyon. Ang pangalan ng asosasyon, pati na rin ang mga pangalan at multiplicity ng mga klase ng tungkulin ng asosasyon, ay maaaring gamitin bilang karagdagang mga espesyal na character. Ang pangalan ng asosasyon ay isang opsyonal na elemento ng pagtatalaga nito.

Aggregation ratio nagaganap sa pagitan ng ilang mga klase kung sakaling ang isa sa mga klase ay isang partikular na entity na kinabibilangan ng iba pang mga entity bilang mga bahaging bumubuo. Ito ay ginagamit upang kumatawan sa part-to-whole system relationships.

Relasyon ng komposisyon ay isang espesyal na kaso ng isang pinagsama-samang ugnayan. Ang ugnayang ito ay nagsisilbing i-highlight ang isang espesyal na anyo ng relasyon na "bahagi-buong", kung saan ang mga bumubuong bahagi, sa isang kahulugan, ay nasa loob ng kabuuan. Ang pagtitiyak ng ugnayan sa pagitan ng mga ito ay nakasalalay sa katotohanan na ang mga bahagi ay hindi maaaring kumilos nang hiwalay mula sa kabuuan, iyon ay, sa pagkasira ng kabuuan, ang lahat ng mga bahagi nito ay nawasak.

Relasyon sa paglalahat ay isang relasyon sa pagitan ng isang mas pangkalahatang elemento (magulang o ninuno) at isang mas pribado o espesyal na elemento (anak o inapo). Kapag inilapat sa isang class diagram, inilalarawan ng relasyong ito ang hierarchical na istraktura ng mga klase at ang pamana ng kanilang mga katangian at pag-uugali. Ipinapalagay na ang descendant class ay may lahat ng katangian at pag-uugali ng ancestor class, at mayroon ding sariling mga katangian at pag-uugali na wala sa ancestor class.

Automaton diagram

Automaton diagram(diagram ng makina ng estado) o diagram ng estado sa UML 1 (state chart diagram) ay isang paraan upang ilarawan ang pag-uugali sa UML nang detalyado. Sa esensya, ang mga diagram ng automat, gaya ng ipinahihiwatig ng pangalan, ay isang graph ng mga estado at mga transition ng isang may hangganan na automat na puno ng maraming karagdagang detalye at detalye.

Ang isang state diagram ay naglalarawan sa proseso ng pagbabago ng mga estado ng isang klase lamang, o sa halip, isang instance ng isang partikular na klase, iyon ay, ito ay modelo ng lahat ng posibleng pagbabago sa estado ng isang partikular na bagay. Sa kasong ito, ang isang pagbabago sa estado ng isang bagay ay maaaring sanhi ng mga panlabas na impluwensya mula sa iba pang mga bagay o mula sa labas. Ito ay upang ilarawan ang reaksyon ng isang bagay sa mga panlabas na impluwensya na ginagamit ang mga diagram ng estado.

Sa diagram ng automat, isang pangunahing uri ng entity ang ginagamit - mga estado, at isang uri ng relasyon - mga paglipat, ngunit para sa pareho, maraming mga uri, mga espesyal na kaso at karagdagang mga notasyon ang tinukoy. Kinakatawan ng automaton ang mga dynamic na aspeto ng nakamodelong sistema sa anyo ng isang nakadirekta na graph, ang mga vertices nito ay tumutugma sa mga estado, at ang mga arko ay tumutugma sa mga transition.

Paunang estado ay isang espesyal na kaso ng isang estado na hindi naglalaman ng anumang mga panloob na aksyon (pseudo states). Ang default na bagay ay nasa ganitong estado sa paunang sandali sa oras. Nagsisilbi itong ipahiwatig sa diagram ng estado ang lugar ng graphics kung saan nagsisimula ang proseso ng paglipat ng estado.

pangwakas (final) ang isang estado ay isang espesyal na kaso ng isang estado na hindi rin naglalaman ng anumang mga panloob na aksyon (pseudo-states). Ang default na object ay nasa ganitong estado pagkatapos ng automaton na matapos ang trabaho nito sa huling sandali ng oras.

Diagram ng aktibidad

Kapag nagmomodelo ng pag-uugali ng isang dinisenyo o nasuri na sistema, ito ay nagiging kinakailangan hindi lamang upang kumatawan sa proseso ng pagbabago ng mga estado nito, ngunit din upang i-detalye ang mga tampok ng algorithmic at lohikal na pagpapatupad ng mga operasyon na isinagawa ng system.

Diagram ng aktibidad(activity diagram) ay isa pang paraan ng paglalarawan ng gawi na biswal na kahawig ng magandang lumang flowchart ng algorithm. Ginagamit upang gayahin ang proseso ng pagsasagawa ng mga operasyon.

Ang pangunahing direksyon ng paggamit ng mga diagram ng aktibidad ay upang mailarawan ang mga kakaibang katangian ng pagpapatupad ng mga operasyon ng klase, kapag kinakailangan upang ipakita ang mga algorithm para sa kanilang pagpapatupad.

Sa diagram ng aktibidad, isang pangunahing uri ng entity ang ginagamit - aksyon, at isang uri ng relasyon - mga transition (paglilipat ng kontrol). Ginagamit din ang mga konstruksyon tulad ng mga tinidor, pagsasanib, pagsali, mga sanga. Inirerekomenda na gumamit ng isang pandiwa na may mga salitang nagpapaliwanag bilang isang simpleng pangalan ng aksyon.

Sequence diagram

Sequence diagram(sequence diagram) ay isang paraan upang ilarawan ang gawi ng system "sa pamamagitan ng mga halimbawa".

Sa katunayan, ang isang diagram ng pagkakasunud-sunod ay isang talaan ng isang protocol ng isang partikular na session ng pagpapatakbo ng system (o isang fragment ng naturang protocol). Sa object-oriented programming, ang pinakamahalagang run-time ay ang paglipat ng mga mensahe sa pagitan ng mga bagay na nakikipag-ugnayan. Ito ay ang pagkakasunod-sunod ng pagpapadala ng mga mensahe na ipinapakita sa diagram na ito, kaya ang pangalan.

Sa sequence diagram, isang pangunahing uri ng entity ang ginagamit - mga pagkakataon ng mga nakikipag-ugnayang classifier (pangunahin ang mga klase, bahagi at aktor), at isang uri ng relasyon - ang mga link kung saan ang mga mensahe ay ipinagpapalit.

Mga posibleng uri ng mensahe (larawan na kinuha mula sa larin.in):

Diagram ng komunikasyon

Diagram ng komunikasyon(diagram ng komunikasyon) - isang paraan ng paglalarawan ng pag-uugali, na katumbas ng semantiko sa isang sequence diagram. Sa katunayan, ito ang parehong paglalarawan ng pagkakasunud-sunod ng pagpapalitan ng mensahe ng mga nag-uugnay na instance ng classifier, na ipinahayag lamang sa iba pang mga graphical na paraan.

Kaya, sa diagram ng komunikasyon, pati na rin sa diagram ng pagkakasunud-sunod, isang pangunahing uri ng entity ang ginagamit - mga pagkakataon ng nakikipag-ugnayan na mga classifier at isang uri ng relasyon - mga link. Gayunpaman, ang diin dito ay hindi sa oras, ngunit sa istruktura ng mga link sa pagitan ng mga partikular na pagkakataon.

Component diagram

Component diagram(component diagram) - nagpapakita ng ugnayan sa pagitan ng mga module (lohikal o pisikal) na bumubuo sa simulate system.

Ang pangunahing uri ng mga entity sa isang component diagram ay ang mga mismong bahagi, pati na rin ang mga interface kung saan ipinapahiwatig ang ugnayan sa pagitan ng mga bahagi. Sa isang component diagram, nalalapat ang mga sumusunod na ugnayan:

• mga pagpapatupad sa pagitan ng mga bahagi at mga interface (ang isang bahagi ay nagpapatupad ng isang interface);
• dependencies sa pagitan ng mga bahagi at mga interface (ang isang bahagi ay gumagamit ng isang interface);

Diagram ng pagkakalagay

Diagram ng pagkakalagay(deployment diagram), kasama ang pagpapakita ng komposisyon at mga ugnayan ng mga elemento ng system, ay nagpapakita kung paano sila pisikal na matatagpuan sa mga mapagkukunan ng computing sa runtime.

Sa placement diagram, kung ihahambing sa component diagram, dalawang uri ng entity ang idinaragdag: isang artifact, na kung saan ay ang pagpapatupad ng isang component at isang node (maaaring ito ay isang classifier na naglalarawan sa uri ng isang node, o isang partikular na instance. ), pati na rin ang isang kaugnayan sa pagitan ng mga node, na nagpapakita na ang mga node ay pisikal na konektado sa runtime.

Diagram ng bagay

Diagram ng bagay(object diagram) - ay isang instance ng class diagram.

Sa object diagram, isang pangunahing uri ng entity ang ginagamit: mga object (class instance), kung saan ipinahiwatig ang mga partikular na relasyon (madalas, association instance). Ang mga Object diagram ay may likas na pantulong - sa katunayan, ang mga ito ay mga halimbawa (maaaring sabihin ng isa, memory dumps) na nagpapakita kung ano ang mga bagay at ang mga koneksyon sa pagitan ng mga ito sa ilang partikular na sandali sa paggana ng system.

Diagram ng panloob na istraktura(composite structure diagram) ay ginagamit para sa isang mas detalyadong presentasyon ng mga structural classifier, pangunahin ang mga klase at mga bahagi.

Ang structural classifier ay inilalarawan bilang isang parihaba, sa itaas na bahagi nito ay ang pangalan ng classifier. Nasa loob ang mga bahagi. Maaaring may ilang bahagi. Ang mga bahagi ay maaaring makipag-ugnayan sa isa't isa. Ito ay ipinahiwatig gamit ang mga konektor ng iba't ibang uri. Ang lokasyon sa panlabas na gilid ng bahagi kung saan nakakabit ang connector ay tinatawag na port. Ang mga port ay matatagpuan din sa panlabas na gilid ng structural classifier.

Diagram ng pangkalahatang-ideya ng pakikipag-ugnayan Ang isang diagram ng pangkalahatang-ideya ng pakikipag-ugnayan ay isang uri ng diagram ng aktibidad na may pinahabang syntax: ang mga link sa paggamit ng pakikipag-ugnayan na tinukoy ng mga sequence diagram ay maaaring kumilos bilang mga elemento ng isang diagram ng pangkalahatang-ideya ng pakikipag-ugnayan.

Diagram ng pag-synchronize

Diagram ng pag-synchronize(timing diagram) ay isang espesyal na anyo ng sequence diagram, kung saan ang espesyal na atensyon ay binabayaran sa pagbabago ng mga estado ng iba't ibang pagkakataon ng mga classifier at ang kanilang timing.

Package diagram

Package diagram(package diagram) ay ang tanging tool na nagbibigay-daan sa iyong pamahalaan ang pagiging kumplikado ng mismong modelo.

Ang mga pangunahing elemento ng notasyon ay mga pakete at dependency na may iba't ibang stereotype.

Entity-relationship model (ER-model)

Analogue mga diagram ng klase(UML) siguro modelo ng ER, na ginagamit sa disenyo ng mga database (relational model).

Ang entity-relationship model (ER-model) ay isang modelo ng data na nagbibigay-daan sa iyong ilarawan ang mga konseptwal na schema ng domain. Ang modelong ER ay ginagamit sa mataas na antas (konsepto) na disenyo ng database. Sa tulong nito, posibleng i-highlight ang mga pangunahing entity at italaga ang mga koneksyon na maaaring maitatag sa pagitan ng mga entity na ito. wikipedia

Ang anumang fragment ng lugar ng paksa ay maaaring katawanin bilang isang hanay ng mga entity, kung saan mayroong isang bilang ng mga koneksyon.

Pangunahing konsepto:

Ang kakanyahan(entity) ay isang entity na maaaring makilala sa ilang paraan na nagpapaiba nito sa ibang entity, halimbawa CLIENT 777... Ang isang entity ay talagang isang hanay ng mga katangian.

Set ng entity(entity set) - isang set ng mga entity ng parehong uri (na may parehong mga katangian).

Koneksyon(relasyon) ay isang asosasyong itinatag sa pagitan ng maraming entity.

Domain(domain) - isang hanay ng mga halaga (saklaw) ng isang katangian.

May tatlong uri ng binary links:

• isa sa isa- isang instance ng isang entity ng isang klase ay nauugnay sa isang instance ng isang entity ng isa pang klase, halimbawa, HEAD - DEPARTMENT;
• 1 hanggang N o isa sa marami- ang isang solong instance ng isang entity ng isang klase ay nauugnay sa maraming mga pagkakataon ng isang entity ng isa pang klase, halimbawa, DEPARTMENT - EMPLOYEE;
• N hanggang M o marami sa marami- maraming instance ng entity ng isang klase ang nauugnay sa maraming instance ng entity ng ibang klase, halimbawa, EMPLOYEE - PROJECT;
Isang glossary ng mga pangunahing konsepto ng UML

bagay- isang entity na natatangi at sumasaklaw sa estado at pag-uugali.

Klase- isang paglalarawan ng isang hanay ng mga bagay na may mga karaniwang katangian na tumutukoy sa estado at mga operasyon na tumutukoy sa pag-uugali.

Interface- isang pinangalanang hanay ng mga operasyon na tumutukoy sa isang hanay ng mga serbisyo na maaaring hilingin ng isang consumer at ibigay ng isang service provider.

Pakikipagtulungan- isang hanay ng mga bagay na nakikipag-ugnayan upang makamit ang isang layunin.

Aktor- isang entity na nasa labas ng modelong sistema at direktang nakikipag-ugnayan dito.

Bahagi- isang modular na bahagi ng system na may mahusay na tinukoy na hanay ng mga kinakailangan at ibinigay na mga interface.

artifact- isang item ng impormasyon na ginagamit o nabuo sa proseso ng pagbuo ng software. Sa madaling salita, ang artifact ay isang pisikal na yunit ng pagpapatupad na nagmula sa isang elemento ng modelo (tulad ng isang klase o bahagi).

Node- isang mapagkukunan ng computing kung saan matatagpuan ang mga artifact at, kung kinakailangan, ay isinasagawa.

Ang mga entity sa pag-uugali ay nilayon upang ilarawan ang pag-uugali. Mayroon lamang dalawang pangunahing entity sa pag-uugali: estado at pagkilos.

Estado- isang panahon sa siklo ng buhay ng isang bagay, kung saan ang bagay ay natutugunan ang isang tiyak na kondisyon at nagsasagawa ng sarili nitong aktibidad o naghihintay para sa paglitaw ng ilang kaganapan.

Aksyon- primitive atomic computation.

makina ay isang pakete na tumutukoy sa isang hanay ng mga konsepto na kinakailangan upang kumatawan sa pag-uugali ng isang modelong entity sa anyo ng isang discrete space na may isang tiyak na bilang ng mga estado at mga transition.

Classifier ay isang descriptor ng isang set ng mga bagay na may parehong uri.

Karagdagang pagbabasa

• Fowler M. UML. Fundamentals, 3rd Edition
• Booch G., Rambeau D., Jacobson I. UML. Gabay sa gumagamit