UML-relasjonstyper: Forening, avhengighet, generalisering

La oss studere dem i detalj

Typer UML-klassediagramrelasjoner

Association

Det er et sett med lenker som kobler sammen elementer i UML-modellen. Den definerer også hvor mange objekter som deltar i den relasjonen.

Avhengighet

I et avhengighetsforhold, som navnet antyder, er to eller flere elementer avhengige av hverandre. I denne typen forhold, hvis vi gjør en endring til et bestemt element, er det sannsynlig at alle de andre elementene også vil bli påvirket av endringen.

Generalisering

Det kalles også et foreldre-barn-forhold. I generalisering er ett element en spesialisering av en annen generell komponent. Det kan erstattes med det. Det brukes mest for å representere arv.

realisering

I et realiseringsforhold til UML, betegner en enhet et ansvar som ikke er implementert av seg selv og den andre enheten som implementerer dem. Dette forholdet finnes for det meste i tilfelle av grensesnitt.

Association

Det er et strukturelt forhold som representerer objekter som kan kobles til eller assosieres med et annet objekt inne i systemet. Følgende begrensninger kan brukes på assosiasjonsforholdet.

• {implisitt} – Implisitte begrensninger spesifiserer at forholdet ikke er åpenbart; den er basert på et konsept.
• {bestilt} – Ordnede begrensninger spesifiserer at settet med objekter i den ene enden av en assosiasjon er på en bestemt måte.
• {changable} – Changeable constraint spesifiserer at forbindelsen mellom ulike objekter i systemet kan legges til, fjernes og endres i henhold til kravet.
• {addOnly} – Den spesifiserer at de nye forbindelsene kan legges til fra et objekt som ligger i den andre enden av en assosiasjon.
• {frossen} – Den spesifiserer at når en kobling legges til mellom to objekter, kan den ikke endres mens den frosne begrensningen er aktiv på den gitte koblingen eller en tilkobling.

Vi kan også lage en klasse som har assosiasjonsegenskaper; det kalles som en foreningsklasse.

Refleksiv assosiasjon

Den refleksive assosiasjonen er en undertype av assosiasjonsforhold i UML. I en refleksiv assosiasjon kan forekomstene av samme klasse relateres til hverandre. En forekomst av en klasse sies også å være et objekt.

Refleksiv assosiasjon sier at en kobling eller en forbindelse kan være tilstede innenfor objektene til samme klasse.

La oss se på et eksempel på en klassefrukt. Fruktklassen har to forekomster, som mango og eple. Refleksiv assosiasjon sier at en kobling mellom mango og eple kan være til stede da de er forekomster av samme klasse, for eksempel frukt.

Regissert forening

Som navnet antyder, er den rettet assosiasjonen knyttet til strømningsretningen innenfor foreningsklasser.

I en rettet assosiasjon er strømmen rettet. Assosiasjonen fra en klasse til en annen klasse flyter bare i en enkelt retning.

Det er angitt med en heltrukket linje med en pilspiss.

Eksempel:

Du kan si at det er et rettet assosiasjonsforhold mellom en server og en klient. En server kan behandle forespørsler fra en klient. Denne flyten er enveis, som bare flyter fra server til klient. Derfor kan et rettet assosiasjonsforhold være tilstede i servere og klienter til et system.

Avhengighet

Ved å bruke et avhengighetsforhold i UML kan man relatere hvordan ulike ting i et bestemt system er avhengige av hverandre. Avhengighet brukes til å beskrive forholdet mellom ulike elementer i UML som er avhengige av hverandre.

Stereotyper

• "binde" – Bind er en begrensning som spesifiserer at kilden kan initialisere malen på et målsted ved å bruke oppgitte parametere eller verdier.
• «avlede» – Det representerer at plasseringen til et kildeobjekt kan beregnes fra målobjektet.
• «venn» – Den spesifiserer at kilden har unik synlighet i målobjektet.
• «instanceOf» – Den spesifiserer at forekomsten av en målklassifikator er kildeobjektet.
• «instansiere» – Den spesifiserer at kildeobjektet er i stand til å lage forekomster av et målobjekt.
• "raffinere" – Den spesifiserer at kildeobjektet har eksepsjonell abstracsjon enn målobjektets.
• "bruk" – Den brukes når pakker opprettes i UML. Bruksstereotypen beskriver at elementene i en kildepakke også kan være tilstede inne i målpakken. Den beskriver at kildepakken bruker noen elementer i en målpakke.
• "erstatte" – spesifiserer at klienten kan erstattes av leverandøren under kjøring.
• "adgang" – Den spesifiserer at kildepakken har tilgang til elementene i målpakken som også kalles som en privat sammenslåing.
• "Import" – Den spesifiserer at målet kan importere elementet i en kildepakke slik de er definert i mål som også kalles som en offentlig sammenslåing.
• "tillate" – spesifiserer at kildeelementet har tilgang til leverandørelementet uansett leverandørens deklarerte synlighet.
• "forlenge" – Hjelper deg med å spesifisere at målet kan utvide virkemåten til kildeelementet.
• "inkludere" – Lar deg spesifisere kildeelementet som kan inkludere virkemåten til et annet element på et spesifisert sted. (samme som et funksjonskall i c/c++)
• "bli" – Den spesifiserer at målet ligner kilden med forskjellige verdier og roller.
• "ringe" – Den spesifiserer at kilden kan påkalle en målobjektmetode.
• "kopiere" – Den spesifiserer at målobjektet er uavhengig, kopi av et kildeobjekt.
• «parameter» – leverandøren er en parameter for kundens drift.
• "sende" – klienten er en operasjon som sender leverandøren et uspesifisert mål.

Stereotyper blant statsmaskiner

• "sende" – Spesifiserer at kildeoperasjonen sender målhendelsen.

Generalisering

Det er et forhold mellom en generell enhet og en unik enhet som er tilstede inne i systemet.

I et generaliseringsforhold kalles det objektorienterte konseptet arv kan implementeres. Det eksisterer et generaliseringsforhold mellom to objekter, også kalt enheter eller ting. I et generaliseringsforhold er en enhet en forelder, og en annen sies å være som barn. Disse enhetene kan representeres ved å bruke arv.

Ved arv kan et barn av en hvilken som helst forelder få tilgang til, oppdatere eller arve funksjonaliteten som spesifisert i det overordnede objektet. Et underordnet objekt kan legge til funksjonaliteten til seg selv, samt arve strukturen og oppførselen til et overordnet objekt.

Denne typen forhold kollektivt kjent som et generaliseringsforhold.

Stereotyper og deres begrensninger

• «implementering» – Denne stereotypen brukes til å representere at den underordnede enheten blir implementert av den overordnede enheten ved å arve strukturen og oppførselen til et overordnet objekt uten å bryte reglene. OBS: Denne stereotypen er mye brukt i en enkelt arv.

Generaliseringsforhold inneholder begrensninger som fullstendig, ufullstendig for å sjekke om alle underordnede enheter er inkludert i forholdet eller ikke.

realisering

I et realiseringsforhold til UML, betegner en enhet et ansvar som ikke er implementert av seg selv og den andre enheten som implementerer dem. Dette forholdet finnes for det meste i tilfelle av grensesnitt.

Realisering kan representeres på to måter:

• Ved hjelp av en kanonisk form
• Bruke en elided form

I diagrammet ovenfor realiserer kontoforretningsregler grensesnittet IRuleAgent.

Typer realisering

1. Kanonisk form: I en realiseringsrelasjon for UML brukes den kanoniske formen til å realisere grensesnitt på tvers av systemet. Den bruker en grensesnittstereotypi for å opprette et grensesnitt, og realiseringsrelasjonen brukes til å realisere det spesifikke grensesnittet. I en kanonisk form er realiseringsrelasjonen angitt med den stiplede linjen med en betydelig åpen pilspiss. I diagrammet ovenfor realiseres grensesnittet Iruleagent ved hjelp av et objekt kalt Account Business Rules.
2. Utelatt form: Realisering i UML klassediagram kan også vises ved hjelp av en elidert form. I en elidert form er grensesnittet angitt med en sirkel, som også kalles en lollipop-notasjon. Dette grensesnittet, når det realiseres ved hjelp av noe som helst som finnes i systemet, skaper en elidert struktur. I diagrammet ovenfor er grensesnittet Iruleagent angitt med en elidert form som realiseres av acctrule.dll.

sammensetning

Det er ikke et standard UML-forhold, men det brukes fortsatt i ulike applikasjoner.

Sammensatt aggregering er en undertype av aggregeringsforhold med egenskaper som:

• det er en toveis assosiasjon mellom objektene.
• Det er en hel/del-relasjon.
• Hvis en kompositt slettes, slettes alle andre deler knyttet til den.

Sammensatt aggregering beskrives som en binær assosiasjon dekorert med en fylt svart diamant i den samlede (hele) enden.

En mappe er en struktur som inneholder n antall filer. En mappe brukes til å lagre filene i den. Hver mappe kan knyttes til et hvilket som helst antall filer. I et datasystem er hver enkelt fil en del av minst én mappe inne i filorganisasjonssystemet. Den samme filen kan også være en del av en annen mappe, men det er ikke obligatorisk. Når en fil fjernes fra mappen, forblir mappen upåvirket, mens dataene knyttet til den aktuelle filen blir ødelagt. Hvis en sletteoperasjon utføres på mappen, påvirker det også alle filene som finnes i mappen. Alle filene knyttet til mappen blir automatisk ødelagt når mappen er fjernet fra systemet.

Denne typen relasjoner i UML er kjent av sammensatt aggregeringsforhold.

aggregering

An aggregering er en undertype av en assosiasjonsrelasjon i UML. Aggregasjon og komposisjon er begge typene assosiasjonsrelasjoner i UML. En aggregasjonsrelasjon kan beskrives enkelt som «et objekt i én klasse kan eie eller få tilgang til objektene i en annen klasse».

I et aggregeringsforhold forblir det avhengige objektet innenfor omfanget av et forhold selv når kildeobjektet blir ødelagt.

La oss se på et eksempel på en bil og et hjul. En bil trenger et hjul for å fungere korrekt, men et hjul trenger ikke alltid en bil. Den kan også brukes med sykkelen, sykkelen eller andre kjøretøy, men ikke en bestemt bil. Her er hjulobjektet meningsfylt også uten bilobjektet. En slik type relasjon kalles en aggregeringsrelasjon.

Spørsmål og svar