Hvilke typer linjer brukes i uml-diagrammer. Grunnleggende UML-diagrammer

Alle UML-diagrammer kan deles inn i to grupper, hvorav den første er generelle diagrammer. Generelle diagrammer er praktisk talt uavhengige av emnet modellering og kan brukes i ethvert programvareprosjekt uten hensyn til fagområde, løsningsområde osv.

1.5.1. Bruksdiagram

Bruksdiagram(use case diagram) er den mest generelle representasjonen av systemets funksjonelle formål.

Bruksdiagrammet er designet for å svare på hovedmodelleringsspørsmålet: hva gjør systemet i omverdenen?

Et bruksdiagram bruker to typer kjerneenheter: brukstilfeller 1 og aktører 2, mellom hvilke følgende grunnleggende typer relasjoner etableres:

assosiasjon mellom aktør og brukscase 3;
generalisering mellom aktører 4 ;
generalisering mellom brukstilfeller 5 ;
avhengigheter (av ulike typer) mellom brukstilfeller 6.

Et bruksdiagram, som alle andre diagrammer, kan inneholde kommentarer 7 . Dessuten anbefales dette sterkt for å forbedre lesbarheten til diagrammene.

Hovedelementene i notasjonen som brukes i bruksdiagrammet er vist nedenfor. En detaljert beskrivelse er gitt i avsnitt 2.2.

1.5.2. Klassediagram

Klassediagram(klassediagram) er hovedmåten for å beskrive strukturen til et system.

Dette er ikke overraskende, siden UML først og fremst er et objektorientert språk, og klasser er den viktigste (om ikke den eneste) byggesteinen.

Et klassediagram bruker én grunnleggende enhetstype: klasse 1 (inkludert mange spesielle tilfeller av klasser: grensesnitt, primitive typer, assosiasjonsklasser og mange andre), mellom hvilke følgende grunnleggende typer relasjoner er etablert:

assosiasjon mellom 2 klasser (med mange tilleggsdetaljer);
generalisering mellom klassene 3;
avhengigheter (av ulike typer) mellom klasse 4 og mellom klasser og grensesnitt.

Noen av notasjonen som brukes i et klassediagram er vist nedenfor. En detaljert beskrivelse er gitt i kapittel 3.

1.5.3. Maskindiagram

Maskindiagram(state machine diagram) er en av måtene å beskrive atferd i detalj i UML basert på eksplisitt identifisering av tilstander og beskrivelse av overganger mellom stater.

I hovedsak er automatdiagrammer, som navnet antyder, en graf over tilstandsoverganger (se kapittel 4) lastet med mange tilleggsdetaljer og detaljer.

På et automatdiagram brukes en hovedtype enhet - tilstander 1, og en type relasjon - overganger 2, men for begge er mange varianter, spesielle tilfeller og tilleggsnotasjoner definert. Det er ingen vits i å liste dem alle i en innledende anmeldelse.

En detaljert beskrivelse av alle variasjoner av automatdiagrammer er gitt i avsnitt 4.2, og den følgende figuren viser bare hovedelementene i notasjonen som brukes i automatdiagrammet.

1.5.4. Aktivitetsdiagram

Aktivitetsdiagram(aktivitetsdiagram) - en måte å beskrive atferd basert på å spesifisere kontrollflyter og dataflyter.

Et aktivitetsdiagram er en annen måte å beskrive atferd som visuelt minner om et godt gammelt algoritmeflytskjema. På grunn av den moderniserte notasjonen i samsvar med den objektorienterte tilnærmingen, og viktigst av alt, på grunn av den nye semantiske komponenten (fri tolkning av Petri-nett), er UML-aktivitetsdiagrammet et kraftig verktøy for å beskrive oppførselen til systemet.

Aktivitetsdiagrammet bruker én hovedtype enhet – handling 1, og én type relasjon – overganger 2 (overføringer av kontroll og data). Også brukt er slike konstruksjoner som gafler, fusjoner, forbindelser, grener 3, som ligner på enheter, men faktisk er de ikke det, men er en grafisk måte å skildre noen spesielle tilfeller av relasjoner med flere steder. Semantikken til aktivitetsdiagramelementer diskuteres i detalj i kapittel 4. Hovedelementene i notasjon som brukes i et aktivitetsdiagram er vist nedenfor.

1.5.5. Sekvensdiagram

Sekvensdiagram(sekvensdiagram) er en måte å beskrive oppførselen til et system basert på å angi sekvensen av overførte meldinger.

Faktisk er et sekvensdiagram en registrering av protokollen til en spesifikk sesjon av systemet (eller et fragment av en slik protokoll). I objektorientert programmering er det viktigste ved kjøring overføring av meldinger mellom kommuniserende objekter. Det er sekvensen for meldingssending som vises i dette diagrammet, derav navnet.

Et sekvensdiagram bruker én hovedtype enhet - forekomster av interagerende klassifikatorer 1 (hovedsakelig klasser, komponenter og aktører), og en type relasjon - forbindelser 2 som meldinger utveksles langs 3. Det er flere måter å sende meldinger på, som i grafisk notasjon er forskjellig i hvilken type pil som tilsvarer relasjonen.

Et viktig aspekt ved et sekvensdiagram er å tydelig vise tidens gang. I motsetning til andre typer diagrammer, bortsett fra kanskje synkroniseringsdiagrammer, er det i et sekvensdiagram viktig ikke bare tilstedeværelsen av grafiske forbindelser mellom elementer, men også den relative plasseringen av elementene på diagrammet. Det antas nemlig at det er en (usynlig) tidsakse, som standard, rettet fra topp til bunn, og meldingen som sendes senere er tegnet under.

Tidsaksen kan rettes horisontalt, i så fall anses tiden å flyte fra venstre til høyre.

Følgende figur viser den grunnleggende notasjonen som brukes i et sekvensdiagram. For å utpeke selve de samvirkende objektene, brukes en standardnotasjon - et rektangel med navnet på klassifiseringsforekomsten. Den stiplede linjen som kommer ut av den kalles livslinjen 4. Dette er ikke en representasjon av et forhold i modellen, men en grafisk kommentar designet for å veilede leseren av diagrammet i riktig retning. Figurer i form av smale striper lagt på livlinjen er heller ikke bilder av de simulerte enhetene. Dette er en grafisk kommentar som viser tidsperioder som objektet eier kontrollflyten (utførelsesforekomst) 5 eller, med andre ord, aktiveringen av objektet finner sted. Kombinerte fragmenttrinn 6 lar sekvensdiagrammet gjenspeile de algoritmiske aspektene ved interaksjonsprotokollen. For andre detaljer om sekvensdiagramnotasjon, se kapittel 4.

1.5.6. Kommunikasjonsdiagram

Kommunikasjonsdiagram(kommunikasjonsdiagram) er en måte å beskrive atferd på som er semantisk ekvivalent med et sekvensdiagram.

Faktisk er dette den samme beskrivelsen av sekvensen for meldingsutveksling av interagerende forekomster av klassifiserere, kun uttrykt med andre grafiske midler. Dessuten kan de fleste verktøy automatisk konvertere sekvensdiagrammer til kommunikasjonsdiagrammer og omvendt.

Således, i kommunikasjonsdiagrammet, så vel som i sekvensdiagrammet, brukes en hovedtype enhet - forekomster av interagerende klassifikatorer 1 og en type relasjon - forbindelser 2. Men her legges ikke vekten på tid, men på strukturen av sammenhenger mellom spesifikke instanser.

Figuren viser hovedelementene i notasjon brukt i et kommunikasjonsdiagram. For å utpeke selve de samvirkende objektene, brukes en standardnotasjon - et rektangel med navnet på klassifiseringsforekomsten. Den relative plasseringen av elementene i samarbeidsdiagrammet spiller ingen rolle - bare forbindelsene (oftest tilfeller av assosiasjoner) som meldinger sendes langs er viktige. Hierarkisk desimalnummerering brukes for å vise rekkefølgen på meldinger over tid.

1.5.7. Komponentdiagram

Komponentdiagram(komponentdiagram) - viser relasjonene mellom modulene (logiske eller fysiske) som utgjør det modellerte systemet.

Hovedtypen av enheter i et komponentdiagram er selve komponentene 1, samt grensesnitt 2, gjennom hvilke forholdet mellom komponentene er indikert. Følgende relasjoner gjelder i et komponentdiagram:

implementeringer mellom komponenter og grensesnitt (en komponent implementerer et grensesnitt);
avhengigheter mellom komponenter og grensesnitt (komponenten bruker grensesnittet) 3.

Figuren viser hovedelementene i notasjonen som brukes i et komponentdiagram. En detaljert beskrivelse er gitt i kapittel 3.

1.5.8. Plasseringsdiagram

Plasseringsdiagram(distribusjonsdiagram), sammen med visning av sammensetningen og tilkoblingene til systemelementer, viser hvordan de fysisk er plassert på dataressurser ved kjøring.

I et plasseringsdiagram, sammenlignet med et komponentdiagram, legges det til to typer enheter: artefakt 1, som er en implementering av komponent 2 og node 3 (kan enten være en klassifikator som beskriver nodetypen eller en spesifikk forekomst). så vel som assosiasjonsforholdet mellom nodene 4, som viser at nodene er fysisk tilkoblet ved kjøretid.

Figuren viser hovedelementene i notasjonen som brukes i et layoutdiagram. For å vise at en enhet er en del av en annen, brukes enten en "deploy"-avhengighetsrelasjon 5 eller en figur av en enhet plasseres inne i en figur av en annen enhet 6 . En detaljert beskrivelse av diagrammet er gitt i kapittel 3.

Vis oppførselen til en gjenstand i løpet av dens levetid, fra opprettelsen av gjenstanden til dens ødeleggelse. Hvert tilstandsdiagram representerer en eller annen automat.

Handlingsplan

I beskrivelsesdelen lærer du det grunnleggende settet med tilstandskartsymboler som trengs for å kunne lese diagrammer.

Etter å ha lest de andre delene (eksempel, applikasjon), kan du prøve deg på å lage tilstandsdiagrammer selv.

Merknader (beskrivelse)

Her er det grunnleggende tegnsettet tilstandsdiagrammer, nødvendig for å kunne lese diagrammet. Etter å ha lest de andre delene ("Eksempel", "Søknad") vil du kunne skrive tilstandsdiagrammer på egenhånd!

Begrep	Bilde	Beskrivelse
Opprinnelig pseudostat		Systemets opprinnelige tilstand
Overgang		Overgang betyr å flytte fra en tilstand til en annen.
Stat		Angir handlingene som utføres av systemet (kan inkludere mulige alternativer) som fører til resultatene observert av aktørene.
Stat aktivitetstilstand		Et vanskelig trinn i en presedens kan representeres av en annen presedens. I UML-termer sier vi at den første brukssaken inkluderer den andre.
Endelig tilstand		Lar deg definere grensene for systemer eller undersystemer.
Interne aktiviteter		Tilfellet der stater kan reagere på hendelser uten å gjøre en overgang, i så fall plasseres hendelsen, beskyttelsen og aktiviteten inne i tilstandsrektangelet.
Inndataaktivitet		Inndataaktiviteten utføres hver gang du går inn i en tilstand
Utgangsaktivitet		Avslutt aktivitet – Utføres når du forlater staten.
Superstat		Det hender ofte at flere stater har felles overganger og interne aktiviteter. I slike tilfeller kan de gjøres om til substater, og den generelle atferden kan overføres til en superstat.
Parallelle tilstander		Stater kan deles inn i flere parallelle tilstander som kjører samtidig.

Hvordan bruke kreativitetsteknikker

UML-statskjemaer er gode for å beskrive oppførselen til et enkelt objekt på tvers av flere brukstilfeller. Men de er lite egnet for å beskrive atferd preget av samspillet mellom mange objekter. Derfor er det fornuftig å bruke andre teknologier i forbindelse med tilstandsdiagrammer. For eksempel gjør interaksjonsdiagrammer (kapittel 4) en utmerket jobb med å beskrive oppførselen til flere objekter i et enkelt brukstilfelle, og UML-aktivitetsdiagrammer er gode for å vise den grunnleggende handlingssekvensen til flere objekter i flere brukstilfeller.

Ikke alle anser tilstandsdiagrammer som naturlige. Se hvordan eksperter jobber med dem. Det er mulig at teammedlemmene dine ikke tror at statsdiagrammer er riktige for arbeidsstilen deres. Dette er ikke den største vanskeligheten; du må huske å bruke ulike arbeidsteknikker sammen.

Hvis du bruker tilstandsdiagrammer, ikke prøv å tegne dem for hver klasse i systemet. Denne tilnærmingen brukes ofte for formelt streng fullstendighet, men det er nesten alltid bortkastet innsats. Bruk kun statecharts for klasser som viser interessant oppførsel der tegning av et statechart hjelper deg å forstå hvordan ting skjer.

Mange eksperter mener det UI-editoren og kontrollobjektene har funksjonalitet som er nyttig når de vises ved hjelp av et tilstandsdiagram.

Hvordan lære

Her har vi forsøkt å gi en så enkel måte som mulig å lære på UML tilstandsdiagrammer.

Som mange andre språk, bruker den et sett med symboler for beskrivelse. Betydningen av disse skiltene finner du i tabellen i delen "Notater (beskrivelse)". Hvert tegn har sitt eget navn (begrep) og stavemåte. Hvert begrep er også utstyrt med en kort forklaring for raskt å forstå den grunnleggende essensen.

Deretter vil vi anbefale å gå til delen "Eksempler". tilstandsdiagrammerå prøve deg på å lese forskjellige diagrammer. Da er det verdt å studere avsnittet "Søknad", siden selv om antallet diagramtyper i UML er lite, kan du få maksimalt utbytte av bruken bare hvis du bruker de tilsvarende diagrammene til deres tiltenkte formål.

Eksempel på bruk

Statlige maskindiagrammer er en velkjent teknologi for å beskrive oppførselen til et system. Tilstandsdiagrammer har eksistert i en eller annen form siden 1960, og i de første dagene av objektorientert programmering ble de brukt til å representere oppførselen til et system. I objektorienterte tilnærminger tegner du et tilstandsdiagram for en enkelt klasse for å vise oppførselen til et enkelt objekt i løpet av levetiden.

Når det skrives om finite state-maskiner, inkluderer eksempler uunngåelig cruisekontrollsystemer eller salgsautomater.
Vi bestemte oss for å bruke en hemmelig kontrollpanelkontroller i et gotisk slott. I dette slottet ønsker vi å gjemme skattene våre slik at de er vanskelige å finne. For å få tilgang til safens lås må vi fjerne det strategiske stearinlyset fra kandelaberen, men låsen vises kun hvis døren er lukket. Etter at låsen vises, kan vi sette nøkkelen inn i den og åpne safen. For ekstra sikkerhet har vi laget det slik at safen først kan åpnes etter at lyset er fjernet. Hvis tyven ikke tar hensyn til denne forholdsregelen, vil vi slippe løs et ekkelt monster som vil svelge tyven.

I fig. 10.1 vist tilstandsdiagram en kontrollerklasse som styrer mitt fancy sikkerhetssystem. Tilstandsdiagrammet begynner med tilstanden til kontrollerobjektet som opprettes: tilstand Vente. Dette er indikert i diagrammet med innledende pseudostat, som ikke er en tilstand, men har en pil som peker til starttilstanden.
Diagrammet viser at kontrolleren kan være i en av tre tilstander: Vent, lås og åpne. Diagrammet viser også reglene som kontrolleren går over fra en tilstand til en annen. Disse reglene presenteres i form av overganger - linjer som forbinder stater.

Overgang betyr å flytte fra en tilstand til en annen. Hver overgang har sin egen etikett, som består av tre deler:
trigger-signatur /aktivitet. Alle er valgfrie. Som oftest, trigger-id er den eneste hendelsen som kan forårsake en tilstandsendring.

Vakten, hvis spesifisert, er en logisk betingelse som må være oppfylt for at overgangen skal finne sted. Aktivitet er en oppførsel av systemet under en overgang. Dette kan være et hvilket som helst atferdsuttrykk. Full form for en ID-utløser kan inkludere flere hendelser og parametere. Overgangen fra ventetilstanden (fig. 10.1) til en annen tilstand kan leses som "I ventetilstanden, hvis stearinlyset er fjernet, ser du en lås og går til låsetilstanden."

