Funktioner i bilden av UML-diagram

För UML-diagram finns det tre typer av visuella grafiska symboler som är viktiga när det gäller informationen de innehåller:

· Geometriska figurer på planet, som spelar rollen som hörn av graferna i motsvarande diagram. I det här fallet fungerar de geometriska figurerna själva som grafiska primitiver för UML-språket, och formen på dessa figurer (rektangel, ellips) måste strikt överensstämma med bilden av individuella element i UML-språket (klass, användningsfall, tillstånd, aktivitet ). UML:s grafiska primitiver har fast semantik som användare inte kan åsidosätta. Grafiska primitiver bör ha sina egna namn, och eventuellt annan text som finns inom gränserna för motsvarande geometriska former eller, som ett undantag, nära dessa former.

· Grafiska samband, som representeras av olika linjer på planet. Relationer i UML generalisera begreppet bågar och kanter från grafteorin, men ha en mindre formell karaktär och mer utvecklad semantik.

· Speciella grafiska symboler avbildade nära vissa visuella element i diagrammen och har karaktären av ytterligare specifikationer (dekorationer).

Alla UML-diagram ritas med hjälp av plana former. Individuella element - med geometriska former som kan ha olika höjder och bredder för att rymma andra konstruktioner av UML inom dem. Oftast placeras textrader inuti sådana symboler, som förtydligar semantiken eller fixar individuella egenskaper för motsvarande element i UML. Informationen som finns i formerna är relevant för specifik modell av systemet som designas, eftersom det reglerar implementeringen av motsvarande element i programkoden.

Banor är sekvenser av linjesegment som förbinder individuella grafiska symboler. I detta fall måste ändpunkterna för linjesegmenten nödvändigtvis vara i kontakt med geometriska former, används för att beteckna diagrammens hörn, som är brukligt inom grafteorin. Ur en konceptuell synvinkel betonas UML-vägar eftersom de är enkla topologiska enheter. Enskilda delar av en väg eller segment kanske inte existerar utanför den innehållande vägen. Banor rör alltid andra grafiska symboler på båda gränserna för motsvarande linjesegment, dvs. banor kan inte avslutas i diagrammet med en linje som inte rör någon grafisk symbol. Som nämnts ovan kan banor ha en speciell grafisk form som en ände eller terminator - en ikon som är avbildad i en av ändarna av linjerna.

Ytterligare ikoner eller dekorationer är grafiska former med en fast storlek och form. De kan inte öka sin storlek för att få plats med ytterligare symboler. Ikoner placeras både inuti och utanför andra grafiska strukturer. Exempel på ikoner är avslutningar på länkar mellan element i diagram, eller grafiska symboler för synlighetskvantifierare för attribut och klassoperationer.

Samarbetsdiagram

Samarbetsdiagram är avsedda att beskriva de dynamiska aspekterna av systemet som modelleras. De är vanligtvis vana vid:

· Visa en uppsättning interagerande objekt i en verklig miljö "ur fågelperspektiv";

· Att fördela funktionalitet mellan klasser, baserat på resultaten av att studera de dynamiska aspekterna av systemet;

Beskriv utförandelogiken komplexa operationer, särskilt i fall där ett objekt interagerar med flera objekt till;

· Studera de roller som objekt spelar inom systemet, såväl som relationerna mellan objekt där de är involverade i dessa roller.

När man talar om samarbetsdiagram nämns ofta två "nivåer" av sådana diagram:

· instansnivå(exempel, instans-nivå): visar interaktioner mellan objekt (klassinstanser); så diagram vanligtvis skapad för att utforska intern organisation objektorienterat system.

· specifikationsnivå(Specification-Level): Används för att studera rollerna som spelas av huvudklasserna i systemet.

Den visar interaktionen mellan objekt, som utförs genom att skicka och ta emot meddelanden.

Komponentdiagram

Komponenter länkas genom beroenden när du ansluter det nödvändiga gränssnittet för en komponent till det befintliga gränssnittet för en annan komponent. Detta illustrerar klient-källa-relationen mellan de två komponenterna.

Beroende indikerar att en komponent tillhandahåller den tjänst som behövs av en annan komponent. Beroendet visas med en pil från klientgränssnittet eller porten till det importerade gränssnittet.

Huvudtypen av enheter i komponentdiagrammet är komponenterna 1 själva, såväl som gränssnitten 2, genom vilka förhållandet mellan komponenterna indikeras. I ett komponentdiagram gäller följande samband:

· Implementeringar mellan komponenter och gränssnitt (en komponent implementerar ett gränssnitt);

· Beroenden mellan komponenter och gränssnitt (komponenten använder gränssnittet) 3.

Implementeringsdiagram

Distributionsdiagrammet är avsett att visualisera elementen och komponenterna i ett program som endast existerar i det skede då det körs (runtime). I det här fallet visas bara komponenter-instanserna av programmet, som är körbara filer eller dynamiska bibliotek. Komponenter som inte används under körning visas inte i distributionsdiagrammet. Så komponenter med källkoder för program kan bara finnas i komponentdiagrammet. De visas inte i distributionsdiagrammet.

Ett distributionsdiagram innehåller grafiska representationer av processorer, enheter, processer och relationerna mellan dem. Till skillnad från logiska vydiagram är ett distributionsdiagram enhetligt för systemet som helhet, eftersom det helt måste återspegla detaljerna i dess implementering. Att utforma ett distributionsdiagram är vanligtvis det sista steget i modellspecifikationen. mjukvarusystem.

När du utvecklar ett distributionsdiagram eftersträvas följande mål:

· Bestäm fördelningen av systemkomponenter efter dess fysiska noder;

· visa fysiska förbindelser mellan alla noder i systemimplementeringen i skedet av dess exekvering;

· Identifiera flaskhalsar i systemet och konfigurera om dess topologi för att uppnå den prestanda som krävs.

15.2. Syfte och sammansättning av komponentdiagrammet

Komponentdiagrammet låter dig bestämma sammansättningen av programvarukomponenter, som kan vara källkod, binär och körbar kod, samt att fastställa beroenden mellan dem.

När man utvecklar komponentdiagram eftersträvas följande mål:

Specifikation allmän struktur källkod system;

Specifikation av den körbara versionen av systemet.

Detta diagram ger en konsekvent övergång från logisk till fysisk representation av systemet i form av mjukvarukomponenter. Vissa komponenter kan bara existera vid kompilering programkod, andra - i skedet av dess utförande. Huvudelementen i ett diagram är komponenter, gränssnitt och beroenden mellan dem. Dessutom kan den visa nyckelklasserna som ingår i komponenterna.

Komponent (engelsk komponent) är den fysiska delen av systemet. Komponenter, som är filer med källkod för klasser, bibliotek, körbara moduler, etc., som måste ha en konsekvent uppsättning gränssnitt. Följande grafiska symboler används för att representera dem grafiskt.

Ris. 15.2. Komponentexempel

Inuti rektangeln skrivs namnet på komponenten och eventuellt några ytterligare information som ett taggat värde.

Komponenter kan ha följande standardstereotyper:

- "fil" - vilken fil som helst, förutom tabellen:

o "körbar" - program (körbar fil);

o "bibliotek" - statiskt eller dynamiskt bibliotek;

o "källa" - en fil med programmets källkod;

o "dokument" - andra filer (till exempel hjälpfil);

- "tabell" - databastabell.

Inuti en komponent, som en klass, kan det väljas ytterligare avsnitt, där de tillhandahållna eller erforderliga gränssnitten och klasserna, metoderna (operationerna), namnet på komponentfilen (artefakter) etc. anges.

Ris. 15.3. Komponent med sektioner

Gränssnitt (Engelskt gränssnitt) är en externt synlig, namngiven uppsättning operationer som en klass, komponent eller undersystem kan tillhandahålla till en annan klass, komponent eller undersystem för att utföra sina funktioner. I vissa programmeringsspråk, särskilt i Java, är ett gränssnitt en separat klass som ingår och implementeras (instansieras) som en del av programkoden för operationer som en del av andra klasser. På komponentdiagrammet visas gränssnittet på samma sätt som på (till vänster om komponenten, de gränssnitt som krävs för drift, till höger - tillhandahålls).

Ris. 15.4. Gränssnittsvisningsmetoder

Föreningsrelation visas mellan komponenter och deras gränssnitt. Beroendeförhållande betyder att implementeringen av vissa komponenter är beroende av implementeringen av andra. Detta är möjligt i följande fall:

I metoderna för klasserna för en komponent (beroende) anropas metoder eller attributen för klasserna för en annan komponent (oberoende) kallas;

En komponent består av andra komponenter (till exempel när man bygger en körbar fil från filer med källkoder);

En komponent läser eller skriver data till en annan komponent;

Relation mellan databastabeller;

På grund av det mångsidiga syftet med ett komponentdiagram, bör följande regler och riktlinjer följas under utvecklingen.

1. Innan du utvecklar komponentdiagram är det nödvändigt att bestämma vilka fysiska delar (filer) mjukvarusystemet ska bestå av. I det här fallet måste två uppgifter lösas - distributionen av klasser i källkodsfiler och i undersystem. I det senare fallet kan fördelningen av klasser i specialiserade (funktionellt inriktade på ämnesområdet) paket hjälpa. I detta skede bör uppmärksamhet ägnas åt implementeringen av systemet som skulle ge förmågan återanvändning kod på grund av rationell nedbrytning av systemet, d.v.s. för att minimera antalet kopplingar mellan komponenter.

2. När du anger den allmänna strukturen för systemets källkod är det nödvändigt att ta hänsyn till detaljerna för det programmeringsspråk som komponenterna implementeras med. I synnerhet i Java rekommenderas det att beskriva en separat klass i en separat fil, trots att språket låter dig beskriva flera klasser i en fil och använda mekanismen för interna klasser. Komponentdiagrammet som används för detta ändamål visas i följande figur.

Ris. 15.5. Fragment av ett komponentdiagram som anger källkodens struktur

Diagrammet i fig. 15.5 visar sammansättningen av klasserna (filerna) som utgör den körbara komponenten iskraPUT.jar, samt beroenden mellan klasserna.

3. För specifikationen av en körbar version av systemet är det nödvändigt att ha en preliminär topologi av systemet, det vill säga en skiss. För varje nod i nätverket kan ett komponentdiagram byggas, som definierar uppsättningen filer som krävs för driften av delsystemet/subsystemen vid en separat arbetsstation.

Ris. 15.6. Exempel på ett komponentdiagram som anger sammansättningen av komponenter på en användares arbetsplats

4. Ett diagram kan representera beroendeförhållanden mellan komponenter och klasserna de innehåller. Denna information är viktig för att säkerställa överensstämmelse mellan de logiska och fysiska representationerna av systemet. I det här fallet kan beroende visas på två sätt:

Visa klasser separat från komponenten och associera komponenten med varje klass i ett beroendeförhållande. Till exempel, i fig. 15.5 istället för komponenter med tillägget "java", visa motsvarande klasser;

Visa klasserna inuti komponentsymbolen.

6. För att visuellt visa detaljerna för komponenter kan du använda grafiska stereotyper istället för en standardkomponentsymbol med en strängstereotyp.

Visa uppdelningen av ett mjukvarusystem i strukturella komponenter och kopplingar (beroenden) mellan komponenter.

Filer, bibliotek, moduler, körbara filer, paket etc. kan fungera som fysiska komponenter.

Handlingsplan

Efter att ha läst avsnitten (Exempel, Applikation) kan du prova dig fram med att göra komponentdiagram själv.

Hur man tillämpar designmetoden

Komponentdiagram bör användas när systemet är uppdelat i komponenter och du vill visa deras samband med hjälp av gränssnitt eller ett komponentdiagram i systemets lågnivåstruktur.

Användningsexempel

Det pågår en debatt i den objektorienterade gemenskapen om vad som är skillnad mellan komponent och normalklass... Vi kommer inte att diskutera denna kontroversiella fråga här, utan kommer att visa UML-notationen som används för att skilja dem från varandra.

I UML 1 fanns en separat symbol för komponenten (Figur 14.1). V UML 2 den här ikonen finns inte, men du kan markera klassens rektangel med en liknande ikon. Eller så kan du använda nyckelord « komponent» ( komponent).

Förutom denna ikon förde komponenterna inte med sig några nya beteckningar. Komponenter kommunicerar med varandra med hjälp av tillhandahållna eller nödvändiga gränssnitt, och kapsling används vanligtvis bara i klassdiagram. Du kan också bryta ner komponenter med hjälp av sammansatta strukturdiagram.

I fig. 14.2 visar ett exempel på ett enkelt komponentdiagram. I det här exemplet, komponenten Till (kassör) kan interagera med komponenten Försäljningsserver använder gränssnittet försäljningsmeddelande. Eftersom nätverket är opålitligt, komponenten Meddelandekö ställ in så att kassan kan prata med servern när nätverket är uppe och prata med meddelandekön när nätverket är nere. Då kan meddelandekön prata med servern när nätverket blir tillgängligt igen. Som ett resultat tillhandahåller meddelandekön ett gränssnitt för att prata med kassörskan och kräver samma gränssnitt för att prata med servern. Servern är uppdelad i två huvudkomponenter: Transaktionsprocessorn implementerar meddelandegränssnittet, och Redovisningsförare kommunicerar med Redovisningssystemet.

Kärnan i en komponent är föremål för oändliga kontroverser. Här är en av de mer genomtänkta domarna vi har hittat:

Komponenter är inte teknik. Tekniker har svårt att förstå dem. Komponenter är mer en typ av kundrelation till programvara... De vill kunna köpa den programvara de behöver i delar och även kunna uppdatera den på det sätt som de uppdaterar sin stereo. De vill att de nya komponenterna ska fungera på samma sätt som de gamla och uppdatera dem enligt deras planer, inte enligt tillverkarnas anvisningar. De vill ha system olika tillverkare kunde arbeta tillsammans och var utbytbara. Det är mycket rimliga krav. En hake: de är svåra att åstadkomma.
Ralph Johnson, http://www.c2.com/cgi/wiki?DoComponentsExist

Det viktiga är att komponenterna representerar föremål som kan köpas och uppgraderas oberoende av varandra. Som ett resultat är att dela upp systemet i komponenter mer en marknadsföringslösning än en teknisk. Hohmans bok ger utmärkt vägledning i detta ämne. Det påminner dig också om att akta dig för att dela upp systemet i för små komponenter, eftersom det är väldigt stor kvantitet komponenter är svåra att hantera, särskilt när versionsproduktionen reser upp sitt fula huvud; därav uttrycket "DLL helvete" eller "dll helvete"... I tidiga versioner av UML användes komponenter för att representera fysiska strukturer som DLL. Nu är detta inte relevant; denna uppgift löses för närvarande med hjälp av artefakter(artefakter).

Prenumerera på sajtnyheterna, du hittar prenumerationsformuläret i högerspalten på sajten.

Om du vill lära dig att frilansa professionellt, bjuder vi in dig till kursen "".

Komponentdiagrammet, i motsats till de tidigare betraktade diagrammen, beskriver egenskaperna hos den fysiska representationen av systemet. Komponentdiagram, ett statiskt strukturdiagram, visar uppdelningen av ett mjukvarusystem i strukturella komponenter och kopplingar (beroenden) mellan komponenter.

Detta illustrerar klient-källa-relationen mellan de två komponenterna. Efter att ha läst avsnitten (Exempel, Applikation) kan du prova dig fram med att göra komponentdiagram själv. Det pågår en debatt i den objektorienterade gemenskapen om vad som är skillnaden mellan en komponent och en vanlig klass. I UML 1 fanns en separat symbol för komponenten (Figur 14.1). UML 2 har inte denna ikon, men du kan representera en klassrektangel med en liknande ikon.

I det här exemplet kan Till-komponenten kommunicera med Sales Server-komponenten med hjälp av försäljningsmeddelandegränssnittet. Kärnan i en komponent är föremål för oändliga kontroverser. Komponenter är inte teknik. Komponenter är mer en stil av kundrelationer med programvara. De vill att de nya komponenterna ska fungera på samma sätt som de gamla och uppdatera dem enligt deras planer, inte enligt tillverkarnas anvisningar.

Under designprocessen skapar en arkitekt eller en erfaren programmerare projektdokumentation, inklusive textbeskrivningar, diagram, modeller av det framtida programmet. UML är ett grafiskt språk för visualisering, parameterbeskrivning, konstruktion och dokumentation olika system(särskilt program).

Ett klassdiagram används för att representera den statiska strukturen hos en systemmodell i terminologin för klasser av objektorienterad programmering. Ur denna synvinkel är klassdiagrammet en vidareutveckling av den konceptuella modellen för det designade systemet. För att modellera interaktionen mellan objekt i UML-språket används lämpliga interaktionsdiagram.

I ett samarbetsdiagram avbildas objekt som deltar i interaktionen som rektanglar som innehåller objektets namn, dess klass och eventuellt attributvärden. Till skillnad från ett sekvensdiagram, skildrar ett samarbetsdiagram endast relationer mellan objekt som spelar specifika roller i en interaktion. I det här fallet visas bara komponenter-instanserna av programmet, som är körbara filer eller dynamiska bibliotek.

Detta diagram fullbordar faktiskt OOAP-processen för ett specifikt programvarusystem och dess utveckling är vanligtvis det sista steget i modellspecifikationen. Och flera speciella tekniker bidrar till detta (Scrum of scrums, komponentteam, deltagande av en arkitekt i rollen som produktägare). Detta är utvecklingen av ett riktigt system.

Och det är inget ovanligt eller fel i detta. Komponenter i mjukvarusystem, deras varianter. Alla diagram som diskuterats tidigare reflekterade de konceptuella och logiska aspekterna av att bygga en systemmodell. För att klargöra skillnaden mellan logiska och fysiska representationer är det nödvändigt att överväga i allmänna termer processen för att utveckla ett mjukvarusystem.

3.4.3. Tillämpa komponent- och placeringsdiagram

I det här fallet, redan i programmets text, antas organisationen av programkoden, bestäms av syntaxen för programmeringsspråket och antar uppdelningen av källkoden i separata moduler. Och detta är endast möjligt om systemets programkod implementeras i form av körbara moduler, bibliotek med klasser och procedurer, standardgrafiska gränssnitt, databasfiler.

Komponentdiagram och funktioner i dess konstruktion

För att representera fysiska enheter i UML-språket används en speciell term - en komponent. En komponent är en fysiskt existerande del av ett system som tillhandahåller implementering av klasser och relationer, såväl som det funktionella beteendet hos ett simulerat mjukvarusystem.

Dessutom kan en komponent ha en textstereotyp och taggade värden, och vissa komponenter kan ha sin egen grafiska representation. Komponent kan vara körbar kod en separat modul, kommandofiler eller filer som innehåller tolkade skript.

Systemanalytiker och arkitekter samt programmerare är involverade i utvecklingen av komponentdiagram. UML-komponenter och stereotyper. Distributionsdiagrammet är avsett att visualisera elementen och komponenterna i ett program som endast existerar i det skede då det körs (runtime). Du kan också bryta ner komponenter med hjälp av sammansatta strukturdiagram. Den här delenägnas åt två diagram samtidigt: komponenter och placering, för vilka du kan använda ett allmänt namn - implementeringsdiagram.

Alla diagram som övervägdes tidigare reflekterade de konceptuella aspekterna av att bygga en modell av systemet och var relaterade till den logiska presentationsnivån. Det speciella med den logiska representationen är att den arbetar med begrepp som inte har en självständig materiell gestaltning. Med andra ord, olika element i en logisk representation, såsom klasser, associationer, tillstånd, meddelanden, existerar inte materiellt eller fysiskt. De återspeglar bara vår förståelse av strukturen fysiska systemet eller aspekter av hennes beteende.

Huvudsyftet med den logiska synen är att analysera de strukturella och funktionella sambanden mellan elementen i systemmodellen. Men för att skapa ett specifikt fysiskt system är det nödvändigt att på något sätt implementera alla element i den logiska representationen i specifika materiella enheter. För att beskriva sådana verkliga enheter är en annan aspekt av modellrepresentationen avsedd, nämligen den fysiska representationen av modellen.

För att klargöra skillnaden mellan logiska och fysiska representationer, låt oss i allmänna termer överväga utvecklingsprocessen för något mjukvarusystem. Dess initiala logiska representation kan vara strukturella diagram algoritmer och procedurer, gränssnittsbeskrivningar och konceptuella databasscheman. Men för att implementera detta system är det nödvändigt att utveckla programmets källkod i något programmeringsspråk (C ++, Pascal, Basic / VBA, Java). I det här fallet, redan i programtexten, antas en sådan organisation av programkoden, vilket innebär dess uppdelning i separata moduler.

Ändå är programmets källkoder ännu inte det slutliga genomförandet av projektet, även om de fungerar som ett fragment av dess fysiska representation. Uppenbarligen kan ett mjukvarusystem anses implementerat i det fall det kommer att kunna utföra funktionerna för sitt avsedda syfte. Och detta är endast möjligt om systemets programkod implementeras i form av körbara moduler, bibliotek med klasser och procedurer, standardgrafiska gränssnitt, databasfiler. Det är dessa komponenter som är nödvändiga element i den fysiska representationen av systemet.

Således är den kompletta designen av ett mjukvarusystem en samling modeller av logiska och fysiska representationer som måste överensstämma med varandra. UML använder så kallade implementeringsdiagram för att fysiskt representera systemmodeller, som inkluderar två separata kanoniska diagram: ett komponentdiagram och ett distributionsdiagram. Funktioner i konstruktionen av den första av dem diskuteras i detta kapitel, och den andra - i nästa.

Komponentdiagrammet, i motsats till de tidigare betraktade diagrammen, beskriver egenskaperna hos den fysiska representationen av systemet. Komponentdiagrammet låter dig bestämma arkitekturen för systemet under utveckling genom att upprätta beroenden mellan programvarukomponenter, som kan vara källkod, binär och körbar kod. I många utvecklingsmiljöer motsvarar en modul eller komponent en fil. Prickade pilar som förbinder moduler visar ömsesidiga beroenden som liknar de som uppstår vid kompilering av källkod. De huvudsakliga grafiska elementen i ett komponentdiagram är komponenter, gränssnitt och deras beroenden.

Ett komponentdiagram är utformat för följande ändamål:

Visualisering av den allmänna strukturen för källkoden för mjukvarusystemet.
Specifikationer för den körbara versionen av mjukvarusystemet.
Säkerställa återanvändning av enskilda fragment av programkoden.
Konceptuella och fysiska databasschemavyer.

Systemanalytiker och arkitekter samt programmerare är involverade i utvecklingen av komponentdiagram. Ett komponentdiagram ger en konsekvent övergång från en logisk vy till en specifik implementering av ett projekt i form av programkod. Vissa komponenter kan existera endast vid kompileringsstadiet av programkoden, andra i skedet av dess exekvering. Ett komponentdiagram återspeglar de allmänna beroenden mellan komponenter, med tanke på de senare som klassificerare.

10.1. Komponenter

UML använder en speciell term för att representera fysiska enheter - en komponent. Komponenten implementerar en viss uppsättning gränssnitt och tjänar till allmän beteckning av elementen i den fysiska representationen av modellen. För att grafiskt representera en komponent kan du använda speciell karaktär- en rektangel med två mindre rektanglar insatta till vänster (Fig. 10.1). Inuti den omslutande rektangeln finns namnet på komponenten och eventuellt ytterligare information. Representationen av denna symbol kan variera något beroende på typen av information som är associerad med komponenten.

I UML-metamodellen är en komponent en ättling till en klassificerare. Det tillhandahåller en organisation inom ett fysiskt paket till dess tillhörande modellelement. Som klassificerare kan en komponent också ha sina egna egenskaper såsom attribut och operationer.

Ris. 10.1. Rita en komponent i UML

Så i det första fallet (fig. 10.1, a) är endast dess namn associerat med instansnivåkomponenten, och i det andra (fig. 10.1, b) - dessutom paketnamnet och det taggade värdet.

Komponentnamn

Komponentnamnet följer de allmänna reglerna för namngivning av modellelement i UML och kan bestå av valfritt antal bokstäver, siffror och några skiljetecken. En enskild komponent kan representeras på typnivå eller på instansnivå. Även om dess grafiska representation är densamma i båda fallen är reglerna för att skriva komponentnamnet något annorlunda. Om komponenten är representerad på typnivå skrivs endast typnamnet med stor bokstav som dess namn.

Om komponenten är representerad på instansnivå skrivs dess namn<имя компонента ":" имя типаХ При этом вся строка имени подчеркивается.

Som enkla namn är det vanligt att använda namnen på körbara filer (med tillägget exe efter separatorpunkten), namn på dynamiska bibliotek (extension dll), namn på webbsidor (extension html), namn på textfiler (extensions txt) eller doc) eller hjälpfiler (höft), namn på databasfiler (DB) eller filnamn med källkoder för program (tillägg h, cpp för C ++, Java-tillägg för Java), skript (pi, asp), etc.

Eftersom den specifika implementeringen av den logiska representationen av systemmodellen beror på de mjukvaruverktyg som används, kommer namnen på komponenterna också att bestämmas av särdragen hos syntaxen för motsvarande programmeringsspråk.

I vissa fall kan information om namnet på det bifogade paketet och den specifika versionen av implementeringen av denna komponent läggas till det enkla namnet på en komponent (fig. 10.1, b). Det bör noteras att i det här fallet skrivs versionsnumret som ett taggat värde i hängslen. I andra fall kan en komponentsymbol delas upp för att uttryckligen ange namnen på de gränssnitt den implementerar. Denna komponentbeteckning kallas avancerad och diskuteras senare i detta kapitel.

Komponenttyper

Eftersom en komponent som en del av den fysiska implementeringen av en modell är en separat kodmodul, kommenteras den ibland med ytterligare grafiska symboler som illustrerar specifika egenskaper hos dess implementering. Strängt taget är dessa ytterligare anteckningar inte specificerade i UML. Men deras användning gör det lättare att förstå komponentdiagrammet, vilket i hög grad ökar synligheten för den fysiska representationen. Några av dessa vanliga komponentkonventioner visas nedan (Figur 10.2).

Det finns tre typer av komponenter i UML.

Först utbyggnadskomponenterna, som säkerställer att systemet kan utföra sina funktioner direkt. Sådana komponenter kan vara dynamiska länkbibliotek med dll-tillägget (Figur 10.2, a), webbsidor i hypertextmarkeringsspråket med html-tillägget (Figur 10.2, b) och hjälpfiler med Yp-tillägget (Figur 10.2, c).
För det andra är komponenterna arbetsprodukter. Som regel är dessa filer med källkoder för program, till exempel med tilläggen h eller cp för språket C ++ (Fig. 10.2, d).
För det tredje, exekveringskomponenterna, som representerar körbara moduler - filer med exe-tillägget. De betecknas på vanligt sätt.

Ris. 10.2. Alternativ för att plotta komponenter i ett komponentdiagram

Dessa element kallas ibland artefakter, och betonar deras fullständiga informationsinnehåll, beroende på den specifika implementeringstekniken för motsvarande komponenter. Dessutom kan utvecklare använda sin egen notation för detta ändamål, eftersom UML inte har en strikt notation för den grafiska representationen av kommentarer.

Ett annat sätt att specificera olika typer av komponenter är att uttryckligen ange stereotypen för komponenten före dess namn. UML definierar följande stereotyper för komponenter:

Bibliotek (bibliotek) - definierar den första typen av komponent, som presenteras i form av ett dynamiskt eller statiskt bibliotek.
Tabell - definierar också den första typen av komponent, som presenteras i form av en databastabell.
Fil (fil) - definierar den andra typen av komponent, som presenteras i form av filer med källkoden för program.
Dokument - definierar den andra typen av komponent,. som presenteras i form av ett dokument.
Executable - definierar den tredje typen av komponent som kan köras i noden.

10.2. Gränssnitt

Nästa element i komponentdiagrammet är gränssnitt. De senare har redan övervägts flera gånger tidigare, så här kommer de funktioner att noteras som är karakteristiska för presentation på komponentdiagram. Kom ihåg att i det allmänna fallet är gränssnittet grafiskt avbildat av en cirkel, som är ansluten till komponenten med ett linjesegment utan pilar (Figur 10.3, a). I det här fallet skrivs namnet på gränssnittet, som nödvändigtvis måste börja med en stor bokstav "I", bredvid cirkeln. Semantiskt betyder en linje implementeringen av ett gränssnitt, och närvaron av gränssnitt i en komponent betyder att denna komponent implementerar motsvarande uppsättning gränssnitt.

Ris. 10.3. Rita gränssnitt i ett komponentdiagram

Ett annat sätt att representera ett gränssnitt på ett komponentdiagram är att representera det som en klassrektangel med stereotypen "gränssnitt" och möjliga delar av attribut och operationer (Figur 10.3, b). Vanligtvis används denna notation för att representera den interna strukturen för ett gränssnitt, vilket kan vara viktigt för implementeringen.

När man utvecklar mjukvarusystem ger gränssnitt inte bara kompatibiliteten för olika versioner, utan också möjligheten att göra betydande ändringar i vissa delar av programmet utan att ändra andra delar av det. Syftet med gränssnitten är alltså mycket bredare än specifikationen av interaktion med användarna av systemet (aktörer).

10.3. Beroenden

Generellt har även beroendeförhållandet diskuterats tidigare (se kapitel 5). Kom ihåg att ett beroende inte är en association, utan endast representerar det faktum att det finns ett sådant samband, när en förändring i ett element i modellen påverkar eller leder till en förändring i ett annat element i modellen. Ett beroendeförhållande i ett komponentdiagram representeras av en streckad linje med en pil som pekar från klienten (beroende) till källan (oberoende).

Beroenden kan återspegla kopplingarna mellan programmoduler vid kompileringsstadiet och genereringen av objektkod. Alternativt kan ett beroende återspegla förekomsten av klassdefinitioner i den oberoende komponenten, som används i den beroende komponenten för att skapa motsvarande objekt. När de tillämpas på ett komponentdiagram kan beroenden länka komponenter och gränssnitten som importeras av den komponenten, såväl som olika typer av komponenter sinsemellan.

I det första fallet dras en pil från klientkomponenten till det importerade gränssnittet (Figur 10.4). Närvaron av en sådan pil innebär att komponenten inte implementerar motsvarande gränssnitt, utan använder det under dess exekvering. Dessutom kan samma diagram innehålla en annan komponent som implementerar detta gränssnitt. Så till exempel ger fragmentet av komponentdiagrammet som visas nedan information om att komponenten med namnet "main.exe" beror på det importerade I Dialog-gränssnittet, som i sin tur implementeras av komponenten med namnet "image.java". För den andra komponenten exporteras samma gränssnitt.

Ris. 10.4. Fragment av ett komponentdiagram med ett beroendeförhållande

Observera att det är omöjligt att representera den andra komponenten som heter "image.java" i form av en variant av anteckningen just på grund av att denna komponent implementerar gränssnittet.

Ett annat fall av ett beroendeförhållande i ett komponentdiagram är förhållandet mellan olika typer av komponenter (Figur 10.5). Förekomsten av ett sådant beroende innebär att ändringar i källkoden för program eller dynamiska bibliotek leder till ändringar i själva komponenten. I det här fallet kan karaktären av ändringarna noteras ytterligare.

Ris. 10.5. Rita beroendeförhållandet mellan komponenter

Slutligen kan ett komponentdiagram representera beroendeförhållandena mellan komponenter och klasserna de implementerar. Denna information är viktig för att säkerställa att de logiska och fysiska representationerna av systemmodellen är konsekventa. Naturligtvis kan förändringar i strukturen för klassbeskrivningar leda till förändringar i komponenten. Nedan är ett fragment av ett beroende av detta slag, när en viss komponent beror på motsvarande klasser.

Ris. 10.6. Grafisk representation av beroendet mellan en komponent och klasser

Det bör noteras att det i detta fall inte följer av komponentdiagrammet att klasserna implementeras av denna komponent. Om du vill betona att någon komponent implementerar separata klasser, används den utökade rektangelsymbolen för att beteckna komponenten. I detta fall är komponentrektangeln uppdelad i två sektioner av en horisontell linje. Den övre delen används för att registrera namnet på komponenten och den nedre delen används för att indikera ytterligare information (Fig. 10.7).

Ris. 10.7. En grafisk representation av en komponent med ytterligare information om klasserna den implementerar

Andra element i grafisk notation som klasser (komponent på typnivå) eller objekt (komponent på instansnivå) kan avbildas inom en komponentsymbol. I det här fallet dras komponentsymbolen för att rymma dessa ytterligare symboler. Så till exempel är komponenten som visas nedan (Figur 10.8) en instans och implementerar tre separata objekt.

Ris. 10.8. En grafisk representation av en komponent på instansnivå som implementerar enskilda objekt

Objekt som finns i en separat instanskomponent visas som kapslade inom symbolen för den komponenten. Sådan kapsling innebär att exekveringen av komponenten medför exekveringen av motsvarande objekt. Med andra ord, förekomsten av en komponent under körningen av programmet säkerställer existensen, och möjligen åtkomst, av alla objekt kapslade i den. Tillgång till dessa objekt kan specificeras ytterligare med hjälp av synlighetskvantifierare, liknande paketets synlighet. Den meningsfulla innebörden av synlighet kan skilja sig åt för olika typer av paket.

Så för komponenter med programmets källkod kan synlighet innebära möjligheten att göra ändringar i motsvarande programtexter med deras efterföljande omkompilering. För komponenter med körbar programkod kan synlighet karakterisera förmågan att starta motsvarande komponent för exekvering eller anropa operationerna eller metoderna som implementeras i den.

Utvecklingen av ett komponentdiagram innebär användning av information både om den logiska representationen av systemmodellen och om funktionerna i dess fysiska implementering. Innan utvecklingen påbörjas är det nödvändigt att fatta beslut om val av datorplattformar och operativsystem som systemet ska implementeras på, samt om val av specifika databaser och programmeringsspråk.

Därefter kan du fortsätta med den allmänna struktureringen av komponentdiagrammet. Först och främst är det nödvändigt att bestämma vilka fysiska delar (filer) mjukvarusystemet ska bestå av. I detta skede bör uppmärksamhet ägnas åt en sådan implementering av systemet som inte bara skulle ge möjligheten att återanvända koden på grund av den rationella nedbrytningen av komponenter, utan också skapandet av objekt endast när de behövs.

Poängen är att den övergripande prestandan för ett mjukvarusystem i hög grad beror på dess rationella användning av datorresurser. För detta ändamål är det nödvändigt att överföra de flesta beskrivningarna av klasser, deras operationer och metoder till dynamiska bibliotek, och lämna kvar i de körbara komponenterna endast de fragment av programkoden som är mest nödvändiga för att initiera programmet.

Efter den allmänna struktureringen av den fysiska representationen av systemet är det nödvändigt att komplettera modellen med gränssnitt och databasscheman. Vid utveckling av gränssnitt bör uppmärksamhet ägnas åt koordinering (dockning) av olika delar av mjukvarusystemet. Införandet av ett databasschema i modellen förutsätter specificering av individuella tabeller och upprättande av informationsrelationer mellan tabellerna.

Slutligen är det sista steget av att bygga ett komponentdiagram relaterat till att etablera och plotta relationer mellan komponenter, såväl som implementeringsrelationer. Dessa relationer bör illustrera alla de viktigaste aspekterna av den fysiska implementeringen av systemet, från och med funktionerna för kompilering av källkoder för program och slutar med exekvering av enskilda delar av programmet i det skede av dess exekvering. För detta ändamål kan du använda olika typer av grafisk representation av komponenter.

När du designar ett komponentdiagram, följ de allmänna principerna för UML-modellering. I synnerhet är det första steget att använda de komponenter och stereotyper som redan finns tillgängliga i UML. För de flesta typiska projekt kan denna uppsättning element vara tillräcklig för att representera komponenterna och beroenden mellan dem.

Om projektet innehåller några fysiska element som inte beskrivs i UML, bör du använda förlängningsmekanismen. Använd i synnerhet ytterligare stereotyper för enskilda atypiska komponenter eller taggade värden för att förtydliga deras individuella egenskaper.

Sammanfattningsvis bör det noteras att ett komponentdiagram som regel utvecklas i samband med ett distributionsdiagram, som ger information om den fysiska placeringen av komponenterna i ett mjukvarusystem vid dess individuella noder. Funktionerna för att bygga ett distributionsdiagram kommer att diskuteras i nästa kapitel.

Anmärkningar:

Anmärkning 7

I exemplet ovan användes en av de accepterade notationerna i vissa programmeringsspråk (till exempel i Object Pascal) för att indikera att en metod tillhör en viss klass. I enlighet med denna notation specificeras först namnet på den klass i vilken metoden är definierad, och sedan, åtskilda av en punkt, namnet på själva metoden. Om en metod är definierad i någon underklass måste hela kedjan av klasser specificeras, börja med den mest allmänna. I det här fallet är ett karakteristiskt drag för en metod ett par parenteser, som används för att indikera en lista med argument eller formella parametrar för denna metod.

Not 72

När det gäller affärssystem bör mjukvarukomponenter förstås i en vidare mening för att kunna modellera affärsprocesser. I detta fall betraktas enskilda organisatoriska enheter (avdelningar, tjänster) eller dokument som faktiskt finns i systemet som komponenter.

Not 73

Komponentbilden härrör från beteckningen av en programmodul, som användes under en tid för att visa funktionerna för inkapsling av data och procedurer. Så den övre lilla rektangeln är konceptuellt associerad med data som denna komponent implementerar (tidigare avbildades den som en oval). Den nedersta lilla rektangeln är associerad med operationer eller metoder som implementeras av komponenten. I enkla fall skrevs namnen på data och metoder explicit i dessa små rektanglar, men de är inte specificerade i UML.

Not 74

Även om UML-namnkonventionerna kräver att namnen på enskilda instanser är understrukna, utelämnas understrecket ofta i litteraturen för komponenter. I det här fallet kommer att skriva komponentnamnet med en liten bokstav känneteckna komponenten på instansnivå.

Not 75

Användningen av gränssnitt av enskilda komponenter kan variera. Därför finns det två sätt att kommunicera mellan gränssnittet och komponenten. Om en komponent implementerar något gränssnitt, kallas ett sådant gränssnitt exportbart eftersom denna komponent tillhandahåller det som en tjänst till andra komponenter. Om en komponent använder något gränssnitt som är implementerat av en annan komponent, kallas ett sådant gränssnitt för den första komponenten importerat. Det speciella med det importerade gränssnittet är att i komponentdiagrammet är detta förhållande avbildat med hjälp av ett beroende.