Mga diagram ng simulation. Mga pangunahing diagram ng UML. Pangkalahatang-ideya ng mga chart ng pakikipag-ugnayan

Modelo ng UML(modelo ng UML) ay isang koleksyon ng isang may hangganang hanay ng mga construct ng wika, na ang pangunahing ay mga entity at relasyon sa pagitan nila.

Ang mga entity at relasyon mismo ng modelo ay mga pagkakataon ng meta-class ng metamodel.

Isinasaalang-alang ang modelo ng UML mula sa pinaka-pangkalahatang pananaw, maaari nating sabihin na ito ay isang graph (mas tiyak, isang load na multi-pseudo-hyper-digraph), kung saan ang mga vertices at mga gilid ay puno ng karagdagang impormasyon at maaaring magkaroon ng isang kumplikadong panloob na istraktura. Ang mga vertice ng graph na ito ay tinatawag na entity, at ang mga gilid ay mga relasyon... Ang natitirang bahagi ng seksyong ito ay nagbibigay ng mabilis (paunang) ngunit kumpletong pangkalahatang-ideya ng mga uri ng entity at mga ugnayang magagamit. Buti na lang at hindi masyadong marami. Sa mga susunod na kabanata ng aklat, ang lahat ng entidad at relasyon ay muling isasaalang-alang, nang mas detalyado at may mga halimbawa.

1.4.1. Mga entidad

Para sa kadalian ng pagtingin, ang mga entity sa UML ay maaaring hatiin sa apat na grupo:

• istruktura;
• pag-uugali;
• pagpapangkat;
• annotation.

Ang mga istrukturang entity, gaya ng maaari mong hulaan, ay nilalayong ilarawan ang istraktura. Kadalasan, kasama sa mga istrukturang entidad ang sumusunod.

Isang bagay(object) 1 ay isang entity na natatangi at sumasaklaw sa estado at pag-uugali.

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

Interface(interface) 3 ay isang pinangalanang hanay ng mga operasyon na tumutukoy sa isang hanay ng mga serbisyo na maaaring hilingin ng isang consumer at ibigay ng isang service provider.

Pagtutulungan(collaboration) 4 - isang koleksyon ng mga bagay na nakikipag-ugnayan upang makamit ang isang layunin.

Aktor(actor) 5 ay isang entity na nasa labas ng modelong sistema at direktang nakikipag-ugnayan dito.

∇ Ang ganitong relasyon ay tiyak na umiiral, na ipinahayag sa Fig. Hierarchy ng uri ng diagram para sa UML 1 bilang isang dependency na relasyon sa isang pinong stereotype.

∇∇ Sa UML 1, nagkaroon ng hindi sinasadyang pagkakaugnay sa pagitan ng diagram ng pakikipagtulungan at ng entity ng parehong pangalan, na hindi ganap na totoo at kung minsan ay nakakapanlinlang.

∇∇∇ Sa UML 2, ang syntactic at semantic load ng state diagram ay nagbago nang husto na ang pangalan ay hindi na sumasalamin sa nilalaman.

Ang isang listahan ng mga bagong chart at ang kanilang mga pangalan na ginamit sa aklat na ito ay ipinapakita sa ibaba.

• Diagram ng Composite Structure
• Package diagram
• Diagram ng makina ng estado
• Diagram ng komunikasyon
• Diagram ng Pangkalahatang-ideya ng Pakikipag-ugnayan
• Timing diagram

Sa fig. Hierarchy ng Uri ng Diagram para sa UML 2 (Bahagi 1 at 2) ay isang class diagram na nagpapakita ng relasyon ng mga diagram sa UML 2.

Sa bandang huli ng kabanatang ito, maikli nating ilalarawan ang lahat ng labintatlong kanonikal na diagram upang magkaroon ng tiyak na konteksto at bokabularyo para sa presentasyon sa ibang pagkakataon. Ang mga detalye ay nakalagay sa natitirang mga kabanata ng aklat.

Ngunit bago lumipat sa susunod na seksyon, gumawa tayo ng isang maliit na digression tungkol sa kung paano ang pamantayan ay nangangailangan ng mga diagram upang ma-format. Ang pangkalahatang template ng presentasyon ng tsart ay ipinapakita sa ibaba.

Mayroong dalawang pangunahing elemento ng disenyo: isang panlabas na frame at isang label na may pangalan ng diagram. Kung ang lahat ay simple sa frame - ito ay isang parihaba na nagbubuklod sa lugar kung saan dapat matatagpuan ang mga elemento ng diagram, kung gayon ang pangalan ng diagram ay nakasulat sa isang espesyal na format, na ipinapakita sa Fig. Notasyon para sa mga chart.

Ang ipinahiwatig na kumplikadong hugis ng tab ay hindi sinusuportahan ng lahat ng mga tool. Gayunpaman, hindi ito kinakailangan, dahil pangunahin ang semantika at pangalawa ang notasyon. Mula ngayon, gagamit kami ng isang parihaba bilang isang label para sa buong diagram, at hindi ito dapat magdulot ng anumang pagkalito.

Ang mga posibleng tag (uri) para sa mga chart ay ipinapakita sa sumusunod na talahanayan. Ang mga tag na inaalok ng pamantayan ay nakasulat sa ikalawang hanay. Gayunpaman, tulad ng ipinakita ng kasanayan, ang mga patakaran na iminungkahi ng pamantayan ay hindi palaging maginhawa at lohikal na pinagbabatayan, samakatuwid ang ikatlong hanay ng talahanayan ay naglalaman ng isang makatwirang alternatibo, sa aming opinyon.

Tab. Mga uri ng tsart at tag

Pamagat ng tsart	Tag (standard)	Tag (iminumungkahi)
Diagram ng paggamit	kaso ng paggamit o uc	kaso ng paggamit
Class diagram	klase	klase
Automaton diagram	makina ng estado o stm	makina ng estado
Diagram ng aktibidad	aktibidad o kumilos	aktibidad
Sequence diagram	pakikipag-ugnayan o sd	sd
Diagram ng komunikasyon	pakikipag-ugnayan o sd	comm
Component diagram	sangkap o cmp	sangkap
Diagram ng pagkakalagay	hindi natukoy	deployment
Diagram ng bagay	hindi natukoy	bagay
Diagram ng panloob na istraktura	klase	klase o sangkap
Diagram ng pangkalahatang-ideya ng pakikipag-ugnayan	pakikipag-ugnayan o sd	pakikipag-ugnayan
Diagram ng pag-synchronize	pakikipag-ugnayan o sd	timing
Package diagram	pakete o pkg	pakete

11.1. Istruktura ng Pinag-isang Wika ng Pagmomodelo

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

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

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

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

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

kanin. 11.1. Istruktura ng UML

11.2. UML semantics at syntax

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

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

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

11.3. UML notation

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

Tinutukoy ng UML ang tatlo uri ng entidad :

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

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

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

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

Talahanayan 11.1. Mga entidad

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

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

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

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

Talahanayan 11.3. Relasyon

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

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

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

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

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

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

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

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

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

Talahanayan 11.4. Mga mekanismo ng extension

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

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

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

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

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

Talahanayan 11.5. Mga diagram

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

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

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

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

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

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

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

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

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

Talahanayan 11.6. Pag-uugnay ng mga Modelo at Diagram

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

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

4. Magbigay ng kahulugan sa konseptong "".

Ang UML o Unified Modeling Language ay isang graphical na paglalarawan ng wika para sa object modeling sa software development. Ngunit ang paggamit ng UML ay hindi limitado sa IT, ang isa pang malaking lugar ng praktikal na aplikasyon ng UML ay ang pagmomodelo ng proseso ng negosyo, system engineering at pagmamapa ng mga istruktura ng organisasyon. Ang UML ay nagbibigay-daan sa mga developer ng software na sumang-ayon sa mga graphical na notasyon upang kumatawan sa mga karaniwang konsepto at tumuon sa disenyo at pag-unlad.

Mga kalamangan ng UML

• Gumagamit ang UML ng mga graphical na simbolo para sa mga elemento ng system na inemodelo, at ang mga diagram ng UML ay sapat na simple upang maunawaan;
• Ginagawang posible ng UML na ilarawan ang mga system mula sa halos lahat ng naiisip na punto ng view, na isinasaalang-alang ang iba't ibang aspeto;
• Ang UML ay object-oriented: ang mga paraan ng pagsusuri at pagbuo nito ay semantically malapit sa mga pamamaraan ng programming na ginagamit sa modernong mga wika ng OOP;
• Ang UML ay isang bukas na pamantayan. Ang pamantayan ay bubuo at nagbabago mula sa bersyon hanggang sa bersyon, na nakakatugon sa mga pinakamodernong kinakailangan para sa paglalarawan ng mga system;
• naglalaman ng mekanismo ng extension na nagbibigay-daan sa pagpapakilala ng mga karagdagang uri ng teksto at graphic, na ginagawang posible na gamitin ang UML hindi lamang sa larangan ng IT.

Mga Uri ng UML Diagram

Mayroong 14 na uri ng mga diagram sa UML. Maaari silang nahahati sa 2 kategorya:

• istruktural kumakatawan sa istraktura ng impormasyon;
• pag-uugali kumakatawan sa pag-uugali ng system at iba't ibang aspeto ng pakikipag-ugnayan. Ang isang hiwalay na subspecies ng mga diagram ng pag-uugali ay isinasaalang-alang mga diagram ng pakikipag-ugnayan.

UML diagram type hierarchy,
kinakatawan ng class diagram

Mga istrukturang diagram

1. Class diagram ay isang pangunahing elemento sa object-oriented na pagmomodelo. Sa tulong ng diagram na ito (sa katunayan, sa pamamagitan ng mga klase, kanilang mga katangian, paraan at mga dependency sa pagitan ng mga klase) ay naglalarawan sa modelo ng domain at sa istruktura ng namodelong sistema.
2. Component diagram ipinapakita ang breakdown ng program code sa malalaking bloke (structural component) at mga palabas dependencies sa pagitan nila. Ang mga bahagi ay maaaring mga pakete, module, library, file, atbp.
3. Diagram ng bagay nagpapakita ng kumpleto o bahagyang hiwa ng namodelong sistema sa isang partikular na sandali sa oras. Kinakatawan nito ang mga instance ng klase (mga bagay), ang kanilang estado (kasalukuyang mga halaga ng katangian) at mga relasyon sa pagitan nila.
4. Composite structure diagram ipinapakita ang panloob na istruktura ng mga klase at, kung maaari, ang mga pakikipag-ugnayan sa pagitan ng mga elemento ng istrukturang ito.
5. Package diagram nagpapakita ng mga pakete at relasyon sa pagitan nila. Ang ganitong uri ng mga diagram ay nagsisilbing pasimplehin ang istraktura ng modelo (at, nang naaayon, upang gumana dito) sa pamamagitan ng pagsasama-sama ng mga elemento ng modelo sa mga grupo ayon sa ilang pamantayan.
6. Deployment diagram ginagaya ang deployment ng mga bahagi ng software ( mga artifact) sa computing resources / mga bahagi ng hardware ( mga node).
7. Diagram ng profile naglalarawan ng mekanismo ng extension na nagbibigay-daan sa UML na maiangkop sa iba't ibang domain at industriya.

Halimbawa ng UML Class Diagram

Mga diagram ng pag-uugali

1. Diagram ng aktibidad nagpapakita ng mga aksyon ( mga aksyon) kung saan ang ilang aktibidad ( aktibidad). Ginagamit ang mga activity diagram upang magmodelo ng mga proseso ng negosyo, mga daloy ng trabaho, sequential at parallel computing.
2. Gamitin ang diagram ng case(o use case diagram) inilalarawan ang ugnayan sa pagitan ng mga aktor (mga karakter) at ang mga kaso ng paggamit ng modelong sistema (mga kakayahan nito). Ang pangunahing layunin ng isang diagram ay maging isang one-stop-shop para sa mga customer, developer, at end user na magkatuwang na talakayin ang isang system — ang mga kakayahan at gawi nito.
3. Diagram ng estado inilalarawan ang dynamic na gawi ng isang entity, na nagpapakita kung paano tumutugon ang entity na ito, depende sa kasalukuyang estado nito, sa iba't ibang mga kaganapan. Ito ay mahalagang diagram ng estado mula sa teorya ng mga atomo.
4. Diagram ng komunikasyon(sa mga naunang bersyon diagram ng pakikipagtulungan) ay nagpapakita ng mga pakikipag-ugnayan sa pagitan ng mga bahagi ng pinagsama-samang istraktura at ang mga tungkulin ng pakikipagtulungan. Ang diagram ay malinaw na nagpapahiwatig ng relasyon sa pagitan ng mga elemento (mga bagay).
5. Sequence diagram ginagamit upang mailarawan ang isang pagkakasunud-sunod ng mga pakikipag-ugnayan ng bagay. Ipinapakita ang ikot ng buhay ng isang partikular na bagay at ang pakikipag-ugnayan ng mga aktor (mga aktor) sa loob ng isang use case, ang pagkakasunud-sunod ng mga mensaheng ipinagpapalit nila.
6. Chart ng pangkalahatang-ideya ng pakikipag-ugnayan may kasamang bahagi ng sequence diagram at control flow constructs. Tumutulong na isaalang-alang ang pakikipag-ugnayan ng mga bagay mula sa iba't ibang mga punto ng view.
7. Diagram ng pag-synchronize- isang hiwalay na subtype ng mga diagram ng pakikipag-ugnayan, na dalubhasa sa timing. Ang mga diagram ng ganitong uri ay ginagamit upang pag-aralan ang pag-uugali ng mga bagay sa isang tiyak na tagal ng panahon.

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

1.5.1. Diagram ng paggamit

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

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

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

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

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

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

1.5.2. Class diagram

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

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

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

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

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

1.5.3. Automaton diagram

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

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

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

Ang isang detalyadong paglalarawan ng lahat ng mga pagkakaiba-iba ng mga diagram ng automat ay ibinibigay sa seksyon 4.2, at ang sumusunod na figure ay nagpapakita lamang ng mga pangunahing elemento ng notasyon na ginamit sa automaton diagram.

1.5.4. Diagram ng aktibidad

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

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

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

1.5.5. Sequence diagram

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

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

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

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

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

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

1.5.6. Diagram ng komunikasyon

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

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

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

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

1.5.7. Component diagram

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

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

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

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

1.5.8. Diagram ng pagkakalagay

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

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

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

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

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

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

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

Mga diagram ng pag-uugali

· Mga diagram ng pakikipag-ugnayan;

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

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

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

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

Mga diagram ng pagpapatupad:

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

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

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

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

4.2. Gamitin ang diagram ng case

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

Larawan 2. Use case

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

Larawan 3. aktor (aktor)

Mayroong tatlong pangunahing uri ng mga aktor:

· Mga gumagamit;

· Mga sistema;

· Iba pang mga sistema na nakikipag-ugnayan dito;

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

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

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

komunikasyon,

Pagsasama (isama),

Extension (extend),

Paglalahat.

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

Larawan 4. Halimbawa ng link ng komunikasyon

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

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

Larawan 5. Halimbawa ng koneksyon ng pagsasama at pagpapalawig

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

Larawan 6. Halimbawa ng link ng generalization

4.3.

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

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

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

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

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

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

4.3.1. Mga diagram ng pagkakasunud-sunod

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

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

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

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

kanin. 7. Halimbawa ng sequence diagram

4.3.2. Diagram ng pakikipagtulungan

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

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

kanin. 8. Halimbawa ng diagram ng kooperasyon

4.4. Class diagram

4.4.1. Pangkalahatang Impormasyon

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

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

Inilalarawan ng class diagram ang mga sumusunod na elemento:

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

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

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

4.4.2. Klase

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

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

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

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

Ang gitnang seksyon ay naglalaman ng isang listahan ng mga katangian

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

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

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

kanin. 9. Halimbawang class diagram

4.4.2.1.Mga stereotype ng klase

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

Mayroong tatlong pangunahing stereotype ng klase na tinukoy sa UML:

Hangganan

Entidad

Kontrolin.

4.4.2.2.Mga Boundary Class

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

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

4.4.2.3.Mga klase ng entity

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

4.4.2.4.Mga Klase ng Kontrol

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

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

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

4.4.2.5.Mga Katangian

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

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

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

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

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

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

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

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

4.4.2.6.Mga operasyon

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

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

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

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

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

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

Mga operasyon sa pagpapatupad;

Kontrolin ang mga operasyon;

Mga operasyon sa pag-access;

Mga pantulong na operasyon.

Mga operasyon sa pagpapatupad

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

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

Kontrolin ang mga operasyon

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

I-access ang mga operasyon

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

Mga pantulong na operasyon

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

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

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

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

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

4.4.2.7.Mga koneksyon

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

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

Samahan ng komunikasyon

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

kanin. 10. Samahan ng komunikasyon

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

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

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

Pagkagumon sa komunikasyon

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

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

kanin. 11. Pagkagumon sa komunikasyon

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

Pagsasama-sama ng link

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

kanin. 11. Pagsasama-sama ng komunikasyon

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

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