UML-modell(UML-modell) är en uppsättning av en ändlig uppsättning språkkonstruktioner, vars huvudsakliga är entiteter och relationer mellan dem.
Entiteterna och relationerna i själva modellen är instanser av metamodellens metaklasser.
Med tanke på UML-modellen från de mest generella positionerna kan vi säga att det är en graf (mer exakt, en laddad multi-pseudo-hyper-digraph) där hörn och kanter är laddade ytterligare information och kan ha en komplex intern struktur. Topparna i denna graf kallas entiteter, och kanterna kallas relationer.. Resten av avsnittet innehåller ett flytande (preliminärt) men fullständig recension tillgängliga enhetstyper och relationer. Som tur är finns det inte så många av dem. I efterföljande kapitel av boken övervägs alla enheter och relationer igen, mer detaljerat och med exempel.
För att underlätta översikten kan enheter i UML delas in i fyra grupper:
Strukturella enheter, som du kanske kan gissa, är avsedda att beskriva strukturen. Typiskt inkluderar strukturella enheter följande.
Ett objekt(objekt) 1 är en entitet som har unikhet och inkapslar tillstånd och beteende.
Klass(klass) 2 - beskrivning av en uppsättning objekt med gemensamma attribut som definierar tillståndet och operationer som definierar beteende.
Gränssnitt(gränssnitt) 3 är en namngiven uppsättning operationer som definierar en uppsättning tjänster som kan begäras av konsumenten och tillhandahållas av tjänsteleverantören.
Samarbete(samarbete) 4 - en uppsättning objekt som interagerar för att uppnå något mål.
Skådespelare(aktör) 5 är en entitet som är utanför det modellerade systemet och direkt interagerar med det.
∇ Ett sådant förhållande finns säkert, vilket uttrycks i fig. Diagramtyphierarki för UML 1 som ett beroendeförhållande med "förfina" stereotypen.
∇∇ I UML 1 fanns en ofrivillig association mellan ett samverkansdiagram och en enhet med samma namn, vilket inte var helt sant och ibland missvisande.
∇∇∇ I UML 2 har den syntaktiska och semantiska belastningen av tillståndsdiagrammet förändrats så mycket att namnet inte längre speglar innehållet.
En lista över nya diagram och deras namn som antagits i denna bok ges nedan.
På fig. Diagramtyphierarki för UML 2 (del 1 och 2) ett klassdiagram som visar förhållandet mellan diagram i UML 2.
Senare i detta kapitel kommer vi att beskriva alla tretton kanoniska diagram mycket kortfattat för att få lite sammanhang och ordförråd för det som följer. Detaljer finns i de återstående kapitlen i boken.
Men innan vi går vidare till nästa avsnitt, låt oss göra en liten avvikelse om hur standarden kräver att diagram formateras. Den allmänna diagrampresentationsmallen ges nedan.
Det finns två huvudsakliga designelement: en yttre ram och en etikett med namnet på diagrammet. Om allt är enkelt med ramen - det är en rektangel som begränsar området där elementen i diagrammet ska vara placerade, skrivs namnet på diagrammet i ett speciellt format som visas i fig. Diagramnotation.
Denna komplexa flikform stöds inte av alla verktyg. Detta är dock inte nödvändigt, eftersom semantik är primär och notation är sekundär. I det följande använder vi en rektangel som diagrametikett genomgående, och detta bör inte orsaka missförstånd.
Möjliga taggar (typer) för diagram visas i följande tabell. Taggarna som erbjuds av standarden skrivs i den andra kolumnen. Men som praxis har visat är de regler som föreslagits av standarden inte alltid lämpliga och logiskt motiverade, därför innehåller tabellens tredje kolumn ett rimligt alternativ enligt vår mening.
Flik. Diagramtyper och taggar
| Diagramtitel | Tag (standard) | Tagg (föreslagen) |
|---|---|---|
| Användningsdiagram | användningsfall eller uc | användningsfall |
| klassdiagram | klass | klass |
| automatdiagram | statsmaskin eller stm | statsmaskin |
| aktivitetsdiagram | aktivitet eller spela teater | aktivitet |
| sekvensdiagram | samspel eller sd | sd |
| Kommunikationsdiagram | samspel eller sd | komm |
| Komponentdiagram | komponent eller cmp | komponent |
| Placeringsdiagram | odefinierat | spridning |
| Objektdiagram | odefinierat | objekt |
| Diagram över inre struktur | klass | klass eller komponent |
| Interaktionsöversiktsdiagram | samspel eller sd | samspel |
| Tidsdiagram | samspel eller sd | timing |
| Paketdiagram | paket eller pkg | paket |
UML är nu standardnotationen för visuell modellering av mjukvarusystem, antagen av Object Managing Group (OMG) hösten 1997 och stöds av många objektorienterade CASE-produkter.
UML-standarden erbjuder följande uppsättning diagram för modellering:
Användningsfallsdiagram (användningsfallsdiagram) - för att modellera en organisations eller företags affärsprocesser och bestämma kraven för det informationssystem som skapas;
klassdiagram (klassdiagram) - för att modellera systemklassernas statiska struktur och relationerna mellan dem;
systembeteendediagram (beteendediagram);
interaktionsdiagram;
Sekvensdiagram - för att modellera processen för meddelanden mellan objekt inom ett användningsfall;
samarbetsdiagram (samarbetsdiagram) - för att modellera processen för meddelanden mellan objekt inom samma användningsfall;
tillståndsdiagram - för att modellera beteendet hos systemobjekt under övergången från ett tillstånd till ett annat;
aktivitetsdiagram - för att modellera systemets beteende inom ramen för olika användningsfall, eller modelleringsaktiviteter;
implementeringsdiagram (implementeringsdiagram):
Komponentdiagram (komponentdiagram) - för modellering av hierarkin av komponenter (delsystem) i ett informationssystem;
deployment diagram (deployment diagram) - för modellering fysisk arkitektur designat informationssystem.
På fig. 1.1 presenterar en integrerad modell av informationssystemet, inklusive de huvuddiagram som ska utvecklas i detta kursprojekt.
Ris. 1. En integrerad modell av ett informationssystem i notationen av UML-språket
4.2. Använd falldiagram
Ett användningsfall är en sekvens av åtgärder som utförs av systemet som svar på en händelse utlöst av något externt objekt (aktör). Ett användningsfall beskriver en typisk interaktion mellan en användare och ett system. I det enklaste fallet bestäms användningsfallet i processen att diskutera med användaren de funktioner som han skulle vilja implementera i detta informationssystem. I UML är ett användningsfall avbildat enligt följande:
Fig.2. Användningsfall
En aktör är en roll som en användare spelar i förhållande till systemet. Skådespelare representerar roller, inte specifika personer eller jobbtitlar. Även om de är avbildade som stiliserade mänskliga figurer i use case-diagram, kan en skådespelare också vara extern. informationssystem, som behöver lite information från det givna systemet. Du bör bara visa skådespelare i ett diagram när de verkligen behöver några användningsfall. I UML representeras aktörer som former:
Fig.3. Karaktär (skådespelare)
Skådespelare är indelade i tre huvudtyper:
Användare
system;
Andra system som interagerar med detta;
Tiden blir en aktör om utlösandet av några händelser i systemet beror på det.
4.2.1. Relationer mellan användningsfall och skådespelare
I UML stöder use case-diagram flera typer av relationer mellan diagramelement:
Kommunikation (kommunikation),
Inkludering (inkludera),
förlängning (förlänga),
generalisering.
kommunikation kommunikationär förhållandet mellan användningsfallet och aktören. I UML visas kommunikationslänkar med en enkelriktad association (heldragen linje).
Fig.4. Exempel på kommunikationslänk
Inklusionskoppling används i situationer där det finns något systembeteende som upprepas i mer än ett användningsfall. Med hjälp av sådana länkar modelleras vanligtvis en återanvändbar funktion.
Förlängningsanslutning används för att beskriva förändringar i ett systems normala beteende. Det tillåter ett användningsfall att valfritt använda funktionalitet ett annat användningsfall.
Fig. 5. Ett exempel på en inkluderings- och förlängningsrelation
Kommunikationsgeneralisering indikerar att flera aktörer eller klasser har gemensamma egenskaper.
Fig. 6. Ett exempel på ett generaliseringssamband
4.3.
Interaktionsdiagram beskriva beteendet hos interagerande grupper av objekt. Vanligtvis täcker ett interaktionsdiagram endast beteendet hos objekt inom ett enda användningsfall. Ett sådant diagram visar ett antal objekt och de meddelanden som de utbyter med varandra.
meddelandeär det sätt på vilket avsändarobjektet begär att mottagarobjektet ska utföra en av dess operationer.
Informationsmeddelande (informativt).är ett meddelande som förser det mottagande objektet med viss information för att uppdatera dess tillstånd.
Begär meddelande (förhör)är ett meddelande som begär utmatning av viss information om mottagarobjektet.
Imperativt budskapär ett meddelande som ber mottagaren att utföra någon åtgärd.
Det finns två typer av interaktionsdiagram: sekvensdiagram och samarbetsdiagram.
4.3.1. Sekvensdiagram
sekvensdiagramåterspeglar flödet av händelser som inträffar inom ett enda användningsfall.
Alla aktörer (skådespelare, klasser eller objekt) som är involverade i ett givet scenario (användningsfall) visas överst i diagrammet. Pilar motsvarar meddelanden som skickas mellan en aktör och ett objekt, eller mellan objekt för att utföra de nödvändiga funktionerna.
I ett sekvensdiagram avbildas ett objekt som en rektangel, från vilken en prickad vertikal linje dras nedåt. Denna linje kallas ett föremåls livlina . Det är ett fragment av ett objekts livscykel i interaktionsprocessen.
Varje meddelande representeras som en pil mellan livlinorna för två objekt. Meddelanden visas i den ordning de visas på sidan uppifrån och ned. Varje meddelande är taggat med åtminstone meddelandenamnet. Alternativt kan du också lägga till argument och viss kontrollinformation. Du kan visa självdelegering, ett meddelande som ett objekt skickar till sig själv, med meddelandepilen som pekar mot samma livlina.
Ris. 7. Exempel på sekvensdiagram
4.3.2. Samarbetsdiagram
Samarbetsdiagram visa flödet av händelser inom ett specifikt scenario (användningsfall). Meddelanden ordnas efter tid, även om samarbetsdiagram fokuserar mer på relationer mellan objekt. Ett samverkansdiagram visar all information som ett sekvensdiagram har, men ett samverkansdiagram beskriver flödet av händelser på ett annat sätt. Utifrån det är det lättare att förstå sambanden som finns mellan objekt.
I ett samverkansdiagram, precis som i ett sekvensdiagram, representerar pilarna de meddelanden som utbyts inom ramverket. detta alternativ använda sig av. Deras tidssekvens indikeras genom numrering av meddelandena.
Ris. 8. Ett exempel på ett samarbetsdiagram
4.4. klassdiagram
4.4.1. Allmän information
klassdiagram definierar typerna av systemklasser och olika typer av statiska länkar som finns mellan dem. Klassdiagram visar också klassattribut, klassoperationer och begränsningar som är placerade på relationer mellan klasser.
Ett klassdiagram i UML är en graf vars noder är elementen i projektets statiska struktur (klasser, gränssnitt), och bågarna är relationerna mellan noderna (associationer, arv, beroenden).
Klassdiagrammet visar följande element:
· Paket (paket) - en uppsättning element i modellen, logiskt relaterade till varandra;
· Klass (klass) - beskrivning av gemensamma egenskaper för en grupp liknande objekt;
· Gränssnitt (gränssnitt) - en abstrakt klass som specificerar en uppsättning operationer som ett objekt av en godtycklig klass associerad med ett givet gränssnitt tillhandahåller andra objekt.
4.4.2. Klass
Klassär en grupp av enheter (objekt) som har liknande egenskaper, nämligen data och beteende. En enskild medlem av en klass kallas ett objekt i klassen, eller helt enkelt ett objekt.
Ett objekts beteende i UML hänvisar till alla regler för ett objekts interaktion med omvärlden och med själva objektets data.
I diagram är en klass avbildad som en rektangel med en hel ram, uppdelad med horisontella linjer i 3 sektioner:
Den översta delen (namnsektionen) innehåller namnet på klassen och andra allmänna egenskaper (särskilt stereotypen).
Mittsektionen innehåller en lista med attribut
Längst ner finns en lista över klassoperationer som återspeglar dess beteende (åtgärder som utförs av klassen).
Någon av attribut- och operationssektionerna kanske inte visas (eller båda). För den saknade sektionen behöver du inte rita en skiljelinje och på något sätt indikera närvaron eller frånvaron av element i den.
Ytterligare avsnitt, såsom undantag, kan införas efter en viss implementering.
Ris. 9. Exempel på klassdiagram
4.4.2.1.Klass stereotyper
Klassstereotyper är en mekanism för att klassificera klasser i kategorier.
UML definierar tre huvudklassstereotyper:
Gräns (gräns);
Entitet (enhet);
Kontroll (ledning).
4.4.2.2.Gränsklasser
Gränsklasser är de klasser som är belägna på gränsen mellan systemet och hela miljön. Dessa är displayer, rapporter, gränssnitt med hårdvara (som skrivare eller skannrar) och gränssnitt med andra system.
För att hitta gränsklasser måste du utforska användningsfallsdiagram. Varje interaktion mellan en aktör och ett användningsfall måste ha minst en gränsklass. Det är denna klass som gör att skådespelaren kan interagera med systemet.
4.4.2.3.Entitetsklasser
Entitetsklasser innehåller lagrad information. De har störst betydelse för användaren och därför använder deras namn ofta termer från ämnesområdet. Vanligtvis skapas en tabell i databasen för varje entitetsklass.
4.4.2.4.Kontrollklasser
Kontrollklasser ansvarar för att samordna andra klassers handlingar. Vanligtvis har varje användningsfall en kontrollklass som styr händelsesekvensen för det användningsfallet. Kontrollklassen ansvarar för koordineringen, men har ingen funktion i sig, eftersom de andra klasserna inte skickar den ett stort antal meddelanden. Istället skickar han själv en massa meddelanden. Chefsklassen delegerar helt enkelt ansvaret till andra klasser, varför den ofta kallas för chefsklassen.
Det kan finnas andra kontrollklasser i systemet som är gemensamma för flera användningsfall. Till exempel kan det finnas en SecurityManager-klass som ansvarar för att övervaka säkerhetsrelaterade händelser. Klassen TransactionManager hanterar koordineringen av meddelanden relaterade till databastransaktioner. Det kan finnas andra chefer för att hantera andra delar av systemets drift, såsom resursdelning, distribuerad databehandling eller felhantering.
Förutom stereotyperna som nämns ovan kan du skapa din egen.
4.4.2.5.Attribut
Ett attribut är en del information som är kopplad till en klass. Attribut lagrar inkapslade klassdata.
Eftersom attributen finns i klassen är de dolda från andra klasser. På grund av detta kan det vara nödvändigt att specificera vilka klasser som har rätt att läsa och ändra attribut. Den här egenskapen kallas attributsynlighet.
Attributet kan ha fyra möjliga värden för denna parameter:
Offentlig (allmän, öppen). Detta synlighetsvärde förutsätter att attributet kommer att vara synligt för alla andra klasser. Alla klasser kan visa eller ändra värdet på ett attribut. I enlighet med UML-notation föregås ett gemensamt attribut av ett "+"-tecken.
Privat (stängd, hemlig). Motsvarande attribut är inte synligt för någon annan klass. Ett privat attribut betecknas med ett "-"-tecken i enlighet med UML-notation.
Skyddad (skyddad). Ett sådant attribut är endast tillgängligt för klassen själv och dess avkomlingar. UML-notationen för ett skyddat attribut är tecknet "#".
Paket eller implementering (batch). Antag att det givna attributet är delat, men bara inom sitt paket. Denna typ av synlighet indikeras inte av någon speciell ikon.
Med hjälp av stängning eller säkerhet är det möjligt att undvika situationen när attributvärdet ändras av alla klasser i systemet. Istället kommer attributmodifieringslogiken att lindas in i samma klass som själva attributet. Synlighetsalternativen du ställer in kommer att påverka den genererade koden.
4.4.2.6.Operationer
Operationer implementerar klassrelaterat beteende. En operation har tre delar - ett namn, parametrar och en returtyp.
Parametrar är de argument som operationen får som indata. Returtypen hänvisar till resultatet av operationens åtgärd.
Ett klassdiagram kan visa både namn på operationer och namn på operationer tillsammans med deras parametrar och returtyp. För att minska belastningen på diagrammet är det användbart att bara visa namnen på operationer på några av dem och deras fullständiga signatur på andra.
I UML har operationer följande notation:
Operation Namn (argument: argument datatyp, argument2: argument2 datatyp,...): returtyp
Det finns fyra olika typer av operationer att överväga:
Implementeringsoperationer;
Ledningsverksamhet;
Åtkomstverksamhet;
Hjälpoperationer.
Implementeringsoperationer
Implementeringsverksamhet implementerar vissa affärsfunktioner. Sådana operationer kan hittas genom att undersöka interaktionsdiagram. Diagram av denna typ fokuserar på affärsfunktioner, och varje meddelande i diagrammet kan med största sannolikhet associeras med en implementeringsoperation.
Varje implementeringsoperation måste lätt kunna spåras till motsvarande krav. Detta uppnås i olika skeden av simuleringen. Operationen härleds från meddelandet i interaktionsdiagrammet, meddelandena kommer från den detaljerade beskrivningen av flödet av händelser, som genereras utifrån användningsfallet, och den senare utifrån kraven. Att kunna spåra hela den här kedjan hjälper till att säkerställa att varje krav implementeras i koden, och varje del av kod implementerar något krav.
Ledningsverksamhet
Manager operationer hanterar skapande och förstörelse av objekt. Klasskonstruktörer och destruktörer tillhör denna kategori.
Åtkomstverksamhet
Attribut är vanligtvis privata eller skyddade. Men andra klasser behöver ibland se eller ändra sina värden. Det finns åtkomstoperationer för detta. Detta tillvägagångssätt gör det möjligt att säkert kapsla in attribut inom en klass, skydda dem från andra klasser, men ändå låta dem vara kontrollerad åtkomst. Att skapa Get and Set-operationer (hämta och ändra ett värde) för varje attribut i en klass är en standard.
Hjälpoperationer
Auxiliary (hjälparoperationer) är de operationer av en klass som är nödvändiga för att den ska kunna fullgöra sitt ansvar, men som andra klasser inte bör veta något om. Dessa är privata och skyddade klassverksamheter.
Gör följande för att identifiera transaktioner:
1. Studera sekvensdiagram och kooperativa diagram. De flesta av meddelandena i dessa diagram är implementeringsoperationer. Reflekterande meddelanden kommer att vara hjälpoperationer.
2. Överväg kontrolloperationer. Du kan behöva lägga till konstruktörer och förstörare.
3. Överväg åtkomstoperationer. För varje klassattribut som andra klasser kommer att behöva arbeta med måste du skapa Get and Set-operationer.
4.4.2.7.Anslutningar
En relation är en semantisk relation mellan klasser. Det ger en klass möjlighet att lära sig om attribut, operationer och relationer för en annan klass. Med andra ord, för att en klass ska kunna skicka ett meddelande till en annan i en sekvens eller ett kooperativt diagram, måste det finnas en koppling mellan dem.
Det finns fyra typer av relationer som kan etableras mellan klasser: associationer, beroenden, aggregationer och generaliseringar.
Kommunikationsförening
En association är ett semantiskt förhållande mellan klasser. De är ritade på klassdiagrammet som en vanlig linje.
Ris. 10. Kommunikationsförening
Associationer kan vara dubbelriktade, som i exemplet, eller enkelriktade. I UML ritas dubbelriktade associationer som en enkel linje utan pilar, eller med pilar på båda sidor om linjen. En enkelriktad association har bara en pil som visar dess riktning.
Riktningen för en association kan bestämmas genom att undersöka sekvensdiagram och kooperativa diagram. Om alla meddelanden på dem skickas av endast en klass och endast tas emot av en annan klass, men inte vice versa, finns det en enkelriktad kommunikation mellan dessa klasser. Om minst ett meddelande sänds i motsatt riktning måste kopplingen vara dubbelriktad.
Associationer kan vara reflexiva. Reflexiv association innebär att en instans av en klass interagerar med andra instanser av samma klass.
Kommunikationsberoende
Beroenderelationer speglar också förhållandet mellan klasser, men de är alltid enkelriktade och visar att en klass beror på definitioner gjorda i en annan. Till exempel använder klass A metoder av klass B. Sedan, när klass B ändras, är det nödvändigt att göra motsvarande ändringar i klass A.
Ett beroende representeras av en prickad linje mellan två diagramelement, och elementet som är förankrat i slutet av en pil sägs vara beroende av elementet som är förankrat i början av den pilen.
Ris. 11. Kommunikationsberoende
Vid generering av kod för dessa klasser kommer inga nya attribut att läggas till dem. De språkspecifika operatörerna som behövs för att stödja kommunikation kommer dock att skapas.
Kommunikationsaggregation
Aggregeringar är en stramare associationsform. Aggregation är sambandet mellan helheten och dess del. Du kan till exempel ha en bilklass, samt motor-, däckklasser och klasser för andra bildelar. Som ett resultat kommer ett objekt av klass Bil att bestå av ett objekt av klass Engine, fyra objekt av Tyres, etc. Aggregeringar visualiseras som en linje med en romb för en klass som är ett heltal:
Ris. 11. Kommunikationsaggregation
Förutom enkel aggregation introducerar UML en starkare form av aggregation som kallas komposition. Enligt kompositionen kan en föremålsdel bara tillhöra en enda helhet, och dessutom sammanfaller i regel delars livscykel med helhetens cykel: de lever och dör med den. Varje borttagande av helheten sträcker sig till dess delar.
Denna kaskadradering anses ofta vara en del av definitionen av aggregering, men det är alltid underförstått när rollmångfalden är 1..1; till exempel, om en kund behöver raderas, måste den raderingen spridas till order (och i sin tur orderrader).
Jag tror att alla i barndomen hörde ett talesätt som " Sju gånger mäta klippa en gång". I programmering är det samma sak. Det är alltid bättre att tänka på implementeringen innan du lägger tid på att utföra den. Ofta måste du skapa klasser under implementeringen, uppfinna deras interaktion. Och ofta kan en visuell representation av detta hjälpa till att lösa problemet på det mest korrekta sättet. Det är här vi hjälper till UML.Om du tittar på bilderna i sökmotorer, det blir tydligt att UML– det här handlar om scheman, pilar och rutor. Det som är viktigt är att UML översätts som Unified Modeling Language. Ordet Unified är viktigt här. Det vill säga att våra bilder kommer att förstås inte bara av oss, utan också av andra som kan UML. Det visar sig att detta är ett så internationellt språk för att rita diagram.
Som Wikipedia säger
UML är ett grafiskt beskrivningsspråk för objektmodellering under utveckling programvara, affärsprocessmodellering, systemdesign och visning av organisationsstrukturer.Det mest intressanta som inte alla tänker på eller gissar om är att UML har specifikationer. Dessutom finns det till och med en UML2-specifikation. Mer information om specifikationen finns på Object Management Groups webbplats. Egentligen är denna grupp engagerad i utvecklingen av UML-specifikationer. Det är också intressant att UML inte begränsar sig till att beskriva klassernas struktur. Det finns många typer av UML-diagram. En kort beskrivning av typerna av UML-diagram kan ses i samma Wikipedia: UML-diagram eller i Timur Batyrshinovs video Översikt över UML-diagram. UML används också flitigt för att beskriva olika processer, till exempel här: Single sign-on med JWT. För att återgå till användningen av UML-klassdiagram är det värt att notera boken Head First: Design Patterns, där mönstren illustreras av samma UML-diagram. Det visar sig att UML verkligen används. Och det visar sig att det är en ganska användbar färdighet att känna till och förstå dess tillämpning.
Men vad händer om du vill rita själv, och även det inte finns någon Ultimate-version av Idea? Om vi använder IntelliJ Idea Community Edition har vi inget annat val. För att göra detta måste du förstå hur ett sådant UML-schema fungerar. Först måste vi installera Graphviz. Det är en uppsättning grafvisualiseringsverktyg. Det används av plugin som vi kommer att använda. Efter installationen måste du lägga till en katalog bin från den installerade katalogen graphviz till en miljövariabel VÄG. Efter det, i IntelliJ Idea, välj Arkiv -> Inställningar från menyn. I fönstret "Inställningar", välj kategorin "Plugins", klicka på knappen "Bläddra i arkiv" och installera PlantUML-integrationsplugin. Varför är den här så bra PlantUML? Han använder för UML-beskrivningar ett grafbeskrivningsspråk som heter " punkt" och detta gör att det kan vara mer universellt, eftersom detta språk används inte bara av PlantUML. Dessutom kan allt som vi kommer att göra nedan göras inte bara i IDE, utan också i planttext.com onlinetjänst. Efter installationen av PlantUML-plugin kommer vi att kunna skapa UML-diagram genom "Arkiv" -> "Ny". Låt oss skapa ett diagram av typen "UML-klass". Under detta genereras automatiskt en mall med ett exempel. Låt oss ta bort dess innehåll och skapa vår egen, beväpnad med en artikel från Habr: Klassrelationer - från UML till kod... Och för att förstå hur man skildra detta i texten, låt oss ta PlantUML-manualen: plantuml class-diagram... I den, vid i början finns det en skylt med hur man beskriver relationer:
Om själva sambanden kan vi fortfarande kika här: "Relationer mellan klasser i UML. Exempel". Baserat på dessa material, låt oss börja skapa vårt UML-diagram. Lägg till följande innehåll som beskriver de två klasserna: @startuml class ArrayList ( ) class LinkedList ( ) @enduml För att se resultatet i Idea, välj "Visa" -> "Verktygsfönster" -> "PlantUML". Vi får bara två rutor som anger klasser. Som vi vet implementerar båda dessa klasser List-gränssnittet. Denna relation mellan klasser kallas - implementering (förverkligande). En pil med en prickad linje används för att avbilda ett sådant förhållande. Låt oss rita det: gränssnitt List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о paket privat element array: ~ Objekt elementData Nu vill vi visa att ArrayList innehåller några objekt. I det här fallet det kommer att finnas en anslutningstyp - aggregering(aggregation). Aggregatet i det här fallet är ArrayList , eftersom den innehåller andra objekt. Vi väljer aggregering eftersom objekten i listan kan leva utan listan: de är inte integrerade delar av den. Deras livstid är inte bunden till listans livstid. Enheten från latin översätts med "samlad", det vill säga något som består av något. Till exempel i livet finns det en pumpenhet, som består av en pump och en motor. Själva enheten kan demonteras och lämnar kvar några av dess komponenter. Till exempel att sälja eller lägga in en annan enhet. Så den finns på listan. Och detta uttrycks i form av en tom romb vid enheten och en kontinuerlig linje. Låt oss uttrycka det så här: class Object ( ) ArrayList o- Object Nu vill vi visa att, till skillnad från ArrayList , innehåller klassen LinkedList Node - behållare som refererar till lagrad data. I det här fallet är noder en del av själva LinkedList och kan inte leva separat. Node är inte direkt lagrat innehåll, utan innehåller bara en referens till det. Till exempel, när vi lägger till en rad i den länkade listan, lägger vi till en ny nod som innehåller en länk till den raden, såväl som en länk till föregående och nästa nod . Denna typ av anslutning kallas sammansättning(sammansättning). För att visa en komposit (en som består av delar) dras en fylld robic, en kontinuerlig linje leder till den. Låt oss nu skriva detta som en textvisning av länken: class Node ( ) LinkedList * -- Node Och nu måste vi lära oss hur man visar en annan viktig typ av länk - missbruk(beroendeförhållande). Den används när en klass använder en annan, medan klassen inte innehåller den använda klassen och inte är dess efterföljare. Till exempel kan LinkedList och ArrayList skapa en ListIterator . Låt oss visa detta som prickade pilar: klass ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
Du kan detaljera så mycket du behöver. Alla beteckningar listas här: "PlantUML - Klassdiagram". Dessutom finns det inget övernaturligt i att rita ett sådant schema, och när du arbetar med dina uppgifter kan du snabbt rita det för hand. Detta kommer att utveckla färdigheterna att tänka igenom applikationsarkitekturen och hjälpa till att identifiera klassstrukturfel tidigt, och inte efter att du redan har tillbringat en dag med att implementera fel modell. Jag tror att det är en bra anledning att prova?)
Eftersom Maven inte är i fokus i den här artikeln kan svar på dina frågor om Maven hittas i Maven Users Center. I det genererade projektet öppnar du projektbeskrivningsfilen för redigering, pom.xml. Vi kommer att kopiera innehållet från beskrivningen av uml-java-docklet som installeras i den. Artefakten som användes i beskrivningen kunde inte hittas i Maven Central-förvaret. Men det fungerade för mig med detta: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . Det vill säga, i den beskrivningen behöver du bara byta ut grupp-ID Med " info.leadinglight"på" com.chfourie"och lägg version" 1.0.0 ". Efter det kan vi köra i katalogen där filen finns pom.xml dessa kommandon är: mvn clean install och mvn javadoc:javadoc . Om vi nu öppnar den genererade dokumentationen (explorer target\site\apidocs\index.html), kommer vi att se UML-diagram. Förresten, implementeringen visas redan korrekt här)
Alla UML-diagram kan villkorligt delas in i två grupper, varav den första är generella diagram. Generella diagram är praktiskt taget oberoende av ämnet för modellering och kan användas i alla programvaruprojekt utan hänsyn till ämnesområde, beslutsområde etc.
Användningsdiagram(use case diagram) är den mest allmänna representationen av systemets funktionella syfte.
Användningsdiagrammet är avsett att svara på huvudmodelleringsfrågan: vad gör systemet i omvärlden?
I användningsdiagrammet används två typer av huvudenheter: användningsfall 1 och aktörer 2, mellan vilka följande huvudtyper av relationer etableras:
Ett användningsdiagram, som alla andra, kan ha kommentarer 7 . Dessutom rekommenderas det starkt att göra detta för att förbättra läsbarheten för diagrammen.
Huvudelementen i notationen som används i användningsdiagrammet visas nedan. En detaljerad beskrivning ges i avsnitt 2.2.
klassdiagram(klassdiagram) är det huvudsakliga sättet att beskriva systemets struktur.
Detta är inte förvånande, eftersom UML främst är ett objektorienterat språk och klasser är den huvudsakliga (om inte den enda) byggstenen.
På klassdiagrammet används en huvudtyp av enheter: klasser 1 (inklusive många specialfall av klasser: gränssnitt, primitiva typer, associationsklasser och många andra), mellan vilka följande huvudtyper av relationer etableras:
Några delar av notationen som används i klassdiagrammet visas nedan. En detaljerad beskrivning ges i kapitel 3 .
automatdiagram(tillståndsmaskindiagram) är ett av sätten att beskriva beteende i detalj i UML baserat på den explicita tilldelningen av tillstånd och beskrivningen av övergångar mellan stater.
I huvudsak är automatdiagram, som namnet antyder, en tillståndsövergångsgraf (se kapitel 4), laddad med många ytterligare detaljer och detaljer.
I automatdiagrammet används en huvudtyp av entiteter - tillstånd 1 , och en typ av relationer - övergångar 2 , men för båda definieras många varianter, specialfall och ytterligare beteckningar. Att lista dem alla i en inledande recension är inte meningsfullt.
En detaljerad beskrivning av alla varianter av automatdiagram ges i avsnitt 4.2, och följande figur visar endast huvudelementen i notationen som används på automatdiagrammet.
aktivitetsdiagram(aktivitetsdiagram) - ett sätt att beskriva beteende baserat på indikeringen av kontrollflöden och dataflöden.
Ett aktivitetsdiagram är ett annat sätt att beskriva beteenden som visuellt liknar ett gammalt gott flödesschema. Men på grund av den moderniserade notationen, i överensstämmelse med det objektorienterade tillvägagångssättet, och viktigast av allt, på grund av den nya semantiska komponenten (fri tolkning av Petrinät), är UML-aktivitetsdiagrammet ett kraftfullt verktyg för att beskriva systemets beteende.
I aktivitetsdiagrammet används en huvudtyp av enheter - åtgärd 1 , och en typ av relation - övergångar 2 (överföringar av kontroll och data). Även sådana konstruktioner som gafflar, sammanslagningar, anslutningar, förgreningar 3 används, som liknar entiteter, men det är de egentligen inte, utan är ett grafiskt sätt att avbilda några speciella fall av relationer på många platser. Semantiken för aktivitetsdiagramelement diskuteras i detalj i kapitel 4. Huvudelementen i notationen som används i aktivitetsdiagrammet visas nedan.
sekvensdiagram(sekvensdiagram) är ett sätt att beskriva systemets beteende baserat på indikeringen av sekvensen av överförda meddelanden.
Faktum är att ett sekvensdiagram är en registrering av protokollet för en viss session i systemet (eller ett fragment av ett sådant protokoll). I objektorienterad programmering är det viktigaste vid körning att skicka meddelanden mellan samarbetande objekt. Det är sekvensen för att skicka meddelanden som visas på detta diagram, därav namnet.
I sekvensdiagrammet används en huvudtyp av enheter - instanser av interagerande klassificerare 1 (främst klasser, komponenter och skådespelare), och en typ av relationsförbindelser 2 , genom vilka meddelanden utbyts 3 . Det finns flera sätt att skicka meddelanden, som i grafisk notation skiljer sig åt i form av en pil som motsvarar en relation.
En viktig aspekt av sekvensdiagrammet är den explicita visningen av tidens gång. Till skillnad från andra typer av diagram, förutom kanske synkroniseringsdiagram, i ett sekvensdiagram, spelar inte bara närvaron av grafiska länkar mellan element betydelse, utan också den relativa positionen för element i diagrammet. Man anser nämligen att det finns en (osynlig) tidsaxel, som standard riktad uppifrån och ned, och meddelandet som skickas senare är ritat nedan.
Tidsaxeln kan riktas horisontellt, i vilket fall tiden anses flyta från vänster till höger.
Följande figur visar huvudelementen i notationen som används i ett sekvensdiagram. För att beteckna själva de interagerande objekten används standardnotationen - en rektangel med namnet på en klassificerareinstans. Den prickade linjen som kommer ut ur den kallas livlina (livlina) 4 . Detta är inte en beteckning på en relation i modellen, utan en grafisk kommentar avsedd att peka läsaren av diagrammet i rätt riktning. Figurer i form av smala remsor överlagrade på livslinjen är inte heller bilder av simulerade enheter. Detta är en grafisk kommentar som visar hur länge ett objekt äger en exekveringsförekomst 5 eller med andra ord en aktivering av ett objekt äger rum. Sammansatta interaktionssteg (kombinerat fragment) 6 tillåter sekvensdiagrammet att återspegla de algoritmiska aspekterna av interaktionsprotokollet. Se kapitel 4 för mer information om sekvensdiagramnotation.
Kommunikationsdiagram(kommunikationsdiagram) - ett sätt att beskriva beteende, semantiskt likvärdigt med ett sekvensdiagram.
I själva verket är detta samma beskrivning av meddelandeutbytessekvensen av interagerande instanser av klassificerare, endast uttryckt med andra grafiska medel. Dessutom kan de flesta verktyg automatiskt konvertera sekvensdiagram till kommunikationsdiagram och vice versa.
Såväl i kommunikationsdiagrammet som i sekvensdiagrammet används en huvudtyp av entiteter - instanser av interagerande klassificerare 1 och en typ av relation - anslutningar 2 . Här ligger dock inte tyngdpunkten på tid, utan på strukturen av relationer mellan specifika instanser.
Figuren visar huvudelementen i notationen som används i kommunikationsdiagrammet. För att beteckna själva de interagerande objekten används standardnotationen - en rektangel med namnet på en klassificerareinstans. Den ömsesidiga positionen för elementen på samarbetsdiagrammet spelar ingen roll - bara anslutningarna (oftast fall av föreningar) är viktiga, längs vilka meddelanden sänds 3 . För att visa ordningen på meddelanden i tid används hierarkisk decimalnumrering.
Komponentdiagram(komponentdiagram) - visar förhållandet mellan modulerna (logiska eller fysiska) som utgör det simulerade systemet.
Huvudtypen av enheter i komponentdiagrammet är själva komponenterna 1 , samt gränssnitt 2 , genom vilka förhållandet mellan komponenterna indikeras. Följande samband gäller i komponentdiagrammet:
Figuren visar huvudelementen i notationen som används i komponentdiagrammet. En detaljerad beskrivning ges i kapitel 3 .
Placeringsdiagram(distributionsdiagram), tillsammans med visning av systemelementens sammansättning och relationer, visar hur de fysiskt placeras på datorresurser under exekvering.
Sålunda, i placeringsdiagrammet, i jämförelse med komponentdiagrammet, läggs två typer av enheter till: artefakt 1, som är implementeringen av komponent 2 och nod 3 (kan vara antingen en klassificerare som beskriver nodtypen eller en specifik instans). såväl som ett associationsförhållande mellan noderna 4, vilket indikerar att noderna är fysiskt länkade vid körning.
Figuren visar huvudelementen i notationen som används i placeringsdiagrammet. För att visa att en entitet är en del av en annan används antingen en "deploy"-beroenderelation 5, eller så placeras formen av en entitet inuti formen av en annan entitet 6 . En detaljerad beskrivning av diagrammet ges i kapitel 3.
UML-diagram är ett specialiserat grafiskt beskrivningsspråk designat för objektmodellering vid utveckling av olika mjukvaror. Detta språk har en bred profil och är en öppen standard som använder olika grafiska notationer för att skapa en abstrakt modell av ett system. UML skapades för att möjliggöra definition, visualisering, dokumentation och design av alla typer av mjukvarusystem. Det är värt att notera att UML-diagrammet i sig inte är ett programmeringsspråk, men det ger möjlighet att generera en separat kod baserad på det.
Användningen av UML slutar inte med att modellera alla typer av mjukvara. Dessutom används detta språk aktivt idag för att modellera olika affärsprocesser, genomföra systemdesign och visa organisationsstrukturer.
Med hjälp av UML kan mjukvaruutvecklare säkerställa fullständig överenskommelse i grafiska symboler att presentera allmänna begrepp, såsom: komponent, generalisering, klass, beteende och aggregering. Detta uppnår en högre grad av koncentration på arkitektur och design.
Det är också värt att notera att det finns flera typer av sådana diagram.
Ett UML-klassdiagram är ett statiskt strukturdiagram utformat för att beskriva strukturen i ett system, samt visa attribut, metoder och beroenden mellan flera olika klasser.
Det är värt att notera det faktum att det finns flera synpunkter på konstruktionen av sådana diagram, beroende på hur de kommer att användas:
UML-komponentdiagrammet är ett helt statiskt strukturdiagram. Det är avsett att visa uppdelningen av en viss mjukvarusystem i olika strukturella komponenter, såväl som kopplingarna mellan dem. UML-komponentdiagram som sådant kan använda alla typer av modeller, bibliotek, filer, paket, körbara filer och många fler andra element.
UML-komposit/kompositstrukturdiagrammet är också ett statiskt strukturdiagram, men det används för att visa klassernas interna struktur. Om möjligt kan detta diagram också visa interaktionen mellan element som finns i klassens interna struktur.
En underart av dessa är UML-samarbetsdiagrammet, som används för att demonstrera olika klassers roller och interaktioner inom ramen för ett samarbete. De är ganska praktiska om du behöver modellera designmönster.
Det är värt att notera att UML-klassdiagram och sammansatta strukturdiagram kan användas samtidigt.
Detta diagram används för att modellera löpande noder, såväl som alla typer av artefakter som har distribuerats på dem. I UML 2 distribueras artefakter vid olika noder, medan i den första versionen endast komponenter distribuerades. Således används UML-distributionsdiagrammet främst för den andra versionen.
Ett manifestationsberoende bildas mellan en artefakt och den komponent som den implementerar.
Denna vy låter dig se en hel eller en del av bilden. skapat system vid en viss tidpunkt. Den visar helt och hållet alla instanser av klasserna i ett visst system, och indikerar de aktuella värdena för deras parametrar, såväl som relationerna mellan dem.
Detta diagram är strukturellt till sin natur, och dess huvudsakliga innehåll är alla typer av paket, såväl som relationerna mellan dem. I det här fallet finns det ingen strikt åtskillnad mellan flera strukturella diagram, vilket resulterar i att deras användning oftast används enbart för bekvämlighet och inte har någon semantisk betydelse. Det är värt att notera att olika element kan tillhandahålla andra UML-diagram (exempel: själva paket och paketdiagram).
Deras användning utförs för att säkerställa organiseringen av flera element i grupper enligt ett visst attribut, för att förenkla strukturen, samt för att organisera arbetet med modellen för detta system.
UML-aktivitetsdiagrammet visar uppdelningen av en viss aktivitet i flera komponentdelar. I det här fallet hänvisar begreppet "aktivitet" till specifikationen av ett visst körbart beteende i form av parallell, såväl som koordinerad sekventiell exekvering av olika underordnade element - kapslade typer av aktiviteter och olika åtgärder, förenade av flöden som går från utgångar från en viss nod till ingångarna från en annan.
UML-aktivitetsdiagrammet används ofta för att modellera olika affärsprocesser, parallell- och sekventiell beräkning. De modellerar bland annat alla typer av tekniska procedurer.
Denna syn kallas och något annorlunda - UML-tillståndsdiagrammet. Den har en presenterad tillståndsmaskin med enkla och sammansatta tillstånd, såväl som övergångar.
En finita tillståndsmaskin är en specifikation av en sekvens av olika tillstånd genom vilka ett visst objekt passerar, eller en interaktion som svar på vissa händelser i dess liv, såväl som ett objekts svar på sådana händelser. Tillståndsmaskinen som UML-tillståndsdiagrammet använder är tilldelad föräldraelement och används för att definiera beteendet för dess instanser.
Så kallade drakdiagram kan användas som analoger till sådana diagram.
UML Use Case Diagram visar alla relationer som uppstår mellan aktörerna, såväl som de olika användningsfallen. Dess huvudsakliga uppgift är att tillhandahålla ett fullfjädrat sätt genom vilket kunden, slutanvändaren eller någon utvecklare gemensamt kan diskutera beteendet och funktionaliteten hos ett visst system.
Om ett UML-användningsfallsdiagram används i en systemmodelleringsprocess kommer analytikern att:
Om ett användningsdiagram utvecklas i UML, börjar proceduren med en textbeskrivning, som erhålls när man arbetar med kunden. Samtidigt är det värt att notera det faktum att olika icke-funktionella krav helt utelämnas i processen med att sammanställa användningsfallsmodellen, och ett separat dokument kommer redan att bildas för dem.
Kommunikationsdiagrammet, precis som UML-sekvensdiagrammet, är transitivt, det vill säga det uttrycker interaktionen, men demonstrerar det samtidigt. olika sätt, och om det behövs, med den grad av noggrannhet som krävs, kan du konvertera den ena till den andra.
Kommunikationsdiagrammet återspeglar de interaktioner som sker mellan de olika delarna av den sammansatta strukturen, såväl som samverkans roller. Dess huvudsakliga skillnad från sekvensdiagrammet är att det tydligt indikerar förhållandet mellan flera element, och tiden används inte som en separat dimension.
Denna typ kännetecknas av ett helt fritt format att beställa flera objekt och relationer på samma sätt som det görs i ett objektdiagram. Om det finns ett behov av att behålla ordningen på meddelanden i detta fria format, numreras de kronologiskt. Läsningen av detta diagram börjar med det initiala meddelandet 1.0 och fortsätter sedan längs den riktning i vilken meddelanden skickas från ett objekt till ett annat.
För det mesta visar sådana diagram exakt samma information som ett sekvensdiagram ger oss, men eftersom det använder ett annat sätt att presentera information blir vissa saker i ett diagram mycket lättare att bestämma än i ett annat. Det är också värt att notera att ett kommunikationsdiagram tydligare visar vilka element varje enskilt element interagerar med, medan ett sekvensdiagram tydligare visar i vilken ordning interaktioner utförs.
UML-sekvensdiagrammet visar interaktionerna mellan flera objekt, som är ordnade efter tidpunkten för deras förekomst. Ett sådant diagram visar en tidsordnad interaktion mellan flera objekt. I synnerhet visar den alla objekt som deltar i interaktionen, såväl som den fullständiga sekvensen av meddelanden som utbyts av dem.
Huvudelementen i detta fall är beteckningarna på olika föremål, liksom vertikala linjer, som representerar tidens gång och rektanglar som representerar aktiviteten hos ett visst objekt eller utförandet av någon funktion av det.
Den här typen av diagram låter dig visa interaktionerna mellan flera objekt, abstrahera från sekvensen av meddelandeöversättning. Denna typ av diagram i kompakt form visar absolut alla sända och mottagna meddelanden för ett visst objekt, såväl som formaten för dessa meddelanden.
Eftersom sekvensdiagram och kommunikationsdiagram helt enkelt är olika vyer av samma procedurer, ger Rational Rose möjligheten att skapa ett kommunikationssekvensdiagram från ett sekvensdiagram eller vice versa, och synkroniserar dem också helt automatiskt.
Dessa är UML-diagram, som tillhör en typ av aktivitetsdiagram och inkluderar både sekvenselement och kontrollflödeskonstruktioner.
Det är värt att notera det faktum att givet format kombinerar Collaboration and Sequence diagram, som ger möjlighet att betrakta samspelet mellan flera objekt i systemet som formas ur olika synvinklar.
Representerar Alternativt alternativ sekvensdiagram, som explicit visar tillståndsändringen på livlinan med en viss tidsskala. Det kan vara ganska användbart i olika realtidsapplikationer.
Det är värt att notera flera fördelar som skiljer UML-användningsdiagrammet och andra:
Trots att konstruktionen av UML-diagram har många av sina fördelar, kritiseras de ofta för följande brister:
Användningen av detta språk är alltså inte relevant i alla situationer.
