Hvilket uml-diagram beskriver systemkrav. UML: fra teori til praksis

UML-modell(UML-modellen) er en samling av et begrenset sett med språkkonstruksjoner, hvor de viktigste er enheter og relasjoner mellom dem.

Selve modellenhetene og relasjonene er forekomster av metamodellmetaklasser.

Tatt i betraktning UML-modellen fra de mest generelle posisjonene, kan vi si at det er en graf (mer presist, en lastet multi-pseudo-hyper-digraph), der hjørner og kanter er lastet med tilleggsinformasjon og kan ha en kompleks intern struktur . Toppunktene til denne grafen kalles enheter, og kantene kalles relasjoner.. Resten av denne delen gir en rask (foreløpig) men fullstendig oversikt over tilgjengelige enhetstyper og relasjoner. Heldigvis er det ikke så mange av dem. I påfølgende kapitler av boken undersøkes alle enheter og relasjoner på nytt, mer detaljert og med eksempler.

1.4.1. Enheter

For å lette oversikten kan enheter i UML deles inn i fire grupper:

strukturell;
atferdsmessige;
gruppering;
annotativ.

Strukturelle enheter, som du kanskje gjetter, er ment å beskrive struktur. Vanligvis inkluderer strukturelle enheter følgende.

En gjenstand(objekt) 1 – en enhet som er unik og innkapsler tilstand og atferd.

Klasse(klasse) 2 – beskrivelse av et sett med objekter med vanlige attributter som definerer tilstand og operasjoner som definerer atferd.

Grensesnitt(grensesnitt) 3 - et navngitt sett med operasjoner som definerer et sett med tjenester som kan etterspørres av en forbruker og leveres av en tjenesteleverandør.

Samarbeid(samarbeid) 4 - en samling av objekter som samhandler for å oppnå et eller annet mål.

Skuespiller(aktør) 5 – en enhet som befinner seg utenfor det modellerte systemet og som interagerer direkte med det.

∇ Et slikt forhold eksisterer absolutt, som er uttrykt i fig. Hierarki av diagramtyper for UML 1 som et avhengighetsforhold til stereotypen «foredle».

∇∇ I UML 1 oppsto det en ufrivillig assosiasjon mellom samarbeidsdiagrammet og enheten med samme navn, noe som ikke var helt sant og noen ganger misvisende.

∇∇∇ I UML 2 har den syntaktiske og semantiske belastningen til tilstandsdiagrammet endret seg så mye at navnet ikke lenger gjenspeiler innholdet.

En liste over nye diagrammer og navnene deres tatt i bruk i denne boken er gitt nedenfor.

Sammensatt strukturdiagram
Pakkediagram
Statens maskindiagram
Kommunikasjonsdiagram
Interaksjon Oversiktsdiagram
Tidsdiagram

I fig. Hierarki av diagramtyper for UML 2 (del 1 og 2) Et klassediagram er gitt som viser forholdet mellom diagrammer i UML 2.

Senere i dette kapittelet vil vi meget kort beskrive alle tretten kanoniske diagrammene slik at vi har litt kontekst og vokabular for det som følger. Detaljer er gitt i de resterende kapitlene i boken.

Men før vi går videre til neste avsnitt, la oss gjøre en liten digresjon angående hvordan standarden krever at diagrammer utformes. En generell diagrampresentasjonsmal er vist nedenfor.

Det er to hoveddesignelementer: en ytre ramme og en etikett med navnet på diagrammet. Hvis alt er enkelt med rammen - det er et rektangel som begrenser området der diagramelementene skal være plassert, er navnet på diagrammet skrevet i et spesielt format vist i fig. Notasjon for diagrammer.

Denne komplekse etikettformen støttes ikke av alle verktøy. Dette er imidlertid ikke nødvendig, siden semantikk er primær, og notasjon er sekundær. I det følgende bruker vi et rektangel som en kartetikett gjennomgående, og dette bør ikke skape noen forvirring.

Mulige tagger (typer) for diagrammer er vist i følgende tabell. Taggene som foreslås av standarden er skrevet i den andre kolonnen. Som praksis har vist, er imidlertid ikke alltid reglene som standarden foreslår praktiske og logisk begrunnede, derfor inneholder tabellens tredje kolonne et alternativ som er rimelig etter vår mening.

Bord Diagramtyper og tagger

Diagramtittel	Tag (standard)	Tag (foreslått)
Bruksdiagram	bruk case eller uc	bruk case
Klassediagram	klasse	klasse
Maskindiagram	statsmaskin eller stm	statsmaskin
Aktivitetsdiagram	aktivitet eller handling	aktivitet
Sekvensdiagram	interaksjon eller SD	SD
Kommunikasjonsdiagram	interaksjon eller SD	komm
Komponentdiagram	komponent eller cmp	komponent
Plasseringsdiagram	udefinert	utplassering
Objektdiagram	udefinert	gjenstand
Intern strukturdiagram	klasse	klasse eller komponent
Interaksjonsoversiktsdiagram	interaksjon eller SD	interaksjon
Tidsdiagram	interaksjon eller SD	timing
Pakkediagram	pakke eller pkg	pakke

UML eller Unified Modeling Language er et grafisk beskrivelsesspråk for objektmodellering innen programvareutvikling. Men bruken av UML er ikke begrenset til IT; et annet stort område for praktisk anvendelse av UML er modellering av forretningsprosesser, systemdesign og kartlegging av organisasjonsstrukturer. UML lar programvareutviklere bli enige om grafiske notasjoner for å representere vanlige konsepter og fokusere på design og utvikling.

Fordeler med UML

UML bruker grafiske notasjoner for elementene i systemet som modelleres, og UML-diagrammer er ganske enkle å forstå;
UML gjør det mulig å beskrive systemer fra nesten alle mulige synsvinkler, med hensyn til ulike aspekter;
UML er objektorientert: metodene for analyse og konstruksjon er semantisk nær programmeringsmetodene som brukes i moderne OOP-språk;
UML er en åpen standard. Standarden utvikler og utvikler seg fra versjon til versjon, og oppfyller de mest moderne kravene for å beskrive systemer;
inneholder en utvidelsesmekanisme som lar deg legge inn ekstra tekst- og grafikktyper, som gjør det mulig å bruke UML ikke bare i IT-feltet.

UML-diagramtyper

Det er 14 typer diagrammer i UML. De kan deles inn i 2 kategorier:

strukturell, som representerer informasjonsstruktur;
atferdsmessige, som representerer oppførselen til systemet og ulike aspekter ved interaksjoner. En egen undertype av atferdsdiagrammer vurderes interaksjonsdiagrammer.

Hierarki av UML-diagramtyper,
representert ved et klassediagram

Strukturdiagrammer

Klassediagram er et sentralt element i objektorientert modellering. Ved å bruke dette diagrammet (faktisk gjennom klasser, deres attributter, metoder og avhengigheter mellom klasser) beskriver domenemodellen og strukturen til det modellerte systemet.
Komponentdiagram viser oppdelingen av programkode i store blokker (strukturelle komponenter) og viser avhengigheter mellom dem. Komponenter kan være pakker, moduler, biblioteker, filer osv.
Objektdiagram viser en hel eller delvis del av det simulerte systemet på et gitt tidspunkt. Den representerer klasseforekomster (objekter), deres tilstand (nåværende attributtverdier) og relasjonene mellom dem.
Sammensatt strukturdiagram demonstrerer den interne strukturen til klasser og, der det er mulig, interaksjonene mellom elementer i denne strukturen.
Pakkediagram viser pakker og relasjoner mellom dem. Denne typen diagram tjener til å forenkle strukturen til modellen (og følgelig arbeid med den) ved å kombinere modellelementer i grupper i henhold til visse kriterier.
Implementeringsdiagram modeller for distribusjon av programvarekomponenter ( gjenstander) på dataressurser/maskinvarekomponenter ( noder).
Profildiagram beskriver en utvidelsesmekanisme som gjør at UML kan tilpasses en rekke fagområder og bransjer.

