Utvikling av et dataprogram i idef0. Kurs: Utvikling av en drivhusmodell ved bruk av IDEF0, DFD og IDEF3 designmetoder

SADT-metodikk (Strukturert analyse og designteknikk - metodikk for strukturanalyse og design) er et sett med metoder, regler og prosedyrer designet for å bygge en funksjonell modell av et system.

Utviklingen av denne metoden ble initiert av Douglas Ross (USA) på midten av 60-tallet. XX århundre. Siden den gang har systemanalytikere fra SofTech, Inc. forbedret SADT og brukte den i å løse bred rekkevidde problemer. Telefonnettverksprogramvare, diagnostikk, langsiktig og strategisk planlegging, automatisert produksjon og prosjektering, datamaskinsystemkonfigurasjon, personalopplæring, økonomi- og anskaffelsesledelse er noen av områdene der SADT kan brukes effektivt. Det brede spekteret av områder indikerer allsidigheten og kraften til SADT-metoden. Det amerikanske forsvarsdepartementets Integrated Computer Aided Manufacturing (ICAM) -program har anerkjent nytten av SADT. Dette førte til publisering av en del av den i 1981, kalt IDEF0 (Icam DEFinition), som en føderal standard for programvareutvikling. Under dette navnet har SADT blitt brukt av tusenvis av fagpersoner i militære og industrielle organisasjoner. Den siste revisjonen av IDEF0-standarden ble utgitt i desember 1993. National Institute of Standards and Technology (NIST).

Denne metoden når man beskriver det funksjonelle aspektet informasjon System konkurrerer med datastrømningsorienterte (DFD) metoder. I motsetning tillater IDEF0:

Beskriv eventuelle systemer, ikke bare informasjonssystemer (DFD er ment å beskrive programvare);

Lag en beskrivelse av systemet og dets eksterne miljø før du definerer de endelige kravene til det. Med andre ord, ved å bruke denne metoden kan du gradvis bygge og analysere systemet selv når det er vanskelig å forestille seg implementeringen.

Dermed kan IDEF0 brukes i de tidlige stadiene av å bygge et bredt spekter av systemer. Samtidig kan den brukes til å analysere funksjonene til eksisterende systemer og utvikle løsninger for forbedring av dem.

IDEF0-metoden er basert på et grafisk prosessbeskrivelsesspråk. En modell i IDEF0-notasjon er en samling hierarkisk ordnede og sammenkoblede diagrammer. Hvert diagram er en enhet av systembeskrivelsen og ligger på et eget ark.

Modellen (AS-IS, TO-BE eller BOR-BE) kan inneholde 4 typer diagrammer [ , ]:

Kontekstdiagram;

Nedbrytningsdiagrammer;

Node-diagrammer;

For kun utlegging av diagrammer (FEO).

Kontekstdiagram (øverste nivådiagram), som er toppen av trestrukturen i diagrammer, viser formålet med systemet (hovedfunksjon) og dets interaksjon med eksternt miljø... Hver modell kan bare ha ett kontekstdiagram. Etter beskrivelsen av hovedfunksjonen utføres funksjonell nedbrytning, det vil si funksjonene som utgjør den viktigste bestemmes.

Videre er funksjonene delt inn i underfunksjoner og så videre til det nødvendige detaljnivået til systemet som studeres er nådd. Diagrammene som beskriver hvert slike fragment av systemet kalles nedbrytningsdiagrammer ... Etter hver dekomponeringsøkt holdes eksamensøkter - fagområdet eksperter indikerer korrespondansen mellom virkelige prosesser og de opprettede diagrammene. De funnet inkonsekvensene elimineres, og deretter fortsetter de med å detaljere prosessene.

Node-treddiagram viser funksjoner (verk) hierarkiske avhengighet, men ikke forholdet mellom dem. Det kan være flere av dem, siden treet kan bygges til en vilkårlig dybde og fra en vilkårlig node.

Eksponeringskart er bygget for å illustrere individuelle fragmenter av modellen for å vise et alternativt synspunkt på prosessene som forekommer i systemet (for eksempel fra organisasjonens ledelsens synspunkt).

6.3. Elementer av den grafiske notasjonen IDEF0

IDEF0-metoden har funnet bred aksept og anvendelse, først og fremst på grunn av den enkle grafiske notasjonen som ble brukt til å bygge modellen. Hovedkomponentene i modellen er diagrammer. De viser systemets funksjoner i form av rektangler, samt forbindelsene mellom dem og det ytre miljøet ved hjelp av piler. Ved å bruke bare to grafiske primitiver (rektangel og pil) kan du raskt forklare reglene og prinsippene for å bygge IDEF0-diagrammer til folk som ikke er kjent med denne metoden. Denne fordelen lar deg koble til og aktivere kundens aktivitet i å beskrive forretningsprosesser ved hjelp av et formelt og visuelt grafisk språk.

Følgende figur viser de grunnleggende elementene i den grafiske IDEF0-notasjonen.

Figur: 6.1. Elementer av den grafiske notasjonen IDEF0

Rektangelet representerer arbeid (prosess, aktivitet, funksjon eller oppgave) , som har et fast mål og fører til noe sluttresultat. Verkets navn skal uttrykke handlingen (for eksempel "Fremstilling av en del", "Beregning av tillatte hastigheter", "Dannelse av listen over det sentraliserte husnummer 3").

Samspillet mellom verk mellom seg selv og omverdenen er beskrevet i form av piler. IDEF0 skiller seg ut 5 typer piler :

- inngang (Engelsk input) - materiale eller informasjon som brukes og transformeres av arbeid for å oppnå et resultat (output). Innlogging svarer på spørsmålet "Hva skal behandles?" Inndataene kan enten være et materielt objekt (råvare, en del, en eksamensbillett) eller en som ikke har klare fysiske konturer (et spørsmål til databasen, et spørsmål fra en lærer). Det antas at verket ikke kan ha noen inngangspiler. Inngangspiler tegnes alltid når de kommer inn på venstre side av verket;

- styre (Engelsk kontroll) - kontroll, regulatoriske og normative data som styrer arbeidet. Avdelingen svarer på spørsmålet "I samsvar med hva gjøres arbeidet?" Ledelse påvirker arbeid, men blir ikke forvandlet av det, dvs. fungerer som en begrensning. Som ledelse kan det være regler, standarder, forskrifter, priser, muntlige instruksjoner. Kontrollpilene er tegnet som en del av arbeidets overside. Hvis det når du bygger et diagram, oppstår spørsmålet om hvordan du tegner en pil riktig ovenfra eller til venstre, anbefales det å tegne den som en inngang (pil til venstre);

- exit (Engelsk produksjon) - materiale eller informasjon som representerer resultatet av arbeidet. Resultatet svarer på spørsmålet "Hva er resultatet av arbeidet?" Utdataene kan være enten et materielt objekt (en del, en bil, betalingsdokumenter, en uttalelse) eller en immateriell (datautvalg fra en database, et svar på et spørsmål, en muntlig indikasjon). Utgangspiler trekkes utgående fra høyre side av arbeidet;

- mekanisme (Eng. Mekanisme) - ressurser som utfører arbeid. Mekanismen svarer på spørsmålet "Hvem gjør arbeidet eller på hva betyr det?" Mekanismen kan være et bedriftspersonell, student, maskin, utstyr, program. Pilene på mekanismen er tegnet når de kommer inn i arbeidets nedre flate;

- anrop (Engelsk samtale) - pilen indikerer at noe av arbeidet utføres utenfor den aktuelle blokken. Utgangspiler trekkes ut av underkanten av verket.

6.4. Typer koblinger mellom jobber

Etter å ha bestemt funksjonssammensetningen og forholdet mellom dem, oppstår spørsmålet om deres korrekte sammensetning (tilknytning) i moduler (delsystemer). Dette innebærer at hver enkelt funksjon må løse ett, strengt definert problem. Ellers kreves ytterligere spaltning eller separasjon av funksjoner.

Når du kombinerer funksjoner i delsystemer, er det nødvendig å streve for at den interne tilkoblingen (mellom funksjonene i en modul) skal være så sterk som mulig, og ekstern (mellom funksjonene som er inkludert i forskjellige moduler) så svak som mulig. Basert på semantikken til metodologikoblingene, vil vi introdusere en klassifisering av koblinger mellom funksjoner (verk). Denne klassifiseringen er en utvidelse. Typer obligasjoner er listet i rekkefølge av avtagende betydning (bindingsstyrke). I de gitte eksemplene fremhever fortykkede linjer funksjoner som det er den aktuelle forbindelsestypen mellom.

1. Hierarkisk forhold (forhold "del" - "helhet") finner sted mellom funksjonen og underfunksjonene den består av.

Figur: 6.2. Hierarkisk forhold

2. Regulerende (kontroll, underordnet) kommunikasjon gjenspeiler avhengigheten av en funksjon til en annen, når utgangen fra en jobb sendes for å kontrollere en annen. Funksjonen som kontrollen går fra, bør betraktes som regulerende eller kontrollerende, og som den kommer inn i - underordnet. Skille direkte kontrolllenke når kontroll overføres fra et arbeid på høyere nivå til et lavere nivå (figur 6.3), og ledelsens tilbakemeldinger når kontroll overføres fra nedstrøms til oppstrøms (fig. 6.4).

3. Funksjonell (teknologisk) kommunikasjon oppstår når utgangen fra en funksjon fungerer som inngang til neste funksjon. Fra synspunktet til strømmen av materielle objekter viser dette forholdet teknologien (arbeidssekvensen) for å behandle disse objektene. Skille direkte inngangstilkobling når utgangen overføres fra arbeid på høyere nivå til lavere nivå (fig. 6.5), og innspill tilbakemelding når utgangen overføres fra nedstrøms til oppstrøms (figur 6.6).

Figur: 6.5. Direkte inngangskommunikasjon	Figur: 6.6. Inngangsfeedback

