Modelleerimine idef0. IDEF0 tähistuse tutvustus ja kasutusnäide

Need standardimissoovitused on mõeldud kasutamiseks tootmis-, tehniliste ja organisatsioonilis-majanduslike süsteemide analüüsil ja sünteesil funktsionaalse modelleerimise meetodite abil erinevates majandussektorites.
Soovitused sisaldavad tööriistakomplekti kirjeldust, mis võimaldab visuaalselt kujutada ettevõtte laia valikut äri-, tootmis- ja muid protsesse ja toiminguid mis tahes üksikasjalikkuse tasemel,samuti nende vahendite kasutamise organisatsioonilised ja metoodilised võtted.

Tootmis-tehniliste ja organisatsioonilis-majanduslike süsteemide – firmade, ettevõtete, tööstusharude jt tootmis- ja majandustegevuse subjektide – pidev komplitseerimine ning nende analüüsimise vajadus toimimise parandamiseks ja efektiivsuse tõstmiseks tingib vajaduse kasutada spetsiaalseid tööriistu kirjeldamaks ja selliste süsteemide analüüsimine. See probleem on eriti oluline seoses integreeritud arvutipõhise tootmise ja automatiseeritud ettevõtete tulekuga.
Ameerika Ühendriikides pakuti 70ndate lõpus välja ja rakendati integreeritud arvutipõhise tootmisprogrammi (ICAM), mille eesmärk oli suurendada ettevõtete tõhusust arvuti(teabe)tehnoloogia laialdase kasutuselevõtu kaudu.
ICAM programmi rakendamine eeldas adekvaatsete meetodite loomist tootmissüsteemide analüüsiks ja kujundamiseks ning selliste probleemidega tegelevate spetsialistide vahelise teabevahetuse viisid. Selle vajaduse rahuldamiseks töötati ICAM programmi raames välja IDEF (ICAM Definition) modelleerimismetoodika, mis võimaldab uurida tootmise, tehniliste ja organisatsioonilis-majanduslike süsteemide struktuuri, parameetreid ja omadusi.

IDEF-i metoodika

Üldine IDEF-metoodika koosneb kolmest spetsiifilisest modelleerimismetoodikast, mis põhinevad süsteemide graafilisel kujutamisel:
IDEF0 kasutatakse kuvatava funktsionaalse mudeli loomisekssüsteemi struktuur ja funktsioonid, samuti teabe- ja materjalivoodnende funktsioonide poolt teisendatud objektid;
IDEF1 kasutatakse kuvatava teabemudeli koostamisekstoetamiseks vajalike infovoogude struktuur ja sisusüsteemi funktsioonid;
IDEF2 võimaldab teil luua ajas muutuva dünaamilise mudelisüsteemi funktsioonide, teabe ja ressursside käitumine.
Praeguseks on enim levinud ja kasutatud IDEF0 ja IDEF1 (IDEF1X) metoodikad.
IDEF0 metoodika, mille omadusi ja rakendust on kirjeldatud nendes soovitustes, põhineb lähenemisel nn
SADT – Structured Analysis & Design Technique – struktuurianalüüsi ja disaini meetod. Selle lähenemise ja IDEF0 metoodika aluseks on graafiline keel süsteemide kirjeldamiseks (modelleerimiseks).

Üldmõisted

IDEF0 mudel: süsteemi graafiline kirjeldus, mis on loodud kindla eesmärgi jaoks ja valitud vaatepunktist. IDEF0 dokumentide komplekt, mis kujutab süsteemi funktsioone graafika (skeemide), teksti ja sõnastikku kasutades.
Eesmärk: mudeli loomise põhjuse lühikirjeldus.
Vaatepunkt: märge organisatsiooni ametniku või osakonna kohta, kelle positsioonilt mudelit arendatakse. Iga mudeli jaoks on ainult üks vaatenurk.
Sõnastik: sõlmede, plokkide, noolte või IDEF0 mudeliga üldiselt seotud märksõnade, fraaside ja lühendite määratluste loend.
Tekst: IDEF0 graafilise diagrammi mis tahes tekst (mittegraafiline) kommentaar.
Mudeli märkus: tekstikommentaar, mis on osa IDEF0 diagrammist ja mida kasutatakse fakti salvestamiseks, mis ei leia graafilist esitust.
Funktsioon: tegevus, protsess või teisendus (modelleeritud IDEF0 plokiga), mis on identifitseeritud verbi või verbivormiga, mis kirjeldab, mida tuleb sooritada.
Dekomponeerimine: modelleeritud funktsiooni jagamine komponentfunktsioonideks.

Konteksti diagrammi näide

Diagramm

Diagramm: osa mudelist, mis kirjeldab ploki lagunemist.
Kontekst: keskkond, milles funktsioon (või funktsioonide kogum diagrammil) töötab.
Kontekstidiagramm: sõlme numbritega A–n (A miinus n) diagramm, mis esindab mudeli konteksti. Ühest plokist koosnev A-0 diagramm on vajalik (kohustuslik) kontekstdiagramm; sõlmede numbritega A–1, A–2, ... diagrammid on täiendavad kontekstdiagrammid (n > 0). A-0 diagramm (A miinus null): eritüüpi (kontekstuaalne) IDEF0 diagramm, mis koosneb ühest plokist, mis kirjeldab tipptaseme funktsiooni, selle sisendeid, väljundeid, juhtelemente ja mehhanisme koos avaldustega selle eesmärgi kohta. mudel ja vaatenurk, millest see mudel on konstrueeritud.
Lapse diagramm: diagramm, mis kirjeldab üksikasjalikult vanema (lapse) plokki.
Ülemdiagramm: diagramm, mis sisaldab emaplokki.
Sõlme viide: kood, mis on määratud diagrammile selle tuvastamiseks ja selle asukoha määramiseks mudelihierarhias; moodustatud lühendatud mudelinimest ja diagrammi sõlme numbrist koos lisalaienditega.
Diagrammi sõlme number: diagrammi sõlme viite osa, mis vastab põhiploki numbrile.

Lagunemine

Kontekstidiagrammis A–0 kujutab modelleerimisobjekti üks plokk piirnooltega, mis näitavad modelleerimisobjekti seost
keskkonnaga.

Ülataseme kontekstidiagrammis kujutatud üksiku funktsiooni saab laotada peamisteks alamfunktsioonideks, luues alamdiagrammid, mis sisaldavad lähteplokkide üksikasju.

Blokeeri

Plokk: ristkülik, mis sisaldab nime ja numbrit ning mida kasutatakse funktsiooni kirjeldamiseks.

Ploki number: ploki alumisse paremasse nurka paigutatud arv (0–6), mis identifitseerib diagrammil ploki üheselt.

Ploki nimi: tegusõna või verbifraas, mis on paigutatud ploki sisse ja mis kirjeldab modelleeritavat funktsiooni.

Lapsplokk: plokk lapse (lapse) diagrammil.

Vanemplokk: plokk, mis on üksikasjalikult kirjeldatud alamdiagrammiga.

Plokkide jaoks on kehtestatud järgmised süntaksireeglid:

Plokkide suurused peavad olema piisavalt suured, et sisaldada ploki nime ja numbrit.

Plokid peaksid olema ristkülikukujulised, paremate nurkadega;

Plokid tuleb tõmmata pidevate joontega.

Sõlm

Sõlm: plokk, mis toodab alamplokke; vanemplokk.

Sõlme number: kood, mis on määratud plokile ja määratleb selle asukoha mudelihierarhias; saab kasutada üksikasjaliku viiteväljendina.

Sõlmepuu: IDEF0 mudeli vanem- ja alamsõlmede vaheliste suhete kujutamine puugraafiku kujul. Sellel on sama tähendus ja sisu kui sõlmede loendil.

Sõlmede loend: sageli sammude kaupa loend, mis näitab IDEF0 mudeli sõlmpunkte järjestatud viisil. Sellel on sama tähendus ja sisu kui sõlmepuul.

Nool

Nool: ühest või mitmest segmendist koosnev suunatud joon, mis modelleerib avatud kanalit või kanalit, mis kannab andmeid või materiaalseid objekte allikast (noole alguspunkt) tarbijani (otsa lõpp-punkt).Sisendnool: noolte klass, mis esindavad IDEF0 ploki sisendit, st andmeid või materiaalseid objekte, mille funktsioon teisendab väljundiks. Sisendnooled on ühendatud IDEF0 ploki vasakule küljele.Väljundnool: noolte klass, mis kuvavad IDEF0 ploki väljundit, st funktsiooni poolt toodetud andmeid või materiaalseid objekte. Väljundnooled on ühendatud IDEF0 ploki paremale küljele.Mehhanisminool: noolte klass, mis kuvab IDEF0 mehhanisme, st funktsiooni täitmiseks kasutatavaid vahendeid; sisaldab spetsiaalset helistamisnoole ümbrist. Mehhanismide nooled on ühendatud IDEF0 ploki alumise küljega.Juhtnool: noolte klass, mis IDEF0-s kuvab, st tingimusi, mille korral ploki väljund on õige. Juhtelementidena modelleeritud andmeid või objekte saab teisendada funktsiooniga, mis toodab vastava väljundi. Juhtnooled on seotud IDEF0 ploki ülemise küljega.

Noolesilt: nimisõna või fraas nimisõnast, mis on seotud noole või noolesegmendiga ja määratleb selle tähenduse.

Sisemine nool: sisend-, juht- või väljundnool, mille otsad ühendavad allika ja tarbija, mis on sama skeemi plokid. Erineb piirinoolest.Piirinool: nool, mille üks ots on ühendatud allika või valamuga ja teine ​​ei ole diagrammil ühegi plokiga ühendatud. Kuvab diagrammi ühenduse teiste süsteemi plokkidega ja erineb sisemisest noolest.Noolelõik: joonelõik, mis algab või lõpeb ploki küljel, haru- või liitmispunktis või piiril (noole mitteseotud ots).Hargnemine: noole jagamine kaheks või enamaks segmendiks.Ühenda: kahe või enama noole lõigu ühendamine üheks segmendiks.Sidumine/lahtisidumine: noolte väärtuste ühendamine liitväärtuseks (komplekteerimine) või eraldavate nooleväärtuste (lahtisidumine), mida väljendatakse liitmise või hargnemise noolte süntaksiga.Tilde: väike katkendlik (laineline) joon, mida kasutatakse sildi ühendamiseks konkreetse noolesegmendiga või mudelimärkuse ühendamiseks diagrammi komponendiga.ICOM-kood: kood, mis tagab, et alamdiagrammi piirinooled vastavad põhiploki nooltele; kasutatakse viidete jaoks (lühend ICOM tähistab sisend - sisend, juhtimine - haldus, väljund - väljund, mehhanism - mehhanism).

Plokkide ja noolte semantika

Funktsiooniploki igal küljel on ploki/noolega suhtlemise osas standardne eesmärk. Ploki külg, mille külge nool on kinnitatud, määrab omakorda unikaalselt selle rolli.

Nooltele on kehtestatud järgmised süntaksireeglid:- Katkised nooled muudavad suunda ainult 90° nurga all;- Nooled tuleb tõmmata pidevate joontena.
Võite kasutada erineva paksusega jooni; - Nooled võivad koosneda ainult vertikaalsetest või horisontaalsetest segmentidest.
Diagonaalselt suunatud lõigud ei ole lubatud; - noolte otsad peavad puudutama funktsiooniploki välispiiri,
kuid ei tohi seda ületada;

Nooled peavad ploki külgedelt ühinema.
Ühendused nurkades ei ole lubatud.

Pilt on väärt tuhat sõna

Rahvatarkus

Sageli on minu töös vajadus mitte ainult uurida ja lahendada konkreetset probleemi, vaid selgitada välja selle asukoht ettevõtte üldises tegevusmudelis. Ei piisa mõistmisest, et teatud üksus ei tööta õigesti, on oluline mõista, kuidas see teistega suhtleb. Vastasel juhul on võimatu tuvastada kõiki olemasolevaid probleeme ja valida probleemi lahendamiseks optimaalset meetodit. Ja selleks peate uurima ettevõtte tööd ja koostama selle funktsionaalse mudeli.

Loomulikult peaks teoreetiliselt juhil olema ettevõtte töö funktsionaalne mudel ja pole vahet, kas räägime lao või IT-süsteemi töö korraldamisest müügivihtest rakenduseni. Kuid tegelikkuses ei selgu see peaaegu kunagi ja seetõttu koostan kliendi probleemile uurimise ja lahenduse otsimise käigus ka iseseisvalt funktsionaalse mudeli ettevõtte tööst või teatud protsessist (funktsioonist).

Paar sõna graafika eeliste kohta

Nagu teate, on IDEF0 funktsionaalsed mudelid alati graafilised diagrammid. Neil on oma omadused ja kompositsioonireeglid. Sellest räägime veidi hiljem. Nüüd tooksin paar näidet graafika efektiivsusest. Miks ma sellele keskendun? Tõenäoliselt arvasid paljud inimesed pärast minu väidet ettevõtte töö funktsionaalse mudeli vajaduse kohta, et seda kõike pole vaja, nad võisid sõnadega selgitada, kuidas see või teine ​​funktsioon ettevõttes töötab. Sellest tahan ma rääkida.

Alustame lühikese ekskursiooniga ajalukku. Tuleme tagasi kaugesse aastasse 1877, Vene-Türgi sõja ajal. Siis kasutas printer Sytin esimest korda sõjaliste operatsioonide kirjeldamiseks graafikat. Nüüd on see kõik meile tuttav mistahes lahingut kirjeldades, meie silme ette kerkivad nooltega kaardid, mis näitavad selgelt lahingu kulgu. Ja neil päevil kirjeldati sõjalisi tegevusi sõnadega. Iga lahingu jaoks on palju, palju sõnu. Ja lõpuks oli väga raske aru saada, mis toimub.

Seetõttu oli Sytini idee tõeliselt revolutsiooniline - ta hakkas trükkima kaartide litograafilisi koopiaid, mis näitasid kindlustusi ja sõjaväeosade asukohti. Need kaardid kandsid nimetust „Ajalehelugejatele. Toetus." Idee osutus nii aktuaalseks, et “Kasu” esimene trükk müüdi koheselt läbi. Ja siis oli selliste rakenduste järele suur nõudlus. Põhjus on ilmne. Graafika aitas mõista seda, mida oli peaaegu võimatu mõista ainult sõnadega.

Sarnase näite verbaalsete kirjelduste abitusest võin tuua ka enda praktikast. Üks mu klient palus mul tõesti võtta tema ettevõttele ERP-süsteemi juurutamine. Kui küsisin, kas neil on mingeid tehnilisi näitajaid, sain vastuseks: “Jah, on. Aga see on 400 lehekülge. Samas kurtis klient väga, et minu kolleegid, kellega ta varem ühendust võttis, kas keeldusid projektist üldse või pakkusid selgelt paisutatud hindu. Pärast seda, kui nägin, et tehnilises kirjelduses oli tegelikult 400 lehekülge ja see koosnes ainult tekstikirjeldusest, sain aru arendajate käitumise põhjustest. Sellise tekstimahu lugemine, sellesse süvenemine, kõikidest nüanssidest aru saamine ainuüksi ülesande mõistmiseks ja hinna nimetamiseks on tõesti väga raske.

Pakkusin sellele kliendile alternatiivse võimaluse - kirjeldada kõike, mis võimalik, graafiliselt märgete kujul. Näitas talle modellitöö näiteid. Seetõttu mõtlevad nad nüüd oma soovid ja tehniliste näitajate kujunduse ümber.

Tean ka palju teisi näiteid, kus äriprotsesside graafiline modelleerimine aitas nii minu kolleege, ärikonsultante ja -arendajaid kui ka ärimehi endid.

Miks on see minu töö jaoks oluline?

Minu töö hõlmab alati olemasolevas süsteemis muudatuste tegemist. Ja selleks, et teha muudatusi ja saada soovitud tulemust, tuleb uurida, mis on juba olemas. Ja pole vahet, mida me täpselt teeme - CRM-süsteemi nullist seadistamine või installimine, tõhusa ERP-süsteemi loomine, erinevate süsteemide integreerimine, et suurendada töö automatiseerimist üldiselt. Igal juhul peate esmalt saama aimu olemasolevast tööskeemist ja alles pärast seda saate teha ettepanekuid muudatusteks ja mõelda läbi probleemi lahendamise võimalused.

Pärast asjade hetkeseisuga tutvumist koostan nagu iga teine ​​​​kolmanda osa spetsialist ärilise ettepaneku, milles avaldan võimalikult üksikasjalikult oma nägemuse hetkeolukorrast ja toimingutest, mida tuleb teha probleemi lahendamiseks ja loomulikult oodatud tulemuseks.

Sellised tööülevaate aruanded on mahukad ja võtavad rohkem kui ühe lehekülje, mis ühest küljest on vajalik, kuid teisalt raskendab tajumist. Alguses, nagu paljud teised, arvasin, et mahukad aruanded on head, sest inimene maksab töö eest ja sa pead talle andma võimalikult üksikasjalikku teavet.

Levinud vead

Funktsionaalne modelleerimine toimub mitmesuguste vahenditega, sealhulgas ka modelleerimiseks mitte ette nähtud vahenditega. Viimasel juhul pole vigade kontrollimist ja standardpiiranguid. Nähtavuse suurendamise soov ja kogemuste puudumine lõppevad sageli vigadega.

Erinevate värvide kasutamine

Kõik diagrammi elemendid on võrdselt olulised. Funktsionaalses modelleerimises ei ole enam ega vähem olulisi elemente. Nende kadumine põhjustab protsessi katkemist ja tootmisdefekte.

Sageli paberil või erinevates programmides modelleerides püüavad kasutajad erinevate värvide abil nähtavust suurendada. See on üks levinumaid vigu. Tegelikult lisab mitmevärviliste noolte ja klotside kasutamine ainult täiendavat segadust ja moonutab ka diagrammi tajumist.

Teie mudel peaks olema must-valgelt loetav ilma täiendavate värviskeemideta. See lähenemine aitab samal ajal vältida arusaamatusi ja distsiplineerib mudeli loojat, mille tulemuseks on mudeli loetavus ja kirjaoskus.

Liiga palju plokke

Mudeli koostamisel püüavad nad sageli ühel lehel kuvada kõik ettevõtte töö nüansid koos kõigi detailidega. Tulemuseks on väga suur hulk plokke suure hulga juhtnooltega. Sel juhul loetavus kaob.

Parim variant on probleemi mõistmiseks piisavalt detailne ja ei midagi enamat. Iga osakonna või isegi töötaja töö üksikasjalikud üksikasjad võivad ilmneda konkreetse protsessi üksikasjaliku vaate valimisel. Ja selline struktuur luuakse ainult siis, kui see on tõesti tööks või otsustamiseks vajalik.

Konstruktsiooni rikkumine kohanduste tegemisel

Olge ettevaatlik, et ei tekiks segadust ega protsesse ilma sissetulevate, väljaminevate või muude oluliste elementideta. Näiteks kui ülaltoodud näites pean vajalikuks vaatenurga nihutada copywriterile, eemaldan autori skeemist. Ja siis muutuvad tarbetuks juhtelemendid "autori kogemus ja kolmanda osapoole allikad", samuti avaldamisplaan. Autor ju kasutab neid. Copywriter töötab helifailiga. Ja kui need jäävad üldisesse skeemi, siis üksikasjalikult viivad need ebaselgesse suunda ja tekitavad segadust.

Samuti, kui otsustan ploki lisada, on oluline veenduda, et sellel on ka kõik nõutavad atribuudid. Ettevaatlikkus on siin väga oluline, kuna keerukate äriprotsesside modelleerimisel võivad muudatused ühes mudeli osas kaasa tuua muutusi teises. Need tuleb kindlasti kaasata.

Juhtelementide ja plokkide nimetamise reeglid

Oluline on meeles pidada lihtsat reeglit: juhtnooli nimetatakse nimisõnadeks, plokke tegusõnadeks. See on IDEF0 standardis aktsepteeritud ning see lähenemine aitab vältida segadust ja vigu.

Kõige sagedamini tehakse vigu plokkide nimetamisel. Näiteks kirjutavad nad teksti "Loo artikkel" asemel "Artikli loomine". Selle lähenemisviisi plokid on tegevused ja seetõttu peaksid need alati olema tegusõnad.

IDEF0 kasutamise eelised

• Kõige esimene eelis on ilmne – nähtavus. Hakkate ise mõistma, kuidas see või teine ​​süsteem töötab, ja saate ka selgelt selgitada, kus on selles süsteemis "õhukesed laigud" ja kuidas teie lahendused aitavad neist lahti saada.
• Vastastikune mõistmine ja lahknevuste puudumine. Funktsionaalse mudeli abil ettevõtte tööd arutades on teil visuaalsed ja intuitiivsed juhtelementidega ülesannete plokid. Lisaks hõlmab funktsionaalne modelleerimine vajaduse korral sõnastiku loomist, milles avalikustatakse kokkulepped ja terminid. Seetõttu räägite probleemi arutamisel sama keelt nii teie kui ka klient, juht ja teised töötajad.
• Mudeli loomise lihtsus ja suur kiirus. Muidugi pole modellinduse õppimine nii lihtne, kui tundub. Diagramm on ju sisuliselt ülitihe info esitlus, millest on väga hea aru saada, kuid sellise esitluse rakendamine nõuab erilist lähenemist. Analüütiku aju toimib sel juhul ühelt poolt väga võimsa pressina ja teiselt poolt filtrina. Kuid kogemustega muutub see protsess väga kiireks. Selle tulemusena saate tööriista, mis aitab teil ise aru saada, mis konkreetses süsteemis toimub, ning lühikese ajaga loodud visuaalse abivahendi abil illustreerida olulisi punkte kolleegidele või klientidele.
• Distsipliin ja ilma vigadeta. IDEF0 standard näeb ette ranged raamistikud ja reeglid. Selline lähenemine loob distsipliini ning harjumus tegutseda standardi piires aitab vältida tähelepanematusest tulenevaid vigu. Kõik standardi rikkumised on koheselt märgatavad.

Mis on IDEF0 kasutamise raskus

Oluline on mõista, et ainult kõige lihtsamatel juhtudel loovad kaks ärianalüütikut ettevõtte töö kirjeldamiseks täpselt samad funktsionaalsed mudelid. Iga mudel peegeldab analüütiku kogemust, tema kirjeldatava ettevõtte mõistmise sügavust ja mingil moel ka tema isiklikku seisukohta selle ettevõtte kohta. Need. inimene arendab ärimudelit juhi vaatenurgast, justkui oleks ta juht.

Samas usun, et ärianalüütik pole just elukutse, ärianalüütikaga tegeleb iga ärijuht või mõne süsteemi arendaja, kes äri analüüsib ja püüab üles ehitada võimalikult efektiivset süsteemi. Just nendele inimestele ja nendel eesmärkidel on IDEF0 tööriist loodud.

Seetõttu on funktsionaalse "nagu on" ärimudeli koostamisel väga oluline pidevalt ettevõtte juhiga nõu pidada, et mitte teha vigu, mis lagunemisetappides automaatselt kaasa toovad vigu. Samuti võidakse järgmistel etappidel nõuda täiendavaid kooskõlastusi osakonnajuhatajatelt ja töötajatelt. Ainult siis, kui teie "nagu on" funktsionaalne mudel peegeldab tõeliselt asjade tegelikku seisu, saate teha muudatusi ja ettepanekuid. Ja sellises töös kvaliteetsete tulemuste saavutamiseks on kõigepealt vaja praktilisi kogemusi ja teadmisi konkreetset tüüpi ettevõtte omadustest.

Veel artikleid sellel teemal.

IDEF0 standardiga tutvumiseks peate selle kohta teadma järgmist:

1. Millist tüüpi mudeleid seda standardit kasutatakse?
2. Milliseid graafilise keele elemente sisaldab standardi tähistus ja millised nõuded diagrammide kujundamiseks on standardis olemas.
3. Milliseid äriprotsesside modelleerimise põhimõtteid on standardis kasutatud (dekomponeerimise printsiip, keerukuse piiramise printsiip, tunnelimise printsiip).
4. Kuidas hinnata koostatud diagramme nende ülekoormatuse ja tasakaalu osas?

IDEF0 loomiseks kasutatud funktsionaalne mudel, süsteemi ülesehituse ja funktsioonide, samuti nende funktsioonide poolt transformeeritud infovoogude ja materiaalsete objektide kuvamine.

IDEF0 metoodika erineb veidi klassikalisest DFD äriprotsesside kirjeldamise skeemist. Peamine erinevus seisneb tööpanuste klassifikatsioonis.

Töö sisendite ja väljundite klassifikatsioon

Standard pakub järgmisi töösisendite tüüpe:

• Sissepääs. Sisestab vasakpoolse töö ja näitab äriprotsessis muunduvaid info- ja materjalivooge.
• Kontroll. See siseneb teosesse ülevalt ja näitab materjali- ja infovooge, mis protsessi käigus ei muundu, kuid on vajalikud selle elluviimiseks.
• mehhanism. Siseneb töösse alt ja näitab inimesi, tehnilisi vahendeid, infosüsteeme jms, mille abil äriprotsess realiseeritakse.
• tulemused väljuge parempoolsest blokist.

Diagrammi põhielemendid:

IDEF0 graafilise keele, mille süntaks ja semantika on defineeritud absoluutse rangusega, aluse moodustavad plokid ja neid ühendavad nooled, mis moodustavad detailsete diagrammide hierarhia.

Element	Graafiline ekraan ja tähendus	Registreerimisnõuded
Funktsionaalne blokk	Kujutatud ristkülikuna. Esindavad funktsioone, mis on määratletud kui tegevus, protsess, toiming, tegevus või transformatsioon.	1. Peab olema ainulaadne identifitseerimisnumber paremas alanurgas; 2. Pealkiri peab olema verbaalses meeleolus.
Liideskaar (nool, kaar)	Kujutatud ühesuunalise noolena. Esitage funktsioonidega seotud andmeid või materiaalseid objekte.	1. Peab olema kordumatu nimi. 2. Nimi peab olema nimisõna vorm. 3.Ainult funktsiooniplokid võivad olla kaare algus ja lõpp. 4. Allikas saab olla ainult ploki väljundi pool ja vastuvõtja võib olla ükskõik milline kolmest ülejäänud.

IDEF0 – mudel:

Mudel sisaldab järgmisi dokumente, mis viitavad üksteisele:

• Graafilised diagrammid on IDEF0 mudeli põhikomponent, mis graafiliselt, kasutades plokke ja nooli ning nende ühendusi, kuvab informatsiooni modelleeritava süsteemi kohta. Plokid esindavad põhifunktsioone. Neid funktsioone saab osadeks jaotada (lagundada) ja esitada üksikasjalikumate diagrammidena. Lagunemisprotsess jätkub seni, kuni objekti kirjeldatakse detailsuse tasemel, mis on vajalik konkreetse projekti eesmärkide saavutamiseks.
• Tekst;
• Sõnastik— Diagrammi iga elemendi jaoks luuakse ja säilitatakse definitsioonide, märksõnade ja selgituste kogum, mis iseloomustavad objekti, mida see element esindab. Seda komplekti nimetatakse sõnastikuks ja see kirjeldab antud elemendi olemust. Sõnastik täiendab harmooniliselt visuaalset graafilist keelt, pakkudes diagramme vajaliku lisateabega.

Näiteks juhtimisliidese kaare "maksekorraldus" jaoks võib sõnastik sisaldada kaarele vastava dokumendi väljade loendit, nõutavat viisade komplekti jne.

Dekompositsiooni põhimõte äriprotsessi mudeli ehitamisel

1. Konteksti diagramm: eesmärk ja vaatenurk

Äriprotsesside modelleerimine algab kontekstdiagrammist. Seda diagrammi nimetatakse A–0 (A miinus null). Sellel on süsteem kujutatud ühe plokina ja kaarena, mis kujutavad süsteemi keskkonda. Diagrammi abil näete simuleeritud süsteemi koostoimet väliskeskkonnaga, kõiki selle sisendeid ja väljundeid. Diagramm A–0 määrab modelleerimisala ja piirid.

Kontekstiskeemi selgitav tekst peab näitama sihtmärk joonistamine ja salvestamine vaatepunktist. Vaatepunkt määrab detailsuse taseme, mudeli arendussuuna ja võimaldab mudelit maha laadida. Seega võite modelleerimisel keelduda üksikasjalikult ja üksikute elementide uurimisest, mis pole vajalikud, lähtudes süsteemi valitud vaatepunktist.

2. Detaileerimine

Plokk, mis esindab kogu süsteemi, on seejärel üksikasjalikult kirjeldatud teises diagrammis.

Lisaks saab diagrammi iga funktsiooni üksikasjalikult kirjeldada alamdiagrammis. Iga funktsioon on modelleeritud eraldi plokiga. Iga vanemplokki kirjeldatakse üksikasjalikult madalama taseme alamdiagrammiga. See jätkub seni, kuni saadakse struktuur, mis võimaldab vastata modelleerimiseesmärgis sõnastatud küsimustele.

Mudeli struktuurse terviklikkuse saavutamiseks kasutatakse järgmisi reegleid:

• Kõik sellesse plokki sisenevad või sealt väljuvad liidesekaared salvestatakse alamdiagrammile.
• Plokkide nummerdamisel näitab ristküliku alumises paremas nurgas olev number diagrammil ploki enda unikaalset seerianumbrit ja paremas nurgas olev tähistus näitab selle ploki alamdiagrammi numbrit.

Tunneldamise põhimõte

Tihti tuleb ette juhtumeid, kus hierarhia teatud tasemest madalamal alamdiagrammides ei ole mõtet üksikuid nooli jätkuvalt käsitleda või vastupidi – üksikutel plokkidel ei ole teatud tasemest kõrgemal praktilist tähendust. Teisest küljest on mõnikord vaja vabaneda üksikutest "kontseptuaalsetest" nooltest ja mitte täpsustada neid teatud tasemest kaugemale.

Selliste probleemide lahendamiseks pakub IDEF0 standard kontseptsiooni tunneldamine. Kahe noole alguses oleva sulgu „tunneli“ tähis näitab, et nool ei pärinenud funktsionaalsest vanemplokist ja ilmub („tunnelist“) ainult sellel diagrammil. Sama tähistus noole otsa ümber vastuvõtjaploki vahetus läheduses tähendab omakorda asjaolu, et selle ploki alamdiagrammis seda noolt ei kuvata ja seda ei võeta arvesse.

Keerukuse piiramise põhimõte

Mudelite ülekoormuse piiramiseks ja nende arusaadavuse hõlbustamiseks kehtestab standard asjakohased keerukuspiirangud:

• piirates diagrammi funktsionaalplokkide arvu kolmele kuni kuuele. Ülemine piir (kuus) sunnib kujundajat kasutama keeruliste objektide kirjeldamisel hierarhiaid ning alumine piir (kolm) tagab, et vastaval diagrammil on piisavalt detailsust, et selle loomist õigustada;
• ühele funktsionaalplokile sobivate (ühest funktsionaalplokist väljuvate) liidesekaare arvu piiramine neljaga.

Loomulikult pole neid piiranguid vaja rangelt järgida, kuid nagu kogemus näitab, on need reaalses töös väga praktilised.

Kvantitatiivse diagrammi analüüs: saldo suhte ja nime hindamine

Kvantitatiivset analüüsi kasutatakse diagrammi analüüsimiseks selle ülekoormatuse ja tajumisraskuse seisukohalt. Analüüsiks kasutatakse järgmisi näitajaid:

• plokkide arv diagrammil - N;
• diagrammi lagunemise tase - L;
• diagrammi tasakaal - IN;
• plokiga ühendavate noolte arv - A.

Tasakaalutegur

Tuleb püüda tagada, et madalama taseme diagrammidel oleks plokkide arv väiksem kui põhidiagrammide plokkide arv.

Samuti peavad diagrammid olema tasakaalus. See tähendab, et sama diagrammi sees ei tohiks tekkida olukorda, kus sissetulevaid nooli ja juhtnooli on oluliselt rohkem kui väljaminevaid.

Tuleb märkida, et seda soovitust ei pruugi tootmisprotsesse kirjeldavate mudelite puhul järgida. Näiteks monteerimisprotseduuri kirjeldamisel võib plokk sisaldada palju nooli, mis kirjeldavad toote komponente, ja ühte noolt, mis väljub valmistootest.

Tutvustame diagrammi tasakaalutegurit:

On vaja pingutada K oli diagrammi jaoks minimaalne ja vähenes lagunemise taseme tõustes.

Nime hinnang

Lisaks diagrammi graafiliste elementide analüüsimisele on vaja arvestada plokkide nimedega. Nimede hindamiseks koostatakse modelleeritava süsteemi elementaarsete (triviaalsete) funktsioonide sõnastik. Tegelikult peaks see sõnastik sisaldama diagrammi lagunemise madalama taseme funktsioone.

Näiteks andmebaasimudeli puhul võivad funktsioonid “leida kirje” ja “lisa kirje andmebaasi” olla elementaarsed, samas kui funktsioon “kasutaja registreerimine” nõuab täiendavat kirjeldamist.

Pärast sõnastiku moodustamist ja süsteemiskeemide paketi koostamist on vaja arvestada mudeli madalama tasemega. Kui diagrammiplokkide nimede ja sõnaraamatu sõnade vahel on vasteid, tähendab see, et on saavutatud piisav lagunemistase.

Seda kriteeriumi kvantitatiivselt peegeldava koefitsiendi võib kirjutada järgmiselt:

L*C

— mudeli taseme ja sõnastiku plokkide nimede ja sõnade vaheliste vastete arvu korrutis. Mida madalam on mudeli tase (suurem L), seda väärtuslikumad on vasted.

6.2. SADT metoodika (IDEF0) eesmärk ja koostis

SADT metoodika (Structured Analysis and Design Technique – struktuurianalüüsi ja disaini metoodika) on meetodite, reeglite ja protseduuride kogum, mis on loodud süsteemi funktsionaalse mudeli koostamiseks.

Selle metoodika väljatöötamine algas Douglas Rossiga (USA) 60ndate keskel. XX sajand Sellest ajast alates on SofTech, Inc. süsteemianalüütikud. täiustas SADT-d ja kasutas seda paljude probleemide lahendamiseks. Telefonitarkvara, diagnostika, pikaajaline ja strateegiline planeerimine, arvutipõhine tootmine ja projekteerimine, arvutisüsteemide konfigureerimine, personalikoolitus, finants- ja logistikajuhtimine on mõned valdkonnad, kus SADT-d saab tõhusalt rakendada. Valdkondade lai valik viitab SADT metoodika mitmekülgsusele ja võimsusele. USA kaitseministeeriumi integreeritud arvutipõhise tootmise (ICAM) programm tunnistas SADT kasulikkust. See tõi kaasa selle osa avaldamise 1981. aastal, nn IDEF0 (Icam DEFinition), mis on tarkvaraarenduse föderaalne standard. Selle nime all hakkasid SADT-d kasutama tuhanded sõjaväe- ja tööstusorganisatsioonide spetsialistid. IDEF0 standardi viimane väljaanne ilmus 1993. aasta detsembris. National Institute of Standards and Technology (NIST).

See metoodika konkureerib infosüsteemi funktsionaalse aspekti kirjeldamisel andmevoo-orienteeritud (DFD) meetoditega. Seevastu IDEF0 võimaldab:

Kirjeldage mis tahes süsteeme, mitte ainult infosüsteeme (DFD on mõeldud tarkvara kirjeldamiseks);

Enne lõplike nõuete määramist koostage süsteemi ja selle väliskeskkonna kirjeldus. Teisisõnu, seda metoodikat kasutades saate süsteemi järk-järgult üles ehitada ja analüüsida isegi siis, kui selle rakendamist on veel raske ette kujutada.

Seega saab IDEF0 kasutada paljude süsteemide ehitamise algfaasis. Samas saab selle abil analüüsida olemasolevate süsteemide funktsioone ja töötada välja lahendusi nende täiustamiseks.

IDEF0 metoodika aluseks on graafiline protsesse kirjeldav keel. IDEF0 tähistusega mudel on hierarhiliselt järjestatud ja omavahel seotud diagrammide kogum. Iga diagramm on süsteemi kirjeldusüksus ja asub eraldi lehel.

Mudel (NAGU ON, TO-BE või PEAKS OLEMA) võib sisaldada 4 tüüpi diagramme [ , ]:

Konteksti diagramm;

Lagunemisdiagrammid;

Sõlmepuu diagrammid;

Diagrammid ainult kokkupuute jaoks (FEO).

Konteksti diagramm (tipptaseme diagramm), olles diagrammide puustruktuuri tipp, näitab süsteemi eesmärki (põhifunktsiooni) ja selle vastasmõju väliskeskkonnaga. Igal mudelil võib olla ainult üks kontekstdiagramm. Pärast põhifunktsiooni kirjeldamist viiakse läbi funktsionaalne lagunemine, st määratakse põhifunktsioonid.

Järgmisena jagatakse funktsioonid alamfunktsioonideks ja nii edasi, kuni saavutatakse uuritava süsteemi nõutav detailsusaste. Nimetatakse diagramme, mis kirjeldavad iga sellist süsteemi fragmenti lagunemise diagrammid . Pärast iga lagunemissessiooni viiakse läbi eksamisessioonid - aineeksperdid näitavad reaalsete protsesside vastavust loodud diagrammidele. Leitud ebakõlad kõrvaldatakse, misjärel algab protsesside edasine täpsustamine.

Sõlmepuu diagramm näitab funktsioonide (tööde) hierarhilist sõltuvust, kuid mitte nendevahelisi seoseid. Neid võib olla mitu, kuna puu saab ehitada suvalisele sügavusele ja suvalisest sõlmest.

Särituse diagrammid on konstrueeritud illustreerima mudeli üksikuid fragmente, et kuvada alternatiivne vaatenurk süsteemis toimuvatele protsessidele (näiteks organisatsiooni juhtimise seisukohalt).

6.3. IDEF0 graafilise märgistuse elemendid

IDEF0 metoodika on leidnud laialdast heakskiitu ja rakendust, peamiselt tänu lihtsale graafilisele tähistusele, mida mudeli koostamisel kasutatakse. Mudeli põhikomponendid on diagrammid. Need kuvavad süsteemifunktsioone ristkülikute kujul, samuti nende ja väliskeskkonna vahelisi ühendusi noolte kaudu. Kasutades ainult kahte graafilist primitiivi (ristkülik ja nool), saate kiiresti selgitada IDEF0 diagrammide koostamise reegleid ja põhimõtteid inimestele, kes seda metoodikat ei tunne. See eelis võimaldab ühendada ja aktiveerida kliendi tegevusi äriprotsesside kirjeldamisel formaalse ja visuaalse graafilise keele abil.

Järgmisel joonisel on näidatud IDEF0 graafilise tähistuse peamised elemendid.

Riis. 6.1. IDEF0 graafilise märgistuse elemendid

Ristkülik kujutab töö (protsess, tegevus, funktsioon või ülesanne) , millel on kindel eesmärk ja mis viib mingi lõpptulemuseni. Töö nimi peaks väljendama tegevust (näiteks “Detaili valmistamine”, “Lubatud kiiruste arvutamine”, “Töökeskuse nr 3 akti koostamine”).

Teoste vastasmõju enda ja välismaailma vahel on kirjeldatud noolte kujul. IDEF0 eristab 5 tüüpi nooli :

- sissepääs (inglise sisend) - materjal või teave, mida kasutatakse ja transformeeritakse tööga tulemuse (väljundi) saamiseks. Sisend vastab küsimusele "Mida töödeldakse?" Sisend võib olla kas materiaalne objekt (tooraine, osa, eksamikaart) või selline, millel puuduvad selged füüsilised kontuurid (andmebaasi päring, õpetaja küsimus). Lubatud on, et tööl ei tohi olla ühte sisenemise noolt. Sisenenooled joonistatakse alati töö vasakusse serva sisenedes;

- kontroll (inglise control) – tööd suunavad kontroll-, reguleerivad ja normandmed. Juhtkond vastab küsimusele "Millega kooskõlas tööd tehakse?" Juhtimine mõjutab tööd, kuid ei muutu sellest, s.t. toimib piiranguna. Juhtkond võib sisaldada reegleid, standardeid, eeskirju, hindu või suulisi juhiseid. Töö ülemisse serva sisenedes joonistatakse juhtnooled. Kui diagrammi koostamisel tekib küsimus, kuidas õigesti noolt ülalt või vasakule joonistada, siis on soovitatav see joonistada sisendina (nool vasakul);

- väljuda (ingliskeelne väljund) – materjal või teave, mis esindab töö tulemust. Väljund vastab küsimusele "Mis on töö tulemus?" Väljundiks võib olla kas materiaalne objekt (detail, auto, maksedokumendid, väljavõte) või immateriaalne objekt (andmete proovivõtt andmebaasist, küsimusele vastamine, suulised juhised). Väljapääsunooled on joonistatud, mis väljuvad töö paremast servast;

- mehhanism (inglise mehhanism) – ressursid, mis töö ära teevad. Mehhanism vastab küsimusele "Kes või mille kaudu tööd teeb?" Mehhanism võib olla ettevõtte personal, õpilane, masin, varustus või programm. Mehhanismi nooled on joonistatud sisenedes töö alumisse serva;

- helistama (Inglise kõne) - nool näitab, et osa töid tehakse väljaspool kõnealust plokki. Töö alumisest servast väljuvad väljapääsunooled.

6.4. Töökohtade vaheliste seoste tüübid

Pärast funktsioonide koostise ja nendevaheliste seoste kindlaksmääramist tekib küsimus nende õigest koostisest (kombinatsioonist) mooduliteks (alamsüsteemideks). See tähendab, et iga üksikfunktsioon peab lahendama ühe rangelt määratletud ülesande. Vastasel juhul on vajalik funktsioonide edasine lagunemine või eraldamine.

Funktsioonide kombineerimisel alamsüsteemideks tuleb püüda tagada, et sisemine ühenduvus (moodulisiseste funktsioonide vahel) oleks võimalikult tugev ning väline ühenduvus (erinevates moodulites sisalduvate funktsioonide vahel) võimalikult nõrk. Lähtudes metoodika seoste semantikast, tutvustame funktsioonide (tööde) vaheliste seoste klassifikatsiooni. See klassifikatsioon on laiendus. Sidemete tüübid on toodud nende tähtsuse (sidumistugevuse) kahanevas järjekorras. Toodud näidetes tõstavad paksud jooned esile funktsioonid, mille vahel on vaadeldav ühenduse tüüp.

1. Hierarhiline seos (suhe "osa" - "tervik") toimub funktsiooni ja alamfunktsioonide vahel, millest see koosneb.

Riis. 6.2. Hierarhiline suhe

2. Reguleeriv (kontroll, alluv) ühendus peegeldab ühe funktsiooni sõltuvust teisest, kui ühe töö väljund on suunatud teise kontrollimiseks. Funktsiooni, millest juhtimine pärineb, tuleks pidada reguleerivaks või kontrollivaks ning funktsiooni, millesse see kuulub, tuleks pidada alluvaks. Eristama otsesuhtlus juhtkonnaga , kui juhtimine viiakse kõrgemalt töölt üle madalamale (joon. 6.3), ja juhtkonna tagasiside kui juhtimine viiakse madalamalt kõrgemale (joon. 6.4).

3. Funktsionaalne (tehnoloogiline) ühendus tekib siis, kui ühe funktsiooni väljund on järgmise funktsiooni sisend. Materiaalsete objektide voolu seisukohalt näitab see seos nende objektide töötlemise tehnoloogiat (tööde järjekorda). Eristama otsene sisendühendus , kui väljund viiakse kõrgemalt operatsioonilt madalamale (joon. 6.5), ja sisselogimise tagasiside , kui väljund edastatakse alumisest kõrgemale (joon. 6.6).

Riis. 6.5. Otsene ühendus sisendi kaudu	Riis. 6.6. Sisselogimise tagasiside

4. Tarbijasuhtlus tekib siis, kui ühe funktsiooni väljund toimib järgmise funktsiooni mehhanismina. Seega tarbib üks funktsioon teise toodetud ressursse.

Riis. 6.7. Tarbijasuhtlus

5. Loogiline ühendus mida täheldatakse loogiliselt homogeensete funktsioonide vahel. Sellised funktsioonid täidavad reeglina sama tööd, kuid erineval (alternatiivsel) viisil või kasutades erinevaid sisendandmeid (materjale).

Riis. 6.8. Loogiline ühendus

6. Kollegiaalne (metoodiline) suhtlus esineb funktsioonide vahel, mille tööalgoritmi määrab sama juht. Sellise suhtluse analoogiks on ühe osakonna töötajate (kolleegide) ühine töö, mis alluvad ülemusele, kes annab juhiseid ja korraldusi (juhtsignaale). Selline seos tekib ka siis, kui nende funktsioonide toimimise algoritmid määrab sama metoodiline tugi (SNIP, GOST, ametlikud regulatiivsed materjalid jne), mis toimib kontrollina.

Riis. 6.9. Metoodiline ühendus

7. Ressursiühendus esineb funktsioonide vahel, mis kasutavad oma tööks samu ressursse. Ressursist sõltuvaid funktsioone ei saa üldjuhul üheaegselt täita.

Riis. 6.10. Ressursiühendus

8. Infosuhtlus esineb funktsioonide vahel, mis kasutavad sisendina sama teavet.

Riis. 6.11. Infosuhtlus

9. Ajutine ühendus esineb funktsioonide vahel, mida tuleb üheaegselt täita enne või üheaegselt pärast mõnda muud funktsiooni.

Lisaks joonisel näidatud juhtudel esineb see seos ka teiste samasse funktsiooni sisenevate juhtimis-, sisendi- ja mehhanismide kombinatsioonide vahel.

Riis. 6.12. Ajutine ühendus

10. Juhuslik ühendus tekib siis, kui funktsioonide vahel on vähe spetsiifilist seost või see puudub üldse.

Riis. 6.13. Juhuslik ühendus

Ülaltoodud ühenduste tüüpidest on tugevaim hierarhiline ühendus, mis sisuliselt määrab funktsioonide ühendamise mooduliteks (alamsüsteemideks). Regulatiivsed, funktsionaalsed ja tarbijasidemed on mõnevõrra nõrgemad. Nende seostega funktsioone rakendatakse tavaliselt ühes alamsüsteemis. Loogilised, kollegiaalsed, ressursi- ja infoühendused on ühed nõrgemad. Funktsioonid, millel need on, realiseeritakse reeglina erinevates alamsüsteemides, välja arvatud loogiliselt homogeensed funktsioonid (loogilise ühendusega ühendatud funktsioonid). Ajaline suhtlus viitab funktsioonide nõrgale sõltuvusele üksteisest ja nõuab nende rakendamist eraldi moodulites.

Seega on funktsioonide kombineerimisel mooduliteks kõige soovitavam viis esimest tüüpi ühendusi. Viimase viie lingiga ühendatud funktsioone on parem rakendada eraldi moodulites.

IDEF0-l on kokkulepped (reeglid ja juhised) diagrammide loomiseks, mis on loodud mudeli lugemise ja kontrollimise hõlbustamiseks [ , ]. Mõnda neist reeglitest toetavad CASE tööriistad automaatselt, samas kui teisi tuleb jõustada käsitsi.

1. Enne mudeli ehitamist on vaja otsustada, milline süsteemi mudel(id) ehitatakse. See eeldab selle tüübi määramist AS-IS, TO-BE või PEAKS OLEMA, aga ka asukoha määramist, millest lähtudes mudelit ehitatakse. "Vaatepunkti" on kõige parem mõelda kui inimese või objekti kohta (positsiooni), kus tuleb seista, et näha süsteemi toimimas. Näiteks toidupoe toimimise mudeli ehitamisel saab võimalike kandidaatide hulgast valida müüja, kassapidaja, raamatupidaja või direktori, kelle seisukohalt süsteemi vaadeldakse. Tavaliselt valitakse üks vaatenurk, mis katab kõige täielikumalt süsteemi töö kõik nüansid, ja vajadusel koostatakse mõne dekomposiitdiagrammi jaoks FEO diagrammid, mis kuvavad alternatiivse vaatenurga.

2. Konteksti diagrammil kuvatakse üks plokk, mis näitab süsteemi eesmärki. Soovitatav on kuvada mõlemal küljel 2-4 sisenevat ja väljuvat noolt.

3. Lagunemisdiagrammide plokkide arv on soovitatav vahemikus 3–6. Kui lagunemisdiagrammil on kaks plokki, siis tavaliselt pole sellel mõtet. Kui plokke on palju, muutub diagramm üleküllastunud ja raskesti loetavaks.

4. Lagunemisdiagrammi plokid tuleks paigutada vasakult paremale ja ülalt alla. See paigutus võimaldab teil selgemalt kajastada töö loogikat ja järjestust. Lisaks on noolemarsruudid vähem segased ja neil on minimaalne ristmike arv.

5. Funktsiooni juht- ja sisendnoolte puudumine ei ole lubatud. See tähendab, et selle funktsiooni käivitamist ei kontrollita ja see võib toimuda suvalisel ajahetkel või üldse mitte kunagi.

Riis. 6.14. Funktsioon ilma juhtimise ja sisendita

Ainult juhtimisega plokki võib käsitleda kui programmi kutsumist funktsioonile (protseduurile) ilma parameetriteta. Kui plokil on sisend, siis on see samaväärne parameetritega funktsiooni kutsumisega programmis. Seega on ilma juhtimise ja sisendita plokk samaväärne funktsiooniga, mida programmis kunagi täitmiseks ei kutsuta.

Joonisel fig. 6.7–6.12, kuvades IDEF0 diagrammide fragmente, on plokid ilma sisendi ja juhtimiseta. Seda ei tohiks pidada veaks, kuna üks nendest nooltest on mõeldud seal olema.

6. Igal plokil peab olema vähemalt üks väljund.

Riis. 6.15. Funktsioon ilma väljundita

Tulemuseta tööl pole mõtet ja seda ei tohiks modelleerida. Erandiks on AS-IS mudelis kuvatavad teosed. Nende olemasolu näitab tehnoloogiliste protsesside ebaefektiivsust ja ebatäiuslikkust. TO-BE mudelis peaksid need tegevused puuduma.

7. Diagrammide koostamisel tuleks minimeerida ristmike, silmuste ja noolte pöördeid.

8. Tagasisidet ja iteratsioone (tsüklilisi toiminguid) saab kujutada tagasikaare abil. Sisendtagasiside joonistatakse “alumise” ahelana, juhttagasiside “ülemise” ahelana (vt joonised 6.4 ja 6.6).

9. Diagrammidel peab igal plokil ja noolel olema nimi. Lubatud on kasutada noolte hargnemist (lagunemist) või liitmist (kompositsiooni). See on tingitud asjaolust, et ühe tööga genereeritud samu andmeid või objekte saab kasutada mitmes teises töös korraga. Ja vastupidi, samas kohas saab kasutada samu või homogeenseid andmeid ja objekte, mis on genereeritud erinevate töökohtadega.

Riis. 6.16. Hargnevad nooled

Sel juhul on võimalik pärast hargnemist (enne liitmist) määrata noole erinevatele harudele kvalifitseerivad nimed. Kui mõni haru ei ole oksa järgi nime saanud, siis loetakse selle nimi vastavaks oksa ette kirjutatud noole nimele.

Niisiis, joonisel fig. 6.16, plokkides "Osade valmistamine" ja "Toote kokkupanek" sisalduvad juhtelemendid on selgitava tähendusega ja on üldisema "Joonised" juhtelemendi lahutamatuks osaks. Kõiki jooniseid kasutatakse kvaliteedikontrolli ploki kasutamiseks.

Diagrammile ei ole lubatud joonistada nooli, kui neid ei nimetata haru ees ja järel. Joonisel fig. 6.17 "Tüüplausete genereerimine" plokis sisalduval noolel ei ole haru ees ja järel nime, mis on viga.

Riis. 6.17. Noolte vale nimetus

10. Diagrammide koostamisel saab parema loetavuse huvides kasutada nooletunneli mehhanismi. Näiteks selleks, et mitte risustada ülemise astme (vanema) diagramme ebavajalike detailidega, paigutatakse lagunemisdiagrammides kaare algus tunnelisse.

Riis. 6.18. Nooletunneldamine

Selles näites ei kuvata uusaastapeo pidamiseks mudeli ehitamisel ülemiste tasemete diagrammidel mehhanismi "kaks telge", mida lugedes võib tekkida õiglane küsimus: "Miks on vaja kahte telge aastavahetuspidu?”

Samamoodi saate tunneldada vastupidise eesmärgiga, et vältida noole ilmumist madalama taseme diagrammidesse. Sel juhul asetatakse noole lõppu sulud. Kontekstidiagrammil (vt. joon. 6.21) on plokkis "Lubatud kiiruste määramine" sisalduv mehhanism "Track Service Engineer" tunneldatud. See otsus tehti, kuna insener on otseselt seotud kogu selle ploki lagunemisdiagrammil kuvatava tööga (vt joonis 6.22). Et seda seost mitte näidata ja lagunemisdiagrammi segamini ajada, tehti nool tunneliga.

11. Kõik plokki sisenevad ja sealt väljuvad nooled, koostades sellele lagunemisskeemi, peavad olema sellel kuvatud. Erandiks on tunneliga nooled. Jaotusdiagrammile üle kantud noolte nimed peavad ühtima tipptaseme diagrammil näidatud nimedega.

12. Kui kaks noolt jooksevad paralleelselt (algavad ühe töö samast tahust ja lõpevad teise töö samal küljel), siis võimalusel tuleks need kombineerida ja nimetada üheks terminiks.

Riis. 6.19. Ühenduste ühendamine

13. Diagrammidel peab igal plokil olema oma number. Diagrammide numbreid kasutatakse mis tahes diagrammi või ploki asukoha näitamiseks hierarhias. Tipptaseme diagrammil on plokid tähistatud 0-ga, teise taseme diagrammide plokid numbritega 1 kuni 9 (1, 2, ..., 9), kolmanda taseme plokid kahe numbriga, millest esimene näitab üksikasjaliku ploki numbrit vanemdiagrammil ja teist ploki numbrit jooksval diagrammil järjekorras (11, 12, 25, 63) jne. Konteksti diagrammil on tähis “A - 0”, lagunemisskeem esimese taseme puhul on “A0”, järgmiste tasandite lagunemisskeemid on tähistatud tähega “ A”, millele järgneb laguneva ploki number (näiteks “A11”, “A12”, “A25”, “ A63"). Joonisel on kujutatud tüüpiline puu diagramm (sõlmepuu diagramm) koos nummerdamisega.

Riis. 6.20. Diagrammi hierarhia

Kaasaegsetes CASE-tööriistades toetatakse tööde nummerdamismehhanisme automaatselt. CASE tööriistad pakuvad ka sõlmepuu diagrammide automaatset koostamist, mis sisaldavad ainult hierarhilisi seoseid. Sellise diagrammi tipuks võib olla mis tahes sõlm (plokk) ja seda saab ehitada mis tahes sügavusele.

6.6. Näide IDEF0 mudeli ehitamisest lubatud kiiruste määramise süsteemi jaoks

Lubatud rongikiiruste arvutamine on töömahukas inseneritöö. Kui rong läbib mis tahes lõigu, ei tohi rongi tegelik kiirus ületada suurimat lubatud kiirust. See maksimaalne lubatud kiirus määratakse kasutuskogemuse ja spetsiaalselt läbiviidud liikumisdünaamika ja veeremi rööbastee mõjude katsete põhjal. Selle kiiruse mitteületamine tagab rongiliikluse ohutuse, reisijatele mugavad sõidutingimused jne. Need määratakse sõltuvalt veeremi tüübist (veduri mark ja vagunite tüüp), rööbastee ülemise struktuuri parameetritest (sõiduki tüüp). rööpad, ballast, liipri skeem) ja plaan (raadiuskõverad, üleminekukõverad, rööpa väliskõrgused jne). Lubatud kiiruste määramiseks on reeglina vaja määrata vähemalt kaks (sirgetel) ja viis (kurvidel) kiirust, mille hulgast valitakse lõplik lubatud kiirus kõigist arvutatutest madalaimaks. Nende kiiruste arvutamist reguleerib Venemaa Raudteeministeeriumi 12. novembri 2001. aasta korraldus nr 41 "Föderaalse Raudteetranspordi 1520 (1524) mm rööpmelaiusega raudteede veeremi lubatud kiiruste normid".

Nagu märgitud, algab IDEF0 mudeli konstrueerimine kogu süsteemi esitamisest lihtsa komponendi (kontekstidiagrammi) kujul. Sellel diagrammil kuvatakse süsteemi eesmärk (põhifunktsioon) ning vajalikud sisend- ja väljundandmed, juhtimis- ja reguleerimisinfo ning mehhanismid.

Lubatud kiiruste määramise probleemi kontekstdiagramm on näidatud joonisel 6.21. Mudeli ehitamiseks kasutati Computer Associatesi BPwin 4.0 toodet.

Riis. 6.21. Lubatud kiiruste määramise süsteemi kontekstdiagramm (IDEF0 metoodika)

Nagu taustainfo, mille alusel määratakse lubatud kiirused, kasutatakse järgmist:

Projekti andmed uue liini või rekonstrueerimisprojekti kohta (sisaldab kogu projekti elluviimiseks vajalikku teavet, nimelt läbisõitu, eraldi punktide telgesid, liiniplaani jne);

Üksikasjalik pikiprofiil (sisaldab teavet, mis sarnaneb eespool käsitletule);

Raja distantsi pass (sisaldab eelpool käsitletule sarnast teavet, samuti teavet raja pealisehituse (VSP) kohta);

Andmed rajamõõtmisautoga rajaplaani mõõdistamise tulemuste kohta;

Väliste rööpakõrguste loend kurvides (sisaldab teavet rööbastee plaani kohta).

Osa taustteabest on pärit erinevatest allikatest. Eelkõige saab infot plaani (kõvera parameetrid) kohta võtta uue liini või rekonstrueerimisprojekti projektist, üksikasjalikust pikiprofiilist, rööbastee kauguse tõendist jne.

Kontrolli andmeid on:

Juhend arvutamiseks teerajateenistuse juhatajalt või JSC Venemaa Raudtee rööbasteede ja konstruktsioonide osakonnalt;

korraldus nr 41, mis sisaldab regulatiivset ja viiteteavet, protseduure ja valemeid lubatud kiiruste määramiseks;

Teave jooksva või kavandatava rongiliikluse kohta (andmed liikvel olevate vedurite markide ja kasutatavate vagunite tüüpide kohta);

Teave planeeritavate rööbasteede remondi, rekonstrueerimise ja konstruktsioonide ning seadmete rekonstrueerimise kohta.

Tulemus süsteemi töö peaks olema järgmine:

Lubatud kiiruste loendid, mis sisaldavad igat tüüpi arvutatud kiirusi ja võimaldavad kindlaks teha nende piiramise põhjuse;

Teejuhi korralduse lehed lõikudel ja eraldiseisvates punktides lubatud kiiruste kehtestamise kohta (korraldus "N") vastavalt teel aktsepteeritud vormile. Kinnitatud korraldusega “N” kehtestatakse ametlikult rongide lubatud kiirused;

Tüüpvormid nr 1, 1a ja 2, mis sisaldavad planeeritud lubatud kiirusi rongide sõiduplaanide koostamiseks.

Tellimuses “N” ja standardvormides sisalduvad kiirused võivad erineda arvutatud ja lubatud kiiruste lehtedel näidatud kiirustest. Selle põhjuseks on asjaolu, et need ei kajasta kiiruspiiranguid mitte ainult veeremi konstruktsiooni, VSP parameetrite ja kõverate osas, vaid ka seadmete ja konstruktsioonide seisukorras (teepõhja deformatsioon, õhuliini kontaktvõrgu tugede kõrvalekaldumine jne). ). Lisaks korrigeeritakse neid planeeritud rööbastee remonti, konstruktsioonide ja seadmete rekonstrueerimist ja rekonstrueerimist jms.

Kui kontekstiskeem on koostatud, on see üksikasjalik, kasutades esimese taseme lagunemisdiagrammi. See diagramm kuvab süsteemifunktsioonid, mis tuleb põhifunktsioonis rakendada. Diagrammi, mille jaoks dekomponeerimine on teostatud, seda üksikasjalikult kirjeldavate diagrammide suhtes nimetatakse vanemlik . Nimetatakse lagunemisdiagrammi vanema suhtes tütarettevõte .

Vaadeldava probleemi esimese taseme lagunemisdiagramm on näidatud joonisel 6.22. Reeglina jagatakse lagunemisdiagrammi koostamisel algne funktsioon (dekomponeeritud) 3–8 alamfunktsiooniks (plokiks). Sel juhul on soovitatav paigutada dekomponeerimisdiagrammil plokid vasakult paremale, ülalt alla, et alamfunktsioonide koostoime jada ja loogika oleks paremini nähtav.

Riis. 6.22. Esimese taseme lagunemisdiagramm (IDEF0 metoodika)

Funktsioonide täitmise järjekord vaadeldava probleemi lahendamiseks on järgmine:

Regulatiivse ja viiteinfo ning teelõikude andmete sisestamine ja kohandamine (plokid 1 ja 2);

Arvutusülesande koostamine (plokk 3). See näitab, millise lõigu ja raja, samuti veduri margi ja autode tüübi jaoks tuleks arvutus teha;

Lubatud kiiruste arvutamine vastavalt korralduses nr 41 (plokk 4) toodud korrale ja valemitele. Lähteinfoks on andmed lõigu trassi kohta (plaan, raja pealisehitus jne) ja arvutusülesande alusel valitud normid;

Lubatud kiiruste nimekirjade koostamine (plokk 5). Arvutustulemuste põhjal luuakse mitut tüüpi väljunddokumente, mis ühelt poolt võimaldavad tuvastada kiiruspiirangute põhjust, teisalt on reguleeritud dokumentide koostamise aluseks;

Korralduse “N” eelnõu ja tüüpavalduste (plokid 6 ja 7) vormistamine ja koostamine.

Peale esimese astme lagunemisdiagrammi koostamist konstrueeritakse sellel näidatud funktsioonide jaoks eraldi diagrammid (teise tasandi lagunemisdiagrammid). Seejärel jätkub lagunemisprotsess (diagrammeerimine), kuni funktsioonide edasine täpsustamine muutub mõttetuks. Iga aatomifunktsiooni jaoks, mis kirjeldab elementaaroperatsiooni (st funktsiooni, millel puudub lagunemisdiagramm), koostatakse üksikasjalik spetsifikatsioon, mis määratleb selle omadused ja teostusalgoritmi. Algoritmi vooskeeme võib kasutada spetsifikatsiooni täiendusena. Seega koosneb funktsionaalse modelleerimise protsess funktsioonide hierarhia järkjärgulisest ülesehitamisest.

6.7. ICOM koodid

Plokist sisse- ja väljapoole liikuvad nooled ülataseme diagrammil on samad, mis madalama taseme diagrammi sisse- ja väljapoole suunduvad nooled, sest kast ja diagramm esindavad sama süsteemi osa (vt joonis 1). Ja ). Selle tulemusena on tipptaseme funktsiooni piirid samad, mis lagunemisdiagrammi piirid.

ICOM koodid (akronüüm sõnadest Input, Control, Output ja Mechanism) on mõeldud piirinoolte tuvastamiseks. ICOM-kood sisaldab nooletüübile (I, C, O või M) vastavat eesliidet ja seerianumbrit (vt joonist).