Allmänna egenskaper hos UML-språket. UML-diagram. Typer av UML-diagram uml-lagerdiagram

UML är ett enhetligt grafiskt modelleringsspråk för att beskriva, visualisera, designa och dokumentera OO-system. UML är designat för att stödja processen för PS-modellering baserad på OO-metoden, för att organisera förhållandet mellan konceptuella och programkoncept och för att spegla problemen med att skala komplexa system. UML-modeller används i alla stadier av mjukvarans livscykel, från affärsanalys till systemunderhåll. Olika organisationer kan använda UML på sitt eget sätt, beroende på deras problemområden och vilken teknik som används.

En kort historia av UML

I mitten av 1990-talet föreslogs flera dussintals OO-modelleringsmetoder av olika författare, som var och en använde sin egen grafiska notation. Samtidigt hade någon av dessa metoder sina styrkor, men tillät inte att bygga en tillräckligt komplett PS-modell, för att visa den "från alla sidor", det vill säga alla nödvändiga projektioner (Se artikel 1). Dessutom gjorde avsaknaden av en OO-modelleringsstandard det svårt för utvecklare att välja den mest lämpliga metoden, vilket förhindrade den utbredda användningen av en OO-metod för mjukvaruutveckling.

På begäran av Object Management Group (OMG) - en organisation som ansvarar för att anta standarder inom området objektteknik och databaser, löstes det akuta problemet med enande och standardisering av författarna till de tre mest populära OO-metoderna - G. Booch , D. Rambo och A. Jacobson, som tillsammans skapade UML version 1.1, godkänd av OMG 1997 som standard.

UML är ett språk

Alla språk består av en ordbok och regler för att kombinera ord för att skapa meningsfulla konstruktioner. Så i synnerhet är programmeringsspråk ordnade, sådan är UML. Dess särdrag är att språkets vokabulär bildas av grafiska element. Varje grafisk symbol har specifik semantik, så en modell skapad av en utvecklare kan otvetydigt förstås av en annan, såväl som av ett verktyg som tolkar UML. Av detta följer i synnerhet att en PS-modell som presenteras i UML automatiskt kan översättas till ett OO-programmeringsspråk (som Java, C ++, VisualBasic), det vill säga med ett bra visuellt modelleringsverktyg som stöder UML, genom att bygger en modell kommer vi också att få en blank av programkoden som motsvarar denna modell.

Det bör betonas att UML är ett språk, inte en metod. Den förklarar vilka element man ska skapa modeller av och hur man läser dem, men säger ingenting om vilka modeller och i vilka fall som ska utvecklas. För att skapa en metod baserad på UML är det nödvändigt att komplettera den med en beskrivning av PS-utvecklingsprocessen. Ett exempel på en sådan process är Rational Unified Process, som kommer att diskuteras i senare artiklar.

UML-ordförråd

Modellen är representerad i form av entiteter och relationer mellan dem, vilka visas på diagram.

Essenserär abstraktioner som är huvudelementen i modeller. Det finns fyra typer av entiteter - strukturella (klass, gränssnitt, komponent, användningsfall, samarbete, nod), beteendemässiga (interaktion, tillstånd), gruppering (paket) och annoterande (kommentarer). Varje enhetstyp har sin egen grafiska representation. Entiteter kommer att diskuteras i detalj när man studerar diagram.

Relationer visa olika relationer mellan enheter. Följande typer av relationer definieras i UML:

  • Missbruk visar ett sådant förhållande mellan två enheter, när en förändring i en av dem - oberoende - kan påverka semantiken hos den andra - beroende. Ett beroende representeras av en prickad pil som pekar från den beroende enheten till den oberoende enheten.
  • Föreningär ett strukturellt samband som visar att objekt från en enhet är relaterade till objekt från en annan. Grafiskt visas en association som en linje som förbinder de relaterade enheterna. Associationer används för att navigera mellan objekt. Till exempel kan kopplingen mellan klasserna "Order" och "Produkt" användas för att hitta alla produkter som anges i en viss beställning - å ena sidan, eller för att hitta alla beställningar som innehåller denna produkt - å andra sidan. Det är tydligt att motsvarande program måste implementera en mekanism som tillhandahåller sådan navigering. Om navigering krävs i endast en riktning indikeras det med en pil i slutet av kopplingen. Ett specialfall av association är aggregering - ett förhållande av formen "hela" - "del". Grafiskt är det markerat med en romb i slutet nära entitetshelheten.
  • Generaliseringär en relation mellan en överordnad enhet och en underordnad enhet. I huvudsak återspeglar detta förhållande egenskapen arv för klasser och objekt. Generaliseringen visas som en linje som slutar med en triangel som pekar mot den överordnade enheten. Barnet ärver förälderns struktur (attribut) och beteende (metoder), men det kan samtidigt få nya strukturelement och nya metoder. UML tillåter multipelt arv när en enhet är relaterad till mer än en överordnad enhet.
  • Genomförande- förhållandet mellan den entitet som definierar specifikationen av beteende (gränssnitt) och den entitet som definierar implementeringen av detta beteende (klass, komponent). Detta förhållande används ofta i komponentmodellering och kommer att beskrivas mer i detalj i efterföljande artiklar.

