Introduksjon til typer UML-diagrammer
Unified Modelling Language, det vil si UML i enkle ord, som er et generelt språk for modellering. Hovedmålet med UML er å visualisere måten et system er designet på en standard måte. Det er også veldig mye det samme som tegninger som også brukes i andre tekniske felt. Det er ikke et programmeringsspråk, men det er snarere et visuelt språk. Typer UML-diagrammer brukes til bare å demonstrere atferden så vel som strukturen til et system. UML hjelper systemarkitekter, forretningsfolk og også programvareingeniører i modellering, design så vel som analyse. OMG, det vil si Object Management Group, tok i bruk UML som standard tilbake i 1997. Siden den gang har den blitt administrert av dem. Etter dette publiserte ISO i 2005 UML som en godkjent standard. UML har blitt revidert og gjennomgått med jevne mellomrom.
La oss deretter diskutere typene UML-diagrammer.
Ulike typer UML-diagrammer
Det finnes mange typer UML-diagrammer, og hver har et annet formål uten å vurdere om det ble designet enten før implementeringen eller etter implementeringen.
2 av de bredeste kategoriene som dekker alle de andre typene er
- Atferdsmessige UML-diagram
- StrukturellUML-diagram.
Som du bare kan gjette fra navnet, analyserer noen av UML-diagrammer samt skildrer strukturen i en prosess, mens en annen beskriver atferden til systemet, dets bygningskomponenter og også dets aktører. De videre kategoriserte typene er som følger:
Strukturelle UML-diagram
- Klassediagram
- Objektdiagram
- Komponentdiagram
- Sammensatt strukturdiagram
- Distribusjonsdiagram
- Pakkediagram
- Profildiagram
Atferdsmessige UML-diagram
- Aktivitetsdiagram
- Bruk saksdiagram
- Diagram over samhandlingsoversikt
- Tidsdiagram
- State Machine Diagram
- Kommunikasjonsdiagram
- Sekvensdiagram
La oss diskutere dem kort:
1. Aktivitetsdiagram
Aktivitetsdiagram er de viktigste UML-diagrammer som brukes til å utføre forretningsprosessmodellering. Det brukes i utgangspunktet for å forklare flyten av ulike aktiviteter så vel som handlinger innen programvareutvikling. Disse kan også være både sekvensielle og parallelle.
2. Bruk saksdiagram
Bruk saksdiagrammer er essensielt for å analysere høye nivå krav til systemet. Nå kan disse kravene uttrykkes ved hjelp av forskjellige brukssaker.
3. Oversikt over samhandlingsskjema
Det er den som har muligheten til å avbilde kontrollstrømmen sammen med noder som inneholder samhandlingsdiagrammer. Det er det samme som aktivitetsdiagrammet i den forstand at begge visualiserer rekkefølgen av aktiviteter.
4. Tidsdiagram
Disse diagrammer er i utgangspunktet nødvendige for å representere forholdet mellom objekter når oppmerksomhetssenteret hviler på tid. Selv om vi ikke er interessert i å vite hvordan gjenstander samhandler eller endrer hverandre, til tross for at vi ønsker å representere hvordan disse objektene skal gjøres, så vil skuespillere opptre langs en tidsakse som er lineær.
5. Tilstandsmaskin UML-diagram
Tilstandsmaskin UML-diagrammer kalles også Tilstandsdiagramdiagrammer. De brukes mest for å forklare forskjellige tilstander for en komponent i systemet. Tilstandsmaskin UML-diagrammer tar navnet tilstand maskin siden diagrammet i utgangspunktet bare er maskin som forklarer de forskjellige tilstandene til et objekt og også hvordan det endres avhengig av interne og eksterne hendelser.
6. Kommunikasjonsdiagram
Kommunikasjonsdiagrammer akkurat som sekvensdiagrammene er et slags interaksjonsdiagram som viser hvordan gjenstandene samhandler. Det er en forlengelse av et objektdiagram som viser objekter med meldinger som beveger seg fra hverandre til en annen.
7. UML-diagram for sekvens
Sekvens UML-diagrammer kan også betraktes som de viktigste UML-diagrammer blant modeller på designnivå for utvikling av en forretningsapplikasjon. Siden de har en visuelt selvforklarende karakter, har i det siste disse diagrammer blitt ganske populære når det gjelder prediksjon av forretningsprosesser.
8. Klassediagram
Klasse UML-diagram kan også betraktes som den vanligste diagramtypen som trengs for programvaredokumentasjon. Ettersom det meste av programvaren som opprettes i dag fortsatt er basert på OOP-paradigmet, så hvis vi bruker klassediagrammer for å dokumentere denne programvaren, viser det seg å være en sunn fornuft-løsning. Dette skjer også siden OOP er avhengig av klasser og relasjoner.
9. Objektdiagram
Objekt UML-diagrammer hjelper utviklere med å sjekke om den generiske abstrakte strukturen som de har opprettet, det vil si klassediagram, representerer levedyktig struktur når den blir satt i bruk, det vil si når gjenstandene til en klasse blir underordnet. Få utviklere ser imidlertid på det som et sekundært nivå av nøyaktighetskontroll.
10. Komponentdiagram
Komponent UML-diagrammer kan hjelpe deg med å dele opp systemet til mindre komponenter når du arbeider med dokumentasjon av ganske komplekse systemer. Ofte er det ganske vanskelig å forutsi arkitekturen til et system, siden det kan omfatte forskjellige avdelinger, eller det kan være å bruke forskjellige teknologier.
11. Sammensatt strukturdiagram
Et sammensatt strukturdiagram anses som en type statisk diagram som viser den interne strukturen i klassen så vel som samarbeid. Det er et sett med sammenkoblede elementer.
12. Distribusjonsdiagram
Deretter brukes distribusjonsdiagrammer generelt for å visualisere forholdet mellom programvaren og maskinvaren. Hvis vi snakker mer spesifikt, kan vi også med hjelp av distribusjonsdiagrammer konstruere en fysisk modell av hvordan gjenstander blir distribuert på noder som er maskinvarekomponenter.
Hvis vi snakker om et typisk forenklet distribusjonsdiagram i en nettapplikasjon, vil det omfatte:
- Noder, det vil si applikasjonsserver og databaseserver
- Artefakter, det vil si applikasjonsklient og databaseskjema
13. Pakkediagram
Pakkediagrammet virker mer som en makrocontainer som er nødvendig for distribusjon av UML-diagrammer som vi allerede har forklart. Nå inneholder forskjellige pakker noder og også gjenstander. De organiserer komponentene og modellskjemaene i grupper på samme måte som et navneområde vil innkapsle forskjellige navn som på en eller annen måte er ganske korrelerte.
14. Profildiagram
Profildiagrammer kan ikke betraktes som den typiske UML-diagramtypen. Til tross for det kan det betraktes mer som en utvidelsesmekanisme og ikke en diagramtype som noen annen.
Hvis vi bruker stereotyper, begrensninger og taggede verdier, kan vi enkelt utvide samt tilpasse allerede eksisterende notasjoner om UML. Profildiagrammer er imidlertid som et språk. Hvis du for eksempel snakker engelsk, kan du enkelt lage nye setninger. På samme måte, hvis du snakker profildiagrammer, kan du enkelt og spesifikt lage nye egenskaper så vel som semantikk for UML-diagrammer.
Konklusjon
Dermed er UML-diagrammer nyttige når vi modellerer forretningsdata. Klassen attribuerer kart til abstrakte tilgangsmetoder for vedvarende felt, og assosieringsroller kartlegger til abstrakte tilgangsmetoder for relasjonsfelt. Navigering forutsier om metoder for tilgang til forhold vises i både relaterte enhetsbønner eller bare en. Videre bestemmer multiplikasjonsnotasjon riktig type for relasjonsfelt, spørsmål om en livssyklus, og også kaskaderende slettegenskaper.
Anbefalte artikler
Dette er en guide til typer UML-diagrammer. Her diskuterer vi de grunnleggende konseptene med bredeste kategorier av UML-diagram. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -
- Hva er C ++
- Hva er Git?
- Hva er JavaScript?
- Hva er PHP Array?