5.4. Objektdiagram Essential: Objekt och deras relationer Ett objektdiagram visar befintliga objekt och deras relationer i den logiska designen av ett system. Med andra ord är ett objektdiagram en ögonblicksbild av flödet av händelser i någon konfiguration

5.7. Processdiagram. Viktigt: Processorer, enheter och anslutningar Processdiagram används för att visa fördelningen av processer över processorer i en fysisk systemdesign. Ett separat processdiagram visar en vy av processstrukturen

10.4. UML-DIAGRAM 10.4.1. Typer av visuella diagram UMLUML låter dig skapa flera typer av visuella diagram: använd falldiagram; sekvensdiagram; kooperativa diagram; klassdiagram; tillståndsdiagram; diagram

1.2.6. Diagramram I fig. Figur 1.2.26 visar ett typiskt exempel på ett nedbrytningsdiagram med begränsningsrutor som kallas diagramramen. Ris. 1.2.26. Exempel på ett nedbrytningsdiagram med en trådram. Trådramen innehåller en titel ( övre del ramar) och källare (nedre delen).

Tidsdiagram För att erhålla tidsdiagram för in- och utgångsspänningarna måste du ändra ingångsfilen något. Som i föregående exempel kommer en sinusformad inspänning att användas: Vi 1 0 sin (0 0, 5V 5kHz) Tillsammans med transientanalys

Diagram och grafer Endast en expert kan urskilja innebörden bakom ändlösa rader av siffror, men vem som helst kan förstå (eller åtminstone påstå sig förstå) ett histogram eller ett cirkeldiagram. VBA har inga inbyggda verktyg för att skapa diagram, men sådana

5.1.14. Diagram Diagram är grafiska representationer av numeriska data i en tabell. Pages erbjuder flera typer av diagram: kolumn, staplad kolumn, stapeldiagram, staplad stapeldiagram, linje, area, staplad area