Diagram. UML tillhandahåller följande diagram:

  • Diagram som beskriver systemets beteende:
    • Tillståndsdiagram (State diagram),
    • Aktivitetsdiagram,
    • Objektdiagram,
    • Sekvensdiagram,
    • Samarbetsdiagram;
  • Diagram som beskriver den fysiska implementeringen av systemet:
    • Komponentdiagram;
    • Implementeringsdiagram.

Modellkontrollvy. Paket.

Vi har redan sagt att för att en modell ska förstås väl av en person är det nödvändigt att organisera den hierarkiskt, vilket lämnar ett litet antal enheter på varje nivå i hierarkin. UML inkluderar ett sätt att organisera en hierarkisk representation av en modell - paket. Alla modeller består av en uppsättning paket som kan innehålla klasser, användningsfall och andra entiteter och diagram. Ett paket kan innehålla andra paket, vilket gör att du kan skapa hierarkier. UML tillhandahåller inga separata paketdiagram, men de kan förekomma i andra diagram. Paketet visas som en rektangel med en flik.

Vad UML ger.

  • hierarkisk beskrivning av ett komplext system genom att markera paket;
  • formalisering av funktionella krav för systemet med hjälp av apparaten för användningsfall;
  • specificera kraven för systemet genom att konstruera diagram över aktiviteter och scenarier;
  • val av dataklasser och konstruktion av en konceptuell datamodell i form av klassdiagram;
  • urval av klasser som beskriver användargränssnittet, och skapandet av ett skärmnavigeringsschema;
  • beskrivning av processerna för interaktion mellan objekt i utförandet av systemfunktioner;
  • beskrivning av objekts beteende i form av diagram över aktiviteter och tillstånd;
  • beskrivning av programvarukomponenter och deras interaktion genom gränssnitt;
  • beskrivning av systemets fysiska arkitektur.

Och den sista…

Trots all attraktivitet med UML skulle det vara svårt att använda det i riktig PS-modellering utan visuella modelleringsverktyg. Sådana verktyg låter dig snabbt presentera diagram på bildskärmen, dokumentera dem, generera tomma programkoder i olika OO-programmeringsspråk och skapa databasscheman. De flesta av dem inkluderar möjligheten att omarbeta programkoder - återställa vissa projektioner av PS-modellen genom att automatiskt analysera källkoderna för program, vilket är mycket viktigt för att säkerställa att modellen och koderna matchar och när man designar system som ärver funktionaliteten från föregångare. .

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.

Varför behövs hon?

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 full överensstämmelse i den grafiska notationen som används för att representera vanliga begrepp 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.

klassdiagram

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:

  • Konceptuell. I det här fallet beskriver UML-klassdiagrammet modellen för ett specifikt ämnesområde, och det tillhandahåller endast klasser av applikationsobjekt.
  • Specifik. Diagrammet används i processen för att designa olika informationssystem.
  • Genomförande. Klassdiagrammet innehåller alla typer av klasser som direkt används i programkoden.

Komponentdiagram

UML-komponentdiagrammet är ett helt statiskt strukturdiagram. Det är avsett att demonstrera uppdelningen av ett visst mjukvarusystem i olika strukturella komponenter, såväl som relationerna mellan dem. Ett UML-komponentdiagram kan använda alla typer av modeller, bibliotek, filer, paket, körbara filer och många andra element som sådana.

Sammansatt/komposit strukturdiagram

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.

Implementeringsdiagram

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.

Objektdiagram

Denna vy låter dig se en hel eller partiell ögonblicksbild av systemet som skapas 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.

Paketdiagram

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.

aktivitetsdiagram

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.

automatdiagram

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 kopplad till det ursprungliga elementet och används för att definiera beteendet hos dess instanser.

Så kallade drakdiagram kan användas som analoger till sådana diagram.

Använd falldiagram

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:

  • Separera tydligt systemet som modelleras från dess omgivning.
  • Identifiera aktörer, sätt att interagera med detta system, såväl som dess förväntade funktionalitet.
  • Ställ in i ordlistan som ämnesområde olika begrepp som relaterar till en detaljerad beskrivning av detta systems funktionalitet.

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.

Kommunikationer

Kommunikationsdiagrammet, precis som UML-sekvensdiagrammet, är transitivt, det vill säga det uttrycker interaktionen, men demonstrerar det samtidigt på olika sätt, och om nödvändigt, med erforderlig grad av noggrannhet, kan en omvandlas till en annan .

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.

sekvensdiagram

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 det här fallet är beteckningarna för olika objekt, såväl som vertikala linjer som visar tidens gång och rektanglar som representerar aktiviteten hos ett visst objekt eller utförandet av någon funktion av det.

Samarbetsdiagram

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.

Interaktionsöversiktsdiagram

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 detta format kombinerar Collaboration och Sequence diagram, vilket ger en möjlighet att överväga interaktionen mellan flera objekt i systemet som formas ur olika synvinklar.

Tidsdiagram

Representerar en alternativ version av sekvensdiagrammet, som explicit visar förändringen i tillståndet på livlinan med en viss tidsskala. Det kan vara ganska användbart i olika realtidsapplikationer.

Vad är fördelarna?

Det är värt att notera flera fördelar som skiljer UML-användningsdiagrammet och andra:

  • Språket är objektorienterat, vilket gör att teknikerna för att beskriva resultaten av analysen och designen som genomförs ligger semantiskt nära programmeringsmetoder i alla typer av objektorienterade språk av modern typ.
  • Med detta språk kan systemet beskrivas från nästan vilken synvinkel som helst, och olika aspekter av dess beteende beskrivs på samma sätt.
  • Alla diagram är relativt lätta att läsa även efter en relativt snabb bekantskap med dess syntax.
  • UML låter dig expandera, samt introducera dina egna grafik- och textstereotyper, vilket bidrar till dess användning inte bara inom mjukvaruutveckling.
  • Språket har blivit ganska utbrett, och är också ganska aktivt under utveckling.

Brister

Trots att konstruktionen av UML-diagram har många av sina fördelar, kritiseras de ofta för följande brister:

  • redundans. I de allra flesta fall säger kritiker att UML är för stort och komplext, och ofta är detta omotiverat. Den innehåller en hel del överflödiga eller nästan värdelösa konstruktioner och diagram, och oftast går sådan kritik till den andra versionen, och inte den första, eftersom det i nyare versioner finns fler "utskottsdesignade" kompromisser.
  • Olika felaktigheter i semantik. Eftersom UML definieras av en kombination av sig själv, engelska och OCL, saknar den styvheten som är inneboende i språk som är exakt definierade av formella beskrivningstekniker. I vissa situationer börjar den abstrakta syntaxen för OCL, UML och engelska att motsäga varandra, medan de i andra fall är ofullständiga. Den felaktiga beskrivningen av själva språket påverkar både användare och verktygsleverantörer, vilket så småningom leder till verktygsinkompatibiliteter på grund av det unika sättet olika specifikationer behandlas på.
  • Problem i processen för genomförande och studier. Alla ovanstående problem skapar vissa svårigheter i processen att implementera och lära sig UML, och detta gäller särskilt när ledningen tvingar ingenjörer att använda det när de saknar förkunskaper.
  • Koden återspeglar koden. En annan uppfattning är att det inte är vackra och attraktiva modeller som är viktiga, utan direkt fungerande system, det vill säga koden är projektet. Enligt denna uppfattning finns det ett behov av att utveckla ett mer effektivt sätt att skriva mjukvara. UML värderas i metoder som kompilerar modeller för att återskapa körbar kod eller källkod. Men i verkligheten kanske detta inte räcker, eftersom språket saknar Turing-fullständighetsegenskaper, och varje genererad kod kommer så småningom att begränsas av vad UML-tolkningsverktyget kan anta eller avgöra.
  • Belastningsfel överensstämmer. Denna term kommer från teorin om systemanalys för att bestämma oförmågan hos input från ett visst system att uppfatta resultatet från ett annat. Som med alla standardnotationer kan UML representera vissa system på ett mer effektivt och kortfattat sätt än andra. Således är utvecklaren mer benägen till de lösningar som är mer bekväma för att väva alla styrkorna hos UML, såväl som andra programmeringsspråk. Detta problem är mer uppenbart om utvecklingsspråket inte överensstämmer med huvudprinciperna för den objektorienterade ortodoxa doktrinen, det vill säga inte försöker arbeta i enlighet med principerna för OOP.
  • Försöker vara mångsidig. UML är ett generellt modelleringsspråk som försöker vara kompatibelt med alla bearbetningsspråk som för närvarande finns. I samband med ett visst projekt, för att designteamet ska uppnå det slutliga målet, är det nödvändigt att välja de tillämpliga funktionerna i detta språk. Dessutom går möjliga sätt att begränsa omfattningen av användningen av UML inom ett visst område genom en formalism som inte är helt formulerad, men som i sig är föremål för kritik.

Användningen av detta språk är alltså inte relevant i alla situationer.

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 affärsprocesserna för en organisation eller ett företag 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;

distributionsdiagram (deployment diagram) - för modellering av den fysiska arkitekturen för det designade informationssystemet.

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 avbildas som stiliserade mänskliga figurer i use case-diagram, kan en aktör också vara ett externt informationssystem som behöver lite information från 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 använda funktionaliteten i ett annat användningsfall när det behövs.

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örande)är ett meddelande som begär utmatning av viss information om mottagarobjektet.

Imperativt meddelandeä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 samarbetsdiagram, som i ett sekvensdiagram, representerar pilarna de meddelanden som utbyts inom ett givet användningsfall. 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 samordningen, men har ingen funktionalitet i sig, eftersom de andra klasserna inte skickar ett stort antal meddelanden till den. 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å tillåta kontrollerad åtkomst till dem. 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å relationen 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).

UML är en akronym för Unified Modeling Language. Faktum är att det är en av de mest populära teknikerna för affärsprocessmodellering och är en internationell standardnotation för att specificera, visualisera och dokumentera mjukvaruutveckling. Definierat av objekthanteringsgruppen, uppstod som ett resultat av flera ytterligare UML-notationssystem och har nu blivit de facto-standarden för visuell modellering. Grundprincipen för all objektorienterad programmering börjar med modellbyggande.

UML skapades ur kaoset kring mjukvaruutveckling och dokumentation. På 1990-talet fanns det flera olika sätt att representera mjukvarusystem. Det fanns ett behov av ett mer enhetligt visuellt UML-sätt att representera dessa system, och som ett resultat utvecklades det 1994-1996 av tre mjukvaruingenjörer som arbetade på Rational Software. Det antogs senare som en standard 1997 och har förblivit så till denna dag med endast ett fåtal uppdateringar.

I grund och botten är UML ett allmänt modelleringsspråk inom området mjukvaruutveckling. Den har dock nu hittat in i dokumentationen av flera affärsprocesser eller arbetsflöden, till exempel aktivitetsdiagram. UML-diagramtypen kan användas som ersättning för flödesscheman. De tillhandahåller både ett mer standardiserat sätt att modellera arbetsflöden och ett brett utbud av funktioner för att förbättra läsbarheten och effektiviteten.

Arkitekturen är baserad på ett metaobjekt, som definierar grunden för skapandet av UML-språket. Det är tillräckligt exakt för att skapa en hel applikation. En helt körbar UML kan distribueras på flera plattformar med hjälp av olika teknologier med alla processer under hela mjukvaruutvecklingscykeln.

UML är designat för användare att utveckla ett visuellt modelleringsspråk. Den stöder utvecklingskoncept på hög nivå som strukturer, mönster och samarbeten. UML är en samling element som:

  1. Programmeringsspråk uttalanden.
  2. Skådespelare beskriver den roll som användaren eller något annat system som interagerar med objektet spelar.
  3. Aktiviteter som ska utföras för genomförandet av arbetskontraktet och presenteras i diagram.
  4. En affärsprocess som inkluderar en uppsättning uppgifter som skapar en specifik tjänst för kunder, visualiserad av ett flödesschema med sekventiella åtgärder.
  5. Logik och återanvändbara mjukvarukomponenter.

UML-diagram delas in i två kategorier. Den första typen innehåller sju typer av diagram som representerar strukturell information, den andra - de återstående sju representerar allmänna typer av beteende. Dessa diagram används för att dokumentera systemarkitekturen och är direkt involverade i UML-modelleringen av systemet.

UML-diagram presenteras som statiska och dynamiska representationer av systemmodellen. Den statiska vyn inkluderar klass- och sammansatta strukturdiagram som betonar den statiska strukturen. Den dynamiska vyn representerar interaktionen mellan objekt och förändringar i objektens interna tillstånd med hjälp av sekvens-, aktivitets- och tillståndsdiagram.

Ett brett utbud av UML-modelleringsverktyg finns tillgängliga för att förenkla modellering, inklusive IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner och Dia.

Användningen av UML har olika former både i och i affärsprocesser:

  1. Skiss. I det här fallet används UML-diagram för att förmedla olika aspekter och egenskaper hos ett system. Detta är dock bara en översikt över systemet och kommer sannolikt inte att innehålla alla nödvändiga detaljer för att genomföra projektet till slutet.
  2. Forward Design - Skissdesign görs innan applikationen kodas. Detta görs för en bättre överblick över systemet eller arbetsflödet som användaren försöker skapa. Många designproblem eller brister kan identifieras, vilket kommer att förbättra projektets allmänna hälsa och välbefinnande.
  3. Omvänd design. När kod är skriven visas UML-diagram som en form av dokumentation för olika aktiviteter, roller, bidragsgivare och arbetsflöden.
  4. Plan. I det här fallet fungerar diagrammet som en komplett konstruktion som endast kräver den faktiska implementeringen av systemet eller programvaran. Detta görs ofta med hjälp av CASE-verktyg (Computer Aided Software Engineering Tools). Den största nackdelen med att använda CASE-verktyg är att de kräver en viss kunskapsnivå, användarutbildning samt ledning och personal.

UML är inte ett fristående programmeringsspråk som Java, C++ eller Python, men med rätt verktyg kan det förvandlas till ett UML-pseudoprogrammeringsspråk. För att uppnå detta mål måste hela systemet dokumenteras i olika diagram och med rätt programvara kan diagrammen direkt översättas till kod. Den här metoden kan bara vara användbar om tiden som ägnas åt att rita diagrammen tar mindre tid än att skriva den faktiska koden. Även om UML skapades för systemmodellering har det hittat flera användningsområden inom affärsområden.

Följande är ett exempel på ett UML-diagram för affärsmodellering.

En praktisk lösning skulle vara att visuellt representera processflödet för telefonförsäljning genom ett aktivitetsdiagram. Från det ögonblick då beställningen tas som en ingång, tills den tidpunkt då beställningen är slutförd och en specifik utgång ges.

Det finns flera typer av UML-diagram, och var och en av dem utför en annan uppgift, oavsett om den utvecklas före implementering eller efter, som en del av dokumentationen. De två bredaste kategorierna som täcker alla andra typer är beteendediagrammet och strukturdiagrammet. Som namnet antyder försöker vissa UML-diagram analysera och skildra strukturen hos ett system eller en process, medan andra beskriver systemets beteende, dess deltagare och komponenter.

De olika typerna är uppdelade enligt följande:

  1. Inte alla av de 14 olika typerna av UML-diagram används regelbundet vid dokumentation av system och arkitekturer.
  2. Pareto-principen gäller även vid användning av UML-diagram.
  3. 20 % av diagrammen används av utvecklare 80 % av tiden.

De mest använda elementen i mjukvaruutveckling är:

  • användningsdiagram;
  • klassdiagram;
  • sekvenser.

Aktivitetsdiagram - De viktigaste UML-diagrammen för att skapa affärsprocessmodeller. Inom mjukvaruutveckling används de för att beskriva flödet av olika aktiviteter. De kan vara antingen seriella eller parallella. De beskriver de föremål som används, konsumeras eller produceras av en aktivitet och förhållandet mellan olika aktiviteter.

Allt ovanstående är väsentligt för att modellera affärsprocesser som leder från en till en annan, eftersom de är sammankopplade med en tydlig början och slut. I en affärsmiljö kallas detta också för affärsprocess kartläggning. Huvudaktörerna är författaren, redaktören och förläggaren. Ett exempel på UML är följande. När en granskare granskar ett projekt och beslutar att vissa ändringar behöver göras. Författaren granskar sedan utkastet och returnerar det igen för att analysera recensionen.

Användningsdiagram

Systemets hörnsten - används för att analysera kraven på systemnivån. Dessa krav uttrycks i olika användningsfall. De tre huvudkomponenterna i ett UML-diagram är:

  1. Funktionell - presenteras som användningsfall.
  2. Ett verb som beskriver en handling.
  3. Skådespelare - att interagera med systemet. Aktörer kan vara användare, organisationer eller ett externt anspråk. Relationer mellan deltagare representeras av raka pilar.

Till exempel för lagerhanteringsdiagrammet. I det här fallet finns det en ägare, en leverantör, en chef, en lagerspecialist och en lagerinspektör. De runda behållarna representerar de handlingar som skådespelarna utför. Möjliga åtgärder: köpa och betala för aktier, kontrollera kvaliteten på aktier, returnera aktier eller distribuera aktier.

Den här typen av diagram är väl lämpade för att visa det dynamiska beteendet mellan deltagare i ett system, vilket gör det lättare att representera utan att visa implementeringsdetaljer.

Temporär

UML-tidsdiagram används för att representera objektrelationer när fokus är tidsberoende. I det här fallet är det inte intressant hur objekt interagerar eller förändrar varandra, utan användaren vill föreställa sig hur objekt och subjekt agerar längs en linjär tidsaxel.

Varje enskild deltagare representeras genom en livlina, som i huvudsak är en linje som bildar stadier när en enskild deltagare flyttar från ett stadium till ett annat. Den huvudsakliga uppmärksamheten ägnas åt varaktigheten av tidpunkten för händelser och de förändringar som sker beroende på den.

Huvudkomponenterna i ett tidsdiagram är:

  1. Lifeline är en individuell medlem.
  2. Statlig tidslinje - den enda livsvägen kan gå genom olika tillstånd inom en process.
  3. Varaktighetsbegränsning - en tidsintervallbegränsning som representerar varaktigheten av den begränsning som krävs för att uppfylla.
  4. Tidsgräns - Begränsar det tidsintervall under vilket något måste utföras av en deltagare.
  5. Destruction Emergence - Uppkomsten av ett meddelande som förstör en enskild medlem och skildrar slutet av den medlemmens livscykel.

Horisontella diagram, även kallade tillståndsdiagram, används för att beskriva de olika tillstånden för en komponent i ett system. Det tar det slutliga namnformatet eftersom diagrammet i huvudsak är en maskin som beskriver ett objekts flera tillstånd och hur det förändras baserat på interna och externa händelser.

Ett mycket enkelt maskintillståndsdiagram skulle vara i ett schackspel. Ett typiskt schackspel består av drag gjorda av vit och drag gjorda av svart. Vit har det första draget, vilket sätter igång spelet. Slutet av spelet kan ske oavsett om vit eller svart vinner. Spelet kan sluta med en match, avgång eller oavgjort (bilens olika tillstånd). Statskartor används främst i framåt och bakåt UML-design av olika system.

Sekventiell

Denna typ av diagram är det viktigaste UML-diagrammet, inte bara inom datavetenskap, utan också som modeller på designnivå för att utveckla affärsapplikationer. De är populära för att beskriva affärsprocesser på grund av deras visuellt självförklarande karaktär. Som namnet antyder beskriver diagram sekvensen av meddelanden och interaktioner som äger rum mellan subjekt och objekt. Skådespelare eller objekt kan bara vara aktiva när det är nödvändigt eller när ett annat objekt vill kommunicera med dem. All kommunikation presenteras i kronologisk ordning.

För mer information, se exempel på UML-sekvensdiagram nedan.

Som följer av exemplet används strukturdiagram för att visa strukturen i ett system. Mer specifikt används språk i mjukvaruutveckling för att representera arkitekturen i ett system och hur olika komponenter är relaterade.

Klassdiagrammet UML är den vanligaste typen av diagram för programvarudokumentation. Eftersom det mesta av programvaran som skapas idag fortfarande är baserad på det objektorienterade programmeringsparadigmet, är det sunt förnuft att använda klassdiagram för att dokumentera programvara. Detta beror på att OOP baseras på UML-klasser och relationerna mellan dem. I ett nötskal innehåller diagram klasser, tillsammans med deras attribut, även kallade datafält, och deras beteenden, kallade medlemsfunktioner.

Mer specifikt har varje klass 3 fält: namn överst, attribut precis under namnet, operationer/beteende längst ner. Relationen mellan olika klasser (representerad av en förbindelselinje) utgör ett klassdiagram. Exemplet ovan visar ett grundläggande klassdiagram.

Objekt

När du diskuterar UML-strukturdiagram behöver du fördjupa dig i begrepp relaterade till datavetenskap. I programvaruteknik betraktas klasser som abstrakta datatyper medan objekt är instanser. Om det till exempel finns "Car" som är en generisk abstrakt typ, så skulle instansen av klassen "Car" vara "Audi".

UML-objektdiagram hjälper mjukvaruutvecklare att kontrollera om den genererade abstrakta strukturen är en genomförbar struktur när den implementeras i praktiken, det vill säga när objekt skapas. Vissa utvecklare anser att detta är en sekundär nivå av noggrannhetskontroll. Den visar klassinstanser. Närmare bestämt har den generiska klassen "Client" nu en faktisk klient, till exempel med namnet "James". James är en instans av en mer allmän klass och har samma attribut, dock med givna värden. Detsamma gjordes med Konton och Sparkontot. De är båda föremål för sina respektive klasser.

Utplaceringar

Implementeringsdiagram används för att visualisera förhållandet mellan mjukvara och hårdvara. För att vara mer specifik, med distributionsdiagram är det möjligt att bygga en fysisk modell av hur mjukvarukomponenter (artefakter) distribueras till hårdvarukomponenter som kallas noder.

Ett typiskt förenklat distributionsschema för en webbapplikation skulle inkludera:

  1. Noder (applikationsserver och databasserver).
  2. Artefaktdiagram över klientapplikationen och databasen.

Paketdiagrammet liknar makron för UML-diagram för distribution som vi förklarade ovan. Olika paket innehåller noder och artefakter. De grupperar diagram och modellerar komponenter i grupper, ungefär som ett namnutrymme kapslar in olika namn som är något relaterade. I slutändan kan paketet också skapas av flera andra paket för att representera mer komplexa system och beteenden.

Huvudsyftet med ett paketdiagram är att visa sambanden mellan de olika stora komponenterna som utgör ett komplext system. Programmerare tycker att denna abstraktion är en bra fördel för att använda paketdiagram, särskilt när vissa detaljer kan lämnas utanför bilden.

Som alla andra saker i livet, för att göra något rätt, behöver du rätt verktyg. För att dokumentera programvara, processer eller system, använd verktyg som erbjuder UML-kommentarer och diagrammallar. Det finns olika som kan hjälpa till att rita diagrammet.

De faller vanligtvis i följande huvudkategorier:

  1. Papper och penna är lätt. Ta tag i papper och penna, öppna UML-syntaxkod från webben och rita vilken typ av diagram du vill.
  2. Onlineverktyg – Det finns flera onlineapplikationer som kan användas för att skapa ett diagram. De flesta av dem erbjuder en betald prenumeration eller ett begränsat antal diagram i den kostnadsfria nivån.
  3. Gratis onlineverktyg är nästan samma som betalda. Den största skillnaden är att betalda också erbjuder handledning och färdiga mallar för specifika diagram.
  4. Skrivbordsapplikation - Den typiska skrivbordsapplikationen att använda för diagram och nästan alla andra diagram är Microsoft Visio. Den erbjuder avancerade funktioner och funktionalitet. Enda nackdelen är att du måste betala för det.

Således är det tydligt att UML är en viktig aspekt i samband med utvecklingen av objektorienterad programvara. Den använder grafisk notation för att skapa visuella modeller av systemprogram.

UML eller Unified Modeling Language är ett grafiskt beskrivningsspråk för objektmodellering inom området mjukvaruutveckling. Men användningen av UML är inte begränsad till IT, ett annat stort område för praktisk tillämpning av UML är affärsprocessmodellering, systemdesign och kartläggning av organisationsstrukturer. UML gör det möjligt för mjukvaruutvecklare att komma överens om grafiska konventioner för att representera vanliga koncept och koncentrera sig på design och utveckling.

Fördelar med UML

  • UML använder grafiska symboler för elementen i systemet som modelleras, och UML-diagrammen är ganska lätta att förstå;
  • UML gör det möjligt att beskriva system från nästan alla möjliga synvinklar, med hänsyn till olika aspekter;
  • UML är objektorienterat: dess metoder för analys och konstruktion ligger semantiskt nära de programmeringsmetoder som används i moderna OOP-språk;
  • UML är en öppen standard. Standarden utvecklas och utvecklas från version till version och uppfyller de modernaste kraven för att beskriva system;
  • innehåller en förlängningsmekanism som låter dig introducera ytterligare text- och grafiktyper, vilket gör det möjligt att använda UML inte bara inom IT-området.

Typer av UML-diagram

Det finns 14 diagramtyper i UML. De kan delas in i 2 kategorier:

  • strukturell, representerar informationsstrukturen;
  • beteendemässiga, som representerar systemets beteende och olika aspekter av interaktioner. En separat underart av beteendediagram är interaktionsdiagram.

Hierarki av UML-diagramtyper, representeras av ett klassdiagram

Strukturdiagram

  1. klassdiagramär ett nyckelelement i objektorienterad modellering. Med hjälp av detta diagram (faktiskt genom klasser, dem attribut, metoder och beroenden mellan klasser) beskriver domänmodellen och strukturen för det modellerade systemet.
  2. Komponentdiagram visar uppdelningen av programkoden i stora block (strukturkomponenter) och visar beroenden mellan dem. Komponenter kan vara paket, moduler, bibliotek, filer etc.
  3. objektdiagram visar en hel eller partiell skärning av det simulerade systemet vid en given tidpunkt. Det representerar instanser av klasser (objekt), deras tillstånd (aktuella attributvärden) och relationer mellan dem.
  4. Sammansatt strukturdiagram demonstrerar klassernas interna struktur och, om möjligt, interaktionerna mellan elementen i denna struktur.
  5. Paketdiagram visar paketen och relationerna mellan dem. Denna typ av diagram tjänar till att förenkla modellens struktur (och följaktligen arbeta med den) genom att kombinera modellelement i grupper enligt vissa kriterier.
  6. Implementeringsdiagram modellerar distributionen av programvarukomponenter ( artefakter) på datorresurser/hårdvarukomponenter ( knutpunkter).
  7. Profildiagram beskriver en utvidgningsmekanism som gör att UML kan anpassas till en mängd olika ämnesområden och verksamhetsområden.

Exempel på UML-klassdiagram

Beteendediagram

  1. aktivitetsdiagram visar åtgärder ( åtgärder) varav viss aktivitet ( aktivitet). Aktivitetsdiagram används för att modellera affärsprocesser, tekniska processer, seriell och parallell beräkning.
  2. Använd falldiagram(eller diagram för användningsfall) beskriver förhållandet mellan aktörer (aktörer) och användningsfall för det simulerade systemet (dess kapacitet). Huvudsyftet med diagrammet är att vara ett universellt verktyg för kunder, utvecklare och slutanvändare, med hjälp av vilket det skulle vara möjligt att gemensamt diskutera systemet - dess möjligheter och beteende.
  3. Tillståndsdiagram skildrar det dynamiska beteendet hos en entitet, och visar hur denna entitet, beroende på dess nuvarande tillstånd, reagerar på olika händelser. I själva verket är detta ett tillståndsdiagram från teorin om atomer.
  4. Kommunikationsdiagram(i tidigare versioner samarbetsdiagram) visar interaktionerna mellan delarna av den sammansatta strukturen och rollerna för samarbetet. Diagrammet anger uttryckligen förhållandet mellan element (objekt).
  5. sekvensdiagram används för att visualisera sekvensen av objektinteraktioner. Visar livscykeln för ett givet objekt och interaktionen mellan aktörer (aktörer) inom ett användningsfall, sekvensen av meddelanden som de utbyter.
  6. Interaktionsöversiktsdiagram inkluderar en del av sekvensdiagrammet och kontrollflödeskonstruktionen. Hjälper till att överväga interaktionen mellan objekt ur olika synvinklar.
  7. Tidsdiagram- en separat underart av interaktionsdiagram, specialiserad på timing. Diagram av denna typ används för att studera objekts beteende under en viss tidsperiod.