Grundläggande element och koncept för IDEF0

IDEF0-standardens historia

IDEF0 standard

IDEF0-metoden kan betraktas som nästa steg i utvecklingen av det välkända grafiska språket för att beskriva funktionella system SADT (Structured Analysis and Design Teqnique). Historiskt sett utvecklades IDEF0 som standard 1981 av det amerikanska flygvapnets departement som en del av det industriella automationsprogrammet, som bar beteckningen ICAM (Integrated Computer Aided Manufacturing). IDEF-standarderna ärvde sitt namn från detta program (IDEF=ICAM DEFinition). I den praktiska implementeringsprocessen stod deltagarna i ICAM-programmet inför behovet av att utveckla nya metoder för att analysera interaktionsprocesser i industriella system. Samtidigt, förutom en förbättrad uppsättning funktioner för att beskriva affärsprocesser, var ett av kraven för den nya standarden tillgången på en effektiv metodik för interaktion inom "analytiker-specialisten". Den nya metoden var med andra ord tänkt att ge grupparbete med skapandet av modellen, med direkt deltagande av alla analytiker och specialister som är involverade i projektet.

Som ett resultat av sökandet efter lämpliga lösningar föddes IDEF0. Sedan 1981 har IDEF0-standarden genomgått flera mindre revisioner, mestadels av restriktiv karaktär, och dess senaste revidering släpptes i december 1993 av US National Institute of Standards and Technology (NIST).

Det grafiska språket IDEF0 är anmärkningsvärt enkelt och harmoniskt. Metodiken bygger på fyra huvudkoncept:

Funktionsblock (Activity Box);

Gränssnittsbåge (pil);

Nedbrytning (nedbrytning);

Ordlista.

Låt oss ta en närmare titt på dessa grundläggande begrepp.

Funktionsblock (Activity Box)

Det funktionella blocket är grafiskt avbildat som en rektangel (fig. 1) och representerar någon specifik funktion inom det betraktade systemet. Enligt kraven i standarden måste namnet på varje funktionsblock formuleras i den verbala stämningen (till exempel "att producera tjänster" och inte "att producera tjänster").

Var och en av de fyra sidorna av det funktionella blocket har sin egen specifika betydelse (roll), medan:

Den övre sidan är "Kontroll";

Den vänstra sidan är "Input";

Den högra sidan är inställd på "Output";

Undersidan har betydelsen "Mechanism" (Mechanism).

En sådan beteckning speglar vissa systemprinciper: ingångar omvandlas till utgångar, styrgränser eller föreskriver villkoren för att utföra transformationer, mekanismer visar vad och hur en funktion utför.

Varje funktionell enhet inom det enskilda systemet i fråga måste ha sitt eget unika identifikationsnummer.

Ris. 1. Funktionsblock.

IDEF0 kräver att ett diagram har minst tre och högst sex rutor. Dessa begränsningar håller komplexiteten i diagrammen och modellerna på en nivå som kan läsas, förstås och användas.

Blocken i IDEF0 är placerade i ordning efter betydelse, enligt upphovsmannen till diagrammet. Denna relativa ordning kallas dominans. Dominans förstås som det inflytande som ett block har på andra block i diagrammet. Till exempel kan det mest dominerande blocket i diagrammet vara antingen det första av en nödvändig sekvens av funktioner, eller en planerings- eller kontrollfunktion som påverkar alla andra.

Den mest dominerande rutan placeras vanligtvis i det övre vänstra hörnet av diagrammet, medan den minst dominerande rutan placeras i det högra hörnet.

Arrangemanget av block på sidan speglar författarens definition av dominans. Således visar diagrammets topologi vilka egenskaper som har större inverkan på de andra. För att understryka detta kan analytikern numrera om blocken enligt deras dominansordning. Ordningen för dominans kan anges med ett nummer placerat i det nedre högra hörnet av varje ruta: 1 skulle indikera den högsta dominansen, 2 nästa, och så vidare.

Gränssnittsbåge (pil)

Dessutom kallas gränssnittsbågar ofta för flöden eller pilar. En gränssnittsbåge representerar ett systemelement som bearbetas av ett funktionsblock eller på annat sätt påverkar funktionen som visas av detta funktionsblock.

Den grafiska visningen av gränssnittsbågen är en enkelriktad pil. Varje gränssnittsbåge måste ha sitt eget unika namn (Arrow Label). Enligt standarden ska namnet vara en omsättning av ett substantiv.

Med hjälp av gränssnittsbågar visas olika objekt som i en eller annan grad bestämmer de processer som sker i systemet. Sådana objekt kan vara delar av den verkliga världen (delar, vagnar, anställda, etc.) eller data- och informationsflöden (dokument, data, instruktioner etc.).

Beroende på vilken av sidorna detta gränssnittsbåge närmar sig kallas det "inkommande", "utgående" eller "kontrollerande". Dessutom kan "källan" (början) och "mottagaren" (slutet) för varje funktionsbåge endast vara funktionella block, medan "källan" bara kan vara utgångssidan av blocket, och "mottagaren" kan vara vilken som helst av de tre kvarvarande.

Pilens namn ges vanligtvis av ett substantiv.

IDEF0-metoden kräver endast fem typer av interaktioner mellan block för att beskriva deras relationer:

Ingångsanslutning (utgång-ingång), när utgången från det högre verket är ansluten till ingången på det lägre (fig. 2);

Ris. 2. Kommunikation genom input

Styranslutning (output-control), när utgången från det högre verket är anslutet till styrningen av det lägre (fig. 3);

Ris. 3.Kommunikation för ledningen

Ingångsåterkoppling (utgång-ingångsåterkoppling), när utgången från det lägre verket är ansluten till ingången på det högre;

Ris. 4. Mata in feedback

Styråterkoppling (output-control feedback), när utgången från det lägre verket är anslutet till styringången för det högre verket;

Ris. 5. Ledningens feedback

En utgångsmekanismlänk är när utsignalen från ett jobb riktas till mekanismen hos ett annat.

Ris. 6. Anslutning av utgångsmekanism

Kontroll- och inträdesrelationer är de enklaste eftersom de återspeglar direkta handlingar som är intuitiva och mycket enkla.

Ett kontrollförhållande uppstår när utsignalen från ett block direkt påverkar ett block med mindre dominans.

Kontrollfeedback och inputfeedback är mer komplexa eftersom de är iterativa eller rekursiva. Utgångar från ett jobb påverkar nämligen det framtida utförandet av andra jobb, vilket sedan kommer att påverka det ursprungliga jobbet.

Styråterkoppling sker då; när utdata från något block påverkar ett block med mer dominans.

Exit-mekanismrelationer är sällsynta. De återspeglar en situation där produktionen av en funktion blir ett medel för ett mål för en annan. Sådana relationer är karakteristiska för fördelningen av resurskällor (t.ex. nödvändiga verktyg, utbildad personal, fysiskt utrymme, utrustning, finansiering, material).

I IDEF0 avbildar en båge sällan ett enda föremål. Vanligtvis symboliserar det en uppsättning objekt. Eftersom bågar representerar samlingar av objekt kan de ha flera startpunkter (källor) och slutpunkter (destinationer). Därför kan bågar förgrena sig och ansluta på olika sätt. Hela bågen eller en del av den kan gå ut från ett eller flera block och sluta i ett eller flera block.

Bågarnas förgrening, avbildad som divergerande linjer, gör att hela eller delar av innehållet i bågarna kan förekomma i varje gren. En båge är alltid märkt före en gren för att ge ett namn till hela uppsättningen. Dessutom kan varje gren av en båge vara märkt enligt följande regler:

Omärkta grenar innehåller alla objekt som anges i bågetiketten före grenen;

Grenar märkta efter en förgreningspunkt innehåller alla eller delar av de objekt som anges i bågetiketten före förgreningen.

Bågsammanslagningar i IDEFO, visade som linjer som konvergerar tillsammans, indikerar att innehållet i varje gren går till att bilda en etikett för bågen som härrör från sammanslagning av de ursprungliga bågarna. Efter en sammanslagning markeras den resulterande bågen alltid för att indikera den nya uppsättningen funktioner som uppstod efter sammanfogningen. Dessutom kan varje gren flaggas eller inte vara flaggad före en sammanslagning, enligt följande regler:

Omärkta grenar innehåller alla entiteter som anges i den gemensamma bågetiketten efter sammanfogningen;

Grenar markerade före sammanfogningen innehåller alla eller några av objekten som listas i det gemensamma märket efter sammanfogningen,

Det bör noteras att varje funktionsblock, enligt kraven i standarden, måste ha minst en styrgränssnittsbåge och en utgående. Detta är förståeligt - varje process måste ske enligt vissa regler (visas av kontrollbågen) och måste producera något resultat (utgående båge), annars är dess övervägande inte meningsfullt.

När man konstruerar IDEF0-diagram är det viktigt att korrekt separera inkommande gränssnittsbågar från kontrollbågar, vilket ofta inte är lätt. Till exempel visar figur 7 funktionsblocket "Bearbeta arbetsstycket".

I en verklig process får arbetaren som utför bearbetningen ett arbetsstycke och tekniska instruktioner för bearbetning (eller säkerhetsföreskrifter vid arbete med maskinen). Det kan av misstag verka som att både arbetsstycket och dokumentet med tekniska instruktioner är inmatningsobjekt, men så är inte fallet. I själva verket, i denna process, bearbetas arbetsstycket enligt reglerna som återspeglas i de tekniska instruktionerna, som respektive ska avbildas av styrgränssnittsbågen.

Ris. 7. Funktionsblock "Bearbeta arbetsstycke".

En annan sak är när tekniska instruktioner bearbetas av chefsteknologen och ändringar görs i dem (fig. 8). I detta fall visas de redan av den inkommande gränssnittsbågen, och kontrollobjektet är till exempel nya industristandarder, baserade på vilka dessa ändringar görs.

Ris. 8. Funktionsblock "Rätta tekniska instruktioner"

Exemplen ovan betonar den till synes liknande karaktären hos inkommande och styrande gränssnittsbågar, men det finns alltid vissa skillnader för system av samma klass. Till exempel, när det gäller företag och organisationer, finns det fem huvudtyper av objekt: materialflöden (delar, varor, råvaror, etc.), finansiella flöden (kontanter och icke-kontanter, investeringar etc.), dokument flöden (kommersiella, finansiella och organisatoriska dokument), informationsflöden (information, avsiktsdata, muntliga order etc.) och resurser (anställda, maskiner, maskiner etc.). I det här fallet, i olika fall, kan inkommande och utgående gränssnittsbågar visa alla typer av objekt som endast hanterar de som är relaterade till flödet av dokument och information, och endast resurser kan visas som bågar-mekanismer.

Den obligatoriska närvaron av styrgränssnittsbågar är en av huvudskillnaderna mellan IDEF0-standarden och andra metoder för klasserna DFD (Data Flow Diagram) och WFD (Work Flow Diagram).

Sönderfall

Principen om nedbrytning tillämpas när en komplex process bryts ner i dess ingående funktioner. I det här fallet bestäms processens detaljnivå direkt av utvecklaren av modellen.

Nedbrytning gör att du gradvis och strukturerat kan representera systemmodellen i form av en hierarkisk struktur av individuella diagram, vilket gör den mindre överbelastad och lättsmält.

IDEF0-modellen börjar alltid med en bild av systemet som helhet - en enda funktionell enhet med gränssnittsbågar som sträcker sig utanför det aktuella området. Ett sådant diagram med ett funktionsblock kallas ett kontextdiagram och betecknas med identifieraren "A-0" (fig. 9).

Ris. 9. Exempel på kontextdiagram

I den förklarande texten till kontextdiagrammet bör syftet (Syftet) med att konstruera diagrammet i form av en kort beskrivning anges och synvinkeln (Viewpoint) fastställas.

Att bestämma och formalisera syftet med att utveckla en IDEF0-modell är en extremt viktig punkt. Faktum är att målet avgör de relevanta områdena i det studerade systemet, som måste fokuseras först. Till exempel, om vi modellerar verksamheten i ett företag för att bygga ett informationssystem baserat på denna modell i framtiden, kommer denna modell att skilja sig väsentligt från den som vi skulle utveckla för samma företag, men med syftet att optimera leveranskedjor.

Synvinkeln bestämmer huvudriktningen för utvecklingen av modellen och vilken detaljnivå som krävs. En tydlig fixering av synvinkeln gör att du kan ladda ur modellen, vägra att detaljera och studera enskilda element som inte är nödvändiga, baserat på den valda synvinkeln på systemet. Till exempel kommer funktionella modeller för samma företag från chefsteknologens och finanschefens synvinkel att skilja sig avsevärt i riktningen för deras detaljering. Detta beror på det faktum att finansdirektören i slutändan inte är intresserad av aspekterna av bearbetning av råvaror på produktionsmaskiner, och chefsteknologen är inte intresserad av de ritade planerna för finansiella flöden. Rätt val av synvinkel minskar avsevärt tiden som läggs på att bygga den slutliga modellen.

Under nedbrytningsprocessen beskrivs funktionsblocket, som i kontextdiagrammet visar systemet som helhet, i ett annat diagram. Det resulterande diagrammet för den andra nivån innehåller funktionsblock som visar huvuddelfunktionerna i funktionsblocket i kontextdiagrammet och kallas ett underordnat diagram (Barndiagram) i förhållande till det (vart och ett av funktionsblocken som hör till underdiagrammet är resp. kallas ett barnblock - Child Box). I sin tur det funktionella blocket - förfadern kallas föräldrablocket i förhållande till underordnat diagram (Parent Box), och diagrammet som det tillhör kallas förälderdiagrammet (Prent Diagram). Var och en av underfunktionerna i barndiagrammet kan detaljeras ytterligare genom en liknande uppdelning av dess motsvarande funktionsblock. Det är viktigt att notera att i varje fall av nedbrytning av ett funktionsblock är alla gränssnittsbågar som ingår i detta block eller utgående från det fixerade på barndiagrammet. Detta uppnår IDEF0-modellens strukturella integritet. Principen för sönderdelning visas tydligt i figur 10. Du bör vara uppmärksam på förhållandet mellan numreringen av funktionsblock och diagram - varje block har sitt eget unika serienummer på diagrammet (numret i det nedre högra hörnet av rektangeln) , och beteckningen i rät vinkel indikerar numret på underordnat diagram för detta block. Frånvaron av denna beteckning indikerar att det inte finns någon sönderdelning för detta block.

Ofta finns det fall då det inte är meningsfullt att fortsätta att överväga individuella gränssnittsbågar i underordnade diagram under en viss nivå i hierarkin, eller vice versa - individuella bågar är inte praktiskt vettiga över en viss nivå. Till exempel är en gränssnittsbåge som visar en "detalj" vid ingången till funktionsblocket "Bearbetning på en svarv" inte meningsfullt att reflektera över diagram på högre nivåer - detta kommer bara att överbelasta diagrammen och göra dem svåra att läsa. Å andra sidan finns det ett behov av att bli av med separata "konceptuella" gränssnittsbågar och att inte detaljera dem djupare än en viss nivå. För att lösa sådana problem tillhandahåller IDEF0-standarden konceptet med tunnling. Beteckningen "tunneln" (Arrow Tunnel) i form av två parenteser runt början av gränssnittsbågen betyder att denna båge inte ärvdes från det funktionella föräldrablocket och förekom (från "tunneln") endast på detta diagram. I sin tur betyder samma beteckning runt änden (pilen) av gränssnittsbågen i omedelbar närhet av mottagarblocket att denna båge inte kommer att visas och kommer inte att beaktas i det underordnade diagrammet för detta block. Oftast händer det att enskilda objekt och deras motsvarande gränssnittsbågar inte beaktas på vissa mellanliggande nivåer i hierarkin - i det här fallet "kastar de först in i tunneln" och sedan, om nödvändigt, "återvänder de från tunneln".