5.2.8. Diagram Ett diagram är en grafisk representation av data från ett valt område. För att bygga ett diagram, följ följande algoritm1. Skapa en tabell med beräknade värden.2. Välj önskat område (det kan bestå av icke-intilliggande rektangulära

Vad är UML?

Om du tittar på bilderna i sökmotorer, då blir det klart att UML– det är något med diagram, pilar och rutor. Det som är viktigt är att UML översätts som Unified Modeling Language. Ordet Unified är viktigt här. Det vill säga att våra bilder kommer att förstås inte bara av oss, utan också av andra som kan UML. Det visar sig att detta är ett internationellt språk för att rita diagram.

Som Wikipedia säger

UML är ett grafiskt beskrivningsspråk för objektmodellering inom mjukvaruutveckling, affärsprocessmodellering, systemdesign och visning av organisationsstrukturer.

Ansökan

Men tänk om du vill rita det själv, och även om du inte gör det Ultimat version Aning? Om vi ​​använder IntelliJ Idea Community Edition har vi inget annat val. För att göra detta måste du förstå hur ett sådant UML-diagram är uppbyggt. Först måste vi installera Graphviz. Detta är en uppsättning verktyg för att visualisera grafer. Det används av plugin som vi kommer att använda. Efter installationen måste du lägga till en katalog bin från den installerade katalogen Graphviz till miljövariabeln VÄG. Efter det, i IntelliJ Idea, välj Arkiv -> Inställningar från menyn. I fönstret "Inställningar", välj kategorin "Plugins", klicka på knappen "Bläddra i arkiv" och installera PlantUML-integrationsplugin. Varför är den här så bra? PlantUML? Den använder ett grafbeskrivningsspråk som heter " punkt"och detta gör att det kan vara mer universellt, eftersom... givet språk Inte bara PlantUML används. Dessutom kan allt vi gör nedan göras inte bara i IDE, utan också i onlinetjänst planttext.com. Efter att ha installerat PlantUML-pluginen kommer vi att kunna skapa UML-diagram genom "File" -> "New". Låt oss skapa ett diagram av typen "UML-klass". Under denna process genereras automatiskt en mall med ett exempel. Låt oss ta bort innehållet och skapa vårt eget, beväpnat med en artikel från Habr: Klassrelationer - från UML till kod. Och för att förstå hur man skildrar detta i texten, låt oss ta PlantUML-manualen: plantuml class-diagram. Allra i början finns en tabell som visar hur anslutningar ska beskrivas:

Vi kan också titta på själva sambanden här: "Relationer mellan klasser i UML. Exempel." Baserat på dessa material, låt oss börja skapa vårt UML-diagram. Låt oss lägga till följande innehåll som beskriver de två klasserna: @startuml class ArrayList ( ) class LinkedList ( ) @enduml För att se resultatet i Idea, välj "Visa" -> " Verktyg Windows" -> "PlantUML". Vi får helt enkelt två rutor som betecknar klasser. Som vi vet implementerar båda dessa klasser List-gränssnittet. Denna klassrelation kallas implementering. För att avbilda en sådan relation, använd en pil med prickad linje. Låt oss skildra det: gränssnitt List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о paket privat array av element: ~ Object elementData Nu vill vi visa att ArrayList innehåller några objekt. I det här fallet kommer anslutningstypen att vara - aggregering(aggregation). Aggregatet i det här fallet är ArrayList, eftersom den innehåller andra objekt. Vi väljer aggregering eftersom objekt i listan kan leva utan listan: de är inte integrerade delar av den. Deras livstid är inte bunden till listans livstid. Aggregat översätts från latin som "sammansatt", det vill säga något som består av något. Till exempel, i livet, finns det en pumpenhet, som består av en pump och en motor. Själva enheten kan demonteras och lämnar en del kvar komponenter. Till exempel att sälja eller lägga in i en annan enhet. Så är listan. Och detta uttrycks i form av en tom diamant nära enheten och en kontinuerlig linje. Låt oss skildra det så här: class Object ( ) ArrayList o- Object Nu vill vi visa att, till skillnad från ArrayList, innehåller LinkedList-klassen Node - behållare som refererar till lagrad data. I det här fallet är noder en del av själva LinkedList och kan inte leva separat. Node lagrar inte innehållet direkt, utan innehåller bara en länk till det. Till exempel, när vi lägger till en rad i en länkad lista, lägger vi till en ny nod som innehåller en länk till den raden, såväl som en länk till föregående och nästa nod. Denna typ av anslutning kallas sammansättning(Sammansättning). För att visa en komposit (en som består av delar) ritas en färgad diamant, med en kontinuerlig linje som leder till den. Låt oss nu skriva detta i form av en textvisning av anslutningen: class Node ( ) LinkedList * -- Node Och nu måste vi lära oss hur man visar en annan viktig typ kommunikation - missbruk(beroendeförhållande). Den används när en klass använder en annan och klassen inte innehåller klassen som används och är inte dess avkomling. Till exempel kan LinkedList och ArrayList skapa en ListIterator. Låt oss visa detta som pilar med en prickad linje: klass ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Du kan gå in på så mycket detaljer som behövs. Alla beteckningar anges här: "PlantUML - Klassdiagram". Dessutom finns det inget övernaturligt i att rita ett sådant diagram, och när du arbetar med dina uppgifter kan du snabbt rita det för hand. Detta kommer att utveckla dina färdigheter i att tänka igenom applikationsarkitektur och hjälpa dig att identifiera klassstrukturfel tidigt, snarare än efter att du har ägnat dagen åt att implementera fel modell. Jag tror att det är en bra anledning att prova?)

Automatisering

Eftersom Maven inte är i fokus i den här artikeln kan svar på dina Maven-frågor hittas i Maven Users Center. I det genererade projektet öppnar du projektbeskrivningsfilen för redigering, pom.xml. Låt oss kopiera innehållet från beskrivningen av uml-java-docklet som installeras i den. Artefakten som användes i beskrivningen kunde inte hittas i Maven Central-förvaret. Men det fungerade för mig med detta: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Det vill säga, du behöver bara byta ut i den beskrivningen grupp-ID Med " info.leadinglight"på" com.chfourie"och installera versionen" 1.0.0 ". Efter detta kan vi köra i katalogen där filen finns pom.xml dessa kommandon: mvn clean install och mvn javadoc:javadoc . Om vi ​​nu öppnar den genererade dokumentationen (explorer target\site\apidocs\index.html), kommer vi att se UML-diagrammen. Förresten, implementeringen visas redan korrekt här)

Slutsats

Anteckning: Ämnet för denna kurs är The UML - the Unified Modeling Language. Förra föreläsningen talade om vad UML är, dess historia, syfte, sätt att använda språket, strukturen på dess definition, terminologi och notation. Det har noterats att en UML-modell är en uppsättning diagram. I denna föreläsning kommer vi att överväga följande frågor: varför behövs flera typer av diagram; typer av diagram; OOP och diagramsekvens

Innan vi går vidare till att diskutera huvudmaterialet i denna föreläsning, låt oss prata om varför vi behöver bygga några diagram överhuvudtaget. Utvecklingen av en modell av vilket system som helst (inte bara programvara) föregår alltid skapandet eller uppdateringen. Detta är nödvändigt åtminstone för att tydligare föreställa sig att problemet löses. Genomtänkta modeller är mycket viktiga både för interaktion inom utvecklingsteamet och för ömsesidig förståelse med kunden. I slutändan säkerställer detta att designen är "arkitektoniskt konsekvent" innan den implementeras i kod.

Vi bygger modeller av komplexa system eftersom vi inte kan beskriva dem helt, "ta en blick på dem." Därför lyfter vi bara fram de egenskaper hos systemet som är väsentliga för en specifik uppgift och bygger dess modell som visar dessa egenskaper. Metoden för objektorienterad analys gör att vi kan beskriva verkliga komplexa system på det mest adekvata sättet. Men i takt med att systemens komplexitet ökar uppstår behovet av bra modelleringsteknik. Som vi redan sa i föregående föreläsning, en enhetlig modelleringsspråk(Unified Modeling Language, UML), som är ett grafiskt språk för att specificera, visualisera, designa och dokumentera system. Med hjälp av UML kan du utveckla en detaljerad modell av systemet som skapas, som inte bara speglar dess koncept utan också specifika egenskaper för dess implementering. Inom UML-modellen registreras alla idéer om systemet i form av speciella grafiska strukturer som kallas diagram.

Notera. Vi kommer inte att överväga alla, utan bara några av typerna av diagram. Till exempel behandlas inte komponentdiagrammet i denna föreläsning, vilket endast är det en kort översikt typer av diagram. Antal diagramtyper för specifik modell applikationer är inte begränsade på något sätt. För enkla applikationer det finns inget behov av att bygga diagram av alla typer utan undantag. Vissa av dem kan helt enkelt saknas, och detta faktum kommer inte att betraktas som ett fel. Det är viktigt att förstå att tillgängligheten för vissa typer av diagram beror på detaljerna i ett visst projekt. Information om andra typer av diagram (som inte diskuteras här) finns i UML-standarden.

Varför du behöver flera typer av diagram

Låt oss först definiera terminologin. I inledningen till denna föreläsning har vi upprepade gånger använt begreppen system, modell och diagram. Författaren är säker på att var och en av oss intuitivt förstår innebörden av dessa begrepp, men för att göra det helt klart, låt oss titta på ordlistan igen och läsa följande:

Systemet- En uppsättning sammankopplade kontrollerade delsystem förenade av ett gemensamt driftsyfte.

Ja, inte särskilt informativt. Vad är då ett delsystem? För att klargöra situationen, låt oss vända oss till klassikerna:

Systemet hänvisar till en uppsättning delsystem organiserade för att uppnå ett specifikt mål och beskrivna med hjälp av en uppsättning modeller, möjligen från olika synvinklar.

Tja, det finns inget du kan göra, du måste leta efter en definition av ett delsystem. Där står det också delsystemär en samling element, av vilka några specificerar beteendet hos andra element. Ian Sommerville förklarar detta koncept så här:

Delsystemär ett system vars funktion inte är beroende av andra delsystems tjänster. Mjukvarusystemet är uppbyggt som en samling relativt oberoende delsystem. Samspelet mellan delsystem definieras också.

Det är inte heller särskilt tydligt, men det är bättre. På ett ”mänskligt” språk representeras systemet som en uppsättning enklare enheter som är relativt självförsörjande. Detta kan jämföras med hur vi i färd med att utveckla ett program bygger GUI från vanliga "kuber" - visuella komponenter, eller hur själva programtexten också är uppdelad i moduler som innehåller subrutiner, förenade av funktionalitet, och de kan återanvändas i efterföljande program.

Vi förstår konceptet med ett system. Under designprocessen beaktas systemet ur olika synvinklar med hjälp av modeller, vars olika representationer framträder i form av diagram. Återigen kan läsaren ha frågor om innebörden av begreppen modeller Och diagram. Vi tycker att det är en vacker, men inte särskilt tydlig definition modeller som en semantiskt sluten abstraktion av systemet Det är osannolikt att klargöra situationen, så vi ska försöka förklara "med våra egna ord."

Modell- detta är ett visst (materiellt eller inte) objekt som endast uppvisar de viktigaste egenskaperna hos systemet för en given uppgift. Modeller är olika - material och immateriella, konstgjorda och naturliga, dekorativa och matematiska...

Låt oss ge några exempel. De plastleksaksbilar som vi alla känner till, som vi lekte med sådan spänning i barndomen, är inget annat än material konstgjord dekorativ modell av en riktig bil. Naturligtvis har en sådan "bil" ingen motor, vi fyller inte tanken med bensin och växellådan fungerar inte (det finns faktiskt ingen växellåda alls), men som modell uppfyller denna leksak helt sina funktioner : det ger barnet en uppfattning om bilen, eftersom den visar sina karakteristiska egenskaper är närvaron av fyra hjul, en kaross, dörrar, fönster, förmåga att köra, etc.

Inom medicinsk forskning föregår djurförsök ofta kliniska prövningar på människor. I det här fallet fungerar djuret som naturligt material mänskliga modeller.

Ekvationen som avbildas ovan är också en modell, men det är en matematisk modell, och den beskriver rörelsen av en materiell punkt under påverkan av gravitationen.

Allt som återstår är att säga vad ett diagram är. Diagramär en grafisk representation av många element. Avbildas vanligtvis som en graf med hörn (entiteter) och kanter (relationer). Det finns många exempel på diagram. Detta är ett blockschema som vi alla känner till från skolåren, och installationsdiagram för olika utrustningar, som vi kan se i användarmanualer, och ett träd med filer och kataloger på disken, som vi kan se genom att köra Windows-konsol trädkommando och mycket, mycket mer. I vardagen omger diagram oss på alla sidor, eftersom vi uppfattar ritningar lättare än text...

Men låt oss gå tillbaka till mjukvarudesign (och mer). I den här branschen med Diagram kan användas för att visualisera ett system från olika perspektiv. Ett av diagrammen kan till exempel beskriva användarens interaktion med systemet, ett annat kan beskriva förändringen i systemets tillstånd under dess drift, det tredje kan beskriva interaktionen av systemelement med varandra, etc. Ett komplext system kan och bör representeras som en uppsättning små och nästan oberoende modeller - diagram, och ingen av dem är tillräcklig för att beskriva systemet och få en fullständig bild av det, eftersom var och en av dem fokuserar på en specifik aspekt av systemets funktion och uttrycker en annorlunda abstraktionsnivå. Med andra ord, varje modell motsvarar en viss, speciell syn på det designade systemet.

Trots det faktum att vi i föregående stycke behandlade konceptet med en modell mycket fritt, bör det förstås att i samband med ovanstående definitioner inget individuellt diagram är en modell. Diagram är bara ett sätt att visualisera en modell, och de två begreppen måste särskiljas. Endast en uppsättning diagram utgör en systemmodell och beskriver det mest fullständigt, men inte bara ett diagram taget ur sitt sammanhang.

Typer av diagram

UML 1.5 definierad tolv diagramtyper, uppdelad i tre grupper:

• fyra typer av diagram representerar applikationens statiska struktur;
• fem representerar beteendeaspekter av systemet;
• tre representerar de fysiska aspekterna av systemets drift (implementeringsdiagram).

Den nuvarande versionen av UML 2.1 har inte gjort alltför många ändringar. Diagrammen har ändrats något i utseende (ramar och andra visuella förbättringar har dykt upp), notationen har förbättrats något och vissa diagram har fått nya namn.

Men det exakta antalet kanoniska diagram för oss är det absolut oviktigt, eftersom vi inte kommer att överväga dem alla, utan bara några - av den anledningen att antalet diagramtyper för en specifik modell av en specifik applikation inte är strikt fast. För enkla applikationer behöver du inte bygga varje enskilt diagram. Till exempel, för en lokal applikation är det inte nödvändigt att bygga ett distributionsdiagram. Det är viktigt att förstå att listan över diagram beror på detaljerna i projektet som utvecklas och bestäms av utvecklaren själv. Om den nyfikna läsaren fortfarande vill veta om alla UML-diagrammen kommer vi att hänvisa honom till UML-standarden (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Låt oss påminna dig om att syftet med denna kurs inte är att beskriva absolut alla funktioner i UML, utan bara att introducera detta språk och ge en första uppfattning om denna teknik.

Så vi kommer kort att titta på sådana typer av diagram som:

• diagram för användningsfall;
• klassdiagram;
• objektdiagram;
• sekvensdiagram;
• interaktionsdiagram;
• tillståndsdiagram;
• aktivitetsdiagram;
• distributionsdiagram.

Vi kommer att prata mer om några av dessa diagram i kommande föreläsningar. För närvarande kommer vi inte att fokusera på detaljerna, utan kommer att sätta oss som mål att lära läsaren att åtminstone visuellt skilja mellan typerna av diagram och att ge en första uppfattning om syftet med huvudtyperna av diagram. Så, låt oss börja.

Använd falldiagram

Alla system (inklusive mjukvara) är utformade med hänsyn till att de under drift kommer att användas av människor och/eller interagera med andra system. Entiteterna som systemet interagerar med under dess drift kallas skådespelare, och varje aktör förväntar sig att systemet ska bete sig på ett strikt definierat, förutsägbart sätt. Låt oss försöka ge en mer strikt definition av en aktör. För att göra detta kommer vi att använda en underbar visuell ordbok för UML Zicom mentor:

Ector (skådespelare)- detta är en uppsättning logiskt relaterade roller som utförs när de interagerar med prejudikat eller entiteter (system, undersystem eller klass). En aktör kan vara en person eller ett annat system, delsystem eller klass som representerar något utanför entiteten.

Grafiskt avbildas ektorn antingen " liten man", liknande de som vi ritade som barn, föreställande medlemmar av vår familj, eller klasssymbol med motsvarande stereotyp, som det visas på bilden. Båda representationsformerna har samma betydelse och kan användas i diagram. Den ”stereotypa” formen används oftare för att representera systemaktörer eller i fall där en aktör har egenskaper och de behöver visas (Fig. 2.1).

En uppmärksam läsare kan omedelbart fråga: varför en skådespelare och inte en skådespelare? Vi är överens, ordet "ektor" är lite hårt i det ryska folkets öron. Anledningen till att vi säger detta är enkel - ector kommer från ordet handling, vilket översatt betyder handling. Den bokstavliga översättningen av ordet "ector" är skådespelare- för lång och obekväm att använda. Därför kommer vi att fortsätta prata på det här sättet.

Samma uppmärksamma läsare kanske har märkt att ordet "prejudikat" blinkar genom ektorns definition. Vad är det? Denna fråga kommer att intressera oss ännu mer om vi kommer ihåg att vi nu talar om diagram för användningsfall. Så,

Användningsfall- beskrivning av en separat aspekt av systemets beteende ur användarens synvinkel (Butch).

Definitionen är ganska tydlig och heltäckande, men den kan förtydligas ytterligare med densamma Zicom mentor"om:

Användningsfall- en beskrivning av en uppsättning sekventiella händelser (inklusive alternativ) utförda av systemet som leder till resultatet som observerats av aktören. Ett användningsfall representerar beteendet hos en entitet, som beskriver interaktionen mellan aktörer och systemet. Ett användningsfall visar inte "hur" ett visst resultat uppnås, bara "vad" som uppnås.

Prejudikat betecknas på ett mycket enkelt sätt - i form av en ellips, inuti vilken dess namn anges. Användningsfall och skådespelare kopplas ihop med hjälp av linjer. Ofta ritas en figur i ena änden av linjen. 2.3

Unified Modeling Language (UML) är för närvarande den de facto standard för att beskriva (dokumentera) resultaten av design och utveckling av objektorienterade system. Utvecklingen av UML började 1994 av Grady Booch och James Rumbaugh, som arbetade på Rational Software. Hösten 1995 anslöt sig Ivar Jacobson till dem och i oktober samma år släpptes en preliminär version 0.8 av Unified Method. Sedan dess har flera versioner av UML-specifikationen släppts, varav två har internationell standardstatus:

UML 1.4.2 – "ISO/IEC 19501:2005. Informationsteknologi. Öppen distributionsbehandling. Unified Modeling Language (UML). Version 1.4.2" (engelska "Informationsteknologi. Öppen distribuerad bearbetning. Unified modeling language (UML). Version 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Informationsteknologi. Object Management Group Unified Modeling Language (OMG UML). Del 1. Infrastructure" (eng. "Information technology -- Object Management Group Unified Modeling Language ( OMG UML) - Del 1: Infrastruktur") och "ISO/IEC 19505-2:2012. Informationsteknologi. Object Management Group Unified Modeling Language (OMG UML). Del 2. Superstructure" (eng. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Del 2: Överbyggnad").

Den senaste officiella språkspecifikationen finns på www.omg.org.

Den allmänna strukturen för UML visas i följande figur.

Ris. 11.1. UML struktur

11.2. UML semantik och syntax

Semantik - en gren av lingvistik som studerar betydelsen av språkenheter, i första hand dess ord och fraser.

Syntax – sätt att kombinera ord och deras former till fraser och meningar, kombinera meningar till komplexa meningar, sätt att skapa påståenden som en del av en text.

Sålunda, i förhållande till UML, bestämmer semantik och syntax presentationsstilen (modellbyggnad), som kombinerar naturliga och formella språk för att representera grundläggande begrepp (modellelement) och mekanismer för deras förlängning.

11.3. UML-notation

Notation är en grafisk tolkning av semantik för dess visuella representation.

UML definierar tre Entitetstyp :

Strukturell - en abstraktion som är en reflektion av ett konceptuellt eller fysiskt objekt;

Gruppering – ett element som används för någon semantisk kombination av diagramelement;

Förklarande (annotativ) – en kommentar till ett diagramelement.

Följande tabell visar kort beskrivning de huvudsakliga enheterna som används i grafisk notation och de huvudsakliga sätten att visa dem.

Tabell 11.1. Entiteter

Typ	namn	Beteckning	Definition (semantik)
Strukturell	(klass)		Många föremål som har allmän struktur och beteende
	(objekt)		En abstraktion av en verklig eller föreställd varelse med tydligt definierade konceptuella gränser, personlighet, tillstånd och beteende. Ur UML-synpunkt är objekt instanser av en klass (instanser av en entitet)
	(skådespelare)	Ingenjör vägtjänster	En enhet utanför systemet som interagerar med och använder systemet funktionalitet att uppnå vissa mål eller lösa särskilda problem. Så en skådespelare är det extern källa eller informationsmottagare
	(användningsfall)		Beskrivning av de åtgärder som utförs av systemet, vilket leder till ett betydande resultat för aktören
	(stat)		En beskrivning av ett ögonblick i en entitets liv när den uppfyller något villkor, utför någon aktivitet eller väntar på att någon händelse ska inträffa.
	Samarbete (samarbete)		Beskrivning av en uppsättning instanser av aktörer, objekt och deras interaktion i processen att lösa ett visst problem
	(komponent)		Den fysiska delen av systemet (filen), inklusive systemmoduler som tillhandahåller implementeringen av en konsekvent uppsättning gränssnitt
	(gränssnitt)	iCalculation	En uppsättning operationer som definierar en tjänst (uppsättning tjänster) som tillhandahålls av en klass eller komponent
	(nod)		Den fysiska delen av systemet (dator, skrivare etc.) som tillhandahåller resurser för att lösa ett problem
Gruppering	(paket)		Allmän mekanism för att gruppera element. Till skillnad från en komponent är ett paket ett rent konceptuellt (abstrakt) koncept. Specialfall av ett paket är system och modell
	(fragment)		Området för specifik interaktion mellan skådespelarinstanser och objekt
	(aktivitetspartition)		En grupp av operationer (ansvarsområde) som utförs av en enhet (aktör, objekt, komponent, nod, etc.)
	(avbrottsbar aktivitetsregion)		En grupp av operationer, vars normala sekvens av utförande kan avbrytas till följd av att en ovanlig situation inträffar
Förklarande	Notera (kommentar)		Kommentar för elementet. Bifogas till det kommenterade elementet med en streckad linje

Vissa källor, särskilt [,], identifierar också beteendemässiga enheter interaktioner Och ändliga tillståndsmaskiner, men ur en logisk synvinkel bör de klassificeras som diagram.

Några av ovanstående enheter enligt antyder dem detaljerad beskrivning på nedbrytningsdiagram. På toppnivådiagrammet är de markerade med en speciell ikon eller etikett.

Följande tabell ger en beskrivning av alla typer relationer UML används i diagram för att indikera relationer mellan enheter.

Tabell 11.3. Relation

namn	Beteckning	Definition (semantik)
Förening		Relationsbeskrivande meningsfull koppling mellan två eller flera enheter. Mest allmän form relation
Aggregation		En undertyp av association som beskriver förhållandet "del"–"hela", där "delen" kan existera separat från "helheten". Romben indikeras från "hela" sidan. Relationen anges endast mellan enheter av samma typ
Sammansättning		En undertyp av aggregering där "delarna" inte kan existera separat från "helheten". Som regel skapas och förstörs "delar" samtidigt med "helheten"
Beroende		En relation mellan två enheter där en förändring i en enhet (den oberoende) kan påverka tillståndet eller beteendet hos den andra enheten (den beroende). Pilsidan indikerar en oberoende enhet
Generalisering		Relationen mellan en generaliserad enhet (förfader, förälder) och en specialiserad enhet (ättling, dotter). Triangeln indikeras från förälderns sida. Relationen anges endast mellan enheter av samma typ
Insikt		En relation mellan enheter där en enhet specificerar en åtgärd som en annan enhet åtar sig att utföra. Relationer används i två fall: mellan gränssnitt och klasser (eller komponenter), mellan användningsfall och samarbeten. Pilsidan anger den enhet som definierar åtgärden (gränssnitt eller användningsfall)

För association kan aggregering och sammansättning anges mångfald (eng. multiplicity), som kännetecknar det totala antalet instanser av enheter som deltar i relationen. Det anges vanligtvis på varje sida av relationen nära motsvarande enhet. Mångfalden kan anges på följande sätt:

- * - valfritt antal kopior, inklusive inga;

Icke-negativt heltal – multipliciteten är strikt fast och lika med det angivna talet (till exempel: 1, 2 eller 5);

Område av icke-negativa heltal "första talet.. andra talet" (till exempel: 1..5, 2..10 eller 0..5);

Ett intervall av tal från ett specifikt initialvärde till ett godtyckligt slutligt "första nummer.. *" (till exempel: 1..*, 5..* eller 0..*);

Listar icke-negativa heltal och intervall separerade med kommatecken (till exempel: 1, 3..5, 10, 15..*).

Om multipliciteten inte specificeras antas dess värde vara 1. Mångfalden av entitetsinstanser som deltar i beroende, generalisering och implementering antas alltid vara 1.

Följande tabell ger en beskrivning expansionsmekanismer , används för att klargöra semantiken för enheter och relationer. I allmänhet är expansionsmekanismen en textsträng omsluten inom parentes eller citattecken.

Tabell 11.4. Expansionsmekanismer

Förutom stereotyper som anges som en textsträng inom citattecken, kan grafiska stereotyper användas i diagram. Följande bild visar exempel på standard och stereotyp display.

a) standardbeteckning		b) standardbeteckning med textstereotyp		c) grafisk stereotyp

Ris. 11.2. Exempel på standard och stereotyp klassvisning

Diagram representerar en gruppering av notationselement för att visa någon aspekt av det utvecklade informationssystem. Diagram är vanligtvis en sammankopplad graf där entiteter är hörn och relationer är bågar. Följande tabell ger en kort beskrivning av UML-diagram.

Tabell 11.5. Diagram

UML 2.x-standarden definierar även ytterligare, högt specialiserade diagram:

Objektdiagram - liknande, men objekt visas istället för klasser;

Tidsdiagram - beskriver tillståndet för ett objekt över tiden;

Sammansatt strukturdiagram - beskriver portarna (inklusive gränssnitt) i en klass för interaktion med andra klasser;

Profildiagram - liknande med en beskrivning av klasserna som ingår i dem;

Interaktionsöversiktsdiagram - liknande, men med dolda interaktionsfragment (fragment märkta ref). Representerar en kontextuell (konceptuell), vars element kommer att specificeras på separata nedbrytningsdiagram.

För syftet med en förstorad konceptuell representation av systemets interna arkitektur tillåter majoriteten av konstruktionen användningen av etablerade grafiska stereotyper för den så kallade. Ett sådant diagram kallas 1, men tillhör inte listan över diagram som definieras av UML-standarden.

När man utvecklar en separat modell av ett system byggs flera typer av diagram. Dessutom, när man utvecklar en modell av ett komplext system, konstrueras som regel flera diagram av samma typ. Samtidigt behöver du inte skapa separata typer av diagram om det inte är nödvändigt. Till exempel, diagram och är utbytbara; de är byggda endast för objekt med komplext beteende. Följande tabell ger rekommendationer om behovet av att utveckla (förtydliga) diagram för systemmodeller.

Tabell 11.6. Samband mellan modeller och diagram

Tabellen nedan visar ingen testmodell, eftersom diagram som en del av dess konstruktion inte utvecklas, utan kontrolleras (testas) för fullständighet och konsistens.

Vissa av diagrammen efter deras konstruktion kräver utveckling och förtydligande som en del av utvecklingen av nästa modell ( teknisk process). Så de bör till exempel förtydligas under utvecklingen. I modeller.

4. Definiera begreppet " ".