6.2. Syfte och sammansättning av SADT-metoden (IDEF0)

6.2. Syfte och sammansättning av SADT-metoden (IDEF0)

SADT metodik (Structured Analysis and Design Technique - metodiken för strukturanalys och design) är en uppsättning metoder, regler och procedurer utformade för att bygga en funktionell modell av systemet.

Utvecklingen av denna metodik initierades av Douglas Ross (USA) i mitten av 1960-talet. 1900-talet Sedan dess har systemanalytiker på SofTech, Inc. förbättrade SADT och använde den för att lösa ett brett spektrum av problem. Programvara för telefonnätverk, diagnostik, långsiktig och strategisk planering, datorstödd tillverkning och design, datorsystemkonfiguration, personalutbildning, ekonomi och logistikhantering är några av de områden där SADT tillämpas effektivt. Det breda utbudet av områden indikerar mångsidigheten och kraften hos SADT-metoden. Det amerikanska försvarsdepartementets ICAM-program (Integrated Computer Aided Manufacturing) insåg användbarheten av SADT. Detta ledde till publiceringen av en del av den 1981 kallad IDEF0 (Icam DEFinition), som den federala standarden för mjukvaruutveckling. Under detta namn har SADT använts av tusentals yrkesverksamma inom militära och industriella organisationer. Den senaste revideringen av IDEF0-standarden gavs ut i december 1993. US National Institute of Standards and Technology (NIST).

Denna metodik, när den beskriver den funktionella aspekten av ett informationssystem, konkurrerar med dataflödesorienterade (DFD) metoder. Däremot tillåter IDEF0:

Beskriv alla system, inte bara informativa (DFD är avsedd att beskriva programvara);

Skapa en beskrivning av systemet och dess yttre miljö innan du definierar de slutliga kraven för det. Med andra ord, med hjälp av denna metodik är det möjligt att successivt bygga och analysera systemet även när det fortfarande är svårt att föreställa sig dess implementering.

Således kan IDEF0 användas i de tidiga stadierna av att bygga ett brett utbud av system. Samtidigt kan den användas för att analysera funktionerna i befintliga system och utveckla lösningar för att förbättra dem.

IDEF0-metoden bygger på ett grafiskt processbeskrivningsspråk. En modell i IDEF0-notation är en samling hierarkiskt ordnade och sammanlänkade diagram. Varje diagram är en enhet för systembeskrivning och finns på ett separat blad.

Modell (IS-IS, TO-BE eller SHOULD-BE) kan innehålla 4 diagramtyper [ , ]:

kontextdiagram;

Nedbrytningsdiagram;

Diagram för nodträd;

Diagram endast för exposition (FEO).

Kontextdiagram (toppnivådiagram), som är toppen av diagrammets trädstruktur, visar syftet med systemet (huvudfunktion) och dess interaktion med den yttre miljön. Det kan bara finnas ett kontextdiagram per modell. Efter beskrivningen av huvudfunktionen utförs funktionell nedbrytning, det vill säga funktionerna som utgör huvudfunktionen bestäms.

Vidare är funktionerna uppdelade i underfunktioner och så vidare tills den erforderliga detaljnivån för systemet som studeras uppnås. Diagram som beskriver varje sådant fragment av systemet kallas sönderdelningsdiagram . Efter varje nedbrytningssession hålls undersökningssessioner - ämnesexperter indikerar överensstämmelsen mellan verkliga processer och de skapade diagrammen. De hittade inkonsekvenserna elimineras, varefter de går vidare till ytterligare detaljering av processerna.

Nodträddiagram visar det hierarkiska beroendet av funktioner (verk), men inte förhållandet mellan dem. Det kan finnas flera av dem, eftersom trädet kan byggas till ett godtyckligt djup och från en godtycklig nod.

Diagram för exponering är byggda för att illustrera enskilda fragment av modellen för att visa en alternativ syn på de processer som sker i systemet (till exempel från organisationens lednings synvinkel).

6.3. Element i IDEF0 grafisk notation

IDEF0-metoden har fått bred acceptans och tillämpning, främst på grund av den enkla grafiska notationen som används för att bygga modellen. Diagram är huvudkomponenterna i modellen. De visar systemets funktioner i form av rektanglar, såväl som länkarna mellan dem och den yttre miljön genom pilar. Användningen av bara två grafiska primitiver (rektangel och pil) gör att du snabbt kan förklara reglerna och principerna för att bygga IDEF0-diagram för personer som inte är bekanta med denna metod. Denna fördel gör att du kan koppla ihop och aktivera kundens aktiviteter för att beskriva affärsprocesser med hjälp av ett formellt och visuellt grafiskt språk.

Följande illustration visar grundelementen i IDEF0 grafiska notation.

Ris. 6.1. Element i IDEF0 grafisk notation

Rektangeln representerar arbete (process, aktivitet, funktion eller uppgift) , som har ett fast mål och leder till något slutresultat. Verkets namn måste uttrycka åtgärden (till exempel "Tillverkning av delen", "Beräkning av tillåtna hastigheter", "Formation av CDL-sats nr 3").

Verkens samspel mellan dem själva och omvärlden beskrivs i form av pilar. IDEF0 skiljer 5 typer av pilar :

- ingång (engelsk input) - material eller information som används och omvandlas av arbetet för att få ett resultat (output). Ingången svarar på frågan "Vad behöver bearbetas?". Som ingång kan det antingen vara ett materialobjekt (råvara, del, tentamensbiljett), eller ett som inte har tydliga fysiska konturer (databasfråga, lärarens fråga). Det är tillåtet att verket inte får ha någon inmatningspil. Inmatningspilar ritas alltid till vänster i jobbet;

- kontrollera (Engelsk kontroll) - hantera, reglera och normativa data som styr arbetet. Ledningen svarar på frågan "I enlighet med vad är arbetet utfört?". Ledningen påverkar arbetet, men förvandlas inte av det, d.v.s. fungerar som en begränsning. Regler, standarder, föreskrifter, priser, muntliga instruktioner kan användas som ledning. Kontrollpilarna är ritade när de kommer in i jobbets övre yta. Om, när man konstruerar ett diagram, uppstår frågan om hur man korrekt ritar en pil på toppen eller till vänster, rekommenderas det att rita den som en ingång (pil till vänster);

- utgång (eng. output) - material eller information som representerar resultatet av arbetet. Resultatet svarar på frågan "Vad är resultatet av arbetet?". Utdata kan vara antingen ett materiellt objekt (en del, en bil, betalningsdokument, ett uttalande) eller ett immateriellt (välja data från en databas, svara på en fråga, verbal instruktion). Utgångspilar ritas från höger sida av jobbet;

- mekanism (engelsk mekanism) - resurser som utför arbete. Mekanismen svarar på frågan "Vem gör arbetet eller genom vad?". Mekanismen kan vara företagets personal, en student, ett verktygsmaskin, utrustning, ett program. Mekanismens pilar är ritade när de kommer in i verkets nedre yta;

- ring upp (engelsk samtal) - pilen indikerar att en del av arbetet utförs utanför det aktuella blocket. Utgångspilar ritas från undersidan av jobbet.

6.4. Typer av länkar mellan jobb

Efter att ha bestämt sammansättningen av funktioner och relationerna mellan dem, uppstår frågan om deras korrekta sammansättning (association) i moduler (delsystem). Detta innebär att varje enskild funktion måste lösa en strikt definierad uppgift. Annars är ytterligare nedbrytning eller separation av funktioner nödvändig.

När man kombinerar funktioner i delsystem är det nödvändigt att sträva efter att säkerställa att den interna kopplingen (mellan funktioner inom en modul) är så stark som möjligt och att den externa kopplingen (mellan funktioner som ingår i olika moduler) är så svag som möjligt. Baserat på semantiken för metodikens länkar introducerar vi en klassificering av länkar mellan funktioner (verk). Denna klassificering är en förlängning av . Typerna av länkar anges i fallande ordning efter deras betydelse (bindningsstyrka). I de givna exemplen framhäver de förtjockade linjerna de funktioner mellan vilka det finns en övervägd typ av koppling.

1. Hierarkisk koppling (koppling "del" - "hel") sker mellan en funktion och de delfunktioner som den är sammansatt av.

Ris. 6.2. Hierarkiskt förhållande

2. Reglerande (kontrollerande, underordnad) kommunikation reflekterar beroendet av en funktion av en annan, när resultatet av ett verk skickas för att styra ett annat. Den funktion från vilken styrningen kommer ut bör betraktas som reglerande eller styrande, och som den går in i - underordnad. Skilja på direkt styrlänk , när kontrollen överförs från ett högre jobb till ett lägre (Fig. 6.3), och ledningens feedback , när kontrollen överförs från den lägre till den högre (Fig. 6.4).

3. Funktionell (teknologisk) anslutning inträffar när utgången från en funktion är ingången till nästa funktion. Ur flödet av materiella objekts synvinkel visar denna koppling tekniken (arbetssekvensen) för att bearbeta dessa objekt. Skilja på direkt anslutning via ingång när utmatningen överförs från uppströmsjobbet till nedströms (Figur 6.5), och input feedback när utgången överförs från nedströms till uppströms (Fig.6.6).

Ris. 6.5. Direkt anslutning vid inträde	Ris. 6.6. Ingångsfeedback

4. Konsumentkommunikation inträffar när utsignalen från en funktion fungerar som mekanismen för nästa funktion. Således förbrukar en funktion resurser som genereras av en annan.

Ris. 6.7. Konsumentkommunikation

5. Logisk koppling observeras mellan logiskt homogena funktioner. Sådana funktioner utför som regel samma arbete, men på olika (alternativa) sätt eller med olika källdata (material).

Ris. 6.8. Logisk koppling

6. Kollegial (metodisk) kommunikation sker mellan funktioner vars operationsalgoritm bestäms av samma kontroll. En analog av en sådan anslutning är det gemensamma arbetet av anställda på en avdelning (kollegor), som rapporterar till chefen, som ger instruktioner och order (kontrollsignaler). En sådan anslutning uppstår också när algoritmerna för driften av dessa funktioner bestäms av samma metodologiska stöd (SNIP, GOST, officiella regleringsmaterial, etc.) som fungerar som kontroll.

Ris. 6.9. Metodisk koppling

7. Resursanslutning sker mellan funktioner som använder samma resurser för sitt arbete. Resursberoende funktioner kan som regel inte köras samtidigt.

Ris. 6.10. Resursanslutning

8. Informationsanslutning sker mellan funktioner som använder samma information som indata.

Ris. 6.11. Informationsanslutning

9. Tillfällig anslutning sker mellan funktioner som måste utföras samtidigt före eller samtidigt efter en annan funktion.

Utöver de fall som anges i figuren sker denna koppling även mellan andra kombinationer av styrning, ingång och mekanism som går in i samma funktion.

Ris. 6.12. Tillfällig anslutning

10. Slumpmässig anslutning uppstår när det finns lite eller inget specifikt samband mellan funktioner.

Ris. 6.13. Slumpmässig anslutning

Av ovanstående typer av länkar är den starkaste den hierarkiska länken, som i själva verket bestämmer associeringen av funktioner till moduler (delsystem). Reglerings-, funktions- och konsumentbanden är något svagare. Funktioner med dessa relationer implementeras vanligtvis i ett enda delsystem. Logiska, kollegiala, resurs- och informationsband är bland de svagaste. Funktioner som har dem är som regel implementerade i olika delsystem, med undantag för logiskt homogena funktioner (funktioner kopplade till en logisk anslutning). Temporell anslutning indikerar ett svagt beroende av funktioner av varandra och kräver att de implementeras i separata moduler.

Sålunda, när man kombinerar funktioner till moduler, är de första fem typerna av länkar de mest önskvärda. Funktionerna som är länkade av de senaste fem länkarna implementeras bäst i separata moduler.

I IDEF0 finns konventioner (regler och riktlinjer) för att skapa diagram som är utformade för att göra det lättare att läsa och granska [ , ]-modellen. Vissa av dessa regler stöds automatiskt av CASE-verktyg, medan andra måste upprätthållas manuellt.

1. Innan man bygger en modell är det nödvändigt att bestämma vilken eller vilka modeller av systemet som ska byggas. Detta inkluderar att specificera dess AS-IS-, TO-BE- eller SHOULD-BE-typ, samt att specificera från vilken position modellen är byggd. En "synvinkel" är bäst att tänka på som platsen (positionen) för en person eller ett föremål som man måste stå för att se systemet i aktion. Till exempel, när du bygger en modell av en livsmedelsbutik, kan du välja en säljare, kassörska, revisor eller direktör bland de möjliga sökande från vilken synvinkel systemet övervägs. Vanligtvis väljs en synvinkel, som mest täcker alla nyanser av systemdriften, och vid behov byggs FEO-diagram för vissa nedbrytningsdiagram, som visar en alternativ synvinkel.

2. Kontextdiagrammet visar ett block som visar syftet med systemet. Det rekommenderas att visa 2-4 pilar för det, in och ut från varje sida.

3. Antalet block på sönderdelningsdiagram rekommenderas inom 3–6. Om det finns två block på nedbrytningsdiagrammet är det som regel inte vettigt. Om det finns ett stort antal block blir diagrammet övermättat och svårt att läsa.

4. Block på sönderdelningsdiagrammet ska placeras från vänster till höger och uppifrån och ned. Detta arrangemang låter dig tydligare återspegla logiken och arbetssekvensen. Dessutom kommer pilarnas rutter att vara mindre förvirrande och ha ett minsta antal korsningar.

5. Om en funktion inte har kontroll- och inmatningspilar samtidigt är den inte tillåten. Detta innebär att lanseringen av denna funktion inte är kontrollerad och kan ske vid vilken godtycklig tidpunkt som helst eller aldrig alls.

Ris. 6.14. Funktion utan kontroll och ingång

Ett block med enbart styrning kan betraktas som ett anrop i programmet för en funktion (procedur) utan parametrar. Om blocket har en ingång är det likvärdigt med att anropa en funktion med parametrar i programmet. Ett block utan styrning och inmatning motsvarar alltså en funktion som aldrig anropas för exekvering i programmet.

På fig. 6.7–6.12, visar fragment av IDEF0-diagram, det finns block utan ingång och kontroll. Detta bör inte betraktas som en bugg, som en av dessa pilar är tänkt att vara.

6. Varje block måste ha minst en utgång.

Ris. 6.15. Funktion utan utgång

Verk utan resultat är meningslösa och bör inte modelleras. Undantaget är jobb som visas i AS-IS-modellen. Deras närvaro indikerar ineffektiviteten och ofullkomligheten hos tekniska processer. I TO-BE-modellen bör dessa verk saknas.

7. Vid konstruktion av diagram bör antalet korsningar, slingor och pilvarv minimeras.

8. Återkopplingar och iterationer (cykliska handlingar) kan avbildas med bakåtbågar. Ingångsåterkopplingar dras av den "nedre" slingan, styråterkopplingen dras av den "övre" (se Fig. 6.4 och 6.6).

9. Varje block och varje pil i diagrammen måste ha ett namn. Det är tillåtet att använda förgrening (sönderdelning) eller sammanslagning (sammansättning) av pilar. Detta beror på att samma data eller objekt som genereras av ett jobb kan användas i flera andra jobb samtidigt. Omvänt kan samma eller liknande data och objekt som genereras av olika jobb användas på samma plats.

Ris. 6.16. Pil förgrening

I det här fallet är det tillåtet att tilldela kvalificerande namn till olika grenar av pilen efter förgrening (innan sammanslagning). Om någon gren efter grenen inte namnges, anses dess namn motsvara pilnamnet som registrerats före grenen.

Så, i fig. 6.16, kontrollerna som ingår i blocken "Tillverkning av delar" och "Montering av produkten" har förtydligande värden och är en integrerad del av den mer allmänna kontrollen "ritningar". Alla ritningar används för driften av kvalitetskontrollblocket.

Det är inte tillåtet att rita pilar på diagrammet när de inte är namngivna före och efter förgrening. På fig. 6.17, pilen som ingår i blocket "Formation of standard statements" har inget namn före och efter förgrening, vilket är ett fel.

Ris. 6.17. Fel namn på pilen

10. Vid konstruktion av diagram för bättre läsbarhet kan piltunnelmekanismen användas. Till exempel, för att inte belamra diagrammen för de övre nivåerna (föräldrarna) med onödiga detaljer, placeras början av bågen i tunneln på nedbrytningsdiagrammen.

Ris. 6.18. Tunnlingspilar

I det här exemplet, när man bygger en modell för att hålla en nyårsfest, kommer mekanismen "två axlar" inte att visas på diagrammen på de övre nivåerna, när man läser vilken en rättvis fråga kan uppstå: "Varför behöver vi två axlar kl. en nyårsfest?".

På samma sätt kan du utföra tunnling med det motsatta målet att förhindra visningen av en pil på diagram på lägre nivå. I det här fallet placeras parenteser i slutet av pilen. På kontextdiagrammet (se fig. 6.21) tunneleras mekanismen "Spårservicetekniker", som ingår i blocket "Bestämning av tillåtna hastigheter". Detta beslut togs eftersom ingenjören är direkt involverad i allt arbete som visas på sönderdelningsdiagrammet för detta block (se fig. 6.22). För att inte visa detta samband och för att inte störa nedbrytningsdiagrammet har pilen tunnlats.

11. Alla pilar som går in i och lämnar blocket, när man konstruerar ett nedbrytningsdiagram för det, måste visas på det. Undantaget är de tunnlade pilarna. Namnen på pilarna som överförs till sönderdelningsdiagrammet måste matcha namnen som anges på toppnivådiagrammet.

12. Om två pilar löper parallellt (som börjar från samma sida av ett verk och slutar på samma sida av ett annat verk), bör de om möjligt kombineras och kallas en enda term.

Ris. 6.19. Kombinera länkar

13. Varje block på diagrammen måste ha sitt eget nummer. För att indikera positionen för valfritt diagram eller block i hierarkin används diagramnummer. Blocket på toppnivådiagrammet betecknas med 0, blocken på diagrammen på den andra nivån - med siffror från 1 till 9 (1, 2, ..., 9), blocken på tredje nivån - med två siffror, varav den första anger numret på det detaljerade blocket från det överordnade diagrammet, och det andra blocknumret i ordning på det aktuella diagrammet (11, 12, 25, 63), etc. Kontextdiagrammet har beteckningen "A - 0, är ​​sönderdelningsdiagrammet för den första nivån "A0", sönderdelningsdiagrammen för nästa nivåer består av bokstaven "A" följt av numret på blocket som ska dekomponeras (till exempel "A11", "A12" , "A25", "A63"). Figuren visar ett typiskt diagramträd (nodträdsdiagram) med numrering.

Ris. 6.20. Diagramhierarki

I moderna CASE-verktyg stöds jobbnumreringsmekanismer automatiskt. CASE-verktyg tillhandahåller också automatisk konstruktion av nodträdsdiagram som endast innehåller hierarkiska relationer. Spetsen för ett sådant diagram kan vara vilken nod som helst (block), och den kan byggas till vilket djup som helst.

6.6. Ett exempel på att bygga en IDEF0-modell för ett system för att bestämma tillåtna hastigheter

Beräkning av tillåtna tåghastigheter är en tidskrävande ingenjörsuppgift. När ett tåg passerar någon sektion får tågets faktiska hastighet inte överstiga den maximalt tillåtna. Denna högsta tillåtna hastighet fastställs på grundval av driftserfarenhet och speciellt utförda tester av rörelsedynamiken och påverkan på den rullande materielens spår. Att inte överskrida denna hastighet garanterar tågtrafikens säkerhet, bekväma körförhållanden för passagerare etc. De bestäms beroende på typen av rullande materiel (lokets märke och typ av vagnar), parametrarna för banans överbyggnad (typ). av räls, ballast, diagram över slipers) och plan (radiekurvor, övergångskurvor, yttre rälshöjd etc.). Som regel, för att fastställa de tillåtna hastigheterna, är det nödvändigt att bestämma minst två (på raka linjer) och fem (i kurvor) hastigheter, från vilka den slutliga tillåtna hastigheten väljs, som den minsta av alla beräknade. Beräkningen av dessa hastigheter regleras av Order of the Ministry of Railways of Russia nr 41 daterad 12 november 2001 "Normer för tillåtna hastigheter för rullande materiel på järnvägsspår med en spårvidd på 1520 (1524) mm från Federal Railway Transport".

Som nämnts börjar konstruktionen av IDEF0-modellen med representationen av hela systemet i form av den enklaste komponenten (kontextdiagram). Detta diagram visar syftet (huvudfunktionen) för systemet och nödvändiga in- och utdata, kontroll- och regleringsinformation samt mekanismer.

Kontextdiagrammet för uppgiften att bestämma de tillåtna hastigheterna visas i fig. 6.21. Modellen byggdes med BPwin 4.0-produkten från Computer Associates.

Ris. 6.21. Kontextdiagram över systemet för att bestämma tillåtna hastigheter (IDEF0-metod)

Som bakgrundsinformation, på grundval av vilken bestämningen av tillåtna hastigheter utförs, används:

Data för ett nytt linjeprojekt eller ett rekonstruktionsprojekt (innehåller all nödvändig information för genomförandet av projektet, nämligen körsträcka, axlar för separata punkter, linjeplan, etc.);

Detaljerad längsgående profil (innehåller information liknande den som diskuterats ovan);

Banavståndspass (innehåller information liknande den som diskuterats ovan, samt information om banans överbyggnad (VSP));

Data om resultaten av kartläggning av spårplanen med en spårmätningsbil;

Höjdförteckning av ytterskenan i kurvor (innehåller information om spårplanen).

En del av den initiala informationen kan hämtas från olika källor. I synnerhet kan information om planen (kurvparametrar) hämtas från ett nytt linjeprojekt eller ett ombyggnadsprojekt, en detaljerad längsgående profil, ett spåravståndspass etc.

kontrolldataär:

Indikation på chefen för vägens spårtjänst eller avdelningen för spår och strukturer för ryska järnvägar för beräkning;

Order nr 41, som innehåller reglerande och referensinformation, förfarandet och formler för att bestämma tillåtna hastigheter;

Information om det aktuella eller planerade tågflödet (data om märken av lok i omlopp och vilka typer av vagnar som används);

Information om planerade reparationer av banan, ombyggnad och omorganisation av strukturer och anordningar.

resultat systemdrift bör vara:

Listor över tillåtna hastigheter som innehåller alla typer av beräknade hastigheter och gör det möjligt att fastställa orsaken till deras begränsning;

Uttalanden av vägledarens order om fastställande av tillåtna hastigheter på drag och separata punkter (ordning "N") i enlighet med den form som antagits på vägen. Den godkända ordern "N" fastställer officiellt de tillåtna tåghastigheterna;

Standardformulär nr 1, 1a och 2, innehållande de planerade tillåtna hastigheterna för utveckling av ett tågschema.

Hastigheterna i Order "N" och standardformulären kan skilja sig från de som beräknas och visas i arken med tillåtna hastigheter. Detta beror på det faktum att de återspeglar hastighetsgränser inte bara genom utformningen av den rullande materielen, VSP-parametrar och kurvor, utan också av tillståndet för enheter och strukturer (deformation av underlaget, snedställning av kontaktnätets stöd, etc. ). Dessutom justeras de med hänsyn till planerade spårreparationer, ombyggnad och omorganisation av strukturer och anordningar m.m.

Efter konstruktionen är kontextdiagrammet detaljerat med hjälp av sönderdelningsdiagrammet på första nivån. Detta diagram visar funktionerna i systemet som måste implementeras i huvudfunktionen. Diagrammet för vilket nedbrytningen utförs, i förhållande till diagrammen som beskriver det, kallas förälder . Nedbrytningsdiagrammet med avseende på föräldern kallas dotterföretag .

Nedbrytningsdiagrammet för den första nivån för det aktuella problemet visas i fig. 6.22. När man konstruerar ett nedbrytningsdiagram delas i regel den ursprungliga funktionen (nedbruten) in i 3–8 delfunktioner (block). Samtidigt rekommenderas det att placera blocken på sönderdelningsdiagrammet från vänster till höger, uppifrån och ned, så att sekvensen och logiken för interaktionen av underfunktioner kan ses bättre.

Ris. 6.22. Första nivås sönderdelningsdiagram (IDEF0-metodik)

Ordningen för utförande av funktioner för att lösa det aktuella problemet är som följer:

Inmatning och uppdatering av referensinformation och data om vägavsnitt (block 1 och 2);

Förberedelse av en uppgift för beräkning (block 3). Den anger för vilken sektion och bana, samt lokets märke och typen av vagnar, beräkningen ska utföras;

Beräkning av tillåtna hastigheter enligt proceduren och formlerna som anges i order nr 41 (block 4). Källinformationen är data om sträckans väg (plan, överbyggnad av banan, etc.) och standarder valda på grundval av uppgiften för beräkningen;

Bildande av uppgifter om tillåtna hastigheter (block 5). Baserat på resultatet av beräkningen skapas flera typer av utdatadokument, som å ena sidan gör det möjligt att identifiera orsaken till hastighetsbegränsningar, å andra sidan fungerar som underlag för upprättande av reglerade dokument;

Utformning och utarbetande av utkastet till Order "N" och standardutlåtanden (block 6 och 7).

Efter att ha konstruerat nedbrytningsdiagrammet för den första nivån, konstrueras separata diagram för de funktioner som anges på den (nedbrytningsdiagram för den andra nivån). Sedan fortsätter nedbrytningsprocessen (byggnadsdiagram) tills ytterligare detaljering av funktioner inte förlorar sin mening. För varje atomfunktion som beskriver en elementär operation (det vill säga en funktion som inte har ett nedbrytningsdiagram), sammanställs en detaljerad specifikation som definierar dess egenskaper och implementeringsalgoritm. Flödesscheman över algoritmer kan användas som ett tillägg till specifikationen. Processen med funktionell modellering består således i att gradvis bygga en hierarki av funktioner.

6.7. ICOM-koder

Pilarna som går in i och ut ur blocket i diagrammet på översta nivån är desamma som pilarna som går in i och ut från diagrammet på lägre nivå, eftersom blocket och diagrammet representerar samma del av systemet (se figur 2). Och ). Som en konsekvens är gränserna för toppnivåfunktionen desamma som gränserna för sönderdelningsdiagrammet.

ICOM-koder (förkortning för Input, Control, Output och Mechanism) används för att identifiera gränspilar. ICOM-koden innehåller ett prefix som motsvarar typen av pil (I, C, O eller M) och ett sekvensnummer (se figur).