IDEF0 metodik. Notation, modelleringsprinciper

För att lära känna IDEF0 -standarden närmare måste du veta följande om den:

1. För konstruktion av vilka typer av modeller denna standard används.
2. Vilka element i det grafiska språket ingår i notationen av standarden, och vilka krav på utformning av diagram finns inom ramen för standarden.
3. Vilka principer för affärsprocessmodellering används i standarden (sönderdelningsprincip, komplexitetsbegränsningsprincip, tunnelprincip).
4. Hur kan de konstruerade diagrammen utvärderas när det gäller överbelastning och balans?

IDEF0 används för att skapa funktionell modell, speglar systemets struktur och funktioner, liksom flödena av information och materiella föremål, transformerade av dessa funktioner.

IDEF0 -metoden skiljer sig något från det klassiska schemat för beskrivning av affärsprocesser i DFD. Den största skillnaden är klassificeringen av arbetsinsatserna.

Klassificering av arbetsinsatser och utgångar

Standarden erbjuder följande typ av arbetsinsatser:

• ingång... Den går in i arbetet till vänster och visar information och materialflöden som omvandlas i affärsprocessen.
• Kontrollera. Den går in i verket ovanifrån och visar material- och informationsflöden som inte transformeras i processen, men som behövs för att slutföra det.
• Mekanism. Han går in i arbetet underifrån och visar människor, tekniska medel, informationssystem etc. med hjälp av vilken affärsprocessen genomförs.
• resultat lämna blocket till höger.

Huvudelementen i diagrammet:

Det grafiska språket IDEF0, vars syntax och semantik definieras med absolut noggrannhet, är baserat på block och pilar som förbinder dem, som bildar en hierarki med detaljerade diagram.

Element	Grafisk display och meningen	Krav för registrering
Funktionell blockera	Ritad som en rektangel. Representerar en funktion som definieras som en aktivitet, process, operation, handling eller transformation.	1. Måste ha unika identifikationsnummer i nedre högra hörnet; 2. Titeln måste vara i verbal stämning.
Gränssnittbåge (pil, båge)	Den avbildas som en enriktad pil. De representerar data eller materialobjekt som är associerade med funktioner.	1. Måste ha ett unikt namn. 2. Namnet måste vara en omsättning av ett substantiv. 3. Början och slutet av bågen kan bara vara funktionella block. 4. Källan kan bara vara blockets utsida och mottagaren kan vara vilken som helst av de tre återstående.

IDEF0 - modell:

Modellen innehåller följande dokument som refererar till varandra:

• Grafiska diagram- huvudkomponenten i IDEF0-modellen, som grafiskt, med hjälp av block och pilar och deras anslutningar, visar information om det simulerade systemet. Blocken representerar huvudfunktionerna. Dessa funktioner kan brytas ner (sönderdelas) i sina komponenter och presenteras i form av mer detaljerade diagram. Nedbrytningsprocessen fortsätter tills objektet beskrivs i detaljnivå som krävs för att uppnå målen för ett visst projekt.
• Text;
• Ordlista- För varje element i diagrammet skapas och underhålls en uppsättning definitioner, nyckelord, förklaringar som kännetecknar objektet som representerar detta element. Denna uppsättning kallas en ordlista och är en beskrivning av essensen i detta element. Ordlistan kompletterar harmoniskt det grafiska språket och ger diagrammen nödvändig ytterligare information.

Till exempel för kontrollgränssnittsbågen "betalningsorder" kan ordlistan innehålla en lista över fält i dokumentet som motsvarar bågen, den obligatoriska uppsättningen visum och så vidare.

Nedbrytningsprincipen när man bygger en affärsprocessmodell

1. Kontextdiagram: syfte och synvinkel

Affärsprocessmodellering börjar med ett kontextdiagram. Detta diagram kallas A - 0 (A minus noll). På den representeras systemet som ett enda block och bågar som representerar systemets miljö. Med hjälp av diagrammet kan du se interaktionen mellan det modellerade systemet och den externa miljön, alla dess ingångar och utgångar. Diagram A - 0 anger modellområdet och gränserna.

Den förklarande texten för sammanhangsdiagrammet måste ange ändamål rita diagrammet och fixa synpunkt... Synspunkten avgör detaljnivån, modellens utvecklingsriktning och låter dig ladda ur modellen. Så när du modellerar kan du vägra att detaljera och studera enskilda element som inte är nödvändiga, baserat på den valda synvinkeln på systemet.

2. Detaljer

Sedan beskrivs blocket som visar hela systemet i ett annat diagram.

Vidare kan varje funktion i diagrammet detaljeras om barnet. Varje funktion modelleras i ett separat block. Varje förälderblock beskrivs i detalj av ett barndiagram på en lägre nivå. Detta sker tills en struktur erhålls som gör att du kan svara på frågorna som formuleras i modelleringsmålet.

För att uppnå modellens strukturella integritet används följande regler:

• Alla gränssnittsbågar som ingår i detta block eller utgående från det är fixerade på underdiagrammet.
• Vid numrering av block indikerar figuren i rektangelns nedre högra hörn det unika serienumret för själva blocket i diagrammet, och beteckningen i höger vinkel indikerar numret på barndiagrammet för detta block.

Tunnelprincip

Det finns ofta tillfällen då enskilda pilar inte är vettiga att fortsätta ses i barndiagram under en viss nivå i hierarkin, eller vice versa - enskilda block är inte praktiskt meningsfulla över en viss nivå. Å andra sidan blir det ibland nödvändigt att bli av med enskilda "konceptuella" pilar och inte detaljera dem djupare än en viss nivå.

För att lösa sådana problem tillhandahåller IDEF0 -standarden konceptet tunnel... Beteckningen på en "tunnel" i form av två parenteser runt början av en pil indikerar att denna pil inte ärvdes från det funktionella överordnade blocket och visades (från "tunneln") endast i detta diagram. I sin tur betyder samma beteckning runt pilens ände i omedelbar närhet av mottagarblocket det faktum att denna barns pil i barndiagrammet inte kommer att visas och inte kommer att beaktas.

Principen att begränsa komplexiteten

För att begränsa trängseln i modellerna och göra dem lättlästa antog standarden motsvarande komplexitetsbegränsningar:

• begränsa antalet funktionella block i diagrammet till tre till sex. Den övre gränsen (sex) tvingar designern att använda hierarkier när de beskriver komplexa objekt, och den nedre gränsen (tre) säkerställer att det finns tillräckligt med detaljer på motsvarande diagram för att motivera dess skapande;
• begränsa antalet gränssnittsbågar som är lämpliga för ett funktionsblock (lämnar ett funktionsblock) till fyra.

Naturligtvis är det inte alls nödvändigt att strikt följa dessa begränsningar, men som erfarenhet visar är de mycket praktiska i verkligt arbete.

Kvantitativ diagramanalys: Balansfaktor och namnpoäng

För att analysera diagrammet när det gäller trängsel och komplexitet för uppfattning används kvantitativ analys. Följande indikatorer används för analysen:

• antalet block i diagrammet - N;
• diagram sönderdelningsnivå - L;
• balansdiagram - I;
• antalet pilar som ansluter till blocket - MEN.

Balansfaktor

Det är nödvändigt att sträva efter att se till att antalet block i diagram på lägre nivå skulle vara lägre än antalet block i överordnade diagram.

På samma sätt måste diagrammen vara balanserade. Detta innebär att inom ramen för ett diagram ska en situation inte uppstå när det finns betydligt fler inkommande och utgående pilar än utgående.

Det bör noteras att denna rekommendation inte får följas i modeller som beskriver produktionsprocesser. Till exempel, när man beskriver ett monteringsförfarande, kan ett block innehålla många pilar som beskriver komponenterna i en produkt, och en pil kan slockna - en färdig produkt.

Låt oss introducera diagramets balansfaktor:

Det är nödvändigt att sträva efter Kh var minimal för diagrammet och minskade med en ökning av sönderdelningsnivån.

Namnvärdering

Förutom att analysera diagrammets grafiska element är det nödvändigt att överväga namnen på blocken. För att utvärdera namnen sammanställs en ordbok med elementära (triviala) funktioner i det modellerade systemet. Faktum är att funktionerna för den lägre, nedbrytningsnivån av diagram bör komma in i denna ordbok.

Till exempel för en databasmodell kan funktionerna "hitta en post", "lägg till en post i databasen" vara elementära, medan funktionen "användarregistrering" kräver ytterligare beskrivning.

Efter att ha formulerat ordförrådet och sammanställt ett paket med systemdiagram är det nödvändigt att överväga modellens lägre nivå. Om det finns tillfälligheter i namnen på diagramblocken och ord från ordlistan på den, indikerar detta att en tillräcklig grad av sönderdelning har uppnåtts.

Koefficienten som kvantitativt återspeglar detta kriterium kan skrivas som:

L * C

— produkten av modellnivån med antalet matchningar av blocknamn med ord från ordlistan. Ju lägre modellnivå (högre L), desto mer värdefull är tillfälligheterna.