Ang class diagram ay sentro sa disenyo ng isang object-oriented system. Ginagamit ang notasyon ng klase sa iba't ibang yugto ng disenyo at itinayo na may iba't ibang antas ng detalye. Ang wikang UML ay ginagamit hindi lamang para sa disenyo, ngunit para din sa layunin ng pagdodokumento at pag-sketch ng isang proyekto. Ako (hindi tulad ng Gradi Bucha) ay hindi isang tagasuporta ng pagbuo ng isang proyekto gamit ang lahat ng uri ng mga diagram ng UML, pati na rin ang detalyadong disenyo. Madalas kong ginagamit ang UML para sa sketching at para din sa disenyo gamit ang proseso ng ICONIX. Inilalarawan ng artikulo ang bahagi ng notasyon ng klase ng UML, ang paggamit nito ay sapat sa karamihan ng mga kaso. Walang magiging impormasyon tungkol sa dami ng mga asosasyon at katangian, mga tampok ng representasyon ng mga parallel na operasyon, mga template (mga naka-parameter na klase) at mga paghihigpit. Kung kinakailangan, ang lahat ng impormasyong ito ay matatagpuan sa iba pang mga libro. Limitahan natin ang ating sarili sa pangunahing bahagi ng notasyon at bibigyan natin ng higit na pansin ang paggamit ng mga class diagram.

1 Mga elemento ng diagram ng klase

Gumagamit ang isang class diagram ng mga espesyal na simbolo upang ilarawan ang mga uri ng data ng programa at mga relasyon sa pagitan ng mga ito, bagama't sa ilang mga kaso ay maaaring gamitin ang ilang iba pang mga elemento - mga pakete at maging ang mga instance ng klase (mga bagay).

1.1 Simbolo ng klase

Ang isang simbolo ng klase sa isang diagram ay maaaring magmukhang iba depende sa granularity ng diagram:

Ang mga isyu ng detalye ay tatalakayin sa mga sumusunod na seksyon, ngunit ngayon kailangan nating bigyang-pansin na ang simbolo ng klase ay naglalaman ng isang pangalan (Player), isang hanay ng mga operasyon (move, get_gealth) at mga katangian (pos, state). Para sa mga elemento ng klase, maaaring itakda ang uri, multiplicity, visibility, atbp.:

Format ng detalye ng katangian:
visibility name: type [multiplicity] = default_value

Format ng pagtutukoy ng operasyon:
visibility name(argument: type) = return_value_type

Depende sa setting ng visibility, ang elemento ay maaaring:

• pribado (pribado, magagamit lamang sa loob ng klase) - tinukoy ng minus na simbolo (-), maaaring ipakita bilang isang parisukat;
• protektado (protektado, magagamit sa loob ng klase, pati na rin sa loob ng mga descendant na klase) - na tinukoy ng simbolo ng hash (#), ay maaaring ipakita bilang isang brilyante;
• bukas (pampubliko, magagamit sa lahat) - tinukoy ng plus na simbolo (+), maaaring ipakita bilang isang bilog.

Ang virtual function at abstract na pangalan ng klase ay naka-italicize, habang ang static na function ay may salungguhit.

1.2 Mga relasyon sa klase

Ang isang class diagram ay nagbibigay-daan para sa iba't ibang uri ng mga relasyon, tingnan natin ang mga ito sa bahagi ng diagram ng isang modelo ng isang laro:

Ang laro ay may iba't ibang uri ng mga elemento (mga pader, dibdib, mga character). Ang lahat ng mga elementong ito ay mga tagapagmana ng abstract class na AbstractItem , at ang ilan sa mga ito ay maaaring ilipat (ang mga naturang elemento ay dapat na minana mula sa MovingItem). Inheritance (ang "ay" na relasyon) ay inilalarawan gamit ang isang solidong linya na may saradong arrow na tumuturo patungo sa superclass - sa diagram, ang MovingItem class ay minana mula sa AbstractItem , ang Player class ay minana mula sa MovingItem , atbp. Ang putol-putol na linya na may saradong arrow ay tumutukoy sa isang relasyon sa pagpapatupad (closed inheritance).

Ang isa pang uri ng ugnayan sa pagitan ng mga klase ay ang pagsasama sa object-oriented na programming, mayroong dalawang uri ng relasyong ito: komposisyon at pagsasama-sama. Ipaalala ko sa iyo na ang komposisyon ay isang uri ng pagsasama kapag ang mga bagay ay hindi mapaghihiwalay na nakaugnay sa isa't isa (ang kanilang buhay ay pareho); pinalitan ng isa pang bagay sa panahon ng pagpapatupad ng programa).

Ang ugnayan ng komposisyon ay ipinahiwatig ng isang punong brilyante, na iginuhit mula sa gilid ng kalakip na klase - halimbawa, ang MovingItem class ay kinabibilangan ng Position class, dahil laging may posisyon ang gumagalaw na bagay. Ang ugnayan ng pagsasama-sama ay kinakatawan ng isang bukas na brilyante - pinagsasama-sama ng manlalaro (Manlalaro) ang estado (IPlayerState).

Kung pamilyar ka sa mga pattern ng Estado, Diskarte o Delegasyon, maaari mong laktawan ang seksyong ito.
Ginagamit ng diagram sa itaas ang pattern ng disenyo ng Estado, na isang variation ng pattern ng Delegasyon at malapit sa pattern ng Strategy. Ang kakanyahan ng delegasyon ay upang gawing simple ang lohika ng isang klase, ang bahagi ng gawain nito ay maaaring ilipat (italaga) sa isang auxiliary na klase. Sa turn, ang pattern ng Estado ay maaaring idagdag, halimbawa, sa yugto ng refactoring kung sa ilang mga pag-andar ng isang klase mayroong isang random na pagsusuri ng estado ng isang bagay upang maisagawa ang ilang mga aksyon. Sa aming kaso, ang karakter ay maaaring makipag-ugnayan sa hedgehog, ipagpalagay na kung ang karakter ay gumagalaw habang nakaupo at nakipag-ugnay sa hedgehog, ang kanyang kalusugan ay dapat bumaba, at kung siya ay tatayo, ang kanyang puntos (mga puntos) ay tataas. Bilang karagdagan sa hedgehog, maaaring mayroong pagkain, mga kalaban, mga cartridge, atbp. Upang ipakita ang pattern na ito, isang abstract na klase na IPlayerState at dalawang descendant na StayState at SeatState ay ginawa. Sa klase ng Player, kapag pinindot ang Ctrl button, maaaring magbago ang estado sa SeatState , at kapag inilabas, maaari itong magbago sa StayState . Kaya, kapag nagsasagawa ng state->process_hedgehog(this), ang aming player ay kahit papaano ay makikipag-ugnayan sa hedgehog sa ilang paraan na tinukoy ng object ng estado.

Ang pattern ng disenyo ng Delegation (at lahat ng variation nito) ay isang magandang halimbawa upang ipakita ang pagsasama-sama. Sa aming kaso, maaaring magbago ang estado ng manlalaro sa pamamagitan ng pagpapalit ng object sa pamamagitan ng pointer, i.e. Iba-iba ang buhay ng mga bagay.

Ang pinakakaraniwang uri ng ugnayan sa pagitan ng mga klase ay ang asosasyon, na ipinapahiwatig ng isang solidong linya (kung minsan ay may arrow). Sa pangkalahatan, ang komposisyon, pagsasama-sama, at paglalahat (mana) ay mga espesyal na kaso ng pagkakaugnay. Ipinapakita ng aming diagram ng asosasyon na binabago ng klase ng IPlayerState ang mga istatistika (kalusugan at mga punto) ng object ng Player. Ang isang asosasyon ay maaaring may pangalan ng koneksyon na nagpapaliwanag sa kakanyahan ng relasyon. Ang pangalan ng kaukulang variable ay kadalasang ginagamit bilang pangalan ng mga ugnayan ng komposisyon at pagsasama-sama. Bilang karagdagan, ang asosasyon ay maaaring magkaroon ng multiplicity;

• 1 - isang koneksyon (ipinapakita ng aming diagram na ang isang manlalaro ay may kasamang isang halimbawa ng klase ng IPlayerState);
• * anumang bilang ng mga koneksyon (kung mayroong isang playing field class sa diagram, pagkatapos ay gamit ang isang asterisk posibleng ipakita na maaari itong maglaman arbitrary na numero mga elemento ng laro);
• [from..to] – maaaring tukuyin bilang isang hanay. Kaya ang range ay katumbas ng isang asterisk, ngunit kung gusto nating ipakita na higit sa isang bagay ang dapat naroroon, maaari tayong sumulat

Ang huling uri ng relasyon na isasaalang-alang natin, ang pag-asa, ay inilalarawan ng isang putol-putol na linya. Kung mayroong isang arrow, pagkatapos ito ay nakadirekta mula sa umaasa sa independiyenteng klase, kung walang arrow, kung gayon ang mga klase ay nakasalalay sa bawat isa. Ang ibig sabihin ng dependency ay dependence sa interface, i.e. kung ang interface ng independiyenteng klase ay nagbabago, pagkatapos ay kailangan mong gumawa ng mga pagbabago sa umaasa na klase. Sa aming diagram, nakadepende ang SeatState at StayState sa klase ng Player, dahil bumaling sa kanyang mga pamamaraan upang baguhin ang mga katangian ng manlalaro. Upang kumatawan sa isang relasyong pagkakaibigan sa pagitan ng mga klase, ginagamit ang isang relasyong dependency na may label na kaibigan.

Malinaw, hindi lahat ng uri ng mga relasyon ay nagkakahalaga ng pagpapakita sa diagram at ang ilang mga relasyon ay maaaring palitan ng iba. Kaya, aalisin ko ang mga relasyon sa dependency mula sa aming halimbawa, ngunit sa ilang mga pagkakataon (halimbawa, kapag nag-sketch sa isang marker board) magiging angkop ang mga ito. Ang pag-aayos ng mga multiplicity at mga pangalan ng mga link ay hindi rin isinasagawa sa lahat ng kaso. Sa pangkalahatan, hindi mo dapat ilagay ito sa diagram hindi kinakailangang impormasyon. Ang pangunahing bagay ay ang diagram ay dapat na malinaw.

2 Paggamit ng class diagram

Sinaklaw namin ang mga pangunahing notasyong ginagamit sa mga diagram ng klase - sapat na dapat ang mga ito sa karamihan ng mga kaso. Hindi bababa sa, sa materyal na ito madali mong maunawaan ang mga diagram ng pattern ng disenyo at maunawaan ang sketch ng anumang proyekto. Gayunpaman, paano gumawa ng gayong mga diagram nang tama? Sa anong pagkakasunud-sunod at sa anong antas ng detalye? — ang sagot ay depende sa mga layunin ng pagbuo ng diagram, kaya ang materyal na ipinakita ay hahatiin sa mga subsection alinsunod sa mga layunin ng pagmomodelo.

Kapansin-pansin na ang payo ni Gradi Bucha sa paggamit ng UML ay ibinibigay sa aklat na "User's Guide", ngunit sa kanyang "Object-Oriented Analysis" makakahanap ka ng magagandang halimbawa at pamantayan para sa kalidad ng disenyo. Ganap na iniiwasan ni Leonenkov ang paksang ito, nag-iiwan lamang ng mga sanggunian sa panitikan, nakakita ako ng mga tiyak na rekomendasyon mula kay Larman at Rosenberg, ang ilan sa mga materyal ay batay sa aking personal na karanasan. Tinitingnan ni Fowler ang UML bilang isang sketching tool, kaya mayroon siyang sariling (napakaiba sa Booch at Rosenberg) na view ng class diagram.

2.1 Class diagram bilang isang system dictionary, conceptual model

Ang diksyunaryo ng system ay nabuo nang kahanay sa pagbuo ng diagram ng use case, i.e. teknikal na mga pagtutukoy. Mukhang ganito - tatanungin mo ang customer ng mga tanong tulad ng "ano pa ang magagawa ng user?", "ano ang mangyayari (dapat ibigay ng system) kung mag-click ang user sa<эту>button?", at isulat ang mga sagot sa kanila sa anyo ng isang paglalarawan ng mga nauna. Gayunpaman, ang customer, kapag nagbibigay ng mga sagot, ay maaaring tumawag sa parehong mga bagay sa iba't ibang mga pangalan - mula sa personal na karanasan: kapag sinasabi ang "cell", "intersection", "node" at "cell" ang customer ay maaaring mangahulugan ng parehong bagay. Sa iyong system, ang lahat ng mga konseptong ito ay dapat na kinakatawan ng isang abstraction (class/function/...). Upang gawin ito, kapag nakikipag-usap sa customer, sulit na i-record ang terminolohiya sa anyo ng isang diksyunaryo ng system - ang isang diagram ng klase ay ginagawa ito nang napakahusay.

Upang bumuo ng diksyunaryo ng system, iminumungkahi ni Gradi Booch na gawin ito sa sumusunod na pagkakasunud-sunod:

1. sa pamamagitan ng pagsusuri ng mga nauna, tukuyin kung aling mga elemento ang ginagamit ng mga user at developer upang ilarawan ang isang problema o solusyon nito;
2. tukuyin para sa bawat abstraction ang kaukulang hanay ng mga responsibilidad (responsibilities). Tiyakin ang tamang pamamahagi ng mga responsibilidad (kabilang ang pagsunod);
3. Bumuo ng mga pamamaraan at operasyon para sa mga klase upang maisagawa ang kanilang mga responsibilidad.

Bilang halimbawa, isaalang-alang ang diksyunaryo ng system para sa larong Minesweeper. Ang diagram sa ibaba ay nagpapakita ng bersyon na nagresulta mula sa pagtalakay ng aking estudyante sa problema. Makikita na ang diagram ay naglalarawan ng mga entidad at ang kanilang mga katangian na nauunawaan ng customer ang diagram na ito ay nagkakahalaga ng pagkakaroon ng bago sa iyong mga mata kapag gumuhit ng mga precedent upang hindi matawagan ang "Cell" na "Field", na nanlilinlang sa lahat. Kapag gumagawa ng diksyunaryo ng system, dapat mong iwasan ang pag-plot ng mga function ng klase sa diagram, dahil Ang ganitong detalyadong pamamahagi ng mga responsibilidad ay pinakamahusay na ginawa pagkatapos gumawa ng mga diagram ng pakikipag-ugnayan.

Sa panahon ng proseso ng disenyo, maaaring mapalawak ang bokabularyo ng system, ipinakita ito ni Rosenberg nang napakahusay sa kanyang aklat na naglalarawan sa umuulit na proseso ng disenyo ng ICONIX. Halimbawa, pagkatapos isaalang-alang ang ilang mga precedent, maaaring lumabas na maraming mga klase ang nagpapatupad ng parehong pag-andar - upang malutas ang problema, kinakailangan upang mas malinaw na tukuyin ang mga responsibilidad ng bawat klase, marahil magdagdag ng isang bagong klase at ilipat ang ilan sa mga responsibilidad na ito sa ito.

Iminumungkahi ni Larman na bumuo ng isang konseptwal na modelo ng system - ito ay humigit-kumulang kung ano ang inilarawan namin bilang isang diksyunaryo ng system, ngunit bilang karagdagan sa mga tuntunin ng lugar ng paksa, nakukuha nito ang ilang mga relasyon na naiintindihan ng customer. Halimbawa, naiintindihan ng customer (at itinatala sa mga teknikal na detalye) iyon<покупку>gumuhit up<продавец>- samakatuwid, sa pagitan ng nagbebenta at ng pagbili mayroong isang relasyon ng asosasyon "mga form". Inirerekomenda ko ang pagbuo ng isang konseptwal na modelo sa pamamagitan ng pagpino sa bokabularyo ng system, bagama't inirerekomenda ni Larman na magdagdag muna ng mga asosasyon at pagkatapos ay mga katangian.

2.2 Diagram ng Klase sa Antas ng Disenyo

Sa anumang object-oriented na proseso ng disenyo, isang class diagram ang resulta dahil... ay ang modelo na pinakamalapit sa pagpapatupad (code). May mga tool na maaaring gawing code ang isang class diagram, isang proseso na tinatawag na code generation na sinusuportahan ng maraming IDE at mga tool sa disenyo. Halimbawa, ang pagbuo ng code ay ginagawa ng Visual Paradigm (magagamit bilang mga plugin para sa maraming IDE), mga bagong bersyon ng Microsoft Visual Studio, mga tool sa pagmomodelo ng UML gaya ng StarUML, ArgoUML, atbp. Upang makabuo ng magandang code mula sa isang diagram, dapat itong sapat na detalyado. Ito ang diagram na pinag-uusapan natin sa seksyong ito.

Bago simulan ni Larman ang pagbuo ng diagram ng klase sa antas ng disenyo, dapat na bumuo ng mga diagram ng pakikipag-ugnayan at isang konseptwal na modelo ng system. Sa kasong ito, ang pagkakasunud-sunod ng pagbuo ng diagram ay ang mga sumusunod:

1. ilipat ang mga klase mula sa sequence diagram;
2. magdagdag ng mga katangian ng modelong konsepto;
3. magdagdag ng mga pangalan ng mga pamamaraan para sa pagsusuri ng mga diagram ng pakikipag-ugnayan (halimbawa, );
4. magdagdag ng mga uri ng katangian at pamamaraan;
5. magdagdag ng mga asosasyon (batay sa mga katangian - komposisyon at pagsasama-sama ng mga relasyon);
6. magdagdag ng mga arrow (direksyon ng mga asosasyon)
7. magdagdag ng mga asosasyon na tumutukoy sa iba pang mga uri ng mga relasyon (pangunahin ang mana).

Ang mga ugnayang idinagdag sa diagram ng klase sa antas ng disenyo ay naiiba sa mga nasa konseptwal na modelo dahil maaaring hindi sila halata sa customer (hindi niya dapat tingnan ang diagram na ito - ito ay binuo para sa mga programmer). Kung sa yugto ng pagsusuri sa mga teknikal na pagtutukoy ay makikilala natin ang mga pangunahing entidad nang hindi iniisip kung paano ito ipapatupad, ngayon ang mga responsibilidad sa pagitan ng ating mga klase ay dapat na sa wakas ay maipamahagi.

Halimbawa, kapag sinusuri ang takdang-aralin para sa larong "Mineweeper," natukoy namin ang mga klase at, ngunit ang mga klase ba ay nasa huling proyekto o mananatili lamang sila sa imahinasyon? — ang isang desisyon ay maaari lamang gawin sa pamamagitan ng pagsusuri sa mga diagram ng pakikipag-ugnayan. Pagkatapos ng lahat, posible rin ang sumusunod na code:

Enum class na CellType ( EmptyOpened, EmptyClose, EmptyCloseFlagged, MineOpened, MineClose, MineCloseFlagged ); klase PlayingGround ( // ... CellType **m_ground; )

Hayaan akong ipaliwanag (para sa mga hindi nagsusulat sa C++) - dito nilikha ang isang enumeration na tumutukoy sa uri ng cell. Maaaring kunin ng isang cell ang isa sa anim na halagang ito (walang laman na bukas, walang laman na sarado, walang laman na sarado na may checkbox, atbp.). Sa kasong ito, ang cell mismo ay hindi makakapag-react sa mga pag-click ng mouse at magiging responsable para sa pagpapakita nito (halimbawa, ang isang walang laman na bukas ay dapat magpakita ng bilang ng mga mina sa paligid nito) - lahat ng mga responsibilidad na ito ay tila babagsak sa klase ng PlayingGround .

Ang halimbawa sa itaas ay pinalaki at tiyak na hindi isang sample magandang disenyo— ang klase ng PlayingGround ay may napakaraming responsibilidad, ngunit maaari ba natin itong isaalang-alang kapag sinusuri ang mga teknikal na detalye? Magagawa ba natin ito bago bumuo ng mga diagram ng pakikipag-ugnayan para sa isang proyekto ng anumang kumplikado? - ito ang dahilan kung bakit ang paggawa ng class diagram ay ang huling yugto disenyo.

2.3 Class diagram para sa sketching, pagdodokumento

Ang ibig sabihin ng sketching ay pagmomodelo ng ilang (kasalukuyang kawili-wili) na bahagi ng system. Halimbawa, ang sketching ay maaaring gawin sa isang marker board kapag ang isang bagong empleyado ay sumali sa iyong kumpanya at tinulungan mo siyang "sumali" sa isang kasalukuyang proyekto. Malinaw, kung bibigyan mo ang isang tao ng diagram ng klase sa antas ng disenyo, aabutin siya ng mahabang panahon upang malaman ito. Ang kakanyahan ng sketching ay selectivity - inilalagay mo lamang sa diagram ang mga elemento na mahalaga para sa pagpapaliwanag ng isang partikular na mekanismo.

Ang isang proponent ng paggamit ng UML para sa sketching ay si Fowler, na naniniwala na ang isang holistic na proseso ng disenyo gamit ang UML ay masyadong kumplikado. Ang sketching ay madalas na ginagamit (hindi lamang kapag nagpapaliwanag ng isang proyekto sa isang marker board):

• sa anumang aklat na nakatuon sa mga pattern ng disenyo, makikita mo ang maraming mga diagram ng UML na ginawa sa istilong ito;
• Kapag nagmomodelo ng isang precedent, pinipili ang mga klase kung saan ipinapatupad ang precedent na ito. Ang pagmomodelo ng use case ay ginagawa sa panahon ng refactoring;
• Walang punto sa pagpasok ng diagram ng klase sa antas ng disenyo sa dokumentasyon para sa mga developer - mas kapaki-pakinabang na ilarawan ang pinakamahalagang (key) na mga punto ng system. Upang gawin ito, binuo ang mga diagram ng klase ng sketch at mga diagram ng pakikipag-ugnayan. Mayroon ding mga espesyal na tool para sa pagbuo ng dokumentasyon sa tapos na code - tulad ng JavaDoc o, sa partikular, bumuo sila ng class diagram, ngunit upang maunawaan ang dokumentasyon, ang mga espesyal na uri ng komento ay dapat idagdag sa source code ng programa. .

Imposibleng mag-alok ng anumang partikular na mga alituntunin para sa mga sketch ng class diagram, at bukod pa, ito ay karaniwang isang medyo simpleng gawain. Mahalagang maunawaan ang kakanyahan - ang pagpili sa pagtatanghal ng mga elemento ay binabawasan ang pagiging kumplikado ng pag-unawa sa diagram.

2.4 Class diagram para sa pagmomodelo ng database

Ang isang espesyal na kaso ng isang class diagram ay isang entity-relationship diagram (E-R diagram), na ginagamit upang imodelo ang lohikal na diagram ng isang database. Hindi tulad ng mga klasikong E-R diagram, binibigyang-daan ka ng class diagram na magmodelo ng gawi (mga trigger at nakaimbak na pamamaraan).

Karaniwang ganito ang hitsura ng sitwasyon - nakabuo ka ng isang sistema na ang estado ay kailangang i-save sa pagitan ng mga pagtakbo, halimbawa:

• sa iyong laro kailangan mong mag-imbak ng impormasyon tungkol sa mga nakamit ng user - mga nakumpletong antas, mga puntos na nakuha, atbp.;
• kung ang laro ay online, maaaring mayroong isang server kung saan naka-imbak ang mga nakamit ng iba't ibang mga manlalaro;
• Itinatala ng iyong app sa telepono ang mga coordinate ng user at pinapayagan silang mag-iwan ng mga marka sa mapa. Ang lahat ng impormasyong ito ay hindi rin dapat sirain pagkatapos isara ang aplikasyon.

Ang data na nakaimbak sa pagitan ng mga pagtakbo ay dapat kahit papaano ay mai-load sa kahilingan ng user, ibig sabihin. Dapat tukuyin ang mga parameter ng kaukulang mga klase. Halimbawa, ang application ay dapat kumuha ng isang listahan ng mga track (ruta) mula sa database at ipakita ito bilang isang listahan sa menu ng programa. Kapag pumipili ng item sa listahan, i-query ang mga parameter ng track sa database, lumikha ng track object at ipakita ito sa mapa. Sa anumang kaso, ang data mula sa database ay ginagamit kapag sinisimulan ang mga bagay sa programa - mahalagang maunawaan ito.

Upang magmodelo ng isang database schema gamit ang isang class diagram kailangan mo:

1. tukuyin ang mga klase na ang data ay dapat na nakaimbak sa pagitan ng mga paglulunsad ng application (o mga tawag ng user) at i-plot ang mga klase na ito sa isang hiwalay na diagram;
2. Tukuyin nang detalyado ang mga katangian ng mga klase, asosasyon at multiplicity. Sa mga modelo ng E-R, ang cardinality ay may malaking kahalagahan - halimbawa, kung mayroong isang many-to-many cardinality, kailangan mong lumikha ng isang auxiliary table. Gumamit ng mga partikular na stereotype ng klase at mga marka ng katangian (upang tukuyin ang pangunahin at pangalawang key, halimbawa);
3. lutasin ang mga problema sa paggamit ng nagresultang diagram bilang isang modelo ng pisikal na database - mga cyclic association, n-ary association, atbp. Kung kinakailangan, lumikha ng mga intermediate abstraction;
4. tumuklas ng mga operasyong mahalaga upang ma-access ang data at mapanatili ang integridad;

Konklusyon at bibliograpiya

Sa artikulo, sinubukan kong ilarawan ang pinakamahalagang elemento ng isang class diagram, pati na rin ang mga aspeto ng kanilang aplikasyon. Ito ay malinaw na ang diagram ay itinayo sa paunang yugto ng disenyo (conceptual model) at ang resulta nito. Sa lahat ng mga yugto ng disenyo, ang diagram ng klase na nilikha sa simula ay pino, i.e. Isinasaalang-alang ko ang isang umuulit na proseso (tulad ng RUP o ICONIX). Bilang karagdagan, ang paggamit ng mga diagram ng klase para sa iba pang mga layunin ay ipinapakita - sketching, pagdodokumento, pagmomodelo ng lohikal na diagram ng isang database. Makakakita ka ng maraming halimbawa ng paggamit ng mga class diagram sa ibang mga pahina ng blog na ito.

• diagram ;
• maraming diagram na nagpapakita ng mga hakbang sa refactoring upang masunod ang proyekto;
• mga diagram ng klase para sa .
• Butch Graddy Object-Oriented na Pagsusuri at Disenyo na may Mga Halimbawang Aplikasyon, 3rd ed. / Butch Graddy, Maksimchuk Robert A., Engle Michael W., Young Bobby J., Conallen Jim, Houston Kelly A.: Isinalin mula sa Ingles. - M.: LLC “I.D. Williams", 2010. - 720 p.
• Leonenkov, A.V. Tutorial sa UML 2 / A.V. Leonenkov. – St. Petersburg: BHV – Petersburg, 2007. – 576 p.
• Larman, K. Application ng UML at mga pattern ng disenyo: Textbook. Pos / K. Larman. - M.: Williams Publishing House, 2001. - 496 p.
• Rosenberg D., Scott K. Application ng object modeling gamit ang UML at use case analysis.: Per. mula sa Ingles M.: DMK Press, 2002
• Budd T. Object-oriented programming in action: Isinalin mula sa English. - St. Petersburg: "Peter", 1997. - 464 p. 2002
• Butch G., Rambo D., Jacobson A. UML na wika. Gabay sa Gumagamit: Per. mula sa Ingles - M.: DMK, 2000. - 432 p.
• Fowler, M. UML. Fundamentals / M. Fowler, K. Scott; lane mula sa Ingles – St. Petersburg: Simbolo – Dagdag pa, 2002. – 192 p.
• — URL: https://site/archives/1914
• — URL: https://site/archives/2769
• Pagmomodelo ng data ng UML - URL: http://www.agiledata.org/essays/umlDataModelingProfile.html
• — URL: https://site/archives/887
• — URL: https://site/archives/2400
• — URL: https://site/archives/1372

Ang Visual Studio 2010 Ultimate ay nagbibigay ng sapat maginhawang mga tampok para sa reverse engineering. Gamit ang mga tool ng Visual Studio, maaari tayong bumuo ng modelong UML batay sa umiiral na code at maunawaan kung paano gumagana ang lahat para sa atin, ngunit nang hindi gumagawa ng malaking pagsisikap na gumawa ng mga diagram nang manu-mano at panatilihing napapanahon ang mga ito.

Magiging maayos ang lahat, ngunit ang tool na ito ay ganap na walang kakayahang i-synchronize ang modelo sa code. Iyon ay, pagkatapos baguhin ang modelo, kailangan nating manu-manong baguhin ang mga klase. Sa kaso ng isang malaking bilang ng mga maliliit na pagbabago, ito ay lumalabas na medyo hindi maginhawa, at sa kadahilanang ito ang ganap na pagmomolde ay madalas na inabandona.

Kamakailan ay naglabas ang Microsoft ng isang add-on na tinatawag na Microsoft Visual Studio 2010 Feature Pack 2. Ang tool na ito nagbibigay sa amin ng magandang pagkakataon na i-synchronize ang mga pagbabago sa modelo sa code. Sasabihin ko sa iyo nang maikli kung paano ito magagamit.

Halimbawa, sabihin nating mayroon tayong primitive na blog. Ang lugar ng paksa ay kinakatawan ng dalawang klase: May-akda at Artikulo. Nagdagdag kami ng bagong Modeling Project sa solusyon. Gumagawa kami ng UML Class Diagram dito.

Samantalahin natin ang mga kakayahan ng Reverse Engineering. I-drag ang mga klase mula sa Architecture Explorer papunta sa diagram. Sa kasong ito, lumilitaw ang entity sa diagram kasama ang mga katangian nito. Paminsan-minsan, ang mga koneksyon ay nabuo sa pagitan ng mga entity na dapat na umiiral (at ang uri ng koneksyon ay kahit na pana-panahong ipinapakita nang tama), ngunit sa kung anong mga kaso ito ay hindi pa posible upang matukoy.

Tulad ng alam nating lahat, ang pamantayan ng UML 2.0 ay tumutukoy sa apat karaniwang uri data: Boolean, Integer, String at UnlimitedNatural. Ang natitirang mga uri ay awtomatikong nilikha sa mga pakete ayon sa kanilang lokasyon sa .NET namespaces.

Kaya, subukan nating "ayusin" ang modelo sa isang sapat na estado, at sa parehong oras, palawakin ito ng kaunti. Upang gawin ito, lumikha ng bagong klase sa diagram, i-drag ito sa gustong Package sa UML Model Explorer at piliin ang C# Class stereotype (Nagdagdag ang Microsoft ng ilang .NET-specific na stereotype na ginagamit sa pagbuo ng code).

Tandaan na ang klase na ito ay wala pa sa Domain assembly. Upang mairehistro ito doon, at sa parehong oras ilapat ang lahat ng aming mga pagbabago, kailangan mong gawin ang sumusunod.

Sa Model Explorer, piliin ang Domain assembly, pumunta sa Properties at sa Text Template Binding item, i-click ang “…” button. Nagdagdag kami ng isang bagong elemento, sa field ng Project Path ipinapahiwatig namin ang pangalan ng proyekto kung saan bubuo ang code, sa field na Target Directory ipinapahiwatig namin ang folder na nauugnay sa proyekto (bumubuo kami sa ugat) at ipahiwatig ang template address. Bilang default, matatagpuan ang mga ito sa folder na "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Visualization and Modeling Feature Pack\2.0\Templates\Text". Maaari kang magtakda ng ilang mga template para sa lahat ng okasyon. Sa aming kaso, piliin ang ClassTemplate.t4.

Pagkatapos nito, mag-right-click sa isang walang laman na espasyo sa diagram at piliin ang Bumuo ng Code.

At - voila! Ang isang bagong klase ay idinagdag sa pagpupulong, ang lahat ng mga pagbabago ay inilapat alinsunod sa modelo.

Sa pamamagitan ng paraan, sa tulong ng mga stereotype posible na tukuyin ang halos lahat: ang kakayahang makita ng mga miyembro, mga katangian na kasama kapag bumubuo ng isang namespace, atbp.

Kaya, nag-aalok sa amin ang M$ ng isang mahusay na tool na magpapadali sa buhay ng mga arkitekto at developer. Sa kasamaang palad, ang kinakailangang package na ito ay magagamit lamang sa mga subscriber ng MSDN, at sa ilang kadahilanan ay hindi pinapayagan ng kumpanya ang lahat ng mga legal na gumagamit na gamitin ito. At ito ay sa halaga ng VS Ultimate na halos 300 libong rubles. Umaasa tayo na ang kalagayang ito ay magbago sa malapit na hinaharap.

UML-- isang graphical na paglalarawan ng wika para sa object modeling sa software development. Ang UML ay isang pangkalahatang wika, isang bukas na pamantayan na gumagamit ng graphical na notasyon upang lumikha ng abstract na modelo ng isang system, na tinatawag na modelo ng UML. Ginawa ang UML upang tukuyin, mailarawan, idisenyo, at idokumento lalo na ang mga software system. Ang UML ay hindi isang programming language, ngunit ang pagbuo ng code ay posible sa mga paraan para sa pagpapatupad ng mga modelo ng UML bilang interpreted code.

Ang paggamit ng UML ay hindi limitado sa pagmomodelo ng software. Ginagamit din ito para sa pagmomodelo ng mga proseso ng negosyo, disenyo ng mga sistema, at pagmamapa ng mga istruktura ng organisasyon.

Pinapayagan din ng UML ang mga developer ng software na sumang-ayon sa mga graphical na notasyon upang kumatawan sa mga karaniwang konsepto (tulad ng klase, bahagi, pangkalahatan, pagsasama-sama, at pag-uugali) at higit na tumuon sa disenyo at arkitektura.

Ang UML ay isang pangkalahatang layunin na visual modeling language na idinisenyo para sa pagtukoy, pagpapakita, pagdidisenyo, at pagdodokumento ng mga bahagi ng software, mga proseso ng negosyo, at iba pang mga system. Ang wikang UML ay parehong simple at makapangyarihang tool sa pagmomodelo na maaaring epektibong magamit upang bumuo ng mga konseptwal, lohikal at graphical na mga modelo kumplikadong mga sistema para sa iba't ibang layunin. Ang wikang ito ay sumisipsip pinakamahusay na kalidad mga pamamaraan ng software engineering na matagumpay na ginamit sa nakalipas na mga taon sa pagmomodelo ng malaki at kumplikadong mga sistema.

Ang wika ng UML ay batay sa ilang pangunahing konsepto na maaaring matutunan at mailapat ng karamihan sa mga programmer at developer na pamilyar sa object-oriented na pagsusuri at mga diskarte sa disenyo. Kasabay nito, ang mga pangunahing konsepto ay maaaring pagsamahin at palawakin sa paraang ang mga object modeler ay nakapag-iisa na makabuo ng mga modelo ng malaki at kumplikadong mga sistema sa isang malawak na iba't ibang mga lugar ng aplikasyon.

Ang visual modeling sa UML ay maaaring katawanin bilang isang tiyak na proseso ng antas-by-level na pagbaba mula sa pinaka-pangkalahatan at abstract na konseptong modelo ng orihinal na sistema patungo sa isang lohikal, at pagkatapos ay sa isang pisikal na modelo ng katumbas na sistema ng software. Upang makamit ang mga layuning ito, ang isang modelo ay unang binuo sa anyo ng isang tinatawag na use case diagram, na naglalarawan sa functional na layunin ng system o, sa madaling salita, kung ano ang gagawin ng system sa panahon ng operasyon nito. Ang diagram ng use case ay ang paunang representasyong konseptwal o modelong konseptwal ng isang sistema sa panahon ng proseso ng disenyo at pagbuo nito.

Ang pagbuo ng isang use case diagram ay may mga sumusunod na layunin:

Tukuyin ang mga pangkalahatang hangganan at konteksto ng namodelong lugar ng paksa sa mga unang yugto ng disenyo ng system;

Bumuo ng mga pangkalahatang kinakailangan para sa functional na pag-uugali ng dinisenyong sistema;

Bumuo ng isang paunang konseptwal na modelo ng system para sa kasunod nitong pagdedetalye sa anyo ng mga lohikal at pisikal na modelo;

Maghanda ng paunang dokumentasyon para sa pakikipag-ugnayan ng mga developer ng system sa mga customer at user nito.

Ang kakanyahan ng diagram na ito ay ang mga sumusunod: ang dinisenyong sistema ay kinakatawan bilang isang hanay ng mga entidad o aktor na nakikipag-ugnayan sa system gamit ang tinatawag na mga kaso ng paggamit. Sa kasong ito, ang aktor o aktor ay anumang entity na nakikipag-ugnayan sa system mula sa labas. Ito ay maaaring isang tao, isang teknikal na aparato, isang programa o anumang iba pang sistema na maaaring magsilbi bilang isang pinagmumulan ng impluwensya sa simulate system na tinutukoy ng developer mismo. Sa turn, ang isang use case ay nagsisilbing ilarawan ang mga serbisyong ibinibigay ng system sa aktor. Sa madaling salita, ang bawat use case ay tumutukoy sa isang tiyak na hanay ng mga aksyon na isinagawa ng system sa panahon ng isang dialogue kasama ang aktor. Gayunpaman, walang sinabi tungkol sa kung paano ipapatupad ang pakikipag-ugnayan ng mga aktor sa sistema.

Ang sequence diagram ay isang diagram ng mga pakikipag-ugnayan na nakatuon sa temporal na pagkakasunud-sunod ng mga mensahe. Sa graphically, ang gayong diagram ay isang talahanayan kung saan ang mga bagay ay matatagpuan sa kahabaan ng X axis, at ang mga mensahe sa pataas na pagkakasunud-sunod ng oras ay matatagpuan sa kahabaan ng Y axis Ang isang diagram ng pakikipagtulungan ay isang diagram ng pakikipag-ugnayan na nakatuon sa istrukturang organisasyon ng mga bagay na tumatanggap at magpadala ng mga mensahe. Sa graphically, ang gayong diagram ay isang graph ng mga vertex at mga gilid.

Ang mga diagram ng pagkakasunud-sunod ay may dalawang tampok na nagpapaiba sa kanila mula sa mga diagram ng pakikipagtulungan.

Una, ipinapakita nila ang linya ng buhay ng bagay. Ito ay isang patayong tuldok na linya na sumasalamin sa pagkakaroon ng isang bagay sa oras. Karamihan sa mga bagay na kinakatawan sa diagram ng pakikipag-ugnayan ay umiiral sa buong pakikipag-ugnayan, kaya inilalarawan ang mga ito sa tuktok ng diagram, at ang kanilang mga linya ng buhay ay iginuhit mula sa itaas hanggang sa ibaba. Ang mga bagay ay maaari ding malikha sa panahon ng mga pakikipag-ugnayan. Ang mga lifeline ng naturang mga bagay ay nagsisimula sa pagtanggap ng mensahe na may lumikha ng stereotype. Ang mga bagay ay maaari ding sirain sa panahon ng mga pakikipag-ugnayan; sa kasong ito, ang kanilang mga lifeline ay nagtatapos sa isang mensahe na may sira na stereotype, at isang malaking X ang ginagamit bilang isang visual na imahe, na nagpapahiwatig ng pagtatapos ng buhay ng bagay.

Ang pangalawang tampok ng mga diagram na ito ay ang pokus ng kontrol. Ito ay inilalarawan bilang isang pinahabang parihaba na nagpapakita ng tagal ng panahon kung saan ang isang bagay ay nagsasagawa ng isang aksyon, nang direkta o gumagamit ng isang subordinate na pamamaraan. Ang tuktok na gilid ng parihaba ay nakahanay sa kahabaan ng axis ng oras sa sandaling magsimula ang pagkilos, ang ilalim na gilid ay nakahanay sa sandaling ito ay nagtatapos (at maaaring markahan ng isang mensahe sa pagbabalik). Ang nesting ng control focus, sanhi ng recursion (iyon ay, pagtawag sa sarili nitong operasyon) o isang callback mula sa isa pang object, ay maaaring ipakita sa pamamagitan ng paglalagay ng isa pang control focus nang bahagya sa kanan ng magulang nito (pinahihintulutan ang nesting ng arbitrary depth). Kung nais mong ipahiwatig ang lokasyon ng control focus na may pinakamataas na katumpakan, maaari mong lilim ang lugar ng rektanggulo na tumutugma sa oras kung kailan aktwal na gumagana ang pamamaraan at hindi naglilipat ng kontrol sa isa pang bagay.

Ang Class diagram ay isang diagram na nagpapakita ng maraming klase, interface, pakikipagtulungan, at relasyon sa pagitan nila. Ito ay inilalarawan bilang maraming mga vertex at arko.

Mas karaniwan ang mga class diagram kapag nagmomodelo ng mga object-oriented system. Ang ganitong mga diagram ay nagpapakita ng maraming klase, interface, pakikipagtulungan, at relasyon sa pagitan nila.

Ginagamit ang mga class diagram upang imodelo ang static na view ng isang system mula sa isang perspektibo ng disenyo. Ito ay higit na nagsasangkot ng pagmomodelo sa bokabularyo, pakikipagtulungan, at mga circuit ng system. Bilang karagdagan, ang mga diagram ng klase ay bumubuo ng batayan ng dalawa pang diagram - mga bahagi at pag-deploy.

Ang mga class diagram ay mahalaga hindi lamang para sa pag-visualize, pagtukoy, at pagdodokumento ng mga structural models, ngunit para din sa forward at reverse engineering ng mga executable system.

Ang mga diagram ng aktibidad ay isa sa limang uri ng mga diagram na ginagamit sa UML upang imodelo ang mga dynamic na aspeto ng gawi ng system. Ang activity diagram ay mahalagang isang flowchart na nagpapakita kung paano lumilipat ang daloy ng kontrol mula sa isang aktibidad patungo sa isa pa.

Ang diagram ng kooperasyon ay nakatuon sa mga organisasyon ng mga bagay na nakikibahagi sa pakikipag-ugnayan. Upang lumikha ng isang diagram ng pakikipagtulungan, kailangan mong ayusin ang mga bagay na kalahok sa pakikipag-ugnayan sa anyo ng mga vertices ng isang graph. Pagkatapos ay ang mga koneksyon na nagkokonekta sa mga bagay na ito ay inilalarawan bilang mga arko ng graph na ito. Sa wakas, ang mga koneksyon ay kinukumpleto ng mga mensahe na natatanggap at ipinapadala ng mga bagay. Nagbibigay ito sa user ng malinaw na visual na representasyon ng daloy ng kontrol sa konteksto ng istrukturang organisasyon ng mga nakikipagtulungang entity.

Ang isang Component diagram ay nagpapakita ng isang hanay ng mga bahagi at ang mga ugnayan sa pagitan ng mga ito. Sa graphically, ang component diagram ay kinakatawan bilang isang graph na may mga gilid at vertices.

Ipinapakita ng Deployment diagram ang configuration ng mga processing node na nagpapatakbo sa system at ang mga component na naninirahan sa mga node na iyon. Ang deployment diagram ay kinakatawan bilang isang graph na may mga gilid at vertice.

Ang mga state diagram ay isa sa limang uri ng mga diagram sa UML na ginagamit upang imodelo ang mga dynamic na aspeto ng isang system. Ang diagram ng estado ay nagpapakita ng makina. Ang partikular na pagkakaiba-iba nito ay ang diagram ng aktibidad, kung saan ang lahat o karamihan ng mga estado ay mga estado ng aktibidad, at lahat o karamihan ng mga paglipat ay sinimulan bilang resulta ng pagkumpleto ng aktibidad sa orihinal na kondisyon. Kaya, ang parehong mga diagram ng aktibidad at mga diagram ng estado ay kapaki-pakinabang kapag nagmomodelo ng siklo ng buhay ng isang bagay. Ngunit habang ipinapakita ng activity diagram ang daloy ng kontrol mula sa aktibidad patungo sa aktibidad, ipinapakita ng state diagram ang daloy ng kontrol mula sa estado patungo sa estado.

Ang sentral na lugar sa OOAP ay ang pagbuo ng isang lohikal na modelo ng system sa anyo ng isang class diagram. Ang notasyon ng klase sa UML ay simple at madaling maunawaan sa sinumang nakaranas na ng mga tool sa CASE. Ang isang katulad na notasyon ay ginagamit para sa mga bagay - mga pagkakataon ng isang klase, na may pagkakaiba na ang pangalan ng bagay ay idinagdag sa pangalan ng klase at ang buong inskripsiyon ay may salungguhit.

Ang notasyon ng UML ay nagbibigay ng sapat na pagkakataon para sa pagpapakita ng karagdagang impormasyon (mga abstract na operasyon at klase, stereotype, pampubliko at pribadong pamamaraan, mga detalyadong interface, mga parameterized na klase). Sa kasong ito, posibleng gumamit ng mga graphic na larawan para sa mga asosasyon at sa mga partikular na katangian ng mga ito, gaya ng ugnayan ng pagsasama-sama, kapag ang ibang mga klase ay maaaring maging bahagi ng isang klase.

Ang isang diagram ng klase ay ginagamit upang kumatawan sa static na istraktura ng isang modelo ng system sa terminolohiya ng mga klase ng programming na nakatuon sa object. Maaaring ipakita ng isang class diagram, sa partikular, ang iba't ibang ugnayan sa pagitan ng mga indibidwal na entity ng domain, tulad ng mga bagay at subsystem, at inilalarawan din ang kanilang panloob na istraktura at mga uri ng mga relasyon. Ang diagram na ito ay hindi nagbibigay ng impormasyon tungkol sa mga aspeto ng timing ng pagpapatakbo ng system. Mula sa puntong ito ng view, ang class diagram ay isang karagdagang pag-unlad ng konseptwal na modelo ng dinisenyong sistema.

Ang class diagram ay isang graph na ang mga vertice ay mga elemento ng uri ng "classifier", na konektado ng iba't ibang uri ng mga istrukturang relasyon. Dapat tandaan na ang isang class diagram ay maaari ding maglaman ng mga interface, package, relasyon, at maging ang mga indibidwal na pagkakataon tulad ng mga bagay at relasyon. Kapag pinag-uusapan nila ang diagram na ito, ang ibig nilang sabihin ay isang static na structural model ng system na idinisenyo. Samakatuwid, ang class diagram ay itinuturing na isang graphical na representasyon ng mga istrukturang relasyon ng lohikal na modelo ng isang sistema na independyente o invariant ng oras.

Ang isang class diagram ay binubuo ng maraming elemento na sama-samang sumasalamin sa deklaratibong kaalaman tungkol sa isang domain. Ang kaalamang ito ay binibigyang kahulugan sa mga pangunahing konsepto ng UML tulad ng mga klase, interface, at ang mga ugnayan sa pagitan ng mga ito at ng kanilang mga bumubuong bahagi. Sa kasong ito, ang mga indibidwal na bahagi ng diagram na ito ay maaaring bumuo ng mga pakete upang kumatawan sa isang mas pangkalahatang modelo ng system. Kung ang isang class diagram ay bahagi ng isang package, ang mga bahagi nito ay dapat tumugma sa mga elemento ng package na iyon, kabilang ang posibleng mga link sa mga elemento mula sa iba pang mga pakete.

Sa pangkalahatan, ang isang static na structural model package ay maaaring katawanin bilang isa o higit pang mga class diagram. Ang pagkabulok ng isang tiyak na representasyon sa magkakahiwalay na mga diagram ay ginagawa para sa layunin ng kaginhawahan at graphical na paggunita ng mga istrukturang relasyon ng lugar ng paksa. Sa kasong ito, ang mga bahagi ng diagram ay tumutugma sa mga elemento ng static na semantic model. Ang modelo ng system, sa turn, ay dapat na pare-pareho sa panloob na istraktura ng klase, na inilalarawan sa UML.

Ang isang klase sa UML ay tumutukoy sa isang hanay ng mga bagay na may parehong istraktura, pag-uugali, at mga relasyon sa mga bagay mula sa iba pang mga klase. Sa graphically, ang klase ay inilalarawan bilang isang parihaba, na maaari ding hatiin ng mga pahalang na linya sa mga seksyon o mga seksyon (Larawan 5.1). Maaaring kabilang sa mga seksyong ito ang pangalan ng klase, mga katangian (mga variable), at mga pagpapatakbo (mga pamamaraan).

kanin. 5.1. Graphical na representasyon ng isang klase sa isang class diagram

Ang isang ipinag-uutos na elemento ng isang pagtatalaga ng klase ay ang pangalan nito. Sa mga unang yugto ng pagbuo ng diagram, ang mga indibidwal na klase ay maaaring ipahiwatig ng isang simpleng parihaba na nagpapahiwatig lamang ng pangalan ng kaukulang klase (Larawan 5.1, a). Habang ang mga indibidwal na bahagi ng diagram ay binuo, ang mga paglalarawan ng klase ay pupunan ng mga katangian (Larawan 5.1, b) at mga operasyon (Larawan 5.1, c).

Ipinapalagay na ang huling bersyon ng diagram ay naglalaman ng pinakamaraming buong paglalarawan mga klase, na binubuo ng tatlong seksyon o seksyon. Kung minsan ang mga notasyon ng klase ay gumagamit ng karagdagang ikaapat na seksyon upang magbigay ng semantic reference na impormasyon o para tahasang ipahiwatig ang mga sitwasyon ng pagbubukod.

Kahit na ang seksyon ng mga katangian at pagpapatakbo ay walang laman, ito ay naka-highlight sa isang pahalang na linya sa notasyon ng klase upang agad na makilala ang klase mula sa iba pang mga elemento ng UML. Ang mga halimbawa ng graphical na representasyon ng mga klase sa isang class diagram ay ipinapakita sa Fig. 5.2. Sa unang kaso, para sa klase ng "Rectangle" (Larawan 5.2, a), tanging ang mga katangian nito ang ipinahiwatig - mga punto sa coordinate plane na tumutukoy sa lokasyon nito. Para sa klase ng "Window" (Larawan 5.2, b), tanging ang mga operasyon nito ang ipinahiwatig, ang seksyon ng mga katangian ay naiwang walang laman. Para sa klase ng "Account" (Larawan 5.2, c), ang isang ikaapat na seksyon ay karagdagang ipinapakita, na nagpapahiwatig ng isang pagbubukod - pagtanggi na iproseso ang isang overdue na credit card.

Fig.5.2. Mga halimbawa ng graphical na representasyon ng mga klase sa isang diagram

Ang pangalan ng klase ay dapat na natatangi sa loob ng package, na inilalarawan ng ilang koleksyon ng mga class diagram (maaaring isang solong diagram). Ito ay ipinahiwatig sa unang itaas na seksyon ng parihaba. Bilang karagdagan sa pangkalahatang tuntunin para sa pagbibigay ng pangalan sa mga elemento ng UML, ang pangalan ng klase ay nakasulat na nakasentro sa seksyon ng pangalan sa bold na font at dapat magsimula sa malaking titik. Inirerekomenda na gumamit ng mga pangngalan bilang mga pangalan ng klase, na isinulat nang walang mga puwang para sa praktikal na mga kadahilanan. Dapat tandaan na ang mga pangalan ng klase ang bumubuo sa diksyunaryo ng domain sa OOAP.

Ang unang seksyon ng pagtatalaga ng klase ay maaaring maglaman ng mga sanggunian sa mga karaniwang template o abstract na mga klase kung saan nagmula ang klase at, nang naaayon, kung saan ito nagmamana ng mga katangian at pamamaraan. Ang seksyong ito ay maaaring magbigay ng impormasyon tungkol sa nag-develop ng klase na ito at ang katayuan ng pag-develop, at maaari ding magtala ng iba pang pangkalahatang katangian ng klase na ito na may kaugnayan sa ibang mga klase sa diagram o karaniwang mga elemento wika ng UML.

Ang mga halimbawa ng mga pangalan ng klase ay maaaring mga pangngalan gaya ng "Empleyado", "Kumpanya", "Manager", "Client", "Seller", "Manager", "Office" at marami pang iba na direktang nauugnay sa modeled subject area at functional na layunin ng dinisenyong sistema.

Maaaring walang instance o object ang isang klase. Sa kasong ito, ito ay tinatawag na abstract class, at ang mga italics ay ginagamit upang ipahiwatig ang pangalan nito. Ang UML ay may pangkalahatang kumbensyon na ang anumang teksto na tumutukoy sa isang abstract na elemento ay nakasulat sa italics. Ang sitwasyong ito ay isang semantikong aspeto ng paglalarawan ng mga kaukulang elemento ng wikang UML.

Ang pangalawang seksyon ng parihaba ng klase mula sa itaas ay naglalaman ng mga katangian o katangian nito. Ang wika ng UML ay nagpatibay ng isang tiyak na standardisasyon ng mga katangian ng klase ng pagsulat, na napapailalim sa ilang partikular na tuntunin ng syntactic. Ang bawat attribute ng klase ay may hiwalay na linya ng text, na binubuo ng visibility quantifier ng attribute, pangalan ng attribute, multiplicity nito, uri ng value ng attribute, at posibleng orihinal na value nito:

<квантор видимости><имя атрибута>[multiplicity]:

<тип атрибута> = <исходное значение>(string ng ari-arian)

Ang visibility quantifier ay maaaring tumagal ng isa sa tatlong posibleng mga halaga at, nang naaayon, ay ipinapakita gamit ang mga espesyal na character:

Ang simbolo na "+" ay tumutukoy sa isang katangian na may saklaw ng uri ng publiko. Ang isang katangian na may ganitong saklaw ay naa-access o nakikita mula sa anumang iba pang klase sa package kung saan tinukoy ang diagram.

Ang simbolo na "#" ay tumutukoy sa isang katangian na may saklaw ng uri na protektado. Ang isang attribute na may ganitong saklaw ay hindi available o hindi nakikita sa lahat ng klase maliban sa mga subclass ng klase na iyon.

Sa wakas, ang tanda na "-" ay nagpapahiwatig ng isang katangian na may saklaw ng uri na pribado. Ang isang katangian na may ganitong saklaw ay hindi magagamit o hindi nakikita para sa lahat ng mga klase nang walang pagbubukod.

Maaaring tanggalin ang visibility quantifier. Sa kasong ito, ang kawalan nito ay nangangahulugan lamang na ang visibility ng katangian ay hindi tinukoy. Ang sitwasyong ito ay naiiba sa mga default na convention sa mga tradisyonal na programming language, kung saan ang kawalan ng visibility quantifier ay itinuturing bilang pampubliko o pribado. Gayunpaman, sa halip na maginoo na mga graphic na simbolo, maaari mong isulat ang kaukulang keyword: pampubliko, protektado, pribado.

Ang pangalan ng katangian ay isang string ng text na ginagamit bilang isang identifier para sa kaukulang katangian at samakatuwid ay dapat na natatangi sa loob ng isang partikular na klase. Ang pangalan ng katangian ay ang tanging kinakailangang elemento ng syntax ng katangian.

Inilalarawan ng attribute multiplicity ang kabuuang bilang ng mga partikular na katangian ng isang partikular na uri na bahagi ng isang hiwalay na klase. Sa pangkalahatan, ang multiplicity ay isinulat bilang isang string ng teksto sa mga square bracket pagkatapos ng pangalan ng kaukulang katangian:

[lower_border1 .. upper_border1, lower_border2.. upper_border2, ..., lower_border .. upper_border],

kung saan ang lower_bound at upper_bound ay mga positive integer, ang bawat pares nito ay nagsisilbing magpahiwatig ng hiwalay na saradong pagitan ng mga integer na ang lower (upper) bound ay katumbas ng value ng lower_bound (upper_bound). Sa pangkalahatan, ang multiplicity convention na ito ay tumutugma sa set-theoretic union ng mga kaukulang agwat. Maaaring gamitin ang espesyal na character na "*" bilang upper_bound, na nangangahulugang isang arbitrary positive integer. Sa madaling salita, nangangahulugan ito na ang multiplicity na halaga ng kaukulang katangian ay walang limitasyon mula sa itaas.

Ang mga halaga ng multiplicity mula sa pagitan ay sumusunod sa monotonically pagtaas ng pagkakasunud-sunod nang hindi nilalaktawan ang mga indibidwal na numero na namamalagi sa pagitan ng mas mababa at itaas na mga hangganan. Sa kasong ito, ang sumusunod na panuntunan ay sinusunod: ang katumbas na mas mababa at itaas na mga hangganan ng mga pagitan ay kasama sa halaga ng multiplicity. Kung ang isang solong numero ay tinukoy bilang ang multiplicity, ang attribute na multiplicity ay kukunin na katumbas ng binigay na numero. Kung tinukoy ang isang solong "*" sign, nangangahulugan ito na ang multiplicity ng attribute ay maaaring isang arbitrary positive integer o zero.

Bilang halimbawa, isaalang-alang ang mga sumusunod na opsyon pagtatakda ng multiplicity ng mga katangian.

Nangangahulugan na ang multiplicity ng attribute ay maaaring kumuha ng value na 0 o 1. Sa kasong ito, 0 ay nangangahulugan na walang value para sa attribute na ito.

Nangangahulugan na ang multiplicity ng attribute ay maaaring tumagal ng anumang positive integer value na mas malaki sa o katumbas ng 0. Ang multiplicity na ito ay maaaring maisulat nang mas maikli bilang isang simpleng simbolo - [*].

Nangangahulugan na ang multiplicity ng attribute ay maaaring tumagal ng anumang positive integer value na mas malaki sa o katumbas ng 1.

Nangangahulugan na ang multiplicity ng attribute ay maaaring kumuha ng anumang halaga mula sa mga numero: 1, 2, 3, 4, 5.

Nangangahulugan na ang multiplicity ng attribute ay maaaring kumuha ng anumang halaga mula sa mga numero: 1, 2, 3, 5, 7.

Nangangahulugan na ang multiplicity ng attribute ay maaaring kumuha ng anumang halaga mula sa mga numero: 1, 2, 3, 7, 8, 9, 10.

Nangangahulugan na ang multiplicity ng attribute ay maaaring kumuha ng anumang value mula sa mga numero: 1, 2, 3, pati na rin ang anumang positive integer value na mas malaki sa o katumbas ng 7.

Kung hindi tinukoy ang multiplicity ng attribute, ang default na value nito ay 1..1, ibig sabihin, eksaktong 1.

Ang uri ng katangian ay isang expression na ang mga semantika ay tinutukoy ng wika ng detalye ng kaukulang modelo. Sa notasyon ng UML, ang uri ng isang katangian ay minsan ay tinutukoy depende sa programming language na nilalayong gamitin upang ipatupad ang modelo. Sa pinakasimpleng kaso, ang uri ng katangian ay ipinahiwatig ng isang string ng text na may makabuluhang kahulugan sa loob ng package o modelo kung saan kabilang ang klase na pinag-uusapan.

Ang mga sumusunod na halimbawa ng pagtukoy sa mga pangalan at uri ng mga katangian ng klase ay maaaring ibigay:

Kulay: Kulay – dito kulay ang pangalan ng katangian, Kulay ang pangalan ng uri ng katangiang ito. Ang nasabing entry ay maaaring tukuyin ang isang tradisyonal na ginagamit na RGB (pula, berde, asul) na modelo upang kumatawan sa kulay. Sa kasong ito, ang pangalan ng uri ng Kulay ay tiyak na nagpapakilala sa semantikong konstruksyon na ginagamit sa karamihan ng mga programming language upang kumatawan sa kulay.

Employee_name: String – dito ang employee_name ay ang pangalan ng isang attribute na nagsisilbing kumakatawan sa impormasyon tungkol sa unang pangalan, at posibleng patronymic, ng isang partikular na empleyado. Ang uri ng katangian ng String ay partikular na nagpapahiwatig ng katotohanan na ang isang solong halaga ng pangalan ay isang string ng teksto ng isa o dalawang salita (halimbawa, "Kirill" o "Dmitry Ivanovich"). Dahil maraming mga programming language ang may String data type, ang paggamit ng kaukulang terminong Ingles ay hindi nagdudulot ng kalituhan sa karamihan ng mga programmer. Gayunpaman, bagama't sa wikang UML ang lahat ng mga termino ay ibinibigay sa Ingles, ang paggamit ng String attribute bilang isang uri sa sitwasyong ito ay hindi ibinubukod at natutukoy lamang sa pamamagitan ng pagsasaalang-alang sa kaginhawahan.

Visibility:Boolean – dito ang visibility ay ang pangalan ng abstract attribute (ang italics ay hindi sinasadya) na maaaring makilala ang presensya visual na representasyon kaukulang klase sa screen ng monitor. Sa kasong ito i-type ang Boolean nangangahulugan na ang mga posibleng halaga para sa katangiang ito ay isa sa dalawang lohikal na halaga: totoo o mali. Sa kasong ito, ang totoong halaga ay maaaring tumugma sa pagkakaroon ng isang graphic na imahe sa screen ng monitor, at ang maling halaga ay maaaring tumugma sa kawalan nito, na karagdagang ipinahiwatig sa paliwanag na teksto. Dahil hindi tinukoy ang multiplicity ng attribute ng visibility, tumatagal ito ng default na value na 1. Sa sitwasyong ito, ang Ingles na pangalan ng uri ng katangian ay ganap na nabibigyang katwiran sa pamamagitan ng pagkakaroon ng katumbas pangunahing uri sa mga programming language. Ang abstract na katangian ng katangiang ito ay ipinahiwatig italic na teksto sa entry para sa katangiang ito.

Hugis: Polygon - dito ang pangalan ng hugis ng katangian ay maaaring makilala ang isang klase na isang geometric na pigura sa isang eroplano. Sa kasong ito, ang uri ng katangian ng Polygon ay tumutukoy sa katotohanan na ang isang geometric na figure ay maaaring hugis tulad ng isang tatsulok, parihaba, brilyante, pentagon, o anumang iba pang polygon, ngunit hindi isang bilog o ellipse. Halatang halata na sa sitwasyong ito ang paggamit ng kaukulang termino sa wikang Ingles ay halos hindi maipapayo, dahil ang uri ng Polygon ay hindi basic para sa mga programming language.

Ang paunang halaga ay ginagamit upang magtakda ng ilang paunang halaga para sa kaukulang katangian sa oras ng paggawa ng isang hiwalay na halimbawa ng klase. Dito kinakailangan na sumunod sa panuntunan na ang halaga ay kabilang sa uri ng isang partikular na katangian. Kung ang paunang halaga ay hindi tinukoy, ang halaga ng katumbas na katangian ay hindi natukoy sa oras na ang bagong instance ng klase ay nilikha. Sa kabilang banda, maaaring i-override ng constructor ng kaukulang bagay ang orihinal na halaga sa panahon ng pagpapatupad ng programa, kung kinakailangan.

Bilang mga halimbawa ng mga paunang halaga ng katangian, ang mga sumusunod na opsyon para sa pagtukoy ng mga katangian, na dinagdagan sa itaas, ay maaaring ibigay:

Kulay:Kulay = (255, 0, 0) – Sa modelo ng kulay ng RGB, tumutugma ito sa purong pula bilang paunang halaga para sa katangiang ito.

Employee_name:String = Ivan Ivanovich - marahil ito ay isang hindi tipikal na kaso, na, sa halip, ay tumutugma sa situation manager_name:81pp§ = Ivan Ivanovich.

Visibility:Boolean = true – maaaring tumugma sa sitwasyon kung kailan, sa oras ng paglikha ng isang instance ng isang klase, ang isang window na tumutugma sa bagay na ito ay nilikha na makikita sa monitor screen.

Hugis: Polygon = rectangle - halos hindi nangangailangan ng komento, dahil dito pinag-uusapan natin ang geometric na hugis ng nilikha na bagay.

Kapag nagtatakda ng mga attribute, dalawang karagdagang syntactic na istruktura ang maaaring gamitin: salungguhitan ang attribute line at explanatory text sa mga curly bracket.

Ang pagsasalungguhit sa isang string ng katangian ay nangangahulugan na ang kaukulang katangian ay maaaring kumuha ng isang subset ng mga halaga mula sa ilang hanay ng mga halaga ng katangian, na tinutukoy ng uri nito. Ang mga halagang ito ay maaaring ituring bilang isang hanay ng mga talaan ng parehong uri o isang array na sama-samang nagpapakilala sa bawat bagay ng klase.

Halimbawa, kung ang ilang katangian ay tinukoy bilang Hugis: Parihaba. pagkatapos ito ay nangangahulugan na ang lahat ng mga bagay ng klase na ito ay maaaring magkaroon ng ilang iba't ibang anyo, bawat isa ay isang parihaba. Ang isa pang halimbawa ay ang pagtatakda ng katangian sa form na account_number:Integer. ano ang maaaring ibig sabihin para sa Empleyado na tumutol sa pagkakaroon ng isang partikular na subset ng mga account, ang kabuuang bilang nito ay hindi naayos nang maaga.

Ang string ng pag-aari ay ginagamit upang ipahiwatig ang mga halaga ng katangian na hindi mababago sa programa kapag nagtatrabaho sa ganitong uri ng bagay. Mga braces nagsasaad lamang sila ng isang nakapirming halaga ng kaukulang katangian para sa klase sa kabuuan, na dapat tanggapin ng lahat ng bagong likhang pagkakataon ng klase, nang walang pagbubukod. Ang value na ito ay kinukuha bilang orihinal na value ng attribute, na hindi maaaring i-override sa ibang pagkakataon. Ang kawalan ng isang default na string ng ari-arian ay binibigyang-kahulugan na ang halaga ng katumbas na katangian ay maaaring baguhin sa programa. Halimbawa, ang string ng property sa attribute record salary:Currency = = ($500) ay maaaring gamitin para magtalaga ng fixed salary para sa bawat object ng Employee class para sa isang partikular na posisyon sa ilang organisasyon. Sa kabilang banda, ang pagsusulat ng attribute na ito sa form na salary_payment: Currency = $500 ay nangangahulugan ng iba, ibig sabihin, kapag lumilikha ng isang bagong halimbawa ng Empleyado (isang pagkakatulad ay pagkuha ng isang bagong empleyado), isang default na suweldo na $500 ay nakatakda para dito. Gayunpaman, para sa mga indibidwal na empleyado, maaaring gumawa ng mga pagbubukod, parehong mas malaki at mas maliit, na dapat pangalagaan bilang karagdagan sa programa.

Ang ikatlong seksyon ng parihaba mula sa itaas ay naglalaman ng mga operasyon o pamamaraan ng klase. Ang operasyon ay isang serbisyong nagbibigay ng bawat pagkakataon ng isang klase para sa isang partikular na pangangailangan. Ang isang hanay ng mga operasyon ay nagpapakilala sa functional na aspeto ng pag-uugali ng isang klase. Ang pagsusulat ng mga pagpapatakbo ng klase sa UML ay na-standardize din at sumusunod sa ilang syntactic na panuntunan. Sa kasong ito, ang bawat operasyon ng klase ay tumutugma sa isang hiwalay na linya, na binubuo ng operation visibility quantifier, ang pangalan ng operasyon, isang expression ng uri ng value na ibinalik ng operasyon, at, posibleng, isang property line ng operasyong ito:

<квантор видимости><имя операции>(listahan ng mga parameter):

<выражение типа возвращаемого значения>(string ng ari-arian)

Ang visibility quantifier, tulad ng sa kaso ng mga katangian ng klase, ay maaaring tumagal ng isa sa tatlong posibleng mga halaga at, nang naaayon, ay ipinapakita gamit ang isang espesyal na character. Ang simbolo na "+" ay tumutukoy sa isang operasyon na may saklaw ng uri ng publiko. Ang simbolo na "#" ay tumutukoy sa isang operasyon na may saklaw ng uri na protektado. Panghuli, ang simbolo na "-" ay ginagamit upang tukuyin ang isang operasyon na may saklaw ng uri na pribado.

Maaaring tanggalin ang visibility quantifier para sa isang operasyon. Sa kasong ito, ang kawalan nito ay nangangahulugan lamang na ang visibility ng operasyon ay hindi tinukoy. Sa halip na maginoo na mga graphic na simbolo, maaari mo ring isulat ang kaukulang keyword: pampubliko, protektado, pribado.

Ang pangalan ng operasyon ay isang string ng text na ginagamit bilang isang identifier para sa kaukulang operasyon at samakatuwid ay dapat na natatangi sa loob ng isang partikular na klase. Ang pangalan ng katangian ay ang tanging kinakailangang elemento ng syntactic na pagtatalaga ng operasyon.

Ang listahan ng parameter ay isang listahan ng mga pormal na parameter na pinaghihiwalay ng kuwit, bawat isa ay maaaring katawanin bilang mga sumusunod:

<вид параметра><имя параметра>:<выражение типа>=<значение параметра по умолчанию>.

Narito ang uri ng parameter ay isa sa mga keyword na papasok, palabas o papasok na may default na halaga sa kung hindi tinukoy ang uri ng parameter. Ang pangalan ng parameter ay ang identifier ng kaukulang pormal na parameter. Ang isang uri ng expression ay isang partikular na wika na detalye ng uri ng pagbabalik ng kaukulang pormal na parameter. Sa wakas, ang isang default na halaga ay karaniwang isang expression para sa halaga ng isang pormal na parameter, ang syntax nito ay depende sa partikular na programming language at napapailalim sa mga paghihigpit nito.

Ang return type expression ay isa ring pagpapatupad-language specification ng uri o mga uri ng parameter value na ibinalik ng object pagkatapos isagawa ang kaukulang operasyon. Ang colon at return type na expression ay maaaring tanggalin kung ang operasyon ay hindi nagbabalik ng anumang halaga. Upang ipahiwatig ang maramihang ng return value, ang detalyeng ito ay maaaring isulat bilang isang listahan ng mga indibidwal na expression.

Ginagamit ang string ng property para tukuyin ang mga value ng property na maaaring ilapat sa elementong ito. Opsyonal ang string ng property at maaaring nawawala kung walang tinukoy na property.

Ang isang operasyon na may saklaw ng klase ay ipinahiwatig sa pamamagitan ng salungguhit sa pangalan at uri ng expression string. Bilang default, ang saklaw ng isang operasyon ay nauunawaan na isang object ng klase. Sa kasong ito, hindi nakasalungguhit ang pangalan at uri ng operasyon na expression string.

Ang isang operasyon na hindi maaaring baguhin ang estado ng system at, nang naaayon, ay walang side effect, ay ipinahiwatig ng string ng property na “(query)” (“(query)”). Kung hindi, maaaring baguhin ng operasyon ang estado ng system, kahit na walang garantiya na gagawin nito.

Upang mapabuti ang pagganap ng system, ang ilang mga operasyon ay maaaring isagawa nang magkatulad o sabay-sabay, habang ang iba ay maaari lamang gawin nang sunud-sunod. Sa kasong ito, upang ipahiwatig ang parallel execution ng operasyon, ang isang property string ng form na "(concurrency = name)" ay ginagamit, kung saan ang pangalan ay maaaring kumuha ng isa sa sumusunod na mga halaga: sequential, parallel, concurent, binabantayan. Sa kasong ito, ang mga sumusunod na semantika para sa mga halagang ito ay sinusunod:

Sequential - para sa operasyong ito kinakailangan upang matiyak ang tanging pagpapatupad nito sa sistema ng sabay-sabay na pagpapatupad ng iba pang mga operasyon ay maaaring humantong sa mga pagkakamali o paglabag sa integridad ng mga bagay sa klase.

Parallel (kasabay) - ang operasyon na ito, dahil sa mga katangian nito, ay maaaring isagawa nang kahanay sa iba pang mga operasyon sa system, habang ang parallelism ay dapat mapanatili sa antas ng pagpapatupad ng modelo.

Binabantayan - lahat ng mga tawag sa operasyong ito ay dapat na mahigpit na nakaayos sa oras upang mapanatili ang integridad ng mga bagay ng klase na ito, at maaaring gumawa ng karagdagang mga hakbang sa pagkontrol. mga pambihirang sitwasyon sa yugto ng pagpapatupad nito.

Upang bawasan ang notasyon, pinapayagang gumamit ng isang pangalan bilang string ng pag-aari upang ipahiwatig ang katumbas na halaga ng parallelism. Ang kawalan ng property string na ito ay nangangahulugan na ang concurrency semantics para sa operasyon ay hindi tinukoy. Samakatuwid, dapat nating ipagpalagay ang pinakamasamang kaso ng pagganap, kung saan ang operasyon ay nangangailangan ng sunud-sunod na pagpapatupad.

Ang paglitaw ng isang lagda ng pagpapatakbo sa pinakamataas na antas ay nagdedeklara ng operasyong ito para sa buong klase, at ang operasyong ito ay minana ng lahat ng mga inapo ng klase na ito. Kung ang isang operasyon sa ilang klase ay hindi ginanap (iyon ay, ang ilang pamamaraan ay hindi inilapat), kung gayon ang naturang operasyon ay maaaring markahan bilang abstract. Ang isa pang paraan upang ipakita ang abstract na katangian ng isang operasyon ay ang pagsulat ng lagda nito sa italics. Ang subordinate na hitsura ng isang naibigay na pagpasok ng operasyon na walang ari-arian (abstract) ay nagpapahiwatig ng katotohanan na ang kaukulang descendant class ay maaaring magsagawa ng ibinigay na operasyon bilang "paraan" nito.

Kung para sa ilang operasyon ay kinakailangan upang dagdagan na ipahiwatig ang mga tampok ng pagpapatupad nito (halimbawa, isang algorithm), kung gayon maaari itong gawin sa anyo ng isang tala na nakasulat sa anyo ng teksto, na naka-attach sa talaan ng operasyon sa kaukulang seksyon ng klase. Kung ang mga bagay ng isang klase ay tumatanggap at tumugon sa isang tiyak na signal, kung gayon ang talaan ng operasyong ito ay minarkahan ng keyword na "signal". Ang pagtatalaga na ito ay katumbas ng pagtatalaga ng ilang operasyon. Ang reaksyon ng isang bagay sa pagtanggap ng signal ay maaaring ipakita sa anyo ng ilang uri ng automat. Sa iba pang mga kaso, ang notasyong ito ay maaaring gamitin upang ipakita kung paano tumugon ang mga object ng klase sa mga sitwasyon ng error o pagbubukod, na maaaring i-modelo bilang mga signal o mensahe.

Ang pag-uugali ng isang operasyon ay maaaring higit pang tukuyin sa anyo ng isang tala na nakalakip sa operasyon. Sa kasong ito, ang teksto ng tala ay nakapaloob sa mga panaklong kung ito ay kumakatawan sa isang pormal na detalye sa ilang programming language at tumutugma sa elemento ng semantic constraint ng UML. Kung hindi, ang teksto ng tala ay isang simpleng paglalarawan sa natural na wika at ipinapahiwatig ng isang parihaba na may "kurba" sa kanang sulok sa itaas (tingnan ang Kabanata 4).

Maaaring hindi tukuyin ang listahan ng mga pormal na parameter at ang uri ng pagbabalik. Ang visibility quantifier ng mga katangian at pagpapatakbo ay maaaring tukuyin bilang espesyal na badge o simbolo na ginagamit upang graphic na kumakatawan sa mga modelo sa ilang tool. Ang mga pangalan ng mga operasyon, pati na rin ang mga katangian, ay isinulat gamit ang isang maliit na titik (maliit) na titik, at ang kanilang mga uri - na may malaking (kapital) na titik. Sa kasong ito, ang isang ipinag-uutos na bahagi ng linya ng talaan ng operasyon ay ang pagkakaroon ng pangalan ng operasyon at mga panaklong.

Bilang mga halimbawa ng mga pagpapatakbo ng pag-record, maaaring ibigay ang mga sumusunod na pagtatalaga ng mga indibidwal na operasyon:

Create() - maaaring magpahiwatig ng abstract na operasyon upang lumikha ng isang hiwalay na bagay ng isang klase, na pampubliko at hindi naglalaman ng mga pormal na parameter. Ang operasyong ito ay hindi nagbabalik ng anumang halaga pagkatapos ng pagpapatupad.

Draw(shape: Polygon = rectangle, fill_color: Color = (O, O, 255)) – maaaring magpahiwatig ng operasyon ng pagguhit ng isang rectangular area sa monitor screen asul, maliban kung ang ibang mga halaga ay tinukoy bilang mga argumento sa operasyong ito.

Request_customer_account (account_number: 1n1e§eg): Siggesu – nagsasaad ng operasyon upang matukoy ang pagkakaroon ng mga pondo sa kasalukuyang account ng isang kliyente sa bangko. Sa kasong ito, ang argumento ng operasyong ito ay ang account number ng kliyente, na nakasulat bilang isang integer (halimbawa, "123456"). Ang resulta ng operasyong ito ay isang numerong nakasulat sa tinatanggap na format ng pera (halimbawa, $1,500.00).

Issue_message():("Division by zero error") - ang kahulugan ng operasyong ito ay hindi nangangailangan ng paliwanag, dahil ito ay nakapaloob sa property line ng operasyon. Maaaring lumabas ang mensaheng ito sa screen ng monitor kung sinubukang hatiin ang isang tiyak na numero sa zero, na hindi katanggap-tanggap.

Bilang karagdagan sa panloob na istraktura o istraktura ng mga klase, ang kaukulang diagram ay nagpapahiwatig ng iba't ibang mga relasyon sa pagitan ng mga klase. Bukod dito, ang hanay ng mga uri ng naturang mga relasyon ay naayos sa wikang UML at paunang natukoy ng mga semantika ng mga ganitong uri ng relasyon. Ang mga pangunahing ugnayan o koneksyon sa UML ay:

Relasyon ng dependency

relasyon sa samahan

relasyon sa pangkalahatan

Relasyon sa pagsasakatuparan

Ang bawat isa sa mga ugnayang ito ay may sariling graphical na representasyon sa diagram, na sumasalamin sa mga ugnayan sa pagitan ng mga bagay ng kaukulang mga klase.

Ang isang dependency relation sa pangkalahatan ay nagpapahiwatig ng ilang semantikong ugnayan sa pagitan ng dalawang elemento ng isang modelo o dalawang set ng naturang mga elemento, na hindi isang kaugnayan ng asosasyon, generalization o pagpapatupad. Ito ay may kinalaman lamang sa mga elemento ng modelo mismo at hindi nangangailangan ng maraming indibidwal na mga halimbawa upang ipaliwanag ang kahulugan nito. 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 elemento ng modelo na nakasalalay dito.

Ang isang dependency na relasyon ay graphic na kinakatawan ng isang tuldok na linya sa pagitan ng mga katumbas na elemento na may arrow sa isang dulo (“->” o “<-»). На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику (рис. 5.3). На данном рисунке изображены два класса: Класс_А и Кяасс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс_А – клиентом этой зависимости.

kanin. 5.3. Graphical na representasyon ng isang dependency na relasyon sa isang class diagram

Ang buong hanay ng mga elemento ng modelo ay maaaring kumilos bilang isang klase ng kliyente at isang klase ng pinagmulan ng dependency. Sa kasong ito, ang isang linya ng arrow na nagmumula sa pinagmulan ng dependency ay nahahati sa ilang punto sa ilang magkakahiwalay na linya, bawat isa ay may hiwalay na arrow para sa klase ng kliyente. Halimbawa, kung ang paggana ng Class_C ay nakasalalay sa mga tampok ng pagpapatupad ng Class_A at Class_/>, kung gayon ang pag-asa na ito ay maaaring ilarawan bilang mga sumusunod (Larawan 5.4).

kanin. 5.4. Graphical na representasyon ng dependency sa pagitan ng client class (Class_C) at ang source classes (Class_L at Class_B)

Ang arrow ay maaaring markahan ng opsyonal ngunit karaniwang keyword sa mga panipi at opsyonal na custom na pangalan. Ang isang dependency na relasyon ay may paunang tinukoy na mga keyword na tumutukoy sa ilang mga espesyal na uri ng mga dependency. Ang mga keyword na ito (stereotypes) ay nakasulat sa mga panipi sa tabi ng arrow na tumutugma sa kaugnayang ito. Ang mga halimbawa ng mga stereotype para sa mga relasyon sa dependency ay ipinakita sa ibaba:

“access” – nagsisilbing ipahiwatig ang pagkakaroon 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 klase ng pinagmulan;

"import" - pampublikong katangian at ang mga operasyon ng pinagmulang klase ay naging bahagi ng klase ng kliyente na para bang sila ay direktang idineklara dito;

"pinuhin" - nagsasaad na ang klase ng kliyente ay nagsisilbing isang pagpipino ng pinagmulang klase para sa mga makasaysayang dahilan kapag lumilitaw ito karagdagang impormasyon habang gumagawa ng proyekto.

Ang kaugnayan ng asosasyon ay tumutugma sa pagkakaroon ng ilang relasyon sa pagitan ng mga klase. Ang relasyon na ito ay ipinahiwatig ng isang solidong linya na may karagdagang mga espesyal na simbolo na nagpapakilala sa mga indibidwal na katangian ng isang partikular na asosasyon. Ang mga karagdagang espesyal na character ay maaaring ang pangalan ng asosasyon, pati na rin ang mga pangalan at multiplicity ng mga klase ng tungkulin ng asosasyon. Ang pangalan ng asosasyon ay opsyonal na elemento mga pagtatalaga nito. Kung ito ay tinukoy, ito ay nakasulat na may malaking (kapital) na titik sa tabi ng linya ng kaukulang asosasyon.

Ang pinakasimpleng kaso ng relasyong ito ay isang binary association. Nag-uugnay ito ng eksaktong dalawang klase at, bilang isang pagbubukod, maaaring mag-link ng isang klase sa sarili nito. Para sa isang binary association, ang pagkakasunud-sunod ng mga klase ay maaaring ipahiwatig sa diagram gamit ang isang hugis-arrow na tatsulok sa tabi ng pangalan ng asosasyon. Ang direksyon ng arrow na ito ay nagpapahiwatig ng pagkakasunud-sunod ng mga klase, ang isa ay una (mula sa tatsulok na bahagi) at ang isa ay pangalawa (mula sa gilid ng vertex). Ang kawalan ng arrow na ito sa tabi ng pangalan ng asosasyon ay nangangahulugan na ang pagkakasunud-sunod ng mga klase sa ugnayang pinag-uusapan ay hindi tinukoy.

Bilang isang simpleng halimbawa ng isang binary association relationship, isaalang-alang ang relasyon sa pagitan ng dalawang klase - ang klase ng "Kumpanya" at ang klase ng "Empleyado" (Figure 5.5). Ang mga ito ay konektado sa isa't isa sa pamamagitan ng binary association Work, ang pangalan nito ay ipinahiwatig sa figure sa tabi ng linya ng asosasyon. Para sa relasyong ito, ang pagkakasunud-sunod ng mga klase ay tinukoy, ang una ay ang klase ng "Empleyado", at ang pangalawa ay ang klase ng "Kumpanya". Ang isang hiwalay na halimbawa o halimbawa ng relasyon na ito ay maaaring maging isang pares ng mga kahulugan (Petrov I. I., "Horns & Hooves"). Nangangahulugan ito na ang empleyado na si I.I. Petrov ay nagtatrabaho para sa kumpanya ng Horns & Hooves.

kanin. 5.5. Graphical na representasyon ng isang binary association na relasyon sa pagitan ng mga klase

Ang isang ternary association at mga asosasyon ng mas mataas na arity ay karaniwang tinatawag na N-ary association (basahin ang "enary association"). Ang nasabing asosasyon ay nag-uugnay ng 3 o higit pang mga klase sa ilang relasyon, habang ang isang klase ay maaaring lumahok sa asosasyon nang higit sa isang beses. Ang klase ng asosasyon ay may partikular na tungkulin sa kaukulang relasyon, na maaaring tahasang ipahiwatig sa diagram. Ang bawat instance ng isang N-ary association ay isang N-ary tuple ng object values ​​mula sa kaukulang mga klase. Ang binary association ay isang espesyal na kaso ng isang N-ary association, kapag ang value ay N=2, at may sariling notation.

Ang isang asosasyong N-ary ay graphic na ipinahiwatig ng isang brilyante, kung saan ang mga linya ay humahantong sa mga simbolo ng klase ng asosasyong ito. Sa kasong ito, ang brilyante ay konektado sa mga simbolo ng kaukulang mga klase sa pamamagitan ng mga solidong linya. Karaniwan, ang mga linya ay iginuhit mula sa mga vertices ng isang rhombus o mula sa gitna ng mga gilid nito. Ang pangalan ng N-ary association ay nakasulat sa tabi ng brilyante ng kaukulang asosasyon.

Ang pagkakasunud-sunod ng mga klase sa isang asosasyong N-ary, hindi katulad ng pagkakasunud-sunod ng mga hanay sa isang kaugnayan, ay hindi naayos sa diagram. Ang ilang klase ay maaaring ikabit sa brilyante na may tuldok na linya. Nangangahulugan ito na ang klase ay nagbibigay ng suporta para sa mga katangian ng kaukulang N-ary association, at ang N-ary association mismo ay may mga katangian, operasyon, at/o asosasyon. Sa madaling salita, ang nasabing asosasyon, sa turn, ay isang klase na may kaukulang pagtatalaga sa anyo ng isang parihaba at isang independiyenteng elemento ng wikang UML - isang Klase ng Asosasyon. Ang N-ary association ay hindi maaaring maglaman ng aggregation symbol para sa alinman sa mga tungkulin nito.

Bilang isang halimbawa ng isang partikular na ternary association, isaalang-alang ang kaugnayan sa pagitan ng tatlong klase: “Football Team,” “Taon,” at “Laro.” Ang asosasyong ito ay nagpapahiwatig ng pagkakaroon ng relasyon sa pagitan ng tatlong klase na ito, na maaaring kumatawan sa impormasyon tungkol sa pagganap ng mga koponan ng football sa pambansang kampeonato sa nakalipas na ilang taon (Larawan 5.6).

Tulad ng nabanggit, ang isang hiwalay na klase ng asosasyon ay may sariling papel sa relasyon. Ang papel na ito ay maaaring ilarawan nang graphic sa isang class diagram. Para sa layuning ito, sa wikang UML, isang espesyal na elemento ang ipinakilala sa pagsasaalang-alang - ang pagtatapos ng asosasyon (Pagtatapos ng Asosasyon), na graphic na tumutugma sa punto ng koneksyon ng linya ng asosasyon na may isang hiwalay na klase. Ang pagtatapos ng isang asosasyon ay bahagi ng asosasyon, ngunit hindi ang klase. Ang bawat asosasyon ay may dalawa o higit pang mga dulo ng asosasyon. Ang pinakamahalagang pag-aari ng asosasyon ay ipinahiwatig sa diagram sa tabi ng mga elemento ng asosasyon na ito at dapat na i-shuffle kasama ng mga ito.

kanin. 5.6. Graphical na representasyon ng ternary association sa pagitan ng tatlong klase

Ang isa sa mga karagdagang pagtatalaga ay ang pangalan ng tungkulin ng isang partikular na klase na bahagi ng isang asosasyon. Ang pangalan ng tungkulin ay isang linya ng teksto malapit sa dulo ng asosasyon para sa kaukulang klase. Ito ay nagsasaad ng tiyak na papel na ginagampanan ng klase na siyang katapusan ng samahan na pinag-uusapan. Ang pangalan ng tungkulin ay isang opsyonal na elemento ng notasyon at maaaring hindi lumabas sa diagram.

Ang susunod na elemento ng notasyon ay ang multiplicity ng mga indibidwal na klase na mga dulo ng asosasyon. Ang multiplicity ng isang partikular na klase ay ipinahiwatig bilang isang pagitan ng mga integer, katulad ng multiplicity ng mga katangian at pagpapatakbo ng mga klase. Ang isang agwat ay isinulat malapit sa dulo ng isang asosasyon at, para sa isang N-ary na asosasyon, ay tumutukoy sa potensyal na bilang ng mga natatanging pagkakataon o tuple na halaga ng asosasyong iyon na maaaring mangyari kapag ang natitirang mga N-1 na pagkakataon o mga halaga ng klase ay naayos.

Kaya, para sa halimbawang tinalakay kanina (tingnan ang Fig. 5.5), ang multiplicity ng "1" para sa klase ng "Company" ay nangangahulugan na ang bawat empleyado ay maaaring magtrabaho sa isang kumpanya lamang. Ang multiplicity ng "1..*" para sa klase ng "Empleyado" ay nangangahulugan na ang bawat kumpanya ay maaaring magkaroon ng ilang empleyado, ang kabuuang bilang nito ay hindi alam nang maaga at hindi limitado sa anumang paraan. Tandaan na sa halip na ang multiplicity na "1..*", imposibleng isulat lamang ang simbolo na "*", dahil ang huli ay nangangahulugan ng multiplicity na "0..*". Para sa halimbawang ito, nangangahulugan ito na maaaring walang empleyado ang mga indibidwal na kumpanya. Ngunit ang gayong multiplicity ay lubos na katanggap-tanggap sa ibang mga sitwasyon, tulad ng makikita mula sa halimbawang tinalakay sa itaas (Larawan 5.6).

Tulad ng para sa iba pang mga katangian ng relasyon, asosasyon, kung naroroon, maaari silang ituring bilang mga katangian ng klase ng asosasyon at maaaring ipahiwatig sa diagram sa karaniwang paraan para sa klase sa kaukulang seksyon ng parihaba ng klase.

Ang isang espesyal na kaso ng isang relasyon sa asosasyon ay ang tinatawag na eksklusibong asosasyon (Xor-association). Ang mga semantika ng asosasyong ito ay tumuturo sa katotohanan na sa ilang potensyal posibleng mga opsyon ng isang naibigay na asosasyon, isang instance lang nito ang magagamit sa isang pagkakataon. Sa isang class diagram, ang isang eksklusibong asosasyon ay kinakatawan ng isang may tuldok na linya na nagkokonekta sa dalawa o higit pang mga asosasyon, sa tabi kung saan nakasulat ang constraint string na "(hog)".

Halimbawa, maaaring mabuksan ang isang bank account para sa isang kliyente, na maaaring indibidwal(indibidwal) o kumpanya, na inilalarawan gamit ang isang eksklusibong asosasyon (Figure 5.7).

kanin. 5.7. Graphical na representasyon ng isang eksklusibong ugnayan sa pagitan ng tatlong klase

Ang isang espesyal na anyo o espesyal na kaso ng kaugnayan ng asosasyon ay ang ugnayan ng pagsasama-sama, na, sa turn, ay mayroon ding isang espesyal na anyo - ang ugnayan ng komposisyon. Dahil ang mga relasyon na ito ay may sariling mga espesyal na pagtatalaga at nauugnay sa mga pangunahing konsepto UML na wika, isasaalang-alang namin ang mga ito nang sunud-sunod.

Nagaganap ang isang pinagsama-samang ugnayan sa pagitan ng ilang klase kung ang isa sa mga klase ay kumakatawan sa ilang entity na kinabibilangan mga bahagi ibang entity.

Ang ugnayang ito ay may pangunahing kahalagahan para sa paglalarawan ng istruktura ng mga kumplikadong sistema, dahil ginagamit ito upang kumatawan sa mga ugnayan ng sistema ng uri ng "bahagi-buong". Inilalantad ang panloob na istraktura ng system, ipinapakita ng ugnayan ng pagsasama-sama kung anong mga bahagi ang binubuo ng system at kung paano nauugnay ang mga ito sa isa't isa. Mula sa punto ng view ng modelo, ang mga indibidwal na bahagi ng system ay maaaring kumilos kapwa sa anyo ng mga elemento at sa anyo ng mga subsystem, na, sa turn, ay maaari ding bumuo ng mga pinagsama-samang bahagi o subsystem. Ang ugnayang ito ay likas na naglalarawan ng pagkabulok o pagkasira ng isang kumplikadong sistema sa mas simpleng bahagi ng mga bahagi, na maaari ding mabulok kung kailanganin sa ibang araw.

Malinaw na ang paghahati ng isang sistema sa mga bahaging bahagi nito, na isinasaalang-alang sa aspetong ito, ay kumakatawan sa isang tiyak na hierarchy ng mga bahagi nito, ngunit ang hierarchy na ito ay sa panimula ay naiiba mula sa hierarchy na nabuo ng ugnayan ng generalization. Ang pagkakaiba ay ang mga bahagi ng system ay hindi sa anumang paraan obligadong magmana ng mga pag-aari at pag-uugali nito, dahil sila ay ganap na independiyenteng mga entidad. Bukod dito, ang mga bahagi ng isang kabuuan ay may sariling katangian at pagpapatakbo na malaki ang pagkakaiba sa mga katangian at pagpapatakbo ng kabuuan.

Bilang isang halimbawa ng isang pinagsama-samang relasyon, isaalang-alang ang isang bahagi-buong relasyon na nangyayari sa pagitan ng entity na "Truck" at mga bahagi tulad ng "Engine", "Chassis", "Cabin", "Katawan". Nang walang pagpapanggap na eksaktong tumutugma sa terminolohiya ng isang partikular na lugar ng paksa, hindi mahirap isipin iyon trak ay binubuo ng isang makina, tsasis, taksi at katawan. Ang ugnayang ito sa pagitan ng klase na "Truck_vehicle" at ng mga klase na "Engine", "Chassis", "Cabin", "Body" ang naglalarawan sa pinagsama-samang relasyon.

Sa graphically, ang ugnayan ng pagsasama-sama ay inilalarawan ng isang solidong linya, ang isa sa mga dulo nito ay isang hindi napunong brilyante sa loob. Ang brilyante na ito ay nagpapahiwatig ng alinmang klase na kumakatawan sa "buo." Ang natitirang mga klase ay ang "mga bahagi" nito (Larawan 5.8).

kanin. 5.8. Graphical na representasyon ng isang pinagsama-samang relasyon sa UML

Ang isa pang halimbawa ng ugnayan ng pagsasama-sama ay ang paghahati ng isang personal na computer sa mga bahaging bahagi nito, na kilala ng bawat mambabasa: unit ng system, monitor, keyboard at mouse. Gamit ang mga notasyon ng wika ng UML, ang komposisyon ng bahagi ng isang PC ay maaaring katawanin sa anyo ng kaukulang class diagram (Larawan 5.9), na sa kasong ito ay naglalarawan ng ugnayan ng pagsasama-sama.

kanin. 5.9. Class diagram upang ilarawan ang ugnayan ng pagsasama-sama gamit ang isang PC bilang isang halimbawa

Ang ugnayan sa komposisyon, gaya ng nabanggit kanina, ay isang espesyal na kaso ng ugnayan ng pagsasama-sama. Ang kaugnayang ito ay nagsisilbing i-highlight ang isang espesyal na anyo ng ugnayang "bahagi-buong", kung saan ang mga bahaging bumubuo sa ilang kahulugan ay matatagpuan sa loob ng kabuuan. Ang pagtitiyak ng relasyon sa pagitan ng mga ito ay nakasalalay sa katotohanan na ang mga bahagi ay hindi maaaring kumilos nang hiwalay mula sa kabuuan, ibig sabihin, sa pagkawasak ng kabuuan, ang lahat ng mga bahagi nito ay nawasak.

Marahil hindi ang pinakamahusay, ngunit tiyak na isang malinaw na halimbawa ng relasyon na ito para sa lahat, ay ang buhay na cell sa biology. Ang isa pang halimbawa ay isang window ng interface ng programa, na maaaring binubuo ng isang bar ng pamagat, mga pindutan ng kontrol sa laki, mga scroll bar, isang pangunahing menu, isang lugar ng trabaho, at isang status bar. Madaling maunawaan na ang naturang window ay isang klase, at ang mga bahagi nito ay parehong mga klase at katangian o katangian ng window. Ang huling pangyayari ay napaka katangian ng relasyon sa komposisyon, dahil ito ay sumasalamin iba't ibang paraan representasyon ng relasyong ito.

Sa graphically, ang relasyon ng komposisyon ay inilalarawan ng isang solidong linya, ang isa sa mga dulo nito ay isang brilyante na may kulay sa loob. Ipinapahiwatig ng brilyante na ito ang alinmang klase ay isang klase ng komposisyon o "buo." Ang natitirang mga klase ay ang "mga bahagi" nito (Larawan 5.10).

kanin. 5.10. Graphical na representasyon ng isang ugnayan sa komposisyon sa UML

Maaaring gamitin ang mga karagdagang notasyon para sa mga ugnayan sa komposisyon at pagsasama-sama bilang karagdagang mga notasyon para sa kaugnayan sa pagkakaugnay. Lalo na, na nagpapahiwatig ng multiplicity ng klase ng asosasyon at ang pangalan ng asosasyong ito, na opsyonal. Kaugnay ng halimbawa ng klase ng "Program_Window" na inilarawan sa itaas, ang class diagram nito ay maaaring magmukhang ganito (Fig. 5.11).

kanin. 5.11. Class diagram upang ilarawan ang ugnayan ng komposisyon gamit ang window class ng programa bilang isang halimbawa

Maaaring ilarawan ng halimbawang ito ang iba pang mga tampok ng binuo programa sa kompyuter, na hindi tahasang tinukoy kapag inilalarawan ang halimbawang ito Kaya, sa partikular, ang pagpapakita ng multiplicity ng 1 sa tabi ng klase ng "Work_area" ay tipikal para sa mga aplikasyon ng solong dokumento.

Ang generalization relation ay isang ordinaryong taxonomic na kaugnayan sa pagitan ng isang mas pangkalahatang elemento (magulang o ninuno) at isang mas tiyak o espesyal na elemento (anak o inapo). Maaaring gamitin ang kaugnayang ito upang kumatawan sa mga ugnayan sa pagitan ng mga pakete, klase, kaso ng paggamit, at iba pang elemento ng wikang UML.

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 nito 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. Sa mga diagram, ang isang ugnayan sa pangkalahatan ay ipinahiwatig ng isang solidong linya na may isang tatsulok na arrow sa isang dulo (Larawan 5.12). Ang isang arrow ay nagpapahiwatig ng isang mas pangkalahatang klase (ancestor class o superclass), habang ang kawalan nito ay nagpapahiwatig ng isang mas espesyal na klase (descendant class o subclass).

kanin. 5.12. Graphical na representasyon ng isang generalization na relasyon sa UML

Karaniwan, maaaring magpakita ang isang diagram ng ilang linya para sa isang ugnayang pangkalahatan, na nagpapakita ng likas na taxonomic nito. Sa kasong ito, ang isang mas pangkalahatang klase ay nahahati sa mga subclass ng isang Generalization relation. Halimbawa, ang klase na Geometric_shape_on_plane (ang italics ay nagsasaad ng abstract na klase) ay maaaring kumilos bilang isang superclass para sa mga subclass na tumutugma sa mga partikular na geometric na hugis, tulad ng Rectangle, Circle, Ellipse, atbp. Ang katotohanang ito ay maaaring ilarawan sa grapiko sa anyo ng isang class diagram ng ang sumusunod na uri (Larawan 5.13).

kanin. 5.13. Isang halimbawa ng isang graphical na representasyon ng isang relasyon sa pangkalahatan ng klase

Upang gawing simple ang notasyon sa isang class diagram, isang set ng mga linya na nagsasaad ng parehong generalization relation ay maaaring pagsamahin sa isang linya. Sa kasong ito, ang mga indibidwal na linyang ito ay inilalarawang nagtatagpo sa isang solong arrow na may karaniwang punto ng intersection sa kanila (Larawan 5.14).

kanin. 5.14. Isang variant ng graphical na representasyon ng ugnayan ng generalization ng klase para sa kaso ng pagsasama-sama ng mga indibidwal na linya

Ang notasyong ito sa anyo ay tumutugma sa isang espesyal na uri ng graph, na tinalakay sa Kabanata 2, ibig sabihin, isang hierarchical tree. Sa kasong ito, ang ancestor class ay ang ugat ng punong ito, at ang descendant classes ay ang mga dahon nito. Ang pagkakaiba ay maaaring ipahiwatig ng isang diagram ng klase ang potensyal para sa iba pang mga descendant na klase na hindi kasama sa mga simbolo ng class diagram (mga ellipse sa halip na mga parihaba).

Sa tabi ng generalization arrow, maaaring maglagay ng linya ng text na nagsasaad ng ilang karagdagang katangian ng kaugnayang ito. Ang text na ito ilalapat sa lahat ng linya ng generalization na napupunta sa mga descendant na klase. Sa madaling salita, ang nabanggit na ari-arian ay nalalapat sa lahat ng mga subclass ng isang ibinigay na kaugnayan. Sa kasong ito, ang teksto ay dapat isaalang-alang bilang isang limitasyon, at pagkatapos ay nakasulat ito sa mga kulot na bracket.

Ang mga sumusunod na keyword ng UML ay maaaring gamitin bilang mga paghihigpit:

(kumpleto) – nangangahulugan na sa ugnayang ito sa pangkalahatan ang lahat ng mga descendant classes ay tinukoy, at ang ancestor class na ito ay hindi maaaring magkaroon ng ibang descendant classes. Halimbawa - ang klase ng Bank_Client ay ang ninuno ng dalawang klase: Indibidwal_tao at Kumpanya, at wala itong iba pang mga descendant na klase. Sa kaukulang class diagram, ito ay maaaring ipahiwatig nang tahasan sa pamamagitan ng pagsulat ng constraint string na ito sa tabi ng generalization line;

(disjoint) – nangangahulugan na ang mga descendant classes ay hindi maaaring maglaman ng mga object na sabay-sabay na instance ng dalawa o higit pang klase. Sa halimbawa sa itaas, nasiyahan din ang kundisyong ito, dahil ipinapalagay na walang partikular na indibidwal ang maaari ding maging partikular na kumpanya. Sa kasong ito, sa tabi ng linya ng generalization, maaari mong isulat ang linya ng pagpilit na ito;

(hindi kumpleto) – nangangahulugang ang kaso na kabaligtaran ng una. Ibig sabihin, ipinapalagay na hindi lahat ng mga descendant classes ay ipinahiwatig sa diagram. Sa dakong huli, posibleng kumpletuhin ang kanilang listahan nang hindi binabago ang naayos na diagram. Ang isang halimbawa ay isang diagram ng klase ng "Kotse", kung saan ang indikasyon ng lahat ng mga modelo ng kotse nang walang pagbubukod ay naaayon sa paglikha ng kaukulang catalog. Sa kabilang banda, para sa isang hiwalay na gawain, tulad ng pagbuo ng isang sistema para sa pagbebenta ng mga kotse ng mga partikular na modelo, hindi ito kinakailangan. Ngunit kinakailangan pa ring ipahiwatig ang hindi kumpleto ng istraktura ng mga descendant classes;

(nagpapatong) - nangangahulugan na ang mga indibidwal na pagkakataon ng mga descendant na klase ay maaaring kabilang sa ilang mga klase nang sabay-sabay. Halimbawa - ang klase ng "Polygon" ay ang ancestor class ng "Rectangle" class at ang "Rhombus" class. Gayunpaman, mayroong isang hiwalay na klase na "Square", mga pagkakataon kung saan ay sabay-sabay na mga bagay ng unang dalawang klase. Medyo natural na ipahiwatig ang ganitong sitwasyon nang tahasan gamit ang constraint string na ito.

Isinasaalang-alang ang posibilidad ng paggamit ng mga linya ng pagpilit, ang diagram ng klase (Larawan 5.14) ay maaaring ilarawan nang walang mga ellipse at walang pagkawala ng impormasyon (Larawan 5.15).

kanin. 5.15. Isang opsyon para sa graphic na kumakatawan sa isang ugnayang generalization ng klase gamit ang isang string constraint

Upang ilarawan ang mga tampok ng paggamit ng ugnayang pangkalahatan, ibahin natin ang isa sa mga naunang tinalakay na halimbawa ng representasyon ng klase sa graphical na notasyon ng wikang UML. Bilang halimbawa, isaalang-alang ang class nesting hierarchy para sa abstract class na "Car" (tingnan ang Fig. 1,2, 2.7). Tulad ng madaling makita, ang ugnayan sa pagitan ng mga indibidwal na klase sa mga figure na ito ay tiyak na isang pangkalahatang relasyon, na sa wikang UML ay may espesyal na graphic na pagtatalaga. Isinasaalang-alang ang graphical notation na ito, ang isang fragment ng semantic network na kumakatawan sa hierarchy ng klase na "Car" (tingnan ang Fig. 2.7) ay maaaring katawanin bilang ang sumusunod na class diagram (Fig. 5.16).

Tandaan na sa halimbawang ito, ang lahat ng mga klase sa itaas na antas ay abstract, ibig sabihin, hindi sila maaaring katawanin ng sarili nilang mga pagkakataon. Kaya naman ang kanilang mga pangalan ay nakasulat sa italics. Sa kabaligtaran, ang mga klase sa mababang antas ay tiyak, dahil maaari silang katawanin ng kanilang sariling mga kopya, na mga gawang kotse ng kaukulang modelo na may natatanging serial number.

kanin. 5.16. Isang fragment ng class diagram na may ugnayang pangkalahatan para kumatawan sa hierarchy ng klase ng "Kotse" mula sa halimbawang tinalakay kanina (tingnan ang Fig. 2.7)

Ang mga interface ay mga elemento ng isang use case diagram at tinalakay sa Kabanata 4. Gayunpaman, kapag gumagawa ng isang class diagram, ang mga indibidwal na interface ay maaaring tukuyin, kung saan ang isang espesyal na graphic na simbolo ay ginagamit upang kumatawan sa kanila - isang class rectangle na may keyword o stereotype "interface" (Larawan 5.17). Sa kasong ito, ang rektanggulo ay walang seksyon ng mga katangian, at tanging ang seksyon ng mga pagpapatakbo ang ipinahiwatig.

kanin. 5.17. Isang halimbawa ng isang graphical na representasyon ng isang interface sa isang class diagram

Ang isang bagay ay isang hiwalay na halimbawa ng isang klase na nilikha sa panahon ng pagpapatupad ng programa. Mayroon itong sariling pangalan at mga partikular na halaga ng katangian. Para sa iba't ibang dahilan, maaaring kailanganin na magpakita ng mga ugnayan hindi lamang sa pagitan ng mga klase ng modelo, kundi pati na rin sa pagitan ng mga indibidwal na bagay na nagpapatupad ng mga klaseng ito. Sa kasong ito, maaaring bumuo ng isang object diagram, na, kahit na hindi kanonikal sa metamodel ng UML, ay may independiyenteng layunin.

Upang graphical na kumatawan sa mga bagay, ang parehong parihaba na simbolo ay ginagamit tulad ng para sa mga klase. Lumilitaw ang mga pagkakaiba kapag tinukoy ang mga pangalan ng mga bagay, na sa kaso ng mga bagay ay kinakailangang may salungguhit (Larawan 5.18). Sa kasong ito, ang talaan ng pangalan ng bagay ay isang linya ng teksto "pangalan ng bagay:pangalan ng klase", pinaghihiwalay ng colon (Larawan 5.18 a, b). Ang pangalan ng bagay ay maaaring nawawala, kung saan ipinapalagay na ang bagay ay hindi nagpapakilala, at ang tutuldok ay nagpapahiwatig ng ganitong pangyayari (Larawan 5.18, d). Maaaring wala rin ang pangalan ng klase. Pagkatapos ang pangalan ng bagay ay ipinahiwatig lamang (Larawan 5.18, c). Ang mga katangian ng bagay ay kumukuha ng mga partikular na halaga.

Kapag naglalarawan ng isang object diagram, kailangan mong tandaan na ang bawat bagay ay isang halimbawa ng kaukulang klase, at ang mga ugnayan sa pagitan ng mga bagay ay inilarawan gamit ang mga koneksyon (mga link), na mga pagkakataon ng kaukulang mga relasyon. Sa kasong ito, ang lahat ng mga koneksyon ay inilalarawan bilang mga solidong linya. Ang mga tampok ng representasyon ng bagay ay tatalakayin nang mas detalyado sa Kabanata 9 kapag pinag-aaralan ang mga diagram ng kooperasyon.

kanin. 5.18. Isang halimbawa ng graphical na representasyon ng mga bagay sa mga diagram ng UML

Ang isang template o parameterized na klase ay inilaan upang tukuyin ang isang klase na may isa (o higit pa) na hindi nakapirming mga pormal na parameter. Tinutukoy nito ang isang buong pamilya o hanay ng mga klase, ang bawat isa ay maaaring makuha sa pamamagitan ng pag-uugnay ng mga parameter na ito sa mga tunay na halaga. Karaniwan, ang mga parameter ng template ay mga uri ng katangian ng klase, tulad ng mga integer, enumeration, string array, atbp. Sa isang mas kumplikadong kaso, ang mga pormal na parameter ay maaari ding kumatawan sa mga operasyon ng klase.

Sa graphically, ang template ay kinakatawan ng isang parihaba na may isang maliit na parihaba ng mga tuldok na linya na nakakabit sa kanang itaas na sulok (Larawan 5.19), ang isang malaking rektanggulo ay maaaring hatiin sa mga seksyon, katulad ng pagtatalaga para sa isang klase. Ang itaas na parihaba ay naglalaman ng isang listahan ng mga pormal na parameter para sa mga klase na maaaring makuha batay sa template na ito. Sa itaas na seksyon ng template, ang pangalan nito ay nakasulat ayon sa mga patakaran para sa pagtatala ng mga pangalan para sa mga klase.

kanin. 5.19. Graphical na representasyon ng isang pattern sa isang class diagram

Ang template ay hindi maaaring direktang gamitin bilang isang klase dahil naglalaman ito ng hindi natukoy na mga parameter. Kadalasan, ang isang superclass ay gumaganap bilang isang template, ang mga parameter kung saan ay tinukoy sa mga descendant na klase nito. Malinaw, sa kasong ito, mayroong kaugnayan sa dependency sa pagitan nila sa keyword na "bind", kapag ang klase ng kliyente ay maaaring gumamit ng ilang template para sa kasunod na parameterization nito. Sa isang mas partikular na kaso, sa pagitan ng isang template at ang klase na nabuo mula dito, mayroong isang generalization na relasyon sa mana ng mga katangian ng template (Fig. 5.20). Itinatampok ng halimbawang ito ang katotohanan na ang klase ng "Address" ay maaaring makuha mula sa template ng Linked_List batay sa pag-update ng mga pormal na parameter na "S, k, l" na may aktwal na mga katangian na "kalye, bahay, apartment".

Ang parehong template ay maaaring gamitin upang tukuyin (i-instantiate) ang isa pang klase, sabihin, ang "Points_on_Plane" na klase. Sa kasong ito, ina-update ng klase na "Points_on_Plane" ang parehong mga pormal na parameter, ngunit may iba't ibang mga halaga, halimbawa, "btsG<координаты_точки, х, у>. Ang konsepto ng mga template ay isang napakalakas na tool sa OOP, at samakatuwid ang paggamit nito sa wikang UML ay nagbibigay-daan hindi lamang upang bawasan ang laki ng mga diagram, kundi pati na rin sa pinakawastong kontrolin ang pagmamana ng mga katangian at pag-uugali. indibidwal na elemento mga modelo.

kanin. 5.20. Halimbawa ng paggamit ng pattern sa isang class diagram

Ang proseso ng pagbuo ng class diagram ay sentro sa object-oriented na disenyo ng mga kumplikadong sistema. Hindi lamang ang tagumpay ng proseso ng disenyo, kundi pati na rin ang pagganap ng pagpapatupad ng programa ay madalas na nakasalalay sa kakayahang pumili ng tama ng mga klase at magtatag ng mga relasyon sa pagitan nila. Tulad ng ipinapakita ng kasanayan sa OOP, bawat programmer sa kanyang trabaho ay nagsisikap na gamitin, sa isang antas o iba pa, ang naipon na personal na karanasan kapag bumubuo ng mga bagong proyekto. Ito ay dahil sa pagnanais na bawasan ang isang bagong problema sa mga nalutas na upang magamit hindi lamang ang mga napatunayang fragment ng program code, kundi pati na rin ang mga indibidwal na bahagi sa kabuuan (mga bahaging aklatan).

Ang stereotypical na diskarte na ito ay maaaring makabuluhang bawasan ang oras ng pagpapatupad ng proyekto, ngunit katanggap-tanggap lamang kung ang bagong proyekto ay hindi masyadong naiiba sa konsepto at teknolohikal mula sa mga nauna. Kung hindi, ang presyo para sa pagbabawas ng timeline ng proyekto ay maaaring ang pagpapatupad nito sa isang hindi napapanahong teknolohikal na base. Tulad ng para sa aktwal na pag-istruktura ng bagay ng lugar ng paksa, angkop na sumunod sa mga rekomendasyon na naipon sa OOP. Ang mga ito ay malawak na sakop sa panitikan at samakatuwid ay hindi tinalakay dito.

Kapag tinutukoy ang mga klase, katangian at pagpapatakbo at tinutukoy ang kanilang mga pangalan at uri, palaging nahaharap ang mga domestic developer sa isang hindi sinasadyang tanong: aling wika ang dapat gamitin bilang natural na wika, Russian o English? Sa isang banda, ang paggamit katutubong wika upang ilarawan ang modelo ay ang pinaka sa natural na paraan ang mga representasyon nito at sa pinakamalaking lawak ay sumasalamin sa communicative function ng system model. Sa kabilang banda, ang pagbuo ng isang modelo ay isa lamang sa mga yugto sa pagbuo ng kaukulang sistema, at ang paggamit ng mga tool para sa pagpapatupad nito sa karamihan ng mga kaso ay nangangailangan ng paggamit ng mga terminong Ingles. Ito ang dahilan kung bakit mayroong isang katangian na kalabuan kung saan ang mga madla na nagsasalita ng Ingles ay tila ganap na hindi pamilyar.

Bilang sagot sa tanong na iniharap sa itaas, dapat tandaan na ito ay pinaka-marapat na sumunod sa mga sumusunod na rekomendasyon. Kapag bumubuo ng isang diagram ng use case, na siyang pinaka-pangkalahatang modelo ng konsepto ng dinisenyo na sistema, ang paggamit ng mga termino sa wikang Ruso ay hindi lamang nabibigyang katwiran mula sa punto ng view ng paglalarawan ng istraktura ng paksa, ngunit epektibo rin mula sa punto. ng view ng pakikipag-ugnayan sa komunikasyon sa customer at mga user. Kapag gumagawa ng iba pang mga uri ng mga diagram, isang makatwirang kompromiso ang dapat gawin.

Sa partikular, sa mga unang yugto ng pagbuo ng mga diagram, ang pagpapayo ng paggamit ng mga termino sa wikang Ruso ay medyo halata at makatwiran. Gayunpaman, dahil ang graphical na modelo ay handa na para sa pagpapatupad sa anyo ng isang software system at inilipat sa mga programmer para sa karagdagang trabaho, ang diin ay maaaring lumipat patungo sa paggamit ng mga termino sa wikang Ingles, na sa isang antas o iba pa ay sumasalamin sa mga tampok ng programming wika kung saan ipinapalagay ang pagpapatupad ng modelong ito.

Bukod dito, ang paggamit ng mga tool ng CASE para sa automation ng OOAP ay kadalasang nagpapataw ng sarili nitong mga kinakailangan sa wika ng detalye ng modelo. Ito ay para sa kadahilanang ito na ang karamihan sa mga halimbawa sa panitikan ay ibinibigay sa Ingles, at kapag sila ay isinalin sa Russian, hindi lamang ang katumpakan ng mga salita ay maaaring mawala, kundi pati na rin ang mga semantika ng mga kaukulang konsepto.

Kapag nabuo na ang class diagram, maaaring ipagpatuloy ang proseso ng OOAP sa dalawang direksyon. Sa isang banda, kung ang pag-uugali ng system ay walang halaga, maaari mong simulan ang pagbuo ng kooperasyon at mga diagram ng bahagi. Gayunpaman, para sa kumplikado mga dynamic na sistema Ang pag-uugali ay kumakatawan sa isang kritikal na aspeto ng kanilang paggana. Ang pagdedetalye ng pag-uugali ay ginagawa nang sunud-sunod sa pamamagitan ng pagbuo ng state, sequence, at activity diagram. Sisimulan nating pag-aralan ang una sa mga ito sa Kabanata 6.

Mga Tala:

Tandaan 4

Ang kahulugan sa itaas ng isang klase ay medyo pangkalahatan. Sa mga susunod na kabanata, habang pinag-aaralan natin ang materyal, lilinawin ang terminong ito batay sa pagtatatag ng mga koneksyon sa semantiko sa iba pang mga konsepto ng pagsusuri at disenyo na nakatuon sa bagay.

Tandaan 44

Sa ilang mga kaso, kinakailangan na tahasang ipahiwatig kung saang pakete kabilang ang isang partikular na klase. Para sa layuning ito, ginagamit ang isang espesyal na karakter ng separator - ang double colon "::". Ang syntax ng string ng pangalan ng klase sa kasong ito ay ang mga sumusunod<Имя_пакета>::<Имя_класса>. Sa madaling salita, ang pangalan ng klase ay dapat na tahasang unahan ng pangalan ng package kung saan ito dapat italaga. Halimbawa, kung ang isang package na pinangalanang "Bank" ay tinukoy, ang klase ng "Account" sa bangkong ito ay maaaring isulat bilang: "Bank::Account".

Tandaan 45

Dahil ang UML ay invariant kaugnay ng pagpapatupad ng mga construct nito sa mga partikular na programming language, ang mga semantika ng mga indibidwal na visibility quantifier ay hindi mahigpit na naaayos. Ang mga kahulugan ng mga quantifier na ito ay dapat na higit pang linawin sa pamamagitan ng pagpapaliwanag ng natural na teksto ng wika o isang kasunduan sa paggamit ng naaangkop na software-dependent syntactic constructs.

Tandaan 46

Maaaring tukuyin ang mga karagdagang visibility quantifier para sa mga partikular na programming language. Sa kasong ito, ang mga naturang karagdagan ay isang extension ng pangunahing notasyon at nangangailangan ng naaangkop na mga paliwanag sa anyo ng teksto sa natural na wika o bilang isang string ng pag-aari.

Tandaan 47

Ang isang dependency na relasyon ay ang pinakakaraniwang anyo ng relasyon sa UML. Ang lahat ng iba pang uri ng mga relasyon na isinasaalang-alang ay maaaring ituring na isang espesyal na kaso ng relasyon na ito. Gayunpaman, ang kahalagahan ng pag-highlight ng mga tiyak na katangian ng semantiko at karagdagang mga katangian para sa iba pang mga uri ng mga relasyon, dapat silang isaalang-alang nang nakapag-iisa kapag gumagawa ng mga diagram.

Tandaan 48

Kaugnay ng pagsasaalang-alang ng relasyong ito, angkop na alalahanin ang espesyal na terminong "pinagsama-sama", na nagsisilbing italaga teknikal na sistema binubuo ng mga nag-uugnay na bahagi o subsystem. Ang pagkakatulad na ito ay hindi sinasadya at maaaring magsilbi upang mas malinaw na maunawaan ang kakanyahan ng relasyon na isinasaalang-alang.

Tandaan 49

Bilang ehersisyo para pagsama-samahin ang materyal na tinalakay, maaari mong subukang bumuo ng mga class diagram, o hindi bababa sa mga fragment ng mga ito, para sa mga karaniwang library ng klase na MFC (Microsoft) at VCL (Borland/Inprise) gamit ang graphical na notation ng UML na wika. Maaaring ipagpalagay na sa malapit na hinaharap, ang mga reference manual para sa kaukulang programming environment ay maglalaman lamang ng mga class diagram, at marahil sa iba pa.

10.4. UML DIAGRAM

10.4.1. Mga uri ng visual Mga diagram ng UML

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 iba't ibang aspeto mga sistema. Halimbawa, ipinapakita ng cooperative diagram kung paano dapat makipag-ugnayan ang mga bagay upang maipatupad ang ilang functionality ng isang system. Ang bawat diagram ay may sariling layunin.

10.4.2. Gamitin ang Case Diagram

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 na tumatanggap o nagpapadala ng impormasyon sa isang partikular na system. Ang isang halimbawa ng use case diagram para sa isang automated teller machine (ATM) ay ipinapakita sa Fig. 10.1.

kanin. 10.1. Gamitin ang Case Diagram

Ang diagram ay kumakatawan sa 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 ang mga function na ginagampanan ng system, at ang mga aktor ay ang mga stakeholder na may kaugnayan sa system na nilikha. Ipinapakita ng mga diagram kung sinong mga aktor ang nagpasimula ng mga use case. Ipinapakita rin ng mga ito kapag nakatanggap ang isang aktor ng impormasyon mula sa isang 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", "Magdeposito ng pera sa account", "Ipakita ang balanse", "Baguhin" numero ng pagkakakilanlan", "Magbayad". Maaaring simulan ng empleyado ng bangko ang use case na "Change Identification Number." Mula sa use case na "Make Payment" mayroong isang arrow papunta sa Credit System. Ang mga aktor ay maaaring at mga panlabas na sistema, sa kasong ito, ang Credit system ay eksaktong ipinapakita bilang isang aktor - ito ay panlabas sa ATM system. Ang isang arrow na tumuturo mula sa isang use case patungo sa isang aktor ay nagpapahiwatig na ang use case ay nagbibigay ng ilang impormasyon sa aktor. Sa kasong ito, ang Make Payment use case ay nagbibigay sa Credit System ng impormasyon tungkol sa pagbabayad sa credit card.

Ang mga use case diagram ay maaaring magbigay ng kaunting impormasyon tungkol sa system. Ang ganitong uri ng diagram ay naglalarawan sa pangkalahatang pag-andar ng system. Maaaring tumingin sa mga use case diagram ang mga user, project manager, analyst, developer, quality assurance specialist, at sinumang interesado sa system upang 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 ilan posibleng mga sequence: pag-withdraw ng pera, pagtatangkang mag-withdraw ng pera kapag walang sapat na pera sa account, subukang 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.

Larawan 10.2. Sequence diagram para sa kliyente ni Joe na nag-withdraw ng $20 mula sa kanyang account

Ang tuktok ng diagram ay nagpapakita ng lahat ng mga aktor at bagay na kinakailangan ng system upang maisagawa ang kaso ng paggamit ng Withdraw Money. 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. Dapat ding tandaan na ang sequence diagram ay nagpapakita ng mga bagay, hindi mga klase. Ang mga klase ay mga uri ng mga bagay. Ang mga bagay ay kongkreto; sa halip na klase Kliyente Ang sequence diagram ay kumakatawan sa isang partikular na customer, si Joe.

Magsisimula ang use case kapag ipinasok ng customer ang kanilang card sa reader - ipinapakita ang bagay na ito sa rectangle sa tuktok 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 laban sa object ng Joe Account at nalaman na ito ay tama. Pagkatapos ay ipinakita ng screen kay Joe ang isang menu na mapagpipilian, at pipiliin niya ang "Mag-withdraw ng Pera." Ang screen ay nagtatanong kung magkano ang gusto niyang i-withdraw, at si Joe ay pumasok ng $20. Ang screen ay nag-withdraw ng pera mula sa account. Sa paggawa nito, sinisimulan nito ang isang serye ng mga prosesong isinagawa ng object na "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. Pagkatapos ay inutusan ang cash register na "mag-isyu ng tseke at $20 na cash." Sa wakas, ang parehong bagay na "Joe's account" ay nagtuturo sa card reader na ibalik ang card.

Kaya, inilalarawan ng sequence diagram na ito ang pagkakasunud-sunod ng mga aksyon na nagpapatupad ng use case na "Mag-withdraw ng pera mula sa account" gamit ang partikular na halimbawa ng pag-withdraw ng kliyente ni Joe 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 kailangang gawin at ang kanilang mga operasyon. Mauunawaan ng mga dalubhasa sa pagkontrol sa kalidad ang mga detalye ng proseso at maaaring bumuo ng mga pagsubok upang i-verify ang mga ito. Kaya, ang mga sequence diagram ay kapaki-pakinabang para sa lahat ng kasangkot sa isang proyekto.

10.4.4. Mga tsart ng kooperatiba

Ang mga diagram ng kooperatiba ay nagpapakita ng parehong impormasyon tulad ng mga diagram ng pagkakasunud-sunod. Gayunpaman, ginagawa nila ito nang iba at may iba pang mga layunin. Ipinapakita sa Fig. 10.2 sequence diagram ay ipinapakita sa Fig. 10.3 sa anyo ng isang cooperative diagram.

Tulad ng dati, ang mga bagay ay inilalarawan bilang mga parihaba, at mga character bilang mga figure. Habang ang isang sequence diagram ay nagpapakita ng pakikipag-ugnayan sa pagitan ng mga aktor at mga bagay sa paglipas ng panahon, ang isang cooperative diagram ay nagpapakita ng walang kaugnayan sa paglipas ng panahon. Kaya, makikita mo na ang card reader ay nagtuturo sa "Joe's account" na buksan, at "Joe's account" ang dahilan upang ibalik ng device ang card sa may-ari. Ang mga direktang nakikipag-ugnayan na mga bagay ay konektado sa pamamagitan ng mga linya. Kung, halimbawa, ang card reader ay direktang nakikipag-ugnayan sa screen ng ATM, dapat na 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 ibang layunin. Ang mga espesyalista sa pagtiyak ng kalidad at mga arkitekto ng system ay mauunawaan ang pamamahagi ng mga proseso sa pagitan ng mga bagay. 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 system ay masyadong nakadepende sa isang sentral na entity 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. Class Diagram

Ang mga class diagram ay sumasalamin sa mga pakikipag-ugnayan sa pagitan ng mga klase sa isang system. Halimbawa, ang "account ni Joe" ay isang bagay. Ang uri ng naturang bagay ay maaaring ituring na isang account sa pangkalahatan, ibig sabihin, ang "Account" ay isang klase. Naglalaman ang mga klase ng data at pag-uugali (mga aksyon) na nakakaapekto sa data na iyon. Kaya, ang klase ng Account ay naglalaman ng numero ng pagkakakilanlan ng kliyente at ang mga pagkilos na nagpapatunay nito. Sa isang class diagram, isang klase ang nilikha para sa bawat uri ng object mula sa Sequence Diagrams o Cooperative Diagrams. Ang class diagram para sa Withdraw money use case ay ipinapakita sa Fig. 10.4.

Ipinapakita ng diagram ang mga ugnayan sa pagitan ng mga klase na nagpapatupad ng kaso ng paggamit ng Withdraw Money. Mayroong apat na klase na kasangkot sa prosesong ito: Card Reader(card reader), Account, ATM (ATM screen) at Cash Dispenser. Ang bawat klase sa isang class diagram ay inilalarawan bilang isang parihaba na nahahati sa tatlong bahagi. Ang unang bahagi ay nagpapahiwatig ng 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: Account Number, PIN, at Balanse. Ang huling bahagi ay naglalaman ng mga operasyon ng klase, na sumasalamin nito pag-uugali(mga aksyon na ginawa ng klase). Ang mga linyang nagkokonekta sa mga klase ay nagpapakita ng mga pakikipag-ugnayan sa pagitan ng mga klase.

kanin. 10.4. Class diagram

Gumagamit ang mga developer ng mga class diagram upang aktwal na lumikha ng mga klase. Ang mga tool tulad ng Rose ay bumubuo ng isang core ng class code na pinupunan ng mga programmer ng mga detalye sa wikang kanilang pinili. Gamit ang mga diagram na ito, maipapakita ng mga analyst ang mga detalye ng isang system at mauunawaan ng mga arkitekto ang disenyo nito. 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. Makakatulong din ang diagram na 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 isang 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 nagpapakita ng pag-uugali ng isang bagay. Kaya, ang isang bank account ay maaaring magkaroon ng ilang magkakaibang estado. Maaaring ito ay bukas, sarado, o na-overdraw. 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 Figure 10.5 ay nagpapakita ng 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 kliyente kaganapan, ito ay mga pangyayari na nagdudulot ng paglipat mula sa isang estado patungo sa isa pa.

Kapag ang isang kliyente ay nag-withdraw ng pera mula sa buksan ang account, ang account ay maaaring mapunta sa "Over-Credit" na estado. Nangyayari lamang ito kung ang balanse ng account ay mas mababa sa zero, na makikita ng kundisyon [ negatibong balanse] sa aming diagram. Nakapaloob sa mga square bracket kundisyon tinutukoy kung kailan maaaring mangyari o hindi maaaring mangyari ang isang paglipat mula sa isang estado patungo sa isa pa.

Mayroong dalawang espesyal na estado sa diagram - inisyal At 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 kaagad bago ang pagkawasak nito. Maaaring magkaroon ng isa at isang paunang estado lamang sa isang diagram ng estado. Kasabay nito, maaaring magkaroon ng maraming huling estado hangga't kailangan mo, o maaaring wala.

Kapag ang isang bagay ay nasa isang partikular na estado, ang ilang mga proseso ay maaaring isagawa. Sa aming halimbawa, kung lumampas ang kredito, isang kaukulang mensahe ang ipapadala sa kliyente. Tinatawag ang mga prosesong nagaganap kapag ang isang bagay ay nasa isang tiyak na estado mga aksyon.

Ang mga statechart ay hindi kailangang likhain para sa bawat klase, ginagamit lamang ang mga ito sa napakakomplikadong mga kaso. Kung ang isang bagay ng isang klase ay maaaring umiral sa maraming estado at iba ang kilos sa bawat estado, malamang na kakailanganin nito ang gayong diagram. Gayunpaman, maraming mga proyekto ang hindi gumagamit ng mga ito. Kung ang mga diagram ng estado ay binuo, maaaring gamitin ng mga developer ang mga ito kapag lumilikha ng mga klase.

Pangunahing kailangan ang mga statechart para sa dokumentasyon.

10.4.7. Mga diagram ng bahagi

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

Sa Fig. Ipinapakita ng Figure 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 extension file. CPP, upang ang bawat klase ay ma-convert sa sarili nitong sariling mga sangkap sa diagram. Ang napiling madilim na bahagi ay tinatawag detalye ng pakete at tumutugma sa ATM class body file sa C++ (file na may extension . CPP). Ang isang hindi napiling bahagi ay tinatawag ding detalye ng package, ngunit tumutugma sa isang C++ na file ng header ng klase ng wika (file na may extension na .H). Bahagi ng ATM. Ang EXE ay isang detalye ng gawain at kumakatawan sa daloy ng pagproseso ng impormasyon. Sa kasong ito, ang processing thread ay ang executable program.

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

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

kanin. 10.6. Component diagram

10.4.8. Mga diagram ng pagkakalagay

Ang mga diagram ng layout ay nagpapakita ng pisikal na layout iba't ibang sangkap mga sistema sa 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 placement diagram para sa ATM system ay ipinapakita sa Fig. 10.7.

Mula sa diagram na ito maaari mong malaman ang tungkol sa pisikal na layout ng system. Ang mga programa ng kliyente ng ATM ay tatakbo sa maraming lokasyon sa maraming site. Sa pamamagitan ng mga saradong network Makikipag-ugnayan ang mga kliyente sa regional ATM server. 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, ipinapakita ng diagram na ito ang pisikal na layout ng system. Halimbawa, ang aming ATM system ay sumusunod sa isang three-tier na arkitektura, kasama ang database sa unang layer, ang regional server sa pangalawa, at ang client sa pangatlo.

10.7. Diagram ng pagkakalagay

Ang layout diagram ay ginagamit ng project manager, user, system architect, at operations personnel para linawin ang pisikal na layout ng 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. Magagawang planuhin ng mga tauhan ng operasyon ang gawain sa pag-install ng system.