UML-klassediagram: Abstract-klasse med eksempler
Redaktionelle team
⚡ Smart opsummering
UML-klassediagram giver en statisk visning af et softwaresystem i blueprint-stil, der viser dets klasser, attributter, operationer og de relationer, der forbinder dem. Denne ressource forklarer de væsentlige elementer, relationstyper, abstract-klasser og et eksempel på en fungerende hæveautomat.
Hvad er klasse i UML-diagram?
A Klasse i UML diagram er en plan, der bruges til at skabe et objekt eller et sæt af objekter. Klassen definerer, hvad et objekt kan gøre. Det er en skabelon til at skabe forskellige objekter og implementere deres adfærd i systemet. En klasse i UML er repræsenteret af et rektangel, der inkluderer rækker med klassenavne, attributter og operationer.
Hvad er klassediagram?
A Klassediagram i Software engineering er en statisk struktur, der giver et overblik over et softwaresystem ved at vise klasser, attributter, operationer og deres forhold mellem hinanden. Dette diagram inkluderer klassens navn, attributter og betjening i separate udpegede rum. Klassediagram hjælper med at konstruere koden til udvikling af softwareapplikationer.
Klassediagram definerer typen af objekter i systemet og de forskellige typer relationer, der findes imellem dem. Det giver et overblik over en applikation på højt niveau. Denne modelleringsmetode kan køre med næsten alle objektorienterede metoder. En klasse kan henvise til en anden klasse. En klasse kan have sine objekter eller kan arve fra andre klasser.
Fordele ved klassediagram
- Klassediagram Illustrerer datamodeller for selv meget komplekse informationssystemer
- Det giver et overblik over, hvordan applikationen er opbygget, før man studerer selve koden. Dette kan nemt reducere vedligeholdelsestiden
- Det hjælper til en bedre forståelse af generelle skemaer for en applikation.
- Giver mulighed for at tegne detaljerede diagrammer, som fremhæver kode, der skal programmeres
- Nyttigt for udviklere og andre interessenter.
Væsentlige elementer i et UML-klassediagram
Væsentlige elementer i UML klassediagram er:
- Klassens navn
- Attributter
- Produktion
Klassens navn
Navnet på klassen er kun nødvendigt i den grafiske repræsentation af klassen. Det vises i det øverste rum. En klasse er planen for et objekt, som kan dele de samme relationer, attributter, operationer og semantik. Klassen er gengivet som et rektangel, inklusive dens navn, attributter og operationer i sperat rum.
Følgende regler skal overholdes, mens du repræsenterer en klasse:
- Et klassenavn skal altid starte med et stort bogstav.
- Et klassenavn skal altid være i midten af det første rum.
- Et klassenavn skal altid skrives ind pin format.
- UML-abstract-klassenavnet skal skrives i kursiv.
Attributter
En attribut kaldes egenskab for en klasse, som beskriver det objekt, der modelleres. I klassediagrammet er denne komponent placeret lige under navnerummet.
En afledt attribut beregnes ud fra andre attributter. For eksempel kan en elevs alder nemt beregnes ud fra hans/hendes fødselsdato.
Attributter egenskaber
- Attributterne er generelt skrevet sammen med synlighedsfaktoren.
- Offentlig, privat, beskyttet og pakke er de fire synligheder, der er angivet med henholdsvis +, -, # eller ~ tegn.
- Synlighed beskriver tilgængeligheden af en attribut i en klasse.
- Attributter skal have et meningsfuldt navn, der beskriver brugen af det i en klasse.
Relationer
Der er hovedsageligt tre slags relationer i UML:
- Afhængigheder
- Generaliseringer
- Foreninger
Afhængighed
En afhængighed betyder forholdet mellem to eller flere klasser, hvor en ændring i den ene kan fremtvinge ændringer i den anden. Det vil dog altid skabe et svagere forhold. Afhængighed indikerer, at en klasse afhænger af en anden.
I de følgende UML-klassediagrameksempler har Student en afhængighed af College
Generalisering:
En generalisering hjælper med at forbinde en underklasse med dens superklasse. En underklasse er nedarvet fra sin superklasse. Generaliseringsforhold kan ikke bruges til at modellere grænsefladeimplementering. Klassediagram tillader nedarvning fra flere superklasser.
I dette eksempel er klassen Elev generaliseret fra Personklasse.
Forening:
Denne form for relation repræsenterer statiske sammenhænge mellem klasse A og B. For eksempel; en medarbejder arbejder for en organisation.
Her er nogle regler for foreningen:
- Association er for det meste verbum eller en verbumsætning eller navneord eller navneord.
- Den skal navngives for at angive den rolle, som klassen spiller ved slutningen af foreningsstien.
- Obligatorisk for refleksive associationer
I dette eksempel er forholdet mellem studerende og college vist, hvilket er studier.
mangfoldighed
En multiplicitet er en faktor forbundet med en egenskab. Det specificerer, hvor mange forekomster af attributter, der oprettes, når en klasse initialiseres. Hvis en multiplicitet ikke er angivet, betragtes en som standard som en standard multiplicitet.
Lad os sige, at der er 100 studerende på et kollegium. Kollegiet kan have flere studerende.
Sammenlægning
Aggregation er en særlig type association, der modellerer et hel-del-forhold mellem aggregat og dets dele.
For eksempel består klassekollegiet af en eller flere studerende. Sammenlagt er de indeholdte klasser aldrig helt afhængige af containerens livscyklus. Her forbliver højskoleklassen, selvom eleven ikke er ledig.
Sammensætning:
Sammensætningen er en særlig type aggregering, som betegner stærkt ejerskab mellem to klasser, når en klasse er en del af en anden klasse.
For eksempel, hvis college er sammensat af klasser studerende. Kollegiet kunne indeholde mange studerende, mens hver elev kun tilhører én skole. Så hvis college ikke fungerer, fjernes alle eleverne også.
Aggregation vs. sammensætning
| Sammenlægning | Sammensætning |
|---|---|
| Aggregation indikerer et forhold, hvor barnet kan eksistere adskilt fra deres forældreklasse. Eksempel: bil (forælder) og bil (barn). Så hvis du sletter bilen, eksisterer barnebilen stadig. | Sammensætningsvisningsforhold, hvor barnet aldrig vil eksistere uafhængigt af forælderen. Eksempel: Hus (forælder) og Værelse (barn). Værelser vil aldrig adskilles i et hus. |
Abstract-klasser
Det er en klasse med en operationsprototype, men ikke implementeringen. Det er også muligt at have en abstract-klasse uden deklarerede operationer indeni. En abstracDet er nyttigt til at identificere funktionaliteterne på tværs af klasserne. Lad os se på et eksempel på en abstract-klasse. Antag, at vi har en mavemuskeltract-klasse kaldes som en bevægelse med en metode eller operation deklareret indeni. Metoden deklareret indeni abstract-klassen kaldes en bevæge sig ().
Denne mavemuskeltract-klassemetoden kan bruges af ethvert objekt, såsom en bil, et dyr, en robot osv., til at ændre den aktuelle position. Det er effektivt at bruge denne abstract-klassemetode med et objekt, fordi der ikke er angivet nogen implementering for den givne funktion. Vi kan bruge den på enhver måde til flere objekter.
I UML, maventract-klassen har samme notation som klassens. Den eneste forskel mellem en klasse og en abstract-klassen er, at klassenavnet udelukkende er skrevet i kursiv skrifttype.
En mavemuskeltract-klassen kan ikke initialiseres eller instantieres.
I ovenstående abstract-klasse notation, der er kun én mavemuskeltract-metode, som kan bruges af flere objekter i klasser.
Eksempel på UML klassediagram
Oprettelse af et klassediagram er en ligetil proces. Det involverer ikke mange tekniske detaljer. Her er et eksempel:
Hæveautomater er meget enkelt, da kunder skal trykke på nogle knapper for at modtage kontanter. Der er dog flere sikkerhedslag, som ethvert ATM-system skal bestå. Dette hjælper med at forhindre svindel og give penge eller behov for detaljer til bankkunder.
Nedenfor er et eksempel på et UML klassediagram:
Tjek også:- UML-diagrammer: Historie, typer, karakteristika, versioner, værktøjer
Klassediagram i softwareudviklings livscyklus
Klassediagrammer kan bruges i forskellige softwareudviklingsfaser. Det hjælper med at modellere klassediagrammer i tre forskellige perspektiver.
1. Konceptuelt perspektiv: Konceptuelle diagrammer beskriver ting i den virkelige verden. Du bør tegne et diagram, der repræsenterer begreberne i det undersøgte domæne. Disse begreber relaterer sig til klasse, og den er altid sproguafhængig.
2. Specifikationsperspektiv: Specifikationsperspektiv beskriver softwareabstractioner eller komponenter med specifikationer og grænseflader. Det giver dog ingen forpligtelse til specifik implementering.
3. Implementeringsperspektiv: Denne type klassediagrammer bruges til implementeringer i et bestemt sprog eller applikation. Implementeringsperspektiv, brug til softwareimplementering.
Bedste praksis for design af klassediagrammet
Klassediagrammer er de vigtigste UML-diagrammer, der bruges til udvikling af softwareapplikationer. Der er mange egenskaber, som bør overvejes, når man tegner et klassediagram. De repræsenterer forskellige aspekter af en softwareapplikation.
Her er nogle punkter, som du bør huske på, når du tegner et klassediagram:
- Navnet på klassediagrammet skal være meningsfuldt. Desuden skal det beskrive det virkelige aspekt af systemet.
- Forholdet mellem hvert element skal identificeres på forhånd.
- Ansvaret for hver klasse skal identificeres.
- For hver klasse skal minimumsantallet af ejendomme angives. Derfor kan uønskede egenskaber nemt gøre diagrammet kompliceret.
- Brugernoter bør inkluderes, når du har brug for at definere nogle aspekter af diagrammet. I slutningen af tegningen skal det være forståeligt for softwareudviklingsteamet.
- Til sidst, før du opretter den endelige version, skal diagrammet tegnes på almindeligt papir. Desuden bør den omarbejdes, indtil den er klar til endelig aflevering.
Tjek også:- UML Diagram Tutorial for begyndere: Lær UML Online GRATIS
