Introduksjon til UML-komponentdiagram

Unified Modelling Language, det vil si UML er i enkle ord, et modelleringsspråk for generelle formål. 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. UML-komponentdiagrammer 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 ble den administrert av dem. Etter dette publiserte ISO i 2005 UML som en godkjent standard. UML har blitt revidert og gjennomgått gjennom årene med jevne mellomrom. Videre vil vi diskutere komponentdiagrammer.

Hva er komponentdiagram i UML?

  • UML-komponentdiagrammer brukes i utgangspunktet for modellering av aspektene som er fysiske ved objektorienterte systemer som brukes i visualisering og dokumentasjon av systemer som er komponentbaser, og det brukes også til konstruksjon av kjørbare systemer ved hjelp av frem- og bakoveringeniør. Komponentdiagrammer er i utgangspunktet diagrammer av klassen som fokuserer på komponenter i et system, og brukes ofte for modellering av den statiske implementeringsvisningen av systemet.
  • Det bryter også ned det faktiske systemet som er under utvikling til forskjellige nivåer av funksjonalitet, i utgangspunktet høyt nivå. Hver komponent i UML er ansvarlig for bare et enkelt klart mål i hele systemet, og det samhandler med bare andre viktige elementer, og det også bare etter behov.
  • Det eneste og viktige formålet med et komponentdiagram i UML er å demonstrere forholdet mellom ulike komponenter i systemet. Hvis vi snakker om UML 2.0, er ordet “komponent” definert som en modul av klasser som representerer systemer eller undersystemer som er uavhengige og som har muligheten til å grensesnitt med resten av systemet.
  • Det er en tilnærming kalt komponentbasert utvikling, også kalt CBD, som kretser rundt alle komponentene. I denne tilnærmingen gjør hele systemet det det egentlig er ment å gjøre siden det tillater planleggeren å identifisere forskjellige komponenter. Vanligvis, hvis vi snakker om Objektorientert programmeringstilnærming, tillater komponentdiagram alltid en seniorutvikler å gruppere klassene, avhengig av deres felles formål og dermed gjøre det mulig for utvikleren så vel som andre å se på programvareutviklingsprosjektet på et høyere nivå.
  • Selv om komponentdiagrammer i UML kan se ut til å være kompliserte ved første blikk, er de imidlertid ganske uvurderlige når det gjelder å bygge vårt system.

Komponentdiagrammer har mange fordeler som kan hjelpe teamet ditt på forskjellige måter:

  1. Det tar hensyn til hvordan systemets komponenter forholder seg.
  2. Det understreker atferden til tjenester når det er relatert til grensesnittet.
  3. Den forestiller seg også den fysiske strukturen i systemet.

Forklar symboler på UML-komponentdiagram

Symboler for UML-komponentdiagrammer er mange som komponent, pakke, pakkebeholder, avhengighet, generalisering, begrensning, ugjennomsiktig stereotype, notat og mange andre. La oss gå gjennom noen viktige. Symbolene er gitt ved siden av dem.

1. Komponent: Komponent i UML er definert som en modulær del av et system. Den definerer alltid oppførselen sin som i form av påkrevde og gitte grensesnitt.

2. Pakke: Pakke i UML kan defineres som noe som kan gruppere elementer, og gir deretter et navneområde for alle disse grupperte elementene.

3. Pakkebeholdere: Pakkebeholdere i UML kan defineres som noe som beskriver UML-elementer som klasser, komponenter og brukstilfeller.

4. Avhengighet: Avhengighetsforhold i UML kan defineres som et forhold der et av elementene som er klienten bruker eller avhenger av et annet element som er leverandøren.

5. Generalisering: Generalisering i UML kan defineres som forholdet der et av modellelementene, dvs. barnet er basert på et annet modellelement, dvs. foreldrene.

6. Begrensning: Begrensning i UML kan defineres som noe som gjør oss i stand til å avgrense semantikken til UML-modellelementet. Det er en forlengelsesmekanisme. Merknad i UML består av kommentarer eller tekstinformasjon.

Merknad i UML kan defineres som noe som representerer enten maskinvare- eller programvareobjekter som er av et høyere nivå hvis vi sammenligner med komponenter. komponenter.

7. Grensesnitt: I UML kan defineres som noe som demonstrerer materialene som en komponent enten vil motta eller vil gi. Vi kan representere grensesnitt med enten tekstnotater eller symboler som lollipop, socket, eller ball og socket former.

8. port: Symbol i UML kan defineres som noe som nevner et annet samspillspunkt mellom miljøet og komponenten. Porter kan symboliseres ved hjelp av et lite torg.

Hvordan lage et komponentdiagram?

Vi kan enkelt lage et perfekt komponentdiagram i UML fra bunnen av ved hjelp av Lucid Chart. Alt vi trenger å gjøre er å følge disse trinnene:

  • Enten åpner du et tomt dokument eller begynner med en mal.
  • UML-formbibliotek skal aktiveres. Klikk deretter på “Shapes” o på venstre side av redaktøren og sjekk på “UML” i Shape Library Manager, og klikk deretter “Save”.
  • Velg formen du vil ha fra biblioteket som skal legges til, og alt du trenger å gjøre er å dra den formen fra verktøykassen inn på lerretet.
  • Tegn linjer mellom figurer for å modellere flyt og vi er ferdige.

Et av eksemplene er som nedenfor for Library Mangement System vist nedenfor

Transaksjonene vises her skaper et nettverk av forhold mellom komponenter i biblioteksystemet. For å forstå hvordan disse forholdene fungerer og hvordan systemet fungerer generelt, må du undersøke UML-diagrammet som er vist ovenfor. Du kan også bruke den som en mal.

Konklusjon

Dermed kan vi konkludere med at komponentdiagrammet er et veldig viktig diagram der arkitekter ofte vil lage ganske tidlig i et prosjekt. Men det er nytten som strekker seg over systemets levetid. Komponentdiagrammer er ganske uvurderlige siden de modellerer og dokumenterer systemets arkitektur.

Anbefalt artikkel

Dette har vært en guide til UML-komponentdiagram. Her diskuterer vi de forskjellige typene symboler som er forklart i detalj. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -

  1. Typer UML-diagrammer
  2. UML-sekvensdiagram
  3. UML aktivitetsdiagram
  4. UML Bruk saksdiagram
  5. Omvendt engineering