Attribut för affärsobjekt. Praktiska exempel. Ursprungligt värde

Lämna en kommentar 6,950

Beskrivande attribut representerar fakta som är inneboende i varje beskrivning av ett objekt. Exempel - logisk funktion element i en digital krets.

Om värdet på det beskrivande attributet ändras, indikerar det att den aspekten av objektinstansen har ändrats, men objektet förblir detsamma.

Pekande attribut används för att namnge eller utse en instans.

Pekattribut används som objektidentifierare.

Dotterföretag attribut används för att associera en instans av ett objekt med en instans av ett annat objekt. Till exempel en instans av objektet "Microcircuit" med en instans av "Basic electrical circuit".

Om värdet på ett hjälpattribut ändras, indikerar detta att nu andra instanser av objektet är länkade.

Beskrivning av attribut

För beskrivande attribut fastställer beskrivningen den verkliga egenskapen, abstraherad som ett attribut.

I det här fallet ges beskrivningen i formen:

En uppräkning av alla möjliga värden som attributet kan ta;

Formuleringen av en regel som bestämmer vilka värden som är tillåtna;

Genom att definiera ett intervall av möjliga värden.

Beskrivningen av värdena för pekattributet bestämmer formen på indikationen och i vilken utsträckning attributet kan användas som en identifierare.

En extra attributbeskrivning måste innehålla en beskrivning av det faktiska förhållandet som definieras av attributet.

Attributregler

Sedan någon informationsmodell genererade av oss bör inte innehålla informationsfel (felaktigheter). För att göra detta måste den sträva efter att vara en relationsmodell, d.v.s. alla relationer mellan informationsmodelldata måste följa reglerna för relationalgebra.

1:a attributregeln

En instans av ett objekt har ett unikt värde för varje attribut vid varje given tidpunkt.

2:a attributregeln

Attributet får inte ha någon intern struktur. Alla attribut är enkla.

3:e attributregeln

Om objektet har en sammansatt identifierare, dvs. identifierare som består av mer än ett attribut, då måste varje attribut som inte ingår i den sammansatta identifieraren karakterisera hela objektet, inte en del av det.

Relationer mellan objekt

AnslutningarÄr en abstraktion av en uppsättning relationer som systematiskt uppstår mellan olika sorters objekt i den verkliga världen.

Varje relation i informationsmodellen specificeras av ett par namn som beskriver relationen ur varje deltagande enhets perspektiv.

Exempel: ett diagram innehåller element - element ingår i ett diagram.

En relation representeras grafiskt av en linje mellan relaterade objekt.

Exempel: låt oss ta ett ekonomiskt objekt:

Direkta relationer är indelade i:

Ovillkorliga anslutningar

Villkorliga länkar

Bland ovillkorliga anslutningar finns det 3 grundläggande typer av anslutningar. Dessa är kopplingarna:

"En till en" - en relation där en instans av ett objekt är associerad med en instans av ett annat objekt

"En till många" - en relation där en instans av något objekt är associerad med en eller flera instanser av ett annat objekt, medan varje instans av ett annat objekt är associerad med endast en instans av det första objektet

Många-till-många är en relation där en instans av ett objekt är associerad med en eller flera instanser av ett annat objekt, och varje instans av ett annat objekt associeras med en eller flera instanser av det första.

Den andra typen av anslutning av relationer är villkorlig anslutning.

En villkorlig länk kan ha sådana objektinstanser som inte deltar i länken.

N till exempel:

Alla länkar kräver en beskrivning. Beskrivningen inkluderar:

Länk-ID

Formulering av länknamn i termer av deltagande enheter

Kommunikationstyp (dess mångfald och konvention)

Formuleringen av hur relationen formaliserades (varför vi introducerar denna relation)

Formalisering av förhållandet (dess definition) är att fastställa förhållandet mellan objektinstanser. Detta görs med hjälp av hjälpmedel.

Om objektet har hjälpattribut, sägs förhållandet vara formaliserat.

För att formalisera en en-till-många-relation sätts ett hjälpattribut på många-sidan.

Om vi har en många-till-många-relation, för att inte bryta mot den tredje regeln för attribut, skapar vi ett extra (associativt) objekt som innehåller länkar till identifieraren för varje deltagande instans.

Länkar som uppstår på grund av närvaron av andra länkar mellan objekt kallas sammansättning anslutningar.

Om arv finns i informationsmodeller, så finns det undertyper och supertyper.

Supertype är det överordnade objektet.

En undertyp är ett underordnat objekt.

ER-diagram

Allmänt sätt att presentera logisk modell Databasen är konstruktion av ER-diagram (Entity-Relationship - entity-relationship). I denna modell definieras en entitet som ett diskret objekt för vilket dataobjekt lagras, och en relation beskriver en relation mellan två objekt.

I exemplet med en resebyråchef finns det 5 huvudobjekt:

Turister

Kuponger

Relationen mellan dessa objekt kan definieras i enkla termer:

Varje turist kan köpa en eller flera (många) kuponger.

Varje voucher motsvarar dess betalning (det kan bli flera betalningar om vouchern till exempel säljs på kredit).

Varje turné kan ha flera säsonger.

Kupongen säljs för en säsong av en turné.

Dessa objekt och relationer kan representeras ER-diagram som visas i figur 2.

Ris. 2. ER-diagram för resebyråchefens databasapplikation

Objekt, attribut och nycklar

Modellen utvecklas vidare genom att definiera attribut för varje objekt. Objektattribut är dataobjekt relaterade till ett specifikt objekt som måste bevaras. Vi analyserar den sammanställda dataordboken, väljer objekt och deras attribut i den, utökar ordboken vid behov. Attributen för varje objekt i detta exempel presenteras i Tabell 2.

Tabell 2. Objekt och attribut för databasen

Ett objekt	Turister	Kuponger	Turer	Årstider	Betalning
			namn	start datum	betalningsdatum
				Slutdatum
	mellannamn		Information
Attribut
Attribut

Observera att flera föremål saknas. Utelämnad registreringsinformation som nämns i funktionsspecifikationen. Hur man tar hänsyn till det, kommer du att tänka på egen hand och ändra det föreslagna exemplet. Men ännu viktigare, det finns fortfarande inga attribut som behövs för att länka objekt till varandra. Dessa dataelement är inte representerade i ER-modellen, eftersom de i själva verket inte är "naturliga" attribut för objekt. De behandlas på olika sätt och kommer att redovisas i relationsmodell data.

Den relationella modellen kännetecknas av användning av nycklar och relationer. Det finns en skillnad i sammanhanget relationsbas dessa termer relation (relation) och relation (dataschema). Relationen ses som en oordnad, tvådimensionell tabell med orelaterade rader. Dataschemat bildas mellan relationer (tabeller) genom gemensamma attribut, som är nycklar.

Det finns flera typer av nycklar, och de skiljer sig ibland bara när det gäller deras relation till andra attribut och relationer. En primärnyckel identifierar unikt en rad i en relation (tabell), och varje relation kan bara ha en primärnyckel, även om mer än ett attribut är unikt. I vissa fall krävs mer än ett attribut för att identifiera rader i en relation. Samlingen av dessa attribut kallas en sammansatt nyckel. I andra fall måste primärnyckeln skapas (genereras) speciellt. Till exempel, i relationen "Turister" är det vettigt att lägga till en unik turistidentifierare (turistkod) i formuläret primärnyckel denna relation för att organisera kopplingar med andra databasrelationer.

En annan typ av nyckel, som kallas en främmande nyckel, existerar endast i termer av dataschemat mellan de två relationerna. En främmande nyckel i en relation är ett attribut som är en primärnyckel (eller del av en primärnyckel) i en annan relation. Det är ett distribuerat attribut som bildar dataschemat mellan två relationer i databasen.

För den designade databasen, låt oss utöka attributen för objekt med kodfält som primärnycklar och använda dessa koder i databasrelationerna för att referera till databasobjekt enligt följande (tabell 3).

Det är för tidigt att betrakta det konstruerade databasschemat som komplett, eftersom dess normalisering krävs. En process som kallas relationsdatabasnormalisering används för att gruppera attribut på speciella sätt för att minimera redundans och funktionellt beroende.

Tabell 3. Objekt och attribut för databasen med utökade kodfält

Ett objekt	Turister	Kuponger	Turer	Årstider	Betalning
Attribut	Turistkod	Turkod		Säsongskod	Faktureringskod
		Turistkod	namn	start datum	betalningsdatum
		Säsongskod		Slutdatum
	mellannamn		Information		Turkod

Normalisering

Funktionella beroenden uppstår när värdet av ett attribut kan bestämmas från värdet av ett annat attribut. Ett attribut som kan definieras kallas funktionellt beroende av ett attribut som är en determinant. Därför kommer, per definition, alla icke-nyckel (nyckellösa) attribut funktionellt att bero på primärnyckeln i varje relation (eftersom primärnyckeln unikt identifierar varje rad). När ett attribut i en relation inte unikt identifierar ett annat attribut, utan begränsar det till en uppsättning fördefinierade värden, kallas det ett multivärdigt beroende. Partiellt beroende uppstår när ett relationsattribut är funktionellt beroende av ett enskilt attribut. sammansatt nyckel... Transitiva beroenden uppstår när ett icke-nyckelattribut är funktionellt beroende av ett eller flera andra icke-nyckelattribut i en relation.

Normaliseringsprocessen består av steg för steg konstruktion DB in normal form(SF).

1. Den första normalformen (1NF) är mycket enkel. Alla databastabeller måste uppfylla ett enda krav - varje cell i tabellerna måste innehålla ett atomärt värde, med andra ord ett lagrat värde inom ämnesområde DB-applikationer bör inte ha en intern struktur, vars delar kan krävas av applikationen.

2. Den andra normala formen (2NF) skapas när alla partiella beroenden tas bort från databasrelationerna. Om förhållandet inte har några sammansatta nycklar, är denna nivå av normalisering lätt att uppnå.

3. Den tredje normala formen (3NF) av databasen kräver att alla transitiva beroenden tas bort.

4. Den fjärde normalformen (4NF) skapas när alla flervärdiga beroenden tas bort.

Databasen i vårt exempel är i 1NF, eftersom alla fält i databastabellerna är atomära i sitt innehåll. Vår databas finns också i 2NF, eftersom vi artificiellt skrev in varje tabell unika koder för varje objekt (turistkod, turistkod, etc.), på grund av vilket vi uppnådde 2NF för var och en av databastabellerna och hela databasen som helhet. Det återstår att ta itu med den tredje och fjärde normalformen.

Observera att de endast existerar med avseende på olika typer av DB-attributberoenden. Det finns beroenden - du måste kosta NF DB, det finns inga beroenden - DB finns redan i NF. Men det senare alternativet finns nästan aldrig i verkliga applikationer.

Så, vilka transitiva och flervärdiga beroenden finns i vår exempeldatabas för en resebyråchef?

Låt oss analysera "turister" attityden. Låt oss överväga beroenden mellan attributen "Turistkod", "Efternamn", "Förnamn", "Patronym" och "Pass" (Fig. 3). Varje turist, representerad i förhållande till kombinationen "Efternamn-namn-patronym", har endast ett pass under hela resan, medan den fullständiga namne måste ha olika passnummer. Därför bildar attributen "Efternamn-Patronym" och "Pass" en sammansatt nyckel i förhållande till turister.

Ris. 3. Ett exempel på ett transitivt beroende

Som du kan se i figuren beror attributet "Pass" transitivt på nyckeln "Turistkod". Därför, för att utesluta detta transitiva beroende, kommer vi att dela upp den sammansatta nyckeln av relationen och själva relationen i 2 i en-till-en-relationer. I den första relationen, låt oss lämna den med namnet "Turister", attributen "Turistkod" och "Efternamn", "Namn", "Patronym" ingår. Den andra relationen, låt oss kalla den "Information om turister", bildas av attributen "Turistkod" och alla återstående attribut för "Turister"-relationen: "Pass", "Telefon", "Stad", "Land", "Index". Dessa två nya relationer har inte längre ett transitivt förhållande och är i 3NF.

Det finns inga flervärdiga beroenden i vår förenklade databas. Anta till exempel att för varje turist, flera kontakttelefoner(hem, arbete, mobiltelefon etc., vilket är väldigt typiskt i praktiken), och inte en, som i exemplet. Vi får ett flervärdigt beroende av nyckeln - "Turistkod" och attributen "Telefontyp" och "Telefon", i denna situation upphör nyckeln att vara en nyckel. Vad ska man göra? Problemet löses också genom att dela upp relationsschemat i 2 nya scheman. En av dem ska ge information om telefoner (relationen "Telefoner") och den andra om turister (relationen "Turister") som är länkade av fältet "Turistkod". Turistkoden kommer att vara den primära nyckeln för turister och den externa nyckeln för telefoner.

2.1.2. Objektattribut

Ett attribut är ett värde som kännetecknar ett objekt i dess klass. Exempel på attribut: kategori, saldo, kredit (attribut för objekt i klasskontot); namn, ålder, vikt (attribut för föremål för klassperson), etc.

Bland attributen skiljer sig åt beständiga attribut(konstanter) och variabla attribut... Konstanta attribut kännetecknar ett objekt i dess klass (till exempel kontonummer, kategori, personens namn, etc.). De aktuella värdena för variabelattributen kännetecknar strömmen skick objekt (till exempel kontosaldo, personens ålder etc.); genom att ändra värdena för dessa attribut ändrar vi objektets tillstånd.

Attributen listas i den andra delen av klassens rektangel (se figur 2.1). Ibland anges typen av attribut (trots allt är varje attribut ett värde) och det initiala värdet för variabla attribut (uppsättningen av initiala värden för dessa attribut anger objektets initiala tillstånd).

Det bör noteras att när vi talar om objekt och deras klasser, menar vi inte något objektorienterat programmeringsspråk. Särskilt detta tar sig uttryck i att på detta stadium utveckling av ett mjukvarusystem bör endast de attribut som är vettiga i verkligheten beaktas (alla attribut för objekt i klasskontot - Figur 2.1 - har denna egenskap). Attribut är relaterade till vanliga implementeringsspecifikationer. Om det till exempel är känt att en databas kommer att användas där varje objekt har en unik identifierare, bör denna identifierare inte inkluderas i objektets attribut i detta skede. Poängen är att genom att introducera sådana attribut begränsar vi möjligheterna för systemimplementeringen. Så, genom att introducera en unik identifierare för ett objekt i en databas som ett attribut, överger vi i början av designen användningen av DBMS som inte stöder en sådan identifierare.

RYSKA FEDERATIONENS UTBILDNINGSMINISTERIET OCH VETENSKAP

stat läroanstalt högre yrkesutbildning

Russian Economic University uppkallad efter G.V. Plechanov

Ufa Institute (filial)

Fakulteten för ekonomi och management

Kurs 2

Specialitet 230700.62 Tillämpad informatik

Gabbasov Timur Aidarovich

Kursarbete

Genom disciplin: " Mjukvaruutveckling»

På ämnet: ”Begreppet en klass och ett objekt. Vad kan vara ett objekt. Attribut och operationer"

Chef: F.A. Sadrtdinov

Ufa 2014

Inledning ………………………………………………………………………………… .3

1. Konceptet med ett objekt i programmering ………………………………… 4

2.Definition av klassen ………………………………………………………… ..6

2.1 Klassattribut ………………………………………………………… ..7

2.2 Verksamhet ………………………………………………………………………… .8

2.3 Beroenden mellan klasser, objekt ………………………… ..11

Slutsats ……………………………………………………………………… .15

Lista över använd litteratur ……………………………………… .17

Introduktion

Detta arbetes relevansligger i det faktum att tack vare sådana begrepp som "Objekt" och "Klass" dök objektorienterad programmering upp, som ett systematiskt tillvägagångssätt för algoritmisk formalisering av komplexa ämnesområden, vilket avsevärt förenklade lösningen av omfattande problem.

Studieämne -begreppet klass och objekt.

Studieobjekt -objekt och klass, och deras förhållande till attribut och operationer.

Syftet med detta arbete:avslöja essensen av begreppen objekt och klass, ange deras förhållande till begreppen attribut och drift, ange deras roll i begreppet objektorienterad programmering.

Uppgifter:

1. Lär dig begreppen objekt och klass.

2. Ge exempel
3. Lär dig begreppen attribut och funktion.

4.Ange rollen i objektorienterade programmeringskoncept.

1. Konceptet med ett objekt i programmering

I alla vanliga direktivprogrammeringsspråk är begrepp som data och datatyper framhävda. Data är siffror, teckensträngar, olika binära koder, som kan lagras i datorns RAM och utföra olika operationer på dem. Datatyper är namnen på grupper av data som är lika stora, upptagna i RAM och på det sätt de representeras externt, till exempel heltal eller symboler.

En liknande uppdelning finns i objektorienterade programmeringsspråk. Ett objekt är det begrepp som ligger närmast begreppet data. Det här är vad som faktiskt borde finnas i programmet, som upptar en specifik typ Bagge... Samtidigt är ett objekt ett mer komplext begrepp än bara en given eller en uppsättning data. Det enklaste objektet kan kallas en oupplöslig samling av data med en uppsättning funktioner (eller så kallade metoder) som är tillräckliga för att bearbeta denna data som krävs i ett program.

För att börja komponera ett objektorienterat program är det nödvändigt att inte ångra en ganska lång tid för valet och klassificeringen av objekt som är nödvändiga för att lösa problemet med mjukvarusystemet.

Ett föremål kan kallas något självstående programmodell, som ett system av modeller av objekt, begrepp och relationer mellan dem med deras karakteristiska beteende i tid och möjliga sätt förändringar som spelar en viktig funktionell roll för att lösa specifik uppgift programmering.

Låt oss ge gemensamma drag objekt.

Objektet är igenkännbart, d.v.s. har några, kanske inte tydligt avgränsade, gränser.

Objektet präglas av många möjliga stater där den stannar med vissa intervall. Stater ersätter varandra under hela objektets existens.

Ett objekt uppvisar sina egenskaper när det interagerar med andra objekt. Den här egenskapen kallas ibland för objektbeteende.

Objektet är unikt, d.v.s. har egenskaper som skiljer den från andra objekt.

Objektet har viss ram livscykel... Han är "född", fungerar, ändrar tillstånd efter tillstånd och "dör". Den här egenskapen är förknippad med förekomsten i programmet av ett tydligt definierat ramverk för objektets funktion. Lokala objekt i programmet har mindre "liv", maximalt - globala objekt som visas omedelbart efter programmets start och försvinner omedelbart innan det avslutas.

De listade egenskaperna för objekten, valda när du löser ett specifikt problem, motsvarar nästan helt de framtida funktionerna för objekt i programmet. Ett objekts funktion börjar vanligtvis med tilldelningen av dator-RAM för det och upprättandet av ett visst initialtillstånd (initialvärden under initiering). Under den efterföljande driften av programmet ändras minnesområdet som upptas av objektet, vilket kännetecknar objektets nya tillstånd, objektet interagerar med andra objekt. Och slutligen, efter att ha avslutat sitt arbete, frigör objektet minnet det upptar.

Ett objekts egenskaper gör det möjligt att skilja begreppet "objekt" från begreppet "klass", som på något sätt är motsatt det.

2 klass definition

Objekt med samma egenskaper och metoder kombineras till en klass.

En av de första åtgärderna en person tar när han försöker förstå världen, är att tillämpa någon strukturell form på den. När vi stöter på ett okänt objekt försöker vi klämma in det i vår befintliga struktur: med andra ord att klassificera det. De flesta känner till åtminstone med flera klassificeringsstrukturer eller hierarkier.

Användningen av en klasshierarki introducerar behovet av abstraktion. Klasserna blir mer abstrakta när du flyttar uppåt i hierarkin.

Objektorienterade språk använder samma tillvägagångssätt. Hierarkier börjar vanligtvis med flera abstrakta klasser. Varje ny klass representeras som en underklass till en befintlig klass (kallad dess superklass). Det ärver data och metoder från de högre klasserna i hierarkin. Endast data och metoder som är nya för denna klass bör definieras och implementeras.

En klass är ett abstrakt begrepp som kan jämföras med en kategori i dess vanliga bemärkelse.

Enligt vissa egenskaper hos någon del av en viss kategori kan det fastställas att den tillhör den. Själva kategorin är definierad generella egenskaper som alla instanser av denna kategori har.

Detta kan illustreras med ett exempel musikinstrument... Musikinstrument är indelade i följande kategorier: blås, slagverk och stråkar.

Alla dessa kategorier tillhör kategorin musikinstrument. I sin tur ingår kategorin musikinstrument i kategorin instrument. I figur 1 visas denna kategoristruktur grafiskt som ett träd.

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.

Fig. 2.1 Fig.2.2

2.1 klassattribut

Bland attributen skiljer man mellan konstanta attribut (konstanter) och variabla attribut. Konstanta attribut kännetecknar ett objekt i dess klass (till exempel kontonummer, kategori, personens namn, etc.). De aktuella värdena för variabla attribut kännetecknar Nuvarande tillstånd objekt (till exempel kontosaldo, personens ålder etc.); genom att ändra värdena för dessa attribut ändrar vi objektets tillstånd.

Det bör noteras att när vi talar om objekt och deras klasser, menar vi inte något objektorienterat programmeringsspråk. Detta uttrycks i synnerhet i det faktum att i detta skede av utvecklingen av ett mjukvarusystem bör endast de attribut som är vettiga i verkligheten beaktas (alla attribut för objekt i klasskontot - Figur 2.1 - har denna egenskap) .

Attribut är relaterade till vanliga implementeringsspecifikationer. Om det till exempel är känt att en databas kommer att användas där varje objekt har en unik identifierare, bör denna identifierare inte inkluderas i objektets attribut i detta skede. Poängen är att genom att införa sådana attribut begränsar vi möjligheterna för systemimplementeringen. Så, genom att introducera en unik identifierare för ett objekt i en databas som ett attribut, överger vi i början av designen användningen av DBMS som inte stöder en sådan identifierare.

2.2 Drift

En operation är en funktion (eller transformation) som kan appliceras på objekt av denna klass... Exempel på operationer: kontrollera, ta bort, placera (för objekt i klasskontot -), öppna, läs, stäng (för objekt i filklassen - Figur 3.1), etc.

Figur 3.1

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).

En och samma operation kan generellt sett tillämpas på objekt av olika klasser: en sådan operation kallas polymorf, eftersom den kan ha olika former för olika klasser. Till exempel, för objekt av klasserna vektor och komplext_tal, kan du definiera operationen +; denna operation kommer att vara polymorf, eftersom vektoraddition och addition komplexa talär generellt sett olika operationer.

Varje operation har en motsvarande metod - implementeringen av denna operation för objekt av denna klass. Således är en operation en specifikation av en metod, en metod är en implementering av en operation. Till exempel kan filklassen definiera en utskriftsoperation. Denna operation kan realiseras olika metoder: (a) skriva ut binär fil; (b) tryckning textfil Logiskt sett utför dessa metoder samma operation, även om de implementeras av olika kodfragment.

Varje operation har ett implicit argument - det objekt som den gäller. Dessutom kan operationen ha andra argument (parametrar). Dessa ytterligare argument parametrerar operationen, men är inte associerade med metodval. En metod är bara associerad med en klass och ett objekt (vissa objektorienterade språk, som C ++, tillåter samma operation med olika nummer argument, och genom att använda detta eller det antal argument, väljer vi praktiskt taget en av metoderna som är associerade med en sådan operation; I skedet av preliminär design av systemet är det bekvämare att betrakta dessa operationer som olika, ge dem olika namn för att inte komplicera designen).

En operation (och metoder som implementerar den) definieras av dess signatur, som förutom namnet på operationen inkluderar typerna (klasserna) av alla dess argument och typen (klass) av resultatet (returvärde). Alla metoder som implementerar operationen måste ha samma signatur som operationen de implementerar.

Operationerna listas längst ner i rektangeln (Figur 3.1) som beskriver klassen. Varje operation måste representeras av sin egen signatur, men i de tidiga stadierna av designen kan du begränsa dig till att ange namnet på operationen, skjuta upp fullständig definition signaturer i slutet av den övervägda fasen av livscykeln (eller till och med för efterföljande faser). V grafiskt språk OMT-teknik, typen av dataobjekt anges efter namnet på detta objekt efter ett kolon (som i Pascal).

När man modellerar ett system är det användbart att skilja mellan operationer som har bieffekter (dessa effekter uttrycks i att ändra värdena för objektets attribut, dvs. att ändra dess tillstånd), och operationer som producerar det önskade värdet utan att ändra objektets tillstånd. Dessa senare operationer kallas frågor.

Värdena för vissa attribut för ett objekt kan endast nås genom operationerna för det objektet. Sådana attribut kallas privata.. Figur 2.3 visar de privata attributen för objekt i klasskontot. Värdena för de privata attributen för ett objekt kan endast hittas utanför objektet om motsvarande frågor är definierade bland operationerna för detta objekt. På samma sätt kan privata (hjälp)operationer definieras i ett objekt, men i de tidiga designstadierna görs detta vanligtvis inte, eftersom valet av slutna operationer huvudsakligen är förknippat med implementeringen av systemet.

Fig 3.2 Offentliga och privata attribut och verksamhet

Frågor utan argument (förutom ett implicit argument - objektet som operationen tillämpas på) kan betraktas som härledda attribut. Härledda attributvärden beror på basattributvärdena. Detta är deras skillnad från huvudattributen, vars värden är oberoende. Därför bestämmer värdena för ett objekts huvudattribut både dess tillstånd och värdena för dess härledda attribut. Så till exempel är längden, bredden och höjden av ett rum dess huvudattribut, och arean och kubikkapaciteten är härledda attribut; ett sådant attribut som kubikkapacitet behövs för att inte beräkna kubikkapaciteten för ett rum närhelst dess värde behövs.

Valet av grundläggande attribut för objekt är godtyckligt, men antalet grundläggande attribut bör inte inkludera de attribut vars värden bestäms av värdena för andra attribut, så att de i själva verket härleds.

För att definiera en klass måste du alltså ange namnet på den klassen och sedan lista dess attribut och operationer (eller metoder). Full beskrivning objekt i det grafiska språket OMT har den form som visas i figur 3.3. Men ibland är det bekvämt att använda en förkortad beskrivning av en klass, när endast namnet på klassen anges i rektangeln som representerar denna klass. Så, figur 2.5 visar förkortningarna för beteckningen av klasser för vårt huvudexempel - kundtjänstsystemet för ett bankkonsortium.

Ris. 3.3. Fullständig objektrepresentation i OMT

Ris. 2.5. Möjliga klasser för AMT-systemet ( banktjänst)

2.3 Beroenden mellan klasser, objekt

En datastruktur är associerad med varje objekt, vars fält är attributen för detta objekt och pekare till 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å en datastruktur, vars typ motsvarar klassen för detta objekt.

Databeroende kan fastställas mellan objekt. Dessa beroenden uttrycker associationer eller relationer mellan klasser av specificerade objekt. Exempel på sådana beroenden visas i figur 3.6 (de första två beroenden ä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. 3.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 namnet på beroendet slags ger riktning till beroendet. Så, i det första exemplet i figur 3.6, antyder namnet på beroendet "har en huvudstad" 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 existerar och det omvända beroendet är huvudstaden. På samma sätt, i det andra exemplet i figur 3.6, kan vi titta på ett eget ägt par av beroenden. Av liknande 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 referera beroenden avslöjar det faktum att beroendet är en egenskap hos ett par klasser, inte 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å beroenden mellan klasser visas i figur 3.7. Det första exemplet visar förhållandet mellan en bankkund och hans konton. En bankklient kan ha flera konton i denna bank samtidigt, eller inte ha ett konto alls (när han först blir bankkund). Du behöver alltså skildra relationen mellan en kund och flera konton, vilket görs i figur 3.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 3.8 visar beroenden mellan objekt för det första exemplet i figur 2.6; Figur 3.9 visar beroenden mellan objekt för exemplen som visas i figur 3.7.

Ris. 3.7. Ytterligare exempel på beroenden. Beteckningar

Ris. 3.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. 3.9. Mer komplexa beroenden mellan objekt

Flyttade begreppet beroende till objektorienterad designteknik mjukvarusystem från databasdesign (och modellering) teknologi, 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 mjukvarusystem. OMT använder beroenden för att tolka diagram som beskriver systemet.

Slutsats

Objekten i programmet fungerar som ett väl koordinerat team. fristående program som själva vet när de är beroende av nuvarande situation du måste börja arbeta, när du tillfälligt ska avbryta det och slutligen, när du helt lämnar programteamet, och lämnar inget minne av dig själv annat än de nödvändiga användbara resultaten av arbetet. Som regel beställer varje objekt, som börjar sitt arbete, från operativ system RAM för dess data, och när det är klart returnerar det detta minne till systemet. Detta optimerar mängden minne som upptas av hela programmet under dess drift.

För att föremålen tydligt ska känna till sin plats och auktoritet i ett enda team, och inte ska utföra samma arbete, utsätts de för en speciell klassificering, vars resultat är valet av föremålsklasser. Om två klasser har gemensamma egenskaper måste de ha fler allmän klass, som bara har de egenskaper som är gemensamma för dessa två objekt. I det här fallet behöver objekt av klasser med gemensamma egenskaper bara oroa sig för att utföra sina funktioner förknippade med deras olika egenskaper. Den gemensamma delen kan utföras av ett objekt av en mer allmän klass.

Vi undersökte definitionerna av en klass, objekt, attribut, operationer, huvudkomponenterna i det objektorienterade tillvägagångssättet.
Det kan delas upp i fyra steg.

Det första steget är att lyfta fram abstraktioner. Att markera abstraktioner innebär att analysera ämnesområdet för vilket programmet är kompilerat för att bestämma ämnesområdets huvudobjekt, deras egenskaper, relationer mellan objekt, samt möjliga operationer på objekt och deras komponenter.

Det andra steget består i att skriva objekt och syntetisera abstrakta typer data. Stadiet innefattar definitionen av nya härledda datatyper och uppsättningar specifika funktioner eller operationer som tillämpas på dessa datatyper på ett sådant sätt att de förhindrar förvirring eller utbyte av olika typer.

Det tredje steget är objektsönderdelning som urvalet av undertyper eller underobjekt och deras beståndsdelar för var och en av objekttyperna.

Det fjärde steget är en kompositionshierarkisering av objekt som ett urval av generiska och kompositionella relationer över objekt.

Som ett resultat av det objektorienterade förhållningssättet till mjukvarudesign förvandlas programutvecklingsprocessen till en evolutionär process.programmering, där eventuella ändringar och tillägg till programmet inte kräver en radikal revidering av de algoritmer som utgör det. Den evolutionära programmeringsmetoden bygger på att bevara programobjektens integritet, d.v.s. att göra ändringar i programmet bör inte påverka den interna organisationen av befintliga objekt i det.

En viktig egendom objektorienterade språk är förmågan att utveckla program på dem som fungerar i system med komplex parallell beräkningsprocesser inneboende i tekniska medel datorteknik... Denna egenskap är baserad på konceptet med aktiva och inaktiva objekt under driften av programmet. Samtidig aktivitet olika föremål blir möjligt på grund av deras starka typning och stängning för förändringar av andra objekt.