Un exemplu de construire a unui model DFD. Metodologii de modelare a domeniului Diagramarea fluxului de date dfd

Diagramele fluxului de date (GRD) sunt principalele mijloace de modelare a cerințelor funcționale pentru sistemul proiectat. Cu ajutorul lor, cerințele sunt reprezentate ca o ierarhie de componente funcționale (procese) conectate prin fluxuri de date. obiectivul principal o astfel de reprezentare este de a demonstra modul în care fiecare proces își transformă intrările în ieșiri, precum și de a dezvălui relațiile dintre aceste procese.

Pentru a construi diagrame EGO se folosesc două notații diferite, corespunzătoare metodelor lui Jordan și Gein-Serson, care diferă ușor în reprezentările grafice ale simbolurilor. În plus, atunci când construiești exemple, se va folosi notația Hein-Serson. Construcția diagramelor FDT este asociată în mare parte cu dezvoltarea sistemelor software, iar notația EDF a fost dezvoltată inițial în acest scop.

În conformitate cu aceste metode, modelul de sistem este definit ca o ierarhie a fluxurilor de date care descriu procesul asincron de transformare a informațiilor de la intrarea în sistem până la emiterea acestuia către utilizator. Diagramele nivelurilor superioare ale ierarhiei (diagramele de context) definesc principalele procese sau subsisteme cu intrări și ieșiri externe. Ele sunt detaliate folosind diagrame de nivel inferior. Această descompunere continuă, creând o ierarhie de diagrame pe mai multe niveluri, până când se ajunge la un asemenea nivel de descompunere la care procesele devin elementare, astfel încât este imposibil să le detaliem mai departe.

Surse de informare (entitati externe) generează fluxuri de informații (fluxuri de date) care transportă informații către subsisteme sau procese. Aceștia, la rândul lor, transformă informațiile și generează noi fluxuri care transferă informații către alte procese sau subsisteme, stocarea datelor sau entități externe – consumatori de informații.

Principalele componente ale diagramelor OGB sunt:

• entitati externe;
• sisteme și subsisteme;
• dispozitive de stocare a datelor;
• fluxuri de date.

Entitățile externe sunt obiecte materiale sau individual, care este o sursă sau un receptor de informații, cum ar fi un client, personal, furnizor, client, depozit. Definirea unui obiect sau a unui sistem ca entitate externă indică faptul că acestea se află în afara granițelor sistemului analizat. În timpul analizei, unele entități externe pot fi mutate în interiorul diagramei sistemului analizat, dacă este necesar, sau, dimpotrivă, unele dintre procese pot fi mutate în afara diagramei și prezentate ca entitate externă.

O entitate externă este indicată printr-un pătrat (Fig. 5.12), situat, parcă, deasupra diagramei și aruncând o umbră, astfel încât simbolul să poată fi distins de alte denumiri. Când se construiește un model al unui sistem software complex, acesta poate fi reprezentat în cea mai generală formă pe așa-numita diagramă de context ca una

sistem ca întreg sau poate fi descompus în mai multe subsisteme (Fig. 5.13).

Orez. 5.12.

Identificator

contor de bușteni

FieldName Câmp

fizic

implementare

Orez. 5.13. Diagrama de context

Numărul subsistemului servește la identificarea acestuia. În câmpul nume, numele subsistemului este introdus sub forma unei propoziții cu subiectul și definițiile și completările corespunzătoare.

Proces este o transformare fluxuri de intrare date la ieșire în conformitate cu un anumit algoritm. Din punct de vedere fizic, procesul poate fi implementat în diverse moduri: poate fi o subdiviziune (departament) a unei organizații care efectuează anumite procesări ale documentelor de intrare și eliberarea de rapoarte, un program, un dispozitiv fizic implementat hardware etc. Procesul din diagramă este reprezentat ca un dreptunghi cu colțuri rotunjite (Fig. 5.14).

Câmp de număr

Câmp de nume Câmp

fizic

implementare

Orez. 5.14. Procesează imaginea

Numărul procesului este utilizat pentru a-l identifica. În câmpul nume, numele procesului este introdus sub forma unei propoziții cu un verb activ fără ambiguitate într-o formă nedefinită („calculați”, „verificați”, „calculați”, „creați”, etc.), urmat de un substantiv în cazul acuzativ (Fig. 5.14 ). Utilizarea verbelor precum „procesează”, „modernizează” sau „editează” indică o lipsă de înțelegere a acestui proces și necesită o analiză suplimentară. Informațiile din câmpul de implementare fizică indică departamentul, programul sau dispozitivul care rulează procesul.

Stocare a datelor- acesta este un dispozitiv abstract pentru stocarea informațiilor care pot fi introduse în unitate în orice moment și îndepărtate după un timp, iar metodele de inserare și extragere pot fi oricare. Un dispozitiv de stocare a datelor (stocare) poate fi implementat fizic sub forma unui tabel în RAM, a unui fișier pe un disc magnetic, a unui dulap de fișiere etc. Dispozitivul de stocare a datelor din diagramă este identificat prin litera și un număr arbitrar. Numele unității este ales din motive pentru cel mai mare conținut de informații pentru proiectant (Fig. 5.15).

Identificare

Câmp de nume

Orez. 5.15. Imaginea unității de date

Acumulatorul de date este în general un prototip al viitoarei baze de date, descrierea datelor stocate în acesta ar trebui să fie legată de modelul informațional (NIM). Fluxul de date este reprezentat de o săgeată și descrie mișcarea informațiilor de la sursă la receptor. În realitate, aceasta poate fi informații transmise printr-un cablu între două dispozitive, scrisori trimise prin poștă, dischete mutate de la un computer la altul etc. Fiecare flux are un nume care reflectă conținutul său (Figura 5.16).

Generați declarații de impozit pe venit

raportare

Raportarea pe

impozit pe venit

Orez. 5.16.

Legăturile din diagramele PBP pot fi rupte (furcate) în părți și fiecare segment rezultat poate fi redenumit în așa fel încât să arate descompunerea datelor transportate de un flux (Fig. 5.17). Săgețile pot fi interconectate (combinate) pentru a forma obiecte complexe. De exemplu, pentru a forma adresa unui contribuabil este necesar să aveți date despre elementele acestuia (codul poștal, orașul, strada, numărul casei și numărul apartamentului).

Notați adresa contribuabilului

Departamentul de contabilitate a contribuabililor

Orez. 5.17.

Când utilizați diagrame WSE pentru a modela cerințele funcționale pentru sistem software, pentru claritatea înțelegerii lor și comoditatea proiectantului, ei construiesc o ierarhie de diagrame. În acest caz, este recomandabil să urmați următoarele recomandări:

• plasați pe fiecare diagramă de la 3 la 6-7 procese;
• nu aglomerați diagramele cu detalii nesemnificative la acest nivel;
• descompunerea fluxurilor de date pentru a se efectua în paralel cu descompunerea proceselor;
• alegeți nume clare și semnificative pentru procese și fire, evitând abrevierile.

Primul pas în construirea unei ierarhii de diagrame de flux de date este de a construi diagrame de context care să arate modul în care sistemul pe care îl proiectați va interacționa cu utilizatorii și alte sisteme externe (oarecum analog cu cazurile de utilizare în obiect). abordare orientată). Atunci când se proiectează sisteme relativ simple, este suficientă o diagramă de context, care are o topologie în stea, în centrul căreia se află procesul principal conectat la sursele și receptorii de informații.

Pentru sistemele complexe se construiește o ierarhie a diagramelor de context, care determină interacțiunea principalelor subsisteme funcționale ale sistemului care se proiectează, atât între ele, cât și cu fluxurile de date externe de intrare și ieșire și obiecte externe. În același timp, diagrama contextului de nivel superior conține un set de subsisteme conectate prin fluxuri de date. Diagramele de context de nivel următor detaliază conținutul și structura subsistemelor.

După construirea diagramelor de context, modelul rezultat trebuie verificat pentru caracterul complet al datelor inițiale privind obiectele sistemului și izolarea obiectelor (lipsa legăturilor de informații cu alte obiecte). Pentru fiecare subsistem prezent pe diagramele de context, acesta este detaliat folosind diagrame BDT. Fiecare eveniment este reprezentat ca un proces cu fluxuri de intrare și ieșire corespunzătoare, acumulatori de date, entități externe, legături către alte procese pentru a descrie legăturile dintre acest proces și mediul său.

Fiecare proces din diagrama YGO, la rândul său, poate fi detaliat folosind un ERE sau (dacă procesul este elementar) o specificație. Când detaliile trebuie respectate urmând reguli:

• regula de echilibrare, ceea ce înseamnă că atunci când detaliezi un subsistem, poți folosi doar acele componente (subsisteme, procese, entități externe, unități de date) cu care are conexiune pe diagrama părinte;
• regula de numerotare, care prevede că atunci când se detaliază procesele, numerotarea lor ierarhică ar trebui să fie suportată.

Specificația procesului ar trebui să-și formuleze principalele funcții în așa fel încât pe viitor specialistul care implementează proiectul să le poată îndeplini sau să dezvolte un program adecvat. Specificația este vârful final al ierarhiei.O/ 7 /). Decizia de a finaliza procesul de detaliere și utilizarea specificației este luată de analist pe baza următoarelor criterii:

• procesul are o cantitate mică de date de intrare și de ieșire (2-3 fire);
• posibilitatea de a descrie transformarea datelor printr-un proces în formă algoritm secvenţial;
• executarea prin procesul unei singure funcții logice de conversie a informațiilor de intrare în informații de ieșire;
• posibilitatea de a descrie logica procesului folosind o specificare a unui volum mic (nu mai mult de 20-30 de linii).

Specificațiile trebuie să îndeplinească următoarele cerințe:

• trebuie să existe o specificație (și doar una) pentru fiecare proces de nivel scăzut;
• specificația trebuie să definească modul în care fluxurile de intrare sunt convertite în fluxuri de ieșire;
• nu este nevoie (cel puțin în stadiul formării cerințelor) să se determine metoda de implementare a acestei transformări;
• specificația ar trebui să se străduiască să limiteze redundanța: nu trebuie să redefinim ceea ce a fost deja definit în diagramă;
• setul de construcții pentru caietul de sarcini trebuie să fie simplu și de înțeles.

De fapt, specificația este o descriere a algoritmilor pentru sarcinile efectuate de procese. Specificațiile conțin numărul și (sau) numele procesului, liste de date de intrare și de ieșire și corpul (descrierea) procesului, care este o specificație a unui algoritm sau a unei operații care transformă fluxurile de date de intrare în cele de ieșire. Sunt cunoscute un număr mare de metode diferite pentru a descrie corpul procesului. Limbile asociate cu aceste metode pot varia de la limbaj natural structurat, sau pseudocod, la limbaje de design vizual.

Limbajul natural structurat este folosit pentru o descriere lizibilă, suficient de riguroasă a specificațiilor procesului. Un astfel de limbaj constă dintr-un subset de cuvinte organizate în structuri logice specifice, expresii aritmetice și diagrame. Structurile de control ale limbajului includ construcția secvențială, construcția selecției și iterația (bucla).

Când se utilizează limbajul natural structurat, se adoptă următoarele convenții:

• logica procesului este exprimată ca o combinație de constructe secvențiale, constructe de selecție și iterații;
• verbele ar trebui să fie active, lipsite de ambiguitate și concentrate pe acțiunea țintă (de exemplu, „umple”, „calcula”, „extrage”, și nu „modernizează”, „procesează”);
• logica procesului trebuie exprimată clar și fără ambiguitate.

Când construiți o ierarhie de diagrame de flux de date, mergeți

detalierea proceselor urmează doar după definirea structurilor de date care descriu conținutul tuturor fluxurilor și depozitelor de date. Structurile de date pot conține alternative, condiționale și iterații. Alternativ înseamnă că unul dintre elementele enumerate poate fi inclus în structură. Apariția condiționată indică faptul că componenta dată poate să nu fie prezentă în structură. Iterația implică apariția oricărui număr de elemente din intervalul specificat.

Pentru fiecare element se poate specifica tipul acestuia (continuu sau discret). Pentru date continue, pot fi specificate o unitate de măsură, un interval de valori, o precizie de reprezentare și o formă de codificare fizică. Pentru date discrete, poate fi specificat un tabel cu valori valide.

După construirea unui model de sistem complet, acesta trebuie verificat (verificat pentru completitudine și coerență). Într-un model complet, toate obiectele sale (subsisteme, procese, fluxuri de date) trebuie descrise și detaliate în detaliu. Într-un model consistent, toate fluxurile de date și depozitele de date trebuie să se supună regulii de conservare a informațiilor: toate datele primite undeva trebuie citite și toate datele citite trebuie scrise.

Baza acestei metodologii pentru modelarea grafică a sistemelor informaționale este o tehnologie specială pentru construirea diagramelor de flux de date DFD. La elaborarea metodologiei DFD au participat mulți analiști, printre care trebuie remarcat E. Yordon (E. Yourdon). Este autorul uneia dintre primele notații grafice DFD. În prezent, cea mai comună este așa-numita notație Gene-Sarson, ale cărei elemente principale vor fi discutate în această secțiune.

Modelul de sistem în contextul DFD este reprezentat ca un model informațional, ale cărui componente principale sunt diverse fluxuri de date care transferă informații de la un subsistem la altul. Fiecare dintre subsisteme realizează anumite transformări ale fluxului de date de intrare și transmite rezultatele prelucrării informațiilor sub formă de fluxuri de date către alte subsisteme.

Principalele componente ale diagramelor de flux de date sunt:

Entități externe

Unități de date sau stocare

Procesele

Fluxuri de date

Sisteme/subsisteme

O entitate externă este un obiect material sau individ care poate acționa ca sursă sau receptor de informații. Definiția unui obiect sau sistem ca entitate externă nu este strict fixă. Deși entitatea externă se află în afara granițelor sistemului în cauză, în procesul de analiză ulterioară, unele entități externe pot fi transferate în interiorul diagramei modelului sistemului. Pe de altă parte, procesele individuale pot fi scoase din diagramă și prezentate ca entități externe. Exemple de entități externe sunt: ​​clienții organizației, clienții, personalul, furnizorii.

O entitate externă este indicată printr-un dreptunghi cu umbră (Fig. 2.15), în interiorul căruia este indicată numele acesteia. În acest caz, se recomandă utilizarea unui substantiv în cazul nominativ ca nume. Uneori, o entitate externă este numită și terminator.

Orez. 2.15. Imaginea unei entități externe într-o diagramă de flux de date

Un proces este un set de operații pentru conversia fluxurilor de date de intrare în fluxuri de ieșire în conformitate cu un anumit algoritm sau regulă. Deși un proces poate fi implementat fizic într-o varietate de moduri, cel mai adesea se înțelege implementarea software a procesului. Un proces într-o diagramă de flux de date este reprezentat printr-un dreptunghi rotunjit (Figura 2.16) împărțit în trei secțiuni sau câmpuri prin linii orizontale. Câmpul cu numărul procesului este utilizat pentru identificarea acestuia din urmă. Câmpul din mijloc indică numele procesului. Ca nume, se recomandă folosirea unui verb în formă nedefinită cu completările necesare. Câmpul de jos conține o indicație a modului în care procesul este implementat fizic.

Orez. 2.16. Imagine a unui proces într-o diagramă de flux de date

Orez. 2.17. Imagine a unui subsistem într-o diagramă de flux de date

Modelul informaţional al sistemului este construit ca o diagramă ierarhică sub forma unei aşa-numite diagrame de context, pe care modelul iniţial este reprezentat secvenţial ca model de subsisteme ale proceselor de transformare a datelor corespunzătoare. În acest caz, subsistemul sau sistemul din diagrama de context DFD este reprezentat în același mod ca și procesul - un dreptunghi cu vârfuri rotunjite (Fig. 2.17).

Un depozit sau o stocare de date este un dispozitiv abstract sau o metodă de stocare a informațiilor care sunt mutate între procese. Se presupune că datele pot fi introduse în unitate în orice moment și recuperate după un anumit timp, iar metodele fizice de plasare și preluare a datelor pot fi arbitrare. Dispozitivul de stocare a datelor poate fi implementat fizic în diferite moduri, dar cel mai adesea se presupune că este implementat în în format electronic pe medii magnetice. Acumulatorul de date de pe diagrama fluxului de date este reprezentat ca un dreptunghi cu două câmpuri (Fig. 2.18). Primul câmp este folosit pentru a specifica numărul sau ID-ul unității, care începe cu litera „D”. Al doilea câmp este folosit pentru a specifica numele. În acest caz, se recomandă utilizarea unui substantiv ca nume al unității, care caracterizează metoda de stocare a informațiilor corespunzătoare.

Orez. 2.18. Imaginea unei unități într-o diagramă de flux de date

În cele din urmă, fluxul de date determină natura calitativă a informației transmise printr-o conexiune de la sursă la receptor. Fluxul de date real poate fi transmis printr-o rețea între două computere sau în orice alt mod care permite extragerea și restaurarea datelor în formatul necesar. Fluxul de date într-o diagramă DFD este reprezentat printr-o linie cu o săgeată la un capăt, săgeata indicând direcția fluxului de date. Fiecare flux de date are propriul nume, reflectând conținutul său.

Astfel, modelul informațional al sistemului în notația DFD este construit sub formă de diagrame de flux de date, care sunt reprezentate grafic folosind notația corespunzătoare. Ca exemplu, luați în considerare un model simplificat al procesului de primire a unei anumite sume de numerar pe un card de credit de către un client al unei bănci. Entitățile externe din acest exemplu sunt un client al unei bănci și, eventual, un angajat al băncii care controlează procesul de servicii pentru clienți. Acumulatorul de date poate fi o bază de date cu privire la starea conturilor clienților individuali ai băncii. Fluxurile de date individuale reflectă natura informatiile transmise necesare pentru a servi un client al unei bănci. Modelul corespunzător pentru acest exemplu poate fi reprezentat ca o diagramă de flux de date (Figura 2.19).

În prezent, diagramele fluxului de date sunt utilizate în unele instrumente CASE pentru a construi modele de informații ale sistemelor de procesare a datelor. Principalul dezavantaj al acestei metodologii este asociat și cu lipsa mijloacelor explicite pentru reprezentarea orientată pe obiect a modelelor de sisteme complexe, precum și pentru reprezentarea algoritmilor de procesare complexi.

date. Deoarece diagramele DFD nu indică caracteristicile timpului de execuție al proceselor individuale și ale transferului de date între procese, modelele de sisteme care implementează prelucrarea sincronă a datelor nu pot fi reprezentate adecvat în notația DFD. Toate aceste caracteristici ale metodologiei de analiză a sistemului structural au limitat posibilitățile de aplicare largă a acesteia și au servit drept bază pentru includerea instrumentelor adecvate într-un limbaj de modelare unificat.

Orez. 2.19. Un exemplu de diagramă DFD pentru procesul de obținere a banilor de pe un card de credit

La construirea unui model funcțional al sistemului, o alternativă la metodologie () este metodologia diagrame de flux de date (Diagrame de flux de date, DFD). Spre deosebire de , conceput pentru proiectarea sistemelor în general, DFD este conceput pentru proiectarea sistemelor informaționale. Accentul acestei metodologii pe proiectare sisteme automatizateîl face un instrument convenabil și mai profitabil pentru construirea unui model funcțional TO-BE.

La construirea diagramelor se disting elementele de notație grafică, prezentate în tabel. 6.1.

Tabelul 6.1. Elemente de notație grafică DFD

Nume	Notație Jordan	Notația Gein-Sarson
Flux de date
Proces (sistem, subsistem)
Stocare a datelor
entitate externă

Flux de date defineşte informaţia (obiectul material) transmisă printr-o conexiune de la sursă la receptor. Fluxul propriu-zis de date poate fi informații transmise printr-un cablu între două dispozitive, trimise prin poștă, scrisori, benzi magnetice sau dischete, transferate de la un computer la altul etc.

Fiecare flux de date are un nume care reflectă conținutul său. Direcția săgeții arată direcția fluxului de date. Uneori, informațiile se pot mișca într-o singură direcție, pot fi procesate și returnate la sursă. O astfel de situație poate fi modelată fie prin două fluxuri diferite, fie prin unul - bidirecțional.

Definiția unui obiect, subiect sau sistem ca entitate externă indică faptul că acesta se află în afara granițelor proiectate. Sistem informatic. Ca rezultat, entitățile externe sunt de obicei afișate numai în diagrama de context DFD. În procesul de analiză și proiectare, unele entități externe pot fi transferate în diagrame de descompunere, dacă este necesar, sau, dimpotrivă, o parte din procese (subsisteme) poate fi reprezentată ca o entitate externă.

Construcția unui model funcțional DFD începe, ca în IDEF0, cu dezvoltarea unei diagrame de context. Afișează procesul principal (sistemul în sine ca întreg) și conexiunile acestuia cu mediul extern (entități externe). Această interacțiune este afișată prin fluxuri de date. Este permisă afișarea simultană a mai multor procese sau subsisteme principale pe diagrama de context. Un exemplu de diagramă de context pentru problema luată în considerare este prezentat în figura următoare.

Orez. 6.23. Diagrama de context a sistemului de determinare a vitezelor admisibile (metodologia DFD)

Această diagramă arată că, ca sursă de date inițiale pentru funcționarea sistemului, poate fi utilizată baza de date ARM-P (Workstation of the track service) sau SBD-P (Consolidated DB - Way fragment), care conține aproape toate informațiile necesare pe tronsoane de drum.

Totodată, sistemul păstrează posibilitatea introducerii și reglarii sale manuale. În ciuda faptului că bazele de date ARM-P sau SDB-P sunt entități externe în raport cu sistemul, acestea sunt prezentate ca un stoc de date pentru o mai bună percepție.

Un alt proces de proiectare este de a construi diagrame de descompunere, care sunt construite (arată dispozitivul) numai pentru procese sau subsisteme (sisteme) .

Diagrama de descompunere a primului nivel al sistemului proiectat este prezentată în figura următoare.

Orez. 6.24. Diagrama de descompunere de prim nivel (metodologia DFD)

În această figură, unor fluxuri de date legate de unitate le lipsesc nume. Acest lucru vă permite să eliminați duplicarea etichetelor și, ca urmare, să reduceți saturația diagramei.

La construirea unei diagrame de descompunere, blocurile sistemului în unele cazuri sunt afișate ca procese (numele începe cu un verb), în altele - ca subsisteme (numele începe cu cuvântul „subsistem”). Acest lucru se face pentru a ilustra regulile de denumire a blocurilor. În același timp, descompunerea sistemului ar putea fi reprezentată fie folosind numai procese, fie numai subsisteme.

Diagrama de context și diagrama de descompunere sunt realizate folosind BPwin 4.0.

Decizia de a completa detaliile procesului și de a utiliza mini-specificația este luată de proiectant pe baza următoarelor criterii:

Procesul are un număr relativ mic de fluxuri de date de intrare și de ieșire (2–3 fluxuri);

Abilitatea de a descrie procese sub forma unui algoritm simplu;

Posibilități de descriere a logicii procesului folosind o mini-specificație mică (nu mai mult de 20-30 de linii).

Modelul DFD, pe lângă descrierea aspectului funcțional al sistemului, conține și informații despre aspectele informaționale și componente. Setul de dispozitive de stocare a datelor este un prototip al viitoarei baze de date, adică. determină compoziţia şi structura informaţiei. Construcția diagramelor folosind subsisteme ca blocuri arată compoziția și conexiunile componentelor viitorului sistem.

6.12. Extensii DFD pentru sisteme în timp real

Sistemele în timp real sunt construite, de regulă, pe interacțiunea mijloacelor informaticăși diverse dispozitive fizice pentru preluarea informațiilor (senzori, camere, microfoane etc.). Primele sunt convertoare de informații discrete, cele din urmă sunt în principal analogice, adică. generând informații într-un flux continuu. O altă caracteristică a unor astfel de sisteme este o părtinire semnificativă față de managementul obiectelor. Pentru a modela comportamentul sistemelor în timp real, P. Ward și S. Mellor au sugerat utilizarea unor elemente suplimentare pe DFD.

DFD ), care oferă descrierea corectă a ieșirilor (răspunsul sistemului sub formă de date) pentru un efect dat asupra intrării sistemului (semnale prin interfețe externe). Diagramele fluxului de date sunt principalele mijloace de modelare cerințe funcționale la sistemul proiectat.

În timp ce creați diagrame de flux de date sunt utilizate patru concepte de bază: fluxuri de date, procese (lucrări) de conversie a fluxurilor de date de intrare în cele de ieșire, entități externe, stocare (stocare) a datelor.

Fluxuri de date sunt abstracții folosite pentru a modela transferul de informații (sau componente fizice) de la o parte a unui sistem la alta. Fluxurile din diagrame sunt reprezentate de săgeți numite, a căror orientare indică direcția fluxului de informații.

Scop proces(de lucru) constă în producerea fluxurilor de ieșire din fluxurile de intrare în conformitate cu acțiunea dată de numele procesului. Numele procesului trebuie să conțină un verb nedefinit urmat de o adăugare (de exemplu, „primiți documente de expediere”). Fiecare proces are un număr unic la care se face referire în diagramă, care poate fi utilizat împreună cu numărul diagramei pentru a obține indice unic proces în întregul model.

Stocarea datelor (unitate) vă permite să definiți date în zonele specificate care vor fi stocate în memorie între procese. De fapt, stocarea reprezintă „slice” de fluxuri de date în timp. Informațiile pe care le conține pot fi folosite în orice moment după ce au fost primite, iar datele pot fi selectate în orice ordine. Numele depozitului trebuie să-și identifice conținutul și să fie un substantiv.

entitate externă reprezintă un obiect material în afara contextului sistemului care este sursa sau receptorul datelor de sistem. Numele său trebuie să conțină un substantiv, cum ar fi „depozitul de mărfuri”. Se presupune că obiectele reprezentate ca entitati externe, nu ar trebui să participe la nicio prelucrare.

Pe lângă elementele principale, DFD include dicționare de date și mini-specificații.

Dicționare de date sunt directoare ale tuturor elementelor de date prezente în DFD, inclusiv fluxuri de date de grup și individuale, depozite și procese, precum și toate atributele acestora.

Prelucrare minispec- descrie procesele DFD de nivel inferior. De fapt, mini-specificațiile sunt algoritmi de descriere a sarcinilor efectuate de procese: setul tuturor mini-specificațiilor este specificația completă a sistemului.

Procesul de construire a unui DFD începe cu crearea așa-numitei diagrame principale de tip „stea”, care reprezintă procesul simulat și toate entitati externe cu care interactioneaza. În cazul unui proces principal complex, acesta este imediat reprezentat ca o descompunere într-un număr de procese care interacționează. Criteriile de complexitate în acest caz sunt: ​​prezența unui număr mare entitati externe, multifuncționalitatea sistemului, natura sa distribuită. Entitățile externe sunt alocate în raport cu procesul principal. Pentru a le determina, este necesar să se identifice furnizorii și consumatorii procesului principal, adică. toate obiectele care interacționează cu procesul principal. În această etapă, descrierea interacțiunii constă în alegerea unui verb care să dea o idee despre modul în care entitatea externă folosește sau este folosită de procesul principal. De exemplu, procesul principal este „contabilitatea apelurilor cetățenilor”, entitatea externă este „cetățeni”, descrierea interacțiunii este „depune cereri și primește răspunsuri”. Această etapă este fundamentală, deoarece definește limitele sistemului modelat.

Pentru toți entitati externe este construit un tabel de evenimente care descrie interacțiunea lor cu firul principal. Tabelul de evenimente include numele entității externe, evenimentul, tipul acestuia (tipic pentru sistem sau excepțional, realizat în anumite condiții) și reacția sistemului.

La pasul următor, procesul principal este descompus într-un set de procese interconectate care fac schimb de fluxuri de date. Fluxurile în sine nu sunt specificate, se determină doar natura interacțiunii. Descompunerea se termină atunci când procesul devine simplu, adică:

1. procesul are două sau trei fluxuri de intrare și de ieșire;
2. procesul poate fi descris ca o transformare a datelor de intrare în date de ieșire;
3. procesul poate fi descris ca algoritm secvenţial.

Pentru procese simple, este construită o mini-specificație - o descriere formală a algoritmului pentru conversia datelor de intrare în date de ieșire.

Mini-specificația satisface următoarele cerințe: se construiește o specificație pentru fiecare proces; specificația definește în mod unic fluxurile de intrare și de ieșire pentru un proces dat; specificația nu definește modul în care fluxurile de intrare sunt convertite în fluxuri de ieșire; caietul de sarcini se referă la elemente existente fără a introduce altele noi; caietul de sarcini utilizează abordări și operațiuni standard ori de câte ori este posibil.

După descompunerea procesului principal, se construiește un tabel similar pentru fiecare sub-proces evenimente interne.

Următorul pas după definirea tabelului complet de evenimente este evidențierea fluxuri de dateîntre procese şi entitati externe. Cel mai simplu mod de a le izola este analiza tabelelor de evenimente. Evenimentele sunt convertite în fluxuri de date de la inițiatorul evenimentului în procesul solicitat, iar reacțiile sunt convertite într-un flux invers de evenimente. După construirea fluxurilor de intrare și de ieșire, fluxurile interne sunt construite într-un mod similar. Pentru alocarea acestora pentru fiecare dintre procesele interne sunt alocați furnizori și consumatori de informații. Dacă furnizorul de informații sau consumatorul reprezintă procesul de stocare sau solicitare a informațiilor, atunci se introduce un depozit de date pentru care acest proces este o interfață.

Odată ce fluxurile de date au fost construite, diagrama trebuie verificată pentru completitudine și coerență. Completitudinea diagramei este asigurată dacă nu există procese „atârnate” în sistem care să nu fie utilizate în procesul de conversie a fluxurilor de intrare în fluxuri de ieșire. Consistența sistemului este asigurată de implementarea unor seturi de reguli formale despre posibilele tipuri de procese: nu poate exista un flux pe diagramă care să conecteze două entitati externe– această interacțiune este scoasă din considerare; nicio entitate nu poate primi sau oferi direct informații depozitului de date - depozitul de date este un element pasiv gestionat printr-un proces de interfață; două depozite de date nu pot face schimb direct de informații - aceste depozite trebuie combinate.

Avantajele tehnicii DFD nu sunt diferite de cele convenționale; absența conceptului de timp, adică. lipsa analizei intervalelor de timp la conversia datelor (toate limitele de timp trebuie introduse în specificațiile proceselor).

Luați în considerare construirea unui model DFD al unui sistem de informații pentru o rețea de magazine care vând genți. Să completăm diagrama IDEF0 construită în lucrarea de laborator nr. 1 cu o diagramă DFD. Să construim o diagramă DFD pentru funcția A4 „Analiza lucru” Vezi fig. patru.

Orez. 4. Un exemplu de diagramă DFD

Exercițiu

1. Învață metoda DFD.
2. Supliment model functional sistem informatic, construit în lucrarea de laborator nr. 1, o diagramă de flux de date, pentru acele blocuri funcționale ale modelului IDEF0 pentru care doriți să afișați mișcarea datelor.
3. Răspunde la întrebări de securitate.
4. Fa un raport ( Pagina titlu, sarcină, diagramă DFD)

întrebări de testare

1. Ce procese din sistem sunt descrise folosind diagrame de flux de date?
2. Care sunt principalele obiecte ale diagramelor de flux de date?
3. Se folosește principiul descompunerii la construirea diagramelor DFD?
4. Locul în care săgeata intră în blocuri sau unde săgeata iese din bloc poate fi arbitrar sau supus unor reguli?
5. Cum este alocat un obiect unei entități externe?

Literatură

1. Fedotova, D.E. CASE-tehnologii: Practicum / D.E. Fedotova, Yu.D. Semenov, K.N. Chizhik. - M.: Linia fierbinte- Telecom, 2005. - 160 p.: ill.
2. Kalashyan, A.N. Modele structurale afaceri: DFD-technologies / A.N. Kalashyan, G.N. Kalyanov. - M.: Finanțe și statistică, 2003.
3. Diagrame de flux de date DFD. - http://www.proinfotech.ru/dmdlr2.htm.
4. Metode de modelare a proceselor de afaceri. - http://www.jetinfo.ru/2004/10/1/article1.10.2004153.html.

Construirea unei diagrame de descompunere în notație DFD

Obiectiv:

• construiți o diagramă de descompunere în notație DFD dintr-una dintre diagramele IDEF0 care au fost construite în laboratoarele anterioare

Diagramele fluxului de date (Dataflowdiagram, DFD) sunt utilizate pentru a descrie fluxul de lucru și procesarea informațiilor. La fel ca IDEF0, DFD reprezintă sistemul modelat ca o rețea de activități conexe. Ele pot fi folosite ca o completare la modelul IDEF0 pentru o afișare mai vizuală a operațiunilor curente ale fluxului de lucru în sistemele de procesare a informațiilor corporative. Scopul principal al DFD este să arate modul în care fiecare loc de muncă își transformă intrările în ieșiri și să dezvăluie relațiile dintre aceste locuri de muncă.

Orice diagramă DFD poate conține joburi, entități externe, săgeți (fluxuri de date) și depozite de date.

Lucrări. Lucrările sunt reprezentate prin dreptunghiuri cu colțuri rotunjite (Fig. 1), semnificația lor coincide cu semnificația lucrărilor IDEF0 și IDEF3. La fel ca IDEF3 funcționează, au intrări și ieșiri, dar nu acceptă controale și mecanisme precum IDEF0. Toate aspectele lucrării sunt egale. Fiecare job poate avea mai multe săgeți care intră și ies.

Figura 1. Lucrul în DFD

entitati externe. Entitățile externe reprezintă intrări și/sau ieșiri din sistem. O entitate externă poate furniza simultan intrări (funcționând ca furnizor) și recepționând ieșiri (funcționând ca receptor). O entitate externă este un obiect material, cum ar fi clienți, personal, furnizori, clienți, depozit. Definirea unui obiect sau a unui sistem ca entitate externă indică faptul că acestea se află în afara granițelor sistemului analizat. Entitățile externe sunt reprezentate ca un dreptunghi cu o umbră și sunt de obicei situate la marginile diagramei (Fig. 2).

Figura 2. Entitate externă în DFD

Săgeți (fluxuri de date). Săgețile descriu mișcarea obiectelor dintr-o parte a sistemului în alta (de aici rezultă că o diagramă DFD nu poate avea săgeți de limită). Deoarece toate laturile lucrării în DFD sunt egale, săgețile pot începe și se pot termina pe orice parte a dreptunghiului. Săgețile pot fi bidirecționale.

Magazin de date. Spre deosebire de săgețile care descriu obiecte în mișcare, depozitele de date descriu obiecte în repaus (Figura 3). Un depozit de date este un dispozitiv abstract pentru stocarea informațiilor care pot fi plasate într-o unitate în orice moment și recuperate după un anumit timp, iar metodele de punere și recuperare pot fi oricare. În cazul general, este un prototip al viitoarei baze de date, iar descrierea datelor stocate în aceasta trebuie să corespundă modelului informațional (Entity-RelationshipDiagram).

Figura 3. Stocarea datelor în DFD

Descompunerea lucrării IDEF0 într-o diagramă DFD. Când descompuneți munca IDEF0 în DFD, trebuie să faceți următoarele:

• eliminați toate săgețile de delimitare din diagrama DFD;
• să creeze entități externe și depozite de date adecvate;
• creați săgeți interioare începând cu entitățile exterioare în loc de săgeți de delimitare;
• săgețile de pe tunelul diagramei IDEF0

Respectarea strictă a regulilor de notație DFD nu este întotdeauna convenabilă, așa că BPWin vă permite să creați săgeți de delimitare în diagramele DFD.

Construirea unei diagrame de descompunere. Să descompunem lucrarea Livrare și aprovizionare diagrama A0 „Activitatea întreprinderii de asamblare și vânzare de calculatoare și laptopuri”. În această lucrare, am identificat următoarele sublucrări:

• procurarea componentelor necesare - se ocupa de activitati legate de gasirea furnizorilor potriviti si comandarea componentelor necesare de la acestia
• depozitarea componentelor și calculatoarelor asamblate
• expedierea produselor finite - toate acțiunile legate de ambalare, documente și expedierea efectivă a produselor finite

Să alocăm munca Livrare și aprovizionare diagrama A0 „Activitățile întreprinderii pentru asamblarea și vânzarea calculatoarelor și laptopurilor”, faceți clic pe butonul „GotoChildDiagram” din bara de instrumente și selectați notația DFD. La crearea unei diagrame copil, BPWin transferă săgețile de delimitare ale lucrării părinte, acestea trebuie eliminate și înlocuite cu entități externe. Săgeți de mecanism, săgeți de control „Reguli și proceduri”, „ Informații de control" și săgeata de ieșire "Rapoarte" de pe diagrama copil nu va fi folosită, pentru a nu aglomera diagrama cu detalii mai puțin semnificative. Restul săgeților vor fi înlocuite cu entități externe - butonul "ExternalReferenceTool" din bara de instrumente, în fereastra care apare, selectați butonul radio „Săgeată” și selectați-l pe cel dorit din numele listei (Fig. 4):

Figura 4. Adăugarea unei entități externe

Figura 5. Locuri de muncă și entități externe

Central aici este lucrarea „Depozitarea componentelor și calculatoarelor asamblate”. Primește calculatoare asamblate și componente primite de la furnizori, precum și o listă de componente necesare pentru asamblarea calculatoarelor. Ieșirea acestei lucrări va fi componentele necesare (dacă există), o listă de componente lipsă, trecute la intrarea lucrării „Aprovizionați componentele necesare” și computerele asamblate transferate pentru expediere. Ieșirile lucrării „Aprovizionarea componentelor necesare” și „Livrarea produselor finite” vor fi, respectiv, comenzi către furnizori și produse finite.

Următorul pas este să determinați ce informații sunt necesare pentru fiecare loc de muncă, de exemplu. trebuie plasat pe diagrama depozitului de date (Fig. 6).

Figura 6. Diagrama de descompunere finală

Jobul „Achiziționarea pieselor necesare” funcționează cu informații despre furnizori și cu informații despre comenzile plasate la acești furnizori. Săgeata care conectează jobul și depozitul de date „Vendor list” este bidirecțională. postul poate primi atât informații despre furnizorii existenți, cât și introduce date despre furnizori noi. Săgeata care conectează jobul cu depozitul de date „Lista de comenzi” este unidirecțională, deoarece work introduce doar informații despre comenzile efectuate.

Jobul „Depozitarea componentelor și calculatoarelor asamblate” funcționează cu informații despre componentele primite și emise și calculatoarele asamblate, prin urmare săgețile care conectează jobul cu depozitele de date „Lista de componente” și „Lista calculatoarelor asamblate” sunt bidirecționale. De asemenea, această lucrare, la primirea componentelor, ar trebui să menționeze că comanda către furnizori a fost finalizată. Pentru a face acest lucru, este conectat la magazinul de date „Lista de comenzi” printr-o săgeată unidirecțională. Vă rugăm să rețineți că aceeași stocare a datelor poate fi duplicată pe diagramele DFD.

În cele din urmă, jobul „Livrarea produselor finite” ar trebui să stocheze informații despre transporturile finalizate. Pentru a face acest lucru, introduceți stocarea de date adecvată - „Date de expediere”.

Ultimul pas este să tunelizați săgețile lucrării părinte (Fig. 7):

Figura 7. Diagrama IDEF0 cu săgeți tunelizate pentru activitatea de expediere și aprovizionare

• o scurtă descriere a lucrării de descompus
• diagrama de descompunere

Un exemplu de diagramă DFD a procesului „Compilarea unei sarcini tehnologice” folosind Bpwin