UML-klassediagram: Abstract-klasse med eksempler
Amelia Parker
⚡ Smart oppsummering
UML-klassediagram gir en statisk visning av et programvaresystem i blåkopistil, som viser klassene, attributtene, operasjonene og relasjonene som forbinder dem. Denne ressursen forklarer de viktigste elementene, relasjonstypene, abs.tract-klasser, og et eksempel på en fungerende minibank.
Hva er klasse i UML-diagram?
A Klasse i UML diagram er en blåkopi som brukes til å lage et objekt eller sett med objekter. Klassen definerer hva et objekt kan gjøre. Det er en mal for å lage ulike objekter og implementere deres oppførsel i systemet. En klasse i UML er representert av et rektangel som inkluderer rader med klassenavn, attributter og operasjoner.
Hva er klassediagram?
A Klassediagram i Software engineering er en statisk struktur som gir en oversikt over et programvaresystem ved å vise klasser, attributter, operasjoner og deres relasjoner mellom hverandre. Dette diagrammet inkluderer klassenavnet, attributtene og operasjonen i separate utpekte rom. Klassediagram hjelper til med å konstruere koden for utviklingen av programvareapplikasjonen.
Klassediagram definerer typene objekter i systemet og de forskjellige typene relasjoner som finnes mellom dem. Det gir et overblikk over en applikasjon på høyt nivå. Denne modelleringsmetoden kan kjøres med nesten alle objektorienterte metoder. En klasse kan referere til en annen klasse. En klasse kan ha sine objekter eller kan arve fra andre klasser.
Fordeler med klassediagram
- Klassediagram Illustrerer datamodeller for selv svært komplekse informasjonssystemer
- Den gir en oversikt over hvordan applikasjonen er bygget opp før man studerer selve koden. Dette kan lett redusere vedlikeholdstiden
- Det hjelper for bedre forståelse av generelle skjemaer for en applikasjon.
- Gjør det mulig å tegne detaljerte diagrammer som fremhever kode som må programmeres
- Nyttig for utviklere og andre interessenter.
Viktige elementer i et UML-klassediagram
Viktige elementer i UML klassediagram er:
- Klassenavn
- attributter
Klassenavn
Navnet på klassen er kun nødvendig i den grafiske representasjonen av klassen. Den vises i det øverste rommet. En klasse er blåkopi av et objekt som kan dele de samme relasjoner, attributter, operasjoner og semantikk. Klassen er gjengitt som et rektangel, inkludert dens navn, attributter og operasjoner i speratrom.
Følgende regler må ivaretas når du representerer en klasse:
- Et klassenavn skal alltid begynne med stor bokstav.
- Et klassenavn skal alltid stå i midten av det første rommet.
- Et klassenavn skal alltid skrives inn pin format.
- UML-abstracNavnet på t-klassen skal skrives i kursiv.
attributter
Et attributt kalles egenskap til en klasse som beskriver objektet som modelleres. I klassediagrammet er denne komponenten plassert rett under navnerommet.
Et avledet attributt beregnes fra andre attributter. For eksempel kan en elevs alder enkelt beregnes ut fra fødselsdatoen hans/hennes.
Attributter egenskaper
- Attributtene er vanligvis skrevet sammen med synlighetsfaktoren.
- Offentlig, privat, beskyttet og pakke er de fire synlighetene som er merket med henholdsvis +, -, # eller ~-tegn.
- Synlighet beskriver tilgjengeligheten til et attributt til en klasse.
- Attributter må ha et meningsfylt navn som beskriver bruken av det i en klasse.
Relasjoner
Det er hovedsakelig tre typer relasjoner i UML:
- avhengig
- generaliseringer
- Associations
Avhengighet
En avhengighet betyr forholdet mellom to eller flere klasser der en endring i den ene kan fremtvinge endringer i den andre. Det vil imidlertid alltid skape et svakere forhold. Avhengighet indikerer at en klasse er avhengig av en annen.
I de følgende UML-klassediagrameksemplene har Student en avhengighet av College
Generalisering:
En generalisering bidrar til å koble en underklasse til dens superklasse. En underklasse er arvet fra sin superklasse. Generaliseringsforhold kan ikke brukes til å modellere grensesnittimplementering. Klassediagram gjør det mulig å arve fra flere superklasser.
I dette eksemplet er klassen Elev generalisert fra Personklasse.
Assosiasjon:
Denne typen relasjoner representerer statiske relasjoner mellom klassene A og B. For eksempel; en ansatt jobber for en organisasjon.
Her er noen regler for foreningen:
- Association er for det meste verb eller en verbfrase eller substantiv eller substantivfrase.
- Den skal navngis for å indikere rollen som klassen spiller ved slutten av tilknytningsbanen.
- Obligatorisk for refleksive assosiasjoner
I dette eksemplet vises forholdet mellom student og høyskole som er studier.
mangfold
En multiplisitet er en faktor knyttet til et attributt. Den spesifiserer hvor mange forekomster av attributter som opprettes når en klasse initialiseres. Hvis en multiplisitet ikke er spesifisert, anses en som standard som en standard multiplisitet.
La oss si at det er 100 studenter på en høyskole. Høgskolen kan ha flere studenter.
aggregering
Aggregasjon er en spesiell type assosiasjon som modellerer et hel-dels forhold mellom aggregat og dets deler.
For eksempel består klassehøgskolen av en eller flere studenter. I aggregering er de inneholdte klassene aldri helt avhengige av beholderens livssyklus. Her blir høgskoleklassen værende selv om eleven ikke er tilgjengelig.
sammensetning:
Sammensetningen er en spesiell type aggregering som betegner sterkt eierskap mellom to klasser når en klasse er en del av en annen klasse.
For eksempel, hvis college er sammensatt av klasser student. Høgskolen kunne inneholde mange studenter, mens hver student tilhører kun en høyskole. Så hvis høyskolen ikke fungerer, fjernes alle studentene også.
Aggregasjon vs. sammensetning
| aggregering | sammensetning |
|---|---|
| Aggregasjon indikerer et forhold der barnet kan eksistere atskilt fra foreldreklassen. Eksempel: bil (foreldre) og bil (barn). Så hvis du sletter bilen, eksisterer fortsatt barnebilen. | Sammensetningsvisningsforhold der barnet aldri vil eksistere uavhengig av forelderen. Eksempel: Hus (foreldre) og Rom (barn). Rom vil aldri skilles til et hus. |
Abstract-klasser
Det er en klasse med en operasjonsprototype, men ikke implementeringen. Det er også mulig å ha en abstract-klasse uten noen operasjoner deklarert inni den. En abstract er nyttig for å identifisere funksjonalitetene på tvers av klassene. La oss se på et eksempel på en abstract-klassen. Anta at vi har en magemuskeltract-klassen kalles som en bevegelse med en metode eller operasjon deklarert inni den. Metoden deklarert inni abstract-klassen kalles en flytte ().
Denne magemusklenetract-klassemetoden kan brukes av ethvert objekt, for eksempel en bil, et dyr, en robot osv., for å endre gjeldende posisjon. Det er effektivt å bruke denne abstract-klassemetode med et objekt fordi ingen implementering er gitt for den gitte funksjonen. Vi kan bruke den på hvilken som helst måte for flere objekter.
I UML, magemusklenetract-klassen har samme notasjon som klassen. Den eneste forskjellen mellom en klasse og en abstract-klassen er at klassenavnet er skrevet i kursiv skrift.
En magemuskeltract-klassen kan ikke initialiseres eller instansieres.
I det ovennevnte abstract-klassenotasjon, det er bare én magemuskeltract-metode som kan brukes av flere objekter i klasser.
Eksempel på UML klassediagram
Å lage et klassediagram er en enkel prosess. Det involverer ikke mange tekniske detaljer. Her er et eksempel:
Minibanksystemet er veldig enkelt da kunder må trykke på noen knapper for å motta kontanter. Imidlertid er det flere sikkerhetslag som ethvert minibanksystem må passere. Dette bidrar til å forhindre svindel og gi kontanter eller behovsdetaljer til bankkunder.
Nedenfor er et eksempel på et UML klassediagram:
Sjekk også: - UML-diagrammer: historie, typer, kjennetegn, versjoner, verktøy
Klassediagram i programvareutviklings livssyklus
Klassediagrammer kan brukes i ulike programvareutviklingsfaser. Det hjelper med å modellere klassediagrammer i tre forskjellige perspektiver.
1. Konseptuelt perspektiv: Konseptuelle diagrammer beskriver ting i den virkelige verden. Du bør tegne et diagram som representerer konseptene i domenet som studeres. Disse begrepene knyttet til klasse og den er alltid språkuavhengig.
2. Spesifikasjonsperspektiv: Spesifikasjonsperspektiv beskriver programvareabstraceller komponenter med spesifikasjoner og grensesnitt. Det gir imidlertid ingen forpliktelse til spesifikk implementering.
3. Implementeringsperspektiv: Denne typen klassediagrammer brukes for implementeringer i et spesifikt språk eller applikasjon. Implementeringsperspektiv, bruk for programvareimplementering.
Beste praksis for utforming av klassediagrammet
Klassediagrammer er de viktigste UML-diagrammene som brukes til utvikling av programvareapplikasjoner. Det er mange egenskaper som bør vurderes når du tegner et klassediagram. De representerer ulike aspekter ved en programvareapplikasjon.
Her er noen punkter du bør huske på når du tegner et klassediagram:
- Navnet som gis til klassediagrammet må gi mening. Dessuten bør den beskrive det virkelige aspektet av systemet.
- Forholdet mellom hvert element må identifiseres på forhånd.
- Ansvaret for hver klasse må identifiseres.
- For hver klasse bør minimum antall eiendommer spesifiseres. Derfor kan uønskede egenskaper lett gjøre diagrammet komplisert.
- Brukernotater bør inkluderes når du trenger å definere et aspekt av diagrammet. På slutten av tegningen må det være forståelig for programvareutviklingsteamet.
- Til slutt, før du oppretter den endelige versjonen, må diagrammet tegnes på vanlig papir. Dessuten bør den omarbeides til den er klar for endelig innlevering.
Sjekk også: - UML Diagram Tutorial for nybegynnere: Lær UML Online GRATIS
