Stuur uw goede werk in de kennisbank is eenvoudig. Gebruik het onderstaande formulier

Studenten, afstudeerders, jonge wetenschappers die de kennisbasis gebruiken in hun studie en werk zullen je zeer dankbaar zijn.

Geplaatst op http://www.allbest.ru/

Omsk State Institute of Service

Modellering van informatiesystemen met behulp van de UML-taal

Methodische instructies voor de implementatie van term paper

IV Chervenchuk

• Invoering
• 2 . Uniforme modelleringstaalUML
• 4. Ontwikkeling van een softwaresysteemmodel door middel vanUML
• 5. Vragen over de implementatie van het informatiesysteem
• 6. Onderwerpen van cursussen
• Bibliografische lijst

Invoering

De paper behandelt de ontwikkeling van informatiesystemen met behulp van de uniforme modelleertaal UML, die de basis vormt voor het cursuswerk in de discipline "Informatiesystemen en -processen. Modellering en management". De belangrijkste fasen van een rationeel verenigd proces van het ontwikkelen van informatiesystemen worden uitgewerkt, voorbeelden en illustraties worden gegeven. Opties voor opdrachten voor cursussen worden gegeven.

Methodische instructies zijn bedoeld voor studenten van de specialiteit "Toegepaste Informatica" en kunnen worden gebruikt in cursussen, voorbereiding op het examen en in het proces van zelfstandig werk.

1. Algemene vereisten voor de implementatie van scriptie

Cursuswerk over de discipline "Informatiesystemen en -processen. Modellering en management" is de laatste fase van het bestuderen van deze cursus en is bedoeld om de theoretische basiskennis van het modelleren van informatiesystemen in de praktijk te consolideren. Het werk bestaat uit het ontwikkelen van een model van een informatiesysteem door middel van de uniforme modelleertaal UML met de daaropvolgende implementatie. Als typische versie van de opdracht wordt voorgesteld om een ​​informatie- en referentiesysteem te ontwikkelen op basis van een database, maar op verzoek van de student, in overleg met de leraar, kan de ontwikkeling van een WEB-applicatie, testsysteem of hardwareapparaat als opdracht worden aangeboden. Tegelijkertijd is de belangrijkste voorwaarde het gebruik van een objectgeoriënteerde benadering en de constructie van een UML-model.

De typische titel van de term paper ziet eruit als "Ontwikkeling van een informatie- en referentiesysteem _ titel _ "

Invoering

1. Inhoudelijk overzicht van het vakgebied. Basis systeemvereisten

2. Een gedetailleerd model van het informatiesysteem

2.1 Uitzicht vanuit het perspectief van use cases

2.2 Ontwerpweergave

2.3 Implementatieweergave

2.4 Procesperspectief (indien van toepassing)

2.5 Uitzicht vanuit het oogpunt van inzet (indien nodig)

3. Implementatie van het informatiesysteem

Gevolgtrekking

Toepassingslijst van een programma of hoofdmodule

In de inleiding kan worden gewezen op het gebruik van informatietechnologie in verschillende werkterreinen, waaronder de dienstensector, de voordelen van elektronische boekhouding, de problemen bij het bouwen van gespecialiseerde informatiesystemen, enz.

Deze richtlijnen bevatten gedetailleerde aanbevelingen voor de hoofdsecties van de toelichting en ontwerpvoorbeelden. Opgemerkt moet worden dat het hoofdonderwerp van dit cursuswerk de ontwikkeling van een UML-model van een informatiesysteem is, daarom wordt het ten zeerste aanbevolen om UML-diagrammen in het hoofdgedeelte van een toelichting te geven, met gedetailleerde opmerkingen. , en de teksten van programma's moeten in de applicatie worden geplaatst.

De procesweergave moet worden gegeven bij het ontwerpen van multitasking-systemen. De implementatieweergave gaat uit van een gedistribueerd informatiesysteem. Deze typen, en de bijbehorende paragrafen van de toelichting, zijn niet verplicht voor de uitvoering van dit cursuswerk, het gebruik ervan wordt verondersteld bij het uitvoeren van alleen bepaalde varianten van het cursuswerk.

Bij het belichten van de problemen van systeemimplementatie in een notitie, is het raadzaam om de keuze voor een programmeeromgeving te rechtvaardigen, door een gebruikershandleiding te verstrekken. Een verplicht element is het opnemen van schermformulieren (screen-shorts) van het geïmplementeerde programma in de tekst, het gebruik van reverse engineering tools wordt aangemoedigd.

In de conclusie worden de belangrijkste resultaten van het werk kort samengevat: er is een UML-model van het systeem ontwikkeld, het systeem is geïmplementeerd via de programmeeromgeving die het ontwikkelde systeem toelaat, de voordelen van de gebruikte benaderingen (gebaseerd op over modellering) tot het ontwerpen van systemen.

taal voor het modelleren van informatiesysteem

Het cursuswerk moet 20-30 pagina's met gedrukte tekst met illustraties bevatten. Diagrammen van use-cases, klassen, interacties moeten zonder mankeren worden verstrekt.

2. Uniforme modelleringstaal UML

De rationele ontwikkeling van een informatiesysteem veronderstelt een diepgaand analytisch vooronderzoek. Allereerst is het noodzakelijk om de reeks taken te schetsen die worden uitgevoerd door het systeem dat wordt ontwikkeld, vervolgens om een ​​model van het systeem te ontwikkelen en ten slotte om de implementatiemethoden te bepalen. Een diepgaande studie van de architectuur van het informatiesysteem dat in de eerste ontwerpfasen wordt ontwikkeld, loont in de regel later, vooral bij het ontwikkelen van grootschalige projecten met ondersteuning op lange termijn.

De tools van de modelleertaal UML (Unified Model Language, - een uniforme programmeertaal) maken het expressief en vrij eenvoudig mogelijk om een ​​voorlopige conceptuele ontwikkeling van een informatiesysteem uit te voeren en tegelijkertijd het hele ontwikkelingsproces methodisch te begeleiden, inclusief de gehele verdere levenscyclus van het ontwikkelde informatiesysteem als softwareproduct.

UML is een objectgeoriënteerde taal voor het visualiseren, specificeren, construeren en documenteren van artefacten van softwaresystemen.

De UML bestaat, net als elke andere taal, uit een vocabulaire en regels waarmee u de woorden die erin zijn opgenomen kunt combineren en zinvolle constructies kunt krijgen. In een modelleertaal zijn woordenschat en regels gericht op de conceptuele en fysieke representatie van informatiesystemen. Modellering is essentieel om het systeem te begrijpen. Dat gezegd hebbende, een enkel model is nooit genoeg. Integendeel, om een ​​niet-triviaal systeem te begrijpen, moet men een groot aantal onderling gerelateerde modellen ontwikkelen. Zoals toegepast op softwaresystemen, betekent dit dat er een taal nodig is waarmee het mogelijk is om vanuit verschillende gezichtspunten de representaties van de architectuur van het systeem gedurende zijn ontwikkelingscyclus te beschrijven.

UML is een visualisatietaal en UML is niet alleen een verzameling grafische symbolen. Elk van hen heeft een goed gedefinieerde semantiek (zie).Zo kan een model dat door de ene ontwikkelaar is geschreven, ondubbelzinnig worden geïnterpreteerd door een andere, of zelfs door een toolkit.

UML is een specificatietaal. Specificeren betekent in deze context het bouwen van nauwkeurige, eenduidige en complete modellen. De UML maakt de specificatie mogelijk van alle belangrijke analyse-, ontwerp- en implementatiebeslissingen die moeten worden genomen tijdens de ontwikkeling en implementatie van een softwaresysteem.

UML is een ontwerptaal. Hoewel de UML geen visuele programmeertaal is, kunnen de modellen die ermee gemaakt worden direct vertaald worden in verschillende specifieke programmeertalen. Met andere woorden, het UML-model kan worden toegewezen aan talen zoals Java, C++, Visual Basic en zelfs relationele databasetabellen of persistente objectgeoriënteerde database-objecten. Die concepten die bij voorkeur grafisch worden overgebracht, worden in de UML weergegeven; degenen die beter in tekstvorm worden beschreven, worden uitgedrukt met behulp van een programmeertaal.

Deze mapping van een model naar een programmeertaal maakt direct ontwerp mogelijk: het genereren van code van een UML-model in een specifieke taal. Je kunt ook het omgekeerde probleem oplossen: herstel het model vanuit de bestaande implementatie. Bij het model en de uitvoering wordt uiteraard gebruik gemaakt van een aantal specifieke entiteiten. Daarom vereist reverse engineering zowel tooling als menselijke tussenkomst. De combinatie van voorwaartse codegeneratie en reverse engineering stelt u in staat om in zowel grafische als tekstuele representaties te werken, zolang de tools maar zorgen voor consistentie tussen beide representaties.

Naast directe mapping naar programmeertalen, stelt de UML, vanwege zijn expressiviteit en eenduidigheid, u in staat om direct modellen uit te voeren, het gedrag van systemen te simuleren en besturingssystemen te besturen.

UML is een documentatietaal

Een softwarebedrijf produceert naast uitvoerbare code ook andere documenten, waaronder:

systeem vereisten;

architectuur;

project;

bron;

projectplannen;

testen;

prototypen;

versies, enz.

Afhankelijk van de gehanteerde ontwikkelingsmethodiek worden sommige werken formeler uitgevoerd, andere minder. De genoemde documenten zijn niet alleen aangeleverde onderdelen van het project; ze zijn nodig voor het management, voor het evalueren van het resultaat en ook als communicatiemiddel tussen teamleden tijdens de ontwikkeling van het systeem en na de implementatie ervan.

De UML biedt de ontwikkelaar en het management hun eigen oplossing voor het probleem van het documenteren van de systeemarchitectuur en al zijn details, biedt een taal voor het formuleren van systeemvereisten en het definiëren van tests, en biedt ten slotte een middel voor het modelleren van werk tijdens de projectplanning en versiebeheer fase.

Laten we eens kijken naar de ontwikkeling van een model van een informatiesysteem door middel van de UML-taal aan de hand van het voorbeeld van de ontwikkeling van een geautomatiseerd werkstation voor een afdelingssecretaris (hierna AWP van een afdelingssecretaresse genoemd).

3. Beschrijving van het vakgebied

Het concept van een database-onderwerp is een van de basisconcepten van de informatica en heeft geen precieze definitie. Het gebruik ervan in de context van IP veronderstelt het bestaan ​​van een stabiele correlatie in de tijd tussen namen, concepten en bepaalde realiteiten van de externe wereld, onafhankelijk van de IP zelf en zijn gebruikerskring. Dus de introductie in overweging van het concept van het databasedomein beperkt en maakt de informatieophaalruimte zichtbaar in de IS en maakt het mogelijk om query's in een eindige tijd uit te voeren.

Onder de beschrijving van het vakgebied verstaan ​​we de beschrijving van de omgeving van het systeem dat wordt ontwikkeld, de soorten gebruikers van het systeem, maar ook de hoofdtaken, waarvan de oplossing aan het systeem wordt toegewezen.

In de voorlopige beschrijving van het vakgebied worden de basisbegrippen geïntroduceerd (systeemvocabulaire), worden de soorten gebruikers en hun rechten bepaald, worden de taken geformuleerd die het ontwikkelde systeem moet oplossen. In dit geval wordt verondersteld dat de beschrijving gebruik maakt van gewone taal en standaard zakelijke afbeeldingen (afbeeldingen, diagrammen, tabellen).

Bij het ontwikkelen van een systeemwoordenboek is het noodzakelijk om de namen van entiteiten ("student", "leraar", "discipline") te definiëren. In dit geval wordt de term essentie door ons begrepen als een onderdeel van het domeinmodel, dat wil zeggen als een object dat al op conceptueel niveau is geïdentificeerd. De objecten die in het onderwerpgebied zijn toegewezen, worden door de analist omgezet in entiteiten.

Entiteit is het resultaat van abstractie van een echt object. Er zijn twee problemen verbonden aan objecten: identificatie en adequate beschrijving. Voor identificatie wordt een naam gebruikt, die uniek moet zijn. In dit geval wordt aangenomen dat de betekenis ervan wordt afgewezen, wat inherent is aan natuurlijke taal. Alleen de indicatieve functie van de naam wordt gebruikt. De naam is een directe manier om een ​​object te identificeren. Indirecte methoden voor objectidentificatie omvatten de definitie van een object door zijn eigenschappen (kenmerken of tekens).

Objecten interageren met elkaar door hun eigenschappen, waardoor situaties ontstaan. Situaties zijn relaties die relaties tussen objecten uitdrukken. Situaties in het vakgebied worden beschreven aan de hand van uitspraken over het vakgebied. In dit stadium kunt u de methoden van propositierekening en predikaatrekening gebruiken, dat wil zeggen formele, wiskundige logica. De stelling "De programmeur en de manager zijn werknemers van het bedrijf" beschrijft bijvoorbeeld een inclusieve relatie. Zo wordt alle informatie over objecten en entiteiten van het domein beschreven met behulp van verklaringen in natuurlijke taal.

U kunt structurele koppelingen specificeren, statische en dynamische situaties markeren (waardoor een tijdparameter in het model wordt geïntroduceerd), maar voor een gedetailleerde studie van het model is het handiger om geavanceerde manieren te gebruiken om het domein te beschrijven, bijvoorbeeld middelen van de UML-taal.

De taak is dus om een ​​systeem te ontwikkelen "Werkstation van de secretaris van de afdeling" dat een geautomatiseerde boekhouding van gegevens over werknemers en studenten van de afdeling ICT van OmSTU mogelijk maakt, flexibele mogelijkheden biedt voor het oplossen van geplande en ongeplande specifieke verwerkingstaken Inloggegevens.

Als onderdeel van het oplossen van het probleem van het ontwikkelen van een geautomatiseerde werkplek voor de secretaris van de afdeling, zullen we de volgende entiteiten uitlichten:

leraren - docenten van de afdeling;

studenten- studenten van de universiteit van dit specialisme;

studenten studeren in groepen, groep is een organiserend (verenigend) geheel voor studenten;

afgestudeerde studenten, hebben de bijzonderheid dat ze enerzijds zelf lessen kunnen geven, anderzijds dat ze zelf student zijn en een wetenschappelijk adviseur hebben;

discipline- de aangeleerde discipline (vak, vak).

Ingevoegde entiteiten hebben een aantal attributen, die we later zullen definiëren.

We hebben twee soorten gebruikers: privé gebruiker(verder gebruiker, en beheerder... Er wordt aangenomen dat gebruiker kan met een verzoek toegang krijgen tot het systeem, rapporten weergeven, beheerder kan bovendien gegevens wijzigen. Zo kan de adjunct-secretaris van de afdeling optreden als gebruiker, de secretaresse zelf of de verantwoordelijke docent als beheerder.

Rekening houdend met de ingevoerde voorwaarden, moet het systeem dat wordt ontwikkeld het volgende bieden:

organisatie van een volledige en betrouwbare boekhouding van alle medewerkers en studenten van de afdeling;

informatieve ondersteuning van genomen managementbeslissingen, het vormen van volledige en betrouwbare informatie over onderwijsprocessen en de resultaten van de activiteiten van de afdeling;

vermindering van arbeidskosten voor het opstellen van primaire documenten en rapporten;

eliminatie van dubbel werk bij het invoeren van informatie en de daaruit voortvloeiende mechanische fouten;

gebruiksvriendelijke interface;

differentiatie van de bevoegdheden van gewone gebruikers en de beheerder.

In dit voorbeeld lossen we een bepaald probleem op - we ontwikkelen een AWP voor de secretaris van de afdeling, daarom wordt de afdeling voor ons als een structurele eenheid van het hoogste niveau beschouwd, wat we standaard in gedachten zullen hebben, dat wil zeggen, er wordt van uitgegaan dat alle elementen van het model alleen betrekking hebben op deze afdeling, die niet expliciet is gespecificeerd ... We kijken niet naar structuren op een hoger niveau, zoals een faculteit, een universiteit.

4. Ontwikkeling van een softwaresysteemmodel met behulp van UML

De UML is een taal voor specificatie en visualisatie, de belangrijkste eenheden zijn diagrammen.

Een UML-diagram is een grafische weergave van een set stencils, meestal afgebeeld als een verbonden grafiek met hoekpunten (entiteiten) en randen (relaties). De diagrammen karakteriseren het systeem vanuit verschillende gezichtspunten. Een diagram is in zekere zin een van de projecties van het systeem. Doorgaans bieden grafieken een samengevouwen weergave van de elementen waaruit een systeem bestaat. Een en hetzelfde element kan in alle diagrammen voorkomen, of alleen in meerdere (de meest voorkomende variant), of in geen enkele (zeer zelden). In theorie kunnen diagrammen elke combinatie van entiteiten en relaties bevatten. In de praktijk wordt echter een relatief klein aantal typische combinaties gebruikt, overeenkomend met de vijf meest voorkomende typen waaruit de architectuur van een softwaresysteem bestaat (zie de volgende paragraaf). Zo worden in de UML negen typen diagrammen onderscheiden:

klassendiagrammen

objectdiagrammen;

use case-diagrammen;

volgorde diagrammen;

samenwerkingsdiagrammen;

toestandsdiagrammen;

actie (activiteiten) diagrammen;

component diagrammen;

inzet diagrammen.

UML conceptueel model

Een klassendiagram toont klassen, interfaces, objecten en samenwerkingsverbanden en hun relaties. Bij het modelleren van objectgeoriënteerde systemen wordt dit type diagram het vaakst gebruikt. Klassendiagrammen komen overeen met de statische ontwerpweergave van het systeem. Klassendiagrammen met actieve klassen komen overeen met de statische weergave van het systeem vanuit een procesperspectief.

Een objectdiagram stelt objecten en de relaties daartussen voor. Het zijn statische "foto's" van de entiteitsinstanties die worden weergegeven in klassendiagrammen. Objectdiagrammen, zoals klassendiagrammen, verwijzen naar een statische weergave van een systeem vanuit een ontwerp- of procesperspectief, maar met het oog op een echte of schijnimplementatie.

Het use-case diagram toont use cases en actoren (een speciaal geval van klassen), evenals de relaties daartussen. Use case-diagrammen verwijzen naar een statische weergave van een systeem in termen van use cases. Ze zijn vooral belangrijk bij het organiseren en modelleren van het gedrag van een systeem.

Sequentiediagrammen en samenwerkingsdiagrammen zijn speciale gevallen van interactiediagrammen. Interactiediagrammen geven relaties tussen objecten weer; toont met name de berichten die objecten kunnen uitwisselen. Interactiediagrammen verwijzen naar de dynamische weergave van het systeem. In dit geval weerspiegelen sequentiediagrammen de temporele ordening van berichten en samenwerkingsdiagrammen - de structurele organisatie van objecten die berichten uitwisselen. Deze diagrammen zijn isomorf, dat wil zeggen dat ze in elkaar kunnen worden omgezet.

Statechart-diagrammen vertegenwoordigen een automaat die toestanden, overgangen, gebeurtenissen en soorten acties omvat. Toestandsdiagrammen verwijzen naar de dynamische weergave van het systeem; ze zijn vooral belangrijk bij het modelleren van het gedrag van een interface, klasse of samenwerking. Ze richten zich op het gedrag van een object, afhankelijk van de volgorde van gebeurtenissen, wat erg handig is voor het simuleren van reactieve systemen.

Een activiteitendiagram is een speciaal geval van een toestandsdiagram; het toont de overgangen van de stroom van controle van de ene activiteit naar de andere binnen het systeem. Activiteitendiagrammen verwijzen naar een dynamische weergave van een systeem; ze zijn het belangrijkst bij het modelleren van de werking ervan en weerspiegelen de stroom van controle tussen objecten.

Het componentendiagram toont de organisatie van een set componenten en de afhankelijkheden daartussen. Componentdiagrammen verwijzen naar een statische weergave van een systeem vanuit het oogpunt van implementatie. Ze kunnen gerelateerd zijn aan klassendiagrammen, aangezien een component meestal wordt toegewezen aan een of meer klassen, interfaces of samenwerkingen.

Het implementatiediagram toont de configuratie van de verwerkingsknooppunten van het systeem en de componenten die daarin zijn geplaatst. Implementatiediagrammen verwijzen naar een statische weergave van de architectuur van een systeem vanuit een implementatieperspectief. Ze zijn gerelateerd aan componentdiagrammen omdat een subassemblage meestal een of meer componenten bevat.

Hier is een gedeeltelijke lijst van diagrammen die in de UML worden gebruikt. Met de tools kunt u ook andere diagrammen genereren, zoals databaseprofieldiagrammen, webtoepassingsdiagrammen, enzovoort.

4.1 Een weergave ontwerpen vanuit een use-caseperspectief

Modellering begint met het definiëren van de belangrijkste doelstellingen van het systeem dat wordt ontwikkeld en de acties die het moet uitvoeren. Hiervoor worden use case diagrammen gebruikt. Zoals eerder besproken, geven use case diagrammen use cases en actoren aan en de relaties daartussen.

Precedent (Use case) is een beschrijving van een reeks acties die door het systeem worden uitgevoerd en die een waarneembaar resultaat oplevert dat significant is voor een bepaalde handeling e ra (Acteur). Use case wordt gebruikt om de gedragsentiteiten van het model te structureren. De use case geeft alleen een beschrijving van een actie van het systeem en beantwoordt de vraag "wat te doen?", maar geeft niet aan met welke middelen. De concrete implementatie van het gedrag gespecificeerd door de use case wordt geleverd door een klasse, klassensamenwerking of component.

Een actor is een samenhangend geheel van rollen die gebruikers van use-cases spelen wanneer ze met hen communiceren. Typisch vertegenwoordigt een actor de rol die een persoon, hardwareapparaat of zelfs een ander systeem in een bepaald systeem speelt. In het ontwikkelde systeem "Werkstation van de secretaris van de afdeling" zijn de acteurs de beheerder (beheerder) en gebruiker.

Grafisch wordt een precedent afgebeeld als een ellips begrensd door een ononderbroken lijn, meestal met alleen de naam, de acteur heeft een "kleine man"-pictogram.

Om een ​​use case-diagram op te bouwen, is het noodzakelijk om de elementaire acties die door het systeem worden uitgevoerd te identificeren en deze te vergelijken met use cases. Tegelijkertijd is het wenselijk om de namen van use-cases te geven zodat ze het gedrag aangeven, vaak bevatten dergelijke namen werkwoorden, bijvoorbeeld "genereer een rapport", "zoek gegevens op criterium", enz. Het is mogelijk om namen te geven aan gebruiksgevallen met zelfstandige naamwoorden die bepaalde acties suggereren, bijvoorbeeld "autorisatie", "zoeken", "controle".

Terugkomend op de modellering van de geautomatiseerde werkplek van de secretaris van de afdeling, laten we de precedenten benadrukken:

Bewerkengegevens,

Zoekopdrachtleerling,

Zoekopdrachtdocent,

Uitgiftelijstonderwezendisciplines,

autorisatie.

Elementen van use case diagrammen (use cases en actoren) moeten door middel van relaties met elkaar verbonden zijn.

De meest voorkomende relatie tussen use cases, use cases en actoren is associatie. In sommige gevallen kunnen generalisatierelaties worden gebruikt. Deze relaties hebben dezelfde betekenis als in het klassendiagram.

Daarnaast zijn er twee specifieke afhankelijkheden gedefinieerd tussen use-cases in de UML: een inclusierelatie en een extensierelatie.

Een inclusierelatie tussen use cases betekent dat op een bepaald moment in de basis use case het gedrag van een andere use case wordt opgenomen (inbegrepen). De meegeleverde use case bestaat nooit autonoom, maar wordt alleen geïnstantieerd als onderdeel van de omsluitende use case. Je kunt de basisgebruikscasus beschouwen als het lenen van het gedrag van de include. Door de aanwezigheid van inclusierelaties is het mogelijk om meerdere beschrijvingen van dezelfde stroom van gebeurtenissen te vermijden, aangezien het algemene gedrag kan worden beschreven als een onafhankelijke use-case die is opgenomen in de basisscenario's. Een inclusierelatie is een voorbeeld van delegatie, waarbij een aantal verantwoordelijkheden van het systeem op één plek worden beschreven (in de meegeleverde use case), en de rest van de use cases, indien nodig, deze verantwoordelijkheden in hun set opnemen.

Inclusierelaties worden afgebeeld als afhankelijkheden met het stereotype "opnemen". Om een ​​plaats in de stroom van gebeurtenissen te specificeren waar een basisgebruiksgeval het gedrag van een ander omvat, schrijft u gewoon het woord include gevolgd door de naam van het gebruiksgeval dat u wilt opnemen.

Een extensierelatie wordt gebruikt om delen van een use case te modelleren die de gebruiker als optioneel systeemgedrag beschouwt. Hierdoor kunt u verplicht en optioneel gedrag scheiden. Uitbreidingsrelaties worden ook gebruikt om individuele substromen te modelleren die alleen onder bepaalde omstandigheden worden uitgevoerd. Ten slotte worden ze gebruikt om meerdere streams te simuleren die op een bepaald punt in het script kunnen worden geactiveerd als gevolg van expliciete interactie met de acteur.

De verlengingsrelatie wordt afgebeeld als een afhankelijkheid met het stereotype "verlengen". De basisscriptuitbreidingspunten worden vermeld in een extra sectie. Het zijn gewoon labels die kunnen verschijnen in de stroom van de onderliggende use case.

Een voorbeeld van het gebruik van deze relatie kan toegang zijn tot een database met een operationeel deel en een archief. In dit geval, als het verzoek is voorzien van gegevens uit het operationele deel, wordt de belangrijkste (basis) toegang tot de gegevens uitgevoerd, als de gegevens uit het operationele deel niet voldoende zijn, wordt toegang verkregen tot de archiefgegevens, dat wil zeggen toegang is uitgevoerd volgens het geavanceerde scenario.

In ons geval, het precedent bewerkengegevens omvat use-cases: invoergegevens, verwijderinggegevens, de veranderinggegevens.

Het diagram van de precedenten van de AWP van de secretaris van de afdeling wordt getoond in Fig. 1.

Rijst. 1. Schema van de precedenten van de AWP van de secretaris van de afdeling

Precedent Zoekopdrachtleerling omvat zoeken op achternaam en zoeken op resultaten van academische prestaties.

Bij het ontwerpen van een view in termen van use cases is het vaak nodig om een ​​uitgebreide beschrijving van de use case te geven (in de verkorte versie wordt alleen de naam gegeven). Meestal wordt de stroom van gebeurtenissen van een use case aan het begin in tekstvorm beschreven. Naarmate u uw systeemvereisten verfijnt, wordt het handiger om over te gaan op een grafische weergave van stromen in activiteiten- en interactiediagrammen.

Gebeurtenissenstromen kunnen worden beschreven door middel van ongestructureerde tekst, gestructureerde tekst (met dienstwoorden: ALS,VOORDATDIEPORDOEI enz.), een gespecialiseerde formele taal (pseudocode).

Bij het beschrijven van een use case als een stroom van gebeurtenissen, is het belangrijk om ook de hoofd- en alternatieve stromen van het systeemgedrag aan te duiden.

Denk bijvoorbeeld aan de beschrijving van de stroom van gebeurtenissen van de use case autorisatie.

Basis stromen evenementen. De use case begint wanneer het systeem de gebruiker om zijn login en wachtwoord vraagt. De gebruiker kan het invoeren vanaf het toetsenbord. De invoer eindigt met een toetsdruk. Binnenkomen. Daarna controleert het systeem de ingevoerde Login en wachtwoord, en als deze overeenkomen met de beheerder, bevestigt het de autoriteit van de beheerder. Hiermee is het precedent gesloten.

Uitzonderlijk stromen evenementen. De klant kan de transactie op elk moment beëindigen door op de toets . te drukken Annuleren. Deze actie begint het precedent helemaal opnieuw. Er is geen invoer in het systeem.

Uitzonderlijk stromen evenementen. De klant kan zijn Login en wachtwoord op elk moment wissen voordat hij op de Enter-toets drukt.

Uitzonderlijk stromen evenementen. Als de klant Login en wachtwoord heeft ingevoerd die niet overeenkomen met de beheerder, wordt hem aangeboden om opnieuw in te voeren of in te loggen op het systeem als een gewone gebruiker.

Het is duidelijk dat de beschrijving van een use case door een stroom van gebeurtenissen een soort algoritme veronderstelt dat kan worden weergegeven in een activiteitendiagram (Fig. 2).

Het algoritmediagram moet de begin- en eindpunten bevatten, met slechts één begin en één einde. Het diagram bevat uitvoerbare hoekpunten - activiteiten (aangegeven door afgeronde rechthoeken), voorwaardelijke hoekpunten (beslissing - selectie, herkenning, aangegeven door ruitjes) en links.

Vergelijkbare diagrammen kunnen de uitvoering van andere use-cases verklaren, en vormen zo een aanvulling op de weergave van het systeem vanuit het oogpunt van use-cases.

Rijst. 2. Gebruikersautorisatie. Activiteiten diagram.

4.2 Een ontwerpvisie ontwikkelen

De ontwerpvisie is de belangrijkste fase in de conceptuele studie van het model. In dit stadium worden de basisabstracties geïntroduceerd, klassen en interfaces gedefinieerd waarmee de oplossing van de taken wordt geïmplementeerd. Als de use-cases alleen het gedrag van het systeem aangeven, wordt in het stadium van de ontwikkeling van de weergave vanuit het ontwerpoogpunt bepaald met welke middelen deze use-cases zullen worden geïmplementeerd. Statische aspecten van dit type worden ontwikkeld via klassendiagrammen, dynamische - via interactie- en toestandsdiagrammen (automaat).

Klassendiagrammen bevatten klassen, interfaces, samenwerkingsverbanden en verbindingen daartussen. De ontwikkeling van een klassendiagram moet beginnen met de definitie van klassen die overeenkomen met de belangrijkste entiteiten van het systeem, die in de regel worden bepaald in de beginfasen van ontwikkeling bij het beschrijven van het vakgebied. Hier is het noodzakelijk om te beslissen welke entiteiten handiger zijn om als klassen te modelleren, en welke als hun attributen. Als het bijvoorbeeld binnen de faculteit verplicht zou zijn om het hoofd van elke afdeling aan te duiden, zou het beter zijn om te specificeren: managerStoelen maak er een klasse-attribuut van stoel de klas aangeven leraren ( een-op-een associatie ), in plaats van een aparte klasse te introduceren managerStoelen.

Bij het modelleren moet er rekening mee worden gehouden dat elke klasse moet overeenkomen met een echte entiteit of conceptuele abstractie van het gebied waarmee de gebruiker of ontwikkelaar te maken heeft. Een goed gestructureerde klasse heeft de volgende eigenschappen:

is een goed gedefinieerde abstractie van een concept uit het vocabulaire van het probleemgebied of het oplossingsgebied;

bevat een kleine, goed gedefinieerde reeks verantwoordelijkheden en voert ze allemaal uit;

handhaaft een duidelijke scheiding tussen abstractiespecificaties en de implementatie ervan;

begrijpelijk en eenvoudig, maar maakt tegelijkertijd uitbreiding en aanpassing aan nieuwe taken mogelijk.

Als onderdeel van de ontwikkeling van het model van de geautomatiseerde werkplek van de secretaris van de afdeling, zullen we de klassen definiëren: leraren, studenten, afgestudeerde studenten, disciplines, groep... Het is duidelijk dat de eerste veel gemeenschappelijke kenmerken hebben, dus laten we een abstracte klasse introduceren PEerson, die alle menselijke eigenschappen omvat in de context van het systeem dat wordt ontwikkeld (achternaam, voornaam, adres, enz.). In dit geval een persoon zal de superklasse zijn en communiceren via een generieke relatie met de klassen leraren, studenten, afgestudeerde studenten.

Attribuut het adres heeft zijn eigen structuur, om het weer te geven kun je een extra klasse introduceren, laten we het noemen t_ ADR(zoals gebruikelijk is in veel programmeersystemen, beginnen klassenamen met de letter T). Merk op dat het attribuut het adres klas een persoon is een instantie van de klasse t_ ADR, dat wil zeggen, er wordt een afhankelijkheidsrelatie tot stand gebracht tussen deze klassen (weergegeven door een gestippelde pijl met een open punt, de pijl is gericht van het afhankelijke naar het onafhankelijke). In ons geval, de structuur van de klas veranderen t_ ADR brengt een klassewisseling met zich mee een persoon door de structuur van het bijbehorende attribuut ( het adres).

Bij het modelleren van een klas t_ ADR attribuut inhoudsopgave ingesteld door middel van een primitief type t_ POSTIDX, gedefinieerd als een decimaal getal van zes cijfers. Primitieve types zijn stereotiep" type" , wordt het waardenbereik gespecificeerd door de beperkingen tussen accolades.

In de klas docent laten we de specifieke kenmerken benadrukken die alleen betrekking hebben op de leraar: positie, uch. rang(academische graad), uch. rang ( academische rang), afvoer(categorie van één tariefschaal). attributen uch. rang en uch. rang het is beter om gespecialiseerde typen te definiëren via opsomming. Opsommingen worden gemodelleerd door een klasse met het stereotype " opsomming" (opsomming - opsomming), toegestane waarden worden geschreven als attributen, labels die de zichtbaarheid van attributen bepalen worden onderdrukt. In het overwogen voorbeeld introduceren we via de opsomming gespecialiseerde klassen t_Moeten, T_UCHST, T_UchZv, respectievelijk het definiëren van mogelijke posities, academische graden, academische titels door middel van overdrachten. In dit geval, zoals elders in vergelijkbare gevallen, worden bij het maken van klassen die de attributen van de hoofdklasse specificeren, afhankelijkheidsrelaties vastgesteld.

Voor de les leerling een specifiek attribuut wordt geïntroduceerd Kamerplatenboeken... Specifieke attributen zijn gedefinieerd voor de postdoctorale klas formulieraan het leren en datumbonnetjes... De vorm van studie wordt bepaald door een speciale klas door middel van een opsomming T_FormObuch(Voltijd Deeltijd).

Klas groep heeft attributen: titel, formulier aan het leren, nummerdekhengst. ( aantal studenten ). Aangezien de docenten van de betreffende afdeling les kunnen geven aan groepen van andere faculteiten, wordt er een extra klas ingevoerd specialiteit, met attributen Kamer(specialiteit), titel(specialiteit ), faculteit waarvan de typen niet zijn gespecificeerd in dit model, hoewel ze kunnen worden bepaald door middel van opsommingen.

Klas discipline heeft attributen: Kamer, titel, fiets. Attribuut fiets door middel van een gespecialiseerd type geïntroduceerd door middel van een opsomming T_Cycles bepaalt tot welke cyclus het vakgebied behoort: de cyclus van humanitaire en sociaal-economische disciplines, wiskundige en natuurwetenschappelijke disciplines, algemene beroepsdisciplines, bijzondere disciplines.

attributen nummeruur, nummersemesters kan niet worden opgegeven in de klas discipline, aangezien ze afhankelijk zijn van de specialiteit, hoe meer je ze niet kunt aangeven in de klas specialiteit... Deze attributen hebben betrekking op het specialiteit-disciplinepaar en zijn gedefinieerd in de klasse - associatie Disciplines-specialiteiten.

Rijst. 3. Klassenschema van de AWP van het secretariaat van de afdeling (optie 1)

Let bij het renderen van een klassenstructuur op de zichtbaarheid van de attributen. Alle beschouwde kenmerken moeten beschikbaar zijn en de zichtbaarheid Openbaar hebben (aangegeven door een "+"-teken of een pictogram zonder hangslot). In de beschouwde klassen hebben we ons meer gericht op structuur dan op gedrag (bewerkingen werden niet beschreven en mogen ook niet worden beschreven), daarom is het wenselijk om de bewerkingen te onderdrukken om het diagram leesbaarder te maken.

Op de geïntroduceerde reeks klassen is het noodzakelijk om de koppelingen opnieuw te definiëren. De verbanden van generalisatie en afhankelijkheden zijn al bepaald, het blijft om de associaties te definiëren.

studenten gevormd in groep, in dit geval zal de associatie de vorm hebben van een aggregatie. Aggregatie gaat uit van een deel-geheel-relatie, aangegeven door een ononderbroken lijn met een ruit aan het einde van de hele zijde (in ons geval groep). De veelheid van veel-op-een student-groep relaties. Elk groep verwijst naar een specifieke specialiteit, op hun beurt kunnen meerdere groepen overeenkomen met een bepaalde specialiteit, daarom heeft de groep-specialiteitsvereniging ook het type multipliciteit "veel op één".

In dit geval, zoals in de meeste andere, is de richting van associaties in twee richtingen, dus het is beter om navigatie te onderdrukken (deselecteer het veld Navigeerbaar van de optie Detailrol)

Laten we een associatie definiëren tussen leraren en onderwezen disciplines als "many-to-many": een leraar kan meerdere disciplines doceren, sommige disciplines kunnen door meerdere docenten worden gegeven. Tussen disciplines en specialiteiten de vereniging "many-to-many" is ook opgericht: het curriculum van specialiteiten bevat veel disciplines, de meeste disciplines zijn te vinden in de werkplannen van verschillende specialiteiten. Aan deze vereniging is de verenigingsklasse verbonden. Disciplines-specialiteiten met attributen die de cursus, het aantal semesters en het aantal uren van een bepaalde discipline in een bepaalde specialiteit aangeven.

Evenzo introduceren we een verband tussen in groepen en leraren: Docenten geven les in groepen, multi-to-many associatietype. Directe associatie tussen in groepen en disciplins u hoeft niet te definiëren, omdat deze relatie wordt getraceerd via de binderklasse specialiteit.

Om de aanwezigheid van een begeleider voor een afgestudeerde student aan te tonen, is het noodzakelijk om een ​​verband te introduceren tussen een afgestudeerde student en een leraar van het "veel-op-een"-type; één begeleider kan meerdere afgestudeerde studenten hebben. Op deze associatie van de kant van de leraar kun je expliciet de rol aangeven: leidinggevende.

Rijst. 4. Schema van klassen AWP van de secretaris van de afdeling (optie 2)

In elke groepene er is een groepsleider, dit feit kan worden weergegeven door een extra associatie (laten we het een naam geven) hoofdman) van groep naar leerlingen met het type multipliciteit "één op één". In dit geval kunt u de navigatie expliciet specificeren.

Postacademische studenten kan ook specifieke disciplines onderwijzen aan specifieke groepen: veel-op-veel verenigingen postdoctorale groepen, postdoctorale disciplines. Sommige afgestudeerde studenten geven misschien geen les, dus het multipliciteitstype aan de uiteinden van de associatie is 0. n.

Het definitieve klassendiagram wordt getoond in Fig. 3.

Rijst. 5. Vereenvoudigd klassendiagram

Aangezien zowel afgestudeerde studenten als docenten lessen geven, kan een extra abstracte klas worden geïntroduceerd, bijvoorbeeld onderwijs die een afstammeling is van de klasse een persoon en een superklas voor de lessen docent en afgestudeerde student, wat het aantal verbindingen enigszins zal verminderen. (afb. 4.). In dit geval uit de lessen discipline en groep verenigingen gaan naar de les onderwijs, uitgaande van een link naar de lessen docent en afgestudeerde student via overerving (generaliseringsrelatie). naar de klas onderwijs je kunt de attributen eruit halen bod(0,5 tarief, vol tarief) en afvoer.

Het resulterende diagram is behoorlijk complex en vol met elementen, maar de modellering van de klassen is verre van compleet: sommige hulpprogrammaklassen en interfaces moeten nog worden gedefinieerd. Om het klassendiagram te verwijderen, zullen we er een nieuwe weergave van maken (op een apart diagram), waarbij we de afbeelding van de hoofdklassen laten en de weergave van hulpklassen die de typen attributen bepalen, onderdrukken (Fig. 5).

In afb. 5, samen met de hoofdklassen die overeenkomen met de conceptuele elementen van het systeem, wordt de klasse ook getoond t_ ADR, die de structuur van het adres onthult, is deze klasse ook belangrijk, omdat deze de nodige gegevenselementen bevat voor: leraren en afgestudeerde studenten- afstammelingen van de klas een persoon.

Laten we verder gaan met het definiëren van de interfaces. Klassen communiceren met de buitenwereld via interfaces.

Koppel (Interface) is een verzameling bewerkingen die een service (set services) definiëren die door een klasse of component wordt geleverd. Een interface beschrijft dus het extern zichtbare gedrag van een element. Een interface kan het gedrag van een klasse of component geheel of gedeeltelijk weergeven; het definieert alleen de specificaties van de operaties (handtekeningen), maar nooit hun implementatie. De grafische interface wordt weergegeven als een cirkel, waaronder zijn naam is geschreven. Een interface bestaat zelden op zichzelf - deze is meestal gekoppeld aan een implementerende klasse of component. De interface veronderstelt altijd het bestaan ​​van een soort "contract" tussen de partij die de uitvoering van een aantal bewerkingen aangeeft en de partij die deze bewerkingen uitvoert.

Plaats de klasse op het diagram elektronischtafel, die alle eigenschappen en bewerkingen van de spreadsheet omvat waarmee u de gegevens kunt bewerken. We zullen de structuur van deze klasse niet onthullen vanwege de grote complexiteit. Dus in moderne tools voor applicatieontwikkeling gebruikt de gebruiker kant-en-klare klassen en sjablonen, waarbij hij hun mogelijkheden erft. De VCL-bibliotheek (Delphi) bevat bijvoorbeeld een TTable-klasse die de mogelijkheden van een spreadsheet omvat. Afstammelingen van de klas elektronischtafel zijn specifieke spreadsheets met specifieke gegevens voor faculteiten, afgestudeerde studenten, studenten, groepen, disciplines en specialiteiten. Door de corresponderende klassen afstammelingen van de klasse te maken elektronischtafel, we declareren voor deze klassen alle eigenschappen en bewerkingen die inherent zijn aan spreadsheets (registratie in het systeem, invoegen, verwijderen, gegevensbewerking, sortering, enz.).

Voor de les elektronischtafel, en dienovereenkomstig definiëren we voor al zijn nakomelingen de interface bewerken, wat alle mogelijke bewerkingen van gegevens impliceert (gegevens invoegen, verwijderen, wijzigen). In dit geval wordt aangenomen dat in de klas elektronischtafel deze mogelijkheden worden gerealiseerd.

Een aangepaste klasse gebruiken elektronischtafel en overerving vermeed het definiëren van speciale eigenschappen en interfaces voor het bewerken van gegevens voor elke spreadsheet.

Laten we de interfaces definiëren Zoekopdrachtdocent, Zoekopdrachtdisciplines door ze aan hun respectieve klassen te koppelen met een implementatierelatie. We zullen de samenstelling van de bewerkingen van deze interfaces niet onthullen (het is nogal triviaal), daarom zullen we de interfaces in een verkorte vorm weergeven (in de vorm van een cirkel). Bedenk dat een implementatierelatie die in verkorte vorm aan een interface is gekoppeld, wordt weergegeven als een eenvoudige ononderbroken lijn (als een associatie).

Koppel Zoekopdrachtleerling wordt weergegeven met een indicatie van de lijst met bewerkingen via een stereotiepe klasse, terwijl de implementatierelatie wordt weergegeven door een gestippelde pijl met een gesloten punt.

Uiteraard wordt aangenomen dat de geïntroduceerde interfaces worden geïmplementeerd door middel van de klassen waaraan ze zijn gekoppeld door de implementatierelatie, dat wil zeggen dat de overeenkomstige klassen bewerkingen en methoden bevatten die de gedeclareerde interfaces implementeren. Om de waarneming te vergemakkelijken, worden deze mechanismen niet gevisualiseerd.

Om toegangsrechten en gebruikersautorisatie te beheren, introduceren we de klasse managertoegang... De toegangsmanager heeft een attribuut voor het type privétoegang tafelwachtwoorden wat een instantie van de klasse is CodirTabel(Gecodeerde tabel) met wachtwoorden ( wachtwoord) en invoernamen ( Log in) van beheerdersgebruikers. Er wordt aangenomen dat de serviceklasse-mogelijkheden CodirTabel sta niet toe dat een onbevoegde gebruiker gebruikerswachtwoorden leest. In dit stadium van het ontwerp verklaren we dergelijke mogelijkheden eenvoudigweg, zonder stil te staan ​​bij het mechanisme voor hun implementatie, maar ervan uit te gaan dat ze zijn ingekapseld in een klasse CodirTabel.

Klas managertoegang bevat openstaande transacties invoerwachtwoord en het verlenen van beheerdersrechten, waarmee autorisatie en beheer van toegangsrechten wordt gerealiseerd.

Laten we de afhankelijkheid aangeven tussen de interface voor het bewerken van gegevens ( bewerken) en een toegangsmanager, ervan uitgaande dat alleen gebruikers met beheerdersrechten volledige gegevensbewerkingsmogelijkheden hebben.

Rijst. 6. Het definitieve diagram van de klassen van de AWP van de secretaris van de afdeling

Het definitieve diagram wordt getoond in Fig. 6.

In dit stadium kan dus de ontwikkeling van een objectgeoriënteerd model van de werkplek van de secretaresse van de afdeling door middel van het UML-klassendiagram als voltooid worden beschouwd. Uiteraard is het mogelijk om hierop terug te komen en enkele elementen te herzien tijdens het ontwerp van het systeem, bij het aanpassen van taken, bij het specificeren van individuele details. Het ontwerpproces van informatiesystemen is iteratief. Opgemerkt moet worden dat het ontwikkelde klassendiagram elementen bevat die expliciet of impliciet alle use cases van het use case diagram implementeren. Elke use case van een use case-diagram moet overeenkomen met een interface of een interfacebewerking (implementatie wordt verondersteld in de klassen die overeenkomen met de interface), of een openbare bewerking van de klasse, of een reeks openbare bewerkingen (in dit geval, de use case wordt direct geïmplementeerd door de overeenkomstige klasse of reeks klassen).

Laten we eens kijken naar het proces van het maken van een nieuw leerlingrecord met behulp van een volgordediagram.

Het maken van een nieuw record veronderstelt beheerdersrechten, dus de beheerder zal de hoofdrolspeler zijn in deze interactie ( beheerder). Dit element is al ingevoerd in het use case diagram, dus sleep het vanuit de use case view browser naar het sequence diagram.

Opgemerkt moet worden dat objecten verschijnen in interactiediagrammen, dat wil zeggen concrete instanties van klassen (de naam van een object is altijd onderstreept).

Wij beheren objecten: formulierinvoer, managerrecords, studentenrecord Petrov(als concreet voorbeeld van een studentenrecord), managertransacties... Deze set objecten is typisch voor het wijzigen van een record in een databasetabel.

Formulierinvoer- een element van de gebruikersinterface, een typisch formulier voor het invoeren van gegevens over een student (achternaam, voornaam, patroniem, adres, enz.). In ons geval is het een wat uitgebreidere concrete implementatie van de standaardinterface bewerken klas elektronischtafel. Aangezien we de interface voor het bewerken van leerlinggegevens in het klassendiagram niet specifiek hebben geïntroduceerd, specificeer daarom expliciet de klasse voor het object formulierinvoer we zullen niet.

Managerrecords- een object dat een standaard set gegevensbeheermogelijkheden heeft bij het werken met een spreadsheet. Deze set mogelijkheden wordt overgenomen door de klasse studenten uit de klas elektronischtafel... Voor object Managerrecords de klasse waarvan het een instantie is, wordt expliciet aangegeven - studenten.

Petrov- een specifiek record over student Petrov, een nieuw element van de tabel over studenten. Hier geven we expliciet de geïntroduceerde klasse aan opnameOleerling... Dergelijke objecten bestaan ​​meestal tijdelijk om tijdens transacties relevante informatie naar de database te sturen. Na afloop van de transactie kan dit object worden vernietigd. Het object dat overeenkomt met het record kan opnieuw worden gemaakt als het nodig is om de informatie te bewerken.

Managertransacties- een object dat zorgt voor de uitvoering van een voltooide bewerking op de database, in dit geval het aanmaken van een nieuw record over student Petrov. Dit object is ook verantwoordelijk voor het uitvoeren van een aantal systeemfuncties die bij de transactie horen. Voorbeelden van transactiemanagers zijn bijvoorbeeld BDE (gebruikt om toegang te krijgen tot Paradox, Dbase, etc. databases vanuit Delphi-applicaties), ADO (gebruikt om toegang te krijgen tot MS Access-databases vanuit verschillende applicaties).

Het volgordediagram voor het invoeren van een nieuw record over een student in de AWS van het afdelingssecretariaat wordt getoond in Fig. 7.

Rijst. 7. Invoeren leerlinggegevens. Volgorde diagram.

In het sequentiediagram definiëren we de overdracht van berichten tussen objecten: creërennieuweopname(uitgezonden van object naar object naar het einde van de keten als een bericht) sparenopname); openvorm geven aan(naar het invulformulier); introducerenF.EN OVER.,het adres. ( invoer van leerlinggegevens), dan worden deze gegevens via berichten uitgezonden sparenF.EN OVER.,het adres. Van managertransacties stuur bericht verzamelen informatieOleerling feedback geven aan de database, en tot slot een reflexief bericht managertransacties benoemd als sparenopnamevDB, zorgt voor het einde van de transactie.

Desgewenst kan deze interactie worden weergegeven door een samenwerkingsdiagram dat allereerst het structurele aspect van de interactie illustreert (Fig. 8). Dit diagram kan worden opgebouwd uit het vorige in de automatische modus (in Rational Rose door op de F5-toets te drukken).

Rijst. 8. Invoeren leerlinggegevens. Samenwerkingsdiagram.

Indien nodig kan het project worden aangevuld met andere interactiediagrammen die het werk van use cases onthullen.

4.3 Een relationeel databaseprofiel ontwikkelen

In het geval dat een objectgeoriënteerd DBMS (OODBMS) wordt gebruikt om het systeem te implementeren, is het objectdiagram dat in de vorige sectie is geconstrueerd het uiteindelijke model en een directe gids voor de implementatie van het informatiesysteem. In hetzelfde geval, wanneer een relationele database (RDB) zou moeten worden gebruikt als de informatiekern van een informatiesysteem, is het nodig om een ​​ander diagram te ontwikkelen, een profieldiagram van een relationele database.

Het UML-profiel voor een databaseproject is een UML-extensie die het UML-metamodel intact houdt. Het profiel voor een databaseproject voegt stereotypen en getagde waarden toe aan deze stereotypen, maar verandert niets aan het onderliggende UML-metamodel. Om de ontworpen database-elementen en ontwerpregels voor relationele databases te visualiseren, zijn de bijbehorende pictogrammen aan het profiel toegevoegd (hierna simpelweg databases). De database wordt beschreven aan de hand van tabellen, kolommen en relaties. Het profiel bevat elementen die de database uitbreiden, zoals triggers, opgeslagen procedures, beperkingen, door de gebruiker gedefinieerde typen (domeinen), weergaven en andere. Het profiel laat zien hoe en waar al deze elementen in het model gebruikt kunnen worden. De volgende entiteiten zijn gedefinieerd in het UML-databaseprofiel:

tafel ( Tabel) - een set records in de database voor een specifiek object, bestaat uit kolommen.

Kolom ( Column) is een tabelcomponent die een van de tabelattributen (tabelveld) bevat.

primair sleutel ( Primaire sleutel) - een mogelijke sleutel die is gekozen om tabelrijen te identificeren.

extern sleutel ( Foreign key) - een of meer kolommen van een tabel, die de primaire sleutels zijn van een andere tabel.

Vertegenwoordiging ( View) is een virtuele tabel die zich vanuit het oogpunt van de gebruiker precies als een gewone tabel gedraagt, maar niet op zichzelf bestaat.

Opgeslagen procedure ( Opgeslagen procedure) is een onafhankelijke procedurele functie die op de server wordt uitgevoerd.

Domeinen ( Domains) is een geldige set waarden voor een attribuut of kolom.

Naast deze entiteiten kunnen enkele aanvullende entiteiten worden geïntroduceerd die specifieke aspecten van het databasemodel weerspiegelen.

Vergelijkbare documenten

Methodologieën voor de ontwikkeling van informatiesystemen in binnen- en buitenlandse literatuur. Staats- en internationale standaarden op het gebied van softwareontwikkeling. Ontwikkeling van een fragment van het educatief-methodisch resource-informatiesysteem.

scriptie, toegevoegd 28-05-2009


Definitie van het begrip "systeem". De geschiedenis van ontwikkeling en kenmerken van moderne informatiesystemen. De belangrijkste fasen van de ontwikkeling van een geautomatiseerd informatiesysteem. Gebruik van nationale en internationale standaarden op het gebied van informatiesystemen.

presentatie toegevoegd op 14-10-2013


Het belangrijkste idee van de methodologie en principes van RAD-ontwikkeling van informatiesystemen, de belangrijkste voordelen ervan. Redenen voor de populariteit, kenmerken van de technologietoepassing. Formulering van de basisprincipes van ontwikkeling. Ontwikkelomgevingen met behulp van RAD-principes.

presentatie toegevoegd op 04/02/2013


De rol van de managementstructuur in het informatiesysteem. Voorbeelden van informatiesystemen. Structuur en classificatie van informatiesystemen. Informatie Technologie. Stadia van de ontwikkeling van informatietechnologie. Soorten informatietechnologie.

scriptie toegevoegd 17-06-2003


Het concept van CASE-tools als softwaretools die het creëren en onderhouden van informatiesystemen (IS) ondersteunen. Kenmerken van IDEF-technologie van IS-ontwikkeling. Beschrijving van IDEF0-notatie. Ontwikkeling van functionele modellen van een bedrijfsproces.

presentatie toegevoegd op 04/07/2013


De essentie van de uniforme modelleertaal, het conceptuele model en werkingsprincipe, algemene regels en mechanismen. Modelleren van het concept van "competentie". Klassendiagram dat het onderwijsproces beschrijft. Implementatie van een bepaald informatiesysteem.

proefschrift, toegevoegd 17-02-2015


Ontwikkeling van informatiesystemen. De moderne markt voor financieel-economische toegepaste software. Voor- en nadelen van het implementeren van geautomatiseerde informatiesystemen. Methoden voor het ontwerpen van geautomatiseerde informatiesystemen.

proefschrift, toegevoegd 22-11-2015


Het concept van een informatiesysteem, soorten informatiesystemen. Analyse van tools voor de ontwikkeling van geautomatiseerde informatiesystemen. Vereisten voor het programma en het softwareproduct. Ontwikkeling van vormen van grafische interface en databases.

proefschrift, toegevoegd 23-06-2015


Oplossing voor informatiebeveiliging. Systemen voor datacenters. Wat is datacenterhardware. Basisconcepten en principes van modellering. De keuze van een methode om problemen op te lossen. Zoitendijk methode van toelaatbare richtingen, Frank – Wolfe algoritme.

scriptie toegevoegd 18-05-2017


Informatie systeemconcept. Stadia van ontwikkeling van informatiesystemen. Processen in het informatiesysteem. Informatiesysteem voor het vinden van marktniches, voor het verlagen van productiekosten. De structuur van het informatiesysteem. Technische hulp.

MINISTERIE VAN ONDERWIJS VAN DE RUSSISCHE FEDERATIE ULYANOVSK STAAT TECHNISCHE UNIVERSITEIT V.S. SCHKLEIN MODELLEN VAN INFORMATIESYSTEMEN Collegenota's voor studenten van richting 652100 "Vliegtuigbouw" de Universiteit van Shcheklein V.S. Щ Modellering van informatiesystemen: dictaten / V.S. SHCHEKLEIN. - Ulyanovsk: UlSTU, 2002 .-- p. De dictaten zijn een selectie van materiaal dat in het studiejaar 1999/2000 is gebruikt bij het geven van lessen in het vakgebied "Information Systems Modeling". Het is bedoeld voor studenten van specialisaties: 130107 "Softwareverwerking van constructiematerialen" en 130111 "Projectmanagement van vliegtuigproductie". Deze handleiding is niet volledig, het is de bedoeling om nieuw ontwikkeld materiaal op te nemen, waarvan de selectie en het ontwerp worden uitgevoerd in overeenstemming met het goedgekeurde disciplineprogramma. 3 INHOUD INLEIDING …………………………………………… .. DE IMPLEMENTATIE MET BEHULP VAN EEN COMPUTER …………… 7 3. ALGEMENE STATISTISCHE MODELLERINGSALGORITHMEN ……………………… ……………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………… …………………… 9 DISTRIBUTIE. SIMULATIE VAN WILLEKEURIGE GEBEURTENISSEN ……………………………………………… .. 5. AANPAK VAN DE SIMULATIE VAN SYSTEMEN …………………… ... 15 6. INSTELLEN VAN WILLEKEURIGE WAARDEN EN WILLEKEURIGE GEBEURTENISSEN IN EXCEL ...................... 23 8. MODELLEN VAN MASSASERVICESYSTEMEN. 25 9. Structuur van informatie en computersystemen systematische TEM ................................................ ................................................. 26 9.1. Het concept van het proces …………………… ………………………… .. 28 9.2. Werklast …………………………………………………… 29 10. INFORMATIESYSTEEM PRESTATIE-INDICATOREN …………………………………………………………… ……… .. 30 11. SCHATTING VAN DE PRESTATIES VAN SYSTEEMCOMPONENTEN …………………………………………………………….…. 31 12. BEOORDELING VAN DE PRESTATIES VAN HET SYSTEEM IN HET ALGEMEEN ……. 32 13. DE INVLOED VAN DE GEGEVENSVERWERKINGSMODUS ………………… .. 35 14. BETROUWBAARHEIDSKENMERKEN ………………………………………………………………… ……………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………… .. … ……………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………… …………………………………………………………………………………. ” ……………. 40 REFERENTIES …………………………………. 46 4 INLEIDING Het nut van wiskundige modellering voor het oplossen van praktische problemen roept geen enkele twijfel op. De vraag kan rijzen, waarom is het nodig om het modelleren van informatiesystemen onder de knie te krijgen (en deze systemen zijn nu niet meer voorstelbaar zonder computertechnologie) voor vliegtuigbouwers die zich richten op de technologie van vliegtuigproductie? Moderne technologie wordt steeds meer geautomatiseerd. Een moderne vliegtuigbouwer, of hij nu een ontwerper of een technoloog is, moet computers gebruiken in zijn werk. Het gevaar bestaat dat de capaciteiten van de computer onvoldoende worden beoordeeld bij het oplossen van technische problemen. Dit kan leiden tot een weigering om een ​​of ander fragment van het technologische proces te automatiseren, of tot ongerechtvaardigde uitgaven voor computerapparatuur, waarvan de mogelijkheden sterk worden overschat in vergelijking met de noodzakelijke. In dit geval kan het zogenaamde gezond verstand leiden tot ernstige fouten in de beoordeling. Het doel van de discipline is om een ​​jonge specialist uit te rusten met een apparaat voor het evalueren van informatie- en computersystemen, zodat hij automatiseringsmiddelen correct kan inpassen in de contouren van productie of beheer. Bovendien doen studenten door het modelleren van bepaalde systemen indirecte ervaring op met het optimaliseren van systemen en versterken ze de vaardigheden van het gebruik van een computer bij het oplossen van professionele problemen. 1. BASISBEGRIPPEN VAN DE THEORIE VAN HET MODELLEN Modelleren is het vervangen van het ene object door het andere om informatie te verkrijgen over de belangrijkste eigenschappen van het object - het origineel met behulp van het object - het model. Model (Frans modele uit het Latijn modulas - maat, monster): 1) een monster voor massaproductie van een product; product merk; 2) het product waaruit de vorm is verwijderd (sjablonen, patronen, pleinen); 3) de persoon of het object afgebeeld door de kunstenaar; 4) een apparaat dat de structuur of werking van een ander apparaat reproduceert; 5) elke afbeelding van een object, proces of fenomeen dat wordt gebruikt als een vertegenwoordiger van het origineel (afbeelding, diagram, tekening, kaart); 6) het wiskundige apparaat dat een object, proces of fenomeen beschrijft; 7) een inrichting voor het maken van een afdruk in een gietvorm. In wat volgt, zal het model, tenzij anders vermeld, worden opgevat als een wiskundig apparaat. Alle modellen hebben een bepaalde structuur (statisch of dynamisch, materieel of ideaal), die lijkt op de structuur van het oorspronkelijke object. Tijdens het werk fungeert het model als een relatief onafhankelijk quasi-object, wat het mogelijk maakt om tijdens het onderzoek enige kennis over het object zelf te verkrijgen. Als de resultaten van een dergelijk onderzoek (modellering) worden bevestigd en als basis kunnen dienen voor voorspellingen in de bestudeerde objecten, dan zeggen ze dat het model geschikt is voor het object. In dit geval hangt de geschiktheid van het model af van het doel van de modellering en de gehanteerde criteria. Het modelleringsproces veronderstelt de aanwezigheid van: - het onderzoeksobject; - een onderzoeker met een specifieke taak; - een model dat is gemaakt om informatie te verkrijgen over een object dat nodig is om een ​​probleem op te lossen. In relatie tot het model is de onderzoeker de experimentator. Houd er rekening mee dat elk experiment alleen van groot belang kan zijn op een specifiek gebied van wetenschap en technologie met een speciale verwerking van de resultaten. Een van de belangrijkste aspecten van systeemmodellering is het doelprobleem. Elk model wordt gebouwd afhankelijk van het doel dat door de onderzoeker is gesteld, daarom is een van de belangrijkste problemen bij het modelleren het doeltoewijzingsprobleem. De gelijkenis van het proces dat in het model verloopt met het werkelijke proces is geen doel op zich, maar een voorwaarde voor het correct functioneren van het model. Als doel moet de taak worden gesteld om elk aspect van het functioneren van het object te bestuderen. Als de doelen van modellering duidelijk zijn, doet zich het volgende probleem voor, het probleem van het bouwen van een model. Deze constructie blijkt mogelijk te zijn als er informatie is of hypothesen worden geopperd over de structuur, algoritmen en parameters van het onderzochte object. Het moet worden benadrukt de rol van de onderzoeker in het proces van het bouwen van een model, dit proces is creatief, gebaseerd op kennis, ervaring, heuristiek. Formele methoden die een voldoende nauwkeurige beschrijving van een systeem of proces mogelijk maken, zijn onvolledig of ontbreken simpelweg. Daarom is de keuze voor deze of gene analogie volledig gebaseerd op de ervaring van de onderzoeker, en de fouten van de onderzoeker kunnen leiden tot foutieve simulatieresultaten. Wanneer het model is gebouwd, kan het volgende probleem worden beschouwd als het probleem om ermee te werken, de implementatie van het model. Hier zijn de belangrijkste taken het minimaliseren van de tijd om de definitieve resultaten te verkrijgen en de betrouwbaarheid ervan te waarborgen. Voor een correct geconstrueerd model is het kenmerkend dat het alleen die regelmatigheden onthult die de onderzoeker nodig heeft, en geen rekening houdt met de eigenschappen van het systeem - het origineel, die op het gegeven moment onbelangrijk zijn. De classificatie van soorten systeemmodellering wordt getoond in Fig. 1.1. Wiskundige modellering is de constructie en het gebruik van wiskundige modellen om het gedrag van systemen (objecten) in verschillende omstandigheden te bestuderen, om bepaalde kenmerken van het origineel te verkrijgen (berekenen) zonder metingen of met een klein aantal ervan. In het kader van wiskundige modellering zijn twee benaderingen ontwikkeld: - analytisch; - imitatie. 6 Systeemmodellering Deterministisch Stochastisch Statisch Dynamisch Discreet Discreet Continu Abstract Materiaal Visueel Symbolisch Wiskundig Natuurlijk Fysisch Analytisch Gecombineerd. Simulatie Afb. 1.1. De analytische benadering is gebaseerd op de constructie van formule-afhankelijkheden die de parameters en elementen van het systeem met elkaar verbinden. Lange tijd was deze benadering eigenlijk een wiskundige benadering. Bij het overwegen van complexe systemen zijn strikte wiskundige afhankelijkheden echter zeer complex; er is een groot aantal metingen vereist om de vereiste waarden van de parameters te verkrijgen. Analyse van de kenmerken van de werkingsprocessen van complexe systemen waarbij alleen analytische onderzoeksmethoden worden gebruikt, stuit op aanzienlijke problemen, wat leidt tot de noodzaak van een aanzienlijke vereenvoudiging van modellen, hetzij in de fase van hun constructie, hetzij tijdens het werken met een model, dat vermindert de betrouwbaarheid van de resultaten. De simulatie (statistische) benadering van modellering is gebaseerd op het gebruik van de limietstelling van Chebyshev in de probabilistische representatie van de systeemparameters. Op basis van een voorstudie van het gemodelleerde systeem is het vrij eenvoudig om de soorten en waarden van de verdelingswetten te bepalen voor de willekeurige waarden van de parameters. In het kader van de simulatiebenadering worden analytische afhankelijkheden tussen de parameters van de systeemelementen gebruikt, maar deze afhankelijkheden zijn van een meer algemene, vereenvoudigde aard. Ze zijn veel eenvoudiger dan afhankelijkheden in de analytische benadering. 7 Wiskundige modellering van systemen, waaronder informatiesystemen, is gericht op het optimaliseren van de structuur van systemen, het kiezen van de meest optimale werkingsmodi van systemen, het bepalen van de vereiste kenmerken van hardware en software. Wiskundige modellering van technologische processen, inclusief informatieprocessen, heeft als hoofddoelen het vinden van de optimale of acceptabele kenmerken van het object zelf, het vinden van optimale verwerkingsmodi, het opleiden van personeel en het verschaffen van bepaalde besturingsfuncties. De modellering moet in ieder geval aan de volgende eisen voldoen: - de modellen moeten geschikt zijn voor de bijbehorende systemen of technologische taken; - de vereiste nauwkeurigheid moet worden gewaarborgd; - het gemak van de gebruiker - een specialist in technologie of informatieverwerking (beheer) moet worden verzekerd: - een begrijpelijke interface voor modelleringsbeheer; - voldoende snelheid van werken; - zichtbaarheid van de resultaten; - aanvaardbare kosten voor ontwikkeling en gebruik van simulatietools. 2. ESSENTIE VAN DE METHODE VAN DE STATISTISCHE TESTEN EN DE UITVOERING DAARVAN MET DE HULP VAN EEN COMPUTER De methode van statistische modellering bestaat uit het reproduceren van het bestudeerde proces met behulp van een probabilistisch wiskundig model en het berekenen van de kenmerken van dit proces. De methode is gebaseerd op herhaald testen van het geconstrueerde model met daaropvolgende statistische verwerking van de verkregen gegevens om de kenmerken van het betreffende proces te bepalen in de vorm van statistische schattingen van zijn parameters. Beschouw de vergelijking: y = f (x, t, ξ), (2.1) waarbij y een te bepalen systeemparameter is, x een fasevariabele is, t tijd is, ξ een willekeurige parameter is, waarvan de verdelingswet is bij ons bekend. Als de functie f in wezen niet-lineair is, dan zijn er geen universele oplossingsmethoden om dit probleem op te lossen, en voldoende volledig ontwikkelde reguliere methoden voor het vinden van optimale oplossingen kunnen alleen worden toegepast door de zichtbaarheid van het gebruik van wiskunde op de voorgrond te plaatsen; vereenvoudigingen zullen leiden tot een ernstig verlies van nauwkeurigheid. Het wiskundige model zal niet meer voldoen aan het systeem dat wordt bestudeerd, en modellering zal slechts een vorm van waanvoorstelling zijn. Als het echter mogelijk is om een ​​functie y = ϕ (ξ) en een generator van willekeurige getallen ξ 1, ξ 2, ..., ξ N te construeren met een gegeven verdelingswet, dan kan de waarde van y worden berekend als y = ∑ ϕ (ξ i) N, (2.2) waarbij ϕ (ξ 1) de waarde is van de i-de realisatie. Als f (x, t, ξ) een analytisch model is van het informatietransformatieproces of het technologische proces van het verwerken van een onderdeel, dan is ϕ (ξ) een statistisch model. Enkele principes en technieken voor het construeren van statistische modellen zullen later worden besproken. Het is belangrijk dat bij het construeren van de functie y = ϕ (ξ) en de generator van willekeurige getallen ξ 1, ξ 2, ..., ξ N op papier, het in de overgrote meerderheid van de gevallen vrij eenvoudig is om ze op een computer met de juiste software. In dit geval zullen de resultaten een fout bevatten, maar deze fout is kleiner dan fouten als gevolg van aannames in het analytische model. Daarnaast kan de fout door toepassing van het statistische model worden gekwantificeerd. Deze techniek wordt uitgebreid naar meer gecompliceerde gevallen, wanneer vergelijking (2.1) niet alleen willekeurige parameters bevat, maar ook willekeurige functies. Na ontvangst van N realisaties op een computer, volgt de fase van het verwerken van statistieken, waarmee, samen met de wiskundige verwachting (2.2), andere parameters ϕ (ξ) kunnen worden berekend, bijvoorbeeld de variantie D = 1 N * ∑ xi - 1 N 2 * (∑xi). In de methode van statistische tests is het, om voldoende betrouwbare resultaten te verkrijgen, noodzakelijk om een ​​groot aantal realisaties N te bieden, bovendien is het, met een verandering in ten minste één initiële parameter van het probleem, noodzakelijk om een ​​reeks uit te voeren van N-tests opnieuw. Bij complexe modellen kan een onterecht grote waarde van N een factor worden die de ontvangst van het resultaat vertraagt. Daarom is het belangrijk om het benodigde aantal resultaten correct in te schatten. Betrouwbaarheidsinterval ε, betrouwbaarheidskans α, variantie D en het aantal realisaties N zijn gerelateerd aan de relatie ε = D NФ −1 (α), waarbij Ф −1 (α) de inverse functie is van de Laplace-functie. In de praktijk kun je de verhouding N ≤ D ε 2 * 6,76 voor α ≥ 0,99 gebruiken, waarbij je voor de betrouwbaarheid de grootste waarde van N uit de verhouding () neemt. Een schatting van de variantie D kan vooraf worden verkregen met hetzelfde statistische model voor het aantal realisaties n, n<< N . 9 При построении статистических моделей информационных систем ис- пользуется общий и прикладной математический аппарат. В качестве приме- ра можно привести аппарат систем массового обслуживания. Система массо- вого обслуживания (СМО) - система, предназначенная для выполнения пото- ка однотипных требований случайного характера. Статистическое моделиро- вание СМО заключается в многократном воспроизведении исследуемого процесса (технического, социального и т.д.) при помощи вероятностной ма- тематической модели и соответствующей обработке получаемой при этом статистики. Существуют пакеты программ статистического моделирования СМО, однако они требуют определенных усилий для их освоения и не всегда доступны. Поэтому в рамках дисциплины предлагается достаточно простой подход, позволяющий с наименьшими затратами моделировать простые СМО. При этом предполагается, что пользователь ознакомлен с теорией мас- сового обслуживания и имеет навыки работы на компьютере. Следует пом- нить, что массовое обслуживание - важный, но далеко не единственный предмет статистического моделирования. На основе этого метода решаются, например, задачи физики (ядерной, твердого тела, термодинамики), задачи оптимизации маршрутов, моделирования игр и т.п. 3. ОБОБЩЕННЫЕ АЛГОРИТМЫ СТАТИСТИЧЕСКОГО МОДЕЛИРОВАНИЯ Существуют две схемы статистического моделирования: - моделирование по принципу особых состояний; - моделирование по принципу ∧ t . Порядок моделирования по принципу особых состояний заключается в выполнении следующих действий: 1) случайным образом определяется событие с минимальным временем - бо- лее раннее событие; 2) модельному времени присваивается значение времени наступления наибо- лее раннего события; 3) определяется тип наступившего события; 4) в зависимости от типа наступившего события осуществляется выполнение тех или иных блоков математической модели; 5) перечисленные действия повторяются до истечения времени моделирова- ния. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования хо- рошо подходит для систем массового обслуживания в традиционном их опи- сании. Обобщенный алгоритм моделирования по принципу особых состоя- ний представлен схемой на рис. 3.1. 10 н Определение времени наступления очередного события Корректировка текущего модельного времени Опр.типа соб Блок реакции 1 Блок реакции К нет Конец модел Да Рис. к Моделирование по принципу ∧ t осуществляется следующим образом: 1) устанавливаются начальные состояния, в т. ч. t = 0 ; 2) модельному времени дается приращение t = t + ∧t ; 3) на основе вектора текущих состояний элементов модели и нового значения времени рассчитываются новые значения этих состояний; за ∧ t может на- ступить одно событие, несколько событий или же может вообще не проис- ходить событий; пересчет состояния всех элементов системы – более тру- доемкая процедура, нежели любой из блоков реакции модели, построенной по принципу особых состояний; 4) если не превышено граничное время моделирования, предыдущие пункты повторяются. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования применима для более широкого круга систем, нежели моделирование по принципу особых событий, однако есть проблемы с определением ∧ t . Если задать его слишком большим - теряется точность, слишком малым - возрас- тает время моделирования. На основе базовых схем моделирования можно строить комбинирован- ные и диалоговые схемы, в которых моделирование идет под контролем опе-

"Computer wiskundige modellering" Doelstellingen van het bestuderen van de sectie. Modellering beheersen als een methode om de omringende realiteit te herkennen (wetenschappelijk onderzoekskarakter van de sectie) - het is aangetoond dat modellering op verschillende kennisgebieden vergelijkbare kenmerken heeft, vaak is het voor verschillende processen mogelijk om zeer vergelijkbare modellen te verkrijgen; - demonstreert de voor- en nadelen van een computerexperiment in vergelijking met een experiment op ware grootte; - er wordt aangetoond dat zowel het abstracte model als de computer de mogelijkheid bieden om de omringende wereld te kennen, te beheersen in het belang van de mens. Ontwikkeling van praktische vaardigheden in computermodellering. De algemene methodologie van computer wiskundige modellering wordt gegeven. Naar het voorbeeld van een aantal modellen uit verschillende wetenschaps- en praktijkgebieden, worden praktisch alle stadia van modellering geïmplementeerd, van het formuleren van het probleem tot de interpretatie van de resultaten die zijn verkregen in de loop van een computerexperiment. Beroepsbegeleiding van studenten bevorderen. Het onthullen van de aanleg van de student voor onderzoeksactiviteiten, de ontwikkeling van creatief potentieel, oriëntatie op de keuze van een beroep dat verband houdt met wetenschappelijk onderzoek. Het overwinnen van dissociatie van onderwerpen, kennisintegratie. De cursus onderzoekt modellen uit verschillende wetenschapsgebieden met behulp van wiskunde. Ontwikkeling en professionalisering van computervaardigheden. Mastering software voor algemene en gespecialiseerde doeleinden, programmeersystemen.

Taken en functies van het informatiesysteem.

IS kan twee groepen problemen oplossen. De eerste groep wordt geassocieerd met puur informatieve ondersteuning van de hoofdactiviteit (selectie van de nodige berichten, hun verwerking, opslag, zoeken en bezorgen aan het onderwerp van de hoofdactiviteit met een vooraf bepaalde volledigheid, nauwkeurigheid en efficiëntie in de meest acceptabele vorm). De tweede groep taken houdt verband met de verwerking van de ontvangen informatie / gegevens in overeenstemming met bepaalde algoritmen om oplossingen voor te bereiden voor de taken waarmee het onderwerp van de hoofdactiviteit wordt geconfronteerd. Om dergelijke problemen op te lossen, moet de IS over de nodige informatie over het vakgebied beschikken. Om dergelijke problemen op te lossen, moet de IS een bepaalde kunstmatige of natuurlijke intelligentie hebben. Informatiesysteem - een systeem voor het ondersteunen en automatiseren van intellectueel werk - zoeken, administratie, expertise en deskundige beoordelingen of oordelen, besluitvorming, beheer, erkenning, kennisopbouw, training. De taken van de eerste groep zijn de taken van de informatisering van de samenleving "in de breedte".

Taken van de tweede groep - taken van informatisering

samenleving "diep".

Om de toegewezen taken op te lossen, moet de IS de volgende functies uitvoeren:

 selectie van berichten uit de interne en externe omgeving, noodzakelijk voor de uitvoering van de hoofdactiviteit;

 invoer van informatie in IS;

 informatie opslaan in het geheugen van de IS, deze bijwerken en de integriteit ervan behouden;

 het verwerken, zoeken en verstrekken van informatie conform de eisen die de ODS stelt. Verwerking kan ook het voorbereiden van opties omvatten voor het oplossen van door de gebruiker toegepaste problemen.

Informatiesysteem (IS) is een onderling verbonden set tools, methoden en personeel die wordt gebruikt voor het opslaan, verwerken en verstrekken van informatie om het gestelde doel te bereiken. Het moderne begrip van het informatiesysteem omvat het gebruik van een personal computer als het belangrijkste technische middel voor informatieverwerking. Een IS is een omgeving waarvan de samenstellende elementen computers, computernetwerken, softwareproducten, databases, mensen, verschillende soorten technische en softwarecommunicatie, enz. zijn. Hoewel het idee van IP en enkele principes van hun organisatie lang vóór de komst van computers ontstonden, verhoogde automatisering de efficiëntie van IP met tientallen en honderden keren en breidde het toepassingsgebied ervan uit.

De functionele structuur van het informatiesysteem.

In IS is het raadzaam om drie onafhankelijke functionele subsystemen te onderscheiden.

Informatie selectie subsysteem. Het informatiesysteem kan alleen de informatie die erin wordt ingevoerd verwerken/verwerken. De kwaliteit van IS-werk wordt niet alleen bepaald door het vermogen om de benodigde informatie in zijn eigen array te vinden, te verwerken en aan de gebruiker te verstrekken, maar ook door het vermogen om relevante informatie uit de externe omgeving te selecteren. Een dergelijke selectie wordt uitgevoerd door het informatieselectie-subsysteem, dat gegevens verzamelt over de informatiebehoeften van IS-gebruikers (intern en extern), deze gegevens analyseert en ordent, waardoor een IS-informatieprofiel wordt gevormd.

Het subsysteem voor invoer, verwerking/verwerking en opslag van informatie transformeert invoerinformatie en verzoeken, organiseert hun opslag en verwerking om te voldoen aan de informatiebehoeften van IS-abonnees.

De implementatie van de functies van dit subsysteem veronderstelt de aanwezigheid van een apparaat voor het beschrijven van informatie (coderingssystemen, een databeschrijvingstaal (DLS), enz.), het organiseren en onderhouden van informatie (logische en fysieke organisatie, procedures voor het onderhouden en beschermen van informatie, enz.), een verwerkingsapparaat en informatieverwerking (algoritmen, modellen, enz.).

Het subsysteem voor de voorbereiding en uitgifte van informatie implementeert direct de bevrediging van de informatiebehoeften van IS-gebruikers (intern en extern). Om deze taak te volbrengen, voert het subsysteem een ​​studie en analyse uit van de informatiebehoeften, bepaalt het de vormen en methoden van hun bevrediging, de optimale samenstelling en structuur van outputinformatieproducten, organiseert het het proces van informatieondersteuning en -onderhoud zelf.

De implementatie van deze functies vereist een apparaat voor het beschrijven en analyseren van informatiebehoeften en hun uitdrukking in de IS-taal (inclusief LOD, IPL, indexeringstaal, enz.), evenals een apparaat voor informatieondersteuning zelf (procedures voor het zoeken en verstrekken van informatie , talen voor gegevensmanipulatie enz.). Veel functies van IC-subsystemen zijn gedupliceerd of overlappen elkaar, wat het onderwerp is van optimalisatie in IC-ontwerp. In dit opzicht gaat de automatisering van IS gepaard met een herverdeling van IS-elementen.

Automatisering veronderstelt een geformaliseerde representatie (structurering) van zowel de IS-functies als de informatie die in de IS zelf verwerkt wordt, wat de invoer, verwerking/verwerking, opslag en opvraging van informatie met behulp van een computer mogelijk maakt. Elke formalisering wordt gekenmerkt door een of ander niveau van adequaatheid van het gecreëerde beeld van de werkelijkheid (model) van de werkelijkheid zelf. Bovendien wordt de geschiktheid van het werkelijkheidsmodel zowel bepaald door de eigenschappen van de werkelijkheid zelf als door de mogelijkheden van het apparaat dat wordt gebruikt voor de geformaliseerde weergave ervan.

Vanuit dit oogpunt hangt het "niveau van automatisering" van IS nauw samen met de "mate van gestructureerdheid" van informatie. Er zijn drie niveaus van gestructureerde informatie: Stijf gestructureerde informatie (data) - informatie waarvan de geformaliseerde representatie door moderne middelen van structurering (in het bijzonder databeschrijvingstalen) niet leidt tot het verlies van de adequaatheid van het informatiemodel zelf

informatie. Zwak gestructureerde informatie is informatie waarvan de geformaliseerde presentatie leidt tot aanzienlijke verliezen in de adequaatheid van het informatiemodel van de initiële informatie zelf.

Ongestructureerde informatie is informatie waarvoor momenteel geen middelen zijn om deze op een geformaliseerde manier te presenteren met een acceptabel niveau van geschiktheid in de praktijk. De middelen om dergelijke informatie te presenteren moeten een hoog semantisch en expressief vermogen hebben. De ontwikkeling van dergelijke tools gaat momenteel langs de lijn van het creëren van talen voor het beschrijven van kennis en IPL met een hoge semantische kracht.

Methoden voor het bouwen van informatiesystemen.

De industrie voor de ontwikkeling van geautomatiseerde informatiebeheersystemen ontstond in de jaren 1950 - 1960 en kreeg tegen het einde van de eeuw volledig afgewerkte formulieren.

In de eerste fase was de belangrijkste benadering bij het ontwerp van IS de "bottom-up"-methode, toen het systeem werd gecreëerd als een reeks applicaties die op dit moment het belangrijkst zijn om de activiteiten van de onderneming te ondersteunen. Deze aanpak is vandaag gedeeltelijk behouden. In het kader van "patchwork-automatisering" is de ondersteuning voor individuele functies vrij goed voorzien, maar er is praktisch geen strategie voor de ontwikkeling van een geïntegreerd automatiseringssysteem

De volgende fase houdt verband met het besef dat er behoefte is aan vrij standaard softwaretools voor het automatiseren van de activiteiten van verschillende instellingen en ondernemingen. Uit het hele spectrum van problemen hebben de ontwikkelaars de meest opvallende geïdentificeerd: automatisering van boekhouding, analytische boekhouding en technologische processen. Systemen werden "top-down" ontworpen, d.w.z. in de veronderstelling dat één programma moet voldoen aan de behoeften van veel gebruikers.

Alleen al het idee om een ​​universeel programma te gebruiken, legt aanzienlijke beperkingen op aan het vermogen van ontwikkelaars om de structuur van de database, schermformulieren en de keuze van berekeningsalgoritmen te vormen. Het rigide kader dat "van bovenaf" wordt opgelegd, maakt het niet mogelijk om het systeem flexibel aan te passen aan de specifieke kenmerken van de activiteit van een bepaalde onderneming. Dus de materiaal- en tijdkosten voor de implementatie van het systeem en de afstemming ervan op de klant vereisten meestal aanzienlijk hoger zijn dan de geplande indicatoren.

Volgens statistieken van de Standish Group (SSL) mislukte van de 8.380 projecten die in 1994 door SSL werden onderzocht meer dan 30% van de projecten met een totale waarde van meer dan $ 80 miljard. Tegelijkertijd werd slechts 16% van het totale aantal projecten op tijd afgerond en bedroegen de kostenoverschrijdingen 189% van het geplande budget.

Tegelijkertijd begonnen IS-klanten steeds meer eisen te stellen om de mogelijkheid van complex gebruik van bedrijfsgegevens bij het beheer en de planning van hun activiteiten te waarborgen. Zo ontstond er een dringende behoefte om een ​​nieuwe methodiek te ontwikkelen voor het bouwen van informatiesystemen.

Volgens moderne methodologie is het proces van het creëren van een IS een proces van het bouwen en sequentiële transformatie van een aantal overeengekomen modellen in alle stadia van de IS-levenscyclus (LC). In elke fase van de levenscyclus worden specifieke modellen gecreëerd - organisaties, vereisten voor

IK P. IP-project. toepassingsvereisten, enz. Doorgaans worden de volgende fasen van het creëren van een IS onderscheiden: het formuleren van eisen aan het systeem, ontwerp, implementatie, testen, inbedrijfstelling, bediening en onderhoud.

De eerste fase van het proces van het creëren van een IS is het modelleren van bedrijfsprocessen die plaatsvinden in de organisatie en het realiseren van haar doelen en doelstellingen. Het organisatiemodel, beschreven in termen van bedrijfsprocessen van bedrijfsfuncties, stelt u in staat om de basisvereisten voor IS te formuleren.

Het IS-ontwerp is gebaseerd op domeinmodellering. Om een ​​IS-project te verkrijgen dat geschikt is voor het vakgebied in de vorm van een systeem van correct werkende programma's, is het noodzakelijk om een ​​integrale, systematische weergave van het model te hebben, die alle aspecten van het functioneren van het toekomstige informatiesysteem weerspiegelt. In dit geval wordt een domeinmodel opgevat als een bepaald systeem dat de structuur of het functioneren van het bestudeerde domein imiteert en voldoet aan de basisvereiste - om geschikt te zijn voor dit domein.

Voorlopige modellering van het onderwerpgebied stelt u in staat om de tijd en de voorwaarden van ontwerpwerk te verminderen en een efficiënter en kwalitatief hoogwaardig project te krijgen. Zonder modellering van het vakgebied is de kans groot dat er een groot aantal fouten wordt gemaakt bij het oplossen van strategische vraagstukken, wat leidt tot economische verliezen en hoge kosten voor het daaropvolgende herontwerp van het systeem. Als gevolg hiervan zijn alle moderne IS-ontwerptechnologieën gebaseerd op het gebruik van domeinmodelleringsmethodologie.

Aan domeinmodellen worden de volgende eisen gesteld:

Formalisatie, het geven van een eenduidige beschrijving van de structuur van het vakgebied;

Begrijpelijkheid voor klanten en ontwikkelaars op basis van het gebruik van grafische middelen om het model weer te geven;

Realiseerbaarheid, wat inhoudt dat er middelen beschikbaar zijn voor fysieke implementatie van het domeinmodel en IS;

Het geven van een beoordeling van de effectiviteit van de implementatie van het domeinmodel op basis van bepaalde methoden en berekende indicatoren.

Functionele modellering IDEF0: basisdefinities en bepalingen.

Het programma voor geïntegreerde automatisering van de productie ICAM (ICAM - Integrated Computer Aided Manufacturing) is gericht op het verhogen van de efficiëntie van industriële ondernemingen door de wijdverbreide introductie van computer(informatie)technologieën. In de Verenigde Staten werd deze omstandigheid eind jaren 70 gerealiseerd, toen de Amerikaanse luchtmacht voorstelde en implementeerde

De IDEF (ICAM Definition)-methodologie maakt het mogelijk om de structuur, parameters en kenmerken van productietechnische en organisatorisch-economische systemen te bestuderen (in de toekomst, waar het geen verwarring veroorzaakt - systemen). De algemene IDEF-methodologie bestaat uit drie specifieke modelleringsmethodologieën op basis van grafische representaties van systemen:

IDEF0 wordt gebruikt om een ​​functioneel model te maken dat de structuur en functies van het systeem weergeeft, evenals de informatiestromen en materiële objecten die deze functies verbinden.

IDEF1 wordt gebruikt om een ​​informatiemodel te bouwen dat de structuur en inhoud weergeeft van informatiestromen die nodig zijn om de systeemfuncties te ondersteunen;

Met IDEF2 kunt u een dynamisch model bouwen van het tijdsafhankelijke gedrag van functies, informatie en systeembronnen.

Inmiddels zijn de meest wijdverbreide en toegepaste methodologieën IDEF0 en IDEF1 (IDEF1X), die in de Verenigde Staten de status van federale normen hebben gekregen. De IDEF0-methodologie, waarvan de kenmerken en toepassing in dit Guidance Document (GD) worden beschreven, is gebaseerd op de benadering die in het begin van de jaren 70 door Douglas T. Ross is ontwikkeld en SADT wordt genoemd (Structured Analysis & Design Technique - methode van structurele analyse en ontwerp). De aanpak en bijgevolg de IDEF0-methodologie zijn gebaseerd op een grafische taal voor het beschrijven van (modellerings)systemen, die de volgende eigenschappen heeft.

Voor de juiste weergave van de interacties van IS-componenten is het van belang om dergelijke componenten gezamenlijk te modelleren, vooral vanuit het inhoudelijke oogpunt van objecten en functies.

De methodologie van structurele systeemanalyse helpt enorm bij het oplossen van dergelijke problemen.

Het is gebruikelijk om een ​​structurele analyse een methode te noemen voor het bestuderen van een systeem, die begint met zijn algemeen overzicht en vervolgens gedetailleerd wordt, waarbij een hiërarchische structuur wordt verkregen met een toenemend aantal niveaus. Dergelijke methoden worden gekenmerkt door: indeling in abstractieniveaus met een beperkt aantal elementen (van 3 tot 7); begrensde context, inclusief alleen de essentiële details van elk niveau; gebruik van strikte formele opnameregels; consistente benadering van het resultaat.

Laten we de belangrijkste concepten van de structurele analyse van de onderneming (organisatie) definiëren.

Bediening is een elementaire (ondeelbare) handeling die op één werkplek wordt uitgevoerd.

Functie - een reeks bewerkingen gegroepeerd volgens een specifieke functie.

Een bedrijfsproces is een samenhangend geheel van functies, tijdens de uitvoering waarvan bepaalde middelen worden verbruikt en een product wordt gecreëerd (object, dienst, wetenschappelijk

ontdekking, idee), wat van waarde is voor de consument.

Een subproces is een bedrijfsproces dat een structureel onderdeel is van een bedrijfsproces en van waarde is voor de consument.

Een bedrijfsmodel is een grafisch gestructureerde beschrijving van een netwerk van processen en activiteiten die verband houden met gegevens, documenten, organisatie-eenheden en andere objecten die de bestaande of beoogde activiteiten van de onderneming weerspiegelen. Er zijn verschillende methodieken voor structurele domeinmodellering, waaronder functiegerichte en objectgeoriënteerde methodieken.

Het beschrijven van een systeem met IDEF0 wordt een functioneel model genoemd. Het functionele model is bedoeld om bestaande bedrijfsprocessen te beschrijven, waarbij zowel natuurlijke als grafische talen worden gebruikt. Om informatie over een specifiek systeem over te brengen, is de bron van de grafische taal de IDEF0-methodologie zelf.

De IDEF0-methodologie schrijft de constructie voor van een hiërarchisch systeem van diagrammen - enkele beschrijvingen van systeemfragmenten. Eerst wordt het systeem als geheel en zijn interactie met de buitenwereld beschreven (contextdiagram), waarna functionele decompositie wordt uitgevoerd - het systeem wordt opgedeeld in subsystemen en elk subsysteem wordt afzonderlijk beschreven (decompositiediagrammen). Vervolgens wordt elk subsysteem opgesplitst in kleinere, enzovoort, totdat het gewenste detailniveau is bereikt.

Gereedschapsomgeving BPwin.

Bedrijfsprocesmodellering wordt meestal uitgevoerd met behulp van case-tools. Deze tools omvatten BPwin (PLATINUM-technologie), Silverrun (Silverrun-technologie), Oracle Designer (Oracle), Rational Rose (Rational Software), enz. De functionaliteit van de structurele modelleringstools voor bedrijfsprocessen zal worden besproken aan de hand van het voorbeeld van de BPwin-case hulpmiddel.

BPwin ondersteunt drie modelleringsmethodologieën: functionele modellering (IDEF0); beschrijving van bedrijfsprocessen (IDEF3); gegevensstroomdiagrammen (DFD). BPwin heeft een vrij eenvoudige en intuïtieve gebruikersinterface. Wanneer u BPwin start, verschijnt standaard de hoofdwerkbalk, het gereedschapspalet (waarvan het uiterlijk afhankelijk is van de geselecteerde notatie) en, aan de linkerkant, de modelnavigator - Model Explorer).

Wanneer u een nieuw model maakt, verschijnt er een dialoogvenster waarin u moet specificeren of het model opnieuw wordt gemaakt of dat het wordt geopend vanuit een bestand of vanuit de ModelMart-repository, voer vervolgens de naam van het model in en selecteer de methodologie waarin het model zal gebouwd worden.

Zoals hierboven vermeld, ondersteunt BPwin drie methodologieën - IDEF0, IDEF3 en DFD, die elk hun eigen specifieke problemen oplossen. In BPwin is het mogelijk om gemengde modellen te bouwen, dat wil zeggen dat een model zowel IDEF0 als IDEF3 en DFD-diagrammen tegelijk kan bevatten. De samenstelling van het toolpalet verandert automatisch bij het overschakelen van de ene notatie naar de andere.

Een BPwin-model wordt gezien als een verzameling activiteiten, die elk op een set gegevens werken. Werk wordt weergegeven als rechthoeken, gegevens als pijlen. Als u met de linkermuisknop op een object van het model klikt, verschijnt een contextmenu, waarvan elk item overeenkomt met de editor van een bepaalde eigenschap van het object.

In de beginfase van het maken van een IP is het noodzakelijk om te begrijpen hoe de organisatie die gaat automatiseren werkt. De manager kent het werk als geheel goed, maar kan niet ingaan op de details van het werk van elke gewone medewerker. Een gewone werknemer weet goed wat er op zijn werkplek gebeurt, maar weet misschien niet hoe collega's werken. Om het werk van een onderneming te beschrijven, is het daarom noodzakelijk om een ​​model te bouwen dat geschikt is voor het vakgebied en de kennis bevat van alle deelnemers aan de bedrijfsprocessen van de organisatie.

De handigste taal voor het modelleren van bedrijfsprocessen is IDEF0, waar het systeem wordt weergegeven als een set van op elkaar inwerkende activiteiten of functies. Deze puur functionele oriëntatie is fundamenteel - de functies van het systeem worden geanalyseerd onafhankelijk van de objecten waarmee ze werken. Hierdoor kun je de logica en interactie van de organisatieprocessen beter modelleren.

Het proces van het modelleren van een systeem in IDEF0 begint met het maken van een contextdiagram, een diagram van het meest abstracte niveau van de beschrijving van het systeem als geheel, met de definitie van het onderwerp van modellering, het doel en het standpunt over het model.

Activiteiten verwijzen naar benoemde processen, functies of taken die in de loop van de tijd plaatsvinden en herkenbare resultaten hebben.

Werken worden afgebeeld als rechthoeken. Alle taken moeten worden benoemd en gedefinieerd. De naam van de taak moet worden uitgedrukt door een verbaal zelfstandig naamwoord dat een actie aanduidt (bijvoorbeeld "Bedrijfsactiviteit", "Een bestelling opnemen", enz.). Het werk "Bedrijfsactiviteiten" kan bijvoorbeeld de volgende definitie hebben: "Dit is een leermodel dat bedrijfsactiviteiten beschrijft." Bij het maken van een nieuw model (menu Bestand / Nieuw), wordt automatisch een contextdiagram gemaakt met een enkel werk dat het systeem als geheel weergeeft.

Pijlen beschrijven de interactie van taken en vertegenwoordigen bepaalde informatie uitgedrukt in zelfstandige naamwoorden (bijvoorbeeld "Klantoproepen", "Regels en procedures", "Boekhoudingssysteem".)

Leerboek voor universiteiten

2e druk, ds. en voeg toe.

2014 G.

Oplage 1000 exemplaren.

Formaat 60x90/16 (145x215 mm)

Uitvoering: paperback

ISBN 978-5-9912-0193-3

BBQ 32.882

UDC 621.395

Grif UMO
Door UMO aanbevolen voor onderwijs op het gebied van telecommunicatie als leerboek voor studenten van instellingen voor hoger onderwijs die studeren in de specialisaties "Netwerken en schakelsystemen", "Meerkanaals telecommunicatiesystemen"

annotatie

Algoritmen voor het modelleren van discrete en continue willekeurige variabelen en processen worden overwogen. De principes en algoritmen voor het modelleren van informatiesignalen beschreven door Markov-processen met discrete en continue tijd worden vermeld.De principes van het modelleren van wachtrijsystemen worden overwogen. De kenmerken van de beschrijving en het gebruik van fractal- en multifractal-processen voor het modelleren van telecommunicatieverkeer worden beschreven. Methoden en voorbeelden van het modelleren van informatiesystemen met behulp van gespecialiseerde softwarepakketten Matlab, Opnet, Network simulator worden geanalyseerd.

Voor studenten die zijn ingeschreven in de specialiteiten "Netwerken en schakelsystemen", "Meerkanaals telecommunicatiesystemen", "Informatiesystemen en technologieën".

Invoering

1 Algemene principes van systeemmodellering
1.1. Algemene concepten van modelleren en modelleren
1.2. Modelclassificatie
1.3. Modelstructuur
1.4. Methodologische grondslagen voor het formaliseren van het functioneren van een complex systeem
1.5. Componentmodellering
1.6. Stadia van de vorming van een wiskundig model
1.7. Simulatiemodellering
Controlevragen

2 Algemene principes van het bouwen van communicatiesystemen en netwerken
2.1. Het concept van het bouwen van communicatiesystemen en netwerken
2.2. Gelaagde netwerkmodellen
2.2.1. Model met drie niveaus
2.2.2. TCP / IP-protocolarchitectuur
2.2.3. OSI-referentiemodel
2.3. Communicatie netwerkstructuur
2.3.1. Wereldwijde netwerken
2.3.2. Lokale netwerken
2.3.3. Computernetwerktopologieën
2.3.4. Lokale Ethernet-netwerken
2.4. Frame Relay-netwerken
2.5. IP-telefonie
Controlevragen

3 Simulatie van willekeurige getallen
3.1. Willekeurige getallen begrijpen
3.2. Programmatische methoden voor het genereren van uniform verdeelde willekeurige getallen
3.3. Vorming van willekeurige variabelen met een gegeven distributiewet
3.3.1. Inverse functie methode:
3.3.2. Geschatte methoden voor het converteren van willekeurige getallen
3.3.3. Screeningsmethode (Neumann-generatiemethode)
3.4. Methoden gebaseerd op de centrale limietstelling
3.5. Algoritmen voor het modelleren van veelgebruikte willekeurige variabelen
3.6. Algoritmen voor het modelleren van gecorreleerde willekeurige variabelen
3.7. Vorming van realisaties van willekeurige vectoren en functies
3.7.1. Modelleren van een n-dimensionaal willekeurig punt met onafhankelijke coördinaten
3.7.2. Vorming van een willekeurige vector (in het kader van de correlatietheorie)
3.7.3. Vorming van implementaties van willekeurige functies

4 Modelleren van discrete distributies
4.1. Bernoulli-distributie
4.2. binominale verdeling
4.3. Poisson-verdeling
4.4. Simulatie van proeven in een willekeurig gebeurtenisschema
4.4.1. Simulatie van willekeurige gebeurtenissen
4.4.2. Tegengestelde gebeurtenissen modelleren
4.4.3. Een discrete willekeurige variabele modelleren
4.4.4. Modelleren van een complete groep gebeurtenissen
4.5. Streams van evenementen
4.6. Verwerking van simulatieresultaten
4.6.1. Precisie en aantal realisaties
4.6.2. Primaire statistische gegevensverwerking
Controlevragen

5 Algoritmen voor het modelleren van stochastische signalen en interferentie in communicatiesystemen
5.1. Algoritme voor het modelleren van niet-stationaire stochastische processen
5.2. Algoritmen voor het modelleren van stationaire willekeurige processen
5.3. Methoden voor het modelleren van signalen en ruis in de vorm van stochastische differentiaalvergelijkingen
5.4. Voorbeelden van modellen van stochastische processen in communicatiesystemen
5.4.1. Informatieprocesmodellen
5.4.2. Interferentiemodellen
5.4.3. Kenmerken van de belangrijkste soorten interferentie
Controlevragen

6 Markov stochastische processen en hun modellering
6.1. Basisconcepten van een Markov stochastisch proces
6.2. Basiseigenschappen van discrete Markov-ketens
6.3. Continue Markov-ketens
6.3.1. Basisconcepten
6.3.2. Semi-Markov-processen
6.3.3. Dood en voortplantingsprocessen
6.4. Modellen van willekeurige Markov-processen met continue waarde op basis van stochastische differentiaalvergelijkingen
6.5. Modellering van Markov stochastische processen
6.5.1. Modelleren van discrete processen
6.5.2. Modellering van scalaire processen met continue waarde
6.5.3. Modelleren van continue gewaardeerde vectorprocessen
6.5.4. Modelleren van een Gaussiaans proces met fractioneel-rationele spectrale dichtheid
6.5.5. Modelleren van meervoudig verbonden reeksen
6.5.6. Markov-processen modelleren met behulp van vormfilters
6.5.7. Algoritme voor statistische modellering van Markov-ketens
Controlevragen

7 Voorbeelden van Markov-modellen
7.1. Markov-modellen van spraakdialoog van abonnees
7.1.1. Spraaktoestanden
7.1.2. Dialoogmodellen
7.2. Markov-modellen van spraakmonoloog
7.3. Markov-gedreven Poisson-proces in spraakmodellen
7.4. Markov-modellen van digitale sequenties aan de uitgang van de G.728-codec
7.5. Statistische multiplexing van de bron van spraakpakketten, rekening houdend met het Markov-model van telefoondialoog
7.6. Markov-model van een draadloos kanaal met ARQ / FEC-mechanisme
7.7. Batchfouten
7.8. Berekening van foutstroomkarakteristieken door modelparameters
7.8.1. De parameters van de foutenstroom schatten
7.8.2. Evaluatie van de geschiktheid van het foutenstroommodel
7.9. Markov-modellen voor het beoordelen van de QoS van realtime multimediadiensten op internet
7.9.1. Realtime multimediadienstenconcept
7.9.2. Analyse en modellering van vertragingen en verliezen
7.10. Modellen van multimedia verkeersstromen
Controlevragen

8 Wachtrijsystemen en hun modellering
8.1. Algemene kenmerken van wachtrijsystemen
8.2. Structuur van wachtrijsysteem
8.3. Wachtrijsystemen met wachten
8.3.1. Servicesysteem M / M / 1
8.3.2. Servicesysteem M / G / 1
8.3.3. Netwerken met een groot aantal knooppunten verbonden door communicatiekanalen
8.3.4. Prioritaire dienst
8.3.5. Servicesysteem M / M / N / m
8.4. Storingswachtrijsystemen
8.5. Algemene principes van het modelleren van wachtrijsystemen
8.5.1. Statistische testmethode:
8.5.2. Modellen van systeemfunctionerende processen blokkeren
8.5.3. Kenmerken van modellering met behulp van Q-circuits
Controlevragen

9 Modelleren van informatiesystemen met behulp van typische technische middelen
9.1. Systeemmodellering en programmeertalen
9.2. De GPSS-taal begrijpen
9.2.1. Dynamische objecten GPSS. Transactiegerichte blokken (operators)
9.2.2. Hardware-georiënteerde blokken (operators)
9.2.3. Meerkanaalsservice
9.2.4. GPSS statistische blokken
9.2.5. Bedieningseenheden GPSS
9.2.6. Andere GPSS-blokken
9.3. Simulatie van het ETHERNET-netwerk in de GPSS-omgeving
Controlevragen

10 Modellering van informatietransmissiesystemen
10.1. Typisch datatransmissiesysteem:
10.2. Immuniteit van transmissie van discrete signalen. Optimale ontvangst
10.3. Schatting van de kans op foutieve ontvangst van discrete signalen met volledig bekende parameters
10.4. Immuniteit van discrete signalen met willekeurige parameters
10.5. Immuniteit van discrete signalen met onsamenhangende ontvangst
10.6. Immuniteit van discrete signalen met willekeurige essentiële parameters
10.7. Algoritmen voor de vorming van discrete signalen
10.8. Algoritme voor het genereren van interferentie
10.9. Algoritme voor demodulatie van discrete signalen
10.10. De structuur van het imitatiecomplex en zijn subroutines
10.11. Mathworks Matlab-softwareomgeving en Simulink visueel modelleringspakket
10.11.1. Technische beschrijving en interface
10.11.2. Simulink Visuele Simulatie Pakket
10.11.3. Aanmaken en maskeren van subsystemen
10.11.4. Communicatie Toolbox Uitbreidingspakket
10.12. Modellering van de blokken van het WiMAX-gegevensoverdrachtsysteem
10.12.1. Zender simulatie
10.12.2. Een transmissiekanaal modelleren
10.12.3. Ontvanger simulatie
10.12.4. Implementatie van het model in het Mathlab-systeem
10.13. Resultaten van WiMAX-systeemsimulatie
Controlevragen

11 Zelf-soortgelijke processen en hun toepassing in telecommunicatie
11.1. Grondbeginselen van de theorie van fractale processen
11.2. Multifractale processen
11.3. Schatting van de Hurst-exponent
11.4. Multifractale analyse met software
11.4.1. Beschrijving van de software
11.4.2. Voorbeelden van het beoordelen van de mate van zelfgelijkheid
11.5. Algoritmen en software voor multifractale analyse
11.6. Invloed van zelfgelijkenis van verkeer op de kenmerken van het servicesysteem
11.7. Methoden voor het modelleren van vergelijkbare processen in tv-verkeer
11.8. Verkenning van de zelf-soortgelijke structuur van Ethernet-verkeer
11.9. Zelfvergelijkende verkeersopstoppingscontrole
11.10. Fractale Brownse beweging
11.10.1. RMD-algoritme voor het genereren van FBD
11.10.2. SRA FWA Generatie-algoritme
11.12. Fractal Gauss-ruis
11.12.1. FFT-algoritme voor FGS-synthese
11.12.2. Evaluatie van simulatieresultaten
Controlevragen

12 Modelleren van een
12.1. Grondbeginselen van het Frame Relay-protocol
12.2. Frame Relay Host Ontwerp
12.3. Simulatieresultaten van een FR-router met G.728-codecs aan de ingang
12.4. Impact van zelfgelijkenis van verkeer op QoS
Controlevragen

13 Gespecialiseerde systemen voor simulatie van computernetwerken
13.1. Algemene kenmerken van gespecialiseerde softwarepakketten voor netwerkmodellering
13.2. Algemene principes van modellering in de OPNET Modeler-omgeving
13.3. OPNET-toepassingsvoorbeelden
13.3.1. Model voor het beoordelen van de kwaliteit van de dienstverlening
13.3.2. Implementatie van het lokale netwerkmodel
Controlevragen

14 Simulatie met Netwerksimulator 2
14.1. Geschiedenis en architectuur van het NS2-pakket
14.2. Een simulatorobject maken
14.3. Een netwerktopologie maken
14.4. Generatorparameters instellen
14.4.1. Exponentieel Aan / Uit
14.4.2. Pareto Aan / Uit
14.5. Twee belangrijke wachtrij-algoritmen
14.6. Adaptieve routering in NS2
14.6.1. API op gebruikersniveau
14.6.2. Interne architectuur
14.6.3. Uitbreidingen naar andere lessen
14.6.4. Gebreken
14.6.5. Lijst met opdrachten die worden gebruikt om dynamische scripting in NS2 te simuleren
14.6.6. Een voorbeeld van dynamische routering in NS2
14.7. Een scriptprogramma uitvoeren in NS2
14.8. Procedure voor het verwerken van simulatieresultaten:
14.9. Een voorbeeld van het modelleren van een draadloos netwerk
14.10. Een voorbeeld van simulatie van de kwaliteit van streaming videotransmissie met behulp van het NS 2-pakket
14.10.1. De structuur van het hardware- en softwarecomplex voor het beoordelen van de kwaliteit van streaming video
14.10.2. PAK functionele modules
14.10.3. Beoordeling videokwaliteit