This is the Trace Id: b19b6513e5a5934463fb429f1b17e822

Veiledning i Unified Modeling Language-diagrammer og databasemodellering

Tre hender peker på ulike Unified Modeling Language-diagrammer på en tavle. Ordet «UML» er skrevet i midten.
Unified Modeling Language (UML) spiller en stor rolle i programvareutvikling, men også i ikke-programvaresystemer i mange bransjer, da det er en måte å visuelt vise virkemåten og strukturen til et system eller en prosess på. UML bidrar til å vise potensielle feil i programstrukturer, systematferd og andre forretningsprosesser prosesser.  

Hvorfor Unified Modeling Language? 

Unified Modeling Language kom først på scenen tilbake på 1990-tallet takket være de tre programvareteknikerne – Grady Booch, Ivar Jacobson og James Rumbaugh – fordi de ønsket å utvikle en mindre rotete måte å representere stadig mer kompleks programvareutvikling på, samtidig som de skiller metodologi fra prosessen. I dag er Unified Modeling Language fortsatt den foretrukne notasjonen for utviklere, så vel som prosjektledere, bedriftsledere, teknologiske entreprenører og fagfolk på tvers av bransjer. 

Hva er fordelene med Unified Modeling Language? 

  • Forenkler kompleksiteten 
 
  • Holder kommunikasjonslinjer åpne 
 
  • Automatiserer produksjon av programvare og prosesser  
 
  • Bidrar til å løse vedvarende arkitektoniske problemer 
 
  • Øker kvaliteten på 
 
  • Reduserer kostnader og 

Typer Unified Modeling Language-diagrammer  

Det finnes to hovedtyper av Unified Modeling Language-diagrammer: strukturdiagrammer og atferdsdiagrammer (og i disse kategoriene ligger flere andre). Disse variasjonene finnes for å representere de mange typene scenarioer og diagrammer som ulike typer personer bruker.

Fra kunder og prosjektledere til tekniske forfattere, designere, analytikere, utviklere og QA-testere, vil hver rolle bruke et spesifikt diagram som passer deres behov. Det betyr at hvert oppsett krever forskjellig fokus og detaljnivå. Målet er at Unified Modeling Language visuelt skal uttrykke diagrammer som er enkle å forstå for alle.  

grunnleggende Unified Modeling Language-diagram

Eksempel på grunnleggende Unified Modeling Language-sekvensdiagram. Mal tilgjengelig for nedlasting 

 

La oss ta en nærmere titt: 

Strukturelle diagrammer 

Strukturelle diagrammerStrukturelle diagrammer representerer den statiske strukturen til programvare eller et system, og de viser også ulike nivåer av abstraksjon og implementering. Disse brukes til å visualisere de ulike strukturene som utgjør et system, for eksempel en database eller et program. De viser hierarkiet av komponenter eller moduler og hvordan de kobler til og samhandler med hverandre. Disse verktøyene gir veiledning og sikrer at alle deler av et system fungerer som de skal i forhold til alle de andre delene. 

Atferdsdiagrammer 

Fokuset her er på dynamiske aspekter ved programvaresystemet eller prosessen. Disse diagrammene viser funksjonaliteten til et system og fremhever hva som må skje i systemet som modelleres.  

La oss ta en nærmere titt på de mange ulike typene Unified Modeling Language-diagrammer som faller under hver kategori: 

1. Strukturelle Unified Modeling Language-diagrammer 

Klassediagram. Dette diagrammet, den vanligste typen i programvareutvikling, brukes til å vise den logiske og fysiske utformingen av et system og viser klassene. Det ligner på et flytskjema fordi klassene er representert med bokser. Dette diagrammet tilbyr et visualobjekt av de ulike klassene og hvordan de er koblet sammen, og hver klasse har tre avdelinger: 

 

  • Øverste inndeling: klassenavn 
 
  • Midtdel: klasseattributter 
 
  • Nederste del: klassemetoder eller operasjoner 
