În continuare, vom lua în considerare metodele standard de analiză structurală a sistemului descrise de o serie de standarde federale din SUA „ Definiția Icam", în conformitate cu . Informații detaliate despre toate standardele din această serie pot fi găsite la http://www.idef.com.

Standard IDEF0(FIPS183) este destinat să creeze un model funcțional care descrie structura și funcțiile unui sistem, precum și fluxurile de informații și obiecte materiale care conectează aceste funcții. Acest document este un design (la inițiativa Departamentului de Apărare al SUA) sub forma unui standard tehnologic pentru analiza sistemelor complexe SADT(Structured Analysis and Design Technique), dezvoltat de un grup de analiști americani condus de Douglas Ross în 1973.

Metoda propusă de standardul IDEF0 este destinată modelării funcționale, adică modelării performanței funcțiilor unui obiect, prin realizarea unui model grafic descriptiv care să arate ce, cum și de către cine se realizează în cadrul funcționării întreprinderii. Un model funcțional este o reprezentare structurată a funcțiilor unui sistem sau mediului de producție, a informațiilor și a obiectelor care conectează aceste funcții. Modelul este construit folosind metoda de descompunere: de la structuri mari compozite la cele mai mici, mai simple. Elementele fiecărui nivel de descompunere reprezintă acțiuni de prelucrare a informațiilor sau a resurselor materiale în anumite condiții folosind mecanisme specificate. Fiecare acțiune este descompusă în operațiuni mai mici de prelucrare a unei anumite părți a informațiilor sau a resurselor materiale în anumite condiții folosind o parte din mecanismele specificate. Operațiunile sunt prezentate într-un mod similar. Ultimul pas de descompunere ar trebui să aibă ca rezultat un model al cărui nivel de detaliu satisface cerințele specificate chiar la începutul procesului de creare a modelului.

Metodologia IDEF0 se bazează pe următoarele principii:

1. Sistem și model. Un model este un obiect artificial care este o reprezentare (imagine) a unui sistem și a componentelor sale. M modele A, Dacă M răspunde la întrebări referitoare la A. Aici M- model, A– obiect modelat (original). Modelul este dezvoltat pentru a înțelege, analiza și lua decizii cu privire la reconstrucția (reproiectarea) sau înlocuirea unui sistem existent sau proiectarea unui nou sistem. Un sistem este o colecție de părți interconectate și care interacționează care efectuează unele lucrări utile. Părțile (elementele) unui sistem pot fi orice combinație de diferite entități, inclusiv oameni, informații, software, echipamente, produse, materii prime sau energie. Modelul descrie ce se întâmplă în sistem, cum este controlat, ce entități transformă, ce instrumente folosește pentru a-și îndeplini funcțiile și ce produce.

2. Modelarea blocurilor și reprezentarea sa grafică. Principiul conceptual principal al metodologiei IDEF este reprezentarea oricărui sistem studiat ca un set de blocuri interconectate și interconectate care afișează procesele, operațiunile și acțiunile care au loc în sistemul studiat. În IDEF0, tot ceea ce se întâmplă în sistem și elementele sale se numește funcții. Fiecărei funcții i se atribuie un bloc. Pe o diagramă IDEF0 (numită mai des diagramă SADT), documentul principal în analiza și proiectarea sistemelor, blocul este un dreptunghi. Interfețele prin care un bloc interacționează cu alte blocuri sau cu mediul extern sistemului care se modelează sunt reprezentate de săgeți care intră sau ies din bloc. Săgețile de intrare indică condițiile care trebuie îndeplinite simultan pentru ca funcția descrisă de bloc să apară.

3. Rigurozitate și formalism. Dezvoltarea modelelor IDEF0 necesită aderarea la o serie de reguli formale stricte care asigură beneficiile metodologiei în ceea ce privește neambiguitatea, acuratețea și integritatea modelelor complexe pe mai multe niveluri. Aceste reguli sunt descrise mai jos în ceea ce privește tehnologia SADT. Aici se notează doar cea principală: toate etapele și etapele dezvoltării și ajustării modelului trebuie să fie strict, formal documentate, astfel încât în ​​timpul funcționării acestuia să nu apară întrebări legate de incompletitudinea sau incorectitudinea documentației.

4. Modelare iterativă. Dezvoltarea modelului în IDEF0 este o procedură iterativă pas cu pas. La fiecare pas de iterație, dezvoltatorul propune o versiune a modelului, care este supusă discuției, revizuirii și editării ulterioare, după care ciclul se repetă. Această organizare a muncii contribuie la utilizarea optimă a cunoștințelor unui analist de sisteme care este competent în metodologia și tehnica IDEF0, precum și cunoștințele specialiștilor - experți în domeniul căruia îi aparține obiectul de modelare.

5. Separarea „organizației” de „funcții”. La elaborarea modelelor, trebuie evitat inițial „legarea” funcțiilor sistemului studiat de structura organizatorică existentă a obiectului modelat (întreprindere, firmă). Acest lucru ajută la evitarea unui punct de vedere subiectiv impus de organizație și managementul acesteia. Structura organizatorică trebuie să fie rezultatul utilizării (aplicarii) modelului. Compararea rezultatului cu structura existentă permite, în primul rând, evaluarea adecvării modelului, iar în al doilea rând, propunerea de soluții care vizează îmbunătățirea acestei structuri.

Exemple de probleme rezolvate pe baza metodologiei de modelare IDEF0:

Analiza si reinginerirea proceselor de afaceri.

Dezvoltarea unui sistem informatic pentru managementul calitatii datelor.

Elaborarea de reglementări și proceduri pentru asigurarea calității produselor și crearea sistemelor de prelucrare a datelor de calitate. Modelul funcțional vă permite să înlocuiți manualele tradiționale de calitate sub formă de documente de tip text descriptiv pe hârtie cu modele electronice standardizate, a căror integritate și consistență este menținută automat. Dacă este necesar, puteți obține întotdeauna un raport pe hârtie de la ei în forma obișnuită.

Proiectarea infrastructurii informaționale, procedurilor și reglementărilor pentru interacțiunea informațională.

Sarcini de analiză a riscurilor în ceea ce privește securitatea informațiilor.

Să luăm în considerare, în conformitate cu lucrarea, principiile construcției diagramelor folosind tehnologia SADT (IDEF0).

Limbajul grafic al SADT este simplu și armonios. Metodologia se bazează pe patru concepte principale.

Primul dintre acestea este conceptul „ bloc funcţional" Un bloc funcțional este reprezentat grafic ca un dreptunghi (vezi Fig. 3.23) și reprezintă o funcție specifică în cadrul sistemului luat în considerare. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în starea verbală (de exemplu, „ produce servicii", dar nu " producerea de servicii"). Fiecare dintre cele patru laturi ale blocului funcțional are propriul său sens specific (rol), în timp ce: partea de sus are semnificația „ Control" (cont r ol); partea stângă are sensul " Intrare» ( intrare); partea dreaptă înseamnă " Ieșire» ( ieșire); partea de jos înseamnă " mecanism» ( mecanism). Fiecare bloc funcțional dintr-un singur sistem luat în considerare trebuie să aibă propriul său număr de identificare unic.

16 septembrie 2010 13:08

„Divide et impera”
Maxima Senatului Roman

Era 1981, Forțele Aeriene ale SUA dezvoltau un program de automatizare industrială, care se numea ICAM (Fabricare integrată asistată de calculator). Pentru derularea cu succes a proiectului, a fost necesar ca toți participanții să poată simula o întreprindere automatizată în paralel. Un set de standarde a fost dezvoltat special pentru aceste scopuri IDEF (DEFINIȚIA ICAM). Unul dintre standardele stabilite a fost o notație de modelare funcțională cu nume de cod IDEF0, care a fost ușor modificat de-a lungul timpului, iar specificația pentru cea mai recentă versiune a fost lansată în decembrie 1993.
Vă voi spune puțin despre caracteristicile procesului de modelare funcțională a unui proces de afaceri folosind notație IDEF0și în același timp îl voi ajuta pe Aristarkh Grigorievich, pe care l-am menționat în articolul anterior: voi descrie procesul de afaceri de preparare a borșului.

Modelarea funcțională începe prin identificarea sarcinii principale care se rezolvă prin executarea acestui proces de afaceri. În cazul nostru, această sarcină este formulată după cum urmează: „Pregătiți borșul”. Mi se pare că este mai eficient să începem procesul de modelare determinând ce date și materiale avem înainte de a executa procesul de afaceri (Input), precum și înțelegerea clară a ceea ce dorim să obținem ca urmare a executării procesului de afaceri ( Ieșire / Ieșire). Acest lucru va face posibilă identificarea cerințelor clare pentru procesul de afaceri și eliminarea speranțelor nerealiste: având doar o mână de pietre de origine dubioasă, este imposibil să obțineți lingouri de aur. În cazul pregătirii borșului, există, de exemplu, legume și carne la intrare (desigur, ele pot să nu fie acolo, dar să presupunem că toate produsele au fost achiziționate cu prudență). La ieșire ar trebui logic să luăm borș.

Notația IDEF0 presupune, de asemenea, că pentru a realiza modelarea funcțională este necesar să se identifice așa-numitul mecanism (mecanism), adică. acelor interpreți care vor fi implicați în procesul de afaceri. În exemplul nostru, mecanismul este însuși Aristarkh Grigorievich și, să zicem, fiul său cel mare Kolya. Execuția corectă a procesului trebuie să fie controlată de ceva (unele standarde, metode, tehnologii etc.). Acest lucru în notația IDEF0 se numește „control” și trebuie să apară pe diagrama funcțională.

Odată ce analistul de afaceri a identificat intrările și ieșirile și a stabilit mecanismul și controalele, toate aceste informații pot fi rezumate într-o primă diagramă numită diagramă de context. Va arăta ca în Figura 1.

Orez. 1. Diagrama de context

Scopul principal al unei diagrame de context este de a identifica sarcina principală, singura și singura funcție pe care execuția unui proces de afaceri o rezolvă. O diagramă de context este deosebit de importantă atunci când punem împreună o vedere generală a problemei de afaceri care se rezolvă: de ce avem nevoie și în ce cantitate, ce vom obține ca rezultat, cine este implicat în procesul de afaceri, ce documente de reglementare avem nevoie pentru a rezolva corect problema.