Alle tre delene av overgangsbeskrivelsen er valgfrie. Å hoppe over aktivitet betyr at det ikke skjer noe under overgangen. Skip shields betyr at overgangen alltid gjøres hvis en triggerhendelse inntreffer. Trigger-ID-en mangler sjelden, men det skjer. Dette betyr at overgangen skjer umiddelbart, noe som hovedsakelig kan observeres i aktive tilstander.

Når en hendelse inntreffer i en bestemt tilstand, kan det bare gjøres én overgang fra denne tilstanden, for eksempel i låsetilstanden (fig. 10.1), må beskyttelsene være gjensidig utelukkende. Hvis en hendelse inntreffer og det ikke er tillatte overganger - for eksempel lukking av en safe i ventetilstand eller fjerning av et stearinlys mens døren er åpen - ignoreres hendelsen.

Endelig tilstand ( endelig tilstand) betyr at tilstandsmaskinen har kjørt ferdig, noe som fører til at kontrollerobjektet blir slettet. Så for de som var uforsiktige nok til å gå i fellen, siden kontrollobjektet slutter å eksistere, er vi tvunget til å sette kaninen tilbake i buret, tørke gulvet og starte systemet på nytt.

Husk at statsmaskiner bare kan vise objekter som er direkte observert eller aksjonert på. Så selv om du kanskje forventer at vi legger inn noe eller tar noe ut av safen når døren er åpen, har vi ikke markert dette på diagrammet fordi kontrolleren ikke kan fortelle oss noe om det.

Når utviklere snakker om objekter, refererer de ofte til objektenes tilstand, altså kombinasjonen av alle dataene i objektenes felt. Imidlertid er en tilstand i et tilstandsmaskindiagram et mer abstrakt tilstandsbegrep; Poenget er at ulike stater krever ulike måter å reagere på hendelser.

Interne aktiviteter i et Statechart

Stater kan reagere på hendelser uten å gjøre en overgang ved hjelp av interne aktiviteter (interne aktiviteter), i så fall er hendelsen, beskyttelsen og aktiviteten plassert inne i tilstandsrektangelet.

I fig. 10.2 viser tilstanden med interne symbolaktiviteter og hjelpesystemhendelser, som du kan observere i tekstfeltene til redaktøren UI. Intern aktivitet er som en selvovergang – en overgang som går tilbake til samme tilstand. Syntaksen til interne aktiviteter er bygget i henhold til det samme logiske oppsettet av hendelser, beskyttelser og prosedyrer.

I fig. 10.2 viser også spesielle aktiviteter: input og output aktiviteter. Inndataaktivitet henrettet når du går inn i en tilstand; produksjonsaktivitet- når du forlater staten. Det settes imidlertid ikke i gang interne aktiviteter input og output aktiviteter; dette er forskjellen mellom interne aktiviteter ogselvoverganger .

Aktivitetstilstander i et tilstandsdiagram

I tilstandene vi har beskrevet så langt, er objektet stille og venter på neste hendelse før du gjør noe. Imidlertid er tilstander mulige der objektet viser en viss aktivitet.

Stat Søker i fig. 10.3 er en slik tilstand aktivitetstilstand: pågående aktivitet indikeres med et symbol gjøre/; derav begrepet gjøre-aktivitet (vær aktiv). Etter at søket er fullført, utføres overganger uten aktivitet, som å vise nytt utstyr (Vis ny maskinvare). Hvis en kanselleringshendelse oppstår under en aktivitet ( Avbryt), Det gjøre-aktivitet bare avbryter og vi går tilbake til staten Oppdater maskinvarevindu.

Både gjøre-aktiviteter og vanlige aktiviteter representerer manifestasjonen av en eller annen atferd. Den avgjørende forskjellen mellom de to er at normale aktiviteter skjer "umiddelbart" og ikke kan avbrytes av normale hendelser, mens aktiviteter kan pågå i en begrenset tid og kan avbrytes, som vist i figur 1. 10.3. Momentanitet tolkes ulikt for ulike systemer; for sanntidssystemer kan dette ta flere maskininstruksjoner, og for stasjonær programvare kan det ta flere sekunder.

I UML 1 ordinære aktiviteter ble betegnet med begrepet handling(handling), og begrepet aktivitet(aktivitet) ble kun brukt til gjøre-aktiviteter.

Superstater

Det hender ofte at flere stater har felles overganger og interne aktiviteter. I slike tilfeller kan de gjøres om til undertilstander, og den generelle oppførselen kan overføres til en superstat, som vist i fig. 10.4. Uten en superstat ville vi måtte tegne en overgang Avbryt(avbryt) for alle tre delstatene i en delstat Skriv inn tilkoblingsdetaljer.

Parallelle tilstander

Stater kan deles inn i flere parallelle tilstander som kjører samtidig. I fig. Figur 10.5 viser en enkel vekkerklokke som kan slå på enten en CD eller radio og vise enten gjeldende klokkeslett eller alarmtidspunkt.

Alternativene CD/Radio og Current Time/Alarm Time er parallelle. Hvis du ønsket å representere dette ved å bruke et ikke-parallelt tilstandsdiagram, ville du ende opp med et rotete diagram når du trenger å legge til tilstander. Å skille de to atferdsområdene i to tilstandsdiagrammer gjør det mye klarere.

Ris. 10.5 inkluderer også tilstand av forhistorie(historie pseudostat). Dette betyr at når klokken er slått på, går radio/CD-alternativet inn i tilstanden klokken var i da den ble slått av. Pilen som kommer ut av forhistorien viser hvilken tilstand som opprinnelig eksisterte når det ikke var noen forhistorie.

