Introduktion til typer UML-diagrammer
Unified Modelling Language, det vil sige UML i enkle ord, hvilket er et generelt sprog til modellering. Hovedmålet med UML er at visualisere den måde, et system designes på en standard måde. Det er også meget det samme som tegninger, der også bruges inden for andre teknikområder. Det er ikke et programmeringssprog, men snarere et visuelt sprog. Typer UML-diagrammer bruges til kun at demonstrere opførsel såvel som strukturen i et system. UML hjælper systemarkitekter, forretningsfolk og også softwareingeniører i modellering, design såvel som analyse. OMG, det vil sige Object Management Group, vedtog UML som standard tilbage i 1997. Siden da er det blevet styret af dem. Derefter offentliggjorde ISO i 2005 UML som en godkendt standard. UML er periodisk revideret og gennemgået gennem årene.
Lad os derefter diskutere typerne af UML-diagrammer.
Forskellige typer UML-diagrammer
Der findes mange typer UML-diagrammer, og hver har et andet formål uden at overveje, om det blev designet enten før implementeringen eller efter implementeringen.
2 af de bredeste kategorier, der dækker alle de andre typer er
- Adfærdsmæssigt UML-diagram
- StrukturelUML-diagram.
Som du kun kan gætte fra navnet, analyserer nogle af UML-diagrammerne samt skildrer strukturen af en proces, mens en anden beskriver opførslen af systemet, dets bygningskomponenter og også dets aktører. De yderligere kategoriserede typer er som følger:
Strukturelt UML-diagram
- Klassediagram
- Objektdiagram
- Komponentdiagram
- Sammensat strukturdiagram
- Implementeringsdiagram
- Pakkediagram
- Profildiagram
Adfærdsmæssigt UML-diagram
- Aktivitetsdiagram
- Brug sagdiagram
- Diagram over interaktionsoversigt
- Tidsdiagram
- Tilstands maskindiagram
- Kommunikationsdiagram
- Sekvensdiagram
Lad os diskutere dem kort nu:
1. Aktivitetsdiagram
Aktivitetsdiagram er de vigtigste UML-diagrammer, der bruges til udførelse af forretningsprocesmodellering. Det bruges dybest set til at forklare strømmen af forskellige aktiviteter såvel som handlinger inden for softwareudvikling. Disse kan også være både sekventielle og også parallelle.
2. Brug sagdiagram
Brug af case-diagrammer er essentielt nødvendigt for at analysere krav på højt niveau til systemet. Nu kan disse krav udtrykkes ved hjælp af forskellige anvendelsessager.
3. Oversigt over interaktionsdiagram
Det er den, der har evnen til at forestille kontrolstrømmen sammen med noder, der indeholder interaktionsdiagrammer. Det er det samme som aktivitetsdiagrammet i den forstand, at begge visualiserer rækkefølgen af aktiviteter.
4. Tidsdiagram
Disse diagrammer er dybest set nødvendige for at repræsentere forholdet mellem objekter, når opmærksomhedens centrum hviler til tiden. Selvom vi ikke er interesseret i at vide, hvordan interagerer objekter eller endda ændrer hinanden, til trods for at vi ønsker at repræsentere, hvordan man gør disse objekter, så vil skuespillere handle langs en tidsakse, der er lineær.
5. Tilstandsmaskine UML-diagram
Tilstandsmaskine UML-diagrammer kaldes også Tilstandsdiagram-diagrammer. De bruges mest til at forklare forskellige tilstande for en komponent i systemet. Tilstandsmaskine UML-diagrammer tager navnet tilstandsmaskine, da diagrammet i bund og grund kun er maskin, der forklarer de forskellige tilstande af et objekt, og også hvordan det ændrer sig afhængigt af interne og eksterne begivenheder.
6. Kommunikationsdiagram
Kommunikationsdiagrammer ligesom sekvensdiagrammerne er en slags interaktionsdiagram, der demonstrerer, hvordan objekterne interagerer. Det er en udvidelse af et objektdiagram, der viser objekter med meddelelser, der kører fra hinanden.
7. Sekvens UML-diagram
Sekvens UML-diagrammer kan også betragtes som de vigtigste UML-diagrammer blandt modeller på designniveau til udvikling af en forretningsapplikation. Da de har en visuelt selvforklarende karakter, er disse diagrammer for nylig blevet ret populære i forudsigelsen af forretningsprocesser.
8. Klassediagram
Klasse UML-diagram kan også betragtes som den mest almindelige diagramtype, der er nødvendig til softwaredokumentation. Da det meste af den software, der oprettes i dag, stadig er baseret på OOP-paradigmet, så hvis vi bruger klassediagrammer til at dokumentere, viser det sig, at denne software er en fælles fornuftig løsning. Dette forekommer også, da OOP afhænger af klasser og relationer.
9. Objektdiagram
Objekt UML-diagrammer hjælper udviklere med at kontrollere, om den generiske abstrakte struktur, som de har oprettet, det vil sige klassediagram, repræsenterer levedygtig struktur, når den bringes i praksis, det vil sige, når objekterne i en klasse bliver instantieret. Få udviklere ser imidlertid på det som et sekundært niveau af nøjagtighedskontrol.
10. Komponentdiagram
Komponent UML-diagrammer kan hjælpe med at opdele systemet til mindre komponenter, når du beskæftiger dig med dokumentation af ganske komplicerede systemer. Ofte er det temmelig svært at forudsige arkitekturerne i et system, da det muligvis omfatter forskellige afdelinger, eller det også muligvis anvender forskellige teknologier.
11. Sammensat strukturdiagram
Et sammensat strukturdiagram betragtes som en type statisk diagram, der viser den interne struktur i klassen såvel som samarbejder. Det er et sæt af sammenkoblede elementer.
12. Distributionsdiagram
Dernæst anvendes distributionsdiagrammer generelt til at visualisere forholdet mellem softwaren og hardwaren. Hvis vi snakker mere specifikt, kan vi også ved hjælp af implementeringsdiagrammer konstruere en fysisk model for, hvordan artefakter implementeres på noder, der er hardwarekomponenter.
Hvis vi taler om et typisk forenklet implementeringsdiagram i en webapplikation, vil det omfatte:
- Koder, det vil sige applikationsserver og databaseserver
- Artefakter, det vil sige applikationsklient og databaseskema
13. Pakkediagram
Pakkediagrammet virker mere som en makrocontainer, der kræves til implementering af UML-diagrammer, som vi allerede har forklaret. Nu indeholder forskellige pakker noder og også artefakter. De organiserer komponenter og modeldiagrammer i grupper på samme måde som et navneområde ville indkapsle forskellige navne, der på en eller anden måde er ganske korrelerede.
14. Profildiagram
Profildiagrammer kan ikke betragtes som den typiske UML-diagramtype. På trods af kan det betragtes mere som en udvidelsesmekanisme og ikke en diagramtype som nogen anden.
Hvis vi bruger stereotyper, begrænsninger og mærkede værdier, kan vi nemt udvide såvel som tilpasse allerede eksisterende notationer af UML. Profildiagrammer er dog som et sprog. For eksempel, hvis du taler engelsk, kan du nemt oprette nye sætninger. Hvis du taler profildiagrammer på en lignende måde, kan du nemt og specifikt oprette nye egenskaber såvel som semantik for UML-diagrammer.
Konklusion
Således er UML-diagrammer nyttige, hver gang vi modellerer forretningsdata. Klassen attributter kort til abstrakte adgangsmetoder for vedvarende felter, og tilknytningsroller kort til abstrakte adgangsmetoder for forholdsfelter. Navigering forudsiger, om forbindelsesadgangsmetoder vises i begge relaterede enhedsbønner eller bare en. Yderligere bestemmer multiplikationsnotation den rigtige type for relationsfelter, spørgsmål om en livscyklus og også kaskaderende sletteegenskaber.
Anbefalede artikler
Dette er en guide til typer UML-diagrammer. Her diskuterer vi de grundlæggende koncepter med de bredeste kategorier af UML-diagram. Du kan også gennemgå vores andre foreslåede artikler for at lære mere -
- Hvad er C ++
- Hvad er Git?
- Hvad er JavaScript?
- Hvad er PHP Array?