Unified Modeling Language-klassegrensesnittdiagram

Eksempel på Unified Modeling Language-klassegrensesnittdiagram. Mal tilgjengelig for nedlasting.

Objektdiagram. Dette diagrammet brukes ofte som en metode for å dobbeltsjekke et klassediagram for nøyaktighet. Vil det med andre ord fungere i praksis? Den viser systemobjekter og deres relasjoner og gir en bedre oversikt over potensielle utformingsfeil som må løses. 

 

Komponentdiagram. Også kjent som et komponentflytdiagram, viser det logiske grupperinger av elementer og deres relasjoner. Det gir med andre ord en mer forenklet visning av et komplekst system ved å dele det ned i mindre komponenter. Hver av delene vises ved hjelp av en rektangulær boks, med navnet skrevet inni. Koblinger definerer relasjonen/avhengighetene mellom de ulike komponentene. 

 

Sammensatt strukturdiagram. Dette brukes sjelden av noen utenfor programvareutviklingsfeltet. Hvorfor? Selv om det ligner på et klassediagram, tar det et dypere dykk, som beskriver den interne strukturen til flere klasser og viser samhandlingene mellom dem. Med mindre du er utvikler, er en visning på øverste nivå sannsynligvis nok informasjon. 

 

Utrullingsdiagram. Dette diagrammet viser maskinvarekomponenter (noder) og programvarekomponenter (artefakter) og deres relasjoner. Det tilbyr en visuell fremstilling av nøyaktig hvor hver programvarekomponent distribueres. 

En person med langt svart hår fokuserer på å skrive eller tegne på et nettbrett mens han sitter innendørs.

Kom raskt i gang med et krasjkurs i Microsoft 365

Gi teamet mulighet til å være produktivt hver dag, fra nesten hvor som helst, med Microsoft 365.

Pakkediagram. Dette brukes til å vise avhengighetene mellom pakkene som utgjør en modell. Hovedmålet er å vise relasjonen mellom de ulike store komponentene som danner et komplekst system. 

 

Profildiagram. Dette er mindre som et diagram og mer som et språk. Et profildiagram bidrar til å opprette nye egenskaper og semantikk for Unified Modeling Language-diagrammer ved å definere egendefinerte stereotyper, kodede verdier og begrensninger. Disse profilene lar deg tilpasse en Unified Modeling Language-metamodell for ulike plattformer (for eksempel Java-plattform, Enterprise Edition (Java EE) eller Microsoft .NET Framework) og domener (for eksempel forretningsprosessmodellering, tjenestebasert arkitektur, medisinske programmer og mer). 

2. Unified Modeling Language-diagrammer for virkemåte: 

Aktivitetsdiagram. Dette viser en trinnvis prosess med en klar begynnelse og slutt. Det er et sett med aktiviteter som må skje for å nå et mål. Den viser hvordan hver aktivitet fører til neste og hvordan alle er tilkoblet. I tillegg til programvareutvikling kan disse brukes i nesten alle forretningsmiljøer. De kalles også tilordning eller modellering av forretningsprosesser. 
Brukstilfellediagram for Unified Modeling Language

Eksempel på grunnleggende sekvensdiagram for Unified Modeling Language. Mal tilgjengelig for nedlasting.

Brukstilfellediagram. Dette beskriver hva et system gjør, men ikke hvordan det gjør det. Et brukstilfelle er et sett med hendelser som oppstår når en «aktør» bruker et system til å fullføre en prosess. En aktør er definert som hvem som helst eller noe som samhandler med systemet (person, organisasjon eller et program) utenfor systemet. Et brukstilfellediagram beskriver visuelt dette settet med sekvenser og representerer de funksjonelle kravene til systemet. 

 

Oversikt over samhandlingsdiagram . Dette diagrammet ligner ofte på aktivitetsdiagrammet fordi begge viser en trinnvis sekvens med aktiviteter. Men et oversiktsdiagram for samhandling er et aktivitetsdiagram laget av forskjellige samhandlingsdiagrammer. De bruker de samme merknadene som et aktivitetsdiagram (start-, slutt-, beslutnings-, sammenslåings-, forgreining- og sammenføyningsnoder), med tillegg av elementer som interaksjon, interaksjonsbruk, tidsbegrensning og varighetsbegrensning. 

 

Tidsberegningsdiagram. Når tidsberegningen står i sentrum, brukes dette Unified Modeling Language-diagrammet. Også kjent som et sekvenserings- eller hendelsesdiagram, viser det ikke hvordan objekter samhandler eller endrer hverandre. Funksjonelt viser det hvordan objekter og aktører fungerer langs en tidslinje. Fokuset her er på hvor lang tid hendelser tar, og endringene som skjer avhengig av varighetsbegrensningene. Hoveddeler i et tidsberegningsdiagram inkluderer: 

 

  • Livslinje: individuell deltaker 
 
  • Tilstandstidslinje: ulike tilstander livslinjen går gjennom i et datasamlebånd 
 
  • Varighetsbegrensning: tid som kreves for at en betingelse skal oppfylles 
 
  • Tidsbegrensning: et tidspunkt der noe må oppfylles av deltakeren 
 
  • Forekomst av ødeleggelse: der livslinjen til et objekt slutter. Ingen annen forekomst vil vises etter ødeleggelseshendelsen på en livslinje. 

 

Maskintilstandsdiagram. Også kalt et tilstandsdia­gram, brukes dette diagrammet når et objekts atferd er kompleks, og detaljer er avgjørende. Det hjelper med å beskrive atferden til ett objekt (eller noen ganger en operatør) og hvordan den endres basert på interne og eksterne hendelser. 

 

Sekvensdiagram. Dette visuelt tiltalende diagrammet er populært enn bare utformingsfellesskapet, og viser alle typer forretningsprosesser. Det viser ganske enkelt strukturen til et system, som viser sekvensen av meldinger og samhandlinger mellom aktører og objekter kronologisk. Sekvensdiagrammer viser enkel gjentakelse og forgrening. Det er en fordel for fleroppgaveoppgaver. 

 

Kommunikasjonsdiagram. Et kommunikasjons- eller samarbeidsdiagram ligner på et sekvensdiagram. Det understreker imidlertid kommunikasjonen mellom objekter. Den viser organiseringen av objektene som deltar i en samhandling og har mer kompleks iterasjon og forgrening. 

Databasemodeller  

Unified Modeling Language har også oppnådd popularitet som en notasjon for modelleringsdatabaser. Disse modellene er et flott visuelt verktøy for idédugnad, frihåndsdiagram og samarbeid om ideer.  

 

Selv om Unified Modeling Language ikke har spesifikasjoner for datamodellering, kan det være et nyttig verktøy for diagrammering, spesielt siden data fra databaser kan brukes i objektorientert programmering.  

 

La oss ta en titt på ulike typer databasemodeller du kan opprette: 

 

  • Hierarkisk databasemodell. Denne modellens data er organisert i en trelignende struktur. Treet består av flere grupper som kalles segmenter. Den bruker en én-til-mange-relasjon. Datatilgangen er også forutsigbar. 

 

  • Nettverksmodell. Denne modellen tar form av en graf, der relasjonstyper er buer, og objekttyper er noder. I motsetning til andre databasemodeller er ikke nettverksmodellskjemaet begrenset til som et gitter eller hierarki. 

 

  • Objektorientert databasemodell. Denne modellen bruker en samling av objekter, eller gjenbrukbare programvareelementer, med tilknyttede funksjoner og metoder. En multimediedatabase kan for eksempel ha bilder som ikke kan lagres i en relasjonsdatabase. Eller en hypertekstdatabase tillater kobling til andre objekter. 

 

  • Relasjonsmodell. Her er data strukturert ved hjelp av relasjoner, eller rutenettlignende matematiske strukturer som har kolonner og rader. Det er egentlig en tabell. 

 

  • Objektrelasjonsmodellen. Som navnet tilsier, er denne modellen en kombinasjon av de to som er nevnt ovenfor. Den støtter objekter, klasser, arv og andre objektorienterte elementer, men støtter også datatyper, tabellstrukturer og mer–som i en relasjonsdatamodell. 

 

  • Enhetsrelasjonsmodell. Dette består av enhetstyper (personer, steder eller ting). Den viser relasjoner som kan eksistere mellom dem. Ved å definere enhetene, attributtene og vise relasjonene mellom dem, illustrerer et ER-diagram den logiske strukturen til databasene. 

 

  • Dokumentmodell. Den er utformet for lagring og administrasjon av dokumenter eller halvstrukturerte data, i stedet for atomiske data. Den har en trestruktur der hver node er et objekt som representerer en del av dokumentet. 

 

  • Enhetsattributtverdimodell. EAV eller åpne skjemamodeller, data registreres som tre kolonner:  
    • Enheten (det som beskrives)  

     

    • Attributtet eller parameteren (for eksempel navn, beskrivelse, datatype) 

     

    • Verdien for attributtet 

 

  • Stjerneskjema. Dette er den enkleste versjonen av en dimensjonsmodell, der data ordnes i dimensjoner og fakta. Den brukes i forretningsanalyse og datalagring siden det passer for spørring av store datasett. 

Forenkle med 

Enten du oppretter databasemodeller eller Unified Modeling Language-diagrammer ved hjelp av et programvareverktøy forenkler og forbedrer prosessen. Pass på at du velger en som lar deg: 

 

  • Opprette profesjonelle diagrammer med ferdiglagde maler og tusenvis av figurer i et innholdsøkosystem som oppfyller bransjestandarder som Unified Modeling Language 2.5, men også Modelleringsnotasjon for forretningsprosesser 2.0 og IEEE. 
 
  • Gi liv til diagrammer med dataoverlegg, ikoner, farger og grafikk for å gjøre dataene enklere å sammendrage, inkludert etttrinns Excel-datavisualisering
 
  • Samarbeid med andre ved hjelp av samtidig redigering, kommentering og merknader. 
 
  • Kommunisere én versjon av sannheten og få tilgang til diagrammer fra nesten hvor som helst i en nettleser eller enhetsprogrammer. 

 

I programvareutvikling og ikke-programvaresystemer i mange bransjer kan bruk av visuelle Unified Modeling Language-diagrammer spille en viktig rolle i suksessen til å bygge atferdsprosesser og strukturer. Mer informasjon om å opprette Unified Modeling Language-diagrammer med programvare med denne trinnvise veiledningen.  

 

Marketing er en del av markedsføringsteamet hos Microsoft. Han er glad for å se hvordan gründere bedre kan starte, administrere og utvikle virksomhetene sine.

  • RELATERTE PRODUKTER

Kom i gang med Visio

Visualiser og kommuniser ideer, informasjon og prosesser fra så godt som overalt, på hvilken som helst enhet, med hjelp fra Visio.

Relatert innhold

Produktivitet

Fem typer samarbeidsverktøy som forbedrer produktiviteten

Produktivitet

Målinnstilling kontra målplanlegging: Utforme en plantegning for varig forretningssuksess

Produktivitet

Moderne endepunktløsninger: Hva de er og hvorfor du trenger dem

Produktivitet

Realisering av potensial: Slik transformerer produktivitetsverktøy drevet av kunstig intelligens arbeidet

Forretningsinnsikt og ideer gir ikke råd om profesjonell skatt eller økonomiske spørsmål. Kontakt egen skatte- eller økonomirådgiver for å diskutere situasjonen din.

Følg Microsoft 365