Implementering av Statecharts

Et tilstandsdiagram kan implementeres på tre hovedmåter: ved å bruke en nestet brytersetning, et tilstandsmønster og en tilstandstabell. Den mest direkte tilnærmingen til å jobbe med statecharts er en nestet brytersetning, slik som i fig. 10.6.

Selv om denne metoden er enkel, er den veldig lang selv for dette enkle tilfellet. I tillegg, med denne tilnærmingen er det veldig lett å miste kontrollen, så vi anbefaler ikke å bruke det selv i elementære situasjoner.
Statens mønster representerer et hierarki av statsklasser for håndtering av statsadferd. Hver tilstand i et tilstandsdiagram har sin egen underklasse av tilstand. Kontrolleren har metoder for hver hendelse som bare videresender til tilstandsklassen. Tilstandsdiagrammet vist i fig. 10.1 kan implementeres ved å bruke klassene presentert i fig. 10.7.

Toppen av hierarkiet er en abstrakt klasse som inneholder en beskrivelse av alle metoder som behandler hendelser, men uten implementering.
For hver spesifikke tilstand er det nok å omskrive behandlermetoden for en spesifikk hendelse som starter en overgang fra tilstanden.
En tilstandstabell representerer et tilstandsdiagram som data.

Så diagrammet i fig. 10.1 kan presenteres i form av en tabell. 10.1.
Vi bygger deretter en tolk som bruker kjøretidstilstandstabellen, eller en kodegenerator som genererer klasser fra den tabellen.

Det er klart at det meste av arbeidet på tilstandsbordet gjøres én gang, men det kan deretter brukes når et statlig problem må løses. Kjøretidstilstandstabellen kan endres uten rekompilering, noe som er litt praktisk. Tilstandsmalen er lettere å sette sammen, og selv om hver stat krever en egen klasse, er mengden kode som må skrives ganske liten.

Implementeringene som vises er nesten minimale, men de gir en ide om hvordan de skal brukes tilstandsdiagrammer. I hvert tilfelle resulterer implementeringen av tilstandsmodeller i et ganske stereotypt program, så det er vanligvis bedre å ty til en form for kodegenerering for å oppnå dette.

Abonner på nettstedets nyheter; du finner abonnementsskjemaet i høyre kolonne på nettstedet.

Hvis du ønsker å lære å jobbe som frilanser profesjonelt, inviterer vi deg til ""-kurset.

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 dekkes ikke komponentdiagrammet i denne forelesningen, som kun er en kort oversikt over diagramtyper. Antall diagramtyper for en spesifikk applikasjonsmodell er ikke begrenset på noen måte. For enkle applikasjoner er det 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 et grafisk grensesnitt 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 følgende programmer.

Vi forstår konseptet med systemet. 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 å kjøre trekommandoen i Windows-konsoll, og mye, mye mer annet. 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.

Ris. 2.1.

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

dannelse av generelle krav til oppførselen til det utformede systemet;

utvikling av en konseptuell modell av systemet for påfølgende detaljering;

utarbeidelse av dokumentasjon for samhandling med kunder og systembrukere.

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.

Foreløpig er UML en standardnotasjon for visuell modellering av programvaresystemer, adoptert av Object Managing Group (OMG)-konsortiet høsten 1997, som støttes av mange objektorienterte CASE-produkter.

UML-standarden tilbyr følgende sett med diagrammer for modellering:

· bruk case-diagram – for å modellere forretningsprosessene til en organisasjon eller bedrift og bestemme kravene til informasjonssystemet som opprettes;

· klassediagram – for modellering av den statiske strukturen til systemklasser og forbindelser mellom dem;

· atferdsdiagrammer av systemet;

· interaksjonsdiagrammer;

· Sekvensdiagrammer – for modellering av prosessen med meldingsutveksling mellom objekter innenfor en brukssak;

· samarbeidsdiagram – for modellering av prosessen med meldinger mellom objekter innenfor en brukssak;

· tilstandskartdiagram – for modellering av oppførselen til systemobjekter under overgangen fra en tilstand til en annen;

· aktivitetsdiagram – for modellering av systemets oppførsel innenfor rammen av ulike brukstilfeller, eller modelleringsaktiviteter;

implementeringsdiagrammer:

· komponentdiagrammer – for modellering av hierarkiet av komponenter (undersystemer) i et informasjonssystem;

· distribusjonsdiagram – for modellering av den fysiske arkitekturen til det utformede informasjonssystemet.

I fig. 1.1 presenterer en integrert modell av et informasjonssystem, inkludert hoveddiagrammer som bør utvikles i dette kursprosjektet.

Ris. 1. Integrert modell av et informasjonssystem i UML-notasjon

4.2. Bruk case-diagram

Et brukstilfelle er en sekvens av handlinger utført av systemet som svar på en hendelse initiert av et eksternt objekt (aktør). En use case beskriver en typisk interaksjon mellom en bruker og et system. I det enkleste tilfellet bestemmes brukstilfellet i prosessen med å diskutere med brukeren hvilke funksjoner han ønsker å implementere i dette informasjonssystemet. I UML er et brukstilfelle avbildet som følger:

Fig.2. Bruk case

En aktør er rollen som en bruker spiller i forhold til systemet. Skuespillere representerer roller, ikke bestemte personer eller stillingsbetegnelser. Selv om de er avbildet som stiliserte menneskefigurer i use case-diagrammer, kan en aktør også være et eksternt informasjonssystem som trenger noe informasjon fra det systemet. Skuespillere skal bare vises på diagrammet hvis de faktisk trenger noen bruksområder. I UML er aktører representert som former:

Fig.3. Karakter (skuespiller)

Skuespillere er delt inn i tre hovedtyper:

· brukere;

· systemer;

· andre systemer som samhandler med dette;

Tiden blir en aktør hvis lanseringen av hendelser i systemet avhenger av det.

4.2.1. Forhold mellom use cases og aktører

I UML støtter use case-diagrammer flere typer relasjoner mellom diagramelementer:

· kommunikasjon

inkludering (inkluderer),

· utvidelse (utvide),

· generalisering.

kommunikasjonskobling er forholdet mellom en use case og en aktør. I UML vises kommunikasjonsrelasjoner ved hjelp av en ensrettet assosiasjon (heltrukken linje).

Fig.4. Eksempel på kommunikasjonskobling

Aktiver tilkobling brukes i situasjoner der det er et stykke systematferd som gjentas i mer enn ett brukstilfelle. Disse tilkoblingene brukes vanligvis til å modellere en gjenbrukbar funksjon.

Utvidelseskommunikasjon brukes til å beskrive endringer i den normale oppførselen til et system. Det lar en brukstilfelle bruke funksjonaliteten til en annen brukstilfelle når det er nødvendig.

Fig.5. Eksempel på inkluderings- og utvidelsesforhold

Generaliseringsforbindelse viser at flere aktører eller klasser har felles egenskaper.

Fig.6. Eksempel på generaliseringskobling

4.3.

Interaksjonsdiagrammer beskrive oppførselen til samvirkende grupper av objekter. Vanligvis dekker et interaksjonsdiagram oppførselen til objekter innenfor bare ett brukstilfelle. Et slikt diagram viser en rekke objekter og meldingene som de utveksler med hverandre.

Beskjed er måten et sendeobjekt ber et mottakerobjekt på om å utføre en av dets operasjoner.

Informasjonsmelding er en melding som gir mottakerobjektet noe informasjon for å oppdatere tilstanden.

Forespørselsmelding (spørrende) er en melding som ber om frigivelse av noe informasjon om mottakerobjektet.

Imperativ melding er en melding som ber mottakerobjektet om å utføre en handling.

Det finnes to typer interaksjonsdiagrammer: sekvensdiagrammer og samarbeidsdiagrammer.

4.3.1. Sekvensdiagrammer

Sekvensdiagram reflekterer flyten av hendelser som oppstår innenfor en enkelt brukssak.

Alle aktører (aktører, klasser eller objekter) som er involvert i et gitt scenario (brukstilfelle) vises øverst i diagrammet. Pilene tilsvarer meldinger som sendes mellom en aktør og et objekt eller mellom objekter for å utføre nødvendige funksjoner.

I et sekvensdiagram er et objekt avbildet som et rektangel med en stiplet vertikal linje trukket ned fra det. Denne linjen kalles gjenstandens livline . Det representerer et fragment av livssyklusen til et objekt i prosessen med interaksjon.

Hver melding er representert som en pil mellom livslinjene til to objekter. Meldinger vises i den rekkefølgen de vises på siden fra topp til bunn. Hver melding er merket med minst et meldingsnavn. Om ønskelig kan du også legge til argumenter og noe kontrollinformasjon. Du kan vise selvdelegering - en melding som et objekt sender til seg selv, med meldingspilen som peker mot den samme livslinjen.

Ris. 7. Eksempel på sekvensdiagram

4.3.2. Samarbeidsdiagram

Samarbeidsdiagrammer vise flyten av hendelser innenfor et spesifikt scenario (brukstilfelle). Meldinger er ordnet etter tid, selv om samarbeidsdiagrammer fokuserer mer på forbindelsene mellom objekter. Et samarbeidsdiagram presenterer all informasjon som finnes i et sekvensdiagram, men et samarbeidsdiagram beskriver flyten av hendelser annerledes. Det gjør det lettere å forstå sammenhengene som finnes mellom objekter.

I et samarbeidsdiagram, akkurat som i et sekvensdiagram, representerer piler meldinger som utveksles innenfor et gitt brukstilfelle. Tidsrekkefølgen deres indikeres ved å nummerere meldingene.

Ris. 8. Eksempel på samarbeidsdiagram

4.4. Klassediagram

4.4.1. Generell informasjon

Klassediagram definerer typene klasser av systemet og ulike typer statiske forbindelser som eksisterer mellom dem. Klassediagrammer viser også attributtene til klasser, operasjonene til klasser og restriksjonene som er pålagt forholdet mellom klasser.

Et klassediagram i UML-språket er en graf, hvis noder er elementer i den statiske strukturen til prosjektet (klasser, grensesnitt), og buene er relasjonene mellom noder (assosiasjoner, arv, avhengigheter).

Klassediagrammet viser følgende elementer:

· Pakke - et sett med modellelementer logisk relatert til hverandre;

· Klasse (klasse) - beskrivelse av de vanlige egenskapene til en gruppe lignende objekter;

· Grensesnitt - en abstrakt klasse som spesifiserer et sett med operasjoner som et objekt av en vilkårlig klasse assosiert med et gitt grensesnitt gir til andre objekter.

4.4.2. Klasse

Klasse er en gruppe enheter (objekter) som har lignende egenskaper, nemlig data og atferd. En individuell representant for en klasse kalles et objekt i klassen eller ganske enkelt et objekt.

