Kapitel 8 Modell och rekvisita för kartläggning När du har en uppfattning om vilken utrustning du kommer att behöva använda i fotograferingsprocessen kan du börja överväga vad som exakt ska kontrolleras i denna process. Eftersom du är

8. Föreläsning: Objektmodell i Java Denna föreläsning avviker från Java: s tekniska egenskaper och ägnas huvudsakligen åt studier av nyckelegenskaper hos Java-objektmodellen, såsom statiska element, abstrakta metoder och klasser, gränssnitt,

10.4. Document Object Model (DOM) Standarduppsättningen av objekt i ett HTML-dokument, deras egenskaper och hur de nås bestäms av Document Object Model (DOM). Med DOM kan du manipulera alla element på en webbsida, ändra deras egenskaper och

Systemets objektmodell beskriver strukturen för de objekt som utgör systemet, deras egenskaper, funktioner och förhållanden med andra objekt.

Objektmodellen bör återspegla de begrepp och objekt i den verkliga världen som är viktiga för systemet som utvecklas. Det återspeglar främst pragmatiken i det system som utvecklas. Pragmatik uttrycks i användningen av applikationsområdets terminologi associerad med användningen av det utvecklade systemet.

Objekt är ett begrepp, abstraktion eller någon annan sak med tydligt definierade gränser som är meningsfulla i det tillämpade problemet. Exempel på föremål: fönsterblad, centralbank, skolnummer 42, Petr Sidorov, filnummer 7461, sparbank etc.

Introduktionen av objekt tjänar två syften:

Förståelse för den tillämpade uppgiften (problem);

Introduktion av grunden för att implementera den på en dator.

Syftet med att utveckla en objektmodell är att identifiera och beskriva de objekt som utgör systemet under design, samt att identifiera och indikera olika beroenden mellan objekt. Denna process är en nedbrytning av systemet (problemet) i objekt - en kreativ och dåligt formaliserad process.

Alla systemobjekt kan ha sina egna och karakterisera deras egenskaper som skiljer ett objekt från ett annat. Till exempel kan ett objekt "äpple" kännetecknas av färg, form, vikt, smak osv. Mellan objekt kan du skapa en identitetsrelation. Sedan anses två objekt som uppfyller denna relation vara desamma (identiska) och tillhör samma klass.

Alla objekt av samma klass kännetecknas av samma uppsättning egenskaper (attribut). Gruppering av objekt i klasser bestäms dock inte av uppsättningar av egenskaper utan av semantik. Så till exempel kan objekten "Stabil" och "Häst" ha samma attribut: "Pris" och "Ålder". Dessutom kan de tillhöra samma klass, om de betraktas i problemet helt enkelt som en vara eller till olika klasser, vilket är mer naturligt.

Genom att kombinera objekt i klasser kan du introducera en abstraktion i problemet och överväga 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å attribut (egenskaper) som definieras för objekt. I denna mening liknar beskrivningen av klassen beskrivningen av typen av struktur (post). Dessutom har varje objekt samma betydelse som en instans av en struktur (en variabel eller konstant av motsvarande typ).

Exempelklass KONTO

Det bör erinras om att detta steg i systemdesign inte innebär användning av något objektorienterat programmeringsspråk. Detta uttrycks i synnerhet i det faktum att i detta skede endast de egenskaper hos föremål som är meningsfulla i verkligheten bör beaktas.

Objektens egenskaper är relaterade till särdragen i det övergripande genomförandet av projektet. Om du till exempel vet att en databas kommer att användas där varje objekt har en unik identifierare, ska du inte inkludera denna identifierare bland attributen för objektet i detta skede. Faktum är att genom att införa sådana egenskaper begränsar vi möjligheterna att implementera systemet. Så genom att införa en unik identifierare av ett objekt i en databas som attribut, vägrar vi i början av designen att använda DBMS som inte stöder en sådan identifierare.

Vissa operationer kan utföras på ett objekt. Till exempel "Kontroll", "Ta bort", "Plats" för objekt i klass "Faktura" eller "Öppna", "Läs", "Stäng" för objekt i klass "File", etc.

Drift - det är en funktion (eller transformation) som kan tillämpas på ett objekt. Alla objekt i samma klass använder samma instans av varje operation (det vill säga en ökning av antalet objekt i en viss klass leder inte till en ökning av mängden laddad programkod).

Generellt sett kan samma operation tillämpas på objekt av olika klass. Denna operation kallas polymorf eftersom den kan ta olika former för olika klasser. Till exempel, för objekt av klasserna vektor och komplexa nummer kan du definiera operationen +; denna operation kommer att vara polymorf, eftersom tillsats av vektorer och addition av komplexa tal är väsentligen olika operationer.

Varje operation motsvarar metod - implementering 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. Exempelvis kan filklassen ha en utskriftsfunktion definierad. Denna operation kan implementeras med olika metoder: (a) "Skriva ut en binär fil", (b) "Skriva ut en textfil", etc. Logiskt, dessa metoder utför samma operation, även om de implementeras av olika kodfragment.

Varje operation har alltid ett implicit argument - det objekt som det gäller. Dessutom kan operationen ha andra argument - egenskaper (parametrar). Dessa ytterligare argument kännetecknar operationen och har inget att göra med valet av metod.

En metod är endast associerad med en klass och ett objekt. (Vissa objektorienterade språk, till exempel C ++, tillåter samma operation med ett annat antal argument, och med detta eller det här antalet argument väljer vi praktiskt taget en av metoderna som är associerade med en sådan operation. preliminär systemdesign, är det bekvämare att läsa dessa operationer är olika, vilket ger dem olika namn för att inte komplicera designen).

Värdena för vissa egenskaper hos ett objekt kan endast nås med hjälp av objektet. Dessa fastigheter kallas privata.

Så för att definiera en objektklass måste du ange namnet på den här klassen och sedan lista dess egenskaper och operationer (eller metoder).

Databeroenden kan fastställas mellan objekt. Dessa beroenden uttrycker kopplingar eller förhållanden mellan klasser av specifika objekt.

Beroenden mellan klasserna är tvåvägs: alla klasser är, beroende på, lika. Detta gäller även i fall där beroendets namn verkar ge riktning till detta beroende. Sådana missförstånd kan undvikas genom att identifiera beroenden inte med namn utan med namnen på rollerna för de klasser som utgör beroendet.

I programmeringsspråk implementeras beroenden mellan klasser (objekt) vanligtvis med referenser (pekare) från en klass (objekt) till en annan. Representation av beroenden med hjälp av referenser avslöjar det faktum att beroendet är en egenskap hos ett par klasser, och inte av någon av dem, dvs. missbruk är en attityd. Observera att även om beroenden mellan objekt är dubbelriktade, behöver de inte implementeras som dubbelriktade i program. Länkar bör endast lämnas i de klasser där det är nödvändigt för programmet. När du utformar ett system är det bekvämare att inte använda objekt utan klasser.

Beroenden, som klasser, kan ha sina egna egenskaper. Till exempel, när du organiserar användaråtkomst till en fil, är "Access Permission" en beroendegenskap för "Available". Observera att åtkomstbehörighet är associerad med både användaren och filen och kan inte vara ett attribut för varken användaren eller filen separat.

Ibland representeras beroenden som har många egenskaper med hjälp av klasser. I databaser representeras sådana beroenden av tillfälliga tabeller organiserade i arbetet med databasen.

Generalisering och arv låter dig identifiera analogier som bestämmer klassificering av objekt på flera nivåer. Så i grafiska system kan det finnas klasser som definierar konturerna av olika geometriska former: punkter, linjer (raka linjer, cirkelbågar och kurvor definierade av splines), polygoner, cirklar etc.

Genom generalisering kan du till exempel isolera klassen Endimensionella former och behandla klasserna Rak, Båge och Spline som underklasser i klassen Endimensionella former och Klassen Endimensionella former som en superklass för Rak, Båge och Spline ". Om vi \u200b\u200bsamtidigt accepterar överenskommelsen att superklassens egenskaper (attribut) och operationer är giltiga i var och en av dess underklasser (de säger att dessa egenskaper och operationer ärvs av underklasserna), så är samma egenskaper och funktioner för klasserna "Linje", "Båge" och "Spline" (underklasser) kan flyttas till klassen "Endimensionella figurer" (superklass).

Det är lätt att se att förhållandet mellan klass och superklass (generalisering) och superklass-underklass (arv) är övergående. I det här fallet ärvs egenskaperna och operationerna för varje superklass av dess underklasser på alla nivåer (det är som om samma operationer tas ur parenteserna). Detta förenklar och förkortar klassbeskrivningen avsevärt.

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

Verksamheter som använder fastighetsvärden men inte ändrar dem måste ärvas av alla underklasser.

Alla operationer som ändrar fastighetsvärden måste ärvas i alla tillägg.

Alla operationer som ändrar värdena för begränsade egenskaper eller egenskaper som definierar beroenden måste blockeras i alla sina tillägg (till exempel är X-dimensionen operationen naturlig för ellipsklassen, men måste blockeras i dess cirkelunderklass);

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

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

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

I objektorienterad design kan varje objekt betraktas som en variabel eller konstant av en strukturerad typ. Därför kan en uppsättning objekt ses som en uppsättning sammankopplade data, dvs. något som liknar en databas. Därför är användningen av databaskoncept ofta användbar vid objektorienterad analys och objektorienterad design av tillämpade programvarusystem.

Det objektorienterade tillvägagångssättet bygger på en uppsättning principer som kallas objektmodellen. De viktigaste principerna är

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

Dessa principer är centrala i den meningen att modellen utan dem inte kommer att vara objektorienterad. Förutom de viktigaste kommer vi att nämna ytterligare tre principer:

• - att skriva;
• - parallellism
• - uthållighet.

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

Abstraktion

Människor har utvecklat extremt effektiv teknik för att övervinna komplexitet. Vi abstraherar från det. Om vi \u200b\u200binte kan återskapa ett komplext objekt helt, måste vi ignorera inte alltför viktiga detaljer. Som ett resultat har vi att göra med en generaliserad, idealiserad modell av ett objekt.

När vi till exempel studerar fotosyntesprocessen i växter fokuserar vi på kemiska reaktioner i vissa bladceller och tar inte hänsyn till resten av delarna - sticklingar, vener etc.

Abstraktion belyser de väsentliga egenskaperna hos ett objekt som skiljer det från alla andra typer av objekt och definierar därmed tydligt dess konceptuella gränser ur observatörens synvinkel.

Abstraktion fokuserar på objektets externa egenskaper och låter dig skilja de viktigaste funktionerna i beteendet från det obetydliga. Denna åtskillnad mellan mening och implementering kallas abstraktionens barriär. Upprättandet av en eller annan abstraktionshindring genererar många olika abstraktioner för samma objekt eller fenomen i den verkliga världen. Genom att i större eller mindre utsträckning göra olika aspekter av verklighetens manifestation befinner vi oss på olika abstraktionsnivåer.

Tänk till exempel på datorsystemenheten. En användare som använder en dator för att skriva text bryr sig inte om vilka delar detta block består av. För honom är det en vit ruta med knappar och en diskett. Den tar bort begrepp som "processor" eller "random access memory". Å andra sidan har en programmerare som skriver program i maskinkoder en mycket lägre abstraktionsbarriär. Han behöver känna till processorns struktur och de kommandon den förstår.

En annan ytterligare princip är användbar, kallad principen om minst överraskning. Enligt honom ska abstraktion omfatta allt beteende hos ett objekt, men inte mer eller inte mindre, och inte införa överraskningar eller biverkningar som ligger utanför dess räckvidd.

Vi måste till exempel använda en datastruktur som liknar en stack (med först in, sista ut) åtkomst, men vi måste kontrollera om det finns något element i stacken. Om vi \u200b\u200bkallar denna datastruktur för en stack och erbjuder den till en extern programmerare, kommer han att bli mycket förvånad över att märka den "extra" operationen.

Alla abstraktioner har både statiska och dynamiska egenskaper. Till exempel, en fil som ett objekt kräver en viss mängd minne på en viss enhet, har ett namn och innehåll. Dessa attribut är statiska egenskaper. De specifika värdena för var och en av de listade egenskaperna är dynamiska och förändras under användning av objektet: filen kan ökas eller minskas, dess namn och innehåll kan ändras.

Vi kommer att kalla en klient vilket objekt som helst som använder resurserna för ett annat objekt, som kallas en server. Vi kommer att karakterisera beteendet hos ett objekt med de tjänster det tillhandahåller andra objekt och de operationer som det utför på andra objekt. Detta tillvägagångssätt fokuserar på objektets yttre manifestationer och implementerar den så kallade kontraktprogrammeringsmodellen. Denna modell är som följer: den yttre manifestationen av ett objekt betraktas ur synvinkeln för dess kontrakt med andra objekt, i enlighet med detta måste dess interna struktur också uppfyllas (ofta i interaktion med andra objekt). Kontraktet fixar alla skyldigheter som serverobjektet har gentemot klientobjektet. Med andra ord definierar detta kontrakt objektets ansvar - beteendet som det är ansvarigt för.

Varje operation som tillhandahålls av kontraktet bestäms unikt av dess signatur - en lista med formella parametertyper och en returtyp. Den kompletta uppsättningen operationer som en klient kan utföra på ett annat objekt, tillsammans med rätt ordning i vilken dessa operationer åberopas, kallas ett protokoll. Protokollet återspeglar alla möjliga sätt på vilka ett objekt kan agera eller påverkas. Således definierar protokollet abstraktionens yttre beteende fullständigt.

Exempel. I ett hydroponiskt växthus odlas växter i näringslösning utan sand, grus eller annan jord. Att hantera driftläget för en växthusinstallation är en mycket ansvarsfull sak. Det beror både på vilken typ av grödor som odlas och på odlingsstadiet. Ett antal faktorer måste kontrolleras: temperatur, luftfuktighet, belysning, surhet och näringskoncentration. På stora gårdar används ofta automatiska system för att lösa detta problem, som styr och reglerar dessa faktorer. Målet med automatisering här är att uppnå överensstämmelse med den växande regimen med minimalt mänskligt ingripande.

En av de viktigaste abstraktionerna i denna uppgift är sensorn. Flera typer av sensorer är kända. Allt som påverkar avkastningen måste mätas. Således behövs sensorer för vattentemperatur, lufttemperatur, fuktighet, surhet, belysning och näringskoncentration.

Ur en extern synvinkel är en temperatursensor ett objekt som kan mäta temperaturen där den är belägen. Temperatur är en numerisk parameter som har ett begränsat värdeintervall och en viss precision och representerar antalet grader Celsius.

Platsen för sensorn är en unik plats i växthuset där du behöver veta temperaturen. Det finns förmodligen få sådana platser. För temperatursensorn är det i det här fallet inte själva platsen som är väsentlig, utan bara det faktum att denna sensor är belägen exakt på denna plats.

Låt oss överväga elementen i implementeringen av vår abstraktion på C ++ - språket.

typedef flottör temperatur; // Temperatur i Celsius

typedef osignerad int Plats; // Ett nummer som unikt identifierar

// sensorposition

Här introducerar de två typerna av slutsatserna Temperatur och plats praktiska alias för de enklaste typerna, och detta gör att vi kan uttrycka våra abstraktioner på ett domänspråk. Temperatur är en flytande punkt numerisk datatyp för registrering av temperaturer. Platsvärden indikerar var temperaturgivare kan placeras.

Tänk på en temperatursensors ansvar. Sensorn måste känna till temperaturen på sin plats och rapportera den på begäran. Klienten kan utföra följande åtgärder i förhållande till sensorn: kalibrera sensorn och ta emot det aktuella temperaturvärdet från den. Således har objektet "Temperatursensor" två operationer: "Kalibrera" och "Aktuell temperatur".

struct Temperatursensor (

Temperatur curTemperature; // aktuell temperatur i

// sensorplats

Plats lok; // sensorplats

ogiltig kalibrering (aktuell temperatur); // kalibrera

Temperaturström Temperatur (); // aktuell temperatur

Denna beskrivning introducerar en ny typ, Temperatursensor. Det viktiga här är att för det första kombineras data och funktioner som ändrar dem i en beskrivning och för det andra arbetar vi inte direkt med data utan ändrar dem genom motsvarande funktioner.

Objekt av denna typ anges på samma sätt som variabler av standardtyper:

Temperatursensor TSensorer; // en matris med hundra objekt av typen

// Temperatursensor

Funktioner som deklareras i en beskrivning kallas medlemsfunktioner. De kan bara anropas för en variabel av motsvarande typ. Du kan till exempel kalibrera en sensor så här:

TSensorer. kalibrera (0.); // sensor nummer 3 är kalibrerad

Eftersom namnet på objektet som medlemsfunktionen kallas för implicit överförs till det saknas funktionsargumentlistorna ett argument av typen TemperatureSensor som specificerar den specifika sensorn som ska användas. Detta objekt i funktionen kan uttryckligen hänvisas till med denna pekare. Till exempel, i kroppen för kalibreringsfunktionen, kan du skriva en av två motsvarande operatörer

detta -\u003e curTemperature \u003d actualTemperature;

Den centrala idén om abstraktion är begreppet en invariant. En invariant är något booleskt tillstånd vars värde (sant eller falskt) måste bevaras. För varje operation av ett objekt kan du ange förutsättningar (dvs. invarianter som antas av operationen) och postconditions (dvs. invarianter som operationen uppfyller).

Tänk på invarianter som är associerade med den aktuella temperaturoperationen. Förutsättningen inkluderar antagandet att sensorn är installerad på rätt plats i växthuset, och efterförutsättningen att sensorn returnerar ett temperaturvärde i grader Celsius.

Att ändra invarianten bryter mot kontraktet i samband med abstraktion. Om förutsättningen bryts, uppfyller inte klienten sina skyldigheter och servern kan inte slutföra uppgiften korrekt. Om postvillkoren bryts bryter servern sina skyldigheter och klienten kan inte längre lita på honom.

För att kontrollera villkor tillhandahåller C ++ speciella faciliteter i assert.h-biblioteket.

Om ett villkor bryts, tas ett undantag upp. Objekt kan höja undantag för att förhindra ytterligare utförande av operationen och varna andra objekt om problemet, vilket i sin tur kan ta över för att fånga undantaget och hantera problemet.

C ++ har en speciell kontextkänslig mekanism för undantagshantering. Kontexten för att kasta ett undantag är ett försöksblock. Om ett undantag inträffar under utförandet av uttalanden inuti försöksblocket, skickas kontrollen till de undantagshanterare som anges av fångstnyckelordet och ligger under försöksblocket. Syntaktiskt ser fånghanteraren ut som beskrivningen av en funktion med ett argument utan att specificera returtypen. För ett försöksblock kan flera hanterare specificeras, olika i typen av argument.

Ett undantag kastas genom att ange kastnyckelordet med ett valfritt uttrycksargument. Undantaget hanteras genom att anropa fångshanteraren vars parametertyp matchar kastargumenttypen. Om det finns kapslade försöksblock (till exempel på grund av kapslade funktionssamtal) kommer hanteraren för det djupaste blocket att användas. Om en hanterare som motsvarar typen av kastargument inte hittas på denna nivå kommer den aktuella funktionen att avslutas och sökas i ett försöksblock med ett mindre häckningsdjup etc. Efter hanteringen av undantaget överförs kontrollen till uttalandet enligt beskrivningarna av fånghanterarna.

Exempel. Tänk på en stack implementerad med en array med fast längd.

int stack; // högst hundra objekt på stacken

int topp \u003d -1; // numret på det tillgängliga elementet

ogiltigt tryck (int el) (

if (top \u003d\u003d 99) throw (1); // kontrollera överflöde

annars stack [++ topp] \u003d el; // tryck ett objekt på stacken

om (topp \u003d\u003d -1) kast (0); // kontrollera tomhet

annars returstack; // pop ett objekt från stacken

försök (// provblock

catch (int error) (...) // om error \u003d 0, då är stacken tom;

// om error \u003d 1, då är stacken full

Vi har nu alla nödvändiga begrepp för att beskriva processen att bygga en objektmodell. Denna process innehåller följande steg:

· Definition av objekt och klasser;

· Utarbetande av en datalogg;

· Definition av beroenden mellan objekt;

· Definition av 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.

2.2.1. Definition av klasser.Analysen av externa krav för det designade mjukvarusystemet gör att du kan bestämma de objekt och klasser av objekt som är associerade med applikationsproblemet som detta system måste lösa. Alla klasser måste förstås i applikationsdomänen i fråga; klasser relaterade till en datorimplementering, till exempel en lista, en stack, etc. bör inte anges i detta skede.

Du måste börja med att markera möjliga klasser från den skriftliga formuleringen av det tillämpade problemet (tekniska specifikationer och annan dokumentation från kunden). Man bör komma ihåg att detta är ett mycket svårt och avgörande utvecklingsstadium, eftersom projektets ytterligare öde till stor del beror på det.

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

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

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

· vagt definierat (i termer av problemet) klasser (se s. 2.3.1);

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

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

· roll: vissa substantiv definierar rollnamnen i objektmodellen (till exempel ägare, chaufför, chef, anställd; alla dessa namn är associerade med roller i olika beroenden av objekt av klassperson);

· genomförandestrukturer: 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 programvarusystemet; exempel på sådana namn: subrutin, process, algoritm, avbrott etc.

Efter att ha uteslutit 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.

2.2.2. Förberedelse av 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 sig data ordbok, 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 de termer som diskuteras på sitt eget sätt. För ett exempel på en ordlista, se avsnitt 2.3.2.

2.2.3. Beroende definition.Nästa steg i att bygga objektmodellen är att definiera beroenden mellan klasserna. Först och främst utesluts attribut som är uttryckliga referenser till andra klasser från klasserna; sådana attribut ersätts av beroenden. Betydelsen med denna ersättning är att beroenden är en abstraktion av samma nivå som klasser, och därför inte har någon direkt inverkan på det framtida genomförandet (referens till en klass är bara ett sätt att implementera beroenden).

På samma sätt som hur namnen på möjliga klasser erhölls från substantiv som påträffades i det preliminära uttalandet om det tillämpade problemet, kan namnen på möjliga beroenden erhållas från verb eller verbet vänderfinns i det angivna dokumentet. Så här brukar de beskriva: fysisk position (följer, är_ en del, innehåller_in), riktad handling (drivrörelse), kommunikation (samtal_med), tillhörighet (har, är_del), etc. Ett exempel på valet av uttryckliga och implicita verbfraser från den preliminära formuleringen av ett specifikt tillämpat problem beaktas i avsnitt 2.3.3.

Sedan bör onödiga eller felaktiga beroenden tas bort med följande kriterier:

· beroenden mellan uteslutna klasser bör uteslutas eller omformuleras i termer av de återstående klasserna (se avsnitt 2.3.3);

· irrelevanta beroenden och implementeringsberoende bör uteslutas (se 2.3.3).

· åtgärder: Beroendet ska beskriva applikationsområdets strukturella egenskaper och inte mindre händelser (se 2.3.3).

· tränarberoenden: de flesta beroendeförhållandena mellan tre eller flera klasser kan sönderdelas i flera binära beroenden, med hjälp av kvalificeringar, om det behövs (se avsnitt 2.3.3); i vissa (sällsynta fall) misslyckas en sådan sönderdelning; till exempel kan tränarberoendet "Professor undervisar en kurs i rum 628" inte sönderdelas till binärt utan förlust av information;

· härledda beroenden: det är nödvändigt att utesluta beroenden som kan uttryckas genom andra beroenden, eftersom de är överflödiga (se avsnitt 2.3.3); när du eliminerar överflödiga (härledda) beroenden måste du vara särskilt försiktig, eftersom inte alla dubbletter av beroenden mellan klasser är överflödiga. i vissa fall tillåter andra beroenden bara en att fastställa existensen av ett annat härledt beroende, men tillåter inte en att fastställa mångfalden av detta beroende; till exempel i det fall som visas i Fig. 2.36, företaget har många anställda och äger många datorer; varje anställd förses med flera datorer för personligt bruk, dessutom finns det offentliga datorer; kardinaliteten i beroendet som tillhandahålls_till_användning kan inte härledas från beroenden tjänar och äger; även om härledda beroenden inte lägger till ny information är de ofta praktiska; i dessa fall kan de anges i diagrammet genom att markera dem med ett snedstreck.

Figur: 2,36. Icke-redundanta beroenden

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

· felnamnade beroenden: de bör döpas om för att göra deras mening tydlig (se s. 2.3.3);

· rollnamn: du måste lägga till rollnamn där det behövs; rollnamnet beskriver den roll som motsvarande klass spelar i detta beroende utifrån en annan klass som deltar i detta beroende. om rollnamnet är klart från klassnamnet kan det utelämnas (se avsnitt 2.3.3);

· kval: genom att lägga till kvalificeringskällor där det behövs introducerar vi kontextuella element som gör det möjligt för oss att uppnå entydig identifiering av objekt; kvalificeringar låter dig också förenkla vissa beroenden genom att sänka deras mångfald.

· mångfald: 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 systemkrav;

· obeskrivna beroenden måste identifieras och läggas till i modellen.

2.2.4. Förtydligande av attribut.I nästa steg förfinas systemet med attribut: klassens attribut korrigeras och nya attribut införs vid behov. Attribut uttrycker egenskaperna för objekt i klassen i fråga eller bestämmer deras nuvarande tillstånd.

Attribut motsvarar vanligtvis substantiv; t.ex. bilfärg (objektegenskap), markörposition (objektstatus). Attribut tenderar att ha liten effekt på strukturen för objektmodellen.

Man bör inte sträva efter att definiera så många attribut som möjligt: \u200b\u200bett stort antal attribut komplicerar modellen, gör det svårt att förstå problemet. Det är nödvändigt att bara ange de attribut som är relevanta för det utformade applikationssystemet, utan att slumpmässiga, oviktiga och härledda attribut utelämnas.

Tillsammans med attributen för objekt ä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 en viss enhet är viktigare än dess värde, är detta ett objekt, om värdet är viktigare är detta ett attribut: till exempel är en chef ett objekt (det spelar ingen roll vem chefen är, det viktigaste är att någon är), lön är ett attribut (dess betydelse är mycket viktig); 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 fall där du vill att staden ska vara ett attribut ska du definiera förhållandet (säg är) mellan klassföretaget och staden.

· Kval... Om värdet på ett attribut beror på ett specifikt sammanhang bör det göras till en kvalificering (se avsnitt 2.3.4).

· Namn... Namnen matchas i allmänhet bättre med kvalificeringar än objektattribut; i alla fall när ett namn tillåter att man väljer ett objekt från en viss uppsättning, bör det göras till en kvalificering (se avsnitt 2.3.4).

· Identifierare... Objektidentifierare är associerade med deras implementering. I de tidiga stadierna av designen bör de inte ses som attribut.

· Länkattribut... Om någon egenskap inte karaktäriserar själva objektet utan dess koppling till ett annat objekt (objekt) är detta ett länkattribut, inte ett objektattribut.

· Interna värden... Attribut som endast definierar objektets interna tillstånd, osynligt utanför objektet, bör uteslutas från övervägande.

· Ej väsentliga detaljer... Det rekommenderas att attribut utelämnas som inte påverkar prestanda för de flesta operationerna.

2.2.5. Organisation av ett klasssystem med arv.Därefter måste du försöka hitta superklasser för de introducerade klasserna. Detta är användbart eftersom det klargör modellens struktur och underlättar efterföljande implementering. Ett exempel ses i avsnitt 2.3.5.

2.2.6. Ytterligare forskning och förbättring av modellen.Endast i mycket sällsynta fall är den konstruerade objektmodellen omedelbart korrekt. Modellen måste granskas och felsökas. Vissa fel kan hittas när man undersöker en modell utan dator, andra - när man tolkar den tillsammans med dynamiska och funktionella modeller på en dator (dessa modeller är byggda efter att objektmodellen redan har byggts).

Här kommer vi att titta på tekniker för datorfri sökning och felkorrigering i objektmodellen. De är baserade på externa tecken, som kan användas för att hitta fel i modellen; dessa tecken kan kombineras i följande grupper.

Tecken på ett saknat objekt (klass):

· Asymmetri av relationer och generaliseringar (arv); för att åtgärda felet måste du lägga till de saknade klasserna;

· Inkonsekvens av attribut och operationer i klassen; för att fixa felet är det nödvändigt att dela upp klassen i flera andra klasser, så att attributen och operationerna för de nya klasserna motsvarar varandra;

· En operation hittas som inte har ett tillfredsställande målbetyg; för att åtgärda felet, lägg till den saknade målklassen;

· Hittade flera beroenden med samma namn och syfte; för att åtgärda felet måste du generalisera och lägga till den saknade superklassen.

Tecken på en onödig (extra) klass:

· Brist på attribut, operationer och beroenden i någon klass; för att åtgärda felet, överväga om en sådan klass ska uteslutas.

Symtom på saknade beroenden:

· Det finns inga åtkomstvägar till operationer; För att åtgärda felet måste du lägga till nya beroenden för att betjäna motsvarande förfrågningar.

Tecken på onödiga (onödiga) beroenden:

· Redundant information i beroenden; För att åtgärda felet måste du utesluta beroenden som inte lägger till ny information eller markera dem som härledda beroenden.

· Det finns inte tillräckligt med operationer som går över beroendet; för att åtgärda felet måste du överväga om ett sådant beroende ska elimineras.

Tecken på felaktig placering av beroenden:

· Rollnamn är för breda eller för smala för sina klasser. för att åtgärda felet måste du flytta beroendet upp eller ner i klasshierarkin.

Tecken på felaktig placering av attribut:

· Det finns inget behov av att komma åt objektet med värdena för ett av dess attribut; för att åtgärda felet måste du överväga om du behöver införa ett kvalificerat beroende.

För exempel på praktisk tillämpning av de beskrivna funktionerna, se avsnitt 2.3.6.

Exempel på objektmodell

Tänk på processen att bygga en objektmodell för ett banksystem i processen att analysera kraven och den preliminära utformningen av detta system. För att bygga en objektmodell av systemet som övervägs måste vi slutföra alla steg som anges i avsnitt 2.2.

2.3.1. Definition av objekt och klasser.I avsnitt 1.3 formuleras uppgiften och ett diagram över banktjänstnätverket visas (figur 1.3). Genom att analysera denna formulering av problemet kan man utpeka möjliga klasser genom att jämföra dem med substantiv som nämns i dess preliminära formulering; du får följande lista över möjliga klassnamn (i alfabetisk ordning):

Låt oss granska den här listan, med undantag för klassnamnen från den i enlighet med rekommendationerna i avsnitt 2.2.1:

· överflödiga klasser: det är tydligt att klienten och användaren menar samma koncept; det är mer naturligt att banksystemet lämnar klientklassen;

· irrelevanta klasser: den här klassen är prisklassen (den är inte direkt relaterad till driften av banknätverket);

· vagt definierade klasser: sådana klasser är record_maintenance_service och säkerhetskontroll (dessa tjänster är en del av utstationering), system (i vårt fall är det inte klart vad det är), bank_network (hela PS kommer att betjäna banknätverket);

· attribut: bokföra data, kontodata, pengar (som betyder riktiga pengar som utfärdas till kunden av kassören eller bankomaten eller accepteras av kassören), ett kvitto (utfärdat till kunden tillsammans med pengarna) är mer naturligt att ha som attribut

· genomförandestrukturer uttrycka namn som programvara och åtkomst; de bör också uteslutas från listan över möjliga klassnamn.

Efter att ha eliminerat alla onödiga namn på möjliga klasser får vi följande lista över klasser som utgör det utformade banksystemet (dessa klasser visas i figur 2.5):

2.3.2. Förberedelse av dataordbok.Här är en del av dataordlistan som innehåller definitionerna av de klasser som används i projektet.

ATM (ATM) är en terminal som gör det möjligt för klienten att utföra sin egen bokning med sitt kort för identifiering. ATM (ATM) interagerar med klienten för att erhålla nödvändig information för transaktionen, skickar informationen för transaktionen till central_datorn så att den kan kontrollera den och sedan använda den när du gör transaktionen och utfärdar pengar och ett kvitto till kunden . Det antas att ATM (ATM) inte krävs för att fungera oberoende av nätverket.

En bank är en finansiell institution som underhåller sina kunders konton och utfärdar kort som ger tillstånd till konton via ATM-nätverket.

Kort - ett plastkort som banken överlämnar till sin klient, vilket ger tillgång till konton via ATM-nätverket. Varje kort innehåller en bankkod och ett kortnummer, kodat i enlighet med nationella standarder för bankkort. Bank_code identifierar unikt banken inom konsortiet. Kortnummer definierar konton som kortet har åtkomst till. Kortet ger inte nödvändigtvis åtkomst till alla kundkonton. Varje kort kan endast ägas av en kund, men det kan ha flera kopior, så det bör övervägas att använda samma kort från olika bankomater (ATM) samtidigt.

Kassör är en bankanställd som har rätt att göra transaktioner från POS-terminaler, samt acceptera och utfärda pengar och checkar till kunder. Transaktionerna, pengarna och checkarna som varje kassör arbetar med måste registreras och bokföras korrekt.

Cash terminal - terminalen från vilken kassören gör transaktioner för kunder. När kassören accepterar och utfärdar pengar och checkar skriver kassaterminalen ut kvitton. POS-terminalen interagerar med bank_datorn för att kontrollera och slutföra bokföringen.

Kund - innehavaren av ett eller flera bankkonton. En klient kan bestå av en eller flera personer eller organisationer. Samma person som innehar kontot hos den andra banken behandlas som en annan kund.

Bank_Computer - en dator som ägs av banken som interagerar med ATM-nätverket (ATM) och bankens egna POS_terminals. En bank kan ha sitt eget interna datornätverk för att hantera fakturor, men här tar vi bara hänsyn till den bankdator som interagerar med ATM-nätverket.

Ett konsortium är en sammanslutning av banker som underhåller ATM-nätverket. Nätverket överför banktransaktioner till konsortiet.

Bokföring är en enda integrerad begäran om att utföra en viss sekvens av åtgärder med en kunds konton. Det har föreslagits att uttagsautomater endast avger pengar, men de bör inte uteslutas från att skriva ut checkar eller ta emot pengar och checkar. Vi vill också tillhandahålla systemets flexibilitet, vilket i framtiden kommer att ge möjlighet till samtidig behandling av olika kunders konton, även om detta ännu inte är nödvändigt. De olika operationerna måste vara ordentligt balanserade.

Konto - ett enda bankkonto till vilket transaktioner görs. Konton kan vara av olika slag; en klient kan ha flera konton.

Central_computer är en dator som ägs av ett konsortium som distribuerar transaktioner och deras resultat mellan bankomater (bankomater) och bankdatorer. Den centrala datorn kontrollerar bankkoderna, men bokför inte.

2.3.3. Beroende definition.Efter rekommendationerna i punkt 2.2.3 skiljer vi uttryckligen och implicit verbet vänder från den preliminära redogörelsen för problemet och betrakta dem som namn på möjliga beroenden. Från uttalandet om banknätproblemet (se s. 1.3) kan följande vändningar härledas:

Verb vänder (uttryckligt och implicit):

Banknätverk inkluderar kassör och bankomater

Konsortium distribuerar Resultat för uttagsautomater

Bank äger bankdator

Bankdator stöder konton

Bank äger kontantterminaler

Kontantterminal interagerar med bankdator

Kassör introducerar bokför ovanstående konto

Bankomater påverka varandra med central dator under utstationering

Central dator interagerar med bankdator

Bankomat tar kort

Bankomat kommunicerar med användaren

Bankomat frågor kontanter

Bankomat grafik kvitton

Systemet reglerar kollektiv tillgång

Bank tillhandahåller programvara

Konsortium innefattar banker

Konsortium äger central dator

Systemet tillhandahåller skogsavverkning

Systemet tillhandahåller säkerhet

Kunder ha kort

Kort ger åtkomst till kontot

I banken tjäna kassör

Sedan utesluter vi onödiga eller felaktiga beroenden med hjälp av kriterierna formulerade i avsnitt 2.2.3:

· beroenden mellan uteslutna klasser: följande beroenden är undantagna: Banknätverk inkluderar kassör och bankomater (klass bank_network är undantaget), bankomat grafik kvitton (klasskvitto exkluderat), bankomat frågor kontanter (klasspengar exkluderade), System tillhandahåller bokföring av loggning (klass record_service undantas), System tillhandahåller kontohantering säkerhet (säkerhet_service klass utesluts), banker förse programvara (klass software_software har uteslutits);

· irrelevanta och implementeringsrelaterade beroenden: beroende "System reglerar delad åtkomst "är utesluten som implementeringsrelaterad;

· åtgärder beskrivs av beroenden såsom "ATM tar kort "och" bankomat kommunicerar med användaren "; vi utesluter dessa beroenden;

· tränarberoenden: missbruk "Kassör introducerar bokföringen ovanför kontot "sönderdelas i två binära beroenden" Kassör introducerar ledningar och ledningar refererar till konto. "ATM-beroende påverka varandra med den centrala datorn under utstationering "sönderdelas i" bankomater " påverka varandra med central dator "och" Kabeldragning börja med ATM ";

· härledda beroenden: beroende "Konsortium distribuerar ATM "s" är en följd av beroenden "Consortium äger central dator "och" ATM " påverka varandra med en central dator ".

Efter att ha tagit bort överflödiga beroenden får vi följande lista med beroenden:

Bank äger bankdator

Bankdator stöder konton

Bank äger kontantterminaler

Kontantterminal interagerar med bankdator

Kassör introducerar ledningar

Kabeldragning refererar till konto

Bankomater påverka varandra med central dator

Kabeldragning börjar med bankomat

Central dator interagerar med bankdator

Konsortium innefattar banker

Konsortium äger central dator

Kunder ha kort

Kort ger åtkomst till kontot

I banken tjäna kassör

Låt oss klargöra semantiken för de återstående beroenden enligt följande:

· döp om felaktigt namngivna beroenden så att deras betydelse blir tydligare; så Computer_bank beroende stöder det är bekvämare att ersätta konton med beroendebank håller konton.

· rollnamn kan utelämnas, eftersom de framgår tydligt av namnen på de klasser som är inblandade i beroendet, t.ex. för ATM: s beroende påverka varandra med en central dator;

· obeskrivna beroenden: Kabeldragning börjar från POS, klienter ha konton, bokföring är registrerad kortet ska läggas till modellen.

Efter att ha klargjort beroenden kan du skapa en första version av objektdiagrammet. För det aktuella problemet kommer det att ha den form som visas i fig. 2,37.

Figur: 2,37. Den första versionen av objektdiagrammet för banknätverket

2.3.4. Förtydligande av attribut.Genom att tillämpa kriterierna formulerade i avsnitt 2.2.4 får vi:

Kortet innehåller bankkod och kortkod; de kan betraktas som attribut för objekt på klasskortet, men det är mer bekvämt att använda dem som kvalificerare, eftersom bank_code ger valet av en bank, vilket minskar mångfalden av konsortiet - bankberoende; för en liknande användning av kortkoden, lägg till bankberoendet släpps ett kort vars kvalificering är kortkod.

Efter att ha gjort de listade ändringarna kommer diagrammet att ta formen som visas i Fig. 2,38.

2.3.5. Organisation av klasssystemet med arv.I det här exemplet är det naturligt att definiera superklasser för objekt som definierar olika terminaler: cash terminal och ATM (ATM), och för objekt som definierar transaktioner: cashier's_wiring och remote_wiring (från ATM).

Genom att göra lämpliga ändringar får vi objektdiagrammet som visas i Fig. 2,39.

Figur: 2,38. Objektdiagram för ett banknätverk efter att ha specificerat attribut och lagt till kvalificeringar

Figur: 2,39. Objektdiagram för bank med avseende på arv

2.3.6. Ytterligare förbättring av modellen.Kortet fungerar i två enheter: som en registreringsenhet i banken (passbook), som ger klienten tillgång till sina konton, och som en datastruktur som ATM arbetar med. Därför är det bekvämt att dela upp kortklassen i två klasser: kortregistrering och kort; den första av dessa klasser ger kunden tillgång till sina bankkonton, och den andra definierar datastrukturen som bankomaten fungerar med.

Det är bekvämt att tänka på en bokningsklass som en sammanställning av ändringsklasser, eftersom en bokföring är en överenskommen sekvens för ändringar av fakturor och andra bankdokument. när man arbetar med bankdokument övervägs tre typer av ändringar: uttag, placering och begäran.

Det är naturligt att kombinera bankklassen med klassen bank_dator och klassen konsortium - med klassen central_dator.

Figur: 2.40. Det sista objektdiagrammet för banknätverket

Efter att ha gjort de listade ändringarna kommer objektdiagrammet att ta formen som visas i Fig. 2.40. Detta slutför konstruktionen av objektmodellen för det preliminära designfasen. Ytterligare förfiningar av objektmodellen kommer att göras i nästa fas av systemets livscykel.

Tilldelning av delsystem

2.4.1. Delsystemskoncept.Så PS är en uppsättning av ö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 ett mjukvarusystem är det bekvämt att anta att alla objektattribut är privata (dvs. de är inte tillgängliga utanför objektet, och för att ta reda på värdet på ett attribut för ett annat objekt i något objekt, eller för att ändra det måste du använda en av de öppna operationerna för detta objekt, om en sådan operation naturligtvis är definierad). Objektoperationer kan vara antingen offentliga eller privata.

Således har varje objekt en strikt definierad gränssnitt, d.v.s. en uppsättning öppna operationer som kan tillämpas på detta objekt. Alla objekt av 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 av motsvarande klass.

Systemobjektmodellen definierar uppsättningen av ömsesidigt beroende objekt som utgör systemet och definierar därför uppsättningen gränssnitt som finns tillgängliga i systemet. Alla databehandlingsfunktioner inom systemet (dvs. i varje objekt som ingår i systemet) bestäms av denna uppsättning gränssnitt, som definierar inre miljö(eller onsdag) system.

Tillsammans med systemets interna miljö kan du definiera det yttre miljön... Det bestäms av funktioner (operationer) som implementeras som en del av systemprogramvaran (dvs. operativsystem, programmeringssystem, olika redigerare, DBMS, etc.), liksom i andra applikationssystem och bibliotek som används tillsammans med systemet. Objekt och funktioner som utgör systemets externa miljö kan också nås inom systemet. För att inte tappa bort detta kan man lägga till ett annat objekt i objektmodellen, vars gränssnitt representerar funktionerna i den externa miljön som används i systemet (ett sådant gränssnitt representerar vanligtvis bara en del av funktionerna i den externa miljön ). Men detta skulle inte vara helt korrekt, eftersom den externa miljön inte implementeras av en utan av flera objekt. Å andra sidan finns det ingen anledning att överväga strukturen för dess externa miljö inom systemet. En väg ut ur denna motsägelse i introduktionen med beaktande av ytterligare en enhet - ett delsystem.

Delsystem är en uppsättning objekt och delsystem som ger viss funktionalitet och interagerar med varandra i enlighet med deras gränssnitt. Gränssnitt för delsystem representerar delmängd enande av gränssnitt för alla objekt och delsystem som utgör detta delsystem. Ett delsystem kan inkludera ett eller flera ömsesidigt beroende objekt och / eller delsystem.

Uppsättningen av gränssnitt för objekt (och delsystem), som i sin helhet utgör ett visst delsystem, är inre miljö av detta delsystem. Varje delsystem måste innehålla ett miljöundersystem som representerar yttre miljön av detta delsystem. Delsystemsmiljön för banktjänstsystemet, betraktad som ett helhetsexempel, visas i fig. 2,41. Gränssnittet för miljöundersystemet definierar i vilken programvarumiljö det designade systemet ska fungera och vilka funktioner i denna miljö som ska användas under dess drift (detta är viktigt när det finns ett behov av att ändra eller ersätta enskilda komponenter i miljön).

Observera att delsystemet miljö endast representerar gränssnittet för banktjänstsystemet med dess externa miljö. Banktjänstsystemets externa miljö består av flera delsystem och bibliotek, och en objektmodell kan också utvecklas för det, som också kan innehålla det system som utvecklas (i den här objektmodellen kommer det att vara ett av delsystemen).

Objektmodellen för banksystemet och dess systemmiljö (extern) kan också avbildas i form av ett objektdiagram (dock kommer detta objektdiagram inte att inkludera objekt, utan endast delsystem; varje delsystem visas på diagrammet som en rektangel med dubbla vertikala sidor). Beroendeförhållandena mellan delsystemen, som visas i detta objektdiagram (fig. 2.42), återspeglar interaktionen mellan det utformade banksystemet och motsvarande delsystem under systemets drift. Detta avgör kraven för det designade systemet till dess systemmiljö.

Figur: 2,41. Objektdiagram för banknätverket, som anger gränssnittet med systemmiljön

Figur: 2,42. Objektdiagram över banknätverket och dess systemmiljö

Introduktionen av konceptet för ett delsystem och förmågan att inkludera i objektmodellen tillsammans med objekt (klasser) och delsystem bestämmer den hierarkiska strukturen för objektmodellen och tillåter användning av OMT-metoden när man utformar ganska komplexa mjukvarusystem som innehåller en stor antal olika objekt och klasser.

2.4.2. Gränssnitt och miljöer.Objekt och delsystem som utgör ett delsystem av högre nivå kommer att kallas komponentersista. Som redan nämnts, för varje komponent som ingår i delsystemets objektmodell, dess gränssnitt, d.v.s. en uppsättning öppna (offentliga) operationer som kan tillämpas på denna komponent (objekt eller delsystem).

Objektgränssnitt definieras av gränssnittet för motsvarande klass och specificeras av listan över signaturer för dess offentliga verksamhet (metoder). Gränssnitt för delsystem definieras genom gränssnitten för dess beståndsdelar och delsystem enligt följande: en operation kan inkluderas i ett delsystemgränssnitt om detta delsystem innehåller ett objekt (delsystem) vars gränssnitt innehåller denna operation. Gränssnitt beskrivs på gränssnittsbeskrivningsspråket IDL (gränssnittsdefinitionsspråk).

Alla möjligheter för databehandling inom ett delsystem (dvs. i varje komponent som ingår i det) bestäms av en uppsättning gränssnitt för dess komponenter, som bestämmer interna miljön i delsystemet.

Om det för något delsystem visar sig att ingen av dess komponenter innehåller en operation som det är önskvärt att inkludera i dess gränssnitt, kan ett objekt läggas till i dess struktur som genomför en sådan operation. Ett sådant objekt kallas gränssnittsobjekt... Gränssnittsobjekt gör att du kan matcha ett delsystems externa gränssnitt med dess yttre miljön, d.v.s. med gränssnitt för andra objekt och delsystem, som tillsammans med det undersökta delsystemet utgör ett delsystem av högre nivå.

Låt oss förklara de introducerade koncepten med hjälp av exemplet med banksystemet. Det kan innehålla ett banksubsystem (i själva verket kommer systemet att ha flera kopior av bankundersystemet - en för varje bank som ingår i konsortiet). I detta fall kommer systemets objektmodell att ha den form som visas i Fig. 2,43.

Figur: 2,43. Objektdiagram för banknätverket efter tilldelning av delsystembanken

I det här fallet utgör de externa gränssnitten för delsystemen, banken och miljön, tillsammans med gränssnitten för ATM-objekt och konsortiet, den interna miljön i banktjänstsystemet. Dess yttre miljö visas i fig. 2,42; den består av de externa gränssnitten för olika mjukvarusystem som används i banksystemet (endast en del av dessa system visas i figuren) och dess egna externa gränssnitt.