IDEF0 diagramok. IDEF0 módszertan a BPWinben

IDEF0 módszertan

IDEF0 módszertan hierarchikus diagramrendszer felépítését írja elő - a rendszer töredékeinek egyetlen leírását. Először a rendszer egészének és a külvilággal való interakciójának leírása történik (kontextus diagram), majd egy funkcionális bontást hajtanak végre - a rendszert alrendszerekre osztják, és minden alrendszert külön írnak le (bontási diagramok). . Ezután minden alrendszer kisebb részekre oszlik, és így tovább, amíg el nem éri a kívánt részletességi szintet.

Minden egyes IDEF0 diagramokA blokkokat és íveket tartalmaz. A blokkok a modellezett rendszer funkcióit ábrázolják. Az ívek összekapcsolják a blokkokat, és képviselik a köztük lévő interakciókat és kapcsolatokat.

A diagramokban a funkcionális blokkokat (munkát) téglalapok ábrázolják, amelyek megnevezett folyamatokat, függvényeket vagy feladatokat képviselnek, amelyek egy bizonyos időtartam alatt fordulnak elő, és felismerhető eredményekkel járnak. A mű nevét a cselekvést jelző szóbeli főnévként kell kifejezni.

IDEF0 megköveteli, hogy a diagramnak legalább három és legfeljebb hat blokkja legyen. Ezek a megszorítások olyan szinten tartják a diagramok és modellek összetettségét, hogy az olvasható, érthető és használható legyen.

A blokk minden oldalának különleges, nagyon konkrét célja van. A blokk bal oldala a bemeneteket, a felső a vezérlést, a jobb a kimeneteket, az alsó pedig a mechanizmusokat szolgálja. Ez a megjelölés bizonyos rendszerelveket tükröz: a bemeneteket kimenetekké alakítják, vezérlési határértékeket vagy előírja a transzformációk végrehajtásának feltételeit, a mechanizmusok megmutatják, hogy egy funkció mit és hogyan teljesít.

Az IDEF0-ban lévő blokkok fontossági sorrendben vannak elhelyezve, ahogy azt a diagram készítője megérti. Ezt a relatív rendet dominanciának nevezzük. Dominancia alatt azt a hatást értjük, amelyet az egyik blokk gyakorol a diagram többi blokjára. Például a diagram legdominánsabb blokkja lehet a szükséges függvénysorozat első része, vagy egy olyan tervezési vagy vezérlő funkció, amely az összes többit befolyásolja.

A legdominánsabb blokk általában a diagram bal felső sarkába kerül, a legkevésbé domináns pedig a jobb sarokba.

A blokkok elrendezése az oldalon tükrözi a szerző dominancia-definícióját. Így a diagram topológiája megmutatja, hogy mely jellemzők vannak nagyobb hatással másokra. Ennek hangsúlyozására az elemző átszámozhatja a blokkokat a dominancia sorrendjének megfelelően. A dominancia sorrendjét minden téglalap jobb alsó sarkában elhelyezett szám jelzi: az 1 a legnagyobb dominanciát jelölné, a 2 a következőt stb.

A művek kölcsönhatása a külvilággal és egymással nyilak formájában van leírva, amelyek egyetlen vonalként vannak ábrázolva, nyilakkal a végén. A nyilak bizonyos információkat jelentenek, és főneveknek nevezik őket.

Az IDEF0 ötféle nyíltípust különböztet meg.

Bejárat- a munka által felhasznált és átalakított objektumok eredmény (kimenet) elérése érdekében. Megengedett, hogy a műnek ne legyen egyetlen belépő nyila. A belépő nyíl a munka bal szélére kerül.

Ellenőrzés-.a mű cselekvéseit irányító információk. Általában a vezérlőnyilak olyan információkat tartalmaznak, amelyek jelzik, hogy egy feladatnak mit kell elvégeznie. Minden munkának rendelkeznie kell legalább egy vezérlő nyíllal, amely a feladat felső szélén jelenik meg.

Kijárat- objektumok, amelyekké a bemeneteket átalakítják. Minden jobnak rendelkeznie kell legalább egy kilépési nyíllal, amely a job jobb széléből származik.

Gépezet- a munkát végző erőforrások. A mechanizmus nyila a munka alsó szélébe kerül. Az elemző belátása szerint előfordulhat, hogy a mechanizmus nyilai nem jelennek meg a modellen.

Hívás- egy speciális nyíl, amely más működési modellre mutat. A hívó nyíl a munka aljáról jön, és azt jelzi, hogy a modellezett rendszeren kívül történik valamilyen munka.

Rizs. 2.1 A nyilak típusai

Az IDEF0 módszertan mindössze ötféle interakciót igényel a blokkok között, hogy leírja kapcsolataikat: vezérlés, bemenet, vezérlési visszacsatolás, bemeneti visszacsatolás, kimeneti mechanizmus. A vezérlési és bemeneti kapcsolatok a legegyszerűbbek, mivel közvetlen hatásokat tükröznek, amelyek intuitívak és nagyon egyszerűek.

Rizs. 2.2. Kimeneti kommunikáció

Rizs. 2.3. Vezetői kommunikáció

Vezérlési kapcsolat akkor jön létre, ha egy blokk kimenete közvetlenül érinti a kevésbé domináns blokkot.

A vezérlés visszacsatolása és a bemeneti visszacsatolás összetettebb, mert iterációt vagy rekurziót foglal magában. Ugyanis az egyik munka kimenetei befolyásolják a többi job jövőbeli végrehajtását, ami utólag hatással van az eredeti munkára.

A vezérlés visszacsatolása ekkor következik be; amikor valamilyen blokk kimenete nagyobb dominanciájú blokkot érint.

Az output-mechanizmus kapcsolatok ritkák. Olyan helyzetet tükröznek, amelyben az egyik funkció kimenete a másik céljának eszközévé válik.

Rizs. 2.4. Bejelentkezési visszajelzés

Rizs. 2.5. Vezetői visszajelzés

Az output-mechanizmus kapcsolatok az erőforrás-források (pl. szükséges eszközök, képzett személyzet, fizikai tér, felszerelés, finanszírozás, anyagok) elosztására jellemzőek.

Az IDEF0-ban egy ív ritkán reprezentál egyetlen objektumot. Általában tárgyak halmazát szimbolizálja. Mivel az ívek objektumok gyűjteményét képviselik, több kiindulási pontja (forrás) és végpontja (célállomása) is lehet. Ezért az ívek különféle módon elágazhatnak és összekapcsolódhatnak. A teljes ív vagy annak egy része egy vagy több blokkból nyúlhat ki, és egy vagy több blokkban végződhet.

Az elágazó ívek, amelyeket sugárzó vonalként ábrázolnak, azt jelentik, hogy az ívek teljes tartalma vagy annak egy része megjelenhet az egyes ágakban. Egy ív mindig egy elágazás előtt van felcímkézve, hogy nevet adjon a teljes halmaznak. Ezenkívül az ív minden ága felcímkézhető vagy nem a következő szabályok szerint:

a címkézetlen ágak az ívcímkében megadott objektumok súlyát tartalmazzák az elágazás előtt;

az elágazási pont után címkézett ágak az elágazás előtti ívcímkében megadott objektumok egészét vagy egy részét tartalmazzák.

Az IDEFO-ban összefolyó vonalakként ábrázolt ívösszevonások azt jelzik, hogy az egyes ágak tartalma az eredeti ívek egyesítéséből származó ív címkéjét képezi. Egyesítés után az eredményül kapott ív mindig megjelölésre kerül, jelezve az összevonás eredményeként létrejövő új objektumkészletet. Ezenkívül az egyes ágakat meg lehet jelölni, vagy nem lehet megjelölni az összevonás előtt, a következő szabályok szerint:

Rizs. 2.6. Kimeneti-mechanizmus kapcsolat

a címkézetlen ágak az összevonás után az ív közös címkéjében megadott objektumok súlyát tartalmazzák;

az egyesítés előtt megjelölt ágak az egyesítés után a közös címkében felsorolt ​​objektumok mindegyikét vagy egy részét tartalmazzák,

blokkok száma a diagramon - N;

diagram bontási szint - L;

diagram egyensúlya - BAN BEN;

a blokkhoz csatlakozó nyilak száma - A

Ez a tényezőkészlet minden modelldiagramra vonatkozik. Az alábbiakban felsoroljuk a diagramon szereplő tényezők kívánt értékére vonatkozó ajánlásokat.

Arra kell törekedni, hogy az alacsonyabb szintek diagramjain a blokkok száma kisebb legyen, mint a szülődiagramokon, azaz a dekompozíció szintjének növekedésével az együttható csökkenjen. Így ennek az együtthatónak a csökkenése azt jelzi. hogy a modell felbontásával a függvények egyszerűsödjenek, ezért a blokkok száma csökkenjen.

A diagramoknak kiegyensúlyozottnak kell lenniük. Ez azt jelenti, hogy egy diagramon belül nem fordulhat elő az 1. ábrán látható helyzet. 2.7: az 1. munkában lényegesen több a bejövő nyíl és a vezérlő nyíl, mint a kimenő. Megjegyzendő, hogy ez az ajánlás nem feltétlenül követhető a gyártási folyamatokat leíró modellekben. Például egy összeszerelési eljárás leírásakor egy blokk sok nyilat tartalmazhat, amelyek egy termék alkatrészeit írják le, és egy nyíl, amely kilép a késztermékből.

Rizs. 2.7. Példa egy kiegyensúlyozatlan diagramra

Mutassuk be a diagram egyensúlyi együtthatóját

Arra kell törekedni K minimális volt a diagram számára.

A diagram grafikai elemeinek elemzése mellett figyelembe kell venni a blokkok nevét is. A nevek kiértékeléséhez a modellezett rendszer elemi (triviális) függvényeinek szótárát állítják össze. Valójában ennek a szótárnak tartalmaznia kell a diagrambontás alsó szintjének függvényeit. Például egy adatbázismodellnél a „rekord keresése” és a „rekord hozzáadása az adatbázishoz” funkciók lehetnek elemiek, míg a „felhasználói regisztráció” függvény további leírást igényel.

A szótár kialakítása és a rendszerdiagram-csomag összeállítása után figyelembe kell venni a modell alsó szintjét. Ha egyezések vannak a diagramblokkok nevei és a szótárból származó szavak között, az azt jelenti, hogy a felbontás megfelelő szintjét sikerült elérni. Ezt a kritériumot mennyiségileg tükröző együtthatót így írhatjuk fel L*C- a modellszint és a blokknevek szótárbeli szavakkal való egyezéseinek számának szorzata. Minél alacsonyabb a modell szintje (nagyobb L), annál értékesebbek az egyezések.

A BPWin indításakor alapértelmezés szerint megjelenik a fő eszköztár, az eszközpaletta és a Model Explorer.

Új modell létrehozásakor egy párbeszédablak jelenik meg, amelyben meg kell adni, hogy a modell újból készül-e, vagy a ModelMart tárolóból nyílik meg, adja meg a modell nevét, és válassza ki a modell felépítésének módszerét ( 2.8. ábra).

2.8 Modellkészítés párbeszédpanel

A BPWin három módszert támogat – IDEF0, IDEF3 és DFD. A BPWin-ben lehetőség van vegyes modellek készítésére, azaz a modell egyszerre tartalmazhat IDEF0 és IDEF3 diagramokat és DFD-t. Az eszközpaletta összetétele automatikusan megváltozik, amikor egyik jelölésről a másikra vált.

A BPWin modelljeit művek halmazának tekintjük, amelyek mindegyike egy bizonyos adatkészlettel működik. Ha bármelyik modellobjektumra kattint a bal egérgombbal, megjelenik egy felugró helyi menü, amelynek minden eleme megfelel az objektum egy tulajdonságának szerkesztőjének.

A rendszermodell felépítését a működését leíró összes dokumentum tanulmányozásával kell kezdeni. Az egyik ilyen dokumentum a műszaki specifikáció, nevezetesen a „Fejlesztési cél”, „A rendszer céljai és célkitűzései” és „A rendszer működési jellemzői” fejezetek.

A forrásdokumentumok áttanulmányozása, valamint a rendszer vásárlói és felhasználói megkérdezése után szükséges a modellezés céljának megfogalmazása és a modellre vonatkozó nézőpont meghatározása. Tekintsük felépítésének technológiáját az "Egyetemi Foglalkoztatási Szolgálat" rendszer példáján keresztül, amelynek főbb lehetőségeit az 1. számú laboratóriumi munka ismertette.

Fogalmazzuk meg a modellezés célját: a rendszer működésének leírását, amely a felhasználó számára érthető lenne, anélkül, hogy a megvalósítással kapcsolatos részletekbe bocsátkoznánk. A modellt a felhasználók (hallgató, tanár, adminisztrátor, dékáni hivatal, cég) szemszögéből építjük fel.

Kezdjük egy IDEF0 kontextusdiagram felépítésével. A rendszer leírása szerint a fő funkciója az ügyfelek kiszolgálása a tőlük érkező kérések feldolgozásával. Így a kontextusdiagram egyetlen feladatát a „Rendszer kliensének kiszolgálása”-ként határozzuk meg. Ezután meghatározzuk a bemeneti és kimeneti adatokat, valamint a mechanizmusokat és a vezérlést.

Az ügyfél kiszolgálásához regisztrálni kell a rendszerben, meg kell nyitni az adatbázishoz való hozzáférést és feldolgozni kérését. A bemeneti adatok a következők lesznek: „ügyfél neve”, „kliens jelszó”, „forrás adatbázis”, „ügyfél kérése”. A kérés teljesítése vagy a rendszerből történő információ vételéhez, vagy az adatbázis tartalmának megváltoztatásához vezet (például szakértői értékelések összeállításakor), így a kimeneti adatok „jelentések” és „módosított adatbázisok” lesznek. A kérésfeldolgozási folyamatot a rendszerfigyelő végzi az adminisztrátor felügyelete mellett.

Így definiáljuk a rendszer kontextusdiagramját (2.9. ábra).

2.9. ábra. Rendszerkontextus diagram

Bontsuk fel a környezeti diagramot, leírva az ügyfélszolgálat sorrendjét:

A rendszerhez való hozzáférés szintjének meghatározása.

Alrendszer kiválasztása.

Hozzáférés az alrendszerhez.

Az adatbázis módosítása (ha szükséges).

ábrán látható diagramot kapjuk. 2.10.

A kontextusdiagram bontásának befejezése után folytassa a következő szintdiagram bontásával. A harmadik és az alsóbb szintek figyelembevételekor a modellek általában visszatérnek a szülődiagramokhoz, és módosítják azokat.

Rizs. 2.10. A „Szolgáltatás, rendszerkliens” munka bontása

A kapott diagram összes blokkját egymás után felbontjuk. A rendszerhez való hozzáférés szintjének meghatározásának első lépése a felhasználói kategória meghatározása. A kliens nevét keresi a felhasználói adatbázisban, meghatározva a kategóriáját. Egy bizonyos kategória szerint meghatározzák a rendszer használójának biztosított jogosítványokat. Ezután a rendszerhez való hozzáférési eljárást hajtják végre, ellenőrizve a hozzáférési nevet és jelszót. A jogosultságokkal és a rendszerhez való hozzáférési szinttel kapcsolatos információk kombinálásával a felhasználó számára engedélyezett műveletek halmaza jön létre. Így a rendszer hozzáférési szintjének meghatározása a 2. ábrán látható módon fog kinézni. 2.11.

Rizs. 2.11.„A rendszerhez való hozzáférés szintjének meghatározása” című munka bontása

A rendszer-hozzáférési eljárás befejezése után a monitor elemzi az ügyfél kérését, és kiválasztja a kérést feldolgozó alrendszert. A „Felhívás egy alrendszerhez” című mű dekompozíciója nem felel meg a modell céljának és nézőpontjának. A rendszer felhasználóját nem érdeklik a működésének belső algoritmusai. Ebben az esetben fontos számára, hogy az alrendszer kiválasztása automatikusan, az ő beavatkozása nélkül történjen, így az alrendszerhez való hozzáférés dekompozíciója csak bonyolítja a modellt.

Felbontjuk az „Ügyfélkérés feldolgozása” munkát, amelyet az alrendszer a kérések feldolgozására végez, meghatározva a felhasználók kategóriáit és jogosultságait. Mielőtt választ keres egy lekérdezésre, meg kell nyitnia az adatbázist (csatlakoznia kell hozzá). Általánosságban elmondható, hogy az adatbázis egy távoli szerveren található, ezért szükséges lehet kapcsolatot létesíteni vele. Határozzuk meg a munka sorrendjét:

Az adatbázis megnyitása.

A kérés teljesítése.

Jelentések generálása.

Az adatbázis megnyitása után értesíteni kell a rendszert, hogy létrejött a kapcsolat az adatbázissal, majd végrehajtani a kérést és jelentéseket generálni a felhasználó számára (2.12. ábra).

Meg kell jegyezni, hogy a „Lekérdezés végrehajtása” magában foglalja a különböző alrendszerek munkáját. Például, ha a kérés tesztelést is tartalmaz, akkor azt a szakmai és pszichológiai tesztek alrendszere hajtja végre. A lekérdezés végrehajtási szakaszában szükség lehet az adatbázis tartalmának módosítására, például szakértői értékelések összeállításakor. Ezért a diagramban biztosítani kell ezt a lehetőséget.

Rizs. 2.12.

A kapott diagram elemzésekor felvetődik a kérdés: milyen szabályok alapján készítik a riportokat? Előre generált sablonokra van szükség, amelyek az adatbázisból történő kiválasztáshoz fognak használni, és ezeknek a sablonoknak meg kell felelniük a lekérdezéseknek és előre definiáltaknak kell lenniük. Ezen túlmenően az ügyfélnek lehetőséget kell biztosítani a jelentés formájának megválasztására.

Állítsuk be a diagramot a „Jelentéssablonok” és az „Adatbázis-módosítási kérések” nyilak, valamint a „Rendszerkliens” alagútnyil hozzáadásával. A „Rendszerkliens” alagútkezelést azért használjuk, hogy a nyíl ne kerüljön a felső diagramra, mivel a jelentés űrlap kiválasztásának funkciója nem elég fontos ahhoz, hogy a szülő diagramon megjelenjen.

A diagram megváltoztatása az összes szülődiagram módosítását eredményezi (2.13 - 2.15. ábra).

Célszerű a „Lekérdezés végrehajtása” munkát DFD diagrammal bontani (3. sz. laboratóriumi munka), mivel az IDEF0 módszertana a rendszert egymással összefüggő munkák halmazának tekinti, amely nem tükrözi jól az információfeldolgozási folyamatokat.

Rizs. 2.13. Az „Ügyfél kérésének feldolgozása” című munka bontása

Rizs. 2.14. A „Rendszerkliens-szolgáltatás” munka bontása (2. lehetőség)

Rizs. 2.15. Rendszerkörnyezet-diagram (2. lehetőség)

Térjünk át az utolsó blokk „Adatbázis módosítása” bontására. A kliens szempontjából a rendszeradatok egy adatbázisban helyezkednek el. Valójában hat adatbázis van a rendszerben:

felhasználói adatbázis,

hallgatói adatbázis, (2. lehetőség)

üresedési adatbázis,

tanulmányi teljesítmény adatbázis,

teszt adatbázis,

szakértői értékelések DB,

DB önéletrajz.

A modellezés célja szerint fontos, hogy az ügyfél megértse, hogy a kapott adatok nem frissülnek azonnal a rendszerben, hanem egy további feldolgozási és ellenőrzési szakaszon esnek át. A változtatási algoritmus a következőképpen fogalmazható meg:

Meg van határozva az adatbázis, amelyben az információ megváltozik.

Az üzemeltető létrehoz egy ideiglenes adatkészletet, és átadja azt az adminisztrátornak.

Az adminisztrátor ellenőrzi az adatokat és beviszi az adatbázisba.

Ezt a modellt más módon is meg lehet valósítani úgy, hogy az adatkezelési folyamat megkerülésével az adatbázis közvetlenül kérésre frissíthető. Ebben az esetben biztosítani kell az adatbázis integritását a károsodás elkerülése érdekében. Ebben az esetben a diagram így fog kinézni (2.17. ábra).

Rizs. 2.16. Az adatbázis megváltoztatása című munka bontása

Rizs. 2.17. Az „Adatbázis módosítása” munka bontása (2. lehetőség) Az első opcióhoz, az ábrán látható. 2.12

Az „Adatbázis-változások” további dekompozíciója bonyolítja a modellt, elmagyarázva, hogyan történik az adatbázis fizikai megváltoztatása a rendszerben. Ebben az esetben a felhasználó nem kap további tájékoztatást a foglalkoztatási szolgálati rendszer működéséről. Ezt a munkát célszerű az adatbázis-rendszer tervezési folyamata során, az adatbázis logikai modelljének elkészítésének szakaszában felbontani.

A lekérdezés-végrehajtási munka bontását a következő laborban végezzük el, bemutatva a DFD diagramok használatát az információfeldolgozási folyamatok leírására.

Végezzük el az ábrán látható modellek kvantitatív elemzését. 2.12 és 2.13, a fent leírt módszer szerint. Tekintsük a ^ együttható viselkedését ezekre a modellekre. Az „Ügyfélkérelem feldolgozása” szülődiagram együtthatója 4/2 = 2, a dekompozíciós diagramé 3/3 = 1. Az együttható értéke csökken, ami a funkciók leírásának egyszerűsödését jelzi, mint az a modell csökken.

Tekintsük az együttható változását NAK NEK b két modell opció van.

a második lehetőséghez

Együttható NAK NEK b nem változtatja meg az értékét, ezért a diagram egyensúlya nem változik.

Feltételezzük, hogy a figyelembe vett diagramok felbontási szintje elegendő ahhoz, hogy tükrözze a modellezés célját, és az alsó szint diagramjain az elemi függvények munkanévként szerepelnek (a rendszerhasználó szemszögéből) .

Összegezve a vizsgált példát, meg kell jegyezni, hogy egy rendszer modellezésekor több diagramopciót is figyelembe kell venni. Ilyen lehetőségek merülhetnek fel a diagramok módosításakor, mint ahogyan az „Ügyfélkérés feldolgozása” esetében történt, vagy amikor a rendszerfunkciók alternatív megvalósításait hozzuk létre (az „Adatbázis módosítása” munka bontása). A lehetőségek áttekintésével kiválaszthatja a legjobbat, és további megfontolás céljából diagramcsomagba foglalhatja.

Az IDEF0 diagramok a BPWin programmal készülnek. A folyamatban lévő üzleti folyamatok grafikus modellezésére szolgálnak

Az IDEF0 módszertanáról

Az IDEF0 módszertan széles körben elterjedt az egyszerű és könnyen érthető grafikus jelölése miatt, melynek használata a modell felépítéséhez nagyon kényelmes. A módszertanban a fő helyet a diagramok kapják. A diagramok geometriai téglalapok segítségével jelenítik meg a rendszer funkcióit, valamint a funkciók és a külső környezet közötti meglévő kapcsolatokat. A kapcsolatok nyilak segítségével jelennek meg. Ezt láthatja, ha megnézi, mit kínál az IDEF0 diagram, amelyre ebben a cikkben talál példákat.

Az a tény, hogy csak két grafikus primitívet használnak a modellezésben, lehetővé teszi az IDEF0 interakciók aktuális szabályainak gyors elmagyarázását azoknak, akiknek fogalmuk sincs róla vizuális grafikai nyelv használata. Megtekintheti, mit kínál az IDEF0 diagram, amelyre az alábbiakban példákat mutatunk be.

IDEF0-hoz használt elemek

Amint már említettük, 2 típusú geometriai primitívet használnak: téglalapokat és nyilakat. A téglalapok bizonyos folyamatokat, funkciókat, munkákat vagy feladatokat jelölnek, amelyeknek céljaik vannak, és amelyek meghatározott eredményhez vezetnek. A folyamatok egymás és a külső környezet közötti kölcsönhatását nyilak jelzik. Az IDEF0 5 különböző típusú nyilat különböztet meg.

Az IDEF0 lehetséges felhasználásai

Az IDEF0 módszertan bármely információs rendszer funkcionális aspektusának leírására használható.

A folyamatok közötti kapcsolatok típusai IDEF0

A modellnek az az érdeke, hogy a konstrukciók olyan kapcsolatait hozzuk létre, hogy a belső kapcsolatok a lehető legerősebbek, a külsők pedig a lehető leggyengébbek legyenek. Ez az IDEF0-val való modellezés erőssége. Példákat láthat diagramokra, és láthatja ezeknek a szavaknak a valódiságát. A kapcsolatok kialakításának megkönnyítése érdekében a hasonlókat modulokká egyesítik. Külső kapcsolatok jönnek létre a modulok között, a belső kapcsolatok pedig a modulokon belül. Többféle kapcsolat létezik.

1. Hierarchikus („rész” – „egész”) kapcsolat.

2. Vezető (szabályozó, beosztott):

2) vezérlő visszacsatolás.

3. Funkcionális vagy technológiai:

2) fordított bemenet.

3) fogyasztó;

4) logikai;

5) módszertani vagy kollegiális;

6) erőforrás;

7) tájékoztató jellegű;

8) ideiglenes;

9) véletlenszerű.

Építőelemek és kapcsolatok diagramokban

Az IDEF0 módszertan számos szabályt és ajánlást ad a használatára és a felhasználás minőségének javítására. Tehát a diagram egy blokkot jelenít meg, amelyen megadhatja a rendszer nevét és célját. 2-5 nyíl vezet a blokkhoz vagy onnan. Lehet több-kevesebb is, de legalább két nyíl kell a be-/kilépéshez, a többi pedig a kiegészítő munkához és azok diagramon való feltüntetéséhez. Ha a nyíl 5-nél nagyobb, akkor érdemes átgondolni a modell optimális felépítését, és azt, hogy lehetséges-e még részletesebbé tenni.

Építőkövek a bomlási diagramokban

Javasoljuk, hogy az egy diagramon megjelenő blokkok száma 3-6 legyen. Ha kevesebb van belőlük, akkor az ilyen diagramok valószínűleg nem hordoznak jelentést. Ha a blokkok száma hatalmas, akkor egy ilyen diagram olvasása nagyon nehéz lesz, tekintettel a további nyilak jelenlétére. Az információ észlelésének javítása érdekében javasolt a blokkokat felülről lefelé és balról jobbra helyezni. Ez az elrendezés tükrözi a folyamatok sorozatának végrehajtási logikáját. És a nyilak is kevesebb zavart keltenek, mivel minimális számú kereszteződésük van egymással.

Ha egy bizonyos funkció elindítása semmilyen módon nem vezérelt, és a folyamat bármikor elindítható, akkor ezt a helyzetet a vezérlést és a bevitelt jelző nyilak hiánya jelzi. De egy ilyen helyzet jelenléte jelezheti a potenciális partnerek számára bizonyos instabilitást és annak szükségességét, hogy közelebbről megvizsgálják a potenciális partnert.

A csak bemeneti nyíllal rendelkező blokk azt jelzi, hogy a folyamat megkapja a bemeneti paramétereket, de a végrehajtás során nem történik vezérlés vagy beállítás. A csak egy vezérlő nyíllal rendelkező blokk olyan munka jelzésére szolgál, amelyet csak a vezérlőrendszer külön parancsára hívnak le. Minden szakaszában kezelik és beállítják őket.

De egy IDEF0 diagram felépítésének példája meggyőzheti Önt arról, hogy a legteljesebb és legátfogóbb típus a bemeneti és vezérlő nyilakkal ellátott diagram.

Elnevezés

A vizuális érzékelés javítása érdekében minden blokknak és minden nyílnak saját nevével kell rendelkeznie, amely lehetővé teszi, hogy azonosítsák őket sok más blokk és nyíl között. Így néznek ki a példadiagramok az IDEF0-ban. A segítségükkel felépített információs rendszer lehetővé teszi a modellek összes hiányosságának és bonyolultságának megértését.

Gyakran használják az összevonó nyilakat, és kérdések merülnek fel az elnevezésükkel kapcsolatban. De az összevonás csak homogén adatok átvitele esetén lehetséges, így külön nevekre nincs szükség, pedig a BPWin programban megadhatók. Továbbá, ha eltérés van a nyilak között, akkor külön-külön is meg lehet nevezni őket, hogy megértsük, mi miért felelős.

Ha az ág után nincs név, akkor a név pontosan megegyezik az elágazás előtti névvel. Ez akkor fordulhat elő, ha két blokk ugyanazt az információt kéri. Az IDEF0 kontextusdiagram, amelyre ebben a cikkben található példa, megerősíti ezeket a szavakat.

Nyíl információk

A kompozíciós diagram elkészítésekor ugyanabba a blokkba belépő és kilépő nyilakat meg kell jeleníteni rajta. A diagramra átvitt geometriai alakzatok nevének pontosan meg kell ismételnie a legmagasabb szintű információkat. Ha két nyíl párhuzamos egymás íveivel (azaz az egyik folyamat szélén indulnak, és mindkettő egy másik folyamatnak ugyanazon a szélén végződnek), akkor a modell optimalizálása érdekében esetleg kombinálni kell őket, és megfelelő nevet kell adni, ami tökéletesen megfelel. IDEF0-ban jelenik meg (a Visio példadiagramjai megtekinthetők).

Példa az IDEF0 módszertan megvalósítására egy adott modellen

Már megtanulta, mi az IDEF0 diagram, részben láthatott példákat és szabályokat az ilyen diagramok készítésére. Most a gyakorláshoz kell fordulnunk. A jobb megértés érdekében a magyarázat nem valamilyen „általános” modellen fog alapulni, hanem egy konkrét példán, amely lehetővé teszi, hogy jobban és teljesebben megértse a BPWin programban az IDEF0-val való munkavégzés jellemzőit.

Példa erre a vonat sebessége A pontból B pontba. Figyelembe kell venni, hogy a vonat nem érhet el a megengedett sebességnél nagyobb sebességet. Ez a vonal az üzemeltetési tapasztalatok és a vonatok vasúti pályára gyakorolt ​​hatása alapján került kialakításra. Meg kell érteni, hogy a vonat célja az utasok szállítása, akik viszont fizettek azért, hogy biztonságosan és kényelmesen elérjék úticéljukat. Hasznos egy IDEF0 diagram, amelyre ebben a cikkben talál példákat.

A kezdeti információ:

1. adatok a vágányvonalról;
2. útlevél a teljes távolságra;
3. útvonalterv.

Ellenőrző adatok:

1. Utasítások a főnöktől, a pályaszolgálat vezetőjétől.
2. Információk a meglévő vonatforgalomról.
3. Tájékoztatás a tervezett javításokról, átépítésekről és pályamódosításokról.

A modell eredménye:

1. A megengedett sebesség korlátozása, feltüntetve a korlátozás okát.
2. Megengedett sebességek külön pontokon történő mozgáskor és a vonatok átszállásakor.

A kontextusdiagram felépítése után le kell fúrni, majd létrejön egy összetett diagram, amely az első szintű diagram lesz. Ez megmutatja a rendszer összes fő funkcióját. Az IDEF0 módszertant és diagramot, amelyre a felbontás történik, szülőnek nevezzük. Az IDEF0 dekompozíciót gyermekfelbontásnak nevezzük.

Következtetés

Az első szintű lebontás után a második szintű dekompozíciót hajtják végre - és így tovább, amíg a további lebontás elveszti értelmét. Mindez azért történik, hogy a folyamatban lévő és tervezett folyamatokról a legrészletesebb grafikus diagramot kapjuk. Ez egy kész példa egy IDEF0 diagramra, amelyet most is használhat.

Az eset-eszközök jellemzői

Az ERwin egy koncepcionális adatbázis-modellező eszköz, amely az IDEF1X módszertant használja (lásd a 2.5 alfejezetet). Az ERwin megvalósítja az adatbázisséma tervezését, leírásának generálását a cél DBMS nyelvén (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress stb.) és egy meglévő adatbázis újratervezését. Az ERwin számos különböző konfigurációban kapható, amelyek a leggyakoribb 4GL alkalmazásfejlesztő eszközöket célozzák meg. Az ERwin/OPEN verzió teljes mértékben kompatibilis a PowerBuilder és SQLWindows alkalmazásfejlesztő eszközökkel, és lehetővé teszi a tervezett adatbázis leírásának közvetlen exportálását az eszköz adattáraiba.

Számos alkalmazásfejlesztő eszközhöz (PowerBuilder, SQLWindows, Delphi, Visual Basic) űrlapokat és alkalmazásprototípusokat állítanak elő.

Az Erwin ModelMart online verziója konzisztens adatbázis- és alkalmazástervezést tesz lehetővé egy munkacsoporton belül.

A BPwin egy funkcionális modellező eszköz, amely megvalósítja az IDEF0 módszertant (lásd a 2.2 alfejezetet).

Az S-Designor 4.2 egy CASE-eszköz relációs adatbázis-tervezéshez. Funkcióját és költségét tekintve közel áll az ERwin CASE eszközhöz, a diagramokban használt külső jelölésben különbözik. Az S-Designor szabványos adatmodellezési módszertant valósít meg, és adatbázisleírást generál olyan DBMS-ekhez, mint az ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server stb. A meglévő rendszerek esetében adatbázis-újratervezést hajtanak végre.

Az S-Designor számos alkalmazásfejlesztő eszközzel kompatibilis (PowerBuilder, Uniface, TeamWindows stb.), és lehetővé teszi az adatbázisleírás exportálását ezen eszközök tárházába. A PowerBuilder közvetlenül is generál alkalmazássablonokat.

A CASE.Analyst 1.1 gyakorlatilag az egyetlen jelenleg versenyképes hazai CASE funkcionális modellező eszköz, és a 2.3 alfejezetben leírt módszertan szerint valósítja meg az adatfolyam diagramok felépítését. Fő funkciói:

• DFD építése és szerkesztése;
• diagramok és tervezési előírások áttekintése teljesség és következetesség szempontjából;
• különböző jelentések fogadása a projektről;
• dokumentumelrendezések generálása a GOST 19.ХХХ és 34.ХХХ követelményei szerint.

Működési környezet: processzor - 386 és újabb, fő memória - 4 MB, lemezmemória - 5 MB, MS Windows 3.x vagy Windows 95.

A projekt adatbázisa Paradox DBMS formátumban van megvalósítva, és elérhető.

Egy külön szoftvertermék (Catherine) segítségével az adatcsere az ERwin CASE eszközzel történik. Ezzel egyidejűleg egy CASE.Analytics-ban készült projektből exportálódik az adatszerkezetek és adattároló eszközök leírása, amely bizonyos szabályok szerint az entitások és attribútumainak leírását képezi.

BPWin eszközkörnyezet

A BPwin meglehetősen egyszerű és intuitív felhasználói felülettel rendelkezik, amely lehetővé teszi az elemző számára, hogy minimális erőfeszítéssel összetett modelleket hozzon létre. A 2.5-ös verzió interfészét az alábbiakban ismertetjük.

Rizs. 1.1. Integrált fejlesztői környezet a BPwin 2.5 modellhez

A BPwin indításakor alapértelmezés szerint megjelenik a fő eszköztár, az eszközpaletta (melynek megjelenése a kiválasztott jelöléstől függ), valamint a bal oldalon a modellböngésző - Model Explorer (1.1. ábra).

Az eszköztár funkciói a Bpwin főmenüjéből érhetők el (1.1. táblázat).

1.1. táblázat. A Bpwin 2.5 fő eszköztár vezérlőinek leírása

Vezérlőelem	Leírás	Megfelelő menüpont
	Hozzon létre egy új modellt	Fájl/Új
	Nyitott modell	Fájl/Megnyitás
	Modell mentése	Fájl/Mentés
	Nyomtatási modell	Fájl/Nyomtatás
	Skála kiválasztása	Megtekintés/Nagyítás
	Méretezés	Megtekintés/Nagyítás
	Helyesírás-ellenőrzés	Eszközök/Helyesírás
	Kapcsolja be vagy ki a Model Explorert	View/Model Explorer
	Kiegészítő eszköztár engedélyezése és letiltása a ModelMart alkalmazáshoz	ModelMart

Új modell létrehozásakor egy párbeszédablak jelenik meg, amelyben meg kell adni, hogy a modell újonnan jön-e létre, vagy fájlból vagy a ModelMart tárolóból nyílik meg, adja meg a modell nevét és válassza ki a módszertant, amelyben a modell épül (1.2. ábra).

Ahogy fentebb említettük, a BPwin három módszert támogat – IDEF0, IDEF3 és DFD, amelyek mindegyike megoldja a saját specifikus problémáit. A BPwin-ben lehetőség van vegyes modellek készítésére, azaz a modell egyszerre tartalmazhat IDEF0 és IDEF3 diagramokat és DFD-t. Az eszközpaletta összetétele automatikusan megváltozik, amikor egyik jelölésről a másikra váltunk, így az eszközpalettáról később lesz szó.

Rizs. 1.2. Modellkészítés párbeszédpanel

A BPwin modelljeit művek halmazának tekintjük, amelyek mindegyike egy bizonyos adatkészlettel működik. A munkát téglalapok, az adatokat nyilak formájában ábrázolják. Ha bármelyik modellobjektumra kattint a bal egérgombbal, megjelenik egy felugró helyi menü, amelynek minden eleme megfelel az objektum egy tulajdonságának szerkesztőjének.

Az objektumok színének és betűtípusának beállítása. A helyi menü Betűszerkesztő és Színszerkesztő menüpontjai hívják meg a megfelelő párbeszédablakokat a betűtípus (beleértve a méretét és stílusát) és az objektum színének beállításához. Ezenkívül a BPwin lehetővé teszi, hogy beállítsa az alapértelmezett betűtípust bizonyos típusú objektumokhoz a diagramokban és jelentésekben. Ehhez válassza az Eszközök/Alapértelmezett betűtípusok menüt, amely után megjelenik egy lépcsőzetes menü, amelynek minden eleme egy adott típusú objektum betűtípusának telepítésére szolgál:

Kontextus-tevékenység – munka a kontextusdiagramon;

Kontextus nyíl - nyilak a kontextus diagramon;

Dekompozíciós tevékenység – a bomlási diagramon dolgozunk;

Dekompozíciós nyíl - nyilak a bomlási diagramon;

NodeTree Text - szöveg a csomópontfa diagramon;

Frame User Text - a felhasználó által a diagramkeretbe beírt szöveg;

Frame System Text - rendszerszöveg a diagramkeretben;

Szövegblokkok – szövegblokkok;

Szülődiagram szövege - a szülődiagram szövege;

Szülő diagram cím szövege - szülő diagram cím szövege;

Jelentés szövege – jelentés szövege.

IDEF0 módszertan a BPWinben. IDEF0 diagram.

(itt nagyon rosszul van leírva, de ha valaki még nem látta Bpvint, annak hasznos lesz :)

IDEF0 modell építése
Az IS létrehozásának kezdeti szakaszában meg kell érteni, hogyan működik az automatizálni kívánt szervezet. A vezető jól ismeri a munka egészét, de nem tud belemenni az egyes hétköznapi alkalmazottak munkájának részleteibe. Egy hétköznapi alkalmazott jól tudja, mi történik a munkahelyén, de lehet, hogy nem tudja, hogyan dolgoznak a kollégái. Ezért egy vállalkozás munkájának leírásához olyan modellt kell felépíteni, amely megfelel a témakörnek, és tartalmazza a szervezet üzleti folyamatainak összes résztvevőjének tudását.
Az üzleti folyamatok modellezésére a legkényelmesebb nyelv az IDEF0, ahol a rendszer egymással kölcsönhatásban álló feladatok vagy funkciók halmazaként jelenik meg. Ez a tisztán funkcionális orientáció alapvető – a rendszer funkcióit a rendszer függetlenül elemzi azoktól az objektumoktól, amelyekkel működnek. Ez lehetővé teszi a szervezeti folyamatok logikájának és interakciójának egyértelműbb modellezését.
A rendszer modellezésének folyamata az IDEF0-ban egy kontextusdiagram létrehozásával kezdődik - egy diagram a rendszer egészének leírásának legelvontabb szintjéről, amely tartalmazza a modellezés tárgyának meghatározását, a modellezés célját és nézőpontját. modell.
A szubjektum alatt magát a rendszert értjük, és pontosan meg kell határozni, hogy mi szerepel a rendszerben, és mi van a határain kívül, más szóval meg kell határozni, hogy mi lesz a továbbiakban a rendszer alkotóeleme, és mi a külső. befolyás. A rendszer alanyának meghatározását jelentősen befolyásolja az a helyzet, ahonnan a rendszert szemléljük, és a modellezés célja – kérdések, amelyekre a megszerkesztett modellnek válaszolnia kell. Más szóval, először meg kell határozni a modellezési területet. Mind a rendszer egészének, mind annak összetevőinek leírása képezi az alapja a modell felépítésének. Bár feltételezzük, hogy a hatókör a szimuláció előrehaladtával módosítható, kezdetben nagyrészt meg kell határozni, mivel a hatókör határozza meg a szimuláció irányát. A hatókör megfogalmazásakor két összetevőt kell figyelembe venni: a szélességet és a mélységet. A szélesség magában foglalja a modell határainak meghatározását – mi lesz a rendszeren belül és mi az azon kívül. A mélység határozza meg, hogy a modell milyen részletességgel készült. A rendszer mélységének meghatározásakor emlékezni kell az időkorlátokra - a modell felépítésének összetettsége exponenciálisan nő a bomlási mélység növekedésével. A modell határainak meghatározása után feltételezzük, hogy nem kell új objektumokat bevinni a modellezett rendszerbe.
A modellezés célja
A modellezés célját a következő kérdésekre adott válaszok határozzák meg:

• Miért kell ezt a folyamatot modellezni?
• Mit kell mutatnia a modellnek?
• Mit kaphat az ügyfél?

Nézőpont.
A nézőpont arra a perspektívára vonatkozik, amelyből a rendszert megfigyelték a modell felépítésekor. Bár a modell megalkotása során különféle emberek véleményét is figyelembe veszik, mindenkinek egyetlen nézőponthoz kell ragaszkodnia a modellel kapcsolatban. A nézőpontnak összhangban kell lennie a modellezés céljával és terjedelmével. Általában a szimulált munka egészéért felelős személy nézőpontját választják.
Az IDEF0 modell egy világosan megfogalmazott cél, egyetlen modellezési alany és egyetlen nézőpont jelenlétét feltételezi. Ha egy tartományt, célt és nézőpontot szeretne hozzáadni egy IDEF0 modellhez a BPwin rendszerben, válassza a Model/Model Properties menüpontot, amely megnyitja a Modell tulajdonságai párbeszédpanelt. A Cél fülön célt és nézőpontot, a Definíció fülön pedig a modell definícióját és a terület leírását kell megadni.
Ugyanezen párbeszédablak Állapot fülén leírhatja a modell állapotát (vázlat, működő, végleges stb.), a létrehozás és az utolsó szerkesztés időpontját (később a rendszer dátuma szerint automatikusan követi). A Forrás lap leírja a modell felépítéséhez szükséges információforrásokat (például „Témaszakértők felmérése és dokumentáció elemzése”). Az Általános fül a projekt és a modell nevének, a szerző nevének és kezdőbetűinek, valamint a modell időkeretének megadására szolgál - AS-IS és TO-VE.
AS-IS és TO-BE modellek. Általában először a meglévő munkaszervezet modelljét építik fel - AS-IS (ahogy van). A funkcionális modell elemzése lehetővé teszi annak megértését, hogy hol vannak a leggyengébb pontok, mik lesznek az új üzleti folyamatok előnyei, és milyen mélyreható változásokon megy keresztül az üzleti szervezet meglévő struktúrája. Az üzleti folyamatok részletezése lehetővé teszi a szervezet hiányosságainak azonosítását még ott is, ahol a funkcionalitás első pillantásra nyilvánvalónak tűnik. Az AS-IS modellben talált hiányosságok kijavíthatók a TO-BE (ahogy lesz) modell – az üzleti folyamatok új szervezésének modellje – létrehozásakor.
Az IS tervezési technológia magában foglalja először egy AS-IS modell létrehozását, annak elemzését és az üzleti folyamatok fejlesztését, azaz egy TO-BE modell létrehozását, és csak a TO-BE modell alapján készül egy adatmodell, egy prototípus, majd a az IS végleges verziója.
Néha a jelenlegi AS-IS és a jövőbeni TO-BE modellek nagyon különböznek egymástól, így a kezdeti állapotból a végső állapotba való átmenet nem nyilvánvaló. Ebben az esetben egy harmadik modellre van szükség, amely leírja a rendszer kezdeti állapotából a végső állapotba való átmenet folyamatát, mivel az ilyen átmenet is üzleti folyamat.
A modellleírás eredménye a Modell jelentésben érhető el. A modelljelentés beállítására szolgáló párbeszédpanel az Eszközök/Jelentések/Modell jelentés menüpontból hívható meg.
A beállítások párbeszédablakban válassza ki a szükséges mezőket, és automatikusan megjelenik az információk megjelenítési sorrendje a jelentésben.
Az IDEF0 módszertana az üzleti folyamatok leírására szolgáló grafikus nyelven alapul. Az IDEF0 jelölésű modell hierarchikusan rendezett és összekapcsolt diagramok gyűjteménye. Minden diagram a rendszer leírásának egysége, és külön lapon található.
A modell négyféle diagramot tartalmazhat:

• kontextusdiagram (minden modellnek csak egy kontextusdiagramja lehet);
• bomlási diagramok;
• csomópontfa diagramok;
• csak expozíciós (FEO) diagramok.

A kontextusdiagram a diagramok fastruktúrájának teteje, és a rendszer legáltalánosabb leírását és a külső környezettel való interakcióját mutatja be. A rendszer egészének leírása után nagy töredékekre oszlik. Ezt a folyamatot funkcionális dekompozíciónak nevezzük, az egyes fragmentumokat és a fragmentumok kölcsönhatását leíró diagramokat pedig dekompozíciós diagramoknak nevezzük. A kontextusdiagram bontása után a rendszer minden nagy töredéke kisebbre bontja, és így tovább, amíg el nem éri a leírás kívánt részletességi szintjét. Minden bontási ülés után vizsgaülésekre kerül sor - a téma szakértői jelzik a valós üzleti folyamatok megfelelését a létrehozott diagramoknak. A talált ellentmondásokat kijavítjuk, és csak azután, hogy észrevétel nélkül sikeresen letették a vizsgát, kezdődhet a következő bontási munka. Ez biztosítja, hogy a modell megfeleljen a valós üzleti folyamatoknak a modell bármely szintjén. A rendszer egészének és minden egyes töredékének leírására szolgáló szintaxis a modellben ugyanaz.
A csomópontfa diagram a tevékenységek hierarchikus függőségét mutatja, de a tevékenységek közötti kapcsolatokat nem. A modellben tetszőleges számú csomópontfa diagram lehet, mivel a fa tetszőleges mélységig építhető, és nem feltétlenül a gyökérből.
Az expozíciós diagramok (FEO) a modell meghatározott részeit, egy alternatív nézőpont illusztrálására vagy speciális célokra készültek.
Művek (Tevékenység) olyan megnevezett folyamatokat, funkciókat vagy feladatokat jelöl, amelyek egy bizonyos időtartam alatt fordulnak elő, és felismerhető eredménnyel járnak. A művek téglalapként vannak ábrázolva. Minden művet meg kell nevezni és meg kell határozni. A mű nevét egy cselekvést jelző szóbeli főnévként kell kifejezni (például „Vállalati tevékenység”, „Megrendelés átvétele” stb.). A „Vállalati tevékenységek” munka például a következő meghatározással rendelkezhet: „Ez egy olyan oktatási modell, amely egy vállalat tevékenységeit írja le.” Új modell létrehozásakor (Fájl/Új menü) automatikusan létrejön egy kontextusdiagram egyetlen, a rendszer egészét ábrázoló munkával.
Egy feladat nevének megadásához kattintson a jobb gombbal a munkára, válassza a Névszerkesztő menüpontot a menüből, és a megjelenő párbeszédablakban írja be a feladat nevét. A tevékenység egyéb tulajdonságainak leírásához használja a Tevékenység tulajdonságai párbeszédpanelt.
A dekompozíciós diagramok testvértevékenységeket tartalmaznak, vagyis olyan gyermektevékenységeket, amelyeknek közös szülői tevékenységük van. Dekompozíciós diagram létrehozásához kattintson a gombra

az eszköztáron.
Megjelenik az Activity Box Count párbeszédablak, amelyben meg kell adni az új diagram jelölését és a rajta lévő tevékenységek számát. Maradjunk most az IDEF0 jelölésnél, és kattintsunk az OK gombra. Megjelenik a bontási diagram. A művek számának elfogadható tartománya 2-8. Nincs értelme a munkát egy feladatra bontani: a nyolcnál több feladatot tartalmazó diagramok túltelítettek és nehezen olvashatók. A szimulált folyamatok áttekinthetősége és jobb megértése érdekében ajánlatos három-hat blokkot használni egy diagramon.
Ha kiderül, hogy a munkák száma nem elegendő, akkor a munka hozzáadható a diagramhoz úgy, hogy először az eszközpalettán a gombra kattintunk, majd a diagramon egy üres helyre kattintunk.
A bontási diagramokon végzett tevékenységek általában átlósan vannak elrendezve a bal felső saroktól a jobb alsó felé haladva.
Ezt a sorrendet dominancia rendjének nevezzük. Ennek az elrendezési elvnek megfelelően a legfontosabb munka, illetve az előbb elkészülő munka a bal felső sarokba kerül. Jobbra lentebb kevésbé fontos vagy későbbi feladatok találhatók. Ez az elhelyezés megkönnyíti a diagramok olvashatóságát, és a munkakapcsolatok fogalmának alapjául is szolgál (lásd alább).
A bontási diagramon szereplő tevékenységek mindegyike felváltva bontható. A bontási diagramon a munka automatikusan balról jobbra számozásra kerül. A munka száma a jobb alsó sarokban látható. A bal felső sarokban egy kis átlós vonal látható, ami azt jelzi, hogy ez a mű nem került felbontásra. Tehát még nem bontották fel az összes munkát.
A nyilak a munka interakcióját írják le, és néhány főnévvel kifejezett információt jelentenek (például „Ügyfélhívások”, „Szabályok és eljárások”, „Számviteli rendszer”).
Az IDEF0-ban ötféle nyíl létezik:
Bejárat(Bemenet) - olyan anyag vagy információ, amelyet a munka felhasznál vagy alakít át egy eredmény (output) előállítására. Megengedett, hogy a műnek ne legyen egyetlen belépő nyila. Minden nyíltípus megközelíti vagy elhagyja a művet ábrázoló téglalap egy meghatározott oldalát. A belépő nyíl a munka bal szélére kerül. A technológiai folyamatok leírásánál (ezért találták ki az IDEF0-t) nincs probléma a bemenetek azonosításával. Valójában az „Ügyfélhívások” olyan dolgok, amelyeket a „Vállalati tevékenységek” folyamatban dolgoznak fel az eredmény elérése érdekében. IP modellezéskor, amikor a nyilak nem fizikai objektumok, hanem adatok, nem minden olyan nyilvánvaló. Például egy „Betegfogadás” során a páciens kártyája a bemeneten és a kimeneten is lehet, miközben ezen adatok minősége megváltozik. Más szóval, példánkban a cél igazolása érdekében pontosan meg kell határozni a bemeneti és kimeneti nyilakat, amelyek jelzik, hogy az adatok valóban feldolgozásra kerültek (például a kimenet „Befejezett betegfelvétel”). Gyakran nehéz meghatározni, hogy az adatok bemeneti vagy vezérlési jellegűek-e. Ebben az esetben támpontként szolgálhat az arra vonatkozó információ, hogy az adatokat feldolgozták-e/módosították-e a műben vagy sem. Ha változnak, akkor valószínűleg bemenet, ha nem, akkor vezérlés.
Ellenőrzés(Ellenőrzés) – a munkát irányító szabályok, irányelvek, eljárások vagy szabványok. Minden feladatnak rendelkeznie kell legalább egy vezérlő nyíllal. A vezérlő nyíl a munka felső szélébe kerül. A „Szabályok és eljárások” nyílon található a „Vállalati tevékenységek” munka vezérlőeleme. A menedzsment befolyásolja a munkát, de a munka nem alakítja át. Ha egy munka célja egy eljárás vagy stratégia megváltoztatása, akkor ez az eljárás vagy stratégia lesz a munka bemenete. Ha egy nyíl (vezérlő vagy bemenet) állapotában bizonytalanság van, akkor javasolt egy vezérlő nyilat rajzolni.
Kijárat(Kimenet) – egy mű által előállított anyag vagy információ. Minden feladatnak rendelkeznie kell legalább egy kilépési nyíllal. Az eredmény nélküli munkának nincs értelme, és nem szabad modellezni. A kilépő nyíl a munka jobb széléből származik. A "Marketinganyagok" és az "Eladott termékek" nyilak a "Vállalati tevékenységek" munka kimenetei.
Gépezet(Gépezet) - a munkát végző erőforrások, például a vállalati személyzet, gépek, eszközök stb. A mechanizmus nyíl a munka alsó szélén látható módon van megrajzolva. A „Számviteli rendszer” nyílon a „Vállalati tevékenységek” működési mechanizmusa látható. Az elemző belátása szerint előfordulhat, hogy a mechanizmus nyilai nem jelennek meg a modellben.
Hívás(Hívás) - egy másik működési modellre mutató speciális nyíl. A hívó nyíl a mű alsó széléből származik. Az „Egyéb munkamodell” nyíl a „Termékgyártás” munkára hív. A hívó nyíl jelzi, hogy bizonyos munkákat a modellezett rendszeren kívül végeznek. A BPwin-ben a hívó nyilakat a modellek egyesítésére és felosztására szolgáló mechanizmusban használják.
Határ nyilak. A kontextusdiagram nyilai a rendszer és a külvilág közötti interakció leírására szolgálnak. Kezdődhetnek a diagram határán, és befejeződhetnek a munkánál, vagy fordítva. Az ilyen nyilakat határnyilaknak nevezzük.
Határbejegyzési nyíl hozzáadása:

• kattintson a nyíl szimbólumú gombra

• az eszközpalettán mozgassa a kurzort a képernyő bal oldalára, amíg meg nem jelenik a kezdeti szaggatott vonal;
• kattintson egyszer a csíkra (ahonnan a nyíl), majd ismét a mű bal oldalára a bejárati oldalról (ahol a nyíl véget ér);
• térjen vissza az eszközpalettára, és válassza a szerkesztés nyíl lehetőséget

• Kattintson a jobb gombbal a nyílvonalra, válassza a Név menüpontot az előugró menüből, és adja hozzá a nyíl nevét az IDEF0 Arrow Properties párbeszédpanel Név lapjához.

A vezérlő, a bemeneti, a mechanizmus és a kimeneti nyilak hasonlóan vannak ábrázolva. Az újonnan hozzáadott nyilak nevei automatikusan bekerülnek a Nyílszótárba.
ICOM kódok. A bontási diagramot a munka részletezésére tervezték. Ellentétben a szervezet felépítését megjelenítő modellekkel, az IDEF0 legfelső szintű diagramján végzett munka nem az alatta lévő munka ellenőrzése. Az alsó szintű munka megegyezik a felső szintű munkával, csak részletesebben. Következésképpen a felső szintű munka határai megegyeznek a dekompozíciós diagram határaival. Az ICOM (az Input, Control, Output és Mechanism rövidítése) olyan kódok, amelyek a határnyilak azonosítására szolgálnak. Az ICOM kód a nyíl típusának megfelelő előtagot (I, C, O vagy M) és sorozatszámot tartalmaz.
A BPwin automatikusan beírja az ICOM kódokat. Az ICOM kódok megjelenítéséhez engedélyezze az ICOM kódok opciót a Model Properties párbeszédpanel Megjelenítés lapján (Modell/Modell tulajdonságai menü).
Szótár vadász speciális Arrow Dictionary Editor segítségével szerkeszthető, amelyben egy nyíl van definiálva és egy hozzá kapcsolódó megjegyzést írunk be. A nyílszótár egy nagyon fontos problémát old meg. A diagramokat egy elemző készíti el a vizsga lebonyolítása érdekében, azaz a diagram megbeszélése a téma szakértőjével. Bármely témakörben kialakul a szakmai zsargon, és nagyon gyakran a szakzsargon kifejezések nem egyértelmű jelentéssel bírnak, és a különböző szakemberek eltérően érzékelik őket. Ugyanakkor az elemzőnek - a diagramok készítőjének - a szakértők számára leginkább érthető kifejezéseket kell használnia. Mivel a formális definíciók sokszor nehezen érthetők, az elemző kénytelen a szakmai zsargont használni, és a félreérthető értelmezések elkerülése érdekében a nyílszótárban minden fogalom bővített, szükség esetén formális definíciót is kaphat.
A nyílszótár tartalma jelentésként kinyomtatható (Eszközök/Jelentés/Nyíl Jelentés... menü), és megkaphatja a modellben használt tartományi kifejezések magyarázó szótárát.
Nem kapcsolódó határ nyilak (nem összekapcsolt szegélynyíl). Egy mű bontásakor a be- és kilépő nyilak (kivéve a hívó nyilat) automatikusan megjelennek a bontási diagramon (nyilak vándorlása), de nem érintik a műveket. Az ilyen nyilakat unlinkednek nevezik, és szintaktikai hibaként kezelik a BPwinben.
A képen egy bontási diagram töredéke látható össze nem kapcsolt nyilakkal, amelyeket a BPwin generált a munka bontása során "Asztali számítógépek összeszerelése". Egy bemenet, vezérlő vagy mechanizmus nyilai összekapcsolásához lépjen a nyíl szerkesztési módba, kattintson a nyílhegyre, majd a megfelelő munkaszegmensre. Kimeneti nyíl összekapcsolásához be kell lépnie a nyíl szerkesztési módba, kattintson a munka kimeneti szegmensére, majd a nyílra.
Belföldi nyilak. A művek összekapcsolásához belső nyilakat használnak, vagyis azok a nyilak, amelyek nem érintik a diagram határát, az egyiknél kezdődnek, és a másikkal végződnek.
Belső nyíl rajzolásához nyílrajz módban az egyik munka szegmensére (például kilépésre), majd egy másik szegmensére (például bemenetre) kell kattintania. Az IDEF0 ötféle munkakapcsolatot különböztet meg.
Kommunikáció bemeneten keresztül(kimenet bemenet), amikor egy magasabb szintű munka kimeneti nyila (a továbbiakban: egyszerűen kimenet) egy alacsonyabb szintű bemenetére irányul (például a nyílra) "összeszerelt számítógépek"összeköti a műveket és "Szállítás és átvétel").
Vezetői kommunikáció(kimenet-vezérlés) amikor egy magasabb művelet kimenete az alacsonyabb vezérlésére kerül. A vezetői kommunikáció a magasabb szintű munka dominanciáját mutatja. A magasabb szintű munka adatai vagy kimeneti objektumai nem változnak az alsóbb szintű munkában. A nyílon "Vásárlói rendelések" műveket köt össze "Kereskedelem és marketing"És "Számítógépek összeszerelése és tesztelése".
Bejelentkezési visszajelzés(kimenet-bemenet visszacsatolás), amikor egy alacsonyabb szintű mű kimenete egy magasabb szintű bemenetére irányul. Az ilyen összefüggést általában ciklusok leírására használják. A „Teszt eredményei” nyíl összekapcsolja a munkát "Számítógépes tesztelés"És "Ütemezési nyomon követés és építési és tesztelési menedzsment".
Vezetői visszajelzés(kimenet-vezérlés visszacsatolás), amikor az alsóbb szintű munka kimenete a magasabb szintű vezérlésébe kerül ("Összeállítási és tesztelési eredmények" nyíl). A vezetői visszajelzések gyakran jelzik az üzleti folyamatok hatékonyságát. Az értékesítési volumen növelhető a "Számítógépek összeszerelése és tesztelése" című munka számítógépek összeszerelési és tesztelési folyamatainak (kimenet) közvetlen szabályozásával.
Kimeneti-mechanizmus kapcsolat(kimeneti mechanizmus). Ezt a kapcsolatot ritkábban használják, mint másokat, és azt mutatja, hogy egy tevékenység előkészíti a másik tevékenység elvégzéséhez szükséges erőforrásokat.
Kifejezett nyilak. Az explicit nyíl egyetlen job a forrása és egyetlen feladat a cél.
Elágazás és összevonás nyilak. Az egy job által generált ugyanazok az adatok vagy objektumok egyszerre több más jobban is használhatók. Másrészt a különböző művekben generált nyilak ugyanazokat vagy homogén adatokat vagy objektumokat ábrázolhatják, amelyeket egy helyen tovább használnak vagy dolgoznak fel. Az ilyen helyzetek modellezéséhez az IDEF0 elágazó és összevonó nyilakat használ. Egy nyíl elágazásához a nyíl szerkesztési módban kattintson a nyílrészletre és a megfelelő munkarészletre. Két kilépési nyíl egyesítéséhez nyíl szerkesztési módban először kattintson a munka kilépési szegmensére, majd a megfelelő nyílrészletre.
Az elágazó és egyesülő nyilak jelentését a nyilak egyes ágainak elnevezése közvetíti. Vannak bizonyos szabályok az ilyen nyilak elnevezésére. Nézzük meg őket példaként elágazó nyilak segítségével. Ha egy nyíl van elnevezve az elágazás előtt, de az ág után nincs elnevezve ág, akkor a feltételezés szerint mindegyik ág ugyanazokat az adatokat vagy objektumokat modellezi, mint az elágazás előtti ág.
Ha egy nyíl van elnevezve az ág előtt, és az ág után bármelyik ágat is megnevezzük, akkor feltételezzük, hogy ezek az ágak megfelelnek a névadásnak. Ha az ág utáni bármely ág névtelen marad, akkor feltételezzük, hogy ugyanazokat az adatokat vagy objektumokat modellezi, mint az elágazás előtti ág.
Elfogadhatatlan az a helyzet, amikor a nyíl nincs megnevezve az elágazás előtt, és az elágazás után nem nevezik meg bármelyik ágat. A BPwin egy ilyen nyilat szintaktikai hibaként észlel.
Az összevonási nyilak elnevezésének szabályai teljesen hasonlóak – hibának minősül az a nyíl, amelyet nem az egyesülés után neveztek el, és valamelyik ágát nem nevezték el az összevonás előtt. Az elágazó és egyesítő nyilak külön ágának elnevezéséhez csak egy ágat jelöljön ki a diagramban, majd hívja meg a névszerkesztőt, és adjon nevet a nyílnak. Ez a név csak a kiválasztott ághoz fog egyezni.
Nyíl alagút. Az újonnan bevezetett határnyilak szögletes zárójelben jelennek meg az alsó szintű bontási diagramon, és nem jelennek meg automatikusan a felső szintű diagramon.
A tetejére húzáshoz kattintson a jobb gombbal a határoló nyíl szögletes zárójeleire, és válassza ki a Nyíl alagút parancsot a helyi menüben.
Megjelenik a Border Arrow Editor párbeszédablak.
Ha a Resolve Border Arrow gombra kattint, a nyíl a legfelső szintű diagramra vándorol, ha a Change To Tunnel gombra kattint, a nyíl alagútba kerül, és nem kerül másik diagramra. Egy alagút nyíl látható zárójelekkel a végén.
Az alagútképzés használható jelentéktelen nyilak ábrázolására. Ha bármely alsóbb szintű diagramon olyan lényegtelen adatokat vagy objektumokat kell ábrázolni, amelyeket az aktuális szinten nem dolgoz fel vagy használ a munka, akkor azokat magasabb szintre (a szülődiagramba) kell küldeni. Ha ezeket az adatokat nem használja fel a szülődiagramban, akkor még magasabbra kell küldeni stb. Ennek eredményeként egy jelentéktelen nyíl jelenik meg minden szinten, és megnehezíti az összes diagram elolvasását, amelyen megjelenik. A megoldás az, hogy a nyilat a legalacsonyabb szinten alagútba helyezzük. Ezt a fajta alagútvezetést "nem-szülő-diagramnak" nevezik.
Az alagút másik példája lehet az a helyzet, amikor egy mechanizmus nyila egy felső szintről egy alsó szintre vándorol, és az alsó szinten ezt a mechanizmust kivétel nélkül minden munkában egyformán alkalmazzák. (Feltételezzük, hogy nem kell részletezni a mechanizmus nyilat, azaz a gyermekműben a mechanizmus nyíl az elágazás előtt van elnevezve, és az ág után az ágaknak nincs saját neve). Ebben az esetben az alsó szinten lévő mechanizmus nyíl eltávolítható, majd a szülő diagramban alagútba helyezhető, és a nyíl megjegyzés vagy szótár jelezheti, hogy a mechanizmust a gyermek dekompozíciós diagram minden tevékenységében használni fogják. Ezt a fajta alagútvezetést "nem gyermekben"-nek nevezik.
A munkák és diagramok számozása. Minden modellmunka számozott. A szám egy előtagból és egy számból áll. Bármilyen hosszúságú előtag használható, de általában az A előtagot használják. Az A0 bontású i munkák A1, A2, A3 stb. számmal rendelkeznek. Az alacsonyabb szintű bontási munkák a szülőmunka számát és a következő sorszámot tartalmazzák, például az A3 bontású művek A31, A32, AZZ számokat tartalmaznak. , A34, stb. A munkák hierarchiát alkotnak, ahol minden munkának lehet egy szülői és több alárendelt munkája, amelyek egy fát alkotnak. Az ilyen fát csomópontfának, a fent leírt számozást pedig csomópontok szerinti számozásnak nevezzük. Az IDEF0 diagramok kétszer vannak számozva. Először is, a diagramok csomópontonként vannak számozva. A kontextusdiagram mindig A-0 számmal rendelkezik, a kontextusdiagram dekompozíciója az A0, a többi dekompozíciós diagram a megfelelő csomóponthoz tartozó számokat tartalmazza (például A1, A2, A21, A213 stb.). A BPwin automatikusan támogatja a csomópontok szerinti számozást, azaz a felbontás során egy új diagram jön létre, és automatikusan hozzárendeli a megfelelő számot. A vizsgálat eredményeként a diagramok finomíthatók, változtathatók, ezért ugyanannak (csomópontfában elfoglalt helyét tekintve) dekompozíciós diagramnak különböző változatai készíthetők. A BPwin lehetővé teszi, hogy egy adott csomóponton egy modellben csak egy bontási diagram legyen. A diagram korábbi verziói papíralapú másolatként vagy FEO diagramként is tárolhatók. (Sajnos a FEO-diagramok készítésekor nincs visszagörgetési funkció, azaz diagramból FEO-felbontásokat kaphatunk, de fordítva nem.) Mindenesetre meg kell különböztetni ugyanannak a diagramnak a különböző változatait. Erre a célra van egy speciális szám - C-szám, amelyet a modell szerzőjének kézzel kell hozzárendelnie. A C-szám egy tetszőleges karakterlánc, de ajánlatos követni a szabványt, ahol a szám egy betűelőtagból és egy sorszámból áll, előtagként a diagram szerzőjének kezdőbetűit, a sorszámot pedig manuálisan követi. a szerző, például MCB00021.

42. Modellezés ERWinben. Entitások, attribútumok, kapcsolatok.

Az ERwin egy adatbázis-struktúra fejlesztésének eszköze. Az ERwin egyesíti a Windows grafikus felületet, az ER diagramok készítéséhez szükséges eszközöket, az adatmodell logikai és fizikai leírását létrehozó szerkesztőket, valamint a vezető relációs DBMS-ek és asztali adatbázisok átlátható támogatását. Az ERwin segítségével adatbázisokat hozhat létre vagy fejthet vissza.

Az ERwin diagram három fő blokkból épül fel – entitásokból, attribútumokból és kapcsolatokból. Ha egy diagramot egy tárgyterület szabályainak grafikus ábrázolásának tekintünk, akkor az entitások főnevek, a kapcsolatok pedig igék.
A logikai és a fizikai megjelenítési szintek közötti választás az eszköztáron vagy a menün keresztül történik. Ezen szinteken belül a következő megjelenítési módok vannak:
"Entitás" mód - az entitás neve (a logikai modellhez) vagy a táblázat neve (a modell fizikai ábrázolásához) megjelenik a téglalapokon belül; egy nagy diagram áttekintésének kényelmét szolgálja, vagy entitások téglalapjainak elhelyezését szolgálja a diagramon. Az „entitásdefiníciós” mód a diagram bemutatására szolgál másoknak. "Attribútumok" mód. Amikor egy tartományról egy modellre vált át, meg kell adnia az entitásról szóló információkat. Ezt az információt az attribútumok megadásával kell megadni (fizikai szinten - táblázat oszlopai). Ebben a módban a téglalap-entitást egy vonal osztja két részre - az elsődleges kulcsot alkotó attribútumok (oszlopok) a felső részben, a többi attribútum pedig az alsó részben jelennek meg. Ez a mód a fő a logikai és fizikai szintű tervezés során. „Elsődleges kulcsok” mód – az entitások téglalapjain belül csak az elsődleges kulcsot alkotó attribútumok/oszlopok jelennek meg. Ikon mód. Prezentációs célból minden táblázathoz egy ikon (bittérkép) rendelhető. "Ige kifejezések megjelenítése" mód. A linkívek olyan igei kifejezéseket mutatnak, amelyek entitásokat (a logikai réteghez) vagy idegen kulcsneveket (a fizikai réteghez) kapcsolnak össze. Egy diagram egynél több képernyőt és egynél több lapot fedhet le nyomtatáskor. A modell áttekintéséhez a képernyő görgetése mellett a kép kicsinyítésére/nagyítására, a teljes modell megjelenítésére és a modell egy kiválasztott részének megjelenítésére szolgáló módok állnak rendelkezésre.

1. A modellnek tartalmaznia kell egy A-0 kontextusdiagramot, amely csak egy blokkot tartalmaz. Az A-0 kontextusdiagram egyetlen blokkszámának 0-nak kell lennie.
2. A diagramon lévő blokkokat átlósan kell elhelyezni - a diagram bal felső sarkától a jobb alsó sarokig a hozzárendelt számok sorrendjében. A diagramon a bal felső sarokban található blokkok „uralják” a jobb alsó sarokban található blokkokat. A "dominancia" alatt azt a hatást értjük, amelyet egy blokk gyakorol a diagramban szereplő többi blokkra. A blokkok elrendezése a diagramlapon tükrözi a szerző dominanciáról alkotott felfogását. Így a diagram topológiája megmutatja, hogy mely jellemzők vannak nagyobb hatással másokra.
3. A nem kontextuális diagramoknak legalább három és legfeljebb hat blokkot kell tartalmazniuk. Ezek a korlátozások a diagramok összetettségét olyan szinten tartják, hogy könnyen olvasható, érthető és használható legyen. A háromnál kevesebb blokkot tartalmazó diagramok komoly kétségeket vetnek fel a szülőfüggvény lebontásának szükségességével kapcsolatban. A hatnál több blokkot tartalmazó diagramok nehezen érthetők az olvasók számára, és nehézségeket okoznak a szerzőnek, amikor az összes szükséges grafikai objektumot és címkét behelyezi.
4. A nem kontextus diagram minden blokkja kap egy számot, amely a jobb alsó sarokban van elhelyezve; A számozási sorrend a bal felsőtől a jobb alsó blokkig terjed (1-től 6-ig).
5. Minden felbontott blokknak rendelkeznie kell egy gyermekdiagramra mutató hivatkozással; egy hivatkozás (például csomópontszám, C-szám vagy oldalszám) kerül elhelyezésre a blokk jobb alsó sarka alatt.
6. A blokkok (végrehajtott funkciók) és a nyílcímkék nevének egyedinek kell lennie. Ha a nyílcímkék egyeznek, a nyilak azonos adatokat jelentenek.
7. Ha összetett topológiájú nyilak vannak, az azonosítás megkönnyítése érdekében célszerű megismételni a címkét.
8. Maximális távolságot kell biztosítani a blokkok és a nyílfordulatok, valamint a blokkok és a nyilak metszéspontjai között, hogy a diagram könnyebben olvasható legyen. Ugyanakkor csökken a két különböző nyíl összekeverésének valószínűsége.
9. A blokkoknak mindig rendelkezniük kell legalább egy vezérlővel és egy kimeneti nyíllal, de nem lehetnek bemeneti nyilak.
10. Ha ugyanazt az adatot használja a vezérléshez és a bemenethez, akkor csak a vezérlő nyíl jelenik meg. Ez hangsúlyozza az adatok irányító jellegét, és csökkenti a diagram bonyolultságát.
11. A párhuzamos nyilak közötti távolság maximalizálása megkönnyíti a jelölések elhelyezését, leolvasását és lehetővé teszi a nyilak útvonalának követését
12. A nyilak össze vannak kapcsolva (összevonva), ha hasonlót képviselnek
    adatok és forrásuk nincs feltüntetve a diagramon (2. ábra)

    2. ábra – Nyilak összekapcsolva

13. A vezérlés visszajelzését „fel és újra” jelzéssel kell megjeleníteni
    (3. ábra, a):
    3. ábra – Visszajelzések

    A bemeneti visszacsatolásokat „lefelé és alább” jelzéssel kell megjeleníteni (3. ábra, b). A mechanizmuson keresztüli visszajelzések is megjelennek. Ez biztosítja, hogy a visszajelzés minimális számú vonallal és metszésponttal jelenjen meg.

14. Ugyanazon blokk ciklikus visszacsatolásait csak a kiemelés céljából ábrázoltuk. A visszacsatolást általában egy diagramban ábrázolják, amely felbontja a blokkot. Néha azonban szükség van újrafelhasználható objektumok kiosztására (4. ábra)

    4. ábra - Ciklikus visszacsatolások

15. A nyilak akkor vannak kombinálva, ha közös forrásuk vagy céljuk van, vagy kapcsolódó adatokat képviselnek. A közönséges név jobban leírja az adatok lényegét. A blokk mindkét oldalát érintő nyilak számát minimalizálni kell, kivéve persze, ha az adatok természete túlságosan heterogén (5. ábra)

    5. ábra – A nyilak egyesülnek

16. Ha lehetséges, nyilak vannak rögzítve a blokkokhoz ugyanabban a helyzetben. Ekkor az adott típusú nyilak blokkokkal való összekapcsolása következetes lesz, és a diagram olvasása egyszerűsödik

    6. ábra - a nyilak ugyanabban a helyzetben kapcsolják össze a blokkokat

17. Nagyszámú blokk csatlakoztatásakor kerülni kell a nyilak szükségtelen metszéspontját. Az egyes nyilak hurkainak és fordulatainak számát minimálisra kell csökkenteni
    

    

18. A blokkok (függvények) akkor kapcsolódnak egymáshoz a környezeten keresztül, ha kapcsolatban állnak az adatot előállító forrással, anélkül, hogy külön meghatároznák egy külön adatnak a blokkhoz való viszonyát.

    

19. Két vagy több funkció rekordcsatolt, ha adathalmazhoz vannak társítva, és nem feltétlenül függenek attól, hogy az összes lehetséges interfész médiapárként legyen ábrázolva. A 10. ábrán látható interfész típust részesítjük előnyben, mert ez határozza meg az egyes adatelemek kapcsolatát az egyes blokkokkal.

    

20. Szükséges (adott esetben) az elágazó nyilak kifejezőképességét használni

6.2. A SADT módszertan célja és összetétele (IDEF0)

SADT módszertana (Structured Analysis and Design Technique – szerkezeti elemzés és tervezés módszertana) egy rendszer funkcionális modelljének felépítésére szolgáló módszerek, szabályok és eljárások összessége.

Ennek a módszernek a kidolgozása Douglas Ross-szal (USA) kezdődött a 60-as évek közepén. XX század Azóta a SofTech, Inc. rendszerelemzői. továbbfejlesztette a SADT-t, és számos probléma megoldására használta. Telefonos szoftverek, diagnosztika, hosszú távú és stratégiai tervezés, számítógéppel támogatott gyártás és tervezés, számítógépes rendszerkonfiguráció, személyzeti képzés, pénzügyi és logisztikai menedzsment néhány olyan terület, ahol a SADT hatékonyan alkalmazható. A területek széles köre jelzi a SADT módszertan sokoldalúságát és erejét. Az Egyesült Államok Védelmi Minisztériumának integrált számítógépes gyártási (ICAM) programja felismerte a SADT hasznosságát. Ennek eredményeként 1981-ben megjelent egy része, ún IDEF0 (Icam DEFinition), mint a szoftverfejlesztés szövetségi szabványa. Ezen a néven a SADT-t a katonai és ipari szervezetekben dolgozó szakemberek ezrei kezdték használni. Az IDEF0 szabvány legújabb kiadása 1993 decemberében jelent meg. Nemzeti Szabványügyi és Technológiai Intézet (NIST).

Ez a módszertan versenyez az adatfolyam-orientált (DFD) módszerekkel az információs rendszer funkcionális aspektusának leírásában. Ezzel szemben az IDEF0 lehetővé teszi:

Írjon le minden rendszert, ne csak információs rendszert (a DFD a szoftver leírására szolgál);

A végső követelmények meghatározása előtt készítsen leírást a rendszerről és külső környezetéről. Más szóval, ezzel a módszertannal fokozatosan fel lehet építeni és elemezni egy rendszert, még akkor is, ha még nehéz elképzelni a megvalósítását.

Így az IDEF0 számos rendszer felépítésének korai szakaszában használható. Ugyanakkor felhasználható a meglévő rendszerek funkcióinak elemzésére és azok fejlesztésére megoldások kidolgozására.

Az IDEF0 módszertan alapja a folyamatok leírására szolgáló grafikus nyelv. Az IDEF0 jelölésű modell hierarchikusan rendezett és összekapcsolt diagramok gyűjteménye. Minden diagram a rendszer leírásának egysége, és külön lapon található.

A modell (AS-IS, TO-BE vagy SHOULD-BE) tartalmazhat 4 féle diagram [ , ]:

Kontextus diagram;

Bomlási diagramok;

Csomópontfa diagramok;

Diagramok csak expozícióhoz (FEO).

Kontextus diagram (felső szintű diagram), amely a diagramok fastruktúrájának teteje, a rendszer célját (fő funkcióját) és a külső környezettel való interakcióját mutatja. Minden modellnek csak egy kontextusdiagramja lehet. A fő funkció leírása után funkcionális dekompozíciót hajtanak végre, azaz meghatározzák a fő funkciót alkotó funkciókat.

Ezt követően a funkciókat alfunkciókra osztják, és így tovább, amíg el nem érik a vizsgált rendszer szükséges részletességi szintjét. A rendszer egyes ilyen töredékeit leíró diagramokat nevezzük bomlási diagramok . Minden dekompozíció után vizsgaülésekre kerül sor - a téma szakértői jelzik a valós folyamatok megfelelését a létrehozott diagramoknak. A talált inkonzisztenciákat kiküszöböljük, ezután kezdődik a folyamatok további részletezése.

Csomópont fa diagram a függvények (művek) hierarchikus függőségét mutatja, de a köztük lévő kapcsolatokat nem. Ezekből több is lehet, hiszen a fa tetszőleges mélységig és tetszőleges csomópontból felépíthető.

Expozíciós diagramok A modell egyes töredékeinek szemléltetésére épülnek fel, hogy alternatív nézőpontot mutassanak a rendszerben lezajló folyamatokról (például a szervezet vezetése szempontjából).

6.3. IDEF0 grafikus jelölés elemei

Az IDEF0 módszertan széles körű elfogadásra és alkalmazásra talált, elsősorban a modell felépítéséhez használt egyszerű grafikus jelölésnek köszönhetően. A modell fő elemei diagramok. Téglalapok formájában jelenítik meg a rendszerfunkciókat, valamint a köztük lévő és a külső környezet közötti kapcsolatokat nyilakkal. Mindössze két grafikus primitív (téglalap és nyíl) használatával gyorsan elmagyarázhatja az IDEF0 diagramkészítés szabályait és alapelveit azoknak, akik nem ismerik ezt a módszert. Ez az előny lehetővé teszi az ügyfél tevékenységeinek összekapcsolását és aktiválását az üzleti folyamatok leírásában, formális és vizuális grafikai nyelven.

A következő ábra az IDEF0 grafikus jelölés fő elemeit mutatja be.

Rizs. 6.1. IDEF0 grafikus jelölés elemei

A téglalap ábrázolja munka (folyamat, tevékenység, funkció vagy feladat) , amelynek fix célja van és valamilyen végeredményhez vezet. A munka nevének kifejeznie kell a műveletet (például „Alkatrész gyártása”, „Megengedett sebességek kiszámítása”, „3. számú munkaközpont nyilatkozatának elkészítése”).

A művek egymás és a külvilág közötti kölcsönhatása nyilak formájában van leírva. Az IDEF0 megkülönbözteti 5 féle nyíl :

- bejárat (angol bemenet) - olyan anyag vagy információ, amelyet a munka felhasznál és átalakít az eredmény (output) elérése érdekében. A bemenet a „Mit dolgozunk fel?” kérdésre válaszol. A bemenet lehet tárgyi objektum (alapanyag, alkatrész, vizsgakártya), vagy olyan, amelynek nincsenek világos fizikai kontúrjai (adatbázis lekérdezés, tanári kérdés). Megengedett, hogy a műnek ne legyen egyetlen belépő nyila. A beviteli nyilak mindig a munka bal szélére lépve jelennek meg;

- ellenőrzés (angol kontroll) – a munkát irányító ellenőrzési, szabályozó és normatív adatok. A vezetőség válaszol arra a kérdésre, hogy „Mivel összhangban folyik a munka?” A menedzsment befolyásolja a munkát, de nem alakul át általa, azaz. korlátozásként működik. A menedzsment tartalmazhat szabályokat, szabványokat, előírásokat, árakat vagy szóbeli utasításokat. A munka felső szélére belépve a vezérlő nyilak rajzolódnak ki. Ha egy diagram készítése során felmerül a kérdés, hogyan kell helyesen rajzolni egy nyilat felülről vagy balra, akkor ajánlott bemenetként rajzolni (bal oldali nyíl);

- kijárat (angol output) – anyag vagy információ, amely a munka eredményét reprezentálja. A kimenet a „Mi a munka eredménye?” kérdésre válaszol. A kimenet lehet tárgyi tárgy (alkatrész, autó, fizetési bizonylatok, kimutatás), vagy immateriális tárgy (adatmintavétel adatbázisból, kérdés megválaszolása, szóbeli utasítások). A munka jobb széléből kilépő nyilak rajzolódnak ki;

- gépezet (angol mechanizmus) – erőforrások, amelyek elvégzik a munkát. A mechanizmus választ ad arra a kérdésre, hogy „Ki végzi a munkát, vagy min keresztül?” A mechanizmus lehet vállalati személyzet, diák, gép, berendezés vagy program. A mechanizmus nyilai a mű alsó szélébe lépve rajzolódnak;

- hívás (angol hívás) - a nyíl azt jelzi, hogy a munka egy része a kérdéses blokkon kívül történik. A munka alsó széléből kilépő nyilak rajzolódnak ki.

6.4. A munkakörök közötti kapcsolatok típusai

A függvények összetételének és a köztük fennálló kapcsolatoknak a meghatározása után felmerül a kérdés azok helyes összetétele (kombinációja) modulokba (alrendszerekké) Ez azt jelenti, hogy minden egyes funkciónak egy szigorúan meghatározott problémát kell megoldania. Ellenkező esetben a funkciók további bontása vagy szétválasztása szükséges.

A funkciók alrendszerekbe történő kombinálásakor törekedni kell arra, hogy a belső (egy modulon belüli funkciók közötti) kapcsolat a lehető legerősebb, a külső (a különböző modulokban szereplő funkciók közötti) kapcsolat a lehető leggyengébb legyen. A módszertan összefüggéseinek szemantikája alapján bevezetjük a függvények (művek) közötti kapcsolatok osztályozását. Ez a besorolás egy kiterjesztés. A kötések típusait jelentőségük (kötőszilárdság) szerinti csökkenő sorrendben adjuk meg. A megadott példákban vastag vonalak jelzik azokat a funkciókat, amelyek között a vizsgált kapcsolat típusa van.

1. Hierarchikus kapcsolat (kapcsolat „rész” – „egész”) egy függvény és az azt alkotó alfunkciók között zajlik.

Rizs. 6.2. Hierarchikus kapcsolat

2. Szabályozási (ellenőrző, alárendelt) kapcsolat tükrözi az egyik funkció függőségét a másiktól, amikor az egyik munka kimenete egy másik vezérlésére irányul. Azt a funkciót, amelyből a vezetés származik, szabályozónak vagy ellenőrzőnek kell tekinteni, és azt a funkciót, amelybe beletartozik, alárendeltnek kell tekinteni. Megkülönböztetni közvetlen kommunikáció a vezetőséggel , amikor az irányítást egy magasabb munkáról egy alacsonyabbra helyezik át (6.3. ábra), ill vezetői visszajelzés amikor a vezérlés alacsonyabbról magasabbra kerül (6.4. ábra).

3. Funkcionális (technológiai) kapcsolat akkor fordul elő, ha az egyik függvény kimenete a következő függvény bemeneteként szolgál. Az anyagi tárgyak áramlása szempontjából ez a kapcsolat mutatja meg ezen tárgyak feldolgozásának technológiáját (munkasorrendjét). Megkülönböztetni közvetlen bemeneti csatlakozás , amikor a kimenet egy magasabb műveletről egy alacsonyabbra kerül (6.5. ábra), ill bejelentkezési visszajelzés , amikor a kimenet az alacsonyabbról a magasabbra kerül (6.6. ábra).

Rizs. 6.5. Közvetlen csatlakozás bemeneten keresztül	Rizs. 6.6. Bejelentkezési visszajelzés

4. Fogyasztói kommunikáció akkor fordul elő, ha az egyik függvény kimenete a következő funkció mechanizmusaként szolgál. Így az egyik funkció a másik által termelt erőforrásokat fogyasztja.

Rizs. 6.7. Fogyasztói kommunikáció

5. Logikai kapcsolat logikailag homogén függvények között megfigyelhető. Az ilyen funkciók általában ugyanazt a munkát végzik, de különböző (alternatív) módokon vagy különböző bemeneti adatok (anyagok) felhasználásával.

Rizs. 6.8. Logikai kapcsolat

6. Kollégiumi (módszertani) kommunikáció olyan függvények között fordul elő, amelyek működési algoritmusát ugyanaz a vezérlés határozza meg. Az ilyen kommunikáció analógja az egyik osztály alkalmazottainak (kollégák) közös munkája, akik a főnöknek vannak alárendelve, akik utasításokat és parancsokat adnak (vezérlőjelek). Ilyen kapcsolat akkor is felmerül, ha e funkciók működésének algoritmusait ugyanaz a módszertani támogatás (SNIP, GOST, hivatalos szabályozási anyagok stb.) határozza meg, amely ellenőrzésként szolgál.

Rizs. 6.9. Módszeres kapcsolat

7. Erőforrás kapcsolat olyan funkciók között fordul elő, amelyek ugyanazokat az erőforrásokat használják munkájukhoz. Az erőforrás-függő funkciók általában nem hajthatók végre egyszerre.

Rizs. 6.10. Erőforrás kapcsolat

8. Információs kommunikáció olyan függvények között fordul elő, amelyek bemenetként ugyanazt az információt használják.

Rizs. 6.11. Információs kommunikáció

9. Ideiglenes kapcsolat olyan függvények között fordul elő, amelyeket egyidejűleg kell végrehajtani egy másik függvény előtt vagy egyidejűleg utána.

Az ábrán jelzett eseteken kívül ez a kapcsolat a vezérlés, bemenet és mechanizmus más kombinációi között is létrejön, amelyek ugyanabba a funkcióba lépnek.

Rizs. 6.12. Ideiglenes kapcsolat

10. Véletlenszerű kapcsolat akkor fordul elő, ha kevés vagy nincs konkrét kapcsolat a funkciók között.

Rizs. 6.13. Véletlenszerű kapcsolat

A fenti kapcsolattípusok közül a legerősebb a hierarchikus kapcsolat, amely lényegében a funkciók modulokba (alrendszerekké) való kombinációját határozza meg. Valamivel gyengébbek a szabályozási, funkcionális és fogyasztói kapcsolatok. Az ezekkel a kapcsolatokkal rendelkező funkciókat általában egyetlen alrendszerben valósítják meg. A logikai, kollegiális, erőforrás- és információs kapcsolatok a leggyengébbek közé tartoznak. Az ilyen funkciókkal rendelkező függvények általában különböző alrendszerekben kerülnek megvalósításra, kivéve a logikailag homogén függvényeket (logikai kapcsolattal összekapcsolt függvények). Az időbeli kommunikáció a funkciók gyenge egymástól való függését jelzi, és külön modulokban való megvalósítást igényel.

Így a funkciók modulokba való kombinálásakor az első öt típusú kapcsolat a legkívánatosabb. Az utolsó öt kapcsolattal összekapcsolt funkciókat a legjobban külön modulokban lehet megvalósítani.

Az IDEF0 konvenciókkal (szabályokkal és irányelvekkel) rendelkezik a diagramok létrehozására, amelyek célja a modell könnyebb olvashatósága és vizsgálata [ , ]. E szabályok némelyikét a CASE eszközök automatikusan támogatják, míg másokat manuálisan kell végrehajtani.

1. A modell felépítése előtt el kell dönteni, hogy a rendszer melyik modellje(i) készül(nek). Ez azt jelenti, hogy meg kell határozni a típusát AS-IS, TO-BE vagy HOULD-BE, valamint meg kell határozni azt a pozíciót, amelyből a modell épül. A „nézőpont” leginkább egy személy vagy tárgy helye (pozíciója), amelyben az embernek meg kell állnia ahhoz, hogy egy rendszert működés közben lásson. Például egy élelmiszerbolt működési modelljének felépítésénél a lehetséges jelöltek közül választhat egy eladót, pénztárost, könyvelőt vagy igazgatót, amelyik szempontjából a rendszert figyelembe veszik. Jellemzően egy nézőpontot választanak ki, amely a legteljesebben lefedi a rendszer működésének összes árnyalatát, és ha szükséges, egyes bontási diagramokhoz FEO diagramokat készítenek, amelyek egy alternatív nézőpontot jelenítenek meg.

2. A kontextus diagram egy blokkot jelenít meg, amely a rendszer célját mutatja. Ajánlott oldalanként 2-4 be- és kilépő nyilat megjeleníteni.

3. A dekompozíciós diagramokon a blokkok száma 3-6 között javasolt. Ha egy dekompozíciós diagramnak két blokkja van, akkor általában nincs értelme. Ha sok blokk van, a diagram túltelített lesz, és nehezen olvasható.

4. A bontási diagram blokkjait balról jobbra és felülről lefelé kell elrendezni. Ez az elrendezés lehetővé teszi, hogy világosabban tükrözze a munka logikáját és sorrendjét. Ezenkívül a nyilak útvonalai kevésbé lesznek zavaróak, és minimális számú kereszteződéssel rendelkeznek.

5. A vezérlő és a bemeneti nyilak hiánya egy funkcióhoz nem megengedett. Ez azt jelenti, hogy ennek a funkciónak az indítása nem szabályozott, és tetszőleges időpontban megtörténhet, vagy egyáltalán nem.

Rizs. 6.14. Vezérlés és bemenet nélküli működés

A csak vezérléssel rendelkező mondatot egy függvény (eljárás) paraméter nélküli meghívásának tekinthetjük a programban. Ha egy blokknak van bemenete, akkor az egyenértékű egy függvény meghívásával a programban paraméterekkel. Így egy vezérlés és bemenet nélküli blokk egyenértékű egy olyan funkcióval, amelyet soha nem hívunk meg végrehajtásra a programban.

ábrán. 6.7–6.12, IDEF0 diagramok töredékeit megjelenítve, vannak bemenet és vezérlés nélküli blokkok. Ezt nem szabad hibának tekinteni, mivel ezen nyilak egyike ott van.

6. Minden blokknak legalább egy kimenettel kell rendelkeznie.

Rizs. 6.15. Kimenet nélküli funkció

Az eredmény nélküli munkának nincs értelme, és nem szabad modellezni. A kivétel az AS-IS modellben megjelenített művek. Jelenlétük a technológiai folyamatok hatástalanságára és tökéletlenségére utal. A TO-BE modellben ezeknek a tevékenységeknek hiányozniuk kell.

7. Diagramok készítésekor minimalizálni kell a metszéspontok, hurkok és nyilakfordulatok számát.

8. A visszacsatolások és iterációk (ciklikus műveletek) visszaívek segítségével ábrázolhatók. A bemeneti visszacsatolás „alsó” hurokként, a vezérlő visszacsatolás „felső” hurokként van megrajzolva (lásd 6.4 és 6.6 ábra).

9. A diagramokon minden blokknak és minden nyílnak nevet kell adni. A nyilak elágazása (bontása) vagy összevonása (összetétele) megengedett. Ez annak köszönhető, hogy ugyanazok az adatok vagy objektumok, amelyeket egy job generál, több más jobban is használhatók egyszerre. Ezzel szemben a különböző jobok által generált azonos vagy homogén adatok és objektumok ugyanazon a helyen használhatók.

Rizs. 6.16. Elágazó nyilak

Ebben az esetben lehetőség van a nyíl különböző ágaihoz minősítő neveket rendelni az elágazás után (összevonás előtt). Ha valamelyik ágat nem az ágról nevezték el, akkor a nevét az ág elé írt nyíl nevének tekintjük.

Tehát az ábrán. A 6.16. pont szerint az „Alkatrészek gyártása” és „Termék összeállítása” blokkban található vezérlőelemek tisztázó jelentéssel bírnak, és az általánosabb „Rajzok” vezérlőelem szerves részét képezik. Az összes rajz a minőségellenőrzési blokk működtetésére szolgál.

Nem szabad nyilakat rajzolni a diagramra, ha azok nincsenek megnevezve az elágazás előtt és után. ábrán. 6.17 A „Szabványos utasítások generálása” blokkban szereplő nyílnak nincs neve az elágazás előtt és után, ami hiba.

Rizs. 6.17. A nyilak helytelen elnevezése

10. Diagramok készítésekor a jobb olvashatóság érdekében a nyíl alagút mechanizmus használható. Például annak érdekében, hogy a felső szintű (szülő) diagramokat ne zsúfolja össze a szükségtelen részletek, a dekompozíciós diagramokban az ív eleje egy alagútba kerül.

Rizs. 6.18. Nyíl alagút

Ebben a példában, amikor egy újévi buli lebonyolítására szolgáló modellt építünk, a „két tengely” mechanizmus nem jelenik meg a felső szintek diagramjain, aminek olvasása során jogos kérdés merülhet fel: „Miért van szükség két tengelyre Újévi buli?”

Hasonlóképpen az alagút az ellenkező céllal, hogy megakadályozza a nyíl megjelenését az alacsonyabb szintű diagramokon. Ebben az esetben zárójelek kerülnek a nyíl végére. A kontextusdiagramban (lásd a 6.21. ábrát) a „Megengedett sebességek meghatározása” blokkban található „Track Service Engineer” mechanizmus alagúttal van ellátva. Ez a döntés azért született, mert a mérnök közvetlenül részt vesz a blokk bontási diagramján látható összes munkában (lásd 6.22. ábra). Annak érdekében, hogy ez az összefüggés ne jelenjen meg, és ne zavarja a bomlási diagramot, a nyilat alagútba vezettük.

11. Minden blokkba belépő és kilépő nyilat fel kell tüntetni a blokkba való bontási diagram készítésekor. Ez alól kivételt képeznek az alagútnyilak. A bontási diagramra átvitt nyilak nevének meg kell egyeznie a legfelső szintű diagramon feltüntetett nevekkel.

12. Ha két nyíl párhuzamosan fut (az egyik mű ugyanazon lapjáról indul, és egy másik mű ugyanazon lapján végződik), akkor lehetőség szerint kombinálni kell őket, és egyetlen tagnak nevezni.

Rizs. 6.19. Kapcsolatok összevonása

13. A diagramokon minden blokknak saját számmal kell rendelkeznie. A diagramszámok bármely diagram vagy blokk pozícióját jelzik a hierarchiában. A legfelső szintű diagramon a blokkokat 0, a második szintű diagramok blokkjait 1-től 9-ig (1, 2, ..., 9) jelölő számok, a harmadik szinten lévő blokkokat két szám jelzi, amelyek közül az első jelzi a részletező blokk számát a szülődiagramból, a második blokkszámot pedig sorrendben az aktuális diagramon (11, 12, 25, 63), stb. A kontextusdiagram jelölése „A - 0”, a dekompozíciós diagram az első szint „A0”, a következő szintek bontási diagramja „A” betűvel, majd a felbontandó blokk számával van jelölve (például „A11”, „A12”, „A25”, „ A63"). Az ábra egy tipikus fadiagramot (csomópontfa diagram) mutat számozással.

Rizs. 6.20. Diagram hierarchia

A modern CASE eszközökben a munkaszámozási mechanizmusok automatikusan támogatottak. A CASE eszközök olyan csomópontfa diagramok automatikus felépítését is biztosítják, amelyek csak hierarchikus kapcsolatokat tartalmaznak. Egy ilyen diagram csúcsa tetszőleges csomópont (blokk) lehet, és tetszőleges mélységig beépíthető.

6.6. Példa IDEF0 modell felépítésére a megengedett sebességeket meghatározó rendszerhez

A megengedett vonatsebesség kiszámítása munkaigényes mérnöki feladat. Amikor egy vonat elhalad bármely szakaszon, a vonat tényleges sebessége nem haladhatja meg a megengedett legnagyobb sebességet. Ezt a megengedett legnagyobb sebességet az üzemeltetési tapasztalatok, valamint a mozgásdinamikai és a gördülőállomány pályájára gyakorolt ​​hatások speciális vizsgálatai alapján határozzák meg. Ennek a sebességnek a nem túllépése garantálja a vonatközlekedés biztonságát, az utasok kényelmes utazási feltételeit stb. Ezeket a gördülőállomány típusától (mozdony márkája és kocsitípusa), a pálya felső szerkezetének paramétereitől (a pálya típusától) függően határozzák meg. sínek, ballaszt, talpfák diagramja) és tervrajz (sugárgörbék, átmeneti ívek, külső sínmagasságok stb.). A megengedett sebességek megállapításához általában legalább két (egyenes vonalon) és öt (kanyarban) sebességet kell meghatározni, amelyek közül a végső megengedett sebességet a legalacsonyabbnak kell kiválasztani az összes számított sebesség közül. Ezeknek a sebességeknek a kiszámítását az Oroszországi Vasúti Minisztérium 2001. november 12-i 41. számú, „A Szövetségi Vasúti Közlekedés 1520 (1524) mm-es nyomtávú vasúti gördülőállomány megengedett sebességére vonatkozó normák” című rendelete szabályozza.

Mint már említettük, az IDEF0 modell felépítése a teljes rendszer egyszerű komponens (kontextusdiagram) formájában történő ábrázolásával kezdődik. Ez a diagram a rendszer célját (fő funkcióját) és a szükséges bemeneti és kimeneti adatokat, vezérlési és szabályozási információkat, valamint mechanizmusokat jeleníti meg.

A megengedett sebességek meghatározásának problémájának kontextusdiagramja a 6.21. ábrán látható. A modell elkészítéséhez a Computer Associates BPwin 4.0 termékét használták.

Rizs. 6.21. A megengedett sebességeket meghatározó rendszer kontextusdiagramja (IDEF0 módszertan)

Mint háttér-információ, amely alapján a megengedett sebességeket meghatározzák, a következőket kell használni:

Projektadatok egy új vonalhoz vagy rekonstrukciós projekthez (tartalmazza a projekt megvalósításához szükséges összes információt, nevezetesen a futásteljesítményt, a különálló pontok tengelyeit, vonaltervet stb.);

Részletes hosszanti profil (a fent tárgyalthoz hasonló információkat tartalmaz);

A pálya távolságának útlevele (a fent tárgyalthoz hasonló információkat tartalmaz, valamint a pálya felépítményére vonatkozó információkat (VSP));

Adatok a pályaterv pályamérő kocsival végzett felmérésének eredményeiről;

A kanyarokban lévő külső sínmagasságok listája (információkat tartalmaz a pályatervről).

A háttérinformációk egy része különböző forrásokból származhat. A tervvel kapcsolatos információk (ívparaméterek) különösen új vonal vagy rekonstrukciós projekt tervezéséből, részletes hosszprofilból, nyomtávolság-igazolásból stb.

Adatok ellenőrzése vannak:

A számításhoz a közúti pályaszolgálat vezetőjének vagy a JSC Orosz Vasutak Pályázati és Szerkezeti Osztályának utasítása;

41. számú rendelet, amely szabályozási és referencia információkat, eljárásokat és képleteket tartalmaz a megengedett sebességek meghatározására;

Információk az aktuális vagy tervezett vonatforgalomról (adatok a forgalomban lévő mozdonymárkákról és a használt kocsitípusokról);

Tájékoztatás a tervezett pályajavításokról, műtárgyak és eszközök rekonstrukciójáról, rekonstrukciójáról.

Az eredmény a rendszer működésének a következőnek kell lennie:

A megengedett sebességek listája, amely tartalmazza a számított sebességek minden típusát, és lehetővé teszi a korlátozás okának megállapítását;

A szakaszokon és különálló pontokon megengedett sebességek megállapításáról szóló útvezetői rendelet lapjai ("N" végzés) az úton elfogadott formanyomtatvány szerint. A jóváhagyott „N” rendelet hivatalosan meghatározza a vonatok megengedett sebességét;

1., 1a. és 2. számú szabványos nyomtatvány, amely tartalmazza a tervezett megengedett sebességeket a vonatok menetrendjének kialakításához.

Az „N” rendelésben és a szabványos nyomtatványokban szereplő sebességek eltérhetnek a megengedett sebességlapokon számítottaktól és feltüntetettektől. Ez annak köszönhető, hogy nem csak a gördülőállomány kialakításán, a VSP paramétereken és íveken, hanem az eszközök és szerkezetek állapotán is tükrözik a sebességkorlátozásokat (az útalap deformációja, a felső érintkezőhálózat tartóinak eltolódása stb.). ). Ezen túlmenően kiigazításra kerülnek a tervezett pályajavítások, műtárgyak és eszközök rekonstrukciója, rekonstrukciója stb.

A felépítés után a kontextusdiagram részletezésre kerül egy első szintű bontási diagram segítségével. Ez a diagram azokat a rendszerfunkciókat jeleníti meg, amelyeket az alapfunkción belül meg kell valósítani. Azt a diagramot, amelyre a dekompozíciót elvégezték, az azt részletező diagramokhoz képest ún szülői . A szülőjére vonatkozó dekompozíciós diagramot nevezzük leányvállalat .

A vizsgált probléma első szintű dekompozíciós diagramja a 6.22. ábrán látható. A dekompozíciós diagram elkészítésekor az eredeti függvényt (felbontva) általában 3-8 részfüggvényre (blokkra) osztják. Ebben az esetben a bontási diagramon javasolt a blokkokat balról jobbra, fentről lefelé rendezni, hogy jobban látható legyen az alfunkciók egymásra hatásának sorrendje és logikája.

Rizs. 6.22. Első szintű bontási diagram (IDEF0 módszertan)

A vizsgált probléma megoldására szolgáló funkciók végrehajtási sorrendje a következő:

Az útszakaszokra vonatkozó szabályozási és referencia információk és adatok bevitele és módosítása (1. és 2. blokk);

Számítási feladat elkészítése (3. blokk). Jelzi, hogy melyik szakaszra és vágányra, valamint a mozdony márkájára és az autók típusára vonatkozóan kell elvégezni a számítást;

A megengedett sebességek kiszámítása a 41. számú rendeletben (4. rovat) meghatározott eljárás és képlet szerint. A kiinduló információ a szakasz nyomvonalára vonatkozó adatok (pálya terv, felépítmény stb.) és a számítási feladat alapján kiválasztott szabványok;

A megengedett sebességek listáinak összeállítása (5. blokk). A számítási eredmények alapján többféle kimeneti bizonylat készül, amelyek egyrészt lehetővé teszik a sebességkorlátozás okának azonosítását, másrészt a szabályozott dokumentumok elkészítésének alapjául szolgálnak;

Az „N” rendelettervezet és a szabványos nyilatkozatok megalkotása és elkészítése (6. és 7. blokk).

Az első szintű dekompozíciós diagram elkészítése után a rajta feltüntetett függvényekhez külön diagramok készülnek (második szintű dekompozíciós diagramok). Ezután a dekompozíció (diagramozás) folyamata addig folytatódik, amíg a függvények további részletezése értelmetlenné válik. Minden egyes elemi műveletet leíró atomi függvényhez (vagyis olyan függvényhez, amely nem rendelkezik lebontási diagrammal) egy részletes specifikációt állítanak össze, amely meghatározza annak jellemzőit és megvalósítási algoritmusát. Algoritmus-folyamatábrák használhatók a specifikáció kiegészítéseként. Így a funkcionális modellezés folyamata a funkciók hierarchiájának fokozatos felépítéséből áll.

6.7. ICOM kódok

A felső szintű diagramban a blokkba be- és kimenő nyilak megegyeznek az alacsonyabb szintű diagramok blokkjából ki- és bemenő nyilakkal, mert a doboz és a diagram ugyanazt a rendszerrészt ábrázolja (lásd 1. ábra). és ). Következésképpen a legfelső szintű függvény határai megegyeznek a dekompozíciós diagram határaival.

ICOM kódok (az Input, Control, Output és Mechanizmus rövidítése) a határnyilak azonosítására szolgálnak. Az ICOM kód a nyíl típusának megfelelő előtagot (I, C, O vagy M) és sorozatszámot tartalmaz (lásd az ábrát).