4. Forbrukerkommunikasjon oppstår når utgangen fra en funksjon fungerer som mekanismen for neste funksjon. Dermed bruker den ene funksjonen ressursene som genereres av den andre.

Figur: 6.7. Forbrukerkommunikasjon

5. Logisk lenke observert mellom logisk homogene funksjoner. Slike funksjoner utfører som regel det samme arbeidet, men på forskjellige (alternative) måter eller ved bruk av forskjellige innledende data (materialer).

Figur: 6.8. Logisk lenke

6. Kollegial (metodisk) kommunikasjon finner sted mellom funksjoner hvis operasjonsalgoritme bestemmes av samme kontroll. En analog av slik kommunikasjon er det felles arbeidet til ansatte i en avdeling (kolleger), underordnet sjefen, som gir instruksjoner og ordrer (kontrollsignaler). En slik forbindelse oppstår også når algoritmene for driften av disse funksjonene bestemmes av samme metodiske støtte (SNIP, GOST, offisielle reguleringsmaterialer, etc.), som fungerer som ledelse.

Figur: 6.9. Metodisk forbindelse

7. Ressurstilkobling oppstår mellom funksjoner som bruker de samme ressursene for arbeidet sitt. Ressursavhengige funksjoner kan vanligvis ikke kjøres samtidig.

Figur: 6.10. Ressurstilkobling

8. Informasjonskommunikasjon foregår mellom funksjoner som bruker samme informasjon som inngang.

Figur: 6.11. Informasjonskommunikasjon

9. Midlertidig forbindelse oppstår mellom funksjoner som må utføres samtidig før eller samtidig etter en annen funksjon.

I tillegg til tilfellene som er angitt i figuren, finner denne forbindelsen også sted mellom andre kombinasjoner av kontroll, inngang og mekanisme, og går inn i en funksjon.

Figur: 6.12. Midlertidig forbindelse

10. Tilfeldig tilkobling oppstår når det er liten eller ingen spesifikk sammenheng mellom funksjonene.

Figur: 6.13. Tilfeldig tilkobling

Av de ovennevnte koblingstypene er den sterkeste den hierarkiske lenken, som faktisk bestemmer kombinasjonen av funksjoner i moduler (delsystemer). Regulerende, funksjonelle og forbrukerbånd er noe svakere. Funksjoner med disse koblingene er vanligvis implementert i ett delsystem. Logiske, kollegiale, ressurs- og informasjonsforbindelser er blant de svakeste. Funksjonene som har dem, er som regel implementert i forskjellige delsystemer, med unntak av logisk homogene funksjoner (funksjoner forbundet med logisk tilkobling). Midlertidig tilkobling indikerer en svak avhengighet av funksjoner fra hverandre og krever implementering i separate moduler.

Når man kombinerer funksjoner i moduler, er de fem første koblingstyper mest ønskelige. Funksjonene knyttet til de fem siste koblingene implementeres best i separate moduler.

IDEF0 har konvensjoner (regler og retningslinjer) for å lage diagrammer for å gjøre det lettere å lese og undersøke [,] modellen. Noen av disse reglene håndteres automatisk av CASE-verktøy, andre må håndheves manuelt.

1. Før du bygger en modell, er det nødvendig å bestemme hvilken modell (er) av systemet som skal bygges. Dette betyr å definere typen AS-IS, TO-BE eller SHOULD-BE, samt å definere posisjonen modellen er bygget fra. "Synspunktet" er best tenkt som et sted (posisjon) for en person eller gjenstand, der man må stå for å se systemet i aksjon. Når du for eksempel bygger en modell for driften av en dagligvarebutikk, kan du velge en selger, kasserer, regnskapsfører eller direktør blant de mulige søkerne fra hvilket synspunkt systemet vurderes. Vanligvis blir det valgt et synspunkt som dekker alle nyansene i systemets drift, og om nødvendig er FEO-diagrammer laget for noen dekomponeringsdiagrammer, og viser et alternativt synspunkt.

2. Kontekstdiagrammet viser en blokk som viser systemets formål. For det anbefales det å vise 2–4 piler som går inn og ut fra hver side.

3. Antall blokker på nedbrytningsdiagrammene anbefales innenfor området 3–6. Hvis det er to blokker i nedbrytningsdiagrammet, gir det vanligvis ikke mening. Med et stort antall blokker blir diagrammet overmettet og vanskelig å lese.

4. Blokker på nedbrytningsdiagrammet skal ordnes fra venstre til høyre og fra topp til bunn. Denne ordningen lar deg tydeligere gjenspeile logikken og sekvensen av arbeidet. I tillegg vil pilruter være mindre forvirrende og ha et minimum antall kryss.

5. Fraværet av både kontroll- og inngangspiler for funksjonen er ikke tillatt. Dette betyr at lanseringen av denne funksjonen ikke kontrolleres og kan forekomme når som helst eller aldri i det hele tatt.

Figur: 6.14. Funksjon uten kontroll og inngang

En blokk med bare kontroll kan sees på som et anrop i et funksjonsprogram (prosedyre) uten parametere. Hvis blokken har en inngang, tilsvarer det å ringe en funksjon med parametere i programmet. Dermed tilsvarer en blokk uten kontroll og inngang en funksjon som aldri kalles til utføring i programmet.

I fig. 6.7-6.12, viser fragmenter av IDEF0-diagrammer, det er blokker uten inngang og kontroll. Dette skal ikke sees på som en feil, da det innebærer at en av disse pilene må være.

6. Hver blokk må ha minst ett utløp.

Figur: 6.15. Ingen utgangsfunksjon

Arbeider uten resultater er meningsløse og skal ikke modelleres. Unntak er jobber som vises i AS-IS-modellen. Deres tilstedeværelse indikerer ineffektivitet og ufullkommenhet. teknologiske prosesser... I TO-BE-modellen skal disse verkene være fraværende.

7. Når du konstruerer diagrammer, bør du minimere antall kryss, sløyfer og sving av piler.

8. Tilbakemelding og iterasjoner (sykliske handlinger) kan skildres ved hjelp av bakoverbuer. Tilbakemelding på inngangen er trukket av "nedre" sløyfe, tilbakemelding på kontroll - av "øvre" (se fig. 6.4 og 6.6).

9. Hver blokk og hver pil i diagrammene må ha et navn. Du kan bruke forgrenings- (dekomponering) eller sammenslåing (komposisjon). Dette skyldes at de samme dataene eller objektene som genereres av en jobb, kan brukes i flere andre jobber samtidig. Omvendt kan de samme eller homogene dataene og objektene generert av forskjellige jobber brukes på ett sted.

Figur: 6.16. Forgreningspiler

Samtidig er det lov å tildele kvalifiserende navn til forskjellige grener av pilen etter forgrening (før sammenslåing). Hvis en gren etter grenen ikke er navngitt, anses navnet å svare til pilnavnet som er registrert før grenen.

Så i fig. 6.16 kontroller inkludert i blokkene "Produksjon av deler" og "Montering av produktet" har klargjørende betydninger og er en integrert del av mer generell ledelse "Tegninger". Alle tegninger brukes til drift av kvalitetskontrollblokken.

Det er ikke tillatt å tegne piler i diagrammet når de ikke er oppkalt før og etter forgrening. I fig. 6.17 pilen som er inkludert i blokken "Generering av standardlister" har ikke noe navn før og etter forgrening, noe som er en feil.

Figur: 6.17. Feil pilnavn

10. Når du bygger diagrammer for bedre lesbarhet, kan piltunnelmekanismen brukes. For eksempel, for ikke å rote opp diagrammene til de øvre nivåene (foreldre) med unødvendige detaljer, i nedbrytningsdiagrammene er begynnelsen på buen plassert i tunnelen.

Figur: 6.18. Tunnelpiler

I dette eksemplet, når man bygger en modell for å holde et nyttårsfest, vil ikke "to akser" -mekanismen vises på diagrammene for de øvre nivåene, mens man leser hvilket et rettferdig spørsmål kan oppstå: "Hvorfor er to akser nødvendig på et nyttårsfest?"

På samme måte kan du tunnelere med det motsatte målet - ikke la pilen vises på diagrammer på lavere nivå. I dette tilfellet plasseres parenteser på slutten av pilen. På kontekstdiagrammet (se fig. 6.21) tunnles "Path Service Engineer" -mekanismen, som er inkludert i blokken "Bestemmelse av tillatte hastigheter". Denne avgjørelsen ble tatt fordi ingeniøren er direkte involvert i alt arbeidet som vises i nedbrytningsdiagrammet til denne blokken (se figur 6.22). For ikke å vise denne forbindelsen og ikke forstyrre nedbrytningsdiagrammet, ble pilen tunnelert.

11. Alle piler som kommer inn og ut av blokken, når de bygger et nedbrytningsdiagram for den, skal vises på den. Unntaket er tunnelpiler. Navnene på pilene som blir dratt til nedbrytningsdiagrammet, må samsvare med navnene som vises på toppdiagrammet.

12. Hvis to piler går parallelle (starter fra samme fasett av en jobb og slutter på samme fasett av den andre jobben), bør de, hvis mulig, kombineres og kalles et enkelt begrep.

Figur: 6.19. Sammenslåing av lenker

13. Hver blokk i diagrammene må ha sitt eget nummer. Kartnumre brukes til å indikere posisjonen til et hvilket som helst diagram eller blokk i hierarkiet. Blokken på toppnivå diagrammet er betegnet med 0, blokkene på andre nivå diagrammene - med tall fra 1 til 9 (1, 2, ..., 9), blokkene på tredje nivå - med to tall, hvorav den første indikerer nummeret på den detaljerte blokken fra foreldrediagrammet, og det andre blokknummeret i rekkefølge på gjeldende diagram (11, 12, 25, 63) osv. Kontekstdiagrammet har betegnelsen "A - 0", det første nivåets dekomponeringsdiagram er "A0", dekomponeringsdiagrammene for de neste nivåene består av bokstaven " A "etterfulgt av nummeret på blokken som skal spaltes (for eksempel" A11 "," A12 "," A25 "," A63 "). Figuren viser et typisk diagrammet (nodetre-diagram) med nummerering.

Figur: 6.20. Hierarki av diagrammer

I moderne CASE-verktøy støttes arbeidsnummereringsmekanismer automatisk. CASE-verktøy gir også automatisk konstruksjon av nodetre-diagrammer som bare inneholder hierarkiske lenker. Toppen av et slikt diagram kan være hvilken som helst node (blokk), og den kan plottes til en hvilken som helst dybde.

6.6. Et eksempel på å bygge en IDEF0-modell for et system for å bestemme tillatte hastigheter

Å beregne tillatte toghastigheter er en møysommelig ingeniøroppgave. Når et tog passerer en hvilken som helst del, bør ikke den faktiske hastigheten på toget overstige den maksimalt tillatte hastigheten. Denne maksimale tillatte hastigheten er innstilt på grunnlag av driftserfaring og spesialutførte tester på bevegelsesdynamikken og påvirkningen på rullende materiell. Å ikke overskride denne hastigheten garanterer togtrafikkens sikkerhet, komfortable forhold for passasjerer osv. De bestemmes avhengig av typen rullende materiell (lokomotiv og vogntype), parametere for overbygningen (som skinner, ballast, sviller) og plan (radius kurver, overgangskurver, høyde på ytre skinne osv.). For å fastslå de tillatte hastighetene er det som regel nødvendig å bestemme minst to (på rette linjer) og fem (i kurver) hastigheter, hvorfra den endelige tillatte hastigheten velges, som den laveste av alle beregnet. Beregningen av disse hastighetene er regulert av Ordenen fra jernbanedepartementet i Russland nr. 41 av 12. november 2001. "Normer for tillatte hastigheter for rullende materiell jernbanespor måler 1520 (1524) mm av Federal Railway Transport ".

Som nevnt begynner å bygge IDEF0-modellen med å representere hele systemet som en enkel komponent (kontekstdiagram). Dette diagrammet viser formålet (hovedfunksjonen) til systemet og nødvendige inndata- og utdata, kontroll- og reguleringsinformasjon og mekanismer.

Kontekstdiagrammet for problemet med å bestemme tillatte hastigheter er vist i figur 6.21. For å bygge modellen brukte vi BPwin 4.0-produktet fra Computer Associates.

Figur: 6.21. Kontekstdiagram over systemet for å bestemme tillatte hastigheter (metodikk IDEF0)

Som bakgrunnsinformasjon, på grunnlag av hvilken bestemmelsen av tillatte hastigheter utføres, brukes:

Data om prosjektet til en ny linje eller et gjenoppbyggingsprosjekt (inneholder all nødvendig informasjon for gjennomføringen av prosjektet, nemlig kjørelengde, akser for separate punkter, linjeplan, etc.);

Detaljert lengdeprofil (inneholder informasjon som ligner på den som er diskutert ovenfor);

Pass på sporavstand (inneholder informasjon som ligner på den som er diskutert ovenfor, samt informasjon om sporets øvre struktur (VSP));

Data om resultatene av kartleggingen av baneplanen med spormålerbilen;

Liste over høyder på den ytre skinnen i kurver (inneholder informasjon om banens plan).

Noe av den originale informasjonen kan hentes fra forskjellige kilder... Spesielt kan informasjon om planen (kurveparametere) hentes fra prosjektet til en ny linje eller gjenoppbyggingsprosjekt, en detaljert lengdeprofil, et pass av sporavstanden, etc.

Kontrolldata er:

Instruksjoner fra sjefen for banetjenesten på veien eller avdelingen for spor og strukturer for russiske jernbaner for beregning;

Bestilling nr. 41, som inneholder normativ referanseinformasjon, prosedyre og formler for å bestemme tillatte hastigheter;

Informasjon om gjeldende eller planlagt togtrafikk (data om merkene til lokomotiver i bruk og hvilke typer biler som brukes);

Informasjon om planlagte reparasjoner av banen, rekonstruksjon og omorganisering av strukturer og innretninger.

Resultatet systemdriften bør være:

Ark med tillatte hastigheter, som inneholder alle typer beregnede hastigheter, og som lar deg fastslå årsaken til deres begrensning;

Bulletin of the Order of the head of the road on the etablering av tillatte hastigheter på sporene og separate punkter (Order "N") i samsvar med skjemaet som er vedtatt på veien. Den godkjente ordren "N" fastsetter offisielt tillatte toghastigheter;

Typiske skjema nr. 1, 1a og 2, som inneholder de planlagte tillatte hastighetene for utvikling av en togplan.

Hastighetene i ordren "H" og standard skjemaer, kan avvike fra de som er beregnet og vist i tillatte hastighetsark. Dette skyldes at de reflekterer fartsgrenser ikke bare av utformingen av rullende materiell, VSP-parametere og kurver, men også av tilstanden til enheter og strukturer (deformasjon av veibunnen, skjevhet i kontaktnettstøttene, etc.). I tillegg justeres de med tanke på planlagte banereparasjoner, rekonstruksjon og omorganisering av strukturer og innretninger, etc.

Når det er bygget, blir kontekstdiagrammet detaljert ved hjelp av et dekomponeringsdiagram på første nivå. Dette diagrammet viser funksjonene til systemet som skal implementeres i hovedfunksjonen. Diagrammet som dekomponeringen utføres for, i forhold til diagrammene som beskriver det, kalles foreldre ... Nedbrytningsdiagrammet i forhold til forelderen kalles datterselskap .

Nedbrytningsdiagrammet for første nivå for problemet som er vurdert er vist i figur 6.22. Når man konstruerer et dekomponeringsdiagram, er den opprinnelige funksjonen (som skal spaltes) delt inn i 3–8 underfunksjoner (blokker). I dette tilfellet anbefales at blokkene på nedbrytningsdiagrammet plasseres fra venstre til høyre, topp til bunn, slik at sekvensen og logikken for interaksjon av underfunksjoner blir bedre synlig.

Figur: 6.22. Nivå 1 nedbrytningsdiagram (IDEF0-metodikk)

Sekvensen for å utføre funksjoner for å løse det aktuelle problemet er som følger:

Inndata og justering av referanseinformasjon og data på veistrekninger (blokk 1 og 2);

Utarbeidelse av en beregningsoppgave (blokk 3). Den indikerer for hvilket snitt og spor, samt lokomotivets merke og typen vogner, beregningen skal utføres;

Beregning av tillatte hastigheter i henhold til prosedyren og formlene spesifisert i ordren nr. 41 (blokk 4). Den opprinnelige informasjonen er dataene langs ruten til seksjonen (plan, overbygg, etc.) og standardene valgt på grunnlag av beregningsoppgaven;

Dannelse av lister over tillatte hastigheter (blokk 5). Basert på resultatene av beregningen, opprettes flere typer utdatadokumenter, som på den ene siden gjør det mulig å identifisere årsaken til fartsgrensene, på den annen side, fungerer som grunnlag for utarbeidelse av regulerte dokumenter;

Dannelse og utarbeidelse av utkastet til ordre "N" og standarduttalelser (blokk 6 og 7).

Etter at dekomponeringsdiagrammet på første nivå er bygget, er det laget separate diagrammer (dekomponeringsdiagrammer på andre nivå) for funksjonene som er angitt på det. Deretter fortsetter nedbrytningsprosessen (bygningsdiagrammer) til ytterligere detaljering av funksjoner mister sin betydning. For hver atomfunksjon som beskriver en elementær operasjon (det vil si en funksjon som ikke har et nedbrytningsdiagram), blir det utarbeidet en detaljert spesifikasjon som definerer dens funksjoner og implementeringsalgoritme. Flytskjemaer med algoritmer kan brukes til å supplere spesifikasjonen. Dermed består prosessen med funksjonell modellering i å gradvis bygge et hierarki av funksjoner.

6.7. ICOM-koder

Pilene som går inn og ut av blokken i toppnivådiagrammet er de samme som pilene som går inn og ut av nedre nivådiagrammet, fordi blokken og diagrammet representerer den samme delen av systemet (se fig. og). Som en konsekvens er grensene for toppnivåfunksjonen de samme som grensene for nedbrytningsdiagrammet.

ICOM-koder (akronym for Input, Control, Output and Mechanism) er for å identifisere grensepiler. ICOM-koden inneholder et prefiks som tilsvarer piletypen (I, C, O eller M) og et sekvensnummer (se figur).

Visste du, hva er et tankeeksperiment, et gedankeneksperiment?
Dette er en ikke-eksisterende praksis, en annen verdslig opplevelse, fantasien om det som ikke er i virkeligheten. Tankeeksperimenter er som å våkne drømmer. De føder monstre. I motsetning til et fysisk eksperiment, som er en eksperimentell hypotesetest, erstatter et "tankeeksperiment" lurt en eksperimentell test med ønsket, uprøvd i praksis konklusjoner, og manipulerer logiske konstruksjoner som faktisk bryter med logikken ved å bruke ubeviste premisser som påviste, det vil si ved erstatning. Dermed er hovedoppgaven til søkere av "tankeeksperimenter" å lure lytteren eller leseren ved å erstatte et reelt fysisk eksperiment med hans "dukke" - fiktiv resonnement på prøveløslatelse uten fysisk bekreftelse.
Å fylle fysikk med imaginære, "tankeeksperimenter" førte til fremveksten av et absurd surrealistisk, forvirret og forvirret bilde av verden. En ekte forsker må skille slike "wrappers" fra reelle verdier.

Relativister og positivister hevder at "tankeeksperimentet" er et veldig nyttig verktøy for å teste teorier (som også oppstår i vårt sinn) for konsistens. I dette lurer de mennesker, siden enhver verifisering kun kan utføres av en kilde uavhengig av objektet for verifisering. Hypotesens søker selv kan ikke være en test av sin egen uttalelse, siden selve uttalelsen er fraværet av motsetninger i uttalelsen som er synlig for søkeren.

Vi ser dette på eksemplet med SRT og GRT, som har blitt til en slags religion som styrer vitenskap og offentlig mening... Ingen mengde fakta som motsier dem, kan overvinne Einsteins formel: "Hvis et faktum ikke samsvarer med teorien, endre faktum" (I en annen versjon "- Fakta tilsvarer ikke teorien? - Så mye verre for det faktum").

Det maksimale som "tankeeksperimentet" kan kreve er bare hypotesens interne konsistens innenfor rammen av søkerens egen, ofte på ingen måte sanne, logikk. Dette tester ikke egnetheten til praksis. Den virkelige testen kan bare finne sted i et gyldig fysisk eksperiment.

Et eksperiment er også et eksperiment, at det ikke er en forbedring av tanken, men en test av tanken. En tanke som er selvkonsistent i seg selv, kan ikke verifisere seg selv. Dette er bevist av Kurt Gödel.

IDEF0 er en grafisk modelleringsnotasjon som brukes til å lage en funksjonell modell som viser strukturen og funksjonene til et system, samt strømmer av informasjon og materielle objekter som knytter disse funksjonene. IDEF0-notasjon er en av de mest populære notasjonene for modellering av forretningsprosesser.

Hensikten med metodikken er å konstruere et funksjonsdiagram av systemet som studeres som beskriver alle nødvendige prosesser med en nøyaktighet som er tilstrekkelig for entydig modellering av systemets aktivitet.

Metodikken er basert på fire hovedbegreper: funksjonsblokk, grensesnittbue, nedbrytning, ordliste.

Funksjonell blokk (Aktivitetsboks) representerer noe spesifikt funksjon innenfor rammen av det vurderte systemet. I henhold til kravene i standarden, må navnet på hver funksjonsblokk formuleres i verbstemningen (for eksempel "å produsere tjenester"). I diagrammet er funksjonsblokken representert med et rektangel (figur 3.).

Hver av de fire sidene av en funksjonell blokk har sin egen spesifikke betydning (rolle), mens:

Den øverste siden er Kontroll;

Venstre side er satt til "Input";

Høyre side er satt til Output;

Ulempen er "Mekanisme".

Grensesnittbue (Pil) viser et systemelement som behandles av en funksjonsblokk eller som på annen måte påvirker funksjonrepresentert av denne funksjonsblokken. Grensesnittbuer kalles ofte strømmer eller piler.

Figur: 3. - Funksjonell blokk

Ved hjelp av grensesnittbuer vises forskjellige objekter, i en eller annen grad som bestemmer prosessene som foregår i systemet. Slike objekter kan være elementer i den virkelige verden (deler, biler, ansatte osv.) Eller strømmer av data og informasjon (dokumenter, data, instruksjoner, etc.).

Avhengig av hvilken side av funksjonsblokken dette grensesnittbuen passer til, kalles den "innkommende", "utgående" eller "kontrollerende".

Det skal bemerkes at enhver funksjonsblokk, i henhold til kravene i standarden, må ha minst en kontrollgrensesnittbue og en utgående. Dette er forståelig - hver prosess må følge noen regler (vises av kontrollbuen) og må gi noe resultat (utgående lysbue), ellers gir det ingen mening å vurdere det.

Den obligatoriske tilstedeværelsen av kontrollgrensesnittbuer er en av hovedforskjellene i IDEF0-standarden fra andre metoder i klassene DFD (Data Flow Diagram) og WFD (Work Flow Diagram).

Nedbrytning (Nedbrytning) er det grunnleggende konseptet til IDEF0-standarden. Nedbrytingsprinsippet brukes når man deler en kompleks prosess i komponentene. funksjoner... I dette tilfellet bestemmes detaljnivået i prosessen direkte av modellutvikleren.

Nedbrytning lar deg gradvis og strukturert representere systemmodellen i form av en hierarkisk struktur av individuelle diagrammer, noe som gjør den mindre overbelastet og lett fordøyelig (figur 4).

Det siste av IDEF0-konseptene er ordlisten. For hvert av IDEF0-elementene - diagrammer, funksjonelle blokker, grensesnittbuer - innebærer den eksisterende standarden opprettelse og vedlikehold av et sett med tilsvarende definisjoner, søkeord, fortellinger osv. som karakteriserer objektet som vises av dette elementet. Dette settet kalles en ordliste og er en beskrivelse av essensen av dette elementet. Ordlisten kompletterer harmonisk det grafiske språket, og gir diagrammene den nødvendige tilleggsinformasjonen.

IDEF0-modellen starter alltid med presentasjonen av systemet som helhet - en enkelt funksjonell blokk med grensesnittbuer som strekker seg utover det vurderte området. Et slikt diagram med en funksjonsblokk kalles kontekstdiagram.

Forklarende tekst for kontekstdiagrammet må angi mål (Formål) konstruere diagrammet som en kort beskrivelse og fast synsvinkel.

Figur: 4. - Skjema for nedbrytning av funksjonelle blokker av modellen

Å definere og formalisere målet om å utvikle en IDEF0-modell er et ekstremt viktig poeng. Faktisk identifiserer målet de relevante områdene i systemet som studeres som det bør fokuseres på først.

Synspunktet definerer hovedretningen for utviklingen av modellen og detaljnivået som kreves.

En klar fiksering av synspunktet lar deg laste ut modellen, og nekte å detaljere og studere individuelle elementer som ikke er nødvendige, basert på det valgte synspunktet på systemet. Riktig valg synspunkt reduserer tiden brukt på å bygge den endelige modellen betydelig.

Fremheving underprosesser... Under nedbrytingsprosessen bores den funksjonelle blokken, som i kontekstdiagrammet viser systemet som en helhet, i et annet diagram. Det resulterende diagrammet til det andre nivået inneholder funksjonelle blokker som viser hovedunderfunksjonene til funksjonsblokken i kontekstdiagrammet, og kalles et barn (Child Diagram) i forhold til det (hver av funksjonsblokkene som tilhører et underordnet diagram, kalles henholdsvis en child block - Child Box).

I sin tur kalles foreldrefunksjonblokken foreldreblokken i forhold til barnediagrammet (foreldreboks), og diagrammet som den tilhører kalles foreldrediagrammet (foreldrediagram). Hver av underfunksjonene til underordnet diagram kan bli nærmere detaljert ved en lignende nedbrytning av den tilsvarende funksjonsblokken. I hvert tilfelle av spaltning av en funksjonell blokk, er alle grensesnittbuer som går inn i eller forlater denne blokken, festet i underordnet diagram. Dette oppnår den strukturelle integriteten til IDEF0-modellen.

Noen ganger gir det ingen mening å fortsette å vurdere individuelle grensesnittbuer på høyere nivå på diagrammene på det lavere nivået, eller omvendt - å reflektere individuelle buer på det lavere nivået på diagrammer på høyere nivåer - dette vil bare overbelaste diagrammene og gjøre dem vanskelige å forstå. For å løse slike problemer sørger IDEF0-standarden for konseptet tunneling. Betegnelsen "Arrow Tunnel" i form av to parenteser rundt begynnelsen av grensesnittbuen betyr at denne buen ikke ble arvet fra den funksjonelle foreldreblokken og dukket opp (fra "tunnelen") bare i dette diagrammet.

I sin tur betyr den samme betegnelsen rundt enden (pilen) på grensesnittbuen i umiddelbar nærhet av mottaksblokken det faktum at denne buen ikke vil vises og ikke vil bli vurdert i barnediagrammet til denne blokken. Ofte hender det at enkeltobjekter og deres tilsvarende grensesnittbuer ikke blir vurdert på noen mellomnivåer i hierarkiet - i dette tilfellet "stuper de først inn i tunnelen" og deretter, om nødvendig, "tilbake fra tunnelen".

Typisk har IDEF0-modeller kompleks og konsentrert informasjon, og for å begrense overbelastningen og gjøre dem lesbare, vedtar standarden passende kompleksitetsbegrensninger.

Det anbefales å representere i diagrammet fra tre til seks funksjonelle blokker, mens antall grensesnittbuer som er egnet for en funksjonsblokk (etterlater en funksjonsblokk) antas å ikke være mer enn fire.

IDEF0-standarden inneholder et sett med prosedyrer som lar en stor gruppe mennesker utvikle og bli enige om en modell fra forskjellige områder av det modellerte systemet.

Vanligvis er utviklingsprosessen iterativ og består av følgende betingede stadier: Opprettelse av en modell av en gruppe spesialister relatert til ulike områder av virksomheten. Denne gruppen kalles forfattere når det gjelder IDEF0. Å bygge en innledende modell er en dynamisk prosess der forfatterne intervjuer kompetente personer om strukturen i forskjellige prosesser, og skaper modeller for avdelingens aktiviteter.

Videre er de interessert i svarene på følgende spørsmål:

Hva går til enheten "ved inngangen"?

Hvilken type funksjoner og i hvilken rekkefølge blir de utført i enheten?

Hvem er ansvarlig for hver av funksjoner?

Hva styres av utøveren når du utfører hver av dem funksjoner?

Hva er resultatet av enhetens arbeid (output)?

Basert på eksisterende bestemmelser, dokumenter og undersøkelsesresultater, opprettes et utkast (Model Draft) av modellen.

Distribusjon av utkastet til gjennomgang, godkjenning og kommentarer. På dette stadiet finner en diskusjon av utkastsmodellen sted med et bredt spekter av kompetente personer (når det gjelder IDEF0 - lesere) i virksomheten. Samtidig blir hvert av diagrammene til utkastsmodellen kritisert og kommentert skriftlig, og deretter overført til forfatteren. Forfatteren er i sin tur også enig i kritikken eller avviser den, og skisserer logikken i beslutningstaking og returnerer det reviderte utkastet for videre behandling. Denne syklusen fortsetter til forfatterne og leserne kommer til enighet.

