Pagmomodelo sa UML. Mga diagram ng pagpapatupad

          Ang Unified Modeling Language (UML) ay isang wika para sa pagtukoy, pagsasalarawan, pagbuo at pagdodokumento ng mga software system, gayundin sa mga modelo ng negosyo at iba pang mga non-software system. Ang UML ay isang kumbinasyon ng mga diskarte sa engineering na dati nang matagumpay na ginamit upang magmodelo ng malalaki at kumplikadong mga sistema

        Ipinakikita ito ng mga tagalikha ng UML bilang isang wika para sa pagtukoy, pagkatawan, pagdidisenyo at pagdodokumento ng mga software system, mga sistema ng negosyo at iba pang mga sistema ng iba't ibang uri. Tinutukoy ng UML ang isang notasyon at isang metamodel. Ang notasyon ay isang koleksyon ng mga graphical na bagay na ginagamit sa mga modelo; ito ang syntax ng modelling language.

        Ang UML ay nagbibigay ng mga tool na nagpapahayag para sa paglikha ng mga visual na modelo na:

• ay pantay na nauunawaan ng lahat ng mga developer na kasangkot sa proyekto;
• ay isang paraan ng komunikasyon sa loob ng proyekto.

          Pinag-isang Modeling Language (UML):

• ay hindi nakadepende sa object-oriented (OO) programming language;
• hindi nakadepende sa ginamit na pamamaraan ng pagbuo ng proyekto;
• maaaring suportahan ang anumang OO programming language.

          Ang UML ay bukas at may mga tool para sa pagpapalawak ng pangunahing core. Maaaring gamitin ang UML upang makahulugang ilarawan ang mga klase, bagay, at bahagi sa iba't ibang paksa, kadalasang ibang-iba sa isa't isa.

Mga Diagram ng UML

        Ang Rational Rose ay nagbibigay ng mga sumusunod na uri ng mga diagram na magagamit ng taga-disenyo ng system, ang sunud-sunod na paglikha nito ay nagbibigay-daan sa iyong makakuha ng kumpletong larawan ng buong dinisenyong system at ang mga indibidwal na bahagi nito:

• Gamitin ang diagram ng kaso;
• Deployment diagram (topology diagram);
• diagram ng statechart;
• Diagram ng pakikipag-ugnayan; Diagram ng aktibidad;
• Sequence diagram;
• Diagram ng pakikipagtulungan;
• Diagram ng klase;
• Component diagram (component diagram);
• Mga diagram ng pag-uugali;
• Diagram ng aktibidad;
• Mga diagram ng pagpapatupad;

        Ang bawat isa sa mga diagram na ito ay tumutukoy sa iba't ibang ideya tungkol sa modelo ng system. Kasabay nito, ang use case diagram ay kumakatawan sa isang konseptwal na modelo ng system, na siyang panimulang punto para sa pagbuo ng lahat ng iba pang mga diagram. Ang class diagram ay isang lohikal na modelo na sumasalamin sa mga static na aspeto ng istrukturang disenyo ng isang system, at ang mga diagram ng pag-uugali, na mga uri din ng isang lohikal na modelo, ay sumasalamin sa mga dinamikong aspeto ng paggana nito. Ang mga diagram ng pagpapatupad ay nagsisilbing kumakatawan sa mga bahagi ng isang sistema at tumutukoy sa pisikal na modelo nito.

        Sa mga diagram na nakalista sa itaas, ang ilan ay nagsisilbing magtalaga ng dalawa o higit pang subspecies. Ang mga sumusunod na diagram ay ginagamit bilang mga independiyenteng representasyon: mga kaso ng paggamit, mga klase, estado, aktibidad, pagkakasunud-sunod, pakikipagtulungan, mga bahagi at pag-deploy.

        Para sa mga diagram ng UML, mayroong tatlong uri ng mga visual na simbolo na mahalaga sa mga tuntunin ng impormasyong nilalaman ng mga ito:

• mga komunikasyon, na kinakatawan ng iba't ibang linya sa eroplano;
• text, na nakapaloob sa loob ng mga hangganan ng mga indibidwal na geometric na hugis;
• mga graphic na simbolo, na inilalarawan malapit sa mga visual na elemento ng mga diagram.

        Kapag graphical na naglalarawan ng mga diagram, inirerekomendang sumunod sa mga sumusunod na panuntunan:

• ang bawat diagram ay dapat na isang kumpletong representasyon ng ilang fragment ng namodelong lugar ng paksa;
• ang mga modelong entity na ipinakita sa diagram ay dapat na nasa parehong antas ng konsepto;
• lahat ng impormasyon tungkol sa mga entidad ay dapat na malinaw na ipinakita sa diagram;
• ang mga diagram ay hindi dapat maglaman ng magkasalungat na impormasyon;
• ang mga diagram ay hindi dapat ma-overload ng impormasyon sa teksto;
• ang bawat diagram ay dapat na sapat sa sarili para sa tamang interpretasyon ng lahat ng elemento nito;
• ang bilang ng mga uri ng diagram na kinakailangan upang ilarawan ang isang partikular na sistema ay hindi mahigpit na naayos at tinutukoy ng developer;
• ang mga modelo ng system ay dapat maglaman lamang ng mga elementong tinukoy sa notasyon ng UML.

Mga nilalang sa UML

        Mayroong apat na uri ng mga entity na tinukoy sa UML: istruktura, asal, pagpapangkat at anotasyon. Ang mga entity ay ang pangunahing object-oriented na elemento ng wika kung saan nilikha ang mga modelo.

        Mga istrukturang entidad ay mga pangngalan sa mga modelong UML. Karaniwan, kinakatawan nila ang mga static na bahagi ng modelo, na tumutugma sa mga konsepto o pisikal na elemento ng system. Ang mga halimbawa ng structural entity ay "class", "interface", "collaboration", "use case", "component", "node", "actor".

        Mga Entidad sa Pag-uugali ay mga dynamic na bahagi ng modelo ng UML. Ito ay mga pandiwa na naglalarawan sa pag-uugali ng modelo sa oras at espasyo. Mayroong dalawang pangunahing uri ng mga entidad sa pag-uugali:

• ang pakikipag-ugnayan ay pag-uugali, ang kakanyahan nito ay ang pagpapalitan ng mga mensahe sa pagitan ng mga bagay sa loob ng isang tiyak na konteksto upang makamit ang isang tiyak na layunin;
• automaton - isang algorithm ng pag-uugali na tumutukoy sa isang pagkakasunud-sunod ng mga estado kung saan dumadaan ang isang bagay o pakikipag-ugnayan bilang tugon sa iba't ibang mga kaganapan.

        Pagpapangkat ng mga Entidad ay ang mga bahagi ng pag-aayos ng modelo ng UML. Ito ay mga bloke kung saan maaaring mabulok ang modelo. Ang ganitong pangunahing entity ay umiiral sa isang kopya - ito ay isang pakete.

        Ang mga package ay isang unibersal na mekanismo para sa pag-aayos ng mga elemento sa mga pangkat. Ang istruktura, pag-uugali, at iba pang mga entidad ng pagpapangkat ay maaaring ilagay sa isang pakete. Hindi tulad ng mga sangkap na aktwal na umiiral habang tumatakbo ang programa, ang mga pakete ay puro konseptwal sa kalikasan, iyon ay, umiiral lamang ang mga ito sa panahon ng proseso ng pag-unlad.

        Mga Entidad ng Anotasyon- Ito ang mga bahaging nagpapaliwanag ng modelo ng UML: mga komento para sa karagdagang paglalarawan, paglilinaw o mga komento sa anumang elemento ng modelo. Mayroon lamang isang pangunahing uri ng elemento ng anotasyon - isang tala. Ang mga tala ay ginagamit upang magbigay ng mga diagram na may mga komento o paghihigpit, na ipinahayag sa impormal o pormal na teksto.

Mga relasyon sa UML

        Ang mga sumusunod na uri ng mga relasyon ay tinukoy sa wikang UML: pagtitiwala, pagsasamahan, paglalahat at pagpapatupad. Ang mga ugnayang ito ay ang pangunahing mga konstruksyon ng pagkonekta ng UML at ginagamit din bilang mga entity upang bumuo ng mga modelo.

        Dependency- ito ay isang semantikong relasyon sa pagitan ng dalawang entity, kung saan ang pagbabago sa isa sa kanila, independiyente, ay maaaring makaapekto sa semantika ng isa pa, umaasa.

        Samahan- isang istrukturang relasyon na naglalarawan ng isang set ng semantiko o lohikal na koneksyon sa pagitan ng mga bagay.

        Paglalahat ay isang relasyon kung saan ang isang espesyal na bagay ng elemento (kaapu-apuhan) ay maaaring palitan para sa isang pangkaraniwang bagay na elemento (ninuno). Kasabay nito, alinsunod sa mga prinsipyo ng object-oriented programming, ang isang inapo (anak) ay nagmamana ng istraktura at pag-uugali ng kanyang ninuno (magulang).

        Realization ay isang semantikong relasyon sa pagitan ng mga classifier kung saan ang isang classifier ay tumutukoy sa isang obligasyon at ang isa ay ginagarantiyahan ang katuparan nito. Ang mga relasyon sa pagpapatupad ay nangyayari sa dalawang kaso:

• sa pagitan ng mga interface at ng mga klase o mga bahagi na nagpapatupad ng mga ito;
• sa pagitan ng mga nauna at ang mga kooperasyong nagpapatupad ng mga ito.

Mga Karaniwang Mekanismo ng UML

        Upang tumpak na ilarawan ang isang system sa UML, ginagamit ang tinatawag na mga pangkalahatang mekanismo:

• mga pagtutukoy;
• mga karagdagan (adornment);
• karaniwang mga dibisyon;
• mga extension (mga mekanismo ng pagpapalawak).

        Ang UML ay hindi lamang isang graphical na wika. Sa likod ng bawat graphic na elemento ay mayroong notasyon nito pagtutukoy, na naglalaman ng representasyong tekstuwal ng kaukulang pagbuo ng wika. Halimbawa, ang isang icon para sa isang klase ay may isang detalye na naglalarawan sa mga katangian, pagpapatakbo, at pag-uugali nito, bagama't biswal, sa isang diagram, ang icon ay madalas na nagpapakita lamang ng maliit na bahagi ng impormasyong ito. Bukod dito, ang modelo ay maaaring maglaman ng ibang representasyon ng klase na ito, na sumasalamin sa ganap na magkakaibang mga aspeto nito, ngunit, gayunpaman, naaayon sa detalye. Kaya, ang UML graphical notation ay ginagamit upang mailarawan ang system, at gamit ang mga pagtutukoy upang ilarawan ang mga detalye nito.

        Halos bawat elemento ng UML ay may natatanging graphical na representasyon na nagbibigay ng visual na representasyon ng pinakamahahalagang katangian nito. Ang notasyon ng entity na "class" ay naglalaman ng pangalan, mga katangian, at pagpapatakbo nito. Ang detalye ng klase ay maaaring maglaman ng iba pang mga detalye, tulad ng visibility ng mga katangian at pagpapatakbo, komento, o isang indikasyon na abstract ang klase. Marami sa mga detalyeng ito ay maaaring makita bilang mga graphics o teksto. mga karagdagan sa isang karaniwang parihaba na kumakatawan sa klase.

        Kapag nagmomodelo ng object-oriented system, mayroong isang tiyak na dibisyon kinatawan ng mga entity.

        Una, mayroong paghahati sa mga klase at bagay. Ang isang klase ay isang abstraction, at ang isang bagay ay isang kongkretong sagisag ng abstraction na iyon. Sa pagsasaalang-alang na ito, halos lahat ng mga konstruksyon ng wika ay nailalarawan sa duality ng klase/bagay. Kaya, may mga precedent at mga pagkakataon ng mga nauna, mga bahagi at mga pagkakataon ng mga bahagi, mga node at mga pagkakataon ng mga node. Sa isang graphical na representasyon, kaugalian na gumamit ng parehong simbolo para sa isang bagay tulad ng para sa isang klase, at salungguhitan ang pangalan.

        Pangalawa, mayroong isang dibisyon sa isang interface at ang pagpapatupad nito. Ang isang interface ay nagdedeklara ng mga pangako, at ang isang pagpapatupad ay kumakatawan sa konkretong pagpapatupad ng mga pangakong iyon at tinitiyak na ang mga ipinahayag na semantika ay eksaktong sinusunod. Dahil dito, halos lahat ng mga konstruksyon ng UML ay nailalarawan sa pamamagitan ng isang interface/implementation duality. Halimbawa, ang mga nauna ay ipinapatupad ng mga pakikipagtulungan, at ang mga pagpapatakbo ay ipinapatupad sa pamamagitan ng mga pamamaraan.

        Ang UML ay isang bukas na wika, ibig sabihin, pinapayagan nito ang mga kontroladong extension na ipakita ang mga tampok ng mga modelo ng domain.

        Ang mga mekanismo ng extension ng UML ay kinabibilangan ng:

• stereotypes (stereotype) - palawakin ang bokabularyo ng UML, na nagpapahintulot sa iyo na lumikha ng mga bago batay sa umiiral na mga elemento ng wika, na nakatuon sa paglutas ng isang partikular na problema;
• mga naka-tag na halaga - pahabain ang mga katangian ng mga pangunahing konstruksyon ng UML, na nagpapahintulot sa karagdagang impormasyon na maisama sa detalye ng elemento;
• mga paghihigpit (constraints) - palawakin ang mga semantika ng mga konstruksyon ng UML, na nagbibigay-daan sa iyong lumikha ng bago at kanselahin ang mga umiiral na panuntunan.

        Magkasama, binibigyang-daan ka ng tatlong mekanismo ng extension ng wika na ito na baguhin ito alinsunod sa mga pangangailangan ng proyekto o mga tampok ng teknolohiya sa pag-unlad.

Gamitin ang diagram ng case

        Nagbibigay-daan sa iyo ang ganitong uri ng diagram na lumikha ng listahan ng mga pagpapatakbo na ginagawa ng system. Kadalasan ang ganitong uri ng diagram ay tinatawag na isang function diagram, dahil batay sa isang hanay ng mga naturang diagram, isang listahan ng mga kinakailangan para sa system ay nilikha at ang hanay ng mga function na ginagampanan ng system ay tinutukoy.

Figure - 1. Use case diagram

        Inilalarawan ng mga use case diagram ang functionality ng isang system o kung ano ang dapat gawin ng system. Ang pagbuo ng diagram ay may mga sumusunod na layunin:

• tukuyin ang pangkalahatang mga hangganan at konteksto ng namodelong lugar ng paksa;
• bumalangkas ng mga pangkalahatang kinakailangan para sa functional na pag-uugali ng dinisenyong sistema;
• bumuo ng isang paunang konseptwal na modelo ng sistema para sa kasunod na pagdedetalye nito sa anyo ng lohikal at pisikal na mga modelo;
• maghanda ng paunang dokumentasyon para sa pakikipag-ugnayan ng mga developer ng system sa mga customer at user nito.

        Ang esensya ng use case diagram ay ang mga sumusunod. Ang system na idinisenyo ay kinakatawan bilang isang hanay ng mga entity o aktor na nakikipag-ugnayan sa system sa pamamagitan ng 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. Use case nagsisilbing paglalarawan sa mga serbisyong ibinibigay ng system sa aktor.

        Ang layunin ng isang use case ay upang tukuyin ang isang kumpletong aspeto o fragment ng pag-uugali ng ilang entity nang hindi inilalantad ang panloob na istraktura nito. Ang nasabing entity ay maaaring isang sistema o anumang elemento ng modelo na may sariling pag-uugali.

        Ang bawat use case ay tumutugma sa isang hiwalay na serbisyo na ibinibigay ng modelong entity sa kahilingan ng aktor, ibig sabihin, tinutukoy nito kung paano gagamitin ang entity na ito. Ang isang serbisyo na pinasimulan sa kahilingan ng isang aktor ay isang kumpleto, hindi mahahati na pagkakasunud-sunod ng mga aksyon. Nangangahulugan ito na pagkatapos na maproseso ng system ang isang kahilingan, dapat itong bumalik sa orihinal nitong estado upang maging handa na iproseso ang mga kasunod na kahilingan

          Maaaring gamitin ang mga kaso ng paggamit upang tukuyin ang mga panlabas na kinakailangan para sa system na idinisenyo, at upang tukuyin ang functional na gawi ng isang umiiral na system. Ang hanay ng mga kaso ng paggamit sa kabuuan ay dapat tukuyin ang lahat ng posibleng aspeto ng inaasahang pag-uugali ng system. Bilang karagdagan, ang mga kaso ng paggamit ay tahasang nagtatakda ng mga kinakailangan na tumutukoy kung paano dapat makipag-ugnayan ang mga aktor sa system upang maayos na mapatakbo ang mga serbisyong ibinigay. Para sa kaginhawahan, maraming mga kaso ng paggamit ang maaaring ituring bilang isang hiwalay na pakete.

        Maaaring kabilang sa mga halimbawa ng mga kaso ng paggamit ang mga sumusunod na pagkilos: pagsuri sa katayuan ng kasalukuyang account ng kliyente, paglalagay ng order para sa pagbili ng mga kalakal, pagkuha ng karagdagang impormasyon tungkol sa pagiging credit ng kliyente, pagpapakita ng graphical na form sa screen ng monitor at iba pa mga aksyon.

diagram ng klase

        Ang pangunahing lugar sa object-oriented na programming ay ang pagbuo ng isang lohikal na modelo ng system sa anyo ng isang class diagram. 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 object at subsystem, pati na rin ilarawan ang kanilang panloob na istraktura at mga uri ng mga relasyon.

Figure - 2. Class diagram

        Nagbibigay-daan sa iyo ang mga icon ng diagram na magpakita ng isang kumplikadong hierarchy ng mga system, mga relasyon sa pagitan ng mga klase (Mga Klase) at mga interface (Mga Interface). Ang ganitong uri ng diagram ay kabaligtaran sa nilalaman ng Collaboration diagram, na nagpapakita ng mga object ng system. Pinapayagan ka ng Rational Rose na lumikha ng mga klase gamit ang ganitong uri ng diagram sa iba't ibang mga notasyon. katulad ng isang ulap. Kaya, ang isang klase ay isang template lamang ayon sa kung saan ang isang partikular na bagay ay malilikha sa hinaharap.

        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. Ang isang class diagram ay maaari ding maglaman ng mga interface, package, relasyon, at maging mga indibidwal na pagkakataon gaya ng mga bagay at relasyon.

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

diagram ng statechart

        Ang bawat state diagram sa UML ay naglalarawan sa lahat ng posibleng estado ng isang instance ng isang partikular na klase at posibleng mga pagkakasunud-sunod ng mga transition nito mula sa isang estado patungo sa isa pa, ibig sabihin, imodelo nito ang lahat ng pagbabago sa mga estado ng isang object bilang tugon nito sa external mga impluwensya.

        Ang mga diagram ng estado ay kadalasang ginagamit upang ilarawan ang pag-uugali ng mga indibidwal na bagay, ngunit maaari ding gamitin upang tukuyin ang paggana ng iba pang mga bahagi ng modelo, gaya ng mga kaso ng paggamit, aktor, subsystem, operasyon, at pamamaraan.

Figure - 2. State diagram

        Ang state diagram ay isang espesyal na uri ng graph na kumakatawan sa isang partikular na automat. Ang mga vertice ng graph ay ang mga posibleng estado ng makina, na inilalarawan ng kaukulang mga graphic na simbolo, at ang mga arko ay nagpapahiwatig ng mga paglipat nito mula sa estado patungo sa estado. Maaaring i-nested ang mga diagram ng estado upang magbigay ng mas detalyadong representasyon ng mga indibidwal na elemento ng modelo.

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

        Ang tagal ng system na nasa alinman sa mga posibleng estado ay makabuluhang lumampas sa oras na ginugol sa paglipat mula sa isang estado patungo sa isa pa. Ipinapalagay na sa limitasyon ang oras ng paglipat ay maaaring katumbas ng zero (maliban kung tinukoy), iyon ay, ang pagbabago sa mga estado ng bagay ay maaaring mangyari kaagad.

        Ang pag-uugali ng automat ay namodelo bilang sunud-sunod na paggalaw sa kahabaan ng graph mula sa vertex hanggang sa vertex, na isinasaalang-alang ang oryentasyon ng mga arko na nagkokonekta sa kanila.

        Ang mga sumusunod na mandatoryong kundisyon ay dapat matugunan para sa makina:

• ang estado kung saan maaaring pumunta ang isang bagay ay tinutukoy lamang ng kasalukuyang estado nito at hindi nakadepende sa nakaraang kasaysayan nito;
• Sa bawat sandali ng oras, ang automat ay maaaring nasa isa lamang sa mga estado nito. Kasabay nito, ang automat ay maaaring manatili sa isang hiwalay na estado hangga't ninanais kung walang mga kaganapan na magaganap;
• ang oras na ang makina ay nasa isang estado o iba pa, pati na rin ang oras na kinakailangan upang makamit ang isang estado o iba pa, ay hindi tinukoy sa anumang paraan;
• ang bilang ng mga estado ng automat ay dapat na may hangganan at lahat ng mga ito ay dapat na tiyak na tinukoy. Ang mga indibidwal na pseudo-state ay maaaring walang mga detalye (mga panimulang at panghuling estado). Sa kasong ito, ang kanilang layunin at semantika ay ganap na tinutukoy mula sa konteksto ng modelo at ang diagram ng estado na isinasaalang-alang;
• Ang automaton graph ay hindi dapat maglaman ng mga nakahiwalay na estado at mga transition. Para sa bawat estado, maliban sa paunang isa, ang isang nakaraang estado ay dapat matukoy, at ang bawat paglipat ay dapat magkonekta ng dalawang estado ng makina;
• ang automat ay hindi dapat maglaman ng magkasalungat na mga transition, kapag ang bagay ay maaaring sabay na lumipat sa dalawa o higit pang mga kasunod na estado (maliban sa kaso ng parallel sub-automata). Sa UML, ang pag-aalis ng salungatan ay posible sa pamamagitan ng pagpapakilala ng mga kondisyon ng bantay.

estado ay pangunahing hindi lamang sa metamodel ng wika ng UML, kundi pati na rin sa pagsusuri ng mga sistemang inilapat. Ang buong konsepto ng isang dinamikong sistema ay batay sa konsepto ng estado. Ang mga semantika ng estado sa wikang UML ay may ilang partikular na tampok.

        Sa UML, ang isang estado ay isang abstract metaclass na ginagamit upang magmodelo ng isang partikular na sitwasyon kung saan natutugunan ang ilang partikular na kundisyon. Maaaring tukuyin ang estado bilang isang hanay ng mga partikular na halaga ng katangian ng klase o object. Ang mga pagbabago sa mga indibidwal na halaga ng katangian ay magpapakita ng mga pagbabago sa estado ng klase o bagay na ginagaya.

Diagram ng aktibidad

        Kapag nagmomodelo ng gawi ng isang system na idinisenyo o sinusuri, ito ay nagiging kinakailangan hindi lamang upang ipakita ang proseso ng pagbabago ng mga estado nito, kundi pati na rin upang i-detalye ang mga tampok ng algorithmic at lohikal na pagpapatupad ng mga pagpapatakbo na ginagawa ng system.

        Sa katunayan, ang ganitong uri ng diagram ay maaari ding gamitin upang ipakita ang mga estado ng modelong object, gayunpaman, ang pangunahing layunin ng Activity diagram ay upang ipakita ang mga proseso ng negosyo ng object. Ang ganitong uri ng diagram ay nagbibigay-daan sa iyo upang ipakita hindi lamang ang pagkakasunud-sunod ng mga proseso, kundi pati na rin ang sumasanga at kahit na pag-synchronize ng mga proseso.

        Nagbibigay-daan sa iyo ang ganitong uri ng diagram na magdisenyo ng mga algorithm para sa pag-uugali ng mga bagay sa anumang kumplikado, kabilang ang maaaring magamit upang gumuhit ng mga block diagram.

        Upang imodelo ang proseso ng pagsasagawa ng mga operasyon sa wikang UML, ginagamit ang mga activity diagram. Ang graphical na notation na ginamit sa mga ito ay sa maraming paraan ay katulad ng notation ng isang state diagram, dahil ang mga diagram na ito ay naglalaman din ng mga simbolo ng estado at transition. Ang bawat estado sa isang diagram ng aktibidad ay tumutugma sa pagkumpleto ng ilang elementarya na operasyon, at ang paglipat sa susunod na estado ay nangyayari lamang kapag natapos ang operasyong ito.

        Kaya, ang mga diagram ng aktibidad ay maaaring ituring na isang espesyal na kaso ng mga diagram ng estado. Nagbibigay-daan sa iyo ang mga ito na ipatupad sa wikang UML ang mga tampok ng procedural at synchronous na kontrol dahil sa pagkumpleto ng mga panloob na aktibidad at pagkilos. Ang pangunahing paggamit ng mga diagram ng aktibidad ay upang mailarawan ang mga tampok ng pagpapatupad ng mga pagpapatakbo ng klase, kapag kinakailangan upang ipakita ang mga algorithm para sa kanilang pagpapatupad.

        Sa konteksto ng wikang UML aktibidad ay isang hanay ng mga indibidwal na kalkulasyon na ginagawa ng isang automat, na humahantong sa ilang resulta o aksyon. Ipinapakita ng diagram ng aktibidad ang lohika at pagkakasunud-sunod ng mga paglipat mula sa isang aktibidad patungo sa isa pa, at itinutuon ang atensyon ng analyst sa mga resulta. Ang resulta ng isang aktibidad ay maaaring magresulta sa pagbabago sa estado ng system o pagbabalik ng ilang halaga.

        Estado ng pagkilos ay isang espesyal na kaso ng isang estado na may ilang input na aksyon at hindi bababa sa isang paglipat na umaalis sa estado. Ang paglipat na ito ay tahasang ipinapalagay na ang input na pagkilos ay nakumpleto na. Ang estado ng pagkilos ay hindi maaaring magkaroon ng mga panloob na transition dahil ito ay elementarya. Ang isang karaniwang paggamit ng isang estado ng pagkilos ay ang pagmodelo ng isang hakbang sa pagpapatupad ng isang algorithm (pamamaraan) o kontrol ng daloy.

Sequence diagram

        Kapag isinasaalang-alang ang mga diagram ng estado at aktibidad, nabanggit na kahit na ang mga diagram na ito ay ginagamit upang tukuyin ang dynamics ng pag-uugali ng system, ang oras ay hindi tahasang naroroon sa mga ito. Ang temporal na aspeto ng pag-uugali ay maaaring maging makabuluhan kapag nagmomodelo ng mga kasabay na proseso na naglalarawan sa mga pakikipag-ugnayan ng mga bagay. Upang imodelo ang pakikipag-ugnayan ng mga bagay sa paglipas ng panahon, gumagamit ang UML ng mga sequence diagram.

        Lamang ang mga iyon mga bagay, na direktang kasangkot sa pakikipag-ugnayan. Ang susi sa sequence diagram ay ang dynamics kung paano nakikipag-ugnayan ang mga bagay sa paglipas ng panahon.

        Sa UML, may dalawang dimensyon ang sequence diagram. Ang una ay mula kaliwa hanggang kanan sa anyo ng mga patayong linya, na ang bawat isa ay naglalarawan ng linya ng buhay ng isang hiwalay na bagay na nakikilahok sa pakikipag-ugnayan. Ang bagay sa dulong kaliwa ng diagram ang siyang nagpasimula ng pakikipag-ugnayan. Sa kanan ay isa pang bagay na direktang nakikipag-ugnayan sa una. Kaya, ang lahat ng mga bagay sa isang sequence diagram ay bumubuo ng ilang pagkakasunud-sunod, na tinutukoy ng pagkakasunud-sunod o antas ng aktibidad ng mga bagay kapag nakikipag-ugnayan sa isa't isa.

        Sa graphically, ang bawat bagay ay inilalarawan bilang isang parihaba at matatagpuan sa itaas na bahagi ng linya ng buhay nito. Sa loob ng parihaba, isulat ang pangalan ng bagay at ang pangalan ng klase, na pinaghihiwalay ng colon. Sa kasong ito, ang buong tala ay binibigyang diin, na isang tanda ng bagay.

        Ang pangalawang dimensyon ng isang sequence diagram ay ang vertical time axis, na nakadirekta mula sa itaas hanggang sa ibaba. Ang pinakamataas na bahagi ng diagram ay tumutugma sa unang sandali ng oras. Ang mga pakikipag-ugnayan sa bagay ay ipinapatupad sa pamamagitan ng mga mensaheng ipinadala ng isang bagay patungo sa isa pa. Ang mga mensahe ay inilalarawan bilang mga pahalang na arrow na may pangalan ng mensahe, at ang kanilang pagkakasunud-sunod ay tinutukoy ng oras ng paglitaw. Ibig sabihin, ang mga mensaheng matatagpuan sa mas mataas sa sequence diagram ay sinisimulan bago ang mga nasa mas mababa. Ang sukat sa axis ng oras ay hindi ipinahiwatig, dahil ang sequence diagram ay nagmomodelo lamang ng temporal na pagkakasunud-sunod ng mga "naunang-mamaya" na pakikipag-ugnayan.

Diagram ng pakikipagtulungan

        Ang pangunahing tampok ng isang diagram ng pakikipagtulungan ay ang kakayahang graphical na kumakatawan hindi lamang sa pagkakasunud-sunod ng pakikipag-ugnayan, kundi pati na rin sa lahat ng istrukturang relasyon sa pagitan ng mga bagay na kalahok sa pakikipag-ugnayang ito.

Figure - 3. Cooperation diagram

        Binibigyang-daan ka ng ganitong uri ng diagram na ilarawan ang mga pakikipag-ugnayan ng mga bagay, na kumukuha mula sa pagkakasunud-sunod ng paghahatid ng mensahe. Ipinapakita ng ganitong uri ng diagram sa isang compact form ang lahat ng natanggap at ipinadalang mensahe ng isang partikular na bagay at ang mga uri ng mga mensaheng ito.

        Una sa lahat, inilalarawan ng diagram ng kooperasyon ang mga bagay na nakikilahok sa pakikipag-ugnayan sa anyo ng mga parihaba, na naglalaman ng pangalan ng bagay, klase nito at, posibleng, mga halaga ng katangian. Dagdag pa, tulad ng sa diagram ng klase, ang mga asosasyon sa pagitan ng mga bagay ay ipinahiwatig sa anyo ng iba't ibang linya ng pagkonekta. Sa kasong ito, maaari mong tahasang tukuyin ang mga pangalan ng asosasyon at ang mga tungkuling ginagampanan ng mga bagay sa asosasyong ito. Bilang karagdagan, ang mga dynamic na koneksyon - mga daloy ng mensahe - ay maaaring ilarawan. Ang mga ito ay kinakatawan din bilang mga linya ng pagkonekta sa pagitan ng mga bagay, kung saan mayroong isang arrow na nagpapahiwatig ng direksyon, pangalan ng mensahe at numero ng pagkakasunud-sunod sa pangkalahatang pagkakasunud-sunod ng pagsisimula ng mensahe.

        Hindi tulad ng isang sequence diagram, ang isang diagram ng pakikipagtulungan ay naglalarawan lamang ng mga ugnayan sa pagitan ng mga bagay na gumaganap ng mga partikular na tungkulin sa pakikipag-ugnayan. Hindi ipinapakita ng chart na ito ang oras bilang hiwalay na dimensyon. Samakatuwid, ang pagkakasunud-sunod ng mga pakikipag-ugnayan at parallel na daloy ay maaaring matukoy gamit ang mga numero ng pagkakasunud-sunod. Samakatuwid, kung kailangan mong tahasang tukuyin ang mga relasyon sa pagitan ng mga bagay sa real time, mas mainam na gawin ito sa isang sequence diagram.

        Konsepto pagtutulungan ay isa sa mga pangunahing konsepto sa wikang UML. Nagsisilbi itong magtalaga ng isang hanay ng mga bagay na nakikipag-ugnayan sa isang partikular na layunin sa pangkalahatang konteksto ng modelong sistema. Ang layunin ng kooperasyon mismo ay upang tukuyin ang mga tampok ng pagpapatupad ng mga indibidwal na pinakamahalagang operasyon sa system. Tinutukoy ng kooperasyon ang istruktura ng pag-uugali ng system sa mga tuntunin ng pakikipag-ugnayan ng mga kalahok sa kooperasyong ito.

        Ang kooperasyon ay maaaring katawanin sa dalawang antas:

• antas ng pagtutukoy - nagpapakita ng mga tungkulin ng mga tagapag-uri at ang mga tungkulin ng mga asosasyon sa pakikipag-ugnayan na isinasaalang-alang;
• halimbawang antas - nagsasaad ng mga pagkakataon at relasyon na bumubuo ng mga indibidwal na tungkulin sa pakikipagtulungan.

        Ipinapakita ng diagram ng pagtutulungan sa antas ng pagtutukoy ang mga tungkuling ginagampanan ng mga elementong kasangkot sa pakikipag-ugnayan. Ang mga elemento ng kooperasyon sa antas na ito ay mga klase at asosasyon, na tumutukoy sa mga indibidwal na tungkulin ng mga tagapag-uri at asosasyon sa pagitan ng mga kalahok sa kooperasyon.

        Ang diagram ng pakikipagtulungan sa antas ng halimbawa ay kinakatawan ng isang hanay ng mga bagay (mga pagkakataon ng mga klase) at mga koneksyon (mga pagkakataon ng mga asosasyon). Sa kasong ito, ang mga koneksyon ay pupunan ng mga arrow ng mensahe. Sa antas na ito, ipinapakita lamang ang mga bagay na direktang nauugnay sa pagpapatupad ng operasyon o classifier. Sa kasong ito, hindi kinakailangan na ilarawan ang lahat ng mga katangian o lahat ng mga asosasyon, dahil ang diagram ng pakikipagtulungan ay naglalaman lamang ng mga tungkulin ng mga classifier, ngunit hindi ang mga classifier mismo. Kaya, habang ang isang classifier ay nangangailangan ng kumpletong paglalarawan ng lahat ng mga pagkakataon nito, ang papel ng isang classifier ay nangangailangan ng paglalarawan lamang ng mga katangian at asosasyon na kinakailangan upang lumahok sa isang partikular na kooperasyon.

        Isang mahalagang kahihinatnan ang kasunod nito. Ang parehong hanay ng mga bagay ay maaaring lumahok sa iba't ibang mga kooperasyon. Depende sa kooperasyon na isinasaalang-alang, ang parehong mga katangian ng mga indibidwal na bagay at ang mga koneksyon sa pagitan ng mga ito ay maaaring magbago. Ito ang pinagkaiba ng isang diagram ng pakikipagtulungan mula sa isang diagram ng klase, na dapat ipahiwatig ang lahat ng mga katangian at pagkakaugnay sa pagitan ng mga elemento ng diagram.

Component diagram

        Ang ganitong uri ng diagram ay nilayon na ipamahagi ang mga klase at bagay sa mga bahagi sa panahon ng pisikal na disenyo ng isang system. Ang ganitong uri ng diagram ay madalas na tinatawag na module diagram.

Figure - 4. Component diagram

        Ang kumpletong disenyo ng software system ay isang hanay ng mga modelo ng lohikal at pisikal na antas na dapat na pare-pareho sa isa't isa. Gumagamit ang UML ng mga diagram ng pagpapatupad upang pisikal na kumatawan sa mga modelo ng system, na kinabibilangan component diagram At deployment diagram.

        Ang isang component diagram, hindi katulad ng mga naunang tinalakay na diagram, ay naglalarawan ng mga tampok ng pisikal na representasyon ng system. Pinapayagan ka nitong matukoy ang arkitektura ng system na binuo sa pamamagitan ng pagtatatag ng mga dependency sa pagitan ng mga bahagi ng software, na maaaring source at executable code. Ang mga pangunahing graphical na elemento ng isang component diagram ay mga component, interface, at dependencies sa pagitan ng mga ito.

        Ang component diagram ay binuo para sa mga sumusunod na layunin:

• visualization ng pangkalahatang istraktura ng source code ng software system;
• mga pagtutukoy ng executable na bersyon ng software system;
• pagtiyak ng muling paggamit ng mga indibidwal na mga fragment ng code ng programa;
• representasyon ng konseptwal at pisikal na mga schema ng database.

        Parehong system analyst at architect, pati na rin ang mga programmer, ay lumahok sa pagbuo ng mga component diagram. Ang isang component diagram ay nagbibigay ng pare-parehong paglipat mula sa isang lohikal na representasyon sa isang kongkretong pagpapatupad ng isang proyekto sa anyo ng software code. Ang ilang mga bahagi ay maaaring umiiral lamang sa yugto ng pagsasama-sama ng code ng programa, ang iba sa yugto ng pagpapatupad nito. Ang isang component diagram ay sumasalamin sa mga pangkalahatang dependency sa pagitan ng mga bahagi, na tinatrato ang huli bilang mga classifier.

        Upang kumatawan sa mga pisikal na entity sa wikang UML, isang espesyal na termino ang ginagamit - sangkap. Ang bahagi ay nagpapatupad ng isang tiyak na hanay ng mga interface at nagsisilbing pangkalahatang italaga ang mga elemento ng pisikal na representasyon ng modelo. Upang graphical na kumatawan sa isang bahagi, isang espesyal na simbolo ang ginagamit - isang parihaba na may dalawang mas maliit na parihaba na ipinasok sa kaliwa. Sa loob ng malaking parihaba ay ang pangalan ng bahagi at, kung kinakailangan, ilang karagdagang impormasyon. Ang hitsura ng simbolong ito ay maaaring bahagyang mag-iba depende sa likas na katangian ng impormasyong nauugnay sa bahagi.

Deployment diagram

        Ang ganitong uri ng diagram ay inilaan para sa pagsusuri sa hardware ng system, iyon ay, hardware, hindi mga program. Direktang isinalin mula sa English, ang Deployment ay nangangahulugang "deployment," ngunit ang terminong "topology" ay mas tumpak na sumasalamin sa kakanyahan ng ganitong uri ng diagram.

Figure - 5. Deployment diagram

        Ang pisikal na representasyon ng isang software system ay hindi maaaring kumpleto kung walang impormasyon sa kung anong platform at kung ano ang ibig sabihin ng computing na ito ay ipinatupad. Kung may binuong program na lokal na tumatakbo sa computer ng user at hindi gumagamit ng mga peripheral na device at mapagkukunan, hindi na kailangang bumuo ng mga karagdagang diagram. Kapag bumubuo ng mga corporate application, ang pagkakaroon ng mga naturang diagram ay maaaring maging lubhang kapaki-pakinabang para sa paglutas ng mga problema ng makatwirang paglalagay ng mga bahagi upang epektibong magamit ang distributed computing at mga mapagkukunan ng komunikasyon ng network, pagtiyak ng seguridad, at iba pa.

        Ang mga deployment diagram ay ginagamit upang kumatawan sa pangkalahatang configuration at topology ng isang distributed software system sa UML.

        Ang deployment diagram ay idinisenyo upang mailarawan ang mga elemento at bahagi ng isang program na umiiral lamang sa yugto ng runtime. Sa kasong ito, ang mga bahagi lang ng instance ng program, na mga executable na file o dynamic na library, ang kinakatawan. Ang mga bahaging iyon na hindi ginagamit sa runtime ay hindi ipinapakita sa deployment diagram. Kaya, ang mga bahagi na may mga source code ng programa ay maaari lamang naroroon sa component diagram. Hindi nakasaad ang mga ito sa deployment diagram.

        Ang deployment diagram ay naglalaman ng mga graphical na representasyon ng mga processor, device, proseso at koneksyon sa pagitan ng mga ito. Hindi tulad ng mga lohikal na diagram ng representasyon, ang isang deployment diagram ay pare-pareho para sa sistema sa kabuuan, dahil dapat itong ganap na sumasalamin sa mga tampok ng pagpapatupad nito. Ang pagbuo ng deployment diagram ay karaniwang ang huling hakbang sa pagtukoy ng modelo ng software system.

        Kapag bumubuo ng isang deployment diagram, ang mga sumusunod na layunin ay hinahabol:

• matukoy ang pamamahagi ng mga bahagi ng system sa mga pisikal na node nito;
• ipakita ang mga pisikal na koneksyon sa pagitan ng lahat ng mga node ng pagpapatupad ng system sa yugto ng pagpapatupad nito;
• tukuyin ang mga bottleneck ng system at muling i-configure ang topology nito upang makamit ang kinakailangang pagganap.

        Ang mga deployment diagram ay sama-samang binuo ng mga system analyst, network engineer at system technician.

Mga tampok ng Rational Rose work interface

        Ang tool na Rational Rose CASE ay nagpapatupad ng mga karaniwang tinatanggap na pamantayan para sa operating interface ng program, katulad ng mga kilalang visual programming environment. Matapos i-install ang Rational Rose sa computer ng gumagamit, na halos walang mga paghihirap kahit para sa mga nagsisimula, ang paglulunsad ng program na ito sa MS Windows 95/98 ay humahantong sa hitsura ng isang gumaganang interface sa screen (Fig. 6).

Larawan - 6. Pangkalahatang view ng gumaganang interface ng Rational Rose program

        Ang Rational Rose operating interface ay binubuo ng iba't ibang elemento, ang mga pangunahing ay:

• Pangunahing menu ng programa
• window ng diagram
• Window ng Dokumentasyon
• window ng browser
• Log window

Isaalang-alang natin sa madaling sabi ang layunin at pangunahing tungkulin ng bawat isa sa mga elementong ito.

Pangunahing menu ng programa

Ang pangunahing menu ng programa ay ginawa sa karaniwang tinatanggap na pamantayan at ganito ang hitsura (Larawan 7).

Ang mga indibidwal na item sa menu, na ang layunin ay malinaw sa kanilang mga pangalan, ay pinagsama ang mga katulad na operasyon na nauugnay sa buong proyekto sa kabuuan. Ang ilan sa mga item sa menu ay naglalaman ng mga kilalang function (pagbubukas ng proyekto, pag-print ng mga diagram, pagkopya at pag-paste ng iba't ibang elemento ng diagram mula sa clipboard). Ang iba ay napakaspesipiko na maaaring mangailangan sila ng karagdagang pagsisikap sa pag-aaral (mga opsyon sa pagbuo ng code, pagsuri sa pagkakapare-pareho ng modelo, pagkonekta ng mga karagdagang module).

Larawan - 7. Hitsura ng pangunahing menu ng programa

Karaniwang toolbar

Ang karaniwang toolbar ay matatagpuan sa ibaba ng pangunahing menu ng programa at ganito ang hitsura nito (Larawan 8). Ang ilan sa mga tool ay hindi magagamit (ang bagong proyekto ay walang anumang mga elemento). Ang karaniwang toolbar ay nagbibigay ng mabilis na access sa mga utos ng menu na pinakamadalas gamitin ng mga developer.

Larawan - 8. Hitsura ng karaniwang toolbar

Maaaring i-customize ng user ang hitsura ng panel na ito sa sarili niyang pagpapasya. Upang gawin ito, piliin ang menu item na Mga Tool -> Mga Pagpipilian at buksan ang tab na Mga Toolbar. Sa ganitong paraan maaari mong ipakita o itago ang iba't ibang mga pindutan ng tool at baguhin ang kanilang laki.

window ng browser

Ang default na window ng browser ay matatagpuan sa kaliwang bahagi ng gumaganang interface sa ilalim ng karaniwang toolbar (Larawan 9).

Ang browser ay nag-aayos ng mga view ng modelo sa isang hierarchical na istraktura na nagpapasimple sa nabigasyon at nagbibigay-daan sa iyong mahanap ang anumang elemento ng modelo sa proyekto. Sa kasong ito, ang anumang elemento na idinagdag ng developer sa modelo ay agad na ipinapakita sa window ng browser. Alinsunod dito, sa pamamagitan ng pagpili ng isang elemento sa window ng browser, maaari nating makita ito sa window ng diagram o baguhin ang detalye nito. Pinapayagan ka rin ng browser na ayusin ang mga elemento ng modelo sa mga pakete at ilipat ang mga elemento sa pagitan ng iba't ibang view ng modelo. Kung ninanais, ang window ng browser ay maaaring matatagpuan sa ibang lugar sa gumaganang interface o nakatago nang buo gamit ang item na View menu. Maaari mo ring baguhin ang laki ng browser sa pamamagitan ng pag-drag sa panlabas na frame nito gamit ang iyong mouse.

Larawan - 9. hitsura ng browser

Espesyal na toolbar

Ang isang espesyal na toolbar ay matatagpuan sa pagitan ng browser window at ng chart window sa gitnang bahagi ng gumaganang interface. Bilang default, inaalok ang isang toolbar para sa pagbuo ng diagram ng klase ng modelo (Larawan 10).

Larawan - 10. Hitsura ng isang espesyal na toolbar para sa isang class diagram

Ang lokasyon ng espesyal na toolbar ay maaaring baguhin sa pamamagitan ng paglipat ng panel frame sa nais na lokasyon. Maaari mo ring i-customize ang komposisyon ng panel sa pamamagitan ng pagdaragdag o pag-alis ng mga indibidwal na button na naaayon sa ilang partikular na tool. Maaaring matutunan ang mga takdang-aralin ng button mula sa mga tooltip na lumilitaw pagkatapos mag-hover ang mouse pointer sa kaukulang button.

window ng diagram

Ang window ng diagram ay ang pangunahing lugar ng trabaho ng interface nito, kung saan nakikita ang iba't ibang mga view ng modelo ng proyekto. Bilang default, ang window ng diagram ay matatagpuan sa kanang bahagi ng gumaganang interface, ngunit ang lokasyon at laki nito ay maaari ding baguhin. Kapag bumubuo ng isang bagong proyekto, kung ang Project Wizard ay hindi pa ginagamit, ang window ng diagram ay isang blangko na lugar na hindi naglalaman ng anumang mga elemento ng modelo (Larawan 11).

Ang pangalan ng diagram na matatagpuan sa window na ito ay ipinahiwatig sa title bar ng program (ang pinakamataas na linya ng program) o, kung ang window ay hindi na-maximize sa full screen, sa title bar ng chart window. Maraming mga chart ang maaaring naroroon sa window ng chart nang sabay-sabay, ngunit isa lamang sa mga ito ang maaaring maging aktibo. Halimbawa, sa Fig. 11 ang aktibong diagram ay ang deployment diagram, bagama't may iba pang mga diagram. Ang paglipat sa pagitan ng mga diagram ay maaaring gawin sa pamamagitan ng pagpili ng nais na view sa karaniwang toolbar o sa pamamagitan ng Window menu item. Kapag nag-activate ka ng hiwalay na view ng chart, nagbabago ang hitsura ng isang espesyal na toolbar, na na-customize para sa partikular na view ng chart.

Larawan - 11. Hitsura ng window ng diagram na may iba't ibang uri ng mga view ng modelo

Window ng Dokumentasyon

Ang window ng dokumentasyon ay maaaring wala sa screen bilang default. Sa kasong ito, maaari itong i-activate sa pamamagitan ng menu item View -> Documentation, pagkatapos nito ay lilitaw ito sa ibaba ng browser (Fig. 12).

Ang window ng dokumentasyon, gaya ng ipinahihiwatig ng pangalan nito, ay idinisenyo upang idokumento ang mga elemento ng isang view ng modelo. Maaari kang mag-record ng malawak na iba't ibang impormasyon dito, at kung ano ang mahalaga - sa Russian. Ang impormasyong ito ay kasunod na na-convert sa mga komento at hindi sa anumang paraan ay nakakaapekto sa lohika ng pagpapatupad ng code ng programa.

Sa window ng dokumentasyon, ang impormasyon na nauugnay sa indibidwal na napiling elemento ng diagram ay isinaaktibo. Sa kasong ito, maaari kang pumili ng isang elemento alinman sa window ng browser o sa window ng diagram. Kapag nagdagdag ka ng bagong elemento sa diagram (halimbawa, isang klase), awtomatikong nabubuo ang dokumentasyon para dito, na walang laman (Walang dokumentasyon). Kasunod nito, ang developer ay nakapag-iisa na nagpasok ng kinakailangang paliwanag na impormasyon, na naaalala at maaaring mabago sa panahon ng trabaho sa proyekto.

Tulad ng para sa iba pang mga window ng gumaganang interface, maaari mong baguhin ang laki at posisyon ng window ng dokumentasyon.

Larawan - 12. Hitsura ng window ng dokumentasyon

Log window

Ang Log window ay idinisenyo upang awtomatikong magtala ng iba't ibang impormasyon ng serbisyo na nabuo habang nagtatrabaho sa programa. Itinatala ng log ang oras at katangian ng mga aksyon na ginawa ng developer, tulad ng pag-update ng modelo, pag-customize ng mga menu at toolbar, pati na rin ang mga mensahe ng error na nangyayari kapag bumubuo ng program code.

Ang window ng log ay palaging naroroon sa gumaganang interface sa lugar ng window ng diagram (Larawan 13). Gayunpaman, maaari itong itago ng iba pang mga window ng tsart o pinaliit. Maaari mong i-activate ang log window sa pamamagitan ng Window->Log menu. Sa kasong ito, ito ay ipinapakita sa tuktok ng iba pang mga bintana sa tamang lugar ng gumaganang interface. Ang window na ito ay hindi maaaring ganap na maalis, maaari lamang itong i-minimize.

Larawan - 13. Ang hitsura ng window ng log

Konklusyon

        Sa paglipas ng panahon, ang wikang UML ay magiging "Esperanto" kung saan ang mga mathematician, system analyst, physicist, programmer, manager, economist at mga espesyalista ng iba pang mga propesyon ay makakapag-usap, na nagpapakita ng kanilang propesyonal na kaalaman sa isang pinag-isang anyo. Pagkatapos ng lahat, sa esensya, ang bawat isa sa mga espesyalista ay nagpapatakbo na may mga representasyon ng modelo sa kanilang larangan ng kaalaman. At tiyak na ang modelong aspetong ito ang maaaring tukuyin gamit ang wikang UML.

        Sa pagsasaalang-alang na ito, ang kahalagahan ng wikang UML ay tumataas nang malaki, dahil ito ay lalong nakakakuha ng mga tampok ng isang wika ng representasyon ng kaalaman. Kasabay nito, ang presensya sa wikang UML ng mga visual na paraan para sa kumakatawan sa istraktura at pag-uugali ng modelo ay ginagawang posible upang makamit ang isang sapat na representasyon ng kaalaman sa deklaratibo at pamamaraan at, hindi gaanong mahalaga, upang magtatag ng semantikong pagsusulatan sa pagitan ng mga form na ito ng kaalaman. Ang lahat ng mga tampok na ito ng wikang UML ay nagbibigay-daan sa amin upang tapusin na ito ang may pinakamabigat na mga prospect sa malapit na hinaharap.

Inilalarawan ng artikulong ito ang bagong panahon ng software development, ang epekto nito sa mga bagong kinakailangan sa UML, at ang pinakamahuhusay na kagawian para sa pagtugon sa mga ito.
  7. "Pagmomodelo ng data sa Rational Rose" Sergey Trofimov Inilalarawan ang pagmomodelo ng pisikal na representasyon ng data gamit ang Rational Rose
  8. UML na wika. Pangkalahatang pag-unawa sa wikang UML: mga istruktura, elemento ng grapiko at mga diagram ng wika.
  9. Praktikal na UML. Ang dokumentong ito ay pagsasalin ng dokumentong "Practical UML. A Hands-On Introduction for Developers". Praktikal na panimula para sa mga developer
  10. "Karaniwang object-oriented modelling language UML" Vendrov Alexander Mikhailovich. Kasaysayan ng UML
  11. UML – pinag-isang wika ng pagmomodelo. Ang materyal na ito ay naglalaman ng paunang impormasyon tungkol sa mga pamamaraan para sa paglalarawan ng mga software system at mga notasyong ginagamit sa UML
  12. UML na wika. Gabay sa gumagamit. Mga May-akda: Grady Booch, James Rumbaugh, Ivar Jacobson
  13. "Mga diagram ng UML sa Rational Rose" Sergey Trofimov
  14. "Pagsusuri at disenyo. Visual modeling (UML) Rational Rose" Konstantin Domolego
  15. Aklatan ni Gennady Vernikov. Kumpletong paglalarawan ng mga pamantayan sa disenyo at pagmomodelo.
  16. "Isang halimbawa ng paglalarawan ng isang paksa na lugar gamit ang UML kapag bumubuo ng mga software system" E.B. Zolotukhina, R.V. Alfimov. Gumagamit ang artikulo ng partikular na halimbawa para magpakita ng posibleng diskarte sa pagmomodelo ng domain batay sa paggamit ng Unified Modeling Language (UML)

       

Ngayon, ang proseso ng paglikha ng mga kumplikadong software application ay hindi maiisip nang hindi hinahati ito sa mga yugto ng ikot ng buhay. Sa pamamagitan ng siklo ng buhay ng isang programa, ang ibig naming sabihin ay isang hanay ng mga yugto:

• Pagsusuri ng lugar ng paksa at paglikha ng mga teknikal na pagtutukoy (pakikipag-ugnayan sa customer)
• Pagdidisenyo ng istraktura ng programa
• Coding (set ng program code ayon sa dokumentasyon ng proyekto)
• Pagsubok at Pag-debug
• Pagpapatupad ng programa
• Suporta sa programa
• Pagtatapon

Tingnan natin ang proseso ng disenyo. Sa panahon ng proseso ng disenyo, ang isang arkitekto o isang bihasang programmer ay lumilikha ng dokumentasyon ng disenyo, kabilang ang mga paglalarawan ng teksto, mga diagram, at mga modelo ng programa sa hinaharap. Tutulungan tayo ng wikang UML sa mahirap na gawaing ito.

Ang UML ay isang graphical na wika para sa visualization, paglalarawan ng mga parameter, disenyo at dokumentasyon ng iba't ibang mga system (mga programa sa partikular). Ang mga diagram ay nilikha gamit ang mga espesyal na CASE tool, tulad ng Rational Rose (http://www-01.ibm.com/software/rational/) at Enterprise Architect (http://www.sparxsystems.com.au/). Ang isang pinag-isang modelo ng impormasyon ay binuo batay sa teknolohiya ng UML. Ang mga tool sa CASE sa itaas ay may kakayahang bumuo ng code sa iba't ibang object-oriented na mga wika, at mayroon ding napakakapaki-pakinabang na reverse engineering function. (Pinapayagan ka ng reverse engineering na lumikha ng isang graphical na modelo mula sa umiiral nang program code at mga komento dito.)

Tingnan natin ang mga uri ng mga diagram para sa pag-visualize ng modelo (ito ay dapat magkaroon, kahit na marami pang uri):

Gamitin ang diagram ng case

Ang idinisenyong sistema ay kinakatawan bilang isang set ng mga entity o aktor na nakikipag-ugnayan sa system gamit ang tinatawag na precedents. Sa kasong ito, ang aktor o aktor ay anumang entity na nakikipag-ugnayan sa system mula sa labas. 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.

diagram ng klase

Ang isang diagram ng klase ay nagsisilbing kumakatawan 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 mga ugnayan sa pagitan ng mga indibidwal na entity ng domain, tulad ng mga object at subsystem, at inilalarawan din ang kanilang panloob na istraktura (mga field, pamamaraan...) at mga uri ng mga relasyon (mana, pagpapatupad ng mga interface... ). 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. Sa yugtong ito, ang kaalaman sa diskarte sa OOP at mga pattern ng disenyo ay mahalaga.

diagram ng statechart

Ang pangunahing layunin ng diagram na ito ay upang ilarawan ang mga posibleng pagkakasunud-sunod ng mga estado at mga paglipat na magkakasamang nagpapakilala sa pag-uugali ng isang elemento ng modelo sa panahon ng siklo ng buhay nito. Kinakatawan ng state diagram ang dynamic na pag-uugali ng mga entity batay sa espesipikasyon ng kanilang tugon sa perception ng ilang partikular na kaganapan.

Sequence diagram

Upang imodelo ang pakikipag-ugnayan ng mga bagay sa wikang UML, ginagamit ang mga naaangkop na diagram ng pakikipag-ugnayan. Ang mga pakikipag-ugnayan ng mga bagay ay maaaring matingnan sa oras, at pagkatapos ay isang sequence diagram ang ginagamit upang kumatawan sa timing ng paghahatid at pagtanggap ng mga mensahe sa pagitan ng mga bagay. Ang mga bagay na nakikipag-ugnayan ay nagpapalitan ng ilang impormasyon sa isa't isa. Sa kasong ito, ang impormasyon ay nasa anyo ng mga nakumpletong mensahe. Sa madaling salita, kahit na ang mensahe ay may nilalamang pang-impormasyon, nakukuha nito ang karagdagang pag-aari ng pagbibigay ng direktang impluwensya sa tatanggap nito.

Diagram ng pakikipagtulungan

Sa diagram ng pakikipagtulungan, ang mga bagay na kalahok sa pakikipag-ugnayan ay inilalarawan sa anyo ng mga parihaba, na naglalaman ng pangalan ng bagay, klase nito at, posibleng, mga halaga ng katangian. Tulad ng isang diagram ng klase, ang mga asosasyon sa pagitan ng mga bagay ay ipinahiwatig sa anyo ng iba't ibang linya ng pagkonekta. Sa kasong ito, maaari mong tahasang tukuyin ang mga pangalan ng asosasyon at ang mga tungkuling ginagampanan ng mga bagay sa asosasyong ito.
Hindi tulad ng isang sequence diagram, ang isang cooperation diagram ay naglalarawan lamang ng mga ugnayan sa pagitan ng mga bagay na gumaganap ng mga partikular na tungkulin sa pakikipag-ugnayan.

Component diagram

Ang isang component diagram, hindi tulad ng mga naunang tinalakay na diagram, ay naglalarawan ng mga tampok ng pisikal na representasyon ng system. Binibigyang-daan ka ng isang component diagram na tukuyin ang arkitektura ng system na binuo sa pamamagitan ng pagtatatag ng mga dependency sa pagitan ng mga bahagi ng software, na maaaring source, binary at executable code. Sa maraming development environment, ang isang module o component ay tumutugma sa isang file. Ang mga tuldok-tuldok na arrow na nagkokonekta sa mga module ay nagpapakita ng mga ugnayang magkakaugnay na katulad ng mga nangyayari kapag kino-compile ang source code ng program. Ang mga pangunahing graphical na elemento ng isang component diagram ay mga component, interface, at dependencies sa pagitan ng mga ito.

Deployment diagram

Ang deployment diagram ay idinisenyo upang mailarawan ang mga elemento at bahagi ng isang programa na umiiral lamang sa yugto ng runtime. Sa kasong ito, ang mga bahagi lang ng instance ng program, na mga executable na file o dynamic na library, ang kinakatawan. Ang mga bahaging iyon na hindi ginagamit sa runtime ay hindi ipinapakita sa deployment diagram.
Ang isang deployment diagram ay naglalaman ng mga graphical na representasyon ng mga processor, device, proseso, at ang mga koneksyon sa pagitan ng mga ito. Hindi tulad ng mga lohikal na diagram ng representasyon, ang isang deployment diagram ay pare-pareho para sa sistema sa kabuuan, dahil dapat itong ganap na sumasalamin sa mga tampok ng pagpapatupad nito. Ang diagram na ito ay mahalagang kinukumpleto ang proseso ng OOAP para sa isang partikular na sistema ng software at ang pagbuo nito ay karaniwang ang huling yugto ng detalye ng modelo.

Ito ay nagtatapos sa aming pangkalahatang-ideya ng mga diagram sa partikular at disenyo sa pangkalahatan. Kapansin-pansin na ang proseso ng disenyo ay matagal nang naging pamantayan para sa pag-unlad ng software, ngunit madalas na kailangan mong harapin ang isang napakahusay na nakasulat na programa, na, dahil sa kakulangan ng normal na dokumentasyon, ay tinutubuan ng hindi kinakailangang pag-andar sa gilid, mga saklay, nagiging mahirap. at nawawala ang dating kalidad nito. =(

Kumbinsido ako na ang isang programmer ay una at pangunahin sa isang coder - HINDI siya dapat makipag-usap sa customer, HINDI dapat isipin ang tungkol sa arkitektura ng system, hindi dapat mag-imbento ng isang interface sa programa, dapat lamang siyang mag-code - magpatupad ng mga algorithm, pag-andar, hitsura, kakayahang magamit, ngunit wala nang iba pa…. Ang taga-disenyo ay dapat, simula sa mga abstract na diagram (naglalarawan sa lugar ng paksa) hanggang sa mga diagram na kumakatawan sa istruktura ng data, mga klase at proseso ng kanilang pakikipag-ugnayan, ilarawan ang lahat nang detalyado sa bawat hakbang. Iyon ay, ang pagiging kumplikado ng trabaho at ang suweldo ng isang taga-disenyo ay dapat na isang order ng magnitude na mas mataas kaysa sa isang programmer == coder. Sorry sa sedisyon....

Ang kumpletong disenyo ng software system ay isang hanay ng mga modelong lohikal at pisikal na antas na dapat na pare-pareho sa isa't isa. Gumagamit ang UML ng mga diagram ng pagpapatupad upang pisikal na kumatawan sa mga modelo ng system, na kinabibilangan ng isang component diagram at isang deployment diagram.

Ang isang component diagram, hindi tulad ng mga naunang tinalakay na diagram, ay naglalarawan ng mga tampok ng pisikal na representasyon ng system. Pinapayagan ka nitong matukoy ang arkitektura ng system na binuo sa pamamagitan ng pagtatatag ng mga dependency sa pagitan ng mga bahagi ng software, na maaaring source at executable code. Ang mga pangunahing graphical na elemento ng isang component diagram ay mga component, interface, at dependencies sa pagitan ng mga ito.

Ang isang component diagram ay binuo para sa mga sumusunod na layunin:

visualization ng pangkalahatang istraktura ng source code ng software system;

mga pagtutukoy ng executable na bersyon ng software system;

pagtiyak ng muling paggamit ng mga indibidwal na mga fragment ng code ng programa;

representasyon ng konseptwal at pisikal na mga schema ng database.

Ang mga analyst ng system at arkitekto, pati na rin ang mga programmer, ay kasangkot sa pagbuo ng mga component diagram. Ang isang component diagram ay nagbibigay ng pare-parehong paglipat mula sa isang lohikal na representasyon sa isang kongkretong pagpapatupad ng isang proyekto sa anyo ng software code. Ang ilang mga bahagi ay maaaring umiiral lamang sa yugto ng pagsasama-sama ng code ng programa, ang iba sa yugto ng pagpapatupad nito. Ang isang component diagram ay sumasalamin sa mga pangkalahatang dependency sa pagitan ng mga bahagi, na tinatrato ang huli bilang mga classifier.

Mga bahagi

Upang kumatawan sa mga pisikal na entidad sa wikang UML, isang espesyal na termino ang ginagamit - bahagi. Ang bahagi ay nagpapatupad ng isang tiyak na hanay ng mga interface at nagsisilbing pangkalahatang italaga ang mga elemento ng pisikal na representasyon ng modelo. Upang graphical na kumatawan sa isang bahagi, isang espesyal na simbolo ang ginagamit - isang parihaba na may dalawang mas maliit na parihaba na ipinasok sa kaliwa. Sa loob ng malaking parihaba ay ang pangalan ng bahagi at, kung kinakailangan, ilang karagdagang impormasyon. Ang hitsura ng simbolong ito ay maaaring bahagyang mag-iba depende sa likas na katangian ng impormasyong nauugnay sa bahagi.

Ang pangalan ng bahagi ay sumusunod sa mga pangkalahatang tuntunin para sa pagbibigay ng pangalan sa mga elemento ng modelo sa wikang UML at maaaring binubuo ng anumang bilang ng mga titik, numero, at ilang mga bantas.

Maaaring katawanin ang isang indibidwal na bahagi sa antas ng uri o sa antas ng halimbawa. Ang graphical na representasyon ay pareho sa parehong mga kaso, ngunit ang mga patakaran para sa pagsulat ng pangalan ng bahagi ay iba. Kung ang isang bahagi ay kinakatawan sa antas ng uri, kung gayon ang naka-capitalize na pangalan ng uri lamang ang nakasulat bilang pangalan nito. Kung ang bahagi ay kinakatawan sa antas ng halimbawa, ang pangalan nito ay nakasulat<имя компонента>":"<имя типаХ>. Sa kasong ito, ang buong linya ng pangalan ay may salungguhit.

Bilang mga simpleng pangalan, kaugalian na gamitin ang mga pangalan ng mga executable na file (nagsasaad ng exe extension pagkatapos ng separator dot), dynamic na library (dll extension), Web page (html extension), text file (txt o doc extension) o help file (hip), database file (DB) o mga file na may program source code (h, cpp extension para sa C++ na wika, java extension para sa Java language), script (pi, asp) at iba pa.

Dahil ang tiyak na pagpapatupad ng lohikal na representasyon ng modelo ng system ay nakasalalay sa mga tool ng software na ginamit, ang mga pangalan ng mga bahagi ay tinutukoy ng mga tampok ng syntax ng kaukulang programming language.

Sa ilang mga kaso, ang impormasyon tungkol sa pangalan ng nakapaloob na pakete at ang partikular na bersyon ng pagpapatupad ng bahaging ito ay maaaring idagdag sa simpleng pangalan ng bahagi. Sa kasong ito, ang numero ng bersyon ay nakasulat bilang isang naka-tag na halaga sa mga kulot na brace. Sa ibang mga kaso, maaaring hatiin ang isang simbolo ng bahagi sa mga seksyon upang tahasang ipahiwatig ang mga pangalan ng mga interface na ipinapatupad nito.

Dahil ang isang bahagi, bilang isang elemento ng pisikal na pagpapatupad ng isang modelo, ay kumakatawan sa isang hiwalay na module ng code, kung minsan ay kinokomento ito ng mga karagdagang graphic na simbolo na naglalarawan ng mga partikular na tampok ng pagpapatupad nito. Ang mga karagdagang annotation na ito ay hindi tinukoy sa UML, ngunit ang paggamit ng mga ito ay ginagawang mas madaling maunawaan ang component diagram sa pamamagitan ng pagpapahusay sa kalinawan ng pisikal na representasyon.

May tatlong uri ng mga bahagi sa UML:

mga deployment na nagbibigay-daan sa system na direktang maisagawa ang mga function nito. Ang mga nasabing bahagi ay maaaring mga dynamic na link na aklatan na may extension na dll, mga Web page sa hypertext markup language na may extension na html, at mga help file na may extension ng hlp;

mga produkto ng trabaho. Bilang panuntunan, ito ay mga file na may source code ng mga programa, halimbawa, na may h o cpp na mga extension para sa C++ na wika;

executions, na mga executable modules - mga file na may extension ng exe.

Ang mga elementong ito ay tinatawag minsan na mga artifact, na nagbibigay-diin sa kanilang kumpletong nilalaman ng impormasyon, na nakasalalay sa partikular na teknolohiya para sa pagpapatupad ng mga kaukulang bahagi.

Ang isa pang paraan upang tukuyin ang iba't ibang uri ng mga bahagi ay ang tahasang ipahiwatig ang stereotype ng bahagi nito bago ang pangalan. Tinutukoy ng UML ang mga sumusunod na stereotype para sa mga bahagi:

library - tumutukoy sa unang uri ng bahagi, na ipinakita sa anyo ng isang dynamic o static na library;

talahanayan - tumutukoy din sa unang uri ng bahagi, na kinakatawan sa anyo ng isang talahanayan ng database;

file (file) - tumutukoy sa pangalawang uri ng bahagi, na ipinakita sa anyo ng mga file na may source code ng mga programa;

dokumento - tumutukoy sa pangalawang uri ng bahagi, . na ipinakita sa anyo ng isang dokumento;

executable - tumutukoy sa ikatlong uri ng component na maaaring isagawa sa node.

Mga interface

Ang susunod na elemento ng component diagram ay mga interface. Sa pangkalahatan, ang interface ay graphic na kinakatawan ng isang bilog na konektado sa bahagi ng isang segment ng linya na walang mga arrow. Ang pangalan ng interface ay dapat magsimula sa isang malaking titik na "I" at nakasulat sa tabi ng isang bilog. Sa semantiko, ang isang linya ay nangangahulugang isang pagpapatupad ng isang interface, at ang pagkakaroon ng mga interface sa isang bahagi ay nangangahulugan na ang bahaging ito ay nagpapatupad ng kaukulang hanay ng mga interface.

Ang isa pang paraan upang kumatawan sa isang interface sa isang component diagram ay ang ilarawan ito bilang isang class rectangle na may "interface" na stereotype at posibleng mga attribute at mga seksyon ng operasyon. Karaniwan, ginagamit ang notasyong ito upang kumatawan sa panloob na istraktura ng isang interface, na maaaring mahalaga sa pagpapatupad.

Kapag bumubuo ng mga sistema ng software, ang mga interface ay nagbibigay hindi lamang ng pagiging tugma sa pagitan ng iba't ibang mga bersyon, kundi pati na rin ng kakayahang gumawa ng mga makabuluhang pagbabago sa ilang bahagi ng programa nang hindi binabago ang iba pang mga bahagi. Kaya, ang layunin ng mga interface ay mas malawak kaysa sa detalye ng pakikipag-ugnayan sa mga gumagamit ng system (mga aktor).

Dependencies

Sa pangkalahatan, ang ugnayan ng dependence ay tinalakay din kanina. Alalahanin natin na ang pag-asa ay hindi isang asosasyon, ngunit nagsisilbing kumakatawan lamang sa katotohanan ng pagkakaroon ng naturang koneksyon, kapag ang isang pagbabago sa isang elemento ng modelo ay nakakaapekto o humantong sa isang pagbabago sa isa pang elemento ng modelo. Ang isang dependency na relasyon sa isang component diagram ay kinakatawan ng isang may tuldok na linya na may arrow na tumuturo mula sa kliyente (ang umaasa na elemento) patungo sa pinagmulan (ang independiyenteng elemento).

Maaaring ipakita ng mga dependency ang mga koneksyon sa pagitan ng mga module ng programa sa yugto ng compilation at pagbuo ng object code. Bilang kahalili, ang dependency ay maaaring magpakita ng presensya sa independiyenteng bahagi ng mga kahulugan ng klase na ginagamit sa umaasa na bahagi upang lumikha ng kaukulang mga bagay. Kapag inilapat sa isang component diagram, maaaring i-link ng mga dependency ang mga bahagi at ang mga interface na na-import ng bahaging iyon, pati na rin ang iba't ibang uri ng mga bahagi sa isa't isa.

Sa unang kaso, ang isang arrow ay iginuhit mula sa bahagi ng kliyente patungo sa na-import na interface. Ang pagkakaroon ng isang arrow ay nangangahulugan na ang bahagi ay hindi nagpapatupad ng kaukulang interface, ngunit ginagamit ito sa panahon ng pagpapatupad nito. Bukod dito, ang parehong diagram ay maaaring maglaman ng isa pang bahagi na nagpapatupad ng interface na ito.

Ang isa pang halimbawa ng isang dependency na relasyon sa isang component diagram ay ang relasyon sa pagitan ng iba't ibang uri ng mga bahagi. Ang pagkakaroon ng naturang dependency ay nangangahulugan na ang paggawa ng mga pagbabago sa source code ng mga programa o mga dynamic na aklatan ay humahantong sa mga pagbabago sa mismong bahagi. Sa kasong ito, ang likas na katangian ng mga pagbabago ay maaaring mapansin bilang karagdagan.

Ang isang component diagram ay maaari ding kumatawan sa mga ugnayan ng dependency sa pagitan ng mga bahagi at ng mga klase na kanilang ipinapatupad. Ang impormasyong ito ay mahalaga upang matiyak ang pagkakapare-pareho sa pagitan ng mga lohikal at pisikal na representasyon ng modelo ng system. Kung nais mong bigyang-diin na ang isang bahagi ay nagpapatupad ng magkakahiwalay na mga klase, kung gayon ang pinalawak na simbolo ng parihaba ay ginagamit upang tukuyin ang bahagi. Sa kasong ito, ang rectangle ng bahagi ay nahahati sa dalawang seksyon sa pamamagitan ng isang pahalang na linya. Ang itaas na seksyon ay ginagamit upang itala ang pangalan ng bahagi, at ang ibabang seksyon ay ginagamit upang ipahiwatig ang karagdagang impormasyon.

Ang iba pang mga elemento ng graphical na notation, gaya ng mga klase (type-level component) o mga object (instance-level component), ay maaaring ilarawan sa loob ng isang component na simbolo. Sa kasong ito, ang simbolo ng bahagi ay iginuhit upang mapaunlakan ang mga karagdagang simbolo na ito.

Ang mga bagay na naninirahan sa isang hiwalay na bahagi ng instance ay inilalarawan bilang naka-nest sa loob ng simbolo ng bahaging iyon. Ang ganitong nesting ay nangangahulugan na ang pagpapatupad ng isang bahagi ay nangangailangan ng pagpapatupad ng mga kaukulang bagay.

Ang pagbuo ng isang component diagram ay nagsasangkot ng paggamit ng impormasyon tungkol sa parehong lohikal na representasyon ng modelo ng system at ang mga tampok ng pisikal na pagpapatupad nito. Bago magsimula ang pag-unlad, kinakailangan na gumawa ng mga desisyon tungkol sa pagpili ng mga platform sa pag-compute at mga operating system kung saan dapat ipatupad ang system, pati na rin ang pagpili ng mga partikular na database at mga wika ng programming.

Pagkatapos nito, maaari kang magpatuloy sa pangkalahatang structuring ng component diagram. Una sa lahat, kinakailangang magpasya kung anong mga pisikal na bahagi (mga file) ang bubuo ng software system. Sa yugtong ito, dapat bigyang pansin ang isang pagpapatupad ng sistema na magbibigay hindi lamang ng posibilidad ng muling paggamit ng code sa pamamagitan ng makatwirang pagkabulok ng mga bahagi, kundi pati na rin ang paglikha ng mga bagay kapag kinakailangan lamang ang mga ito.

Ang punto ay ang pangkalahatang pagganap ng isang sistema ng software ay lubos na nakadepende sa makatwirang paggamit ng mga mapagkukunan ng computing. Para sa layuning ito, kinakailangan na ilipat ang karamihan sa mga paglalarawan ng mga klase, ang kanilang mga operasyon at pamamaraan sa mga dynamic na aklatan, na iniiwan sa mga executable na bahagi lamang ang pinaka-kinakailangang mga fragment ng program code para sa pagsisimula ng programa.

Pagkatapos ng pangkalahatang structuring ng pisikal na representasyon ng system, ito ay kinakailangan upang madagdagan ang modelo na may mga interface at database schemas. Kapag bumubuo ng mga interface, dapat mong bigyang pansin ang koordinasyon (pagsali) ng iba't ibang bahagi ng sistema ng software. Ang pagsasama ng isang database schema sa isang modelo ay nagsasangkot ng pagtukoy ng mga indibidwal na talahanayan at pagtatatag ng mga ugnayan ng impormasyon sa pagitan ng mga talahanayan.

Ang huling yugto ng pagbuo ng isang component diagram ay nauugnay sa pagtatatag at pag-plot ng mga mutual na koneksyon sa pagitan ng mga bahagi, pati na rin ang mga relasyon sa pagpapatupad, sa diagram. Ang mga ugnayang ito ay dapat na ilarawan ang lahat ng pinakamahalagang aspeto ng pisikal na pagpapatupad ng system, simula sa mga tampok ng pagsasama-sama ng mga source code ng mga programa at nagtatapos sa pagpapatupad ng mga indibidwal na bahagi ng programa sa yugto ng pagpapatupad nito. Para sa layuning ito, maaari mong gamitin ang iba't ibang uri ng graphical na representasyon ng mga bahagi.

Kapag bumubuo ng isang component diagram, dapat kang sumunod sa mga pangkalahatang prinsipyo ng paglikha ng mga modelo sa wikang UML. Sa partikular, kinakailangang gumamit ng mga bahagi at stereotype na magagamit na sa wikang UML. Para sa karamihan ng mga tipikal na proyekto, ang hanay ng mga elementong ito ay maaaring sapat upang kumatawan sa mga bahagi at ang mga dependency sa pagitan ng mga ito.

Kung ang proyekto ay naglalaman ng ilang pisikal na elemento na hindi inilalarawan sa wikang UML, dapat mong gamitin ang mekanismo ng extension at gumamit ng mga karagdagang stereotype para sa mga indibidwal na hindi pangkaraniwang bahagi o may label na mga halaga upang linawin ang kanilang mga indibidwal na katangian.

Dapat tandaan na ang isang component diagram ay karaniwang binuo kasabay ng isang deployment diagram, na nagbibigay ng impormasyon tungkol sa pisikal na paglalagay ng mga bahagi ng software system sa mga indibidwal na node nito.

Ipinapakita ng component diagram ang mga bahagi ng disenyo ng software system. Ang isang component diagram ay nakakatulong na makita ang mataas na antas na istraktura ng isang system at ang gawi ng mga serbisyong ibinigay at ginagamit ng mga elementong ito sa pamamagitan ng mga interface. Para gumawa ng UML component diagram, sa Architecture menu, i-click ang Create Diagram.

Maaaring gamitin ang isang component diagram upang ilarawan ang isang disenyo ng system na ipinatupad sa anumang wika o istilo. Kinakailangan lamang na tukuyin ang mga bahagi ng istraktura na nakikipag-ugnayan sa ibang mga bahagi sa pamamagitan ng limitadong hanay ng mga channel ng input at output. Maaari kang gumamit ng mga bahagi ng anumang sukat, na magkakaugnay sa anumang paraan.

Ang sumusunod na talahanayan ay naglalarawan ng mga elemento na maaaring magamit sa isang component diagram at ang kanilang mga pangunahing katangian.

Pigura	Elemento	Paglalarawan at pangunahing katangian
	Component	Isang magagamit muli na functional na elemento ng isang system. Ang isang bahagi ay naglalantad at gumagamit ng gawi sa pamamagitan ng mga interface at maaaring gumamit ng iba pang mga bahagi. Maaari mong itago o ipakita ang mga panloob na bahagi ng isang component gamit ang expand/collapse control (9). Ang isang bahagi ay isang uri ng klase. Ay isang implicitly na nilikhang instance. Kung totoo (ang default), ang bahagi ay umiiral lamang bilang isang artifact ng disenyo. Sa runtime, bahagi lamang nito ang umiiral.
	Ibinigay na interface port	Kumakatawan sa isang pangkat ng mga mensahe o tawag na ipinatupad ng isang bahagi at magagamit ng iba pang mga bahagi o mga panlabas na system. Ang port ay isang component property na may interface bilang uri nito.
	Kinakailangang interface port	Kumakatawan sa isang pangkat ng mga mensahe o tawag na ipinadala ng isang bahagi sa iba pang mga bahagi o mga panlabas na system. Ang bahagi ay idinisenyo upang kumonekta sa mga bahagi na nagbibigay ng hindi bababa sa mga operasyong ito. Ang isang port ay may isang interface bilang uri nito.
	Pagkagumon	Maaaring gamitin upang ipahiwatig na ang kinakailangang interface ng isang bahagi ay maaaring tumugma sa ibinigay na interface ng isa pang bahagi. Ang mga dependency ay maaari ding gamitin nang mas pangkalahatan kapag nagtatrabaho sa mga elemento ng modelo upang ipakita na ang disenyo ng isa ay nakasalalay sa disenyo ng isa pa.
		Isang katangian ng isang bahagi na ang uri ay karaniwang isa pang bahagi. Ang bahagi ay ginagamit sa panloob na disenyo ng parent component nito. Sa graphically, ipinapakita ang mga bahagi bilang nested sa loob ng isang parent na bahagi. Upang lumikha ng bahagi ng isang umiiral na uri ng bahagi, i-drag ang bahagi mula sa UML Model Explorer papunta sa nagmamay-ari na bahagi. Para gumawa ng bagong uri ng bahagi, piliin ang Component tool at i-click ang pagmamay-ari na bahagi. Halimbawa, ang bahagi ng Kotse ay may mga bahagi ng makina:CarEngine, likodKaliwa:Gulong, kanan sa harap:Gulong, atbp. Maaaring magkapareho ang uri ng maramihang bahagi, at maaaring magkaroon ng magkaparehong uri ang iba't ibang bahagi. Uri. Isang uri ng bahagi na tinukoy sa ibang lugar sa modelo. Kadalasan ang uri ay isa pang bahagi. Multiplicity. Ang default na halaga ay 1. Maaari mong itakda ito sa 0..1 upang ipahiwatig na ang bahagi ay maaaring null, o maaari mo itong itakda sa * upang ipahiwatig na ang bahagi ay isang koleksyon ng mga pagkakataon ng ganoong uri. Maaari mo ring itakda ang halaga sa anumang expression na maaaring masuri sa isang hanay ng numero.
	Bahagi ng pagpupulong	Isang koneksyon sa pagitan ng mga kinakailangang interface port ng isang bahagi at ang ibinigay na interface port ng isa pa. Ang pagpapatupad ng bahagi ng pagpupulong ay maaaring mag-iba para sa iba't ibang mga bahagi. Ang mga konektadong bahagi ay dapat magkaroon ng parehong bahagi ng magulang.
	Delegasyon	Iniuugnay ang isang port na may interface ng isa sa mga bahaging bahagi. Isinasaad na ang mga mensaheng ipinadala sa isang bahagi ay pinoproseso ng bahaging ito, o ang mga mensaheng ipinadala ng bahaging ito ay ipinadala mula sa isang pangunahing bahagi.
(Hindi pinakita)	Paglalahat	Isinasaad na ang isang bahagi ay nagmamana mula sa isa pa. Ang mga bahagi at interface ay minana.
	Palawakin/i-collapse ang kontrol	Binibigyang-daan kang itago o ipakita ang mga panloob na bahagi ng isang bahagi.
(Hindi pinakita)

Ang seksyong ito ay nakatuon sa dalawang diagram nang sabay-sabay: mga bahagi at pagkakalagay, kung saan maaari mong gamitin ang pangkalahatang pangalan ‒ mga diagram ng pagpapatupad. Ito ay dahil sa ang katunayan na ang mga diagram na ito ay nagiging lalong mahalaga sa mga huling yugto ng pag-unlad - sa mga yugto ng pagpapatupad at paghahatid. Habang nasa mga unang yugto ng pag-unlad - pagsusuri at disenyo - ang mga diagram na ito ay alinman sa hindi ginagamit o may isang napaka pangkalahatan, hindi detalyadong hitsura.

Mula sa pananaw ng pagpapatupad, ang idinisenyong sistema ay binubuo ng mga bahagi (kinakatawan sa mga component diagram) na ipinamahagi sa mga computing node (kinakatawan sa mga placement diagram).

Sa UML 2, kumpara sa UML 1, nagkaroon ng makabuluhang pagbabago, ibig sabihin, ang konsepto ng "bahagi" ay nahahati sa dalawang bahagi: lohikal at pisikal. Lohikal na bahagi na patuloy na nagdadala ng pangalan sangkap(component), ay isang elemento ng lohikal na modelo ng system, habang ang pisikal na bahagi, tinatawag artifact(artifact), nagpapakilala sa pisikal na elemento ng dinisenyong sistema, na matatagpuan sa computing node(node).

Ang mga diagram ng bahagi at layout ay may maraming pagkakatulad, pinagsasama-sama ang mga sumusunod, malapit na nauugnay na mga bagay:

• istraktura ng mga lohikal na elemento (mga bahagi);
• pagmamapa ng mga lohikal na elemento (mga bahagi) sa mga pisikal na elemento (mga artifact);
• ang istraktura ng mga mapagkukunang ginamit (mga node) na may mga pisikal na elemento (mga artifact) na ipinamahagi sa kanila.

Sa seksyong ito, lilihis tayo sa panuntunang pinagtibay natin noong inilalarawan ang natitirang mga diagram. Ibig sabihin, hindi namin isasaalang-alang nang hiwalay para sa bawat diagram ang mga entity na ginamit dito. Mukhang mas tama sa amin na sama-samang isaalang-alang ang lahat ng entity at relasyon sa isang seksyon, na kung ano ang gagawin namin.

3.4.1. Interface

∇ Mga opsyon sa pagsasalin na makikita sa literatura: “ipinatupad”, “ibinigay”.

∇∇ Ang opsyon sa pagsasalin na makikita sa panitikan ay “hinihiling”

Gayunpaman, hindi natin dapat kalimutan na ang interface mismo ay isang paglalarawan lamang ng kontrata, at ito ay ibinibigay o kinakailangan depende sa kung paano ginagamit ang interface na ito:

• kung ang isang classifier ay nagpapatupad ng isang interface, kung gayon para sa classifier na ito ito secured interface at ang katotohanang ito ay ipinapakita gamit ang pagpapatupad na kaugnayan 3;
• kung ang classifier ay tumatawag sa mga operasyon ng interface, kung gayon para sa classifier na ito ito kailangan interface at ang katotohanang ito ay ipinapakita gamit ang dependency na relasyon 4.

Ang pagkakaroon ng pakikitungo sa mga interface, lumipat tayo sa mga bahagi.

3.4.2. Mga Bahagi, Artifact at Assemblies

Component(component) ay isang modular na fragment ng lohikal na representasyon ng system, pakikipag-ugnayan kung saan inilalarawan ng isang set ng ibinigay at kinakailangang mga interface.

Ang konsepto ng "component" ay madalas na nauugnay sa component o assembly programming, ngunit para sa UML ang sulat na ito ay hindi lehitimo. Ang isang bahagi ng UML ay bahagi ng isang modelo, at naglalarawan ng isang lohikal na entity na umiiral lamang sa oras ng disenyo(panahon ng disenyo), bagama't sa hinaharap maaari itong maiugnay sa isang pisikal na pagpapatupad (artifact) oras ng pagpapatupad(oras ng pagtakbo).

Ang pamantayan ng UML ay nagbibigay ng mga stereotype para sa mga bahagi, tulad ng ipinapakita sa sumusunod na talahanayan.

mesa Mga Standard na Component Stereotypes

Ang analogue ng isang bahagi sa kahulugan ng assembly programming ay ang konsepto ng isang artifact sa UML. At hindi lamang anumang artifact, ngunit ilan lamang sa mga stereotype nito.

artifact‒ ay anumang artipisyal na nilikhang elemento ng isang software system.

Ang mga elemento ng isang software system, at samakatuwid ay mga artifact, ay maaaring magsama ng mga executable na file, source code ng program, mga web page, mga file ng tulong, mga sumusuportang dokumento, mga file ng data, mga modelo, at marami pang ibang pisikal na elemento ng impormasyon. Sa madaling salita, ang mga artifact ay ang mga elemento ng impormasyon na ginagamit sa isang paraan o iba pa sa panahon ng pagpapatakbo ng isang software system at kasama sa komposisyon nito.

Upang kahit papaano ay maipakita ang iba't ibang uri ng artifact, ang UML ay nagbibigay ng mga karaniwang stereotype na nakalista sa talahanayan

mesa Mga Karaniwang Stereotype ng Artifact

Gayunpaman, ang mga tunay na artifact ay mas magkakaibang sa kanilang mga uri kaysa sa mga nakalista sa itaas. Upang isaalang-alang ito, maraming tool, bilang karagdagan sa mga karaniwang stereotype, ang sumusuporta sa mga karagdagang stereotype ng artifact, kadalasang may mga espesyal na icon at hugis na ginagawang lubos na nakikita ang mga diagram.

Ang pinakamahalagang aspeto ng paggamit ng konsepto ng artifact sa UML ay ang isang artifact ay maaaring lumahok sa isang manifestation relationship.

Pagpapakita‒ ito ay isang dependency na relasyon sa "manifest" na stereotype na nag-uugnay sa isang elemento ng modelo (halimbawa, isang klase o bahagi) at ang pisikal na pagpapatupad nito sa anyo ng isang artifact.

Nasa ibaba ang klase ng Kumpanya , na may kaugnayan sa pagpapakita (dependency sa stereotype na "manifest") na may dalawang artifact na may stereotype na "source", na tumutukoy naman sa isang runtime artifact, isang dynamic na library (na may stereotype na "library") Company .

Sa pangkalahatan, ang isang manipestasyon na relasyon ay isang relasyong marami-sa-maraming; ang isang elemento ng modelo ay maaaring ipatupad ng maraming artifact, at ang isang artifact ay maaaring lumahok sa pagpapatupad ng maraming elemento ng modelo.

Ang pagpapakita ay graphic na inilalarawan ng isang relasyon ng pag-asa sa stereotype na "manifest" mula sa isang artifact hanggang sa isang natanto na entity. Dahil ang manifestation ay isang many-to-many na relasyon, maaaring kailanganin ang maraming dependency na relasyon sa modelo upang ganap na ilarawan ang manifestation na relasyon.

Ang ikatlong entity na tinalakay sa seksyong ito ay isang node.

∇ Kapag gumagamit ng UML sa ibang mga paksa, ang isang node ay maaaring hindi lamang isang computer, ngunit isa pang bagay: isang tao, isang mekanikal na aparato, atbp.

Nagbibigay ang UML ng dalawang stereotype para sa "executionEnvironment" at "device" na mga node.

Ang isang node na may stereotype na "executionEnvironment" ay nagbibigay-daan sa iyo na imodelo ang hardware at software platform kung saan ang application ay pinaandar. Ang mga halimbawa ng runtime environment ay: operating system, database management system, atbp.

Ang isang node na may stereotype na "device" ay nagmomodelo din ng isang platform ng hardware at software, ngunit nagbibigay-daan sa posibilidad na mag-nest ng isang node sa loob ng isa pa, tulad ng ipinapakita sa sumusunod na figure.

Ang mga artifact ng system sa panahon ng operasyon nito ay inilalagay sa mga node, na kung saan ay graphical na ipinahayag alinman sa pamamagitan ng paglilista ng mga ito sa loob ng node 1 (tingnan ang figure sa itaas), o sa pamamagitan ng isang dependency na relasyon sa stereotype na "deploy" sa pagitan ng artifact at node 1 (tingnan ang figure sa ibaba ), o sa pamamagitan ng paglalarawan ng artifact sa loob ng mga larawan ng node 2 (tingnan ang larawan sa ibaba). Ang lahat ng mga pagpipilian sa notasyon ay pantay.

Kung ang mga parameter na partikular sa kapaligiran ay may mahalagang papel kapag naglalagay ng artifact sa isang node, maaari silang tukuyin gamit ang mga pagtutukoy ng deployment(detalye ng pag-deploy).

Ang detalye ng deployment ay inilalarawan bilang isang classifier (bilang isang parihaba), ngunit may stereotype na "deploymentSpec" at nauugnay sa isang dependency na relasyon sa artifact.

Ang huling bagay na kailangan nating isaalang-alang sa seksyong ito ay ang relasyon mga asosasyon sa pagitan ng mga node.

Kung ang mga node ay konektado sa pamamagitan ng isang relasyon sa asosasyon, nangangahulugan ito ng parehong bagay tulad ng sa iba pang mga konteksto: ang kakayahang makipagpalitan ng mga mensahe. May kaugnayan sa mga network ng computer na binubuo ng mga node, ang asosasyon ay nangangahulugan ng pagkakaroon ng isang channel ng komunikasyon. Kung kailangan mong tukuyin ang karagdagang impormasyon tungkol sa mga katangian ng isang channel, maaari itong gawin gamit ang mga karaniwang mekanismo: mga stereotype (halimbawa, "tcp/ip", tingnan ang figure sa ibaba), mga paghihigpit at pinangalanang mga halaga.

Dito natin tatapusin ang talatang ito ng pangkalahatang-ideya, upang sa susunod ay mas makikilala natin ang mga diagram ng mga bahagi at pagkakalagay gamit ang halimbawa ng isang sistema ng impormasyon para sa departamento ng tauhan.

3.4.3. Paglalapat ng Component at Layout Diagram

Subukan nating sagutin ang tanong kung anong mga interface, sangkap at artifact ang maaaring makilala sa sistema ng impormasyon ng HR, pati na rin kung paano ipinapayong ilagay ang binuo na software sa mga node ng computing.

Ang pangunahing layunin ng idinisenyong sistema ng impormasyon ay mag-imbak ng data ng tauhan at magsagawa ng ilang partikular na operasyon gamit ang data na ito sa direksyon ng user. Sinusuri ang komposisyon ng mga operasyon, nakita namin na bumaba ang mga ito sa paglikha, pagbabago at pagtanggal ng mga nakaimbak na elemento ng data. Ang karaniwang solusyon sa ganitong mga sitwasyon ay ang paggamit ng isang handa na DBMS (DBMS - Data Base Management System). Mula sa punto ng view ng pagdidisenyo ng isang sistema ng impormasyon para sa departamento ng HR, ipinapayong isaalang-alang ang DBMS na ginamit bilang isang handa na bahagi na may paunang natukoy na mga interface at isang protocol ng pakikipag-ugnayan. Hindi namin kailangang tumuon sa istraktura ng bahaging ito - ito ay karaniwan at, marahil, medyo mahusay na inilarawan sa labas ng aming modelo.

Ang DBMS ang kukuha sa lahat ng mga function para sa direktang pagmamanipula ng data: paggawa, pagtanggal at paghahanap ng mga tala sa mga talahanayan, atbp. Ang pagpapatupad ng mga pagpapatakbo ng aming HR information system ay bumaba sa isang tiyak na pagkakasunud-sunod ng mga elementarya na operasyon na may data. Halimbawa, ang paglipat ng isang empleyado mula sa isang posisyon patungo sa isa pa ay malamang na nangangailangan ng mga pagbabago sa tatlong elemento ng data: ang data ng empleyado at ang luma at bagong data ng trabaho. Gayunpaman, ipinapayong isaalang-alang na ang kahulugan at pagpapatupad ng mismong pagkakasunud-sunod ng mga elementarya na operasyon na may data ay ang prerogative din ng bahaging napili namin - ang DBMS? Sinasagot ng karaniwang kasanayan ang tanong na ito sa negatibo. Para sa maraming mga kadahilanan, mas mahusay na paghiwalayin ito sa isang hiwalay na bahagi, karaniwang tinatawag na lohika ng negosyo ∇. Bilang karagdagan, dapat nating ipagpalagay na ang ating system ay dapat may bahaging responsable para sa user interface. Bilang unang pagtatantya, nakarating kami sa istruktura ng bahagi sa ibaba, na tinatawag na "tatlong antas na arkitektura."

∇ Isang lubhang kapus-palad, ngunit madalas na ginagamit na termino, na isang kopya ng lohika ng negosyo sa Ingles. Ang lohika ng negosyo ay walang kinalaman sa alinman sa negosyo (sa kahulugan ng salitang Ruso) o lohika. Mas tamang gamitin ang kumplikadong pariralang "mga panuntunan sa pagpoproseso ng data," ngunit natatakot kaming hindi maunawaan.

Ipinakilala ng UML 2 ang mga sumusunod na pagbabago sa component diagram notation.

Una, ang mga bahagi, tulad ng anumang classifier, ay maaaring ilarawan nang pantay, sa anyo ng mga parihaba, kung saan ang alinman sa stereotype na "bahagi" 1 o isa sa mga nagpapalinaw na stereotype na ibinigay sa talahanayan ay ipinahiwatig. Mga karaniwang stereotype ng sangkap sa talata 3.4.2 2, o ang kaukulang icon sa kanang sulok sa itaas ng parihaba 3.

Pangalawa, ang kinakailangan at ibinigay na mga interface ay maaaring katawanin gamit ang lollipop notation 4 (tingnan ang Seksyon 3.3.1), upang ang ugnayan sa pagitan ng mga bahagi sa pamamagitan ng ilang interface ay mukhang natural at simetriko.

Ito ay inilalarawan ng figure sa ibaba, na nagpapakita ng parehong mga entity at relasyon tulad ng sa figure sa itaas.

Ang ibinigay na halimbawa ng isang component diagram ay medyo walang halaga at mukhang hindi masyadong kapani-paniwala mula sa punto ng view ng pagiging kapaki-pakinabang sa disenyo ng arkitektura. Ang pagkilala sa pagkukulang na ito, magbibigay kami ng isa pang halimbawa na nauugnay sa sistema ng impormasyon ng HR, kung saan susubukan naming ipakita na ang mga diagram ng bahagi ay isang medyo nagpapahayag na tool para sa disenyo ng arkitektura.

Ipagpalagay natin na sa inaasahang sistema ng impormasyon ng departamento ng HR kinakailangan na pag-iba-ibahin ang mga karapatang magsagawa ng mga operasyon at pag-access sa data para sa iba't ibang kategorya ng mga gumagamit. Bagama't ang aming mga teknikal na pagtutukoy ay hindi nagsasabi ng isang salita tungkol dito, para sa mga modernong sistema ang pangangailangan na ito ay naging pangkaraniwan (kung minsan ay malinaw na hindi kailangan), kaya ang halimbawa ay hindi malayo. Alam namin ang maraming paraan para ipatupad ang pagkakaiba-iba ng mga karapatan sa pag-access sa data, at malamang na marami pang paraan na hindi namin alam. Hindi tayo pupunta sa kanilang paglalarawan at talakayan, ngunit lilimitahan ang ating sarili sa isang bagay - napakasimple, ngunit epektibo. Ang aming aplikasyon ay may dalawang aktor (tingnan ang talata 2.2.1), i.e. dalawang kategorya ng mga gumagamit. Ipagpalagay natin na sapat na ang pag-iiba ng mga karapatan sa antas ng mga kategorya ng user. Pagkatapos ay maaari mong gawin ang sumusunod: gumawa lamang ng dalawang magkaibang aplikasyon (o, gaya ng karaniwang sinasabi nila sa mga ganitong kaso, dalawa mga awtomatikong workstation- ARMA). Ang mga user na may access sa workstation sa kabuuan ay maaaring magsagawa ng lahat ng mga operasyon ng workstation at, sa gayon, mayroon ang mga iyon at tanging mga karapatang iyon upang ma-access ang data na ibinibigay ng mga operasyong ipinatupad sa workstation.

Para sa isang aplikasyon tulad ng isang HR information system, ang gayong solusyon ay halos sapat. Kaya, ang pagkakaiba-iba ng mga karapatan sa pag-access sa data ay inililipat sa antas ng pag-access sa mga computer at mga application na naka-install sa kanila, at ito ay mga problema na ng mga operating system at mga serbisyo sa seguridad ng enterprise, na hindi maaaring alagaan sa sistema ng impormasyon ng HR.

Ang desisyon na ginawa ay madaling ipinahayag sa isang component diagram.

Ang lahat na nananatiling dapat gawin ay upang matukoy ang komposisyon ng mga bahagi, i.e. ipakita kung aling mga klase ang kasama sa kung aling mga bahagi.

Ang pinakasimpleng paraan upang ipakita ang kaugnayan sa pagitan ng isang bahagi at mga klase ng miyembro nito ay ang paggamit ng kaugnayan sa pagpapatupad 1, tulad ng ipinapakita sa ibaba.

Ang isa pang paraan upang matukoy ang komposisyon ng isang bahagi ay ang tratuhin ito bilang isang structured classifier at gumamit ng internal structure diagram (tingnan ang paragraph 1.6.2 at paragraph 3.5.1).

Ang susunod na aspeto ng istruktura na kailangang talakayin ay ang paglalarawan ng paglalagay ng mga artifact na may kaugnayan sa mga mapagkukunan ng computing na kasangkot.

Kung pinag-uusapan natin ang tungkol sa isang desktop application na ganap na naka-imbak at naisakatuparan sa isang computer, kung gayon ang isang hiwalay na diagram ng layout ay hindi kinakailangan - sapat na ang isang component diagram (at marahil ay magagawa mo nang wala ito). Kapag nagmomodelo ng mga distributed application, ang kahalagahan ng mga placement diagram ay tumataas nang husto: ang mga ito ay isang paglalarawan ng topology ∇ deployed system.

∇ Hiniram ng mga programmer ang pangalan ng sangay ng matematika (topology) bilang termino. Halimbawa, madalas mong makikita ang expression na "topology ng lokal na network". Hindi masasabi na ang gayong paghiram ay ganap na hindi tama, ngunit sa parehong oras ay hindi ito ganap na kakanyahan. Kami ay nagsasalita lamang tungkol sa paglalarawan ng istraktura ng mga koneksyon ng isang may hangganan na hanay ng mga node, i.e. tungkol sa bilang.

Ipagpatuloy natin ang ating pagsasaalang-alang sa sistema ng impormasyon ng departamento ng HR sa aspetong ito. Ipagpalagay natin na pinagtibay natin ang arkitektura na ipinapakita sa itaas sa figure na "IC Component Diagram OK". Ilang mga computer ang gagamitin kapag pinapatakbo ang application na ito? Dapat ding sagutin ang tanong na ito sa tanong na: ilang user ang magkakaroon ng system at ilan sa kanila ang gagana sa application nang sabay? Kung mayroon lamang isang gumagamit (o, mas masahol pa, mai-install ang aming system "para ipakita" at hindi gagamitin), pagkatapos ay walang problema - desktop application - isang computer at walang placement diagram ang kailangan. Sabihin nating dapat maraming user ang aming system, at maaari silang gumana nang sabay-sabay. Kung gayon ang sagot ay halata: dapat na walang mas kaunting mga node kaysa sa bilang ng mga kasabay na gumagamit, dahil hindi maginhawa para sa mga ordinaryong gumagamit na magtulungan sa isang personal na computer. Malamang, dapat mayroong isa pang node kaysa sa mga user, dahil Karamihan sa mga organisasyon ay may espesyal na nakatuong computer (server) para sa pag-iimbak ng data ng kumpanya. Doon namin ilalagay ang aming database, sa inaasahan na ang kinakailangang DBMS ay malamang na naka-install na sa server. Ang tanong ay nananatili tungkol sa paglalagay ng mga artifact na nagpapatupad ng lohika ng negosyo. Mayroong iba't ibang mga opsyon dito: sa computer ng user, sa isang intermediate machine (application server), sa isang corporate database server. Kung pupunta tayo sa huling opsyon (na sa jargon ay tinatawag na "arkitektura ng kliyente/server na may manipis na kliyente"), makukuha natin ang mga diagram na ipinapakita sa susunod na dalawang figure.

Pareho sa mga diagram na ito ay mga placement diagram, ngunit ang bawat isa ay may sariling katangian. Sa unang diagram, ang diin ay sa pagpahiwatig ng mga sulat sa pagitan ng mga bahagi at artifact, na ipinahayag sa pagkakaroon ng isang malaking bilang ng mga dependency na relasyon sa stereotype na "manifest" (tingnan, halimbawa, 1 sa unang diagram). Ipinapakita ng pangalawang diagram ang mga ugnayan sa pagitan ng mga artifact, o sa madaling salita, tinutukoy kung aling artifact ang nakasalalay kung saan, halimbawa, humihiling ng data (halimbawa, tingnan ang 1 sa pangalawang diagram). Ang parehong mga diagram ay nagpapakita ng mga compute node at ang mga relasyon sa pagitan ng mga ito (2 sa parehong mga diagram). Tandaan na may lumitaw na karagdagang artifact sa diagram - Tulong (halimbawa, 3 sa pangalawang diagram). Ito ay isang dokumento na naglalaman ng background na impormasyon.

Sa dulo ng seksyong ito, magbibigay kami ng ilang tip sa kung kailan gagamit ng component at placement diagram.

Magsimula tayo sa elementarya na pagsasaalang-alang na ipinahayag na: sa kaso ng pagbuo ng isang "monolitik" na desktop application, ang mga diagram ng layout ay hindi kinakailangan - sila ay naging walang halaga at hindi naglalaman ng anumang kapaki-pakinabang na impormasyon. Samakatuwid, ang mga placement diagram ay ginagamit lamang kapag nagmomodelo ng mga multi-component na application.

Kung ang isang application ay ibinibigay sa anyo ng isang "constructor" (isang set ng "cubes") kung saan ang isang partikular na natatanging halimbawa ng application ay binuo sa panahon ng pag-install, kung gayon ang mga placement diagram ay isang kailangang-kailangan na tool. Sa katunayan, maraming mga modernong aplikasyon, lalo na ang mga binuo na sistema ng automation ng pamamahala ng opisina ng negosyo, ay inihahatid sa anyo ng isang malaking (sampu at daan-daang) hanay ng mga artifact, kung saan ang pagsasaayos na kinakailangan ng gumagamit, kadalasang kakaiba, ay binuo "sa lugar." Inirerekomenda ng ilang awtoridad ang paggamit ng mga diagram ng layout para sa pamamahala ng pagsasaayos hindi lamang sa yugto ng paghahatid at pag-install ng software, kundi pati na rin sa proseso ng pag-develop: upang subaybayan ang mga bersyon ng bahagi, mga pagpipilian sa pagbuo, atbp.

Kapag bumubuo ng mga application na kailangang makipag-ugnayan sa tinatawag na minana(legacy) application at data, mahirap gawin nang walang mga component diagram. Ang katotohanan ay halos ang tanging tool ng UML na nagbibigay-daan sa iyong ilarawan at isama ang mga legacy na application at data sa isang modelo ay mga bahagi (at ang kanilang mga interface). Kasama rin dito ang kaso ng pagmomodelo ng access sa data mula sa isang "hindi katutubong" DBMS.

Ang huling (sa aming listahan) halimbawa ng paggamit ng mga placement diagram ay ang pagmomodelo ng mga dynamic na sistema ng arkitektura, iyon ay, mga system na nagbabago sa komposisyon at bilang ng mga pagkakataon ng kanilang mga artifact sa panahon ng pagpapatupad. ∇. Halimbawa, maraming mga web application ang nagbabago ng kanilang configuration sa runtime depende sa kasalukuyang pag-load. Ang sistema ng impormasyon ng HR ay hindi isang dynamic na sistema ng arkitektura, kaya hindi kami nagbibigay ng isang halimbawa.

∇ Pansinin muli na sa runtime ay hindi namin nakikitungo sa mga classifier mismo, ngunit sa kanilang mga pagkakataon. Ang Seksyon 3.5.4 ay nakatuon sa representasyon ng mga instance ng classifier.

Ang diagram ng UML ay isang espesyal na wika ng paglalarawan ng grapiko na idinisenyo para sa pagmomodelo ng bagay sa pagbuo ng iba't ibang software. Ang wika ay may malawak na profile at isang bukas na pamantayan na gumagamit ng iba't ibang mga graphical na notasyon upang lumikha ng abstract na modelo ng isang system. Ginawa ang UML upang paganahin ang kahulugan, visualization, dokumentasyon, at disenyo ng lahat ng uri ng software system. Kapansin-pansin na ang UML diagram mismo ay hindi isang programming language, ngunit nagbibigay ito ng posibilidad na makabuo ng hiwalay na code batay dito.

Bakit kailangan ito?

Ang paggamit ng UML ay hindi nagtatapos sa pagmomodelo ng lahat ng uri ng software. Gayundin, ang wikang ito ay aktibong ginagamit ngayon para sa pagmomodelo ng iba't ibang mga proseso ng negosyo, pagsasagawa ng disenyo ng system, at pagpapakita din ng mga istruktura ng organisasyon.

Sa UML, ang mga developer ng software ay makakapagbigay ng kumpletong kasunduan sa graphical na notation na ginamit upang kumatawan sa mga karaniwang konsepto gaya ng: component, generic, class, behavior, at aggregation. Dahil dito, nakakamit ang mas malaking antas ng konsentrasyon sa arkitektura at disenyo.

Ito ay nagkakahalaga din na tandaan na mayroong ilang mga uri ng naturang mga tsart.

Diagram ng klase

Ang diagram ng klase ng UML ay isang static na structural diagram na idinisenyo upang ilarawan ang istruktura ng isang system, pati na rin ipakita ang mga katangian, pamamaraan, at dependency sa ilang iba't ibang klase.

Ito ay nagkakahalaga ng pagpuna sa katotohanan na mayroong ilang mga punto ng pananaw sa pagtatayo ng naturang mga diagram, depende sa kung paano ito gagamitin:

• Konseptwal. Sa kasong ito, inilalarawan ng diagram ng klase ng UML ang modelo ng isang partikular na lugar ng paksa, at nagbibigay lamang ito ng mga klase ng mga object ng application.
• Tukoy. Ang diagram ay ginagamit sa proseso ng disenyo ng iba't ibang sistema ng impormasyon.
• Pagpapatupad. Kasama sa class diagram ang lahat ng uri ng klase na direktang ginagamit sa program code.

Component Diagram

Ang UML component diagram ay isang ganap na static na structure diagram. Ito ay inilaan upang ipakita ang pagkasira ng isang partikular na sistema ng software sa iba't ibang mga bahagi ng istruktura, pati na rin ang mga koneksyon sa pagitan ng mga ito. Ang isang diagram ng bahagi ng UML ay maaaring gumamit ng lahat ng uri ng mga modelo, library, file, package, executable, at marami pang ibang elemento tulad nito.

Composite/Composite Structure Diagram

Ang isang UML composite/composite structure diagram ay isa ring static na structure diagram, ngunit ito ay ginagamit upang ipakita ang panloob na istraktura ng mga klase. Kung maaari, ang diagram na ito ay maaari ding magpakita ng interaksyon ng mga elemento na matatagpuan sa panloob na istraktura ng klase.

Ang isang subtype ng mga ito ay ang UML collaboration diagram, na ginagamit upang ipakita ang mga tungkulin, pati na rin ang pakikipag-ugnayan ng iba't ibang klase sa loob ng mga hangganan ng pakikipagtulungan. Ang mga ito ay medyo maginhawa kung kailangan mong mag-modelo ng mga pattern ng disenyo.

Kapansin-pansin na ang klase ng UML at mga view ng composite structure diagram ay maaaring gamitin nang sabay-sabay.

Deployment diagram

Ginagamit ang diagram na ito upang magmodelo ng mga running node, pati na rin ang lahat ng uri ng artifact na na-deploy sa kanila. Sa UML 2, ang mga artifact ay na-deploy sa iba't ibang mga node, habang sa unang bersyon, mga bahagi lamang ang na-deploy. Kaya, ang UML deployment diagram ay pangunahing ginagamit para sa pangalawang bersyon.

Isang manifestation dependence ang nabuo sa pagitan ng artifact at ng component na ipinapatupad nito.

Diagram ng Bagay

Binibigyang-daan ka ng view na ito na makakita ng buo o bahagyang snapshot ng system na ginagawa sa isang partikular na punto ng oras. Ito ay ganap na nagpapakita ng lahat ng mga pagkakataon ng mga klase ng isang partikular na sistema, na nagpapahiwatig ng kasalukuyang mga halaga ng kanilang mga parameter, pati na rin ang mga koneksyon sa pagitan nila.

Package diagram

Ang diagram na ito ay likas na istruktura, at ang pangunahing nilalaman nito ay ang lahat ng uri ng mga pakete, pati na rin ang mga ugnayan sa pagitan ng mga ito. Sa kasong ito, walang mahigpit na dibisyon sa pagitan ng ilang mga diagram ng istruktura, bilang isang resulta kung saan ang kanilang paggamit ay madalas na matatagpuan lamang para sa kaginhawahan, at hindi nagdadala ng anumang semantikong kahulugan. Mahalagang tandaan na ang iba't ibang elemento ay maaaring magbigay ng iba pang mga diagram ng UML (mga halimbawa: mga package at mga diagram ng package mismo).

Ang kanilang paggamit ay isinasagawa upang matiyak ang samahan ng ilang mga elemento sa mga grupo ayon sa isang tiyak na pamantayan upang gawing simple ang istraktura, pati na rin upang ayusin ang trabaho sa modelo ng isang naibigay na sistema.

Diagram ng aktibidad

Ang isang diagram ng aktibidad ng UML ay naglalarawan ng pagkabulok ng isang partikular na aktibidad sa ilang bahagi ng bahagi. Sa kasong ito, ang konsepto ng "aktibidad" ay ang pagtutukoy ng isang tiyak na maipapatupad na pag-uugali sa anyo ng parallel, pati na rin ang coordinated na sunud-sunod na pagpapatupad ng iba't ibang mga subordinate na elemento - mga nested na uri ng mga aktibidad at iba't ibang mga aksyon, na pinagsama ng mga daloy mula sa mga output. ng isang tiyak na node sa mga input ng isa pa.

Ang mga diagram ng aktibidad ng UML ay kadalasang ginagamit upang magmodelo ng iba't ibang proseso ng negosyo, parallel at sequential computing. Sa iba pang mga bagay, ginagaya nila ang lahat ng uri ng mga teknolohikal na pamamaraan.

Diagram ng makina

Ang uri na ito ay tinatawag ding medyo naiiba - UML state diagram. Mayroon itong ipinakitang finite state machine na may simple at composite na mga estado, pati na rin ang mga transition.

Ang state machine ay isang detalye ng isang pagkakasunud-sunod ng iba't ibang mga estado kung saan ang isang partikular na bagay, o pakikipag-ugnayan, ay dumadaan bilang tugon sa ilang mga kaganapan sa buhay nito, pati na rin ang tugon ng bagay sa mga naturang kaganapan. Ang state machine na gumagamit ng UML state diagram ay naka-attach sa isang source element at ginagamit upang tukuyin ang gawi ng mga instance nito.

Ang tinatawag na mga diagram ng dragon ay maaaring gamitin bilang mga analogue ng naturang mga diagram.

Gamitin ang mga diagram ng kaso

Ang isang UML use case diagram ay naglalarawan sa lahat ng mga ugnayang nagaganap sa pagitan ng mga aktor pati na rin ang iba't ibang mga kaso ng paggamit. Ang pangunahing gawain nito ay ang magbigay ng isang ganap na paraan kung saan ang customer, end user o sinumang developer ay maaaring magkasamang talakayin ang pag-uugali at functionality ng isang partikular na system.

Kung ang isang UML use case diagram ay ginamit sa proseso ng pagmomodelo ng system, ang analyst ay:

• Malinaw na ihiwalay ang system na ginagaya sa kapaligiran nito.
• Kilalanin ang mga aktor, mga paraan ng kanilang pakikipag-ugnayan sa sistemang ito, pati na rin ang inaasahang paggana nito.
• Itinakda sa glossary bilang isang paksa ng iba't ibang mga konsepto na nauugnay sa isang detalyadong paglalarawan ng functionality ng isang ibinigay na system.

Kung ang isang diagram ng paggamit ay binuo sa UML, ang pamamaraan ay magsisimula sa isang paglalarawan ng teksto, na nakuha kapag nagtatrabaho sa customer. Ito ay nagkakahalaga ng pagpuna sa katotohanan na ang iba't ibang mga di-functional na mga kinakailangan ay ganap na tinanggal sa proseso ng pagguhit ng isang modelo ng kaso ng paggamit, at isang hiwalay na dokumento ay bubuo para sa kanila.

Komunikasyon

Ang isang diagram ng komunikasyon, tulad ng isang diagram ng pagkakasunud-sunod ng UML, ay palipat, ibig sabihin, ito ay nagpapahayag ng pakikipag-ugnayan, ngunit sa parehong oras ay ipinapakita ito sa iba't ibang paraan, at, kung kinakailangan, ay maaaring ma-convert mula sa isa't isa na may kinakailangang antas ng katumpakan .

Ang diagram ng komunikasyon ay sumasalamin sa mga pakikipag-ugnayan na nagaganap sa pagitan ng iba't ibang elemento ng pinagsama-samang istraktura, pati na rin ang mga tungkulin ng pakikipagtulungan. Ang pangunahing pagkakaiba sa pagitan nito at ng sequence diagram ay ginagawa nitong malinaw ang mga ugnayan sa pagitan ng ilang elemento at hindi gumagamit ng oras bilang hiwalay na dimensyon.

Ang uri na ito ay nakikilala sa pamamagitan ng isang ganap na libreng format para sa pag-aayos ng ilang mga bagay at koneksyon sa parehong paraan tulad ng ginagawa sa isang object diagram. Kung may pangangailangang panatilihin ang pagkakasunud-sunod ng mga mensahe sa libreng format na ito, ang mga ito ay binibilang nang magkakasunod. Ang pagbabasa ng diagram na ito ay nagsisimula sa paunang mensahe 1.0, at pagkatapos ay nagpapatuloy sa direksyon kung saan ang mga mensahe ay ipinadala mula sa isang bagay patungo sa isa pa.

Para sa karamihan, ang mga diagram na ito ay nagpapakita ng eksaktong parehong impormasyon na ibinibigay sa atin ng isang sequence diagram, ngunit dahil gumagamit ito ng ibang paraan ng paglalahad ng impormasyon, ang ilang mga bagay sa isang diagram ay nagiging mas madaling makilala kaysa sa iba. Dapat ding tandaan na ang isang diagram ng komunikasyon ay mas malinaw na nagpapakita kung anong mga elemento ang nakikipag-ugnayan sa bawat indibidwal na elemento, habang ang isang sequence diagram ay mas malinaw na nagpapakita sa kung anong pagkakasunud-sunod ng mga pakikipag-ugnayan.

Sequence diagram

Ang isang diagram ng pagkakasunud-sunod ng UML ay nagpapakita ng mga pakikipag-ugnayan sa pagitan ng maraming bagay na nakaayos ayon sa oras na nangyari ang mga ito. Ipinapakita ng diagram na ito ang oras-order na pakikipag-ugnayan sa pagitan ng ilang mga bagay. Sa partikular, ipinapakita nito ang lahat ng mga bagay na nakikilahok sa pakikipag-ugnayan, pati na rin ang kumpletong pagkakasunud-sunod ng mga mensaheng ipinagpapalit sa pagitan nila.

Ang mga pangunahing elemento sa kasong ito ay ang mga pagtatalaga ng iba't ibang mga bagay, pati na rin ang mga patayong linya na naglalarawan sa pagpasa ng oras at mga parihaba na kumakatawan sa aktibidad ng isang tiyak na bagay o ang pagganap ng ilang function.

Diagram ng kooperasyon

Ang ganitong uri ng diagram ay nagbibigay-daan sa iyo upang ipakita ang mga pakikipag-ugnayan sa pagitan ng ilang mga bagay, mula sa pagkakasunud-sunod ng pagsasalin ng mensahe. Ang ganitong uri ng diagram ay nagpapakita sa isang compact form na ganap na lahat ng ipinadala at natanggap na mga mensahe ng isang partikular na bagay, pati na rin ang mga format ng mga mensaheng ito.

Dahil ang mga diagram ng pagkakasunud-sunod at komunikasyon ay magkaibang mga pananaw sa parehong mga pamamaraan, ang Rational Rose ay nagbibigay ng kakayahang lumikha ng isang diagram ng komunikasyon mula sa isang diagram ng pagkakasunud-sunod o kabaligtaran, at awtomatikong isina-synchronize ang mga ito.

Pangkalahatang-ideya ng mga diagram ng pakikipag-ugnayan

Ito ay mga UML diagram na isang uri ng activity diagram at kasama ang parehong Sequence elements at control flow construct.

Ito ay nagkakahalaga ng pagpuna sa katotohanan na ang format na ito ay pinagsasama ang Collaboration at Sequence diagram, na nagbibigay ng pagkakataon na isaalang-alang ang pakikipag-ugnayan sa pagitan ng ilang mga bagay sa system na nabuo mula sa iba't ibang mga punto ng view.

Timing diagram

Kinakatawan ang isang alternatibong bersyon ng isang sequence diagram na tahasang nagpapakita ng pagbabago sa estado kasama ng isang lifeline sa isang partikular na sukat ng oras. Maaaring maging kapaki-pakinabang sa iba't ibang real-time na application.

Ano ang mga pakinabang?

Ito ay nagkakahalaga ng pagpuna sa ilang mga pakinabang na nagpapakilala sa diagram ng paggamit ng UML at iba pa:

• Ang wika ay object-oriented, bilang isang resulta kung saan ang mga teknolohiya para sa paglalarawan ng mga resulta ng pagsusuri at disenyo ay semantically malapit sa mga pamamaraan ng programming sa lahat ng uri ng modernong object-oriented na mga wika.
• Gamit ang wikang ito, maaaring ilarawan ang isang sistema mula sa halos anumang posibleng punto ng view, at ang iba't ibang aspeto ng pag-uugali nito ay inilalarawan sa parehong paraan.
• Ang lahat ng mga diagram ay medyo madaling basahin kahit na pagkatapos ng isang medyo mabilis na pagpapakilala sa syntax nito.
• Hinahayaan ka ng UML na palawakin at ipakilala din ang sarili mong mga graphic at text stereotype, na nagpo-promote ng paggamit nito hindi lamang sa software engineering.
• Ang wika ay naging lubos na kalat at medyo aktibong umuunlad.

Bahid

Sa kabila ng katotohanan na ang pagbuo ng mga diagram ng UML ay may maraming pakinabang, madalas silang pinupuna dahil sa mga sumusunod na kawalan:

• Redundancy. Sa karamihan ng mga kaso, sinasabi ng mga kritiko na ang UML ay masyadong malaki at kumplikado, at ito ay madalas na hindi makatwiran. Kabilang dito ang napakaraming kalabisan o halos walang silbi na mga disenyo at diagram, at kadalasan ang ganitong pagpuna ay nakadirekta sa pangalawang bersyon, hindi sa una, dahil ang mga bagong rebisyon ay naglalaman ng mas maraming "dinisenyo ng komite" na mga kompromiso.
• Iba't ibang kamalian sa semantika. Dahil ang UML ay tinukoy ng isang kumbinasyon ng sarili nito, English at OCL, wala itong katigasan na likas sa mga wika na tiyak na tinukoy ng mga pamamaraan ng pormal na paglalarawan. Sa ilang partikular na sitwasyon, nagsisimulang magkasalungat ang abstract syntax ng OCL, UML, at English, habang sa ibang mga kaso ay hindi kumpleto ang mga ito. Ang hindi kawastuhan sa detalye ng wika mismo ay nakakaapekto sa parehong mga user at tool vendor, na humahantong sa hindi pagkakatugma ng tool dahil sa kakaibang paraan ng pagtrato sa iba't ibang mga detalye.
• Mga problema sa proseso ng pagpapatupad at pag-aaral. Ang lahat ng isyu sa itaas ay lumilikha ng mga hamon sa pagpapatupad at pag-aaral ng UML, lalo na kapag pinipilit ng pamamahala ang mga inhinyero na gamitin ito nang walang paunang kaalaman.
• Ang code ay sumasalamin sa code. Ang isa pang opinyon ay hindi ito maganda at kaakit-akit na mga modelo na mahalaga, ngunit ang mga gumaganang sistema mismo, iyon ay, ang code ay ang proyekto. Ayon sa pananaw na ito, may pangangailangan na bumuo ng isang mas mahusay na paraan ng pagsulat ng software. Ang UML ay karaniwang pinahahalagahan sa mga diskarte na nag-compile ng mga modelo upang muling buuin ang executable o source code. Ngunit sa katotohanan, maaaring hindi ito sapat, dahil ang wika ay walang mga katangian ng pagkakumpleto ng Turing, at ang bawat code na nabuo ay sa huli ay limitado sa kung ano ang maaaring hulaan o matukoy ng UML interpreting tool.
• Mag-load ng hindi tugma. Ang terminong ito ay nagmula sa teorya ng pagsusuri ng mga sistema upang matukoy ang kawalan ng kakayahan ng input ng isang tiyak na sistema upang makita ang isa pang output. Tulad ng anumang karaniwang notasyon, ang UML ay maaaring kumatawan sa ilang mga sistema nang mas mahusay at maigsi kaysa sa iba. Kaya, ang developer ay mas hilig sa mga solusyong iyon na mas komportable sa pagsasama-sama ng lahat ng lakas ng UML, pati na rin ang iba pang mga programming language. Ang problemang ito ay mas malinaw kung ang wika ng pag-unlad ay hindi umaayon sa mga pangunahing prinsipyo ng object-oriented orthodoxy, iyon ay, hindi ito sumusubok na gumana alinsunod sa mga prinsipyo ng OOP.
• Sinusubukang maging unibersal. Ang UML ay isang general-purpose modeling language na sumusubok na maging tugma sa anumang processing language na available ngayon. Sa konteksto ng isang partikular na proyekto, upang makamit ng pangkat ng disenyo ang pangwakas na layunin, kinakailangang piliin ang mga naaangkop na tampok ng wikang iyon. Bilang karagdagan, ang mga posibleng paraan upang limitahan ang saklaw ng UML sa isang partikular na lugar ay sa pamamagitan ng isang pormalismo na hindi ganap na naipahayag at kung saan mismo ay napapailalim sa pagpuna.

Kaya, ang paggamit ng wikang ito ay hindi nauugnay sa lahat ng sitwasyon.