Atferden til et objekt i UML refererer til alle regler for samspillet til et objekt med omverdenen og med dataene til selve objektet.

I diagrammene er klassen avbildet som et rektangel med en solid kant, delt med horisontale linjer i 3 seksjoner:

Den øverste delen (navnedelen) inneholder klassenavnet og andre generelle egenskaper (spesielt stereotypen).

Den midtre delen inneholder en liste over attributter

Nederst er en liste over klasseoperasjoner som gjenspeiler dens oppførsel (handlinger utført av klassen).

Noen av attributt- og operasjonsdelene vises kanskje ikke (eller begge samtidig). For en manglende seksjon trenger du ikke å tegne en skillelinje eller på noen måte indikere tilstedeværelse eller fravær av elementer i den.

Ytterligere seksjoner, for eksempel unntak, kan innføres etter den spesifikke implementeringens skjønn.

Ris. 9. Eksempel på klassediagram

4.4.2.1.Klasse stereotypier

Klassestereotyper er en mekanisme for å dele klasser inn i kategorier.

UML definerer tre hovedklassestereotyper:

Grens (grense);

Entitet (enhet);

Kontroll.

4.4.2.2.Grenseklasser

Grenseklasser er de klassene som er plassert på grensen til systemet og hele miljøet. Disse inkluderer skjermer, rapporter, grensesnitt med maskinvare (som skrivere eller skannere) og grensesnitt med andre systemer.

For å finne grenseklasser må du undersøke use case-diagrammer. Enhver interaksjon mellom en aktør og en use case må være knyttet til minst én grenseklasse. Det er denne klassen som lar en skuespiller samhandle med systemet.

4.4.2.3.Entitetsklasser

Enhetsklasser inneholder lagret informasjon. De har størst betydning for brukeren, og derfor bruker navnene deres ofte begreper fra fagområdet. Vanligvis opprettes en tabell i databasen for hver enhetsklasse.

4.4.2.4.Kontrollklasser

Kontrollklasser er ansvarlige for å koordinere handlingene til andre klasser. Vanligvis har hver brukstilfelle én kontrollklasse som styrer hendelsesrekkefølgen for den aktuelle brukstilfellet. Lederklassen er ansvarlig for koordinering, men gir ingen funksjonalitet selv, siden de andre klassene ikke sender mange meldinger til den. I stedet sender han mange meldinger selv. En lederklasse delegerer rett og slett ansvar til andre klasser, og det er derfor den ofte kalles en lederklasse.

Det kan være andre kontrollklasser i systemet som er felles for flere brukstilfeller. For eksempel kan det være en SecurityManager-klasse (sikkerhetsansvarlig) som er ansvarlig for å overvåke sikkerhetsrelaterte hendelser. TransactionManager-klassen er ansvarlig for å koordinere meldinger relatert til databasetransaksjoner. Det kan være andre ledere som skal håndtere andre elementer av systemets drift, som ressursdeling, distribuert databehandling eller feilhåndtering.

I tillegg til stereotypiene nevnt ovenfor, kan du lage dine egne.

4.4.2.5.Attributter

Et attributt er et informasjonselement knyttet til en klasse. Attributter lagrer innkapslede klassedata.

Fordi attributter er inneholdt i en klasse, er de skjult fra andre klasser. På grunn av dette må du kanskje spesifisere hvilke klasser som har rett til å lese og endre attributter. Denne egenskapen kalles attributtsynlighet.

Attributtet kan ha fire mulige verdier for denne parameteren:

Offentlig (generelt, åpen). Denne synlighetsverdien forutsetter at attributtet vil være synlig for alle andre klasser. Enhver klasse kan se eller endre verdien av et attributt. I henhold til UML-notasjon innledes et vanlig attributt av et "+"-tegn.

Privat (lukket, hemmelig). Det tilsvarende attributtet er ikke synlig for noen annen klasse. Et privat attributt er angitt med et "–"-tegn i henhold til UML-notasjon.

Beskyttet (beskyttet). Dette attributtet er bare tilgjengelig for klassen selv og dens etterkommere. UML-notasjonen for et beskyttet attributt er "#"-tegnet.

Pakke eller Implementering (pakke). Forutsetter at attributtet er delt, men bare innenfor rammen av pakken. Denne typen synlighet er ikke angitt med noe spesielt ikon.

Ved hjelp av lukkethet eller sikkerhet er det mulig å unngå en situasjon hvor verdien av et attributt endres av alle klasser i systemet. I stedet vil logikken for å endre attributtet være inneholdt i samme klasse som selve attributtet. Synlighetsinnstillingene du angir vil påvirke den genererte koden.

4.4.2.6.Drift

Operasjoner implementerer atferd knyttet til en klasse. En operasjon har tre deler: et navn, parametere og en returtype.

Parametre er argumentene mottatt av operasjonen som input. Returtypen refererer til resultatet av operasjonen.

Et klassediagram kan vise både operasjonsnavn og operasjonsnavn sammen med deres parametere og returtype. For å redusere belastningen på diagrammet, er det nyttig å vise bare navnene på operasjoner på noen av dem, og deres fulle signatur på andre.

I UML har operasjoner følgende notasjon:

Operasjonsnavn (argument: argument datatype, argument2:argument2 datatype,...): returtype

Det er fire forskjellige typer operasjoner å vurdere:

Implementeringsoperasjoner;

Management Operations;

Tilgang operasjoner;

Hjelpeoperasjoner.

Implementeringsoperasjoner