Eksempel på UML klassediagram

Atferdsdiagrammer

Aktivitetsdiagram viser handlinger ( handlinger) som en del aktivitet består av ( aktivitet). Aktivitetsdiagrammer brukes til å modellere forretningsprosesser, teknologiske prosesser, sekvensiell og parallell databehandling.
Bruk case-diagram(eller bruk case diagram) beskriver forholdet mellom aktører (aktører) og brukstilfeller av det modellerte systemet (dets evner). Hovedformålet med diagrammet er å være et universelt verktøy for kunder, utviklere og sluttbrukere til i fellesskap å diskutere systemet - dets muligheter og oppførsel.
Tilstandsdiagram skildrer den dynamiske oppførselen til en enhet, og viser hvordan denne enheten, avhengig av dens nåværende tilstand, reagerer på ulike hendelser. Dette er i hovedsak et tilstandsdiagram fra atomteori.
Kommunikasjonsdiagram(i tidligere versjoner samarbeidsdiagram) viser samspillet mellom delene av den sammensatte strukturen og samarbeidsrollene. Diagrammet angir eksplisitt relasjonene mellom elementer (objekter).
Sekvensdiagram brukes til å visualisere sekvensen av objektinteraksjoner. Viser livssyklusen til et gitt objekt og interaksjonen mellom aktører (aktører) innenfor en bestemt brukssituasjon, sekvensen av meldinger som de utveksler.
Interaksjonsoversiktsdiagram inkluderer en del av sekvensdiagrammet og kontrollflytdesign. Hjelper med å vurdere samspillet mellom objekter fra ulike synsvinkler.
Tidsdiagram- en egen undertype av interaksjonsdiagrammer som spesialiserer seg på timing. Diagrammer av denne typen brukes til å studere oppførselen til objekter over en viss tidsperiode.

UML er et enhetlig grafisk modelleringsspråk for å beskrive, visualisere, designe og dokumentere OO-systemer. UML er designet for å støtte prosessen med å modellere programvare basert på OO-tilnærmingen, organisere forholdet mellom konseptuelle og programkonsepter, og reflektere problemene med å skalere komplekse systemer. UML-modeller brukes i alle stadier av programvarens livssyklus, fra forretningsanalyse til systemvedlikehold. Ulike organisasjoner kan bruke UML slik de finner passende, avhengig av deres problemområder og teknologiene de bruker.

En kort historie om UML

På midten av 90-tallet hadde forskjellige forfattere foreslått flere dusin OO-modelleringsmetoder, som hver brukte sin egen grafiske notasjon. Samtidig hadde noen av disse metodene sine styrker, men tillot ikke å bygge en tilstrekkelig komplett modell av PS, som viste den "fra alle sider", det vil si alle nødvendige anslag (se artikkel 1). I tillegg gjorde mangelen på en OO-modelleringsstandard det vanskelig for utviklere å velge den mest passende metoden, noe som forhindret den utbredte bruken av OO-tilnærmingen til programvareutvikling.

På forespørsel fra Object Management Group (OMG), organisasjonen som er ansvarlig for vedtakelse av standarder innen objektteknologi og databaser, ble det presserende problemet med forening og standardisering løst av forfatterne av de tre mest populære OO-metodene - G Butch, D. Rambo og A. Jacobson, som sammen skapte versjon UML 1.1, godkjent av OMG i 1997 som standard.

UML er et språk

Ethvert språk består av et vokabular og regler for å kombinere ord for å skape meningsfulle konstruksjoner. Dette er spesielt hvordan programmeringsspråk er strukturert, for eksempel UML. Dens særtrekk er at språkordboken er dannet av grafiske elementer. Hvert grafisk symbol har en spesifikk semantikk knyttet til seg, så en modell laget av en utvikler kan tydelig forstås av en annen, så vel som av et programvareverktøy som tolker UML. Spesielt herfra følger det at en programvaremodell presentert i UML automatisk kan oversettes til et OO-programmeringsspråk (som Java, C++, VisualBasic), det vil si hvis det er et godt visuelt modelleringsverktøy som støtter UML, som har bygget modellen, vil vi også motta en prøveprogramkode som tilsvarer denne modellen.

Det bør understrekes at UML er et språk, ikke en metode. Den forklarer hvilke elementer man skal lage modeller av og hvordan man leser dem, men sier ingenting om hvilke modeller som skal utvikles og i hvilke tilfeller. For å lage en metode basert på UML er det nødvendig å supplere den med en beskrivelse av programvareutviklingsprosessen. Et eksempel på en slik prosess er Rational Unified Process, som vil bli diskutert i påfølgende artikler.

UML-ordbok

Modellen er representert i form av enheter og relasjoner mellom dem, som er vist i diagrammer.

Enheter er abstraksjoner som er hovedelementene i modeller. Det er fire typer entiteter - strukturelle (klasse, grensesnitt, komponent, brukstilfelle, samarbeid, node), atferdsmessig (interaksjon, tilstand), gruppering (pakker) og annotering (kommentarer). Hver type enhet har sin egen grafiske representasjon. Enheter vil bli diskutert i detalj når du studerer diagrammene.

Forhold vise ulike sammenhenger mellom enheter. UML definerer følgende relasjonstyper:

Avhengighet viser en slik sammenheng mellom to enheter når en endring i en av dem - uavhengig - kan påvirke semantikken til den andre - avhengige. Avhengighet er representert med en stiplet pil rettet fra den avhengige enheten til den uavhengige.
assosiasjon er et strukturelt forhold som viser at objektene til en enhet er relatert til objektene til en annen. Grafisk vises en assosiasjon som en linje som forbinder de tilknyttede enhetene. Assosiasjoner tjener til å navigere mellom objekter. For eksempel kan assosiasjonen mellom klassene "Ordre" og "Produkt" brukes til å finne alle produkter spesifisert i en spesifikk bestilling, på den ene siden, eller for å finne alle bestillinger som inneholder dette produktet, på den andre. Det er klart at de tilsvarende programmene må implementere en mekanisme som gir slik navigering. Hvis navigering i bare én retning er nødvendig, indikeres det med en pil på slutten av tilknytningen. Et spesielt tilfelle av assosiasjon er aggregering - et forhold av formen "hele" - "del". Grafisk er den uthevet med en diamant på slutten nær essensen-helheten.
Generalisering er forholdet mellom en overordnet enhet og en underordnet enhet. I hovedsak gjenspeiler dette forholdet arveegenskapen for klasser og objekter. Generaliseringen vises som en linje som slutter med en trekant rettet mot den overordnede enheten. Barnet arver strukturen (attributtene) og atferden (metodene) til forelderen, men samtidig kan det få nye strukturelementer og nye metoder. UML tillater multippel arv, der en enhet er relatert til mer enn én overordnet enhet.
Gjennomføring– forholdet mellom en enhet som definerer en spesifikasjon av atferd (grensesnitt) med en enhet som definerer implementeringen av denne atferden (klasse, komponent). Dette forholdet brukes ofte ved modellering av komponenter og vil bli beskrevet mer detaljert i påfølgende artikler.

Diagrammer. UML gir følgende diagrammer:

Diagrammer som beskriver oppførselen til systemet:

Statlige diagrammer
Aktivitetsdiagrammer,
Objektdiagrammer,
Sekvensdiagrammer,
Samarbeidsdiagrammer;

Diagrammer som beskriver den fysiske implementeringen av systemet:

Komponentdiagrammer;
Implementeringsdiagrammer.

Modellkontrollvisning. Pakker.

Vi har allerede sagt at for at en modell skal bli godt forstått av mennesker, er det nødvendig å organisere den hierarkisk, og etterlate et lite antall enheter på hvert nivå i hierarkiet. UML inkluderer et middel for å organisere en hierarkisk representasjon av en modell - pakker. Enhver modell består av et sett med pakker som kan inneholde klasser, brukstilfeller og andre enheter og diagrammer. En pakke kan inneholde andre pakker, slik at det kan lages hierarkier. UML gir ikke separate pakkediagrammer, men de kan vises i andre diagrammer. Pakken er avbildet som et rektangel med et bokmerke.

Hva UML gir.

hierarkisk beskrivelse av et komplekst system ved å identifisere pakker;
formalisering av funksjonelle krav til systemet ved å bruke apparatet for brukstilfeller;
detaljering av systemkrav ved å konstruere aktivitetsdiagrammer og scenarier;
identifisere dataklasser og konstruere en konseptuell datamodell i form av klassediagrammer;
identifisere klasser som beskriver brukergrensesnittet og lage et skjermnavigasjonsskjema;
beskrivelse av prosessene for interaksjon mellom objekter når du utfører systemfunksjoner;
beskrivelse av objektadferd i form av aktivitets- og tilstandsdiagrammer;
beskrivelse av programvarekomponenter og deres interaksjon gjennom grensesnitt;
beskrivelse av den fysiske arkitekturen til systemet.

Og det siste...

Til tross for all attraktiviteten til UML, ville det være vanskelig å bruke i ekte programvaremodellering uten visuelle modelleringsverktøy. Slike verktøy lar deg raskt presentere diagrammer på skjermen, dokumentere dem, generere programkodemaler i ulike OO-programmeringsspråk og lage databaseskjemaer. De fleste av dem inkluderer muligheten for å omstrukturere programkoder - gjenopprette visse projeksjoner av programvaremodellen ved automatisk å analysere kildekoder til programmer, noe som er svært viktig for å sikre samsvar mellom modellen og kodene og når man designer systemer som arver funksjonaliteten til forgjengersystemer.

11.1. Strukturen til Unified Modeling Language

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 distribuert prosessering. Unified modeling language (UML). Versjon 1.4.2" (eng. "Information technology. Open distributed processing. 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.

Tabellen nedenfor gir en kort beskrivelse av 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)		Et sett med objekter som deler en felles struktur og atferd
	(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 systemet og bruker dets funksjonalitet til å oppnå bestemte mål eller løse spesifikke problemer. Dermed er en aktør en ekstern kilde eller mottaker av informasjon
	(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 de ovennevnte enhetene i samsvar med antyder deres detaljerte beskrivelse i 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		Et forhold som beskriver en meningsfull forbindelse mellom to eller flere enheter. Den mest generelle typen 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

Navn	Betegnelse	Definisjon (semantikk)
Stereotype (stereotype)	« »	En betegnelse som spesifiserer semantikken til et notasjonselement (for eksempel: en avhengighet med "inkluder"-stereotypen betraktes som en inklusjonsrelasjon, og en klasse med "grense"-stereotypen er en grenseklasse)
Vakttilstand (vakttilstand)		Boolsk tilstand (for eksempel: eller [identifikasjon fullført])
Begrensning (begrensning)	{ }	En regel som begrenser semantikken til et modellelement (for eksempel (utførelsestid mindre enn 10 ms))
Flagget verdi (merket verdi)	{ }	Ny eller tydeliggjørende egenskap for et notasjonselement (for eksempel: (versjon = 3.2))

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 er en gruppering av notasjonselementer for å vise et aspekt av informasjonssystemet som utvikles. Diagrammer er vanligvis en sammenhengende graf der entiteter er toppunkter og relasjoner er buer. Tabellen nedenfor gir en kort beskrivelse av UML-diagrammer.

Tabell 11.5. Diagrammer

Diagram			Hensikt
				i henhold til graden av fysisk gjennomføring	ved å vise dynamikk	etter vist aspekt
(brukstilfelle)			Viser systemfunksjoner, interaksjoner mellom aktører og funksjoner	Logisk	Statisk	Funksjonell
(klasse)			Viser et sett med klasser, grensesnitt og relasjoner mellom dem	Logisk eller fysisk	Statisk	Funksjonell og informativ
(pakke)			Viser et sett med pakker og relasjonene mellom dem	Logisk eller fysisk	Statisk	Komponent
Atferd (oppførsel)	(statsmaskin)		Viser tilstandene til en enhet og overganger mellom dem i løpet av dens livssyklus	Logisk	Dynamisk	Atferdsmessig
	(aktivitet)		Viser forretningsprosesser i systemet (beskrivelse av atferdsalgoritmer)
	Interaksjoner (interaksjon)	(sekvens)	Viser sekvensen av meldinger som går mellom objekter og aktører
		(kommunikasjon)	Ligner på et sekvensdiagram, men det er lagt vekt på strukturen av interaksjoner mellom objekter
Implementeringer (gjennomføring)	(komponent)		Viser systemkomponenter (programmer, biblioteker, tabeller osv.) og forbindelser mellom dem	Fysisk	Statisk	Komponent
	utplassering		Viser plasseringen av komponenter på nettverksnoder, samt konfigurasjonen

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 " ".

Unified Modeling Language (UML) er et språk for å spesifisere, visualisere, konstruere og dokumentere programvaresystemer, samt forretningsmodeller og andre ikke-programvaresystemer. UML er en kombinasjon av ingeniørteknikker som tidligere har vært vellykket brukt til å modellere store og komplekse systemer

Skaperne av UML presenterer det som et språk for å definere, representere, designe og dokumentere programvaresystemer, forretningssystemer og andre systemer av forskjellig karakter. UML definerer en notasjon og en metamodell. Notasjon er en samling av grafiske objekter som brukes i modeller; det er syntaksen til modelleringsspråket.

UML gir uttrykksfulle verktøy for å lage visuelle modeller som:

er ensartet forstått av alle utviklere som er involvert i prosjektet;
er et kommunikasjonsmiddel innenfor prosjektet.

Unified Modeling Language (UML):

er ikke avhengig av objektorienterte (OO) programmeringsspråk;
er ikke avhengig av prosjektutviklingsmetodikken som brukes;
kan støtte alle OO programmeringsspråk.

UML er åpen og har verktøy for å utvide den grunnleggende kjernen. UML kan brukes til meningsfullt å beskrive klasser, objekter og komponenter i forskjellige fagområder, ofte svært forskjellige fra hverandre.

UML-diagrammer

Rational Rose tilbyr følgende typer diagrammer til disposisjon for systemdesigneren, og den sekvensielle opprettelsen av disse lar deg få et fullstendig bilde av hele designet og dets individuelle komponenter:

Bruk case diagram;
Implementeringsdiagram (topologidiagrammer);
Statskart diagram;
Interaksjonsdiagram; Aktivitetsdiagram;
Sekvensdiagram;
Samarbeidsdiagram;
Klassediagram;
Komponentdiagram (komponentdiagrammer);
Atferdsdiagrammer;
Aktivitetsdiagram;
Implementeringsdiagrammer;

Hvert av disse diagrammene spesifiserer forskjellige ideer om systemmodellen. Samtidig representerer use case-diagrammet en konseptuell modell av systemet, som er utgangspunktet for å konstruere alle andre diagrammer. Et klassediagram er en logisk modell som gjenspeiler de statiske aspektene ved den strukturelle utformingen av et system, og atferdsdiagrammer, som også er typer av en logisk modell, gjenspeiler de dynamiske aspektene ved dets funksjon. Implementeringsdiagrammer tjener til å representere komponentene i et system og refererer til dets fysiske modell.

Av diagrammene oppført ovenfor tjener noen til å angi to eller flere underarter. Følgende diagrammer brukes som uavhengige representasjoner: brukstilfeller, klasser, tilstander, aktiviteter, sekvenser, samarbeid, komponenter og distribusjon.

For UML-diagrammer er det tre typer visuelle symboler som er viktige med tanke på informasjonen de inneholder:

kommunikasjon, som er representert av forskjellige linjer på planet;
tekst, inneholdt innenfor grensene til individuelle geometriske former;
grafiske symboler, avbildet nær de visuelle elementene i diagrammene.

Når du viser diagrammer grafisk, anbefales det å følge følgende regler:

hvert diagram må være en fullstendig representasjon av et eller annet fragment av det modellerte fagområdet;
modellenhetene presentert på diagrammet må være på samme konseptuelle nivå;
all informasjon om enheter må være tydelig presentert på diagrammet;
diagrammer skal ikke inneholde motstridende informasjon;
diagrammer bør ikke overbelastes med tekstinformasjon;
hvert diagram må være selvforsynt for riktig tolkning av alle dets elementer;
antall diagramtyper som kreves for å beskrive et spesifikt system er ikke strengt fastsatt og bestemmes av utvikleren;
systemmodeller skal bare inneholde de elementene som er definert i UML-notasjonen.

Enheter i UML

Det er fire typer enheter definert i UML: strukturell, atferdsmessig, gruppering og merknad. Entiteter er de viktigste objektorienterte elementene i språket som modeller lages med.

Strukturelle enheter er substantiv i UML-modeller. Vanligvis representerer de statiske deler av modellen, tilsvarende konseptuelle eller fysiske elementer i systemet. Eksempler på strukturelle enheter er "klasse", "grensesnitt", "samarbeid", "brukstilfelle", "komponent", "node", "aktør".

Atferdsmessige enheter er dynamiske komponenter i UML-modellen. Dette er verb som beskriver oppførselen til modellen i tid og rom. Det er to hovedtyper av atferdsmessige enheter:

interaksjon er atferd, hvis essens er utveksling av meldinger mellom objekter innenfor en bestemt kontekst for å oppnå et spesifikt mål;
automat - en atferdsalgoritme som definerer en sekvens av tilstander som et objekt eller interaksjon passerer som svar på ulike hendelser.

Gruppering av enheter er de organiserende delene av UML-modellen. Dette er blokker som modellen kan dekomponeres i. En slik primær enhet eksisterer i en enkelt kopi - dette er en pakke.

Pakker er en universell mekanisme for å organisere elementer i grupper. Strukturelle, atferdsmessige og andre grupperingsenheter kan plasseres i en pakke. I motsetning til komponenter som faktisk eksisterer mens programmet kjører, er pakker av rent konseptuell natur, det vil si at de kun eksisterer under utviklingsprosessen.

Annoteringsenheter- Dette er de forklarende delene av UML-modellen: kommentarer for ytterligere beskrivelse, presisering eller bemerkninger til ethvert element i modellen. Det er bare én grunnleggende type merknadselement - et notat. Notater brukes til å gi diagrammer med kommentarer eller begrensninger, uttrykt i uformell eller formell tekst.

Relasjoner i UML

Følgende typer relasjoner er definert i UML-språket: avhengighet, assosiasjon, generalisering og implementering. Disse relasjonene er de viktigste forbindelseskonstruksjonene til UML og brukes også som enheter for å bygge modeller.

Avhengighet- dette er et semantisk forhold mellom to enheter, der en endring i en av dem, uavhengig, kan påvirke semantikken til den andre, avhengige.

assosiasjon- et strukturelt forhold som beskriver et sett med semantiske eller logiske forbindelser mellom objekter.

Generalisering er et forhold der et spesialisert elementobjekt (etterkommer) kan erstattes med et generisk elementobjekt (forfedre). Samtidig, i samsvar med prinsippene for objektorientert programmering, arver en etterkommer (barn) strukturen og oppførselen til sin forfar (forelder).

Realisering er et semantisk forhold mellom klassifikatorer der den ene klassifisereren definerer en forpliktelse og den andre garanterer oppfyllelsen. Implementeringsforhold forekommer i to tilfeller:

mellom grensesnitt og klassene eller komponentene som implementerer dem;
mellom presedenser og samarbeidene som implementerer dem.

Vanlige UML-mekanismer

For å nøyaktig beskrive et system i UML, brukes såkalte generelle mekanismer:

spesifikasjoner;
tillegg (pynt);
felles inndelinger;
utvidelser (utvidbarhetsmekanismer).

UML er ikke bare et grafisk språk. Bak hvert grafisk element er det notasjonen spesifikasjon, som inneholder en tekstlig representasjon av den tilsvarende språkkonstruksjonen. For eksempel har et ikon for en klasse en spesifikasjon som beskriver dens attributter, operasjoner og oppførsel, men visuelt, i et diagram, gjenspeiler ikonet ofte bare en liten del av denne informasjonen. Dessuten kan modellen inneholde en annen representasjon av denne klassen, som gjenspeiler helt andre aspekter ved den, men likevel i samsvar med spesifikasjonen. Dermed brukes UML grafisk notasjon for å visualisere systemet, og bruker spesifikasjoner for å beskrive detaljene.

Nesten hvert UML-element har en unik grafisk representasjon som gir en visuell representasjon av de viktigste egenskapene. Entitetsnotasjonen "klasse" inneholder dens navn, attributter og operasjoner. Klassespesifikasjonen kan inneholde andre detaljer, for eksempel synligheten av attributter og operasjoner, kommentarer eller en indikasjon på at klassen er abstrakt. Mange av disse detaljene kan visualiseres som grafikk eller tekst. tillegg til et standard rektangel som representerer klassen.

Ved modellering av objektorienterte systemer er det en viss inndeling representerte enheter.

For det første er det en inndeling i klasser og objekter. En klasse er en abstraksjon, og et objekt er en konkret utførelse av den abstraksjonen. I denne forbindelse er nesten alle språkkonstruksjoner preget av klasse/objekt-dualitet. Dermed er det presedenser og forekomster av presedenser, komponenter og forekomster av komponenter, noder og forekomster av noder. I en grafisk representasjon er det vanlig å bruke samme symbol for et objekt som for en klasse, og understreke navnet.

For det andre er det en inndeling i et grensesnitt og implementeringen av det. Et grensesnitt erklærer forpliktelser, og en implementering representerer den konkrete implementeringen av disse forpliktelsene og sikrer at den erklærte semantikken følges nøyaktig. På grunn av dette er nesten alle UML-konstruksjoner preget av en grensesnitt/implementeringsdualitet. For eksempel implementeres presedenser ved samarbeid, og operasjoner implementeres med metoder.

UML er et åpent språk, det vil si at det lar kontrollerte utvidelser gjenspeile funksjonene til domenemodeller.

UML-utvidelsesmekanismer inkluderer:

stereotypier (stereotypier) - utvide UML-vokabularet, slik at du kan lage nye basert på eksisterende språkelementer, fokusert på å løse et spesifikt problem;
taggede verdier - utvide egenskapene til grunnleggende UML-konstruksjoner, slik at tilleggsinformasjon kan inkluderes i elementspesifikasjonen;
restriksjoner (begrensninger) - utvide semantikken til UML-konstruksjoner, slik at du kan lage nye og kansellere eksisterende regler.

Sammen lar disse tre språkutvidelsesmekanismene deg endre det i samsvar med prosjektets behov eller funksjonene til utviklingsteknologien.

Bruk case-diagram

Denne typen diagram lar deg lage en liste over operasjoner som systemet utfører. Ofte kalles denne typen diagram et funksjonsdiagram, fordi basert på et sett med slike diagrammer opprettes en liste med krav til systemet og settet med funksjoner som utføres av systemet.

Figur - 1. Brukscasediagram

Use case-diagrammer beskriver funksjonaliteten til et system eller hva systemet skal gjøre. Utviklingen av diagrammet har følgende mål:

bestemme de generelle grensene og konteksten til det modellerte fagområdet;
formulere generelle krav til den funksjonelle oppførselen til det utformede systemet;
utvikle en innledende konseptuell modell av systemet for dets påfølgende detaljering i form av logiske og fysiske modeller;
utarbeide innledende dokumentasjon for samspillet mellom systemutviklere og sine kunder og brukere.

Essensen av use case-diagrammet er som følger. Systemet som utformes er representert som et sett av enheter eller aktører som samhandler med systemet gjennom brukstilfeller. I dette tilfellet er en aktør eller aktør enhver enhet som samhandler med systemet fra utsiden. Dette kan være en person, en teknisk enhet, et program eller et hvilket som helst annet system som kan tjene som en kilde til innflytelse på det simulerte systemet som bestemt av utvikleren selv. Bruk case tjener til å beskrive tjenestene som systemet yter til aktøren.

Hensikten med en brukstilfelle er å definere et fullstendig aspekt eller fragment av oppførselen til en enhet uten å avsløre dens interne struktur. En slik enhet kan være et system eller et hvilket som helst element i modellen som har sin egen oppførsel.

Hvert brukstilfelle tilsvarer en egen tjeneste som den modellerte enheten leverer på forespørsel fra aktøren, det vil si at den bestemmer hvordan denne enheten skal brukes. En tjeneste som initialiseres på forespørsel fra en aktør er en komplett, udelelig sekvens av handlinger. Dette betyr at etter at systemet er ferdig med å behandle en forespørsel, må det gå tilbake til sin opprinnelige tilstand for å være klart til å behandle påfølgende forespørsler

Brukstilfeller kan brukes både til å spesifisere eksterne krav til systemet som skal designes, og for å spesifisere den funksjonelle oppførselen til et eksisterende system. Settet med brukstilfeller som helhet bør definere alle mulige aspekter av den forventede oppførselen til systemet. I tillegg stiller use cases implisitt krav som definerer hvordan aktører må samhandle med systemet for å kunne drifte tjenestene som tilbys korrekt. For enkelhets skyld kan mange brukstilfeller behandles som en egen pakke.

Eksempler på brukstilfeller kan omfatte følgende handlinger: sjekke statusen til kundens brukskonto, legge inn en bestilling for kjøp av varer, innhente tilleggsinformasjon om kundens kredittverdighet, vise et grafisk skjema på skjermen og annet handlinger.

klasseskjema

Den sentrale plassen i objektorientert programmering er utviklingen av en logisk modell av systemet i form av et klassediagram. Et klassediagram brukes til å representere den statiske strukturen til en systemmodell i terminologien til objektorienterte programmeringsklasser. Et klassediagram kan spesielt reflektere ulike relasjoner mellom individuelle domeneenheter, som objekter og undersystemer, samt beskrive deres interne struktur og typer relasjoner.

Figur - 2. Klassediagram

Diagramikoner lar deg vise et komplekst hierarki av systemer, relasjoner mellom klasser (klasser) og grensesnitt (grensesnitt). Denne typen diagram er i innhold motsatt av samarbeidsdiagrammet, som viser systemobjekter. Rational Rose lar deg lage klasser ved å bruke denne typen diagram i en rekke notasjoner. ligner på en sky. Dermed er en klasse bare en mal som et spesifikt objekt vil bli opprettet i henhold til i fremtiden.

Et klassediagram er en graf hvis toppunkter er elementer av typen "klassifiserer", forbundet med ulike typer strukturelle relasjoner. Et klassediagram kan også inneholde grensesnitt, pakker, relasjoner og til og med individuelle forekomster som objekter og relasjoner.

Klasse i UML-språket, tjener til å betegne et sett med objekter som har samme struktur, oppførsel og relasjoner med objekter fra andre klasser. Grafisk er en klasse avbildet som et rektangel, som i tillegg kan deles inn i seksjoner eller seksjoner med horisontale linjer. Disse delene kan inkludere klassenavnet, attributter (variabler) og operasjoner (metoder).

statskart diagram

Hvert tilstandsdiagram i UML beskriver alle mulige tilstander for en forekomst av en bestemt klasse og mulige sekvenser av overgangene fra en tilstand til en annen, det vil si at det modellerer alle endringer i tilstandene til et objekt som dets respons på eksterne påvirkninger.

Tilstandsdiagrammer brukes oftest for å beskrive oppførselen til individuelle objekter, men kan også brukes til å spesifisere funksjonaliteten til andre modellkomponenter, for eksempel brukstilfeller, aktører, undersystemer, operasjoner og metoder.

Figur - 2. Tilstandsdiagram

Et tilstandsdiagram er en spesiell type graf som representerer en bestemt automat. Toppene på grafen er de mulige tilstandene til maskinen, avbildet av de tilsvarende grafiske symbolene, og buene indikerer overgangene fra tilstand til tilstand. Tilstandsdiagrammer kan nestes for å gi en mer detaljert representasjon av individuelle modellelementer.

I UML-metamodellen maskin er en pakke som definerer mange konsepter som er nødvendige for å representere oppførselen til den modellerte enheten i form av et diskret rom med et begrenset antall tilstander og overganger.

Varigheten av at systemet er i en av de mulige tilstandene overskrider betydelig tiden brukt på overgang fra en tilstand til en annen. Det antas at i grensen kan overgangstiden være lik null (med mindre annet er spesifisert), det vil si at endringen i objekttilstander kan skje umiddelbart.

Oppførselen til automaten er modellert som sekvensiell bevegelse langs grafen fra toppunkt til toppunkt, og tar hensyn til orienteringen til buene som forbinder dem.

Følgende obligatoriske betingelser må oppfylles for maskinen:

tilstanden et objekt kan gå inn i bestemmes kun av dets nåværende tilstand og avhenger ikke av dets tidligere historie;
I hvert øyeblikk kan automaten bare være i én av tilstandene. Samtidig kan automaten forbli i en separat tilstand så lenge det er ønskelig dersom ingen hendelser inntreffer;
tiden maskinen er i en eller annen tilstand, samt tiden det tar å oppnå en eller annen tilstand, er ikke spesifisert på noen måte;
antall tilstander til automaten må være endelig og alle må spesifiseres eksplisitt. Individuelle pseudotilstander har kanskje ikke spesifikasjoner (start- og slutttilstander). I dette tilfellet er deres formål og semantikk fullstendig bestemt fra konteksten til modellen og tilstandsdiagrammet som vurderes;
Automatgrafen skal ikke inneholde isolerte tilstander og overganger. For hver tilstand, bortsett fra den opprinnelige, må en tidligere tilstand bestemmes, og hver overgang må koble to tilstander til maskinen;
automaten bør ikke inneholde motstridende overganger, når objektet samtidig kan gå over til to eller flere påfølgende tilstander (bortsett fra tilfellet med parallelle underautomater). I UML er konflikt eliminering mulig ved å innføre vaktforhold.

stat er grunnleggende ikke bare i UML-språkmetamodellen, men også i anvendt systemanalyse. Hele konseptet med et dynamisk system er basert på statsbegrepet. Tilstandssemantikken i UML-språket har en rekke spesifikke funksjoner.

I UML er en tilstand en abstrakt metaklasse som brukes til å modellere en spesifikk situasjon der visse betingelser er oppfylt. Tilstand kan spesifiseres som et sett med spesifikke klasse- eller objektattributtverdier. Endringer i individuelle attributtverdier vil reflektere endringer i tilstanden til klassen eller objektet som modelleres.

Aktivitetsdiagram

Når man modellerer oppførselen til et system som blir designet eller analysert, blir det nødvendig ikke bare å presentere prosessen med å endre tilstandene, men også å detaljere funksjonene til den algoritmiske og logiske implementeringen av operasjonene som utføres av systemet.

Faktisk kan denne typen diagram også brukes til å gjenspeile tilstandene til det modellerte objektet, men hovedformålet med aktivitetsdiagrammet er å gjenspeile forretningsprosessene til objektet. Denne typen diagram lar deg vise ikke bare sekvensen av prosesser, men også forgrening og til og med synkronisering av prosesser.

Denne typen diagram lar deg designe algoritmer for oppførselen til objekter av enhver kompleksitet, inkludert kan brukes til å tegne blokkdiagrammer.

For å modellere prosessen med å utføre operasjoner i UML-språket, brukes aktivitetsdiagrammer. Den grafiske notasjonen som brukes i dem ligner på mange måter notasjonen til et tilstandsdiagram, siden disse diagrammene også inneholder tilstands- og overgangssymboler. Hver tilstand i et aktivitetsdiagram tilsvarer fullføringen av en elementær operasjon, og overgangen til neste tilstand skjer bare når denne operasjonen er fullført.

Dermed kan aktivitetsdiagrammer betraktes som et spesialtilfelle av tilstandsdiagrammer. De lar deg implementere funksjonene til prosedyremessig og synkron kontroll på UML-språket på grunn av fullføringen av interne aktiviteter og handlinger. Hovedbruken av aktivitetsdiagrammer er å visualisere implementeringsfunksjonene til klasseoperasjoner, når det er nødvendig å presentere algoritmer for deres implementering.

I sammenheng med UML-språket aktivitet er et sett med individuelle beregninger utført av en automat, som fører til et resultat eller en handling. Et aktivitetsdiagram viser logikken og sekvensen av overganger fra en aktivitet til en annen, og fokuserer analytikerens oppmerksomhet på resultatene. Resultatet av en aktivitet kan resultere i en endring i systemets tilstand eller tilbakeføring av en verdi.

Handlingstilstand er et spesialtilfelle av en stat med en eller annen inputhandling og minst én overgang som forlater staten. Denne overgangen forutsetter implisitt at inndatahandlingen allerede er fullført. Handlingstilstanden kan ikke ha interne overganger fordi den er elementær. En vanlig bruk av en handlingstilstand er å modellere ett trinn i utførelsen av en algoritme (prosedyre) eller kontrollflyt.

Sekvensdiagram

Når man vurderer tilstands- og aktivitetsdiagrammer, ble det lagt merke til at selv om disse diagrammene brukes til å spesifisere dynamikken i systematferd, er tid ikke eksplisitt tilstede i dem. Det tidsmessige aspektet av atferd kan være betydelig når man modellerer synkrone prosesser som beskriver interaksjoner mellom objekter. For å modellere interaksjonen mellom objekter over tid, bruker UML sekvensdiagrammer.

Bare de gjenstander, som er direkte involvert i samhandlingen. Nøkkelen til sekvensdiagrammer er dynamikken i hvordan objekter samhandler over tid.

I UML har et sekvensdiagram to dimensjoner. Den første er fra venstre til høyre i form av vertikale linjer, som hver viser livslinjen til et separat objekt som deltar i interaksjonen. Objektet helt til venstre i diagrammet er det som setter i gang interaksjonen. Til høyre er et annet objekt som samhandler direkte med det første. Dermed danner alle objekter i et sekvensdiagram en eller annen rekkefølge, bestemt av rekkefølgen eller graden av aktivitet til objekter når de samhandler med hverandre.

Grafisk er hvert objekt avbildet som et rektangel og er plassert i den øvre delen av livslinjen. Inne i rektangelet skriver du objektnavnet og klassenavnet, atskilt med et kolon. I dette tilfellet er hele posten vektlagt, som er et tegn på objektet.

Den andre dimensjonen til et sekvensdiagram er den vertikale tidsaksen, rettet fra topp til bunn. Den øverste delen av diagrammet tilsvarer det første tidspunktet. Objektinteraksjoner implementeres gjennom meldinger sendt av ett objekt til et annet. Meldinger er avbildet som horisontale piler med meldingsnavnet, og rekkefølgen deres bestemmes av tidspunktet for forekomsten. Det vil si at meldinger som ligger høyere i sekvensdiagrammet initieres før de som ligger lavere. Skalaen på tidsaksen er ikke angitt, siden sekvensdiagrammet bare modellerer den tidsmessige rekkefølgen av "tidligere-senere" interaksjoner.

Samarbeidsdiagram

Hovedtrekket til et samarbeidsdiagram er muligheten til å grafisk representere ikke bare sekvensen av interaksjon, men også alle de strukturelle relasjonene mellom objektene som deltar i denne interaksjonen.

Figur - 3. Samarbeidsdiagram

Denne typen diagram lar deg beskrive interaksjonene til objekter, abstrahere fra sekvensen av meldingsoverføring. Denne typen diagram viser i en kompakt form alle mottatte og overførte meldinger til et bestemt objekt og typene av disse meldingene.

Først av alt viser samarbeidsdiagrammet objektene som deltar i interaksjonen i form av rektangler, som inneholder navnet på objektet, dets klasse og, muligens, attributtverdier. Videre, som i klassediagrammet, er assosiasjoner mellom objekter indikert i form av forskjellige forbindelseslinjer. I dette tilfellet kan du eksplisitt spesifisere navnene på foreningen og rollene som objekter spiller i denne foreningen. I tillegg kan dynamiske forbindelser - meldingsflyter - avbildes. De er også representert som forbindelseslinjer mellom objekter, over hvilke det er en pil som indikerer retningen, meldingsnavnet og sekvensnummeret i den generelle sekvensen for meldingsinitialisering.

I motsetning til et sekvensdiagram, viser et samarbeidsdiagram bare relasjonene mellom objekter som spiller spesifikke roller i interaksjonen. Dette diagrammet viser ikke tid som en egen dimensjon. Derfor kan sekvensen av interaksjoner og parallelle strømmer bestemmes ved hjelp av sekvensnummer. Derfor, hvis du trenger å spesifisere relasjonene mellom objekter i sanntid, er det bedre å gjøre dette i et sekvensdiagram.

Konsept samarbeid er et av de grunnleggende konseptene i UML-språket. Det tjener til å utpeke et sett med objekter som samhandler med et spesifikt formål i den generelle konteksten til det modellerte systemet. Formålet med selve samarbeidet er å spesifisere implementeringstrekk ved de enkelte viktigste operasjonene i systemet. Samarbeid definerer strukturen til systematferd når det gjelder interaksjonen mellom deltakerne i dette samarbeidet.

Samarbeid kan representeres på to nivåer:

spesifikasjonsnivå - viser rollene til klassifikatorer og rollene til assosiasjoner i interaksjonen som vurderes;
eksempelnivå - indikerer tilfeller og relasjoner som danner individuelle roller i samarbeid.

Et samarbeidsdiagram på spesifikasjonsnivå viser rollene som spilles av elementene som er involvert i samhandlingen. Samarbeidselementene på dette nivået er klasser og assosiasjoner, som betegner klassifiseres individuelle roller og assosiasjoner mellom deltakere i samarbeidet.

Samarbeidsdiagrammet på eksempelnivå er representert av et sett med objekter (forekomster av klasser) og forbindelser (forekomster av assosiasjoner). I dette tilfellet er forbindelsene supplert med meldingspiler. På dette nivået vises bare objekter som er direkte relatert til implementeringen av operasjonen eller klassifisereren. I dette tilfellet er det slett ikke nødvendig å skildre alle egenskaper eller alle assosiasjoner, siden samarbeidsdiagrammet bare inneholder rollene til klassifikatorer, men ikke selve klassifikatoren. Mens en klassifikator krever en fullstendig beskrivelse av alle dens forekomster, krever rollen til en klassifikator kun beskrivelsen av de egenskapene og assosiasjonene som er nødvendige for å delta i et bestemt samarbeid.

En viktig konsekvens følger av dette. Samme sett med objekter kan delta i ulike samarbeid. Avhengig av samarbeidet som vurderes, kan både egenskapene til enkeltobjekter og forbindelsene mellom dem endres. Det er dette som skiller et samarbeidsdiagram fra et klassediagram, som skal angi alle egenskapene og assosiasjonene mellom elementene i diagrammet.

Komponentdiagram

Denne typen diagram er ment å distribuere klasser og objekter mellom komponenter under den fysiske utformingen av et system. Denne typen diagram kalles ofte moduldiagrammer.

Figur - 4. Komponentdiagram

En komplett programvaresystemdesign er et sett med modeller av logiske og fysiske nivåer som må være i samsvar med hverandre. UML-språket bruker implementeringsdiagrammer for fysisk å representere systemmodeller, som inkluderer komponentdiagram Og distribusjonsdiagram.

Et komponentdiagram, i motsetning til de tidligere diskuterte diagrammene, beskriver funksjonene til den fysiske representasjonen av systemet. Den lar deg bestemme arkitekturen til systemet som utvikles ved å etablere avhengigheter mellom programvarekomponenter, som kan være kildekode og kjørbar kode. De viktigste grafiske elementene i et komponentdiagram er komponenter, grensesnitt og avhengigheter mellom dem.

Komponentdiagrammet er utviklet for følgende formål:

visualisering av den generelle strukturen til kildekoden til programvaresystemet;
spesifikasjoner for den kjørbare versjonen av programvaresystemet;
sikre gjenbruk av individuelle programkodefragmenter;
representasjoner av konseptuelle og fysiske databaseskjemaer.

Både systemanalytikere og arkitekter, samt programmerere, deltar i utviklingen av komponentdiagrammer. Et komponentdiagram gir en konsistent overgang fra en logisk representasjon til en konkret implementering av et prosjekt i form av programvarekode. Noen komponenter kan bare eksistere på stadiet av kompilering av programkoden, andre på stadiet av utførelse. Et komponentdiagram gjenspeiler de generelle avhengighetene mellom komponenter, og behandler sistnevnte som klassifikatorer.

For å representere fysiske enheter på UML-språket, brukes en spesiell term - komponent. Komponenten implementerer et visst sett med grensesnitt og tjener til generelt å betegne elementene i den fysiske representasjonen av modellen. For å representere en komponent grafisk, brukes et spesielt symbol - et rektangel med to mindre rektangler satt inn til venstre. Inne i det store rektangelet er navnet på komponenten og om nødvendig litt tilleggsinformasjon. Utseendet til dette symbolet kan variere litt avhengig av informasjonen knyttet til komponenten.

Implementeringsdiagram

Denne typen diagram er ment for å analysere maskinvaren til systemet, det vil si maskinvare, ikke programmer. Direkte oversatt fra engelsk betyr Deployment "distribusjon", men begrepet "topologi" gjenspeiler mer nøyaktig essensen av denne typen diagram.

Figur - 5. Implementeringsdiagram

Den fysiske representasjonen av et programvaresystem kan ikke være fullstendig hvis det ikke er informasjon om hvilken plattform og på hvilke databehandlingsmidler det er implementert. Hvis det utvikles et program som kjører lokalt på brukerens datamaskin og ikke bruker perifere enheter og ressurser, er det ikke nødvendig å utvikle flere diagrammer. Når du utvikler bedriftsapplikasjoner, kan tilstedeværelsen av slike diagrammer være ekstremt nyttige for å løse problemer med rasjonell plassering av komponenter for effektivt å bruke distribuerte databehandlings- og kommunikasjonsressurser i nettverket, for å sikre sikkerhet og andre.

Distribusjonsdiagrammer brukes til å representere den generelle konfigurasjonen og topologien til et distribuert programvaresystem i UML.

Distribusjonsdiagrammet er utformet for å visualisere elementene og komponentene i et program som bare eksisterer på kjøretidsstadiet. I dette tilfellet er bare programforekomstkomponenter, som er kjørbare filer eller dynamiske biblioteker, representert. De komponentene som ikke brukes under kjøretid, vises ikke i distribusjonsdiagrammet. Dermed kan komponenter med programkildekoder bare være til stede på komponentdiagrammet. De er ikke angitt på distribusjonsdiagrammet.

Distribusjonsdiagrammet inneholder grafiske representasjoner av prosessorer, enheter, prosesser og forbindelser mellom dem. I motsetning til logiske representasjonsdiagrammer, er et distribusjonsdiagram enhetlig for systemet som helhet, siden det fullt ut må reflektere funksjonene til implementeringen. Å utvikle et distribusjonsdiagram er vanligvis det siste trinnet i å spesifisere en programvaresystemmodell.

Når du utvikler et distribusjonsdiagram, etterstrebes følgende mål:

bestemme fordelingen av systemkomponenter på tvers av dets fysiske noder;
vise fysiske forbindelser mellom alle noder i systemimplementeringen på utførelsesstadiet;
identifisere systemflaskehalser og rekonfigurere topologien for å oppnå den nødvendige ytelsen.

Implementeringsdiagrammer er utviklet i fellesskap av systemanalytikere, nettverksingeniører og systemteknikere.

Funksjoner i arbeidsgrensesnittet Rational Rose

Rational Rose CASE-verktøyet implementerer generelt aksepterte standarder for programmets operative grensesnitt, i likhet med velkjente visuelle programmeringsmiljøer. Etter å ha installert Rational Rose på brukerens datamaskin, noe som praktisk talt ikke forårsaker vanskeligheter selv for nybegynnere, fører lansering av dette programmet i MS Windows 95/98 til utseendet til et fungerende grensesnitt på skjermen (fig. 6).

Figur - 6. Generell oversikt over arbeidsgrensesnittet til Rational Rose-programmet

Betjeningsgrensesnittet Rational Rose består av forskjellige elementer, de viktigste er:

Hovedmeny for programmet
Diagramvindu
Dokumentasjonsvindu
Nettleservindu
Loggvindu

La oss kort vurdere formålet og hovedfunksjonene til hvert av disse elementene.

Hovedmeny for programmet

Hovedmenyen til programmet er laget i den allment aksepterte standarden og ser slik ut (fig. 7).

Individuelle menyelementer, hvis formål er tydelig fra navnene deres, kombinerer lignende operasjoner relatert til hele prosjektet som helhet. Noen av menyelementene inneholder velkjente funksjoner (åpne et prosjekt, skrive ut diagrammer, kopiere til og lime inn ulike diagramelementer fra utklippstavlen). Andre er så spesifikke at de kan kreve ekstra innsats for å studere (alternativer for kodegenerering, kontroll av modellkonsistens, tilkobling av tilleggsmoduler).

Figur - 7. Utseendet til hovedmenyen til programmet

Standard verktøylinje

Standardverktøylinjen er plassert under hovedmenyen til programmet og ser slik ut (fig. 8). Noen av verktøyene er ikke tilgjengelige (det nye prosjektet har ingen elementer). Standardverktøylinjen gir rask tilgang til menykommandoene som utviklere bruker oftest.

Figur 8. Utseendet til standardverktøylinjen

Brukeren kan tilpasse utseendet til dette panelet etter eget skjønn. For å gjøre dette, velg menypunktet Verktøy -> Alternativer og åpne fanen Verktøylinjer. På denne måten kan du vise eller skjule ulike verktøyknapper og endre størrelsen på dem.

Nettleservindu

Standard nettleservindu er plassert på venstre side av arbeidsgrensesnittet under standardverktøylinjen (fig. 9).

Nettleseren organiserer modellvisninger i en hierarkisk struktur som forenkler navigering og lar deg finne et hvilket som helst modellelement i prosjektet. I dette tilfellet vises ethvert element som utvikleren legger til modellen umiddelbart i nettleservinduet. Følgelig, ved å velge et element i nettleservinduet, kan vi visualisere det i diagramvinduet eller endre spesifikasjonen. Nettleseren lar deg også organisere modellelementer i pakker og flytte elementer mellom ulike visninger av modellen. Om ønskelig kan nettleservinduet plasseres et annet sted i arbeidsgrensesnittet eller skjules helt ved å bruke menypunktet Vis. Du kan også endre størrelse på nettleseren ved å dra den ytre rammen med musen.

Figur - 9. Utseende på nettleseren

Spesiell verktøylinje

En spesiell verktøylinje er plassert mellom nettleservinduet og kartvinduet i den midtre delen av arbeidsgrensesnittet. Som standard tilbys en verktøylinje for å konstruere et modellklassediagram (fig. 10).

Figur - 10. Utseende til en spesiell verktøylinje for et klassediagram

Plasseringen av spesialverktøylinjen kan endres ved å flytte panelrammen til ønsket plassering. Du kan også tilpasse sammensetningen av panelet ved å legge til eller fjerne individuelle knapper som tilsvarer bestemte verktøy. Knappetilordninger kan læres fra verktøytips som vises etter at musepekeren holder musepekeren over den tilsvarende knappen.

Diagramvindu

Diagramvinduet er hovedarbeidsområdet for grensesnittet, der ulike visninger av prosjektmodellen er visualisert. Som standard er diagramvinduet plassert på høyre side av arbeidsgrensesnittet, men plasseringen og størrelsen kan også endres. Når du utvikler et nytt prosjekt, hvis prosjektveiviseren ikke har blitt brukt, er diagramvinduet et tomt område som ikke inneholder noen modellelementer (fig. 11).

Navnet på diagrammet som er plassert i dette vinduet er indikert i tittellinjen til programmet (den øverste linjen i programmet) eller, hvis vinduet ikke er maksimert til fullskjerm, i tittellinjen i kartvinduet. Flere kart kan være tilstede i kartvinduet samtidig, men bare ett av dem kan være aktivt. For eksempel, i fig. 11 det aktive diagrammet er distribusjonsdiagrammet, selv om det finnes andre diagrammer. Bytte mellom diagrammer kan gjøres ved å velge ønsket visning på standardverktøylinjen eller gjennom menypunktet Vindu. Når du aktiverer en separat kartvisning, endres utseendet til en spesiell verktøylinje, som er tilpasset den spesifikke kartvisningen.

Figur - 11. Utseende av diagramvinduet med forskjellige typer modellvisninger

Dokumentasjonsvindu

Dokumentasjonsvinduet er kanskje ikke til stede på skjermen som standard. I dette tilfellet kan den aktiveres gjennom menypunktet Vis -> Dokumentasjon, hvoretter den vises under nettleseren (fig. 12).

Dokumentasjonsvinduet, som navnet antyder, er designet for å dokumentere elementene i en modellvisning. Du kan registrere et bredt utvalg av informasjon i den, og hva som er viktig - på russisk. Denne informasjonen blir deretter konvertert til kommentarer og påvirker ikke på noen måte utførelseslogikken til programkoden.

I dokumentasjonsvinduet aktiveres informasjonen som gjelder det enkelte valgte elementet i diagrammet. I dette tilfellet kan du velge et element enten i nettleservinduet eller i diagramvinduet. Når du legger til et nytt element i diagrammet (for eksempel en klasse), genereres det automatisk dokumentasjon for det, som er tomt (Ingen dokumentasjon). Deretter legger utvikleren uavhengig inn nødvendig forklarende informasjon, som huskes og kan endres under arbeidet med prosjektet.

Akkurat som for andre vinduer i arbeidsgrensesnittet, kan du endre størrelsen og plasseringen av dokumentasjonsvinduet.

Figur - 12. Utseendet til dokumentasjonsvinduet

Loggvindu

Loggvinduet er designet for automatisk å registrere forskjellig tjenesteinformasjon som genereres mens du arbeider med programmet. Loggen registrerer tiden og arten av handlinger utført av utvikleren, for eksempel oppdatering av modellen, tilpasning av menyer og verktøylinjer, samt feilmeldinger som oppstår ved generering av programkode.

Loggvinduet er alltid til stede på arbeidsgrensesnittet i diagramvinduet (fig. 13). Det kan imidlertid være skjult av andre kartvinduer eller minimert. Du kan aktivere loggvinduet gjennom Vindu->Logg-menyen. I dette tilfellet vises det på toppen av andre vinduer i høyre område av arbeidsgrensesnittet. Dette vinduet kan ikke fjernes helt, det kan bare minimeres.

Figur - 13. Loggvinduets utseende

Konklusjon

Over tid vil UML-språket bli "esperanto" der matematikere, systemanalytikere, fysikere, programmerere, ledere, økonomer og spesialister fra andre profesjoner vil kunne kommunisere og presentere sin faglige kunnskap i en enhetlig form. Tross alt, i hovedsak opererer hver av spesialistene med modellrepresentasjoner innen sitt kunnskapsfelt. Og det er nettopp dette modellaspektet som kan spesifiseres ved hjelp av UML-språket.

I denne forbindelse øker betydningen av UML-språket betydelig, siden det i økende grad tilegner seg egenskapene til et kunnskapsrepresentasjonsspråk. Samtidig gjør tilstedeværelsen i UML-språket av visuelle midler for å representere strukturen og oppførselen til modellen det mulig å oppnå en adekvat representasjon av deklarativ og prosedyrekunnskap og, ikke mindre viktig, å etablere semantisk samsvar mellom disse formene for kunnskap. Alle disse funksjonene til UML-språket lar oss konkludere med at det har de mest seriøse utsiktene i nær fremtid.

Denne artikkelen utforsker den nye æraen for programvareutvikling, hvordan den påvirker nye UML-krav, og beste praksis for å oppfylle dem.
7. "Datamodellering i Rational Rose" Sergey Trofimov Beskriver modelleringen av den fysiske representasjonen av data ved hjelp av Rational Rose
8. UML-språk. Generell forståelse av UML-språket: strukturer, grafiske elementer og diagrammer av språket.
9. Praktisk UML. Dette dokumentet er en oversettelse av dokumentet "Praktisk UML. En praktisk introduksjon for utviklere". Praktisk introduksjon for utviklere
10. "Standard objektorientert modelleringsspråk UML" Vendrov Alexander Mikhailovich. UMLs historie
11. UML – enhetlig modelleringsspråk. Dette materialet inneholder innledende informasjon om metoder for å beskrive programvaresystemer og notasjoner som brukes i UML
12. UML-språk. Brukerhåndboken. Forfattere: Grady Booch, James Rumbaugh, Ivar Jacobson
13. "UML-diagrammer i Rational Rose" Sergey Trofimov
14. "Analyse og design. Visuell modellering (UML) Rational Rose" Konstantin Domolego
15. Gennady Vernikovs bibliotek. Fullstendige beskrivelser av design- og modelleringsstandarder.
16. "Et eksempel på å beskrive et fagområde ved bruk av UML ved utvikling av programvaresystemer" E.B. Zolotukhina, R.V. Alfimov. Artikkelen bruker et spesifikt eksempel for å demonstrere en mulig tilnærming til domenemodellering basert på bruken av Unified Modeling Language (UML)