Basisconcepten van objectdatamodellen. Objectmodel

Nu hebben we alle benodigde concepten om het proces van het bouwen van een objectmodel te beschrijven. Dit proces omvat de volgende stappen:

· definitie van objecten en klassen;

· voorbereiding van een datawoordenboek;

· bepaling van afhankelijkheden tussen objecten;

· bepaling van objectattributen en verbindingen;

· organisatie en vereenvoudiging van klassen bij gebruik van overerving;

· verder onderzoek en verbetering van het model.

2.2.1. Definitie van klassen. Analyse van externe vereisten voor de ontworpen PS maakt het mogelijk om objecten en klassen van objecten te bepalen die verband houden met het toegepaste probleem dat dit systeem moet oplossen. Alle klassen moeten betekenisvol zijn in het beschouwde toepassingsgebied; klassen die verband houden met computerimplementatie, zoals lijst, stapel, enz. mag in dit stadium niet worden toegediend.

U moet beginnen met het identificeren van mogelijke klassen uit de schriftelijke verklaring van het toegepaste probleem (technische specificaties en andere documentatie verstrekt door de klant). Houd er rekening mee dat dit een zeer moeilijke en verantwoordelijke ontwikkelingsfase is, omdat het toekomstige lot van het project er grotendeels van afhangt.

Bij het identificeren van mogelijke klassen moet u proberen zoveel mogelijk klassen te identificeren, waarbij u de naam opschrijft van elke klasse die in u opkomt. In het bijzonder kan elk zelfstandig naamwoord dat in de voorlopige verklaring van het probleem voorkomt een overeenkomstige klasse hebben. Daarom wordt bij het identificeren van mogelijke klassen elk zelfstandig naamwoord gewoonlijk geassocieerd met een mogelijke klasse.

· overtollige klassen: als twee of meer klassen dezelfde informatie uitdrukken, mag slechts één daarvan behouden blijven;

· irrelevant(niet direct gerelateerd aan het probleem) klassen: voor elke mogelijke klassenaam wordt beoordeeld hoe noodzakelijk deze is in het toekomstige systeem (dit is vaak erg lastig in te schatten); irrelevante klassen zijn uitgesloten;

· slecht gedefinieerd(vanuit het probleemperspectief) klassen(zie artikel 2.3.1);

· attributen: sommige zelfstandige naamwoorden komen meer overeen met attributen dan met klassen; dergelijke zelfstandige naamwoorden beschrijven in de regel de eigenschappen van objecten (bijvoorbeeld naam, leeftijd, gewicht, adres, enz.);

· activiteiten: het is waarschijnlijker dat sommige zelfstandige naamwoorden bewerkingsnamen zijn in plaats van klassen (het is bijvoorbeeld onwaarschijnlijk dat phone_call een klasse aanduidt);

· rollen: Sommige zelfstandige naamwoorden definiëren de namen van rollen in het objectmodel (bijvoorbeeld eigenaar, chauffeur, baas, werknemer; al deze namen zijn geassocieerd met rollen in verschillende objectafhankelijkheden van de persoonsklasse);

· uitvoeringsstructuren: namen die meer verband houden met programmeren en computerhardware mogen in dit stadium niet worden vergeleken met klassen, omdat ze niet de kenmerken van de ontworpen PS weerspiegelen; voorbeelden van dergelijke namen: subroutine, proces, algoritme, interrupt, enz.

Na het elimineren van de namen van alle onnodige (overbodige) mogelijke klassen, zal een voorlopige lijst van klassen waaruit het ontworpen systeem bestaat worden verkregen.

2.2.2. Het datawoordenboek voorbereiden. Individuele woorden hebben te veel interpretaties. Daarom is het noodzakelijk om je helemaal aan het begin van het ontwerp voor te bereiden data woordenboek, met duidelijke en ondubbelzinnige definities van alle objecten (klassen), attributen, bewerkingen, rollen en andere entiteiten die in het project worden beschouwd. Zonder zo'n woordenboek is het bespreken van het project met collega-ontwikkelaars en systeemklanten zinloos, aangezien iedereen de besproken termen op zijn eigen manier kan interpreteren. Voor een voorbeeld van een woordenboek, zie paragraaf 2.3.2.

2.2.3. Definitie van afhankelijkheden. In de volgende fase van het bouwen van een objectmodel worden de afhankelijkheden tussen klassen bepaald. Allereerst worden attributen die expliciete links naar andere klassen zijn, uitgesloten van klassen; dergelijke attributen worden vervangen door afhankelijkheden. Het punt van deze vervanging is dat afhankelijkheden een abstractie vertegenwoordigen op hetzelfde niveau als klassen, en daarom geen directe impact hebben op de toekomstige implementatie (een verwijzing naar een klasse is slechts één manier om afhankelijkheden te implementeren).

Op dezelfde manier waarop de namen van mogelijke klassen werden verkregen uit de zelfstandige naamwoorden in de voorlopige verklaring van het toepassingsprobleem, kunnen de namen van mogelijke afhankelijkheden worden verkregen uit werkwoorden of werkwoordszinnen die in het opgegeven document voorkomen. Dit is hoe ze gewoonlijk beschrijven: fysieke positie (volgt_achter, is_deel, is_bevat), gerichte actie (leidt_naar_beweging), communicatie (praat_met), erbij horen (heeft, is_deel), enz. Een voorbeeld van het isoleren van expliciete en impliciete werkwoorduitdrukkingen uit een voorlopige formulering van een specifiek toegepast probleem wordt besproken in paragraaf 2.3.3.

Verwijder vervolgens onnodige of onjuiste afhankelijkheden aan de hand van de volgende criteria:

· afhankelijkheden tussen uitgesloten klassen moet worden uitgesloten of geherformuleerd in termen van de overige klassen (zie paragraaf 2.3.3);

· irrelevante afhankelijkheden en implementatieafhankelijkheden moeten worden uitgesloten (zie paragraaf 2.3.3);

· acties: de afhankelijkheid moet de structurele eigenschappen van het toepassingsdomein beschrijven, en niet onbelangrijke gebeurtenissen (zie paragraaf 2.3.3);

· trainingsafhankelijkheden: de meeste afhankelijkheden tussen drie of een groot aantal klassen kunnen worden ontleed in verschillende binaire afhankelijkheden, indien nodig met behulp van kwalificaties (zie paragraaf 2.3.3); in sommige (zeldzame) gevallen kan een dergelijke ontleding niet worden uitgevoerd; Zo kan de trenaire afhankelijkheid “De professor geeft een cursus in kamer 628” niet worden ontleed in binaire afhankelijkheid zonder verlies van informatie;

· afgeleide afhankelijkheden: het is noodzakelijk afhankelijkheden uit te sluiten die via andere afhankelijkheden kunnen worden uitgedrukt, aangezien deze overbodig zijn (zie paragraaf 2.3.3); wanneer u overtollige (afgeleide) afhankelijkheden uitsluit, moet u bijzonder voorzichtig zijn, aangezien niet alle duplicerende afhankelijkheden tussen klassen overbodig zijn; in sommige gevallen stellen andere afhankelijkheden ons in staat alleen het bestaan van een andere afgeleide afhankelijkheid vast te stellen, maar stellen ze ons niet in staat de veelheid van deze afhankelijkheid vast te stellen; bijvoorbeeld in het geval getoond in Fig. 2.36, het bedrijf heeft veel werknemers en bezit veel computers; iedere medewerker is voorzien persoonlijk gebruik meerdere computers, daarnaast zijn er computers normaal gebruik; de afhankelijkheidsmultipliciteit die voor gebruik wordt verschaft, kan niet worden afgeleid uit de afhankelijkheid die wordt geboden en bezit; hoewel afgeleide afhankelijkheden niets toevoegen nieuwe informatie, ze zijn vaak handig; in deze gevallen kunnen ze op het diagram worden aangegeven door ze met een schuine streep te markeren.

Rijst. 2.36. Niet-redundante afhankelijkheden

Nadat u overtollige afhankelijkheden hebt verwijderd, moet u de semantiek van de resterende afhankelijkheden als volgt verduidelijken:

· verkeerd benoemde afhankelijkheden: ze moeten worden hernoemd zodat hun betekenis duidelijk wordt (zie paragraaf 2.3.3);

· rol namen: u moet waar nodig rolnamen toevoegen; de rolnaam beschrijft de rol die de overeenkomstige klasse speelt in een bepaalde afhankelijkheid vanuit het gezichtspunt van een andere klasse die aan die afhankelijkheid deelneemt; als de rolnaam duidelijk blijkt uit de klassenaam, kan deze worden weggelaten (zie paragraaf 2.3.3);

· kwalificatietoernooien: Door waar nodig kwalificaties toe te voegen, introduceren we contextelementen, waardoor we een ondubbelzinnige identificatie van objecten kunnen bereiken; kwalificaties maken het ook mogelijk om sommige afhankelijkheden te vereenvoudigen door de veelheid ervan te verminderen;

· veelheid: het is noodzakelijk om aanduidingen toe te voegen voor de veelheid aan afhankelijkheden; Er moet aan worden herinnerd dat de veelheid aan afhankelijkheden kan veranderen tijdens het proces van verdere analyse van systeemvereisten;

· niet-verantwoorde afhankelijkheden moet worden geïdentificeerd en aan het model worden toegevoegd.

2.2.4. Kenmerkverduidelijking. In de volgende fase wordt het attributensysteem verduidelijkt: klassenattributen worden aangepast en indien nodig worden nieuwe attributen geïntroduceerd. Attributen drukken de eigenschappen uit van objecten van de betreffende klasse, of bepalen hun huidige status.

Attributen komen meestal overeen met zelfstandige naamwoorden; bijvoorbeeld car_color (objecteigenschap), cursor_position (objectstatus). Attributen hebben in de regel weinig invloed op de structuur van het objectmodel.

Probeer niet zoveel mogelijk attributen te definiëren: een groot aantal van attributen compliceren het model en maken het moeilijk om het probleem te begrijpen. Het is noodzakelijk om alleen die attributen in te voeren die relevant zijn voor het ontworpen applicatiesysteem, waarbij willekeurige, onbelangrijke en afgeleide attributen worden weggelaten.

Naast objectattributen is het ook nodig om attributen van afhankelijkheden tussen klassen (relaties tussen objecten) in te voeren.

Bij het specificeren van attributen worden ze geleid door de volgende criteria:

· Attributen vervangen door objecten. Als de aanwezigheid van een entiteit belangrijker is dan de waarde ervan, dan is het een object als betekenis is belangrijker, dan is dit een attribuut: een baas is bijvoorbeeld een object (het maakt niet uit wie de baas is, het belangrijkste is dat iemand dat is), salaris is een attribuut (de betekenis ervan is erg belangrijk); stad is altijd een object, hoewel het in sommige gevallen lijkt alsof het een attribuut is (bijvoorbeeld stad als onderdeel van een bedrijfsadres); in gevallen waarin u stad als attribuut wilt hebben, moet u een afhankelijkheid (bijvoorbeeld locatie) definiëren tussen de klassen firma en stad.

· Kwalificaties. Als de waarde van een attribuut afhangt van een specifieke context, moet er een kwalificatie van worden gemaakt (zie paragraaf 2.3.4).

· Namen. Namen komen doorgaans beter overeen met kwalificaties dan met objectattributen; in alle gevallen waarin een naam het mogelijk maakt om te selecteren uit objecten van een bepaalde set, moet er een kwalificatie van worden gemaakt (zie paragraaf 2.3.4).

· Identificatiegegevens. Object-ID's zijn gekoppeld aan hun implementatie. In de vroege stadia van het ontwerp mogen ze niet als attributen worden beschouwd.

· Koppelingsattributen. Als een eigenschap niet het object zelf karakteriseert, maar de relatie met een ander object (objecten), dan is dit een attribuut van de verbinding en niet een attribuut van het object.

· Interne waarden. Attributen die alleen de interne toestand van een object definiëren en onzichtbaar zijn buiten het object, moeten buiten beschouwing worden gelaten.

· Onbelangrijke details. Het wordt aanbevolen om attributen weg te laten die de uitvoering van de meeste bewerkingen niet beïnvloeden.

2.2.5. Een klassensysteem organiseren met behulp van overerving. Vervolgens moet je proberen superklassen te vinden voor de geïntroduceerde klassen. Dit is nuttig omdat het de structuur van het model verduidelijkt en de daaropvolgende implementatie eenvoudiger maakt. Het voorbeeld wordt besproken in paragraaf 2.3.5.

2.2.6. Verder onderzoek en verbetering van het model. Slechts in zeer zeldzame gevallen blijkt het geconstrueerde objectmodel onmiddellijk te kloppen. Het model moet worden onderzocht en gedebugd. Sommige fouten kunnen worden gevonden bij het onderzoeken van een model zonder computer, andere bij het interpreteren ervan samen met dynamische en functionele modellen op een computer (deze modellen worden gebouwd nadat het objectmodel al is gebouwd).

Hier zullen we kijken naar technieken voor het computervrij zoeken en corrigeren van fouten in het objectmodel. Ze zijn gebaseerd op externe tekens die kunnen worden gebruikt om fouten in het model te vinden; deze tekens kunnen worden gecombineerd in de volgende groepen.

Tekenen van een ontbrekend object (klasse):

· asymmetrie van verbindingen en generalisaties (overerving); om de fout op te lossen, moet je de ontbrekende klassen toevoegen;

· mismatch tussen attributen en operaties van een klasse; om de fout te corrigeren, is het noodzakelijk om de klasse in verschillende andere klassen te splitsen, zodat de attributen en bewerkingen van de nieuwe klassen met elkaar corresponderen;

· er is een operatie gedetecteerd waarvoor geen bevredigende doelklasse bestaat; Om de fout op te lossen, moet u de ontbrekende doelklasse toevoegen;

· er zijn verschillende afhankelijkheden met dezelfde namen en doeleinden gevonden; Om de fout op te lossen, moet u generaliseren en de ontbrekende superklasse toevoegen.

Tekenen van een onnodige (overbodige) klasse:

· gebrek aan attributen, operaties en afhankelijkheden van een bepaalde klasse; Om de fout te corrigeren, moet u overwegen of een dergelijke klasse moet worden uitgesloten.

Tekenen van ontbrekende afhankelijkheden:

· er zijn geen toegangswegen tot operaties; Om de fout op te lossen, moet u nieuwe afhankelijkheden toevoegen die de mogelijkheid bieden om aan de bijbehorende verzoeken te voldoen.

Tekenen van onnodige (overbodige) afhankelijkheden:

· redundante informatie in afhankelijkheden; om de fout te corrigeren, is het noodzakelijk afhankelijkheden uit te sluiten die geen nieuwe informatie toevoegen, of ze te markeren als afgeleide afhankelijkheden;

· er zijn niet genoeg operaties die de afhankelijkheid overschrijden; Om de fout te corrigeren, moet u overwegen of een dergelijke afhankelijkheid moet worden uitgesloten.

Tekens onjuiste plaatsing afhankelijkheden:

· rolnamen zijn te breed of te smal voor hun klassen; Om de fout op te lossen, moet u de afhankelijkheid naar boven of beneden in de klassenhiërarchie verplaatsen.

Tekenen van onjuiste plaatsing van attributen:

· het is niet nodig om toegang te krijgen tot een object via de waarden van een van zijn attributen; Om de fout op te lossen, moet u overwegen of u een gekwalificeerde afhankelijkheid moet introduceren.

Voorbeelden praktische toepassing Voor de beschreven symptomen zie paragraaf 2.3.6.

Voorbeeld objectmodel

Laten we eens kijken naar het proces van het bouwen van een objectmodel voor een bankservicesysteem tijdens het analyseren van de vereisten en het voorlopige ontwerp van dit systeem. Om een objectmodel van het systeem in kwestie te bouwen, moeten we alle stappen in paragraaf 2.2 voltooien.

2.3.1. Definitie van objecten en klassen. In paragraaf 1.3 wordt de taak geformuleerd en wordt een diagram van het bankservicenetwerk getoond (Fig. 1.3). Door deze probleemstelling te analyseren, is het mogelijk mogelijke klassen te identificeren door ze te matchen met de zelfstandige naamwoorden die in de voorlopige formulering worden genoemd; Dit resulteert in de volgende lijst met mogelijke klassenamen (in alfabetische volgorde):

We onderzoeken deze lijst, waarbij we klassenamen ervan uitsluiten in overeenstemming met de aanbevelingen van paragraaf 2.2.1:

· overbodige lessen: Het is duidelijk dat opdrachtgever en gebruiker hetzelfde begrip bedoelen; Voor banksysteem het is natuurlijker om de klantenklas te verlaten;

· irrelevante klassen: een dergelijke klasse is de prijsklasse (deze houdt niet direct verband met de werking van het banknetwerk);

· slecht gedefinieerde klassen: dergelijke klassen zijn record_keeping_service en security check (deze services maken deel uit van de posting), system (in ons geval is het niet duidelijk wat dit is), banking_network (de hele PS zal het banknetwerk bedienen);

· attributen: transactiegegevens, rekeninggegevens, geld (dat wil zeggen echt geld dat aan de klant wordt gegeven door een kassier of geldautomaat, of geaccepteerd door de kassier), ontvangstbewijs (uitgegeven aan de klant samen met het geld) is natuurlijker om als attributen te hebben;

· uitvoeringsstructuren uitdrukkelijke namen zoals software_software en toegang; ze moeten ook worden uitgesloten van de lijst met mogelijke klassenamen.

Nadat we alle onnodige namen van mogelijke klassen hebben geëlimineerd, verkrijgen we de volgende lijst met klassen waaruit het ontworpen banksysteem bestaat (deze klassen worden weergegeven in figuur 2.5):

2.3.2. Het datawoordenboek voorbereiden. Hier is een deel van de datadictionary met definities van de klassen die in het project worden gebruikt.

ATM (ATM) is een terminal waarmee de klant zijn eigen transacties kan uitvoeren met behulp van zijn kaart ter identificatie. De ATM (ATM) communiceert met de klant om de noodzakelijke transactie-informatie te verkrijgen, stuurt de transactie-informatie naar de centrale computer voor verificatie en verder gebruik bij de transactie, en geeft geld en een ontvangstbewijs uit aan de klant. Aangenomen wordt dat de ATM (geldautomaat) niet onafhankelijk van het netwerk hoeft te functioneren.

Een bank is een financiële organisatie die rekeningen aanhoudt voor haar klanten en kaarten uitgeeft die toegang tot rekeningen autoriseren via een geldautomaatnetwerk.

Kaart - een plastic kaart die door een bank aan haar klant wordt uitgegeven en die toegang tot rekeningen via het ATM-netwerk autoriseert. Elke kaart bevat een bankcode en kaartnummer, gecodeerd in overeenstemming met de nationale normen voor bankkaarten. De bank_code identificeert op unieke wijze de bank binnen het consortium. Het kaartnummer bepaalt tot welke rekeningen de kaart toegang heeft. De kaart geeft niet noodzakelijkerwijs toegang tot alle klantenrekeningen. Elke kaart kan slechts het eigendom zijn van één klant, maar er kunnen meerdere exemplaren bestaan, dus hier moet rekening mee worden gehouden gelijktijdig gebruik dezelfde kaart uit verschillende geldautomaten (ATM's).

Een kassier is een bankmedewerker die het recht heeft om transacties uit te voeren via geldautomaten, en om geld en cheques aan klanten te accepteren en uit te geven. Transacties, geld en cheques waarmee elke kassier werkt, moeten worden geregistreerd en correct worden verantwoord.

Cash_terminal - de terminal van waaruit de kassier transacties voor klanten uitvoert. Wanneer de kassier geld en cheques accepteert en uitgeeft, drukt de POS-terminal de bonnen af. De POS-terminal werkt samen met de bankcomputer om de boeking te controleren en te voltooien.

Cliënt is houder van één of meerdere bankrekeningen. De opdrachtgever kan bestaan uit één of meerdere personen of organisaties. Dezelfde persoon die een rekening bij een andere bank heeft, wordt als een andere cliënt behandeld.

Bank_computer is een computer die eigendom is van de bank en die communiceert met het ATM-netwerk en de eigen cash_terminals van de bank. Een bank kan een eigen intern computernetwerk hebben voor het verwerken van facturen, maar hier kijken we alleen naar de bank_computer die communiceert met het ATM-netwerk.

Het consortium is een vereniging van banken die zorgt voor de werking van het ATM-netwerk. Het netwerk verzendt banktransacties naar het consortium.

Een boeking is één enkel geïntegreerd verzoek om een bepaalde reeks bewerkingen uit te voeren op de rekeningen van één klant. Er wordt aangenomen dat geldautomaten (geldautomaten) alleen geld uitdelen, maar ze mogen de mogelijkheid niet uitsluiten om cheques af te drukken of geld en cheques te accepteren. Ook willen wij graag de flexibiliteit van het systeem waarborgen, waardoor het in de toekomst mogelijk wordt om gelijktijdig rekeningen van verschillende klanten te verwerken, al is dat nog niet nodig. Diverse operaties moet goed in balans zijn.

Account - één bankrekening waarop boekingen worden gedaan. Rekeningen kunnen dat wel zijn verschillende types; een klant kan meerdere accounts hebben.

Centrale_computer - een computer die eigendom is van een consortium dat transacties en hun resultaten verdeelt tussen geldautomaten (geldautomaten) en bankcomputers. De centrale computer controleert de bankcodes, maar post deze niet.

2.3.3. Definitie van afhankelijkheden. In navolging van de aanbevelingen uit paragraaf 2.2.3 maken we onderscheid tussen expliciet en impliciet werkwoordszinnen uit de voorlopige verklaring van het probleem en beschouw ze als namen van mogelijke afhankelijkheden. Uit de formulering van het probleem van het bankennetwerk (zie paragraaf 1.3) kunnen de volgende uitdrukkingen worden afgeleid:

Werkwoordzinnen (expliciet en impliciet):

Banknetwerk omvat kassiers en geldautomaten

Consortium verdeelt resultaten van transacties via ATM

Bank bezit bankcomputer

Bankcomputer ondersteunt rekeningen

Bank bezit geldautomaten

Geldautomaat interageert met bankcomputer

Kassa komt binnen boeken op de factuur

Geldautomaten interageren met de centrale computer tijdens de bedrading

Centrale computer interageert met bankcomputer

Geldautomaat accepteert kaart

Geldautomaat communiceert met gebruiker

Geldautomaat problemen contant geld

Geldautomaat afdrukken ontvangstbewijzen

Systeem reguleert gedeelde toegang

Bank biedt software

Consortium omvat banken

Consortium bezit centrale computer

Systeem biedt loggen

Systeem biedt veiligheid

Klanten hebben kaarten

Kaart biedt toegang naar de rekening

In de bank dienen kassiers

Vervolgens sluiten we onnodige of onjuiste afhankelijkheden uit aan de hand van de criteria geformuleerd in paragraaf 2.2.3:

· afhankelijkheden tussen uitgesloten klassen: de volgende afhankelijkheden zijn uitgesloten: Banknetwerk omvat kassiers en geldautomaten (exclusief banknetwerkklasse), geldautomaat afdrukken bonnen (exclusief bonnenklasse), ATM problemen contant geld (exclusief klassegeld), Systeem biedt transacties registreren (excl. klasse record_keeping_service), System biedt beveiliging van accountbeheer (klasse security_service uitgesloten), Banken voorzien software (klasse software_software uitgesloten);

· irrelevante afhankelijkheden en implementatiegerelateerde afhankelijkheden: afhankelijkheid "Systeem" reguleert gedeelde toegang" is uitgesloten omdat dit gerelateerd is aan de implementatie;

· acties worden beschreven door afhankelijkheden zoals "ATM accepteert kaart" en "ATM communiceert met de gebruiker"; deze afhankelijkheden sluiten wij uit;

· trainingsafhankelijkheden: verslaving "Kassier" komt binnen posten op de rekening" wordt opgesplitst in twee binaire afhankelijkheden "Cashier komt binnen bedrading" en "Bekabeling verwijst naar account". Afhankelijkheid "geldautomaten". interageren met de centrale computer tijdens bedrading" wordt uitgebreid naar "geldautomaten". interageren met centrale computer" en "Bekabeling begin met GELDAUTOMAAT";

· afgeleide afhankelijkheden: afhankelijkheid "Consortium" verdeelt Geldautomaten zijn een gevolg van de afhankelijkheden van het Consortium bezit centrale computer" en "geldautomaten". interageren met een centrale computer."

Door overtollige afhankelijkheden te verwijderen, krijgen we de volgende lijst met afhankelijkheden:

Bank bezit bankcomputer

Bankcomputer ondersteunt rekeningen

Bank bezit geldautomaten

Geldautomaat interageert met bankcomputer

Kassa komt binnen bedrading

Bedrading verwijst naar rekening

Geldautomaten interageren met centrale computer

Bedrading begint met pinautomaat

Centrale computer interageert met bankcomputer

Consortium omvat banken

Consortium bezit centrale computer

Klanten hebben kaarten

Kaart biedt toegang naar de rekening

In de bank dienen kassiers

Laten we de semantiek van de resterende afhankelijkheden als volgt verduidelijken:

· laten we hernoemen afhankelijkheden verkeerd benoemd zodat hun betekenis duidelijker wordt; dus afhankelijkheid Computer_bank ondersteunt het is handiger om de rekeningen te vervangen door de bankafhankelijkheid houdt rekeningen.

· namen van rollen mogen niet worden gebruikt, omdat ze duidelijk blijken uit de namen van de klassen die bij de afhankelijkheid betrokken zijn, zoals voor de ATM-afhankelijkheid interageren met een centrale computer;

· niet-verantwoorde afhankelijkheden: Bedrading begint van cash_terminal, Klanten hebben Rekeningen, posten geregistreerd kaart moet aan het model worden toegevoegd.

Nadat de afhankelijkheden zijn opgehelderd, kan een eerste versie van het objectdiagram worden samengesteld. Voor het onderzochte probleem zal het de vorm hebben die wordt getoond in Fig. 2.37.

Rijst. 2.37. Eerste versie van het objectdiagram voor het banknetwerk

2.3.4. Kenmerkverduidelijking. Door de criteria toe te passen die zijn geformuleerd in paragraaf 2.2.4, verkrijgen we:

De kaart bevat de bankcode en kaartcode; ze kunnen worden beschouwd als attributen van objecten van de kaartklasse, maar het is handiger om ze als kwalificaties te gebruiken, aangezien de bank_code de keuze van de bank garandeert, waardoor de veelheid van de consortium-bankrelatie wordt verminderd; voor een soortgelijk gebruik van card_code moet u de bankafhankelijkheid toevoegen problemen kaarten, waarvan de kwalificatie card_code is.

Nadat u de bovenstaande wijzigingen heeft aangebracht, zal het diagram de vorm aannemen die wordt weergegeven in Fig. 2.38.

2.3.5. Een klassensysteem organiseren met behulp van overerving. In het beschouwde voorbeeld is het normaal om superklassen te definiëren voor objecten die verschillende terminals definiëren: cash_terminal en ATM (ATM), en voor objecten die transacties definiëren: cashier_transaction en remote_transaction (van een geldautomaat).

Nadat we de juiste wijzigingen hebben aangebracht, verkrijgen we het objectdiagram getoond in Fig. 2.39.

Rijst. 2.38. Objectdiagram voor een banknetwerk na het specificeren van attributen en het toevoegen van kwalificaties

Rijst. 2.39. Objectdiagram voor bankieren rekening houdend met overerving

2.3.6. Verdere verbetering van het model. De kaart fungeert in twee entiteiten: als registratie-eenheid in de bank (bankboekje), die de klant toegang geeft tot zijn rekeningen, en als datastructuur waarmee ATM werkt. Daarom is het handig om de kaartklasse in twee klassen te splitsen: registratiekaart en kaart; de eerste van deze klassen biedt de klant toegang tot zijn bankrekeningen, en de tweede definieert de datastructuur waarmee ATM werkt.

Het is handig om de boekingsklasse voor te stellen als een samenvoeging van wijzigingsklassen, aangezien boeking een overeengekomen volgorde is van het aanbrengen van wijzigingen in rekeningen en andere bankdocumenten; Bij het werken met bankdocumenten wordt rekening gehouden met drie soorten wijzigingen: opname, plaatsing en aanvraag.

Het is normaal om de bankklasse te combineren met de computer_bank-klasse, en de consortiumklasse met de central_computer-klasse.

Rijst. 2.40. Eindaanzicht van het objectdiagram voor het banknetwerk

Na het aanbrengen van de bovenstaande wijzigingen zal het objectdiagram de vorm aannemen die wordt getoond in Fig. 2.40. Hiermee is de constructie van het objectmodel van de voorlopige ontwerpfase voltooid. Verdere verfijningen van het objectmodel zullen worden uitgevoerd in de volgende fasen van de systeemlevenscyclus.

Isolatie van subsystemen

2.4.1. Het concept van een subsysteem. De PS is dus een reeks onderling afhankelijke objecten. Elk object wordt gekenmerkt door een reeks attributen waarvan de waarden de status van het object bepalen, en een reeks bewerkingen die op dit object kunnen worden toegepast. Bij het ontwikkelen van een softwaresysteem is het handig om aan te nemen dat alle attributen van objecten gesloten zijn (dat wil zeggen dat ze niet toegankelijk zijn buiten het object, en om de waarde van een attribuut van een ander object in een object te achterhalen of te wijzigen is het noodzakelijk om een van de openbare bewerkingen van dit object te gebruiken, als een dergelijke bewerking uiteraard is gedefinieerd). Objectbewerkingen kunnen openbaar of privé zijn.

Elk object heeft dus een strikt gedefinieerde koppel, d.w.z. een reeks openbare bewerkingen die op dit object kunnen worden toegepast. Alle objecten van dezelfde klasse hebben dezelfde interface. De interface van een klasse (en bijgevolg van elk object van deze klasse) wordt gespecificeerd door een lijst met handtekeningen van zijn open (publieke) operaties (en methoden die deze implementeren); handtekeningen van gesloten bewerkingen zijn niet opgenomen in de interface van objecten van de overeenkomstige klasse.

Het systeemobjectmodel specificeert de reeks onderling afhankelijke objecten waaruit het systeem bestaat, en definieert daarom de reeks interfaces die binnen het systeem beschikbaar zijn. Alle binnen het systeem (d.w.z. in elk object dat deel uitmaakt van het systeem) worden bepaald door deze reeks interfaces, die de interne omgeving(of woensdag) systemen.

Samen met de interne omgeving van het systeem is het mogelijk om de omgeving ervan te bepalen externe omgeving . Het wordt bepaald door de functies (bewerkingen) die zijn geïmplementeerd als onderdeel van de systeemsoftware (d.w.z. besturingssysteem, programmeersysteem, diverse redacteuren, DBMS, enz.), evenals in andere applicatiesystemen en bibliotheken die in combinatie met het systeem worden gebruikt. Objecten en bewerkingen die de externe omgeving van het systeem vormen, zijn ook binnen het systeem toegankelijk. Om dit in gedachten te houden, zouden we een ander object aan het objectmodel kunnen toevoegen waarvan de interface de omgevingsmogelijkheden zou vertegenwoordigen die in het systeem worden gebruikt (een dergelijke interface vertegenwoordigt gewoonlijk slechts een deel van de mogelijkheden van de externe omgeving). Maar dit zou niet helemaal juist zijn, omdat de externe omgeving niet door één, maar door meerdere objecten wordt gerealiseerd. Aan de andere kant is er binnen het systeem geen reden om rekening te houden met de structuur van de externe omgeving. De uitweg uit deze tegenstrijdigheid is door een andere entiteit in overweging te nemen: een subsysteem.

Subsysteem is een reeks objecten en subsystemen die enige functionaliteit bieden en met elkaar communiceren in overeenstemming met hun interfaces. Subsysteeminterface vertegenwoordigt subgroep het combineren van de interfaces van alle objecten en subsystemen waaruit dit subsysteem bestaat. Een subsysteem kan een of meer onderling afhankelijke objecten en/of subsystemen omvatten.

De set interfaces van objecten (en subsystemen), die samen een bepaald subsysteem vormen, vormt interne omgeving dit subsysteem. Elk subsysteem moet een omgevingssubsysteem bevatten dat representeert externe omgeving dit subsysteem. Het omgevingssubsysteem voor het bankservicesysteem, beschouwd als een end-to-end voorbeeld, wordt getoond in figuur 1. 2.41. De omgevingssubsysteeminterface bepaalt in welke softwareomgeving het ontworpen systeem zal opereren en welke mogelijkheden van deze omgeving tijdens de werking ervan zullen worden gebruikt (dit is belangrijk wanneer er behoefte is aan aanpassing of vervanging individuele onderdelen omgeving).

Merk op dat het omgevingssubsysteem alleen de interface vertegenwoordigt van het bankdienstsysteem met zijn externe omgeving. De externe omgeving van het bankdienstsysteem bestaat uit verschillende subsystemen en bibliotheken, en er kan ook een objectmodel voor worden ontwikkeld, dat ook het te ontwikkelen systeem kan bevatten (in dit objectmodel zal het een van de subsystemen zijn).

Het objectmodel van het bankdienstsysteem en zijn systeem(externe) omgeving kan ook worden weergegeven in de vorm van een objectdiagram (dit objectdiagram bevat echter geen objecten, maar alleen subsystemen; elk subsysteem wordt in het diagram weergegeven als een rechthoek met dubbel verticale zijkanten). De afhankelijkheden tussen de subsystemen weergegeven in dit objectdiagram (Fig. 2.42) weerspiegelen de interactie van het ontworpen banksysteem en de overeenkomstige subsystemen tijdens de werking van het systeem. Dit bepaalt de vereisten van het ontworpen systeem voor zijn systeemomgeving.

Rijst. 2.41. Objectdiagram van het banknetwerk, dat de interface met de systeemomgeving aangeeft

Rijst. 2.42. Objectdiagram van een banknetwerk en zijn systeemomgeving

De introductie van het concept van een subsysteem en de mogelijkheid om subsystemen in het objectmodel op te nemen samen met objecten (klassen) definieert de hiërarchische structuur van het objectmodel en maakt het gebruik van de OMT-methodologie mogelijk bij het ontwerpen van vrij complexe softwaresystemen met groot aantal verschillende objecten en klassen.

2.4.2. Interfaces en omgevingen. De objecten en subsystemen waaruit een subsysteem op een hoger niveau bestaat, worden aangeroepen componenten de laatste. Zoals reeds opgemerkt, geldt voor elke component die deel uitmaakt van het subsysteemobjectmodel zijn koppel, d.w.z. een reeks open (openbare) bewerkingen die op deze component (object of subsysteem) kunnen worden toegepast.

Objectinterface wordt gedefinieerd door de interface van de overeenkomstige klasse en wordt gespecificeerd door een lijst met handtekeningen van zijn openbare operaties (methoden). Subsysteeminterface wordt als volgt gedefinieerd via de interfaces van de samenstellende objecten en subsystemen: een bewerking kan worden opgenomen in de interface van een subsysteem als dit subsysteem een object (subsysteem) bevat waarvan de interface deze bewerking bevat. Interfaces worden beschreven in een interfacebeschrijvingstaal IDL (Interface Definition Language).

Alle binnen het subsysteem (d.w.z. in elke component die deel uitmaakt van de samenstelling ervan) worden bepaald door een reeks interfaces van de componenten ervan, die bepalen interne omgeving van het subsysteem.

Als voor een bepaald subsysteem blijkt dat geen van de componenten ervan een bewerking bevat die wenselijk is om in de interface op te nemen, kan een object dat een dergelijke bewerking implementeert aan de samenstelling ervan worden toegevoegd. Zo'n object wordt genoemd interface-object. Met interfaceobjecten kunt u de externe interface van een subsysteem coördineren met zijn externe omgeving, d.w.z. met interfaces van andere objecten en subsystemen, die samen met het betreffende subsysteem een subsysteem op een hoger niveau vormen.

Laten we de geïntroduceerde concepten uitleggen aan de hand van het voorbeeld van een bankservicesysteem. In zijn samenstelling kan men het banksubsysteem onderscheiden (in feite zal het systeem verschillende kopieën van het banksubsysteem hebben - één voor elke bank die deel uitmaakt van het consortium). In dit geval zal het objectmodel van het systeem de vorm aannemen die wordt getoond in Fig. 2.43.

Rijst. 2.43. Objectdiagram van het banknetwerk na markering van het banksubsysteem

Tegelijkertijd vormen de externe interfaces van de bank- en omgevingssubsystemen, samen met de interfaces van de ATM- en consortiumobjecten, de interne omgeving van het bankdienstsysteem. De externe omgeving wordt getoond in Fig. 2,42; het bestaat uit de externe interfaces van verschillende softwaresystemen die in het banksysteem worden gebruikt (de figuur toont slechts een deel van deze systemen) en zijn eigen externe interface.

De objectgeoriënteerde benadering is gebaseerd op een reeks principes die het objectmodel wordt genoemd. De belangrijkste principes zijn

- abstractie;
- inkapseling;
- modulariteit;
- hiërarchie.

Deze principes zijn de belangrijkste in de zin dat zonder deze principes het model niet objectgeoriënteerd zal zijn. Naast de belangrijkste noemen we nog drie aanvullende principes:

- typen;
- parallellisme;
- behoud.

Door ze optioneel te noemen, bedoelen we dat ze nuttig zijn in het objectmodel, maar niet vereist.

Abstractie

Mensen hebben zich enorm ontwikkeld effectieve technologie het overwinnen van complexiteit. Wij abstraheren ons ervan. Als we niet in staat zijn om volledig te recreëren complex object, dan moet je het niet te veel negeren belangrijke details. Als gevolg hiervan hebben we te maken met een gegeneraliseerd, geïdealiseerd model van het object.

Wanneer we bijvoorbeeld het proces van fotosynthese in planten bestuderen, concentreren we ons op chemische reacties in bepaalde cellen van het blad en besteden we geen aandacht aan andere delen - stekken, aderen, enz.

Abstractie benadrukt de essentiële kenmerken van een object die het onderscheiden van alle andere soorten objecten, en definieert dus duidelijk de conceptuele grenzen ervan vanuit het standpunt van de waarnemer.

Abstractie vestigt de aandacht op externe functies object en stelt u in staat de belangrijkste kenmerken van gedrag te scheiden van de onbelangrijke. Deze scheiding tussen betekenis en implementatie wordt een abstractiebarrière genoemd. Het opwerpen van een of andere barrière voor abstractie leidt tot veel verschillende abstracties voor hetzelfde object of fenomeen echte wereld. In meer of mindere mate abstraheren van verschillende aspecten manifestaties van de werkelijkheid, bevinden we ons op verschillende niveaus van abstractie.

Neem bijvoorbeeld de computersysteemeenheid. Een gebruiker die een computer gebruikt om tekst te typen, maakt het niet uit uit welke delen dit blok bestaat. Voor hem is het een witte doos met knoppen en ruimte voor een diskette. Het abstraheert concepten als ‘processor’ of ‘ RAM". Aan de andere kant, de programmeur, programma schrijven V machinecodes ligt de barrière van abstractie veel lager. Hij moet de structuur van de processor kennen en de commando's die hij begrijpt.

Een ander aanvullend principe is nuttig, het zogenaamde principe van de minste verrassing. Volgens hem moet de abstractie al het gedrag van het object bestrijken, maar niet meer en niet minder, en geen verrassingen of problemen met zich meebrengen. bijwerkingen, die buiten het toepassingsgebied ervan vallen.

We moeten bijvoorbeeld een datastructuur gebruiken die lijkt op een stapel (waarbij toegang wordt uitgevoerd volgens de regel "first in, last out"), maar we moeten controleren op de aanwezigheid van een element in de "stack". Als we deze datastructuur een stapel noemen en deze aan een externe programmeur presenteren, zal hij zeer verrast zijn als hij een “extra” bewerking opmerkt.

Alle abstracties hebben zowel statische als dynamische eigenschappen. Een bestand als object vereist bijvoorbeeld een bepaalde hoeveelheid geheugen op een specifiek apparaat, heeft een naam en inhoud. Deze attributen zijn statische eigenschappen. De specifieke waarden van elk van de vermelde eigenschappen zijn dynamisch en veranderen tijdens het gebruik van het object: het bestand kan worden vergroot of verkleind, de naam en de inhoud kunnen worden gewijzigd.

We noemen een client elk object dat de bronnen van een ander object gebruikt, een zogenaamde server. We zullen het gedrag van een object karakteriseren aan de hand van de diensten die het aan andere objecten levert en de bewerkingen die het op andere objecten uitvoert. Deze aanpak richt zich op de externe manifestaties van het object en implementeert het zogenaamde contractprogrammeringsmodel. Dit model is als volgt: de externe manifestatie van een object wordt beschouwd vanuit het gezichtspunt van zijn contract met andere objecten; in overeenstemming hiermee wordt zijn interne organisatie(vaak - in interactie met andere objecten). In het contract worden alle verplichtingen vastgelegd die het serverobject heeft tegenover het clientobject. Met andere woorden: dit contract definieert de verantwoordelijkheden van het object – het gedrag waarvoor het verantwoordelijk is.

Elke bewerking waarin een contract voorziet, wordt op unieke wijze bepaald door de handtekening ervan: een lijst met formele parametertypen en een retourwaardetype. De volledige reeks bewerkingen die een client op een ander object kan uitvoeren, samen met de juiste volgorde waarin deze bewerkingen worden aangeroepen, wordt een protocol genoemd. Het protocol weerspiegelt alles mogelijke manieren, waardoor een object kan handelen of beïnvloed kan worden. Het protocol bepaalt dus volledig het externe gedrag van de abstractie.

Voorbeeld. In een hydrocultuurkas worden planten gekweekt in een voedingsoplossing zonder zand, grind of andere grond. Het beheren van de bedrijfsmodus van een kasinstallatie is een zeer verantwoorde zaak. Het hangt zowel af van het type gewas dat wordt geteeld als van het stadium van de teelt. Een aantal factoren moeten worden gecontroleerd: temperatuur, vochtigheid, verlichting, zuurgraad en nutriëntenconcentratie. Op grote boerderijen gebruiken ze vaak om dit probleem op te lossen automatische systemen, die deze factoren controleren en reguleren. Het doel van automatisering is hier om met minimale menselijke tussenkomst te voldoen aan het groeiende regime.

Een van de belangrijkste abstracties in dit probleem is de sensor. Er zijn verschillende soorten sensoren bekend. Alles wat van invloed is op de opbrengst moet worden gemeten. Er zijn dus sensoren nodig voor de watertemperatuur, luchttemperatuur, luchtvochtigheid, zuurgraad, verlichting en nutriëntenconcentratie.

MET extern punt In zicht is een temperatuursensor een object dat in staat is de temperatuur te meten waar deze zich bevindt. Temperatuur is een numerieke parameter die een beperkt bereik aan waarden en een bepaalde nauwkeurigheid heeft en een aantal graden Celsius betekent.

De locatie van de sensor is een uniek gedefinieerde plek in de kas, waarvan u de temperatuur moet weten. Er zijn waarschijnlijk maar weinig van dergelijke plaatsen. Bij een temperatuursensor is niet de locatie zelf van belang, maar alleen het feit dat deze sensor zich op deze specifieke plek bevindt.

Laten we eens kijken naar de elementen van het implementeren van onze abstractie in C++.

typedef vlotter Temperatuur; // Temperatuur in Celsius

typedef unsigned int Locatie; // Een getal dat op unieke wijze definieert

// sensorpositie

Hier introduceren de twee typedefinitieoperatoren Temperatuur en Locatie handige aliassen voor de eenvoudigste typen, en dit stelt ons in staat onze abstracties in taal uit te drukken gebied. Temperatuur is numeriek type gegevens in drijvende-kommaformaat voor het registreren van temperaturen. Locatiewaarden geven locaties aan waar temperatuursensoren kunnen worden geplaatst.

Laten we eens kijken naar de verantwoordelijkheden van een temperatuursensor. De sensor moet de temperatuur op zijn locatie kennen en deze desgevraagd rapporteren. De klant kan de volgende acties uitvoeren met betrekking tot de sensor: de sensor kalibreren en hiervan de huidige temperatuurwaarde ontvangen. Het object "Temperatuursensor" heeft dus twee bewerkingen: "Kalibreren" en "Huidige temperatuur".

struct Temperatuursensor (

Temperatuur curTemperatuur; // huidige temperatuur in

// sensorlocatie

Locatie loc; // sensorlocatie

void calibrate (actuele temperatuurtemperatuur); // ijken

Temperatuur huidigeTemperatuur(); // Huidige temperatuur

Deze beschrijving introduceert nieuw type Temperatuursensor. Het belangrijkste hier is dat ten eerste de gegevens en de functies die deze wijzigen, samen in één beschrijving worden gecombineerd en ten tweede dat we niet rechtstreeks met de gegevens werken, maar deze wijzigen via de juiste functies.

Voorwerpen van dit type worden op dezelfde manier ingevoerd als variabelen van standaardtypen:

Temperatuursensor TSensoren; // array van honderd objecten van het type

// Temperatuursensor

Functies die binnen een declaratie worden gedeclareerd, worden lidfuncties genoemd. Ze kunnen alleen worden aangeroepen op een variabele van het juiste type. U kunt de sensor bijvoorbeeld als volgt kalibreren:

TSensoren. kalibreren(0.); // sensor nummer 3 is gekalibreerd

Omdat de naam van het object waarop de lidfunctie wordt aangeroepen er impliciet aan wordt doorgegeven, bevatten de functieargumentlijsten geen argument van het type TemperatuurSensor dat de specifieke sensor specificeert waarmee moet worden gewerkt. Dit object kan expliciet worden benaderd binnen een functie met behulp van de this-aanwijzer. In de hoofdtekst van de kalibratiefunctie kunt u bijvoorbeeld een van de twee equivalente operatoren schrijven

this -> curTemperature = actueleTemperatuur;

Het centrale idee van abstractie is het concept van invariant. Een invariant is een logische voorwaarde waarvan de waarde (waar of onwaar) behouden moet blijven. Voor elke bewerking van een object kunt u precondities (d.w.z. invarianten die door de bewerking worden aangenomen) en postvoorwaarden (d.w.z. invarianten waaraan de bewerking voldoet) specificeren.

Laten we eens kijken naar de invarianten die zijn gekoppeld aan de currentTemperature-bewerking. De voorwaarde omvat de aanname dat de sensor is geïnstalleerd juiste plaats in een kas, en de voorwaarde is dat de sensor een temperatuurwaarde in graden Celsius retourneert.

Het veranderen van een invariant schendt het contract dat bij de abstractie hoort. Als de voorwaarde wordt geschonden, komt de client zijn verplichtingen niet na en kan de server de taak niet correct voltooien. Als de postvoorwaarde wordt geschonden, heeft de server zijn verplichtingen geschonden en kan de client deze niet langer vertrouwen.

Om de voorwaarden te controleren, biedt de taal C++ speciale tools in de assert.h-bibliotheek.

In geval van overtreding van enige voorwaarde, a uitzonderlijke situatie. Objecten kunnen uitzonderingen genereren om verdere uitvoering van een bewerking te voorkomen en andere objecten op het probleem te wijzen, die op hun beurt het over kunnen nemen om de uitzondering op te vangen en het probleem op te lossen.

C++ heeft een speciaal mechanisme voor de afhandeling van uitzonderingen dat contextgevoelig is. De context voor het genereren van een uitzondering is een try-blok. Als er een uitzondering optreedt bij het uitvoeren van instructies binnen een try-blok, wordt de controle overgedragen aan uitzonderingshandlers, die worden gespecificeerd door het trefwoord catch en zich onder het try-blok bevinden. Syntactisch gezien ziet een catch-handler eruit als een functiedeclaratie met één argument zonder het retourneringstype op te geven. Voor één try-blok kunnen meerdere handlers worden opgegeven, die verschillen in het argumenttype.

Er ontstaat een uitzondering door op te geven trefwoord throw met een optioneel expressieargument. De uitzondering wordt afgehandeld door de catch-handler aan te roepen waarvan het parametertype overeenkomt met het type throw-argument. Als er geneste try-blokken zijn (bijvoorbeeld vanwege het nesten van functieaanroepen), zal de handler van het diepste blok worden gebruikt. Als er op dit niveau geen handler wordt gevonden die overeenkomt met het type throw-argument, wordt exit uitgevoerd. huidige functie en zoeken in een try-blok met minder nestdiepte, enz. Nadat de uitzondering is afgehandeld, wordt de controle overgedragen naar de instructie volgens de beschrijvingen van de catch-handler.

Voorbeeld. Overweeg een stapel die is geïmplementeerd met behulp van een array met een vaste lengte.

int-stapel; // niet meer dan honderd elementen op de stapel

int top=-1; // aantal beschikbare elementen

leegte push (int el) (

if(top == 99) worp (1); // controleer op overloop

anders stapel[++top] = el; // duw het element op de stapel

if(top == -1) worp (0); // controleer op leegte

anders retourstapel; // pop een element uit de stapel

try(//proefblok

catch(int error)(. . .) // als error = 0, dan is de stapel leeg;

// als fout = 1, dan is de stapel vol

Een object is een uniek gedefinieerde entiteit die attributen bevat die de toestanden van een object in de echte wereld beschrijven en de acties die daarmee samenhangen (gedragsregels). In veel opzichten hebben het object en de RDB-entiteit dezelfde eigenschappen, maar de entiteit modelleert alleen de staat, en het object omvat ook de gedragsregels.

Onder de attributen van een object valt het referentieattribuut op: het bevat een waarde/verzameling van waarden, die zelf een object is. Met andere woorden: een referentieattribuut is conceptueel vergelijkbaar vreemde sleutel in RDB of verwijzingen in PL.

Elk object krijgt op het moment van creatie een OID toegewezen. Het heeft de volgende eigenschappen:

1. Gegenereerd door het systeem

2. Identificeert dit object op unieke wijze

3. Het kan niet worden gewijzigd zolang het object blijft bestaan

4. Zodra een object is gemaakt, kan de identificatie ervan onder geen enkele voorwaarde in de toekomst opnieuw worden gebruikt.

5. Hangt niet af van de waarden van de attributen van het object, d.w.z. Twee objecten kunnen dezelfde status hebben, maar ze hebben altijd verschillende OID's.

6. Idealiter is OID verborgen voor gebruikers.

Dankzij OID wordt de integriteit van entiteiten automatisch gegarandeerd.

Een object omvat niet alleen gegevens, maar ook functies (methoden). In een objectbasis kunnen methoden de status van een object wijzigen door attribuutwaarden te wijzigen of een query te maken op bepaalde waarden van specifieke attributen.

Berichten zijn een middel voor interactie tussen objecten. De inhoud van het bericht is een verzoek van het ene object (afzender) naar het andere (ontvanger), waarbij het tweede object wordt gevraagd een van zijn methoden uit te voeren.

Klassen zijn een groep identieke objecten.

Overerving - één klasse wordt gedefinieerd als een speciaal geval (subklasse) van meer algemene klasse(Superklasse). De subklasse erft alle eigenschappen van de superklasse + extra. definieert zijn eigen attributen en methoden. Alle instanties van een subklasse zijn instanties van de superklasse. Substitutieprincipe: een instantie van een subklasse kan altijd elke methode/attribuut van de superklasse gebruiken of in elke constructie waarin de superklasse wordt gebruikt. Het concept van subklasse, superklasse en overerving bestaat ook in het uitgebreide RDB-model. In een puur objectmodel heeft overerving echter betrekking op zowel toestand als gedrag.

Door overbelasting kunt u een methodenaam hergebruiken in een of meer methoden van een klasse. Een speciaal geval van overbelasting is overlap. Hiermee kunt u een eigenschapsnaam in een subklasse opnieuw definiëren.

Met dynamisch koppelen kunt u het koppelen uitstellen tot de uitvoering ervan.

Objectmodellen

Met het objectmodel kunt u enkele problemen oplossen die verband houden met sommige relationele databases.

Problemen:

1. Ondersteuning van meerdere versies

Versiebeheer is het proces waarbij de evolutie van een object wordt gehandhaafd.

Het versietraceringsmechanisme moet wijzigingen in objecteigenschappen beheren, zodat objectreferenties altijd naar de juiste versie verwijzen.

Voor versiebeheer zijn er drie soorten versies: 1) tijdelijke versie - wordt als instabiel beschouwd, kan worden verwijderd of bijgewerkt en wordt opgeslagen in een privéwerkruimte van de projectontwikkelaar.

2) Werkversie - wordt als stabieler beschouwd, kan niet worden bijgewerkt, maar kan door de maker worden verwijderd en wordt ook opgeslagen in een gesloten ontwikkelaarswerkruimte.

3) De vrijgegeven versie (release) wordt als stabiel beschouwd, kan niet worden bijgewerkt of verwijderd en is opgeslagen in database openen en wordt daar geplaatst als resultaat van het extraheren van de werkende versie uit de gesloten ontwikkelaarsruimte.

2. Ondersteuning voor lange transacties

Voor de gebruiker die een langetermijntransactie heeft gestart, is het belangrijk om wat op te slaan tussenresultaten in het geval dat de transactie mislukt, bijvoorbeeld als gevolg van een lock-conflict.

Opties voor probleemoplossing: 1) er wordt een parallel uitvoeringscontroleprotocol met tijdstempels geïntroduceerd.

Voor elk gegevenselement slaat de database drietallen waarden op die overeenkomen met elke verandering in de waarde van het element. Wij slaan op eigenwaarde versie-element, we slaan de laatste keer dat de versie werd geopend op, de tijdstempel van de versie-invoer.

In dit geval mogen meerdere transacties verschillende versies van hetzelfde gegevensitem lezen en schrijven.

Versies kunnen onmiddellijk worden verwijderd nadat de gehele transactie is voltooid.

1) De tijdstempel van de oudste transactie in het systeem wordt bepaald, alles onder deze transactie wordt verwijderd.

2) Verbeterde transactiemodellen worden geïntroduceerd. (de volledige transactie wordt opgesplitst in een boomstructuur van transactiebedragen die parallel worden uitgevoerd.

3) Gebruik van spaarpunten en emulatie van geneste transacties. (Een savepoint is een punt in een vlakke transactie dat wordt gebruikt als tussenliggend herstartpunt.

4) Het kroniekmechanisme (saga) van de database garandeert dat ofwel alle transacties in de kroniek zullen worden voltooid, ofwel compenserende transacties zullen worden gestart.

3. Ondersteuning van de evolutie van het project, d.w.z. Flexibele faciliteiten beschikbaar dynamische definitie en wijzigingen in het databaseschema.

Om dit te bereiken worden verschillende creatieve benaderingen gebruikt. Sommige producten introduceren bijvoorbeeld invariante circuits die bij geen enkele wijziging mogen veranderen.

Over het algemeen zijn methoden voor databasemodificatie gebaseerd op de aanwezigheid of kunstmatige introductie van gedeeltelijke ordening (ordening zoals #) in systeemobjecten; dit is onmogelijk in relationele databases.

Nadeel: vrijwel de objectdatabase wordt handmatig geschreven.

De objectdatabase heeft analogieën met de basistechnieken van het werken in een relationele database.

Normalisatie in een objectbasis betekent dat elk attribuut van een object afhankelijk moet zijn van de objectidentificator.

Relaties in de objectdatabase worden weergegeven met behulp van referentieattributen.

Referentiële integriteit.

Controlemogelijkheden: 1) het is de gebruiker verboden objecten expliciet te verwijderen; het systeem verwijdert zelf objecten die ontoegankelijk worden.

2) de gebruiker mag objecten verwijderen wanneer deze overbodig worden, waarna het systeem automatisch ongeldige referenties detecteert en de ongeldige referentie toewijst aan NULL.

3) de gebruiker mag objecten wijzigen en verwijderen, en het systeem gebruikt omgekeerde attributen.

ALGEMENE KENMERKEN VAN HET OBJECT RELATIONELE DATAMODEL

Algemeen idee Het OR-model bestaat uit het aanvullen van het P-model met objectgeoriënteerde mogelijkheden, namelijk een door de gebruiker uitbreidbaar datatypesysteem, inkapseling, overerving en polymorfisme worden toegevoegd, en het gebruik van complexe objecten en objectidentificatie wordt toegevoegd.

Voordelen: Hergebruik en delen van standaardcomponenten.

De databaseserver wordt aangevuld met standaardfuncties die niet in het formulier geschreven hoeven te worden uitvoerbare code als onderdeel van afzonderlijke toepassingen.

Voorbeeld van ondersteuning lineair programmeren, wanneer functies centraal worden uitgevoerd.

Mogelijkheid tot geleidelijke overgang naar objectmethoden met toenemende gebruikerskwalificaties.

Nadelen: Vervorming van de objectideologie.

GEAVANCEERDE SQL-STANDAARD 3. BASIS VOOR HET OPBOUWEN VAN OBJECTRELATIONELE DBMS

Inclusief: type constructors, de gehele string kan worden opgeslagen als variabelen of worden doorgegeven als parameter of worden geretourneerd als resultaat van een functieaanroep.

Door de gebruiker gedefinieerde typen, procedures, functies en operators zijn toegestaan.

In de regel worden procedures of functies buiten het DBMS geschreven en in SQL aangeroepen met behulp van de CALL-operator.

Constructors voor verzamelingstypen: er wordt een enkele tabel gemaakt waarin er verschillende nestniveaus zijn.

Ondersteuning voor grote objecten. Groot voorwerp- een tabelveld dat een aanzienlijke hoeveelheid gegevens bevat.

De SQL-standaard bevat drie topgrote objecten:

1) klodder

2) groot symbolisch object

De SQL 3-standaard staat bepaalde bewerkingen met objecten toe: bijvoorbeeld de aaneenschakelingsoperator - retourneert een tekenreeks die wordt gevormd door tekenreeksen in de opgegeven volgorde met elkaar te verbinden.

Er zijn functies voor het extraheren van een teken-substring:

Lijnoverlappingsfunctie.

Registreer conversie-vouwfunctie.

Functie voor het berekenen van de lengte van een string.

DATAWAREHOUSE-MODEL

Een datawarehouse is een domeinspecifieke, geïntegreerde, tijdgebonden en onveranderlijke set gegevens die is ontworpen om de besluitvorming te ondersteunen.

Een datawarehouse heeft veel gemeen met het relationele model.

1) Het datawarehouse is niet georganiseerd rond activiteitengebieden, maar rond (objecten, goederen, enz.).

2) De gegevens worden niet bijgewerkt, maar alleen aangevuld.

3) De relationele database is ontworpen om intensieve verwerking van een klein aantal transacties mogelijk te maken, het datawarehouse is ontworpen om afzonderlijke willekeurige zoekopdrachten te verwerken.

4) Het basisobject van het opslagmodel is een tijdsgebonden feit.

5) De belangrijkste operatie is aggregatie en het grootste probleem maximum snelheid toegang tot feiten.

Gegevensopslag.

Databases in het magazijnconcept worden beschreven met behulp van de "dimensionale modellering"-methode.

Elk model van deze methode bestaat uit een tabel met een samengestelde primaire sleutel (feitentabel), waaraan een reeks kleine feiten (dimensionale tabellen) is gekoppeld.

Elke dimensietabel heeft een niet-samengestelde (eenvoudige) hoofdsleutel, die exact overeenkomt met een van de componenten van de samengestelde sleutel in de feitentabel

Sterrenschema - een logische structuur met in het midden een feitentabel, omgeven door een dimensietabel met referentiegegevens, terwijl de dimensietabellen meestal genormaliseerd zijn. (zie sterdiagram)

Feitentabellen zijn meestal enorm groot in vergelijking met dimensietabellen; het grootste deel van de feitentabel bestaat uit numerieke gegevens en de resultaten van het optellen van getallen.

In datawarehouses gebeurt het bijna nooit met afzonderlijke records, basis operatie voor hen is het aggregatie.

Tegelijkertijd bevat de dimensietabel meestal beschrijvend tekst informatie, waarbij dimensieattributen worden gebruikt als beperkingen in query's naar het datawarehouse.

De toepasbaarheid van het datawarehouse-concept is direct afhankelijk van de succesvolle structurering van de dimensietabel.

Het sterschema kan de uitvoering van query's versnellen door middel van denormalisatie, omdat het entiteiten identificeert die vaak worden gebruikt, maar denormalisatie mag niet worden gebruikt als er niet vaak aanvullende gegevens nodig zijn.

Sneeuwvlokkenschema - een variant van het sterrenschema, waarbij elke dimensie zijn eigen dimensies kan hebben.

Voordelen van datawarehouses:

1. Efficiëntie – uniformiteit van de structuur zorgt voor een efficiëntere toegang tot gegevens, ongeacht de toegangsmiddelen.

2. Alle dimensies bieden in gelijke mate toegang tot de feitentabel, waardoor het project een groter vermogen heeft om willekeurige gebruikersvragen te ondersteunen.

3. Uitbreidbaarheid - typische veranderingen:

1. Het toevoegen van nieuwe feiten is mogelijk, op voorwaarde dat deze hetzelfde detailniveau hebben als de feitentabel.

2. Het toevoegen van nieuwe dimensies is mogelijk op voorwaarde dat er voor elk bestaand record in de feitentabel één enkele waarde voor een bepaalde dimensie is gedefinieerd.

3. Nieuwe attributen toevoegen.

4. Bestaande dimensies opsplitsen in records met een lager detailniveau, te beginnen met bepaald punt tijd.

OLAP-gegevensmodel

Tafel binnen relationele DBMS vertegenwoordigt multidimensionale gegevens in slechts 2 dimensies: theorie multidimensionale kubussen toepassingen, die gemakshalve worden weergegeven als een ruimte met dimensie n, kan elke zijde van zo'n kubus worden geïnterpreteerd als een tweedimensionale tafel.

Elke cel van de kubus bevat een afzonderlijk feit, en de reeks coördinaten van deze cel vertegenwoordigt een complete reeks gegevens over dit feit.

1. Multidimensionale databases zijn zeer compact; eenvoudige remedies bekijken en manipuleren van elementen en gegevens.

2. De kubus is eenvoudig uitbreidbaar: elke cel van de kubus kan worden uitgebreid tot een subkubus.

3. Er bestaat een krachtig wiskundig apparaat om met multidimensionale kubussen te werken, dit zijn matrices.

1. Naarmate het aantal dimensies toeneemt, neemt het aantal cellen in een kubus exponentieel toe en neemt de verwerkingstijd van een multidimensionale zoekopdracht toe.

2. Dergelijke structuren zijn in de regel zeer schaarse matrices. Veel NULL.

Voor het creëren van een effectief multidimensionale basis Er zijn verschillende mogelijke manieren:

1. Identificeer de hiërarchische structuur in de gegevens.

2. Identificeer andere roostertype-orden met typische afmetingen.

3. De hyperkubus opsplitsen in vele kleine kubussen met gevulde cellen.

Ongeacht de opslagstructuur wordt de efficiëntie dus bepaald door metadata, dat wil zeggen de verwachte opties voor het plaatsen van gegevens.

Semi-gestructureerd datamodel

Zwak - verwijst naar data die een bepaalde structuur hebben, maar deze structuur blijkt inconsistent, onvoldoende bestudeerd of onvolledig te zijn. Dergelijke gegevens kunnen in de regel niet worden gebruikt. beschreven aan de hand van één onveranderlijk schema.

Als een DBMS semi-gestructureerde gegevens moet opslaan, moet het DBMS op basis van deze gegevens een schema genereren.

De meeste benaderingen voor het beheren van dergelijke gegevens maken gebruik van querytalen die een boomachtige, gelabelde grafiek doorkruisen. Dienovereenkomstig wordt de uitvoering van zoekopdrachten niet decoratief, maar traditioneel.

Opties voor het vastleggen van semi-gestructureerde gegevens:

1. OEM-objectgegevensuitwisselingsmodel. Het model voor het weergeven van meerdere objecten wordt door zichzelf bepaald. Hiermee kunt u gegevens weergeven met een onregelmatige structuur en een ongedefinieerd type. Het is een gelabelde, georiënteerde grafiek, in de knooppunten waarvan er speciale objecten zijn (OEM-objecten), voor elk object is een unieke identificatie gespecificeerd, een beschrijvende tekstlabel, type, waarde. Objecten zijn onderverdeeld in elementair en samengesteld. Elementaire zijn bladeren; ze worden in de grafiek weergegeven zonder uitgaande randen. alle andere worden composiet genoemd, en één en hetzelfde object kan hebben willekeurig nummer bovenliggende objecten. Het type van een bepaald object wordt gedefinieerd als een set object-ID's. Het werken met dit soort constructies is moeilijk, omdat het onmogelijk is een lege grafiekstructuur te selecteren.

2. XML-taal is een metataal, een taal om andere talen te beschrijven. Een systeem voor het definiëren van gestructureerde documenttypen en opmaaktalen die exemplaren van een bepaald documenttype vertegenwoordigen. Voordelen:

1. Kan worden gebruikt om alle documenten te markeren, inclusief tekst en multimedia.

2. Hiermee kunt u de datastructuur duidelijk beschrijven. Kan worden gebruikt om heterogene (heterogene) databases te beschrijven.

3. Hiermee kunt u de inhoud van een document en de presentatiemethode afzonderlijk (onafhankelijk) opslaan.

Relationele algebra en relationele calculus

De SQL-taal ondersteunt algebraïsche formuleringen voor het uitvoeren van zoekopdrachten; de algebraïsche formulering is procedureel, dat wil zeggen: uitdrukkelijk specificeert de reeks acties om het verzoek te voltooien.

Bestaat Alternatieve optie om een vraag te beschrijven die logische calculus wordt genoemd.

Er zijn twee varianten van relationele logica: tupelcalculus en domeincalculus.

Tupelrekening - een variabele is een tupel (rij) van de hoofdtekst van een relatie.

Om voorwaarden te vormen voor het nemen van steekproeven uit een reeks relaties, worden zogenaamde goed gevormde formules gebruikt - dit zijn voorwaarden die worden opgelegd aan tupelvariabelen.

Voorbeeld: WERKNEMER SL_NOM = CHIEF CHIEF_NOM

Om WFF te construeren, worden logische verbindingen en regels van de wiskundige logica gebruikt.

Hoe het werkt: Het systeem doorloopt alle combinaties van tupels die beschikbaar zijn in de database, bijvoorbeeld voor elke tupel van een project, doorzoekt het definitiegebied van werknemers-tupels en selecteert die combinaties van tupels waarvoor WFF waar is.

Dit komt dus overeen met het feit dat het systeem standaard een join-bewerking uitvoert.

Domeincalculus: Het belangrijkste formele verschil tussen domeincalculus en tupelcalculus is de aanwezigheid van een extra reeks predikaten die het mogelijk maken om de lidmaatschapsvoorwaarde te isoleren.

Vergelijking van relationele algebra en relationele calculus.

Formeel zijn er verschillen tussen beide, maar vanuit het oogpunt van het runtime-systeem zijn relationele algebra en relationele calculus logisch gelijkwaardig. Elke uitdrukking relationele algebra kan op unieke wijze worden omgezet in een relationele calculusuitdrukking en vice versa.

Voorbeelden: Subds die op Linux draaien zijn INGRES (Integratie graphics retrielale System) (wat staat er, het heeft een gebogen onderstreping).

En de taal is in tabelvorm Query by example

Laten we eens kijken naar het proces van het construeren van een objectmodel voor een bankdienstsysteem (zie clausule 1.3) tijdens het proces van het analyseren van de vereisten en het voorlopige ontwerp van dit systeem. Om een objectmodel van het systeem in kwestie te bouwen, moeten we alle stappen voltooien die in paragraaf 2.2 worden vermeld.

2.3.1. Objecten en klassen definiëren

In paragraaf 1.3 wordt de taak geformuleerd en wordt een diagram van het bankservicenetwerk getoond (Fig. 1.3). Door deze probleemstelling te analyseren, is het mogelijk mogelijke klassen te identificeren door ze te vergelijken met de zelfstandige naamwoorden die in de voorlopige formulering worden genoemd; Dit geeft je de volgende lijst met mogelijke klassenamen (in alfabetische volgorde):

We onderzoeken deze lijst, waarbij we klassenamen ervan uitsluiten in overeenstemming met de aanbevelingen van paragraaf 2.2.1:

overbodige lessen: Het is duidelijk dat opdrachtgever en gebruiker hetzelfde begrip bedoelen; voor het banksysteem is het natuurlijker om de klantenklasse te verlaten;

irrelevante klassen: een dergelijke klasse is de prijsklasse (deze houdt niet direct verband met de werking van het banknetwerk);

slecht gedefinieerde klassen: dergelijke klassen zijn de administratiedienst en veiligheidscontrole (deze diensten maken deel uit van de detachering), het systeem (in ons geval is het niet duidelijk wat dit is), het banknetwerk (ons hele softwaresysteem zal het banknetwerk bedienen);

attributen: transactiegegevens, rekeninggegevens, geld (dat wil zeggen echt geld dat aan de klant wordt gegeven door een kassier of geldautomaat, of geaccepteerd door de kassier), ontvangstbewijs (uitgegeven aan de klant samen met het geld) is natuurlijker om als attributen te hebben;

uitvoeringsstructuren uitdrukkelijke namen zoals software en toegang; ze moeten ook worden uitgesloten van de lijst met mogelijke klassenamen.

2.3.2. Het gegevenswoordenboek voorbereiden

Hier is een deel van de datadictionary met definities van de klassen die in het project worden gebruikt.

ATM (ATM) is een terminal waarmee de klant zijn eigen transacties kan uitvoeren met behulp van zijn kaart ter identificatie. De ATM (geldautomaat) communiceert met de klant om de noodzakelijke transactie-informatie te verkrijgen, stuurt de transactie-informatie naar de centrale computer voor verificatie en later gebruik bij het uitvoeren van de transactie, en geeft het geld en de ontvangstbon uit aan de klant. Aangenomen wordt dat de ATM (geldautomaat) niet onafhankelijk van het netwerk hoeft te functioneren.

Een bank is een financiële organisatie die rekeningen aanhoudt voor haar klanten en kaarten uitgeeft die toegang tot rekeningen autoriseren via een geldautomaatnetwerk.

Kaart – een plastic kaart die door een bank aan haar klant wordt uitgegeven en die toegang tot rekeningen via het ATM-netwerk autoriseert. Elke kaart bevat een bankcode en kaartnummer, gecodeerd in overeenstemming met de nationale normen voor bankkaarten. De bankcode identificeert op unieke wijze de bank binnen het consortium. Het kaartnummer bepaalt tot welke rekeningen de kaart toegang heeft. De kaart geeft niet noodzakelijkerwijs toegang tot alle klantenrekeningen. Elke kaart kan slechts het eigendom zijn van één klant, maar er kunnen meerdere exemplaren van zijn. Er moet dus rekening worden gehouden met de mogelijkheid om dezelfde kaart tegelijkertijd bij verschillende geldautomaten (geldautomaten) te gebruiken.

Geldterminal – een terminal van waaruit de kassier transacties voor klanten uitvoert. Wanneer de kassier geld en cheques accepteert en uitgeeft, drukt de POS-terminal de bonnen af. De POS-terminal communiceert met de computer van de bank om de boeking te verifiëren en te voltooien.

Bankcomputer is een computer van de bank die communiceert met het ATM-netwerk en de eigen geldautomaten van de bank. Een bank beschikt weliswaar over een eigen intern computernetwerk voor het verwerken van rekeningen, maar hier kijken we alleen naar de bankcomputer die communiceert met het geldautomatennetwerk.

Een consortium is een vereniging van banken die zorgt voor de werking van het ATM-netwerk. Het netwerk verzendt banktransacties naar het consortium.

Rekening – één enkele bankrekening waarop boekingen worden gedaan. Accounts kunnen van verschillende typen zijn; een klant kan meerdere accounts hebben.

Een centrale computer is een computer die eigendom is van een consortium dat transacties en de resultaten ervan verdeelt tussen geldautomaten (geldautomaten) en bankcomputers. De centrale computer controleert de bankcodes, maar voert niet zelf de boekingen uit.

Samenvatting

Nadelen van het TCP/IP-model

Ondanks zijn enorme populariteit hebben het TCP/IP-model en de bijbehorende protocollen een aantal nadelen:

· gebrek aan onderscheid tussen de conceptuele concepten van interface, protocol en serviceniveau, wat heel duidelijk wordt gedaan in het ISO/OSI-model. Als gevolg hiervan kan het TCP/IP-model niet worden gebruikt bij het ontwikkelen van nieuwe netwerken;

· bij gebruik van het TCP/IP-model kan er geen andere protocolstack dan TCP/IP worden beschreven;

· het model maakt geen onderscheid tussen het fysieke niveau en het kanaalniveau, terwijl deze totaal verschillend zijn en een correct model zou hier rekening mee moeten houden;

· IP- en TCP-protocollen zijn het meest zorgvuldig doordacht en ontwikkeld. Veel van de andere protocollen in de stapel zijn ontwikkeld door studenten (studenten om over na te denken!) en vrij verspreid, waardoor ze in de praktijk wijdverbreid zijn ingebakken en nu moeilijk te vervangen zijn door iets nieuws dat door een commercieel programma wordt aangeboden.

Samenvattend kan worden gezegd dat het ISO/OSI-model nuttig is voor theoretisch onderzoek en ontwikkeling van nieuwe netwerken OSI-protocollen worden niet veel gebruikt. Voor TCP/IP kan het tegenovergestelde worden beweerd: de stack kan niet als een volwaardig model worden beschouwd, terwijl de protocollen zelf goed getest en extreem populair zijn.

Overwegende referentiemodel vanuit het gezichtspunt van de nieuwe eisen die informatiestromen stellen aan het overdrachtsproces in het informatie- en communicatienetwerk moeten twee problemen worden benadrukt.

Ten eerste worden twee onafhankelijke overdrachtsmechanismen geïmplementeerd op de transport- en verbindingslagen. Deze verdeling van de taak van het transporteren van informatie werd ooit gedicteerd door de noodzaak om meerdere netwerken te combineren met behulp van verschillende technologieën voor toegang tot het communicatiekanaal. De aanwezigheid van twee inconsistente transmissiemechanismen creëert echter een probleem bij het garanderen van de kwaliteit van de dienstverlening bij de overdracht van informatie. Bereik gecoördineerd gedrag van transport en kanaalniveaus(via de netwerklaag) is onmogelijk, gebaseerd op het principe van autonomie van lagen in het ISO/OSI-model. Moderne concepten voor de ontwikkeling van netwerken op multiservicebasis (in het bijzonder het NGN-concept) bieden echter strategieën voor gecoördineerd gedrag van de transport- en datalinklagen, waarbij netwerklaag, wat formeel in strijd is met het autonomiebeginsel en buiten de reikwijdte van het referentiemodel valt.

In de tweede plaats vanwege de convergentie van netwerken en de eenwording van informatiestromen diverse diensten in de algemene verzonden stroom van heterogeen verkeer, is het nodig de inhoud ervan te identificeren. In een situatie waarin zeer gespecialiseerde netwerken informatiestromen overbrachten specifieke typen, dit probleem bestond niet.

De meeste fabrikanten van netwerkapparatuur zoeken naar oplossingen voor deze problemen.

Zelfs met de meest oppervlakkige blik op het functioneren van het netwerk wordt dat duidelijk informatie netwerk is een complex complex van software- en hardwarecomponenten. In dit geval is het de software die de functionaliteit van het informatienetwerk bepaalt.

Moderne netwerksoftware in hoogste graad gestructureerd. De kernfuncties en de gehele communicatiearchitectuur (protocolmodellen) zijn grotendeels in de netwerksoftware geïmplementeerd.

Analyse programma structuur Hiermee kunt u rekening houden met de hiërarchie van netwerksoftware. De elementen van deze structuur zijn softwaremodules waarin netwerkobjecten en logische modules zijn geïmplementeerd.

De softwarehiërarchie kan worden weergegeven in het volgende formulier:

· applicatiesoftware;

· middleware;

· basissoftware.

IN applicatiesoftware Applicatieobjecten worden geïmplementeerd. Er zijn twee soorten applicaties die de structuur van de softwareorganisatie beïnvloeden: lokaal beperkt En gedistribueerd toepassingen.

Lokaal beperkte applicatie wordt volledig binnen één eindsysteem geïnstalleerd, opgeroepen, beheerd en uitgevoerd en vereist geen tussenkomst van communicatiefuncties. Een voorbeeld is het bewerken van een document bij het voorbereiden van tekst op de computer van de gebruiker (gebruikersterminal).

Distributie applicatie bestaat uit meerdere componenten die in verschillende eindsystemen kunnen worden uitgevoerd en vereisen daarom de organisatie van de interactie tussen deze eindsystemen. Bijvoorbeeld het gezamenlijk redigeren van de tekst van een omvangrijke publicatie door gebruikers die zich op verschillende plaatsen bevinden.

Componenten gedistribueerde applicatie kan herhaaldelijk door andere toepassingen worden gebruikt. In dit geval worden het objecten middelware en ondersteunende diensten met betrekking tot netwerkintelligentie.

Middelware implementeert servicemanagementfuncties en -functies in het netwerk administratief beheer netwerk. Objecten van beide softwaregroepen, vergelijkbaar met componenten van distributieapplicaties, communiceren via de communicatiefuncties van het netwerk.

Basissoftware is bedoeld om toepassingssoftware en middleware-objecten de mogelijkheid te bieden andere objecten uit te voeren en ermee te communiceren, door een omgeving te bieden voor interactie met netwerkcommunicatiefuncties en logische gebruikersinterfaces. De organisatie van deze omgeving wordt uitgevoerd door uniforme softwaresystemen genaamd netwerk besturingssystemen . De efficiëntie van niet alleen applicatie- en middleware-objecten, maar ook van het netwerk als geheel hangt af van welke resource management-concepten de basis vormen van het netwerkbesturingssysteem. Tegenwoordig zijn UNIX-systemen en netwerkversies van Windows de de facto standaarden geworden voor netwerkbesturingssystemen. Logische componenten van communicatiefuncties geïmplementeerd in software die de communicatie tussen objecten op afstand garanderen, behoren ook tot de functies van de basissoftware.

Basissoftware omvat ook gegevensverwerking en daarin geïmplementeerde opslagobjecten softwaresystemen, zoals DBMS (databasebeheersystemen), basisserversoftware voor transactieverwerking, enz.

De aard van de interactie tussen objecten wordt bepaald door het type objectinterface, wat vergelijkbaar is protocol En functioneel referentiepunt.

Onderscheiden volgende typen objectinterfaces ( software-interfaces):

· toepassingsprotocol (Toepassingsprotocol, AP) – logische interface tussen applicatieobjecten;

· koppel applicatieprogramma's (Application Program Interface, API) – een logische interface tussen applicatieobjecten en middleware-objecten die applicatieobjecten ondersteunen;

· middleware-protocol(Managing Protocol, MP) – een logische interface tussen middleware-objecten;

· basisprogramma-interface(Base Program Interface, BPI) – een logische interface tussen middleware en basissoftwareobjecten die middleware-objecten ondersteunen;

· mens-computerinterface User-Computer Interface (UCI) is een logische interface tussen de gebruiker en voornamelijk hostsoftwareobjecten, maar kan ook logische interfaces omvatten met middleware-objecten en zelfs applicatieobjecten.

Netwerksoftware is een hulpbron die betrokken is bij de organisatie van serviceleveringsplatforms, en daarom zijn de compositieprincipes van het combineren van softwaremodules onderworpen aan dezelfde dynamiek als de principes van constructie functioneel model netwerken.