Send det gode arbeidet ditt i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor

Studenter, hovedfagsstudenter, unge forskere som bruker kunnskapsbasen i studiene og arbeidet vil være veldig takknemlige for deg.

Lagt ut på http://www.allbest.ru/

Omsk State Institute of Service

Modellering av informasjonssystemer ved bruk av UML-språket

Metodisk veiledning for gjennomføring av semesteroppgave

I.V. Chervenchuk

• Introduksjon
• 2 . Unified Modeling LanguageUML
• 4. Utvikling av en programvaresystemmodell ved hjelp avUML
• 5. Spørsmål om implementering av informasjonssystemet
• 6. Emner for kursarbeid
• Bibliografisk liste

Introduksjon

Oppgaven tar for seg utvikling av informasjonssystemer ved bruk av det enhetlige modelleringsspråket UML, som er grunnlaget for kursarbeidet i faget "Informasjonssystemer og prosesser. Modellering og ledelse". Hovedstadiene i en rasjonell enhetlig prosess for utvikling av informasjonssystemer er under utarbeidelse, eksempler og illustrasjoner er gitt. Det gis muligheter for oppgaver til kurs.

Metodiske instruksjoner er beregnet på studenter med spesialiteten "Anvendt informatikk" og kan brukes i kurs, forberedelse til eksamen, så vel som i prosessen med selvstendig arbeid.

1. Generelle krav til gjennomføring av semesteroppgave

Kursarbeid på disiplinen "Informasjonssystemer og prosesser. Modellering og ledelse" er det siste stadiet av å studere dette emnet og er designet for å konsolidere i praksis den grunnleggende teoretiske kunnskapen om modellering av informasjonssystemer. Arbeidet består i å utvikle en modell av et informasjonssystem ved hjelp av det enhetlige modelleringsspråket UML med påfølgende implementering. Som en typisk versjon av oppgaven foreslås det å utvikle et informasjons- og referansesystem basert på en database, men etter ønske fra eleven, etter avtale med lærer, kan utvikling av WEB-applikasjon, testsystem eller maskinvareenhet. tilbys som et oppdrag. Samtidig er hovedforutsetningen bruk av en objektorientert tilnærming og konstruksjon av en UML-modell.

Den typiske tittelen på semesteroppgaven ser ut som "Utvikling av et informasjons- og referansesystem _ tittel _ "

Introduksjon

1. Betydelig oversikt over fagområdet. Grunnleggende systemkrav

2. En detaljert modell av informasjonssystemet

2.1 Utsikt fra brukstilfellers perspektiv

2.2 Designvisning

2.3 Implementeringssyn

2.4 Prosessperspektiv (hvis aktuelt)

2.5 Utsikt fra distribusjonssynspunkt (om nødvendig)

3. Implementering av informasjonssystemet

Konklusjon

Søknadsliste for et program eller hodemodul

I innledningen kan man peke på bruk av informasjonsteknologi innen ulike virksomhetsområder, herunder tjenestesektoren, fordelene med elektronisk regnskap, problemene med å bygge spesialiserte informasjonssystemer mv.

Disse retningslinjene inneholder detaljerte anbefalinger for hoveddelene i det forklarende notatet og designeksempler. Det skal bemerkes at hovedemnet for dette kursarbeidet er utviklingen av en UML-modell av et informasjonssystem, derfor anbefales det sterkt at UML-diagrammer gis i hoveddelen av et forklarende notat, og gir dem detaljerte kommentarer , og tekstene til programmer skal plasseres i søknaden.

Prosessvisningen bør gis når du designer multitasking-systemer. Utrullingsvisningen forutsetter et distribuert informasjonssystem. Disse typene, og de tilsvarende delene av det forklarende notatet, er ikke obligatoriske for gjennomføringen av dette kursarbeidet, bruken av dem forutsettes når du utfører kun visse varianter av kursarbeidet.

Når du fremhever problemene med systemimplementering i et notat, er det tilrådelig å begrunne valget av et programmeringsmiljø, for å gi en brukermanual. Et obligatorisk element er inkludering av skjermskjemaer (screen-shorts) av det implementerte programmet i teksten, bruk av reverse engineering-verktøy oppmuntres.

I konklusjonen er hovedresultatene av arbeidet kort oppsummert: en UML-modell av systemet er utviklet, systemet er implementert gjennom et slikt og slikt programmeringsmiljø som det utviklede systemet tillater, fordelene med tilnærmingene som brukes (basert om modellering) til design av systemer.

språk for modellering av informasjonssystem

Kursarbeid skal inneholde 20-30 sider trykt tekst med illustrasjoner. Diagrammer over brukstilfeller, klasser, interaksjoner må leveres uten feil.

2. Unified Modeling Language UML

Rasjonell utvikling av et informasjonssystem forutsetter en dyp analytisk forundersøkelse. Først av alt er det nødvendig å skissere utvalget av oppgaver som utføres av systemet som utvikles, deretter å utvikle en modell av systemet, og til slutt å bestemme implementeringsmetodene. En dyp studie av arkitekturen til informasjonssystemet som utvikles i de innledende designstadiene, lønner seg som regel senere, spesielt når man utvikler store prosjekter med langsiktig støtte.

Verktøyene til modelleringsspråket UML (Unified Model Language, - et enhetlig programmeringsspråk) tillater uttrykksfullt og ganske enkelt å utføre en foreløpig konseptuell utvikling av et informasjonssystem, og samtidig følge metodisk hele utviklingsprosessen, inkludert hele videre livssyklus av det utviklede informasjonssystemet som et programvareprodukt.

UML er et objektorientert språk for å visualisere, spesifisere, konstruere og dokumentere artefakter av programvaresystemer.

UML, som alle andre språk, består av et vokabular og regler som lar deg kombinere ordene som er inkludert i det og få meningsfulle konstruksjoner. I et modelleringsspråk er vokabular og regler fokusert på den konseptuelle og fysiske representasjonen av informasjonssystemer. Modellering er avgjørende for å forstå systemet. Når det er sagt, er en enkelt modell aldri nok. Tvert imot, for å forstå ethvert ikke-trivielt system må man utvikle et stort antall sammenhengende modeller. Når det gjelder programvaresystemer, betyr dette at det trengs et språk som det er mulig å beskrive representasjonene av systemets arkitektur fra ulike synsvinkler gjennom hele utviklingssyklusen.

UML er et visualiseringsspråk, og UML er ikke bare en samling grafiske symboler. Hver av dem har veldefinert semantikk (se) Dermed kan en modell skrevet av en utvikler tolkes entydig av en annen, eller til og med av en verktøykasse.

UML er et spesifikasjonsspråk. I denne sammenheng betyr spesifikasjon å bygge nøyaktige, entydige og komplette modeller. UML tillater spesifikasjon av alle viktige analyse-, design- og implementeringsbeslutninger som må tas under utvikling og distribusjon av et programvaresystem.

UML er et formspråk. Selv om UML ikke er et visuelt programmeringsspråk, kan modellene som er opprettet med det oversettes direkte til ulike spesifikke programmeringsspråk. Med andre ord kan UML-modellen kartlegges til språk som Java, C ++, Visual Basic og til og med relasjonsdatabasetabeller eller vedvarende objektorienterte databaseobjekter. De konseptene som fortrinnsvis formidles grafisk er representert i UML; de som er bedre beskrevet i tekstform uttrykkes ved hjelp av et programmeringsspråk.

Denne kartleggingen av en modell til et programmeringsspråk tillater direkte design: generering av kode fra en UML-modell til et spesifikt språk. Du kan også løse det omvendte problemet: gjenopprett modellen fra den eksisterende implementeringen. Naturligvis innebærer modellen og implementeringen bruk av en rekke spesifikke enheter. Derfor krever revers engineering både verktøy og menneskelig inngripen. Kombinasjonen av fremadkodegenerering og reverse engineering lar deg jobbe i både grafiske og tekstlige representasjoner så lenge verktøyene sikrer konsistens mellom begge representasjonene.

I tillegg til direkte kartlegging til programmeringsspråk, lar UML, på grunn av sin uttrykksfullhet og entydighet, deg direkte utføre modeller, simulere oppførselen til systemene og kontrollere operativsystemer.

UML er et dokumentasjonsspråk

Et programvareselskap produserer andre dokumenter i tillegg til kjørbar kode, inkludert:

Systemkrav;

arkitektur;

prosjekt;

kilde;

prosjektplaner;

tester;

prototyper;

versjoner osv.

Avhengig av vedtatt utviklingsmetodikk utføres noen arbeider mer formelt, andre mindre. Dokumentene det vises til er ikke bare leverte deler av prosjektet; de er nødvendige for ledelsen, for å evaluere resultatet, og også som et middel for kommunikasjon mellom teammedlemmer under systemutvikling og etter implementering.

UML gir utvikleren og ledelsen sin egen måte å løse problemet med å dokumentere systemarkitekturen og alle dens detaljer, gir et språk for å formulere systemkrav og definere tester, og til slutt gir et middel for modelleringsarbeid under prosjektplanlegging og versjon kontrollfasen.

La oss vurdere utviklingen av en modell av et informasjonssystem ved hjelp av UML-språket ved å bruke eksempelet på utviklingen av en automatisert arbeidsstasjon for en avdelingssekretær (heretter referert til som en avdelingssekretærs AWP).

3. Beskrivelse av fagområdet

Begrepet databasefagområde er et av de grunnleggende begrepene innen informatikk og har ingen presis definisjon. Dens bruk i sammenheng med IP forutsetter eksistensen av en stabil korrelasjon over tid mellom navn, konsepter og visse realiteter i den ytre verden, uavhengig av IP selv og dens brukerkrets. Dermed begrenser og gjør introduksjonen av konseptet til databasedomenet informasjonsinnhentingsrommet synlig i IS og gjør det mulig å utføre spørringer på en begrenset tid.

Under beskrivelsen av fagområdet mener vi beskrivelsen av miljøet til systemet som utvikles, typene brukere av systemet, samtidig som vi angir hovedoppgavene hvis løsning er tilordnet systemet.

I den foreløpige beskrivelsen av fagområdet introduseres de grunnleggende begrepene (systemvokabular), brukertypene og deres rettigheter fastsettes, oppgavene som det utviklede systemet skal løse er formulert. I dette tilfellet er beskrivelsen ment å bruke virkemidlene til vanlig språk og standard forretningsgrafikk (bilder, diagrammer, tabeller).

Når du utvikler en systemordbok, er det nødvendig å definere navnene på enheter ("student", "lærer", "disiplin"). I dette tilfellet blir begrepet essens forstått av oss som en komponent av domenemodellen, det vil si som et objekt som allerede er identifisert på konseptuelt nivå. Objektene som er tildelt i fagområdet omdannes av analytikeren til enheter.

Entitet er resultatet av abstraksjon av et virkelig objekt. Det er to problemer knyttet til objekter: identifikasjon og adekvat beskrivelse. For identifikasjon brukes et navn, som skal være unikt. I dette tilfellet antas det at det er en avvisning av betydningen, som er iboende i naturlig språk. Kun den veiledende funksjonen til navnet brukes. Navnet er en direkte måte å identifisere et objekt på. Indirekte metoder for objektidentifikasjon inkluderer definisjonen av et objekt gjennom dets egenskaper (karakteristikker eller tegn).

Objekter samhandler med hverandre gjennom egenskapene deres, noe som gir opphav til situasjoner. Situasjoner er relasjoner som uttrykker relasjoner mellom objekter. Situasjoner i fagområdet beskrives ved hjelp av utsagn om fagområdet. På dette stadiet kan du bruke metodene for proposisjonskalkyle og predikatkalkulus, det vil si formell, matematisk logikk. For eksempel beskriver utsagnet «Programmeren og lederen er ansatte i bedriften» et inkluderende forhold. Dermed blir all informasjon om objekter og enheter i domenet beskrevet ved hjelp av utsagn på naturlig språk.

Du kan spesifisere strukturelle koblinger, fremheve statiske og dynamiske situasjoner (og dermed introdusere en tidsparameter i modellen), men for en detaljert studie av modellen er det mer praktisk å bruke avanserte metoder for å beskrive domenet, for eksempel UML-språket.

Så oppgaven er å utvikle et system "arbeidsstasjon for sekretæren for avdelingen" som vil tillate automatisert regnskapsføring av data om ansatte og studenter ved avdelingen for IKT ved OmSTU, gi fleksible muligheter for å løse planlagte og ikke-planlagte spesifikke behandlingsoppgaver legitimasjon.

Som en del av å løse problemet med å utvikle en automatisert arbeidsplass for sekretæren for avdelingen, vil vi skille ut følgende enheter:

lærere - lærere ved avdelingen;

studenter- studenter ved universitetet i denne spesialiteten;

studenter studerer i grupper, gruppe er en organiserende (samlende) enhet for studenter;

avgangselev, har det særegne at de på den ene siden selv kan gjennomføre undervisning, på den andre siden er de selv studenter og har en vitenskapelig rådgiver;

disiplin- den underviste disiplinen (fag, kurs).

Innsatte enheter har en rekke attributter, som vi vil definere senere.

Vi utfører to typer brukere: private bruker(lengre bruker, og administrator... Det antas at bruker kan få tilgang til systemet med en forespørsel, vise rapporter, administrator kan i tillegg endre data. For eksempel kan assisterende sekretær ved avdelingen fungere som bruker, sekretæren selv eller ansvarlig lærer kan fungere som administrator.

Med tanke på vilkårene som er introdusert, bør systemet som utvikles gi:

organisering av fullstendig og pålitelig regnskap for alle ansatte og studenter ved avdelingen;

informasjonsstøtte til ledelsesbeslutninger som er tatt, dannelse av fullstendig og pålitelig informasjon om utdanningsprosesser og resultatene av avdelingens aktiviteter;

reduksjon av arbeidskostnader for utarbeidelse av primære dokumenter og rapporter;

eliminering av duplisering når du legger inn informasjon og de resulterende mekaniske feilene;

brukervennlig grensesnitt;

differensiering av makten til vanlige brukere og administrator.

I dette eksemplet løser vi et spesielt problem - vi utvikler AWP for sekretæren for avdelingen, derfor blir avdelingen tatt som en strukturell enhet på høyeste nivå for oss, som vi vil ha i tankene som standard, det vil si, det antas at alle elementene i modellen kun relaterer seg til denne avdelingen, som ikke er eksplisitt spesifisert ... Vi vil ikke vurdere strukturer på høyere nivå, for eksempel et fakultet, et universitet.

4. Utvikling av en programvaresystemmodell ved bruk av UML

UML er et språk for spesifikasjon og visualisering, hovedenhetene er diagrammer.

Et UML-diagram er en grafisk representasjon av et sett med sjablonger, oftest avbildet som en sammenhengende graf med hjørner (entiteter) og kanter (relasjoner). Diagrammene karakteriserer systemet fra ulike synsvinkler. Et diagram er på en måte en av projeksjonene til systemet. Vanligvis gir diagrammer en sammenslått visning av elementene som utgjør et system. Ett og samme element kan være til stede i alle diagrammer, eller bare i flere (den vanligste varianten), eller ikke til stede i noen (svært sjelden). I teorien kan diagrammer inneholde en hvilken som helst kombinasjon av enheter og relasjoner. I praksis brukes imidlertid et relativt lite antall typiske kombinasjoner, tilsvarende de fem vanligste typene som utgjør arkitekturen til et programvaresystem (se neste avsnitt). Således, i UML, skilles ni typer diagrammer ut:

klassediagrammer

objekt diagrammer;

bruk case-diagrammer;

sekvensdiagrammer;

samarbeidsdiagrammer;

tilstandsdiagrammer;

handling (aktivitet) diagrammer;

komponentdiagrammer;

distribusjonsdiagrammer.

UML konseptuell modell

Et klassediagram viser klasser, grensesnitt, objekter og samarbeid, og deres relasjoner. Ved modellering av objektorienterte systemer brukes denne typen diagram oftest. Klassediagrammer tilsvarer den statiske designvisningen av systemet. Klassediagrammer som inkluderer aktive klasser tilsvarer det statiske synet av systemet fra et prosessperspektiv.

Et objektdiagram representerer objekter og relasjonene mellom dem. De er statiske "fotografier" av enhetsforekomstene vist i klassediagrammer. Objektdiagrammer, som klassediagrammer, refererer til en statisk visning av et system fra et design- eller prosessperspektiv, men med sikte på en reell eller falsk implementering.

Use-case-diagrammet viser usecases og aktører (et spesialtilfelle av klasser), samt relasjonene mellom dem. Use case-diagrammer refererer til en statisk visning av et system når det gjelder brukstilfeller. De er spesielt viktige når du organiserer og modellerer oppførselen til et system.

Sekvensdiagrammer og samarbeidsdiagrammer er spesielle tilfeller av interaksjonsdiagrammer. Interaksjonsdiagrammer representerer relasjoner mellom objekter; viser spesielt meldingene som objekter kan utveksle. Interaksjonsdiagrammer refererer til det dynamiske synet av systemet. I dette tilfellet gjenspeiler sekvensdiagrammer den tidsmessige rekkefølgen av meldinger, og samarbeidsdiagrammer - den strukturelle organiseringen av objekter som utveksler meldinger. Disse diagrammene er isomorfe, det vil si at de kan transformeres til hverandre.

Statechart-diagrammer representerer en automat som inkluderer tilstander, overganger, hendelser og typer handlinger. Tilstandsdiagrammer refererer til det dynamiske synet av systemet; de er spesielt viktige når man skal modellere oppførselen til et grensesnitt, klasse eller samarbeid. De fokuserer på oppførselen til et objekt, avhengig av hendelsesforløpet, noe som er veldig nyttig for å simulere reaktive systemer.

Et aktivitetsdiagram er et spesialtilfelle av et tilstandsdiagram; den viser overgangene til flyten av kontroll fra en aktivitet til en annen i systemet. Aktivitetsdiagrammer refererer til en dynamisk visning av et system; de er viktigst for å modellere funksjonen og reflekterer flyten av kontroll mellom objekter.

Komponentdiagrammet viser organiseringen av et sett med komponenter og avhengighetene mellom dem. Komponentdiagrammer refererer til en statisk visning av et system fra et implementeringssynspunkt. De kan være relatert til klassediagrammer, siden en komponent vanligvis tilordnes en eller flere klasser, grensesnitt eller samarbeid.

Distribusjonsdiagrammet viser konfigurasjonen av behandlingsnodene til systemet og komponentene som er plassert i dem. Distribusjonsdiagrammer refererer til en statisk visning av et systems arkitektur fra et distribusjonsperspektiv. De er relatert til komponentdiagrammer fordi en undersammenstilling vanligvis inneholder en eller flere komponenter.

Her er en delvis liste over diagrammer som brukes i UML. Verktøyene lar deg generere andre diagrammer også, for eksempel databaseprofildiagrammer, webapplikasjonsdiagrammer og så videre.

4.1 Utforme en visning fra et bruksperspektiv

Modellering begynner med å definere hovedmålene for systemet som utvikles og handlingene det skal utføre. Use case-diagrammer brukes til disse formålene. Som diskutert tidligere, viser use case-diagrammer brukstilfeller og aktører og relasjonene mellom dem.

Presedens (Use case) er en beskrivelse av en sekvens av handlinger utført av systemet som gir et observerbart resultat som er signifikant for en viss Handling e ra (Skuespiller). Use case brukes til å strukturere atferdsenhetene til modellen. Brukstilfellet erklærer bare en beskrivelse av en eller annen handling av systemet, og svarer på spørsmålet "hva skal jeg gjøre?", Men angir ikke med hvilke midler. Den konkrete implementeringen av atferden spesifisert av brukstilfellet leveres av en klasse, klassesamarbeid eller komponent.

En skuespiller er et sammenhengende sett med roller som brukere spiller når de samhandler med dem. Vanligvis representerer en skuespiller rollen som en person, maskinvareenhet eller til og med et annet system spiller i et gitt system. I det utviklede systemet "Arbeidsstasjon for sekretæren for avdelingen" er aktørene administrator (admin) og bruker.

Grafisk er en presedens avbildet som en ellipse avgrenset av en kontinuerlig linje, som vanligvis bare inneholder navnet, skuespilleren har et "liten mann"-ikon.

For å bygge et use case-diagram er det nødvendig å identifisere de elementære handlingene som utføres av systemet og sammenligne dem med use cases. Samtidig er det ønskelig å gi navn på brukstilfeller slik at de indikerer atferd, ofte inneholder slike navn verb, for eksempel "generer en rapport", "finn data etter kriterium" osv. Det er mulig å gi navn for å bruke kasus med substantiv som foreslår noen handlinger, for eksempel "autorisasjon", "søk", "kontroll".

Tilbake til modelleringen av den automatiserte arbeidsplassen til sekretæren for avdelingen, la oss fremheve presedensene:

Redigeringdata,

Søkstudent,

Søklærer,

Utstedelselisteundervistdisipliner,

Autorisasjon.

Use case diagramelementer (use case og aktører) må knyttes sammen med relasjoner.

Det vanligste forholdet mellom use cases, use cases og aktører er assosiasjon. I noen tilfeller kan generaliseringsforhold brukes. Disse relasjonene har samme betydning som i klassediagrammet.

I tillegg er to spesifikke avhengigheter definert mellom brukstilfeller i UML - et inkluderingsforhold og et utvidelsesforhold.

Et inklusjonsforhold mellom brukstilfeller betyr at på et tidspunkt i basisbrukstilfellet blir oppførselen til en annen brukstilfelle inkorporert (inkludert). Den inkluderte brukssaken eksisterer aldri autonomt, men instansieres kun som en del av den vedlagte brukssaken. Du kan tenke på grunnbruken som å låne oppførselen til inkluderingen. På grunn av tilstedeværelsen av inkluderingsrelasjoner, er det mulig å unngå flere beskrivelser av den samme strømmen av hendelser, siden den generelle atferden kan beskrives som en uavhengig brukstilfelle inkludert i de grunnleggende. Et inkluderingsforhold er et eksempel på delegering, der en rekke ansvarsområder for systemet er beskrevet på ett sted (i den inkluderte brukssaken), og resten av brukssakene, når det er nødvendig, inkluderer disse ansvarsoppgavene i sitt sett.

Inkluderingsforhold er avbildet som avhengigheter med stereotypen "inkluder". For å spesifisere et sted i strømmen av hendelser der et grunnleggende brukstilfelle inkluderer oppførselen til en annen, skriver du ganske enkelt ordet inkludere etterfulgt av navnet på brukstilfellet som skal inkluderes.

En utvidelsesrelasjon brukes til å modellere deler av en use case som brukeren oppfatter som valgfri systematferd. Dette lar deg skille nødvendig og valgfri atferd. Utvidelsesrelasjoner brukes også til å modellere individuelle understrømmer som bare kjører under visse omstendigheter. Til slutt brukes de til å simulere flere strømmer som kan utløses på et tidspunkt i manuset som et resultat av eksplisitt interaksjon med skuespilleren.

Forlengelsesforholdet er avbildet som en avhengighet med stereotypen "utvide". Utvidelsespunktene for basisskript er oppført i en ekstra del. De er ganske enkelt etiketter som kan vises i flyten av den underliggende brukssaken.

Et eksempel på bruk av denne relasjonen kan være tilgang til en database med en operativ del og et arkiv. I dette tilfellet, hvis forespørselen er utstyrt med data fra den operative delen, utføres hovedtilgangen til dataene, hvis dataene fra den operative delen ikke er nok, får arkivdataene tilgang, det vil si at tilgangen er utført i henhold til det avanserte scenariet.

I vårt tilfelle, presedensen redigeringdata inkluderer brukstilfeller: inputdata, slettingdata, forandringendata.

Diagrammet over presedensene til AWP til sekretæren for avdelingen er vist i fig. 1.

Ris. 1. Diagram over presedensene til AWP til sekretæren for avdelingen

Presedens Søkstudent innebærer søk på etternavn og søk på resultater av akademiske prestasjoner.

Ved utforming av en visning med tanke på brukstilfeller er det ofte nødvendig å gi en utvidet beskrivelse av brukstilfellet (kun navnet er oppgitt i den forkortede versjonen). Vanligvis er flyten av hendelser i en use case beskrevet i tekstform i starten. Når du avgrenser systemkravene dine, vil det være mer praktisk å gå over til en grafisk representasjon av flyter i aktivitets- og interaksjonsdiagrammer.

Strømmer av hendelser kan beskrives ved hjelp av ustrukturert tekst, strukturert tekst (som inneholder tjenesteord: HVIS,FØRDEPORSAMTIDIG SOM etc.), et spesialisert formelt språk (pseudokode).

Når en use case skal beskrives som en flyt av hendelser, er det viktig å også utpeke hoved- og alternative flyter av systemets atferd.

Vurder for eksempel beskrivelsen av flyten av hendelser i brukssaken autorisasjon.

Grunnleggende strømme arrangementer. Brukssaken begynner når systemet ber brukeren om pålogging og passord. Brukeren kan legge den inn fra tastaturet. Oppføringen avsluttes med et tastetrykk. Tast inn. Etter det kontrollerer systemet det angitte påloggingsnavnet og passordet, og hvis de samsvarer med administratoren, bekrefter administratorens autoritet. Dette avslutter presedensen.

Eksepsjonell strømme arrangementer. Kunden kan når som helst avslutte transaksjonen ved å trykke på tasten Avbryt. Denne handlingen starter presedensen på nytt. Det er ingen inngang i systemet.

Eksepsjonell strømme arrangementer. Klienten kan slette påloggings- og passordet sitt når som helst før han trykker på Enter-tasten.

Eksepsjonell strømme arrangementer. Dersom klienten oppga Innlogging og passord som ikke samsvarer med administrator, tilbys han å gå inn på nytt eller logge inn i systemet som en ordinær bruker.

Åpenbart forutsetter beskrivelsen av et use case ved en strøm av hendelser en slags algoritme som kan representeres i et aktivitetsdiagram (fig. 2).

Algoritmediagrammet må inneholde start- og sluttpunktene, med bare én start og én slutt. Diagrammet inneholder kjørbare hjørner - aktiviteter (indikert med avrundede rektangler), betingede hjørner (beslutning - valg, gjenkjennelse, indikert med ruter) og lenker.

Lignende diagrammer kan forklare utførelsen av andre brukstilfeller, og dermed utfylle synet på systemet fra et brukstilfelles synspunkt.

Ris. 2. Brukerautorisasjon. Aktivitetsdiagram.

4.2 Utvikle en designvisning

Designsynet er hovedstadiet i den konseptuelle studien av modellen. På dette stadiet introduseres de grunnleggende abstraksjonene, klasser og grensesnitt defineres som løsningen av oppgavene implementeres gjennom. Hvis brukstilfellene bare erklærer systemets oppførsel, bestemmes det på stadiet for å utvikle utsikten fra designsynspunktet med hvilke midler disse brukstilfellene skal implementeres. Statiske aspekter av denne typen utvikles gjennom klassediagrammer, dynamiske - gjennom interaksjon og tilstandsdiagrammer (automater).

Klassediagrammer inneholder klasser, grensesnitt, samarbeid, samt forbindelser mellom dem. Utviklingen av et klassediagram bør begynne med definisjonen av klasser som tilsvarer hovedenhetene i systemet, som som regel bestemmes på de innledende stadiene av utviklingen når man beskriver fagområdet. Her er det nødvendig å bestemme hvilke enheter som er mer praktisk å modellere som klasser, og hvilke som deres attributter. For eksempel, hvis det var påkrevd innen fakultetet å angi leder for hver avdeling, ville det være bedre å spesifisere sjefStoler gjør det til et klasseattributt stol angir klassen lærere ( en-til-en forening ), heller enn å introdusere en egen klasse sjefStoler.

Ved modellering må det huskes at hver klasse må tilsvare en reell enhet eller konseptuell abstraksjon fra området som brukeren eller utvikleren har å gjøre med. En godt strukturert klasse har følgende egenskaper:

er en veldefinert abstraksjon av et konsept fra ordforrådet til problemområdet eller løsningsområdet;

inneholder et lite, veldefinert sett med ansvar og utfører hver av dem;

opprettholder et klart skille mellom abstraksjonsspesifikasjoner og implementeringen;

forståelig og enkel, men tillater samtidig utvidelse og tilpasning til nye oppgaver.

Som en del av utviklingen av modellen for den automatiserte arbeidsplassen til sekretæren for avdelingen, vil vi definere klassene: lærere, studenter, avgangselev, disipliner, gruppe... Det er klart at den første av dem har mange vanlige attributter, så la oss introdusere en abstrakt klasse NSEerson, som vil innkapsle alle menneskerelaterte egenskaper i sammenheng med systemet som utvikles (etternavn, fornavn, adresse osv.). I dette tilfellet en person vil være superklassen og kommunisere ved generisk relasjon med klassene lærere, studenter, avgangselev.

Egenskap adresse har sin egen struktur, for å reflektere det kan du introdusere en ekstra klasse, la oss kalle det T_ ADR(som det er vanlig i mange programmeringssystemer, begynner klassenavn med bokstaven T). Merk at attributtet adresse klasse en person er en forekomst av klassen T_ ADR, det vil si at det etableres et avhengighetsforhold mellom disse klassene (vist med en stiplet pil med åpen spiss, pilen er rettet fra den avhengige til den uavhengige). I vårt tilfelle, endre strukturen i klassen T_ ADR innebærer et klasseskifte en person gjennom strukturen til det tilsvarende attributtet ( adresse).

Når du modellerer en klasse T_ ADR Egenskap indeks satt ved hjelp av en primitiv type T_ POSTIDX, definert som et sekssifret desimaltall. Primitive typer er stereotype " type" , er verdiområdet spesifisert gjennom begrensningene omsluttet av krøllete klammeparenteser.

I klassen lærer la oss fremheve de spesifikke egenskapene som kun er relatert til læreren: posisjon, uch. grad(akademisk grad), uch. rang ( akademisk rangering), utslipp(kategori av en enkelt tariffskala). Egenskaper uch. grad og uch. rang det er bedre å definere spesialiserte typer via opplisting. Oppregninger er modellert av en klasse med stereotypen " enum" (oppregning - oppregning), tillatte verdier skrives som attributter, etiketter som bestemmer synligheten til attributter undertrykkes. I det betraktede eksemplet, gjennom oppregningen, introduserer vi spesialiserte klasser T_Må, T_UCHST, T_UchZv, henholdsvis definering av mulige stillinger, akademiske grader, akademiske titler gjennom overføringer. I dette tilfellet, som andre steder i lignende tilfeller, når du oppretter klasser som spesifiserer attributtene til hovedklassen, etableres avhengighetsrelasjoner.

For klassen student en spesifikk egenskap introduseres romrekordbøker... Spesifikke attributter er definert for doktorgradsklassen formenlæring og Datokvitteringer... Studieformen vil bli bestemt av en spesialklasse gjennom en oppregning T_FormObuch(fulltid deltid).

Klasse gruppe har attributter: tittel, formen læring, Nummerstud. ( antall studenter ). Med tanke på at lærerne ved det aktuelle instituttet kan undervise grupper fra andre fakulteter, innføres en ekstra klasse spesialitet, med attributter rom(spesialiteter), tittel(spesialiteter ), fakultet hvis typer ikke er spesifisert i denne modellen, selv om de kan bestemmes gjennom oppregninger.

Klasse disiplin har attributter: rom, tittel, syklus. Egenskap syklus ved hjelp av en spesialisert type introdusert gjennom en oppregning T_Sykluser bestemmer hvilken syklus disiplinen tilhører: syklusen av humanitære og sosioøkonomiske disipliner, matematiske og naturvitenskapelige disipliner, generelle fagdisipliner, spesielle disipliner.

Egenskaper Nummertimer, Nummersemestre kan ikke spesifiseres i klassen disiplin, siden de er avhengige av spesialitet, jo mer kan du ikke angi dem i klassen spesialitet... Disse attributtene er relatert til spesialitet-disiplin-paret og er definert i klasse - assosiasjonen Disipliner-spesialiteter.

Ris. 3. Klassediagram av AWP til sekretæren for avdelingen (alternativ 1)

Når du gjengir en klassestruktur, vær oppmerksom på synligheten til attributtene. Alle vurderte attributter må være tilgjengelige og ha synligheten offentlig (angitt med et "+"-tegn eller et ikon uten hengelås). I de betraktede klassene fokuserte vi på struktur i stedet for atferd (operasjoner ble ikke beskrevet og skal ikke beskrives), derfor, for å gjøre diagrammet lettere å lese, er det ønskelig å undertrykke operasjonene.

På det introduserte settet med klasser er det nødvendig å omdefinere koblingene. Sammenhengene mellom generalisering og avhengigheter er allerede bestemt, det gjenstår å definere assosiasjonene.

Studenter dannet i gruppe, i dette tilfellet vil foreningen være i form av aggregering. Aggregering forutsetter et del-helt forhold, angitt med en heltrukket linje med en rombe på slutten fra hele siden (i vårt tilfelle gruppe). Flertallet av mange-til-en student-gruppe relasjoner. Hver gruppe refererer til en bestemt spesialiteter, på sin side kan flere grupper tilsvare en viss spesialitet, derfor har gruppe-spesialitetsforeningen også typen mangfold "mange til en".

I dette tilfellet, som i de fleste andre, er retningen til assosiasjoner toveis, så det er bedre å undertrykke navigasjon (fjern merket for Navigerbar-feltet i alternativet Detaljrolle)

La oss definere en assosiasjon mellom lærere og underviste disipliner som "mange-til-mange": en lærer kan undervise i flere disipliner, noen disipliner kan undervises av flere lærere. Mellom disipliner og spesialiteter foreningen «mange-til-mange» er også etablert: pensum for spesialiteter inneholder mange disipliner, de fleste disipliner finnes i arbeidsplanene til flere spesialiteter. Foreningsklassen er knyttet til denne foreningen. Disipliner-spesialiteter med attributter som angir emnet, antall semestre og antall timer i en gitt disiplin i en gitt spesialitet.

På samme måte introduserer vi en assosiasjon mellom i grupper og lærere: Lærere underviser i grupper, multi-til-mange foreningstype. Direkte assosiasjon mellom i grupper og disciplins du trenger ikke å definere, siden dette forholdet spores gjennom binderklassen spesialitet.

For å vise tilstedeværelsen av en veileder for en hovedfagsstudent, er det nødvendig å innføre en assosiasjon mellom en hovedfagsstudent og en lærer av typen "mange-til-en"; en veileder kan ha flere hovedfagsstudenter. På denne assosiasjonen fra lærerens side kan du eksplisitt angi rollen: veileder.

Ris. 4. Diagram over klasser av AWP til sekretæren for avdelingen (alternativ 2)

I hver gruppere det er en gruppeleder, dette faktum kan vises av en ekstra forening (la oss gi den et navn rektor) fra gruppe til elever med typen multiplisitet «en til en». I dette tilfellet kan du spesifisere navigasjonen eksplisitt.

Hovedfagsstudenter kan også lære spesifikke disipliner til spesifikke grupper: mange-til-mange foreninger hovedfagsgrupper, postgraduate disipliner. Noen doktorgradsstudenter underviser kanskje ikke, så multiplisitetstypen i enden av foreningen vil være 0. n.

Det endelige klassediagrammet er vist i fig. 3.

Ris. 5. Forenklet klassediagram

Med tanke på at både hovedfagsstudenter og lærere underviser, kan en ekstra abstrakt klasse introduseres, f.eks. undervisning som er en etterkommer av klassen en person og en superklasse for klassene lærer og utdannet student, noe som vil redusere antall tilkoblinger noe. (fig. 4.). I dette tilfellet fra klassene disiplin og gruppe foreninger vil gå til klassen undervisning, forutsatt en kobling til klassene lærer og utdannet student gjennom arv (generaliseringsforhold). Til klassen undervisning du kan ta ut attributtene bud(0,5 sats, full sats) og utslipp.

Det resulterende diagrammet er ganske komplekst og lastet med elementer, men modelleringen av klassene er langt fra komplett: noen verktøyklasser og grensesnitt må fortsatt defineres. For å laste ut klassediagrammet, vil vi konstruere en ny visning av det (på et eget diagram), forlate bildet av hovedklassene og undertrykke visningen av hjelpesystemer som bestemmer typene attributter (fig. 5).

I fig. 5, sammen med hovedklassene som tilsvarer de konseptuelle elementene i systemet, vises også klassen T_ ADR, som avslører strukturen til adressen, er denne klassen også viktig, siden den inneholder de nødvendige dataelementene for lærere og avgangselev- etterkommere av klassen en person.

La oss gå videre til å definere grensesnittene. Klasser samhandler med omverdenen gjennom grensesnitt.

Grensesnitt (Grensesnitt) er en samling operasjoner som definerer en tjeneste (sett med tjenester) levert av en klasse eller komponent. Dermed beskriver et grensesnitt den eksternt synlige oppførselen til et element. Et grensesnitt kan representere oppførselen til en klasse eller komponent helt eller delvis; den definerer kun spesifikasjonene for operasjonene (signaturer), men aldri implementeringen av dem. Det grafiske grensesnittet er avbildet som en sirkel som navnet hans er skrevet under. Et grensesnitt eksisterer sjelden alene - det er vanligvis knyttet til en implementeringsklasse eller komponent. Grensesnittet forutsetter alltid at det eksisterer en slags "kontrakt" mellom parten som erklærer utførelsen av en rekke operasjoner og parten som gjennomfører disse operasjonene.

Plasser klassen på diagrammet elektroniskbord, som innkapsler alle egenskapene og operasjonene til regnearket som lar deg redigere dataene. Vi vil ikke avsløre strukturen til denne klassen på grunn av dens store kompleksitet. Så, i moderne applikasjonsutviklingsverktøy, bruker brukeren ferdige klasser og maler, og arver evnene deres, for eksempel inneholder VCL-biblioteket (Delphi) en TTable-klasse som innkapsler egenskapene til et regneark. Etterkommere av klassen elektroniskbord er spesifikke regneark som inneholder spesifikke data for fakultetet, hovedfagsstudenter, studenter, grupper, disipliner og spesialiteter. Ved å gjøre de tilsvarende klassene til etterkommere av klassen elektroniskbord, vi erklærer for disse klassene alle egenskapene og operasjonene som ligger i regneark (registrering i systemet, innsetting, sletting, dataredigering, sortering, etc.).

For klassen elektroniskbord, og følgelig definerer vi grensesnittet for alle dens etterkommere redigering, antyder alle mulige dataredigeringsoperasjoner (sett inn, slett, endre data). I dette tilfellet er det antatt at i klassen elektroniskbord disse mulighetene implementeres.

Bruke en tilpasset klasse elektroniskbord og arv unngikk å definere spesielle egenskaper og dataredigeringsgrensesnitt for hvert regneark.

La oss definere grensesnittene Søklærer, Søkdisipliner ved å knytte dem til sine respektive klasser med et implementeringsforhold. Vi vil ikke avsløre sammensetningen av operasjonene til disse grensesnittene (det er ganske trivielt), derfor vil vi vise grensesnittene i en forkortet form (i form av en sirkel). Husk at et implementeringsforhold knyttet til et grensesnitt i forkortet form vises som en enkel heltrukket linje (som en assosiasjon).

Grensesnitt Søkstudent vil vises med en indikasjon på listen over operasjoner gjennom en stereotyp klasse, mens implementeringsrelasjonen vises med en stiplet pil med en lukket spiss.

Naturligvis antas det at de introduserte grensesnittene er implementert ved hjelp av klassene de er knyttet til av implementeringsrelasjonen, det vil si at de tilsvarende klassene inneholder operasjoner og metoder som implementerer de deklarerte grensesnittene. For å lette oppfatningen blir ikke disse mekanismene visualisert.

For å administrere tilgangsrettigheter og brukerautorisasjon introduserer vi klassen sjefadgang... Tilgangsbehandlingen har et attributt for privat tilgangstype bordpassord som er en forekomst av klassen Kodirtabell(Kodet tabell) som inneholder passord ( passord) og skriv inn navn ( Logg Inn) av administratorbrukere. Det antas at tjenesteklassen evner Kodirtabell ikke la en uautorisert bruker lese brukerpassord. På dette stadiet av designet erklærer vi ganske enkelt slike evner, ikke dveler ved mekanismen for implementeringen, men forutsetter at de er innkapslet i en klasse Kodirtabell.

Klasse sjefadgang inneholder åpne transaksjoner inputpassord og tildeling av administratorrettigheter, ved hjelp av hvilke autorisasjon og administrasjon av tilgangsrettigheter realiseres.

La oss indikere avhengigheten mellom dataredigeringsgrensesnittet ( redigering) og en tilgangsbehandler, forutsatt at bare brukere med administratorrettigheter har fulle dataredigeringsmuligheter.

Ris. 6. Det endelige diagrammet over klassene til AWP til sekretæren for avdelingen

Det endelige diagrammet er vist i fig. 6.

Så på dette stadiet kan utviklingen av en objektorientert modell av arbeidsstasjonen til sekretæren for avdelingen ved hjelp av UML klassediagram betraktes som komplett. Naturligvis er det mulig å gå tilbake til det og revidere noen elementer under utformingen av systemet, når du justerer oppgaver, når du spesifiserer individuelle detaljer. Ier iterativ. Det skal bemerkes at det utviklede klassediagrammet inneholder elementer som eksplisitt eller implisitt implementerer alle use case-diagrammet. Hvert brukstilfelle av et use case-diagram må tilsvare enten et grensesnitt eller en grensesnittoperasjon (implementering antas i klassene som tilsvarer grensesnittet), eller en offentlig operasjon av klassen, eller et sett med offentlige operasjoner (i dette tilfellet, brukstilfellet implementeres direkte av den tilsvarende klassen eller settet med klasser).

La oss se på prosessen med å lage en ny studentpost ved hjelp av et sekvensdiagram.

Å opprette en ny post forutsetter administratorrettigheter, så administratoren vil være hovedpersonen i denne interaksjonen ( admin). Dette elementet er allerede lagt inn i use case-diagrammet, så dra det til sekvensdiagrammet fra use case view-nettleseren.

Det skal bemerkes at objekter vises i interaksjonsdiagrammer, det vil si konkrete forekomster av klasser (navnet på et objekt er alltid understreket).

Vi administrerer objekter: formeninput, sjefposter, studentrekord Petrov(som et konkret eksempel på studentrekord), sjeftransaksjoner... Dette settet med objekter er typisk når du endrer en post i en databasetabell.

Formeninput- et element i brukergrensesnittet, som er en typisk form for å legge inn data om en student (etternavn, fornavn, patronym, adresse osv.). I vårt tilfelle er det en noe utvidet konkret implementering av standardgrensesnittet redigering klasse elektroniskbord. Siden vi ikke spesifikt introduserte grensesnittet for redigering av elevdata på klassediagrammet, spesifiser derfor klassen for objektet eksplisitt formeninput vi vil ikke.

sjefposter- et objekt som har et standard sett med databehandlingsfunksjoner når du arbeider med et regneark. Dette settet med evner arves av klassen studenter fra klassen elektroniskbord... For objekt sjefposter klassen det er en forekomst av er eksplisitt angitt - studenter.

Petrov- en spesifikk rekord om student Petrov, et nytt element i tabellen om studenter. Her angir vi eksplisitt den introduserte klassen innspillingOstudent... Slike objekter eksisterer vanligvis midlertidig for å sende relevant informasjon til databasen under transaksjoner. Etter slutten av transaksjonen kan dette objektet bli ødelagt. Objektet som tilsvarer posten kan opprettes på nytt hvis det er nødvendig å redigere informasjonen.

sjeftransaksjoner- et objekt som sikrer utførelsen av en fullført operasjon på databasen, i dette tilfellet opprettelsen av en ny post om studenten Petrov. Dette objektet er også ansvarlig for å utføre en rekke systemfunksjoner som følger med transaksjonen. Eksempler på transaksjonsbehandlere er for eksempel BDE (brukes for å få tilgang til Paradox, Dbase, etc. databaser fra Delphi-applikasjoner), ADO (brukes for å få tilgang til MS Access-databaser fra ulike applikasjoner).

Sekvensdiagrammet for å legge inn en ny post om en student i AWS til avdelingssekretæren er vist i fig. 7.

Ris. 7. Legge inn elevdata. Sekvensdiagram.

I sekvensdiagrammet definerer vi overføringen av meldinger mellom objekter: skapenyinnspilling(kringkastes fra objekt til objekt til slutten av kjeden som en melding lagreinnspilling); åpenform(til inndataskjemaet); å introdusereF.OG OM.,adresse. ( elevdataregistrering), så kringkastes disse dataene via meldinger lagreF.OG OM.,adresse. Fra sjeftransaksjoner send melding samle informasjonOstudent gi tilbakemelding til databasen, og til slutt en refleksiv melding sjeftransaksjoner navngitt som lagreinnspillingvDB, sikrer slutten av transaksjonen.

Om ønskelig kan denne interaksjonen representeres av et samarbeidsdiagram, som først og fremst illustrerer det strukturelle aspektet ved interaksjonen (fig. 8). Dette diagrammet kan bygges fra det forrige i automatisk modus (i Rational Rose ved å trykke på F5-tasten).

Ris. 8. Legge inn elevdata. Samarbeidsdiagram.

Om nødvendig kan prosjektet suppleres med andre interaksjonsdiagrammer som avslører arbeidet med brukssaker.

4.3 Utvikle en relasjonsdatabaseprofil

I tilfelle det brukes en objektorientert DBMS (OODBMS) for å implementere systemet, er objektdiagrammet konstruert i forrige seksjon den endelige modellen og en direkte guide til implementeringen av informasjonssystemet. I samme tilfelle, når en relasjonsdatabase (RDB) skal brukes som informasjonskjernen i et informasjonssystem, er det nødvendig å utvikle et annet diagram, et profildiagram av en relasjonsdatabase.

UML-profilen for et databaseprosjekt er en UML-utvidelse som holder UML-metamodellen intakt. Profilen for et databaseprosjekt legger til stereotyper og merkede verdier som er lagt til disse stereotypene, men endrer ikke den underliggende UML-metamodellen. For å visualisere de utformede databaseelementene og designreglene for relasjonsdatabaser, er de tilsvarende ikonene lagt til profilen (heretter ganske enkelt databaser). Databasen beskrives ved hjelp av tabeller, kolonner og relasjoner. Profilen inneholder elementer som utvider databasen, for eksempel triggere, lagrede prosedyrer, begrensninger, brukerdefinerte typer (domener), visninger og andre. Profilen viser hvordan og hvor du skal bruke alle disse elementene i modellen. Følgende enheter er definert på UML-databaseprofilen:

bord ( Tabell) - et sett med poster i databasen for et bestemt objekt, består av kolonner.

Kolonne ( Column) er en tabellkomponent som inneholder en av tabellattributtene (tabellfeltet).

Hoved nøkkel ( Primærnøkkel) - en mulig nøkkel valgt for å identifisere tabellrader.

Utvendig nøkkel ( Fremmednøkkel) - en eller flere kolonner i en tabell, som er primærnøklene til en annen tabell.

Opptreden ( View) er en virtuell tabell som oppfører seg fra brukerens synspunkt akkurat som en vanlig tabell, men som ikke eksisterer alene.

Lagret fremgangsmåte ( Lagret prosedyre) er en uavhengig prosedyrefunksjon som utføres på serveren.

Domener ( Domains) er et gyldig sett med verdier for et attributt eller kolonne.

I tillegg til disse enhetene, kan noen tilleggsenheter introduseres som gjenspeiler spesifikke aspekter ved databasemodellen.

Lignende dokumenter

Metoder for utvikling av informasjonssystemer i innenlandsk og utenlandsk litteratur. Statlige og internasjonale standarder innen programvareutvikling. Utvikling av et fragment av det pedagogiske-metodiske ressursinformasjonssystemet.

semesteroppgave, lagt til 28.05.2009


Definisjon av begrepet "system". Historien om utvikling og funksjoner i moderne informasjonssystemer. Hovedstadiene i utviklingen av et automatisert informasjonssystem. Bruk av nasjonale og internasjonale standarder innen informasjonssystemer.

presentasjon lagt til 14.10.2013


Hovedideen til metodikken og prinsippene for RAD-utvikling av informasjonssystemer, dens viktigste fordeler. Årsaker til populariteten, funksjonene til teknologiapplikasjonen. Formulering av de grunnleggende prinsippene for utvikling. Utviklingsmiljøer ved bruk av RAD-prinsipper.

presentasjon lagt til 04/02/2013


Ledelsesstrukturens rolle i informasjonssystemet. Eksempler på informasjonssystemer. Struktur og klassifisering av informasjonssystemer. Informasjonsteknologi. Stadier av informasjonsteknologiutvikling. Typer informasjonsteknologi.

semesteroppgave lagt til 17.06.2003


Konseptet med CASE-verktøy som programvareverktøy som støtter oppretting og vedlikehold av informasjonssystemer (IS). Funksjoner ved IDEF-teknologi for IS-utvikling. Beskrivelse av IDEF0-notasjon. Utvikling av funksjonelle modeller for en forretningsprosess.

presentasjon lagt til 04.07.2013


Essensen av det enhetlige modelleringsspråket, dets konseptuelle modell og operasjonsprinsipp, generelle regler og mekanismer. Modellering av begrepet "kompetanse". Klassediagram som beskriver utdanningsprosessen. Implementering av et gitt informasjonssystem.

avhandling, lagt til 17.02.2015


Utvikling av informasjonssystemer. Det moderne markedet for finansiell og økonomisk anvendt programvare. Fordeler og ulemper ved å implementere automatiserte informasjonssystemer. Metoder for utforming av automatiserte informasjonssystemer.

avhandling, lagt til 22.11.2015


Konseptet med et informasjonssystem, typer informasjonssystemer. Analyse av verktøy for utvikling av automatiserte informasjonssystemer. Krav til programmet og programvareproduktet. Utvikling av former for grafisk grensesnitt og databaser.

avhandling, lagt til 23.06.2015


Informasjonssikkerhetsløsning. Systemer for datasentre. Hva er maskinvare for datasenter. Grunnleggende konsepter og prinsipper for modellering. Valg av metode for å løse problemer. Zoitendijk-metoden for tillatte retninger, Frank – Wolfe-algoritmen.

semesteroppgave lagt til 18.05.2017


Informasjonssystemkonsept. Stadier i utviklingen av informasjonssystemer. Prosesser i informasjonssystemet. Informasjonssystem for å finne markedsnisjer, for å redusere produksjonskostnader. Strukturen til informasjonssystemet. Teknisk støtte.

UDDANNINGSDEPARTEMENTET FOR DEN RUSSISKE FØDERASJON ULYANOVSK STATE TECHNICAL UNIVERSITY V.S. SCHKLEIN MODELLERING AV INFORMASJONSSYSTEMER Forelesningsnotater for studenter med retning 652100 "Aircraft construction" University of Shcheklein V.S. Щ Modellering av informasjonssystemer: forelesningsnotater / V.S. SHCHEKLEIN. - Ulyanovsk: UlSTU, 2002 .-- s. Forelesningsnotatene er et utvalg stoff som ble brukt i studieåret 1999/2000 ved gjennomføring av undervisning i faget "Information Systems Modeling". Den er beregnet på studenter med spesialisering: 130107 "Programvarebehandling av byggematerialer" og 130111 "Prosjektledelse av flyproduksjon". Denne håndboken er ikke komplett, det er planlagt å inkludere nyutviklet materiale, hvis valg og utforming utføres i samsvar med det godkjente fagprogrammet. 3 INNHOLD INTRODUKSJON ……………………………………………… .. IMPLEMENTERINGEN VED BRUK AV EN DATAMASKIN ………………… 7 3. GENERALISEREDE STATISTISKE MODELLERINGSALGORITIMER ………………………… ………………………………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………………………………… ………………………… 9 DISTRIBUSJON. SIMULERING AV TILFELDIGE HENDELSER ………………………………………………………… .. 5. TILNÆRING TIL SIMULERING AV SYSTEMER ………………………… ... 15 6. INNSTILLING AV TILFELDIGE VERDIER OG TILFELDIGE HENDELSER I EXCEL ...................... 23 8. MODELLERING AV MASSETJENESTESYSTEMER. 25 9. Struktur av informasjon og databehandling systematisk TEM ........................................ ........................................ 26 9.1. Konseptet med prosessen ………………………………………… .. 28 9.2. Arbeidsmengde ………………………………………………… 29 10. INFORMASJONSSYSTEMETS YTELSEINDIKATORER ………………………………………………………………… ……… .. 30 11. ESTIMERING AV YTELSE TIL SYSTEMKOMPONENTER ………………………………………………………………………….…. 31 12. VURDERING AV SYSTEMYTELSE GENERELT ……. 32 13. PÅVIRKELSEN AV DATABEHANDLINGSMODUS ………………………… .. 35 14. PÅLITELIGHETS- KARAKTERISTIKA ………………………………………………………………………… ………………………………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………………………… .. … ………………………………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………………………………… …………………………………………………………………………………………………. ” …………………. 40 REFERANSER …………………………………………. 46 4 INNLEDNING Nytten av matematisk modellering for å løse praktiske problemer reiser ikke tvil i det hele tatt. Spørsmålet kan oppstå, hvorfor er det nødvendig å mestre modelleringen av informasjonssystemer (og nå kan disse systemene ikke tenkes uten datateknologi) for flybyggere med fokus på teknologien for flyproduksjon? Moderne teknologi blir mer og mer automatisert. En moderne flyprodusent, enten han er designer eller teknolog, må bruke datamaskiner i sitt arbeid. Det er fare for en mangelfull vurdering av datamaskinens muligheter ved løsning av tekniske problemer. Dette kan enten føre til et avslag på å automatisere et eller annet fragment av den teknologiske prosessen, eller til uberettigede utgifter til datautstyr, hvis evner er sterkt overvurdert sammenlignet med de nødvendige. I dette tilfellet kan såkalt sunn fornuft føre til alvorlige feil i vurderingen. Målet med disiplinen er å utstyre en ung spesialist med et apparat for å evaluere informasjon og datasystemer slik at han kan tilpasse automatiseringsmidler riktig inn i konturene av produksjon eller ledelse. I tillegg, ved å modellere visse systemer, får studentene indirekte erfaring med å optimalisere systemer og forsterke ferdighetene til å bruke en datamaskin til å løse profesjonelle problemer. 1. GRUNNLEGGENDE BEGREPP I MODELLERINGSTEORIEN Modellering er å erstatte ett objekt med et annet for å få informasjon om de viktigste egenskapene til objektet - originalen ved hjelp av objektet - modellen. Modell (fransk modele fra latin modulas - mål, prøve): 1) en prøve for masseproduksjon av et produkt; produkt merkevare; 2) produktet som skjemaet er fjernet fra (maler, mønstre, plasser); 3) personen eller gjenstanden som er avbildet av kunstneren; 4) en enhet som gjengir strukturen eller handlingen til enhver annen enhet; 5) ethvert bilde av et objekt, en prosess eller et fenomen brukt som en representant for originalen (bilde, diagram, tegning, kart); 6) det matematiske apparatet som beskriver et objekt, en prosess eller et fenomen; 7) en anordning for å få et avtrykk i en støpeform. I det følgende, med mindre annet er angitt, vil modellen bli forstått som et matematisk apparat. Alle modeller har en viss struktur (statisk eller dynamisk, materiell eller ideell), som ligner strukturen til det originale objektet. I arbeidsprosessen fungerer modellen som et relativt uavhengig kvasi-objekt, noe som gjør det mulig å oppnå en viss kunnskap om selve objektet under forskning. Hvis resultatene av en slik studie (modellering) bekreftes og kan tjene som grunnlag for prognoser i objektene som studeres, så sier de at modellen er tilstrekkelig for objektet. I dette tilfellet avhenger modellens tilstrekkelighet av formålet med modelleringen og de vedtatte kriteriene. Modelleringsprosessen forutsetter tilstedeværelsen av: - objektet for forskning; - en forsker med en spesifikk oppgave; - en modell laget for å få informasjon om et objekt som er nødvendig for å løse et problem. I forhold til modellen er det forskeren som er eksperimentatoren. Det bør huskes at ethvert eksperiment kan være av betydelig betydning i et spesifikt område av vitenskap og teknologi bare med en spesiell behandling av resultatene. En av de viktigste aspektene ved systemmodellering er målproblemet. Enhver modell bygges avhengig av målet satt av forskeren, derfor er et av hovedproblemene i modellering måloppdragsproblemet. Likheten mellom prosessen som forløper i modellen og den virkelige prosessen er ikke et mål i seg selv, men en betingelse for riktig funksjon av modellen. Som et mål bør oppgaven med å studere ethvert aspekt av funksjonen til objektet settes. Hvis målene med modellering er klare, oppstår det neste problemet, problemet med å bygge en modell. Denne konstruksjonen viser seg å være mulig dersom det er informasjon eller det fremsettes hypoteser om strukturen, algoritmene og parameterne til det undersøkte objektet. Det bør understrekes rollen til forskeren i prosessen med å bygge en modell, denne prosessen er kreativ, basert på kunnskap, erfaring, heuristikk. Formelle metoder som tillater en tilstrekkelig nøyaktig beskrivelse av et system eller prosess er ufullstendige eller rett og slett fraværende. Derfor er valget av denne eller hin analogien helt basert på erfaringen til forskeren, og forskerens feil kan føre til feilaktige simuleringsresultater. Når modellen er bygget, kan neste problem betraktes som problemet med å jobbe med den, implementeringen av modellen. Her er hovedoppgavene å minimere tiden for å oppnå de endelige resultatene og sikre deres pålitelighet. For en riktig konstruert modell er det karakteristisk at den bare avslører de regelmessighetene som er nødvendige av forskeren, og ikke vurderer egenskapene til systemet - originalen, som er ubetydelige i det gitte øyeblikket. Klassifiseringen av typer systemmodellering er vist i fig. 1.1. Matematisk modellering er konstruksjon og bruk av matematiske modeller for å studere oppførselen til systemer (objekter) under ulike forhold, for å oppnå (beregne) visse egenskaper ved originalen uten å ta målinger eller med et lite antall av dem. Innenfor rammen av matematisk modellering har det utviklet seg to tilnærminger: - analytisk; - imitasjon. 6 Systemmodellering Deterministisk Stokastisk Statisk Dynamisk Diskret Diskret Kontinuerlig Abstrakt Material Visuelt Symbolisk Matematisk Naturlig Fysisk Analytisk kombinert. Simulering Fig. 1.1. Den analytiske tilnærmingen er basert på konstruksjonen av formelavhengigheter som forbinder parametrene og elementene i systemet. I lang tid var denne tilnærmingen faktisk en matematisk tilnærming. Men når man vurderer komplekse systemer, er strenge matematiske avhengigheter veldig komplekse; et stort antall målinger kreves for å oppnå de nødvendige verdiene til parameterne. Analyse av egenskapene til prosessene for funksjon av komplekse systemer ved bruk av bare analytiske forskningsmetoder møter betydelige vanskeligheter, noe som fører til behovet for å forenkle modellene betydelig enten på konstruksjonsstadiet eller i ferd med å jobbe med en modell, noe som reduserer modellene. påliteligheten til resultatene. Simulering (statistisk) tilnærming til modellering er basert på bruken av Chebyshev-grensesetningen i den sannsynlige representasjonen av systemparametrene. På grunnlag av en foreløpig studie av det modellerte systemet er det ganske enkelt å bestemme typene og verdiene til distribusjonslovene for de tilfeldige verdiene til parameterne. Innenfor rammen av simuleringstilnærmingen benyttes analytiske avhengigheter mellom parameterne til systemelementene, men disse avhengighetene er av mer generalisert, forenklet karakter. De er mye enklere enn avhengigheter i den analytiske tilnærmingen. 7 Matematisk modellering av systemer, inkludert informasjonssystemer, er rettet mot å optimalisere strukturen til systemene, velge de mest optimale funksjonsmåtene til systemene, bestemme de nødvendige egenskapene til maskinvare og programvare. Matematisk modellering av teknologiske prosesser, inkludert informasjonsprosesser, har som hovedmål å finne de optimale eller akseptable egenskapene til selve objektet, finne de optimale prosesseringsmodusene, trene personell og gi visse kontrollfunksjoner. I alle fall må modelleringen oppfylle følgende krav: - modellene må være tilstrekkelige til de tilsvarende systemene eller teknologiske oppgaver; - den nødvendige nøyaktigheten må sikres; - brukerens bekvemmelighet - en spesialist i teknologi eller informasjonsbehandling (administrasjon) - bør sikres: - et forståelig grensesnitt for modelleringsstyring; - tilstrekkelig hastighet på arbeidet; - synlighet av resultatene; - akseptable kostnader ved utvikling og bruk av simuleringsverktøy. 2. ESSENS I METODEN FOR STATISTISKE TESTER OG IMPLEMENTERING AV DEN VED HJELP AV EN DATAMASKIN Metoden for statistisk modellering består i å reprodusere prosessen som studeres ved å bruke en sannsynlig matematisk modell og beregne egenskapene til denne prosessen. Metoden er basert på gjentatt testing av den konstruerte modellen med påfølgende statistisk behandling av dataene som er oppnådd for å bestemme egenskapene til prosessen som vurderes i form av statistiske estimater av dens parametere. Tenk på ligningen: y = f (x, t, ξ), (2.1) hvor y er en systemparameter som skal bestemmes, x er en fasevariabel, t er tid, ξ er en tilfeldig parameter, hvis distribusjonslov er kjent for oss. Hvis funksjonen f i hovedsak er ikke-lineær, er det ingen universelle løsningsmetoder for å løse dette problemet, og tilstrekkelig fullt utviklede vanlige metoder for å finne optimale løsninger kan bare brukes ved å plassere synligheten ved bruk av matematikk i forkant; forenklinger vil føre til en alvorlig tap av nøyaktighet. Den matematiske modellen vil bli utilstrekkelig 8 for systemet som studeres, og modellering vil kun være en form for vrangforestillinger. Men hvis det er mulig å konstruere en funksjon y = ϕ (ξ) og en generator av tilfeldige tall ξ 1, ξ 2, ..., ξ N med en gitt distribusjonslov, så kan verdien av y beregnes som y = ∑ ϕ (ξ i) N, (2.2) hvor ϕ (ξ 1) er verdien av den i-te realiseringen. Hvis f (x, t, ξ) er en analytisk modell av infoeller den teknologiske prosessen med å behandle en del, så vil ϕ (ξ) være en statistisk modell. Noen prinsipper og teknikker for å konstruere statistiske modeller vil bli diskutert senere. Det er viktig at når du konstruerer funksjonen y = ϕ (ξ) og generatoren av tilfeldige tall ξ 1, ξ 2, ..., ξ N på papir, er det i det overveldende flertallet av tilfellene ganske enkelt å implementere dem på en datamaskin med riktig programvare. I dette tilfellet vil resultatene inneholde en feil, men denne feilen er mindre enn feil på grunn av forutsetninger i den analytiske modellen. I tillegg kan feilen på grunn av bruken av den statistiske modellen kvantifiseres. Denne teknikken utvides til mer kompliserte tilfeller, når ligning (2.1) inneholder ikke bare tilfeldige parametere, men også tilfeldige funksjoner. Etter å ha mottatt N realisasjoner på en datamaskin, følger stadiet med å behandle statistikk, som gjør det mulig å beregne, sammen med den matematiske forventningen (2.2), andre parametere ϕ (ξ), for eksempel variansen D = 1 N * ∑ xi - 1 N 2 * (∑ xi). I metoden for statistiske tester, for å oppnå tilstrekkelig pålitelige resultater, er det nødvendig å gi et stort antall realiseringer N, i tillegg, med en endring i minst en innledende parameter av problemet, er det nødvendig å utføre en serie av N tester igjen. Med komplekse modeller kan en urettmessig stor verdi av N bli en faktor som forsinker mottak av resultatet. Derfor er det viktig å vurdere det nødvendige antallet resultater riktig. Konfidensintervall ε, konfidenssannsynlighet α, varians D og antall realisasjoner N er relatert ved forholdet ε = D NФ −1 (α), hvor Ф −1 (α) er den inverse funksjonen til Laplace-funksjonen. I praksis kan du bruke forholdet N ≤ D ε 2 * 6,76 for α ≥ 0,99, og ta, for pålitelighetens skyld, den største verdien av N fra forholdet (). Et estimat av variansen D kan fås på forhånd ved bruk av samme statistiske modell for antall realisasjoner 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 . Если задать его слишком большим - теряется точность, слишком малым - возрас- тает время моделирования. На основе базовых схем моделирования можно строить комбинирован- ные и диалоговые схемы, в которых моделирование идет под контролем опе-

"Datamatisk matematisk modellering" Mål med å studere seksjonen. Mestring av modellering som en metode for å erkjenne den omkringliggende virkeligheten (seksjonens vitenskapelige forskningskarakter) - det vises at modellering innen ulike kunnskapsfelt har lignende trekk, ofte for ulike prosesser er det mulig å oppnå svært like modeller; - demonstrerer fordeler og ulemper ved et dataeksperiment sammenlignet med et fullskalaeksperiment; - det vises at både den abstrakte modellen og datamaskinen gir en mulighet til å erkjenne omverdenen, kontrollere den i menneskets interesse. Utvikling av praktiske ferdigheter i datamodellering. Den generelle metodikken for matematisk datamodellering er gitt. På eksemplet med en rekke modeller fra ulike felt av vitenskap og praksis, implementeres praktisk talt alle stadier av modellering, fra formuleringen av problemet til tolkningen av resultatene oppnådd i løpet av et dataeksperiment. Fremme yrkesveiledning for studenter. Å avsløre studentens evne til forskningsaktiviteter, utvikling av kreativt potensial, orientering mot valg av profesjon knyttet til vitenskapelig forskning. Overvinne fagdissosiasjon, kunnskapsintegrasjon. Emnet undersøker modeller fra ulike vitenskapsfelt ved hjelp av matematikk. Utvikling og profesjonalisering av datakunnskaper. Mestring av programvare for generelle og spesialiserte formål, programmeringssystemer.

Oppgaver og funksjoner til informasjonssystemet.

IS kan løse to grupper problemer. Den første gruppen er knyttet til ren informasjonsstøtte for hovedaktiviteten (valg av nødvendige meldinger, deres behandling, lagring, søk og levering til emnet for hovedaktiviteten med en forhåndsbestemt fullstendighet, nøyaktighet og effektivitet i den mest akseptable formen). Den andre gruppen av oppgaver er knyttet til behandlingen av den mottatte informasjonen / dataene i samsvar med visse algoritmer for å forberede løsninger på oppgavene som står overfor emnet for hovedaktiviteten. For å løse slike problemer må IS ha nødvendig informasjon om fagområdet. For å løse slike problemer må IS ha en viss kunstig eller naturlig intelligens. Informasjonssystem - et system for å støtte og automatisere intellektuelt arbeid - søk, administrasjon, ekspertise og ekspertvurderinger eller vurderinger, beslutningstaking, ledelse, anerkjennelse, kunnskapsoppbygging, opplæring. Oppgavene til den første gruppen er oppgavene med informatisering av samfunnet "i bredden".

Oppgaver til den andre gruppen - oppgaver med informatisering

samfunnet "dypt".

For å løse de tildelte oppgavene, bør IS utføre følgende funksjoner:

 utvalg av meldinger fra det interne og eksterne miljøet, nødvendig for gjennomføringen av hovedaktiviteten;

 input av informasjon til IS;

 lagre informasjon i minnet til IS, oppdatere den og opprettholde dens integritet;

 behandle, søke og utstede informasjon i samsvar med kravene satt av ODS. Behandling kan også inkludere utarbeidelse av alternativer for å løse brukeranvendte problemer.

Informasjonssystem (IS) er et sammenkoblet sett med verktøy, metoder og personell som brukes til å lagre, behandle og utstede informasjon for å nå det fastsatte målet. Den moderne forståelsen av informasjonssystemet innebærer bruk av en personlig datamaskin som det viktigste tekniske middelet for informasjonsbehandling. En IS er et miljø, hvis bestanddeler er datamaskiner, datanettverk, programvareprodukter, databaser, mennesker, ulike typer teknisk og programvarekommunikasjon, etc. Selv om selve ideen om IP og noen prinsipper for deres organisasjon oppsto lenge før bruken av datamaskiner, økte imidlertid databehandling effektiviteten til IP med titalls og hundrevis av ganger og utvidet omfanget av deres anvendelse.

Informasjonssystemets funksjonelle struktur.

I IS er det tilrådelig å skille mellom tre uavhengige funksjonelle undersystemer.

Undersystem for valg av informasjon. Informasjonssystemet kan kun behandle/behandle informasjonen som legges inn i det. Kvaliteten på IS-arbeidet bestemmes ikke bare av dens evne til å finne og behandle nødvendig informasjon i sin egen matrise og gi den til brukeren, men også av dens evne til å velge relevant informasjon fra det eksterne miljøet. Slik utvelgelse utføres av delsystemet for valg av informasjon, som samler data om informasjonsbehovene til IS-brukere (interne og eksterne), analyserer og organiserer disse dataene, og danner en IS-informasjonsprofil.

Undersystemet for inndata, prosessering/behandling og lagring av informasjon transformerer inputinformasjon og forespørsler, organiserer lagring og behandling for å møte informasjonsbehovene til IS-abonnenter.

Implementeringen av funksjonene til dette delsystemet forutsetter tilstedeværelsen av et apparat for å beskrive informasjon (kodesystemer, et databeskrivelsesspråk (DLS), etc.), organisere og vedlikeholde informasjon (logisk og fysisk organisering, prosedyrer for å vedlikeholde og beskytte informasjon, etc.), et prosesseringsapparat og informasjonsbehandling (algoritmer, modeller osv.).

Delsystemet for utarbeidelse og utstedelse av informasjon implementerer direkte tilfredsstillelsen av informasjonsbehovene til IS-brukere (interne og eksterne). For å utføre denne oppgaven gjennomfører delsystemet en studie og analyse av informasjonsbehov, bestemmer formene og metodene for deres tilfredsstillelse, den optimale sammensetningen og strukturen av, organiserer selve prosessen med informasjonsstøtte og vedlikehold.

Implementeringen av disse funksjonene krever et apparat for å beskrive og analysere informasjonsbehov og deres uttrykk i IS-språket (inkludert LOD, IPL, indekseringsspråk, etc.), samt et apparat for informasjonsstøtte selv (prosedyrer for søk og utsendelse av informasjon) , datamanipulasjonsspråk osv.). Mange funksjoner til IC-delsystemer er duplisert eller overlappet, noe som er gjenstand for optimalisering i IC-design. I denne forbindelse er automatiseringen av IS ledsaget av omfordeling av IS-elementer.

Automatisering forutsetter en formalisert representasjon (strukturering) av både IS-funksjonene og informasjonen som behandles i selve IS, som tillater inndata, bearbeiding/behandling, lagring og gjenfinning av informasjon ved hjelp av en datamaskin. Enhver formalisering er preget av en eller annen grad av tilstrekkelighet av det skapte bildet av virkeligheten (modellen) av selve virkeligheten. Dessuten er tilstrekkeligheten til virkelighetsmodellen bestemt både av egenskapene til virkeligheten selv og av egenskapene til apparatet som brukes til dens formaliserte representasjon.

Fra dette synspunktet er "automatiseringsnivået" til IS nært knyttet til "graden av strukturert" av informasjon. Det er tre nivåer av struktureringsinformasjon: Rigid strukturert informasjon (data) - informasjon, hvis formaliserte representasjon ved moderne midler for strukturering (spesielt databeskrivelsesspråk) ikke fører til tap av tilstrekkeligheten til selve informasjonsmodellen.

informasjon. Svak strukturert informasjon er informasjon, hvis formaliserte presentasjon fører til betydelige tap i tilstrekkeligheten av informasjonsmodellen til selve den opprinnelige informasjonen.

Ustrukturert informasjon er informasjon som det foreløpig ikke finnes midler for formalisert presentasjon av med et akseptabelt tilstrekkelighetsnivå i praksis. Midlene for å presentere slik informasjon må ha høye semantiske og uttrykksfulle evner. Utviklingen av slike verktøy går for tiden i retning av å lage språk for å beskrive kunnskap og IPL med høy semantisk kraft.

Metoder for konstruksjon av informasjonssystemer.

Industrien for utvikling av automatiserte informasjonsstyringssystemer oppsto på 1950-1960-tallet og fikk på slutten av århundret fullstendig ferdige skjemaer.

På den første fasen var hovedtilnærmingen i utformingen av IS "bottom-up"-metoden, da systemet ble opprettet som et sett med applikasjoner som er viktigst for øyeblikket for å støtte virksomheten til virksomheten. Denne tilnærmingen er delvis beholdt i dag. Innenfor rammen av "patchwork automation" er støtte for individuelle funksjoner ganske godt gitt, men det er praktisk talt ingen strategi for utvikling av et integrert automasjonssystem

Det neste trinnet er forbundet med erkjennelsen av at det er behov for ganske standard programvareverktøy for å automatisere aktivitetene til ulike institusjoner og virksomheter. Fra hele spekteret av problemer har utviklerne identifisert de mest merkbare: automatisering av regnskap, analytisk regnskap og teknologiske prosesser. Systemer begynte å bli designet "top-down", dvs. under forutsetning av at ett program må møte behovene til mange brukere.

Selve ideen om å bruke et universelt program pålegger betydelige begrensninger på utviklernes evne til å danne strukturen til databasen, skjermskjemaer og valg av beregningsalgoritmer. Det stive rammeverket som er pålagt "ovenfra" gjør det ikke mulig å fleksibelt tilpasse systemet til spesifikasjonene til aktiviteten til en bestemt bedrift. Dermed blir material- og tidskostnadene for implementering av systemet og dets finjustering til kundens behov. kravene overstiger vanligvis de planlagte indikatorene betydelig.

I følge statistikk utarbeidet av Standish Group (SSL), av de 8 380 prosjektene som ble undersøkt av SSL i 1994, mislyktes mer enn 30 % av prosjektene med en total verdi på over 80 milliarder dollar. Samtidig ble kun 16 % av det totale antall prosjekter ferdigstilt i tide, og kostnadsoverskridelser utgjorde 189 % av planlagt budsjett.

Samtidig begynte IS-kunder å stille flere og flere krav rettet mot å sikre muligheten for kompleks bruk av bedriftsdata i styring og planlegging av sine aktiviteter. Det oppsto derfor et presserende behov for å danne en ny metodikk for å bygge informasjonssystemer.

I følge moderne metodikk er prosessen med å lage en IS en prosess med å bygge og sekvensiell transformasjon av en rekke avtalte modeller på alle stadier av IS livssyklus (LC). På hvert stadium av livssyklusen lages det spesifikke modeller - organisasjoner, krav til

IP. IP-prosjekt. søknadskrav etc. Vanligvis skilles følgende stadier for å lage en IS: dannelsen av krav til systemet, design, implementering, testing, igangkjøring, drift og vedlikehold.

Den innledende fasen av prosessen med å skape en IS er modellering av forretningsprosesser som forekommer i organisasjonen og realisere dens mål og mål. Organisasjonsmodellen, beskrevet i form av forretningsprosesser til forretningsfunksjoner, lar deg formulere de grunnleggende kravene til IS.

IS-designet er basert på domenemodellering. For å få et IS-prosjekt som er dekkende for fagområdet i form av et system med korrekt fungerende programmer, er det nødvendig å ha en integrert, systematisk representasjon av modellen, som gjenspeiler alle aspekter ved funksjonen til det fremtidige informasjonssystemet. I dette tilfellet forstås en domenemodell som et bestemt system som imiterer strukturen eller funksjonen til det studerte domenet og oppfyller det grunnleggende kravet - å være adekvat for dette domenet.

Foreløpig modellering av fagområdet lar deg redusere tid og vilkår for prosjekteringsarbeid og få et mer effektivt og høykvalitetsprosjekt. Uten å modellere domenet, er det stor sannsynlighet for å gjøre et stort antall feil ved løsning av strategiske problemer, noe som fører til økonomiske tap og høye kostnader for påfølgende redesign av systemet. Som et resultat er alle moderne IS-designteknologier basert på bruk av domenemodelleringsmetodikk.

Følgende krav stilles til domenemodeller:

Formalisering, gir en entydig beskrivelse av strukturen til fagområdet;

Forståelighet for kunder og utviklere basert på bruk av grafiske virkemidler for å vise modellen;

Realiserbarhet, som antyder tilgjengeligheten av midler for fysisk implementering av domenemodellen og IS;

Gir en vurdering av effektiviteten av implementeringen av domenemodellen basert på visse metoder og beregnede indikatorer.

Funksjonell modellering IDEF0: grunnleggende definisjoner og bestemmelser.

Programmet for integrert databehandling av produksjonen ICAM (ICAM - Integrated Computer Aided Manufacturing) er rettet mot å øke effektiviteten til industrielle bedrifter gjennom den utbredte introduksjonen av datateknologier (informasjonsteknologier). I USA ble denne omstendigheten realisert tilbake på slutten av 70-tallet, da det amerikanske flyvåpenet foreslo og implementerte

IDEF (ICAM Definition) metodikken gjør det mulig å studere strukturen, parametrene og egenskapene til produksjonstekniske og organisasjonsøkonomiske systemer (i fremtiden, der det ikke forårsaker forvirring - systemer). Den generelle IDEF-metodikken består av tre spesifikke modelleringsmetoder basert på grafiske representasjoner av systemer:

IDEF0 brukes til å lage en funksjonell modell som viser strukturen og funksjonene til systemet, samt strømmene av informasjon og materielle objekter som forbinder disse funksjonene.

IDEF1 brukes til å bygge en informasjonsmodell som viser strukturen og innholdet i informasjonsstrømmene som kreves for å støtte systemets funksjoner;

IDEF2 lar deg bygge en dynamisk modell av den tidsvarierende oppførselen til funksjoner, informasjon og systemressurser.

Nå er de mest utbredte og anvendte metodene IDEF0 og IDEF1 (IDEF1X), som har fått status som føderale standarder i USA. IDEF0-metodikken, hvis funksjoner og anvendelse er beskrevet i dette veiledningsdokumentet (GD), er basert på tilnærmingen utviklet av Douglas T. Ross på begynnelsen av 70-tallet og kalt SADT (Structured Analysis & Design Technique - metode for strukturell analyse og design). Tilnærmingen og, som en konsekvens, IDEF0-metodikken er basert på et grafisk språk for å beskrive (modellere) systemer, som har følgende egenskaper.

For riktig visning av interaksjonene til IS-komponenter er det viktig å gjennomføre felles modellering av slike komponenter, spesielt fra innholdssynspunktet til objekter og funksjoner.

Metodikken for strukturell systemanalyse hjelper i stor grad med å løse slike problemer.

Det er vanlig å kalle en strukturanalyse en metode for å studere et system, som begynner med dens generelle oversikt, og deretter er detaljert, og får en hierarkisk struktur med et økende antall nivåer. Slike metoder er preget av: inndeling i abstraksjonsnivåer med et begrenset antall elementer (fra 3 til 7); avgrenset kontekst, inkludert bare de essensielle detaljene for hvert nivå; bruk av strenge formelle opptaksregler; konsekvent tilnærming til resultatet.

La oss definere nøkkelbegrepene for strukturanalysen av bedriften (organisasjonen).

Operasjon er en elementær (udelelig) handling utført på én arbeidsplass.

Funksjon - et sett med operasjoner gruppert i henhold til en bestemt funksjon.

En forretningsprosess er et relatert sett med funksjoner, under utførelsen av hvilke visse ressurser forbrukes og et produkt opprettes (objekt, tjeneste, vitenskapelig

funn, idé), som er av verdi for forbrukeren.

En delprosess er en forretningsprosess som er et strukturelt element i en forretningsprosess og er av verdi for forbrukeren.

En forretningsmodell er en grafisk strukturert beskrivelse av et nettverk av prosesser og operasjoner knyttet til data, dokumenter, organisasjonsenheter og andre objekter som gjenspeiler eksisterende eller tiltenkte aktiviteter til virksomheten. Det finnes ulike metoder for strukturell domenemodellering, blant hvilke funksjonsorienterte og objektorienterte metoder bør skilles.

Å beskrive et system som bruker IDEF0 kalles en funksjonell modell. Funksjonsmodellen er ment å beskrive eksisterende forretningsprosesser, som bruker både naturlige og grafiske språk. For å formidle informasjon om et spesifikt system, er kilden til det grafiske språket selve IDEF0-metodikken.

IDEF0-metodikken foreskriver konstruksjonen av et hierarkisk system av diagrammer - enkeltbeskrivelser av systemfragmenter. Først beskrives systemet som helhet og dets interaksjon med omverdenen (kontekstdiagram), hvoretter funksjonell dekomponering utføres - systemet er delt inn i delsystemer og hvert delsystem beskrives separat (dekomponeringsdiagrammer). Deretter brytes hvert delsystem ned i mindre, og så videre til ønsket detaljnivå er oppnådd.

Verktøymiljø BPwin.

Forretningsprosessmodellering utføres vanligvis ved hjelp av caseverktøy. Disse verktøyene inkluderer BPwin (PLATINUM-teknologi), Silverrun (Silverrun-teknologi), Oracle Designer (Oracle), Rational Rose (Rational Software), etc. Funksjonaliteten til de strukturelle modelleringsverktøyene for forretningsprosesser vil bli diskutert ved å bruke eksemplet med BPwin-saken. verktøy.

BPwin støtter tre modelleringsmetoder: funksjonell modellering (IDEF0); beskrivelse av forretningsprosesser (IDEF3); dataflytdiagrammer (DFD). BPwin har et ganske enkelt og intuitivt brukergrensesnitt. Når du starter BPwin, vises hovedverktøylinjen som standard, verktøypaletten (hvis utseendet avhenger av den valgte notasjonen) og, til venstre, modellnavigatoren - Model Explorer).

Når du oppretter en ny modell, vises en dialogboks der du skal spesifisere om modellen skal opprettes på nytt eller den skal åpnes fra en fil eller fra ModelMart-depotet, skriv deretter inn navnet på modellen og velg metodikken som modellen har. vil bli bygget.

Som nevnt ovenfor støtter BPwin tre metoder - IDEF0, IDEF3 og DFD, som hver løser sine egne spesifikke problemer. I BPwin er det mulig å bygge blandede modeller, det vil si at en modell kan inneholde både IDEF0 og IDEF3 og DFD diagrammer samtidig. Sammensetningen av verktøypaletten endres automatisk når du bytter fra en notasjon til en annen.

En BPwin-modell blir sett på som en samling av aktiviteter, som hver opererer på et sett med data. Arbeid er avbildet som rektangler, data som piler. Hvis du klikker på et objekt i modellen med venstre museknapp, vises en kontekstmeny, hvor hvert element tilsvarer redaktøren av en bestemt egenskap til objektet.

I de innledende stadiene av å lage en IP er det nødvendig å forstå hvordan organisasjonen som skal automatisere fungerer. Lederen kjenner arbeidet som helhet godt, men er ikke i stand til å fordype seg i detaljene i arbeidet til hver ordinær medarbeider. En vanlig ansatt vet godt hva som skjer på arbeidsplassen hans, men vet kanskje ikke hvordan kollegaer jobber. Derfor, for å beskrive arbeidet til en bedrift, er det nødvendig å bygge en modell som vil være tilstrekkelig til fagområdet og inneholde kunnskapen til alle deltakere i organisasjonens forretningsprosesser.

Det mest hensiktsmessige språket for modellering av forretningsprosesser er IDEF0, hvor systemet er representert som et sett med samvirkende aktiviteter eller funksjoner. Denne rent funksjonelle orienteringen er grunnleggende - funksjonene til systemet analyseres uavhengig av objektene de opererer med. Dette lar deg tydeligere modellere logikken og samspillet til organisasjonens prosesser.

Prosessen med å modellere et system i IDEF0 begynner med å lage et kontekstdiagram - et diagram over det mest abstrakte nivået av beskrivelsen av systemet som helhet, som inneholder definisjonen av emnet modellering, målet og synspunktet på modellen.

Aktiviteter refererer til navngitte prosesser, funksjoner eller oppgaver som oppstår over tid og har gjenkjennelige resultater.

Verkene er avbildet som rektangler. Alle jobber må navngis og defineres. Navnet på jobben må uttrykkes med et verbalt substantiv som angir en handling (for eksempel "Bedriftsaktivitet", "Ta en ordre" osv.). Arbeidet "Bedriftsaktiviteter" kan for eksempel ha følgende definisjon: "Dette er en læringsmodell som beskriver virksomhetens aktiviteter." Når du oppretter en ny modell (meny Fil / Ny), opprettes det automatisk et kontekstdiagram med et enkelt verk som viser systemet som en helhet.

Piler beskriver samspillet mellom jobber og representerer noe informasjon uttrykt i substantiv. (For eksempel "Kundeanrop", "Regler og prosedyrer", "Regnskapssystem".)

Lærebok for universiteter

2. utg., Rev. og legg til.

2014 G.

Opplag 1000 eksemplarer.

Format 60x90 / 16 (145x215 mm)

Utførelse: pocketbok

ISBN 978-5-9912-0193-3

BBK 32.882

UDC 621.395

Grif UMO
Anbefalt av UMO for utdanning innen telekommunikasjon som lærebok for studenter ved høyere utdanningsinstitusjoner som studerer i spesialitetene "Nettverk og svitsjesystemer", "Flerkanals telekommunikasjonssystemer"

merknad

Algoritmer for modellering av diskrete og kontinuerlige tilfeldige variabler og prosesser vurderes. Prinsippene og algoritmene for modellering av informasjonssignaler beskrevet av Markov-prosesser med diskret og kontinuerlig tid er angitt Prinsippene for modellering av køsystemer vurderes. Funksjonene ved beskrivelsen og bruken av fraktale og multifraktale prosesser for modellering av telekommunikasjon er beskrevet. Metoder og eksempler på modellering av informasjonssystemer ved bruk av spesialiserte programvarepakker Matlab, Opnet, Nettverkssimulator analyseres.

For studenter påmeldt spesialitetene "Nettverk og svitsjsystemer", "Flerkanals telekommunikasjonssystemer", "Informasjonssystemer og teknologier".

Introduksjon

1 Generelle prinsipper for systemmodellering
1.1. Generelle konsepter for modell og modellering
1.2. Modellklassifisering
1.3. Modellstruktur
1.4. Metodologisk grunnlag for å formalisere funksjonen til et komplekst system
1.5. Komponentmodellering
1.6. Stadier av dannelsen av en matematisk modell
1.7. Simuleringsmodellering
Kontrollspørsmål

2 Generelle prinsipper for å bygge kommunikasjonssystemer og nettverk
2.1. Konseptet med å bygge kommunikasjonssystemer og nettverk
2.2. Lagdelte nettverksmodeller
2.2.1. Tre-lags modell
2.2.2. TCP / IP-protokollarkitektur
2.2.3. OSI referansemodell
2.3. Kommunikasjonsnettverksstruktur
2.3.1. Globale nettverk
2.3.2. Lokale nettverk
2.3.3. Datanettverkstopologier
2.3.4. Lokale Ethernet-nettverk
2.4. Frame Relay-nettverk
2.5. IP-telefoni
Kontrollspørsmål

3 Simulering av tilfeldige tall
3.1. Forstå tilfeldige tall
3.2. Programmatiske metoder for å generere jevnt fordelte tilfeldige tall
3.3. Dannelse av tilfeldige variabler med en gitt distribusjonslov
3.3.1. Invers funksjonsmetode
3.3.2. Omtrentlig metoder for å konvertere tilfeldige tall
3.3.3. Screeningsmetode (Neumann Generation Method)
3.4. Metoder basert på sentralgrensesetningen
3.5. Algoritmer for modellering av ofte brukte tilfeldige variabler
3.6. Algoritmer for modellering av korrelerte tilfeldige variabler
3.7. Dannelse av realiseringer av tilfeldige vektorer og funksjoner
3.7.1. Modellering av et n-dimensjonalt tilfeldig punkt med uavhengige koordinater
3.7.2. Dannelse av en tilfeldig vektor (innenfor rammen av korrelasjonsteorien)
3.7.3. Dannelse av implementeringer av tilfeldige funksjoner

4 Modellering av diskrete distribusjoner
4.1. Bernoulli distribusjon
4.2. Binomial fordeling
4.3. Giftfordeling
4.4. Simulering av forsøk i et tilfeldig hendelsesskjema
4.4.1. Simulering av tilfeldige hendelser
4.4.2. Modellering av motsatte hendelser
4.4.3. Modellering av en diskret tilfeldig variabel
4.4.4. Modellering av en komplett gruppe hendelser
4.5. Strømmer av hendelser
4.6. Behandling av simuleringsresultater
4.6.1. Presisjon og antall realiseringer
4.6.2. Primær statistisk databehandling
Kontrollspørsmål

5 Algoritmer for modellering av stokastiske signaler og interferens i kommunikasjonssystemer
5.1. Algoritme for modellering av ikke-stasjonære stokastiske prosesser
5.2. Algoritmer for modellering av stasjonære tilfeldige prosesser
5.3. Metoder for modellering av signaler og støy i form av stokastiske differensialligninger
5.4. Eksempler på modeller for stokastiske prosesser i kommunikasjonssystemer
5.4.1. Informasjonsprosessmodeller
5.4.2. Interferensmodeller
5.4.3. Kjennetegn på hovedtypene av interferens
Kontrollspørsmål

6 Markov stokastiske prosesser og deres modellering
6.1. Grunnleggende konsepter for en Markov stokastisk prosess
6.2. Grunnleggende egenskaper til diskrete Markov-kjeder
6.3. Kontinuerlige Markov-kjeder
6.3.1. Enkle konsepter
6.3.2. Semi-Markov prosesser
6.3.3. Døds- og reproduksjonsprosesser
6.4. Modeller av tilfeldige Markov-prosesser med kontinuerlig verdi basert på stokastiske differensialligninger
6.5. Modellering av Markovs stokastiske prosesser
6.5.1. Modellering av diskrete prosesser
6.5.2. Modellering av skalære prosesser med kontinuerlig verdi
6.5.3. Modellering av vektorprosesser med kontinuerlig verdi
6.5.4. Modellering av en Gauss-prosess med fraksjonell-rasjonell spektraltetthet
6.5.5. Modellering av flere tilkoblede sekvenser
6.5.6. Modellering av Markov-prosesser ved hjelp av formingsfiltre
6.5.7. Algoritme for statistisk modellering av Markov-kjeder
Kontrollspørsmål

7 Eksempler på Markov-modeller
7.1. Markov-modeller for taledialog av abonnenter
7.1.1. Tale sier
7.1.2. Dialogmodeller
7.2. Markov-modeller av talemonolog
7.3. Markov-drevet Poisson-prosess i talemodeller
7.4. Markov-modeller av digitale sekvenser ved utgangen av G.728-kodeken
7.5. Statistisk multipleksing av kilden til talepakker som tar hensyn til Markov-modellen for telefondialog
7.6. Markov-modell av en trådløs kanal med ARQ / FEC-mekanisme
7.7. Batching feil
7.8. Beregning av feilstrømkarakteristikk etter modellparametere
7.8.1. Estimerer parameterne for feilstrømmen
7.8.2. Evaluering av tilstrekkeligheten av feilflytmodellen
7.9. Markov-modeller for å vurdere QoS for sanntids multimediatjenester på Internett
7.9.1. Sanntids multimedietjenester konsept
7.9.2. Analyse og modellering av forsinkelser og tap
7.10. Modeller av multimediatrafikkstrømmer
Kontrollspørsmål

8 Køsystemer og deres modellering
8.1. Generelle kjennetegn ved køsystemer
8.2. Køsystemstruktur
8.3. Køsystemer med venting
8.3.1. Servicesystem M / M / 1
8.3.2. Servicesystem M / G / 1
8.3.3. Nettverk med et stort antall noder forbundet med kommunikasjonskanaler
8.3.4. Prioritert tjeneste
8.3.5. Servicesystem M/M/N/m
8.4. Feil i køsystemer
8.5. Generelle prinsipper for modellering av køsystemer
8.5.1. Statistisk testmetode
8.5.2. Blokkmodeller av systemfungerende prosesser
8.5.3. Funksjoner ved modellering ved bruk av Q-kretser
Kontrollspørsmål

9 Modellering av informasjonssystemer ved bruk av typiske tekniske midler
9.1. Systemmodellering og programmeringsspråk
9.2. Forstå GPSS-språket
9.2.1. Dynamiske objekter GPSS. Transaksjonsorienterte blokker (operatører)
9.2.2. Maskinvareorienterte blokker (operatører)
9.2.3. Multikanal tjeneste
9.2.4. GPSS statistiske blokker
9.2.5. Driftsenheter GPSS
9.2.6. Andre GPSS-blokker
9.3. Simulering av ETHERNET-nettverket i GPSS-miljøet
Kontrollspørsmål

10 Modellering av informasjonsoverføringssystemer
10.1. Typisk dataoverføringssystem
10.2. Immunitet for overføring av diskrete signaler. Optimal mottak
10.3. Estimering av sannsynligheten for feil mottak av diskrete signaler med fullt kjente parametere
10.4. Immunitet til diskrete signaler med tilfeldige parametere
10.5. Immunitet av diskrete signaler med usammenhengende mottak
10.6. Immunitet til diskrete signaler med tilfeldige essensielle parametere
10.7. Algoritmer for dannelse av diskrete signaler
10.8. Algoritme for å generere interferens
10.9. Algoritme for demodulering av diskrete signaler
10.10. Strukturen til imitasjonskomplekset og dets subrutiner
10.11. Mathworks Matlab programvaremiljø og Simulink visuell modelleringspakke
10.11.1. Teknisk beskrivelse og grensesnitt
10.11.2. Simulink Visual Simulation Package
10.11.3. Oppretting og maskering av delsystem
10.11.4. Utvidelsespakke for kommunikasjonsverktøykasse
10.12. Modellering av blokkene til WiMAX-dataoverføringssystemet
10.12.1. Sendersimulering
10.12.2. Modellering av en overføringskanal
10.12.3. Mottakersimulering
10.12.4. Implementering av modellen i Mathlab-systemet
10.13. Resultater av WiMAX-systemsimulering
Kontrollspørsmål

11 Selvliknende prosesser og deres anvendelse i telekommunikasjon
11.1. Grunnleggende om teorien om fraktale prosesser
11.2. Multifraktale prosesser
11.3. Estimering av Hurst-eksponenten
11.4. Multifraktal analyse ved hjelp av programvare
11.4.1. Beskrivelse av programvaren
11.4.2. Eksempler på vurdering av graden av selvlikhet
11.5. Algoritmer og programvare for multifraktal analyse
11.6. Påvirkning av trafikkens egenlikhet på egenskapene til tjenestesystemet
11.7. Metoder for å modellere selvliknende prosesser i TV-trafikk
11.8. Utforske den selv-lignende strukturen til Ethernet-trafikk
11.9. Selvliknende trafikkbelastningskontroll
11.10. Fraktal Brownsk bevegelse
11.10.1. RMD-algoritme for å generere FBD
11.10.2. SRA FWA Generation Algoritme
11.12. Fraktal Gaussisk støy
11.12.1. FFT-algoritme for FGS-syntese
11.12.2. Evaluering av simuleringsresultater
Kontrollspørsmål

12 Modellering av en telekommunikasjonsnettverksnode
12.1. Fundamentals of Frame Relay Protocol
12.2. Frame Relay Host Design
12.3. Simuleringsresultater av en FR-ruter med G.728-kodeker ved inngangen
12.4. Effekten av trafikkens egenlikhet på QoS
Kontrollspørsmål

13 Spesialiserte systemer for simulering av datanettverk
13.1. Generelle kjennetegn ved spesialiserte programvarepakker for nettverksmodellering
13.2. Generelle prinsipper for modellering i OPNET Modeler-miljøet
13.3. OPNET-applikasjonseksempler
13.3.1. Modell for vurdering av tjenestekvalitet
13.3.2. Implementering av den lokale nettverksmodellen
Kontrollspørsmål

14 Simulering med nettverkssimulator 2
14.1. Historie og arkitektur til NS2-pakken
14.2. Lag et simulatorobjekt
14.3. Opprette en nettverkstopologi
14.4. Stille inn generatorparametere
14.4.1. Eksponentiell på/av
14.4.2. Pareto på/av
14.5. To hovedkøalgoritmer
14.6. Adaptiv ruting i NS2
14.6.1. API på brukernivå
14.6.2. Intern arkitektur
14.6.3. Utvidelser til andre klasser
14.6.4. ulemper
14.6.5. Liste over kommandoer som brukes til å simulere dynamisk skripting i NS2
14.6.6. Et eksempel på dynamisk ruting i NS2
14.7. Kjøre et skriptprogram i NS2
14.8. Prosedyre for behandling av simuleringsresultater
14.9. Et eksempel på modellering av et trådløst nettverk
14.10. Et eksempel på simulering av kvaliteten på streaming videooverføring ved bruk av NS 2-pakken
14.10.1. Strukturen til maskinvare- og programvarekomplekset for å vurdere kvaliteten på streaming av video
14.10.2. PAK funksjonelle moduler
14.10.3. Videokvalitetsvurdering