Implementeringsoperasjoner implementerer noen forretningsfunksjoner. Slike operasjoner kan bli funnet ved å undersøke interaksjonsdiagrammer. Denne typen diagram fokuserer på forretningsfunksjoner, og hver melding i diagrammet kan sannsynligvis tilordnes en implementeringsaktivitet.

Hver implementeringsoperasjon må lett kunne spores til det tilsvarende kravet. Dette oppnås på ulike stadier av simuleringen. Aktiviteten er utledet fra meldingen i interaksjonsdiagrammet, meldingene kommer fra en detaljert beskrivelse av flyten av hendelser som skapes ut fra use casen, og sistnevnte lages ut fra kravene. Evnen til å spore hele denne kjeden lar deg sikre at hvert krav er implementert i kode, og hvert stykke kode implementerer et eller annet krav.

Kontrolloperasjoner

Lederoperasjoner kontrollerer opprettelsen og ødeleggelsen av objekter. Klassekonstruktører og destruktorer faller inn i denne kategorien.

Tilgang operasjoner

Attributter er vanligvis private eller beskyttede. Imidlertid må andre klasser noen ganger se eller endre verdiene sine. Det er tilgangsoperasjoner for dette formålet. Denne tilnærmingen gjør det mulig å sikkert innkapsle attributter i en klasse, beskytte dem mot andre klasser, men fortsatt tillate kontrollert tilgang til dem. Det er standard å lage Get and Set-operasjoner for hvert klasseattributt.

Hjelpeoperasjoner

Hjelpeoperasjoner er de operasjonene til en klasse som er nødvendige for at den skal utføre sitt ansvar, men som andre klasser ikke skal vite noe om. Dette er private og beskyttede klasseoperasjoner.

Følg disse trinnene for å identifisere transaksjoner:

1. Lær sekvensdiagrammer og samarbeidsdiagrammer. De fleste meldingene i disse diagrammene er implementeringsoperasjoner. Reflekterende meldinger vil være hjelpeoperasjoner.

2. Vurder kontrolloperasjoner. Du må kanskje legge til konstruktører og destruktorer.

3. Vurder tilgangsoperasjoner. For hvert klasseattributt som andre klasser må jobbe med, må du opprette Get and Set-operasjoner.

4.4.2.7.Tilkoblinger

Et forhold representerer et semantisk forhold mellom klasser. Det gir en klasse muligheten til å lære om egenskapene, operasjonene og relasjonene til en annen klasse. Med andre ord, for at en klasse skal sende en melding til en annen i et sekvensdiagram eller samarbeidsdiagram, må det være et forhold mellom dem.

Det er fire typer relasjoner som kan etableres mellom klasser: assosiasjoner, avhengigheter, aggregasjoner og generaliseringer.

Kommunikasjonsforeningen

Assosiasjon er en semantisk forbindelse mellom klasser. De er tegnet på klassediagrammet som en vanlig linje.

Ris. 10. Kommunikasjonsforeningen

Assosiasjoner kan være toveis, som i eksempelet, eller ensrettet. I UML er toveis assosiasjoner tegnet som en enkel linje uten piler eller med piler på begge sider. En ensrettet assosiasjon har bare én pil som viser retningen.

Tilknytningsretningen kan bestemmes ved å undersøke sekvensdiagrammer og samarbeidsdiagrammer. Hvis alle meldinger på dem sendes av bare én klasse og mottas kun av en annen klasse, men ikke omvendt, er det enveiskommunikasjon mellom disse klassene. Dersom minst én melding sendes i motsatt retning, må foreningen være toveis.

Assosiasjoner kan være refleksive. Refleksiv assosiasjon innebærer at en forekomst av en klasse samhandler med andre forekomster av samme klasse.

Kommunikasjonsavhengighet

Avhengighetsrelasjoner gjenspeiler også relasjoner mellom klasser, men de er alltid ensrettet og viser at en klasse er avhengig av definisjoner laget i en annen. For eksempel bruker klasse A metoder i klasse B. Når klasse B endres, er det nødvendig å gjøre tilsvarende endringer i klasse A.

En avhengighet er representert av en stiplet linje trukket mellom to diagramelementer, og elementet forankret på slutten av pilen sies å avhenge av elementet forankret i begynnelsen av den pilen.

Ris. 11. Kommunikasjonsavhengighet

Når du genererer kode for disse klassene, vil ingen nye attributter bli lagt til dem. Språkspesifikke operatører vil imidlertid bli opprettet for å støtte kommunikasjon.

Kommunikasjonsaggregering

Aggregasjoner er en strammere assosiasjonsform. Aggregasjon er en sammenheng mellom helheten og dens del. Du kan for eksempel ha en klasse som heter Bil, samt klasser som Motor, Dekk og klasser for andre deler av bilen. Som et resultat vil et objekt i bilklassen bestå av et objekt i motorklassen, fire dekkobjekter osv. Aggregasjoner visualiseres som en linje med en diamant nær klassen, som er et heltall:

Ris. 11. Kommunikasjonsaggregering

I tillegg til enkel aggregering, introduserer UML en sterkere type aggregering kalt komposisjon. Ifølge komposisjonen kan en objektdel bare tilhøre en enkelt helhet, og i tillegg faller livssyklusen til delene som regel sammen med helhetens syklus: de lever og dør med den. Enhver sletting av helheten gjelder dens deler.

Denne gjennomgripende slettingen anses ofte som en del av definisjonen av aggregering, men det er alltid underforstått når rollemangfoldet er 1..1; for eksempel, hvis det er nødvendig å slette en kunde, må denne slettingen også gjelde for bestillinger (og på sin side for ordrelinjer).