UML-diagram. Typer av UML-diagram. Allmänna egenskaper hos UML-språket Ett exempel på diagram i UML-språket

UML (Unified Modeling Language - unified modeling language) - ett grafiskt beskrivningsspråk för objektmodellering inom området mjukvaruutveckling. UML är ett allmänt språk, det är en öppen standard som använder grafisk notation för att skapa en abstrakt modell av ett system, en så kallad UML-modell. UML skapades för att definiera, visualisera, designa och dokumentera mestadels mjukvarusystem. UML är inte ett programmeringsspråk, men kodgenerering är möjlig i runtime-verktygen för UML-modeller som tolkad kod. Wikipedia

Kommersiella produkter

Microsoft Visio

Typ: kommersiell programvara

En populär mjukvaruprodukt från Microsoft som låter dig rita rika diagram, inklusive UML:

Från och med 2010 års version blev det möjligt att publicera diagram på webben (SharePoint + Visio Services):

Visio Viewer- ett gratis program som låter dig se tidigare skapade Visio-diagram. Du kan ladda ner på %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modellering,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sekvens%20Diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Användning%20fodral%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualisering%20och%20Modellering%20Funktion%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A
  • %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
    • %0A
  • %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20lager%20diagram%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
    • %0A
  • %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20lager%20diagram
    • %0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualisering%20och%20Modellering%20Funktion%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/en-us/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Förmågor:

  • Användningsfallsdiagram (diagram över prejudikat);
  • Implementeringsdiagram (topologidiagram);
  • Tillståndsdiagram (tillståndsdiagram);
  • Aktivitetsdiagram (aktivitetsdiagram);
  • Interaktionsdiagram (interaktionsdiagram);
  • Sekvensdiagram (diagram över sekvenser av åtgärder);
  • Samarbetsdiagram (samarbetsdiagram);
  • Klassdiagram (klassdiagram);
  • Komponentdiagram (komponentdiagram).

Skärmdumpar:

öppen källkod

StarUML

Förmågor:

  • UML 2.0-stöd
  • MDA (Model Driven Architecture)
  • Plugin-arkitektur (du kan skriva på COM-kompatibla språk: C++, Delphi, C#, VB, ...)

StarUML skrivs huvudsakligen i Delphi, men komponenter kan även läggas till på andra språk, såsom C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Nedan finns några skärmdumpar.

Klassdiagram:

Diagram för användningsfall:

ArgoUML

Diagram som stöds:

  • klass
  • stat
  • användningsfall
  • Aktivitet
  • Samarbete
  • Spridning
  • Sekvens

Förmågor:

  • Stöd för nio UML 1.4-diagram
  • Plattformsoberoende (Java 5+)
  • UML 1.4 Standard Metamodell
  • XMI-stöd
  • Exportera till GIF, PNG, PS, EPS, PGML och SVG
  • Språk: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
  • OCL-stöd
  • Forward, Reverse Engineering

Skärmdump:

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 återspegla 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 representeras 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 hos föregångare. .

Anteckning: Ämnet för denna kurs är The UML - Unified Modeling Language. I förra föreläsningen pratade vi om vad UML är, om dess historia, syfte, sätt att använda språket, dess definitionsstruktur, terminologi och notation. Det har noterats att en UML-modell är en uppsättning diagram. I den här föreläsningen kommer vi att överväga sådana frågor: varför vi behöver flera typer av diagram; typer av diagram; OOP och sekvensdiagram

Innan vi går vidare till att diskutera det huvudsakliga materialet i denna föreläsning, låt oss prata om varför man bygger några diagram överhuvudtaget. Utvecklingen av en modell av vilket system som helst (inte bara programvara) föregår alltid skapandet eller uppdateringen. Detta är nödvändigt åtminstone för att tydligare föreställa sig att problemet löses. Genomtänkta modeller är mycket viktiga både för interaktion inom utvecklingsteamet och för ömsesidig förståelse med kunden. Det låter dig trots allt se till att projektet är "arkitektoniskt konsekvent" innan det implementeras i kod.

Vi bygger modeller av komplexa system eftersom vi inte kan beskriva dem helt, "ta en titt på dem på ett ögonkast". Därför pekar vi bara ut de egenskaper hos systemet som är väsentliga för en viss uppgift och bygger dess modell som speglar dessa egenskaper. Metoden för objektorienterad analys gör det möjligt att beskriva verkliga komplexa system på det mest adekvata sättet. Men i takt med att systemen blir mer komplexa finns det ett behov av bra simuleringsteknik. Som vi sa i föregående föreläsning används ett enhetligt system som en sådan "standard"-teknik. modelleringsspråk(Unified Modeling Language, UML), som är ett grafiskt språk för specifikation, visualisering, design och dokumentation av system. Med UML kan du utveckla en detaljerad modell av systemet som skapas, som inte bara speglar dess koncept utan också specifika implementeringsfunktioner. Inom ramen för UML-modellen är alla representationer om systemet fixerade i form av speciella grafiska strukturer som kallas diagram.

Notera. Vi kommer inte att överväga alla, utan bara några av typerna av diagram. Exempelvis behandlas inte komponentdiagrammet i denna föreläsning, som endast är en kort översikt över diagramtyper. Antalet diagramtyper för en viss applikationsmodell är inte begränsat på något sätt. För enkla applikationer finns det inget behov av att bygga diagram av alla typer utan undantag. Vissa av dem kan helt enkelt saknas, och detta faktum kommer inte att betraktas som ett fel. Det är viktigt att förstå att tillgängligheten av diagram av en viss typ beror på detaljerna i ett visst projekt. Information om andra (ej diskuterade här) typer av diagram finns i UML-standarden.

Varför du behöver flera typer av diagram

Låt oss först definiera terminologi. I förordet till denna föreläsning använde vi upprepade gånger begreppen system, modell och diagram. Författaren är säker på att var och en av oss intuitivt förstår innebörden av dessa begrepp, men för att vara helt tydlig, låt oss titta på ordlistan igen och läsa följande:

Systemet- En uppsättning sammankopplade kontrollerade delsystem förenade av ett gemensamt mål att fungera.

Ja, inte särskilt informativt. Vad är då ett delsystem? För att klargöra situationen, låt oss vända oss till klassikerna:

systemet kalla en uppsättning delsystem organiserade för att uppnå ett specifikt mål och beskrivna med hjälp av en uppsättning modeller, möjligen från olika synvinklar.

Tja, det finns inget du kan göra, du måste leta efter definitionen av ett delsystem. Där står det också delsystemär en uppsättning element, av vilka några specificerar beteendet hos andra element. Ian Sommerville förklarar konceptet så här:

Delsystemär ett system vars funktion inte är beroende av andra delsystems tjänster. Mjukvarusystemet är uppbyggt som en uppsättning relativt oberoende delsystem. Interaktioner mellan delsystem definieras också.

Inte heller särskilt tydligt, men bättre. På ett "mänskligt" språk representeras systemet som en uppsättning enklare enheter som är relativt självförsörjande. Detta kan jämföras med hur vi i processen att utveckla ett program bygger ett grafiskt gränssnitt av vanliga "kuber" - visuella komponenter, eller hur själva programtexten också är uppdelad i moduler som innehåller subrutiner som kombineras enligt en funktionell funktion, och de kan återanvändas, i följande program.

Förstå konceptet med ett system. Under designprocessen beaktas systemet ur olika synvinklar med hjälp av modeller, vars olika representationer framträder i form av diagram. Återigen kan läsaren ha frågor om innebörden av begreppen modeller och diagram. Vi tycker en vacker, men inte särskilt tydlig definition modeller som en semantiskt sluten systemabstraktionär osannolikt att klargöra situationen, så låt oss försöka förklara "med våra egna ord."

Modell- detta är ett visst (materiellt eller inte) objekt som endast uppvisar de viktigaste egenskaperna hos systemet för denna uppgift. Modeller är olika - påtagliga och immateriella, konstgjorda och naturliga, dekorativa och matematiska...

Låt oss ge några exempel. De plastleksaksbilar som vi alla känner till, och som vi spelade med sådan passion i barndomen, är inget annat än material konstgjord dekorativ riktig bilmodell. Naturligtvis, i en sådan "bil" finns det ingen motor, vi fyller inte tanken med bensin, växellådan fungerar inte i den (detta är den frånvarande alls), men som modell uppfyller denna leksak fullt ut sin funktioner: det ger barnet en uppfattning om bilen, eftersom det visar dess karakteristiska egenskaper är närvaron av fyra hjul, en kaross, dörrar, fönster, förmågan att köra, etc.

Inom medicinsk forskning föregår djurförsök ofta kliniska prövningar av läkemedel på människor. I det här fallet fungerar djuret som naturligt material mänskliga modeller.

Ekvationen som visas ovan är också en modell, men detta är en matematisk modell, och den beskriver rörelsen av en materiell punkt under inverkan av gravitationen.

Det återstår bara att säga vad ett diagram är. Diagramär en grafisk representation av en uppsättning element. Vanligtvis avbildad som en graf med hörn (entiteter) och kanter (relationer). Det finns många exempel på diagram. Detta är ett blockdiagram som vi alla känner till från skolåren, och installationsdiagram för olika utrustningar som vi kan se i användarmanualer, och ett träd med filer och kataloger på en disk, som vi kan se genom att köra trädkommandot i Windows-konsol, och mycket, mycket mer annat. I vardagen omger diagram oss från alla håll, eftersom en bild är lättare för oss att uppfatta än en text...

Men tillbaka till mjukvarudesign (och inte bara). I denna bransch sedan dess med hjälp av diagram kan du visualisera systemet från olika synvinklar. Ett av diagrammen kan till exempel beskriva användarens interaktion med systemet, det andra - förändringen i systemets tillstånd under dess drift, det tredje - interaktionen mellan elementen i systemet, etc. En komplex systemet kan och bör representeras som en uppsättning små och nästan oberoende modeller - diagram, och ingen av dem är tillräcklig för att beskriva systemet och få en fullständig bild av det, eftersom var och en av dem fokuserar på någon speciell aspekt av hur systemet fungerar. system och uttrycker ett annat abstraktionsnivå. Med andra ord, varje modell motsvarar någon specifik, speciell synvinkel på det system som designas.

Trots det faktum att vi i föregående stycke var mycket lösa med begreppet modell, bör det förstås att i samband med ovanstående definitioner inget enskilt diagram är en modell. Diagram är bara ett sätt att visualisera modellen, och de två bör särskiljas. Endast en uppsättning diagram utgör en systemmodell och beskriver det mest fullständigt, men inte ett diagram taget ur sitt sammanhang.

Typer av diagram

UML 1.5 definierad tolv typer av diagram uppdelad i tre grupper:

  • fyra typer av diagram representerar applikationens statiska struktur;
  • fem representerar de beteendemässiga aspekterna av systemet;
  • tre representerar de fysiska aspekterna av systemdrift (implementeringsdiagram).

Den nuvarande versionen av UML 2.1 har inte gjort alltför många ändringar. Diagram har ändrats något i utseende (ramar och andra visuella förbättringar har dykt upp), notationen har förbättrats något, vissa diagram har fått nya namn.

Men det exakta antalet kanoniska diagram det är absolut oviktigt för oss, eftersom vi inte kommer att överväga alla, utan bara några - av anledningen att antalet diagramtyper för en viss modell av en viss applikation inte är strikt fast. För enkla applikationer finns det inget behov av att bygga alla diagram utan undantag. Till exempel, för en lokal applikation, är det inte nödvändigt att bygga ett distributionsdiagram. Det är viktigt att förstå att listan över diagram beror på detaljerna i projektet som utvecklas och bestäms av utvecklaren själv. Om den nyfikna läsaren fortfarande vill veta om alla UML-diagram, kommer vi att hänvisa honom till UML-standarden (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Kom ihåg att syftet med denna kurs inte är att beskriva absolut alla möjligheter med UML, utan bara att introducera detta språk, för att ge en första uppfattning om denna teknik.

Så vi kommer kort att titta på sådana typer av diagram som:

  • diagram för användningsfall;
  • klassdiagram;
  • objektdiagram;
  • sekvensdiagram;
  • interaktionsdiagram;
  • tillståndsdiagram;
  • aktivitetsdiagram;
  • distributionsdiagram.

Vi kommer att prata om några av dessa diagram mer i detalj i nästa föreläsningar. För närvarande kommer vi inte att fokusera på detaljerna, utan sätta oss som mål att lära läsaren att åtminstone visuellt skilja mellan typerna av diagram, för att ge en första uppfattning om syftet med huvudtyperna av diagram. Så, låt oss börja.

Använd falldiagram

Alla system (inklusive mjukvara) är utformade med hänsyn till det faktum att de under arbetets gång kommer att användas av människor och/eller interagera med andra system. De enheter som systemet interagerar med under sitt arbete kallas skådespelare, och varje aktör förväntar sig att systemet ska bete sig på ett strikt definierat, förutsägbart sätt. Låt oss försöka ge en mer rigorös definition av en aktör. För att göra detta använder vi en underbar visuell vokabulär för UML Zicom mentor:

Hector (skådespelare)- detta är en uppsättning logiskt relaterade roller som utförs när de interagerar med prejudikat eller entiteter (system, undersystem eller klass). En aktör kan vara en person eller ett annat system, delsystem eller klass som representerar något utanför entiteten.

Grafiskt avbildas vektorn antingen " liten man", liknande de som vi ritade i barndomen, föreställande medlemmar av vår familj, eller klasssymbol med motsvarande stereotyp, som det visas på bilden. Båda presentationsformerna har samma innebörd och kan användas i diagram. Den "stereotypa" formen används oftare för att representera systemaktörer eller i de fall där aktören har egenskaper som behöver visas (Fig. 2.1).

Den uppmärksamma läsaren kan omedelbart ställa frågan: Varför är Hector och inte en skådespelare?? Vi är överens, ordet "ektor" skär en rysk person lite i örat. Anledningen till att vi säger detta är enkel - ektorn bildas av ordet handling, vilket betyder i översättning handling. Den bokstavliga översättningen av ordet "ektor" - skådespelare- för lång och obekväm att använda. Därför kommer vi att fortsätta att säga så.


Ris. 2.1.

Samma uppmärksamma läsare kunde lägga märke till att ordet "prejudikat" blinkade i definitionen av ektorn. Vad är det? Denna fråga kommer att intressera oss ännu mer om vi kommer ihåg att vi nu talar om diagram för användningsfall. Så,

Prejudikat (use-case)- beskrivning av en viss aspekt av systemets beteende ur användarens synvinkel (Butch).

Definitionen är ganska förståelig och uttömmande, men den kan förfinas ytterligare med densamma Zicom mentor"om:

användningsfall- Beskrivning av uppsättningen av successiva händelser (inklusive varianter) som utförs av systemet som leder till resultatet som observerats av skådespelaren. Ett användningsfall representerar beteendet hos en entitet genom att beskriva interaktionen mellan aktörerna och systemet. Ett prejudikat visar inte "hur" ett visst resultat uppnås, utan bara "vad" det är.

Prejudikat anges på ett mycket enkelt sätt - i form av en ellips, inuti vilken dess namn anges. Användningsfall och skådespelare kopplas ihop med linjer. Ofta i ena änden av raden avbildar ris. 2.3

  • bildande av allmänna krav för beteendet hos det system som designas;
  • utveckling av en konceptuell modell av systemet för dess efterföljande detaljering;
  • upprättande av dokumentation för interaktion med kunder och användare av systemet.
    • UML är ett generellt grafiskt modelleringsspråk för specifikation, visualisering, design och dokumentation av alla artefakter som skapas i utvecklingen av mjukvarusystem.

    Det finns många bra böcker som beskriver i detalj om UML (ibland till och med väldigt detaljerat), jag skulle vilja samla på ett ställe de grundläggande begreppen om diagram, entiteter och relationer mellan dem för snabb återkallelse, ungefär som ett fuskblad.

    Anteckningen använder material från böcker: Ivanov D. Yu., Novikov F. A. Unified modeling language UML och Leonenkov. UML handledning.

    Låt oss börja med editorn. Under Linux provade jag olika UML-redigerare, mest av allt gillade jag UMLet, även om det är skrivet i Java, det rör sig väldigt snabbt och de flesta av de tomma enheterna finns i det. Det finns också ArgoUML, en plattformsoberoende UML-redigerare, också skriven i Java, funktionellt rik, men saktar ner mer.

    Jag stannade kl UMLet, installera den under Arch Linux och ubuntu:

    # under Arch Linux yaourt -S umlet # under Ubuntu sudo apt-get install umlet

    I UML kan alla enheter delas upp i följande typer:

    • strukturell;
    • beteendemässiga;
    • gruppering;
    • annoterande;

    UML använder fyra huvudtyper av relationer:

    Beroende- indikerar att förändring av den oberoende enheten påverkar den beroende enheten på något sätt. Grafiskt avbildas ett beroendeförhållande som en prickad linje med en pil som pekar från den beroende enheten till den oberoende enheten.

    Förening- äger rum om en enhet är direkt relaterad till en annan (eller till andra - associationen kan inte bara vara binär). Grafiskt avbildas en association som en heldragen linje med olika tillägg som förbinder relaterade enheter.

    Generaliseringär ett förhållande mellan två enheter, varav den ena är ett särskilt (specialiserat) fall av den andra. Grafiskt avbildas generalisering som en linje med en triangulär ofylld pil i slutet, riktad från den särskilda (underklassen) till den allmänna (superklassen).

    Genomföranden- implementeringsrelationen indikerar att en enhet är en implementering av en annan. Grafiskt avbildas implementeringen som en prickad linje med en triangulär ofylld pil i slutet, riktad från den implementerande enheten till den implementerade.

    PÅ UML 2 definierat 13 diagramtyper. Enligt standarder bör varje diagram ha en ram med en rektangel (nedre högra hörnet avfasat) i det övre vänstra hörnet, vilket indikerar diagram-ID (tagg) och titel.

    Diagram som visar systemets struktur:

    • Komponentdiagram (komponentdiagram, tag komponent);
    • Implementeringsdiagram (distributionsdiagram, tagg spridning);
    • Klassdiagram (klassdiagram, tagg klass);
    • Objektdiagram (objektdiagram, tagg objekt);
    • Internt strukturdiagram (sammansatt strukturdiagram, tagg klass);

    Diagram för att visa systemets beteende:

    • Synkroniseringsdiagram (interaktionsdiagram, tagg timing);
    • Aktivitetsdiagram (aktivitetsdiagram, tagg aktivitet);
    • sekvensdiagram (sekvensdiagram, tagg sd);
    • Kommunikationsdiagram (kommunikationsdiagram, tagg komm);
    • Automatdiagram (ange maskindiagram, tagg statsmaskin);
    • Interaktionsöversiktsdiagram, tagg samspel);

    Diagrammen sticker ut:

    • Use case diagram (use case diagram, use case tag);
    • Paketdiagram (paketdiagram, tag paket);

    Användningsdiagram

    Användningsdiagram(use case diagram) är den mest allmänna representationen av systemets funktionella syfte.

    Om man betraktar ett use case-diagram som en modell av ett system, kan man associera det med en black box-modell. Varje användningsfall definierar en sekvens av åtgärder som måste utföras av det designade systemet när det interagerar med motsvarande aktör.

    Användningsdiagrammet använder två typer av grundläggande entiteter: användningsfall och aktörer, mellan vilka följande grundläggande typer av relationer etableras.

    föreningsförhållande– Detta förhållande fastställer vilken specifik roll en skådespelare spelar när han interagerar med en instans av ett användningsfall. En associationsrelation indikeras av en heldragen linje mellan aktören och användningsfallet. Denna rad kan ha ytterligare symboler, som till exempel ett namn och en multiplicitet.

    Förlängningsförhållande- definierar förhållandet mellan instanser av ett enstaka användningsfall och ett mer allmänt användningsfall, vars egenskaper bestäms baserat på hur dessa instanser kombineras. Om det alltså finns ett utvidgningsförhållande från användningsfall A till användningsfall B, innebär detta att egenskaperna för en instans av användningsfall B kan kompletteras på grund av förekomsten av egenskaper i utökat användningsfall A.

    Ett förlängningsförhållande mellan användningsfall indikeras av en streckad linje med en pil (beroendeförhållande) som pekar bort från användningsfallet som är en förlängning av det ursprungliga användningsfallet.

    Generaliseringsförhållande tjänar till att indikera det faktum att vissa användningsfall A kan generaliseras till användningsfall B. I detta fall kommer användningsfall A att vara en specialisering av användningsfall B. I det här fallet kallas B en förfader eller förälder till A, och användning A är en avkomling av användningsfall av V.

    Grafiskt representeras detta förhållande av en heldragen linje med en öppen triangelpil som pekar på det överordnade användningsfallet.

    En generaliseringsrelation mellan användningsfall används när det är nödvändigt att notera att underordnade användningsfall har alla attribut och beteenden för överordnade användningsfall.

    Inklusionsrelation mellan två användningsfall indikerar att något specificerat beteende för ett användningsfall ingår som en komponent i beteendesekvensen för ett annat användningsfall.

    Ett inkluderingsförhållande, från användningsfall A till användningsfall B, indikerar att varje instans av användningsfall A inkluderar de funktionella egenskaper som specificerats för användningsfall B.

    Grafiskt representeras detta förhållande av en prickad linje med en pil (variant av beroendeförhållande) som pekar från basanvändningsfallet till det inkluderade användningsfallet.

    klassdiagram

    klassdiagram(klassdiagram) - det huvudsakliga sättet att beskriva systemets statiska struktur.

    Klassdiagrammet använder en huvudtyp av entiteter: klasser (inklusive många specialfall av klasser: gränssnitt, primitiva typer, associationsklasser, etc.), mellan vilka följande huvudtyper av relationer etableras: beroenden, associationer, generaliseringar, implementeringar.

    Beroendeförhållande indikerar i allmänhet någon semantisk relation mellan två modellelement eller två uppsättningar av sådana element som inte är en association, generalisering eller implementeringsrelation. Ett beroendeförhållande används i en situation där någon förändring i ett modellelement kan kräva en förändring av ett annat beroende modellelement.

    Ett beroendeförhållande representeras grafiskt av en streckad linje mellan motsvarande element med en pil i ena änden, där pilen pekar från beroendets klientklass till den oberoende eller källklassen.

    Särskilda nyckelord (stereotyper) kan placeras ovanför pilen:

    • "access" - tjänar till att indikera tillgängligheten av offentliga attribut och operationer för källklassen för klientklasser;
    • "bind" - klientklassen kan använda någon mall för sin efterföljande parametrering;
    • "derive" - ​​attribut för klientklassen kan beräknas från källklassens attribut;
    • "import" - offentliga attribut och operationer för källklassen blir en del av klientklassen, som om de deklarerades direkt i den;
    • "förfina" - indikerar att klientklassen fungerar som en förfining av källklassen av historiska skäl, när ytterligare information blir tillgänglig under arbetet med projektet.

    föreningsförhållande motsvarar förekomsten av något samband mellan klasser. Detta förhållande indikeras av en heldragen linje med ytterligare specialsymboler som kännetecknar individuella egenskaper hos en viss förening. Som ytterligare specialtecken kan föreningens namn, samt namnen och mångfalden av föreningens rollklasser, användas. Namnet på en förening är en valfri del av dess beteckning.

    Aggregationsförhållande uppstår mellan flera klasser om en av klasserna är en entitet som inkluderar andra entiteter som komponenter. Den används för att representera systemrelationer av typen "del-hela".

    Sammansättningsförhållandeär ett specialfall av en aggregeringsrelation. Detta förhållande tjänar till att lyfta fram en speciell form av del-hel-förhållandet, där de ingående delarna i någon mening är inom helheten. Det speciella med förhållandet mellan dem ligger i det faktum att delarna inte kan agera isolerat från helheten, d.v.s. med förstörelsen av helheten förstörs också alla dess beståndsdelar.

    Generaliseringsförhållandeär ett förhållande mellan ett mer allmänt element (förälder eller förfader) och ett mer specifikt eller speciellt element (barn eller avkomling). Som tillämpat på ett klassdiagram beskriver detta förhållande klassernas hierarkiska struktur och arvet av deras egenskaper och beteende. Detta förutsätter att den efterkommande klassen har alla egenskaper och beteenden hos förfaderklassen, och även har sina egna egenskaper och beteende som inte finns i förfaderklassen.

    automatdiagram

    automatdiagram(ange maskindiagram) eller tillståndsdiagram i UML 1 (state chart diagram) är ett sätt att beskriva beteende i detalj i UML. I huvudsak är automatdiagram, som namnet antyder, en graf över tillstånd och övergångar för en finit automat laddad med många ytterligare detaljer och detaljer.

    Tillståndsdiagrammet beskriver processen att ändra tillstånden för endast en klass, eller snarare, en instans av en viss klass, det vill säga det modellerar alla möjliga förändringar i tillståndet för ett visst objekt. I detta fall kan en förändring i ett objekts tillstånd orsakas av yttre påverkan från andra objekt eller utifrån. Det är för att beskriva ett föremåls reaktion på sådana yttre påverkan som tillståndsdiagram används.

    I automatdiagrammet används en huvudtyp av entitet - tillstånd och en typ av relation - övergångar, men för båda definieras många varianter, specialfall och ytterligare beteckningar. Automaten representerar de dynamiska aspekterna av det simulerade systemet i form av en riktad graf, vars hörn motsvarar tillstånd och bågarna motsvarar övergångar.

    Initialtillståndär ett specialfall av ett tillstånd som inte innehåller några interna handlingar (pseudo-tillstånd). Objektet är i detta tillstånd som standard vid det första ögonblicket. Det tjänar till att indikera på tillståndsdiagrammet för det grafiska området från vilket processen att ändra tillstånd börjar.

    Final (final) en stat är ett specialfall av en stat som inte heller innehåller några interna handlingar (pseudo-tillstånd). Objektet kommer att vara i detta tillstånd som standard efter att automaten har slutförts vid sluttiden.

    aktivitetsdiagram

    När man modellerar beteendet hos ett designat eller analyserat system, blir det nödvändigt att inte bara presentera processen för att ändra dess tillstånd, utan också att detaljera funktionerna i den algoritmiska och logiska implementeringen av de operationer som utförs av systemet.

    aktivitetsdiagram(aktivitetsdiagram) är ett annat sätt att beskriva beteende som visuellt liknar ett gammalt gott flödesschema över en algoritm. Används för att simulera processen att utföra operationer.

    Huvudriktningen för att använda aktivitetsdiagram är att visualisera funktionerna i implementeringen av klassoperationer, när det är nödvändigt att presentera algoritmer för deras exekvering.

    I aktivitetsdiagrammet används en huvudtyp av enheter - handling, och en typ av relation - övergångar (överlåtelser av kontroll). Även sådana konstruktioner som gafflar, sammanslagningar, anslutningar, förgreningar används. Det rekommenderas att använda ett verb med förklarande ord som namn på en enkel handling.

    sekvensdiagram

    sekvensdiagram(sekvensdiagram) är ett sätt att beskriva systemets beteende "med exempel".

    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 entiteter - instanser av interagerande klassificerare (främst klasser, komponenter och aktörer), och en typ av relation - länkar genom vilka meddelanden utbyts.

    Möjliga typer av meddelanden (bild tagen från larin.in):

    Kommunikationsdiagram

    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.

    Således, i kommunikationsdiagrammet, såväl som i sekvensdiagrammet, används en huvudtyp av enheter - instanser av interagerande klassificerare och en typ av relation - anslutningar. Här ligger dock inte tyngdpunkten på tid, utan på strukturen av relationer mellan specifika instanser.

    Komponentdiagram

    Komponentdiagram(komponentdiagram) - visar förhållandet mellan modulerna (logiska eller fysiska) som utgör det simulerade systemet.

    Huvudentitetstypen i ett komponentdiagram är själva komponenterna, såväl som gränssnitt, genom vilka förhållandet mellan komponenterna indikeras. Följande samband gäller i komponentdiagrammet:

    • implementeringar mellan komponenter och gränssnitt (komponenten implementerar gränssnittet);
    • beroenden mellan komponenter och gränssnitt (en komponent använder ett gränssnitt);

    Placeringsdiagram

    Placeringsdiagram(distributionsdiagram), tillsammans med visning av systemelementens sammansättning och relationer, visar hur de fysiskt är placerade på datorresurser under exekvering.

    I placeringsdiagrammet, jämfört med komponentdiagrammet, läggs två typer av entiteter till: en artefakt, som är en implementering av komponenten och en nod (det kan antingen vara en klassificerare som beskriver typen av nod, eller en specifik instans) , såväl som ett associeringsförhållande mellan noder, vilket visar att noderna är fysiskt anslutna vid körning.

    Objektdiagram

    Objektdiagram(objektdiagram) - är en instans av ett klassdiagram.

    Objektdiagrammet använder en huvudtyp av entiteter: objekt (klassinstanser), mellan vilka specifika relationer anges (oftast associationsinstanser). Objektdiagram är av hjälpkaraktär - i själva verket är dessa exempel (man kan säga, minnesdumpar) som visar vilka objekt som finns och relationerna mellan dem vid något speciellt tillfälle i systemets drift.

    Diagram över inre struktur(sammansatt strukturdiagram) används för en mer detaljerad presentation av strukturella klassificerare, i första hand klasser och komponenter.

    En strukturell klassificerare visas som en rektangel med namnet på klassificeraren överst. Inuti finns delar. Det kan finnas flera delar. Delar kan interagera med varandra. Detta indikeras av kontakter av olika slag. Platsen på ytterkanten av den del som kontakten är fäst vid kallas porten. Hamnar är också belägna på den yttre gränsen för den strukturella klassificeraren.

    Interaktionsöversiktsdiagram(interaktionsöversiktsdiagram) är ett slags aktivitetsdiagram med en utökad syntax: länkar till interaktioner (interaktionsanvändning) definierade av sekvensdiagram kan fungera som element i ett översiktsinteraktionsdiagram.

    Tidsdiagram

    Tidsdiagram(tidsdiagram) är en speciell form av ett sekvensdiagram, där särskild uppmärksamhet ägnas åt förändringen i tillstånden för olika instanser av klassificerare och deras tidssynkronisering.

    Paketdiagram

    Paketdiagram(paketdiagram) är det enda verktyget som låter dig hantera komplexiteten i själva modellen.

    Huvudelementen i notationen är paket och beroenden med olika stereotyper.

    Entitetsrelationsmodell (ER-modell)

    analog klassdiagram(UML) kan vara ER-modell, som används vid design av databaser (relationsmodell).

    Entity-relationship model (ER-modell) är en datamodell som låter dig beskriva ämnesområdets konceptuella scheman. ER-modellen används i högnivå (konceptuell) databasdesign. Med dess hjälp kan du markera nyckelentiteterna och utse de relationer som kan upprättas mellan dessa entiteter. wikipedia

    Varje fragment av ämnesområdet kan representeras som en uppsättning enheter, mellan vilka det finns en viss uppsättning relationer.

    Grundläggande koncept:

    Väsen(enhet) är en enhet som kan identifieras på något sätt som särskiljer den från andra enheter, till exempel, KUND 777. En entitet är faktiskt en uppsättning attribut.

    Entitetsuppsättning(entitetsuppsättning) - en uppsättning enheter av samma typ (som har samma egenskaper).

    Förbindelse(relation) är en förening som upprättats mellan flera enheter.

    Domän(domän) - uppsättning värden (domän) för attributet.

    Det finns tre typer av binära länkar:

    • en till en- en enstaka instans av en entitet av en klass är associerad med en enskild instans av en entitet av en annan klass, till exempel HEAD - DEPARTMENT;
    • 1 till N eller en till många- en enstaka instans av en enhet av en klass är associerad med många instanser av en enhet av en annan klass, till exempel AVDELNING - ANSTÄLLD;
    • N till M eller många till många- många instanser av en entitet av en klass är associerade med många instanser av en entitet av en annan klass, till exempel, ANSTÄLLD - PROJEKT;
      • Ordlista över grundläggande begrepp i UML

      objekt- en enhet som har en unikhet och kapslar in tillstånd och beteende.

      klass- en beskrivning av en uppsättning objekt med gemensamma attribut som definierar tillstånd och operationer som definierar beteende.

      gränssnitt- 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- en uppsättning objekt som samverkar för att uppnå något mål.

      Skådespelare- en enhet som är utanför det modellerade systemet och direkt interagerar med det.

      komponent- en modulär del av systemet med en väldefinierad uppsättning nödvändiga och tillhandahållna gränssnitt.

      Artefakt- en del av information som används eller genereras i mjukvaruutvecklingsprocessen. Med andra ord är en artefakt en fysisk enhet för implementering som härrör från ett modellelement (som en klass eller komponent).

      Nod- en datorresurs på vilken artefakter placeras och vid behov exekveras.

      Beteendeenheter är avsedda att beskriva beteende. Det finns bara två grundläggande beteendeentiteter: tillstånd och handling.

      stat- en period i ett objekts livscykel, där objektet uppfyller ett visst villkor och utför sin egen aktivitet eller väntar på att någon händelse ska inträffa.

      handling- primitiv atomberäkning.

      Maskinär ett paket som definierar en uppsättning begrepp som är nödvändiga för att representera beteendet hos den modellerade entiteten som ett diskret utrymme med ett ändligt antal tillstånd och övergångar.

      klassificerareär en deskriptor för en uppsättning objekt av samma typ.

      Extra läsning

      • Fowler M. UML. Fundamentals, 3:e upplagan
      • Butch G., Rambo D., Jacobson I. UML-språk. Användarmanual

    Visa ett objekts beteende under dess livstid, från skapandet av objektet till dess förstörelse. Varje tillståndsdiagram representerar någon automat.

    Handlingsplan

    I avsnittet Beskrivning kan du lära dig mer om den grundläggande teckenuppsättningen för statechart som behövs för att kunna läsa diagram.

    Efter att ha läst de andra avsnitten ("Exempel", "Användning") kan du prova på att skapa tillståndsdiagram på egen hand.

    Anteckningar (beskrivning)

    Här är huvudpersonuppsättningen tillståndsdiagram behövs för att kunna läsa diagrammet. Efter att ha läst de andra avsnitten ("Exempel", "Ansökan"), kommer du att kunna komponera tillståndsdiagram på egen hand!

    Termin Bild Beskrivning
    Initial pseudostat Systemets initiala tillstånd
    Övergång Övergång innebär att flytta från ett tillstånd till ett annat.
    stat Betecknar de åtgärder som utförs av systemet (kan inkludera möjliga alternativ) som leder till de resultat som observerats av aktörerna.
    stat
    aktivitetstillstånd    		 Ett svårt steg i ett användningsfall kan representeras av ett annat användningsfall.
    I UML-termer säger vi att det första användningsfallet inkluderar det andra.
    Slutläge Låter dig ange gränserna för system eller delsystem.
    Interna aktiviteter Fallet där stater kan svara på händelser utan att göra en övergång, i vilket fall händelsen, vakten och aktiviteten placeras inuti tillståndsrektangeln.
    inmatningsaktivitet Inträdesaktiviteten utförs när du går in i staten
    produktion Exit-aktivitet - utförs när du lämnar staten.
    superstat
    		Det händer ofta att flera stater har gemensamma övergångar och interna aktiviteter. I sådana fall kan du förvandla dem till substater (substater) och överföra det övergripande beteendet till en superstat (superstat).
    Parallella stater
    		Tillstånd kan delas upp i flera samtidiga tillstånd som körs samtidigt.

    Hur man tillämpar tekniken för kreativitet

    UML-tillståndsdiagram är bra för att beskriva beteendet hos ett enda objekt över flera användningsfall. Men de är inte särskilt lämpade för att beskriva beteende som kännetecknas av interaktion mellan många objekt. Därför är det vettigt att använda andra tekniker i samband med tillståndsdiagram. Till exempel är interaktionsdiagram (kapitel 4) bra på att beskriva beteendet hos flera objekt i ett enda användningsfall, medan UML-aktivitetsdiagram är bra för att visa huvudsekvensen av åtgärder för flera objekt i flera användningsfall.

    Inte alla anser att tillståndsdiagram är naturliga. Se hur experterna arbetar med dem. Det är möjligt att dina teammedlemmar inte tycker att statecharts är rätt för deras sätt att arbeta. Detta är inte den största svårigheten; du måste komma ihåg att dela olika arbetssätt.

    Om du använder tillståndsdiagram, försök inte rita dem för varje klass i systemet. Detta tillvägagångssätt används ofta för formellt rigorös fullständighet, men det är nästan alltid ett slöseri med ansträngning. Använd endast tillståndsdiagram för klasser som uppvisar intressant beteende, där plottning av tillståndsdiagrammet hjälper dig att förstå hur det går.

    Många experter tror det UI-redigeraren och kontrollobjekten har funktionalitet som är användbar när de visas med ett tillståndsdiagram.

    Hur man lär sig

    Här har vi försökt ge det enklaste sättet att lära sig UML tillståndsdiagram.

    Liksom många andra språk använder den en uppsättning tecken för att beskriva. Innebörden av dessa symboler finns i tabellen i avsnittet "Anmärkningar (beskrivning)". Varje tecken har sitt eget namn (term) och stavning. Varje term är också försedd med en kort förklaring för att snabbt förstå dess huvudsakliga väsen.

    Därefter rekommenderar vi att du går till avsnittet "Exempel". tillståndsdiagram att prova på att läsa olika diagram. Sedan bör du studera avsnittet "Användning", för även om antalet diagramtyper i UML är litet, kan du få maximal nytta av att använda dem endast om du använder lämpliga diagram för deras avsedda syfte.

    Användningsexempel

    Statliga maskindiagramär en välkänd teknik för att beskriva ett systems beteende. Tillståndsdiagram har funnits i en eller annan form sedan 1960-talet, och i början av objektorienterad programmering användes de för att representera ett systems beteende. I objektorienterade tillvägagångssätt ritar du ett tillståndsdiagram för en enskild klass för att visa beteendet hos ett enskilt objekt under dess livstid.

    Närhelst det skrivs om finita tillståndsmaskiner, nämns oundvikligen farthållare eller varuautomater som exempel.
    Vi bestämde oss för att använda kontrollpanelen för den hemliga kontrollpanelen i Gothic Castle. I det här slottet vill vi gömma våra skatter så att de är svåra att hitta. För att få tillgång till kassaskåpets lås måste vi dra ut ett strategiskt ljus från kandelabern, men låset dyker bara upp om dörren är stängd. När låset dyker upp kan vi sätta in nyckeln i det och öppna kassaskåpet. För ökad säkerhet har vi gjort det så att kassaskåpet endast kan öppnas efter att ljuset har tagits bort. Om tjuven inte följer denna försiktighetsåtgärd, kommer vi att släppa lös ett avskyvärt monster som kommer att svälja tjuven.

    På fig. 10.1 visas tillståndsdiagram controller klass som hanterar mitt ovanliga säkerhetssystem. Tillståndsdiagrammet börjar med tillståndet för kontrollobjektet som skapas: tillstånd Vänta. Detta anges på diagrammet med initialt pseudostat, som inte är ett tillstånd, utan har en pil som pekar på initialtillståndet.
    Diagrammet visar att styrenheten kan vara i ett av tre tillstånd: Vänta (väntar), lås (lås) och öppna (öppnat). Diagrammet visar också reglerna enligt vilka regulatorn övergår från ett tillstånd till ett annat. Dessa regler representeras som övergångar - linjer som förbinder tillstånd.

    Övergång innebär att flytta från ett tillstånd till ett annat. Varje övergång har sin egen etikett, som består av tre delar:
    trigger-identifierare [skydd]/aktivitet (trigger-signatur /aktivitet). Alla är valfria. Vanligtvis, trigger-idär den enda händelse som kan orsaka en tillståndsändring.

    Bevakningen, om den anges, är ett logiskt villkor som måste uppfyllas för att övergången ska kunna ske. Aktivitet är något av systemets beteende under övergången. Det kan vara vilket beteendeuttryck som helst. Den fullständiga formen av en ID-utlösare kan inkludera flera händelser och parametrar. Övergången från vänteläge (Fig. 10.1) till ett annat tillstånd kan läsas som "I väntanläge, om ljuset tas bort, ser du ett lås och går till låsläge."

    Alla tre delar av övergångsbeskrivningen är valfria. Att hoppa över aktivitet innebär att ingenting händer under övergången. Skip guards innebär att övergången alltid exekveras om den utlösande händelsen inträffar. Triggeridentifieraren saknas sällan, men det händer. Detta innebär att övergången sker omedelbart, vilket främst kan observeras i aktiva tillstånd.

    När en händelse inträffar i ett visst tillstånd, då kan endast en övergång göras från detta tillstånd, till exempel i låst tillstånd (fig. 10.1), måste skydd vara ömsesidigt uteslutande. Om en händelse inträffar och det inte finns några tillåtna övergångar – till exempel att stänga ett kassaskåp i vänteläget eller ta bort ett ljus medan dörren är öppen – ignoreras händelsen.

    Slutläge ( sluttillstånd) betyder att tillståndsmaskinen har körts färdigt, vilket gör att kontrollobjektet raderas. Så för er som inte var noga nog med att falla i fällan, när kontrollobjektet upphör att existera, är vi tvungna att sätta tillbaka kaninen i sin bur, torka golvet och starta om systemet.

    Kom ihåg att tillståndsmaskiner endast kan visa objekt som direkt observeras eller ageras på. Så även om du kanske förväntar dig att vi lägger in något eller tar ut något ur kassaskåpet när dörren är öppen, har vi inte markerat det på diagrammet eftersom kontrollenheten inte kan berätta något om det.

    När utvecklare pratar om objekt hänvisar de ofta till objektens tillstånd, vilket betyder en kombination av all data som finns i objektets fält. Emellertid är tillstånd i ett tillståndsmaskindiagram ett mer abstrakt begrepp om tillstånd; poängen är att olika tillstånd innebär olika sätt att reagera på händelser.

    Interna aktiviteter i ett tillståndsdiagram

    Stater kan svara på händelser utan att göra en övergång med hjälp av intern verksamhet (intern verksamhet), i vilket fall händelsen, vakten och aktiviteten placeras inuti tillståndsrektangeln.

    På fig. Figur 10.2 visar tillståndet med interna symbolaktiviteter och hjälpsystemhändelser som du kan observera i editorns textfält. UI. En inre aktivitet är som en självövergång – en övergång som återgår till samma tillstånd. Syntaxen för interna aktiviteter är byggd enligt samma logiska schema av händelser, skydd och procedurer.

    På fig. 10.2 visar också särskilda aktiviteter: input och output aktiviteter. inmatningsaktivitet avrättas när du går in i staten; produktion– närhelst du lämnar staten. Däremot startar inte interna aktiviteter input och output aktivitet; detta är skillnaden mellan interna aktiviteter ochsjälvövergångar .

    Aktivitetstillstånd i ett tillståndsdiagram

    I de tillstånd vi har beskrivit hittills är objektet tyst och väntar på nästa händelse innan det gör något. Däremot är tillstånd möjliga där objektet uppvisar viss aktivitet.

    stat Sökande i fig. 10.3 är ett sådant tillstånd aktivitetstillstånd: pågående aktivitet indikeras med symbolen do/; därav termen göra aktivitet (var aktiv). Efter att sökningen är klar utförs övergångar utan aktivitet, som att visa ny utrustning (Visa ny maskinvara). Om en avbrytningshändelse inträffar under aktiviteten ( Avbryt), sedan gör-aktivitet avbryts helt enkelt och vi återvänder till staten Fönstret Uppdatera maskinvara.

    Både gör-aktiviteter och normala aktiviteter representerar manifestationen av något beteende. Den avgörande skillnaden mellan de två är att vanliga aktiviteter sker "omedelbart" och inte kan avbrytas av regelbundna händelser, medan aktiviteter kan pågå under en begränsad tid och kan avbrytas, som visas i figur 2. 10.3. Momentanitet för olika system tolkas olika; för realtidssystem kan detta ta flera maskininstruktioner och för stationär programvara kan det ta flera sekunder.

    PÅ UML 1 ordinarie verksamhet betecknades med begreppet handling(åtgärd) och termen aktivitet(aktivitet) användes endast för göra-aktiviteter.

    Superstater

    Det händer ofta att flera stater har gemensamma övergångar och interna aktiviteter. I sådana fall kan du förvandla dem till undertillstånd (substater) och överföra det övergripande beteendet till en superstat (superstat), som visas i fig. 10.4. Utan superstaten skulle vi behöva rita övergången Avbryt(avbryt) för alla tre staterna i en stat Ange anslutningsinformation.

    Parallella stater

    Tillstånd kan delas upp i flera samtidiga tillstånd som körs samtidigt. På fig. Figur 10.5 visar en enkel väckarklocka som kan slå på antingen en CD eller en radio och visa antingen aktuell tid eller signaltid.

    CD-/radioalternativ och aktuell tid/larmtid är parallella. Om du ville representera detta med ett icke-parallellt tillståndsdiagram, skulle du sluta med ett rörigt diagram eftersom tillstånd måste läggas till. Att dela upp de två beteendena i två tillståndsdiagram gör det mycket tydligare.

    Ris. 10.5 inkluderar också förhistorisk tillstånd(historia pseudostat). Det betyder att när klockan slås på ändras radio/CD-alternativet till det tillstånd som klockan var i när den stängdes av. En pil som kommer ut ur historien visar vilket tillstånd som fanns från början när det inte fanns någon historia.

    Implementera statecharts

    Ett tillståndsdiagram kan implementeras på tre huvudsakliga sätt: med hjälp av en kapslad switch-sats, tillståndsmönstret och en tillståndstabell. Det mest direkta tillvägagångssättet för att arbeta med tillståndsdiagram är en kapslad switch-sats, som den i figur 1. 10.6.

    Även om denna metod är okomplicerad, är den väldigt lång även för detta enkla fall. Dessutom, med detta tillvägagångssätt är det mycket lätt att tappa kontrollen, så vi rekommenderar inte att använda det även i enkla situationer.
    Tillståndsmönstret representerar en hierarki av tillståndsklasser för hantering av tillståndsbeteende. Varje tillstånd i tillståndsdiagrammet har sin egen tillståndsunderklass. Styrenheten har metoder för varje händelse som helt enkelt omdirigerar till tillståndsklassen. Tillståndsdiagrammet som visas i fig. 10.1 skulle kunna implementeras med hjälp av klasserna som visas i fig. 10.7.

    Överst i hierarkin är en abstrakt klass som innehåller en beskrivning av alla metoder som hanterar händelser, men ingen implementering.
    För varje specifikt tillstånd är det tillräckligt att skriva om hanterarmetoden för en specifik händelse som initierar övergången från tillståndet.
    Tillståndstabellen representerar tillståndsdiagrammet som data.

    Så, diagrammet i fig. 10.1 kan presenteras i form av en tabell. 10.1.
    Sedan bygger vi en tolk som använder tillståndstabellen under programkörning, eller en kodgenerator som genererar klasser baserat på denna tabell.

    Uppenbarligen görs det mesta av arbetet med tillståndstabellen en gång, men sedan kan det användas när du behöver lösa ett tillståndsrelaterat problem. Körtidstillståndstabellen kan modifieras utan omkompilering, vilket är något bekvämt. Tillståndsmallen är lättare att sätta ihop, och även om varje tillstånd kräver en separat klass, är mängden kod som måste skrivas ganska liten.

    De angivna implementeringarna är nästan minimala, men de ger en uppfattning om hur man ansöker tillståndsdiagram. I varje fall resulterar implementeringen av tillståndsmodellerna i ett ganska stereotypt program, så det är vanligtvis bättre att använda någon form av kodgenerering för detta.

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

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