5.4. Objektdiagrammer Essensielt: Objekter og deres relasjoner Et objektdiagram viser eksisterende objekter og deres relasjoner i den logiske utformingen av et system. Med andre ord er et objektdiagram et øyeblikksbilde av flyten av hendelser i en eller annen konfigurasjon

5.7. Prosessdiagrammer. Viktig: Prosessorer, enheter og tilkoblinger Prosessdiagrammer brukes til å vise fordelingen av prosesser på tvers av prosessorer i en fysisk systemdesign. Et eget prosessdiagram viser ett syn på prosessstrukturen

10.4. UML-DIAGRAMMER 10.4.1. Typer visuelle diagrammer UMLUML lar deg lage flere typer visuelle diagrammer: bruk kasusdiagrammer; sekvensdiagrammer; samarbeidsdiagrammer; klassediagrammer; tilstandsdiagrammer; diagrammer

1.2.6. Diagramramme I fig. Figur 1.2.26 viser et typisk eksempel på et dekomponeringsdiagram med avgrensningsbokser kalt diagramrammen. Ris. 1.2.26. Eksempel på et dekomponeringsdiagram med en wireframe. Trådrammen inneholder en tittel ( øverste del rammer) og kjeller (nedre del).

Tidsdiagrammer For å få tak i tidsdiagrammene for inngangs- og utgangsspenningene, må du endre inngangsfilen litt. Som i forrige eksempel vil en sinusformet inngangsspenning brukes: Vi 1 0 sin (0 0. 5V 5kHz) Sammen med transientanalyse

Diagrammer og grafer Bare en ekspert kan skjelne meningen bak endeløse rader med tall, men alle kan forstå (eller i det minste hevde å forstå) et histogram eller et sektordiagram. VBA har ikke innebygde kartverktøy, men

5.1.14. Diagram Diagrammer er grafiske representasjoner av numeriske data i en tabell. Pages tilbyr flere typer diagrammer: kolonne, stablet kolonne, stolpediagram, stablet stolpediagram, linje, areal, stablet areal

5.2.8. Diagrammer Et diagram er en grafisk representasjon av data fra et valgt område. For å bygge et diagram, følg følgende algoritme1. Lag en tabell med beregnede verdier.2. Velg ønsket område (det kan bestå av ikke-tilstøtende rektangulære

Hva er UML?

Hvis du ser på bildene i søkemotorer, så blir det klart det UML– det handler om diagrammer, piler og firkanter. Det som er viktig er at UML oversettes som Unified Modeling Language. Ordet Unified er viktig her. Det vil si at bildene våre vil bli forstått ikke bare av oss, men også av andre som kjenner UML. Det viser seg at dette er et internasjonalt språk for å tegne diagrammer.

Som Wikipedia sier

UML er et grafisk beskrivelsesspråk for objektmodellering i programvareutvikling, forretningsprosessmodellering, systemdesign og visning av organisasjonsstrukturer.

applikasjon

Men hva om du vil tegne det selv, og selv om du ikke gjør det Ultimate versjon Idé? Hvis vi bruker IntelliJ Idea Community Edition, har vi ikke noe annet valg. For å gjøre dette må du forstå hvordan et slikt UML-diagram er strukturert. Først må vi installere Graphviz. Dette er et sett med verktøy for å visualisere grafer. Den brukes av plugin-en som vi skal bruke. Etter installasjonen må du legge til en katalog bin fra den installerte katalogen Graphviz til miljøvariabelen STI. Etter det, i IntelliJ Idea, velg Fil -> Innstillinger fra menyen. I vinduet "Innstillinger", velg kategorien "Plugins", klikk på "Bla gjennom repositories"-knappen og installer PlantUML-integrasjonsplugin. Hvorfor er denne så bra? PlantUML? Den bruker et grafbeskrivelsesspråk kalt " punktum"og dette gjør at det kan være mer universelt, fordi... gitt språk Ikke bare PlantUML brukes. Dessuten kan alt vi gjør nedenfor gjøres ikke bare i IDE, men også i online tjeneste planttext.com. Etter å ha installert PlantUML-pluginen, vil vi kunne lage UML-diagrammer gjennom "Fil" -> "Ny". La oss lage et diagram av typen "UML-klasse". Under denne prosessen genereres det automatisk en mal med et eksempel. La oss slette innholdet og lage vårt eget, bevæpnet med en artikkel fra Habr: Klasseforhold – fra UML til kode. Og for å forstå hvordan du skildre dette i teksten, la oss ta PlantUML-manualen: plantuml klassediagram. Helt i begynnelsen er det en tabell som viser hvordan forbindelser skal beskrives:

Vi kan også se på selve sammenhengene her: "Relasjoner mellom klasser i UML. Eksempler." Basert på disse materialene, la oss begynne å lage UML-diagrammet vårt. La oss legge til følgende innhold som beskriver de to klassene: @startuml class ArrayList ( ) class LinkedList ( ) @enduml For å se resultatet i Idea, velg "View" -> " Verktøy Windows" -> "PlantUML". Vi vil ganske enkelt få to firkanter som angir klasser. Som vi vet implementerer begge disse klassene List-grensesnittet. Dette klasseforholdet kalles implementering. For å avbilde et slikt forhold, bruk en pil med stiplet linje. La oss skildre det: grensesnitt List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о pakke privat array of elements: ~ Object elementData Nå ønsker vi å vise at ArrayList inneholder noen objekter. I dette tilfellet vil tilkoblingstypen være - aggregering(sammenslåing). Aggregatet i dette tilfellet er ArrayList, fordi den inneholder andre objekter. Vi velger aggregering fordi objekter i listen kan leve uten listen: de er ikke integrerte deler av den. Levetiden deres er ikke knyttet til listens levetid. Aggregat er oversatt fra latin som "samlet", det vil si noe som består av noe. For eksempel, i livet, er det en pumpeenhet, som består av en pumpe og en motor. Selve enheten kan demonteres, noe av det blir igjen komponenter. For eksempel å selge eller sette inn i en annen enhet. Det samme er listen. Og dette kommer til uttrykk i form av en tom diamant nær enheten og en kontinuerlig linje. La oss skildre det som følger: klasse Object ( ) ArrayList o- Object Nå ønsker vi å vise at, i motsetning til ArrayList, inneholder LinkedList-klassen Node - containere som refererer til lagrede data. I dette tilfellet er noder en del av selve LinkedList og kan ikke leve separat. Node lagrer ikke innholdet direkte, men inneholder kun en lenke til det. For eksempel, når vi legger til en rad i en LinkedList, legger vi til en ny node som inneholder en lenke til den raden, samt en lenke til forrige og neste node. Denne typen tilkobling kalles komposisjon(Komposisjon). For å vise en kompositt (en som består av deler), tegnes en farget diamant, med en kontinuerlig linje som fører til den. La oss nå skrive dette i form av en tekstvisning av forbindelsen: klasse Node ( ) LinkedList * -- Node Og nå må vi lære å vise en annen viktig type kommunikasjon - avhengighet(avhengighetsforhold). Den brukes når en klasse bruker en annen, og klassen inneholder ikke klassen som brukes og er ikke dens etterkommer. For eksempel kan LinkedList og ArrayList lage en ListIterator. La oss vise dette som piler med en stiplet linje: klasse ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Du kan gå inn i så mange detaljer som nødvendig. Alle betegnelser er angitt her: "PlantUML - Klassediagram". I tillegg er det ikke noe overnaturlig i å tegne et slikt diagram, og når du jobber med oppgavene dine, kan du raskt tegne det for hånd. Dette vil utvikle ferdighetene dine i å tenke gjennom applikasjonsarkitektur og hjelpe deg med å identifisere klassestrukturfeil tidlig, i stedet for etter at du har brukt dagen på å implementere feil modell. Jeg tror det er en god grunn til å prøve det?)

Automasjon

Siden Maven ikke er fokus i denne artikkelen, kan du finne svar på dine Maven-spørsmål i Maven Users Center. I det genererte prosjektet åpner du prosjektbeskrivelsesfilen for redigering, pom.xml. La oss kopiere innholdet fra beskrivelsen av uml-java-docklet som installeres i den. Artefakten som ble brukt i beskrivelsen ble ikke funnet i Maven Central-depotet. Men det fungerte for meg med dette: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Det vil si, du trenger bare å erstatte i den beskrivelsen gruppe-ID Med " info.leadinglight"på" com.chfourie"og installer versjonen" 1.0.0 ". Etter dette kan vi kjøre i katalogen der filen ligger pom.xml disse kommandoene: mvn clean install og mvn javadoc:javadoc . Nå, hvis vi åpner den genererte dokumentasjonen (explorer target\site\apidocs\index.html), vil vi se UML-diagrammene. Forresten, implementeringen vises allerede riktig her)

Konklusjon

Merknad: Emnet for dette kurset er The UML - the Unified Modeling Language. Det forrige foredraget snakket om hva UML er, dets historie, formål, måter å bruke språket på, strukturen i dets definisjon, terminologi og notasjon. Det har blitt lagt merke til at en UML-modell er et sett med diagrammer. I denne forelesningen vil vi vurdere følgende spørsmål: hvorfor trengs det flere typer diagrammer; typer diagrammer; OOP og diagramsekvens

Før vi går videre til å diskutere hovedmaterialet i denne forelesningen, la oss snakke om hvorfor vi trenger å bygge noen diagrammer i det hele tatt. Utviklingen av en modell av et hvilket som helst system (ikke bare programvare) går alltid foran opprettelsen eller oppdateringen. Dette er i det minste nødvendig for å tydeligere forestille seg at problemet blir løst. Gjennomtenkte modeller er svært viktige både for samhandling innad i utviklingsteamet og for gjensidig forståelse med kunden. Til syvende og sist sikrer dette at designet er "arkitektonisk konsistent" før det implementeres i kode.

Vi bygger modeller av komplekse systemer fordi vi ikke kan beskrive dem fullstendig, "ta et blikk på dem." Derfor fremhever vi bare egenskapene til systemet som er essensielle for en spesifikk oppgave og bygger modellen som viser disse egenskapene. Metoden for objektorientert analyse lar oss beskrive virkelige komplekse systemer på den mest adekvate måten. Men etter hvert som kompleksiteten til systemene øker, oppstår behovet for god modelleringsteknologi. Som vi allerede sa i forrige forelesning, en enhetlig modelleringsspråk(Unified Modeling Language, UML), som er et grafisk språk for å spesifisere, visualisere, designe og dokumentere systemer. Ved å bruke UML kan du utvikle en detaljert modell av systemet som opprettes, som gjenspeiler ikke bare konseptet, men også spesifikke funksjoner ved implementeringen. Innenfor UML-modellen er alle ideer om systemet registrert i form av spesielle grafiske strukturer kalt diagrammer.

Merk. Vi vil vurdere ikke alle, men bare noen av typene diagrammer. For eksempel er ikke komponentdiagrammet dekket i denne forelesningen, som kun er det en kort oversikt typer diagrammer. Antall diagramtyper for spesifikk modell applikasjoner er ikke begrenset på noen måte. Til enkle applikasjoner det er ikke nødvendig å bygge diagrammer av alle typer uten unntak. Noen av dem kan rett og slett mangle, og dette faktum vil ikke bli ansett som en feil. Det er viktig å forstå at tilgjengeligheten til visse typer diagrammer avhenger av spesifikasjonene til et bestemt prosjekt. Informasjon om andre typer diagrammer (ikke omtalt her) finnes i UML-standarden.

Hvorfor du trenger flere typer diagrammer

Først, la oss definere terminologien. I innledningen til denne forelesningen har vi gjentatte ganger brukt begrepene system, modell og diagram. Forfatteren er sikker på at hver enkelt av oss intuitivt forstår betydningen av disse konseptene, men for å gjøre det helt klart, la oss se på ordlisten igjen og lese følgende:

System- et sett av sammenkoblede kontrollerte delsystemer forent av et felles formål med driften.

Ja, ikke særlig informativ. Hva er da et delsystem? For å avklare situasjonen, la oss gå til klassikerne:

System refererer til et sett med delsystemer organisert for å oppnå et spesifikt mål og beskrevet ved hjelp av et sett med modeller, muligens fra forskjellige synsvinkler.

Vel, det er ingenting du kan gjøre, du må se etter en definisjon av et undersystem. Det står det også der delsystem er en samling av elementer, hvorav noen spesifiserer oppførselen til andre elementer. Ian Sommerville forklarer dette konseptet på denne måten:

Subsystem er et system hvis funksjon ikke er avhengig av tjenestene til andre delsystemer. Programvaresystemet er strukturert som en samling av relativt uavhengige delsystemer. Samspillet mellom delsystemer er også definert.

Det er heller ikke veldig tydelig, men det er bedre. Når vi snakker på "menneskelig" språk, er systemet representert som et sett med enklere enheter som er relativt selvforsynt. Dette kan sammenlignes med hvordan vi i prosessen med å utvikle et program bygger GUI fra standard "kuber" - visuelle komponenter, eller hvordan selve programteksten også er delt inn i moduler som inneholder subrutiner, forent av funksjonalitet, og de kan gjenbrukes i påfølgende programmer.

Vi forstår konseptet med et system. Under designprosessen vurderes systemet fra ulike synsvinkler ved hjelp av modeller, hvis ulike representasjoner vises i form av diagrammer. Igjen kan leseren ha spørsmål om betydningen av begrepene modeller Og diagrammer. Vi synes det er en vakker, men ikke veldig klar definisjon modeller som en semantisk lukket abstraksjon av systemet Det er usannsynlig å avklare situasjonen, så vi vil prøve å forklare "med våre egne ord."

Modell- dette er et bestemt (materiell eller ikke) objekt som viser bare de viktigste egenskapene til systemet for en gitt oppgave. Modeller er forskjellige - materielle og immaterielle, kunstige og naturlige, dekorative og matematiske...

La oss gi noen eksempler. Plastlekebilene som er kjent for oss alle, som vi lekte med så spenning i barndommen, er ikke annet enn materiale kunstig dekorativ modell av en ekte bil. Selvfølgelig har en slik "bil" ikke en motor, vi fyller ikke tanken med bensin, og girkassen fungerer ikke (det er faktisk ingen girkasse i det hele tatt), men som en modell oppfyller dette leketøyet sine funksjoner. : det gir barnet en ide om bilen, siden den viser sine karakteristiske trekk er tilstedeværelsen av fire hjul, et karosseri, dører, vinduer, evne til å kjøre, etc.

I medisinsk forskning går dyreforsøk ofte før kliniske forsøk på mennesker. I dette tilfellet fungerer dyret som materiale naturlig menneskelige modeller.

Ligningen som er avbildet ovenfor er også en modell, men den er en matematisk modell, og den beskriver bevegelsen til et materiell punkt under påvirkning av tyngdekraften.

Alt som gjenstår er å si hva et diagram er. Diagram er en grafisk representasjon av mange elementer. Vanligvis avbildet som en graf med toppunkter (entiteter) og kanter (relasjoner). Det er mange eksempler på diagrammer. Dette er et blokkdiagram som er kjent for oss alle fra skoleårene, og installasjonsdiagrammer for diverse utstyr, som vi kan se i brukermanualer, og et tre med filer og kataloger på disken, som vi kan se ved å utføre Windows-konsoll trekommando, og mye, mye mer. I hverdagen omgir diagrammer oss på alle kanter, fordi vi oppfatter tegninger lettere enn tekst...

Men la oss gå tilbake til programvaredesign (og mer). I denne bransjen med Diagrammer kan brukes til å visualisere et system fra ulike perspektiver. Et av diagrammene kan for eksempel beskrive brukerens interaksjon med systemet, et annet kan beskrive endringen i systemets tilstander under driften, det tredje kan beskrive samspillet mellom systemelementer med hverandre osv. Et komplekst system kan og bør representeres som et sett med små og nesten uavhengige modeller - diagrammer, og ingen av dem er tilstrekkelig til å beskrive systemet og få et fullstendig bilde av det, siden hver av dem fokuserer på et spesifikt aspekt av systemets funksjon og uttrykker en annen abstraksjonsnivå. Med andre ord tilsvarer hver modell et bestemt, spesielt synspunkt på det utformede systemet.

Til tross for at vi i forrige avsnitt behandlet konseptet med en modell veldig fritt, bør det forstås at i sammenheng med definisjonene ovenfor ingen individuelle diagram er en modell. Diagrammer er kun et middel for å visualisere en modell, og de to begrepene må skilles. Bare et sett med diagrammer utgjør en systemmodell og beskriver det mest fullstendig, men ikke bare ett diagram tatt ut av kontekst.

Typer diagrammer

UML 1.5 definert tolv diagramtyper, delt inn i tre grupper:

• fire typer diagrammer representerer den statiske strukturen til applikasjonen;
• fem representerer atferdsaspekter ved systemet;
• tre representerer de fysiske aspektene ved systemets drift (implementeringsdiagrammer).

Den nåværende versjonen av UML 2.1 har ikke gjort for mange endringer. Diagrammene har endret seg litt i utseende (rammer og andre visuelle forbedringer har dukket opp), notasjonen er litt forbedret, og noen diagrammer har fått nye navn.

Men det nøyaktige antallet kanoniske diagrammer for oss er det helt uviktig, siden vi ikke vil vurdere alle, men bare noen - av den grunn at antall diagramtyper for en spesifikk modell av en spesifikk applikasjon ikke er strengt fastsatt. For enkle applikasjoner er det ikke nødvendig å bygge hvert eneste diagram. For en lokal applikasjon er det for eksempel ikke nødvendig å bygge et distribusjonsdiagram. Det er viktig å forstå at listen over diagrammer avhenger av detaljene i prosjektet som utvikles og bestemmes av utvikleren selv. Hvis den nysgjerrige leser fortsatt ønsker å vite om alle UML-diagrammene, vil vi henvise ham til UML-standarden (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). La oss minne deg på at formålet med dette kurset ikke er å beskrive absolutt alle egenskapene til UML, men bare å introdusere dette språket og gi en første idé om denne teknologien.

Så vi vil kort se på slike typer diagrammer som:

• bruk case diagram;
• klasse diagram;
• objektdiagram;
• sekvensdiagram;
• interaksjonsdiagram;
• tilstandsdiagram;
• aktivitetsdiagram;
• distribusjonsdiagram.

Vi vil snakke mer om noen av disse diagrammene i fremtidige forelesninger. Foreløpig vil vi ikke fokusere på detaljene, men vil sette oss som mål å lære leseren å i det minste visuelt skille mellom typene diagrammer og gi en innledende idé om formålet med hovedtypene av diagrammer. Så la oss begynne.

Bruk case-diagram

Alle (inkludert programvare) systemer er utformet med tanke på at de under driften vil bli brukt av mennesker og/eller samhandle med andre systemer. Enhetene som systemet samhandler med under driften kalles skuespillere, og hver aktør forventer at systemet oppfører seg på en strengt definert, forutsigbar måte. La oss prøve å gi en mer streng definisjon av en aktør. For å gjøre dette, vil vi bruke en fantastisk visuell ordbok for UML Zicom mentor:

Ector (skuespiller)- dette er et sett med logisk relaterte roller som utføres når du samhandler med presedenser eller enheter (system, undersystem eller klasse). En aktør kan være en person eller et annet system, subsystem eller klasse som representerer noe utenfor enheten.

Grafisk er ektoren avbildet enten " liten mann", lik de vi tegnet som barn, som viser medlemmer av familien vår, eller klassesymbol med tilhørende stereotypi, som vist på bildet. Begge representasjonsformer har samme betydning og kan brukes i diagrammer. Den "stereotype"-formen brukes oftere for å representere systemaktører eller i tilfeller der en aktør har egenskaper og de må vises (fig. 2.1).

En oppmerksom leser kan umiddelbart spørre: hvorfor en skuespiller og ikke en skuespiller? Vi er enige, ordet "ektor" er litt hardt for russiske folks ører. Grunnen til at vi sier dette er enkel - ector er avledet fra ordet handling, som oversatt betyr handling. Den bokstavelige oversettelsen av ordet "ector" er skuespiller- for lang og upraktisk å bruke. Derfor vil vi fortsette å snakke på denne måten.

Den samme oppmerksomme leseren kan ha lagt merke til at ordet "presedens" blinker gjennom ektorens definisjon. Hva er det? Dette spørsmålet vil interessere oss enda mer hvis vi husker det vi nå snakker om bruk case diagram. Så,

Use-case- beskrivelse av et eget aspekt av systematferd fra brukerens synspunkt (Butch).

Definisjonen er ganske klar og omfattende, men den kan avklares ytterligere ved hjelp av den samme Zicom mentor"om:

Bruk case- en beskrivelse av et sett med sekvensielle hendelser (inkludert alternativer) utført av systemet som fører til resultatet observert av skuespilleren. Et use case representerer oppførselen til en enhet, og beskriver samspillet mellom aktører og systemet. En brukstilfelle viser ikke "hvordan" et bestemt resultat oppnås, bare "hva" som oppnås.

Presedenser er utpekt på en veldig enkel måte - i form av en ellipse, hvor navnet er angitt. Use cases og aktører kobles sammen ved hjelp av linjer. Ofte er en figur tegnet i den ene enden av linjen. 2.3

Unified Modeling Language (UML) er i dag de facto-standarden for å beskrive (dokumentere) resultatene av design og utvikling av objektorienterte systemer. Utviklingen av UML begynte i 1994 av Grady Booch og James Rumbaugh, som jobbet hos Rational Software. Høsten 1995 ble Ivar Jacobson med dem og i oktober samme år ble en foreløpig versjon 0.8 av Unified Method utgitt. Siden den gang har flere versjoner av UML-spesifikasjonen blitt utgitt, hvorav to har internasjonal standardstatus:

UML 1.4.2 – "ISO/IEC 19501:2005. Informasjonsteknologi. Åpen distribusjonsbehandling. Unified Modeling Language (UML). Versjon 1.4.2" (engelsk "Informasjonsteknologi. Åpen distribuert prosessering. Unified modeling language (UML). Versjon 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Informasjonsteknologi. 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") og "ISO/IEC 19505-2:2012. Informasjonsteknologi. Object Management Group Unified Modeling Language (OMG UML). Del 2. Superstructure" (eng. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Del 2: Overbygning").

Den siste offisielle språkspesifikasjonen finner du på www.omg.org.

Den generelle strukturen til UML er vist i følgende figur.

Ris. 11.1. UML struktur

11.2. UML semantikk og syntaks

Semantikk - en gren av lingvistikk som studerer betydningen av språkenheter, først og fremst dens ord og uttrykk.

Syntaks – måter å kombinere ord og deres former til fraser og setninger, kombinere setninger til komplekse setninger, måter å lage utsagn på som en del av en tekst.

Derfor, i forhold til UML, bestemmer semantikk og syntaks presentasjonsstilen (modellbygging), som kombinerer naturlige og formelle språk for å representere grunnleggende konsepter (modellelementer) og mekanismer for deres utvidelse.

11.3. UML-notasjon

Notasjon er en grafisk tolkning av semantikk for dens visuelle representasjon.

UML definerer tre enhetstype :

Strukturell - en abstraksjon som er en refleksjon av et konseptuelt eller fysisk objekt;

Gruppering – et element som brukes for en semantisk kombinasjon av diagramelementer;

Forklarende (annotativ) – en kommentar til et diagramelement.

Følgende tabell viser Kort beskrivelse hovedenhetene som brukes i grafisk notasjon, og de viktigste måtene å vise dem på.

Tabell 11.1. Enheter

Type	Navn	Betegnelse	Definisjon (semantikk)
Strukturell	(klasse)		Mange gjenstander som har generell struktur og oppførsel
	(gjenstand)		En abstraksjon av en ekte eller forestilt enhet med klart definerte konseptuelle grenser, personlighet, tilstand og atferd. Fra et UML-synspunkt er objekter forekomster av en klasse (forekomster av en enhet)
	(skuespiller)	Ingeniør stitjenester	En enhet utenfor systemet som samhandler med og bruker systemet funksjonalitetå oppnå bestemte mål eller løse spesielle problemer. Så en skuespiller er ekstern kilde eller informasjonsmottaker
	(brukstilfelle)		Beskrivelse av handlingene utført av systemet, som fører til et betydelig resultat for aktøren
	(stat)		En beskrivelse av et øyeblikk i livet til en enhet når den oppfyller en betingelse, utfører en aktivitet eller venter på at en hendelse skal inntreffe.
	Samarbeid (samarbeid)		Beskrivelse av et sett med forekomster av aktører, objekter og deres interaksjon i prosessen med å løse et bestemt problem
	(komponent)		Den fysiske delen av systemet (fil), inkludert systemmoduler som gir implementering av et konsistent sett med grensesnitt
	(grensesnitt)	iBeregning	Et sett med operasjoner som definerer en tjeneste (sett med tjenester) levert av en klasse eller komponent
	(node)		Den fysiske delen av systemet (datamaskin, skriver osv.) som gir ressurser til å løse et problem
Gruppering	(pakke)		Generell mekanisme for gruppering av elementer. I motsetning til en komponent er en pakke et rent konseptuelt (abstrakt) konsept. Spesielle tilfeller av en pakke er system og modell
	(fragment)		Området med spesifikk interaksjon mellom aktørforekomster og objekter
	(aktivitetspartisjon)		En gruppe operasjoner (ansvarsområde) utført av én enhet (aktør, objekt, komponent, node, etc.)
	(avbrytbar aktivitetsregion)		En gruppe operasjoner, hvis normale sekvens av utførelse kan avbrytes som et resultat av forekomsten av en uvanlig situasjon
Forklarende	Merk (kommentar)		Kommentar til elementet. Festes til det kommenterte elementet med en stiplet linje

Noen kilder, spesielt [,], identifiserer også atferdsenheter interaksjon Og endelige tilstandsmaskiner, men fra et logisk synspunkt bør de klassifiseres som diagrammer.

Noen av enhetene ovenfor antyder dem Detaljert beskrivelse på dekomponeringsdiagrammer. På toppnivådiagrammet er de merket med et spesielt ikon eller etikett.

Tabellen nedenfor gir en beskrivelse av alle typer relasjoner UML brukt i diagrammer for å indikere forhold mellom enheter.

Tabell 11.3. Forhold

Navn	Betegnelse	Definisjon (semantikk)
assosiasjon		Relasjonsbeskrivende meningsfull forbindelse mellom to eller flere enheter. Mest generell form forhold
Aggregasjon		En undertype av assosiasjon som beskriver forholdet «del»–«hele», der «delen» kan eksistere separat fra «helheten». Romben er indikert fra "hele" siden. Forholdet spesifiseres kun mellom enheter av samme type
Komposisjon		En undertype av aggregering der "delene" ikke kan eksistere atskilt fra "helheten". Som regel blir "deler" opprettet og ødelagt samtidig med "helheten"
Avhengighet		Et forhold mellom to enheter der en endring i en enhet (den uavhengige) kan påvirke tilstanden eller oppførselen til den andre enheten (den avhengige). Pilsiden indikerer en uavhengig enhet
Generalisering		Forholdet mellom en generalisert enhet (forfar, forelder) og en spesialisert enhet (etterkommer, datter). Trekanten er angitt fra foreldrenes side. Forholdet spesifiseres kun mellom enheter av samme type
Realisering		Et forhold mellom enheter der en enhet spesifiserer en handling som en annen enhet påtar seg å utføre. Relasjoner brukes i to tilfeller: mellom grensesnitt og klasser (eller komponenter), mellom brukstilfeller og samarbeid. Pilsiden indikerer enheten som definerer handlingen (grensesnitt eller brukstilfelle)

For assosiasjon kan aggregering og sammensetning spesifiseres mangfold (eng. multiplicity), som karakteriserer det totale antallet forekomster av enheter som deltar i forholdet. Det er vanligvis indikert på hver side av forholdet nær den tilsvarende enheten. Multiplisiteten kan angis på følgende måter:

- * - et hvilket som helst antall kopier, inkludert ingen;

Ikke-negativt heltall – multiplisiteten er strengt tatt fast og lik det angitte tallet (for eksempel: 1, 2 eller 5);

Område for ikke-negative heltall "første tall.. andre tall" (for eksempel: 1..5, 2..10 eller 0..5);

Et tallområde fra en spesifikk startverdi til et vilkårlig endelig "første tall.. *" (for eksempel: 1..*, 5..* eller 0..*);

Viser ikke-negative heltall og områder atskilt med komma (for eksempel: 1, 3..5, 10, 15..*).

Hvis multiplisiteten ikke er spesifisert, antas dens verdi å være 1. Multiplisiteten av entitetsforekomster som deltar i avhengighet, generalisering og implementering antas alltid å være 1.

Tabellen nedenfor gir en beskrivelse ekspansjonsmekanismer , brukes til å klargjøre semantikken til enheter og relasjoner. Generelt er ekspansjonsmekanismen en tekststreng omsluttet av parenteser eller anførselstegn.

Tabell 11.4. Ekspansjonsmekanismer

I tillegg til stereotyper angitt som en tekststreng i anførselstegn, kan grafiske stereotyper brukes i diagrammer. Følgende figur viser eksempler på standard og stereotyp visning.

a) standardbetegnelse		b) standardbetegnelse med tekststereotypi		c) grafisk stereotypi

Ris. 11.2. Eksempler på standard og stereotyp klassevisning

Diagram representerer en gruppering av notasjonselementer for å vise et aspekt av det utviklede informasjon System. Diagrammer er vanligvis en sammenhengende graf der entiteter er toppunkter og relasjoner er buer. Følgende tabell gir en kort beskrivelse av UML-diagrammer.

Tabell 11.5. Diagrammer

UML 2.x-standarden definerer også ytterligere, høyt spesialiserte diagrammer:

Objektdiagram - lignende, men objekter vises i stedet for klasser;

Tidsdiagram - beskriver tilstanden til et objekt over tid;

Sammensatt strukturdiagram - beskriver portene (inkludert grensesnitt) til en klasse for interaksjon med andre klasser;

Profildiagram - lignende med en beskrivelse av klassene som er inkludert i dem;

Interaksjonsoversiktsdiagram - lignende, men med skjulte interaksjonsfragmenter (fragmenter merket ref). Representerer en kontekstuell (konseptuell), hvis elementer vil bli spesifisert på separate dekomponeringsdiagrammer.

For formålet med en forstørret konseptuell representasjon av den interne arkitekturen til systemet, tillater flertallet av konstruksjonen bruk av etablerte grafiske stereotyper for den såkalte. Et slikt diagram kalles 1, men tilhører ikke listen over diagrammer definert av UML-standarden.

Ved utvikling av en egen modell av et system bygges det flere typer diagrammer. Videre, når man utvikler en modell av et komplekst system, er det som regel konstruert flere diagrammer av samme type. Samtidig trenger du ikke lage separate typer diagrammer hvis det ikke er nødvendig. For eksempel er diagrammer og utskiftbare; de ​​er kun bygget for objekter med kompleks oppførsel. Følgende tabell gir anbefalinger om behovet for å utvikle (klargjøre) diagrammer for systemmodeller.

Tabell 11.6. Sammenheng mellom modeller og diagrammer

Tabellen nedenfor viser ikke en testmodell, siden som en del av dens konstruksjon utvikles ikke diagrammer, men sjekkes (testes) for fullstendighet og konsistens.

Noen av diagrammene etter deres konstruksjon krever utvikling og avklaring som en del av utviklingen av neste modell ( teknologisk prosess). Så de bør for eksempel avklares under utviklingen. I modeller.

4. Definer konseptet " ".