Objektmodell

Objektorienterad teknik bygger på den sk objektmodell. Huvudprinciperna för dess konstruktion är: abstraktion, inkapsling, modularitet, hierarki, typning, parallellism och uthållighet. Var och en av dessa principer är inte nya i sig, men det är första gången de tillämpas tillsammans i objektmodellen.

Objektorienterad analys och design skiljer sig fundamentalt från traditionella tillvägagångssätt för strukturell design: här måste du föreställa dig nedbrytningsprocessen på ett annat sätt och arkitekturen för den resulterande mjukvaruprodukt ligger till stor del utanför ramen för traditionell strukturerad programmering. Skillnaderna beror på att strukturerad design bygger på strukturerad programmering, medan objektorienterad design bygger på den objektorienterade programmeringsmetodiken.

Strukturella designtekniker hjälper till att förenkla utvecklingen av komplexa system genom att använda algoritmer som färdiga byggstenar. Likaså är objektorienterade designtekniker utformade för att hjälpa utvecklare att tillämpa den kraftfulla uttrycksfullheten hos objektorienterad och objektorienterad programmering som använder klasser och objekt som block.

. (objektorienterad analys, OOA) syftar till att skapa modeller av verkligheten utifrån en objektorienterad världsbild.

Objektorienterad analysär en metodik där kraven på ett system uppfattas i termer av de klasser och objekt som identifieras inom ämnesområdet.

. ( objektorienterad design, OOD )

Programmering innebär i första hand korrekt och effektiv användning mekanismer för specifika programmeringsspråk. Däremot fokuserar design på att strukturera komplexa system korrekt och effektivt. Låt oss definiera objektorienterad design enligt följande:

Objektorienterad designär en designmetodik som kombinerar processen för objektnedbrytning och metoder för att representera logiska och fysiska, såväl som statiska och dynamiska modeller av det designade systemet.

V denna definition innehåller två viktiga delar: objektorienterad design

1) är baserad på objektorienterad nedbrytning;

2) använder en mängd olika tekniker för att representera modeller som återspeglar systemets logiska (klasser och objekt) och fysiska (moduler och processer) struktur, såväl som dess statiska och dynamiska aspekter.

Det är den objektorienterade nedbrytningen som skiljer objektorienterad design från strukturell design; i det första fallet reflekteras systemets logiska struktur av abstraktioner i form av klasser och objekt, i det andra - av algoritmer.

. (objektorienterad programmering, OOP)

Objektorienterad programmeringär en programmeringsmetodik baserad på att representera ett program som en samling objekt, som vart och ett är en instans av en viss klass, och klasserna bildar en arvshierarki.

Denna definition kan delas in i tre delar:

1) OOP använder som grundläggande element objekt, inte algoritmer;

2) varje objekt är kopiera någon specifik klass;

3) klasser är organiserade hierarkiskt.

Programmet kommer att vara objektorienterat endast om alla dessa tre krav är uppfyllda. I synnerhet programmering som inte är baserad på hierarkiska relationer är inte OOP, utan kallas programmering baserad på abstrakta datatyper.

Det finns fem huvudtyper av programmeringsstilar, som listas nedan, tillsammans med deras inneboende typer av abstraktioner:

Det är omöjligt att känna igen någon programmeringsstil som den bästa inom alla områden. praktisk applikation... Till exempel är en regelorienterad stil mer lämpad för utformning av kunskapsbaser, och en procedurorienterad stil för beräkningsproblem. Enligt vår erfarenhet är den objektorienterade stilen den mest lämpliga för de bredaste applikationerna; faktiskt, detta paradigm fungerar ofta som den arkitektoniska grund som andra paradigm bygger på.

Varje programmeringsstil har sin egen konceptuella bas. Varje stil kräver sitt eget tänkesätt och sätt att uppfatta problemet löst. För en objektorienterad stil är konceptbasen objektmodell. Den har fyra huvudelement:

• abstraktion;
• inkapsling;
• modularitet;
• hierarki.

Dessa element är den huvudsakliga i den meningen att utan någon av dem skulle modellen inte vara objektorienterad. Förutom de viktigaste finns det tre till ytterligare element:

• skriver;
• parallellism;
• uthållighet.

Genom att kalla dem valfria menar vi att de är användbara i objektmodellen, men inte obligatoriska.

Abstraktion lyfter fram de väsentliga egenskaperna hos ett objekt som skiljer det från alla andra typer av objekt och definierar därmed tydligt dess begreppsmässiga gränser ur betraktarens synvinkel.

Abstraktionen är baserad på begreppen klient och server.

Av klienten alla objekt som använder resurserna för ett annat objekt (kallas server).

Vi kommer att karakterisera beteendet hos ett objekt med de tjänster som det tillhandahåller till andra objekt och de operationer det utför på andra objekt. Detta tillvägagångssätt fokuserar på objektets yttre manifestationer och leder till idén avtalsmodell programmering när yttre manifestation ett objekt betraktas utifrån dess kontrakt med andra objekt, i enlighet med detta måste även dess interna struktur uppfyllas (ofta i samspel med andra objekt). Kontraktet fixar alla skyldigheter som serverobjektet har mot klientobjektet. Med andra ord, detta kontrakt definierar ett ansvar objekt, det vill säga det beteende som det är ansvarigt för.

Varje operation som tillhandahålls av detta kontrakt bestäms unikt av dess formella parametrar och returtyp. Hela uppsättningen operationer som en klient kan utföra på ett annat objekt, tillsammans med den korrekta ordningen i vilken dessa operationer anropas, anropas protokoll. Protokollet återspeglar allt möjliga sätt genom vilken objektet kan agera eller påverkas. Den definierar alltså helt abstraktionens yttre beteende ur en statisk och dynamisk synvinkel.

Inkapsling är processen att separera elementen i ett objekt från varandra som bestämmer dess struktur och beteende. Inkapsling tjänar till att isolera de kontraktuella skyldigheterna för abstraktionen från deras genomförande.

Abstraktion och inkapsling kompletterar varandra: abstraktion fokuserar på ett objekts observerbara beteende, medan inkapsling handlar om intern enhet... Oftast utförs inkapsling genom att dölja information, det vill säga genom att maskera alla interna detaljer som inte påverkar yttre beteende. Vanligtvis är både den interna strukturen för ett objekt och implementeringen av dess metoder dolda. I praktiken innebär det att man har två delar i en klass: ett gränssnitt och en implementering. Gränssnitt reflekterar ett objekts yttre beteende, som beskriver en abstraktion av beteendet hos alla objekt i en given klass. Inre insikt beskriver representationen av denna abstraktion och mekanismerna för att uppnå det önskade beteendet hos objektet. Principen om separation av gränssnitt och implementering motsvarar essensen av saker: allt relaterat till interaktion samlas i gränssnittsdelen. av detta föremål med andra föremål; implementeringen döljer från andra objekt alla detaljer som inte är relaterade till processen för interaktion mellan objekt.

Modularitet är en egenskap hos ett system som har sönderdelats i internt anslutna men svagt anslutna moduler.

I processen att dela upp ett system i moduler kan två regler vara användbara. För det första, eftersom moduler fungerar som elementära och odelbara kodblock som kan återanvändas i systemet, måste allokeringen av klasser och objekt till moduler ta hänsyn till detta. För det andra skapar många kompilatorer ett separat kodsegment för varje modul. Därför kan det finnas begränsningar för modulens storlek. Dynamiken i subrutinsamtal och placeringen av deklarationer inom moduler kan i hög grad påverka länklokalitet och sidhantering. virtuellt minne... Dåligt modulariserade rutiner ökar samtalen mellan segmenten, vilket resulterar i en förlust av cacheeffektivitet och frekventa sidbyten.

Det är ganska svårt att sammanföra sådana motstridiga krav, men det viktigaste är att förstå att isoleringen av klasser och objekt i projektet och organisationen av den modulära strukturen är självständig handlingar. Processen att isolera klasser och objekt är en del av den logiska designen av systemet, och uppdelning i moduler är stadiet för fysisk design. Visst, ibland är det omöjligt att slutföra logisk design system utan att slutföra den fysiska designen och vice versa. Dessa två processer utförs iterativt.

Hierarki - detta är ordningen av abstraktioner, deras arrangemang på nivåer.

Huvudtyperna av hierarkiska strukturer i förhållande till komplexa system är klassstruktur ("är-en" hierarki) och objektstruktur ("del av" hierarki).

En viktig del av objektorienterade system och huvudtypen av "är-en"-hierarki är begreppet arv som nämnts ovan. Med arv menas ett sådant förhållande mellan klasser (förälder/barnförhållande) när en klass lånar den strukturella eller funktionella delen av en eller flera andra klasser (respektive, enslig och multipelt arv). Med andra ord skapar arv en hierarki av abstraktioner där underklasser ärver struktur från en eller flera superklasser. Ofta bygger en underklass på eller skriver om komponenter i den överordnade klassen.

Om "är en"-hierarki definierar ett generaliserings-/specialiseringsförhållande, så introducerar "del av"-relationen en aggregeringshierarki. I "delen av" hierarkin ligger klassen på mer hög nivå abstraktion än någon av dem som användes för att implementera den.

Skriver är ett sätt att skydda mot att använda objekt av en klass istället för en annan, eller av åtminstone hantera sådan användning.

Parallellism är en egenskap som skiljer aktiva objekt från passiva.

Uthållighet - förmågan hos ett objekt att existera i tiden, uppleva processen som genererade det, och (eller) i rymden, flytta från dess ursprungliga adressutrymme.

Databas. Extrastudenter

Laboratoriearbete nr 1

Bygga en objektmodell av problemet med UML-modelleringsspråket.

För att försvara arbetet måste ett projekt skapat i Rational Rose-paketet tillhandahållas, vilket inkluderar tre typer av diagram: användningsfall, klasser (gränssnitt, data) och sekvenser för varje funktion.

allmän information

Modellbyggande är nödvändigt för att bättre förstå det system som utvecklas.

Modellering låter dig lösa följande uppgifter:

Visualisera systemet i dess nuvarande eller önskvärda skick för oss;

Bestäm strukturen eller beteendet hos systemet;

Skaffa en mall för att sedan designa systemet;

Dokumentera de beslut som fattats med hjälp av de resulterande modellerna.

Klass(Klass) är en beskrivning av en samling objekt med gemensamma attribut, operationer och relationer. Grafiskt avbildas en klass som en rektangel, som vanligtvis innehåller dess namn, attribut och operationer, som visas i Fig. 1. En av varianterna av entitetsklassen är skådespelare(Skådespelare). Vanligtvis representerar en skådespelare rollen som en person spelar i ett givet system, hårdvaruenhet eller till och med ett annat system. Såsom visas i fig. 2, skådespelarna avbildas som mänskliga figurer.

Prejudikat(Use Case) är en beskrivning av en sekvens av åtgärder som utförs av systemet som ger ett observerbart resultat som är signifikant för en viss aktör (Actor). Användningsfall används för att strukturera modellens beteendeentiteter. Grafiskt avbildas ett användningsfall som en ellips avgränsad av en kontinuerlig linje, som vanligtvis endast innehåller dess namn, som visas i fig. 3.

Beteendeenheterär dynamiska komponenter i UML-modellen. Dessa är verb i språket: de beskriver modellens beteende i tid och rum. Det finns två typer av beteendemässiga enheter:

Samspel;

Statsmaskin.

Samspel(Interaktion) är ett beteende, vars essens är utbyte av meddelanden (Meddelanden) mellan objekt inom ett specifikt sammanhang för att uppnå ett specifikt mål. Grafiskt avbildas meddelanden som en pil, över vilken namnet på motsvarande operation nästan alltid skrivs, som visas i fig. 4.

Gruppera enheterär de organiserande delarna av UML. Det är dessa block som modellen kan delas upp i. Det finns bara en grupperingsenhet, och det är ett paket.

Paket(Paketer) är en universell mekanism för att organisera föremål i grupper. Strukturella, beteendemässiga och till och med andra grupperingsenheter kan placeras i paketet. Till skillnad från komponenter som finns medan systemet körs, är paket rent konceptuella, det vill säga de existerar endast vid utvecklingstidpunkten. Paketet visas som en mapp med en flik som i regel endast innehåller namnet (se fig. 5).

Anteckningsenheter- förklarande delar av UML-modellen. Detta är kommentarer för ytterligare beskrivning, förtydliganden eller anmärkningar till någon del av modellen. Det finns bara en typ av anteckningselement - Anteckningar.

NoteraÄr helt enkelt en symbol för att avbilda kommentarer eller begränsningar kopplade till ett element eller en grupp av element. Grafiskt avbildas en anteckning som en rektangel med en vikt kant som innehåller text eller grafiska kommentarer, som visas i fig. 6.

UML definierar fyra typer av relationer:

Missbruk;

Förening;

Generalisering;

Genomförande.

Dessa relationer är de grundläggande byggstenarna i UML och används för att skapa giltiga modeller.

Missbruk(Beroende) är en semantisk relation mellan två enheter, där förändring av en av dem, oberoende, kan påverka semantiken hos den andra, beroende. Grafiskt avbildas förhållandet som en rak streckad linje, ofta med en pil (se fig. 7).

Förening(Association) - ett strukturellt förhållande som beskriver en uppsättning kopplingar; en länk är en koppling mellan objekt. Föreningen är grafiskt avbildad som en rak linje (som ibland slutar med en pil eller innehåller en etikett), bredvid vilken ytterligare beteckningar kan finnas, såsom kardinalitet och rollnamn. I fig. 8 visar ett exempel på denna typ av relation.

Ett UML-diagram är en grafisk representation av en uppsättning stenciler, oftast avbildad som en sammankopplad graf med hörn (entiteter) och kanter (relationer). Diagram ritas för att visualisera systemet från olika synvinklar. Det finns nio typer av diagram i UML:

Klassdiagram

Objektdiagram;

Använd falldiagram

Sekvensdiagram;

Samarbetsdiagram;

Tillståndsdiagram;

Handlingsdiagram;

Komponentdiagram

Implementeringsdiagram.

På klassdiagram visa klasser, gränssnitt, objekt och samarbeten och deras relationer. Vid modellering av objektorienterade system används denna typ av diagram oftast. Klassdiagram representerar den statiska designvyn av systemet.

På diagram för användningsfall Prejudikat och skådespelare presenteras ( specialfall klasser), samt förhållandet mellan dem. Användningsfallsdiagram hänvisar till en statisk vy av ett system när det gäller användningsfall. De är särskilt viktiga när man organiserar och modellerar ett systems beteende.

Sekvensdiagramär ett specialfall av interaktionsdiagram. På interaktionsdiagram länkar mellan objekt presenteras; särskilt de meddelanden som objekt kan utbyta visas. Interaktionsdiagram hänvisar till den dynamiska vyn av systemet. I det här fallet återspeglar sekvensdiagram den tidsmässiga ordningen för meddelanden.

Proceduren för att utföra arbetet kommer att övervägas med exemplet på följande uppgift:

Det är nödvändigt att se till att följande information lagras i databasen:

- information om studenter (inklusive fullständigt namn, hemadress, passdata, studentboksnummer, Födelsedatum, grupp);

- information om specialiteter (namn på specialitet, kod);

- information om grupper (specialitet, antagningsår, gruppnummer).

Se till att du utfärdar dokumentet "Grupplista" som innehåller fälten: serienummer, Fullständigt namn, elevens postnummer.

Objektmodellbygge utförs i Rational Rose-paketet. För att göra detta, låt oss skapa ett tomt projekt. Börja med ett diagram över användningsfall. Den är byggd i huvudområdet i avsnittet Use Case View, som visas i Fig. 9.

Innan du börjar bygga ett diagram är det nödvändigt att bestämma rollerna för användarna av systemet (aktörer) och deras funktioner (användningsfall). I vårt fall arbetar två aktörer med systemet – det är ”Anställd på utbildningsavdelningen” och ”Anställd på dekanatet”. Funktionerna för en anställd på utbildningsavdelningen inkluderar att upprätthålla en lista över specialiteter (under hålla en lista vi förstår att lägga till poster, korrigera dem och ta bort dem). Funktionerna för en anställd vid dekanusämbetet inkluderar att upprätthålla en lista över studenter och att upprätthålla en lista över grupper.

Det konstruerade diagrammet visas i fig. tio.

Därefter, i avsnittet Logical View, ska två klassdiagram skapas. För att göra detta kan du skapa två paket. Det första diagrammet bör innehålla klasserna för gränssnittet för den designade applikationen (se fig. 11). Det andra diagrammet är databasentiteterna (se figur 12).

Det konstruerade klassdiagrammet visar alla former för den framtida applikationen och deras relation.

Nästa steg i att bygga objektmodellen är att skapa sekvensdiagram. Sekvensdiagram genereras för varje användningsfall i use case-diagrammet. För att lägga till ett sekvensdiagram till ett användningsfall måste du markera det i trädet och anropa det innehållsmeny(NewàSequence Diagram) som visas i fig. 13.

Ett exempel på ett sekvensdiagram för användningsfallet "Behåll en lista över specialiteter" visas i fig. fjorton.

INTRODUKTION

De viktigaste egenskaperna hos ett system är dess struktur och funktionsprocess. Strukturen i ett system förstås som en uppsättning av inbördes relationer mellan dess element eller komponenter som är stabila över tid. Det är strukturen som binder samman alla element och hindrar systemet från att sönderfalla i enskilda komponenter. Strukturen av ett system kan återspegla en mängd olika relationer, inklusive kapsling av element från ett system i ett annat. I detta fall är det vanligt att kalla ett mindre eller kapslat system för ett delsystem. Processen att fungera i ett system är nära relaterad till förändringen i dess egenskaper eller beteende över tid. Vart i viktig egenskap systemet är dess tillstånd, vilket förstås som en uppsättning egenskaper eller attribut som vid varje tidpunkt återspeglar de viktigaste egenskaperna hos systemets beteende. En gemensam egenskap för alla modeller är deras likhet med originalsystemet. Vikten av att bygga modeller ligger i möjligheten att använda dem för att få information om det ursprungliga systemets egenskaper eller beteende. I det här fallet kallas processen att konstruera och sedan tillämpa modeller för att få information om det ursprungliga systemet modellering. Allmän modell systemet innehåller några viktig information om de funktionella egenskaperna hos detta system, som ger en uppfattning om dess fortsatta beteende.

Studiet av modelleringsprocessen är föremål för forskning i detta kursarbete. Konstruktionen av en specifik objektmodell, studien av dess beteende kommer att betraktas som föremål för forskning. För att uppnå detta mål används följande metoder: studie av nödvändig litteratur, jämförelse, exempel från livserfarenhet Eftersom konstruktionen av objektmodellen kommer att utföras med hjälp av exemplet på en biltjänst, är det nödvändigt att studera principen om driften av denna organisation. För att göra detta räcker det att besöka de officiella webbplatserna för olika biltjänster. Men för att studera principerna för att bygga en objektmodell studerade jag vetenskaplig inhemsk och utländsk litteratur. Det visade sig vara en mycket spännande upplevelse.

I slutändan mitt mål terminspapper blev: att bygga en objektmodell av informationssystemet "Autoservice", att studera principen för att bygga en objektmodell, att beskriva byggprocessen, att bevisa vikten av att besitta denna kunskap och förmågan att tillämpa den i praktiken.

Kursarbetets struktur är följande: först studeras teorin om att konstruera en objektiv modell, därefter prövas implementeringen av teorin på ett praktiskt exempel.

1. Grundläggande begrepp för det objektorienterade tillvägagångssättet

Det objektorienterade tillvägagångssättet bygger på systematisk användning av modeller. Objekt och begrepp i den verkliga världen som är relaterade till det utvecklade mjukvarusystemet är involverade i formuleringen av målet. I den objektorienterade ansatsen ersätts dessa objekt och begrepp av sina modeller, d.v.s. vissa formella konstruktioner som representerar dem i mjukvarusystemet.

Modellen innehåller inte alla tecken och egenskaper hos objektet eller konceptet den representerar, utan endast de som är väsentliga för det mjukvarusystem som utvecklas. Således är modellen enklare än det objekt (koncept) den representerar. Detta förenklar både utveckling och studier (analys) av modeller, och deras implementering på en dator. I synnerhet gör den formella karaktären av modellerna det möjligt att erhålla en formell modell av det utvecklade mjukvarusystemet som en sammansättning av formella modeller av dess komponenter.

Det objektorienterade tillvägagångssättet hjälper alltså till att hantera så komplexa problem som att minska komplexiteten hos programvara; öka tillförlitligheten hos programvara; ger möjlighet till modifiering enskilda komponenter programvara utan att ändra dess andra komponenter; säkerställa möjligheten till återanvändning av enskilda programvarukomponenter.

Den systematiska tillämpningen av det objektorienterade tillvägagångssättet gör det möjligt att utveckla välstrukturerade, driftsäkra och ganska lätt modifierbara mjukvarusystem. Detta förklarar programmerares intresse för det objektorienterade tillvägagångssättet. Det objektorienterade tillvägagångssättet är ett av de mest intensivt utvecklande områdena inom teoretisk och tillämpad programmering.

Objektorienterad mjukvaruutveckling förknippas med tillämpningen av objektorienterade modeller i utvecklingen av mjukvarusystem och deras komponenter.

Objektorienterad utveckling kan börja redan i första skedet livscykel; det är inte relaterat till det programmeringsspråk som det utvecklade mjukvarusystemet ska implementeras i: detta språk kanske inte är objektorienterat. På designstadiet är objekt några formella konstruktioner (till exempel rektanglar med rundade hörn, med vars hjälp de avbildas på diagrammen), som inte på något sätt är kopplade till deras framtida implementering i något av programmeringsspråken.

Objektorienterad mjukvaruutveckling är förknippad med tillämpningen av objektorienterade metoder (teknologier). Vanligtvis stöds dessa objektorienterade metoder av mjukvaruverktyg, men även utan sådana verktyg är de användbara, eftersom de låter dig förstå olika aspekter och egenskaper hos mjukvarusystemet som utvecklas, vilket sedan avsevärt underlättar dess implementering, testning, underhåll, utveckling av nya versioner och mer betydande modifieringar.

Utformningen av ett applikationsprogramsystem börjar med en analys av de krav som det måste uppfylla. En sådan analys görs för att förstå syftet och driftförhållandena för systemet för att kunna utforma dess preliminära design.

I det objektorienterade tillvägagångssättet reduceras analysen av systemkrav till utveckling av modeller av detta system. En modell av ett system (eller något annat objekt eller fenomen) är en formell beskrivning av systemet, där huvudobjekten som utgör systemet och relationerna mellan dessa objekt markeras. Modellbygge är ett utbrett sätt att studera komplexa föremål och fenomen. Modellen har utelämnat många detaljer som gör den svår att förstå. Simulering är utbredd inom både vetenskap och teknik.

Modeller hjälper till att kontrollera prestandan hos det system som utvecklas i de tidiga stadierna av dess utveckling, för att kommunicera med kunden av systemet, förtydliga dess krav på systemet, för att göra (om nödvändigt) ändringar i utformningen av systemet (båda i början av dess design och i andra faser av dess livscykel).

Modeller som utvecklats och felsökt i den första fasen av systemets livscykel fortsätter att användas i alla efterföljande faser, vilket underlättar systemprogrammering, felsökning och testning, underhåll och ytterligare modifieringar.

Objektmodellen beskriver strukturen hos de objekt som utgör systemet, deras attribut, operationer, relationer med andra objekt. Objektmodellen bör återspegla de begrepp och objekt i den verkliga världen som är viktiga för det system som utvecklas. Objektmodellen speglar i första hand pragmatiken i det system som utvecklas, vilket uttrycks i användningen av terminologi tillämpat fält i samband med användningen av det utvecklade systemet.

Låt oss överväga de grundläggande begreppen som används för att bygga en objektmodell.

Ett objekt är en abstraktion eller något annat med tydligt definierade gränser som är vettigt i sammanhanget av det tillämpade problemet som övervägs. Införandet av objekt har två mål: att förstå det tillämpade problemet (problemet) och att införa grunden för implementering på en dator.

Målet med att utveckla en objektmodell är att beskriva de objekt som utgör systemet under design, samt att identifiera och indikera de olika beroenden mellan objekt.

En klass är en deskriptor för en uppsättning objekt som har samma egenskaper. Klassen beskriver egenskaperna hos ett antal objekt. Varje objekt är en instans av endast en klass.

Alla objekt av samma klass kännetecknas av samma uppsättning attribut. Grupperingen av objekt i klasser bestäms dock inte av uppsättningarna av attribut, utan av semantik. Till exempel kan ett stall och en häst ha samma attribut: pris och ålder. Dessutom kan de tillhöra samma klass, om de i problemet bara betraktas som en vara, eller till olika klasser, vilket är mer naturligt.

Genom att kombinera objekt i klasser kan du introducera abstraktion i problemet och betrakta det i en mer allmän miljö. En klass har ett namn (t.ex. häst) som refererar till alla objekt i den klassen. Dessutom introducerar klassen namnen på de attribut som är definierade för objekten. I denna mening liknar beskrivningen av klassen beskrivningen av typen av struktur (rekord); dessutom har varje objekt samma betydelse som en instans av strukturen (en variabel eller konstant av motsvarande typ).

Ett objektattribut är ett värde som kännetecknar ett objekt i dess klass. Exempel på attribut: fabrikat, tillverkningsår, färg (attribut för föremål i klassbilen), etc.

En operation är en funktion (eller transformation) som kan appliceras på objekt i en given klass. Exempel på operationer: kontrollera, ta bort, leverera (för föremål i reservdelsklassen).

Alla objekt i en given klass använder samma instans av varje operation (dvs en ökning av antalet objekt i en viss klass leder inte till en ökning av antalet laddade programkod). Objektet från vilket operationen anropas skickas till det som dess implicita argument (parameter).

Samma operation kan tillämpas på objekt av olika klasser: en sådan operation kallas polymorf, eftersom den kan ha olika former för olika klasser.

Beroenden mellan klasser är tvåvägs: alla klasser är, beroende på, lika. Detta gäller även i de fall där beroendets namn verkar ge riktning till detta beroende. Beroenden mellan klasser motsvarar beroenden mellan objekt i dessa klasser. Beroenden, som klasser, kan ha attribut.

Diskriminatorn är ett attribut av typen "uppräkning" som visar vilka av objektegenskaperna som används för denna generalisering.

Roll definierar en sida av missbruket. Det finns två roller definierade i ett binärt beroende. Rollnamnet identifierar unikt en sida av beroendet. Roller gör det möjligt att betrakta ett binärt beroende som ett förhållande mellan ett objekt och en uppsättning beroende objekt: varje roll är en beteckning av ett objekt eller en uppsättning objekt som är relaterade av ett beroende till ett objekt i andra änden av beroendet. Ett rollnamn kan ses som ett härlett attribut vars uppsättning värden är den uppsättning objekt som är associerade med den rollen. I ett binärt beroende kan ett par rollnamn användas för att identifiera det beroendet.

Rollnamn måste anges när beroenden upprättas mellan objekt av samma klass. Rollnamn måste vara unika eftersom de används för att skilja mellan objekt som är involverade i ett beroende.

En kvalificerare är något attribut som gör att du kan minska den effektiva mångfalden av ett beroende. Kvalificerare används i ett-till-många eller många-till-många beroenden.

Aggregation är förhållandet mellan en klass av sammansatta objekt och de klasser som representerar komponenterna i dessa objekt (relationen "hela" - "del").

Generalisering och arv låter dig identifiera analogier mellan olika klasser av objekt, definiera en flernivåklassificering av objekt. Så i grafiska system kan det finnas klasser som definierar konturerna av olika geometriska former: punkter, linjer (räta linjer, cirkelbågar och kurvor definierade av splines), polygoner, cirklar, etc.

Diskriminatorn är ett attribut av typen "uppräkning" som visar vilka av objektegenskaperna som används för denna generalisering.

Det bör noteras att omfattande nivåklassificeringar bör undvikas, eftersom beteendet hos underklasser av de lägre nivåerna av nivåklassificering kan vara svårt att förstå: de flesta (och ofta alla) attribut och operationer för sådana klasser definieras i deras superklasser vid olika nivåer. Om antalet klassificeringsnivåer har blivit oöverkomligt måste struktureringen av systemet omstruktureras något.

Generalisering och nedärvning används i stor utsträckning, inte bara i analysen av krav på mjukvarusystem och deras preliminära design, utan också i deras implementering.

Ibland i en underklass är det nödvändigt att åsidosätta en operation definierad i en av dess superklasser. För detta definieras även operationen som kan erhållas från superklassen till följd av nedärvning i underklassen; denna omdefiniering av den "döljer" dess definition i superklassen, så underklassen använder inte den ärvda operationen, utan den omdefinierade operationen. Kom ihåg att varje operation identifieras med sin egen signatur; därför måste signaturen för operationsöverstyrningen matcha signaturen för operationen från superklassen som åsidosätts av operationen.

Åsidosättande kan tjäna ett av följande syften:

extension: den nya operationen utökar den ärvda operationen, med hänsyn till inflytandet av underklassens attribut;

begränsning: den nya operationen är begränsad till exekvering av endast en del av åtgärderna för den ärvda operationen, med användning av detaljerna för objekten i underklassen;

optimering: genom att använda detaljerna för subklassobjekt kan du förenkla och påskynda motsvarande metod;

bekvämlighet.

Det är tillrådligt att följa följande semantiska arvsregler:

alla frågeoperationer (operationer som använder attributvärden men inte ändrar dem) måste ärvas av alla underklasser;

alla operationer som ändrar attributvärden måste ärvas i alla deras tillägg;

alla operationer som ändrar värdena för begränsade attribut, eller attribut som definierar beroenden, måste blockeras i alla deras tillägg;

operationer bör inte åsidosättas; alla metoder som implementerar samma operation måste utföra samma attributkonvertering;

ärvda operationer kan förfinas genom att lägga till ytterligare åtgärder.

Genom att följa dessa regler, som tyvärr sällan stöds av objektorienterade programmeringsspråk, kan du göra det utvecklade programmet mer begripligt, lättare att modifiera, mindre mottagligt för olika fel och förbiser.

En abstrakt klass kan inte ha objekt, eftersom operationer på objekt inte är definierade i den; objekt måste tillhöra konkreta underklasser av den abstrakta klassen. Abstrakta klasser används för att specificera gränssnitten för operationer (metoder som implementerar dessa operationer definieras därefter i underklasser av den abstrakta klassen). Abstrakta klasser är bekväma vid analys av kraven för systemet, eftersom de låter dig identifiera en analogi i till synes olika operationer definierade i det analyserade systemet.

Multipelt arv tillåter en klass att ha mer än en superklass genom att ärva egenskaper (attribut och operationer) från alla dess superklasser. En klass som har flera superklasser kallas en sammanslagen klass. Egenskaper för en förfaderklass som förekommer mer än en gång i en arvsgraf ärvs endast i en instans. Konflikter mellan parallella definitioner skapar oklarheter som måste lösas vid genomförandet. I praktiken bör sådana oklarheter eller missförstånd undvikas även när det särskilda programmeringsspråket som valts för att implementera systemet ger möjlighet att lösa dem med prioriteringar eller på något annat sätt.

Inom objektorienterad design har vi att göra med många sammanlänkade objekt. Varje objekt kan betraktas som en variabel eller konstant av en strukturerad typ (i detta övervägande behandlas metoderna som beskrivs i objektet som adresser till funktioner som är tillåtna att appliceras på detta objekt). Därför är en uppsättning objekt en uppsättning sammankopplade data, dvs. något som liknar en databas. Därför är användningen av databaskoncept ofta användbar i objektorienterad analys och objektorienterad design av tillämpad mjukvarusystem.

Metadata är data som beskriver annan data. Till exempel är en klassdefinition metadata, eftersom en klass beskriver andra data - objekt av denna klass. Modeller är metadata eftersom de beskriver objekten som modelleras. Ett annat exempel på metadata är en abstrakt klass.

Skådespelare är roller som spelas av enheter som interagerar direkt med systemet.

Skådespelaren definierar den roll som någon extern enhet spelar i direkt interaktion med detta system. Det kan representera en användarroll eller en roll som spelas av ett annat system eller hårdvara som rör systemets gränser.

Jag gillade verkligen beskrivningen av begreppet ”skådespelare” i Jim Arlow och Isle Neustadts verk ”UML 2 and the Unified Process”: ”För att förstå skådespelare är det viktigt att förstå begreppet roller. En roll kan ses som en hatt som bärs i en viss situation." (sidan 92).

När de grundläggande begreppen är kända kan själva modellens konstruktion övervägas.

1. Bygga objektmodellen

1. Definiera klasser

Analys av externa krav för det designade applikationssystemet låter dig bestämma de objekt och klasser av objekt som är associerade med applikationsproblemet som detta system måste lösa. Du måste börja med att lyfta fram möjliga klasser från den skriftliga formuleringen av det tillämpade problemet ( mandat och annan dokumentation tillhandahållen av kunden). Detta är ett mycket svårt och avgörande utvecklingsstadium, eftersom projektets vidare öde till stor del beror på det.

När du identifierar möjliga klasser bör du försöka lyfta fram så många klasser som möjligt och skriva ner namnet på varje klass som du tänker på. I synnerhet kan en klass motsvara varje substantiv som förekommer i den preliminära formuleringen av problemet. Därför, när man identifierar möjliga klasser, är varje sådant substantiv vanligtvis associerat med en möjlig klass.

redundanta klasser: om två eller flera klasser uttrycker samma information, bör endast en av dem behållas;

irrelevanta (inte direkt relaterade till problemet) klasser: för varje namn på en möjlig klass bedöms det hur nödvändigt det är i det framtida systemet (det är ofta mycket svårt att bedöma detta); irrelevanta klasser är uteslutna;

vagt definierade (ur det aktuella problemets synvinkel) klasser;

attribut: vissa substantiv motsvarar inte längre klasser, utan attribut; sådana substantiv beskriver som regel objektens egenskaper (till exempel namn, ålder, vikt, adress, etc.);

operationer: vissa substantiv motsvarar inte längre klasser, utan namnen på operationer (till exempel betyder phone_call knappast någon klass);

Roller: vissa substantiv definierar namnen på roller i objektmodellen (till exempel ägare, förare, chef, anställd; alla dessa namn är associerade med roller i olika beroenden av objekt i klasspersonen);

implementeringskonstruktioner: namn som är mer associerade med programmering och datorhårdvara bör inte jämföras med klasser i detta skede, eftersom de inte återspeglar funktionerna i det designade applikationssystemet; exempel på sådana namn: subrutin, process, algoritm, avbrott, etc.

Efter att ha exkluderat namnen på alla onödiga (onödiga) möjliga klasser kommer en preliminär lista över klasser som utgör det designade systemet att erhållas.

1. Förbereder en dataordbok

Vissa ord har för många tolkningar. Därför är det nödvändigt i början av designen att förbereda en dataordbok som innehåller tydliga och entydiga definitioner av alla objekt (klasser), attribut, operationer, roller och andra enheter som beaktas i projektet. Utan ett sådant ordförråd är det inte meningsfullt att diskutera ett projekt med utvecklingskollegor och systemkunder, eftersom alla kan tolka termerna som diskuteras på sitt eget sätt.

2.3. Definition av beroende

I nästa steg av att bygga objektmodellen bestäms beroenden mellan klasserna. Först och främst är attribut som är explicita referenser till andra klasser exkluderade från klasser; sådana attribut ersätts av beroenden. Meningen med en sådan ersättning är att beroenden är en abstraktion på samma nivå som klasser, och därför inte har någon direkt inverkan på den framtida implementeringen (hänvisning till en klass är bara ett av sätten att implementera beroenden).

På samma sätt som namnen på möjliga klasser erhölls från substantiv som finns i den preliminära formuleringen av det tillämpade problemet, kan namnen på möjliga beroenden erhållas från verb eller verbfraser som förekommer i det angivna dokumentet. Så här brukar de beskriva: fysisk position (följer, är_ en del, innehåller_i), riktad handling (driver_rörelse), kommunikation (pratar_med), tillhörighet (har, är_del) osv.

Då bör du ta bort onödiga eller felaktiga beroenden med hjälp av följande kriterier:

beroenden mellan uteslutna klasser bör elimineras, eller omformuleras i termer av de återstående klasserna;

irrelevanta och genomförandeberoenden bör uteslutas.

åtgärder: beroendet ska beskriva applikationsområdets strukturella egenskaper, inte mindre händelser;

Trear-beroenden: de flesta av beroenden mellan tre eller flera klasser kan delas upp i flera binära beroenden, med hjälp av kvalificerare om nödvändigt; i vissa (mycket sällsynta) fall misslyckas en sådan nedbrytning; till exempel kan tågberoendet "Professorn undervisar i en kurs i rum 628" inte dekomponeras till binärt utan förlust av information;

härledda beroenden: du måste utesluta beroenden som kan uttryckas genom andra beroenden, eftersom de är redundanta; när du eliminerar redundanta (härledda) beroenden måste du vara särskilt försiktig, eftersom inte alla duplicerade beroenden mellan klasser är redundanta; i vissa fall tillåter andra beroenden bara en att fastställa existensen av ett annat härlett beroende, men tillåter inte en att fastställa mångfalden av detta beroende.

Efter att ha tagit bort redundanta beroenden måste du förtydliga semantiken för de återstående beroenden enligt följande:

felaktigt namngivna beroenden: de bör döpas om så att deras betydelse blir tydlig;

rollnamn: lägg till rollnamn där det behövs; rollnamnet beskriver den roll som motsvarande klass spelar i detta beroende utifrån en annan klasss synvinkel som deltar i detta beroende; om rollnamnet är tydligt från klassnamnet kan det utelämnas;

kvalificerare: genom att lägga till kvalificerare vid behov, introducerar vi kontextuella element, vilket gör att vi kan uppnå entydig identifiering av objekt; kvalificerare kan också förenkla vissa beroenden genom att minska deras mångfald;

multiplicitet: det är nödvändigt att lägga till symboler för mångfalden av beroenden; man bör komma ihåg att mångfalden av beroenden kan förändras i processen för ytterligare analys av kraven för systemet;

oredovisade beroenden bör identifieras och läggas till i modellen.

2.4. Förtydligande av attribut

I nästa steg förfinas attributsystemet: klassernas attribut korrigeras och nya attribut införs om nödvändigt. Attribut uttrycker egenskaperna hos objekt i klassen i fråga, eller bestämmer deras nuvarande tillstånd.

Attribut motsvarar vanligtvis substantiv; t.ex. car_color (objektegenskap), cursor_position (objekttillstånd). Attribut tenderar att ha liten effekt på objektmodellens struktur.

Tillsammans med objektens attribut är det nödvändigt att införa attribut för beroenden mellan klasser (länkar mellan objekt).

När du anger attribut följs följande kriterier:

Ersätter attribut med objekt. Om närvaron av någon entitet är viktigare än dess värde, så är detta ett objekt, om värdet är viktigare, då är detta ett attribut: till exempel är en chef ett objekt (det spelar ingen roll vem som är chefen) , huvudsaken är att någon är), lön är ett attribut ( dess betydelse är mycket betydande); en stad är alltid ett objekt, även om det i vissa fall kan verka som ett attribut (till exempel en stad som en del av en företagsadress); i de fall där det är nödvändigt att staden är ett attribut är det nödvändigt att fastställa förhållandet (säg, är) mellan klassföretaget och staden.

Kval. Om värdet på ett attribut är kontextspecifikt, bör det göras till en kvalificering.

Namn. Namn är i allmänhet bättre matchade med kvalificerare än objektattribut; i alla fall, när namnet tillåter dig att göra ett val från objekt av någon uppsättning, bör det göras till en kvalificering.

Identifierare. Objektidentifierare är associerade med deras implementering. I de tidiga stadierna av design bör de inte betraktas som attribut.

Länkattribut. Om någon egenskap inte karakteriserar ett objekt i sig, utan dess koppling till ett annat objekt (objekt), så är detta ett attribut för en koppling, inte ett attribut för ett objekt.

Inre värderingar. Attribut som endast bestämmer objektets interna tillstånd, osynliga utanför objektet, bör uteslutas från övervägande.

Obetydliga detaljer. Det rekommenderas att utelämna attribut som inte påverkar prestandan för de flesta av operationerna.

2.5. Tilldelning av delsystem

Ett applikationssystem är en uppsättning ömsesidigt beroende objekt. Varje objekt kännetecknas av en uppsättning attribut, vars värden bestämmer objektets tillstånd, och en uppsättning operationer som kan tillämpas på detta objekt. När man utvecklar tillämpade system det är bekvämt att anta att alla attribut för objekt är privata (dvs. de är inte tillgängliga utanför objektet, och för att ta reda på värdet av ett attribut för ett annat objekt i något objekt, eller ändra det, är det nödvändigt att använda en av den offentliga verksamheten för detta objekt, om, naturligtvis, en sådan verksamhet definieras). Objektoperationer kan vara antingen offentliga eller privata.

Således har varje objekt ett strikt definierat gränssnitt, d.v.s. en uppsättning öppna operationer som kan tillämpas på detta objekt. Alla objekt i samma klass har samma gränssnitt. Gränssnittet för en klass (och följaktligen för varje objekt i denna klass) specificeras av en lista med signaturer för dess offentliga (offentliga) operationer (och metoder som implementerar dem); Signaturer för privata operationer ingår inte i gränssnittet för objekt i motsvarande klass.

etc.................

Beroenden mellan klasser (objekt)

Varje objekt är associerat med en datastruktur, vars fält är attributen för detta objekt och pekare för funktioner (kodfragment) som implementerar operationerna för detta objekt (observera att funktionspekare vanligtvis ersätts av anrop till dessa funktioner som ett resultat kodoptimering). Ett objekt är alltså någon slags datastruktur, vars typ motsvarar klassen för detta objekt.

Du kan installera mellan objekt beroenden enligt. Dessa beroenden uttrycka anslutningar eller relation mellan klasserna för de angivna objekten. Exempel på sådana beroenden visas i figur 2.6 (de två första beroendena är binära, det tredje beroendet är trenar). Beroende avbildas av en linje som förbinder klasser ovanför vilken namnet på detta beroende är inskrivet, eller rollerna för objekt (klasser) i detta beroende anges (indikationen av roller är mest bekväm väg identifiering av beroende).

Ris. 2.6. Beroende mellan klasser

Beroenden mellan klasser är tvåvägs: alla klasser är, beroende på, lika. Detta gäller även i de fall där beroendets namn verkar ge riktning till detta beroende. Så, i det första exemplet i figur 2.6, antar beroendenamnet has_capital att beroendet är riktat från klasslandet till klassstaden (beroendets tvåsidighet verkar ha försvunnit); men man bör komma ihåg att detta beroende är dubbelsidigt i den meningen att det samtidigt finns ett omvänt beroende är_kapital. På samma sätt, i det andra exemplet i figur 2.6, kan vi titta på ett egenägt beroendepar. Sådana missförstånd kan undvikas genom att identifiera beroenden inte genom namn, utan genom namnen på rollerna för de klasser som utgör beroendet.

I programmeringsspråk implementeras beroenden mellan klasser (objekt) vanligtvis med hjälp av referenser (pekare) från en klass (objekt) till en annan. Att hänvisa till beroenden avslöjar det faktum att beroendet är en egenskap hos ett par klasser och inte hos någon av dem, dvs. beroende är en attityd. Observera att även om beroenden mellan objekt är dubbelriktade, behöver de inte implementeras i program som dubbelriktade, och lämnar endast referenser i de klasser där programmet behöver det.

Ytterligare exempel på klassberoenden visas i figur 2.7. Det första exemplet visar förhållandet mellan en bankkund och dennes konton. En bankklient kan ha flera konton i denna bank samtidigt, eller inte ha ett konto alls (när han först blir bankkund). Det är alltså nödvändigt att skildra relationen mellan en kund och flera konton, vilket görs i figur 2.7. Det andra exemplet visar förhållandet mellan korsande kurvor (i synnerhet raka) linjer. Du kan överväga 2, 3 eller fler sådana linjer, och de kan ha flera skärningspunkter. Slutligen visar det tredje exemplet ett valfritt beroende: datorn kan ha en mus eller inte.

Beroenden mellan klasser motsvarar beroenden mellan objekt i dessa klasser. Figur 2.8 visar beroenden mellan objekt för det första exemplet i figur 2.6; Figur 2.9 visar beroenden mellan objekt för exemplen som visas i figur 2.7.

Ris. 2.7. Ytterligare exempel på beroenden. Beteckningar

Ris. 2.8. Beroenden mellan objekt

Observera att när vi skildrar beroenden mellan objekt vet vi som regel antalet objekt och behöver inte sådana beteckningar som "flera", "två eller fler", "inte nödvändigtvis".

När man designar ett system är det bekvämare att inte arbeta med objekt utan med klasser.

Ris. 2.9. Mer komplexa beroenden mellan objekt

Beroendebegreppet har överförts till objektorienterad teknik för design av mjukvarusystem från teknik för design (och modellering) av databaser, där beroenden har använts under lång tid. Programmeringsspråk stöder som regel inte explicit beskrivning av beroenden. Att beskriva beroenden är dock mycket användbart när man utvecklar programvarusystem. OMT använder beroenden för att tolka diagram som beskriver systemet.

Nu har vi allt nödvändiga koncept att beskriva objektmodellbyggeprocessen. Denna process inkluderar följande steg:

• definition av objekt och klasser;
• utarbetande av en dataordbok;
• definiera beroenden mellan objekt;
• definiera attribut för objekt och länkar;
• organisation och förenkling av klasser vid användning av arv;
• ytterligare forskning och förbättring av modellen.

Bygga en objektmodell av problemet med UML-modelleringsspråket.

ARBETA I STARUML

Ledtid:

2-3 lektioner

För att försvara arbetet måste ett projekt skapat i Rational Rose-paketet tillhandahållas, vilket inkluderar tre typer av diagram: användningsfall, klasser (gränssnitt, data) och sekvenser för varje funktion.

EXEMPEL UPPGIFT:

Det är nödvändigt att se till att följande information lagras i databasen:

- studentinformation

o FULLSTÄNDIGA NAMN.,

o adress,

o passdata,

o klassrumsnummer,

o Födelsedatum,

o grupp);

- information om specialiteter

o namnet på specialiteten,

o chiffer;

- gruppinformation

o specialitet,

o antagningsår,

o gruppnummer.

Se till att du utfärdar dokumentet "Grupplista" som innehåller fälten:

· serienummer,

· FULLSTÄNDIGA NAMN.,

· student nummer.

Arbetsorder

Objektmodellbygge utförs i Rational Rose-paketet. För att göra detta, låt oss skapa ett tomt projekt. Börja med ett diagram över användningsfall. Den är byggd i huvudområdet i avsnittet Use Case View, som visas i Fig. 9.

Innan du börjar bygga ett diagram är det nödvändigt att bestämma rollerna för användarna av systemet (aktörer) och deras funktioner (användningsfall). I vårt fall arbetar två aktörer med systemet – det är ”Anställd på utbildningsavdelningen” och ”Anställd på dekanatet”. Funktionerna för en anställd på utbildningsavdelningen inkluderar att upprätthålla en lista över specialiteter (under hålla en lista vi förstår att lägga till poster, korrigera dem och ta bort dem). Funktionerna för en anställd vid dekanusämbetet inkluderar att upprätthålla en lista över studenter och att upprätthålla en lista över grupper.

Det konstruerade diagrammet visas i fig. tio.

Därefter, i avsnittet Logical View, ska två klassdiagram skapas. För att göra detta kan du skapa två paket. Det första diagrammet bör innehålla klasserna för gränssnittet för den designade applikationen (se fig. 11). I den här figuren, i klasserna "Lista över grupper" och "Lista över elever", är operationerna att lägga till, ändra och ta bort utelämnade för att undvika att figuren blir rörig. Listan över gruppen (lägre klass) är utdatadokumentet (föregås av klassen "Välj en grupp", eftersom det är nödvändigt att få en lista över elever i en viss grupp). Det andra diagrammet är databasentiteterna (se figur 12).

Det konstruerade klassdiagrammet visar alla former för den framtida applikationen och deras relation.

Nyckelfält bör ställas in och en länk upprättas (från pilens snabbmeny - Multiplicity).

Nästa steg i att bygga objektmodellen är att skapa sekvensdiagram. Sekvensdiagram genereras för varje användningsfall i use case-diagrammet. För att lägga till ett sekvensdiagram till ett användningsfall, välj det i trädet och anropa kontextmenyn på det (NewàSequence Diagram) som visas i Fig. 13.

Ett exempel på ett sekvensdiagram för användningsfallet "Behåll en lista över specialiteter" visas i fig. fjorton.

Det bör noteras att när du bygger den här typen av diagram för utdatadokumentet "Grupplista", i vårt fall, välj först en grupp i formuläret "Gruppval" (i sin tur bör data från enheten "Grupp" komma till den ), och visa sedan utdataformuläret, som tar emot data från "Student"-entiteten.