Objectgeoriënteerde databases: prestaties en uitdagingen. Object-relationeel datamodel

In de OOMD is het bij het presenteren van gegevens mogelijk om individuele databaserecords te identificeren. Er worden relaties gelegd tussen databaserecords en hun verwerkingsfuncties met behulp van mechanismen die vergelijkbaar zijn met de overeenkomstige tools in objectgeoriënteerde programmeertalen.

Het gestandaardiseerde objectgeoriënteerde model wordt beschreven in de aanbevelingen van de ODMG-93-standaard (Object Database Management Group). De ODMG-93-aanbevelingen zijn nog niet volledig geïmplementeerd. Overweeg een enigszins vereenvoudigd model van een objectgeoriënteerde database om de belangrijkste ideeën te illustreren.

De structuur van een objectgeoriënteerde database (OODB) wordt grafisch weergegeven in de vorm van een boom waarvan de knooppunten objecten zijn. De eigenschappen van objecten worden beschreven door een standaardtype (bijvoorbeeld een tekenreekstype) of een door de gebruiker geconstrueerd type (gedefinieerd als een klasse).

De waarde van een eigenschap van het type string is een tekenreeks. De waarde van een eigenschap van het type class is een object dat een instantie is van de corresponderende klasse. Elke instantie van een klasse wordt beschouwd als een afstammeling van het object waarin het als een eigenschap is gedefinieerd. Een instantieobject van een klasse behoort tot zijn klasse en heeft een enkele ouder. Generieke relaties in de database vormen een coherente hiërarchie van objecten.

Een voorbeeld van de logische structuur van een bibliothecaris OODB wordt getoond in Fig. 2.8.

Hier is een object van het type LIBRARY de bovenliggende objecten van bijvoorbeeld de klassen SUBSCRIBER, DIRECTORY en OUTPUT. Diverse objecten BOEKtypen kunnen dezelfde of verschillende ouders hebben. Objecten van het type BOOK met dezelfde ouder moeten minimaal het inventarisnummer verschillen (uniek voor elk exemplaar van het boek), maar hebben dezelfde waarden eigenschappen isbn, udk, naam en auteur.

Rijst. 2.8. De logische structuur van de bibliotheekdatabase

De logische structuur van de OODB is uiterlijk vergelijkbaar met de structuur van de OODB. Het belangrijkste verschil tussen hen ligt in de methoden van gegevensmanipulatie.

Om acties uit te voeren op gegevens in het beschouwde databasemodel, gebruik logische bewerkingen verbeterd door objectgeoriënteerde mechanismen van inkapseling, overerving en polymorfisme. Bewerkingen vergelijkbaar met SQL-commando's kunnen in beperkte mate worden gebruikt (bijvoorbeeld om een ​​database te maken).

Het aanmaken en wijzigen van de database gaat gepaard met het automatisch aanmaken en vervolgens aanpassen van indexen (indextabellen) met informatie voor Snelzoeken gegevens.

Laten we kort de concepten van inkapseling, overerving en polymorfisme beschouwen in relatie tot het objectgeoriënteerde databasemodel.

inkapseling beperkt het bereik van de eigenschapsnaam tot de limieten van het object waarin het is gedefinieerd. Dus als we een eigenschap toevoegen die het telefoonnummer van de auteur van het boek instelt en de naam phone heeft voor een object van het type DIRECTORY, dan krijgen we de eigenschappen met dezelfde naam voor de objecten SUBSCRIBER en DIRECTORY. De betekenis van zo'n eigenschap wordt bepaald door het object waarin het is ingekapseld.

Erfenis, integendeel, het breidt de reikwijdte van de eigenschap uit tot alle nakomelingen van het object. Dus alle objecten van het type BOOK die afstammen van een object van het type DIRECTORY kunnen de eigenschappen van het bovenliggende object krijgen: isbn, udk, naam en auteur. Als het nodig is om de werking van het overervingsmechanisme uit te breiden tot objecten die geen directe verwanten zijn (bijvoorbeeld tussen twee afstammelingen van dezelfde ouder), dan wordt een abstracte eigenschap van het type abs gedefinieerd in hun gemeenschappelijke voorouder. Dus de definitie van abstracte eigenschappen ticket en nummer in het LIBRARY-object leidt tot de overerving van deze eigenschappen door alle onderliggende objecten SUBSCRIBER, BOOK en REFERENCE. Het is geen toeval dat de waarden van het onroerend goed ticket van de SUBSCRIBER- en ISSUE-klassen die in de afbeelding worden getoond, zullen hetzelfde zijn - 00015.

Polymorfisme v objectgeoriënteerde programmeertalen betekent het vermogen van dezelfde programmacode om met verschillende soorten gegevens te werken. Met andere woorden, het betekent dat het mogelijk is om methoden (procedures of functies) met dezelfde naam te hebben in objecten van verschillende typen. Tijdens de uitvoering van een objectprogramma werken dezelfde methoden op verschillende objecten, afhankelijk van het type argument. Zoals toegepast op onze objectgeoriënteerde database, betekent polymorfisme dat objecten van de BOOK-klasse, die verschillende ouders hebben dan de DIRECTORY-klasse, een andere set eigenschappen kunnen hebben. Bijgevolg kunnen programma's voor het werken met objecten van de klasse BOOK polymorfe code bevatten.

Zoeken in OODB bestaat uit het vinden van de overeenkomst tussen het object, gespecificeerd door de gebruiker, en de objecten die zijn opgeslagen in de database. Een door de gebruiker gedefinieerd object dat een doelobject wordt genoemd (een objecteigenschap heeft een typedoel), v algemeen geval kan een subset vertegenwoordigen van de gehele hiërarchie van objecten die in de database zijn opgeslagen. Het doelobject, evenals het resultaat van de uitvoering van de query, kunnen in de database zelf worden opgeslagen. In Fig. 2.9.

Rijst. 2.9. Fragment van een database met een doelobject

de belangrijkste waardigheid OOMD in vergelijking met relationeel is het vermogen om informatie over complexe relaties van objecten weer te geven. Met OOMD kunt u een enkel databaserecord identificeren en de functies van hun verwerking definiëren.

de belangrijkste nadelen OOMD zijn hoge conceptuele complexiteit, ongemak van gegevensverwerking en lage snelheid uitvoering van verzoeken.

In de jaren 90 waren er experimentele prototypes van OODBMS. Momenteel zijn er meer dan 300 van dergelijke DBMS'en. Sommige systemen zijn relatief wijdverbreid, bijvoorbeeld de volgende DBMS: Cache (InterSystems), ROET (ROET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (ArdentSoftware), ODB-Jupiter (onderzoeks- en productiecentrum " Inteltek Plus"), evenals Iris, Orion en Postgres.

De voordelen van OODB op de lange termijn moeten leiden tot een zeer brede verspreiding. Om dit te doen, moet u eerst de problemen oplossen van het elimineren van de tekortkomingen die inherent zijn aan OODB: om de flexibiliteit van de databasestructuur te vergroten, een duidelijke programmeertaal te bouwen, de syntaxis uit te werken voor het parseren van query's, verschillende methoden voor toegang tot gegevens te definiëren, werk de problemen van gelijktijdige toegang oplossen, complexe gegevensinventarisatie definiëren, de bescherming en het herstel van gegevens uitwerken. De lijst met op te lossen taken kan worden vervolgd.

Maar zelfs nadat deze problemen zijn opgelost, zal de overgang naar OODB geleidelijk en niet erg snel gaan, aangezien het om objectieve en subjectieve redenen moeilijk zal zijn om los te komen van het enorme aantal operationele relationele DBMS. Om zo'n overgang minder pijnlijk te maken, kan niet alleen het object, maar ook de relationele component in de OODBMS worden opgenomen. Bovendien zou MMD in OODBMS moeten worden geïntroduceerd voor de vorming van HD OLAP-systemen, waar in de praktijk steeds meer vraag naar is.

Basisconcepten

Definitie 1

Objectgericht model presentatie van gegevens maakt het mogelijk om individuele records van de database te identificeren.

Databaserecords en hun verwerkingsfuncties zijn gekoppeld door mechanismen die vergelijkbaar zijn met de overeenkomstige tools die zijn geïmplementeerd in objectgeoriënteerde programmeertalen.

definitie 2

Grafische weergave een objectgeoriënteerde databasestructuur is een boom waarvan de knooppunten objecten vertegenwoordigen.

Standaardtype (bijvoorbeeld tekenreeks - snaar) of een door de gebruiker gemaakt type ( klas), beschrijft objecteigenschappen.

In Afbeelding 1 is het LIBRARY-object het bovenliggende object van de instantieobjecten DIRECT, SUBSCRIBER en REFERENCE. Verschillende objecten van het type BOEK kunnen één of verschillende ouders hebben. Objecten van het type BOEK die dezelfde ouder hebben, moeten een of meer hebben minstens verschillende inventarisnummers (uniek voor elk exemplaar van het boek), maar dezelfde eigendomswaarden auteur, titel, udk en isbn.

De logische structuren van een objectgeoriënteerde database en een hiërarchische database lijken oppervlakkig op elkaar. Ze verschillen voornamelijk in methoden voor gegevensmanipulatie.

Bij het uitvoeren van acties op gegevens in het objectgeoriënteerde model worden logische bewerkingen gebruikt, die worden versterkt door inkapseling, overerving en polymorfisme. Met enige beperking kunt u bewerkingen gebruiken die vergelijkbaar zijn met SQL-opdrachten (bijvoorbeeld bij het maken van een database).

Bij het maken en wijzigen van de database worden automatisch indexen (indextabellen) aangemaakt en vervolgens aangepast, die informatie bevatten voor het snel ophalen van gegevens.

Definitie 3

Doel inkapseling- de reikwijdte van de eigenschapsnaam beperken tot de grenzen van het object waarin deze is gedefinieerd.

Als er bijvoorbeeld een eigenschap wordt toegevoegd aan het DIRECTORY-object dat het telefoonnummer van de auteur instelt en de naam telefoon, worden de eigenschappen met dezelfde naam verkregen voor de objecten DIRECTORY en SUBSCRIBER. De betekenis van een eigenschap wordt bepaald door het object waarin het is ingekapseld.

Definitie 4

Erfenis, omgekeerd inkapselen, is verantwoordelijk voor het verspreiden van de reikwijdte van de eigenschap ten opzichte van alle nakomelingen van het object.

Alle BOOK-objecten die afstammen van het DIRECTORY-object kunnen bijvoorbeeld de eigenschappen van het bovenliggende object krijgen: auteur, titel, udk en isbn.

Als het nodig is om de werking van het overervingsmechanisme uit te breiden tot objecten die geen directe verwanten zijn (bijvoorbeeld twee afstammelingen van dezelfde ouder), wordt een eigenschap van het abstracte type gedefinieerd in hun gemeenschappelijke voorouder buikspieren.

Dus de eigenschappen Kamer en ticket in het LIBRARY-object worden overgenomen door alle onderliggende objecten REFERENCE, BOOK en SUBSCRIBER. Dat is de reden waarom de waarden van deze eigenschap van de SUBSCRIBER- en OUTPUT-klassen hetzelfde zijn - 00015 (Figuur 1).

Definitie 5

Polymorfisme staat dezelfde programmacode toe om met verschillende soorten gegevens te werken.

Met andere woorden, het staat in objecten toe verschillende soorten hebben methoden (functies of procedures) met dezelfde namen.

Zoekopdracht in een objectgeoriënteerde database is het om de overeenkomst te bepalen tussen het object dat de gebruiker opgeeft en de objecten die in de database zijn opgeslagen.

Voor- en nadelen van het objectgeoriënteerde model

de belangrijkste voordeel objectgeoriënteerd datamodel, in tegenstelling tot het relationele model, bestaat uit het vermogen om informatie over complexe relaties van objecten weer te geven. Het overwogen datamodel maakt het mogelijk om te bepalen: aparte invoer DB en functies van de verwerking ervan.

NAAR nadelen Het objectgeoriënteerde model wordt gekenmerkt door een hoge conceptuele complexiteit, onhandige gegevensverwerking en een lage uitvoeringssnelheid van query's.

Tegenwoordig zijn dergelijke systemen vrij wijdverbreid. Deze omvatten DBMS:

• Postgres,
• Orion,
• Iris,
• ODBJupiter,
• Versant,
• Objectiviteit / DB,
• ObjectStore,
• statistiek,
• Edelsteen
• G-basis.

Objectgeoriënteerd gegevensmodel

Object- relationeel model gegevens

Andere datamodellen

De toenemende complexiteit van databasetoepassingen en de beperkingen van het relationele model leidden tot de ontwikkeling van het Codd-model, ĸᴏᴛᴏᴩᴏᴇ eerst genoemd uitgebreid relationeel model, en kreeg later zijn ontwikkeling in het object-relationele datamodel. Databases die op deze modellen zijn gebaseerd, worden meestal generatie III genoemd.

Het Object Relational Data Model (ORMD) wordt geïmplementeerd met behulp van relationele tabellen, maar bevat objecten die lijken op het concept van een object in objectgeoriënteerd programmeren. ORMD maakt gebruik van objectgeoriënteerde componenten zoals door de gebruiker gedefinieerde gegevenstypen, inkapseling, polymorfisme, overerving, overschrijven van methoden, enzovoort.

Helaas zijn de ontwikkelaars tot nu toe niet tot een consensus gekomen over wat de ORMD zou moeten bieden. In 1999 . de SQL-99-standaard werd aangenomen, en in 2003 werd ᴦ. de tweede release van deze standaard werd uitgebracht, genaamd SQL-3, die de belangrijkste kenmerken van de ORMD definieert. Maar tot nu toe zijn de object-relationele modellen ondersteund door verschillende fabrikanten DBMS verschillen aanzienlijk van elkaar. De vooruitzichten van deze richting worden bewezen door het feit dat toonaangevende DBMS-fabrikanten, waaronder Oracle, Informix, INGRES en anderen, de mogelijkheden van hun producten hebben uitgebreid tot een object-relationeel DBMS (ORDBMS).

In de meeste implementaties van ORMD worden objecten herkend als een aggregaat en een tabel (relatie), die onderdeel kan zijn van een andere tabel. Gegevensverwerkingsmethoden worden weergegeven als opgeslagen procedures en triggers, die procedurele database-objecten zijn en zijn gekoppeld aan tabellen. Op conceptueel niveau worden alle gegevens in een object-relationele database weergegeven als een relatie en ondersteunt het ORDBMS de SQL-taal.

Een andere benadering voor het bouwen van een database is het gebruik van een objectgeoriënteerd datamodel (OOMD). Gegevensmodellering in OOMD is gebaseerd op het concept van een object. OOMD wordt meestal gebruikt in complexe vakgebieden die de functionaliteit van het relationele model voor modellering missen (bijvoorbeeld voor ontwerpautomatiseringssystemen (CAD), publicatiesystemen, enz.).

Bij het maken van objectgeoriënteerde DBMS (OODBMS) worden gebruikt verschillende methoden, namelijk:

• inbedding in de objectgeoriënteerde taal van middelen die bedoeld zijn om met een database te werken;
• verlenging bestaande taal werken met databases met objectgeoriënteerde functies;
• creatie van objectgeoriënteerde bibliotheken met functies voor het werken met een database;
• creatie van een nieuwe taal en een nieuw objectgeoriënteerd datamodel

De voordelen van OOMD omvatten: volop kansen modellering gebied, een expressieve zoektaal en hoge productiviteit... Elk object in de OOMD heeft unieke identificatie(OID - object-ID). Het ophalen van OID is aanzienlijk sneller dan het opzoeken van relationele tabellen.

Een van de nadelen van OOMD is het ontbreken van: conventioneel model, gebrek aan ervaring met de oprichting en werking van OODB, de complexiteit van het gebruik en het ontbreken van instrumenten voor gegevensbescherming.

In 2000 . werkgroep ODMG (Object) Database management Group), gevormd door fabrikanten van OODBMS'en, heeft een andere standaard (ODMG 3.0) voor OODBMS'en uitgebracht, die het objectmodel, de querydefinitietaal, de objectquerytaal en de verbindingstalen C++, Smalltalk en Java beschrijft. ODMG-normen zijn niet officieel. De ODMG-benadering van standaardisatie is in wezen dat na de goedkeuring van de volgende versie van de standaard door de ODMG-lidorganisaties, een boek wordt gepubliceerd dat de tekst van de standaard bevat.

Laten we nu eens kijken hoe de ondersteuning van gegevensmodellen wordt geïmplementeerd in: echte systemen database management.

Objectgeoriënteerd datamodel - concept en typen. Classificatie en kenmerken van de categorie "Objectgeoriënteerd datamodel" 2017, 2018.

In het objectgeoriënteerde model is het bij het presenteren van gegevens mogelijk om individuele databaserecords te identificeren. Er worden relaties gelegd tussen records en hun verwerkingsfuncties met behulp van mechanismen die vergelijkbaar zijn met die in objectgeoriënteerde programmeertalen.

Laten we een vereenvoudigd model van een objectgeoriënteerde database bekijken. De structuur van een objectgeoriënteerde database wordt grafisch weergegeven in de vorm van een boom waarvan de knooppunten objecten zijn. De eigenschappen van objecten worden beschreven door een standaard of door de gebruiker geconstrueerd type (gedefinieerd als een klasse). De waarde van een eigenschap van het type class is een object dat een instantie is van de corresponderende klasse. Elke instantie van een klasse wordt beschouwd als een afstammeling van het object waarin het als een eigenschap is gedefinieerd. Een instantieobject van een klasse behoort tot zijn klasse en heeft een enkele ouder. Generieke relaties in de database vormen een coherente hiërarchie van objecten. Voorbeeld logische structuur De objectgeoriënteerde database van bibliotheken wordt getoond in Fig. 2.9. Hier is een object van het type Bibliotheek de bovenliggende objecten van bijvoorbeeld de klassen Subscriber, Directory en Issuance. Verschillende objecten van het type Boek kunnen dezelfde of verschillende ouders hebben. Objecten van het type Boek met dezelfde ouder moeten verschillen, in ieder geval in het inventarisnummer (uniek voor elk exemplaar van het boek), maar hebben dezelfde eigenschapswaarden isb n, udc, titel en auteur.

De logische structuur van een objectgeoriënteerde database is uiterlijk vergelijkbaar met de structuur van een hiërarchische database. Het belangrijkste verschil tussen de twee is de methoden voor gegevensmanipulatie.

Om acties uit te voeren op gegevens in het beschouwde databasemodel, worden logische bewerkingen gebruikt, versterkt door objectgeoriënteerde mechanismen van inkapseling, overerving en polymorfisme.

inkapseling beperkt het bereik van de eigenschapsnaam tot de limieten van het object waarin het is gedefinieerd. Erfenis omgekeerd, breidt de reikwijdte van de eigenschap uit naar alle nakomelingen van het object.

Polymorfisme in objectgeoriënteerde programmeertalen betekent het vermogen van hetzelfde programmacode: werken met verschillende soorten gegevens. Met andere woorden, het betekent dat het mogelijk is om methoden (procedures of functies) met dezelfde naam te hebben in objecten van verschillende typen. Zoeken in een objectgeoriënteerde database bestaat uit het vinden van de overeenkomst tussen het object, gespecificeerd door de gebruiker, en de objecten die in de database zijn opgeslagen.

Het belangrijkste voordeel van het objectgeoriënteerde datamodel in vergelijking met het relationele model is de mogelijkheid om informatie weer te geven over complexe relaties tussen objecten. Met het objectgeoriënteerde gegevensmodel kunt u een enkel databaserecord identificeren en de functies van hun verwerking definiëren.

De nadelen van het objectgeoriënteerde model zijn een hoge conceptuele complexiteit, ongemak bij de gegevensverwerking en een lage querysnelheid.

Objectgeoriënteerde DBMS'en omvatten POET, Jasmine, Versant, O 2, ODB - Jupiter, Iris, Orion, Postgres.

Databasetechnologieën op basis van de bovenstaande MD's zijn gebaseerd op een statisch concept van informatieopslag, gericht op gegevensmodellering. Nieuwe technologische toepassingen met complexe, onderling verbonden database-objecten, zoals:

Computerondersteund ontwerp;

Geautomatiseerde productie;

Geautomatiseerde ontwikkeling software;

Kantoor informatiesystemen;

Multimediasystemen;

Geografische Informatie Systemen;

Publicatiesystemen en anderen - demonstreerden de beperkte mogelijkheden van het statische concept in termen van objectmodellering de echte wereld.

Voor nieuwe typen complexe gespecialiseerde databasetoepassingen is een dynamisch concept van informatieopslag effectief, waardoor het mogelijk is om gegevens en processen die op deze gegevens inwerken parallel te simuleren. Hierdoor kunt u rekening houden met de semantiek van het domein en deze toepassingen dus het meest adequaat beschrijven. Dit concept is gebaseerd op de objectgeoriënteerde benadering die veel wordt gebruikt in softwareontwikkeling. MD implementeren dit concept en gebaseerd op het objectgeoriënteerde paradigma (OOP), wordt het objectgeoriënteerde datamodel (OOMD) genoemd.

De constructie van OOMD gaat uit van de veronderstelling dat het onderwerpgebied kan worden beschreven door een reeks objecten. Elk object is een uniek identificeerbare entiteit die attributen bevat die de toestand van "echte" objecten en hun bijbehorende acties beschrijven. De huidige staat van een object wordt beschreven door een of meer attributen, die eenvoudig of complex kunnen zijn. Een eenvoudig attribuut kan hebben: primitief type(zoals een geheel getal, string, enz.) en accepteer een letterlijke waarde. Een samengesteld attribuut kan collecties en/of links bevatten. Een referentieattribuut vertegenwoordigt een relatie tussen objecten.

De belangrijkste eigenschap van een object is de uniciteit van zijn identificatie. Daarom moet elk object in een objectgeoriënteerd systeem zijn eigen identifier hebben.

Een Object Identifier (OID) is een database-interne manier om individuele objecten te taggen. Gebruikers die met het dialoogprogramma werken voor het instellen van query's of het bekijken van informatie, zien deze identifiers in de regel niet. Ze worden toegewezen en gebruikt door het DBMS zelf. De semantiek van de identifier in elk DBMS is anders. Het kan een willekeurige waarde zijn of informatie bevatten die nodig is om een ​​object in het databasebestand te vinden, bijvoorbeeld het paginanummer in het bestand en de verschuiving van het object vanaf het begin. Het is de identifier die moet worden gebruikt om verwijzingen naar het object te organiseren.

Alle objecten zijn ingekapseld, dat wil zeggen dat de representatie of interne structuur van het object voor de gebruiker verborgen blijft. In plaats daarvan weet de gebruiker alleen dat: dit object sommige functies kan uitvoeren. Voor het WAREHOUSE-object kunnen bijvoorbeeld methoden worden gebruikt zoals ACCEPT_PRODUCT, EXIT_TOBAP, enz. Het voordeel van inkapseling is dat u de interne representatie van objecten kunt wijzigen zonder toepassingen die deze objecten gebruiken opnieuw te bewerken. Met andere woorden, inkapseling impliceert gegevensonafhankelijkheid.

Een object kapselt gegevens en functies in (methoden, volgens OOP). Methoden definiëren het gedrag van een object. Ze kunnen worden gebruikt om de status van een object te wijzigen door de waarden van zijn attributen te wijzigen, of om de waarden van geselecteerde attributen op te vragen. Er kunnen bijvoorbeeld methoden zijn om informatie over een nieuwe huurwoning toe te voegen, de salarisgegevens van een werknemer bij te werken of informatie over een specifiek item af te drukken.

Objecten die dezelfde set attributen hebben en op dezelfde berichten reageren, kunnen worden gegroepeerd in: Klas(in de literatuur worden de termen "klasse" en "type" vaak door elkaar gebruikt). Elke dergelijke klasse heeft zijn eigen vertegenwoordiger - een object, dat een gegevenselement is. Objecten van een bepaalde klasse worden het genoemd kopieën.

In sommige objectgeoriënteerde systemen is een klasse ook een object en heeft deze zijn eigen attributen en methoden genaamd klasseattributen en klassemethoden.

Belangrijke OOP-concepten zijn: klassenhiërarchie en containerhiërarchie.

Klassenhiërarchie impliceert de mogelijkheid dat elke klasse, in dit geval een superklasse genoemd, zijn eigen subklasse heeft. Als voorbeeld kunnen we de volgende keten geven: alle programmeurs van een onderneming zijn haar werknemers, daarom is elke programmeur die een object is van de klasse PROGRAMMERS binnen de OOMD ook een werknemer die op zijn beurt een object is van de WERKNEMERS klas. PROGRAMMEURS zullen dus een subklasse zijn, WERKNEMERS een superklasse. Maar programmeurs kunnen ook worden onderverdeeld in systeem en applicatie. Daarom zal PROGRAMMERS de superklasse zijn van de subklassen SIS_PROGRAMMERS en APPLICATION_PROGRAMMERS. Als we deze keten verder voortzetten, krijgen we een klassenhiërarchie waarin elk object van de subklasse de instanties van variabelen en methoden van de overeenkomstige superklasse erft.

Er zijn verschillende soorten overerving - enkelvoudig, meervoudig en selectief. Enkele overerving is een geval waarin subklassen van maximaal één superklasse erven. meervoudige overerving- overerving van meer dan één superklasse. Met selectieve overerving kan een subklasse een beperkt aantal eigenschappen van zijn superklasse erven.

Overerving van variabele instanties heet structurele overerving, methode overerving - gedragsovererving, en de mogelijkheid om dezelfde methode te gebruiken voor verschillende klassen of liever, het toepassen van verschillende methoden met dezelfde naam voor verschillende klassen wordt genoemd polymorfisme.

Objectgeoriënteerde architectuur heeft ook een ander type hiërarchie: containerhiërarchie... Het bestaat uit het feit dat sommige objecten conceptueel in andere kunnen worden opgenomen. Een object van de klasse DEPARTMENT moet dus de openbare variabele HEAD bevatten, die een link is naar het object van de klasse EMPLOYEES die overeenkomt met het hoofd van de afdeling, en moet ook een link bevatten naar een reeks verwijzingen naar objecten die overeenkomen met de medewerkers die op deze afdeling werken.

In sommige objectgeoriënteerde systemen is een klasse ook een object en heeft deze zijn eigen attributen en methoden. Algemene karakteristieken klasse worden beschreven door zijn attributen. Objectklasse-methoden zijn een beetje analoog aan eigenschappen van objecten in de echte wereld. Elk object dat tot een bepaalde klasse behoort, heeft deze eigenschappen. Daarom moet u bij het maken van een object de klasse aangeven waartoe het behoort om de inherente eigenschappen op deze manier te definiëren.

De gebruiker en het object communiceren via berichten. Als reactie op elk bericht voert het systeem de juiste methode uit.

Alle koppelingen in het objectmodel worden gemaakt met behulp van referentieattributen, die meestal worden geïmplementeerd als OID's.

Relaties in een relationele database worden weergegeven door een toewijzing van primaire en externe sleutels. In de basis zelf zijn er geen structuren voor het vormen van associaties tussen tabellen, koppelingen worden indien nodig gebruikt bij het samenvoegen van tabellen. Relaties vormen daarentegen de ruggengraat van een objectgeoriënteerde database, aangezien elk object de identifiers bevat van de objecten waarmee het is geassocieerd.

In OOMD kunnen niet alleen traditionele koppelingen worden geïmplementeerd, maar ook koppelingen die zijn geconditioneerd door overerving.

Eén-op-één communicatie (1: 1) tussen objecten A en B wordt geïmplementeerd door een referentie-attribuut toe te voegen aan object B aan object A en (om de referentiële integriteit te behouden) een referentie-attribuut aan object A aan object B.

Een-op-veel-relatie (1: M) tussen objecten A en B wordt geïmplementeerd door aan object A een referentie-attribuut toe te voegen aan object B en een attribuut dat een set verwijzingen naar object A naar object B bevat (bijvoorbeeld een referentie-attribuut B (OID2, OID3 ...) wordt toegevoegd aan object A, en aan object instanties B met OID2, OID3, ... wordt een referentiekenmerk A: OID1 toegevoegd.

Veel-op-veel-relatie (M: N) tussen objecten A en B wordt geïmplementeerd door aan elk object een attribuut toe te voegen dat een set koppelingen bevat.

In OOMD kunt u een geheel-naar-deel-relatie gebruiken, die beschrijft dat een object van een klasse objecten van andere klassen als onderdelen bevat. In het geval van een productiedatabase zou er een geheel-naar-deel relatie zijn tussen de klasse PRODUCT en de klassen PART en ASSEMBLY. deze verbinding is een variant van een veel-op-veel-relatie met speciale semantiek. Een geheel-naar-deel-relatie wordt geïmplementeerd zoals elke andere veel-op-veel-relatie, met behulp van een set gerelateerde object-ID's. Het heeft echter, in tegenstelling tot de gebruikelijke veel-op-veel-relatie, een andere semantische betekenis.

Aangezien het objectgeoriënteerde paradigma overerving ondersteunt, is het in OOMD mogelijk om de relatie van het type "is" en de relatie van het type "extends" te gebruiken. De is-relatie, ook wel de generalisatie-specialisatierelatie genoemd, genereert een overervingshiërarchie waarin subklassen speciale gevallen van superklassen zijn. Dit vermijdt het beschrijven van opnieuw overgeërfde kenmerken. Bij gebruik van de "extends"-relatie ontwikkelt de subklasse de functionaliteit van de superklasse in plaats van beperkt te zijn tot het specifieke geval.

Overweeg hoe componenten zoals integriteitsbeperkingen en bewerkingen op gegevens worden geïmplementeerd in OOMD.

De kenmerken van deze componenten worden bepaald door de specifieke kenmerken van het model. Deze specificiteit in OOMD wordt voornamelijk bepaald door interne concepten als de inkapseling van objecten, dat wil zeggen het geheim van de interne structuur, alleen toegang tot gegevens via vooraf gedefinieerde methoden, de klassenhiërarchie en de hiërarchie van containers.

De specificiteit van de OOMD wordt ook bepaald door de specificiteit van het object. Het manifesteert zich in de behoefte om objecten in klassen te groeperen. Elk object is opgenomen in een of andere klasse, afhankelijk van de taak, en een object kan tot meerdere klassen tegelijk behoren (bijvoorbeeld de families PROGRAMMERS en HIGHLY BETAALD). Een andere specificiteit van een object is dat het van de ene klasse (subklasse) naar de andere kan "overlopen". Dus een SYSTEEMPROGRAMMEUR kan in de loop van de tijd TOEGEPAST worden. De klassenhiërarchie is dus niet analoog aan het hiërarchische model, zoals het eerder lijkt, maar vereist dat het systeem de locatie van elk object binnen de klassenhiërarchie kan wijzigen, bijvoorbeeld "omhoog" of "omlaag" verplaatsen binnen deze hiërarchie. Maar een complexer proces is ook mogelijk: het systeem moet ervoor zorgen dat een object op elk moment aan een willekeurige top van de hiërarchie kan worden bevestigd (losgemaakt).

Belangrijke rol beperkingen op de integriteit van links spelen in OOMD. Om koppelingen in een objectgeoriënteerde MD te laten werken, moeten de object-ID's aan beide zijden van de koppeling overeenkomen. Als er bijvoorbeeld een relatie is tussen WERKNEMERS en hun KINDEREN, dan moet er enige zekerheid zijn dat wanneer een object dat een kind beschrijft, wordt ingevoegd in een object dat een werknemer vertegenwoordigt, de identificator van deze laatste wordt toegevoegd aan het overeenkomstige object. Dit soort linkintegriteit, enigszins analoog aan referentiële integriteit in een relationeel datamodel, wordt vastgesteld met behulp van feedback... Om de integriteit van de links te waarborgen, is de ontwerper voorzien van een speciale syntaxis die nodig is om de locatie van de inverse object-ID te specificeren. De verantwoordelijkheid om beperkingen te stellen aan de integriteit van links (evenals de referentiële integriteit in een relationele database) ligt bij de ontwerper.

In OOMD vinden zowel de beschrijving van gegevens als de manipulatie ervan plaats met behulp van dezelfde objectgeoriënteerde procedurele taal.

De ODMG-groep (Object Database Management Groop) houdt zich bezig met de problemen van standaardisatie van objectdatabasetechnologie. Ze ontwikkelde een objectmodel (ODMG versie 2.0 werd in september 1997 aangenomen) dat een standaardmodel definieert voor de semantiek van databaseobjecten. Dit model is belangrijk omdat het ingebouwde semantiek definieert die een objectgeoriënteerd DBMS (OODBMS) begrijpt en kan implementeren. De structuur van bibliotheken en toepassingen die deze semantiek gebruiken, moet overdraagbaar zijn tussen de verschillende OODBMS'en die een bepaald object-MD ondersteunen. De belangrijkste componenten van de ODMG-architectuur zijn het Object Model (OM), Object Definition Language (ODL), Object Query Language (OQL) en de mogelijkheid om te linken naar C++, Java en Smalltalk.

Objectmodel gegevens volgens de ODMG 2.0-standaard worden gekenmerkt door de volgende eigenschappen:

De basisbouwstenen zijn objecten en letterlijken. Elk object heeft een unieke identificatie. Een letterlijke heeft geen eigen identifier en kan niet afzonderlijk als object bestaan. Letterlijke termen zijn altijd ingebed in objecten en kunnen niet afzonderlijk worden verwezen;

Objecten en letterlijke verschillen in type. Elk type heeft: eigen domein gedeeld door alle objecten en letterlijke termen van dit type... Typen kunnen ook gedrag vertonen. Als een type enig gedrag vertoont, dan hebben alle objecten van dat type hetzelfde gedrag. In de praktijk kan een type de klasse zijn waaruit het object is gemaakt, een interface of een eenvoudig gegevenstype (zoals een geheel getal). Een object kan worden gezien als een instantie van een type;

De toestand van een object wordt bepaald door een set huidige waarden geïmplementeerd door een set eigenschappen. Deze eigenschappen kunnen attributen zijn van een object of een relatie tussen een object en een of meer andere objecten;

Het gedrag van een object wordt bepaald door een reeks bewerkingen die op een object of op het object zelf kunnen worden uitgevoerd. Bewerkingen kunnen een lijst met invoer- en uitvoerparameters hebben, die elk strikt zijn van een bepaald type... Elke bewerking kan ook een getypt resultaat retourneren;

De databasedefinitie wordt opgeslagen in een schema dat is geschreven in de definitietaal Objectobjecten Definitietaal (ODL). De database slaat objecten op zodat ze door verschillende gebruikers en applicaties kunnen worden gedeeld.

DBMS op basis van OOMD worden objectgeoriënteerde DBMS (OODBMS) genoemd. Deze DBMS'en worden derde generatie DBMS'en genoemd * (* De geschiedenis van de ontwikkeling van dataopslagmodellen is vaak onderverdeeld in drie fasen (generaties): de eerste generatie (eind jaren 60 - begin jaren 70) - hiërarchisch en netwerkmodellen; tweede generatie (ca. 1970s-1980s) - relationeel model; derde generatie (jaren '80 - begin jaren 2000) - objectgeoriënteerde modellen.).

Tegenwoordig worden objectgeoriënteerde databases in verschillende organisaties gebruikt om een ​​breed scala aan taken op te lossen. Analyse en veralgemening van de opgebouwde ervaring op het gebied van informatietechnologiegegevens maakte het mogelijk om toepassingen te identificeren waarin het gebruik van objectgeoriënteerde databases gerechtvaardigd is:

De applicatie bestaat uit: een groot aantal samenwerkende delen. Elk van hen heeft zijn eigen gedrag, dat afhankelijk is van het gedrag van anderen;

Het systeem moet grote hoeveelheden ongestructureerde of complexe structuur gegevens;

De applicatie biedt voorspelbare gegevenstoegang, dus het navigatiekarakter van objectgeoriënteerde databases zal dat niet zijn aanzienlijk nadeel;

De behoefte aan ad-hocverzoeken is beperkt;

De structuur van de opgeslagen gegevens is hiërarchisch of vergelijkbaar van aard.

V momenteel er zijn veel objectgeoriënteerde DBMS'en op de softwaremarkt. Tafel 10.6 presenteert enkele van commerciële systemen van deze klasse.

Tabel 10.6

Moderne commerciële OODBMS,

hun productiebedrijven en toepassingsgebieden

Een van de fundamentele verschillen objectdatabases van relationeel is de mogelijkheid om nieuwe gegevenstypen te maken en te gebruiken. Belangrijke functie OODBMS is dat het creëren van een nieuw type geen wijziging van de basiskern vereist en is gebaseerd op de principes van objectgeoriënteerd programmeren.

De kern van de OODBMS is geoptimaliseerd voor objectmanipulatie. Natuurlijke bewerkingen ervoor zijn objectcaching, objectversiebeheer, scheiding van toegangsrechten tot specifieke objecten. OODBMS'en worden gekenmerkt door hogere prestaties bij bewerkingen waarvoor toegang tot en ophalen van in objecten verpakte gegevens vereist zijn, vergeleken met relationele DBMS, waarvoor de noodzaak om verbonden gegevens op te halen leidt tot de uitvoering van aanvullende interne bewerkingen.

Van groot belang voor OODBMS is de mogelijkheid om objecten van de ene database naar de andere te verplaatsen.

Bij het maken van verschillende applicaties op basis van OODBMS is de ingebouwde klassenstructuur van een bepaald DBMS belangrijk. De klassenbibliotheek ondersteunt meestal niet alleen alles standaard typen data, maar ook een uitgebreide set multimedia en andere complexe datatypes, zoals video, geluid, opeenvolging van animatieframes. In sommige OODBMS-klassen zijn bibliotheken gecreëerd die het mogelijk maken om documentaire informatie op te slaan en full-text te doorzoeken (bijvoorbeeld Jasmine, ODB-Jupiter). Voorbeeld basis structuur klassen wordt getoond in Fig. 10.17.

De belangrijkste positie daarin wordt ingenomen door de klasse TOdbObject, die alle benodigde eigenschappen en methoden bevat om de toegang tot de database te regelen en indexering uit te voeren. Alle andere klassen overschrijven de methoden door een validatiecontrole toe te voegen voor het type dat ze implementeren en een specifieke indexeerder.

Zoals blijkt uit afb. 10.17 zijn er verschillende klassen in de structuur die gericht zijn op het verwerken van documentaire informatie - TOdbText, TOdbDocument, TODBTextDocument, enz. Elk document wordt vertegenwoordigd door een afzonderlijk object. Zo is de natuurlijke opslag van documenten verzekerd. Een van de belangrijkste handelingen is het op verzoek zoeken naar documenten. Voor de meeste klassen is de mogelijkheid geïmplementeerd om naar objecten te zoeken op de waarde van een specifieke sleutel. Voor de klasse TOdbText, de mogelijkheid om te vormen geïmplementeerd zoekopdracht door een zin geschreven in natuurlijke taal.

De klasse TOdbDocument is speciaal en kan objecten van verschillende typen bevatten. Het bestaat uit velden, die elk een naam hebben en zijn gekoppeld aan een object van een bepaald type. Door de aanwezigheid van deze klasse kan de gebruiker de reeks typen uitbreiden. Door het containerobject (document) te wijzigen, kunt u een bepaalde set velden instellen en tegelijkertijd ophalen nieuw type Document.

Op basis van ODB-Jupiter hebben OODBMS-ontwikkelaars een volledig uitgerust informatie-ophaalsysteem ODB-Text gecreëerd, dat een universele structuur van opgeslagen gegevens en een krachtige zoekmachine heeft. ODB-Text systeem is een tool voor het collectief verwerken van documenten en het bijhouden van een bedrijfsarchief. Tussen mogelijke toepassingen laten we het automatiseren van documentbeheer in een modern kantoor noemen, het bouwen van referentie- en informatiesystemen (vergelijkbaar met de bekende juridische databases), onderhoud van netwerkdatabases, personeelsdossiers, bibliografie, etc.

41. Kenmerken van het ontwerp van toegepaste IS. Fasen van IP-ontwikkeling. (Onderwerp 11, blz. 100-103).

11.1.3. Kenmerken van toegepast ontwerp van IC-systemen

Bij het bouwen (kiezen, aanpassen) informatie Systeem twee hoofdconcepten kunnen worden gebruikt, twee hoofdbenaderingen (het derde concept is een combinatie van beide):

1. oriëntatie op de problemen die met behulp van dit informatiesysteem moeten worden opgelost, d.w.z. probleemgerichte benadering (of inductieve benadering);

2. oriëntatie op technologie die beschikbaar is (geüpdatet) in een bepaald systeem, omgeving, d.w.z. technologiegerichte benadering (of deductieve benadering).

De keuze van het concept hangt af van strategische (tactische) en (of) lange termijn (korte termijn) criteria, problemen, middelen.

Als eerst de mogelijkheden van de beschikbare technologie worden onderzocht en vervolgens worden vastgesteld welke problemen met hun hulp kunnen worden opgelost, dan is het noodzakelijk om te vertrouwen op een technologiegerichte benadering.

Als eerst concrete problemen worden geïdentificeerd en vervolgens een technologie wordt geïntroduceerd die voldoende is om deze problemen op te lossen, dan is het noodzakelijk om te vertrouwen op een probleemgerichte aanpak.

Tegelijkertijd zijn beide concepten van het bouwen van een informatiesysteem van elkaar afhankelijk: de introductie van nieuwe technologieën verandert de problemen die worden opgelost, en de verandering in de problemen die worden opgelost leidt tot de noodzaak om nieuwe technologieën te introduceren; beide hebben invloed op de genomen beslissingen.

Systeemontwerp (ontwikkeling) en gebruik van een eventueel toegepast (bedrijfs)informatiesysteem moeten de volgende levenscyclus van het informatiesysteem doorlopen:

- analyse voorafgaand aan het ontwerp (ervaring met het creëren van andere soortgelijke systemen, prototypes, verschillen en kenmerken van het systeem dat wordt ontwikkeld, enz.), analyse van de externe manifestaties van het systeem;

- intrasysteemanalyse, interne analyse(analyse van systeemsubsystemen);

- systemische (morfologische) beschrijving (representatie) van het systeem (beschrijving van het systemische doel, systemische relaties en verbanden met omgeving, andere systemen en systeembronnen- materieel, energie, informatief, organisatorisch, menselijk, ruimtelijk en tijdelijk);

- bepaling van criteria voor toereikendheid, efficiëntie en stabiliteit (betrouwbaarheid);

- functionele beschrijving van de subsystemen van het systeem (beschrijving van modellen, algoritmen voor het functioneren van subsystemen);

- prototyping (lay-outbeschrijving) van het systeem, beoordeling van de interactie van subsystemen van het systeem (ontwikkeling van een lay-out - implementatie van subsystemen met vereenvoudigde functionele beschrijvingen, procedures en goedkeuring van de interactie van deze lay-outs om aan het systeemdoel te voldoen), terwijl het mogelijk is om "lay-outs" van criteria voor adequaatheid, duurzaamheid, efficiëntie te gebruiken;

- "montage" en testen van het systeem - implementatie van volwaardige functionele subsystemen en criteria, evaluatie van het model volgens de geformuleerde criteria;

- de werking van het systeem;

- definitie van doelen verdere ontwikkeling systeem en zijn toepassingen;

- systeemonderhoud - verduidelijking, wijziging, uitbreiding van de mogelijkheden van het systeem in de modus van zijn werking (met het doel van zijn evolutie).

Deze fasen zijn van fundamenteel belang voor de re-engineering van informatiesystemen.

De ontwikkeling van een bedrijfsinformatiesysteem wordt in de regel uitgevoerd voor een zeer specifieke onderneming. De bijzonderheden van de onderwerpactiviteit van de onderneming zullen ongetwijfeld de structuur van het informatiesysteem beïnvloeden. Maar tegelijkertijd zijn de structuren van verschillende ondernemingen over het algemeen vergelijkbaar. Elke organisatie, ongeacht het type activiteit, bestaat uit een aantal divisies die rechtstreeks een of ander type bedrijfsactiviteit uitvoeren. En deze situatie geldt voor bijna alle organisaties, ongeacht het soort activiteit dat ze uitoefenen.

Elke organisatie kan dus worden beschouwd als een reeks op elkaar inwerkende elementen (divisies), die elk hun eigen nogal complexe structuur kunnen hebben. Ook de relaties tussen afdelingen zijn vrij complex. Over het algemeen zijn er drie soorten banden tussen de divisies van de onderneming:

Functionele verbindingen - elke afdeling voert bepaalde soorten werk uit binnen één bedrijfsproces;

Informatieve verbindingen- onderafdelingen wisselen informatie uit (documenten, faxen, schriftelijke en mondelinge opdrachten, enz.);

Externe betrekkingen - sommige eenheden werken samen met externe systemen en hun interactie kan ook zowel informatief als functioneel zijn.

De algemeenheid van de structuur van verschillende ondernemingen stelt ons in staat enkele gemeenschappelijke principes te formuleren voor het bouwen van bedrijfsinformatiesystemen.

In het algemeen kan het proces van het ontwikkelen van een informatiesysteem vanuit twee gezichtspunten worden bekeken:

Op tijd of in fasen levenscyclus het systeem dat wordt ontwikkeld. V in dit geval de dynamische organisatie van het ontwikkelproces wordt beschouwd, beschreven in termen van cycli, stadia, iteraties en stadia.

Als een soort project wordt een bedrijfsinformatiesysteem ontwikkeld. Veel kenmerken van projectmanagement- en projectontwikkelingsfasen (levenscyclusfasen) zijn algemeen, niet alleen afhankelijk van het onderwerp, maar ook van de aard van het project (het maakt niet uit of het een technisch of economisch project is) . Daarom is het logisch om eerst naar de reeks te kijken algemene problemen project management.

Een project is een tijdgebonden, doelgerichte verandering apart systeem met in eerste instantie duidelijk omschreven doelen, waarvan de realisatie bepalend is voor de voltooiing van het project, evenals met vastgestelde eisen de timing, resultaten, risico, omvang van de uitgaven en organisatiestructuur.

Gewoonlijk is het voor een complex concept (dat in het bijzonder het concept van een project is) moeilijk om een ​​eenduidige formulering te geven die alle kenmerken van het geïntroduceerde concept volledig omvat. Daarom pretendeert de gegeven definitie niet uniek en volledig te zijn.

De volgende hoofdkenmerken van het project als beheerobject zijn te onderscheiden:

Variabiliteit is een doelgerichte overdracht van een systeem van een bestaand naar een bepaald systeem

de gewenste staat, beschreven in termen van de doelstellingen van het project;

De beperking van het uiteindelijke doel;

Beperkte duur;

Beperkt budget;

Beperkte middelen nodig;

Nieuwheid voor de onderneming waarvoor het project wordt uitgevoerd;

Complexiteit - de aanwezigheid van een groot aantal factoren die direct of indirect van invloed zijn op de voortgang en resultaten van het project;

Juridische en organisatorische ondersteuning- het creëren van een specifieke organisatiestructuur voor de duur van het project.

Werkefficiëntie wordt bereikt door het beheer van het projectimplementatieproces, dat zorgt voor de toewijzing van middelen, de coördinatie van de werkvolgorde en compensatie van interne en externe storende invloeden.

Vanuit het oogpunt van de theorie van controlesystemen moet het project als controleobject observeerbaar en controleerbaar zijn, dat wil zeggen dat er enkele kenmerken worden onderscheiden waardoor het mogelijk is om de voortgang van het project constant te volgen (de eigenschap van observeerbaarheid) . Daarnaast zijn mechanismen nodig om het verloop van de projectuitvoering tijdig te beïnvloeden (de eigenschap van beheersbaarheid).

De eigenschap van beheersbaarheid is vooral belangrijk in omstandigheden van onzekerheid en variabiliteit van het vakgebied, die vaak gepaard gaan met projecten voor de ontwikkeling van informatiesystemen.

Elk project, ongeacht de complexiteit en de hoeveelheid werk die nodig is voor de uitvoering ervan, doorloopt bepaalde fasen in zijn ontwikkeling: van een toestand waarin "het project er nog niet is" tot een toestand waarin "het project er niet meer is". De reeks ontwikkelingsstadia vanaf het ontstaan ​​van een idee tot de volledige voltooiing van het project is gewoonlijk verdeeld in fasen (stadia, stadia).

Er zijn enkele verschillen bij het bepalen van het aantal fasen en hun inhoud, aangezien deze kenmerken grotendeels afhangen van de voorwaarden voor de uitvoering van een bepaald project en de ervaring van de belangrijkste deelnemers. Niettemin zijn de logica en de hoofdinhoud van het ontwikkelingsproces van het informatiesysteem in bijna alle gevallen hetzelfde.

De volgende fasen van de ontwikkeling van informatiesystemen kunnen worden onderscheiden:

Conceptvorming;

Ontwikkeling van technische specificaties;

Ontwerp;

Productie;

Het systeem in gebruik nemen.

Laten we elk van hen in meer detail bekijken. De tweede en gedeeltelijk de derde fase worden meestal de fasen van systeemontwerp genoemd, en de laatste twee (soms omvat dit ook de ontwerpfase) - de fasen van implementatie.

Conceptuele fase

Ideevorming, doelen stellen;

Vorming van een belangrijk projectteam;

Het bestuderen van de motivatie en wensen van de klant en andere deelnemers;

Verzameling van baselinegegevens en analyse van de bestaande toestand;

Bepaling van basisvereisten en beperkingen, benodigde materiële, financiële en arbeidsmiddelen;

Vergelijkende beoordeling van alternatieven;

Indiening van voorstellen, hun onderzoek en goedkeuring.

Ontwikkeling van een technisch voorstel

Ontwikkeling van de hoofdinhoud van het project, de basisstructuur van het project;

Ontwikkeling en goedkeuring van technische specificaties;

Planning, decompositie van het structurele basismodel van het project;

Inschatten en budgetteren van het project, bepalen van de behoefte aan middelen;

Ontwikkeling kalender plannen en uitgebreide werkschema's;

Het ondertekenen van een contract met een klant;

Het in gebruik nemen van de communicatiemiddelen van de projectdeelnemers en controle over de voortgang van de werkzaamheden.

Ontwerp

In deze fase worden subsystemen, hun onderlinge verbindingen bepaald, de meest effectieve manieren projectuitvoering en gebruik van middelen. Karakteristieke werken deze fase:

Basis uitvoeren design werk;

Ontwikkeling van privé technische specificaties;

Conceptueel ontwerp;

Het opstellen van technische specificaties en instructies;

Ontwerp indiening, expertise en goedkeuring.

Ontwikkeling

In deze fase vindt coördinatie en operationele aansturing van projectwerk plaats, worden subsystemen vervaardigd, gecombineerd en getest. Belangrijkste inhoud:

Implementatie vanen;

Voorbereiden van de implementatie van het systeem;

Controle en regulering van de belangrijkste indicatoren van het project.

Systeem inbedrijfstelling

Tijdens deze fase worden tests uitgevoerd, proefbedrijf van het systeem in reële omstandigheden, onderhandelingen gaande over de resultaten van het project en over eventuele nieuwe contracten. Belangrijkste soorten werk:

Complexe testen;

42. Het concept van de levenscyclus van IP. (Onderwerp 11, blz. 103-105).