Objektorienterad modellering av grafiska språk på hög nivå. Objektorienterat förhållningssätt till modellering av informationssystem

Handledning innehåller: sammanfattning UML-språket - den del av det som kan användas som grund för språket för modellering av komplexa dynamiska system; beskrivning och kapacitet för det föreslagna av författarna ett nytt modelleringsspråk baserat på hybridautomater, som är en förlängning av UML; historisk översikt och exempel på olika tillvägagångssätt för att designa modelleringsverktyg; objektorienterad analys av komplexa dynamiska system. Boken är den andra av tre böcker under den allmänna titeln System Modeling.

Behovet av ett enhetligt språk för att beskriva modeller.
Den traditionella tekniken för design av komplexa system, som inte involverar preliminär datormodellering, innefattar följande huvudsteg: formulering av krav för framtida system, utveckling av projektdokumentation på grundval av dem, skapande av en prototyp, testning av den för överensstämmelse med krav och stöd för en industriell design.

I det ideala fallet är en komplett funktionsspecifikation, utvecklad av systemanalytiker eller automatiskt med hjälp av datorteknik, redan en designlösning, det finns lite kvar - att bygga en fysisk modell enligt denna specifikation, som kommer att vara det designade systemet. Tyvärr är det inte så. Skapande verkliga systemet att överensstämma med de utvecklade funktionsspecifikationerna kräver kreativitet, inte formaliserad tekniska lösningar och manuellt arbete.

Även en till synes fullt formaliserad "mjuk del" av moderna tekniska system - inbäddad programvara - exekveras oftast på speciella inbäddade datorer eller mikroprocessorer med speciella utbyteskanaler, speciella operativsystem och andra funktioner som innebär "manuell" felsökning av den utvecklade programvaran. Utan detta "manuella", dåligt formaliserade, steg är det svårt att uppfylla de speciella kraven på tillförlitlig drift av systemet vid givna temperaturer, vibrationer, överbelastningar, strålningsnivåer, volym- och viktbegränsningar. Kapitel 5 diskuterar villkoren under vilka automatisk generering av fast programvara men funktionell specifikation är möjlig, och dessa villkor är fortfarande mycket långt ifrån dagens verklighet.

Innehållsförteckning
Innehållsförteckning
Förord
Kapitel 1. Objektorienterad metod för modellering
Behovet av ett enhetligt språk för att beskriva modeller
Klasser, instanser och flerkomponentsystem
Använda UML i den tidiga designfasen
Klassdiagram
Attribut
Beteende
Operationer och metoder
Abstrakta och konkreta klasser. Gränssnitt
Klasser och relationer
Förening
Generalisering
Aggregation
Arv
Polymorfism
Beteende. Tillståndsdiagram
Strukturerade klassificerare
Komponenter
Händelser och signaler
Paket
Modell
Kapitel 2. Objektorienterad modellering av komplexa dynamiska system baserade på formalismen hos en hybridautomat
Aktiv klass och aktivt dynamiskt objekt
Paket och modell
Använda passiva föremål
Variabler
Datatyper
Skalära typer
Riktig typ
Heltalstyper
boolesk typ
Uppräknade typer
Karaktärstyper
Vanliga typer
Vektorer
Matriser
Arrayer
Listor
Kombinerad typ (skriv)
Explicit definierade typer
Signaler
Automatisk typgjutning
Ekvationssystem
Beteendekarta
stater
Övergångar
Strukturplan
Föremål
Anslutningar
Regelbundna strukturer
Klassarv
Lägger till nya beskrivningselement
Åsidosätt ärvda föremål
Polymorfism
Parametriserade klasser
Kapitel 3. Modellering av hybridsystem och objektorienterat tillvägagångssätt i olika paket
Modellera hybridsystem i verktyg ah för "stora" datorer
SLAM II språk
NEDIS språk
Hybridmodeller i moderna modelleringsverktyg
Simulering av hybridsystem i Simulink-paketet ("blocksimulering")
Modellera hybridsystem i Modelica-språk ("fysisk modellering")
Hybrid riktning
Objektorienterade modelleringsspråk
Simula-67 och NEDIS
ObjectMath
Omola
Modelica
Blockmodelleringsverktyg
Analys av befintliga OOM-språk som används för att modellera komplexa dynamiska system
Kapitel 4. Flerobjektsmodeller
Kapitel 5. Objektorienterad modellering och objektorienterad analys
Komplext tekniskt system
Objektorienterad analys vid utveckling av komplexa tekniska system
Objektorienterad modellering i de efterföljande stadierna av utveckling och underhåll av komplex tekniskt system
Systemanalytisk modell som bas för "end-to-end" designteknik
Litteratur
Mer läsning för kapitel 1
Mer läsning för kapitel 2
Mer läsning för kapitel 3
Mer läsning för kapitel 4
Mer läsning för kapitel 5
Sakregister.

Gratis nedladdning e-bok i ett bekvämt format, titta och läs:
Ladda ner boken System Modeling, Object-Oriented Approach, Yu. Kolesov, Yu. Senichenkov, 2012 - fileskachat.com, snabb och gratis nedladdning.

Ladda ner pdf
Nedan kan du köpa den här boken på bästa pris med rabatt med leverans i hela Ryssland.

Transkript

1 Laborationer 4 "Metodologi för objektorienterad modellering" 1. Syfte med arbetet: Förtrogna med de grundläggande delarna av definition, representation, design och modellering mjukvarusystem använder UML-språket. 2. Metodiska instruktioner Laborationsarbetet syftar till att bekanta sig med de grundläggande delarna av definition, presentation, design och modellering av mjukvarusystem med hjälp av UML-språket, skaffa färdigheter i att använda dessa element för att bygga objektorienterade IS-modeller utifrån krav. Krav på utföranderesultat laboratorieverkstad: systemmodellen bör innehålla: ett diagram över användningsfall; interaktionsdiagram för varje användningsfall; ett klassdiagram som låter dig implementera alla beskrivna IS-funktioner; kombinerat komponentdiagram och placering för klasser för att indikera stereotyper; Beroende på uppdraget ska layoutdiagrammet visa var komponenterna är placerade i den distribuerade applikationen eller förhållandet mellan den inbäddade processorn och enheterna. 3. Allmän information om objektmodellering av IS Det finns många teknologier och verktyg som kan användas för att implementera, på ett sätt, en optimal IS-design, med början från analysstadiet och slutar med skapandet av systemets programkod. I de flesta fall ställer dessa teknologier mycket strikta krav på utvecklingsprocessen och de resurser som används, och försök att omvandla dem för specifika projekt misslyckas. Dessa teknologier representeras av CASE-verktyg högsta nivån eller CASE-verktyg för hela livscykeln (övre CASE-verktyg eller CASE-verktyg för hela livscykeln). De tillåter dig inte att optimera aktiviteter på nivån för enskilda delar av projektet, och som ett resultat har många utvecklare bytt till de så kallade lägre CASE-verktygen. Men de stod inför ett nytt problem, problemet med att organisera interaktionen mellan de olika teamen som genomför projektet. Unified Modeling Language (UML) är avvägningen mellan dessa tillvägagångssätt. Det finns tillräckligt med verktyg där ute för att stödja livscykeln med UML informationssystem, och samtidigt är UML tillräckligt flexibel för att anpassa och stödja specifikationerna för olika utvecklingsteams aktiviteter.

2 Skapandet av UML började i oktober 1994, när Jim Rambeau och Grady Booch från Rational Software Corporation började arbeta för att kombinera sina OMT- och Booch-metoder. För närvarande innehåller konsortiet av UML Partners användare representanter för sådana jättar inom informationsteknologi som Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology. UML är ett objektorienterat modelleringsspråk med följande huvudegenskaper: det är ett visuellt modelleringsspråk som tillhandahåller utveckling av representativa modeller för att organisera interaktion mellan en kund och en IS-utvecklare, olika grupper av IS-utvecklare; innehåller mekanismer för att utöka och specialisera språkets grundläggande begrepp. UML är standardnotationen för mjukvarusystem för visuell modellering som antogs av Object Managing Group (OMG) hösten 1997 och stöds nu av många objektorienterade CASE-produkter. UML inkluderar en intern uppsättning modelleringsverktyg som nu används i många modelleringstekniker och verktyg. Dessa koncept behövs i de flesta applikationer, även om inte alla koncept behövs i varje del av varje applikation. Användarna av språket ges följande möjligheter: att bygga modeller baserade på kärnfaciliteter, utan att använda förlängningsmekanismer för de flesta typiska applikationer; lägg till nya element och konventioner efter behov om de inte är en del av kärnan, eller specialisera komponenter, konventioner (notation) och domänspecifika begränsningar. UML-språk Fig. 1. En integrerad modell av ett komplext system i notationen av UML-språket UML-standarden erbjuder följande uppsättning diagram för modellering: användningsfallsdiagram för modellering av affärsprocesser i en organisation och krav för systemet som skapas); klassdiagram för modellering av systemklassernas statiska struktur och relationerna mellan dem;

3 beteendediagram: interaktionsdiagram: sekvensdiagram och samarbetsdiagram för modellering av meddelandeutbytet mellan objekt; tillståndsdiagram för att modellera beteendet hos systemobjekt under övergången från ett tillstånd till ett annat; aktivitetsdiagram för att modellera systemets beteende inom olika alternativ använda eller modellera aktiviteter; implementeringsdiagram: komponentdiagram för modellering av en hierarki av systemkomponenter (delsystem); distributionsdiagram för att modellera den fysiska arkitekturen för ett system. Use Case Diagram Konceptet med ett use case utvecklades av Ivar Jacobson och gavs sådan betydelse att use casen nu har blivit en central del av projektdesign och planering. Ett användningsfall är en sekvens av åtgärder (transaktioner) som utförs av systemet som svar på en händelse utlöst av någon extern enhet (aktör). Ett användningsfall beskriver en typisk interaktion mellan en användare och ett system. I det enklaste fallet bestäms användningsfallet genom diskussioner med användaren om vilken funktion de vill implementera. I UML-språket är användningsfallet avbildat enligt följande: Fig. 2. Use Case En aktör är den roll som användaren spelar i förhållande till systemet. Skådespelare representerar roller, inte specifika personer eller jobbtitlar. Även om de är avbildade som stiliserade mänskliga figurer i use-case diagram, kan skådespelaren också vara ett externt system som behöver lite information från det systemet. Visa tecken i diagrammet endast när de verkligen behöver några användningsfall. I UML-språket representeras tecknen i form av figurer: Fig. 3. Skådespelare (skådespelare) Karaktärerna är indelade i tre huvudtyper:

4 användare; system; andra system som interagerar med detta; tid. Tiden blir en aktör om lanseringen av några händelser i systemet beror på det. Relationer mellan användningsfall och aktörer I UML stöder use case-diagram flera typer av relationer mellan diagramelement. Dessa är kommunikation, inkludera, utöka och generalisering. En kommunikationslänk är länken mellan ett användningsfall och en aktör. I UML visas kommunikationslänkar med en enkelriktad association (heldragen linje). Fig. 4. Exempel på en kommunikationslänk En inkluderingslänk används i situationer där det finns ett systembeteende som upprepas i mer än ett användningsfall. Dessa länkar används ofta för att modellera återanvändbar funktionalitet. En förlängningsrelation används för att beskriva förändringar i ett systems normala beteende. Det tillåter ett användningsfall att bara använda funktionaliteten hos en annan när det behövs. Fig. 5. Exempel på ett inkluderings- och expansionsförhållande Med hjälp av ett generaliseringsförhållande visas att flera aktörer har likheter.

5 Fig. 6. Exempel på ett generaliseringsförhållande Interaktionsdiagram Interaktionsdiagram beskriver beteendet hos interagerande grupper av objekt. Vanligtvis täcker ett interaktionsdiagram beteendet hos objekt inom endast ett användningsfall. Ett sådant diagram visar ett antal objekt och de meddelanden som de utbyter med varandra. Ett meddelande är ett sätt genom vilket avsändarobjektet begär att mottagarobjektet ska utföra en av dess operationer. Ett informativt meddelande är ett meddelande som förser ett mottagarobjekt med viss information för att uppdatera dess tillstånd. Ett frågemeddelande är ett meddelande som begär leverans av viss information om mottagarobjektet. Ett imperativt meddelande är ett meddelande som ber mottagaren att vidta några åtgärder. Det finns två typer av interaktionsdiagram: sekvensdiagram och samarbetsdiagram. Sekvensdiagram Ett sekvensdiagram visar flödet av händelser som inträffar inom ett användningsfall. Alla skådespelare visas överst i diagrammet. Pilar motsvarar meddelanden som sänds mellan aktören och objektet, eller mellan objekt för att utföra de nödvändiga funktionerna. I ett sekvensdiagram ritas ett objekt som en rektangel med en vertikal streckad linje nedåt. Denna linje kallas objektets livlina. Det är ett fragment av ett objekts livscykel i interaktionsprocessen. Varje meddelande representeras som en pil mellan livslinjerna för två objekt. Meddelanden visas i den ordning de visas på sidan uppifrån och ned. Varje meddelande är taggat med åtminstone meddelandenamnet. Alternativt kan du lägga till argument och viss kontrollinformation också. Du kan visa ett självdelegeringsmeddelande som ett objekt skickar till sig själv, med meddelandepilen som pekar på samma livlina.

6 Fig. 7. Exempel på sekvensdiagram Samarbetsdiagram Samarbetsdiagram visar flödet av händelser genom ett specifikt användningsfallsscenario, ordnat efter tid, och samarbetsdiagram fokuserar mer på relationerna mellan objekt. Ett samverkansdiagram representerar all information som ett sekvensdiagram innehåller, men ett samarbetsdiagram beskriver flödet av händelser annorlunda. Det gör det lättare att förstå sambanden mellan objekt, däremot är det svårare att förstå händelseförloppet. I ett kooperativt diagram, som i ett sekvensdiagram, indikerar pilar meddelanden som utbytts inom ett givet användningsfall. Deras tidsföljd indikeras av numreringen av meddelandena.

7 Fig. 8. Exempel på ett samarbetsdiagram Klassdiagram Allmän information Ett klassdiagram definierar typerna av klasser i systemet och olika typer av statiska länkar som finns mellan dem. Klassdiagram visar också klassattribut, klassoperationer och begränsningar som gäller relationer mellan klasser. Ett UML-klassdiagram är en graf, vars noder är delarna av projektets statiska struktur (klasser, gränssnitt), och bågarna är relationerna mellan noderna (associationer, arv, beroenden). Klassdiagrammet visar följande element: Klasspaket (paket) - en uppsättning modellelement som är logiskt relaterade till varandra; Klass (klass) - en beskrivning av de allmänna egenskaperna hos en grupp liknande objekt; Gränssnitt är en abstrakt klass som definierar en uppsättning operationer som ett objekt av en godtycklig klass associerad med ett givet gränssnitt tillhandahåller till andra objekt. En klass är en grupp av entiteter (objekt) som har liknande egenskaper, nämligen data och beteende. En individuell representant för en klass kallas ett klassobjekt, eller helt enkelt ett objekt. Ett objekts beteende i UML förstås som alla regler för ett objekts interaktion med omvärlden och med själva objektets data. I diagrammen är klassen avbildad som en rektangel med en heldragen kant, uppdelad med horisontella linjer i 3 sektioner: Den övre sektionen (namnsektionen) innehåller klassnamnet och andra allmänna egenskaper (särskilt stereotypen). Den mellersta sektionen innehåller en lista med attribut. Den nedre sektionen innehåller en lista över klassoperationer som återspeglar dess beteende (åtgärder som utförs av klassen).

8 Någon av attribut- och operationssektionerna kanske inte visas (liksom båda). Inget behov av att rita för saknad sektion skiljelinje och på något sätt indikerar närvaron eller frånvaron av element i den. Ytterligare avsnitt, såsom undantag, kan införas efter eget gottfinnande av en viss implementering. Klassstereotyper Fig. 9. Klassdiagram Exempel Klassstereotyper är en mekanism som låter dig kategorisera klasser. UML definierar tre grundläggande klassstereotyper: Gräns; Entitet Kontrollera. Gränsklasser Gränsklasser är klasser som ligger vid gränsen för systemet och hela miljö... Detta skärmformulär, rapporter, gränssnitt till hårdvara (som skrivare eller skannrar) och gränssnitt till andra system. För att hitta gränsklasserna måste du undersöka use case-diagrammen. Varje interaktion mellan aktören och användningsfallet måste matchas av åtminstone, en gränsklass. Det är denna klass som tillåter till skådespelaren interagera med systemet. Entitetsklasser Entitetsklasser innehåller lagrad information. De är av största vikt för användaren och därför använder de ofta termer från ämnesområdet i sina namn. Vanligtvis skapas en tabell i databasen för varje entitetsklass. Kontrollklasser

9 Kontrollklasser ansvarar för att samordna andra klassers agerande. Vanligtvis har varje användningsfall en kontrollklass som styr händelseförloppet för det användningsfallet. Den kontrollerande klassen ansvarar för koordineringen, men den har ingen funktion i sig, eftersom de andra klasserna inte skickar många meddelanden till den. Istället skickar han många meddelanden själv. Chefsklassen delegerar helt enkelt ansvaret till andra klasser, av denna anledning kallas den ofta för chefsklassen. Det kan finnas andra kontrollklasser i systemet som är gemensamma för flera användningsfall. Till exempel kan det finnas en SecurityManager-klass som är ansvarig för att övervaka säkerhetshändelser. Klassen TransactionManager ansvarar för att koordinera meddelanden relaterade till databastransaktioner. Det kan finnas andra chefer att arbeta med andra delar av systemets funktion, såsom resursdelning, distribuerad bearbetning data eller felhantering. Förutom stereotyperna som nämns ovan kan du skapa din egen. Attribut Ett attribut är en del information som är kopplad till en klass. Attribut lagrar inkapslade klassdata. Eftersom attributen finns i klassen är de dolda från andra klasser. Därför kan du behöva ange vilka klasser som får läsa och ändra attribut. Den här egenskapen kallas attributsynlighet. Ett attribut kan ha fyra möjliga värden för denna parameter: Public. Detta synlighetsvärde förutsätter att attributet kommer att vara synligt för alla andra klasser. Alla klasser kan visa eller ändra värdet på attributet. I UML-notation föregås det gemensamma attributet av ett "+"-tecken. Privat (stängd, hemlig). Motsvarande attribut är inte synligt för någon annan klass. Ett privat attribut betecknas med ett tecken i enlighet med UML-notationen. Skyddad Ett sådant attribut är endast tillgängligt för klassen själv och dess avkomlingar. UML-notationen för ett skyddat attribut är tecknet "#". Paket eller implementering Förutsätter att det här attributet är generiskt, men bara inom dess paket. Denna typ av synlighet indikeras inte av någon speciell ikon. I allmänhet rekommenderas det att göra attribut privata eller skyddade. Detta möjliggör bättre kontroll över själva attributet och koden. Med hjälp av slutenhet eller säkerhet är det möjligt att undvika en situation då värdet på ett attribut ändras av alla klasser i systemet. Istället kommer logiken för att modifiera ett attribut att lindas in i samma klass som själva attributet. Synlighetsparametrarna du ställer in kommer att påverka den genererade koden. Operations Operations implementerar klassrelaterat beteende. En operation har tre delar: namn, parametrar och returtyp. Parametrar är argument som tas emot av "på"-operationen. Returtypen hänvisar till resultatet av operationens åtgärd.

10 I ett klassdiagram kan du visa både namnen på operationerna och namnen på operationerna tillsammans med deras parametrar och returtyp. För att minska arbetsbelastningen för diagrammet är det användbart att endast visa namnen på operationer på vissa av dem och på andra deras fullständiga signatur. I UML har operationer följande notation: Operationsnamn (argument: argumentdatatyp, argument2: argumentdatatyp, ...): returtyp Det finns fyra olika typer av operationer att beakta: Implementeringsoperationer; Kontrolloperationer; Åtkomstverksamhet; Hjälpoperationer. Implementeringsverksamhet Implementeringsverksamhet implementerar vissa affärsfunktioner. Sådana operationer kan hittas genom att undersöka interaktionsdiagram. Diagram av denna typ fokuserar på affärsfunktioner, och varje meddelande i diagrammet kan med största sannolikhet associeras med en implementeringsoperation. Varje implementeringssteg måste lätt kunna spåras till motsvarande krav. Detta uppnås i olika skeden av simuleringen. Aktivitet härleds från ett meddelande i ett interaktionsdiagram, meddelanden härleds från detaljerad beskrivning ett händelseflöde som genereras utifrån användningsfallet och det senare utifrån krav. Möjligheten att spåra hela denna kedja säkerställer att varje krav implementeras i kod, och varje kod implementerar ett krav. Chefsoperationer Chefsoperationer styr skapandet och förstörelsen av objekt. Klasskonstruktörer och destruktörer tillhör denna kategori. Access Operations-attribut är vanligtvis privata eller skyddade. Men andra klasser behöver ibland se eller ändra sina värden. Det finns åtkomstoperationer för detta. Detta tillvägagångssätt gör det möjligt att säkert kapsla in attribut inom en klass, skydda dem från andra klasser, men tillåter fortfarande kontrollerad åtkomst till dem. Det är standardpraxis att skapa Get and Set-operationer för varje klassattribut. Hjälparoperationer Hjälpoperationer är de operationer i en klass som den behöver för att uppfylla sitt ansvar, men som andra klasser inte behöver veta något om. Dessa är privata och skyddade verksamheter i klassen. Kör för att identifiera transaktioner följande åtgärder: 1. Utforska sekvensdiagram och kooperativa diagram. De flesta av meddelandena i dessa diagram är implementeringsaktiviteter. Reflekterande meddelanden kommer att vara hjälpoperationer.

11 2. Överväg kontrolloperationer. Du kan behöva lägga till konstruktörer och förstörare. 3. Överväg åtkomstoperationer. För varje klassattribut som andra klasser kommer att behöva arbeta med måste du skapa Get and Set-operationer. Relationer En relation är en semantisk relation mellan klasser. Det gör det möjligt för en klass att lära sig om attribut, operationer och relationer för en annan klass. Med andra ord, för att en klass ska kunna skicka ett meddelande till en annan i ett sekvensdiagram eller ett kooperativt diagram, måste det finnas en relation mellan de två. Det finns fyra typer av relationer som kan upprättas mellan klasser: associationer, beroenden, aggregationer och generaliseringar. Associationer En association är en semantisk relation mellan klasser. De är ritade i klassdiagrammet som en vanlig linje. Ris. 10. Association Association Associations kan vara dubbelriktade, som i exemplet, eller enkelriktade. I UML ritas dubbelriktade associationer som en enkel linje utan pilar eller med pilar på vardera sidan. På en enkelriktad association är endast en pil avbildad som visar dess riktning. Föreningens riktning kan bestämmas genom att undersöka sekvensdiagram och kooperativa diagram. Om alla meddelanden till dem skickas av endast en klass och tas emot endast av en annan klass, men inte vice versa, sker en enkelriktad relation mellan dessa klasser. Om minst ett meddelande sänds i motsatt riktning måste kopplingen vara dubbelriktad. Associationer kan vara reflekterande. Reflexiv association antar att en instans av en klass interagerar med andra instanser av samma klass. Beroenden Beroenderelationer återspeglar också förhållandet mellan klasser, men de är alltid enkelriktade och visar att en klass beror på definitionerna i den andra. Till exempel, klass A använder metoder för klass B. Sedan, när klass B ändras, är det nödvändigt att göra motsvarande ändringar i klass A. början av denna pil.

Fig. 12 11. Relationsberoende Vid generering av kod för dessa klasser kommer inga nya attribut att läggas till dem. Däremot kommer de språkspecifika uttalanden som krävs för att stödja kommunikationen att genereras. Aggregationer Aggregationer är en stramare associationsform. Aggregation är sambandet mellan helheten och dess del. Du kan till exempel ha en klass för bil, samt klasser för motor, däck och klasser för andra delar av bilen. Som ett resultat kommer ett objekt av klassen Bil att bestå av ett objekt av klassen Motor, fyra objekt av Däck, etc. Aggregeringar visualiseras som en linje med en diamant för en klass som är en helhet: Fig. 11. Relationsaggregation Förutom enkel aggregation introducerar UML en starkare form av aggregation som kallas komposition. Enligt kompositionen kan en föremålsdel bara tillhöra en enda helhet, och dessutom sammanfaller som regel delars livscykel med helhetens cykel: de lever och dör med den. Varje borttagande av helheten sträcker sig till dess delar. Denna kaskadradering ses ofta som en del av definitionen av aggregering, men det är alltid underförstått när mångfalden av roller är 1...1; till exempel, om det är nödvändigt att ta bort en kund, måste denna radering gälla för beställningar (och i sin tur för beställningsrader). Generaliseringar (arv) Generalisering (arv) är ett offentligt-privat förhållande mellan modellelement. Använd generalisering och visa arvsförhållandet mellan två klasser. De flesta objektorienterade språk stöder direkt begreppet arv. Det tillåter en klass att ärva alla attribut, operationer och relationer från en annan. Paketarv innebär att i ett ärvt paket kommer alla enheter i det överordnade paketet att vara synliga under sina egna namn (dvs. namnområden slås samman). Arv visas med en heldragen linje som går från ättlingklassen till anfaderklassen (i OOP-terminologi - från ättling till förfader, från son till far eller från underklass till superklass). En stor ihålig triangel dras från sidan av det mer allmänna elementet.

Fig. 13 12. Exempel på en arvsrelation Förutom arv har varje underklass sina egna unika attribut, operationer och relationer. Multiplicity Multiplicity anger hur många instanser av en klass som interagerar genom detta förhållande med en instans av en annan klass vid en given tidpunkt. Om du till exempel utformar ett kursregistreringssystem vid ett universitet kan du definiera klasserna Kurs och Student. En koppling har upprättats mellan dem: kurser kan ha studenter och studenter kan ha kurser. Frågor som ska besvaras av multiplicitetsparametern: ”Hur många kurser kan en student gå för tillfället? Hur många elever kan ta en kurs åt gången?" Eftersom mångfald ger svaret på båda dessa frågor, är dess indikatorer installerade i båda ändarna av kommunikationslinjen. I kursregistreringsexemplet bestämde vi att en student kan gå noll till fyra kurser och en kurs kan gå av 0 till 20 studenter. UML använder vissa notationer för att beteckna pluralitet. Tabell 1 - UML-beteckningar för flera relationer Relationsnamn Relationer kan kvalificeras med relationsnamn eller rollnamn. Ett länknamn är vanligtvis ett verb eller verbfras som beskriver varför det behövs. Till exempel kan det finnas en koppling mellan klassen Person och klassen Företag. I detta avseende kan du ställa frågan om föremålet för klassen Person är en kund till företaget, dess

14 anställd eller ägare? För att definiera detta kan föreningen kallas "anställer": Roller Fig. 13. Exempel på relationsnamn Rollnamn används i associations- eller aggregeringsrelationer istället för namn för att beskriva varför relationen behövs. För att återgå till exemplet med klasserna Person och Företag, agerar klassen Person som en anställd i företagsklassen. Rollnamn är vanligtvis substantiv eller fraser baserade på dem, och de visas i diagrammet bredvid klassen som spelar motsvarande roll. Vanligtvis används antingen rollnamnet eller associationsnamnet, men inte båda. Liksom relationsnamn är rollnamn valfria och ges endast om syftet med relationen inte är uppenbart. Ett exempel på roller ges nedan: Paket. Paketmekanism Fig. 14. Exempel på relationsroller I samband med klassdiagram är ett paket en behållare för en uppsättning klasser och andra paket. Paketet är ett eget namnområde. Ris. 15. Paketbeteckning i UML Det finns inga begränsningar i UML på reglerna för vilka utvecklare kan eller bör gruppera klasser i paket. Men det finns vissa standardfall där en sådan gruppering är lämplig, såsom tätt interagerande klasser, eller det mer allmänna fallet att dela upp ett system i delsystem. Ett paket innehåller fysiskt de entiteter som definieras i det (det sägs att "entiteter tillhör paketet"). Det betyder att om ett paket förstörs kommer allt innehåll att förstöras. Det finns flera vanliga metoder för gruppering. Först kan du gruppera dem efter stereotyp. I det här fallet får du ett paket med entitetsklasser, ett med gränsklasser, ett med hantering av klasser, etc. Detta tillvägagångssätt kan vara användbart när det gäller att vara värd för det färdiga systemet, eftersom alla gränsklasser på klientdatorerna redan finns i samma paket.

15 Ett annat tillvägagångssätt är att kombinera klasser efter deras funktionalitet. Säkerhetspaketet innehåller till exempel alla klasser som är ansvariga för att säkra en applikation. I det här fallet kan de andra paketen kallas för personalunderhåll, rapportering och felhantering. Fördelen med detta tillvägagångssätt är dess återanvändbarhet. Paketmekanismen är tillämplig på alla modellelement, inte bara klasser. Om någon heuristik inte används för att gruppera klasserna, blir det godtyckligt. En som mest används i UML är beroende. Det finns ett beroende mellan två paket om det finns ett beroende mellan två klasser i paketen. Således är ett paketdiagram ett diagram som innehåller paket med klasser och beroenden mellan dem. Strängt taget är paket och beroenden delar av ett klassdiagram, det vill säga ett paketdiagram är en form av ett klassdiagram. Ris. 16. Exempel på ett paketdiagram Ett beroende mellan två element uppstår när ändringar i definitionen av ett element kan leda till ändringar i det andra. För klasser kan orsakerna till beroenden vara mycket olika: en klass skickar ett meddelande till en annan; en klass inkluderar en bit data från en annan klass; en klass använder den andra som en operationsparameter. Om en klass ändrar sitt gränssnitt kan alla meddelanden den skickar förlora sin giltighet. Paketen ger inget svar på frågan om hur du kan minska antalet beroenden i ditt system, men de hjälper till att isolera dessa beroenden och efter att de alla är i sikte återstår bara att arbeta med att minska antalet. Paketdiagram kan betraktas som huvudkontrollen övergripande struktur system. Paket är ett viktigt verktyg för stora projekt. De bör användas i de fall då ett klassdiagram som täcker hela systemet och placerat på ett enda A4-papper blir oläsligt. Tillståndsdiagram Tillståndsdiagram definierar alla möjliga tillstånd där ett visst objekt kan befinna sig, såväl som processen att ändra ett objekts tillstånd som ett resultat av att vissa händelser inträffar. Det finns många former av tillståndsdiagram med lite olika semantik. Det finns två specialtillstånd i diagrammet: start och stopp. Det initiala tillståndet är markerat med en svart prick, det motsvarar objektets tillstånd,

16 när den precis skapades. Sluttillståndet indikeras av en svart prick i en vit cirkel, den motsvarar objektets tillstånd precis innan dess förstörelse. Det kan finnas ett och endast ett initialtillstånd i ett tillståndsdiagram. Samtidigt kan det finnas så många sluttillstånd som du behöver, eller så finns det inga alls. När ett objekt är i ett specifikt tillstånd, olika processer... Processer som uppstår när ett objekt är i visst tillstånd kallas handlingar. Det finns fem typer av data som du kan associera med ett tillstånd: aktivitet, ingångsåtgärd, utdataåtgärd, händelse och tillståndshistorik. Aktivitet En aktivitet är beteendet som ett objekt implementerar medan det är i ett givet tillstånd. Aktivitet är ett avbrutet beteende. Det kan exekveras tills det är färdigt, medan objektet är i detta tillstånd, eller det kan avbrytas av objektets övergång till ett annat tillstånd. Aktiviteten avbildas inom själva staten, den måste föregås av ordet do och ett kolon. Entry action En entry action är det beteende som exekveras när ett objekt går in i ett givet tillstånd. Denna åtgärd utförs inte efter att objektet har hamnat i detta tillstånd, utan snarare som en del av denna övergång. Till skillnad från aktivitet anses inmatningsåtgärden vara oavbruten. Inmatningsåtgärden visas också inom staten, föregås av ordet inmatning och ett kolon. Exit Action Exit-åtgärden liknar ingången. Det utförs dock som en integrerad del av processen att ta sig ur detta tillstånd. Det är en del av övergångsprocessen. Liksom ingångsåtgärden är utgångsåtgärden icke-avbrytbar. Exithandlingen avbildas inom staten, föregås av ordet exit och ett kolon. Ett objekts beteende under en aktivitet, under inmatnings- och utmatningsåtgärder, kan inkludera att en händelse skickas till ett annat objekt. I det här fallet föregås beskrivningen av aktiviteten, inmatningsåtgärden eller utdataåtgärden av ett "^"-tecken. Motsvarande rad i diagrammet ser ut som Gör: ^ Target.Event (Arguments) Här är Target objektet som tar emot händelsen, Event är meddelandet som ska skickas och Arguments är parametrarna för meddelandet som ska skickas. En aktivitet kan också utföras som ett resultat av att en händelse tas emot av ett objekt. När en viss händelse tas emot utförs viss aktivitet. Övergång syftar på att flytta från ett tillstånd till ett annat. Uppsättningen av diagramövergångar visar hur ett objekt kan röra sig mellan dess tillstånd. I diagrammet är alla övergångar avbildade som en pil som börjar vid initialtillståndet och slutar med nästa.

17 Övergångar kan vara reflekterande. Objektet kan gå till samma tillstånd som det för närvarande befinner sig i. Reflexiva övergångar avbildas som pilar som börjar och slutar i samma tillstånd. Övergången har flera specifikationer. Dessa inkluderar händelser, argument, omslutande villkor, åtgärder och skickade händelser. Händelser En händelse är det som orsakar en övergång från ett tillstånd till ett annat. Händelsen placeras på diagrammet längs övergångslinjen. I ett diagram kan du använda antingen operationsnamnet eller en vanlig fras för att visa en händelse. De flesta övergångar måste ha händelser, eftersom det är de som gör att övergången sker i första hand. Men det finns också automatiska övergångar som inte har händelser. I det här fallet förflyttas själva objektet från ett tillstånd till ett annat med en hastighet som tillåter implementering av ingångsåtgärder, aktiviteter och utgångsåtgärder. Vaktförhållanden Vaktförhållanden definierar när en övergång kan och när den inte kan inträffa. Annars kommer övergången att misslyckas. De omslutande villkoren plottas längs övergångslinjen efter händelsenamnet och omsluter dem inom hakparenteser. Det är valfritt att ställa in omslutningsvillkoren. Men om det finns flera automatiska tillståndsövergångar måste du definiera ömsesidigt uteslutande omslutande villkor för dem. Detta kommer att hjälpa läsaren av diagrammet att förstå vilken övergångsväg som väljs automatiskt. Handling En handling, som diskuterats, är ett icke-avbrottsbart beteende som uppstår som en del av en övergång. Inmatnings- och utmatningsåtgärder visas inom tillstånd när de bestämmer vad som händer när ett objekt går in i eller lämnar det. De flesta av åtgärderna är dock avbildade längs övergångslinjen, eftersom de inte bör utföras när man går in i eller ut ur ett tillstånd. Åtgärden ritas längs övergångslinjen efter händelsenamnet, föregås av ett snedstreck. En händelse eller handling kan vara ett beteende inom ett objekt, eller det kan vara ett meddelande som skickas till ett annat objekt. Om en händelse eller åtgärd skickas till ett annat objekt, placeras ett ^ framför det i diagrammet.

Fig. 18 17. Exempel på Statechart Statecharts behöver inte skapas för varje klass, de används bara i komplexa fall. Om ett objekt i en klass kan existera i flera tillstånd och bete sig olika i var och en av dem, kan ett sådant diagram krävas för det. Distributionsdiagram Ett distributionsdiagram visar de fysiska relationerna mellan mjukvaran och hårdvarukomponenterna i ett system. Hon är bra botemedel för att visa rörelsevägarna för objekt och komponenter i ett distribuerat system. Varje nod i layoutdiagrammet representerar någon typ av datorenhet, i de flesta fall en hårdvara. Denna hårdvara kan vara en enkel enhet eller sensor, eller det kan vara en stordator. Placeringsdiagrammet visar den fysiska platsen för nätverket och dess placering olika komponenter... Ris. 19. Exempel på layoutdiagram Ett layoutdiagram används av projektledaren, användarna, systemarkitekten och driftpersonalen för att förstå den fysiska layouten av ett system och platsen för dess individuella delsystem.

19 Komponentdiagram Komponentdiagram visar hur modellen ser ut i det fysiska lagret. De skildrar mjukvarukomponenter och relationerna mellan dem. Samtidigt särskiljs två typer av komponenter på ett sådant diagram: körbara komponenter och kodbibliotek. Varje modellklass (eller delsystem) konverteras till en komponent källkod... När de väl har skapats läggs de omedelbart till i komponentdiagrammet. Beroenden skildras mellan enskilda komponenter, motsvarande beroenden vid kompileringstidpunkten eller programexekveringen. Ris. 18. Exempel på komponentdiagram Komponentdiagram används av de projektdeltagare som ansvarar för att sammanställa systemet. Den visar i vilken ordning komponenterna ska kompileras, samt vilka körbara komponenter som kommer att skapas av systemet. Detta diagram visar överensstämmelsen mellan klasserna och de implementerade komponenterna. Det behövs där kodgenerering börjar. Kombinera komponent- och distributionsdiagram I vissa fall kanske du vill placera ett komponentdiagram i ett distributionsdiagram. Detta låter dig visa vilka komponenter som körs och på vilka noder. 4. Tillvägagångssätt för att utföra arbetet 1. Studera det föreslagna teoretiska materialet. 2. Bygg ett användningsfallsdiagram för det valda informationssystemet. 3. Implementera användningsfallet i termer av interagerande objekt och är en uppsättning diagram: klassdiagram som implementerar användningsfallet; interaktionsdiagram (sekvensdiagram eller kooperativa diagram) som representerar interaktionen mellan objekt under implementeringen av ett användningsfall. 4. Dela upp klasser i paket med hjälp av en av uppdelningsmekanismerna.

20 5. Bygg ett tillståndsdiagram för specifika objekt i informationssystemet. 6. Bygg en rapport som inkluderar alla erhållna nivåer av modellen, en beskrivning av funktionsblock, dataströmmar, lagringar och externa objekt.

FEDERAL AGENCY FOR EDUCATION KEMEROVSK STATE UNIVERSITY UNESCO-ordförande i New Information Technologies A.M. Gudov, S.Yu. Zavozkin, S.N. Trofimov TEKNOLOGI PROGRAMVARUUTVECKLING

Metodinstruktioner för att utföra beräknings- och grafiskt arbete. Syfte med arbetet: Förtrogna med huvudelementen i definition, presentation, design och modellering av informationssystem med hjälp av

GRUNDLÄGGANDE INFORMATION OM UML-VERKTYG UML Unified Language UML-modellering(Unified Modeling Language) är ett språk för att definiera, representera, designa och dokumentera programvara

4 Unified Modeling Language (UML) diagram i UML. Klasser och klassstereotyper. Associativa klasser. Huvudelementen i interaktionsdiagram är objekt, meddelanden.

Föreläsning 2.1 UML-språket. Användningsfallsdiagram 1. UML-innehåll 2. Användningsfallsdiagram Användningsfall Aktörer Relation 3. Exempel Användningsfall Diagram Grafik

Federal Agency for Railway Transport, en gren av den federala statens budgetutbildande institution för högre yrkesutbildning"Sibirisk State University

CASE-teknik Föreläsning 5 1 UML:en: Typer av diagram UML 1.5 definierade tolv typer av diagram, uppdelade i tre grupper: fyra typer av diagram representerar den statiska strukturen för en applikation; fem representerar

Kapitel 1. Förstå UML Det bästa verktyget är ett stort diagram fäst på väggen. Doug Scott 1.1. Mål och historik för skapandet av UML-språket Unified modeling language UML (Unified

12_Stages av IS-design med UML Huvudtyperna av UML-diagram som används vid design av informationssystem. Relationer mellan diagram. UML-stöd för iterativ designprocess

Sammanfattning om UML-språket Sammanställt av E.A. Leichenok gr. 521701 Unified Modeling Language (UML) är ett grafiskt språk för visualisering, specifikation, design

Labb 1 "Use Case Diagram" Innehållsförteckning Förstå UML ... 3 Usecase Diagram ... 6 Use Case ... 7 Skådespelare ... 7 Gränssnitt ...

Föreläsning 3, del 6: Element i den grafiska notationen av ett komponentdiagram Annotation: Syftet med ett komponentdiagram, dess huvudelement. Funktioner i den fysiska representationen av mjukvarusystem. Komponenter

Labbaktivitetsdiagram över användningsfall Mål: Förtrogenhet med de grundläggande begreppen i UML 2. Förtrogenhet med Rational Rose-modelleringsmiljön 3. Utforska komponenterna i modellen 4. Bygga

FEDERAL STATE BUDGETARISK UTBILDNINGSINSTITUT FÖR HÖGRE UTBILDNING STAVROPOL STATE AGRARIAN UNIVERSITY Ekonomiska fakulteten Institutionen för informationssystem GODKÄNT

UML-diagram Klassdiagram (2) Use case-diagram (22) Aktivitetsdiagram (35) Interaktionsdiagram (51) Klassdiagram En klass är en kategori av saker som har gemensamma attribut och

Diagram över interaktion mellan objekt i UML Denna artikel diskuterar i detalj samarbetsdiagrammet och sekvensdiagrammet

CASE-teknologier Föreläsning 4 1 UML: förhistoria mitten av 1970-talet slutet av 1980-talet Framväxten och uppgången av objektorienterad design (OOP) "Method War"-design i mitten av 1990-talet

Föreläsning 3 del 2: Relationer och deras grafiska representation på ett klassdiagram Nyckelord: UML, association, associationsrelation, generalisering, generaliseringsrelation, aggregering, sammansättning, presentation,

Föreläsning 3 del 4 Delar av diagrammets grafiska notation Kommentar: Syftet med diagrammet. Objekt, deras grafiska representation. Livslinje och fokus för ledningen. Funktioner i bilden av skapelseögonblicken

ObAn och PRS Föreläsning 1 sida 1 av 7 UML-standardens grafiska primitiver Paradigmer för UML-standarden A Språklexikon B Regler över ordboken C Mekanismer Språkvokabulär Entiteter Beteendeenheter Gruppering

Laborationer 2 "Klassdiagram" Innehållsförteckning Allmänt koncept... 3 Klass ... 3 Attribut ... 4 Operation ... 6 Relation Between Classes ... 7 Beroenderelation ... 7 Associationsrelation ... 8 Relation

Labb 3 "Tillstånds- och aktivitetsdiagram" Innehållsförteckning STÄLLSDIAGRAM ... 3 Allmänt koncept ... 3 Tillstånd ... 4 Övergång ... 6 Sammansatta tillstånd och deltillstånd ... 8 Exempel på diagram

Objektorienterad analys och design Copyright Mukhortov V. V., Nianchuk-Tatarsky N. A., 2001-2004 Copyright LLC "Intex", 2003-2004 Klasser Klass är en uppsättning objekt med en gemensam struktur och beteendegränssnitt

LABORATORIUM 4 UTVECKLA EN FYSISK REPRESSENTATION AV PROGRAMVARANS DRIFTPROCESS MED UML 1 Lektionsmål Att lära sig hur man genererar komponentdiagram och distributionsdiagram

Federal Communications Agency Federal State Educational Budgetary Institute of Higher Professional Education POVOLGA STATE UNIVERSITY OF TELECOMMUNICATIONS AND INFORMATICS

Mål: Lab 7: Grunderna för UML Syftet med detta arbete är att bekanta dig med de grundläggande teknikerna för att designa system och processer med hjälp av Universal Modeling Language (UML).

Zolotov Sergey Yuryevich Ph.D., docent vid institutionen för automatiserade styrsystem Designing Information Systems Webinar 3 "Kärnan i den objektorienterade strategin för design av informationssystem" Webinarplan Innebörden av objektorienterad

SOFTWARE ENGINEERING CASE IMPLEMENTATION G.I. RADCHENKO, DEPARTMENT SP YURGU CASE ANALYS En analytisk klassmodell är en statisk struktur i systemet, och implementeringen av prejudikat visar hur

Förord ​​Introduktion till UML och UP Vad är UML? Vad är UML? Födelsen av UML MDA - framtiden för UML Varför "enat"? Objekt och UML UML-struktur UML-byggstenar Gemensamma UML-mekanismer arkitektur

Lab 4 ”Introduktion till den rationella enhetliga processen. Mönster ”Syftet med arbetet är att lära sig att utveckla arbetsflödesmodeller; förstå platsen för denna modell för att bestämma funktionerna hos det system som utvecklas

CASE-VERKTYG FÖR UTVECKLING AV INFORMATIONSFÖRSÖRJNING CAD Föreläsning 5 "Utveckling av krav på informationsstöd" Objektorienterat tillvägagångssätt för OOP bygger på representationen av problemets domän

UML - Universal Modeling Language allmän information UML - Universal Modeling Language är ett universellt modelleringsspråk designat för att skapa enhetliga beskrivningar av modeller av systemobjekt. Hans

St. Petersburg State University of Information Technologies, Mechanics and Optics Beskrivning av studenters självständiga arbete (IWS) "Analysis and Design in UML" FA Novikov, Cand. fys.-mat.

1 1. Inledning ... 3 2. Grunder ... 4 3. Typer av diagram ... 5 3.1 Användningsfallsdiagram. 5 3.2 Sekvensdiagram ... 13 3.3 Klassdiagram ... 19

Föreläsning 2.5 Implementeringsdiagram. Tidsdiagram 1 Utbyggnadsdiagram 2 1.1 Artefakt 3 1.2 Nod 3 1.3 Anslutningar 5 1.3.1 Beroendeförhållanden 6 1.4 Rekommendationer för

LABORATORIEARBETE PÅ KURS TEORI OM INFORMATIONSPROCESSER OCH SYSTEM 1. Syfte med arbetet LABORATORIEARBETE 4 Skapande av interaktionsdiagram Få färdigheter att bygga sekvensdiagram och samarbete

SOFTWARE ENGINEERING OBJEKTORIENTERAD ANALYS GI RADCHENKO, AVDELNING AV JV YURGU CASE-CASE ANALYSIS UPs aktivitet "Use Case Analysis" inkluderar: skapande av analysklasser för implementering av användningsfall Klasser

Kapitel 5 Affärsprocessmodellering Grundläggande För problemanalys i en IS/IT-miljö är affärsprocessmodellering den mest lämpliga metoden. Affärsprocessmodellen hjälper oss att bestämma

Innehåll Förord ​​19 Introduktion 21 Utbildnings- och webbresurser 22 Vem bör läsa den här boken 22 Vad du behöver veta 22 Java-exempel 22 Bokstruktur 23 Om författaren 23 Kontakt 24 Tillägg

Grafiska diagram över SObjectizer-agenter Boris Sivko Intervale 2007.11.20 Innehåll 1 Introduktion 1 2 Typer av diagram 2 3 Operationsdiagram 2 3.1 Använda element .................... 2 3.1. 1 Agenter ...................................

SOFTWARE ENGINEERING Analysklasser G.I.RADCHENKO, AVDELNING FÖR SP YURGU OBJEKTORIENTERAD DESIGN MED UML RADCHENKO G.I., AVDELNING FÖR SP YURGU 2 NOTATION AV UML-OBJEKT Rektangel med två

Relationell datamodell Grundläggande begrepp för relationsmodellen En domän är en samling värden från vilka värdena för motsvarande attribut för en viss relation tas. Ur programmeringssynpunkt,

Modellering av flöden 1 Modellering av flöden Denna metod (Gane / Sarson-metodik) är baserad på konstruktionen av en modell av den analyserade IS, designad eller faktiskt existerande. Enligt metodiken

IP-UTVECKLING IP-livscykel Definition 1: IP-livscykeln är processen att bygga och utveckla den. Definition 2: Livscykeln för en IP är den tidsperiod som börjar från det ögonblick ett beslut fattas om behovet

Datamodellering Entitet-Relationsmodell Frågor som omfattas: Entity-Relationship Model Elements Entity-Relationship Diagrams Svaga enheter Entitetsundertyper Frågor som omfattas: Exempel ER Diagram

Utbildningsministeriet i Republiken Vitryssland Utbildningsinstitution "Vitrysslands statliga universitet för informatik och radioelektronik" Institutionen för elektronisk datormaskiner A.V. Otvagin, N.A.

GOU VPO Vladimir State University uppkallad efter Alexander Grigorievich och Nikolai Grigorievich Stoletovs VISUELL MODELLINGSSPRÅK UML Metodologiska riktlinjer för kursarbete inom disciplinen

Lab 3 HANTERA AUTOMATISKA SYSTEMKRAV MED IBM RATIONAL REQUISITE PRO. SKAPA ANVÄNDNINGSSCENARIER Syfte med arbetet: utveckling av scenarier för användning av programvara

Ryska federationens utbildnings- och vetenskapsministerium Federal State Budgetary Education Institute of Higher Professional Education "Vladimir State University uppkallad efter

Föreläsning 2 Verktyg för modellering av affärsprocesser 2.1 Inledning BPMN (Business Process Modeling Notation) grafisk notation för modellering av affärsprocesser. BPMN har utvecklats av Business Process Management

KAZAN (Volga Region) FEDERAL UNIVERSITY INSTITUTE OF COMPUTATIONAL MATEMATICS AND INFORMATION TECHNOLOGIES Visuell modellering av system i StarUML Kazan 2013 UDC 004.4 "22 519.682.6 Tryckt enl.

Vichugova Anna Aleksandrovna, assistent vid Institutionen för automation och datorsystem, Institutet för cybernetik, TPU. E-post: [e-postskyddad] Forskningsintressen: affärsmodellering, strukturanalys, databaser

FEDERAL KOMMUNIKATIONSMYNDIGHET Federal State Budgetary Education Institute högre utbildning"POVOLZH STATE UNIVERSITY OF TELECOMMUNICATIONS AND INFORMATICS"

Metaspråket för att konstruera visuella modelleringsspråk L.N. Lyadova, A.O. Sukhov Perm State University [e-postskyddad], [e-postskyddad] Inledning Med det ökande antalet krav på anpassningsbar

SOFTWARE ENGINEERING ANALYSIS AND DESIGN RADCHENKO G.I., DEPARTMENT OF JV YURGU DESIGNING ENLIGT RADCHENKO GI, DEPARTMENT OF JV YURGU 2 VAD ÄR DESIGNING MJUKVARA? Mjukvarudesign är ett medvetet val av lösningar

Laborationer 7. SEKVENSDIAGRAM. Ett sekvensdiagram visar sekvensen i vilken objekt interagerar för att utbyta meddelanden. Sekvensdiagram

Ämne: FÖRSÄTTNINGAR TILL DESIGNEN AV KOMPLEXA SYSTEM. Jacksons teknik. Innehåll: introduktion till strukturerad programmering. Jackson-metoden "10 regler" 1. Inledning För tillfället över hela världen

Objektorienterad modellering

Den allmänt accepterade filosofin i de flesta moderna grafiska system när man skapar ritningar på en dator är användningen av de enklaste geometriska primitiverna: punkter, linjer och bågar. Via olika kombinationer av de listade primitiva, genom att tilldela vissa värden till deras geometriska egenskaper (vilket betyder koordinaterna för karakteristiska punkter, längder, radier, etc.), samt att använda redigeringskommandona som ingår i programmet, kan användaren skapa en godtyckligt komplex bild. Du kan hävda att i nästan alla grafiksystem finns det också många fler kommandon för att rita till exempel Bézier-kurvor eller NURBS-kurvor. Men låt inte detta vilseleda dig: på hårdvarunivå översätts alla dessa kurvor och splines fortfarande till en sekventiell uppsättning segment som approximerar den verkliga kurvan (det vill säga så nära kurvans faktiska position som möjligt). Ungefär samma tillvägagångssätt i tredimensionell solid modellering: ett komplext volymetriskt objekt skapas genom successiva kombinationer av olika grundläggande tredimensionella former (kub, sfär, kon, torus, etc.), såväl som genom att använda grundläggande formningsoperationer (extrudering, rotation, boolesk operation, etc.) etc.).

I de flesta fall är detta tillvägagångssätt ganska lämpligt för användare, eftersom det låter dig skapa bilder och modeller av praktiskt taget vilken form som helst. Detta kommer dock till en kostnad av tid som läggs på mastering funktionalitet grafiksystem, samt den tid det tar att skapa varje sådan ritning eller tredimensionell modell. Avgiften är faktiskt inte så stor, men snart slutade detta tillvägagångssätt att passa användarna. Anledningen till detta bör först och främst betraktas som det faktum att användaren vid design skapar en modell eller bild av ett verkligt (om än inte existerande) materialobjekt. Varje sådant objekt i den verkliga världen är försett med väldefinierade egenskaper som inte alltid kan förmedlas genom en bild av en konventionell ritning eller en 3D-modell. Det bör noteras att en sådan möjlighet med utveckling av medel och följaktligen designkrav skulle vara långt ifrån överflödig. Det var detta som fungerade som drivkraften som tvingade enskilda utvecklare att gå en något annorlunda väg, vilket resulterade i att objektsmetod uppfanns.

I objektorienterad modellering arbetar användaren inte med de enklaste geometriska primitiverna, utan med specifika objekt. Till exempel, när man bygger en planritning av en byggnad, används nu istället för punkter, linjer och bågar, väggar, fönster, dörrar, separata rum etc. Varje sådant objekt är försett med en viss uppsättning egenskaper som är satta ( eller tilldelas som standard) när ett objekt skapas och lagras i dokumentfilen tillsammans med ritningsbilden eller 3D-modellens geometri. För fönster kan dessa egenskaper inkludera de övergripande måtten och beskrivningen av fönsterformen (rektangulär, halvcirkelformad, bågformad eller vilken annan form som helst), glasningens optiska egenskaper och ramens material och struktur. För väggar - väggens tjocklek, längd och höjd, väggens material, strukturen på de yttre och inre ytorna, det faktum att det finns fönster eller dörrar på denna vägg, samt referenser till föremål som motsvarar dessa fönster eller dörrar.

I tredimensionell modellering byggs också en 3D-scen av enskilda objekt som systemet erbjuder användaren att välja mellan. Till exempel, om ett visst program är avsett för att modellera utformningen av vardagsrum eller kommersiella lokaler, kan databasen för ett sådant program representeras av en uppsättning olika stoppade eller kontorsmöbler, skåp, bord, etc. Varje tredimensionell interiörobjektet har också specifika egenskaper som gör att det kan modifieras till vissa gränser (ändra färg, konfiguration, välj material och andra egenskaper).

Ansökan objekt tillvägagångssätt ger många fördelar.

Hastigheten för att skapa planer och ritningar ökar med en storleksordning.

Ritningen eller modellen blir mer informativ: när du väljer (eller redigerar) ett objekt kan du enkelt definiera (ersätta) dess egenskaper, och de flesta av dessa egenskaper kan som regel inte visas på en vanlig ritning eller modell.

Databasen med föremål är ibland fylld med inte bara godtyckliga, tidigare förberedda, utan ganska verkliga föremål (till exempel verkliga möbler från olika företag, material från specifika tillverkare etc.). I sådana fall måste programmet innehålla adresser till leverantörer och tillverkare, där du kan kontakta och beställa nödvändiga material och andra föremål omedelbart efter avslutat projekt.

Objekt är lätta att ändra och modifiera, medan programmet övervakar korrektheten av att ställa in värdena för vissa egenskaper (till exempel kan du inte skapa ett fönster som är större än måtten på väggen som det är placerat på). Detta underlättar arbetet och undviker oavsiktliga misstag.

Den konstruerade modellen (ritningen) kan presenteras i form av ett hierarkiskt träd (Fig. 1.1), vilket gör det lättare att navigera i projektet, söka och redigera dess enskilda delar.

Ris. 1.1. Ett exempel på en hierarkisk representation av en byggnadsplan baserad på ett objektssyn

Notera

Hierarkisk representation är långt ifrån ny datorstödd design... Men i det här fallet är trädets noder inte separata delar av den grafiska bilden, som i regel är oinformativa och inte bär någon semantisk belastning, utan specifika objekt, uppdelade enligt en viss egenskap.

En av de främsta, men inte alls uppenbara fördelarna med det objektorienterade tillvägagångssättet när man skapar grafiska bilder är förmågan att snabbt och fullständigt automatisk övergång till en tredimensionell bild (med andra ord förmågan att automatiskt generera en tredimensionell modell av det projicerade objektet). Med hänsyn till det faktum att uppsättningen objekt som användaren kan använda i alla fall är begränsad, och även med hänsyn till det faktum att tillräckligt med information kan läggas in i egenskaperna för varje objekt för att få en fullständig bild av dess form, blir möjligt att implementera "höjningen" av den grafiska bilden i 3D utan någon ansträngning från användarens sida (detta är exakt det tillvägagångssätt som implementeras i ArCon-systemet). Som ett resultat får användaren nästan omedelbart en tredimensionell representation av sitt projekt, nästan utan ansträngning. Den resulterande tredimensionella modellen kan sedan visualiseras och få en realistisk bild eller överföras till ett annat system för vidare redigering eller tekniska beräkningar. Dessutom, i det här fallet, behöver användaren inte några speciella 3D-modelleringsfärdigheter alls.

Notera

Mer uppmärksamhet bör ägnas denna egenskap, eftersom genereringen av en tredimensionell modell från ritningar länge har varit en stötesten för alla utvecklare av tekniska grafiska system. Faktum är att i praktiken den motsatta principen implementeras - genereringen av en ritning (i själva verket en projektion av en 3D-modell) från en färdig modell. Ett försök att implementera den motsatta handlingen (övergång från en tvådimensionell bild till 3D) ägde rum i några välkända CAD-system (särskilt i SolidWorks), men det är svårt att kalla det framgångsrikt. För strikta begränsningar läggs på den tvådimensionella bilden, vilket inte tillåter att den deklarerade funktionen tillämpas överallt. Objektsynsättet gör det möjligt att erhålla en komplett tredimensionell modell, naturligtvis, med hänsyn till specifika objekts särdrag.

Trots de många fördelar som anges ovan har det objektorienterade tillvägagångssättet också nackdelar.

Först och främst (och detta är uppenbart) är det den begränsade uppsättningen av färdiga föremål, såväl som omöjligheten av deras godtyckliga förändring. Detta tar bort programmets flexibilitet, vilket gör att principen för objektdesign endast kan tillämpas i specialiserade system (som ArCon, Professional Home Design Platinum, etc.). Utvecklare av sådana system måste noggrant ta hänsyn till särdragen i branschen för vilken mjukvaruprodukten är avsedd att automatisera och lösa problem, samt att maximera förmågan att anpassa egenskaperna för de föreslagna objekten.

Här kommer frågan om systemets kostnad och funktionalitet i förgrunden. Om du är 100% säker på att det eller det specialiserat program lämplig för dina ändamål, det bör inte råda några tvivel när du köper den. Annars måste du studera funktionaliteten mer i detalj för att försäkra dig om om det kommer att gå att lösa de tilldelade uppgifterna eller i värsta fall måste du lägga pengar på en "vanlig" och dyr CAD-editor.

Den andra nackdelen med objektorienterade grafiksystem är problemet med integration med andra grafiksystem... Vi pratar inte om några problem med dataöverföring - utbyte av både 2D- och 3D-information har länge ansetts vara standarden för all kommersiell programvara. Kärnan i problemet ligger just i förlusten av värdena för objektens egenskaper, såväl som alla hierarkiska kopplingar byggda mellan objekt. Anledningen är tydlig: det system som projektet planeras att exporteras till kanske inte stöder objektmetoden, eller så kan det ha en lista med egenskaper för sina egna objekt som skiljer sig från detta. Av denna anledning, när du sparar ett projekt från ArCon-programmet, exporteras endast den grafiska bilden till något annat format (inte ett ArCon-objekt).

Notera

Framöver kommer jag att säga att ArCon + 2005-projekt kan exporteras i olika 2D- och 3D-format med hjälp av filen? Exportera i formatet (Fig. 1.2). Det är viktigt att notera att programmet stöder sådana kända format datautbyte som VRML, DXF, 3ds Max systemformat, samt möjligheten att spara ett projekt till en körbar EXE-fil (mer om detta nedan).

Ris. 1.2. Format som stöds för att exportera projekt från ArCon

Situationen är ännu värre med import av data från andra system. Om de inte reduceras till ett visst format är det omöjligt att "ta" in dem i det objektspecialiserade systemet. Till exempel, när du importerar en ritning från AutoCAD till ArCon, kan endast en bild laddas. Samtidigt kommer ArCon inte att självständigt kunna känna igen var i den öppna bilden det finns fönster, dörrar, väggar etc., och ännu mer tilldela enskilda föremål ganska rimliga egenskaper. Detta innebär att ytterligare redigering av ritningen i ArCon, såväl som att "höja" den i 3D, är omöjlig. Att importera blir i grunden meningslöst, så de allra flesta objektorienterade designsystem har inte funktioner för att läsa grafisk data utifrån.

Men trots sådana betydande brister råder det enkla arbetet, och viktigast av allt, hastigheten och synligheten i projektgenomförandet. Som ett resultat av detta har nyligen system som ArCon-programmet som diskuteras i den här boken fått bred tillämpning vid lösning olika uppgifter design.

UML (English Unified Modeling Language) är ett grafiskt beskrivningsspråk för objektmodellering inom området mjukvaruutveckling. UML är ett brett baserat språk; det är en öppen standard som använder grafisk notation för att skapa en abstrakt modell av ett system som kallas UML-modellen. UML skapades för att definiera, visualisera, designa och dokumentera, främst mjukvarusystem. UML är inte ett programmeringsspråk, men kodgenerering är möjlig baserat på UML-modeller. (wiki)

Snabb utveckling på 1980-talet.

Huvudsaken inte ett förfarande eller en funktion, men ett objekt.

Bibliotek med standardobjektklasser som kan utföra åtgärder har skapats för olika PL.

Fonder dök upp visuell programmering(RAD), där programmeraren skapar ett program med musen, och programkoden genereras automatiskt. Programmerares uppmärksamhet bytte från att skriva kod till de tidigare stadierna - analys av ämnesområdet och programmets design.

OOA / OOD objektorienterade analys- och designmetoder har dykt upp. De låter dig designa system innan du skriver kod, så att projektet dokumenteras. Med hjälp av modellen kan du rätta till bristerna utan kostnad.

2 typer av diagram:

1) Strukturella modeller

2) beteendemönster

I framtiden började UML användas inte så mycket för designen av IS som för analys och omdesign av strömförsörjningssystem.

Att modellera ett företag med UML innebär att bygga två modeller:

1) fallmodell (fråga 16)

2) objektmodell (analys av strukturmodellen, beskriven av verksamhetens externa struktur etc.) (fråga 17).

Affärsmodell

Såväl som för användningsfall och för skådespelare särskiljs begreppet klass och instans. En klass beskriver de allmänna egenskaperna hos en viss typ av skådespelare, och en instans beskriver egenskaperna hos en viss skådespelare. Ett användningsfallsdiagram visar vanligtvis användningsfallsklasser och aktörsklasser. Dessutom kan deras placering vara godtycklig. Aktörer som tillhör olika klasser kan ha gemensamma egenskaper eller gemensamma skyldigheter i förhållande till verksamheten. Det är möjligt att introducera en generaliserad klass av aktörer som kombinerar de gemensamma egenskaperna hos flera mer specifika klasser. Till exempel, för klasserna Möbelköpare och datorköpare, kan en generisk köpareklass anges. I detta fall etableras ett generaliseringssamband mellan en generaliserad typ av aktörer och en mer specifik typ.

En kommunikationsrelation upprättas mellan prejudikat och aktörer. De modellerar information och materialflöden, d.v.s. utbyte av prejudikat med ämnen i miljön av materiell och informativ natur (data, dokument, råvaror, etc.).

För vart och ett av elementen i modellen upprättas en specifikation. Specifikationen för skådespelaren anger namn, stereotyp, beskrivning, lista över underdiagram och dokument relaterade till prejudikatet. Det viktigaste dokumentet för att beskriva användningsfall är ett dokument som kallas en händelseström. Den beskriver ett scenario för implementering av användningsfall som en sekvens av processsteg.

Varje steg eller händelse i ett användningsfall är en åtgärd som överför användningsfallet till ett nytt tillstånd. I sin tur är det nya tillståndet av prejudikatet ett incitament att utföra nästa steg eller händelse. Således ses ett användningsfall som en sekvens av tillstånd och händelser.

Objektmodell av affärsverksamhet.

Användningsfallsmodellen illustrerar verksamhetens funktioner. Men för att förstå verksamheten fullt ut behövs en modell som visar av vem och med hjälp av vilka use case som implementeras. Objektmodellen avslöjar den interna strukturen i ett företag: vilka typer av resurser som används och hur de interagerar. Denna modell kallas även affärsanalysmodellen. Grundkonceptet för denna modell är konceptet med ett objekt.

Affärsmodellobjekt representerar de personer som är involverade i genomförandet av processer, och av olika slag, enheter som bearbetas eller skapas av verksamheten. Deltagare i processer kallas aktiva objekt, entiteter kallas passiva. Liknande objekt grupperas i klasser, varje specifikt objekt betraktas som en instans av någon klass. Till exempel kan objekt som motsvarar specifika anställda grupperas i en "anställda"-klass. En objektegenskap beskrivs med hjälp av egenskaper som kallas attribut, medan sammansättningen av attributen är densamma för hela klassen. Klassen "anställd" kan ha attribut: efternamn, tjänstgöringstid osv. Olika föremål kommer att ha olika betydelser(vilket kan förändras med tiden). Beteende representeras av en uppsättning operationer som ett objekt kan utföra. Exempel på "anställd"-klassoperationer: Acceptera en order, utfärda ett kontrakt, acceptera betalning etc.

Typer av BP-analys.

Det finns olika klassificeringar av typer av analyser. Klassificering efter analysobjektet låter dig särskilja:

1. Analys av miljön

~ Analys av makromiljön (politisk, ekonomisk, teknisk)

~ Analys av mikromiljön (kunder, leverantörer, konkurrenter)

2. Affärsanalys (Produkter, Utrustning, Personal).

Analysen av makromiljön inkluderar analys av skattepolitik, arbetslagstiftning, studiet av det politiska systemet i regionen, analys av de senaste landvinningarna i produktionen, etc.

De viktigaste områdena för mikromiljöanalys är studiet av kundkrav, analys av leverantörer och partners samt analys av företagets konkurrensposition. I processen med affärsanalys utförs BP-analys, teknologier för deras implementering, analys av tillverkade produkter, analys och bedömning av personal.

Klassificeringar i enlighet med de analyserade tillstånden i systemet (nuvarande, tidigare, framtida) - låter dig markera jämförande, retrospektiv och prediktiv analys.

Klassificering efter analysmetoder - låter dig särskilja två huvudgrupper:

Kvantitativ (baserat på objektiv mätning och vidarebearbetning av kvantitativa parametrar)

1) statistisk (korrelation, regression, kluster)

2) ekonomisk (deterministisk faktoranalys, balansräkning)

3) beräkning (linjär programmering, känslighetsanalys, etc.)

· Kvalitativ analys (baserad på åsikter, subjektiva bedömningar och expertbedömningar). I detta fall används som regel informella eller svagt formaliserade metoder, såsom: Metoder för exportuppskattningar, DELPHI-metod, morfologisk analys, scenariometod och metod för att konstruera ett beslutsträd.

Objektorienterade modelleringsspråk började dyka upp mellan mitten av 1970-talet och slutet av 1980-talet, när utvecklingen av tillvägagångssätt för objektorienterad analys och design (OOAP) system började. I mitten av 1990-talet hade några av metoderna förbättrats avsevärt. Följande blev kända under denna period: Grady Booch-metoden (Grady Booch - Boosh "93); James Rumbaugh-metoden (Object Modeling Technique); Ivar Jacobson-metoden (Object Orienter Software Engineering).

Historien om Unified Modeling Language (UML) går tillbaka till oktober 1994, när Booch och Rumbach från Rational Software Corp. började arbeta med att förena sina metoder. Ett utkast till den så kallade enhetliga metoden version 0.8 utarbetades och publicerades i november 1995. Hösten samma år anslöt sig Jacobson, chefsteknolog på ObjectoryAB (Sverige), för att integrera sin OOSE-metod med de två tidigare.

Under denna period blir stöd för utvecklingen av UML-språket ett av målen för OMG-konsortiet (Object Management Group) - som bildades 1989. UML håller på att bli den andra strategiska riktningen i OMG:s arbete. G. Boochs, J. Rumbachs och A. Jacobsons ansträngningar ledde till uppkomsten av dokument som innehåller en beskrivning av det faktiska språket UML version 0.9 (1996)

Rational Software Corporation, tillsammans med flera organisationer, har anmält sig frivilligt för att avsätta resurser för att utveckla en rigorös definition av UML, bildade ett konsortium av UML-partners.I januari 1997 publicerades ett dokument som beskriver UML 1.0.

Av de mer än 800 företag och organisationer som för närvarande ingår i OMG-konsortiet, fortsätter Rational Software Corp., som låg i framkanten av utvecklingen av UML, att spela en speciell roll. Detta företag utvecklade och släppte ett av de första Rational CA8E-verktygen! Rose 98, där notationen för olika UML-diagram implementerades. Rational Software Corporation förvärvades av IBM i februari 2003 och har sedan dess formellt fått namnet IBM Rational Software.

För närvarande är alla frågor om vidareutveckling av UML koncentrerade inom OMG-konsortiet. Ett lämpligt team av experter ser till att material som beskriver framtida versioner av UML publiceras. Nästa steg i utvecklingen av detta språk avslutades i mars 1999, när OMG-konsortiet publicerade en beskrivning av språket UML 1.3. Nästa version av UML var version 1.5, som specificerades i mars 2003. 2004 släpptes UML 2.0.

Baserat på UML-teknik har Microsoft, Rational Software och andra leverantörer av mjukvaruutvecklingsverktyg utvecklat en enhetlig informationsmodell som kallas UML Information Model. Det antas att denna modell kommer att möjliggöra för olika program som stödjer UML-ideologin att utbyta komponenter och beskrivningar sinsemellan.

UML är ett generellt visuellt modelleringsspråk som är utvecklat för specifikation, visualisering, design och dokumentation av programvarukomponenter, affärsprocesser och andra system. Det är ett enkelt och kraftfullt modelleringsverktyg som effektivt kan användas för att bygga konceptuella, logiska och grafiska modeller av komplexa system för en mängd olika ändamål. Detta språk har absorberats bästa egenskaper och erfarenhet av programvarutekniker som framgångsrikt har använts under de senaste åren för att modellera stora och komplexa system.

Inom ramen för UML-språket är alla idéer om modellen för ett komplext system fixerade i form av speciella grafiska konstruktioner, så kallade diagram. När det gäller UML definieras följande typer av diagram:

diagram för användningsfall

klassdiagram

beteendediagram

interaktionsdiagram

samarbetsdiagram

sekvensdiagram

tillståndsdiagram

aktivitetsdiagram

implementeringsdiagram

komponentdiagram

distributionsdiagram

Några av de listade diagrammen används för att indikera två eller flera andra undertyper av diagram. I detta fall används följande diagram som oberoende representationer i UML.

Use Case Diagram - Systemfunktioner

Klassdiagram - statisk struktur av en systemmodell i OOP-klassterminologi

Samarbetsdiagram - den strukturella aspekten av interaktionen mellan systemobjekt genom sändning och mottagning av meddelanden

Sekvensdiagram - den tidsmässiga aspekten av interaktionen mellan systemobjekt

Tillståndsdiagram - beskriver beteendet hos ett system i termer av övergångar och tillstånd

Aktivitetsdiagram - modellering av processen för att utföra operationer (ett specialfall av ett tillståndsdiagram)

Komponentdiagram - En beskrivning av den fysiska representationen av ett system som definierar dess arkitektur (det första av två implementeringsdiagram)

Implementeringsdiagram - En vy av den övergripande konfigurationen och topologin för ett distribuerat system (andra av två implementeringsdiagram)

Listan över dessa diagram och deras namn är kanoniska i den meningen att de är en integrerad del av den grafiska notationen av UML. Dessutom är OOAP-processen oupplösligt kopplad till processen att konstruera dessa diagram. Samtidigt är uppsättningen av diagram konstruerade på detta sätt självförsörjande i den meningen att de innehåller all information som är nödvändig för genomförandet av ett projekt av ett komplext system.

Vart och ett av dessa diagram beskriver och konkretiserar olika vyer av modellen för ett komplext system när det gäller UML-språket. I det här fallet är use case-diagrammet den mest allmänna konceptuella modellen av ett komplext system, vilket är utgångspunkten för att konstruera alla andra diagram. Ett klassdiagram är i huvudsak en logisk modell som speglar de statiska aspekterna av den strukturella konstruktionen av ett komplext system.

Beteendediagram är också varianter av den logiska modellen som återspeglar de dynamiska aspekterna av hur ett komplext system fungerar. Slutligen används implementeringsdiagram för att representera de fysiska komponenterna i ett komplext system och hänvisar därför till dess fysiska modell.