O diagramă de context nu oferă o vedere completă a procesului, ci doar o vedere generală. Pentru a vizualiza secvența procesului, trebuie să rotiți roata microscopului: descompuneți diagrama, adică. oferiți o descriere puțin mai detaliată a procesului. Întotdeauna mi-a fost mai convenabil să împart o sarcină generală gigantică în 4-5 altele mai mici, cu aproximativ același nivel de detaliu. Aceste sarcini pot fi fie secvențiale, fie paralele în timpul executării lor. De exemplu, în cazul pregătirii borșului, aceste sarcini se rezumă la: pregătirea bulionului, pregătirea legumelor, de fapt gătitul și servirea preparatului. Este clar că puteți pregăti bulionul și legumele în același timp, dar servirea borșului înainte de a fi asezonat va ieși prost. Să obținem o diagramă, de exemplu, ca cea prezentată în Figura 2.

Orez. 2. Diagrama de descompunere a primului nivel

În același mod, puteți descompune fiecare dintre aceste mici funcții până când este atins nivelul necesar de detaliu.

Văd un avantaj foarte mare al descompunerii în faptul că, atunci când descrieți un proces tehnologic greu, de exemplu, puteți indica un întreg atelier, de exemplu, un atelier de turnare, ca principal executant al procesului în diagrama de context și apoi selectați echipe individuale, de exemplu, pe diagrama de descompunere acest atelier, responsabile pentru o direcție sau alta în execuția procesului. Este deosebit de important ca pentru fiecare bloc de descompunere, la fel ca întreaga diagramă de context în ansamblu, să fie indicate atât datele de intrare, cât și datele de ieșire. Acestea. putem controla fluxul de resurse, distribuindu-le, reducându-le în unele locuri, mărindu-le în altele, putem înțelege că este necesar să amânăm o parte din muncă, deoarece, de exemplu, nu este posibil să folosim aceeași mașină în același timp. În colțul din stânga jos al blocurilor de descompunere este indicat costul aproximativ al efectuării unei operații, ceea ce vă permite să evidențiați operațiunile mai costisitoare care ar trebui elaborate mai detaliat. Și invers: sarcinile mici sunt mai ușor de evaluat decât cele mari. După ce a găsit costul finalizării fiecăreia dintre sarcinile mici, costul sarcinii mari poate fi calculat prin simpla adunare a costurilor sarcinilor mici.

Marele dezavantaj al notației IDEF0 este, în opinia mea, că nu reflectă bine și, în general, deloc, reacția participanților la proces la evenimentele de mediu. Prin urmare, este imposibil să se evalueze riscurile asociate cu schimbările din mediul extern și, de asemenea, este imposibil să se modeleze opțiunile de rollback. De aceea, în opinia mea, notația IDEF0 este perfect potrivită pentru a descrie nu procese de afaceri, ci procese tehnologice în care influența mediului este exclusă, deoarece operațiunile se desfășoară conform planului. Nu pot fi excluse, desigur, avariile echipamentelor. Dar, dacă te gândești bine, defecțiunea echipamentului duce doar la necesitatea reparației sau a schimbării echipamentului. În cele mai multe cazuri, acest lucru are ca rezultat fie o întârziere, fie anularea procesului la o anumită etapă, dar nu o retrocedare (imaginați-vă cum, atunci când un cuptor se defectează, cărămizile se dezintegrează din nou în nisip și lut), în timp ce atunci când apar situații excepționale într-o afacere. mediu, În cele mai multe cazuri, sunt necesare acțiuni de rollback. Acesta este motivul pentru care notația IDEF0 pare mai potrivită pentru descrierea proceselor tehnologice.

În episoadele următoare veți găsi povești interesante despre notațiile BPMN, EPC și UML.

(4,77 - evaluat de 43 de persoane)

Scopul lucrării:

• studierea principiilor de bază ale metodologiei IDEF0,
• crearea unui nou proiect în BPWin,
• formarea unei diagrame de context,
• a face legături.

Descrierea unui sistem care utilizează IDEF0 se numește model funcțional. Modelul funcțional este conceput pentru a descrie procesele de afaceri existente, care utilizează atât limbaje naturale, cât și limbaje grafice. Pentru a transmite informații despre un anumit sistem, sursa limbajului grafic este însăși metodologia IDEF0.

Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor sistemului. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii sale cu lumea exterioară (diagrama contextului), după care se efectuează o descompunere funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris separat (diagrame de descompunere) . Fiecare subsistem este apoi împărțit în altele mai mici și așa mai departe, până când este atins nivelul dorit de detaliu.

Fiecare Diagramele IDEF0 a conține blocuri și arce. Blocurile descriu funcțiile sistemului modelat. Arcurile leagă blocurile între ele și reprezintă interacțiunile și relațiile dintre ele.

Blocurile funcționale (lucrul) din diagrame sunt reprezentate prin dreptunghiuri, reprezentând procese, funcții sau sarcini numite care apar într-o perioadă de timp și au rezultate recunoscute. Numele lucrării trebuie exprimat ca un substantiv verbal care denotă acțiunea.

IDEF0 necesită ca diagrama să aibă cel puțin trei și nu mai mult de șase blocuri. Aceste constrângeri mențin complexitatea diagramelor și modelului la un nivel care este lizibil, înțeles și utilizabil.

Fiecare parte a blocului are un scop special, foarte specific. Partea stângă a blocului este pentru intrări, partea de sus este pentru control, dreapta este pentru ieșiri, iar partea de jos este pentru mecanisme. Această desemnare reflectă anumite principii de sistem: intrările sunt convertite în ieșiri, limitele de control sau prescriu condițiile pentru efectuarea transformărilor, mecanismele arată ce și cum funcționează o funcție.

Blocurile din IDEF0 sunt plasate în ordinea importanței, așa cum a înțeles autorul diagramei. Această ordine relativă se numește dominanță. Dominanța este înțeleasă ca influența pe care o are un bloc asupra altor blocuri din diagramă. De exemplu, cel mai dominant bloc al diagramei poate fi fie primul dintr-o secvență de funcții cerută, fie o funcție de planificare sau control care le influențează pe toate celelalte.

Blocul cel mai dominant este de obicei plasat în colțul din stânga sus al diagramei, iar blocul cel mai puțin dominant este în colțul din dreapta.

Dispunerea blocurilor pe pagină reflectă definiția autorului a dominației. Astfel, topologia diagramei arată care caracteristici au un impact mai mare asupra altora. Pentru a sublinia acest lucru, analistul poate renumerota blocurile în funcție de ordinea lor de dominanță. Ordinea dominantei poate fi indicata printr-un numar plasat in coltul din dreapta jos al fiecarui dreptunghi: 1 ar indica cea mai mare dominatie, 2 urmatorul etc.

Interacțiunea lucrărilor cu lumea exterioară și între ele este descrisă sub formă de săgeți, reprezentate ca linii unice cu săgeți la capete. Săgețile reprezintă unele informații și se numesc substantive.

Tipuri de săgeți

IDEF0 distinge între cinci tipuri de săgeți.

Intrare- obiecte folosite și transformate prin muncă pentru a obține un rezultat (ieșire). Este permis ca lucrarea să nu aibă o singură săgeată de intrare. Săgeata de intrare este desenată ca intrând în marginea stângă a lucrării.

Control-.informaţii care controlează acţiunile lucrării. De obicei, săgețile de control poartă informații care indică ceea ce ar trebui să facă un loc de muncă. Fiecare job trebuie să aibă cel puțin o săgeată de control, care este descrisă ca intrând în marginea superioară a jobului.

Ieșire- obiecte în care sunt convertite intrările. Fiecare job trebuie să aibă cel puțin o săgeată de ieșire, care este desenată ca emanând din marginea dreaptă a jobului.

Mecanism- resursele care execută munca. Săgeata mecanismului este desenată ca intrând în marginea inferioară a lucrării. La discreția analistului, săgețile mecanismului pot să nu fie reprezentate pe model.

Apel- o săgeată specială care indică un alt model de operare. Săgeata de apel este desenată ca venind din partea de jos a lucrării și este folosită pentru a indica faptul că unele lucrări sunt efectuate în afara sistemului care este modelat.

Orez. 2.1 Tipuri de săgeți

Metodologia IDEF0 necesită doar cinci tipuri de interacțiuni între blocuri pentru a descrie relațiile lor: control, intrare, feedback de control, feedback de intrare, mecanism de ieșire. Conexiunile de control și intrare sunt cele mai simple, deoarece reflectă influențe directe intuitive și foarte simple.

Orez. 2.2. Comunicare de ieșire

Orez. 2.3. Comunicarea managementului

O relație de control apare atunci când ieșirea unui bloc afectează direct blocul mai puțin dominant.

Feedback-ul de control și feedback-ul de intrare sunt mai complexe deoarece implică iterație sau recursivitate. Și anume, rezultatele unui job influențează execuția viitoare a altor joburi, care ulterior afectează jobul inițial.

Feedback-ul de control are loc atunci; când ieșirea unui bloc afectează un bloc cu dominanță mai mare.

Relațiile de ieșire-mecanism sunt rare. Ele reflectă o situație în care rezultatul unei funcții devine un mijloc pentru un scop pentru alta.

Orez. 2.4. Feedback de conectare

Orez. 2.5. Feedback de management

Relațiile producție-mecanism sunt caracteristice alocării surselor de resurse (de exemplu, instrumente necesare, personal instruit, spațiu fizic, echipamente, finanțare, materiale).

În IDEF0, un arc rareori reprezintă un singur obiect. De obicei simbolizează un set de obiecte. Deoarece arcurile reprezintă colecții de obiecte, ele pot avea mai multe puncte de plecare (surse) și puncte de sfârșit (destinații). Prin urmare, arcurile se pot ramifica și se pot conecta în diferite moduri. Întregul arc sau o parte a acestuia se poate extinde de la unul sau mai multe blocuri și se poate termina în unul sau mai multe blocuri.

Arcurile de bifurcare, reprezentate ca linii radiante, înseamnă că tot sau o parte din conținutul arcelor poate apărea în fiecare ramură. Un arc este întotdeauna etichetat înaintea unei ramuri pentru a da un nume întregului set. În plus, fiecare ramură a unui arc poate fi sau nu etichetată conform următoarelor reguli:

• ramurile neetichetate conțin greutatea obiectelor specificate în eticheta arcului înainte de ramură;
• ramurile etichetate după punctul de ramificare conțin toate sau o parte din obiectele specificate în eticheta arcului înainte de ramificare.

Îmbinările arcului în IDEFO, reprezentate ca linii care converg împreună, indică faptul că conținutul fiecărei ramuri formează o etichetă pentru arcul care rezultă din îmbinarea arcurilor originale. După o îmbinare, arcul rezultat este întotdeauna marcat pentru a indica noul set de obiecte rezultat în urma îmbinării. În plus, fiecare ramură poate fi sau nu marcată înainte de fuzionare, conform următoarelor reguli:

Orez. 2.6. Conexiune ieșire-mecanism

• ramurile neetichetate conțin greutatea obiectelor specificate în eticheta arcului comun după îmbinare;
• ramurile marcate înainte de îmbinare conțin toate sau unele dintre obiectele enumerate în eticheta comună după îmbinare,

Analiza grafică cantitativă

Pentru a efectua o analiză cantitativă a diagramelor, listăm indicatorii modelului:

• numărul de blocuri pe diagramă - N;
• nivel de descompunere a diagramei - L;
• echilibrul diagramei - ÎN;
• numărul de săgeți care se conectează la bloc - A

Acest set de factori se aplică fiecărei diagrame model. Următoarele vor enumera recomandări cu privire la valorile dorite ale factorilor din diagramă.

Este necesar să ne străduim să ne asigurăm că numărul de blocuri de pe diagramele nivelurilor inferioare este mai mic decât numărul de blocuri de pe diagramele părinte, adică, pe măsură ce nivelul de descompunere crește, coeficientul scade. Astfel, scăderea acestui coeficient indică faptul că. că pe măsură ce modelul este descompus, funcțiile ar trebui simplificate, prin urmare, numărul de blocuri ar trebui să scadă.

Diagramele trebuie să fie echilibrate. Aceasta înseamnă că situația prezentată în Fig. 1 nu ar trebui să apară în cadrul aceleiași diagrame. 2.7: lucrarea 1 are mult mai multe săgeți de intrare și săgeți de control decât cele care ies. Trebuie remarcat faptul că această recomandare poate să nu fie urmată în modelele care descriu procesele de producție. De exemplu, atunci când descrieți o procedură de asamblare, un bloc poate include multe săgeți care descriu componentele unui produs și o săgeată care iese - produsul finit.

Orez. 2.7. Exemplu de grafic dezechilibrat

Să introducem coeficientul de echilibru al diagramei

Este necesar să ne străduim să Q a fost minim pentru diagramă.

Pe lângă analiza elementelor grafice ale diagramei, este necesar să se ia în considerare denumirile blocurilor. Pentru a evalua numele, este compilat un dicționar de funcții elementare (triviale) ale sistemului modelat. De fapt, acest dicționar ar trebui să includă funcțiile nivelului inferior de descompunere a diagramei. De exemplu, pentru un model de bază de date, funcțiile „găsiți o înregistrare” și „adăugați o înregistrare în baza de date” pot fi elementare, în timp ce funcția „înregistrare utilizator” necesită o descriere suplimentară.

După formarea unui dicționar și compilarea unui pachet de diagrame de sistem, este necesar să se ia în considerare nivelul inferior al modelului. Dacă există potriviri între numele blocurilor de diagramă și cuvintele din dicționar, aceasta înseamnă că a fost atins un nivel suficient de descompunere. Coeficientul care reflectă cantitativ acest criteriu poate fi scris ca L*C- produsul nivelului de model și numărul de potriviri ale numelor de bloc cu cuvintele din dicționar. Cu cât nivelul modelului este mai scăzut (L mai mare), cu atât potrivirile sunt mai valoroase.

Setul de instrumente BPWin

Când porniți BPWin, bara de instrumente principală, paleta de instrumente și Model Explorer apar în mod implicit.

La crearea unui model nou, apare un dialog în care trebuie să indicați dacă modelul va fi creat din nou sau va fi deschis din depozitul ModelMart, introduceți numele modelului și selectați metodologia în care va fi construit modelul ( Fig. 2.8).

Fig.2.8 Dialog de creare a modelului

BPWin acceptă trei metodologii - IDEF0, IDEF3 și DFD. În BPWin este posibil să se construiască modele mixte, adică modelul poate conține simultan atât diagrame IDEF0, cât și IDEF3 și DFD. Compoziția paletei de instrumente se schimbă automat când treceți de la o notație la alta.

Un model în BPWin este considerat ca un set de lucrări, fiecare dintre ele funcționând cu un anumit set de date. Dacă faceți clic pe orice obiect model cu butonul stâng al mouse-ului, apare un meniu contextual pop-up, fiecare articol corespunzător editorului unei proprietăți a obiectului.

Exemplu

Construirea unui model de sistem ar trebui să înceapă cu studierea tuturor documentelor care descriu funcționalitatea acestuia. Unul dintre aceste documente este specificația tehnică, și anume secțiunile „Scopul dezvoltării”, „Scopul și obiectivele sistemului” și „Caracteristicile funcționale ale sistemului”.

După studierea documentelor sursă și intervievarea clienților și utilizatorilor sistemului, este necesar să se formuleze scopul modelării și să se determine punctul de vedere asupra modelului. Să luăm în considerare tehnologia construcției sale folosind exemplul sistemului „Serviciul universitar de ocupare a forței de muncă”, ale cărui capacități principale au fost descrise în munca de laborator nr. 1.

Să formulăm scopul modelării: de a descrie funcționarea sistemului, care ar fi de înțeles utilizatorului său, fără a intra în detalii legate de implementare. Vom construi modelul din punctul de vedere al utilizatorilor (elev, profesor, administrator, decanat, companie).

Să începem prin a construi o diagramă IDEF0 de context Conform descrierii sistemului, funcția principală este de a-și servi clienții prin procesarea cererilor de la aceștia. Astfel, definim singura sarcină a diagramei de context ca „Servește clientul sistemului”. În continuare, definim datele de intrare și de ieșire, precum și mecanismele și controlul.

Pentru a deservi un client, este necesar să îl înregistrați în sistem, să deschideți accesul la baza de date și să procesați cererea acestuia. Datele de intrare vor fi „nume client”, „parolă client”, „bază de date sursă”, „cerere client”. Executarea unei cereri duce fie la primirea de informații din sistem, fie la modificarea conținutului bazei de date (de exemplu, la compilarea evaluărilor experților), astfel încât datele de ieșire vor fi „rapoarte” și „bază de date modificată”. Procesul de procesare a cererii va fi efectuat de monitorul sistemului sub controlul administratorului.

Diagrama de context

Astfel, definim diagrama de context a sistemului (Fig. 2.9).

Figura 2.9. Diagrama contextului sistemului

Să descompunăm diagrama de context, descriind secvența serviciului clienți:

• Determinarea nivelului de acces la sistem.
• Selectarea subsistemului.
• Acces la subsistem.
• Modificarea bazei de date (dacă este necesar).

Obținem diagrama prezentată în fig. 2.10.

După ce ați finalizat descompunerea diagramei de context, treceți la descompunerea diagramei de nivel următor. În mod obișnuit, atunci când se iau în considerare al treilea și cel mai jos nivel, modelele revin la diagramele părinte și le ajustează.

Orez. 2.10. Descompunerea lucrării „Serviciul, clientul de sistem”

Descompunem secvenţial toate blocurile diagramei rezultate. Primul pas în determinarea nivelului de acces la sistem este determinarea categoriei de utilizatori. Numele clientului este căutat în baza de date a utilizatorilor, determinându-se categoria acestuia. După o anumită categorie sunt determinate puterile acordate utilizatorului sistemului. În continuare, se efectuează procedura de accesare a sistemului, verificând numele și parola de acces. Prin combinarea informațiilor despre autorități și nivelul de acces la sistem, se formează un set de acțiuni permise pentru utilizator. Astfel, determinarea nivelului de acces la sistem va arăta ca în fig. 2.11.

Orez. 2.11. Descompunerea lucrării „Determinarea nivelului de acces la sistem”

După finalizarea procedurii de acces la sistem, monitorul analizează cererea clientului, selectând subsistemul care va procesa cererea. Descompunerea lucrării „Apel la un subsistem” nu corespunde scopului și punctului de vedere al modelului. Utilizatorul sistemului nu este interesat de algoritmii interni ai funcționării acestuia. În acest caz, este important pentru el ca alegerea subsistemului să se facă automat, fără intervenția sa, așa că descompunerea accesului la subsistem nu va face decât să complice modelul.

Descompunem lucrarea „Procesarea unei cereri client”, realizată de subsistemul de procesare a cererilor, determinând categoriile și puterile utilizatorilor. Înainte de a căuta un răspuns la o interogare, trebuie să deschideți baza de date (conectați-vă la ea). În general, baza de date poate fi localizată pe un server la distanță, așa că poate fi necesară stabilirea unei conexiuni la acesta. Să determinăm succesiunea lucrărilor:

• Deschiderea bazei de date.
• Executarea cererii.
• Generarea de rapoarte.

După deschiderea bazei de date, trebuie să informați sistemul că a fost stabilită o conexiune la baza de date, apoi să executați cererea și să generați rapoarte pentru utilizator (Fig. 2.12).

Trebuie remarcat faptul că „Execuția interogărilor” include munca diferitelor subsisteme. De exemplu, dacă cererea include testarea, atunci aceasta va fi executată de subsistemul de teste profesionale și psihologice. În etapa de execuție a interogării, poate fi necesară modificarea conținutului bazei de date, de exemplu, la compilarea evaluărilor experților. Prin urmare, este necesar să se prevadă această posibilitate în diagramă.

Orez. 2.12.

Ajustarea graficului

Atunci când se analizează diagrama rezultată, apare întrebarea: ce reguli sunt folosite pentru a genera rapoarte? Este necesar să existe șabloane pregenerate care vor fi folosite pentru a selecta din baza de date, iar aceste șabloane trebuie să corespundă interogărilor și să fie predefinite. În plus, clientului ar trebui să i se ofere posibilitatea de a alege forma raportului.

Să ajustăm diagrama adăugând săgețile „Șabloane de raport” și „Solicitări de modificare a bazei de date” și săgeata tunel „Client de sistem”. Tunnelarea „Clientului de sistem” este utilizată pentru a nu plasa săgeata pe diagrama de sus, deoarece funcția de selectare a formularului de raport nu este suficient de importantă pentru a fi afișată pe diagrama părinte.

Schimbarea diagramei va avea ca rezultat ajustări la toate diagramele părinte (Fig. 2.13 - 2.15).

Este recomandabil să descompuneți lucrarea „Execuția interogării” folosind o diagramă DFD (lucrare de laborator nr. 3), deoarece metodologia IDEF0 consideră sistemul ca un set de lucrări interconectate, care nu reflectă bine procesele de prelucrare a informațiilor.

Orez. 2.13. Descompunerea lucrării „Prelucrarea cererii unui client”

Orez. 2.14. Descompunerea lucrării „Serviciul pentru clienți de sistem” (opțiunea 2)

Orez. 2.15. Diagrama contextului sistemului (opțiunea 2)

Să trecem la descompunerea ultimului bloc „Schimbarea bazei de date”. Din punctul de vedere al clientului, datele sistemului se află într-o singură bază de date. În realitate, există șase baze de date în sistem:

• baza de date a utilizatorilor,
• baza de date a studentilor, (opțiunea 2)
• baza de date a posturilor vacante,
• baza de date a performantelor academice,
• baza de date de testare,
• DB de evaluări de experți,
• CV DB.

Conform scopului modelării, este important ca clientul să înțeleagă că datele primite nu sunt actualizate imediat în sistem, ci trec printr-o etapă suplimentară de prelucrare și control. Algoritmul de schimbare poate fi formulat după cum urmează:

• Este determinată baza de date în care vor fi modificate informațiile.
• Operatorul creează un set temporar de date și îl furnizează administratorului.
• Administratorul controlează datele și le introduce în baza de date.

Acest model poate fi implementat într-un alt mod, oferind posibilitatea de a actualiza baza de date direct la solicitări, ocolind procesul de control al datelor. În acest caz, este necesar să se asigure integritatea bazei de date pentru a evita deteriorarea. În acest caz, diagrama va arăta astfel (Fig. 2.17).

Orez. 2.16. Descompunerea lucrării „Schimbarea bazei de date”

Orez. 2.17. Descompunerea lucrării „Modificarea bazei de date” (opțiunea 2) Pentru prima opțiune, prezentată în Fig. 2.12

Efectuarea descompunerii ulterioare a „Modificărilor bazei de date” va complica modelul, explicând modul în care se realizează modificarea fizică a bazei de date în sistem. În acest caz, utilizatorul nu va primi informații suplimentare despre funcționarea sistemului de servicii de ocupare a forței de muncă. Este recomandabil să descompuneți această lucrare în timpul procesului de proiectare a unui sistem de baze de date în etapa creării unui model logic al bazei de date.

O descompunere a lucrării de execuție a interogărilor va fi efectuată în laboratorul următor, ilustrând utilizarea diagramelor DFD pentru a descrie procesele de procesare a informațiilor.

Să efectuăm o analiză cantitativă a modelelor prezentate în Fig. 2.12 și 2.13, conform metodei descrise mai sus. Să luăm în considerare comportamentul coeficientului ^ pentru aceste modele. Diagrama părinte „Procesarea unei cereri client” are un coeficient de 4/2 = 2, iar diagrama de descompunere are 3/3 = 1. Valoarea coeficientului scade, ceea ce indică o simplificare a descrierii funcțiilor ca nivelul de modelul scade.

Să luăm în considerare modificarea coeficientului K b au două opțiuni de model.

pentru a doua varianta

Coeficient K b nu își modifică valoarea, prin urmare, echilibrul diagramei nu se modifică.

Vom presupune că nivelul de descompunere a diagramelor luate în considerare este suficient pentru a reflecta scopul modelării, iar în diagramele de nivel inferior, funcțiile elementare sunt folosite ca nume de lucrări (din punctul de vedere al utilizatorului de sistem) .

Rezumând exemplul luat în considerare, este necesar să remarcăm importanța luării în considerare a mai multor opțiuni de diagramă la modelarea unui sistem. Asemenea opțiuni pot apărea la ajustarea diagramelor, așa cum sa făcut cu „Procesarea unei cereri de client” sau la crearea unor implementări alternative ale funcțiilor sistemului (descompunerea lucrării „Modificarea bazei de date”). Revizuirea opțiunilor vă permite să o selectați pe cea mai bună și să o includeți într-un pachet de diagrame pentru o analiză suplimentară.

Întrebări de control

Listă Intrebari de securitate:

1. Ce este un model în notația IDEF0?
2. Ce înseamnă joburile din IDEF0?
3. Care este ordinea denumirii lucrărilor?
4. Câte lucrări ar trebui să fie prezente pe o diagramă?
5. Care este ordinea dominantei?
6. Cum sunt aranjate lucrările după principiul dominației?
7. Care este scopul laturilor dreptunghiurilor de lucru pe diagrame?
8. Enumerați tipurile de săgeți.
9. Numiți tipurile de relații.
10. Cum se numesc săgețile de delimitare?
11. Explicați principiul denumirii săgeților de ramificare și îmbinare.
12. Ce metodologii sunt acceptate de BPWin?
13. Enumerați elementele principale ale ferestrei principale BPWin.
14. Descrieți procesul de creare a unui nou model în BPWin.
15. Cum se face conexiuni între lucrări?
16. Cum să setați un nume de job.
17. Descrieți procesul de defalcare a muncii.
18. Cum se adaugă lucru la o diagramă?
19. Cum să rezolvi săgețile tunelizate?
20. Poate un model BPWin să conțină diagrame de metodologii multiple?

IDEF0 este o notație de modelare grafică utilizată pentru a crea un model funcțional care descrie structura și funcțiile unui sistem, precum și fluxurile de informații și obiecte materiale care leagă aceste funcții. Notația IDEF0 este una dintre cele mai populare notații de modelare a proceselor de afaceri.

Scopul tehnicii este de a construi o diagramă funcțională a sistemului studiat, care să descrie toate procesele necesare cu o acuratețe suficientă pentru modelarea fără ambiguitate a activității sistemului.

Metodologia se bazează pe patru concepte principale: bloc funcțional, arc de interfață, descompunere, glosar.

Bloc funcțional(Activity Box) reprezintă unele specifice funcţieîn cadrul sistemului în cauză. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în starea verbală (de exemplu, „produce servicii”). În diagramă, blocul funcțional este reprezentat ca un dreptunghi (Fig. 3.).

Fiecare dintre cele patru laturi ale blocului funcțional are propriul său sens specific (rol) și:

Partea de sus este setată la „Control”;

Partea stângă este setată la „Intrare”;

Partea dreaptă este setată la Ieșire;

Partea de jos are semnificația „Mecanism”.

Arc de interfață(Săgeată) afișează un element de sistem care este procesat de un bloc funcțional sau care afectează în alt mod funcţie, reprezentat de acest bloc funcțional. Arcurile de interfață sunt adesea numite fluxuri sau săgeți.

Orez. 3. - Bloc funcţional

Folosind arcele de interfață, sunt afișate diverse obiecte care, într-o măsură sau alta, determină procesele care au loc în sistem. Astfel de obiecte pot fi elemente ale lumii reale (piese, mașini, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).

În funcție de ce parte a blocului funcțional se potrivește acest arc de interfață, se numește „incoming”, „outgoing” sau „control”.

De menționat că orice bloc funcțional, conform cerințelor standardului, trebuie să aibă cel puțin un arc de interfață de control și unul de ieșire. Acest lucru este de înțeles - fiecare proces trebuie să aibă loc conform unor reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel luarea în considerare a acestuia nu are sens.

Prezența obligatorie a arcurilor de interfață de control este una dintre principalele diferențe între standardul IDEF0 și alte metodologii ale claselor DFD (Diagrama fluxului de date) și WFD (Diagrama fluxului de lucru).

Descompunere(Descompunerea) este un concept de bază al standardului IDEF0. Principiul descompunerii este utilizat atunci când un proces complex este împărțit în componentele sale funcții. În acest caz, nivelul de detaliu al procesului este determinat direct de dezvoltatorul modelului.

Descompunerea vă permite să prezentați treptat și structurat modelul de sistem sub forma unei structuri ierarhice de diagrame individuale, ceea ce îl face mai puțin supraîncărcat și ușor de digerat (Fig. 4.).

Ultimul dintre conceptele IDEF0 este Glosarul. Pentru fiecare dintre elementele IDEF0 - diagrame, blocuri funcționale, arcuri de interfață - standardul existent necesită crearea și menținerea unui set de definiții corespunzătoare, cuvinte cheie, enunțuri narative etc., care caracterizează obiectul afișat de acel element. Acest set se numește glosar și este o descriere a esenței unui element dat. Glosarul completează armonios limbajul grafic vizual, oferind diagramelor informațiile suplimentare necesare.

Modelul IDEF0 începe întotdeauna cu o vedere a sistemului ca un întreg - un singur bloc funcțional cu arcuri de interfață care se extind dincolo de domeniul luat în considerare. Se numește o astfel de diagramă cu un singur bloc funcțional diagrama de context.

Textul explicativ pentru diagrama de context trebuie să indice ţintă(Scopul) de a construi o diagramă sub forma unei scurte descriere și înregistrată Punct de vedere.

Orez. 4. - Schema de descompunere a blocurilor functionale ale modelului

Definirea și formalizarea obiectivului dezvoltării modelului IDEF0 este un punct extrem de important. De fapt, obiectivul definește zonele relevante din sistemul studiat pe care trebuie să se concentreze mai întâi.

Punctul de vedere determină direcția principală de dezvoltare a modelului și nivelul de detaliu necesar.

O fixare clară a punctului de vedere vă permite să descărcați modelul refuzând detalierea și studierea elementelor individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului. Alegerea corectă a punctului de vedere reduce semnificativ timpul petrecut pentru construirea modelului final.

Selecţie subprocese. În timpul procesului de descompunere, un bloc funcțional care reprezintă sistemul ca întreg într-o diagramă de context este detaliat într-o altă diagramă. Diagrama de al doilea nivel rezultată conține blocuri funcționale care afișează principalele subfuncții ale blocului funcțional al diagramei de context și se numește diagramă copil în relație cu aceasta (fiecare dintre blocurile funcționale aparținând diagramei copil este numit în mod corespunzător o casetă copil). .

La rândul său, blocul funcțional strămoș se numește bloc părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține se numește diagramă părinte (Parent Diagram). Fiecare dintre subfuncțiile unei diagrame copil poate fi detaliată în continuare printr-o descompunere similară a blocului său funcțional corespunzător. În fiecare caz de descompunere a unui bloc funcțional, toate arcurile de interfață care intră sau emană din acest bloc sunt fixate pe diagrama copil. Acest lucru realizează integritatea structurală a modelului IDEF0.

Uneori, nu are sens să se ia în considerare în continuare arcuri individuale de interfață de un nivel superior pe diagramele de un nivel inferior sau invers - să reflecte arcuri individuale de un nivel inferior pe diagramele de niveluri superioare - acest lucru va supraîncărca diagramele și le va face greu de inteles. Pentru a rezolva astfel de probleme, standardul IDEF0 oferă conceptul de tunel. Desemnarea „Arrow Tunnel” a două paranteze în jurul începutului unui arc de interfață indică faptul că arcul nu a fost moștenit de la blocul părinte funcțional și apare (din „tunel”) doar pe această diagramă.

La rândul său, aceeași desemnare în jurul capătului (săgeata) arcului de interfață în imediata apropiere a blocului receptor înseamnă faptul că acest arc nu va fi afișat sau luat în considerare în diagrama copil a acestui bloc. Cel mai adesea, se întâmplă ca obiectele individuale și arcurile lor de interfață corespunzătoare să nu fie luate în considerare la unele niveluri intermediare ale ierarhiei - în acest caz, ele sunt mai întâi „cufundate în tunel” și apoi, dacă este necesar, „întors din tunel”.

De obicei, modelele IDEF0 conțin informații complexe și concentrate, iar pentru a le limita aglomerația și a le face lizibile, standardul adoptă restricții de complexitate adecvate.

Se recomandă reprezentarea de la trei până la șase blocuri funcționale pe diagramă, în timp ce numărul de arcuri de interfață potrivite pentru un bloc funcțional (ieșind dintr-un bloc funcțional) se presupune a nu mai mult de patru.

Standardul IDEF0 conține un set de proceduri care permit dezvoltarea și convenirea unui model de către un grup mare de persoane aparținând diferitelor domenii de activitate ale sistemului modelat.

De obicei, procesul de dezvoltare este iterativ și constă din următoarele etape convenționale: Crearea unui model de către un grup de specialişti care ţin de diverse domenii ale întreprinderii. Acest grup se numește Autori în termenii IDEF0. Construirea modelului inițial este un proces dinamic în timpul căruia autorii intervievează persoane competente despre structura diferitelor procese, creând modele de activități departamentale.

În același timp, ei sunt interesați de răspunsuri la următoarele întrebări:

Ce primește departamentul ca input?

Care funcțiiși în ce succesiune sunt efectuate în cadrul departamentului?

Cine este responsabil pentru implementarea fiecăruia dintre funcții?

Ceea ce îl ghidează pe interpret atunci când execută fiecare dintre funcții?

Care este rezultatul muncii departamentului (ieșire)?

Pe baza reglementărilor existente, a documentelor și a rezultatelor sondajului, este creată o schiță de model a modelului.

Distribuirea proiectului pentru revizuire, aprobare și comentariu. În această etapă, proiectul de model este discutat cu o gamă largă de persoane competente (în termeni IDEF0 - cititori) din întreprindere. În acest caz, fiecare dintre diagramele proiectului de model este criticată și comentată în scris, apoi transferată autorului. Autorul, la rândul său, este de asemenea în scris de acord cu critica sau o respinge, conturând logica deciziei și returnează proiectul revizuit pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.

Aprobarea oficială a modelului. Modelul agreat este aprobat de șeful grupului de lucru dacă autorii modelului și cititorii nu au nicio dezacord cu privire la adecvarea acestuia. Modelul final este o vedere coerentă asupra întreprinderii (sistemului) dintr-un punct de vedere dat și pentru un scop dat.

Claritatea limbajului grafic IDEF0 face ca modelul să fie complet lizibil chiar și pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru expoziții și prezentări. Pe viitor, pe baza modelului construit, pot fi organizate noi proiecte menite să facă modificări în model.

Modelul IDEF0 este recomandat pentru utilizare într-o întreprindere atunci când descrie procesele de afaceri la nivel superior. La elaborarea unui model funcțional al unui proces de afaceri (IDEF0) sunt descrise funcțiile îndeplinite și fluxurile de intrare și ieșire ale resurselor materiale, financiare și informații (documente, dosare).

Simbolurile în format IDEF0 sunt prezentate în tabelele 2 și 3.

Tabelul 2. - Simboluri grafice ale notației IDEF0

Simbol	Imagine	Descriere
bloc		Blocul descrie procesul. Un bloc tipic este prezentat în Fig. 1. În interiorul fiecărui bloc sunt plasate numele și numărul acestuia. Numele trebuie să fie un verb activ, o expresie verbală sau un substantiv verbal. Numărul blocului este situat în colțul din dreapta jos. Numerele bloc sunt utilizate pentru identificare în diagramă și textul asociat.
Săgeată		Săgețile reprezintă obiecte (date) care intră și ies din proces. Fiecare parte a unui bloc funcțional are o semnificație standard în ceea ce privește conexiunea bloc-săgeată La rândul său, partea blocului de care este atașată săgeata determină în mod unic rolul său. Săgețile care intră în partea stângă a blocului sunt intrări. Săgețile care intră în bloc de sus sunt comenzi. Săgețile care părăsesc procesul în dreapta sunt ieșiri, adică. date sau obiecte materiale produse de un proces. Săgețile conectate la partea inferioară a blocului reprezintă mecanismele.
Săgeată tunelată		Săgețile tunelizate indică faptul că datele reprezentate de săgeți nu sunt luate în considerare în diagrama părinte și/sau diagrama secundară. O săgeată plasată în tunel unde se unește cu un bloc înseamnă că datele exprimate de acea săgeată nu sunt necesare la următorul nivel de descompunere. O săgeată plasată într-un tunel la capătul liber înseamnă că datele pe care le reprezintă nu sunt prezente în diagrama părinte.
Referință externă		Referință externă - un loc, entitate sau subiect care se află în afara granițelor sistemului care se modelează. Folosit pentru a indica sursa sau destinația săgeților din afara modelului. În diagrame, o legătură externă este reprezentată ca un pătrat, lângă care este afișat numele legăturii externe.
Link interchart		Un element care reprezintă o altă diagramă. Servește pentru a indica trecerea săgeților la o diagramă a unui alt proces de afaceri fără a afișa o săgeată pe diagrama de deasupra (când se utilizează modele ierarhice).

Tabelul 3. - Simboluri grafice ale notării IDEF0

1. Modelarea funcțională a unui sistem informațional folosind tehnologia IDEF CASE.
2. Descrierea logicii interacțiunii și a succesiunii de lucru.

2. Planul de lecție

1. Controlul cunoștințelor prin testare (test ISE002).
2. Dezvoltarea unui model pe mai multe niveluri de activitate a sistemului informatic (model AS - IS) folosind instrumentul BPwin CASE folosind tehnologii IDEF 0Și IDEF 3 :
   • Descrierea proprietăților modelului (Proprietăți model).
   • Crearea primului nivel al modelului funcțional - elaborarea unei diagrame de context.
   • Crearea celui de-al doilea nivel al modelului funcțional - detalierea lucrării contextuale și elaborarea unei diagrame de descompunere.
   • Crearea celui de-al treilea nivel al modelului funcțional - detalierea activității celui de-al doilea nivel care implementează funcția Contabilitatea activității organizatii. Această etapă de dezvoltare permite crearea unei diagrame de descompunere folosind una dintre cele două metodologii - IDEF 0 (prima opțiune) sau IDEF 3 (a doua opțiune). Conform celei de-a 2-a opțiuni, crearea unui scenariu și a unei diagrame de secvență pentru realizarea lucrărilor individuale (Diagrama fluxului de lucru) în procesul de contabilizare a activităților se realizează folosind metodologia IDEF 3.
3. Dezvoltarea unui dicționar de lucrări și a unui dicționar de săgeți care vă permit să afișați o descriere a fragmentelor corespunzătoare ale modelului.

1. Modelarea funcțională a unui sistem informațional folosind tehnologie IDEF trebuie efectuată cu ajutorul unui instrument CASE BPwin, care este încărcat de comandă Start/Programe/Computer Associates/BPwin 4.0/BPwin4.0 . Procesele tehnologice ale modelării IDEF sunt prezentate în secțiunea 4 „Informații teoretice pentru lecția practică”.
2. La elaborarea unei diagrame de context, trebuie luat în considerare faptul că proprietățile modelului pot fi formatate după cum urmează, folosind informații corespunzătoare domeniului de subiect modelat:
   • Numele modelului : Activitățile companiei „Nume”;
   • Proiect (numele proiectului): Modelul de activitate al companiei „Nume”;
   • Nume complet, grup;
   • Domeniul de aplicare (zona de modelare care include scopul modelării, adică întrebări la care modelul construit ar trebui să răspundă) – de exemplu, „Conducerea generală a activității companiei: cercetare de piață, achiziție de componente, testare și vânzare de produse” sau „Aspecte tehnologice, financiare și manageriale ale activităților companiei”;
   • Interval de timp (tip de model) : Așa cum este;
   • Definiție , scopul modelului) : Model de instruire care descrie activitățile companiei „Nume”;
   • Punct de vedere (Punct de vedere – persoană al cărei punct de vedere este adoptat în timpul dezvoltării) : Șeful întreprinderii și directorul general;
   • stare : FUNCTIONARE;
   • Scop : Modelarea proceselor de afaceri curente ale companiei „Nume” în vederea reglementării activităților acesteia;
   • Sursă (sursă informație): Analiza domeniului si analiza documentelor de intrare;
   • Numele autorului : NUMELE COMPLET.
3. Facand descompunerea diagramei de context trebuie avut în vedere că ea, fiind al doilea nivel descompunerea modelului de sistem, reprezintă subproces sau munca copilului , implementate în formă lucrare contextuală, care în acest caz acționează ca munca parentală, implementat în formular Diagrama parentală) . Diagrama de descompunere de nivel al doilea trebuie să conțină cel puțin trei blocuri funcționale, dintre care unul trebuie să îndeplinească funcția de modelare contabilitatea activitatii organizație, iar restul ar trebui să îndeplinească funcția de modelare procesele de afaceri, implementat în sistem.
4. La fiecare pas de descompunere, ar trebui să monitorizați procesul de mișcare automată a arcurilor de interfață (săgeți) la nivelurile inferioare ale modelului și să încercați să evitați crearea de săgeți tunelizate în mod inutil. Dacă apar, tunelurile ar trebui îndepărtate.
5. La implementare al treilea nivel descompunere, trebuie avut în vedere că fiecare dintre diagramele de descompunere elaborate este al treilea nivel de descompunere a lucrărilor de al doilea nivel și reprezintă subproces sau munca subsidiara implementate în formă Diagrama copilului lucrări relevante de nivel al treilea. Toate lucrările de al doilea nivel în acest caz acționează ca munca parentală, implementat în formular diagrame părinte(Diagrame parentale).
6. Descompunerea lucrării de nivel al doilea, modelarea funcției contabile și crearea unui scenariu pentru interacțiunea muncii ar trebui efectuate folosind tehnologia IDEF 3 care folosește ca blocuri funcționale unitatimuncă (Unitatea de lucru, UOW) , precum și cele necesare obiecte de referință (referenți) , care poate fi fie implementat în script din dicționarul cu săgeți, fie creat din nou.
7. Un dicționar de lucru și un dicționar de săgeți sunt create la fiecare nivel de descompunere a modelului, iar o condiție necesară pentru dezvoltarea lor este prezența unei descrieri de lucru. (activitate)și descrieri ale datelor înregistrate pe arcul de interfață ( săgeată) .
8. Salvați rezultatele lucrării într-un fișier Function_model IS_Name_ IDEF.bp1 în folderul dvs EU VAD.
9. Un exemplu de model funcțional generalizat este dat în

4. Informații teoretice pentru lecția practică

4.1. IDEF 0-tehnologie

Metodologia IDEF0 este concepută pentru a modela activitățile unei organizații. În etapa inițială a dezvoltării proiectului, este creat un model conceput pentru a descrie procesele de afaceri și procesele tehnologice existente în întreprindere conform principiului „AS - IS” („As Is”) și, mai important, reprezintă întreprinderea din perspectiva angajaților care lucrează acolo și cunosc în detaliu toate nuanțele, inclusiv cele informale. AS-IS este „ceea ce facem astăzi”, înainte de a trece la „ceea ce vom face mâine”.

Model de activitate sau, cu alte cuvinte, model functional. Model functional tratează sistemul ca pe un set actiuni, in care fiecare acțiune transformă pe unele un obiect sau set de obiecte . Tehnologie IDEF 0 folosește principiul descompunere functionala sisteme (împărțirea sistemului în fragmente). Principiul de descompunereînseamnă că modelul funcțional trebuie construit conform regulii "de sus în jos" , din general tip de model la privat modele. Prin urmare, de obicei, modelul funcțional pentru rezolvarea unei probleme este un set de modele funcționale private .

Modelele funcționale evidențiază acțiunile reprezentându-le ca un element special - bloc. bloc – principalul element structural al unui model funcțional, a cărui reprezentare grafică este diagramă . Numele acțiunii – substantiv verbal sau verb . Ca rezultat al descompunerii modelului, este creat un set de diagrame ordonate ierarhic și interconectate. Fiecare diagramă este o unitate de descriere a sistemului și se află pe o foaie separată.

Metodologie IDEF 0 se bazează pe patru concepte de bază: bloc funcțional (nod), arc de interfață, descompunere, glosar.

Bloc funcțional

Conceptul fundamental de tehnologie IDEF 0 este conceptul bloc funcţional. Este destinat să reprezinte un anumit tip Activitate , care reprezintă unele specifice funcţie în cadrul sistemului în cauză. Această funcție înseamnă, la rândul său, o anumită acțiune (set de acțiuni), având un scop fix și conducând la un rezultat final.

Bloc funcțional este reprezentat printr-un dreptunghi, ale cărui laturi au următoarele valori:

• Partea de sus este managementul.
• Partea de jos este mecanismul.
• Partea dreaptă este ieșirea.
• Partea stângă este intrarea.

Un bloc funcțional are un nume, care este specificat în modul verbal sau un substantiv verbal. Interacțiunea dintre acțiuni iar lumea din jurul lui, inclusiv alte acțiuni, este afișată folosind arce de interfață (săgeți).

Arc de interfață

Arc de interfață afișează un element de sistem care sau prelucrate bloc funcțional sau are un efect diferit la activitatea (funcţia) afişată de acest bloc funcţional. Arc de interfață descris ca o săgeată care indică purtător , asigurand transferul de date sau obiecte de la o activitate la alta. Săgețile descriu interacțiunea lucrărilor cu lumea exterioară și între ele, reprezintă unele informații și sunt numite substantive .

Numele săgeții îl indică rol (setul de roluri posibile este notat cu – ICOM ):

Intrare bloc funcțional – eu nput .

management - C Control .

Ieșire bloc funcțional – O ieșire .

Mecanism - M mecanism .

Intrare) este materialul sau informația care este folosită sau transformată de muncă pentru a produce un rezultat (ieșire). Este posibil să nu existe săgeată de intrare.

Control– reguli, politici, proceduri sau standarde care ghidează munca. Ea influențează munca, dar nu este transformată de muncă. Săgeata este desenată ca intrând în marginea superioară a lucrării. Fiecare bloc funcțional trebuie să aibă cel puțin o săgeată de control.

Este adesea dificil de determinat dacă datele sunt introduse sau controlate. Dacă datele din lucrare sunt modificate sau procesate, atunci aceasta este cel mai probabil intrare, iar dacă nu, este control. Dacă este dificil să determinați starea unei săgeți, se recomandă să desenați o săgeată de control.

Ieșire– materialul sau informația care este produsă de lucrare. Este necesară cel puțin o săgeată de ieșire, care emană din partea dreaptă a lucrării.

Mecanism de execuție (Mecanism)– resurse care efectuează munca (de exemplu, personal, mașini, dispozitive etc.). Săgeata este desenată ca intrând în marginea de jos a lucrării. Este posibil ca săgețile mecanismului să nu fie afișate. În general, blocul funcțional este prezentat în Fig. 2.1.

În fig. 2.1 toate arcurile de interfață sunt afișate ca săgeți numite. Conform cerințelor standardului, fiecare bloc funcțional trebuie să aibă cel puțin o ieșire și un control, deoarece fiecare sarcină (proces) trebuie să aibă cel puțin o ieșire și cel puțin o regulă pentru rezolvarea acesteia. Este posibil ca arcul de interfață „Mecanism” să nu fie reprezentat.

Din mai multe blocuri funcționale conectate prin arcuri de interfață în modul cerut, a model functional.

Vă rugăm să rețineți că săgețile se pot ramifica pentru a realiza conexiunile necesare între blocurile funcționale.

Log in blocul funcțional poate fi nu numai Ieșire un alt bloc funcțional, dar și al acestuia Control sau chiar mecanism. Ca urmare, modelul funcțional poate conține procese variate, destul de complexe și neobișnuite pentru rezolvarea problemelor din sistemul informațional.

Crearea de diagrame folosind tehnologia IDEF0

Atunci când se dezvoltă modelul de afaceri al unei organizații, trebuie utilizate trei tipuri de diagrame:

• Diagrama tip I – Diagrama context (nu poate fi decât unul) – vârful structurii arborescente, care reprezintă cel mai abstract nivel de descriere a sistemului și a interacțiunii acestuia cu mediul extern. Ea definește funcția de context;
• II tip diagramă – Diagrama de descompunere .

Diagramele de defalcare sunt concepute pentru a detalia lucrul și a conține legate de munca, adica filiale munca care are un comun părintească muncă. Munca de nivel inferior este aceeași cu munca de nivel superior, dar mai detaliat. Diagramele sunt create de un analist pentru a conduce o sesiune de examinare, adică pentru a discuta diagrama cu un specialist în materie.

După fiecare sesiune de descompunere, se desfășoară sesiuni de examinare - experții în materie indică conformitatea proceselor reale de afaceri cu diagramele create. Neconcordanțele găsite sunt corectate și numai după promovarea examenului fara comentarii puteți trece la următoarea sesiune de descompunere. Acest lucru asigură că modelul se potrivește cu procesele de afaceri reale la orice nivel al modelului.

Este necesar să setați numărul de lucrări la cel mult șase (3–6), altfel diagrama este greu de citit (suprasaturată). Limita superioară (șase) forțează proiectantul să folosească ierarhii atunci când descrie obiecte complexe, iar limita inferioară (trei) asigură că diagrama corespunzătoare are suficiente detalii pentru a justifica crearea acesteia.

Într-o diagramă de defalcare, lucrarea care este cea mai importantă și finalizată mai întâi este situată în stânga sus. Lucrarea care este mai puțin importantă sau finalizată mai târziu scade secvenţial.

• III tip de diagramă – Diagrama arborescentă a nodurilor arată dependența ierarhică a locurilor de muncă, dar nu și relațiile dintre joburi (pot fi atât de multe dintre aceste diagrame, câte doriți, deoarece arborele poate fi construit la orice adâncime și nu neapărat de la rădăcină).

4.2. Procesul tehnologic de modelare IDEF0:

Orez. 2.2

Instrumentul BPWin CASE are o interfață de utilizator simplă și intuitivă pentru construirea modelelor și scenariilor funcționale necesare. Depinde de tehnologia folosită. În fig. 2.2 arată fereastra BPWin ( Computer Associates B.P.Win ).

Bara de instrumente a ferestrei principale Computer Associates BPwin conține următoarele butoane:

	– crearea unui nou model,
	– deschiderea unui model existent,
	– salvarea modelului construit,
	– imprimare model,
	- alegerea scalei,
	- scalare,
	- verificarea ortografiei,
	- porniți/dezactivați navigatorul de model,
	– porniți/dezactivați Model Mart.

Navigatorul de modele arată compoziția modelului în funcție de nivelul de dezvoltare. Cu ajutorul lui, puteți trece ușor și rapid de la un nivel la altul. Lucrul cu navigatorul de model este similar cu lucrul cu Windows Explorer.

Bara de instrumente specială conține următoarele butoane principale:

Fereastra model este locul pentru crearea unui model funcțional al sistemului studiat. În ea, blocurile funcționale sunt construite și editate, săgețile sunt desenate și editate și se realizează descompunerea.

Pregătirea modelului

1. Faceți clic pe butonul de creare a modelului pentru a deschide caseta de dialog B.P.Win(Fig. 2.3):

În caseta de dialog B.P.Win efectuați următoarele acțiuni:

• alege Proces de afaceri (IDEF0);
• setați numele modelului și apăsați butonul Bine;
• La fereastră Proprietăți pentru modelul nou înregistrați numele autorului modelului;
• apasa butonul Bine .

1. Echipă Model/Proprietăți model caseta de dialog apel Proprietățile modelului (Fig. 4), în care să se oficializeze proprietățile modelului în conformitate cu recomandările metodologice expuse în secțiunea 2.

Primul nivel de modelare

1. Proiectați un bloc funcțional în fereastra modelului, parcurgând următorii pași:
   • selectați comanda din meniul contextual al blocului funcțional Nume… ;
   • în caseta de dialog Proprietățile activității (Fig. 2.5) în tab Nume a stabilit Nume lucru (scurt) plasat în acest bloc funcțional, și în fila Definițieîn câmp Definiție Descriere muncă;
   • în marcaj Font setați fontul Arial Cyr și bifați casetele pentru a permite folosirea acestui font în toate blocurile funcționale ale diagramei ( Toate activitățile din această diagramă, Toate activitățile din acest model Și Schimbați toate aparițiile acestui font în model ), apoi apăsați butonul Bine.

• în caseta de dialog Proprietăți săgeți (Fig. 2.7), în tab Nume setați numele săgeții (scurt), iar în filă Definițieîn câmp Definiție introduceți suficiente detalii Descriere scopul acestei săgeți;

• selectați o comandă din meniul contextual săgeată Font… ;
• în caseta de dialog Proprietăți săgeți (Fig. 2.8), în tab Font setați fontul Arial Cyrși bifați casetele pentru a utiliza acest font pentru toate săgețile din diagramă ( Toate săgețile din această diagramă, Toate săgețile din acest model, Toate instanțele acestei săgeți Și Modificați toate aparițiile acestui font în model );

1. Proiectați o săgeată Ieșire, stânga frontiere dreapta;
2. Proiectați o săgeată Control , de ce repetați pasul 2, înlocuind stânga frontiere top;
3. Proiectați o săgeată Mecanism, de ce repetați pasul 2, înlocuind stânga frontiere inferior.

Al doilea nivel de modelare

Orice nivel de modelare

Pentru a crea o descompunere a modelului la orice nivel de modelare, ar trebui să efectuați următorii pași:

• activați un anumit bloc funcțional făcând clic;
• repetați pasul 3 pentru nivelul actual al modelului.

1. Tipul și stilul de design al săgeții pot fi selectate în caseta de dialog Arrow Properties (Fig. 2.9), apelată de comanda Style din meniul contextual săgeată.

1. Pentru instalare împachetarea cuvintelor Ar trebui, prin evidențierea numelui, să reduceți dimensiunea dreptunghiului, după care acesta va crește automat în jos.
2. Fiecare săgeată desenată pe o diagramă de nivel superior trebuie să fie prezentă pe o diagramă de nivel inferior.
3. Săgeată nouă desenată pe diagrama de nivel scăzut (nerezolvată ( nerezolvată) săgeată), este plasată între paranteze drepte (tunele), care subliniază absența unei astfel de săgeți la un nivel superior. Pentru a elimina tunelurile:
   • selectați elementul de meniu Arrow Tunnel ;
   • în caseta de dialog Editor săgeată chenar(Editor săgeată limită) selectați opțiunea Rezolvați-l la Border Arrow (Permiteți ca săgeată la margine). Ca urmare, tunelul de la nivelul actual va fi eliminat, iar săgeata va apărea la nivelul anterior, iar dacă nu este primul, atunci este tunelizat (Fig. 2.10).

1. Pentru a copia săgețile tunelizate de la nivelul inferior în cel superior:
   • faceți clic dreapta pe paranteze pătrate;
   • selectați elementul de meniu Referință în afara paginii;
   • în caseta de dialog Referință săgeată în afara paginii selectați diagrama pe care să plasați săgeata și setați comutatorul de tip săgeată necesar (Fig. 2.11);

• apăsați unul dintre butoanele: OK și mergeți la diagramă (mergi la diagrama selectată) sau OK și rămâneți în diagrama curentă (Rămâneți în diagrama curentă).

Este inacceptabil să lăsați săgeți de delimitare neconectate ( săgeată de frontieră neconectată) – săgețile transferate automat în diagrama de descompunere din diagrama părinte (mod migrație trăgător). Aceste săgeți nu se referă la joburi și trebuie să fie asociate cu joburi în modul Creare săgeți ( Instrumentul săgeată de prioritate – ).

Proiectarea locației și stilului corect al săgeților în mod implicit:

• executa comanda Model/Proprietăți model;
• La fereastră Proprietățile modelului(Fig. 2.12) selectați un marcaj Aspect ;
• bifați caseta (opțional) Spațiează automat săgețile in grup Săgeți

1. Când creați o săgeată feedback-ul managementului ar trebui să setați opțiunea pentru a indica direcția săgeții Extra Arrowhead (din meniul contextual).
2. Dacă etichetele de pe săgeți sunt prost plasate (foarte departe, etc.), ar trebui să bifați caseta de selectare Squiggle (în meniul contextual) pentru liderul etichetei.

1. În diagrama de descompunere, în stânga sus este un bloc funcțional, care conține cea mai importantă lucrare care este efectuată mai întâi. Lucrarea care este mai puțin importantă sau finalizată mai târziu scade secvenţial.
2. Împachetarea cuvintelorîn interiorul lucrării se desfășoară în modul Editor de nume... prin apăsarea unei taste introduce.
3. O diagonală în colțul din stânga sus al dreptunghiului înseamnă că lucrarea corespunzătoare nu este descompusă.
4. Pentru a afișa nu numai numărul de joburi secundare care apar automat, ci și prefixele (A), ar trebui să selectați comanda Model/Proprietăți model, marcaj Numerotare caseta de selectare (optional) Afișează prefixul(Fig. 2.13).

1. Pentru a afișa numerele de lucru și numerele de nivel (numere cu două, trei, patru cifre) pentru locurile de muncă pentru copii, selectați comanda Model/Proprietăți model, marcaj Numerotare caseta de selectare (optional) Utilizați formatul de numerotare diagramă (Fig. 2.13).
2. Pentru a face distincția între diferitele versiuni ale aceleiași diagrame, versiunilor individuale ar trebui să li se atribuie numere (C - număr), care pot fi setate liber în meniu Proprietăți diagramă pe marcaj Kit.

Construirea unui arbore model

• echipă Diagramă/Adăugați/Arbore de noduri caseta de dialog apel Node Tree Wizard_Pasul 1 din 2 (Fig. 2.14);
• conduceți un dialog selectând numărul necesar de niveluri de arbore de noduri ( Numărul de niveluri );
• apasa butonul Gata.

4.3. Tehnologia IDEF3

Tehnologie IDEF3 este o metodologie de descriere a procesului care ia în considerare secvență de execuțieȘi relații cauză-efectîntre situaţii şi evenimente. Folosind IDEF3, ele descriu logica executării lucrărilor, ordinea în care sunt începute și finalizate.

Tehnologia IDEF3 folosește categoria scenarii pentru a simplifica structura descrierilor unui proces complex în mai multe etape. Scenariu (Scenariu) – este o secvență repetată de situații sau acțiuni care descriu o clasă tipică de probleme prezente într-o organizație sau sistem și este, de asemenea, o descriere a secvenței de proprietăți ale unui obiect în cadrul procesului luat în considerare. Modelele IDEF0 sunt legate de scenariile IDEF3, deoarece fiecare model IDEF0 poate fi reprezentat ca unul sau mai multe scenarii IDEF3.

Tehnologia IDEF3 este concepută pentru a oferi colectarea datelor de proces și permite:

• documentează datele disponibile cu privire la tehnologia de desfășurare a procesului, identificate, să zicem, în cadrul unui sondaj al specialiștilor din domeniu;
• analizează procesele existente și dezvoltă altele noi;
• simuleaza situatii prin identificarea situatiilor in care este necesar luarea deciziilor , care afectează ciclul de viață al procesului, de exemplu, modificări ale designului, proprietăților tehnologice sau operaționale ale produsului final;
• facilitează adoptarea deciziilor optime la reorganizarea procesului.

Scenariu în tehnologia IDEF3

Diagrame de scenarii descrie acțiuni și evenimente care trebuie procesate într-o anumită perioadă de timp. Scriptul este însoțit de o descriere a proceselor și poate fi folosit pentru a documenta fiecare funcție a sistemului. În consecință, scenariile fac parte din analiza sistemului, deoarece fac posibilă analiza în timp a unei situații și descrierea obiectelor care participă la un proces în același timp.

Când se utilizează tehnologia IDEF3, toate construcțiile se bazează pe două tipuri de diagrame:

1. Diagrama care descrie succesiunea etapelor procesului.
2. Diagrama stării obiectului.

Sunt utilizate următoarele convenții standard:

	Element funcțional al comportamentului,
	Transferul acțiunii de la un element funcțional al comportamentului (precedent) la altul (ulterior) ( Precedenta ),
	Tranziția fluxului de date de la job la job ( Fluxul obiectelor ),
	Conectarea datelor la locul de muncă ( Referent ),
	Relația dintre lucrări ( Relațional ),
	Starea obiectului.

Reglarea secvenței de execuție a unităților de lucru se realizează prin introducerea în diagramă intersecții (Joncţiune) în diverse scopuri.

Simbol J intersecția poate lua una dintre următoarele valori:

• & – fuziune rezultatele tuturor acțiunilor dacă săgețile intră în intersecție; lansa toate acțiunile dacă săgețile îl părăsesc;
• DESPRE - fuziune acțiunea rezultă dacă cel puțin una dintre acțiunile de intrare este finalizată; lansa cel puțin o acțiune;
• X - fuziune o singură acțiune dintr-un număr dintre cei care intră în intersecție; lansa doar una dintre acțiunile care ies din ea.

O ilustrare a utilizării unei răscruce în diagrame care descriu succesiunea etapelor procesului este fig. 2.15. Din aceasta rezultă că o răscruce este un mijloc de construire a unor procese tehnologice ramificate complexe.

Descrierea tehnologiei care este dezvoltată sau cercetată mai întâi sub formă diagrame care descriu succesiunea etapelor procesului tehnologic , și apoi în formă diagrame de stare a obiectelor oferă o imagine completă a acțiunilor efectuate și a rezultatelor aplicării acestora.

	Job 3 apare atunci când Job 1 și Job 3 sunt terminate
	Iov 1 și Iov 2 apar împreună
	Lucrarea 3 apare atunci când Lucrarea 1 sau Lucrarea 2 sau ambele sunt terminate
	Job 1 și Job 2 apar împreună sau separat
	Lucrarea 3 apare atunci când Lucrarea 1 sau Lucrarea 2 este încheiată
	Are loc Job 1 sau Job 2

În consecință, managerii și dezvoltatorii de sisteme informatice au în mâinile lor un instrument puternic pentru crearea de scenarii pentru procese complexe de management care necesită studiu și automatizare.

4.4. Procesul tehnologic de modelare IDEF3

Pregătirea modelului

1. Faceți clic pe butonul de creare a modelului.
2. În caseta de dialog B.P.Win urmează următoarele instrucțiuni:
   • alege Fluxul procesului (IDEF3);
   • setați numele modelului;
   • apasa butonul Bine;
   • în caseta de dialog Proprietăți pentru modelul nou confirmați proprietățile specificate acolo.

Formalizarea actiunii

1. Faceți clic pe butonul de acțiune de creare ( Instrument Caseta de activitate ).
2. Faceți clic pe butonul stâng al mouse-ului în locația dorită din fereastra modelului.
3. În meniul contextual de acțiune, selectați comanda Nume…
4. În caseta de dialog Proprietățile activității, în marcaj Nume setați numele acțiunii (Fig. 2.16).

1. În caseta de dialog Proprietățile activitățiiîn marcaj Font a stabilit Arial Cyr, Bine.

Formatarea datelor

1. Faceți clic pe butonul de creare a datelor. ( Instrument de referință ).
2. La locul potrivit pe fereastră Referent faceți clic stânga pentru a încorpora numele datelor din dicționarul de entități create (opțiune Entitate) sau din dicționarul creat de săgeți (opțiunea Săgeată), sau creați-le din nou (opțiune Alte) (Fig. 2.17).

1. În dialog Fereastra Proprietăți referitor (Fig. 2.18), în tab Font a stabilit Arial Cyr bifați casetele de selectare necesare și faceți clic pe butonul Bine.

5. Temele pentru următoarea lecție

1. Gândiți și identificați obiectele materiale sau indivizi care sunt surse sau receptori de informații (entități externe).
2. Gândiți și dezvoltați un model relațional al datelor prelucrate de sistemul informațional:
   • faceți o listă de entități și atributele acestora,
   • arată relaţiile dintre entităţi.
3. Pe baza specificațiilor tehnice elaborate, gândiți și propuneți profesorului denumirile lucrărilor individuale implementate în sistem în procesul de realizare a fiecăreia dintre lucrările cheie plasate în diagrama de descompunere de nivelul doi.
4. Executarea paragrafelor Înregistrați 1-3 teme pentru acasă într-un fișier numit „ Informații pentru lecția 3.doc „, realizată în Cuvânt, și prezentată profesorului.
5. Lucrați prin secțiunea " Informații teoretice pentru pregătirea practică» atelier la a 3-a lecție.

1.6. Fragment al diagramei arborelui nodurilor la efectuarea descompunerii blocului de contabilitate a activității conform celei de-a doua opțiuni (IDEF3)

Dicţionar de activitate

Nume	Definiție
	Analiza informațiilor citite din baza de date pentru a satisface criteriile specificate
Analiza documentelor	Analiza documentelor însoțitoare și primite pentru conformitatea cu standardele
Întreținerea bazei de date	Efectuarea operațiunilor de actualizare a datelor
ÎN CURS LOC DE MUNCA	Numele funcției de context care definește SCOPUL și limitele simulării
Prelucrare finală	Luarea si formularea unei decizii (POZITIV daca datele indeplinesc criteriile specificate si NEGATIV in caz contrar), precum si crearea si prelucrarea documentelor necesare
Control de calitate și testare	Lucrări care finalizează un proces de fabricație sau dezvoltare
Procesarea datelor	Efectuarea de operațiuni de căutare și analiză a datelor și luarea deciziilor pe baza analizei efectuate
Prelucrarea rezultatelor controlului calității	Sistematizarea si analiza rezultatelor pentru conformitatea cu standardul
Prelucrarea rezultatelor testelor	Analiza rezultatelor pentru funcționalitate, fiabilitate și supraviețuire
Hârtii	Primirea documentelor și selectarea informațiilor care urmează să fie introduse în baza de date
	Căutarea datelor în tabelele bazei de date pe baza interogărilor create de utilizator
Reumplerea bazei de date	Introducerea de noi date în tabelele bazei de date
Recepția și înregistrarea documentelor	Recepția și înregistrarea documentelor de însoțire primite
Productie sau dezvoltare	Numele procesului cheie de afaceri al companiei (modelul părții de producție a domeniului subiect)
Lucrul în prima etapă a procesului de afaceri1	O acțiune care rezumă operațiunile tehnologice din prima etapă a procesului de producție
Lucru în etapa a 2-a a procesului de afaceri1	O acțiune care rezumă operațiunile tehnologice din a doua etapă a procesului de producție
Lucrul în etapa a 3-a a procesului de afaceri1	O acțiune care rezumă operațiunile tehnologice din a treia etapă a procesului de producție
Prelucrarea rezultatelor activităților de producție	Recepția și analiza documentelor pe baza rezultatelor muncii și controlului în curs
Editarea bazei de date	Modificarea înregistrărilor în tabelele bazei de date
ACTIVITATE CONTABILITATEA	Prelucrarea documentației și raportarea (modelul părții de non-producție a domeniului de studiu)

Dicţionar Arrow

Nume	Definiție
	Obiecte care nu îndeplinesc cerințele standardului
DATE DE INTRARE	Documente primite și obiecte de procesare
Date de intrare DB	Datele care urmează să fie scrise în tabelele bazei de date
Documentele primite	Documente care însoțesc obiectele de procesare și documentele care inițiază un proces de afaceri
IEȘIRE	Documente trimise, obiecte noi și modificate
Documente de ieșire	Documente (formulare, rapoarte, instrucțiuni, declarații, contracte etc.) create în timpul procesului de contabilitate
Standard de stat	Standard de stat pentru documentare
Datele din tabelul bazei de date	Date citite din tabelele bazei de date
Date obţinute în urma analizei	Informații destinate procesării documentelor emise și utilizate la luarea deciziilor
Date care caracterizează rezultatele lucrului cu documente	Informații care reflectă detaliile (caracteristicile calitative și cantitative) ale obiectelor prelucrate
Documente privind rezultatele testării și controlului	Documente care reflectă datele obținute în etapa finală a procesării obiectului
Descrierea postului	Instrucțiuni care reflectă responsabilitățile locului de muncă ale interpretului
Cererile utilizatorilor
Obiecte noi și schimbate	Obiecte create și modificate în timpul ciclului de producție
Obiecte baze de date	Tabele, formulare, interogări, rapoarte, macrocomenzi și module
Prelucrarea obiectelor	Obiecte care se modifică în diferite etape ale procesului de producție
Obiecte procesate la etapa 1	Obiecte schimbate la prima etapă a procesului de producție
Obiecte procesate în etapa 2	Obiecte modificate în etapa a 2-a a procesului de producție
Obiecte procesate la etapa 3	Obiecte modificate în etapa a 3-a a procesului de producție
	Departamentul de control tehnic verifică obiectul creat pentru conformitatea cu cerințele standardului
Divizii de companie și profesioniști	Entități implicate în procesul de producție sau dezvoltare
REGULI DE EXECUTARE	Reguli pentru transformarea proceselor și a datelor
Reguli contabile	Un sistem de înregistrare și procesare a documentației care însoțește procesul de producție sau dezvoltare
DECIZIE	O decizie pozitivă sau negativă luată în funcție de dacă datele analizate îndeplinesc criteriile specificate
Documente acceptate	Documente care au fost înregistrate
Software	Platforma pe care este implementata baza de date in curs de dezvoltare
Rezultatele analizei documentului	Rezultate obținute în urma analizării documentelor primite și însoțitoare pentru conformitatea cu standardele
Rezultate controlul calității
rezultatele căutării	Informații din tabelele bazei de date obținute din solicitările utilizatorilor
Rezultatele testului	Datele obținute în etapa finală a prelucrării
Manualul utilizatorului	Instrucțiuni și reguli pentru lucrul cu baza de date
Serviciu de contabilitate	Departamentele implicate în procesul de contabilitate și documentare
Documente însoțitoare	Documente care însoțesc obiectele de procesare primite
Specialisti profesionisti	Subiecții implicați în activități de producție
Instructiuni tehnologice	Secvența operațiilor proceselor tehnologice
Cererile utilizatorilor	Interogări create de utilizator pentru a prelua informațiile necesare din baza de date și pentru a crea documente de ieșire
MECANISM DE EXECUTARE	Resurse care transformă datele de intrare în date de ieșire
Intrări noi	Înregistrări în tabelele bazei de date care au apărut după introducerea datelor noi
Corecţie
	Subiectul care efectuează examenul

versiune tipărită