Dfd eksempel på konstruksjon. Metoder for domenemodellering

Hjem > Forelesning

FOREDRAG nr. 3

DATAFLØMSDIAGRAMMER Dataflytdiagrammer(DFD) er den primære metoden for å modellere funksjonskravene til systemet som designes. Med deres hjelp blir disse kravene brutt ned i funksjonelle komponenter (prosesser) og presentert som et nettverk koblet sammen av datastrømmer. Hovedformålet med slike verktøy er å demonstrere hvordan hver prosess transformerer sine input til output, samt å avsløre relasjonene mellom disse prosessene. Dataflytdiagrammer har eksistert i svært lang tid. La meg gi deg følgende eksempel på bruk av DFD til å omorganisere et kontor overfylt med funksjonærer, som dateres tilbake til 20-tallet. Konsulenten som utførte omorganiseringen markerte hver kontorist med en sirkel og hvert dokument som ble sendt mellom dem med en pil. Ved å bruke et slikt diagram foreslo han en omorganiseringsordning der to funksjonærer som utvekslet mange dokumenter ble sittende i nærheten, og funksjonærer med lite interaksjon ble sittende på stor avstand. Slik ble den første modellen født, som er et flytdiagram - en forkynner for DFD. To forskjellige notasjoner brukes tradisjonelt for å representere DFD-er: Yourdon og Gane-Sarson. Vi vil bruke Yodan-notasjon når vi konstruerer eksempler.

Grunnleggende symboler

De viktigste DFD-symbolene er vist i fig. 1.

R
Fig.1 Hovedkomponenter i et dataflytdiagram

La oss beskrive formålet deres. Diagrammer representerer funksjonelle krav ved bruk av prosesser og lagre forbundet med datastrømmer. DATASTRØMMER er mekanismer som brukes til å modellere overføring av informasjon (eller til og med fysiske komponenter) fra en del av et system til en annen. Betydningen av dette objektet er åpenbart: det gir navnet til hele instrumentet. Strømmer i diagrammer er vanligvis representert med navngitte piler, hvis orientering indikerer retningen informasjonen flyter i. Noen ganger kan informasjon bevege seg i én retning, bli behandlet og gå tilbake til kilden. Denne situasjonen kan modelleres enten ved to forskjellige strømmer, eller ved en - toveis. Hensikt PROSESS består av å produsere utgangsstrømmer fra inngangsstrømmer i samsvar med handlingen spesifisert av prosessnavnet. Dette navnet må inneholde et verb i ubestemt form etterfulgt av et objekt (for eksempel BEREGN MAKS HØYDE). I tillegg må hver prosess ha et unikt nummer for referanse i diagrammet. Dette nummeret kan brukes sammen med diagramnummeret for å gi en unik prosessindeks for hele modellen. DATALAGRING lar deg definere data i visse områder som vil bli lagret i minnet mellom prosesser. Faktisk representerer lageret "stykker" av datastrømmer over tid. Informasjonen den inneholder kan brukes når som helst etter at den er definert, og dataene kan velges i hvilken som helst rekkefølge. Depotnavnet må identifisere innholdet og være et substantiv. I tilfellet der en dataflyt kommer inn eller ut av et lager og strukturen samsvarer med strukturen til lageret, må den ha samme navn, som ikke trenger å vises i diagrammet. EKSTERN ENHET (eller TERMINATOR) representerer en enhet utenfor systemkonteksten som er kilden eller kilden til systemdata. Navnet hennes må inneholde et substantiv, f.eks. LAGER, Objektene representert av slike noder forventes ikke å delta i noen behandling. Kontekstdiagram og prosessdetalj DFD-dekomponering er prosessbasert: hver prosess kan utvides ved å bruke en DFD på lavere nivå. En spesiell type DFD spiller en viktig spesifikk rolle i modellen - kontekstdiagram, modellering av systemet på den mest generelle måten. Kontekstdiagrammet gjenspeiler systemets grensesnitt med omverdenen, nemlig informasjonsflyten mellom systemet og de eksterne enhetene det må kobles til. Den identifiserer disse eksterne enhetene så vel som vanligvis en enkelt prosess som reflekterer hovedformålet eller naturen til systemet så mye som mulig. Og selv om kontekstdiagrammet virker trivielt, ligger dets utvilsomt nytte i det faktum at det etablerer grensene for systemet som analyseres. Hvert prosjekt skal ha nøyaktig ett kontekstdiagram, og det er ikke nødvendig å nummerere den eneste prosessen. Første nivå DFD er bygget som en dekomponering av prosessen som er tilstede i kontekstdiagrammet. Det konstruerte førstenivådiagrammet har også mange prosesser, som igjen kan dekomponeres til en DFD på lavere nivå. Dette bygger et DFD-hierarki med et kontekstdiagram ved roten av treet. Denne dekomponeringsprosessen fortsetter til prosessene kan beskrives effektivt ved å bruke korte (opptil én side) (prosessspesifikasjoner). Med denne konstruksjonen av DFD-hierarkiet, må hver prosess på lavere nivå korreleres med en prosess på høyere nivå. Typisk strukturerte prosessnummer brukes til dette formålet. Så hvis vi for eksempel detaljerer prosess nummer 2 på diagrammet på første nivå ved å utvide det ved å bruke en DFD som inneholder tre prosesser, vil tallene deres være som følger: 2.1, 2.2 og 2.3. Om nødvendig kan du gå til neste nivå, dvs. for prosess 2.2 får vi 2.2.1, 2.2.2. etc. La oss illustrere kontekstdiagrammet med et eksempel. P

eksempel . La oss se på prosessen med å BESTÅ EKSAMEN. Vi har to enheter STUDENT og LÆRER. La oss beskrive datastrømmene som vårt designet system utveksler med eksterne objekter.

Fra STUDENT-enhetssiden vil vi beskrive informasjonsflyter. For å bestå eksamen, er det nødvendig at STUDENT har en KREDITT og også at han har OPPTAK TIL EKSAMEN. Resultatet av bestått eksamen, dvs. utdatastrømmene vil være EKSAMEN GRADE og TEST, der GRADEN vil bli lagt inn. Fra siden av LÆRER-enheten er informasjonsstrømmene som følger. EKSAMENSRAPPORT, hvor det vil være kjent at STUDENT er tatt opp til eksamen, samt den offisielle oppgaven hvor eksamensresultatet skal føres, d.v.s. EKSAMENSKARTER INKLUDERT I RAPPORTEN. La oss nå detaljere prosessen 1. BESTÅ EKSAMEN. Denne prosessen vil inneholde følgende prosesser:

Tegn lodd Forbered deg på svar Svar på lodd Vurdering

Datanedbryting og relaterte utvidelser av dataflytdiagrammer

Individuelle data i et system er ofte uavhengige. Noen ganger er det imidlertid nødvendig å håndtere flere uavhengige data samtidig. For eksempel har systemet tråder EPLER, APPELSINER Og PÆRER. Disse trådene kan grupperes ved å introdusere en ny tråd FRUKT. For å gjøre dette er det nødvendig å formelt definere flyten FRUKT som består av flere etterkommerelementer. Denne definisjonen er gitt ved hjelp av Backus-Naur-skjemaer (BNF) i dataordboken (vi skal se på dette skjemaet i neste forelesning). I sin tur flyten FRUKT seg selv kan være inneholdt i en stamfartråd MAT sammen med bekkene GRØNNSAKER, KJØTT osv. Slike strømmer som kombinerer flere strømmer kalles gruppe Den omvendte operasjonen, splitting av strømmer i understrømmer, utføres ved hjelp av en gruppenode (fig. 3), som lar deg dele en strøm i et hvilket som helst antall understrømmer.

R

er. 3

Ved splitting er det også nødvendig å formelt definere delstrømmene i dataordboken (ved bruk av BNF). Dekomponeringen av strømmer over diagramgrenser utføres på lignende måte, noe som gjør det mulig å forenkle den detaljerte DFD. La det være en flyt FRUKT, inkludert i den detaljerte prosessen. Et flytdiagram som beskriver denne prosessen FRUKT finnes kanskje ikke i det hele tatt, men det kan være tråder i stedet EPLER Og APPELSINER(som om de ble overført fra prosessen som ble detaljert). I dette tilfellet må det være en BNF-definisjon av flyten FRUKT, bestående av understrømmer EPLER Og APPELSINER, for balanseformål. Bruken av disse operasjonene på data gir mulighet for datastrukturering og øker synligheten og lesbarheten til diagrammer. For å gi datadekomponering og noen andre tjenestefunksjoner, legges følgende typer objekter til DFD: 1) GRUPPE NODE. Designet for å splitte og slå sammen bekker. I noen tilfeller kan det være fraværende (dvs. faktisk degenerert til et punkt med sammenslåing/deling av strømmer på diagrammet). 2) FORFARNODE . Lar deg koble inngående og utgående flyt mellom detaljeringsprosessen og detaljerings-DFD. 3) UBRUKT NODE . Den brukes i en situasjon der datadekomponering utføres i en gruppenode, og ikke alle elementene i flyten som kommer inn i noden er nødvendige. 4) NAVNEENDRINGNODE . Lar deg tvetydig navngi strømmer, mens innholdet er tilsvarende. For eksempel, hvis det samme datastykket under utformingen av forskjellige deler av systemet mottok forskjellige navn, sikres ekvivalensen av de tilsvarende datastrømmene av navneendringsnoden. I dette tilfellet en av strømmene
data er inngangen for denne noden, og den andre er utgangen.

Tekst i fritt format hvor som helst på diagrammet. En mulig måte å skildre disse nodene er vist i fig. 3.

Modellbygg

Hovedformålet med å konstruere et hierarkisk sett med DFD-er er å gjøre kravene klare og forståelige på hvert detaljnivå, og å bryte ned disse kravene i deler med nøyaktig definerte forhold mellom dem. For å oppnå dette, anbefales det å bruke følgende anbefalinger:

Plasser fra 3 til 6-7 prosesser på hvert diagram. Den øvre grensen tilsvarer menneskets evne til samtidig å oppfatte og forstå strukturen til et komplekst system med mange interne forbindelser, den nedre grensen er valgt av hensyn til sunn fornuft: det er ikke nødvendig å detaljere prosessen med et diagram som inneholder bare en eller to prosesser. Ikke fyll diagrammene med detaljer som er uviktige på dette nivået. Dekomponering av datastrømmer utføres parallelt med dekomponering av prosesser; de to jobbene skal gjøres samtidig, ikke den ene etter den andre er fullført. Velg klare, beskrivende prosess- og trådnavn for å gjøre diagrammer lettere å forstå, og unngå å bruke forkortelser. Definer funksjonelt identiske prosesser én gang på høyeste nivå der en slik prosess er nødvendig, og referer den til lavere nivåer. Bruk de enkleste diagramteknikkene: hvis noe kan beskrives ved hjelp av DFD, bør dette gjøres, og ikke bruke mer komplekse objekter for beskrivelse. Skille kontrollstrukturer fra prosesseringsstrukturer (dvs. prosesser), lokaliser kontrollstrukturer. I samsvar med disse anbefalingene er prosessen med å bygge en modell delt inn i følgende stadier:

Å bryte ned flere krav og organisere dem i store funksjonelle grupper.

Identifikasjon av eksterne objekter som systemet skal kobles til.

Identifikasjon av hovedtypene informasjon som sirkulerer mellom systemet og eksterne objekter. Foreløpig utvikling av et kontekstdiagram der de viktigste funksjonelle gruppene er representert av prosesser, eksterne objekter - av eksterne enheter, hovedtyper av informasjon - av datastrømmer mellom prosesser og eksterne enheter. Studer det foreløpige kontekstdiagrammet og skriv inn
endringer i den basert på resultatene av svarene på resultatet
studere spørsmål i alle deler. Konstruere et kontekstdiagram ved å kombinere alle
pre-diagram prosesser til én prosess, og
gruppering av tråder. Generering av førstenivå DFD basert på foreløpige kontekstdiagramprosesser. Verifikasjon av de grunnleggende kravene for Level 1 DFD. Dekomponering av hver prosess i gjeldende DFD ved hjelp av et detaljdiagram eller prosessspesifikasjon. Kontrollerer de grunnleggende kravene til DFD på riktig nivå. Legg til nye flytdefinisjoner til dataordboken når de vises i diagrammene dine. Parallell (med dekomponeringsprosessen) studie av krav (inkludert nylig mottatte), bryte dem ned i elementære og identifisere prosesser eller prosessspesifikasjoner som oppfyller disse kravene. Etter å ha bygget to eller tre nivåer, gjennomføre en revisjon for å kontrollere riktigheten og forbedre forståelsen av modellen. Konstruksjon av en prosessspesifikasjon (i stedet for et enkelt diagram) i tilfelle en bestemt funksjon er vanskelig eller umulig å uttrykke ved en kombinasjon av prosesser.

Sanntidsutvidelser

Sanntidsutvidelser brukes for å supplere datafunksjonsmodellen (DFD-hierarkiet) med verktøy for å beskrive kontrollaspekter i sanntidssystemer. For disse formålene brukes følgende symboler (fig. 4):

1) KONTROLLPROSESS. Den representerer grensesnittet mellom DFD og kontrollspesifikasjoner som faktisk modellerer og dokumenterer sanntidsaspekter. Navnet angir typen kontrollaktivitet produsert av spesifikasjonen. Faktisk er kontrollprosessen en omformer av inngangskontrollstrømmer til utgangskontrollstrømmer; i dette tilfellet må den nøyaktige beskrivelsen av denne transformasjonen spesifiseres i kontrollspesifikasjonen. 2) LEDELSESLAGRING. Representerer en "del av kontrollflyt i tid. Kontrollinformasjonen den inneholder kan brukes når som helst etter at den er lagret i butikken, og de tilsvarende dataene kan brukes i hvilken som helst rekkefølge. Navnet på kontrolllageret må identifisere innholdet og være et substantiv. Kontrolllager er forskjellig fra tradisjonelle ved at det bare kan inneholde kontrollstrømmer; alle andre egenskaper er identiske. 3) KONTROLLSTRØM. Er et "rør" som kontrollinformasjon går gjennom. Navnet skal ikke inneholde verb, men bare substantiv og adjektiver. Vanligvis har en kontrollstrøm diskret snarere enn kontinuerlig verdi. Dette kan for eksempel være et signal som representerer tilstanden eller typen operasjon. En logisk kontrollprosess er en slags kommandopost som reagerer på endringer i eksterne forhold som overføres til den ved hjelp av kontrollflyter, og produserer i samsvar med dens interne logiske kommandoer utført av prosesser. I dette tilfellet avhenger prosessutførelsesmodusen av typen kontrolltråd. Følgende typer kontrollstrømmer er tilgjengelige: a) T-flow (trigger flow). Er tråden til prosesskontroll som kan få en prosess til å kjøre. I dette tilfellet ser det ut til at prosessen er slått på i en kort operasjon. Dette er en analog av en lysbryter, hvis enkelt trykk starter prosessen med å brenne lampen. b) A-flow (aktivatorstrøm). Er en prosesskontrolltråd som kan modifisere utførelsen av en enkelt prosess. Brukes for å sikre kontinuitet i prosessutførelsen så lenge tråden er "på" (dvs. flyter kontinuerlig), når tråden er "slått av" avsluttes prosesskjøringen. Dette er analogt med en lampebryter, som kan være enten på eller av. V) E/D-strømme(aktiver/deaktiver flyt). Er en prosesskontrolltråd som kan bytte utførelse av en separat prosess. Flyt langs E-linjen får prosessen til å utføre, som fortsetter til flyt langs D-linjen startes. Dette er en analog av en bryter med to knapper: en for å slå på lyset, den andre for å slå den av. Merk at du kan bruke 3 typer slike strømmer: E-stream, D-stream, E/D-stream. Noen ganger er det behov for å representere det samme datastykket med strømmer av forskjellige typer. For eksempel kan datastrømmen MACHINE SPEED i noen tilfeller brukes som en kontrollstrøm for å kontrollere den kritiske verdien. For å sikre dette brukes TYPEENDRINGNODEN (Fig. 5): datastrømmen er inngangen for denne noden, og kontrollstrømmen er utgangen.

Ris. 5. Skriv endringsnode

Generelt konsept

Prosessmodelleringsmetode - dataflyt (DFD)

DFD-er lar deg presentere kravene til det utformede systemet i form av et hierarki av funksjonelle komponenter (prosesser) koblet sammen av datastrømmer.

Hensikten med denne representasjonen er å demonstrere hvordan hver prosess transformerer sine input til output, og å avsløre relasjonene mellom disse prosessene.

Eksempel. Amerika 20-tallet. Kontorkonsulenten markerte hver kontorist med en sirkel og hvert dokument som ble sendt mellom dem med en pil. Ved å bruke et slikt diagram foreslo han en omorganiseringsordning der to funksjonærer som utvekslet mange dokumenter ble sittende i nærheten, og funksjonærer med lite interaksjon satt i stor avstand fra hverandre. Slik ble den første DFD-prototypen født.

For å konstruere DFD brukes to forskjellige notasjoner, tilsvarende Jordan- og Hein–Serson-metodene. Ytterligere eksempler vil bruke den mer populære Hein–Serson-notasjonen i dag.

Systemmodellen beskriver den asynkrone prosessen med informasjonstransformasjon. Dekomponering kontekstdiagrammer(diagrammer over de øvre nivåene) fortsetter, og skaper et flernivåhierarki av diagrammer, til nedbrytningsnivået er nådd, hvor prosessene blir elementære og det er umulig å detaljere dem ytterligere.

Hovedkomponentene i dataflytdiagrammer er:

1. Eksterne enheter.

2. Systemer og delsystemer.

3. Prosesser.

4. Datalagringsenheter.

5. Datastrømmer.

Ekstern enhet– et materiell objekt eller individ som er en kilde eller mottaker av informasjon (kunder, leverandører, kunder, lager osv.) På dataflytdiagrammer er en ekstern enhet indikert med en firkant som kaster en skygge.

Systemer og delsystemer er elementer i det øverste nivået av dekomponering og vises på kontekstdiagrammer som en enkelt helhet.

Systemer og delsystemer dekomponeres til prosesser– diagramkomponenter designet for å transformere inndatastrømmer til utdatastrømmer i samsvar med en spesifikk algoritme.

Fysisk kan prosessen implementeres på ulike måter: det kan være en avdeling i organisasjonen som behandler inndatadokumenter og utsteder rapporter, eller et program, eller en maskinvareimplementert logisk enhet, etc.

Å bruke verb som "behandle", "oppgradere" eller "redigere" i diagrammer indikerer mangel på forståelse av prosessen og krever ytterligere analyse.

Datalagring– en abstrakt enhet for lagring av informasjon. Det forutsettes at informasjon når som helst kan plasseres i en lagringsenhet og hentes etter noe tid, og måtene å plassere og hente derfra kan være forskjellige.

Fysisk kan en datalagringsenhet implementeres i form av en boks i et arkivskap, et bord i RAM, filer på magnetiske medier, etc.

I et dataflytdiagram identifiseres en datastasjon med bokstaven "D" og et vilkårlig tall. Stasjonsnavnet er valgt for å være mest informativt for designeren. Generelt er en datalagringsenhet en prototype av en fremtidig database, og beskrivelsen av dataene som er lagret i den må spesifiseres i samsvar med informasjonsmodellen (ERD).

Data strøm definerer informasjon som overføres gjennom en tilkobling fra en kilde til en mottaker. Selve datastrømmen kan være informasjon som overføres over en kabel mellom to enheter, brev sendt med post, magnetbånd eller disketter som overføres fra en datamaskin til en annen, etc.

I et diagram er dataflyt representert av en linje som slutter på en pil som viser retningen til flyten. Hver datastrøm har et navn som gjenspeiler innholdet.

Når du konstruerer DFD-diagrammer, er det vanlig å bruke følgende anbefalinger:

1.Plasser fra 3 til 6÷7 prosesser på hvert diagram.

3. Prøv å ikke bruke forkortelser.

4. Ikke fyll diagrammene med uviktige detaljer.

9.3. Entitetsforholdsdiagrammer

ERD-notasjonen for å konstruere enhetsforholdsdiagrammer inkluderer ni hovedkomponenter.

Oftest brukes informasjonsmodeller av denne typen for å designe en databasestruktur.

Emne 8. Modellering av datastrømmer

Generelle bestemmelser. 1

Modell DFD...3

Typer DFD-notasjoner.. 3

Strukturen til DFD-modellen.. 4

Grunnleggende elementer i DFD og deres formål. 6

Konklusjon: 11

Generelle bestemmelser

Det er en legende om hvordan DFD-er ble til.

På 1920-tallet markerte en konsulent som reorganiserte et kontor hver kontorist med en sirkel og hvert dokument som ble sendt mellom dem med en pil. Ved å bruke et slikt diagram foreslo han en omorganiseringsordning der to funksjonærer som utvekslet mange dokumenter ble sittende i nærheten, og funksjonærer med lite interaksjon ble sittende på stor avstand. Slik ble den første modellen født, som er et flytdiagram - en forkynner for DFD. Det har gått mye tid siden den gang. Nye symboler ble lagt til sirkler og piler, noe som økte uttrykkskraften til notasjonen. Det har dukket opp utvikling på måter å bruke DFD til å løse problemer knyttet til design og utvikling av komplekse programvaresystemer. Alt dette har ført til at DFD har blitt en av de svært populære notasjonene for den strukturelle tilnærmingen.

Et eksempel på et DFD-diagram er vist i diagrammet (fig. 87).

Ris. 87. Eksempel på et DFD-diagram

Før du begynner å se på syntaksen til DFD, bør det bemerkes separat at, i motsetning til SADT (IDEF0), er ikke DFD en metodikk. Med andre ord er DFD bare et sett med generelt aksepterte notasjoner uten strenge begrensninger på metodene for modellering og anvendelse av de resulterende modellene.

Ved gjennomføring av et IS-opprettingsprosjekt kan DFD-notasjonen brukes som hovedfunksjonell modelleringsnotasjon, men den brukes ofte som en tilleggsnotasjon i forhold til IDEF0 (fig. 88).

Informasjonsnettverk" href="/text/category/informatcionnie_seti/" rel="bookmark">informasjonsbehandling. I motsetning til IDEF0, hvor systemet betraktes som sammenkoblede funksjonsblokker, og buene representerer stive relasjoner, viser pilene i DFD kun hva hvordan objekter (inkludert data) beveger seg fra en jobb til en annen En DFD reflekterer de funksjonelle avhengighetene til verdier beregnet i et system, inkludert inngangsverdier, utgangsverdier og interne datalagre.

Med andre ord, en DFD er en graf som viser bevegelsen av dataverdier fra kildene deres gjennom prosessene som transformerer dem til sine forbrukere i andre objekter.

En DFD inneholder prosesser som transformerer data, datastrømmer som transporterer data, aktive objekter som produserer og forbruker data, og datalagre som passivt lagrer data.

Hvis vi snakker om uttrykkskraften til notasjonen og sammenligner DFD med IDEF0, kan vi si at fraværet av slike konsepter som kontroll og mekanisme reduserer potensialet til DFD kraftig når man analyserer en modell, identifiserer flaskehalser, finner måter å forbedre, etc. Alt dette førte til at DFD sjelden brukes som en grunnleggende notasjon i prosjekter for å omstrukturere forretningsprosesser, bygge et kvalitetsstyringssystem, etc.

DFD-modell

Typer DFD-notasjoner

ODA.: I DFD (Data Flow Diagram) er en systemmodell definert som et hierarki av dataflytdiagrammer som beskriver prosessene med å transformere informasjon fra det øyeblikket den legges inn i systemet til den utstedes til sluttbrukeren. Diagrammer over de øvre nivåene i hierarkiet - kontekstdiagrammer, setter grensene for modellen, definerer miljøet (eksterne innganger og utganger) og hovedprosessene som vurderes. Kontekstdiagrammer er detaljert ved hjelp av følgende diagramnivåer.

Siden DFD ikke er en standard, er det for øyeblikket ingen enkelt notasjon med sine unikt definerte primitiver. En rekke forskjellige DFD-notasjoner brukes til å representere modeller. De mest utbredte blant dem er Gein-Sarson- og Jodan/de Marco-notasjonene (fig. 89). I tillegg til disse notasjonene er det andre. For eksempel har notasjonen som brukes i CA BPwin sine egne egenskaper.

Ris. 89. Mest vanlige DFD-notasjoner

Til tross for eksistensen av flere forskjellige DFD-notasjoner, er de alle forskjellige bare i settet med grafiske primitiver som brukes til å bygge funksjonelle modeller.

DFD modellstruktur

Hierarkiet til DF-diagrammer er vist i diagrammet (fig. 90).

Koll" href="/text/category/koll/" rel="bookmark">utviklingsteam.

Etter å ha konstruert kontekstdiagrammer, bør den resulterende modellen kontrolleres for fullstendighet av innledende data om systemobjekter og isolasjon av objekter (fravær av informasjonsforbindelser med andre objekter).

For hvert delsystem som er tilstede på kontekstdiagrammene, er det detaljert ved hjelp av DFD. Hver prosess på DFD kan i sin tur detaljeres ved hjelp av en DFD eller mini-spesifikasjon. Ved detaljering skal avveiningsregelen følges. Essensen av denne regelen er at når du detaljerer et delsystem eller en prosess, kan detaljeringsdiagrammet bare ha de komponentene (delsystemer, prosesser, eksterne enheter, datalagringsenheter) som det detaljerte delsystemet eller prosessen på overordnet har en informasjonsforbindelse som eksternt. datakilder/mottakere diagram;

Minispesifikasjonen (beskrivelse av prosesslogikken) bør formulere hovedfunksjonene på en slik måte at spesialisten som implementerer prosjektet i fremtiden vil være i stand til å utføre dem eller utvikle et passende program.

Minispesifikasjonen er den siste toppen av DFD-hierarkiet. Beslutningen om å fullføre prosessdetaljeringen og bruke minispesifikasjonen tas av analytikeren basert på følgende kriterier:

– prosessen har et relativt lite antall inn- og utdatastrømmer (2-3 strømmer);

– evnen til å beskrive datatransformasjon ved en prosess i form av en sekvensiell algoritme;

– prosessen utfører en enkelt logisk funksjon for å konvertere inndatainformasjon til utdata;

– Evnen til å beskrive prosesslogikken ved hjelp av en liten minispesifikasjon (ikke mer enn 20-30 linjer).

Når du bygger et DFD-hierarki, bør du gå videre til detaljeringsprosesser først etter å ha bestemt innholdet i alle flyter og datastasjoner, som er beskrevet ved hjelp av datastrukturer. Datastrukturer er konstruert fra dataelementer og kan inneholde alternativer, betingede forekomster og iterasjoner. Betinget forekomst betyr at en gitt komponent kanskje ikke er tilstede i strukturen. Alternativ betyr at strukturen kan inneholde ett av de oppførte elementene. Iterasjon betyr å legge inn et hvilket som helst antall elementer i et spesifisert område. For hvert dataelement kan dets type (kontinuerlige eller diskrete data) spesifiseres. For kontinuerlige data kan måleenheten (kg, cm, etc.), verdiområde, presisjon av presentasjon og form for fysisk koding spesifiseres. For diskrete data kan en tabell med akseptable verdier spesifiseres.

Etter å ha bygget en komplett systemmodell, må den verifiseres (sjekkes for fullstendighet og konsistens). I en komplett modell må alle dens objekter (delsystemer, prosesser, datastrømmer) beskrives og detaljeres i detalj. Identifiserte ikke-detaljerte objekter bør detaljeres ved å gå tilbake til de forrige utviklingstrinnene. I en konsistent modell må alle datastrømmer og datalagringsenheter følge informasjonsoppbevaringsregelen: all data som kommer et sted må leses, og all data som leses må skrives.

Grunnleggende elementer i DFD og deres formål

DFD-syntaks inkluderer fire hovedelementer:

- data strøm;

- prosess;

- Oppbevaring;

- ekstern enhet.

La oss se nærmere på disse elementene.

Data strøm

ODA.: En dataflyt kobler utgangen til et objekt (eller prosess) til inngangen til et annet objekt (eller prosess). Den representerer mellomliggende beregningsdata. Dataflyten er avbildet som en pil mellom en dataprodusent og en dataforbruker, merket med navnene på de tilsvarende dataene. Enkelt sagt er datastrømmer mekanismer som brukes til å modellere overføring av informasjon (eller fysiske komponenter) fra en del av et system til en annen.

Strømmer i diagrammer er representert med piler (vanligvis navngitt), hvis orientering angir retningen informasjonen flyter i (fig. 91).

Ris. 91. Dataflyt

I motsetning til buer i IDEF0, kan datastrømmer i DFD ikke bare være ensrettet, men også toveis.

Prosess

ODA.: Prosessen transformerer dataverdier.

Prosesser representerer transformasjonen av inndatastrømmer til utdatastrømmer i samsvar med en spesifikk algoritme. I det virkelige liv kan prosessen utføres av en avdeling i organisasjonen som behandler inndatadokumenter og utsteder rapporter, av en individuell ansatt, av et program installert på en datamaskin, av en spesiell logisk enhet og lignende.

Formålet med en prosess er å produsere utgangsstrømmer fra inngangsstrømmer i samsvar med handlingen spesifisert av prosessnavnet. Dette navnet må inneholde et verb i ubestemt form etterfulgt av et objekt (for eksempel "utstede et pass"). I tillegg må hver prosess ha et unikt nummer for referanse i diagrammet. Dette nummeret kan brukes sammen med diagramnummeret for å gi en unik prosessindeks for hele modellen.

Som nevnt tidligere kan DFD-objekter på grunn av manglende enhetlig standard ha ulike betegnelser (fig. 92).

Det bør spesielt understrekes at, i motsetning til SADT, i DFD er alle sider av blokken likeverdige (dette er åpenbart hvis du ser på betegnelsen på prosessen i Jodan/de Marco-notasjonen). Med andre ord, i motsetning til IDEF0-diagrammer, bruker ikke DFD-diagrammer kontrollpiler for å indikere reglene for å utføre en handling og mekanismepiler for å indikere de nødvendige ressursene.

Databaser" href="/text/category/bazi_dannih/" rel="bookmark">databaser over organisasjonens informasjonssystem.

ODA. 2: DATALAGRING lar deg definere data i visse områder som vil bli lagret i minnet mellom prosesser. Faktisk representerer lageret "stykker" av datastrømmer over tid. Informasjonen den inneholder kan brukes når som helst etter at den er definert, og dataene kan velges i hvilken som helst rekkefølge. Depotnavnet må identifisere innholdet og være et substantiv. I tilfellet der en dataflyt kommer inn eller ut av et lager og strukturen samsvarer med strukturen til lageret, må den ha samme navn, som ikke trenger å vises i diagrammet.

I diagrammet er lageret angitt som vist i diagrammet (fig. 93).

https://pandia.ru/text/80/146/images/image009_14.gif" width="555" height="183 src=">

Ris. 94. Betegnelse av en ekstern enhet i forskjellige DFD-notasjoner

Et eksempel på bruk av eksterne enheter i kontekstdiagrammet er vist nedenfor (fig. 95). Under dekomponering må eksterne enheter overføres til underordnet diagram. CA BPwin har ikke muligheten til å automatisk overføre eksterne enheter til et underordnet diagram, så denne operasjonen må utføres manuelt.

https://pandia.ru/text/80/146/images/image011_14.gif" width="567" height="394 src=">

Ris. 96. Eksempel på et DFD-diagram

Konklusjoner:

Som det ble vist i begynnelsen av emnet, kan DFD betraktes som den viktigste funksjonelle modelleringsnotasjonen for IC-design. Med tanke på at IDEF0 også er en notasjon som gir en beskrivelse av organisasjonsøkonomiske og produksjonsteknologiske systemer, oppstår problemet med valg av notasjon ved gjennomføring av et spesifikt automatiseringsprosjekt. La oss prøve å svare på spørsmålet: i hvilket tilfelle vil DFD være å foretrekke, og i hvilken IDEF0?

Som det følger av den korte gjennomgangen av de sammenlignede notasjonene, har DFD en fordel fremfor IDEF0 når det gjelder å representere datastrukturer på modellen. Faktisk lar denne notasjonen deg designe en database allerede på funksjonsmodelleringsstadiet.

De alvorlige ulempene med DFD er at:

– for det første viser den uttrykkskraften til DFD-notasjonen seg å være utilstrekkelig når man analyserer modellen, identifiserer flaskehalser, søker etter måter å forbedre seg på, etc.;

– For det andre er ikke DFD en metodikk, som fører til muligheten for tvetydig tolkning av modelleringsresultater.

Alt dette lar oss si at bruken av DFD som en grunnleggende notasjon for funksjonell modellering er berettiget når det gjelder å utvikle et selvskrevet programvaresystem og det er ment å automatisere eksisterende forretningsprosesser uten å optimalisere dem, det vil si når vi er snakker om lappeteppeautomatisering.

Når det gjelder kompleks automatisering, når hovedviktigheten ikke er programmering, men søket etter forretningsoptimaliseringsløsninger, kan ikke DFD-notasjonen konkurrere med IDEF0 og kan bare betraktes som tillegg.

Tatt i betraktning at IT-trender tydelig viser blindveien til "patchwork-automatisering"-veien og behovet for å bevege seg bort fra selvskrevne systemer, blir det åpenbart hvorfor bruken av DFD-notasjon i aktivitetene til konsulentselskaper reduseres kraftig, og omvendt, populariteten til IDEF0 øker kraftig.

prosesser knyttet til datastrømmer. Dataflytdiagrammer vise hvordan hver prosess transformerer sine input til output, og avslør relasjonene mellom disse prosessene. DFD-diagrammer er vellykket brukt som et tillegg til IDEF0-modellen for å beskrive dokumentflyt og informasjonsbehandling. I likhet med IDEF0, representerer DFD systemet som modelleres som et nettverk av relaterte aktiviteter. Hovedkomponentene i DFD (som nevnt ovenfor) er prosesser eller aktiviteter, eksterne enheter, datastrømmer , datalagringsenheter(Oppbevaring).

Ris. 8.8.

BPwin bruker Hein-Sarson-notasjon for å konstruere dataflytdiagrammer.

For å supplere IDEF0-modellen med et DFD-diagram, må du "klikke" på DFD-radioknappen under dekomponeringsprosessen i Activity Box Count-dialogen. Nye knapper vises i verktøypaletten på det nye DFD-diagrammet:

(Ekstern referanse) - legg til en ekstern lenke til diagrammet;
(Datalager) - legg til diagrammet datalager ;
Editor for diagramordbok– lenke til en annen side. I motsetning til IDEF0 lar dette verktøyet deg rette pilen til et hvilket som helst diagram (ikke bare det øverste nivået).

I motsetning til IDEF0-piler, som representerer stive relasjoner, viser DFD-piler hvordan objekter (inkludert data) beveger seg fra en jobb til en annen. Dette er en representasjon av tråder sammen med datavarehus Og eksterne enheter gjør DFD-modeller mer lik de fysiske egenskapene til systemet - bevegelse av objekter, lagring av objekter, levering og distribusjon av objekter (fig. 8.9).

I motsetning til IDEF0, som ser på et system som sammenhengende aktiviteter, ser DFD på et system som en samling av elementer. Et kontekstdiagram inkluderer ofte verk og eksterne lenker. Verk omtales vanligvis med navnet på systemet, f.eks. "Informasjonsbehandlingssystem". Inkludert eksterne lenker i kontekstdiagram opphever ikke kravet til metodikken om å klart definere målet, omfanget og enkeltsynspunktet på det modellerte systemet.

Ris. 8.9.

I DFD arbeid(prosesser) er systemfunksjoner som transformerer innganger til utganger. Selv om verkene er avbildet som rektangler med avrundede hjørner, er deres betydning den samme som betydningen av IDEF0- og IDEF3-verkene. Akkurat som IDEF3-prosesser har de innganger og utganger, men støtter ikke kontroller og mekanismer som IDEF0 (Fig. 8.9) (blokkerer "Kontrollere og legge inn kunder", "Legge inn bestillinger").

Eksterne enheter skildre systempålogginger og/eller utlogginger. Eksterne enheter er avbildet som et rektangel med en skygge og er vanligvis plassert langs kantene av diagrammet (fig. 8.9, blokk "Kundeanrop"). ekstern enhet kan brukes flere ganger på ett eller flere diagrammer. Denne teknikken brukes vanligvis for å unngå å tegne for lange og forvirrende piler.

Arbeidsflyter er avbildet piler Og beskrive bevegelsen av objekter fra en del av systemet til en annen. Siden i DFD hver side av arbeidet ikke har en klar hensikt, som i IDEF0, kan piler komme inn og ut av hvilken som helst kant av arbeidsrektangelet. DFD bruker også toveispiler for å beskrive kommando-svar-dialoger mellom jobber, mellom jobber og ekstern enhet og mellom eksterne enheter(Fig. 8.9).

I motsetning til piler som beskriver objekter i bevegelse,

Dataflytdiagrammer(Data Flow Diagrams - DFD) representerer et hierarki av funksjonelle prosesser forbundet med dataflyter. Hensikten med en slik representasjon er å demonstrere hvordan hver prosess transformerer sine input til output, samt å avsløre relasjonene mellom disse prosessene.

To forskjellige notasjoner brukes tradisjonelt for å konstruere DFD-er, tilsvarende Jordan-DeMarco- og Gain-Sarson-metodene. Disse notasjonene skiller seg litt fra hverandre i den grafiske representasjonen av symboler (heretter, i eksemplene, brukes Gein-Sarson-notasjonen).

I samsvar med denne metoden er systemmodellen definert som et hierarki av dataflytdiagrammer som beskriver den asynkrone prosessen med å transformere informasjon fra inndata i systemet til levering til forbruker. Informasjonskilder (eksterne enheter) genererer informasjonsstrømmer (datastrømmer) som overfører informasjon til undersystemer eller prosesser. Disse transformerer igjen informasjon og genererer nye strømmer som overfører informasjon til andre prosesser eller undersystemer, datalagringsenheter eller eksterne enheter - informasjonsforbrukere.

Diagrammer på de øverste nivåene i hierarkiet (kontekstdiagrammer) definerer hovedprosessene eller undersystemene med eksterne innganger og utganger. De er detaljert ved hjelp av diagrammer på lavere nivå. Denne dekomponeringen fortsetter, og skaper et flernivåhierarki av diagrammer, inntil et dekomponeringsnivå er nådd der det ikke gir mening å detaljere prosessene ytterligere.

Sammensetning av dataflytdiagrammer

Hovedkomponentene i dataflytdiagrammer er: eksterne enheter; systemer og delsystemer; prosesser; datalagringsenheter; datastrømmer.

Ekstern enhet representerer et materiell objekt eller individ som er kilden eller mottakeren av informasjon, for eksempel kunder, personell, leverandører, klienter, lager. Å definere et objekt eller system som en ekstern enhet indikerer at det er utenfor grensene til systemet som analyseres. Under analyseprosessen kan noen eksterne enheter overføres inne i diagrammet til det analyserte systemet, om nødvendig, eller omvendt, noen prosesser kan flyttes utenfor diagrammet og presenteres som en ekstern enhet.

Den eksterne enheten er indikert med en firkant (fig. 1), plassert over diagrammet og kaster en skygge på det slik at dette symbolet kan skilles fra andre betegnelser.

Figur 1. Grafisk representasjon av en ekstern enhet

Når du bygger en modell av et komplekst system, kan den presenteres i den mest generelle formen på det såkalte kontekstdiagrammet i form av ett system som en enkelt helhet, eller den kan dekomponeres i en rekke delsystemer. Et delsystem (eller system) er avbildet på et kontekstdiagram slik det er vist i fig. 2.

Figur 2. Delsystem for arbeid med enkeltpersoner (BNI - Statens skattetilsyn)

Delsystemnummeret tjener til å identifisere det. I navnefeltet skriver du inn navnet på delsystemet i form av en setning med et emne og tilsvarende definisjoner og tillegg.

Prosess representerer transformasjonen av inndatastrømmer til utdatastrømmer i samsvar med en viss algoritme. Fysisk kan prosessen implementeres på ulike måter: det kan være en avdeling av organisasjonen (avdelingen) som behandler inngangsdokumenter og utsteder rapporter, et program, en maskinvare-implementert logisk enhet, etc. Prosessen i et dataflytdiagram er avbildet som vist i fig. 3.

Figur 3. Grafisk fremstilling av prosessen

Prosessnummeret tjener til å identifisere det. I navnefeltet skriver du inn navnet på prosessen i form av en setning med et aktivt, entydig verb i ubestemt form (beregn, beregne, sjekke, bestemme, opprette, motta), etterfulgt av substantiv i akkusativ bokstav, for eksempel: "Legg inn opplysninger om skattytere", "Utstede opplysninger om løpende utgifter", "Sjekk kvittering av penger". Informasjonen i det fysiske implementeringsfeltet indikerer hvilken organisasjonsenhet, program eller maskinvareenhet som utfører prosessen.

Datalagring- dette er en abstrakt enhet for lagring av informasjon som kan plasseres i en stasjon når som helst og hentes etter en stund, og metodene for lagring og gjenfinning kan være hvilken som helst. Datalagringsenheten kan implementeres fysisk i form av en mikrofiche, en boks i et arkivskap, et bord i RAM, en fil på magnetiske medier, etc. Datalageret i dataflytdiagrammet er avbildet som vist i fig. 4.

Figur 4. Grafisk representasjon av datalagringsenheten

Datalagringsenheten identifiseres med bokstaven "D" og et vilkårlig tall. Stasjonsnavnet er valgt for å være mest informativt for designeren. Generelt er en datalagringsenhet en prototype av en fremtidig database, og beskrivelsen av dataene som er lagret i den må samsvare med datamodellen.

Dataflyten i diagrammet er representert med en linje som slutter med en pil som viser strømningsretningen (fig. 5).

Hver datastrøm har et navn som gjenspeiler innholdet.

Figur 5. Dataflyt

Bygge et hierarki av dataflytdiagrammer

Hovedmålet med å konstruere et DFD-hierarki er å gjøre systembeskrivelsen klar og forståelig på hvert detaljnivå, og å bryte den ned i deler med nøyaktig definerte forhold mellom dem. For å oppnå dette, anbefales det å bruke følgende anbefalinger:

Plasser fra 3 til 6-7 prosesser på hvert diagram (ligner på SADT). Den øvre grensen tilsvarer menneskets evne til samtidig å oppfatte og forstå strukturen til et komplekst system med mange interne forbindelser, den nedre grensen er valgt av hensyn til sunn fornuft: det er ikke nødvendig å detaljere prosessen med et diagram som inneholder bare en eller to prosesser.

Ikke fyll diagrammene med detaljer som er uviktige på dette nivået.

Dekomponering av datastrømmer utføres parallelt med dekomponering av prosesser. Disse to jobbene skal gjøres samtidig, ikke den ene etter den andre er fullført.

Velg klare, beskrivende navn for prosesser og tråder, og prøv å ikke bruke forkortelser.

Det første trinnet i å konstruere et DFD-hierarki er å konstruere kontekstdiagrammer. Vanligvis, når man designer relativt enkle systemer, bygges et enkelt kontekstdiagram med en stjernetopologi, i sentrum av denne er den såkalte hovedprosessen, koblet til synkene og informasjonskildene som brukere og andre eksterne systemer samhandler med system. Før du bygger en kontekstuell DFD, er det nødvendig å analysere eksterne hendelser (eksterne enheter) som påvirker funksjonen til systemet. Antall tråder i et kontekstdiagram bør være så lite som mulig, siden hver av dem kan brytes ytterligere ned i flere tråder på etterfølgende nivåer i diagrammet.

For å teste kontekstdiagrammet kan du lage en liste over hendelser. Listen over hendelser bør bestå av beskrivelser av handlingene til eksterne enheter (hendelser) og de tilsvarende systemreaksjonene på hendelser. Hver hendelse må tilsvare én eller flere datastrømmer: inngangsstrømmer tolkes som påvirkninger, og utgangsstrømmer tolkes som systemreaksjoner på inngangsstrømmer.

For komplekse systemer (tegn på kompleksitet kan være tilstedeværelsen av et stort antall eksterne enheter (ti eller flere), systemets distribuerte natur eller dets multifunksjonalitet), bygges et hierarki av kontekstdiagrammer. Samtidig inneholder kontekstdiagrammet på øverste nivå ikke en enkelt hovedprosess, men et sett med delsystemer koblet sammen av datastrømmer. Det neste nivået av kontekstdiagrammer beskriver konteksten og strukturen til delsystemer. For hvert delsystem som er tilstede på kontekstdiagrammene, er det detaljert ved hjelp av DFD. Dette kan gjøres ved å plotte et diagram for hver hendelse. Hver hendelse er representert som en prosess med tilhørende input- og outputstrømmer, datalagre, eksterne enheter og referanser til andre prosesser for å beskrive relasjonene mellom den prosessen og dens miljø. Deretter kombineres alle de konstruerte diagrammene til ett nullnivådiagram.

Hver prosess på en DFD kan på sin side detaljeres ved hjelp av en DFD eller (hvis prosessen er elementær) en spesifikasjon. Prosessspesifikasjonen bør formulere hovedfunksjonene på en slik måte at spesialisten som implementerer prosjektet i fremtiden vil være i stand til å utføre dem eller utvikle et passende program.

Spesifikasjonen er den siste toppen av DFD-hierarkiet. Beslutningen om å fullføre prosessdetaljeringen og bruken av spesifikasjonen tas av analytikeren basert på følgende kriterier:

Prosessen har et relativt lite antall inn- og utdatastrømmer (2-3 strømmer);

Mulighet for å beskrive transformasjonen av dataprosesser i form av en sekvensiell algoritme;

Prosessen utfører en enkelt logisk funksjon for å konvertere inndatainformasjon til utdata;

Mulighet for å beskrive prosesslogikken ved hjelp av en liten spesifikasjon (ikke mer enn 20-30 linjer).

Spesifikasjoner er beskrivelser av algoritmer for oppgaver utført av prosesser. De inneholder nummeret og/eller navnet på prosessen, lister over inn- og utdata, og kroppen (beskrivelse) av prosessen, som er spesifikasjonen til en algoritme eller operasjon som transformerer inndatastrømmer til utdata. Spesifikasjonsspråk kan variere fra strukturert naturlig språk eller pseudokode til visuelle modelleringsspråk.

Strukturert naturlig språk brukes til å beskrive prosessspesifikasjoner på en klar, tilstrekkelig streng måte. Følgende konvensjoner aksepteres når du bruker den:

Prosesslogikk uttrykkes som en kombinasjon av sekvensielle konstruksjoner, valgkonstruksjoner og iterasjoner;

Verb skal være aktive, entydige og handlingsorienterte (fylle ut, beregne, trekke ut, ikke oppgradere, behandle);

Logikken i prosessen må uttrykkes klart og entydig.

Når du bygger et DFD-hierarki, bør du gå videre til detaljeringsprosesser først etter å ha bestemt innholdet i alle flyter og datastasjoner, som er beskrevet ved hjelp av datastrukturer. For hver datastrøm genereres en liste over alle dataelementene, deretter kombineres dataelementene til datastrukturer som tilsvarer større dataobjekter (for eksempel dokumentstrenger eller domeneobjekter). Hvert objekt må bestå av elementer som er dets attributter. Datastrukturer kan inneholde alternativer, betingede forekomster og iterasjoner. En betinget forekomst betyr at komponenten kanskje ikke finnes i strukturen (for eksempel forsikringsdatastrukturen for arbeidstakerobjektet). Alternativ betyr at strukturen kan inneholde ett av de oppførte elementene. Iterasjon betyr forekomsten av et hvilket som helst antall elementer i et spesifisert område (for eksempel elementet "barnets navn" for objektet "ansatt"). For hvert dataelement kan dets type (kontinuerlige eller diskrete data) spesifiseres. For kontinuerlige data kan måleenhet, verdiområde, presisjon av presentasjon og form for fysisk koding spesifiseres. For diskrete data kan en tabell med akseptable verdier spesifiseres.

I forretningsprosessmodellering brukes dataflytdiagrammer (DFD-er) til å bygge AS-IS og AS-TO-BE-modeller, og reflekterer dermed den eksisterende og foreslåtte strukturen til en organisasjons forretningsprosesser og interaksjonene mellom dem. I dette tilfellet utføres beskrivelsen av dataene som brukes i organisasjonen på et konseptuelt nivå, uavhengig av midlene for å implementere databasen, ved å bruke "entity-relationship"-modellen.

Nedenfor er hovedtypene og sekvensen av arbeid når du bygger forretningsmodeller ved å bruke Yordon-metodikken:

1. Beskrivelse av prosesskonteksten og konstruksjon av det innledende kontekstdiagrammet.

Det innledende kontekstuelle dataflytdiagrammet bør inneholde prosess null med et navn som gjenspeiler organisasjonens aktiviteter, eksterne enheter knyttet til prosess null gjennom dataflyter. Dataflyter tilsvarer dokumenter, forespørsler eller meldinger som eksterne enheter utveksler med en organisasjon.

2. Spesifikasjon av datastrukturer.

Sammensetningen av datastrømmer bestemmes og innledende informasjon utarbeides for å konstruere en konseptuell datamodell i form av datastrukturer. Alle strukturer og dataelementer av typene "iterasjon", "betinget forekomst" og "alternative" er uthevet. Enkle strukturer og dataelementer kombineres til større strukturer. Som et resultat må det for hver dataflyt dannes en hierarkisk (tre) struktur, hvor de siste elementene (bladene) er dataelementer, trenodene er datastrukturer, og toppnoden i treet tilsvarer dataflyten som en hel.

3. Konstruksjon av den første versjonen av den konseptuelle datamodellen. For hver klasse av domeneobjekter tildeles en enhet. Forbindelser mellom enheter etableres og deres egenskaper bestemmes. Et enhetsforholdsdiagram er konstruert (uten enhetsattributter).

4. Konstruksjon av dataflytdiagrammer av null og påfølgende nivåer.

For å fullføre analysen av det funksjonelle aspektet ved organisasjonens aktiviteter, er det innledende kontekstdiagrammet detaljert (dekomponert).

I dette tilfellet kan du bygge et diagram for hver hendelse, tilordne en prosess til den og beskrive inngangs- og utdatastrømmer, datastasjoner, eksterne enheter og koblinger til andre prosesser for å beskrive forbindelsene mellom denne prosessen og dens miljø. Etter dette blir alle konstruerte diagrammer kombinert til ett nullnivådiagram.

Prosesser er delt inn i grupper som har mye til felles (arbeider med samme data og/eller har lignende funksjoner). De er avbildet sammen på et lavere (første) nivådiagram, og på et nullnivådiagram er de kombinert til én prosess. Datalagringsenheter som brukes av prosesser fra samme gruppe tildeles.

Komplekse prosesser dekomponeres og etterlevelsen av ulike nivåer av prosessmodellen kontrolleres.

Datalagringsenheter er beskrevet gjennom datastrukturer, og prosesser på lavere nivå er beskrevet gjennom spesifikasjoner.

5. Foredling av den konseptuelle datamodellen.

Entitetsattributter er definert. Identifikatorattributter er uthevet. Tilkoblinger kontrolleres og supertype-subtype-forbindelser identifiseres (om nødvendig). Samsvaret mellom beskrivelsen av datastrukturer og den konseptuelle modellen kontrolleres (alle dataelementer må være tilstede på diagrammet som attributter).