Modellgodkjenning. Den godkjente modellen er godkjent av lederen for arbeidsgruppen i tilfelle forfatterne av modellen og leserne ikke er uenige om dens tilstrekkelighet. Den endelige modellen er et konsistent syn på virksomheten (systemet) fra et gitt synspunkt og for et gitt formål.

Synligheten av det grafiske IDEF0-språket gjør modellen ganske lesbar for de som ikke deltok i prosjektet for opprettelsen, så vel som effektiv for å holde show og presentasjoner. I fremtiden, basert på den konstruerte modellen, kan nye prosjekter organiseres med sikte på å gjøre endringer i modellen.

IDEF0-modellen anbefales for bruk i en bedrift når man beskriver forretningsprosesser på toppnivå. Når du tegner en funksjonell modell av en forretningsprosess (IDEF0), funksjonene som er utført, og input, output-strømmer av materiale, finansielle ressurser og informasjon (dokumenter, filer).

Konvensjoner av IDEF0-format er presentert i tabell 2, 3.

Tabell 2. - Grafiske symboler for IDEF0-notasjon

Tabell 3. - Grafiske symboler for IDEF0-notasjon

Gennady Vernikov

I Russland har interessen for generelt aksepterte ledelsesstandarder i Vesten for øyeblikket økt kraftig, men i reell ledelsespraksis er det et veldig veiledende øyeblikk. Mange ledere kan fortsatt være forvirret av det direkte spørsmålet om organisasjonsstruktur selskap eller om ordningen med eksisterende forretningsprosesser. De mest avanserte lederne som regelmessig leser økonomiske tidsskrifter, begynner som regel å tegne hierarkiske diagrammer som bare de kan forstå, men selv i denne prosessen kommer de vanligvis raskt til en blindvei. Det samme gjelder ansatte og ledere av ulike tjenester og funksjonelle enheter. I de fleste tilfeller er det eneste settet med regler som et foretak må operere, et sett med individuelle bestemmelser og stillingsbeskrivelser... Ofte ble disse dokumentene tegnet opp for mer enn ett år siden, de er dårlig strukturert og ikke sammenkoblet, og som et resultat samler de ganske enkelt støv i hyllene. Foreløpig var en slik tilnærming berettiget, siden begrepet konkurranse under dannelsen av den russiske markedsøkonomien var praktisk talt fraværende, og det var ikke noe særlig behov for å vurdere kostnader - overskuddet var enormt. Som et resultat har vi de siste to årene sett et helt forståelig bilde: store selskaper som vokste tidlig på 90-tallet, mister gradvis sine posisjoner, helt opp til fullstendig tilbaketrekning fra markedet. Dette skyldes delvis at virksomheten ikke implementerte ledelsesstandarder, konseptet med en funksjonell modell for aktivitet og misjon var helt fraværende. Ved hjelp av modellering av ulike aktivitetsområder er det mulig å effektivt analysere flaskehalsene i ledelsen og optimalisere den samlede forretningsplanen. Men som kjent i alle foretak, er det bare de prosjektene som direkte gir profitt som har høyeste prioritet, og derfor er det vanligvis bare under en håndgripelig krise i ledelsen av selskapet vi snakker om kartlegging av aktiviteter og omorganisering.

På slutten av 90-tallet, da markedet var tilstrekkelig konkurransedyktig og lønnsomheten til bedrifter begynte å synke kraftig, følte ledere enorme vanskeligheter med å prøve å optimalisere kostnadene slik at produktene forble både lønnsomme og konkurransedyktige. Det var akkurat nå øyeblikket at behovet for å ha en modell av virksomhetens aktivitet som skulle gjenspeile alle mekanismene og prinsippene for samtrafikk mellom ulike delsystemer innenfor rammen av en virksomhet, ble ganske tydelig.

Selve konseptet med "modellering av forretningsprosesser" kom inn i hverdagen til de fleste analytikere samtidig med fremveksten av komplekse programvareprodukterment for integrert automatisering bedriftsledelse. Slike systemer innebærer alltid en dyp forprosjektundersøkelse av selskapets aktiviteter. Resultatet av denne undersøkelsen er en ekspertuttalelse der individuelle punkter er anbefalt for å eliminere "flaskehalser" i ledelsen av aktiviteter. Basert på denne konklusjonen, rett før prosjektet med å innføre et automatiseringssystem, gjennomføres den såkalte omorganiseringen av forretningsprosesser, noen ganger ganske seriøs og smertefull for selskapet. Dette, og naturlig nok, et team som har utviklet seg gjennom årene, er alltid vanskelig å få "til å tenke på en ny måte." Slike komplekse undersøkelser av bedrifter er alltid komplekse og er vesentlig forskjellige fra sak til sak. Det er velprøvde metoder og standarder for å løse slike problemer med modellering av komplekse systemer. Disse standardene inkluderer metodene til IDEF-familien. Med deres hjelp er det mulig å effektivt vise og analysere modellene for aktiviteten til et bredt spekter av komplekse systemer i forskjellige seksjoner. Samtidig bestemmes bredden og dybden av undersøkelsen av prosessene i systemet av utvikleren selv, som gjør det mulig å ikke overbelaste den opprettede modellen med unødvendige data. For øyeblikket kan følgende standarder tilskrives IDEF-familien:

IDEF0 er en funksjonell modelleringsmetodikk. Ved hjelp av det visuelle grafiske språket IDEF0 ser systemet som studeres ut for utviklere og analytikere som et sett med sammenhengende funksjoner (funksjonelle blokker - når det gjelder IDEF0). Vanligvis er IDEF0-modellering det første trinnet i å lære om ethvert system;

IDEF1 er en metodikk for modellering av informasjonsflyter i systemet, som lar deg vise og analysere deres struktur og forhold;

IDEF1X (IDEF1 Extended) - metodikk for å bygge relasjonelle strukturer. IDEF1X er en type Entity-Relationship (ER) -metodikk og brukes vanligvis til å modellere relasjonsdatabaser som er relevante for det aktuelle systemet;

IDEF2 er en metodikk for dynamisk modellering av systemutvikling. På grunn av de svært alvorlige problemene med å analysere dynamiske systemer, ble denne standarden praktisk talt forlatt, og utviklingen ble suspendert helt i begynnelsen. Imidlertid er det for tiden algoritmer og deres datamaskinimplementeringer som gjør det mulig å transformere et sett med statiske IDEF0-diagrammer til dynamiske modeller basert på "fargede Petri-nett" (CPN - Color Petri Nets);

IDEF3 er en metode for å dokumentere prosessene som forekommer i systemet, som for eksempel brukes i studiet av teknologiske prosesser i bedrifter. IDEF3 beskriver scenariet og arbeidsflyten for hver prosess. IDEF3 har et direkte forhold til IDEF0-metoden - hver funksjon (funksjonsblokk) kan representeres som en egen prosess ved bruk av IDEF3;

IDEF4 er en metodikk for å bygge objektorienterte systemer. IDEF4-verktøy lar deg visuelt vise strukturen til objekter og de underliggende prinsippene for deres interaksjon, slik at du kan analysere og optimalisere komplekse objektorienterte systemer;

IDEF5 er en metodikk for ontologisk studie av komplekse systemer. Ved bruk av IDEF5-metoden kan ontologien til et system beskrives ved hjelp av en spesifikk ordbok for vilkår og regler, på grunnlag av hvilke pålitelige uttalelser om tilstanden til systemet som blir vurdert på et bestemt tidspunkt kan dannes. På grunnlag av disse uttalelsene blir konklusjoner om den videre utviklingen av systemet dannet og optimaliseringen utført.
I denne artikkelen vil vi se på den mest brukte funksjonelle modelleringsmetoden IDEF0.

Historien til IDEF0-standarden

IDEF0-metoden kan betraktes som neste trinn i utviklingen av det velkjente grafiske språket for beskrivelse av funksjonelle systemer SADT (Structured Analysis and Design Teqnique). For flere år siden ble en liten utgave av boken med samme navn utgitt i Russland, som var viet til å beskrive de grunnleggende prinsippene for å konstruere SADT-diagrammer. Historisk ble IDEF0 som standard utviklet i 1981 som en del av et omfattende automatiseringsprogram industribedrifter, som bar betegnelsen ICAM (Integrated Computer Aided Manufacturing) og ble foreslått av US Air Force. IDEF-familien av standarder arvet selv betegnelsen fra navnet på dette programmet (IDEF \u003d ICAM DEFinition). I prosessen med praktisk implementering møtte deltakerne i ICAM-programmet behovet for å utvikle nye metoder for å analysere samhandlingsprosesser i industrielle systemer. Samtidig, i tillegg til et forbedret sett med funksjoner for å beskrive forretningsprosesser, var et av kravene til den nye standarden tilgjengeligheten av en effektiv metodikk for samhandling innenfor rammen av "analytiker-spesialisten". Med andre ord, ny metode skulle gi gruppearbeid med å lage modellen, med direkte deltakelse fra alle analytikere og spesialister som var involvert i prosjektet.

Som et resultat av søket etter passende løsninger ble IDEF0 funksjonell modelleringsmetodikk født. Siden 1981 har IDEF0-standarden gjennomgått flere mindre endringer, for det meste av en begrensende karakter, og den siste revisjonen ble utgitt i desember 1993 av US National Institute for Standards and Technology (NIST).

Grunnleggende elementer og konsepter i IDEF0

Det grafiske språket IDEF0 er overraskende enkelt og harmonisk. Metodikken er basert på fire hovedbegreper.

Den første av disse er konseptet med Activity Box. En funksjonsblokk er grafisk avbildet i form av et rektangel (se fig. 1) og personifiserer en eller annen spesifikk funksjon innenfor rammen av det aktuelle systemet. I henhold til kravene i standarden, må navnet på hver funksjonsblokk formuleres i verbstemningen (for eksempel "produser tjenester", ikke "produksjon av tjenester").

Hver av de fire sidene av en funksjonell blokk har sin egen spesifikke betydning (rolle), mens:

Hver funksjonsblokk i et enkelt vurdert system må ha sitt eget unike identifikasjonsnummer.

Figur 1. Funksjonell blokk.

Den andre "hvalen" i IDEF0-metoden er konseptet med en grensesnittbue (pil). Grensesnittbuer kalles ofte strømmer eller piler. Grensesnittbuen viser et systemelement som behandles av en funksjonsblokk eller på annen måte påvirker funksjonen som vises av denne funksjonsblokken.

Den grafiske visningen av grensesnittbuen er en ensrettet pil. Hver grensesnittbue må ha sitt eget unike navn (Arrow Label). Som kreves av standarden, må navnet være en substantivomsetning.

Ved hjelp av grensesnittbuer vises forskjellige objekter, i en eller annen grad som bestemmer prosessene som foregår i systemet. Slike objekter kan være elementer i den virkelige verden (deler, biler, ansatte osv.) Eller strømmer av data og informasjon (dokumenter, data, instruksjoner, etc.).

Avhengig av hvilken av sidene dette grensesnittbuen passer til, kalles det "inngående", "utgående" eller "kontroll". I tillegg er det bare funksjonelle blokker som kan være "kilde" (start) og "synke" (slutt) til hver funksjonelle bue, mens "kilde" bare kan være utgangssiden av blokken, og "vasken" kan være en av de tre gjenværende.

Det skal bemerkes at enhver funksjonsblokk, i henhold til kravene i standarden, må ha minst en kontrollgrensesnittbue og en utgående. Dette er forståelig - hver prosess må følge noen regler (vises av kontrollbuen) og må gi noe resultat (utgående lysbue), ellers gir det ingen mening å vurdere det.

Når du bygger IDEF0 - diagrammer, er det viktig å skille innkommende grensesnittbuer korrekt fra kontrollene, noe som ofte ikke er lett. For eksempel viser figur 2 funksjonsblokken "Process workpiece".

I en reell prosess får arbeideren som utfører behandlingen et arbeidsemne og teknologiske instruksjoner for behandling (eller sikkerhetsregler når han arbeider med maskinen). Det kan feilaktig virke som at både arbeidsstykket og dokumentet med teknologiske instruksjoner er innkommende gjenstander, men dette er ikke slik. I denne prosessen blir arbeidsstykket faktisk behandlet i henhold til reglene som gjenspeiles i de teknologiske instruksjonene, som skal vises henholdsvis av kontrollgrensesnittbuen.

Figur 2.

En annen ting er når teknologiske instruksjoner behandles av sjefsteknologen og det gjøres endringer i dem (fig. 3). I dette tilfellet vises de som en allerede innkommende grensesnittbue, og kontrollobjektet er for eksempel nye industrielle standarder, som disse endringene gjøres på.

Figur 3.

Ovennevnte eksempler understreker den tilsynelatende like naturen til innkommende og utgående grensesnittbuer, men det er alltid visse skiller for systemer av samme klasse. For eksempel når det gjelder å vurdere bedrifter og organisasjoner, er det fem hovedtyper av objekter: materialstrømmer (deler, varer, råvarer osv.), Finansielle strømmer (kontanter og ikke-kontanter, investeringer osv.), Dokumentflyter (kommersielle, økonomiske og organisasjonsdokumenter), informasjonsflyter (informasjon, intensjonsdata, muntlige instruksjoner osv.) og ressurser (ansatte, maskiner, maskiner osv.). I dette tilfellet, i forskjellige tilfeller, kan alle typer objekter vises med innkommende og utgående grensesnittbuer, som bare kontrollerer de som er relatert til strømmer av dokumenter og informasjon, og bare ressurser kan vises med buemekanismer.

Den obligatoriske tilstedeværelsen av kontrollgrensesnittbuer er en av hovedforskjellene i IDEF0-standarden fra andre metoder i klassene DFD (Data Flow Diagram) og WFD (Work Flow Diagram).

Det tredje grunnleggende konseptet til IDEF0-standarden er Nedbrytning. Nedbrytningsprinsippet brukes når man bryter ned en kompleks prosess i dens funksjoner. I dette tilfellet bestemmes detaljnivået i prosessen direkte av modellutvikleren.

Nedbrytning lar deg gradvis og strukturert representere systemmodellen i form av en hierarkisk struktur av individuelle diagrammer, noe som gjør den mindre overbelastet og lett å fordøye.

IDEF0-modellen starter alltid med presentasjonen av systemet som helhet - en enkelt funksjonell blokk med grensesnittbuer som strekker seg utover det vurderte området. Et slikt diagram med en funksjonsblokk kalles et kontekstdiagram, og betegnes med identifikatoren "A-0".

I forklaringsteksten til kontekstdiagrammet må Formålet med å bygge diagrammet i form av en kort beskrivelse angis og synspunktet (Synspunkt) må være fast.

Å definere og formalisere formålet med å utvikle en IDEF0-modell er ekstremt viktig. Faktisk identifiserer målet de relevante områdene i systemet som studeres som det bør fokuseres på først. Hvis vi for eksempel modellerer virksomheten til en bedrift for å bygge et informasjonssystem på grunnlag av denne modellen i fremtiden, vil denne modellen skille seg betydelig fra den vi ville utvikle for den samme virksomheten, men med sikte på å optimalisere forsyningskjeder.

Synspunktet definerer hovedretningen for utviklingen av modellen og detaljnivået som kreves. En klar fiksering av synspunktet lar deg laste ut modellen, og nekte å detaljere og studere individuelle elementer som ikke er nødvendige, basert på det valgte synspunktet på systemet. For eksempel funksjonelle modeller av den samme virksomheten fra sjefsteknologens og cFO vil variere betydelig i retning av detaljering. Dette skyldes at finansdirektøren til slutt ikke er interessert i aspektene ved bearbeiding av råvarer på produksjonsmaskiner, og sjefsteknologen trenger ikke trukket ordninger for økonomiske strømmer. Riktig valg av synspunkt reduserer tiden brukt på å bygge den endelige modellen.

Under nedbrytingsprosessen bores den funksjonelle blokken, som i kontekstdiagrammet viser systemet som en helhet, i et annet diagram. Det resulterende diagrammet til det andre nivået inneholder funksjonelle blokker som viser hovedunderfunksjonene til funksjonsblokken i kontekstdiagrammet og kalles et barnediagram (Child diagram) i forhold til det (hver av funksjonsblokkene som tilhører underdiagrammet kalles henholdsvis en child block - Child Box). I sin tur kalles foreldrefunksjonsblokken foreldreblokken i forhold til underordnet diagram (foreldreboks), og diagrammet som den tilhører, kalles overordnet diagram (foreldrediagram). Hver av underfunksjonene til underordnet diagram kan bli nærmere detaljert ved en lignende nedbrytning av den tilsvarende funksjonsblokken. Det er viktig å merke seg at i hvert tilfelle av spaltning av en funksjonell blokk, er alle grensesnittbuer som er inkludert i denne blokken eller utgående fra den, fiksert i underordnet diagram. Dette oppnår den strukturelle integriteten til IDEF0-modellen. Prinsippet for nedbrytning er tydelig vist i figur 4. Du bør være oppmerksom på forholdet mellom nummereringen av funksjonsblokker og diagrammer - hver blokk har sitt eget unike serienummer på diagrammet (tallet i nederste høyre hjørne av rektangelet), og betegnelsen i rett vinkel indikerer nummeret på barnediagrammet for denne blokken ... Fraværet av denne betegnelsen betyr at det ikke er noen spaltning for denne blokken.

Det er ofte tilfeller når det ikke gir mening å fortsette å vurdere individuelle grensesnittbuer i underordnede diagrammer under et visst nivå i hierarkiet, eller omvendt - individuelle buer gir ikke praktisk mening over et visst nivå. For eksempel en grensesnittbue som viser en "detalj" ved inngangen til "Prosessen på dreiebenk"det gir ingen mening å reflektere over diagrammer på høyere nivåer - dette vil bare overbelaste diagrammene og gjøre dem vanskelige å forstå. På den annen side blir det nødvendig å kvitte seg med separate" konseptuelle "grensesnittbuer og ikke detaljere dem dypere enn et visst nivå. IDEF0-standarden sørger for konseptet tunneling. Betegnelsen på "tunnelen" (Arrow Tunnel) i form av to parenteser rundt begynnelsen av grensesnittbuen betyr at denne buen ikke ble arvet fra den funksjonelle foreldreblokken og dukket opp (fra "tunnelen") bare i dette diagrammet. sving, betyr den samme betegnelsen rundt enden (pilene) på grensesnittbuen i umiddelbar nærhet av mottakerblokken det faktum at i barnediagrammet til denne blokken vil denne buen ikke vises og vurderes. Ofte vil enkeltobjekter og deres tilsvarende grensesnittbuer blir ikke vurdert på noen mellomnivåer i hierarkiet - inkludert I dette tilfellet "stuper de først inn i tunnelen" og deretter, om nødvendig, "tilbake fra tunnelen".

Det siste av IDEF0-konseptene er ordlisten. For hvert av IDEF0-elementene: diagrammer, funksjonsblokker, grensesnittbuer, innebærer den eksisterende standarden oppretting og vedlikehold av et sett med passende definisjoner, nøkkelord, fortellinger osv., Som karakteriserer objektet som vises av dette elementet. Dette settet kalles en ordliste og er en beskrivelse av essensen av dette elementet. For eksempel, for grensesnittbuen "betalingsordre", kan ordlisten inneholde en liste over felt i dokumentet som tilsvarer lysbuen, det nødvendige settet med visum, etc. Ordlisten kompletterer harmonisk det grafiske språket, og gir diagrammene den nødvendige tilleggsinformasjonen.

Figur 4. Nedbrytning av funksjonsblokker.

Prinsippene for å begrense kompleksiteten til IDEF0-diagrammer

Vanligvis har IDEF0-modeller kompleks og konsentrert informasjon, og for å begrense overbelastningen og gjøre dem lesbare, blir de tilsvarende kompleksitetsgrensene vedtatt i den tilsvarende standarden:

Begrensning av antall funksjonsblokker i diagrammet til tre til seks. Den øvre grensen (seks) tvinger designeren til å bruke hierarkier når han beskriver komplekse elementer, og den nedre grensen (tre) sørger for at det er nok detaljer på det tilsvarende diagrammet til å rettferdiggjøre opprettelsen;

Begrensning av antall grensesnittbuer som passer for en funksjonsblokk (etterlater en funksjonsblokk) til fire.
Selvfølgelig er det slett ikke nødvendig å følge disse begrensningene strengt, men som erfaring viser, er de veldig praktiske i ekte arbeid.

Disiplin av gruppearbeid om utvikling av IDEF0-modellen

IDEF0-standarden inneholder et sett med prosedyrer som lar en stor gruppe mennesker utvikle og bli enige om en modell fra forskjellige områder av det modellerte systemet. Vanligvis er utviklingsprosessen iterativ og består av følgende betingede stadier:

Oppretting av en modell av en gruppe spesialister knyttet til ulike områder av virksomheten. Denne gruppen kalles forfattere når det gjelder IDEF0. Å bygge en innledende modell er en dynamisk prosess der forfattere intervjuer kompetente personer om strukturen til forskjellige prosesser. Basert på eksisterende bestemmelser, dokumenter og undersøkelsesresultater, opprettes et utkast (Model Draft) av modellen.

Distribusjon av utkastet til gjennomgang, godkjenning og kommentarer. På dette stadiet blir utkastsmodellen diskutert med et bredt spekter av kompetente personer (når det gjelder IDEF0-lesere) i bedriften. Samtidig blir hvert av diagrammene til utkastsmodellen kritisert og kommentert skriftlig, og deretter overført til forfatteren. Forfatteren er i sin tur også enig i kritikken eller avviser den, og skisserer logikken i beslutningstaking og returnerer det reviderte utkastet for videre behandling. Denne syklusen fortsetter til forfatterne og leserne kommer til enighet.

Modellgodkjenning. Den godkjente modellen er godkjent av lederen for arbeidsgruppen i tilfelle forfatterne av modellen og leserne ikke er uenige om dens tilstrekkelighet. Den endelige modellen er et konsistent syn på virksomheten (systemet) fra et gitt synspunkt og for et gitt formål.
Synligheten av det grafiske IDEF0-språket gjør modellen ganske lesbar for de som ikke deltok i prosjektet for opprettelsen, så vel som effektiv for å holde show og presentasjoner. I fremtiden, på grunnlag av den konstruerte modellen, kan nye prosjekter organiseres med sikte på å gjøre endringer i virksomheten (i systemet).

Funksjoner av den nasjonale praksisen med å bruke funksjonell modellering ved hjelp av IDEF0

De siste årene har interessen for IDEF-familien av metodologier i Russland stadig økt. Jeg observerer dette kontinuerlig og ser på statistikken over samtaler til min personlige webside (http://www.vernikov.ru), som kort beskriver de grunnleggende prinsippene i disse standardene. Samtidig vil jeg kalle interesse for slike standarder som IDEF3-5 teoretisk, og for IDEF0 ganske praktisk berettiget. Faktisk, de første Case-verktøyene som gjorde det mulig å bygge DFD- og IDEF0-diagrammer, dukket opp på det russiske markedet tilbake i 1996, samtidig med utgivelsen av den populære boken om prinsippene for modellering i SADT-standardene.

Likevel anser de fleste ledere fortsatt den praktiske anvendelsen av modellering i IDEF-standarder mer som en hyllest til mote enn en effektiv måte å optimalisere. det eksisterende systemet virksomhetsledelse. Dette skyldes mest sannsynlig en uttalt mangel på informasjon om praktisk anvendelse disse metodikkene og med den uunnværlige programvareforstyrrelsen til det absolutte flertallet av publikasjoner.

Det er ingen hemmelighet at nesten alle prosjekter for kartlegging og analyse av økonomiske og Økonomisk aktivitet bedrifter nå i Russland er på en eller annen måte knyttet til konstruksjonen av automatiserte kontrollsystemer. Takket være dette har IDEF-standardene i forståelsen av flertallet blitt betinget uatskillelige fra implementeringen av informasjonsteknologi, selv om de noen ganger til og med er små med deres hjelp lokale oppgaver, bokstavelig talt med blyant og papir.

Når du gjennomfører komplekse bedriftsundersøkelsesprosjekter, lar utviklingen av modeller i IDEF0-standarden deg visuelt og effektivt vise hele mekanismen for virksomhetsaktivitet i ønsket sammenheng. Det viktigste er imidlertid muligheten teamarbeidlevert av IDEF0. I min praksis var det ganske mange tilfeller da konstruksjonen av modellen ble utført med direkte hjelp fra ansatte fra forskjellige avdelinger. Samtidig, konsulenten for nok en kort tid forklarte dem de grunnleggende prinsippene til IDEF0 og lærte dem hvordan de kan arbeide med den tilsvarende applikasjonsprogramvaren. Som et resultat opprettet ansatte ved forskjellige avdelinger IDEF-diagrammer over aktivitetene til deres funksjonelle enhet, som skulle svare på følgende spørsmål:

Hva går til enheten "ved inngangen"?

Hvilke funksjoner, og i hvilken rekkefølge, utføres i enheten?

Hvem er ansvarlig for hver funksjon?

Hva styres eksekutøren når han utfører hver av funksjonene?

Hva er resultatet av enhetens arbeid (output)?

Etter å ha blitt enige om utkast til diagrammer innen hver spesifikke avdeling, samles de av konsulenten i et utkast til bedriftsmodell, der alle inngangs- og utgangselementene er koblet. På dette stadiet registreres alle avvik mellom individuelle diagrammer og deres kontroversielle steder. Videre går denne modellen igjen gjennom de funksjonelle avdelingene for videre koordinering og foreta de nødvendige justeringene. Som et resultat, på ganske kort tid og med tiltrekningen av minimum menneskelige ressurser fra et konsulentselskaps side (og disse ressursene, som du vet, er veldig dyre), oppnås en IDEF0-modell av en virksomhet i henhold til "As is" -prinsippet, og viktigere, den representerer bedriften fra stillingen til ansatte som jobber i den og kjenner grundig til alle nyanser, inkludert uformell. I fremtiden vil denne modellen bli overført for analyse og prosessering til forretningsanalytikere som vil se etter flaskehalser i selskapets ledelse og optimalisere hovedprosessene, og transformere "As is" -modellen til den tilsvarende "Som skal være" -visningen. Basert på disse endringene trekkes en endelig konklusjon som inneholder anbefalinger for omorganisering av styringssystemet.

Selvfølgelig krever en slik tilnærming en rekke organisatoriske tiltak, først og fremst fra ledelsen av den undersøkte virksomheten. Dette skyldes det faktum at denne teknikken innebærer tildeling av ytterligere ansvar til noen ansatte i utviklingen og praktisk anvendelse av nye metoder. Til slutt lønner det seg imidlertid, siden den ekstra en eller to timers arbeid for enkeltmedarbeidere over flere dager kan spare penger på å betale for konsulenttjenester til et tredjepartsfirma (som i alle fall vil rive av de samme ansattes arbeid med spørreskjema og spørsmål). Når det gjelder de ansatte i bedriften selv, har jeg på en eller annen måte ikke møtt noen uttrykt motstand fra deres side.

Konklusjonen fra alt dette kan gjøres som følger: det er slett ikke nødvendig å komme med løsninger for standardproblemer hver gang. Når du står overfor behovet for å analysere et bestemt funksjonelt system (fra et romfartøy-designsystem til prosessen med å forberede en kompleks middag) - bruk metoder som har blitt bevist og testet gjennom årene. En av disse metodene er IDEF0, som lar deg løse komplekse livsproblemer ved hjelp av enkle og forståelige verktøy.

Workshop for bruk av IDEF0 for funksjonell beskrivelse av programvare
Del 1.

Hvis du analyserer annonsene for ansettelse av ansatte i firmaer som driver programvareutvikling, har det nylig vært en akutt mangel på prosjektledere som kompetent kan utføre oppgavene. Problemet er ikke at de ikke kan formulere en oppgave, men at de ikke kan utarbeide dokumentasjon riktig med hensyn til moderne designstandarder. For kunden allerede det er ikke nok å gi noen få blad skrevet inn i Word. Han vil ha dokumentasjon formatert i BPWin, ErWin, S-Designer, Power Designer, Rational Rose, etc. Det er en standard bak hvert av disse CASE-verktøyene. Denne artikkelen er dedikert til en av dem - IDEF0.

Introduksjon. Når man utarbeider dokumentasjon, anser hver prosjektleder det som en ære å komme med noe "sitt eget" - sitt eget "superformat" for å presentere ideene sine. Kompleksiteten til prosjekter vokser, volumet av dokumentasjon for et prosjekt vokser, dokumentasjonen går utover arbeidsgruppen ... og da blir det klart at dokumentasjonen ikke passer kunden eller gruppen av utviklere som fullfører prosjektet og støtter det.

Vanligvis er prosjektlederen enten en kul programmerer (hovedprogrammerer for emnet - prosjekt), eller en god fremmed språk person som er kjent med programmering. Dette er hovedutvelgelseskriteriene for prosjektlederstillingen. Dette er roten til problemet. Du kan være en kul programmerer eller bare en god ansatt, men dette har ingenting med dokumentasjon å gjøre.

Spesifikasjonen for hver type manager glir vanligvis ned til en beskrivelse av selve programmets modell (arkitektur av moduler, klasser, DLLer, databasestruktur og dens bruk osv.) Eller til en beskrivelse av brukerdefinerte funksjoner (hva de skal gjøre, hvilke former som skal være program osv.).

Ideell når klienten setter oppgaven. I dette tilfellet kan du leve etter prinsippet "kunden ønsker", og så lenge han er fornøyd, får du penger fra kunden. Men flere og flere prosjekter blir opprettet i dypet av en organisasjon, og så blir de tilbudt kunden. Og i dette tilfellet kommer kvaliteten på dokumentasjonen frem, hva du har gjort og hva du har tenkt å gjøre. Dokumentasjonen avgjør alt i dette tilfellet ...

IDEF0 (Integrated Definition Function Modelling) standard er ment for funksjonell modellering og er vedtatt som en føderal standard i USA. IDEF0-standarden er en av en gruppe standarder som er mye brukt for å beskrive enhver forretningsprosess. Bruken av den for å beskrive programvareprosjekter er en veldig ung retning, men bruk av IDEF0 garanterer at partnerne dine vil ta deg på alvor ...

Anvendelsen av IDEF-gruppestandarder (IDEF0, IDEF1, etc.) er den faktiske forutsetningen for å oppnå status for en organisasjon som oppfyller ISO9000, ISO9001. Disse standardene for en organisasjon er en mulighet til å øke salg av produkter, en mulighet til å bevise at den er "på toppen av en bølge."

Mange programmerere bruker CASE ErWin mye uten å vite at det er basert på IDEF1-standarden. Det er ikke bare det du liker eller kundene dine liker. Dette er standarden - og det sier alt.

Korte grunnleggende konsepter i IDEF0-standarden. IDEF0-standarden er basert på begrepet funksjon. En funksjon er en kontrollert handling på en inngang som resulterer i en utgang, ved hjelp av en mekanisme som denne handlingen utføres for.

IDEF0-standarden er basert på tre grunnleggende prinsipper:

1. prinsippet om funksjonell nedbrytning - hvilken som helst funksjon kan spaltes (detaljert, brutt ned) til enklere funksjoner;

2. prinsippet om å begrense kompleksiteten - antall blokker i diagrammet skal være 2 ... 6 (lesbarhetsbetingelse);

3. prinsippet om kontekst - modellering av forretningsprosessen begynner med å bygge et kontekstdiagram, som bare viser en blokk - hovedfunksjonen til modelleringssystemet, som begrenser området for modelleringssystemets grense (regulerer den innledende fasen av å bygge modellen).

IDEF0-diagrammer er bygd ved hjelp av blokker. Hver blokk beskriver en fullstendig handling (funksjon).

De fire sidene av blokken har forskjellige formål. Inndata vises til venstre, utdata til høyre, kontroll på toppen og mekanisme nederst.

Inndata - innledende ressurser for funksjonen som er beskrevet av blokken (innledende informasjon, materialer).

Output data - de resulterende ressursene oppnådd som et resultat av utførelsen av funksjonen beskrevet av blokken ( avtrykk, bearbeidede råvarer).

Kontroll er det som påvirker prosessen med å utføre funksjonen som er beskrevet av blokken, og lar deg påvirke resultatet av handlingen (kontroller, sensorer, personer).

En mekanisme er hva en gitt handling utføres (maskiner, enheter, menneskelige ressurser, programvare).

Samspillet mellom blokkene vises som buer (piler). Noen ganger kalles sidene av en blokk retninger og pilene kalles strømmer. Pilene kan signeres. Signaturer er knyttet til den tilsvarende pilen ved hjelp av en sikksakk (lyn).

En generell oversikt over implementeringen av IDEF0-diagramblokken er vist i figur 1.

Figur 1. Implementering av blokken som brukes i IDEF0-diagrammer.

Under nedbrytning (nedboring) av en funksjon vises alle innkommende og utgående piler (buer, strømmer) assosiert med funksjonen som deles, i det nylig dannede diagrammet. Antall piler på ethvert nivå i diagrammet og i hvilken som helst retning er ikke begrenset. Diagrammet kalles blokken (funksjonen) som blir delt. Bare navnet på kontekstdiagrammet (DK) faller sammen med navnet på funksjonen i diagrammet.

I det vesentlige danner diagrammer et tre. Ethvert diagram fungerer som en DC i forhold til de underliggende.

Som et eksempel kan du vurdere en eller annen abstrakt funksjon. Denne funksjonen har inngangsdata, to forskjellige typer utdata, styres av en ekstern påvirkning og implementeres av mekanismene A og B. Et eksempel på hovedkontekstdiagrammet er vist i figur 2, og en detaljert (dekomponert) versjon av denne funksjonen, bestående av to funksjoner (mer elementære handlinger ) er vist i fig. 3. I sin tur kan funksjoner 1 og 2 også bli detaljert (dekomponert).

Fig. 2. Et eksempel på et grunnleggende diagram.

Fig. 3. Et eksempel på nedbrytning av hovedfunksjonen.

Diagrammet er lokalisert på et spesielt skjema som inneholder navnet på funksjonen, dens grafiske fremstilling, betegnelsen på diagrammet med hekkingsnivå, lenker til andre funksjoner, spesiell informasjon om forfatteren, organisasjonen og det beskrevne prosjektet.

Tilkoblinger. Piler eller buer viser forholdet mellom blokker. Pilene signerer vanligvis. Pilesignaturer er valgt som substantiv. For enkelhets skyld er piler koblet til signaturer med lyn. For lesbarhet av IDEF0-diagrammet anbefales det å plassere etiketter enten over pilen eller til høyre for pilen.

Ledningsruting begynner vanligvis med data. Inngangsdata er dataene som kreves for å utføre en funksjon. Med denne retningen dukker det sjelden opp spørsmål. Output er data som er resultatet av å utføre en funksjon. Den enkleste situasjonen er når utgangen mates til en annen blokk. Er dette alltid tilfelle? Hvis en funksjon, som behandler inngangsinformasjon, danner en kontrollkommando, er dette kontroll. Situasjonen er omtrent den samme når funksjonen danner dataformatet. Dataformat er en mekanisme for overføring av informasjon.

Hovedtyper av koblinger mellom blokker i diagrammet, dannet på grunnlag av utdataene, er vist i figur 1.

Fig. 4. Typer koblinger mellom blokker i diagrammet. Følgelig, a) kommunikasjon via data, b) kommunikasjon via kontroll, c) kommunikasjon via mekanisme, d) tilbakemelding.

Tilbakemelding er en lenke som danner en ring mellom datablokker, kontroll eller format. Et eksempel på en slik forbindelse er vist i figur 2.d. Når dette forholdet vises, sjekk om diagrammet ditt koker ned til et flytskjema. Tilstedeværelsen av en slik forbindelse er ikke et tegn på feil.

Blokker prioritet og nummerering. Alle blokker har prioritet. Prioriteten til blokkene avhenger av sekvensen for utførelsen. Blokkene til venstre og øverst har høyest prioritet. Den dominerende stillingen er horisontal.

Blokknummerering (blokkindeks i diagrammet) i diagrammet bestemmes ut fra prioritet. Nummerering starter fra en. Kartkoden består av bokstaven "A" og et tall. DC har kode A-0. Bokstaven "A" betyr aktiv handling (fra engelsk. Aktiv). Diagrammet, som er en dekomponert versjon av DC, vil ha koden A0. Hvert element i diagram A0 vil bli kodet fra A1 til A6 i henhold til prioritet. Når en av blokkene A1 ... A6 blir spaltet, vil blokkodene til det nylig dekomponerte diagrammet bestå av koden til det dekomponerte diagrammet pluss indeksen til den valgte blokken. Kartblokkkoder gjentas ikke gjennom hele kartet.

Ved antall sifre i diagramkoden kan du bestemme diagramnivået - dekomponeringsnivået til DC. Det er vanlig å betrakte DC som hovednivå, og alle de andre er fra det første dekomponeringsnivået og oppover.

Typer av sekvens av handlinger. Data kan behandles sekvensielt eller parallelt.

Et eksempel på sekvensiell behandling er å fylle adresseboken (du kan tross alt ikke skrive to adresser inn i den samtidig). Hver blokk behandler alltid bare en kopi av dataene, og endres sekvensielt etter hver behandling. Blokker plasseres enten i rekkefølge horisontalt eller skrått fra øvre venstre hjørne til nedre høyre.

Et eksempel på parallell behandling - du kan se på TV og spise et eple samtidig. I dette tilfellet utføres to handlinger samtidig. Disse handlingene er ikke relatert til hverandre. Disse blokkene er stablet vertikalt oppå hverandre i diagrammet.

Ofte er det en gruppe handlinger (blokker) på diagrammet, hvorav bare en utføres, avhengig av noen tilstand. Slike handlinger kalles alternative handlinger. Betingelsen må brukes på slike blokker som en kontrollhandling (valg av handling). Det anbefales å innføre en spesiell blokk i diagrammet som behandler betingelsen for å velge en alternativ handling (blokk). Denne blokken genererer separate valgbare kommandoer for hver blokk.

Menneskenes rolle i IDEF0-diagrammer. Er han en kontroll eller en mekanisme? Du bestemmer hvilke funksjoner personen utfører i den beskrevne oppgaven. Hvis handlingen i blokken kontrolleres av en person, så kontroller. Hvis en handling utføres av en person, så en mekanisme. Alt avhenger av graden av abstraksjon av oppgavepresentasjonen din.

Det er tilfeller når en person (inkludert samme person) vil fungere som en mekanisme og kontroll for en blokk. DET SKJER. Eksempel, en person skriver et brev. Det er skrevet av denne personen, og den samme personen kontrollerer innholdet i dette brevet.

Kontrolldata. Ledelse er et team. Hvis en kommando inneholder en informativ del (navn, betingelser, tidsfrister osv.), Er den informative delen av kommandoen inndata.

Den enkleste løsningen er å dele den opprinnelige pilen i to: kontroll og data. Disse pilene fører til de tilsvarende sidene av blokken. Begge atskilte pilene skal merkes tilsvarende.

Sergey Sokolov (Minsk, BSUIR)
E-post: