Den enkle innføringen i oppretting av diagrammer og modellering av databaser i UML

Unified Modeling Language (UML) spiller en stor rolle i programvareutvikling, men også i ikke-programvaresystemer i mange bransjer, fordi programmet kan brukes til å vise atferd og struktur i et system eller en prosess visuelt. UML hjelper med å finne potensielle feil i programstrukturer, systematferd og andre forretningsprosesser.  

Hvorfor UML? 

UML ble lansert på 1990-tallet av programvareutviklerne Grady Booch, Ivar Jacobson og James Rumbaugh. De ønsket å utvikle en mindre kaotisk måte å representere stadig mer avansert programvareutvikling på, samtidig som de i tillegg atskilte metodologien fra prosessen. I dag er UML fortsatt standarden som brukes for utviklere, prosjektledere, forretningseiere, teknikere og andre eksperter på tvers av ulike bransjer. 

Hva er fordelene med UML? 

  • Forenkler kompleksitet 
  • Holder kommunikasjonslinjer åpne 
  • Automatiserer produksjonen av programvare og prosesser  
  • Hjelper med å løse vedvarende arkitekturproblemer 
  • Øker arbeidskvaliteten 
  • Reduserer kostander og leveringstid til markedet 

Typer UML-diagrammer  

Det finnes to hovedtyper UML-diagrammer: strukturelle diagrammer og adferdsbaserte diagrammer (og i de to kategoriene finnes det flere underkategorier). Disse variasjonene finnes for å representere ulike typer scenarier og diagrammer som forskjellige personer bruker. 

Fra kunder og prosjektledere til tekniske forfattere, designere, analytikere, kodere, kvalitetssikrere og testere vil hver rolle bruke et bestemt diagram som passer til deres behov. Det betyr at hvert oppsett krever et unikt fokus og detaljnivå. Målet er at UML skal vise diagrammene på en slik måte at alle forstår innholdet.  

grunnleggende UML-diagram
Eksempel på grunnleggende UML-sekvensdiagram. Mal tilgjengelig for nedlasting

La oss se nærmere på dette: 

Strukturelle diagrammer 

Strukturelle diagrammer representerer den statiske strukturen for programvare eller et system, og de viser også ulike nivåer av abstraksjon og implementering. Disse brukes til å hjelpe deg med å visualisere de ulike strukturene som et system består av, for eksempel en database eller app. De viser hierarkiet med komponenter eller moduler samt hvordan de er tilkoblet og samhandler med hverandre. Disse verktøyene gir veiledning og sørger for at alle deler av et system fungerer som tiltenkt for alle de andre delene. 

Adferdsbaserte diagrammer 

Fokuset her er på det dynamiske aspektet av programvarens system eller prosess. Disse diagrammene viser funksjonaliteten til et system og understreker hva som må skje i systemet som blir modellert.  

La oss se nærmere på de mange ulike typene UML-diagrammer som finnes i hver kategori: 

1. Strukturelle URL-diagrammer 

  • Klassediagram. Dette diagrammet, som er den vanligste typen innen programvareutvikling, brukes til å illustrere den logiske og fysiske utformingen av et system og viser systemets klasser. Det ligner på et flytdiagram ettersom klassene er representert med bokser. Dette diagrammet illustrerer de ulike klassene og hvordan de samhandler, og hver klasse har tre avdelinger: 
  • Øvre del: klassenavn 
  • Midtre del: klasseattributter 
  • Nedre del: klassemetoder eller -operasjoner 
UML-klassediagram med grensesnitt
Eksempel på UML-klassediagram med grensesnitt. Mal tilgjengelig for nedlasting.
  • Objektdiagram. Dette diagrammet brukes ofte som en måte å dobbeltsjekke nøyaktigheten i et klassediagram. Med andre ord: vil diagrammet fungere i praksis? Det viser objektene i et system og deres relasjoner, og gir en bedre oversikt over potensielle utformingsmangler som må utbedres. 
  • Komponentdiagram. Også kalt komponentflytdiagram, og dette diagrammet viser logiske grupperinger av elementer og deres relasjoner. Med andre ord gir det en forenklet visning av et avansert system ved å dele det inn i mindre komponenter. Hver av delene vises ved hjelp av en rektangulær boks med et navn i boksen. Koblinger definerer relasjonen/avhengighetene mellom de ulike komponentene. 
  • Sammensatt strukturdiagram. Dette brukes sjelden av personer utenfor programvareutviklingsnisjen. Hvorfor? Det minner om et klassediagram, men det er mye mer detaljert og beskriver den interne strukturen i flere klasser og viser samhandlingen mellom dem. Såfremt du ikke er utvikler, er sannsynligvis visning på øverste nivå nok informasjon. 
  • Utviklingsdiagram. Dette diagrammet viser maskinvarekomponenter (noder) og programvarekomponenter (artefakter) og deres relasjoner. Det gir en visuell representasjon av nøyaktig hvor hver programvarekomponent er distribuert. 
  • Pakkediagram. Dette brukes til å illustrere avhengighetene mellom pakkene som utgjør en modell. Hovedmålet er å vise relasjonen mellom de ulike store komponentene som utgjør et avansert system. 
  • Profildiagram. Dette minner mer om et språk enn et diagram. Et profildiagram hjelper deg med å opprette nye egenskaper og semantikk for UML-diagrammer ved å definere tilpassede stereotyper, kodede verdier og begrensninger. Med disse profilene kan du tilpasse en UML-metamodell for ulike plattformer (f.eks. Java Platform, Enterprise Edition (Java EE) eller Microsoft .NET Framework) og domener (f.eks. modellering av forretningsprosesser, tjenesteorientert arkitektur, medisinske programmer og mer). 

2. Adferdsbaserte URL-diagrammer 

  • Aktivitetsdiagram. Dette illustrerer en trinnvis prosess med en tydelig start og slutt. Det er et sett med aktiviteter som må skje for å nå et mål. Det viser hvordan hver aktivitet fører til den neste og hvordan alle er knyttet til hverandre. Bortsett fra programvareutvikling kan disse diagrammene brukes til alle typer forretningsmiljøer. De refereres også til som tilordning eller modellering av forretningsprosesser. 
UML-brukstilfellediagram
Eksempel på grunnleggende UML-brukstilfellediagram. 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 en bruker eller en prosess som samhandler med systemet (person, organisasjon eller en app) fra utsiden av systemet. Et brukstilfellediagram beskriver dermed visuelt det settet med sekvenser og representerer funksjonskravene til systemet. 
  • Diagram for samhandlingsoversikt. Dette diagrammet er ofte avansert, og det minner om aktivitetsdiagrammet ettersom begge viser en trinnvis sekvens med aktiviteter. Men et diagram for samhandlingsoversikt er et aktivitetsdiagram som består av flere samhandlingsdiagrammer. De bruker de samme merknadene som et aktivitetsdiagram (start-, slutt-, beslutnings-, flette-, forgrenings- og sammenslåingsnoder) med tillegg av elementer som for eksempel samhandling, samhandlingsbruk, tidsbegrensning og varighetsbegrensning. 
  • Tidsberegningsdiagram. I forbindelse med tidsberegning brukes dette UML-diagrammet. Det kalles også sekvensierings- eller hendelsesdiagram, og det viser ikke hvordan objekter samhandler eller endres i forhold til hverandre. Funksjonelt sett viser det hvordan objekter og aktører agerer langs en tidslinje. Fokuset her er på hvor lang tid hendelsene tar, og endringene som utføres, avhenger av varighetsbegrensningene. Hoveddelene i et tidsberegningsdiagram inkluderer: 
    • Livslinje: individuell deltaker 
    • Tilstandslivslinje: ulike tilstander som livslinjen opplever i et forløp 
    • Varighetsbegrensning: tiden som kreves for at en begrensning må oppfylles 
    • Tidsbegrensning: en tidsperiode noe må utføres innen av deltakeren 
    • Destruksjonsforekomst: når et objekts livslinje slutter. Ingen andre forekomster vises etter destruksjonsforekomsten på en livslinje. 
  • Tilstandsmaskindiagram. Dette diagrammet kalles også et tilstandsdiagram, og det brukes når atferden til et objekt er kompleks og detaljene derfor er svært viktige. Diagrammet hjelper med å beskrive atferden til ett objekt (eller noen ganger en operator) og hvordan det endres basert på interne og eksterne hendelser. 
  • Sekvensdiagram. Dette diagrammet er populært ikke bare i designmiljøer, og dets visuelle illustrasjonsegenskaper er egnet til å vise alle typer forretningsprosesser. Det viser en detaljert oversikt over strukturen i et system, viser sekvensen av meldinger, og viser samhandlinger mellom aktører og objekter kronologisk. I tillegg viser de enkle gjentakelser og forgreninger. Det passer godt i forbindelse med multitasking. 
  • Kommunikasjonsdiagram. Et kommunikasjons- eller samarbeidsdiagram ligner på et sekvendiagram. Det legger imidlertid vekt på kommunikasjonen mellom objekter, og det viser organisasjonen for objektene som deltar i en samhandling samt inneholder mer avanserte gjentakelser og forgreninger. 

Databasemodeller  

UML har også blitt mer og mer populær som notasjon for modellering av databaser. Disse modellene er et enestående visuelt verktøy for idedugnader, oppretting av programmer i frihåndsform og samarbeid om ideer.  

UML har ikke spesifikasjoner for datamodellering, men det kan være et nyttig verktøy for oppretting av diagrammer, spesielt ettersom data fra databaser kan brukes i objektorientert programmering.  

La oss se litt nærmere på ulike typer databasemodeller du kan opprette: 

  • Hierarkisk databasemodell. Denne modellens data er organisert i en treaktig struktur, noe som er en gammel modell som faktisk fungerer. Treet består av flere grupper kalt segmenter. Det bruker en en-til-mange-relasjon. Datatilgangen er også forutsigbar. 
  • Nettverksmodell. Denne modellen ser ut som en graf, der relasjonstyper er buer og objekttyper er noder. I motsetning til andre databasemodeller blir ikke nettverksmodellens skjema begrenset til rutenett eller hierarki. 
  • Objektorientert databasemodell. Denne modellen bruker en samling av objekter, eller programvareelementer som kan brukes på nytt, med tilknyttede funksjoner og metoder. En multimediedatabase kan for eksempel inneholde bilder som ikke kan lagres i en relasjonsdatabase. Eller en hypertekstdatabase tillater kobling til andre objekter. 
  • Relasjonsbasert modell. Her er dataene strukturert ved hjelp av relasjoner, eller rutenettaktige matematiske strukturer som har kolonner og rader. Det er i praksis en tabell. 
  • Objektrelasjonsmodellen. Som navnet antyder er denne modellen en kombinasjon av de to som er nevnt ovenfor. Den støtter objekter, klasser, arving og andre objektorienterte elementer, men støtter også datatyper, tabellstrukturer og mer, på samme måte som i en relasjonsdatamodell. 
  • Enhetsrelasjonsmodell. Denne består av enhetstyper (personer, steder eller ting). Den viser relasjoner som kan finnes mellom dem. Ved å definere enhetene, attributtene deres og å vise relasjonene mellom dem, illustrerer et ER-diagram den logiske strukturen i databaser. 
  • 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. I EAV-modeller eller åpne skjemamodeller representeres data i tre kolonner:  
  1. Enheten (det som beskrives)  
  2. Attributtet eller parameteren (f.eks. navn, beskrivelse, datatype) 
  3. Verdien for attributtet. 
  • Stjerneskjema. Dette er den enkleste versjonen av en dimensjonsmodell, der data blir ordnet i dimensjoner og fakta. Skjemaet brukes i forretningsintelligens og datavarehus ettersom det er egnet for å søke i sett med store data. 

Forenkling med programvare 

Enten du oppretter databasemodeller eller UML-diagrammer, så vil bruk av et programvareverktøy forenkle og forbedre prosessen. Sørg for at du velger et verktøy der du kan: 

  • Opprette profesjonelle diagrammer med bruksklare maler og tusenvis av figurer i et innholdsøkosystem som oppfyller bransjestandarder, for eksempel UML 2.5, men også BPMN 2.0 og IEEE. 
  • Gi liv til diagrammene med dataoverlegg, ikoner, farger og grafikk for å gjøre det enklere å forstå dataene, inkludert datavisualisering med ett trinn i Excel. 
  • Samarbeide med andre ved hjelp av samtidig redigering, kommentering og tilføying. 
  • Formidle én versjon av sannheten og åpne diagrammer fra nesten hvor som helst i en nettleser eller enhetsapper. 

I programvareutvikling og ikke-programvaresystemer i mange bransjer kan bruk av visuelle UML-diagrammer spille en viktig rolle for å bygge adferdsprosesser og -strukturer som er vellykkede. Finn ut mer om oppretting av UML-diagrammer med programvare med denne trinnvise veiledningen.  

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.

Kjøp nå
Relatert innhold
Produktivitet

5 måter integrerte nettkalender-apper øker produktiviteten på

Les mer
Produktivitet

Gjør møter mer engasjerende med digitale tavler

Les mer
Produktivitet

5 måter meningsmålinger kan styrke engasjementet i nettmøter på

Les mer
Produktivitet

5 måter eksterne arbeidere kan samarbeide på

Les mer

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.