Typer av diagram UML. UML2 och ER-diagram

UML-diagrammet är ett specialiserat grafiskt beskrivningsspråk som är utformat för objektmodellering i utvecklingen av olika utveckling programvara. Detta språk har en bred profil och är en öppen standard där olika grafiska beteckningar används för att skapa en abstrakt systemmodell. UML skapades för att tillhandahålla definition, visualisering, dokumentation, liksom utformningen av alla typer av mjukvarusystem. Det är värt att notera att UML-diagrammet själv inte är ett programmeringsspråk, men det ger möjlighet att generera en separat kod på grundval av.

Varför behövs det?

UML-ansökan slutar inte på modellering av alla typer av programvara. Dessutom används detta språk aktivt idag för att simulera olika affärsprocesser, hålla systemdesign, liksom visningen av organisationsstrukturer.

Att använda UML-programutvecklare kan ge ett fullständigt avtal i den grafiska notationen som används för att presentera allmänna koncept, till exempel: komponent, generalisering, klass, beteende och aggregering. På grund av detta uppnås en stor grad av koncentration på arkitektur och design.

Det är också värt att notera att det finns flera typer av sådana diagram.

Diagramdiagram

UML-klasserna är ett statiskt strukturdiagram som är utformat för att beskriva systemstrukturen, liksom demonstration av attribut, metoder och beroenden mellan flera olika klasser.

Det är värt att notera det faktum att det finns flera synpunkter på att bygga sådana diagram beroende på hur de kommer att användas:

• Konceptuell. I det här fallet beskriver UML-klassens diagram modellen för ett specifikt ämne, och det ger endast klasser av applikationer.
• Specifik. Diagrammet används i färd med att utforma olika informationssystem.
• Insikt. Klassdiagrammet innehåller alla typer av klasser som används direkt i programkoden.

Komponentdiagram

Diagrammet för UML-komponenterna är ett helt statiskt strukturdiagram. Det är avsett att visa uppdelningen av ett specifikt mjukvarusystem på en mängd olika konstruktionskomponenter, såväl som anslutningar mellan dem. Diagrammet för UML-komponenterna som sådana kan använda alla slags modeller, bibliotek, filer, paket, exekverbara filer och många andra element.

Komposit / sammansatt strukturdiagram

UML Sammansatt / kompositstrukturdiagrammet är också ett statiskt strukturdiagram, men det används för att visa den inre strukturen av klasserna. Om möjligt kan detta diagram också demonstrera interaktionen mellan element i klassens inre struktur.

Underdelen av dem är ett UML-diagram över samarbete, som används för att visa roller, liksom interaktionen mellan olika klasser inom kooperativa gränser. De är lämpliga nog om du behöver simulera designmallar.

Det är värt att notera att typerna av klass och kompositstrukturer används samtidigt.

Implementeringsschema

Detta diagram används för att simulera arbetsnoder, liksom alla slags artefakter som användes på dem. I UML 2 utplaceras artefakter på olika noder, medan i den första versionen uteslutande komponenter utvecklas. Således används UML-utplaceringsdiagrammet huvudsakligen till den andra versionen.

Mellan artefakten och den komponent som den realiserar bildas beroendet av manifestationen.

Diagram över objekt

Denna art gör att du kan se den fullständiga eller partiella ögonblicksbilden för systemet som skapas i viss ögonblick tid. Det visar helt alla fall av klasserna av ett visst system som indikerar de aktuella värdena för deras parametrar, liksom anslutningar mellan dem.

Paketdiagram

Detta diagram är strukturellt, och dess huvudinnehåll är alla slags paket, liksom relationer mellan dem. I det här fallet finns det ingen hård separation Mellan flera strukturella diagram, som ett resultat, är deras användning oftast enbart för bekvämlighet, och ingen semantisk mening är tråkig. Det är värt att notera att olika element kan ge andra UML-diagram (exempel: paket och paketdiagrams själva).

Deras användning utförs för att säkerställa att flera delar av flera delar i gruppen är ett visst tecken för att förenkla strukturen, liksom organisera arbete med modellen för detta system.

Diagramaktivitet

UML-aktivitetsschemat visar sönderdelning av vissa aktiviteter i flera komponenter. I det här fallet kallas begreppet "aktivitet" specifikationen av ett visst exekverbart beteende i form av en parallell, såväl som det samordnade sekventiella utförandet av olika underordnade element - investerade typer av aktiviteter och olika åtgärder, kombinerat med strömmar som är från utgångarna av en viss nod till ingångarna på den andra.

UML-aktivitetsdiagrammet används ofta för att simulera olika affärsprocesser, parallella och konsekventa beräkningar. Dessutom simuleras alla typer av tekniska procedurer.

Diagram över automatisk

Denna art kallas och något annorlunda - ett UML-tillståndsdiagram. Den har en skickad finig maskin med enkla och kompositstater, liksom övergångar.

Den slutliga automaten är specifikationen av en sekvens av olika tillstånd genom vilka ett visst objekt passerar, eller interaktionen som svar på några av händelserna i deras liv, liksom objektets svarsåtgärder för sådana händelser. Den slutliga maskinen som använder UML-tillståndsdiagrammet är fixerat av det ursprungliga elementet och används för att bestämma beteendet hos sina fall.

De så kallade draksystemen kan användas som analoger av sådana diagram.

Använd skript som ska användas

UML-användningsdiagrammet visar alla relationer som uppstår mellan aktörer, såväl som olika användningsalternativ. Huvuduppgiften är att utföra ett fullfjädrande medel, med vilken kunden, slutanvändaren eller någon utvecklare kommer att kunna diskutera beteendet och funktionaliteten hos ett visst system.

Om UML använder alternativdiagrammet används i systemmodelleringsprocessen, kommer analytiker att:

• Tydligt separera det simulerade systemet från sin miljö.
• Att identifiera aktörerna, sätt att interagera med detta system, liksom den förväntade funktionaliteten.
• Installera i ordlista som ett område med olika begrepp som relaterar till detaljerad beskrivning Funktionaliteten hos detta system.

Om du är utvecklad i UML i användardiagrammet börjar proceduren med en textbeskrivning, som erhålls när du arbetar med kunden. Det är värt att notera det faktum att olika icke-funktionella krav i processen att utarbeta den prejudikade modellen är helt sänkta, och ett separat dokument kommer redan att bildas.

Kommunikation

Kommunikationsdiagrammet på samma sätt som diagrammet för UML-sekvensen är transitiv, det vill säga det, och samtidigt demonstrerar det på olika sätt och, om det behövs, med den önskade graden av noggrannhet, en till En annan kan omvandlas till en annan.

Kommunikationsdiagrammet visar de interaktioner som uppstår mellan olika delar av kompositstrukturen, liksom samarbetets roller. Den huvudsakliga skillnaden i det från sekvensdiagrammet är att det tydligt indikerar relationerna mellan flera element, och tiden används inte som en separat mätning.

Denna typ kännetecknas av ett helt gratis format för att beställa flera objekt och anslutningar på samma sätt som det utförs i objektdiagrammet. Om det finns behov av att behålla meddelandesordningen i detta fria format utförs deras kronologiska numrering. Läser detta diagram börjar med det ursprungliga meddelandet 1.0, och fortsätter därefter av den riktning som meddelanden från ett objekt överförs till ett annat.

För det mesta visar sådana diagram exakt samma information som sekvensdiagrammet ger oss, men på grund av att en annan metod för att presentera information används här, blir vissa saker på ett diagram mycket lättare att bestämma än på en annan. Det är också värt att notera att kommunikationsdiagrammet tydligare visar med vilka element som varje enskilt element kommer in i interaktionen, medan sekvensdiagrammet visar tydligare, i vilka orderinteraktioner utförs.

Diagramsekvens

UML-sekvensdiagrammet demonstrerar interaktioner mellan flera föremål som beställs i enlighet med tiden för deras manifestation. På detta diagram visas interaktionen mellan flera objekt som beställts i tid. I synnerhet visar den alla föremål som deltar i interaktionen, liksom den fullständiga sekvensen av meddelanden som byts ut.

Huvudelementen i detta fall är beteckningarna av olika föremål, liksom vertikala linjer som visar tiden för tid och rektanglar som ger aktiviteten hos ett specifikt objekt eller utförandet av någon funktion.

Figursamarbete

Denna typ av diagram gör att du kan demonstrera interaktioner mellan flera objekt, abstrahera från meddelandesändningssekvensen. Denna typ av diagram i en kompakt form visar absolut alla överförda och mottagna meddelanden av ett specifikt objekt, liksom formaten för dessa meddelanden.

På grund av det faktum att sekvensen och kommunikationsdiagrammen helt enkelt är ett annat utseende på samma procedurer, Rationell ros. Ger förmågan att skapa kommunikation mellan sekvensdiagrammet eller tvärtom, och utför också helautomatisk synkronisering.

Diagramsöversyns interaktion

Dessa är diagrammen på UML-språket, som relaterar till sorterna av aktivitetsdiagrammen och inkluderar både sekvenselement och styrflödesdesign.

Det är värt att notera det faktum att detta format kombinerar samarbets- och sekvensdiagrammet som ger möjlighet med olika punkter Vision visning av interaktion mellan flera objekt i systemet som genereras.

Synkroniseringsschema

Det är en alternativ version av ett sekvensdiagram som uttryckligen visar en förändring i livsledningen med en viss tidsskala. Kan vara ganska användbar i olika realtidsansökningar.

Vad är fördelarna?

Det är värt att notera flera fördelar som skiljer sig från UML och det andra:

• Språk är objektorienterat, som ett resultat av vilken teknik som beskriver resultaten av analysen och designen är semantiskt nära programmeringsmetoder på alla slags objektorienterade språk av modern typ.
• Med hjälp av detta språk Systemet kan beskrivas nästan med eventuella synpunkter, och de olika aspekterna av sitt beteende beskrivs på samma sätt.
• Alla diagram är relativt enkla att läsa även efter en relativt snabb bekantskap med sin syntax.
• UML låter dig expandera, liksom ange dina egna grafiska och textstereotyper, vilket bidrar till dess användning inte bara i programvaruteknik.
• Språket var allmänt utbrett, och utvecklas också ganska aktivt.

nackdel

Trots det faktum att byggandet av UML-diagrammen särskiljs av massan av dess fördelar, är de ganska ofta kritiserade för följande brister:

• Redundans. I de flesta fall föreslås kritiker att UML är för stort och komplext, och det är ofta orimligt. Det innehåller ganska mycket överflödiga eller praktiskt taget värdelösa mönster och diagram, och oftast är sådan kritik till den andra versionen, och inte den första, eftersom det i nyare revisioner finns mer kompromisser "utvecklade av kommittén".
• Olika felaktigheter i semantik. Av den anledningen till att UML bestäms av kombinationen av sig själv, engelska och OCL, har den ingen styvhet, som är inneboende på språken, exakt definierade formella beskrivningstekniker. I vissa situationer börjar den abstrakta syntaxen OCL, UML och engelska motsäga varandra, medan de i andra fall är ofullständiga. Felaktigheter av beskrivningen av själva språket är lika påverkad av både användare och verktygsleverantörer, vilket slutligen leder till inkompatibilitet av verktyg på grund av en unik metod för tolkning av olika specifikationer.
• Problem i processen med implementering och studie. Alla ovanstående problem skapar vissa svårigheter i processen att genomföra och studera UML, och särskilt detta gäller de fall då manuell tvingar ingenjörerna att använda den för det, medan de inte har några preliminära färdigheter.
• Koden återspeglar koden. En annan åsikt är att vikten inte är vackra och attraktiva modeller, men direkt arbetssystem, det vill säga koden är projektet. I enlighet med detta yttrande är det nödvändigt att utveckla mer effektiv metod Programvara skrivande. UML är vanligt att uppskatta när närmar sig kompileringsmodeller för regenerering eller källkod. Men i själva verket kan det inte vara tillräckligt, eftersom det på detta språk inte finns några egenskaper för fullständighet i turning, och varje genererad kod kommer så småningom att begränsas till det faktum att det kan anta eller definiera ett tolkning av UML-verktyg.
• Fantasi av belastningen. Denna term Kommer från teorin om systemanalys för att bestämma oförmågan att ange ett specifikt system för att uppfatta utbytet av andra. Som i någon standardsystem Beteckningar, UML kan representera vissa system i effektivare och kort form jämfört med andra. Således är utvecklaren mer benägen att de lösningar som är bekvämare för att interlacera alla styrkor av UML, liksom andra programmeringsspråk. Det här problemet Det är tydligare om utvecklingsspråket inte motsvarar de grundläggande principerna för en objektorienterad ortodox doktrin, det vill säga det försöker inte arbeta i enlighet med OOP: s principer.
• Försöker vara universell. UML är ett modelleringsspråk generell meningVilket försöker säkerställa kompatibilitet med all befintlig språkbehandling idag. I samband med ett specifikt projekt, så att designers team kan uppnå det ultimata målet, måste du välja det tillämpliga kapaciteterna för detta språk. Dessutom pågår de möjliga sätten att begränsa omfattningen av UML-användningsområdet i ett visst område genom formalism, vilket inte är fullt formulerat, och som i sig är ett objekt av kritik.

Således är användningen av detta språk relevant långt ifrån alla situationer.

UML är ett enhetligt grafiskt modelleringsspråk för att beskriva, visualisering, design och dokumentation av OO-system. UML är utformad för att upprätthålla processen att modellera PS baserat på OO-tillvägagångssättet, för att organisera förhållandet mellan konceptuella och programkoncept, återspeglar problemen med skalande komplexa system. Modeller på UML används i alla stadier av PS livscykel, som börjar med en affärsanalys och slutar med underhållet av systemet. Olika organisationer kan tillämpa UML efter eget gottfinnande beroende på deras problemområden och teknik som används.

Kort historia UML

Vid mitten av 1990-talet föreslogs flera dussinmetoder för OO-modellering av olika författare, som var och en använde sin grafiska notering. Samtidigt hade någon av dessa metoder sina styrkor, men tillåter inte att bygga en ganska komplett PS-modell, visa den "på alla sidor", det vill säga alla nödvändiga prognoser (se artikel 1). Dessutom gjorde bristen på standard OO-modellering det svårt för utvecklare valet av den lämpligaste metoden, som förhindrade den utbredda spridningen av OO-metoden för utvecklingen av PS.

På begäran av Object Management Group (OMG) - Organisationer som ansvarar för antagande av standarder inom objektivteknik och databaser löses det brådskande problemet med enighet och standardisering av författarna till de tre mest populära OO-metoderna - B., D. Mboz och A.jekobson, som kombinerade ansträngningar skapade den version av UML 1.1, godkänd av OMG 1997 som en standard.

UML är ett språk

Varje språk består av en ordlista och regler för att kombinera ord för att få meningsfulla mönster. Så, i synnerhet programmeringsspråk är ordnade, så är både UML. Dess särskiljande funktion är att språkordlistan bildar grafiska element. Varje grafisk symbol motsvarar en specifik semantik, så den modell som skapas av en utvecklare kan också förstås förstås som andra programvaraTolka UML. Härifrån följer det att PS-modellen som presenteras på UML automatiskt kan översättas till OO-programmeringsspråket (till exempel Java, C ++, VisualBasic), det vill säga om det finns ett bra verktygsverktyg för visuell modellering Stödja UML, bygga en modell Vi får både en programkod som motsvarar den här modellen.

Det bör betonas att UML är språket, och inte metoden. Han förklarar från vilka element som skapar modeller och hur man läser dem, men ingenting talar om vilka modeller och i vilka fall som ska utvecklas. För att skapa en UML-baserad metod är det nödvändigt att komplettera det med en beskrivning av PS-utvecklingsprocessen. Ett exempel på en sådan process är rationell enhetlig process, som kommer att beaktas i efterföljande artiklar.

Uml ordbok

Modellen presenteras i form av enheter och relationer mellan dem, som visas i diagram.

Väsen - Det här är abstraktioner som är de viktigaste elementen i modellerna. Det finns fyra typer av enheter - strukturell (klass, gränssnitt, komponent, användningsalternativ, samarbete, nod), beteende (interaktion, stat), gruppering (paket) och anteckning (kommentarer). Varje typ av enhet har sin egen grafiska representation. Ental kommer att övervägas i detalj när man studerar diagram.

Förbindelser Visa olika anslutningar mellan enheter. Följande typer av relationer definieras i UML:

• Missbruk Visar denna anslutning mellan två enheter när förändringen i en av dem är oberoende - kan påverka semantiken av den andra - beroende. Beroende är avbildat av en prickad pil riktad mot den beroende enheten till oberoende.
• Förening - Detta är en strukturell attityd som visar att objekt av en enhet är förknippade med de andra föremålen. Grafiskt visas föreningen i form av en linje som förbinder de associerade enheterna. Föreningar används för att navigera mellan objekt. Till exempel kan associeringen mellan klasserna "order" och "varor" användas för att hitta alla varor som anges i en viss ordning - å ena sidan, eller för att hitta alla beställningar där det finns denna produkt - på den andra. Det är uppenbart att mekanismen i de relevanta programmen måste genomföras, vilket ger en sådan navigering. Om du bara behöver navigering i en riktning visas den av pilen i slutet av föreningen. Ett speciellt fall av föreningen är aggregering - förhållandet mellan arten "heltal" är "del". Det är grafiskt det är markerat med en diamant i slutet nära essensintegren.
• Generalisering - Detta är förhållandet mellan kärnan i föräldern och essensen i efterföljaren. I huvudsak återspeglar denna attityd egenskapen för arv för klasser och föremål. Generaliseringen visas i form av en linje som slutar med en triangel som syftar till föräldraskap. Den efterkommande äroderna är medlemmens struktur (attribut) och beteende (metoder), men samtidigt kan det få nya delar av strukturen och nya metoderna. UML tillåter flera arv när kärnan är associerad med mer än en förälder essens.
• Försäljning - Förhållandet mellan kärnan som bestämmer specifikationen för beteendet (gränssnitt) med en väsen som bestämmer genomförandet av detta beteende (klass, komponent). Denna relation används vanligen vid modellering av komponenten och kommer att beskrivas närmare i efterföljande artiklar.

Diagram. Följande diagram finns i UML:

• Diagram som beskriver systemets beteende:
• Statusdiagram (tillståndsdiagram),
• Aktivitetsdiagram (Aktivitetsdiagram),
• Objektdiagram (objektdiagram),
• Sekvensdiagram,
• Samarbetsdiagram;
• Diagram som beskriver det fysiska genomförandet av systemet:
• Komponentdiigram;
• Distributionsdiagram (Distributionsdiagram).

Modellhanteringsrepresentation. Paket.

Vi har redan pratat om det faktum att det för att modellen ska kunna bli väl förstådd av en person är det nödvändigt att organisera det hierarkiskt och lämna ett litet antal enheter på varje nivå av hierarkin. UML innehåller ett sätt att organisera en hierarkisk representation av modellen - paket. Varje modell består av ett paket som kan innehålla klasser, använda alternativ och andra enheter och diagram. Paketet kan innehålla andra paket, vilket gör att du kan skapa hierarkier. UML tillhandahåller inte enskilda paketdiagram, men de kan vara närvarande på andra diagram. Paketet är avbildat som en rektangel med ett bokmärke.

Vad ger UML.

• hierarkisk beskrivning av ett komplext system genom att markera paket;
• formalisering av funktionella krav för systemet med användning av användningsalternativ;
• detaljer om systemkrav genom att bygga kartor av verksamhet och scenarier;
• tilldelning av datakurser och konstruera en konceptuell datamodell i form av klassdiagram;
• urval av klasser som beskriver användargränssnittoch skapandet av skärmnavigeringsschemat;
• beskrivning av objektinteraktionsprocesser när man utför systemfunktioner;
• en beskrivning av beteendet hos objekt i form av diagram över aktiviteter och stater.
• beskrivning av programvarukomponenten och deras interaktion genom gränssnitt;
• beskrivning av systemets fysiska arkitektur.

Och den sista ...

Trots UML: ns attraktivitet skulle det vara svårt att använda i verklig modellering av PS utan instrumentala medel för visuell modellering. Sådana verktyg gör det möjligt att omedelbart representera diagrammen på skärmen, dokumentera dem, generera programmering av arbetsstycken på olika programmeringsspråk, skapa databasscheman. De flesta av dessa inkluderar programmeringsryggmöjligheterna - återställ vissa prognoser av PS-modellen genom att automatiskt analysera källkoden för program, vilket är mycket viktigt för att säkerställa modellens och kodernas överensstämmelse och vid utformning av system som är avvikande av föregångarnas funktionalitet.

Alla UML-diagram kan invigas till två grupper, varav den första är vanliga diagram. De totala diagrammen är praktiskt taget oberoende av modelleringsobjektet och kan användas i vilket program som helst, utan hänsyn till ämnesområdet, lösningsområdet etc.

1.5.1. Diagram användning

Diagram användning Använda falldiagram) är den mest allmänna presentationen av det funktionella systemet.

Användningsdiagrammet är utformat för att svara på huvudfrågan om modellering: Vad gör systemet i omvärlden?

Två typer av grundläggande enheter används i användningsdiagrammet: Alternativ för användning 1 och verkställande personer 2, mellan vilka följande huvudtyper av relationer är etablerade:

• förening mellan den aktiva personen och användningen av 3;
• generalisering mellan aktörer 4;
• generalisering mellan användningsalternativ 5;
• beroenden (olika typer) mellan användningsalternativ 6.

På användningsdiagrammet, såväl som någon annan, kan kommentarer delta. Dessutom rekommenderas det starkt att göra för att förbättra läsbarheten hos diagram.

Huvudelementen i den angivna notationen som används på användningsdiagrammet visas nedan. Detaljerad beskrivning ges i avsnitt 2.2.

1.5.2. Diagramdiagram

Diagramdiagram (Klassdiagram) är det viktigaste sättet att beskriva systemstrukturen.

Detta är inte förvånande eftersom UML är främst ett objektorienterat språk, och klasserna är de viktigaste (om inte det enda) "byggmaterialet".

På klasscheferna tillämpas en huvudtyp av enhet: klasserna 1 (inklusive många privata klasser Fodral: Gränssnitt, primitiva typer, associeringsklasser och många andra), mellan vilka följande huvudtyper av relationer är etablerade:

• förening mellan klasserna 2 (med många ytterligare detaljer);
• generalisering mellan klasserna 3;
• beroenden (olika typer) mellan klasserna 4 och mellan klasser och gränssnitt.

Vissa delar av notationen som används på klasschemat visas nedan. En detaljerad beskrivning ges i kapitel 3.

1.5.3. Diagram över automatisk

Diagram över automatisk Statens maskediagram) är ett av sätten att en detaljerad beskrivning av beteende i UML baserat på uttryckliga stater och beskrivningar av övergångar mellan stater.

I huvudsak är Automaton-diagrammen, som följer av namnet, ett diagram över statlig övergångsgraf (se kapitel 4), laddad med många ytterligare detaljer och detaljer.

På maskinschemat, en grundläggande typ av enhet - Staterna 1 och en typ av relation - övergångar 2, men också för dem för andra, är många arter, speciella fall och ytterligare beteckningar definierade. Listade dem alla i den inledande granskningen är inte meningsfullt.

En detaljerad beskrivning av alla variationer av automatdiagrammen ges i avsnitt 4.2, och följande figur visar endast de grundläggande elementen i den anmärkning som används på maskediagrammet.

1.5.4. Diagramaktivitet

Diagramaktivitet (Aktivitetsdiagram) är ett sätt att beskriva beteende baserat på indikering av kontrollflöden och dataströmmar.

Aktivitetscheman är ett annat sätt att beskriva beteende som visuellt liknar det gamla bra blockdiagrammet för algoritmen. På bekostnad av moderniserade beteckningar som överenskommits med ett objektorienterat tillvägagångssätt, och viktigast av allt, på grund av den nya semantiska komponenten (fri tolkning av Petri-nätverk), är UML-aktivitetschemat ett kraftfullt verktyg för att beskriva systemets beteende.

På aktivitetsschemat används en huvudenhetstyp - åtgärd 1 och en typ av relation - övergångar 2 (kontroll och dataöverföring). Det använder också sådana strukturer som en gaffelporering, fusioner, föreningar, förgrening 3, som liknar enheter, men är inte egentligen inte, men är en grafisk metod för bilden av några speciella fall av flerfamiljsliga relationer. Semantikerna för delar av aktivitetscheman demonteras i detalj i kapitel 4. Huvudelementen i notationen som används på aktivitetsdiagrammet visas nedan.

1.5.5. Diagramsekvens

Diagramsekvens (Sekvensdiagram) är ett sätt att beskriva systemets beteende baserat på att specificera sekvensen av överförda meddelanden.

Faktum är att sekvensdiagrammet är registret för protokollet för en specifik session i systemet (eller fragment av ett sådant protokoll). I objektorienterad programmering är den mest signifikanta vid utförandet att skicka meddelanden mellan interagerande föremål. Det är sekvensen av meddelandepaket som visas på detta diagram, följaktligen namnet.

På sekvensdiagrammet tillämpas en huvudtyp av enhet - instanser av interagerande klassificeringsmedel 1 (främst klasser, komponenter och fungerande personer) och en typ av relation - kommunikation 2, på vilka meddelanden utbyts 3. Det finns flera sätt att skicka meddelanden, vilket i grafisk notering skiljer sig åt i synvinkeln som motsvarar förhållandet.

En viktig aspekt av sekvensdiagrammet är en tydlig visning av tidflödet. Till skillnad från andra typer av diagram, med undantag för synkroniseringsdiagram, är sekvensdiagrammet, inte bara närvaron av grafiska kopplingar mellan elementen, utan också elementets relativa läge i diagrammet. Namnlösa anser det att det finns en (osynlig) tidsaxel, som standard riktad från topp till botten, och det meddelande som skickas senare dras nedan.

Tidaxeln kan riktas horisontellt, i det här fallet antas det att tiden flyter från vänster till höger.

Följande bild visar huvudelementen i notationen som används på sekvensdiagrammet. Standard Notation tillämpas för att beteckna de interaktiva objekten själva - en rektangel med namnet på klassificeringsinstansen. Den prickade linjen kommer från det kallas en Linas of Life (Lifeline) 4. Detta är inte beteckningen av förhållandet i modellen, men en grafisk kommentar, utformad för att rikta läsarens syn på diagrammet i rätt riktning. Siffror i form av smala remsor som åläggs livslängden är inte heller bilder av simulerade enheter. Detta är en grafisk kommentar som visar segmenten av den tid under vilken objektet äger kontrollströmmen (utförande förekomst) 5 eller med andra ord, aktiveringen (aktivering) av objektet äger rum. Kompositinteraktionssteg (kombinerat fragment) 6 Tillåt på sekvensdiagrammet, återspeglar de algoritmiska aspekterna av interaktionsprotokollet. Övriga detaljer om notering av sekvensdiagrammet, se kapitel 4.

1.5.6. Kommunikationsdiagram

Kommunikationsdiagram (Kommunikationsdiagram) är ett sätt att beskriva beteende, semantiskt ekvivalent sekvensdiagram.

I själva verket är detta samma beskrivning av meddelandesekvensen för interaktiva instanser av klassificerare, som endast uttrycks av annan grafik. Dessutom kan de flesta verktyg automatiskt konvertera sekvensdiagrammen i kommunikationsschemat och tillbaka.

Således, på kommunikationsdiagrammet, liksom på sekvensdiagrammet, används en huvudtyp av enhet - instanser av interagerande klassificeringsmedel 1 och en typ av relation - kommunikation 2. Men betoningen är inte klar i tid, men på strukturen av anslutningar mellan specifika kopior.

Figuren visar huvudelementen i notationen som används på kommunikationsschemat. Standard Notation tillämpas för att beteckna de interaktiva objekten själva - en rektangel med namnet på klassificeringsinstansen. Elements gemensamma position på samarbetsdiagrammet spelar ingen roll - endast band är viktiga (oftast instanser av föreningar), därmeddelanden 3 överförs. En hierarkisk decimalnummer tillämpas för att visa beställningen av meddelanden i tid.

1.5.7. Komponentdiagram

Komponentdiagram (Komponentdiagram) - Visar förhållandet mellan moduler (logiskt eller fysiskt), varav modellen är en modell.

Huvudtypen av enheten på komponentdiagrammet är komponenterna 1, såväl som gränssnitt 2, med vilket förhållandet mellan komponenter indikeras. Följande relationer gäller på komponentdiagrammet:

• implementeringar mellan komponenter och gränssnitt (komponenten implementerar gränssnittet);
• beroende mellan komponenterna och gränssnittet (komponenten använder gränssnittet) 3.

Figuren visar huvudelementen i notationen som används på komponentdiagrammet. En detaljerad beskrivning ges i kapitel 3.

1.5.8. Placeringsdiagram

Placeringsdiagram (Distributionsschema) tillsammans med displayen av kompositionen och länkarna i systemelementen, visar hur de fysiskt publiceras på beräkningsresurser under utförandet.

Således finns det två typer av enheter jämfört med komponentdiagrammet, två typer av enheter läggs till: artefakt 1, vilket är implementeringen av komponent 2 och nod 3 (kan vara som en klassificerare som beskriver typen av nod och en specifik instans) , såväl som associeringens inställning mellan noder 4, som visar att noderna är fysiskt anslutna under utförandet.

Figuren visar huvudelementen i notering som används i loggdiagrammet. För att visa att en enhet är en del av den andra, appliceras den antingen förhållandet mellan "implementera" 5-beroende, eller siffran för en enhet placeras inuti en annan enhets siffra 6. En detaljerad beskrivning av diagrammet ges i kapitel 3.

& NBSP & NBSP & PSP & NBSP Unified Modeling Language (Unified Modeling Language - UML) är ett språk för att specificera, visualisera, designa och dokumentera programvaran, samt affärsmodeller och andra icke-programvarusystem. UML är en sammanslutning av tekniktekniker som tidigare användes i modellering av stora och komplexa system.

& NBSP & NBSP & NBSP & NBSP Skaparna av UML representerar det som ett språk för att definiera, presentera, utforma och dokumentera mjukvarusystem, affärssystem och andra system av olika natur. UML definierar notering och metamodel. Notation är en kombination av grafiska objekt som används i modeller; Det är syntaxen för modelleringsspråket.

& NBSP & NBSP & NBP & NBSP UML ger uttrycksfulla verktyg för att skapa visuella modeller som:

• enhetligt förstås av alla utvecklare som är involverade i projektet;
• är ett kommunikationsmedel inom projektet.

& NBSP & NBSP & NBSP Unified Modeling Language (UML):

• beror inte på objektorienterade (OO) programmeringsspråk;
• beror inte på den använda projektmetodiken;
• kan stödja något OO-programmeringsspråk.

& NBSP & NBSP & NBSP & NBSP UML är öppen och har möjlighet att expandera baskärnan. Vid UML är det möjligt att beskriva klasser, föremål och komponenter i olika ämnesområden som ofta skiljer sig från varandra.

UML-diagram

& NBSP & NBSP & NBSP & NBSP Adress Rational Rose Designer ger följande typer av diagram, den sekventiella skapelsen som gör det möjligt att få en komplett bild av det hela projicerade systemet och dess separata komponenter:

• Använd falldiagram (prejudikatdiagram);
• Deployment Diagram (Topology Charts);
• Statechart Diagram (State Charts);
• Interaktionsdiagram (interaktionsdiagram); Aktivitetsdiagram (Aktivitetsdiagram);
• Sekvensdiagram (sekvensdiagram);
• Samarbetsschema (samarbetsdiagram);
• Klassschema (klasschema);
• Komponentdiagram (komponentdiagram);
• Beteendediagram (beteendekartor);
• Aktivitetsdiagram (Aktivitetsdiagram);
• Implementeringsdiagram (implementeringsdiagram)

& NBSP & NBSP & NBSP & NBSP Varje av dessa diagram anger olika idéer om systemmodellen. Samtidigt är ett diagram över användningsalternativ en konceptuell modell av ett system som är originalet för att bygga alla andra diagram. Klassdiagrammet är en logisk modell som återspeglar de statiska aspekterna av systemets strukturella konstruktion, och beteendekartorna, som också är sorter av den logiska modellen, återspeglar de dynamiska aspekterna av dess funktion. Implementeringskartor tjänar till att representera systemkomponenter och tillhör sin fysiska modell.

& Nbsp & nbsp & nbsp & nbsp Vissa ovanstående tjänar till att ange två eller flera underarter. Följande diagram används som oberoende representationer: alternativ för användning, klasser, stater, aktiviteter, sekvenser, samarbete, komponenter och implementering.

& NBSP & NBSP & NBSP & NBSP för UML-diagram Det finns tre typer av visuella beteckningar som är viktiga ur informationssynpunkt som bifogas dem:

• kommunikationsom verkar olika linjer på planet;
• textinnehöll inom gränserna för enskilda geometriska former;
• grafiska symbolerAvbildad nära de visuella elementen i diagram.

& NBSP & NBSP & NBSP & PSP med en grafisk bild av diagram, rekommenderas att följa följande regler:

• varje diagram bör vara den färdiga representationen av ett fragment av det simulerade ämnesområdet;
• modellens essensdiagram ska vara en konceptnivå;
• all information om enheter bör uttryckligen representeras i diagrammet.
• diagram ska inte innehålla motstridiga uppgifter.
• diagram ska inte överbelasta textinformation;
• varje diagram måste vara självförsörjande för rätt tolkning av alla dess element;
• antalet typer av diagram som krävs för att beskriva ett specifikt system är inte strikt fast och bestäms av utvecklaren;
• systemmodellerna måste endast innehålla de element som definieras i Notering av UML-språket.

Enheter i UML.

& Nbsp & NBSP & NBSP i UML definierade fyra typer av enheter: Strukturell, beteende, gruppering och anteckning. Enheter är de viktigaste objektorienterade elementen i vilket modeller som skapas.

& Nbsp & nbsp & nbsp & nbsp Strukturella enheter - Det här är substantiv i modeller på UML-språket. Som regel representerar de de statiska delarna av modellen som motsvarar systemets konceptuella eller fysiska element. Exempel på strukturella enheter är klass, "gränssnitt", "samarbete", "prejudikat", "komponent", "nod", "skådespelare".

& Nbsp & nbsp & nbsp & nbsp Beteendemässiga enheterär de dynamiska komponenterna i UML-modellen. Dessa är verb som beskriver beteendet hos modellen i tid och i rymden. Det finns två huvudtyper av beteendemässiga enheter:

• interaktion är beteendet, vars essens är att utbyta meddelanden mellan föremål inom ett visst sammanhang för att uppnå ett visst mål.
• maskinen - beteendalgoritmen som bestämmer sekvensen av tillstånd genom vilka objektet eller interaktionen sker som svar på olika händelser.

& Nbsp & nbsp & nbsp & nbsp Gruppering enheterorganiserar delar av UML-modellen. Dessa är block som du kan sönderdela modellen. Sådan primär essens är tillgänglig i en enda instans - det här är ett paket.

& NBSP & NBSP & NBSP & NBSP-paket är en universell mekanism för att organisera element i grupper. Paketet kan placeras strukturella, beteendemässiga och andra gruppgivningsenheter. Till skillnad från komponenter som verkligen finns under programmet är paketen rent konceptuella i naturen, det är bara i utvecklingsprocessen.

& Nbsp & nbsp & nbsp & nbsp Annotationsenheter- Detta är en förklarande del av UML-modellen: Kommentarer till ytterligare beskrivning, förtydligande eller kommentarer till något element i modellen. Det finns bara en grundläggande typ av anteckningselement - anteckning. Obs! Används för att ge diagram med kommentarer eller restriktioner uttryckta i form av informell eller formell text.

Förbindelser i UML

& Nbsp & nbsp & nbsp &p i UML-språk, följande typer av relationer definieras: Beroende, förening, generalisering och försäljning. Dessa relationer är de viktigaste bindande UML-konstruktionerna och även som enheter används för att bygga modeller.

& Nbsp & nbsp & nbsp & nbsp Beroende (beroende)- Detta är ett semantiskt förhållande mellan två enheter, där förändringen i en av dem, oberoende, kan påverka semantiken hos en annan beroende.

& Nbsp & nbsp & nbsp & nbsp Association (Association) - Strukturellt förhållande som beskriver uppsättningen av semantiska eller logiska anslutningar mellan objekt.

& Nbsp & nbsp & nbsp & nbsp Generalisering (generalisering) - Detta är ett förhållande där föremålet för ett specialiserat element (ättling) kan ersättas istället för föremålet för det generaliserade elementet (förfader). Samtidigt är det i enlighet med principerna om objektorienterad programmering, varva sin förfader (förälder) strukturen och beteendet.

& Nbsp & nbsp & nbsp & nbsp Implementering (realisering) Det är en semantisk inställning mellan klassificerare, där en klassificerare bestämmer skyldigheten, och den andra garanterar dess verkställighet. Realiseringsrelationen finns i två fall:

• mellan gränssnitt och deras klasser eller komponenter;
• mellan prejudikat och samarbeten som genomför dem.

Allmänna mekanismer UML

& NBSP & NBSP & NBSP & NBSP För exakta beskrivning av systemet i UML används de så kallade allmänna mekanismerna:

• specifikationer (specifikationer);
• tillägg (prydnader);
• divisioner (gemensamma divisioner)
• extensibilitetsmekanismer (extensibilitetsmekanismer).

& NBSP & NBSP & NBSP & NBSP UML är inte bara grafiskt språk. För varje grafiskt element i dess notationskostnader specifikationinnehållande en textrepresentation av motsvarande språkdesign. Till exempel motsvarar en klassikon en specifikation som beskriver dess attribut, operationer och beteende, men visuellt, i diagrammet, speglar ikonen ofta endast en liten del av denna information. Dessutom kan det finnas en annan presentation av denna klass i modellen, vilket återspeglar helt olika aspekter, men ändå motsvarande specifikationen. Således används UML-grafiska notationen för att visualisera systemet och använda specifikationerna beskriva dess delar.

& NBSP & NBSP & NBSP & NBSP Nästan varje UML-element har en unik grafisk bild, vilket ger en visuell representation av sina viktigaste egenskaper. Notation av företaget "klass" innehåller sitt namn, attribut och operationer. Klassspecifikationen kan innehålla andra detaljer, till exempel synligheten av attribut och operationer, kommentarer eller indikation på att klassen är abstrakt. Många av dessa delar kan visualiseras som grafisk eller text. Tillägg Till standardrektangeln, som visar klassen.

& NBSP & NBSP & NBSP & NBSP När du modellerar objektorienterade system finns det en viss divisionrepresenterade enheter.

& Nbsp & nbsp & nbsp & nbsp Första, det finns en uppdelning i klasser och föremål. Klassen är en abstraktion, och objektet är en specifik utföringsform av denna abstraktion. I detta avseende kännetecknas nästan alla språk av språket av dualiteten i "klass / objekt". Så det finns precenter och instanser av prejudikat, komponenter och instanser av komponenter, noder och kopior av noder. I den grafiska representationen för objektet är det vanligt att använda samma symbol som för klassen, och namnet är att betona.

& Nbsp & nbsp & nbsp & nbsp För det andra finns det en division på gränssnittet och dess implementering. Gränssnittet förklarar skyldigheterna, och genomförandet presenterar en särskild utföringsform av dessa förpliktelser och ger en exakt efterlevnad av den tillkännagivna semantiken. I detta avseende kännetecknas nästan alla UML-mönster av dubbelt gränssnitt / implementering. Exempelvis imponeras prejudikat av kooperatorer och operationer - metoder.

& NBSP & NBSP & PSP & NBSP UML är ett öppet språk, det vill säga att det tillåter kontrollerade tillägg för att återspegla funktionerna i modellerna av ämnesområden.

& NBSP & NBSP & NBSP & NBSP UML Expansion Mekanismer inkluderar:

• stereotyper (stereotyp) - Expandera UML-ordlistan, så att de befintliga språkomunkten kan skapa nya orienterade för att lösa ett specifikt problem.
• taggat värde - expandera egenskaperna hos de grundläggande UML-strukturerna, så att du kan inkludera ytterligare information till elementspecifikationen;
• begränsningar - Utöka semantiken i UML-design, så att du kan skapa nya och avbryta befintliga regler.

& NBSP & NBSP & NBSP & NBSP Tillsammans medger dessa tre språkutbyggnadsmekanismer att du ändrar det i enlighet med projektets behov eller funktionerna i utvecklingstekniken.

Använd Case Diagram (Använd Case Diagram)

& NBSP & NBSP & NBSP & NBSP Denna typ av diagram gör att du kan skapa en lista över operationer som systemet utför. Ofta kallas denna typ av diagram diagram över funktioner, eftersom på grundval av en uppsättning sådana diagram, skapas en lista över systemkrav och uppsättningen funktioner som utförs av systemet.

Figur - 1. Diagram av användningsalternativ

& Nbsp & nbsp & nbsp & nbsp-diagram beskriver systemfunktionellt eller vad systemet ska göra. Diagrammets utveckling har följande mål:

• bestäm de totala gränserna och sammanhanget för det simulerade ämnesområdet.
• formulera allmänna krav för det projicerade systemets funktionella beteende;
• utveckla en källa konceptuell systemmodell för efterföljande detaljer i form av logiska och fysiska modeller;
• förbered källdokumentationen för samspelet mellan systemutvecklare med sina kunder och användare.

& NBSP & NBSP & NBSP & NBSP Kärnan i användningsoptionsdiagrammet är som följer. Det projicerade systemet presenteras i form av en rad olika enheter eller aktörer som interagerar med systemet med hjälp av användningsalternativ. Samtidigt kallas en skådespelare (skådespelare) eller en aktiv person någon enhet som interagerar med systemet från utsidan. Det kan vara en person, en teknisk enhet, ett program eller något annat system, som kan fungera som en påverkan på det simulerade systemet när utvecklaren själv bestämmer. Alternativ användning Det tjänar till att beskriva de tjänster som systemet ger skådespelaren.

& Nbsp & nbsp & nbsp & nbsp Syftet med användningsalternativet är att bestämma den färdiga aspekten eller fragmentet av beteendet hos någon enhet utan att avslöja sin interna struktur. Ett system eller något element i en modell som har sitt eget beteende kan fungera som en sådan enhet.

& NBSP & NBSP & NBSP & NBSP Varje användningsalternativ uppfyller en separat tjänst som ger en simulerad enhet på skådespelarens begäran, det vill säga bestämmer metoden för tillämpning av denna enhet. Tjänsten som initieras på begäran av skådespelaren är en fullständig odelbar sekvens av åtgärder. Det innebär att efter att systemet avslutat bearbetningen av begäran måste den returneras till det ursprungliga tillståndet för att vara redo att utföra följande förfrågningar.

& NBSP & NBSP & NBSP & NBSP-användningsalternativ kan användas både för att ange externa krav för designsystemet och för specifikationen av det redan befintliga systemets funktionella beteende. Många alternativ för användning i allmänhet bör bestämma alla möjliga fester i det förväntade beteendet hos systemet. Dessutom fastställer användningsalternativ implicit de krav som definierar hur aktörerna måste interagera med systemet för att kunna fungera korrekt med de tillhandahållna tjänsterna. För bekvämligheten kan många användningsalternativ behandlas som ett separat paket.

& NBSP & NBSP & NBSP & NBSP Exempel på användningsalternativ kan vara följande åtgärder: Kontrollera statusen för kundens löpande konto, registrering av inköpsordern, ta emot ytterligare information om kundens kreditvärdighet, kartläggning av grafisk form på bildskärmen och andra åtgärder.

Klassdiagramdiagram

& NBSP & NBSP & NBSP & NBSP Den centrala platsen i objektorienterad programmering är upptagen av utvecklingen av en logisk modell av systemet i form av ett klasser diagram. Klassdiagram (klassschema) används för att representera den statiska strukturen i systemmodellen i terminologin för objektorienterade programmeringsklasser. Klassdiagrammet kan särskilt reflektera av de olika relationerna mellan de enskilda enheterna i ämnesområdet, såsom föremål och delsystem, samt beskriver deras interna struktur och typer av relationer.

Figur 2. Klassdiagram

& Nbsp & nbsp & nbsp & nbsp diagram ikoner gör att du kan visa en komplex hierarki av system, klassrelationer (klasser) och gränssnitt (gränssnitt). Denna typ av diagram är motsatt innehållet i samarbetsdiagrammet, som visar systemobjekten. Rational Rose kan du skapa klasser med denna typ av diagram i olika noteringar. Ser ut som ett moln. Således är en klass bara en mall för vilken ett specifikt objekt kommer att skapas i framtiden.

& Nbsp & nbsp & nbsp & nbsp klassdiagram är ett diagram vars vertikor är "klassificerare" typelement som är förknippade med olika typer av strukturella relationer. Klassdiagram kan också innehålla gränssnitt, paket, relationer och till och med enskilda instanser, till exempel objekt och kommunikation.

& Nbsp & nbsp & nbsp & nbsp Klass (klass) UML-språket tjänar till att ange en mängd olika föremål som har samma struktur, beteende och relationer med andra klasser. Grafiskt är klassen avbildad som en rektangel, som dessutom kan delas med horisontella linjer till sektioner eller sektioner. Dessa sektioner kan indikera klassnamnet, attribut (variabler) och operationer (metoder).

Statskarta (Statechart Diagram)

& NBSP & NBSP & NBP & NBSP Varje statligt diagram i UML beskriver alla möjliga tillstånd av en förekomst av en viss klass och möjliga sekvenser av dess övergångar från ett tillstånd till en annan, det vill säga att det simulerar alla ändringar i objektets tillstånd som dess reaktion på yttre påverkan.

& NBSP & NBSP & NBSP & NBSP Condition Charts används oftast för att beskriva beteendet hos enskilda objekt, men kan också tillämpas på specifikationen av funktionaliteten hos andra komponenter i modeller, såsom användningsområden, aktörer, delsystem, operationer och metoder.

Figur 2. Statligt diagram

& Nbsp & nbsp & nbsp & nbsp State Chart är ett speciellt typgraf som representerar någon maskin. Grafens vertikal är de möjliga tillstånden i den automatiska som avbildas av motsvarande grafiska symboler, och bågarna indikerar dess övergångar från tillståndet till tillståndet. Skicksdiagram kan investeras i varandra för en mer detaljerad presentation av enskilda modellelement.

& Nbsp & nbsp & nbsp i UML Metamodel maskin Det är ett paket där många begrepp behövs för att representera beteendet hos den simulerade enheten i form av ett diskret utrymme med ett begränsat antal stater och övergångar.

& NBSP & NBSP & NBSP & NBSP Systemets varaktighet är belägen i någon av de möjliga staterna, överstiger avsevärt den tid som spenderas på övergången från ett tillstånd till en annan. Det antas att i gränsen kan övergångstiden vara noll (om annars noteras inte anges), det vill säga ändringen av statliga stater kan inträffa omedelbart.

& NBSP & NBSP & NBSP & NBSP Maskinens beteende simuleras som en sekventiell rörelse längs grafen från vertexen till vertexen, med hänsyn till orienteringen av bindningen av deras bågar.

Följande obligatoriska villkor måste utföras med NBSP & NBSP & NBSP & NBSP

• det tillstånd där objektet kan gå är endast bestämt av sitt nuvarande tillstånd och beror inte på förhistoria;
• när som helst kan maskinen endast vara i en av sina stater. Samtidigt kan maskinen vara i ett separat tillstånd som om några händelser inte förekommer;
• tiden att hitta en maskingevär i ett tillstånd, liksom tiden för att uppnå ett eller annat tillstånd inte anges.
• antalet västar av maskinen måste vara ändlig och alla måste anges uttryckligen. Separat pseudo-position får inte ha specifikationer (inledande och slutliga stater). I det här fallet bestäms deras syfte och semantik fullt ut ur modellens sammanhang och det aktuella diagrammet.
• maskinens diagram får inte innehålla isolerade tillstånd och övergångar. För varje stat, förutom det ursprungliga, måste föregående tillstånd definieras, och varje övergång måste ansluta två tillstånd av maskinen;
• maskinen får inte innehålla motstridiga övergångar när objektet samtidigt kan gå in i två eller flera efterföljande tillstånd (förutom fallet med parallella matare). På UML-språket är eliminering av konflikter möjlig på grundval av införandet av vakthundar.

statyer (stat) Det är grundläggande inte bara i UML-språkmetamodel, utan även i tillämpad systemisk analys. Hela konceptet av det dynamiska systemet är baserat på konceptet. Semantiken i samma tillstånd i UML-språket har ett antal specifika egenskaper.

& NBSP & NBSP & NBSP & PSP i UML-språket under staten förstås som en abstrakt metaklass som används för att simulera en separat situation under vilken vissa villkor utförs. Staten kan anges som en uppsättning specifika värden för klass- eller objektattribut. Att ändra individuella attributvärden kommer att återspegla förändringen i tillståndet för den simulerade klassen eller objektet.

Aktivitetsdiagramdiagram

& NBSP & NBSP & PSP & NBSP När du modellerar det projicerade eller analyserade systemets beteende är det ett behov av att inte bara lämna in processen att ändra sina stater, utan också att detaljera funktionerna i det algoritmiska och logiska genomförandet av de utförda verksamheterna .

& Nbsp & nbsp & nbsp & nbsp den här typen Diagram kan användas för att återspegla staterna i det simulerade objektet, men huvudsyftet med aktivitetsdiagrammet är att återspegla objektets affärsprocesser. Denna typ av diagram gör att du kan visa inte bara sekvensen av processer, utan även förgrening och till och med synkronisering av processer.

& NBSP & NBSP & NBSP & NBSP Denna typ av diagram gör att du kan designa algoritmer för beteendet hos föremål för någon komplexitet, inklusive kan användas för att sammanställa flödesschema.

& NBSP & NBSP & NBSP & NBSP För att simulera processen att utföra operationer i UML-språket används aktivitetscheman. Den grafiska notationen som används i dem liknar i stor utsträckning av statens diagram, eftersom dessa diagram också är presentation av stater och övergångar. Varje stat i aktivitetsschemat motsvarar genomförandet av en viss elementär operation, och övergången till följande tillstånd utförs endast när denna operation är klar.

& NBSP & NBSP & NBSP & NBSP Således kan aktivitetscheman betraktas som ett speciellt fall av statliga diagram. De tillåter dem att genomföras i UML-språkfunktionerna i Procedural and Synchronous Management, på grund av slutförandet av interna aktiviteter och åtgärder. Huvudfokus för användningen av aktivitetsdiagram är att visualisera funktionerna i genomförandet av klasser, när algoritmerna av deras genomförande måste lämnas in.

& Nbsp & nbp & nbsp & nbsp i uml språk sammanhang aktivitet (Aktivitet) Det är en kombination av enskilda beräkningar som utförs av en maskingevär som leder till något resultat eller handling (åtgärd). På aktivitetsschemat visas logiken och sekvensen av övergångar från en aktivitet till en annan, och analytikens uppmärksamhet fokuserar på resultaten. Resultatet av aktiviteten kan leda till en förändring av systemstatus eller returnerar ett visst värde.

& Nbsp & nbsp & nbsp & nbsp Åtgärdsstatus (åtgärdsstatus) Det är ett speciellt fall av ett tillstånd med viss inmatningsåtgärd och, åtminstone ett övergångsuttag. Denna övergång antar implicit att ingångsåtgärden redan har slutförts. Åtgärdsstaten kan inte ha interna övergångar, eftersom det är elementärt. Normal användning Åtgärdstaterna ligger i modellering av ett steg i exekveringen av algoritmen (förfarandet) eller kontrollflöde.

Sekvensdiagram (sekvensdiagram)

& NBSP & NBSP & NBSP & NBSP När man överväger status- och aktivitetsdiagrammen noterades att även om dessa diagram används för att ange dynamiken i systemets beteende, är tiden explicit inte närvarande i dem. Tidsaspekten av beteende kan vara avgörande när man modellerar synkronprocesser som beskriver interaktionen mellan objekt. För att simulera interaktionen av objekt i tid i UML-språket används sekvensdiagram.

& Nbsp & nbsp & nbsp & nbsp Sekvensdiagrammet visar bara de föremålsom är direkt involverade i interaktionen. Nyckeln till sekvensdiagrammen är dynamiken för interaktion av objekt i tid.

& NBSP & NBSP & NBSP & NBSP i UML har sekvensdiagrammet två dimensioner. Den första vänstra rätten i form av vertikala linjer, som var och en avbildar livslinjen för ett separat föremål som är involverat i interaktionen. Den extrema kvar i diagrammet är en anläggning som är initiativtagaren till interaktionen. Det relevanta är det andra objektet, som direkt interagerar med den första. Således bildar alla objekt på sekvensdiagrammet någon order, definierad av sekvensen eller graden av aktivitet av objekt när de interagerar med varandra.

& Nbsp & nbsp & nbsp & nbsp grafiskt avbildas varje objekt av en rektangel och ligger högst upp i sin livsstil. Inuti rektangeln spelas namnet på objektet och klassnamnet separerat av kolon. Samtidigt betonas hela skivan, vilket är ett tecken på objektet.

& NBSP & NBSP & NBSP & NBSP Den andra mätningen av sekvensdiagrammet är den vertikala tidsaxeln riktad mot topp till botten. Det ursprungliga vridmomentet motsvarar den övre delen av diagrammet. Objektinteraktion implementeras av meddelanden som skickas till ett objekt till andra. Meddelanden är avbildade som en horisontella pilar med namnet på meddelandet, och deras order bestäms av förekomsttiden. Det vill säga meddelanden som finns på sekvensdiagrammet är högre, initierade innan de som finns nedan. Skalan på tidsaxeln indikeras inte, eftersom sekvensdiagrammet simulerar endast den tillfälliga interaktionsordningen av typen "tidigare".

Coopram av samarbete (samarbetsdiagram)

& NBSP & NBSP & NBSP & NBSP Huvuddragen i samarbetsdiagrammet ligger i förmågan att grafiskt representera inte bara sekvensen av interaktion utan också alla strukturella relationer mellan de föremål som är inblandade i denna interaktion.

Figur 3. Samarbetsdiagram

& NBSP & NBSP & NBSP & NBSP Denna typ av diagram gör att du kan beskriva interaktionen mellan objekt, abstrakt från meddelandeöverföringssekvensen. På denna typ av diagram återspeglar den kompakta formen alla mottagna och överförda meddelanden av ett visst objekt och typerna av dessa meddelanden.

NBSP & NBSP & NBSP & NBSP är främst i samarbetsdiagrammet i form av rektanglar, de objekt som innehåller objektets namn, dess klass och, eventuellt, attributvärdena är avbildade. Vidare, som i klassschemat, indikeras föreningar mellan objekt i form av olika anslutningslinjer. Samtidigt är det möjligt att uttryckligen ange namnen på föreningen och roller som föremålen spelar i den här föreningen. Dessutom kan dynamiska anslutningar avbildas - meddelandeflöden. De presenteras också i form av anslutningslinjer mellan föremål över vilka pilen är belägen som indikerar riktningen, meddelandets namn och sekvensnumret i den totala sekvensen av meddelandeinitialisering.

& NBSP & NBSP & NBSP & NBSP Till skillnad från sekvensdiagrammet är endast relationer mellan objekt som spelar vissa roller i interaktionen avbildade på samarbetsdiagrammet. Detta diagram anger inte tiden som en separat mätning. Därför kan sekvensen av interaktioner och parallella strömmar bestämmas med användning av sekvensnummer. Följaktligen, om det är nödvändigt att uttryckligen ange förhållandet mellan objekt i realtid, är det bättre att göra på sekvensdiagrammet.

& Nbsp & nbsp & nbp & nbsp koncept kooperativ (samarbete) Det är en av de grundläggande begreppen på UML-språket. Det tjänar till att referera till uppsättningen objekt som interagerar med ett visst syfte i det övergripande sammanhanget i det simulerade systemet. Syftet med samarbetet är att ange funktionerna i genomförandet av enskilda mest betydande verksamheter i systemet. Samarbetet definierar strukturen för systemets beteende när det gäller interaktionen mellan deltagarna i detta samarbete.

& NBSP & NBSP & NBSP & NBSP-samarbete kan representeras på två nivåer:

• specifikationsnivå - visar rollerna av klassificeringsmedel och föreningarnas roll i den aktuella interaktionen.
• exempelnivå - indikerar instanser och anslutningar som bildar separata roller i samarbete.

& Nbsp & nbsp & nbsp & nbsp Specification Sociation Diagram visar roller som spelar element som är involverade i interaktionen. Samarbetselementen på denna nivå är klasser och föreningar som utser vissa roller av klassificerare och föreningar mellan deltagare i samarbete.

& NBSP & NBSP & NBSP & NBSP Nivån på exempel på nivån av exempel verkar vara en uppsättning objekt (instanser av klasser) och anslutningar (instanser av föreningar). Samtidigt kompletteras förhållandet med meddelandepilarna. På denna nivå Endast objekt som är direkt relaterade till genomförandet av operationen eller klassificeraren visas. Samtidigt är det inte nödvändigt att avbilda alla egenskaper eller alla föreningar, eftersom endast klasserna av klassificatorer är närvarande på samarbetsschemat, men inte själva klassificeringarna. Således, medan klassificeringen kräver en fullständig beskrivning av alla sina kopior, kräver klassifierarens roll beskrivningar av endast de egenskaper och föreningar som är nödvändiga för att delta i ett separat samarbete.

& Nbsp & nbsp & nbsp & nbsp säger en viktig konsekvens härifrån. Samma totalitet av objekt kan delta i olika samarbeten. Beroende på det aktuella samarbetet kan det variera både egenskaperna hos enskilda föremål och förhållandet mellan dem. Detta är exakt vad som kännetecknas av ett diagram över samarbete från det klassschema som alla egenskaper och föreningar mellan elementen i diagrammet ska anges.

Komponentdiagram (komponentdiagram)

& NBSP & NBSP & NBSP & NBSP Denna typ av diagram är utformad för att distribuera klasser och föremål av komponenter i systemets fysiska design. Ofta kallas denna typ av diagram moduldiagram.

Figur - 4. Komponentdiagram

& NBSP & NBSP & NBSP & NBSP Det fullständiga projektet för mjukvarusystemet är en kombination av modeller av logiska och fysiska nivåer som måste överensstämma med varandra. På UML-språket används implementeringsdiagram för den fysiska presentationen av system, som innefattar att genomföra systemet (implementeringsdiagram), som inkluderar komponentdiagram och implementeringsschema.

& NBSP & NBSP & NBSP & NBSP Komponentdiagram, till skillnad från tidigare granskade diagram, beskriver särdragen i systemets fysiska representation. Det låter dig definiera arkitekturen i systemet som utvecklas genom att ställa in förhållandet mellan programkomponenterna, som kan fungera den ursprungliga och körbara koden. De huvudsakliga grafiska elementen i komponentdiagrammet är komponenter, gränssnitt och relationer mellan dem.

& NBSP & NBSP & NBSP & NBSP Component Diagram är utvecklat för följande ändamål:

• visualisering av den övergripande strukturen i källkoden för programvaran;
• specifikationer för den exekverbara versionen av programvaran;
• säkerställa flera användningen av enskilda programkodsfragment;
• representationer av konceptuella och fysiska databasscheman.

& NBSP & NBSP & NBSP & NBSP I utvecklingen av komponentdiagram deltar båda systemanalytikerna och arkitekterna och programmerarna. Komponentdiagrammet ger en konsekvent övergång från en logisk representation till ett specifikt projektimplementering i form av en programkod. Vissa komponenter kan bara existera i kompileringssteget i programkoden, andra på scenen i dess utförande. Komponentdiagrammet återspeglar det gemensamma förhållandet mellan komponenter, med tanke på de senare som klassificerare.

& NBSP & NBSP & NBSP & NBSP För presentation av fysiska enheter på UML-språket tillämpas en speciell term - komponent (komponent). Komponenten implementerar viss uppsättning gränssnitt och tjänar till att generellt beteckna elementen i den fysiska representationen av modellen. För grafisk representation av komponenten används en speciell symbol - en rektangel med vänster infört två mindre rektanglar. Inuti en stor rektangel registreras komponentens namn och, om det behövs, vissa ytterligare information. Bilden av denna symbol kan variera något beroende på vilken information som är associerad med informationskomponenten.

Deployment diagram (distributionsschema)

& NBSP & NBSP & NBSP & NBSP Denna typ av diagram är utformad för att analysera hårdvarusystemet, det vill säga "järn" och inte program. I direkt översättning från den engelska implementeringen betyder "utplacering", men termen "topologi" återspeglar mer exakt kärnan i denna typ av diagram.

Figur 5. Deployment diagram

& NBSP & NBSP & NBSP & NBSP Fysisk presentation av mjukvarusystemet kan inte vara fullständigt om det inte finns någon information om vilken plattform och på vilken datoranvändning Det implementeras. Om ett program som körs lokalt på en användares dator och inte använder kringutrustning och resurser utvecklas, så är det inte nödvändigt med utvecklingen av ytterligare diagram. När man utvecklar företagsapplikationer kan närvaron av sådana diagram vara extremt användbara för att lösa problemen med rationell placering av komponenter för att effektivt använda distribuerade datorer och kommunikationsnätverk, säkerhet och annat.

& NBSP & NBSP & NBSP & NBSP För att representera den allmänna konfigurationen och topologin för det distribuerade mjukvarusystemet i UML, är deplaceringsdiagrammen konstruerade.

& NBSP & NBSP & NBSP & NBSP Deployment Diagram är utformat för att visualisera elementen och komponenterna i det program som finns endast på scenen i dess utförande (körtid). Samtidigt är endast komponenter i förekomsterna av programmen exekverbara filer eller dynamiska bibliotek. De komponenter som inte används vid exekveringssteget visas inte på implementeringsschemat. Således kan komponenterna med källtexten av programmen vara närvarande endast på komponentdiagrammet. På distributionsdiagrammet anges de inte.

& NBSP & NBSP & NBSP & NBSP Deployment Diagram innehåller grafiska bilder av processorer, enheter, processer och anslutningar mellan dem. Till skillnad från logiska representationskartor är utplaceringsdiagrammet en för systemet som helhet, eftersom det fullt ut ska återspegla funktionerna i genomförandet. Utveckling av ett distributionschema är vanligtvis det sista steget i programvarans systemspecifikation.

& NBSP & NBSP & NBSP & NBSP När du utvecklar ett distributionsdiagram, följer följande mål:

• bestäm fördelningen av komponenterna i systemet i sina fysiska noder;
• visa fysiska anslutningar mellan alla noder av systemets genomförande på scenen av dess utförande;
• granska flaskhalsarna i systemet och omkonfigurera sin topologi för att uppnå önskad prestanda.

& NBSP & NBSP & NBSP & NBSP Deployment Charts utvecklas gemensamt av systemanalytiker, nätverksingenjörer och systemingenjörer.

Funktioner i det fungerande gränssnittet Rational Rose

& NBSP & NBSP & NBSP i Rational Rose Case-Tool, genomförs konventionella standarder på programmets arbetsgränssnitt, som liknar de kända visuella programmeringsmiljön. Efter att ha installerat rationella steg till användarens dator, som praktiskt taget inte orsakar svårigheter även på nybörjare, kommer lanseringen av detta program i MS Windows 95/98 att visas på skärmbilden för operativ gränssnitt (bild 6).

Figur 6. Allmän syn på det rationella rosationsgränssnittet

& NBSP & NBSP & NBSP & NBSP Working Interface Rational Rose består av olika element, vars huvudsakliga är:

• Huvudmenyn i programmet
• Fönsterdiagram
• Dokumentationsfönster
• Webbläsarfönster
• Fönstermagasin

Tänk kort på syftet och huvudfunktionerna för var och en av dessa föremål.

Huvudmenyn i programmet

Huvudmenyn i programmet är gjord i den allmänt accepterade standarden och har följande form (fig 7).

Separata menyalternativ, vars syfte är förståeligt från deras namn, kombinerar liknande verksamheter relaterade till hela projektet som helhet. Några av menyalternativen innehåller välkända funktioner (projektöppning, utmatningsdiagram, kopiering till en buffert och insats från buffert av olika diagramelement). Andra är så specifika att de kan kräva ytterligare insatser för att studera (mjukvarugenereringsalternativ, kontrollera modeller, anslutning av ytterligare moduler).

Figur 7. Extern bild av huvudmenyn i programmet

Standardverktygsfält

Standardverktygsfältet ligger under huvudmenyn i programmet och har följande formulär (bild 8). Några av verktygen är inte tillgängliga (det nya projektet har inga föremål). Standardverktygsfältet ger snabb åtkomst till menykommandon som utförs av utvecklarna oftast.

Figur 8. Utseende av standardverktygsfält

Användaren kan konfigurera utseendet på den här panelen efter eget gottfinnande. För att göra detta, välj alternativet Verktyg -\u003e Alternativ och öppna fliken Verktygsfält. På så sätt kan du visa eller dölja olika verktygsknappar, samt ändra storlek.

Webbläsarfönster

Standardwebbläsarfönstret är placerat på vänster sida av arbetsgränssnittet under standardverktygsfältet (bild 9).

Webbläsaren organiserar presentationen av modellen i form av en hierarkisk struktur som förenklar navigeringen och låter dig hitta något modellelement i projektet. Samtidigt visas varje element som utvecklaren lägger till modellen omedelbart i webbläsarfönstret. Följaktligen väljer vi ett objekt i webbläsarfönstret, vi kan visualisera det i diagramfönstret eller ändra specifikationen. Webbläsaren låter dig också organisera modellelement i förpackningar och flytta objekt mellan olika representationer av modellen. Om så önskas kan webbläsarfönstret placeras på annat håll i arbetsgränssnittet eller gömma alls med menyalternativet Visa (Visa). Du kan också ändra webbläsarens storlek, flytta musen med gränsen för dess yttre ram.

Figur 9. Yttre webbläsare

Specialverktygsfält

En specialverktygsfält ligger mellan webbläsarfönstret och diagrammets fönster i mitten av arbetsgränssnittet. Som standard föreslås verktygsfältet för att konstruera ett modellklasser diagram (fig 10).

Figur - 10. Utsikt över en speciell verktygsfält för klasser diagram

Platsen för den speciella verktygsfältet kan ändras genom att flytta panelramen till önskad plats. Du kan konfigurera panelens sammansättning genom att lägga till eller ta bort separata knappar som motsvarar miniatyrbilden. Du kan lära av popup-tips som visas efter muspekaren fördröjning över motsvarande knapp.

Fönsterdiagram

Diagramfönstret är det viktigaste arbetsområdet i sitt gränssnitt, där olika presentationer av projektmodellen visualiseras. Som standard är diagramfönstret placerat på höger sida av arbetsgränssnittet, men dess läge och dimensioner kan också ändras. När du utvecklar ett nytt projekt, om projektguiden inte användes, är diagramfönstret ett rent område som inte innehåller några modellelement (fig 11).

Diagrammets namn, som ligger i det här fönstret, anges i programhuvudlinjen (den högsta raden i programmet) eller, om fönstret inte används till hela skärmen, i huvudfältet i diagramfönstret . Samtidigt kan flera diagram vara närvarande i diagramfönstret, men bara en av dem kan vara aktiva. Till exempel i fig. 11 Aktiv är implementeringsschemat, även om det finns andra diagram. Växling mellan diagram kan väljas genom att välja önskad vy på standardverktygsfältet eller genom menyalternativet. När du aktiverar en separat typ av diagram ändras utseendet på en speciell verktygsfält, som är konfigurerat till en viss typ av diagram.

Figur - 11. Utsikt över diagramfönstret med olika typer av modellrepresentationer

Dokumentationsfönster

Fönstret Standarddokumentation kanske inte är närvarande på skärmen. I det här fallet kan den aktiveras via menyalternativet Visa-\u003e Dokumentation, varefter webbläsaren visas nedan (bild 12).

Dokumentationsfönstret, som följer av sitt namn, är utformat för att dokumentera modellrepresentationselementen. Den kan spelas in i den mest olika informationen, och vad är viktigt - på ryska. Denna information omvandlas därefter till kommentarerna och påverkar inte logiken i programkoden.

Dokumentationsfönstret aktiveras av den information som hänvisar till ett separat dedikerat element i diagrammet. Samtidigt är det möjligt att välja ett element antingen i webbläsarfönstret eller i fönstret Diagram. När du lägger till ett nytt element i diagrammet (till exempel klass) genereras dokumentationen för den automatiskt, vilket är tomt (ingen dokumentation). Därefter gör utvecklaren oberoende den nödvändiga förklarande informationen som kommer ihåg och kan ändras under arbetet med projektet.

Precis som för andra operativgränssnittsfönster kan du ändra storlek och placera dokumentationsfönstret.

Figur - 12. Utsikt över dokumentationsfönstret

Fönstermagasin

Logfönstret (Log) är avsedd för automatisk inspelning av olika officiella uppgifter som genereras under arbetet med programmet. Tidningen är fast och arten av den handlingsutvecklare som utvecklats av utvecklaren, till exempel uppdatering av modellen, inställning av menyn och verktygsfälten, såväl som felmeddelanden som härrör från generationskodgenerering.

Logfönstret är alltid närvarande på arbetsgränssnittet i diagrammets fönsterområde (bild 13). Det kan dock stängas av andra fönster med diagram eller minimeras. Du kan aktivera loggfönstret genom fönstret-\u003e loggmenyn (loggfönstret). I det här fallet är det avbildat ovanpå andra fönster i det rätta området för arbetsgränssnittet. Ta bort det här fönstret kan inte, det kan bara minimeras.

Figur - 13. Utsikt över magasinfönstret

Slutsats

& NBSP & NBSP & NBSP & NBSP Över tiden kommer UML-språket att vara "esperanto" -emotiverna, som kommer att kunna kommunicera matematik, systemanalytiker, fysik, programmerare, chefer, ekonomer och specialister av andra yrken, som presenterar deras professionell kunskap i en enhetlig form. Det är trots allt, i huvudsak, var och en av specialisterna modeller med modellidéer inom sitt kunskapsområde. Och det är den här modellaspekten som kan anges av UML-språket.

& NBSP & NBSP & NBSP & NBSP På grund av detta ökar värdet på UML-språket betydligt, eftersom det i allt högre grad förvärvar kunskapspresentationen. I det här fallet gör närvaron i UML-språket i det visuella sättet att representera modellens struktur och beteende det möjligt att uppnå en adekvat presentation av deklarativ och processuell kunskap och, inte mindre viktigt, att upprätta en semantisk efterlevnad mellan dessa former . Alla dessa funktioner i UML-språket gör det möjligt att dra slutsatsen att den har de allvarligaste utsikterna inom en snar framtid.

I den här artikeln beskrivs den nya eran av mjukvaruutvecklingen, om dess inverkan på de nya kraven fram till UML-språket och de optimala metoderna för deras utförande.
& Nbsp 7. "Data Modeling i Rational Rose" Sergey Trofimov beskriver simuleringen av den fysiska datapresentationen med hjälp av rationell ros
& Nbsp 8. UML-språk. Allmän syn på UML-språket: strukturer, grafiska element och språkdiagram.
& Nbsp 9. Praktisk UML. Detta dokument är översättningen av dokumentet "Praktisk UML. En hands-on introduktion för utvecklare". Praktisk introduktion för utvecklare
& Nbsp 10. "Standard språk av objektorienterad Modeling UML" Vendrov Alexander Mikhailovich. Historien om skapandet av UML.
& Nbsp 11. UML är ett enhetligt modelleringsspråk. Detta material innehåller initial information om metoderna för att beskriva mjukvarusystem och noteringar som används i UML
& Nbsp 12. UML-språk. Användarmanual. Författare: Grady Buch, James Rambo, Aivar Jacobson
& Nbsp 13. "UML-diagram i rationell ros" Sergey Trofimov
& Nbsp 14. "Analys och design. Visuell modellering (UML) Rationell Rose" Konstantin Domolegroup
& Nbsp 15. Bibliotek Gennady Vernikova. Fullständiga beskrivningar Design och modelleringsstandarder.
& Nbsp 16. "Ett exempel på att beskriva ämnesområdet med UML när du utvecklar mjukvarusystem" E.B. Zolotukhina, R.V. Alfimov. I artikeln om specifikt exempel Ett eventuellt tillvägagångssätt för modelleringen av ämnesområdet är baserat på tillämpningen av det enhetliga modelleringsspråket (Unified Modeling Language) (UML)

& Nbsp & nbsp & nbsp & nbsp

UML (Unified Modeling Språk - Unified Modeling Språk) - Grafisk Beskrivning Språk för objektmodellering i mjukvaruutveckling. UML är ett brett profilspråk, det är en öppen standard som använder grafisk notering för att skapa en abstrakt systemmodell som heter UML-modell. UML skapades för att bestämma, visualisering, design och dokumentation i de viktigaste mjukvarusystemen. UML är inte ett programmeringsspråk, men i utförandet av UML-modeller som en tolkbar kod är möjlig kodgenerering.Wikipedia

Kommersiella produkter

Microsoft Visio.

Typ: Kommersiell

Populär mjukvaruprodukt från Microsoft, som låter dig dra rika diagram, inklusive UML:

Från och med 2010-versionen var det möjligt att publicera diagram på webben (SharePoint + Visio-tjänster):

Visio Viewer.- Ett gratis program som låter dig bläddra i de tidigare skapade Visio-diagrammen. Du kan ladda upp i% 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% bc% d0% bc% d0% bc% d0% b5% d1% 80% d1% 87% d0% b5% d1% 81% d0% ba% d0% är% 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% d1% 80% d0% b5% d1% 80% d0% b5% d1% 80% % D1% 81% d0% b8% d1% 8f).

% 0a.

% D0% 92% 20% d0% bf% d0% är% d1% 81% d0% bb% d0% b5% d0% b4% d0% bd% d0% b5% d0% b9% 20% d0% b2% d0% 20% d0% b2% d0% % B5% D1% 80% D1% 81% D0% B8% D0% B8% 20microsoft% 20Visuell% 20Studio% 202010% 20% D0% BF% D0% B2% D0% B8% D0% B2% D0% B8% D0% B2% D0% B8% D0% % Bb% d1% 81% d1% 8f% 20% d0% bd% d0% är% d0% b2% d1% 8b% d0% b9% 20% d1% 82% d0% b8% d0% bf% 20% d0% d0% bf% 20% d0% % Bf% d1% 80% d0% är% d0% b5% d0% ba% d1% 82% d0% b0% 20-% 20modelling,% 20% d0% ba% d0% vara% d1% 82% d0% vara % D1% 80% d1% 8b% d0% b9% 20% d0% bf% d0% vara% d0% b7% d0% b2% d0% är% 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% B0% D0% B7% D0% B0% D0% B7% D0% % Bb% d0% b8% d1% 87% d0% bd% d1% 8b% d0% b5% 20uml% 20% d0% b4% d0% b3% d1% 80% d0% b3% d1% 80% d0% b3 % D0% bc% d0% bc% d0% b0% 20% d0% b8% 20% d0% bf% d1% 80% d0% är% d1% b2% d0% b5% d1% 80% d1% 8f% d1 % 82% d1% 8c% 20% d0% bd% d0% b0% d0% bf% d0% b8% d1% 81% d0% bll% d1% bd% d0% bd% d1% 8b% d0% b5% % D1% 80% d0% b5% d1% 88% d0% b5% d0% bd% d0% b8% d1% 8f% 20% d0% bd% d0% b0% 20% d1% 81% d0% är% d0% 81% 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% BL% 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% är% d0% b9.

% 0a.

% D0% 9F% D0% B2% D0% B7% 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% 20.220% 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% är% 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% är% d0% b5% d0% ba% d1% 82% d0% b5% 20% d0% bc% d0% b5% d1% b6% d0% b4% d1% 83% 20% d0% ba% d0% bc% d0% bc% d0% bf% d0% vara% d0% bd% d0% b5% d0% bd% dl% 82% d0% b8 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% 20USE% 20case% 20% d0% B4% D0% B3% D1% 80% D0% B3% D1% 80% % D0% b0% d0% bc% d0% bc% d1% 8b,% 20% d0% bd% d0% b0% d1% 80% d0% b8% d1% 81% d0% är% d0% b2% d0% B0% D0% BD% D0% BD% D0% BE% D0% B9% 20% D0% B2% 20Visuell% 20Studio% 202010:

% 0a% 0a

% D0% 9A% D1% 80% D0% B5% 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% 20 och% 20Modeling% 20Featur% 20Pack% 20 (% d0% B4% D0% BB% D1% 8F% 20% % D0% bf% d0% är% d0% b4% d0% bf% d0% b8% d1% 81% d1% 87% d0% b8% d0% ba% d0% är% d0% b2% 20msdn),% 20% b2% 20 msDN) % D0% ba% d0% är% d1% 82% d0% är% d1% 80% d1% 8b% d0% b9% 20% d0% bf% d0% vara% d0% b7% d0% b2% d0% % D0% bb% d1% 8f% d0% b5% d1% 82:

% 0a.

• % D0% b3% d0% b5% d0% bd% d0% b5% d1% 80% d0% b8% d1% 80% d0% är% d1% b2% d0% b0% dl% 82% d1% 8c% 20% 82% d1% 8c% % D0% ba% d0% var% d0% b4% 20% d0% bd% d0% b0% 20% d0% b1% d0% b0% d0% b7% d0% b5% 20um% 20% d0% b4% d0% 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% d1% 81% d1% 81% d0% % Vara% d0% b2
% 0a.
• % D1% 81% d0% är% d0% b7% d0% b4% d0% b0% d0% b2% d0% b0% d1% 82% d1% 8c% 20uml% 20% d0% b4% d0% b8% 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% är% d0% b4 % D0% b0
% 0a.
• % D0% b8% d0% bc% d0% bf% d0% är% d1% 80% d1% 82% d0% b8% d1% 80% d0% är% d0% b2% d1% 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% 20% d0% ba% d0% % Bb% d0% b0% d1% 81% d1% 81% d0% är% d0% b2,% 20% d0% b4% d0% b8% d1% b0% d0% b3% d1% 80% d0% b0% D0% bc% d0% bc% d1% 8b% 20% d0% bf% d0% är% d1% 81% d0% bb% d0% b5% d0% b2% d0% b0% D1% 82% d0% b5% d0% bb% d1% 8c% d0% bd% d0% är% 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% är% d0% b2% 20% d0% b8% d1% 81% d0% bf% d0% vara% d0% bb% d1% 8c% d0% b7% d0% % D0% b2% d0% b0% d0% bd% d0% b8% d1% 8f% 20% d1% 81% 20xmi% 202.1
% 0a.
• % D1% 81% d0% är% d0% b7% d0% b4% d0% b0% d0% b2% d0% b0% d1% 82% d1% 8c% 20% d0% b4% d0% b8% d0% b0% d0% b8% d0% b0% d0% b8% d0% b0% % D0% b3% d1% 80% d0% b0% d0% bc% d0% bc% d1% 8b% 20% d0% b7% d0% b0% d1% b2% d0% b8% d1% 81% d0% b8 % D0% bc% d0% är% 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% BO% D0% B2% D0% B5% D1% 80% Dl% 8F% D1% 82% Dl% 8C% 20Layer% 20Diagram% 20% D0% B4% D0% BB% D1% 8F% 20C% % 20% d0% b8% 20c ++% 20% d0% bf% d1% 80% d0% vara% d0% b5% d0% ba% d1% 82% d0% är% d0% b2
% 0a.
• % D0% bf% d0% b8% d1% 81% d0% b0% d1% 82% d1% 8c% 20% d1% 81% d0% är% d0% b1% d1% 81% d1% 82% d0% b2 % D0% b5% d0% bd% d0% bd% d1% 8b% d0% b5% 20% d0% bf% d1% 80% d0% är% d1% b2% d0% b5% d1% 80% d0% ba % D0% B8% 20% D0% B4% D0% BB% D1% 8F% 20Layer% 20Diagrams
% 0a.

% D0% a1% d0% ba% d0% b0% d1% 87% d0% b0% d1% 82% d1% 8c% 20Visualisering% 20 och% 20modell% 20Featur% 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/ru-ru/vstudio/f655021%28en-us%29.aspx.

IBM Rational Rose.

Förmågor:

• Använd falldiagram (prejudikatdiagram);
• Deployment Diagram (Topology Charts);
• Statechart Diagram (State Charts);
• Aktivitetsdiagram (Aktivitetsdiagram);
• Interaktionsdiagram (interaktionsdiagram);
• Sekvensdiagram (sekvensdiagram);
• Samarbetsschema (samarbetsdiagram);
• Klassschema (klasschema);
• Komponentdiagram (komponentdiagram).

Skärmdumpar:

Öppna källprogram

Staruml

Förmågor:

• stöd UML 2.0
• MDA (modelldriven arkitektur)
• Plug-in Architecture (Du kan skriva på COM-kompatibla språk: C ++, Delphi, C #, VB, ...)

Staruml är skrivet huvudsakligen på Delphi, men du kan lägga till komponenter på andra språk, till exempel C / C ++, Java, Visual Basic., Delphi, JScript, VBScript, C #, VB.Net. Följande visar flera skärmdumpar.

Klassdiagram:

Använd Case Chart:

Argouml

Stödda diagram:

• Klass
• stat
• Användningsfall
• Aktivitet
• Samarbete.
• Spridning.
• Sekvens

Förmågor:

• Stöd nio UML 1.4 diagram
• Plattform och beroende (Java 5+)
• Standard Metamodel UML 1.4
• XMI-stöd
• Export till GIF, PNG, PS, EPS, PGML och SVG
• Språk: SV, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
• Ocl support
• Framåt, omvänd teknik

Skärmdump: