Ang UML ay isang pinag-isang graphical modeling language para sa paglalarawan, pag-visualize, pagdidisenyo at pagdodokumento ng mga OO system. Ang UML ay idinisenyo upang suportahan ang proseso ng pagmomodelo ng software batay sa OO na diskarte, ayusin ang ugnayan ng mga konseptong konsepto at programa, at ipakita ang mga problema ng pag-scale ng mga kumplikadong sistema. Ginagamit ang mga modelo ng UML sa lahat ng yugto ng ikot ng buhay ng software, mula sa pagsusuri sa negosyo hanggang sa pagpapanatili ng system. Maaaring gumamit ng UML ang iba't ibang organisasyon ayon sa kanilang nakikita, depende sa kanilang mga lugar ng problema at sa mga teknolohiyang ginagamit nila.

Isang Maikling Kasaysayan ng UML

Noong kalagitnaan ng dekada 90, ang iba't ibang mga may-akda ay nagmungkahi ng ilang dosenang mga pamamaraan sa pagmomodelo ng OO, na ang bawat isa ay gumagamit ng sarili nitong graphical na notasyon. Kasabay nito, ang alinman sa mga pamamaraan na ito ay may mga lakas nito, ngunit hindi pinahintulutan ang pagbuo ng isang sapat na kumpletong modelo ng PS, na ipinapakita ito "mula sa lahat ng panig," iyon ay, lahat ng kinakailangang projection (Tingnan ang artikulo 1). Bilang karagdagan, ang kakulangan ng pamantayan sa pagmomodelo ng OO ay naging mahirap para sa mga developer na pumili ng pinaka-angkop na paraan, na pumigil sa malawakang paggamit ng diskarte sa OO sa pagbuo ng software.

Sa kahilingan ng Object Management Group (OMG), ang organisasyon na responsable para sa pag-ampon ng mga pamantayan sa larangan ng mga teknolohiya ng object at database, ang kagyat na problema ng pag-iisa at standardisasyon ay nalutas ng mga may-akda ng tatlong pinakasikat na pamamaraan ng OO - G . Butch, D. Rambo at A. Jacobson, na pinagsama ang mga pagsisikap na lumikha ng bersyon ng UML 1.1, na inaprubahan ng OMG noong 1997 bilang isang pamantayan.

Ang UML ay isang wika

Ang anumang wika ay binubuo ng isang bokabularyo at mga panuntunan para sa pagsasama-sama ng mga salita upang lumikha ng mga makabuluhang konstruksyon. Ito ay, sa partikular, kung paano nakaayos ang mga programming language, tulad ng UML. Ang natatanging tampok nito ay ang diksyunaryo ng wika ay nabuo sa pamamagitan ng mga graphic na elemento. Ang bawat graphic na simbolo ay may partikular na semantika na nauugnay dito, kaya ang isang modelong ginawa ng isang developer ay malinaw na mauunawaan ng isa pa, gayundin ng isang software tool na nagbibigay-kahulugan sa UML. Mula rito, sa partikular, sumusunod na ang isang modelo ng software na ipinakita sa UML ay maaaring awtomatikong isalin sa isang OO programming language (tulad ng Java, C++, VisualBasic), iyon ay, kung mayroong isang mahusay na visual modeling tool na sumusuporta sa UML, pagkakaroon binuo ang modelo , makakatanggap din kami ng sample na program code na naaayon sa modelong ito.

Dapat bigyang-diin na ang UML ay isang wika, hindi isang pamamaraan. Ipinapaliwanag nito kung saang mga elemento ang lilikha ng mga modelo at kung paano basahin ang mga ito, ngunit walang sinasabi tungkol sa kung aling mga modelo ang dapat gawin at sa anong mga kaso. Upang lumikha ng isang paraan batay sa UML, kinakailangan upang madagdagan ito ng isang paglalarawan ng proseso ng pagbuo ng software. Ang isang halimbawa ng naturang proseso ay ang Rational Unified Process, na tatalakayin sa mga susunod na artikulo.

Diksyunaryo ng UML

Ang modelo ay kinakatawan sa anyo ng mga entity at relasyon sa pagitan nila, na ipinapakita sa mga diagram.

Mga nilalang ay mga abstraction na pangunahing elemento ng mga modelo. May apat na uri ng mga entity - structural (class, interface, component, use case, collaboration, node), behavioral (interaction, state), grouping (packages) at annotation (comments). Ang bawat uri ng entity ay may sariling graphical na representasyon. Tatalakayin nang detalyado ang mga entity kapag pinag-aaralan ang mga diagram.

Relasyon ipakita ang iba't ibang koneksyon sa pagitan ng mga entity. Ang mga sumusunod na uri ng mga relasyon ay tinukoy sa UML:

• Pagkagumon nagpapakita ng gayong koneksyon sa pagitan ng dalawang entity kapag ang pagbabago sa isa sa kanila - independiyente - ay maaaring makaapekto sa semantika ng isa pa - umaasa. Ang dependency ay inilalarawan ng isang may tuldok na arrow na nakadirekta mula sa umaasang entity patungo sa nagsasarili.
• Samahan ay isang istrukturang relasyon na nagpapakita na ang mga bagay ng isang entity ay nauugnay sa mga bagay ng isa pa. Sa graphically, ipinapakita ang isang asosasyon bilang isang linya na nagkokonekta sa mga nauugnay na entity. Ang mga asosasyon ay nagsisilbing mag-navigate sa pagitan ng mga bagay. Halimbawa, ang kaugnayan sa pagitan ng mga klase na "Order" at "Produkto" ay maaaring gamitin upang mahanap ang lahat ng produkto na tinukoy sa isang partikular na pagkakasunud-sunod, sa isang banda, o upang mahanap ang lahat ng mga order na naglalaman ng produktong ito, sa kabilang banda. Malinaw na ang kaukulang mga programa ay dapat magpatupad ng isang mekanismo na nagbibigay ng naturang nabigasyon. Kung kinakailangan ang pag-navigate sa isang direksyon, ito ay ipinapahiwatig ng isang arrow sa dulo ng asosasyon. Ang isang espesyal na kaso ng asosasyon ay pagsasama-sama - isang relasyon ng form na "buo" - "bahagi". Sa graphically, ito ay naka-highlight na may isang brilyante sa dulo malapit sa essence-buo.
• Paglalahat ay ang ugnayan sa pagitan ng parent entity at child entity. Sa esensya, ang kaugnayang ito ay sumasalamin sa pag-aari ng mana para sa mga klase at bagay. Ang generalization ay ipinapakita bilang isang linya na nagtatapos sa isang tatsulok na nakadirekta patungo sa parent entity. Ang bata ay nagmamana ng istraktura (mga katangian) at pag-uugali (mga pamamaraan) ng magulang, ngunit sa parehong oras maaari itong magkaroon ng mga bagong elemento ng istraktura at mga bagong pamamaraan. Pinapayagan ng UML ang maramihang mana, kung saan nauugnay ang isang entity sa higit sa isang parent na entity.
• Pagpapatupad– ang ugnayan sa pagitan ng isang entity na tumutukoy sa isang detalye ng pag-uugali (interface) sa isang entity na tumutukoy sa pagpapatupad ng pag-uugali na ito (klase, bahagi). Ang kaugnayang ito ay karaniwang ginagamit kapag nagmomodelo ng mga bahagi at ilalarawan nang mas detalyado sa mga susunod na artikulo.

Mga diagram. Ang UML ay nagbibigay ng mga sumusunod na diagram:

• Mga diagram na naglalarawan sa pag-uugali ng system:
• Mga diagram ng estado
• Mga diagram ng aktibidad,
• Mga diagram ng bagay,
• Sequence diagram,
• Mga diagram ng pakikipagtulungan;
• Mga diagram na naglalarawan sa pisikal na pagpapatupad ng system:
• Mga diagram ng bahagi;
• Mga diagram ng deployment.

Model Control View. Mga package.

Nasabi na namin na upang ang isang modelo ay lubos na nauunawaan ng mga tao, kinakailangan na ayusin ito sa hierarchy, na nag-iiwan ng isang maliit na bilang ng mga entity sa bawat antas ng hierarchy. Kasama sa UML ang isang paraan ng pag-aayos ng isang hierarchical na representasyon ng isang modelo - mga pakete. Ang anumang modelo ay binubuo ng isang hanay ng mga pakete na maaaring naglalaman ng mga klase, use case, at iba pang entity at diagram. Ang isang pakete ay maaaring maglaman ng iba pang mga pakete, na nagpapahintulot sa paglikha ng mga hierarchy. Ang UML ay hindi nagbibigay ng hiwalay na mga diagram ng package, ngunit maaaring lumitaw ang mga ito sa iba pang mga diagram. Ang pakete ay inilalarawan bilang isang parihaba na may isang bookmark.

Ano ang ibinibigay ng UML.

• hierarchical na paglalarawan ng isang kumplikadong sistema sa pamamagitan ng pagtukoy ng mga pakete;
• pormalisasyon ng mga kinakailangan sa pagganap para sa system gamit ang apparatus ng mga kaso ng paggamit;
• pagdedetalye ng mga kinakailangan ng system sa pamamagitan ng paggawa ng mga activity diagram at mga senaryo;
• pagkilala sa mga klase ng data at pagbuo ng isang konseptwal na modelo ng data sa anyo ng mga diagram ng klase;
• pagtukoy ng mga klase na naglalarawan sa user interface at paglikha ng isang screen navigation scheme;
• paglalarawan ng mga proseso ng pakikipag-ugnayan ng mga bagay kapag gumaganap ng mga function ng system;
• paglalarawan ng pag-uugali ng bagay sa anyo ng aktibidad at mga diagram ng estado;
• paglalarawan ng mga bahagi ng software at ang kanilang pakikipag-ugnayan sa pamamagitan ng mga interface;
• paglalarawan ng pisikal na arkitektura ng system.

At ang huling bagay...

Sa kabila ng lahat ng pagiging kaakit-akit ng UML, magiging mahirap gamitin sa tunay na pagmomodelo ng software nang walang mga visual na tool sa pagmomodelo. Binibigyang-daan ka ng mga naturang tool na mabilis na magpakita ng mga diagram sa display screen, idokumento ang mga ito, bumuo ng mga template ng program code sa iba't ibang OO programming language, at lumikha ng mga schema ng database. Karamihan sa mga ito ay kinabibilangan ng posibilidad ng reengineering program codes - pagpapanumbalik ng ilang partikular na projection ng software model sa pamamagitan ng awtomatikong pagsusuri ng source codes ng mga program, na napakahalaga upang matiyak ang pagsunod sa pagitan ng modelo at mga code at kapag nagdidisenyo ng mga system na nagmamana ng functionality ng mga naunang system.

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. Ang pagbuo ng UML ay nagsimula noong 1994 nina Grady Booch at James Rumbaugh, na nagtrabaho sa Rational Software. Noong taglagas ng 1995, sumali sa kanila si Ivar Jacobson at noong Oktubre ng taong iyon, 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 internasyonal na pamantayang katayuan:

UML 1.4.2 – "ISO/IEC 19501:2005. Information technology. Open distributed processing. Unified modelling 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. Object Management Group Unified Modeling Language (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 para sa Object Management Group (OMG UML) Part 2. Superstructure" (eng. "Information technology - Object"). Management Group Unified Modeling Language (OMG UML) - Bahagi 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 sangay 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 isang teksto.

Kaya, kaugnay ng UML, tinutukoy ng mga semantika at syntax ang istilo ng pagtatanghal (pagbuo ng modelo), 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 representasyon 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 kumbinasyon ng mga elemento ng diagram;

Explanatory (annotative) - 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 nilalang

Uri	Pangalan	Pagtatalaga	Kahulugan (semantics)
Structural	(klase)		Isang hanay ng mga bagay na nagbabahagi ng isang karaniwang istraktura at pag-uugali
	(bagay)		Isang abstraction ng isang tunay o naisip na entity na may malinaw na tinukoy na konseptong mga hangganan, personalidad, estado, at pag-uugali. Mula sa pananaw ng UML, ang mga bagay ay mga instance ng isang klase (mga instance ng isang entity)
	(artista)	Inhinyero mga serbisyo ng landas	Isang entity na nasa labas ng 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 isang aktor ay isang panlabas na mapagkukunan o tagatanggap ng impormasyon
	(use case)		Paglalarawan ng mga aksyon na ginawa ng system, na humahantong sa isang makabuluhang resulta para sa aktor
	(estado)		Isang paglalarawan ng isang sandali sa buhay ng isang entity kapag natugunan nito ang ilang kundisyon, nagsasagawa ng ilang aktibidad, o naghihintay na mangyari ang 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 upang malutas ang isang problema
Pagpapangkat	(package)		Pangkalahatang mekanismo para sa pagpapangkat ng mga elemento. Hindi tulad ng isang bahagi, ang isang pakete ay isang simpleng konsepto (abstract) na konsepto. Ang mga espesyal na kaso ng isang pakete ay sistema at modelo
	(fragment)		Ang lugar ng partikular na pakikipag-ugnayan sa pagitan ng mga pagkakataon ng aktor at mga bagay
	(activity partition)		Isang pangkat ng mga operasyon (lugar ng responsibilidad) na ginagampanan ng isang entity (aktor, bagay, bahagi, node, atbp.)
	(nagagambalang rehiyon ng aktibidad)		Isang pangkat ng mga operasyon, ang normal na pagkakasunud-sunod ng pagpapatupad na maaaring maantala bilang resulta ng paglitaw ng isang hindi pangkaraniwang sitwasyon
Paliwanag	Tandaan (komento)		Magkomento para sa elemento. Nakakabit sa nagkomento na elemento na may putol-putol na linya

Ang ilang mga pinagmumulan, lalo na ang [,], ay tumutukoy din sa mga entidad ng pag-uugali pakikipag-ugnayan At may hangganan na mga makina ng estado, ngunit mula sa isang lohikal na punto ng view ay dapat na inuri sila bilang mga diagram.

Ang ilan sa mga entity sa itaas alinsunod sa nagpapahiwatig ng kanilang detalyadong paglalarawan sa mga diagram ng decomposition. Sa top-level na diagram ay minarkahan sila ng isang espesyal na icon o label.

Ang sumusunod na talahanayan ay nagbibigay ng paglalarawan ng lahat ng 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 koneksyon sa pagitan ng dalawa o higit pang entity. Ang pinaka-pangkalahatang uri ng relasyon
Pagsasama-sama		Isang subtype ng asosasyon na naglalarawan sa "bahagi"–"buong" relasyon, kung saan ang "bahagi" ay maaaring umiral nang hiwalay sa "buo." Ang rhombus ay ipinahiwatig mula sa "buong" gilid. Tinukoy lang ang relasyon 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 nang sabay-sabay sa "buong"
Dependency		Isang relasyon sa pagitan ng dalawang entity kung saan ang pagbabago sa isang entity (ang independent) ay maaaring makaapekto sa estado o pag-uugali ng isa pang entity (ang umaasa). Ang gilid ng arrow ay nagpapahiwatig ng isang independiyenteng entity
Paglalahat		Ang ugnayan sa pagitan ng isang pangkalahatang entity (ninuno, magulang) at isang espesyal na entity (kaapu-apuhan, anak na babae). Ang tatsulok ay ipinahiwatig mula sa gilid ng magulang. Tinukoy lang ang relasyon sa pagitan ng mga entity ng parehong uri
Realization		Isang ugnayan sa pagitan ng mga entity kung saan ang isang entity ay tumutukoy sa isang aksyon na isasagawa ng isa pang entity. Ginagamit ang mga ugnayan sa dalawang sitwasyon: sa pagitan ng mga interface at mga klase (o mga bahagi), sa pagitan ng mga kaso ng paggamit at pakikipagtulungan. Ang arrow side ay nagpapahiwatig ng entity na tumutukoy sa aksyon (interface o use case)

Para sa pagsasamahan, maaaring tukuyin ang pagsasama-sama at komposisyon multiplicity (eng. 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 ipahiwatig sa mga sumusunod na paraan:

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

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

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

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

Paglilista 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 1 ang value nito. Ang multiplicity ng mga instance ng entity na kalahok sa dependency, generalization, at pagpapatupad ay palaging ipinapalagay na 1.

Ang sumusunod na talahanayan ay nagbibigay ng isang paglalarawan mga mekanismo ng pagpapalawak , ginamit upang linawin ang semantika ng mga entity at relasyon. Sa pangkalahatan, ang mekanismo ng pagpapalawak ay isang string ng teksto na nakapaloob sa mga panaklong o mga panipi.

Talahanayan 11.4. Mga Mekanismo ng Pagpapalawak

Pangalan	Pagtatalaga	Kahulugan (semantics)
Stereotype (stereotype)	« »	Ang isang pagtatalaga na tumutukoy sa mga semantiko 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 "hangganan" na stereotype ay isang boundary class)
Kondisyon ng bantay (kondisyon ng bantay)		Boolean na kundisyon (halimbawa: o [nakumpleto ang pagkakakilanlan])
Limitasyon (pagpigil)	{ }	Isang panuntunan na naglilimita sa mga semantika ng isang elemento ng modelo (halimbawa, (oras ng pagpapatupad na mas mababa sa 10 ms))
Na-flag na halaga (tag na halaga)	{ }	Bago o naglilinaw na katangian 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 graphic na stereotype ay maaaring gamitin sa mga diagram. Ang sumusunod na figure ay nagpapakita ng mga halimbawa ng standard at stereotypical display.

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

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

Diagram ay isang pagpapangkat ng mga elemento ng notasyon upang ipakita ang 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			Layunin
				ayon sa antas ng pisikal na pagpapatupad	sa pamamagitan ng pagpapakita ng dynamics	ayon sa ipinapakitang aspeto
(use case)			Ipinapakita ang mga function ng system, mga 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 mga ugnayan sa pagitan ng mga ito	Lohikal o pisikal	Static	Component
Mga ugali (pag-uugali)	(mesin ng estado)		Ipinapakita ang mga estado ng isang entity at mga paglipat sa pagitan ng mga ito sa panahon ng ikot ng buhay nito	Lohikal	Dynamic	Pag-uugali
	(aktibidad)		Ipinapakita ang mga proseso ng negosyo sa system (paglalarawan ng mga algorithm ng pag-uugali)
	Mga pakikipag-ugnayan (interaksyon)	(sequence)	Ipinapakita ang pagkakasunod-sunod ng pagpasa ng 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
Mga pagpapatupad (pagpapatupad)	(bahagi)		Nagpapakita ng mga bahagi ng system (mga programa, aklatan, talahanayan, atbp.) at mga koneksyon sa pagitan ng mga ito	Pisikal	Static	Component
	deployment		Ipinapakita ang paglalagay ng mga bahagi sa mga node ng network, pati na rin ang pagsasaayos nito

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

Object diagram - katulad, 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 isang paglalarawan ng mga klase na kasama sa kanila;

Diagram ng pangkalahatang-ideya ng pakikipag-ugnayan - katulad, ngunit may mga nakatagong mga fragment ng pakikipag-ugnayan (mga fragment na may label na ref). Kumakatawan sa isang kontekstwal (konsepto), ang mga elemento nito ay tutukuyin sa magkakahiwalay na diagram ng decomposition.

Para sa layunin ng isang pinalaki na haka-haka na representasyon ng panloob na arkitektura ng system, ang karamihan sa panahon ng pagtatayo ay nagpapahintulot sa paggamit ng mga itinatag na graphic 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 isang sistema, maraming uri ng mga diagram ang binuo. Bukod dito, kapag bumubuo ng isang modelo ng isang kumplikadong sistema, bilang panuntunan, maraming mga diagram ng parehong uri ang itinayo. Kasabay nito, hindi mo kailangang gumawa ng magkakahiwalay na uri ng mga chart kung hindi ito kinakailangan. Halimbawa, ang mga diagram at ay maaaring palitan; Ang sumusunod na talahanayan ay nagbibigay ng mga rekomendasyon sa pangangailangang bumuo (linawin) ang mga diagram para sa mga modelo ng system.

Talahanayan 11.6. Relasyon sa pagitan ng mga modelo at mga diagram

Ang talahanayan sa ibaba ay hindi nagpapakita ng modelo ng pagsubok, dahil bilang bahagi ng pagbuo nito, ang mga diagram ay hindi binuo, ngunit sinuri (nasubok) para sa pagkakumpleto at pagkakapare-pareho.

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

4. Tukuyin ang konseptong " ".

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

Ang mga entity ng modelo at relasyon mismo ay mga instance ng metamodel metaclasses.

Isinasaalang-alang ang modelo ng UML mula sa pinaka-pangkalahatang mga posisyon, maaari nating sabihin na ito ay isang graph (mas tiyak, isang load na multi-pseudo-hyper-digraph), kung saan ang mga vertice 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 mga entity, at ang mga gilid ay tinatawag na mga relasyon.. Ang natitirang bahagi ng seksyong ito ay nagbibigay ng mabilis (paunang) ngunit kumpletong pangkalahatang-ideya ng mga available na uri at relasyon ng entity. Buti na lang at hindi masyadong marami. Sa mga susunod na kabanata ng aklat, ang lahat ng entidad at relasyon ay muling susuriin, nang mas detalyado at may mga halimbawa.

1.4.1. Mga nilalang

Para sa kadalian ng pangkalahatang-ideya, ang mga entity sa UML ay maaaring hatiin sa apat na pangkat:

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

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

Bagay(object) 1 – isang entity na natatangi at sumasaklaw sa estado at pag-uugali.

Klase(klase) 2 - 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 - 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 ilang layunin.

karakter(actor) 5 – isang entity na matatagpuan sa labas ng modelong sistema at direktang nakikipag-ugnayan dito.

∇ Tiyak na umiiral ang gayong relasyon, na ipinahayag sa Fig. Hierarchy ng mga uri ng diagram para sa UML 1 bilang isang dependency na relasyon sa stereotype na "pino".

∇∇ Sa UML 1, lumitaw ang isang hindi sinasadyang pag-uugnay sa pagitan ng diagram ng pakikipagtulungan at ng entity ng parehong pangalan, na hindi ganap na totoo at minsan ay nakakapanlinlang.

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

Ang isang listahan ng mga bagong diagram at ang kanilang mga pangalan na pinagtibay sa aklat na ito ay ibinigay 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 Mga Uri ng Diagram para sa UML 2 (Bahagi 1 at 2) Isang class diagram ang ibinigay na nagpapakita ng ugnayan sa pagitan ng mga diagram sa UML 2.

Sa bandang huli sa kabanatang ito, ilalarawan natin ang lahat ng labintatlong canonical diagram upang magkaroon tayo ng ilang konteksto at bokabularyo para sa mga sumusunod. Ang mga detalye ay ibinigay 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 idisenyo. Ang isang pangkalahatang template ng pagtatanghal ng diagram 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 rektanggulo na naglilimita 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 diagram.

Ang kumplikadong hugis ng label na ito ay hindi sinusuportahan ng lahat ng mga tool. Gayunpaman, hindi ito kinakailangan, dahil pangunahin ang semantika, at pangalawa ang notasyon. Sa mga sumusunod, gumagamit kami ng isang parihaba bilang isang label ng tsart sa kabuuan, 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 iminungkahi 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 makatwiran, samakatuwid ang ikatlong hanay ng talahanayan ay naglalaman ng isang kahalili na makatwiran sa aming opinyon.

mesa Mga uri ng tsart at tag

Pamagat ng tsart	Tag (standard)	Tag (iminumungkahi)
Diagram ng paggamit	use case o uc	use case
Diagram ng klase	klase	klase
Diagram ng makina	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 tinukoy	deployment
Diagram ng bagay	hindi tinukoy	bagay
Diagram ng panloob na istraktura	klase	klase o sangkap
Diagram ng pangkalahatang-ideya ng pakikipag-ugnayan	pakikipag-ugnayan o SD	pakikipag-ugnayan
Timing diagram	pakikipag-ugnayan o SD	timing
Package diagram	pakete o pkg	pakete

Ang UML o Unified Modeling Language ay isang graphical na paglalarawan ng wika para sa object modeling sa larangan ng 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 mga proseso ng negosyo, disenyo ng system 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.

• Gumagamit ang UML ng mga graphical na notasyon para sa mga elemento ng system na inemodelo, at ang mga diagram ng UML ay medyo madaling maunawaan;
• Ginagawang posible ng UML na ilarawan ang mga system mula sa halos lahat ng posibleng 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 iyong magpasok ng mga karagdagang uri ng teksto at graphic, na ginagawang posible na gamitin ang UML hindi lamang sa larangan ng IT.

Mga Uri ng Diagram ng UML

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

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

Hierarchy ng mga uri ng diagram ng UML,
kinakatawan ng isang class diagram

Mga diagram ng istruktura

1. Diagram ng klase ay isang mahalagang elemento sa object-oriented modeling. Gamit ang diagram na ito (sa totoo lang, sa pamamagitan ng mga klase, kanilang mga katangian, pamamaraan 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 buo o bahagyang slice ng simulate system sa isang partikular na punto ng oras. Kinakatawan nito ang mga instance ng klase (mga bagay), ang kanilang estado (kasalukuyang mga halaga ng katangian), at ang mga ugnayan sa pagitan nila.
4. Composite structure diagram ipinapakita ang panloob na istruktura ng mga klase at, kung posible, 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 diagram ay nagsisilbing gawing simple ang istraktura ng modelo (at, nang naaayon, magtrabaho kasama nito) sa pamamagitan ng pagsasama-sama ng mga elemento ng modelo sa mga grupo ayon sa ilang pamantayan.
6. Deployment diagram modelo 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 nagpapahintulot sa UML na maiangkop sa iba't ibang paksa 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 ay binubuo ( aktibidad). Ang mga diagram ng aktibidad ay ginagamit upang magmodelo ng mga proseso ng negosyo, teknolohikal na proseso, sequential at parallel computing.
2. Gamitin ang diagram ng case(o use case diagram) inilalarawan ang ugnayan sa pagitan ng mga aktor (mga aktor) at mga kaso ng paggamit ng modelong sistema (mga kakayahan nito).
3. Ang pangunahing layunin ng diagram ay maging isang unibersal na tool para sa mga customer, developer, at end user na magkasamang talakayin ang system - ang mga kakayahan at gawi nito. Diagram ng estado
4. Diagram ng komunikasyon inilalarawan ang dynamic na pag-uugali 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 atom.(sa mga naunang bersyon
5. Sequence diagram diagram ng pakikipagtulungan
6. ) ay nagpapakita ng mga pakikipag-ugnayan sa pagitan ng mga bahagi ng pinagsama-samang istraktura at ang mga tungkulin ng pakikipagtulungan. Ang diagram ay tahasang nagpapahiwatig ng mga ugnayan sa pagitan ng mga elemento (mga bagay). ginagamit upang mailarawan ang 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 partikular na kaso ng paggamit, ang pagkakasunud-sunod ng mga mensaheng ipinagpapalit nila.
7. Timing diagram Diagram ng pangkalahatang-ideya ng pakikipag-ugnayan

kabilang ang bahagi ng sequence diagram at disenyo ng control flow. Tumutulong na isaalang-alang ang pakikipag-ugnayan ng mga bagay mula sa iba't ibang punto ng view.- 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 UML (Unified Modeling Language) ay isang graphical na paglalarawan ng wika para sa object modeling sa larangan ng software development. Ang UML ay isang pangkalahatang wika, isang bukas na pamantayan na gumagamit ng graphical na notasyon upang lumikha ng abstract na modelo ng isang system, na tinatawag na modelo ng UML. Ginawa ang UML upang tukuyin, mailarawan, idisenyo, at idokumento lalo na ang mga software system. Ang UML ay hindi isang programming language, ngunit ang pagbuo ng code ay posible sa mga paraan para sa pagpapatupad ng mga modelo ng UML bilang interpreted code.

Wikipedia

Mga Komersyal na Produkto

Microsoft Visio

Uri: komersyal na software

Isang sikat na produkto ng software mula sa Microsoft na nagbibigay-daan sa iyong gumuhit ng mga rich diagram, kabilang ang UML: ay isang libreng programa na nagbibigay-daan sa iyong tingnan ang mga naunang ginawang Visio diagram. Maaari kang mag-download sa %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Pagmomodelo,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sequence%20Diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Gumamit ng%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualization%20and%20Modeling%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A

• %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
%0A
• %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrams%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagrams
%0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualization%20and%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/ru-ru/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Mga posibilidad:

• Gamitin ang diagram ng kaso;
• Deployment diagram (topology diagram);
• diagram ng statechart;
• Diagram ng aktibidad;
• Diagram ng pakikipag-ugnayan;
• Sequence diagram;
• Diagram ng pakikipagtulungan;
• Diagram ng klase;
• Component diagram.

Mga screenshot:

Mga open source na programa

StarUML

Mga posibilidad:

• Suporta sa UML 2.0
• MDA (Model Driven Architecture)
• Plug-in Architecture (maaari kang sumulat sa mga COM compatible na wika: C++, Delphi, C#, VB, ...)

Ang StarUML ay pangunahing nakasulat sa Delphi, ngunit ang mga bahagi ay maaari ding isulat sa ibang mga wika, halimbawa C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Nasa ibaba ang ilang mga screenshot.

Class diagram:

Gamitin ang diagram ng case:

ArgoUML

Mga sinusuportahang chart:

• Klase
• Estado
• Use case
• Aktibidad
• Pakikipagtulungan
• Deployment
• Pagkakasunod-sunod

Mga posibilidad:

• Sinusuportahan ang siyam na UML 1.4 diagram
• Independiyenteng platform (Java 5+)
• UML 1.4 Standard Metamodel
• Suporta sa XMI
• I-export sa GIF, PNG, PS, EPS, PGML at SVG
• Mga Wika: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
• Suporta sa OCL
• Pasulong, Reverse Engineering

Screenshot: